UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE)

Banco de Dados

Sandra de Albuquerque Siebra

Volume 1

Recife, 2010
Universidade Federal Rural de Pernambuco

Reitor: Prof. Valmar Corrêa de Andrade

Vice-Reitor: Prof. Reginaldo Barros
Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho
Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski
Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire
Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira
Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena
Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos

Produção Gráfica e Editorial

Capa e Editoração: Allyson Vila Nova, Rafael Lira, Italo Amorim e Arlinda Torres
Revisão Ortográfica: Marcelo Melo e Elias Vieira
Ilustrações: Noé Aprígio
Coordenação de Produção: Marizete Silva Santos
Sumário

Apresentação.................................................................................................................. 4

Conhecendo o Volume 1................................................................................................. 5

Capítulo 1 – Banco de Dados: Por onde começar?........................................................... 7

Alguns Conceitos Básicos..................................................................................................8

Como era antes de surgirem os bancos de dados?........................................................10

O Sistema Gerenciador de Banco de Dados (SGBD).......................................................14

Estrutura Geral de um SGBD..........................................................................................17

Classes de Usuários de um Sistema de Banco de Dados................................................18

Alguns Exemplos de SGBDs............................................................................................19

Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados............................................. 27

E houve a evolução.........................................................................................................27

Primeira Geração dos Bancos de Dados.........................................................................28

Segunda Geração dos Bancos de Dados.........................................................................31

Terceira Geração dos Bancos de Dados..........................................................................32

Arquiteturas de Sistemas de Banco de Dados................................................................34

Abstração de Dados........................................................................................................41

Apêndice A – Novas Tendências e Perspectivas............................................................. 49

Classificação dos Bancos de Dados.................................................................................49

O que mais há por aí?.....................................................................................................53

Considerações Finais..................................................................................................... 59

Conheça a Autora......................................................................................................... 61
Apresentação
Caro(a) Cursista,
Seja bem-vindo(a) ao primeiro módulo do curso Banco de Dados. Neste primeiro módulo, vamos estudar
os fundamentos necessários para compreender o assunto que será visto durante toda a disciplina. Além disso, o
conteúdo deste primeiro módulo lhe ajudará a ter uma visão geral da disciplina como um todo e da importância da
mesma no contexto do curso.
Espero que goste e se empolgue com o assunto. Até porque, neste módulo, você vai perceber o quanto
Banco de Dados é uma área que está muito presente na sua vida.
Bons estudos!
Sandra de Albuquerque Siebra
Professora Autora

4
 Banco de Dados

Conhecendo o Volume 1
Neste primeiro volume, você irá encontrar o Módulo 1 da disciplina de Banco de
Dados. Para facilitar seus estudos, veja a organização deste primeiro módulo.

Módulo 1 – Fundamentos de Banco de Dados e Sistemas Gerenciadores

de Banco de Dados

Carga horária do Módulo 1: 15 h/aula

Objetivo do Módulo 1: Introduzir os principais conceitos e definições relacionados
à área de Banco de Dados, além de dar uma visão geral da evolução dos SGBDs.

Conteúdo Programático do Módulo 1

» Conceitos Básicos
» Sistemas de Banco de Dados
» Evolução dos Bancos de Dados
» Arquitetura dos Bancos de Dados
» Classificação dos Bancos de Dados
» Novas Tendências e Perspectivas

5
 Banco de Dados

Capítulo 1

O que vamos estudar neste capítulo?

Neste capítulo, vamos estudar os seguintes temas:

» Conceitos Básicos sobre Banco de Dados

» Conceitos Básicos sobre Sistemas Gerenciadores de Banco de Dados

Metas

Após o estudo deste capítulo, esperamos que você consiga:

» Identificar os principais conceitos relacionados à área de Banco de Dados

» Diferenciar um sistema de arquivos de um sistema de banco de dados

6
 Banco de Dados

Capítulo 1 – Banco de Dados: Por onde

começar?

Vamos conversar sobre o assunto?

“Você sabe o que é um banco de dados? Você saberia mensurar o quanto essa área
está presente na sua vida? Sabia que pode ser muito mais do que você imagina? Afinal, você
tem o seu cadastro aqui na UFRPE que está em um banco de dados. Você foi estudante de
outras instituições e deve estar no banco de dados delas. Se você tem uma conta bancária,
você está no banco de dados do banco ao qual sua conta pertence. Você está no banco
de dados da receita federal como contribuinte ou como isento, mas, se você é maior de
18 anos, você deve estar lá! Isso só para começo de conversa... porque deve haver muitos
outros bancos de dados dos quais você faz parte. Logo, só por ser uma área tão presente na
sua vida, a área de Banco de Dados já merece ser estudada, não acha? Fora isso, qualquer
sistema que você pensar em desenvolver na sua vida, deverá fazer uso de um banco de
dados e mesmo se você não desenvolver sistemas, mas utilizá-los no seu dia-a-dia, você
será, com certeza, um usuário de Banco de Dados. Então, que tal conhecer esses tais Bancos
de Dados mais a fundo? Começaremos a fazer isso nesse capítulo.”

Neste capítulo, vamos apresentar os conceitos básicos da área de Banco de Dados.

Como comentado acima, essa é uma área muito presente no nosso dia-a-dia e que ganha
ainda mais importância quando paramos para pensar que estamos vivendo na chamada
“Era da Informação”, onde o conhecimento adquirido a partir da avaliação das informações
é o maior bem de qualquer empresa ou instituição. E informações são obtidas a partir de
dados que precisam estar armazenados em algum lugar. Você poderia me perguntar: mas
dados e informações não são a mesma coisa? Não, não são. Vamos diferenciar.
Dado é um elemento que mantém a sua forma bruta (texto, imagens, sons, vídeos,
etc.) e ele sozinho não levará a compreender determinada situação. Ou seja, o termo
“Dado” envolve fatos, imagens, sons que podem ou não serem úteis para determinado
fim, eles apenas representam coisas do mundo real. Já a “Informação” é o conjunto de
dados coletados de forma a se tornarem aplicáveis a determinada situação, ou seja, sua
forma e conteúdo são apropriados para um uso específico. A informação não existe por
si só, ela é obtida através de uma interpretação realizada sobre um grupo de dados. Além
disso, ela necessita de uma situação ou objetivo que justifique a sua existência. Vamos dar
alguns exemplos. O nome de um cliente, o número de peças em um estoque, o número de
horas trabalhadas por um empregado e o valor total de um pedido são dados. Já o valor
total das vendas por mês de uma loja é uma informação que para ser obtida vai precisar
considerar uma série de dados (tais como, o mês de cada pedido e o valor total do pedido)
armazenados em algum lugar.
O Banco de Dados, geralmente, será esse lugar onde os dados estarão armazenados
e a partir do qual você irá extrair informações para finalidades diversas. Mas, finalmente,
qual a definição de Banco de Dados?

7
 Banco de Dados

Alguns Conceitos Básicos

Um Banco de Dados (também chamado por alguns autores de Base de Dados)
é uma coleção de dados relacionados, organizados e armazenados visando facilitar sua
posterior manipulação e a realização de consultas. Em outras palavras, um banco de dados
é uma coleção de dados interrelacionados, representando informações sobre um domínio
específico. Os tipos de coleções de dados que podem ser armazenados são ilimitados (ex:
dados de um produto, de um estudante, mapas, dados sobre genes humanos, etc.).
Realmente, um banco de dados (abreviado daqui para frente como BD) é um
modelo de uma determinada parte da realidade, geralmente denominada de Universo
de Discurso ou minimundo. Isso porque só devemos colocar no banco de dados as
informações do domínio que sejam relevantes para a resolução de um problema ou para
obter determinadas informações. Vamos dar um exemplo. Suponha que precisamos
criar um banco de dados para uma Livraria. O minimundo da Livraria englobaria diversas
características que a definem como, por exemplo, o seu nome, a sua localização, os dados
dos seus proprietários, os dados dos funcionários que trabalham lá, os dados dos livros
disponíveis e de qualquer outro produto que esteja sendo comercializado. Isso porque essas
informações são interessantes para serem armazenadas e, posteriormente recuperadas.
Porém, por exemplo, as cores das paredes da livraria, o material de que é feito o chão, não
são características relevantes para serem consultadas em um sistema, logo, não fariam parte
dos dados a serem armazenados no banco de dados. Logo, o minimundo será justamente
a especificação da parte do mundo real que é relevante para a implementação da livraria
(vide Figura 1) e deverá conter informações que caracterizem o domínio do negócio.

Figura 1 - O Mundo Real x MiniMundo

Um banco de dados pode ser criado e mantido por um conjunto de aplicações

