Uma Abordagem para Armazenamento de Dados Semi-Estruturados em Bancos de Dados Relacionais

Texto

(1)Uma Abordagem para Armazenamento de Dados Semi-Estruturados em Bancos de Dados Relacionais Karine V. Magalhães. Alberto H. F. Laender. Altigran S. da Silva. Departamento de Ciência da Computaça˜ o Universidade Federal de Minas Gerais 31270-901 Belo Horizonte MG versieux,laender,alti @dcc.ufmg.br Abstract This paper presents an approach to storing semistructured data in relational databases. We focus on semistructured data as extracted from Web pages by a tool called DEByE (Data Extraction By Example), and organized according to its data model, the DEByE Object Model (DEByE-OM). The approach presented here consists in representing the structure of objects extracted by DEByE by a relational schema and populating the corresponding database accordinly. We also show how to retrieve such data by automatically transforming high-level query specifications (query patterns) into SQL queries that are executed over the relational database. Results of experiments carried out to evaluate our approach are also described.. 1 Introduça˜ o A Internet, em especial a World Wide Web (Web), tornou-se um vasto repositório de dados. Entretanto, os dados dispon´ıveis na Web são, em geral, dif´ıceis de serem efetivamente utilizados pela maioria dos usuários da Internet. A dificuldade em se utilizar esses dados deve-se ao fato de que eles não podem ser adequadamente consultados e manipulados através de técnicas tradicionais de bancos de dados. Essa limitaça˜ o deve-se a` maneira como os dados da Web estão estruturados. Ao contrário de como ocorre em bancos de dados tradicionais, cada fonte de dados apresenta suas próprias caracter´ısticas em termos de meios de acesso e de estruturaça˜ o dos dados nela contidos. A estrutura desses dados e´ irregular e apresenta-se implicitamente definida, podendo, em geral, ser facilmente reconhecida pelo usuário. Como exemplo, podemos citar dados contidos em páginas de sites de livrarias eletrônicas, referências bibliográficas, catálogos eletrônicos, sites de previsão de tempo e outros. Dados deste tipo são denominados semi-estruturados [1]. Uma poss´ıvel soluça˜ o para o problema de manipulaça˜ o de dados semi-estruturados e´ extra´ı-los de páginas da Web e armazená-los em um banco de dados relacional para posterior manipulaça˜ o. Neste sentido, diversas abordagens têm sido propostas para extraça˜ o e estruturaça˜ o dos dados encontrados na Web. Entre elas, podemos citar linguagens para geraça˜ o de wrappers [3, 8, 15], processamento de linguagem natural [7, 13], geraça˜ o de wrappers baseados em induça˜ o [4, 16, 19, 26], ontologia [10] e modelagem de documentos [2, 28], além daquelas que exploram a estrutura dos documentos HTML para geraça˜ o de regras de extraça˜ o [22, 30]..

(2) A abordagem DEByE (Data Extraction By Example) [20, 28], para extraça˜ o de dados semiestruturados da Web, difere-se de outras abordagens devido ao fato de o processo de extraça˜ o ser totalmente guiado por exemplos fornecidos pelo usuário. O usuário especifica alguns objetos de exemplo derivados de uma página de amostra e esses objetos são usados para extrair automaticamente novos objetos de páginas que apresentam estrutura similar. A ferramenta DEByE [20, 21, 28] foi desenvolvida para suportar o processo de especificaça˜ o de exemplos e a extraça˜ o dos dados. A interface gráfica da DEByE auxilia o usuário a descrever a estrutura impl´ıcita dos objetos. A partir dos exemplos fornecidos pelo usuário, são gerados padrões de extraça˜ o que alimentam o processo de extraça˜ o. O resultado de um processo de extraça˜ o da ferramenta DEByE e´ um arquivo-texto, contendo os objetos extra´ıdos de páginas da Web, denominado DTOR (DEByE Textual Object Repository). Em um DTOR, os objetos estão organizados segundo um formato baseado na notaça˜ o XML [33] chamado DTORF (DEByE Textual Object Repository Format). O DTORF constitui uma implementaça˜ o XML do modelo de objetos DEByE-OM (DEByE Object Model) [20], modelo adotado pela abordagem DEByE para representaça˜ o de dados semi-estruturados. A principal vantagem de se ter uma implementaça˜ o XML do modelo DEByE-OM e´ que os objetos representados textualmente podem ser processados através de aplicaço˜ es e bibliotecaspadrão existentes para diversas plataformas e ambientes de programaça˜ o. Entretanto, o formato DTORF utiliza-se de um conjunto limitado de tags espec´ıficas para representaça˜ o da estrutura dos objetos extra´ıdos da Web. Desta forma, as linguagens de consulta para documentos XML génericos tornam-se dif´ıceis de serem aplicadas a um arquivo no formato DTORF devido a diferenças na forma como elementos e atributos são utilizados para representar dados nesses repositórios textuais. Além disso, em muitas situaço˜ es, a manipulaça˜ o de dados diretamente em um formato textual pode se tornar dif´ıcil e pouco eficiente. Este artigo apresenta uma abordagem para armazenamento e manipulaça˜ o de dados semiestruturados extra´ıdos de páginas da Web e organizados de acordo com o modelo DEByE-OM. A abordagem consiste na utilizaça˜ o de um sistema gerenciador de banco de dados (SGBD) relacional para armazenamento e consulta desses dados. A principal justificativa e´ que um SGBD relacional provê um meio seguro e robusto para o gerenciamento de grandes volumes de dados. Os dados são estruturados de tal forma que e´ poss´ıvel realizar sobre eles operaço˜ es tradicionais de bancos de dados. Além disso, aproveitando-se da semântica adicionada pela estruturaça˜ o dos objetos, e´ poss´ıvel integrar mais facilmente objetos oriundos de uma fonte de dados semiestruturados com objetos de outras fontes de dados estruturados ou semi-estruturados. Este artigo está organizado da seguinte maneira. A Seça˜ o 2 descreve trabalhos relacionados. A Seça˜ o 3 apresenta os conceitos do modelo DEByE-OM. A Seça˜ o 4 apresenta a estratégia adotada para armazenamento de dados semi-estruturados em um banco de dados relacional. Na Seça˜ o 5, descrevemos como repositórios textuais (DTORs) são reconstru´ıdos a partir do repositório relacional. A Seça˜ o 6 apresenta resultados de experimentos realizados para avaliar a abordagem proposta. Finalmente, a Seça˜ o 7 conclui o artigo. 2 Trabalhos Relacionados Diversas abordagens foram propostas para armazenamento de dados semi-estruturados permitindo posterior consulta sobre seu conteúdo. Uma primeira alternativa consiste na criaça˜ o de sistemas espec´ıficos para tratamento de dados semi-estruturados considerando suas próprias caracter´ısticas. Exemplos de sistemas deste tipo são Lore [25], Tsimmis [5] e Strudel [11], e.

(3) sistemas comerciais como eXceleron [27] e Tamino [31]. Em geral, esses sistemas armazenam o esquema juntamente com os dados. A prática de armazenamento dos dados juntamente com o esquema provê a flexibilidade necessária aos dados semi-estruturados, portanto implica em maior espaço de armazenamento e custo adicional de processamento devido ao fato do esquema estar replicado a cada item de dados armazenado. XML vem tornando-se o padrão dominante para representaça˜ o de dados na Web devido a` sua simplicidade (se comparada a SGML) e seu poder de expressão (se comparada a HTML). Diversos modelos e linguagens de consulta para dados semi-estruturados têm sido propostos para explorar o poder da XML. Diferentes abordagens têm sido propostas para armazenamento e manipulaça˜ o de dados XML utilizando bancos de dados relacionais [9, 12, 14, 17, 32]. Com relaça˜ o a essas abordagens, podemos identificar três alternativas básicas [17]. A primeira alternativa e´ muito simples e consiste em armazenar o documento XML inteiro como um u´ nico atributo do banco de dados. A segunda alternativa consiste em representar documentos XML como grafos e então criar um esquema relacional que permite o armazenamento das estruturas genéricas de um grafo como atributos e valores [12, 14]. A terceira alternativa consiste em mapear os diferentes tipos de elemento encontrados nos documentos XML para esquemas relacionais correpondentes [9, 17, 32]. Apenas esta u´ ltima alternativa permite explorar as caracter´ısticas dos SGBDs relacionais como mecanismos de consulta, otimizaça˜ o, controle de concorrência, etc. Por esta razão, a nossa abordagem explora a idéia presente nesta alternativa e, no contexto DEByE, tem como objetivo a representaça˜ o dos tipos de objetos considerados pelo modelo DEByE-OM em termos de esquemas de relaça˜ o. Em [9], os autores apresentam uma técnica para armazenamento de dados semi-estruturados em um banco de dados relacional que está baseada em um mapeamento do modelo OEM (Object Exchange Model) para o modelo relacional. O mapeamento e´ expresso em uma linguagem de consulta declarativa denominada STORED (Semistructured TO Relational Data) e e´ gerado automaticamente utilizando-se técnicas de data-mining. Desta forma, dados XML são automaticamente convertidos em dados relacionais. O mapeamento e´ feito sem perdas, isto e´ , parte dos dados que não e´ poss´ıvel de ser armazenada no banco de dados relacional e´ armazenada em um grafo de overflow. Diversos fornecedores de SGBDs relacionais têm implementado extensões para possibilitar a transferência de dados entre documentos XML e tabelas definidas pelo usuário. Alguns deles possibilitam o armazenamento de documentos XML como um u´ nico atributo de uma tabela do banco de dados e a manipulaça˜ o desses documentos através de extensões que permitem consultas baseadas em processamento de texto. Exemplos desses SGBDs são o Oracle 8i, DB2 e Informix. Existem também propostas de se utilizar SGBDs orientado a objetos para armazenamento de dados semi-estruturados. Esta abordagem e´ apresentada em [6] e implementada em sistemas comerciais como O . Mais recentemente, têm sido desenvolvidos SGBDs cujo modelo subjacente e´ semi-estruturado [25]. 3 Conceitos do Modelo DEByE-OM Esta seça˜ o apresenta os conceitos do modelo de objetos DEByE-OM (DEByE Object Model) [20] utilizados para descrever a estrutura dos dados extra´ıdos da Web. O modelo DEByEOM baseia-se na suposiça˜ o de que certa categoria de páginas da Web, ditas ricas em dados e de abrangência semântica espec´ıfica [10], podem ser vistas como coleço˜ es de objetos complexos que possuem uma estrutura impl´ıcita. Esses objetos, por sua vez, podem ser compostos por out-.

