"Esta é a terceira e última parte do artigo onde será abordada uma das mais consagradas metodologias de integração."

6 Metodologia de união de esquemas Elmasri

6.1 Visão geral da metodologia

Esta metodologia utiliza uma variante do modelo de entidade relacionamento (E-R) chamada entidade categoria relacionamento (E-R estendido) para representar esquemas ou visões do usuário e discutir o problema de integrar relacionamentos de esquemas diferentes.

Usando três critérios principais para comparar relacionamentos, foi desenvolvido um esquema hierárquico de comparação. Cada caso representado pelos nós terminais desta hierarquia é discutido separadamente e as regras da integração são desenvolvidas. O problema é tratado dentro de um sentido geral, de modo que a discussão qualitativa seja aplicável a diversos outros modelos semânticos de dados.

Com a atual diversidade dos modelos de dados e dos sistemas de gerenciamento de base de dados, o problema da integração de esquemas tem se tornado cada vez mais importante. A integração de esquemas baseia-se em dois contextos diferentes:

a) Projeto global do esquema.

b) Projeto de base de dados lógico.

No projeto global do esquema, diversas bases de dados já existem e estão em uso. O objetivo é projetar um único esquema global que represente os índices de todas estas bases de dados. Este esquema global pode então ser usado como uma relação às diversas bases de dados.

As consultas e transações do usuário podem então ser especificadas ao encontro a este esquema global, e os pedidos são mapeados às bases de dados relevantes.

A integração do esquema é aplicável ao projeto global do esquema em ambientes centralizados e distribuídos. Nesta metodologia de trabalho é focalizado o uso da integração de esquemas no projeto de base de dados lógico. Porém, a filosofia total da integração de esquemas discutida aqui se aplica a ambos os contextos.

6.1.1 Fase de pré-integração

A fase de pré-integração é necessária para especificar correspondências entre objetos em diferentes visões. Nesta fase são tratados, por exemplo, os problemas de homônimos e sinônimos. A fase de pré-integração estabelece os seguintes contextos entre as visões individuais do usuário:

a) Correspondências de nomes de classe.

b) Correspondências de nomes de atributos.

c) Chaves candidatas para cada classe.

d) Correspondências entre classes de entidades em diversas visões.

e) Correspondências entre nomes de regras e relacionamentos.

6.1.2 Critérios para a comparação de relacionamentos

a) Grau de um relacionamento: O grau de um relacionamento é o número de entidades (não necessariamente distintos) participando nesse relacionamento. Uma entidade por si mesma pode ser tratada como um relacionamento do zero grau para finalidades da comparação com outros relacionamentos.

b) Regras em um relacionamento: Uma regra significa a regra usada por uma classe entidade em um relacionamento [BACH77, CHEN76]. Há uma regra distinta para cada classe entidade que participa de um relacionamento.

c) Constraints estruturais: Um relacionamento entre duas classes de objetos é um mapeamento que associa os objetos de uma classe entidade com objetos das outras classes entidade.

6.1.3 Unindo relacionamentos com o mesmo grau

Caso1 - Mesmas regras e mesmos constraints estruturais (ou a ausência de constraints estruturais): Este é o exemplo mais simples de integração de relacionamentos.

Um exemplo deste tipo é mostrado na Figura 11 e Figura 12.

Figura 11 - Relacionamentos com o mesmo grau

Figura 12 - União de mesmo grau

Caso 2 - Mesmas regras e constraints estruturais diferentes: Neste caso uma das visões tem mais constraints do que a outra.

Regras diferentes: Quando regras diferentes são usadas nos relacionamentos, os relacionamentos não são idênticos desde que se conduzam em semânticas diferentes. Em muitos casos, as classes de objetos que participam no relacionamento não serão idênticas. Durante a integração dos objetos, as subclasses adicionais são criadas.

6.1.4 Unindo relacionamentos de diferentes graus

Nós classificamos a integração dos relacionamentos de diferentes graus em três diferentes tipos como a estrutura mostrada na Figura 13. Estes três casos são discutidos abaixo:

Figura 13 - Classificação de relacionamentos de diferentes graus

