7.7 Modelagem de dados e camada semântica

Visão geral e motivação

Um modelo de dados é uma decisão sobre o que os seus dados significam, tomada antes de decidir onde os dados vivem. Ele nomeia as coisas com que o seu negócio se importa, os atributos que as descrevem e as relações entre elas. Armazenamento, índices, formatos de arquivo e motores de consulta vêm todos depois. Essa ordem importa porque o significado dos seus dados sobrevive a toda tecnologia que vocês usam para guardá-los. Os warehouses são substituídos, os formatos de tabela mudam e os motores de consulta vão e vêm, mas “cliente”, “pedido” e “usuário ativo” precisam significar a mesma coisa em todos eles, por anos.

Para uma equipe pequena, a modelagem costuma ser implícita. Um engenheiro guarda o esquema inteiro na cabeça, e um entendimento compartilhado de “receita” sobrevive porque há apenas três pessoas para discordar. Na escala das grandes organizações de desenvolvimento, das empresas e das agências governamentais, essa informalidade desmorona exatamente como descrito no capítulo 7.1 (estratégia e governança de dados). Dezenas de equipes constroem centenas de tabelas, cada uma com a sua ideia do que é uma “sessão” ou de quando um usuário conta como “ativo”. Dois painéis mostram dois números diferentes para a mesma semana, e uma reunião de liderança vira uma discussão sobre de quem é a consulta certa em vez de o que fazer a seguir. A má modelagem não se anuncia. Aparece meses depois como trabalho de reconciliação, auditorias malsucedidas e decisões tomadas com números que ninguém consegue defender.

Este capítulo trata de fazer esse trabalho deliberadamente. Cobre modelos conceituais, lógicos e físicos; a modelagem entidade-relacionamento; quando normalizar e quando desnormalizar; como a modelagem difere para cargas transacionais e analíticas; a modelagem dimensional com fatos e dimensões; e a camada semântica que guarda a definição governada, única, de cada métrica de negócio. O ganho não é elegância por si só. É que “usuário ativo” e “receita” signifiquem uma só coisa em toda parte, de modo que as suas equipes possam confiar nos números e andar mais depressa por causa disso.

Veja também: capítulo 3.4 (arquitetura e armazenamento de dados), capítulo 7.3 (análises e inteligência de negócio) e capítulo 11.5 (indicadores-chave de desempenho).

Princípios fundamentais

Decidam o que os dados significam antes de decidir onde vivem.
Modelem em três níveis: conceitual (negócio), lógico (estrutura), físico (implementação).
Normalizem para proteger a correção nos sistemas transacionais. Desnormalizem deliberadamente para a velocidade analítica.
Ajustem o modelo à carga: transações e análises têm necessidades opostas.
Toda métrica de negócio tem exatamente uma definição governada, e ela vive na camada semântica.
As dimensões conformadas permitem que equipes independentes juntem e comparem dados com segurança.
A granularidade é uma decisão de projeto tomada de propósito, não um acidente de uma consulta.
Os modelos são ativos vivos: nomeiem-nos bem, documentem-nos e mantenham-nos evolutivos.

Recomendações

Modele em três níveis, em ordem

Trabalhem do significado para fora. Comecem por um modelo conceitual: as entidades com que o negócio se importa e como se relacionam, escritas em linguagem simples que um especialista do domínio possa conferir. “Um cliente faz muitos pedidos; um pedido contém muitos itens; cada item se refere a um produto.” Sem chaves, sem tipos, sem tabelas ainda. Depois construam um modelo lógico que acrescenta estrutura: atributos, chaves primárias e estrangeiras, cardinalidades e restrições, ainda independente de qualquer banco de dados específico. A modelagem entidade-relacionamento é a notação padrão aqui, e um diagrama entidade-relacionamento é o artefato que vocês revisam com engenheiros e com partes interessadas do negócio. Só então produzam o modelo físico: as tabelas, colunas, tipos de dados, índices, partições e layout de armazenamento reais para o motor escolhido. Pular para o projeto físico é o erro de modelagem mais comum, porque assa as escolhas tecnológicas de hoje em decisões que deveriam durar mais que elas.

Normalize os sistemas transacionais, desnormalize os analíticos de propósito

