Em muitos projetos, “modelagem” e “arquitetura” de dados viram sinônimos em reunião. Uma define a forma dos dados; a outra, o caminho que eles percorrem até virar decisão. Confundir as duas produz sistemas bem desenhados que não conversam com nada.

O que a modelagem de dados resolve

A modelagem de dados decide o que um sistema vai guardar e como cada informação se liga às outras. Ela trabalha com entidades, atributos, relacionamentos e regras de integridade. Na prática, responde perguntas como quais campos são obrigatórios e o que impede dois cadastros do mesmo cliente.

Pense numa loja virtual. As entidades óbvias são cliente, pedido e produto. Um cliente pode ter vários pedidos, e cada pedido reúne um ou mais produtos de alguma categoria. Parece simples até alguém perguntar se um pedido pode existir sem cliente, ou o que acontece com o histórico quando um produto sai de linha, e a resposta a cada pergunta vira uma regra no modelo.

O trabalho costuma passar por três níveis, cada um mais perto da tecnologia que o anterior. A divisão abaixo segue a descrição da AWS:

Nível

O que representa

Quem participa

Conceitual

Entidades e relações em alto nível, na linguagem do negócio

Áreas de negócio fornecem os insumos

Lógico

Atributos, chaves e restrições, sem depender de um banco específico

Arquitetos de dados e analistas de negócio

Físico

Tabelas, tipos de dados, índices e procedimentos do banco escolhido

Desenvolvedores e DBAs

No exemplo da loja, o modelo conceitual diz apenas que o cliente faz pedidos. O lógico define que o pedido guarda data, valor e o identificador do cliente. Já o físico vira um CREATE TABLE em PostgreSQL ou SQL Server, com índice na coluna que mais aparece nas consultas.

O alcance da modelagem termina na fronteira do banco. De onde os dados chegam e quem vai consumi-los depois são perguntas de outra disciplina.

O que a arquitetura de dados resolve

A arquitetura de dados cuida do percurso. Ela define de onde os dados vêm, como chegam ao ambiente analítico, onde ficam guardados, quem pode acessá-los e de que jeito viram relatório, alerta ou modelo de IA. O escopo é a organização inteira, e não um banco isolado.

O DAMA-DMBOK, guia de referência em gestão de dados, trata as duas como áreas de conhecimento separadas. No framework, a arquitetura se ocupa dos fluxos de dados e das cadeias de valor, enquanto a modelagem traduz requisitos em modelos.

Uma arquitetura moderna costuma se organizar em camadas:

Camada

Função

Exemplos de tecnologia

Fontes

Onde o dado nasce

ERP, CRM, APIs, sensores, aplicativos

Ingestão

Captura e transporte

Apache Kafka, Azure Data Factory, Apache NiFi

Armazenamento

Persistência bruta e tratada

Amazon S3, Azure Data Lake Storage, Snowflake, BigQuery

Processamento

Limpeza, cruzamento e cálculo

Apache Spark, Apache Flink, Databricks

Consumo

Onde alguém usa o resultado

Power BI, aplicações internas, APIs, modelos de IA

Por cima de todas as camadas ficam decisões que não aparecem em nenhum diagrama de tabelas: quem é dono de cada dado, por quanto tempo ele fica retido, como cada acesso é registrado e o que a LGPD exige em cada etapa.

Voltando à loja virtual, a modelagem garantiu que o pedido tenha cliente, data e valor. A arquitetura cuida de levar esse pedido do sistema de vendas até o painel do diretor comercial, cruzado com os dados de estoque, antes da reunião de segunda-feira.

Modelagem e arquitetura de dados não são a mesma coisa

A modelagem trabalha dentro de um sistema; a arquitetura, na organização inteira.

As duas disciplinas lado a lado

A modelagem de dados se parece com o projeto de um prédio, que define quantos andares ele terá, onde fica cada sala e quais paredes sustentam a estrutura. É um trabalho de detalhe, e um erro na planta costuma aparecer logo nas primeiras rachaduras.

