domingo, 20 de novembro de 2011

Normalização

1) Quais são as diretrizes informais para o projeto de esquema de relações? Explique resumidamente cada uma.

Diretriz 1ª: Projetar um esquema de relação de maneira que seja simples descrever seu significado. Normalmente, isso significa que não se pode combinar atributos de múltiplos tipos de entidades e tipos de relacionamentos numa simples relação. Intuitivamente, se um esquema de relação corresponde a um tipo de entidade ou tipo de relacionamento, o significado tende a ser claro. Por outro lado, tende ser uma mistura de múltiplas entidades e relacionamentos e, assim, semanticamente não-clara.

Diretriz 2ª: Projetar esquemas de relações de maneira que nenhuma anomalia de alteração ocorra em relações. Se existir alguma anomalia, isso deverá ser considerado para que as modificações pelos programas ocorram corretamente.

Diretriz 3ª: Tanto quanto possível, evite colocar atributos em um esquema de relação base cujos valores possam ser null. Se for inevitável os valores nulls, esteja seguro que eles se apliquem apenas em casos excepcionais e não se apliquem na maioria das tuplas da relação.

Diretriz 4ª: Projetar esquemas de relações tal que, quando aplicadas operações JOINNATURAIS, os atributos nas condições-joins envolvam atributos que sejam ou chaves primárias ou chaves-estrangeiras de maneira a garantir que nenhuma tupla espúria seja gerada.


2) Quais são as métricas de qualidade informal para projeto de esquemas de relações? Explique resumidamente cada uma delas.

São elas:

Semântica de atributos : Assume-se que um certo significado esteja associado aos atributos, para todo agrupamento de atributos que formam uma relação esquema. Intuitivamente, verifica-se que cada relação pode ser interpretada como um conjunto de fatos ou declarações. Este significado, ou semântica, especifica como podem ser interpretados os valores de atributos armazenados em uma tupla da relação, em outras palavras, como os valores de atributos estão relacionados uns com os outros. Em geral, é mais simples descrever a semântica de relações, ao invés da semântica de atributos de uma relação.

Redução de valores redundantes em tuplas: Uma das metas do projeto de esquemas é a minimização do espaço de armazenamento que relações da base ocupam. O agrupamento de atributos em esquemas de relações tem um efeito significativo no espaço de armazenamento.

Redução de valores nulos em tuplas: Uma relação degenerada (tabelão), pode causar valores null, o que prejudica a interpretação dos dados.
Em alguns projetos de esquemas pode-se agrupar atributos em uma “grande” relação. Se muitos atributos não se aplicarem a todas as tuplas da relação, ter-se-á muitos valores nulls na relação. Isto pode despender espaço armazenamento e pode também trazer problemas de entendimento do significado dos atributos na especificação de operações JOIN´s. Um outro problema com valores nulls é que não se pode contá-los quando operações de agregação, tais como COUNT ou SUM são aplicadas. Mais que isso, os valores nulls podem ter múltiplas interpretações, tais como:

- O atributo pode não se aplicar a tupla.
- O valor de atributo para a tupla é desconhecido.
- O valor é conhecido, porém não foi registrado ainda.

Não permissão de tuplas espúrias: Tabelas degeneradas, quando relacionadas poder gerar informações / dados errôneos, isto é, tuplas espúrias.


3) O que é e para que serve o conceito de dependência funcional? Quais são os tipos de dependência? Explique-os

Dependências Funcionais são restrições ao conjunto de relações válidas. Elas permitem expressar determinados fatos em banco de dados relativos ao empreendimento que se deseja modelar.
A noção de dependência funcional generaliza a noção de super chave. Para existir o destino (dependência à chave estrangeira) tem que exitir a origem (chave primária). O atributo deve realmente caracterizar na relação.


4) O que é e para que serve normalização de dados relacionais? Quando será utilizada a normalização na maioria das vezes?

Normalização de dados relacionais é o processo de identificação dos agrupamentos necessários e da localização correta de cada atributo que consiste num conjunto de técnicas designadas, e ainda exercitar as definições relacionadas à normalização eliminando redundâncias e inconsistências de um banco de dados, com reorganização mínima dos dados:

• Identificação das redundâncias e outros problemas
• Reorganização do banco de dados
• Reprojeto das aplicações

A normalização será utilizada quando houver redundâncias e a necessidade de reorganizar os dados, ela converte cada entidade gradualmente para Formas Normais através da aplicação sucessiva de regras que alteram o formato dos dados da 1 Forma Normal até a 5 Forma Normal.