Para os sistemas que registram transações, favoreçam a normalização de bancos de dados. As formas normais removem a redundância para que cada fato seja guardado uma só vez, o que previne anomalias de atualização e mantém as escritas corretas quando muitos usuários mudam dados concorrentemente. Esse é o padrão certo para o processamento de transações online (OLTP), onde a correção sob escritas concorrentes importa mais que a velocidade de qualquer consulta analítica isolada. Os sistemas analíticos têm prioridades opostas. Eles leem muito, varrem e agregam faixas enormes, e juntar dezenas de tabelas normalizadas na hora da consulta é lento e difícil de raciocinar. Ali vocês desnormalizam de propósito, reunindo atributos relacionados para que as consultas sejam mais simples e mais rápidas. A disciplina é desnormalizar deliberadamente, com uma razão documentada, em vez de deixar a redundância se infiltrar por acidente. O capítulo 3.4 (arquitetura e armazenamento de dados) cobre os motores que fazem cada padrão render.

Use a modelagem dimensional para análises

Para as cargas analíticas, adotem a modelagem dimensional, a abordagem popularizada por Ralph Kimball. Vocês dividem o mundo em fatos e dimensões. Uma tabela de fatos guarda as medições de um processo de negócio: o valor de uma venda, a duração de uma chamada, a quantidade despachada. As tabelas de dimensões guardam o contexto descritivo pelo qual vocês filtram e agrupam: o cliente, o produto, a loja, a data. Arrumem uma tabela de fatos cercada por suas dimensões e vocês têm um esquema estrela, fácil de os analistas entenderem e rápido de os motores consultarem. Normalizem essas dimensões em subtabelas e vocês têm um esquema floco de neve, que economiza algum armazenamento ao custo de mais junções e mais complexidade. Prefiram a estrela, a menos que tenham uma razão concreta. Para ambientes muito grandes e altamente regulados em que a auditabilidade e o rastreamento da origem dominam, uma abordagem de data vault modela hubs, links e satélites para capturar histórico e linhagem de forma agressiva, ao custo de mais tabelas e uma curva de aprendizado mais íngreme. A maioria das equipes deve começar com estrelas no estilo Kimball e recorrer ao data vault apenas quando as exigências de auditoria o justificarem.

Fixe a granularidade e trate as dimensões que mudam explicitamente

Antes de acrescentar uma única coluna a uma tabela de fatos, declarem a sua granularidade: exatamente o que uma linha representa. “Uma linha por item de pedido.” “Uma linha por usuário por dia.” A granularidade é a fundação de um modelo correto, porque toda medida e toda dimensão ou se encaixa nessa granularidade ou não pertence à tabela. Misturar granularidades é como se obtém receita contada em dobro. Depois decidam como as dimensões mudam com o tempo. Um cliente se muda para outra cidade: vocês sobrescrevem o valor antigo, guardam o histórico completo ou acompanham só o valor atual e o anterior? Esses são os padrões clássicos de dimensão de mudança lenta, e escolher errado significa que os seus relatórios históricos reescrevem o passado em silêncio. Decidam a granularidade e a estratégia de mudança de antemão, escrevam-nas na documentação do modelo e mantenham a linha na revisão.

Construa uma camada semântica como a definição única de cada métrica

Esta é a recomendação que paga o capítulo inteiro. Uma camada semântica fica entre as tabelas físicas e toda ferramenta que as consome e guarda a definição governada, única, de cada métrica de negócio. “Usuário ativo” é definido uma só vez, como código, com a sua lógica exata: quais eventos contam, em que janela, excluindo quais contas internas. “Receita” é definida uma só vez, incluindo como os reembolsos, os descontos e a conversão de moeda são tratados. Todo painel, caderno, relatório e job de ETL reverso lê essa definição em vez de reimplementá-la numa consulta sob medida. Quando a definição muda, muda num só lugar e todos os consumidores se atualizam juntos. Esse é o mecanismo que torna reais, e não aspiracionais, as definições governadas de métricas, e é a implementação direta do que o capítulo 11.5 (indicadores-chave de desempenho) pede. Tratem as definições de métricas como código versionado, com donos, revisão e testes, exatamente como o capítulo 7.1 pede que vocês tratem os dados como um produto.

