Vantagens e desvantagens da normalização

Hoje a gente vai dar mais uma olhada, agora com mais detalhes, nesse assunto importante: vantagens e desvantagens da normalização, pra você sacar melhor como esses conceitos funcionam na vida real. Então, se prepara aí — bora começar!

Eliminação de redundância de dados

Quando os dados numa tabela não estão normalizados, você pode perceber que a mesma informação aparece repetida em várias linhas. Por exemplo, numa tabela de pedidos pode ter o endereço do cliente repetido pra cada pedido. A normalização resolve essas duplicidades, jogando os dados em tabelas separadas.

Exemplo:

-- Antes da normalização
CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_name TEXT,
    customer_address TEXT,
    order_date DATE
);

-- Depois da normalização
CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY,
    customer_name TEXT,
    customer_address TEXT
);

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    customer_id INT REFERENCES customers(customer_id),
    order_date DATE
);

Por que isso é importante? Menos dados duplicados significa menos chance de erro. Se o endereço do cliente mudar, você só precisa atualizar em um lugar.

Garantia de integridade dos dados

Quando os dados estão divididos em tabelas lógicas, fica fácil gerenciar as relações entre eles. Usar foreign keys ajuda a manter a integridade dos dados automaticamente. Por exemplo, você não consegue apagar um cliente que ainda tem pedidos na tabela de pedidos.

Exemplo:

-- A foreign key garante que ao deletar um cliente, os pedidos relacionados também são deletados
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;

Você pode ficar tranquilo que a estrutura do banco não vai deixar rolar dados "órfãos".

Facilidade nas atualizações

Quando seu banco tá normalizado, atualizar dados fica fácil e menos propenso a erro. Voltando ao exemplo dos clientes — se o cliente muda de endereço, você só atualiza em uma tabela. Em tabelas não normalizadas, é fácil esquecer de atualizar em todas as linhas, o que gera inconsistência.

Minimização de anomalias

Anomalias de inserção: numa tabela não normalizada, pode rolar de não conseguir adicionar um registro sem informação extra. Tipo, não dá pra adicionar um pedido sem saber o nome do cliente.

Anomalias de atualização: podem rolar erros ao atualizar dados. Por exemplo, se mudar o nome do cliente em uma linha, em outra pode continuar o nome antigo.

Anomalias de exclusão: deletar um registro pode fazer você perder informação importante. Tipo, deletar um pedido também apaga o nome do cliente, se tudo estiver numa tabela só.

Redução do volume de dados

Normalizar geralmente diminui o tamanho do banco, já que elimina duplicidade. Isso é importante pra guardar grandes volumes de informação.

Desvantagens da normalização

1. Estrutura do banco mais complexa

Com o tempo, a normalização pode deixar o banco bem complexo, com milhares(!) de tabelas conectadas. Aí, pra pegar dados que antes estavam numa tabela só, você precisa fazer SQLs mais complicados com vários JOIN.

Exemplo de complexidade:

-- Query pra pegar info dos pedidos com detalhes dos produtos e categorias
SELECT
    o.order_id,
    o.order_date,
    c.customer_name,
    p.product_name,
    cat.category_name,
    oi.quantity,
    oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;

Se o número de tabelas e relações cresce, o tempo das queries pode aumentar bastante.

2. Queda de performance com muitos joins

Fazer muitos JOIN pode pesar, principalmente se as tabelas forem grandes e não tiverem índices. Em sistemas analíticos, onde as queries processam milhões de linhas, a normalização pode dar uma bela prejudicada na performance.

3. Precisa de operações extras pra desnormalizar

Se a estrutura normalizada do banco é usada pra análise, às vezes você vai precisar desnormalizar temporariamente pra acelerar as queries analíticas. Isso pode envolver criar views (VIEW) ou tabelas de agregação.

Exemplo:

-- View desnormalizada pra analytics
CREATE VIEW orders_with_customers AS
SELECT
    o.order_id,
    o.order_date,
    c.customer_name,
    c.customer_address
FROM
    orders o
JOIN
    customers c ON o.customer_id = c.customer_id;

4. Barreira de entrada alta

Pra quem tá começando, normalização pode parecer difícil. Em vez de uma tabela só com tudo, você tem que lidar com várias tabelas e entender como elas se conectam. Isso pode atrasar o desenvolvimento, principalmente se o time não manja muito de banco de dados.

5. Às vezes a redundância é útil

Na vida real, às vezes é melhor manter dados redundantes pra ganhar performance. Por exemplo, se o app usa direto dados que só dá pra pegar com um join complicado, pode ser melhor guardar tudo numa tabela só.

1

Pesquisa/teste

Análise de bancos de dados existentes, nível 26, lição 4

Indisponível

Análise de bancos de dados existentes

Análise de bancos de dados existentes

Abrir