Atributos e domínios na Modelagem de Dados: definição, obrigatoriedade e qualidade

O que é um atributo e por que ele importa

Atributo é uma característica que descreve uma entidade (ou, em alguns casos, um relacionamento). Em termos práticos, é o “campo” que você precisa armazenar para representar um fato do negócio. Um atributo bem definido evita ambiguidades, reduz retrabalho e melhora a qualidade dos dados, porque deixa explícito o que pode (e o que não pode) ser registrado.

Exemplo: na entidade Cliente, data_nascimento descreve um fato específico (a data em que a pessoa nasceu). Já idade pode ser um dado derivado (calculado) e tende a gerar inconsistência se for armazenado sem necessidade.

Como definir um atributo: checklist completo

Ao definir um atributo, documente pelo menos os itens abaixo. Isso pode ser feito em um dicionário de dados (tabela) e, quando necessário, complementado por regras de validação.

• Nome: identificador técnico, consistente e sem ambiguidade.
• Significado (descrição): definição em linguagem de negócio, com exemplos quando útil.
• Tipo de dado: texto, inteiro, decimal, data/hora, booleano, etc.
• Formato: padrão de representação (ex.: YYYY-MM-DD para datas).
• Tamanho/precisão: ex.: VARCHAR(120), DECIMAL(10,2).
• Obrigatoriedade (nulabilidade): se pode ser nulo; se é obrigatório sempre ou apenas em certas condições.
• Valores permitidos: lista (enum), faixa, máscara, referência a tabela de domínio, etc.
• Valor padrão: valor assumido quando não informado (com cuidado para não mascarar erro).
• Regras adicionais: validações, unicidade, dependências e restrições condicionais.
• Origem (quando aplicável): informado pelo usuário, importado, calculado, integração, etc.

Exemplo rápido (definição bem especificada)

• Atributo: email
• Significado: endereço de e-mail principal do cliente para comunicação e recuperação de acesso.
• Tipo: texto
• Tamanho: até 254 caracteres
• Obrigatório: sim (para clientes com canal digital ativo)
• Valores permitidos: deve seguir padrão de e-mail (ex.: nome@dominio)
• Regras: deve ser único por cliente; normalizar para minúsculas; remover espaços nas extremidades

Passo a passo prático para especificar atributos

Passo 1 — Liste os fatos que precisam ser registrados

Para cada entidade, escreva perguntas do tipo “o que preciso saber sobre isso para operar o processo?”. Ex.: para Pedido: quando foi feito, qual o status, qual o valor, quem comprou, como será entregue.

Passo 2 — Transforme cada fato em um atributo candidato

Converta cada resposta em um nome de atributo. Ex.: “quando foi feito” → data_criacao; “status” → status_pedido.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Passo 3 — Defina significado e exemplos

Escreva a definição de negócio e um exemplo válido. Isso reduz interpretações diferentes entre times.

Passo 4 — Escolha tipo, formato e tamanho

Evite tipos genéricos demais. Ex.: preço não deve ser texto; use decimal com escala. Para datas, prefira tipo de data/hora em vez de texto.

Passo 5 — Defina obrigatoriedade e regras condicionais

Nem todo “obrigatório” é absoluto. Muitas vezes é condicional. Ex.: data_cancelamento só é obrigatória quando status_pedido = 'CANCELADO'.

Passo 6 — Defina domínio e validações

Estabeleça valores permitidos (lista/faixa/máscara) e regras de consistência (unicidade, dependência, integridade).

Passo 7 — Revise atomicidade, composição e multivalor

Antes de “fechar” o atributo, verifique se ele está atômico (um único valor), se é composto (pode ser decomposto) ou multivalorado (pode ter vários valores por registro).

Atributos atômicos, compostos e multivalorados

Atributos atômicos

São indivisíveis para o propósito do sistema. Ex.: cpf, data_nascimento, valor_total.

Regra prática: se você precisa filtrar, ordenar, validar ou integrar por partes, provavelmente não é atômico.

Atributos compostos

Podem ser decompostos em partes com significado próprio. Ex.: endereco pode virar logradouro, numero, complemento, bairro, cidade, uf, cep.

Como lidar: prefira armazenar as partes separadas quando elas forem usadas em busca, validação, relatórios ou integrações. Se houver necessidade de exibição “formatada”, ela pode ser derivada (montada) a partir das partes.

Atributos multivalorados

São aqueles em que um registro pode ter vários valores do mesmo tipo. Ex.: um cliente pode ter vários telefones.

Como lidar: em vez de criar colunas telefone1, telefone2, modele como uma estrutura separada (ex.: entidade/tabela ClienteTelefone) com um atributo que indique o tipo (principal, comercial, recado) e regras de unicidade.

Cliente (id_cliente, nome, ...)

ClienteTelefone (id_cliente, telefone, tipo_telefone, principal)

Assim você permite N telefones sem alterar o modelo e mantém validações consistentes.

Dados calculados/derivados: armazenar ou calcular?

Atributos derivados são obtidos a partir de outros dados. Ex.: idade derivada de data_nascimento; valor_total_pedido derivado da soma dos itens.

Quando evitar armazenar

• Quando o valor muda com o tempo sem um evento explícito (ex.: idade).
• Quando pode ser recalculado com baixo custo e sem perda de performance.
• Quando o risco de inconsistência é alto (atualizar um e esquecer o outro).

