Modelação de Dados

07/06/2023
_____________________________________________________________________

1. Normalização

Fundamenta-se com base em anomalias existentes na construção de bases

de dados. Estas anomalias são divididas em três:

● Inserção = ocorre quando se ocorre um dado novo (cadastro) no banco de

dados. Neste caso, não é possível cadastrar um novo dado a não ser que outro
dado esteja disponível.
○ Ex. não é possível adicionar um novo livro sem que um autor esteja
cadastrado, ou seja, se não há o autor na tabela de autores, o livro não
pode ser cadastrado; outro é que só se pode inserir dados de um cliente
em fatura se o cliente já existir;

● Atualização = ocorre quando dados são atualizados em uma tabela não são
modificados nas demais as quais o dado atualizado faz relação;
○ ex. se for alterado o ID de um autor na tabela de autores, o ID também
deve ser alterado na tabela de livros e em todas as tabelas com
dependência do ID do autor;

● Eliminação = ao excluir os registros em uma tabela, os dados relacionados ao

dado eliminado em outras tabelas também serão excluídos;
○ ex. se for excluído um autor, todos os livros deste autor na tabela de
livros também serão incluídos;

Para eliminar essas anomalias, é preciso utilizar métodos de Normalização,

que consiste em processo de análise de uma relação para assegurar que ela seja bem
formada, produzindo relações menores e bem-estruturadas de modo a evitar o
surgimento de anomalias e dados multivalor*. São dividas em 5 níveis, mas nesta
cadeira, veremos 3 delas.
* Ocorre quando uma entidade tem mais de um registro em um campo, por exemplo, um cliente com mais
de um número de telefone em tabelas multivaloradas possui dois registros e cada um com cada número
de telefone associado a sua identificação. O problema desta metodologia é a duplicidade dos dados,
ocupação excessiva de memória etc.

- Minimizam redundância de dados;

- Minimizam anomalias;
- Deve ser feita em todos os níveis (existem 5 níveis de normalização, mas
geralmente são usados 3);
- Deve ser aplicada em TODAS as tabelas do BD;
_____________________________________________________________________

2. Dependência Funcional

Atributos funcionalmente dependentes em um banco de dados compõem dois

conjuntos de atributos, A e B de uma entidade que sua existência é baseada na
existência de outras entidades dominantes. Desta maneira, diz-se que:

- B é funcionalmente dependente de A; ou
- A determina B; ou
- B depende de A; ou
- A → B;

ex.
● O preço de um produto depende do artigo para existir;
● O telefone de um fornecedor de peças é dependente do código do fornecedor,
não do código da peça que ele vende;
● Um departamento não determina os funcionários. A existência dos funcionários
condiciona a existência dos departamentos.

NOTA: a identificação de dependências funcionais não pode ser definida apenas pela
inspeção de algumas instâncias, mas através das propriedades (natureza) de cada
atributo.
 1. Primeira Forma Normal

Foi definida para reprovar atributos multivalor. Os dados de cada campo

devem ter somente valores absolutos.

Uma tabela está na primeira forma normal quando:

● Somente possui valores nucleares;

● Não há grupos de atributos repetidos (um dado por coluna nas linhas);
● Existe uma chave primária;
● Sem atributos de multivalor;
● Elementos que representam o nível mais baixo de detalhamento;

Ex. um campo de endereço eventualmente será transformado em uma tabela e são

dissociados campos aos seus subcampos para separá-los, ou seja, a entidade
endereço terá um campo destinado ao número, a rua, o bairro, a freguesia, a cidade e
o país.
Outro exemplo é o campo nome, que minimamente deve ser dividido em nome
e apelido.

Exemplo disso é a tabela abaixo para inserção do cadastro de clientes em uma

base de dados. Na prática, abaixo uma tabela sem normalização na primeira FN, que
apresenta números de telefone repetidos:
 No círculo, campos multivalorados

Agora uma tabela normalizada:

Agora, há uma tabela telefone dedicada somente para armazenar os dados de

telefone de cada um dos clientes, no caso de terem mais de um número associado.

_____________________________________________________________________

2. Segunda Forma Normal

Identifica-se atributos que são totalmente e funcionalmente dependentes do

primary key.
Para estar na segunda forma normal:

- A tabela está na primeira forma normal;

- Todos os atributos não-chave dependem totalmente da chave primária;
- Caso a PK tenha somente um atributo, não precisa ser aplicado, pois os
demais atributos são já são dependentes da primary key;

Exemplo disso é a seguinte tabela de fornecedores de peças industriais. Na

prática, tem-se essa tabela de peças e fornecedores:

● O código da peça e o código do fornecedor são chaves primárias, que

formam uma chave primária composta, portanto, para estar na 2FN, todos os
campos devem depender inteiramente das duas chaves;
● O local do fornecedor depende do código do fornecedor, mas não
necessariamente do código da peça;
● A quantidade em estoque depende do código da peça, mas não depende
inteiramente do código do fornecedor;
● O telefone do fornecedor depende inequivocamente do código do fornecedor,
mas não tem qualquer relação com o código da peça;
Agora em uma tabela normalizada:

● Os atributos que eram funcionalmente dependentes do código do fornecedor

formaram uma tabela a parte;
● Os atributos funcionalmente dependentes de ambas as PK foram agrupados
na tabela, tornando o atributo menos dependente do código do fornecedor uma
foreign key, ou chave estrangeira, advinda da tabela fornecedor.
_____________________________________________________________________

3. Terceira Forma Normal

Identifica-se atributos que são transitivamente dependentes de outros atributos,

mas que não sejam a chave primária. É o objetivo final da normalização. As demais
técnicas de normalização 4 e 5 são desenvolvidas para bancos de dados com
restrições de domínios e chaves:

Para estar na terceira forma normal:

● Quando já estiver na segunda;

● Nenhuma coluna não-chave depender de outras colunas não-chave;
● Para cada atributo não-chave que for determinante na relação, crie uma nova
tabela;
 Exemplo de uma tabela de vendedores em uma superfície comercial. Na
prática, tem essa tabela de vendas:

● O nome do vendedor depende código do vendedor, que não é chave

primária;

Agora, para normalizar a tabela:

● O código do vendedor torna-se chave primária em uma tabela “vendedor”,

que designa um vendedor pelo seu nome, conforme a dependência funcional;
● Associa-se em uma chave estrangeira o código de vendedor na tabela
“venda”, então caso queira saber quem foi o vendedor que efetuou as vendas,
puxa-se os dados da tabela “vendedor”.