05 Formas normais

Prévia do material em texto

Fundamentos 
de Banco de Dados
Prof Nazareno Morais
*
5 – Projetos de esquemas relacionais
Unidade de Aprendizado
*
5 – Projetos de esquemas relacionais
Você aprenderá:
5.1 – Orientações para projetos relacionais
5.2 – Normalização
*
5.1 Orientações para projetos relacionais
Bloco de Construção de Aprendado
*
5.1 Orientações
Semântica dos Atributos
Redução de Valores Redundantes nas Tuplas
Redução de Valores null
Impedimento para Geração de Tuplas Ilegítimas
*
Para inserir uma nova tupla empregado em EMP_DEPT, teremos que incluir os valores dos atributos para o departamento que o empregado trabalha, ou null se o empregado ainda não trabalhar em nenhum departamento.
5.1 Anomalia de Inserção
*
Anomalia de Atualização: Em EMP_DEPT, se o valor de um dos atributos de um departamento específico for alterado, deve-se atualizar as tuplas de todos os empregados que trabalham nesse departamento.
Anomalia de Exclusão: Em EMP_DEPT, caso o único empregado vinculado a um departamento seja excluído, haverá perda de informação sobre o departamento.
5.1 Anomalia de Atualização e Exclusão
*
5.1 Anomalias
Diretriz: Modelar esquemas de relações de forma que nenhuma anomalia de:
Inserção
Alteração
Ou exclusão
que possa ocorrer nas relações.
*
5.1 Solução Evitando Anomalias
*
5.1 Impedir a Geração de Tuplas Ilegítimas
*
5.1 Impedir a Geração de Tuplas Ilegítimas
Uma má escolha de particionamento de relações pode levar a resultados inconsistentes.
*
5.1 Impedir a Geração de Tuplas Ilegítimas
O particionamento de uma relação usando campos inadequados, pode inviabilizar a reconstrução da informação. No exemplo, ao tentar-se unir as tabelas realizando uma operação de junção, observa-se que o conjunto resultante será composto por diversas tuplas ilegítimas.
*
5.2 Normalização
Bloco de Construção de Aprendado
*
5.2 Normalização
“Técnicas de racionalização das estruturas de dados de um sistema, eliminando redundâncias, problemas de manipulação e armazenamento”. 
“Normalização é um processo através do qual esquemas de relação, que não sejam satisfatórios às características do modelo relacional, são decompostos em esquemas menores que satisfaçam as propriedades desejáveis”.(Date)
*
5.2 Normalização
As medidas de normalização evita o mau uso dos dados, buscando:
1º - Correta representação semântica – Os dados devem ser projetados de forma a terem seus significados bem definidos e coerentes com o que realmente querem representar.
2º - Redução de valores redundantes – Sempre que possível deve-se reduzir ao máximo os valores redundantes desnecessários, ou seja, valores que muitas vezes aparecem repetidos quando isto não seria preciso.
*
5.2 Normalização
3º - Redução de valores nulos – Sempre que possível deve-se reduzir o número de atributos que por alguma razão receberão muitos valores nulos.
4º - Não geração de tuplas espúrias (sem sentido) – Durante o processo de normalização deve-se atentar para evitar que sejam geradas tuplas que não façam sentido diante da realidade, isto pode ocorrer devido a alguma decomposição.
*
5.2 Normalização
A decomposição ocorre como abaixo:
								 R1.1 (A1, A2, A3)
	R1 (A1, A2, A3, A4)
								 R1.2 (A1, A4)
