UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO UM PROCESSO DE CONVERSÃO ENTRE BANCO DE DADOS RELACIONAL E SERVIÇO DE OBJETO DE DADOS ADRIANO CRESTANI CAMPOS CUIABÁ MT 2008

2 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO UM PROCESSO DE CONVERSÃO ENTRE BANCO DE DADOS RELACIONAL E SERVIÇO DE OBJETO DE DADOS ADRIANO CRESTANI CAMPOS Orientadora: Profa. Esp. MARIA ELISA PATTARO Monografia apresentada ao Curso de Ciência da Computação da Universidade Federal de Mato Grosso, para obtenção do Título de Bacharel em Ciência da Computação. CUIABÁ MT 2008

3 UNIVERSIDADE FEDERAL DE MATO GROSSO COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CERTIFICADO DE APROVAÇÃO Título: Um processo de conversão entre banco de dados relacional e serviço de objeto de dados Autor: Adriano Crestani Campos Aprovada em / / Profa. Esp. MARIA ELISA PATTARO ICET/DCC (Orientadora) Prof. Dra. Patricia Cristiane de Souza ICET/DCC Prof. Dr. Josiel Maimone de Figueiredo ICET/DCC

4 SUMÁRIO LISTA DE TABELAS... 4 LISTA DE FIGURAS... 5 LISTA DE CÓDIGOS... 7 LISTA DE SIGLAS E ABREVIATURAS... 8 RESUMO INTRODUÇÃO APRESENTAÇÃO OBJETIVOS Objetivo Geral Objetivos Específicos JUSTIFICATIVA METODOLOGIA CRONOGRAMA PROPOSTO CRONOGRAMA EXECUTADO SERVIÇO DE OBJETO DE DADOS (SDO) OBJETOS DE DADOS PROPRIEDADES TIPOS Tipos Simples Tipos Complexos Tipos Abertos GRAFO DE DADOS RESUMO DE ALTERAÇÕES RELACIONANDO SDO COM OUTRAS TECNOLOGIAS BANCO DE DADOS RELACIONAL (BDR) CHAVE PRIMÁRIA CHAVE ESTRANGEIRA CONSULTA SERVIÇO DE ACESSO A DADOS (DAS) O PROCESSO DE CONVERSÃO ACESSANDO AS ESTRUTURAS DE DADOS RELACIONANDO OS COMPONENTES DAS ESTRUTURAS Tipos Complexos e Tabelas Tipos Simples e Colunas Relacionamentos Mapeamento de Nomes de Tipos, Tabelas, Propriedades e Colunas TIPOS DE DADOS PRIMITIVOS Tipos Dados Primitivos do SDO Tipos Dados Primitivos do BDR Conversão dos Tipos de Dados Primitivos PROCESSO DE CONVERSÃO DE UM BDR PARA UM GRAFO DE DADOS DO SDO 49

5 6.1 CONVERSÃO DE UMA TABELA SIMPLES Acessando os Dados em um BDR Definição dos Tipos Complexos Criação dos Objetos de Dados CONVERSÃO DE UMA JUNÇÃO DE TABELAS Descriminação das Colunas da Tabela Resultado Definição dos Tipos Complexos Criação dos Objetos de Dados Definição do Objeto Raiz do Grafo de Dados ATUALIZANDO AS ALTERAÇÕES DE UM GRAFO DE DADOS EM UM BDR OBTENÇÃO DOS OBJETOS DE DADOS ALTERADOS GERAÇÃO DE INSTRUÇÕES DE SQL PARA OS OBJETOS DE DADOS ALTERADOS Conversão de um Objeto de Dados Deletado para Tupla Conversão de um Objeto de Dados Criado para Tupla Conversão de um Objeto de Dados Modificado para Tupla ATUALIZAÇÃO DE UM BDR A PARTIR DAS INSTRUÇÕES DE SQL GERADAS Caso Caso Caso Caso Caso Caso Caso Caso Caso Caso Definição da Prioridade de Execução das Instruções de SQL CONVERSÃO DOS RELACIONAMENTOS ENTRE OBJETOS DE DADOS EM RELACIONAMENTOS ENTRE TUPLAS Geração das Instruções de SQL de Cada Objeto de Dados Alterado Geração de Instruções de SQL para Relacionamentos Relacionamentos Removidos Relacionamentos Criados Priorização das Instruções de Remoção de Tupla Definição da Prioridade de Execução das Instruções de SQL com Relacionamentos POSSÍVEIS PROBLEMAS CAUSADOS PELA ESTRUTURA DO BDR Remoção de Tuplas Referenciadas Por Tuplas Não Presentes no Grafo de Dados Alteração da Chave Primária de uma Tupla Ausência de Valores para Colunas Definidas como NOT NULL IMPLEMENTAÇÃO DO PROCESSO DE CONVERSÃO CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS

6 4 LISTA DE TABELAS Tabela 1 - Cronograma Proposto Tabela 2 - Cronograma Executado Tabela 3 - Comparativo entre SDO e outras tecnologias (adaptado de BEATTY et al, 2003) Tabela 4 - Relação dos tipos simples pré-definidos do SDO (adaptado de BEATTY et al, 2003) Tabela 5 - Relação dos tipos de dados primitivos definidos da linguagem SQL (adaptado de MICROSOFT, 1995) Tabela 6 - Tuplas da tabela COMPANIA armazenadas no BDR Tabela 7 - Tuplas resultantes da execução do Código Tabela 8 - Tuplas da tabela DEPARTAMENTO Tabela 9 - Tuplas da tabela EMPREGADO Tabela 10 Tabela resultante da junção efetuada pelo Código Tabela 11 - Tabela contendo apenas as colunas pertencentes à tabela DEPARTAMENTO contidas na Tabela Tabela 12 - Tabela contendo apenas as colunas pertencentes à tabela EMPREGADO contidas na Tabela

