UM ESTUDO SOBRE SGBDs PARA AMBIENTES NO CRTICOS

Leonardo dos Reis

Uberlndia, Dezembro/2000.

UM ESTUDO SOBRE SGBDs PARA AMBIENTES NO CRTICOS

Leonardo dos Reis

Monografia apresentada ao Curso de Cincia da Computao do Centro Universitrio do Tringulo Unit, como requisito bsico obteno do grau de Bacharel em Cincia da Computao, sob a orientao
do Prof. Fabian Martins da Silva.

Uberlndia, Dezembro/2000.

UM ESTUDO SOBRE SGBDs PARA AMBIENTES NO CRTICOS

Leonardo dos Reis

Monografia apresentada ao Curso de Cincia da Computao do Centro Universitrio do Tringulo Unit, como requisito bsico obteno do grau de Bacharel em Cincia da Computao.

Fabian Martins da Silva, Msc.

Marcos Ferreira de Rezende, Msc.

(Orientador )

(Coordenador de Curso)

Jansen Rubens Fidelis da Silva, Msc.

Cludia de S. Felipe Spirandelli, Msc.

(Avaliador )

(Avaliador )

Uberlndia, Dezembro/2000.

ii

Agradeo a Deus,
pois sem a presena Dele nada
seria possvel. Em especial, agradeo a meus pais,
que sempre estiveram comigo e me incentivaram em todos os meus desafios.

iii

Dedico esta obra a

minha namorada Renata L. Soares,
por quem admiro e gosto muito.

iv

Resumo

As experincias vivenciadas no curso de computao, na UNIT campus Arax, onde o autor iniciou suas
pesquisas em Banco de Dados, levou-o idealizao deste trabalho, que traa uma srie de caractersticas
e particularidades sobre os SGBDs para melhor uso dos mesmos, seja em escolas, seja em empresas de
grande, mdio e pequeno porte. Em primeira instncia, so apresentados alguns conceitos bsicos sobre
SGBDs, vantagens, bem como sua arquitetura e funcionalidade. Em seguida sero mostrados alguns dos
principais SGBDs existentes no mercado, com suas respectivas caractersticas e particularidades.
Finalmente analisou-se que deve-se levar em conta suporte a linguagem, escabilidade, segurana,
recuperao dos dados e treinamento para a escolha mais adequada do SGBD a ser implementado.

Sumrio

1 - Introduo..................................................................................................... 01
1.1 - Gerenciamento de Dados em Organizaes Antes do Surgimento
dos Bancos de Dados................................................................................. 01
1.2 - Banco de Dados......................................................................................... 04
1.2.1 - Definio................................................................................................. 04
1.2.2 - Vantagens............................................................................................... 05
1.3 - Sistemas de Gerncia de Banco de Dados.................................................. 07
1.3.1 - Definio................................................................................................. 07
1.3.2 - Funes Bsicas...................................................................................... 07
1.3.3 - Dicionrio de Dados................................................................................ 10
1.3.4 - Arquitetura Bsica de um SGBD.............................................................. 11
1.3.5 - Agentes de Interao com o SGBD......................................................... 13
1.3.6 - Funcionamento do SGBD........................................................................ 15

2 - Coleta de parmetros em SGBDs.................................................................. 18

2.1 - XBASE E SQL: Uma comparao tcnica.................................................. 18
2.1.1 - Origem.................................................................................................... 18

2.1.2 - Linguagem............................................................................................... 19
2.1.3 - Arquivos Fsicos...................................................................................... 21
2.1.4 - Travamento (Locking)............................................................................. 22
2.1.5 - Padronizao........................................................................................... 23
2.1.6 - Diferenas na Implementao................................................................... 24

vi

2.1.7 - Clientes e Servidores............................................................................... 25

2.1.8 - Concluso............................................................................................... 27
2.2 - SQL Server................................................................................................ 28
2.2.1 - Introduo - Sistemas de arquivos x bancos relacionais............................ 28
2.2.2 - Entidades, relacionamentos e atributos..................................................... 28
2.2.3 - Linguagem SQL (Strutured Query Language)........................................... 30
2.2.4 - Bancos de dados (DATABASES)........................................................... 31
2.2.5 - Localizao dos bancos de dados............................................................ 37
2.2.6 - Stored Procedures................................................................................... 38
2.2.8 - Acesso via Intranet / extranet / Internet..................................................... 42
2.3 - Banco de Dados Orientado a Objetos........................................................ 49
2.3.1 - Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos...... 49
2.3.2 - Definio de SGBDOO........................................................................... 50
2.3.3- Outros Conceitos..................................................................................... 51
2.3.4 - Vantagens, Desvantagens e Comparativos de SGBDOO.......................... 51
2.3.4.1 - Comparativo........................................................................................ 51
2.3.4.2 - Vantagens............................................................................................ 52
2.3.4.3 - Desvantagens....................................................................................... 52
2.3.5 - Aplicaes de SGBDOO........................................................................ 53
2.3.6 - Concluso............................................................................................... 53
3 - Selecionando um banco de dados.................................................................. 55

3.1 - Como escolher um banco de dados............................................................ 55

3.2 - Modelo de banco de dados datawarehouse................................................ 58
4 - Concluso..................................................................................................... 61
Referncias Bibliogrficas.................................................................................... 62

vii

vii

1 Introduo
1.1 Gerenciamento de Dados em Organizaes Antes do Surgimento dos Bancos de Dados
O surgimento da tecnologia de Banco de Dados (BD) ocorreu no momento em que os especialistas no
desenvolvimento de sistemas computacionais perceberam que, para a informatizao de grandes
organizaes, vrias questes relacionadas com o gerenciamento de dados necessitavam ser resolvidas de
uma forma mais eficiente.
Para ilustrar esta situao, pode-se tomar como exemplo uma organizao como a Universidade. Na
Universidade, vrios setores so responsveis pela administrao de um grande volume de dados, sendo
muitos destes dados comuns a vrios setores. Pode-se imaginar trs setores nesta organizao: o setor
Acadmico, responsvel pela controle das atividades de ensino; o setor Administrativo, que coordena a
estrutura geral da Universidade; e o setor de Pessoal, responsvel pela administrao das pessoas que
trabalham na Universidade e onde esto lotadas. A tabela, a seguir, mostra alguns arquivos de dados que
estes setores manipulam.
Setor Acadmico Setor Administrativo

Setor Pessoal

Alunos

Centros

Centros

Professores

Departamentos

Departamentos

Disciplinas

Cursos

Professores

Turmas

Disciplinas

Funcionrios

Salas
Dados manipulados por trs setores da Universidade
Imagina-se, ainda, que cada setor apresenta um sistema aplicativo que automatiza a sua administrao.
No existe a tecnologia de banco de dados nesta realidade. Assim, tem-se a seguinte situao:

Cada setor da Universidade descreve os seus arquivos: cada setor define registros com

campos e formatos que julga adequados. Por exemplo, o arquivo de professores em Acadmico
mantm dados como nome, data do nascimento, titulao e rea de interesse. J o arquivo de
mesmo nome em Pessoal necessita de nome, data do nascimento, CPF, salrio e data de admisso.
Mesmo os campos semelhantes em ambos os arquivos, como nome e data de nascimento, podem
apresentar formatos (tipos de dados) diferentes;

Implementam-se organizaes simples de arquivos: cada aplicao define arquivos atravs

do seu ambiente de programao e implementa procedimentos para lidar com os seus dados. Por
exemplo, para o arquivo de alunos, em Acadmico, so necessrias rotinas para incluir um novo
aluno e consultar registros com base na informao do nmero de matrcula do mesmo. De forma
alternativa, cada aplicao poderia utilizar softwares rudimentares para gerenciamento de
arquivos, que permitem a definio de um conjunto de arquivos e disponibilizam um conjunto
limitado de funes, como por exemplo, incluso de um registro, alterao de um campo de
registro, consulta pela igualdade de valor de um campo, etc. Estes softwares podem ser
considerados os sistemas predecessores dos atuais sistemas de gerncia de BD;

O acesso aos dados controlado pelas aplicaes de cada setor: todo o esforo de
gerenciamento de dados (definio de arquivos, manipulao de dados, consistncia de dados, etc)
implementado em cada aplicao. Obviamente, quanto maior a quantidade de arquivos, maior
este esforo;

No existe compartilhamento de dados entre as aplicaes: o gerenciamento de dados

local, ou seja, realizado individualmente por cada aplicao. Os dados so dependentes dos
programas da aplicao, sendo manipulados apenas por estes programas (isolamento dos dados em
relao a organizao como um todo). Atravs da anlise desta realidade, possvel perceber uma
srie de problemas no que diz respeito administrao de dados da organizao:

Redundncia: existe replicao de dados (por exemplo, professores, disciplinas e centros) e de

procedimentos para tratamento destes dados (por exemplo, consulta pelo nome de um professor e
excluso de uma disciplina);

Difcil manuteno: a atualizao de um dado replicado exige que todos os setores que
apresentam este dado sejam informados da atualizao desejada e a efetivem esta atualizao no
seu arquivo. Inconsistncias podem ocorrer facilmente, caso esta manuteno no seja controlada
rigidamente. Por exemplo, suponha que um novo professor passou a trabalhar no departamento de
informtica. A incluso dos seus dados foi feita no setor Acadmico. Em virtude do no
compartilhamento de dados, apenas alguns dias depois foi enviado um relatrio para o setor
Pessoal e a incluso feita neste setor. Com isto, o novo professor perdeu alguns dias de salrio;

Falta de padronizao: como cada aplicao define os seus dados de interesse, sem um projeto

global dos dados da organizao, fica difcil a integrao de aplicaes, pois no possvel
reutilizar definies de arquivos e procedimentos para manipul-los. Pode-se tomar como
exemplo as definies, mostradas anteriormente, dos arquivos de Professores feitas nos setores
Acadmico e Pessoal;

Formas restritas de acesso: no projeto inicial de cada aplicao, definem-se certas operaes
sobre cada arquivo. Caso, seja necessria, posteriormente, uma nova operao, como por exemplo,
uma consulta a disciplinas pelo cdigo do departamento, alm do cdigo da prpria disciplina,
deve-se implementar mais um procedimento e recompilar a aplicao. A manuteno da aplicao
trabalhosa, quando se deseja flexibilizar o acesso a dados;

No h controle de segurana dos dados: imagina-se que cada aplicao implementa rotinas
bsicas para garantia de consistncia dos dados, como verificao de valores vlidos quando
ocorre uma incluso. Porm, controles mais sofisticados, como autorizaes de acesso e
preveno contra falhas, no so suportados, devido complexidade de implementao.

1.2 Banco de Dados

1.2.1 Definio
Um BD pode ser definido como sendo:
Uma coleo de dados operacionais inter-relacionados. Estes dados so armazenados de forma
independente dos programas que os utilizam, servindo assim a mltiplas aplicaes de uma organizao.
Algumas partes desta definio so fundamentais para a compreenso do conceito de BD:

Coleo: agrupamento com repetio;

Operacionais: vitais; estratgicos para a tomada de decises; permanentes;

Inter-relacionados: um BD mantm um agrupamento de entidades (fatos da realidade em

questo) e de relacionamentos entre estas entidades;

Independentes dos programas: dados so mantidos em um meio de armazenamento destinado

