FACULDADE DE TECNOLOGIA DE SÃO PAULO

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Thiago Aquino Lima – N° 21206956

Camila Aparecida Matias Meneghel – N° 21209967
Danilo Oliveira Alves – N° 22119819
Gabriela de Moraes da Silva – N° 21106306
João Marcos Lopes de Carvalho – N° 21206268
Juliana Marques – N° 1211357
Samira Mariano da Cruz – N° 21209985

Laboratório de Banco de Dados - IBD100

Professor: Paulo Roberto Bernice

SÃO PAULO
2024
 Normalização de Banco de Dados

1) FORMAS DE NORMALIZAÇÃO
A normalização é o procedimento de modelar o banco de dados ao projetar
a maneira como as informações serão armazenadas, com o objetivo de eliminar,
ou pelo menos minimizar, a redundância presente no banco. Esse processo
envolve a identificação de anomalias em uma relação e a subsequente
decomposição delas em relações mais bem estruturadas.
Um banco de dados aderente aos critérios de normalização diminui a carga
de trabalho na manutenção e previne o desperdício de espaço de
armazenamento. Por exemplo, quando um cliente é cadastrado no banco e seu
número de telefone está presente em múltiplas tabelas, qualquer modificação
nesse número requer atualizações em todas as tabelas. A eficácia dessa tarefa
é notavelmente aprimorada quando o número de telefone do cliente está
registrado em apenas uma tabela.
Segundo a Microsoft, o processo de normalização envolve a utilização de um
conjunto de regras denominadas formas normais. Ao avaliarmos o banco de
dados e constatarmos que ele adere às regras da primeira forma normal,
podemos afirmar que o banco se encontra na "primeira forma normal". Se o
banco estiver em conformidade com as três primeiras regras, então ele está na
"terceira forma normal". Embora haja conjuntos adicionais de regras para outros
níveis de normalização, a terceira forma normal é considerada o requisito mínimo
para a maioria das aplicações. A seguir, as cinco primeiras formas normais serão
abordadas com exemplos.

1° Forma Normal
Uma relação está na primeira forma normal quando todos os atributos contêm
apenas um valor correspondente, singular, e não existem grupos de atributos
repetidos. Isso significa que não são permitidas repetições nem campos que
possuam mais de um valor.
O primeiro passo é identificar a chave primária da tabela. Em seguida,
identificamos o grupo repetitivo e o retiramos da entidade. Após isso, criamos
uma nova tabela que inclui a chave primária da tabela original e o grupo
repetitivo.

Analisando o exemplo acima, podemos identificar dois problemas: há uma

pessoa com dois números de telefone e um endereço com diferentes valores,
incluindo rua e bairro. Para normalizar os dados, é necessário separar cada
informação em uma coluna individual e criar uma nova tabela que relacione a
pessoa aos seus números de contato.

Dessa maneira, como demonstrado nas tabelas acimas, alcançamos a

primeira forma normal, eliminando repetições e campos com múltiplos valores.

2° Forma Normal
Diz-se que uma tabela está na segunda forma normal quando ela satisfaz
todos os requisitos da primeira forma normal e, além disso, os registros na tabela
que não são chaves dependem inteiramente da chave primária, não apenas
parcialmente. A segunda forma normal lida com essas irregularidades e evita
redundância no banco de dados.
Para alcançar esse objetivo, é necessário identificar os valores que
dependem apenas parcialmente da chave primária e criar tabelas separadas
para conjuntos de valores que se aplicam a vários registros, relacionando essas
tabelas com chaves estrangeiras.
 No exemplo apresentado acima, notamos que a tabela possui uma coluna
que armazena o título do filme, onde ele foi alugado e sua associação com um
número de locação. No entanto, também está associado a um código, tornando-
o um valor que não é totalmente dependente da chave primária da tabela.
Se em algum momento precisarmos modificar o título de um filme, teríamos
que localizar e alterar os valores em cada linha da tabela, o que demandaria
tempo e esforço desnecessários. No entanto, ao criar uma tabela separada e
estabelecer relacionamentos com chaves estrangeiras, tornamos nosso banco
de dados mais organizado e eficiente para futuras consultas e manutenções que
possam ser necessárias.

3° Forma Normal
Se ao examinarmos uma tupla não encontrarmos um atributo não chave que
dependa de outro atributo não chave, podemos concluir que a entidade em
questão está na terceira forma normal, desde que isso não conflite com as
especificações da primeira e da segunda forma normal.
O procedimento primordial para organizar uma entidade de acordo com as
diretrizes da terceira forma normal envolve a identificação dos campos que não
dependem da chave primária e que dependem de outro campo não chave. Em
seguida, se necessário, separamos esses campos para criar uma tabela distinta.
 No exemplo fornecido, temos uma entidade que lista carros cadastrados,
