Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Artigo SQL Magazine 63 - Convertendo um Diagrama de Classes
Artigo publicado Revista SQL Magazine 63.
Projeto
Convertendo um Diagrama de Entidade-Relacionamento
A modelagem consiste em um passo importante para a construção de um banco de dados, pois simplifica o processo de captura dos requisitos vindos a partir de um domínio de aplicação antes de se pensar em uma solução técnica para esse problema. No entanto, na continuidade do desenvolvimento de software surgirá a necessidade de transformar tais modelos de dados em bancos de dados físicos, que realmente possibilitem o armazenamento de informações a partir de um SGBD.
Nesse contexto, o objetivo deste artigo é descrever uma abordagem para converter um Diagrama de Entidade-Relecionamento (DER), que é um dos diagramas mais adotados para modelagem de dados durante o desenvolvimento de uma aplicação, em um banco de dados físico.
Este artigo não lida com alguns tópicos avançados relacionados à modelagem de dados, tal como relacionamentos envolvendo três ou mais entidades. Para este momento, iremos focar em relacionamentos binários envolvendo duas entidades, que são aqueles mais comumente encontrados nas aplicações.
Ao final do artigo, será apresentado um estudo de caso relacionado à modelagem de uma aplicação para o domínio hospitalar, onde serão mapeados sintomas e doenças relacionadas a pacientes. Para a modelagem da aplicação, seguiremos os passos apresentados anteriormente para transformar um diagrama de entidade-relacionamento (desenvolvido ao longo do artigo) em um banco de dados físico.
Abordagem para Conversçao de DER em Banco de Dados
A abordagem que iremos seguir é formada por quarto passos, como resumiremos a seguir:
1. Converter as entidades
o Relacionamento um-para-um
o Relacionamento um-para-muitos
o Relacionamento muitos-para-muitos
o Relacionamento supertipo -subtipo
2. Aplicar as regras de negócio às tabelas criadas através da configuração de restrições (constraints) nos campos (colunas) de forma apropriada.
3. Criar referências entre tabelas e integridade referencial, aplicando as regras de negócio apropriadas.
4. Criar índices apropriados. Para típicos bancos de dados OLTP (Online Transaction Processing – Ver Nota DevMan 1), iremos considerar que isso significaria garantir que chaves primárias e estrangeiras estejam indexadas.
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
0 COMENTÁRIO
Space do autor
0
0