(4) ros objetos formando uma estrutura hierárquica de objetos. Por exemplo, no trecho da página do site da livraria Murder by the Book (http://www.neosoft.com/ mrdrbybk) apresentado na Figura 1, podemos identificar porço˜ es distintas contendo dados sobre livros de quatro autores. Cada uma dessas porço˜ es de dados pode ser considerada um objeto impl´ıcito. Para cada um desses objetos, podemos identificar um nome de autor associado a uma lista de livros. Para os livros de uma lista, encontramos informaça˜ o adicional como t´ıtulos e preços. Desta maneira, existe uma estrutura inerente a cada objeto presente na página da Figura 1. Os objetos impl´ıcitos nesta figura possuem uma estrutura de vários n´ıveis e, devido a isto, são chamados objetos complexos. A Figura 2 representa a estrutura hierárquica inerente ao objeto correspondente a` autora Agatha Christie.. Figura 1: Extrato de uma página do site da livraria Murder by the Book.. Author Name. Book. Agatha Christie. Title. Price. , 5.95), {(The Adventure of the Christmas Pudding, (The Hound of Death, 8.95)} Figura 2: Estrutura hierárquica de um dos objetos da Figura 1. O modelo DEByE-OM utiliza o conceito de tipo de objeto para criar abstraço˜ es para conjuntos de objetos que apresentam estrutura similar. Os tipos de objeto considerados são o tipo atômico (tipo-a), tipo lista (tipo-l), tipo tupla (tipo-t) e o tipo variante (tipo-v). Um objeto do tipo atômico pode assumir somente valores atômicos. Um objeto do tipo lista e´ um conjunto ordenado de objetos, todos do mesmo tipo, chamados de membros. Um objeto do tipo tupla e´ uma agregaça˜ o de outros objetos, chamados de componentes. Objetos de um tipo variante são objetos de qualquer tipo de uma lista de tipos chamados alternativas do tipo variante. Tipos variantes são usados para representar a natureza semi-estruturada dos dados, definindo poss´ıveis estruturas distintas que um mesmo objeto pode apresentar. A sintaxe e semântica de cada tipo de objeto definido anteriormente são descritas detalhadamente em [20]. A expressão (1) define um tipo de objeto complexo definido de acordo com os tipos de objeto (tipo-a, tipo-l, tipo-t e tipo-v) descritos acima. Neste exemplo, um tipo-l foi definido.

(5) sobre o tipo-v

(6) . O tipo-v

(7) possui como alternativas dois tipos-t distintos. As duas alternativas são compostas por um tipo-a e por um tipo-l . Entretanto, a estrutura interna do tipo-t da primeira alternativa e´ diferente da estrutura interna do tipo-t da segunda alternativa. O tipo-v descrito acima pode ser utilizado para descrever a estrutura dos dados encontrados no extrato da página da Figura 1. Naquela figura, os dados sobre os livros de Agatha Christie estão estruturados de acordo com a primeira alternativa do tipo-v

(8) . Já os dados sobre os livros de Leslie Charteris apresentam-se estruturados conforme a segunda alternativa. .

(9) : ( , :( ! , "# $&%' ) ( ), ( )* , :( +-,. /"# $&%0 , 0 ! 1( ) ( )] (. (1). O modelo DEByE-OM permite que os objetos extra´ıdos sejam representados por tabelas aninhadas [18, 23]. A correspondência entre tabelas aninhadas e objetos complexos permite que todo esquema de uma tabela seja representado em termos de objetos complexos. Entretanto, o contrário não e´ necessariamente verdadeiro [20]. Desta forma, podemos concluir que objetos complexos são mais poderosos para representar objetos encontrados na Web quando comparados ao paradigma de tabelas aninhadas. Por outro lado, tabelas aninhadas caracterizam-se por serem simples, intuitivas e expressivas para representar esses objetos. Na abordagem DEByE, este paradigma foi escolhido por facilitar a descriça˜ o da estrutura de objetos complexos identificados pelo usuário. A noça˜ o usual de tabelas aninhadas foi estendida para permitir variaço˜ es na estrutura dessas tabelas e, portanto, acomodar a natureza semi-estruturada dos dados encon trados na Web. Seja 23 3 (54/6769898:); ) ( um tipo-l definido sobre o tipo-t . Uma instância deste tipo pode ser vista como uma tabela cujas linhas (tuplas) são instâncias do tipo-t e cujas colunas são instâncias dos tipos <.6=->698?898@6A5, . Se cada componente 5 e´ do tipo atômico, temos uma tabela basta que um dos )B seja definido relacional pura. Para representar atributos multivalorados, como uma lista sobre um tipo atômico, por exemplo, )BC3 HDG BE( . Para o caso de tabelas aninhadas, temos que um )B qualquer pode ser definido como )BF3 BC3 ( DBE4I69DBJK698?8?69DBJL ) ( , onde os valores destes atributos são instâncias que podem ser vistas como tabelas. A Figura 3 apresenta uma tabela representando instâncias extra´ıdas da Figura 1. A estrutura dessa tabela corresponde ao tipo-l definido em (1). 4 Armazenamento de Dados Semi-Estruturados em um Banco de Dados Relacional Esta seça˜ o apresenta, por meio de um exemplo, como dados semi-estruturados organizados de acordo com o modelo DEByE-OM podem ser armazenados em um banco de dados relacional. A estratégia adotada para armazenamento está baseada em um mapeamento do modelo DEByE-OM para o modelo relacional. O objetivo e´ que os objetos extra´ıdos, que apresentam caracter´ısticas como aninhamento e variaça˜ o na estrutura, sejam adequadamente representados no modelo relacional. A caracter´ıstica do modelo DEByE-OM de ser um modelo para representaça˜ o de dados no n´ıvel lógico faz com que esse mapeamento seja feito de forma mais direta. Entretanto, o principal desafio existente e´ a representaça˜ o no modelo relacional de dados que apresentam estrutura irregular. O mapeamento e´ feito de forma a preservar a estrutura hierárquica dos dados e, conseqüentemente, a semântica associada a eles. Para ilustrar o processo de armazenamento de dados semi-estruturados em um banco de dados relacional, usaremos como exemplo a página do site da livraria Murder by the Book ilustrada.

(10) Author Name. Agatha Christie. Leslie Charteris. Reginald Hill. Pat Burden. Book Title The Adventure of the Christmas Pudding The Hound of Death .... Price 5.95 8.95 .... UnitPrice. BookTitle. 6.95. Saint Bids Diamonds Saint Goes West Saint in Pursuit. UnitPrice. BookTitle. 10.95. An April Shroud Clubbable Woman. Title Bury Him Kindly Screaming Bones. MNMOM. Price 8.95 8.95. Figura 3: Tabela aninhada representando quatro instâncias de

(11) de acordo com (1). na Figura 1. As relaço˜ es resultantes contendo instâncias de objetos extra´ıdos dessa página são apresentadas na Figura 4. O banco de dados gerado a partir de um ou mais DTORs constitui um repositório de objetos e e´ denominado DROR (DEByE Relational Object Repository). A criaça˜ o do esquema relacional e´ feita a partir de regras [24] que determinam como os tipos de objeto considerados pelo modelo DEByE-OM (tipo atômico, tipo lista, tipo tupla e tipo variante) são representados em termos de esquemas de relaça˜ o segundo o modelo relacional. As regras são aplicadas de forma recursiva sobre a estrutura hierárquica dos objetos a serem armazenados. O algoritmo apresentado na Figura 5 implementa essas regras para criaça˜ o do esquema relacional completo. A estratégia adotada para representaça˜ o relacional de objetos de um tipo variante consiste em criar relaço˜ es comuns para armazenar as porço˜ es de dados desses objetos que apresentam estrutura similar e relaço˜ es distintas para armazenar as porço˜ es de dados desses objetos que possuem semântica comum, porém que estão estruturados de diferentes formas. Assim, o algoritmo que implementa as regras para geraça˜ o do esquema relacional cria uma relaça˜ o PQB para cada estrutura diferente para um mesmo tipo-l ou tipo-t que compõe as alternativas do tipo variante. O valor de varia entre 1 e , sendo o número de estruturas distintas para um mesmo tipo-l ou tipo-t. Para o nosso exemplo, a relaça˜ o

(12) foi criada para armazenar nomes de autores, porça˜ o.

(13) col source id 17830161 17830161. Author col oid 709 1094. col Name Agatha Christie Leslie Charteris. Book1 col source id 17830161 17830161 17830161. col oid 727 783 812. col ref Author 709 709 709. col source id 17830161. col oid 1114. col source id 17830161 17830161 17830161. col oid 1125 1145 1162. col Title The Adventure of the Christimas Pudding The Hound of Death Miss Marple’s Final Cases Book2 col ref Author 1094. BookTitle col ref Book2 1114 1114 1114. col Price 5.95 8.95 8.95. col UnitPrice 6.95. col BookTitle Saint Bids Diamonds Saint Goes West Saint’s Gataway. Figura 4: Repositório relacional contendo instâncias de objetos extra´ıdos da página da Web ilustrada na Figura 1. de dados comum a todos os objetos do tipo

(14) . As relaço˜ es R< e K> foram criadas para armazenar dados relativos aos livros publicados pelos autores. Esses dados são apresentados em duas formas diferentes para as diferentes instâncias de

(15) , como definido em (1). A relaça˜ o 0 ! armazena t´ıtulos de livros estruturados de acordo com a segunda alternativa existente para representaça˜ o dos livros dos autores. A chave primária de cada relaça˜ o e´ definida pelo par de atributos SE%' ! TO J%' &UV6W%' ! UX . O valor do atributo %0 ! TN Y%0 U e´ uma assinatura para o identificador de origem da página da Web. O valor do atributo %0 ! &U corresponde a` posiça˜ o inicial na página de origem do conjunto de valores armazenado na relaça˜ o correspondente. Assim, o valor do atributo %0 ! TO J%' &U identifica os objetos pertencentes a uma página e o valor do atributo %' ! U identifica os objetos no escopo dessa página. Combinando-se esses dois valores podemos identificar de forma u´ nica os objetos armazenados no repositório relacional. Além disso, preservamos a ordem dos objetos para a reconstruça˜ o de DTORs armazenados nesse repositório. A Figura 6 mostra como e´ gerado o valor da chave primária para as tuplas das relaço˜ es

(16) e 1< que armazenam os valores referentes a uma instância de um objeto do tipo

(17) . O valor do atributo col source id para as tuplas de

(18) e 1< , representadas na Figura 6, e´ uma assinatura para o valor do atributo sourcehref do elemento Z OBJECTS [ do DTOR resultante da extraça˜ o da página ilustrada na Figura 1. O valor desse atributo identifica a origem dos dados contidos no documento. O valor do atributo col oid corresponde ao valor do atributo ipos referente ao elemento SE\]^`_badcHeVfgihjlkmnfKh*X , no caso da relaça˜ o

(19) , e ao elemento S$\]ô_badc

(20) epfgqhR]srEaOtufKh*X , no caso da relaça˜ o 1< . Os relacionamentos entre um objeto e seus sub-objetos são representados por chaves estrangeiras definidas por restriço˜ es de integridade referencial especificadas entre as relaço˜ es correspondentes..

(21) ´ INICIO Para um tipo-l definido sobre um tipo-a : crie um esquema de relaça˜ o que possua como atributo o membro atômico de ; defina um ´ındice u´ nico para o atributo criado; adicione o par de atributos definindo-o como chave primária; defina um ´ındice u´ nico para o atributo ; crie uma referência com a relaça˜ o correspondente ao objeto imediatamente superior.. v. w. x. v. y?zd{H| }${H~'zd RQzO{

(22) | {K K zO{

(23) | }${H~'zd . v. . . Para um tipo-l definido sobre um tipo-t ou para um tipo-t : crie um esquema de relaça˜ o que possua como atributos os componentes atômicos de ; defina um ´ındice u´ nico para cada atributo criado; adicione o par de atributos definindo-o como chave primária; defina um ´ındice u´ nico para o atributo ; crie uma referência com a relaça˜ o correspondente ao objeto imediatamente superior, se existir; chame, recursivamente, o algoritmo para os componentes não atômicos de .. . x. y?zd{H| }${H~'zd RQzO{

(24) | {K K zO{

(25) | }${H~'zd . . #& QIA Q0. Para um tipo-v : chame, recursivamente, o algoritmo para cada uma das alternativas do tipo variante. FIM. A . Figura 5: Algoritmo para geraça˜ o do esquema relacional do repositório de objetos. Author. <OBJECTS sourcehref = "file/home/versieux/dsm/experimentos/mrdrbybk.html " <VARIANT type = "Author">. (17830161,709,Agatha Christie). <TUPLE type = "Author"> <ATOM type = "Name"> <VALUE ipos = 709 fpos = 723> Agatha Christie</VALUE></ATOM> <LIST type = "Book"> <TUPLE type = "Book"> <ATOM type = "Title"> <VALUE ipos = 727 fpos = 761> The Adventure of The Christmas Pudding</VALUE></ATOM> <ATOM type = "Price"> <VALUE ipos = 767 fpos = 780> 5.95</VALUE></ATOM> </TUPLE> <TUPLE type = "Book"> <ATOM type = "Title"> <VALUE ipos = 783 fpos = 801> The Hound of Death</VALUE></ATOM> <ATOM type = "Price"> <VALUE ipos = 806 fpos = 809> 8.95</VALUE></ATOM> </TUPLE> <TUPLE type = "Book"> <ATOM type = "Title"> <VALUE ipos = 812 fpos = 836> Miss Marple’s Final Cases</VALUE></ATOM> <ATOM type = "Price"> <VALUE ipos = 840 fpos = 843> 8.95</VALUE></ATOM> </TUPLE> </LIST> </TUPLE> </VARIANT> </OBJECTS>. Book1 (17830161,727,709,The Adventure of The Christmas Pudding,5.95) (17830161,783,709,The Hound of Death,8.95) (17830161,812,709,Miss Marple’s Final Cases,8.95). Figura 6: Geraça˜ o do valor da chave primária para as tuplas das relaço˜ es

(26) e. R<. .. A estratégia adotada para armazenamento de dados semi-estruturados utiliza-se de metainformaça˜ o para possibilitar posterior recuperaça˜ o, no formato original, dos dados armazenados no repositório relacional. Assim, um repositório relacional contém, além dos objetos ar-.

(27) mazenados, um conjunto de informaço˜ es relativas a` estrutura do próprio repositório relacional e a` estrutura dos objetos nos repositórios textuais de origem. A Figura 7 apresenta o conjunto de relaço˜ es contendo meta-informaça˜ o para objetos armazenados no repositório relacional apresentado na Figura 4. SOURCE col databasename MURDER. col databasename MURDER MURDER MURDER MURDER MURDER MURDER MURDER MURDER MURDER MURDER. col source oid 17830161. col source oid 17830161 17830161 17830161 17830161 17830161 17830161 17830161 17830161 17830161 17830161. col databasename MURDER MURDER MURDER MURDER. col tablename AUTHOR BOOK1 BOOK1 BOOK2 BOOKTITLE. COLUMN col columname COL NAME COL TITLE COL PRICE COL UNITPRICE COL BOOKTITLE. col source file/home/versieux/dsm/experimentos/mrdrbybk.html. OBJECT col name col type Author VARIANT Author TUPLE Name ATOM Book LIST Book TUPLE UnitPrice ATOM BookTitle LIST Title ATOM Price ATOM BookTitle ATOM TABLE col tablename AUTHOR BOOK1 BOOK2 BOOKTITLE. col objectname Name Title Price UnitPrice BookTitle. col parent Author Author Author Book Book Book Book Book BookTitle. col parenttype OBJECTS VARIANT TUPLE TUPLE LIST TUPLE TUPLE TUPLE TUPLE LIST. col objectname Author Book Book BookTitle. REFERENCE col tablename col ref tablename BOOK1 AUTHOR BOOK2 AUTHOR BOOKTITLE BOOK2. Figura 7: Meta-informaça˜ o referente ao repositório relacional apresentado na Figura 4.. 5 Recuperaça˜ o de Dados no Repositório Relacional. A abordagem aqui apresentada decompõe DTORs em fragmentos para armazená-los no repositório relacional (DROR) o que possibilita a sua manipulaça˜ o utilizando-se operaço˜ es tradicionais de bancos de dados. Entretanto, e´ importante ter mecanismos que possibilitem a recuperaça˜ o, no formato original, dos dados armazenados nesse repositório. Para isso, propomos a utilizaça˜ o de padrões de consulta que descrevem os dados a serem recuperados e são automaticamente convertidos em consultas SQL que são executadas sobre o repositório relacional. Um padrão de consulta e´ uma especificaça˜ o em alto n´ıvel dos objetos a serem recuperados. Um padrão de consulta segue o formato DTORF e pode ser visto como uma especificaça˜ o de porço˜ es de um ou mais DTORs a serem reconstru´ıdas a partir do repositório relacional. O objetivo de um padrão de consulta e´ permitir a recuperaça˜ o de objetos armazenados no repositório relacional sem a necessidade do conhecimento de como esses objetos estão fragmentados nesse repositório. A Figura 8 apresenta o padrão de consulta utilizado para recuperar as publicaço˜ es de Agatha Christie. O atributo U*O*H

(28) TNH,H* do elemento Z OBJECTS [ e´ utilizado para especificar o nome do repositório relacional do qual os dados serão recuperados. O valor do atributo TO J%'1 Y' especifica o DTOR original associado aos dados. Isso torna poss´ıvel reconstruir um u´ nico DTOR a partir do repositório relacional. O atributo 1 Y F0%' , e´ utilizado para identificar porço˜ es dos.

(29) <OBJECTS sourcehref = "http://www.neosoft.com/mrdrbybk" databasename = > <VARIANT type="Author" > <TUPLE type="Author" > <ATOM type="Name" ><VALUE>Agatha Christie</VALUE></ATOM> <LIST type="Book" projection = "Yes" > </LIST> </TUPLE> </VARIANT> </OBJECTS>. Figura 8: Exemplo de um padrão de consulta. objetos que serão recuperadas. Um atributo 1 Y F0%I& , com valor Yes especifica a operaça˜ o de projeça˜ o a ser executada. Padrões de consulta são automaticamente convertidos em consultas SQL que envolvem as relaço˜ es que contêm meta-informaça˜ o e consultas para recuperaça˜ o dos objetos propriamente ditos. Assim, o primeiro grupo de consultas envolve consultas para identificaça˜ o do conjunto de DTORs a ser recuperado, da estrutura original de cada um desses repositórios textuais e para identificaça˜ o da estrutura do repositório relacional gerado a partir deles. O segundo grupo de consultas envolve consultas para recuperaça˜ o dos objetos propriamente ditos. Assim, a partir do primeiro n´ıvel da estrutura hierárquica do padrão de consulta, uma consulta e´ executada sobre cada uma das relaço˜ es que representam o objeto em questão, projetandose os atributos necessários eaplicando-se a restriça˜ o, quando presente para esse grupo. Essas relaço˜ es são identificadas a partir da execuça˜ o das consultas pertencentes ao primeiro grupo. Para os objetos recuperados, consultas similares são executadas sobre as relaço˜ es que representam os objetos imediatamente inferiores na hierarquia. Esse procedimento e´ executado até que os objetos do u´ ltimo n´ıvel sejam recuperados. A Figura 9 apresenta as consultas pertencentes ao segundo grupo geradas a partir do processamento do padrão de consulta da Figura 8. O resultado final do processamento de um padrão de consulta e´ um DTOR contendo os objetos que estão em conformidade com esse padrão. SELECT FROM WHERE AND AND. Book1.col_Title,col_Price Author, Book1 Author.col_source_id = Book1.col_source_id Author.col_oid = Book1.col_ref_Author Author.col_Name = ‘Agatha Christie’. SELECT FROM WHERE AND AND AND AND. Book2.col_UnitPrice, BookTitle.col_BookTitle Author, Book2, BookTitle Author.col_source_id = Book2.col_source_id Author.col_oid = Book2.col_ref_Author Book2.col_source_id = BookTitle.col_source_id Book2.col_oid = BookTitle.col_ref_Book2 Author.col_Name = ‘Agatha Christie’. Figura 9: Consultas SQL geradas a partir do processamento do padrão de consulta da Figura 8..

(30) 6 Resultados Experimentais. Nesta seça˜ o, apresentamos resultados de experimentos realizados para avaliar a nossa abordagem [24]. Em nossos experimentos, um repositório relacional foi gerado a partir de um conjunto de repositórios textuais (DTORs) e padrões de consulta foram processados para a recuperaça˜ o dos objetos armazenados. O conjunto de DTORs foi gerado pela ferramente DEByE como resultado do processo de extraça˜ o de páginas da Web contendo informaça˜ o sobre publicaço˜ es de quinze anais da conferência ACM SIGMOD (International Conference on Management of Data) (http://www.acm.org/sigmod). Os dados contidos nessas páginas foram estruturados segundo o tipo de objeto complexo definido em (2).. . HG. . . ,uH JH,

(31) %0.3$01 C6?"#! H%'R6 0TOT & ,3@)*R6 Y %1! .3@ ! 169"=H.'T'6

(32) (1 (1/(1. (2). Os objetos extra´ıdos contêm dados sobre o ano e o local de cada conferência, as sessões técnicas e os artigos apresentados em cada sessão. Para cada artigo, foram extra´ıdos os nomes dos seus autores, o t´ıtulo e as páginas correspondentes no anais. Os DTORs resultantes do processo de extraça˜ o totalizam 788.240 bytes. O repositório relacional gerado possui um total de 9 relaço˜ es, incluindo as relaço˜ es que contêm meta-informaça˜ o, e ocupa um total de 1.228.800 bytes. Comparando o espaço de armazenamento necessário para os repositórios textuais com o espaço necessário para o repositório relacional, percebemos um aumento de 64% para o repositório relacional. Entretanto, grande parte desse espaço adicional ocupado deve-se aos ´ındices criados neste repositório que ocupam em torno de 55% do espaço total de armazenamento necessário. As relaço˜ es contendo meta-informaça˜ o ocupam 11% desse espaço. Para avaliar o custo de recuperaça˜ o dos dados armazenados no repositório relacional, foram utilizados diversos padrões de consulta que tinham como propósito recuperar objetos completos ou partes dos objetos armazenados. Para cada consulta realizada sobre o repositório relacional utilizando-se padrões de consulta, uma consulta correspondente, expressa em uma linguagem de consulta para documentos XML, foi realizada sobre o conjunto de respositórios textuais (DTORs) que originou o repositório relacional. A linguagem de consulta utilizada foi a XQL (XML Query Language) [29]. Os tempos necessários para a recuperaça˜ o do mesmo conjunto de dados a partir do repositório relacional e dos repositórios textuais foram então comparados. As consultas realizadas foram agrupadas segundo os n´ıveis considerados da estrutura hierárquica dos objetos e o número de objetos recuperados. Primeiramente, foram realizadas consultas que tinham como objetivo recuperar objetos considerando os quatro n´ıveis da hierarquia. A seguir, consultas que envolviam apenas três n´ıveis, dois n´ıveis e o u´ ltimo n´ıvel foram realizadas. Em relaça˜ o ao número de objetos recuperados, as consultas tinham como objetivo recuperar todos ou apenas um u´ nico objeto. A Tabela 1 apresenta o tempo médio gasto, em segundos, para execuça˜ o das consultas pertencentes a cada grupo. O objetivo de se expressar as consultas por meio de padrões de consulta e na linguagem XQL foi avaliar o custo de recuperaça˜ o de dados a partir do repositório relacional e dos repositórios textuais. Os experimentos não tinham por objetivo avaliar a linguagem de consulta XQL. Os experimentos foram realizados em uma estaça˜ o de trabalho com processador i686 (Pentium II, CPU 400 Mhz, Memória Cache: 512 Kb) e memória RAM de 256 Mb, rodando o sistema operacional Linux RedHat 2.2.16..

(33) 4 N´ıveis 3 N´ıveis 2 N´ıveis 1 N´ıvel. Objetos Recuperados Todos 1 Todos 1 Todos 1 Todos 1. Rep. Relacional 23,11 03,47 24,97 01,49 28,10 01,59 24,49 01,43. Rep. Textual 14,69 09,43 13,69 09,82 14,36 12,21 12,28 12,72. Tabela 1: Tempo médio, em segundos, para recuperaça˜ o dos objetos considerando os n´ıveis da hierarquia. Podemos perceber que o tempo gasto para recuperaça˜ o dos dados a partir de repositórios textuais (DTORs) mantém um certo valor independentemente do número de objetos recuperados, o que deve-se ao fato da necessidade de se fazer uma pesquisa sequencial em arquivos-texto para identificaça˜ o dos objetos que satisfazem a consulta. Por outro lado, o armazenamento de dados semi-estruturados em um banco de dados relacional nos permite consultar, de forma mais direta, porço˜ es desses dados, devido ao fato desses dados estarem fragmentados em relaço˜ es independentes. Assim, podemos perceber que o tempo necessário para recuperar um u´ nico objeto do repositório relacional e´ consideravelmente menor quando comparado ao repositório textual. E´ necessário ressaltar que, parte significativa do tempo necessário para recuperaça˜ o dos objetos a partir do repositório relacional está vinculada a` tranformaça˜ o dos dados para o formato DTORF, o que não e´ necessário para os repositórios textuais. 7 Conclusões A abordagem para armazenamento de dados semi-estruturados em um banco de dados relacional, descrita ao longo deste artigo, difere-se de outras abordagens [9, 12, 14, 17, 32] por possuir como foco dados semi-estruturados armazenados em arquivos-texto organizados segundo o modelo de objetos DEByE-OM. A abordagem está baseada em um mapeamento do modelo DEByE-OM para o modelo relacional, no qual os tipos de objeto considerados pelo DEByE-OM são representados em termos de esquemas de relaça˜ o. O conjunto de relaço˜ es criado e´ utilizado para representar a noça˜ o de coleça˜ o e agregaça˜ o de objetos e não representar apenas atributos e valores como em abordagens anteriormente citadas. Essas abordagens, diferentemente da nossa abordagem, possuem como foco documentos XML genéricos. Experimentos realizados mostraram que e´ poss´ıvel a criaça˜ o de representaço˜ es relacionais para dados semi-estruturados, organizados segundo o modelo DEByE-OM, preservando a estrutura hierárquica presente nesses dados. Os dados são estruturados de tal forma que e´ poss´ıvel manipulá-los utilizando-se operaço˜ es tradicionais de bancos de dados. Assim, dados extra´ıdos da Web são armazenados em um meio seguro e robusto para o gerenciamento de grandes volumes de dados, evitando-se a manipulaça˜ o de diversos arquivos-texto. O espaço necessário para armazenamento dos dados no repositório relacional e´ maior do que o espaço necessário para armazenamento dos dados em repositórios textuais, entretanto parte significativa desse espaço adicional deve-se a existência de ´ındices no repositório relacional. Os dados armazenados no repositório relacional podem ainda ser recuperados no seu formato original, formato DTORF, permitindo ao usuário obter diferentes visões dos dados extra´ıdos da Web. A adoça˜ o de padrões de consulta para recuperar objetos complexos de um.

(34) repositório relacional permite recuperar os dados sem a necessidade de conhecimento de como esses objetos estão fragmentados em relaço˜ es do repositório. Experimentos mostraram que, para a recuperaça˜ o dos dados semi-estruturados armazenados no repositório relacional, existe um custo adicional considerável para a conversão dos dados para o formato DTORF. Agradecimentos Este trabalho e´ parcialmente financiado pelo projeto SIAM (MCT/CNPq/PRONEX processo no¯ 00418.00/00). Os autores também agradecem o suporte financeiro do CNPq e CAPES. Referências [1] A BITEBOUL , S. Querying Semi-Structured Data. In Proceedings of Sixth International Conference on Database Theory (Delphi, Greece, 1997), pp. 1–18. [2] A DELBERG , B. NoDoSE - A Tool for Semi-Automatically Extracting Structured and Semistructured Data from Text Documents. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Seattle, Washington, 1998), pp. 283–294. [3] ATZENI , P., AND M ECCA , G. Cut & Paste. In Proceedings of the Sixteenth ACM Symposium on Principles of Database Systems (Tucson, Arizona, 1997), pp. 144–153. [4] C ALIFF , M. E., AND M OONEY, R. J. Relational Learning of Pattern-Match Rules for Information Extraction. In Proceedings of the Sixteenth National Conference on Artificial Intelligence and Eleventh Conference on Innovative Applications of Artificial Intelligence (Menlo Park, California, 1999), pp. 328–334. [5] C HAWATHE , S., G ARCIA -M OLINA , H., H AMMER , J., I RELAND , K., PAPAKONSTANTI NOU , Y., U LLMAN , J., AND W IDOM , J. The TSIMMIS Project: Integration of Heterogeneous Information Sources. In Proceedings of Information Processing Society of Japan Conference - IPSJ (Tokyo, Japan, 1994), pp. 7–18. [6] C HRISTOPHIDES , V., A BITEBOUL , S., C LUET, S., AND S CHOLL , M. From structured documents to novel query facilities. In Proceedings of the ACM SIGMOD International Conference on Management of Data (1994), pp. 313–324. [7] C OHEN , W. W., AND S INGER , Y. A Simple, Fast, and Effective Rule Learner. In Proceedings of the Sixteenth National Conference on Artificial Intelligence and Eleventh Conference on Innovative Applications of Artificial Intelligence (Orlando, Florida, 1999), pp. 335–342. [8] C RESCENZI , V., AND M ECCA , G. Grammars have exceptions. Information Systems 23, 8 (1998), 539–565. [9] D EUTSCH , A., F ERNANDEZ , M. F., AND S UCIU , D. Storing Semistructured Data with STORED. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Philadephia, Pennsylvania,1999), pp. 431–442..

(35) [10] E MBLEY, D. W., C AMPBELL , D. M., J IANG , Y. S., L IDDLE , S. W., L ONSDALE , D. W., N G , Y.-K., Q UASS , D., AND S MITH , R. D. Conceptual-Model-Based Data Extraction From Multiple-Record Web Pages. Data & Knowledge Engineering 31, 3 (1999), 227– 251. [11] F ERNANDEZ , M. F., F LORESCU , D., K ANG , J., L EVY, A. Y., AND S UCIU , D. Catching the Boat with Strudel: Experiences with a Web-Site Management System. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Seattle, Washington,1998), pp. 414–425. [12] F LORESCU , D., AND KOSSMAN , D. Storing and Querying XML Data using a RDBMS. IEEE Data Engineering Bulletim 2, 3 (1999), 10–17. [13] F REITAG , D. Information Extraction from HTML: Application of a General Learning Approach. In Proceedings of the Fifth Conference on Artificial Intelligence AAAI-98 (Madison, Wisconsin, 1998), pp. 517–523. [14] G ARDARIN , G., S HA , F., AND DANG -N GOC , T.-T. XML-Based Components for Federating Multiple Heterogeneous Data Sources. In Conceptual Modeling - ER ’99, 18th International Conference on Conceptual Modeling, J. Akoka, M. Bouzeghoub, I. ComynWattiau, and E. Métais, Eds. Springer, Berlin, 1999, pp. 506–519. [15] H AMMER , J., G ARCIA -M OLINA , H., N ESTOROV, S., Y ERNENI , R., B REUNIG , M., AND VASSALOS , V. Template-Based Wrappers in the TSIMMIS Experience. In Proceedings of the ACM SIGMOD International Conference on Management of Data (Tucson, Arizona, 1997), pp. 532–535. [16] H SU , C.-N., AND D UNG , M.-T. Generating Finite-State Transducer for Semi-Strucutred Data Extraction from the Web. Information Systems 23, 8 (1998), 521–538. [17] K APPEL , G., K APSAMMER , E., R AUSCH -S CHOTT, S., AND R ETSCHITZEGGER , W. XRay - Towards Integrating XML and Relational Database Systems. In Conceptual Modeling - ER 2000, 19th International Conference on Conceptual Modeling, A. H. F. Laender, S. W. Liddle, and V. C. Storey, Eds. Springer, Berlin, 2000, pp. 339–353. [18] KORTH , H. F., AND ROTH , M. A. Query Languages for Nested Relational Databases. Lecture Notes in Computer Science 361 (April 1989), 190–204. [19] K USHMERICK , N., W ELD , D. S., AND D OORENBOS , R. Wrapper induction for information extraction. In Proceedings of the 15th International Joint Conference on Artificial Intelligence (Osaka, Japan, 1997), pp. 729–737. [20] L AENDER , A. H. F., R IBEIRO -N ETO , B., DA S ILVA , A. S., AND S ILVA , E. S. Representing Web Data as Complex Objects. In Electronic Commerce and Web Technologies, First International Conference, EC-Web 2000, K. Bauknecht, S. K. Madria, and G. Pernul, Eds. Springer, Berlin, 2000, pp. 216–228. [21] L AENDER , A. H. F., S ILVA , A. S., AND S ILVA , E. S. DEByE - Uma Ferramenta para Extraça˜ o de Dados Semi-estruturados. In Anais do XIV Simpósio Brasileiro de Banco de Dados (Florianópolis, Santa Catarina, Outubro 1999), pp. 155–169. In Portuguese..

