Administração de Banco de Dados (PARTE X)

Do diagrama Entidade-Relacionamento (DER) às tabelas: entendendo o modelo lógico relacional

Se você já passou horas desenhando entidades, atributos e relacionamentos em um Diagrama Entidade-Relacionamento (DER), parabéns: você sobreviveu à modelagem conceitual.

Mas existe um detalhe técnico implacável:

*Os Sistemas gerenciadores de banco de dados (SGBDs) não entendem desenhos, nem cardinalidades nem muito menos sabem o que é uma entidade forte, fraca ou abstrata.*

O SGBD entende:

• tabelas;
• colunas;
• chaves;
• restrições;
• referências.

E é justamente aqui que entra a modelagem lógica de banco de dados. É nessa etapa que o modelo conceitual deixa de ser apenas uma representação abstrata e começa a se transformar em algo implementável no mundo real.

Muita gente aprende essa parte decorando definições formais sem realmente entender o que está acontecendo por trás da estrutura relacional. O resultado normalmente é o clássico cenário:

“Eu sei desenhar um DER… mas não sei transformar isso em um banco relacional de verdade.”

Neste artigo vamos desmontar essa transformação passo a passo, entendo na prática:

• como entidades viram tabelas;
• como relacionamentos viram chaves estrangeiras;
• como identificar PK, FK e campos únicos;
• como funcionam as restrições;
• por que tudo isso prepara o terreno para a normalização de dados;
• e por que o modelo relacional continua dominando sistemas reais até hoje.

O grande mapa: da ideia até a implementação

O desenvolvimento de um banco de dados normalmente passa por três etapas principais:

Figura 1 — Etapas evolutivas de um projeto de banco de dados.

O modelo conceitual funciona como a planta de uma casa.

Ele mostra:

• quais elementos existem;
• como eles se relacionam;
• quais regras fazem parte do negócio.

Mas ele ainda não define:

• tabelas reais;
• tipos de dados;
• SQL;
• restrições;
• implementação física.

O Projeto Lógico é justamente a ponte entre:

• o mundo abstrato do DER;
• e o mundo concreto do banco relacional.

O modelo relacional: a base dos bancos modernos

O modelo relacional proposto por Edgar F. Codd em 1970, rege 90% dos sistemas corporativos até hoje.

Mesmo depois de décadas, ele continua sendo a base da maior parte dos Sistemas Gerenciadores de Banco de Dados modernos:

• PostgreSQL;
• MySQL;
• SQL Server;
• Oracle;
• MariaDB.

A ideia central do modelo relacional é extremamente simples:

Organizar os dados em tabelas relacionadas entre si.

E justamente por ser simples, ele se tornou extremamente poderoso.

Traduzindo os “termos acadêmicos” para o mundo real

Na literatura acadêmica, os termos utilizados são extremamente matemáticos, mas no dia a dia da engenharia de software, nós usamos versões mais diretas, como descrito a seguir:

Figura 2 — Comparativa das terminologias utilizadas no âmbito de desenvolvimento de banco de dados.

💡 Importante! Entender os termos formais ajuda bastante ao estudar modelagem e documentação técnica.

O passo a passo da transformação do modelo conceitual para modelo lógico

Antes de transformar um DER em tabelas reais, precisamos entender alguns símbolos fundamentais do modelo relacional, já que a mágica da modelagem lógica acontece através de um conjunto de regras de mapeamento. Nós não pulamos do desenho direto para o código SQL; nós usamos uma Simbologia de Notação Lógica para validar a arquitetura primeiro.

💡Importante! Esses elementos aparecem praticamente em qualquer banco de dados.

Aprendendo a ler um modelo lógico

Antes de transformar um DER em tabelas reais, é necessário entender alguns símbolos fundamentais do modelo relacional, usados no dia a dia como convenção utilizada para criar projetos de banco de dados, as quais serão descritas a seguir.

1. Chave primária (Primary Key)

A chave primária identifica cada registro de forma única dentro de uma tabela.

Exemplo:

Figura 3 — Representação gráfica da chave primária (PK) em uma entidade (tabela) de banco de dados.

💡 **A sigla PK significa Primary Key**.

Na prática, a chave primária:

• não pode se repetir;
• não pode ser NULL;
• identifica exclusivamente cada linha.

Assim, se duas pessoas tiverem o mesmo nome, ainda assim o id_empregado continuará sendo único.

