Artigo 9 – Normalização de Dados

Como vimos anteriormente as entidades são compostas, por um conjunto de atributos e estas relacionam-se entre si por relações especificas através de atributos comuns(Chave Primária e chave estrangeira) para fazer a ligação entre as entidades.

Os atributos de uma entidade, não podem ser colocados ao acaso, pois, dessa forma o mais certo é perder-se informação ou então iremos deparar-nos com cenários em que se tem duplicação de informação. Para evitar estes problemas, extistem mecanismos bem definidos que nos ajudam a “afinar” o nosso esquema, passo a passo. A este processo chama-se Normalização.

A normalização é o processo que permite a simplificação da estrutura de uma base de dados de modo que esta se apresente num estado óptimo sem duplicação de informação.

A normalização é um processo relativamente simples, que essencialmente tem por objectivo remover grupos repetidos de informação.

Habitualmente, ao normalizar, aumentam-se o número de entidades e o número total de atributos, embora o número de atributos em cada entidade tenha tendência para diminuir pois pretende-se que um determinado dado ou informação seja armazenado na base de dados uma única vez.

Através do processo de normalização vão se eliminando anomalias no esquema que se pretende adoptar para suportar a base de dados.

 Evitando-se:

1-Existência de grupos repetitivos;

2-Existência de atributos multi valor;

3-Redundância de dados;

4-Perdas de informação;

5-Falhas na sincronização dos mesmos dados existentes em tabelas diferentes;

6-Existência de atributos que dependem apenas da parte da chave primária;

7-Existência de relações transitivas entre atributos.

A teoria da normalização é baseada no conceito de forma normal.

Existem regras as quais a estrutura de informação deve obedecer para que se possa afirmar qual o nivel de normalização de estrutura. A essas regras dá-se o nome de formas normais e são (5+1)

1-Primeira Forma Normal (1FN)

2-2FN

3-3FN

4-Forma Normal de Boyce Codd

5-4FN

6-5FN

O objectivo final da normalização é permitir criar, um conjunto de tabelas numa base de dados livre de informação redundante, e que possa ser modificada de forma correcta e consistente.

   

         Objectivos da normalização:

1-Minimizar ou eliminar a redundância da informação;

2-Melhorar a performance do sistema pois não existe, informação redundante;

3-Permitir a integridade referêncial entre entidades.

Embora existam 6 formas normais, é habitual considerar que um esquema de dados que se encontre na terceira forma normal está a um bom nivel e tal é considerado suficiente para a generalidade das aplicações.

            A 3FN é, normalmente, o objectivo da aplicação da normalização. As duas primeiras formas normais, 1FN e 2FN correspondem ao passo intermédio para obter a 3FN.

           

                        Normalização de dados

Formas Normais

Uma factura quando é emitida, pelo estabelecimento comercial, é constituida pelo seguinte conjunto de campos:

FACTURA = Nº da Factura + Data + Total_de_factura + Dados_do_cliente* + {Linha_da_factura**}

*Atributos Multi-valor

**Grupo Repetitivo

Linha de Factura ->  Nº da factura; cod_prod; descrição produto; quantidade; preço; valor(preço*Quantidade) ; IVA; Total(Valor + IVA).

Dados do Cliente-> Cod_cliente; Nr_Cont; Nome; Morada; Telefone; Fax.

1ªFN -Uma relação está na 1ªFN quando

            *Não tem atributos Multivalor;

            *Não tem grupos repetitivos.

Factura = Nr_fact+Data + Total_da_factura + cod_cliente + nr_contribuinte + Nome + Morada + telef + fax + {n_da_lina + cod_prod + desc_prod + quant + preço + valor + IVA + Total }

Factura = Nr_fact + Data + total_da_fact + cod_cliente + nr_contribuinte + Nome + Morada + Telefone + Fax

Linha da Factura=(Nr_fact + nr_linha(campo combinado para chave)) + cod_prod + desc_prod + quant + preco + valor + IVA +  Total

            2 Tabelas ou 2 Entidades

2ªFN - Uma relação está na 2FN se:

            *Está na 1FN

            *Todos os atributos(campos) não chave dependem funcionalmente da totalidade da chave.

Uma entidade (tabela)  encontra-se automaticamente , na 2FN , se se encontra na 1FN e se a sua chave primária for contituida por um único atributo.

Linha Factura = Nr Linha + Cod_prod + Quantidade + Preço + Valor + IVA + Total

Produto = Cod_produto + Desc_produto + Preço

3ªFN - Uma entidade está na 3FN se:

            *Está na 2FN

            *Todos os atributos não chave, não dependem funcionalmente uns dos outros.

(As entidades não devem ter associado aos seus atributos assuntos diferentes)

Factura= nr_factura, Data, Total de Factura, nº contribuinte.

