Projete até à terceira forma normal, depois recue
Também em 28 idiomas
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 sustenta-se sozinho. Anterior: Coloque os dados onde eles pertencem · Próximo: Transforme o modelo em Salesforce
A pergunta que este módulo responde: Quando me devo afastar de propósito de um modelo normalizado e limpo?
No último módulo, disse-lhe para projetar até à terceira forma normal.
Agora vou dizer-lhe para a quebrar.
Às vezes.
Esta é uma distinção importante. Há uma grande diferença entre construir sem querer um modelo de dados desarrumado e desnormalizar de propósito um modelo limpo. Se não entende onde os dados pertencem, à partida, copiá-los para outro lugar não é arquitetura. É só duplicação.
Mas, depois de entender 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é à terceira forma normal onde for viável. Depois recue quando for preciso.
Repare no que esta frase não diz. 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 têm de a remontar na cabeça. A normalização diz-me onde pertence cada facto. Não promete que essa é a forma mais fácil de ler, usar ou reportar. É exatamente por isso que recuar é uma competência de design, e não um fracasso.
Comece por modelar a verdade. Depois decida como essa verdade precisa de ser entregue.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”De volta aos cães, e desta vez fazemos algumas escolhas deliberadas.
Raça: uma lista de opções, ou uma tabela própria? Passe-a pelas perguntas que lhe vou dar mais adiante neste módulo. Há mais do que 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. Por isso, a Raça merece a sua própria tabela, e cada cão aponta para a sua raça. Isso resolve a pergunta que trazemos desde o módulo 1: a Raça é uma caixa própria.
Nível de habilidade: uma lista de opções. A aprender, 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 sabe cada cão? A resposta já está no modelo: conte os registos de Truque do cão desse cão. Mas o treinador quer esse número em todos os relatórios, para ordenar e filtrar por ele, sem montar um relatório sobre duas tabelas. Por isso recuo, e mantenho uma contagem de Truques conhecidos diretamente no cão. Isso é uma cópia. A verdade continua a viver no Truque do cão; a contagem é uma representação dela, e tem de ficar sincronizada. O Salesforce dá-nos 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 Cão, e um Truque do gato ao lado do Truque do cão. Tudo duplica: dois de cada ecrã, 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 factos e as mesmas relações de um cão. Por isso generalizamos: um Pet (animal de estimação), com uma Espécie, cão ou gato. Cada raça também pertence a uma espécie, e é aí que a espécie realmente vive: um labrador é um cão. O pet leva uma cópia, de propósito, para que todos os ecrãs e relatórios possam começar com «cão ou gato?» sem consultar a raça. Mais uma cópia deliberada, e no módulo 6 ganha um trabalho próprio.
Isso é projetar para a mudança, e é um trade-off. Generalize cedo demais e tudo se torna uma «Coisa» vaga com um campo de tipo que ninguém entende. Eu generalizo quando o negócio me traz de facto o segundo tipo, e os dois partilham quase tudo, como os cães e os gatos aqui. Se os gatos precisassem de factos muito diferentes, 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 equipa numa paragem. A entrega tem os seus artigos. A instalação tem uma checklist. Cada etapa precisa de fotografias. O Destinatário assina.
O modelo normalizado é lindo: Entrega → Item de entrega → Checklist de instalação → Fotografia, cada um onde pertence.
Depois sento-me com as pessoas que realmente o usam. Uma equipa fecha umas dez paragens por dia, em garagens e passeios, muitas vezes sem rede. Se o meu lindo modelo as obriga a passar por um labirinto de ecrãs e listas relacionadas para terminar uma paragem, tenho um problema de arquitetura.
O modelo de dados não é a única coisa que estamos a projetar.
Estamos a projetar um sistema.
Às vezes a experiência do utilizador ganha
Seção intitulada “Às vezes a experiência do utilizador ganha ”Este é um dos motivos pelos quais às vezes me afasto de um modelo perfeitamente normalizado: experiência do utilizador.
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 deixo de perguntar só «Onde pertence este facto em teoria?» e começo a perguntar «Como vai este sistema ser realmente usado?»
Isso não significa que cada queixa sobre um clique a mais achate o modelo. Significa que a usabilidade é uma entrada legítima da arquitetura.
Às vezes os relatórios ganham
Seção intitulada “Às vezes os relatórios ganham ”Os relatórios são outro motivo comum.
Cada Parceiro retalhista quer um scorecard: entregas dentro do prazo por região, por mês. No modelo limpo, uma entrega conhece o seu centro de distribuição, e o CD conhece a sua região. Tecnicamente, conseguimos navegar por isso.
Mas a ferramenta de relatórios consegue? As pessoas que fazem os seus próprios relatórios conseguem? Conseguem responder à pergunta sem uma arquitetura de relatórios mais complicada do que a própria pergunta?
É aí que posso copiar ou derivar a região para a entrega, mais perto de onde é consumida.
Agora introduzi duplicação. Então preciso de outra pergunta: quem é dono da verdade?
Se o valor de origem muda, o que acontece à minha cópia? 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.
Desloca-a.
Relação de pesquisa ou lista de opções?
Seção intitulada “Relação de pesquisa ou lista de opções? ”Eis um exemplo menor que os administradores Salesforce encontram constantemente. O utilizador precisa de escolher entre um conjunto de valores. Crio outra entidade e relaciono-me com ela, ou uso uma lista de opções?
Pegue no estado de uma entrega: agendada, carregada, saiu para entrega, a chegar, 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 no tipo de paragem: só entrega, entrega com instalação, entrega com recolha. Esse carrega informação própria: quanto tempo a paragem leva, que competências a equipa tem de ter, que checklist de instalação se aplica. Muda de forma independente, e é o negócio que o gere. 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 ficar encurralado muito depressa.
Por isso pergunto: tem informação própria? Relações? Muda de forma independente? Precisa de ser gerido como dado? Poderá o negócio um dia precisar dele de mais do que um rótulo?
Eis as perguntas que realmente faço numa sessão de design.
Há mais do que uma coluna de informação? Se o valor precisa de uma descrição, uma duração, uma lista de competências, um responsável, já não é um rótulo.
Quantos valores? A minha regra prática é uns 20. Passados os 20 valores, uma lista de opções começa a descambar, e é altura 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-as 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 todas as semanas, e as pessoas que os acrescentam não são administradores, uma lista de opções põe um pedido de suporte à frente de cada valor novo.
As pessoas precisam de filtrar e fazer relatórios por ele? As listas de opções são ótimas para isso. As relações de pesquisa não são tão limpas. Cada relação 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 relações entre objetos), o ecrã passa a ter 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-a conquistá-lo.
À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 registos pode comportar-se de forma muito diferente com milhões.
Por isso 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, a crescer 30% ao ano. Cada entrega acumula umas oito atualizações de estado. São oito milhões de registos de estado este ano, e cerca de 13,5 milhões por ano no terceiro ano. Some quatro ou cinco milhões de fotografias por ano.
O mesmo modelo. Uma arquitetura muito diferente.
Vamos muito mais a fundo em Architecting at Scale (arquitetar à escala). Por agora, lembre-se: o volume pode mudar uma decisão de modelação de dados. Uma relação logicamente correta não é automaticamente o melhor design físico a qualquer escala.
Consumidores diferentes querem formas diferentes
Seção intitulada “Consumidores diferentes querem formas diferentes ”Até aqui pensámos no sistema operacional. Os coordenadores planeiam as rotas das entregas. As equipas fecham paragens. O sistema muda à medida que o negócio funciona.
Mas o negócio também quer analisar anos de histórico. Que parceiros e regiões se atrasam? Como mudou o tempo de entrega? Com que frequência as instalações precisam de uma segunda visita?
Um sistema analítico pode querer as mesmas informações organizadas de outra forma. Vai ouvir termos como data warehouse, facto, dimensão e esquema em estrela. Não os vamos destrinçar aqui; na Steve Trucking esse é o data warehouse no Snowflake, e vamos voltar a ele mais adiante no curso.
Por agora: 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 envia uma mensagem: «Onde está a minha entrega?» Um assistente de IA poderia consultar isto:
Entrega 10427, Rota 3312, Paragem 7, Camião 117, Janela 13:00–15:00.
Uma aplicação tradicional fica perfeitamente satisfeita a seguir estas relações. Mas, para responder ao Destinatário, o assistente precisa de contexto montado a partir de vários lugares:
A sua máquina de lavar loiça da Redrock é a sétima paragem da rota de hoje que sai do centro de distribuição de Phoenix. O camião está a três paragens de distância, e 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 o meu modelo normalizado. E com certeza não significa «a IA gosta de dados planos, por isso ponha 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á a fazer. É a mesma ideia que acabámos de ver com a análise:
Uma fonte da verdade pode sustentar várias formas de consumo.
Vamos muito mais a 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, envio 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. Tudo o resto é uma representação dessa verdade com um propósito.
Esse lugar é o sistema de registo. As cópias desnormalizadas podem ser boas: o ecrã da paragem, 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 registo, 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 isto importa mais quando os dados mudam. Se um centro de distribuição passa hoje para outra região, 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 já não é um problema de sincronização. É uma decisão de negócio.
É por isso que a desnormalização nunca deve acontecer por acidente. Cada facto 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 está a comprar (um ecrã mais fácil, um relatório mais simples, um contexto melhor para a IA) e o que está a pagar (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 ali. Estou a pôr uma representação aqui por causa deste requisito.» É uma decisão que podemos rever, questionar e registar, para que o próximo arquiteto saiba porquê.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Quando estou a considerar desnormalizar, estou a decidir:
- Onde vive a fonte com autoridade de cada fato de negócio.
- Se o modelo limpo cria problemas reais para utilizadores, relatórios, escala ou desempenho.
- Se uma representação mais simples compensa a duplicação, e como a cópia se mantém fiá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 pertence a verdade. Depois, quando os requisitos o justificarem, dê-lhe uma forma para a entrega.
A seguir, o Salesforce volta ao quadro. Vamos transformar o que projetámos 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 relações 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 estas três recém-chegadas.»
- 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 vai ver porque é que a Raça mereceu a sua própria tabela.