Relacionamentos unificáveis: Dois relacionamentos são unificáveis quando um relacionamento pode ser derivado do outro. Isto se aplica aos casos onde um relacionamento em uma visão esteja representado por uma entidade (isto é, um relacionamento com grau zero) em uma outra visão. Considere duas visões V1 e V2 como mostrado na Figura 14.

Figura 14 - Relacionamentos Unificáveis

Relacionamentos unificáveis por condição: Em alguns casos da união de relacionamentos, dois relacionamentos poderiam ser unificados somente quando as informações semânticas adicionais forem especificadas. Considere dois relacionamentos definidos na visão V1 e V2 na Figura 15.

Figura 15 - Relacionamentos unificáveis por condição

A derivabilidade da visão V1 em V2 é dependente da entidade C. Sob certo aspecto, quando a semântica das duas visões são as mesmas, a visão V1 dever ser "derivável" de V2. Aqui, V2 é retida como visão global. Mas a interpretação semântica do relacionamento na visão V1 (como representado pela regra) não deve ser equivalente ao relacionamento na visão V2. Por exemplo, na Figura 16 temos que o relacionamento de Majors-In não é uma composição dos relacionamentos Attends e Offered-By. Então, todos os relacionamentos são retidos.

Figura 16- Relacionamentos retidos

É possível, em alguns casos, que um relacionamento de grau mais baixo seja derivável de um relacionamento de grau mais elevado.

Relacionamentos não-unificáveis: Esta categoria inclui relacionamentos de duas visões onde algumas ou todas as classes entidade envolvidas podem ser comuns a ambas as visões, contudo o grau de relacionamentos é dissimilar e a semântica não é exatamente a mesma.

Considere um exemplo simples, (Figura 17): Na visão V1, há dois relacionamentos R1 e R2. Eles descrevem independentemente o relacionamento de um negociante que fornece uma peça e o cliente que compra uma peça. A visão V2 descreve o relacionamento R3, que é uma associação ternária que descreve o fato que um cliente compra uma determinada parte de um determinado negociante.

Embora a mesma classe entidade esteja envolvida nas duas visões, o conjunto de instâncias de cada classe entidade envolvida nas visões V1 e V2 deve ser idêntico. Este é o exemplo clássico de uma armadilha da conexão [CODD70]. Agora o esquema integrado resultante conterá as classes entidade Dealer, Part, Customer e todos os relacionamentos R1, R2, R3.

Figura 17 - Relacionamentos não unificáveis

7 Conclusão

Este artigo procurou levantar os principais esforços existentes na área de tratamento de integração de esquemas de integração de banco de dados. Com o aumento da complexidade e da utilização de tais recursos de armazenamento de informação, o problema de integração se torna mais difícil e desafiador.

Embora de forma bastante condensada, foi demonstrado o estado da arte relacionado à questão de integração de esquemas. Foi feita uma breve análise das escolas de pensamento através do tempo, assim como as principais causas da diversidade de esquemas e as etapas adequadas para um bom andamento do processo da integração, para que se tenha um amadurecimento a respeito do assunto e se evite cometer os mesmos erros.

Além disso, foram apresentadas de forma geral diversas metodologias para a integração de esquemas de acordo com as etapas delineadas para o processo, com a indicação de quadros comparativos e o comportamento das entradas e saídas das referidas arquiteturas.

Levando-se em consideração características como a transparência dos processos de integração e a utilização de uma modelagem amplamente aceita no meio acadêmico e comercial, foi relatada com um pouco mais de profundidade a metodologia utilizada por ElMasri [1987]. Embora a metodologia tenha sido apresentada no contexto do modelo Entidade Categoria Relacionamento (E-C-R), acredita-se que os resultados possam ser obtidos através de outros modelos.

O conhecimento e a informação se tornaram um bem precioso para a organização. Sendo assim, é necessário gerenciá-lo bem para se ter um efetivo controle sobre este patrimônio peculiar. Este gerenciamento só é possível através de uma arquitetura coesa com o pleno domínio das bases de dados. O seu valor aumenta considerando que as informações estão cada vez mais integradas e passam a dar apoio a tomadas de decisão, a fim de obter vantagens competitivas para a organização.