desenvolvidas especialmente para esta tarefa (por exemplo, no caso da livraria, poderia
existir um Sistema Controle de Livraria para gerenciar o acesso ao Banco de Dados) ou por
um Sistema Gerenciador de Bancos de Dados (SGBDs ou DBMS – Database Management
System). Um SGBD é um pacote de software designado para guardar e gerenciar um banco
de dados. É ele que realiza a manipulação dos dados armazenados em um BD. O SGBD
tem uma gama de funções pré-implementadas que gerenciam as operações de inserção,
remoção, atualização e consulta dos dados armazenados.
O conjunto formado por um banco de dados mais as aplicações que o manipulam (o
SGBD) é chamado de Sistema de Banco de Dados (SBD). Pode-se definir esse sistema como
um ambiente cujo objetivo global é registrar e manter informação. A Figura 2 representa
o ambiente de um sistema de banco de dados, que interage com os programadores
(as pessoas que o desenvolveram) e com os usuários finais (as pessoas que o utilizarão).
Num primeiro nível, as pessoas interagem com os programas de aplicação (programas

8
 Banco de Dados

desenvolvidos em uma linguagem de programação como Java, C#, PHP, etc.), que foram
criados para os usuários finais e que, para acesso ao BD, fazem uso de uma linguagem de
consulta (linguagem própria para acesso ao banco de dados). Esta aplicação interage com
o SGBD, que possui programas responsáveis por processar as consultas e acessar os dados
armazenados, dentre outras funções. Por fim, num nível mais interno, encontra-se a base de
dados, separada em dois arquivos distintos:

» Um arquivo contendo a definição dos dados (informações sobre os dados ou

metadados) – este arquivo irá conter informações, como: qual o tipo do dado
armazenado, qual o tamanho dele, se ele pode ficar em branco ou não, etc.
» E outro arquivo contendo os dados propriamente ditos, ou seja, os dados
armazenados.

Figura 2 - Sistema de Banco de Dados

A separação da base de dados em dois arquivos distintos deve-se ao fato que,

geralmente, a estrutura (definição) dos dados altera-se pouco depois de criada e os dados
armazenados, costumam serem manipulados e alterados mais frequentemente. Vamos dar
um exemplo. Pode ser definido que serão armazenados no banco de dados a matricula, o
nome e o endereço de cada estudante. No arquivo de definição de dados, seria especificado
que um estudante seria representado por:

» Um campo chamado matricula do tipo numérico, de tamanho 6 e com

preenchimento obrigatório;
» Um campo chamado nome do tipo alfanumérico, de tamanho 50 e com
preenchimento obrigatório; e
» Um campo chamado endereço do tipo alfanumérico de tamanho 50 e com
preenchimento opcional.
Já no arquivo de dados armazenados, estaria o preenchimento dessa definição para
cada estudante cadastrado. Por exemplo, poderiam estar armazenados neste arquivo os
valores:

» 123456, “Ana Maria Gomes”, “Rua das Flores, 56”;

» 234567, “Jorge Tavares”, “Rua Vasco da Gama, 789”.
9
 Banco de Dados

Observe que os dados armazenados devem seguir a definição (tipo, tamanho, etc.)
especificada no arquivo de definição de dados. Observe também que, pela natureza dos
dados armazenados, eles tendem a ter vários valores para a mesma definição (ex: cada
estudante cadastrado obedece a mesma definição feita para um estudante) e eles são mais
variáveis que a definição dos dados, visto que, por exemplo, um estudante pode mudar de
endereço (ex: o endereço da estudante Ana Maria poderia ser modificado para Av. Abdias
de Carvalho, 52), mas a definição do endereço continuaria a mesma (um campo do tipo
alfanumérico de tamanho 50 e com preenchimento opcional). Dessa forma, por terem
naturezas distintas, é interessante manter estes dois arquivos separados.

Como era antes de surgirem os bancos de dados?

Antes de existirem os bancos de dados, qualquer sistema, programa ou aplicação
que precisasse armazenar e manipular dados fazia uso de um sistema de arquivos. Ou
seja, cada sistema, programa ou aplicação desenvolvido tinha seus próprios arquivos de
armazenamento dos dados. Geralmente, naquela época, os programas eram escritos
em respostas às necessidades, ou seja, iam sendo desenvolvidos na medida em que
as necessidades apareciam e muitas vezes eram desenvolvidos por programadores
diferentes. Qual a implicação disso? Diferentes Programadores pensam e programam de
forma diferente. Desse modo, os arquivos de cada programa desenvolvido poderiam estar
em formatos diferentes e poderiam ter sido criados usando linguagens de programação
diferentes. Qual o problema com isso? O problema com isso é que se uma mesma empresa
ou instituição desenvolve diversos sistemas, gradualmente, esses sistemas podem vir a ter
dados em comum. Vamos dar um exemplo: suponha uma fábrica que possui um Sistema
de Vendas, um Sistema de Produção e um Sistema de Engenharia (vide Figura 3). Cada
um deles teria seus próprios arquivos e nesses arquivos poderia existir em comum, por
exemplo, os dados de um produto, que por causa dessa organização precisaria ser replicado
em cada sistema de arquivos. E qual a consequência dessa replicação de dados dentro de
uma mesma fábrica?

Figura 3 - Exemplo de sistemas que fazem uso de um Sistema de Arquivos

A consequência é que essa redundância poderia acarretar inconsistência dos

dados, uma vez que a mesma informação poderia estar duplicada em diversos arquivos (no
exemplo, os dados do produto). Vamos dar um exemplo. Vamos supor que nos arquivos de
Vendas, eu atualizei o nome do produto 01 de Mesa para Cadeira. Se eu desejasse manter a
consistência, eu teria de entrar nos arquivos de Produção e de Engenharia e fazer a mesma
10
 Banco de Dados

atualização. Se não fizesse, os dados do produto na fábrica ficariam inconsistentes, pois

dependendo do sistema acessado o produto 01 poderia ser Mesa ou Cadeira. Ficou claro?
Além disso, a duplicação de dados em diversos sistemas de arquivos leva a um maior custo
de armazenamento (lembre, você está armazenando diversas vezes os mesmos dados) e
a necessidade de redigitação de dados (e esse trabalho repetitivo pode levar a erros, que
também geram inconsistências entre os dados). Adicionalmente, o uso de sistemas de
arquivos possui outros problemas tais como:

» Dificuldade do acesso a dados – a geração de informação pode surgir, durante o

tempo em que o sistema está em produção, sob diferentes aspectos. Cada requisição
de informação diferente, no sistema de arquivos, vai gerar a necessidade da criação
de um programa aplicativo, de uma nova consulta ou de um novo relatório. Dessa
forma, a recuperação de informação não é atendida de modo eficiente. Haveria
dificuldade em apagar informações dos sistemas. Poderia novamente ocorrer casos
de incosistência, onde um produto poderia ser deletado dos arquivos de Vendas,
mas não dos outros dois arquivos (Engenharia e Produção).
» Isolamento dos dados – os dados estão armazenados em arquivos distintos, que
não possuem qualquer tipo de relacionamento direto, e ainda, podem conter
diferentes formatos para o mesmo dado. Por exemplo, o código do produto nos
arquivos de venda poderia ser representado só por números e nos arquivos de
Produção por letras e números.
» Problemas de integridade – fica difícil manter restrições de integridade
automaticamente. E o que são essas restrições de integridade? Seriam checagens de
determinadas condições a serem feitas pelo sistema sobre os dados armazenados
(por exemplo, a quantidade de produtos em estoque não pode ser inferior a um
valor X). Essas restrições teriam de ser mantidas pelo sistema, implicando em
implementação do código apropriado para fazer esse tipo de checagem em CADA
UM dos sistemas afetados. O problema seria que a cada inclusão de uma nova
restrição de integridade, um novo código deveria ser escrito EM CADA SISTEMA
para poder mantê-la, já que cada sistema trabalha com um diferente sistema de
arquivos.
» Problemas de segurança - Nem todos os usuários do sistema devem estar
autorizados a ver/acessar todos os dados armazenados. Porém, uma vez que os
programas de aplicação são inseridos no sistema como um todo, de forma aleatória
(à medida que a necessidade surge, lembra?) é difícil implementar e garantir a
efetividade de regras de segurança.
» Anomalias no acesso concorrente - a melhora de desempenho em um sistema
pode ocorrer pela execução simultânea de diversas operações. Geralmente, nos
sistemas de arquivos, esta melhoria seria difícil de implementar sem levar a danos
na consistência dos dados. Ou seja, seria difícil permitir que múltiplos usuários
possam ter acesso aos dados ao MESMO TEMPO. Vamos dar um exemplo. Considere
um sistema bancário (com a existência de contas correntes, agências, transações
bancárias, etc) e a seguinte situação: suponha que o saldo de uma conta bancária
C1 seja 500 reais. Se dois clientes retiram fundos desta conta C1 AO MESMO
TEMPO (acesso concorrente à conta C1), um estado inconsistente pode ocorrer se
na execução das duas instâncias do programa de débito, ambos os clientes lerem o
saldo inicial original e retirarem, cada um, seu valor correspondente, e seja então
armazenado o valor restante. Instanciando o problema:
1. Ambos leem o valor do saldo 500;
2. Um retira 50 reais (resultando 450 reais) e o outro 100 reais (resultado 400

11
 Banco de Dados

reais) – lembre que ambos estão realizando a operação em cima dos 500 reais
iniciais que foi lido;
3. Dependendo de qual execução do programa de débito registre o saldo restante
primeiro, o valor do saldo da conta será 450 ou 400 reais, quando, na verdade,
deveria ser 350 reais.
Outros problemas existentes são:

» A definição das estruturas dos arquivos está inserida no próprio código dos
programas, sistemas ou aplicativos, dificultando a manutenção;
» Compartilhamento de um arquivo por vários programas fica comprometido. Há a
necessidade de duplicar a definição das estruturas dos arquivos nos programas;
» Podem existir arquivos e programas de um mesmo sistema desenvolvidos, de
forma isolada, por diferentes programadores de forma diferentes e, até mesmo, em
linguagens de programação diferentes.
Justamente a necessidade de resolver diversos desses problemas motivou a criação
dos bancos de dados e dos sistemas gerenciadores de banco de dados. Com eles, os dados
só necessitam ser armazenados uma única vez e passam a ser acessados por todos os
sistemas (vide Figura 4)

Figura 4 - Exemplo de Sistemas fazendo uso de um Banco de Dados

Que tal recapitular com outras palavras, de forma resumida, o que foi
apresentado?
No início da computação, os programas tinham o único objetivo de armazenar e
manipular dados. Esses programas gravavam seus dados em arquivos em disco, segundo
estruturas de dados próprias (vide Figura 5). Programas que não conhecessem a estrutura
dos dados não podiam utilizar os dados.

Figura 5 - Programa acessando seu arquivo

12
 Banco de Dados

Se vários programas precisassem compartilhar os dados de um mesmo arquivo, eles

todos teriam que conhecer e manipular as mesmas estruturas de dados (vide Figura 6). Ou
seja, toda a definição dos dados deveria estar dentro dos programas que os manipulariam.

Figura 6 - Vários programas acessando os dados tinham de conhecer sua estrutura

Se um programa precisasse realizar alguma mudança na estrutura de dados, todos

os programas que acessam os dados tinham que ser alterados, mesmo que a alteração
ocorresse em dados não manipulados pelos outros programas. Isso gerava um grande
problema: Como garantir a unicidade das estruturas de dados entre os diversos programas
devido à existência de redundâncias? Para evitar esse problema, colocou-se um sistema
intermediário que deveria conhecer a estrutura de dados do arquivo manipulado; que
deveria fornecer apenas os dados que cada programa necessitasse e deveria armazenar
adequadamente os dados de cada programa (vide Figura 7).

Figura 7 - Acesso ao arquivo através de um sistema intermediário

Agora, através do uso desse sistema intermediário:

» Os programas passariam a enxergar apenas os dados que lhes interessam.

» Os programas não precisariam conhecer os detalhes de como seus dados estão
gravados fisicamente.
» Os programas não precisariam ser modificados se a estrutura de dados que utilizam
não for modificada.
» As alterações ficariam concentradas nesse sistema intermediário.
Com o tempo, esse sistema intermediário passou a gerenciar vários arquivos (vide
Figura 8) e a essa coleção de arquivos foi dado o nome de Banco de Dados e ao sistema
intermediário deu-se o nome de Sistema Gerenciador de Banco de Dados (SGBD).

13
 Banco de Dados

Figura 8 - SGBD gerenciando o acesso aos arquivos usados pelos programas

Que tal? Ficou mais claro? Espero que sim! Vamos detalhar agora os SGBDs...

O Sistema Gerenciador de Banco de Dados (SGBD)

Vimos anteriormente neste capítulo que um Sistema de Banco de Dados (SBD)
é o conjunto formado por um banco de dados (BD) mais as aplicações que o manipulam
(o SGBD). Assim, um SGBD é uma coleção de programas que habilitam usuários a criar e
manter um banco de dados. Ele é um software de propósito geral, que facilita o processo de
definição, construção e manipulação de um banco de dados.

› Definição do banco de dados envolve especificar estruturas e tipos de dados para

serem gravados no banco de dados, com uma descrição detalhada de cada tipo de
dado.
› Construção do banco de dados é o processo de consistir e gravar inicialmente
dados no banco de dados.
› Manipulação de um banco de dados inclui funções como consulta por dados
específicos e atualização para refletir as alterações no mundo real.
Quais características esse software deve ter? Vamos apresentá-las a seguir:

» Independência de Dados - consiste na capacidade de tornar as características físicas

dos dados (como localização, estrutura e tamanho) transparentes para a aplicação.
Ou seja, os SGBD devem ser dotados de recursos que possibilitem a descrição das
estruturas de dados (layout de arquivos e/ou tabelas) de forma independente dos
procedimentos de manipulação (leitura e gravação) de dados no BD. Isto possibilita
tornar transparente para os programas que acessam o BD as alterações que, por
ventura, venham a ocorrer nas estruturas de dados, como, por exemplo, o acréscimo
de um novo campo de informação ao banco. Da mesma forma, alterações em
lógicas de programas que acessam o BD não devem afetar as estruturas de dados
definidas no BD. Os SGBDs conseguem isso por fazer uso de SQL (Structured Query
Language), que possui grupos de comandos específicos e independentes para as
tarefas de criação e alteração de tabelas (DDL - Data Definition Language) e leitura e
atualização do BD (DML - Data Manipulation Language).
» Redução ou Eliminação de Redundâncias – Em um sistema tradicional de
controle de arquivos, cada usuário normalmente apresenta seus próprios arquivos
armazenando o conjunto de dados que é de seu interesse e, nestes casos, é comum
ocorrer redundância de dados. Esta redundância consiste no armazenamento de
uma mesma informação em locais diferentes. Por exemplo, o nome do funcionário
poderia estar nos arquivos dos Sistemas de Cadastro, de Folha de Pagamento e
de Avaliação em uma empresa, se esses não tivessem uma única base de dados
compartilhada. A redundância é danosa para o ambiente computacional, pois ela
14
 Banco de Dados

leva a um aumento de esforço computacional para realizar a atualização dos dados

redundantes e aumento do espaço necessário para o armazenamento destes dados.
Porém, o problema mais sério é que a representação dos dados desta forma pode
tornar-se inconsistente, pois duas informações podem aparecer em locais distintos,
mas apresentando valores diferentes. Dessa forma, um SGBD deve prover meios
para que seja possível o controle da redundância de dados nos diversos arquivos
administrados por ele. Para isso, os dados que eventualmente são comuns a mais
de um sistema devem ser compartilhados por eles, fazendo-os acessar um mesmo
banco de dados. Além disso, deve haver uma centralização da definição dos dados
num Dicionário de Dados ou Catálogo, que vai servir como base para a operação do
SGBD.
» Eliminação de Inconsistências – Geralmente causada pela redundância de dados,
a inconsistência ocorre quando um mesmo campo tem valores diferentes em
sistemas diferentes. Por exemplo, o estado civil de um funcionário pode estar como
solteiro no Sistema de Cadastro e como casado no Sistema de Folha de Pagamento.
Isto pode ocorrer quando esta pessoa atualizou o campo em um sistema e não o
atualizou em outro. Quando o dado é armazenado em um único local (no caso, o
banco de dados) e compartilhado pelos sistemas, este problema não ocorre.
» Compartilhamento dos Dados - Permite a utilização simultânea e segura de um
dado, por mais de uma aplicação ou usuário (através do tratamento de concorrência),
independente da operação que esteja sendo realizada. O compartilhamento de
dados visa diminuir a redundância de dados. Para implementar o compartilhamento
de dados, é necessário que o SGBD possua um competente sistema de segurança,
para que se estabeleça a privacidade de dados, através de mecanismos de restrição
de acesso.
» Tratamento de Concorrência – para que seja possível um compartilhamento
simultâneo dos dados armazenados no banco de dados, o SGBD implementa o
tratamento de concorrência. Ou seja, o SGBD deve possuir mecanismos para a
identificação e tratamento dos acessos concorrentes, para garantir a consistência
das informações do BD no sentido de sua veracidade. Os sistemas de bloqueio
(LOCK) e desbloqueio (UNLOCK) são os mecanismos utilizados para evitar que
uma informação que está sendo manipulada por um determinado usuário U1, seja
alterada por outro usuário U2. Enquanto o primeiro usuário U1 estiver acessando
um dado no BD, o segundo usuário U2 não terá acesso ao mesmo ou o terá apenas
para leitura e receberá um aviso do SGBD de que a informação está sendo acessada
por outro usuário e pode estar sendo modificada. Saiba Mais

» Privacidade dos Dados – um SGBD deve fornecer um subsistema de autorização e 1

Sistemas de LOG e
segurança (por exemplo, através de senhas e sistemas de LOG e AUDIT1, o qual é AUDIT registram dados
utilizado pelo DBA (DataBase Administrator ou Administrador do Banco de Dados) sobre as operações
para criar “contas” e especificar as restrições destas contas; o controle de restrições que são efetuadas
no BD, tais como:
se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao data, hora, usuário,
SGBD. Dessa forma, torna-se possível definir, para cada usuário, o nível de acesso comando que foi
a ele concedido (leitura, leitura e gravação ou sem acesso) a tabela e/ou campo. utilizado, campo
que foi afetado pelo
Este recurso impede que pessoas não autorizadas utilizem ou atualizem uma comando, etc.
determinada tabela ou campo, bem como que utilizem softwares inadequados ao
seu perfil.
» Segurança dos Dados - o SGBD deve oferecer meios que resguardem a base de
dados nos casos de falha de programa, equipamento ou acidentes. Também deve
ser possível que alterações indevidas feitas pelos usuários durante a operação dos
aplicativos sejam desfeitas sem prejuízo da coerência dos dados. A segurança física
15
 Banco de Dados

dos dados poderá ser obtida a partir de utilitários e aplicativos que os fabricantes
colocam em seus produtos, visando facilitar o trabalho de proteção aos dados
contra danos físicos, que podem ser causados por falhas de hardware ou queda
da rede. Nessa linha, destacam-se as rotinas de backup (cópias de segurança dos
dados armazenados) e a gravação com espelhamento (você ter duas máquinas
diferentes com o banco de dados instalado e periodicamente ele ser replicado de
uma máquina para outra, para se uma sair do ar, a outra já assumir).
» Padronização dos Dados - Permite que os campos armazenados na base de
dados sejam padronizados segundo um determinado formato. Por exemplo, para
o campo sexo poderia ser definido e apenas permitido usar os caracteres “M” ou
“F”. Padronizar os dados pode facilitar a comunicação e a cooperação entre vários
departamentos, projetos e usuários. Padrões podem ser definidos para formatos
de nomes, elementos de dados, telas, relatórios, terminologias, etc. O DBA pode
obrigar a padronização em um ambiente de base de dados centralizado, muito mais
facilmente que em um ambiente onde cada usuário ou grupo tem o controle de
seus próprios arquivos e software;
» Controle de Transações: Uma Transação é um conjunto de operações sobre o
BD que devem ser executadas integralmente e sem falhas ou interrupções. Caso
contrário, devem ser desfeitas. Todo SGBD deve realizar o controle das Transações.

TRANSAÇÃO – é uma coleção de operações que desempenha uma função lógica única dentro de
uma aplicação do sistema de banco de dados. Uma transação deve ter as seguintes propriedades
que formam a sigla ACID:

A – Atomicidade: ou todas as operações envolvidas na transação ocorrem, ou nenhuma delas deve

ter efeito sobre o banco de dados. Assegurá-la é tarefa do SGBD.

C – Consistência: ao final da execução da transação a consistência dos dados no banco deve ter sido
mantida. Assegurá-la é tarefa do programador.

I – Isolamento: uma transação deve ter sua execução realizada de forma isolada em relação à
execução de outras transações.

D – Durabilidade: depois que uma transação é executada com sucesso, as modificações por ela
realizadas devem ser mantidas no sistema, mesmo na ocorrência de falhas. Assegurá-la é tarefa
do SGBD.

O conceito de transação é importante porque qualquer sistema computacional está sujeito

a falhas. Por isso, em muitas aplicações é crucial assegurar que, uma vez detectada uma falha,
os dados sejam salvos em seu último estado consistente. Para exemplificar, suponha que você
deseje transferir R$ 50 da conta A para a conta B. Se ocorrer falha durante sua execução, é possível
que os R$ 50 sejam debitados da conta A sem serem creditados na conta B, criando um estado
inconsistente no banco de dados. É essencial para a consistência do BD que ambos (débito e
crédito) ocorram ou nenhum deles seja efetuado. Isto é, a transferência de fundos deve ser uma
operação atômica (uma transação), ou seja, deve ocorrer por completo, ou não ocorrer.

» Integridade dos Dados - A integridade de dados refere-se a mecanismos que estão

disponíveis nos SGBD, que garantem a consistência dos dados armazenados no
SGBD, segundo parâmetros de validação, especificados no momento de criação do
BD, em conjunto com as estruturas de dados. Ou seja, esses mecanismos garantem
que o conteúdo dos dados armazenados no Banco de Dados possua valores
coerentes ao objetivo do campo, não permitindo que valores absurdos sejam
16
 Banco de Dados

cadastrados. Por exemplo: Não permite que uma data final seja menor do que uma
data inicial.
» Representação de Relacionamento Complexo entre Dados: uma base de dados
pode possuir uma variedade de dados que estão interrelacionados de muitas
maneiras. Um SGBD deve ter a capacidade de representar uma variedade de
relacionamentos complexos entre dados, bem como recuperar e modificar dados
relacionados de maneira fácil e eficiente
» Possibilidade de Múltiplas Interfaces: Vários usuários representam também
necessidades diversas no que se refere aos tipos de interfaces fornecidas pelo
SGBD. Interfaces para consultas de dados, programação, e interfaces baseadas em
menus ou em linguagem natural são exemplos de alguns tipos que podem estar
disponíveis.

Estrutura Geral de um SGBD

A estrutura geral de um SGBD envolve, em síntese, os componentes apresentados
na Figura 9 e descritos a seguir.

Saiba Mais

2
Comandos DML
(Data Manipulation
Language) incluem
comandos para inserir,
atualizar, consultar e
excluir dados do banco
de dados.

Figura 9 - Estrutura Geral do SGBD

Saiba Mais
Pré-compilador da DML - converte comandos da DML2 embutidos em um aplicativo
para chamadas de procedimentos normais na linguagem hospedeira do BD. O pré- 3
DDL (Data Definition
compilador precisa interagir com o processador de consultas para gerar o código apropriado. Language) ou
linguagem de definição
Compilador DDL3 - converte comandos da DDL em um conjunto de tabelas de dados inclui
contendo metadados (“dados sobre dados”), que são armazenados no Dicionário de Dados. comandos para a
criação e manutenção
Processador de consultas - traduz os comandos em uma linguagem de consulta da estrutura da base
para instruções de baixo nível que o gerenciador do banco de dados pode interpretar. Além de dados.
disso, o processador de consultas tenta transformar uma requisição do usuário em uma

17
 Banco de Dados

forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa
estratégia para executar a consulta.
Gerenciador do banco de dados - fornece a interface entre os dados de baixo
nível armazenados no disco e o Código Objeto de Aplicativos e as consultas submetidas ao
sistema (após passarem pelo Processador de Consultas).
Gerenciador de arquivos - gerencia a alocação do espaço na armazenagem do disco
e as estruturas de dados usadas para representar a informação armazenada no disco. É o
gerenciador de memória quem traduz os diversos comandos DML em comandos de baixo
nível para atuar sobre os dados armazenados na base de dados.
Adicionalmente, diversas estruturas de dados são requeridas como parte da
implementação do sistema físico, incluindo:
Arquivos de dados - armazenam o banco de dados propriamente dito.
Dicionário de dados - armazena informações sobre a estrutura do banco de dados.
Também chamado de catálogo de dados, contém os metadados, isto é, as informações a
respeito dos componentes do banco de dados: tabelas, índices, procedimentos, restrições
e outros.

Classes de Usuários de um Sistema de Banco de

Dados
Um Banco de Dados pode apresentar diversos usuários cada qual com uma
necessidade em particular, e com um envolvimento diferente com os dados do BD. Você
sabe quais são eles? Não? Que tal conhecer um pouco mais? Os usuários podem ser
classificados nas seguintes categorias:

» Administrador de Bancos de Dados (DBA – DataBase Administrator) - em

qualquer organização onde muitas pessoas compartilham diversos recursos, existe
a necessidade de um administrador chefe (sempre existe o que vai ficar à frente,
não é?) para supervisionar e gerenciar estes recursos (em um ambiente de base
de dados, o recurso primário é a própria base de dados e os recursos secundários
são o SGBD e os demais softwares relacionados. A administração desses recursos é
de responsabilidade do DBA. Ele é responsável, entre outras coisas, por autorizar
acesso à base de dados e coordenar e monitorar seu uso. Adicionalmente, ele
é responsável por sanar problemas, tais como quebra de segurança ou baixo
desempenho do BD.
» Projetista de Bancos de Dados – também chamado de analista de banco de dados,
possui a responsabilidade de identificar os dados a serem armazenados no BD e
pela escolha da estrutura apropriada a ser utilizada para armazená-los. Ou seja, é
a pessoa responsável pelo projeto de construção e utilização do BD, envolvendo
as tarefas de definição de quais dados deverão ser construídos e como eles serão
construídos. Pode existir um único projetista ou um grupo deles e ele(s) irá(ão)
interagir com outras classes de usuários, tanto os analistas e programadores, como
os chamados usuários finais do sistema, a fim de obter a visão dos dados que cada
um possui, integrando-as de forma a se obter uma representação adequada de
todos os dados.
» Usuários Finais: existem profissionais que precisam ter acesso à base de dados para
consultar, modificar e gerar relatórios. A base de dados existe para estes usuários.
Existem algumas categorias de usuários finais:

18
 Banco de Dados

› Usuários ocasionais: ocasionalmente fazem acesso à base de dados, mas eles

podem necessitar de diferentes informações a cada vez que fazem acesso.
Eles podem usar uma linguagem de consulta sofisticada para especificar suas
requisições e são, tipicamente, gerentes de médio ou alto nível;
› Usuários comuns ou paramétricos: estes usuários realizam operações padrões
de consultas e atualizações, chamadas transações permitidas, que foram
cuidadosamente programadas e testadas. Estes usuários constantemente
realizam recuperações e modificações na base de dados;
› Usuários sofisticados: incluem engenheiros, analistas de negócios e outros
que procuraram familiarizar-se com as facilidades de um SGBD para atender
aos seus complexos requisitos;
› Analistas de Sistemas e Programadores de Aplicações: são os Engenheiros
de Software, aquelas pessoas que determinam as necessidades dos usuários
finais e desenvolvem as especificações para as transações que irão atender a
estas necessidades. Os programadores das aplicações são as pessoas que irão
realmente implementar estas especificações, criando os programas que irão
constituir o sistema e fazer acesso ao BD. Adicionalmente, os programadores
também são os responsáveis por testar os programas criados.
Muitos de nós nos enquadramos nessa última categoria de usuários (usuários
finais).
Podem existir ainda alguns profissionais de apoio ou suporte para realizar tarefas
específicas como tirar backup (cópia de segurança) dos dados armazenados no Banco de
Dados.

Alguns Exemplos de SGBDs

Alguns dos principais SGBDs disponíveis no mercado nos últimos anos são:
Saiba Mais
» Oracle é um sistema comercial, mas possui versões gratuitas para uso acadêmico
e/ou doméstico (em casa). Ele foi o primeiro Banco de Dados Corporativo (cliente/ 4
PL/SQL (Procedural
servidor) possuindo grande variedade de distribuições (para Macintosh, Windows, Language/Structured
Query Language)
Linux, FreeBSD, Unix) e para computadores de grande porte. Foi um dos primeiros
é uma linguagem
a fazer parte do mercado Web. Nele a linguagem padrão é a SQL, mas possui procedural que é
também uma linguagem própria para desenvolvimento de aplicações, a PL/SQL4. extensão da linguagem
A participação do Oracle no mercado de Banco de Dados é bastante acentuada, padrão SQL para o
SGBD Oracle, a fim
principalmente em grandes empresas e em conjunto com sistemas de médio e de permitir que a
grande porte. É um SGBD robusto e seguro, quando bem administrado. Além da manipulação de
base de dados, a Oracle desenvolve uma suíte de desenvolvimento chamada de dados seja incluída
em unidades de
Oracle Developer Suite, utilizada na construção de programas de computador
programas.
que interagem com a sua base de dados. Site Oficial em http://www.oracle.com/us/
products/database/index.htm

» Microsoft SQL Server – é o banco de dados comercial da Microsoft. Ele é um dos

principais concorrentes do Oracle. Tem como uma das vantagens o fato de, por
ser um produto Microsoft, se integrar nativamente com produtos e linguagens
da Microsoft (talvez seja esse o fator que o popularizou!). As versões atuais
são independentes e operam exclusivamente sobre Windows. É um software
proprietário e pago, como a maioria dos produtos Microsoft. Algumas empresas
que usam o MS SQL Server e são consideradas casos de sucesso no Brasil são o
Hipercard, o Banco Itaú e a ANEEL (vide: http://www.microsoft.com/brasil/servidores/
19
 Banco de Dados

sql/default.mspx). Site Oficial em http://www.microsoft.com/sqlserver/2008/en/us/

» IBM DB2 - é o Sistema Gerenciador de Banco de Dados Relacionais (SGDBR)

produzido pela IBM. Existem diferentes versões do DB2 que rodam desde num
simples PDA (computador de mão), até em potentes mainframes e funcionam
em servidores baseados em sistemas Unix, Windows ou Linux. DB2 é vendido
em diversos tipos de edições ou licenças. Pela escolha de uma versão com menos
recursos, a IBM evita que os consumidores paguem por coisas que não iriam usar.
Informações em http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
» Interbase - é um sistema gerenciador de banco de dados relacionais da Borland.
Foi incluído, pela Borland, nas suas ferramentas de desenvolvimento (Delphi, C++
Builder e JBuider). Ele pode ser instalado em sistemas operacionais Microsoft
Windows, Linux, Mac OS X e Sun Solaris. Além de não ser pesado é relativamente
rápido e suporta bancos de dados de grande tamanho (maiores que 2 Gigabytes).
Em 2000 a Borland liberou o código da versão 6.0, mas as posteriores voltaram a
ter licença proprietária. Desta versão 6.0 foi criado o Banco de Dados Open source
Firebird. Site Oficial: http://www.embarcadero.com/products/interbase-smp
» Firebird - Nascido de uma iniciativa da Borland em abrir o código do InterBase
6.0, este sistema é open source e esbanja versatilidade e robustez. O Firebird
(algumas vezes chamado de FirebirdSQL) roda em Linux, Windows, Mac OS e uma
variedade de plataformas Unix. A Fundação FirebirdSQL coordena a manutenção e
desenvolvimento do Firebird, sendo que os códigos fonte são disponibilizados sob o
CVS da SourceForge. O produto é bastante seguro e confiável, suportando sistemas
com centenas de usuários simultâneos e bases de dados com dezenas/centenas
de gigabytes. Há suporte gratuito na Internet através de vários sites. O Firebird é
amplamente utilizado em todo o mundo, com a maior base de usuários no Brasil,
Rússia e Europa. Site Oficial em http://www.firebirdsql.org/
» MySQL - é, atualmente, um dos bancos de dados mais populares, com mais de 10
milhões de instalações pelo mundo. Ele possui versões para Windows, Solaris, Unix,
FreeBSD, Linux e é gratuito para uso não-comercial. Algumas das empresas mais
famosas que fazem uso deste banco estão: NASA, Banco Bradesco, Dataprev, HP,
Nokia, Sony e Lufthansa. O MySQL é usado principalmente para desenvolvimento
WEB como servidor de dados para comércio eletrônico. Passou a ser considerado
um SGBD de verdade (com conceito de transação) a partir da versão 5. Site Oficial
em http://www.mysql.com/
» PostgreSQL - é um sistema gerenciador de banco de dados objeto relacional
(SGBDOR), desenvolvido como projeto de código aberto. Ele é um dos SGBDs
(Sistema Gerenciador de Bancos de Dados) de código aberto mais avançados, é
grautito e tem uma boa aceitação no mercado. Originalmente concebido para
rodar em Linux, ele possui versões para Windows. É usando, principalmente, para
comércio eletrônico juntamente com linguagem PHP. O PostgreSQL é um projeto
open source coordenado pelo PostgreSQL Global Development Group. Site Oficial
em http://www.postgresql.org/
» Microsoft Access: é um banco de dados da Microsoft para uso em micros desktops
e não em servidores. Esta é a principal diferença dele para os demais bancos
SGBD como o Oracle, SQL Server e MySQL, por exemplo. Contudo, ele tem sido
muito usado em pequenas e médias empresas para armazenamento de dados em
pequenas quantidades. Agora, o MS Access não é considerado um SGBD completo,
por não possuir todas as características de um. Mas ele permite o desenvolvimento
rápido de aplicações que envolvem tanto a modelagem e estrutura de dados como
também a interface a ser utilizada pelos usuários. A linguagem de programação
20
 Banco de Dados

disponível no access é a Microsoft Visual Basic for Applications, igualmente a outros

produtos da série Microsoft Office. Maiores informações em: http://office.microsoft.
com/pt-br/access/default.aspx

Dos SGBDs listados acima vale ressaltar que o SQL Server e o Oracle tem versões
gratuitas, porém limitadas. O Firebird e o PostgreSQL são open source, o DB2 e o MS Access
são pagos (sendo que o Access já vem em algumas versões do pacote Microsoft Office) e o
MySQL é gratuito para desenvolvimento, mas pago para produção.
A escolha de qual SGBD usar depende muito do projeto sendo desenvolvido e do
quanto a empresa está disposta a investir para armazenamento dos seus dados. Um SGBD
gratuito e muito popular nos dias de hoje é o PostGreSQL e vários sistemas de instituições
públicas vêm adotando o mesmo. Já no mundo corporativo o Oracle tem sido um dos mais
adotados, por ser um dos mais robustos. Dos SGBDs citados, você já usou algum?

Considerações Finais

Apesar de todas as vantagens citadas anteriormente sobre um SGBD, há situações

em que deve-se ponderar sobre sua utilização, como por exemplo, o alto investimento
inicial e a possibilidade de compra de um novo hardware; ou a possibilidade de insatisfação
no desempenho geral do sistema que pode ser provocado pelas funções de segurança,
controle de concorrência, recuperação e manutenção de integridade dos dados. Dessa
forma, mesmo com todos os benefícios ainda existem situações em que você pode não
utilizar um SGBD, elas estão descritas no Quadro 1.

Quadro 1 - Usar ou não usar um SGBD, eis a questão!

Quando usar SGBD Quando não usar SGBD

Quando desejar obter:

» Controle de redundância
» Controle de consistência e integridade
» Acesso multiusuário
» Compartilhamento de dados
» Controle de acesso e segurança
» Controle de recuperação e restauração
» Realização de consultas eficientes 1
» Dados e aplicações simples, bem definidas
e estáveis (sem expectativas de mudança)
» Quando requisitos de tempo real não
puderem ser atendidos
» Não há necessidade de acesso
multiusuário aos dados

Conheça Mais

Neste capítulo, vimos apenas alguns conceitos básicos. Para obter mais informações
ou materiais diversificados para o que foi visto aqui, você pode proceder a uma pesquisa
usando o Google (www.google.com.br) com as palavras chaves “Banco de Dados” +
“Introdução”. Você vai ver que irá vir muito material. Entre eles: apostilas, notas de aula,
reportagens, etc.
Adicionalmente, gostaríamos de indicar o texto “Introdução a Banco de Dados”
dos professores Osvaldo Kotaro Takai, Isabel Cristina Italiano e João Eduardo Ferreira
(DCC-IME-USP), produzida em fevereiro de 2005. Eles elaboraram este texto para apoiar a
aprendizagem dos alunos nas disciplinas de introdução a Sistemas Banco de Dados do IME-
USP e ela pode servir para apoiar os seus estudos também. Ela está disponível em: http://
www.ime.usp.br/~jef/apostila.pdf

21
 Banco de Dados

Para quem tem curiosidade, uma comparação entre alguns SGBDs dos mais
utilizados pode ser encontrada em: http://www.microsoft.com/sqlserver/2008/en/us/compare.
aspx (apenas em inglês).

Se possível, leia também os capítulos introdutórios (geralmente capítulo 1 ou 1 e 2)

dos seguintes livros:

SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de

dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São
Paulo: Pearson Education do Brasil, 2005.
DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus,
2000.

Você Sabia?

O maior banco de dados do mundo se encontra no World Data Centre for Climate que é operado
pelo Max Planck Institute for Meteorology e o German Climate Computing Centre. Ele possui
cerca de 220 terabytes de dados acessíveis via Web (incluindo informações sobre pesquisas
climáticas e previsões do tempo) e 110 terabytes de dados sobre simulações climáticas. Além
disso, ainda há 6 pentabytes de dados adicionais armazenados em fitas magnéticas. Já imaginou
quanto dado é tudo isso?
Fonte: http://www.docstoc.com/docs/5628186/Top-Largest-Databases-in-the-World-We-all-collected

Aprenda Praticando

A seguir apresento algumas questões sobre banco de dados que fizeram parte das
provas de concursos diversos. Que tal praticar com elas?

Concurso TCE (Técnico em Informática) - CESGRANRIO - 2007 - RO

Uma coleção de dados interrelacionados e uma coleção de programas para acesso
a esse banco de dados é um(a):
a) SQL;
b) SGBD;
c) Banco de Dados;
d) SBD;
e) Tabela.
Concurso STF (Analista Judiciário – Tecnologia da Informação) – CESPE - 2008
A execução de transações de maneira concorrente é a única causa do surgimento
de inconsistências dos dados armazenados em um banco de dados. Assim, a
responsabilidade pela consistência dos dados é única e exclusiva do componente
de controle de concorrência.
⃝ Certo ⃝ Errado

