Modelo Conceitual VS Modelo Lógico

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. Conseqüentemente, 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 são comuns para todos os tipos de veículos, mas que temos diferenças
significativas de um tipo para o outro.

Se fizéssemos somente três 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.