Tendo em vista os aspectos apresentados, acredita-se que o aumento da necessidade de metodologias para integração de dados em conceitos e formas físicas será cada vez mais essencial em todos os segmentos de tratamento da informação.

Referências

1. ABITEBOUL, S. On views and XML. Le chesnay: N.R.I.A, Oct. 1999. 78153.

2. AL-FEDAGHI, S.; SCHEUERMANN, P. Mapping considerations in the design of schemas for the relational model. IIEE Trans.

Softw. Eng., v. 7, n.1, Jan. 1981.

3. BATINI, C.; LENZERINI, M. A methodology for data schema integration in the entity-relationship model. IEEE Transactions on Software Engineering, v. 10, n.6, p. 650-664, Nov.1984.

4. BATINI, C.; LENZERINI, M; NAVATHE, S. B. A comparative analysis of methodologies for database schema integration. ACM Computing Surveys, v. 18, n. 4, p. 323-364, Dec. 1986.

5. CHEN, P. P. The entity-relationship model: toward an unified view of data. ACM Trans. Database Syst., v. 1, n. 1 p. 9-36, Mar.1976.

6. ELMASRI, R; LARSON, J.; NAVATHE, S. B. Schema integration algorithms for federated databases and logical database design. [s.l.]: Honeywell Corporate Research Center, 1986. Relatório Técnico.

7. ELMASRI, R; NAVATHE, S. B. Fundamentals of database systems. 3.ed. [s.l.]: Benjamin/Cummings, 1994.

8. ELMASRI, R; NAVATHE, S. B. Object integration in database design. In: IEEE COMPDEC CONFERENCE, 1984, Anaheim. Proceedings... New York: IEEE, 1984. p. 426-433.

9. ELMASRI, R; WEELDRYER, J.; HEVNER, A. The category concept: an extension to the entity-relationship model. Data Knawl Eng., ano I, n.1, June 1985.

10. ELMASRI, R; WIEDERHOLD, G. Data model integration using the structural model. In: INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, 1979, Boston. Proceedings... New York: ACM, 1979.

11. HALL, G. Negotiation in database schema integration. Montreal: Faculty of Management, McGill University. Disponível em: <http://hsb.baylor.edu/ramsower/acis/papers/hall.htm>. Acesso em: 02 fev. 2002.

12. NAVATHE, S. B.; ELMASRI, R.; LARSON, J. Integrating user views in database design. IEEE Computer, v. 19, n. 1, p. 50-62, Jan. 1986.

13. NAVATHE, S. B; GADGIL, S. G. A methodology for view integration in logical data base design. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 8., 1982, Mexico City. Proceedings... Saratoga: VLDB Endowment, 1982.

14. NAVATHE, S. B.; SASHIDHART, T.; ELMASRI, R. Relationship merging in schema integration. In: INTERNATIONAL CONFERENCE ON VERY LARGE DATA BASES, 10., 1984, Singapura. Proceedings... Singapura, 1984.

15. PARENT, C; SPACCAPIETRA, S. Issues and approaches of database integration. Communications of the ACM, v. 41, n. 5, p.166-178, 1998.

16. SAMY GAMAL-ELDIN, M.; THOMAS, G; ELMASRI, R. Integrating relational databases with support for updates. In: INTERNATIONAL SYMPOSIUM ON DATABASES IN PARALLLEL AND DISTRIBUTED SYSTEM, 1988, Austin. Proceedings... Austin: IEEE, 1988. p. 202-209.

17. SPACCAPIETRA, S.; PARENT, C. Conflicts and correspondence assertions in interoperable databases. SIGMOD Record, v. 20, n.4, p. 49-54, Dec. 1991.

18. SPACCAPIETRA, S.; PARENT, C. View integration: a step forward in solving structural conflicts. IEEE Transactions on Knowledge and Data Engineering, v. 6, n.2, p. 258-274, Apr. 1994.

19. WIEDERHOLD, G.; ELMASRI, R. A structural model for database systems. Stanford: Stanford University, Computer Science Dept., 1979. Technical Report STANCS-79-722.