volume 1

Prévia do material em texto

Recife, 2010
Banco de Dados
UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)
COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE)
Sandra de Albuquerque Siebra
Volume 1
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
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? .........................................................9
O Sistema Gerenciador de Banco de Dados (SGBD) ......................................................13
Estrutura Geral de um SGBD .........................................................................................16
Classes de Usuários de um Sistema de Banco de Dados ...............................................17
Alguns Exemplos de SGBDs ...........................................................................................18
Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados ............................................ 26
E houve a evolução... .....................................................................................................26
Primeira Geração dos Bancos de Dados ........................................................................27
Segunda Geração dos Bancos de Dados ........................................................................29
Terceira Geração dos Bancos de Dados .........................................................................30
Arquiteturas de Sistemas de Banco de Dados ...............................................................32
Abstração de Dados .......................................................................................................39
Capítulo 3 – Novas Tendências e Perspectivas .............................................................. 46
Classificação dos Bancos de Dados ................................................................................46
O que mais há por aí? ....................................................................................................50
Considerações Finais .................................................................................................... 56
Conheça a Autora ........................................................................................................ 58
4
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
5
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 
6
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
7
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 utiliza-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 comentar sobre 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 seriam 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 trabalhadaspor 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?
8
Banco de Dados
Alguns Conceitos Básicos
Um Banco de Dados (também chamado de Base de Dados) é uma coleção de 
dados relacionados, organizados e armazenados visando facilitar a manipulação dos dados 
armazenados, permitindo realizar alterações, inserções, remoções e consultas. Os tipos de 
“coleções de dados” são ilimitados (ex: dados de um produto, de um estudante, mapas, 
dados sobre genes humanos, etc), ou seja, quaisquer aplicações do mundo real que possam 
ser representadas através de dados computáveis poderão ser armazenadas em um banco 
de dados. Vamos ver agora, algumas definições mais formais:
“Um Banco de Dados é uma coleção de dados operacionais armazenados, sendo 
usados pelos sistemas de aplicação de uma determinada organização” (DATE, 2000).
“Um Banco de dados é um conjunto de dados armazenados, cujo conteúdo 
informativo representa a cada instante, o estado atual de uma determinada aplicação” 
(LAENDER, 1993).
 “Um banco de dados é uma coleção de dados relacionados que representa alguns 