7 5 LISTA DE FIGURAS Figura 1 - Diagrama de classes de um grafo de dados do SDO (adaptado de MARECHAUX, 2005) Figura 2 - Como um grafo de dados armazena suas alterações (adaptado de MARECHAUX, 2005) Figura 3 - Situação de um DAS entre as estruturas de dados(adaptado de MARECHAUX, 2005) Figura 4 - Camadas do processo de conversão Figura 5 - Equivalência entre tipo complexo e tabela Figura 6 - Equivalência entre objeto de dados e tupla Figura 7 - Equivalência entre tipo simples e coluna Figura 8 - Equivalência entre um relacionamento 1xN em BDR e uma propriedade 1xN de tipo reference em SDO Figura 9 - Equivalência entre um relacionamento 1x1 em BDR e uma propriedade 1x1 de tipo reference em SDO Figura 10 - Estrutura do grafo do SDO gerada a partir da Tabela Figura 11 - Instâncias da estrutura do grafo da Figura Figura 12 - Estrutura do grafo de dados gerada a partir da Tabela 9 e Tabela Figura 13 - Estrutura do grafo de dados da Figura 12 contendo uma propriedade 1xN do tipo reference Figura 14 - Remoção de propriedades equivalentes às chaves estrangeiras Figura 15 - Objeto de dados equivalentes às tuplas contidas na Tabela 10 e Tabela Figura 16 - Exclusão dos objetos de dados repetidos Figura 17 - Grafo de dados contendo referências entre objetos de dados Figura 18 - Equivalência entre o grafo de dados convertido a partir de uma tabela retornada por um BDR Figura 19 - Grafo de dados contendo o tipo RAIZ (Tipos simples omitidos para melhor visualização) Figura 20 - Grafo de dados contendo um objeto raiz (Objetos de tipos simples omitidos para melhor visualização) Figura 21 - Estrutura de um grafo de dados para armazenar uma lista de empregados Figura 22 - Grafo de dados possui uma lista de empregados Figura 23 - Grafo de dados da Figura 22 alterado Figura 24 - Ilustração de como o processo de conversão irá visualizar o grafo de dados da Figura 22 após compará-lo com seu resumo de alterações Figura 25 Solução para o caso Figura 26 - Solução para o caso Figura 27 - Solução para o caso Figura 28 - Solução para o caso Figura 29 - Modificação entre valores de chaves primárias entre objetos do mesmo tipo em uma forma circular... 85

8 Figura 30 - Estrutura de um grafo de dados que possui departamentos com seus respectivos empregados Figura 31 - Uma instância da estrutura da Figura 30 no momento em que o resumo de alterações foi ativado Figura 32 - Grafo de dados da Figura 31 alterado Figura 33 - Ilustração de como o processo de conversão irá visualizar o grafo de dados da Figura 32 após compará-lo com seu resumo de alterações Figura 34 - Grafo de dados alterado comparado com as alterações armazenadas em seu resumo de alterações

9 7 LISTA DE CÓDIGOS Código 1 - Selecionando duas tuplas da tabela COMPANIA Código 2 - Instrução que efetua a junção entre as tabelas DEPARTMENTO e EMPREGADO Código 3 - Condição de SQL que indica qual tupla deve ser atualizada Código 4 - Condição em SQL que indica qual tupla da tabela EMPREGADO deve ser atualizada Código 5 - Estrutura de uma instrução de SQL que remove uma tupla que equivale à um objeto de dados Código 6 - Instrução de remoção da tupla equivalente ao objeto deletado no grafo de dados da Figura Código 7 - Estrutura de uma instrução de SQL que insere uma tupla equivalente a um objeto de dados Código 8 - Instrução de SQL que insere uma tupla equivalente ao objeto de dados criado no grafo de dados da Figura Código 9 - Estrutura de uma instrução de SQL que modifica uma tupla de acordo com as alterações efetuadas em seu objeto de dados equivalente Código 10 - Instrução de SQL que modifica a coluna da tupla equivalente ao objeto de dados modificado no grafo de dados da Figura Código 11 - Instrução de SQL que altera o valor da chave primária de uma tupla de N para M Código 12 - Instrução de SQL que altera o valor da chave primária de uma tupla de M para P Código 13 - Instrução de SQL que altera o valor da chave primária de uma tabela de N para M Código 14 - Instrução de SQL que altera o valor da chave primária de uma tabela de M para N Código 15 - Seqüência de instruções que irão refletir as modificações feitas no grafo de dados, ilustrado na Figura 23, em um BDR Código 16 - Código SQL altera o nome do departamento de ID igual a Código 17 - Estrutura de uma instrução de SQL que remove o relacionamento entre tuplas que equivalem a objetos de dados Código 18 - Instrução de SQL que reflete a remoção de um relacionamento entre um objeto de dados do tipo EMPREGADO e seu departamento 97 Código 19 - Instrução de SQL que reflete a remoção de um relacionamento entre um objeto de dados do tipo EMPREGADO e seu departamento 98 Código 20 - Estrutura de uma instrução de SQL que reflete a adição de um relacionamento entre dois objetos de dados em um BDR Código 21 - Instrução de SQL que cria um relacionamento entre duas tuplas100 Código 22 - Instrução de SQL que cria um relacionamento entre duas tuplas100 Código 23 - Seqüência de instruções que irão refletir as modificações feitas no grafo de dados, ilustrado na Figura 32, em um BDR

10 8 LISTA DE SIGLAS E ABREVIATURAS ANSI API ASF BDR COC DAS DMS ISO RDB SDO SOA SOAP SGBD American National Standards Institute - Instituto Nacional Americano de Padrões Aplication Program Interface - Interface Aplicação de Programas Apache Software Foundation Banco de Dados Relacional Optimistic Concurrency Control - Controle de Concorrência Otimista Data Access Service - Serviço de Acesso a Dados Data Mediator Service - Serviço Mediador de Dados International Standards Organization - Organização de Padrões Internacionais Relational Database - Banco de Dados Relacional Service Data Object - Serviço de Objeto de Dado Service Oriented Architecture - Serviço Orientado a Arquitetura Simple Object Access Protocol - Protocolo de Acesso Simples a Objetos Sistema Gerenciador de Banco de Dados SGBDR Sistema Gerenciador de Banco de Dados Relacional SQL UDDI WSDL XML Structured Query Language - Linguagem de Consulta Estruturada Universal Description, Discovery and Integration - Descrição, Descobrimento e Integração Web Services Description Language - Linguagem de Descrição de Web Services Extensible Modeling Language - Linguagem de Modelagem Estendida

