/Design

voltar
/Design

Modelo Conceitual vs Modelo Lógico

PorThiago Ferreira em

Amigos, uma grande falha dos desenvolvedores web é achar que basta aprender a programar. A realidade do nosso mercado é que apenas um desenvolvedor produz todo o projeto sozinho, do início ao fim. Consequentemente, são poucos os que fazem análise, modelagem do banco de dados, layout, programação, testes, etc.

Logo, se o profissional sabe apenas programar, fatalmente ele fará um projeto que não seguirá normas, padrões, etc.

Por que estou falando isso tudo?

Porque vejo que muitos projetos são feitos com erros graves de modelagem de banco de dados. Não estou dizendo que não funcionam. Até funcionam! Mas precariamente, sem consistência e com muito mais lógica do que deveriam.

Esse artigo é direcionado àqueles que desenvolvem sistemas web e que ainda não têm esses conceitos. Não tenho a pretensão de fazer desse artigo uma verdadeira apostila ou livro. O objetivo é mostrar algumas técnicas e os principais erros cometidos e tão questionados em fóruns.

Iniciarei hoje mostrando algumas dicas para a transição do modelo conceitual para o modelo lógico.

Modelo Conceitual vs. Modelo Lógico

Utilizaremos pequenos trechos de diagramas de contexto hipotéticos para exercitar algumas formas de modelagem.

 

Relacionamento “um-para-um”.

Contexto:

Um produto tem estoque.

Modelo conceitual:

Modelo lógico:

Explicação:

Como não nos interessa manter dados do estoque senão sua quantidade, estoque não é uma entidade e por isso seus atributos (quantidade) são incorporadas pela entidade produto.

Observações:

Existem variações de relacionamentos “um-para-um”, mas que não abordarei neste momento.

 

Relacionamento “um-para-muitos”

Contexto:

Um departamento tem nenhum ou vários funcionários, mas um funcionário pode pertencer a somente um departamento.

Modelo conceitual:

Modelo lógico:

Explicação:

Quanto há um relacionamento “um-para-muitos”, a entidade do lado “N” recebe como atributo a chave primária da entidade do lado “um”.

Observação:

Caso haja dependência de existência entre as entidades, ou seja, uma entidade só possa existir se a outra existir, a chave primária da entidade do lado “um” passa a ser chave primária (e estrangeira) da entidade do lado “N”, juntamente com a chave primária dessa entidade. Ou seja, uma chave primária composta, na entidade do lado “N”.

 

Relacionamento “muitos-para-muitos”

Contexto:

Um aluno tem aulas de nenhuma ou várias disciplinas e uma disciplina é cursada por nenhum ou vários alunos.

Modelo conceitual:

Modelo lógico:

Explicação:

Num relacionamento “muitos-para-muitos”, é preciso criar uma tabela intermediária que terá como chave primária composta as chaves primárias das outras duas tabelas.

Observação:

Nessa tabela intermediária, você pode colocar atributos que identifiquem a relação entre as entidades. Exemplo: ano e semestre que o aluno está cursando a disciplina.

 

Auto-relacionamento “um-para-muitos”

Contexto:

Um funcionário supervisiona nenhum ou vários funcionários e um funcionário tem somente um supervisor.

Modelo conceitual:

Modelo lógico:

Explicação:

A própria entidade recebe como atributo a sua própria chave primária.

 

Auto-relacionamento “muitos-para-muitos”

Contexto:

Um aluno só poderá cursar a disciplina X se tiver sido aprovado nas disciplinas A e B. E só poderá cursar a disciplina Y se tiver sido aprovado na disciplina A.

Modelo conceitual:

Modelo lógico:

Explicação:

No contexto, podemos ver que a disciplina A é pré-requisito de X e Y. E a disciplina B é pré-requisito para X.

Nesse caso, criamos uma tabela que armazenará os relacionamentos entre as disciplinas. E essa tabela terá como chave primária composta a chave primária da outra tabela (duas vezes).

 

