BD-ddl-dml_06 - Banco de Dados DDL-DML - Normalização

Prévia do material em texto

Banco de Dados (DDL/DML)
Aula 06 – Normalização
Prof. MSc. Marcello Mello
Mini Glossário
Baseado no livro de Teorey
‹#›
Modelo entidade-relacionamento (ER)
Um modelo de dados conceitual envolvendo entidades, relacionamentos entre entidades, e atributos dessas entidades.
Diagrama entidade-relacionamento (ER)
Um diagrama (ou gráfico) de entidades e seus relacionamentos, e possivelmente os atributos dessas entidades.
‹#›
Entidade
Um objeto de dados que representa uma pessoa, local, coisa ou evento se tiver interesse informativo; ele corresponde a um registro em um arquivo quando armazenado. Por exemplo, você poderia definir funcionário, cliente, projeto, equipe e departamento como entidades.
Tabela
Em um banco de dados relacional, a coleção de linhas (ou registros) de um único tipo (semelhante a um arquivo).
Relação
Uma tabela em um banco de dados relacional.
‹#›
Instância de entidade (ou ocorrência)
Uma ocorrência em particular de uma entidade.
Por exemplo, uma instância da entidade ator seria Johnny Depp.
‹#›
Registro
Um grupo de itens de dados tratado como uma unidade por uma aplicação; uma linha em uma tabela de banco de dados.
Linha
Um grupo de itens de dados tratados como uma unidade por uma aplicação; um registro; uma tupla na terminologia de banco de dados relacional.
Tupla
Uma linha em uma tabela relacional; um registro.
‹#›
Atributo
Um elemento de dados primitivo que oferece detalhes descritivos sobre uma entidade; um campo de dados ou item de dados em um registro.
Por exemplo, sobrenome seria um atributo para a entidade cliente.
Os atributos também podem ser usados como elementos descritivos para certos relacionamentos entre entidades.
‹#›
Relacionamento
Uma associação do mundo real entre uma ou mais entidades.
Por exemplo, “comprado” poderia ser um relacionamento entre cliente e produto.
‹#›
Relacionamento binário recursivo
Um relacionamento entre uma ocorrência de uma entidade com outra ocorrência da mesma entidade.
Também chamado de auto-relacionamento.
Relacionamento binário
Um relacionamento entre ocorrências de duas entidades.
‹#›
Grau de um relacionamento
O número de entidades associadas no relacionamento:
binário recursivo (1 entidade)
binário (2 entidades)
ternário (3 entidades)
n-ário (n entidades)
‹#›
Agregação
Um tipo especial de relacionamento de abstração que define uma entidade de nível superior que é uma agregação de várias entidades de nível inferior; um relacionamento do tipo “parte de”.
Por exemplo, uma entidade bicicleta seria uma agregação de entidades roda, quadro e assento.
‹#›
Generalização
Um tipo especial de relacionamento de abstração que especifica que vários tipos de entidades com certos atributos comuns podem ser generalizados (ou definidos de forma abstrata) com um tipo de entidade de nível superior, uma entidade de supertipo; um relacionamento do tipo “é um”.
Por exemplo, funcionário é uma generalização de engenheiro, gerente e assistente administrativo, com base no atributo comum cargo.
Uma ferramenta normalmente usada para possibilitar a integração de visões.
‹#›
Entidade de subtipo
A entidade abstrata de nível inferior em um relacionamento de generalização.
Entidade de supertipo
A entidade de nível superior em um relacionamento de generalização.
‹#›
Chave
Um termo genérico para um conjunto de um ou mais atributos (itens de dados) que, tomados coletivamente, permitem que se identifique exclusivamente uma entidade ou um registro em uma tabela SQL; uma superchave.
Chave candidata
Qualquer subconjunto dos atributos (itens de dados) em uma superchave que também é uma superchave e não é redutível a outra superchave.
‹#›
Chave primária
Uma chave que é selecionada dentre as chaves candidatas para uma tabela SQL a ser usada para criar um índice para essa tabela.
Chave estrangeira
Qualquer atributo em uma tabela SQL (chave ou não chave) que é tomado do mesmo domínio de valores como chave primária em outra tabela SQL e pode ser usado para juntar as duas tabelas (sem perda de integridade de dados) como parte de uma consulta SQL.
‹#›
Um domínio é o conjunto de todos os valores possíveis para determinado tipo de atributo, mas pode ser usado para mais de um atributo
Por exemplo, o domínio dos nomes de pessoas é o conjunto básico de todos os possíveis nomes que poderiam ser usados para nome-cliente ou nome-vendedor
‹#›
Cada coluna em uma tabela relacional representa um único atributo
‹#›
Normalização
‹#›
As tabelas de banco de dados relacional, sejam elas derivadas dos modelos ER ou UML, às vezes sofrem com alguns problemas bastante sérios em termos de desempenho, integridade e facilidade de manutenção
Por exemplo, quando o banco de dados como um todo é definido como uma única e grande tabela, isso pode resultar em uma grande quantidade de dados redundantes e pesquisas demoradas mesmo para pequenas quantidades de linhas
‹#›
‹#›
Classes de esquemas de bancos de dados relacionais, ou definições de tabelas, chamadas formas normais, geralmente são usadas como um método para desmembrar tabela grandes em tabelas menores, de modo que certos problemas sejam eliminados, e o banco de dados se torne muito mais eficiente e confiável
‹#›
A criação de tabelas de banco de dados em uma dada forma normal é chamada de normalização
A normalização é feita analisando as interdependências entre atributos individuais associados a essas tabelas e tomando-se projeções (subconjuntos de colunas) de tabelas maiores para formar tabelas menores
Vamos rever primeiro as formas normais básicas, que já foram bem estabelecidas na literatura de banco de dados relacional e na prática
‹#›
A propriedade de um ou mais atributos determinarem unicamente o valor de um ou mais outros atributos é chamada de dependência funcional (DF)
Dada uma tabela (R), um conjunto de atributos (B) é dependente funcionalmente de outro conjunto de atributos (A) se, em qualquer momento do tempo, cada valor A estiver associado a apenas um valor B
Essa dependência funcional é indicada por: A → B
‹#›
Uma Dependência Funcional é um relacionamento entre dois ou mais atributos de forma que o valor de um atributo identifique o valor para cada um dos outros atributos, ou seja, um atributo está relacionado a outro
No caso A → B, o atributo B é dependente (funcionalmente) do atributo A
Em outras palavras, para ‘descobrirmos o valor de B, precisamos saber o valor de A’ (observe que a recíproca NÃO é verdadeira)
https://www.devmedia.com.br/artigo-sql-magazine-47-normalizacao-de-dados/8078
‹#›
Código do cliente → Nome do cliente
Nesse exemplo, para descobrirmos o nome do cliente (dentro de um conjunto de clientes), primeiramente precisamos saber qual é o código dele; assim, o campo/atributo “nome” é dependente do campo/atributo “código”
Observe que a recíproca NÃO é verdadeira!
Você poderia pensar: “Ora, eu posso conhecer o nome do cliente, e não o seu código - nem sempre eu vou precisar saber o código do cliente para obter o nome dele”
Esse pensamento é incorreto, pois você pode ter clientes com o mesmo nome
‹#›
‹#›
Uma dependência funcional parcial ocorre quando os atributos não chave não dependam funcionalmente de toda a chave primária quando esta for composta.
Assim, nas tabelas onde a chave primária for composta, todos os atributos devem depender de toda a chave primária.
Caso a dependência seja de parte da chave, verificamos a existência de dependência funcional parcial.
‹#›
Por exemplo:
AB → C, D
Considere que o atributo C depende funcionalmente de A, mas não depende de B
O atributo NomeDisciplina depende apenas do CodDisciplina e não depende da matrícula do aluno junto com seu período
Assim, existe uma dependência funcional parcial
‹#›
Na definição dos campos de uma entidade podem ocorrer casos em que um campo não seja dependente diretamente da chave primária ou de parte dela, mas sim dependente de outro campo da tabela, campo este que não a Chave Primária.
Quando istoocorre, dizemos que a tabela possui dependência funcional transitiva.
É importante deixar claro a diferença entre dependência funcional parcial e a transitiva.
Na parcial, pelo menos um atributo da tabela depende de parte da chave primária (e não dela toda); na transitiva, pelo menos um atributo da tabela depende de outro atributo que não seja chave primária.
‹#›
Normalização de Dados
Processo de análise de determinados esquemas de relações com base em suas Dependências Funcionais e chaves primárias para alcançar as propriedades desejáveis (inicialmente proposto por E.F.Codd, 1972):
Minimização de redundância
Minimização de anomalias de inserção, exclusão e atualização
‹#›
Formas Normais
Codd propôs três formas normais que ele chamou de primeira, segunda e terceira forma normal
Uma definição mais forte da 3FN — chamada forma normal Boyce Codd (FNBC OU BCNF) — foi depois proposta por Boyce e Codd
Todas essas formas normais são baseadas nas dependências funcionais entre os atributos de uma relação
Depois, uma quarta forma normal (4FN) e uma quinta forma normal (5FN) foram propostas, baseadas nos conceitos de dependências multivaloradas e de junção, respectivamente
‹#›
Formas Normais
A forma normal de uma relação refere-se à condição da mais alta forma normal alcançada e, consequentemente, indica o grau no qual foi normalizada
As formas normais, quando consideradas isoladamente de outros fatores, não garantem um bom projeto de banco de dados!
Devem ter duas propriedades:
As propriedades da junção sem perda ou junção não aditiva, que garante que o problema de geração de tuplas ilegítimas, não ocorra nos esquemas de relação criados após a decomposição
A propriedade da preservação da dependência, que garante que cada dependência funcional será representada em alguma relação individual resultante da decomposição
‹#›
Na Prática
A normalização, realizada na prática, garante que os projetos resultantes sejam de alta qualidade e alcancem propriedades desejáveis
Embora existam várias formas normais de alto grau, como as 4FN e 5FN, a utilidade prática dessas formas normais se torna questionável quando as restrições, nas quais são baseadas, são difíceis de serem entendidas ou detectadas pelos projetistas e pelos usuários de um banco de dados, os quais deveriam estabelecê-las
Assim, o projeto praticado hoje comercialmente dá particular atenção somente à normalização até a 3FN, 4FN ou BCNF
‹#›
Primeira Forma Normal (1FN)
Considerada parte da definição formal de uma relação no modelo relacional básico (flat)
Foi definida como impedimento para a criação de atributos multivalorados, atributos compostos e combinações entre eles
Estabelece-se que o domínio de um atributo só deva incluir os valores atômicos (simples, indivisíveis), e que o valor de qualquer atributo em uma tupla deve ter um único valor no domínio daquele atributo
‹#›
Conjuntos de Valores (Domínios)
‹#›
1FN
‹#›
BOLETIM = {matricula-aluno, materia, notas}
BOLETIM = {matricula-aluno, materia, numero-prova, nota}
Primeira Forma Normal
“Uma tabela estará na
primeira forma normal
(1FN) se, e somente
se, todas as colunas
tiverem apenas valores
atômicos, ou seja, se
cada coluna só puder
ter um valor para cada
linha na tabela.”
‹#›
Segunda Forma Normal (2FN)
Baseada no conceito de dependência funcional total
Um esquema de relação R está na 2FN se todo atributo não primário A em R tem dependência funcional total da chave primária de R
Uma relação está na segunda forma normal quando duas condições são satisfeitas:
A relação estiver na primeira forma normal
Todos os atributos primos dependem funcionalmente de toda a chave primária
‹#›
2FN
‹#›
Apenas o atributo nota depende totalmente de toda chave primária
BOLETIM = {matricula-aluno, materia, numero-prova, nota}
Segunda Forma Normal
Uma tabela está na segunda forma
normal (2FN) se, e somente se, ela
estiver na 1FN e os atributos não chaves
forem totalmente dependentes da chave
primária. Um atributo será totalmente
dependente da chave primária se estiver no
lado direito de uma DF que tem no lado
esquerdo a própria chave primária ou
algo que possa ser derivado da chave
primária usando a transitividade das DFs.
‹#›
Relatório Geral
‹#›
Neste exemplo, projetamos relatório sobre num_relat, editor, num_depto, nome_depto e end_depto para formar relatório1; projetamos relatório sobre id_autor, nome_autor e end_autor para formar relatório2; e finalmente projetamos relatório sobre num_relat e id_autor para formar relatório3.
A projeção de relatório em três tabelas menores preservou as DFs e a associação entre num_relat e num_autor, que era importante na tabela original.
‹#›
‹#›
Terceira Forma Normal (3FN)
Baseada no conceito de dependência transitiva
Uma dependência funcional X 🡪 Y, em um esquema de relação R, será uma dependência transitiva se existir um conjunto de atributos Z que não é nem uma chave candidata nem um subconjunto de qualquer chave de R, e ambas X 🡪 Z e Z 🡪 Y forem asseguradas
Duas condições devem ser satisfeitas:
A relação deve estar na segunda forma normal
Todos os atributos primos dependem não transitivamente de toda a chave primária
‹#›
3FN
‹#›
Observe que:
numero-pedido 🡪 codigo-cliente 🡪 nome-cliente
numero-pedido 🡪 codigo-cliente 🡪 codigo-cidade-cliente
numero-pedido 🡪 codigo-cliente 🡪 codigo-cidade-cliente 🡪 nome-cidade-cliente
Isto é dependência transitiva!
Terceira Forma Normal
Uma tabela está na terceira forma normal (3FN) se, e somente se, para cada dependência funcional não trivial X->A, onde X e A são atributos simples ou compostos, uma das duas condições precisam ser mantidas: ou o atributo X é uma superchave, ou o atributo A é membro de uma chave candidata.
Se o atributo A é membro de uma chave candidata, A é chamado de atributo primo.
Nota: uma DF trivial tem a forma YZ->Z.
‹#›
Se excluirmos um relatório do banco de dados (aquele do Relatório Geral - mostrado anteriormente), o que envolve excluir as linhas apropriadas de relatório1 e relatório3 (da segunda forma normal), temos o efeito colateral de excluir também a associação entre num_depto, nome_depto e end_depto.
Se pudéssemos projetar a tabela relatório1 sobre num_relat, editor e num_depto para formar a tabela relatório11, e projetar relatório1 sobre num_depto, nome_depto e end_depto para formar a tabela relatório12, poderíamos eliminar esse problema.
‹#›
‹#›
Outras Formas Normais
BCNF (3FN forte)
Proposta como uma forma mais simples de 3FN, mas é considerada mais rígida; a única diferença é que a condição que permite que o atributo funcional seja primário da 3FN, não se aplica para a BCNF
4FN
Um conjunto F de dependências (que inclui dependências funcionais e dependências multivaloradas) se, para cada dependência multivalorada não trivial X -> Y em F, X for uma superchave de R
5FN
Um conjunto F de dependências funcionais, multivaloradas e de junção se, para cada dependência de junção não trivial Dj(R[, R2,. . ., Rn) de F (ou seja, implicada por F), todo R, for uma superchave de R
‹#›
A 3FN, que elimina a maioria das anomalias conhecidas nos bancos de dados de hoje, é o padrão mais comum para normalização nos bancos de dados comerciais e ferramentas CASE.
Outras formas normais:
Forma Normal de Boyce-Codd (FNBC), considerada uma variação forte da 3FN
4FN
5FN
6FN
FNCE
FNTE
FNCD
‹#›
Até logo mais!
marcellormello@fac.pe.senac.br