Diagrama de Entidade e Relacionamento Diagrama de Estrutura de Dados

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).