O que significa “do texto ao Diagrama ER (conceitual)”
O objetivo deste roteiro é transformar uma descrição textual (requisitos, e-mails, documento de processos, entrevista) em um Diagrama Entidade-Relacionamento (ER) conceitual. Aqui, o foco é operacional: você vai produzir artefatos intermediários (lista de termos, glossário, lista de entidades/atributos, relações e regras) e iterar até que o diagrama represente o negócio com precisão e sem ambiguidades.
O ponto-chave é trabalhar em ciclos curtos: você não “acerta de primeira”. Você evolui o modelo a cada iteração, testando contra cenários reais e ajustando nomes, regras e relacionamentos.
Roteiro operacional em 8 passos
1) Extrair termos e regras do texto
Comece com uma leitura “marcadora”: sublinhe substantivos (possíveis entidades/atributos), verbos (possíveis relacionamentos) e quantificadores/condições (regras, cardinalidades, opcionalidades, unicidade).
- Substantivos: cliente, pedido, item, produto, pagamento, endereço.
- Verbos: realiza, contém, pertence, paga, entrega.
- Quantificadores: “um ou mais”, “no máximo um”, “pode”, “obrigatório”, “único”, “por pedido”.
- Regras explícitas: “o pedido deve ter ao menos um item”, “CPF é único”.
Produza duas listas brutas: (a) termos candidatos e (b) regras candidatas, sem tentar modelar ainda.
2) Consolidar um glossário (padronizar linguagem)
Antes de desenhar, elimine ambiguidade. Para cada termo relevante, registre: definição curta, sinônimos, exemplos, e observações (o que não é).
- Ouça o áudio com a tela desligada
- Ganhe Certificado após a conclusão
- + de 5000 cursos para você explorar!
Baixar o aplicativo
| Termo | Definição | Sinônimos/Observações |
|---|---|---|
| Cliente | Pessoa que compra na loja | Pode ser pessoa física; “comprador” no texto |
| Pedido | Solicitação de compra feita por um cliente | Tem data e status |
| Item do Pedido | Linha do pedido que referencia um produto e quantidade | No texto pode aparecer como “item” |
| Produto | Bem vendido pela loja | Identificado por SKU |
Regra prática: se o time usa dois nomes para a mesma coisa, escolha um termo padrão e registre o outro como sinônimo. Se um termo é usado para duas coisas diferentes, divida em dois termos distintos.
3) Listar entidades e atributos (rascunho estruturado)
Com o glossário em mãos, separe o que tende a ser entidade (algo com identidade própria no negócio) do que tende a ser atributo (característica de algo). Faça um rascunho em formato de lista.
Entidades candidatas: Cliente, Pedido, ItemPedido, Produto, Pagamento, EnderecoEntrega? (ver regra do negócio)Em seguida, associe atributos prováveis a cada entidade, sem se preocupar ainda com chaves.
Cliente: nome, cpf, email, telefone? (validar), dataCadastro? (validar necessidade conceitual)Pedido: data, statusItemPedido: quantidade, precoUnitarioNoMomento? (validar)Produto: sku, nome, precoAtualPagamento: data, valor, forma, statusCritério operacional: se um “atributo” precisa ter vários valores ao longo do tempo ou tem estrutura própria (ex.: múltiplos pagamentos, múltiplos endereços), ele pode virar entidade. Marque com “?” para validar no passo 8.
4) Definir chaves (identificadores conceituais)
Agora escolha como cada entidade será identificada no nível conceitual. Você pode usar identificadores naturais (ex.: CPF, SKU) quando são estáveis e realmente únicos no negócio; ou um identificador substituto (ex.: idCliente) quando o natural é instável, sensível ou não confiável.
- Cliente: CPF pode ser candidato a identificador; se o negócio aceita cliente sem CPF (ex.: estrangeiro), então CPF não pode ser obrigatório e você precisará de um identificador alternativo.
- Produto: SKU costuma ser um bom identificador natural se for único e não reutilizado.
- Pedido: geralmente um número de pedido (ou idPedido) é o identificador.
- ItemPedido: frequentemente é identificado pelo par (Pedido, Produto) ou por (Pedido, númeroSequencialDoItem). Decida com base em regras: “um produto pode aparecer duas vezes no mesmo pedido?” Se não pode, (Pedido, Produto) funciona; se pode, use sequencial.
Registre decisões e dependências no próprio glossário (ou em uma seção “Decisões de modelagem”).
5) Mapear relacionamentos (verbo + sentido)
Converta verbos do texto em relacionamentos nomeados. Uma técnica prática é escrever frases no padrão: “Entidade A <verbo> Entidade B”.
- Cliente realiza Pedido
- Pedido contém ItemPedido
- ItemPedido refere-se a Produto
- Pedido é pago por Pagamento
Evite relacionamentos genéricos como “tem” sem significado. Prefira verbos que expliquem o papel (realiza, contém, refere-se, liquida, entrega, etc.).
6) Aplicar cardinalidades e opcionalidades (a partir das regras)
Use as regras extraídas no passo 1 para definir participação mínima e máxima. Sempre que possível, amarre a cardinalidade a uma frase do requisito.
- “Um cliente pode fazer vários pedidos” → Cliente 1:N Pedido (do lado de Pedido, mínimo 0 ou 1 conforme regra de cadastro).
- “Todo pedido deve ter ao menos um item” → Pedido 1:1..N ItemPedido.
- “Um item do pedido referencia exatamente um produto” → ItemPedido N:1 Produto.
- “Um pedido pode ser pago em uma ou mais parcelas” → Pedido 1:1..N Pagamento (se for permitido pagamento parcial).
Quando o texto não diz, marque como pendência e volte no passo 8 com perguntas objetivas (ex.: “pedido pode existir sem pagamento?” “produto pode ficar sem preço?”).
7) Revisar redundâncias e normalização conceitual (sem perder significado)
Nesta etapa, você procura sinais de duplicidade e inconsistência sem “otimizar demais”. Checklist prático:
- Mesmo dado em dois lugares: “preço do produto” e “preço no item do pedido” não são necessariamente redundantes; podem representar conceitos diferentes (preço atual vs. preço praticado na compra). Se são diferentes, mantenha ambos com nomes claros.
- Atributo que é entidade disfarçada: “formaPagamento” como texto pode ser entidade (FormaPagamento) se houver regras próprias (códigos, taxas, disponibilidade).
- Listas dentro de atributo: “telefones do cliente” como atributo único sugere entidade Telefone ou atributo multivalorado (dependendo da notação adotada).
- Relacionamento faltando: se existe “endereço de entrega” e ele muda por pedido, não é atributo do Cliente; tende a ser associado ao Pedido.
O resultado esperado é um modelo conceitual mais coerente, com nomes que distinguem conceitos parecidos e sem duplicações acidentais.
8) Validar com cenários e exemplos (teste de mesa)
Valide o diagrama com “histórias de dados” curtas: crie exemplos concretos e veja se o modelo consegue representá-los sem gambiarras.
- Cenário A: cliente faz um pedido com 2 itens, paga em 2 pagamentos.
- Cenário B: cliente faz pedido e cancela antes de pagar (o modelo permite pedido sem pagamento?).
- Cenário C: mesmo produto aparece duas vezes no mesmo pedido (o identificador de ItemPedido permite?).
Para cada cenário, tente “instanciar” entidades e relacionamentos. Se você precisar violar cardinalidades, duplicar dados ou inventar campos, o modelo precisa de ajuste.
Caso completo e progressivo (modelo evoluindo por iterações)
Texto inicial (requisitos)
“A loja registra clientes. Cada cliente informa nome, CPF e e-mail. Um cliente pode realizar vários pedidos. Todo pedido possui data e status e deve conter pelo menos um item. Cada item do pedido informa quantidade e se refere a um produto. Produtos possuem SKU, nome e preço atual. Um pedido pode ser pago em uma ou mais parcelas; cada pagamento tem data, valor e forma.”
Iteração 1 — Extração e rascunho (termos, entidades e relações)
Termos candidatos: loja, cliente, nome, CPF, e-mail, pedido, data, status, item, quantidade, produto, SKU, preço, pagamento, parcela, forma.
Regras candidatas:
- Cliente pode realizar vários pedidos.
- Pedido deve conter pelo menos um item.
- Item refere-se a um produto.
- Pedido pode ser pago em uma ou mais parcelas.
Entidades (rascunho): Cliente, Pedido, ItemPedido, Produto, Pagamento.
Relacionamentos (rascunho):
- Cliente realiza Pedido
- Pedido contém ItemPedido
- ItemPedido refere-se a Produto
- Pedido é pago por Pagamento
Iteração 2 — Atributos e identificadores (primeira versão consistente)
Cliente(cpf, nome, email)
Produto(sku, nome, precoAtual)
Pedido(idPedido?, data, status)
ItemPedido(quantidade, ...)
Pagamento(idPagamento?, data, valor, forma)
Decisões pendentes (marque para validar):
- Pedido terá um identificador próprio (idPedido/numeroPedido) ou é identificado por (Cliente, data)? (normalmente precisa de idPedido/numeroPedido).
- ItemPedido será identificado por (Pedido, Produto) ou (Pedido, sequencial)? Depende se o mesmo produto pode repetir no pedido.
- Forma de pagamento é texto livre ou catálogo controlado?
Iteração 3 — Cardinalidades e opcionalidades (derivadas do texto)
| Relacionamento | Cardinalidade (conceitual) | Justificativa no texto |
|---|---|---|
| Cliente —realiza→ Pedido | Cliente 1 : 0..N Pedido | “pode realizar vários pedidos” (não obriga ter pedido) |
| Pedido —contém→ ItemPedido | Pedido 1 : 1..N ItemPedido | “deve conter pelo menos um item” |
| ItemPedido —refere-se a→ Produto | ItemPedido N : 1 Produto | “se refere a um produto” |
| Pedido —é pago por→ Pagamento | Pedido 1 : 1..N Pagamento | “pode ser pago em uma ou mais parcelas” |
Ponto de atenção: “pode ser pago” pode significar que o pedido pode existir sem pagamento (ex.: aguardando pagamento). Se isso for possível, a cardinalidade do lado de Pagamento vira 0..N. Isso será resolvido na validação por cenários.
Iteração 4 — Ajustes por regra implícita (preço no item e repetição de produto)
Ao testar cenários, surge uma pergunta: se o preço do produto muda, como preservar o preço praticado no pedido? O texto não diz, mas é uma necessidade comum. Você pode introduzir precoUnitario em ItemPedido como “preço no momento da compra”, sem remover precoAtual de Produto.
Produto(sku, nome, precoAtual)ItemPedido(quantidade, precoUnitario)Outra pergunta: o mesmo produto pode aparecer duas vezes no mesmo pedido? Se a resposta for “não”, ItemPedido pode ser identificado por (Pedido, Produto). Se a resposta for “sim” (ex.: itens separados por observação, brindes, lotes), use um sequencial do item.
Opção A (sem repetição): ItemPedido identificado por (Pedido, Produto)Opção B (com repetição): ItemPedido identificado por (Pedido, numeroItem)Iteração 5 — Refinar “forma de pagamento” (atributo vs. entidade)
Se “forma” for apenas um rótulo (PIX, cartão, boleto) sem regras adicionais, pode permanecer como atributo. Se houver regras (taxas, parcelamento máximo, bandeira, conciliação), promova para entidade FormaPagamento e relacione Pagamento a ela.
Pagamento(idPagamento, data, valor)Pagamento N:1 FormaPagamento(codigo, descricao)Esse tipo de decisão deve ser guiado por regras e cenários, não por preferência estética.
Iteração 6 — Validação com cenários (teste de mesa) e correções finais
Cenário A: Cliente Ana (CPF 123) faz Pedido P100 em 10/01 com 2 itens: (Produto SKU10, qtd 1, precoUnitario 50) e (Produto SKU20, qtd 2, precoUnitario 30). Paga em 2 pagamentos: 40 no PIX e 70 no cartão.
- O modelo suporta 1 pedido com 2 itens? Sim (Pedido 1..N ItemPedido).
- O modelo suporta 2 pagamentos para o mesmo pedido? Sim (Pedido 1..N Pagamento).
- O modelo preserva preço praticado mesmo se preçoAtual mudar? Sim (precoUnitario em ItemPedido).
Cenário B: Pedido criado e ainda não pago (aguardando pagamento).
- Se o negócio permite, ajuste Pedido—Pagamento para 0..N do lado de Pagamento.
Cenário C: Mesmo produto aparece duas vezes no pedido.
- Se permitido, escolha a identificação de ItemPedido com numeroItem (Opção B).
Como documentar a evolução do diagrama (entregável prático)
Para mostrar o diagrama evoluindo a cada iteração, registre versões com mudanças explícitas:
- V1: entidades e relacionamentos principais (sem detalhes de chaves e cardinalidades).
- V2: atributos principais e identificadores escolhidos.
- V3: cardinalidades/opcionalidades aplicadas e pendências listadas.
- V4: ajustes por cenários (ex.: precoUnitario em ItemPedido; opcionalidade de Pagamento; FormaPagamento como entidade se necessário).
Esse histórico facilita validação com stakeholders: cada mudança tem motivo (regra, cenário, ambiguidade resolvida), e o diagrama final é consequência de decisões rastreáveis.
