Modelagem de Dados do Zero: objetivos, contexto e entregáveis do modelo

O que você será capaz de produzir ao final do curso

Ao final do curso, você terá dois entregáveis principais, conectados entre si por regras claras de transformação:

• Diagrama ER (conceitual): representação do domínio do negócio em termos de entidades, relacionamentos, cardinalidades e regras essenciais, sem compromisso com um SGBD específico.
• Esquema lógico relacional: conjunto de tabelas, chaves primárias e estrangeiras, restrições e tipos de dados (quando aplicável), pronto para implementação em um banco relacional.

Além desses entregáveis, você produzirá artefatos intermediários que garantem consistência, comunicação com stakeholders e rastreabilidade entre requisitos e o modelo.

O que é um modelo de dados (e por que ele existe)

Um modelo de dados é uma descrição estruturada de como um domínio do mundo real será representado em dados, incluindo:

• Conceitos (entidades e atributos) que precisam ser armazenados.
• Relações entre esses conceitos (como eles se conectam).
• Regras que limitam e qualificam os dados (obrigatoriedade, unicidade, cardinalidade, dependências).

Modelo de dados em sistemas transacionais (OLTP)

Em sistemas transacionais, o modelo é orientado a registrar operações do dia a dia com integridade e consistência. Características típicas:

• Foco em cadastro e movimentação (ex.: pedidos, pagamentos, entregas).
• Regras de integridade fortes (chaves, restrições, validações).
• Estruturas que evitam redundância indevida e suportam atualizações frequentes.

Modelo de dados em sistemas analíticos (OLAP)

Em sistemas analíticos, o modelo é orientado a consulta, agregação e histórico para apoiar decisões. Características típicas:

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

• Foco em medidas e dimensões (ex.: vendas por período, por produto, por região).
• Ênfase em leitura e performance de consulta.
• Tratamento explícito de histórico e granularidade de análise.

Neste curso, o foco principal é construir um modelo sólido para o domínio (conceitual) e transformá-lo em um esquema lógico relacional consistente. Quando houver necessidade, indicaremos como decisões diferem em cenários analíticos.

Delimitação: escopo do problema, fronteiras do domínio e premissas

Modelar dados começa antes do desenho: começa definindo o que está dentro e fora do problema. Isso evita modelos inchados, ambíguos ou impossíveis de implementar.

1) Escopo do problema

Escopo é o conjunto de processos e informações que o sistema precisa cobrir. Uma forma prática de definir escopo é responder:

• Quais perguntas o sistema precisa responder? (consultas e relatórios essenciais)
• Quais operações o sistema precisa registrar? (eventos transacionais)
• Quais cadastros são necessários? (entidades mestre)

Exemplo (loja online): registrar pedidos, itens do pedido, pagamentos e entregas. Fora do escopo: contabilidade completa, antifraude avançado, CRM.

2) Fronteiras do domínio

Fronteiras definem onde termina a responsabilidade do sistema e onde começam integrações com outros sistemas. Perguntas úteis:

• Este dado é fonte de verdade aqui ou vem de outro sistema?
• Este evento acontece aqui ou apenas recebemos uma confirmação?
• Quais identificadores precisamos armazenar para integração?

Exemplo: o sistema de e-commerce pode armazenar id_gateway_pagamento e status do pagamento, mas a autorização detalhada pode estar no provedor externo.

3) Premissas e decisões explícitas

Premissas são escolhas documentadas para reduzir ambiguidade. Elas devem ser registradas para que o modelo seja interpretado corretamente.

• Granularidade: um pedido pode ter vários itens; um item referencia um produto.
• Histórico: manter histórico de preço do item no pedido (snapshot) ou sempre consultar preço atual do produto.
• Identidade: CPF é único para cliente? E para empresa (CNPJ)?

Premissas mal definidas viram inconsistência no banco (duplicidade, perda de histórico, regras contraditórias).

Entregáveis por etapa: quais artefatos serão gerados

Para sair de requisitos textuais até um esquema relacional, você produzirá artefatos que se conectam. Abaixo está uma visão prática do que será gerado em cada etapa.

Etapa 1 — Glossário do domínio

Objetivo: alinhar linguagem e reduzir ambiguidades. Cada termo relevante recebe uma definição curta e exemplos.

Conteúdo típico do glossário:

• Termo
• Definição
• Sinônimos/termos proibidos
• Exemplos e observações