11 9 RESUMO Aplicações utilizadas em ambientes orientados a serviços necessitam de uma estrutura de dados que possa ser utilizada independentemente da linguagem em que estas estão implementadas e do ambiente de execução. O Serviço de Objeto de Dados (SDO Service Data Object) vem para solucionar esse problema, definindo uma estrutura de dados em forma de grafo. Esta estrutura é armazenada em forma de texto no formato XML, possibilitando o acesso independente de como foi implementada a aplicação. Porém, a maioria dos dados utilizados por essas aplicações e armazenados no grafo de dados do SDO estão persistidos em bancos de dados relacional necessitando, assim, de algo que efetue a conversão entre estas duas estruturas de dados. Este trabalho descreve um processo de conversão entre essas duas estruturas, de forma que a estrutura semântica de cada estrutura de dados seja fiel à original após a conversão. Isto é feito utilizando como base processos de conversão já implementados e resultados extraídos durante a implementação deste processo. Como resultado, foi obtido um processo de conversão que consegue converter quase que totalmente a semântica de uma estrutura de dados para outra e, também, a implementação desse processo em um Serviço de Acesso a Dados para Banco de Dados Relacionais (RDB DAS Relacional Database Data Access Service) implementado na linguagem C++. Palavras-chave: Serviço de Objeto de Dados, Banco de Dados Relacional, Estrutura de Dados, Serviço Orientado a Arquitetura, Serviço.

12 10 1. INTRODUÇÃO 1.1 Apresentação Na última década surgiu no mercado uma infinidade de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDR), permitindo aos desenvolvedores escolherem qual melhor se adequa ao seu produto. Porém, a maioria dos SGBDRs possuem recursos próprios, que quando utilizados por uma aplicação, deixam essa fortemente relacionadas com ao SGBDR, consequentemente tornando difícil uma futura migração para um outro SGBDR (DEVMEDIA, 2006). Ou ainda, acarretando uma exaustiva implementação de aplicações que necessitem acessar diferentes bases de dados em diferentes SGBDRs. Uma das soluções existentes para esse problema é a utilização de um Serviço de Objeto de Dados (SDO - Service Data Object) que propõe o armazenamento de dados de forma homogênea e relacionados na estrutura de um grafo, onde eles poderão ser lidos e alterados. Com isso as aplicações não mais precisam conhecer como os dados estão armazenados ou como acessálos, deixando esta função apenas para um Serviço de Acesso a Dados (DAS Data Access Service). Um DAS tem a função de ler e atualizar dados persistidos em qualquer estrutura de dados e efetuar as conversões necessárias para armazená-los em um grafo homogêneo utilizando um SDO. Atualmente existe um projeto chamado Tuscany 1, que está incubado na Apache Software Foundation (ASF), que tem como um de seus subprojetos o desenvolvimento de um SDO. O Tuscany SDO se encontra em fase beta de desenvolvimento. 1

13 11 Este trabalho descreve as principais características de um SDO e um BDR, a fim de detalhar o processo de conversão entre as duas estruturas de dados, o qual poderá ser utilizado na implementação de um DAS para Banco de Dados Relacionais (RDB DAS Relational Database Data Access Service). 1.2 Objetivos Objetivo Geral O objetivo deste trabalho é descrever o processo de conversão da estrutura de dados de um SDO para a estrutura de dados de um banco de dados relacional e vice-versa Objetivos Específicos Descrever as características de um SDO. Descrever as características de um BDR. Descrever as características de um RDB DAS. Definir a equivalência entre a estrutura de dados de um SDO e de um BDR. Definir o processo de conversão de um BDR para um grafo de dados do SDO. Definir o processo de conversão de um grafo de dados do SDO para um BDR. Implementar o processo de conversão definido em um RDB DAS. Descrever os resultados da implementação do processo de conversão. 1.3 Justificativa Atualmente, eu sou commiter do projeto Tuscany, ou seja, eu possuo permissão para contribuir diretamente com o desenvolvimento das aplicações

14 12 desenvolvidas nesse projeto. Esse projeto desenvolve aplicações para ambientes orientados a serviços e uma dessas aplicações é um SDO. O projeto possui a implementação de um SDO em duas linguagens: em C++, que está em atualmente em fase final de desenvolvimento, e em Java, que já possui uma versão estável. Entretanto, as aplicações que irão utilizar um SDO necessitarão de algo que crie um grafo de dados, definindo seus tipos e suas ligações. No caso de aplicações que acessam dados persistidos em um Banco de Dados Relacional (BDR) utilizando um SDO, elas próprias deverão acessar esses dados e povoar o grafo do SDO. Desta forma dificulta sua codificação, uma vez que o desenvolvedor terá que definir no código toda a estrutura do grafo do SDO e populá-lo. Devido à complexidade de definir manualmente a estrutura do grafo do SDO e populá-lo, surge a necessidade da utilização de uma RDB DAS que acesse os dados persistidos, identifique seus tipos e relações, e com isso gere automaticamente um grafo de dados. Dessa forma, a aplicação que utilizar um RDB DAS em conjunto com um SDO, poderá se preocupar apenas com as partes intrínsecas da lógica do sistema em que ela faz parte não se preocupando como os dados estão sendo acessados. A implementação de um RDB DAS também é um dos subprojetos do projeto Tuscany. Entretanto, seu RDB DAS possuia apenas implementação na linguagem Java e com o desenvolvimento de um SDO na linguagem C++, surgiu a necessidade de também desenvolver um RDB DAS utilizando essa linguagem. Com essa necessidade, eu me propus a tomar a frente na implementação do RDB DAS na linguagem C++ e junto com esta implementação descrever o processo de conversão, o qual foi implementado nesse RDB DAS, neste trabalho.

15 13 Entretanto, o processo de conversão que um RDB DAS utiliza para converter os dados de um BDR para um grafo de dados do SDO e vice-versa, não é apenas utilizado por um RDB DAS, mas também por qualquer outra aplicação que necessite efetuar este tipo de conversão. Logo, o processo de conversão descrito aqui será independente do RDB DAS, podendo assim ser implementação em qualquer aplicação que necessite efetuar este tipo de conversão de dados. 1.4 Metodologia A metodologia empregada se inicia por um levantamento bibliográfico das principais características de um SDO e de um BDR, listando as principais semelhanças e diferenças entre as duas estruturas de dados. Esta pesquisa foi efetuada principalmente em livros e na internet. Pelo escasso material disponível sobre SDO e por esta ser uma tecnologia recente, muitas das informações foram obtidas através de listas de discussão, como a lista de desenvolvedores 2 e usuários 3 do projeto Tuscany. Após definidas as semelhanças e diferenças entre SDO e BDR, foi iniciada a descrição do processo de conversão, tendo como base implementações deste processo de conversão, como o processo de conversão implementado no RDB DAS, em Java, do projeto Tuscany. Uma vez descrito o processo de conversão entre as estruturas, este foi implementado no RDB DAS em C++ do projeto Tuscany. A experiência adquirida na implementação deste processo ajudou a definir e detalhar mais o processo de conversão descrito neste trabalho

