Modelo Entidade-Relacionamento: como planejar um banco de dados

O Modelo Entidade-Relacionamento, frequentemente chamado de MER, é uma representação conceitual dos dados de um sistema. Ele ajuda a descobrir o que precisa ser armazenado, quais características descrevem cada elemento e como esses elementos se relacionam. Seu objetivo é esclarecer as regras do negócio antes da criação das tabelas e dos comandos SQL.

Os componentes do modelo

Entidade

Entidade é algo relevante para o sistema e sobre o qual precisamos guardar informações. Em uma escola, Aluno, Turma e Disciplina podem ser entidades. Em uma loja, podemos ter Cliente, Produto e Pedido.

Uma entidade deve representar um conceito bem definido. “Nome” não costuma ser entidade, pois é uma característica de outra coisa. “Relatório” só deve virar entidade quando o sistema realmente precisa armazená-lo como objeto independente.

Atributo

Atributos descrevem uma entidade. Um aluno pode ter matrícula, nome, data de nascimento e e-mail. Um produto pode ter código, descrição, preço e estoque. Cada atributo deve possuir significado claro e um tipo de dado coerente.

Também precisamos indicar um atributo identificador. A matrícula pode identificar um aluno, enquanto um código interno pode identificar um produto. Nomes geralmente não são bons identificadores porque podem se repetir ou mudar.

Relacionamento

Relacionamento expressa uma associação relevante. Um aluno participa de uma turma; um cliente realiza pedidos; um professor ministra disciplinas. O verbo ajuda a conferir se a ligação faz sentido nos dois sentidos.

Cardinalidade: quantas ocorrências participam?

A cardinalidade depende da regra real, não do desenho preferido. Uma turma pode ter muitos alunos, mas um aluno pertence a apenas uma turma no ano atual? Ou pode participar de várias turmas e cursos? A resposta muda o modelo.

Participação também indica obrigatoriedade. Um pedido deve possuir cliente? Um cliente pode existir antes de realizar qualquer pedido? Essas perguntas distinguem relações obrigatórias e opcionais.

Exemplo: controle acadêmico

Considere estas regras:

• cada aluno possui matrícula única, nome e e-mail;
• cada disciplina possui código único, nome e carga horária;
• um aluno pode cursar várias disciplinas;
• uma disciplina pode receber vários alunos;
• cada matrícula em disciplina registra data, situação e nota final.

Temos as entidades Aluno e Disciplina ligadas por um relacionamento muitos-para-muitos. Como a própria ligação possui dados, ela se torna uma entidade associativa chamada Matrícula. Cada ocorrência de Matrícula conecta exatamente um aluno a uma disciplina.

Esse detalhe evita guardar uma lista de disciplinas dentro da linha do aluno ou repetir os dados do aluno para cada disciplina. O modelo passa a representar corretamente tanto os elementos quanto o histórico acadêmico.

Um roteiro para criar seu MER

1. Leia o problema e destaque os elementos sobre os quais é necessário guardar dados.
2. Transforme conceitos relevantes em entidades.
3. Liste atributos necessários, evitando guardar dados que possam ser calculados com segurança.
4. Escolha um identificador estável para cada entidade.
5. Escreva os relacionamentos como frases com verbos.
6. Defina cardinalidade mínima e máxima conforme as regras.
7. Teste o modelo usando situações reais e casos excepcionais.

Converse com quem conhece o processo. Um diagrama tecnicamente bonito ainda pode estar errado se representar uma regra inventada.

Do modelo conceitual para as tabelas

Na transformação básica, entidades tornam-se tabelas e atributos tornam-se colunas. Em um relacionamento 1:N, a chave do lado “um” normalmente aparece como chave estrangeira no lado “muitos”. Em um relacionamento N:N, criamos uma tabela associativa.

CREATE TABLE alunos (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    matricula VARCHAR(20) UNIQUE NOT NULL,
    nome VARCHAR(120) NOT NULL
);

CREATE TABLE disciplinas (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    codigo VARCHAR(20) UNIQUE NOT NULL,
    nome VARCHAR(120) NOT NULL
);

CREATE TABLE matriculas (
    aluno_id INTEGER REFERENCES alunos(id),
    disciplina_id INTEGER REFERENCES disciplinas(id),
    data_matricula DATE NOT NULL,
    situacao VARCHAR(20) NOT NULL,
    nota_final NUMERIC(4,2),
    PRIMARY KEY (aluno_id, disciplina_id)
);

Esse código é uma possível implementação do modelo, não a única. Regras como permitir que o aluno refaça a mesma disciplina em outro período exigiriam incluir semestre ou um identificador próprio na matrícula.

Erros comuns na modelagem

• começar pelas tabelas sem entender o processo;
• usar nome, telefone ou e-mail mutável como única identificação interna;
• guardar vários valores em uma única coluna;
• criar uma tabela diferente para cada mês, turma ou categoria;
• ignorar relações muitos-para-muitos;
• confundir o diagrama conceitual com detalhes específicos do SGBD;
• não validar o modelo com exemplos reais.

Perguntas frequentes