(36) [22] L IU , L., P U , C., AND H AN , W. XWRAP: An XML-enable Wrapper Construction System for Web Information Sources. In Proceedings of the 16th International Conference on Data Engineering (San Diego, California, 2000), pp. 611–621. [23] L ORENTZOS , N. A., AND D ONDIS , K. A. Query by Example for Nested Tables. In Database and Expert Systems Applications, 9th International Conference, DEXA’98, E. S. Gerald Quirchitayr and T. J.M.Bench-Capon, Eds. Springer, Berlin, 1998, pp. 716–725. [24] M AGALHAES , K. V. Uma Abordagem para Armazenamento de Dados Semi-Estruturados em Bancos de Dados Relacionais. Dissertaça˜ o de Mestrado, Departamento de Ciência da Computaça˜ o, Universidade Federal de Minas Gerais, Belo Horizonte, Minas Gerais, 2001. [25] M C H UGH , J., A BITEBOUL , S., G OLDMAN , R., Q UASS , D., AND W IDOM , J. Lore: A Database Management System for Semistructured Data. SIGMOD Record 26, 3 (1997), 54–66. [26] M USLEA , I., M INTON , S., AND K NOBLOCK , C. A Hierarchical Approach to Wrapper Induction. In Proceedings of the Third Annual Conference on Autonomous Agents (Seattle, Washington, 1999), pp. 190–197. [27] O BJECT D ESIGN I NC . An XML Data Server for Building Entreprise Web Applications. http://www.odi.com/excelon/XMLResource. [28] R IBEIRO -N ETO , B., L AENDER , A. H. F., AND DA S ILVA , A. S. Extracting SemiStructured Data Through Examples. In Proceedings of The Eighth ACM International Conference on Information and Knowledge Management (Kansas City, Missouri, 1999), pp. 94–101. [29] ROBIE , J., L APP, J., AND S CHACH , D. http://www.w3.org/TandS/QL/QL98/pp/xql.html.. XML Query Language (XQL).. [30] S AHUGUET, A., AND A ZAVANT, F. Building light-weight wrappers for legacy web datasources using W4F. In Proceedings of the 25th International Conference on Very Large Database Systems (Edingurgh, Scotland, 1999), pp. 738–741. [31] S CHONING , H., AND WASH , J. Tamino: An Internet Database System. In Proceedings of the Eleventh International Conference on Extending Database Technology (Konstanz, Germany, 2000), pp. 383–387. [32] S HANMUGASUNDARAM , J., T UFTE , K., H E , G., Z HANG , C., D E W ITT, D., AND NAUGHTON , J. Relational Databases for Quering XML Documents: Limitations and Opportunities. In Proceedings of the 25th International Conference on Very Large Data Bases (Edinburgh, Scotland, 1999), pp. 302–304. [33] S PENCER , P., C ORSHAM , A., AND J ONES , P. XML Design and Implementation. Wrox Press Ltd., Acocks Green, Birmingham, 1999..

(37)