Introdução à normalização do banco de dados As três primeiras formas normais

O objetivo de uma normalização do banco de dados relacional é alcançar e melhorar integridade de dados e evite redundância de dados Portanto, para evitar possíveis inserções, atualização ou exclusão de anomalias. Um banco de dados relacional é normalizado aplicando uma série de regras chamadas formulários normais. Neste artigo, discutiremos as três primeiras formas normais.

Neste tutorial, você aprenderá:

• Qual é a primeira forma normal
• Qual é a segunda forma normal
• Qual é a terceira forma normal

Requisitos de software e convenções usadas

A primeira forma normal

Suponha que tenhamos a tabela a seguir que usamos para armazenar informações sobre alguns filmes:

+----+--------------------+--------------------+------+ | id | nome | gênero | ano | +----+--------------------+--------------------+- ----+ | 1 | O exorcista | Horror | 1973 | | 2 | Os suspeitos usuais | Suspense, Neo-noir | 1995 | | 3 | Guerra nas Estrelas | Space-Opera | 1977 | +----+--------------------+--------------------+------+ 

A tabela acima, não satisfaz o Primeira forma normal, por que? Para que a primeira forma normal seja satisfeita, cada coluna de uma tabela deve conter atômico Dados (indivisíveis). Na segunda fila da nossa mesa, que contém informações sobre o filme "os suspeitos usuais", podemos ver que o gênero A coluna contém dados que não são atômicos. Dois gêneros estão realmente listados: thriller e neo-noir. Digamos que, em nossa representação, queremos permitir que um filme seja associado a mais de um gênero; Como resolvemos o problema?

A primeira coisa que vem à mente pode ser adicionar uma nova linha na mesma tabela, repetindo as informações sobre o filme e apenas especificar um gênero por cru. Essa ideia é bastante horrível, já que teríamos muitos dados redundantes (devemos repetir as mesmas informações de filme cada vez que queremos associá -las a um novo gênero!).

Outra solução um pouco melhor, seria adicionar uma nova coluna, então ter, por exemplo, um Gênero1 e Gênero2 colunas. No entanto, isso, entre as outras coisas, representaria um limite: e se um filme deve ser listado em mais de dois gêneros?

Uma maneira mais inteligente de resolver esse problema é criar uma nova tabela usada para armazenar informações de gêneros. Aqui está a tabela de "gênero":

+----+-------------+ | id | nome | +----+-------------+| 1 | Horror | | 2 | Neo-noir | | 3 | Space-Opera | | 4 | Thriller | +----+-------------+ 

Agora, já que o entre gênero e filme é um muitos para muitos Relacionamento (um filme pode estar relacionado a vários gêneros, e um gênero pode estar relacionado a muitos filmes diferentes), para expressá -lo sem redundância de dados, podemos usar um SO
chamado Tabela de junção:

+----------+----------+ | filme_id | gênero_id | +----------+----------+| 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Nossa tabela de junção tem a única tarefa de expressar o relacionamento muitos para muitos entre as duas tabelas ou entidades filme e gênero. É composto por apenas duas colunas: filme_id e gênero_id. O filme_id A coluna tem um Chave estrangeira restrição ao eu ia coluna do filme mesa e o gênero_id tem uma restrição de chave estrangeira para o eu ia coluna do gênero mesa. As duas colunas juntas são usadas como um composto chave primária, então a relação entre um filme e um gênero pode ser expressa apenas uma vez. Neste ponto, podemos remover a coluna "gênero" da tabela "filme":

+----+--------------------+------+ | id | nome | ano | +----+--------------------+------+| 1 | O exorcista | 1973 | | 2 | Os suspeitos usuais | 1995 | | 3 | Guerra nas Estrelas | 1977 | +----+--------------------+------+ 

A tabela está agora na primeira forma normal.

A segunda forma normal

A primeira forma normal é um pré -requisito para o segundo: para que a segunda forma normal seja satisfeita, os dados já devem estar em Primeira forma normal E não deve haver nenhum dependência parcial de atributos secundários de um subconjunto de qualquer Chave candidata.

O que é uma dependência parcial? Vamos começar dizendo que em uma mesa poderia haver mais de um Chave candidata. Uma chave candidata é uma coluna, ou um conjunto de colunas que juntas podem ser identificadas como exclusivas em uma tabela: apenas um dos
Keys candidatos, será escolhido como a mesa chave primária, que identifica exclusivamente cada linha.

Os atributos que fazem parte das chaves do candidato são definidos como melhor, Enquanto todos os outros são chamados secundário. Para que uma relação esteja em segunda forma normal, não deve haver um atributo secundário que depende de um subconjunto
de uma chave candidata.

Vamos ver um exemplo. Suponha que tenhamos uma mesa que usamos para armazenar dados sobre jogadores de futebol e suas pontuações para cada dia para um aplicativo de futebol de fantasia, algo assim:

+-----------+------------+-----------+------------+---------+-------+ | player_id | primeiro_name | Último nome | papel | GameDay | pontuação | +-------------+------------+-----------+-------------- +---------+-------+| 111 | Cordaz | Alex | Goleiro | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Goleiro | 18 | 7.50 | | 124 | Handanovic | Samir | Goleiro | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Vamos dar uma olhada nesta mesa. Primeiro de tudo, podemos ver que ela satisfaz a primeira forma normal, pois os dados em cada coluna são atômicos. Os dados contidos no player_id A coluna pode ser usada para identificar exclusivamente um jogador, mas
pode ser usado como chave primária para a tabela? A resposta é não, porque uma linha para cada jogador existirá para cada dia! Aqui poderíamos usar um composto chave primária, em vez disso, feita pela combinação do player_id e Dia de jogo colunas, já que uma e apenas uma entrada pode existir para esse jogador para cada gameday.

