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!