Estabeleça convenções, nomeação e documentação

A consistência é uma funcionalidade. Adotem convenções de nomeação e imponham-nas: uma convenção para nomes de tabelas, uma para chaves, um padrão para colunas de data, uma regra para marcar um fato versus uma dimensão. Decidam uma vez se usam nomes de entidades no singular ou no plural e nunca os misturem. Documentem cada modelo onde as pessoas que o usam vão olhar: o significado de cada tabela, a granularidade de cada fato, a definição de cada métrica e o dono de cada uma. Boa nomeação e boa documentação são o que permite a um novo analista se servir sozinho em vez de interromper a equipe, e o que permite a um auditor rastrear um número da apresentação ao conselho até a origem sem um passeio guiado.

Mantenha os modelos evolutivos

O seu modelo vai mudar, então projetem para a mudança. Acrescentem colunas em vez de reaproveitar as existentes. Usem chaves substitutas para que uma mudança na chave natural de um sistema de origem não se propague por todo o warehouse. Versionem as definições de métricas e descontinuem-nas com aviso em vez de alterá-las em silêncio sob painéis em execução. Mantenham as transformações em controle de versões, testadas e revisadas, de modo que uma mudança no que “usuário ativo” significa seja um pull request com um diff e um aprovador, não uma edição discreta numa ferramenta de BI. Um modelo que vocês não conseguem evoluir com segurança vira um modelo que as pessoas contornam, e as definições paralelas são como a fonte única da verdade morre.

Compromissos: prós e contras

Abordagem	Prós	Contras	Melhor ajuste
Normalizada (3FN)	Escritas corretas, sem redundância, flexível	Junções analíticas lentas, consultas complexas	OLTP e sistemas operacionais
Esquema estrela (Kimball)	Rápido, intuitivo, amigável ao analista	Alguma redundância, ETL a manter	A maioria das análises e BI
Esquema floco de neve	Menos armazenamento, dimensões mais limpas	Mais junções, mais complexidade	Dimensões grandes e rigidamente governadas
Data vault	Histórico completo, auditável, cargas ágeis	Muitas tabelas, curva de aprendizado íngreme	Altamente regulado, pesado em auditoria
Camada semântica sobre modelos	Uma definição em toda parte, agnóstica de ferramenta	Construção inicial, exige propriedade	Organizações multiequipe e multiferramenta

A tensão central é a velocidade de uma única consulta contra a correção e a flexibilidade em todo o patrimônio. A normalização protege a correção e a paga em complexidade de consulta; os modelos dimensionais compram velocidade e clareza de consulta e as pagam com ETL e alguma redundância gerenciada. Não há vencedor universal, e é por isso que vocês ajustam o modelo à carga em vez de escolher um favorito. A camada semântica resolve a segunda tensão, entre muitas equipes e muitas ferramentas, tornando a definição da métrica independente de qualquer uma delas. O erro é tratar esses campos como arraiais ideológicos. Uma organização saudável roda sistemas OLTP normalizados, modelos analíticos dimensionais alimentados por eles e uma camada semântica por cima, cada um fazendo o trabalho em que é bom.

Perguntas para discutir com sua equipe