22
 Banco de Dados

Concurso Petrobrás (Técnico em Informática) - CESGRANRIO - 2008

Atomicidade é uma propriedade de transação de um SGBD relacional que garante
que:
a) uma transação seja realizada de forma independente de outras transações;
b) uma operação de uma transação seja efetuada de forma independente de outras
operações;
c) nenhuma operação de uma transação seja subdividida em tarefas menores pelo
SGBD;
d) todos os atributos manipulados por uma transação sejam atômicos;
e) todas as operações em um banco de dados, que fazem parte de uma transação,
sejam executadas ou nenhuma delas o seja.
Concurso Petrobrás (Analista de Sistemas Pleno - Especialidade Processos)
CESGRANRIO - 2006
A transação T1, pertencente a um sistema bancário
T1
e é definida pelas operações listadas na tabela ao lado. Ela é
1 Ler (A);
responsável pela transferência de R$ 30,00 da conta A para
2 A = A - 30; a conta B. Considere também uma transação T2 que esteja
3 Escrever (A); sendo executada simultaneamente a T1. Caso a transação
4 Ler (B)
T2 realize uma operação Escrever(B) após a execução da
operação 4 e antes da execução da operação 6 por T1, qual das
5 B = B + 30;
propriedades das transações estará sendo violada no banco de
6 Escrever (B) dados do sistema bancário?

a) Atomicidade;
b) Distributividade;
c) Isolamento;
d) Durabilidade;
e) Consistência.

Gabarito e Comentários

Questão 1: Resposta letra D. Um SGD é justamente o conjunto formado pela coleção

de dados interrelacionados (que é o BD) e os programas que o manipulam (que é o SGBD).
Questão 2: Resposta Errado. A redundância de dados também pode levar ao
surgimento de inconsistências. Dessa forma, a responsabilidade por manter a consistência
dos dados é do componente de controle de concorrência, mas também do controle de
redundâncias.
Questão 3: Resposta letra E. Atomicidade é justamente a propriedade (entre
as outras propriedades ACID das transações) que diz que ou tudo é executado ou nada é
executado.
Questão 4: Resposta letra C. Isolamento é justamente a propriedade que diz que
uma transação não pode interferir no que está sendo executado por outra transação, até
que ela acabe. Logo, T2 não poderia acessar a variável B que estaria sendo utilizada por T1.

23
 Banco de Dados

Atividades e Orientações de Estudo

Agora vamos exercitar o que foi estudado até agora. Assim sendo, faça as atividades
sugeridas a seguir. Lembre que exercitar vai lhe ajudar a fixar melhor o conteúdo estudado.
Mãos à obra!

Atividades Práticas

Responda as questões a seguir:

1. Quais as principais desvantagens de fazer uso de um sistema de arquivos

