Diagrama de Entidade e Relacionamento Através deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstraídos no processo de análise de sistemas. Denominamos entidade (retângulo) estes elementos. Atribuímos a cada entidade definida atributos pertinentes ao sistema. Desta forma, podemos definir conceitualmente que representaremos como entidades aqueles elementos no qual gostaríamos de armazenar dados que por sua vez, são representados pelos atributos. Através do relacionamento (losango) representaremos o tipo de relação 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 próxima etapa do processo de análise de banco de dados fixase na formulação do Diagrama de Estrutura de Dados (DED). Através deste diagrama, serão representadas, de forma a facilitar o processo implementação posterior (SQL), as entidades neste caso, chamadas de tabelas. Os atributos serão representados com seus respectivos domínios (tipos). Veja a seguir, na Figura 2, os domínios adotados neste diagrama. C(número) Utilizado na representação de uma seqüência de caracteres com tamanho número. Exemplo: Nome_Cliente C(60) N(Esquerda, Direita) Para representação de números na base de dados. Teremos Esquerda elementos ao lado esquerdo da vírgula e Direita elementos do lado direito da vírgula (casas decimais). Exemplo: Salario_Empregado N(5,2) com o formato 99999,99 D Representa uma data. Exemplo: Data_Nascimento D Figura 2 Domínios dos Atributos
A representação dos relacionamentos existentes no DER permanece no DED de forma a satisfazer os conceitos do modelo relacional, ou seja, com grande proximidade da implementação 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 conveniência do aprendizado da Normalização, alguns elementos foram propositalmente repetidos de forma errada. Figura 3 Diagrama de Estrutura de Dados Normalização O processo de normalização visa corrigir a base de dados evitando possíveis problemas de integridade, redundância e má estruturação dos dados. A correção acontece através 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 virão ajustando o banco. Adiante iremos corrigir os problemas encontrados no Diagrama de Estrutura de Dados apresentado anteriormente. As Formas Normais (1FN, 2FN e 3FN) serão explicadas durante cada etapa do processo.
Primeira Forma Normal (1FN): A primeira forma normal reajustará na base de dados atributos compostos (atributos que são compostos por sub-atributos, como por exemplo, endereço que é composto por rua, número, 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 Observação 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 também é primária) que não é chave primária na tabela Produtos. Isto foi criado apenas para ser posteriormente tratado pela 3FN. Uma outra possibilidade: considerar o campo Cod_Fornecedor como chave primária (em conjunto com Cod_Prod) na tabela Produtos.
Segunda Forma Normal (2FN): Como primeira restrição, a 2FN requere que a base esteja enquadrada na 1FN. A Segunda Forma Normal trabalha para que todo atributo primo (aqueles atributos que não são chaves primárias) dependa funcionalmente das chaves primárias (pois na prática, este tipo de problema ocorrerá nas tabelas com mais de um atributo chave). Por exemplo, visualize com atenção a tabela Vendas. O único atributo primo, que talvez (isto varia com a abordagem do sistema) dependa exclusivamente das duas chaves primárias é a Comissão_Venda_Emp. Os outros atributos, ou só dependem de Cod_Venda ou só de Cod_Empregado. A correção 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á então uma terceira tabela com chave primária composta (Cod_Venda e Cod_Empregado). Por conveniência didática, suponha que a Comissão_Venda_Emp seja definida quando determinado empregado realiza determina venda de algum produto, ou seja, exigindo a adoção 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 existência de dependência 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 Funcionários dentro da tabela em questão. A correção desta anomalia é feita separando-se essas duas tabelas. Veja na Figura 6, o diagrama tratado pela 3FN. O problema ocasionado na correção pela 1FN (da tabela Telefones) foi, por conseqüência, resolvido. Figura 6 Diagrama de Estrutura de Dados na 3FN Dica: Existe certa semelhança entre a 2FN e 3FN. Para evitar confusão, deve-se, na correção da 2FN, proceder visualizando os atributos chaves e sua relação com os atributos primos. Deve-se também lembrar que ela, em geral será usada na existência de mais de um atributo chave na tabela. Já a 3FN trata apenas das questões de dependência transitiva (ou grosseiramente, da existência de Sub-Tabelas dentro da Tabela).