Quando dois painéis mostram números diferentes para a mesma métrica, a definição de quem vence, e onde essa definição fisicamente vive? Esta pergunta expõe se vocês de fato têm uma fonte única da verdade ou apenas acreditam que têm. Na maioria das grandes equipes, a resposta honesta é que “usuário ativo” é redefinido em uma dúzia de consultas diferentes, e o vencedor é quem discute mais alto na reunião. Levem evidências reais: escolham uma métrica, achem todos os lugares onde ela é calculada e comparem a lógica linha a linha. Vocês quase certamente acharão desacordos silenciosos sobre janelas, exclusões e casos de borda. A resposta deve conduzir à decisão de construir uma camada semântica em que cada métrica é definida uma só vez, como código revisado, para que a pergunta deixe de ser sobre pessoas e passe a ser sobre um artefato versionado. Enquanto essa definição não tiver um único lar físico, toda reconciliação é temporária.
Qual é a granularidade da sua tabela de fatos mais importante, e todos na sala conseguem enunciá-la do mesmo modo? A granularidade é a fundação silenciosa a que a maioria das falhas de modelagem remonta. Se metade da equipe diz “uma linha por pedido” e a outra metade diz “uma linha por item de pedido”, vocês têm um bug de contagem em dobro esperando para surgir num relatório de receita. Levem a tabela de verdade e peçam a cada pessoa que descreva uma linha em uma frase. O desacordo aqui não é um problema de comunicação a ser amaciado: é um defeito de projeto a consertar antes que mais medidas se acumulem por cima. A resposta deve ser escrita na documentação do modelo e imposta na revisão, porque, uma vez que os analistas constroem consultas sobre uma granularidade ambígua, a ambiguidade se espalha mais depressa do que vocês conseguem corrigir.
Como este modelo vai absorver a mudança, e o que acontece com os relatórios do ano passado quando uma definição muda? Todo modelo enfrenta sistemas de origem que mudam, regras de negócio que mudam e definições de métricas que mudam, então a pergunta real é se a mudança é um pull request controlado ou uma edição silenciosa que reescreve a história. Levem um exemplo recente: uma métrica cuja definição mudou, ou uma chave de origem que foi renomeada, e rastreiem o que aconteceu com os painéis existentes. Se uma dimensão de mudança lenta foi tratada por sobrescrita, os seus relatórios históricos podem ter mudado em silêncio os próprios valores passados, o que é um problema sério para quem faz análise de tendência ou relatórios regulados. A resposta deve empurrar vocês para chaves substitutas, definições de métricas versionadas, estratégias explícitas de mudança e transformações mantidas em controle de versões com revisão. Um modelo que ninguém consegue mudar com segurança vira um modelo que as pessoas abandonam.
Que dimensões precisam significar a mesma coisa em todas as equipes, e quem responde por ser dono de cada uma? As dimensões conformadas são o que permite ao marketing, às finanças e às operações juntar seus dados e obter respostas comparáveis, mas só quando “cliente”, “produto”, “região” e “data” carregam uma definição combinada em vez de uma cópia privada por equipe. A atração contrária é a autonomia: cada equipe quer modelar o próprio mundo no próprio ritmo, e forçar uma dimensão compartilhada as atrasa no curto prazo enquanto compensa em todo o patrimônio. Levem as duas ou três dimensões que aparecem em mais relatórios entre equipes, listem todas as versões de cada uma que existem hoje e vejam o quanto suas chaves e atributos de fato divergem. Nomeiem um dono para cada dimensão conformada, porque uma dimensão compartilhada sem dono volta a ser cópias privadas em um trimestre. Em contextos corporativos e governamentais, em que um número de um departamento é comparado com o de outro em público, uma dimensão não conformada é a diferença entre uma comparação honesta e uma falsidade acidental, então decidam cedo quais dimensões são governadas centralmente e quais ficam locais.
Onde fica a fronteira entre os seus sistemas transacionais normalizados e os seus modelos analíticos desnormalizados, e toda desnormalização é uma decisão deliberada? Ajustar o modelo à carga é a disciplina central, mas a fronteira é exatamente onde ela se turva: um analista desnormaliza uma tabela do warehouse por velocidade, um engenheiro normaliza uma tabela de relatório por hábito e ninguém escreveu a que lado cada escolha pertence. A tensão é a velocidade de uma única consulta contra a correção e a flexibilidade em tudo, e pessoas razoáveis chegam a conclusões diferentes conforme sejam donas das escritas ou das leituras. Levem a sua consulta analítica mais lenta e a sua tabela transacional mais disputada e perguntem, para cada coluna redundante, se a redundância foi escolhida com uma razão documentada ou se se infiltrou por acidente. O objetivo é uma regra escrita de quando a desnormalização é permitida e quem a aprova, não um concurso de pureza. Para organizações grandes ou reguladas, essa fronteira também decide onde os dados pessoais são duplicados, então uma desnormalização não documentada é ao mesmo tempo uma questão de desempenho e uma exposição de governança de dados que alguém um dia terá de explicar a um auditor.
Vocês devem construir ou comprar a camada semântica, e quem responde por manter atual cada definição de métrica depois que ela existir? Uma camada semântica só entrega uma fonte única da verdade quando é possuída e mantida, então a escolha da ferramenta importa menos que a resposta a quem revisa uma mudança no que “receita” significa e quem responde quando uma definição fica obsoleta. As considerações concorrentes são reais: construir dá controle e se ajusta à sua pilha mas acrescenta um fardo de engenharia, enquanto comprar uma ferramenta de métricas é mais rápido mas arrisca aprisionamento (lock-in) e uma linguagem de definição que vocês não controlam por completo. Levem o seu punhado de métricas de maior risco, as ferramentas que as consomem hoje e uma leitura honesta de se alguém hoje é dono dessas definições ou se elas simplesmente existem. Decidam de antemão se as definições vivem como código versionado, com donos nomeados e testes, porque uma camada semântica que ninguém mantém apodrece nas mesmas definições espalhadas que ela deveria substituir. Em relatórios corporativos e governamentais, em que uma métrica num painel público precisa ser rastreável a uma definição documentada e revisada, essa propriedade e a capacidade de provar a linhagem de um número é o que transforma a camada semântica de uma conveniência num controle auditável.

