Banco de Dados I

Unidade 3: Projeto de BD Relacional

Cludio Baptista

4.1 Transformao de Diagramas MER
em Diagramas DR

Principais conceitos do MER:
Tipos de entidades (regular, fraca)
Graus de relacionamentos (binrio,
n-rio)
Atributos (simples, compostos,
multivalorados)
Restries (chave, cardinalidade, etc.)

A seguir, mostraremos um conjunto
de regras para efetuar o mapeamento
entre modelo ER e modelo Relacional
3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 1: Entidades Regulares
1.1. Para cada entidade regular E no
esquema E-R, criamos uma relao R que
inclui os atributos simples de E.
1.2. Para cada atributo composto de E
inclumos somente os seus atributos
simples.
1.3. Escolhemos um dos atributos chaves
de E para ser a chave primria de R.

3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 2: Entidades Fracas
2.1. Para cada entidade fraca W, com
entidade forte E, no esquema E-R,
criamos uma relao R e inclumos todos
os atributos simples de W como atributos
de R.
2.2. Inclumos como atributos da chave
estrangeira de R os atributos que
compem a chave primria da entidade
forte E.
2.3. A chave primria de R a
combinao da chave primria da
entidade forte E e a chave da entidade
fraca W.

3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 3: Relacionamentos 1:1
3.1. Identificamos as relaes S e T que
correspondem s entidades que
participam do relacionamento.
3.2. Escolhemos uma das relaes,
digamos S, e inclumos como chave
estrangeira em S a chave primria de T.
melhor escolher para desempenhar o
papel de S, a entidade que tenha
participao total no relacionamento.
3.3. Inclumos todos os atributos simples
do relacionamento 1:1 como atributos de
S.
3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 4: Relacionamentos 1:N
que no envolvem entidades
fracas
4.1. Identificamos a relao S que
representa a entidade que participa do
lado N do relacionamento.
4.2. Inclumos como chave estrangeira
em S, a chave primria da relao T que
representa a outra entidade (lado 1) que
participa do relacionamento.
4.3. Inclumos qualquer atributo simples
do relacionamento 1:N em S.
3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 5: Relacionamento N:M
5.1. Criamos uma nova relao S para
representar o relacionamento.
5.2. Inclumos como chave estrangeira
em S as chaves primrias das relaes
que participam do relacionamento. A
combinao destas chaves formar a
chave primria da relao S.
5.3. Inclumos qualquer atributo do
relacionamento N:M em S.
Podemos mapear o relacionamento 1:1 ou 1:N de
maneira similar ao M:N. Isto usado quando
poucas instncias do relacionamento existe,
evitando valores nulos nas chaves estrangeiras.
3.1 Transformao de Diagramas MER
em Diagramas DR

Regra 6: Atributos Multivalorados
6.1. Criamos uma nova relao R que
inclui o atributo multivalorado A mais a
chave primria K da relao que
representa a entidade (ou
relacionamento) que tem A como
atributo.
6.2. A chave primria de R a
combinao de A e K.
6.3. Se o atributo multivalorado
composto => incluir seus componentes
atmicos
3.1 Transformao de Diagramas MER
em Diagramas DR

Regra7:
Especializao/Generalizao
7.1. Converta cada especializao com m
subclasses {S1,S2,...,Sm} e superclasse
C, cujos atributos so {k, a1,..., an}
onde k a chave primria, em esquemas
de relaes usando uma das seguintes
opes:

3.1 Transformao de Diagramas MER
em Diagramas DR

Regra7: Especializao/Generalizao
A) Criar uma relao L para C com os atributos
Atrib(L) = {k,a1, ... , an} e chave primria k.
Criar tambm uma relao Li para cada subclasse
Si, 1 <= i <= m, com os seguintes atributos:
Atrib(Li) = {k} { atributos de Si}, k
ser a chave primria.
Ex.:Empregado(Matrcula,Nome,
Salrio,Endereo,TipoTrab), Secretria(Matr,
VelocidadeDigitao), Tcnico(Matrcula,
Especialidade), Engenheiro(Matrcula, Tipo, CREA)

3.1 Transformao de Diagramas MER
em Diagramas DR

Regra7:
Especializao/Generalizao
B) Criar uma relao Li para cada
subclasse Si, 1 <= i <= m, com os
atributos Atrib(Li) = {atributos de Si}
{k,a1,...,an} e chave primria (Li) = k.
Ex.:
Carro ( Identificao, Licena, Preo,
VelMax,NumPassag),
Caminho(Identificao, Licena, Preo,
NumEixos, Tonelag)


3.1 Transformao de Diagramas MER
em Diagramas DR

