Diagrama de Entidade e Relacionamento

Atravs deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstrados no processo de anlise de sistemas. Denominamos entidade (retngulo) estes elementos. Atribumos a cada entidade definida atributos pertinentes ao sistema. Desta forma, podemos definir conceitualmente que representaremos como entidades aqueles elementos no qual gostaramos de armazenar dados que por sua vez, so representados pelos atributos. Atravs do relacionamento (losango) representaremos o tipo de relao existente entre as entidades. Abaixo, na Figura 1, temos um exemplo (incorreto ou mal estruturado em melhores palavras) de um Diagrama de Entidade e Relacionamento (DER).

Figura 1 Diagrama de Entidade e Relacionamento

Diagrama de Estrutura de Dados

A prxima etapa do processo de anlise de banco de dados fixase na formulao do Diagrama de Estrutura de Dados (DED). Atravs deste diagrama, sero representadas, de forma a facilitar o processo implementao posterior (SQL), as entidades neste caso, chamadas de tabelas. Os atributos sero representados com seus respectivos domnios (tipos). Veja a seguir, na Figura 2, os domnios adotados neste diagrama.

C(nmero) Utilizado na representao de uma seqncia de caracteres com tamanho nmero. Exemplo: Nome_Cliente C(60) N(Esquerda, Direita) Para representao de nmeros na base de dados. Teremos Esquerda elementos ao lado esquerdo da vrgula e Direita elementos do lado direito da vrgula (casas decimais). Exemplo: Salario_Empregado N(5,2) com o formato 99999,99 D Representa uma data. Exemplo: Data_Nascimento D Figura 2 Domnios dos Atributos

A representao dos relacionamentos existentes no DER permanece no DED de forma a satisfazer os conceitos do modelo relacional, ou seja, com grande proximidade da implementao das tabelas no SGBD. A seguir, temos o diagrama anterior (DER) transportado para o Diagrama de Estrutura de Dados (DED). Observe que a modelagem ainda est inapropriada. Aqui, por convenincia do aprendizado da Normalizao, alguns elementos foram propositalmente repetidos de forma errada.

Figura 3 Diagrama de Estrutura de Dados

Normalizao
O processo de normalizao visa corrigir a base de dados evitando possveis problemas de integridade, redundncia e m estruturao dos dados. A correo acontece atravs dos conceitos das formas normais que reestruturam o banco de dados. O processo dever ocorrer em etapas: primeiramente a base dever satisfazer as regras da primeira forma normal (1FN). A posteriori, estar enquadrada nas regras da segunda forma normal (2FN) que por sua vez, s poder ser realizada quando a 1FN j estiver atendida. Por seguinte, outras formas normais viro ajustando o banco. Adiante iremos corrigir os problemas encontrados no Diagrama de Estrutura de Dados apresentado anteriormente. As Formas Normais (1FN, 2FN e 3FN) sero explicadas durante cada etapa do processo.

Primeira Forma Normal (1FN): A primeira forma normal reajustar na base de dados atributos compostos (atributos que so compostos por sub-atributos, como por exemplo, endereo que composto por rua, nmero, bairro, cep, cidade e uf) e atributos multivalorados (como por exemplo, os telefones do cliente um cliente pode ter de 0 a N telefones). Para que a base esteja enquadrada na 1FN ela precisa satisfazer essas regras. Abaixo, na Figura 4, tempos o DED apresentado anteriormente j reestruturado de acordo com a 1FN.

Figura 4 Diagrama de Estrutura de Dados na 1FN Observao Importante: Existem outras possibilidades de reestruturar este DED pelas regras da 1FN. Propositalmente, a tabela telefones estar em desacordo com os conceitos relacionais, pois possui uma chave estrangeira (Cod_Fornecedor, que tambm primria) que no chave primria na tabela Produtos. Isto foi criado apenas para ser posteriormente tratado pela 3FN. Uma outra possibilidade: considerar o campo Cod_Fornecedor como chave primria (em conjunto com Cod_Prod) na tabela Produtos.

Segunda Forma Normal (2FN): Como primeira restrio, a 2FN requere que a base esteja enquadrada na 1FN. A Segunda Forma Normal trabalha para que todo atributo primo (aqueles atributos que no so chaves primrias) dependa funcionalmente das chaves primrias (pois na prtica, este tipo de problema ocorrer nas tabelas com mais de um atributo chave). Por exemplo, visualize com ateno a tabela Vendas. O nico atributo primo, que talvez (isto varia com a abordagem do sistema) dependa exclusivamente das duas chaves primrias a Comisso_Venda_Emp. Os outros atributos, ou s dependem de Cod_Venda ou s de Cod_Empregado. A correo desta anomalia resultaria em duas ou mais tabelas. Uma tabela ser a de Vendas que conter todos os atributos pertinentes. Outra ser a tabela de Empregados. Se EXISTIR algum atributo que dependa das duas chaves simultaneamente, haver ento uma terceira tabela com chave primria composta (Cod_Venda e Cod_Empregado). Por convenincia didtica, suponha que a Comisso_Venda_Emp seja definida quando determinado empregado realiza determina venda de algum produto, ou seja, exigindo a adoo de uma terceira tabela (neste caso, que j existe: Prod_Venda antiga entidade Possui).

Figura 5 Diagrama de Estrutura de Dados na 2FN

Terceira Forma Normal (3FN): Analogamente 2FN, a 3FN exige que a primeira e segunda forma estejam satisfeitas. A Terceira Forma Normal trabalha com intuito de evitar a existncia de dependncia transitiva, ou seja, evitar que um atributo primo dependa funcionalmente (esteja relacionado) de outro atributo primo. Este tipo de problema pode ser visualizado na tabela Produtos. Observe que existe uma Sub-Tabela Funcionrios dentro da tabela em questo. A correo desta anomalia feita separando-se essas duas tabelas. Veja na Figura 6, o diagrama tratado pela 3FN. O problema ocasionado na correo pela 1FN (da tabela Telefones) foi, por conseqncia, resolvido.

Figura 6 Diagrama de Estrutura de Dados na 3FN Dica: Existe certa semelhana entre a 2FN e 3FN. Para evitar confuso, deve-se, na correo da 2FN, proceder visualizando os atributos chaves e sua relao com os atributos primos. Deve-se tambm lembrar que ela, em geral ser usada na existncia de mais de um atributo chave na tabela. J a 3FN trata apenas das questes de dependncia transitiva (ou grosseiramente, da existncia de Sub-Tabelas dentro da Tabela).