Diretrizes:  Bancos de Dados Relacionais de Engenharia Reversa

Tópicos

• Replicação de Tabelas RDBMS no Modelo de Design
  • Criar uma Classe para cada Tabela
  • Identificar Classes Incorporadas ou Implícitas
  • Lidar com Relacionamentos de Chave Estrangeira
  • Lidar com Relacionamentos Muitos-para-Muitos
  • Introduzir a Generalização
• Replicação do Comportamento RDBMS no Modelo de Design

O procedimento a seguir pode ser usado para produzir um modelo de objeto de um esquema de banco de dados relacional.

Replicação de Tabelas RDBMS no Modelo de Design

A replicação da estrutura do banco de dados em um modelo de classe é um procedimento relativamente simples. O processo listado abaixo descreve o algoritmo para conversão de um esquema de banco de dados relacional em um modelo de objeto.

Criar uma Classe para cada Tabela

Crie uma classe para representar cada tabela que será submetida à engenharia reversa. Para cada coluna, crie um atributo na classe com o tipo de dado apropriado. Tente fazer a correspondência mais aproximada possível entre o tipo de dado do atributo e o tipo de dado da coluna associada.

Exemplo

Considere a tabela de banco de dados Clientes, com a seguinte estrutura, mostrada na figura abaixo:

Definição da tabela Clientes

A partir desse pronto, criamos a classe Clientes, com a estrutura mostrada na figura a seguir:

Classe Clientes inicial

Nessa classe Clientes inicial há um atributo para cada coluna da tabela Clientes. Cada atributo possui visibilidade pública já que qualquer uma das colunas da tabela de origem pode ser consultada.

Observe que, o ícone , listado à esquerda do atributo, indica que o atributo é 'público'. Por padrão, todos os atributos derivados das tabelas RDBMS devem ser públicos, pois o RDBMS geralmente permite que qualquer coluna seja consultada sem restrição.

Identificar Classes Incorporadas ou Implícitas

Geralmente, a classe que resulta do mapeamento direto das classes de tabela contém atributos que podem ser separados em uma outra classe, principalmente nos casos em que os atributos aparecerem em várias classes convertidas. Esses 'atributos repetidos' podem resultar de uma anormalidade das tabelas, por motivos de desempenho, ou de um modelo de dados muito simplificado. Nesses casos, divida a classe correspondente em duas ou mais classes para representar uma visão normalizada das tabelas.

Exemplo

Entretanto, quase que imediatamente após definir a classe Clientes acima, é possível definir uma classe Endereçoscontendo todas as informações de endereço (considerando que haverá outros endereços no sistema), resultando nas seguintes classes:

classe Clientes revisada, com a classe Endereços extraída

A associação dessas duas classes resulta em uma agregação já que o endereço do cliente pode ser considerado como parte do cliente.

Lidar com Relacionamentos de Chave Estrangeira

Para cada relacionamento de chave estrangeira da tabela, crie uma associação entre as classes associadas, removendo o atributo da classe mapeada para a coluna de chave estrangeira. Se a coluna de chave estrangeira tiver sido representada inicialmente como um atributo, remova-a da classe.

Exemplo

Considere a estrutura a seguir para a tabela Pedidos:

Estrutura da tabela Pedidos

Na tabela Pedidos listada acima, a coluna ID_do_Cliente é uma referência de chave estrangeira; essa coluna contém o valor da chave primária da classe Clientes associada à classe Pedidos. Essa representação é mostrada a seguir no Modelo de Design:

Representação dos relacionamentos de chave estrangeira no modelo de design

A chave estrangeira é representada como uma associação entre as classes Pedidos e Itens.

Lidar com Relacionamentos Muitos-para-Muitos

Os modelos de dados RDBMS representam relacionamentos muitos-para-muitos que chamaram a tabela de junção ou a tabela de associação. Essas tabelas permitem que esses relacionamentos sejam representados através de uma tabela intermediária, contendo as chaves primárias de duas tabelas diferentes que podem ser associadas. As tabelas de junção são necessárias porque uma referência de chave estrangeira pode conter apenas uma referência a um único valor de chave estrangeira. Quando uma única linha puder ser relacionada a várias outras linhas de uma tabela diferente, a tabela de junção será necessária para associá-las.

Exemplo

Considere o caso de Produtos, que podem ser fornecidos por qualquer um dos diversos Fornecedores, e de qualquer Fornecedor que pode fornecer qualquer número de Produtos. As tabelas Produtos e Fornecedores possuem a estrutura definida abaixo:

Definições das Tabelas Produtos e Fornecedores

Para vincular essas duas tabelas e localizar os produtos oferecidos por um determinado fornecedor, é necessária a tabela Produtos-Fornecedores , definida a seguir.

Definição da Tabela Produtos-Fornecedores

Essa tabela de junção contém as chaves primárias de produtos e fornecedores e faz sua vinculação. Uma linha na tabela indicaria que um fornecedor específico oferece um determinado produto. Todas as linhas cuja coluna ID_do_Fornecedor correspondesse a uma identificação específica de fornecedor forneceriam uma listagem de todos os produtos oferecidos por esse fornecedor.

No Modelo de Design, essa tabela intermediária é redundante pois um modelo de objeto pode representar diretamente as associações muitos-para-muitos. As classes Fornecedores e Produtos e seus relacionamentos são mostrados na Figura 8, junto com a classe Endereços, extraída da classeFornecedores, de acordo com a discussão anterior.

