Modelagem conceitual: entidades, atributos e relacionamentos
Modelagem de dados descreve, de forma estruturada, as informações que o sistema precisa armazenar e como elas se conectam. Em sistemas do DETRAN, é comum lidar com cadastros (cidadão, veículo) e eventos/vínculos (infração, atendimento, propriedade, agendamento), exigindo regras rígidas de integridade.
Entidade
Entidade representa um conjunto de objetos do mundo real sobre os quais se deseja guardar dados. Exemplos típicos: Cidadão, Veículo, Infração, Atendimento, Unidade (posto), Agente.
Atributo
Atributo é uma característica da entidade. Exemplos: Cidadão(nome, cpf, data_nascimento), Veículo(placa, renavam, chassi, ano_fabricacao), Infração(data_hora, enquadramento, valor_base).
Relacionamento
Relacionamento liga entidades e expressa um vínculo. Em DETRAN, muitos vínculos são temporais e precisam de histórico (ex.: propriedade de veículo muda ao longo do tempo). Exemplos: Cidadão possui Veículo; Veículo recebe Infração; Cidadão solicita Atendimento.
Cardinalidade e opcionalidade
Cardinalidade define quantas ocorrências de uma entidade podem se associar a outra. Opcionalidade define se a associação é obrigatória ou pode ser nula.
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
- 1:1: raro em cadastros; pode ocorrer em extensões (ex.: Veículo e VeículoComplemento).
- 1:N: comum (um Cidadão pode ter vários Atendimentos; um Veículo pode ter várias Infrações).
- N:N: comum em vínculos (Cidadão e Veículo via Propriedade; Atendimento e Serviço via AtendimentoServico).
Chaves: identificação, unicidade e rastreabilidade
Chave primária (PK)
Identifica unicamente cada registro. Pode ser natural (cpf, renavam) ou substituta (id_cidadao). Em ambientes corporativos, é comum usar PK substituta para estabilidade e manter chaves naturais como UNIQUE.
Chave candidata e chave alternativa
Chaves candidatas são atributos que poderiam identificar unicamente (ex.: cpf). A escolhida vira PK; as demais viram chaves alternativas com restrição de unicidade.
Chave estrangeira (FK)
Implementa relacionamentos no modelo relacional, garantindo integridade referencial (ex.: infracao.id_veiculo referencia veiculo.id_veiculo).
Chave composta
Usada quando a identificação depende de múltiplos atributos, muito comum em tabelas de associação (ex.: atendimento_servico(id_atendimento, id_servico)).
Do conceitual ao lógico: passo a passo prático
A seguir, um roteiro prático para sair de um cenário típico do DETRAN e chegar a um esquema relacional consistente.
Passo 1: levantar entidades e eventos
Separe cadastros (entidades estáveis) de eventos (ocorrências no tempo).
- Cadastros: Cidadão, Veículo, Unidade, Agente, Serviço.
- Eventos/vínculos: Propriedade (histórico), Infração, Atendimento, Pagamento, Agendamento.
Passo 2: definir atributos e domínios
Para cada atributo, defina tipo, obrigatoriedade, formato e domínio. Exemplos:
- cpf: 11 dígitos, obrigatório, único, validação de dígito verificador.
- placa: padrão Mercosul, obrigatório, único (com regra de formato).
- data_hora_infracao: timestamp, obrigatório.
- valor_multa: numérico com escala, não negativo.
Passo 3: identificar relacionamentos e cardinalidades
- Cidadão 1:N Atendimento (um cidadão pode ter vários atendimentos; um atendimento pertence a um cidadão).
- Veículo 1:N Infração (um veículo pode ter várias infrações; uma infração está vinculada a um veículo).
- Cidadão N:N Veículo ao longo do tempo (resolver com entidade associativa Propriedade).
Passo 4: resolver N:N com entidade associativa
Quando houver N:N, crie uma nova entidade/tabela com FKs e atributos do vínculo. Para propriedade de veículo, atributos do vínculo são essenciais: data_inicio, data_fim, tipo_posse, indicador_principal.
Passo 5: mapear para o modelo relacional
Regras gerais de tradução:
- Entidade vira tabela.
- Atributos viram colunas.
- Relacionamento 1:N vira FK no lado N.
- Relacionamento N:N vira tabela associativa com duas FKs (e possivelmente PK composta).
- Atributos multivalorados viram tabela própria (ex.: telefones do cidadão).
Representando cadastros e vínculos do DETRAN
Cidadão
Cadastro central para serviços, atendimentos e vínculos com veículos. Recomenda-se separar dados sensíveis e dados de contato quando houver políticas específicas.
cidadao( id_cidadao PK, cpf UNIQUE NOT NULL, nome NOT NULL, data_nascimento, email, data_cadastro NOT NULL )Veículo
Veículo possui identificadores fortes (renavam, chassi, placa). Em geral, renavam e chassi devem ser únicos; placa pode mudar (troca de placa), então pode exigir histórico dependendo do escopo.
veiculo( id_veiculo PK, renavam UNIQUE NOT NULL, chassi UNIQUE NOT NULL, placa UNIQUE NOT NULL, ano_fabricacao, marca_modelo, uf_registro )Vínculo Cidadão–Veículo (Propriedade com histórico)
Para manter histórico, não basta uma FK direta em veiculo. Use uma tabela de vínculo com período de vigência e regra de não sobreposição.
propriedade_veiculo( id_propriedade PK, id_cidadao FK NOT NULL, id_veiculo FK NOT NULL, data_inicio NOT NULL, data_fim, tipo_posse NOT NULL )Regras típicas:
- data_fim pode ser nula para vínculo vigente.
- Não pode haver dois vínculos vigentes simultâneos para o mesmo veículo (dependendo da regra do órgão).
- Não pode haver sobreposição de períodos para o mesmo veículo e mesmo tipo de posse.
Infração
Infração é um evento associado a veículo (e frequentemente a um agente, local e enquadramento). Evite duplicar dados de enquadramento na infração; use tabela de referência.
enquadramento( id_enquadramento PK, codigo UNIQUE NOT NULL, descricao NOT NULL, valor_base NOT NULL )infracao( id_infracao PK, id_veiculo FK NOT NULL, id_enquadramento FK NOT NULL, data_hora NOT NULL, local_descricao, status NOT NULL )Atendimento
Atendimento representa interação do cidadão com o órgão (presencial, online). Pode envolver múltiplos serviços no mesmo protocolo, então é comum modelar cabeçalho e itens.
atendimento( id_atendimento PK, id_cidadao FK NOT NULL, id_unidade FK, canal NOT NULL, data_abertura NOT NULL, status NOT NULL )servico( id_servico PK, codigo UNIQUE NOT NULL, nome NOT NULL )atendimento_servico( id_atendimento FK NOT NULL, id_servico FK NOT NULL, PRIMARY KEY(id_atendimento, id_servico) )Regras de integridade e constraints
Integridade de entidade
PK não pode ser nula e deve ser única. Em tabelas associativas, PK composta impede duplicidade do vínculo.
Integridade referencial
FK garante que não existam registros órfãos. Decida políticas de deleção/atualização:
- RESTRICT/NO ACTION: impede exclusão de pai com filhos (comum para histórico e auditoria).
- CASCADE: útil em tabelas dependentes puras, mas perigoso para dados legais/históricos.
- SET NULL: quando o vínculo é opcional e faz sentido manter o registro sem referência (ex.: atendimento sem unidade em canal digital, se permitido).
Constraints de domínio (CHECK) e NOT NULL
Use constraints para impedir valores inválidos na origem:
- CHECK(valor_base >= 0)
- CHECK(status IN ('ABERTO','ENCERRADO','CANCELADO'))
- NOT NULL em campos essenciais (cpf, renavam, data_hora).
Unicidade (UNIQUE) e chaves naturais
Mesmo com PK substituta, mantenha unicidade em identificadores oficiais:
- cidadao.cpf UNIQUE
- veiculo.renavam UNIQUE
- enquadramento.codigo UNIQUE
Regras complexas: sobreposição de períodos
Algumas regras não cabem apenas em FK/UNIQUE. Exemplo: impedir sobreposição de propriedade vigente para o mesmo veículo. Soluções comuns:
- Trigger que valida intervalos antes de INSERT/UPDATE.
- Constraint de exclusão por intervalo (quando o SGBD suporta).
- Validação na camada de aplicação com transação e bloqueio adequado, complementada por mecanismos no banco.
Normalização aplicada ao cenário
1FN: atomicidade
Evite colunas com listas (ex.: telefones em um único campo). Modele como tabela:
cidadao_telefone( id_cidadao FK NOT NULL, telefone NOT NULL, tipo, PRIMARY KEY(id_cidadao, telefone) )2FN: dependência total da chave
Em tabelas com PK composta, nenhum atributo não-chave deve depender apenas de parte da PK. Exemplo: em atendimento_servico(id_atendimento, id_servico), não coloque nome_servico (depende só de id_servico).
3FN: sem dependências transitivas
Se veiculo guarda id_marca e marca_nome, há redundância. Mantenha marca em tabela própria e referencie por FK.
Desnormalização controlada
Em consultas operacionais intensas (painéis, relatórios), pode-se criar visões materializadas ou tabelas de apoio para performance, mantendo o dado mestre normalizado e com trilha de auditoria.
Exercícios: DER e tradução para esquema relacional
Exercício 1: DER (conceitual) para atendimento com múltiplos serviços
Enunciado: Um Cidadão pode abrir vários Atendimentos. Cada Atendimento pode incluir um ou mais Serviços. Um Serviço pode aparecer em muitos Atendimentos. Modele entidades, relacionamentos e cardinalidades. Depois traduza para tabelas.
Gabarito esperado (conceitual):
- Entidades: Cidadão, Atendimento, Serviço.
- Relacionamentos: Cidadão 1:N Atendimento; Atendimento N:N Serviço.
Tradução para relacional (uma solução):
cidadao( id_cidadao PK, cpf UNIQUE, nome, ... )atendimento( id_atendimento PK, id_cidadao FK NOT NULL, data_abertura, status, ... )servico( id_servico PK, codigo UNIQUE, nome )atendimento_servico( id_atendimento FK NOT NULL, id_servico FK NOT NULL, PRIMARY KEY(id_atendimento, id_servico) )Exercício 2: DER para infração e enquadramento
Enunciado: Um Veículo pode ter várias Infrações. Cada Infração pertence a um único Veículo. Cada Infração referencia um Enquadramento (tabela de códigos). Um Enquadramento pode ser usado por várias Infrações. Modele e traduza.
Tradução para relacional (uma solução):
veiculo( id_veiculo PK, renavam UNIQUE, placa UNIQUE, ... )enquadramento( id_enquadramento PK, codigo UNIQUE NOT NULL, descricao NOT NULL, valor_base NOT NULL )infracao( id_infracao PK, id_veiculo FK NOT NULL, id_enquadramento FK NOT NULL, data_hora NOT NULL, status NOT NULL )Exercício 3: vínculo de propriedade com histórico e regra de vigência
Enunciado: Um Cidadão pode ser proprietário de vários Veículos ao longo do tempo. Um Veículo pode trocar de proprietário. É necessário histórico com data_inicio e data_fim. Modele o relacionamento e traduza para relacional. Inclua uma regra para impedir dois proprietários vigentes para o mesmo veículo.
Tradução para relacional (uma solução):
propriedade_veiculo( id_propriedade PK, id_cidadao FK NOT NULL, id_veiculo FK NOT NULL, data_inicio NOT NULL, data_fim, tipo_posse NOT NULL )Constraint/regra (exemplo conceitual): para cada id_veiculo, deve existir no máximo um registro com data_fim nula.
-- Exemplo (quando suportado): índice único parcial para vínculo vigente (pseudoexemplo, varia por SGBD) UNIQUE(id_veiculo) WHERE data_fim IS NULLQualidade de dados: consistência, completude e rastreabilidade
Dimensões práticas de qualidade
- Completude: campos essenciais preenchidos (cpf, renavam, datas).
- Consistência: regras respeitadas (status válidos, FKs existentes, formatos corretos).
- Unicidade: evitar duplicidade de cidadão por variações de nome; usar cpf como chave alternativa e rotinas de deduplicação.
- Acurácia: validações (DV de CPF, formato de placa, faixas de valores).
- Atualidade: dados de contato atualizados; histórico preservado para dados legais.
Estratégias no banco e no processo
- Constraints (NOT NULL, UNIQUE, CHECK) como primeira barreira.
- Padronização de domínios (tabelas de referência para status, tipos, códigos).
- Auditoria: colunas como criado_em, criado_por, atualizado_em, atualizado_por.
- Trilha de histórico: tabelas de vigência (data_inicio/data_fim) para vínculos e atributos que mudam.
Dicionário de dados e governança de metadados
Dicionário de dados
Dicionário de dados documenta cada tabela e coluna: significado, tipo, tamanho, obrigatoriedade, regras, origem e exemplos. Em ambientes do DETRAN, isso reduz ambiguidades entre áreas (atendimento, fiscalização, veículos) e melhora integrações.
Campos recomendados no dicionário:
- Nome lógico e nome físico (ex.: Cidadão.cpf vs cidadao.cpf).
- Descrição de negócio.
- Tipo e formato (ex.: CHAR(11)).
- Domínio/valores permitidos.
- Regra de preenchimento (obrigatório, condicional).
- Chaves e relacionamentos (PK/FK/UNIQUE).
- Classificação do dado (pessoal, sensível, público) e política de acesso.
Metadados e governança
Governança de metadados define responsabilidades e processos para manter o modelo confiável:
- Data owner: responsável pelo significado e uso do dado (negócio).
- Data steward: cuida da qualidade, padronização e catálogo.
- Equipe técnica: implementa constraints, versiona modelos e garante performance.
- Catálogo: centraliza definições, linhagem (data lineage) e impactos de mudança.
Versionamento de modelos em ambientes corporativos
O que versionar
- Arquivos do modelo lógico (DER e definições).
- Scripts DDL (CREATE/ALTER), migrações e rollback.
- Dicionário de dados (como artefato versionado).
- Contratos de integração (views, APIs, eventos) que dependem do esquema.
Boas práticas de evolução do esquema
- Evitar mudanças destrutivas sem migração: renomear coluna exige compatibilidade (views, colunas duplicadas temporárias).
- Migrações incrementais: cada alteração com script idempotente quando possível.
- Controle de impacto: mapear quais sistemas/relatórios usam cada tabela/coluna.
- Ambientes: aplicar em desenvolvimento, homologação e produção com o mesmo pipeline e validações.
- Testes de dados: checar constraints, cardinalidades e amostras de integridade após migração.
