Universidade Federal da Paraíba
Centro de Ciências e Tecnologia
Coordenação de Pós-Graduação em Informática
SIT
Projeto e implementação de uma biblioteca
para recuperação textual
Adriano Sérgio Rodrigues de Souza
Campina Grande - PB
Dezembro, 1995
Adriano Sérgio Rodrigues de Souza
SIT
Projeto e implementação de uma biblioteca
para recuperação textual
Dissertação apresentada ao Curso de Mestrado
em Informática da Universidade Federal da
Paraíba, em cumprimento às exigências para
obtenção do Grau de Mestre.
Jacques Philippe Sauvé
(Orientador)
Campina Grande - PB
Dezembro, 1995
SIT- PRO JETO E IMPLEMENTAÇÃO DE UMA BIBLIOTECA PARA RECUPERAÇÃO TEXTUAL.
ADRIANO SÉRGIO RODRIGUES DE SOUZA
DISSERTAÇÃO APROVADA E M 20/12/95
W/ML
JACQUESf PHDJPPE, Ph.D.
Presidente
JOSE ANTÃO BELTRÃO MOURA, Ph.D. Componente da Banca
FRANCISCO VILAR BRASILEIRO, Ph.D. Componente da Banca
I
i
Agradecimentos
Dedico esta página para agradecer àquelas pessoas que contribuíram para a realização deste trabalho. A todas elas externo o meu mais profundo agradecimento e, especialmente:
- A minha esposa, Maryane, pela compreensão, apoio e amor que demonstrou nos momentos fáceis e difíceis deste trabalho e de nossa vida.
- A meus país pelo amor e pelos anos dedicados à minha educação. A meus irmãos pela amizade e pelo constante incentivo.
- Ao meu orientador, Jacques Philippe Sauvé, por ter compartilhado seu profundo conhecimento comigo, por ter confiado em mim para o desenvolvimento deste trabalho e pela pressão que fez durante a fase de conclusão deste trabalho.
- A Ana Lúcia Guimarães pela insistência e pelo incentivo constantes. - ALight-Infocon, que possibilitou a realização deste trabalho.
- Ao pessoal da GREEN SOFTWARE pela troca de conhecimentos e pela amizade. - A Marcos Sebastian e Alessandro Jatobá pela amizade e pela colaboração na fase de implementação do trabalho.
- A Dálmer Júnior e Fernanda Angélica pelos momentos de lazer que me proporcionaram e, principalmente, pela amizade.
- Ao refrigerante, a batatinha frita e até a cerveja que não tomei, mas compartilhei com a turma. Aos sanduíches e pizzas que saciaram a fome.
- Enfim, a Deus, por ter me proporcionado todos os momentos da minha vida e por ter permitido que eu chegasse até aqui.
Resumo
A grande quantidade de informações que as pessoas têm que gerenciar hoje em dia está tornando esse trabalho cada vez mais. difícil. A recuperação das informações de forma rápida e eficiente não é possível se não houver um sistema automatizado para essa tarefa.
Com base nessa necessidade de controle de dados, este trabalho descreve o projeto e a implementação de uma ferramenta para gerência de informações não estruturadas e recuperação textual.
Abstract
It is becoming more and more difEcult for people to manage large quantitíes of information. Information retrieval in a fast and efíicient way is not possibie without an automated system.
The need for higher data control motivated us to pursue this work, which descríbes the project and implementation of a tool for non structured information management and textual retrieval.
índice
Capítulo 1 - Introdução 2
1.1. Importância eobjetivos do trabalho 3 1.2. Descrição do Servidor de Informações Textuais , 4
1.3. Organização do trabalho 5
Capítulo 2 - Projeto de uma ferramenta para manipulação de
informações não estruturadas 6
2.1. Requisitos exigidos para um sistema de gerenciamento de informações não
estruturadas 7 2.1.1. Requisito Geral do Projeto 7
2.1.2. Abrangência 7 2.1.3. Indexação e armazenamento flexíveis 8
2.1.4. Ambientes: monousuário, multiusuário e cliente/servidor. 9
2.1.4.1. - Ambiente monousuário 9 2.1.4.2. -Ambientemultiusuário 12 2.1.4.3. -Ambientecliente/servidor 12
2.1.5. Portabilidade 14 2.1.5.1. -PlataformaOperacional 14
2.1.5.2. -Esquemas deIPC/redes variados 16 2.1.5.3. -Ferramentas de Desenvolvimento 17
2.1.6. Segurança 17 . 2.1.6.1.-Requisito Global do Projeto 17
2.1.6.2. - Gerenciamento de Usuários 17 2.1.6.3. - Flexibilidade na alocação de autorizações 18
2.1.6.4. - Não incluir esquema de "Deus global" 18
2.1.6.5. -Simplicidade de gerência 18 2.1.6.6. -Esquemapreparado para ambiente distribuído 19
2.1.6.7. -Mecanismo de proteção de bases 19 2.1.7. Robustez . 19
2.1.8. Desempenho 23 1 - Uso de threads 23
2 - Travamento de recursos 23 3 - Granularidade adequada para o fluxo de informações 24
4 - Uso de API assíncrona 24
2 - Suporte para o padrão de caracteres IS08859/1 26 3 - Possibilidade de suporte total para Unicode 26 4 - Suporte a vários formatos de data, hora e dados numéricos em
geral 26 2.1.10. FlexibiHdade/ortogonalidade 26
2.2.0 que será implementado neste trabalho 27
2.3. Definição geral do SIT v 30
2.3.1. Arquitetura Geral do SIT 31
2.3.2. Bases de Usuários 34 2.3.3. Sistema de Segurança do SIT 36
2.3.3.1. -Login 37 2.3.3.2. - Ticket 37 2.3.3.3. -Passwords 38 2.3.3.4. - Características de segurança de uma base de dados 39
2.3.3.5. -ACLs 41 2.3.4. Tipos de dados no SIT 44
2.3.5. Indexação, Consulta e Listas de Ocorrências 48
Capítulo 3 - Implementação do Servidor de Informações Textuais 52
3.1. Arquitetura em detalhes 53 3.2. Classes oferecidas pelo SIT 56
3.2.1. A classe C_Session 61 3.2.2. A classe CJBase 61 3.2.3. As classes C_Field, C_Data, C_Occurrence e ÇJTicket 62
3.3. O processo de Login 64 3.4. O processo de Criação de Bases 66
3.5. Restrição de uma Lista de Ocorrências a partir das ACLs 69
3.6. O Protocolo MMF 69 3.7. O Protocolo Client/Server 74
3.8. Reprocessamento de bases 75 3.9. Considerações sobre desempenho do SIT 77
Capítulo 4 - Detalhes de Implementação 80
4.1. Modularização ' 80
4.1.1. Os Stubs 81 4.1.2. Modularização Interna 82
4.4. Comunicação entre processos 91 4.4.1. Um pouco sobre MMF 92 4.4.2. Como o SIT utiliza o potencial MMF 93
4.5. Tratando compartilhamento de bases entre várias aplicações ;. 95
4.6. Robustez das bases 97 4.7. Reprocessamento de bases 100
4.8. Indexação, Consulta e Listas de Ocorrências 102
4.8.1. O processo de indexação 102 4.8.2. O processo de consulta 104
Capítulo 5 - Considerações Finais 106
5.1. Preenchimento dos requisitos 106
índice de Figuras
Figura 1 - Arquitetura Geral do SIT 31 Figura 2 - Arquitetura Geral do SIT para versão cliente/servidor 33
Figura 3 - Estrutura geral de uma ACL 43 Figura 4 - Arquitetura detalhada do SIT 54 Figura 5 - Organização hierárquica das classes do SIT 60
Figura 6 - Modularização do SIT 80 Figura 7 - Esquema de empacotamento de dados entre Stubs . 82
Figura 8 - Divisão funcional do SIT 83 Figura 9 - Hierarquia das classes de tratamento de arquivos 84
índice de Tabelas
Tabela I - Conjunto de permissões de ACL .. 42
Tabela H - Tipos de campo manipulados pelo SIT 45
Tabela UJ - índices usados pelo SIT 48 Tabela IV - Resultado dos testes realizados com o DESEMP 78
Glossário
A P I - Application Programming Interface - conjunto de funções e/ou classes de objetos disponibilizados para uso do programador.,
D?C - InterProcess Communicatíon. Determina um conjunto de técnicas utilizadas para implementação de comunicação entre dois ou mais processos.
KPC - Remote Procedure Cali - Esquema de comunicação entre processos que estão em máquinas diferentes, interligadas por uma rede.
D L L - Dynamic-Link Library - Biblioteca que se liga à aplicação dinamicamente. TERMO - Menor unidade de informação passível de ser armazenada em um índice
GRUPO - Entidade que contém os termos que uma aplicação deseja indexar. Também é chamado de campo neste trabalho e pode conter mais de um valor (neste caso, é chamado de multivalorado).
SUBGRUPO - Representa um dos possíveis valores de um grupo, para grupos multivalorados. Dessa forma, um grupo pode conter vários subgrupos. Um subgrupo também é chamado de repetição neste trabalho.
Capítulo 1 - Introdução
A tecnologia de armazenamento de dados tem evoluído bastante nos últimos anos. As pessoas sentem necessidade de guardar informações em formatos e tamanhos diversos e os computadores (software + hardware) têm se adaptado à essas necessidades. Uma das últimas tendências no mundo da informática é o uso de bancos de dados textuais. Esse tipo de software consegue armazenar grandes volumes de informações não estruturadas e indexá-las de tal forma a tornar possível a recuperação através de palavras, números, datas ou outros elementos de formação dos dados.
A necessidade de armazenar e recuperar grandes volumes de informação tem levado os sistemas de gerenciamento de bancos de dados a evoluções significativas. Questões como velocidade, precisão, controle de acesso e integridade das informações são cada vez mais enfocadas pelos softwares especializados.
Combinar todos os recursos desejados pelos usuários, porém, torna os sistemas de bancos de dados complexos e caros. A ideia deste trabalho é projetar e implementar um sistema de gerenciamento de bancos de dados textuais em forma de uma biblioteca, sem interface com o usuário final. O usuário desse sistema é o programador de aplicações, que implementará seu software de recuperação textual sem se preocupar com questões como segurança, performance, acesso aos dados, integridade das informações, etc. O trabalho desse programador será com a interface do software.
1.1 Importância e objetivos do trabalho
É indiscutível a importância de um sistema automatizado de armazenamento e recuperação de informações na vida das pessoas. Os sistemas gerenciadores de informações estruturadas, assim como os de informações não estruturadas, estão cada vez mais presentes no nosso dia-a-dia, cada um cumprindo o seu papel.
Os gerenciadores de informações estruturadas são úteis para o cadastro de funcionários de uma empresa ou outros processos operacionais semelhantes, mas não conseguem a mesma eficiência no controle de documentos não estruturados, por exemplo. Para cada tipo e formato de informação, o usuário tem que determinar uma estrutura de dados para que os sistemas tradicionais trabalhem com eficiência.
Dessa forma, os sistemas de gerenciamento de informações não estruturadas ganham destaque, pois conseguem manipular informações nos mais variados formatos e tipos sem perda de performance ou eficiência.
O presente trabalho consiste no projeto e implementação de uma biblioteca de gerenciamento de informações textuais, que será chamada de SIT - Servidor de Informações Textuais - e poderá ser usada por programadores que desejam elaborar aplicações para manipulação de informações não estruturadas.
1.2 Descrição do Servidor de Informações Textuais
A ferramenta projetada neste trabalho engloba uma série de mecanismos para manipulação de informações com segurança, objetividade e consistência. Trata-se de uma biblioteca de apoio, sobre a qual serão construídas aplicações finais, responsáveis pela interaçâo entre o usuário e as informações.
Com essa ferramenta, o programador terá que se preocupar apenas com a interface de suas aplicações. Todo o trabalho de criação e manipulação de bases de dados é feito pelo SIT, assim como os esquemas de segurança dos dados, integridade, alocação de permissões e cadastramento de usuários.
Um conjunto de requisitos foi cuidadosamente estudado e proposto para o projeto do SIT. Esses requisitos determinam o que o sistema deve e o que não deve implementar para oferecer garantia de uma boa funcionalidade. A implementação, contudo, obedece apenas a um subconjunto dos requisitos, mas deixa o código pronto para que trabalhos futuros possam complementar o atendimento aos requisitos.
Neste trabalho, o SIT implementará as seguintes características:
• suporte a vários tipos de dados • linguagem de recuperação textual
• gerenciamento de usuários com controle de autenticação • alocação de autorizações de forma flexível
• simplicidade de gerência de usuários e de dados • mecanismos de proteção de dados
• recuperação de dados em casos de falha
Cada uma dessas características será analisada nos próximos capítulos deste trabalho.
1.3 Organização do trabalho
Este trabalho está organizado em 5 capítulos. O primeiro faz um levantamento rápido das necessidades de se ter um sistema de recuperação textual e descreve, também de forma resumida, a importância do SIT e o que foi projetado e implementado neste trabalho. No segundo capítulo, encontram-se relacionados todos os requisitos propostos para o sistema, os requisitos que serão atendidos neste trabalho e uma descrição geral do SIT. O terceiro capítulo descreve a implementação do sistema, destacando sua arquitetura e seus objetos. No quarto capítulo encontram-se descritos os detalhes mais importantes da implementação, como a modularização interna e o sistema de tratamento de arquivos. O quinto e último capítulo é dedicado às considerações finais sobre o trabalho e propostas de trabalhos futuros. No final do trabalho, existe um apêndice contendo as classes mais importantes da API do sistema.
Capítulo 2 - Projeto de uma ferramenta para manipulação de
informações não estruturadas
Os Sistemas Gerenciadores de Banco de Dados (SGBD) são ferramentas concebidas para armazenamento e recuperação de informações em geral. Entretanto esses sistemas trabalham com informações estruturadas, segundo algum modelo de organização de dados.
Há uma necessidade de.gerência sobre documentos, de forma que sejam fáceis o armazenamento e a recuperação de relatórios, artigos, livros e textos em geral. Essa carência motivou o projeto de uma ferramenta capaz de trabalhar de maneira eficaz com informações não estruturadas, como textos por exemplo.
A ferramenta projetada é uma biblioteca que disponibiliza uma API1 para construção
e gerência de Bases de Dados Textuais (BDT). Essa biblioteca, chamada de Servidor de Informações Textuais (SIT), tem como usuário alvo o programador de aplicações finais. Esse usuário cria aplicativos que manipulem BDTs, sem se preocupar com esquemas de
segurança, indexação, armazenamento e outros detalhes de programação. Os aplicativos, também chamados de aplicações clientes, são construídos sobre o SIT.
O SIT não é simplesmente um sistema de armazenamento/recuperação de textos. Ele atende a uma série de requisitos impostos a um bom sistema de gerência de informações. Esses requisitos serão analisados na próxima seção. A seção 2.2 apresenta uma relação dos requisitos que serão atendidos neste trabalho e na seção 2.3, será
1 Application Programming Interface - conjunto de funções e/ou classes de objetos disponibilizados
apresentada a arquitetura geral "do SIT, proposta para atender as exigências expostas na seção 2.2.
2.1 Requisitos exigidos para um sistema de gerenciamento de informações não estruturadas
Esta seção descreve, um a um, todos os requisitos considerados fundamentais para um sistema de gerenciamento de informações não estruturadas.
2.1.1 Requisito Geral do Projeto
0 primeiro e mais importante requisito a ser imposto é que flexibilidade não deve implicar em complexidade. Se for desejado algo simples, então deve ser simples de resolver, quando se desejar algo mais complexo, o sistema pode exigir mais do usuário.
2.1.2 Abrangência
O sistema deve suportar consultas a dados textuais através de uma linguagem de recuperação. Deve ser possível recuperar informações através de
strings, substrings, valores numéricos e datas, além de outros recursos que a
A biblioteca deve oferecer suporte a vários tipos de dados, como datas e números, além de texto, mas deve ser voltada principalmente para a gerência de informações textuais. O foco maior será o armazenamento e, sobretudo, a recuperação de informações desse tipo. Portanto, sempre que houver um impasse de decisão, a parte textual será favorecida.
A necessidade de se tratar tipos de dados como números e datas aparece no momento de uma consulta que não pode ser satisfeita com tratamento apenas sobre o tipo texto. São consultas que envolvem intervalos entre datas, valores resultantes de cálculos, etc.
A linguagem de recuperação textual a ser oferecida deve disponibilizar recursos como formação de palavras através de metacaracteres, busca fonética de palavras e busca por aproximação, entre outros. A especificação completa da linguagem de recuperação textual pode ser obtida era [BUSSMANN95], que trata de uma biblioteca especializada em indexação e recuperação de informações não estruturadas.
2.1.3 Indexação e armazenamento flexíveis
Já que a biblioteca suporta mais de um tipo de dado, os sistemas de armazenamento e indexação devem sem flexíveis. Isso significa que esses sistemas
não devem ser "amarrados'' a um só tipo de dado. Durante o processamento, os tipos de dados devem ser selecionados automaticamente.
Dessa forma, durante a indexação de um texto, por exemplo, o SIT deve reconhecer números e datas e indexá-los de maneira que torne possível a recuperação por intervalos.
2.1.4 O servidor proposto funcionará em três tipos diferentes de ambiente: monousuário, multiusuário e cliente/servidor.
Cada um desses ambientes e seus requisitos é descrito a seguir.
2.1.4.1 - Ambiente monousuário
Nesse tipo de ambiente não é necessário implementar nenhum tipo de controle de concorrência, pois não há múltiplos acessos simultâneos aos dados. Esta versão do SIT trabalha apenas com um cliente (aplicação cliente), o que garante unicidade no acesso às informações.
A interação entre o servidor (SIT) e o cliente (aplicação) pode ser implementada de pelo menos três formas diferentes:
• O servidor pode ser uma biblioteca de ligação estática com a aplicação
Essa é a forma mais simples de se implementar uma biblioteca. Trata-se de um conjunto de funções e/ou objetos já compilados e agrupados em um arquivo que possuí a terminação LIB. Esse arquivo é usado por uma aplicação que deseja utilizar aquelas fiinções/objetos que lá estão. O código da LIB é então ligado ao da aplicação, de forma que é gerado um único arquivo executável, contendo os dois conjuntos de código.
Esse tipo de biblioteca é aceitável na maioria dos ambientes operacionais (UNIX, Windows, DOS, etc), mas possuí a desvantagem de ter seu código agregado ao código de cada aplicação que a utiliza. Isso significa que as aplicações têm seus executáveis grandes (seu próprio código + código da biblioteca) e que o sistema operacional não vai reutilizar o código da biblioteca, o que implica em aumento no consumo de memória. Outro fator negativo no uso desse tipo de biblioteca é que, quando se faz uma alteração no seu código, todas as aplicações que a utilizam devera ser regeradas (religadas).
• O servidor pode ser uma biblioteca de ligação dinâmica com a aplicação
Essa forma de biblioteca é mais interessante do que a anterior. Conhecidas como DLLs (Dynamic-Link Líbraries), elas também são conjuntos de funções e/ou objetos compilados e agrupados em um arquivo (que possui terminação DLL).
DLLs são formas de bibliotecas muito utilizadas no ambiente Windows. Elas reduzem o tamanho das aplicações, pois não há a necessidade de agregação dos dois códigos, como no caso das LIBs. Quando uma aplicação é executada, o sistema operacional invoca, automaticamente, as DLL necessárias ao seu funcionamento. Para outras aplicações que utilizam a biblioteca, o sistema operacional não executa uma cópia do seu código, mas o reutiliza. Somente quando a última aplicação usuária de uma DLL finaliza sua execução é que o sistema operacional descarta a biblioteca. Tal ligação dinâmica tem pelo menos duas enormes vantagens em relação à implementação de bibliotecas estáticas: primeiro, o ganho de memória, pois não há uma cópia da biblioteca em memória para cada aplicação; segundo (essa, do ponto de vista de um programador), quando a biblioteca sofrer alteração em seu código, não há a necessidade de se recompilar todas as aplicações que a utilizam, pois a ligação é dinâmica.
• o servidor pode ser um executável e se integrar com o cliente através de um mecanismo qualquer de IPC2 [STEVENS90].
Neste caso, o servidor seria uma aplicação e não uma biblioteca. A comunicação entre o servidor e o(s) cliente(s) seria através de algo do tipo memória compartilhada ou algum protocolo de rede.
2.1.4.2- Ambiente multiusuário
A implementação de um ambiente deste tipo é bem mais trabalhosa do que a implementação do ambiente visto no item anterior. A ideia básica é que haja múltiplos servidores e clientes em máquinas diferentes com a possibilidade de acessar, ao mesmo tempo, as mesmas bases de dados.
Essas bases podem até estar em uma máquina da rede que nem possui servidor ou cliente, mas funciona como um servidor de arquivos (Netware, por exemplo). É certo que isso também pode acontecer em ambientes monousuário. O problema aqui é que vários servidores podem estar acessando as mesmas bases simultaneamente; no ambiente monousuário, apenas um servidor vai estar acessando as bases.
A grande preocupação para o ambiente multiusuário é o controle de concorrência. Os múltiplos acessos simultâneos aos mesmos arquivos podem gerar inconsistências no conteúdo das bases de dados.
O sistema proposto deve ser capaz de gerenciar o acesso simultâneo aos dados e permitir o uso de sistema de arquivos distribuído.
Essa arquitetura deixa mais fortes os conceitos de servidor e cliente. O SIT deve ser, para este caso, uma aplicação executável, capaz de gerenciar por si só todas as bases de dados da máquina onde estiver rodando. Os clientes podem estar na mesma máquina ou em outras espalhadas pela rede. A comunicação entre os processos deve ser implementada através de algum protocolo de rede já conhecido.
As maiores preocupações para esse ambiente são:
• minimização de tráfego: o protocolo de comunicação entre os processos deve
prever o mínimo de tráfego possível na rede. O fluxo muito alto de informações é indesejável, pois degrada o rendimento de toda a rede e pode inviabilizar o uso de redes a longa distância, cujas velocidades são menores que as de redes locais.
• minimização de estado: na arquitetura cliente/servidor o problema de robustez
dos processos se torna mais crítico do que em outras. Nesta arquitetura, o processo deve se preocupar com a sua recuperação em caso de falha e ainda dar condições para que outros se recuperem de maneira eficiente. Muitas vezes, o processo de recuperação de falhas é feito com base em estados que são guardados pelos processos, mas isso traz implicações indesejáveis, que serão discutidas no tópico que trata de robustez, mais adiante.
• maximizar desempenho com API assíncrona: nessa arquitetura é possível
implementar, no servidor, atendimentos assíncronos3 [STEVENS90] aos
pedidos vindos dos clientes. Dessa forma os clientes podem ser mais eficientes, fazendo o pedido ao servidor e já liberando o usuário para outra tarefa, mesmo que o servidor ainda não tenha terminado de atender o pedido (veja mais detalhes sobre API assíncrona no tópico que trata de desempenho, mais adiante).
2.1.5 O SIT deve ser um sistema portável
O sistema proposto deve ser implementado de forma a minimizar todas as dependências que venham a surgir. Essas dependências podem ser de hardware, de compilador, sistema operacional, etc.
A seguir, estão enumerados alguns dos pontos de dependência que merecem considerações:
2.1.5.1 - Plataforma Operacional
A plataforma operacional deve ser escolhida de forma a atender as seguintes exigências:
• proteção de memória: cada processo deve ser executado em seu próprio espaço
de endereçamento, sem interferir no funcionamento dos outros.
implementadas para que o servidor retome a conversa com o cliente após um atendimento assíncrono.
• memória virtual: os processos podem enxergar uma quantidade de memória
maior do que a existente "fisicamente" na máquina, sem preocupação com o esquema de swap de dados entre a memória física e o disco.
• esquema flexível de alocação de memória: o processo não tem que se
preocupar com segmentação de memória, limite de segmentos, etc.
• disponibilização de threads: para a implementação de atendimento assíncrono e
para implementar a versão cliente/servidor, o processo deve poder contar com o suporte a threads4 [SANTOS93J, a partir do sistema operacional. Veja mais
detalhes sobre esse recurso no tópico que trata de desempenho, mas adiante.
• mecanismo eficaz de IPC: o sistema operacional deve disponibilizar recursos
para a comunicação entre processos, como memória compartilhada por exemplo.
• serviços diversos: como se trata de um gerencíador de banco de dados, serão
necessários recursos como travamento de arquivos, compartilhamento de memória, timers, e outros.
Apesar das exigências feitas acima, o SIT não impõe algumas coisas, como um processador de altíssimo desempenho, suporte para um grande número de arquivos abertos, interface gráfica, etc.
As possíveis plataformas para a implementação do SIT são: • Windows-95
• Windows-NT • Unix
• Netware (esta é uma plataforma possível, mas não enfocada neste trabalho)
Os ambientes Windows 3.1 e Windows 3.11 foram descartados por não atenderem a todos os requisitos citados acima. Eles não oferecem recursos como
proteção de memória, esquema flexível de alocação de memória e threads.
2.1.5.2- Esquemas de IPC/redes variados
Para minimizar dependências, o SIT deve ser implementado sobre uma camada de isolamento que permita usar qualquer protocolo de comunicação, como TCP/IP, NETBEUI, OSL etc.
Para tanto, torna-se necessário programar no mais alto nível possível. Um esquema do tipo RPC deve ser usado, mantendo portabilidade.
Nas versões monousuário e multiusuário do SIT, pode ser usado um mecanismo de IPC mais rápido do que RPC, por exemplo, pois não há a necessidade de comunicação via rede. Uma opção é o uso de memória compartilhada.
2.1.5.3- Ferramentas de Desenvolvimento
Aqui entra em questão a dependência de ambientes de desenvolvimento. Existem várias ferramentas, cada uma oferecendo recursos diferentes das outras. O grande problema de se usar esses recursos avançados é que o código fica "amarrado" à ferramenta, impossibilitando o transporte para outros ambientes.
As opções de ferramentas para o desenvolvimento do SIT para ambiente Windows são: Borland C++, Microsoft Visual C++ e Watcom C/C-H-, que são as mais conhecidas. Para o ambiente Unix não serão citadas ferramentas, pois neste trabalho o SIT será implementado em ambiente Windows (NT e 95)
2.1.6 Segurança
Este é, sem dúvida, um aspecto de grande importância para qualquer sistema de banco de dados.
O subsistema de segurança do SIT deve observar aos seguintes requisitos:
2.1.6.1- Requisito Global do Projeto
• O primeiro requisito a ser imposto aqui é o requisito global do projeto, citado no inicio da seção 2.1.
• O sistema deve cadastrar e gerenciar os usuários que terão acessos às bases de dados. Com isso, o SIT será capaz de administrar as permissões de acesso que cada usuário possui sobre as bases.
2.1.6.3- Flexibilidade na alocação de autorizações
• Alocar autorizações para usuários deve ser uma tarefa flexível. O sistema não deve exigir que o usuário configure níveis de permissão ou coisa parecida. Por outro lado, se for necessário definir um conjunto de regras de acesso aos dados ou delegar poderes para usuários, isso deve ser permitido.
2.1.6.4- Não incluir esquema de "Deus global"
• O SIT deverá adotar uma maneira segura de definir permissões para os usuários. Não deve ser permitido, por exemplo, que cada um defina o que pode e o que hão pode fazer com as bases de dados. Por outro lado, não é desejável a presença de um super-usuário, que tenha poderes sobre todos os outros. Isso é ruim, pois tudo e todos passam a depender de um único usuário, que pode cadastrar outros, removê-los, delegar poderes, alterar senhas, etc. Além do mais, a noção de super-usuário acaba se tornando um ponto fraco no sistema para possíveis intrusos. O sistema deve implementar um meio termo, onde as permissões sejam gerenciáveis de maneira segura, mas não deixe os recursos concentrados nas mãos de um único usuário.
• A gerência de lodos os itens de segurança deve ser feita de maneira simples. O SIT deve possuir esquemas internos de gerência para os casos em que o usuário não esteja interessado em administrar segurança.
2.1.6.6- Esquema preparado para ambiente distribuído
• Todo o esquema de segurança do SIT deve estar preparado para ambiente distribuído, onde as possibilidades de furos são maiores. O sistema deve se preocupar com problemas de ataque de segurança em rede.
2.1.6.7- Mecanismo de proteção de bases
• A última exigência feita em termos de segurança é que o SIT implemente mecanismos de proteção para as bases de dados, para evitar que elas sejam transportadas e usadas em outros ambientes, sem administração adequada. O sistema deve possuir meios de evitar a cópia das bases de dados.
1.7 Robustez
Um dos maiores problemas encontrados pelos programadores é a implementação de recuperação de erros. As vezes não é possível nem sequer determinar em que situações eles podem acontecer, principalmente quando falamos de sistemas distribuídos. O fato é que eles ocorrem e é necessário que o software seja robusto o suficiente para se recuperar.
O Servidor de Informações Textuais deverá oferecer mecanismos de recuperação ou reconstrução de bases e índices que, por algum motivo, tenham ficado inconsistentes.
Ê natural que haja algum tipo de falha no sistema, independentemente de sua arquitetura. Em ambientes monousuário, há o risco de queda de energia ou de pane no sistema operacional ou até no hardware. Isso pode acarretar destruição parcial dos arquivos abertos, danificação do sistema de índices de uma base, etc. Portanto, o SIT deve se precaver contra essas possibilidades e prover um esquema
de autorecuperação.
Para os sistemas distribuídos os riscos são bem maiores. Além das mesmas situações descritas acima, esses sistemas podem sofrer "falhas parciais" [SANTOS93], que são provocadas pela queda de um ou mais módulos envolvidos (clientes ou servidores).
Alguns sistemas guardam estado para implementar a recuperação de falhas parciais. A existência de estado implica no consumo de recursos do sistema e em
overhead para as aplicações. O processo que trabalha seguindo esse esquema deve
estar sempre atualizando informações de estado em um meio de armazenamento não volátil (disco, por exemplo) a fim de poder se recuperar após uma queda. A recuperação implica em ler o estado e atualizar as estruturas internas, para que o processo se comporte como estava antes da queda.
Guardar estado requer cuidados, principalmente durante sua atualização. Se o processo cair durante a gravação das informações de estado, elas podem ficar danificadas e impedir a correta "retomada" da aplicação após a queda. A sincronização de imagem das estruturas de memória com as do disco requer velocidade e certeza de que elas vão estar realmente em disco, aos invés de estar nos buffers do sistema operacional. Isso implica em forçar gravações não buferizadas, o que degrada ainda mais a performance do sistema.
Existem alternativas para a implementação de recuperação de falha que não necessitam de manutenção de estado em meio não volátil [SANTOS93]. Uma delas é, no processo de recuperação, perguntar ao outro lado (o cliente pergunta ao servidor e vice-versa) todas as informações necessárias para a reconstrução das estruturas internas. Neste caso, existe a vantagem de não ser necessária a atualização constante em disco das informações de estado. Essas informações são naturalmente transmitidas pela rede e um lado (cliente ou servidor) é capaz de fornecer informações necessárias para a recuperação do outro. Uma das desvantagens, no entanto, é que normalmente é necessário o uso de broadcost para que um processo identifique os outros na rede. Isso limita os processos a trabalharem apenas em redes locais, pois o broadcost só é aplicável nesse tipo de ambiente.
O ideal seria que o processo não precisasse manter estado, o que significa que, para se recuperar de uma queda, bastaria entrar no ar novamente e tudo se procederia como se nada tivesse acontecido. Mais informações sobre o uso de estado em ambientes distribuídos podem ser encontradas em [SANTOS93] e em [ALSINA94].
Infelizmente, não se pode determinar tão facilmente que um servidor de banco de dados simplesmente não guarde estado. Tudo dependerá das necessidades na implementação. O requisito é: minimizar o uso de estado.
Toda essa discussão sobre o uso ou não uso de estado tem um objetivo: a recuperação de queda no sistema, seja por parte do servidor ou do cliente. Ambos os módulos podem tomar diversas atitudes para a ressincronização, dependendo das informações que são guardadas como estado.
Na ocorrência de uma falha, o sistema deve prever recuperação automática sempre que for possível. O usuário só deve interferir em casos extremos.
Os erros fatais devem ser mininúzados, mas se acontecerem, o sistema deve elaborar um relatório da situação a fim de ajudar na recuperação.
2.1.8 Desempenho
Além de tudo o que já foi mencionado anteriormente, o SIT deve atentar para a questão de desempenho. O sistema deve utilizar todos os recursos disponíveis no ambiente operacional, mas sem afetar os requisitos citados acima, como portabilidade, segurança, etc. Abaixo estão descritas as alternativas consideradas para aumentar o desempenho do SIT.
1 - Uma das alternativas para melhorar desempenho de sistemas desse tipo é o uso de threads. Um thread representa o agente de controle de uma sequência de instruções sendo executadas por um programa. Um processo que possui arquitetura multi-thread. é composto por um ou mais threads que são executados em paralelo, compartilhando o mesmo espaço de memória [SANTOS93],
2 - Ainda em relação a sistemas distribuídos, existe o problema de travamento de recursos como arquivos e memória compartilhada. Dado que mais de um processo pode estar querendo atualizar os mesmos arquivos/regiões de memória ao mesmo tempo, faz-se necessário implementar um esquema de região crítica para evitar inconsistências. O processo (ou thread) que desejar atualizar uma informação em um desses recursos deve realizar um travamento (através de primitivas do sistema operacional), depois fazer a atualização e só então liberar o recurso. Isso garante a integridade das informações. A
granularidade do travamento deve ser escolhida de forma a maximizar o desempenho.
3 - No que se refere à transferência de informações pela rede, o SIT deve se preocupar em transferir sempre o mínimo possível. Isso significa que deve ser definida uma granularidade adequada para que o fluxo de informações não seja grande.
Para as versões do SIT que não são cliente-servidor, pode-se implementar um mecanismo de IPC mais rápido do que o usado para comunicação pela rede. Nessas versões só existe comunicação entre os módulos que estão na mesma máquina, dispensando mecanismos de rede.
4 - 0 último requisito sobre desempenho para o SIT, é que seja utilizada, sempre que desejável, uma API assíncrona, a fim de liberar o cliente para outras atividades. Isso significa que o sistema deve fornecer meios de atender a um pedido do cliente e imediatamente o liberar para outras coisas, enquanto tenta atendê-lo. Isso é prático, mas traz algumas dificuldades na implementação da aplicação cliente. A maior delas é o tratamento do final de processamento do servidor: quando e como o cliente descobre que o servidor terminou de tratar o pedido que foi feito há um tempo atrás? Outro ponto importante é a obtenção de status: será que houve erro? Qual?
Tanto o servidor quanto o cliente têm que implementar mecanismos dè sincronização para detectar término de processamento do servidor. Uma alternativa é o servidor devolver uma espécie de handle para o cliente quando este último fizer uma chamada assíncrona. Periodicamente, o cliente pergunta ao servidor se o pedido identificado pelo handle já terminou e obtém o status da operação no final para verificar se houve erro.
Outra alternativa é o uso de funções callback pelo cliente. Isso permite que o cliente indique uma função sua que deve ser chamada pelo servidor quando este terminar de tratar um determinado pedido.
Devido ao aumento de complexidade inerente era operações assíncronas, tanto para o cliente como para o servidor, é recomendado que a API assíncrona não seja implementada em todos os pontos do SIT, até porque isso não é necessário. Basta implementá-las em pontos onde o uso da assincronía seja mais útil, como na gravação/indexação de um registro, por exemplo.
Os casos considerados úteis são basicamente aqueles em que o servidor precisa de tempo para a execução e o cliente não precisa ficar esperando. Quando a operação é rápida no servidor, não é necessário implementá-la de forma assíncrona; mas as operações lentas prendem o cliente, enquanto ele poderia estar fazendo outras coisas, como edição, impressão, etc.
2.1.9 Internacionalização
Para que o SIT possa ser utilizado em qualquer linguagem, é necessário que ele esteja acompanhado de um bom esquema de internacionalização.
Os requisitos básicos para este tópico são:
1 - Suportar conjuntos de caracteres internacionais
2 - Suporte (na versão definida por este trabalho) apenas para o padrão de caracteres IS03859/1, dando suporte efetivo para todas as línguas da Europa Ocidental
3 - Tornar possível (e fácil) o suporte total para Unicode. Com este conjunto de caracteres, as linguagens orientais, arábicas, etc. seriam também suportadas. 4 - Suportar vários formatos de data, hora e dados numéricos em geral (questões
de ponto decimal, vírgula, moeda, etc).
2.1.10 Fleiibilidade/ortogonalidade
Este é o último conjunto de exigências feitas para a implementação do SIT. Aliás, é um conjunto de um único requisito: "não re-inventar a roda". Isso significa que o sistema proposto deverá reutilizar suas estruturas sempre que for possível. Eis um exemplo onde este requisito seria aplicável: no tópico sobre segurança foi citada a necessidade de se cadastrar os usuários que terão acesso às bases gerenciadas pelo SIT. Esse cadastro de usuários deve ser implementado utilizando
todos os recursos de segurança e facilidades de uso disponíveis no próprio sistema, desde que a portabilidade da ferramenta não seja comprometida. Então, por que não implementá-lo como uma base dft dados? Fazendo assim, todo o esquema de segurança, robustez, portabilidade, gerência, etc. é automaticamente aproveitado. Outros tipos de informações de controle/administração que se fizerem necessários ao longo da implementação também devem seguir estes passos. Assim, o sistema se torna mais flexível e menos complexo.
2.2 O que será implementado neste trabalho
Os requisitos citados acima deverão ser aplicados ao sistema proposto. Porém, neste trabalho, apenas um subconjunto do SIT será realmente implementado, ficando o restante para trabalhos futuros.
A relação abaixo apresenta os itens que serão implementados agora: • abrangência
• todos os tipos de dados propostos • resolução de impasse de decisão • linguagem para recuperação textual • indexação e armazenamento flexíveis • servidor apenas para a versão monousuário
• sem controle de concorrência
• ligação com a aplicação cliente através de DLL ou algum mecanismo de IPC (decisão a cargo da implementação)
• portabilidade
• implementação será feita em um sistema operacional que disponibilize: • proteção de memória
• memória virtual
• esquema flexível de alocação de memória • mecanismo eficaz de IPC
• esquema de travamento
• o sistema escolhido foi o Windows-NT, por apresentar as características acima e por estar disponível para a implementação
• ferramenta de desenvolvimento
• a ferramenta escolhida foi o Visual C++ 2.0, da Microsoft • segurança
• flexibilidade não deve implicar em complexidade
• gerenciamento de usuários com controle de autenticação • flexibilidade na alocação de autorizações
• não inclui esquema de super-usuário, que pode mandar em tudo • simplicidade de gerência
-• mecanismos de proteção de bases • robustez
• implementar reconstrução de bases e de índices • desempenho
• granularidade adequada para o travamento de recursos
• internacionalização
• nenhum suporte embutido para línguas não Europeias • suporte apenas para o padrão IS08859/1
• flexibilidade/ortogonalidade • cadastro de usuários é uma base
• dados de administração/estatísticas também é uma base
Para trabalhos futuros, os seguintes requisitos devem ser atendidos: • servidor para a versão multiusuário
• implementar controle de concorrência
• permitir uso de um sistema de arquivos distribuído • servidor para a versão cliente/servidor
• minimização de tráfego • minimização de estado
• maximização de desempenho com API assíncrona • portabilidade
• implementação em um sistema operacional que disponibilize threads • implementar esquemas de IPC/redes variados
• camada de isolamento para usar qualquer protocolo • programação em mais alto nível possível
• para as versões monousuário e multiusuário: usar IPC mais rápido que uma camada de rede (ex.: memória compartilhada)
• tecer considerações sobre falhas em ambiente distribuído • mmimizar manutenção de estado
• implementar procedimentos de ressincronização após volta de um cliente ou servidor • implementar sincronização de imagem em disco (fazer flush de estruturas mantidas em
memória)
• implementação de recuperação de falhas • minimizar erros fatais
• no caso de ocorrência de erros fatais, emitir relatório da situação para ajudar • desempenho
• usar threads
• manter granularidade pequena nas transferências de dados entre cliente e servidor • usar IPC mais rápido em versões não cliente/servidor
• implementar API assíncrona para liberar o cliente • internacionalização
• utilizar conjunto de caracteres internacional • implementar suporte total para Unicode
2.3 Definição geral do S U
Esta seção apresenta a arquitetura geral do SIT e tópicos relacionados com esquemas de segurança, tipos de dados e indexação.
2.3.1 Arquitetura Geral do SIT
Para aversão monousuário (ver tópico 3.1.4), o SIT possui uma arquitetura simples, como ilustrada na figura I .
Servidor de Informações Textuais
Sistema de
Segurança
Sistema de Indexação
e Consultas
Bases de dados
Cadastro de
Usuários
Figura 1 -Arquitetura Geral do SIT
As aplicações Apl, Ap2, ... Âpn se comunicam com o SIT, que gerência todos os acessos às bases de dados, juntamente com o sistema de indexação e consultas. £ importante observar que esse sistema de indexação e consultas não é alvo desta dissertação. O SIT apenas o utiliza como base para o tratamento dos índices.
O cadastro de usuários é um conjunto de informações sobre as pessoas que utilizam o sistema. Essas informações são gerenciadas pelo próprio SIT, sem a necessidade de
intervenção de algum processo externo. Esse cadastro está implementado como um conjunto de bases de dados comuns para que o SIT possa reaproveitar todo o seu esquema de segurança, robustez, indexação e acesso aos dados. Isso atende ao requisito citado na seção 2.1.10. Mais detalhes sobre o cadastro de usuários podem ser obtidos mais adiante, na seção sobre Bases de Usuários (tópico 2.3.2).
O sistema de segurança do SIT é responsável pelo processo de login de usuários no ambiente e pelo esquema de controle de acesso aos dados, que incluem ACLs5, senhas e
tickets* de acesso. A seção 2.3.3, mais adiante, trata do sistema de segurança.
Para a versão multiusuário do SIT, a arquitetura básica pode ser igual à descrita acima, mas para a versão cliente/servidor, ela sofrerá algumas alterações, como ilustra a figura 2. Essas duas versões não são alvos desta dissertação.
ACL - Access Control List - Lista de Controle de Acessos: São estruturas de dados que determinam acessos de usuários a um conjunto de informações.
Apl
Ap2
STUB CLIENTE RPC
STUB SERVIDOR RPC
Servidor de Informações Textuais
Sistema de
Segurança
Sistema de Indexação
e Consultas
Bases de dados
Cadastro de
Usuários
Figura 2 -Arquitetura Geral do SIT para versão cliente/servidor
A diferença básica entre as duas arquiteturas está na implantação dos stubs de rede. Esses stubs são camadas de software responsáveis pela comunicação na rede. O stub cliente
se encarrega de dar transparência para as aplicações, para que elas continuem trabalhando como se estivessem conversando diretamente com o SIT. O stub servidor recebe pedidos vindos do cliente e se comporta como se fosse uma aplicação para o SIT. Para a versão cliente/servidor, nem as aplicações nem o SIT devem sofrer alterações em seus códigos. A simples presença dos stubs deve resolver tudo.
2.3.2 Bases de Usuários
Uma base de usuários (também chamada de UDB - User DataBase) é uma base de dados comum, onde o sistema armazena informações sobre as pessoas para controle de segurança. As duas únicas particularidades de uma UDB em relação aos outros tipos de base são:
• o SIT gerência e manipula a UDB sozinho, sem interferência de um processo ou usuário;
• nenhum usuário consegue acessar diretamente as informações contidas em uma UDB. Isto é, não é possível abrir uma UDB e manipular seus registros, como se faz em uma base de dados comum.
As informações de uma UDB, apresentadas abaixo, são mantidas pelo sistema para controlar os acessos às bases de dados. Cada uma dessas informações é representada por um campo na base.
• Nome do usuário • Senha
• Descrição do usuário (nome completo, ou alguma informação adicional) • Tipo do usuário (administrador ou normal)
• Lista de grupos aos quais o usuário pertence
• Data da última atualização
• Lista das bases de dados às quais o usuário possui algum tipo de acesso • Tipo das bases de dados do campo anterior
A API do sistema oferece funções para a manipulação das informações de uma UDB de forma segura. Porém, essa API só permite acesso de leitura aos dados da base. Todas as alterações feitas em uma UDB são comandadas pelo próprio sistema (por exemplo, quando um usuário é cadastrado, um novo registro é criado na UDB).
Quando um usuário realiza a instalação do SIT em sua máquina, ele participa do processo de criação da primeira base de usuários, chamada de defauli1. Essa UDB conterá
nesse instante apenas um usuário, chamado de GERENTE. A senha para esse usuário é dada pela pessoa que está fazendo a instalação do sistema.
Dessa forma, apenas o GERENTE pode fazer login no sistema, pois apenas ele está cadastrado. Para que outro usuário possa acessar o sistema, o GERENTE deverá cadastrá-lo na base de usuários default.
Uma vez que um usuário está cadastrado na UDB default, ele poderá fazer login e criar bases de dados para ele. Todas as bases de dados criadas serão ligadas pelo SIT à UDB na qual o seu criador foz'login. Isto é, quando um usuário tenta criar uma base de dados, o sistema a associa à base de usuários na qual esse usuário fez login. Portanto,
apesar de o usuário ser dono de sua base, ele ainda não possui segurança total, pois o GERENTE tem poderes especiais e poderá acessar qualquer base que tenha sido "amarradan à base de usuários default.
Para eliminar esse inconveniente, é permitido que o usuário crie sua própria base de usuários, onde ele é o dono e, portanto, o gerente. Dessa forma, o usuário poderá fazer
login na sua UDB e todas as bases de dados que forem criadas serão amarradas a essa base
de usuários. Como o usuário em questão é o dono da UDB e o dono das bases que criou, ele possui segurança e acesso total sobre essas bases. E como ele é o dono da base de usuários, ele pode cadastrar quem ele desejar e com isso dar permissão de acesso às bases de dados.
Essa solução atende ao requisito citado na seção 2.1.6, item 4.
2.3.3 Sistema de Segurança do SIT
O SIT é uma ferramenta que propicia um nível de segurança rnínimo para quem não quer ter trabalho com esse aspecto. Mas aquele usuário que quer um padrão mais alto de segurança também pode usar esse sistema. Esta seção descreve os elementos básicos que compõem o esquema de segurança do SIT:
• Login • Ticket
• Características de segurança de uma base de dados • Passwords
• ACLs
2.3.3.1- Login
Para ter acesso ao sistema de bases de dados que o SIT gerência, o usuário deve passar por uma fase de identificação chamada de login. O esquema de login é bastante simples para o usuário, embora apresente uma certa complexidade interna, requerida para implementar o esquema de segurança.
Para passar pelo processo de login, o usuário precisa informar seu nome, sua senha pessoal e uma base de usuários onde ele está cadastrado. O SIT verifica os dados do usuário na UDB indicada e retorna para o usuário um ticket de acesso caso a operação obtenha sucesso.
2.3.3.2- Ticket
Um ticket é um objeto que é criado pelo sistema quando um processo de login é bem sucedido. Esse objeto contém informações criptografadas sobre o usuário, nome do servidor na rede, nome do cliente, data e hora do processo de login.
operações sobre as bases de dados, o usuário deve informar qual é o seu ticket de acesso. O SIT então faz uma checagem interna para certificar-se de que o usuário possui permissão para realizar o que pretende.
Ãs informações contidas no ticket sobre o servidor e o cliente serão úteis para o esquema de autenticação dos stubs de rede, quando a versão cliente/servidor for implementada.
2.3.3.3- Passwords
Outro ponto de segurança no SIT é uso de passwords. Quando uma base de dados é criada, o usuário informa um conjunto de passwords que serão utilizadas pelo sistema no esquema de segurança. Esse conjunto envolve os seguintes itens:
• password de base
• password de manutenção de base • password de campo
A primeira é a mais comum e é usada sempre que um usuário tenta abrir uma base de dados. Mesmo tendo passado pelo processo de login, o usuário deve informar essa password para ter acesso a uma base de dados. Com ela o usuário "entra" na base e pode manipular os registros e campos conforme os níveis de segurança definidos pelas ACLs, que serão vistas na seção 2.3.3.5.
A segunda password serve para aquele usuário que deseja realizar alterações na estrutura de uma base de dados, como por exemplo, incluir ou excluir um campo. Isso significa que com a password de base, descrita acima, é possível manipular apenas dados. Para alterar a estrutura física de uma base é necessário conhecer a password de manutenção.
A terceira na verdade é um conjunto de passwords. Para cada campo de uma base de dados existe uma password. Ela poderá ser usada para proteger um campo contra aqueles casos acidentais dé exclusão ou alteração de algumas de suas características. Quando o usuário tenta realizar uma dessas operações, ele deve informar a password do campo em questão.
2.3.3.4- Características de segurança de uma base de dados
Todas as bases de dados criadas pelo SIT possuem mecanismos de segurança que, quando aliados aos outros mecanismos descritos nesta seção, tornam todo o esquema mais eficiente.
O primeiro item de segurança de uma base de dados é o seu tipo. Cada base possui um identificador de tipo, que determina níveis de segurança para ela mesma. Quem define esse tipo é o usuário, no momento de criar uma base. Os possíveis tipos de base são:
• Base Pública • Base Privada
• Base Pública com restrição a registros (chamada de PUB_RR) • Base Privada com restrição a registros (chamada de PRIVJRR)
Quando uma base é PÚBLICA, todos os usuários possuem livre acesso ás informações nela contida; quando ela é PRIVADA, todos os usuários precisarão saber a senha de uso ou estar cadastrados nas ACLs (ver seção 2.3.3.5) para ter o direito de usá-la.
Quando um usuário cria um registro em uma base de dados, o SIT fixa esse usuário como o dono do registro. Em bases dos tipos PUB_RR e PRIV_RR o acesso aos registro é determinado por ACLs existentes para cada um deles. Isto é, para cada registro de uma base PUBJRR ou PRIV_RR há um conjunto de permissões. Com isso, um usuário pode impedir que outros acessem seus registros, mesmo estando em uma base pública. Dessa forma, as bases PUBRR podem ser abertas normalmente, como uma base pública, mas cada usuário possui o direito de atribuir permissões para seus registros; de forma semelhante, as bases PRIV_RR podem ser acessadas por quem souber a senha de uso ou estiver cadastrado nas ACLs, mas alguns registros podem estar protegidos.
Para todos os casos, a senha de manutenção é necessária quando se deseja alterar a estrutura física da base.
Uma base de dados possuí mais outro atributo, que é o nome da base de usuários à qual ela pertence. Essa UDB é consultada todas as vezes que alguém tentar acessar a base de dados. Há duas finalidades básicas dessa consulta:
• validar o usuário que está tentando abrir a base, através de consulta aos dados cadastrais;
• validar a existência da base de dados, para verificar se realmente ela foi criada onde está ou se foi copiada indevidamente por algum usuário. Esse mecanismo de segurança impede que as bases de dados sejam transportadas para outros locais sem administração adequada, conforme exige o requisito citado na seção 2.1.6, item 7.
2.3.3.S- ACLs
As ACLs, que significam Listas de Controle de Acesso, representam um esquema de segurança bastante poderoso e ao mesmo tempo simples. Um usuário que criar uma base de dados pode delegar poderes para outros usuários através deste esquema de segurança.
Com as ACLs é possível determinar níveis de acesso para uma base, para os campos da base (um a um) e até mesmo para registros da base. Isso significa que um usuário A, dono de uma base BA , poderá informar ao SIT que o usuário B possui acesso total à sua
base, mas o usuário C poderá acessar apenas os campos 1, 3 e 4, e para leitura. Quanto aos registros, suponha que o usuário A criou centenas deles, mas há um que é secreto e ninguém poderá vê-lo (nem o usuário B, que possui acesso total). Então, o usuário A define
uma permissão de ACL para o registro especifico, informando ao sistema que apenas ele (A) terá acesso. Os outros usuários, mesmo se fizerem um carriinhamento sequencial pelos registros da base BA, não verão esse registro.
A tabela I apresenta o conjunto de permissões que o SIT admite.
READ o item indicado (base, campo ou registro) só pode ser lido WRITE o item indicado poderá ser atualizado
APPEND
o usuário possui o direito de criar um valor, que pode ser um registro ou uma informação de campo.
DELETE o usuário possui o direito de apagar um item.
NONE o usuário não possui nenhum direito sobre o item indicado. ADM o usuário possui permissão de administrador, o que significa
que ele tem todas as permissões possíveis
Tabelai - Conjunto de permissões de ACL
Todas as permissões podem ser combinadas para que o usuário obtenha a permissão desejada.
A figura 3 mostra o formato de uma ACL, que é composta por vários itens de ACL, que por sua vez, são formados (cada um) por elementos de ACL. Cada elemento de ACL contém os campos (ou registros) e as permissões.
TIPO ACL USRouGRP NOME ítem de ACL-Elementos de ACL NOME USRouGRP C/R PERM C/R P E R M ; C/R PERM C/R PERM NOME USRouGRP C/R PERM C/R PERM]
Figura 3 -Estrutura geral de uma ACL
Cada ACL pode ser de um grupo de usuários ou de um usuário. O TIPO_ACL indica se a permissão é para usuário ou para grupo. Cada item de ACL contém o nome do usuário ou do grupo, conforme TIPO_ACL. Para cada item de ACL, há uma lista de
elementos de ACL, que armazenam as permissões associadas a cada campo ou registro.
As informações contidas nos elementos de ACL são o identificador do campo (para ACLs de campo) ou o número do registro (para ACLs de registros) mais uma máscara que define a permissão de acesso ao campo/registro referenciado (C/R = campo/registro). As possíveis permissões estão descritas na tabela I .
A API do SIT permite que a aplicação manipule as ACLs de tal forma que não é necessário conhecer a estrutura acima. Com uma única função da API é possível definir permissões para qualquer usuário ou grupo de usuários, seja para campo ou para registro.
As ACLs de registros só são usadas nos casos de base pública com restrição de registros e base privada com restrição de registros (veja esses conceitos na seção 2.3.3.4) e só será dada permissão de acesso se o usuário passar pelas restrições do registro.
Todo esse esquema de segurança descrito acima atende aos requisitos impostos nas seções 2.1.1 e 2.1.6, itens 3, 5, 6 e 7.
2.3.4 Tipos de dados no SIT
O SIT oferece alguns tipos de dados diferentes, representados por tipos de campo que o usuário poderá utilizar em suas bases de dados. A descrição de cada um deles está na tabela IL abaixo.
i
I •• <i ... .... . . .
VALUE o campo pode armazenar valores inteiros de 4 bytes BYTE o campo pode armazenar valores inteiros de 1 byte SVALUE o campo pode armazenar valores inteiros de 2 bytes FVALUE o campo pode armazenar valores de ponto flutuante
(float)
DVALUE o campo pode armazenar valores de ponto flutuante (double)
ALPHA o campo pode armazenar strings de tamanho limitado TEXT o campo pode armazenar textos
DATE o campo pode armazenar datas TIME o campo pode armazenar horas
BINARY
o campo pode armazenar informações binárias, que não têm significado para o sistema, mas que o usuário conhece
Tabela II - Tipos de campo manipulados pelo SIT
Cada um dos tipos de campo citados acima possui as seguintes características:
• pode ser multivalorado • possui um SLOT • contém senha
• identificador numérico único em uma base • nome de identificação
• tamanho • índices
Um campo multivalorado é aquele que pode conter mais de um valor (dado, informação) no mesmo registro. Um exemplo típico é o campo telefone, de uma base de clientes de uma loja. Cada registro pode conter o nome do cliente (um campo), o endereco residencial (outro campo) e uma lista de telefones (um campo multivalorado).
Um SLOT é uma área de disco destinada a armazenar uma informação do usuário. O SIT não tem qualquer controle sobre a informação armazenada em um SLOT. Através de funções específicas da API, o usuário poderá gravar uma informação em um SLOT, ler essa informação ou consultar o tamanho da informação que está armazenada.
Todos 05 campos de uma base de dados possuem senhas de acesso, que são definidas no momento da criação da base e servem para dar permissão a um usuário que deseja alterar características dos campos, tais como nome e tamanho.
Para cada campo que é criado em uma base de dados, o sistema cria um identificador numérico único. Através do identificador de um campo o usuário poderá manipulá-lo. Já o nome de identificação é dado pelo usuário no momento da criação. Esse nome também pode ser usado como referência para manipular os campos.
Os campos do tipo DATE, TIME, VALUE, BYTE, SVALUE, FVALUE e DVALUE possuem tamanhos fixos já definidos pelo SIT. O campo do tipo ALPHA possui tamanho fixo definido pelo usuário no momento de sua criação e os campos do tipo TEXT e BINARY possuem tamanhos variáveis de acordo com o conteúdo armazenado.
Finalmente, para cada campo existente em uma base de dados, poderá haver até nove índices diferentes. Cada um dos possíveis índices é usado para um caso especifico e nada impede o usuário de combiná-los conforme suas necessidades. A tabela m apresenta os nove índices que um campo pode ter.
UNIQUETREE
cada valor de um campo é uma chave que só pode ser encontrada uma vez na base de dados. Não é possível gravar uma mesma chave mais de uma vez neste índice.
WORDTREE
cada palavra encontrada em um valor de um campo é indexada neste índice. Isso significa que se o usuário mandar indexar um campo do tipo TEXT ou ALPHA, cada uma das palavras contidas no texto será indexada.
REFERENCETREE
neste índice o SIT armazena uma referência que indica a localização exata de uma palavra dentro da base de dados. Assim, é possível saber em qual parágrafo e frase de um texto pode ser encontrada uma palavra.
DATETREE este índice armazena valores que indiquem data, mesmo que esses valores estejam entre palavras de um texto. TIMETREE semelhante ao DATETREE, só que armazena valores que
indicam hora
VALUETREE
também semelhante ao DATETREE, só que armazena valores inteiros e de ponto flutuante. Esses três últimos índices são apropriados para pesquisas de faixa, do tipo: obtenha todas as datas entre 9/9/1957 e 10/5/1991, por exemplo.
BACKTREE
este índice é semelhante ao índice de palavras, com a diferença que, neste caso, as palavras sofrem uma inversão na ordem de seus caracteres antes de serem indexadas. Isso é particularmente útil quando se deseja fazer uma pesquisa do tipo *gia> onde poderíamos obter biologia, cardiologia,
PHONETREE este índice annazena palavras de forma fonética, o que permite pesquisas do tipo casa ou coza.
ENTIRETREE
este índice é semelhante ao UNIQUETREE. A diferença é que neste índice é possível armazenar chaves repetidas. 0 SIT indexa o conteúdo completo de um campo que possui este índice. Isto é, o conteúdo do campo não é "quebrado" em palavras.
Tabela 111 - índices usados pelo SIT
Essa variedade de tipos de dados e índices faz com que o SIT atenda aos requisitos citados na seção 2.1.2.
O SIT também atende aos requisitos citados no tópico 2.1.9.
2.3.5 Indexação, Consulta e Listas de Ocorrências
O SIT indexa automaticamente todos os dados de um registro quando ele é gravado. Portanto, a aplicação não precisa se preocupar com esse fator. Mas se houver necessidade de uma performance maior durante a gravação dos registros, a aplicação pode desativar a indexação automática (também chamada de indexação on-liné). Dessa forma, os registros são gravados e não são indexados. Quando for desejado, a aplicação poderá ordenar que o sistema indexe todos aqueles registros que foram gravados sem indexação.
Há também aquele caso em que é necessário re-úidexar todos os registros de uma base de dados devido a danos físicos nos arquivos ou por outro motivo qualquer. O SIT
disponibiliza uma maneira de realizar essa operação, destruindo os índices atuais e construindo outros a partir dos dados da base.
Como visto na tabela IH, o SIT disponibiliza vários índices para que a aplicação escolha quais são os mais adequados. Esses índices são montados por um sistema de índices que, como dito anteriormente, não é alvo desta dissertação. Durante o processo de indexação, o SIT descobre automaticamente em quais índices colocar as informações dé forma a possibilitar consultas mais eficientes.
Uma vez que os dados estejam devidamente indexados, é possível realizar pesquisas sobre os índices para a obtenção de dados. Como o sistema trabalha com recuperação textual, é possível realizar buscas do tipo "quero todas as ocorrências da palavra acidente, que esteja no mesmo parágrafo da palavra trânsito1'. O SIT então fará a busca sobre o
sistema de índices e montará o que é conhecido por Lista de Ocorrências.
Essa lista representa o resultado da pesquisa realizada sobre o sistema de índices. Ela contém exatamente todas as ocorrências encontradas. Cada ocorrência contém informações sobre a localização da palavra pesquisada dentro da base de dados. As informações de uma ocorrência são as seguintes:
• número do registro • identificador do campo
• número do parágrafo dentro da repetição • número da frase dentro do parágrafo
• número de sequência da palavra dentro da frase • palavra encontrada
Essa última informação pode não parecer útiL pois o usuário já sabe qual foi a palavra que mandou procurar. Mas ela é útil sim. O usuário pode ter pedido para o SIT procurar, por exemplo, aciden*. Então, a última informação de uma ocorrência poderia ser:
• acidente • acidentes • acidentada • acidentada *
As outras informações têm significados óbvios e servem basicamente para localização da palavra dentro de um contexto. Por exemplo, a aplicação pode querer brilhar as palavras encontradas dentro de um editor de textos. Com as informações de uma ocorrência é muito fácil fazer isso.
A lista de ocorrências serve para que a aplicação caminhe através dos registros da base. Sempre que for pedido o próximo registro, por exemplo, o SIT responde com o
próximo registro que é indicado pela lista, que pode não ser o próximo registro físico da base de dados.
Esse tipo de lista pode ser obtida de várias formas. A primeira delas é através da realização de uma consulta feita sobre o sistema de índices. Outra forma é carregá-la do disco, o que significa que ela pode ser gravada. Ainda outra forma é através de "batimentos" que podem ser feitos entre duas listas. Por exemplo, é possível obter uma lista que resulte da operação
ListaA or ListaB.
A operação or é feita sobre as duas listas e uma terceira lista é gerada contendo as combinações das ocorrências de cada uma das listas.
O esquema de indexação e consultas apresentado acima permite que o SIT atenda aos requisitos citados nas seções 2.1.3 e 2.1.7 (parcialmente, pois esta seção não trata só de indexação), além da 2.1.9.