Relacionamento Generalização/Especialização

Contexto:

Precisamos armazenar o código de identificação, cor e capacidade de passageiros dos veículos que possuímos.

Para os veículos terrestres, é interessante armazenarmos a quantidade de rodas. Para os aquáticos, o tamanho em pés. Para os aéreos, a forma de propulsão (turbina, hélice, etc).

Modelo conceitual:

Modelo Lógico:

Explicação:

Nesse caso, temos que os atributos código de identificação, cor e capacidade de passageiros é comum para todos os tipos de veículos, mas que temos diferenças significativas de um tipo para o outro.

Se fizéssemos somente 3 tabelas (uma para cada tipo), teríamos que repetir os campos em comum. Em princípio, isso é errado! O correto é colocarmos os atributos comuns numa tabela abstrata e nas tabelas mais concretas somente os atributos inerentes a ela.

Existem outros tipos de relacionamento, como agregação e ternário, mas não são muito comuns e por isso não tratarei.

Conclusão

Modelagem de banco de dados não é uma ciência exata, assim como outros tipos de modelagem.

Portanto, não há verdade absoluta.

Essas regras podem mudar de caso para caso. Mas é preciso que tenhamos atenção para “quando” quebrar essas regras. Precisamos ser muito criteriosos e fazer testes.

Acredito que esse artigo seja muito útil para muita gente. A quantidade de erros de modelagem que vejo diariamente é espantosa e só acontecem por falta de conhecimento destas e de outras regras de modelagem de banco de dados.

Caso tenham dúvidas ou comentários, sugestões, críticas, etc, por favor, postem abaixo!

Abração!

Deixe um comentário! 29

