DP-900: compreender e usar normalização em bases de dados relacionais

João Barros 10 de August de 2026 6 min de leitura

Vou ensinar a competência de normalização de esquemas relacionais (1NF–3NF) — uma aptidão-chave na secção "Dados relacionais no Azure" do DP-900. Saber normalizar ajuda-te a desenhar bases de dados eficientes e a reduzir redundância, o que importa tanto para o exame como para soluções reais no Azure SQL Database ou no SQL Server. Para além de teoria, explico passos concretos, trade-offs de desempenho e formas práticas de experimentar num ambiente Azure ou local.

O que precisas de saber

Normalização é um conjunto de regras para organizar atributos e tabelas de modo a reduzir redundância e evitar anomalias de inserção/actualização/eliminações. As formas normais mais relevantes para o nível Fundamentals são:

1NF (Primeira Forma Normal): cada coluna deve conter valores atómicos (sem listas ou estruturas) e cada linha deve ser única (chave primária). Por exemplo, não coloques uma coluna "Products" com uma lista separada por vírgulas — cada produto deve ser uma linha.
2NF (Segunda Forma Normal): além de estar em 1NF, todos os atributos não-chave devem depender totalmente da chave primária. Isto é importante especialmente quando tens chaves compostas (por exemplo, OrderID + ProductID). A 2NF elimina dependências parciais que causam repetição desnecessária.
3NF (Terceira Forma Normal): além de 2NF, não pode haver dependências transitivas entre atributos não-chave. Ou seja, um atributo não-chave não deve depender de outro atributo não-chave; se isso acontecer, move essa parte para uma nova tabela.

Exemplo simples: um registo de encomendas. Um esquema não normalizado pode ter: OrderID, CustomerName, CustomerAddress, ProductID, ProductName, Quantity numa única tabela. Isto causa redundância — se uma encomenda tiver 5 linhas (5 produtos), os dados do cliente repetem-se 5 vezes. Em conjuntos de dados reais (por exemplo, 100 000 linhas de encomendas) esta repetição pode aumentar o espaço usado e complicar actualizações: alterar a morada do cliente exigiria actualizar muitas linhas.

Como funciona (passo-a-passo)

Segue um processo prático para normalizar até 3NF, usando um exemplo de Encomendas:

Identificar entidades e repetições: examina os dados e separa conceitos — Encomenda, Cliente, Produto. Conta quantas vezes cada peça de informação se repete (por exemplo, se 10% das linhas repetem o mesmo CustomerName, é sinal de redundância).
Garantir 1NF: substituir campos multivalorados por linhas separadas. Se a encomenda tem vários produtos, cada produto é uma linha em OrderItems com OrderID repetido mas chave composta (OrderID, ProductID). Isto transforma listas em registos atómicos.
Aplicar 2NF: detectar chaves compostas. Se OrderItems usa (OrderID, ProductID) como chave, atributos como ProductName ou UnitPrice não devem depender só de uma parte (ProductID). Movê-los para uma tabela Products evita repetição de nome e preço por cada linha de encomenda.
Aplicar 3NF: remover dependências transitivas. Se na tabela Customers existir CustomerCity e CityRegion, e CityRegion depende de City, cria uma tabela Cities (CityID, CityName, Region) e referencia por chave. Assim, alterações na região provocam uma só modificação.

-- Esquema normalizado (exemplo conceptual)
Customers(CustomerID PK, CustomerName, CustomerAddress)
Products(ProductID PK, ProductName, UnitPrice)
Orders(OrderID PK, OrderDate, CustomerID FK)
OrderItems(OrderID FK, ProductID FK, Quantity, PRIMARY KEY(OrderID, ProductID))

Este design centraliza informação do cliente e do produto, facilitando manutenção e permitindo a aplicação de constraints e transacções para manter integridade no Azure SQL Database.

Na prática — recomendações para o Azure

Quando implementares no Azure SQL Database ou em Managed Instance, considera estes pontos práticos:

Define chaves primárias e estrangeiras para reforçar integridade referencial; isto permite ao motor do SQL validar relações automaticamente.
Cria índices em colunas de junção (por exemplo, um non-clustered index em Orders.CustomerID) para acelerar joins; sem índices, uma query de junção pode custar várias centenas de ms ou mais em tabelas grandes.
Analisa o plano de execução (Query Plan) para perceber o custo dos joins; se uma consulta de leitura crítica fizer 5 joins e estiver lenta, considera materializar resultados com vistas indexadas ou desnormalização controlada.
Equilibra normalização com requisitos de desempenho: em cenários de leitura intensiva (por exemplo, relatórios em Power BI), alguma desnormalização (duplicar um campo que raramente muda) pode reduzir 2–3 joins e acelerar consultas de leitura; documenta sempre as razões e impactos nas operações de escrita.

Erros comuns

Algumas armadilhas típicas e como as evitar:

Confundir normalização com eliminação total da duplicação: normalizar até formas muito avançadas pode criar demasiadas tabelas e muitos joins, penalizando leituras. Avalia o balanço entre escrita e leitura.
Esquecer chaves naturais versus chaves artificiais: usar nome ou email como chave natural pode quebrar integridade se o valor mudar. Prefere chaves substitutas (IDs inteiros autoincrementados) para estabilidade e desempenho em joins.
Ignorar operações de leitura/escrita: normalizar em demasia aumenta o número de operações de escrita (mais tabelas a actualizar) e pode induzir contenção. Testa com cargas representativas (por exemplo, 1000 inserts/sec) para medir impacto.

Como praticar

Pratica modelação e normalização usando um ambiente de testes no Azure (por exemplo, uma instância de Azure SQL Database na camada gratuita/créditos) ou um servidor local com SQL Server Developer. Passos sugeridos:

Cria um esquema denormalizado, popula com alguns milhares de linhas (por exemplo 10k–100k) e mede o tamanho e tempos de consultas básicas (SELECT, UPDATE).
Normaliza para 3NF conforme o processo acima, popula as tabelas normalizadas e compara espaço ocupado, tempo de consultas e número de joins. Documenta diferenças percentuais — em muitos casos vais observar redução de redundância e facilitação de actualizações, e um pequeno aumento no custo de leitura se não houver índices apropriados.
Usa as ferramentas de monitorização do Azure (Query Performance Insight, Query Store) para analisar queries reais.

Para preparação do exame: usa o Practice Assessment OFICIAL da Microsoft (gratuito) e a study guide oficial da Microsoft (gratuita). Estes recursos ajudam-te a verificar os conhecimentos medidos sem recorrer a material proibido.

Em resumo

Normalização (1NF–3NF) organiza dados para reduzir redundância e evitar anomalias de dados.
1NF exige valores atómicos; 2NF elimina dependências parciais; 3NF remove dependências transitivas.
No Azure SQL Database, combina normalização com índices e integridade referencial para atingir bom desempenho; testa com cargas reais e ajusta se necessário.
Pratica com esquemas reais e usa os recursos oficiais gratuitos da Microsoft para preparar o DP-900, respeitando sempre as boas práticas de modelação e avaliação de performance.