aspectos do mundo real, sendo chamado, às vezes, de minimundo.” (ELMASRI e NAVATHE, 
2005)
Realmente, como definiram ELMASRI e NAVATHE, um banco de dados (abreviado 
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, 
9
Banco de Dados
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 desenvolvidos em 
uma linguagem de aplicação), que foram criados para os usuários finais utilizando-se 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 contendo a definição 
dos dados e outro 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 de que 
para um conjunto de dados é definida apenas uma estrutura, que por suas características 
próprias altera-se pouco. Por exemplo, define-se que o endereço do estudante deve 
ser um campo alfanumérico com capacidade para armazenar 80 caracteres. Já os dados 
armazenados mudam muito uma vez que a cada nova inserção, alteração ou remoção de 
dados, os dados são modificados. Por exemplo, o endereço da estudante Ana Maria é Rua 
das Flores, 320. Mas a qualquer instante esse dado pode ser modificado. Por exemplo, ela 
pode passar a morar na Av. Abdias de Carvalho, 52. Sendo assim, é uma vantagem manter 
separados estes dois arquivos com características distintas. O arquivo contendo a definição 
dos dados é o que podemos chamar de metadados, ou dados sobre os dados. Ou seja, são 
dados cujo significado reflete características dos próprios dados, como por exemplo: de que 
tipo são estes dados? Qual será o tamanho deles? Ele pode ficar em branco ou não? Etc.
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 usadas linguagem de programação diferentes. Qual 
o problema com isso? O problema com isso é que entre os diversos sistemas desenvolvidos 
gradualmente para uma determinada empresa ou instituição poderiam haver dados em 
10
Banco de Dados
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 
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.
11
Banco de Dados
» 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 
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 
12
Banco de Dados
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
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 deconsistir 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 
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 
14
Banco de Dados
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. 
» Privacidade dos Dados – um SGBD deve fornecer um subsistema de autorização 
e segurança (por exemplo, através de senhas e sistemas de LOG e AUDIT1, o qual 
é utilizado pelo DBA para criar “contas” e especificar as restrições destas contas; 
o controle de restrições se aplica tanto ao acesso aos dados quanto ao uso de 
softwares inerentes ao SGBD. Dessa forma, torna-se possível definir, para cada 
usuário, o nível de acesso a ele concedido (leitura, leitura e gravação ou sem acesso) 
a tabela e/ou campo. Este recurso impede que pessoas não autorizadas utilizem ou 
atualizem uma 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 
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 
Saiba Mais
1Sistemas de LOG e 
AUDIT registram dados 
sobre as operações 
que são efetuadas 
no BD, tais como: 
data, hora, usuário, 
comando que foi 
utilizado, campo 
que foi afetado pelo 
comando, etc. 
15
Banco de Dados
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çãoa 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 
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 
16
Banco de Dados
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.
Figura 9 - Estrutura Geral do SGBD
Pré-compilador da DML - converte comandos da DML2 embutidos em um aplicativo 
para chamadas de procedimentos normais na linguagem hospedeira do BD. O pré-
compilador precisa interagir com o processador de consultas pra gerar o código apropriado.
Compilador DDL3 - converte comandos da DDL em um conjunto de tabelas 
contendo metadados (“dados sobre dados”), que são armazenados no Dicionário de Dados.
Processador de consultas - traduz os comandos em uma linguagem de consulta 
para instruções de baixo nível que o gerenciador do banco de dados pode interpretar. Além 
disso, o processador de consultas tenta transformar uma requisição do usuário em uma 
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 os programas aplicativos e de consulta submetidos ao sistema.
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 
Saiba Mais
2 Comandos DML 
(Data Manipulation 
Language) incluem 
comandos para inserir, 
atualizar, consultar e 
excluir dados do banco 
de dados.
Saiba Mais
3 DDL (Data Definition 
Language) ou 
linguagem de definição 
de dados inclui 
comandos para a 
criação e manutenção 
das bases de dados.
17
Banco de Dados
e outros.
Índices - proporcionam acesso rápido aos itens de dados com valores específicos. 
São estruturas que permitem um acesso mais eficiente aos dados
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 próprio SGBD e software 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 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á(ao) 
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:
› 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 
18
Bancode Dados
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:
» 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/
servidor) possuindo grande variedade de distribuições (para Macintosh, Windows, 
Linux, FreeBSD, Unix) e para computadores de grande porte. Foi um dos primeiros 
a fazer parte do mercado Web. Nele a linguagem padrão é a SQL, mas possui 
também uma linguagem própria para desenvolvimento de aplicações, a PL/SQL4. 
A participação do Oracle no mercado de Banco de Dados é bastante acentuada, 
principalmente em grandes empresas e em conjunto com sistemas de médio e 
grande porte. É um SGBD robusto e seguro, quando bem administrado. Além da 
base de dados, a Oracle desenvolve uma suíte de desenvolvimento chamada de 
Oracle Developer Suite, utilizada na construção de programas de computador 
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/
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). 
Saiba Mais
4 PL/SQL (Procedural 
Language/Structured 
Query Language) é 
uma extensão da 
linguagem padrão 
SQL para o SGBD 
Oracle da Oracle 
Corporation. É uma 
Linguagem Procedural 
da Oracle que 
estende a linguagem 
SQL e permite que 
a manipulação de 
dados seja incluída 
em unidades de 
programas.
19
Banco de Dados
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 
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?
20
Banco de Dados
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 possibilidadede 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 
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.
21
Banco de Dados
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 
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
22
Banco de Dados
T1
1 Ler (A);
2 A = A - 30;
3 Escrever (A);
4 Ler (B)
5 B = B + 30;
6 Escrever (B)
A transação T1, pertencente a um sistema bancário 
e é definida pelas operações listadas na tabela ao lado. Ela é 
responsável pela transferência de R$ 30,00 da conta A para 
a conta B. Considere também uma transação T2 que esteja 
sendo executada simultaneamente a T1. Caso a transação 
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 
propriedades das transações estará sendo violada no banco de 
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.
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 em um documento de texto (doc) e poste as 
respostas no ambiente virtual, no local indicado.
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 que uma transação?
3. O que são metadados? Dê exemplos.
23
Banco de Dados
4. Que problemas podem ser causados pela falta de padronização dos dados 
armazenados?
5. Qual a importância do controle de redundância?
Atividades de Interação
Usando o fórum da apropriado, discuta com seus colegas, com o professor e o tutor 
sobre seu conhecimento sobre Banco de Dados. Tenha como guia as seguintes questões:
Você já conhecia alguma coisa sobre o tema Banco de Dados? Se sim, o que? E 
como ficou sabendo (fez curso, leu sozinho, etc)?
Você já fez uso de algum banco de dados na prática? Se sim, qual(ais)? Em que 
situação fez uso?
Participe! Responda, discuta, pergunte! Lembre-se que este é um fórum temático 
e fará parte da sua avaliação somativa.
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õessã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.
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 
24
Banco de Dados
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 forma 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 os banco de dados orientado a objetos e objeto-relacional. A seguir, 
detalharemos cada uma dessas gerações.
Figura 10 - Evolução dos Bancos de Dados
27
Banco 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
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 a regra que “cada filho só pode 
ter um único pai”.
28
Banco de Dados
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;
» Complexidade dos diagramas de estrutura de árvore;
» Não pode haver ciclos no gráficobá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 à 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 sistema 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 
29
Banco de Dados
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
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;
30
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 
(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. 
31
Banco de Dados
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 
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 
32
Banco de Dados
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 
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.
Arquiteturas de Sistemas de Banco de Dados
A arquitetura dos sistemas de banco de dados é influenciada pela arquitetura dos 
sistemas computacionais, levando em consideração aspectos como:
» Redes de computadores, cujo surgimento colaborou para a divisão de tarefas entre 
máquinas remotas, em que uma assume papel de cliente e outra de servidor, 
levando a uma arquitetura cliente-servidor;
» Paralelismo, que consiste na possibilidade de executar atividades simultaneamente, 
obtendo melhores tempos de resposta e executando uma maior quantidade de 
transações por segundo;
» Distribuição, em que os dados residem na localidade em que são gerados ou 
em que serão mais úteis, por meio de diversas cópias do banco de dados. Uma 
33
Banco de Dados
arquitetura distribuída possibilita uma maior disponibilidade dos dados, que 
podem ser acessados ainda que uma determinada localidade enfrente problemas e 
se torne indisponível.
Como consequência do emprego desses aspectos, temos as arquiteturas 
centralizadas, cliente-servidor, distribuída e paralela que iremos descrever a seguir.
Arquiteturas Centralizadas
As primeiras arquiteturas usavam mainframes6 para executar o processamento 
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 
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 dosistema 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.
Saiba Mais
6 Mainframes são 
computadores 
de grande porte, 
dedicados, 
normalmente, ao 
processamento de 
um volume grande de 
informações. 
Os mainframes 
são capazes de 
oferecer serviços de 
processamento a 
milhares de usuários 
através de milhares de 
terminais conectados 
diretamente ou 
através de uma rede. 
Embora venham 
perdendo espaço 
para os servidores 
de arquitetura PC e 
servidores Unix, de 
custo bem menor, 
ainda são muito 
usados em ambientes 
comerciais e em 
grandes empresas, 
tais como: bancos, 
empresas de aviação e 
universidades.
34
Banco de Dados
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 
mantém os arquivos de máquinas clientes) ou servidores de impressão (que podem 
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 
para o usuário as interfaces apropriadas para utilizar esses servidores, bem como poder de 
processamento para executar aplicações locais. Esta arquitetura se tornou muito popular 
por algumas razões. 
» Primeiro, a facilidade de implementação dada à clara separação das funcionalidades 
e dos servidores. 
» Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples 
são delegadas às máquinas clientes, que são mais baratas. 
» Terceiro, o usuário pode executar uma interface gráfica que lhe é familiar, ao invés 
de usar a interface do servidor. 
Diferentes técnicas foram propostas para implementar essa arquitetura, sendo 
que a mais adotada pelos SGBDs relacionais comerciais é a inclusão da funcionalidade de 
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 
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 
linguagem SQL), prover a interface para o usuário e as funções da interface usando uma 
linguagem de programação. Comumente, o servidor SQL também é chamado de back-end 
machine e a máquina cliente de front-end machine. 
Resumindo com outras palavras, na arquitetura Cliente-Servidor, o cliente (front_
end machine) executa as tarefas do aplicativo, ou seja, fornece a interface do usuário (tela 
e processamento de entrada e saída), ferramentas de relatório, geração de formulários, 
análise e mineração de dados. Já o servidor (back_end machine) executa as consultas no 
SGBD e retorna os resultados ao cliente, ficando responsável por tarefas como o controle de 
acesso, otimização de consultas, controle de concorrência, recuperação, etc.
Como SQL provê uma linguagem padrão para os SGBDs Relacionais, esta criou o 
ponto de divisão lógica entre o cliente e o servidor. Dessa forma, a comunicação entre a 
front-end machine e o back-end machine é realizada por meio da linguagem SQL e por 
meio de uma API7 que possibilita a conexão e a comunicação entre as máquinas cliente e 
servidora. Exemplos de APIs são os padrões ODBC8, JDBC9 que vão justamente servir para a 
comunicação de programas escritos em uma linguagem de programação com os SGBDs. 
Quando um programa escrito em uma linguagem de programação faz uso de 
uma API (tudo isso no lado do cliente) para acesso a um banco de dados que está em uma 
máquina servidora (vide Figura 18), dizemos que se está usando uma arquitetura cliente-
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 
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 
uma camada intermediária (a segunda camada), processando as solicitações dos usuários 
e fornecendo respostas obtidas através do acesso ao servidor de banco de dados (que é 
Saiba Mais
7 Uma API (Application 
Programming 
Interface ou Interface 
de Programação de 
Aplicativos) é um 
conjunto de rotinas e 
padrões estabelecidos 
por um software 
para a utilização das 
suas funcionalidades 
por programas 
aplicativos que não 
querem envolver-
se em detalhes da 
implementação do 
software, mas apenas 
usar seus serviços
Saiba Mais
8 ODBC (Open Data 
Base Connectivity) 
é um padrão para 
acesso a SGBDs. Este 
padrão define um 
conjunto de interfaces 
que permitem o 
uso de linguagens 
de programação 
como Visual Basic, 
Delphi, Visual C++, 
entre outras capazes 
de utilizar estas 
interfaces, para ter 
acesso a uma vasta 
gama de banco de 
dados distintos sem 
a necessidade de 
codificar métodos de 
acesso especializados. 
O uso destas interfaces 
está condicionado à 
existência de drivers 
ODBC específicos para 
as bases de dados que 
se deseja acessar.
Saiba Mais
9 JDBC (Java Database 
Connectivity) é 
uma API escrita em 
Java e usada com 
a linguagem JAVA 
para fazer o envio de 
instruções SQL para 
qualquer banco de 
dados relacional. É o 
equivalente do ODBC 
para a linguagem JAVA.
35
Banco de Dados
a terceira camada), que continua sendo o responsável pela realização de consultas e 
transações no SGBD. Sistemas que lidam com grande quantidade de usuários adotam essa 
arquitetura em três camadas.
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 
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
36
Banco de Dados
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 consultandoa 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 
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:
37
Banco de Dados
» 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 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
» 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 vantagens 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
38
Banco de Dados
» 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 
desvangagem é 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 
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.
39
Banco de Dados
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 deveprover 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, 
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 
40
Banco de Dados
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.
» 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 de dados física. 
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 
41
Banco de Dados
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.
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 gerenciadoresde 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.
42
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:
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.
43
Banco 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 em um documento texto (doc) e poste no ambiente 
virtual, no local indicado. 
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.
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 
44
Banco de Dados
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.
45
Banco de Dados
Capítulo 3
O que vamos estudar neste capítulo?
Neste capítulo, vamos estudar os seguintes temas:
» Tipos de Banco de Dados
» Perspectivas
Metas
Após o estudo deste capítulo, esperamos que você:
» Reconheça os diferentes tipos de Banco de Dados do mundo atual
» Desperte a curiosidade para as novas perspectivas da área de Banco de Dados
46
Banco de Dados
Capítulo 3 – 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 tipso de dados. É justamente sobre 
esses novos tipos de SGBDs que vamos tratar neste capítulo”
Neste capítulo, 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, deixaremosindicadas 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 
47
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 georeferenciados, 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 
climatológica.
O que diferencia os SGBDGs dos demais sistemas capazes de manipular dados 
espaciais como, por exemplo, softwares de CAD10, é a capacidade de realizar operações 
complexas de análise sobre dados espaciais. 
E o que é armazenado em um SGBD geográfico? Geralmente, a modelagem de um 
SGBDG consiste em referenciar objetos representados em mapas. Estes objetos podem 
ser constituídos de informações espaciais e informações não espaciais (vide Figura 26). As 
informações espaciais estão georeferenciadas, tal como o local de uma área de plantação e 
as não espaciais representam as informações descritivas, como o tipo de cultura plantada 
na área e o nome do proprietário. 
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 é uma 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. 
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 
Saiba Mais
10 Computer-Aided 
Design (CAD) ou 
desenho assistido por 
computador, é o nome 
genérico de sistemas 
computacionais 
(softwares) utilizados 
pela engenharia, 
geologia, arquitetura, 
e design para facilitar 
o projeto e desenho 
técnicos.
48
Banco de Dados
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; 
» 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);
49
Banco de Dados
» 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 forma 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 
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 
50
Banco de Dados
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.
Que aplicações fazem uso desse tipo de SGBD? A utilização de um BD temporal se 
faz necessária em tempos onde a riqueza dos dados é fundamental para a análise e obtenção 
de informações, ampliando a capacidade de sistemas que fazem o cruzamento de dados/
informações. Exemplos de aplicações que são beneficiadas pelo uso de BD temporal são os 
SIGs (Sistemas de Informações Gerenciais), Dataminer (sistemas de mineração de dados), 
Datawarehouses, Sistemas de Suporte a Decisão tais como as aplicações de BI (Business 
Intelligence11), aplicações da área médica (por exemplo, para manter o registro do quadro 
clínico ou o acompanhamento do diagnóstico de pacientes), aplicações da área empresarial 
(ex: tomada de decisões e planejamento de orçamentos), dentre outras. 
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 
inserida no Oracle, oferecem recursos para que informações temporais possam ser inseridas 
aos dados em banco de dados. 
O que mais há por aí?
E ainda há mais? Há sim. Há vários bancos de dados surgindo tanto pela necessidade 
criada por uma área específica (por exemplo, os bancos de dados biológicos), como também 
surgindo pela própria evolução da tecnologia (tais como os bancos de dados XML e os banco 
de dados móveis). Vamos apresentar mais esses exemplos. 
Bancos de Dados Biológicos
A quantidade de bancos de dados em Biologia Molecular vem crescendo 
exponencialmente nos últimos anos, e o aspecto funcional da bioinformática12 é a 
representação, o armazenamento e a distribuição de dados. Os objetivos destes bancos 
variam e podem ser utilizados para armazenar e disponibilizar biosequências, funções 
moleculares, estruturas de proteínas, modelos metabólicos, entre outros, oferecendo em 
alguns casos informações mais amplas. Em alguns casos, as informações biológicas sã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 entendimentocontribui 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 
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:
Saiba Mais
11 Business Intelligence 
(BI) pode ser traduzido 
como “Inteligência de 
negócios”, refere-se 
ao processo de coleta, 
organização, análise, 
compartilhamento 
e monitoramento 
de informações que 
oferecem suporte à 
gestão de negócios.
Saiba Mais
12 Bioinformática 
é o campo da 
ciência no qual a 
Biologia, a Ciência 
da Computação 
e a Tecnologia da 
Informação convergem 
em uma única 
disciplina. Esse campo 
surgiu da necessidade 
de formação de um 
profissional que 
tivesse conhecimento 
suficiente para 
saber quais eram os 
problemas biológicos 
reais e quais seriam 
as opções viáveis de 
desenvolvimento 
e abordagem 
computacional 
dos problemas em 
questão.
51
Banco de Dados
» 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, 
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 
dados. É um padrão aberto desenvolvido pela W3C (World Wide Web Consortium), que é 
responsável pela definição de padrões para a Web. É um consórcio formado pela academia 
e pela indústria. Os dados no formato XML são descritos em um documento XML. Mas qual 
o formato de um documento XML? Veja, a seguir, um exemplo de um documento XML 
representando a ficha de um cliente:
<?xml version=”1.0” encoding=”UTF-8”?> 
<ficha> 
 <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> 
 <Profissao>Professora</Profissao> 
 </InformacaoPessoal> 
</ficha>
Qual a motivação para a utilização crescente da XML? Entre os motivos para 
Saiba Mais
13 Linguagem de 
marcação de dados 
é aquela que utiliza 
tags para descrição 
dos dados (uma tag 
indica a intenção do 
dado e delimita o 
seu conteúdo). Outro 
exemplo de linguagem 
de marcação é a 
linguagem HTML.
52
Banco de Dados
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 
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.
53
Banco de Dados
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 requisitosde 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 capítulo, 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., 
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 
54
Banco de Dados
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/
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 é... 
55
Banco de Dados
Atividades e Orientações de Estudo
Atividades de Interação
Discuta no fórum da semana sobre o seu conhecimento sobre os banco de dados 
convencionais. Tenha como guia as seguintes questões:
1. Você já conhecia, fez uso ou já ouviu falar de algum dos banco de dados não-
convencionais descritos nesse capítulo? 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)?
Este é um fórum temático, logo, ele fará parte da sua avaliação somativa. Logo, não 
deixe de participar! Além disso, 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 capítulo 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.
56
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
57
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 Conceituale 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.
58
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.