É exatamente para estruturar esse fluxo que existem frameworks arquiteturais como o Medallion (Bronze, Silver, Gold) e o modelo SOR, SOT, SPEC. Na prática, ambos descrevem a mesma jornada de amadurecimento do dado, mas com origens e focos ligeiramente diferentes.

A Arquitetura Medallion (Bronze, Silver, Gold)

O conceito foi introduzido pela equipe da Databricks (liderada por nomes como Ali Ghodsi, CEO e cofundador) por volta de 2020 junto com o conceito de Data Lakehouse, a arquitetura Medallion foca no estado de qualidade e refinamento dos arquivos e tabelas dentro de um pipeline de Big Data.

A analogia é simples: o dado entra bruto e vai sendo “lapidado” até virar ouro.

Camada Bronze (Raw / Bruta): É a zona de aterrissagem. Os dados chegam aqui exatamente no mesmo formato dos sistemas de origem (APIs, ERPs, CRMs, logs), sem nenhuma alteração.

Objetivo: Manter o histórico imutável. Se houver um erro no processamento futuro, você sempre pode voltar à camada Bronze e reprocessar o dado original.

Camada Silver (Cleansed / Conformed): É onde a faxina acontece. Os dados da Bronze são lidos, filtrados, padronizados (ex: transformar todas as datas para o formato YYYY-MM-DD), desduplicados e têm seus tipos de dados corrigidos.

Objetivo: Criar uma base de dados limpa, integrada e confiável que representa a operação da empresa, pronta para exploração por analistas e cientistas de dados.

Camada Gold (Curated / Aggregated): É a camada de negócio. Aqui, os dados da Silver são agregados, somados e cruzados para responder a perguntas específicas (ex: “Total de vendas por região por mês”).

Objetivo: Entregar dados altamente otimizados e prontos para consumo por ferramentas de BI (Tableau, Power BI, Metabase) ou modelos de Machine Learning.

O Modelo SOR, SOT e SPEC