Sem chave primária:

• registros podem se duplicar;
• relacionamentos quebram;
• o banco de dados perde consistência.

2. Chave estrangeira (Foreign Key)

A chave estrangeira (FK) é o mecanismo que permite criar relações entre tabelas no modelo relacional.

Ela funciona como uma referência para a chave primária de outra tabela, garantindo que os relacionamentos permaneçam válidos e consistentes.

Exemplo:

Figura 4 — Representação gráfica da chave estrangeira (FK) em uma entidade (tabela) de banco de dados.

💡 *A sigla FK significa Foreign Key.*

Neste caso, indica que cada Pedido está associado a um e somente um Cliente e que cada Cliente pode realizar muitos Pedidos.

O banco passa a entender algo como:

*“Este valor precisa existir na tabela Cliente.”*

É assim que os relacionamentos do DER passam a existir no modelo relacional.

3. Chave primária composta

Em alguns casos, uma única coluna não consegue identificar um registro sozinha.

É aqui que entra o uso da chave composta, que consiste em uma chave primária formada por dois ou mais atributos que, juntos, identificam unicamente um registro em uma entidade.

Exemplo:

Figura 5 — Representação gráfica da chave composta em entidades (tabelas) de banco de dados.

Na entidade Itens_Pedido, um pedido pode ter vários produtos, e um produto pode aparecer em vários pedidos. Assim, precisamos da combinação (id_pedido, id_produto) para identificar cada item de forma única.

A seguir, é mostrado como seriam representadas as chaves compostas na estrutura de tabelas do banco de dados.

Figura 6— Representação gráfica do uso de chave composta em tabelas de banco de dados.

Nesse cenário:

• codigo_pedido sozinho não identifica o registro;
• codigo_produto sozinho também não identifica o registro;
• mas a combinação dos dois é única.

💡 Quando usar? Quando nenhum atributo individual identifica de forma única a entidade ou quando a unicidade só é garantida pela combinação de dois ou mais campos.

4. Chave alternativa ou única (U — UQ — Unique)

O campo U ou UQ ou UNIQUE é uma restrição usada para garantir que um valor não seja repetido dentro de uma tabela no banco de dados.

Muita gente confunde UNIQUE com chave primária (PRIMARY KEY), mas eles têm propósitos diferentes, dentre os quais, pode-se mencionar.

• A PRIMARY KEY identifica unicamente cada registro da tabela e representa o identificador principal da entidade.
• Já um campo UNIQUE apenas garante exclusividade dos valores, sem necessariamente ser o identificador principal.

Uma tabela pode possuir:

• apenas uma PRIMARY KEY;
• vários campos UNIQUE.

Exemplo:

Figura 7— Representação gráfica do uso de campo único em uma tabela de banco de dados.

Nesse caso:

• dois usuários não podem ter o mesmo cpf;
• mas o cpf não necessariamente é a PK da tabela.

💡 Importante! Campos únicos são muito utilizados para armazenar: — CPF; — e-mail; — matrícula.

Como transformar um DER em modelo relacional

Agora começa uma das etapas mais importantes da modelagem, pois é nesse momento que o desenho conceitual passa a se transformar em uma estrutura real de banco de dados.

Existem diferentes abordagens propostas por autores e materiais acadêmicos para realizar essa conversão. Por isso, a seguir será apresentada uma síntese prática dos principais passos utilizados para transformar um DER em um modelo relacional.

1. Entidade vira tabela e atributo(s) viram coluna(s)

Nesta etapa, cada entidade representada no DER é convertida em uma tabela no modelo relacional. Da mesma forma, os atributos da entidade passam a se tornar colunas dessa tabela, indicando o tipo de dado que pretende armazenar.

Em outras palavras:

• entidade → tabela;
• atributo → coluna.

A seguir, é apresentado um exemplo gráfico dessa transformação.

Figura 8 — Exemplo de comparação de uma entidade no nível conceitual e lógico de banco de dados.

Perceba a transformação:

• a entidade VIROU tabela;
• os atributos VIRARAM colunas;
• o identificador VIROU chave primária.

Nesta etapa, o modelo começa a se tornar implementável em um SGBD.

2. Definição de domínio (tipo de dados) dos atributos

Uma das definições mais mal compreendidas em banco de dados é o conceito de domínio dos atributos.

Muitas pessoas associam domínio apenas ao tipo de dado da coluna, como VARCHAR, INT ou DATE. Porém, o conceito vai além disso, já que o domínio define:

