Banco de Dados I – Aula 13

Tradução
Tradução de relacionamento maior que 2

• O relacionamento é transformado em uma entidade. Esta nova entidade é

ligado através de um relacionamento binário a cada uma das entidades que
participavam do relacionamentos original.
• Assim tem-se apenas relacionamentos binários.
• Aplica-se as regras do relacionamento binário.
Esquema textual equivalente

Produto (CodProd, Nome)

Cidade (CodCid, Nome)

Distribuidor (CodDistr, Nome)

Distribuicao (CodProd, CodCid, CodDistr, DataInicio)

CodProd referencia Produto
CodCid referencia Cidade
CodDistr referencia Distribuidor
Tradução de generalização / especialização

• Recomendado o uso de uma tabela para cada entidade especializada.

• Aplicar as regras correspondentes à implementação de entidades e

relacionamentos já apresentadas nas seções anteriores.

• Incluir a chave primária da entidade genérica, em cada entidade

especializada como FK e PK.
Emp (CodigoEmp, Nome, CIC, CodigoDept)
CodigoDept referencia Depto

Motorista (CodigoEmp, CartaHabil)

CodigoEmp referencia Emp

Engenheiro (CodigoEmp, CREA, CodigoRamo)

CodigoEmp referencia Emp
CodigoRamo referencia Ramo

Secretaria(CodigoEmp)
CodigoEmp referencia Emp

Depto (CodigoDept, Nome)

Ramo (CodigoRamo,Nome)

ProcessTexto (CodigoProc,Nome)

Domínio (CodigoEmp,CodigoProc)
CodigoEmp referencia Emp
Codigo Proc referencia ProcessTexto

Projeto (CodigoProj,Nome)

Participação (CodigoEmp,CodigoProj)
CodigoEmp referencia Emp
CodigoProj referencia Projeto
Formas Normais
Normalização

• Uma forma normal é uma regra que deve ser obedecida por uma tabela para
que esta seja considerada “bem projetada”.

• O processo de normalização pode ser visto como o processo no qual são

eliminados esquemas de relações (tabelas) não satisfatórios, decompondo-os,
através da separação de seus atributos em esquemas de relações menos
complexas, mas que satisfaçam as propriedades desejadas.

• Implica em conduzir um esquema de relação através de um bateria de testes

para certificar se o mesmo está nas Formas Normais (FN).

• Das 5 Formas Normais (regras) estudaremos as 3 primeiras, que são as

principais.
1ª Forma Normal
• Cada campo deve possuir apenas um valor.
▫ Não há sentido inserir mais de um valor (Alien, Predador) no mesmo campo
Locação
• Cada coluna deve armazenar registros únicos (a menos que seja chave
estrangeira).
▫ Não há sentido em repetir-se valores iguais em linhas diferentes na mesa
coluna.
▫ Ex: Locação(Cliente, Locação, Telefone).
▫ Risco do nome do cliente e/ou seu telefone constarem em várias linhas da
tabela.

• Prática:
▫ Eliminar tabelas aninhadas
▫ Usar chaves únicas
▫ Criar relacionamentos correctamente (verbos e tradução)
▫ Os atributos de uma tabela devem ser atômicos (indivisíveis),
▫ ou seja, não são permitidos atributos multivalorados, atributos compostos
ou atributos multivalorados compostos.
Exemplo 1FN
Exemplo 1FN

• O exemplo possui tabela aninhada (pode ser gerada por um atributo

multivalorado) que deve ser removido por não ser atómico.
Passagem para a 1FN

• Cria-se uma nova tabela

(relação) com os tributos
atómicos que não estavam
aninhados.

• Cria-se uma nova tabela

(relação) para a parte aninhada
apenas com atributos atómicos.
2ª Forma Normal
• Objectiva eliminar um tipo de redundância
• Deve estar na 1FN
• Se possuir chave primária composta, cada coluna não chave deve depender
da chave primária completa (dependência funcional total) e não de parte da
chave.
• Uma tabela que não se encontra na segunda formal contém dependências
funcionais parciais
▫ ou seja, contém colunas não chave que dependem apenas de uma parte da
chave primária.
• Observações:
▫ Tabelas com Chave primária não compostas já estão na 2FN
▫ Tabelas com Chave primária composta e sem outra coluna já estão na 2FN

