• Nenhum resultado encontrado

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
15
0
0

Texto

(1)Uma Abordagem para Armazenamento de Dados Semi-Estruturados em Bancos de Dados Relacionais Karine V. Magalh˜aes. Alberto H. F. Laender. Altigran S. da Silva. Departamento de Ciˆencia da Computac¸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 Introduc¸a˜ o A Internet, em especial a World Wide Web (Web), tornou-se um vasto reposit´orio de dados. Entretanto, os dados dispon´ıveis na Web s˜ao, em geral, dif´ıceis de serem efetivamente utilizados pela maioria dos usu´arios da Internet. A dificuldade em se utilizar esses dados deve-se ao fato de que eles n˜ao podem ser adequadamente consultados e manipulados atrav´es de t´ecnicas tradicionais de bancos de dados. Essa limitac¸a˜ o deve-se a` maneira como os dados da Web est˜ao estruturados. Ao contr´ario de como ocorre em bancos de dados tradicionais, cada fonte de dados apresenta suas pr´oprias caracter´ısticas em termos de meios de acesso e de estruturac¸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´ario. Como exemplo, podemos citar dados contidos em p´aginas de sites de livrarias eletrˆonicas, referˆencias bibliogr´aficas, cat´alogos eletrˆonicos, sites de previs˜ao de tempo e outros. Dados deste tipo s˜ao denominados semi-estruturados [1]. Uma poss´ıvel soluc¸a˜ o para o problema de manipulac¸a˜ o de dados semi-estruturados e´ extra´ı-los de p´aginas da Web e armazen´a-los em um banco de dados relacional para posterior manipulac¸a˜ o. Neste sentido, diversas abordagens tˆem sido propostas para extrac¸a˜ o e estruturac¸a˜ o dos dados encontrados na Web. Entre elas, podemos citar linguagens para gerac¸a˜ o de wrappers [3, 8, 15], processamento de linguagem natural [7, 13], gerac¸a˜ o de wrappers baseados em induc¸a˜ o [4, 16, 19, 26], ontologia [10] e modelagem de documentos [2, 28], al´em daquelas que exploram a estrutura dos documentos HTML para gerac¸a˜ o de regras de extrac¸a˜ o [22, 30]..

(2) A abordagem DEByE (Data Extraction By Example) [20, 28], para extrac¸a˜ o de dados semiestruturados da Web, difere-se de outras abordagens devido ao fato de o processo de extrac¸a˜ o ser totalmente guiado por exemplos fornecidos pelo usu´ario. O usu´ario especifica alguns objetos de exemplo derivados de uma p´agina de amostra e esses objetos s˜ao usados para extrair automaticamente novos objetos de p´aginas que apresentam estrutura similar. A ferramenta DEByE [20, 21, 28] foi desenvolvida para suportar o processo de especificac¸a˜ o de exemplos e a extrac¸a˜ o dos dados. A interface gr´afica da DEByE auxilia o usu´ario a descrever a estrutura impl´ıcita dos objetos. A partir dos exemplos fornecidos pelo usu´ario, s˜ao gerados padr˜oes de extrac¸a˜ o que alimentam o processo de extrac¸a˜ o. O resultado de um processo de extrac¸a˜ o da ferramenta DEByE e´ um arquivo-texto, contendo os objetos extra´ıdos de p´aginas da Web, denominado DTOR (DEByE Textual Object Repository). Em um DTOR, os objetos est˜ao organizados segundo um formato baseado na notac¸a˜ o XML [33] chamado DTORF (DEByE Textual Object Repository Format). O DTORF constitui uma implementac¸a˜ o XML do modelo de objetos DEByE-OM (DEByE Object Model) [20], modelo adotado pela abordagem DEByE para representac¸a˜ o de dados semi-estruturados. A principal vantagem de se ter uma implementac¸a˜ o XML do modelo DEByE-OM e´ que os objetos representados textualmente podem ser processados atrav´es de aplicac¸o˜ es e bibliotecaspadr˜ao existentes para diversas plataformas e ambientes de programac¸a˜ o. Entretanto, o formato DTORF utiliza-se de um conjunto limitado de tags espec´ıficas para representac¸a˜ o da estrutura dos objetos extra´ıdos da Web. Desta forma, as linguagens de consulta para documentos XML g´enericos tornam-se dif´ıceis de serem aplicadas a um arquivo no formato DTORF devido a diferenc¸as na forma como elementos e atributos s˜ao utilizados para representar dados nesses reposit´orios textuais. Al´em disso, em muitas situac¸o˜ es, a manipulac¸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 manipulac¸a˜ o de dados semiestruturados extra´ıdos de p´aginas da Web e organizados de acordo com o modelo DEByE-OM. A abordagem consiste na utilizac¸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ˆe um meio seguro e robusto para o gerenciamento de grandes volumes de dados. Os dados s˜ao estruturados de tal forma que e´ poss´ıvel realizar sobre eles operac¸o˜ es tradicionais de bancos de dados. Al´em disso, aproveitando-se da semˆantica adicionada pela estruturac¸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´a organizado da seguinte maneira. A Sec¸a˜ o 2 descreve trabalhos relacionados. A Sec¸a˜ o 3 apresenta os conceitos do modelo DEByE-OM. A Sec¸a˜ o 4 apresenta a estrat´egia adotada para armazenamento de dados semi-estruturados em um banco de dados relacional. Na Sec¸a˜ o 5, descrevemos como reposit´orios textuais (DTORs) s˜ao reconstru´ıdos a partir do reposit´orio relacional. A Sec¸a˜ o 6 apresenta resultados de experimentos realizados para avaliar a abordagem proposta. Finalmente, a Sec¸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´udo. Uma primeira alternativa consiste na criac¸a˜ o de sistemas espec´ıficos para tratamento de dados semi-estruturados considerando suas pr´oprias caracter´ısticas. Exemplos de sistemas deste tipo s˜ao 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´atica de armazenamento dos dados juntamente com o esquema provˆe a flexibilidade necess´aria aos dados semi-estruturados, portanto implica em maior espac¸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˜ao dominante para representac¸a˜ o de dados na Web devido a` sua simplicidade (se comparada a SGML) e seu poder de express˜ao (se comparada a HTML). Diversos modelos e linguagens de consulta para dados semi-estruturados tˆem sido propostos para explorar o poder da XML. Diferentes abordagens tˆem sido propostas para armazenamento e manipulac¸a˜ o de dados XML utilizando bancos de dados relacionais [9, 12, 14, 17, 32]. Com relac¸a˜ o a essas abordagens, podemos identificar trˆes alternativas b´asicas [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˜ao criar um esquema relacional que permite o armazenamento das estruturas gen´ericas 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, otimizac¸a˜ o, controle de concorrˆencia, etc. Por esta raz˜ao, a nossa abordagem explora a id´eia presente nesta alternativa e, no contexto DEByE, tem como objetivo a representac¸a˜ o dos tipos de objetos considerados pelo modelo DEByE-OM em termos de esquemas de relac¸a˜ o. Em [9], os autores apresentam uma t´ecnica para armazenamento de dados semi-estruturados em um banco de dados relacional que est´a 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´ecnicas de data-mining. Desta forma, dados XML s˜ao automaticamente convertidos em dados relacionais. O mapeamento e´ feito sem perdas, isto e´ , parte dos dados que n˜ao e´ poss´ıvel de ser armazenada no banco de dados relacional e´ armazenada em um grafo de overflow. Diversos fornecedores de SGBDs relacionais tˆem implementado extens˜oes para possibilitar a transferˆencia de dados entre documentos XML e tabelas definidas pelo usu´ario. Alguns deles possibilitam o armazenamento de documentos XML como um u´ nico atributo de uma tabela do banco de dados e a manipulac¸a˜ o desses documentos atrav´es de extens˜oes que permitem consultas baseadas em processamento de texto. Exemplos desses SGBDs s˜ao o Oracle 8i, DB2 e Informix. Existem tamb´em 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ˆem sido desenvolvidos SGBDs cujo modelo subjacente e´ semi-estruturado [25]. 3 Conceitos do Modelo DEByE-OM Esta sec¸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 suposic¸a˜ o de que certa categoria de p´aginas da Web, ditas ricas em dados e de abrangˆencia semˆantica espec´ıfica [10], podem ser vistas como colec¸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´arquica de objetos. Por exemplo, no trecho da p´agina do site da livraria Murder by the Book (http://www.neosoft.com/  mrdrbybk) apresentado na Figura 1, podemos identificar porc¸o˜ es distintas contendo dados sobre livros de quatro autores. Cada uma dessas porc¸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 informac¸a˜ o adicional como t´ıtulos e prec¸os. Desta maneira, existe uma estrutura inerente a cada objeto presente na p´agina da Figura 1. Os objetos impl´ıcitos nesta figura possuem uma estrutura de v´arios n´ıveis e, devido a isto, s˜ao chamados objetos complexos. A Figura 2 representa a estrutura hier´arquica inerente ao objeto correspondente a` autora Agatha Christie.. Figura 1: Extrato de uma p´agina 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´arquica de um dos objetos da Figura 1. O modelo DEByE-OM utiliza o conceito de tipo de objeto para criar abstrac¸o˜ es para conjuntos de objetos que apresentam estrutura similar. Os tipos de objeto considerados s˜ao o tipo atˆomico (tipo-a), tipo lista (tipo-l), tipo tupla (tipo-t) e o tipo variante (tipo-v). Um objeto do tipo atˆomico pode assumir somente valores atˆomicos. 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 agregac¸a˜ o de outros objetos, chamados de componentes. Objetos de um tipo variante s˜ao objetos de qualquer tipo de uma lista de tipos chamados alternativas do tipo variante. Tipos variantes s˜ao usados para representar a natureza semi-estruturada dos dados, definindo poss´ıveis estruturas distintas que um mesmo objeto pode apresentar. A sintaxe e semˆantica de cada tipo de objeto definido anteriormente s˜ao descritas detalhadamente em [20]. A express˜ao (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˜ao 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´agina da Figura 1. Naquela figura, os dados sobre os livros de Agatha Christie est˜ao estruturados de acordo com a primeira alternativa do tipo-v 

(8)  . J´a 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ˆencia entre tabelas aninhadas e objetos complexos permite que todo esquema de uma tabela seja representado em termos de objetos complexos. Entretanto, o contr´ario n˜ao e´ necessariamente verdadeiro [20]. Desta forma, podemos concluir que objetos complexos s˜ao 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 descric¸a˜ o da estrutura de objetos complexos identificados pelo usu´ario. A noc¸a˜ o usual de tabelas aninhadas foi estendida para permitir variac¸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ˆancia deste tipo pode ser vista como uma tabela cujas linhas (tuplas) s˜ao instˆancias do tipo-t  e cujas colunas s˜ao instˆancias dos tipos <.6=->698?898@6A5, . Se cada componente 5 e´ do tipo atˆomico, temos uma tabela  basta que um dos )B seja definido relacional pura. Para representar atributos multivalorados, como uma lista sobre um tipo atˆomico, 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˜ao instˆancias que podem ser vistas como tabelas. A Figura 3 apresenta uma tabela representando instˆancias 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 sec¸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´egia adotada para armazenamento est´a 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 variac¸a˜ o na estrutura, sejam adequadamente representados no modelo relacional. A caracter´ıstica do modelo DEByE-OM de ser um modelo para representac¸a˜ o de dados no n´ıvel l´ogico faz com que esse mapeamento seja feito de forma mais direta. Entretanto, o principal desafio existente e´ a representac¸a˜ o no modelo relacional de dados que apresentam estrutura irregular. O mapeamento e´ feito de forma a preservar a estrutura hier´arquica dos dados e, conseq¨uentemente, a semˆantica associada a eles. Para ilustrar o processo de armazenamento de dados semi-estruturados em um banco de dados relacional, usaremos como exemplo a p´agina 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ˆancias de 

(11)  de acordo com (1). na Figura 1. As relac¸o˜ es resultantes contendo instˆancias de objetos extra´ıdos dessa p´agina s˜ao apresentadas na Figura 4. O banco de dados gerado a partir de um ou mais DTORs constitui um reposit´orio de objetos e e´ denominado DROR (DEByE Relational Object Repository). A criac¸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ˆomico, tipo lista, tipo tupla e tipo variante) s˜ao representados em termos de esquemas de relac¸a˜ o segundo o modelo relacional. As regras s˜ao aplicadas de forma recursiva sobre a estrutura hier´arquica dos objetos a serem armazenados. O algoritmo apresentado na Figura 5 implementa essas regras para criac¸a˜ o do esquema relacional completo. A estrat´egia adotada para representac¸a˜ o relacional de objetos de um tipo variante consiste em criar relac¸o˜ es comuns para armazenar as porc¸o˜ es de dados desses objetos que apresentam estrutura similar e relac¸o˜ es distintas para armazenar as porc¸o˜ es de dados desses objetos que possuem semˆantica comum, por´em que est˜ao estruturados de diferentes formas. Assim, o algoritmo que implementa as regras para gerac¸a˜ o do esquema relacional cria uma relac¸a˜ o PQB para cada estrutura diferente para um mesmo tipo-l ou tipo-t que comp˜oe as alternativas do tipo variante. O valor de  varia entre 1 e  , sendo  o n´umero de estruturas distintas para um mesmo tipo-l ou tipo-t. Para o nosso exemplo, a relac¸a˜ o 

