Matéria: Banco de Dados Banco de Dados Aula 02 Professor: Esp.: Patricia Dias da Silva Peixoto
NORMALIZAÇÕES DE ENTIDADES DO BANCO DE DADOS Quando estamos criando as tabelas de um banco de dados, devemos tomar o cuidado de retirarmos dessas os campos que armazenarão registros redundantes desnecessários. A esse processo damos o nome de NORMALIZAÇÃO. Em alguns momentos a redundância de dados torna-se necessária, como veremos adiante. Normalizar, diante do que foi descrito acima, nada mais é do que: A) MINIMIZAR REDUNDÂNCIAS e INCONSISTÊNCIAS de dados; B) FACILITAR A MANIPULAÇÃO DO BANCO DE DADOS; C) FACILITAR A MANUTENÇÃO DOS DADOS NO BANCO DE DADOS. Antes de normalizarmos as ENTIDADES de um banco de dados relacional, devemos identificar as ANOMALIAS NELAS EXISTENTES.
ANOMALIAS DE ENTIDADES DE BANCO DE DADOS As anomalias mais comuns existentes em ENTIDADES de um banco de dados são as seguintes: Anomalia da INCLUSÃO; Anomalia da INCONSISTÊNCIA; Anomalia da ALTERAÇÃO (atualização); Anomalia da EXCLUSÃO;
ilustrando as situações de anomalias de entidades. Anomalia de INCLUSÃO Ocorre quando: que para trabalhar com uma nova peça no banco de dados, o usuário será obrigado fazer um pedido da mesma, visto que não é possível somente cadastrar dados da peça. Este é um exemplo prático de uma anomalia de INCLUSÃO.
ilustrando as situações de anomalias de entidades. Anomalia de ALTERAÇÃO (atualização) Ocorre quando: Ao efetuar UMA alteração na peça BT04, essa se fará necessária em várias outras tuplas da entidade, visto que vários pedidos desta mesma peça foram cadastrados na entidade. Este é um exemplo prático de uma anomalia de ALTERAÇÃO.
ilustrando as situações de anomalias de entidades. Anomalia de EXCLUSÃO Ocorre quando: Ao excluirmos o pedido 1000 perderemos também qualquer referência da peça AX12, pois esta foi requisitada somente em um pedido. Imagine o que aconteceria se esta peça fosse vendida para algum cliente! Este é um exemplo prático de uma anomalia de EXCLUSÃO.
ilustrando as situações de anomalias de entidades. Anomalia de INCONSISTÊNCIA Ocorre quando: não há nada que impeça que a peça BT04 seja cadastrada com várias descrições diferentes. Isso seria uma catástrofe no momento de uma venda! Este é um exemplo prático de uma anomalia de INCONSISTÊNCIA.
NORMALIZAÇÃO Diante das anomalias exemplificadas anteriormente iremos falar neste ponto das normalizações de entidades de um banco de dados. Existem 6 formas de normalizarmos uma entidade: 1NF primeira forma normal; 2NF segunda forma normal; 3NF terceira forma normal; BCNF Forma normal de Boyce Codd; 4NF quarta forma normal; 5NF quinta forma normal;
1NF (PRIMEIRA FORMA NORMAL) Uma relação está na 1FN, se somente todos os domínios básicos (CONTEÚDOS DE CADA CAMPO) contiverem somente valores atômicos (não repetidos). Para atingir esta forma normal devemos eliminar os grupos de registros repetidos. Como? Procedimentos: a) Identificar a chave primária da entidade; b) Identificar o grupo de atributos que causam a repetição de registros e excluí-lo da entidade; c) Criar uma nova entidade com a chave primária da entidade anterior e o grupo de atributos que causavam a repetição. A chave primária da nova entidade será obtida pela concatenação da chave primária da entidade inicial e a chave primária do grupo repetitivo.
A ENTIDADE CITADA NÃO ESTÁ NORMALIZADA, PORTANTO DEVEMOS NORMALIZÁ-LA PARA A 1NF, pois apresenta as seguintes ANOMALIAS: a) Para toda nota fiscal cadastrada, há necessidade de informarmos o código, a descrição e o preço de venda de CADA mercadoria da nota. Desta forma, corremos o risco de cadastrarmos uma descrição ou preço, de uma MESMA MERCADORIA, de diferentes formas. b) Caso seja necessário alterar a descrição ou preço de venda de uma mercadoria, correríamos o risco de alterar somente em uma tupla da entidade. c) Se quisermos excluir uma determinada mercadoria da entidade, deveremos procurá-la tupla a tupla, o que tornaria uma tarefa trabalhosa. d) Caso excluíssemos da entidade uma mercadoria que fosse cadastrada uma única vez, perderemos as informações dessas para consultas futuras.
OBSERVAÇÃO IMPORTANTE: Na nova entidade Vendas, ilustrada na figura anterior, note que a chave primária é composta pela chave da tabela NotaFiscal (NumeroNotaFiscal) e CódigoMercadoria.
Uma relação está na 2FN, se e somente se, ela estiver na 1NF e todos os atributos não chave forem totalmente dependentes da chave primária (dependente de toda a chave e não apenas de parte dela). Procedimentos: a) Identificar os atributos que não são funcionalmente dependentes de toda a chave primária. b) Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles. A chave primária da nova entidade será o atributo nos quais os atributos removidos são funcionalmente dependentes.
Exemplo: Vejamos as entidades a seguir: Notas Fiscais: (Num. NF, Série, Código do Cliente, Nome do cliente, Endereço do cliente, Total Geral da Nota) Arquivo de Vendas: (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da Venda)
AS ENTIDADES ACIMA NÃO ESTÃO NA SEGUNDA FORMA NORMAL, MAS SIM NA PRIMEIRA FORMAL
Arquivo de Notas Fiscais (Num. NF, Série, Código do Cliente, Nome do cliente, Endereço do cliente, Total Geral da Nota) Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da Venda) Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (a ENTIDADE NOTAFISCAL, não foi alterada, por não possuir chave composta) em duas estruturas, a saber: Primeira estrutura (Arquivo de Vendas): Contêm os atributos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria. Segundo estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.
Uma relação está na 3FN se somente estiver na 2FN e todos os atributos não chave forem dependentes não transitivos da chave primária (cada atributo for funcionalmente dependente apenas dos atributos componentes da chave primária, ou se, todos os seus atributos não chave forem independentes entre si). Procedimentos: a) Identificar todos os atributos que são funcionalmente dependentes de outros atributos não chave; b) Removê-los e criar uma nova entidade com os mesmos.
A chave primária da nova entidade será o atributo nos quais os atributos removidos são funcionalmente dependentes. Estrutura na segunda forma normal (2FN): Observem as entidades abaixo: Notas Fiscais: (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, Total Geral da Nota) Vendas: (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria) Mercadorias: (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Estrutura na terceira forma normal (3FN): Observem as entidades abaixo: Notas Fiscais: (Num. NF, Série, Data emissão, Código do Cliente e Total Geral da Nota) Vendas: (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria) Mercadorias: (Código da Mercadoria, Descrição da Mercadoria, Preço de venda) Clientes: (Código do Cliente, Nome do cliente, Endereço do cliente)
Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o único que possuía campos que não eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço, por eliminar o armazenamento frequente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.
As estruturas alteradas e o motivo das alterações: Primeira estrutura (Notas Fiscais): Contêm os elementos originais, sendo excluído os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente). Segundo estrutura (Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço serão constantes. Após a normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema. A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades específicas do sistema, a critério do analista, durante a fase de desenvolvimento do projeto físico do sistema.
A BCNF, a 4FN e a 5FN não serão abordadas neste curso. Ressalta-se que estas normalizações existem e devem ser tratadas em cursos que abordam a fundo as teorias de banco de dados. Vale dizer também, que o objetivo desse curso é aprofundarmos na linguagem Transact-SQL e conhecer a ferramenta SQL-SERVER, o que faz necessário termos noções básicas de normalizações e relacionamentos entre entidades de um banco de dados relacional. Antes de normalizarmos as tabelas de um banco de dados devemos passar por etapas de modelagem de dados. As etapas envolvidas na construção de modelos de dados são: Modelo Conceitual Modelo Lógico Modelo Físico
MODELO CONCEITUAL Nesta etapa da modelagem de dados o DBA deve: Conhecer o negócio Rascunhar as principais entidades do BD. e seus principais atributos. Não se preocupar com os relacionamentos n : n. MODELO LÓGICO Nesta etapa da modelagem de dados o DBA deve: Representar o negócio. Criar as entidades de relacionamentos para substituir os relacionamentos n:n. Definir as chaves primárias de cada entidade. Normalizar as tabelas. Adequar aos padrões do banco de dados escolhido, neste caso, ao padrão do SQL SERVER. Documentar as entidades e seus atributos. MODELO FÍSICO Nesta etapa da modelagem de dados o DBA deve: Tomar ciência das limitações do banco de dados, neste caso, o SQL-SERVER. Considerar os requisitos dos softwares que farão acesso ao banco de dados. Criar fisicamente as entidades, relacionamentos, chaves, índices, definir níveis de acessos entre outros, ou seja, criar fisicamente o banco de dados projetado nas etapas anteriores.