Gerador de Tabelas de Mapeamento GTM

Este é o segundo módulo que trata do mapeamento entre os bancos de dados atra- vés do identificador do motor. Podemos vê-lo como a parte centralizadora que re- quisita e integra os serviços dos outros módulos. O gerador de tabelas de mapeamento tem a finalidade de recuperar os valores originais dos identificadores do motor, enviá-los para o parser, e salvar os resultados do parser nas tabelas de mapeamento. Além disso é responsabilidade deste módulo também recuperar to- dos os demais pontos de entrada e armazená-los nas mesmas tabelas de mapea- mento.

As tabelas de mapeamento são geradas pela primeira vez na primeira inicialização do servidor. Neste momento são buscados todos os pontos de entrada das fontes de dados originais, o parser é chamado para formatar os valores dos identificado- res do motor e a seguir todos os valores são armazenados nas tabelas de mapea- mento. Estas tabelas de mapeamento são armazenadas em um banco de dados gerenciado pelo sistema middleware. Essas tabelas podem ser geradas também pelo usuário. Através da GUI o usuário pode requisitar informações sobre esta ta- bela e decidir se deseja ou não realizar um novo mapeamento.

Entretanto, para que esta técnica tenha o efeito esperado, é preciso que haja uma ligação eficiente entre os dados mapeados e as fontes de dados originais, de modo que as outras informações da relação que armazena o identificador de motor sejam recuperadas com sucesso. Para criar esta referência entre as tabelas, um novo atri- buto foi inserido nas tabelas de mapeamento, além dos dados formatados pelo par- ser. Este atributo é o motor no formato original (Figura 6.2). Em relação ao banco de dados Mentas, este relacionamento é feito através de três atributos -tipo, espe- cificação e baumuster-, em conjunto ou separadamente.

Banco de Dados A Tabela de Mapeamento A Tabela de Mapeamento B Banco de Dados do Sistema Middleware Banco de Dados B .. . .. . ... Banco de Dados C ...

Tipo Espec Modelo ... Ponteiro

As tabelas de mapeamento têm uma importância vital para que a navegação ocorra com sucesso. Todas as consultas que envolvem os pontos de entrada que identifi- cam o motor acessam-nas obrigatoriamente. O acesso também ocorre quando o usuário especifica que a navegação deve ocorrer seguindo as normas de consis- tência entre os pontos de entradas dos bancos de dados envolvidos. Portanto, uma propriedade que deve estar presente nestas tabelas é a sua disponibilidade aos usu- ários sempre que forem requisitadas. Por esta razão, decidimos utilizar duas tabe- las, uma ativa e uma reserva, como veremos a seguir.

Considere o caso em que apenas uma tabela de mapeamento é utilizada. Como sa- bemos, operações de leitura e escrita devem ser cuidadosamente tratadas para ga- rantir a consistência dos dados acessados. Dessa forma, quando um usuário requisitar uma operação que resulte em escrita de dados na tabela (no nosso caso,

isto ocorre quando o usuário requisita através da GUI que um novo mapeamento deve ser feito) os demais devem aguardar até que a transação seja concluída. Po- rém, caso a transação não seja tão simples, o que significa que a tabela ficará blo- queada por um longo período de tempo, todos os demais usuários ficarão inabilitados a fazer acesso aos dados da tabela. Podemos ver o caso ilustrado na Figura 6.3. O primeiro quadro da esquerda apresenta o caso em que todos os usu- ários utilizam a tabela apenas para leitura, o que não ocasiona problema algum. O quadro da direita mostra exatamente o problema onde um usuário está realizando uma operação de escrita na tabela e os demais aguardam sem poder acessá-la. Isso significaria no MENTAS a paralisação da navegação por todos os usuários, até que um novo mapeamento fosse concluído por um usuário, sendo portanto, uma alter- nativa inviável.

Figura 6.3 Problema de Acesso as Tabelas de Mapeamento.

1 2 3 4 1 2 3 4 read read read

read read read read

write

Para garantir que este tipo de problema não exista nas tabelas de mapeamento do MENTAS, nós usamos duas tabelas para cada banco de dados, sendo que apenas uma está ativa num dado instante. A Figura 6.4 ilustra a nossa solução:

1 2 3 4

1 2 3 4

Ativa _{Reserva - vazia}

1 2 4

Ativa

3

Reserva - sendo gerada Reserva – antiga ativa Ativa – antiga reserva

read read

read read read read read write

1 2 1 2 read read read read 1 2

O primeiro quadro ilustra o caso em que todos os usuários estão acessando a tabela de mapeamento ativa, enquanto a outra está vazia - tabela reserva. Se algum usu- ário resolver gerar um novo mapeamento, ele o faz utilizando a tabela reserva (se- gundo quadro). Com isso, não existe o problema apontado anteriormente, dos demais usuários ficarem impossibilitados de navegar pelos bancos de dados inte- grados até que o novo mapeamento seja completado. A navegação entre os bancos de dados continua sendo realizada sem nenhum problema. Quando o novo mape- amento torna-se completo (quadro três da Figura 6.4), a tabela de reserva torna-se a tabela ativa e vice-versa.

Esta técnica introduz um novo problema: como gerenciar as tabelas de mapea-

mento de modo que seja feito o acesso a tabela correta? A Figura 6.5 apresenta como é feito o relacionamento entre as tabelas de mapeamento e as tabelas de ge- renciamento e os usuários numa operação de leitura (read). Os nomes das tabelas de mapeamento ativas para cada banco de dados são armazenados numa outra ta- bela que é a encarregada de informar aos usuários qual é a tabela de mapeamento ativa no momento de um acesso. Dessa forma, qualquer atividade que envolver as tabelas de mapeamento deve antes de tudo consultar a tabela de gerenciamento para localizar a tabela ativa.

A operação de escrita (write) é similar a de leitura. Sendo que a escrita ocorrerá na tabela de mapeamento reserva e quando todos os dados são gravados na tabela re- serva o usuário realiza um novo acesso à tabela de gerenciamento para atualizar o nome da nova tabela que acabou de ser gerada. Como podemos perceber, com esta técnica a navegação é interrompida apenas no momento de atualizar dois campos relativos à tabela de mapeamento que acabou de ser gerado (o nome e o times-

tamp). Este é o único instante em que as operações de navegação são interrompi- das, apenas uma simples e única operação de escrita.

No momento que ocorre a atualização da tabela de gerenciamento, a tabela de ma- peamento ativa torna-se a reserva e a tabela de mapeamento reserva torna-se ativa. Entretanto, a tabela que agora é a reserva ainda está populada com os valores do antigo mapeamento. Este valores devem ser deletados para que um próximo ma- peamento possa ser feito da mesma maneira que o especificado anteriormente. Isto é feito por um thread assíncrono em background.

Figura 6.5

Tabela de mapeamento ativa PSD

1

2 3

Tabela de mapeamento ativa LKD

Tabela de mapeamento reserva PSD

Tabela de mapeamento reserva LKD

Tabela de Gerenciamento

Read

1 - usuário consulta a tabela de gerenciamento para saber qual tabela de mapeamento está ativa 2- usuário recebe a informacao de qual tabela é a ativa

3 - usuário realiza a operacao de leitura da tabela de mapeamento (ativa)

Tabela de Mapeamento versus Tabela de Gerenciamento (Leitura).