BD - Aula02 - Normalização de Dados

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Normalização de Dados
Prof. Rogério Vassoler
Projetos “Limpos”
Um projeto “limpo” de uma tabela ou arquivo só contém dados sobre uma classe de entidades;
Estes projetos são fáceis de entender, fáceis de usar e fáceis de expandir quando houver necessidade de adicionar informações (ou atributos) à classe de entidades;
Se o projeto agrupasse em uma só tabela informações sobre diversas classes de entidades estas facilidades seriam reduzidas substancialmente .
Projetos “Limpos”
Um projeto ‘limpo” é um projeto no qual cada fato tem seu lugar;
Pode-se dizer que cada atributo representa um fato a respeito da chave (ou sobre a entidade identificada pela chave primária da tabela que contém o atributo);
Projetos ‘limpos” são estáveis e tem melhores possibilidades de expansão.
Problemas práticos
O processamento de sistemas de informações requer a interação de diversas classes de entidades;
Mesmo que o projeto das tabelas representando cada uma dessas classes de entidades seja “limpo”, existem informações relevantes que não são características de nenhuma delas em particular;
Existem atributos que pertencem não a uma classe de entidades primitiva e sim a uma classe de entidades gerada pelo relacionamento entre duas classes de entidades “naturais”. 
Anomalias de Atualização
Um sistema integrado de tabelas ou arquivos pode apresentar anomalias de atualização quando ocorrerem inclusões, exclusões ou modificações de registros em algumas tabelas individuais;
Estas anomalias devem ser evitadas porque violam a semântica da informação representada pelos itens de dados das entidades;
As anomalias podem ser minimizadas por meio de uma judiciosa partição de atributos entre as tabelas.
Tipos de Anomalias de Atualização
Anomalias de Atualização de Tabelas, Arquivos ou Relações:
De modificação
De exclusão
De inclusão
Anomalias de modificação
Ocorrem quando existirem valores redundantes de dados para um mesmo atributo em tabelas distintas
Anomalias de exclusão
Oriundas do fato de a exclusão de uma informação causar a eventual perda de outra informação.
Anomalias de inclusão
Oriundas da inclusão de registros em tabela contendo informações incompletas, informações essas que devem ser parte de entidades ainda não definidas e que estejam se abrigando na tabela de outra classe de entidades.
Normalização
É um processo que consiste em estruturar as tabelas e os atributos na forma mais adequada, do ponto de vista das operações a executar sobre a informação registrada na base de dados, tendo em vista eliminar redundâncias desnecessárias e evitar problemas com a inserção, eliminação e atualização de dados.
Normalização
Processo utilizado para:
evitar a ocorrência das anomalias de atualização
otimizar o processo de armazenamento de informações reduzindo a redundância e aumentando a confiabilidade do sistema
Este processo de projeto transforma um conjunto de especificações de entidades em outro conjunto, sendo que:
Semântica original é preservada
Dependências parciais, transitivas e de junção são eliminadas 
Redundância de dados é minimizada
Normalização
Processo iterativo;
Processo decomposto em vários níveis de normalização, chamados de segunda forma normal, terceira forma normal e assim por diante;
Cada forma normal é mais restritiva que a anterior;
A forma normal de ordem N + 1 está na forma normal de ordem N e não possui uma característica “não desejável” que a forma normal anterior de ordem N possui;
A forma normal de ordem N + 1 é mais desejável do que a forma normal de ordem N;
O processo de normalização é um processo de redução da redundância.
Exemplo de Anomalias
Anomalia de inclusão: quando se desejar incluir um aluno que ainda não tenha se matriculado em nenhuma disciplina
Anomalia de exclusão: quando se desejar excluir uma tupla que seja a única que contenha uma dada disciplina. Isto significa que se o único aluno matriculado em uma disciplina cancelar a matrícula perder-se-á a informação referente a essa disciplina
Anomalias de atualização: quando houver troca de código de disciplina, o que exigirá a varredura de toda a relação buscando as tuplas que contenham a disciplina recém atualizada.
Relacionamentos e chaves
Chaves primária (Primary key – PK): Um conjunto de atributos únicos e não nulos com característica de minimalidade, que identificam unicamente uma tupla.
Chave estrangeira (Foreign Key – FK): Um atributo ou uma combinação de atributos, cujos valores aparecem necessariamente na chave primária de uma outra relação ou da mesma relação.
Relacionamentos e chaves
Relacionamentos
Ligações entre tabelas.
Chave Primária (Primary Key, PK) 
Coluna com valores únicos.
Chave Composta
Composição de duas ou mais colunas para gerar uma combinação única.
Chave Estrangeira (Foreign Key, FK)
Coluna que armazena a chave primária de outra tabela.	
Tipos de Relacionamentos (1:1)
Relacionamento 1 para 1 (1:1)
Para cada registro da primeira tabela existe no máximo um correspondente na segunda tabela, e vice-versa.
Tipos de Relacionamentos (1:*)
Relacionamento 1 para muitos (1:*)
Para cada registro da primeira tabela existe um ou mais correspondentes na segunda tabela, e para cada registro na segunda tabela existe apenas um registro correspondente na primeira tabela.
Tipos de Relacionamentos (*:*)
Relacionamento muitos para muitos (*:*)
Para cada registro da primeira tabela pode existir um ou mais correspondentes na segunda tabela, e vice-versa.
Boas práticas no uso de chaves
Quanto menor, melhor
Transparente para o usuário
Diagrama de modelo de dados
Um dos padrões de modelagem de dados
Relacionamento 1:1
Relacionamento 1:*
Relacionamento *:*
Anomalia dos dados
Tabelas “fazem tudo” geram anomalias
Anomalia de inserção
Impede a inclusão de registros devido à falta de dados.
Anomalia de exclusão
Impede a exclusão de registros devido ao relacionamento com outra tabela.
Anomalia de alteração
Impede a alteração de registros devido ao relacionamento com outra tabela.
Normalização de dados
Evitar anomalias
Facilitar a manutenção
Maximizar a performance
Manter a integridade dos dados
Normalização de dados
Criada em 1970;
5 Formas Normais (FNs);
Na prática a normalização é feita por intuição;
Resulta em um número maior de tabelas no banco;
Mais tabelas podem aumentar a manutenção e diminuir a performance;
Deve ser utilizado com bom senso.
Primeira Forma Normal (1FN)
Cada linha de tabela deve representar um registro
Cada célula de tabela deve conter um único valor
1FN
Tabela 
Original
Segunda Forma Normal (2FN)
Obrigatoriamente estar na 1FN
Atributos não chave da tabela devem depender de alguma das chaves da tabela
1FN
2FN
Terceira Forma Normal (3FN)
Obrigatoriamente estar na 2FN
Atributos não chave da tabela devem depender exclusivamente da chave primária da tabela
2FN
3FN
4FN e 5FN
Separam em novas tabelas valores que ainda estejam redundantes em uma mesma coluna
3FN
4FN 
e
5FN
Exercício
Baseado na especificação de um sistema fictício apresentada a seguir, organize e desenhe manualmente em um papel as tabelas que fornecem uma solução adequada para a situação, normalizando o que achar necessário, indicando no desenho as chaves primárias e relacionamentos caso existam.
Especificação fictícia: 
A Unifacs está contratando você como DBA para que você crie um banco de dados para gerenciar as matrículas dos alunos da Unifacs. Neste banco de dados deverá estar armazenado as informações dos cursos disponibilizados pela Unifacs, como nome, tipo, preço e os dados do professor ou instrutor responsável pelo curso (nome e telefone).
Neste mesmo banco de dados deve ser armazenado as informações dos alunos da Unifacs (nome, endereço e e-mail) bem como todos os cursos que o aluno já se matriculou. Assim como no site Unifacs, deve ser possível comprar dois ou mais cursos em um mesmo pedido, armazenando data e hora da compra. 
Leve em consideração que todas as informações
dos alunos, cursos e instrutores poderão ser alteradas a qualquer tempo. Popule as tabelas criadas com alguns exemplos fictícios.
Todas as chaves estrangeiras apresentadas neste exemplo são consideradas índices.
Exercício
Segue “Tabelão Geral” criado para atender a solução. Realize as normalizações necessárias para atender corretamente a demanda.
Exercício (Solução)
Mais de uma solução pode ser considerada adequada para este exercício, de acordo com o bom senso de cada DBA.
A tabela TIPO foi criada separadamente pois um mesmo tipo de curso poderá ser utilizado em dezenas de cursos. Para poupar recursos de armazenamento na tabela CURSO – pois armazenar um número (campo CODIGO) ocupa menos espaço do que armazenar textos (campo TIPO) - e também para disponibilizar os tipos de cursos sem depender do cadastro de outros cursos, esta informação deve ser gerenciada por esta tabela.
Exercício (Solução)
A tabela PROFESSOR foi criada separadamente dos cursos pois um mesmo professor pode ser o responsável por um ou mais cursos disponibilizados pela Unifacs. Para não haver redundância de dados, gerar economia de espaço de armazenamento e facilidade de manutenção (alteração de dados do instrutor), estas informações devem ser gerenciadas por esta tabela.
Exercício (Solução)
A tabela CURSO é criada com as colunas TIPO e PROFESSOR como chaves estrangeiras (FK), pois representam o código dos registros das outras tabelas as quais fazem referência. Desta forma, se o professor mudar o seu telefone, será necessário alterar apenas na tabela PROFESSOR, além da economia em espaço de armazenamento por não repetir informações.
Exercício (Solução)
A tabela ALUNO é criada sem nenhuma informação sobre as matrículas já realizadas por este aluno, para evitar que seus dados pessoais sejam repetidos em mais de um registro de matrícula. Nesta tabela uma possibilidade seria não criar a coluna CODIGO e em seu lugar utilizar a coluna EMAIL como chave primária. Contudo, para prevenir anomalias de alteração (pois e-mail é algo que uma pessoa pode mudar e criar outro, e neste caso seria necessário alterar em outras tabelas que fizessem referências), bem como para poupar espaço de armazenamento ao utilizar a chave primária em outras tabelas, é recomendável utilizar códigos únicos internos como chave primária.
Exercício (Solução)
A tabela PEDIDO representa o momento em que o aluno realizou o seu pedido, como um caixa de mercado. Ela apresenta as informações do aluno e do momento das matrículas, mas como cada aluno pode estar se matriculando em um ou mais cursos no mesmo pedido, a tabela PEDIDO deve ser referenciada pela tabela PEDIDO_DETALHE, onde consta cada curso que o aluno está se matriculando.
Observe que não consta o valor total do pedido nesta tabela, pois este valor pode ser obtido com a soma dos itens que fazem parte deste pedido, gerenciados pela tabela PEDIDO_DETALHE.
Exercício (Solução)
A tabela PEDIDO_DETALHE informa quais cursos fazem parte de cada pedido realizado na Unifacs. Observe que a chave primária neste exemplo é formada pelas chaves estrangeiras PEDIDO e CURSO. Isto ocorre pois em nosso modelo podemos assumir que não é possível comprar dois ou mais cursos iguais em um mesmo pedido.
Observe que existe uma coluna VALOR, que pode parecer redundante com a coluna VALOR já existente na tabela CURSO, contudo ela será encarregada de armazenar o valor do curso no momento da matrícula, já que futuramente o preço na tabela CURSO poderá ser corrigido, devido a novos preços praticados pela Unifacs.
Como a coluna VALOR desta tabela e a coluna VALOR de CURSOS possivelmente terão valores que poderão se repetir em vários registros, seria possível ainda normalizar esta coluna em uma tabela chamada PRECO formada por um código (PK) e o valor em questão, e apenas referenciar este código nas tabelas citadas. Contudo, por ser um campo numérico e significativamente ocupar menos espaço que outros campos de texto, este campo não será normalizado em tabela própria.
Obrigado e até a próxima aula