Conversão de diagrama de classes para o modelo relacional
Como vimos, os Diagramas ER e os Diagramas de classes foram concebidos para representar as entidades e classes de uma base de dados.
A questão importante que agora se coloca é saber como utilizar os diagramas ER ou de classes para elaborar o modelo de uma base de dados relacional — isto quer dizer: desenhar um modelo (ou esquema) com as tabelas da base de dados, incluindo, para cada tabela, os campos que a constituem, as chaves primárias de cada tabela, as chaves estrangeiras necessárias às relações entre as tabelas, etc.
Consideremos, a título de exemplo, uma situação muito simples, em que temos apenas as entidades Fornecedor e Artigo e em que um fornecedor pode fornecer um ou vários artigos e um artigo pode ser fornecido por zero ou vários fornecedores.
Na figura abaixo, temos o diagrama ER (em cima) e o diagrama de classes (em baixo) correspondente a esta situação.
Modelo conceptual da BD
Esta fase corresponde aos diagramas ER ou de classes apresentados na figura acima.
Nesta fase apresentam-se apenas as entidades principais a ter em conta para a elaboração da base de dados e, opcionalmente, os atributos mais importantes dessas entidades.
O modelo conceptual deve representar a base de dados de uma forma independente do SGBD em que vier a ser implementada.
Modelo lógico da BD
Esta fase resulta de um maior detalhe dos diagramas elaborados na fase anterior, tendo já em vista o modelo de base de dados e o SGBD que se vai adotar.
Nesta fase, o modelo lógico da base de dados já tem de ser desenhado de acordo com o modelo relacional de bases de dados (sendo este o modelo que se adotou, como acontece na maior parte dos casos).
Isto implica que devem ser explicitados todos os atributos de cada entidade, bem como o atributo que vai funcionar como chave primária (ver figura abaixo).
Modelo físico da BD
Na fase do modelo físico da base de dados, as entidades do modelo lógico são convertidas em tabelas (na sua representação de estrutura).
Aqui, já é necessário ter em conta todas as regras de funcionamento dos SGBD relacionais.
Por exemplo, uma questão muito importante é que esses sistemas não permitem diretamente relações entre tabelas do tipo M:M (muitos-para-muitos) mas apenas dos tipos 1:1 e 1:M.
No nosso exemplo em análise (na figura acima), verificamos que o relacionamento entre Fornecedor e Artigo é do tipo M:M. Como os SGBD relacionais não permitem esta relação, ela deve ser reconvertida para relacionamentos 1:M. Neste caso, a solução passa por introduzir uma tabela de relacionamento — que vai traduzir a relação entre as duas entidades originais.
Na figura abaixo, está representada a solução para esta situação e que é também o modelo físico para a nossa base de dados. Para além das tabelas Fornecedor e Artigo, foi introduzida a tabela Fornece_Artigo.
A tabela Fornece_Artigo deverá ter, como chave primária, a junção das chaves primárias das duas outras tabelas: CodForn e CodArt que são importadas para aqui como chaves estrangeiras (FK – Foreign Key).
NOTA: a chave primária da tabela Fornece_Artigo é formada pelas duas chaves estrangeiras: CodForn (importada de Fornecedor) e CodArt (importada de Artigo).
O diagrama da figura acima apresenta um exemplo muito simples de um modelo físico de uma base de dados. Para tal, estão presentes:
- todas as tabelas e todos os seus campos;
- os tipos de relacionamentos entre as tabelas;
- as chaves primárias (com a indicação <<PK>>) e as chaves estrangeiras (indicação <<FK>>).
Nesta fase, também é típico apresentar as é tabelas da base de dados na sua representação analítica. No nosso exemplo, seria assim:
Fornecedor (CodForn, Nome, Morada)
Artigo (CodArt, Designação, Tipo)
ForneceArtigo (CodForn, CodArt, Preço)
Regras de conversão de relacionamentos para o modelo relacional
Vamos apresentar um conjunto de situações de relacionamentos binários típicos quanto à cardinalidade e participação das entidades. Estas situações influem no número de tabelas necessárias, bem como nos seus campos, chave primárias e chaves estrangeiras. É isso que vai ser aqui analisado.