Perspectiva por setor

Startup. A modelagem pode esperar, mas as definições não. Com dois engenheiros e sem fôlego para construir um warehouse, ponham uma pequena camada semântica na sua ferramenta de transformação e definam as duas ou três métricas que o seu conselho de fato acompanha, “usuário ativo” e “receita”, uma só vez, como código testado. Pulem o data vault e os esquemas dimensionais elaborados: uma estrela enxuta e um punhado de definições governadas compram números consistentes sem frear a entrega. O ganho é que o preparo do conselho deixa de ser uma discussão sobre de quem é a consulta certa.

Pequena empresa. Vocês não têm modelador de dados nem orçamento para uma plataforma de métricas, então apoiem-se nas definições embutidas nas ferramentas que já operam e escrevam as poucas que importam num único documento compartilhado que todos leiam. Favoreçam comprar análises embutidas no seu software existente a montar um warehouse que vocês não conseguem manter com equipe. Onde modelarem, mantenham simples e nomeiem as coisas de modo consistente, porque quem mantiver aquilo no ano que vem pode ser quem não consegue lembrar por que “cliente” significava duas coisas. A consistência é mais barata que a reconciliação.

Grande empresa. O problema são muitas equipes e muitas ferramentas derivando para definições privadas, então invistam em dimensões conformadas, uma camada semântica governada e definições de métricas mantidas como código versionado, com donos e revisão. Padronizem a nomeação, as declarações de granularidade e as estratégias de dimensões de mudança lenta em todo o patrimônio para que um número numa ferramenta coincida com o mesmo número em outra. Tratem a camada semântica como um produto, com um roteiro e uma equipe dona, e meçam quanto tempo de reconciliação ela remove. O retorno são números confiáveis em todo o negócio e auditorias que rastreiam limpamente da apresentação ao conselho até a origem.

Governo. A transparência e a comparabilidade entre agências moldam o trabalho: dados de referência canônicos para geografia e demografia, definições governadas de indicadores centrais e metodologia publicada com lançamentos versionados para que o público possa rastrear qualquer número até uma definição documentada. As regras de contratação podem exigir que os seus modelos e definições permaneçam portáveis e neutros quanto a fornecedores, então evitem uma camada semântica presa a uma única ferramenta proprietária. Mantenham cada agência livre para modelar seus dados operacionais enquanto se conforma às dimensões compartilhadas para tudo que for reportado nacionalmente. Um indicador publicado que não pode ser rastreado a uma definição versionada é tanto uma falha de prestação de contas quanto uma falha de dados.

Exemplos

Startup. Uma empresa de Série A tinha três definições de “usuário ativo” vivendo em três lugares: a ferramenta de análise de produto, a planilha financeira e a apresentação aos investidores. Os números nunca batiam, e todo preparo do conselho virava uma correria. Dois engenheiros introduziram uma pequena camada semântica na ferramenta de transformação, definindo “usuário ativo” e “receita recorrente mensal” uma só vez como código testado, com as janelas e exclusões exatas escritas. Todo painel agora lê essas definições. A discussão do preparo do conselho desapareceu, e a integração de um novo analista passou de uma semana de conhecimento tribal para a leitura de um modelo documentado. Isso se liga diretamente à disciplina descrita no capítulo 7.4 (análises de produto e experimentação), onde uma definição estável de “ativo” é o que torna comparáveis os resultados dos experimentos.