Cliente=Nº contribuinte, Nome, Morada, Telefone, Fax.

Linha=Nr Factura, Nr Linha, cod_ produto, Quantidade, Preço, IVA.

Preço=Cod_produto, Nome Produto.

A normalização é executada como uma série de passos, cada passo corresponde a uma forma normal com propriedades conhecidas.

           Á medida que procedemos á normalização, as relações tornam-se cada vez mais restritivas e menos vulneráveis a anomalias.

          

  As notações mais comuns para apresentar as estruturas não normalizadas, indicando os grupos repetitivos são:

   a)      Notação DeMarco

Livro=ISBN, Titulo, Data Edição, Capa, Nº Unidades Editadas, Cod. Colecção, {Cod_autor, nome autor, telefone autor, contribuinte, cod nacionalidade, nacionalidade} grupo repetitivo.

    b)      Notação Gane and Sarson.

Normalização

Artigo 8 - Modelo Orientado Por Objectos

 Modelo Orientado Por Objecto

 

A necessidade de representar realidades complexas levou ao desenvolvimento de sistemas orientados por objectos.

O objectivo da existência destas bases de dados é permitir estender o conceito de programação.

Orientada por objectos e adicional também aos sistemas de armazenamentos de dados. Daqui resulta uma proximidade muito maior entre as aplicações e os elementos que são armazenados.

As bases de dados orientadas por objectos permitem armazenar tipos complexos de dados ou mesmo objectos. Estas bases suportam entre outras, as características que se seguem, de modo a permitir uma total implementação orientada por objectos:

·      -   Encapsulamento

·      -   Herança

·     -    Polimorfismo

Modelo objecto relacional

A generalidade dos SGBD´S utilizam um modelo relacional, no entanto, vimos anteriormente que existe uma forte tendência para que os sistemas evoluam no sentido de permitir armazenar objectos, perdendo, no entanto, algumas das funcionalidades e das vantagens do modelo relacional, nomeadamente no que se refere á disponibilidade da linguagem SQL como linguagem de manipulação de dados.

Recentemente, apareceram as bases de dados do tipo objecto relacional, tentando incluir numa mesma infra-estrutura o melhor dos dois modelos (relacional e orientado objectos).

Não é uma nova tecnologia mas sim uma junção dos dois modelos.

As bases de dados deste tipo são híbridas. Trata-se, normalmente, de um sistema gestor de base de dados relacional cujas funcionalidades foram estendidas de maneira a suportar o armazenamento e o processamento de objectos, que possam ser tratados como se fossem um tipo de dados da própria base de dados.

Tratando-se de uma evolução dos SGBD´S relacionais, o modelo objecto relacional integra na sua estrutura o processamento robusto, de transacções e a elevada performance de acesso aos dados que herdou do modelo relacional e a flexibilidade do modelo orientado por objectos.

Um sistema gestor de base de dados objecto relacional utilizam um modelo de dados que incorpora características orientadas por objectos num SGBD relacional.

A maioria das grandes empresas desta área( IBM, informix, Microsoft, oracle e sybase) já disponibilizaram versões objecto relacional dos seus principais produtos.

Outros Modelos

Modelo distribuído

Num sistema de base de dados centralizado, os dados, as aplicações que os manipulam e todo o processamento estão localizados no mesmo computador.

Todos sabemos que, apesar dos baixos custos do material informático, os recursos continuam a ser limitados e finitos. Não existem computadores como espaço ilimitado em disco ou memória.

Por isso, por vezes a solução passa por interligar diferentes computadores, partilhando alguns dos recursos do hardware e software.

Uma base de dados distribuída consiste numa colecção de uma mais base de dados logicamente integrados e distribuídos por vários computadores ligados por uma rede física(LAN ou WAN), é muitas vezes a solução para a complexidade de estrutura de uma base de dados de uma grande empresa.

Apesar da base de dados distribuída existir fisicamente distribuída por vários computadores, os utilizadores vêm-na como se tratasse de uma base de dados centralizada.

Este é o papel do SGBD de base de dados distribuídas que gere a base de dados e fornece todos os mecanismos de acesso que tornam a distribuição dos dados transparente para os utilizadores.

Arquitectura cliente servidor

Este modelo não é propriamente um modelo de base de dados, mas antes um modelo de arquitectura de software.

A arquitectura cliente-servidor foi desenvolvida por um tratamento de ambientes com um número elevado de equipamentos informáticos ligados através de uma rede.

O objecto principal desta arquitectura, foi libertar o servidor da carga habitual de trabalho que lhe era pedida quando tinha de controlar uma rede de terminais não inteligentes, passando a fazer apenas o conjunto de serviços associados ao processamento de dados.

Comunicação de Objectos