• Prática:
▫ Fazer análise de dependência funcional.
▫ A coluna depende de toda a chave ou apenas de parte dela?
▫ Dividir tabelas e eliminar a dependência funcional.
Exemplo de 2FN

• No caso do exemplo anterior, a tabela Proj encontra-se na 2FN por possuir uma chave
primária simples (composta de apenas uma coluna).

• Já na tabela ProjEmp há redundância. Um exemplo é o do empregado de código “8191”.

• As colunas Nome, Cat e Sal dependem, cada uma, apenas da coluna CodEmp, já que nome,
categoria funcional e salário são determinados tão somente pelo número do empregado.

• Por sua vez, as colunas DataIni e TempAl dependem da chave primária completa.
Passagem para a 2FN

• Para eliminar as dependências de

parte da chave primária é necessário
dividir a tabela ProjEmp em duas
tabelas.

• Na tabela ProjEmp, ficam apenas as

colunas não chave que dependem
completamente da chave primária
composta.

• Cria-se a tabela Emp, com chave

primária que era parte da chave
composta anterior e com as colunas
não chave que dependem apenas de
sua chave.
3ª Forma Normal

• Na passagem à terceira forma normal, elimina-se um outro tipo de

redundância.
• Deve estar na 2FN
• Toda coluna não chave depende diretamente de chave primária,
▫ isto é, quando não há dependências funcionais transitivas ou indiretas.
▫ uma dependência funcional transitiva ou indireta acontece quando uma
coluna não chave primária depende funcionalmente de outra coluna ou
combinação de colunas não chave primária.

• Prática:
▫ Fazer análise de dependência funcional.
▫ Dividir tabelas e eliminar a dependência entre os atributos não chave.
Exemplo de 3FN

• Vamos supor que o salário (coluna Sal) de um empregado seja determinado pela
sua categoria funcional (coluna Cat).

• Neste caso, a informação de que salário é pago a uma categoria funcional está
representado redundantemente na tabela, tantas vezes quantos empregados
possui a categoria funcional.

• Observe na tabela que toda categoria A1 tem salário 4 e toda B1 tem salário 9.
Passagem para a 3FN

• Para eliminar as dependências de

parte da chave primária é necessário
dividir a tabela Emp em duas tabelas.

• Na tabela Emp, ficam as colunas não

chave sem dependência transitiva e a
coluna determinante.

• Cria-se a tabela Cat, com a coluna

determinante como chave primária e
a colunas dependentes como não
chave.
Resumo das três Formas Normais
Forma Teste
Normal
Primeira A relação não deve ter qualquer atributo
(1FN) não atômico nem relações agrupadas
(multivalores).
Segunda Para relações nas quais a chave primária
(2FN) contém múltiplos atributos, nenhum
atributo não chave deve ser funcionalmente
dependente de uma parte da chave
primária.
Terceira A relação não deve ter um atributo não
(3FN) chave funcionalmente determinado por um
outro atributo não chave (ou por um
conjunto de atributos não chave). Ou seja,
não deve haver dependências transitivas de
um atributo não chave na chave primária.
Solução(Normalização)
Forme novas relações para cada atributo
não atômico ou relação
agrupada(multivalorada).
Decomponha e monte uma relação para
cada chave parcial com seu(s) atributo(s)
dependente(s). Certifique-se de manter
uma relação com a chave primária
original e quaisquer atributos que sejam
completamente dependentes dela em
termos funcionais.
Decomponha e monte uma relação que
inclua o(s) atributo(s) não chave que
funcionalmente determine(m) outros
atributos não chave.
Exercício

• Faça a tradução e descrição do Esquema Textual e Diagrama Relacional dos

exercícios. Em cada um aplique as três formas normais:

• Fazer o Diagrama Relacional no Workbench e exportar como imagem.

• Fazer o Esquema Textual no Word.

▫ Sistema de Empresa (Questão 01 do trabalho anterior).

▫ Sistema de Farmácia (Questão 02 do trabalho anterior).

▫ Sistema de Empregado (Questão 03 do trabalho anterior).