Aprenda um método prático para transformar histórias de usuário, entidades e fluxos de trabalho em um esquema de banco de dados claro e como o raciocínio de IA pode ajudar a verificar lacunas e regras.
Um esquema de banco de dados é o plano de como sua aplicação vai lembrar das coisas. Em termos práticos, é:
Quando o esquema corresponde ao trabalho real, ele reflete o que as pessoas realmente fazem—criar, revisar, aprovar, agendar, designar, cancelar—em vez do que soa arrumado num quadro branco.
Histórias de usuário e critérios de aceitação descrevem necessidades reais em linguagem simples: quem faz o quê, e o que significa “feito”. Se você usa esses elementos como fonte, o esquema tem menos chance de perder detalhes chave (como “temos que rastrear quem aprovou o reembolso” ou “um agendamento pode ser reagendado várias vezes”).
Começar pelas histórias também mantém você honesto quanto ao escopo. Se não está nas histórias (ou no fluxo), trate como opcional em vez de construir um modelo complicado “só por precaução”.
A IA pode ajudar você a ir mais rápido, por exemplo:
A IA não pode, de forma confiável:
Trate a IA como uma assistente poderosa, não como quem toma a decisão.
Se quiser transformar essa assistente em velocidade de execução, uma plataforma vibe-coding como Koder.ai pode ajudar você a ir de decisões de esquema para uma aplicação React + Go + PostgreSQL funcionando mais rápido—enquanto mantém você no controle do modelo, restrições e migrações.
O design de esquema é um ciclo: rascunho → testar contra histórias → encontrar dados faltantes → refinar. O objetivo não é um primeiro resultado perfeito; é um modelo que você consiga traçar de volta para cada história de usuário e dizer com confiança: “Sim, podemos armazenar tudo que esse fluxo precisa—e explicar por que cada tabela existe.”
Antes de transformar requisitos em tabelas, deixe claro o que você está modelando. Um bom esquema raramente começa do zero—começa a partir do trabalho concreto que as pessoas fazem e da prova que você precisará depois (telas, saídas e casos de borda).
Histórias de usuário são a manchete, mas não bastam sozinhas. Reúna:
Se você estiver usando IA, essas entradas mantêm o modelo ancorado. A IA pode propor entidades e campos rapidamente, mas precisa de artefatos reais para evitar inventar uma estrutura que não casa com seu produto.
Os critérios de aceitação muitas vezes contêm as regras de banco de dados mais importantes, mesmo quando não mencionam dados explicitamente. Procure por declarações como:
Histórias vagas (“Como usuário, posso gerenciar projetos”) escondem múltiplas entidades e fluxos. Outra lacuna frequente são casos de borda faltantes como cancelamentos, tentativas, reembolsos parciais ou reatribuições.
Antes de pensar em tabelas ou diagramas, leia as histórias e destaque os substantivos. Em escrita de requisitos, substantivos geralmente apontam às “coisas” que seu sistema deve lembrar—essas frequentemente viram entidades no seu esquema.
Um modelo mental rápido: substantivos viram entidades, enquanto verbos viram ações ou fluxos. Se uma história diz “Um gerente atribui um técnico a um trabalho”, as entidades prováveis são manager, technician e job—e “atribui” indica um relacionamento que você modelará depois.
Nem todo substantivo merece sua própria tabela. Um substantivo é um bom candidato a entidade quando:
Se um substantivo aparece apenas uma vez, ou apenas descreve outra coisa (“botão vermelho”, “sexta-feira”), pode não ser uma entidade.
Um erro comum é transformar todo detalhe em tabela. Use esta regra prática:
Dois exemplos clássicos:
A IA pode acelerar a descoberta de entidades escaneando histórias e retornando uma lista inicial de substantivos agrupados por tema (pessoas, itens de trabalho, documentos, locais). Um prompt útil é: “Extraia substantivos que representam dados que devemos armazenar, e agrupe duplicatas/sinônimos.”
Trate a saída como um ponto de partida, não como a resposta final. Faça perguntas de acompanhamento como:
O objetivo do Passo 1 é uma lista curta e limpa de entidades que você consiga defender apontando para as histórias reais.
Uma vez que você nomeou as entidades (como Order, Customer, Ticket), o próximo trabalho é capturar os detalhes que você precisará mais tarde. No banco de dados, esses detalhes são campos (também chamados atributos)—os lembretes que seu sistema não pode esquecer.
Comece com a história de usuário, depois leia os critérios de aceitação como uma lista do que deve ser armazenado.
Se um requisito diz “Usuários podem filtrar pedidos por data de entrega”, então delivery_date não é opcional—deve existir como campo (ou ser derivável de outros dados armazenados). Se diz “Mostrar quem aprovou a solicitação e quando”, você provavelmente precisará de approved_by e approved_at.
Um teste prático: Alguém precisará disso para exibir, buscar, ordenar, auditar ou calcular algo? Se sim, provavelmente pertence como campo.
Muitas histórias incluem palavras como “status”, “type” ou “priority”. Trate-as como vocabulários controlados—um conjunto limitado de valores permitidos.
Se o conjunto for pequeno e estável, um campo enum simples pode funcionar. Se pode crescer, precisa de rótulos ou requer permissões (ex.: categorias gerenciadas por admin), use uma tabela de lookup separada (ex.: status_codes) e armazene uma referência.
É assim que histórias viram campos em que você pode confiar—pesquisáveis, reportáveis e difíceis de inserir errado.
Depois de listar as entidades (User, Order, Invoice, Comment, etc.) e rascunhar seus campos, o próximo passo é conectá-las. Relacionamentos são a camada de “como essas coisas interagem” implícita nas histórias.
Um-para-um (1:1) significa “uma coisa tem exatamente uma outra coisa.”
User ↔ Profile (muitas vezes você pode mesclar essas tabelas a menos que haja razão para separá-las).Um-para-muitos (1:N) significa “uma coisa pode ter muitas de outra.” Este é o mais comum.
User → Order (armazene user_id em Order).Muitos-para-muitos (M:N) significa “muitas coisas podem se relacionar com muitas coisas.” Isso precisa de uma tabela extra.
Bancos de dados não conseguem armazenar “uma lista de product IDs” propriamente dentro de Order sem causar problemas depois (busca, atualização, relatório). Em vez disso, crie uma tabela de junção que represente o relacionamento em si.
Exemplo:
OrderProductOrderItem (tabela de junção)OrderItem normalmente inclui:
order_idproduct_idquantity, unit_price, discountObserve como os detalhes da história (“quantity”) frequentemente pertencem ao relacionamento, não a nenhuma das entidades isoladas.
As histórias também dizem se uma conexão é obrigatória ou por vezes ausente.
Order precisa de um user_id (não permitir em branco).phone pode ficar vazio.shipping_address_id pode ser nulo para pedidos digitais.Um cheque rápido: se a história implica que não dá para criar o registro sem o link, trate como obrigatório. Se a história diz “pode”, “pode ser” ou dá exceções, trate como opcional.
Quando você lê uma história, reescreva-a como um pareamento simples:
User 1:N CommentComment N:1 UserFaça isso para cada interação nas suas histórias. No final, você terá um modelo conectado que corresponde a como o trabalho realmente acontece—antes mesmo de abrir uma ferramenta de diagrama ER.
Histórias de usuário dizem o quê as pessoas querem. Fluxos de trabalho mostram como o trabalho realmente anda, passo a passo. Traduzir um fluxo em dados é uma das formas mais rápidas de capturar problemas de “esquecemos de armazenar isso”—antes de construir qualquer coisa.
Escreva o fluxo como uma sequência de ações e mudanças de estado. Por exemplo:
Essas palavras em negrito muitas vezes viram um campo status (ou uma pequena tabela de “state”), com valores permitidos claros.
Ao caminhar por cada passo, pergunte: “O que precisaríamos saber mais tarde?” Fluxos costumam revelar campos como:
submitted_at, approved_at, completed_atcreated_by, assigned_to, approved_byrejection_reason, approval_notesequence para processos em vários passosSe o seu fluxo inclui espera, escalonamento ou repasses, você geralmente precisará pelo menos de um timestamp e um campo “quem tem agora”.
Alguns passos do fluxo não são apenas campos—são estruturas de dados separadas:
Forneça à IA: (1) as histórias e critérios de aceitação, e (2) os passos do fluxo. Peça para listar cada passo e identificar os dados necessários para cada um (estado, ator, timestamps, saídas), então destacar qualquer requisito que não possa ser suportado pelos campos/tabelas atuais.
Em plataformas como Koder.ai, essa “checagem de lacunas” fica especialmente prática porque você pode iterar rápido: ajuste pressupostos do esquema, regenere scaffoldings e continue sem um grande desvio por boilerplate manual.
Ao transformar histórias em tabelas, você não está apenas listando campos—você também decide como os dados permanecem identificáveis e consistentes ao longo do tempo.
Uma chave primária identifica unicamente um registro—pense nela como a carteira de identidade permanente da linha.
Por que cada linha precisa de uma: histórias implicam atualizações, referências e histórico. Se uma história diz “Suporte pode ver um pedido e emitir um reembolso”, você precisa de uma forma estável de apontar o pedido—mesmo que o cliente mude o email, o endereço seja editado ou o status do pedido mude.
Na prática, isso costuma ser um id interno (número ou UUID) que nunca muda.
Uma chave estrangeira é como uma tabela aponta com segurança para outra. Se orders.customer_id referencia customers.id, o banco pode assegurar que todo pedido pertence a um cliente real.
Isto corresponde a histórias como “Como usuário, posso ver minhas faturas.” A fatura não fica solta; ela está ligada a um cliente (e muitas vezes a um pedido ou assinatura).
Histórias frequentemente contêm requisitos de unicidade ocultos:
Essas regras evitam duplicatas confusas que aparecem meses depois como “bugs de dados”.
Índices aceleram pesquisas como “encontrar cliente por email” ou “listar pedidos por cliente”. Comece com índices alinhados às suas consultas mais comuns e às regras de unicidade.
O que deixar para depois: indexação pesada para relatórios raros ou filtros especulativos. Capture essas necessidades nas histórias, valide o esquema primeiro e otimize com base em uso real e evidência de consultas lentas.
Normalização tem um objetivo simples: evitar duplicatas conflitantes. Se um mesmo fato pode ser salvo em dois lugares, cedo ou tarde vai discordar (duas grafias, dois preços, dois endereços “atuais”). Um esquema normalizado armazena cada fato uma vez e referencia-o.
1) Cuidado com grupos repetidos
Se você vê padrões como “Phone1, Phone2, Phone3” ou “ItemA, ItemB, ItemC”, isso sinaliza outra tabela (ex.: CustomerPhones, OrderItems). Grupos repetidos dificultam busca, validação e escala.
2) Não copie o mesmo nome/detalhe em várias tabelas
Se CustomerName aparece em Orders, Invoices e Shipments, você criou múltiplas fontes de verdade. Mantenha detalhes do cliente em Customers e armazene só customer_id onde for necessário.
3) Evite “múltiplas colunas para a mesma coisa”
Colunas como billing_address, shipping_address, home_address podem ser aceitáveis se realmente forem conceitos diferentes. Mas se você está modelando “muitos endereços de tipos diferentes”, use uma tabela Addresses com um campo type.
4) Separe lookups de texto livre
Se usuários escolhem de um conjunto conhecido (status, category, role), modele consistentemente: ou enum restrito ou tabela de lookup. Isso evita “Pending” vs “pending” vs “PENDING”.
5) Verifique se todo campo não-ID depende da coisa certa
Um bom teste de intuição: em uma tabela, se uma coluna descreve algo que não é a entidade principal da tabela, provavelmente pertence em outro lugar. Ex.: Orders não deve armazenar product_price a menos que signifique “preço no momento do pedido” (um snapshot histórico).
Às vezes você armazena duplicatas de propósito:
O ponto é fazer intencionalmente: documente qual campo é a fonte de verdade e como as cópias são atualizadas.
A IA pode sinalizar duplicações suspeitas (colunas repetidas, nomes de campo parecidos, campos de “status” inconsistentes) e sugerir divisão em tabelas. Humanos ainda escolhem o trade-off—simplicidade vs. flexibilidade vs. performance—baseado em como o produto será realmente usado.
Uma regra útil: armazene fatos que você não consegue recriar de forma confiável mais tarde; calcule todo o resto.
Dados armazenados são a fonte de verdade: itens individuais de linha, timestamps, mudanças de status, quem fez o quê. Dados calculados (derivados) são produzidos a partir desses fatos: totais, contadores, flags como “está atrasado” e rollups como “estoque atual”.
Se dois valores podem ser calculados a partir dos mesmos fatos, prefira armazenar os fatos e calcular o resto. Caso contrário, você corre o risco de contradições.
Valores derivados mudam quando suas entradas mudam. Se você armazena tanto as entradas quanto o resultado derivado, precisa mantê-los sincronizados em todos os fluxos e casos de borda (edições, reembolsos, alterações retroativas). Uma atualização perdida e o banco começa a contar duas histórias diferentes.
Exemplo: armazenar order_total enquanto também guarda order_items. Se alguém muda uma quantidade ou aplica desconto e o total não for atualizado perfeitamente, financeiro vê um número enquanto o carrinho mostra outro.
Fluxos mostram quando você precisa da verdade histórica, não só da “verdade atual”. Se usuários precisam saber qual era o valor naquela hora, armazene um snapshot.
Para um pedido, você pode armazenar:
order_total capturado no checkout (snapshot), pois impostos, descontos e regras de preço mudam depoisPara inventário, “nível de estoque” costuma ser calculado a partir de movimentos (recebimentos, vendas, ajustes). Mas se você precisa de trilha de auditoria, armazene os movimentos e, opcionalmente, snapshots periódicos para rapidez em relatórios.
Para login tracking, armazene last_login_at como fato (timestamp de evento). “Está ativo nos últimos 30 dias?” fica calculado.
Vamos usar um aplicativo familiar de suporte/tickets. Iremos de cinco histórias a um modelo ER simples (entidades + campos + relacionamentos), e então checar contra um fluxo.
Desses substantivos, tiramos entidades centrais:
Antes (erro comum): Ticket tem assignee_id, mas esquecemos de garantir que somente agentes possam ser assignees.
Depois: a IA sinaliza e você adiciona uma regra prática: assignee deve ser um User com role = “agent” (implementada via validação de aplicação ou uma constraint/policy no banco, dependendo da stack). Isso evita “atribuir para um cliente” e quebrar relatórios depois.
Um esquema só está “pronto” quando cada história pode ser respondida com dados que você realmente pode armazenar e consultar. O passo de validação mais simples é pegar cada história e perguntar: “Podemos responder essa pergunta a partir do banco de dados, de forma confiável, para todo caso?” Se a resposta for “talvez”, seu modelo tem uma lacuna.
Reescreva cada história como uma ou mais questões de teste—coisas que você esperaria de um relatório, tela ou API. Exemplos:
Se você não conseguir expressar uma história como uma pergunta clara, a história está confusa. Se conseguir expressar—mas não conseguir responder com seu esquema—falta um campo, um relacionamento, um status/evento ou uma restrição.
Crie um conjunto pequeno de dados (5–20 linhas por tabela chave) que inclua casos normais e complicados (duplicados, valores faltantes, cancelamentos). Então “execute” as histórias usando esses dados. Você vai notar problemas rapidamente como “não dá para saber qual endereço foi usado na compra” ou “não temos onde guardar quem aprovou a mudança”.
Peça à IA para gerar perguntas de validação por história (incluindo casos de borda e cenários de deleção), e para listar quais dados seriam necessários para respondê-las. Compare essa lista com seu esquema: qualquer discrepância vira uma ação concreta, não uma sensação vaga de que “algo está errado”.
A IA pode acelerar a modelagem, mas também aumenta o risco de vazar informação sensível ou de cristalizar suposições ruins. Trate-a como uma assistente muito rápida: útil, mas precisa de guardrails.
Compartilhe entradas realistas o suficiente para modelar, mas saneadas o bastante para ser seguro:
invoice_total: 129.50, status: "paid")Evite qualquer coisa que identifique pessoa ou revele operações confidenciais:
Se precisar de realismo, gere amostras sintéticas que batam com formatos e intervalos—nunca copie linhas de produção.
Esquemas falham em geral porque “todo mundo assumiu” algo diferente. Ao lado do seu modelo ER (ou no mesmo repositório), mantenha um registro curto de decisões:
Isso transforma a saída da IA em conhecimento de equipe em vez de artefato único.
Seu esquema vai evoluir com novas histórias. Mantenha-o seguro:
Se você usa uma plataforma como Koder.ai, aproveite guardrails como snapshots e rollback ao iterar mudanças de esquema, e exporte o código-fonte quando precisar de revisão tradicional ou customização profunda.
Comece pelas histórias e destaque os substantivos que representam coisas que o sistema precisa lembrar (por exemplo, Ticket, User, Category).
Promova um substantivo a entidade quando ele:
Mantenha uma lista curta que você possa justificar apontando para sentenças específicas das histórias.
Use o teste “atributo vs. entidade”:
customer.phone_number).Uma pista rápida: se você algum dia precisar de “muitos desses”, provavelmente precisa de outra tabela.
Trate critérios de aceitação como uma lista de verificação de armazenamento. Se um requisito diz que você deve filtrar/ordenar/exibir/auditar algo, você deve armazená-lo (ou derivá-lo de forma confiável).
Exemplos:
approved_by, approved_atdelivery_dateReescreva sentenças das histórias como sentenças de relacionamento:
customer_id em orders)order_items)Se o relacionamento em si tiver dados (quantidade, preço, papel), esses dados pertencem à tabela de junção.
Modele M:N com uma tabela de junção que armazene ambas as chaves estrangeiras mais campos específicos do relacionamento.
Padrão típico:
ordersPercorra o fluxo de trabalho passo a passo e pergunte: “O que precisaríamos provar que isso aconteceu mais tarde?”
Adições comuns:
submitted_at, closed_atComece com:
id)orders.customer_id → customers.id)Depois adicione índices para suas buscas mais comuns (ex.: , , ). Deixe indexes especulativos para depois, baseados em padrões reais de consulta.
Faça uma checagem rápida de consistência:
Phone1/Phone2, divida em uma tabela filha.Desnormalize depois apenas com uma razão clara (performance, relatório, snapshots de auditoria) e documente o que é a autoridade.
Armazene fatos que você não pode recriar de forma confiável; calcule todo o resto.
Bom de armazenar:
Bom de calcular:
Se você armazenar valores derivados (como ), decida como mantê-los sincronizados e teste os casos de borda (reembolsos, edições, envios parciais).
Use IA para rascunhos e depois verifique contra seus artefatos.
Prompts práticos:
Guardrails:
emailproductsorder_items com order_id, product_id, quantity, unit_priceEvite armazenar “uma lista de IDs” em uma única coluna—consultas, atualizações e integridade ficam difíceis.
created_by, assigned_to, closed_byrejection_reasonSe você precisa saber “quem mudou o quê e quando”, adicione uma tabela de eventos/auditoria em vez de sobrescrever um único campo.
emailcustomer_idstatus + created_atorder_total