16 Cronograma Proposto A seguir o cronograma proposto para ser executado durante o desenvolvimento do trabalho de conclusão de curso. Tabela 1 - Cronograma Proposto Meses/Semanas Etapas Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa 5 Etapa 6 Etapa 7 Etapa 8 Etapa 9 Etapa 1 Pesquisa bibliográfica Leitura de livros e pesquisa em artigos na Internet para fazer o levantamento sobre SDO e DAS disponíveis no mercado. Etapa 2 Detalhamento de um SDO Detalhar as principais características de um SDO. Etapa 3 Detalhamento de um BDR Detalhar as principais características de um SDO. Etapa 4 Detalhamento de um RDB DAS Detalhar as principais características de um DAS.

17 15 Etapa 5 Defesa do projeto Apresentar e defender o projeto do trabalho de conclusão de curso. Etapa 6 - Definição de um RDB DAS Definir as diretrizes de como será o a conversão de RDB para SDO. Etapa 7 Implementação de um RDB DAS Implementar um RDB DAS de acordo com as diretrizes definidas na etapa 5. Etapa 8 Descrição dos resultados Descrever os resultados obtidos durante a implementação de um RDB DAS. Etapa 9 Apresentação à banca avaliadora 1.6 Cronograma Executado O cronograma executado teve algumas alterações em relação ao cronograma proposto. A principal alteração foi a implementação do processo de conversão antes da descrição do mesmo. Também, a etapa 6, que define como deve ser a conversão entre as estruturas de dados em um RDB DAS, foi separada em 3 etapas diferentes: etapa 7, 8 e 9. Desta forma, ficando bem divido o processo de conversão que poderá ser implementado por qualquer RDB DAS. Além disso, a etapa de levantamento bibliográfico foi estendida ao longo de quase todo o trabalho, uma vez que algumas surgiram durante o desenvolvimento do mesmo. A seguir o cronograma executado durante o desenvolvimento deste trabalho de conclusão de curso.

18 16 Tabela 2 - Cronograma Executado Meses/Semanas Etapas Junho Julho Agosto Setembro Outubro Novembro Dezembro Janeiro Fevereiro Etapa 1 Etapa 2 Etapa 3 Etapa 4 Etapa 5 Etapa 6 Etapa 7 Etapa 8 Etapa 9 Etapa 10 Etapa 11 Etapa 1 Pesquisa bibliográfica Leitura de livros e pesquisa em artigos na Internet para fazer o levantamento sobre SDO e DAS disponíveis no mercado. Etapa 2 Detalhamento de um SDO Detalhar as principais características de um SDO. Etapa 3 Detalhamento de um BDR Detalhar as principais características de um SDO. Etapa 4 Detalhamento de um RDB DAS Detalhar as principais características de um DAS.

19 17 Etapa 5 Defesa do projeto Apresentar e defender o projeto do trabalho de conclusão de curso. Etapa 6 Implementação do processo de conversão Implementar o processo de conversão em um RDB DAS. Etapa 7 - Definição da equivalência entre BDR e SDO Definir a equivalência entre a estrutura de dados de um SDO e de um BDR. Etapa 8 - Definição da conversão de um BDR para um SDO Definir o processo de conversão de um BDR para um grafo de dados do SDO. Etapa 9 - Definição da conversão de um SDO para um BDR Definir o processo de conversão de um BDR para um grafo de dados do SDO. Etapa 10 Descrição dos resultados da implementação Descrever os resultados obtidos durante a implementação do processo de conversão. Etapa 11 Apresentação à banca avaliadora

20 18 2. SERVIÇO DE OBJETO DE DADOS (SDO) Antes de começar o processo de desenvolvimento de uma aplicação é necessário escolher quais tecnologias de persitência de dados, comunição, linguagem de programação e etc serão utilizadas por esta aplicação. A escolha de cada uma dessas tecnologias depende da necessidade da aplicação e se a tecnologia atende essas necessidades de forma satisfatória. Entretanto, as tecnologias escolhidas nem sempre são compatíveis entre si. Desta forma, as decisões sobre a lógica de negócio da aplicação fica fortemente ligada a forma em que essa é implementada. Para solucionar este problema, surgiu a Arquitetura Orientada a Serviço (SOA Service Oriented Architecture) que possibilita separar a implementação de uma tecnologia do tipo de serviço que ela disponibiliza. SOA é uma maneira de se organizar um software, baseada na exposição de unidades de software customizadas chamadas serviços (MARGOLIS et al, 2007). Serviços são disponibilizados através de um interface, a qual é independente da linguagem de implementação do serviço e de seu ambiente de execução. Logo, é possível tomar a decisão sobre a arquitetura de uma aplicação, ou seja, como as tecnologias se relacionam nessa aplicação, sem que seja necesssário conhecer como cada uma é implementada e sem ter problema de compatibilidade entre essas tecnologias. Além disso, a arquitetura da aplicação fica desacoplada da forma em que essa é implementada, tornando-a flexível e possibilitando uma rápida adaptação de sua arquitetura, atendendo rapidamente a novas necessidades do usuário. Como a implementação de um serviço é independente da implementação dos outros serviços, cada serviço pode estar executando em qualquer lugar do globo, necessitando assim, apenas definir um protocolo de comunicação entre os serviços, como, por exemplo, Web Services.