Regra7:
Especializao/Generalizao
C) Criar uma nica relao L com
atributos
Atrib(L) = {k,a1,...,an} { atributos de
S1} ... {atributos de Sm} {t} e
chave primria k.
Onde t um atributo de tipo que indica a
subclasse a qual a tupla pertence. (opo
usada para especializao cujas
subclasses so disjuntas)
Ex.: Empregado(Matrcula, Nome,
Salrio, Endereo, TipoTrab, VelDatilog,
EspTec, TipoEng, CREA)


3.1 Transformao de Diagramas MER
em Diagramas DR

Regra7: Especializao/Generalizao
D) Criar uma nica relao L com atributos
Atrib(L) = {k,a1,...,an}
{ atributos de S1 } ... { atributos de Sm }
{t1,t2,...,tm} e chave primria k.
Onde cada ti , 1 <= i <= m, um atributo
booleano que indica se uma tupla pertence a uma
subclasse Si. (opo usada para especializao
cujas subclasses so sobrepostas)
Ex.:Pea(Cdigo,Descrio,MFLag,NDesenho,DataManu
fat,NLote,CFlag, Fornecedor, Preo)


3.2 Qualidade de Esquemas
Relacionais: Normalizao
A normalizao necessria (embora no
suficiente) a um bom projeto relacional.
Felizmente, um bom projeto de um esquema
de entidades, e sua consequente converso
para um esquema relacional, segundo as
regras vistas, praticamente deixa o esquema
relacional normalizado.
Assim, utiliza-se a normalizao somente para
validar um projeto relacional.
Para entender o que a normalizao significa,
vamos dar primeiramente um exemplo de
motivao.


3.2 Qualidade de Esquemas
Relacionais: Normalizao
HABILIDADES-ESPORTIVAS
Identidade Nome Endereo Habilidade
8795835 dson Arantes Ponta da Praia Futebol
8795835 dson Arantes Ponta da Praia Voleibol
8795835 dson Arantes Ponta da Praia Basquete
8795835 dson Arantes Ponta da Praia Atletismo
8795835 dson Arantes Ponta da Praia Tnis
Esta tabela est mal projetada!
1) Se Pel mudar de endereo ? (anomalia de atualizao)
2)Um novo esporte para Pel ? (anomalia de incluso)
3) Retirar Pel do Banco de Dados (anomalia de remoo)

3.2 Qualidade de Esquemas
Relacionais: Normalizao
Idealmente:
HABILIDADES-ESPORTIVAS
Identidade Nome Endereo Habilidade
8795835 dson Arantes Ponta da
Praia
{Futebol,
Voleibol,
Basquete,
Atletismo,
Tnis}
Mas isto no uma tabela (atributo habilidade
no atmico)! O que possvel fazer, dentro
do modelo relacional?
3.2 Qualidade de Esquemas
Relacionais: Normalizao
ESPORTISTAS
Identidade Nome Endereo
8795835 dson Arantes Ponta da Praia
... ... ...
HABILIDADES
Identidade Esporte
8795835 Futebol
8795835 Voleibol
8795835 Basquetebol
8795835 Atletismo
8795835 Tnis
A repetio da coluna Identidade uma redundncia
necessria
3.2 Qualidade de Esquemas
Relacionais: Normalizao
3.2.2 Primeira Forma Normal (1FN)

Toda tabela deve ser minimamente normalizada
(1FN).


Tabela em 1FN: O valor de uma coluna de uma
tabela indivisvel.


3.2 Qualidade de Esquemas
Relacionais: Normalizao
Ex.: Empregado
Matr
cula
Nome Cod
Cargo
NomeCargo CodProj DataFim Horas
120 Joo 1 Programador 01 17/07/95 37
120 Joo 1 Programador 08 12/01/96 12
121 Hlio 1 Programador 01 17/07/95 45
121 Hlio 1 Programador 08 12/01/96 21
121 Hlio 1 Programador 12 21/03/96 107
270 Gabriel 2 Analista 08 12/01/96 10
270 Gabriel 2 Analista 12 21/03/96 38
273 Silva 3 Projetista 01 17/07/95 22
274 Abrao 2 Analista 12 21/03/96 31
279 Carla 1 Programador 01 17/07/96 27
279 Carla 1 Programador 08 12/01/96 20
279 Carla 1 Programador 12 21/03/96 51
301 Ana 1 Programador 12 21/03/96 16
306 Manoel 3 Projetista 17 21/03/96 67
3.2 Normalizao
A chave primria para a tabela
empregados (Matrcula,CodProj)

Vimos que um dos objetivos da
normalizao reduzir a redundncia de
dados, porm com a tabela anterior
aumentamos a redundncia ?!?!