Onde R1 é uma relação formada pelos atributos A1, A2, A3 e A4, que foi descomposta em outras duas relações R1.1 e R1.2. Ser for recompor R1.1 e R1.2 o resultado desejado seria a tabela R1, mas nem sempre isso é conseguido.
A decomposição deve ser feita de forma muito cuidadosa. O atributo A1, que é a chave primária da relação R1, deve ser o pivô da decomposição e deve ser chave primária também de uma ou de ambas as novas relações.
*
5.2 Dependências Funcionais
Uma dependência funcional, denotada X -> Y entre dois conjuntos de atributos X e Y, que são subconjuntos de R, especificam uma restrição nas possíveis tuplas que formem um estado da relação r de R.
A restrição é que para quaisquer duas tuplas t1 e t2 em r tenham t1[X] = t2[X], elas também têm de ter t1[Y] = t2[Y].
São exemplos de dependências funcionais:
CPF -> Nome
CEP -> Endereço
*
5.2 Normalização de Relações
Processo inicialmente concebido por 
Edgar Frank Codd (Ted Codd) em 1972.
Consiste em aplicar testes sucessivos usando dependências funcionais
As formas normais têm abordagem top-down:
Uma relação pode estar na 1FN e não estar na 2FN e assim por diante.
*
5.2 Normalização de Relações
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.
O processo de normalização como foi proposto inicialmente por Codd conduz um esquema de relação através de uma bateria de testes para certificar se o mesmo está na 1ª, 2ª e 3ª formas normais. Estas três Formas Normais são baseadas em dependências funcionais dos atributos do esquema de relação. 
*
5.2 Normalização de Relações
Obtido o esquema relacional correspondente ao documento, passa-se ao processo de normalização.
Este processo baseia-se no conceito de forma normal. Uma forma normal é uma regra que deve ser obedecida por uma tabela para que esta seja considerada “bem projetada”.
Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para verificar tabelas relacionais. Para o nosso estudo, vamos considerar quatro formas normais, abreviadamente de 1FN, 2FN, 3FN e FNBC.
*
4.2 Principais Formas Normais
1ª Forma Normal (1FN)
2ª Forma Normal (2FN)
3ª Forma Normal (3FN)
*
5.2 - 1ª Forma Normal
Uma relação está na 1FN quando todos os seus atributos são Atômicos e Monovalorados. Um atributo atômico é aquele que não é tratado em partes separadas. Um atributo monovalorados é aquele que possui somente um valor (não uma lista).
*
5.2 - 1ª Forma Normal
Considere a seguinte relação:
 
Cliente = {CPF, nome, endereço, (telefone)}
 
A relação Cliente não está na 1FN, porque Nome e Endereço são atributos compostos e telefone é um atributo multivalorado. A normalização desta relação resulta nas seguintes relações:
 
Cliente={CPF, nome, sobrenome, rua, numero_casa, bairro}
Cliente_Telefone = {CPF, DDD, numero_tel}
*
5.2 Dependências Funcionais
A dependência funcional é representada por uma linha horizontal que parte do(s) atributo(s) mais à esquerda, terminando com setas nos atributos dependentes, localizados à direita.
Todos os atributos que não fazem parte da chave primária de uma relação são funcionalmente dependentes dela.
*
5.2 - 2ª Forma Normal
A passagem à 2FN objetiva eliminar redundância de dados.
Uma tabela encontra-se na 2FN quando, além de encontrar-se na 1FN, cada coluna não chave depende da chave primária completa.
Uma tabela que não se encontra na segunda forma normal contém dependências funcionais parciais, ou seja, contém colunas não chave que dependem apenas de uma parte da chave primária.
*
5.2 - 2ª Forma Normal
A tabela EMP_PROJ não está na 2FN porque alguns dados não chave dependem somente de parte da chave, como ENOME depende de SSN e PNOME e PLOCALIZAÇÃO dependem de PNUMERO.
*
5.2 - 2ª Forma Normal
A passagem à 2FN objetiva eliminar um certo tipo de redundância de dados. Para exemplificar, tomamos a tabela ProjEmp da figura acima. Nesta tabela, os dados referentes a empregados (Nome, Cat e Sal) estão redundantes, para os empregados que trabalham em mais de um projeto. Um exemplo é o do empregado de código “8191”.
*
5.2 - 2ª Forma Normal
*
5.2 - 3ª Forma Normal
Uma tabela encontra-se na 3FN quando, além de 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 acontecequando uma coluna não chave primária depende funcionalmente de outra coluna ou combinação de colunas não chave primária.
A passagem à 3FN consta em dividir tabelas de forma a eliminar as dependência transitivas.
*
5.2 - 3ª Forma Normal
*
5.2 - 3ª Forma Normal
Na passagem à terceira forma normal, elimina-se um outro tipo de redundância. Vamos supor que o salário (coluna Sal) de um empregado seja determinado pela sua categoria funcional.
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.
A passagem à 3FN objetiva eliminar este tipo de redundância de dados.
*
Exercício
1) Coloque na 1FN:
	ESTUDANTES = {Matrícula, Nome, Gênero, DataNasc, (Endereço), CodCurso}