• Quais valores são válidos para aquele atributo? — exemplo: uma coluna “idade” não pode aceitar o texto “vinte e cinco” ou combinações desse texto, nem pode ter valor negativo;
• Quais regras a coluna deve respeitar? — exemplo: uma coluna “status” pode ser limitada a aceitar apenas ‘ATIVO’ ou ‘INATIVO’;
• Qual é o significado lógico daquele dado dentro do sistema?.

Ou seja, o domínio não descreve apenas “como” o dado será armazenado, mas também “quais valores fazem sentido” e “as regras válidas” para aquele atributo.

3. Definição de integridade de entidade

A integridade de entidade é a regra que garante que todo registro de uma tabela possa ser identificado de forma única.

Para isso, cada tabela deve possuir uma chave primária (Primary Key ou PK), responsável por atuar como identificador principal da entidade. Essa chave impede registros duplicados e permite localizar cada linha individualmente dentro da tabela.

Uma das principais regras da integridade de entidade é que a chave primária nunca pode possuir valor NULL. Em outras palavras: se um registro não possui identificação, ele não pode existir no modelo relacional.

4. Definição de integridade referencial

A integridade referencial é a regra responsável por garantir a consistência dos relacionamentos entre tabelas.

Ela impede a existência de registros órfãos, ou seja, registros que fazem referência a dados inexistentes em outra tabela.

Na prática, isso significa que uma chave estrangeira (FK) deve sempre apontar para um registro válido. Por exemplo: se um empregado pertence ao Departamento RH, então esse departamento obrigatoriamente precisa existir na tabela Departamento.

Em outras palavras, o banco de dados não permite criar relacionamentos apontando para registros inexistentes.

5. Relacionamentos 1:N viram chave estrangeira

Nos relacionamentos do tipo (1, n) (um para muitos), a chave primária (PK) da tabela do lado 1 é adicionada como chave estrangeira (FK) na tabela do lado n.

Isso acontece porque vários registros da tabela “muitos” podem estar associados a um único registro da tabela “um”.

Por exemplo: um departamento pode possuir vários empregados, mas cada Empregado pertence a apenas um Departamento. Nesse caso, a chave primária da tabela Departamento (lado 1) é inserida na tabela Empregado (lado n ou muitos) como chave estrangeira.

6. Relacionamentos N:N viram tabela associativa

Relacionamentos do tipo (n, n) (muitos para muitos) não podem ser representados diretamente no modelo relacional. Por isso, eles precisam ser transformados em uma tabela associativa.

Essa nova tabela é criada para armazenar o relacionamento entre as duas entidades, contendo normalmente as chaves primárias (PK) das tabelas envolvidas como chaves estrangeiras (FK).

Por exemplo: um aluno pode cursar várias disciplinas, e uma disciplina pode possuir vários alunos. Nesse caso, cria-se uma tabela intermediária, como Disciplina_Aluno, responsável por registrar essas associações.

Próximos passos: suas tabelas estão realmente boas?

Quando você entende a progressão de Entidades para Tabelas, e de Relacionamentos para Chaves Estrangeiras (FKs), você deixa de apenas “salvar dados” e começa a projetar sistemas escaláveis.

Você agora tem um Modelo Lógico pronto. Mas surge uma nova dúvida letal:

“Como eu sei se as tabelas que eu criei não vão gerar dados duplicados, anomalias e problemas de performance no futuro?”

Não basta apenas criar as tabelas; elas precisam estar otimizadas e livres de redundâncias. E é exatamente para resolver isso que entra o nosso próximo grande assunto: a temida (mas essencial) Normalização de Dados.

Se esse conteúdo te ajudou de alguma forma, deixe suas palmas, deixe seus comentários e compartilhe com alguém que também está aprendendo banco de dados.

Para continuar lendo a matéria, ***clique neste link***.

Nos vemos na próxima parte!

Referências bibliográficas consultadas

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4. ed. Porto Alegre: Sagra Luzzatto, 2004. ALVES, William Pereira. Banco de Dados — Teoria e Desenvolvimento. São Paulo: Editora Érica, 2009. DATE, C. J. Introdução aos Sistemas de Banco de Dados. 8. ed. Rio de Janeiro: Campus, 2004. ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. São Paulo: Pearson/Addison Wesley, 2011. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. São Paulo: Elsevier, 2012.