Enquanto o Medallion nasceu no mundo do Big Data e processamento em nuvem, a nomenclatura SOR, SOT e SPEC tem raízes mais profundas na Governança de Dados clássica e em arquiteturas de Data Warehousing (como as de Ralph Kimball e Bill Inmon). O termo ganhou força com Bill Inmon (conhecido como o “Pai do Data Warehouse. O foco aqui é a confiabilidade e o propósito do dado.

SOR (System of Record – Sistema de Registro): É a origem do dado. Em arquitetura de dados, representa a camada onde a informação é armazenada de forma bruta e fidedigna ao sistema transacional que a gerou.

Equivalência: É a representação lógica da camada Bronze.

SOT (Source of Truth / Single Source of Truth – Fonte Única da Verdade): É o coração da governança. É a camada onde as discrepâncias entre diferentes sistemas foram resolvidas. Se o sistema de Vendas diz que o cliente é “João S.” e o sistema de Entregas diz “João Silva”, a SOT resolve esse conflito e consolida o dado oficial da empresa.

Equivalência: É a representação lógica da camada Silver.

SPEC (Specific / System of Engagement – Específico): São as visões de dados criadas para propósitos específicos de um departamento ou caso de uso. O RH não quer ver a base inteira da empresa; ele quer um conjunto de dados focado em métricas de contratação e turnover (um Data Mart).

Equivalência: É a representação lógica da camada Gold.

Qual a diferença real entre eles?

A diferença não está na tecnologia ou no fluxo (ambos usam pipelines de extração, limpeza e agregação), mas sim na filosofia e no vocabulário adotado pela equipe.

Na prática das empresas modernas, esses termos frequentemente se misturam. Um Arquiteto de Dados pode perfeitamente desenhar um pipeline dizendo: “Vamos usar a camada Silver do nosso Data Lake como a nossa Source of Truth (SOT) corporativa”.

Se você abrir o banco de dados de uma empresa madura, a tabela que o engenheiro chama de “Silver” é a exata mesma tabela que o time de governança chama de “SOT” (Source of Truth).

A diferença não está na tecnologia ou no fluxo dos dados. A diferença está na perspectiva de quem está olhando e no vocabulário usado para resolver problemas diferentes.

Pense nisso como duas “lentes” para olhar o mesmo funil de dados: a lente da Engenharia e a lente do Negócio/Governança.

Lente 1: Medallion (A Visão da Engenharia)

O Medallion (Bronze, Silver, Gold) foca no estado de processamento e qualidade do dado. É o vocabulário de quem “põe a mão na massa” (Engenheiros de Dados, Arquitetos Cloud).

• A pergunta que ele responde: “O quanto de código, limpeza e transformação nós já rodamos nesse dado?”
• Na prática: Você usa esses termos em reuniões técnicas.
  • Exemplo: “A pipeline deu erro porque o arquivo JSON que chegou na Bronze veio corrompido, então o script do Spark não conseguiu limpar e jogar para a Silver.”

Lente 2: SOR, SOT, SPEC (A Visão do Negócio e Governança)

O SOR/SOT/SPEC foca na confiabilidade, auditoria e autoridade do dado. É o vocabulário de quem consome o dado e toma decisões de negócio (Diretores, Analistas de Negócio, Auditores, Data Stewards).

• A pergunta que ele responde: “Eu posso confiar nesse número para apresentar para o conselho diretivo? Quem é o dono dessa informação?”
• Na prática: Você usa esses termos em reuniões de alinhamento estratégico ou resolução de conflitos.
  • Exemplo: “O dashboard de Vendas e o de Finanças estão mostrando faturamentos diferentes. Precisamos definir que a tabela X do Data Warehouse será a nossa SOT (Fonte Única da Verdade) para o faturamento global da empresa.”

Quando usar um vocabulário no lugar do outro?

Aqui está a regra de ouro para o seu dia a dia profissional: Você não escolhe um modelo em detrimento do outro, você os usa simultaneamente dependendo com quem está falando.

Veja como os dois mundos se mapeiam perfeitamente na mesma infraestrutura:

Resumo:

• Você fala Bronze, Silver e Gold quando está discutindo com outro desenvolvedor sobre como o código vai transformar o arquivo.
• Você fala SOR, SOT e SPEC quando o Diretor pergunta: “De onde veio esse número e por que eu deveria confiar nele?”.

O post Arquitetura Medallion (Bronze, Silver, Gold) x Modelo SOR, SOT e SPEC apareceu primeiro em Data Universe.

Imagine um restaurante. Num monólito, existe um único chef que anota o pedido, cozinha, serve e lava a louça, tudo numa cozinha só. É simples, eficiente para começar, mas se o chef adoecer, o restaurante para.

Num sistema de microserviços, há especialistas: um maître, um garçom, um grelheiro, um confeiteiro e um lavador de louças, cada um faz sua parte de forma independente, se comunicando para entregar o prato ao cliente. Mais complexo de coordenar, mas muito mais resiliente e escalável.

O Monólito: A “Cozinha de um único Chef”

No modelo monolítico, toda a aplicação é construída como uma unidade única e indivisível. Todas as funções (pedidos, pagamentos, estoque, entrega) estão no mesmo código, rodam no mesmo servidor e compartilham o mesmo banco de dados.

Como funciona na prática: Imagine um pequeno restaurante onde o mesmo chef recebe o pedido, cozinha, lava a louça e faz o caixa.

Repare que os três módulos internos vivem dentro do mesmo processo. Um bug em “Acesso a dados” pode derrubar a “Apresentação”. Um deploy de qualquer módulo exige redeployar o sistema inteiro.

Vantagens do monólito:

É muito simples de começar. É fácil de testar e colocar no ar (deploy), pois é apenas um “pacote”.

• Simples de desenvolver no início um único projeto, uma única base de código
• Fácil de testar localmente
• Sem latência de rede entre módulos (chamadas são em memória)
• Deploy simples: um artefato, um servidor

Desvantagens do monólito:

Se o restaurante lota e você precisa de mais agilidade na cozinha, você não consegue contratar “apenas um cozinheiro”. Você teria que clonar o restaurante inteiro (com caixa, pia e balcão novos) só para fritar mais batatas. Se o chef tropeça e se machuca, o restaurante inteiro para.

• Qualquer falha pode derrubar tudo
• Escalar exige replicar a aplicação inteira, mesmo que só uma parte precise de mais recursos
• Times grandes brigam pela mesma base de código
• Com o tempo, o código fica acoplado e difícil de manter (o famoso “big ball of mud”)

Microsserviços: A “Praça de Alimentação”

Na arquitetura de microsserviços, a aplicação é dividida em vários pequenos serviços independentes que se comunicam entre si (geralmente via APIs ou Mensageria). Cada serviço cuida de uma única função de negócio e pode ter seu próprio banco de dados e tecnologia.

Eles se comunicam via HTTP/REST, gRPC ou mensageria (Kafka, RabbitMQ).

Como funciona na prática: Imagine uma praça de alimentação. Existe um quiosque só para Bebidas, um só para Hambúrgueres e um Totem central para Pagamentos.

Cada serviço é completamente independente. O serviço de Pedidos pode cair sem afetar o de Produtos. Você pode escalar só o serviço de Pagamentos em datas como Black Friday, sem tocar nos outros.

Vantagens dos microserviços:

Se a demanda por hambúrgueres aumenta, você coloca mais chapas apenas naquele quiosque, sem mexer no setor de bebidas. Se o sistema de bebidas der erro, as pessoas ainda conseguem comprar comida e pagar.

• Escalabilidade granular: escale só o que precisa
• Falhas são isoladas: um serviço cai sem derrubar os outros
• Times podem trabalhar de forma independente em serviços diferentes
• Cada serviço pode usar a linguagem e o banco de dados mais adequados para seu problema
• Deploy independente por serviço

Desvantagens dos microserviços:

Agora você precisa de uma logística complexa para que os pedidos cheguem corretamente de um quiosque ao outro. A comunicação entre os serviços é o ponto mais difícil de gerenciar.

• Complexidade operacional muito maior (Kubernetes, service mesh, monitoramento distribuído)
• Latência de rede nas chamadas entre serviços
• Transações distribuídas são difíceis (não tem BEGIN TRANSACTION entre bancos diferentes)
• Debugging é mais difícil: um erro pode atravessar 5 serviços
• Overhead de infraestrutura significativo

Comparativo Direto

O ponto crítico que ninguém conta: A falácia do “começa com microserviços”

Um erro clássico é começar um projeto novo já com microserviços. O problema é que você ainda não sabe onde estão as fronteiras naturais do seu domínio. Martin Fowler chama isso de “distributed monolith”: você tem toda a complexidade dos microserviços, sem nenhum dos benefícios os serviços ficam tão acoplados que um deploy de um exige deploy de todos os outros.

A abordagem recomendada é começar com um monólito bem estruturado e extrair microserviços conforme a necessidade real aparecer.

Qual escolher?

• Escolha Monólito se: Você está criando um MVP (Produto Mínimo Viável), tem uma equipe pequena ou a aplicação não é absurdamente complexa. Dica: Comece como um “Monólito Modular” bem organizado.
• Escolha Microsserviços se: Sua aplicação é gigante (nível Netflix, Uber ou Nubank), você tem dezenas de times de desenvolvedores e precisa escalar partes diferentes do sistema de forma independente.

Existe uma heurística simples que resume bem quando migrar:

Fique no monólito enquanto: O time for pequeno, o produto ainda estiver buscando product-market fit, ou você conseguir deployar sem travar outros times.

Considere microserviços quando: Times diferentes estão se bloqueando para deployar, uma parte do sistema tem exigências de escala radicalmente diferentes das outras (ex: serviço de busca vs serviço de autenticação), ou a resiliência de partes críticas vira um requisito de negócio.

Netflix, Amazon e Uber não começaram com microserviços, todos começaram como monólitos e migraram conforme a necessidade. Isso diz muito sobre a ordem certa de fazer as coisas.

O post Monólitos x Microserviços apareceu primeiro em Data Universe.

Para resolver isso, utilizamos as Views (ou Visões).

O que é uma View?

Uma view (ou visão) é uma tabela virtual criada a partir de uma consulta SQL. Ela não armazena dados por si mesma, em vez disso, é uma “janela” que sempre exibe o resultado de uma query pré-definida, como se fosse uma tabela real.

Pense em uma view como um atalho salvo para uma consulta complexa. Quando você consulta uma view, o banco de dados executa a query por trás dela e retorna o resultado, como se você estivesse consultando uma tabela comum.

Veja como uma view se posiciona na arquitetura de um banco de dados:

Por que criar uma view?

1. Simplicidade e reutilização

Queries longas e com muitos JOINs podem ser encapsuladas em uma view e reutilizadas em vários lugares, sem repetição de código.

2. Segurança e controle de acesso

Views permitem expor apenas os dados que um usuário ou sistema pode ver, sem dar acesso direto às tabelas.

3. Abstração e manutenção

Se a estrutura do banco mudar, você atualiza apenas a view — as aplicações que a consomem não precisam saber o que mudou por baixo.

Como criar uma view: Exemplos práticos

Exemplo 1 — Criando uma view simples

-- Criando uma view simples
CREATE VIEW resumo_clientes AS
SELECT
    c.id,
    c.nome,
    COUNT(p.id) AS total_pedidos,
    SUM(p.valor) AS valor_total
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
GROUP BY c.id, c.nome;

-- Consultando a view como se fosse uma tabela
SELECT * FROM resumo_clientes WHERE valor_total > 1000;

-- Criando uma view simples
CREATE VIEW resumo_clientes AS
SELECT
    c.id,
    c.nome,
    COUNT(p.id) AS total_pedidos,
    SUM(p.valor) AS valor_total
FROM clientes c
LEFT JOIN pedidos p ON p.cliente_id = c.id
GROUP BY c.id, c.nome;

-- Consultando a view como se fosse uma tabela
SELECT * FROM resumo_clientes WHERE valor_total > 1000;

Exemplo 2 — relatório de vendas por mês:

CREATE VIEW vendas_mensais AS
SELECT
    DATE_TRUNC('month', data_pedido) AS mes,
    COUNT(*) AS quantidade_pedidos,
    SUM(total) AS receita_total,
    AVG(total) AS ticket_medio
FROM pedidos
WHERE status = 'concluido'
GROUP BY DATE_TRUNC('month', data_pedido)
ORDER BY mes DESC;

-- Uso:
SELECT * FROM vendas_mensais WHERE mes >= '2024-01-01';

CREATE VIEW vendas_mensais AS
SELECT
    DATE_TRUNC('month', data_pedido) AS mes,
    COUNT(*) AS quantidade_pedidos,
    SUM(total) AS receita_total,
    AVG(total) AS ticket_medio
FROM pedidos
WHERE status = 'concluido'
GROUP BY DATE_TRUNC('month', data_pedido)
ORDER BY mes DESC;

-- Uso:
SELECT * FROM vendas_mensais WHERE mes >= '2024-01-01';

Neste vídeo, falo sobre como criar uma View no phpMyAdmin para otimizar consultas no banco de dados de forma simples e eficiente:

Materialized Views: Quando performance importa

Views comuns executam a query toda vez que são consultadas. Para queries muito pesadas, existe o conceito de materialized view, que armazena fisicamente o resultado e pode ser atualizada periodicamente.

-- PostgreSQL: criando uma materialized view
CREATE MATERIALIZED VIEW estatisticas_diarias AS
SELECT
    DATE(criado_em) AS dia,
    COUNT(*) AS novos_usuarios,
    SUM(receita) AS receita_do_dia
FROM eventos
GROUP BY DATE(criado_em);

-- Atualizando os dados armazenados
REFRESH MATERIALIZED VIEW estatisticas_diarias;

-- PostgreSQL: criando uma materialized view
CREATE MATERIALIZED VIEW estatisticas_diarias AS
SELECT
    DATE(criado_em) AS dia,
    COUNT(*) AS novos_usuarios,
    SUM(receita) AS receita_do_dia
FROM eventos
GROUP BY DATE(criado_em);

-- Atualizando os dados armazenados
REFRESH MATERIALIZED VIEW estatisticas_diarias;

É importante conhecer essa diferença, especialmente se você trabalha com grandes volumes de dados:

• View Comum: É apenas um “atalho”. Toda vez que você a chama, o banco executa o SELECT original. Se a tabela base mudar, a View reflete a mudança na hora.
• Materialized View (View Materializada): Muito comum em Data Warehouses (como Snowflake, Oracle ou Redshift). Ela salva o resultado da consulta fisicamente no disco.
  • Vantagem: É infinitamente mais rápida para leitura em tabelas gigantes.
  • Desvantagem: Os dados podem ficar desatualizados (é necessário dar um “refresh” manual ou agendado para atualizar os dados).

Qual é a diferença entre uma View, um Tabela e uma consulta AD-HOC?

• Tabelas: São estruturas físicas que armazenam dados diretamente no banco. Elas são a base de qualquer banco de dados relacional.
• Views: São consultas armazenadas que não armazenam dados por si mesmas, servindo como uma camada de abstração para facilitar o acesso a informações complexas.
• Consultas ADHOC: Uma consulta SQL que é executada de forma esporádica ou para responder a uma necessidade específica, sem estar previamente salva como uma view ou estrutura fixa.

💡 Quando usar uma View?
Se você deseja simplificar consultas, ocultar dados sensíveis ou organizar melhor as informações sem criar cópias dos dados.

💡 Quando usar uma Tabela?
Sempre que precisar armazenar dados de forma persistente e garantir que sejam acessados com alta performance.

💡 Quando usar uma Consulta ADHOC?
Sempre que precisar responder alguma pergunta temporária que não precisa ser consumida posteriormente

O post Views e Materialized Views em Bancos de Dados apareceu primeiro em Data Universe.

A Analogia Clássica: O Índice de um Livro

Imagine que você está lendo um livro de História de 1.000 páginas e quer encontrar todas as menções a “Júlio César”.

• Sem um índice (Full Table Scan): Você teria que ler o livro inteiro, da página 1 à 1.000, procurando o nome. No banco de dados, isso se chama Full Table Scan (Varredura Completa da Tabela), e é o pior cenário para a performance.
• Com um índice (Index Scan): Você vai até as últimas páginas do livro, no Índice Remissivo, procura a letra “J”, acha “Júlio César” e vê que ele é citado nas páginas 45, 112 e 890. Você vai direto a essas páginas.

Um índice de banco de dados faz exatamente isso: ele cria uma estrutura de dados separada (geralmente uma árvore chamada B-Tree) que mantém os valores de uma coluna específica ordenados, junto com um “ponteiro” (o número da página) que diz exatamente onde a linha inteira está gravada no disco.

O Preço a se Pagar (Trade-offs)

Se os índices deixam tudo mais rápido, por que não colocamos índices em todas as colunas de todas as tabelas?

Porque índices não são mágicos; eles têm um custo.

1. Overhead de Escrita (Lentidão no CRUD): Toda vez que você faz um INSERT, UPDATE ou DELETE na tabela, o banco de dados precisa atualizar a tabela principal E reorganizar a estrutura do índice. Muitos índices deixam as gravações muito lentas.
2. Consumo de Disco: O índice é uma cópia ordenada dos dados daquela coluna. Ele ocupa espaço físico no servidor. Um banco de dados super indexado pode ter seus índices ocupando mais gigabytes do que os próprios dados reais.

Quando Usar (e Quando NÃO Usar) Índices

A arte da otimização de banco de dados está em saber equilibrar a balança entre a velocidade de leitura e o custo de escrita.

Onde você DEVE criar índices:

• Chaves Primárias (PK) e Estrangeiras (FK): (Bancos relacionais geralmente criam o índice da PK automaticamente). Essencial para que os JOINs entre tabelas sejam rápidos.
• Colunas muito usadas no WHERE: Se você pesquisa clientes pelo CPF o tempo todo, a coluna cpf precisa de um índice.
• Colunas usadas em ORDER BY ou GROUP BY: Como o índice já guarda os dados de forma ordenada, o banco não gasta processamento extra para ordenar o resultado.

Onde você NÃO DEVE criar índices:

• Tabelas muito pequenas: Se a tabela tem 500 linhas, o banco lê tudo em milissegundos. O índice só gastaria espaço.
• Colunas de Baixa Cardinalidade: Colunas com poucos valores distintos, como sexo (M/F) ou status (Ativo/Inativo). O índice não ajuda a filtrar muita coisa e o banco pode acabar optando pelo Full Table Scan de qualquer jeito.
• Tabelas com altíssimo volume de inserção (Logs): Se uma tabela recebe milhares de INSERTS por segundo e é pouco lida, um índice vai criar um gargalo de gravação.

Exemplos Práticos em Código SQL

Vamos ver como aplicar isso na prática usando SQL. Imagine uma tabela Clientes com milhões de registros.

1. Criando um Índice Simples

Se o time de vendas sempre busca clientes pelo e-mail, criar um índice nessa coluna vai transformar uma busca que demorava 10 segundos em algo que leva 5 milissegundos.

-- Criando um índice simples na coluna email
CREATE INDEX idx_clientes_email 
ON Clientes (email);

-- Criando um índice simples na coluna email
CREATE INDEX idx_clientes_email 
ON Clientes (email);

2. Criando um Índice Único (Unique Index)

Além de acelerar a busca, ele garante a integridade dos dados, impedindo que dois clientes sejam cadastrados com o mesmo CPF.

-- Criando um índice único na coluna cpf
CREATE UNIQUE INDEX idx_clientes_cpf 
ON Clientes (cpf);

-- Criando um índice único na coluna cpf
CREATE UNIQUE INDEX idx_clientes_cpf 
ON Clientes (cpf);

3. Criando um Índice Composto (Composite Index)

Se você tem uma consulta que SEMPRE filtra por duas colunas ao mesmo tempo (ex: buscar vendas de uma loja específica em uma data específica), você pode criar um índice que combina as duas colunas.

-- Índice composto: a ordem das colunas importa!
CREATE INDEX idx_vendas_loja_data 
ON Vendas (id_loja, data_venda);

-- Índice composto: a ordem das colunas importa!
CREATE INDEX idx_vendas_loja_data 
ON Vendas (id_loja, data_venda);

(Nota: Esse índice é excelente para consultas como WHERE id_loja = 5 AND data_venda = '2026-03-11', mas não ajudaria em nada se você buscasse APENAS pela data_venda).

4. Removendo um Índice

Se você percebeu que um índice não está sendo usado e está apenas atrasando suas inserções, você deve excluí-lo.

-- Removendo o índice do banco de dados
DROP INDEX idx_clientes_email;

-- Removendo o índice do banco de dados
DROP INDEX idx_clientes_email;

DataWarehouses Modernos não utilizam índices tradicionais.

Bancos de dados tradicionais (OLTP) usam índices B-Tree para encontrar uma agulha no palheiro (uma linha específica). Já o BigQuery e o Snowflake são bancos Orientados a Colunas (Columnar Databases) projetados para análise massiva de dados (OLAP).

Em vez de índices, eles usam três conceitos automáticos:

1. Micro-particionamento (Automático): No Snowflake, por exemplo, os dados são divididos em arquivos minúsculos chamados micro-partitions. O sistema sabe o valor mínimo e máximo de cada coluna em cada arquivo e descarta o que não precisa ler.
2. Metadata Cache: O banco mantém metadados sobre onde cada dado está. Ele não precisa de você para “criar” o caminho; ele faz isso sozinho.
3. Clustering: É o “primo” do índice nessas ferramentas. Você define uma Clustering Key para dizer ao banco: “Organize esses dados fisicamente por data e região”. Isso agrupa os dados de forma eficiente.

Como saber se uma tabela tem “índices” (ou otimizações) em Data Warehouses modernos

Se você está em um banco tradicional, você procura por Indexes. Se você está em BigQuery/Snowflake, você procura por Clustering e Partitioning.

1. No Snowflake

O Snowflake não tem índices. Se você quer saber como uma tabela foi otimizada, você deve checar as Clustering Keys.

• Via interface: Vá na aba “Data”, selecione a tabela e procure por “Clustering Information”.
• Via código SQL:

-- Mostra detalhes da tabela, incluindo as chaves de agrupamento (clustering)
SHOW TABLES LIKE 'nome_da_minha_tabela';
-- Verifique a coluna 'cluster_by' no resultado.

-- Mostra detalhes da tabela, incluindo as chaves de agrupamento (clustering)
SHOW TABLES LIKE 'nome_da_minha_tabela';
-- Verifique a coluna 'cluster_by' no resultado.

2. No BigQuery

O BigQuery usa Partitioning (geralmente por data) e Clustering.

• Via interface: Clique na tabela e vá na aba “Details”. Procure pelas seções “Table info” (onde diz se é particionada) e “Schema” (onde as colunas de cluster aparecem com um ícone específico).
• Via código SQL:

-- Consulta os metadados das tabelas no dataset
SELECT table_name, ddl 
FROM `meu_projeto.meu_dataset.INFORMATION_SCHEMA.TABLES`
WHERE table_name = 'nome_da_tabela';
-- No DDL (o código de criação), você verá as cláusulas PARTITION BY e CLUSTER BY.

-- Consulta os metadados das tabelas no dataset
SELECT table_name, ddl 
FROM `meu_projeto.meu_dataset.INFORMATION_SCHEMA.TABLES`
WHERE table_name = 'nome_da_tabela';
-- No DDL (o código de criação), você verá as cláusulas PARTITION BY e CLUSTER BY.

3. Em Bancos Tradicionais (Postgres, SQL Server, MySQL)

Se você cair em um projeto que usa bancos relacionais comuns, você usa as tabelas de sistema:

-- Exemplo para PostgreSQL: Lista todos os índices de uma tabela
SELECT * FROM pg_indexes WHERE tablename = 'nome_da_tabela';

-- Exemplo genérico (muitas ferramentas de BI mostram isso na lateral):
-- Procure por uma pasta chamada "Indexes" na árvore de objetos do banco.

-- Exemplo para PostgreSQL: Lista todos os índices de uma tabela
SELECT * FROM pg_indexes WHERE tablename = 'nome_da_tabela';

-- Exemplo genérico (muitas ferramentas de BI mostram isso na lateral):
-- Procure por uma pasta chamada "Indexes" na árvore de objetos do banco.

Dica para Arquitetos e Engenheiros

Índices são a ponte entre um sistema que “funciona” e um sistema que escala. Em um curso de Engenharia de Dados, esse tema é o divisor de águas que ensina os alunos a pararem de culpar o “servidor fraco” e começarem a olhar para a estrutura física das suas consultas.

O post Índices de Banco de Dados (Database Indexes) apareceu primeiro em Data Universe.

O CRUD é o padrão absoluto que define as funções essenciais para o armazenamento persistente de dados em sistemas de software.

Entendendo cada letra do CRUD

Para ilustrar, imagine que você está usando a agenda de contatos do seu smartphone:

• C – Create (Criar): É a ação de inserir uma nova informação no sistema.
  • Exemplo prático: Quando você conhece alguém novo e salva o nome e o número de telefone dessa pessoa na sua agenda.
• R – Read (Ler): É a ação de consultar, buscar ou recuperar dados que já foram armazenados. É a operação mais executada na maioria dos sistemas.
  • Exemplo prático: Quando você abre a agenda e pesquisa pelo nome “João” para ver qual é o número dele.
• U – Update (Atualizar): É a ação de modificar um dado que já existe no banco de dados.
  • Exemplo prático: Quando o João muda de número de telefone e você edita o contato dele na agenda para salvar a informação nova.
• D – Delete (Excluir): É a ação de remover permanentemente uma informação do sistema.
  • Exemplo prático: Quando você não fala mais com o João e decide apagar o contato dele do seu celular.

Como o CRUD se traduz na Tecnologia?

O conceito de CRUD é universal, mas ele ganha “nomes” diferentes dependendo de onde o Engenheiro de Dados ou Desenvolvedor está trabalhando.

A tabela abaixo mostra como essas quatro ações conceituais são traduzidas para a linguagem de Banco de Dados Relacional (SQL) e para o padrão de comunicação da web (APIs REST):

Create (Criar/Inserir)

A operação de criação é feita através do comando INSERT. Aqui, passamos o nome da tabela, as colunas que queremos preencher e os respectivos valores.

-- Inserindo um novo aluno na tabela
INSERT INTO Alunos (nome_aluno, matricula, data_nasc)
VALUES ('Felipe Andrade', '2026105', '2004-08-20');

-- Inserindo um novo aluno na tabela
INSERT INTO Alunos (nome_aluno, matricula, data_nasc)
VALUES ('Felipe Andrade', '2026105', '2004-08-20');

Read (Ler/Consultar)

A leitura é a alma do SQL, feita com o comando SELECT. Podemos buscar todos os dados de uma vez ou filtrar por critérios específicos.

-- Consultar todos os alunos cadastrados
SELECT * FROM Alunos;

-- Consultar apenas o nome de um aluno específico usando a matrícula
SELECT nome_aluno 
FROM Alunos 
WHERE matricula = '2026105';

-- Consultar todos os alunos cadastrados
SELECT * FROM Alunos;

-- Consultar apenas o nome de um aluno específico usando a matrícula
SELECT nome_aluno 
FROM Alunos 
WHERE matricula = '2026105';

Update (Atualizar/Alterar)

O comando UPDATE modifica registros existentes. Atenção: É vital usar a cláusula WHERE; caso contrário, você atualizará todos os alunos da tabela de uma só vez (o pesadelo de todo DBA).

-- Alterando a data de nascimento do Felipe
UPDATE Alunos
SET data_nasc = '2004-09-20'
WHERE matricula = '2026105';

-- Alterando a data de nascimento do Felipe
UPDATE Alunos
SET data_nasc = '2004-09-20'
WHERE matricula = '2026105';

Delete (Excluir/Remover)

A exclusão é feita com o comando DELETE. Assim como no Update, o uso do WHERE é obrigatório para garantir que você está apagando apenas o registro correto.

-- Removendo o aluno do sistema através do seu ID único
DELETE FROM Alunos
WHERE id_aluno = 5;

-- Removendo o aluno do sistema através do seu ID único
DELETE FROM Alunos
WHERE id_aluno = 5;

Em ambientes de produção, é comum utilizarmos o Soft Delete. Em vez de usar o comando DELETE físico, adicionamos uma coluna chamada ativo (booleano). Para “apagar” o usuário, apenas fazemos um UPDATE Alunos SET ativo = false. Isso mantém o histórico e a integridade dos dados para auditoria futura.

Por que o CRUD é tão importante?

Entender o CRUD é o primeiro passo para projetar qualquer aplicação. Se você modelou um banco de dados (como vimos nas fases Conceitual, Lógica e Física) e o seu sistema não consegue realizar pelo menos o Create e o Read, ele não tem utilidade prática.

Além disso, é através da limitação das operações CRUD que implementamos a segurança e o RBAC (Role-Based Access Control). Por exemplo, um estagiário pode ter permissão apenas de Read em uma tabela financeira, enquanto o gerente tem permissão completa de Create, Read, Update e Delete.

O post CRUD (Create, Read, Update e Delete) apareceu primeiro em Data Universe.

O objetivo é ilustrar os tipos de dados utilizados e armazenados no sistema, as relações entre esses tipos de dados, as formas como os dados podem ser agrupados e organizados e seus formatos e atributos.

Os modelos de dados são construídos em torno das necessidades do negócio. As regras e os requisitos são definidos antecipadamente através do feedback das partes interessadas do negócio, para que possam ser incorporados no design de um novo sistema ou adaptados na iteração de um sistema existente.

Os dados podem ser modelados em vários níveis de abstração. O processo começa com a coleta de informações sobre os requisitos de negócios das partes interessadas e dos usuários finais.

Essas regras de negócios são então traduzidas em estruturas de dados para formular um projeto concreto de banco de dados. 

Um modelo de dados pode ser comparado a um roteiro, um projeto de arquiteto ou qualquer diagrama formal que facilite uma compreensão mais profunda do que está sendo projetado.

A modelagem de dados emprega esquemas padronizados e técnicas formais. Isso fornece uma maneira comum, consistente e previsível de definir e gerenciar recursos de dados em uma organização ou mesmo fora dela.

Idealmente, os modelos de dados são documentos vivos que evoluem junto com as mudanças nas necessidades de negócios. Eles desempenham um papel importante no suporte aos processos de negócios e no planejamento da arquitetura e estratégia de TI. 

1. Modelo Conceitual:
   • Pergunta: O QUÊ?
   • Visão do Negócio
   • Sem Detalhes Técnicos
   • Entidades e Relacionamentos
   • Atividade: Reuniões com Usuários
2. Modelo Lógico:
   • Pergunta: COMO?
   • Estrutura Lógica
   • Independente de SGBD
   • Tabelas, Chaves, Atributos
   • Atividade: Design do Banco
3. Modelo Físico:
   • Pergunta: IMPLEMENTAÇÃO
   • Banco de Dados Real
   • Específico para SGBD
   • Índices, Constraints, Tipos
   • Resultado: Banco Pronto para Usar

Progressão Lógica:

• Conceitual → Lógico → Físico
• Cada nível adiciona mais detalhe técnico
• Do abstrato para o concreto

Primeiro passo: Entendimento do Negócio

Imagine que você vai construir uma casa. Você não começa comprando cimento e tijolos no primeiro dia. Primeiro, você desenha um esboço com o arquiteto para entender quantos quartos a casa terá (o conceito). Depois, faz uma planta baixa com as medidas e a disposição das portas (a lógica). Por fim, o engenheiro define a espessura da parede, a fiação e o tipo de encanamento (o físico).

Na Engenharia de Software e de Dados, o processo de criar um banco de dados segue exatamente a mesma lógica. A Modelagem de Dados é dividida em três fases: Conceitual, Lógica e Física.

Atividades:

• Reuniões com stakeholders para entender o modelo de negócio, processos e objetivos da startup.
• Análise de documentos e softwares utilizados pela contabilidade.
• Levantamento dos requisitos de dados para cada área da empresa (financeiro, fiscal, clientes, etc.).

Exemplo: Identificar quais dados são necessários para registrar transações financeiras, gerar relatórios fiscais, gerenciar clientes e acompanhar indicadores de desempenho.

Modelagem Conceitual: A Visão de Negócio

O modelo conceitual é o mais alto nível de abstração. O foco aqui não é a tecnologia, mas sim entender as regras de negócio e como as informações se relacionam no mundo real. É um desenho feito para que gerentes, diretores e analistas de negócio consigam entender o sistema sem precisar saber programação.

Os modelos conceituais geralmente são criados como parte do processo de coleta dos requisitos iniciais do projeto. Normalmente, eles incluem classes de entidade (definindo os tipos de coisas que são importantes para o negócio representar no modelo de dados), suas características e restrições, os relacionamentos entre elas e os requisitos relevantes de segurança e integridade de dados. 

Objetivo: Criar uma representação abstrata das entidades, relacionamentos e atributos dos dados, independente de tecnologia.

Atividades:

• Identificação das entidades principais (Cliente, Conta Bancária, Transação Financeira, Plano de Contas, Nota Fiscal, etc.).
• Definição dos atributos de cada entidade (nome, CPF/CNPJ, data, valor, descrição, categoria, etc.).
• Estabelecimento dos relacionamentos entre as entidades (um cliente possui várias contas bancárias, uma transação está associada a uma conta e a um plano de contas, etc.).
• Criação de um Diagrama Entidade-Relacionamento (DER) para visualizar o modelo conceitual.

Exemplo Prático:

Em um sistema de biblioteca escolar:

• Um Aluno pega emprestado um Livro.
• O modelo conceitual mostrará apenas caixas para “Aluno” e “Livro”, unidas por uma linha representando o “Empréstimo”. Não nos importamos com o CPF do aluno ou o ISBN do livro ainda.

Esse modelo oferece uma visão geral do que o sistema conterá, como será organizado e quais regras de negócios estão envolvidas. 

2. Modelagem Lógica: A Estrutura da Informação

Esse modelo fornece maiores detalhes sobre os conceitos e relações no domínio em consideração. 

Os modelos lógicos não especificam nenhum requisito técnico do sistema. Este estágio é frequentemente omitido em práticas ágeis ou DevOps. 

Os modelos lógicos podem ser úteis em ambientes de implementação altamente processuais ou para projetos que são orientados a dados por natureza, como design de Data Warehouse ou desenvolvimento de sistemas de relatórios.

Objetivo: Transformar o modelo conceitual em um modelo mais detalhado, utilizando estruturas e regras específicas.

Atividades:

• Definição das características detalhadas dos dados (tipo de dado, tamanho, formato, constraints, etc.).
• Estabelecimento de regras de negócio (validações, gatilhos, etc.).
• Criação de um Modelo Lógico de Dados (MLD) utilizando notações como UML.

Uma vez aprovado o conceito, avançamos para o modelo lógico. Aqui, começamos a adicionar detalhes estruturais aos dados, mas ainda sem nos prender a um banco de dados específico (como Oracle, MySQL ou PostgreSQL). Este modelo é geralmente construído por Arquitetos de Dados ou Analistas de Sistemas.

• Objetivo: Responder como os dados serão estruturados e relacionados.
• Elementos adicionados:
  • Atributos: As características das entidades (ex: Nome, Data de Nascimento, Preço).
  • Chaves Primárias (PK): O identificador único de cada registro (ex: ID_Cliente).
  • Chaves Estrangeiras (FK): O campo que cria a ligação entre duas tabelas.
  • Normalização: É aqui que aplicamos as Formas Normais (1FN, 2FN, 3FN) para evitar redundâncias.

Exemplo Prático (Tabelas Lógicas):

Tabela: LIVRO

Tabela: AUTOR

Tabela: CATEGORIA

Tabela: MEMBRO

Tabela: EMPRESTIMO

Entidades (Tabelas) e seus Atributos:

1. LIVRO:
   • id_livro (Chave Primária)
   • titulo, isbn (Chave Única)
   • descricao, data_publicacao
   • quantidade_total, quantidade_disponível
   • id_autor (Chave Estrangeira)
   • id_categoria (Chave Estrangeira)
2. AUTOR:
   • id_autor (Chave Primária)
   • nome, nacionalidade
   • data_nascimento, biografia
3. CATEGORIA:
   • id_categoria (Chave Primária)
   • nome, descricao
4. MEMBRO:
   • id_membro (Chave Primária)
   • nome, email (Chave Única)
   • telefone, endereco
   • data_cadastro, status
5. EMPRESTIMO:
   • id_emprestimo (Chave Primária)
   • id_membro (Chave Estrangeira)
   • id_livro (Chave Estrangeira)
   • data_emprestimo, data_devolucao_prevista
   • data_devolucao_real, status

Relacionamentos:

• Um LIVRO é escrito por Um AUTOR
• Um LIVRO pertence a Uma CATEGORIA
• Um LIVRO tem vários EMPRÉSTIMOs
• Um MEMBRO realiza vários EMPRÉSTIMOs

Legenda

• PK (Primary Key): Chave Primária – Identifica unicamente cada registro
• FK (Foreign Key): Chave Estrangeira – Estabelece relacionamento com outra tabela
• UK (Unique Key): Chave Única – Campo único que não pode ser duplicado

3. Modelagem Física: A Implementação Tecnológica

O modelo físico é a “mão na massa”. É aqui que o modelo lógico é traduzido para a linguagem de um Sistema Gerenciador de Banco de Dados (SGBD) específico. O Engenheiro de Dados ou o DBA (Database Administrator) define como os dados serão efetivamente gravados no disco do servidor.

• Objetivo: Responder como o sistema vai armazenar os dados fisicamente, otimizando o desempenho.
• Elementos adicionados:
  • Tipos de Dados (Data Types): Definir se um campo será VARCHAR(50), INT, DECIMAL(10,2) ou BOOLEAN.
  • Índices (Indexes): Criados para acelerar a busca de dados.
  • Restrições (Constraints): Regras do banco, como NOT NULL ou UNIQUE.
  • Particionamento: Decisões de arquitetura (como vimos no caso do Sharding e Partitioning).

Exemplo Prático (Especificação Física):

A tabela de Aluno agora ganha sua definição técnica, pronta para virar código SQL:

Quadro Resumo: Comparando as 3 Fases

Para facilitar a visualização e servir de material de estudo, aqui está a comparação direta:

Referências Importantes sobre o Tema

Se você deseja se aprofundar na literatura acadêmica e de mercado que padronizou esses conceitos, recomendo os seguintes pilares da engenharia de dados:

1. Peter Chen (1976): Criador do Modelo Entidade-Relacionamento (MER), que é a base da modelagem conceitual até hoje. Seu artigo “The Entity-Relationship Model: Toward a Unified View of Data” mudou a história da computação.
2. DAMA-DMBOK (Data Management Body of Knowledge): O guia oficial da Data Management Association. O capítulo de Data Modeling and Design estabelece os padrões globais da indústria para a criação de modelos lógicos e físicos em empresas de grande porte.
3. Ralph Kimball e Bill Inmon: Para modelagem focada em Data Warehouses (OLAP), que utiliza modelagem dimensional (Star Schema/Snowflake), que é uma variação específica após a modelagem relacional clássica.

O post Modelagem de dados Conceitual, Lógica e Física apareceu primeiro em Data Universe.

Eles não são inimigos, mas sim estratégias opostas usadas para resolver problemas diferentes. A normalização foca na escrita e integridade (OLTP), enquanto a desnormalização foca na velocidade de leitura (OLAP).

O que é Normalização?

A normalização é o processo de organizar os dados em um banco de dados relacional para reduzir a redundância e melhorar a integridade. O objetivo é garantir que cada pedaço de informação seja armazenado em apenas um lugar. Quando você precisa atualizar o nome de um cliente, por exemplo, você altera apenas uma linha em uma única tabela, e não em centenas de registros de vendas.

Para atingir esse nível de organização, aplicamos regras progressivas chamadas de Formas Normais (FN).

O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados para verificar se estas estão corretamente projetadas.

Embora existam cinco formas normais (ou regras de normalização), na prática usamos um conjunto de três Formas Normais, ou seja, um banco de dados é considerado normalizado se nele foram aplicadas as regras destas três formas normais.

O que é Desnormalização?

A desnormalização é o processo intencional de adicionar redundância a um banco de dados que já foi normalizado. O objetivo é melhorar a performance de leitura.

Em sistemas de Data Warehouse ou Analytics (OLAP), fazer dezenas de JOINs para montar um relatório através de tabelas na 3FN é extremamente lento. A desnormalização “achata” essas tabelas, agrupando dados frequentemente consultados em um lugar só.

• Exemplo Prático: Em vez de fazer um JOIN entre Vendas, Clientes, Cidades e Estados para saber o total vendido em São Paulo, você cria uma tabela desnormalizada gigante (Fato/Dimensão) onde a linha da venda já contém o nome da cidade e do estado, mesmo que isso repita a palavra “São Paulo” um milhão de vezes.

1ª Forma Normal (1FN): Atomicidade

A regra de ouro aqui é: cada coluna deve conter apenas um valor único e indivisível (atômico), e não pode haver grupos repetidos. Uma entidade estará na primeira forma normal (IFN) se todos os campos forem atômicos (simples) e não multivalorados (com múltiplos valores).

Problema (Não Normalizado): Uma tabela de livros onde um livro possui vários autores na mesma célula.

Solução (1FN): Dividir em múltiplas linhas, garantindo que a coluna Autores tenha apenas um valor por registro.

Quais os problemas de uma tabela não normalizada com a 1FN?

São vários. A primeira forma normal tenta resolver um dos maiores problemas de bancos de dados que é
a repetição (redundância de dados) e a desorganização deles.

Imagine um campo telefone que permita a entrada de mais de um valor (dois números de telefones) por exemplo. Como faríamos uma busca em um dos valores apenas? Mesma coisa em um campo endereço onde as partes não estivessem desmembradas, da seguinte forma:

Rua das Oliveiras, 256, Parque Novo Mundo, São Paulo, SP.

Como seria possível fazer uma busca de todos os clientes que morassem no Parque Novo
Mundo? Ou na cidade de São Paulo? Ou no estado de SP?

Toda tabela precisa obrigatoriamente ser normalizada com a 1FN?

Não. A normalização é um processo corretivo que deve ser aplicado em casos específicos onde o problema for identificado. Tudo irá depender de como a análise dos dados foi feita. De início você terá muita dificuldade em aplicar as regras de normalização e somente o tempo e o acúmulo de experiência farão esse processo ser natural para você. Um analista experiente aplica a normalização de dados por padrão, pois ele olha para uma tabela e já ‘sente’ que tem algo errado ali e aplica a correção para tal.

2ª Forma Normal (2FN): Dependência Total

Para estar na 2FN, a tabela precisa estar na 1FN e todos os atributos não-chave devem depender de toda a chave primária (isso se aplica a tabelas com chaves primárias compostas). Uma entidade estará na 2FN se ela já se encontrar na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária.

• Crie tabelas separadas para conjuntos de valores que se aplicam a vários registros.
• Relacione essas tabelas com uma chave estrangeira.
• Primeiramente, para estar na 2FN é preciso estar também na 1FN. 

2FN define que os atributos normais, ou seja, os não chave, devem depender unicamente da chave primária da tabela. Assim como as colunas da tabela que não são dependentes dessa chave devem ser removidas da tabela principal e cria-se uma nova tabela utilizando esses dados.

Problema (1FN, mas viola 2FN): Uma tabela de matrículas onde a chave composta é ID_Aluno + ID_Curso. O Nome_Curso depende apenas do ID_Curso, não do aluno.

Solução (2FN): Separar as informações específicas do curso em uma nova tabela.

Tabela Matricula:

Tabela Curso:

Conforme vimos tanto com a 1FN quanto agora com a 2FN, quando aplicamos a normalização de dados é comum gerar novas tabelas a fim de satisfazer as formas normais que estão sendo aplicadas. Mais uma vez gostaria de deixar claro que a normalização de dados, apesar das regras serem simples, causa grande dificuldade nos iniciantes da área. Então tenha paciência pois com o tempo irá ganhar experiência e tudo ficará mais fácil.

3ª Forma Normal (3FN): Sem Dependências Transitivas

Para estar na 3FN, a tabela deve estar na 2FN e nenhum atributo não-chave pode depender de outro atributo não-chave. Todos devem depender apenas da chave primária.

• Elimine campos que não dependem da chave.
• Assim como para estar na 2FN é preciso estar na 1FN, para estar na 3FN é preciso estar também na 2FN. 

3FN define que todos os atributos dessa tabela devem ser funcionalmente independentes uns dos outros, ao mesmo tempo que devem ser dependentes exclusivamente da chave primária da tabela. 

3FN foi projetada para melhorar o desempenho de processamento dos banco de dados e minimizar os custos de armazenamento. 

Problema (2FN, mas viola 3FN): Uma tabela de veículos onde a chave primária é a Placa. O atributo Pais_Origem_Marca depende da Marca, e não diretamente da Placa.

Solução (3FN): Criar uma tabela separada para as marcas.

Tabela Veiculo:

Tabela Marca:

3.5 Forma Normal de Boyce-Codd (BCNF)

Conhecida como “3.5FN”, ela é uma versão mais rigorosa da 3FN. A regra dita que todo determinante deve ser uma chave candidata. Ela resolve anomalias em tabelas que possuem múltiplas chaves candidatas compostas e sobrepostas.

Problema: Uma clínica onde a chave primária é (ID_Paciente + Especialidade). Um médico atende apenas uma especialidade. O Nome_Medico determina a Especialidade, criando uma redundância se o médico mudar de especialidade.

Solução (BCNF): Separar a relação do paciente com o médico, e do médico com a especialidade.

Tabela Consulta:

Tabela Medico_Especialidade:

4ª Forma Normal (4FN): Dependências Multivaloradas Independentes

Para estar na 4FN, a tabela deve estar na BCNF e não pode conter mais de uma dependência multivalorada independente.

Problema: Um programador tem várias “Linguagens” (Python, Java) e possui várias “Certificações” (AWS, Azure). Colocar tudo na mesma tabela cria uma multiplicação (produto cartesiano) de registros desnecessários.

Solução (4FN): Criar duas tabelas distintas para separar as dependências que não têm relação entre si.

Tabela Programador_Linguagem:

Tabela Programador_Certificacao:

5ª Forma Normal (5FN): Dependência de Junção

É extremamente rara na prática. Diz que uma tabela está na 5FN se ela não puder ser dividida em tabelas menores sem perder informações ao tentar juntá-las (JOIN) novamente. Trata de relações ternárias (três variáveis conectadas) que causam anomalias se agrupadas.

Problema: Uma relação complexa onde um Vendedor vende produtos de uma Marca que pertence a uma Categoria. Se juntarmos tudo, podemos inferir erroneamente que um vendedor vende uma categoria de uma marca específica que ele, na verdade, não tem autorização para vender.

Solução (5FN): Dividir a relação ternária em três tabelas binárias (relação de dois em dois).

Tabela Vendedor_Marca:

Tabela Vendedor_Categoria:

Tabela Marca_Categoria:

O post Normalização vs. Desnormalização de Dados apareceu primeiro em Data Universe.

É aqui que entram duas das arquiteturas mais importantes da Engenharia de Dados e de Software: Partitioning (Particionamento) e Sharding (Fragmentação). Embora frequentemente confundidos, eles resolvem problemas de escala de maneiras fundamentalmente diferentes.

O que é Partitioning (Particionamento)?

O particionamento é a técnica de dividir uma tabela lógica muito grande em pedaços físicos menores e mais gerenciáveis, dentro do mesmo banco de dados ou servidor. O sistema de banco de dados gerencia essas partições de forma transparente; para a aplicação, parece que ela ainda está consultando uma única tabela gigante.

Existem dois tipos principais de particionamento:

O que é Sharding (Fragmentação)?

O Sharding é, na verdade, uma forma extrema de particionamento horizontal. A diferença crucial é a infraestrutura: no Sharding, os dados são divididos e distribuídos em múltiplos servidores físicos ou instâncias de banco de dados independentes (chamados de Shards).

Nesta arquitetura, conhecida como Shared-Nothing (Nada Compartilhado), cada Shard atua como um banco de dados autônomo contendo apenas uma fatia dos dados totais.

• Como funciona: Uma “Chave de Shard” (Shard Key) determina para qual servidor o dado vai. Se você fizer o sharding por “Região”, o Shard A pode guardar os clientes do Brasil, o Shard B os dos EUA, e o Shard C os da Europa.
• Por que usar: Quando um único servidor (mesmo o mais caro e potente do mercado) não tem mais CPU, RAM ou disco suficiente para lidar com o volume de dados ou de requisições simultâneas. O Sharding permite escalabilidade horizontal infinita: basta adicionar mais servidores baratos ao cluster.

Principais Diferenças

A tabela abaixo destaca o contraste direto entre as duas abordagens:

Particionamento na Prática: O E-commerce e o Relatório Lento

Imagine que você trabalha na engenharia de dados de um grande e-commerce. Vocês têm uma tabela chamada Pedidos no PostgreSQL que armazena todas as vendas desde a fundação da empresa, há 10 anos. Essa tabela tem 5 bilhões de linhas.

O Problema:

Toda vez que o time de marketing tenta puxar um relatório das “vendas de ontem”, a query demora minutos para rodar. Além disso, o índice dessa tabela ficou tão gigante que não cabe mais na memória RAM do servidor (que custa caro).

A Solução (Particionamento Horizontal por Data):

Você decide particionar a tabela Pedidos por mês e ano.

• Como fica nos bastidores: O banco de dados cria tabelas físicas menores “escondidas” (ex: pedidos_2025_12, pedidos_2026_01, pedidos_2026_02).
• A Mágica (Partition Pruning): Quando o marketing roda um SELECT * FROM Pedidos WHERE data = '04/03/2026', o banco de dados é inteligente o suficiente para saber que não precisa ler a tabela inteira. Ele vai direto na partição pedidos_2026_03 e ignora todo o resto. O relatório que demorava minutos passa a rodar em milissegundos.
• Manutenção: Se a política da empresa diz que dados com mais de 5 anos devem ser apagados, você não roda um comando DELETE (que travaria o banco e consumiria muito processamento). Você simplesmente roda um DROP PARTITION pedidos_2021_01. A exclusão de milhões de linhas acontece instantaneamente, liberando espaço no disco.

Agora imagine que você é o arquiteto de um sistema de CRM (SaaS) global, parecido com o Salesforce. Vocês têm milhares de empresas como clientes.

O Problema:

O sistema faz 100.000 gravações (inserções e atualizações) por segundo. O servidor de banco de dados atual chegou a 100% de uso de CPU, a memória RAM está no limite e o disco não consegue gravar dados mais rápido do que isso. Fazer um particionamento não vai ajudar, porque a máquina física não aguenta mais o tráfego.

A Solução (Sharding Baseado em ID do Cliente):

Você decide transformar seu banco de dados único em um cluster de múltiplos servidores independentes (Shards). Você escolhe o id_empresa como a sua Chave de Shard (Shard Key).

• Como fica nos bastidores:
  • Servidor 1 (Shard A): Armazena todos os dados das Empresas de ID 1 a 10.000.
  • Servidor 2 (Shard B): Armazena todos os dados das Empresas de ID 10.001 a 20.000.
  • Servidor 3 (Shard C): Armazena todos os dados das Empresas de ID 20.001 a 30.000.
• A Mágica (Roteamento): Quando um funcionário da Empresa 15.000 faz login e tenta salvar um novo cliente no CRM, a sua aplicação (ou um roteador de banco de dados intermediário) avalia a requisição. Ele vê o ID 15.000 e pensa: “A Empresa 15.000 mora no Servidor 2”. A requisição de gravação é enviada exclusivamente para o Servidor 2.
• Escalabilidade Infinita: O Servidor 1 e o Servidor 3 nem ficam sabendo dessa transação. Você acabou de dividir o uso de CPU, RAM e Disco por três. Se o SaaS continuar crescendo e vocês ganharem mais 10.000 empresas clientes, basta comprar um Servidor 4 (Shard D) e plugar na arquitetura.

Resumo do Impacto Prático

A implementação do particionamento geralmente é nativa e mais simples (bancos como PostgreSQL e MySQL fazem isso muito bem). Já o sharding adiciona uma camada de complexidade grande na engenharia, pois a sua aplicação precisa saber como rotear as informações.

Quando escolher qual?

A regra de ouro na arquitetura de dados é: Evite o Sharding até que ele seja absolutamente necessário.

Vá de Partitioning quando:

• Você tem tabelas gigantes (ex: logs, histórico financeiro) que estão deixando os relatórios lentos.
• Você precisa arquivar ou deletar dados antigos rapidamente (basta “dropar” a partição do mês passado, o que é instantâneo em comparação a deletar milhões de linhas).
• Seu hardware atual ainda tem capacidade de CPU e memória, o problema é apenas a organização do dado no disco.

Vá de Sharding quando:

• Você atingiu o limite de hardware. Fazer um upgrade no servidor atual custaria uma fortuna ou é fisicamente impossível.
• Sua aplicação tem uma carga massiva de gravação (Writes) que um único disco não consegue processar.
• Você precisa de distribuição geográfica (ex: guardar dados de europeus na Europa por questões de latência ou conformidade com a GDPR).

O Desafio do Sharding: O “Hotspot”

Um dos maiores riscos do Sharding é escolher a chave errada, criando um Hotspot (ponto quente). Por exemplo, se você dividir um banco de dados de uma rede social pela letra inicial do nome, o servidor responsável pela letra “A” e “M” receberá 80% do tráfego e vai travar, enquanto o servidor das letras “X”, “Y” e “Z” ficará ocioso. A distribuição precisa ser perfeitamente balanceada.

O post Sharding vs. Partitioning apareceu primeiro em Data Universe.

Para entender tudo sobre o assunto, precisamos desmistificar o que ele é, por que é fundamental e se ele realmente é o “novo” padrão da segurança em nuvem.

O que é o RBAC e como ele funciona?

O RBAC é um método de segurança que restringe o acesso a sistemas e redes com base nas funções (roles) que os usuários exercem dentro de uma organização.

Em vez de atribuir permissões individualmente para cada funcionário (o que seria um pesadelo administrativo), você cria Funções e atribui Permissões a essas funções. Depois, basta alocar os Usuários nas funções adequadas.

A estrutura lógica funciona assim:

Se o “João” é promovido de Analista Júnior para Sênior, a equipe de TI não precisa alterar dezenas de permissões individuais. Basta remover o João da função “Júnior” e adicioná-lo à função “Sênior”.

Por que devemos usar o RBAC?

A adoção do RBAC deixou de ser uma “boa prática” para se tornar uma exigência básica de governança de TI. Os principais motivos incluem:

1. Aplicação do Princípio do Privilégio Mínimo (PoLP): O RBAC garante que um usuário tenha apenas os acessos estritamente necessários para realizar seu trabalho, reduzindo drasticamente a superfície de ataque caso a conta dele seja comprometida.
2. Eficiência Operacional: Processos de onboarding (entrada de funcionários) e offboarding (saída) tornam-se rápidos e automatizados. Quando alguém sai da empresa, desativar o usuário revoga automaticamente todos os acessos associados à sua função.
3. Auditoria e Compliance: Para estar em conformidade com leis como LGPD, GDPR ou normas como ISO 27001, você precisa provar quem tem acesso a quais dados. O RBAC torna essa auditoria clara e mapeável.

O RBAC é o “novo” padrão de segurança Cloud?

Para ser direto: não, o RBAC não é novo. O conceito existe desde a década de 1990. No entanto, ele é o padrão fundamental e absoluto da segurança em nuvem moderna.

Provedores como AWS, Microsoft Azure e Google Cloud Platform (GCP) utilizam o RBAC como o coração dos seus sistemas de IAM (Identity and Access Management). Você não gerencia a nuvem de forma segura sem dominar o RBAC.

Porém, a verdadeira “novidade” e o próximo passo natural na evolução da segurança em nuvem é o ABAC (Attribute-Based Access Control).

A tabela abaixo esclarece a diferença para que você entenda a evolução:

Boas Práticas para Implementar RBAC

Se você está estruturando o RBAC na sua empresa ou ambiente cloud, siga estas regras de ouro:

• Comece pequeno: Não tente criar funções para cada micro-atividade. Comece com funções amplas (Leitura, Escrita, Administração) e refine conforme necessário.
• Evite o “Creep de Privilégios”: Revise periodicamente as funções. É comum que usuários acumulem funções antigas quando mudam de departamento.
• Não atribua permissões diretamente: Se um usuário precisa de um acesso temporário, crie uma função temporária. Nunca fuja do modelo Função -> Permissão.

O post RBAC (Role-Based Access Control) apareceu primeiro em Data Universe.

Desde uma curtida em uma rede social e sinais de GPS até sensores em turbinas de avião, quase tudo o que fazemos gera rastros digitais que alimentam esse ecossistema.

Os 5 Vs do Big Data

Para entender o que define o Big Data, a indústria utiliza o modelo dos “Vs”, que ajudam a distinguir um banco de dados comum de uma operação de Big Data real:

1. Volume: A quantidade de dados gerados é massiva (escala de Terabytes a Zettabytes).
2. Velocidade: Os dados são criados e precisam ser analisados em tempo real ou quase real (ex: transações de cartão de crédito).
3. Variedade: Os dados vêm em diversos formatos: estruturados (tabelas), semiestruturados (XML/JSON) e não estruturados (vídeos, áudios, posts).
4. Veracidade: A necessidade de garantir que os dados sejam confiáveis e precisos.
5. Valor: O ponto mais importante. De nada serve ter montanhas de dados se eles não gerarem uma decisão de negócio ou benefício social.

Como o Big Data é Processado?

Diferente de um arquivo Excel que roda no seu computador, o Big Data exige processamento distribuído. Isso significa que o trabalho é dividido entre centenas ou milhares de servidores que trabalham em paralelo.

• Hadoop: Um framework que permite o armazenamento e processamento de grandes volumes em clusters.
• Spark: Um motor de processamento ultra veloz que trabalha com dados em memória.
• Data Lakes: Repositórios que armazenam dados em seu formato bruto até que sejam necessários para análise.

Por que o Big Data é Importante?

O Big Data é o “combustível” para a Inteligência Artificial e o Machine Learning. Sem grandes volumes de exemplos (dados), as máquinas não conseguem aprender padrões.

A Base de Tudo: Bits e Bytes

• Bit (Binary Digit): É a menor unidade de informação. Um bit pode assumir apenas dois valores: 0 ou 1 (ligado ou desligado). É a linguagem fundamental dos processadores.
• Byte: Um conjunto de 8 bits. É a menor unidade que representa um caractere compreensível (como uma letra ou um número). Se você digitar a letra “A”, ela ocupará aproximadamente 1 byte.

As Medidas que Usamos no Dia a Dia

A partir do Byte, as medidas crescem em escalas de 1.024 (embora comercialmente o mercado use o arredondamento para 1.000).

• Kilobyte (KB): Equivale a 1.024 bytes. É o tamanho comum de arquivos de texto simples ou ícones pequenos.
• Megabyte (MB): São 1.024 KB. Aqui entramos no mundo multimídia: uma música em MP3 média tem cerca de 5 MB, e um minuto de vídeo em baixa resolução pode ocupar de 10 a 20 MB.
• Gigabyte (GB): São 1.024 MB. É a medida padrão para pendrives, memória RAM e smartphones. Um filme em alta definição (HD) costuma ocupar entre 4 GB e 8 GB.
• Terabyte (TB): São 1.024 GB. Atualmente, é o padrão para HDs externos e computadores de alta performance. Para ter uma ideia, 1 TB pode armazenar cerca de 200 mil músicas.

A Escala Industrial e Global

Além do Terabyte, entramos em grandezas que fogem do uso doméstico comum e passam a descrever o tráfego global da internet e grandes centros de dados.

• Petabyte (PB): 1.024 Terabytes. O Google, por exemplo, processa dezenas de petabytes por dia. Estima-se que 2 PB seriam suficientes para armazenar toda a produção acadêmica de um país como os EUA.
• Exabyte (EB): 1.024 Petabytes. É uma escala usada para medir o tráfego total da internet mundial por mês. Um único Exabyte poderia armazenar o equivalente a 1 bilhão de gigabytes.
• Zettabyte (ZB): 1.024 Exabytes. Imagine 1 bilhão de discos rígidos de 1 TB lotados. Isso é um Zettabyte. Especialistas dizem que se gravássemos todas as palavras já ditas pela humanidade em alta qualidade, seriam necessários cerca de 42 ZB.
• Yottabyte (YB): 1.024 Zettabytes. É o topo da escala atual. Para dar uma dimensão humana, se dividíssemos um Yottabyte pela população mundial, cada pessoa teria direito a cerca de 142 Terabytes de armazenamento próprio.

Conclusão

Big Data não é uma tecnologia do futuro; é a fundação da economia atual. Para empresas e profissionais, o desafio não é mais “obter” dados, mas sim saber quais perguntas fazer a eles. A capacidade de navegar nesse oceano de informações define quem lidera a inovação e quem fica para trás na transformação digital.

O post Big Data apareceu primeiro em Data Universe.