PBD_-_PARTE_2_-_2015-2

02/09/2015

1

Escola de Ciência e TecnologiaCurso: Sistemas de Informação

Disciplina: Projeto de Banco de Dados - Professor Anderson Nascimento

Parte 2 - Normalização

35



Normalização - Conceitos

• Objetivos da normalização:

– Evitar os problemas provocados por falhas no Projeto do Banco de Dados.

– Eliminar a "mistura de assuntos" e as correspondentes repetições desnecessárias de dados.

36

02/09/2015

2



• Regra: não misturar assuntos em uma mesma tabela para evitar repetição desnecessária dos dados bem como inconsistência dos dados.

• O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados para verificar se estas estão corretamente projetadas.

• Normalmente após a aplicação das regras de normalização, algumas tabelas acabam sendo divididas em duas ou mais tabelas, o que no final gera um número maior de tabelas do que o originalmente existente.

37



Dependência Funcional

• Existe uma dependência funcional entre atributos de uma relação, quando a um valor de um atributo X está sempre associado um mesmo valor para um atributo Y.

• Assim, se um valor Vx ocorrer em linhas diferentes da relação R, o valor Vy será o mesmo em todas as linhas onde Vx ocorrer.

38

02/09/2015

3



• Pode-se então afirmar que: X Y

• Lê-se:

– X determina Y ou

– Y é dependente funcional de X ou ainda

– X é o determinante de Y

• Exemplo:

funcionario (matricula, nome, cargo, salario)

matricula {nome, cargo}

Cargo salario

39



• Alguns atributos podem depender funcionalmente de um conjunto de atributos e não apenas de um único.

• A esses casos dizemos que temos uma dependência composta.

• Exemplo:

matriculas (matr, cod_turma, nome, curso, num_vagas, data)

matr {nome, curso}

cod_turma num_vagas

{matr, cod_turma} data

40

02/09/2015

4



Exercícios:

1) Determine as dependências funcionais da tabela a seguir utilizando os seus conhecimentos do domínio empresa:

funcionario (cod_func, nome, cargo, salario, cbo, cod_setor, nome_setor, localizacao_setor, chefe_setor, sexo_func, admissao_func)

41



2) Determine as dependências funcionais a partir da tabela abaixo:

42

A B C

X 1 340

X 3 120

Y 2 18

Y 1 27

02/09/2015

5



TDE03 – ARTEFATO 01 DO PROJETO• Pesquisa: Descrever em texto corrido o minimundo do projeto final da

disciplina:– Descrição do cenário;

– Características do sistema que o BD vai apoiar;

– Identificação dos usuários do BD;

– Entidades, Atributos, Relacionamentos, Multiplicidades;

– Regras de Negócio;

– Transações principais do sistema;

– Consultas que deverão ser realizadas;

• Entrega apenas por email, enviar para [email protected];– No campo Assunto usar o padrão: TDE03 – PBD – PRIMEIRO NOME DO ALUNO

– No arquivo anexado usar o mesmo padrão acima;

• Tamanho máximo ideal de 2 páginas;

• Grupo de até 4 pessoas (este grupo permanecerá até o fim do semestre);

• Entregar em formato DOC;

• Prazo: próxima aula até às (23:59hs);

43



Formas Normais

• Primeira Forma Normal (1FN)

– Uma relação está na Primeira Forma Normal (1FN) se e somente se os seus atributos contêm apenas valores atômicos (simples, indivisíveis).

– Uma tabela não poderá ter atributos compostos nem multivalorados;

– Exemplo:

44

mailto:[email protected]

02/09/2015

6



Paciente (id, nome, endereço, telefones)

• A relação paciente não está na 1FN, pois possui o atributo telefone multivalorado e endereço composto;

• Solução?

45

id nome Endereço telefones

101 Maria Batista Rua C, 123 2277-0011

2253-1010

8115-0909

121 João Batista Rua H, 546 2505-0005

231 Antônio Souza Rua A, no. 12

332 Carlos Sá Rua J, no. 321 2442-0016

2222-0121



• Criar uma relação adicional para armazenar os telefones;

• Decompor o campo endereço;

Paciente (id, nome, logradouro, numero, complemento, bairro, cidade, cep, uf)

Telefone (idTelefone, telefone, idPaciente)

• Ainda podemos melhorar mais as tabelas?

46

02/09/2015

7



Exercícios teóricos:

1) Refine a tabela paciente, resolvendo as anomalias de logradouro (que pode ser rua, estrada, avenida, beco, travessa, etc.);

2) Refine a tabela telefone, levando em consideração que o cliente gostaria de armazenar o DDD, o tipo do telefone (celular, residência ou comercial) e ainda a operadora. Precisaremos de mais uma tabela, nesse caso?

3) O cliente agora deseja armazenar mais de um endereço para cada paciente. Trate esse novo requisito nesse modelo:

47



Exercícios práticos:

1) Normalize a tabela cedida pelo professor utilizando a primeira forma normal (1FN);

a) primeiro analise a tabela;

b) realize o mapeamento das DF’s;

c) crie o novo projeto da tabela;

d) Reflita o projeto no SGBD;

48

02/09/2015

8



TDE04• A partir da tabela abaixo:

– Criar o Mapa de Dependências;

– Normalizar a tabela abaixo usando a Primeira Forma Normal;

– Realizar as devidas alterações para melhorar a tabela;

PESSOA (CodPessoa, Nome, Sexo, Nascimento, Telefones (0,N), Emails (0,2), Filiação, Dependentes, Endereco Pessoal, Endereco Comercial)

• Entrega apenas por email, enviar para [email protected];– No campo Assunto usar o padrão: TDE04 – PBD – PRIMEIRO NOME DO ALUNO

