Você está na página 1de 10

14/12/20

Modelação e Bases de Dados

Projetos de BDs
Relacionais
Valéria Pequeno

Introdução
• Um projeto de Base de Dados Relacional é constituído por:
• Um conjunto de esquemas de relações
• Um conjunto de restrições (de domínio, de entidade, de
integridade referencial)
• Exemplo*:

(*) Fonte da imagem: Database System Concepts - 6th Edition, ©Silberschatz, Korth and Sudarshan

Introdução (cont.)
• Objetivo de um projeto de BD relacional:
• Guardar todos os dados relevantes de modo que a informação
seja facilmente acessível e ocupe o menos espaço possível
• Especificamente:
• Ter mínima redundância dos dados armazenados Dicas
• A semântica da relação seja clara Informais

• Como saber se o projeto da BD relacional é bom?

• Clara semân+ca dos atributos nos esquemas das


relações
• Evitar informações redundantes nos tuplos
• Restringir os valores nulos nos tuplos

1
14/12/20

Dica 1: Atributos com Semântica


Clara
• Informalmente, cada tuplo na relação deve representar uma
entidade ou uma instância de um relacionamento
• Combinar (fazer a fusão de relações) quase sempre não é uma
boa solução
• Somente chaves estrangeiras devem ser usadas para referenciar
outras relações Decomposição
EMP_DEPTO Empregado Departamento das relações
Ename SSN BDate Address DNumber Dname Dlocation
João 1234 97-10-10 Rua 1 100 RH Lisboa
Pedro 1111 82-01-01 Rua 2 100 RH Lisboa
Ana 2222 67-02-10 Rua 3 100 RH Porto

Projete um esquema de relação em que cada


relação possa ser facilmente explicada!

Dica 2: Evitar Informações


Redundantes nos Tuplos
• Um dos objetivos no projeto de esquemas de BD é reduzir o
espaço necessários para guardar as relações
• Agrupar atributos de diferentes relações em uma única
relação pode acarretar em:
• Necessidade de maior espaço devido as informações
redundantes
Informação
• Anomalias nos dados quando estes são atualizados redundante
EMP_DEPTO
Ename SSN BDate Address DNumber Dname Dlocation
João 1234 97-10-10 Rua 1 100 RH Lisboa
Pedro 1111 82-01-01 Rua 2 100 RH Lisboa
Ana 2222 67-02-10 Rua 3 100 RH Porto

• Informação é repetida para todo empregado que trabalha no


mesmo departamento na mesma cidade

Tipos de Anomalias: Inserção


EMP_DEPTO
Ename SSN BDate Address DNumber Dname Dlocation
João 1234 97-10-10 Rua 1 100 RH Lisboa
Pedro 1111 82-01-01 Rua 2 100 RH Lisboa
Ana 2222 67-02-10 Rua 3 100 RH Porto

• Para inserir um novo empregado em EMP_DEPTO, temos 2


opções:
• Inserir os dados do empregado + dados do departamento onde
ele trabalha
• Inserir os dados do empregado e NULL nos atributos relativos a
departamento
• O que fazer quando queremos inserir um novo departamento
que não tem ainda empregados?

2
14/12/20

Tipos de Anomalias: Remoção


EMP_DEPTO
Ename SSN BDate Address DNumber Dname Dlocation
João 1234 97-10-10 Rua 1 100 RH Lisboa
Pedro 1111 82-01-01 Rua 2 100 RH Lisboa
Ana 2222 67-02-10 Rua 3 100 RH Porto

• Ocorre quando queremos remover um empregado que é o

único empregado de um dado departamento

• A informação sobre esse departamento é perdida na remoção

Tipos de Anomalias: Modificação


EMP_DEPTO
Ename SSN BDate Address DNumber Dname Dlocation
João 1234 97-10-10 Rua 1 100 RH Lisboa
Pedro 1111 82-01-01 Rua 2 100 RH Lisboa
Ana 2222 67-02-10 Rua 3 100 RH Porto

• Se atualizarmos o valor de um dado atributo, por exemplo,


mudar o nome do departamento RH para Recursos Humanos,
esta modificação deve ser feita para todos os empregados que
trabalham neste departamento
• Caso essas modificações não sejam feitas a BD fica inconsistente

Dica 2:
Projete uma BD que não tenha anomalias de
inserção, remoção ou modificação

Dica 3: Restringir os Valores


Nulos nos Tuplos
• Alguns atributos numa relação podem ser opcionais
• Estes atributos não se aplicam para todas as entidades da relação
• Exemplo:
ALUNO
Ename SSN BDate Graduado? Título AnoGrau Classificação
João 1234 97-10-10 Sim Mestre 2011 16
Pedro 1111 82-01-01 Não NULL NULL NULL

• Problemas:
• Desperdício de espaço no disco
• O valor NULL pode ter vários significados:
• não se aplica
• valor desconhecido
• valor conhecido mas não disponível na altura da inserção