aos dados da organizao e no necessariamente no espao local do programa de aplicao;

Serve mltiplas aplicaes: dados em um BD podem ser compartilhados por vrias

aplicaes da organizao. Cada uma delas define exatamente os dados que deseja manipular.

Um exemplo de BD para a Universidade seria todas as entidades (alunos, disciplinas, etc.) que compem

a realidade e os relacionamentos que existem entre elas esto definidas no BD. possvel tambm
identificar a poro do BD que interessa para cada aplicao (setor) presente na Universidade.

1.2.2 Vantagens
O uso da tecnologia de BD traz inmeras vantagens, se comparada com a situao descrita na seo 1.1:

Dados armazenados em um nico local: o BD o repositrio nico dos dados da organizao.

Com isto, reduz-se drasticamente a redundncia e eliminam-se redefinies de dados semelhantes,
que antes estavam replicadas nas vrias aplicaes;

Dados compartilhados pelas aplicaes: o compartilhamento facilita a integrao de novas

aplicaes organizao, uma vez que no necessrio redefinir o que j existe, nem incluir
dados j presentes no BD (melhor reusabilidade de especificaes e valores de itens de dados);

Independncia dos dados: dados no necessariamente esto na rea de armazenamento

secundrio do equipamento onde executa a aplicao. Alm disso, todos os procedimentos para
tratamento de dados so agora realizados pelo BD. Modificaes nestes procedimentos no afetam
a aplicao, ou seja, esta no necessita ser recompilada. Ainda, o cdigo da aplicao fica mais
enxuto;

Flexibilidade de acesso: o acesso ao BD realizado atravs de linguagens de alto nvel para

manipulao de dados. A manuteno do cdigo da aplicao facilitado. Onde antes era
necessrio programar um procedimento para realizar uma operao sobre os dados, agora basta
apenas escrever um pequeno comando nesta linguagem de manipulao;

Aplicaes no se preocupam com a gerncia dos dados: todo o gerenciamento de dados, no

que diz respeito ao acesso, integridade, segurana, concorrncia, autorizao, etc, incumbncia
de um software denominado sistema de gerncia de BD (SGBD).
SGBDs, apesar de oferecerem todas estas vantagens para os desenvolvedores de aplicaes,
necessitam ser devidamente escolhidos, de forma a se adequarem com a plataforma computacional
onde a aplicao executar. Muitas vezes, dependendo desta plataforma, os SGBDs podem ser
mais ou menos poderosos. Alguns SGBDs de grande porte, consolidados no mercado, por
exemplo, muitas vezes no apresentam verses disponveis para plataformas pequenas, como o
Windows 95.

1.3 Sistemas de Gerncia de BD (SGBDs)

1.3.1 Definio
Um SGBD pode ser definido como segue:
"Um sistema cujo objetivo principal gerenciar o acesso e a correta manuteno dos dados
armazenados em um banco de dados."
Acesso quer dizer que o SGBD deve disponibilizar uma interface, via linguagens, que permita a
comunicao com a aplicao. Correta manuteno significa que devem ser gerenciados aspectos de
integridade, segurana e concorrncia, de maneira a evitar dados inconsistentes.
1.3.2 Funes Bsicas
Com base na definio de um SGBD, as seguintes funes bsicas so encontradas:
1) Mtodos de acesso: duas categorias de linguagens devem ser suportadas:

DDL (Data Definition Language): permite a especificao do esquema da organizao, ou seja,

entidades com seus atributos e tipos de dados associados; os relacionamentos entre estas entidades
e os ndices de acesso associados aos atributos. Por esquema, entende-se uma organizao lgica
dos dados de uma realidade, adequados ao modelo de dados do SGBD;

DML (Data Manipulation Language): permite as operaes usuais de manipulao de dados,

executados pelas aplicaes: incluso, alterao, excluso e consulta;

Consultas, de modo especial, devem ser executadas pelo SGBD de maneira eficaz, ou seja, procurando
minimizar o nmero de acessos ao meio de armazenamento secundrio assim como o volume de dados
gerados nos resultados intermedirios do processamento da mesma. Para tanto, a antecipao da aplicao
de filtros e a busca apenas de dados relevantes para os relacionamentos, em uma certa etapa do
processamento, so exemplos de estratgias que so consideradas.
2) Restries de integridade (RIs): integridade est associada idia de dados corretos, dados
consistentes no BD. RIs preocupam-se em manter dados sempre coerentes, verdadeiros com a realidade
em questo. Devem garantir:

Estados possveis de serem assumidos pelos dados: Por exemplo, a idade de um funcionrio
deve estar entre 16 e 80 anos. Alteraes no salrio de um funcionrio no podem diminuir o valor
existente, etc;

Manuteno de relacionamentos vlidos entre os dados: Exemplos: uma turma no pode estar
vinculada a mais de uma disciplina; Disciplinas no podem existir sem estarem vinculadas a um

curso, etc.
Para tanto, o SGBD deve disponibilizar uma linguagem para especificao de RIs, chamada DCL (Data
Constraint Language). Atravs dela deve ser possvel programar testes (por exemplo, 16 <= idade <= 80)
e aes (por exemplo, remover todas as turmas de uma disciplina quando a disciplina removida).
3) Segurana: este controle evita a violao da consistncia dos dados por agentes e/ou situaes no
previstas (falhas). Dois gerenciamentos devem ser realizados:

Autorizao de acesso: permitir que apenas agentes autorizados, sejam usurios ou aplicaes,
realizem certas operaes sobre certos dados. Para tanto, faz-se necessrio manter uma matriz de
autorizao, que especifica, para cada agente e cada dado, a(s) operao(es) autorizadas. Por
dado entende-se alguma poro do BD, como um ou mais registros, um arquivo completo ou
vrios, alguns campos de um registro, etc. O mecanismo de vises permite especificar a poro do
BD que um agente tem direito de acesso;

Recuperao de falhas (recovery): possibilitar o retorno do BD a um estado consistente de seus

dados aps a ocorrncia de uma falha involuntria. Para tanto, o SGBD deve manter, por exemplo,
arquivos histricos (chamados logs) que cadastram todas as atualizaes realizadas no BD por
transaes. Por transao entende-se um conjunto de operaes de manipulao de dados que
submetido ao BD, sendo que todas estas operaes devem ser efetivadas ou, na ocorrncia de uma
falha, nada deve ser efetivado, para preservar a consistncia dos dados. Os logs devem registrar,
dentre outras coisas, a identificao das transaes, os arquivos manipulados, os registros
atualizados, a operao feita e os valores atual e antigo. No caso de falhas de transao ou de
sistema (afetam uma ou vrias transaes, respectivamente), o log deve ser consultado e as aes
realizadas por transaes inacabadas devem ser desfeitas. Caso todas as modificaes da transao
estejam registradas, possvel refaz-la. J para falhas de meio de armazenamento, que tornam
inoperantes, por exemplo, as unidades de disco onde se encontra o BD, deve-se restaurar o BD a
partir do ltimo backup realizado e consultar o log para refazer ou desfazer as transaes
cadastradas aps este backup.

4) Controle de concorrncia: este controle evita conflitos de acesso simultneo a um dado por mais de
uma transao. Se este controle no existisse, os dados consultados por uma transao, por exemplo,
poderiam se tornar invlidos caso fossem atualizados por outra transao. Este controle geralmente feito
atravs do uso de estratgias de bloqueio (lock), que garantem que apenas uma transao manipule um
dado, durante o espao de tempo que necessitar, sem que ocorra interferncia de outras transaes.
5) Independncia dos dados: esta funcionalidade do SGBD uma decorrncia direta das vantagens
trazidas pelo uso de um BD. Independncia de dados significa transparncia de gerenciamento e
armazenamento, assim como do esquema global da organizao, para as aplicaes. O primeiro caso

chamado de independncia fsica, ou seja, a aplicao no se preocupa com detalhes de localizao fsica
dos dados ou controles de integridade e segurana, por exemplo, quando deseja realizar um acesso ao BD.
A independncia lgica garante, atravs do mecanismo de vises, que uma aplicao tenha condies de
especificar a poro do BD que deseja ter acesso, no precisando ter conhecimento do esquema global.

1.3.3 Dicionrio de Dados (DD)

O DD o catlogo do SGBD, responsvel pela manuteno dos metadados (dados sobre os dados), que
dizem respeito :

Estrutura do esquema: entidades (com atributos e tipos de dados associados) e

relacionamentos;

Integridade: RIs associadas s entidades e relacionamentos; autorizaes de acesso;

Configuraes do SGBD para efeitos de controle, segurana e performance, como por

exemplo: localizao dos dispositivos onde se encontram os dados, backups e logs; nmero de
logs; nmero de buffers para log e para dados; tamanho dos buffers para log e para dados; nmero
mximo de usurios e locks; tempo mximo de timeout; intervalo de backup automtico dos
dados; etc;

Estimativas de acesso e estimativas sobre os dados, como por exemplo: tamanho do log e
suas informaes; espao ocupado/livre nos dispositivos de armazenamento; tamanho dos
arquivos de dados (quantidade de registros); percentual de utilizao de buffers; ltimo acesso a
um arquivo; mdia de tempo de processamento de transaes; ndices utilizados em acessos; etc.

O DD constantemente consultado pelo SGBD durante a realizao de vrias das suas tarefas, como
processamento de consultas, pr-compilao de comandos DML, verificao de integridade em operaes
de atualizao, etc. O Administrador do BD tambm tem acesso s suas informaes atravs de
ferramentas especiais do SGBD. Estas ferramentas so responsveis, por exemplo, pela monitorao de
performance e configurao do sistema.

1.3.4 Arquitetura Bsica de um SGBD

Um SGBD geralmente interage com diversas aplicaes de uma organizao, assim como com os meios
de armazenamento de dados. No primeiro caso, a aplicao se vale de comandos DML embutidos no seu
cdigo. No segundo caso, geralmente existe uma interface com o sistema operacional do equipamento,
para leitura e gravao de dados.

