- Sem dependências transitivas: Esta regra é fundamental. Em uma tabela 3NF, qualquer coluna não chave primária deve depender exclusivamente da chave primária, não indiretamente através de outra coluna não chave.
Vamos dar uma olhada em o que isso significa na prática.
Decompondo Tabelas para Alcançar a 3ª Forma Normal
Vamos seguir o processo de decomposição de tabelas para alcançar a 3ª Forma Normal. Usaremos alguns dados de exemplo dos cursos da DataCamp para ilustrar cada etapa.
Passo 1: Identificar dependências transitivas
Para começar, vamos procurar por quaisquer atributos em uma tabela que dependem indiretamente da chave primária. Como regra geral, se algum atributo depende de algo que não seja a chave primária, isso indica uma dependência transitiva. Isso é um sinal de que pode ser hora de dividir sua tabela.
Dê uma olhada nas três tabelas abaixo. Qual delas possui uma dependência transitiva?
Tabela 1: Curso
Course ID | Course Name | Difficulty |
---|---|---|
201 | SQL Fundamentals | Iniciante |
202 | Introdução ao Python | Iniciante |
203 | Compreensão de Ciência de Dados | Intermediário |
Tabela 2: Instrutor
Instructor ID | Instructor Name | Expertise |
---|---|---|
1 | Sarah Johnson | Ciência de Dados |
2 | Tom Williams | Aprendizado de Máquina |
3 | Emily Brown | Python |
Tabela 3: Inscrições
Enrollment ID | Student Name | Course ID | Course Name |
---|---|---|---|
1001 | Alice Smith | 201 | Fundamentos de SQL |
1002 | Bob Green | 202 | Introdução ao Python |
1003 | Charlie Blue | 201 | Fundamentos de SQL |
A resposta é… Tabela 3!
Nesta tabela, Nome do Curso depende do ID do Curso, mas não diretamente do ID de Matrícula (a chave primária). Essa dependência indireta torna o Nome do Curso uma dependência transitiva.
Passo 2: Separar dados em novas tabelas
Para resolver a dependência transitiva, vamos dividir a Tabela 1 em duas tabelas. Cada tabela vai focar nos dados diretamente dependentes.
Tabela de matrículas revisada
Enrollment ID | Student Name | Course ID |
---|---|---|
1001 | Alice Smith | 201 |
1002 | Bob Green | 202 |
1003 | Charlie Blue | 201 |
Tabela de cursos
Course ID | Course Name |
---|---|
201 | SQL Fundamentals |
202 | Introdução ao Python |
Agora, cada tabela contém apenas informações que dependem diretamente de sua chave primária: ID do Curso é agora a chave primária para Nome do Curso na tabela Cursos, e ID de Matrícula é a chave primária na tabela Matrículas.
Com essa decomposição, as tabelas agora atendem aos requisitos da 3NF, eliminando a redundância e garantindo que cada tabela armazene apenas informações diretamente relevantes.
Se você deseja colocar a mão na massa e criar seus próprios bancos de dados, dê uma olhada no nosso curso Criando Bancos de Dados PostgreSQL. Se você estiver um pouco mais avançado, poderá experimentar o Introdução à Modelagem de Dados no Snowflake, que aborda ideias como modelagem entidade-relacionamento e dimensional.
Benefícios e Limitações do Uso da Terceira Forma Normal
Então, por que passar por todo esse esforço para alcançar a 3NF? Aqui estão as principais vantagens:
- Melhoria da Integridade dos Dados: Ao eliminar dependências transitivas, a 3NF ajuda a garantir que atualizações e exclusões não levem a dados conflitantes ou desatualizados em várias tabelas.
- Redução de Redundância: Menos redundância significa que seu banco de dados é mais fácil de manter e o uso de armazenamento é reduzido.
- Manutenção de Dados Mais Simples: Manter informações semelhantes em tabelas dedicadas facilita a atualização de registros sem precisar rastrear entradas redundantes.
Dito isso, enquanto as estruturas de 3NF suportam a precisão dos dados, também podem levar a dados mais segmentados, às vezes tornando consultas complexas mais lentas devido a junções de tabelas adicionais. Em casos em que a necessidade de velocidade supera a necessidade de normalização, BCNF ou 4NF podem ser opções mais práticas.
Comparação: Primeira, Segunda, Terceira e Formas Normais BC
Vamos dar uma olhada nas diferenças de formas.
Tabela de comparação: primeira, segunda e terceira formas normais
Aqui está uma tabela de comparação para ajudá-lo a entender os requisitos de 1NF, 2NF e 3NF.
O BCNF é uma forma “mais rigorosa” da 3NF que elimina ainda mais anomalias que surgem com chaves candidatas sobrepostas. Pode ser especialmente útil em casos complexos onde a 3NF sozinha não elimina completamente as dependências. O BCNF se aplica quando um atributo não-primo depende de um atributo que faz parte de uma chave candidata composta. Eu sei que isso parece complexo, então vamos explicar com um exemplo.
**Estrutura atual (em 3NF)**
Depois da decomposição para atingir a 3NF, tínhamos estas duas tabelas:
Tabela de Matrículas
Tabela de Cursos
Course ID | Course Name |
---|---|
201 | Fundamentos de SQL |
202 | Introdução ao Python |
Nesta estrutura, cada tabela está na 3NF sem dependências transitivas, e os dados estão normalizados adequadamente.
Introdução de um novo requisito
Agora, vamos adicionar um novo atributo a Cursos: a Sala de Aula na qual cada curso é ministrado. Este novo atributo poderia resultar em um cenário que requer BCNF.
Tabela de cursos atualizada (3NF)
Course ID | Course Name | Classroom |
---|---|---|
201 | Fundamentos de SQL | Sala 101 |
202 | Introdução ao Python | Sala 102 |
203 | Compreensão da Ciência de Dados | Sala 101 |
Aqui, ID do Curso ainda é a chave primária, e todos os outros atributos dependem diretamente dela. Mas vamos supor que haja uma nova regra de que cada sala de aula pode conter apenas uma disciplina por vez. Vamos também supor que o Nome do Curso “SQL Fundamentals” poderia ser oferecido sob diferentes IDs de Curso (como 201, 204, etc.), se fossem agendados em horários diferentes. Nesse caso, cada oferta de “SQL Fundamentals” ainda ocorreria na “Sala 101”, independentemente do ID do Curso específico. Como resultado, o Nome do Curso também determina de forma única a Sala de Aula.
Isso significa que agora temos duas chaves candidatas:
- ID do Curso
- Nome do Curso
Com ambas as chaves candidatas, agora temos um problema que a 3NF não aborda: Sala de Aula depende de Nome do Curso em vez de apenas ID do Curso.
Aplicando a BCNF
Para eliminar este problema de dependência, precisaremos decompor ainda mais a Cursos tabela em duas tabelas separadas que se alinhem melhor com a BCNF:
- Uma nova tabela de Cursos, que inclui apenas o ID do Curso e Nome do Curso.
- Uma tabela CourseDetails, que armazena a Nome do Curso e associação com a Sala de Aula.
Aqui está como isso se parece:
Tabela de cursos revisada (BCNF)
Tabela de Detalhes do Curso (BCNF)
Course Name | Classroom |
---|---|
Fundamentos de SQL | Sala 101 |
Introdução ao Python | Sala 102 |
Compreensão da Ciência de Dados | Sala 101 |
- N a tabela de Cursos, o ID do Curso é a chave primária, e todos os atributos dependem exclusivamente dele.
- No quadro CourseDetails, Nome do Curso é a chave primária, e Sala de Aula depende apenas do Nome do Curso.
Esta configuração remove quaisquer problemas de dependência causados por chaves candidatas sobrepostas, garantindo uma estrutura estritamente normalizada.
Conclusão
A terceira forma normal é uma ferramenta valiosa para os designers de banco de dados que visam manter os dados limpos, consistentes e livres de dependências problemáticas. Com a 3NF, a integridade dos dados é aprimorada, tornando a gestão mais suave e reduzindo a redundância. Lembre-se, enquanto a 3NF funciona bem na maioria das situações, bancos de dados mais complexos podem se beneficiar de formas adicionais como BCNF ou 4NF.
Se você achou este artigo útil, considere dar o próximo passo obtendo nossa Certificação de Associado em SQL. É uma ótima maneira de validar suas habilidades em SQL e gerenciamento de banco de dados e demonstrar sua expertise para potenciais empregadores!