AVALIAÇÃO DE IMPLEMENTAÇÕES DA
RECOMENDAÇÃO XQUERY FULL TEXT EM
SGBD's XML
Lavras – MG
2014
AVALIAÇÃO DE IMPLEMENTAÇÕES DA RECOMENDAÇÃO XQUERY FULL TEXT EM SGBD's XML
Monografia apresentada ao colegiado do Curso de Sistemas de Informação, para a obtenção do título de Bacharel em Sistemas de Informação.
ORIENTADOR
Dr. Leonardo A. Ribeiro.
COORIENTADOR Dr. Denilson Alves Pereira
Lavras – MG 2014
Monografia apresentada ao colegiado do Curso de Sistemas de Informação, para a obtenção do título de Bacharel em Sistemas de Informação.
APROVADA em 04 de Julho de 2014.
Lavras – MG 2014
XML (eXtensible Markup Language) juntamente com o avanço da Web. Uma característica do modelo de XML é a capacidade de representar dados semiestruturados. Dados desta natureza são caracterizados por conterem porções estruturadas, tais como tabelas do modelo relacional, e não estruturados, tais como texto livre. A representação de dados semiestruturados é extremamente importante porque um número cada vez maior de aplicações produzem e utilizam estes tipos de dados. Uma linguagem de consulta sobre dados semiestruturados deve prover meios para especificação tanto de condições estruturais rígidas quanto condições imprecisas ou vagas. No contexto de dados XML com consultas baseadas em palavras-chave atualmente existe um grande número de implementações do XQuery Full Text em SGBD's XML comerciais e de código livre. Entretanto, a literatura ainda carece de uma análise destes produtos. Com foco em sistemas de código livre e gratuitos, este trabalho apresenta uma análise de SGBD's com suporte ao XQuery Full Text no contexto de facilidade de utilização por pessoas sem treinamento especializado, tais como: estudantes, funcionários de empresas ou órgão público. Os SGBD's analisados foram o Basex, MXQuery, IBM DB2 Express e o ORACLE XMLDB Express. Foram utilizados como critério de análise: instalação, criação de índice, funcionalidade, desempenho e suporte técnico.
Figura 1- DTD do xml ... 7
Figura 2- documento XML ... 9
Figura 3- Árvore XML ... 10
Figura 4- sequência ... 11
Figura 5- Consulta de predicado ... 12
Figura 6- Consulta FLWOR ... 14
Figura 7- Consulta FTContainsExpr ... 15
Figura 8- Processo de indexação... 19
Figura 9- Processamento de consulta ... 28
ER - Entidade-Relacionamentos HTML - Hyper Text Markup Language
SGBD's - Sistemas Gerenciadores de Banco de Dados.
SGBDR's - Sistemas Gerenciadores de Banco de Dados Relacionais SQL - Structured Query Language
URL - Uniform Resource Locator W3C - World Wide Web Consortium XML - eXtensible Markup Language
XQFT – XQuery Full Text
2 REFERENCIAL TEÓRICO ... 4
2.1 XML: Importância e diferença em relação ao modelo relacional ... 4
2.2 Composição de Dados XML ... 6
2.3 XQuery: Linguagem de Consulta para XML... 10
2.4 Modelo de Dados do XQuery ... 11
2.5 XPath ... 12
2.6 Expressões XQuery ... 12
2.7 XQuery Full Text: Extensão do XQuery para Lidar com Texto ... 14
3 SGBD'S XML ... 15
3.1 Oracle XML DB ... 16
3.1.1 Oracle suporte ao XQuery Full Text ... 16
3.1.2 Carga e Armazenamento de Dados e Processamento de Consultas 18 3.1.3 Limitações do Oracle XE... 21
3.2 SGBD XML Basex ... 22
3.2.1 Basex suporte ao XQuery Full Text ... 22 3.2.2 Carga e Armazenamento de Dados e Processamento de Consultas
28
3.3.3 MXQUERY limitações ... 30
3.4 SGBD IBM DB2 ... 30
3.4.1 IBM DB2 Suporte ao XQuery Full Text ... 31
3.4.2 Carga e Armazenamento de Dados e Processamento de Consultas 32 3.4.3 IBM DB2 limitações ... 33 4 METODOLOGIA ... 34 4.1 Classificação ... 34 4.2 Hardware ... 35 4.3 Instalação ... 36 4.4 Importação ... 36 4.5 Teste de Funcionalidade ... 37 4.6 Teste de Desempenho ... 40 4.7 Métricas utilizadas ... 42 5 RESULTADOS ... 44 5.1 Criação de Índices ... 45 5.2 Funcionalidade ... 46
7 REFERÊNCIAS ... 52 1 APÊNDICES ... 59 2 ANEXOS ... 67
1 INTRODUÇÃO
Diante da dificuldade de sistemas gerenciadores de banco de dados relacionais (SGBDR's) em armazenarem dados semiestruturados e não estruturados, foram desenvolvidas ferramentas que armazenam e processam informações não estruturadas, motivo pelo qual é interessante mensurar quão eficazes são tais ferramentas.
Em SGBDR's, antes da carga dos dados, é especificado um esquema descrevendo a estrutura desses dados, mas isto não impõe limitações significativas sobre sistemas tradicionais, que lidam com dados com uma estrutura rígida. Exemplos de domínios de aplicação populares nesse contexto são sistemas de folhas de pagamento, controle de estoque, folha de ponto, entre outros. Por outro lado, a necessidade de uma estrutura prévia para armazenar dados restringe-nos diante da vasta gama de informações que encontramos nos dias de hoje e se encontram representadas em formatos heterogêneos.
Atualmente as empresas utilizam aplicações modernas onde elas têm que lidar com dados onde há estrutura regular ou não. Por exemplo, em um sistema de segurança, juntamente com campos para entradas padronizadas como vítima, local e horário, pode haver um campo texto para entrar com a descrição de testemunhas . Outro exemplo são sistemas para suporte ao consumidor, onde a descrição estruturada de um produto pode estar associada com texto livre representando comentários ou reclamações de consumidores.
Neste contexto, XML é o padrão mais seguido para representação de dados e XQuery é a linguagem de consulta sobre dados XML, tal como SQL é a linguagem de consulta sobre dados relacionais. Para atender a demanda dessas aplicações, vários sistemas gerenciadores de banco de dados (SGBD's) comerciais ou de código aberto foram construídos ou adaptados para suportar nativamente XML e XQuery. (HAUSTEIN, 2007 e BEYER, 2005)
Apesar de permitir a especificação de consultas explorando certas características estruturais, o suporte à consultas destinadas à porções não-estruturadas de dados XML ainda é limitado em XQuery. Por exemplo, não é possível consultar porções de texto livre em um documento XML usando palavras-chave.
Recentemente, uma extensão de XQuery chamada XQuery Full Text foi criada para permitir a especificação de consultas baseadas tanto na estrutura de dados XML quanto em palavras-chave, de acordo com grupo internacional desenvolve padrões para Web, World Wide Web Consortium - W3C. Em particular, XQuery Full Text permite a exploração de técnicas de Recuperação de Informação em XML's, ponderação de termos e contagens de palavras em consultas sobre dados XML. (BAEZA-YATES e RIBEIRO-NETO 2011)
O suporte à XQuery Full Text tem sido divulgado por vários SGBD's tais como: BASEX , IBM DB2, ORACLE XMLDB e MXQUERY. Entretanto, pouco ainda é conhecido a respeito do desempenho e do grau de adequação dos SGBD's à recomendação XQuery Full Text da W3C. Este trabalho visou realizar uma análise em SGBD's de código livre e gratuitos no contexto de facilidade de utilização por pessoas sem treinamento especializado, tais como: estudantes, funcionários de empresas ou órgão público.
As empresas, no contexto da sociedade em geral, se beneficiarão da presente pesquisa porque com um SGBD que suporta XQuery Full Text a empresa poderá representar de forma mais completa os dados complexos gerados no seu dia-a-dia.
Na realidade, as pequenas empresas ou órgãos públicos e privados não dispõem de recursos financeiros para investir em ferramentas caras, e por outro lado, as grandes empresas se resguardam de investimentos em tecnologias que possam coloca-las em risco operacional/financeiro ou porventura não lhes
tragam benefício algum. É interessante ter conhecimento da ferramenta antes da aquisição.
As versões gratuitas das ferramentas proprietárias ajudam a conhecer o produto porque dá para testá-lo, antes de pagar pela licença, já que foco deste trabalho está na examinação das ferramentas gratuitas. Assim, as empresas que se encontram com dificuldades em escolher entre os SGBD's disponíveis no mercado terão dados que servirão de parâmetro para dar suporte na escolha da ferramenta.
O objetivo geral do presente trabalho foi realizar uma análise de implementações gratuitas da recomendação XQuery Full Text em SGBD's XML, onde os aspectos considerados na análise foram desempenho, funcionalidades, suporte técnico e compatibilidade com a recomendação XQuery Full Text.
Os objetivos específicos se dividiram em:
Estudar o suporte à funcionalidades do XQuery Full Text em SGBD's XML comerciais e de código aberto.
Construir de um ambiente de testes para comparação entre SGBD's XML que caracterize cenários reais de aplicações baseadas em dados semiestruturados.
Adaptar modelos de consultas XQuery Full Text sobre coleção de dados XML . (GRAY, 1993)
Avaliar e comparar o desempenho e as funcionalidades dos SGBD's XML que suportem XQuery Full Text, de código livre e proprietário.
Este trabalho se encontra organizado da seguinte forma. Na Seção 2 REFERENCIAL TEÓRICO foram elencadas as bases bibliográficas para reforçar a nossa discussão, na Seção 3 SGBD's XML listamos as características dos SGBD's estudados, na Seção 4 está a METODOLOGIA de como o
trabalho foi desenvolvido, na seção 5 estão os RESULTADOS obtidos após o desenvolvimento e 6 CONCLUSÃO.
2 REFERENCIAL TEÓRICO
Este capítulo apresenta os conceitos básicos dos temas relacionados com desenvolvimento deste trabalho.
2.1 XML: Importância e diferença em relação ao modelo relacional
Em SGBDR's, os dados ficam armazenados em tabelas distribuídos em linhas, colunas e objetos. Esses sistemas trabalham com dados estruturados, e é necessário ter informações a priori a respeito dos mesmos, tais como:
estrutura e propriedades das informações a serem modeladas; como se dará o relacionamento entre as entidades;
qual vocabulário será utilizado pelas pessoas envolvidas na manipulação destes dados.
Diante da necessidade de armazenar dados que não estão estruturados da forma descrita acima, o modelo relacional passou a ser insuficiente diante das novas realidades das informações que classificaremos como dados semiestruturados e não estruturados.
Dados semiestruturados são dados que possuem uma certa estrutura, mas esta estrutura não é rígida e regular como no modelo relacional. São chamados semiestruturados porque os dados são brutos, sem tipificação ou organização aparente, e são desprovidos de estrutura.
A Web fornece exemplos de dados semiestruturados; nela os dados consistem de arquivos em um particular formato, como HTML, com alguma estruturação primitiva tais como tags e âncoras. Um outro exemplo de dados
semiestruturados temos um blog na Web, normalmente eles não têm uma estrutura explícita, porque ele é carregado ou abastecido pelo autor e seguem comentários de outros participantes sem que haja qualquer padrão de representação podendo conter texto, imagem, vídeos ou sons cujos arquivos têm extensão .doc, .txt, .pdf, entre outros.
Os tipos de documentos citados acima estão representados normalmente em linguagem natural, ou seja, a informação não está estruturada (ABITEBOUL, 1997).
Para lidar com dados desestruturados o modelo XML apresenta vantagens como: flexibilidade em representar dados complexos, heterogêneos e independentes. De acordo com Howard Katz (2003), as diferenças entre dados relacionais e dados XML são:
Dados relacionais são planos, isto é, são organizados em linhas e colunas ao contrário dos XML que são aninhados e podem ser apresentar profundidade arbitrária (FLORESCU, 2005).
Dados relacionais podem representar estruturas de dados aninhados usando hierarquia de tipos ou tabelas com chaves estrangeiras. Entretanto, a busca nessas estruturas não é fácil devido ao desconhecimento da profundidade do aninhamento, ao contrário do XML que permite consultar um objeto num documento, mesmo desconhecendo sua estrutura.
Dados relacionais são regulares e homogêneos, cada linha da tabela tem os mesmos nomes e tipos (real, inteiros, caracteres entre outros), ao contrário dos XML que são irregulares e heterogêneos, a organização dos dados é descrita através de etiquetas (tags), e não por tipos de dados descritos em um esquema separado dos dados em si. Em outras palavras, a informação em XML é representada como uma hierarquia de
elementos que têm nomes, atributos opcionais e conteúdos opcionais podendo ser constituídos de texto, elementos aninhados ou pela mistura destes.
A busca numa base relacional resulta em registros com dados do mesmo tipo e organização regular, ao passo que em busca por XML o resultado consistirá em expressões com dados de vários tipos heterogêneos e organização possivelmente irregular. Em base de dados relacional toda linha e toda coluna deve
conter um valor, caso contrário o valor NULL é utilizado para representar ausência (ou desconhecimento) da informação relacionada, ao contrário de XML que os dados desconhecidos ou inaplicáveis simplesmente não aparecem.
Em uma base de dados relacional não são consideradas a ordem das linhas da tabela, uma vez que se pode estabelecer qualquer ordenação pelos valores dos dados sem que seja prejudicada sua significância, ao contrário do XML que a ordem dos dados tem um significado.
A seguir, serão apresentados mais detalhes sobre o modelo de dados XML e seu emprego na representação de dados semiestruturados.
2.2 Composição de Dados XML
Os dados XML podem ser formados por meio de dois modelos, são eles os Data-centric e os Document-centric. Dados Data-centric têm a estrutura relativamente estática e previsível, aplicações tiram proveito desta estrutura, os dados tem o formato de um Schema XML, enfim, este tipo é um modelo de dados que decompõe o documento XML em uma entidade e relacionamento - ER e a indexação é uma árvore B. Document-centric cujos dados estão
relativamente estruturados sua indexação é feita pelo índice XML. As aplicações não tiram proveito de sua estrutura tratando os dados como se eles fossem desprovidos de estrutura (ORACLE, 05/2013).
No modelo de dados XML cada documento é representado como uma árvore de nós, onde cada nó tem uma identidade que o distingue dos outros nós. Os tipos de nós que podem ocorrer são: documento, elemento, atributo, texto, espaço_nome (namespace), instrução de processamento e comentário. (HOWARD KATZ, 2003)
A partir de um DTD – Document Type Definition, podemos apresentar a estrutura de um documento XML. Por exemplo, no caso de um documento contendo uma bibliografia, é possível especificar que o mesmo é constituído por uma sequência de livros, cada livro tem um título, ano de publicação, um autor ou editor, e um editor tem uma afiliação. A Figura 1 é a representação de um DTD.
Figura 1- DTD do XML Exemplo de DTD:
<!ELEMENT books (book* )> <!ELEMENT books (number )>
<!ELEMENT book (title shortTitle, (author+ | editor+ ), content (p, note)> <!ATTLIST book number CDATA #REQUIRED >
<!ELEMENT author> <!ELEMENT editor>
<!ELEMENT title (#PCDATA )> <!ELEMENT shortTitle (#PCDATA )> <!ELEMENT content (#PCDATA )>t
De acordo, com a ordem de documento do modelo de dados XML, cada elemento aparece uma única vez de forma que ordenando os mesmos se remove
as duplicatas. Ele é uma ordenação que está definida entre todos os nós no modelo de consulta de dados de um documento, correspondendo à ordem de representação de vários nós, como eles seriam encontrados se o documento estivesse sendo serializado no formato XML. Cada nó elemento é seguido por seus nós espaço_nome, nós atributo e nós filhos na ordem em que eles aparecem no documento. O conceito de document order é muito importante para a definição operadores das linguagens XPath e nas regras de semântica do XQuery, como será discutido mais adiante. (HOWARD KATZ, 2003)
O primeiro nó em qualquer documento é o nó document que contém o documento todo representando o próprio documento. Os nós elemento, comentários e instruções de processamento ocorrem no documento logo após a expansão das entidades. Os nós elementos ocorrem antes de seus filhos eles contêm nós elementos, nós texto, nós comentários e nós instruções de processamento.
Os atributos são encontrados no documento depois do elemento e antes do filho do elemento, a ordem de atributos é estável, mas dependente da implementação. Veja o exemplo de arquivo XML na Figura 2 a ordem dos nós do documento respeita a estrutura apresentada no DTD, no Anexo II contém mais um exemplar de arquivo XML
2.3 XQuery: Linguagem de Consulta para XML
Figura 3- Árvore XML
A Figura 3 ilustra a estruturação hierárquica de dados XML. As consultas XML seriam mais eficientes em uma nova linguagem de consulta ao invés de serem estendidas à linguagem relacional em virtude das várias diferenças entre os modelos de dados relacionais e XML mencionadas anteriormente.
Contudo a consulta aos dados XML precisa de uma linguagem de consulta adequada às suas características, ou seja, uma linguagem de consulta cuja sintaxe respeite a estrutura de um arquivo XML. Para atender este requisito, o W3C projetou o XQuery que é a linguagem de consulta sobre dados XML tal como SQL é a linguagem de consulta sobre dados relacionais. XQuery opera sobre o modelo de dados de um documento XML.
2.4 Modelo de Dados do XQuery
A entrada e a saída de XQuery são definidas em termos de um modelo de dados baseado na noção de uma sequência ordenada em conjunto de zero ou mais itens. Um item pode ser um nó ou um valor atômico. Um valor atômico é uma instância de um dos tipos de dados internos definido pelo XML Schema, tais como strings, inteiros, decimais e datas. Um nó está em conformidade com um dos sete tipos de elementos: nó, atributo, texto, documento, comentário, instrução de processamento, e nome-espaço. Um nó pode ter outros nós como filhos, formando assim uma ou mais hierarquias de nós. Sequências podem ser heterogêneas, isto é, elas podem conter misturas de vários tipos de nodos e valores atômicos.(W3C, 14/12/2010)
Figura 4- sequência
let $sequence := ("1",
“ Improving Web Site Usability",
“Improving the Usability of a Web Site Through Expert Reviews and Usability Testing”,
“Millicent Marigold”, ”Montana Marigold”, “New York”, “Ersatz Publications”, 2001, 2002 )
2.5 XPath
XPath é uma linguagem que opera sobre a estrutura de um documento XML pois ela é utilizada para localizar partes de um documento XML, ela fornece recursos básicos para manipulação de strings, números e booleanos. Desta forma XPath navega pela estrutura hierárquica de um arquivo recebendo o nome de um caminho como URLs (W3C, 1999).
Em XQuery as expressões XPath são usadas para localizar os nós de dados XML identificando sua localização na hierarquia da árvore por meio de. expressões de caminho para selecionar nós ou conjunto de nós em um documento XML.
O nó é selecionado seguindo um caminho ou passos. No anexo II tem uma lista com algumas seleções em XPath. Para refinar ainda mais a seleção os predicados são utilizados e a expressão é escrita entre colchetes e retorna um valor booleano (AMER–YAHIA et al, 2006). Predicados são usados para encontrar um nó específico ou um nó que contém um valor específico, (W3CSCHOOLS, ca. 2000)
Figura 5- Consulta de predicado Fonte: AMER–YAHIA et al, 2006
/books/book[author = "Montana Marigold"]/title
2.6 Expressões XQuery
XQuery é uma linguagem funcional, isto é, que consiste em expressões que podem ser compostas por operadores que utilizam termos ou sintaxe com aplicação de função que são totalmente combináveis, e portanto, em qualquer local onde uma expressão é esperada, qualquer tipo de expressão pode ser
utilizada, além disto, cada expressão retorna um valor único e não tem efeitos colaterais.
Em expressões mais complexas em que são aceitos tanto o uso de funções predefinidas quanto funções definidas pelo usuário, uma chamada para uma função é uma forma básica de expressão podendo conter nelas literais, referência à variáveis, expressões de contexto de item, construtores e chamadas para funções.
As expressões ficam fechadas entre parênteses elas e são constituídas basicamente de expressões que consistem de símbolos terminais e separadores de símbolos tais como aspas simples ou duplas para os valores literais e o sinal de dólar para as variáveis (W3C, 14/12/2010).
Para combinar e reestruturar informações de documentos XML são utilizadas expressões FLWOR. (JONATHAN ROBIE, 2004)
A expressão FLWOR é um dos mais importantes tipos de expressões do XQUERY, ela é a expressão que controla a iteração e ordenação. A expressão de iteração, busca, ligação e ordenação FLWOR, cujo nome vem das palavras-chave for, let, where, order by, return é a palavras-chave para integrar a parte da funcionalidade.
As expressões FLWOR são semelhantes às declarações select, from, where da linguagem SQL, mas elas não são definidas em forma de tabelas, linhas e colunas, pois elas ligam variáveis a valores nas cláusulas let e for e usa as variáveis que foram ligadas para gerar novos resultados e esses resultados são chamados de tupla. (Howard Katz et al, 2004)
Figura 6- Consulta FLWOR
for $book in doc("full-text.xml") /books/book let $title := $book/metadata/title
where $title contains text "improving usability" ordered distance at most 2 words at start return $title
2.7 XQuery Full Text: Extensão do XQuery para Lidar com Texto
Nos dias atuais, as informações são disponibilizadas das mais variadas formas possíveis, uma delas é a prática de manter informações por meio de uma ferramenta Web, que permite acrescentar informações de forma colaborativa a fim de difundir o conhecimento dentro das empresas ou instituições públicas, tal ferramenta é denominada wiki.
Dentro das wikis, os artigos estão no formato de texto desta forma o leitor ao fazer uma pesquisa precisa de uma ferramenta que localize de forma rápida um título ou uma palavra-chave sem que ele tenha que ler todos os artigos. Este é um exemplo de aplicação que encoraja o uso da linguagem de consulta XQuery Full Text, pois ela pode ser usada para consultar perfeitamente tanto a estrutura como conteúdo texto de documentos XML.
XQuery Full Text foi desenvolvido como uma extensão à linguagem de consulta XQuery definida na Seção 2.1,3. XQuery Full Text permite aos usuários combinar consultas Full Text com consultas XQuery / XPath regulares. A linguagem XQuery Full Text é uma linguagem funcional, pois ela utiliza funções como recurso de consulta. A expressão FTContainsExpr representa uma função que permite aos usuários pesquisar sobre nós XML combinando textos primitivos. A função FTContainsExprexpression permite
utilizar expressões FLWOR XQuery junto da função FTContainsExpr. O Anexo II apresenta um exemplo de consulta com expressões.
Figura 7- Consulta FTContainsExpr Fonte: AMER–YAHIA et al, 2006
//book[(metadataftcontains"usabilitytests")and (content/part/chapter/title ftcontains
"web-site usability")] /title
É possível tornar uma consulta mais específica ou mais detalhada por meio de uma busca aos outros nós, aprofundando na árvore por meio da mistura de XQuery com FTContainsExpr como na consulta da Figura 7 que retornará os títulos dos livros que contêm o termo "usability tests" e os títulos dos capítulos que tiverem a frase "web-site usability". FTSelection Expressions são usados para especificar a condição Full Text em uma expressão FTContainsExpr (AMER–YAHIA et al, 2006).
A tabela presente no Apêndice I apresenta as formas de seleção Full Text de acordo com a W3C (2011).
3 SGBD'S XML
Muitas aplicações de dados e conteúdos Web são armazenadas em um banco de dados relacional ou em arquivos de sistema, mas devido ao crescimento e troca do volume de dados estes métodos de armazenamento se tornaram ineficientes para acomodar conteúdo XML (ORACLE, 05/2008)
3.1 Oracle XML DB
Oracle XML DB é o nome dado para um conjunto de tecnologias
relacionadas a alta performance de armazenamento e retorno de XML.
Ele fornece suporte XML nativo pelo englobamento dos modelos SQL e
XML de forma interoperável. Ele oferece suporte para a W3C XML e
esquema de modelo de dados XML bem como, métodos de acesso padrão
para navegar e consultar XML por meio de características próprias, tais
como: um armazenamento independente, conteúdo independente e
linguagem de programação independente e infraestrutura para armazenar
e gerenciar dados XML. O repositório BD XML DB facilita esta
manipulação pelo gerenciamento de hierarquia dos documentos XML.
A respeito de manipulação de dados, o Oracle XML DB suporta
os principais padrões para atualização e transformação de dados XML, os
padrões incluem a recomendação W3C XPath e o padrão ISO-ANSI
SQL/XML. FTP, HTTP(S) e WebDav que podem ser usados para mover
conteúdos XML para dentro ou para fora do Banco de Dados Oracle.
Estas APIs fornecem acesso e manipulação de conteúdo XML contendo
Java, C e PL/SQL (ORACLE, 05/2008).
3.1.1 Oracle suporte ao XQuery Full Text
O Oracle Banco de dados XML foi o principal fornecedor a dar suporte a recomendação XQuery Full Text. A distribuição mais nova do XMLDB é a 12C e ela suporta os seguintes padrões W3C XQuery: Recomendação XQuery
1.0, Recomendação XQuery Facilidade de Atualização e a Recomendação XQuery e XPath Full Text 1.0 ( ORACLE, 26/06/2013).
A Tabela 1 apresenta as principais as compatibilidades do banco de dados Oracle XML com a W3C (ORACLE, 08/2008 e ORACLE, 05/2013). Tabela 1- Suporte Oracle
W3C Suporte
Oracle
W3C Suporte
Oracle
Match Options: Full-Text Operators
Semantics:
Language Option não FTOr sim
Wildcard Option sim FTAnd sim
Thesaurus Option sim FTUnaryNot sim
Stemming Option sim FTMildNot sim
Case Option - FTOrder sim
Diacritics Option - FTScope não
Stop Word Option não FTContent não
Extension Option - FTWindow sim
FTDistance sim
Logical Full-Text Operators:
FTTimes -
Or-Selection sim FTWords Sim
And-Selection sim FTWordsValue sim
Mild-Not Selection sim FTAnyallOption sim
Not-Selection não
FTIgnoreOption
NãoFTWeight
nãoFTScoreVar
não
FLWOR
Sim
XQuery Full Text pode ser utilizado em consultas de dados do tipo XML independentemente do modelo de armazenamento utilizado. O SGBD Oracle suporta expressões Full Text Contains. Ela realiza uma pesquisa de contexto especificando os itens para a busca e uma seleção Full Text que filtra os itens selecionando e seus casamentos.
3.1.2 Carga e Armazenamento de Dados e Processamento de Consultas
Os índices são um recurso essencial para otimizar consultas aos documentos XML. O tipo dados apropriado para armazenar XML no ORACLE XML DB é o XMLTYPE de forma que as tabelas e visões XMLTYPE podem ser indexadas usando XMLIndex, árvore B, função baseada e/ou índices de texto. Para realizar busca sobre dados cujo esquema é conhecido deve previamente ser criado um índice de texto. A seguir, será descrito o fluxo que representa processo de indexação de texto no Oracle XML DB.
O objeto denominado Armazenamento faz a leitura de como os documentos são armazenados no sistema de acordo com seu armazenamento de dados de preferência, em seguida, o fluxo passa através do objeto Filtro,
O Filtro pode ser especificado conforme a preferência, NULL_FILTER, AUTO_FILTER ou CHARSET_FILTER, não deve aplicar filtros em documentos plain text, HTML ou XML. Depois de ser filtrado, o texto marcado passa através do objeto Separador.
O Separador separa o fluxo em textos e em seções de informações, tais como, onde o fluxo de texto começa e termina. A informação da seção é passada diretamente para o motor de indexação que será usado depois do texto ter passado pelo objeto Vocabulário Linguístico.
O vocabulário linguístico tem a função de especificar a linguagem do texto a ser indexado.
O motor de indexação cria um índice invertido que mapeia os tokens para os documentos que os contêm. Nesta fase o Oracle Text usa a Lista de parada para especificar exclusão de palavras de parada ou temas de parada do índice. Oracle Text também usa o parâmetro definidos na preferência denominada lista de Palavras que diz ao sistema como criar o prefixo do índice ou o índice substring caso disponível (ORACLE, 04/2013).
Figura 8- Processo de indexação
O propósito dos índices de texto é fornecer um acesso rápido para uma passagem particular do texto dentro dos nós texto do XML, ou seja, ele indexa cadeias de caracteres Full Text, deste modo o padrão de índices de base de dados que geralmente utilizados, tais como, árvore B ou bitmap não sejam adequados para acessar partes particulares de um documento XML.
Existem dois tipos de índices apropriados para trabalhar com documentos XML no ORACLE XML DB são eles o XMLINDEX e o CONTEXT Índex.
O índice Full Text é o CONTEXT, ele é criado sobre uma coluna do tipo XMLTYPE e este habilita as funções SQL contains() e facilita a função XQuery XPATH ora:contains() para realizar busca sobre XML. Ele é um índice invertido onde cada palavra contém uma lista de documentos que contêm a mesma palavra. Por exemplo, após uma simples operação inicial de indexamento a palavra DOG deve ter uma entrada desta forma: DOG DOC1 DOC2 DOC5. Este processo também é conhecido como indexação por token. Veja um exemplo de criação de índice Full Text no Apêndice III (ORACLE, 02/2014).
O índice XML é o XMLINDEX, ele fornece em geral um índice específico que indexa a estrutura interna do dado XML. Ele é um tipo de índice lógico projetado especificamente para dados XML. Ele pode ser usado juntamente com qualquer outro índice; pode ser utilizado com XML baseados em schema ou não baseado em schema; pode ser usado com os armazenamentos desestruturados, híbridos, e BINARY XML; e também as expressões XPath devem ser conhecidas a priori para serem utilizadas nas consultas.
O XMLINDEX desestruturado se aplica em todas a expressões XPATH possíveis para o XML, isto é possível por meio de uma tabela de caminhos composto por nós do documento e um conjunto de índices secundários na tabela de caminhos. Assim o uso de um componente desestruturado sozinho pode levar a problemas de ineficiência envolvendo vários exames e self-joins das partes da tabelas para consultas que projetam partes estruturadas. Veja o exemplo de criação de índice XML no Apêndice III (ORACLE, 02/2014.).
Para um melhor tratamento dos dados durante a realização das consultas aos documentos XML, a escolha da forma de armazenamento apropriada é indispensável a fim de se obter um retorno satisfatório de dados. O Banco de Dados Oracle possui suporte para armazenar arquivos XML nos modelos de dados Binary XML, Estruturados e Desestruturados. OS dados Binary XML estão armazenados internamente utilizando LOB's, Large Objects, porém atualmente utiliza o armazenamento SecureFiles LOB. O limite de tamanho máximo para os LOB’s são de 8 para 128 TERABYTES, dependendo do seu tamanho de bloco do banco de dados (ORACLE, 06/2005).
O tipo de dado utilizado para Binary XML é o XMLTYPE. Com a introdução do XMLTYPE como tipo de dados foram fornecidas técnicas que facilitam a persistência do conteúdo XML dentro do banco de dados. Entre estas técnicas incluem a habilidade de armazenar documentos XML como uma coluna
ou tabela ou em um DB repositório XML, O XMLTYPE permite executar validações, operações e otimizações em conteúdos XML.
A natureza do dado XML e a forma como será utilizado definirá o formato do XMLTYPE pois dados altamente estruturados são denominados caso de uso data-centric, centrados nos dados e os dados altamente desestruturados são denominados document-centric, centrados no documento.
3.1.3 Limitações do Oracle XE
O Oracle XML Database Express é a versão gratuita do SGBD XML Oracle e por isto apresenta algumas limitações quando comparado com a versão paga da ferramenta. As principais limitações apresentadas neta versão:
Cada nó de texto ou valor de atribruto processado está limitado ao tamanho de 64 K bytes (ORACLE, 05/2008 B)
Limite de tamanho do identificador XML que suporta apenas identificadores XML que estejam no máximo entre 32767 bytes ou 4000 bytes, dependendo do tamanho do valor de inicialização do MAX_STRING_SIZE.
Limite de tamanho do repositório de arquivo no qual o tamanho máximo de um arquivo dentro do repositório é por volta de 4 gigabytes.
Limite de recurso de arquivo de configuração do Repository-Wide, pois não pode criar mais de 125 recursos de arquivos de configuração para Repository-Wide.
Exclusão de pastas recursivas: Não pode deletar mais de 50 níveis de pastas aninhadas usando opções para deleção recursiva.
Não tem compressão de coluna híbrida isto porque a compressão coluna híbrida que está disponível somente para Oracle Exadata Storage Server Software não pode ser usada com uma coluna XMLType que está armazenada como objeto relacional ou com uma tabela XMLTYPE. O XMLTYPE suporta
apenas compressões básicas e compressão por OLDP. Pode ser um dos fatores para a para o caso de a baixa performance.
Não tem encriptação em nível de coluna para XMLTYPE, ele possui apenas encriptação nível tablespace para todos os modelos de armazenamento XMLTYPE.
Não tem acesso XMLType sobre links de banco de dados como não suporta acesso remoto à tabelas ou colunas XMLType (ORACLE, 05/2013 A).
Oracle Database XE pode ser instalado qualquer máquina com qualquer número de CPU’s, armazena no máximo 11GB de dados de usuário, utiliza no máximo 1 GB de memória e utiliza apenas uma CPU na máquina hospedeira (ORACLE, 06/2014).
Esta versão é gratuita e está disponível nas plataformas Linux e Windows.(ORACLE, 09/2011).
3.2 SGBD XML Basex
Basex é um banco de dados XML de alta performance, escalável e é um processador de XQuery 3.0 com suporte às extensões Full Text. Ele está focado em armazenamento, consulta e visualização de XML grandes, documentos JSON e coleções.
Ele possui uma interface visual permite aos usuários explorar dados interativamente e avaliar consultas em tempo real.
3.2.1 Basex suporte ao XQuery Full Text
Basex fornece uma implementação da W3C das linguagens XPath 3.0 e XQuery 3.0 que estão intimamente ligadas ao armazenamento de banco de dados permitindo acessar fontes de dados locais e remotas.
O Basex foi o primeiro processador de consultas a oferece suporte completo para a recomendação W3C XQuery Full Text 1.0. O Basex trata as expressões Full Text por meio da comparação entre as strings de busca e entrada divididas em tokens. Muitas normalizações são entradas no processo de divisão em tokens, tais como, maiúsculas ou minúscula e acentos são removidos e uma linguagem opcional, linguagem de stemming será aplicada. Além disto os caracteres especiais, tais como espaços em branco e pontuações serão ignorados. O Basex possui biblioteca com suporte às linguagens inglesa e alemã. Ele disponibiliza um índice Full Text para poder manipular as mais variadas combinações de opções de casamento definidas na recomendação Full Text, por padrão a maior parte das opções se encontram desabilitadas.
A Tabela 2s apresenta as funcionalidades W3C suportadas pelo Basex (BASEX, 2014 ):
Tabela 2- Suporte Basex
W3C Suporte
Basex
W3C Suporte
Basex
Match Options: Full-Text Operators
Semantics:
Language Option Sim FTOr Sim
Wildcard Option sim FTAnd sim
Thesaurus Option sim FTUnaryNot Sim
Stemming Option Sim FTMildNot Sim
Case Option Sim FTOrder Sim
Diacritics Option Sim FTScope -
Stop Word Option Sim FTContent -
Extension Option não FTWindow Sim
FTDistance Sim
Logical Full-Text Operators:
FTTimes -
Or-Selection sim FTWords Sim
And-Selection sim FTWordsValue Sim
Mild-Not Selection - FTAnyallOption Sim
Not-Selection sim
FTIgnoreOption
-FTScoreVar
Sim
FLWOR
Sim
3.2.2 Carga e Armazenamento de Dados e Processamento de Consultas
O Basex oferece estratégias de execução diferentes para consultas XQFT, pois a escolha dependerá da entrada dos dados e da existência de um índice Full Text. O compilador de consultas tenta otimizar e acelerar a consultas por meio da aplicação de uma estrutura de índice Full Text sempre que for útil e possível. Um exemplo de criação de índice pode ser visto no Apêndice V
Existem três estratégias de avaliação disponíveis: a padrão, exame sequencial do banco de dados; uma avaliação baseada em índice Full Text e a híbrida que representa a combinação das duas estratégias anteriores (BASEX, 2014).
A estratégia exame sequencial requer que o documento seja escaneado sequencialmente, a expressão localpath, caminho local, começa a partir do nó raiz e atravessa todos os nós filhos. Cada elemento é passado no próximo passo para o filho, os elementos resultantes são filtrados pela expressão FTcontains.
A estratégia baseada em índice com inversão de caminho o otimizador de consultas irá reescrever e inverter a localização dos predicados e caminhos sempre que o acesso ao índice for possível. Esta abordagem é caracterizada como sendo de baixo para cima ao contrário da estratégia de exame sequencial. Primeiro o índice Full Text é acessado e depois faz o caminho de volta das folhas até a raiz passando pelos nós. A estratégia híbrida é a junção da avaliação sequencial com o uso de índice.
O Basex possui funções úteis tais como as funções que permitem acessar um índice diretamente. Os resultados de Full Text podem ser marcados com
elementos adicionais ou partes relevantes podem ser extraídas dos mesmos. (GRUN. C, GATH. S, HOLUPIREK. A, SCHOLL. M H, ca. 2000).
Quanto ao armazenamento, um banco de dados BASEX pode conter documentos XML e também arquivos binários. Eles são manipulados de forma uniforme: um caminho de banco de dados único serve como chave e os conteúdos podem ser retornados via comandos do banco de dados, XQuery ou as várias API’s existentes.
Os dados tipo binários são armazenados em seu formato original dentro de um subdiretório denominado raw. A boa performance do Basex se deve ao fato dos arquivos de sistema geralmente executarem muito bem quando eles vêm para a atualização e o retorno dos arquivos binários. O foco do Basex está no armazenamento eficiente da estrutura dos dados hierárquicos e formatos de arquivos tais como XML ou JSON (BASEX, 2012).
3.2.3 Basex limitações
As limitações apresentadas pelo Basex são os limites de performance e chaves. Muitos arquivos de sistemas não são capazes de manipular milhares ou milhões de recursos binários em um diretório único de forma eficiente, isto ocorre quando existe um grande número de documentos XML que precisam ser importados para o banco de dados Basex ou exportado dele. A solução para evitar o gargalo é distribuir os binários relevantes em subdiretórios adicionais. O Basex não suporta o uso de chaves no sistema de arquivo corrente e a solução para a questão das chaves é adicionar um documento XML dentro do banco de dados que contenha o mapeamento de todos pares palavra_chave/caminho. (BASEX, 2012).
3.3 MXQUERY
MXQUERY é uma ferramenta de busca XQuery de código aberto
para trabalhar com dados XML . MXQuery possui alguns diferenciais por
suportar grande variedade de plataformas por ser implementado em Java.
Ela fornece uma ampla cobertura os padrões mais atuais da W3C como
XQuery 3.0, scripting. Ela possui um compilador cruzado da plataforma
Java, isto permite ao compilador produzir um código executável para
uma plataforma diferente da de criação, ideal para uso pelo navegador de
internet. Ela também possui processamento de streaming de dados
(MXQuery, ca. 2000 ).
MXQuery foi desenvolvido para ser uma máquina XQuery para
rodar em dispositivos móveis. Para isso, é existe uma integração com
modelo de aplicação Android usando a classe import do java para isto
(Sync/Async/Service)e também a habilidade de para chamar
funcionalidade de plataforma Android usando a classe Java Import. Para
manter o uso de memória baixo a máquina MXQuery inicialmente
suportou apenas um subconjunto de XQuery, não suportava tipos
definidos pelo usuário e nem a tipificação completa do sistema XQuery
restringindo–se apenas a um subconjunto de tipos atômicos
como xs:untypedAtomic, xs:string. Isto reduz o tamanho de armazenamento e memória da máquina consideravelmente (MXQUERY, 2008).3.3.1 MXQUERY suporte ao XQuery Full Text
MXQuery está parcialmente em conformidade com XPath/XQuery FullText 1.0, conforme Tabela 3. (MXQUERY, 2009).
Tabela 3- suporte MXQUERY
W3C Suporte
MXQUERY
W3C Suporte
MXQUERY
Match Options: Full-Text Operators
Semantics:
Language Option Não FTOr Sim
Wildcard Option Sim FTAnd Sim
Thesaurus Option Não FTUnaryNot Sim
Stemming Option Sim FTMildNot Sim
Case Option Sim FTOrder Sim
Diacritics Option Sim FTScope -
Stop Word Option
Sim FTContent -
Extension Option - FTWindow Sim
FTDistance Não
Logical Full-Text Operators:
FTTimes Não
Or-Selection Sim FTWords Sim
And-Selection Sim FTWordsValue Sim
Mild-Not Selection
Não FTAnyallOption Sim
Not-Selection Não
FTIgnoreOption
NãoFTWeight
NãoFTScoreVar
Não
3.3.2 Carga e Armazenamento de Dados e Processamento de Consultas
Figura 9- Processamento de consulta
Sobre máquina XQuery streaming a Figura 9 pode dar uma visão geral de seu funcionamento. Uma aplicação java submete consultas XQuery e os resultados da consulta consumida através de uma interface referida como XDBC.
O compilador de consulta faz o parse (análise da palavra) e a otimização da consulta. O compilador gera um plano de consulta, que é uma árvore de operadores que consomem dados de um outro em cascata de moda. O plano de consultas é interpretado pelo sistema de tempo de execução que consiste da implementação de todas as funções e operadores da biblioteca XQuery e do núcleo XQuery.
Além disso o sistema de tempo de execução contém um analisador XML e um validador de esquema que são requeridos quando um dado XML externo deve ser processado como parte da consulta. As mensagens de entrada XML são analisadas e tem seu esquema validado uma única vez e então é armazenado em um formato especial para que então ele possa ser utilizado em muitas consultas XQuery sem que se tenha que realizar todos esses passos para cada consulta invocada.
As mensagens são limitadas como variáveis livres para consultas e variáveis de ligação são também para executadas por meio da interface XDBC. Todos os dados XML são interpretados como uma corrente de tokens. Estas corrente de token minimiza as exigências de memória da máquina.
Em adição, a corrente de token permite a avaliação postergada das consultas (referenciada como lazy pelo autores). Em tempo de execução cada operador runtime recebe como entrada um tokens por vez e os dados que não são requeridos são descartados. A corrente de tokens corresponde (casa) com o modelo de dados ( FLORESCU et al., Ca 2000).
O MXQuery é um modelo de iterador pull-based, um ponto forte deste tipo de protocolo de streaming é a simplicidade que faz dele uma opção para muitos sistemas de streaming do mundo real. A característica principal é que o protocolo inclui (buffer map exchanges) mapa de trocas armazenamento periódico e falta de programação centralizada. Esta característica contribui muito para a simplicidade do protocolo pull-based mesh (engrenagem baseada em puxar), mas ao mesmo tempo conduz para uma brecha entre os limites fundamentais e a performance atual ( CHEN FENG, BAOCHUN E LI, BO LI, Ca. 2000).
A representação de dados usados internamente é uma sequência de tokens chamado de corrente de token (token stream) que é um modelo de corrente de tokens tipificados em XMLe acessado via uma API pull-based para
produzir e consumir tokens vagarosamente. Além do mais os tokens para começo de documento, elementos, ou atributos são aumentados para carregar os ids dos nós a fim de comparar nós por ambos igualdade e ordenação de documentos (DIAO, Ca 2000).
Esta abordagem apresenta algumas vantagens tais como: baixo requerimento de memória principal, evita a materialização de modularidade resultados intermediários, suporta avaliação postergada, Lazy que é muito importante para streamings infinitas que já foram testadas pela máquina ( TSOULO, 2008).
Quanto ao armazenamento de dados o MXQUERY a fonte de dados pode ser um esquema XM ou um arquivo (VAKALI, A. ,PALLIS, G, 2007).
3.3.3 MXQUERY limitações
O MXQUERY não da suporte completo ao XQuery, as expressões de ordenação, agrupamento e extensões variáveis de itens e de contexto externo não se aplicam no momento. Com relação ao Full Text ele também não fornece suporte de forma completa porque as funções scoring e Weights não estão implementadas. Não atendem satisfatoriamente: Seleção de armazenamento automático Fine-grained, Mistura atualizável de armazemanmento de streaming e Full Text dentro do mesmo módulo de consulta, Melhorias da performance, CPU e memória (MXQUERY, Ca 2000).
3.4 SGBD IBM DB2
O DB2 Express-C é a versão gratuita de um dos sistemas de gerenciamento de banco de dados da IBM. O DB2 Express-C 9.7 está disponível
para Linux, Unix, Windows e até mesmo Mac OS X. Para lidar com XML utiliza uma tecnologia denominada pureXML. (DB2 Express-C, Ca 2000).
3.4.1 IBM DB2 Suporte ao XQuery Full Text
A funcionalidade do IBM DB2 para realizar consultas XQuery Full Text é conhecida como DB2 Text Search, a qual habilita um usuário do banco de dados IBMDB2 para Linux, UNIX e Windows criarem aplicações com capacidade de busca Full Text por meio da adição de cláusulas Full Text nas declarações SQL e XQuery. DB2 Text Search possibilita fazer busca em dados estruturados e desestruturados armazenados no banco de dados, tais como busca Full Text em textos, HTML e documentos XML. SQL completamente integrado, SQL/XML, suporte XQuery, incluindo sintaxe XPath e subconjuntos para busca em documentos XML (IBM, Ca 2000). .
A fim de alcançar boa performance e escalabilidade DB2 Text Search faz uso de streaming para evitar o alto consumo de recursos durante as consultas.
Tabela 4- suporte DB2
W3C Suporte
DB2
Match Options: Full-Text Operators
Semantics:
Language Option Sim FTOr Sim
Wildcard Option Sim FTAnd sim
Thesaurus Option Sim FTUnaryNot Sim
Stemming Option Sim FTMildNot Não
Case Option - FTOrder Sim
Diacritics Option Sim FTScope -
Stop Word Option Sim FTContent -
Extension Option - FTWindow Sim
FTDistance Sim
Logical Full-Text Operators:
FTTimes -
Or-Selection Sim FTWords Sim
And-Selection Sim FTWordsValue
-Mild-Not Selection Não FTAnyallOption -
Not-Selection Sim
FTIgnoreOption
-FTWeight
-FTScoreVar
Sim
FLWOR
Sim
As funções disponíveis para busca Full Text são as consultas com palavras ou frases usando CONTAINS() ou xmlcolumn-contains() (IBM, Ca 2000).
3.4.2 Carga e Armazenamento de Dados e Processamento de Consultas
No DB2 há disponível o suporte à indexação de dados armazenados em colunas XML, os índices XML indexam parte de uma coluna onde indica que partes de uma coluna será indexada especificando um padrão limitado por uma expressão XPath (IBM, 2013).
O índice de texto pode ser criado sobre uma variedade de tipos de dados de VARCHAR pequenos até BLOB’s grandes que contenham objetos texto. Em um documento XML o índice pode ser criado para elementos, atributos ou valores, nós textos (DB2 Express-C, Ca 2000).
Um índice text search consiste de termos significantes que são extraídos dos textos de documentos. A chave primária da linha da tabela é usada no index para identificar a fonte dos termos (IBM, Ca 2000).
O DB2 armazena os dados XML nativamente, ou seja, ele utiliza o modelo de dados hierárquicos do XML para armazenar e processar XML internamente. Não existe mapeamento para o modelo relacional, os documentos XML não são convertidos em strings (CLOB ou VARCHAR)..
Dados relacionais e dados hierárquicos podem ambos ser armazenados no DB2 banco de dados híbrido. Os dados relacionais são acessados utilizando SQL ou XQuery, os dados XML podem ser acessados usando SQL/XML ou XQUERY (IBM, Ca 2000).
3.4.3 IBM DB2 limitações
O DB2-Express-C oferece partilhamento do mesmo código fonte
das edições comerciais, limites de 2 Cores (1 CPU) , 2 GB de RAM,
Sem limites de tamanho da base de dados, Sem limites de conexões e
Sem limites de usuários ou quaisquer outros limites
(DB2 Express-C, Ca 2000).O servidor DB2 Text Search não é instalado por padrão juntamente com o servidor de banco de dados DB2, pois ele requer a execução de uma configuração stand alone para que o Text serch seja habilitado.
4 METODOLOGIA
Nesta seção serão explicados os critérios utilizados para a criação do ambiente de testes nos quais os dados, os SGBD's, os procedimentos de execução das tarefas e as informações obtidas após este processo serviram de subsídio para realizar a avaliação de facilidade de uso, funcionalidade e desempenho dos SGBD's.
Dentro da perspectiva da facilidade de uso dos SGBD's buscaremos avaliar as dificuldades sob o ponto de vista de uma equipe técnica de uma empresa sem o auxílio direto do suporte técnico especializado in loco. Neste contexto, este suporte através de canais virtuais como fóruns e listas de e-mail também será um critério de avaliação.
No que diz respeito à funcionalidade buscaremos avaliar o suporte ao Full Text entre os SGBD's com o intuito de descobrir o quão adequados eles estão com a recomendação de XQuery Full Text de acordo com a W3C.
A avaliação de desempenho consiste to tempo de resposta obtidos dos SGBD's no contexto de uma carga maior de dados, a fim de explorar o potencial máximo das consultas sobre um volume de dados alto.
4.1 Classificação
Nesta seção apresentaremos a classificação da pesquisa.
A presente pesquisa se classifica quanto à natureza como básica, quanto aos objetivos de forma descritiva, quanto às abordagens como pesquisa qualitativa e quantitativa. Para a colimação dos objetivos deste trabalho, os seguintes passos foram realizados:
para a revisão bibliográfica buscamos informações atualizadas do momento em que os testes foram realizados.
para estudar o suporte às funcionalidades do XQuery Full Text em SGBD's XML comerciais e de código aberto foram consultadas as documentações dos SGBDXs escolhidos;
para construir de um ambiente de testes para comparação entre SGBD's XML que caracterizassem cenários reais de aplicações baseadas em dados semiestruturados trabalharemos na configuração do ambiente, na coleta de dados reais e na definição do conjunto de consultas a serem usadas nos testes; para avaliar e comparar o desempenho e as funcionalidades dos
dois SGBD's XML que suportam XQuery Full Text utilizamos uma tabela com valores ponderados de avaliação e comparação. As bases de dados que foram utilizadas a serem utilizadas como métrica para avaliação do XQuery Full Text são:
O caso de uso da W3C, XQuery and XPath Full Text 1.0, forneceu modelos de consultas em documento XML e o INEX, Iniciativa para avaliação de recuperação de informação XML, forneceu a coleção de dados da wikipédia.
. Teremos por objeto de avaliação dos SGBD's XML: BASEX e MXQUERY, de código aberto (BASEX, 2012. MXQUERY, 2009 ). e o SGBD's proprietários Oracle XML Database e IBM DB2(ORACLE, 2013. IBM,2013).
A seguir, apresentaremos mais detalhes a respeito das avaliações de funcionalidade e desempenho.
4.2 Hardware
Nesta seção apresentaremos os equipamentos técnicos que serviram para o desenvolvimento deste trabalho.
Para construir de um ambiente de testes que tornasse possível realizar a comparação entre SGBD's XML que caracterizassem cenários reais de aplicações baseadas em dados semiestruturados foi utilizado um servidor plataforma Ubunto Línux. A configuração da máquina era de 8GB DE RAM e 1 TB de HD.
4.3 Instalação
Basex: foi instalado com sucesso sem nenhuma complexidade apresentada durante o processo de instalação.
IBM DB2: foi instalado parcialmente porque a ferramenta DB2 Text Search a qual habilita busca full text não estava inclusa na instalação padrão, por isto foi necessário executar a instalação da mesma de forma stand alone, o tutorial disponível é muito complexo e nem um pouco didático.
MXQUERY: foi instalado com sucesso e o processo de instalação não apresentou nenhuma complexidade.
ORACLE XML DB: foi instalado com sucesso sem apresentar problemas.
4.4 Importação
Basex: para realizar a importação de dados para o Basex foi realizada a referenciação do diretório no sistema de arquivos no SGBD no momento da criação do banco a validação dos dados pode ser habilitada nos parâmetros do SGBD.
IBM DB2: A importação é por meio de comandos e o arquivo XML foi importado para o banco sem apresentar restrições ou erros. O SGBD exigiu
tratamentos dos dados e por isso foi necessário alterar alguns caracteres como aspas simples por dupla e vice-versa para depois executar a importação.
MXQUERY: A importação dos dados também foi simples, este processo é composto pela referenciação do local do diretório do arquivo XML na máquina que é passado como parâmetro dentro da consulta, o que causou um pouco de transtorno foi no momento da importação da coleção de arquivos XML, pois devido ao MXQUERY não fornecer na sua documentação os comandos para criar collections iria inviabilizar realizar a consulta sobre os 26.416 arquivos. A fim de contornar esta deficiência do MXQUERY e poder prosseguir com o trabalho foi criado um arquivo XML único composto por todos os arquivos da base de dados.
4.5 Teste de Funcionalidade
Nesta seção será apresentada a descrição dos dados e das consultas utilizadas durante os teste de funcionalidades.
A base de dados foi composta por uma amostra de dados de uma coleção de apenas três livros que foram coletados do caso de uso XQuery e XPath Full Text 1.0 que estão disponíveis em W3C (2011). O caso de uso XQuery e XPath Full Text 1.0 é composto por um modelo de dados XML, uma lista de consultas mais o retorno delas. O documento XML pode ser visualizado no Anexo I e as consultas escolhidas para serem utilizadas nos teste se encontram mais adiante nesta mesma seção.
Para preparar para ambiente de teste de funcionalidades foram utilizados Casos de Uso XML Full Text para que que tivéssemos cenários de usos de consultas com possíveis soluções em XQuery e XPath,. dentre estas consultas foram selecionadas dez consultas a fim de compor um conjunto de consultas Full Text. Os casos de uso forneceram além do um arquivo XML das consultas,
exemplos de entradas de dados, tais como, funções, características dos textos suportados em XQuery e XPath, ilustrando consultas simples e complexas mais suas respectivas saídas de dados.
A escolha das consultas que foram utilizadas na construção do ambiente testes foram escolhidas mediante o seguinte critério: intenção de aplicar consultas coerentes com realidade de uma organização que gostaria de extrair dados de documentos XML, desta forma classificamos as consultas dentro das categorias simples, medianas e complexas conforme exibido na Figura 15 .
As consultas 1,2 e 3 foram consideradas simples porque representam buscas por uma palavra ou uma simples frase.
As consultas 4,5, e 6 foram consideradas medianas porque são compostas por uma consulta mais avançada por conter declarações de expressões FLWOR e FTSelections.
AS consultas 7,8,9 e 10 foram consideradas complexas porque além de conterem declarações presentes nas consultas simples e medianas elas possuem variáveis, wildcards, e consulta em atributo.
Figura 10 - Consultas de Funcionalidade
Consultas Simples
Q1 2.2.1 Q1- Encontrar todos os títulos de livro que contém a palavra "usability". Esta consulta encontra uma palavra em um elemento.
doc("full-text.xml") /books/book/metadata/title[. contains text "usability"] Q2 2.2.2 Q2 - Encontrar todos os assuntos dos livros que contenham a frase
"usability testing".Esta consulta encontra uma frase em um elemento. doc("text.xml") /books/book/metadata/subjects/subject[. contains text
"usability testing"]
Q3 3.2.6 Q6 - Encontrar alguma palavra "mouse" em todos os livros. Esta consulta busca em todo o documento.
doc("full-text.xml")[. contains text "mouse"]/books/book Consultas medianas
Q4 2.2.6 Q6 - Encontrar todos os títulos de livro que começam com "improving" seguida de 2 palavras pela "usability". Esta consulta encontra um elemento que começa com uma palavra específica.
for $book in doc("full-text.xml") /books/book let $title := $book/metadata/title
where $title contains text "improving" ftand "usability" ordered distance at most 2 words at start
return $title
Q5 10.2.5 Q5 Busca And Not. Encontrar todos os livros com a palavra "usability" e não tenham a palavra "plan" no metadata.
for $book in doc("ull-text.xml") /books/book let $up := $book/metadata
where $up contains text "usability" ftand ftnot "plan" return $book
Q6 16.2.1 Q1 - Full-Text Query construção de um novo elemento. Para os livros que contêm “usability” no título será criada uma lista rasa de todos pares título-autor. Cada par estará agrupado no elemento novo construído. for $book in doc("full-text.xml") /books/book
let $var := $book/metadata/title where $var contains text "usability"
return <result>{$book/metadata/title, $book/metadata/author} </result>
Consultas complexas
Q7 4.2.1 Q1 - Encontrar todos os livros com as palavras "improve" "web" "usability" no short title. Esta consulta busca por palavras múltiplas em um atributo permitindo palavras variantes e permitindo a palavra em qualquer ordem com um número máximo especificado de palavras no meio. for $book in doc("full-text.xml") /books/book
where $book/metadata/title/@shortTitle contains text "improve"
using stemming ftand "web" ftand "usability" distance at most 2 words return $book/metadata/title
Q8 6.2.1 Q1 - Encontrar todos os títulos de livro que contém a palavra "test" no texto. Esta consulta encontra uma palavra e suas variantes (derivadas) for $book in doc("full-text.xml") /books/book
let $cont := $book/content
return $book
Q9 10.2.4 Q4 - Encontrar em todos os livros a coleção que não contenha "usability testing". Esta consulta busca por livros que não contenham uma frase em um elemento e em seus descendentes.
for $book in doc("full-text.xml") /books/book
where $book contains text ftnot "us.* testing" using wildcards return $book
Q10 12.2.2 Q2 - Encontrar todos os livros com as palavras "efficient task completion".Esta consulta busca por palavras múltiplas em um atributo permitindo palavras variantes e permitindo a palavra em qualquer ordem com um número máximo especificado de palavras no meio ordenados. for $book in doc("full-text.xml") /books/book
let $cont := $book/content
where $cont contains text "efficient" ftand "task" ftand "completion" ordered distance at most 10 words
return $book
4.6 Teste de Desempenho
O benchmark é executado em vários sistemas diferentes ranqueando os resultados dos custos e performance de cada sistema submetido, baseando se pela carga de trabalho medida usualmente em trabalho/segundo ou transação/segundo. (GRAY, 1993).
No presente trabalho adotamos o modelo de Gray (1993), aplicando o benchmark nos SGBD's Basex, MXQUERY, IBM DB2 e ORACLE XML DB. O conjunto de dados consiste de dados compostos por um conjunto de arquivos XML, para isto o tamanho representado pela carga de dados foi uma das preocupaões. Os dados para compor o conjunto de dados a serem importados foram obtidos da base de dados de arquivos XML criada pelo INEX. O INEX tem por objetivo fornecer grandes coleções de documentos com informações
relevantes que possibilitem realizar a avaliação sobre ferramentas de retorno de informação.
Dentre as coleções disponíveis, a coleção denominada Wikipedia 2009 cosiste de 14 GB e um total de até 32311 tags distribuídas entre os arquivos. Contudo para cada 1GB de dados seriam necessários 4 GB para processá-los. Esta foi a base de dados selecionada para compor dos experimentos, juntamente com a coleção de dados foi adquirido o arquivo 2009 Topics 2009001-2009115 (v1.0) e o qrels.txt .
O arquivo Topics contém informações relevantes sobre a coleção de dados, tais como os assuntos relacionados aos artigos que se encontram no conjunto de dados e uma estrutura que mostra onde aquele assunto pode ser encontrado dentro da hierarquia dos nós dos XML apresentada como XPath. Para certificar de que a a palavra-chave ou o a frase citada em TOPICS está realmente no diretório dos arquivos, para isto pode ser utilizado o documento qrels.txt . Cada tópico contido no arquivo TOPICS tem um número de id que está também no arquivo qrels.txt seguido de alguns números, nesses números, os três últimos algarismos do id representa pastas onde o documentos que contêm as palavras-chaves poderão ser encontrados. As demais colunas representam o número do documento XML e a posição da palavra. (INEX, Ca. 2000).
O teste de desempenho foi realizado sobre uma parte da coleção Wikipédia 2009 composta por 26.416 arquivos que representam 512 MB em dados armazenados .Estes arquivos foram modificados para atender os requisitos de importação exigidos pelos SGBD's tais como, alterações nos caracteres HTML para o hexadecimal dos mesmos e a primeira linha de comentário foi excluída.
A criação das consultas para o teste de desempenho tiveram como base as consultas do teste de funcionalidade de forma que foram adaptadas para o