Grande empresa. Uma varejista global rodava cinco ferramentas de inteligência de negócio entre marketing, finanças, cadeia de suprimentos, merchandising e lojas, e cada uma tinha reinventado a “margem bruta” de modo ligeiramente diferente. Construíram uma camada semântica sobre um warehouse no estilo Kimball com dimensões conformadas, de modo que “produto”, “loja” e “data” significassem a mesma coisa em toda tabela de fatos e toda ferramenta. Cada métrica era definida uma vez e consumida em toda parte. As reuniões de reconciliação que antes comiam dias por trimestre em sua maioria sumiram, e quando as finanças mudaram como as devoluções afetavam a margem, a mudança se propagou às cinco ferramentas de uma vez. As dimensões conformadas foram o que permitiu a equipes independentes juntar seus dados com confiança em vez de suspeita.

Governo. Um governo nacional precisava de relatórios comparáveis entre as agências de saúde, trabalho e educação, cada uma das quais historicamente definia “domicílio”, “região” e “emprego” do seu jeito. Um órgão interagências estabeleceu dados de referência compartilhados e definições padrão: tabelas de dimensões canônicas para geografia e demografia e definições governadas de indicadores centrais, publicadas com metodologia e lançamentos versionados. As agências individuais modelam seus próprios dados operacionais mas se conformam às dimensões e definições compartilhadas para tudo que for reportado nacionalmente. O resultado é que um número de uma agência pode ser comparado com o de outra com honestidade, e o público pode rastrear qualquer indicador publicado até uma definição documentada, apoiando as obrigações de transparência cobertas no capítulo 7.1.

Justificativa de negócio: motivações, ROI e TCO

O retorno de uma boa modelagem e de uma camada semântica é, em sua maior parte, tempo recuperado e erro evitado. Em muitas organizações, os analistas gastam a maior parte do tempo achando dados, reconciliando números conflitantes e reconstruindo definições que outras pessoas já escreveram. Uma única definição governada de cada métrica transforma esse trabalho repetido num investimento único. Também remove uma categoria inteira de falha cara: o número errado numa apresentação ao conselho, o número relatado errado que dispara um achado de auditoria, o projeto de reconciliação de um trimestre que só existe porque duas equipes definiram “receita” de modo diferente. Quando a definição vive num único lugar revisado, essas falhas em grande parte deixam de acontecer.

O custo é real e vale nomeá-lo. Vocês investem de antemão em modelagem conceitual e lógica, em construir e popular a camada semântica e na propriedade contínua que mantém as definições atuais. O custo total de propriedade (TCO) inclui as ferramentas, o tempo de modelagem e de engenharia analítica e a governança para impedir que o modelo derive. Pesem isso contra o custo de não fazê-lo, que é maior mas escondido: aparece como pipelines duplicados, analistas como motores humanos de reconciliação e executivos tomando decisões confiantes com números que ninguém consegue defender. Defendam o caso junto à liderança nos termos dela. Uma definição confiável de cada métrica é o que permite comparar todo o negócio, confiar nos painéis e responder aos reguladores sem um alarme de incêndio. Comecem onde a dor da reconciliação é pior, definam essas poucas métricas uma só vez e deixem o tempo recuperado financiar o resto.

Antipadrões e armadilhas

Saltar direto para tabelas físicas, assando a tecnologia de hoje em decisões que deveriam durar mais.
Definir a mesma métrica de forma independente em cada painel, de modo que dois números nunca concordam.
Deixar a granularidade sem declarar e depois descobrir medidas contadas em dobro num relatório de receita.
Desnormalizar tabelas analíticas por acidente em vez de por decisão documentada.
Normalizar um warehouse analítico até que toda consulta seja uma junção de doze tabelas que ninguém entende.
Tratar as dimensões de mudança lenta por sobrescrita, de modo que os relatórios históricos reescrevem o passado em silêncio.
Usar chaves naturais em toda parte, de modo que uma mudança de chave num sistema de origem se propaga por todo o warehouse.
Construir uma camada semântica sem dono, de modo que as definições derivam e a confiança se erode.
Tratar o modelo como concluído no lançamento em vez de um ativo vivo que precisa permanecer evolutivo.

