Na modelagem de dados, o objetivo é representar o domínio do problema de forma precisa e consistente, para que o banco de dados suporte consultas, relatórios e regras de negócio sem ambiguidades. Em concursos, é comum cobrar a passagem do modelo Entidade-Relacionamento (conceitual) para o modelo relacional (lógico), além de chaves, cardinalidades e integridade.
1) Modelagem conceitual (ER): elementos fundamentais
Entidades
Entidade é um “tipo de objeto” do mundo real sobre o qual se deseja armazenar dados. No domínio judicial, exemplos típicos são: Processo, Unidade (vara, gabinete, secretaria), Movimentação, Intimação, Servidor, Lotação.
- Entidade forte: existe independentemente (ex.: Processo).
- Entidade fraca: depende de outra para existir/ser identificada (ex.: ItemMovimentacao se for identificado apenas por (Processo, Sequência)).
Atributos
Atributos descrevem propriedades de uma entidade/relacionamento.
- Simples: atômico (ex.: numeroProcesso).
- Composto: pode ser decomposto (ex.: endereço em logradouro, número, bairro).
- Multivalorado: múltiplos valores (ex.: telefones). No relacional, costuma virar tabela própria.
- Derivado: calculado (ex.: prazoRestante). Geralmente não se armazena, calcula-se.
Exemplo de atributos de Processo: idProcesso, numeroCNJ, classe, assunto, dataDistribuicao, segredoJustica (S/N), status.
Relacionamentos
Relacionamento liga entidades e representa uma associação do domínio.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Processo “tramita em” Unidade.
- Processo “possui” Movimentação.
- Intimação “refere-se a” Processo e “destina-se a” uma parte/advogado (se modelado).
- Servidor “está lotado em” Unidade (via entidade associativa Lotação).
Cardinalidade e participação
Cardinalidade define quantas ocorrências de uma entidade podem se associar a outra.
- 1:1: raro no domínio, mas pode ocorrer (ex.: Processo ↔ Distribuição, se houver exatamente uma distribuição por processo).
- 1:N: muito comum (ex.: Processo 1:N Movimentação).
- N:N: comum e exige tabela associativa no relacional (ex.: Servidor N:N Unidade ao longo do tempo, via Lotação).
Participação (obrigatória/opcional) indica se a entidade precisa participar do relacionamento.
- Ex.: toda Movimentação deve estar associada a um Processo (participação obrigatória de Movimentação).
- Um Processo pode existir sem movimentações no instante inicial (participação opcional de Processo no relacionamento “possui”).
Chaves no modelo conceitual
No ER, define-se um identificador (chave) para distinguir univocamente cada ocorrência.
- Chave natural: existe no domínio (ex.: numeroCNJ pode ser candidato, mas cuidado com formatação/validação e possíveis exceções).
- Chave substituta (surrogate): id numérico/UUID (ex.: idProcesso). Muito usada para simplificar FKs.
- Chave composta: combinação de atributos (ex.: (idProcesso, sequenciaMov) para Movimentação).
2) Integridade: regras que o modelo deve garantir
Integridade de entidade
Chave primária (PK) não pode ser nula e deve ser única. No domínio judicial, isso evita duplicidade de processos, unidades, movimentações etc.
Integridade referencial
Chave estrangeira (FK) deve referenciar uma PK existente (ou ser nula, se permitido). Ex.: toda movimentação deve apontar para um processo válido.
Integridade de domínio e restrições
Restrições típicas:
- NOT NULL para campos obrigatórios (ex.: dataDistribuicao).
- UNIQUE para evitar duplicidade (ex.: numeroCNJ).
- CHECK para valores controlados (ex.: segredoJustica IN ('S','N')).
- Regras temporais: em Lotação, dataFim deve ser maior que dataInicio (CHECK) e pode haver regra de “não sobreposição” (geralmente via trigger/constraint avançada).
3) Do ER para o relacional: regras de transformação
A transformação ER → Relacional é um roteiro muito cobrado. A seguir, um passo a passo prático com regras gerais.
Passo 1: cada entidade vira uma tabela
Para cada entidade forte, crie uma tabela com seus atributos atômicos e defina a PK.
PROCESSO(id_processo PK, numero_cnj UNIQUE, classe, assunto, data_distribuicao, segredo_justica, status)UNIDADE(id_unidade PK, nome, sigla, tipo)Passo 2: atributos multivalorados viram tabela própria
Se uma entidade possui um atributo multivalorado, crie uma tabela para ele, com FK para a entidade “dona”.
Exemplo (hipotético): se UNIDADE tiver vários telefones:
UNIDADE_TELEFONE(id_unidade FK, telefone, PK(id_unidade, telefone))Passo 3: relacionamento 1:N vira FK no lado N
Se um Processo possui várias Movimentações (1:N), a FK fica em MOVIMENTACAO apontando para PROCESSO.
MOVIMENTACAO(id_mov PK, id_processo FK NOT NULL, data_hora, tipo, descricao)Se a regra exigir ordenação por sequência dentro do processo, pode-se usar chave composta ou restrição UNIQUE:
MOVIMENTACAO(id_mov PK, id_processo FK NOT NULL, sequencia NOT NULL, data_hora, tipo, descricao, UNIQUE(id_processo, sequencia))Passo 4: relacionamento 1:1 vira FK com UNIQUE (ou fusão de tabelas)
Em 1:1, você pode:
- Colocar FK em uma das tabelas e marcar como UNIQUE.
- Fundir as tabelas (se fizer sentido e não houver muitos nulos).
Exemplo: se cada Processo tiver exatamente um registro de Distribuição:
DISTRIBUICAO(id_processo PK/FK, data_distribuicao, criterio)Passo 5: relacionamento N:N vira tabela associativa
Relacionamentos N:N exigem uma tabela de junção com FKs para as duas entidades. Se o relacionamento tiver atributos (ex.: período), eles ficam nessa tabela.
Exemplo: Servidor lotado em Unidade ao longo do tempo (N:N com atributos):
SERVIDOR(id_servidor PK, nome, matricula UNIQUE)LOTACAO(id_servidor FK, id_unidade FK, data_inicio, data_fim, PK(id_servidor, id_unidade, data_inicio))Observação: a PK inclui data_inicio para permitir múltiplas lotações do mesmo servidor na mesma unidade em períodos diferentes. Alternativamente, use id_lotacao como PK e imponha UNIQUE conforme a regra.
Passo 6: entidade fraca vira tabela com PK composta (inclui a PK da forte)
Se MOVIMENTACAO for identificada por (Processo, Sequência), ela pode ser modelada como fraca:
MOVIMENTACAO(id_processo FK, sequencia, data_hora, tipo, descricao, PK(id_processo, sequencia))Passo 7: especialização/generalização (se aparecer)
Se houver supertipo/subtipo (ex.: USUARIO como supertipo e SERVIDOR/ADVOGADO como subtipos), há estratégias:
- Tabela por hierarquia: uma tabela com coluna “tipo” (pode gerar muitos nulos).
- Tabela por tipo: supertipo + tabelas de subtipos com PK=FK.
- Tabela por classe concreta: uma tabela para cada subtipo (replica atributos comuns).
Em provas, a estratégia “supertipo + subtipos com PK=FK” é frequente por manter integridade e reduzir nulos.
4) Exemplo completo (ER conceitual → relacional lógico)
Descrição conceitual (texto do ER)
- Entidades: PROCESSO, UNIDADE, MOVIMENTACAO, INTIMACAO.
- Relacionamentos: PROCESSO 1:N MOVIMENTACAO; PROCESSO N:1 UNIDADE (processo tramita em uma unidade atual); PROCESSO 1:N INTIMACAO.
- Regras: toda MOVIMENTACAO pertence a um PROCESSO; toda INTIMACAO pertence a um PROCESSO; PROCESSO pode existir sem MOVIMENTACAO; UNIDADE pode ter zero ou muitos PROCESSOS.
Modelo relacional resultante (tabelas e restrições)
UNIDADE( id_unidade PK, nome NOT NULL, sigla UNIQUE, tipo NOT NULL )PROCESSO( id_processo PK, numero_cnj UNIQUE NOT NULL, classe NOT NULL, assunto, data_distribuicao NOT NULL, segredo_justica NOT NULL CHECK (segredo_justica IN ('S','N')), status NOT NULL, id_unidade_atual FK NOT NULL REFERENCES UNIDADE(id_unidade) )MOVIMENTACAO( id_mov PK, id_processo FK NOT NULL REFERENCES PROCESSO(id_processo), data_hora NOT NULL, tipo NOT NULL, descricao, sequencia NOT NULL, UNIQUE(id_processo, sequencia) )INTIMACAO( id_intimacao PK, id_processo FK NOT NULL REFERENCES PROCESSO(id_processo), data_envio NOT NULL, meio NOT NULL, status NOT NULL, prazo_dias INT CHECK (prazo_dias >= 0) )Note como as cardinalidades 1:N viraram FKs no lado N (MOVIMENTACAO e INTIMACAO). O relacionamento “processo tramita em unidade” foi representado por uma FK em PROCESSO (id_unidade_atual). Se fosse necessário histórico de tramitação por unidade, isso mudaria para uma tabela de histórico (N:N ao longo do tempo) com datas.
5) Exercícios (ER → relacional) com gabarito comentado
Exercício 1: Processo e Partes (N:N)
Enunciado (ER em texto): Um Processo envolve uma ou mais Partes. Uma Parte pode participar de vários Processos. No relacionamento, existe o atributo “papel” (AUTOR, RÉU, TERCEIRO) e “data_entrada”.
Pede-se: transformar para o modelo relacional com PKs, FKs e restrições básicas.
Gabarito (uma solução possível):
PARTE( id_parte PK, nome NOT NULL, documento UNIQUE )PROCESSO( id_processo PK, numero_cnj UNIQUE NOT NULL, ... )PROCESSO_PARTE( id_processo FK NOT NULL REFERENCES PROCESSO(id_processo), id_parte FK NOT NULL REFERENCES PARTE(id_parte), papel NOT NULL CHECK (papel IN ('AUTOR','REU','TERCEIRO')), data_entrada NOT NULL, PK(id_processo, id_parte, papel) )Comentário: como uma mesma parte pode ter mais de um papel no mesmo processo (situação possível em alguns cenários), incluir “papel” na PK evita colisões. Se a regra do domínio proibir múltiplos papéis, a PK poderia ser (id_processo, id_parte) e “papel” seria atributo comum.
Exercício 2: Lotação com período (N:N com atributos temporais)
Enunciado: Servidor pode ser lotado em várias Unidades ao longo do tempo. Cada lotação tem data_inicio e data_fim (opcional, nula quando vigente). Não pode haver duas lotações vigentes simultâneas do mesmo servidor.
Pede-se: modelo relacional e uma restrição para “data_fim > data_inicio”.
Gabarito:
SERVIDOR( id_servidor PK, matricula UNIQUE NOT NULL, nome NOT NULL )UNIDADE( id_unidade PK, nome NOT NULL, ... )LOTACAO( id_lotacao PK, id_servidor FK NOT NULL REFERENCES SERVIDOR(id_servidor), id_unidade FK NOT NULL REFERENCES UNIDADE(id_unidade), data_inicio NOT NULL, data_fim, CHECK (data_fim IS NULL OR data_fim > data_inicio) )Comentário: a regra “não pode haver duas lotações vigentes simultâneas do mesmo servidor” normalmente exige lógica adicional (índices parciais, exclusão por intervalo, trigger), pois não é garantida apenas com PK/FK/CHECK simples.
Exercício 3: Movimentação como entidade fraca
Enunciado: Movimentação é identificada pela combinação (Processo, sequencia). Cada Movimentação tem data_hora e descricao. Um Processo pode ter zero ou muitas Movimentações.
Gabarito:
PROCESSO( id_processo PK, numero_cnj UNIQUE NOT NULL, ... )MOVIMENTACAO( id_processo FK NOT NULL REFERENCES PROCESSO(id_processo), sequencia NOT NULL, data_hora NOT NULL, descricao, PK(id_processo, sequencia) )Comentário: aqui não há necessidade de id_mov substituto, pois a identificação natural do domínio já é composta.
6) Anomalias de modelagem (o que a prova costuma explorar)
Anomalias são problemas típicos de um modelo relacional mal estruturado (frequentemente por mistura de entidades/relacionamentos em uma tabela só), levando a inconsistências.
Anomalia de inserção
Ocorre quando não é possível inserir um fato sem inserir outro indevido.
Exemplo ruim: uma tabela única PROCESSO_UNIDADE com colunas (numero_cnj, classe, unidade_nome, unidade_sigla). Se ainda não houver processo, você não consegue cadastrar uma unidade sem “inventar” um processo.
Correção: separar UNIDADE e PROCESSO, relacionando por FK.
Anomalia de atualização
Ocorre quando o mesmo dado é repetido em várias linhas e precisa ser atualizado em vários lugares.
Exemplo ruim: armazenar nome e sigla da unidade em cada linha de PROCESSO. Se a sigla mudar, é preciso atualizar todos os processos daquela unidade.
Correção: PROCESSO guarda apenas id_unidade_atual (FK). O nome/sigla ficam em UNIDADE.
Anomalia de exclusão
Ocorre quando ao excluir um registro você perde informação que deveria permanecer.
Exemplo ruim: se MOVIMENTACAO guardar também dados do PROCESSO (classe, assunto) e você apagar a última movimentação, pode perder os dados do processo.
Correção: PROCESSO e MOVIMENTACAO em tabelas separadas, com FK.
Exercício 4: identificar anomalias e corrigir
Enunciado: Considere a tabela abaixo:
REGISTRO( numero_cnj, classe, assunto, unidade_sigla, unidade_nome, mov_data_hora, mov_tipo, mov_descricao )Há uma linha por movimentação. Identifique pelo menos 2 anomalias e proponha um modelo corrigido (tabelas).
Gabarito (exemplo de resposta):
- Anomalia de atualização: unidade_nome e unidade_sigla repetem a cada movimentação; mudança de nome exige atualizar várias linhas.
- Anomalia de exclusão: ao excluir a última movimentação, perde-se o cadastro do processo/unidade.
- Anomalia de inserção: não dá para cadastrar um processo sem movimentação (se a tabela exige mov_* preenchido).
Modelo corrigido:
UNIDADE( id_unidade PK, sigla UNIQUE, nome, ... )PROCESSO( id_processo PK, numero_cnj UNIQUE, classe, assunto, id_unidade_atual FK )MOVIMENTACAO( id_mov PK, id_processo FK, data_hora, tipo, descricao )