Precisamos realizar outros passos de
normalizao para termos um bom
projeto.
A 1FN possui caractersticas indesejveis!

3.2 Normalizao
Anomalias da 1FN

Insero: no podemos inserir um
empregado sem que este esteja
alocado num projeto, nem um projeto
sem que haja um empregado
trabalhando nele (integridade de
entidade).


3.2 Normalizao
Anomalias da 1FN
Remoo: se precisarmos remover
um projeto, as informaes de
empregados que estiverem lotados
apenas naquele projeto sero
perdidas.
Atualizao: se um empregado for
promovido de cargo teremos que
atualizar os atributos CodCargo e
NomeCargo em todas as tuplas nas
quais aquele empregado est
presente.

3.2 Normalizao
Concluso:

Uma tabela em 1FN no evita, porm,
anomalias de incluso, atualizao, e
remoo. preciso uma normalizao
mais fina , ou outras formas formas
normais:
Segunda Forma Normal (2FN)
Terceira Forma Normal (3FN)
Esta normalizao fina utiliza o
conceito de dependncia funcional


3.2.3 Dependncias Funcionais

A B, l - se:
A funcionalmente determina B
B funcionalmente dependente de A
B funo de A

Para cada valor de A s existe um
valor de B.

A B, negao de A B.

3.2.3 Dependncias Funcionais

A ou B podem ser um conjunto de
atributos.
Identidade Nome
Identidade Endereo
Identidade Habilidade
Nome Identidade
Endereo Identidade
Habilidade Identidade
Identidade Nome, Endereo


3.2.3 Dependncias Funcionais

A ou B podem ser um conjunto de
atributos.
Identidade Nome
Identidade Endereo
Identidade Habilidade
Nome Identidade
Endereo Identidade
Habilidade Identidade
Identidade Nome, Endereo


3.2.3 Dependncias Funcionais

Idia de normalizao fina: agrupar
numa tabela somente dois conjuntos de
atributos X e Y, com X Y.
X ento a chave da tabela, e Y
complemento da chave.
Consequncia das definies de
dependncia funcional e de chave:
se X chave ento cada valor de X nico, e,
consequentemente, um valor de X identifica
uma linha da tabela.
3.2.3 Dependncias Funcionais

importante salientar que mais de um
atributo (ou conjunto de atributos) pode ser
chave, isto , pode-se ter vrios X Y,
cada X sendo uma chave candidata.



3.2.4 Segunda Forma Normal (2FN)

Uma tabela est na Segunda Forma
Normal (2FN) se ela 1FN e todo
atributo do complemento de uma chave
candidata totalmente funcionalmente
dependente daquela chave.

A, B, C => D (D totalmente
funcionalmente dependente de {A, B, C})
se para todo valor de {A, B, C} s
existe um valor de D, e se D no
funcionalmente dependente de A, ou B, ou
C.



3.2.4 Segunda Forma Normal (2FN)

Exemplo 1: ESPORTISTA (Identidade,
Nome, Endereo, Esporte)

Chaves Candidatas Complementos da
Chave
Identidade Nome, Endereo, Esporte
{Nome, Endereo} Identidade, Esporte
3.2.4 Segunda Forma Normal (2FN)

Identidade Nome

Identidade Endereo

Identidade Esporte


{Nome, Endereo} => Identidade

{Nome, Endereo} => Esporte

3.2.4 Segunda Forma Normal (2FN)

Concluso: O atributo Esporte deve ser retirado da
relao ESPORTISTA.

ESPORTISTA (Identidade, Nome, Endereo)

PRATICA-ESPORTE (Identidade, Esporte)

Um atributo sublinhado faz parte da chave.

Atualizar o endereo de Pel: sem anomalia.

Incluir uma nova habilidade de Pel: sem
anomalia.

3.2.4 Segunda Forma Normal (2FN)

