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

Artigo 7 - Modelo Relacional

Modelo Relacional

O modelo relacional surgiu como uma tentativa de libertar os utilizadores das especificações rígidas associadas ao formato dos dados como acontecia com o modelo hierárquico e o modelo em rede.

O modelo relacional surgiu em 1970, tendo por base a seguinte publicação que se tornou um clássico de Codd.

Ao contrário dos modelos anteriores (hierárquico e em rede), o modelo relacional não evoluiu a partir das técnicas de processamento de ficheiros.

Uma das principais vantagens do modelo elaborado por Codd foi ter-se baseado num ramo da matemática que é, simultaneamente, simples e poderoso - a teoria dos conjuntos. O modelo desenhado por Codd foi durante alguns anos desenvolvido e implementado apenas em universidades e em laboratórios de pesquisas nesta área.

A estrutura de dados utilizada no modelo relacional é a relação. Esta pode se definida como uma tabela constituída por linhas e colunas, na qual as colunas ou campos representam os atributos e as linhas representam os registos ou as instâncias da relação.

Por definição, uma relação é uma estrutura bidimensional que obedece a um esquema determinado de zero ou mais instâncias. O esquema de uma relação e constituído por um ou mais atributos que traduzem o tipo de dados a armazenar. A cada instância de uma relação chama-se tuplo.

O modelo relacional é constituído por:

   1.Relação/ tabela

   2.Atributos/ colunas

   3.Tuplos/ linhas

Equivalência entre conceitos

 

Associado ao modelo relacional existem 2 conceitos fundamentais a saber:

•          Grau de uma Relação – corresponde ao número de atributos que constituem o esquema de uma relação.

•          Cardinalidade de uma relação – corresponde ao número de tuplos (linhas) de uma relação (tabela).

Exemplo

 

Chaves

No modelo relacional a única forma de relacionar dados que existem numa tabela, com dados que existem noutra tabela, é através de atributos comuns. Assim vão existir atributos especiais (chaves estrangeiras) que servem para fazer ligações a outras tabelas em que esses mesmos atributos identificam, univocamente cada uma das linhas (chaves primarias).

Tipos de chave:

        1. Superchave

        2. Chave candidata

        3. Chave primária

        4. Chave estrangeira

Restrições de integridade

As restrições de integridade são um dos objectos principais de um sistema gestor de base de dados. A integridade dos dados é um termo abrangente que inclui, simultaneamente, os conceitos de consistência, precisão e correcção dos dados armazenados numa base de dados. Existem 4 tipos de integridade:

1.      Integridade da entidade – cada tabela deverá possuir na sua definição uma chave primária.

2.      Integridade do domínio – o valor de um campo deve obedecer ao tipo de dados e às restrições de valores admitidos para essa coluna.

3.      Integridade referencial – tem por objectivo manter os dados sincronizados, entre tabelas que estejam relacionadas.

4.      Integridade definida pelo utilizador – é obtida pela definição específica de regras particulares do negócio.

Álgebra e cálculo relacional

Codd propôs dois interfaces para o modelo relacional:

     1. Álgebra relacional – se considerarmos que uma relação é um conjunto, então todas as operações que se podem realizar sobre conjuntos pode ser aplicadas à relação.

     2. Cálculo relacional – o utilizador pode definir o que se pretende através de uma forma declarativa, sendo o cálculo baseado em predicados de 1ª ordem.

Com a utilização deste modelo, aquilo que parecia tão complexo tornou-se mais simples, pois podia-se fazer alterações no esquema de base de dados sem afectar a capacidade do sistema em manipular os dados, pois neste modelo toda a informação e armazenada sob a forma de tabelas bidimensionais e as relações são estabelecidas através de colunas (campos) comuns em tabelas distintas.

Para garantir que o modelo relacional fosse definido de forma igual, Codd definiu um conjunto de 12/13 regras a que um SGBD deve obedecer para que possa ser considerado um modelo relacional.