Representação das Classes Produtos e Fornecedores

Introduzir a Generalização

Geralmente, algumas tabelas terão uma estrutura semelhante. No Modelo de Dados Relacional, não existe o conceito de generalização; portanto, não há como representar duas ou mais tabelas com alguma estrutura em comum. Algumas vezes, uma estrutura comum resulta de uma anormalidade de desempenho, como o caso acima em que a tabela Endereços, extraída em uma classe separada, está 'implícita'. Nos outros casos, as tabelas compartilham características mais fundamentais que podem ser extraídas em uma classe pai generalizada com duas ou mais subclasses. Para localizar oportunidades de generalização, procure por colunas repetidas em várias tabelas, onde o texto tem mais semelhanças do que diferenças.

Exemplo

Considere as tabelas ProdutosDeSoftware e ProdutosDeHardware abaixo:

Tabelas ProdutosDeSoftware e ProdutosDeHardware

Observe que as colunas destacadas em azul são idênticas; essas duas tabelas compartilham a maior parte de suas definições em comum e diferem somente um pouco. Para essa representação, podemos extrair uma classe Produtos comum que possui as subclasses ProdutosDeSoftware e ProdutosDeHardware, conforme mostra a figura a seguir:

Classes ProdutosDeSoftware e ProdutosDeHardware, mostrando uma generalização da classe Produtos

A figura abaixo, que reúne todas as definições de classe, mostra um diagrama de classes consolidado para o sistema Entrada de Pedidos (somente as classes principais)

Diagrama de Classes Consolidado para o Sistema Entrada de Pedidos

Replicação do Comportamento RDBMS no Modelo de Design

Replicar um comportamento é um procedimento mais difícil, pois geralmente os bancos de dados relacionais não são orientados a objetos e não parecem ter nada semelhante às operações em uma classe no modelo de objeto. Os passos a seguir podem ajudar a reconstruir o comportamento das classes identificadas acima:

1. Criar operações para obter e definir cada atributo. É necessário encontrar uma maneira de definir, alterar e consultar os valores dos atributos dos objetos. Como a única maneira de acessar os atributos de um objeto é através de operações fornecidas pela classe, essas operações devem ser definidas na classe. Ao criar as operações que definirão o valor de um atributo, verifique se incorporou todas as restrições de validação que possam ser operadas na coluna associada. Se não houver restrições de validação, você poderá optar por simplesmente marcar os atributos como permitidos para visibilidade "pública", como foi feito nos diagramas acima (com o ícone à esquerda do nome de atributo), para indicar que podem ser obtidos e definidos.
2. Criar uma operação na classe para cada procedimento armazenado operado na tabela associada. Os procedimentos armazenados são subrotinas que podem ser executadas dentro do próprio DBMS. Essa lógica precisa ser convertida no Modelo de Design. Se um procedimento armazenado operar apenas em uma classe, crie uma operação na classe com os mesmos parâmetros e o mesmo tipo de retorno do procedimento armazenado. Documente o comportamento do procedimento armazenado na operação, verificando na descrição do método se a operação é implementada pelo procedimento armazenado.
3. Criar operações para gerenciar as associações entre as classes. No caso de uma associação entre duas classes, é necessário que haja uma maneira de criar, gerenciar e remover as associações. As associações entre os objetos são gerenciadas através de referências a objetos. Portanto, para criar uma associação entre Pedidos e ItensDeLinha (isto é, para adicionar ItensDeLinha a Pedidos), uma operação seria disparada em Pedidos, passando ItensDeLinha como um argumento (isto é, Order.add(aLineItem)). É necessário que também haja maneiras de remover e atualizar a associação (isto é, Order.remove(aLineItem) e Order.change(aLineItem,aNewLineItem)).
4. Lidar com Exclusão de Objeto. Se o idioma de destino suportar uma exclusão explícita, acrescente o comportamento ao destrutor de classe que implementará a verificação de integridade referencial. Nos casos em que houver restrições de integridade referencial no banco de dados, como exclusão em cascata, o comportamento precisará ser replicado nas classes apropriadas. Por exemplo, o banco de dados poderá definir uma restrição para determinar que sempre que o objeto Pedidos for excluído, todos os objetos ItensDeLinha associados também sejam excluídos. Se o idioma de destino suportar coleta de lixo, crie um mecanismo que permita remover linhas de tabelas quando o objeto associado for coletado para a lixeira. Observe que isso é mais difícil do que parece (e mesmo assim parece difícil), pois será necessário implementar um mecanismo que garanta que nenhum cliente de banco de dados tenha qualquer referência ao objeto que será coletado para a lixeira. Não basta depender das capacidades de coleta de lixo do ambiente de execução/máquina virtual; essa é uma visão simplista do cliente de perceber o mundo.
5. Lidar com o Comportamento Implicado por Consultas. Examine as instruções Select que acessam a tabela para verificar como as informações são recuperadas e manipuladas. Para cada coluna diretamente retornada de uma instrução Select, defina a propriedade public do atributo associado para true; todos os outros atributos deverão ser private. Para cada coluna calculada em uma instrução Select, crie uma operação na classe associada para calcular e retornar o valor. Ao considerar as instruções Select, inclua também as instruções Select incorporadas nas definições View.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process