3
14/12/20

Guia 3: Restringir os Valores


Nulos nos Tuplos
ALUNO
Ename SSN BDate Graduado? Título AnoGrau Classificação
João 1234 97-10-10 Sim Mestre 2011 16
Pedro 1111 82-01-01 Não NULL NULL NULL

GUIA 3:
Projete uma BD de modo a restringir ao máximo o
valor NULL nos atributos
• Atributos com muitos valores nulos podem ser convertidos em
relação Decomposição
das relações
Ename SSN BDate
João 1234 97-10-10 SSN Título AnoGrau Classificação
Pedro 1111 82-01-01 1234 Mestre 2011 16

10

Dependencias Funcionais
• Guias formais para identificar bons projetos de BDs relacionais
• Não dependem da extensão das relações
• Definição:
Um conjunto de atributos X funcionalmente determina um
conjunto de atributos Y se o valor de X determina unicamente
valores para Y
Ou seja…
• Sempre que dois tuplos tem o mesmo valor para X, também
tem o mesmo valor para Y
• Matematicamente …
∀t1, t2 ∈ R, se t1 [ X ] = t2 [ X ] ⇒ t1 [Y ] = t2 [Y ]

11

Dependencias Funcionais
• Representação:

X -> Y

• Ler-se:

X determina Y
Y é funcionalmente dependente de X
Existe uma dependência funcional de X para Y
Y depende de X

12

4
14/12/20

DF - Exemplo
EMPREGADO
ID NomePróprio Apelido NumDepto
1234 João Silva 900
1111 Pedro Moura 700
2222 Ana Pinto 900

• NumDepto -> ID?


• Não pois 900 => {1234,2222}
• ID -> NumDepto ?
• Sim, pois não existe dois ID iguais para departamentos diferentes
(1 empregado só pertence a 1 departamento)
Nota: Para identificar as DFs não podemos nos basear apenas
nos valores de algumas instâncias, mas sim através das
propriedades dos atributos

13

Exercício Comentado
• Identificar quais atributos da relação abaixo funcionalmente
depende de quais atributos da relação:
Papelaria Artigo Preço {Papelaria,Artigo} ->
Colmeia caneta 1.50 Preço
Central Fita cola 3.00
Aquarela borracha 1.75
Silva caneta 2.00
Colmeia Fita cola 2.00

• Artigo -> Preço ?


Não, o mesmo artigo pode ter preço distintos
• Papelaria -> Preço?
Não, há tantos valores para preços de acordo com o número de artigos
vendidos na papelaria

14

Dependência Funcional (cont.)


• Dependência funcional completa (X -> Y):
• Quando retiramos algum atributo de X, a DF deixa de ser uma
dependência funcional
• Dependência funcional parcial (X -> Y):
• Quando retiramos algum atributo de X, a DF continua sendo uma
dependência funcional
• Fecho de F
• Dado F ser o conjunto de dependências funcionais de uma
relação
• F+ (fecho de F) é o conjunto mínimo de todas as DF de uma
relação
• Formado por todas as DF inicialmente conhecidas + as que se
podem derivar a partir das DF iniciais

15

5
14/12/20

Axiomas de Armstrong
• Conjunto de regras de inferências que podem ser usadas para
determinar F+
X,Y,Z e W são conjuntos de atributos A é apenas um atributo

R1 Reflexividade Se Y ⊆ X, então X → Y
R2 Aumento/Incremento Se Z ⊆ W e X → Y, então XW → YZ
R3 Transitividade Se X → Y e Y → Z, então X → Z
R4 PseudoTransitividade Se X → Y e YW → Z então XW → Z
R5 Decomposição X → Y, então X → A, ∀A ∈ Y
R6 União X → Y e X → Z, então X → YZ
R7 Composição X → Y e Z → W, então XZ → YW
R8 Unificação X → Y e Z → W, então X(Z − Y ) → YW

16

Axiomas de Armstrong –
Exemplo*
• Dados os atributos R, S, T, U e V, demonstrar que as FD R->T,
S->T e TU->V implicam RU -> V

1. Início: R -> T (aplica R2: Aumento)


2. RU -> TU (aplica R3: Transitividade)

3. RU->TU e TU->V então RU -> V

(*) Fonte:Fundamentos de Bases de dados, FCA, Feliz Gouveia

17

Normalização
• É o processo de analisar os esquemas das relações de modo a
minimizar redundâncias e minimizar a ocorrência de
anomalias de inserção, remoção e modificação
• É o processo para melhorar a qualidade do projeto do
esquema da BD por aplicar uma série de testes para certificar
que um dado esquema da relação satisfaz uma certa forma
normal
• Em outras palavras …
• A normalização converte cada esquema de uma relação
gradualmente para formas normais através da aplicação
sucessiva de regras que alteram o formato do esquema da
relação da 1ª forma normal até a forma normal desejada (2ª,
3ª, 4ª ou 5ª)

