Diagrama de Entidade e Relacionamento

Atravs deste diagrama poderemos representar, de forma sucintae bem estruturada, todos os elementos essenciais abstrados noprocesso de anlise de sistemas. Denominamos entidade (retngulo)estes elementos. Atribumos a cada entidade definida atributospertinentes ao sistema. Desta forma, podemos definir conceitualmenteque representaremos como entidades aqueles elementos no qualgostaramos de armazenar dados que por sua vez, so representadospelos atributos. Atravs do relacionamento (losango) representaremos otipo de relao existente entre as entidades. Abaixo, na Figura 1, temosum exemplo (incorreto ou mal estruturado em melhores palavras) deum 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 fixa-se na formulao do Diagrama de Estrutura de Dados (DED). Atravsdeste diagrama, sero representadas, de forma a facilitar o processoimplementao posterior (SQL), as entidades neste caso, chamadasde tabelas. Os atributos sero representados com seus respectivosdomnios (tipos). Veja a seguir, na Figura 2, os domnios adotados nestediagrama.

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

Figura 2 Domnios dos Atributos

A representao dos relacionamentos existentes no DERpermanece no DED de forma a satisfazer os conceitos do modelorelacional, ou seja, com grande proximidade da implementao dastabelas no SGBD. A seguir, temos o diagrama anterior (DER)transportado para o Diagrama de Estrutura de Dados (DED). Observeque a modelagem ainda est inapropriada. Aqui, por convenincia doaprendizado da Normalizao, alguns elementos foram propositalmenterepetidos de forma errada.

Figura 3 Diagrama de Estrutura de Dados

Normalizao

O processo de normalizao visa corrigir a base de dadosevitando possveis problemas de integridade, redundncia e mestruturao dos dados. A correo acontece atravs dos conceitos dasformas normais que reestruturam o banco de dados. O processo deverocorrer em etapas: primeiramente a base dever satisfazer as regras daprimeira forma normal (1FN). A posteriori, estar enquadrada nas regrasda segunda forma normal (2FN) que por sua vez, s poder serrealizada quando a 1FN j estiver atendida. Por seguinte, outras formasnormais viro ajustando o banco. Adiante iremos corrigir os problemasencontrados no Diagrama de Estrutura de Dados apresentadoanteriormente. As Formas Normais (1FN, 2FN e 3FN) sero explicadasdurante cada etapa do processo.

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

Figura 4 Diagrama de Estrutura de Dados na 1FN

Observao Importante: Existem outras possibilidades de reestruturareste DED pelas regras da 1FN. Propositalmente, a tabela telefonesestar em desacordo com os conceitos relacionais, pois possui umachave estrangeira (Cod_Fornecedor, que tambm primria) que no chave primria na tabela Produtos. Isto foi criado apenas para serposteriormente tratado pela 3FN. Uma outra possibilidade: considerar ocampo Cod_Fornecedor como chave primria (em conjunto comCod_Prod) na tabela Produtos.

Segunda Forma Normal (2FN): Como primeira restrio, a 2FN requereque a base esteja enquadrada na 1FN. A Segunda Forma Normaltrabalha para que todo atributo primo (aqueles atributos que no sochaves primrias) dependa funcionalmente das chaves primrias (poisna prtica, este tipo de problema ocorrer nas tabelas com mais de umatributo chave). Por exemplo, visualize com ateno a tabela Vendas. Onico atributo primo, que talvez (isto varia com a abordagem do sistema)dependa exclusivamente das duas chaves primrias aComisso_Venda_Emp. Os outros atributos, ou s dependem deCod_Venda ou s de Cod_Empregado. A correo desta anomaliaresultaria em duas ou mais tabelas. Uma tabela ser a de Vendas queconter todos os atributos pertinentes. Outra ser a tabela deEmpregados. Se EXISTIR algum atributo que dependa das duas chavessimultaneamente, haver ento uma terceira tabela com chave primriacomposta (Cod_Venda e Cod_Empregado). Por convenincia didtica,suponha que a Comisso_Venda_Emp seja definida quandodeterminado empregado realiza determina venda de algum produto, ouseja, exigindo a adoo de uma terceira tabela (neste caso, que jexiste: Prod_Venda antiga entidade Possui).

Figura 5 Diagrama de Estrutura de Dados na 2FN

Terceira Forma Normal (3FN): Analogamente 2FN, a 3FN exige quea primeira e segunda forma estejam satisfeitas. A Terceira FormaNormal trabalha com intuito de evitar a existncia de dependnciatransitiva, ou seja, evitar que um atributo primo dependa funcionalmente(esteja relacionado) de outro atributo primo. Este tipo de problema podeser visualizado na tabela Produtos. Observe que existe uma Sub-TabelaFuncionrios dentro da tabela em questo. A correo desta anomalia feita separando-se essas duas tabelas. Veja na Figura 6, o diagramatratado pela 3FN. O problema ocasionado na correo pela 1FN (databela 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 chavese sua relao com os atributos primos. Deve-se tambm lembrar queela, em geral ser usada na existncia de mais de um atributo chave natabela. J a 3FN trata apenas das questes de dependncia transitiva(ou grosseiramente, da existncia de Sub-Tabelas dentro da Tabela).