(12)  foi criada para armazenar nomes de autores, porc¸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´orio relacional contendo instˆancias de objetos extra´ıdos da p´agina da Web ilustrada na Figura 1. de dados comum a todos os objetos do tipo 

(14)  . As relac¸o˜ es   R< e   K> foram criadas para armazenar dados relativos aos livros publicados pelos autores. Esses dados s˜ao apresentados em duas formas diferentes para as diferentes instˆancias de 

(15)  , como definido em (1). A relac¸a˜ o   0   !  armazena t´ıtulos de livros estruturados de acordo com a segunda alternativa existente para representac¸a˜ o dos livros dos autores. A chave prim´aria de cada relac¸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´agina da Web. O valor do atributo %0 ! &U corresponde a` posic¸a˜ o inicial na p´agina de origem do conjunto de valores armazenado na relac¸a˜ o correspondente. Assim, o valor do atributo %0 ! TO  J%' &U identifica os objetos pertencentes a uma p´agina e o valor do atributo %' !  U identifica os objetos no escopo dessa p´agina. Combinando-se esses dois valores podemos identificar de forma u´ nica os objetos armazenados no reposit´orio relacional. Al´em disso, preservamos a ordem dos objetos para a reconstruc¸a˜ o de DTORs armazenados nesse reposit´orio. A Figura 6 mostra como e´ gerado o valor da chave prim´aria para as tuplas das relac¸o˜ es 

(16)  e   1< que armazenam os valores referentes a uma instˆancia 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 extrac¸a˜ o da p´agina 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 relac¸a˜ o 

(19)  , e ao elemento S$\]^o_badc

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

(21) ´ INICIO Para um tipo-l definido sobre um tipo-a : crie um esquema de relac¸a˜ o que possua como atributo o membro atˆomico de ; defina um ´ındice u´ nico para o atributo criado; adicione o par de atributos definindo-o como chave prim´aria; defina um ´ındice u´ nico para o atributo ; crie uma referˆencia com a relac¸a˜ o correspondente ao objeto imediatamente superior.. v. w. x. v. y?zd{H| }${H~'€zd ‚ ƒR„QzO{

(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 relac¸a˜ o que possua como atributos os componentes atˆomicos de ; defina um ´ındice u´ nico para cada atributo criado; adicione o par de atributos definindo-o como chave prim´aria; defina um ´ındice u´ nico para o atributo ; crie uma referˆencia com a relac¸a˜ o correspondente ao objeto imediatamente superior, se existir; chame, recursivamente, o algoritmo para os componentes n˜ao atˆomicos de .. †. x. y?zd{H| }${H~'€zd ‚ ƒR„QzO{

(24) | {K‚ ƒK zO{

(25) | }${H~'€zd ‚ ƒ. †. ‡#ˆ‰&†Š „ †Q‹I„ŒŒA„ †QŽ0. Para um tipo-v : chame, recursivamente, o algoritmo para cada uma das alternativas do tipo variante. FIM. † Š „ † ‹ „AŒŒ„ † Ž. Figura 5: Algoritmo para gerac¸a˜ o do esquema relacional do reposit´orio 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: Gerac¸a˜ o do valor da chave prim´aria para as tuplas das relac¸o˜ es 

(26)  e.   R<. .. A estrat´egia adotada para armazenamento de dados semi-estruturados utiliza-se de metainformac¸a˜ o para possibilitar posterior recuperac¸a˜ o, no formato original, dos dados armazenados no reposit´orio relacional. Assim, um reposit´orio relacional cont´em, al´em dos objetos ar-.

(27) mazenados, um conjunto de informac¸o˜ es relativas a` estrutura do pr´oprio reposit´orio relacional e a` estrutura dos objetos nos reposit´orios textuais de origem. A Figura 7 apresenta o conjunto de relac¸o˜ es contendo meta-informac¸a˜ o para objetos armazenados no reposit´orio 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-informac¸a˜ o referente ao reposit´orio relacional apresentado na Figura 4.. 5 Recuperac¸a˜ o de Dados no Reposit´orio Relacional. A abordagem aqui apresentada decomp˜oe DTORs em fragmentos para armazen´a-los no reposit´orio relacional (DROR) o que possibilita a sua manipulac¸a˜ o utilizando-se operac¸o˜ es tradicionais de bancos de dados. Entretanto, e´ importante ter mecanismos que possibilitem a recuperac¸a˜ o, no formato original, dos dados armazenados nesse reposit´orio. Para isso, propomos a utilizac¸a˜ o de padr˜oes de consulta que descrevem os dados a serem recuperados e s˜ao automaticamente convertidos em consultas SQL que s˜ao executadas sobre o reposit´orio relacional. Um padr˜ao de consulta e´ uma especificac¸a˜ o em alto n´ıvel dos objetos a serem recuperados. Um padr˜ao de consulta segue o formato DTORF e pode ser visto como uma especificac¸a˜ o de porc¸o˜ es de um ou mais DTORs a serem reconstru´ıdas a partir do reposit´orio relacional. O objetivo de um padr˜ao de consulta e´ permitir a recuperac¸a˜ o de objetos armazenados no reposit´orio relacional sem a necessidade do conhecimento de como esses objetos est˜ao fragmentados nesse reposit´orio. A Figura 8 apresenta o padr˜ao de consulta utilizado para recuperar as publicac¸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´orio relacional do qual os dados ser˜ao 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´orio relacional. O atributo ’1 Y “F0%'” , e´ utilizado para identificar porc¸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˜ao de consulta. objetos que ser˜ao recuperadas. Um atributo ’1 Y “F0%I”& , com valor Yes especifica a operac¸a˜ o de projec¸a˜ o a ser executada. Padr˜oes de consulta s˜ao automaticamente convertidos em consultas SQL que envolvem as relac¸o˜ es que contˆem meta-informac¸a˜ o e consultas para recuperac¸a˜ o dos objetos propriamente ditos. Assim, o primeiro grupo de consultas envolve consultas para identificac¸a˜ o do conjunto de DTORs a ser recuperado, da estrutura original de cada um desses reposit´orios textuais e para identificac¸a˜ o da estrutura do reposit´orio relacional gerado a partir deles. O segundo grupo de consultas envolve consultas para recuperac¸a˜ o dos objetos propriamente ditos. Assim, a partir do primeiro n´ıvel da estrutura hier´arquica do padr˜ao de consulta, uma consulta e´ executada sobre cada uma das relac¸o˜ es que representam o objeto em quest˜ao, projetandose os atributos necess´arios eaplicando-se a restric¸a˜ o, quando presente para esse grupo. Essas relac¸o˜ es s˜ao identificadas a partir da execuc¸a˜ o das consultas pertencentes ao primeiro grupo. Para os objetos recuperados, consultas similares s˜ao executadas sobre as relac¸o˜ es que representam os objetos imediatamente inferiores na hierarquia. Esse procedimento e´ executado at´e 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˜ao de consulta da Figura 8. O resultado final do processamento de um padr˜ao de consulta e´ um DTOR contendo os objetos que est˜ao em conformidade com esse padr˜ao. 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˜ao de consulta da Figura 8..

(30) 6 Resultados Experimentais. Nesta sec¸a˜ o, apresentamos resultados de experimentos realizados para avaliar a nossa abordagem [24]. Em nossos experimentos, um reposit´orio relacional foi gerado a partir de um conjunto de reposit´orios textuais (DTORs) e padr˜oes de consulta foram processados para a recuperac¸a˜ o dos objetos armazenados. O conjunto de DTORs foi gerado pela ferramente DEByE como resultado do processo de extrac¸a˜ o de p´aginas da Web contendo informac¸a˜ o sobre publicac¸o˜ es de quinze anais da conferˆencia ACM SIGMOD (International Conference on Management of Data) (http://www.acm.org/sigmod). Os dados contidos nessas p´aginas 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ˆem dados sobre o ano e o local de cada conferˆencia, as sess˜oes t´ecnicas e os artigos apresentados em cada sess˜ao. Para cada artigo, foram extra´ıdos os nomes dos seus autores, o t´ıtulo e as p´aginas correspondentes no anais. Os DTORs resultantes do processo de extrac¸a˜ o totalizam 788.240 bytes. O reposit´orio relacional gerado possui um total de 9 relac¸o˜ es, incluindo as relac¸o˜ es que contˆem meta-informac¸a˜ o, e ocupa um total de 1.228.800 bytes. Comparando o espac¸o de armazenamento necess´ario para os reposit´orios textuais com o espac¸o necess´ario para o reposit´orio relacional, percebemos um aumento de 64% para o reposit´orio relacional. Entretanto, grande parte desse espac¸o adicional ocupado deve-se aos ´ındices criados neste reposit´orio que ocupam em torno de 55% do espac¸o total de armazenamento necess´ario. As relac¸o˜ es contendo meta-informac¸a˜ o ocupam 11% desse espac¸o. Para avaliar o custo de recuperac¸a˜ o dos dados armazenados no reposit´orio relacional, foram utilizados diversos padr˜oes de consulta que tinham como prop´osito recuperar objetos completos ou partes dos objetos armazenados. Para cada consulta realizada sobre o reposit´orio relacional utilizando-se padr˜oes de consulta, uma consulta correspondente, expressa em uma linguagem de consulta para documentos XML, foi realizada sobre o conjunto de resposit´orios textuais (DTORs) que originou o reposit´orio relacional. A linguagem de consulta utilizada foi a XQL (XML Query Language) [29]. Os tempos necess´arios para a recuperac¸a˜ o do mesmo conjunto de dados a partir do reposit´orio relacional e dos reposit´orios textuais foram ent˜ao comparados. As consultas realizadas foram agrupadas segundo os n´ıveis considerados da estrutura hier´arquica dos objetos e o n´umero 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ˆes n´ıveis, dois n´ıveis e o u´ ltimo n´ıvel foram realizadas. Em relac¸a˜ o ao n´umero de objetos recuperados, as consultas tinham como objetivo recuperar todos ou apenas um u´ nico objeto. A Tabela 1 apresenta o tempo m´edio gasto, em segundos, para execuc¸a˜ o das consultas pertencentes a cada grupo. O objetivo de se expressar as consultas por meio de padr˜oes de consulta e na linguagem XQL foi avaliar o custo de recuperac¸a˜ o de dados a partir do reposit´orio relacional e dos reposit´orios textuais. Os experimentos n˜ao tinham por objetivo avaliar a linguagem de consulta XQL. Os experimentos foram realizados em uma estac¸a˜ o de trabalho com processador i686 (Pentium II, CPU 400 Mhz, Mem´oria Cache: 512 Kb) e mem´oria 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´edio, em segundos, para recuperac¸a˜ o dos objetos considerando os n´ıveis da hierarquia. Podemos perceber que o tempo gasto para recuperac¸a˜ o dos dados a partir de reposit´orios textuais (DTORs) mant´em um certo valor independentemente do n´umero de objetos recuperados, o que deve-se ao fato da necessidade de se fazer uma pesquisa sequencial em arquivos-texto para identificac¸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, porc¸o˜ es desses dados, devido ao fato desses dados estarem fragmentados em relac¸o˜ es independentes. Assim, podemos perceber que o tempo necess´ario para recuperar um u´ nico objeto do reposit´orio relacional e´ consideravelmente menor quando comparado ao reposit´orio textual. E´ necess´ario ressaltar que, parte significativa do tempo necess´ario para recuperac¸a˜ o dos objetos a partir do reposit´orio relacional est´a vinculada a` tranformac¸a˜ o dos dados para o formato DTORF, o que n˜ao e´ necess´ario para os reposit´orios textuais. 7 Conclus˜oes 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´a baseada em um mapeamento do modelo DEByE-OM para o modelo relacional, no qual os tipos de objeto considerados pelo DEByE-OM s˜ao representados em termos de esquemas de relac¸a˜ o. O conjunto de relac¸o˜ es criado e´ utilizado para representar a noc¸a˜ o de colec¸a˜ o e agregac¸a˜ o de objetos e n˜ao representar apenas atributos e valores como em abordagens anteriormente citadas. Essas abordagens, diferentemente da nossa abordagem, possuem como foco documentos XML gen´ericos. Experimentos realizados mostraram que e´ poss´ıvel a criac¸a˜ o de representac¸o˜ es relacionais para dados semi-estruturados, organizados segundo o modelo DEByE-OM, preservando a estrutura hier´arquica presente nesses dados. Os dados s˜ao estruturados de tal forma que e´ poss´ıvel manipul´a-los utilizando-se operac¸o˜ es tradicionais de bancos de dados. Assim, dados extra´ıdos da Web s˜ao armazenados em um meio seguro e robusto para o gerenciamento de grandes volumes de dados, evitando-se a manipulac¸a˜ o de diversos arquivos-texto. O espac¸o necess´ario para armazenamento dos dados no reposit´orio relacional e´ maior do que o espac¸o necess´ario para armazenamento dos dados em reposit´orios textuais, entretanto parte significativa desse espac¸o adicional deve-se a existˆencia de ´ındices no reposit´orio relacional. Os dados armazenados no reposit´orio relacional podem ainda ser recuperados no seu formato original, formato DTORF, permitindo ao usu´ario obter diferentes vis˜oes dos dados extra´ıdos da Web. A adoc¸a˜ o de padr˜oes de consulta para recuperar objetos complexos de um.

