Modelagem de dados: entidades, relacionamentos e cardinalidade

1. Introdução à Modelagem de Dados Relacional

A modelagem de dados é o processo de definir a estrutura lógica de um banco de dados, representando como os dados serão organizados, armazenados e relacionados. Trata-se de uma etapa fundamental no ciclo de vida de qualquer sistema de banco de dados, pois define as bases para a integridade, consistência e desempenho das consultas.

Existem três níveis de abstração na modelagem:

  • Modelo conceitual: representa as entidades e relacionamentos do mundo real, independente de tecnologia (ex: Diagrama Entidade-Relacionamento - DER)
  • Modelo lógico: adapta o modelo conceitual para um modelo de dados específico (ex: relacional), definindo tabelas, colunas e chaves
  • Modelo físico: implementa o modelo lógico em um SGBD específico, com tipos de dados, índices e configurações de armazenamento

Uma boa modelagem evita redundâncias, anomalias de atualização e garante que as regras de negócio sejam respeitadas.

2. Entidades: Conceito e Representação

Entidade é um objeto ou conceito do mundo real que pode ser identificado de forma única. No modelo relacional, entidades são representadas como tabelas.

Entidade forte vs. entidade fraca:

  • Entidade forte: existe independentemente. Exemplo: Cliente
  • Entidade fraca: depende de outra entidade para existir. Exemplo: ItemPedido depende de Pedido

Atributos:

  • Simples: valor atômico (ex: nome, cpf)
  • Composto: pode ser dividido em subpartes (ex: endereco → rua, numero, cidade)
  • Multivalorado: pode ter múltiplos valores (ex: telefones de um cliente)
  • Derivado: calculado a partir de outros atributos (ex: idade a partir de data_nascimento)

Identificadores únicos: chave primária (PK) que identifica cada instância da entidade.

-- Exemplo de entidade forte com atributos
CREATE TABLE Cliente (
    id_cliente INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    cpf VARCHAR(11) UNIQUE NOT NULL,
    data_nascimento DATE,
    idade INTEGER GENERATED ALWAYS AS (DATE_PART('year', AGE(data_nascimento))) STORED
);

3. Relacionamentos entre Entidades

Relacionamentos representam associações entre entidades. Podem ser:

  • Binários: entre duas entidades (ex: Cliente faz Pedido)
  • Ternários: entre três entidades (ex: Professor leciona Disciplina em Turma)
  • Recursivos: uma entidade se relaciona consigo mesma (ex: Funcionario gerencia Funcionario)

Papéis e nomes: cada entidade em um relacionamento pode desempenhar um papel específico.

Dependência existencial: quando uma entidade só existe se outra existir (relacionamento obrigatório vs. opcional).

-- Exemplo de relacionamento entre entidades (Cliente e Pedido)
CREATE TABLE Pedido (
    id_pedido INTEGER PRIMARY KEY,
    data_pedido DATE NOT NULL,
    id_cliente INTEGER NOT NULL,
    FOREIGN KEY (id_cliente) REFERENCES Cliente(id_cliente)
);

4. Cardinalidade: Definição e Tipos

Cardinalidade define quantas instâncias de uma entidade podem estar associadas a instâncias de outra. Representa-se como par (mínima, máxima):

  • (0,1): opcional, no máximo uma
  • (1,1): obrigatório, exatamente uma
  • (0,N): opcional, muitas
  • (1,N): obrigatório, pelo menos uma, podendo ser muitas

Relacionamento 1:1 (um-para-um): cada instância de A se relaciona com no máximo uma instância de B.

CREATE TABLE Usuario (
    id_usuario INTEGER PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL
);

CREATE TABLE Perfil (
    id_perfil INTEGER PRIMARY KEY,
    biografia TEXT,
    id_usuario INTEGER UNIQUE,
    FOREIGN KEY (id_usuario) REFERENCES Usuario(id_usuario)
);

Relacionamento 1:N (um-para-muitos): o caso mais comum. Uma instância de A se relaciona com várias de B.

CREATE TABLE Departamento (
    id_depto INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL
);

CREATE TABLE Funcionario (
    id_func INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    id_depto INTEGER NOT NULL,
    FOREIGN KEY (id_depto) REFERENCES Departamento(id_depto)
);

5. Relacionamentos Muitos-para-Muitos (N:N)

Quando várias instâncias de A se relacionam com várias de B, é necessário criar uma tabela associativa (tabela de junção).

Exemplo prático: alunos e disciplinas.

CREATE TABLE Aluno (
    id_aluno INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL
);

CREATE TABLE Disciplina (
    id_disciplina INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL
);

-- Tabela associativa com chave composta
CREATE TABLE Matricula (
    id_aluno INTEGER NOT NULL,
    id_disciplina INTEGER NOT NULL,
    data_matricula DATE NOT NULL,
    PRIMARY KEY (id_aluno, id_disciplina),
    FOREIGN KEY (id_aluno) REFERENCES Aluno(id_aluno),
    FOREIGN KEY (id_disciplina) REFERENCES Disciplina(id_disciplina)
);

Alternativamente, pode-se usar uma chave substituta (surrogate key) como id_matricula como PK, mantendo as FKs.

6. Mapeamento do Modelo Lógico para SQL (DDL)

A tradução do modelo lógico para SQL segue regras claras:

  • Entidade → CREATE TABLE
  • Atributos → colunas com tipos de dados
  • Chave primária → PRIMARY KEY
  • Chave estrangeira → FOREIGN KEY
  • Relacionamentos → FKs com constraints

Regras de integridade referencial com ON DELETE:

  • CASCADE: deleta registros dependentes automaticamente
  • RESTRICT: impede a deleção se houver dependentes
  • SET NULL: define a FK como NULL ao deletar o registro pai
CREATE TABLE Pedido (
    id_pedido INTEGER PRIMARY KEY,
    data_pedido DATE NOT NULL,
    id_cliente INTEGER NOT NULL,
    FOREIGN KEY (id_cliente) 
        REFERENCES Cliente(id_cliente)
        ON DELETE RESTRICT
);

CREATE TABLE ItemPedido (
    id_item INTEGER PRIMARY KEY,
    id_pedido INTEGER NOT NULL,
    produto VARCHAR(100) NOT NULL,
    quantidade INTEGER NOT NULL,
    FOREIGN KEY (id_pedido) 
        REFERENCES Pedido(id_pedido)
        ON DELETE CASCADE
);

7. Boas Práticas e Armadilhas Comuns

Evitar redundância: dados repetidos geram anomalias de atualização, inserção e exclusão. A normalização (1FN, 2FN, 3FN) ajuda a minimizar esses problemas.

Cuidados com relacionamentos cíclicos: loops entre tabelas podem causar problemas de integridade e dificultar consultas. Avalie se o ciclo é realmente necessário.

Auto-relacionamentos: use com cautela e sempre defina claramente os papéis.

-- Exemplo de auto-relacionamento (recursivo)
CREATE TABLE Funcionario (
    id_func INTEGER PRIMARY KEY,
    nome VARCHAR(100) NOT NULL,
    id_gerente INTEGER,
    FOREIGN KEY (id_gerente) REFERENCES Funcionario(id_func)
);

Documentação e revisão: antes de implementar, documente o modelo com DERs e revise com a equipe. Verifique se todas as regras de negócio estão contempladas.

Armadilhas comuns:

  • Esquecer de definir chaves estrangeiras
  • Usar tipos de dados inadequados
  • Não considerar a cardinalidade mínima (NOT NULL vs NULL)
  • Criar tabelas associativas sem chave primária adequada

Conclusão

A modelagem de dados é a base de qualquer banco de dados relacional bem-sucedido. Compreender entidades, relacionamentos e cardinalidade permite criar estruturas eficientes, íntegras e de fácil manutenção. Investir tempo na modelagem conceitual e lógica antes da implementação física reduz retrabalho e garante que o sistema atenda aos requisitos de negócio.

Referências