Assim, um SGBD lida com diversos nveis de viso de um mesmo dado, de maneira a abstrair detalhes da
organizao dos dados. Por exemplo, para um programa de aplicao no interessa saber que o dado de
um empregado x apresenta y bytes e se encontra armazenado em um dispositivo t. Ele apenas deseja
conhecer os seus atributos, informando, por exemplo, o seu nome, para efeitos de pesquisa.
Um SGBD lida basicamente com 3 nveis de viso (ou de abstrao) de dados:
1) Nvel Fsico: nvel menos abstrato, onde se sabe detalhes fsicos da organizao de um dado (Esquema
fsico). uma estruturao de baixo nvel, onde descrito como os dados esto armazenados, em termos
de bytes (tamanho de registros, tamanho e posio de campos, etc). O mdulo de gerenciamento de
arquivos do SGBD lida com este nvel de viso dos dados, uma vez que localiza, l e grava registros;
2) Nvel Conceitual: nvel intermedirio, que suporta uma descrio de mais alto nvel em relao ao
nvel fsico, onde a preocupao est em descrever quais dados so significativos para uma organizao
(tem semntica, so relevantes para a o dia a dia da organizao). Neste caso, lida-se com os dados a nvel
de entidades e relacionamentos, tal qual esto definidos no esquema. similar, por analogia, descrio
de um registro em uma linguagem de programao, ou seja, lida-se com nomes de arquivos e campos e
no com seqncias de bytes. Os usurios que lidam neste nvel, devem ter conhecimento completo de
todo o esquema da organizao, como o administrador do BD ou usurio especializado, que enviam
comandos ao SGBD;
3) Nvel de Viso: nvel mais alto de abstrao, sendo particular de cada aplicao que manipula dados
do BD. Neste caso, cada aplicao pode determinar o universo de dados que deseja ter acesso. Este
universo de dados pode ser uma poro do esquema global da organizao. Assim sendo, cada aplicao
abstrai detalhes irrelevantes, desnecessrios para o seu processamento, como por exemplo, o setor de
pessoal, que no tem interesse por dados de disciplinas e turmas e apenas manipula nome, CPF e salrio
de professores. Como j foi dito, os usurios deste nvel so os programas de aplicao.
Para suportar a manipulao de dados nestes 3 nveis, o SGBD deve realizar mapeamentos entre os
mesmos, de maneira a deixar transparente, para o usurio de um nvel mais alto, a organizao do dado
nos nveis mais baixos. Para o mapeamento entre o nvel conceitual e o nvel de viso, o SGBD transfere
dados das estruturas de dados (EDs) do nvel conceitual (registros com todos os campos de uma entidade)
para EDs das vises definidas sobre o esquema, que so adequadas s EDs da aplicao. J no caso do
mapeamento conceitual-fsico, o SGBD se vale de funes de manipulao de registros, que so
disponibilizadas pelo mdulo de gerenciamento de arquivos. Estas funes retornam/gravam dados do/no
nvel fsico para as/presentes nas EDs conceituais.

1.3.5 Agentes de Interao com o SGBD

Um SGBD deve se comunicar com vrios agentes (usurios ou programas), com o objetivo de atender as
necessidades de dados de diversas aplicaes, permitir o desenvolvimento de aplicaes que utilizem um
BD, assim como possibilitar que aspectos de performance possam ser otimizados, conforme a demanda
de acesso a dados pelas aplicaes.
Os agentes de interao com um SGBD so os seguintes:
1) Administrador do BD (DBA): o DBA (Data Base Administrator) pode ser encarado como um
superusurio do SGBD, uma vez que detm todos os privilgios no que diz respeito definio e acesso a
dados. As suas incumbncias so, algumas vezes, separadas em 2 agentes:

Administrador de dados (DA): especializado em projeto de BD. Interage com os usurios da

aplicao a ser desenvolvida, com o objetivo de definir os requisitos de dados e especificar o
esquema do BD. Deve ser um especialista em desenvolvimento de sistemas;

Administrador do BD (DBA): especialista no SGBD adotado pela organizao. Controla

diversos aspectos funcionais do SGBD, como definio e modificao do esquema, das
autorizaes de acesso e das regras de integridade; controle dos procedimentos de segurana
(como por exemplo: execuo de backups e recuperao de falhas de meio de armazenamento);
assim como monitorao de performance de acesso a dados e tomada de decises para melhor-la,
como criao de ndices, controle do tamanho de buffers, nmero de usurios permitidos, etc;

Esta classificao nem sempre adotada em uma grande organizao, podendo a figura denominada DBA
acumular as 2 tarefas;
2) Programas de Aplicao: interagem com o SGBD atravs de comandos de manipulao de dados
(DML) embutidos no seu cdigo. Estes comandos so pr-compilados pelo SGBD, gerando cdigo
objeto. Este cdigo executa procedimentos de acesso a dados que levam como parmetros variveis ou
estruturas de dados da aplicao;
3) Programadores de aplicao: desenvolvem aplicaes utilizando ferramentas disponibilizadas pelo
SGBD. Estas ferramentas podem ser: compiladores de linguagens de programao tradicionais que
permitem o embutimento da DML; linguagens de quarta gerao (4GL), que oferecem um ambiente
integrado para programao de sistemas e manipulao de dados, e outras ferramentas como geradores de
interfaces grficas com o usurio, geradores de relatrios, etc.
4) Usurios especializados: usurios familiarizados com a DML do SGBD. Estes usurios executam
operaes de atualizao e consulta a dados (desde que tenham permisso para isto) sem serem usurios
de uma aplicao. Diz-se que estes agentes solicitam operaes ad hoc ao BD, ou seja, operaes que so
traduzidas em tempo de execuo, enquanto o SGBD estiver on-line. diferente de operaes embutidas
em programas de aplicao, que so traduzidas uma nica vez pelo SGBD em tempo de compilao;

5) Gerenciador de Arquivos: mdulo do SGBD responsvel pela transparncia do acesso fsico aos
dados armazenados, seja para aplicaes, seja para os usurios especializados e o DBA. O SGBD apenas
solicita dados a este mdulo e o mesmo se encarrega de localizar os registros fisicamente em disco e
transferi-los para as estruturas de dados do SGBD. Este mdulo realiza a comunicao com o sistema
operacional do equipamento onde se encontram os dados, atravs do mapeamento de registros em
memria para as pginas de disco onde se encontram, ou vice-versa.
Para possibilitar a comunicao com estes agentes, um SGBD deve disponibilizar as seguintes interfaces:

Interface DDL/DCL: interface disponvel para o DBA. Atravs dela, o mesmo especifica,
atravs destas linguagens, as entidades e relacionamentos, as RIs e as autorizaes de acesso que
iro compor o esquema da organizao;

Interface DML embutida: interface de comunicao dos programas de aplicao com o

SGBD. Atravs dela, as tarefas de consulta e atualizao de dados so realizadas pelas aplicaes
em execuo;

Interface de Utilitrios: interface representada por todas as ferramentas oferecidas pelo SGBD,
seja para desenvolvimento de aplicaes, controle e configurao do SGBD ou solicitaes de
acesso a dados ad hoc. Assim sendo, os agentes que se valem desta interface so, respectivamente,
os programadores de aplicao, o DBA e os usurios especializados;

Interface de Manipulao de Arquivos e Registros: interface do SGBD com o mdulo

gerenciador de arquivos. Atravs dela, o SGBD solicita, envia, cria ou remove dados fisicamente.
Esta interface formada pelas vrias funes que so disponibilizadas pelo gerenciador de
arquivos, como por exemplo:

criao/destruio de arquivos;

criao/destruio de ndices;

incluso/excluso/alterao de registros de arquivos;

consulta de registros de arquivos.

1.3.6 Funcionamento do SGBD

Detalhando um pouco mais a arquitetura de um SGBD, encontramos os seguintes mdulos internos,
fundamentais para o seu funcionamento:
1) Mdulo Gerenciador do BD: mdulo central; ncleo (corao) de um SGBD. Responsvel pelo

atendimento das requisies de dados e metadados feitas pelos mdulos que interagem com os agentes.
Atende tambm as solicitaes de operaes sobre dados enviadas pelo cdigo objeto das aplicaes.
Retorna dados e/ou status (cdigos) que indicam situaes como execuo Ok, erros de acesso, violaes
de integridade ou permisso, etc, a estes mdulos. o nico mdulo que se comunica com o mdulo
gerenciador de arquivos. Alm disso, os controles de segurana e concorrncia tambm so
responsabilidade sua;
2) Mdulo Gerenciador de Arquivos: gerencia o acesso aos dispositivos de armazenamento. Recebe e
realiza requisies para leitura e gravao de dados, metadados e dados de segurana do mdulo
gerenciador do BD;
3) Mdulo [Pr-] Compilador DML: responsvel pela traduo de comandos DML, que podem ter sido
embutidos em um programa de aplicao ou enviados de forma ad hoc por usurios especializados. No
primeiro caso, ele realiza a pr-compilao e a gerao de cdigo objeto para estes comandos, criando um
programa pr-compilado, que remetido para o compilador do ambiente de desenvolvimento utilizado
pelo programador de aplicaes. No segundo caso, ele traduz e j executa o comando, caso esteja correto.
Em ambos os casos, ele solicita metadados ao mdulo gerenciador do BD, para poder traduzir os
comandos e, caso a solicitao seja uma consulta, ele a remete ao mdulo processador de consultas,
recebendo-a modificada;
4) Mdulo Processador de Consultas: recebe um comando de consulta do mdulo [pr-] compilador
DML e define a melhor estratgia de acesso para process-la. Para tanto, ele necessita solicitar metadados
ao mdulo gerenciador do BD, com o objetivo de analisar, por exemplo, o tamanho dos arquivos
envolvidos na consulta, relacionamentos existentes entre os dados, filtros definidos, ndices existentes,
estimativa de valores distintos de atributos, visando determinar um procedimento que processe a consulta
mais rapidamente. Este procedimento, uma vez determinado, enviado ao mdulo [pr-] compilador
DML para ser traduzido;
5) Mdulo Compilador do Utilitrio: traduz o programa fonte da aplicao, escrito em alguma das
linguagens de programao suportadas pelo SGBD. Retorna um cdigo de status ferramenta de
desenvolvimento e gera, no caso de uma traduo OK, o cdigo objeto da aplicao;
6) Mdulo Compilador DDL: traduz comandos DDL e gera, no caso de uma traduo OK, os esquemas
conceitual e fsico, ou seja, solicita a criao do BD da aplicao para o mdulo gerenciador do BD, que
por sua vez, solicita ao mdulo gerenciador de arquivos a criao de arquivos de dados (BD) e metadados
(DD). Sempre remete um status interface DDL, indicando o resultado da compilao;
7) Mdulo Compilador DCL/Autorizao: traduz comandos DCL e de autorizao de acesso e gera, no
caso de uma traduo OK, procedimentos para verificao de integridade e permisses de acesso. Estes
procedimentos so remetidos ao mdulo gerenciador do BD, que por sua vez, solicita ao mdulo

gerenciador de arquivos o armazenamento dos mesmos no DD. Sempre remete um status interface
DCL/Autorizao, indicando o resultado da compilao;
8) Mdulo de Administrao: mantm os procedimentos para monitoramento de performance e
configurao do BD, e recuperao de falhas. A primeira classe de procedimentos solicita/modifica dados
de configurao e solicita estimativas sobre performance ao mdulo gerenciador do BD, que as obtm no
DD e/ou nos dispositivos que mantm dados de segurana (BD de Recovery). A segunda classe de
procedimentos solicita dados ao BD de Recovery, para restaurar os dados do BD, na ocorrncia de uma
falha.

2 - Coleta de parmetros em SGBDs

