Descrever a normalização
A normalização do banco de dados é um processo de design usado para organizar dados em tabelas e colunas dentro de um banco de dados. Cada tabela deve conter dados relacionados a uma entidade específica e incluir apenas informações que suportem essa entidade. O objetivo principal da normalização é minimizar dados duplicados no banco de dados, o que ajuda a evitar a degradação do desempenho durante inserções e atualizações. Por exemplo, se o endereço de um cliente precisar ser atualizado, é mais simples implementar a alteração se o endereço estiver armazenado em um único local, como a Customers tabela.
As formas mais comuns de normalização são primeira, segunda e terceira formas normais.
Primeira forma normal
A primeira forma normal tem as seguintes especificações:
- Criar uma tabela separada para cada conjunto de dados relacionados
- Elimine grupos repetitivos em tabelas individuais
- Identificar cada conjunto de dados relacionados com uma chave primária
Neste modelo, você deve evitar o uso de várias colunas em uma única tabela para armazenar dados semelhantes. Por exemplo, se um produto pode vir em várias cores, você não deve ter várias colunas em uma única linha contendo os diferentes valores de cor. A primeira tabela a seguir, ProductColors, não está na primeira forma normal porque tem valores repetitivos para cor. Para produtos com apenas uma cor, há espaço desperdiçado. Além disso, se um produto vem em mais de três cores, torna-se impraticável definir um número máximo de colunas. Em vez disso, podemos recriar a tabela como mostrado na segunda tabela, ProductColor.
O primeiro formulário normal também requer que haja uma chave exclusiva para a tabela, que é uma coluna (ou colunas) cujo valor identifica exclusivamente cada linha. Na segunda tabela, nenhuma das colunas é exclusiva por si só, mas juntas, a combinação de ProductID e Color forma uma chave exclusiva. Quando várias colunas são necessárias para criar uma chave exclusiva, ela é chamada de chave composta.
ProductColorsTabela:#B0 ProductID #C1 Cor1 Color2 Color3 1 Vermelho Verde Amarelo 2 Amarelo 3 Azul Vermelho 4 Azul 5 Vermelho ProductColorTabela:ProductID Cor 1 Vermelho 1 Verde 1 Amarelo 2 Amarelo 3 Azul 3 Vermelho 4 Azul 5 Vermelho
A terceira tabela, ProductInfo, está na primeira forma normal porque cada linha se refere a um determinado produto, não há grupos repetitivos e temos a coluna ProductID para usar como chave primária.
| #B0 IdentificaçãoDoProduto #C1 | Nome do Produto | Preço | #B0 ProductionCountry #C1 | #B0 #C1 ShortLocation |
|---|---|---|---|---|
| 1 | Widget | 15.95 | Estados Unidos da América | EUA |
| 2 | Foop | 41.95 | Reino Unido | Reino Unido |
| 3 | Glombit | 49.95 | Reino Unido | Reino Unido |
| 4 | Sorfina | 99.99 | República das Filipinas | RepPhil |
| 5 | Parafuso de fixação | 29.95 | Estados Unidos da América | EUA |
Segunda forma normal
A segunda forma normal tem as seguintes especificações, para além das exigidas pela primeira forma normal:
- Se a tabela tiver uma chave composta, todos os atributos devem depender da chave completa e não apenas de parte dela.
A segunda forma normal só é relevante para tabelas com chaves compostas, como na tabela ProductColor, que é a segunda tabela. Considere o caso em que a ProductColor tabela também inclui o preço do produto. Esta tabela tem uma chave composta em ProductID e Color, porque somente usando ambos os valores de coluna podemos identificar exclusivamente uma linha. Se o preço de um produto não mudar com a cor, poderemos ver os dados conforme mostrado nesta tabela.
| ProductID | Cor | Preço |
|---|---|---|
| 1 | Vermelho | 15.95 |
| 1 | Verde | 15.95 |
| 1 | Amarelo | 15.95 |
| 2 | Amarelo | 41.95 |
| 3 | Azul | 49.95 |
| 3 | Vermelho | 49.95 |
| 4 | Azul | 99,95 |
| 5 | Vermelho | 29.95 |
Esta tabela não está na segunda forma normal. O valor do preço depende do ProductID mas não do Color. Existem três linhas para ProductID 1, de modo que o preço desse produto é repetido três vezes. O problema com a violação da segunda forma normal é que, se precisarmos atualizar o preço, devemos garantir que ele seja atualizado em todos os lugares. Se atualizarmos o preço na primeira linha, mas não na segunda ou terceira, encontraríamos uma anomalia de atualização. Após a atualização, não seria possível determinar o preço real do ProductID 1. A solução é mover a Price coluna para uma tabela que tenha ProductID como uma única chave de coluna, porque essa é a única coluna da qual Price depende. Por exemplo, poderíamos usar a Tabela 3 para armazenar o Pricearquivo .
Se o preço de um produto fosse diferente com base na sua cor, a quarta tabela seria na segunda forma normal, uma vez que o preço dependeria de ambas as partes da chave: o ProductID e o Color.
Terceira forma normal
A terceira forma normal é tipicamente o objetivo para a maioria dos bancos de dados OLTP. A terceira forma normal tem as seguintes especificações, para além das exigidas pela segunda forma normal:
- Todas as colunas não-chave são não transitivamente dependentes da chave primária.
Uma relação transitiva implica que uma coluna numa tabela está relacionada com outras colunas através de uma segunda coluna. Dependência significa que uma coluna pode derivar seu valor de outra como resultado dessa relação. Por exemplo, a sua idade pode ser determinada a partir da sua data de nascimento, tornando a sua idade dependente da sua data de nascimento. Consulte novamente a terceira tabela, ProductInfo. Esta tabela está na segunda forma normal, mas não na terceira. A ShortLocation coluna depende da ProductionCountry coluna, que não é a chave. Como a segunda forma normal, violar a terceira forma normal pode levar a anomalias de atualização. Acabaríamos com dados inconsistentes se atualizássemos o ShortLocation em uma linha, mas não o atualizássemos em todas as linhas onde esse local ocorreu. Para evitar isso, poderíamos criar uma tabela separada para armazenar nomes de países/regiões e seus formulários abreviados.
Desnormalização
Embora a terceira forma normal seja teoricamente desejável, nem sempre é possível para todos os dados. Além disso, um banco de dados normalizado nem sempre oferece o melhor desempenho. Os dados normalizados frequentemente requerem várias operações de junção para obter todos os dados necessários retornados em uma única consulta. Há uma compensação entre normalizar dados quando o número de junções necessárias para retornar resultados de consulta tem alta utilização da CPU e dados desnormalizados que têm menos junções e menos CPU necessária, mas abre a possibilidade de anomalias de atualização.
Dados desnormalizados podem ser mais eficientes para consulta, especialmente para cargas de trabalho intensivas em leitura, como um armazém de dados. Nesses casos, ter colunas extras pode oferecer melhores padrões de consulta e/ou consultas mais simplistas.
Esquema em estrela
Enquanto a maioria da normalização é destinada a cargas de trabalho OLTP, os data warehouses têm sua própria estrutura de modelagem, que normalmente é um modelo desnormalizado . Esse design usa tabelas de fatos para registrar medições ou métricas para eventos específicos, como vendas, e as une a tabelas de dimensão. As tabelas de dimensão são menores em termos de contagem de linhas, mas podem ter um grande número de colunas para descrever os dados de fato. Exemplos de dimensões incluem inventário, tempo e geografia. Esse padrão de design torna o banco de dados mais fácil de consultar e oferece ganhos de desempenho para cargas de trabalho de leitura.
#B0 #C1 #C0 #A3 #A4 #C5
A imagem ilustra um exemplo de um esquema em estrela, apresentando uma FactResellerSales tabela de fatos e dimensões para data, moeda e produtos. A tabela de fatos contém dados relacionados a transações de vendas, enquanto as dimensões contêm apenas dados relacionados a elementos específicos dos dados de vendas. Por exemplo, a FactResellerSales tabela inclui apenas um ProductKey para indicar qual produto foi vendido. Todos os detalhes sobre cada produto são armazenados na DimProduct tabela e são relacionados de volta à tabela de fatos usando a ProductKey coluna.
Relacionado com o design do esquema em estrela é o esquema em floco de neve, que utiliza um conjunto de tabelas mais normalizadas para uma única entidade comercial. A imagem a seguir ilustra um exemplo de uma única dimensão em um esquema de flocos de neve. A dimensão Produtos é normalizada e armazenada em três tabelas: DimProductCategory, DimProductSubcategorye DimProduct.
Exemplo de Esquema Snowflake
A principal diferença entre os esquemas de estrela e floco de neve é que as dimensões em um esquema de flocos de neve são normalizadas para reduzir a redunância, o que economiza espaço de armazenamento. A contrapartida é que suas consultas exigem mais junções, o que pode aumentar sua complexidade e diminuir o desempenho.