Base de Dados em Memória - Dei-Isep

Instituto Superior de Engenharia do Porto
Projecto de Licenciatura de
Engenharia Informática
Computadores e Sistemas
Base de Dados em Memória
Sistema de Indexação
Aluno: Luís Manuel Oliveira Marques
Orientador: Eng.º Alexandre Bragança
Setembro de 2002
IMDB – Sistema de Indexação
Índice
Índice
ÍNDICE..................................................................................................... 2
ÍNDICE DE FIGURAS.............................................................................. 6
ÍNDICE DE TABELAS ............................................................................. 8
AGRADECIMENTOS .............................................................................. 9
PREFÁCIO ............................................................................................ 10
OBJECTIVOS........................................................................................ 12
1. INTRODUÇÃO................................................................................... 14
1.1
Estrutura do relatório................................................................................................. 15
1.2
Soluções comerciais ..................................................................................................... 16
2.
CARACTERIZAR IMDB ................................................................. 18
2.1
IMDB – definições ....................................................................................................... 18
2.1.1
Onde usar..................................................................................................................... 18
2.2
Casos de utilização ...................................................................................................... 19
2.2.1 DataSet - ADO.NET ...................................................................................................... 19
2.2.2 DataSet - Java ................................................................................................................ 22
2.2.3 SQL – IMDB ................................................................................................................. 23
2.2.4 XML – IMDB ................................................................................................................ 25
2.2.5 Motor de indexação MySQL ......................................................................................... 27
2.3
Necessidade de Indexação........................................................................................... 28
2.3.1 Analogia IMBD com XML............................................................................................ 28
ISEP – DEI
2
IMDB – Sistema de Indexação
Índice
2.4
Problemas e pontos a reter ......................................................................................... 29
3.
BTREES ++ .................................................................................... 30
3.1
Introdução – outros sistemas...................................................................................... 30
3.1.1 Árvores ADT ................................................................................................................. 30
3.1.2 Árvores AVL ................................................................................................................. 31
3.1.3 Árvores Red-Black ........................................................................................................ 32
3.2 Caracterização ..................................................................................................................... 33
3.3 Estrutura de uma BTree ..................................................................................................... 33
3.3.1 Altura das b-Trees.......................................................................................................... 34
3.4 Operações em BTrees.......................................................................................................... 35
3.4.1 B-Tree-Search(x, k) ....................................................................................................... 36
3.4.2 B-Tree-Create(T) ........................................................................................................... 36
3.4.3 B-Tree-Split-Child(x, i, y) ............................................................................................. 37
3.4.4 B-Tree-Insert.................................................................................................................. 37
3.4.5 B-Tree-Delete ................................................................................................................ 39
3.5 Exemplos de aplicações de BTrees ..................................................................................... 39
3.5 Aplicações............................................................................................................................. 42
3.5 Problemas e vantagens ........................................................................................................ 42
4.
SGBDOC ........................................................................................ 45
4.1
Considerações Genéricas ............................................................................................ 45
4.1.1 Definição de Documento no SGBdoc............................................................................ 46
4.1.1.1 Analogia com XML ............................................................................................... 48
4.1.2 Definição de colecção.................................................................................................... 48
4.1.3 Funcionamento interno – parâmetros e funções............................................................. 50
4.1.4 Indexação sobre uma colecção....................................................................................... 51
4.1.4.1 Porquê a indexação no SGBdoc? ........................................................................... 53
4.2
Exemplo de utilização ................................................................................................. 54
4.3
Exemplos de uso reais – I2S ....................................................................................... 55
4.3.1 CODOMO...................................................................................................................... 55
4.3.1.1 Arquitectura ........................................................................................................... 56
4.3.1.2 Características Gerais das Aplicações baseadas em CODOMO ............................ 58
ISEP – DEI
3
IMDB – Sistema de Indexação
Índice
4.3.1.2.1 Desempenho ................................................................................................... 58
4.3.1.2.2 Interoperabilidade........................................................................................... 59
4.3.1.2.3 Escalabilidade................................................................................................. 59
4.3.1.2.4 Programabilidade ........................................................................................... 60
4.3.2 EURO – BigBang .......................................................................................................... 60
5.
BTREES NO SGBDOC .................................................................. 63
5.1 Procedimento anterior à inserção de BTrees .................................................................... 63
5.1.1 Exemplo de navegação sem BTrees............................................................................... 64
5.2 Inserção de funções da árvore no SGBdoc ........................................................................ 66
5.2.1 Descrição das funções elaboradas.................................................................................. 71
5.2.1.1 Abertura de indexação - lps_f_Idx_Open .............................................................. 71
5.2.1.2 Guardar dados - lps_f_Idx_Save ............................................................................ 71
5.2.1.3 Fecho da indexação - lps_f_Idx_Close .................................................................. 72
5.2.1.4 Inserção de uma nova chave - lps_f_Idx_Insert ..................................................... 72
5.2.1.5 Eliminação de uma chave - lps_f_Idx_Delete........................................................ 72
5.2.1.6 Pesquisa de uma chave - lps_f_Idx_Find ............................................................... 72
5.2.1.7 Posicionar no início - lps_f_Idx_First .................................................................... 72
5.2.1.8 Posicionar no fim - lps_f_Idx_Last ........................................................................ 73
5.2.1.9 Posicionar próximo - lps_f_Idx_Next .................................................................... 73
5.2.1.1 Posicionar anterior - lps_f_Idx_Prev...................................................................... 73
5.2.2 Problemas encontrados no desenvolvimento ................................................................. 73
5.2.3 Funções de posicionamento ........................................................................................... 74
5.2.4 Guardar árvore e reabri-la.............................................................................................. 74
5.3 Resultado final ..................................................................................................................... 75
5.3.1 Exemplo de navegação com BTrees .............................................................................. 76
5.3.2 Comparação de resultados ............................................................................................. 78
5.4 Inovações futuras................................................................................................................. 78
6.
CONCLUSÕES .............................................................................. 80
GLOSSÁRIO E LINGUAGEM ESPECÍFICA......................................... 82
REFERÊNCIAS ..................................................................................... 86
BIBLIOGRAFIA ..................................................................................... 87
ISEP – DEI
4
IMDB – Sistema de Indexação
Índice
ÍNDICE REMISSIVO.............................................................................. 88
ANEXOS................................................................................................ 91
A.1 I2S, S.A. – Informática Sistemas e Serviços ..................................................................... 91
A.2 XML..................................................................................................................................... 92
A.3 ADO ..................................................................................................................................... 94
A.4 .NET..................................................................................................................................... 97
ISEP – DEI
5
IMDB – Sistema de Indexação
Índice de Figuras
Índice de Figuras
Figura 1 – Modelo do DataSet ........................................................................................ 20
Figura 2 – Os suportes do DataSet e interligação com o DapaApdater SQLDataAdapter .................................................................................................... 21
Figura 3 – Encaixar documento XML numa tabela de memória.................................... 26
Figura 4 – Exemplo de SQL em XML-IMDB................................................................ 26
Figura 5 – SQL (UPDATE e DELETE) em XML - IMDB............................................ 26
Figura 6 – Exemplo de uma árvore ADT ....................................................................... 31
Figura 7 – Exemplo de árvores AVL e não AVL ........................................................... 31
Figura 8 – Exemplo de uma árvore red-black ................................................................ 32
Figura 9 – Cálculo da altura de uma BTree .................................................................... 34
Figura 10 – Algoritmo de pesquisa numa BTree ............................................................ 36
Figura 11 – Algoritmo de criação de uma b-tree vazia................................................... 36
Figura 12 – Algoritmo de divisão do filho numa BTree................................................. 37
Figura 13 – Algoritmo de inserção com um nó cheio..................................................... 38
Figura 14 – Algoritmo de inserção numa árvore com um nó vazio................................ 38
Figura 15 – Exemplo de uma b-tree................................................................................ 39
Figura 16 – Sequência de pesquisa numa b-tree............................................................. 40
Figura 17 – Sequência de inserção de um valor numa b-tree com split (divisão) .......... 42
Figura 18 – Documentos no CODOMO ......................................................................... 47
Figura 19 – Exemplo do código necessário para a criação de um documento no SGBdoc
................................................................................................................................ 50
Figura 20 – Laboratório do CODOMO .......................................................................... 56
Figura 21 – Arquitectura CODOMO .............................................................................. 57
Figura 22 – Ilustração do problema encontrado na migração dos dados EURO – Big
Bang I2S ................................................................................................................. 62
Figura 23 – Carregamento dos dados para uma colecção............................................... 64
Figura 24 – Lista de dados obtidos a partir do AS/400 .................................................. 65
Figura 25 – Obter um registo não usando indexação...................................................... 66
Figura 26 – Exemplo de incrementação de uma função no SGBdoc ............................. 69
ISEP – DEI
6
IMDB – Sistema de Indexação
Índice de Figuras
Figura 27 – Exemplo do código lps_f_Idx_Open ........................................................... 71
Figura 28 – Ilustração de como guardar um árvore (idx_save) e reabrir a árvore
guardada.................................................................................................................. 75
Figura 29 – Carregar dados na b-tree.............................................................................. 76
Figura 30 – Pesquisa de um valor na árvore balanceada ................................................ 77
Figura 31 – Posicionar na colecção usando indexação................................................... 78
Figura 32 – Hierarquia de indexação .............................................................................. 79
Figura 33 – Exemplo de documento XML ..................................................................... 92
Figura 34 – Permuta de dados entre dois sistemas distintos com XML ......................... 94
Figura 35 – Objectos e colecções ADO.......................................................................... 97
ISEP – DEI
7
IMDB – Sistema de Indexação
Índice de Tabelas
Índice de Tabelas
Tabela 1 – Configuração de relações entre tabelas num DataSet usando XML............. 21
Tabela 2 – Capacidades do SQL – IMDB ...................................................................... 25
Tabela 3 – Analogia entre o que suporta SGBdoc e o que suporta a tecnologia XML .. 48
Tabela 4 – Tabela de operações de indexação ................................................................ 51
Tabela 5 – Tabelas de exemplificação de movimentação de operações......................... 52
Tabela 6 – Funções de posicionamento necessárias para uma indexação ...................... 52
Tabela 7 – Mapeamento das funções de BTree ++ para o SGBdoc............................... 68
Tabela 8 – Associar um retorno a uma função do SGBdoc............................................ 68
Tabela 9 – Descrição dos parâmetros de uma função a inserir numa dada tabela do
SGBdoc de modo a definir o comportamento da função........................................ 70
Tabela 10 – Funções de posicionamento no SGBdoc..................................................... 74
Tabela 11 – Descriçãos dos objectos e colecções ADO ................................................. 96
ISEP – DEI
8
IMDB – Sistema de Indexação
Agradecimentos
Agradecimentos
Neste último ano de curso tenho que começar por agradecer ao ISEP, por todos
os momentos lá passados e por tudo aquilo que me foi ensinado, neste contexto, como é
óbvio, está inserido o DEI e todos os seus professores.
Também gostaria de agradecer a pessoas que trabalham comigo na I2S como o
Sérgio Ribeiro, Sérgio Nogueira, Filipe Miranda, António Correia, Rui Duarte, Nuno
Ferreira, Paulo Vilela, entre outros...
De seguida tenho de começar por agradecer a todos os meus colegas de curso,
mas terei obrigatoriamente de agradecer de um modo mais explícito a alguns... Deste
modo os meus agradecimento vão para o Sérgio Lopes, Américo Silva, Sérgio Matos,
Ricardo Teixeira, António Amaral, Vítor Moreira, Anabela Vieira, Celina Pereira, entre
outros...
Apesar de já todos os professores terem sido evidenciados, não posso deixar de
salientar aquele que mais me apoiou e ajudou como ninguém para a conclusão deste
projecto, até por acaso é meu orientador... Obrigado, Eng.º Alexandre Bragança...
Tenho também de agradecer à minha família, pais e irmãos por todo o apoio...
E por último ao meu anjo... a minha mais que tudo Sandra, por ter estado sempre
por aqui...
ISEP – DEI
9
IMDB – Sistema de Indexação
Prefácio
Prefácio
O projecto apresentado neste relatório diz respeito ao curso de licenciatura em
Engenharia Informática – ramo de Computadores e sistemas – do Instituto Superior de
Engenharia do Porto (ISEP).
A escolha deste projecto começou em Março, após ideia do Engenheiro
Alexandre Bragança, já que esta era uma tecnologia a inserir numa aplicação existente
na empresa I2S S.A. – Informática Sistemas e Serviços (tecnologia abordada neste
relatório – SGBdoc).
O projecto sobre o qual me debrucei tenta abordar alguns dos temas mais
importantes dos nossos dias:
o Manipulação em memória de elevadas quantidades de dados
o Indexação de dados.
É, portanto, importante desde já referir que este estudo é bastante interessante.
Além do relatório, é também importante abordar todo o curso onde são
adquiridos outros valores, além dos já conhecidos académicos, pedagógicos e técnicos
de cada área. Posso evidenciar que os valores incutidos ao longo de um curso são a
experiência que mais tarde nos ajuda, no decorrer de uma vida ao nível profissional e
pessoal. No ISEP encontrei amigos, e ideais, mas também descobri a verdadeira
essência que devemos personificar nos objectivos que temos pela nossa vida fora.
Contudo, e apesar de já estar activo profissionalmente, sinto que uma nova fase
se aproxima e para a qual novos obstáculos irão ser encontrados, mas também sinto que
todos os momentos passados no ISEP, e todos os amigos que lá conheci, estarão sempre
comigo para me ajudar a ultrapassar esses difíceis obstáculos para os quais todo o apoio
é pouco.
ISEP – DEI
10
IMDB – Sistema de Indexação
Prefácio
A conclusão deste relatório e deste curso constituem um objectivo alcançado, no
entanto existem dois sentimentos que se contrapõem… um, é lógico, a conclusão do
curso... o outro será o deixar para trás todos os bons momentos passados na bela casa de
ensino que é o ISEP.
ISEP – DEI
11
IMDB – Sistema de Indexação
Objectivos
Objectivos
Para o desenvolvimento de um projecto, trabalho ou serviço, é sempre
necessário definir certos limites (objectivos), de modo a tornar a produção o mais
concisa possível, baseado nesta ideia foram também idealizadas certas fronteiras na
elaboração deste projecto.
O projecto efectuado tem como base inicial o estudo de bases de dados
indexadas em memória, e um estudo aprofundado de forma (s) de implementar este tipo
de tecnologia.
A principal vertente deste projecto é demonstrar como poderemos ter o referido
objectivo, manuseando um determinado conjunto de dados (n bytes ou uma base de
dados) em memória sem tornar o sistema insustentável (Bases de Dados em Memória).
Análises efectuadas permitem chegar à conclusão, que um modo eficaz de efectuar esta
gestão será através de árvores balanceadas, mais concretamente BTrees++. O objectivo
deste projecto é o de demonstrar a viabilidade do descrito, assim como, abordar um
exemplo concreto do uso desta tecnologia.
Um dos grandes problemas de tecnologias como o XML (para melhor
compreender o XML ver Anexo A.2) é o manuseamento de dados em memória que por
vezes é bastante complexo de suportar, provocando com que a referida tecnologia possa
ser bastante lenta. Tal como o XML, também outras tecnologias sofrem deste problema,
mas principalmente aplicações que trabalhem com Internet (caso do XML), em que a
velocidade de processamento é deveras importante e, todos os pedaços de tempo têm
que ser devidamente aproveitados. Ainda mais impraticável é a indexação de bases de
dados em memória.
O SGBdoc (ver capítulo 4) é um sistema gestor de base de documentos,
permitindo a representação e gestão de documentos, esta é uma tecnologia muito em uso
na empresa I2S (ver Anexo A.1).
ISEP – DEI
12
IMDB – Sistema de Indexação
Objectivos
Tal como o XML também o SGBdoc pode sofrer da referida dificuldade (gestão
de bases de dados em memória e sua indexação), devido a elevadas quantidades de
informação existentes em memória e, ao seu manuseamento. Para exemplificar bases de
dados indexadas em memória foi usado então, o SGBDoc.
Além dos conceitos referidos, também outros serão abordados neste relatório,
mais explicitamente tecnologias relacionadas com a gestão de base de dados em
memória (indexação) e, tecnologias relacionadas com SGBdoc.
Em forma de conclusão, os objectivos deste projecto são um estudo profundo do
uso de bases de dados indexadas em memória (alguns exemplos existentes), usando
árvores balanceadas no SGBDoc (CODOMO), e tirando deste estudo ideias sobre como
melhor aplicar estes conceitos no futuro.
ISEP – DEI
13
IMDB – Sistema de Indexação
Introdução
1. Introdução
O problema que se nos coloca é de como tratar um grande volume de dados em
memória de forma eficaz. Este problema coloca-se hoje em dia com particular
significado, pois o processamento das eAplicações consiste em grande parte no
processamento de documentos (por exemplo em formato XML) com grande volume de
dados e, estruturas relativamente complexas. Muitas vezes esse processamento também
é complexo, pelo que é essencial que seja efectuado de forma rápida. Este problema tem
sido alvo de estudo recente nomeadamente no contexto do XML. A I2S encara também
este problema numa outra vertente que é a do seu Sistema Gestor de Base de
Documentos, SGBDoc.
O projecto que vou apresentar de seguida é relacionado com a indexação de
bases de dados em memória. Hoje em dia existem bases de dados com grandes
quantidades de informação, o que traz graves problemas, nomeadamente o seu
carregamento de um disco rígido (hoje em dia trinta mil milhões de bytes para um disco
é perfeitamente normal) para memória (uma memória para um bom PC será de duzentos
e cinquenta e seis mil bytes), para isto bastava imaginar que existisse uma base de dados
com quinhentos milhões de bytes! Primeiramente este projecto tenta ultrapassar este
obstáculo, no entanto poderemos considerar outra dificuldade a ultrapassar, que será a
de podermos ordenar/indexar uma coluna! Como é lógico, seria impraticável indexar
tamanha quantidade de informação, que não fosse de um modo que nos permitisse
indexar em tempo útil um sistema deste tipo. A solução poderá ser o uso de árvores
balanceadas – “BTrees ++”.
IMDB é uma sigla que tem como significado base de dados em memória (IMDB
– “In Memory Database”). IMDB é, então, a representação fiel de uma base de dados
existente, por exemplo num disco rígido, em memória, podendo eventualmente efectuar
a sua gestão (transações, ou manipulação da pretensa informação existente nas tabelas).
O Sistema de Indexação que é parte integrante do projecto vem tornar as IMDB mais
eficiente.
ISEP – DEI
14
IMDB – Sistema de Indexação
Introdução
No projecto irá ser apresentado um exemplo prático do uso de IMDB com
“BTrees ++” num projecto existente na I2S – SGBdoc, será exemplificado como foi
feito o mapeamento de funções de modo a obter um sistema de indexação no referido
projecto – SGBdoc.
Neste âmbito tentarei ao longo deste relatório enquadrar Bases de Dados em
Memória e, a sua necessidade de indexação, assim como os diversos usos que, cada vez
mais, são importantes nos dias que correm.
1.1 Estrutura do relatório
Para a elaboração deste relatório tentei formular uma compreensão progressiva
de toda a informação, começando por definir determinados conceitos teóricos até à parte
prática que elaborada.
O relatório é constituído por cinco capítulos principais, a saber:
o Introdução – efectuação de uma introdução ao tema.
o IMDB (bases de dados em memória) – exemplificação teórica do que se
entende por IMDB e alguns exemplos de uso.
o BTrees++ – Definições relacionadas com árvores balanceadas (sistema
usado na parte prática elaborada neste projecto)
o SGBdoc – Abordagem a esta aplicação da I2S, sistema também usado na
parte prática do projecto
o BTrees no SGBdoc – Parte prática elaborada para o projecto um sistema
de indexação.
Os estrangeirismos e alguns termos técnicos são representados em itálico, e
algumas das suas definições encontram-se no Glossário e linguagem específica.
As referências encontram-se marcadas com um número entre parênteses rectos,
por exemplo [1].
ISEP – DEI
15
IMDB – Sistema de Indexação
Introdução
O capítulo em falta será o 6 – Conclusões (conclusões do projecto).
1.2 Soluções comerciais
Como já foi dito anteriormente as empresas têm bases de dados em crescimento
exponencial e, como tal, é essencial uma boa forma de as manusear.
Nem todas as bases de dados contêm milhões de registros a necessitarem de
muitos gigabytes de armazenamento, contudo existem algumas que ocupam esse espaço
gigantesco.
Por
exemplo,
a
TELSTRA,
uma
companhia
australiana
de
telecomunicações, mantém uma base de dados de facturamento ao cliente com mais de
51 biliões de linhas com 4,2 terabytes de dados. Para que a base de dados seja útil e
utilizável, ela deve suportar as operações desejadas, tais como a recuperação e o
armazenamento, de uma forma eficiente e rápida [1].
Existe também uma base de dados de nome Polyhedra que é um servidor de
base dados relacional com respostas em tempo real, esta foi desenhada para aplicações
especiais. Aplicações que precisem de respostas em tempo real para determinadas
variações de informação, com sistemas complexos e com tolerância a falhas
(transacções e sempre disponível). A base de dados Polyhedra tem como requisito um
bom desempenho temporal (rapidez), podendo variar desde uma comunicação sem fios,
a uma gestão normal de network, ou até mesmo funcionar com a Internet. Como o
objectivo é funcionar em tempo real, pretende-se que se faça a menor computação
possível e, que responda em tempos aceitáveis. Funciona também em diversas
plataformas (Unix, Windows). Para que sejam possíveis todas estas capacidades
(principalmente respostas em tempo real) é essencial o facto da base de dados residir
sempre em memória, sem esta característica seria incomportável (tempo de computação
muito superior) [2].
Existem também outras bases de dados com este tamanho, basta pensar numa
base de dados com toda a informação militar de um país, ou a informação dos
contribuintes portugueses (e aceder a estes dados pela Internet!). O XML, a tecnologia
ISEP – DEI
16
IMDB – Sistema de Indexação
Introdução
mais usada na Internet para estes casos, apresenta bastantes dificuldades de performance
para lidar com esta quantidade de informação.
Pode-se considerar urgente a investigação de novos métodos para conseguir
manipular elevadas quantidades de informação, de modo a determinados sistemas não
se tornarem incomportáveis.
ISEP – DEI
17
IMDB – Sistema de Indexação
2.
Caracterizar IMDB
Caracterizar IMDB
2.1 IMDB – definições
IMDB é uma sigla que representa “In Memory Database” (Bases de Dados em
Memória), uma sigla cada vez mais usada nos dias que correm, extremamente
importante pelo crescimento exponencial do tamanho das bases de dados e, da
capacidade dos suportes magnéticos mais vulgares (discos rígidos, CDs, entre outros).
No entanto a referida sigla aparece não só com intuito de manipular bases de dados com
elevada quantidade de informação em memória “RAM”, mas, também com o propósito
de se encontrar um solução viável no sentido de manipular essa mesma base de dados
em memória.
IMBD teve já associado ao conhecido Dataset da Microsoft, sobre o qual
falaremos mais à frente, pois, primeiramente o nome de Dataset seria IMDB, mas por
questões comerciais (já que não estava a ter o impacto esperado) esse mesmo nome teve
que ser alterado para o referido Dataset.
2.1.1 Onde usar
O uso de IMDB é necessário quando é imprescindível a manipulação de
quantidades elevadas de informação em memória.
Poderemos usar IMDB quando desejamos ter tempos de acesso a dados
bastantes rápidos e, representar estruturas complexas de dados em memória, manipular
os dados de uma forma bastante eficiente, um exemplo prático onde cada vez mais
poderá ser essencial o uso de IMBD será em tecnologias relacionadas com a Internet.
ISEP – DEI
18
IMDB – Sistema de Indexação
Caracterizar IMDB
Contudo, o seu uso estará sempre dependente da quantidade de informação que
estamos a tratar e, como é lógico, das capacidades de hardware (mais explicitamente
memória) que dispomos.
2.2 Casos de utilização
Neste capítulo tentaremos ilustrar alguns exemplos importantes na informática
dos nossos dias, como o DataSet – ADO.NET –, o DataSet do Java, o SQL-IMDB, o
XML-IMDB e o motor de indexação do mysql. Como abordagem inicial ao DataSet
poderemos desde já expor que o seu uso apenas está ao nível de utilizadores, analistas
ou programadores experimentados, quer isto dizer que o DataSet exige o conhecimento
prévio de outras tecnologias, a saber:
o ActiveX (ver Glossário)
o Data Objects (ADO) (ver Anexo – A.3)
o OLE DB (ver Glossário)
o SQL Server (ver Glossário)
o Plataforma .NET (ver Anexo – A.4)
2.2.1 DataSet - ADO.NET
A última “revolução” da Microsoft foi a introdução de Record Set dinâmicos
com IMDB.
ADO.NET é o modelo de acesso a dados para aplicações .NET. O DataSet no
ADO.NET pretende fazer uma representação da informação de bases de dados em
memória, contendo múltiplas tabelas relacionadas de uma forma hierárquica. Por este
facto, devemos tentar compreender como devemos navegar desde o registo pai até aos
registos filhos é uma tarefa fundamental para esta tecnologia que não é compreensível
de uma forma intuitiva – especialmente nas ocasiões em que estamos a tentar aceder a
tabelas que estão no fundo da relação hierárquica.
ISEP – DEI
19
IMDB – Sistema de Indexação
Caracterizar IMDB
O ADO.NET pode-se usar para aceder a bases de dados relacionais, tais como o
SQL Server 2000 e outros Data Sources (ver Glossário) nos quais exista um serviço
OLE DB. ADO.NET é a última evolução da tecnologia ADO, contudo, ADO.NET (ver
Anexo – A.4 e A.3) introduz grandes mudanças e inovações específicas como a herança,
importantes para aplicações de natureza WEB.
Uma das principais mudanças que o ADO.NET introduz é a substituição do
Recordset ADO pela combinação dos objectos DataTable, DataSet, DataAdapter e o
DataReader. A DataTable representa um conjunto de linhas de uma só tabela e, neste
aspecto torna-se similar ao RecordSet.
Figura 1 – Modelo do DataSet
Um DataSet representa uma colecção de objectos DataTable, estes com as
relações e constrangimentos é que se interligam as várias tabelas. De facto, um DataSet
estruturado em memória relacionado é construído com suporte para o conhecido XML
(Extensible Markup Language – ver Anexo A.2).
De seguida, demonstra-se como usar um DataSet com várias tabelas
relacionadas, navegando de uma tabela para outra usando uma terceira tabela – Tabela
intermediária (relações de N para N). Elucidando com um exemplo prático a
configuração de uma tabela em relação a outra (XML).
ISEP – DEI
20
IMDB – Sistema de Indexação
Caracterizar IMDB
Quando geramos um DataSet não são criadas as relações entre tabelas
automaticamente. As relações poderão ser criadas por programação ou visualmente
(usando o XML Designer) como verificamos na tabela seguinte, em que a tabela
“Trabalhador_Programador” tem como tabela pai “Trabalhador” e tabela filha
“Programador”.
Elemento
Configuração
Nome da tabela
Trabalhador_Programador
Nome da tabela Pai
Trabalhador
Nome da tabela Filho
Programador
Campos chaves
TrabalhadorID
Campos chaves estrangeiras
TrabalhadorID
Tabela 1 – Configuração de relações entre tabelas num DataSet usando XML.
Uma das principais características do DataSet é que é uma entidade usada para
representar colecções de dados, a sua flexibilidade em fazer binding (mapeamento) dos
dados e de poder ser passada de componente para componente através de diferentes
aplicações. Pode também ser formulada através de dados XML, fazendo do DataSet
ideal para transferir dados entre diferentes plataformas. ADO.NET usa o objecto
DataAdapter para comunicar com o DataSet e vice-versa. O objecto DataAdapter
também permite actualizações transparentes (em batch – invisíveis para o utilizador),
permitindo compatibilidade com o que já existia no RecordSet (ver Glossário).
Figura 2 – Os suportes do DataSet e interligação com o DapaApdater - SQLDataAdapter
ISEP – DEI
21
IMDB – Sistema de Indexação
Caracterizar IMDB
Na figura anterior é usado um DataAdapter – SQLDataAdapter – para
comunicar com o DataSet, e o DataSet, por sua vez, usa o SQLDataAdapter para
comunicar com a base de dados [3].1
2.2.2 DataSet - Java
O DataSet em Java providencia acesso directo a uma base de dados.
O modelo DataSet assenta nos seguintes pontos:
o Uma implementação de um serviço DataSet (Interface DataSet.Provider)
que lê informação a partir de um data source (neste caso o JDBC - ver
Glossário - ou um servidor EJB – Enterprise Java Beans - ver Glossário)
de uma base de dados, como é óbvio. A informação obtida é colado em
cache, para isto necessitamos de uma implementação de um DataSet que
guarda esses mesmos dados (Interface DataSet.Store). Para colocar os
dados em memória é usado o DataSet.Store.
o Manipulação dos dados fornecidos. O DataSet fornece diversas
funcionalidades com os dados e as tabelas obtidas como a edição,
navegação, ordenação, filtragem, agregação, constrangimentos, gestão,
relações de N para 1 e de 1 para N.
o Permite guardar ou editar a informação em cache, através de um ou mais
DataSet, no data source (para guardar informação é usado um Interface
DataSet.Resolver). O DataSet trata de identificar todas as operações de
inserção, actualização e eliminação feitas em cache, permitindo assim
guardar os dados no data source de um modo optimista, guardando
apenas as alterações.
A principal funcionalidade do DataSet em Java é que não está “preocupado”
com a origem dos dados (DataSet.Provider), a informação sobre a qual está a fazer
cache (DataSet.Store), ou aquilo que vai guardar e onde depois das alterações em cache
1
Ver algumas definições importantes sobre no Glossário, para uma melhor compreensão.
ISEP – DEI
22
IMDB – Sistema de Indexação
Caracterizar IMDB
(DataSet.Resolver). Esta separação de responsabilidades permite-nos misturar e
encaixar as implementações destes três interfaces, independentemente de plataformas e
bases de dados em que estamos a trabalhar
A vantagem que o DataSet nos apresenta é a sua grande capacidade, já que
consegue guardar quase 2 biliões de linhas por tabela. No entanto, também tem em
conta
a
persistência,
porque
permite
a
efectuação
de
transacções
e
a
recuperação/tolerância a falhas.
A API DataSet providencia acessos bastantes interessantes para navegação,
edição, filtragem e principalmente a indexação/ordenação [4].
2.2.3 SQL – IMDB
SQL – IMDB é um componente de base dados em memória (em ActiveX, DLL
ou LIB – ver Glossário), para SQL e manuseamento de XML, desenhado pela empresa
QuiLogic.
É bastante rápido e, até nem pesa muito em memória, isto para um componente
IMDB com transacção, é UNICODE (ver Glossário) e com suporte de multi-processos
(multi-thread- ver Glossário). SQL-IMDB providencia “variáveis globais” na forma de
tabelas SQL, sempre acessíveis da própria aplicação ou de outras aplicações em
diferentes endereços de processamento. Com o SQL – IMDB é possível gerir os dados
de uma aplicação de uma maneira declarativa em vez do modo normal (de uma forma
procedimental), todo gerido na memória principal. Suporta Enterprise Application
Integration (EAI) através de memória partilhada, troca de dados entre diferentes
linguagens e diferentes ambientes (C++, VBA, ASP, Office...).
Esta tecnologia vem substituir outras estruturas mais tradicionais como vectores,
listas, tabelas de hash (ver Glossário)... através do suporte da base de dados em
memória.
ISEP – DEI
23
IMDB – Sistema de Indexação
Caracterizar IMDB
Como já referido o SQL-IMDB está disponível em ActiveX, DLL ou um
componente LIB, tudo isto em UNICODE. É bastante útil no desenvolvimento de ASP
(Active Server Page – ver Glossário). A troca de dados entre aplicações em diferentes
espaços de processamento é tão simples como executar um comando de SQL (INSERT
ou SELECT).
Independentemente de usar C++ ou um script em VBA, usando SQL-IMDB os
problemas de troca de informação entre aplicações estão resolvidos. Esta tecnologia
quase que nos fornece respostas em tempo real, ideal para aplicações e-business, isto
porque é baseado numa estrutura in-memory database, usando memória partilhada
(shared memory) com tempos de resposta muito aceitáveis. Tem também um bom
sistema de cache, que nos permite gerir ou gravar informação em memória de uma
forma muito simplista.
Para a indexação o SQL-IMDB usa o algoritmo TST-tree. Este algoritmo, foi
publicado por Bentley e Sedgewick (1998), combina a rapidez de acesso tabela de hash
com a ordem de acesso que as árvores binárias nos oferecem. Contudo, o algoritmo
inicialmente tinha requisitos de espaço muito superiores a uma árvore normal, mas a
empresa QuiLogic inventou um modo especial para comprimir os requisitos de espaço,
ficando quase comparável a uma árvore binária normal [5].
Característica
Tamanho
Capacidade máxima de armazenamento
~ 2GB
Número máximo de tabelas
65535
Número máximo de indexações numa
32
tabela
Número máximo de colunas numa
1
indexação
Tamanho máximo do nome da tabela
48
Tamanho máximo dos nomes das colunas
32
Número máximo de colunas numa tabela
32
Número máximo de linhas numa tabela
64
Tamanho máximo para um tamanho fixo
4096
ISEP – DEI
24
IMDB – Sistema de Indexação
Caracterizar IMDB
de uma coluna
Tamanho máximo para colunas binárias
32
Número máximo de aberturas simultâneas
256
de cursores
Tabela 2 – Capacidades do SQL – IMDB
2.2.4 XML – IMDB
XML-IMDB é uma base de dados representada em XML e é também parte da
empresa QuiLogic. Foi desenhada no intuito de unificar informação estruturada e não
estruturada de bases de dados relacional, documentos XML, e ficheiros normais. Com o
XML-IMDB, pode-se facilmente aceder a dados relacionais como se de informação
XML se tratasse; fazer vistas e diversas pesquisas sobre a informação; aceder aos dados
em tempo real e pesquisar dados ao longo de um documento XML; como o XMLIMDB é baseado na nova versão XML, o Xquery, pode-se também usar comandos de
SQL.
Esta tecnologia suporta o processamento de documentos XML assim como a
gestão in-memory-database. Esta tecnologia é, no fundo, baseada na mesma gestão de
memória usada pelo SQL-IMDB (ver atrás).
O XML-IMDB é dinamicamente optimizado, durante a execução, baseando-se
na informação a pesquisar e nos resultados intermédios.
É bastante rápido a processar os documentos XML, usando uma tecnologia de
indexação da empresa QuiLogic, assim como, a indexação mais tradicional – árvores e
tabelas de hash. Esta tecnologia também é eficiente porque se baseia num sistema de
cache de ficheiros, com XML em tabelas de memória (localmente ou remotamente).
Atentar no exemplo seguinte para melhor entender como se consegue encaixar
um documento XML numa tabela de memória. O exemplo seguinte demonstra a criação
de uma tabela, o carregamento de um documento XML (book.xml) para a tabela
anteriormente criada, e finalmente demonstra como podemos eliminar a tabela criada.
ISEP – DEI
25
IMDB – Sistema de Indexação
Caracterizar IMDB
db.ExecXql("CREATE TABLE TX")
db.ExecXql("LOAD 'book.xml' INTO TX")
...
db.ExecXql("DROP TABLE TX")
Figura 3 – Encaixar documento XML numa tabela de memória
Como já descrito anteriormente o XML-IMDB suporta código SQL (isto porque
usa pesquisas XQuery), para melhor compreensão seria útil atentarmos no exemplo
seguinte. Este demonstra-nos o modo de integrar um SELECT ou um INSERT no
código XML-IMDB.
"FOR $X IN (SELECT * FROM TR WHERE ...)
...
RETURN $X"
"FOR $X IN DOCUMENT('abc.xml') WHERE $X/B/text() = (SELECT ... WHERE b =
$X/ID/number()) RETURN $X"
"FOR $X IN DOCUMENT('abc.xml') ... RETURN (INSERT INTO TR
VALUES($X/A/text(), $X/B/number()))"
Figura 4 – Exemplo de SQL em XML-IMDB
Também são suportadas as funções de UPDATE (REPLACE) e DELETE, de
uma forma fácil.
"FOR $X IN TX .... DELETE $X/..."
"FOR $X IN TX .... RENAME $X/... TO 'abc'"
"FOR $X IN TX .... REPLACE $X/text() WITH 'abc'"
"FOR $X IN TX .... REPLACE $X WITH <>...<>"
"FOR $X IN TX .... REPLACE $X/@A WITH ATTRIBUT('abc',12)"
"FOR $X IN TX .... INSERT <>...<> INTO $X"
....
Figura 5 – SQL (UPDATE e DELETE) em XML - IMDB
ISEP – DEI
26
IMDB – Sistema de Indexação
Caracterizar IMDB
De igual modo ao SQL-IMDB, também o XML-IMDB é distribuído em
ActiveX, DLL ou em LIB, contudo é apenas suportado na plataforma Windows
(95/98/NT/2000/XP) [6].
2.2.5 Motor de indexação MySQL
Dentro do MySQL apenas nos iremos concentrar nas tabelas InnoDB. Este
providencia-nos transacções, fazer commit e rollback assim com recuperação depois de
falhas. Este também suporta multi-utilizador, e podemos colocar esta tecnologia em
pequenos espaços de memória. As tabelas InnoDB também suportam chaves
estrangeiras.
Consegue computar grandes quantidades de informação, com uma eficiência de
CPU bastante considerável. É basicamente o suporte para bases de dados existente no
MySQL. Funciona em memória principal (RAM).
Cada tabela InnoDB tem uma indexação chamada de “clustered index”, onde a
informação de todas as linhas da tabela está guardada. Se foi definida uma chave
primária na nossa tabela, então a indexação da chave primária será o “clustered index”.
Se, por outro lado, não definirmos uma chave primária na nossa tabela, o InnoDB irá
internamente gerar um “clustered index”, em que, as linhas serão ordenadas pelo ID
que o InnoDB fornece às respectivas linhas da tabela. O ID é um campo de 6 caracteres
que será incrementado cada vez que uma nova linha é inserida. As linhas estarão, então,
ordenadas pela ordem de inserção.
Aceder a uma linha através do “clustered index” é rápido, porque a informação
da linha estará na mesma página de memória para onde a indexação nos direcciona (em
algumas bases de dados a informação é guardada em diferentes páginas da indexação).
InnoDB usa a chave primária para procurar pela linha através do “clustered
index”.
ISEP – DEI
27
IMDB – Sistema de Indexação
Caracterizar IMDB
Todas as indexações usam o algoritmo B-Tree (ver capítulo 3), tal qual o
sistema de indexação desenvolvido neste projecto, onde os registos de indexação são
guardados.
2.3 Necessidade de Indexação
Um dos usos mais vulgares para a tecnologia IMDB será o DataSet (Java ou
Microsoft como já referido anteriormente), ao qual estará sempre associado o XML.
Pois, o XML é uma das tecnologias que hoje em dia mais se usa na Internet e, como já
foi referido anteriormente, esta é uma área em que urge a integração de IMDB.
A indexação é importante na Internet, porque nos pode permitir diminuir o
tempo gasto com carregamentos de dados, aumentando bastante a performance a este
nível. Este facto torna-se ainda mais gritante quando existem cada vez mais aplicações a
trabalhar com Internet.
2.3.1 Analogia IMBD com XML
Esta secção tem interesse no sentido em que se tenta comprovar a importância
da existência de IMDB, nada melhor para despertar o interesse, do que fazer uma
analogia com a famosa tecnologia XML.
Uma desvantagem que o XML nos apresenta é o facto de sempre que desejarmos
abrir um documento XML teremos que carregá-lo todo para memória. E, como o XML
representa os dados de uma forma hierárquica (estilo uma árvore a expandir), pode-se
mesmo dizer que o XML tem a estrutura de documento encaixado, torna-se importante
um fácil e rápido acesso aos dados (a rapidez é, portanto, uma característica em falta no
XML).
Para a solução do problema seria, por exemplo, usar esta tecnologia em conjunto
como os já descritos DataSet, ou um SQL-IMDB, ou um XML-IMDB permitindo desta
forma ter todos os documentos em memória com todas as suas relações, assim como,
ISEP – DEI
28
IMDB – Sistema de Indexação
Caracterizar IMDB
gerir o documento XML (permitindo indexação da informação), sem pesar em demasia o
sistema.
2.4 Problemas e pontos a reter
Em primeira instância é preciso definir quais os limites que desejamos atingir,
por outras palavras, quanto queremos guardar em memória (RAM) e quanto queremos
guardar no disco rígido.
O que se pretende realçar é que devemos pensar que nem em todas as ocasiões
os dados deverão remanescer em memória, já que, poderão pesar o sistema. Ou seja, ao
ocuparmos memória de um sistema em demasia poderemos provocar a instabilidade
deste, de tal modo que sejam impraticáveis as mais básicas operações num sistema de
indexação em memória (sistema demasiado lento).
No entanto é de reter que um sistema IMDB na sua plenitude, é sempre aquele
que mais nos satisfaz em eficiência e rapidez.
ISEP – DEI
29
IMDB – Sistema de Indexação
3.
BTrees ++
BTrees ++
3.1 Introdução – outros sistemas
Neste capítulo irá ser apresentado o sistema usado para a indexação das bases de
dados em memória – BTrees++, este código tem por base uma implementação Open
Source (ver Glossário), que foi adaptada ao sistema de indexação pretendido. Contudo,
seria importante salientar que esta não é a única tecnologia existe para esta finalidade.
Existem outros tipos de árvores que poderão produzir o mesmo efeito, de seguida
apresentam-se alguns exemplos:
o Árvores ADT
o Árvores AVL
o Árvores Red-Black
Foram
escolhidas
as
BTrees
porque
nos
apresentavam
um
melhor
manipulamento da memória, sendo talvez mais rápidas, e porque se adequavam melhor
e mais facilmente ao SGBDoc.
3.1.1 Árvores ADT
Uma árvore ADT pode ser definida para suportar as seguintes operações:
o Retornar o Pai
o Retornar Filho mais à esquerda
o Retornar a raiz
o Colocar árvore como nula
o Calcular altura
ISEP – DEI
30
IMDB – Sistema de Indexação
BTrees ++
o Calcular profundidade
o Criar árvore – criando uma parecida com a da figura que se segue [7]
Figura 6 – Exemplo de uma árvore ADT
3.1.2 Árvores AVL
Também conhecidas como árvores binárias de pesquisa balanceadas. Procura,
inserção e eliminação podem ser implementadas.
Uma árvore AVL é uma árvore binaria de pesquisa em que:
o A altura da sub-árvore direita e da sub-árvore esquerda diferem da raiz
de pelo menos 1.
o A sub-árvore esquerda e a sub-árvore direita são elas próprias árvore
AVL [7]
Figura 7 – Exemplo de árvores AVL e não AVL
ISEP – DEI
31
IMDB – Sistema de Indexação
BTrees ++
3.1.3 Árvores Red-Black
Permite efectuar procuras binárias pela árvore onde o caminho da raiz até a um
último nó (leaf), não maior do que o dobro do outro caminho da raiz até outro último nó
qualquer.
Uma árvore é descrita com red-black se satisfaz as seguintes condições:
o Qualquer nó é red ou black.
o Qualquer último nó é sempre black.
o Se um nó é red os seus filhos são black
o
Qualquer caminho desde um nó até aos seus últimos descendentes conte
o mesmo número de nós black [7]
Figura 8 – Exemplo de uma árvore red-black
ISEP – DEI
32
IMDB – Sistema de Indexação
BTrees ++
3.2 Caracterização
As estruturas de árvore suportam várias operações dinâmicas básicas incluindo a
pesquisa, o predecessor, o seguinte, o menor, o maior, a inserção e a eliminação
proporcional à altura da árvore. Idealmente, uma árvore será equilibrada se a altura for
log n, onde n é o número de nós da árvore. Para assegurar-se de que a altura da árvore
seja tão pequena quanto possível e, forneça consequentemente o melhor tempo de
execução possível, uma estrutura de árvore balanceada como a árvore red-black tree
(ver 3.1.3) , a árvore de AVL (ver 3.1.2), ou a b-tree (BTree++) deve ser usada.
Ao manusear com grandes quantidades dos dados, não é frequentemente
possível, ou desejável, manter toda estrutura inteira na memória principal (RAM). Ao
contrário, uma parcela relativamente pequena da estrutura de dados é mantida em RAM,
e os restantes dados são lidos de um repositório secundário (por exemplo disco rígido)
conforme for necessário. Infelizmente, um disco rígido, a forma mais comum de
armazenamento secundário, é significativamente mais lento do que a memória RAM.
De facto, o sistema gasta frequentemente mais tempo em ir buscar os dados do que a
processá-los.
As b-trees são árvores balanceadas que são optimizadas para situações quando
parte ou toda a árvore deve ser mantida em memória secundária, usando por exemplo
um disco rígido. Como os acessos ao disco são dispendiosos (tempo que consome), as
b-trees tentam minimizar o número de acessos ao disco. Por exemplo, uma b-tree com
uma altura de 2 e um factor de 1001 pode armazenar mais que um bilião de chaves mas,
requerem pelo menos dois acessos ao disco para pesquisar por um nó qualquer.
3.3 Estrutura de uma BTree
Ao contrário de uma árvore binária, cada nó de uma b-tree pode ter um número
variável de chaves e de filhos. As chaves são armazenadas em ordem crescente. Cada
chave tem um filho associado que pode ser a raiz de uma sub-árvore que contem todos
ISEP – DEI
33
IMDB – Sistema de Indexação
BTrees ++
os nós com chaves menores ou iguais à chave, mas maiores do que a chave precedente.
Um determinado nó pai tem também um filho adicional mais à direita, que pode ser a
raiz para uma sub- árvore que contem todas as chaves maiores do que todas as chaves
do nó pai.
Uma b-tree tem um número mínimo de filhos para cada nó, chamado o factor de
minimização. Se t for o factor de minimização, então cada nó deve ter pelo menos t - 1
chaves. Sob determinadas circunstâncias, ao nó raiz é permitido violar esta propriedade
tendo menos do que t - 1 chaves. Cada nó pode ter no máximo 2t - 1 chaves ou,
equivalente, 2t filhos.
Sabendo que cada nó tende a ter um factor ramificação grande (um grande
número de filhos – branching factor), é normalmente necessário atravessar
relativamente poucos nós antes de encontrar a chave desejada. Se o acesso a cada nó
requerer um acesso a disco, então a b-tree tentará minimizar o número de acessos ao
disco. O factor de minimização é escolhido geralmente de modo a que o tamanho total
de cada nó corresponda a um múltiplo do tamanho de bloco do dispositivo de
armazenamento subjacente (do disco rígido, por exemplo). Esta escolha simplifica e
optimiza o acesso ao disco. Consequentemente, uma b-tree é uma estrutura de dados
ideal para as situações onde todos os dados não podem residir no armazenamento
preliminar e os acessos ao armazenamento secundário (disco) são comparativamente
demorosos (tempo consumido).
3.3.1 Altura das b-Trees
Para n maior do que ou igual a um, a altura de uma ‘n - chave b-tree T’ de altura
h com um grau mínimo t maior do que ou o igual a 2,
Figura 9 – Cálculo da altura de uma BTree
ISEP – DEI
34
IMDB – Sistema de Indexação
BTrees ++
O pior caso de altura será em O(log n). Já que, a "ramificação" de uma b-tree
pode ser grande, isto quando comparada a muitas outras estruturas de árvore
balanceadas, a base do logaritmo tende a ser grande; consequentemente, o número da
nós visitados durante uma busca tende a ser menor do que requerido por outras
estruturas de árvore. Embora isto não afecte a pior altura simétrica, as b-trees tendem a
ter alturas menores do que outras árvores com a mesma altura simétrica.
3.4 Operações em BTrees
Os algoritmos de search (busca), create (criar), e os de operações de insert
(inserção) são visualizados abaixo. Note-se que estes algoritmos são de uma única
passagem; ou seja não existem passagem de baixo para cima. Sabendo que as b-trees
tentam minimizar acessos ao disco e, os nós são armazenados geralmente em disco, esta
aproximação de uma única passagem reduzirá o número de visitas a um nó e, logo, o
número de acessos ao disco. Umas aproximações simples de dupla passagem que sejam
passagens de baixo para cima na árvore, ajudam a reparar possíveis falhas.
Já que todos os nós são supostos serem guardados em armazenamento
secundário (disco), em vez de serem armazenados em memória (RAM), todas as
referências a um dado nó dado devem precedidas por uma operação de leitura
denominada Disk-Read. Similarmente, uma vez um nó modificado e, não sendo mais
preciso, deve ser escrito para armazenamento secundário com uma operação da escrita
denominada de Disk-write. Os algoritmos abaixo supõem que todos os nós
referenciados nos parâmetros já tiveram a correspondente operação Disk-Read. Os nós
novos são criados e o armazenamento é atribuído com a chamada ao Allocate-Node. Os
detalhes da implementação das funções Disk-read, Disk-write, e do Allocate-Node são
dependentes do sistema operativo e da implementação.2
2
No fundo será este um dos processos a serem alterados, já que, os nossos desejos não são os
mencionados. Para uma melhor compreensão atentar em 5.1, mais concretamenta, nas alterações de
leitura e escrita efectuadas no sistema de indexação.
ISEP – DEI
35
IMDB – Sistema de Indexação
BTrees ++
3.4.1 B-Tree-Search(x, k)
i <- 1
while i <= n[x] and k > keyi[x]
do i <- i + 1
if i <= n[x] and k = keyi[x]
then return (x, i)
if leaf[x]
then return NIL
else Disk-Read(ci[x])
return B-Tree-Search(ci[x], k)
Figura 10 – Algoritmo de pesquisa numa BTree
A operação de busca numa b-tree é análoga a uma busca numa árvore binária.
Em vez de escolher entre um filho à esquerda e à direita como numa árvore binária, uma
pesquisa numa b-tree deve fazer a escolha de n maneiras. O filho correcto é escolhido
executando uma pesquisa linear aos valores do nó. Após ter encontrado o valor maior
do que ou igual ao valor desejado, o ponteiro do filho imediatamente à esquerda desse
valor é seguido. Se todos os valores forem menores do que o valor desejado, o ponteiro
mais à direita do filho será seguido. Naturalmente, a busca pode ser terminada assim que
o nó desejado for encontrado. Sabendo que o tempo de execução de uma pesquisa
depende da altura da árvore, B-Tree-Search é no tempo de execução O(log t n) .
3.4.2 B-Tree-Create(T)
x <- Allocate-Node()
leaf[x] <- TRUE
n[x] <- 0
Disk-Write(x)
root[T] <- x
Figura 11 – Algoritmo de criação de uma b-tree vazia
A operação B-Tree-Create cria uma b-tree vazia e aloca um nó novo, a raiz, que
não tem nenhuma chave. Somente o nó a raiz pode ter esta propriedade; todos nós
restantes devem seguir os critérios esboçados previamente. A operação B-Tree-Create
demora O(1) .
ISEP – DEI
36
IMDB – Sistema de Indexação
BTrees ++
3.4.3 B-Tree-Split-Child(x, i, y)
z <- Allocate-Node()
leaf[z] <- leaf[y]
n[z] <- t - 1
for j <- 1 to t - 1
do keyj[z] <- keyj+t[y]
if not leaf[y]
then for j <- 1 to t
do cj[z] <- cj+t[y]
n[y] <- t - 1
for j <- n[x] + 1 downto i + 1
do cj+1[x] <- cj[x]
ci+1 <- z
for j <- n[x] downto i
do keyj+1[x] <- keyj[x]
keyi[x] <- keyt[y]
n[x] <- n[x] + 1
Disk-Write(y)
Disk-Write(z)
Disk-Write(x)
Figura 12 – Algoritmo de divisão do filho numa BTree
Se um nó se tornar "demasiado cheio", é necessário executar uma operação de
divisão. A operação de divisão move a chave mediana do nó x para o seu pai y onde x é
o na posição iº filho de y. Um nó novo, z , é alocado, e todas as chaves à direita de x da
chave mediana são movidas para z. As chaves à esquerda da chave mediana continuam
no nó original x. O novo nó, z, torna-se no filho imediatamente à direita da chave
mediana que foi movida para o pai y, e o nó original, x, trona-se no filho imediatamente
à esquerda da chave mediana que foi movida no pai y.
A operação de split (divisão) transforma um nó cheio com 2t – 1 chaves em dois
nós com t - 1 as chaves cada um. Note-se que uma chave é movida para o nó pai. O
algoritmo B-Tree-Split-Child demorará O(t), onde t é constante.
3.4.4 B-Tree-Insert
B-Tree-Insert(T, k)
r <- root[T]
if n[r] = 2t - 1
then s <- Allocate-Node()
root[T] <- s
leaf[s] <- FALSE
ISEP – DEI
37
IMDB – Sistema de Indexação
BTrees ++
n[s] <- 0
c1 <- r
B-Tree-Split-Child(s, 1, r)
B-Tree-Insert-Nonfull(s, k)
else B-Tree-Insert-Nonfull(r, k)
Figura 13 – Algoritmo de inserção com um nó cheio
B-Tree-Insert-Nonfull(x, k)
i <- n[x]
if leaf[x]
then while i >= 1 and k < keyi[x]
do keyi+1[x] <- keyi[x]
i <- i - 1
keyi+1[x] <- k
n[x] <- n[x] + 1
Disk-Write(x)
else while i >= and k < keyi[x]
do i <- i - 1
i <- i + 1
Disk-Read(ci[x])
if n[ci[x]] = 2t - 1
then B-Tree-Split-Child(x, i, ci[x])
if k > keyi[x]
then i <- i + 1
B-Tree-Insert-Nonfull(ci[x], k)
Figura 14 – Algoritmo de inserção numa árvore com um nó vazio
Para executar uma inserção numa b-tree, o nó apropriado para a chave deve ser
encontrado usando um algoritmo similar ao B-Tree-Search. Em seguida, a chave deve
ser introduzida no nó. Se o nó não estiver cheio antes da inserção nenhuma acção
especial será requerida; contudo, se o nó estiver cheio, este deve ser divido (split), de
modo a abrir espaço para a nova chave. Sabendo que dividir nó é mover uma chave para
o nó pai, o nó pai não deve estar cheio ou uma outra operação de divisão é requerida.
Este processo pode-se repetir até a raiz e, pode ser preciso dividir o nó da raiz. Esta
aproximação requer duas passagens. A primeira passagem encontra o nó onde a chave
deve ser introduzida; a segunda passagem executa todos os splits (divisões) requeridos
pelo nó filho.
Cada acesso a um nó pode corresponder a um acesso caro ao disco, é desejável
evitar a segunda passagem assegurando-se de que o nó pai nunca esteja cheio. Para
realizar isto, o algoritmo apresentado divide (faz split) sobre todos os nós cheios
encontrados ao descer a árvore. Embora esta aproximação possa resultar em operações
de split desnecessárias, garante que o pai nunca necessita de ser divido e elimina a
ISEP – DEI
38
IMDB – Sistema de Indexação
BTrees ++
necessidade de uma segunda passagem até ao topo da árvore. Um split funciona em
tempo linear, tem pouco efeito no tempo de execução que faz o algoritmo B-Tree-Insert
– tempo de execução O(t t n).
Dividir o nó da raiz é processado como um caso especial, já que uma raiz nova
deve ser criada para conter a chave mediana da raiz antiga. A b-tree crescerá a partir do
topo.
3.4.5 B-Tree-Delete
A eliminação de uma chave de uma b-tree é possível; contudo, cuidados
especiais devem ser tomados para se assegurar de que as propriedades de uma b-tree
sejam mantidas. Diversos casos devem ser considerados. Se a eliminação reduzir o
número das chaves num nó abaixo do grau mínimo da árvore, esta violação deve ser
corrigida combinando diversos nós e possivelmente reduzindo a altura da árvore. Se a
chave tiver filhos, os filhos devem ser reorganizados.
3.5 Exemplos de aplicações de BTrees
De seguida apresenta-se uma b-tree exemplo:
Figura 15 – Exemplo de uma b-tree
Agora tenta-se exemplificar a sequência da pesquisa da chave 21 numa b-tree:
ISEP – DEI
39
IMDB – Sistema de Indexação
BTrees ++
Figura 16 – Sequência de pesquisa numa b-tree
Agora exemplifica-se a inserção da chave 33 com split (divisão):
ISEP – DEI
40
IMDB – Sistema de Indexação
BTrees ++
Mediana
ISEP – DEI
41
IMDB – Sistema de Indexação
BTrees ++
Figura 17 – Sequência de inserção de um valor numa b-tree com split (divisão)
3.5 Aplicações
Uma base de dados é uma colecção de dados organizados numa forma que
facilite actualizar, ler, recuperar, e controlar os dados. Os dados podem consistir em
qualquer coisa, incluindo, mas não limitado aos nomes, aos endereços, ás imagens, e
aos números. As bases de dados são muito usuais hoje em dia. Por exemplo, um sistema
de reservas de uma linha aérea pode manter uma base de dados de voos disponíveis, de
clientes, e de bilhetes emitidos. Um professor pode manter uma base de dados com
nomes de estudantes e de turmas.
Porque os PC computam rapidamente e são exactos, manipulando,
armazenando, e recuperando dados, as bases de dados são mantidas frequentemente
electronicamente usando um sistema de gestão de base de dados. Os sistemas de gestão
de base de dados são componentes essenciais de muitas operações de negócio que
acontecem diariamente. Os produtos de base de dados como o Microsoft SQLSERVER,
o IBM DB2, Sybase Adaptative e o Oracle (ver Glossário) servem para sistemas como
contabilidade, sistemas de inventário, sistema médicos, sistemas de reserva de linha
aérea, e outros aspectos importantes de negócios modernos.
3.5 Problemas e vantagens
Como as bases de dados não podem tipicamente ser mantidas inteiramente em
memória, as b-trees são usadas frequentemente para posicionar nos dados e fornecer
acessos rápidos. Por exemplo, procurar em dados não indexados e não ordenados numa
base de dados que contem n valores chaves terá uma pesquisa demasiadamente
demorosa (tempo O(n)); se os mesmos dados forem armazenados com uma b-tree, a
ISEP – DEI
42
IMDB – Sistema de Indexação
BTrees ++
mesma operação de pesquisa funcionará em O(log n). Para executar uma pesquisa de
uma única chave com um milhão de chaves (1.000.000), uma busca linear requererá na
a maioria dos casos 1.000.000 comparações. Se os mesmos dados forem posicionados
com uma b-tree de grau mínimo 10, 114 comparações serão necessárias no pior caso.
Claramente, posicionar em grandes quantidades de dados pode significativamente
melhorar o desempenho da pesquisa.
Embora outras estruturas de árvore equilibradas possam ser usadas, uma b-tree
optimiza também os acessos demorosos ao disco que são interessantes ao tratar de séries
de dados de grandes volumes. O acesso simultâneo às bases de dados das B-Trees
funciona tipicamente nos ambientes multi-utilizador onde muitos utilizadores podem
simultaneamente executar operações na base de dados.
Infelizmente, este cenário muito comum introduz complicações. Por exemplo,
imagine uma base de dados a armazenar balanços de um cliente de banco. Suponha
agora que alguém tenta retirar 40Є de um cliente que contem 60Є. Primeiramente, o
balanço actual é verificado para assegurar fundos suficientes. Depois dos fundos
descontados, o balanço do cliente está reduzido. Suponha, ainda, que uma outra pessoa
tenta simultaneamente retirar 30Є do mesmo cliente. O balanço do cliente é verificado
no mesmo espaço temporal da primeira pessoa, o balanço do cliente é recuperado
também para a segunda pessoa. Desde que nenhuma pessoa estivesse a pedir mais
fundos do que estavam na altura disponíveis, ambos os pedidos são satisfeitos para um
total de 70Є. Após a transação da primeira pessoa, 20Є devem remanescer (60Є - 40Є),
assim que o novo balanço é gravado como 20Є. Em seguida, o balanço do cliente após
transação para a segunda da pessoa, 30Є (60Є - 30Є), é gravado o balanço de 20Є.
Infelizmente, 70Є foram levantados, mas o balanço do cliente foi diminuído somente
30Є. Claramente, este comportamento é indesejável, e devem ser tomadas precauções
especiais. Uma b-tree sofre de problemas similares num ambiente multi-utilizador. Se
dois ou os mais processos estiverem a usar a mesma árvore, é possível para a árvore
tornar-se corrupta e resultar na perda ou em erros de dados.
A solução mais simples é colocar em série o acesso à estrutura de dados. Ou seja
se um outro processo estiver a usar a árvore, todos restantes processos devem esperar.
Embora isto seja praticável em muitos casos, pode colocar um limite desnecessário e
ISEP – DEI
43
IMDB – Sistema de Indexação
BTrees ++
“dispendioso” no desempenho, porque muitas operações podem ser executadas
simultaneamente sem o risco [8].
ISEP – DEI
44
IMDB – Sistema de Indexação
SGBDoc
4. SGBDoc
O SGBDoc é um sistema que foi desenvolvido na I2S, como o próprio nome
indica é um sistema que permite gerir documentos em memória e com o conceito de
repositório, este permite guardar os dados num sistema de ficheiros e numa base de
dados relacional (SQL Server, AS/400, Linux). Para melhor perceber todos os conceitos
mais importantes desta tecnologia, que contém aspectos bastantes interessantes, então
deve-se atentar neste capítulo, que nos pretende elucidar acerca de considerações
importantes relacionadas com o SGBdoc assim como do uso do SGBdoc em algumas
aplicações (I2S).
4.1 Considerações Genéricas
O SGBdoc é um sistema gestor de base de documentos, permitindo a
representação e gestão de documentos.
Os documentos do SGBdoc são objectos com identidade que permitem
representar de forma adequada a informação tratada por sistemas de informação e
aplicações informáticas.
O SGBdoc permite representar, tratar e armazenar informação e regras de
tratamento dessa informação.
A representação da informação é feita através dos campos que compõem um
Documento. O tratamento da informação é efectuado através de métodos. O
armazenamento dos Documentos é efectuado em repositórios.
Os Documentos do SGBdoc são objectos fortemente tipados, ou seja, a sua
estrutura é bem definida embora possa evoluir ao longo do tempo. Para garantir essa
ISEP – DEI
45
IMDB – Sistema de Indexação
SGBDoc
coerência existe o conceito de Tipo de Documento. Qualquer Documento é de um Tipo.
Os Tipos especificam a estrutura e comportamento dos Documentos.
O SGBdoc mantém Documentos e Tipos armazenados em Repositórios. Nos
Repositórios ficam registadas todas as versões dos Tipos de Documentos assim como
dos Documentos.
4.1.1 Definição de Documento no SGBdoc
Um documento, no âmbito do sistema SGBdoc ou CODOMO (ver 4.3.1), é um
objecto com identidade que serve para armazenar objectos de dados complexos assim
como métodos que modelam o comportamento desses objectos. Os objectos de dados
que podem fazer parte de um documento vão desde os tipos de dados escalares até
objectos colecções e objectos compostos a partir desses objectos. Isto é, num
documento podemos representar objectos com uma estrutura quase arbitrária,
nomeadamente relações numa forma não normalizada ou na forma NNF (Non Normal
Form).
Os métodos são escritos numa linguagem de programação extensível (LPS – ver
Glossário), com características de uma linguagem procedimental e com instruções de
acesso universal a dados. O compilador da LPS e o ambiente de execução são parte
integrante do CODOMO.
Normalmente os documentos são armazenados num repositório num formato
binário nativo. Este formato de persistência é utilizado para fazer circular documentos
entre camadas de uma aplicação ou entre sistemas desde que estes tenham o sistema
operativo Windows ou AS/400. Os documentos também podem ser criados em memória
e alimentados a partir de programas ou a partir de dados externos utilizando-se para isso
métodos com as instruções de acesso universal a dados. Esta ultima característica
permite utilizar o documento para criar uma visão desconectada de uma parte de uma
base de dados e, se necessário, com transformações estruturais.
ISEP – DEI
46
IMDB – Sistema de Indexação
SGBDoc
A descrição da estrutura de um documento e os métodos LPS são armazenados
num documento especial designado por tipo de documento. Um tipo de documento
permite representar uma classe de documentos: documentos que partilham a mesma
estrutura e os mesmos métodos. Isto implica que cada documento esteja
necessariamente associado a um tipo de documento.
A utilização de documentos é suportada numa aplicação especializada que foi
denominada de CODOMO.
Para que os documentos possam ser utilizados e geridos o CODOMO tem as
seguintes funcionalidades:
Criação de tipos de documentos que consiste na especificação das
características estruturais e de comportamento que deverão ter os documentos de um
dado tipo. Estas especificações são realizadas através de uma linguagem de definição de
tipos de documentos (LDTD).
Manipulação de documentos através de uma linguagem de manipulação de
documentos (LMD).
Gestão de repositórios de documentos.
o Gestão de versões de um dado tipo de documento
o Gestão de versões de um dado documento
A figura seguinte mostra a arquitectura CODOMO:
Figura 18 – Documentos no CODOMO
ISEP – DEI
47
IMDB – Sistema de Indexação
SGBDoc
4.1.1.1 Analogia com XML
Em termos concretos o XML é uma tecnologia hierárquica baseada em
documentos, o SGBdoc baseia-se numa estrutura de documentos. O SGBdoc nem
sempre necessita de carregar todo o conteúdo de um documento, por sua vez, o XML
sempre que deseja obter um documento tem de carregá-lo em memória.
Na tabela seguinte podemos visualizar quais as funções suportadas por uma e
por outra tecnologia.
Função
SGBdoc
XML
Tipos
S
N3
Métodos
S
N
Documentos
S
S
Classes
S
S4
Hierárquico
N5
S
Multiplataforma
S
S
Binário
S
N
Repositórios
S
N
Tabela 3 – Analogia entre o que suporta SGBdoc e o que suporta a tecnologia XML
4.1.2 Definição de colecção
Tentaremos nesta parte não só exemplificar o que é uma colecção mas também
permitir que se tenha uma ideia mais esclarecedora de como construir um documento no
SGBdoc.
3
4
Também existe o XML Schema que pode simular um tipo de um documento.
Não necessáriamente através de funções nativas do XML, mas de outros sistemas que
interafem com o XML, como o ANT.
5
A nível das colecções (o que estamos a abordar) só existe um nível, no entanto usando vectores
poderíamos ter níveis ilimitados de hierarquias.
ISEP – DEI
48
IMDB – Sistema de Indexação
SGBDoc
Entende-se por colecção no SGBdoc como um conjunto de valores podendo ser
inteiros, ou strings, ou mesmo uma estrutura (como nos mostra a figura seguinte –
estrutura com os campos Name, Age, BthDate e Gender).
A linguagem de definição de tipos de documentos (LDTD) permite uma forma
simples e amigável definir tipos de documentos sem ser através da utilização da API.
Assim o utilizador pode definir um ficheiro de texto (script, normalmente com a
extensão lps) contendo a definição de um tipo de documento segundo a gramática da
LDTD. Este ficheiro pode ser então utilizado, por exemplo na Consola CODOMO (ver
4.3.1), para criar tipos de documentos ou versões de tipos de documentos.
Se atentarmos na figura, que se segue, podemos verificar que primeiramente
definimos a estrutura info e posteriormente definimos uma colecção – AllPersons –
baseada na estrutura info. Linhas mais à frente poderemos visualizar um método
(comando methods) e, como efectuamos a inserção de um elemento através do SGBdoc
– comando addnew.
ISEP – DEI
49
IMDB – Sistema de Indexação
SGBDoc
Figura 19 – Exemplo do código necessário para a criação de um documento no SGBdoc
4.1.3 Funcionamento interno – parâmetros e funções
O SGBdoc serve de base para uma linguagem de programação existente na I2S
(LPS – Linguagem para seguros). A manipulação das funções e dos parâmetros
internamente é processado do modo mais comum, através de uma pilha (LIFO – “Last
In First Out” – o último a entrar será o último a sair). Assim quando procedemos à
busca de parâmetros dentro de uma determinada função, esta é processada de modo
inverso, ou seja, do último para o primeiro (ver caso prático – 5.2.2, problemas
encontrados).
ISEP – DEI
50
IMDB – Sistema de Indexação
SGBDoc
4.1.4 Indexação sobre uma colecção
Entende-se indexação sobre uma colecção como a efectuação de uma
determinada ordem nos dados sobre um determinado campo de uma colecção, ou seja,
permitindo que nos coloquemos numa dada posição de modo eficiente e rápido.
Possuindo determinadas funções como nos mostra a seguinte tabela:
Tabela 4 – Tabela de operações de indexação.
Função
Descrição
Encontrar primeiro
Encontrar a primeira posição segundo a
indexação de um campo
Encontrar Último
Encontrar a última posição segundo a
indexação de um campo
Encontrar Próximo
Encontrar a próxima posição
Encontrar Anterior
Encontrar a posição Anterior
Encontrar chave
Encontrar um campo segundo uma dada
chave
Posicionar
Obter um código segundo uma posição
Tabela 4 – Tabela de operações de indexação
No fundo ao usar indexação estamos a tentar permitir com que as referidas
operações possam usar cursores6.
Para melhor entendermos a importância deste facto seria de bom atentarmos nas
seguintes tabelas – Tabela 5 – Tabelas de exemplificação de movimentação de
operações.
Imaginando só que nos encontrávamos no código 1 e nos desejávamos
posicionar no código N, segundo apenas a primeira tabela, seria necessário percorrer
todos os códigos entre os referidos (mais concretamente os códigos 2 e 3). Contudo, se
6
Os cursores são variáveis que nos permitir movimentar entre registos de forma eficiente, no
SGBdoc deverão ser variáveis “leves”.
ISEP – DEI
51
IMDB – Sistema de Indexação
SGBDoc
atentarmos na segunda tabela, verificamos que segundo um código obtemos uma
posição. Através desta posição, o deslocamento (na primeira tabela) é quase imediato
(por exemplo: “posicionar N”)!
Código
Valor
1
Valor1
2
Valor2
3
3
N
ValorN
Código
Posição
1
1
2
2
3
3
ValorN
N
Tabela 5 – Tabelas de exemplificação de movimentação de operações
Isto leva-nos a concluir que, além das referidas operações (ver Tabela 4 – Tabela
de operações de indexação), teríamos que ter também uma função que nos permitissem
posicionar numa determinada posição directamente (ver 5.2.4, para verificar as funções
criadas). O que se pretende é que depois de obtermos a posição, consigamos
posicionarmo-nos nessa posição da colecção de uma forma automática.
Seriam, então, necessárias duas funções, como nos mostra o seguinte quadro.
Função
Retornar posição
Posicionar
Descrição
Retornar a posição de uma dada colecção
Posicionar numa dada posição de um
colecção
Tabela 6 – Funções de posicionamento necessárias para uma indexação
ISEP – DEI
52
IMDB – Sistema de Indexação
SGBDoc
4.1.4.1 Porquê a indexação no SGBdoc?
A indexação no SGBdoc torna-se então uma necessidade, já que, se atentarmos
no
ISEP – DEI
sector
anterior
(
53
IMDB – Sistema de Indexação
SGBDoc
4.1.4 Indexação sobre uma colecção), verificamos que a eficiência melhora, e de que
maneira, usando indexação.
E, quando estamos perante elevadas quantidades de dados desejando
movimentarmo-nos numa tabela segundo a ordem de uma determinada coluna, este tipo
de processo torna-se impraticável.
A indexação facilita-nos o processo de navegação entre registos e ainda nos
permitir usufruir de todas as anteriores funções existentes – sem indexação.
4.2 Exemplo de utilização
Imaginemos que desejamos representar um sistema de informação de Facturas.
Analisando o problema facilmente chegamos a conclusão que todas as facturas
têm elementos comuns: dizem respeito a um cliente, têm uma data, têm um conjunto de
produtos ou serviços vendidos e respectivo preço e normalmente têm também valores
globais como por exemplo a quantia total a pagar. Toda esta informação tipifica o que é
uma Factura. Temos então a informação necessária para especificar o que é um Tipo de
Documento Factura (pelos menos ao nível da sua estrutura de dados...).
Algumas informações de um Tipo de Documento Factura tomam valores
específicos em cada Documento Factura (instância do Tipo de Documento Factura). Por
exemplo, o cliente ou os artigos comprados variam de Factura para Factura. Por outro
lado, nalguns casos, existem informações que são constantes em todos os Documentos.
Por exemplo, se desejarmos representar numa Factura a identificação da empresa que a
emite (existem empresas que produzem pre-impressos com essa informação constante já
empresa no papel).
No que diz respeito às regras associadas à manipulação de uma Factura existem
vários exemplos que podemos apresentar. Um dos casos mais simples é a existência de
valores calculados num Documento. No caso da Factura poderíamos concluir que o
valor total da factura é uma informação calculada com base no valor de todos os
produtos e/ou serviços vendidos. Essa lógica poderia estar especificada num método do
ISEP – DEI
54
IMDB – Sistema de Indexação
SGBDoc
Tipo de Documento Factura. Podemos alargar esta análise. Por exemplo, se a empresa
que emite a Factura permitir o pagamento parcial desta poderemos ter um método que
especifica o comportamento de uma Factura quando há um pagamento parcial (que pode
implicar uma actualização dos artigos ou serviços que se consideram pagos assim como
do montante em dívida).
Este é um exemplo prático onde o SGBdoc é passível de ser usado, contudo,
para uma melhor compreensão seria útil atentar nos próximos parágrafos.
4.3 Exemplos de uso reais – I2S
Como já foi referido anteriormente o SGBdoc é utilizado em algumas aplicações
I2S. Pode mesmo já ser considerado um componente nuclear no seio das aplicações da
referida empresa.
4.3.1 CODOMO
O CODOMO é um modelo da I2S que incorpora o SGBdoc, é uma tecnologia
que incorpora diversos componentes da I2S (dos quais falaremos mais à frente), a saber:
o SAUD – Sistema universal de acesso a dados (ver Glossário)
o LPS – Linguagem para seguros
o SGBdoc
o Laboratório – aplicação visual para usar o CODOMO
ISEP – DEI
55
IMDB – Sistema de Indexação
SGBDoc
Figura 20 – Laboratório do CODOMO
Descrever as características do CODOMO é importante não só para descrever
algum componente que use o SGBdoc, mas também, para nos elucidarmos sobre a
aplicação onde foram executados testes de indexação para o sistema prático
desenvolvido.
4.3.1.1 Arquitectura
O CODOMO consiste basicamente num Sistema Gestor de Base de Documentos
(SGBdoc), com funcionalidades análogas às de sistemas gestores de bases de dados, que
possibilita uma gestão centralizada de documentos.
Um conceito fundamental do CODOMO é o de repositório entendendo-se este
como um sistema de gestão do armazenamento de documentos (documentos e tipos de
documentos).
ISEP – DEI
56
IMDB – Sistema de Indexação
SGBDoc
A figura seguinte mostra, a cinzento, os componentes da arquitectura
CODOMO.
Figura 21 – Arquitectura CODOMO
Com o repositório o CODOMO mantém versões de documentos e tipos de
documentos, identificando universalmente os documentos através de UDIDs (Universal
Document ID) e os tipos de documentos através de UTIDs (Universal Document Type
ID). Os repositórios são identificados por RIDs (Repository ID).
O CODOMO disponibiliza uma linguagem de definição de tipos de documentos
(LDTD) e uma linguagem de manipulação de documentos (LMD), já referenciadas
anteriormente.
A linguagem LDTD permite definir os diversos tipos de documentos, isto é,
definir a estrutura dos objectos de dados e os métodos.
A linguagem LMD permite que os utilizadores finais (componentes/aplicações)
possam criar novos documentos (de um determinado tipo) e trabalhar com documentos,
ou seja, alterar os seus objectos de dados, invocar métodos, executar comandos LPS
sobre documentos, etc.
Analisando a arquitectura apresentada verificamos que:
ISEP – DEI
57
IMDB – Sistema de Indexação
SGBDoc
O CODOMO fornece APIs que possibilitam o acesso a todas as suas
funcionalidades quer na vertente LDTD quer na vertente LMD.
O repositório é suportado, neste momento, em memória, sistema de ficheiros do
S.O. ou base de dados relacional. Quando suportado em base de dados relacional é
utilizado o sistema de acesso universal a dados (SAUD).
Para facilitar a definição de tipos de documentos existe a possibilidade de
utilização da LDTD sobre a forma de linguagem de script.
As aplicações e componentes de negócio devem utilizar a vertente Object
Oriented da API em COM.
Está disponível uma Consola CODOMO que permite o trabalho interactivo com
repositórios CODOMO, podendo-se criar e alterar documentos e tipos de documentos
de diversos repositórios.
4.3.1.2 Características Gerais das Aplicações baseadas em
CODOMO
Com as funcionalidades do CODOMO é possível desenvolver aplicações
caracterizadas por elevados graus de desempenho, de interoperabilidade, de
escalabilidade e de programabilidade.
4.3.1.2.1 Desempenho
O CODOMO é “thread safe” e foi desenvolvido em linguagem C. Além disso
possui um elevado desempenho no acesso ao repositório de documentos (ver
escalabilidade) possibilitando que os documentos sejam mais rapidamente processados
e transmitidos.
ISEP – DEI
58
IMDB – Sistema de Indexação
SGBDoc
4.3.1.2.2 Interoperabilidade
Um documento pode ser transformado pelo CODOMO num formato binário
(formato nativo de persistência) altamente compactado ou pode ser transformado no
formato XML.
No primeiro caso qualquer aplicação baseada na tecnologia CODOMO poderá
processar o documento. É o formato adequado para fazer passar um documento entre
camadas ou aplicações proprietárias (intra sistema).
No segundo caso qualquer aplicação que possa ler XML poderá processar os
dados do documento (somente os dados). Este formato é adequado para fazer passar um
documento entre aplicações não proprietárias (inter sistemas).
4.3.1.2.3 Escalabilidade
Escalabilidade é a capacidade de um sistema distribuído suportar o aumento da
quantidade de utilizadores sem degradar o seu desempenho. Um recurso que afecta a
escalabilidade é o conjunto de conexões a uma base de dados. A utilização de dados em
memória, isto é, desconectados de qualquer base de dados, contribui para uma solução
escalonável porque não retém “locks” nem mantém conexões abertas.
Se o documento estiver persistente, a sua escrita realiza-se através de uma única
operação e, a sua leitura realiza-se também com uma única operação incluída numa
operação de «check in» se a leitura for realizada para actualização.
Como a persistência de um documento se realiza através de um elemento num
formato binário, isto é, escreve-se todo o documento numa única operação de escrita e
lê-se todo o documento numa única operação de leitura e como após a leitura se pode
ISEP – DEI
59
IMDB – Sistema de Indexação
SGBDoc
desfazer a conexão ao sistema de armazenamento, pensamos que a escalabilidade está
optimizada.
Se o documento for alimentado a partir de uma base de dados, após a
transferência dos dados das tabelas para o documento a ligação à base de dados pode ser
desfeita, mesmo num processo de actualização da base de dados utilizando-se uma
estratégia optimista.
4.3.1.2.4 Programabilidade
Parte da lógica dos objectos de negócio pode ser implementada com métodos
escritos na linguagem LPS, a programação restante será realizada utilizando as
diferentes APIs disponibilizadas pelo CODOMO, como por exemplo, a interface COM
[9].
4.3.2 EURO – BigBang
A I2S, como quase todas as empresas informáticas da União Europeia (apenas
aqueles países que aderiram ao euro), tiveram a difícil tarefa de migrar todos os dados
monetários de escudos (ou na moeda correspondente) para EUROS. Usou-se o referido
CODOMO, juntamente com as funções SAUD e, claro, com a ajuda do SGBdoc. Esta
funcionalidade funcionava do seguinte modo, seleccionávamos uma base de dados a
converter e outra para onde enviar os dados convertidos. No caso concreto até eram
tabelas do AS/400 pelo que os campos até eram numéricos (os valores monetários eram
assinalados por uma outras configuração), os valores são assumidos de estarem em
escudos e serão convertidos para EURO na nova base de dados destino.
No entanto este procedimento teve alguns defeitos os quais veremos mais à
frente.
ISEP – DEI
60
IMDB – Sistema de Indexação
SGBDoc
Como já referido anteriormente existia uma dificuldade na conversão dos dados
em EUROS, este facto deve-se precisamente à inexistência de indexação no SGBdoc.
Este era um grave defeito do SGBdoc, o de não podermos ordenar logicamente os dados
de forma diferente da sua ordem física! No referido exemplo esta dificuldade constituiu
um grave problema. A conversão acabou por se revelar algo lenta. Isto implicou com
que o SGBDoc tivesse que carregar as colecções já de forma ordenada e que se
introduzisse alguma complexidade no código de conversão visto não ser possível (ou
fácil) obter outras ordenações dos dados após estes terem sido carregados para as
colecções.
Na risco temos uma colecção com os dados de um risco (ex: capital, etc) e que
está ordenada por código de risco. A colecção de participantes contém as pessoas que
subscreveram um seguro de determinado risco. Esta colecção esta ordenada por código
de risco e código de participante no risco. Se estamos no 1º participante do risco 2 e nos
desejamos colocar no 1º participante do risco 3 como o fazemos? Actualmente devemos
percorrer todos os elementos a partir do actual até alcançarmos um novo risco (como
nos ilustra a figura que se segue). Muitas vezes era também necessário voltar para trás,
para por exemplo guardar valores totais dos capitais de todos os participantes de um
risco e colocar esse resultado no primeiro participante (este simboliza o grupo dos
participantes do risco). Para fazer isto, tinha que se andar com o cursor da colecção até
encontrar o primeiro participante do risco em questão.7
Contudo, com indexação seria extremamente rápido e eficaz, já que só
necessitávamos de conhecer o código do código do Risco e, podíamos posicionar o
cursor no primeiro participante desse Risco. Como mostra, a vermelho, a seta da figura
que se segue.
7
Há também que considerar que uma colecção no SGBdoc apenas pode conter um cursor, ou
seja, não poderíamos colocar um cursor no primeiro participante de um risco de modo a proceder ao
posicionamento de modo automático
ISEP – DEI
61
IMDB – Sistema de Indexação
SGBDoc
Risco 1 – 1º Participante
Risco 1
Risco 1 – 2º Participante
Risco 1 – Nº Participante
Risco 2
Risco 2 – 1º Participante
Risco 2 – 2º Participante
Risco 2 – Nº Participante
Risco 3
Risco 3 – 1º Participante
Risco 3 – 2º Participante
Risco 3 – Nº Participante
Risco N
Risco N – 1º Participante
Risco N – 2º Participante
...
Risco N – Nº Participante
...
Figura 22 – Ilustração do problema encontrado na migração dos dados EURO – Big Bang I2S
ISEP – DEI
62
IMDB – Sistema de Indexação
BTrees no SGBdoc
5. BTrees no SGBDoc
A introdução de árvores balanceadas do SGBdoc foi, como já referido, no
âmbito de possibilitar a indexação de campos. Neste capítulo tentar-se-á exemplificar
como se procedeu à introdução de “BTrees ++” no SGBdoc, desde o processo de
análise até ao desenvolvimento propriamente dito.
Como o código Open Source estava escrito em linguagem C, tal como o
SGBdoc (um dos motivos porque funciona em multi-plataforma), também as alterações
ao código das árvores balanceadas foi procedido em linguagem C, assim como, as
funções, que descrevemos neste capítulo, escritas no SGBdoc para permitir a indexação
de dados.
5.1 Procedimento anterior à inserção de BTrees
Antes da inserção de árvores balanceadas no SGBdoc toda a navegação dentro
de uma colecção de registos era procedida sequencialmente, segundo a ordem de
entrada na colecção, ou seja, era impossível levar em linha de conta a ordem alfabética
de um dado campo da colecção.
Assim, quando pretendíamos movermo-nos de um registo para outro no SGBdoc
(ver capítulo anterior – 4.1 – Considerações Genéricas), teríamos obrigatoriamente de
passar pelos que se encontravam entre os dados registos comparando sempre os valores
por cada registo passado. Para pensarmos na impraticabilidade deste sistema basta
pensarmos que contínhamos as idades de N pessoas não ordenadas, e pretendíamos
obter aquele que tinha a maior idade, teríamos que fazer N comparações para obtermos
o que tinha maior idade! Com a introdução de árvores balanceadas bastaria obter a
última da árvore que logo nos forneceria o indivíduo com maior idade.
ISEP – DEI
63
IMDB – Sistema de Indexação
BTrees no SGBdoc
5.1.1 Exemplo de navegação sem BTrees
Para o exemplo que é apresentado de seguida temos de ter em linha de conta que
existe uma estrutura com os dados de uma pessoa:
o name – nome da pessoa
o age – idade da pessoa
o bthdate – data de nascimento
o Gender – Classificação das pessoas
Na imagem que se segue tenta-se traduzir (no texto seleccionado – função
SQL_SELECTINTOCOL) como foi procedido o carregamento dos dados (da tabela
PESSOAS do AS/400) a manipular para colecção (ALLPERSONS), claro que
anteriormente houve uma conexão ao AS/400 – função SQL_START. No quadro inferior
direito podemos visualizar que o tempo de carregamento deste registos – 125 345 – foi
procedido em aproximadamente trinta segundos.
Figura 23 – Carregamento dos dados para uma colecção
ISEP – DEI
64
IMDB – Sistema de Indexação
BTrees no SGBdoc
Na figura seguinte ilustram-se os dados obtidos a partir do AS/400, a tabela
PESSOAS com os campos referidos anteriormente (NAME, AGE, BTHDATE e
GENDER).
Figura 24 – Lista de dados obtidos a partir do AS/400
Na figura apresenta-se, além do já referido carregamento dos dados, no texto
seleccionado um ciclo para a obtenção da pessoa – “ZE MANUEL TESTE”. Neste ciclo
posicionamo-nos na primeira posição da colecção ALLPERSONS (função MOVEFIRST)
e depois vamos percorrendo a colecção (função MOVENEXT) e comparando o valor
actual com o valor pretendido. Era isto que poderíamos fazer antes de termos indexação.
Poderemos verificar (no painel do quanto inferior direito) que esta pesquisa demorou
aproximadamente setecentos milésimos de segundos.
ISEP – DEI
65
IMDB – Sistema de Indexação
BTrees no SGBdoc
Figura 25 – Obter um registo não usando indexação
5.2 Inserção de funções da árvore no SGBdoc
O programa de árvores balanceadas que estudamos (“BTrees ++”) era ideal
para o que desejávamos executar no SGBdoc, no entanto encontramos uma pequena
dificuldade, que era o facto de a leitura dos dados ser feita do disco rígido (ficheiro) e a
sua escrita dos dados depois de manipulados também seria executada no disco. Como os
dados do SGBdoc eram manipulados em memória seria necessária uma alteração no
referido procedimento, ou seja, em vez da abertura de uma b-tree receber um ficheiro de
leitura seria um buffer de dados e, como é óbvio, os dados depois de manipulados
seriam também escritos no referido buffer.
Contudo, para poder trabalhar com um buffer, tivemos de fazer novas funções de
escrita no ficheiro, assim como, variáveis que nos permitissem retornar a posição actual
do buffer e o tamanho deste.
ISEP – DEI
66
IMDB – Sistema de Indexação
BTrees no SGBdoc
Era então, necessário o desenvolvimento de funções de mapeamento do SGBdoc
para as árvores binários, para um melhor esclarecimento atentar na tabela seguinte.
Ainda teriam de ser desenvolvidas novas funções, relacionado com o facto de podermos
obter a posição de uma colecção e posicionamento numa colecção (ver 5.2.3).
Função SGBdoc
lps_f_Idx_Open
Função BTrees
Nome para invocação
++
externa
bOpen
IDX_OPEN
Observações
Abertura de uma
nova indexação a
partir
de
um
buffer,
que
estivesse
se
nulo
seria criado um
novo
lps_f_Idx_Save
I2s_Save
IDX_SAVE
Função que seria
desenvolvida
no
intuito de colocar
todos
os
dados
existentes
no
buffer para um
outro
buffer
passado
por
parâmetro
lps_f_Idx_Close
bClose
IDX_CLOSE
Fechar
uma
indexação
lps_f_Idx_Insert
bInsertKey
IDX_INSERT
Inserir uma nova
chave na árvore
lps_f_Idx_Delete bDeleteKey
IDX_DELETE
Remover
um
elemento
da
árvore
lps_f_Idx_Find
bFindKey
IDX_FIND
Pesquisa de uma
chave na árvore
lps_f_Idx_First
ISEP – DEI
bFindFirstKey
IDX_FIRST
Procura
a
67
IMDB – Sistema de Indexação
BTrees no SGBdoc
primeira chave da
árvore
lps_f_Idx_Last
bFindLastKey
IDX_LAST
Pesquisa a última
chave da árvore
lps_f_Idx_Next
bFindNextKey
IDX_NEXT
Pesquisa
a
próxima chave da
árvore
(em
relação à posição
onde
nos
encontramos
no
buffer)
lps_f_Idx_Prev
bFindPrevKey
IDX_PREV
Pesquisa a chave
anterior da árvore
(em
relação
à
posição onde nos
encontramos
no
buffer)
Tabela 7 – Mapeamento das funções de BTree ++ para o SGBdoc
De seguida iremos tentar exemplificar de um modo mais prático de como foi
efectuada a função lps_f_Idx_Open, as outras foram efectuadas de modo análogo.
No SGBdoc, existem determinadas regras que devem ser seguidas para
podermos acrescentar uma nova função, a saber:
o Primeiramente é necessário acrescentar uma entrada numa tabela que
contém todas as funções assim como o seu retorno, para o exemplo da
tabela que se segue,
Retorno
Nome da função
Real
lps_f_Idx_Open
Tabela 8 – Associar um retorno a uma função do SGBdoc
seria necessário acrescentar a seguinte entrada
{ lps_t_Real,
ISEP – DEI
lps_f_Idx_Open }
68
IMDB – Sistema de Indexação
o Posteriormente
BTrees no SGBdoc
teremos
que
associar
o
nome
da
função
(lps_f_Idx_Open), acrescentando mais uma entrada, sendo esta um
incremento em relação a uma suposta função anterior como demonstra na
figura o texto marcado a negrito (exemplo para o lps_f_Idx_Open)
#define ANTERIOR
1
#define TESTE
ANTERIOR + 1
#define LPS_F_IDX_OPEN
LPS_F_DESCRIBECMD + 1
Figura 26 – Exemplo de incrementação de uma função no SGBdoc
o Por último teremos que inserir uma entrada para configurar o
comportamento da função. Atentar na tabela que se segue.
Descrição
Nome Externo
Nome
abreviada
mapear
à
Valor do Exemplo
para IDX_OPEN
função
correspondente
(lps_f_Idx_Open)
Código de Identificação
Código
único
de 10630
identificação da função
Número de caracteres do Número de caracteres que o 8
Número Externo
Prioridade
nome externo contém
Prioridade de invocação da 0
função
Retorno
Número de parâmetros
Retorno da função
lps_t_Real
Número de parâmetros que 3
a função contém (máximo
de oito parâmetros
Descrição de cada
Descrição
parâmetro8
parâmetro
8
de
cada lps_t_Bin_Ref,
existente
lps_t_Real,
na lps_t_Real_Ref, 0, 0, 0, 0, 0
Os parâmetros não existentes têm descrição “0” (zero).
ISEP – DEI
69
IMDB – Sistema de Indexação
BTrees no SGBdoc
função, num máximo de
oito parâmetros
Tabela 9 – Descrição dos parâmetros de uma função a inserir numa dada tabela do
SGBdoc de modo a definir o comportamento da função
O exemplo que se segue ilustra a entrada efectuada para o exemplo que
estamos a abordar:
{ "IDX_OPEN", 10630, 8, 0, lps_t_Real, 3, { lps_t_Bin_Ref, lps_t_Real, lps_t_Real_Ref, 0, 0, 0, 0, 0}}
De seguida apresentamos um pouco do código exemplo que introduzimos para o
mapeamento da função bOpen, na criação, como é lógico, da função lps_f_Idx_Open.
Como já descrito mais à frente (ver 5.2.2) e também anteriormente (ver capítulo
anterior - 4.1.3), a obtenção dos parâmetros era feito de um modo inverso com
demonstras o código que se segue; p1, significa o primeiro parâmetro, embora
possamos verificar que é o último a obter; por sua vez, p3, será o terceiro e último
parâmetro, no entanto, verificamos no código que é o primeiro parâmetro obtido.
Posteriormente à obtenção dos parâmetros verificamos no código à função
mapeada – bOpen - e a respectiva passagem dos valores obtidos por parâmetro numa
estrutura interna (bOpenType).
/*
Abre um índice com base num campo binário
Parametros de entrada
BIN_REF -> buffer com o indice
NUM -> tamanho da chave
Parametros de saida
NUM_REF -> handle do indice
Retorno
-> 0 se conseguiu abrir o indice
*/
if( lps_i_PopRef(&(p_rtAux->rtStack), &p3) == lps_TRUE )
/* NUM_REF ->Handle do Indice */
if( lps_i_PopDoubleVal(&(p_rtAux->rtStack), &p2) == lps_TRUE )/* NUM ->Tamanho da chave */
if( lps_i_PopRef(&(p_rtAux->rtStack), &p1) == lps_TRUE )/* BIN_REF -> buffer com o indice */
if( lps_i_PopWH(&(p_rtAux->rtStack), &wh) == lps_TRUE )/* BIN_REF -> buffer com o indice
*/
…
ISEP – DEI
70
IMDB – Sistema de Indexação
BTrees no SGBdoc
/*Construção do Tipo de abertura da árvore balanceada*/
bOpenType info;
info.iName = p1;
info.len = len(p1);
info.keySize = p2;
bOpen(info, &handle);
Figura 27 – Exemplo do código lps_f_Idx_Open
Apenas se efectuou uma descrição mais pormenorizada de como foi efectuada a
função lps_f_Idx_Open, já que, como foi referido, todas as outras têm um procedimento
análogo.
5.2.1 Descrição das funções elaboradas
Para uma melhor compreensão do que foi implementado e da tabela acima
descrita irá fazer-se de seguida uma descrição das funções elaboradas.
5.2.1.1 Abertura de indexação - lps_f_Idx_Open
Através da obtenção dos parâmetros, irá proceder-se à validação do buffer que é
passado por parâmetro, e alocar memória para colocar esses mesmo dados do buffer
num buffer temporário, caso existam. Posteriormente é invocada a função bOpen que
fará a abertura de uma nova árvore. Também nesta função é importante o parâmetro que
determina o tamanho das chaves.
5.2.1.2 Guardar dados - lps_f_Idx_Save
Para guardar os dados primeiro tivemos que efectuar uma função que nos
permitisse saber qual o tamanho dos dados existentes, para esta eventualidade elaborouse a função – I2s_Ptr_Len.
ISEP – DEI
71
IMDB – Sistema de Indexação
BTrees no SGBdoc
Como já descrito anteriormente, o programa original apenas escrevia os dados
para disco, no nosso caso desejávamos que escrevesse num buffer, para tal
implementou-se a função I2s_Save.
Então, depois da obtenção do parâmetro é invocada a função I2s_Ptr_Len,e
posteriormente a função I2s_Save que nos retornará os dados gravados num buffer.
5.2.1.3 Fecho da indexação - lps_f_Idx_Close
Apenas é necessário passar por parâmetro o endereço do handle da árvore a
fechar, e depois de obtido esse parâmetro é invocada a função bClose.
5.2.1.4 Inserção de uma nova chave - lps_f_Idx_Insert
Mais uma vez torna-se necessário a obtenção dos parâmetros, é posteriormente
invocada a função bInsertKey que se encarregará da inserção da nova chave na árvore.
5.2.1.5 Eliminação de uma chave - lps_f_Idx_Delete
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função bDeleteKey que fará a eliminação da chave na árvore.
5.2.1.6 Pesquisa de uma chave - lps_f_Idx_Find
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função lps_f_Idx_Find que retornará a chave encontrada, se for caso disso.
5.2.1.7 Posicionar no início - lps_f_Idx_First
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função lps_f_Idx_First que retornará a chave da primeira posição da árvore.
ISEP – DEI
72
IMDB – Sistema de Indexação
BTrees no SGBdoc
5.2.1.8 Posicionar no fim - lps_f_Idx_Last
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função lps_f_Idx_Last que retorna a chave que se encontra na última posição da árvore.
5.2.1.9 Posicionar próximo - lps_f_Idx_Next
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função bDeleteKey que retornará a próxima posição na árvore em relação à que nos
encontramos actualmente.
5.2.1.1 Posicionar anterior - lps_f_Idx_Prev
Posteriormente à obtenção dos parâmetros, irá proceder-se à invocação da
função lps_f_Idx_Prev que retornará a posição anterior na árvore em relação à que nos
encontramos actualmente.
5.2.2 Problemas encontrados no desenvolvimento
O mapeamento das funções é ainda penoso já que os parâmetros recebidos em
cada uma das funções vêm pela ordem inversa (para um melhor esclarecimento atentar
no capítulo 4.1.3, referente ao SGBdoc, relacionado com o LPS). Por outras palavras, os
parâmetros encontram-se numa pilha (LIFO – “Last In First Out” – o último a entrar
será o último a sair), ou seja, o último parâmetro será aquele que iremos obter primeiro
e assim sucessivamente até ao primeiro parâmetro que será o último a obter. Isto,
porque o SGBdoc usa a linguagem LPS que por sua vez usa uma stack na
implementação. Além desta dificuldade ainda teremos que transformar os dados
recebidos por parâmetros em dados legíveis (ou seja, interpretáveis) pelas funções que
iremos invocar.
ISEP – DEI
73
IMDB – Sistema de Indexação
BTrees no SGBdoc
Depois de obtidos os dados também teremos que colocar o retorno na pilha, e os
valores que foram passado por referência terão que ser actualizados de uma forma
particular (de acordo com as imposições do SGBdoc).
5.2.3 Funções de posicionamento
Além das referidas funções de mapeamento com a árvore balanceada foi
também necessário a construção de duas funções, para melhor compreensão atentar na
tabela seguinte.
Função
Nome para
Parâmetros
Observações
Colecção
Permite-nos obter a
invocação
externa
lps_f_Get_Pos
GETPOS
posição em que nos
encontramos numa
dada colecção
lps_f_Goto_Pos
GOTOPOS
Colecção e posição
Permite posicionar
numa colecção,
segundo uma dada
posição
Tabela 10 – Funções de posicionamento no SGBdoc
5.2.4 Guardar árvore e reabri-la
Existe também uma funcionalidade importante no contexto das funções da
árvore balanceada (atentar Tabela 7 – Mapeamento das funções de BTree ++ para o
SGBdoc), se verificarmos a função bOpen, verificamos que podemos passar um buffer
por parâmetro. Este buffer quando passado sem nenhum conteúdo (modo mais normal),
é construída uma árvore de novo, contudo, se passarmos algo no referido buffer existe
uma tentativa de construção de árvore a partir desse mesmo conteúdo.
ISEP – DEI
74
IMDB – Sistema de Indexação
BTrees no SGBdoc
Para o buffer conter algo válido (construção de uma árvore válida), é necessário
que primeiramente esse buffer seja actualizado a partir da invocação do método do
SGBdoc “lps_f_Idx_Save”.
Figura 28 – Ilustração de como guardar um árvore (idx_save) e reabrir a árvore guardada
Se atentarmos na imagem anterior podemos visualizar (três instruções acima do
texto seleccionado) a invocação da função IDX_SAVE que guarda os dados
anteriormente trabalhados num campo binário (bin_idx), é este o campo posteriormente
usado como buffer na função IDX_OPEN (uma linha antes do texto seleccionado). No
texto seleccionado tenta-se verificam-se resultados coerentes com os dados existentes
no binário/buffer (bin_idx).
5.3 Resultado final
Neste capítulo tentar-se-á ilustrar os exemplos obtidos e, a valorização que o
sistema de indexação proporciona ao SGBdoc.
ISEP – DEI
75
IMDB – Sistema de Indexação
BTrees no SGBdoc
5.3.1 Exemplo de navegação com BTrees
No seguimento da linha anterior tentaremos exemplificar a navegação entre
registos, mas desta vez já usando árvores balanceadas, de modo a se conseguir provar a
eficácia deste método.
É criado um novo índice (nova árvore balanceada) com a função IDX_OPEN.
Depois no texto seleccionado representa-se um ciclo onde todas as chaves existentes na
colecção (aproximadamente 125 000) são inseridas (através da função IDX_INSERT) no
índice previamente aberto, este processo ocorreu em aproximadamente um segundo e
meio (como nos mostra o painel inferior direito).
Figura 29 – Carregar dados na b-tree
No écran que se segue pode-se verificar, no painel inferior direito, que o tempo
de uma pesquisa (IDX_FIND) na árvore não é distinguível ao milésimo de segundo.
ISEP – DEI
76
IMDB – Sistema de Indexação
BTrees no SGBdoc
Como verificamos no exemplo é pesquisada a mesma pessoa (“ZE MANUEL TESTE”)
que já foi usada numa procura sem indexação (ver 5.1.1).
Figura 30 – Pesquisa de um valor na árvore balanceada
Por último, e no seguimento do écran anterior, verificamos na imagem seguinte
que no texto seleccionado nos posicionamos na primeira posição (função MOVEFIRST),
depois a colecção ALLPERSONS é colocada na posição pretendida com o valor que a
variável valor continha. Por último listamos o nome da posição actual da colecção
(ACTUAL(ALLPERSONS).NAME) para ilustrar a realidade da pesquisa.
Verifica-se que este posicionamento apenas demorou cinquenta milésimos de
segundo.
ISEP – DEI
77
IMDB – Sistema de Indexação
BTrees no SGBdoc
Figura 31 – Posicionar na colecção usando indexação
5.3.2 Comparação de resultados
Verificamos, na figura acima, que o tempo de execução/pesquisa do valor
apenas demorou cinquenta milésimos de segundo e a procura na árvore (IDX_FIND)
nem sequer é notória temporalmente ao nível do milésimo de segundo. Se antentarmos
em 5.1.1, verificamos que uma pesquisa com o mesmo efeito demorou
aproximadamente setecentos milésimos de segundo, ou seja, o comportamento
melhorou substancialmente.
5.4 Inovações futuras
Uma das inovações que futuramente pode vir a ser implementada é uma
hierarquia de indexação, como mostra a figura que se segue.
ISEP – DEI
78
IMDB – Sistema de Indexação
BTrees no SGBdoc
Idade
Sexo
BI
Figura 32 – Hierarquia de indexação
Na figura anterior tentou-se representar, como exemplo, a indexação em
primeira instância pela idade, posteriormente pelo sexo e em último lugar pelo bilhete
de identidade. Esta indexação hierárquica é algo a desenvolver num futuro próximo.
Existem também outras inovações futuras que será o de a árvore balanceada
permitir a inserção de chaves duplicadas, que poderia ser através de , por exemplo, uma
configuração (aceitando ou não essas chaves duplicadas).
ISEP – DEI
79
IMDB – Sistema de Indexação
6.
Conclusões
Conclusões
O assunto tratado no relatório é já bastante importante no mercado de trabalho,
no entanto, julgo que é ainda cedo para este assunto atingir o seu apogeu, por outras
palavras, IMDB virá a tornar-se muito mais importante no futuro, não só pelo
crescimento exponencial de informação, mas também pelas respostas rápidos (quase em
tempo real) que por vezes desejamos obter.
É também importante referir o quanto este tema pode ser vasto, e que o relato
deste relatório, deste projecto, é bastante diminuto quando comparado com a quantidade
de tecnologias que aqui são misturadas (bases de dados, estruturas de dados complexas
– diversas formas de árvore –, e como é óbvio o próprio conceito de IMDB).
Além dos referidos conceitos abordados há também que evidenciar que este
tema – IMDB – necessita ainda de muita investigação, de modo a torná-lo realmente
importante em todo e qualquer sistema. Questões como a capacidade de hardware
necessárias para a implementação de um sistema com quantidades de dados em
crescimento exponencial, podem não ficar ainda respondidas no presente momento,
ainda há um longo caminho a percorrer.
Contudo, foi extremamente importante o contacto com esta tecnologia, mais
importante ainda pelo facto de algo prático ter sido implementado, que virá a ser usado
a nível empresarial, o que nos leva a pensar que o “mundo” IMDB não é utópico.
Também foi possível provar com o sistema de indexação desenvolvida um
melhoramento substancial da pesquisa a dados.
Os objectivos a que me propôs foram na sua maioria atingidos, já que, o
desenvolvimento de uma ferramenta que fizesse a indexação dos dados em memória foi
conseguida, estudou-se o IMDB (algumas das aplicações já existentes), também se
estudaram árvores (principalmente as balanceadas – BTree++).
ISEP – DEI
80
IMDB – Sistema de Indexação
Conclusões
Deve-se concluir que o projecto revelou uma área muito importante, mas ainda
muito pouco estudada, o que revela a necessidade deste tipo de sistemas.
Tal como o projecto elaborado no bacharelato, também este projecto, embora
com uma abordagem mais teórica, permitiu-me alcançar conhecimentos importantes,
não só na conclusão da minha vida académica, mas para a minha carreira profissional.
ISEP – DEI
81
IMDB – Sistema de Indexação
Glossário e linguagem específica
Glossário e linguagem específica
A
ActiveX – Uma tecnologia usa várias linguagens para aceder a dados em que se
usam modelos de objectos incorporadas em objectos de conexão a dados, objectos
para execução de comandos, objectos Recordset e colecções dentro destes objectos.
O modelo dos objectos do ADO fornece facilidades para uso de objectos,
propriedades, e métodos para criação de scripts que podem aceder a dados de uma
base de dados.
ASP – Active Server Page, é uma ambiente onde se combinam componentes como
páginas HTML, scripts e ActiveX para criar aplicação Web.
D
DB2 – Base de dados existente num sistema AS/400 da IBM. É uma base de dados
bastante poderosa e muito bem vista no mercado.
Data Sources – Também conhecido pela sigla DSN, e contém o registo de toda a
informação necessária para conectar a uma dada base de dados, é usado no ODBC.
DataTable – Usado pelo DataSet – Microsoft - , representa toda a informação de
uma tabela. O esquema da informação de uma tabela é definido pelo
DataColumnCollection, que constrói a tabela. Quando duas tabelas estão
relacionadas entre si, o objecto DataRelation usa um DataColumn de cada tabela
para relacionar dados.
DataRelation – Usado pelo DataSet – Microsoft - , Relaciona múltiplas tabelas e
facilita a navegação entre os registos de tabelas relacionadas. Quando tentamos
aceder a registos relacionados, o objecto DataRelation é passado para os métodos
GetChildRows e GetParentRow. É o objecto DataRelation que determina quais são
as tabelas relacionadas a pesquisar, de modo a retornar os dados associados à
invocação dos métodos GetChildRows ou GetParentRow.
ISEP – DEI
82
IMDB – Sistema de Indexação
Glossário e linguagem específica
DataRow – Usado pelo DataSet – Microsoft - , Representa a informação de um
único registo. Os referidos métodos que retornam os dados relacionados
(GetChildRows e GetParentRow), são membros do objecto DataRow.
DataColumn – Usado pelo DataSet – Microsoft - , Representa um campo, que pode
definir o esquema para uma DataTable. Quando duas tabelas são relacionadas o
objecto DataRelation usa o valor das colunas de cada tabela para relacionar dados,
DataApdater – Usado pelo DataSet – Microsoft - , É um elo de ligação entre a base
de dados e o DataSet e vice-versa.
DLL – É um ficheiro que contém uma ou mais funções que são compiladas, e
guardadas separadamente dos processos que os usam. Em Windows, o sistema
operativo mapeia as DLL (Dynamic-link Libraries) para o espaço de memória do
processo, no início da aplicação ou enquanto esta a correr. Estas ficheiro tem
extensão .DLL.
E
EJB – Enterprise Java Beans, é uma arquitectura de componentes para
desenvolvimento e instalação de aplicações de empresas distribuídas baseada sobre
componentes. As aplicações que utilizam a arquitectura Enterprise Java Beans são
evolutivas, transaccionais e seguras. Essas aplicações podem ser escritas uma vez e
instaladas sobre todas as plataformas de servidor que suportarem as especificações
Enterprise Java Beans.
J
Java – Linguagem de programação orientada a objectos muito famosa pela
produtividade que os programadores conseguem alcançar.
JDBC – É no fundo o “ODBC do Java”, já que este é um encapsulamento do
ODBC.
L
ISEP – DEI
83
IMDB – Sistema de Indexação
Glossário e linguagem específica
LPS – Linguagem para seguros, linguagem de programação da I2S, com funções
específicas relacionadas com o mundo do negócio das seguradoras.
LDTD – Linguagem de definição de tipos de documentos, que permite uma forma
simples e amigável de definir tipos de documentos
LMD – Linguagem de manipulação de documentos, permite que os utilizadores
possam criar documentos e trabalhar com os documentos, ou seja, alterar os seus
objectos de dados, invocar métodos, e executar comandos LPS sobre documentos.
LIB – É conhecido como o comum formato de ficheiros (Common Object File
Format - COFF), é gerado por ferramentas da Microsoft (em 32-bit), para as
normais e para as bibliotecas importadas. A extensão destes ficheiros é .LIB.
M
multi-thread – Processamento/computação de dados paralelo, ou seja, ter dois
processos a executar paralelamente.
O
OLE DB – Uma arquitectura de bases de dados que fornece uma acesso universal a
dados com integração sobre a rede de uma empresa, desde o servidor a um
computador de rede, independentemente do tipo de dados. OLE DB é um suporte
genérico e tem uma estratégia eficiente para aceder a dados através do ODBC,
porque permite aceder a mais tipos de dados e é baseado no formato COM
ODBC – Open Database Connectivity is an industry standard and a component of
Microsoft Windows Open Services Architecture (WOSA). The ODBC interface
makes it possible for applications to access relational data stored in almost any
database management system (DBMS).
Open Source – Código de livre uso, embora a modificação desse mesmo código é na
maior parte dos casos interdita, a sua distribuição tem regras muito particulares.
ISEP – DEI
84
IMDB – Sistema de Indexação
Glossário e linguagem específica
Oracle – É também uma base de dados muito usada nos dias que correm.
R
RecordSet – Agrupa um conjunto de resultados de resultados obtidos depois de uma
dada pesquisa a uma ou mais tabelas.
S
SAUD – Este conjunto de funções permite o acesso a bases de dados através da
linguagem LPS.A LPS acede a bases de dados externas através da biblioteca SAUD.
As funções que permitem esta funcionalidade da LPS estão implementadas como
UDFs numa DLL.
SQL Server – É um gestor de bases de dados, sobre o qual a Microsoft detém os
direitos. Tem como função a gestão de bases de dados de várias servidores, assim
como, a gestão das respectivas tabelas.
T
Tabelas de hash – Um conjunto de chaves numéricas para permite o fácil acesso,
localização de um registo numa tabela, ou um ponto inicial para pesquisar um
registo associado à chave. Se a chave for alfanumérica , então a cada caracter é
associado um valor numérico para permitir manipulação numérica.
U
UNICODE – é a forma como os dados são representados (o texto – os bits e os
bytes), sendo UNICODE permite que ao mudarmos de plataforma (AS400,
Windows, UNIX...), continuando a aceitar quase todo o tipo de caracteres é baseado
em códigos de 16 bits.
X
XML – “Extensive Markup Language”, é um tipo de documentos muito usuais hoje
em dia, que têm como função descrever os dados de uma forma estruturada,
tornando as buscas mais rápidas, já que, é organizado de uma forma hierárquica.
ISEP – DEI
85
IMDB – Sistema de Indexação
Referências
Referências
[1] http://www.public.asu.edu/~peterjn/btree
[2] Polyhedra In-Memory Database, OSE Systems, www.ose.com
[3] http://msdn.microsoft.com
[4] http://www.borland.com/
http://www.sourceforge.net/
http://www.ibm.com/
[5] SQL-IMDB White Paper, QuiLogic
http://www.quilogic.com/home.htm
[6] http://www.quilogic.com/home.htm
[7] http://lcm.csa.iisc.ernet.in/dsa/node2.html
[8] T-Tree or Btree: Main Memory Database Index Structure Revisites.
Hongjun Lu, Yuet Yeung Ng, Zenping Tian.
http://www.public.asu.edu/~peterjn/btree
A general solution of the n-dimensional B-Tree problem, Michael
Freeston.
Main-Memory Index Structures with
fixed size partial keys. Philip
Bohannon, Peter MacIIRoy, Rajeev Rastoji.
[9]
ISEP – DEI
Manual do CODOMO – I2S
86
IMDB – Sistema de Indexação
Bibliografia
Bibliografia
o http://www.microsoft.com
o http://msdn.microsoft.com
o http://www.fit.qut.edu.au/~maire/baobab/baobab.html
o http://www.public.asu.edu/~peterjn/btree
o Apontamentos de Linguagens de Programação I, 1º ano de do curso de
Engenharia Informática do Instituto Superior de Engenharia do Porto.
o T-Tree or Btree: Main Memory Database Index Structure Revisites. Hongjun
Lu, Yuet Yeung Ng, Zenping Tian.
o Manual do CODOMO – I2S
o Heitlinger ,Paulo - Guia Prático do XML, Centro Atlântico
o A general solution of the n-dimensional B-Tree problem, Michael Freeston.
o Main-Memory Index Structures with
fixed size partial keys. Philip
Bohannon, Peter MacIIRoy, Rajeev Rastoji.
ISEP – DEI
87
IMDB – Sistema de Indexação
Índice Remissivo
Índice Remissivo
.
.NET.................................................................................................................... 19, 20, 21
A
ActiveX ................................................................................................... 19, 23, 24, 27, 82
ADO............................................................................................ 19, 20, 21, 82, 94, 96, 97
ADT .......................................................................................................................... 30, 31
Árvores binárias ................................................................................ 13, 24, 31, 63, 66, 76
AVL .................................................................................................................... 30, 31, 33
B
b-tree ......................................................................... 33, 34, 35, 36, 38, 39, 40, 42, 43, 66
BTrees ................................................................. 12, 14, 15, 30, 35, 39, 63, 64, 66, 67, 76
BTrees ++ ................................................................................... 12, 14, 15, 30, 63, 66, 67
C
CODOMO..................................................... 13, 46, 47, 49, 55, 56, 57, 58, 59, 60, 86, 87
Colecções ............ 20, 21, 42, 46, 48, 49, 51, 52, 54, 61, 63, 65, 67, 74, 82, 94, 95, 96, 97
D
DataAdapter ........................................................................................................ 20, 21, 22
DataColumn .............................................................................................................. 82, 83
DataColumnCollection ................................................................................................... 82
DataRelation ............................................................................................................. 82, 83
DataRow ......................................................................................................................... 83
DataSet.................................................................................. 19, 20, 21, 22, 23, 28, 82, 83
DataTable............................................................................................................ 20, 82, 83
Documento............................................................................ 14, 45, 46, 47, 48, 54, 56, 92
ISEP – DEI
88
IMDB – Sistema de Indexação
Índice Remissivo
H
Hierarquia ......................................................................................... 19, 28, 48, 78, 79, 85
HTML ............................................................................................................................. 82
I
I2S ....................................................... 9, 10, 12, 14, 15, 45, 50, 55, 60, 62, 84, 86, 87, 91
IMDB ...................................................... 14, 15, 18, 19, 23, 24, 25, 26, 27, 28, 29, 80, 86
Indexar ................................................................................................ 1, 10, 14, 28, 51, 54
Internet .............................................................................................. 12, 16, 18, 28, 94, 97
J
Java ............................................................................................................... 19, 22, 28, 83
L
LDTD...................................................................................................... 47, 49, 57, 58, 84
LMD.............................................................................................................. 47, 57, 58, 84
LPS........................................ 46, 47, 50, 55, 57, 60, 67, 68, 69, 71, 72, 73, 74, 75, 84, 85
M
Memória... 1, 10, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28, 29, 30, 33, 35,
42, 45, 46, 48, 58, 59, 66, 71, 80, 83, 86, 87
MySQL ........................................................................................................................... 27
R
RAM ....................................................................................................... 18, 27, 29, 33, 35
Recordset .................................................................................... 20, 21, 82, 85, 94, 95, 96
red-black tree .................................................................................................................. 33
S
SAUD............................................................................................................ 55, 58, 60, 85
SGBdoc .. 10, 12, 13, 14, 15, 30, 45, 46, 48, 49, 50, 51, 53, 55, 56, 60, 61, 63, 65, 66, 67,
68, 69, 70, 73, 74, 75
ISEP – DEI
89
IMDB – Sistema de Indexação
Índice Remissivo
X
XML.............. 12, 13, 14, 16, 19, 20, 21, 23, 25, 26, 27, 28, 48, 59, 85, 87, 92, 93, 94, 97
ISEP – DEI
90
IMDB – Sistema de Indexação
Anexos
Anexos
A.1 I2S, S.A. – Informática Sistemas e Serviços
Fundada em 1984 por cinco elementos do corpo docente do curso de Informática
do Instituto Superior de Engenharia do Porto, a I2S começou por ser uma empresa de
formação com o objectivo de vir a tornar-se posteriormente numa entidade oficial de
ensino superior na área das novas tecnologias e sistemas de informação.
Começou também, por desenvolver software genérico na área de gestão como a
contabilidade, a facturação, a gestão de stocks, entre outros.
Em 1989, a I2S aceitou a proposta da REAL Companhia de Seguros, SA., que
consistia no desenvolvimento e na manutenção dum conjunto de soluções informáticas
eficazes de forma a responder às necessidades dos agentes de seguros. Em
contrapartida, essa companhia deteria 51% das acções da I2S e o restante dividido pelos
sócios e por alguns funcionários da I2S.
Beneficiando do lançamento pela IBM do sistema informático AS/400, em 1988,
a I2S passou, quase sem concorrência, a liderar o mercado nacional de soluções
informáticas para a actividade seguradora.
Em 1996, devido ao alargamento dos negócios para o estrangeiro, esta empresa
procedeu a um aumento do capital social de 50.000 cts para 150.000 cts, a partir de
reserva de capital e duma alteração no quadro de distribuição dos títulos das acções,
onde a Real Companhia de Seguros, SA. cedeu grande parte da sua quota à Partinvest
(46,6%). Deste modo, a I2S reforça a sua imagem deixando de pertencer
maioritariamente a uma companhia de seguros.
ISEP – DEI
91
IMDB – Sistema de Indexação
Anexos
A.2 XML
XML é o formato universal para partilha de dados entre aplicações. O conceito
XML é simples e as possibilidades são inúmeras. Documentos em formato XML podem
conter bases de dados, transacções comerciais, catálogos de produtos, gráficos
vectoriais, equações matemáticas, fórmulas químicas, relatórios financeiros. Dados
bibliográficos, anúncios publicitários, enfim, quase todos os dados estruturados em
texto.
A flexibilidade da XML provém da faculdade de transpostar variadíssimos tipos
de dados e de mantê-los estruturalmente coesos. A XML serve magnificamente para a
estruturação de qualquer tipo de dados para descrevê-los sem dúvidas ou ambiguidades
em formato de texto.
Figura 33 – Exemplo de documento XML
Isto porque a XML permite definir a linguagem de marcação mais adequada a
um tipo de documentos.
ISEP – DEI
92
IMDB – Sistema de Indexação
Anexos
A eXtended Markup Language (XML) rapidamenre adquiriu grande
popularidade entre os peritos informáticos. Um factor determinante para o rápido
avanço da XML é o suporte garantidos por empresas líderes do mercado do software –
empresas como a Microsoft, Oracle, SAP, Sofware AG, IBM, SUN – entre outras...
A XML é uma tecnologia fundamental da nova plataforma .NET da Microsoft.
Um outro factor determinante do êxito da XML está fundamentada na sua
própria natureza: o formato XML tornou-se, em pouco tempo, um formato universal
para a partilha de dados entre aplicações. O conceito e a filosofia da XML são simples,
os seus derivados e as ossíveis aplicações são inúmeras, como já mencionado
anteriormente.
Onde antes existiam bastiões proprietários, esta nova linguagem trouxe uma
grande simplificação para a transferência e para a partilha de dados. Com a metalinguagem XML facilmente se definem linguagem de marcação para partilha de
informação entre aplicações baseadas em sistemas incompatíveis. Incompatíveis, por
trabalhar com formatos proprietários.
Convém salientar de antemão qua a partilha de dados muito estruturados entre
computadores heterogéneos figura entre as aplicações principais da XML. “A aplicação
mais importante da XML nos próximos anos será a comunicação de computador a
computador, ou seja, a partilha de dados – e não o diálogo entre homem e o
computador”, como aformou Simon Phipps, da IBM.
ISEP – DEI
93
IMDB – Sistema de Indexação
Anexos
Figura 34 – Permuta de dados entre dois sistemas distintos com XML
A integração fácil entre aplicações de uma empresa – ou de empresas diferentes
– está sempre entre as grandes potencialidades da XML.
A.3 ADO
ADO foi desenhado com o intuito de permitir aos utilizadores por programação
aceder, editar e actualizar data sources atravé do interface OLE DB. A maneira mais
comum para usar o ADO é fazer uma ou mais pesquisas a uma tabela de uma base de
dados relacional, retornando e mostrando os dados numa aplicação, e permitir ao
utilizador fazer alterações sobre a informação obtida, assim como, guardar a informação
modificada. Outras tarefas que podemos fazer por programação com o ADO são:
o Pesquisar numa base de dados usando SQL e mostrando os resultados
o Aceder a informação que se encontra num ficheiro na Internet
o Gerir mensagens e directórios num sistema de e-mail.
o Guardar informação de uma base de dados para um ficheiro XML.
o Executar comando com o auxílio do XML, e retornando uma stream
XML.
o Guardar dados binários para uma stream XML.
o Permitir aos utilizadores que rever e alteraros dados de tabelas de bases
de dados.
o Criar e reusar comandos parametrizados sobre uma base de dados
o Executar stored procedures.
o Criar dinâmicamente uma estrutura, chamada Recordset, para gerir,
navegar e conter os dados.
o Operações de transacção
o Filtrar e ordenar dados baseado-se num critério, isto em tempo de
execução
o Criar e manipular resultados hierárquicos de uma base de dados
ADO requer apenas nove objectos e quatro colecções para fornecer todas as suas
funcionalidades, atentar na tabela seguinte.
ISEP – DEI
94
IMDB – Sistema de Indexação
Anexos
Objectos e colecções
Objecto Connection
Descrição
Representa uma sessão única de um data source.
No caso dos sistemas cliente – servidor, pode ser
equivalente a uma conecção para um servidor
Dependendo
network.
da
funcionalidade
suportado pelo servidor, algumas colecções,
métodos
ou
propriedades
de
um
objecto
Connection podem não estar disponíveis
Objecto Command
Usado para definir uma commando específico,
como um commando SQL, executado sobre um
data source.
Objecto Recordset
Representa todos os registos obtidos de uma ou
mais tabela depois de executado um comando.
Todos os objectos Recorset consistem em registos
(linhas) e campos (colunas)
Objecto Record
Representa uma única linha de dados, ou de um
Recordset ou de um servidor. Este registo pode
representar um registo de uma base de dados ou
outro tipo de objecto como um ficheiro ou
directoria, dependento do servidor
Objecto Stream
Representa uma stream binário ou em formato de
texto. Po exemplo, um documento XM;L pode
ser carregado para uma stream através de um
comando ou através do retorno de alguns servidos
como resultado de uma pesquisa
Objecto Parameter
Representa um parâmetro ou argumentoassociado
a
um
objecto
Command,
baseado
na
parametrização de uma pesquisa ou de um stored
procedure
Objecto Field
Representa os dados de uma coluna com um tipo
de dados comum. Cada objecto Field corresponde
ISEP – DEI
95
IMDB – Sistema de Indexação
Anexos
a uma coluna num Recordset
Objecto Property
Representa as características de um objecto ADO
que é definido pelo servidor. Os objectos ADO
têm dois tipos de propriedades: built-in e
dinâmicas. As propriedades Built-in são as
propriedades
implementados
no
ADO
e
disponíveis para qualquer objecto. O objecto
Property é um repositório das propriedades
dinâmicas, definidas pelo servidor
Objecto Error
Contém detalhes sobre os erros ocorridos no
acesso a dados que dizem respeito a uma única
operação envolvendo o servidor
Colecção Fields
Contém todos os objectos Field de um Recordset
ou de um objecto Record
Colecção Properties
Contém todos os objectos Property para uma
instância específica de um objecto
Colecção Parameters
Contém todos os objectos Parameter de um
objecto Command
Colecção Errors
Contém todos os objectos Error criados na reposta
a uma única falha
Tabela 11 – Descriçãos dos objectos e colecções ADO
A figura que se segue ilustra melhor o enquadramento dos conceitos abordados.
ISEP – DEI
96
IMDB – Sistema de Indexação
Anexos
Figura 35 – Objectos e colecções ADO
A.4 .NET
Neste parte do anexo apenas se fará uma brave introdução acerca do que é o
.NET, já que, esta plataforma é bastante extensa e complexa, apenas se pretende uma
pequena compreensão teórica no âmbito do relatório. Para saber mais sobre esta
tecnologia consultar a página da .NET na microsoft – www.microsoft.com/net
O .NET é um componente do software Microsoft para conectar todo um
universo de informação, pessoas, sistemas e dispositivos. Este permite integração de
sofware através do use de servições XML Web: permitindo a conecção entre diferentes
aplicações, até via Internet.
Os produtos .NET que fazem a plataforma Microsoft, permite uma forma rápida
e eficiente de contruir, guardar, e utilizar de um modo segura e conectar a solução
usando serviços XML. Esta plataforma da Microsoft oferece uma gama de ferramentas,
aplicações cliente, serviços XML Web e os necessários servidos para conseguir obter
este universo conectado.
“.NET is Microsoft's platform for XML web services. XML web services allow
applications to communicate and share data over the Internet or an intranet, regardless
of operating system or programming language.”, esta é a definição da Microsoft sobre a
.NET. Permite-nos chegar, então, à conclusão que a plataforma .NET permite a partilha
de dados (Internet ou numa intranet), independemente do sistema operativo ou
linguagem que usarmos.
ISEP – DEI
97
IMDB – Sistema de Indexação
Anexos
Como já referido anteriormente, seria necessário consultar a página da Microsoft
para uma melhor compreensão do assunto; neste anexo apenas se transmite uma ideia
genérica.
ISEP – DEI
98