21 19 Aplicações implementadas utilizando o conceito de SOA necessitam transferir entre seus serviços. Entretanto esses dados provêm de diversas fontes de dados diferentes, necessitando assim um modelo de programação que permita manipular dados heterogêneos de forma consistente e uniforme (RESENDE, 2007). Com isso surgiu o SDO, que define um modelo de programação independente e unificado de manipulação de dados através de múltiplos tipos de fontes de dados (RESENDE, 2007). "SDO especifica uma forma padronizada de acessar e modificar dados de negócio independentemente de como estes dados estão armazenados fisicamente" (Clarke, 2006, p. 2, tradução nossa). SDO é um serviço que pretende unificar e simplificar a forma em que os dados são acessados por uma aplicação. Usando SDO, os serviços poderão uniformemente acessar e manipular dados de diferentes fontes de dados, incluindo bancos de dados relacional, bases de dados em XML, Web services, entre outras, sem precisar conhecer como estão armazenados. De acordo com Clarke (2006), o SDO suporta processamento desconectado, ou seja, ele consegue armazenar as mudanças efetuadas em seu grafo de dados, mesmo que o mesmo seja transportado através de vários serviços. Com isso, os dados podem ser carregados em um grafo a partir de uma fonte de dados e transportados através de vários serviços, e quando retornado a fonte de dados, será possível atualizá-la de acordo com as alterações efetuadas no grafo de dados. 2.1 Objetos de Dados Objetos de dados são as instâncias que formam o grafo de dados. Eles são gerados a partir de uma fonte de dados e relacionados entre si, formando um grafo de dados, que representa a semântica em que os dados estão relacionados em sua fonte. Uma vez gerado o grafo de dados, os clientes do

22 20 SDO não precisam mais conhecer como estes estão persistidos e nem como acessá-los em sua fonte, deixando esta tarefa para um DAS. O SDO disponibiliza duas formas de acessar e modificar os dados em um objeto de dados: estática e dinâmica. Acesso estático fornece ao programador uma maneira fácil de acessar dados em um objeto de dados, apenas definindo uma interface em tempo de compilação, que deve possuir os getters e setters para acessar e modificar cada propriedade que ele possui. Entretanto, acesso estático impede a manipulação de um objeto de dados quando o programador não conhece previamente suas propriedades, ou quando a fonte de dados de onde o objeto de dados provém for semi-estruturada, pois impossibilita a definição de uma interface fixa para acessá-lo. Porém, o acesso dinâmico é essencial, permitindo acesso de forma independente da linguagem em que a aplicação é implementada, além de permitir acesso a objetos de dados totalmente desconhecidos utilizando a introspecção de dados (BEATTY et al, 2003). 2.2 Propriedades Cada objeto de dados está relacionado com um outro objeto de dados através de uma propriedade. A propriedade de um objeto de dados define como e com qual objeto de dados ele se relaciona, ou seja, seu relacionamento. Propriedades podem ser classificadas como: contaiment ou reference. Uma propriedade contaiment define um relacionamento de propriedade que um objeto de dados exerce em outro. Por exemplo, se um objeto de dados carro possuir uma propriedade contaiment que o relacione com um objeto de dados motor, o objeto de dados que representa o motor somente existirá se o objeto de dados que representa o carro também existir, e será automaticamente apagado caso o objeto de dados carro seja apagado.

23 21 Por outro lado, uma propriedade reference define um relacionamento de referência entre dois objetos de dados. No caso do exemplo acima, se a propriedade que relaciona o objeto de dados carro e motor fosse do tipo reference, o objeto de dados motor poderia existir independentemente da existência de um objeto de dados carro, e caso o objeto de dados carro fosse apagado, apenas a referência entre carro e motor será removida. O SDO garante a integridade dos relacionamentos, não permitindo um objeto de dados referenciar outro objeto de dados que não existe mais. Uma propriedade define também cardinalidade do relacionamento entre objetos de dados, que pode ser 1x1 ou 1xN. O SDO garante esta cardinalidade, e não permite que um objeto de dados seja referenciado pela propriedade de mais de um objeto de dados. Propriedades inicialmente não são definidas, possuem um estado nulo, representando que a propriedade não está relacionando o objeto que a possui a nenhum outro objeto de dados. Para representar o mesmo, após uma propriedade ter sido definida com algum objeto, uma propriedade pode ser definida como nula, removendo o relacionamento, que esta representa, com qualquer outro objeto. 2.3 Tipos Os tipos formam a estrutura em que o SDO armazena seus dados. Eles possuem todas as definições sobre o dado que a sua instância, o objeto de dados, carrega, além de todas as propriedades que este possui. A partir de um objeto de dados é possível acessar seu tipo, permitindo introspecção no mesmo. De acordo com Gadotti et al (2002), introspecção é a capacidade de um sistema computacional de examinar sua própria estrutura, estado e representação. Logo, o SDO possibilita, através de introspecção, qualquer aplicação conhecer como os dados estão estruturados em seu grafo de dados.

24 22 "Um tipo é a forma de descrever um objeto de dados, similar a uma classe em Java" (Robbins et al, 2006, tradução nossa). Um tipo pode ser simples ou complexo. Um tipo complexo é análogo a uma classe em orientação a objetos, um ComplexType ou SimpleType em XML, ou uma Struct em C (BEATTY et al, 2003). E um tipo simples é análogo a um tipo primitivo em qualquer linguagem de programação Tipos Simples Objetos de dados de tipo simples apenas armazenam um valor primitivo. Tipos simples são similares à dados primitivos em Java e representam elementos, tais como um inteiro, um byte, um boleano, entre outros (Robbins et al, 2006, tradução nossa). Alguns dos tipos primitivos já fornecidos pelo SDO são: Boleano; Byte; Caractere com 2 bytes dando suporte a codificação ASCII, UNICODE e qualquer outra que possa ser armazenada em até 2 bytes; Cadeia de bytes; Cadeia de caracteres; Ponto flutuante simples e de dupla precisão; Inteiro de 2, 4 e 8 bytes; UserData, o qual dá suporte a utilização de qualquer tipo primitivo não previsto na especificação do SDO;

25 Tipos Complexos Um objeto de dado de tipo complexo apenas possui propriedades, que o relaciona com outros objetos de dados, sejam eles de tipo complexo ou simples. Tipos complexos suportam herança, que permite um tipo herdar as características e propriedades de outro tipo complexo. Também existem tipos complexos abstratos, que não podem ser instanciados, apenas herdados Tipos Abertos SDO fornece suporte à estrutura de dados semi-estruturada através dos tipos abertos. Inicialmente, todos tipos criados em um grafo de dados são estruturados, ou seja, obedecem a uma estrutura previamente definida. Com isso, uma instância de um tipo comum não irá permitir a definição de um relacionamento entre dois objetos de dados, caso esta não tenha sido previamente definida entre eles. Porém, uma instância de um tipo aberto aceita o relacionamento entre dois objetos de dados mesmo se não existir nenhum relacionamento previamente definido. Com tipos abertos, o SDO consegue dar suporte a fontes de dados semiestruturadas, como arquivos XML. 2.4 Grafo de Dados Um grafo é um par (V,A) em que V é um conjunto arbitrário e A é um subconjunto. Os elementos de V são chamados vértices e os de A são chamados arestas (FEOFILOFF et al, 2005).