convencional em relação ao uso de banco de dados?
2. Quais as propriedades de uma transação?
3. O que são metadados? Dê exemplos.
4. Que problemas podem ser causados pela falta de padronização dos dados
armazenados?
5. Qual a importância do controle de redundância?

Sugestão para Atividade de Interação

Discuta com seus colegas, com o professor e o tutor sobre seu conhecimento sobre
Banco de Dados. Tenha como guia as seguintes questões:

1. Você já conhecia alguma coisa sobre o tema Banco de Dados? Se sim, o quê? E
como ficou sabendo (fez curso, leu sozinho, etc)?
2. Você já fez uso de algum banco de dados na prática? Se sim, qual(ais)? Em que
situação fez uso?
Participe, discuta, pergunte! Assim você pode aprender ainda mais!

Filmoteca: Cinema em Ação

Você saberia dizer em quantos bancos de dados você está cadastrado? Você
saberia mensurar a importância de ter seus dados íntegros, seguros, de forma a não serem
modificados por pessoas indevidas? Você saberia mensurar as consequências de ter seus
dados modificados ou apagados de alguns bancos de dados sem sua ciência? Essas e outras
questões são abordadas e levam a pensar no filme chamado “A Rede” (The Net) que tem
como atriz principal Sandra Bullock. Esse é um filme um pouco antigo, porém, mostra bem
como os dados armazenados em um BD podem ser importantes.

24
 Banco de Dados

Dica de Cinema

A Rede
Sinopse: Após receber um disquete com dados confidenciais, uma analista de sistemas passa a
viver um verdadeiro pesadelo, com seus dados sendo alterados nos computadores do governo
para que ela seja considerada uma criminosa.
Diretor: Irwin Winkler
Ano de Produção: 1995
Atores Principais: Sandra Bullock e Jeremy Northam.

Vamos Revisar?

Você estudou, neste capítulo, os conceitos básicos iniciais sobre banco de

dados (tais como: o que é um BD, um SGBD, um SBD, o que é dado, informação, etc). Foi
apresentado o cenário existente antes dos bancos de dados virem a ser utilizados (quando
eram usados sistemas de arquivos convencionais). Cenário este que apresentava diversos
problemas como redundância de dados que levava a inconsistências, dificuldade de acesso
concorrente, dificuldade de manutenção, entre outros. Também foram especificadas as
principais vantagens de utilização de um SGBD e os perfis dos usuários que fazem uso de
sistemas de banco de dados. Para finalizar, foram apresentados exemplos de SGBDs atuais e
foram apresentadas situações onde o uso de sistemas de banco de dados é dispensável. No
capítulo a seguir, vamos continuar o nosso estudo introdutório falando sobre a evolução dos
sistemas de banco de dados e como está estruturada a sua arquitetura. Até lá!

25
 Banco de Dados

Capítulo 2

O que vamos estudar neste capítulo?

Neste capítulo, vamos estudar os seguintes temas:

» Evolução dos Bancos de Dados

» Arquiteturas dos Bancos de Dados
» Abstração de Dados

Metas

Após o estudo deste capítulo, esperamos que você consiga:

» Diferenciar as diferentes gerações de Banco de Dados

» Identificar as diferentes arquiteturas de Banco de Dados
» Entender o conceito de Abstração de Dados

26
 Banco de Dados

Capítulo 2 – Evolução e Arquitetura

dos Bancos de Dados

Vamos conversar sobre o assunto?

“Vimos, no capítulo anterior, a importância dos Sistemas de Banco de Dados e as

principais características dos mesmos. Porém, será que os banco de dados sempre foram do
mesmo jeito? Será que eles mudaram? Será que evoluíram com o tempo? Ainda mais, como
é a arquitetura de um Banco de Dados? Como ele está organizado para fazer tudo que você
leu no capítulo anterior? Você sabe? Justamente sobre esses pontos vamos estudar neste
capítulo, procurando responder as perguntas aqui formuladas.”

Neste capítulo, vamos estudar a evolução dos SGBDs no tempo, que deram origem
a gerações diferentes de banco de dados, além de estudar a forma como os bancos de dados
estão organizados internamente, ou seja, a sua arquitetura. Vamos lá?

E houve a evolução...
Como vimos no capítulo anterior, no começo, não existiam bancos de dados, mas
apenas os sistemas de arquivos. Ou seja, cada aplicação ou programa desenvolvido para
uma organização tinha seu próprio conjunto de dados e a descrição desses dados ficava
dentro das próprias aplicações. Dessa forma, não havia compartilhamento de dados entre
as mesmas. Devido a isso, diversos problemas surgiam, tais como redundância de dados,
inconsistências, falta de padronização, falta de segurança no acesso aos dados, limitações
no compartilhamento dos dados, entre outros. Os bancos de dados surgiram como forma de
tentar resolver esses problemas (o que você pode observar pela definição de BD e vantagens
anteriormente apresentadas). Mas os bancos de dados foram sempre os mesmos? Ou eles
evoluíram com o tempo? Os bancos de dados não foram sempre os mesmos. Podemos
inclusive subdividir sua evolução em três gerações bem definidas (vide Figura 10), cada uma
com características próprias. Na primeira geração, que surgiu no final dos anos 60, estão os
bancos de dados hierárquicos e em rede. Na segunda geração que nasceu no final dos anos
70 está o banco de dados relacional. E, por fim, a geração mais atual que data de desde o
final dos anos 80 está o banco de dados orientado a objetos e objeto-relacional. A seguir,
detalharemos cada uma dessas gerações.

27
 Banco de Dados

Figura 10 - Evolução dos Bancos de Dados

Primeira Geração dos Bancos de Dados

Os primeiros bancos de dados surgiram nos anos 60, com o surgimento dos bancos
de dados hierárquicos e em rede, com acesso sequencial aos dados e processamento em
batch (em lote, várias instruções de uma vez), essa foi a chamada primeira geração. Os dois
modelos da época eram o Hierárquico e o em Rede, ambos orientados a registros, isto é,
qualquer acesso à base de dados – inserção, consulta, alteração ou remoção – era feita em
um registro de cada vez. Vamos detalhar agora, cada um desses modelos.

Modelo de Dados Hierárquico

O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados.

Nesse modelo de dados, os dados são estruturados em hierarquias ou árvores (lembra das
árvores que você estudou na disciplina de estrutura de dados?). Os nós das hierarquias
contêm ocorrências de registros, onde cada registro é uma coleção de campos (atributos),
cada qual contendo somente um valor.
Os registros são conectados uns aos outros por meio de uma ligação, também
chamada de link (associação essa entre exatamente dois registros). O registro da hierarquia
que precede a outros é o registro-pai, os outros são chamados de registros-filhos. O
relacionamento entre um registro-pai e vários registros-filhos possui cardinalidade 1:N,
ou seja, cada registro-pai pode possuir 1 ou mais registros-filhos, mas os registros filhos
possuem apenas um único registro pai (vide representação da Figura 11).

Figura 11 - Relação 1-N entre registro-pai e registros-filhos

28
 Banco de Dados

Os dados organizados, segundo este modelo, podem ser acessados segundo uma
sequência hierárquica com uma navegação do topo (raiz) para as folhas (nós sem filhos) e
da esquerda para a direita dentro de cada nó ou registro. Um mesmo registro pode estar
associado a vários registros diferentes, desde que seja replicado. Porém, a replicação
possui duas grandes desvantagens: pode causar inconsistência de dados quando houver
atualização e causar desperdício de espaço.
Vamos dar um exemplo. Suponha que o conjunto de todos os registros de clientes
e de contas de um banco está organizado na forma de uma árvore com raiz (vide Figura
12), em que a raiz da árvore é um registro falso (sem conteúdo, serve apenas para iniciar a
árvore). Teríamos nós que representariam os clientes (com valores para o nome do cliente,
a rua onde ele mora e a cidade) como, por exemplo, o nó com valor “Rui, Rua XV e S. Carlos”
e nós que representariam as contas (com valores para o número da conta e o saldo) como,
por exemplo, o nó com valor “7556, 3.000” (vide Figura 13). Neste modelo, a necessidade
de representar contas conjuntas levaria à duplicação de registros, devido à representação
em árvore. Por exemplo, suponhamos que Silvia e Rui possuem a conta conjunta de número
7556 (vide Figura 12, os nós com o número da conta em negrito), para representar esse fato,
o nó da conta corrente teve de ser duplicado para obedecer à regra que “cada filho só pode
ter um único pai”.

Figura 12 - Exemplo de Modelo Hierárquico

Figura 13 - Representação dos nós usada no exemplo

Além de poder causar inconsistência de dados quando houver atualização e causar

desperdício de espaço, outros problemas encontrados no modelo hierárquico são:

» Nem tudo pode ser representado como uma hierarquia;

29
 Banco de Dados

» Complexidade dos diagramas de estrutura de árvore;

» Não pode haver ciclos no gráfico básico de um diagrama de estrutura de árvore;
» Restrições à cardinalidade dos links (não pode haver ligações de muitos para muitos
(N:M) e de muitos para um (N:1));
» Ausência de facilidades de consultas declarativas (não há linguagem ou recurso
específico para isso), logo a realização de consultas é uma atividade complexa;
» Necessidade de navegação por ponteiros para acesso a informações.
O sistema comercial mais divulgado no modelo hierárquico foi o Information
Management System (IMS) da IBM Corporation. O IMS é um dos mais antigos e mais
amplamente utilizados sistemas de bancos de dados. Os desenvolvedores deste sistema
estão entre os primeiros a tratarem características como concorrência, recuperação,
integridade e processamento eficiente de consultas. Além dele, outros bancos que usavam
o modelo hierárquico foram: UNIVAC 1100, CDC 6000, CYBER 70 e 170.

Modelo de Dados em Redes

O modelo em redes surgiu como uma extensão ao modelo hierárquico, eliminando

o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em
várias associações. E que benefícios trás isso? Bem, isso faz com que seja possível construir
relações menos restritivas entre os registros.
No modelo em rede, os registros são organizados em grafos onde aparece um único
tipo de associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário
e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre
os registros C e D é possível construir um relacionamento M:N (muitos para muitos) entre A
e D, o que não era possível no modelo hierárquico. Adicionalmente, ao contrário do Modelo
Hierárquico, em que qualquer acesso aos dados passa pela raiz (lembra do tal registro
falso?), o modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz.
Dessa forma, no modelo em redes os registros são organizados no banco de dados por um
conjunto arbitrário de grafos.
Na Figura 14, podemos ver o mesmo exemplo de registros de clientes e contas
apresentado antes como exemplo do modelo hierárquico, agora sendo representados pelo
modelo em redes. Note que não há mais duplicação do registro que representa a conta 7556
(em negrito na Figura 14), por ser permitida mais de uma ligação (o que não era possível no
modelo hierárquico). Note também a ausência do registro falso (raiz).

Figura 14 - Exemplo de Modelo em Rede

30
 Banco de Dados

As restrições impostas pelo Modelo de Redes podem ser descritas como de ordem
de Entrada e de Existência. Em relação às restrições de entrada, citamos a obrigatoriedade
de cada novo registro estar conectado ao conjunto indicado. Em relação a restrições de
Existência, podemos dizer que um componente de um tipo de registro pode existir de forma
independente de outros desde que esteja conectado a algum outro registro fazendo parte
de algum conjunto, ou sendo base de um novo conjunto. A identificação de um conjunto
pode ser verificada através do esquema de ligação entre o registro pai e o registro filho,
assim sendo, cada instância de conjunto apresenta um elemento de distinção, o tal registro
pai, e os registros filhos devidamente ordenados e, portanto, passíveis de serem acessados
pelos seus elementos.
Alguns problemas do modelo em redes são:

» O modelo de rede é fortemente dependente da implementação.

» As consultas são complicadas: o programador é forçado a pensar em termos de
links e, em como percorrê-los para obter as informações de que necessita. Essa
manipulação de dados é chamada navegacional.
No Modelo em Rede, o sistema comercial mais divulgado é o CAIDMS da Computer
Associates. Além dele, há o DBMS10, o IDS II, o DMS II e o IMAGE

Segunda Geração dos Bancos de Dados

Nos anos 70 e 80, com os dispositivos de acesso direto aos dados, surgem
os sistemas indexados e de processamento transacional (cada operação deve ser
completamente realizada, se não o for, deve ser desfeita, esse é o conceito de transação).
Nos anos 80, foram lançadas as bases do modelo relacional (dando origem à segunda
geração) que impulsionou o uso e abriu caminho para todos os SGBDs atuais.

Modelo de Dados Relacional

O modelo relacional apareceu devido às seguintes necessidades:

» Aumentar a independência de dados nos sistemas gerenciadores de banco de

dados;
» Prover um conjunto de funções apoiadas em álgebra relacional para armazenamento
e recuperação de dados;
» Permitir processamento ad hoc
O Modelo Relacional (MR) é considerado o primeiro modelo de dados efetivamente
usado em aplicações comerciais. Foi introduzido por Codd em 1970. É o modelo que possui
a base mais formal entre os modelos de dados, entretanto é o mais simples e com estrutura
de dados mais uniforme. O modelo relacional tem como base a teoria dos conjuntos e a
álgebra relacional.
A estrutura fundamental do modelo relacional é a relação (tabela). Na verdade,
o modelo é composto por uma coleção de tabelas de nomes únicos. Cada relação ou
tabela é constituída por uma ou mais colunas chamadas de atributos (campos) que são os
tipos dos dados contidos na relação. O conjunto de valores passíveis de serem assumidos
por um atribruto será intitulado de domínio. Cada linha da relação é chamada de tupla
(registro). O esquema de uma relação nada mais é do que os campos (colunas) existentes
em uma relação ou tabela. Já a instância da relação consiste no conjunto de valores que
cada atributo assume em um determinado instante. As relações não podem ser duplicadas

31
 Banco de Dados

(por exemplo, não podem existir dois estados de Pernambuco, no conjunto de estados
brasileiros) e a ordem de entrada de dados no Banco de Dados não deverá ter qualquer
importância para as relações, no que concerne ao seu tratamento.
Diferentemente dos modelos que o precederam o modelo relacional não tem
caminhos pré-definidos para se fazer acesso aos dados. Os relacionamentos entre as tabelas
são feitos através do uso de valores de atributos. Por exemplo, na Figura 15, a Tabela de
Empregados precisa usar valores que estão, originalmente, na tabela de Departamentos (o
atributo ou campo chamado Cod_Depto). Isso causa a necessidade de um relacionamento
entre as tabelas.

Figura 15 - Exemplo de Relacionamento no Modelo Relacional

Para trabalhar com tabelas, algumas restrições precisaram ser impostas para evitar
aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte
da informação e perda de informação. Essas restrições são: integridade referencial, chaves
e integridade de junções de relações. Veremos em detalhes isso tudo no volume II da
disciplina. O modelo relacional faz uso da linguagem SQL para definição e manipulação de
dados (discutiremos sobre a linguagem SQL, em detalhes, no volume III da disciplina).
Alguns exemplos de banco de dados que fazem uso desse modelo são: PostGreSQL,
Oracle, SQLServer, MySql, entre outros.

Terceira Geração dos Bancos de Dados

Devido às necessidades do mundo moderno de manipular dados complexos, surgiu
a terceira geração dos bancos de dados, com os modelos de dados orientados a objetos e os
modelos de dados objeto-relacionais. E o que eles trouxeram de novo? Vamos ver a seguir.

Modelo de Dados Orientado a Objetos

Os bancos de dados orientados a objeto começaram a se tornar comercialmente

viáveis em meados de 1980. A motivação para seu surgimento está em função dos limites
de armazenamento e representação semântica impostas no modelo relacional. Um exemplo
de modelo orientado a objetos são os sistemas de informações geográficas (SIG) que são
mais facilmente construídos usando tipos complexos de dados. A habilidade para criar os
tipos de dados necessários é uma característica das linguagens de programação orientadas
a objetos.
Contudo, estes sistemas necessitam guardar representações das estruturas de
dados que utilizam no armazenamento permanente. A estrutura padrão para os bancos
de dados orientados a objetos foi feita pelo Object Database Management Group (ODMG).
Esse grupo é formado por representantes dos principais fabricantes de banco de dados
orientados a objeto disponíveis comercialmente. Membros do grupo têm o compromisso
32
 Banco de Dados

de incorporar o padrão em seus produtos. O termo Modelo de Dados Orientado a Objetos

é usado para documentar o padrão que contém a descrição geral das facilidades de um
conjunto de linguagens de programação orientadas a objetos e a biblioteca de classes que
pode formar a base para o Sistema de Banco de Dados.
Quando os bancos de dados orientados a objetos foram introduzidos, algumas
das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas com esta
tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado.
Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serão usados em
aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os
negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes.
Alguns exemplos de banco de dados que fazem uso desse modelo são: O2,
OBJECTSTORE, Caché e IRIS.
O diagrama de classes UML, usado na análise orientada a objetos, serve geralmente
como o esquema para o modelo de dados orientado a objetos (vide exemplo para o
problema dos registros de clientes e contas, que já foi utilizado para ilustrar os modelos
hierárquico e em rede, na Figura 16).