2.1 - XBASE E SQL: Uma Comparao Tcnica
2.1.1 Origem
As linguagens de Banco de Dados (Xbase e SQL) tem tido diversas conotaes desde sua concepo. A
linguagem SQL (Structured Query Language) inicia seu caminho na IBM em 1970 com o documento
"Um Modelo Relacional para Grandes Bancos de Dados Compartilhados" (A Relational Model For Large
Shared Data Banks) escrito pelo Dr. E. F. Codd. Aps a definio de clculos relacionais e das 12 leis de
Codd de sistemas relacionais, os padres e as implementaes do SQL, ocorreram rapidamente. Em
contraste, a linguagem Xbase comeou como aplicao CP/M, escrita em 1981 no Pasadena Jet
Propulsion Laboratory para gerenciar vrios projetos. A teoria do Xbase baseada no Mtodo de Acesso
Sequencial Indexado (ISAM - Indexed Sequential Access Method) para acesso a dados. Embora o Xbase
tenha suas origens no SQL, ele conseguiu significante sucesso por um bom nmero de razes. A mais
importante que o Xbase rpido, simples, e de baixo custo de implementao.
Embora o Xbase no represente uma exploso terica como o SQL, ele possui inmeras vantagens
tcnicas que o tornam uma soluo superior para acesso a dados em muitas situaes. Infelizmente, o
SQL tornou-se um padro de mercado, resultando em desperdcio de esforos e investimentos em
implementaes sem sucesso, que estariam bem melhor em Xbase.
A diferena fundamental entre um banco de dados relacional e um banco de dados Xbase que a unidade
bsica de dados em SQL um conjunto de dados, enquanto que em Xbase um registro. Um banco de
dados SQL possui uma tabela como um conjunto (tambm chamada de uma relao, por isso o termo
"banco de dados relacional"). Estes conjuntos so grupos de registros que so divididos em campos,
contendo informaes. Estes conjuntos formam as bases da fora e da complexidade de consulta (query)
do SQL. O Xbase enxerga cada arquivo do banco de dados (tipicamente representado por extenso .DBF
no nome do arquivo) como uma tabela contendo registros de tamanho uniforme com campos definidos de
maneira exata. A unidade bsica de acesso aos dados um registro individual. A definio exata de
acesso aos dados propicia ao Xbase sua velocidade e simplicidade.

2.1.2 Linguagem
A diferena mais significativa entre SQL e Xbase a linguagem de manipulao de dados utilizada. A
linguagem SQL uma representao em texto da lgebra relacional proposta pelo Dr. Codd. Suas
instrues utilizam linguagem familiar s pessoas, tais como: ATUALIZAR (UPDATE), SELECIONAR
(SELECT) e INSERIR (INSERT). Este modo intuitivo de se relacionar com os dados muito natural para
as pessoas entenderem, mas no muito simples de se manipular, a partir de um cdigo.
O Xbase foi inicialmente desenvolvido para se concentrar em um cdigo, assim sua sintaxe mais como
uma linguagem procedural de computador do que uma linguagem humana. Ao invs de executar uma
consulta (query) como no SQL e navegar sobre um conjunto de resultados, o Xbase usa o conceito de rea
de trabalho, que essencialmente um cursor numa tabela. A rea de trabalho contm o registro corrente,
uma lista de ndices aberta, um ndice corrente e marcas (flags), tais como final e incio de arquivo.
Algumas diferenas entre rea de trabalho do Xbase e um cursor SQL so que a rea de trabalho do
Xbase quando aberta tem todos os registros visveis, e os dados visveis aos usurios no so pedaos
(snapshots) como os resultados de consulta (query) do SQL.
Navegao em uma rea de trabalho Xbase facilitada pela ida ao incio ou final dos registros visveis,
avanando ou retrocedendo, tendo como base o registro corrente, procurando por uma chave utilizando
um ndice, ou indo a um registro especfico em uma tabela. Navegao em SQL tipicamente feita por
busca na prxima linha ou nas seguintes. As vantagens do esquema do Xbase so desempenho e
flexibilidade. Pelo fato do Xbase utilizar o conceito de registro corrente, a atualizao do campo de dados
muito mais fcil e rpida do que em SQL, devido ao formato de dados implcito. Depois de atualizar ou
inserir um registro, a rea de trabalho ainda est posicionada, enquanto que no SQL deve-se refazer a
consulta (query) no banco de dados para visualizar atualizaes e incluses. Ironicamente, as ferramentas
de desenvolvimento para uso do SQL quase sempre incluem um mtodo de manipulao de seus
resultados, empregando conceitos tais como skips, replaces e appends, oriundos do Xbase.
Implementaes em Xbase tambm permitem filtros em reas de trabalho. Filtro em Xbase permite que
somente registros que atendam as condies especificadas sejam visveis ao usurio. Esta funcionalidade
similar a clusula WHERE de uma consulta (query) do SQL, mas permite o uso de expresses Xbase e
podem ser alteradas sem necessidade de uma nova consulta (query) em toda a base de dados. Scopes
tambm podem ser utilizados para delimitar os registros visveis. Scopes em Xbase so usados em um
conjunto de ndices para marcar um incio e/ou fim dos registros visveis, provendo melhor desempenho
em relao ao uso de filtros Xbase.
As expresses em Xbase so muito mais ricas que as permitidas pelo SQL padro. A maioria das
plataformas Xbase suportam uma grande variedade de funes. Alguns exemplos de funes Xbase so:
VAL(), que converte uma expresso string em valor, SUBSTR(), que permite que substrings sejam
extrados, e IF(), que permite expresses condicionais em qualquer expresso Xbase. Estas funes esto

frequentemente disponveis de alguma forma atravs do SQL, mas seu uso mais limitado. Em Xbase,
estas e muitas outras funes podem ser usadas em expresses de filtragem, que controlam dados visveis
em uma rea de trabalho, e em expresses de ndice. Estas expresses em Xbase podem tambm ser
avaliadas em processamento. A complexidade de expresses de ndice permite grande velocidade e
controle do acesso aos dados. Um ndice em Xbase poder ser construdo de quase todas as formas. Por
exemplo, um ndice pode ser criado por registros que contenham somente nomes no vazios que
contenham a letra "A" no estado da Bahia. Estes ndices complexos podem prover funcionalidade similar
as do SQL. Um ndice complexo muito mais rpido de se usar do que um VIEW, porque h uma
sobrecarga muito pequena para manter um ndice em relao ao VIEW em servidor SQL. Tambm, os
ndices do Xbase so completamente atualizveis.
O Xbase tambm tem o conceito de 'relacionamentos' que so bem diferentes do conceito de
'relacionamentos' do SQL. As relaes do Xbase so similares aos JOINS do SQL. Estas relaes so
sempre baseadas em ndices e um ndice utilizado por uma relao o equivalente em Xbase a uma chave
externa do SQL. As relaes do Xbase so mais difceis de usar que as junes do SQL, mas so
totalmente controlveis pelo programador e podem ser muito mais eficientes que as junes do SQL,
porque as relaes do Xbase so realizadas em nvel de aplicao e o trabalho necessrio em servidores
de dados Xbase enormemente reduzido.

2.1.3 Arquivos Fsicos

As diferenas dos arquivos dos sistemas usados pelos banco de dados SQL e Xbase, para que fisicamente
guardem dados, descendem naturalmente das plataformas nas quais eles foram primeiramente
implementados. Os bancos de dados SQL foram desenvolvidos para rodar em computadores
(mainframes) isolados, assim existe uma tendncia do banco de dados monopolizar toda a mquina. As
atuais implementaes do SQL requerem, tipicamente, um banco de dados a ser alocado, antes de
permitir que dados sejam armazenados nele. Quando estes arquivos pr-definidos ficam cheios, medidas
rpidas podem ser tomadas para evitar perda de novos dados. Somando-se a isto, alguns tipos de SQL
realmente trocam o sistema de I/O do arquivo no sistema operacional de suas mquinas para ganhar o
desempenho necessrio. Os banco de dados so, normalmente, um s arquivo contendo todas as tabelas,
ndices, informaes dos usurios em formato proprietrio. Os registros, em muitos arquivos SQL no
possuem tamanho fixo, o que adiciona bastante flexibilidade mas tambm uma grande sobrecarga quando
acessando dados. Para melhor desempenho, o sistema de arquivos requer sintonia fina efetuada pelo
administrador com base nas operaes realizadas pelo sistema.
Os arquivos de dados em Xbase so muito mais fceis de entender e simples de gerenciar. Cada tabela
(chamada .DBF devido a sua costumeira extenso) um arquivo separado, com o tamanho dos registros
j definidos. O tamanho de registro j definido permite que a posio de cada registro possa ser calculada

pela multiplicao do nmero de registros pelo seu tamanho mais o tamanho do header do arquivo.
Arquivos .DBF crescem a medida que os dados vo sendo includos em seu final fsico. Caso um DBF
contenha campos memo, os quais so formados por campos de tamanho varivel, utilizado um arquivo
separado contendo os dados do DBF. Os arquivos de ndices usados pelo bancos de dados Xbase esto em
arquivos separados que so construdos utilizando-se dados do DBF, mas que podem ser manipulados
separadamente se desejado. Por ser o Xbase um formato aberto, h uma grande variedade de ferramentas
e ambientes que podem utilizar arquivos Xbase.

2.1.4 Travamento (Locking)

Na atualizao de dados em um sistema de banco de dados multi-usurio, alguma forma de travamento de
registro (locking) deve ser empregada para assegurar que os dados no sejam corrompidos por dois
usurios que estejam atualizando o mesmo registro simultaneamente. A caracterstica vital do esquema de
travamentos a granulao, o que indica quais dados esto protegidos pelo travamento. Quanto menor for
a granulao, melhor o controle concorrente. Granulao grossa, entretanto, resulta em menor sobrecarga
de travamento a ser mantida pelo banco de dados. Em Xbase, os travamentos so para registros
individuais, que a unidade bsica do armazenamento de dados. Os travamentos do Xbase so gerados
pela aplicao que atualiza os dados e no pelo servidor. Os travamentos devem ser mantidos por um
servidor, mas as aplicaes Xbase tem controle total sobre os travamentos. Isto torna o travamento em
Xbase bastante flexvel e fcil de controlar em nvel de aplicao.
Muitas implementaes em SQL empregam esquemas de paginao de travamentos, porque os registros
no tm tamanhos pr-definidos. Devido ao travamento ser controlado pelo banco de dados, muitos
servidores SQL tem problemas com travamentos, o que no acontece no Xbase. Uma paginao de
travamentos pode sobrepor registros e um ndice de paginao de travamentos quase que certamente
sobrepor muitas chaves de ndices. Por causa desta granulao grossa, muitos servidores SQL
necessitam enderear o problema da indisponibilidade do usurio, que ocorre quando parte de um arquivo
de banco de dados travado por um usurio que est atualizando os dados, que fisicamente perto dos
dados que um segundo usurio est tentando atualizar. Este problema agravado por servidores multitarefas, que podem causar paralisao do sistema. A paralisao do sistema ocorre quando uma requisio
est esperando por outra requisio para destravar um recurso, mas a requisio que abriga o recurso
tambm est esperando pela primeira para destravar o outro recurso. Paralisao de sistema um
problema de difcil soluo, incrementando assim a complexidade na manuteno de bancos de dados
SQL.

2.1.5 Padronizao

O ponto fraco do Xbase tem sido a falta de padronizao do Xbase. O SQL tem mantido um bom
processo de padronizao, o que resultou no padro SQL-92, dentre outros. O Xbase falhou duas vezes
em sua padronizao, e atualmente os desenvolvedores continuam a liberar extenses proprietrias para o
formato de arquivo .DBF e para linguagens Xbase. Este processo resultou em uma evoluo Darwiniana
do Xbase, ou seja, gerou inmeros dialetos do Xbase. Esta situao certamente continuar a menos que
algum padro finalmente seja adotado.

2.1.6 Diferenas na Implementao