18

6
14/12/20

1ª Forma Normal
• Dizemos que uma relação está na 1ª forma normal quando:
• Os domínios de todos os atributos da relação consitem apenas de
valores atómicos
• Não existem subgrupos de atributos repetidos Atributo multi-valor
• Exemplo:

Não está na 1NF

19

Quando
1ª Forma Normal transformamos o MER
no MR já estamos a
obedecer a 1ª FN!
• Solução:

20

2ª Forma Normal
• Dizemos que uma relação está na 2ªFN quando:
• A relação está na 1ª FN
• Todos os atributos que não pertencem a chave dependem de
toda a chave (e não de um subgrupo da chave)
• Exemplo:

{Ssn,Pnumber} -> Hours


Ssn -> Ename
Não está na 2NF Pnumber -> Pname
Pnumber -> Plocation
Dizemos que a relação não contém dependências parciais

21

7
14/12/20

2ª Forma Normal {Ssn,Pnumber} -> Hours


Ssn -> Ename
• Solução: Pnumber -> Pname
Pnumber -> Plocation

22

3ª Forma Normal
• Dizemos que uma relação está na 3ª FN quando:
• Está na 2ª FN
• Os atributos que não pertencem à chave não dependem de
nenhum atributo que também não pertença à chave
Dizemos que a relação não contém dependências transitivas
Item_vendido
ID_fatura ID_produto quantidade preço total
{ID_fatura,ID_produto} -> quantidade
Não está na 3NF {ID_fatura,ID_produto} -> preço
{ID_fatura,ID_produto} -> total
Total = quantidade * preço
Todos a atributos dependem totalmente da chave à está na 2ª FN

23

3ª Forma Normal
• Solução:

Item_vendido
ID_fatura ID_produto quantidade preço total

Item_vendido
ID_fatura ID_produto quantidade preço
Total_vendido
quantidade preço total

24

8
14/12/20

Exercício 1
• Decomponha a relação para obedecer em 3FN :

Proprietário(Num_carro,Marca,Tipo,Cor,BI,Nome,Data,Preço)
sabendo que:

Num_carro -> {Cor,Tipo}


Tipo -> {Marca,Preço}

BI-> Nome

{Num_carro,BI} -> Data

25

Exercício 2
• Decomponha a relação para a 2FN e depois para 3FN:

Projeto_emp(CodProjeto,CodEmp,Nome,Categoria,Salário,DataI
nício,HorasTrabalhadas)

• Sabendo que:
{CodProjeto,CodEmp} -> DataInício, HorasTrabalhadas

CodEmp -> Nome, Categoria,Salário

26

Exercício 3
• Na normalização de dados, caso exista um ou
mais atributos que dependam de um atributo
não-chave, estes atributos deverão ser extraídos
para outra tabela. Trata-se da condição para que
a tabela esteja na:
a) primeira forma normal Dica para memorizar:
b) segunda forma normal 2FN: Dependência PARcial
c) terceira forma normal (dois é PAR)
3FN: Dependência TRansitiva
d) quarta forma normal (Forma Normal TRês)
e) forma normal Boyce/Codd.

27

9
14/12/20

Exercício 4
• Considere uma tabela relacional R, com atributos
A, B e C, atômicos, na qual o atributo A é a chave
primária. Sabendo-se que as dependências
funcionais A -> B e B -> C se verificam, pode-se
concluir que a tabela R está normalizada até a:
a) primeira forma normal
b) segunda forma normal
c) terceira forma normal
d) forma normal Boyce_Codd
e) quarta forma normal
Fonte: Ano: 2008. Órgão: UFRJ Prova: Analista de Tecnologia da Informação

28

Exercício 5
• Suponha a seguinte tabela (com todos seus domínios
atômicos) de uma base de dados relacional:
T (A, B, C, D)

Considere, ainda, as seguintes dependências funcionais:


A → B,C,D e C → D
A maior forma normal em que se encontra essa tabela é:
a) primeira forma normal
b) segunda forma normal
c) terceira forma normal
d) quarta forma normal
e) forma normal de Boyce-Codd

Fonte: Ano: 2013. Órgão: COREN-SP Prova: Administrador de Banco de Dados

29

Exercício 6
• No contexto de base de dados relacionais, Dependência
Funcional é caracterizada quando:

a) duas tabelas têm entre si relação N para N.


b) no relacionamento N para N há uma chave estrangeira.
c) para cada valor do atributo A existem n valores do atributo
B.
d) a chave primária da tabela do lado 1 vai para a tabela do
lado N.
e) para cada valor do atributo A existe exatamente um único
valor do atributo B

Fonte: Ano: 2011 Órgão: TRE-RN Prova: Técnico Judiciário - Programação de Sistemas

30

10

Você também pode gostar