(34) reposit´orio relacional permite recuperar os dados sem a necessidade de conhecimento de como esses objetos est˜ao fragmentados em relac¸o˜ es do reposit´orio. Experimentos mostraram que, para a recuperac¸a˜ o dos dados semi-estruturados armazenados no reposit´orio relacional, existe um custo adicional consider´avel para a convers˜ao 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´em agradecem o suporte financeiro do CNPq e CAPES. Referˆencias [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´etais, 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 Extrac¸a˜ o de Dados Semi-estruturados. In Anais do XIV Simp´osio Brasileiro de Banco de Dados (Florian´opolis, 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. Dissertac¸a˜ o de Mestrado, Departamento de Ciˆencia da Computac¸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)

Referências

Documentos relacionados

Este presente artigo é o resultado de um estudo de caso que buscou apresentar o surgimento da atividade turística dentro da favela de Paraisópolis, uma

A não uniformização quanto ao método de referência pode promover diferenças entre as curvas de calibração geradas por laboratórios de dosimetria citogenética, que podem

Estes resultados apontam para melhor capacidade de estabelecimento inicial do siratro, apresentando maior velocidade de emergência e percentual de cobertura do solo até os 60

Entendendo, então, como posto acima, propõe-se, com este trabalho, primeiramente estudar a Lei de Busca e Apreensão para dá-la a conhecer da melhor forma, fazendo o mesmo com o

A variação do pH da fase móvel, utilizando uma coluna C8 e o fluxo de 1,2 mL/min, permitiu o ajuste do tempo de retenção do lupeol em aproximadamente 6,2 minutos contribuindo para

O presente experimento teve como objetivo avaliar o desenvolvimento até os vinte e oito meses de idade e o desempenho reprodutivo no primeiro período de acasalamento de fêmeas

As seguintes características foram avaliadas: período, em dias, da semeadura à emergência das plantas em 75% das covas; dias da semeadura à abertura da primeira flor; dias da

Do ponto de vista técnico, conseguiu convencer o corpo médico presente ao encontro que a doença seria transmissível, como comprova o primeiro item da resolução final do encontro: