Arquivo em PDF - DCC

Propaganda

UNIVERSIDADE FEDERAL DE GOIÁS – UFG
CAMPUS CATALÃO – CaC
DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO – DCC
Bacharelado em Ciência da Computação
Projeto Final de Curso
Armazenamento de Dados XML: Técnicas de
Benchmark para avaliação
Autor: Nádia Félix Felipe da Silva
Orientador: Ms. Márcio de Souza Dias
Catalão - 2007
Nádia Félix Felipe da Silva
Armazenamento de Dados XML: Técnicas de Benchmark para avaliação
Monografia apresentada ao Curso de
Bacharelado em Ciência da Computação da
Universidade Federal de Goiás Campus Catalão
como requisito parcial para obtenção do tı́tulo de
Bacharel em Ciência da Computação
Área de Concentração: Banco de Dados
Orientador: Ms. Márcio de Souza Dias
Catalão - 2007
S. Félix Felipe da, Nádia
Armazenamento de Dados XML: Técnicas de Benchmark para avaliação/Ms.
Márcio de Souza Dias- Catalão - 2007
Número de paginas: 134
Projeto Final de Curso (Bacharelado) Universidade Federal de Goiás, Campus
Catalão, Curso de Bacharelado em Ciência da Computação, 2007.
Palavras-Chave: 1. Dados semi-estruturados. 2. XML. 3. Benchmarks
Nádia Félix Felipe da Silva
Armazenamento de Dados XML: Técnicas de Benchmark para avaliação
Monografia apresentada e aprovada em
de
Pela Banca Examinadora constituı́da pelos professores.
Ms. Márcio de Souza Dias – Presidente da Banca
Ms. Márcio Antônio Duarte
Wisner Antônio Marques
À minha famı́lia, em e special meus pais, que souberam entender minha ausência. Aos
meus amigos e meu orientador Márcio de Souza Dias.
AGRADECIMENTOS
Primeiramente agradeço infinitamente a Deus, pelo dom e graça da vida, tenho convicta certeza que sem Ele seria impossı́vel concluir este trabalho. Agradeço incessantemente aos meus pais, Dioclemar e Iva, irmãos e aos meus sobrinhos Ana Júlia e João
Antônio, pela certeza de que frutos seriam colhidos, bastaria para isso dedicação.
Agradeço também ao meu orientador Márcio de Souza Dias, por abdicar muitas vezes
de horas de descanso e por ter me dado todo suporte necessário a conclusão deste. É
inevitável citar ainda os amigos João Luiz, Liliane, Clayton, Wellington, Francilene,
Luiz Carlos e Leonardo, fontes de apoio e insentivo na busca contı́nua pelas respostas
necessárias a este trabalho.
Agradeço ainda à professora Cristiane de Fátima dos Santos, pelo apoio e decisão pelo
tema deste projeto.
Aos amigos e colegas de trabalho da Unimed Catalão pelo apoio, em especial ao meu
grande amigo Adercley.
Se torna difı́cil citar todos os nomes, uma vez que, pela graça de Deus, foram várias
as pessoas que estiveram ao meu lado, me consolando nos momentos difı́ceis e me incentivando quando necessário. Obrigado a todos pelo apoio. Esta vitória não é minha, é
nossa.
”Nada te perturbe, nada te espante... Tudo passa. A paciência tudo alcança! A quem
tem Deus nada falta.” Santa Tereza D’ávila.
”A vida é para nós o que concebemos dela. Para o rústico cujo campo lhe é tudo,
esse campo é um império. Para o César cujo império lhe ainda é pouco, esse império
é um campo. O pobre possui um império; o grande possui um campo. Na verdade, não
possuı́mos mais que as nossas próprias sensações; nelas, pois, que não no que elas vêem,
temos que fundamentar a realidade da nossa vida.”
Fernando Pessoa
RESUMO
Silva, N. Armazenamento de Dados XML: Técnicas de Benchmark para avaliação.
Curso de Ciência da Computação, Campus Catalão, UFG, Catalão, Brasil, 2007, 134p.
A Internet vem gradativamente ganhando destaque ao ser usada como veı́culo de
intercâmbio de informações. Têm sido objeto de estudo de grandes ciêntistas, os quais
buscam melhorar esse intercâmbio, tornando o mais leve e eficiênte. Os dados produzidos
neste contexto são conhecidos por apresentar caracterı́sticas semi-estruturadas, ou seja,
uma informalidade na sua organização. Um tipo de dado semi-estruturado e de grande
aceitação neste cenário é o XML (eXtensible Markup Language), um formato que caminha
para ser considerado um padrão nesse meio, sendo fortemente utilizado por aplicações
diversas, como intercâmbio e integração de dados. Com o aparecimento da XML surge a
necessidade de prover meios para manipulação e armazenamento desse tipo de informação,
uma vez que são dados com caracterı́sticas particulares e diferenciadas, não podendo
simplesmente ser aplicados técnicas de gerenciamento com Bancos de Dados tradicionais
sem algum pré-processamento. Deste modo, este trabalho busca estabelecer o Estado
da Arte do armazenamento de dados XML, os tipos de bancos de dados existentes, suas
particularidades, vantagens e desvantagens, e também apresentar ao leitor as ferramentas
existentes no mercado para a realização de uma análise comparativa automatizada entre
Bancos de Dados XML, utilizando técnicas de avaliação e de softwares de benchmarks
(softwares voltados a testar o desempenho de um sistema por meio de comparações e
métricas estabelecidas).
Palavras-Chaves: Dados semi-estruturados, XML, Benchmarks
i
Sumário
1 Introdução
1
2 Armazenamento de Informações - Definições
4
2.1
Caraterı́sticas Fundamentais acerca dos Bancos de Dados . . . . . . . . . .
5
2.1.1
Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.2
Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.3
Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.4
Arquitetura do Sistema de Banco de Dados
2.1.5
Linguagens de Banco de Dados . . . . . . . . . . . . . . . . . . . . 13
. . . . . . . . . . . . . 10
3 Histórico e Desenvolvimento dos Bancos de Dados
3.1
17
Do surgimento da Escrita à automação do processo de armazenamento . . 17
3.1.1
Processamento manual de dados (papel e lápis) . . . . . . . . . . . 17
3.1.2
Surgimento dos Computadores, cartões perfurados e máquinas eletromecânicas para ordenar e tabular registros . . . . . . . . . . . . . . 18
3.1.3
Fitas magnétivas, Sistemas de Arquivos . . . . . . . . . . . . . . . . 20
3.1.4
Os primeiros SGBD’s da Década de 70 - Modelos Hierárquicos, Modelo em Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2
3.3
3.1.5
Meados da Década de 80 - Modelo Relacional . . . . . . . . . . . . 24
3.1.6
Final da Década de 80 até atual . . . . . . . . . . . . . . . . . . . . 25
A internet no contexto de armazenamento de informações . . . . . . . . . . 27
3.2.1
Uma mudança de paradigma . . . . . . . . . . . . . . . . . . . . . . 28
3.2.2
Linguagens de Marcação no Contexto de Armazenamento . . . . . . 31
Bancos de Dados para documentos XML . . . . . . . . . . . . . . . . . . . 34
4 Dados - Sua Representação, sua estruturação e a utilização de XML
4.1
36
Classificação de Dados apartir de sua representação Estrutural . . . . . . . 37
4.1.1
Dados Estruturados . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.2
Dados Não Estruturados . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.3
Dados Semi - Estruturados . . . . . . . . . . . . . . . . . . . . . . . 38
ii
4.2
A estrutura de um documento XML . . . . . . . . . . . . . . . . . . . . . . 41
4.3
DTD(Document Type Definition) . . . . . . . . . . . . . . . . . . . . . . . 43
4.4
XML Schema Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1
Representação - Árvores XML . . . . . . . . . . . . . . . . . . . . . 48
4.5
Documentos Centrados em Dados e Documentos Centrados em Documentos 49
4.6
Banco de Dados para documentos XML
. . . . . . . . . . . . . . . . . . . 50
4.6.1
Banco de Dados Relacional habilitado para receber dados XML . . 51
4.6.2
XML Native Databases ou (Sistemas de Banco de Dados Nativos
em XML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.3
Caracterı́sticas de SGBDs XML Nativos . . . . . . . . . . . . . . . 60
4.6.4
Principais Vantagens em trabalhar com bancos de dados relacionais
4.6.5
Principais Desvantagens em trabalhar com bancos de dados relacionais
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6.6
Principais Vantagens em trabalhar com Banco de Dados XML . . . 69
4.6.7
Principais Desvantagens em trabalhar com Banco de Dados XML . 69
5 Benchmark em Bancos de Dados XML
5.1
5.2
67
71
Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.1
XOO7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.2
XMach-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.3
XBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1.4
XMark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.5
MBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1.6
XCheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.7
Um comparativo entre os Benchmarks apresentados . . . . . . . . . 87
Bancos de Dados escolhidos para o Estudo de Caso . . . . . . . . . . . . . 89
5.2.1
BD nativo escolhido: eXist . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.2
BD com suporte a XML escolhido: Oracle 9i . . . . . . . . . . . . . 93
5.2.3
XCheck - o benchmark escolhido . . . . . . . . . . . . . . . . . . . . 93
5.2.4
Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.5
Trabalhos Futuros
. . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6 Conclusão
100
Referências
103
Apêndices
108
iii
A XCheck
109
A.1 Descrição do processo de instalação . . . . . . . . . . . . . . . . . . . . . . 109
A.1.1 Fase de análise dos dados
. . . . . . . . . . . . . . . . . . . . . . . 119
A.2 Como adaptar o XCheck para receber outros BD’s . . . . . . . . . . . . . . 119
B eXist
121
B.1 Descrição do processo de Instalação . . . . . . . . . . . . . . . . . . . . . . 121
B.2 Alguns conceitos sobre eXist . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C Oracle XML
126
C.1 Descrição do Processo de Instalação . . . . . . . . . . . . . . . . . . . . . . 127
C.2 Alguns conceitos sobre Oracle . . . . . . . . . . . . . . . . . . . . . . . . . 131
iv
LISTA DE ABREVIATURAS E SIGLAS
XML - eXtensible Markup Languagem
BD - Banco de Dados
DBA - Administrador de Banco de Dados
SGBD - Sistema Gerenciador de Banco de Dados
DBMS - Database Management System
DDL - Data Definition Language
DML - Data Manipulation Language
SQL - Structured Query Language
ISAM - Indexed Sequential Access Method
VSAM - Virtual Storage Access Method
IMS - Information Menagement Systems
OO - Orientado ao Objeto
DARPA - Defense Advanced Research Projects Agency
TCP - Transmission Control Protocol
IP - Internet Protocol
GML - Generalized Markup Language
SGML - Standard Generalized Markup Language
HTML - HyperText Markup Language
W3C - World Wide Web Consortium
DTD - Document Type Definition
XSD - XML Schema language
CLOB - Character Large Objects
XQL - XML Query Language
XPATH - XML Path Language
SUT - System Under Test
GNU - General Public Licence
CPU - Central Processing Unit
GPL - General Public Licence
LGPL - Lesser General Public Licence
v
Lista de Figuras
2.1
O Dado processado gera Informação
. . . . . . . . . . . .
6
2.2
Acesso ao banco de Dados . . . . . . . . . . . . . . . . . .
7
2.3
Sistema Gerenciador de Banco de Dados . . . . . . . . . .
9
2.4
Os três nı́veis da arquitetura . . . . . . . . . . . . . . . . .
11
2.5
Arquitetura Detalhada do Sistema . . . . . . . . . . . . . .
13
3.1
Cartões Perfurados . . . . . . . . . . . . . . . . . . . . . .
19
3.2
Máquina de Cartões Perfurados . . . . . . . . . . . . . . .
19
3.3
Modelo de Banco de Dados Hierárquico . . . . . . . . . . .
22
3.4
Modelo de Banco de Dados em Rede . . . . . . . . . . . .
23
3.5
Modelo de Banco de Dados Relacional . . . . . . . . . . .
25
3.6
Arquitetura tradicional de banco de dados Cliente/Servidor
29
3.7
Arquitetura de Aplicação com Base na WEB . . . . . . . .
30
3.8
Evolução dos Bancos de Dados até a necessidade de Bancos
de Dados especiais para documentos XML[Santiago, 2004]
35
4.1
Tipos de Dados e exemplos
. . . . . . . . . . . . . . . . .
39
4.2
Exemplo de um documento XML . . . . . . . . . . . . . .
41
4.3
Exemplo de uma DTD . . . . . . . . . . . . . . . . . . . .
43
4.4
Exemplo de um XML Schema . . . . . . . . . . . . . . . .
46
4.5
Documento XML . . . . . . . . . . . . . . . . . . . . . . .
46
4.6
DTD para Documento XML . . . . . . . . . . . . . . . . .
47
4.7
XML Schema para Documento XML . . . . . . . . . . . .
47
4.8
Exemplo de um documento Centrado em Dados . . . . . .
49
4.9
Exemplo de um documento Centrado em Documentos . . .
50
vi
4.10 Representação do documento XML com o uso de grafos . .
53
4.11 Abordagem em Grafo . . . . . . . . . . . . . . . . . . . . .
54
4.12 Tabela de rótulo . . . . . . . . . . . . . . . . . . . . . . . .
54
4.13 Granularidade Grande . . . . . . . . . . . . . . . . . . . .
56
4.14 Granularidade pequena . . . . . . . . . . . . . . . . . . . .
56
4.15 Granularidade Média . . . . . . . . . . . . . . . . . . . . .
57
4.16 Nı́veis de Granularidade . . . . . . . . . . . . . . . . . . .
58
4.17 Trecho de um documento XML . . . . . . . . . . . . . . .
63
4.18 Consulta Xpath . . . . . . . . . . . . . . . . . . . . . . . .
63
4.19 A consulta XPath representada no Grafo . . . . . . . . . .
64
5.1
Estrutura de um Benchmark . . . . . . . . . . . . . . . . .
73
5.2
Estrutura hierárquica do documento de teste gerado pelo
gerador de dados XML - [Rahm, 2000]. . . . . . . . . . . .
78
5.3
DTD de controle de documentos para XMarch-01,
. . . .
79
5.4
Componentes da Arquitetura Benchmark XMach . . . . .
80
5.5
Tempo médio gasto pela CPU para execução das Consultas
98
A.1 Instalação do XCheck . . . . . . . . . . . . . . . . . . . . .
112
A.2 Estrutura arquivo engines.xml . . . . . . . . . . . . . . . .
113
A.3 Arquivo experiment . . . . . . . . . . . . . . . . . . . . . .
114
A.4 Status que o programa dá após o comando $./XCheck.pl run example . . . . . . . . . . . . . . . . . . . . . . . . . .
114
A.5 Alterando o arquivo experiment . . . . . . . . . . . . . . .
116
A.6 Interações realizadas pelo Xcheck para chegar ao resultado
117
A.7 Arquivo experiment adaptado ao Oracle . . . . . . . . . .
120
B.1 Instalação BD Exist
. . . . . . . . . . . . . . . . . . . . .
121
B.2 Organização Hierárquica das coleções . . . . . . . . . . . .
123
B.3 Tela de criação de coleções no Banco de Dados XML eXist. 123
B.4 Armazenamento dos documentos aluno.xml e curso.xml no
Banco de Dados eXist . . . . . . . . . . . . . . . . . . . .
vii
124
B.5 Documento curso.xml após armazenado no banco de dados
125
C.1 Arquitetura do Oracle XML DB . . . . . . . . . . . . . . .
127
C.2 Instalador Oracle . . . . . . . . . . . . . . . . . . . . . . .
128
C.3 Produto a escolher para a instalação . . . . . . . . . . . .
128
C.4 opções para a instalação . . . . . . . . . . . . . . . . . . .
129
C.5 Criação do BD . . . . . . . . . . . . . . . . . . . . . . . .
129
C.6 Instalação do Componente XML . . . . . . . . . . . . . . .
130
C.7 Resumo da instalação . . . . . . . . . . . . . . . . . . . . .
130
C.8 Tela de status de configuração . . . . . . . . . . . . . . . .
131
C.9 Criação da Tabela Aluno no Oracle . . . . . . . . . . . . .
132
C.10 Criação da Tabela Curso no Oracle . . . . . . . . . . . . .
132
C.11 Inserir dados na tabela aluno . . . . . . . . . . . . . . . .
132
viii
Lista de Tabelas
3.1
Principais Diferenças entre XML e HTML . . . . . . . . .
4.1
Algumas diferenças entre dados Semi-Estruturados e Estru-
33
turados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2
abordagem grafo . . . . . . . . . . . . . . . . . . . . . . .
55
4.3
Comparação entre Banco de Dados Relacional e Banco Dados XML . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.1
Parâmetros de geração de documentos . . . . . . . . . . .
80
5.2
Banco de dados suportados pelo XCheck de forma padrão .
87
5.3
Resumo de Benchmarks para Bancos de Dados XML . . .
88
5.4
Alguns Bancos de dados XML nativos existentes . . . . . .
91
5.5
Bancos de dados com suporte a XML . . . . . . . . . . . .
92
ix
Lista de Algoritmos
x
Capı́tulo 1
Introdução
A necessidade de organizar e gerenciar a informação faz com que não
baste que um dado seja simplesmente armazenado, é indispensável que
posteriormente a isso tal dado possa ser consultado com semântica correta
e em tempo hábil. Faz parte do campo de ação dos Sistemas Gerenciadores
de Bancos de Dados administrar a infomação de maneira a assegurar a
integridade do que está guardado. Neste contexto, justifica-se a constante
prática dos estudiosos e pesquisadores da área de Banco de Dados em
buscar formas de aprimorar esses sistemas com intuito de garantir que as
informações estarão de fato seguras e ao alcance dos seus devidos usuários.
O sucesso nos resultados obtidos por parte de estudiosos da área já
é vivenciado e vêm sendo aprimorado mediante as necessidades que vão
surgindo no coditiano, conforme já dito anteriormente. E uma das mudanças de paradigmas mais impactantes nesse contexto de armazenamento
de informações surge a partir do aumento do fluxo de informação que
trafega pela Internet.
Esse fluxo crescente justifica-se pela diversidade de aplicações que trabalham dados conforme a polı́tica da sua empresa, ou seja, na Internet
passam a trafegar dados que possuem uma natureza heterogênea, uma
estrutura não estável e não tão rı́gida e suscetı́vel a mudanças (Dados
Semi-Estruturados tratados em Capı́tulos seguintes) [Moraes, 2001]. Dados advindos da Internet não podem ser armazenados em Banco de Da-
1
dos tradicionais, onde a informação e a forma de organização já são prédeterminadas, com uma representação rı́gida e estável, sem que haja antes
algum tipo de processamento.
Neste trabalho, onde o foco é a Tecnologia de armazenamento de informação e dados cuja estrutura não é pré-determinada, será mostrado
conceitos e modelos de Banco de Dados preparados e especı́ficos para receber tais tipos.
A abordagem feita será delineada para dois segmentos, sendo o primeiro
o armazenamento de dados semi-estruturados, levando em consideração
especificamente a Linguagem XML (eXtensible Markup Language), por
ser um formato que é bastante usado para intercâmbio de informações e
portanto necessita ser armazenado. E a segunda abordagem será voltada
para especificação de ferramentas automatizadas que possibilitem escolher
entre as várias opções de Bancos de Dados já existentes no mercado para
trabalhar Dados XML.
Tal estudo será realizado no intuito de retratar duas frentes de pesquisa
destinadas a obter uma solução para o problema de armazenamento de
dados semi-estruturados, como exposto a seguir, [Moraes, 2001]:
• Será mostrado o ponto de vista dos cientistas que acreditam na Adaptação
dos Bancos de Dados já existentes e predominantes no mercado para
receber dados XML, que são denominados Banco de Dados habilitados
ou com suporte à dados XML.
• E ainda será exposto a proposta dos estudiosos que apostam na consolidação de Bancos de dados especı́ficos para Documentos XML, chamados Banco de Dados Nativos XML.
Como objetivo desse Trabalho, embasado nos dois modelos de Banco de
Dados citados será feita uma análise comparativa acerca desses dois tipos
de Sistemas Gerenciadores de Banco de Dados existentes para XML. Para
isso abordaremos a técnica de Benchmark, ou seja, a aplicação de softwares
para a avaliação de Banco de Dados XML.
2
Utilizando de pesquisas em livros e sites da Internet relacionados ao
tema, o trabalho é dividido nos seguintes Capı́tulos:
O primeiro e presente Capı́tulo destina-se a uma Introdução ao tema,
situando o leitor desta em qual contexto vislumbra estar este trabalho.
O Segundo Capı́tulo contempla definições importantes ao entendimento
desde trabalho. Ou seja, neste capı́tulo é mostrado aspectos relevantes e
conceitos sobre bancos de dados em geral.
No Terceiro Capı́tulo será apresentado um breve Histórico acerca da
Tecnologia de Armazenamento de Dados, desde a necessidade de se guardar
a informação até a necessidade de melhorar as técnicas e o padrão de
intercâmbio e tráfego de informação na Internet.
No Quarto Capı́tulo serão abordados aspectos quanto a representação
de um dado, a classificação, as formas de armazenamento, as técnicas de
guarda, entre outras caracterı́sticas. Como o foco é o dado XML, estaremos ainda apresentando pontos relevantes quanto a estrutura de um Dado
XML, técnicas de busca, tipos de banco de dados existentes, primeiros
modelos e formas de representação, etc.
No Quinto Capı́tulo após uma abordagem teórica do padrão XML e da
apresentação de Bancos de Dados XML, será abordado formas do administrador do Banco de Dados (DBA) estar optanto entre qual técnica é a
melhor diante da situação em que ele se encontra.
Para conseguir tal feito, neste capı́tulo são apresentados técnicas de
Benchmark, sendo que, para exemplificar seu uso são escolhidos dois Bancos de Dados, um do tipo Especı́fico a Documentos XML e o outro com
Suporte para documentos XML (eXist e Oracle respectivamente). Estes
testes são feitos com um Benchmark eleito, o XCheck.
E por fim serão feitas conclusões acerca das experiências vivenciadas
com este trabalho.
3
Capı́tulo 2
Armazenamento de Informações Definições
Cresce com o passar dos anos o número e a variabilidade das informações
que estão disponı́veis aos usuários por meio eletrônico. E em vão seriam
estas informações caso não fosse possı́vel seu armazenamento para seu posterior acesso.
Desta forma, os Bancos de Dados (BD’s) definidos como Sistemas
Computadorizados que proporcionam meios para armazenamento e processamento de tais dados [Date, 2004], tornaram-se um componente essencial
no cotidiano da sociedade moderna. A partir do momento que a comunidade acadêmica e empresarial admite a importância de aumentar as potencialidades de Sistemas para o gerênciamento das Informações, passa a
existir um enorme esforço para simplificar o uso desses bancos de dados
de forma a acomodar e integrar fontes de informações de naturezas diversas, com o intuito de garantir aos usuários segurança, confiabilidade e
maximização de ganhos de tempo e consequêntemente lucros.
Dentro deste contexto, faz-se necessário um entendimento a cerca dos
termos e das caracterı́sticas dos Bancos de Dados de maneira geral. Sendo
este capı́tulo, destinado a apresentar termos técnicos com os quais o leitor
deve estar familiarizado.
4
2.1
Caraterı́sticas Fundamentais acerca dos Bancos
de Dados
É comum surgirem atividades que envolvam alguma interação com um
banco de dados no dia a dia de qualquer ser humano, como por exemplo,
ao realizar uma reserva em um hotel, ao fazer alguma transação bancária,
ao pegar emprestado um livro em uma biblioteca, dentre várias outras
situações cotidianas. Tais situações são exemplos de aplicações de bancos
de dados, onde tradicionalmente a maior parte dos dados que são armazenados e acessados estão em formato textual ou numérico. Porém, em outros
contextos é possı́vel ter dados com formatos diferentes, como imagens e
sons, com caracterı́sticas próprias de cada contexto.
Essas situações dispertam a comunidade acadêmica para estudos cada
vez mais aprofundados de tecnologias que viabilizem o uso dos BD’s nas
suas formas de manipulação.
2.1.1
Dados
Dados são valores que representam conceitos, instruções, fatos sobre
eventos ou alguma aplicação, de modo formalizado [Navathe e Elmasri, 2000].
São a parte mais preciosa de um sistema, pois são a representação convencional de fatos, conceitos ou instruções de forma apropriada para comunicação e processamento por meios automáticos. São registros organizados
de transações e que representam um conjunto de sı́mbolos sem qualquer
significado em si mesmos, desta forma, é necessário que possa ser feito algum processamento ou interpretação (mecânica ou humana) para que um
dado possua um significado .
O valor do dado por si só não constitui um conhecimento útil, não
fornece interpretação sobre os eventos, nem qualquer base para ação. É
necessário que os dados sejam armazenados para que possam ser então
processados ou interpretados, principalmente se tal interpretação depen-
5
der de recursos temporais (dados guardados de maneira cronológica, ou
histórica) ou da avaliação de mais de uma pessoa [Navathe e Elmasri, 2000].
2.1.2
Informação
Já foi falado anteriormente que um dado não possui valor semântico
por si só, entretando um dado trabalhado gera informação [Date, 2004].
Ou seja, a partir de um dado registrado 1 , é possı́vel interpretar e processar tal dado por pessoas ou por meios automatizados, e esse resultado (a
informação obtida) é o que dará sentido a uma aplicação.
Faz-se ainda importante dizer que é a informação que permite a tomada
de decisões, sendo que o significado dos dados ou a informação obtida
apartir de dados armazenados, como ilustra a Figura 2.1 [Navathe e Elmasri, 2000],
é o que fará com que o profissional ou a aplicação obtenha êxito nos resultados.
Desta forma, a qualidade dos resultados obtidos apartir do uso das informações geradas depende também do meio de armazenamento, sendo que
este meio deve possibilitar que [Date, 2004]:
• Os dados armazenados estejam organizados;
• Estejam disponı́veis no tempo certo e de forma correta;
• E que possam estar acessı́veis às pessoas certas, com segurança.
Figura 2.1: O Dado processado gera Informação
1
O termo registro é bastante usado em Banco de Dados para referenciar um dado armazenado, ou
seja, um dado passa a ser um registro quando armazenado em algum sistema [Date, 2004]
6
Tais caracterı́sticas citadas anteriormente são implementadas em Sistemas denominados Banco de Dados, tratados com maior atenção na seção
a seguir.
2.1.3
Banco de Dados
Um Banco de Dados é uma coleção de dados relacionados, de tal
forma que se possa recuperá-los quando necessário. Estes dados representam informações do mundo real e podem ser manipulados por usuários
especı́ficos, [Takai et al., 2005]
Geralmente quando se fala em um Banco de dados, se estabelece uma
aplicação a qual estará acessando a Informação presente no banco de dados,
uma camada de acesso e o Banco de dados em si, conforme Figura 2.2 a
seguir:
Figura 2.2: Acesso ao banco de Dados
De acordo com [Navathe e Elmasri, 2000], os Bancos de Dados possuem
algumas propriedades, dentre elas destacam-se:
• Um banco de dados representa algum aspecto do mundo real, ou seja,
uma parte da rotina de uma empresa, ou de alguma organização, cu7
jos dados precisam ser armazenados ( conforme citado na Figura 2.2,
tendo em vista que é uma aplicação de cunho real). Imagina-se isso
fisicamente e organiza de forma cronológica ou não o seu armazenamento. Há autores, como em [Martins, 2003], que chamam essa parte
do mundo real de minimundo (miniword ) ou Universo de Discurso
(UoD, Universe of Discurse).
• Os dados para se relacionar devem seguir uma lógica, dados aleatórios,
sem uma lógica na interação não podem ser referenciados como um
Banco de Dados. Essa lógica é garantida exatamente pela caracterı́stica anterior, visto que, se o Banco de dados é baseado em algum
aspecto do mundo real, ele segue uma lógica e possui semântica, ou
seja, não são meros dados, são dados em um contexto, o que o caracteriza, após alguns processamentos, uma informação armazenada.
• Todo Banco de Dados têm um objetivo especı́fico, portanto, deve ficar
claro quais são seus usuários, quais as restrições de acesso, quais as
aplicações estabelecidas.
Sendo assim, um Banco de Dados tem sempre uma fonte de alimentação,
uma relativa interação com o mundo real, o minimundo e um grupo de
usuários [Navathe e Elmasri, 2000]. Observando a Figura 2.2 é possı́vel
verficar que a fonte de alimentação é uma aplicação, é ela quem comunica
diretamente com o mundo real. A camada de acesso faz a conecção entra
a camada de aplicação e o BD e pode se fazer necessária ou não.
O BD ainda possibilita que os dados estejam atualizados a todo instante,
ou seja, operações de inserção, remoção e consultas são facilitadas e são
coordenadas por um software gestor, o SGBD.
O Sistema de Gerenciamento de Bancos de Dados (SGBD) ou
DBMS (Database Management System), como mostra a Figura 2.3 é quem
coordena o Banco de Dados, e por consequência a organização. O SGBD
é composto por softwares e aplicativos que dinamizam as operações de
8
inserção, consulta e atualização de forma que usuários não autorizados não
tenham acesso a componentes crı́ticos do sistema [Date, 2004]. Ou seja, o
principal objetivo de um SGBD é proporcionar um ambiente tanto conveniente quanto eficiênte para recuperação e armazenamento das informações
no Banco de Dados.
Na Figura 2.3 é possı́vel observar que o SGBD é composto por um
Banco de Dados, ou seja, um armazém de informações, sendo este por sua
vez composto pelos dados.
Figura 2.3: Sistema Gerenciador de Banco de Dados
[Navathe e Elmasri, 2000]
O SGBD provê um controle das informações e operações pertinentes
no Banco de Dados. Logo, ao comparar o enfoque de Banco de Dados com
o do armazenamento tradicional feito com arquivos é possı́vel visualizar
diferenças que manifestam na comunidade acadêmica o desejo de continuar inovando com SGBD’s. Para que fique mais claro, a seguir algumas
diferenças são apresentadas [Date, 2004].
• No processamento de arquivos cada usuário define e implementa os
arquivos necessários para a aplicação especı́fica. Embora em muitos
casos, usem de dados em comum, usuários diversos mantém arquivos
9
separados, atualizando-os somente para uso próprio. Isso faz com que
haja trabalho redundante e desperdı́cio de memória. Em se tratando
dos Bancos de Dados, um único repositório é mantido, sendo que após
definido passa a ser acessado por diversos usuários.
• O Sistema de Banco de Dados possui uma relativa descrição dos dados,
as restrições de acesso e a estrutura do Banco de Dados. Essa definição
é armazenada no catálogo2 do sistema, que contém informações como
a estrutura de cada arquivo, o tipo de formato de armazenamento de
cada itém de dados e várias restrições relativas aos dados. As informações armazenadas no catálogo são chamadas de metadados e
descrevem a estrutura fundamental do Banco de Dados. Isso faz com
que a inconcistência e as divergências geradas no caso dos arquivos sejam corrigidas nos Bancos de Dados, uma vez que é estabelecido um
padrão e uma certa organização com relação ao acesso e armazenamento da informação.
• Outra importante propriedade dos Sistemas de Banco de Dados é
o Compartilhamento de Dados e Processamento de Transações de
Multiusário, onde como o próprio nome coloca, os SGBDs possibilitam a vários usuários terem acesso a um mesmo repositório de dados
ao mesmo tempo, com ferramentas que permitam que a informação
armazenada esteja correta, não se corrompa e não seja redundante, o
que não acontece com o Sistema de Processamento de Arquivos.
2.1.4
Arquitetura do Sistema de Banco de Dados
Uma das caracterı́sticas que trazem destaque aos Bancos de Dados é o
fato de fornecerem nı́veis de abstração, ou seja, tal técnica possibilita que
detalhes não interessantes a todos usuários sejam revelados. De acordo
com a arquitetura proposta por ANSI/SPARC - Study Group on Data
2
Um espaço na memória para armazenamento especı́fico de dados da estrutura do Banco de Dados
[Date, 2004]
10
Base Management Systems [Stanley, ] é possı́vel visualizar três nı́veis dessa
arquitetura, observe a Figura 2.4:
Figura 2.4: Os três nı́veis da arquitetura
[Date, 2004]
1. Nı́vel interno: Também conhecido como nı́vel de armazenamento,
é o mais próximo do meio de armazenamento fı́sico. É aquele que
se preocupa com o modo como os dados são fisicamente armazenados
dentro do sistema.
2. Nı́vel externo: Também conhecido como nı́vel lógico do usuário, é
o nı́vel mais próximo dos usuários, é aquele que se preocupa com o
modo como os dados são vistos por usuários individuais. Nesse nı́vel
usa-se muito o termo visões, que se refere à permissão de acesso que
cada usuário possui.
3. Nı́vel conceitual: Também conhecido como nı́vel lógico de comunidade, ou ainda somente como nı́vel lógico, é um nı́vel ”indireto”entre
os outros dois.
O nı́vel externo se preocupa com as percepções dos usuários individuais,
enquanto o nı́vel conceitual está preocupado com uma percepção do grupo
de usuários (os usuários que acessam o Banco de Dados como um todo).
Mas se faz importante lembrar que a maior parte dos usuários não está
interessada no Banco de Dados inteiro, mas somente em alguma parte
11
restrita dele, desta forma haverá muitas visões externas distintas, cada
qual consistindo em uma representação mais ou menos abstrata de alguma
parte do banco de dados completo, e haverá exatamente uma visão conceitual, consistindo em uma representação igualmente abstrata do Banco
de Dados em sua totalidade. Do mesmo modo, haverá uma ”visão interna”representando o modo como o Banco de Dados está armazenado
internamente. Os nı́veis interno e conceitual são nı́veis implementados por
meio dos Modelos de Banco de Dados [Takai et al., 2005].
Nos modelos de Bancos de Dados existentes faz-se necessário definir a
sua estrutura (tipos de dados, relacionamentos e restrições que devem existir entre os mesmos). Tais modelos podem ser classificados como modelos
de mais alto nı́vel ou conceituais (que estão próximos do modo como muitos
usuários percebem os dados) a até o mais baixo nı́vel (modelos que definem
a forma como os dados são armazenados com detalhes)[Date, 2004].
Dentro dos vários modelos existentes
3
é importante definir a diferença
entre a estrutura (descrição) do banco de dados e os dados em si (o que
será armazenado). A descrição do banco de dados é chamada de Esquema
de banco de dados [Navathe e Elmasri, 2000]. E este é definido durante
o projeto do Banco de dados, podendo ser alterado poucas vezes em BDs
tradicionais. Porém os dados em si podem mudar com relativa freqüência,
sofrendo alterações de acordo com cada usuário 4 .
A seguir na Figura 2.5 é apresentado a arquitetura detalhada de um
Sistema de Banco de dados. Observe a importância do Administrador do
Banco de Dados (DBA) e do Sistema de Gerênciamento de Banco de Dados
(SGBD), pois é o SGBD sobre as coordenadas do DBA que determina os
acessos:
3
4
Estaremos falando desses modelos de Banco de Dados de forma cronológica no Capı́tulo 2
Mais adiante, será possı́vel ver que esta é uma das necessidades de aprimoramento reveladas com o
surgimento da internet, devido a grande diversidade dos tipos de dados da WEB.
12
Figura 2.5: Arquitetura Detalhada do Sistema
[Date, 2004]
2.1.5
Linguagens de Banco de Dados
Um sistema de banco de dados proporciona dois tipos de linguagens:
uma especı́fica para os esquemas do banco de dados e outra para expressar
consultas e atualizações [Navathe e Elmasri, 2000].
Linguagem de Definição de Dados
Um esquema de dados é especificado por um conjunto de definições
expressas por uma linguagem especial chamada linguagem de definição de
dados (Data Definition Language) ou DDL. O resultado da compilação
dos parâmetros DDL’s é armazenado em um conjunto de tabelas que constituem um arquivo especial chamado diretório de dados ou dicionário de
13
dados [Santiago, 2004].
Um dicionário de dados é um arquivo de metadados, ou seja, um arquivo
que possui informações a respeito dos dados a serem armazenados. Em um
sistema de banco de dados, esse arquivo ou diretório é consultado antes
que o dado real seja modificado e isso é feito em tempo de execução.
A estrutura de memória e o método de acesso usados pelo Banco de
Dados são especificados por um conjunto de definições em um tipo especial de DDL chamado Linguagem de Definição e Armazenamento de Dados
(Data Storage and Definition Language). O resultado da compilação dessas
definições é um conjunto de instruções para especificar os detalhes de implementação dos esquemas do banco de dados (os detalhes normalmente
são ocultados dos usuários) [Navathe e Elmasri, 2000].
Linguagem de Manipulação dos Dados
São várias formas de manipulação de dados tais como:
• A recuperação das informações armazenadas no Banco de dados, ou
seja é realizada uma consulta, que por sua vez é uma solicitação para
recuperação de informações;
• Inserção de novas informações no Banco de dados;
• A remoção de informações do Banco de dados;
• A modificação das informações do Banco de dados;
Sendo assim, é necessário ter uma linguagem para facilitar tais formas de
manipulação, o que é garantido com o uso da Linguagem de Manipulação de
Dados ou a (DML). São classificadas segundo dois tipos [Navathe e Elmasri, 2000]:
• DML procedurais - Exigem que o usuário especifique quais dados
são necessários e como obtê-los.
• DML não procedurais - Exigem que o usuário especifique quais
dados são necessários, sem especificar como obtê-los.
14
As DML’s não procedurais são normalmente mais fáceis de aprender e
de usar. Entretanto, como o usuário não especifica como obter os dados,
essas linguagens podem gerar código menos eficiênte que os gerados por
linguagens procedurais.
Sendo então, uma consulta uma solicitação para recuperação de informações, a parte de uma DML responsável pela recuperação de informações
é chamada de linguagem de consultas (query language), [Navathe e Elmasri, 2000].
SQL
Uma DML procedural bastante conhecida é a SQL, ou Structured Query
Language ou Linguagem de Consulta Estruturada. Foi originalmente desenvolvida pela IBM, quando ainda era chamada Sequel 2 [Silberschatz, 1999].
Normalmente, os diversos SGBDs relacionais implementam versões da SQL
que possuem algumas pequenas diferenças entre si.
Dentre os mecanismos para consulta aos dados, as principais funcionalidades oferecidas pela SQL são [Silberschatz, 1999]:
• Ordenação dos resultados por um determinado campo da tabela;
• Junções entre tabelas, ou seja, permite consultas a fontes diferentes;
• Funções de agregação, que permitem que sobre os valores de uma determinada coluna da tabela, sejam realizadas operações. As principais
funções oferecidas são: soma, média, máximo valor, mı́nimo valor e
contagem;
• Consultas aninhadas, um mecanismo para especificação de condições
que representem a existência de valores de campos em outros campos
de outras tabelas. É semelhante às junções;
• Operações de conjuntos, que vêem os resultados de consultas como
conjuntos, realizando operações de união, interseção e subtração. SQL
oferece também, recursos para a inserção de dados, exclusão, junção,
15
criação de tabelas, restrições de segurança, definição de visões [Silberschatz, 1999].
Ela é utilizada basicamente para consultas a dados organizados segundo um esquema relacional, o que requer uma estrutura definida
previamente.
16
Capı́tulo 3
Histórico e Desenvolvimento dos
Bancos de Dados
3.1
Do surgimento da Escrita à automação do processo
de armazenamento
Neste capı́tulo será feita uma recapitulação rápida do histórico e evolução
dos Métodos de Armazenamento de Informações e os Bancos de Dados,
visto que tal tecnologia passou por várias gerações, e se conserva aprimorando suas funções e se especificando a cada aplicação.
Neste trabalho, vamos dividir a História dos Bancos de dados em algumas gerações distintas.
3.1.1
Processamento manual de dados (papel e lápis)
A primeira fase do Armazenamento de dados é caracterizada pelo surgimento da escrita até 1900. Segundo [Carabajal, 2006] a escrita além de
servir como forma de comunicação, veio de uma necessidade de guardar
informações para que pudessem ser usadas posteriormente, e mesmo antes
com os hieroglifos, o armazenamento já era feito através de marcas (os
homens ao voltar de uma caçada marcavam os lugares pelos quais eles
passavam para facilitar sua volta) ou mesmo através de desenhos (desenhos
feitos em rochas eram marcas para que os descendentes dos homens da
17
época viessem a conhecer sua cultura, uma forma de guardar informações
para serem usadas no futuro).
O homem evoluiu e a necessidade de guardar o trajeto realizado na
floresta não soou mais como um problema, a automação dos processos Industriais, a Revolução das Máquinas trouxe consigo a necessidade agora de
armazenar dados para agilizar tarefas cotidianas, maximizando os ganhos
e o lucro do homem. Surgem os armazenamentos fı́sicos, grandes salas destinadas ao arquivamento e guarda de documentos necessários ao processo
e constituição da história.
A difı́cil tarefa dos responsáveis pela guarda dos documentos fisicos alinhada à necessidade de processamento, faz com que equipamentos para
facilitar tal rotina fossem desenvolvidos.
3.1.2
Surgimento dos Computadores, cartões perfurados e máquinas
eletro-mecânicas para ordenar e tabular registros
Apartir da necessidade de processamento e automação do processo de
guarda de informações, surgem os primeiros computadores [Junior, 2006]
baseados em transistores, o que permitiu que a computação começasse a
fazer parte da vida de algumas empresas que decidiram investir em processamento de dados. A princı́pio a idéia era trabalhar os dados e simplesmente processá-los (gravar e gerar relatórios) sem qualquer transformação.
Com os ganhos trazidos por um processamento eletrônico, vieram também
tentativas de melhorar os benefı́cios trazidos por tal técnica, surge os
cartões perfurados [Junior, 2006]. Os cartões perfurados (placas perfuradas
para guardar informações) foi um hábido iniciado entre 1801 e 1805, por
Joseph Marie Jacquard, um matemático francês, que usou tal artifı́cio para
controlar a produção de tecido a partir de padrões descritos em cartões perfurados (informações acerca do processo eram armazenadas para se manter
um padrão na confeccção dos tecidos, na máquina de tecelagem).
A máquina conseguia ler esses cartões, conforme um dispositivo encon18
trava um furo no cartão, e o atravessava, e com isso era cumprida uma
determinada instrução. [Meirelles, 2002]. Na Figura 3.1, é possı́vel visualizar como era o formato de um cartão perfurado:
Figura 3.1: Cartões Perfurados
[Oliveira, 2000]
Em 1890, Herman Hollerith usou a tecnologia dos cartões perfurados
e sugeriu automatizar o procedimento do censo demográfico dos EUA1 .
Hollerith formou uma companhia para produzir máquinas que registravam
dados em cartões, os ordenava e tabulava. Esta companhia se tornou a
IBM.
Até 1955, muitas companhias tinham andares inteiros para guardar
cartões perfurados e processavam milhares de registros a cada noite [Azevedo, 2006].
A seguir na Figura 3.2 é possı́vel visualizar como eram essas máquinas:
Figura 3.2: Máquina de Cartões Perfurados
[Azevedo, 2006]
Os Cartões perfurados ainda não garantiam segurança o suficiênte para
os dados, e não davam suporte para um armazenamento eficaz, além da
grande demanda de espaço fı́sico para a guarda dos mesmos. Empresas
1
Hollerith obteve o resultado do censo em 6 semanas, enquanto a forma anterior ao procedimento
proposto por ele demorava cerca de dez anos [Junior, 2006]
19
especializadas da área incentivaram estudos, o que garantiu o desenvolvimento de técnicas de armazenamento mais eficazes. A seção a seguir contextualiza o surgimento das Fitas Magnéticas e Sistemas de Arquivos.
3.1.3
Fitas magnétivas, Sistemas de Arquivos
Na sequência, nas décadas de 40 e 50 aproximadamente, a empresa UNIVAC (Universal Automated Computer ) desenvolveu uma fita magnética
capaz de armazenar o equivalente a 10 mil cartões. A máquina UNIVAC
I construı́da por esta empresa, ficou conhecida do público americano por
após cálculos e armazenamentos de dados, prever em uma eleição para a
presidência (em 1952) a vitória do candidato Eisenhower [Meirelles, 2002].
O fato da UNIVAC proporcionar aos usuários, computadores capazes
de armazenar programas, veio fazer com que mais tarde na Década de 60,
surgisse a programação baseada em processos. Isto auxiliou os usuários nas
operações realizadas diariamente com o uso dessas máquinas. Por exemplo,
programas de adição eram organizados em função do processo de adição
usado pela máquina: carregando os registradores com números, executando
a instrução de adição, se preocupando principalmente com overflow 2 e
underflow 3 , mas não se preocupando se os resultados eram armazenados
para uso posterior [Figueiredo, 2003].
Devido a necessidade de conservar a informação, a maioria dos programas passou a usar o armazenamento em disco [Figueiredo, 2003]. Contudo,
os dados gravados em disco ficaram logo difı́ceis de organizar e administrar. Essa situação levou os profissionais a criar pacotes de programas cuja
finalidade era facilitar a manipulação do armazenamento em disco. Surgiram, então, os chamados sistemas de arquivo [Figueiredo, 2003]. Com eles,
os programadores podiam criar arquivos, armazenar dados e lê-los mais
2
Estouro de pilha ou transbordamento de dados, sobrecarga de um registro, ou seja quando se excede
a quantidade máxima de armazenamento de um registro [Moraes, 2001]
3
Quando se tenta retirar algo que não existe, ou seja quando se tenta remover uma informação de um
registro vazio [Moraes, 2001]
20
tarde para análise e apresentação. Os aplicativos ainda eram geralmente
organizados em função do modelo baseado em processos, e o aparecimento
de linguagens de nı́vel mais elevado, especialmente do COBOL, resultou
no desenvolvimento de grandes programas de aplicação comercial.
Embora esses primeiros sistemas de arquivo auxiliassem o programador,
os métodos de acesso aos dados eram ainda primitivos. O acesso ao dado
era aleatório e requeria que o aplicativo soubesse a localização fı́sica dos
dados no disco. Os endereços exigiam algoritmos de hashing 4 .
Desenvolver algoritmos de hashing com uma distribuição boa e uniforme
era uma habilidade importante, especialmente quando diferentes drives de
discos exigiam diferentes algoritmos. Essa dificuldade fez surgir o primeiro
recurso importante independente da implementação: o arquivo indexado
que em vez de exigir que o aplicativo fornecesse a localização exata de um
segmento de dados gravado, somente uma chave simbólica era necessária
[Meirelles, 2002].
Dentre os sistemas de arquivos mais usados estavam os sistemas ISAM
(Indexed Sequencial Access Method ) e VSAM (Virtual Sequential Access
Method ), que rodam em equipamentos de grande porte. Esses sistemas,
embora escassos, ainda são usados em algumas empresas para armazenar
dados históricos (relatórios acessados com pouquı́ssima frequência, mas que
precisam ser guardados por uma questão burocrática) [Figueiredo, 2003].
Nesta fase descrita, o processamento era orientado ao arquivo, sendo que
era necessário que o arquivo fosse lido seqüencialmente, e a inserção de um
novo dado era feita gravando-se os novos registros no arquivo principal.
Tal operação demandava tempo e se o arquivo fosse grande ocasionava
processamento desnecessário.
A busca incessante por técnicas de armazenamento mais eficazes perdurou e a década de 70 inaugura Sistemas Gerenciadores de Dados.
4
Técnica de Consulta para encontrar um endereço de memória [Moraes, 2001]
21
3.1.4
Os primeiros SGBD’s da Década de 70 - Modelos Hierárquicos,
Modelo em Redes
Os primerios Sistemas Gerenciadores de Bancos de Dados surgiram com
a demanda de maior processamento, visto que, não era o bastante as facilidades trazidas pelos sistemas de arquivos indexados, era necessário um
sistema capaz de coordenar todos os ”arquivos”, ou seja, os registros armazenados, e não deixar estas atividades para o usuário.
Os pesquisadores partiram da natureza muito das vezes hierárquica dos
dados, considerando registros como uma árvore, onde um registro podia ter
um subregistro e assim sucessivamente, ou seja, existia um arquivo denominado ascendente e o outro descendente, estabelecendo uma hierarquia,
caracterizando assim os SGBD’s hierárquicos [Meirelles, 2002].
Figura 3.3: Modelo de Banco de Dados Hierárquico
[Takai et al., 2005]
Conforme observado na Figura 3.3, cada tipo de registos, ou seja cada nó
da arvore está associado a outros por relações de 1 para N, em que do lado
N das relações estão os filhos, as quais podem ser vistas como relações pai
e filhos. Neste modelo não existem ligações entre elementos da árvore ao
mesmo nı́vel ou nı́veis diferentes nem com elementos em diferentes ramos.
Apenas existem ligações entre cada elemento e o seu superior (ou pai).
Neste modelo, se um dado registo tiver de pertencer a mais que um ramo
da árvore, terá que ser duplicado, podendo isto causar inconsistência na
informação e uma redundância de dados.
22
O mais conhecido dos SGBD’s hierárquicos é o IMS (Information Management Systems ) da IBM. O problema desses tipos de sistemas é que
em vários casos não era possı́vel armazenar dados de forma hierárquica.
Um exemplo de uma situação como esta, é no caso de um produto, que
pode ser comprado de vários fornecedores e um mesmo fornecedor pode
fabricar vários produtos [Navathe e Elmasri, 2000].
Como solução ao problema apresentado anteriormente, foi projetado os
Sistemas de Bancos de Dados em Rede. O primeiro a surgir foi o
CODASYL. Neste modelo os dados também podiam ser representados em
forma de árvore, porém um registro descendente podia ter qualquer número
de ascendentes. Vale lembrar que em ambos os casos citados, a sua implementação era facilitada pelo uso de ponteiros [Navathe e Elmasri, 2000].
Figura 3.4: Modelo de Banco de Dados em Rede
[Date, 2004]
O modelo de rede foi desenvolvido aproximadamente na mesma altura
do modelo relacional tendo sido utilizado em produtos comerciais antes
deste último [Jackson, 1999]. Neste modelo, a informação é armazenada
de forma semelhante ao modelo hierárquico, no entanto, ao contrário deste,
cada elemento que constitui a estrutura pode ter ligações com vários elementos ao mesmo nı́vel ou em nı́veis diferentes, existindo relações um para
muitos, muitos para um ou muitos para muitos. Este modelo permite que a
navegação até chegar a um determinado elemento não necessite de passar
por todos os nı́veis, podendo tomar atalhos. Desta forma, a informação
23
está organizada num grafo. Tal como o modelo hierárquico, este modelo caiu agora em desuso, existindo no entanto ainda em aplicações mais
antigas. A Figura 3.4 representa o modelo de rede.
Entretanto, os dois Modelos apresentados anteriormente ainda sofriam
de deficiências tais como complexidade para efetuar consultas, acessos por
meio de links ou ponteiros dentre outras, o que fez com que pesquisadores
continuassem na batalha por um modelo que facilitasse a vida dos projetistas. O modelo Relacional aparece como meio de superar as deficiências dos
Modelos apresentados anteriormente.
3.1.5
Meados da Década de 80 - Modelo Relacional
Um estudo realizado por um pesquisador da área de Banco de dados,
chamado Edgar Frank Codd veio formalizar a base para futuros desenvolvedores, ou seja, por meio de um trabalho teórico de representação de relacionamentos de dados complexos, Codd veio tornar mais simples a estrutura resultante, através do método denominado normalização [Silva, 2001].
A normalização consistia em separar armazenamento e recuperação de
dados. Esse esforço culminou com o desenvolvimento de um novo tipo de
banco de dados - O Relacional [Meirelles, 2002].
Apartir da normalização do Banco de Dados, o modelo relacional mudou
a visão antes centrada nas ”estruturas de dados e nas operações fı́sicas”,
para a modelagem dos dados no ambiente em que os dados se inserem.
O foco do processo passou a ser visto de um nı́vel mais elevado, abstraindo detalhes de como implementar os aplicativos necessários para o bom funcionamento do sistema e potencializando o dado em si, suas caraterı́sticas,
suas futuras formas de interpretação, que é o que realmente interessa para o
uuário final. O banco de dados passa a ser definido apartir de um esquema,
apartir de uma estrutura [Silva, 2001].
Sendo assim, os Bancos de Dados Relacionais consistem em um conjunto
de tabelas, que contém linhas e colunas e se relacionam entre si, delimi24
tados por uma estrutura rı́gida. Cada tabela possui várias colunas e cada
uma das colunas tem um nome único. Elas possuem ainda colunas que
são definidas como campos chaves e possibilitam a conexão entre elas. É
possı́vel realizar consultas por meio de linguagens como a SQL (Structured
Query Language), sendo que toda consulta feita resulta também em uma
tabela [Navathe e Elmasri, 2000].
Figura 3.5: Modelo de Banco de Dados Relacional
[Date, 2004]
3.1.6
Final da Década de 80 até atual
A busca pela melhora da performace nos Bancos de Dados já existentes
fez surgir um novo modelo que atendesse também a comunidade daqueles
que além de armazenar textos e registro cotidianos precisavam armazenar
imagens, e dados mais complexos.
• Modelo Orientado a Objetos: Posteriormente ao modelo Relacional que normalmente armazena somente dados, surge o Banco de
Dados Orientado a Objetos (O.O.), que possui a caracterı́stica de
armazenar não só dados, mas também métodos, ou seja procedimentos manipuladores destes dados. Estes não armazenam tabelas, nem
25
árvores, mas sim estados de objetos [Navathe e Elmasri, 2000].
Os sistemas de gerenciamento de Banco de Dados Orientado a Objetos
cresceram fora das pesquisas durante o começo da metade dos anos 80,
buscando ter sustentação da gerência da base de dados para objetos
gráfico-estruturados. O termo “sistema de banco de dados orientado
a objetos”surgiu por volta de 1985.
• Objeto-relacionais: Após o surgimento dos Bancos de Dados Orientados a Objetos, surge também um banco de dados que mescla as
facilidades dos BD’s Relacionais e dos BD’s O.O’s, sendo então chamados de Banco de Dados Objeto-Relacionais.
Estes foram criados a partir da necessidade de se ampliar os conceitos
do modelo orientado a objetos para o modelo relacional, ou seja, estender o modelo relacional para lidar com aplicações novas. São geralmente usados em aplicações para objetos complexos, tais como imagens, mapas, imagens geradas por satélite, previsão do tempo, projetos
de engenharia, biologia, projeto genoma, etc [Navathe e Elmasri, 2000].
Nesse contexto, os Bancos de Dados Objeto-relacionais fazem uso
de alguns conceitos do modelo de dados orientados a objeto dentro
do modelo relacional. Alguns exemplos de caracterı́sticas presentes
nas linguagens orientadas a objetos e abordadas nos modelos objetorelacionais são: a abstração de dados, herança de dados e funções,
representação de atributos multivalorados dentro de uma tabela, dentre outros [Abiteboul, 2003].
Os Bancos de Dados até aqui apresentados atendem a uma comunidade,
cujas as exigências se restringem a acomodar bem, dados que possuem
uma estrutura representacional bem definida [Figueiredo, 2003]. Porém,
atentos à ascensão da internet, ao crescimento e particularidade dos dados,
os cientistas se motivaram a desenvolver sistemas de armazenamento que
atendem a esta clientela, que integrem a informação de forma a facilitar
26
seu manuseio.
3.2
A internet no contexto de armazenamento de informações
A Internet evoluiu a partir da Arpaneth, que foi um projeto do final da
década de 60 sob o patrocı́nio da Agência de Projetos de Pesquisa Avançada
do Departamento de Defesa dos Estados EUA (DARPA), para conectar todas as diversas redes do governo e acadêmicas dos Estados Unidos, em uma
única rede, com protocolo de comunicação comum TCP/IP (Transmission
Control Protocol/ Internet Protocol) 5 .
Paralelo a este trabalho desenvolvido pela Agência DARPA, o cientista
da computação Theodore Nelson implementava uma forma de estruturar a
informação, permitindo que documentos de texto referenciem outros documentos e arquivos, tal mecânismo de acesso é chamado de hipertexto, e
era feito por meio de links ou ligações entre tais documentos.
Mais tarde por volta de 1990 Tim Berners-Lee aprimorou os conceitos
desenvolvidos por Ted Nelson (como era chamado o Theodore Nelson),
contribuindo com a idéia do browser 6 , onde os links propostos por Ted
foram implementados, ou seja, por meio de um browser gráfico que podesse
integrar todos os diferentes tipos de informações em uma única janela. Isto
facilitou ao usuário final que ganhou a praticidade de não ter que usar todos
os comandos e procedimentos separados que precisavam usar antes.
O empenho e dedicação dos ciêntistas anteriormente citados e de outros
contribuintes do processo de aprimoramento sofrido pela Internet trouxe
5
O modelo TCP/IP - como muitos outros modelos de protocolos - pode ser visto como um grupo de
camadas, em que cada uma resolve um grupo de problemas da transmissão de dados, fornecendo um
serviço bem definido para os protocolos da camada superior. Estas camadas mais altas estão mais perto
do usuário (camada de aplicação), lidam com dados mais abstratos e confiam nos protocolos das camadas
mais baixas para traduzir dados em um formato que pode eventualmente ser transmitido fisicamente.
6
Um navegador (também conhecido como web browser ou simplesmente browser, termos em inglês).
O termo browser vem do verbo to browse que significa olhar páginas de um livro, revista, etc, porém o
termo neste caso refere-se às páginas da internet
27
um sucesso indescritı́vel a Internet, fazendo com que sua diversidade, sua
heterogeneidade e o crescimento ”desordenado”dos dados despertasse a
comunidade cientı́fica da área de Banco de Dados para o estudo e a especificação de uma base que atendesse também a esta aplicação.
A justificativa para tal estudo vem da própria natureza dos dados, e
da constante necessidade de intercâmbio de informações geradas no mundo
do business-to-business 7 e e-commerce 8 . Cada empresa adota sua própria
polı́tica de transporte de dados, gerando consequentemente dificuldade
quanto a quesitos de portabilidade e integração entre sistemas.
No cenário proposto pelos BD’s tradicionais, fazia-se necessário que os
dados apresentassem a mesma estrutura. Ou seja, BD’s tradicionais pedem
um esquema pré-definido, uma estrutura rı́gida, enquanto que os dados no
ambiente web são diversificados e não possuem essa estrutura rı́gida, sendo
denominados semi-estruturados [Mello, 2003a]. Então, há a necessidade
de realizar a comunicação entre essas duas abordagens de troca de informação, sendo esta necessidade uma parte integrante do objetivo desse
trabalho.
3.2.1
Uma mudança de paradigma
Em comparação com sistemas convencionais de gerenciamento de banco
de dados, a comunicação com dados na Web apresenta uma mudança essencial de paradigma. A abordagem padrão de dados é baseada em uma arquitetura cliente/servidor. O cliente, pessoa ou programa, emite uma consulta que é processada. Por sua vez, o servidor responde a esta consulta
[Figueiredo, 2003]. Observe a Figura :
7
8
Comércio Eletrônico feito entre Empresas [Garber, 2004]
Comércio realizado via internet, ou seja comércio eletrônico [Garber, 2004]
28
Figura 3.6: Arquitetura tradicional de banco de dados Cliente/Servidor
[Mello, 2003a]
Já no contexto Web, considera-se uma abordagem de ”múltiplas camadas”. A camada mais baixa consiste de fontes de dados, também chamadas
de servidores. Estes podem ser servidores de banco de dados convencionais,
podem ser também sistemas legados9 , servidores de arquivos ou qualquer
aplicação que produza dados.
A camada mais alta, ou seja a camada do Cliente, consiste em interfaces
ou aplicações com o usuário. Entre a camada do Cliente e a camada do
servidor podem haver camadas intermediárias, frequentemente chamadas
de Middleware, ou seja são camadas que transformam, integram ou adicionam valor aos dados [Abiteboul, 2003].
Observe a Figura :
9
Sistemas existentes, que foram desenvolvidos no passado, com métodos de análise e programação
obsoletos, pouco documentados, usando linguagens ultrapassadas [Figueiredo, 2003].
29
Figura 3.7: Arquitetura de Aplicação com Base na WEB
[Abiteboul, 2003]
No nı́vel mais simples, não há camadas intermediárias e a interação é
diretamente entre clientes e servidores. Os dados fluem dos servidores para
os clientes, enquanto consultas são mandadas na direção inversa. O processamento da consulta no lado do servidor consiste em traduzir a consulta
para o modelo de dados próprio do servidor. O resultado é novamente
processado para modelo de dados de lógica comum, de forma que o cliente
possa entendê-lo.
Pesquisadores de Banco de Dados interessados em integração de dados
trabalham no entendimento do Middleware. Uma abordagem é o data
warehousing. O middleware importa dados da fonte e os armazena em um
banco de dados intermediário especialmente construı́do (o warehouse), que
é consultado pelo cliente. A principal dificuldade com esta abordagem é
manter o banco de dados em dia quando as fontes são atualizadas. Uma
segunda abordagem é um Sistema Mediador, onde as consultas do cliente
são transformadas e traduzidas junto à fonte de dados. Resultados parciais
de várias fontes são integrados pelo mediador em tempo real, isto resolve
o problema de atualizações, mas aumenta a carga para comunicação e
atualizações [Abiteboul, 2003].
Houveram várias tentativas que foram se aperfeiçoando na arte de inte30
grar dados num ambiente tão dinâmico quanto é a internet.
O surgimento de tecnologias como as linguagens de Marcação tais como
a GML (Generalized Markup Language- Linguagem de Marcações Genéricas),
a SGML ( Standard Generalized Markup Language - Linguagem Padrão de
Marcações Genéricas) e posteriormente a XML ( EXtensible Markup Language ou, em português, Linguagem extensı́vel de formatação). Vieram
melhorar as formas de representação e manipulação de dados semi-estruturados,
como serão abordados nas seções seguintes.
3.2.2
Linguagens de Marcação no Contexto de Armazenamento
O surgimento das Linguagens de Marcação foi marcante na década de
90, com o aparecimento da Web. Estas linguagens permitem a construção
de padrões públicos e abertos que vêm sendo criados para se tentar maiores
avanços no tratamento da informação; elas minimizam o problema de transferência de um formato de representação de um documento para outro, e
liberam a informação das tecnologias de informação proprietárias.
Sendo assim considera-se todo documento como constituı́do de três componentes, claramente distintos e separados: (a) conteúdo, (b) estrutura e
(c) estilo (ou formatação). O conteúdo é a informação propriamente dita,
a estrutura define como se dá a organização da informação, ou das idéias,
no documento e o estilo define o visual de apresentação das informações
ao usuário. Neste trabalho, não estamos preocupados com o estilo, ou seja
com a apresentação das informações, mas sim com o conteúdo e a estrutura
desse documento, por isso a seguir será apresentado algumas linguagens que
têm em seu contexto a caraterı́stica de se preocupar com o dado em si, não
com a apresentação:
• SGML (Generalized Markup Language) A SGML foi proposta
em 1986 para permitir a definição de documentos de acordo com sua
estrutura e conteúdo, independente de sua apresentação [Iso, 1986].
O intercâmbio e troca de dados seria favorecido se a SGML obtivesse
31
êxito com isso, e o armazenamento passaria a usar das facilidades de
tal implementação.
É uma linguagem genérica para a descrição da estrutura lógica de
documentos, permitindo a definição de linguagens especı́ficas, ou seja
geradas a partir das regras definidas por ela, o que fez com que padrão
SGML desse origem a outros padrões que surgiram com a demanda
do WWW (World Wide Web) por novos recursos.
A linguagem SGML é um padrão muito poderoso e geral, tendo sido
utilizada em ramos como o da publicação técnica, indústrias farmacêuticas, companhias aeroespaciais, automotivas e de telecomunicações. Mas apesar dos benefı́cios que podem ser ganhos usando
SGML, sua base de usuários foi limitada a grandes empresas, pois se
trata de uma linguagem muito complexa e extensa, fazendo com que
os custos com implementação não sejam tão triviais [Iso, 1986].
Para remediar os problemas enfrentados pela SGML, surge então um
subconjunto da SGML, o XML (Extensible Markup Language) tratado
a seguir.
• XML(Extensible Markup Language)
A Web, devido ainda não possuir um padrão barato e acessı́vel a
todos, precisava descobrir um meio de estabelecer um padrão para
transmissão de dados sem uma estrutura pré-definida e sem a complexidade da SGML, fato já afirmado no tópico anterior. Partindo
dessa premissa, o trabalho conjunto de um grande número de empresas (Oracle, IBM, Compaq, Xerox, Microsoft, dentre outras) e de
pesquisadores (MIT - USA, INRIA - França, Universidade de Keio Japão) reunidos no World Wide Web Consortium (W3C) 10 em 1996,
com o objetivo de criar um formalismo para facilitar a troca de da10
Órgão que desenvolve tecnologias (especificações, diretrizes, programas e ferramentas) para conduzir
a Internet ao seu potencial máximo, funciona como um fórum para informação, comércio, comunicação e
entendimento coletivo [W3C, 1996]
32
dos na Web, veio culminar com o surgimento da XML (eXtensible
Markup Language) [W3C, 1996].
A XML é uma linguagem de marcação, assim como a Hypertext Markup
Language (HTML). A principal diferença entre essas duas linguagens de marcação é o enfoque, a HTML é voltada à apresentação e
a XML permite a associação de tags definidas pelo usuário para descrição de conteúdo, algumas diferenças são mostradas na Tabela 3.1.
Neste sentido, enquanto os elementos HTML são pré-definidos e, portanto, não podem ser alterados, na XML é permitido que sejam criados
conforme a necessidade da aplicação, provendo assim, extensibilidade
[Martins, 2003].
Outro ponto que também diferencia HTML de XML é o fato de que
em documentos HTML, como a preocupação é somente com a apresentação não é possı́vel fazer consultas e isso também motivou os desenvolvedores da XML a criar uma linguagem que permitisse consultas
com o máximo de eficiência possı́vel, o que aproxima o documento
XML de um Banco de Dados.
Tabela 3.1: Principais Diferenças entre XML e HTML
XML
[Heuser et al., 2005]
HTML
Descreve uma unidade de informação Apresenta uma unidade de informação
Foca no que o Dado Significa
Foca na Apresentação do dado
Troca de Dados entre Aplicações
Apresentação do dado
Após a união de diversas empresas e entidades educacionais, em 10
fevereiro de 1998 vêm a tona então, a publicação da recomendação
para versão 1.0 da linguagem XML, atualmente encontra - se na versão
1.1 [W3C, 1996].
Embora o propósito original da iniciativa da XML fosse a definição
de uma linguagem de marcação voltada para o ambiente Web, esta
33
linguagem também se mostrou uma forma interessante para a representação de dados estruturados11 e semi-estruturados
12
, tornando-se
um importante meio de representação no transporte e interoperabilidade dos dados [W3C, 1996]. Devido a essa caracterı́stica, cada vez
mais empresas da área de negócios eletrônicos e finanças vêm aderindo
à utilização de tecnologias associadas à XML. Como essas aplicações
exigiam um controle de segurança e maior grau de confiabilidade, não
demorou muito para que os documentos XML (ou seja, documentos
escritos segundo as regras desta linguagem) recebessem atenção das
principais ferramentas gerenciadoras de banco de dados, os SGBDs.
Os SGBDs adaptados para tratar documentos XML são chamados
de XML habilitados, enquanto os SGBDs desenvolvidos com a finalidade de lidar com documentos XML são chamados de XML nativos
[Martins, 2003].
3.3
Bancos de Dados para documentos XML
Em 1998, começam a surgir comercialmente os primeiros bancos de Dados para armazenamento de documentos XML. Após o despertar dos desenvolvedores para o crescimento de tais dados na Web veio a necessidade
de tratar estes dados e armazená-los em um repositório especı́fico de forma
a facilitar sua manipulação.
O XML é uma linguagem de marcação que trabalha com dados semiestruturados (tratado no próximo Capı́tulo), sendo que do pondo de vista
de um Banco de Dados, um documento XML é uma coleção de dados.
Porém não tem em muitos casos uma estrutura tão rı́gida quanto a exigida
pelos BD’s relacionais por exemplo, combinando linguagem natural com
uma certa linha de rigidez [Figueiredo, 2003].
Como já citado anteriormente, os SGBDs adaptados para tratar do11
12
Dados com uma estrutura rı́gida de organização, melhor apresentados no próximo Capı́tulo
Uma estrutura não tão rı́gida de organização, também detalhado no próximo Capı́tulo
34
cumentos XML são chamados de XML habilitados, enquanto os SGBDs
desenvolvidos com a finalidade de lidar com documentos XML são chamados de XML nativos [Martins, 2003]. Estes tipos de Sistemas de Banco de
Dados serão melhor apresentados no capı́tulo seguinte, onde também será
abordado a tecnologia XML.
Sendo assim, neste Capı́tulo foram abordados algumas das gerações e
momentos pelos quais os principais Bancos de Dados passaram e a necessidade de ampliar ou mesmo apresentar novos Bancos de Dados nesta lista
para tratar de dados com caracterı́sticas não tão rı́gidas e não tão formais
(os dados semi-estruturados). Tal tentativa será constantemente abordada
neste trabalho, visto que este é o objetivo do mesmo.
Em alguns momentos foram citados exemplos de dados que trafegam
pela internet, e portanto merecem um tratamento especial, devido a natureza heterogenea e citada no parágrafo anterior.
Na Figura 3.8 é apresentado um esboço da evolução pela qual os Bancos
de Dados passaram até chegar no foco deste trabalho, ou seja, o tratamento
especial que se deve dar a dados cuja natureza é heterogênea e os Bancos
de Dados especiais para trabalharem com o padrão XML.
Figura 3.8: Evolução dos Bancos de Dados até a necessidade de Bancos de Dados especiais
para documentos XML[Santiago, 2004]
35
Capı́tulo 4
Dados - Sua Representação, sua
estruturação e a utilização de XML
O sucesso da Internet culminando com o seu crescimento veio justificar
a necessidade de encontrar mecanismos para viabilizar o armazenamento,
o acesso e atualização destes dados, visto que os mesmos não podem ser
consultados através de técnicas tradicionais de Bancos de Dados. Isto se
dá devido uma estrutura heterogênea, na qual dados advindos de fontes
distintas, de naturezas diversas se cruzam diariamente, impossibilitanto
técnicas tradicionais de manipulação de dados.
Este capı́tulo destina-se a abordar conceitos relevantes acerca do aspecto prepresentacional do dado, relatando caracterı́sticas interessantes e
primordiais na definição da estrutura representacional, na existência ou
não de padrões que estes dados precisam seguir para garantir o sucesso das
operações realizadas no armazenamento em um determinado repositório
de dados. Consequentemente serão abordados também conceitos acerca
da linguagem XML, uma linguagem para representação de dados, que será
apresentada neste capı́tulo e podendo também ajudar na tecnologia de
Banco de Dados, dinamizando o acesso e integrando fontes de dados.
36
4.1
Classificação de Dados apartir de sua representação
Estrutural
Manipular um dado constitui-se em vários passos, dentre tais é necessário
a princı́pio entender a sua natureza e a forma de representá-lo, visto que
em bases de dados eletrônicas pode-se distinguir formas de representação
especı́ficas para cada aplicação e de acordo com cada banco de Dados,
então definir as operações relevantes para o usuário.
O modelo de dados é primordial para a definição da forma como será
armazenados dados. Porém é necessário definir que tipo de dados pode
ser guardado em cada base de dados, tomando cuidados com relação à
estrutura.
Nas seções seguintes serão abordados aspectos quanto a classificação dos
dados, sua representação (sua estrutura) e suas caracterı́sticas particulares
[Mello, 2003a]:
4.1.1
Dados Estruturados
Os Dados Estruturados são dados que seguem um modelo pré definido
(definição a priori), ou seja, na sua representação são regidos por regras,
estão subordinados a manter um padrão imposto por um esquema (um
conceito abordado no Capı́tulo 2) definido antes do conhecimento dos dados
[Mello, 2003a]. Um esquema pode prever quais elementos são encontrados
nos documentos, a ordem em que estes elementos podem aparecer, a hierarquização destes elementos, o tipo de dados do conteúdo destes elementos,
entre outros. Um exemplo disso são os Bancos de Dados Relacionais, que
seguem a descrição do banco de dados definida durante o seu projeto, o qual
fornece uma estrutura, ou seja, a forma como os dados serão armazenados
[Hunter et al., 2003].
Isto limita o usuário na inserção e dificulta a integração de BD’s diferentes, visto que de acordo com o seu respectivo programador, cada Banco
37
de Dados é regido por seu esquema.
4.1.2
Dados Não Estruturados
Ao contrário dos dados estruturados, os dados não estruturados não
apresentam qualquer padrão, não podem ser armazenados de acordo com
um esquema. Exemplo de tais dados são as imagens, o texto livre, etc
[Mello, 2003a]. E para este trabalho só serão citados, uma vez que não faz
parte do escopo deste.
4.1.3
Dados Semi - Estruturados
Dados semi-estruturados possuem caracterı́sticas intermediárias em
relação aos tipos definidos nas seções anteriores a esta, ou seja, esta categoria traz consigo uma representação não completamente rı́gida, nem tão
pouco completamente sem estrutura. São classificados assim por possuirem
uma Representação Estrutural Heterogênea [Hunter et al., 2003].
O exemplo mais prático e conhecido de dados com essa caracterı́stica
heterogênea citada são os dados contidos na web, onde fontes de origens
diversas, com padrões diferentes são lançados neste mundo virtual que é a
internet.
Outro ponto que merece ser mencionado em relação a estes dados é
que são considerados auto-descritivos, pois possuem uma representação na
qual o esquema está presente no próprio dado, sendo assim o esquema
não é pré-definido, como no caso dos Dados Estruturados. Esquemas para
Dados Semi-estruturados são definidos após a existência dos mesmos. E
por possuirem esta representação auto-descritiva, os valores e a estrutura
em muitos casos se confundem.
Outra caracterı́stica desse tipo de representação de dados, é a sua Estrutura Irregular. Na internet, por exemplo, onde existem formas diferentes
de representar o mesmo objeto, com campos diversos e não padronizados,
operações de armazenar ou acessar grandes bases de dados podem se tornar
38
dispendiosas e desgastantes, além de alterar a semântica dos dados, caso
não haja técnicas de armazenamento eficazes.
Tomando como exemplo uma base de currı́culos de todos colaboradores
de uma multinacional, aspectos individuais de cada um, como a escolaridade, experiência, conhecimento em idiomas poderiam em muitos casos
serem campos que não seriam preenchidos e consequentemente estes campos ficariam em branco, trazendo desperdı́cio de memória e aumento do
tempo de resposta à alguma requisição feita pelo usuário. Além disso, considerando ainda bases de dados de diferentes etnias e culturas diferentes,
este seria outro fator que tornaria difı́cil a integração dessas bases, onde
todas as filiais teriam que seguir o mesmo padrão.
Para facilitar o acesso aos usuários do sistema, dando mais sentido
(semântica) à aplicação, a Estrutura Irregular é um aspecto que deve ser
considerado, sendo a particularidade de cada filial, de cada departamento
mantida ao máximo, com o mı́nimo de pré-processamento. Dá-se aqui
um motivo pelo qual a ciência tem investido no estudo de dados Semiestruturados.
Desta forma é possı́vel visualizar na figura 4.1 em qual posição se encontra os dados Semi-Estruturados em relação a classificação dos outros
tipos, ou seja, em uma posição intermediária.
Figura 4.1: Tipos de Dados e exemplos
[Mello, 2003b]
39
Algumas diferenças entre dados Semi-estruturados e dados Estruturados
são apresentadas na Tabela 4.1 a seguir:
Tabela 4.1: Algumas diferenças entre dados Semi-Estruturados e Estruturados
[Mello, 2003a]
Dados Estruturados
Dados Semi-Estruturados
Esquema Rı́gido
Esquema Não tão rı́gido
Estrutura regular
Estrutura Irregular
Estrutura prescritiva
Estrutura descritiva
Esquema definido a priori em tempo de projeto Esquema pode ser definido depois
do conhecimento dos dados
Dados e estrutura são separados claramente
Dados e estrutura se confundem,
estrutura embutida nos dados
A busca por mecanismos que auxiliam o entendimento das informações
(antes, durante e depois da manipulação dos dados) tanto por aplicações
quanto pelo homem está se tornando frequente, possibilitando o intercâmbio
de dados. E é neste cenário que padrões e meios de representar a informação
semi-estruturada da melhor forma possı́vel surgem.
As linguagens de marcação surgem com o intuito de melhor representar um dado semi-estruturado, tentando minimizar o problema de transferência de um formato de representação de um documento para outro. No
Capı́tulo anterior, foi falado sobre as linguagens de marcação e seu contexto histórico, enfatizando seus pontos fortes e fracos. Dentro deste seguimento, na próxima seção será abordada a XML, linguagem de marcação
criada com o objetivo especı́fico de representar uma informação e facilitar
seu manuseio por aplicações web que lidam com armazenamento de dados.
40
4.2
A estrutura de um documento XML
A XML é uma linguagem de marcação criada com o propósito de estabelecer uma estrutura não tão rı́gida, mas passı́vel de ser usada para
intercâmbio de dados via web [W3C, 1996]. Faz-se então necessário entender e visualizar sua estrutura para então captar o motivo pelo qual a XML
têm-se consolidado por tais caracterı́sticas.
Sintaxe Básica
XML é uma representação textual de dados. O componente básico em
XML é o elemento, ou seja, um texto delimitado por tags (marcas), como
na Figura 4.2:
Figura 4.2: Exemplo de um documento XML
Essa representação textual de dados segue uma sintaxe, onde o documento deve obedecer as seguintes regras [Martins, 2001]:
• A primeira linha do documento, que é opcional, consiste em uma
instrução de processamento que define a versão da linguagem XML
e a codificação usada no documento; Conforme Figura 4.2 onde a
primeira linha corresponde a: <?xml version=”1.0”encoding=”ISO
-8859-1”?>
A versão aqui citada é a versão 1.0 sobre a codificação das normas da
ISO -8859-1.
41
• Cada documento XML deve possuir apenas um elemento raı́z; Em 4.2
o elemento raiz é <cadastro>;
• A cada elemento de abertura, deve haver outro de fechamento correspondente; Na figura 4.2 anteriormente citado, é possı́vel visualizar
claramente, cada tag de abertura, possui sua respectiva tag de fechamento.
Por exemplo: <nome> é uma tag de iniciação e é finalizada pela tag
</nome>. Fazendo uma analogia a Banco de Dados, cada elemento
poderia ser visto como uma coluna da tabela1 e os dados contidos
entre tais tags podem ser comparados às linhas da tabela.
• Deve-se respeitar a ordem de ocorrência dos elementos dentro do documento, ou seja, ter o cuidado de fechar a tag certa, no momento
certo;
• Os elementos de abertura e fechamento devem possuir o mesmo nome,
inclusive respeitando letras maı́usculas e minúsculas;
• Cada elemento pode ter um ou mais atributos, com seus respctivos
valores entra aspas;
• Cada elemento pode posssuir um ou mais sub-elementos;
Sendo assim baseado nesta sintaxe é possı́vel obter o conceito de documento bem-formado, onde é um documento XML é considerado bemformado se atende à sintaxe XML usada dentro do documento. Por exemplo, se o programador não incluir marcas de fechamento ao inserir elementos no documento, se ele esquecer de incluir a declaração de documento
XML no inı́cio do documento ou se o documento incluir caracteres que não
possam ser analisados sintaticamente ou sejam inválidos, o programador
não possuirá um documento XML bem formado [W3C, 1996].
Apesar do projetista ter muita liberdade ao descrever um documento
XML, existe uma estrutura a ser modelada, não tão rı́gida como nos dados
1
Considerndo por exemplo Banco de Dados Relacionais
42
estruturados, como já falado neste trabalho, mas que merece ser discutida para que um documento XML seja validado [Abiteboul, 2003]. A
seguir será tratado formas de padronizar a representação dos dados XML,
validando-os e criando esquemas para tal fim.
4.3
DTD(Document Type Definition)
O documento XML deve ser regido por uma gramática formal, ou seja,
uma sintaxe. Uma das tecnologias relacionada a XML e que trabalha com
tal designação é a DTD, ou Document Type Definition.
A gramática especificadora DTD, estabelece regras que definem a composição do documento, informa quais elementos se relacionam com outros,
indica para cada elemento todas as possı́veis marcações válidas, os elementos obrigatórios, seus atributos (se existem), etc [Pinto, ]. Sendo assim é
possı́vel dizer que uma DTD permite especificar a estrutura básica de um
documento XML para um determinado ramo, o que tornaria um padrão
para aquele setor.
Para exclarecer, a seguir um exemplo, Figura 4.3
Figura 4.3: Exemplo de uma DTD
[Martins, 2001]
O DTD da Figura 4.3 descreve um documento contendo o endereço de
43
alguém. O documento deve possuir um elemento <endereço> que contém
<nome>, <logradouro>, <cidade>, <estado>, <cep>. Todos esses elementos devem existir, nessa ordem. O elemento <nome> contém um
<titulo> opcional, seguido de <primeiro-nome> e <ultimo-nome>. Todos os outros elementos contêm texto (#PCDATA), [W3C, 1996].
É importante notar que a sintaxe do DTD é diferente da sintaxe da
XML. Um DTD não é um documento XML. Para se construir um DTD
é necessário que se conheçam as caracterı́sticas dos tipos de dados que os
o documento XML vai conter, apesar de que é possı́vel fazer alterações no
DTD quando necessário. Utilizando um DTD, os arquivos XML podem
conter formatos próprios, podem ser utilizadas por um conjunto de pessoas.
O DTD pode ser utilizado como padrão ate mesmo para verificar se os
dados recebidos são válidos, apesar de que a sintaxe de um documento
XML é diferente de um DTD. Os DTDs são opcionais dentro de uma
estrutura XML, porém os dados enviados com um DTD são conhecidos
como XML válidos, [W3C, 1996].
É necessário ainda salientar que na DTD não existe uma declaração
distinta para dados do tipo string e dados numéricos, ou seja, são tratados
da mesma forma.
4.4
XML Schema Definition
Outra forma de formalização da estrutura dos dados é definida por meio
do uso do XML Schema Definition - Definição de um Esquema para XML
ou simplesmente XSD.
XSD é uma recomendação da W3C lançada em 2001 e possui mais
recursos para a especificação de esquemas em relação a um DTD, como
o suporte a tipos de dados, a conceitos de orientação a objetos, como
herança2 e polimorfismo3 , além de apresentar uma sı́ntaxe XML.
2
3
É possı́vel por meio de links que um documento XML herde caracterı́sticas de outro documento XML
mudança nos dados, ou na estrututura dos mesmos [W3C, 1996]
44
Apesar de XSD ser mais expressivo que um DTD em termos de especificação de esquemas XML, DTDs ainda são amplamente utilizados e
a grande maioria das ferramentas que realizam validação de documentos
XML (chamadas parsers) operam sobre DTDs [Hunter et al., 2003].
Porém apesar da usabilidade dos DTSs, um esquema XML possui algumas vantagens vantagens em relação a um DTD, pois XML Schema
utiliza sintaxe XML. Ou seja, um XML Schema é um documento XML.
Isso significa que ele pode ser processado como qualquer outro XML. Com
as mesmas ferramentas.
Algumas caracterı́sticas são reforçadas a seguir:
• XML Schema permite a definição de tipo de dado. Podemos definir
elementos com tipo integer (inteiro), date (data), time (hora), string
(caracteres), entre outros. Podemos ainda definir por meio do XDS
os atributos autorizados, os elementos que são filhos, a ordem dos
elementos filhos, se um elemento é vazio ou não
• XML Schema é extensı́vel. Além dos tipos de dados definidos pela especificação do XML Schema, é possı́vel criar novos. Inclusive derivados de tipos de dados já definidos (herança).
• XML Schema possui um poder de expressão maior. Por exemplo, elementos podem ser validados através de expressões regulares.[Graves, 2003]
A seguir um Exemplo (Figura 4.4) explicitando melhor as caracterı́sticas
de um XML Schema:
45
Figura 4.4: Exemplo de um XML Schema
[Pinto, ]
Como é possı́vel verificar no exemplo que possui a estrutura XML Schema
(Figura 4.4), o código XML Schema é maior que o código DTD.
Ao considerar a Figura 4.5 e a XML Schema descrita, algumas conclusões serão obtidas:
Figura 4.5: Documento XML
Uma DTD para a Figura 4.5ficaria assim:
46
Figura 4.6: DTD para Documento XML
Com XML Schema ficaria assim:
Figura 4.7: XML Schema para Documento XML
Existem 2 tipos de schemas internos ou externos. Isto é, se o schema
é interno vem incorporado num documento XML, e se é externo vem referenciado no documento XML, sendo que neste último caso, o mesmo
documento XML pode referenciar vários schemas e o mesmo Schema pode
ser referenciado por vários documentos.
Após serem abordadas as definições de DTD e XML SChema, é importante citar o conceito de Documentos XML Válidos, onde um documento
XML é considerado válido se ele contém um DTD ou XML Schema apropriada.
É preciso seguir uma gramática, seja ela por meio da DTD ou XSD.
Erros em documentos XML param um programa. A especificação XML
proposta pela W3C diz que um programa escrito para processar XML deve
parar caso encontre erros de sintaxe no documento. A razão é que um programa escrito para processar XML, será compatı́vel para qualquer documento XML [Heuser et al., 2005]. Isto também permite que um documento
XML possa servir de base à troca de informação entre várias entidades uma
47
vez que desta forma será interpretado sempre da mesma forma por todas
as aplicações envolvidas.
O DTD e o XSD neste contexto podem ser utilizados por programas que
precisem efetuar validações na estrutura do documento [Pinto, ], geralmente programas que envolvem a inserção ou atualização de informação
num BD, ou ainda ser utilizado como documento de referência a outras
aplicações que queiram utilizar a mesma estrutura para partilha de informação.
4.4.1
Representação - Árvores XML
Documentos bem-formados podem ser representados como uma árvore,
onde elementos e atributos correspondem aos nós da árvore [Abiteboul, 2003].
Assim, é comum usar o termo ”nó”como sinônimo para elementos e
atributos, sendo que os nós-texto ou nós-folha são aqueles que não possuem descendentes e correspondem aos valores associados aos elementos
e atributos. Existem Analisadores Sintáticos, também conhecidos como
processadores XML, que têm o papel de verificar se um documento é bemformado, transformando-o em árvore para isso [W3C, 1996].
Os processadores XML são responsáveis pela interpretação de um documento XML, ou seja, disponibilizar o conteúdo do mesmo para um aplicativo. Ele é capaz de detectar problemas como formato de arquivos que o
aplicativo não pode processar ou URL’s que apontam para recursos não
válidos. Os processadores XML são dividos em duas partes [Mello, 2003a]:
o manipulador de entidades e o parser.
• Manipulador de entidades - O manipulador de entidades é a parte do
processador XML responsável por localizar pedaços ou partes de documentos e manipular a substituição das referências. Esses pedações
de documentos podem ser declarações de entidades ou outros arquivos
de dados.
• Parser - O Parser é a parte do processador XML responsável por ve48
rificar a integridade dos dados XML. O Parser pode ser executado de
dois modos: sem validação e com validação. Um parser sem validação
verifica a sintaxe do documento, ou seja, verifica se o documento é
”bem formado”. No Parser com validação, além da verificação da
sintaxe, os dados são comparados com uma DTD. Deste modo, um
Parser com validação é capaz de verificar se um documento é ”válido”.
4.5
Documentos Centrados em Dados e Documentos
Centrados em Documentos
Segundo [Srisvastana, 2004], um documento é Centrado nos dados (datacentric) quando a ordem dos nós e a estrutura do documento não é importante. Eles são designados para serem usados por alguma aplicação, é
um documento composto por valores que não se relacionam entre si precisamente.
Figura 4.8: Exemplo de um documento Centrado em Dados
Segundo [Srisvastana, 2004] Documentos centrados em documentos (documentcentric) são usualmente escritos para consumo humano. Esses documentos
são caracterizados por possuirem uma estrutura menos regular ou irregular, sendo que neste caso a ordem em que os nós ocorrem na árvore XML
é importante.
49
Figura 4.9: Exemplo de um documento Centrado em Documentos
No modelo centrado nos dados inserem-se documentos que utilizam o
XML como forma de transporte de informação [Bourret, 2007], sendo destinados predominantemente a consumo por parte de computadores e não a
uso por parte de humanos. Neste modelo, os documentos são caracterizados
por possuı́rem uma estrutura regular e normalmente a ordem pela qual os
vários elementos com o mesmo nı́vel na estrutura são representados é irrelevante. Outra caracterı́stica deste tipo de documentos é também o fato de
apresentarem uma pequena granulosidade na informação [Bourret, 2007],
isto é, as unidades mais elementares de informação estão ao nı́vel de elementos que suportam apenas dados ou de atributos, não existindo elementos
com conteúdo misto de informação e sub-elementos.
Documentos deste tipo são obtidos por exemplo quando se extrai informação de um BD e cuja informação é convertida para XML. Exemplos
deste tipo de documentos podem ser ordens de compra, ficha pessoal de
um paciente num hospital, registos de informação cientı́fica de vários tipos,
etc.
4.6
Banco de Dados para documentos XML
Como já citado em Capı́tulos anteriores, existem duas formas de armazenamento em se tratadando de documentos XML: ou se armazena os
dados com esta caracterı́stica em BD’s nativos (criado com o propósito
de receber somente dados semi-estruturados, XML), ou se armazena em
BD’s habilitados (XML-enabled, ou também chamados de Bancos de
50
Dados Habilitados para receber documentos XML).
Dentre os BD’s habilitados para receber documentos XML, o principal
deles e usado neste trabalho como objeto de estudo é o Banco de Dados
Relacional.
4.6.1
Banco de Dados Relacional habilitado para receber dados
XML
Segundo [Date, 2004] existem basicamente duas maneiras de armazenar
um documento XML em um BD Relacional:
1. Armazenar o documento inteiro como o valor de algum atributo dentro
de alguma tupla.
2. Dividir o documento e representar suas diversas partes como diversos valores de atributos dentro de diversas tuplas dentro de diversas
relações.
No primeiro itém descrito anteriormente, é definido um novo tipo de
dados e o documento XML é armazenado inteiro em uma respectiva coluna do banco de dados, fato que faz com que informalmente, tal tipo
de armazenamento seja chamado de coluna XML [Date, 2004]. Para armazenar documentos XML nessa abordagem é utilizado os tipos CLOBs
(character large objects) onde todo o documento é tratado como texto
tirando partido das funcionalidades de manipulação de texto disponı́veis
no BD [Novais, 2006] e ainda se forem necessárias manipulações de partes
do texto, o documento terá que ser lido como um todo pelo Banco de dados e posteriormente tratado. Alguns dos fatores que poderiam tornar essa
abordagem uma opção apropriada são:
• Dados usados em sua totalidade e não aos poucos.
• Não são atualizados com frequência relevante.
• Os documentos precisam ser armazenados de forma intácta.
51
Esta abordagem é apropriada para aplicações que visam o consumo
humano final e consistem principalmente de texto em linguagem natural,
[Moraes, 2001].
Considerando ainda a segunda forma de armazenar dados em Banco
de dados Relacionais, o processo de armazamento não envolve quaisquer
tipos de dados novos [Date, 2004], em vez disso, os documentos XML são
divididos em partes - elementos e atributos, por exemplo - essas partes são
então armazenadas como valores de diversos atributos relacionais. Sendo
assim faz-se interessante dizer que neste caso o Banco de Dados não contém
documentos XML.
Porém nessa abordagem, é possı́vel visualizar alguns problemas. Um
documento XML possui uma dada sequência, enquanto que não existe uma
ordenação nos bancos de dados relacionais, como próprio nome diz, existe
uma relação entre as tuplas. Como foi referido anteriormente, o modelo
relacional é constituı́do por três partes: a BD é um conjunto de tabelas,
que são conjuntos de registos, os quais são constituı́dos por campos que
deverão ser atômicos (não podem ser eles próprios coleções de outros subelementos). Os documentos XML apresentam um conceito diferente, no
qual a informação pode ser encarada como árvore de nós, [Novais, 2006].
Outro problema com relação a segunda abordagem citada é que alguma
informação pode ser perdida quando um documento é particionado e se
isso acontecer, se for necessário reconstituir esse documento apartir do
Banco de dados Relacional, o documento gerado não possuirá as mesmas
caracterı́sticas do documento original [Date, 2004].
Visando minimizar os problemas enfrentados com o particionamento ou
o mapeamento do documento XML para as tabelas de um banco de dados
relacional são propostas na literatura dois enfoques: grafos e nı́veis de
granularidade [Graves, 2003].
1. Grafos Na abordagem Grafo [Florescu e Kossamann, 1999], um documento XML é visto como um grafo orientado rotulado cujas arestas
52
são ordenadas e representam relacionamentos hierárquicos entre elementos, entre elemento e atributo, ou entre elemento/atributo e
conteúdo. Diversas alternativas são propostas para o armazenamento
deste grafo em um BD relacional. As duas alternativas mais viáveis
em termos de desempenho são as seguintes:
• Analisando a Figura 4.11, é possı́vel ver que todas as arestas são
mantidas em uma única tabela com colunas que informam o nodo
pai, o nome do rótulo, a ordem da aresta dentre todos os nodos
filhos e uma referência a um nodo filho e ao valor (se houver) do
nodo destino;
Para exemplificar essa alternativa do uso de grafos, será analisado
a figura 4.10 a seguir, e a tabela contento as informações que
possibilitariam a sua ordenação segundo o conceito de grafos na
figura 4.11:
Figura 4.10: Representação do documento XML com o uso de grafos
53
Figura 4.11: Abordagem em Grafo
• arestas com o mesmo rótulo são mantidas em tabelas separadas,
equivalendo a uma tabela para cada tipo de elemento ou atributo. Colunas que informam o nodo pai, a ordem da aresta e uma
referência ao nodo (com um possı́vel valor) são necessárias; Para
visualizarmos este caso na prática, consideremos ainda a Figura
4.10, onde as arestas em rótulo frutos desse gráfo serão exibidas
a seguir:
Figura 4.12: Tabela de rótulo
Surgem então alguns questionamentos sobre qual a abordagem com
relação à grafos seria a mais eficiente, considerar uma unica tabela
(tabela de arestas) ou várias (tabela de rótulos) para o armazenamento
dos documentos, na tabela a seguir é possı́vel distinguir e relacionar
54
os pontos fracos e pontos fortes dessas duas representações em grafos:
Tabela 4.2: abordagem grafo
[Heuser et al., 2005]
Tabela de arestas
Tabela para rótulos
Uma única tabela
Várias tabelas
Bom desempenho para buscas na hier- Desempenho ruim para buscas na hierarquia
arquia do documento
do documento, pois exigem junções
Armazena espaços nulos
Não há desperdı́cio de espaço
Desempenho ruim para buscas por um Bom desempenho para buscas por um deterdeterminado tipo de elemento ou atrib- minado tipo de elemento ou atributo
uto
- Em ambos os casos o desempenho é ruim na reconstrução do documento XML
- Não há distinção entre elemento e atributo
2. Nı́veis de Granularidade
Outro enfoque de armazenamento baseia-se em nı́veis de granularidade (ou de detalhamento) que podem ser definidos para um documento XML [Graves, 2003]. Em função destes nı́veis, um esquema
de armazenamento relacional é definido. Três nı́veis de granularidade
podem ser definidos:
• Granularidade grande: Conforme a figura define uma única
tabela para armazenar todos os documentos XML. As colunas
desta tabela descrevem basicamente o identificador do documento,
seu nome e um campo para o seu conteúdo. Este é o nı́vel com
menor detalhamento de dados XML;
55
Figura 4.13: Granularidade Grande
• Granularidade pequena: define uma tabela para cada tipo de
elemento ou atributo existente em um documento XML, exigindo
colunas adicionais para manter os relacionamentos hierárquicos
entre elementos e a ordem de subelementos ou atributos de um
elemento. Este é o nı́vel de maior detalhamento de dados XML;
Figura 4.14: Granularidade pequena
56
• Granularidade média: define um meio termo entre os nı́veis
de granularidade grande e pequena, ou seja, parte do esquema
do documento é definida de forma estruturada (em geral os elementos de nı́vel superior no documento) e parte é armazenada
na forma de um campo longo. A decisão pelos pontos exatos de
divisão na árvore do documento depende basicamente do nı́vel de
detalhe das consultas desejadas (e conseqüentemente, das colunas que necessitam ser indexadas) e do tamanho de buffer para
transmissão de dados, que pode ser equivalente ao tamanho dos
campos longos.
Figura 4.15: Granularidade Média
Sendo assim é possı́vel observar que o nı́vel de granularidade influencia
diretamente no desempenho das consultas e na performance do banco
de dados relacional como um todo, observemos então a figura, onde
57
é enfatisado algumas caracterı́sticas que se tornam mais evidentes segundo o nı́vel de granularidade:
Figura 4.16: Nı́veis de Granularidade
Quanto maior o nı́vel de granularidade, mais simples é a definição do
esquema relacional e menos detalhes do documento XML são passı́veis de
consulta. No nı́vel de granularidade grande não é possı́vel definir consultas
declarativas com base em valores de elementos e atributos, por outro lado,
não existe um custo associado à reconstrução do documento XML. Estes
prós e contras devem ser considerados quando do projeto do BD relacional.
Sendo assim, ainda faz-se necessário lembrar que o acesso a dados através
de um SGBD deve considerar a estrutura lógica do modelo do BD para
a definição de expressões de consulta. No caso de um BD relacional, a
linguagem SQL é o protocolo padrão para acesso a tabelas. Caso um mapeamento de granulação pequena ou média atributos e elementos estão em
tabelas e podem ser consultados via SQL.
58
4.6.2
XML Native Databases ou (Sistemas de Banco de Dados
Nativos em XML)
O termo ”SBGD XML nativo”surgiu pela primeira vez durante a campanha de lançamento do SGBD Tamino, que foi o primeiro banco de dados
XML a ser desenvolvido. Devido ao sucesso da campanha, o termo passou
a ser usado, desde então [Tamino, 2007]. Bancos de dados XML são um
conjunto de documentos orientados ao processamento de dados, ou seja
possuem a capacidade de tratar os dados Semi-Estruturados, preservando
as caracterı́sticas nativas dos mesmos. Possui um gerenciador de dados que
é capaz de armazenar e extrair dados no formato XML sem a necessidade
de programação [Martins, 2003].
Não há uma definição formal do que é um SGBD XML nativo, entretanto uma possı́vel definição, a qual é bastante aceita, é a que diz que um
SGBD XML nativo [Moraes, 2001]:
• Define um modelo lógico para um documento XML e armazena e
recupera documentos de acordo com esse modelo. No mı́nimo, o modelo deve incluir atributos, elementos, e ordem de documentos. Essa
definição é bastante similar a de outros tipos de SGBD, obviamente
baseada no modelo usado para cada um dos outros tipos de SGBD.
• Tem um documento XML como unidade fundamental (lógica) de armazenamento, assim como um SGBD relacional tem uma linha como
unidade fundamental (lógica) de armazenamento, por exemplo.
• Não necessariamente tem um documento XML como modelo fundamental de armazenamento fı́sico. Ele pode, por exemplo, ser construı́do sobre um banco relacional, hierárquico, objeto-relacional.
Banco de dados XML, também conhecidos como Banco de dados Nativos, possuem uma estrutura própria onde é possı́vel armazenar os dados
XML na forma Nativa, não sendo necessários mapeamentos como no armazenamento em Banco de Dados Relacionais, pois nos Banco de Dados
59
Nativos XML possuem um modelo lógico especı́fico para tratar documentos
XML, SGBD XML fornece acesso direto aos documentos XML e também
a trechos dele, em banco de dados XML nativos é possı́vel armazenar recuperar e modificar os dados, porém para que isto aconteça um documento
XML deve ter no mı́nimo uma Definição de elementos como DTD, por
exemplo, e a ordem dos dados deve ser mantida no documento.
SGBDs XML nativos são, geralmente, mais úteis para armazenar documentos do tipo ”centrado em documentos”porque esses tipos de SGBDs
preservarem caracterı́sticas como ordem, comentários, sessões entre outras,
enquanto que os SGBDs que suportam XML não preservam, uma forma de
tentar manter a ”linguagem natural”e consequêntemente fazer com textos
e informações conservem seu sentido. Além disso, os SGBDs XML nativos
suportam linguagens de consulta XML, o que torna possı́vel uma consulta
do tipo ”Retornar todos os documentos cujo primeiro parágrafo começa
com uma palavra em itálico”. Obviamente que este tipo de consulta não é
muito trivial em outro tipo de SGBD.
4.6.3
Caracterı́sticas de SGBDs XML Nativos
A seguir algumas caracterı́sticas acerca dos SGBDs XML Nativos:
Coleções de documentos
Muitos SGBDs suportam a noção de coleção. Elas têm papel similar às
tabelas em bancos relacionais ou diretórios em um sistema de arquivos. Um
exemplo claro disso é quando se deseja armazenar todos os filmes de uma
locadora. Para isso, pode-se usar uma coleção para armazenar os filmes e
dentro dessa coleção uma coleção de atores de cada filme [Bourret, 2007].
Linguagens de consulta
Quase todos os SGBDs suportam uma ou mais linguagens de consulta,
sendo que as mais populares são a XPath e a XQuery, porém estaremos
60
apresentando também outras linguagens das quais a XPath e a XQuery
aproveitaram algumas caracterı́sticas. No entanto, deve-se levar em conta
na hora da escolha de um SGBD XML nativo a linguagem de consulta que
mais se adequar às necessidades do sistema a ser desenvolvido [Bourret, 2007].
Lorel Um dos primeiros SGBDs criados para armazenar e gerenciar dados
XML e outros tipos de dados semi-estruturados foi o Lightweight Object Repository (Lore) (citado no Capı́tulo 2), Sua linguagem de consulta nativa é a Lorel (Lore Language), cujas principais caracterı́sticas
de acordo com [Pinto, 2003], são:
• É projetada para ser utilizada sob um contexto de um SGBD,
a Lorel suporta, além de consultas, operações de atualização e
exclusão;
• É possı́vel ser utilizada a cláusula WITH para reestruturar os
dados resultantes da consulta, ou seja, criar um novo documento
XML com estrutura diferente;
• A sintaxe das consultas é do tipo SELECT-FROM-WHERE, sendo
bastante semelhante à da SQL.
XQL (XML Query Language) A XQL(XML Query Language) foi projetada por desenvolvida pela XSL Working Group em 1998 apresenta
as seguintes caracterı́sticas principais, [Schuenck, 2004]:
• Os resultados das consultas não retornam documentos com estrutura diferente do documento original;
• Não permite a consulta a várias fontes;
• As consultas formuladas em XQL são baseadas em contextos, que
nada mais são que expressões de caminho com recursos adicionais.
Elas aceitam comparações entre elementos e atributos, e o uso de
funções nativas do XQL.
61
A XQL suporta apenas funções de agregação e operações de conjuntos,
como funções auxiliares às consultas. Além disso, ela não suporta
operações de inserção, exclusão, atualização, criação de esquemas e
visões.
XPATH e XQUERY É por meio da Linguagem XPATH (XML Path
Language) que são explorados o conteúdo sequencial e hierárquico
do documento XML, ou seja, por meio de expressões da linguagem
XPath, é possı́vel identificar ı́tens pela sua localização na estrutura
hierárquica do documento. Path em Inglês significa caminho, ou seja
por meio de tal padrão é possı́vel encontrar uma possı́vel estrutura
para o documento XML e dinâmizar uma consulta a esse documento.
Um path é uma série de passos, ou um caminho para uma localização
do seu alvo [W3C, 1996]. Sendo assim, a sintaxe adotada pelo XPath é
bastante intuitiva, já que ela baseia-se em caminhos, como os caminhos
de um sistema de arquivos. Considere para efeitos de exemplificação
o documento XML a seguir, que caracteriza um pedido de compra
fictı́cio de uma empresa filial para ser enviado a sua matriz.
62
Figura 4.17: Trecho de um documento XML
[W3C, 1996]
Considerando a figura 4.17 uma expressão válida para pesquisar todos
os pedidos realizados é apresentada a seguir, onde todos os elementos ”Pedidos”que são filhos do elemento ”PedidosItens”(No caso do
exemplo citado seria somente um pedido) serão listados:
Figura 4.18: Consulta Xpath
[W3C, 1996]
Na Figura a seguir é possı́vel ver como uma expressão Xpath gera o
seu resultado, observe que a pesquisa feita pelo padrão de consulta
Xpath é feita hierárquicamente:
63
Figura 4.19: A consulta XPath representada no Grafo
[W3C, 1996]
O XQuery ou XML Query é linguagem funcional de consulta à Documentos XML assim como SQL é uma linguagem de consulta para
Bancos de Dados Relacionais. XQuery é baseada numa linguagem
chamada Quilt (uma das primeiras linguagens de pesquisa a Dados
XML) e implementa as facilidades oferecidas pelo XPath e tipo de
dados do XML Schema descritas anteriormente.
Uma consulta XQuery é uma expressão que:
• Lê um documento XML, ou valores atômicos4 ;
• Retorna um documento XML, ou valores atômicos;
• XQuery é suportada por todas os grandes desenvolvedores de
Banco de dados (IBM, Oracle, Microsoft, etc);
• o Xquery se encontra na versão 1.0, e é uma recomendação do
W3C desde 23 de janeiro de 2007. [W3C, 1996].
4
conceito herdado do padrão XPath
64
Índices
Um ı́ndice é uma estratégia de otimização de consulta para implementações de Bancos de Dados. Assim como em qualquer banco de dados,
os ı́ndices (links ou ponteiros que interligam dados, atributos ou elementos)
são usados para aumentar a performance em consultas [Santiago, 2004].
Existem 3 tipos de ı́ndices (árvore, hash e binário), e serão descritos a
seguir [Moraes, 2001]:
• Um indice em árvore ordena os dados e permite buscas razoavelmente
rápidas para elementos especı́ficos. O ı́ndice em árvore é geralmente
baseado na idéia da Árvore Binária, onde cada nó pode ser particionado em dois nós filhos;
• Um ı́ndice em hash organiza os dados codificando-os e mapeando-os
em posições de array 5 . São uma forma extremamente rápida de encontrar elementos especı́ficos, mas praticamente inúteis para responder
um intervalo de valores.
• Um ı́ndice binário é indicado quando o campo indexado tem um pequeno número de valores que indicam a categoria do registro do documento, por exemplo o campo sexo (M,F), que é constantemente usada
em consultas. Nesse caso, é criada uma lista dos elementos de cada
tipo.
Quase todos os SGBDs XML nativos suportam a indexação ou interligação de elementos e atributos.
Normalização
A normalização é um processo de eliminar redundâncias e inconsistências
em um Banco de dados, com reorganização mı́nima dos dados. Dentro
deste contexto, a normalização de dados em um banco XML nativo é basicamente idêntica a normalização de um banco relacional, ou outro banco.
5
também conhecido como vetor ou lista
65
Uma boa modelagem dos documentos deve garantir que nenhum dado seja
repetido, causando inconsistências. Uma vantagem da normalização em
bancos XML nativos é que eles suportam propriedades multivaloradas,
enquanto que a maioria dos relacionais não suporta. Isso torna possı́vel
normalizar os dados de uma forma mais simples e intuitiva [W3C, 1996].
Integridade referencial
Assim como para normalização, a integridade referencial também é
semelhante a bancos relacionais em banco XML nativos. Em resumo, serve
para garantir a validade de ponteiros entre dados de diferentes tabelas. Em
bancos relacionais, a integridade referencial garante que chaves estrangeiras
apontem para chaves primárias válidas. Em bancos XML nativos, a integridade referencial garante que mecanismos de ”linkagem”apontem para
documentos ou fragmentos de documentos válidos. Tal caracterı́stica esta
diretamente relacionada com a caracterı́stica de Índices [Santiago, 2004].
Escalabilidade
Escalabilidade é a capacidade de manter a alta performance mesmo com
um aumento significativo do tamanho ou carga do banco. Assim como bancos hierárquicos e relacionais, os XML nativos usam ı́ndices para procurar
dados. Isto significa que localizar documentos e fragmentos de documentos
está relacionado com o tamanho do ı́ndice e não com tamanho ou quantidade de documentos [Abiteboul, 2003]. Dado isso, a performance dos
bancos XML nativos é a mesma comparada a outros tipos de bancos. Conseqüentemente, a escalabilidade desses bancos é semelhante a dos outros.
Os bancos XML nativos usam largamente ı́ndices, algumas vezes até
indexando todos os elementos e atributos. Isto pode ser uma solução para
bancos que são mais usados para consultas, mas quando muitas atualizações são feitas, essa performance cai drasticamente.
Quando um banco XML nativo faz consultas por dados não indexados,
66
a performance cai um pouco, principalmente devido à normalização não
tão boa. Então, devem-se levar em conta esses fatores antes de se decidir
por um banco XML nativo. Se a aplicação vai recuperar os dados na
ordem que eles foram armazenados, ele deverá escalar bem. Esse é o caso
de documentos ”centrados em documento”. Caso contrário escalabilidade
pode ser um problema, [Bourret, 2007].
4.6.4
Principais Vantagens em trabalhar com bancos de dados
relacionais
Uma grande vantagem de se utilizar o Banco de dados relacional para
armazenar documentos XML, além da economia que se terá em não ter
de implementar um novo banco, é que é possı́vel fazer consultas, inclusive
consultas complexas utilizando a linguagem padrão de consultas em SGBDs
relacionais, a SQL. Isto é muito útil quando é necessário apresentar varias
visões em diferentes aplicativos 6 .
Outra vantagem é a fácil integração com outros bancos de dados relacionais, dentre outras vantagens que são fornecidas pelos SGBD relacionais,
como controle de Integridade (Impedir que aplicações ou acessos por meio
de interfaces possam comprometer a integridade dos dados armazenados no
banco de dados), Controle de Redundância, escalabilidade, dentre outras
caraterı́sticas já estudadas e mantidas nos Bancos de dados relacionais que
estão no mercado.
SGBDs XML Nativos ainda estão em fase de pesquisa e desenvolvimento, apresentando ainda algumas limitações, ou seja se comparados aos
SGBDs relacionais, que são mais robustos e maduros, os SGBDs nativos
ainda deixam a desejar. Outra vantagem é a maioria das grandes empresas de banco de dados relacionais possuem ferramentas para trabalhar com
XML. Banco de Dados Relacionais, tem a vantagem de possibilitar a coexistência de dados XML e dados estruturados, tornando viável a construção de
6
Formas diferentes, de mostrar as informações aos usuários de acordo com as permissões de acesso
[Silva, 2001]
67
aplicações que envolvam dados de diferentes naturezas com algum esforço
adicional no desenvolvimento dessas aplicações. Os dados, sendo mantidos
em um banco de dados relacional facilitam a integração entre sistemas.
Existem várias ferramentas, bibliotecas para a geração e visualização
dos dados a partir de um banco de dados relacional, facilitando assim o
uso da informação para outros fins além de aplicações Web. O esforço
necessário para a exportação de dados de um banco relacional para XML é
muito pequeno, geralmente demandando apenas uma cláusula ou comando
a mais em SQL. O que às vezes é necessário é a definição de um arquivo
XSL, ou XML schema, para que o XML gerado esteja em um determinado
formato, diferente do padrão gerado pelo SGBD e recuperação após falha.
4.6.5
Principais Desvantagens em trabalhar com bancos de dados relacionais
A representação dos dados é limitada aos relacionamentos, o que pode
ser um problema para algumas áreas. Ou seja, existe uma incompatibilidade entre o que o relacionamento e o elemento XML podem representar,
pois o elemento definido em XML possui mais flexibilidade natural do que
o relacionamento, ou seja, um relacionamento (a linha de uma tabela por
exemplo), é composto de uma quantidade fixa de caracteres (colunas) e
cada uma contém um item dos dados(registros), enquanto um elemento
XML pode armazenar uma quantidade aleatória em caracterı́sticas (como
os subelementos ou atributos) e cada subelemento pode conter mais de um
item dos dados. Neste caso o relacionamento pode ser facilmente expresso
em XML, mas carregar dados de um documento XML arbitrário em um
banco de dados, na maioria das vezes é difı́cil.
Outra desvantagem é a dificuldade de se importar dados XML de um
banco de dados e fazer mudanças em esquemas (schemas dos documentos).
68
4.6.6
Principais Vantagens em trabalhar com Banco de Dados
XML
Uma das vantagens da XML é que sua estrutura é mais expressiva do
que os relacionamentos usados em banco de dados relacionais. O relacionamento é um conjunto desordenado de registros, em que cada um possui um
conjunto fixo de caracteres (ou atributos em documentos XML).
A Estrutura de um elemento XML é muito mais expressiva que a do
relacionamento, porque ela pode conter outros elementos, variar a ordem
e a quantidade de atributos, podendo ter vários elementos do mesmo tipo,
tornando mais fácil representar dados muito complexos.
4.6.7
Principais Desvantagens em trabalhar com Banco de Dados XML
Hoje não existe uma linguagem padrão para recuperação dos dados
XML, ao se implantar um banco de dados XML em uma empresa por
exemplo, pode ser que seja necessário um treinamento para pessoas que
trabalharam com este sistema.
Mesmo existindo algumas linguagens que são padrão da W3C ainda
assim existem algumas limitações como modificação dos dados, hoje são
poucos os banco de dados que fornecem suporte para atualizar dados, na
maioria das vezes é necessário recuperar o dado, alterar e em seguida inserilo no banco novamente.
A seguir é apresentado uma tabela com diferenças relevantes entre os
Bancos de dados Relacionais com Suporte a dados XML e Bancos de Dados
especı́ficos para dados XML:
69
Tabela 4.3: Comparação entre Banco de Dados Relacional e Banco Dados XML
[Heuser et al., 2005]
Banco Dados Relacional
Banco Dados XML
Banco relacional contém tabelas
Banco XML contém coleções
Tabela relacional contém registros com Coleção contém documentos XML com
mesmo esquema
mesmo DTD
Registro relacional é lista de valores
Documento XML é uma árvore de nós
As consultas são feitas em SQL, uma As consultas são feitas em uma linguagem
linguagem de consulta padrão de Banco desenvolvida especialmente para a consulta
de Dados Relacionais ou orientados a de dados XML.
objeto, que usa tabelas como um modelo básico.
O resultado de uma consulta é uma O resultado de uma consulta é um conjunto
tabela contendo um conjunto de linhas. de nós de um ou mais documentos XML
que podem ser empacotados em um nó raiz,
criando um documento XML bem formado.
SQL query retorna conjunto não orde- XML Query retorna uma seqüência não ornado de registros
denada de nós
70
Capı́tulo 5
Benchmark em Bancos de Dados
XML
Este trabalho se propôs avaliar Bancos de Dados escolhidos para exemplificar as duas formas de armazenamento de Dados XML: Banco de Dados
XML Nativo e Banco de Dados Relacional habilitado para receber tais
dados. Sendo assim, este capı́tulo estará apresentando os benchmarks para
BDs XML, softwares que realizam por meio de métricas estabelecidas uma
comparação ou mesmo uma avaliação entre as funcionalidades de um ou
mais Sistemas Gerenciadores de Bancos de Dados, e dentro de um certo
contexto, seja ele uma aplicação fictı́cia ou uma aplicação de natureza real
demonstrar qual BD se faz melhor. Este estudo tem como objetivo validar
as comparações já feitas entre os bancos de dados e orientar o leitor na
escolha entre um Banco de Dados XML Nativo e um Banco de Dados
Relacional para o armazenamento de dados XML, além de demonstrar
como um Benchmark funciona e como pode ser implementado.
5.1
Benchmark
Um benchmark é um programa utilizado para testar a performance de
um software, hardware ou um sistema [Collin, 2002], os quais proporcionam
padrões na avaliação de desempenho de sistemas. Sendo assim, um benchmark para BDs pode ser visto como um conjunto de instruções utilizadas
71
para medir e comparar o desempenho de dois ou mais sistemas de gestão
de base de dados. Isto é feito recorrendo à execução de experiências bem
definidas cujas medidas de desempenho serão usadas para prever o desempenho do sistema [Seng, 2005]. Para isso é necessário que este software
possua caracterı́sticas que garantam a sua credibilidade. Segundo Vieira
[Vieira, 2005], benchmarks de confiabilidade precisam contêr os seguintes
parâmetros, que o compõe:
• Medidas: é o componente responsável por quantificar os resultados obtidos durante as avaliações. Elas podem ser subdivididas em
duas classes: condicionais ou incondicionais. As medidas condicionais
demonstram o funcionamento do sistema e são utilizadas para realizar
comparações entre os ambientes. São obtidas através dos resultados
das experiências. As medidas incondicionais vão representar a confiabilidade global do sistema, como por exemplo, disponibilidade, integridade, entre outros.
• Workload: é o responsável por medir o trabalho do sistema transacional, ou seja, é um sistema que interage com o SGBD para analisar
seu desempenho de trabalho.
• Faultload: componente utilizado quando o benchmark é voltado para
confiabilidade de sistemas.
• Procedimentos e regras: são variáveis dependentes da finalidade
do benchmark, algumas podem ser utilizadas de forma geral, como as
regras para divulgação de resultados finais, construção e aplicação dos
benchmarks de acordo com as especificações.
• Ambiente experimental: é a descrição completa do ambiente e
plataforma necessária para se executar o benchmark.
Desta forma, na especificação de um benchmark são considerados pelo
menos três componentes dos citados anteriormente, [Rahm, 2004]: o sis72
tema a ser testado (SUT - System under Test), a carga de trabalho submetida ao SUT (workload ) que consiste nas operações de teste e, uma ou
mais métricas que são resultantes da monitorização e avaliação do desempenho do SUT o qual inclui o BD de teste. Assim a Figura 5.1 representa a
especificação de um benchmark, onde o trabalho a executar ou o Workload
propõe as consultas, as atualizações ou seja, as operações de teste a realizarem sobre o sistema a ser testado (SUT), a monitoração desse processo
se dá pelo próprio benchmark, o qual identifica problemas ou não durante a
fase de execução. Exemplos de métricas são throughput ou processamento,
tempo de resposta, tamanho do Banco de Dados e relação performance e
custos de manutenção.
Figura 5.1: Estrutura de um Benchmark
[Seng, 2005]
Desta forma Gray em [Gray, 1993] defende o uso de benchmarks levando
em consideração os seguintes princı́pios básicos:
• Relevância: deverá obter as caracterı́sticas do sistema a ser medido,
executando operações comuns no respectivo domı́nio e não repetitivas.
• Portabilidade: deverá facilmente ser implementado em diferentes
sistemas, com diferentes arquiteturas, devem ser portáveis para diferentes plataformas, proporcionando assim, comparativos de desempenhos entre diversos distribuidores de sistemas;
73
• Repetibilidade: quando um benchmark é aplicado no mesmo ambiente, mais de uma vez, ele deve produzir resultados semelhantes;
• Escalabilidade: deverá ser aplicável a sistemas de tamanhos variáveis,
de pequenos a grandes dimensões. Essa caracterı́stica prevê que os
benchmarks realizem avaliações em ambientes com diferentes capacidades.
• Não Intrusividade: na necessidade de avaliar outro ambiente devese realizar o mı́nimo ou nenhuma alteração nesse novo ambiente.
Os benchmarks podem classificar-se como sintéticos, empı́ricos ou uma
mistura entre ambos [Collin, 2002]. Benchmarks sintéticos simulam aplicações
tı́picas de um determinado domı́nio, tanto a nı́vel de operações como de
BDs de teste, ao passo que os empı́ricos utilizam operações de testes e
informação reais.
Para sistemas baseados em modelos mais comuns como o relacional,
foram desenvolvidos ao longo do tempo diversos testes de performance
que estimularam a comparação e consequentemente o aperfeiçoamento dos
sistemas.
Com o aparecimento de sistemas capazes de lidar com XML, foi necessário
criar testes, levando em consideração novos desafios colocados por este
modelo.
Para avaliar BDs voltados a documentos XML, o benchmark precisa
evidenciar algumas caracterı́sticas [Rahm, 2004]:
• Preservação de ordem textual das várias estruturas que compõem os
documentos manipulados.
• Utilização de strings como tipo de dados básicos, cujo armazenamento
e manipulação podem levantar problemas aos sistemas e entrar em
conflito com a forma como os tipos de dados são tratados pelas linguagens de busca.
74
• Queries ou consultas ao banco de dados que envolvem a manipulação
de estruturas hierárquicas complexas e, a preservação de ordem requerem a execução de operações dispendiosas, principalmente quando
o XML está armazenado numa estrutura relacional.
Em [Demurjian, 1985] é apresentado uma metodologia para avaliar sistemas gerenciadores de banco de dados, na qual é enfatizada uma maneira
de obter o tempo gasto entre a requisição de uma consulta e o retorno da
sua resposta.
Nessa metodologia, o autor utiliza o conceito de check-point, que consiste em criar pontos de coletas de tempo nas requisições de consultas ao
banco de dados através de uma linguagem de programação. Os pontos
de coletas de tempo são gravações do relógio do sistema em uma variável.
São utilizados dois pontos de coleta de tempo, sendo um no momento em
que se faz a requisição e o outro quando se obtém a resposta. Com os
dois pontos de tempos coletados, calcula-se a diferença entre eles e como
resultado tem-se o tempo gasto na realização da consulta.
Para BDs XML existem dois tipos de benchmarks: micro-benchmarks
e aplicacionais. Todos eles consistem num conjunto de informação (Banco
de Dados Teste) que pode ter várias versões com tamanhos diferentes e
sobre o qual serão executados um conjunto pré - definido de queries (consultas) [Seng, 2005]
Os micro-benchmarks, são propostos de forma a testarem componentes especı́ficos do sistema com o objetivo de corrigir certos problemas.
Pretendem explorar o impacto na performance do sistema e das caracterı́sticas mais importantes do XML, dispondo de um Banco de Dados
de teste heterogêneo, não inspirado em qualquer aplicação real, sobre o
qual são especificados queries especialmente propostas para testar componentes elementares da linguagem de query (como seleção, joins 1 , etc).
Com um benchmark deste tipo torna-se possı́vel aperfeiçoar as operações
1
consultas que geram como resultado alguma junção
75
mais básicas ao nı́vel do SGBD [Seng, 2005]. Os benchmarks classificados
dessa forma são usados principalmente por projetistas de banco de dados,
ou seja na fase de concepção do mesmo, para detectar erros e possı́veis
pontos de melhora.
Os benchmarks aplicacionais, por outro lado funcionam a um nı́vel
mais elevado, pretendendo medir a performance do sistema como um todo
e não questões especı́ficas. Ele dispõe de um BD de teste, que pode ser
ou não inspirado numa aplicação real, sobre o qual são definidas consultas
que pretendem abranger o maior número possı́vel de caracterı́sticas da
linguagem. Esse tipo de benchmark é utilizado por responsáveis e gestores
da área de tecnologia de informação, na escolha e definição de qual tipo de
BD será usado pela área.
Nas seções seguintes serão apresentados alguns benchmarks já utilizados
pelo mercado para avaliar Bancos de Dados XML:
5.1.1
XOO7
O XOO7 é um benchmark aplicacional desenvolvido na Universidade
de Singapura National University of Singapore. Tal benchmark é baseado
no OO7 que foi concebido para testar a performance de SGBD Orientado
a Objetos. A justificativa para o XOO7 se basear no OO7 advém das
semelhanças entre o modelo de dados XML e o Orientado a Objeto (OO)
[Li, 2001].
Também as consultas foram importados e convertidos do modelo OO
para linguagem de consulta a dados XML, sendo no entanto adicionados
novas queries para melhor explorar as caracterı́sticas do XML, tentando
abranger o máximo das funcionalidades que as linguagens de query deveriam suportar [Li, 2001].
Outro ponto é com relação às consultas do OO7 que abordam uma
perspectiva da informação centrada nos dados, foi necessário expandir as
queries do XOO7 de forma a abordarem uma visão centrada no documento
76
(Ver seção 4.3.4 do Capı́tulo anterior). Estas queries (18 no total) foram
divididos conforme as caracterı́sticas relativas ao banco de dados que está
sendo usado como teste [Li, 2001]:
• Queries relacionais, para testar funcionalidades mais comuns e já testadas em outros benchmarks;
• Queries de navegação para explorar funcionalidades de navegação na
árvore XML;
• Queries de documento, para explorar o suporte à abordagem centrada
nos documentos da informação e ordenação da informação;
Os testes são realizados em um único documento de tamanho fı́xo 4 MB,
ou seja este benchmark não provê a escalabilidade do sistema.
Este benchmark é bastante usado, mas como mostrou esta seção, possui
ainda algumas limitações, o que torna necessário estudos para aprimorá-lo
ou o surgimento de outros como é mostrado em seções seguintes.
5.1.2
XMach-1
Desenvolvida pela University of Leipzig [Bohme, 2000], na Germânia, o
XMach-1 (XML Data Management Benchmark ) vêm caracterizar-se como
outra ferramenta de avaliação de banco de dados para armazenamento de
Dados XML, um benchmark do tipo aplicacional [Bohme, 2000]. Tal ferramenta tem como meta avaliar a performance de sistemas individualmente.
Esta performance do Sistema de Banco de Dados é mensurada aplicando
consultas a este banco de dados e medindo o tempo de resposta. Tal
métrica é chamada de Xqps (XML queries per second ) ou Consultas XML
por segundo.
Também é possı́vel considerar a escalabilidade do Banco de Dados ou
seja, considerar relevante o tamanho do banco de dados, que no caso do
XMach-1 pode ter 10.000, 100.000, 1.000.000 e 10.000.000 documentos,
77
onde esta escalabilidade é indicada pelo operador do sistema ao gerador de
documentos XML [Collin, 2002].
O gerador de dados XML é disponibilizado gratuitamente pelo desenvolvedor do sistema e é open source [Bohme, 2000], tendo os dados gerados
conforme a estrutura da Figura 5.2. Tal estrutura obedece os parâmetros
informados na DTD da Figura 5.3.
Figura 5.2: Estrutura hierárquica do documento de teste gerado pelo gerador de dados
XML - [Rahm, 2000].
78
Figura 5.3: DTD de controle de documentos para XMarch-01,
[Bohme, 2000]
Como visualizado na Figura 5.2, o gerador de documentos XML trabalha com um algoritmo de geração de documentos seguindo o modelo em
árvore. Os dados são gerados em cima da estrutura de um documento
XML (documentXX) que possui elementos filhos autor, código, tı́tulo e
capı́tulos, sendo que cada capı́tulo possui um autor, cabeçalho e seções,
tais seções podem possuir outras seções filhas.
A geração do documento é controlado por parâmetros de acordo com a
tabela a seguir:
79
Tabela 5.1: Parâmetros de geração de
Parâmetro
Número de seções por documento
Número de parágrafos por seções
Número de sentenças por paragrafo
Número de palavras por sentença
Probabilidade de ter um autor que é elemento e atributo
Número de palavras por cabeçalho ou tı́tulo
do elemento.
Probabilidade de ter uma frase sem uma sentença
Probabilidade de ter um link de um elemento
sem um parágrafo
Número de documentos por DTD
documentos
Valor
5-150
1-15
2-30
3-30
0.5
2-12
0.01
0.05
2-100
O benchmark XMach-1 é baseado em uma aplicação web e sua arquitetura mostrada na Figura 5.4 consiste em quatro partes: O banco
de Dados XML, servidor de aplicações, carregador (Loader) e o browser
client 2 . Tal software é um Sistema de Testes para tempo de resposta e
performance do processamento. Ele usa dos servidores de aplicação, uma
vez que são essenciais para melhorar o processamento, escalabilidade e
memória cache. O número de bancos de dados e servidores de aplicação
não é pré-determinado, mas pode ser escolhido de acordo com o objetivo
do processamento [Rahm, 2004].
Figura 5.4: Componentes da Arquitetura Benchmark XMach
[Rahm, 2004]
2
Máquina que acessa o BD Servidor
80
São realizadas 11 operações padrões de acesso ao banco de dados, sendo
elas 8 consultas (Q) e 3 atualizações (A), conforme descritas a seguir
[Collin, 2002]:
• Q1: Retorna um documento dada a sua URL, ou seja, retorna um
documento completo preservando a sua hierarquia e a ordem.
• Q2: Retorna o código de identificação3 e uma URL de um documento
que contém um dado nó, ou seja um dado elemento.
• Q3: Simulando a navegação em uma árvore usando operadores sequenciais, a consulta retorna os nós folha em uma estrutura de árvore de
um documento dado pelo código de identificação daquele documento
seguindo o primeiro filho apartir do nó raiz.
• Q4: Retorna uma lista de elemento,s os quais são nós filhos e são iniciados com elemento seção, conforme Figura 5.2. Tal consulta precisa
apenas do código do documento.
• Q5: Retorna o nome do documento de todos os documentos que pertencem a URL dada.
• Q6: Encontra os capı́tulos de um dado autor , tendo a chave do documento XML, (ver estrutura da árvore indicada na Figura 5.2).
• Q7: Retornar o último código de um documento o qual foi referenciado
pelos últimos quatro outros documentos.
• Q8: Retorna a chave dos últimos 100 documentos atualizados tendo
em vista o atributo autor.
• A1: Inserir documentos tendo uma dada URL.
• A2: Deletar documentos tendo uma dada chave (doc id).
• A3: Atualizar a URL e o tempo para uma dada chave (doc id).
3
Um código único que cada documento tem, uma espécie de chave
81
Em cima destas operações são calculados os tempos de resposta e consequentemente a sua performance.
5.1.3
XBench
O XBench é uma famı́lia de benchmarks que pretende abranger vários
tipos de aplicações de BD, sendo caracterizado como um Benchmark aplicacional, onde a análise elaborada pelo software se faz considerando todas
as operações que o BD realiza [Khandelwal, 2004].
Este benchmark também leva em consideração análises estatı́sticas detalhadas de vários conjuntos de informação XML, onde os estudiosos classificam as aplicações de BDs segundo duas vertentes [Novais, 2006] [Khandelwal, 2004].
A primeira refere-se às caracterı́sticas da aplicação, ou seja tipo de informação do BD, como: (a) datacentric - (centradas nos dados) ou (b)
document-centric - (centrado no documento).
Já a segunda vertente refere-se à forma do BD:(1) Se ele é um single document (único documento ), onde toda a informação do BD está
armazenada num único documento ou ainda se o BD possui (2) multiple document (documentos múltiplos), onde o BD é constituı́do por vários
documentos [Novais, 2006].
Apartir dessas caracterı́sticas, surgem então algumas classes de dados
(fato que começou a ser implementado no XBench, outros benchmarks não
possuiam esta caracterı́stica): a1(Centrados nos dados e único documento armazenado), a2(Centrado nos dados e vários documentos armazenados), b1(Centrado no documento e formado por um único documento),
b2(Centrado no documento e formado por múltiplos documentos).
Tendo em vista tais classificações é importante salientar que a classe
armazenada tem impacto direto na performance do banco de dados.
A avaliação, assim como os benchmarks anteriores apresentados neste
trabalho, é feita tendo em consideração o tempo de retorno das consultas
estabelecidas pelo próprio benchmark. Sendo que neste caso consistem em
82
20 queries que cobrem todas as funcionalidades da linguagem de consulta
XQuery apresentada anteriormente neste trabalho.
Os BDs de teste utilizados têm o tamanho de 10MB (pequeno), 100MB
(normal), 1GB (grande) e 10GB (enorme), ou seja este benchmark provê
a caraterı́stica de escalabilidade [Khandelwal, 2004].
5.1.4
XMark
O XMark foi desenvolvido no Instituto de Pesquisa em Matemática e
Ciência da Computação na Holanda (National Research Institute for Mathematics and Computer Science). Ao contrário do XOO7, do XMach-1 e
do XBench, este benchmark baseia o seu modelo de dados numa aplicação
real, mais propriamente numa aplicação onde ocorre leilões de produtos na
Internet [Busse, 2003].
É um benchmark aplicacional e apresenta na sua maioria caracterı́sticas
centradas nos dados, mas também possui algumas centradas no documento,
com a introdução de descrições textuais associadas a objetos representados
no modelo de dados. Com base neste modelo, é gerado um BD de teste
que consiste num único documento XML recorrendo a uma ferramenta
desenvolvida pelos autores. O documento gerado pode variar entre 10MB
a 10GB [Busse, 2003].
Este benchmark oferece um conjunto de 20 consultas para avaliar a
capacidade de processamento de queries por parte do sistema.
5.1.5
MBench
Outro benchmark desenvolvido para Bancos de dados XML foi o Michigan Benchmark ou MBench desenvolvido na Universidade de Michigan
[Runapongsa, 2003]. Em contraste com seus antecessores ele é projetado
como um micro-benchmark tendo em vista a avaliação de custo de partes
individuais da funcionalidade de um banco de dados. Seu objetivo não é
escolher um ou outro banco de dados em particular e, sim avaliar partes da
83
estrutura e apontar deficiências de acordo com as consultas feitas. Sendo
assim, o conjunto de dados do benchmark é uma estrutura criada para
simular diferentes caracterı́sticas nos dados XML e permitir a predição de
custos com tais operações. Como o XMark e no XOO7, um documento
contém todos os dados possuindo ainda a caracterı́stica de avaliar somente
dados centrados em dados [Runapongsa, 2003].
O benchmark Mbench define 56 operações as quais são definidas e agrupadas de acordo com categorias: consultas de seleção, consultas join (junção)
baseada em valores, consultas join baseadas em ponteiros, operações de
agregação e atualização.
Dentro de cada grupo, geralmente as consultas diferem somente com respeito a caracterı́stica especı́fica como a seletividade para medir a influência
na performance das consultas [Runapongsa, 2003].
Outro ponto que merece destaque nesse benchmark é a questão da escalabilidade do BD, inicialmente ele começa com um tamanho de 50 MB
e cresce de acordo com a fórmula [Runapongsa, 2003]:
50 MB *10n,
onde n = 1,2,3,4...
O Mbench é referência em se tratando de micro-benchmarks, porém estudiosos continuam a busca por aprimorar as técnicas de avaliação realizadas
pelo Mbench.
5.1.6
XCheck
O XCheck é um software benchmark aplicacional para avaliação de armazenamento de dados XML por meio da análise de consultas XPath e
XQuery, [XCheck, 2006].
O XCheck trabalha em duas fases, [XCheck, 2006]: Executando consultas e/ou analisando os dados armazenados nos bancos de dados que o
mesmo suporta.
Na fase em que está executando o benchmark na avaliação do armazena84
mento em BD XML, o software XCheck contabiliza o tempo de retorno
decorrente entre uma consulta e uma resposta a um BD. Opcionalmente,
ele também armazena os resultados das consultas realizadas.
E na fase de análise dos dados, o XCheck elabora uma avaliação fruto
do armazenamento dos dados guardados na fase anterior, retornando estatı́sticas de tempo de execução. Como resultado, é gerado relatórios e
gráficos.
XCheck é licenciado pela GNU (General Public License)licença para
software livre e desenvolvido pelo Instituto de Informática da Universidade
de Amsterdam [XCheck, 2006].
As entradas do benchmark XCheck são arquivos XML e as saı́das podem
ser arquivos XML, HTML, PostScript4 e Gnuplot5
Antes de rodar o XCheck existem algumas caracterı́sticas importantes
a ser consideradas [XCheck, 2006]:
1. Hardware e Software: Mensurar o quanto a execução do benchmark
é confiável não é tão fácil quanto parece. O hardware e os softwares
usados no cenário de avaliação influênciam na execução do programa.
A velocidade da CPU, a quantidade de memória principal, a memória
cache, o sistema operacional e tudo que interfere na compilação são
pontos importantes a serem considerados na execução do benchmark.
Para Bancos de dados desenvolvidos em Java, a máquina virtual java
impoem uma camada de software entre o programa e o sistema operacional que pode alterar o tempo de execução e, portanto a avaliação
do experimento.
Para evitar resultados não confiáveis, XCheck roda o mesmo experimento n+1 vezes e retorna a média desses valores.
2. No XCheck existem métricas de tempo como se seguem para calcular
4
é uma linguagem de programação especializada para visualização de informações, ou uma linguagem
de descrição de páginas [Wikimedia, 2001]
5
O gnuplot é um software que facilita a criação de graficos 2D e 3D para ambientes UNIX, IBM OS/2,
MS Windows, DOS, Macintosh, VMS, Atari [Gnuplot, 2004]
85
a performance [XCheck, 2006]:
• Tempo de processamento do documento: É o tempo que
um BD leva para receber o documento XML de entrada e criar
uma representação interna desse documento no Banco de Dados.
• Tempo de compilar a consulta: É o tempo que uma banco de
dados recebe a consulta e traduz para a estrutura formal interna
do banco de dados, considerando a existência das estruturas de
otimização dessa consulta ou não.
• Tempo de execução da consulta: É o tempo que o banco de
dados leva para executar a consulta. Este tempo inclui somente
o tempo para localizar os resultados da consulta sem retornar a
saı́da. Usualmente, esta é a métrica de tempo mais importante
numa avaliação de um banco de dados.
• Tempo de serialização ou retorno de resultados: É o tempo
que um Banco de Dados leva para representar e retornar os resultados da consulta.
• Tempo total: É o tempo total que um banco de dados leva
para avaliar uma consulta, começando com uma invocação de uma
consulta até as saı́das e resultados válidos. Este tempo é calculado
de acordo com o tempo de processamento, sendo assim, a atuação
da CPU influencia diretamente neste resultado.
3. Bancos de Dados suportados pelo XCheck de forma padrão: XCheck é
designado para comunicar facilmente com os bancos de dados em XML
com uma interface de linhas de comando. Para cada banco de dados
XCheck usa um adaptador (um arquivo XML de configuração) que
contém instruções de execução. A versão 0.1.5, usada neste trabalho,
inclui adapatadores para nove bancos de dados, conforme mostra a
tabela a seguir:
86
Tabela 5.2: Banco de dados suportados pelo XCheck de forma padrão
BD
Versão
Métricas de tempo
SaxonB
8.7
D, QC, QE, T
Galax
0.5.0
T
MonetDB
0.10.3
D, QC, QE, S, T
eXist
1.0
T
Qizx
1.0
QE, S, T
Qexo
1.8.1 alpha
T
Blixem
16 de junho de 2005
T
Xml Task Force
30 de Setembro de T
2004
Arb
15 de agosto de 2005
D, QE, T
Onde D = Tempo de processamento do documento, QC = Tempo
de compilar a consulta, QE = Tempo de execução da consulta, S =
tempo de serialização ou retorno de resultados e T = tempo total.
Tendo ainda a opção de criar um novo adaptador para o seu banco de
dados escolhido, editando um script, [XCheck, 2006].
4. Requerimento de Sistema: O XCheck trabalha com o Sistema Operacional GNU/Linux. Em teoria é possı́vel usar o XCheck com outros
sistemas operacionais, mas só foi testado em diferentes versões do
GNU/Linux. XCheck é escrito na linguagem Perl e necessita de um
interpretador Perl, na versão 5.8.5 ou superior. Há também alguns
Módulos CPAN Peal que necessitam estar instalados. Para gerar os
gráficos do benchmark é necessário que tenha também instalado o
Software Gnuplot na versão 4.0 ou superior.
5. Licença de uso: XCheck é licenciado pela General Public License
(GPL) a qual permite que seja copiado e distribuı́das cópias do software de forma gratuita.
5.1.7
Um comparativo entre os Benchmarks apresentados
Na tabela a seguir é apresentado um resumo acerca das seções anteriores
onde foi descrito caracterı́sticas particulares de cada Benchmark.
87
Tabela 5.3: Resumo de Benchmarks para
XOO7
XBench
XMach-1
Tipo de Centrado
Centrado
Centrado
Dados do nos dados
nos dados/ no docuBD teste
Centrado
mento
(Data
nos docuset)
mentos
Centrado
no documento ou
em dados
Tipo
BD
de
Único Documento
Número
18
de Consultas
(Queries)
Tamanho 4 MB
do BD
Unico documento/
Múltiplos
documentos
20
10MB
10GB
Múltiplos
documentos
8 consultas
+ 3 de atualizações
Bancos de Dados XML
XMark
Mbench
Centrado
centrado
nos
da- nos dados
dos, mas
também
com
algumas
caracterı́sticas
de
centrado no
documento
Único Doc- Único documento
umento
20
-
10MB
- 10MB
10GB de 10GB
documentos
ClassificaçãoAplicacional Aplicacional Aplicacional Aplicacional
XCheck
centrado
nos dados
Múltiplos
documentos
56
20
50
MB∗10n
onde
n=1,2,3,4
Microbenchmark
10MB
10GB
Aplicacional
A diferença fundamental entre os benchmarks apresentados aqui estão
no escopo, ou seja, com a concepção de avaliação imposta pelo benchmark,
todo o sistema de banco de dados em modo multi-usuário, por exemplo no
caso do XMach-1 é avaliada. Todos os componentes do sistema de banco de
dados como processamento de consulta, armazenamento, etc são incluidas
na avaliação.
Os outros benchmarks restringem eles mesmos a avaliação do processo
de consulta em modo usuário único para determinar a performance para
consultas especı́ficas. XMark e XOO7 avaliam consultas complexas.
Enquanto que o Mbench possui um número grande de consultas para
avaliar sistematicamente as principais funções da parte de processamento
de consultas de xml em BDs, [Runapongsa, 2003].
88
-
Se faz necessário estabelecer então, em qual contexto está a aplicação a
ser avaliada, para posteriormente definir qual o benchmark vai avaliar de
forma correta o banco de dados.
5.2
Bancos de Dados escolhidos para o Estudo de
Caso
Existem vários bancos de dados no mercado para acomodar dados XML,
dada a demanda e necessidade. São bancos de dados open source 6 , comerciais, de grande porte, muito conhecidos ou não.
Sendo assim, para demonstrar a aplicação de benchmarks, na escolha
dos BDs de teste, foram considerados algumas caracterı́sticas:
• Boa documentação. É fundamental a existência de documentos (artigos, livros, entre outros) que exponham claramente as caracterı́sticas
do BD bem como forneçam exemplos de utilização, em especial para
utilizadores com pouca ou nenhuma experiência;
• Suporte eficiente. No decorrer da utilização do BD é extremamente
importante existirem fontes de informação adicionais, além da documentação, a qual seja possı́vel recorrer em caso do surgimento de
problemas. Estas fontes podem ser grupos de usuários, fóruns de
discussão ou mesmo, no caso de BDs comerciais, um sistema eficiente
de resolução de problemas e apoio ao utilizador eficiente;
• Provas dadas na área. É importante que o BD seja reconhecido como
sendo uma referência na área. Este aspecto leva consequentemente
a uma maior utilização e à criação de uma grande comunidade de
usuários, o que poderá favorecer os dois pontos anteriores;
• Possibilidade de funcionar na plataforma previamente escolhida, uma
vez que foi definido um benchmark que só é possı́vel rodar em Linux,
6
de código livre, free ou gratuitos [Wikimedia, 2001]
89
o banco de dados escolhido tem que ter suporte para execução em
plataforma Linux.
• Facilidade na obtenção de licenças do respectivo software.
No âmbito deste trabalho, como trata de apresentar a tecnologia de
armazenamento de dados semi-estruturado com foco em XML e ainda
mostrar formas de analisar a performance dos bancos de dados em vista,
usando para fins de exemplificação um benchmark favorável a comparações
e dois bancos de dados escolhidos por atenderem às caracterı́ticas citadas
anteriormente e pelo fato da comunidade de Banco de dados citá-los como
referência em se tratando de armazenamento a documentos XML.
Sendo assim para fins de conhecimento, na tabela 5.4 são apresentados resumidamente alguns Bancos de Dados XML nativos existentes no
mercado, seus respectivos desenvolvedores e sua Licença.
90
Tabela 5.4: Alguns Bancos de dados XML nativos existentes
[Srisvastana, 2004]
Produto
Desenvolvedor
Licença
4Suite, 4Suite Server
Four Thought
Open Source
Berkely DB XML
Sleepycat Software
Open Source
Birdstep RDM XML
Birdstep
Comercial
Centor Interaction Server
Centor Software Corp.
Comercial
DBDOM
K. Ari Krupnikov
Open Source
DBXML
DBXML Group
Open Source
DOMSafeXML
Ellipsis
Comercial
eXist
Wolfgang Meier
Open Source
Tamino
Software AG
Comercial
eXtc
M/Gateway Developments Comercial
Ltd.
GoXML DB
XML Global
Comercial
Infonyte DB
Infonyte
Comercial
Ipedo
Ipedo
Comercial
Lore
Stanford University
Open Source
Mark Logic Content Inter- Mark Logic Corp.
Comercial
action Server
Natix
Data ex machine
Comercial
NaX Base
Naxoft
Comercial
Neocore XML
Xpriori
Comercial
Ozone
Ozone Db org.
Open Source
Sedna XML DBMS
ISP RAS MODIS
Open Source
XDBM
Matthew
Parry,
Paul Open Source
Sokolovsky
XIndice
Apache Software Founda- Open Source
tion
Após conhecidos alguns BDs nativos, faz-se interessante apresentar também
alguns BD’s com suporte a dados XML. De acordo com a tabela apresentada por [Bourret, 2007], ou seja a tabela 5.5, é possı́vel ver que existem
no mercado muitos bancos de dados com suporte a dados XML e que na
grande maioria são softwares comerciais
91
Produto
Access 2002
Cache
DB2
eXtremeDB
FileMaker
Informix
Matisse
MySQL
Objectivity/DB
OpenInsight
Oracle
PostgreSQL
SQL Server
Sybase ASE
UniData
UniVerse
Versant enJin
View500
5.2.1
Tabela 5.5: Bancos de dados com suporte a XML
[Bourret, 2007]
Desenvolvedor
Licença
Microsoft
comercial
InterSystems Corp.
comercial
IBM
comercial
McObject
Comercial
FileMaker
Comercial
IBM
Comercial
Matisse Software
Comercial
MySQL
Open Source
Objectivity
Comercial
Revelation Software
Comercial
Oracle Corporation
comercial
PostgreSQL Global Devel- Open Source
opment Group
Microsoft
comercial
Sybase
comercial
IBM
Comercial
IBM
Comercial
Versant Corp
Comercial
eB2Bcom
Comercial
BD nativo escolhido: eXist
O eXist foi um Banco de dados que atendeu as caracterı́sticas necessárias
aos testes que serão feitos pelo benchmark escolhido, ou seja, existe boa documentação, um número relativamente grande de usuários ativos, suporte
à plataforma Linux e facilidade de obtenção de licenças.
O eXist é um banco de dados open source nativo XML, licenciado sob a
LGPL (Lesser General Public License), desenvolvido em Java com suporte
para todos os padrões colocados pela W3C [Meier, 2004] advindos da XML.
Detalhes da instalação e da manipulação de operações relacionadas ao
BD são mostrados no Apêndice B deste trabalho.
Foi escolhido por ser um dos primeiros BDs nativos XML, portanto
consolidado nesse meio e por ser de código livre, o que facilita sua obtenção
e de materiais para estudo do mesmo.
92
5.2.2
BD com suporte a XML escolhido: Oracle 9i
O Oracle é um Sistema Gerenciador de Banco de dados idealizado por
Larry Ellison em parceria com Bob Miner e Ed Oates no final dos anos 70
[Oracle, 2005]. O projeto do banco de dados oracle veio a se tornar lı́der
no mercado e alavancar a empresa Oracle Corporation.
Ao longo dos anos foram sendo introduzidas inovações e em 1999 foi
lançada o primeiro BD com suporte para XML (versão 8i ).
Dispõe de uma vasta documentação, existindo, por exemplo, dezenas de
livros escritos sobre o tema, e é usada por um grande número de usuários
permitindo assim um intercâmbio de experiências.
Existem inúmeras versões deste BD para diversas plataformas como
Microsoft Windows, Unix e Linux, e é possı́vel a sua utilização com várias
linguagens de programação como Java, PHP, .NET entre outras.
É um software comercial, e para este trabalho foi usado uma versão trial
disponı́vel em [Oracle, 2005]. Foi usado a versão para plataforma Linux,
uma vez que o benchmark usado foi instalado nesse Sistema Operacional.
Detalhes relativos a instalação e algumas operações de manipulação dos
dados estão disponı́veis no Apêndice C.
5.2.3
XCheck - o benchmark escolhido
Para a obtenção da performance dos BDs usados foi escolhido o Benchmark XCheck, pela facilidade das licenças, por se adequar aos Bds que
seriam usados e por proporcinar materiais que sanariam as dúvidas que
viessem surgindo no decorrer do trabalho. Outro ponto forte oferecido
pelo XCheck é o fato de ser um BD aplicacional, o que proporciona a
análise do BD como um todo, operações de consulta, atualização, tempo
de processamento de um documento, compilação, etc. O XCheck usou
como documento XML de entrada dados fictı́cios gerados por um Data
Generator ou gerador de dados XML [XCheck, 2006].
O Gerador de Dados utilizado para os testes é denominado xmlgen e
93
pertence ao pacote de instalação do XCheck. O xmlgen gera dados bem
formados, válidos, centrados em documentos, proporcionando escalabilidade, e gera arquivos de até gigas. O arquivo é gerado apartir de textos
de ShakespeareAutor de romances. O único parâmetro que é necessário
informar ao xmlgen para a geração do documento XML é o tamanho que
terá o documento.
No anexo 1 é apresentado o relatório que foi obtido com os testes realizados pelo XCheck.
5.2.4
Conclusões
A seguir é apresentado algumas das caraterı́sticas que extraimos dos
resultados obtidos do benchmark e ainda da vivência com os estudos e
experiências realizadas.
1. Quando e Por que Utilizar?
Oracle - Quando possui um documento XML mais voltado a dados
(sem muito texto). O oracle possui a caracterı́stica de ser um
Banco Relacional e como tal, contém tabelas que contém registros
com o mesmo esquema. Nesse sentido um registro retorna por
meio da linguagem SQL um conjunto não ordenado de registros.
eXist - O eXist é indicado quando o documento XML é mais voltado
para textos, quando não existe a necessidade de se relacionar os
elementos do documento xml com outros elementos. No apendice
B vimos que um banco eXist contém coleções, que por sua vez
contém documentos XML com mesma DTD. O documento XML
é uma árvore de nós e a linguagem usada pelo eXist, é a XML
Query que retorna uma seqüência ordenada de nós. Outra caracterı́stica que diferencia do oracle é que o eXist foi desenvolvido
para trabalhar especificamente com Dados XML.
2. Esquemas Utilizados
94
Oracle - O Oracle possui como linguagem de suporte para XML,
a linguagem XML Schema. Com isto, é possı́vel determinar a
estrutura do documento XML e seu mapeamento para o esquema
do Banco de Dados.
eXist - O eXist possui uma linguagem de esquema chamada XML
Schema.
3. Armazenamento
Oracle - Para armazenar documentos é utilizado o tipo de dado
XMLType, que oferece suporte nativo para XML, este tipo de
dado pode ser tratado de 3 formas:
• O tipo de dados CLOB, para o armazenamento do documento
inteiro;
• O mapeamento objeto relacional baseado no esquema do documento;
• O armazenamento hı́brido. Pode existir ou não uma validação,
ou seja, não é obrigatório o uso de um esquema antes do armazenamento dos documentos.
eXist - O próprio documento é a unidade de armazenamento, os
documentos são armazenados em coleções, documentos de esquemas diferentes podem estar armazenados na mesma coleção,
sendo assim, é possı́vel fazer o armazenamento de documentos em
massa no eXist. É possı́vel também armazenar um documento
sem validá-lo, porém, existem alguns parâmetros que dirão se este
armazenamento poderá ser realizado ou não, por regras de se um
documento é válido ou não.
4. Linguagem de Consulta
Oracle - Para recuperação de registros armazenados no oracle é utilizada a linguagem padrão de consulta SQL, quando são armazenados dados de um documento XML no oracle também é utilizado a
95
linguagem SQL para recuperação dos registros, independente da
complexidade da consulta, é possı́vel sempre utilizar SQL, inclusive quando se quer recuperar dados de documentos XML com
dados relacionais do banco. As consultas, baseadas na linguagem
XPATH, são feitas através das APIs Java7 e PL/SQL8 do tipo
XMLType.
eXist - Uma extensão da linguagem XPATH, chamada XQuery, é
utilizada, permitindo o acesso a múltiplos documentos. O resultado da consulta é um documento XML cuja raiz contém os elementos encontrados na consulta. A consulta aos dados contidos
nos documentos armazenados no eXist é feita usando a XQuery.
5. Linguagem de Atualização
Oracle - Para atualizar documentos XML armazenados no Oracle,
é feito através da instrução de comando UPDATE.
eXist - São poucos os bancos XML, que oferecem suporte a atualização de documentos XML, para atualizar um documento XML
no eXist, deve-se primeiro recuperar o documento atualizar e em
seguida armazenar novamente.
6. Formas de Indexação
Oracle - Para se criar um ı́ndice para um elemento XML armazenado
no Oracle, deve se levar em consideração o objetivo da consulta
que vai ser realizado sobre o elemento, podendo ser aplicado no
nı́vel de coluna XMLType, sobre o resultado de uma consulta
XPATH ou sobre recursos organizados de forma hierárquica.
eXist - Para criar ı́ndice, deve-se escolher um elemento ou um atributo, sendo aplicável de forma prática e direta.
7
Application Programming Interface ou Interface de Programação de Aplicativos Java é um conjunto
de rotinas e padrões estabelecidos por um software para utilização de suas funcionalidades por programas
aplicativos, ou seja meios para manipular ou validar documentos XML [Federizzi, 2006]
8
Procedural Language/Structured Query Language, ou linguagem procedural de consultas, é uma
extensão da SQL [Takai et al., 2005]
96
7. Interfaces de Acesso
Oracle - Para se consultar os documentos XML armazenados no
Oracle, são utilizadas interfaces padrões, como SQL Navigator,
SQL Plus. O Repositório XML DB permite visualizar hierarquicamente os objetos XMLType armazenados Isto é feito através
dos protocolos HTTP, WebBanco de Dados e FTP, além da API
JDBC;
eXist - Pode ser feita diretamente via banco, como mostrado no
Apendice B, ou ainda via navegação Web, onde se faz a consulta
via url, e o resultado é retornado a página que se fez a consulta.
8. Descrição e análise de desempenho de acordo com o benchmark
Foram realizadas 8 consultas das 20 possı́veis pelo XCheck. Não foram
usadas todas as 20 em função do tempo necessário para rodá-las, exigiria uma máquina exclusiva para tal fim.
As consultas foram feitas em cima de um documento de tamanho 9.40
KB. O relatório emitido demonstra os tempos de processamento do
documento, o tempo de compilação da consulta, o tempo de execução
da consulta, o tempo de retorno da consulta e ainda o tempo total.
É possı́vel observar de acordo com os resultados obtidos no relatório
anexo a este trabalho, que o Oracle obteve tempos menores em relação
ao eXist.
O gráfico a seguir é um gráfico do Tempo médio de execução de todas
as operações realizadas pelo XCheck e emitido pelo mesmo:
97
Figura 5.5: Tempo médio gasto pela CPU para execução das Consultas
Neste trabalho como citado anteriormente não foi considerado a escalabilidade ou seja, o fato de ser acrescentados mais informações no banco
de dados. Mas caso isso fosse considerada ainda existiria os gráficos com
média de tempo para cada documento ou (Average Execution Time for
each Document) e o gráfico para média de tempo gasto em cada consulta
(Average Execution Time for each Query).
5.2.5
Trabalhos Futuros
Com a execução deste trabalho, são deixadas em aberto algumas possibilidades de trabalho futuro:
• Para um maior detalhamento e alcance de resultados mais confiáveis,
a execução de testes com diferentes tipos de informação se mostra
bastante interessante.
• Considerar a escalabilidade do Banco de Dados também viabiliza a
quantificação dos resultados, o que proporciona ao usuário prever
como o Banco de Dados se comportaria diante do armazenamento
98
de documentos maiores. Poderá ser interesse modificar este valor
de acordo com critérios baseados em estudos sobre BDs de médias
e grandes dimensões utilizados em aplicações reais.
• Abordar aspectos quanto a normalização em BDs XML, confiabilidade, integridade referencial, escalabilidade, dentre outras caraterı́sticas
não consideradas neste trabalho.
99
Capı́tulo 6
Conclusão
A Internet vem favorecendo o tráfego e a troca de informações a cada
dia com mais intensidade e em proporções maiores. Por ela, transitam
dados de diversos formatos, com naturezas não pré-determinadas e sem
uma rigidez em seu esquema. É nesse cenário que surge a XML, um formato
que caminha para ser um padrão nesse meio e ainda vêm fortemente sendo
utilizado por aplicações diversas, como intercâmbio e integração de dados.
Sendo assim, este trabalho se propôs de forma cientı́fica, realizar um estudo sobre dados semi-estruturados e focado ao dado XML, abordar suas
aplicações, exemplos práticos e armazenamento. No contexto de armazenamento, foi realizado um comparativo entre as duas principais formas de
armazenamento, ou seja, bancos de dados com Suporte a dados XML e
Bancos de Dados Nativos XML. As comparações quanto a suas funcionalidades também foram feitas e apresentadas.
Foi observado no decorrer deste trabalho que pelo fato dos Bancos de
Dados Modelo Relacional serem ainda os mais utilizados pelo mundo todo,
eles acabam ganhando um destaque maior. Tais bancos de dados são consolidados no mercado e por isso investi-se mais no estudo de técnicas de
adaptação e suporte a dados XML.
É interessante notar que ao longo dos últimos anos todos os grandes fabricantes de BDs (como Oracle, IBM ou Microsoft) têm incluı́do nos seus
produtos suporte a XML, o qual vem sendo sempre melhorado nas sucessivas versões dos seus produtos. Mas, tais investimentos não desmerecem os
100
BDs nativos para dados XML, o que é mostrado no decorrer deste trabalho.
Estes dois cenários tecnológicos, utilização do modelo relacional e utilização de XML, justificam pela sua relevância um estudo comparativo de
desempenho, muito embora isso deve ser feito com bastante cautela, visto
que são modelos diferentes, com grandes particularidades. E isto foi feito
recorrendo a um sistema de testes cuja arquitetura foi baseada em testes de
performance (benchmark ) e ainda a estudos e experiências vividas durante
a implementação deste trabalho.
Para a realização deste trabalho tiveram de ser superados alguns obstáculos.
Sendo que o maior de todos foi a familiarização e posterior utilização de
dois BDs completamente distintos, o Oracle e o eXist, cada um com as
suas particularidades, modo de funcionamento e acesso próprios. Além da
tarefa de conhecer o bechmark XCheck, que é um software poderosı́ssimo,
porém de complexo entendimento.
Outro ponto que merece ser mencinado é o fato da escolha dos dois
bancos de dados Oracle e eXist. Não é de interesse deste trabalho optar
pelo melhor entre os dois BDs escolhidos, mas sim apresentar ao leitor uma
ferramenta que o auxilie nesse sentido.
De acordo com os resultados dos testes que foram realizados, demonstram dois nı́veis de desempenho claros: alto para o modelo relacional e
baixo para o modelo XML. Isto não deixaria qualquer dúvida no momento
de selecionar o BD, isto é, um BD relacional seria a escolha imediata.
No entanto, esta decisão não deve ser tomada com base na medida de
desempenho pura e simples. É necessário ainda contextualizar a situação
e analisar a viabilidade do BD mesmo após o resultado do benchmark.
É importante estar ciente da linguagem de consulta que o banco de
dados utiliza, os meios de atualização que ele proporciona, se existem e
como trabalham os tipos de indexação que favorecem muito o desempenho
das consultas, além das interfaces de acesso e dos meios de manipulação
dos dados.
101
Desta forma, chega-se a conclusão de que além do uso dos benchmarks,
faz-se necessário um estudo das funcionalidades do BD em questão e do
contexto em que será inserido.
Para trabalhos futuros, é recomendado o aprofundamento e uma possı́vel
implementação de benchmarks que proporcionem uma análise mais detalhada, uma vez que por meio do uso do relógio do sistema é possı́vel calcular
o tempo de resposta entre uma consulta e outra, além de informações como
inserção de dados e atualizações possı́veis. Além disso, seria interessante
considerar documentos XML maiores, levando em consideração também
a escalabilidade do sistema, aumentando o tamanho do documento em
proporções pré estabelecidas.
102
Referências
Abiteboul, S. (2003). Gerenciando Dados na Web. Editora Campus Ltda.
Azevedo, A. L. d. (2006). Os primórdios do controle numérico. http:
//www.mundocnc.com.br/historico.htm.
Bohme, T. (2000).
agement.
Xmach-1:
A benchmark for xml data man-
http://dbs.uni-leipzig.de/de/projekte/XML/paper/
XMach-1.html Último acesso em 24/10/2007.
Bourret, R. (2007). Xml and databases. http://www.rpbourret.com/
xml/XMLAndDatabases.htm Último acesso em 20/10/2007.
Busse, R. (2003). Xmark an xml benchmark project. http://monetdb.
cwi.nl/xml/ Último acesso em 30/10/2007.
Carabajal, M. (2006). Sı́ntese histórica do surgimento e evolução da escrita. html://www.academialetrasbrasil.org.br/histescrita.htm,
Último acesso em 10/10/2007.
Collin, P. (2002). Dictionary of Information Technology. Peter Collin
Publishing.
Date, C. (2004). Introdução a Sistemas de Banco de Dados. Campus.
Demurjian, A. S. (1985). Performance measurement methodologies for
database systems. ACM.
Federizzi, G. L. (2006). Apis java para xml. http://www.inf.ufrgs.br/
procpar/disc/inf01008/trabalhos/sem01-1/t2/apis xml java/,
Último acesso em 17/11/2007.
Figueiredo, F. J. V. (2003). Xml e banco de dados. Dissertação (Monografia
em Ciência da Computação) - Instituto de Informática, Curso de Ciência
da Computação Universidade Presbiteriana Mackenzie.
103
Florescu, D. e Kossamann, D. (1999). Storing and querying xml data using
an rdmbs. IEEE Data Engineering Bulletin.
Garber, R. (2004). Business-to-business. http://nasrvzope01.sebrae.
com.br/revsb14/temasdecapa/ecommerce/businesstobusiness
Último acesso em 25/09/2007.
Gnuplot (2004). Gnuplot homepage. http://www.gnuplot.info/, Último
acesso em 30/10/2007.
Graves, M. (2003). Projeto de Banco de Dados com XML. Makron Books.
Gray, J. (1993). Database and transaction processing performance handbook. the benchmark handbook. Morgan Kaufmann Publishers, Inc.
Heuser, C. A., Carina, D., e Vanessa, B. (2005). Xml: Teoria e aplicações.
20o Simpósio Brasileiro de Banco de Dados.
Hunter, D., Cagle, K., e et al., C. D. (2003). Beginning xml, 2nd edition:
Xml schemas, soap, xslt, dom, and sax 2.0. Wiley Publishing, Inc.
Iso (1986). International standards organization.iso/iec is 8879. information processing - text and office systems - standard generalized markup
language. International Standards Organization.
Jackson, M. (1999). Thirty years (and more of) databases. Elsevier.
Junior, E. H. (2006). Sı́ntese histórica do surgimento dos computadores.
http://www.tay.com.br/fip/microprocessadores, Último acesso em
10/09/2007.
Khandelwal, N. (2004).
xml dbmss.
Xbench - a family of benchmarks for
http://se.uwaterloo.ca/∼ddbms/projects/xbench/
Publications.html Último acesso em 30/10/2007.
104
Li, Y. G. (2001). Xoo7: Applying oo7 benchmark to xml query processing
tools.
http://www.comp.nus.edu.sg/∼leeml/papers/CIKM v11.pdf
Último acesso em 20/10/2007.
Martins, A. E. (2003). Análise comparativa de armazenamento,indexação
e manipulação de documentos xml em sgbds nativo e habilitado. Monografia - Universidade Federal do Rio De Janeiro - UFRJ, Instituto de
Matemática – IM,Departamento de Ciência da Computação.
Martins, W. R. (2001). Servidor de documentos xml usando java. Dissertação apresentada ao Instituto de Ciências Matemáticas e de Computação, da Universidade de São Paulo - USP, como parte dos requisitos
para obtenção do tı́tulo de Mestre em Ciências - Área de Ciências de
Computação e Matemática Computacional.
Meier, W. (2004). Open source native xml database. http://exist.
sourceforge.net Último acesso em 01/10/2007.
Meirelles, F. d. S. (2002). Informática - novas aplicações com microcomputadores. Makron Books.
Mello, R. d. S. (2003a).
Dados semi-estruturados.
http://www.
dcc.ufrj.br/∼braganholo/artigos/tutorial.pdf Último acesso em
05/05/2007.
Mello, R. d. S. (2003b).
Gerenciamento de dados xml.
http:
//www.ulbra-to.br/ensino/43020/artigos/anais2003/anais/
ein/minicursoEIN-1.pdf Último acesso em 26/05/2007.
Moraes, C. R. (2001). Estrutura de Dados e Algoritmos. Berkeley.
Navathe, S. e Elmasri, R. (2000). Sistemas de banco de dados - fundamentos e aplicações. LTC.
Novais, J. L. P. (2006). Benchmark de bases de dados de suporte a serviços
de informação. Dissertação apresentada à Escola de Engenharia da Uni105
versidade do Minho como parte dos requisitos para obtenção do tı́tulo
de Mestre em Sistemas de Informação.
Oliveira,
M. B. (2000).
História do computador.
http://
www.novomilenio.inf.br/ano97/97hist01.htm Último acesso em
05/08/2007.
Oracle (2005).
Oracle technology network.
http://www.oracle.
com/technology/software/products/oracle9i/index.html, Último
acesso em 10/11/2007.
Pinto, M. B. Um estudo sobre esquemas para documentos xml. Anais do
V Encontro de Estudantes de Informática do Tocantins. Palmas, TO.
pp. 211-220.
Pinto,
M. B. (2003).
Uma proposta para integração de es-
quemas para documentos xml.
www.ulbra-to.br/ensino/43020/
artigos/relatorios2003-2/TCC/Esquemas XML.pdf Último acesso em
25/09/2007.
Rahm, E. (2000). Multi-user evaluation of xml data management systems with xmach-1. http://dbs.uni-leipzig.de Último acesso em
25/10/2007.
Rahm, E. (2004). Benchmarking xml database systems - first experiences.
http://dbs.uni-leipzig.de Último acesso em 10/10/2007.
Runapongsa,
xml
query
K. (2003).
performance
The michigan benchmark:
diagnostics.
Towards
citeseer.ist.psu.edu/
runapongsa03michigan.html, Último acesso em 26/10/2007.
Santiago, P. C. (2004). Uma estratégia de indexação para dados xml. Dissertação apresentada ao Instituto de Ciências Matemáticas e de Computação da Universidade Federal do Ceará.
106
Schuenck, M. (2004). Linguagem de consulta para documentos xml. http:
//www.inf.ufrgs.br/∼deise/linguagemConsulta.doc, Último acesso
em 29/10/2007.
Seng, H. (2005). Requirements-driven database systems benchmark method.
Berkeley.
Silberschatz, A. K. (1999). Sistema de Banco de Dados. Makron Books.
Silva, E. K. O. D. (2001). Um estudo sobre sistemas de banco de dados
cliente/servidor. http://www.sebraepb.com.br:8080/bte/download/
Inform%C3%A1tica/190 1 arquivo bdados.pdf,
Último acesso em
20/09/2007.
Srisvastana, A. V. (2004). Comparison and benchmarking of native xml
databases. http://www.cse.iitk.ac.in/report-repository/2004/
Y1043.pdf Último acesso em 05/10/2007.
Stanley, Y. W. S. A methodology of application program analysis and
conversion based on database semantics.
Takai, O. K., Italiano, I. C., e Ferreira, J. E. (2005). Introdução a banco
de dados. http://www.ime.usp.br/∼jef/apostila.pdf Último acesso
em 22/09/2007.
Tamino (2007). Native xml management. http://www.softwareag.com/
corporate/products/tamino/ Último acesso em 22/08/2007.
Vieira, M. (2005). Especificação e validação de benchmarks de confiabilidade para sistemas transaccionais.
http://ieeexplore.ieee.org/
iel5/9907/31504/01468665.pdf?tp=&isnumber=&arnumber=1468665,
Último acesso em 28/10/2007.
W3C (1996). World wide web consortium. extensible markup language
(xml)1.1 w3c recommendation 04 february 2005. http://www.w3.or/
TR/xml11/ Último acesso em 04/04/2007.
107
Wikimedia (2001).
Wikimedia:
A enciclopedia livre.
http://pt.
wikipedia.org/wiki/PostScript, Último acesso em 26/10/2007.
XCheck (2006).
A benchmark checker for xml query processors.
http://ilps.science.uva.nl/Resources/XCheck/, Último acesso em
17/11/2007.
108
Apêndice A
XCheck
A.1
Descrição do processo de instalação
Foi usado para instalação do XCheck, o sistema operacional Linux na
distribuição Ubuntu1 e as instruções aqui dadas são válidas para este Sistema Operacional.
Para instalação do XCheck, como já foi falado anteriormente é necessário
que se tenha o interpretador Perl. Para verificar se este interpretador já
existe na sua máquina e em qual versão ele existe, use o comando: perl
-v. No caso de não existir visite a página oficial http://www.cpan.org
e então instale o mesmo. Nesta mesma página para proceguirmos com o
processo de instalação do XCheck é necessário também obter os módulos
CPAN Perl:
• XML::Parser (na versão 2.34 ou superior)
• XML::Checker (na versão 0.13 ou superior)
O processo de instalação desses módulos pode ser dado de duas formas:
• Se o usuário possuir privilégio de root 2 , ele pode instalar o módulo
CPAN usando o seguinte comando: $ perl -MCPAN -e ’nome do
módulo a ser instalado’, onde nome do módulo a ser instalado é substituindo inicialmente pelo XML::Parser e depois pelo XML::Checker.
1
Um sistema operacional completo free baseado em Linux
Permissão para acesso total ao sistema operacional (instalação, remoção, alteração nos softwares e
dados existentes na máquina)
2
109
• Caso o usuário não possua privilégios de root na máquina, é necessário
para a instalação que os módulos sejam baixados diretamente no site,
e que os seguintes comandos sejam dados:
$ tar -xzvf XML-Parser-2.34.tar.gz
$ tar -xzvf XML-Checker-0.13.tar.gz
Sendo que os comandos anterios descompactam os arquivos, uma vez
que eles estão num formato compacto. Após isto os seguintes comandos se
fazem necessários:
$ cd XML-Parser-2.34
$ perl Makefile.PL LIB=/mylib PREFIX=/mylib
$ make
$make test
$ make install
onde /mylib é o caminho do diretório onde você deseja instalar o módulo.
É necessário repetir a sequência de comandos para o diretório XML-Checker0.13.
Após isto é necessário modificar a biblioteca do Perl para o novo caminho dado /mylib, usando o seguinte comandos no bash shell 3 :
$ PERL5LIB=/mylib/lib/perl/x.y.z:/mylib/share/perl/x.y.z
$ export PERL5LIB
Para continuar atualizando o caminho para /mylib é necessário que o
usuário entre agora no editor de comandos tcsh shell, digitando:
$ tcsh
Já na tela do shell tcsh, é necessário entrar com os seguintes comandos:
$setenv PERL5LIB
/mylib/lib/perl/x.y.z:/mylib/share/perl/x.y.z
Onde x.y.z é a versão do interpretador Perl, que o usuário já descobriu
digitando perl -v no prompt de comandos padrão.
3
Prompt de comando padrão do linux. Quando o usuário tecla alt+ F7 no Ubuntu ele já cai no bash
shell, ou editor de comandos
110
Após a instalação dos módulos citados anteriormente é necessário baixar
o XCheck na página ofical no mesmo diretório onde já estão os módulos
CPAN instalados. E na sequência descompactar o mesmo usando o seguinte
comando:
$ tar -xzvf XCheck.tqz
Observe que após descompactados os seguintes arquivos estarão presentes:
• Adapters - Diretório Adaptadores para bancos de dados o qual contém
arquivos com a configuração dos Bds em um conjunto XML;
• experiments - Diretório experimentos, contém todas as entradas de
dados e os arquivos de saı́da que serão gravados nessa pasta (tanto
os arquivos gerados na fase de execução quanto os dados gerados a
fase de análise). Cada experimeno é gravado numa subpasta nesse
diretório chamada experiment;
• dtd - Diretório que contém as dtds para os arquivos XML de teste. O
XCheck usa estes arquivos para validar as entradas;
• repository - Diretório repository contém dois subdiretórios: docs e
queries. Neles você pode armazenar os documentos XML e as consultas;
• XML - Diretório que contém módulos usados pelo XCheck;
• XCheck.pl - Parte principal do software;
• CLAdapter.pl - é o script que processa os adaptadores;
• Utility.pm - Módulo usado pelo XCheck;
• Analysis.pm - Módulo usado pelo XCheck;
• engines.xml - Arquivo de configuração que contém informações sobre
os Bancos de dados;
111
• README (Arquivo em formato txt, com instruções de uso e instalação);
• License (Arquivo com a licença GNU de uso);
Para executar XCheck é necessário usar o seguinte comando no bash
shell : $ ./XCheck.pl, e a tela, conforme figura A.1, é mostrada:
Figura A.1: Instalação do XCheck
Configuração do XCheck
Para configurar o XCheck é necessário que o(s) Banco(s) de Dados esteja(m) instalado(s) no computador em que se encontra o XCheck. Tendo
isto feito, a configuração inicia-se editando o arquivo engines.xml que
está no diretório XCheck.
Este arquivo tem uma estrutura como esta:
112
Figura A.2: Estrutura arquivo engines.xml
Para cada banco de dados é necessário indicar o <path>, ou seja, o
caminho completo de instalação do BD.
Teste de configuração
Depois da fase de configuração é possı́vel testar a funcionalidade do
XCheck pela execução de um exemplo que vem com o pacote de instalação.
O exemplo padrão que acompanha o XCheck é apropriado para o BD SaxonB. Em ordem para executar o exemplo com outro banco de dados é
necessário editar o arquivo experiment.xml que se encontra no diretório experiments/example/ e modificar o elemento <engines> que contém o id de
um banco de dados presente no arquivo de configuração engines.xml. Para
o momento se o usuário quisesse usar o BD Galax é necessário modificar o
arquivo experiment.xml conforme indicado na figura a seguir:
113
Figura A.3: Arquivo experiment
Para testar a execução do XCheck com um exemplo é necessário estar
no diretório principal do XCheck e executar o seguinte comando:
$./XCheck.pl - run example
Então aparecerá uma saı́da como esta:
Figura A.4: Status que o programa dá após o comando $./XCheck.pl - run example
Não havendo nenhum problema com a execução do XCheck, os resultados estarão na pasta experiments/example/output. Neste diretório estará
dois arquivos, com o nome de outcome.xml e outcome.html contendo os
114
tempos de execução e outras informações, como os tamanhos dos resultados das consultas, detalhes técnicos do computador e sistema operacional
usados, etc.
Fase de execução - descrição dos experimentos
Um experimento consiste em entrar com os documentos XML em um
ou mais bancos de dados. O usuário pode especificar qual BD, as consultas
e os documentos que irão participar dos testes no arquivo experiment.xml.
XCheck executa o experimento lendo este arquivo XML e rodando as consultas definidas em todos os documentos.
Todos os testes são armazenados em um diretório comum chamado experiments. É criado um diretório para cada experimento feito, que tem o
nome sujestivo do BD o qual é usado para os testes. Sendo assim, para criar
um novo experimento é necessário criar uma pasta dentro de experiments
e salvar o arquivo experiment.xml. A seguir o arquivo experiment.xml :
115
Figura A.5: Alterando o arquivo experiment
Um experimento é especificado pelos elementos name contendo o nome
do experimento, description, contendo a descrição do experimento, engines, contendo uma lista de banco de dados representados pela palavra
engine no documento, documents, que representa os documentos XML
para teste e as consultas representadas no documento de configuração por
queries.
Os documentos XML são descritos pelo elemento document no arquivo
de configuração citado anteriormente na figura. Para cada documento
é necessário especificar o atributo id, que é um código de identificação
daquele documento, a descrição do documento que é opcional e o nome do
documento (todos os documentos XML devem estar armazenados na pasta
repository/docs no diretório XCheck).
116
O usuário ainda tem a opção de conectar o benchmark a um gerador
de documentos XML, ou seja o gerador cria os documentos de acordo com
os tamanhos especificados pelo operador e isso pode ser útil ao avaliar
a escalabilidade de um Sistema Gerenciador de Banco de dados. Neste
trabalho não iremos abordar a escalabilidade no XCheck.
Para rodar nosso experimento, use o comando
.XCheck.pl - run teste nadia
onde teste nadia foi o diretório criado dentro da pasta experiments e
dentro de teste nadia já está o arquivo configurado com as especificações
do BD eXist e o Oracle já definidas anteriormente como objeto de estudo.
O Xcheck realiza então as seguintes interações para a realização dos
testes:
Figura A.6: Interações realizadas pelo Xcheck para chegar ao resultado
Na figura ENGINES, DOCUMENTS e QUERIES são os elementos especificados no experiment.xml. É no documento de configuração experiment que o usuário direciona o caminho onde estão armazenados todos
estes elementos.
Durante a fase de execução o XCheck imprime algumas informações de
saı́da informando o status sobre a execução do experimento. Para cada
consulta o XCheck usa a palavra ok para indicar se a execução aconteceu
sem nenhum erro ou a string ”!?” para indicar um erro na execução. No
final da execução o XCheck produz 2 arquivos, chamados outcome.xml
e outcome.html e estes arquivos são armazenados no diretório /experiments/teste nadia/output/ dentro da pasta XCheck.
Por opção padrão o Xcheck executa cada consulta 4 vezes e retorna a
média das 3 últimas consultas. Quando uma consulta retorna um erro
no seu resultado, o próprio Xcheck avança para a próxima consulta. O
117
operador do sistema tem a opção de mudar o número de execuções com o
uso do comando -n num, onde as consultas serão executadas num+1 vezes,
sendo assim o comando:
$ .XCheck.pl -run teste nadia - n 1
diz que as consultas serão realizadas 1+1 vezes, ou seja 2 vezes, visto
que num=1.
É possı́vel também gerar gráficos e o XCheck gera, após a realização da
fase de execução, 5 gráficos:
• plots queries.html
• plots docs.html
• plots 3d.html
• plots engines queries.html
• plots engines docs.html
Outro ponto a ser citado é que o XCheck não armazena os resultados
das consultas que ele faz ao Banco. É armazenado somente o tamanho
dos resultados em bytes no arquivo outcome.html. Caso o usuário queira
armazenar o resultado das consultas deve usar o comando:
$ .XCheck.pl -run teste nadia -s
Sendo que os resultados das consultas serão armazenados em experiments/teste nadia/output.
Para facilitar é possı́vel usar todos os comandos de uma só vez assim,
como por exemplo:
$ .XCheck.pl -run teste nadia -n 2 -p -s, ou seja execute o experimento
teste nadia 3 vezes cada consulta, gerando gráficos (-p) e armazenando o
resultado das consultas (-s).
118
A.1.1
Fase de análise dos dados
Depois da fase de execução de um experimento, o Xcheck pode auxiliar
ao usuário na análise dos resultados obtidos com análises de estatı́sticas e
gráficos. Sendo que, neste ponto a saı́da da fase de execução passa a ser
a entrada da fase de análise dos dados, ou seja o arquivo outcome.xml da
fase anterior passa a ser a entrada da fase de análise dos dados. Sendo que
para executar a fase de análise é usado o comando -data no XCheck, como
se segue:
$ .XCheck.pl -data teste nadia
XCheck lê o arquivo outcome.xml e os resultados da fase de análise
são armazenados no arquivo outcome analysis.html no diretorio experiments/teste nadia/output e os gráficos são arquivados no diretório img
A.2
Como adaptar o XCheck para receber outros
BD’s
É possı́vel adaptar o XCheck para trabalhar com outros Bancos de Dados, além dos Bds que já existem por defaut 4 . Muitos dos BD’s XML possui
uma interface que executa consultas por meio de linhas de comando. O
arquivo adaptador do XCheck para um BD XML deve conter instruções
de execução e uma formal descrição de suas saı́das (resultado de consultas, mensagens de erro, etc). Xcheck interpreta este arquivo XML por
um interpretador Perl, chamado CLAdapter.pl e executa o BD usando as
intruções dadas e suas respectivas entradas.
Neste trabalho foi usado então esta funcionalidade do XCheck para
adaptá-lo ao uso do Oracle 9i e então poder testá-lo. Para conectá-lo
ao XCheck os seguintes passos foram seguidos:
1. Copiar um arquivo de um BD já suportado pelo XCheck e renomeálo para oracle9i.xml, armazenando-o na pasta adapters, no XCheck
4
padrão
119
(mesmo lugar onde estão os adaptadores por defaut);
2. Inserir no arquivo engines.xml, o novo banco de dados. O arquivo
engines.xml se encontra no diretório principal do XCheck.
Figura A.7: Arquivo experiment adaptado ao Oracle
120
Apêndice B
eXist
B.1
Descrição do processo de Instalação
A instalação do banco de dados Exist é bem intuitiva sendo necessário a
JVM, ou Java Virtual Machine que é um programa que carrega e executa
os aplicativos java, visto que como já dito no parágrafo anterior o BD Exist
é desenvolvido em Java.
Figura B.1: Instalação BD Exist
Basta para sua instalação o usuário vá clicando em next e direcione o
local da instalação.
B.2
Alguns conceitos sobre eXist
O Exist utiliza o conceito de esquemas lógicos baseados em coleções
(Collection). Collection é utilizado para se referenciar um diretório de
121
armazenamento de documentos XML. As coleções poderão conter outras
coleções como filhas e não define restrições a qualquer esquema particular
ou tipo de documento XML.
O eXist pode também fornecer um armazenamento de documentos XML
sem esquema em coleções hierárquicas. Usando uma extensão da sintaxe
XPath, usuários podem consultar uma parte distinta da coleção hierárquica
ou mesmo todos os documentos contidos em um BD. Apesar de ser de pouco
peso, a engenharia de pesquisa do eXist implementa um eficiente processo
de consulta em ı́ndices. Um esquema de ı́ndices suporta a identificação
rápida de relacionamentos estruturais entre os nós, tais como pai-filho,
antecessor-descendente ou anterior/próximo. O alcance aos nós reais que
estão armazenados em um documento XML central, não é requerido para
esse tipo de expressão.
Os estudiosos da área citam esse BD, com atualmente o melhor conjunto para aplicações que tratam desde pequenas até grandes coleções de
documentos XML que são pouco atualizadas. eXist fornece um número de
extensões ao padrão XPath para eficientemente processar consultas fulltext,
ou seja em documentos centrados no documento, é possı́vel realizar buscas
por palavras-chave, por proximidade de termos ou através de expressões
regulares.
Toda procura fulltext usa um arquivo de ı́ndice works.dbx, que mapeia
palavras-chave para uma lista ordenada do documento e identificadores de
nós únicos. Assim, quando são efetuadas requisições XPath, o eXist monta
uma varredura completa sobre os ı́ndices de cada nó retornando os dados
com maior eficiência.
122
Figura B.2: Organização Hierárquica das coleções
A seguir são criadas as coleções e armazenamento dos documentos XML.
Figura B.3: Tela de criação de coleções no Banco de Dados XML eXist.
Foi criada uma coleção TCC e entro desta coleção uma sub coleção
chamada Exemplos, onde serão armazenados os documentos aluno.xml e
curso.xml, confome a seguir:
123
Figura B.4: Armazenamento dos documentos aluno.xml e curso.xml no Banco de Dados
eXist
A seguir é possı́vel observar o documento curso.xml após seu armazenamento:
124
Figura B.5: Documento curso.xml após armazenado no banco de dados
125
Apêndice C
Oracle XML
A partir da versão 9i, o oracle apresenta um novo tipo de objeto, que é
o ”XMLType”, que oferece mecanismos para criar, extrair e indexar dados
XML. Com o XMLType, desenvolvedores podem utilizar todo o poder
de um Banco de Dados Relacional e simultaneamente trabalhar em um
contexto XML, enquanto que desenvolvedores XML podem usar todo o
poder de XML e trabalhar simultaneamente no contexto de um Banco de
Dados Relacional [ORACLE, 2004]. A seguir na figura é apresentado a
arquitetura do Oracle XML DB, seus componentes e serviços oferecidos:
126
Figura C.1: Arquitetura do Oracle XML DB
[Oracle, 2005]
C.1
Descrição do Processo de Instalação
Para este trabalho usamos o Oracle na versão 9i, e para facilitar o
entendimento do leitor deste, a seguir são apresentados algumas telas do
momento da instalação. A instalação do oracle se dá de maneira bastante
intuitiva, por meio de um instalador que o orienta o usuário, como pode
ser observado na figura C.2
127
Figura C.2: Instalador Oracle
Após o usuário clicar em próximo, aparece uma tela, figura C.3, que
pede para indicar o local de instalação e na sequência indicar o produto
para instalação, como é mostrado na figura C.3 a seguir:
Figura C.3: Produto a escolher para a instalação
Após isto opta-se por uma instalação personalizada e o usuário faz as
escolhas de acordo com a Figura C.4
128
Figura C.4: opções para a instalação
Estabelece-se o local a ser instalado os componentes e no momento de instalação é possı́vel criar-se o banco de dados para armazenamento, aproveitando esta funcionalidade já é feito isso como pode ser visualizado na figura
C.5, na sequência os componentes listados são instalados conforme tela da
figura C.6
Figura C.5: Criação do BD
129
Figura C.6: Instalação do Componente XML
Após isto aparece para o usuário conforme figura C.7, uma forma de
dar um status das funcionalidades acrescentadas, um resumo do que foi
instalado conforme opção do usuário dos produtos oracle, conforme tela a
seguir:
Figura C.7: Resumo da instalação
As operações seguintes acontecem por defaut, bastando que o usuário vá
clicando em próximo. Uma das últimas telas que aparecem para o usuário
130
dá o status da configuração do Banco de dados e é dada a seguir, na figura
C.8
Figura C.8: Tela de status de configuração
C.2
Alguns conceitos sobre Oracle
Para inserir os documentos XML no Banco de Dados Relacional Oracle
foi utilizado o tipo XMLType. Os dados são armazenados em um tipo
CLOB, um tipo de dados binário, mas espera-se que futuramente poderão
ser armazenados de outras formas. Entre os muitos benefı́cios do XMLType, os principais são:
• A junção dos dois mundos XML e SQL, pois torna possı́vel:
- Operações SQL em contexto XML
- Operações XML em contexto SQL.
• Possui funções pré-definidas para indexação e navegação, entre outras;
• XMLType usa um parser e um processador XML embutidos para obter
melhor performance e escalabilidade;
• O XMLType pode ser usado em conjunto com o comando SQL e
combinado com outros tipos de dados. Por exemplo, pode-se fazer
uma consulta a colunas XMLType e juntar com o resultado de uma
consulta a uma coluna do tipo varchar;
131
Para exemplificar seu uso na prática foram criadas duas tabelas, uma
chamada Aluno (figura C.9) e uma chamada curso (figura C.10).
Figura C.9: Criação da Tabela Aluno no Oracle
Figura C.10: Criação da Tabela Curso no Oracle
Para ambos os casos primeira coluna é do tipo NUMBER e vai identificar
o código de identificação do documento XML que será armazenado. A
segunda coluna é do tipo XMLType onde serão armazenados os dados que
estão no documentos XML.
A inserção dos dados nas tabelas criadas se dá da seguinte maneira:
Figura C.11: Inserir dados na tabela aluno
132
O oracle proporciona aos dados XML as mesmas operações que proporciona a dados com caracterı́stica relacional. Por exemplo, através do
comando Update é possı́vel fazer atualizações em qualquer elemento, os elementos também podem ser removidos utilizando o comando delete. Foram
testados também controle de integridade e controle de transação, da mesma
forma que um Banco de Dados Relacional tratam os dados relacionais,
tratam também os dados de um documento XML, ou seja, as modificações
só são efetivadas após um comando commit, ou são descartadas após um
comando rollback.
No oracle é possı́vel armazenar o documento sem qualquer schema associado. Para fazer a validação de um documento XML após serem armazenados no Banco de Dados esquemas que devem ser do tipo XML
Schema, devem ser previamente registrados no Oracle. Os documento que
são baseados em um esquema são mapeados em tabelas e podem ser acessados através do Repositório XML DB. Utilizando tabelas ou visões do tipo
XMLType é possı́vel indexar os dados, ou seja, a utilização de ı́ndices.
133
ANEXO A
134