PROJETO DE BANCO DE DADOS (27)

Prévia do material em texto

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 con-
victa certeza que sem Ele seria imposs´ıvel concluir este trabalho. Agradec¸o incessante-
mente 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 incen-
tivando 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 . . . . . . . . . . . . . 10
2.1.5 Linguagens de Banco de Dados . . . . . . . . . . . . . . . . . . . . 13
3 Histo´rico e Desenvolvimento dos Bancos de Dados 17
3.1 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 eletro-
mecaˆ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, Mo-
delo em Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.5 Meados da De´cada de 80 - Modelo Relacional . . . . . . . . . . . . 24
3.1.6 Final da De´cada de 80 ate´ atual . . . . . . . . . . . . . . . . . . . . 25
3.2 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
3.3 Bancos de Dados para documentos XML . . . . . . . . . . . . . . . . . . . 34
4 Dados - Sua Representac¸a˜o, sua estruturac¸a˜o e a utilizac¸a˜o de XML 36
4.1 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.2XML 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 67
4.6.5 Principais Desvantagens em trabalhar com bancos de dados rela-
cionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 71
5.1 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
5.2 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 . . . . . . . . . . . . . . . . . . . . 124
vii
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 . . . . . . . . . 33
4.1 Algumas diferenc¸as entre dados Semi-Estruturados e Estru-
turados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 abordagem grafo . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 Comparac¸a˜o entre Banco de Dados Relacional e Banco Da-
dos 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 mu-
danc¸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 tra-
balham 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]. Da-
dos 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 in-
formac¸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 re-
ceber 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 consol-
idac¸a˜o de Bancos de dados espec´ıficos para Documentos XML, chama-
dos 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, estare-
mos 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 admi-
nistrador 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 Ban-
cos 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 pos-
terior acesso.
Desta forma, os Bancos de Dados (BD’s) definidos como Sistemas
Computadorizados que proporcionam meios para armazenamento e proces-
samento de tais dados [Date, 2004], tornaram-se um componente essencial
no cotidiano da sociedade moderna. A partir do momento que a comu-
nidade acadeˆmica e empresarial admite a importaˆncia de aumentar as po-
tencialidades 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 di-
versas, 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 fazeralguma 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 armazena-
dos 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 conven-
cional de fatos, conceitos ou instruc¸o˜es de forma apropriada para comu-
nicac¸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 al-
gum 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 proces-
sar 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 resul-
tados.
Desta forma, a qualidade dos resultados obtidos apartir do uso das in-
formac¸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
1O 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 Sis-
temas 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 represen-
tam 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, cu-
7
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 armazena-
mento. 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 carac-
ter´ı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 carac-
teriza, 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 conve-
niente 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 conti-
nuar 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 in-
formac¸o˜esarmazenadas 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 se-
jam 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 armazena-
mento 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 possibili-
tam 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
2Um 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 comu-
nidade, 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 con-
ceitual, consistindo em uma representac¸a˜o igualmente abstrata do Banco
de Dados em sua totalidade. Do mesmo modo, havera´ uma ”visa˜o in-
terna”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 exis-
tir 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:
3Estaremos falando desses modelos de Banco de Dados de forma cronolo´gica no Cap´ıtulo 2
4Mais 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 cons-
tituem 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 espe-
cial 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 im-
plementac¸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 in-
formac¸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 de-
senvolvida pela IBM, quando ainda era chamada Sequel 2 [Silberschatz, 1999].
Normalmente, os diversos SGBDs relacionais implementamverso˜es da SQL
que possuem algumas pequenas diferenc¸as entre si.
Dentre os mecanismos para consulta aos dados, as principais funciona-
lidades 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 de-
terminada 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 se-
gundo 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 apri-
morando suas func¸o˜es e se especificando a cada aplicac¸a˜o.
Neste trabalho, vamos dividir a Histo´ria dos Bancos de dados em algu-
mas 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 sur-
gimento 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 In-
dustriais, 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 des-
tinadas 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 ali-
nhada 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 proces-
samento de dados. A princ´ıpio a ide´ia era trabalhar os dados e simples-
mente 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 per-
furados (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 encon-
18
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 visu-
alizar 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 processavammilhares 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
1Hollerith 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 desenvolvi-
mento de te´cnicas de armazenamento mais eficazes. A sec¸a˜o a seguir con-
textualiza 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 UNI-
VAC (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 progra-
mas passou a usar o armazenamento em disco [Figueiredo, 2003]. Contudo,
os dados gravados em disco ficaram logo dif´ıceis de organizar e adminis-
trar. Essa situac¸a˜o levou os profissionais a criar pacotes de programas cuja
finalidade era facilitar a manipulac¸a˜o do armazenamento em disco. Surgi-
ram, enta˜o, os chamados sistemas de arquivo [Figueiredo, 2003]. Com eles,
os programadores podiam criar arquivos, armazenar dados e leˆ-los mais
2Estouro 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]
3Quando 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 hashing4.
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 per-
durou e a de´cada de 70 inaugura Sistemas Gerenciadores de Dados.
4Te´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 fa-
cilidades trazidas pelos sistemas de arquivos indexados, era necessa´rio um
sistema capaz de coordenar todos os ”arquivos”, ou seja, os registros ar-
mazenados, 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 deno-
minado 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 Ma-
nagement 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 imple-
mentac¸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 ele-
mentos 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 mode-
lo 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 projetis-
tas. 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 desenvolve-
dores, ou seja, por meio de um trabalho teo´rico de representac¸a˜o de rela-
cionamentos de dados complexos, Codd veio tornar mais simples a estru-
tura 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, abstrain-
do detalhes de como implementar os aplicativos necessa´rios para o bom fun-
cionamento 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, delimi-
24
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 queatendesse 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 Rela-
cional 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 procedimen-
tos 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 Ori-
entados 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 chama-
dos 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, es-
tender o modelo relacional para lidar com aplicac¸o˜es novas. Sa˜o geral-
mente usados em aplicac¸o˜es para objetos complexos, tais como ima-
gens, 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 objeto-
relacionais 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, den-
tre 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 in-
formac¸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 to-
das 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 doc-
umentos 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
5O 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.
6Um 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 especi-
ficac¸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-business7 e e-commerce8. 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 in-
formac¸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 essen-
cial de paradigma. A abordagem padra˜o de dados e´ baseada em uma ar-
quitetura cliente/servidor. O cliente, pessoa ou programa, emite uma con-
sulta que e´ processada. Por sua vez, o servidor responde a esta consulta
[Figueiredo, 2003]. Observe a Figura :
7Come´rcio Eletroˆnico feito entre Empresas [Garber, 2004]
8Come´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 ca-
madas”. 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 adi-
cionam valor aos dados [Abiteboul, 2003].
Observe a Figura :
9Sistemas 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 proces-
samento da consulta no lado do servidor consiste em traduzir a consulta
parao 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 inte-
30
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 Lan-
guage 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 trans-
fereˆ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 com-
ponentes, 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 far-
maceˆuticas, companhias aeroespaciais, automotivas e de telecomu-
nicac¸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 com-
plexidade da SGML, fato ja´ afirmado no to´pico anterior. Partindo
dessa premissa, o trabalho conjunto de um grande nu´mero de em-
presas (Oracle, IBM, Compaq, Xerox, Microsoft, dentre outras) e de
pesquisadores (MIT - USA, INRIA - Franc¸a, Universidade de Keio -
Japa˜o) reunidos noWorld Wide Web Consortium (W3C) 10 em 1996,
com o objetivo de criar um formalismo para facilitar a troca de da-
10O´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 aHypertext Markup
Language (HTML). A principal diferenc¸a entre essas duas lingua-
gens 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 des-
cric¸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, por-
tanto, 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 apresen-
tac¸a˜o na˜o e´ poss´ıvel fazer consultas e isso tambe´m motivou os desen-
volvedores 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
[Heuser et al., 2005]
XML 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 repre-
sentac¸a˜o de dados estruturados11 e semi-estruturados 12, tornando-se
um importante meio de representac¸a˜o no transporte e interoperabili-
dade 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 finali-
dade 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 Da-
dos para armazenamento de documentos XML. Apo´s o despertar dos de-
senvolvedorespara 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 semi-
estruturados (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 do-
11Dados com uma estrutura r´ıgida de organizac¸a˜o, melhor apresentados no pro´ximo Cap´ıtulo
12Uma 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 chama-
dos 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 neces-
sidade 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 na-
tureza 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 as-
pecto 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
OsDados Estruturados sa˜o dados que seguem ummodelo 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 hierar-
quizac¸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 dife-
rentes, 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 cate-
goria 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 Estru-
tura 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 escola-
ridade, experieˆncia, conhecimento em idiomas poderiam em muitos casos
serem campos que na˜o seriam preenchidos e consequentemente estes cam-
pos 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, con-
siderando 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.