– No arquivo anexado usar o mesmo padrão acima;

• Tamanho máximo ideal de 2 páginas;

• Grupo de até 4 pessoas (este grupo permanecerá até o fim do semestre);

• Entregar em formato DOC;

• Prazo: Dia 23/03 (dia anterior à aula) até às 23:59hs;

49



• Segunda Forma Normal (2FN)

– Uma relação está na Segunda Forma Normal (2FN) quando:

• Está na 1FN;

• Não contém dependências parciais, ou seja, todos os atributos que não são chave dependem totalmente de toda a chave.

• Toda dependência parcial deverá ser excluída;

50

mailto:[email protected]

02/09/2015

9



• Exemplo:

1) Normalizar a tabela Aluguel:

Aluguel(codcliente, codcarro, nomecliente, modelocarro, anocarro, telcliente (0,N), dataaluguel, funcaluguel)

2) Agora leve em consideração que um cliente pode alugar o mesmo carro mais de uma vez;

51



• Dependência parcial: uma dependência (funcional) parcial ocorre quando uma coluna depende apenas de parte de uma chave primária composta.

– Exemplo:

Consulta (idPaciente, idMedico, data, nomePaciente, nomeMedico, crmMedico)

OBS: Um mesmo paciente não pode ser atendido pelo mesmo médico mais de uma vez.

52

02/09/2015

10



Resposta:

Dependências funcionais:

{idPaciente, idMedico} → data

idPaciente → nomePaciente

idMedico → {nomeMedico, crmMedico}

• idPaciente determina nomePaciente.

• idMédico determina nomeMedico e crmMedico.

53


Disciplina: Projeto de Banco de Dados - Professor Anderson Nascimento 54

idPaciente idMedico data nomePaciente nomeMedico crmMedico

1 1 01/08/2005 João Paulo 123

9 6 03/09/2005 Maria Luiz 345

7 4 07/10/2005 Pedro Alexandre 567

9 1 08/11/2005 Maria Paulo 123

4 6 09/11/2005 Antônio Luiz 345

1 6 12/11/2005 João Luiz 345

4 4 15/12/2005 Antônio Alexandre 567

Exemplo de Instância:

02/09/2015

11



• Os atributos nomePaciente, nomeMedico e crmMedico não dependem totalmente da chave primária, {idPaciente, idMedico}.

• O problema é que a relação não está bem projetada, misturando diferentes conceitos em uma única representação.

Solução:

• Paciente(idPaciente, nomePaciente)

• Medico(idMedico, nomeMedico, crmMedico)

• Consulta(idPaciente, idMedico, data)

Obs: Chave estrangeira está representada em itálico

55



• Exercícios:

1) A partir do script cedido pelo professor, normalizar a tabela usando a 2FN;

56

02/09/2015

12



• Terceira Forma Normal (3FN)

– Uma relação está na Terceira Forma Normal (3FN) quando:

• Está na 2FN;

• Não contém dependências transitivas, ou seja, se não houver um atributo não-chave funcionalmente determinado por um outro atributo não-chave (ou por um conjunto de atributos não-chave).

• Exemplo:

57



Paciente (id, nome, endereço, telefone, sexo, siglaConvênio, nomeConvênio, telefoneConvênio)


id → {nome, endereço, telefone, sexo, siglaConvênio}

siglaConvênio → {nomeConvênio, telefoneConvênio}

• id determina siglaConvênio.

• siglaConvênio determina nomeConvênio e telefoneConvênio.

58

02/09/2015

13


Disciplina: Projeto de Banco de Dados - Professor Anderson Nascimento 59

id nome endereço telefone sexo siglaConvênio nomeConvênio telConvênio

1 João Rua 1 111 M AM Amil 1000

2 Maria Rua 2 222 F GC Golden Cross 4000

3 Antônio Rua 3 333 M BR Bradesco 6000

4 Pedro Rua 4 444 M GC Golden Cross 4000

5 Paulo Rua 5 555 M BR Bradesco 6000

6 Luiz Rua 6 666 M AM Amil 1000

7 Alexandre Rua 7 777 M AM Amil 1000

Exemplo de Instância:



• nomeConvênio e telefoneConvênio não são chaves e são funcionalmente determinados por um outro atributo não chave, siglaConvênio.

• Problema: id → siglaConvênio → {nomeConvênio, telefoneConvênio}

Solução:

• Paciente (id, nome, log, num, comp, bairro, cidade, uf, cep, telefone, sexo, siglaConvênio)

• Convênio (siglaConvênio, nomeConvênio, telefoneConvênio)

60

02/09/2015

14



• Forma Normal de Boyce-Codd (FNBC)

– Uma relação está na forma normal de BoyceCodd (FNBC) quando todo o determinante da relação for uma chave candidata.

– A FNBC corresponde a um grau de normalização mais elevado do que a 3FN e é necessária quando:

– A entidade tem várias chaves candidatas;

• As chaves candidatas são compostas;

• As chaves candidatas sobrepõem-se porque possuem pelo menos um atributo em comum.

61



– Exemplo:

– Orientação (id, especialização, orientador)

62

id especialização orientador

100 Matemática Carlos

150 Psicologia João


200 Matemática Renato


250 Psicologia João

300 Psicologia Pedro

350 Matemática Renato

02/09/2015

15



Chave Primária: (id, especialização)

Chave Candidata: (id, orientador)


orientador → especialização

Solução:

alunoOrientador (id, orientador)

orientadorDisciplina (orientador, especialização)

63



Parte 3 Mapeamento de esquemas de classes da UML em esquemas

relacionais

64

Documents

PBD_-_PARTE_2_-_2015-2