Modelo lógico de banco de dados: exemplo relacional

O modelo lógico de banco de dados organiza as informações segundo um modelo de dados escolhido, explicitando relações, atributos, identificadores e restrições. No projeto relacional, ele transforma entidades e relacionamentos do domínio em tabelas relacionadas. A preocupação central é representar corretamente as regras, antes de decidir índices, armazenamento e outros detalhes físicos de um sistema específico.

Este guia usa um cadastro acadêmico hipotético para mostrar a passagem das regras ao esquema. O modelo físico de banco de dados trata da implementação. A introdução a bancos relacionais oferece a base de relações, chaves e integridade usada aqui.

Conceitual, lógico e físico

As fronteiras podem variar entre métodos e ferramentas, mas a distinção de responsabilidades continua útil. O capítulo de modelagem entidade-relacionamento do BCcampus apresenta entidades, atributos e relacionamentos. Converter o desenho em tabelas exige preservar o significado das regras, além de reproduzir os nomes das caixas.

Regras do exemplo acadêmico

A palavra “oferta” evita confundir a disciplina do catálogo com sua realização em um período. Se a matrícula fosse identificada apenas por aluno e disciplina, uma nova tentativa em outro semestre poderia entrar em conflito com a anterior. Modelar exige perceber esse tipo de distinção no domínio.

Um esquema lógico possível

A relação MATRÍCULA resolve o relacionamento muitos para muitos entre aluno e oferta. Sua chave composta impede repetir a mesma combinação. Outra solução poderia usar um identificador próprio, mantendo uma restrição de unicidade sobre aluno e oferta. A escolha precisa preservar a regra, independentemente da aparência do diagrama.

Chaves e restrições de integridade

A chave primária identifica cada ocorrência; a estrangeira liga uma ocorrência a outra relação. Uma matrícula não deve apontar para um aluno inexistente. A documentação de restrições do PostgreSQL mostra como chaves, unicidade, obrigatoriedade e verificações podem ser implementadas. A decisão lógica vem da regra do domínio, não da disponibilidade de um botão na ferramenta.

No exemplo, o nome de aluno não é um identificador seguro, pois pessoas diferentes podem ter o mesmo nome. A ausência de nota também precisa de significado: “não registrada” é diferente de nota zero. Defina a regra antes de escolher um valor padrão. Esse cuidado evita que uma conveniência de implementação altere a interpretação dos dados.

Redundância e dependências

Repetir o nome da disciplina em toda matrícula cria uma dependência desnecessária: mudar o nome exigiria atualizar muitas linhas. Mantê-lo em DISCIPLINA permite uma atualização central. O modelo relacional apresentado pelo BCcampus fornece o vocabulário de relações e atributos para discutir essas decisões.

Normalização não significa dividir tabelas indefinidamente. Ela examina dependências e anomalias para organizar fatos de maneira coerente. Depois, requisitos de desempenho podem motivar escolhas físicas ou redundâncias controladas, mas elas devem ser explícitas e acompanhadas de uma estratégia de consistência.

Como validar o modelo antes do SQL

Esses cenários testam significado e integridade. Depois de validá-los, a implementação em SQL transforma o esquema em definições executáveis. Um modelo lógico útil permite explicar onde cada fato fica armazenado, como se relaciona aos demais e quais estados dos dados são aceitos.