Figura 16 - Exemplo de Modelo de Dados Orientado a Objetos

Alguns problemas do modelo orientado a objetos são: ele não tem base teórica
(formalismo) como os modelos anteriores e não existe linguagem padronizada para acesso
e manipulação dos dados (tal qual o SQL). Isso fez com que esse paradigma não fosse bem
aceito no mercado. Como solução surgiu o paradigma objeto-relacional.

Modelo de Dados Objeto-Relacional

A área de atuação dos sistemas Objeto-Relacional tenta suprir a dificuldade dos

sistemas relacionais convencionais, que é o de representar e manipular dados complexos,
visando ser mais representativos em semântica e construções de modelagens. Neste
modelo de dados, toda a informação persistente está ainda nas tabelas, mas algumas
das entradas da tabela podem ter uma estrutura de dados mais rica, denominada tipos
abstratos de dados (TAD). Um TAD é um tipo de dado que é construído combinando tipos de
dados alfanuméricos básicos. Um suporte para tipos de dados abstratos é atrativo porque as
operações e funções associadas com o novo tipo podem ser usadas para indexar, armazenar,
e recuperar registros baseados no índice do novo tipo de dado (por exemplo, multimídia).
Diferente do modelo orientado a objetos, o modelo objeto-relacional foi
desenvolvido com base no modelo relacional. Dessa forma, foi possível unir conceitos
de OO (tais como: supertabelas, supertipos, herança, reutilização de códigos de criação,
encapsulamento, controle de identidade de objetos e referência a objetos) com conceitos
do modelo relacional (tais como: capacidade de consulta avançada e a alta proteção a
dados). Assim, os modelos Objeto-Relacional combinam os benefícios do modelo Relacional
com a capacidade de modelagem do modelo OO
A linguagem de consulta objeto relacional é uma extensão da linguagem SQL
33
 Banco de Dados

para suportar o modelo de objetos. As extensões incluem consultas envolvendo objetos,

atributos multivalorados, TADs, métodos e funções como predicados de busca em uma
consulta.
Alguns motivos que levam a utilização desse tipo de modelo são:

» A incapacidade do modelo relacional básico de resolver os desafios e atender as

necessidades das novas aplicações;
» A capacidade de armazenar novos tipos de dados;
» Fornecem suporte para consultas complexas sobre dados complexos
» Atendem aos requisitos das novas aplicações e da nova geração de aplicações de
negócios
Algumas aplicações para as quais é necessário o uso desse tipo de modelo são:

» Armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital);

» Dados complexos não-convencionais em projeto de engenharia;
» Grandes informações sobre o genoma biológico
» Projetos de arquitetura;
» Dados de séries temporais em transações;
» Dados sobre o espaço (regiões geográficas, criação de mapas)
» Sistemas móveis e distribuídos, dentre outros.
Alguns bancos de dados que fazem uso do modelo objeto-relacional são Oracle 9i,
DB2/6000, ILUSTRA e CA-Ingres.
Saiba Mais

6
Mainframes são
computadores
Arquiteturas de Sistemas de Banco de Dados
de grande porte,
dedicados, A arquitetura dos sistemas de banco de dados é influenciada pela arquitetura dos
normalmente, ao
processamento de
sistemas computacionais, levando em consideração aspectos como:
um volume grande de
» Redes de computadores, cujo surgimento colaborou para a divisão de tarefas entre
informações.
máquinas remotas, em que uma assume papel de cliente e outra de servidor,
Os mainframes
são capazes de levando a uma arquitetura cliente-servidor;
oferecer serviços de » Paralelismo, que consiste na possibilidade de executar atividades simultaneamente,
processamento a
milhares de usuários obtendo melhores tempos de resposta e executando uma maior quantidade de
através de milhares de transações por segundo;
terminais conectados
diretamente ou » Distribuição, em que os dados residem na localidade em que são gerados ou
através de uma rede. em que serão mais úteis, por meio de diversas cópias do banco de dados. Uma
Embora venham
arquitetura distribuída possibilita uma maior disponibilidade dos dados, que
perdendo espaço
para os servidores podem ser acessados ainda que uma determinada localidade enfrente problemas e
de arquitetura PC e se torne indisponível.
servidores Unix, de
custo bem menor, Como consequência do emprego desses aspectos, temos as arquiteturas
ainda são muito centralizadas, cliente-servidor, distribuída e paralela que iremos descrever a seguir.
usados em ambientes
comerciais e em
grandes empresas, Arquiteturas Centralizadas
tais como: bancos,
empresas de aviação e As primeiras arquiteturas usavam mainframes6 para executar o processamento
universidades. principal e de todas as funções do sistema, incluindo os programas aplicativos, programas
de interface com o usuário, bem como a funcionalidade dos SGBDs. Esta é a razão pela qual
34
 Banco de Dados

a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de
processamento, apenas a capacidade de visualização (esses terminais eram muitas vezes
chamados de terminais-burros, justamente por não terem poder de processamento). Ou
seja, todos os processamentos eram feitos remotamente, apenas as informações a serem
visualizadas e os controles eram enviados do mainframe para os terminais de visualização
(também chamados de nós), conectados a ele por uma rede de comunicação (vide Figura
17).
Como os preços do hardware foram decrescendo, muitos usuários trocaram seus
terminais por computadores pessoais (PCs) e estações de trabalho (tais como as estações
unix). No começo os SGBDs usavam esses computadores da mesma maneira que usavam
os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de
programas aplicativos e processamento da interface do usuário eram executados em apenas
uma máquina (a que centralizava tudo). A arquitetura centralizada tem como principais
vantagens: permitir que muitos usuários manipulem grande volume de dados e que, com
os dados totalmente isolados, se ganha consideravelmente em segurança, visto que o
acesso aos dados é feito somente em um único local. E a sua principal desvantagem é a total
dependência de um único sistema, podendo ocasionar uma elevada indisponibilidade em
caso de falhas deste.

Figura 17 - Esquema de um BD Centralizado

Com o desenvolvimento de computadores pessoais com maior capacidade de

processamento, parte do controle da aplicação e interface junto ao usuário, que antes era de
total responsabilidade do sistema centralizado, passou a ser realizado pelos computadores
pessoais, cabendo ao sistema centralizado apenas satisfazer às solicitações geradas pelos
sistemas clientes. Assim, gradualmente, os SGBDs começaram a explorar a disponibilidade
do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor,
que veremos a seguir.

Arquitetura Cliente-Servidor

A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de

computação onde um grande número de PCs, estações de trabalho, servidores de arquivos,
impressoras, servidores de banco de dados e outros equipamentos são conectados juntos
por uma rede.
A ideia é definir servidores especializados, tais como servidor de arquivos (que
35
 Banco de Dados

mantém os arquivos de máquinas clientes) ou servidores de impressão (que podem

Saiba Mais estar conectados a várias impressoras), assim, quando se desejar imprimir algo, todas as
requisições de impressão são enviadas a este servidor. As máquinas clientes disponibilizam
7
Uma API (Application para o usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de
Programming processamento para executar aplicações locais. Esta arquitetura se tornou muito popular
Interface ou Interface
de Programação de por algumas razões.
Aplicativos) é um
conjunto de rotinas e » Primeiro, a facilidade de implementação dada à clara separação das funcionalidades
padrões estabelecidos e dos servidores.
por um software
para a utilização das » Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples
suas funcionalidades são delegadas às máquinas clientes, que são mais baratas.
por programas
aplicativos que não » Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés
querem envolver- de usar a interface do servidor.
se em detalhes da
implementação do Diferentes técnicas foram propostas para implementar essa arquitetura, sendo
software, mas apenas que a mais adotada pelos SGBDs relacionais comerciais é a inclusão da funcionalidade de
usar seus serviços. um SGBD centralizado no lado do servidor. A realização de consultas e a funcionalidade
transacional (você lembra do que é uma transação?) permanecem no servidor, sendo que
Saiba Mais este é chamado de servidor de consulta ou servidor de transação. É assim que um servidor
SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas (usando a
8
ODBC (Open Data linguagem SQL), prover a interface para o usuário e as funções da interface usando uma
Base Connectivity)
linguagem de programação. Comumente, o servidor SQL também é chamado de back-end
é um padrão para
acesso a SGBDs. Este machine e a máquina cliente de front-end machine.
padrão define um
conjunto de interfaces Resumindo com outras palavras, na arquitetura Cliente-Servidor, o cliente (front_
que permitem o end machine) executa as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela
uso de linguagens e processamento de entrada e saída), ferramentas de relatório, geração de formulários,
de programação
análise e mineração de dados. Já o servidor (back_end machine) executa as consultas no
como Visual Basic,
Delphi, Visual C++, SGBD e retorna os resultados ao cliente, ficando responsável por tarefas como o controle de
entre outras capazes acesso, otimização de consultas, controle de concorrência, recuperação, etc.
de utilizar estas
interfaces, para ter Como SQL provê uma linguagem padrão para os SGBDs Relacionais, esta criou o
acesso a uma vasta ponto de divisão lógica entre o cliente e o servidor. Dessa forma, a comunicação entre a
gama de banco de
front-end machine e o back-end machine é realizada por meio da linguagem SQL e por
dados distintos sem
a necessidade de meio de uma API7 que possibilita a conexão e a comunicação entre as máquinas cliente e
codificar métodos de servidora. Exemplos de APIs são os padrões ODBC8, JDBC9 que vão justamente servir para a
acesso especializados. comunicação de programas escritos em uma linguagem de programação com os SGBDs.
O uso destas interfaces
está condicionado à Quando um programa escrito em uma linguagem de programação faz uso de
existência de drivers
uma API (tudo isso no lado do cliente) para acesso a um banco de dados que está em uma
ODBC específicos para
as bases de dados que máquina servidora (vide Figura 18), dizemos que se está usando uma arquitetura cliente-
se deseja acessar. servidor de 2 camadas. Ou seja, a comunicação é direta do cliente para o servidor.
Já a arquitetura cliente-servidor em três camadas, conta com a máquina cliente
Saiba Mais na qual um navegador web, atua como front-end junto ao usuário para acessar um servidor
de aplicação (também conhecido como servidor Web). Esse servidor de aplicação atua em
9
JDBC (Java Database uma camada intermediária (a segunda camada), processando as solicitações dos usuários
Connectivity) é
e fornecendo respostas obtidas através do acesso ao servidor de banco de dados (que é
uma API escrita em
Java e usada com a terceira camada), que continua sendo o responsável pela realização de consultas e
a linguagem JAVA transações no SGBD. Sistemas que lidam com grande quantidade de usuários adotam essa
para fazer o envio de
arquitetura em três camadas.
instruções SQL para
qualquer banco de
dados relacional. É o
equivalente do ODBC
para a linguagem JAVA.

36
 Banco de Dados

Figura 18 - Esquema de uma arquitetura em 2 camadas

Figura 19 - Esquema de uma arquitetura em 3 camadas

A principal vantagem da arquitetura cliente-servidor é a divisão do processamento

entre dois ou mais sistemas, o que reduz o tráfego de dados na rede.

Arquitetura Distribuída

A tecnologia de Banco de Dados Distribuídos (BDDs) surgiu como uma intercalação

de duas tecnologias: tecnologia de banco de dados e tecnologia de comunicação de dados
e de rede. Com as novas tecnologias de comunicação de dados, atendendo à necessidade
da descentralização, é possível se trabalhar com bancos de dados não mais centralizados em
um servidor, mas sim distribuídos em vários servidores. Podendo esses servidores estar na
mesma rede, assim como podem estar em países diferentes, compartilhando informações
37
 Banco de Dados

de uma maneira transparente para os usuários. Assim, em um sistema de banco de

dados distribuídos, o banco de dados é armazenado em diversos computadores, que se
comunicam uns com os outros através de vários meios de comunicação, tais como redes
de alta velocidade ou linhas de telefone, em que cada qual pode participar na execução de
transações que acessam dados em um ou diversos nós (vide Figura 20).

Figura 20 - Esquema de um banco de dados distribuído

Nesta arquitetura, cada servidor atua como no sistema cliente-servidor, porém as

consultas oriundas dos aplicativos são feitas para qualquer servidor indistintamente. Caso a
informação solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se
de obter a informação necessária, de maneira transparente para o aplicativo, que passa a
atuar consultando a rede, independente de conhecer seus servidores. Exemplos típicos são
as bases de dados corporativas, em que o volume de informação é muito grande e, por isso,
deve ser distribuído em diversos servidores.
De forma simplificada, pode-se dizer que a principal diferença entre sistemas de
bancos de dados centralizados e distribuídos é que no primeiro os dados estão localizados
em um único lugar, enquanto no último os dados residem em diversos locais.
Um dos motivos para distribuir um banco de dados é que um banco de dados
distribuído além de ser mais confiável, tem a capacidade de resolver da melhor maneira os
problemas grandes e complexos com os quais nos defrontamos hoje, usando uma variação
da regra de dividir e conquistar. Ou seja, problemas complicados podem ser resolvidos
simplesmente dividindo-os em fragmentos menores e atribuindo-os a grupos de software
distintos, que funcionem em computadores diferentes, produzindo um sistema que atue
sobre vários elementos de processamento. Esses grupos de software devem colaborar de
forma eficaz para a execução de uma tarefa em comum. Outros motivos para distribuir são:

» Disponibilidade - pois se um site “sai do ar”, os demais sites podem continuar em

operação. Isso é devido ao fato que, como os dados são replicados em vários nós,
uma transação que necessita de um particular item de dado pode encontrá-lo
em qualquer outro nó. Com isso, a falha de um nó não necessariamente implica
na parada de funcionamento de um sistema, aumentando a confiabilidade e
disponibilidade do sistema.
» Desempenho otimizado – o desempenho otimizado dos SGBDs distribuídos
se baseia em dois pontos: Um SGBD distribuído fragmenta o banco de dados,
permitindo que os dados fiquem armazenados próximos a seus pontos de
38
 Banco de Dados

utilização, reduzindo o atraso de acesso remoto, além disso, cada site manipula
apenas uma parte do banco de dados, tornando a administração deste mais
simples. O paralelismo inerente de sistemas distribuídos pode ser explorado para
se obter paralelismo entre consultas e intraconsulta, assim é possível executar
várias consultas ao mesmo tempo e o paralelismo intraconsulta é alcançado
desmembrando uma única consulta em várias subconsultas que serão executadas
em locais diferentes. Segundo Moura [1985], a possibilidade de autonomia local é
frequentemente a maior vantagem de bancos de dados distribuídos.
» Facilidade de Expansão - um sistema distribuído pode crescer mais facilmente que
um sistema centralizado. Se for necessário expandir o sistema porque o volume de
dados cresceu ou o volume de processamento aumentou, é mais fácil acrescentar
um novo nó à rede de computadores, desde que os nós sejam autônomos, do que
substituir um sistema centralizado já existente por outro maior.
Porém, tudo na vida tem pontos positivos e negativos. Dessa forma, nos sistemas
distribuídos há um acréscimo de complexidade para assegurar a coordenação entre os sites
e há um custo para desenvolver os softwares de aplicação e gerenciamento do sistema
como um todo.

Arquitetura Paralela

Sistemas gerenciadores de bancos de dados paralelos são compostos por diversos

processadores, memórias e discos, utilizados em aplicações críticas, que necessitam
lidar com quantidades muito grandes de dados e oferecer baixos tempos de resposta. A
arquitetura paralela é adequada aos seguintes casos:

» Quando é necessário consultar bancos de dados extremamente grandes (na ordem

de terabytes);
» Quando é necessário processar um número muito grande de transações por
segundo (na ordem de milhares de transações por segundo).
Existem vários modelos de arquitetura paralela. São eles:

» Memória compartilhada - Em um modelo de memória compartilhada, diversos

processadores acessam uma única memória, por meio de barramento ou rede de
interconexão (vide Figura 21). Esse modelo tem como vantagem o fato de que os
processadores podem trocar rapidamente mensagens entre si através da memória
comum. E possui como desvantagem o fato de que o modelo não pode ser
expandido a um número superior a 32 ou 64 processadores, visto que o barramento
ou a rede de interconexão entre processadores e memória se tornaria um gargalo
e os processadores passariam mais tempo aguardando pela sua vez para acessar
memória do que realizando o processamento.

Figura 21 - Esquema do modelo paralelo de memória compartilhada

39
 Banco de Dados

» Disco compartilhado - No modelo de disco compartilhado (vide Figura 22),

