Databases

Dependências Funcionais

P. Serendero, 2011-13

Referências e exemplos tirados de diversas fontes,

excetuando aqueles relacionados com embarcações
 Dependências Funcionais (DF)
Uma Base de Dados, para ser um modelo que bem represente a
realidade, precisa de de ser depurada de anomalias, redundâncias e
outros problemas que se presentam quando operamos nela:
inserções, apagar, modificar, interrogar

Utilizamos a Teoria da Normalização para fazer esta depuração

Na base da normalização, estão as chamadas:

Dependências Funcionais

Utilizando os conceitos de chaves e dependências funcionais podemos

desenhar “boas” relações numa BD

As DF constituem um tipo de restrição de integridade, no desenho de

BD
 Dependências Funcionais
Considere a seguinte relação:

colaborador(num-empregado,num-projeto, nome-empregado,
nome-projeto, num-horas)

Anomalias que se podem apresentar:

INSERÇÃO: Não se pode inserir um novo projeto, de não ser que um

empregado seja atribuído a ele. Inversamente, não se pode inserir um novo
empregado sem ter que lhe atribuir um projeto

ACTUALIZAÇÃO: se mudarmos o nome dum projeto, vamos ter que

atualizar em todos os muitos empregados que colaboram em dito projeto.

APAGAR: Se apagarmos um projeto, vamos apagar todos os colaboradores

do mesmo

Portanto, NÃO É BOA PRÁTICA DE DESENHO, MISTURAR ATRIBUTOS

PERTENCENTES A DISTINTAS ENTIDADES NUMA MESMA RELAÇÃO
 Dependência Funcional

Numa relação R, existe DF sse o valor dum conjunto de atributos X

determinam o valor preciso dum outro atributo A

X →A ex: BI → nome
O conjunto dos atributos X determinam funcionalmente o
atributo A
(no ex. o nome depende do BI , mas o BI não depende do nome)

X: O conjunto determinante
A: o atributo dependente

Por outras palavras, dados 2 tuplos em R, se os valores de X são

os mesmos, então os valores de A devem ser também os mesmos

DF é portanto uma declaração sobre todas as relações permitidas:

uma restrição. A relação R satisfaz a depêndencia X → Y
 Dependências Funcionais
Dependência Funcional
Esta relação de dependência funcional também se pode
expressar como subconjuntos
X1,X2,..,Xm → A1,....An ou X→Y
O símbolo da seta → se lê “determina”, portanto
“o conjunto X determina o conjunto Y”

Isto é equivalente a dizer que a projecção π x,y R é uma

função, isto é, Y é função de X

Nota:
A convenção em muitos textos utiliza as letras A,B,C,D, para atributos singulares
e as letras X,Y,Z para conjuntos de atributos
 Dependências Funcionais
Portanto, numa tabela representando uma relação R,
Se dois tuplos j e m coincidem no valor de todos os seus
Tuplosatributos
A1A, devem
A2 tambémAn coincidir
B1 em todos
B2 os valores
B3
dos seus atributos B

Tuplo j

Tuplo m

Se j e m concordam aqui Também devem concordar aqui

Efeitos da dependência funcional em dois tuplos

Ullman, pag. 119
 Dependências Funcionais
modelo comprimento

Exemplo: Repare nos conjuntos Benetton I 11.25

modelo e comprimento na relação Hurrican A 10.90
embarcação -mostrada anteriormente- : Benetton II 12.50
Laser 470 4.75

Existe um dependência entre os valores destes

conjuntos. O comprimento é função do modelo.
Dado um modelo de embarcação, posso encontrar o comprimento

Essa dependência se expressa assim:

modelo → comprimento

Isto tem uma aplicação imediata nas conhecidas chaves candidatas:

Uma chave candidata é o subconjunto mínimo de atributos que
determina todos os atributos numa relação
 Dependências Funcionais
Seria correto escrever a DF:

comprimento → modelo ?

Não, porque podem existir diferentes modelos com o mesmo comprimento

Da mesma maneira como nome → BI indicado anteriormente

não é DF porque um mesmo nome (Diana por ex.) não determina um único
BI

O que quer dizer que se criamos uma relação com estes elementos, modelo
seria a chave e comprimento o atributo

Como vemos, existe normalmente DF entre a chave e os atributos numa

tabela
Se K é a chave primária numa relação R, então K determina funcionalmente
o valor de cada um dos atributos em R. Em termos de tabelas, nunca temos
dois tuplos idênticos, posto que a chave primária é única na tabela
 Chaves nas relações