26 24 Um grafo em SDO possui toda a estrutura de dados em forma de um grafo bidirecional, onde seus vértices são os objetos de dados e suas arestas representam os relacionamentos entre os dados, formando assim, um grafo de dados. Além disso, armazena um grafo de metadados, que é definido na criação do grafo de dados, o qual os vértices são os tipos dos dados e as arestas são as propriedades, as quais determinam como um determinado tipo se relaciona com outro. Este relacionamento de tipos e propriedades pode ser notado no diagrama de classes ilustrado na Figura 1. Um grafo de dados possui também um resumo de alterações, ou seja, um resumo de todas as alterações efetuadas no grafo de dados. Figura 1 - Diagrama de classes de um grafo de dados do SDO (adaptado de MARECHAUX, 2005) Um grafo de dados possui apenas uma raiz, a qual deve ser qualquer objeto de dados, que a partir dele possa ser acessado todos os outros objetos de dados do grafo, utilizando apenas propriedades do tipo contaiment. SDO suporta a serialização de seus grafos de dados em XML, possibilitando a fácil integração entre SDOs implementados em diferentes linguagens.

27 Resumo de Alterações Cada grafo de dados possui um resumo de alterações, que é um resumo de todas as alterações efetuadas nos objetos contidos no grafo de dados, como ilustrado na Figura 2. O monitoramento efetuado pelo resumo de alterações no grafo pode ser ativado ou não, de acordo com a necessidade do programador. Quando um grafo de dados é criado, seu resumo de alterações não monitora as alterações efetuadas, ele deve ser ativado, para que assim comece o monitoramento. Caso este seja desativado, todas as informações sobre as alterações ocorridas no grafo de dados serão perdidas. O resumo de alterações não armazena todas as alterações efetuadas em determinado dado, e sim, apenas a alteração mais antiga e o valor que este possui antes de ser alterado. Figura 2 - Como um grafo de dados armazena suas alterações (adaptado de MARECHAUX, 2005) Em SDO, o resumo de alterações é representado pelo tipo complexo especial chamado ChangeSummary. Ele deve ser adicionado a um tipo complexo do grafo através de uma propriedade 1x1 do tipo containment. Uma vez ativado,

28 26 ele armazenará todas as alterações efetuadas no objeto de dados em que está contido, e também as alterações de todos os objetos contidos nesse objeto, exceto a própria instância do ChangeSummary. A API do SDO especifica funções que permitem o acesso aos objetos de dados modificados no grafo e a todos os valores antigos de suas propriedades modificadas, os quais estão armazenados no resumo de alterações, desde que o mesmo esteja ativado. 2.6 Relacionando SDO com Outras Tecnologias Além do SDO, existem outras tecnologias que pretendem unificar o acesso a dados. Na Tabela 3 pode ser observada a relação entre estas tecnologias e o SDO, e concluir que o SDO hoje em dia é o que mais fornece vantagens. Tabela 3 - Comparativo entre SDO e outras tecnologias (adaptado de BEATTY et al, 2003) Tecnologia Modelo Acesso a Dados Fonte de Dados Introspecção de Dados Linguagem de Requisição JDBC Conectado Dinâmico Relacional Sim SQL RowSet JDBC Desconectado Dinâmico Relacional Sim SQL CachedRow Set Entity EJB Conectado Estático Relacional Sim EJBQL JDO Conectado Estático Relacional, Sim JDOQL Objeto JCA Desconectado Dinâmico Record Não Definido Não Definido DOM and Não Dinâmico XML Sim Xpath e Xquery SAX Disponível JAXB Não Estático XML Sim Não Disponível Disponível JAX-RPC Não Estático XML Sim Não Disponível Disponível SDO Desconectado Estático e Dinâmico Qualquer Sim Qualquer Na tabela 3 pode ser notada a vantagem do SDO com outras tecnologias, pois: Possui um modelo desconectado, ou seja, sua estrutura de dados não precisa se manter conectada a um sistema gerenciador de dados.

29 27 Permite que seja efetuado acesso aos seus dados de forma dinâmica, possibilitando qualquer aplicação que não conheça a estrutura do grafo de dados acessar dinamicamente os seus dados. E também permite que esses dados sejam acessados estaticamente, através de interfaces definidas pelas aplicações, possibilitando essas aplicações padronizar a forma em que desejam trabalhar com os dados contidos no grafo de dados. A especifição do SDO define que seu grafo de dados é independente de fonte de dados, permitindo a utilização de dados vindos de qualquer fonte, desde que os mesmos sofram as conversões necessárias. Como a maioria das outras tecnologias, o SDO também permite a introspecção na sua estrutura de dados. A especifição do SDO não define uma linguagem de requisição dos dados, apenas define instruções em sua API de acesso que permitem uma aplicação navegar por todo o seu grafo de dados. Possibilitando assim que as implementações do SDO especifiquem alguma liguagem de requisição de dados. Por exemplo, a implementação do SDO do projeto Tuscany permite que a requisição dos dados no grafo de dados seja feita utilizando a linguagem XPath. Logo, a principal vantagem do SDO em relação a outras tecnologias, é que ele não possui nenhuma fonte de dados específica, suportando fonte de dados heterogêneas e tornando possível o acesso a inúmeras fontes de dados distintas de forma transparente.