todos os processadores acessam todos os discos diretamente por meio de uma
rede de interconexão, contudo, cada processador possui sua própria memória
privada e exclusiva. Esse modelo tem como vantagem o fato de que, como cada
processador possui sua própria memória, não há problemas de gargalo de acesso à
memória e pode-se maximizar o número de processadores utilizados. Além disso,
há uma boa tolerância a falhas, visto que caso um processador falhe, todos os
demais continuarão trabalhando normalmente e acessando os dados nos discos
compartilhados de forma natural. Como desvantagem, temos que, em relação ao
modelo de memória compartilhada, a troca de mensagens entre os processadores
é muito mais lenta, uma vez que é necessário que as mensagens trafeguem pela
rede de interconexão (tanto para acessar o disco, como para haver a comunicação
entre os processadores).

Figura 22 – Esquema do modelo paralelo de disco compartilhado

» Nenhum compartilhamento – Neste modelo (vide Figura 23), cada nó possui seus
próprios discos, processador e memória, comunicando-se com os demais nós por
meio de uma rede de interconexão de alta velocidade. Aqui, cada nó assume o
papel de servidor em relação aos demais nós, oferecendo como serviço o acesso
aos dados que estão em seus discos. A vantagem é que esse modelo é altamente
escalável, podendo admitir facilmente uma grande quantidade de processadores. A
desvantagem é que o custo para comunicação e acesso aos dados em discos não-
locais é muito maior que nos modelos de memória e discos compartilhados, visto
que, além de ser necessária a transmissão por rede, também há a interação entre
os softwares, em ambas as extremidades.

Figura 23 - Esquema do modelo paralelo sem compartilhamento

» Hierárquico – este modelo combina características do modelo de memória

40
 Banco de Dados

compartilhada, disco compartilhado e com nenhum compartilhamento. Em

um nível superior, pode-se ter nós que não compartilham memória ou discos
entre si, trabalhando em um modelo “sem nenhum compatilhamento”, porém,
cada nó poderia ser um sistema de memória compartilhada entre dois ou mais
processadores. Ou seja, no nível mais alto os nós são conectados por uma rede,
sem compartilhar recursos. E, no nível mais baixo, cada nó é constituído de sistemas
de compartilhamento (vide Figura 24).

Figura 24 - Esquema de modelo paralelo hierárquico

Arquitetura Mono-Usuário

Aqui, o banco de dados encontra-se no mesmo computador em que são executadas

as aplicações e não há múltiplos usuários. Geralmente utilizada com computadores
pessoais, no começo esse processamento era bastante limitado, porém, com a evolução
do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o
padrão Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta
maneira, possuem um único aplicativo a ser executado na máquina. A principal vantagem
desta arquitetura é a simplicidade.

Abstração de Dados
Abstrair dados significa omitir a complexidade do sistema de modo a facilitar a
interação dos usuários com ele. Como um dos principais objetivos de um SGBD é simplificar
a interação do usuário com o sistema, ele deve prover uma visão abstrata dos dados, ou
seja, omitir detalhes de como os dados são armazenados e mantidos. Na verdade, uma das
características fundamentais da abordagem de banco de dados é que ela fornece algum
nível de abstração de dados, pela omissão de detalhes de armazenamento de dados que não
são necessários para a maioria dos usuários. O modelo de dados é a principal ferramenta
que fornece esta abstração.
Um Modelo de Dados é um conjunto de conceitos que podem ser usados para
descrever a estrutura do banco de dados. Por estrutura do banco de dados entendem-se
os tipos de dados, relacionamentos e restrições pertinentes aos dados. Muitos modelos
de dados também definem um conjunto de operações para especificar como recuperar e
modificar a base de dados.

Em qualquer modelo de dados é importante distinguir entre a descrição do banco de dados e o

banco de dados propriamente dito. A descrição de um banco de dados é chamada Esquema do
Banco de Dados. Um esquema de banco de dados é especificado durante o projeto deste banco,
sendo que a expectativa de mudanças não é grande. A forma de visualização de um esquema
é chamada Diagrama do Esquema. Muitos modelos de dados têm certas convenções para,

41
 Banco de Dados

diagramaticamente, mostrar esquemas especificados no modelo.

Os dados existentes em um banco de dados podem mudar com relativa frequência. Os dados
contidos em um banco de dados em um momento específico do tempo são chamados Instâncias
do Banco de Dados (ou Ocorrências ou Estados). A base-esquema é algumas vezes chamada de
Base-Intencional e uma instância é chamada de Base-Extensional do esquema.

Para prover abstração um SGBD provê a definição de esquemas em três níveis

(vide Figura 25): o nível de visão, o nível conceitual e o nível físico. Estes níveis facilitam a
manutenção do sistema e a interação dos usuários com os sistemas. Vamos detalhar mais
cada um deles a seguir.

Figura 25 - Níveis de Abstração providos por um SGBD

» O nível físico – também chamado nível interno, possui um esquema interno que
descreve como os dados estão de fato armazenados no(s) disco(s) rígido(s) (ex:
formato dos registros, ordem em que aparecem, etc). Ou seja, descreve a estrutura
de armazenamento físico dos dados do BD, fornecendo um modelo físico dos dados
que inclui detalhes sobre os caminhos de acesso aos dados internamente. Os
desenvolvedores de Banco de Dados devem ter noção desse nível.
» O nível conceitual – também chamado nível lógico, é um nível médio de abstração
e possui um esquema conceitual que descreve quais dados estão armazenados no
banco de dados e quais são os interrelacionamentos entre eles. Ou seja, descreve a
estrutura de todo o BD para uma determinada comunidade de usuários, ocultando
detalhes sobre a organização física dos dados e apresentando a descrição lógica
dos dados e das ligações existentes entre eles. Esse esquema se concentra na
descrição de entidades, tipos de dados, relacionamentos e restrições. É a visão dos
administradores de banco de dados e dos programadores.
42
 Banco de Dados

» O nível de visão – também chamado nível externo, possui esquemas externos ou

visões dos usuários. Ele é o mais alto nível de abstração. Cada esquema externo
descreve a visão do banco de dados de um grupo de usuários deste banco. Cada
visão descreve, tipicamente, a parte do banco de dados que um grupo particular
de usuários está interessado e esconde deste o restante do banco de dados. Ou
seja, vai existir uma visão diferente para cada grupo de usuários finais. Ele descreve
apenas parte do BD, pois os usuários normalmente não precisam conhecer todo o
banco, eles acabam utilizando apenas parte dele.
Essa divisão em níveis é conhecida como arquitetura “Three-Schema” (também
conhecida como arquitetura ANSI/SPARC) e foi proposta por Tsichritzis & Klug em 1978. A
meta desta arquitetura é separar as aplicações de usuários do banco de dados físico (meio
que deixar “cada macaco no seu galho”) ☺

Como os três níveis apresentam descrições diferentes para os mesmos dados, torna-se necessário
converter uma representação em outra, ou seja, definir mapeamentos de dados entre os níveis.
Esses mapeamentos são mantidos pelo DBA.

Muitos SGBDs não separam os três níveis completamente. Pode acontecer que alguns SGBDs
incluam detalhes do nível interno no esquema conceitual. Em muitos SGBDs que permitem visões,
os esquemas externos são especificados com o mesmo modelo de dados usado no nível conceitual..

Estes três níveis podem ser utilizados para explicar conceitos de independência
de dados. Mas o que é independência de dados? Independência de dados se refere à
imunidade de aplicativos dos usuários a mudanças na definição e na organização de dados,
e vice-versa. Em outras palavras, ela pode ser definida como a capacidade de alterar
o esquema de um nível de abstração sem ter que alterar o esquema do próximo nível
superior. Você só vai ter ideia da importância disso quando começar realmente a manipular
um banco de dados!
Pode-se dividir a independência de dados em dois tipos: a independência de dados
lógica e a independência física de dados.
A independência de dados lógica é a capacidade de alterar o esquema conceitual
sem ter que mudar os esquemas externos (nível de visão) ou programas de aplicação
que fazem uso do banco de dados. Pode-se mudar o esquema conceitual para expandir o
banco de dados, com a adição de novos tipos de registros (ou itens de dados), ou reduzir
o banco de dados removendo um tipo de registro. Neste último caso, esquemas externos
que se referem apenas aos dados remanescentes (que não foram alterados) não devem
ser afetados. Assim é possível modificar a organização conceitual com impacto mínimo nas
aplicações (construídas sobre os esquemas externos ou visões).
A independência de dados física é a capacidade de alterar o esquema interno
(nível físico) sem ter que alterar o esquema conceitual (nível lógico). Mudanças no esquema
interno podem ser necessárias devido a alguma reorganização de arquivos físicos para
melhorar o desempenho nas recuperações e/ou modificações. Após a reorganização, se
nenhum dado foi adicionado ou perdido, não haverá necessidade de modificar o esquema
conceitual. Em outras palavras, a independência de dados física lida com a ocultação dos
detalhes da estrutura de armazenamento em relação aos aplicativos do usuário, ou seja,
quando um aplicativo é escrito, ele não deve se preocupar com os detalhes da organização
física dos dados. Assim, é possível modificar as estruturas de armazenamento sem impactar
nas aplicações que fazem uso do BD.

43
 Banco de Dados

Conheça Mais

Para maiores detalhes sobre os assuntos tratados neste capítulo, você pode
recorrer a qualquer livro de banco de dados, como os indicados no capítulo anterior.
Adicionalmente, você pode consultar as seguintes fontes:
CASANOVA, M. A.; MOURA, A. V. Princípios de Sistemas de Gerência de Bancos de
Dados Distribuídos. Rio de Janeiro: Campus, 1985
MATTOSO, Marta. Bancos de Dados Distribuídos. Universidade Federal do Rio de
Janeiro, 1998.
TSICHRITZIS, D. & KLUG, A. (eds.). The ANSI/X3/SPARC DBMS framework report of
the study group on database management systems. Information Systems 3, pp.
173-191, 1978.
DATE, C.J. □Introdução a Sistemas de Banco de Dados. 7ª Edição, Editora Campus,
2000.
Há também um texto bem interessante na internet:
TAKAI, K.; ITALIANO, I.C.; FERREIRA, J. E. □Introdução a Banco de Dados (Apostila).
DCCIME-USP, 2005. Disponível em: http://www.ime.usp.br/~jef/apostila.pdf

Você Sabia?

Existem alguns termos que vamos utilizar, em breve, que é interessante já conhecer. São eles:
Tempo de resposta - Em sistemas gerenciadores de banco de dados, tempo de resposta é o
tempo necessário para que o sistema execute uma única tarefa, a partir do momento em que
esta foi submetida.
Throughtput - Em sistemas de bancos de dados, throughput é o número de tarefas que um
sistema é capaz de completar em um determinado intervalo de tempo.
Agora, você já sabe o significado para quando eles aparecerem tanto nas suas leituras, como nos
nossos textos futuros, ok?

Aprenda Praticando

O sistema de banco de dados deve prover uma visão abstrata de dados para os
usuários, isolando, desta forma, detalhes mais internos do BD. Essa abstração é provida em
três níveis. Faça um esquema gráfico e explique estes níveis de abstração.
Como você responderia essa questão? Como você desenharia o esquema de níveis
de abstração? Bom, quanto ao desenho podemos partir para algo bem simples, veja a seguir.

44
 Banco de Dados

Cada nível é representado por um retângulo com o nome dentro. Para reforçar
a ideia de que o nível físico é o que realmente armazena os dados no banco de dados,
podemos desenhar umas bases de dados conectadas ao nível físico. Para dar a ideia de que
no nível de visão, para cada grupo de usuários pode existir uma visão diferente dos dados,
devemos desenhar mais de um retângulo. Você ainda poderia ter colocado bonequinhos
de usuários conectados às caixas do nível de visão. Preferimos simplificar e não colocar os
bonecos. Agora, vamos à descrição dos níveis.
O nível físico é também chamado de “Esquema interno” e é o nível mais baixo de
abstração. Descreve como os dados estão realmente armazenados, englobando estruturas
complexas de baixo nível.
O nível conceitual (ou lógico) é conhecido também como “Esquema Conceitual”. Ele
descreve quais dados estão armazenados e seus relacionamentos.
O nível de visões do usuário é o nível externo. Ele descreve partes do BD que serão
visualizadas pelos usuários de acordo com suas necessidades. Uma visão é um subconjunto
de dados do BD, sem que exista a necessidade de estarem armazenados no BD.
Vamos dar uma olhada novamente em questões de concurso?

TRF4 -FCC-2004
1. Considerando a proposta ANSI/X3/SPARC, o esquema de banco de dados:
a) interno corresponde ao modelo lógico.
b) interno corresponde ao modelo conceitual.
c) externo corresponde ao modelo lógico.
d) externo corresponde ao modelo conceitual.
e) conceitual corresponde ao modelo lógico.
2. Qual(ais) do(s) modelo(s) abaixo é (são) modelo(s) de Banco de Dados?
a) Modelo Relacional
b) Modelo Hierárquico
c) Modelo em Rede
d) Todas as alternativas estão corretas
e) Todas as alternativas estão incorretas
3. A arquitetura de um banco de dados divide-se em três níveis de abstração: físico
(ou interno), conceitual e de visões (ou externo). A respeito do nível de visões,
não é correto afirmar que:

45
 Banco de Dados

a) fornecem mecanismos de segurança, restringindo o acesso dos usuários aos

dados.
b) é o nível mais alto de abstração e pode ser composto por inúmeras visões do
mesmo banco de dados.
c) os usuários veem um conjunto de aplicações e visualizam os detalhes de todos
os tipos de dados.
d) o nível de visões é definido para simplificar a interação entre o usuário final e o
banco de dados.
e) é a forma como geralmente os usuários finais veem as informações contidas no
banco de dados.

Respostas

1. E (o esquema interno corresponde ao modelo físico, o esquema externo ao

modelo de visões ou modelo externo, a única correta é que o esquema conceitual
corresponde ao modelo lógico).
2. D (todos os modelos citados são modelos de banco de dados, como vimos quando
descrevemos a evolução dos BDs)
3. C (o nível de visão restringe o acesso aos dados dos banco, tornando visível apenas
uma parte dele, que seja a adequada às operações do usuário, simplificando assim
a interação)

Atividades e Orientações de Estudo

Atividades Práticas

Resolva os exercícios a seguir:

1. Como os conceitos de níveis de abstração do banco de dados (nível de visão,

conceitual e físico) se relacionam com os conceitos de independência de dados?
2. Qual a diferença entre esquema e instância do banco de dados?
3. Quais os modelos de arquitetura paralela? Fale brevemente, com suas palavras,
sobre cada um deles.
4. Quais as principais diferenças entre o modelo relacional e os seus antecessores
(modelos hierárquico e em rede)?
5. Quais os dois exemplos mais conhecidos de arquitetura cliente-servidor e qual a
diferença entre eles?
Responder esses exercícios lhe permitirá revisar o assunto que acabou de ser
estudado.

46
 Banco de Dados

Vamos Revisar?

O primeiro Sistema Gerenciador de Banco de Dados (SGBD) comercial surgiu no final

de 1960 com base nos primitivos sistemas de arquivos disponíveis na época, os quais não
controlavam o acesso concorrente por vários usuários ou processos. Os SGBDs evoluíram
desses sistemas de arquivos de armazenamento em disco, criando novas estruturas
de dados com o objetivo de armazenar informações. Com o tempo, os SGBD’s passaram
a utilizar diferentes formas de representação, ou modelos de dados, para descrever a
estrutura das informações contidas em seus bancos de dados: modelo hierárquico, modelo
em redes, modelo relacional (amplamente usado) e o modelo orientado a objetos.
Em termos de arquitetura, dependendo do uso feito das redes de computadores,
do paralelismo envolvido e da distribuição dos dados, os SBDs podem ser classificados em
centralizados, cliente-servidor (cujos modelos mais conhecidos são o em 2 e em 3 camadas),
distribuído, paralelos (podendo haver memória compartilhada, disco compartilhado,
compartilhamento hierárquico e não haver compartilhamento) e mono-usuário.
Também podemos considerar a arquitetura em termos da abstração dos dados.
Para prover abstração um SGBD provê a definição de esquemas em três níveis: o nível de
visão, o nível conceitual e o nível físico. Estes níveis facilitam a manutenção do sistema e a
interação dos usuários com os sistemas e são muitas vezes chamados de arquitetura “three-
schema”.
O uso da arquitetura “three-schema” relaciona-se com o conceito de independência
de dados, que pode ser independência física e independência lógica.

47
 Banco de Dados

Apêndice A

Qual o conteúdo deste apêndice?

Aqui se encontram os seguintes temas:

» Tipos de Banco de Dados;

» Perspectivas.

Metas

Este apêndice pode lhe ajudar a:

» Reconhecer os diferentes tipos de Banco de Dados do mundo atual;

» Despertar a curiosidade para as novas perspectivas da área de Banco de Dados.

48
 Banco de Dados

Apêndice A – Novas Tendências e

Perspectivas

Vamos conversar sobre o assunto?