5) O que são e quantas são as formas formais de relação? Explique-as resumidamente. Para manter eficiência e a simplicidade de processamento em certos casos podemos normalizar as relações até a 3ºFN por que?

O objetivo da normalização de um banco de dados é evitar os problemas que podem provocar falhas no projeto do banco de dados, bem como eliminar a mistura de assuntos e as correspondentes redundâncias dos dados desnecessárias. O processo de normalização aplica uma série de regras sobre as tabelas (também chamadas de relações) de um banco de dados, para verificar se estão corretamente projetadas.

Primeira Forma Normal: A primeira forma normal enuncia que cada atributo de uma entidade ou relacionamento pode armazenar apenas um valor. Tabelas com atributos multi-valorados não são consideradas em 1NF.

Segunda Forma Normal: A segunda forma normal (2NF) descreve que todo atributo deve ser determinado unicamente pela chave primária. Se existem atributos que dependem apenas de parte da chave, estes devem ser separados em tabelas onde a 2NF seja obedecida.
Terceira Forma Normal: A terceira forma normal (3NF) exige que a tabela esteja em 2NF e que todos os atributos que não são chave sejam mutuamente independentes, isto é, que não existam funções que definam um ao outro. Portanto, sempre a chave por inteiro deve definir toda a tabela.

Forma normal Boyce/Codd (BCNF): Definição que engloba as outras formas normais, e define que uma tabela está em BCNF se, e somente se, todo determinante funcional for em relação a uma chave candidata. Na prática, uma tabela está em BCNF se estiver em 3NF e não existir dependência funcional dentro da chave primária.



6) Dê exemplos de normalizações de uma relação.

Normalização de banco de dados relacional

Objetivo:
Eliminar redundâncias e inconsistências de um banco de dados, com reorganização mínima dos dados

Sub-Fases:
• Identificação das redundâncias e outros problemas
• Reorganização do banco de dados
• Reprojeto das aplicações


Redundâncias e inconsistências em atributos:

– atributo com domínio enumerável
• representado sem controle

– atributo multivalorado
• representado sem normalização

– atributo pertencente a chave
• ocorre com valor nulo

– atributo redundante
• inferido ou materializado sem controle


Tratamento de atributo com domínio enumerável:

– criar tabela definindo o domínio:
• valor
• descrição, se for o caso

– uniformizar os valores

– controlar atualizações


Exemplo de tratamento de atributo com domínio enumerável:
– TIPO_AREA em AREAESPECIAL



Exemplo de tratamento de atributo com domínio enumerável:
– DATUM em PLAT_FIXA, DGPS (e outras tabelas)



Tratamento de atributo multivalorado:
– normalizar e controlar atualizações



Tratamento de atributo pertencente a chave:
– eliminar nulos



Tratamento de atributo redundante:
– eliminar, ou
– manter e controlar consistência

Exemplo de tratamento de atributo redundante:
– TIPO_AREA em AREASHD parece ter sempre o mesmo valor
– candidato a ser eliminado



Exemplo de tratamento de atributo redundante:
– BLOCO_ANP possui vários atributos que não se aplicam (e portanto são sempre nulos)
– eliminar todos estes atributos



Exemplo de tratamento de atributo redundante:
– BLOCO_ANP, BLOC_PARC, BLOCO_PETRO e PARC podem ser representados em uma única tabela
• novo atributo para indicar o tipo de bloco
• atributos que não se aplicam ao tipo de bloco terão valores nulos



Exemplo de tratamento de atributo redundante:
– o atributo BACIA em DGPS pode ser computado já que a área de cobertura do DGPS e a área da bacia são conhecidos (a mesma situação ocorre em várias outras tabelas)
– manter para melhorar desempenho de consultas (ver tratamento de relacionamentos n-m adiante)
– controlar consistência



Redundâncias e inconsistências na representação de relacionamentos:
– binários n-1
• representados por atributos que não são chaves estrangeiras
– binários n-m:
• representados por atributos multivalorados sem controle

• Tratamento de relacionamentos binários n-1:
– substituir nomes das entidades pelas suas chaves
– transformar o atributo em chave estrangeira para a tabela que representa o conjunto de entidades



• Tratamento de relacionamentos binários n-m:
– normalizar
             • criar uma nova tabela com as chaves estrangeiras apropriadas












Nenhum comentário:

Postar um comentário