30 28 3. BANCO DE DADOS RELACIONAL (BDR) Dados dificilmente são armazenados de forma independente um do outro, mas co-relacionados, a fim de formar uma estrutura de dados lógica, a qual representa como determinado dado se relaciona com outro. Esta estrutura é armazenada em um banco de dados, o qual é uma coleção de dados estruturados (Din, 1994). Um banco de dados relacional define maneiras de como armazenar, manipular e recuperar dados que estão relacionados entre si. Para isso se faz necessário definir um modelo que representa como os dados devem ser relacionados. Este modelo é chamado de modelo relacional. Em 1970, E. F. Codd desenvolveu o modelo relacional. Entretanto, naquela época imaginava-se ser uma idéia impossível de ser colocar em prática utilizando os recursos de hardware disponíveis. Porém, qualquer computador pessoal dos dias atuais consegue por em prática o modelo de Codd sem qualquer dificuldade (GILFILLAN, 2002). O modelo relacional de Codd define uma estrutura de dados onde os dados são simplesmente armazenados em tabelas bidimensionais que representam entidades do mundo real (LITWIN, 1994). Cada entidade possui atributos diferentes, onde estes são representados como sendo as colunas da tabela. Um atributo de uma entidade pode ser apenas um dado ou uma outra entidade, no segundo caso é definido pelo relacionamento entre duas entidades. Cada linha de uma determinada tabela são as instâncias desta tabela, que são chamadas de tuplas. Um conjunto de dados armazenados e estruturados de acordo com um determinado modelo forma um banco de dados. Porém, é necessário um software que permita o acesso, manipulação e recuperação destes dados. Este software é chamado de Sistema Gerenciador de Banco de Dados (SGBD). Um

31 29 SGBD que controla um banco de dados relacional recebe o nome de SGBD Relacional (SGBDR). 3.1 Chave Primária De acordo com Battisti (2004), o conceito de chave primária é fundamental para o correto entendimento de como funciona um banco de dados baseado no modelo relacional. Pois, é baseado na chave primária que o SGDBR garante a unicidade de uma tupla em sua tabela. Quando o modelo de uma tabela é definido deve-se também definir sua chave primária. A chave primária é formada por colunas, a qual pode ser constituída por apenas uma coluna, caracterizando uma chave primária simples, ou por várias colunas, chave composta. Simples ou composta, o valor da chave de determinada tupla deve ser único entre todas as tuplas da mesma tabela, garantindo assim a identidade da tupla na tabela (BATTISTI, 2004). 3.2 Chave Estrangeira Chaves estrangeiras são cópias das chaves primárias dentro das tabelas filhas para formar a ligação oposta em um relacionamento entre tabelas, desta forma estabelecendo uma relação de um banco de dados relacional. Uma chave estrangeira define a referência para cada tupla em uma tabela filha, referenciando de volta a chave primária na tabela pai (Powell, 2005, p. 60, tradução nossa). O relacionamento de uma tabela com outra, ocorre através de uma chave estrangeira, que é o conjunto de uma ou mais colunas de uma tabela que definirá seu relacionamento com outra. Esse conjunto de colunas deve representar um valor possa identificar uma única tupla, onde essa é a tupla que é referenciada pela chave estrangeira. Em uma relação entre duas tabelas, uma tabela possui uma chave primária e a outra uma chave estrangeira. A chave primária identifica unicamente cada tupla na primeira tabela. Em outras palavras, somente poderá existir uma tupla na primeira tabela com o mesmo valor de chave primária. A chave estrangeira é colocada na segunda

32 30 tabela do relacionamento, de forma que a chave estrangeira contenha uma cópia do valor da chave primária da tupla na tabela relacionada (Powell, 2005, p. 63, tradução nossa). A base para se manter a integridade de um banco de dados relacional depende unicamente das chaves primárias e estrangeiras. Uma chave primária nunca poderá conter um valor nulo ou igual a de outra tupla da mesma tabela. Uma chave estrangeira poderá ser nula ou possuir o valor da chave primária da tupla de outra tabela. Seguindo estas regras, o SGDBR consegue manter a integridade de um banco de dados relacional. 3.3 Consulta Após os primeiros SGBDRs surgirem, várias linguagens foram criadas a fim de permitirem os programadores acessar e manipular os dados armazenados no banco de dados. Entre estas linguagens, a que mais se destacou foi a Structured Query Language (SQL). A linguagem SQL é uma linguagem com um propósito especial desenvolvida para a criação e manutenção de dados de uma base de dados relacional. Embora os desenvolvedores de sistemas para manutenção de bases relacionais tenham suas próprias definições de SQL, um padrão ISO/ANSI define e controla o que é SQL (TAYLOR, 2003, p. 45). De acordo com Din (1994), SQL é apenas um instrumento que é usado como meio de informar ao SGBDR o que você quer fazer. Instruções de SQL são comandos que são usados para requisitar, atualizar, remover e inserir dados em uma base de dados. SQL é uma linguagem não-procedural, ou seja, não é necessário explicitar onde procurar pelos dados no banco de dados, pois o SGBDR irá procurar onde estes dados estão baseando nas informações contidas na instrução de SQL. A linguagem SQL é atualmente suportada pela maioria dos SGBDRs do mercados, como Oracle, Microsoft SQL Server, Sybase DB/2, MySQL, PostgreSQL, entre outros. Por sua grande utilização, a linguagem SQL ganhou

33 31 certificação ISO e ANSI, padronizando assim a estrutura de seus comandos e facilitando a utilização de um comando SQL por vários SGBDRs diferentes.

34 32 4. SERVIÇO DE ACESSO A DADOS (DAS) Segundo Marechaux (2005), um Serviço de Acesso a Dados (DAS - Data Access Service) ou Serviço Mediador de Dados (DMS - Data Mediator Service) é um serviço que fornece métodos para popular um grafo de dados de um SDO a partir de uma determinada fonte de dados. Este serviço também efetua o processo inverso a atualização dos dados alterados no grafo de volta na fonte de dados. Serviços de Acesso a Dados são responsáveis por aplicar as mudanças de um grafo de dados em uma fonte de dados (RESENDE, 2007, tradução nossa). Por causa da variedade de tecnologias diferentes que um SDO pode utilizar como fonte de dados, será necessário a implementação de um DAS para cada fonte diferente, como ilustrado na Figura 3. O DAS deverá garantir a semântica dos dados no processo de conversão do grafo de dados para a fonte de dados e vice-versa, de acordo com a estrutura da tecnologia em que os dados estão armazenados. Basicamente, o processo de acesso a uma fonte de dados utilizando o DAS ocorre da seguinte forma: 1- O usuário informa ao DAS os dados que deseja. 2- O DAS requere dados da fonte de dados baseando na informação passada pelo usuário. 3- Com os dados retornados pela fonte de dados, o DAS gera o grafo do SDO e o retorna para o cliente. 4- O usuário faz as alterações necessárias no grafo de dados e repassa para o DAS. 5- O DAS verifica quais foram as alterações realizadas no grafo de dados, e as atualiza na fonte de dados.

