Qual é a terceira forma normal? (Bases de dados)

O Terceira forma normal (bancos de dados) É uma técnica de design de banco de dados relacional, onde as diferentes tabelas que a compõem não apenas atendem à segunda forma normal, mas todos os seus atributos ou campos dependem diretamente da chave principal.

Quando um banco de dados é projetado, o principal objetivo é criar uma representação precisa dos dados, das relações entre eles e as restrições aos dados que são relevantes.

Fonte: Pixabay.com

Para atingir esse objetivo, algumas técnicas de design de banco de dados podem ser usadas, entre as quais é a padronização.

Este é um processo de organização de dados em um banco de dados para evitar redundâncias e possíveis anomalias na inserção, atualização ou descarte dos dados, gerando para ele um design simples e estável do modelo conceitual.

Começa examinando a relação funcional ou dependência entre atributos. Estes descrevem algumas propriedades dos dados ou o relacionamento entre eles.

[TOC]

Formas normais

A padronização usa uma série de testes, chamados formas normais, para ajudar a identificar o agrupamento ideal desses atributos e finalmente estabelecer o conjunto de relacionamentos adequados que suportam os requisitos de dados de uma empresa

Ou seja, a técnica de normalização é construída em torno do conceito de maneira normal, que define um sistema de restrições. Se um relacionamento atender às restrições de uma maneira normal, diz -se que o relacionamento é dessa maneira normal.

Primeira forma normal (1FN)

Dizem que uma tabela está em 1FN se todos os atributos ou campos dentro dela contêm apenas valores únicos. Isto é, todo o valor para cada atributo deve ser indivisível.

Por definição, um banco de dados relacional sempre será normalizado para a primeira forma normal, porque os valores dos atributos são sempre atômicos. Todos os relacionamentos em um banco de dados estão em 1FN.

Pode servir a você: constante (programação): conceito, tipos, exemplos

No entanto, deixar o banco de dados simplesmente estimula uma série de problemas, como redundância e possíveis anomalias de atualização. As formas normais mais altas foram desenvolvidas para corrigir esses problemas.

Segunda forma normal (2FN)

Ele lida com a eliminação de uma mesa as unidades circulares. Dizem que uma proporção está em 2FN se estiver em 1FN e também cada campo ou atributo não depende completamente da chave primária, ou mais especificamente, é garantido que a tabela tenha um único propósito.

Um atributo não chave é qualquer atributo que não faz parte da chave primária para um relacionamento.

Terceira forma normal (3FN)

Ele trata de eliminar dependências transitivas de uma tabela. Isto é, eliminar atributos não -chave que não dependem da chave primária, mas de outro atributo.

Uma dependência transitiva é um tipo de dependência funcional na qual o valor de um atributo ou campo não é determinado pelo valor de outro campo que também não é essencial.

Valores repetidos devem ser buscados nos atributos não -chave para garantir que esses atributos que não são essenciais não dependem apenas da chave primária.

Dizem que os atributos são mutuamente independentes se nenhum deles depender funcionalmente de uma combinação de outros. Essa independência mútua garante que os atributos possam ser atualizados individualmente, sem o risco de afetar outro atributo.

Portanto, para que uma razão de banco de dados esteja na terceira forma normal, deve cumprir:

- Todos os requisitos 2FN.

Pode atendê -lo: TIC na casa

- Se houver atributos que não estão relacionados à chave primária, eles devem ser eliminados e colocados em uma tabela separada, relacionando as duas tabelas através de uma chave externa. Isto é, não deve haver dependência transitiva.

Exemplos da terceira forma normal

Exemplo 1

Seja a tabela de estudantes, cuja chave primária é a identificação do aluno (id_estudiant) e é composto pelos seguintes atributos: nome do aluno, rua, cidade e código detal, atendendo às condições a serem 2FN.

Nesse caso, a rua e a cidade não têm um relacionamento direto com a chave de identidade primária, pois eles não estão diretamente relacionados ao aluno, mas dependem totalmente do código postal.

Como o aluno está localizado pelo site determinado por code_postal, Street and City estão relacionados a este atributo. Devido a este segundo grau de dependência, não é necessário armazenar esses atributos na tabela de estudantes.

Crie uma nova tabela

Suponha que existam vários estudantes localizados no mesmo código postal, com a mesa do aluno tendo uma imensa quantidade de registros, e é necessário alterar o nome da rua ou da cidade, então esta rua ou cidade deve ser pesquisada e atualizada em todo o Aluno da mesa.

Por exemplo, se for necessário mudar a rua "El Limón" para "El Limón II", terá que procurar "El Limón" em toda a mesa do aluno e depois atualizá -lo para "El Limón II".

Encontre em uma tabela enorme e atualize os registros exclusivos ou múltiplos exigirá muito tempo e, portanto, afetará o desempenho do banco de dados.

Em vez disso, esses detalhes podem ser adquiridos em uma tabela separada (cartão postal) relacionado à tabela de estudantes usando o atributo code_postal.

A tabela postal terá uma quantidade comparativamente menor de registros e só precisará atualizar assim que esta tabela postal. Isso será refletido automaticamente na tabela de estudantes, simplificando os bancos de dados e consultas. Assim, as tabelas estarão em 3fn:

Pode servir a você: Metabusters: Características, tipos e exemplos

Exemplo 2

Seja a tabela a seguir com o campo num_project como a chave principal e com valores repetidos em atributos que não são chave.

O valor do telefone é repetido toda vez que o nome de um gerente é repetido. Isso ocorre porque o número de telefone tem apenas uma segunda dependência de graus com o número do projeto. Realmente depende do gerente, e isso, por sua vez, depende do número do projeto, o que torna uma dependência transitiva.

O atributo gerente_project não pode ser uma chave possível nos projetos da tabela, porque o mesmo gerente lida com mais de um projeto. A solução para isso é eliminar o atributo com dados repetidos (telefone), criando uma tabela separada.

Os atributos correspondentes devem ser agrupados, criando uma nova tabela para salvá -los. Os dados são inseridos e é verificado que os valores repetidos não fazem parte da chave primária. A chave primária para cada tabela é estabelecida e, se necessário, as chaves externas são adicionadas.

Para atender à terceira forma normal, uma nova tabela (gerentes) é criada para resolver o problema. Ambas as tabelas estão relacionadas através do campo Gerenciador_project:

Referências

1. Teradata (2019). Primeiro, segundo e terceira formas normais. Retirado de: documentos.Teradata.com.
2. Tutorial da Copa (2019). Terceira forma normal (3NF). Retirado de: TutorialCup.com.
3. Database Dev (2015). Terceira forma normal (3NF) - normalizando seu banco de dados. Retirado de: DatabasedEv.co.Reino Unido.
4. Relational DB Design (2019). Introdução à terceira forma normal. Retirado de: relacionaldbdesign.com.
5. Dummies (2019). SQL Primeiro, Segunda e Terceira formas normais. Retirado de: manequins.com.