A ferramenta SQL tpicamente suporta procedimentos armazenados (stored procedures), que so cdigos
que efetuam rotinas especficas, executadas quando chamadas. Um procedimento armazenado
especializado um gatilho (trigger), ou seja, um procedimento armazenado que executado quando
ocorrerem eventos, tais como: delees, atualizaes ou incluses. Procedimentos armazenados so muito
teis porque o cdigo reside com o dado e gatilhos (triggers) garantem que os procedimentos
armazenados sero executados toda a vez que a tabela de dados for modificada. Algumas implementaes
em Xbase incluem procedimentos armazenados e gatilhos, mas os procedimentos armazenados do Xbase
no so to naturais como os do SQL.
O controle de transaes comeou com servidores SQL, e atualmente estes servidores permitem
comandos de transaes muito complexos e potentes. Pelo fato do SQL operar somente em blocos de
dados e necessitar de um servidor para efetuar todo o processamento, transaes so parte vital do
sistema. Como o Xbase comeou a utilizar plataformas mono-usurio e com atualizaes efetuadas de
maneira navegacional, as transaes foram menos naturais para o Xbase. O valor do controle de
transaes tem sido bem testado e atualmente muitas implementaes em Xbase suportam alguma
funcionalidade: begin transaction . rollback / commit.
Xbase carece do conceito de integridade referencial, delees em cascata e restries de colunas. Os dois
primeiros esto ausentes porque os dados do Xbase residem em arquivos separados sem nenhuma ligao
concreta entre eles. Enquanto o SQL freqentemente tem apenas um arquivo de dados, os bancos de
dados Xbase so conjuntos de arquivos separados. Estes dois conceitos adicionam sobrecarga
considervel em todas as operaes de gravao atravs do SQL e uma das muitas razes porque os
banco de dados SQL sejam to lentos quando comparados a seus primos Xbase. O Xbase pode
implementar restries por campo e algumas implementaes especficas assim o fizeram. Muitos,
entretanto, deixaram a validao de dados para as aplicaes que utilizam os dados, como ocorre em
muitas aplicaes SQL atualmente, em adio aos requisitos de verificao do servidor.
Pelo fato do SQL ter tido seu incio em grandes mainframes, segurana foi uma preocupao desde sua
concepo. Em contraste, o Xbase comeou em sistemas isolados (standalone) e a muitos sistemas multi-

usurios eram rodados em pequenas redes. Por causa desta arquitetura, implementaes em sistemas
Xbase tinham menos segurana que as em SQL. Os sistema em SQL normalmente possuem login e
tambm controle de acesso por arquivo. Existem caractersticas de segurana em algumas
implementaes em Xbase, mas a facilidade do Xbase tem ajudado a promover lentamente esta
implementao. Os esquemas de segurana em aplicaes Xbase apoiam-se tipicamente no computador
ou no sistema operacional da rede que roda a aplicao, para implementao de segurana.

2.1.7 Clientes e Servidores

Pelo fato do SQL ter comeado em computadores mainframe e o Xbase nos primeiros PCs , o conceito de
processamento distribudo tem sido bastante estranho para ambas linguagens. SQL sempre rodou em
servidores potentes. As estaes normalmente enviam solicitaes que so totalmente processadas no
servidor. Em contraste, o Xbase teve seu incio em computadores isolados. Ambos evoluram, o SQL tem
sido desenvolvido para deslocar o processamento para mltiplos servidores e os servidores Xbase tem
sido desenvolvidos para prover dados aos clientes.
A implementao do SQL muito complexa e cara. SQL requer servidor potente, administrador de dados
com dedicao total ou parcial para ajustar e monitorar o servidor. Recentemente, esforos tm sido feitos
para deslocar algum processamento, como lgica de negcios, para outros computadores, bem como
simplificar a administrao de servidor SQL. Este enfoque multi-camada no tem tido sucesso muito
abrangente, entretanto, devido aos servidores SQL serem muito complexos, os altos custos
computacionais do trabalho no so facilmente rateados.
Historicamente, o Xbase tem sido conhecido por ter problemas com desempenho e estabilidade, quando
mltiplos usurios compartilham os dados. Tipicamente, os dados Xbase so compartilhados atravs de
redes existentes. Mas, pelo fato de que cada cliente (estao) gravar diretamente nos arquivos de dados, a
queda de uma estao poder resultar em arquivos corrompidos. O trfego de rede pode se tornar um
problema, pois grandes arquivos so transferidos para muitas estaes. Nos ltimos anos, entretanto, o
Xbase tem sido revolucionado pela soluo cliente/servidor. A arquitetura cliente/servidor resolve os
problemas histricos do Xbase, eliminando corrupo e problemas de desempenho. Xbase encaixa-se
muito bem na arquitetura cliente/servidor porque o Xbase pode permitir mais processamento a ser
distribudo para estaes do que o SQL. muito mais fcil para uma estao solicitar um skip para o
prximo registro em um ndice do que executar uma consulta (query) no SQL. Por causa desta
distribuio lgica e por causa da simplicidade do conceito do Xbase, o cliente/servidor Xbase pode ser
mais rpido do que o do SQL. Devido ao servidor ter que trabalhar menos, ele no necessita ser potente
ou ser servidor dedicado. Ainda, por causa da simplicidade dos arquivos e sistemas Xbase, o
administrador no precisa supervisionar diariamente o servidor.

2.1.8 Concluso
O SQL a maior exploso terica na histria da teoria de banco de dados. A linguagem SQL
extremamente fcil de utilizar e muito poderosa para consulta (query) de dados relacionais. Para
implementar a teoria, as instalaes de servidores SQL so implementadas em sistemas potentes e
complexos. Anlise em dados atravs de linguagem SQL expressa acesso a complexas informaes de
uma forma parecida com a linguagem natural.
O Xbase um modelo muito mais simples do que o SQL. Os dialetos do Xbase so fceis de serem
integrados em linguagem de computador e o Xbase faz com que a atualizao de dados seja
extremamente fcil. Xbase tambm gasta muito menos recursos do que o SQL. Em grande parte devido a
sua simplicidade, as implementaes em Xbase so tipicamente mais rpidas e fceis de manter do que
configuraes SQL. Implementaes de cliente/servidor Xbase distribuem suavemente o processamento
entre os computadores clientes e servidor.
A simplicidade e desempenho do Xbase o tornam a melhor opo para pequenos bancos de dados, e a
medida que estas aplicaes forem crescendo o Xbase pode evoluir suavemente para operaes
cliente/servidor. O Xbase tambm melhor escolha do que o SQL para sistemas com grandes volumes de
atualizaes e aplicaes que necessitem manipulao e pesquisa em registro isolado. As implementaes
em Xbase so mais rpidas e eficientes do que em SQL, mas perdem algumas das caractersticas dos
servidores SQL. Devido ao custo e complexidade do SQL, seus servidores so mais adequados para
instalaes onde os dados necessitam ser tratados em grande escala, e programadores de aplicao podem
se amparar nos administradores para controle e sintonia fina no acesso aos dados.

2.2 SQL Server

2.2.1 Sistemas de Arquivos X Bancos Relacionais
O acesso a informaes em sistemas de processamento de dados que no utilizam Sistemas Gerenciadores
de Bancos de Dados (SGBDs), feito pelo acesso seqencial a um ou mais arquivos. Cabe ao
desenvolvedor criar mecanismos de recuperao da informao. Com a utilizao de um SGBD, porm, o
acesso fica diferente: pede-se as informaes ao gerenciador de banco de dados e elas so devolvidas pelo
mesmo.
O processo pode ser comparado a uma compra em uma loja de departamentos e uma compra em uma loja
de autopeas, que normalmente funcionam por processo diferentes. No primeiro caso, o cliente dirige-se
loja, procura por todas as sees, encontra o produto desejado e efetua a compra. No segundo, o cliente
pede ao balconista o item desejado e este entrega-o. No caso da compra em loja de departamentos, o
trabalho todo do cliente, sendo este responsvel inclusive pelas especificaes necessrias (fazer a
escolha certa). J na loja de autopeas, o balconista assume toda a responsabilidade pela entrega da
mercadoria desejada.

2.2.2 Entidades, relacionamentos e atributos

Quanto mais organizadas estiverem as informaes no Banco de Dados, mais fcil ser a conversa com
o Gerenciador de Banco de Dados.
Para isso, criou-se um modelo chamado Modelo de Entidades e Relacionamentos, do qual fazem parte
trs elementos:

Entidades
Uma entidade um objeto de interesse do qual podem ser colecionadas informaes. Elas so

representadas por tabelas. Exemplos: tabela de clientes; tabela de pedidos de clientes. [SQL2000]

Relacionamentos
As entidades podem ser relacionadas entre si pelos relacionamentos. Por exemplo: relacionamento entre a
entidade de clientes e a entidade de pedidos ( clientes fazem pedidos).

Atributos
Atributos so as caractersticas das entidades. [SQL2000] So representadas pelas colunas das tabelas.
Por exemplo: nome, endereo do cliente.

Uma das colunas de uma tabela uma primary key (chave primria). Isso indica para o gerenciador de
banco de dados que uma coluna (ou um conjunto de colunas) deve ter um valor nico para identificar a
linha inteira. O gerenciador faz ento o controle para que no entrem duas linhas com o mesmo valor na
coluna que primary key.
A figura a seguir demonstra o relacionamento entre tabelas utilizando-se chaves primrias (PK) e
estrangeiras (FK).

Pedidos se relacionam aos Clientes, atravs do campo cliente da tabela de pedidos. Esse campo tambm
denominado chave estrangeira (foreign key). Isso garante o que denominado integridade referencial: ou
seja, no pode haver inconsistncia nas linhas que esto associadas nas tabelas. Por exemplo: o
gerenciador no permite que clientes que tenham pedidos sejam removidos da tabela clientes, nem que
pedidos sejam realizados por clientes inexistentes.
2.2.3 Linguagem SQL (Strutured Query Language)
O SQL uma linguagem estruturada para manipulao de dados. padronizada para os bancos de dados
relacionais, mas cada gerenciador pode possuir uma extenso prpria dessa linguagem.
Como no exemplo do pedido de compra para o funcionrio da loja de autopeas, cada comando no SQL
um pedido de busca ou alterao de dados para o gerenciador do banco de dados. Quem vai executar
propriamente o comando o gerenciador.
O Microsoft SQL Server
Trata-se de um Sistema Gerenciador de Bancos de Dados, Relacionais, SGBDR, que funciona
unicamente sob sistema operacional Windows NT.
Para trabalhar com esta ferramenta a Microsoft fornece o ISQL, tanto em interface DOS quanto em
interface Windows. Alm disso, podemos nos comunicar com o banco a partir de APIs do Windows,
fazendo uso da camada de comunicao DB-Library, ou via ODBC. A interface com o usurio pode ser

construda em Visual Basic ou Visual C++, para acesso atravs da DB-Library (que d total controle
sobre as funes do banco), ou via VB, VC++, Visual Fox Pro, Access, Excel, Word, para acesso via
ODBC. Tambm podemos utilizar o acesso atravs de protocolo TCP/IP e linguagem HTML,
caracterizando aplicaes de INTRA/INTER/EXTRANET; o acesso ao banco propriamente dito, entre a
camada de conexo a bancos de dados e o Web Server, ser realizado via ODBC.
O Microsoft SQL Server foi originalmente baseado no Sybase SQL Server X, quando da verso 4.2. Na
verso 6 a Microsoft implementou modificaes visando fazer uso de caractersticas multitarefa do
Windows NT.
2.2.4 Bancos de dados (DATABASES)
Uma vez instalado o SQL Server so criadas automaticamente quatro databases:
a)

