Projete até a terceira forma normal, depois recue
Também em 28 idiomas
English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 5 de 6 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Coloque os dados onde eles pertencem · Próximo: Transforme o modelo em Salesforce
A pergunta que este módulo responde: Quando devo me afastar de propósito de um modelo normalizado e limpo?
No último módulo, eu disse para você projetar até a terceira forma normal.
Agora vou dizer para você quebrá-la.
Às vezes.
Essa é uma distinção importante. Há uma grande diferença entre construir sem querer um modelo de dados bagunçado e desnormalizar de propósito um modelo limpo. Se você não entende onde os dados pertencem, para começo de conversa, copiá-los para outro lugar não é arquitetura. É só duplicação.
Mas, depois que entendo o modelo lógico limpo, posso tomar a decisão consciente de dar aos dados outra forma para as pessoas e os sistemas que os consomem.
Projete até a terceira forma normal onde for viável. Depois recue quando necessário.
Repare no que essa frase não diz. Ela não diz que a terceira forma normal é mais fácil de entender. Às vezes é mais difícil: um modelo totalmente normalizado pode espalhar uma ideia de negócio por cinco objetos, e as pessoas que o usam precisam remontá-la na cabeça. A normalização me diz onde cada fato pertence. Ela não promete que essa é a forma mais fácil de ler, usar ou reportar. É exatamente por isso que recuar é uma habilidade de design, e não um fracasso.
Comece modelando a verdade. Depois decida como essa verdade precisa ser entregue.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”De volta aos cachorros, e desta vez fazemos algumas escolhas deliberadas.
Raça: uma lista de opções, ou uma tabela própria? Passe-a pelas perguntas que vou lhe dar mais adiante neste módulo. Há mais de uma coluna de informação? Sim: o porte, pelo menos. Quantos valores? Os kennel clubs reconhecem algumas centenas de raças (só o American Kennel Club lista 205), bem acima da minha regra prática de uns 20. Então a Raça merece sua própria tabela, e cada cachorro aponta para a sua raça. Isso resolve a pergunta que carregamos desde o módulo 1: a Raça é uma caixa própria.
Nível de habilidade: uma lista de opções. Aprendendo, Bom, Especialista. Três rótulos, nada mais a dizer sobre eles, e não vão mudar. É exatamente para isso que serve uma lista de opções.
Quantos truques cada cachorro sabe? A resposta já está no modelo: conte os registros de Truque do cachorro do cachorro. Mas o adestrador quer esse número em todo relatório, para ordenar e filtrar por ele, sem montar um relatório sobre duas tabelas. Então eu recuo, e mantenho uma contagem de Truques conhecidos direto no cachorro. Isso é uma cópia. A verdade continua vivendo no Truque do cachorro; a contagem é uma representação dela, e precisa ficar em sincronia. O Salesforce nos dá uma forma limpa de fazer exatamente isso, e vamos vê-la no módulo 6.
Agora a reviravolta: a escola de cães começa a aceitar gatos. O que fazemos? Uma opção: acrescentar uma tabela Gato ao lado da tabela Cachorro, e um Truque do gato ao lado do Truque do cachorro. Tudo dobra: duas de cada tela, dois de cada relatório, e no dia em que aceitarem coelhos, três. A outra opção: dar um passo atrás e perceber que um gato tem um dono, talvez um criador, uma raça, uma data de nascimento e, com paciência, um ou dois truques. Os mesmos fatos e os mesmos relacionamentos de um cachorro. Então generalizamos: um Pet (animal de estimação), com uma Espécie, cachorro ou gato. Cada raça também pertence a uma espécie, e é aí que a espécie realmente vive: um labrador é um cachorro. O pet carrega uma cópia, de propósito, para que toda tela e todo relatório possam começar com “cachorro ou gato?” sem consultar a raça. Mais uma cópia deliberada, e no módulo 6 ela ganha um trabalho próprio.
Isso é projetar para a mudança, e é um trade-off. Generalize cedo demais e tudo vira uma “Coisa” vaga com um campo de tipo que ninguém entende. Eu generalizo quando o negócio de fato me traz o segundo tipo, e os dois compartilham quase tudo, como cachorros e gatos aqui. Se os gatos precisassem de fatos muito diferentes, eu pensaria duas vezes.
Agora os mesmos tipos de escolha na Steve Trucking, onde o que está em jogo é maior.
O modelo mais limpo nem sempre é o melhor sistema
Seção intitulada “O modelo mais limpo nem sempre é o melhor sistema ”Imagine uma equipe numa parada. A entrega tem seus itens. A instalação tem um checklist. Cada etapa precisa de fotos. O Destinatário assina.
O modelo normalizado é lindo: Entrega → Item de entrega → Checklist de instalação → Foto, cada um onde pertence.
Aí me sento com as pessoas que realmente o usam. Uma equipe fecha umas dez paradas por dia, em garagens e calçadas, muitas vezes sem sinal. Se meu lindo modelo as faz passar por um labirinto de telas e listas relacionadas para terminar uma parada, tenho um problema de arquitetura.
O modelo de dados não é a única coisa que estamos projetando.
Estamos projetando um sistema.
Às vezes a experiência do usuário vence
Seção intitulada “Às vezes a experiência do usuário vence ”Este é um dos motivos pelos quais às vezes me afasto de um modelo perfeitamente normalizado: experiência do usuário.
Talvez um conceito pudesse tecnicamente ser uma entidade própria, mas separá-lo acrescenta uma complexidade que traz pouquíssimo valor. Talvez um pai com vários níveis de filhos seja academicamente limpo, mas um sofrimento para preencher e manter. Talvez o conceito seja pequeno, estável e usado quase só como seleção.
É aqui que paro de perguntar só “Onde este fato pertence em teoria?” e começo a perguntar “Como este sistema vai realmente ser usado?”
Isso não significa que toda reclamação sobre um clique a mais achata o modelo. Significa que a usabilidade é uma entrada legítima da arquitetura.
Às vezes os relatórios vencem
Seção intitulada “Às vezes os relatórios vencem ”Os relatórios são outro motivo comum.
Cada Parceiro varejista quer um scorecard: entregas no prazo por região, por mês. No modelo limpo, uma entrega conhece seu centro de distribuição, e o CD conhece sua região. Tecnicamente, conseguimos navegar por isso.
Mas a ferramenta de relatórios consegue? As pessoas que montam os próprios relatórios conseguem? Elas conseguem responder à pergunta sem uma arquitetura de relatórios mais complicada do que a própria pergunta?
É aí que eu posso copiar ou derivar a região para a entrega, mais perto de onde ela é consumida.
Agora introduzi duplicação. Então preciso de outra pergunta: quem é dono da verdade?
Se o valor de origem muda, o que acontece com minha cópia? Ela deve mudar? Ou deve manter o que era verdade quando a entrega aconteceu? São requisitos diferentes.
A desnormalização não elimina a complexidade.
Ela a move.
Relacionamento de pesquisa ou lista de opções?
Seção intitulada “Relacionamento de pesquisa ou lista de opções? ”Eis um exemplo menor que administradores Salesforce encontram o tempo todo. O usuário precisa escolher entre um conjunto de valores. Crio outra entidade e me relaciono com ela, ou uso uma lista de opções?
Pegue o status de uma entrega: agendada, carregada, saiu para entrega, chegando, entregue, instalada, exceção, devolvida. Uma lista curta e estável de rótulos. Uma lista de opções é exatamente o que quero.
Agora pegue o tipo de parada: só entrega, entrega com instalação, entrega com recolhimento. Esse carrega informação própria: quanto tempo a parada leva, que habilidades a equipe precisa ter, qual checklist de instalação se aplica. Ele muda de forma independente, e o negócio o gerencia. Isso é uma entidade, não um rótulo.
Se crio um objeto para cada conceito que em teoria poderia ser normalizado, posso construir um sistema tecnicamente lindo que ninguém gosta de usar. Se transformo cada conceito numa lista de opções porque é fácil, posso me encurralar num canto muito rápido.
Então pergunto: ele tem informação própria? Relacionamentos? Muda de forma independente? Precisa ser gerenciado como dado? O negócio poderia um dia precisar de mais dele do que um rótulo?
Eis as perguntas que realmente faço numa sessão de design.
Há mais de uma coluna de informação? Se o valor precisa de uma descrição, uma duração, uma lista de habilidades, um responsável, ele não é mais um rótulo.
Quantos valores? Minha regra prática é uns 20. Passou de 20 valores, uma lista de opções começa a desandar, e é hora de pensar num objeto. Os estados americanos, cinquenta, são a exceção com que convivemos, e os países são piores; sinceramente, alguém adora listas de opções de países? Eu acho irritantes.
Os valores são criados ao longo do tempo, e por quem? Acrescentar um valor de lista de opções é uma mudança de configuração, o que significa um administrador. Se o negócio acrescenta valores toda semana, e as pessoas que os acrescentam não são administradores, uma lista de opções coloca um chamado na frente de cada valor novo.
As pessoas precisam filtrar e fazer relatórios por ele? Listas de opções são ótimas para isso. Relacionamentos de pesquisa não são tão limpos. Cada relacionamento de pesquisa acrescenta um salto: um tipo de relatório segue só uma cadeia curta de objetos relacionados (um tipo de relatório personalizado permite no máximo quatro relacionamentos entre objetos), a tela vira listas relacionadas dentro de listas relacionadas, e o código fica mais complicado.
Uma lista de valores muitas vezes nasce como lista de opções e, com o tempo, conquista o direito a um objeto próprio. Deixe que ela conquiste.
Às vezes a escala muda a resposta
Seção intitulada “Às vezes a escala muda a resposta ”Um design que funciona lindamente com alguns milhares de registros pode se comportar de forma muito diferente com milhões.
Então não olhe só para o diagrama. Conheça os números.
A Steve Trucking faz cerca de um milhão de entregas por ano, crescendo 30% ao ano. Cada entrega acumula umas oito atualizações de status. São oito milhões de registros de status este ano, e cerca de 13,5 milhões por ano no terceiro ano. Some quatro ou cinco milhões de fotos por ano.
Mesmo modelo. Arquitetura muito diferente.
Vamos muito mais fundo em Architecting at Scale (arquitetar em escala). Por enquanto, lembre-se: o volume pode mudar uma decisão de modelagem de dados. Um relacionamento logicamente correto não é automaticamente o melhor design físico em qualquer escala.
Consumidores diferentes querem formas diferentes
Seção intitulada “Consumidores diferentes querem formas diferentes ”Até aqui pensamos no sistema operacional. Coordenadores roteirizam entregas. Equipes fecham paradas. O sistema muda à medida que o negócio funciona.
Mas o negócio também quer analisar anos de histórico. Quais parceiros e regiões atrasam? Como o tempo de entrega mudou? Com que frequência as instalações precisam de uma segunda visita?
Um sistema analítico pode querer as mesmas informações organizadas de outro jeito. Você vai ouvir termos como data warehouse, fato, dimensão e esquema estrela. Não vamos destrinchá-los aqui; na Steve Trucking esse é o data warehouse no Snowflake, e vamos voltar a ele mais adiante no curso.
Por enquanto: consumidores diferentes podem precisar de formas diferentes da mesma verdade.
A IA acrescenta outro consumidor
Seção intitulada “A IA acrescenta outro consumidor ”E agora há outro consumidor: a IA.
Um Destinatário manda uma mensagem: “Cadê minha entrega?” Um assistente de IA poderia consultar isto:
Entrega 10427, Rota 3312, Parada 7, Caminhão 117, Janela 13:00–15:00.
Uma aplicação tradicional fica perfeitamente feliz seguindo esses relacionamentos. Mas, para responder ao Destinatário, o assistente precisa de contexto montado a partir de vários lugares:
Sua lava-louças da Redrock é a sétima parada da rota de hoje que sai do centro de distribuição de Phoenix. O caminhão está a três paradas de distância, e você ainda está dentro da sua janela das 13h às 15h.
Pegamos informações de várias entidades relacionadas e montamos uma representação mais plana e rica em contexto para um consumidor específico.
Isso não significa que eu destrua meu modelo normalizado. E com certeza não significa “a IA gosta de dados planos, então coloque tudo num único objeto gigante”. Não faça isso.
A fonte da verdade continua limpa. A IA recebe uma representação construída para o trabalho que está fazendo. É a mesma ideia que acabamos de ver com a análise:
Uma fonte da verdade pode sustentar várias formas de consumo.
Vamos muito mais fundo em grounding e recuperação mais adiante no curso.
Não crie várias verdades
Seção intitulada “Não crie várias verdades ”Há um perigo aqui.
Se copio a região para a entrega por causa dos relatórios, mando uma versão achatada para o Snowflake e construo uma versão rica em contexto para o assistente de IA, qual delas está correta?
Essa pergunta precisa de resposta. Quero saber onde vive o valor com autoridade. Todo o resto é uma representação dessa verdade com um propósito.
Esse lugar é o sistema de registro. Cópias desnormalizadas podem ser boas: a tela da parada, o scorecard, o Snowflake e o contexto da IA fazem cada um melhor o seu trabalho com uma forma construída para eles, e consultá-las não tem problema. Mas, quando algo muda, a mudança começa no sistema de registro, tipicamente o modelo relacional, e flui para fora, para cada cópia. Ninguém corrige a região no Snowflake, nem edita à mão o contexto da IA. Corrija na origem, e deixe a mudança fluir.
E isso importa mais quando os dados mudam. Se um centro de distribuição muda para outra região hoje, as entregas do mês passado devem mostrar a nova região? Talvez. Talvez não. Para o histórico, posso precisar da região que era verdade quando a entrega aconteceu. Isso não é mais um problema de sincronização. É uma decisão de negócio.
É por isso que a desnormalização nunca deve acontecer por acidente. Todo fato duplicado levanta perguntas sobre propriedade, sincronização, histórico e confiança. É o raciocínio de trade-offs do capítulo 1: saiba o que você está comprando (uma tela mais fácil, um relatório mais simples, um contexto melhor para a IA) e o que está pagando (dados duplicados, sincronização, uma propriedade da verdade mais complicada). E, como partimos de um modelo lógico limpo, podemos apontar para cada cópia e dizer: “Sei que isto pertence lá. Estou colocando uma representação aqui por causa deste requisito.” Essa é uma decisão que podemos revisar, questionar e registrar, para que o próximo arquiteto saiba por quê.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Quando estou considerando desnormalizar, estou decidindo:
- Onde vive a fonte com autoridade de cada fato de negócio.
- Se o modelo limpo cria problemas reais para usuários, relatórios, escala ou desempenho.
- Se uma representação mais simples vale a duplicação, e como a cópia continua confiável.
- Se os valores históricos devem mudar quando a fonte atual muda.
- Se a análise ou a IA precisam de uma forma dos dados diferente da do sistema operacional.
O ponto de partida nunca muda: saiba onde a verdade pertence. Depois, quando os requisitos justificarem, dê a ela uma forma para a entrega.
A seguir, o Salesforce volta para o quadro. Vamos transformar o que projetamos num modelo de dados físico.
Para saber mais
Seção intitulada “Para saber mais ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 de junho de 2019 (em inglês, consultado em 2026-10-12): um tipo de relatório personalizado “pode abranger até 4 relacionamentos de objetos”.
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 de janeiro de 2026 (em inglês, consultado em 2026-10-12): “O AKC reconhece 205 raças, incluindo essas três novatas.”
- Por diversão: a FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (em inglês, consultado em 2026-10-12): a lista de raças da federação internacional, em dez grupos. Percorra-a e você vai ver por que a Raça mereceu sua própria tabela.