incluindo o modelo, a quilometragem percorrida, o código do fabricante e o nome
do fabricante. É notável que o "nome_fab" está relacionado ao "cod_fab". Para
ajustar essa tabela de acordo com os padrões da terceira forma normal, é
necessário remover a coluna do nome do fabricante.
A coluna removida deve ser transferida para uma nova tabela, estabelecendo
uma relação adequada entre o nome do fabricante e o seu código. Abaixo, é
possível visualizar como essa nova entidade ficaria.

4° Forma Normal
Uma entidade alcança a quarta forma normal quando já se encontra na
terceira forma normal e não apresenta dependências multivaloradas entre seus
atributos. Em outras palavras, não existem campos que se repetem em relação
à chave primária, evitando assim redundâncias nas tuplas da entidade. O
objetivo é fragmentar essa relação para eliminar essas dependências funcionais.

No exemplo mencionado, temos uma tabela que relaciona músicas, cantores

e álbuns, contendo informações sobre as músicas. Uma música pode ser
interpretada por um artista e pode estar presente em um ou mais álbuns ou ser
interpretada por outros artistas. Para evitar a repetição de informações e resolver
esse problema de redundância, é necessário dividir a tabela em partes distintas.

5° Forma Normal
A Quinta Forma Normal (5FN) lida com situações em que uma informação
específica pode ser reconstruída a partir de informações menores combinadas.
Ela não difere da 4FN, a menos que haja uma constante simétrica que atue como
uma regra global entre as tabelas em questão. Na ausência dessa constante, se
o esquema estiver na 4FN, automaticamente estará também na 5FN.
Em exemplos práticos, consideremos o armazenamento de tuplas do tipo "um
vendedor vende produto x para a empresa y" da seguinte forma:

Até este ponto, o esquema está na Quarta Forma Normal, pois os fatos
multivalorados da empresa e do produto são dependentes. E, se assumirmos
que o vendedor vende produtos específicos para cada empresa, ele estará na
Quinta Forma Normal.
No entanto, suponhamos que uma nova regra global seja aplicada: "Se um
vendedor vende um tipo de produto e também vende para uma determinada
empresa, então ele vende esse produto para essa empresa." Ou seja, se ele
vende discos rígidos e vende para a Apple, automaticamente vende discos
rígidos da Apple. Se esta regra global for verdadeira, o esquema não estará mais
na Quinta Forma Normal, uma vez que uma constante simétrica foi introduzida.
Nesse caso, para que o esquema se enquadre na 5FN, seria necessário separar
o que ele vende de para quem ele vende.

Assim, a repetição de dados foi eliminada ao fragmentar a informação em

três partes distintas: As empresas para qual o vendedor vende, os produtos que
ele vende e os produtos que a companhia vende.
2) Criação da tabela

3) Código SQL

-- Tabela Clientes
CREATE TABLE Clientes (
Cod_Cliente INT PRIMARY KEY,
Nome_Cliente VARCHAR(255),
CGCCPF_Cliente VARCHAR(20),
Ender_Cliente VARCHAR(255),
Bairro_Cliente VARCHAR(100),
Cep_Cliente VARCHAR(10),
Cidade_Cliente VARCHAR(100),
UF_Cliente CHAR(2)
);
 -- Tabela Vendedores
CREATE TABLE Vendedores (
Cod_vendedor INT PRIMARY KEY,
Nome_vendedor VARCHAR(255)
);

-- Tabela ItensPedido
CREATE TABLE ItensPedido (
Id_Item INT AUTO_INCREMENT PRIMARY KEY,
Num_pedido INT,
Cod_Item INT,
QTD_Item INT,
Descric_Item VARCHAR(255),
Vl_unitario_Item DECIMAL(10, 2),
Vl_Total_Item DECIMAL(10, 2),
Perc_descto_Item DECIMAL(5, 2),
FOREIGN KEY (Num_pedido) REFERENCES Pedidos(Num_pedido)
);

-- Tabela Pedidos

CREATE TABLE Pedidos (

Num_pedido INT PRIMARY KEY,
Data_pedido DATE,
Cod_Cliente INT,
Cod_vendedor INT,
Vl_Total_pedido DECIMAL(10, 2),
Vl_liquido_pedido DECIMAL(10, 2),
FOREIGN KEY (Cod_Cliente) REFERENCES Clientes(Cod_Cliente),
FOREIGN KEY (Cod_vendedor) REFERENCES
Vendedores(Cod_vendedor);