Modelagem de Dados - Validação do modelo ER

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Veja neste artigo Modelagem de Dados - a validação do Diagrama Entidade -Relacionamento: o DER.

Mauri Gonçalves (e-mail) é acadêmico de Tecnologia em Desenvolvimento de Sistemas e autodidata em Microsoft Access.

Nesta terceira parte da nossa série, vou falar sobre a validação do Diagrama Entidade-Relacionamento: o DER. Tendo definido as entidades, seus atributos e relacionamentos, vamos fazer uma verificação em nosso modelo ER em busca de falhas. É nesta fase que vamos validar nosso modelo ER e corrigir falhas em relacionamentos e possíveis entidades que deveriam ou não existir.

Nesta parte, também começamos a visualizar o modelo físico do banco de dados, onde as entidades viram tabelas e os atributos viram campos. Abaixo estão descritos os erros mais frequentes ocorridos no modelo:

Associações Incorretas: No modelo ER sempre pensamos nas associações entre entidades não entre atributos. Seria incorreto por exemplo associar ao Livro (voltando ao nosso modelo Biblioteca) o nome do usuário que o tomou emprestado. Não se pode associar o nome do usuário ao livro, e sim o usuário como um todo. Verifique se não há associações entre atributos no seu modelo. Faça sempre associações entre Entidades.

Usar uma entidade como atributo de outra: No modelo lógico, as associações ainda se dão de forma abstrata. É incorreto colocar na entidade Empréstimo o atributo Usuário, sendo que Usuário é uma entidade associada e não um atributo e isso vale para qualquer outra entidade relacionada. Essa regra costuma gerar muita controvérsia porque costumamos confundir o conceito com o modelo físico onde criamos as Chaves - mas este assunto veremos mais à frente.

Usar o número incorreto de entidades em um relacionamento: Verifique sempre os casos de mais de uma entidade associada á mesma entidade. Nestes casos, o que surge é um relacionamento redundante e desnecessário.

Depois de verificados e corrigidos os erros nas associações (ou relacionamentos) devemos verificar se o modelo está completo. Nele devem ser expressadas todas as entidades, com seus atributos e relacionamentos. Para isso, verifique se é possivel obter todas as informações desejadas a partir do modelo construido e também se todas as transações de dados pode ser executadas. Se tudo estiver ok, partimos para o próximo passo.

Verificar redundâncias: Um modelo de banco de dados deve ser "mínimo", ou seja, não apresentar nenhum tipo de redundância. Para verificar a redundância nas transações com dados, analise a função de cada relacionamento e reveja os que fizerem operações muito semelhantes ou iguais. Verifique também se há ciclos associativos, por exemplo:

"A é associado a B que é associado a C que é associado a A"

Neste caso, á uma redundância na parte "C que é associado a A", pois C ja é associado a A através da entidade B, ou seja, este exemplo representa uma associação desnecessária e pode ser descartada sem nenhum prejuízo para o modelo. O correto seria: "A é associado a B que é associado a C"

Além disso, podem haver atributos redundantes nas entidades. Atributos redundantes são aqueles que podem ter uma nomenclatura diferente porem eles armazenam os mesmo dados, a mesma informação. Verifique a existencia destes atributos e elimine-os do modelo.

Outro item considerável é o aspecto de tempo do banco de dados. Quando construimos modelo ER, pensamos somente na situação momentânea do banco de dados. Para corrigir isso, devemos verificar atributos e relacionamentos que podem ser alterados durante a utilização do banco de dados.

Um exemplo ótimo de atributo, porém fora do nosso caso da Biblioteca, é o Empregado.

Suponha a existência de uma entidade Empregado e o atributo Salario. A partir dessa entidade, pode-se criar uma entidade Salario com o atributo Data. Desta forma, obtém-se um histórico de salários do empregado.

Um exemplo de associação pode ser a associação entre Empregado e Departamento. Adicionando um atributo Data neste relacionamento, teremos um histório de departamentos por onde o Empregado passou.

Também é importante levar em conta o armazenamento de informações antigas. Para evitar o crescimento demasiado do banco de dados, podem ser eliminadas informações antigas ou podem ser reinseridas no banco de outra forma. Por isso, é importante pensar no caso de remoção de dados da base, que outras informações seriam comprometidas. Deve-se planejar como guardar informações antigas ou que com o passar do tempo não venham mais a ser utilizadas, como, por exemplo, informações que serão usadas somente para cálculos estatísticos ou visões.

Pode ocorrem também a existência de entidades isoladas, isto é, sem nenhuma associação. A ocorrência destas entidades não é de todo incorreto, mas, na prática, elas acabam sendo descartadas, por isso verifique se ela não faz parte de alguma associação incorreta ou que não tenha sido feita.

Lembre-se que por mais simples que seja seu modelo ER, você deve fazer a validação completa. Este é o momento de corrigir erros e falhas de modelagem porque quando identificadas na modelagem física você acaba tendo que voltar a esse passo para fazer a arrumação do problema.

No proximo artigo, começamos a falar sobre a Modelagem Física.

Até lá.

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?