master

b) model
c)

tempdb

d) msdb
Depois, poderemos criar e instalar nossos prprios bancos de dados livremente, os quais sero bancos de
dados de usurio.
Embora ambos os tipos de bancos de dados (sistema e usurio) armazenem dados, o SQL Server utiliza os
bancos de sistema para operar e gerenciar o sistema. O catlogo de sistema, por exemplo, consiste
unicamente de tabelas armazenadas no banco de dados master.
A figura a seguir ilustra os bancos de dados no SQL Server.

Figura 02

Vejamos a funo de cada um dos bancos de sistema.

O banco de dados Master
Controla os bancos de dados de usurios e a operao do SQL Server, por isso os dados armazenados em
suas tabelas so crticos e deve-se sempre manter back up atualizado. Ocupa inicialmente cerca de 17
Mbytes, mantendo:
a)

contas de login;

b) processos em andamento;
c)

mensagens de erro do sistema;

d) databases armazenados no servidor;

e)

espao alocado a cada database;

f)

locks ativos;

g)

databases disponveis e dispositivos de dump;

h)

procedimentos de sistema, que so primariamente utilizados para administrao.

O banco de dados master contm 13 tabelas de uso compartilhado com o sistema, conhecidas como
Catlogo do Sistema ou Dicionrio de Dados, que so:
1.

syscharsets - cdigos de pgina que estabelecem quais caracteres esto disponveis e sua ordem de

classificao;
2.

sysconfigures - variveis de ambiente configurveis;

3.

syscurconfigs - variveis de ambiente configurveis;

4.

sysdatabases - bancos existentes no servidor;

5.

sysdevices - referncia fsica aos dispositivos e bancos do servidor;

6.

syslanguages - entrada para as lnguas conhecidas pelo servidor;

7.

syslocks - quais so os locks ativos;

8.

syslogins - contas de usurios;

9.

sysmessages - mensagens de erro do sistema;

10.sysprocesses - processos em andamento

11.sysremotelogins - contas de acesso remoto, para conexo entre dois servidores;
12.sysservers - servidores remotos;
13.sysusages - espao em disco disponibilizado para cada banco de dados (relaciona-se com sysdatabases
e sysdevices).
O banco de dados Model

Fornece um prottipo (template) para um novo banco de dados. Contm as tabelas de sistema que sero
inseridas em cada banco de dados de usurio. As seguintes implementaes podem ser realizadas neste
database:
a)

tipos definidos pelo usurio (user datatypes), regras (rules), padres (defaults), stored procedures;

b) usurios que tero acesso a todos os bancos adicionados ao sistema (administradores);

c)

privilgios padro, notadamente aos usurios guest (guest accounts);

O tamanho padro deste banco de 1 Mbyte, e sua estrutura bsica pode ser vista na figura a seguir; as 18
tabelas mostradas sero sempre criadas em novos bancos de dados.

Este conjunto de 18 tabelas conhecido como Catlogo do Banco de Dados, e suas funes so as
seguintes (note que todas possuem o prefixo sys):
1.

sysalternates - possui uma linha para cada usurio mapeado para um banco de dados de usurio;

2.

syscolumns - possui uma linha para cada coluna em uma tabela ou view, e para cada parmetro em

uma stored procedure;

3.

syscomments - possui uma ou mais linhas para cada view, regra (rule), padro (default), trigger e

stored procedure que contenha uma declarao de definio;

4.

sysdepends - uma linha para cada procedure, view, ou tabela que seja referenciada por uma

procedure, view ou trigger;

5.

sysindexes - uma linha para cada clustered index, nonclustered index, e tabela sem ndices, mais uma

linha extra para cada tabela com informaes de textos ou imagens;

6.

syskeys - uma linha para cada chave estrangeira (foreign), primria (primary) ou comum (common);

7.

syslogs - armazena o transaction log;

8.

sysobjects - uma linha para cada tabela (table), viso (view), stored procedure, regra (rule), trigger,

padro (default), log e objeto temporrio (somente tempdb);

9.

sysprocedures - uma linha para cada viso (view), stored procedure, regra (rule), trigger, padro

(default);
10.sysprotects - mantm as informaes de permisses de usurio;
11.syssegments - uma coluna para cada segmento;
12.systypes - uma linha para cada datatype definido pelo usurio ou fornecido pelo sistema;
13.sysusers - uma linha para cada usurio permitido no database;
14.sysreferences - uma linha para cada constraint de integridade referencial criada (PK-FK, Chave
primria, chave estrangeira);
15.sysconstraints - informaes sobre cada constraint criada;
As ltimas trs tabelas so usadas para manter informaes sobre replicao de dados.
16.sysarticles - contm a article information para cada artigo criado para replicao;
17.syspublications - contm uma linha para cada publicao criada;
18.syssubscriptions - contm uma linha para cada subscrio de um subscription server.
O banco de dados Tempdb
Providencia um espao de armazenamento para tabelas e outras aes temporrias ou intermedirias, tais
como resultados que envolvam a clusula GROUP BY, ORDER BY, DISTINCT e cursores (CURSORS).
Possui as seguintes caractersticas:
a)

criado automaticamente no DEVICE MASTER (ateno, DEVICE e DATABASE so coisas

diferentes);
b) seu contedo apagado quando o usurio fecha a conexo, exceto para tabelas temporrias globais;
c)

quando o banco parado (stoped) seu contedo apagado completamente;

d) seu tamanho padro de 2 Mbytes.

e)

pode ser colocado em memria RAM.

O banco de dados MSDB

Providencia suporte ao servio SQL Executive Service (o qual fornece servios de schedulle de tarefas,
replicao, gerenciamento de alertas). Possui as seguintes tabelas de sistema:
a)

sysalerts - armazena informaes sobre todos os alertas definidos por usurios;

b) sysoperators - informaes sobre os operadores;

c)

sysnotifications - relaciona quais operadores devem receber quais alertas;

d) systasks - mantm informaes sobre todas as tarefas definidas por usurios;

e)

syshistory - informaes a respeito de quando um alerta e uma tarefa foram executados, se com

sucesso ou falha, identificao do operador, data e hora da execuo;

f)

sysservermessages - mensagens sobre as operaes relacionadas ao servidor.

2.2.5 Localizao dos bancos de dados

Os bancos de dados ficam armazenados em arquivos fsicos que recebem o nome de DEVICES. Um
DEVICE ocupa sempre a quantidade de disco que for a ele destinada, independentemente da existncia ou
no de bancos de dados em seu interior e independentemente da taxa de ocupao destes databases. Ou
seja, mesmo vazio ele ocupar a poro de disco a ele destinada com seu arquivo. A figura a seguir
demonstra esta caracterstica.

Voc pode observar que existe neste exemplo um banco de dados instalado no drive C: (o disco rgido do
equipamento), o qual contm um arquivo chamado NOMEARQ.DAT, que fisicamente ocupa 500 Mbytes
do disco. Porm, dentro deste DEVICE, que recebe o nome lgico de TESTE, existe somente um banco
de dados, de nome lgico MEUBANCO, o qual ocupa somente 40 Mbytes do espao disponvel.
2.2.6 Stored Procedures
Stored procedures so objetos do banco de dados que contm uma srie de comando SQL Padro, que
tem por objetivo facilitar e agilizar o trabalho com o banco. [SQL2000] Podem ser de sistema ou criadas
pelo usurio. Por exemplo, poderemos ter uma stored procedure para atualizar dados no, outra para
retornar valores, outra para deletar um determinado conjunto de dados, etc.
Os procedimentos armazenados em uma sp so pr-compilados, de maneira que sua execuo, em
comparao com a execuo de comandos que realizem a mesma tarefa, mais rpida.
So usadas tanto para obter dados como para modific-los, mas no ambos na mesma sp. Sua sintaxe
verificada na primeira vez que so executadas, quando so compiladas e armazenadas em cache. Portanto,
chamadas subsequentes a uma mesma sp sero ainda mais rpidas que a primeira.
Podem ser utilizadas em mecanismos de segurana: uma pessoa poder possuir direitos de execuo de
uma sp, mesmo no possuindo permisses sobre as tabelas e views que ela referencia. Assim, por
exemplo, poderamos liberar o acesso a uma sp que calcula o total de salrios de um determinado setor,
pesquisando para isso todos os salrios indivduais deste setor; mas a pessoa que tivesse acesso execuo
desta sp no teria acesso tabela de salrios propriamente dita. Como resultado, nosso usurio hipottico

poderia conhecer o total de salrios de cada departamento sem jamais ter contato com salrios
individuais.
As stored procedures de sistema que usaremos so: (note que todas comeam com sp_).
SP_HELP

Fornece um relatrio dos objetos de um database.

SP_HELPDB

Fornece um relatrio dos databases existentes.

SP_HELPTEXT Lista o texto correspondente a uma stored procedure e de outros

objetos.
SP_HELPSQL

Exibe informaes a respeito de declaraes (comandos) SQL, stored

procedures e outros tpicos.

SP_HELP
Quando utilizada sem parmetros, lista todos os objetos do database atual:
SP_HELP

Se for passado para esta sp o nome de uma tabela, lista todos os objetos da tabela, ou seja, exibe suas
caractersticas.
SP_HELP authors

SP_HELPDB
Fornece uma lista dos databases.
SP_HELPDB

SP_HELPTEXT
Lista o texto correspondente a uma sp e de outros objetos.
SP_HELPTEXT sp_help

Note que, como a stored procedure SP_HELP est armazenada no database master, ser necessrio
alternar para este banco antes de iniciar o comando, caso contrrio ser visualizada a mensagem de erro a
seguir, indicando que o objeto no foi encontrado no database em uso.

SP_HELPSQL
Exibe informaes a respeito de declaraes (comandos) SQL, stored procedures e outros tpicos.
Caso no seja passado um parmetro, a sp SP_HELPSQL exibir uma janela com informaes:
SP_HELPSQL

Para passar como parmetro o comando sobre o qual se necessita de ajuda, devermos pass-lo entre aspas,
pois caso contrrio surgir uma mensagem de erro. As aspas podero ser simples ou duplas, desde que
ambas (incio e fim) sejam do mesmo tipo. Para maior clareza, e com fins de padronizao, prefira aspas
simples.
SP_HELPSQL select

2.2.7 Acesso via Intranet / extranet / Internet

Acessar informaes atravs da utilizao de navegadores, seja no ambiente de uma Intranet, de uma
Extranet ou da Internet, uma tendncia tecnolgica, devido facilidade de uso, e em muitos casos de
implementao e facilidade de atualizao, entre outras vantagens.
A Intranet um ambiente interno empresa, como exemplificado a seguir.

J no caso da Internet, o que muda que os acessos sero permitidos a todo e qualquer usurio em
qualquer parte do mundo, conforme exemplificado na figura a seguir.

Em ambos os casos utiliza-se um servidor dotado do sistema operacional Windows NT e acompanhado do