Modelo de maturidade

Nível 1, Iniciar: A modelagem é implícita e reativa. As tabelas são projetadas com o físico primeiro por quem precisar delas. As métricas são redefinidas em cada relatório e os números rotineiramente conflitam. A granularidade não é documentada e ninguém é dono das definições.
Nível 2, Desenvolver: Algumas tabelas analíticas seguem um padrão dimensional e algumas métricas-chave têm definições escritas, mas vivem numa wiki e não são impostas. As convenções de nomeação existem no papel. A prática varia de equipe para equipe, e a reconciliação ainda é frequente e manual.
Nível 3, Padronizar: Os modelos conceitual, lógico e físico são distintos e revisados. Uma camada semântica define as métricas centrais uma só vez, como código versionado, com donos. As dimensões conformadas permitem que as equipes juntem dados com segurança. A granularidade e as estratégias de dimensões de mudança lenta são documentadas e impostas na revisão em toda a organização.
Nível 4, Gerenciar: O patrimônio de modelos é medido contra linhas de base. Vocês acompanham a cobertura de definições de métricas (a fração das métricas reportadas atendidas pela camada semântica), a contagem de definições duplicadas ou paralelas ainda em uso, as horas de reconciliação gastas por trimestre e a taxa de defeitos de granularidade e de linhagem pegos na revisão versus em produção. As mudanças de definição fluem por pull requests revisados com testes, e a atualidade, as taxas de aprovação de testes e a deriva são vigiadas em painéis. Quando uma métrica diverge ou uma dimensão deixa de se conformar, a medição a revela antes de uma reunião do conselho.
Nível 5, Orquestrar: Toda métrica importante tem uma definição governada consumida por todas as ferramentas e equipes, e a camada semântica é integrada às análises, à experimentação e aos relatórios regulados. Os modelos são evolutivos por projeto e continuamente refinados; as definições são confiáveis em toda a organização; o trabalho de reconciliação em grande parte desapareceu. A organização rotineiramente descontinua, redefine o escopo e conforma novas dimensões conforme o negócio muda, reequilibrando o patrimônio de modelos como um ativo adaptativo.

Ideias para discussão

Escolham as suas três métricas mais importantes. Quantas definições distintas de cada uma existem hoje entre as suas ferramentas, e o que seria preciso para colapsá-las numa?
Onde uma granularidade não declarada causou um erro real de relatório, e quanto tempo levou para notar?
Quais das suas dimensões devem ser conformadas primeiro entre as equipes, e quem é dono delas?
As suas definições de métricas estão em controle de versões com revisão, ou podem ser editadas em silêncio dentro de uma ferramenta de BI?
Quando foi a última vez que uma dimensão de mudança lenta reescreveu a sua história sem ninguém notar, e como vocês a pegariam da próxima vez?
Se vocês trocassem o motor do seu warehouse amanhã, quanto do significado do seu modelo sobreviveria à mudança?

Principais conclusões

Modelar dados é decidir o que eles significam, e esse significado sobrevive a toda tecnologia de armazenamento que vocês escolherem.
Modelem em três níveis, em ordem: primeiro o conceitual, depois o lógico, depois o físico.
Normalizem os sistemas transacionais pela correção. Desnormalizem os analíticos deliberadamente pela velocidade.
Usem a modelagem dimensional, com fatos, dimensões e uma granularidade declarada, para as análises.
Construam uma camada semântica para que toda métrica de negócio tenha uma única definição governada em toda parte.
As dimensões conformadas permitem que equipes independentes juntem e comparem seus dados com confiança.
Nomeiem bem, documentem, usem chaves substitutas e versionem as definições para que o modelo permaneça evolutivo.

Referências e leitura complementar

Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modelling.
Bill Inmon, Building the Data Warehouse.
Dan Linstedt and Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
Peter Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” ACM Transactions on Database Systems.
E. F. Codd, “A Relational Model of Data for Large Shared Data Banks,” Communications of the ACM.
C. J. Date, An Introduction to Database Systems.
Lars Rönnbäck and colleagues, writings on anchor modelling.
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.