35 33 Figura 3 - Situação de um DAS entre as estruturas de dados(adaptado de MARECHAUX, 2005) Como o grafo de dados do SDO possui um modelo desconectado da fonte de dados, não é possível realizar um controle de concorrência na fonte de dados entre o período de tempo que o DAS gerou o grafo de dados a partir da fonte de dados e a atualização deste grafo nesta mesma fonte. Controle de concorrência é o gerenciamento da contenção para fontes de dados. Um esquema de controle de concorrência é considerado otimista quando os dados são bloqueados e desbloqueados por um curto período de tempo no final da transação. O objetivo de um controle de concorrência otimista é minimizar o tempo o qual a fonte dos dados estaria indisponível para uso por outras transações (IBM, 2005, tradução nossa). Para resolver este problema de concorrência, o DAS utiliza um Controle de Concorrência Otimista (OCC Optimistic Concurrency Control), onde toda vez que o DAS for atualizar os dados na fonte de dados, ele checa se o dado na fonte está diferente de quando o grafo foi gerado. Se o dado possuir o mesmo valor que ele possuía antes do grafo de dados ser gerado, ele atualiza o dados. Caso contrário, ele gera um aviso de concorrência e não atualiza o dados.

36 34 5. O PROCESSO DE CONVERSÃO O processo de conversão entre os dados de um BDR e um grafo de dados do SDO caracteriza-se pelo processo de converter os dados retornados por uma requisição do usuário feita ao SGBDR para um grafo de dados do SDO e atualizar estes dados no BDR após eles terem sido modificados no grafo de dados pelo usuário. Para que este processo ocorra, é necessário definir as equivalências e diferenças que as duas estruturas possuem, além de definir como estas estruturas serão acessadas pelo processo de conversão. 5.1 Acessando as Estruturas de Dados Para que seja acessado os dados armazenados em um grafo de dados do SDO, é utilizada a API do SDO. Esta API define as interfaces necessárias em C, C++, Java e COBOL para manipular e acessar os dados, os quais estão armazenados em formato XML, de acordo com a especificação do SDO. Esta especificação, que se encontra na versão 2.1, foi elaborada em conjunto pela IBM, BEA, Rogue Wave Software e Sybase, e é disponibilizada pela Open SOA Collaboration 4. Na outra ponta, para que possam ser acessados os dados nos BDRs, independentemente do SGBDR utilizado, é importante que seja utilizada uma API largamente aceita pela maioria dos SGBDRs do mercado, possibilitando desta forma, fornecer suporte de acesso a maior quantidade de SGBDRs possíveis. A API ODBC possibilita que programas acessem qualquer SGBDR, independentemente da linguagem de programação e ambiente de execução, utilizando a linguagem de SQL. A maioria dos SBGDRs do mercado que 4

37 35 fornecem uma API de acesso a dados possuem implementações da API ODBC. Por esses motivos, essa API se torna uma grande candidata a ser utilizada pelo processo de conversão entre SDO e um BDR, uma vez que a mesma fornece a interface necessária para que seja efetuada leitura e atualização dos dados armazenados em um BDR. Figura 4 - Camadas do processo de conversão Como pode ser observado na Figura 4, utilizando APIs de acesso a dados, como a API do SDO e ODBC, tanto para acessar um grafo do SDO quanto para acessar um BDR, é possível que a aplicação que irá efetuar a conversão, representada pela camada de conversão, efetue a conversão de qualquer BDR para um grafo de SDO e vice-versa. Desde que, o SGBDR implemente a API do ODBC e também que os dados no formato XML, que correspondem ao

38 36 grafo de dados do SDO, estejam formatados de acordo com a especificação do SDO e a implementação da API do SDO também siga as regras especificadas para essa API. Acessando os dados desta forma, evita que seja implementada uma camada de conversão específica para cada SGBDR ou SDO diferente e possibilita o acesso a dados de qualquer fonte de forma uniforme e transparente. 5.2 Relacionando os Componentes das Estruturas De acordo com Malveau et al (2000), uma entidade é qualquer coisa de interesse, seja ela concreta ou abstrata. Elas são representadas de formas diferentes em diferentes estruturas, entretanto independentemente da estrutura, elas devem sempre ser representadas de forma que não seja perdido o aspecto semântico da entidade. Componentes de uma estrutura são utilizados para definir uma entidade, de forma a manter o sentido semântico que esta entidade possui. Os componentes de um BDR são as tabelas, colunas, chaves primárias, chaves estrangeiras, gatilhos, etc. Os componentes de um grafo de dados do SDO são os tipos e as propriedades. Por exemplo, a entidade pessoa pode ser representada em um grafo de dados do SDO como um tipo complexo ou em um BDR como uma tabela. A entidade nome, que representa o nome desta pessoa, pode ser representada por uma propriedade deste tipo complexo ou uma coluna desta tabela. Nesta sessão será descrito como os componentes que formam a estrutura de um BDR podem ser convertidos para os componentes que formam a estrutura de um grafo de dados do SDO e vice-versa, de forma que não seja perdida a semântica que cada componente representa em sua estrutura.

39 Tipos Complexos e Tabelas Uma entidade complexa caracteriza-se por ser formada por outras entidades. Um objeto complexo contem um número arbitrário de campos, cada um armazenando valores de dados atômicos ou referências para outros objetos [...] (Lange et al, 1999, p. 14, tradução nossa). Um tipo complexo em SDO é o componente que define uma entidade complexa em um grafo de dados do SDO, ou seja, uma entidade que é formada por outras entidades. Ele possui um nome que o identifica em sua estrutura. O mesmo ocorre em um BDR, porém este componente é conhecido como tabela, a qual define uma entidade complexa, ou seja, uma entidade que é formada por outras entidades. A tabela também é identificada por um nome em sua estrutura. De acordo com Beatty et al (2006), uma classe pode ser representada por um tipo complexo em SDO. E segundo Powell (2006), uma classe equivale a uma tabela em um BDR. Logo, um tipo complexo em grafo de dados do SDO equivale a uma tabela em um BDR. Figura 5 - Equivalência entre tipo complexo e tabela Logo, uma vez definida a equivalência entre tipos complexos e tabelas, podemos concluir que um objeto de dados, que é uma instância de um tipo complexo, equivale a uma tupla, que é a instância de uma tabela. Figura 6 - Equivalência entre objeto de dados e tupla