2) Coloque na 2FN:
	ESTOQUE = {Produto, Almox, End_Almox, Unid_Est, Qtd, Preço}
*
Exercício
1)
*
Obrigado !
*
Bibliografia
Livros:
1. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S.. Sistema de Banco de Dados. 5a ed., Campus, 2006.
2. HEUSER, Carlos Alberto. Projeto de Banco de Dados. 6a Ed., Bookman, 2008.
3. ELMASRI, R.; NAVATHE, S. B.. Sistemas de Banco de Dados. 4a ed., Pearson-Addison-Wesley, 2005.
4. DATE, C. J.. Introdução a Sistemas de Banco de Dados. Elsevier Editora, 2004.
5. GENNICK, J. SQL Guia de Bolso. Rio de Janeiro: Alta Books, 2007.
Heuser, C.A. Projeto de Banco de Dados. Ed. Sagra, 2001.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Para inserir uma nova tupla empregado em EMP_DEPT, teremos que incluir os valores dos atributos para o departamento que o empregado trabalha, ou null se o empregado ainda não trabalhar em nenhum departamento
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Anomalia de Atualização: Em EMP_DEPT, se o valor de um dos atributos de um departamento específico for alterado, deve-se atualizar as tuplas de todos os empregados que trabalham nesse departamento.
Anomalia de Exclusão: Em EMP_DEPT, caso o único empregado vinculado a um departamento seja excluído, haverá perda de informação sobre o departamento.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Uma má escolha de particionamento de relações pode levar a resultados inconsistentes.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
O particionamento de uma relação usando campos inadequados, pode inviabilizar a reconstrução da informação. No exemplo, ao tentar-se unir as tabelas realizando uma operação de junção, observa-se que o conjunto resultante será composto por diversas tuplas ilegítimas.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
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. 
	
	O processo de normalização como foi proposto inicialmente por Codd conduz um 
esquema de relação através de uma bateria de testes para certificar se o mesmo está na 1°, 2°
e 3° formas normais. Estas três Formas Normais são baseadas em dependências funcionais 
dos atributos do esquema de relação. 
 
	Obtido o esquema relacional correspondente ao documento, passa-se ao processo de 
normalização. Este processo baseia-se no conceito de forma normal. Uma forma normal é 
uma regra que deve ser obedecida por uma tabela para que esta seja considerada “bem 
projetada”. Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para 
verificar tabelas relacionais. Para o nosso estudo, vamos considerar quatro formas normais, 
abreviadamente 1FN, 2FN, 3FN e 4FN.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
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. 
	
	O processo de normalização como foi proposto inicialmente por Codd conduz um 
esquema de relação através de uma bateria de testes para certificar se o mesmo está na 1°, 2°
e 3° formas normais. Estas três Formas Normais são baseadas em dependências funcionais 
dos atributos do esquema de relação. 
 
	Obtido o esquema relacional correspondente ao documento, passa-se ao processo de 
normalização. Este processo baseia-se no conceito de forma normal. Uma forma normal é 
uma regra que deve ser obedecida por uma tabela para que esta seja considerada “bem 
projetada”. Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para 
verificar tabelas relacionais. Para o nosso estudo, vamos considerar quatro formas normais, 
abreviadamente 1FN, 2FN, 3FN e 4FN.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
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. 
	
	O processo de normalização como foi proposto inicialmente por Codd conduz um 
esquema de relação através de uma bateria de testes para certificar se o mesmo está na 1°, 2°
e 3° formas normais. Estas três Formas Normais são baseadas em dependências funcionais 
dos atributos do esquema de relação. 
 
	Obtido o esquema relacional correspondente ao documento, passa-se ao processo de 
normalização. Este processo baseia-se no conceito de forma normal. Uma forma normal é 
uma regra que deve ser obedecida por uma tabela para que esta seja considerada “bem 
projetada”. Há diversas formas normais, isto é, diversas regras, cada vez mais rígidas, para 
verificar tabelas relacionais. Para o nosso estudo, vamos considerar quatro formas normais, 
abreviadamente 1FN, 2FN, 3FN e 4FN.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Para o modelo relacional, a Forma Normal (FN) mais importante é a chamada de 1° forma normal (1FN). Uma relação está na 1FN quando todos os seus atributos são Atômicos e Monovalorados. Um atributo atômico é aquele que não é tratado em partes separadas. Um atributo monovalorados é aquele que possui somente um valor (não uma lista). Considere a seguinte relação:
 