Microsoft Internet Information Server, IIS, que o servidor de servios Internet (gerencia servios de ftp,
gopher e www). Nestes exemplos assumiu-se que o banco de dados que est disponvel para os usurios,
via net, o SQL Server; mas na verdade qualquer outra ferramenta que suporte o protocolo ODBC poder
ser utilizada (Access, Sybase, Informix, Oracle, ...).

Interessa-nos em especial o servio www, e o acesso a bancos de dados

via protocolo HTTP. O acesso s informaes contidas no servidor
feito de maneira relativamente simples. A partir da figura a seguir,
veremos como isto realizado.

Como podemos observar, o navegador (web browser) comunica-se com o servidor (web server)
utilizando o protocolo HTTP, o qual portado no TCP/IP. O servidor, ao receber uma comunicao
inicial envia como resposta uma seqncia HTML, atravs da qual o navegador efetua a formatao da
pgina e mostra-a ao usurio.
Opcionalmente podem ser enviados ao servidor comandos adicionais, anexados ao endereo. Na figura a
seguir exemplifica-se isto atravs do envio de um comando para execuo da library add.dll, qual sero
passados dois argumentos

O Microsoft IIS poder ainda executar scripts cgi, bastante comuns em aplicaes Internet.

Para entendermos o que ocorre para que um usurio possa acessar informaes em um banco de dados
SQL Server (ou em outro que aceite conexes ODBC, como o Access), vamos basear-nos na figura a
seguir.

Todo o gerenciamento da comunicao com a Internet efetuada pelo

IIS. Para conectar-se a um banco de dados ele utiliza-se do IDC,
Internet Database Conector, o qual integrado ao IIS e efetua a
conexo atravs do protocolo ODBC, possibilitando assim acesso a
uma ampla gama de databases.
Antes de prosseguirmos, devemos ter em mente que realizada uma
checagem de segurana antes que comandos e/ou acesso sejam
efetivamente executados, de maneira a manter a integridade e sigilo
dos dados. A segurana do IIS integrada do Windows NT, deixando
para este todo o gerenciamento de usurios, contas e direitos de
acesso.

Exemplo prtico
Vamos construir uma pequena aplicao de banco de dados, em que
utilizaremos um browser como front end.
Nossa aplicao ser formada por uma tabela, na qual poderemos cadastrar um nome, um estado e um
cdigo, conforme a estrutura mostrada a seguir:
CREATE TABLE cadastro (
numero int IDENTITY (1, 1) NOT NULL ,
nome varchar (40) NULL ,
estado char (2) NULL DEFAULT ('PR'),
codigo int NOT NULL
)
Para acessar esta tabela simples, criaremos um acesso conforme mostrado a seguir; uma vez cadastrado,
deveremos oferecer uma lista para consulta e possibilidades de alterao.

Quando as informaes forem submetidas ao IIS, este ir

realizar uma consulta no arquivo de conexo indicado pelo
mtodo submit do formulrio, descobrindo ento a qual
banco de dados dever se conectar. Uma vez conectado ao
banco, ser realizada a query passada pelo arquivo de
conexo, que tambm passou os valores de campos
recebidos do formulrio. Realizada a consulta, o IIS ir
utilizar o arquivo de modelo para montar uma seqncia de
comandos HTML correspondentes pgina que ser
enviada ao usurio. Desta maneira o browser enxergar
HTML puro.
Vejamos como ficar nosso esquema de navegao:

Pgina INICIAL

Agradecimento

Arquivo: HTML

Arquivo: HTX

Tela para alterao dos dados

Lista

Arquivo: HTX
Arquivo: HTX

Teremos uma tela inicial, escrita em HTML padro que conter um FORM. Uma vez preenchido o
formulrio e submetido ao servidor, atravs do arquivo IDC, no mostrado acima, ser realizada a
insero dos dados no database, e enviada uma tela de agradecimento ao usurio. Desta tela, o usurio
ter possibilidade de conectar-se com o servidor para realizar uma consulta s informaes cadastradas.
Ser novamente utilizado um arquivo IDC, o qual usar um novo arquivo de template, do tipo HTX, para
enviar os dados (Lista) ao usurio. Nesta tela de resultados o usurio poder escolher qualquer um dos
itens existentes para proceder sua alterao. O campo correspondente ao nmero ser usado como chave
de pesquisa, quando da alterao, mas no aparecer na tela (dever estar com o atributo de invisvel).

2.3 - Banco de Dados Orientado a Objetos

2.3.1 - Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos
O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO)
teve origem na combinao de idias dos modelos de dados tradicionais e de linguagens de programao
orientada a objetos. No SGBDOO, a noo de objeto usada no nvel lgico e possui caractersticas no
encontradas nas linguagens de programao tradicionais, como operadores de manipulao de estruturas,
gerenciamento de armazenamento, tratamento de integridade e persistncia dos dados.

Os modelos de dados orientados a objetos tm um papel importante nos SGBDs porque, em primeiro
lugar, so mais adequados para o tratamento de objetos complexos (textos, grficos, imagens) e
dinmicos (programas, simulaes). Depois, por possurem maior naturalidade conceitual e, finalmente,
por estarem em consonncia com fortes tendncias em linguagens de programao e engenharia de
software. O casamento entre as linguagens de programao e banco de dados um dos problemas que
esto sendo tratados de forma mais adequada no contexto de orientao a objetos.
SGBDs orientados a objeto combinam conceitos a objeto com capacidade de bancos de dados e, portanto,
tm o potencial de fornecer poderosos repositrios para aplicaes avanadas de bancos de dados.

2.3.2 - Definio de SGBDOO

Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos (SGBDOO) podem ser definidos
como um banco de dados capaz de armazenar alm de dados, como nos Sistemas de Arquivos e estruturas
de dados nos Bancos de Dados Relacionais, outros tipos diferentes de dados que no podem ser
convertidos somente em arquivos lineares ou bidimensionais como tabelas, e sim um tipo especial de
objeto. A principal caracterstica de SGBDOO modelar estruturas complexas armazenando no somente
a estrutura de dados, mas tambm seu comportamento. Para tanto, tem-se a necessidade de Banco de
Dados Orientados a Objetos.
Os Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos foram uma das grandes idias
do incio dos anos 80. Contudo, at hoje, est em desenvolvimento e ainda no um modelo definido, por
isso pouco usado pelas empresas. No entanto, o surgimento cada vez maior de banco de dados no
convencionais para aplicaes especficas aumenta o valor e o interesse para a tecnologia orientada a
objeto.
2.3.3 - Outros Conceitos
Finalmente, h duas propriedades fundamentais para a construo de um SGBDOO: extensibilidade e
completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permita a
definio de novos tipos e no h distino entre os tipos pr-definidos e os definidos pelo usurio. A
segunda implica em que a linguagem de manipulao de um banco de dados orientado a objetos possa
exprimir qualquer funo computacional.
2.3.4 - Vantagens, Desvantagens e Comparativos de SGBDOO
Vejamos algumas vantagens e desvantagens de SGBDOO e comparativos com Banco de Dados
convencionais usados atualmente:

2.3.4.1 - Comparativo

Cada produto de banco de dados projetado para um segmento especfico e no generalizado,

independente de ser ou no convencional, o que no se aplica diretamente em SGBDOO.

Pesquisas revelam que bancos de dados relacionais representam 90% do mercado financeiro e
apenas 12% de todo processamento de dados feito em produtos relacionais.

A maior parte dos sistemas em funcionamento no mundo consiste em velhos sistemas de arquivos e
dados legados (sem estruturao dos dados).

Banco de dado relacional bidimensional (linha e coluna).

SGBDOO tem modelagem complexa de objetos da forma que eles existem, ao invs de tentar
esprem-los em uma estrutura bidimensional.

2.3.4.2 - Vantagens

As aplicaes Internet so particularmente adequadas para banco de dados de objetos, j que a

maioria das aplicaes so desenvolvidas em Java, que uma linguagem orientada a objeto.

SGBDOO ideal para as aplicaes mais populares.

Crescimento da Internet, videogames, aplicaes para multimdia e o desenvolvimento de banco de

dados distribudos que no se prestam ao modelo relacional esto trazendo o foco para SGBDOO
menos complexo do ponto de vista do desenvolvimento e utilizao.

Segue os princpios das atuais linguagens de programao.

2.3.4.3 - Desvantagens

SGBDOO no tem embasamento terico como o caso dos bancos de dados hierrquicos baseado na
metodologia de "rvore", em rede baseado em "grafo" e relacional em "matemtica dos conjuntos".
Porm, nem tudo que no tem embasamento terico intil, como o clculo numrico que utilizado
at hoje.

Poucos recursos de ferramentas grficas para desenvolvimento.

Instvel com relao a direcionamento de suas aplicaes, j que tudo se resume em objetos.

Linguagens para consultas de objetos so difceis e nem um pouco padronizadas.

Pouco explorado (tecnologia nova).

2.3.5 - Aplicaes de SGBDOO

A maioria das descries dos bancos de dados orientados a objeto os caracteriza como SGBD de
"prxima gerao" para aplicaes avanadas. Tradicionalmente, estas aplicaes avanadas incluram
projeto auxiliado por computador (CAD), manufatura auxiliada por computador (CAM) e escritrios
inteligentes, o que inclui automao de escritrios e documentao de imagens.
2.3.6 - Concluso
Os bancos de dados orientados a objetos ainda esto amadurecendo, so mal-entendidos e difceis de usar.
Mas esto ganhando aceitao, graas ao explosivo, e um tanto especulativo, crescimento da Internet e da
multimdia. Os fabricantes que fazem citaes sobre as caractersticas de objetos acrescentadas a seus
produtos so como os fabricantes no relacionais de vrios anos atrs, que fizeram afirmaes falsas
sobre caractersticas relacionais.
O modelo de banco de dados de objetos e o modelo relacional coexistem porque so projetados para
aplicaes diferentes. Dito de outra forma: no se deve adaptar os dados ao banco de dados. Deve-se
escolher o tipo de banco de dados e o produto com base no tipo dos dados e na forma como os usurios
finais os acessaro, pois no existe at o presente momento um SGBD compatvel para aplicaes
diversificadas.
O SGBDOO Jasmine, mesmo sendo inexato, um dos mais prximos a ser adequado no momento, para
abordagem de banco de dados orientado a objetos, enquanto o advento da orientao a objeto para banco
de dados no for propcia para um pleno desenvolvimento e aplicao.
Mesmo encontrando-se em processo de evoluo os SGBDOO's ainda apresentam pontos fracos que
devem ser trabalhados.

3 - Selecionando um banco de dados

3.1 Como escolher um banco de dados
H oito reas chaves a examinar antes de comprar um banco de dados de objetos:

Suporte a linguagem - quais as linguagens necessrias: Java C++, OQL? Algumas linguagens
proprietrias so mais velozes que OQL, mas um produto que utilize uma linguagem padro ser
mais flexvel e portvel.

Escalabilidade - qual o maior banco de dados que o produto suporta? Qual o maior banco de
dados j pronto e em funcionamento usando o produto? Quantos usurios acessam o banco de
dados de uma s vez?

Segurana - como determinada a segurana - por usurio, grupo, ou ambos?

Backup e recuperao - como o produto lida com backup e recuperao?

Transaes - como banco de dados lida com registro, recuperao e estorno de transaes?