A arquitetura de dados é o planejamento da cidade em volta desse prédio. Envolve as ruas que levam até a portaria, a rede elétrica, o abastecimento de água e a ligação entre os bairros. Um prédio impecável num terreno sem acesso fica vazio, e uma cidade bem traçada cheia de prédios mal construídos vive em obra.

Aspecto

Modelagem de dados

Arquitetura de dados

Foco

Estrutura da informação

Fluxo e uso da informação

Escopo

Um sistema ou banco

A organização inteira

Entregáveis

Modelos conceitual, lógico e físico; dicionário de dados

Desenho de camadas, pipelines, políticas de acesso e retenção

Quem conduz

Analistas, engenheiros de dados e DBAs

Arquitetos de dados

Pergunta central

Como representar o negócio nos dados?

Como os dados circulam e geram valor?

Na prática, as fronteiras se misturam. Em equipes pequenas, a mesma pessoa desenha o modelo pela manhã e monta o pipeline à tarde. Vale saber qual chapéu está usando em cada momento, porque as perguntas certas e os erros típicos mudam de um papel para o outro.

Um exemplo com câmeras inteligentes

Um sistema de videomonitoramento com reconhecimento facial ajuda a ver as duas disciplinas trabalhando no mesmo projeto.

A modelagem define as entidades e as regras entre elas:

• câmera, com localização e situação de funcionamento

• pessoa de interesse, com os dados que permitem a comparação

• alerta, que liga uma pessoa a uma câmera num instante preciso

É nesse nível que se decide, por exemplo, que todo alerta precisa de uma câmera de origem registrada e que uma pessoa retirada da lista de interesse deixa de gerar alertas.

A arquitetura desenha o caminho que uma imagem percorre até virar decisão:

1.  A câmera captura a imagem e publica o evento numa fila, como Apache Kafka ou Azure Event Hubs.

2. Um motor de IA compara o rosto com a lista de interesse.

3. As correspondências viram registros na base de alertas.

4. A central de monitoramento recebe o alerta e decide como agir.

5. Painéis analíticos consolidam o histórico para a gestão.

Em volta desse fluxo, a arquitetura também define quanto tempo cada imagem fica guardada, quem pode consultar os alertas e como cada acesso é registrado para auditoria. Num sistema que lida com imagens de pessoas, essas regras pesam tanto quanto a precisão do algoritmo.

Quando falta uma das duas

Os problemas mais comuns aparecem quando uma organização investe pesado numa disciplina e trata a outra como detalhe.

Com bom modelo e pouca arquitetura, cada sistema tem um banco limpo e bem normalizado. O financeiro confia nos seus números, o comercial confia nos dele, e os dois não batem. Para montar um relatório consolidado, alguém exporta planilhas toda segunda-feira e cruza tudo à mão. Os sintomas costumam ser:

• dados isolados por área

• integrações feitas às pressas, ponto a ponto

• o mesmo cliente cadastrado em três sistemas com grafias diferentes

O cenário oposto é tão comum quanto. A empresa monta um data lake, contrata uma ferramenta de orquestração e conecta dezenas de fontes. Os pipelines rodam em minutos, mas transportam campos que mudam de significado de um sistema para outro e chaves duplicadas, então o painel recebe rápido um número errado.

Nos dois casos, a saída é responder às perguntas da camada que ficou para trás, e comprar outra ferramenta raramente ajuda.

Antes do próximo projeto de dados, vale fazer dois testes. O primeiro é verificar se existe um modelo que explique, na linguagem do negócio, o que cada entidade significa. O segundo é pedir a alguém da equipe que desenhe num quadro branco o caminho de um dado, da origem até a decisão. O teste que falhar mostra por qual das duas disciplinas o projeto precisa começar.

  • Compartilhe esse post

Discussão e Comentários

Olá, deixe seu comentário para Modelagem e arquitetura de dados não são a mesma coisa

Enviando Comentário Fechar :/