29 comentários

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Thiago, vc acha que o trabalho dos DBA´s pode ou está sendo ameaçado pelo frameworks ORM? Pois eles fazem todo o mapeamento do banco, coisa que o programador pode implementar…

  2. Emerson, o trabalho de um DBA é muito mais do que a modelagem do banco. Além disso, há certas peculiaridades que os sistemas não “entregam prontas”, pois dependem de análise e experiência. Eu penso que os DBAs tendem a ter cada vez mais destaque num mundo sedento de informações rápidas e precisas.

  3. Thiago Ferreira, bom dia!

    Tudo bem, gostaria de pedir um favor, tenho um trabalho para entregar ainda hoje de modelo conceitual e lógico referente a um açougue, o modelo conceitual eu ja fiz só não fiz o Lógico, será que vc poderia me dar uma forcinha? anota meu email: camandona@hotmail.com

  4. Thiago Ferreira, bom dia!

    Tudo bem, gostaria de pedir um favor, tenho um trabalho para entregar ainda hoje de modelo conceitual e lógico referente a um açougue, o modelo conceitual eu ja fiz só não fiz o Lógico, será que vc poderia me dar uma forcinha? anota meu email: camandona@hotmail.com

  5. É exatamente tudo que eu precisava, eu ainda tinha algumas duvidas relacionadas a modelagem de bd, inclusive hoje tenho uma prova sobre a mesma.

    Otimo artigo.

  6. eu estou a criar um banco de dados sobre gestao de clientes e activacao de servicos de uma empresa de telecomunicacao.
    tem as seguintes entidades e atributos:
    1-Cliente(n da identificacao,nome,endereco),
    2-numero[telefonico](id, serie do numero,n da identificacao, serial number ),
    3-telemovel(serial number, marca, sistema, cor),
    4-servicos(nome do servico, descricao)
    eu acho que esta muito simples pelo titulo do trabalho, gostaria que me ajudasse nesse sentido, pfv

  7. olá …. muito boa a explicação……

    sobre os DBAs eu concordo plenamente sobre o que você expôs……. pois são profissionais altamente capacitados em banco de dados…

    vlw …. foi de grande ajuda para meus estudos pra prova de hoje….!!!

  8. Thiago, primeiramente, temos divisões nas áreas de TI nos dias atuais, é como se você tivesse, por exemplo, falando para um médico da área pediátrica realizar um exame que deveria ser feito por um profissional da área oftalmológica, somente pelo fato de pertencerem à área da saúde. Cada um tem seu papel, especialidade e conhecimento para a construção de um sistema seguro e consistente. O desenvolvedor não poder ser totalmente responsável por fazer todas às analises, documentações e elaborações de um sistema, esses conceitos de entidade relacional e conceitual devem ser direcionados também pros analistas de banco de dados (DBA’s) juntamente com os analistas de requisitos, que depois de serem feitos essas analises devesse passar pros analistas de sistemas darem um aval do que possa ser realizado e por último passar pro desenvolvedor verificar se é ou não possível desenvolver com aquelas informações levantadas e exigir um prazo para o desenvolvimento do serviço proposto, esse tipo de trabalho deve ser feito em conjunto pelos profissionais de TI, pois a “união faz a força”, hoje o que vejo são DBA’s se achando o bam bam bam e ficando somente com a responsabilidade de fazerem backups, recuperar o backups e migrarem os dados de um servidor pra outro, não fazem mais analise nenhum, pelo menos nos órgãos públicos só ficam repassando trabalho para os terceirizados ou repassa as responsabilidades deles para os administradores de banco de dados que seria a realização das analises de inconsistência, duplicidade do banco e performance, mas mesmo assim, colocam gente sem competência nenhum para fazer o papel de administrador que e por fim repassam para as mãos dos analistas de sistemas que por sua vez tacam nas costas do desenvolvedores para avaliarem os dados do banco e fazerem levantamentos e proporem soluções para resolver a questão dos dados do banco, ou seja, no final das contas o desenvolvedor é o que faz tudo pra que o sistema funcione, por isso, acho que dar conselhos ou ensinamentos pra desenvolvedores não é a solução, temos que começar com os analistas, pois acho que essa palavra analista já diz tudo, eles analisam o que será feito, se pulam essa etapa, realmente o desenvolvedor não vai ter toda essa gama de conhecimento para desenvolver um sistema sozinho que atenda a todos os requisitos. FAÇAM-ME O FAVOR A TODOS OS PROFISSIONAIS DE TI, COLABOREM, DEIXEM O ORGULHO DE LADO, PAREM DE FICAR REPASSANDO O PROBLEMA OU A RESPONSABILIDADE DE UM PARA O OUTRO E COMECEM A TRABALHAR EM EQUIPE, COMECEM A PROPOR SOLUÇÕES, MELHOR MODELO PARA O TRABALHO EM EQUIPE É O USO DO XP (EXTREME PROGRAMMING).

  9. Perfeita a explicação rapaz… Há muito procurava algo que explicasse bem como funciona os relacionamentos em modelos relacionais e você explicou perfeitamente…

  10. Thiago, muito bom o artigo, adorei, no entanto não consigo entender como é feita essa conversão do modelo conceitual para o lógico. Tenho muita dificuldade em entender BD. Poderia me dar uma força por favor ? fiz uma prova de BD, que no caso eu tinha que converter o modelo conceitual em lógico, até consegui criar as entidades e tals, mas me enrolo na hora de inserir os atributos às entidades. Sei que o relacionamento não preciso inserir no modelo lógico, mas os atributos são essenciais. Segue meu contato, se puder ajudar, Obrigado. Atenciosamente,

  11. Moss, apenas to passando pra agradecer , pois esse material é muito simplificado , e muito didático. Esclareceu muitas duvidas! agradeço

  12. Boa tarde,

    Gostei bastante do seu artigo, muito bem explicado. Uma pena que as imagens não referente as exemplificações não carregam. Seria possível corrigir isso? Ficaria muito mais claro.

leia mais
Este projeto é mantido pelas empresas:
Este projeto é apoiado pelas empresas: