none
Modelos

Answers

  • Boa Tarde,

     

    Na verdade, é bem comum haverem três divisões.

    • Modelo conceitual
    • Modelo lógico
    • Modelo físico

    A fronteira entre essas divisões nem sempre é uma tarefa muito simples. É comum também que as vezes se coloque características de um modelo lógico no modelo conceitual e do modelo físico no modelo lógico.

     

    O modelo conceitual é uma representação que visa capturar de uma forma bem abstrata a representação de dados de uma situação de negócio. Nesse modelo falamos de entidades, de relacionamentos entre essa entidades e de atributos, mas não falamos da tecnologia utilizada. Posso ter uma entidade chamada clientes, uma entidade chamada pedidos e um relacionamento entre clientes e pedidos (um cliente tem vários pedidos) mas não necessariamente isso significa que clientes irá gerar uma tabela, pedidos irá gerar outra tabela e que haverá um FK. O modelo conceitual representa apenas conceitos e não tecnologias...

     

    No modelo lógico, derivamos o modelo conceitual para uma tecnologia específica como XML, Bancos de dados relacionais, banco de dados OO ou algum outro tipo de banco de dados (vale até sistema de arquivos embora não seja a escolha mais recomendada). Provavelmente nesse modelo lógico, teremos uma tabela de clientes, uma tabela de pedidos e uma FK, mas ainda assim se optarmos por um banco de dados relacional estamos apenas modelando para um banco de dados relacional sem considerar um produto específico

     

    No modelo físico, derivamos o modelo lógico para uma tecnologia específica. As tabelas definidas no modelo lógico podem gerar uma ou mais tabelas no modelo físico, ou pode-se ainda ter implementações não tão triviais. Pode-se por exemplo decidir criar uma única tabela de clientes e uma coluna XML (no caso do SQL Server 2005) com a relação de pedidos dentro dessa coluna (admitindo-se que um pedido não tenha outras características). Observe que essa implementação difere radicalmente do modelo lógico e que nesse modelo físico estamos realmente nos atendendo a características de um produto específico.

     

    Na prática (in)felizmente não é bem assim que funciona. Os analistas mais novos já na entrevista com o cliente já pensam no modelo de dados físico. O cliente fala que tem deseja um sistema de pedidos e o analista já está imaginando os índices, PKs e as consultas SQL que irá utilizar no seu banco de dados, quando a sua maior preocupação nesse momento não deveria ser com uma implementação física (muitas vezes o banco de dados relacional não é a melhor solução). É comum também que o vício em construir aplicações simples acabe por não mostrar ao implementador que a diferença entre os modelos pode ser muito pequena ou muito grande. E que para aplicações complexas essas diferenças são notórias.

     

    Outros fatores que fazem com que essa divisão acabe caindo por terra é que o modelo conceitual, cuja principais notações são o Peter Chain e o James Martin, acaba sendo substituído por outros documentos como o diagrama de casos de uso e o diagrama de classes de fronteira e negócio.

     

    Há também a questão do velho (e péssimo) hábito de não se documentar e quando se precisa de um modelo, opta-se por fazer uma engenharia reversa do banco de dados, o que naturalmente só nos fornece o modelo de dados físico, que com certeza é o pior de todos para entender de negócio.

     

    [ ]s,

     

    Gustavo

    Saturday, July 19, 2008 6:10 PM

All replies

  • Boa Tarde,

     

    Na verdade, é bem comum haverem três divisões.

    • Modelo conceitual
    • Modelo lógico
    • Modelo físico

    A fronteira entre essas divisões nem sempre é uma tarefa muito simples. É comum também que as vezes se coloque características de um modelo lógico no modelo conceitual e do modelo físico no modelo lógico.

     

    O modelo conceitual é uma representação que visa capturar de uma forma bem abstrata a representação de dados de uma situação de negócio. Nesse modelo falamos de entidades, de relacionamentos entre essa entidades e de atributos, mas não falamos da tecnologia utilizada. Posso ter uma entidade chamada clientes, uma entidade chamada pedidos e um relacionamento entre clientes e pedidos (um cliente tem vários pedidos) mas não necessariamente isso significa que clientes irá gerar uma tabela, pedidos irá gerar outra tabela e que haverá um FK. O modelo conceitual representa apenas conceitos e não tecnologias...

     

    No modelo lógico, derivamos o modelo conceitual para uma tecnologia específica como XML, Bancos de dados relacionais, banco de dados OO ou algum outro tipo de banco de dados (vale até sistema de arquivos embora não seja a escolha mais recomendada). Provavelmente nesse modelo lógico, teremos uma tabela de clientes, uma tabela de pedidos e uma FK, mas ainda assim se optarmos por um banco de dados relacional estamos apenas modelando para um banco de dados relacional sem considerar um produto específico

     

    No modelo físico, derivamos o modelo lógico para uma tecnologia específica. As tabelas definidas no modelo lógico podem gerar uma ou mais tabelas no modelo físico, ou pode-se ainda ter implementações não tão triviais. Pode-se por exemplo decidir criar uma única tabela de clientes e uma coluna XML (no caso do SQL Server 2005) com a relação de pedidos dentro dessa coluna (admitindo-se que um pedido não tenha outras características). Observe que essa implementação difere radicalmente do modelo lógico e que nesse modelo físico estamos realmente nos atendendo a características de um produto específico.

     

    Na prática (in)felizmente não é bem assim que funciona. Os analistas mais novos já na entrevista com o cliente já pensam no modelo de dados físico. O cliente fala que tem deseja um sistema de pedidos e o analista já está imaginando os índices, PKs e as consultas SQL que irá utilizar no seu banco de dados, quando a sua maior preocupação nesse momento não deveria ser com uma implementação física (muitas vezes o banco de dados relacional não é a melhor solução). É comum também que o vício em construir aplicações simples acabe por não mostrar ao implementador que a diferença entre os modelos pode ser muito pequena ou muito grande. E que para aplicações complexas essas diferenças são notórias.

     

    Outros fatores que fazem com que essa divisão acabe caindo por terra é que o modelo conceitual, cuja principais notações são o Peter Chain e o James Martin, acaba sendo substituído por outros documentos como o diagrama de casos de uso e o diagrama de classes de fronteira e negócio.

     

    Há também a questão do velho (e péssimo) hábito de não se documentar e quando se precisa de um modelo, opta-se por fazer uma engenharia reversa do banco de dados, o que naturalmente só nos fornece o modelo de dados físico, que com certeza é o pior de todos para entender de negócio.

     

    [ ]s,

     

    Gustavo

    Saturday, July 19, 2008 6:10 PM