Etapa 2 — Lista de entidades e atributos candidatos

Objetivo: transformar substantivos e informações dos requisitos em candidatos a entidades e atributos.

Saída: uma lista inicial (ainda sujeita a revisão) com:

• Entidade candidata
• Descrição
• Atributos candidatos
• Identificador candidato (se existir)

Exemplo (trecho):

• Cliente: nome, email, documento, telefone
• Pedido: data, status, total, endereço de entrega (ou referência)
• Produto: nome, SKU, preço atual

Etapa 3 — Regras de negócio (catálogo de regras)

Objetivo: registrar restrições e comportamentos que impactam o modelo. Regras de negócio são a ponte entre texto e estrutura.

Formato recomendado: cada regra com um identificador único (ex.: RB-###), descrição e impacto.

Etapa 4 — Diagrama ER (conceitual)

Objetivo: consolidar entidades, relacionamentos e cardinalidades, incorporando as regras de negócio essenciais.

O que deve aparecer no diagrama conceitual:

• Entidades e seus atributos principais (sem detalhar tipos físicos)
• Relacionamentos e cardinalidades (1:1, 1:N, N:N)
• Opcionalidade (participação obrigatória/opcional)
• Generalizações/especializações quando fizer sentido

Exemplo de leitura (texto): Cliente (1) — (N) Pedido; Pedido (1) — (N) ItemPedido; ItemPedido (N) — (1) Produto.

Etapa 5 — Dicionário de dados (definições detalhadas)

Objetivo: detalhar cada atributo e padronizar significado, formato e validações. O dicionário evita interpretações divergentes na implementação.

Campos comuns:

• Nome do atributo
• Descrição
• Domínio (valores possíveis)
• Obrigatoriedade
• Exemplos
• Origem (se vem de integração)

Etapa 6 — Esquema lógico relacional

Objetivo: converter o modelo conceitual em tabelas relacionais com chaves e restrições.

Saída típica:

• Tabelas e colunas
• Chaves primárias (PK)
• Chaves estrangeiras (FK)
• Restrições (UNIQUE, NOT NULL, CHECK)

CLIENTE(id_cliente PK, nome, email UNIQUE, documento UNIQUE, ... ) PEDIDO(id_pedido PK, id_cliente FK, data_pedido, status, ... ) ITEM_PEDIDO(id_pedido FK, seq_item, id_produto FK, qtd, preco_unitario, PK(id_pedido, seq_item))

Observe que o esquema lógico torna explícitas as decisões de identificação (PK), dependência (FK) e integridade (restrições), mantendo coerência com as regras catalogadas.

Como garantir rastreabilidade entre requisitos textuais e elementos do modelo

Rastreabilidade é a capacidade de apontar, para cada elemento do modelo, qual requisito o originou e, para cada requisito, onde ele está atendido no modelo. Isso reduz retrabalho e facilita revisão.

Estratégia prática: IDs e matriz de rastreabilidade

Use identificadores únicos para requisitos e regras, e referencie esses IDs nos artefatos seguintes.

• REQ-###: requisito textual (funcional ou informacional)
• RB-###: regra de negócio
• ER-###: elemento do diagrama (entidade/relacionamento) ou decisão
• DD-###: item do dicionário de dados

Passo a passo para montar rastreabilidade:

1. Numere os requisitos no documento de entrada (ex.: REQ-010 “Registrar pedidos com itens e quantidades”).
2. Extraia regras e numere (ex.: RB-001 “Pedido deve ter ao menos um item”).
3. Ao criar entidades/relacionamentos, anote a origem (ex.: Entidade PEDIDO atende REQ-010; relacionamento PEDIDO–ITEM_PEDIDO atende RB-001).
4. No dicionário de dados, inclua uma coluna “Origem” com REQ-###/RB-###.
5. No esquema lógico, mantenha comentários ou documentação externa apontando quais tabelas/colunas implementam quais regras.

Exemplo de matriz de rastreabilidade

Boas práticas para manter rastreabilidade viva

• Evite nomes soltos: padronize nomes de entidades e atributos e mantenha equivalência entre diagrama, dicionário e esquema lógico.
• Registre decisões: quando houver alternativas (ex.: histórico de preço), crie uma decisão com ID e vincule aos elementos afetados.
• Controle de mudanças: quando um requisito mudar, atualize primeiro o catálogo (REQ/RB) e depois percorra os links para ajustar diagrama, dicionário e esquema.