Um ou mais atributos {A1, A2, ...An } formam uma chave

numa relação R, se:

1) Aqueles atributos determinam funcionalmente todos os outros

atributos nessa relação

Por outras palavras, é impossível que dois tuplos em R concordarem no

valor de todos os seus atributos {A1, A2, ...An }

2) Nenhum subconjunto em {A1, A2, ...An } determina funcionalmente

todos os outros atributos da relação R. Isto é, uma chave deve ser mínima.

A esta denomina-se chave principal ou primária

 Dependências Funcionais
modelo → comprimento

matricula → nome da embarcação

num-aluno → curso
Exemplos de DF
curso → nome-curso, data-criação na relação
aluno,ano,disciplina, epoca → nota
embarcação

BI → nome-pessoa

Bi → NIF
NIF → BI São estas duas dependências verdadeiras?
 Dependências Funcionais
Outro exemplo: Dada a relação R
embarcação(matricula, nome, proprietario, pais, modelo, comprimento, boca,
bi_proprietario), e as seguintes dependências funcionais

matricula → nome, matricula → pais, matricula → bi_proprietario

matricula → comprimento

Estas dependências são corretas?

NÃO!! o BI depende do seu proprietário, e não da matricula do seu barco.
Uma pessoa que mude de bi, continuará a ser proprietário da mesma
embarcação, identificada pelo número de matrícula

A determinação do bi não depende funcionalmente da matrícula do barco

Mais uma outra?

 DF's

Portanto um atributo é funcionalmente dependente, se o seu valor é

determinado por um outro atributo que é uma CHAVE

Se A → B logo dado um valor para A só pode existir um valor para B

Se A → B e B → A, logo A e B estão numa relação 1-1

Se A → (B,C) logo A → B e A → C

Se (A,B) → C, não é necessariamente verdadeiro que

A→CeB→C
 Regras nas Dependências Funcionais
A maneira de pensar sobre as dependências funcionais
“Splitting rule” e “combination rule”
Já foi dito que
A1, A2,.., An → B1, B2,....Bm
isto quer dizer que:

A1, A2,.., An → B1
A1, A2,.., An → B2
...
A1, A2,.., An → Bm
Podemos separar os atributos no lado direito tal que só 1 atributo aparece à
direita de cada dependência funcional
Da mesma maneira podemos substituir uma coleção de dependências com
um lado esquerdo comum por uma dependência simples com o mesmo lado
esquerdo e todos os lados direitos combinados num só conjunto de
atributos X → Y
 Dependências Funcionais
Exemplo: o conjunto de dependências:

tipo-embarcação, modelo → boca

tipo-embarcação, modelo → comprimento
tipo-embarcação, modelo → calado

são equivalentes a dependência:

tipo-embarcação, modelo → boca, comprimento, calado

Não existe “splitting rule” para o lado esquerdo da dependência

Porque?
tipo-embarcação → boca
modelo → boca
modelo não determina sozinho o tamanho da boca. E o tipo de
embarcação também não. São precisos os dois: superchave
 Regras nas Dependências Funcionais

Em qualquer evento o novo conjunto de dependências é equivalente

ao velho. Isto pode ser utilizado de diversas maneiras:

substituindo A1, A2,.., An → B1,B2,....Bm por

A1, A2,.., An → Bi para i = 1,2,..,m
A esta transformação chama-se “splitting rule”

Podemos substituir as dependências A1, A2,.., An → Bi

(i = 1,2,..,m) pela dependência simples:

A1, A2,.., An → B1,B2,....Bm

Chamamos esta transformação, “combination rule”, regra de

combinação
 Dependências Funcionais
Dependências triviais

A dependência funcional A1, A2,.., An → B

é considerada TRIVIAL se B pertence a algum subconjunto de A
Por exemplo:
tipo-embarcação, modelo → tipo-embarcação
Portanto dependências triviais existem sempre numa relação,
posto que dois tuplos que coincidem em todas as A1, A2,.., An
também concordam numa delas

Dependências não triviais: se pelo menos uma das B não está

entre as A

Dependências completamente não triviais: se nenhuma das B

está entre as A
 Dependências Funcionais
Regras de inferência: propriedades das DF

Axiomas de Amstrong:

➲ Reflexividade: Se A é um subconjunto de X, logo X → A

➲ Augmentação: Se X → A, logo XZ → AZ , (XZ = X Ս Z)
➲ Transitividade: Se X → A e A → B, logo X → B
➲ Aditividade: Se X → Y, Z → V, implica XUZ→ YUV