Exemplo 2:
ESTUDANTE-DISCIPLINA
E # Enome Sexo Idade D # Dnome Opinio
E 1 Joo M 25 D 1 Mat Boa
E 1 Joo M 25 D 2 Quim M
E 1 Joo M 25 D 3 Fis Boa
E 2 Maria F 22 D 2 Quim Satisf.
E 2 Maria F 22 D 3 Fis Satisf.
E 2 Maria F 22 D 4 Est M
E 3 Joo M 27 D 2 Quim Boa
E 3 Joo M 27 D3 Fis Boa
Chaves Candidatas Complementos da
Chave
{E#, D#} Enome, Sexo, Idade,
Dnome, Opinio
{E#, Dnome}} Enome, Sexo, Idade, D#,
Opin
3.2.4 Segunda Forma Normal (2FN
{E#, D# }:

{E#, D#} => Enome (E# Enome)

{E#, D#} => Sexo (E# Sexo)

{E#, D#} => Idade (E# Idade)

{E#, D#} => Dnome (D# Dnome)

{E#, D#} => Opinio

3.2.4 Segunda Forma Normal (2FN
{E# , Dnome):

{E#, Dnome} => Enome (E# Enome)

{E#, Dnome} => Sexo (E# Sexo)

{E#, Dnome} => Idade (E# Idade)

{E#, Dnome} => D# (Dnome D# )

{E#, Dnome} => Opinio

Concluso: Enome, Sexo, Idade e Dnome
devem ser retirados de ESTUDANTE-DISCIPLINA

3.2.4 Segunda Forma Normal (2FN)
ESTUDANTE
E # Enome Sexo Idade
E1 Joo M 25
E2 Maria F 22
E3 Joo M 27
DISCIPLINA ESTUDANTE-DISCIPLINA
D # Dnome E # D # Opinio
D1 Mat E1 D1 Boa
D2 Quim E1 D2 Pobre
D3 Fis E1 D3 Boa
D4 Est E2 D2 Satisfatria
E2 D3 Satisfatria
E2 D4 Pobre
E3 D2 Boa
E3 D3 Boa
3.2.4 Segunda Forma Normal (2FN)
Ex3:A tabela Empregado anterior
aps passarmos para 2FN resultaria
em trs tabelas:

Empregado
Matrcula Nome CodCargo NomeCargo
120 Joo 1 Programador
121 Hlio 1 Programador
270 Gabriel 2 Analista
273 Silva 3 Projetista
274 Abrao 2 Analista
279 Carla 1 Programador
301 Ana 1 Programador
306 Manuel 3 Projetista
3.2.4 Segunda Forma Normal (2FN)
Ex3:A tabela Empregado anterior aps
passarmos para 2FN resultaria em trs
tabelas:

Projeto
CodProj DataFim
01 17/07/95
08 12/01/96
12 21/03/96
Alocao
Matrcula CodProj Horas
120 01 37
120 08 12
121 01 45
121 08 21
121 12 107
270 08 10
270 12 78
273 01 22
274 12 31
279 01 27
279 08 20
279 12 51
301 01 16
301 12 85
306 12 67
3.2.4 Segunda Forma Normal (2FN)
Anomalias da 2FN:

Insero: S podemos criar cargos se
houver empregados designados para ele.

Remoo: Se removermos um
empregado que ocupa unicamente um
cargo na empresa, perderemos a
informao deste cargo.

Atualizao: Se um cargo muda de nome
precisaremos mudar todas as tabelas em
que este cargo aparece.


3.2.5 Terceira Forma Normal (3FN)
Envolve o conceito de dependncia
transitiva. Suponha que tenhamos
uma tabela com colunas A, B e C.

Se a coluna C funcionalmente
dependente de B e B
funcionalmente dependente de A,
ento C funcionalmente dependente
de A.



3.2.5 Terceira Forma Normal (3FN)

Definio: Uma relao est em 3FN
se, e somente se, estiver em 2FN e
todos os atributos no-chave forem
dependentes no-transitivos da chave
primria

Ex.: Ao analisarmos a nova tabela
empregado que est em 2FN temos:

Matrcula CodCargo NomeCargo
3.2.5 Terceira Forma Normal (3FN)
NomeCargo dependente transitivo de
Matrcula.
Removendo esta dependncia transitiva,
obteremos,alm das tabelas Projeto e
Alocao, as seguintes tabelas:


Empregado
Matrcula Nome CodCargo
120 Joo 1
121 Hlio 1
270 Gabriel 2
273 Silva 3
274 Abrao 2
279 Carla 1
301 Ana 1
306 Manuel 3
Cargo
CodCargo Nome
1 Programador
2 Analista
3 Projetista
3.2.5 Terceira Forma Normal (3FN)
"Uma relao est em 3FN se todas as
colunas da tabela so funcionalmente
dependentes da chave inteira e nada
alm da chave".

A 3FN elimina as caractersticas mais
potencialmente indesejveis dos dados
que esto em 2FN ou 1FN.

Existem outros casos especiais que
requerem mais nveis de normalizao:
Boyce-Codd, 4FN e 5FN

3.2.6 Uma Metodologia de Normalizao

Passo 1: Tome projees de tabelas 1FN para
eliminar todas as dependncias funcionais no-
totais. O resultado uma coleo de tabelas 2FN.


Passo 2: Tome projees das tabelas obtidas no
passo 1 para eliminar todas as dependncias
transitivas. O resultado uma coleo de
relaes 3FN.