Cliente = {CPF, nome, endereço, (telefone)}
 
A relação cliente não está na 1FN, porque Nome e Endereço são atributos compostos e telefone é um atributo multivalorado. A normalização desta relação resulta nas seguintes relações:
 
Cliente={CPF, nome, sobrenome, rua, numero_casa, bairro}
Cliente_Telefone = {CPF, DDD, numero_tel}
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Para o modelo relacional, a Forma Normal (FN) mais importante é a chamada de 1° forma normal (1FN). Uma relação está na 1FN quando todos os seus atributos são Atômicos e Monovalorados. Um atributo atômico é aquele que não é tratado em partes separadas. Um atributo monovaloradosé aquele que possui somente um valor (não uma lista). Considere a seguinte relação:
 
Cliente = {CPF, nome, endereço, (telefone)}
 
A relação cliente não está na 1FN, porque Nome e Endereço são atributos compostos e telefone é um atributo multivalorado. A normalização desta relação resulta nas seguintes relações:
 
Cliente={CPF, nome, sobrenome, rua, numero_casa, bairro}
Cliente_Telefone = {CPF, DDD, numero_tel}
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Na figura acima é apresentada a notação gráfica relacionada com a dependência funcional. A dependência funcional é representada por uma linha horizontal que parte do(s) atributo(s) mais à esquerda, terminando com setas nos atributos dependentes, localizados à direita. Todos os atributos que não fazem parte da chave primária de uma relação são funcionalmente dependentes dela.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
2ª Forma Normal: A passagem à segunda forma normal objetiva eliminar redundância de dados. Uma tabela encontra-se na segunda forma normal (2FN) quando, além de encontrar-se na primeira forma normal, cada coluna não chave depende da chave primária completa. Uma tabela que não se encontra na segunda forma normal contém dependências funcionais parciais, ou seja, contém colunas não chave que dependem apenas de uma parte da chave primária. 
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
2ª Forma Normal: A passagem à segunda forma normal objetiva eliminar redundância de dados. Uma tabela encontra-se na segunda forma normal (2FN) quando, além de encontrar-se na primeira forma normal, cada coluna não chave depende da chave primária completa. Uma tabela que não se encontra na segunda forma normal contém dependências funcionais parciais, ou seja, contém colunas não chave que dependem apenas de uma parte da chave primária. 
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
A passagem à segunda forma normal (2FN) objetiva eliminar um certo tipo de redundância de dados. Para exemplificar, tomamos a tabela ProjEmp da figura acima. Nesta tabela, os dados referentes a empregados (Nome, Cat e Sal) estão redundantes, para os empregados que trabalham em mais de um projeto. Um exemplo é o do empregado de código “8191”. 
	
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
No caso do documento exemplo, a tabela Emp encontra-se na 2FN por possuir uma chave primária simples (composta de apenas uma coluna). Já a tabela ProjEmp deve ser examinada para procurar dependências parciais, pois possui uma chave primária composta de mais de uma coluna. As colunas Nome, Cat e Sal dependem, cada uma, apenas da coluna NumEmp, 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 (para determinar a data em que um empregado começou a trabalhar em um projeto, bem como para determinar o tempo pelo qual ele foi alocado ao projeto é necessário conhecer tanto o código do projeto quanto o número do empregado).
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
3ª Forma Normal: Uma tabela encontra-se na 3FN quando, além de 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. A passagem à 3FN consta em dividir tabelas de forma a eliminar as dependência transitivas. 
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
3ª Forma Normal: Uma tabela encontra-se na 3FN quando, além de 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. A passagem à 3FN consta em dividir tabelas de forma a eliminar as dependência transitivas. 
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
Na passagem à terceira forma normal, elimina-se um outro tipo de redundância. Vamos supor que o salário (coluna Sal) de um empregado seja determinado pela sua categoria funcional. 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. A passagem à 3FN objetiva eliminar este tipo de redundância de dados.
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
*
INFNET TRAINING - 
I801 – FUNDAMENTOS DE BANCO DE DADOS
INFNET TRAINING - 
*
I801 – FUNDAMENTOS DE BANCO DE DADOS
INFNET TRAINING - 
*
I801 – FUNDAMENTOS DE BANCO DE DADOS