As primeiras 3 regras formam um conjunto completo de regras

de inferência nas relações

(U - união)
 Dependências Funcionais
Das regras anteriores pode-se derivar outras regras adicionais de
inferência

Descomposição

Se X → YZ, logo X → Y e X → Z
União
Se X → Y e X → Z, logo X → YZ, onde (Y U Z)

Pseudotransitividade

Se X → Y e WY → Z, logo WX → Z
 Computando o fecho dos atributos

Como sabemos se um conjunto de atributos é uma super

chave?
Computando o fecho dum atributo ajuda-nos a responder
esta questão

O fecho de Y, escrito como Y+ é o conjunto de todos os

atributos X dos quais Y+ depende funcionalmente

Numa DF olhemos para o lado esquerdo X.

Se este determina igualmente um atributo A, então A vai
fazer parte do fecho Y+.

O fecho dum conjunto Y de DF é o conjunto Y+ de todas as DF

que podem serem inferidas desde Y
 Computando o fecho dos atributos
Algoritmo para calcular o fecho de atributos:

Começando com um conjunto de atributos, repetidamente

expandimos este conjunto adicionando os lados direitos das DF
dadas, na altura que incluirmos os seus lados esquerdos.
Eventualmente não podemos expandir mais este conjunto. O
conjunto resultante é o FECHO
Algoritmo para calcular o fecho de atributos:

1. Y+ = Y

2. Se A1, A2,..,Am → B, adicionar B em Y+ (adicionar uma DF)

3. Terminar quando não conseguimos adicionar mais

atributos a Y+
(como implementava você este algoritmo numa linguagem de
programação?)
Computando o fecho dos atributos

Se o 
subconjunto A 
determina um 
outro atributo B, 
adicionamos 
A  B
este ao fecho Y+
Y+

                  Novo Y+
 Fecho dos atributos: exemplo
Dada a seguinte relação R (A, B, C, D, E) e dado o seguinte
conjunto de DF:
➲ A → BC
➲ CD → E
➲ B → D
➲ E → A

Queremos saber se:

A é ou não uma super chave desta R? Computamos o fecho A+

1. A+ = A
2. ABC // porque A → BC
3. ABCD // porque B → D
4. ABCDE // porque CD → E
5. ABCDE
➲ A+ = ABCDE, portanto A é uma super chave em R
 Fecho dos atributos: exemplo
Dada a mesma R (A, B, C, D, E) da página anterior e as
mesmas DF:
➲ A → BC
➲ CD → E
➲ B→D
➲ E→A

Será B uma super chave em R? Computamos o fecho B+

1. B+ = B
2. BD // porque B → D
3. BD
➲ B+ = BD, portanto B NÃO é uma super chave em R

Se K → todos os Ai numa R, então K é uma super chave

As DF são uma generalização das chaves
 Fecho de atributos - Exemplo
Dado R = (A, B, C, G, H, I) e
dadas DF = { A → B, A → C, CG → H, CG → I, B → H }
desejamos saber se AG será uma chave candidata.

➲ Portanto AG é uma super chave? ou seja AG+ → R ?

➲ Existe algum subconjunto de AG que seja também uma super chave?
A → R? é A+ ?, ou seja é A+ um subconjunto em R?
G → R? é G+ ?, ou seja é G+ um subconjunto em R?

Para responder calculamos o fecho para AG+

1) AG+ = AG
2) AGB //por A → B
3) AGBC // por A → C
4) AGBCH // por CG → H
5) AGBCHI // por CG → I e CG é subconjunto de AGBCH
6) ABCGHI , portanto AG é uma super chave
 Dependências Funcionais
Exemplo
Dada a relação R(ABCDEF ) com as seguintes DF’s:

AB → C
BC → A
BC → D
D→E
CF → B

Qual será o fecho de (AB)+

(AB)+ = AB
= ABC, porque AB → C
= ABCD, porque BC → D
= ABCDE, porque D → E
= ABCDE
Se (AB)+ ser a chave principal desta relação, então o
atributo F não é determinado funcionalmente por AB
 Dependências funcionais
Redundância entre as Dependências

A → C é redundante em F+ quando {A → B, B → C}

Partes duma DF poderiam ser redundantes

No lado ESQUERDO duma regra:

{A → B, B → C, AC → D}
pode ser simplificada: {A → B, B → C, A → D}

No lado DIREITO duma regra: {A → B, B → C, A → CD}

Pode ser simplificada: {A → B, B → C, A → D}
Dependências Funcionais

Fim