Esta tabela satisfaz a segunda forma normal? A resposta é não, vamos ver o porquê. Dissemos anteriormente que cada atributo que não faz parte de nenhuma chave de candidato é chamado secundário e para a tabela satisfazer o segundo normal
forma não deve depender de um subconjunto de qualquer chave candidata, mas deve depender da chave do candidato como um todo.

Vamos pegar o papel atributo, por exemplo. É um atributo secundário, pois não faz parte de nenhuma chave candidata. Podemos dizer que é funcionalmente dependente de player_id, Como se o jogador mudar, também o papel associado pode mudar; No entanto, não depende de Dia de jogo, que é o outro componente da chave primária composta, pois mesmo que o GameDay mude o papel do jogador permanece o mesmo. Nós podemos dizer que papel é funcionalmente dependente de um subconjunto da chave primária composta, portanto, a segunda forma normal não é satisfeita.

Para resolver o problema, podemos criar uma tabela separada usada para descrever exclusivamente cada jogador:

+-----------+------------+-----------+------------+ | player_id | primeiro_name | Último nome | papel | +-------------+------------+-----------+-------------- + | 111 | Cordaz | Alex | Goleiro | | 117 | Donnarumma | Gianluigi | Goleiro | | 124 | Handanovic | Samir | Goleiro | +-----------+------------+-----------+------------+ 

Agora podemos remover essas informações da tabela de pontuação e fazer com que pareça desta maneira:

+-----------+---------+-------+ | player_id | GameDay | pontuação | +-------------+---------+-------+| 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

A segunda forma normal agora está satisfeita.

A terceira forma normal

A segunda forma normal é um pré-requisito para a terceira forma normal. Para estar na terceira forma normal, uma tabela já deve estar em segunda forma normal e não deve conter atributos que são dependente transitivamente na tabela chave primária. O que isso significa? Podemos dizer que temos um dependência transitiva Quando um atributo secundário não depende diretamente da chave primária da tabela, mas depende de outro atributo secundário. Suponha que adicionemos duas novas colunas ao jogador Tabela acima, então se parece assim:

+-----------+------------+-----------+------------+---------+-----------+ | player_id | primeiro_name | Último nome | papel | Clube | Club_City | +-------------+------------+-----------+-------------- +---------+-----------+| 111 | Cordaz | Alex | Goleiro | Crotone | Crotone | | 117 | Donnarumma | Gianluigi | Goleiro | Milão | Milano | | 124 | Handanovic | Samir | Goleiro | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Adicionamos o clube e Club_City colunas para a tabela para especificar, respectivamente, o clube associado a um jogador, e a cidade que o clube pertence. Infelizmente a tabela agora não satisfaz o Terceira forma normal, por que? É bastante simples: o Club_City atributo não depende diretamente de player_id, Qual é a chave primária da tabela, mas tem uma dependência transitiva, através de outro atributo secundário: clube.

Como resolver o problema para que a terceira forma normal seja satisfeita? Tudo o que precisamos fazer é criar outra tabela, onde gravar informações sobre cada clube. Aqui está a tabela "Clube":

+-----------+-----------+ | Club_name | Club_City | +-------------+-----------+| Crotone | Crotone | | Milão | Milano | | Inter | Milano | +-----------+-----------+ 

Isolamos informações do clube em uma tabela dedicada. Como chave primária para a tabela, neste caso, usamos o Club_name coluna. No jogador Tabela agora podemos remover Club_City coluna e adicione uma restrição de chave estrangeira ao clube coluna para que ela referencia o Club_name coluna no clube mesa:

+-----------+------------+-----------+------------+---------+ | player_id | primeiro_name | Último nome | papel | Clube | +-------------+------------+-----------+-------------- + ---------+ | 111 | Cordaz | Alex | Goleiro | Crotone | | 117 | Donnarumma | Gianluigi | Goleiro | Milão | | 124 | Handanovic | Samir | Goleiro | Inter | +-----------+------------+-----------+------------+---------+ 

A terceira forma normal agora está satisfeita.

Conclusões

Neste tutorial, conversamos sobre as três primeiras formas normais de um banco de dados relacional e como elas são usadas para reduzir a redundância de dados e evitar anomalias de inserção, exclusão e atualização. Vimos quais são os pré -requisitos de cada forma normal, alguns exemplos de suas violações e como consertá -los. Outras formas normais existem após o terceiro, no entanto, nas aplicações mais comuns, atingir a terceira forma normal é suficiente para obter uma configuração ideal.

Tutoriais do Linux relacionados:

• Coisas para instalar no Ubuntu 20.04
• Uma introdução à automação, ferramentas e técnicas do Linux
• Mastering Bash Script Loops
• Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
• Mint 20: Melhor que o Ubuntu e o Microsoft Windows?
• Arquivos de configuração do Linux: os 30 primeiros mais importantes
• Configurando o ZFS no Ubuntu 20.04
• Ubuntu 20.04 truques e coisas que você pode não saber
• Manipulação de big data para diversão e lucro Parte 1
• Loops aninhados em scripts de basquete