“O mundo atual é complexo e lida, diariamente, com dados cada vez mais complexos.
Sejam eles mapas, imagens, vídeos, genomas, etc. Além disso, surgiu a necessidade de
extrações diferenciadas dos dados, de forma a dar suporte à tomada de decisão e de ter
banco de dados onde a temporalidade do dado ganha uma importância elevada. Isso
tudo trouxe a necessidade de se criarem formas alternativas e não-convencionais de
armazenamento, manutenção e consulta desses novos tipos de dados. É justamente sobre
esses novos tipos de SGBDs que vamos tratar neste apêndice”

Neste apêndice, vamos comentar sobre os novos e não-convencionais tipos de

banco de dados, dando uma breve descrição sobre cada um deles e, posteriormente, vamos
apresentar novas perspectivas para dar uma ideia do que pode estar por vir. A ideia é lhe
proporcionar apenas uma visão geral dessas novas tecnologias de BD. Mas, se você desejar
se aprofundar nos temas, deixaremos indicadas várias referências. Vamos lá?

Classificação dos Bancos de Dados

Um Sistema de Gerência de Bancos de Dados (SGBD), como já estudamos nos
capítulos anteriores, permite o controle de grandes volumes de dados, oferecendo
persistência e garantindo o acesso de múltiplos usuários com eficiência e segurança.
Todo SGBD, normalmente, implementa um determinado modelo de dados, que
define tanto uma estrutura de representação para os dados como também o formalismo
de manipulação dos mesmos. Há vários anos o modelo relacional de dados, baseado em
relações matemáticas, comumente abstraídas como tabelas, vem sendo utilizado como
modelo padrão de mercado. Para aplicações ditas convencionais, envolvendo administrações
empresariais ou coorporativas, os SGBDs relacionais disponíveis no mercado atendem os
requisitos de dados e funcionais sem maiores dificuldades.
Entretanto, novas aplicações trazem desafios de estruturação de dados nos
diversos níveis de memória, especificação de consultas e manipulações complexas, sobre
conjuntos de dados cada vez maiores. Esse é o caso das aplicações científicas, dos sistemas
de informações geográficas e de suporte a decisão que compreendem objetos geográficos,
dados semiestruturados, petabytes de dados e processamentos complexos. Em vários
casos, como por exemplo, em sistemas onde o atributo tempo é importante, sistemas que
compreendem imagens, vídeos ou dados espaciais de forma geral, é difícil utilizar SGBDs
convencionais ou mesmo suas versões com funcionalidades estendidas. Por exemplo,
abstrair mapas para armazenamento em tabelas convencionais de SGBDs relacionais exige
muitas adaptações e simplificações que podem comprometer a semântica da aplicação.
Neste cenário, os Bancos de Dados Não-Convencionais (BDNCs), também chamados
de BDs pós-relacionais, visam atender as necessidades de gerenciamento de dados de
aplicações ditas não-convencionais que realizam processamentos complexos e manipulam
49
 Banco de Dados

a diversidade de novos dados que vão surgindo (mapas, imagens, sons, vídeos, o genoma
humano, etc). Vamos, a seguir, descrever brevemente alguns desses BDNCs.

Banco de Dados de Informações Geográficas (BDG)

Um Sistema Gerenciador de Bancos de Dados Geográficos (SGBDG) é caracterizado

por armazenar e manipular dados cuja geometria está referenciada à superfície planetária.
Ou seja, um SGBDG armazena informações geográficas (mapas dos mais diversos tipos),
dados climatológicos, imagens de satélite, etc.
Os SGBDGs permitem manter dados georreferenciados, sendo fundamentais
para o desenvolvimento de aplicações em várias áreas, como controle sobre os processos
ambientais e de uso da terra (tais como: planejamento agrícola e de bacias hidrográficas,
controle de queimadas e desmatamento e classificação de solos); econômicos e sociais
(tais como: análise de distribuição de produtos e de serviços); cadastro e planejamento
urbano e rural (tais como lotes, logradouros, redes de infraestrutura, turismo) e previsão
Saiba Mais climatológica.
O que diferencia os SGBDGs dos demais sistemas capazes de manipular dados
10
Computer-Aided
espaciais como, por exemplo, softwares de CAD10, é a capacidade de realizar operações
Design (CAD) ou
desenho assistido por complexas de análise sobre dados espaciais.
computador é o nome
genérico de sistemas E o que é armazenado em um SGBD geográfico? Geralmente, a modelagem de um
computacionais SGBDG consiste em referenciar objetos representados em mapas. Estes objetos podem
(softwares) utilizados ser constituídos de informações espaciais e informações não espaciais (vide Figura 26). As
pela engenharia,
informações espaciais estão georreferenciadas, tal como o local de uma área de plantação
geologia, arquitetura,
e design para facilitar e as não espaciais representam as informações descritivas, como o tipo de cultura plantada
o projeto e desenho na área e o nome do proprietário.
técnicos.

Figura 26 – Exemplo de objetos representados em um SGBDG

O uso de SGBDGs permite a Análise Geo-Espacial. Esta análise é um conjunto

de funções aplicadas sobre um mapa ou objetos deste mapa e é um dos principais
diferenciais operacionais em relação aos SGBDs convencionais. Um SGBDG é apenas um dos
componentes de um Sistema de Informação Geográfica (SIG), que é um sistema responsável
por capturar, armazenar, manipular, analisar e apresentar dados geográficos.

Banco de Dados Multimídia

Sistemas Multimídia devem armazenar, recuperar, transportar, e apresentar dados

com características heterogêneas tais como textos, imagens, gráficos, sons e vídeos. Estes
são sistemas complexos e necessitam de acesso uniforme aos objetos multimídia, de forma
transparente.
50
 Banco de Dados

Todos os principais arquivos são armazenados em binário, ou seja, em cadeias

de zeros e uns, e são codificados de acordo com o tipo de arquivo (imagem, vídeo, etc).
Os SGBDs relacionais mais utilizados (tais como: Microsoft SQL Server, Oracle e MySQL)
oferecem suporte a este tipo de informação. Mas onde ela é armazenada no Banco de
Dados? Ela é armazenada em um campo criado para o armazenamento de qualquer tipo de
informação em formato binário (tal como o dado multimídia) dentro de uma tabela em um
Banco de dados chamado BLOB (Binary Large Object ou grande Objeto binário).
Porém, o uso dessa solução mostrou-se inadequada para lidar com dados
multimídia, em função da grande quantidade de bytes necessários para este fim, com isso,
tornou-se necessário o desenvolvimento de sistemas de bancos de dados especificamente
voltados para essas aplicações.
Os Sistemas de Bancos de Dados Multimídia (SGBD MM) se caracterizam pela
incorporação de mídia contínua como vídeo, áudio e animação. Um bom SGBD MM deve
permitir consultas baseadas no conteúdo dos documentos e, para isso, é importante que
ele seja capaz de fazer a interpretação dos dados, com a identificação de objetos conceituais
nele contidos e seus relacionamentos.
E em que tipos de aplicações são usados os SGBD MM? Vamos dar alguns exemplos:

» Gerenciamento de documentos e registros: os dados podem incluir projetos de

engenharia e dados sobre produção, registros médicos de pacientes, entre outros.
» Disseminação de conhecimento: o modo multimídia irá abranger um crescimento
fenomenal em livros, catálogos, manuais e enciclopédias eletrônicas, bem como
repositórios de informações em muitos tópicos.
» Marketing, propaganda, vendas no varejo, entretenimento e turismo:
praticamente não existem limites para utilização de informações multimídia nessas
aplicações – desde apresentações eficazes de vendas até excursões virtuais em
cidades e galerias de arte. A utilização de objetos armazenados pré-projetados em
banco de dados multimídia irá expandir a extensão dessas aplicações.

Datawarehouses

Nos últimos anos houve um aumento considerável nos sistemas de gestão

empresarial, e como consequência os dados também cresceram. Bancos de dados evoluíram
para atender a esse crescimento tecnológico e toda uma atmosfera de gestão informatizada
foi gerada. Nessa evolução, os sistemas convencionais que são transacionais não conseguiram
cumprir a tarefa de analisar esses dados para garantir um resultado confiável ao usuário. Era
preciso trabalhar num contexto de dados distintos para uni-los externamente. O conceito
de Data Warehouse surgiu da necessidade de integrar dados corporativos espalhados em
diferentes máquinas e sistemas operacionais, para torná-los acessíveis a todos os usuários
dos níveis decisórios. Outro fator que contribuiu para o estabelecimento desse conceito foi
a evolução da Tecnologia da Informação, particularmente, os Sistemas de Apoio à Decisão
(do inglês, Decision Support Systems - DSS). O DataWarehouse surgiu como uma solução
para suprir as necessidades de informações para o usuário de nível decisório (ou gerencial).
Mas o que é um Datawarehouse? DataWarehouse (se traduzirmos ao pé da letra,
chamaríamos “armazém de dados”, mas não é usada tradução para o termo) é uma coleção
de dados, organizados por assunto, integrados, não-voláteis, históricos, cujo propósito é
fornecer suporte à tomada de decisão nas organizações. Vamos explicar melhor alguns dos
termos dessa definição:

» O datawarehouse é orientado por assunto, o que significa que os dados que farão
parte dele, devem ser orientados e organizados por um tema;

51
 Banco de Dados

» O datawarehouse é composto de dados integrados, o que quer dizer que “uma

limpeza” preliminar dos dados é necessária, com vista a uma racionalização e
normalização (porque os dados podem vir de fontes diferentes, tais como, arquivos
e banco de dados diversos);
» Os dados do datawarehouse são não voláteis o que significa que um dado entrando
no armazém fica assim para sempre e não deve ser deletado; só há inserção de
novos dados, mas não há atualização ou deleção (senão, não seria possível manter
o histórico);
» Os dados do datawarehouse devem ter um histórico, logo, eles devem ser datados.
Para que fazer uso de um datawarehouse? Os sistemas de informação disponíveis
foram concebidos e implantados para atender ao nível operacional. Ou seja, para agilizar
procedimentos administrativos das organizações, sendo mantidos por áreas estanques e
independentes. Porém, os níveis gerencial e estratégico passaram a requerer informações
mais trabalhadas, o que provocou uma alteração no perfil da demanda por informações.
As necessidades de informações para o nível estratégico da organização são supridas por
meio de processamentos sob demanda sobre os dados de nível operacional depositados
em fitotecas, arquivos e bases on-line. No entanto, o acesso aos dados corporativos torna-
se difícil, devido à falta de integração dessas bases. A integração dos dados e a agilidade
na recuperação de informações foi conseguida com o advento dos datwarehouses,
com a vantagem de que, como os dados do DataWarehouse estão separados das bases
operacionais, os usuários podem acessá-los, explorando e descobrindo as informações
disponíveis sem impacto no processamento operacional.
E como os dados do datawarehouse são manipulados? Será que se usa SQL
também, tal qual nos bancos de dados relacionais? Não. Para acessar e manipular os
dados em um datawarehouse são usadas ferramentas OLAP (do inglês, Online Analytical
Processing). Essas ferramentas são capazes de navegar pelos dados de um DataWarehouse,
possuindo uma estrutura adequada tanto para a realização de pesquisas, quanto para a
apresentação de informações. Por exemplo, através de um processo chamado Drill o usuário
pode aumentar (Drill down) ou diminuir (Drill up) o nível de detalhamento dos dados sendo
consultados. Como é isso? Imagine que você fez uma consulta e os dados foram retornados
organizados por países. Fazendo um Drill down, os dados passarão a ser apresentados
por estados, cidades, bairros e, assim, sucessivamente até o maior nível de detalhamento
possível. O processo contrário, o Drill up, faz com que os dados sejam consolidados em
níveis superiores de informação.
O uso de recursos para manipular, formatar e apresentar os dados de modo rápido
e flexível é um dos pontos fortes de um datawarehouse.

Banco de Dados Temporal (BDT)

Segundo Edelweiss (1998), bancos de dados temporais permitem armazenar e

recuperar todos os estados de um objeto, registrando sua evolução ao longo do tempo.
As informações relativas ao tempo são associadas aos dados de forma implícita (através
do tempo de transação e do tempo de validade) ou de forma explícita (através de um
tempo definido pelo usuário). Bancos de dados que suportam tempo de transação e
tempo de validade (BD bi-temporais) são necessários para realizar a modelagem completa
da realidade, que possibilite o acesso a todos os estados dos objetos armazenados. Logo,
diferentemente de bancos de dados convencionais onde a realidade é representada
apenas pelo estado presente de um objeto, os bancos de dados temporais (BDT) permitem
armazenar e recuperar todos os estados do objeto ao longo do tempo.
Por que armazenar o tempo é importante? Normalmente, em aplicações do
52
 Banco de Dados

mundo real estão presentes informações temporais que são relevantes na especificação de
sistemas. Para saber quais informações tiveram, têm ou terão seus valores alterados. Com a
inclusão de uma dimensão tempo é possível identificar quando uma informação foi definida
e por quanto tempo ela é válida. Outro ponto importante é que se o valor de um atributo
for alterado, o valor anterior não é perdido, favorecendo a criação de um histórico.
Como se inclui essa dimensão temporal no BD? Informações temporais são
representadas em BDs através de datas, períodos, intervalos temporais e duração da
validade de informações. A associação entre as informações temporais e os dados, ou
simplesmente a inserção do quesito tempo a um dado, é possível através do acréscimo de
uma dimensão (uma tabela ou um atributo) temporal ao banco de dados. Saiba Mais
Que aplicações fazem uso desse tipo de SGBD? A utilização de um BD temporal se 11
Business Intelligence
faz necessária em tempos onde a riqueza dos dados é fundamental para a análise e obtenção (BI) pode ser traduzido
de informações, ampliando a capacidade de sistemas que fazem o cruzamento de dados/ como “Inteligência de
informações. Exemplos de aplicações que são beneficiadas pelo uso de BD temporal são os negócios”, refere-se
ao processo de coleta,
SIGs (Sistemas de Informações Gerenciais), Dataminer (sistemas de mineração de dados),
organização, análise,
Datawarehouses, Sistemas de Suporte a Decisão tais como as aplicações de BI (Business compartilhamento
Intelligence11), aplicações da área médica (por exemplo, para manter o registro do quadro e monitoramento
clínico ou o acompanhamento do diagnóstico de pacientes), aplicações da área empresarial de informações que
oferecem suporte à
(ex: tomada de decisões e planejamento de orçamentos), dentre outras. gestão de negócios.
Apesar do custo de armazenamento ser alto em BD temporais, os benefícios são
relevantes pelo fato de serem possíveis consultas históricas com alta recuperabilidade
de dados. Atualmente, SGBDs como o PostgreSQL ou a ferramenta Time Series Cartridge Saiba Mais
inserida no Oracle, oferecem recursos para que informações temporais possam ser inseridas
aos dados em banco de dados. 12
Bioinformática
é o campo da
ciência no qual a
Biologia, a Ciência
O que mais há por aí? da Computação
e a Tecnologia da
Informação convergem
E ainda há mais? Há sim. Há vários bancos de dados surgindo tanto pela necessidade em uma única
criada por uma área específica (por exemplo, os bancos de dados biológicos), como também disciplina. Esse campo
surgindo pela própria evolução da tecnologia (tais como os bancos de dados XML e os banco surgiu da necessidade
de formação de um
de dados móveis). Vamos apresentar mais esses exemplos.
profissional que
tivesse conhecimento
Bancos de Dados Biológicos suficiente para
saber quais eram os
A quantidade de bancos de dados em Biologia Molecular vem crescendo problemas biológicos
reais e quais seriam
exponencialmente nos últimos anos, e o aspecto funcional da bioinformática12 é a
as opções viáveis de
representação, o armazenamento e a distribuição de dados. Os objetivos destes bancos desenvolvimento
variam e podem ser utilizados para armazenar e disponibilizar biosequências, funções e abordagem
moleculares, estruturas de proteínas, modelos metabólicos, entre outros, oferecendo em computacional
dos problemas em
alguns casos informações mais amplas. Em alguns casos, as informações biológicas são questão.
obtidas por análise computacional de outros bancos de dados; já em outros, através da
literatura ou informações especificadas (preenchidas no BD) por pesquisadores.
BDs biológicos se tornaram uma importante ferramenta no entendimento da vasta
quantidade de fenômenos biológicos existentes, desde a estrutura das biomoléculas e sua
interação ao metabolismo como um todo e a evolução das espécies. Este entendimento
contribui para facilitar a luta contra doenças, auxilia no desenvolvimento de novos produtos
farmacêuticos e na descoberta de relações entre espécies.
Os BDs biológicos são tanto bancos públicos quanto privados. Há mais de 1000
bancos de dados biológicos comerciais e públicos disponíveis atualmente. O acesso a esses
53
 Banco de Dados

bancos de dados, geralmente, se dá através de padrões abertos (open standards) como a

web, para facilitar o acesso aos usuários destes bancos (em geral, pessoal da área médica e
pesquisadores). Vamos dar alguns exemplos de BDs biológicos existentes:

» Bancos de dados primários de sequência (nucleotídeos e aminoácidos) – ex:

GenBank, UniProt, EBI (European Bioinformatics Institute) e o DDBJ (DNA Data Bank
of Japan)
» Bancos de genomas – ex: Mouse Genome Database, NCBI Genomic Biology
» Bancos de dados especializados – ex: Flybase, Wormbase, CGAP
» Bancos de dados de vias bioquímicas – ex: KEGG (Kyoto Encyclopedia of Genes and
Genomes)
» Bancos de dados de estrutura de proteínas – ex: PDB (Protein Data Bank), SCOP
» Bancos de dados de microarrays – ex: Array Express, SMD
» Bancos de dados de interações proteína-proteína – ex: STRING, BioGRID
» Bancos de Cadastro de recursos naturais – ex: AmazonLink, ENDS, National Whale
and Dolphins Stranding Database
A revista Nucleic Acids Research é um importante recurso com informações
sobre estes BD (http://www3.oup.co.uk/nar/database/c/). Anualmente, ela publica uma lista
atualizada com a classificação de todos os bancos de dados biológicos disponíveis.

Banco de Dados XML

XML (eXtensible Markup Language) é uma linguagem de marcação de dados13,

Saiba Mais utilizada para troca, compartilhamento e armazenamento de dados. Na verdade, é
uma linguagem que vem se tornando um padrão para representação e transferência de
13
Linguagem de dados. É um padrão aberto desenvolvido pela W3C (World Wide Web Consortium), que é
marcação de dados responsável pela definição de padrões para a Web. É um consórcio formado pela academia
é aquela que utiliza e pela indústria. Os dados no formato XML são descritos em um documento XML. Mas qual
tags para descrição
dos dados (uma tag
o formato de um documento XML? Veja, a seguir, um exemplo de um documento XML
indica a intenção do representando a ficha de um cliente:
dado e delimita o
seu conteúdo). Outro
exemplo de linguagem <?xml version=”1.0” encoding=”UTF-8”?>
de marcação é a <ficha>
linguagem HTML. <InformacaoPessoal>
<DataNascimento>10/10/1970</DataNascimento>
<Nomecompleto> Jéssica Soares </Nomecompleto>
<Contatos>
<Endereco>
<Rua>R. das Flores</Rua>
<Num>45</Num>
<Cidade>Recife</Cidade>
<Estado>PE</Estado>
<Pais>Brasil</Pais>
</Endereco>
<Telefone>9999-9999</Telefone>
<CorreioEletronico>jessica@email.com</CorreioEletronico>
</Contatos>
<Nacionalidade>Brasileira</Nacionalidade>
<Sexo>F</Sexo>

54
 Banco de Dados

<Profissao>Professora</Profissao>
</InformacaoPessoal>
</ficha>

Qual a motivação para a utilização crescente da XML? Entre os motivos para

essa utilização crescente está o aumento do uso de aplicações Web e fato de ser cada
vez mais frequente a utilização de operações de extração, manipulação, integração,
transferência e publicação de dados. De fato, cada vez mais é comum o uso de documentos
XML em aplicações, principalmente àquelas relacionadas à Web, tornando importante a
manipulação desses documentos. Por isso, com o tempo surgiu a necessidade de armazená-
los em um ambiente que forneça recursos de bancos de dados. Porém, dados XML não são
naturalmente adequados para armazenamento em BDs, como pode ser visto na comparação
feita no Quadro 2.

Quadro 2 – Dado BD x Dado XML

Dado de Banco de Dados Dado XML

Representação homogênea Representação heterogênea

Esquema independente dos dados Representação autodescritiva

Totalmente Estruturado Estruturação parcial

Esquema enxuto Esquema Extenso

Assim, surgiu a necessidade de utilização de BDs específicos para armazenar esse

novo tipo de dado ou que deem suporte a esse armazenamento. Assim, surgiram os bancos
de dados XML, que permitem o armazenamento de dados no formato XML. Há dois tipos de
banco de dados XML: os com suporte a XML e os XML nativo.
Bancos de dados com suporte a XML mapeiam todo XML para um banco de dados
tradicional (tal como um BD relacional). Eles aceitam XML como entrada e renderizam XML
como saída, sendo o próprio banco responsável por essa conversão. Exemplos: o Oracle o
PostgreSQL possuiem suporte a XML (biblioteca interna de manipulação XML).
Banco de dados nativos XML possuem documentos XML como unidade de
armazenamento. Utilizam o próprio XML para estruturar, organizar e armazenar as
informações. Ex: Tamino.
Mas qual a vantagem de usar um banco de dados XML? Devido ao aumento de
fluxo de dados entre bancos de dados tradicionais e documentos XML nos sistemas de
informação atuais, fazer uso de banco de dados XML trás uma maior eficiência (e facilidade)
para converter e armazenar dados em XML. Além de melhorar bastante o tempo de resposta
das consultas.

Bancos de Dados Móveis

Em computação móvel, uma unidade móvel está em constante mudança de lugar o

que torna a localização um fator de grande importância. Nestes sistemas, as respostas para
consultas dependem de onde são originadas tornando-as significativamente diferentes de
sistemas fixos sendo necessárias diferentes técnicas que devem considerar as características
dos sistemas móveis. Na verdade, o paradigma de computação móvel tem afetado
conceitos, modelos e premissas tradicionais em várias áreas da ciência da computação. Na
área de redes, é preciso que os dispositivos estejam conectados à rede independente de

55
 Banco de Dados

sua localização, o que é conhecido como computação ubíqua. Na área de engenharia, o

novo paradigma introduziu a noção de código móvel, que significa a capacidade do código
de migrar entre unidades da rede. Em relação aos bancos de dados não é diferente. A
computação móvel introduziu o conceito e a necessidade de os clientes móveis acessarem
seus bancos de dados de qualquer lugar. E que os bancos de dados conseguissem responder
a variação de localidade com rapidez.
Assim, bancos de dados móveis se resumem a uma ou mais base de dados acessada
por unidades móveis. Cada base de dados está localizada em uma outra unidade da
rede, seja ela fixa ou móvel. Se observarmos bem, os bancos de dados móveis são uma
particularidade de BDs distribuídos. Na verdade, todo banco de dados móvel é distribuído,
principalmente, entre os componentes sob a rede com fio, possivelmente com replicação
parcial ou total. Assim, uma estação de base gerencia seu próprio banco de dados com
as funcionalidades inerentes aos SGBDs, com funcionalidades adicionais para localizar
unidades móveis e características adicionais de gerência de consultas e transações, para
atender aos requisitos de ambientes móveis. A responsabilidade sobre a gerência de dados
é compartilhada entre estações de base e unidades móveis.
Um exemplo de aplicação para uso de BD móveis é a consulta dependente
de localidade. Imagine uma família viajando em férias em um estado completamente
desconhecido. As bases de dados sensíveis a localidade poderão estar mantendo
informações sobre os diversos serviços locais, tais como hotéis, postos de gasolina, hospitais
e etc..As bases de dados responderão a pesquisa como “Qual o hotel mais próximo de onde
estamos que aceite o cartão VISA para pagamento?”, ou “Qual é o hospital mais próximo
que possui determinado convênio?”. Estas perguntas podem ser feitas repetidamente e
produzirão respostas diferentes a cada momento, pois dependerão da localidade a partir de
onde a pesquisa foi realizada.
A tecnologia de Sistemas de Bancos de Dados Móveis encontra-se ainda num
patamar emergente, representando um grande desafio para mundo tecnológico.

Considerações Finais

Neste apêndice, apresentamos alguns exemplos de BD-não convencionais que

surgiram para atender propósitos específicos ou devido às necessidades tecnológicas. A
apresentação de cada um dos BDs foi breve, apenas para lhe dar uma ideia do que existe,
mas tanto há muito mais informação sobre cada tipo de BD deste, como a cada dia tanto
novas técnicas e informações sobre os já existentes, como surgem novos tipos de BDs (ex:
BDs dedutivos). Ou seja, BD é uma área ampla para se pesquisar e se você se interessar, vai
ter muito pano pra manga.

Conheça Mais

Existem diversos livros de Banco de Dados que, nos capítulos finais, falam um pouco
sobre os bancos de dados não convencionais. Além dos que indicamos no capítulo 1 deste
fascículo, você pode consultar as seguintes referências:

KIM, W. Modern Database Systems: The Object Model, Interoperability and

Beyond. Addison Wesley, 1995.
RAMAKRISHNNAN, R.; GEHRKE, J. Database Management Systems. McGraw-Hill,
2003.
STONEBRAKER, M. Object-Relational DBMS: The Next Great Wave. 2a ed.,

56
 Banco de Dados

Academic Press. 1998.

BRADLEY, N. XML Companion. 3a ed., Addison-Wesley. 2002.
CHAUDHRI, A. B.; RASHID, A.; ZICARI, R. XML Data Management: Native XML and
XML-Enabled Database Systems. Addison-Wesley. 2003.
CAMARA, Gilberto. Anatomia de Sistemas de Informação geográfica: Visão Atual
e Perspectivas de Evolução. São Paulo, 1993. Anais do Simpósio Brasileiro de
Geoprocessamento, USP, 2005.
CAMARA, Gilberto. Bancos de Dados Geográficos. Mundo Geo. Curitiba – PR, 2005.
EDELWEISS, Nina; OLIVEIRA, José Palazzo M. Modelagem de aspectos temporais de
sistemas de informação. Livro texto da Escola da Nona Computação. Universidade
Federal de Pernambuco, Recife, 1994.
EDELWEISS, N. Bancos de Dados Temporais: Teoria e Prática. Anais do XVIII
Congresso Nacional da SBC (XVII JAI), v.II, 1998. 
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. Editora Érica, 2004.
KIMBALL, R. Data warehouse toolkit: técnicas para construção de data warehouses
dimensionais. Tradução Mônica Rosemberg. Makron Books, São Paulo, 1998.
KIMBALL, R.; REEVES, L.; ROSS, M.; THOMTHWAITE, W. The datawarehouse
lifecycle toolkit: tools and techniques for designing, developing and deploying data
warehouses. Jonh Wiley & Sons, New York, 1998.
INMON, W.H. Building the data warehouse. 2nd ed. John Wiley & Sons, New York,
1996.
MOUNT, D. Bioinformatics: Sequence and Genome Analysis. Cold Spring Harbor
Laboratory, 2001.
JAMBECK, P.; GIBAS, C. Desenvolvendo Bioinformática - Ferramentas de Software
Para Aplicações Em Biologia. Editora: Elsevier Editora LTDA,2001.
Além disso, você pode consultar os seguintes sites:

Sobre Data Warehouse: http://www.datawarehouse.inf.br/

Apresentação sobre BD Temporal: http://www.slideshare.net/sergeduardo/banco-de-
dados-temporais-temporal-database

Notas de Aula sobre Banco de Dados não-convencionais do professor Ronaldo S.

Mello: http://www.inf.ufsc.br/~ronaldo/bdnc/
Reportagem BateByte sobre “O Que é Data Warehouse”, escrita por Carlos Alberto
Sowek: http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=250
Informações sobre alguns bancos de dados biológicos:
Genbank: http://www.ncbi.nlm.nih.gov/
DDJB: http://www.ddbj.nig.ac.jp/
EBI: http://www.ebi.ac.uk/
KEBB: http://www.genome.ad.jp/kegg/

57
 Banco de Dados

Você Sabia?

Que os Banco de Dados Dedutivos (BDD) têm a capacidade de definir regras dedutivas? Ou seja,
eles derivam novos dados a partir das relações básicas existentes no BD, podendo deduzir ou
inferir informações adicional a partir de fatos que já estão armazenados. Pois é...

Atividades e Orientações de Estudo

Sugestão de Atividade de Interação

Discuta com seus colegas, seu tutor e professor sobre o seu conhecimento sobre os
bancos de dados não-convencionais. Tenha como guia as seguintes questões:

1. Você já conhecia, fez uso ou já ouviu falar de algum dos bancos de dados não-
convencionais descritos nesse apêndice? Quais?
2. Entre os especificados nesse capítulo, qual o que você achou mais interessante e
por quê?
3. Há algum outro banco de dados não-convencional que você já ouviu falar que não
foi tratado neste capítulo? Qual(ais)? O que você pode dizer sobre ele(s)?
Você pode aprender muito compartilhando informações com seus colegas!

Vamos Revisar?

Novas aplicações trazem desafios de estruturação de dados nos diversos níveis

de memória, especificação de consultas e manipulações complexas, sobre conjuntos de
dados cada vez maiores. Por isso, surgiu a necessidade de especificar e utilizar novos tipos
de bancos de dados, chamados específicos. Entre esses, descrevemos nesse apêndice os
bancos de dados geográficos, temporais, datawarehouses, biológicos, móveis, multimídia e
os banco de dados XML. A ideia foi lhe dar uma visão geral do que existe e lhe abrir a visão
para novos rumos para pesquisa, se você for um interessando na área de BD.

58
 Banco de Dados

Considerações Finais
Olá, cursista!
Esperamos que você tenha aproveitado este primeiro módulo da disciplina Banco
de Dados.
No próximo módulo, estudaremos como fazer a modelagem dos dados a fim de que
eles possam ser armazenados em um banco de dados. Você vai perceber a importância de
fazer essa modelagem e conhecerá os diversos tipos de modelos e esquemas existentes.
Eu diria que esse é um dos assuntos mais importantes da disciplina, porque uma vez que a
modelagem seja feita de forma errada, o banco de dados será criado de maneira errada e,
consequentemente, você não conseguirá obter dele as informações que gostaria.
Nesse sentido, o final deste módulo já é uma motivação para que você fique
curioso(a) para as próximas reflexões sobre como criar um banco de dados.
Aguardamos sua participação no próximo módulo.
Até lá e bons estudos!
Sandra de Albuquerque Siebra
Professora Autora

59
 Banco de Dados

Referências

SILBERSCHATZ, Abraham; KORTH, Henry F;SUDARSHAN, S. Sistema de banco de

dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
HEUSER, Carlos Alberto. Projeto de Bancos de Dados. 4 ed. Porto Alegre: Sagra
Luzzatto, 2001.
ELMASRI, Ramez;NAVATHE, Shamkant B. Sistemas de banco de dados. Traduzido
por: Marilia Guimarães Pinheiro et al. 4a. ed. São Paulo: Pearson Education do
Brasil, 2005.
DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus,
2000.
BATINI, C.; CERI, S.; NAVATHE, S. B. Conceptual database design: an entity-
relationship approach. San Francisco : Benjamim Cummings, 1992.
COUGO, Paulo Sérgio. Modelagem Conceitual e Projeto de Banco de Dados.
Elsevier Editora, 1997.
DATE, C. J. Banco de dados: tópicos avançados. Rio de Janeiro : Campus, 1988.
DATE, C. J. Introdução a Sistemas de Banco de Dados. Elsevier Editora, 2004.
ELMASRI, R. & NAVATHE, S. B. Sistemas de Banco de Dados. 4. ed., Pearson-
Addison-Wesley, 2005.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. 3. Edição., Porto Alegre: Sagra-
Luzzatto, 2004.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados.
Elsevier Editora, 2006.
LAENDER, A. H. F. ; CASANOVA, M. A. ; TUCHERMAN, L. . On the Design and
Maintenance of Optimized Relational Representations of Entity-Relationship
Schemas. Data & Knowledge Engineering, Amsterdam, v. 11, n. 1, p. 1-20, 1993
Revista SQL Magazine - http://www.sqlmagazine.com.br
SETZER, V. W. Banco de dados. 3.ed. São Paulo : Revista Edgard Blucher, 1989.

60
 Banco de Dados

Conheça a Autora

Sandra de Albuquerque Siebra

Doutora em Ciência da Computação, pelo Centro de Informática da UFPE onde

trabalhou com Ambientes Virtuais de Aprendizagem e Ambientes Colaborativos em Geral.
Ensinou na Faculdade Integrada do Recife (FIR) e na Universidade Católica de Pernambuco
(UNICAP), além de ter trabalhado como gerente de projetos no Centro de Estudos e Sistemas
Avançados do Recife (CESAR). Atualmente, é professora da Universidade Federal Rural de
Pernambuco (UFRPE). Atua na equipe de Educação a Distância da UFRPE e no Departamento
de Estatística e Informática (DEINFO), como professora autora de materiais didáticos para
cursos a distância, já tendo também atuado como coordenadora de curso e professora
executora de disciplinas. Tem experiência, trabalhos desenvolvidos e artigos publicados nas
áreas de Educação a Distância, Interfaces Homem- Máquina, Sistemas Colaborativos, Banco
de Dados, Análise e Projeto de Sistemas Orientados a Objetos, Sistemas de Informação e
Engenharia de Software. Atualmente, desenvolve pesquisas sobre contextualização de
interações em ambientes virtuais de aprendizagem e trabalho cooperativo.

61