01. Arquitetura e modelagem de dados

Imagine uma empresa na qual vendas, atendimento e financeiro chamam a mesma pessoa por identificadores diferentes. Antes de criar tabelas, é preciso entender o significado dos dados, seu percurso e as regras que os mantêm confiáveis.

O percurso começa pela representação do mundo real. Primeiro entendemos a arquitetura e os níveis de modelagem; depois construímos o modelo relacional, protegemos sua integridade e aprendemos SQL. Ao final, levamos essa base para o ambiente analítico dimensional. Este é o capítulo 1 de 12 da disciplina Modelagem de Dados e SQL. Ele abre a sequência e estabelece o vocabulário necessário para os próximos capítulos. Depois, seguiremos para Modelagem de dados: conceitual, lógica e física.

O fio condutor

Banco de dados deve ser estudado como um sistema de decisões conectadas. O significado atribuído ao dado orienta o modelo; o modelo condiciona consultas e atualizações; o SGBD executa essas operações sob regras de segurança, concorrência, desempenho e recuperação. Quando uma dessas camadas muda, as demais podem ser afetadas.

Ao longo da leitura, acompanhe sempre quatro perguntas: qual problema está sendo resolvido, qual estrutura representa o problema, que garantia precisa ser preservada e qual custo acompanha a escolha. Esse roteiro ajuda a compreender os conceitos em vez de apenas memorizar nomes.

O que a arquitetura de dados abrange

Começamos por O que a arquitetura de dados abrange, pois essa base permite compreender as decisões apresentadas nas seções seguintes.

Arquitetura de dados é o conjunto de princípios, modelos, fluxos, plataformas, integrações, controles de segurança e regras de governança que descreve como o dado nasce, circula e é consumido na organização. Ela conecta a necessidade do negócio ao ciclo de vida do dado em vários sistemas — não é sinônimo de "desenho de tabelas", que é apenas uma parte dela.

Duas categorias de dado aparecem nesse recorte e são cobradas pelo nome. Dados mestres representam entidades compartilhadas e centrais, como cliente, produto e fornecedor; para terem uma visão confiável, dependem de governança, correspondência entre registros (matching), regras de sobrevivência do valor vencedor e identificadores estáveis. Dados de referência são domínios padronizados — códigos de país, de moeda, de situação — que exigem autoridade única e versionamento para não divergirem entre sistemas.

Mudar estrutura em produção é decisão de arquitetura, não detalhe operacional: alterar uma coluna pode, sim, quebrar aplicações consumidoras. O que reduz o risco é contrato de dados explícito e implantação gradual — adicionar a coluna nova, migrar leitores, só então remover a antiga.

Repare como Princípios e modelos, Fluxos, plataformas e integração, Segurança e governança participam da mesma decisão. Ao relacionar esses elementos, fica mais fácil prever o comportamento do banco e reconhecer os efeitos de cada escolha.

Conceitual, lógico e físico

A seção anterior apresentou O que a arquitetura de dados abrange. Agora chegamos a Conceitual, lógico e físico, que acrescenta a próxima peça do mesmo raciocínio.