Mtodos - como os ODBMS armazena mtodos? Para ser um verdadeiro ODBMS, ele dever
armazen-los no prprio banco de dados.

Classes de colees - com quais classes de colees o banco de dados lida? ODMG, Java e
diversas bibliotecas de classes de objetos, notavelmente STL definiriam certas colees de classes
comuns. O uso de classes de colees padronizadas aumenta a portabilidade e a flexibilidade.

Suporte e treinamento - que tipo de suporte e treinamento o fabricante oferece? Por quanto
tempo ele treinar a equipe do comprador?

Um projetista de banco de dados relacional pode usar uma ferramenta de diagramao

entidade/relacionamento para verificar matematicamente se o projeto est na forma terceira normal. Um
projetista de ODBMS nem sequer tem um conceito similar a formas normais para seus objetos. O
problema das ferramentas est sumindo, o Jasmine, da Computer Associados, um exemplo de ambiente
de desenvolvimento muito bom.
Hoje, todo mundo se confunde com os bancos de dados relacionais estendidos, objeto-relacionais e os
bancos de dados de objetos (puros). O maior problema do ODBMS puro seu nome, o termo deveria ser
banco de objetos (objectbase), ao invs de banco de dados de objetos, porque o objetivo no armazenar,
manipular e recuperar dados dentro de um objeto, mas sim armazenar, manipular e recuperar os prprios
objetos. Os bancos de dados de objetos puros permitem consultas mais simples sobre dados complexos.
Um banco de dados de objetos puros tem mtodos, classes e outras coisas que caracterizam o modelo
orientado a objetos no ncleo do banco de dados. Os objetos so ativos, diferente dos
Relacionais que so passivos, e preciso um programa hospedeiro para fazer alguma coisa com eles. No

se deve confundir ODBMS com produtos relacionais estendidos e objeto-relacionais. Eles so projetados
para solucionar um conjunto de problemas diferente. Usar um banco de dados objetos puros para
armazenar dados relacionais como manter as peas dos automveis na forma de carros inteiramente
montados e desmontar toda a frota quando preciso contar os parafusos que existem no estoque. O
usurio acaba perguntando se essa a forma mais eficiente de se fazer um inventrio.
Os ODBMS no tm uma linguagem padro, portanto eles no so bons para desenvolvimento srio. Essa
sabedoria uma verdade convencional, mas no de fato. Nos prximos anos, ela pode se tornar falsa,
enquanto o processo de padronizao ISSO estava em andamento, o Object Database Management Group
(ODBMG), um grupo de fabricantes de ODBMS, comeou a tentar padres para bancos de dados de
objetos fora da estrutura ISO. O ODMG produziu um padro para uma linguagem de consultas para
ODBMS em 1.993, sob o nome OQL. Vrios fabricantes j concordaram em da suporte ao OQL.
Os bancos de dados de objetos esto em amadurecimento, so mal entendidos e difceis de usar, mas esto
ganhando aceitao, graas ao explosivo, e um tanto especulativo , crescimento da Internet e da
multimdia (voz, texto, grficos).
Uma advertncia: a passagem para a tecnologia de objetos pode ser difcil, por causa dos pesados
investimentos financeiros e humanos em tecnologia relacional. Projetos envolvendo um banco de dados
de objetos demoraro mais tempo com uma equipe sem experincia. Mesmo para quem estiver lidando
com equipe experiente, o projeto demorar mais ser mais dispendioso por causa da inerente
complexidade da tecnologia de objetos. Quem estiver preparado para isso, estar pronto para um banco de
dados objetos.

3.2 Modelo de banco de dados DATAWAREHOUSE

Datawarehousing ( sistema e bancos de dados projetados para anlise de comportamento e tendncias de
negcio).
Esquea tudo o que se diz sobre Datawarehousing. Essa melhor maneira de preparar-se para entender
como construir este sistema de W.H.Innon voltado, principalmente para gerentes e analistas de sistemas.
Os armazns de dados no so feitos de programas e mquinas, mas de um extenso trabalho de anlise e
depurao de dados.
Para muitos profissionais, a obra de Innon mostrar que seu conhecimento pode ter-se tornado obsoleto.
que ao contrrio dos sistemas tradicionais, os projetos de Datawarehousing partem da implantao para
chegar as necessidades do usurio.
Quem possui experincia em desenvolvimento de sistemas ir, com certeza, encontrar situaes
familiares. Os programas extratores so um caso tpico. J na dcada de 70 antes que o termo

Datawarehousing ganhasse fama, gerentes pediam a programadores que enviassem relatrios e arquivos
resumidos, com dados extrados de grandes de dados corporativos.
Depois de explorar as origens do Datawarehousing, possvel montar passo a passo um projeto completo,
melhor dizer ms a ms, pois o trabalho envolvido digno de Hrcules, dado a necessidade de filtragem e
conciliao de todos os dados e sistemas de empresa. Mas como o prprio Innan diz, se a empresa esperar
condies favorveis para a implantao do Datawarehousing, ela nunca o far.
Um exemplo atual do poder de um Datawarehousing:
Mais do que uma expresso, se transformou em um bordo repetido a cada duas frases por todos os
funcionrios da NCR Corporation, em todas as suas apresentaes pblicas. O exemplo partiu do prprio
Chief Executive Officer (CEO) e chairman, Lars Nybergn, na abertura da Partners, a conferncia anual de
usurios da empresa, realizada entre os dias entre os dias 5 e 9 de outubro, em San Diego, na Califrnia, e
que reuniu cerca de 700 clientes vindos de todas as partes do mundo.
A NCR est direcionada a se tornar na indiscutvel lder mundial em Datawarehousing, no s para os
bancos e a indstria. Mais e mais os sistemas de Datawarehousing esto se tornado cruciais para todas as
empresas que prestam servios a cliente. A sua capacidade de prever one-to-one vai tornar essa
tecnologia, pouco tempo, no um luxo, mas uma necessidade para todos os negcios que esperam se
manter competitivos, disse Nyberg ao traar a estratgia da empresa para os prximos trs anos.
Para alcanar a meta de ganhar liderana, a NCR tomou trs providncias. A primeira foi tornar o seu
sistema de gerenciador de banco de dados Teradata um produto mais aberto, capaz de rodar em diversas
plataformas e o primeiro passo port-lo para Windows NT . Isso vai acontecer, segundo Nyberg, at o
fim do ano, de forma que a nova verso esteja disponvel, comercialmente, no incio de 98. E o NT,
prometeu tambm o chairman, ser a plataforma fundamental de todas a solues da NCR para ambientes
que exijam alta disponibilidade e para comrcio eletrnico, assim como para solues especficas para
bancos e comrcio.
Outra medida da NCR foi o lanamento de duas novas plataforma de hardware, integrante a famlia de
servidores WorldMark, voltada especificamente para solues Datawarehousing, e que o Aberdeen
Group, empresa de pesquisa de Boston, definiu como servidores mainframe.
O modelo 4700 construdo com quatro processadores Pentium Pro de 200 Mhz, por mdulo, cada um
com 512 cache de memria. possvel colocar at dois mdulos em cada gabinete e, com oito mdulos
alinhados em cluster, se chega a uma plataforma capaz de suportar um sistema de Datawarehousing com
600Gb de dados.
O modelo 5150 pode ter at 128 mdulos conectados, suportando, assim, acima de 600Gb e at
100Terabytes.Os dois novos servidores podem rodar o gerenciador de bancos de dados Teradata, da

prpria NCR, para aplicaes Datawarehousing, e, ainda, o Informix XPS ou o Oracle Paralel Server para
processamento de transaes online. E, finalmente, a terceira providncia da NCR para garantir a
liderana em projetos de Datawarehousing foi celebrar uma aliana com a SAS Institute, segundo a qual
as duas empresas vo combinar suas expertises em Datawarehousing e data mining para prover solues
completas e integradas para clientes de todos os portes e em todos os setores da economia.

4 Concluso
Para que uma organizao cresa no mercado empresarial e saiba lidar com novas tecnologias, ela deve se
preocupar especialmente, com o modo de organizar suas informaes.
Um meio eficaz de gerenciamento de informaes, somente realizada atravs de um Banco de Dados.
Alm de interligar todo trabalho da organizao, reduz custos, elimina duplicao de tarefas, permite uma
previso de crescimento da empresa e ajuda na elaborao de estratgias.
Fazendo uma anlise dos exemplos de banco de dados, podemos perceber que necessrio uma busca de
novas implementaes em seu desenvolvimento, visto que para cada modelo de banco de dados existe
vantagens e desvantagens.
Dando um maior enfoque ao banco de dados corporativo, foi verificada sua importncia na exatido,
rapidez com que as informaes devem ser conduzidas, alm da segurana ao usurio.
Concluindo a sua importncia, verifica-se a disponibilidade de filtrar todas as informaes de uma
organizao por meio de um banco de dados que realmente transmita segurana, qualidade e
competitividade.

Referncias Bibliogrficas
[AAM2000] Almanaque Abril 2000 Multimdia, Internet,2000
[CAD1990] The Committee for Advanced DBMS Function Third-Generation Database System
Manifesto SIGMOD. Record, set. 1990.
[CC1997] Joe Celko; Jackie Celko. Verdades e Mentiras sobre banco de dados de objetos. Byte Brasil,
So Paulo, v.6, n. 10, out. 1997.
[DES2000] Departamento de Engenharia de Sistemas, 2000. Site: http://www.densis.fee.unicamp.br/
[DSM1990] THE Committee for Advanced DBMS Function Third-Generation Database System
Manifesto SIGMOD. Record, set. 1990.
[DUN1993] Sheldon M. Dunn, Xbase Cross Reference Handbook. Alameda, CA: Sybex, Inc., 1993.
[FAU1994] ODBC 2.0 Programmer's Reference and SDK Guide. Redmond: Microsoft Press, 1994. Autor
Joe Faulhauber, engenheiro da equipe de Pesquisa e Desenvolvimento da Extended Systems
Inc.
[GW1994] James R. Groff and Paul N. Weinberg, LAN TIMES: Guide To SQL. Berkeley: McGraw-Hill,
Inc., 1994.
[ION1993] Interface Online - Julho 1993. Site: http://www.ipt.br
[KO1999] Henry F. Korth e Abraham Silberschatz: "Sistemas de Banco de Dados", Makron, 1999.
[LIM2000] Iremar Nunes de Lima, "Intranet CECOM", 2000, http://www.cecom.ufmg.br/~iremar/.
[LL2000] Srgio Lifschitz e Iremar Nunes de Lima, Arquiteturas de Integrao Web SGBD: um Estudo
do Ponto de Vista de Sistemas de Banco de Dados, 2000. Site: http://www.cecom.ufmg.br/ ~iremar/
publicacoes/ semish98html/semish98.htm
[SIL1994] S. D. da Silva: Sistemas de Banco de dados Heterogneos, Tese de Doutorado, Dept.
Informtica, PUC-Rio,1994.
[SQL2000] Apostila Microsoft SQL Server 7.0, 2000.
[WES1995] "A Comparison of Borland Interbase 4.0, Sybase SQL Server and Microsoft SQL Server."
Interbase Software Corporation Date, C.J. An Introduction to Database Systems. Addison-Wesley
Publishing, 1995.