Quando pode fazer sentido armazenar

• Performance: cálculo caro e muito frequente (com controles de consistência).
• Auditoria/histórico: você precisa do valor “como era” em um momento (ex.: valor_total_fechamento após o pedido ser finalizado).
• Integração: sistemas externos exigem o valor materializado.

Boas práticas para derivados

• Documente como o atributo é calculado (fórmula/regra).
• Defina o “momento de congelamento” quando aplicável (ex.: no fechamento do pedido).
• Evite duplicar derivados que podem divergir (ex.: armazenar subtotal, desconto e total sem regras claras de consistência).

Domínios: valores permitidos e padronização

Domínio é a definição do conjunto de valores válidos para um atributo. Ele pode ser:

• Lista de valores (enum): conjunto fechado ou controlado (ex.: status).
• Faixa: mínimo/máximo (ex.: percentual de desconto entre 0 e 100).
• Máscara/padrão: formato obrigatório (ex.: CEP, placa, e-mail).
• Referência: valores vêm de uma tabela de domínio (ex.: UF, TipoDocumento).

Lista de valores (exemplo)

status_pedido:

• CRIADO
• PAGO
• FATURADO
• ENVIADO
• ENTREGUE
• CANCELADO

Cuidados: evite listas “soltas” em texto livre; padronize maiúsculas/minúsculas; defina se novos valores podem surgir e como serão versionados.

Faixa (exemplo)

percentual_desconto: decimal DECIMAL(5,2), permitido de 0.00 a 100.00.

Máscara/padrão (exemplos)

• cep: 8 dígitos numéricos; pode ser armazenado sem hífen e formatado na apresentação.
• cpf: 11 dígitos numéricos com validação de dígitos verificadores.
• email: padrão de e-mail e normalização (minúsculas).

Validações e regras de qualidade de dados

Domínio define o que é válido; validações garantem que o dado gravado respeite o domínio e as regras do negócio.

Tipos comuns de validação

• Obrigatoriedade: não aceitar nulo quando obrigatório.
• Unicidade: não permitir duplicidade (ex.: cpf único).
• Consistência entre campos: regras condicionais (ex.: se tipo_pessoa = 'PJ', então cnpj obrigatório e cpf não aplicável).
• Integridade referencial: valores devem existir em tabelas de referência (ex.: uf deve existir em DominioUF).
• Validação de formato: regex/máscara (ex.: e-mail, telefone).
• Validação temporal: datas coerentes (ex.: data_entrega não pode ser menor que data_envio).

Exemplo de regras condicionais (documentação)

Dicionário de dados: exemplo prático

Um dicionário de dados é o documento que descreve atributos, domínios e regras. Abaixo, um exemplo simplificado para as entidades Cliente e Pedido.

Boas práticas de nomenclatura de atributos

Princípios

• Consistência: use o mesmo padrão em todo o modelo (ex.: snake_case).
• Clareza: nomes autoexplicativos, evitando abreviações obscuras.
• Semântica: o nome deve refletir o significado real (ex.: data_pagamento não é data_atualizacao).
• Evite redundância: se a entidade já é Cliente, prefira nome em vez de nome_cliente, a menos que haja ambiguidade em consultas/integrações.
• Evite termos genéricos: descricao1, campo_extra, valor sem contexto.

Padrões úteis

• Datas: prefixo data_ para datas e data_hora_ quando necessário (ex.: data_hora_envio).
• Booleanos: prefixos como is_, tem_, ativo (ex.: is_principal, canal_digital_ativo).
• Chaves: id_* para identificadores (ex.: id_cliente).
• Valores monetários: prefixo valor_ e tipo decimal (ex.: valor_frete).

Erros comuns e como corrigir

Domínios como artefatos reutilizáveis

Para evitar repetir regras, trate domínios como componentes reutilizáveis. Exemplos típicos:

• DominioUF: lista fixa de UFs.
• DominioStatusPedido: lista controlada e versionada de status.
• DominioTipoTelefone: CELULAR, RESIDENCIAL, COMERCIAL, RECADO.

Ao documentar, indique se o domínio é fechado (não muda sem alteração de sistema) ou controlado (pode receber novos valores via governança).

Valor padrão: quando ajuda e quando atrapalha

Valor padrão pode ser útil para reduzir atrito (ex.: status_pedido inicia em CRIADO), mas pode mascarar falhas se usado para “preencher” dados que deveriam ser informados.

• Bom uso: data_criacao = agora; ativo = true ao cadastrar.
• Uso perigoso: email = 'nao_informado@exemplo.com' (gera lixo e quebra unicidade/contato).

Mini-roteiro de revisão de qualidade (para aplicar no seu modelo)

• Todo atributo tem definição clara e exemplo?
• O tipo escolhido impede valores inválidos (ex.: número como texto)?
• O atributo é atômico? Se não, deve ser decomposto?
• Se for multivalorado, existe estrutura adequada para N ocorrências?
• Domínio está explícito (lista/faixa/máscara/referência)?
• Obrigatoriedade é absoluta ou condicional? Está documentada?
• Derivados estão justificados (performance/auditoria) ou devem ser calculados?
• Nomenclatura segue padrão e evita ambiguidades?