Banco de Dados - 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 e Elias Vieira
Ilustrações: Noé Aprígio
Coordenação de Produção: Marizete Silva Santos
Sumário
Apresentação ................................................................................................................. 4
Conhecendo o Volume 1 ................................................................................................ 5
Capítulo 1 – Banco de Dados: Por onde começar? .......................................................... 7
Alguns Conceitos Básicos .................................................................................................8
Como era antes de surgirem os bancos de dados? .......................................................10
O Sistema Gerenciador de Banco de Dados (SGBD) ......................................................14
Estrutura Geral de um SGBD .........................................................................................17
Classes de Usuários de um Sistema de Banco de Dados ...............................................18
Alguns Exemplos de SGBDs ...........................................................................................19
Capítulo 2 – Evolução e Arquitetura dos Bancos de Dados ............................................ 27
E houve a evolução... .....................................................................................................27
Primeira Geração dos Bancos de Dados ........................................................................28
Segunda Geração dos Bancos de Dados ........................................................................31
Terceira Geração dos Bancos de Dados .........................................................................32
Arquiteturas de Sistemas de Banco de Dados ...............................................................34
Abstração de Dados .......................................................................................................41
Apêndice A – Novas Tendências e Perspectivas ............................................................ 49
Classificação dos Bancos de Dados ................................................................................49
O que mais há por aí? ....................................................................................................53
Considerações Finais .................................................................................................... 59
Conheça a Autora ........................................................................................................ 61
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 utilizá-los no seu dia-a-dia, você 
será, com certeza, um usuário de Banco de Dados. Então, que tal conhecer esses tais Bancos 
de Dados mais a fundo? Começaremos a fazer isso nesse capítulo.”
Neste capítulo, vamos apresentar os conceitos básicos da área de Banco de Dados. 
Como comentado acima, essa é uma área muito presente no nosso dia-a-dia e que ganha 
ainda mais importância quando paramos para pensar que estamos vivendo na chamada 
“Era da Informação”, onde o conhecimento adquirido a partir da avaliação das informações 
é o maior bem de qualquer empresa ou instituição. E informações são obtidas a partir de 
dados que precisam estar armazenados em algum lugar. Você poderia me perguntar: mas 
dados e informações não são a mesma coisa? Não, não são. Vamos diferenciar.
Dado é um elemento que mantém a sua forma bruta (texto, imagens, sons, vídeos, 
etc.) e ele sozinho não levará a compreender determinada situação. Ou seja, o termo 
“Dado” envolve fatos, imagens, sons que podem ou não serem úteis para determinado 
fim, eles apenas representam coisas do mundo real. Já a “Informação” é o conjunto de 
dados coletados de forma a se tornarem aplicáveis a determinada situação, ou seja, sua 
forma e conteúdo são apropriados para um uso específico. A informação não existe por 
si só, ela é obtida através de uma interpretação realizada sobre um grupo de dados. Além 
disso, ela necessita de uma situação ou objetivo que justifique a sua existência. Vamos dar 
alguns exemplos. O nome de um cliente, o número de peças em um estoque, o número de 
horas trabalhadas por um empregado e o valor total de um pedido são dados. Já o valor 
total das vendas por mês de uma loja é uma informação que para ser obtida vai precisar 
considerar uma série de dados (tais como, o mês de cada pedido e o valor total do pedido) 
armazenados em algumlugar.
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 por alguns autores de Base de Dados) 
é uma coleção de dados relacionados, organizados e armazenados visando facilitar sua 
posterior manipulação e a realização de consultas. Em outras palavras, um banco de dados 
é uma coleção de dados interrelacionados, representando informações sobre um domínio 
específico. Os tipos de coleções de dados que podem ser armazenados são ilimitados (ex: 
dados de um produto, de um estudante, mapas, dados sobre genes humanos, etc.).
Realmente, um banco de dados (abreviado daqui para frente como BD) é um 
modelo de uma determinada parte da realidade, geralmente denominada de Universo 
de Discurso ou minimundo. Isso porque só devemos colocar no banco de dados as 
informações do domínio que sejam relevantes para a resolução de um problema ou para 
obter determinadas informações. Vamos dar um exemplo. Suponha que precisamos 
criar um banco de dados para uma Livraria. O minimundo da Livraria englobaria diversas 
características que a definem como, por exemplo, o seu nome, a sua localização, os dados 
dos seus proprietários, os dados dos funcionários que trabalham lá, os dados dos livros 
disponíveis e de qualquer outro produto que esteja sendo comercializado. Isso porque essas 
informações são interessantes para serem armazenadas e, posteriormente recuperadas. 
Porém, por exemplo, as cores das paredes da livraria, o material de que é feito o chão, não 
são características relevantes para serem consultadas em um sistema, logo, não fariam parte 
dos dados a serem armazenados no banco de dados. Logo, o minimundo será justamente 
a especificação da parte do mundo real que é relevante para a implementação da livraria 
(vide Figura 1) e deverá conter informações que caracterizem o domínio do negócio.
Figura 1 - O Mundo Real x MiniMundo
Um banco de dados pode ser criado e mantido por um conjunto de aplicações 
desenvolvidas especialmente para esta tarefa (por exemplo, no caso da livraria, poderia 
existir um Sistema Controle de Livraria para gerenciar o acesso ao Banco de Dados) ou por 
um Sistema Gerenciador de Bancos de Dados (SGBDs ou DBMS – Database Management 
System). Um SGBD é um pacote de software designado para guardar e gerenciar um banco 
de dados. É ele que realiza a manipulação dos dados armazenados em um BD. O SGBD 
tem uma gama de funções pré-implementadas que gerenciam as operações de inserção, 
remoção, atualização e consulta dos dados armazenados. 
O conjunto formado por um banco de dados mais as aplicações que o manipulam (o 
SGBD) é chamado de Sistema de Banco de Dados (SBD). Pode-se definir esse sistema como 
um ambiente cujo objetivo global é registrar e manter informação. A Figura 2 representa 
o ambiente de um sistema de banco de dados, que interage com os programadores 
(as pessoas que o desenvolveram) e com os usuários finais (as pessoas que o utilizarão). 
Num primeiro nível, as pessoas interagem com os programas de aplicação (programas 
9
Banco de Dados
desenvolvidos em uma linguagem de programação como Java, C#, PHP, etc.), que foram 
criados para os usuários finais e que, para acesso ao BD, fazem uso de uma linguagem de 
consulta (linguagem própria para acesso ao banco de dados). Esta aplicação interage com 
o SGBD, que possui programas responsáveis por processar as consultas e acessar os dados 
armazenados, dentre outras funções. Por fim, num nível mais interno, encontra-se a base de 
dados, separada em dois arquivos distintos:
» Um arquivo contendo a definição dos dados (informações sobre os dados ou 
metadados) – este arquivo irá conter informações, como: qual o tipo do dado 
armazenado, qual o tamanho dele, se ele pode ficar em branco ou não, etc.
» E outro arquivo contendo os dados propriamente ditos, ou seja, os dados 
armazenados.
Figura 2 - Sistema de Banco de Dados
A separação da base de dados em dois arquivos distintos deve-se ao fato que, 
geralmente, a estrutura (definição) dos dados altera-se pouco depois de criada e os dados 
armazenados, costumam serem manipulados e alterados mais frequentemente. Vamos dar 
um exemplo. Pode ser definido que serão armazenados no banco de dados a matricula, o 
nome e o endereço de cada estudante. No arquivo de definição de dados, seria especificado 
que um estudante seria representado por:
» Um campo chamado matricula do tipo numérico, de tamanho 6 e com 
preenchimento obrigatório;
» Um campo chamado nome do tipo alfanumérico, de tamanho 50 e com 
preenchimento obrigatório; e
» Um campo chamado endereço do tipo alfanumérico de tamanho 50 e com 
preenchimento opcional.
Já no arquivo de dados armazenados, estaria o preenchimento dessa definição para 
cada estudante cadastrado. Por exemplo, poderiam estar armazenados neste arquivo os 
valores:
» 123456, “Ana Maria Gomes”, “Rua das Flores, 56”;
» 234567, “Jorge Tavares”, “Rua Vasco da Gama, 789”.
10
Banco de Dados
Observe que os dados armazenados devem seguir a definição (tipo, tamanho, etc.) 
especificada no arquivo de definição de dados. Observe também que, pela natureza dos 
dados armazenados, eles tendem a ter vários valores para a mesma definição (ex: cada 
estudante cadastrado obedece a mesma definição feita para um estudante) e eles são mais 
variáveis que a definição dos dados, visto que, por exemplo, um estudante pode mudar de 
endereço (ex: o endereço da estudante Ana Maria poderia ser modificado para Av. Abdias 
de Carvalho, 52), mas a definição do endereço continuaria a mesma (um campo do tipo 
alfanumérico de tamanho 50 e com preenchimento opcional). Dessa forma, por terem 
naturezas distintas, é interessante manter estes dois arquivos separados.
Como era antes de surgirem os bancos de dados?
Antes de existirem os bancos de dados, qualquer sistema, programa ou aplicação 
que precisasse armazenar e manipular dados fazia uso de um sistema de arquivos. Ou 
seja, cada sistema, programa ou aplicação desenvolvido tinha seus próprios arquivos de 
armazenamento dos dados. Geralmente, naquela época, os programas eram escritos 
em respostas às necessidades, ou seja, iam sendo desenvolvidos na medida em que 
as necessidades apareciam e muitas vezes eram desenvolvidos por programadores 
diferentes. Qual a implicação disso? Diferentes Programadores pensam e programam de 
forma diferente. Desse modo, os arquivos de cada programa desenvolvido poderiam estar 
em formatos diferentes e poderiam ter sido criados usando linguagens de programação 
diferentes. Qual o problema com isso? O problema com isso é que se uma mesma empresa 
ou instituição desenvolve diversos sistemas, gradualmente, esses sistemas podem vir a ter 
dados em comum. Vamos dar um exemplo: suponha uma fábrica que possui um Sistema 
de Vendas, um Sistema de Produção e um Sistema de Engenharia (vide Figura 3). Cada 
um deles teria seus próprios arquivos e nesses arquivos poderia existir em comum, por 
exemplo, os dados de um produto, que por causa dessa organização precisaria ser replicado 
em cada sistema de arquivos. E qual a consequência dessa replicação de dados dentro de 
uma mesma fábrica? 
Figura 3 - Exemplo de sistemas que fazem uso de um Sistema de Arquivos
A consequência é que essa redundância poderia acarretar inconsistência dos 
dados, uma vez que a mesma informação poderia estar duplicada em diversos arquivos (no 
exemplo, os dados do produto). Vamos dar um exemplo. Vamos supor que nos arquivos de 
Vendas, eu atualizei o nome do produto 01 de Mesa para Cadeira. Se eu desejasse manter a 
consistência, eu teria de entrar nos arquivos de Produção e de Engenharia e fazer a mesma 
11
Banco de Dados
atualização. Se não fizesse, os dados do produto na fábrica ficariam inconsistentes, pois 
dependendo do sistema acessado o produto 01 poderia ser Mesa ou Cadeira. Ficouclaro? 
Além disso, a duplicação de dados em diversos sistemas de arquivos leva a um maior custo 
de armazenamento (lembre, você está armazenando diversas vezes os mesmos dados) e 
a necessidade de redigitação de dados (e esse trabalho repetitivo pode levar a erros, que 
também geram inconsistências entre os dados). Adicionalmente, o uso de sistemas de 
arquivos possui outros problemas tais como:
» Dificuldade do acesso a dados – a geração de informação pode surgir, durante o 
tempo em que o sistema está em produção, sob diferentes aspectos. Cada requisição 
de informação diferente, no sistema de arquivos, vai gerar a necessidade da criação 
de um programa aplicativo, de uma nova consulta ou de um novo relatório. Dessa 
forma, a recuperação de informação não é atendida de modo eficiente. Haveria 
dificuldade em apagar informações dos sistemas. Poderia novamente ocorrer casos 
de incosistência, onde um produto poderia ser deletado dos arquivos de Vendas, 
mas não dos outros dois arquivos (Engenharia e Produção).
» Isolamento dos dados – os dados estão armazenados em arquivos distintos, que 
não possuem qualquer tipo de relacionamento direto, e ainda, podem conter 
diferentes formatos para o mesmo dado. Por exemplo, o código do produto nos 
arquivos de venda poderia ser representado só por números e nos arquivos de 
Produção por letras e números.
» Problemas de integridade – fica difícil manter restrições de integridade 
automaticamente. E o que são essas restrições de integridade? Seriam checagens de 
determinadas condições a serem feitas pelo sistema sobre os dados armazenados 
(por exemplo, a quantidade de produtos em estoque não pode ser inferior a um 
valor X). Essas restrições teriam de ser mantidas pelo sistema, implicando em 
implementação do código apropriado para fazer esse tipo de checagem em CADA 
UM dos sistemas afetados. O problema seria que a cada inclusão de uma nova 
restrição de integridade, um novo código deveria ser escrito EM CADA SISTEMA 
para poder mantê-la, já que cada sistema trabalha com um diferente sistema de 
arquivos.
» Problemas de segurança - Nem todos os usuários do sistema devem estar 
autorizados a ver/acessar todos os dados armazenados. Porém, uma vez que os 
programas de aplicação são inseridos no sistema como um todo, de forma aleatória 
(à medida que a necessidade surge, lembra?) é difícil implementar e garantir a 
efetividade de regras de segurança.
» Anomalias no acesso concorrente - a melhora de desempenho em um sistema 
pode ocorrer pela execução simultânea de diversas operações. Geralmente, nos 
sistemas de arquivos, esta melhoria seria difícil de implementar sem levar a danos 
na consistência dos dados. Ou seja, seria difícil permitir que múltiplos usuários 
possam ter acesso aos dados ao MESMO TEMPO. Vamos dar um exemplo. Considere 
um sistema bancário (com a existência de contas correntes, agências, transações 
bancárias, etc) e a seguinte situação: suponha que o saldo de uma conta bancária 
C1 seja 500 reais. Se dois clientes retiram fundos desta conta C1 AO MESMO 
TEMPO (acesso concorrente à conta C1), um estado inconsistente pode ocorrer se 
na execução das duas instâncias do programa de débito, ambos os clientes lerem o 
saldo inicial original e retirarem, cada um, seu valor correspondente, e seja então 
armazenado o valor restante. Instanciando o problema:
1. Ambos leem o valor do saldo 500;
2. Um retira 50 reais (resultando 450 reais) e o outro 100 reais (resultado 400 
12
Banco de Dados
reais) – lembre que ambos estão realizando a operação em cima dos 500 reais 
iniciais que foi lido;
3. Dependendo de qual execução do programa de débito registre o saldo restante 
primeiro, o valor do saldo da conta será 450 ou 400 reais, quando, na verdade, 
deveria ser 350 reais.
Outros problemas existentes são:
» A definição das estruturas dos arquivos está inserida no próprio código dos 
programas, sistemas ou aplicativos, dificultando a manutenção;
» Compartilhamento de um arquivo por vários programas fica comprometido. Há a 
necessidade de duplicar a definição das estruturas dos arquivos nos programas;
» Podem existir arquivos e programas de um mesmo sistema desenvolvidos, de 
forma isolada, por diferentes programadores de forma diferentes e, até mesmo, em 
linguagens de programação diferentes.
Justamente a necessidade de resolver diversos desses problemas motivou a criação 
dos bancos de dados e dos sistemas gerenciadores de banco de dados. Com eles, os dados 
só necessitam ser armazenados uma única vez e passam a ser acessados por todos os 
sistemas (vide Figura 4)
Figura 4 - Exemplo de Sistemas fazendo uso de um Banco de Dados
Que tal recapitular com outras palavras, de forma resumida, o que foi 
apresentado?
No início da computação, os programas tinham o único objetivo de armazenar e 
manipular dados. Esses programas gravavam seus dados em arquivos em disco, segundo 
estruturas de dados próprias (vide Figura 5). Programas que não conhecessem a estrutura 
dos dados não podiam utilizar os dados.
Figura 5 - Programa acessando seu arquivo
13
Banco de Dados
Se vários programas precisassem compartilhar os dados de um mesmo arquivo, eles 
todos teriam que conhecer e manipular as mesmas estruturas de dados (vide Figura 6). Ou 
seja, toda a definição dos dados deveria estar dentro dos programas que os manipulariam.
Figura 6 - Vários programas acessando os dados tinham de conhecer sua estrutura
Se um programa precisasse realizar alguma mudança na estrutura de dados, todos 
os programas que acessam os dados tinham que ser alterados, mesmo que a alteração 
ocorresse em dados não manipulados pelos outros programas. Isso gerava um grande 
problema: Como garantir a unicidade das estruturas de dados entre os diversos programas 
devido à existência de redundâncias? Para evitar esse problema, colocou-se um sistema 
intermediário que deveria conhecer a estrutura de dados do arquivo manipulado; que 
deveria fornecer apenas os dados que cada programa necessitasse e deveria armazenar 
adequadamente os dados de cada programa (vide Figura 7).
Figura 7 - Acesso ao arquivo através de um sistema intermediário
Agora, através do uso desse sistema intermediário:
» Os programas passariam a enxergar apenas os dados que lhes interessam.
» Os programas não precisariam conhecer os detalhes de como seus dados estão 
gravados fisicamente.
» Os programas não precisariam ser modificados se a estrutura de dados que utilizam 
não for modificada.
» As alterações ficariam concentradas nesse sistema intermediário.
Com o tempo, esse sistema intermediário passou a gerenciar vários arquivos (vide 
Figura 8) e a essa coleção de arquivos foi dado o nome de Banco de Dados e ao sistema 
intermediário deu-se o nome de Sistema Gerenciador de Banco de Dados (SGBD).
14
Banco de Dados
Figura 8 - SGBD gerenciando o acesso aos arquivos usados pelos programas
Que tal? Ficou mais claro? Espero que sim! Vamos detalhar agora os SGBDs...
O Sistema Gerenciador de Banco de Dados (SGBD)
Vimos anteriormente neste capítulo que um Sistema de Banco de Dados (SBD) 
é o conjunto formado por um banco de dados (BD) mais as aplicações que o manipulam 
(o SGBD). Assim, um SGBD é uma coleção de programas que habilitam usuários a criar e 
manter um banco de dados. Ele é um software de propósito geral, que facilita o processo de 
definição, construção e manipulação de um banco de dados. 
› Definição do banco de dados envolve especificar estruturas e tipos de dados para 
serem gravados no banco de dados, com uma descrição detalhada de cada tipo de 
dado.
› Construção do banco de dados é o processo de consistir e gravar inicialmente 
dados no banco de dados.
› Manipulação de um banco de dados inclui funções como consulta por dados 
específicos e atualização para refletir as alterações no mundo real.
Quais características esse software deve ter? Vamos apresentá-las a seguir:
» Independência de Dados - consiste na capacidade de tornar as características físicas 
dos dados (como localização,estrutura e tamanho) transparentes para a aplicação. 
Ou seja, os SGBD devem ser dotados de recursos que possibilitem a descrição das 
estruturas de dados (layout de arquivos e/ou tabelas) de forma independente dos 
procedimentos de manipulação (leitura e gravação) de dados no BD. Isto possibilita 
tornar transparente para os programas que acessam o BD as alterações que, por 
ventura, venham a ocorrer nas estruturas de dados, como, por exemplo, o acréscimo 
de um novo campo de informação ao banco. Da mesma forma, alterações em 
lógicas de programas que acessam o BD não devem afetar as estruturas de dados 
definidas no BD. Os SGBDs conseguem isso por fazer uso de SQL (Structured Query 
Language), que possui grupos de comandos específicos e independentes para as 
tarefas de criação e alteração de tabelas (DDL - Data Definition Language) e leitura e 
atualização do BD (DML - Data Manipulation Language). 
» Redução ou Eliminação de Redundâncias – Em um sistema tradicional de 
controle de arquivos, cada usuário normalmente apresenta seus próprios arquivos 
armazenando o conjunto de dados que é de seu interesse e, nestes casos, é comum 
ocorrer redundância de dados. Esta redundância consiste no armazenamento de 
uma mesma informação em locais diferentes. Por exemplo, o nome do funcionário 
poderia estar nos arquivos dos Sistemas de Cadastro, de Folha de Pagamento e 
de Avaliação em uma empresa, se esses não tivessem uma única base de dados 
compartilhada. A redundância é danosa para o ambiente computacional, pois ela 
15
Banco de Dados
leva a um aumento de esforço computacional para realizar a atualização dos dados 
redundantes e aumento do espaço necessário para o armazenamento destes dados. 
Porém, o problema mais sério é que a representação dos dados desta forma pode 
tornar-se inconsistente, pois duas informações podem aparecer em locais distintos, 
mas apresentando valores diferentes. Dessa forma, um SGBD deve prover meios 
para que seja possível o controle da redundância de dados nos diversos arquivos 
administrados por ele. Para isso, os dados que eventualmente são comuns a mais 
de um sistema devem ser compartilhados por eles, fazendo-os acessar um mesmo 
banco de dados. Além disso, deve haver uma centralização da definição dos dados 
num Dicionário de Dados ou Catálogo, que vai servir como base para a operação do 
SGBD. 
» Eliminação de Inconsistências – Geralmente causada pela redundância de dados, 
a inconsistência ocorre quando um mesmo campo tem valores diferentes em 
sistemas diferentes. Por exemplo, o estado civil de um funcionário pode estar como 
solteiro no Sistema de Cadastro e como casado no Sistema de Folha de Pagamento. 
Isto pode ocorrer quando esta pessoa atualizou o campo em um sistema e não o 
atualizou em outro. Quando o dado é armazenado em um único local (no caso, o 
banco de dados) e compartilhado pelos sistemas, este problema não ocorre.
» Compartilhamento dos Dados - Permite a utilização simultânea e segura de um 
dado, por mais de uma aplicação ou usuário (através do tratamento de concorrência), 
independente da operação que esteja sendo realizada. O compartilhamento de 
dados visa diminuir a redundância de dados. Para implementar o compartilhamento 
de dados, é necessário que o SGBD possua um competente sistema de segurança, 
para que se estabeleça a privacidade de dados, através de mecanismos de restrição 
de acesso. 
» Tratamento de Concorrência – para que seja possível um compartilhamento 
simultâneo dos dados armazenados no banco de dados, o SGBD implementa o 
tratamento de concorrência. Ou seja, o SGBD deve possuir mecanismos para a 
identificação e tratamento dos acessos concorrentes, para garantir a consistência 
das informações do BD no sentido de sua veracidade. Os sistemas de bloqueio 
(LOCK) e desbloqueio (UNLOCK) são os mecanismos utilizados para evitar que 
uma informação que está sendo manipulada por um determinado usuário U1, seja 
alterada por outro usuário U2. Enquanto o primeiro usuário U1 estiver acessando 
um dado no BD, o segundo usuário U2 não terá acesso ao mesmo ou o terá apenas 
para leitura e receberá um aviso do SGBD de que a informação está sendo acessada 
por outro usuário e pode estar sendo modificada. 
» 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 (DataBase Administrator ou Administrador do Banco de Dados) 
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 
Saiba Mais
1 Sistemas 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. 
16
Banco de Dados
dos dados poderá ser obtida a partir de utilitários e aplicativos que os fabricantes 
colocam em seus produtos, visando facilitar o trabalho de proteção aos dados 
contra danos físicos, que podem ser causados por falhas de hardware ou queda 
da rede. Nessa linha, destacam-se as rotinas de backup (cópias de segurança dos 
dados armazenados) e a gravação com espelhamento (você ter duas máquinas 
diferentes com o banco de dados instalado e periodicamente ele ser replicado de 
uma máquina para outra, para se uma sair do ar, a outra já assumir). 
» Padronização dos Dados - Permite que os campos armazenados na base de 
dados sejam padronizados segundo um determinado formato. Por exemplo, para 
o campo sexo poderia ser definido e apenas permitido usar os caracteres “M” ou 
“F”. Padronizar os dados pode facilitar a comunicação e a cooperação entre vários 
departamentos, projetos e usuários. Padrões podem ser definidos para formatos 
de nomes, elementos de dados, telas, relatórios, terminologias, etc. O DBA pode 
obrigar a padronização em um ambiente de base de dados centralizado, muito mais 
facilmente que em um ambiente onde cada usuário ou grupo tem o controle de 
seus próprios arquivos e software;
» Controle de Transações: Uma Transação é um conjunto de operações sobre o 
BD que devem ser executadas integralmente e sem falhas ou interrupções. Caso 
contrário, devem ser desfeitas. Todo SGBD deve realizar o controle das Transações.
TRANSAÇÃO – é uma coleção de operações que desempenha uma função lógica única dentro de 
uma aplicação do sistema de banco de dados. Uma transação deve ter as seguintes propriedades 
que formam a sigla ACID:
A – Atomicidade: ou todas as operações envolvidas na transação ocorrem, ou nenhuma delas deve 
ter efeito sobre o banco de dados. Assegurá-la é tarefa do SGBD.
C – Consistência: ao final da execução da transação a consistência dos dados no banco deve ter sido 
mantida. Assegurá-la é tarefa do programador.
I – Isolamento: uma transação deve ter sua execução realizada de forma isolada em relação à 
execução de outras transações.
D – Durabilidade: depois que uma transação é executada com sucesso, as modificações por ela 
realizadas devem ser mantidas no sistema, mesmo na ocorrência de falhas. Assegurá-la é tarefa 
do SGBD.
O conceito de transação é importante porque qualquer sistema computacional está sujeito 
a falhas. Por isso, em muitas aplicações é crucial assegurar que, uma vez detectada uma falha, 
os dados sejam salvosem 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 
17
Banco de Dados
cadastrados. Por exemplo: Não permite que uma data final seja menor do que uma 
data inicial.
» Representação de Relacionamento Complexo entre Dados: uma base de dados 
pode possuir uma variedade de dados que estão interrelacionados de muitas 
maneiras. Um SGBD deve ter a capacidade de representar uma variedade de 
relacionamentos complexos entre dados, bem como recuperar e modificar dados 
relacionados de maneira fácil e eficiente
» Possibilidade de Múltiplas Interfaces: Vários usuários representam também 
necessidades diversas no que se refere aos tipos de interfaces fornecidas pelo 
SGBD. Interfaces para consultas de dados, programação, e interfaces baseadas em 
menus ou em linguagem natural são exemplos de alguns tipos que podem estar 
disponíveis.
Estrutura Geral de um SGBD
A estrutura geral de um SGBD envolve, em síntese, os componentes apresentados 
na Figura 9 e descritos a seguir.
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 para 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 
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 
da estrutura da base 
de dados.
18
Banco de Dados
forma compatível e mais eficiente com respeito ao banco de dados, encontrando uma boa 
estratégia para executar a consulta.
Gerenciador do banco de dados - fornece a interface entre os dados de baixo 
nível armazenados no disco e o Código Objeto de Aplicativos e as consultas submetidas ao 
sistema (após passarem pelo Processador de Consultas).
Gerenciador de arquivos - gerencia a alocação do espaço na armazenagem do disco 
e as estruturas de dados usadas para representar a informação armazenada no disco. É o 
gerenciador de memória quem traduz os diversos comandos DML em comandos de baixo 
nível para atuar sobre os dados armazenados na base de dados.
Adicionalmente, diversas estruturas de dados são requeridas como parte da 
implementação do sistema físico, incluindo:
Arquivos de dados - armazenam o banco de dados propriamente dito.
Dicionário de dados - armazena informações sobre a estrutura do banco de dados. 
Também chamado de catálogo de dados, contém os metadados, isto é, as informações a 
respeito dos componentes do banco de dados: tabelas, índices, procedimentos, restrições 
e outros.
Classes de Usuários de um Sistema de Banco de 
Dados
Um Banco de Dados pode apresentar diversos usuários cada qual com uma 
necessidade em particular, e com um envolvimento diferente com os dados do BD. Você 
sabe quais são eles? Não? Que tal conhecer um pouco mais? Os usuários podem ser 
classificados nas seguintes categorias: 
» Administrador de Bancos de Dados (DBA – DataBase Administrator) - em 
qualquer organização onde muitas pessoas compartilham diversos recursos, existe 
a necessidade de um administrador chefe (sempre existe o que vai ficar à frente, 
não é?) para supervisionar e gerenciar estes recursos (em um ambiente de base 
de dados, o recurso primário é a própria base de dados e os recursos secundários 
são o SGBD e os demais softwares relacionados. A administração desses recursos é 
de responsabilidade do DBA. Ele é responsável, entre outras coisas, por autorizar 
acesso à base de dados e coordenar e monitorar seu uso. Adicionalmente, ele 
é responsável por sanar problemas, tais como quebra de segurança ou baixo 
desempenho do BD. 
» Projetista de Bancos de Dados – também chamado de analista de banco de dados, 
possui a responsabilidade de identificar os dados a serem armazenados no BD e 
pela escolha da estrutura apropriada a ser utilizada para armazená-los. Ou seja, é 
a pessoa responsável pelo projeto de construção e utilização do BD, envolvendo 
as tarefas de definição de quais dados deverão ser construídos e como eles serão 
construídos. Pode existir um único projetista ou um grupo deles e ele(s) irá(ão) 
interagir com outras classes de usuários, tanto os analistas e programadores, como 
os chamados usuários finais do sistema, a fim de obter a visão dos dados que cada 
um possui, integrando-as de forma a se obter uma representação adequada de 
todos os dados. 
» Usuários Finais: existem profissionais que precisam ter acesso à base de dados para 
consultar, modificar e gerar relatórios. A base de dados existe para estes usuários. 
Existem algumas categorias de usuários finais:
19
Banco de Dados
› Usuários ocasionais: ocasionalmente fazem acesso à base de dados, mas eles 
podem necessitar de diferentes informações a cada vez que fazem acesso. 
Eles podem usar uma linguagem de consulta sofisticada para especificar suas 
requisições e são, tipicamente, gerentes de médio ou alto nível; 
› Usuários comuns ou paramétricos: estes usuários realizam operações padrões 
de consultas e atualizações, chamadas transações permitidas, que foram 
cuidadosamente programadas e testadas. Estes usuários constantemente 
realizam recuperações e modificações na base de dados;
› Usuários sofisticados: incluem engenheiros, analistas de negócios e outros 
que procuraram familiarizar-se com as facilidades de um SGBD para atender 
aos seus complexos requisitos;
› Analistas de Sistemas e Programadores de Aplicações: são os Engenheiros 
de Software, aquelas pessoas que determinam as necessidades dos usuários 
finais e desenvolvem as especificações para as transações que irão atender a 
estas necessidades. Os programadores das aplicações são as pessoas que irão 
realmente implementar estas especificações, criando os programas que irão 
constituir o sistema e fazer acesso ao BD. Adicionalmente, os programadores 
também são os responsáveis por testar os programas criados.
Muitos de nós nos enquadramos nessa última categoria de usuários (usuários 
finais).
Podem existir ainda alguns profissionais de apoio ou suporte para realizar tarefas 
específicas como tirar backup (cópia de segurança) dos dados armazenados no Banco de 
Dados.
Alguns Exemplos de SGBDs
Alguns dos principais SGBDs disponíveis no mercado nos últimos anos são:
» 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/
Saiba Mais
4 PL/SQL (Procedural 
Language/Structured 
Query Language) 
é uma linguagem 
procedural que é 
extensão da linguagem 
padrão SQL para o 
SGBD Oracle, a fim 
de permitir que a 
manipulação de 
dados seja incluída 
em unidades de 
programas.
20
Banco de Dados
sql/default.mspx). Site Oficial em http://www.microsoft.com/sqlserver/2008/en/us/
» IBM DB2 - é o Sistema Gerenciador de Banco de Dados Relacionais (SGDBR) 
produzido pela IBM. Existem diferentes versões do DB2 que rodam desde num 
simples PDA (computador de mão), até em potentes mainframes e funcionam 
em servidores baseados em sistemas Unix, Windows ou Linux. DB2 é vendido 
em diversos tipos de edições ou licenças. Pela escolha de uma versão com menos 
recursos, a IBM evita que os consumidores paguem por coisas que não iriam usar. 
Informações em http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp 
» Interbase - é um sistema gerenciador de banco de dados relacionais da Borland. 
Foi incluído, pela Borland, nas suas ferramentas de desenvolvimento (Delphi, C++ 
Builder e JBuider). Ele pode ser instalado em sistemas operacionais Microsoft 
Windows, Linux, Mac OS X e Sun Solaris. Além de não ser pesado é relativamente 
rápido e suporta bancos de dados de grande tamanho (maiores que 2 Gigabytes). 
Em 2000 a Borland liberou o código da versão 6.0, mas as posteriores voltaram a 
ter licença proprietária. Desta versão 6.0 foi criado o Banco de Dados Open source 
Firebird. Site Oficial: http://www.embarcadero.com/products/interbase-smp
» Firebird - Nascido de uma iniciativa da Borland em abrir o código do InterBase 
6.0, este sistema é open source e esbanja versatilidade e robustez. O Firebird 
(algumas vezes chamado de FirebirdSQL) roda em Linux, Windows, Mac OS e uma 
variedade de plataformas Unix. A Fundação FirebirdSQL coordena a manutenção e 
desenvolvimento do Firebird, sendo que os códigos fonte são disponibilizados sob o 
CVS da SourceForge. O produto é bastante seguro e confiável, suportando sistemas 
com centenas de usuários simultâneos e bases de dados com dezenas/centenas 
de gigabytes. Há suporte gratuito na Internet através de vários sites. O Firebird é 
amplamente utilizado em todo o mundo, com a maior base de usuários no Brasil, 
Rússia e Europa. Site Oficial em http://www.firebirdsql.org/ 
» MySQL - é, atualmente, um dos bancos de dados mais populares, com mais de 10 
milhões de instalações pelo mundo. Ele possui versões para Windows, Solaris, Unix, 
FreeBSD, Linux e é gratuito para uso não-comercial. Algumas das empresas mais 
famosas que fazem uso deste banco estão: NASA, Banco Bradesco, Dataprev, HP, 
Nokia, Sony e Lufthansa. O MySQL é usado principalmente para desenvolvimento 
WEB como servidor de dados para comércio eletrônico. Passou a ser considerado 
um SGBD de verdade (com conceito de transação) a partir da versão 5. Site Oficial 
em http://www.mysql.com/
» PostgreSQL - é um sistema gerenciador de banco de dados objeto relacional 
(SGBDOR), desenvolvido como projeto de código aberto. Ele é um dos SGBDs 
(Sistema Gerenciador de Bancos de Dados) de código aberto mais avançados, é 
grautito e tem uma boa aceitação no mercado. Originalmente concebido para 
rodar em Linux, ele possui versões para Windows. É usando, principalmente, para 
comércio eletrônico juntamente com linguagem PHP. O PostgreSQL é um projeto 
open source coordenado pelo PostgreSQL Global Development Group. Site Oficial 
em http://www.postgresql.org/
» Microsoft Access: é um banco de dados da Microsoft para uso em micros desktops 
e não em servidores. Esta é a principal diferença dele para os demais bancos 
SGBD como o Oracle, SQL Server e MySQL, por exemplo. Contudo, ele tem sido 
muito usado em pequenas e médias empresas para armazenamento de dados em 
pequenas quantidades. Agora, o MS Access não é considerado um SGBD completo, 
por não possuir todas as características de um. Mas ele permite o desenvolvimento 
rápido de aplicações que envolvem tanto a modelagem e estrutura de dados como 
também a interface a ser utilizada pelos usuários. A linguagem de programação 
21
Banco de Dados
disponível no access é a Microsoft Visual Basic for Applications, igualmente a outros 
produtos da série Microsoft Office. Maiores informações em: http://office.microsoft.
com/pt-br/access/default.aspx 
Dos SGBDs listados acima vale ressaltar que o SQL Server e o Oracle tem versões 
gratuitas, porém limitadas. O Firebird e o PostgreSQL são open source, o DB2 e o MS Access 
são pagos (sendo que o Access já vem em algumas versões do pacote Microsoft Office) e o 
MySQL é gratuito para desenvolvimento, mas pago para produção.
A escolha de qual SGBD usar depende muito do projeto sendo desenvolvido e do 
quanto a empresa está disposta a investir para armazenamento dos seus dados. Um SGBD 
gratuito e muito popular nos dias de hoje é o PostGreSQL e vários sistemas de instituições 
públicas vêm adotando o mesmo. Já no mundo corporativo o Oracle tem sido um dos mais 
adotados, por ser um dos mais robustos. Dos SGBDs citados, você já usou algum?
Considerações Finais
Apesar de todas as vantagens citadas anteriormente sobre um SGBD, há situações 
em que deve-se ponderar sobre sua utilização, como por exemplo, o alto investimento 
inicial e a possibilidade de compra de um novo hardware; ou a possibilidade de insatisfação 
no desempenho geral do sistema que pode ser provocado pelas funções de segurança, 
controle de concorrência, recuperação e manutenção de integridade dos dados. Dessa 
forma, mesmo com todos os benefícios ainda existem situações em que você pode não 
utilizar um SGBD, elas estão descritas no Quadro 1.
Quadro 1 - Usar ou não usar um SGBD, eis a questão!
Quando usar SGBD Quando não usar SGBD
Quando desejar obter: 
» Controle de redundância 
» Controle de consistência e integridade 
» Acesso multiusuário 
» Compartilhamento de dados 
» Controle de acesso e segurança 
» Controle de recuperação e restauração 
» Realização de consultas eficientes 1
» Dados e aplicações simples, bem definidas 
e estáveis (sem expectativas de mudança) 
» Quando requisitos de tempo real não 
puderem ser atendidos 
» Não há necessidade de acesso 
multiusuário aos dados
Conheça Mais
Neste capítulo, vimos apenas alguns conceitos básicos. Para obter mais informações 
ou materiais diversificados para o que foi visto aqui, você pode proceder a uma pesquisa 
usando o Google (www.google.com.br) com as palavras chaves “Banco de Dados” + 
“Introdução”. Você vai ver que irá vir muito material. Entre eles: apostilas, notas de aula, 
reportagens, etc. 
Adicionalmente, gostaríamos de indicar o texto “Introdução a Banco de Dados” 
dos professores OsvaldoKotaro 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 
22
Banco de Dados
Para quem tem curiosidade, uma comparação entre alguns SGBDs dos mais 
utilizados pode ser encontrada em: http://www.microsoft.com/sqlserver/2008/en/us/compare.
aspx (apenas em inglês).
Se possível, leia também os capítulos introdutórios (geralmente capítulo 1 ou 1 e 2) 
dos seguintes livros: 
 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de 
dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006.
 ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São 
Paulo: Pearson Education do Brasil, 2005.
 DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 
2000.
Você Sabia?
O maior banco de dados do mundo se encontra no World Data Centre for Climate que é operado 
pelo Max Planck Institute for Meteorology e o German Climate Computing Centre. Ele possui 
cerca de 220 terabytes de dados acessíveis via Web (incluindo informações sobre pesquisas 
climáticas e previsões do tempo) e 110 terabytes de dados sobre simulações climáticas. Além 
disso, ainda há 6 pentabytes de dados adicionais armazenados em fitas magnéticas. Já imaginou 
quanto dado é tudo isso?
Fonte: http://www.docstoc.com/docs/5628186/Top-Largest-Databases-in-the-World-We-all-collected
Aprenda Praticando
A seguir apresento algumas questões sobre banco de dados que fizeram parte das 
provas de concursos diversos. Que tal praticar com elas?
Concurso TCE (Técnico em Informática) - CESGRANRIO - 2007 - RO
 Uma coleção de dados interrelacionados e uma coleção de programas para acesso 
a esse banco de dados é um(a):
a) SQL;
b) SGBD;
c) Banco de Dados;
d) SBD;
e) Tabela.
Concurso STF (Analista Judiciário – Tecnologia da Informação) – CESPE - 2008
 A execução de transações de maneira concorrente é a única causa do surgimento 
de inconsistências dos dados armazenados em um banco de dados. Assim, a 
responsabilidade pela consistência dos dados é única e exclusiva do componente 
de controle de concorrência.
⃝ Certo ⃝ Errado 
23
Banco de Dados
Concurso Petrobrás (Técnico em Informática) - CESGRANRIO - 2008
 Atomicidade é uma propriedade de transação de um SGBD relacional que garante 
que:
a) uma transação seja realizada de forma independente de outras transações;
b) uma operação de uma transação seja efetuada de forma independente de outras 
operações;
c) nenhuma operação de uma transação seja subdividida em tarefas menores pelo 
SGBD;
d) todos os atributos manipulados por uma transação sejam atômicos;
e) todas as operações em um banco de dados, que fazem parte de uma transação, 
sejam executadas ou nenhuma delas o seja.
 Concurso Petrobrás (Analista de Sistemas Pleno - Especialidade Processos) 
CESGRANRIO - 2006
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.
24
Banco de Dados
Atividades e Orientações de Estudo
Agora vamos exercitar o que foi estudado até agora. Assim sendo, faça as atividades 
sugeridas a seguir. Lembre que exercitar vai lhe ajudar a fixar melhor o conteúdo estudado. 
Mãos à obra!
Atividades Práticas
Responda as questões a seguir:
1. Quais as principais desvantagens de fazer uso de um sistema de arquivos 
convencional em relação ao uso de banco de dados?
2. Quais as propriedades de uma transação?
3. O que são metadados? Dê exemplos.
4. Que problemas podem ser causados pela falta de padronização dos dados 
armazenados?
5. Qual a importância do controle de redundância?
Sugestão para Atividade de Interação
Discuta com seus colegas, com o professor e o tutor sobre seu conhecimento sobre 
Banco de Dados. Tenha como guia as seguintes questões:
1. Você já conhecia alguma coisa sobre o tema Banco de Dados? Se sim, o quê? E 
como ficou sabendo (fez curso, leu sozinho, etc)?
2. Você já fez uso de algum banco de dados na prática? Se sim, qual(ais)? Em que 
situação fez uso?
Participe, discuta, pergunte! Assim você pode aprender ainda mais!
Filmoteca: Cinema em Ação
Você saberia dizer em quantos bancos de dados você está cadastrado? Você 
saberia mensurar a importância de ter seus dados íntegros, seguros, de forma a não serem 
modificados por pessoas indevidas? Você saberia mensurar as consequências de ter seus 
dados modificados ou apagados de alguns bancos de dados sem sua ciência? Essas e outras 
questões são abordadas e levam a pensar no filme chamado “A Rede” (The Net) que tem 
como atriz principal Sandra Bullock. Esse é um filme um pouco antigo, porém, mostra bem 
como os dados armazenados em um BD podem ser importantes.
25
Banco de Dados
Dica de Cinema
A Rede
Sinopse: Após receber um disquete com dados confidenciais, uma analista de sistemas passa a 
viver um verdadeiro pesadelo, com seus dados sendo alterados nos computadores do governo 
para que ela seja considerada uma criminosa. 
Diretor: Irwin Winkler
Ano de Produção: 1995
Atores Principais: Sandra Bullock e Jeremy Northam.
Vamos Revisar?
Você estudou, neste capítulo, os conceitos básicos iniciais sobre banco de 
dados (tais como: o que é um BD, um SGBD, um SBD, o que é dado, informação, etc). Foi 
apresentado o cenário existente antes dos bancos de dados virem a ser utilizados (quando 
eram usados sistemas de arquivos convencionais). Cenário este que apresentava diversos 
problemas como redundância de dados que levava a inconsistências, dificuldade de acesso 
concorrente, dificuldade de manutenção, entre outros. Também foram especificadas as 
principais vantagens de utilização de um SGBD e os perfis dos usuários que fazem uso de 
sistemas de banco de dados. Para finalizar, foram apresentados exemplos de SGBDs atuais e 
foram apresentadas situações onde o uso de sistemas de banco de dados é dispensável. No 
capítulo a seguir, vamos continuar o nosso estudo introdutório falando sobre a evolução dos 
sistemas de banco de dados e como está estruturada a sua arquitetura. Até lá!
26
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 asdiferentes gerações de Banco de Dados
» Identificar as diferentes arquiteturas de Banco de Dados
» Entender o conceito de Abstração de Dados
27
Banco de Dados
Capítulo 2 – Evolução e Arquitetura 
dos Bancos de Dados
Vamos conversar sobre o assunto?
“Vimos, no capítulo anterior, a importância dos Sistemas de Banco de Dados e as 
principais características dos mesmos. Porém, será que os banco de dados sempre foram do 
mesmo jeito? Será que eles mudaram? Será que evoluíram com o tempo? Ainda mais, como 
é a arquitetura de um Banco de Dados? Como ele está organizado para fazer tudo que você 
leu no capítulo anterior? Você sabe? Justamente sobre esses pontos vamos estudar neste 
capítulo, procurando responder as perguntas aqui formuladas.”
Neste capítulo, vamos estudar a evolução dos SGBDs no tempo, que deram origem 
a gerações diferentes de banco de dados, além de estudar a forma como os bancos de dados 
estão organizados internamente, ou seja, a sua arquitetura. Vamos lá?
E houve a evolução...
Como vimos no capítulo anterior, no começo, não existiam bancos de dados, mas 
apenas os sistemas de arquivos. Ou seja, cada aplicação ou programa desenvolvido para 
uma organização tinha seu próprio conjunto de dados e a descrição desses dados ficava 
dentro das próprias aplicações. Dessa forma, não havia compartilhamento de dados entre 
as mesmas. Devido a isso, diversos problemas surgiam, tais como redundância de dados, 
inconsistências, falta de padronização, falta de segurança no acesso aos dados, limitações 
no compartilhamento dos dados, entre outros. Os bancos de dados surgiram como forma de 
tentar resolver esses problemas (o que você pode observar pela definição de BD e vantagens 
anteriormente apresentadas). Mas os bancos de dados foram sempre os mesmos? Ou eles 
evoluíram com o tempo? Os bancos de dados não foram sempre os mesmos. Podemos 
inclusive subdividir sua evolução em três gerações bem definidas (vide Figura 10), cada uma 
com características próprias. Na primeira geração, que surgiu no final dos anos 60, estão os 
bancos de dados hierárquicos e em rede. Na segunda geração que nasceu no final dos anos 
70 está o banco de dados relacional. E, por fim, a geração mais atual que data de desde o 
final dos anos 80 está o banco de dados orientado a objetos e objeto-relacional. A seguir, 
detalharemos cada uma dessas gerações.
28
Banco de Dados
Figura 10 - Evolução dos Bancos de Dados
Primeira Geração dos Bancos de Dados
Os primeiros bancos de dados surgiram nos anos 60, com o surgimento dos bancos 
de dados hierárquicos e em rede, com acesso sequencial aos dados e processamento em 
batch (em lote, várias instruções de uma vez), essa foi a chamada primeira geração. Os dois 
modelos da época eram o Hierárquico e o em Rede, ambos orientados a registros, isto é, 
qualquer acesso à base de dados – inserção, consulta, alteração ou remoção – era feita em 
um registro de cada vez. Vamos detalhar agora, cada um desses modelos.
Modelo de Dados Hierárquico
O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados. 
Nesse modelo de dados, os dados são estruturados em hierarquias ou árvores (lembra das 
árvores que você estudou na disciplina de estrutura de dados?). Os nós das hierarquias 
contêm ocorrências de registros, onde cada registro é uma coleção de campos (atributos), 
cada qual contendo somente um valor. 
Os registros são conectados uns aos outros por meio de uma ligação, também 
chamada de link (associação essa entre exatamente dois registros). O registro da hierarquia 
que precede a outros é o registro-pai, os outros são chamados de registros-filhos. O 
relacionamento entre um registro-pai e vários registros-filhos possui cardinalidade 1:N, 
ou seja, cada registro-pai pode possuir 1 ou mais registros-filhos, mas os registros filhos 
possuem apenas um único registro pai (vide representação da Figura 11). 
Figura 11 - Relação 1-N entre registro-pai e registros-filhos
29
Banco de Dados
Os dados organizados, segundo este modelo, podem ser acessados segundo uma 
sequência hierárquica com uma navegação do topo (raiz) para as folhas (nós sem filhos) e 
da esquerda para a direita dentro de cada nó ou registro. Um mesmo registro pode estar 
associado a vários registros diferentes, desde que seja replicado. Porém, a replicação 
possui duas grandes desvantagens: pode causar inconsistência de dados quando houver 
atualização e causar desperdício de espaço. 
Vamos dar um exemplo. Suponha que o conjunto de todos os registros de clientes 
e de contas de um banco está organizado na forma de uma árvore com raiz (vide Figura 
12), em que a raiz da árvore é um registro falso (sem conteúdo, serve apenas para iniciar a 
árvore). Teríamos nós que representariam os clientes (com valores para o nome do cliente, 
a rua onde ele mora e a cidade) como, por exemplo, o nó com valor “Rui, Rua XV e S. Carlos” 
e nós que representariam as contas (com valores para o número da conta e o saldo) como, 
por exemplo, o nó com valor “7556, 3.000” (vide Figura 13). Neste modelo, a necessidade 
de representar contas conjuntas levaria à duplicação de registros, devido à representação 
em árvore. Por exemplo, suponhamos que Silvia e Rui possuem a conta conjunta de número 
7556 (vide Figura 12, os nós com o número da conta em negrito), para representar esse fato, 
o nó da conta corrente teve de ser duplicado para obedecer à regra que “cada filho só pode 
ter um único pai”.
Figura 12 - Exemplo de Modelo Hierárquico
Figura 13 - Representação dos nós usada no exemplo
Além de poder causar inconsistência de dados quando houver atualização e causar 
desperdício de espaço, outros problemas encontrados no modelo hierárquico são:
» Nem tudo pode ser representado como uma hierarquia;
30
Banco de Dados
» Complexidade dos diagramas de estrutura de árvore;
» Não pode haver ciclos no gráfico básico de um diagrama de estrutura de árvore;
» Restrições à cardinalidade dos links (não pode haver ligações de muitos para muitos 
(N:M) e de muitos para um (N:1));
» Ausência de facilidades de consultas declarativas (não há linguagem ou recurso 
específico para isso), logo a realização de consultas é uma atividade complexa;
» Necessidade de navegação por ponteiros para acesso a informações.
O sistema comercial mais divulgado no modelo hierárquico foi o Information 
Management System (IMS) da IBM Corporation. O IMS é um dos mais antigos e mais 
amplamente utilizados sistemas de bancos de dados. Os desenvolvedores deste sistema 
estão entre os primeiros a tratarem características como concorrência, recuperação, 
integridade e processamento eficiente de consultas. Além dele, outros bancos que usavam 
o modelo hierárquico foram: UNIVAC 1100, CDC 6000, CYBER 70 e 170.
Modelo de Dados em Redes
O modelo em redes surgiu como uma extensão ao modelo hierárquico, eliminando 
o conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em 
várias associações. E que benefícios trás isso? Bem, isso faz com que seja possível construir 
relações menos restritivas entre os registros. 
No modelo em rede, os registros são organizados em grafos onde aparece um único 
tipo de associação (set) que define uma relação 1:N entre 2 tipos de registros: proprietário 
e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre 
os registros C e D é possível construir um relacionamento M:N (muitos para muitos) entre A 
e D, o que não era possível no modelo hierárquico. Adicionalmente, ao contrário do Modelo 
Hierárquico, em que qualquer acesso aos dados passa pela raiz (lembra do tal registro 
falso?), o modelo em rede possibilita acesso a qualquer nó da rede sem passar pela raiz. 
Dessa forma, no modelo em redes os registros são organizados no banco de dados por um 
conjunto arbitrário de grafos. 
Na Figura 14, podemos ver o mesmo exemplo de registros de clientes e contas 
apresentado antes como exemplo do modelo hierárquico, agora sendo representados pelo 
modelo em redes. Noteque 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
31
Banco de Dados
As restrições impostas pelo Modelo de Redes podem ser descritas como de ordem 
de Entrada e de Existência. Em relação às restrições de entrada, citamos a obrigatoriedade 
de cada novo registro estar conectado ao conjunto indicado. Em relação a restrições de 
Existência, podemos dizer que um componente de um tipo de registro pode existir de forma 
independente de outros desde que esteja conectado a algum outro registro fazendo parte 
de algum conjunto, ou sendo base de um novo conjunto. A identificação de um conjunto 
pode ser verificada através do esquema de ligação entre o registro pai e o registro filho, 
assim sendo, cada instância de conjunto apresenta um elemento de distinção, o tal registro 
pai, e os registros filhos devidamente ordenados e, portanto, passíveis de serem acessados 
pelos seus elementos. 
Alguns problemas do modelo em redes são:
» O modelo de rede é fortemente dependente da implementação.
» As consultas são complicadas: o programador é forçado a pensar em termos de 
links e, em como percorrê-los para obter as informações de que necessita. Essa 
manipulação de dados é chamada navegacional. 
No Modelo em Rede, o sistema comercial mais divulgado é o CAIDMS da Computer 
Associates. Além dele, há o DBMS10, o IDS II, o DMS II e o IMAGE
Segunda Geração dos Bancos de Dados
Nos anos 70 e 80, com os dispositivos de acesso direto aos dados, surgem 
os sistemas indexados e de processamento transacional (cada operação deve ser 
completamente realizada, se não o for, deve ser desfeita, esse é o conceito de transação). 
Nos anos 80, foram lançadas as bases do modelo relacional (dando origem à segunda 
geração) que impulsionou o uso e abriu caminho para todos os SGBDs atuais. 
Modelo de Dados Relacional
O modelo relacional apareceu devido às seguintes necessidades: 
» Aumentar a independência de dados nos sistemas gerenciadores de banco de 
dados;
» Prover um conjunto de funções apoiadas em álgebra relacional para armazenamento 
e recuperação de dados; 
» Permitir processamento ad hoc 
O Modelo Relacional (MR) é considerado o primeiro modelo de dados efetivamente 
usado em aplicações comerciais. Foi introduzido por Codd em 1970. É o modelo que possui 
a base mais formal entre os modelos de dados, entretanto é o mais simples e com estrutura 
de dados mais uniforme. O modelo relacional tem como base a teoria dos conjuntos e a 
álgebra relacional.
A estrutura fundamental do modelo relacional é a relação (tabela). Na verdade, 
o modelo é composto por uma coleção de tabelas de nomes únicos. Cada relação ou 
tabela é constituída por uma ou mais colunas chamadas de atributos (campos) que são os 
tipos dos dados contidos na relação. O conjunto de valores passíveis de serem assumidos 
por um atribruto será intitulado de domínio. Cada linha da relação é chamada de tupla 
(registro). O esquema de uma relação nada mais é do que os campos (colunas) existentes 
em uma relação ou tabela. Já a instância da relação consiste no conjunto de valores que 
cada atributo assume em um determinado instante. As relações não podem ser duplicadas 
32
Banco de Dados
(por exemplo, não podem existir dois estados de Pernambuco, no conjunto de estados 
brasileiros) e a ordem de entrada de dados no Banco de Dados não deverá ter qualquer 
importância para as relações, no que concerne ao seu tratamento. 
Diferentemente dos modelos que o precederam o modelo relacional não tem 
caminhos pré-definidos para se fazer acesso aos dados. Os relacionamentos entre as tabelas 
são feitos através do uso de valores de atributos. Por exemplo, na Figura 15, a Tabela de 
Empregados precisa usar valores que estão, originalmente, na tabela de Departamentos (o 
atributo ou campo chamado Cod_Depto). Isso causa a necessidade de um relacionamento 
entre as tabelas.
Figura 15 - Exemplo de Relacionamento no Modelo Relacional
Para trabalhar com tabelas, algumas restrições precisaram ser impostas para evitar 
aspectos indesejáveis, como: Repetição de informação, incapacidade de representar parte 
da informação e perda de informação. Essas restrições são: integridade referencial, chaves 
e integridade de junções de relações. Veremos em detalhes isso tudo no volume II da 
disciplina. O modelo relacional faz uso da linguagem SQL para definição e manipulação de 
dados (discutiremos sobre a linguagem SQL, em detalhes, no volume III da disciplina).
Alguns exemplos de banco de dados que fazem uso desse modelo são: PostGreSQL, 
Oracle, SQLServer, MySql, entre outros.
Terceira Geração dos Bancos de Dados
Devido às necessidades do mundo moderno de manipular dados complexos, surgiu 
a terceira geração dos bancos de dados, com os modelos de dados orientados a objetos e os 
modelos de dados objeto-relacionais. E o que eles trouxeram de novo? Vamos ver a seguir. 
Modelo de Dados Orientado a Objetos
Os bancos de dados orientados a objeto começaram a se tornar comercialmente 
viáveis em meados de 1980. A motivação para seu surgimento está em função dos limites 
de armazenamento e representação semântica impostas no modelo relacional. Um exemplo 
de modelo orientado a objetos são os sistemas de informações geográficas (SIG) que são 
mais facilmente construídos usando tipos complexos de dados. A habilidade para criar os 
tipos de dados necessários é uma característica das linguagens de programação orientadas 
a objetos.
Contudo, estes sistemas necessitam guardar representações das estruturas de 
dados que utilizam no armazenamento permanente. A estrutura padrão para os bancos 
de dados orientados a objetos foi feita pelo Object Database Management Group (ODMG). 
Esse grupo é formado por representantes dos principais fabricantes de banco de dados 
orientados a objeto disponíveis comercialmente. Membros do grupo têm o compromisso 
33
Banco de Dados
de incorporar o padrão em seus produtos. O termo Modelo de Dados Orientado a Objetos 
é usado para documentar o padrão que contém a descrição geral das facilidades de um 
conjunto de linguagens de programação orientadas a objetos e a biblioteca de classes que 
pode formar a base para o Sistema de Banco de Dados. 
Quando os bancos de dados orientados a objetos foram introduzidos, algumas 
das falhas perceptíveis do modelo relacional pareceram ter sido solucionadas com esta 
tecnologia e acreditava-se que tais bancos de dados ganhariam grande parcela do mercado. 
Hoje, porém, acredita-se que os Bancos de Dados Orientados a Objetos serão usados em 
aplicações especializadas, enquanto os sistemas relacionais continuarão a sustentar os 
negócios tradicionais, onde as estruturas de dados baseadas em relações são suficientes. 
Alguns exemplos de banco de dados que fazem uso desse modelo são: O2, 
OBJECTSTORE, Caché e IRIS.
O diagrama de classes UML, usado na análise orientada a objetos, serve geralmente 
como o esquema para o modelo de dados orientado a objetos (vide exemplo para o 
problema dos registros de clientes e contas, que já foi utilizado para ilustrar os modelos 
hierárquico e em rede, na Figura 16).
Figura 16 - Exemplo de Modelo de Dados Orientado a Objetos
Alguns problemas do modelo orientado a objetos são: ele não tem base teórica 
(formalismo) como os modelos anteriores e não existe linguagem padronizada para acesso 
e manipulação dos dados (tal qual o SQL). Isso fez com que esse paradigma não fosse bem 
aceito no mercado. Como solução surgiu o paradigma objeto-relacional.
Modelo de Dados Objeto-Relacional
A área de atuação dos sistemas Objeto-Relacional tenta suprir a dificuldade dos 
sistemas relacionais convencionais, que é o de representar e manipular dados complexos, 
visando ser mais representativos em semântica e construções de modelagens. Neste 
modelo de dados, toda a informação persistenteestá ainda nas tabelas, mas algumas 
das entradas da tabela podem ter uma estrutura de dados mais rica, denominada tipos 
abstratos de dados (TAD). Um TAD é um tipo de dado que é construído combinando tipos de 
dados alfanuméricos básicos. Um suporte para tipos de dados abstratos é atrativo porque as 
operações e funções associadas com o novo tipo podem ser usadas para indexar, armazenar, 
e recuperar registros baseados no índice do novo tipo de dado (por exemplo, multimídia).
Diferente do modelo orientado a objetos, o modelo objeto-relacional foi 
desenvolvido com base no modelo relacional. Dessa forma, foi possível unir conceitos 
de OO (tais como: supertabelas, supertipos, herança, reutilização de códigos de criação, 
encapsulamento, controle de identidade de objetos e referência a objetos) com conceitos 
do modelo relacional (tais como: capacidade de consulta avançada e a alta proteção a 
dados). Assim, os modelos Objeto-Relacional combinam os benefícios do modelo Relacional 
com a capacidade de modelagem do modelo OO
A linguagem de consulta objeto relacional é uma extensão da linguagem SQL 
34
Banco de Dados
para suportar o modelo de objetos. As extensões incluem consultas envolvendo objetos, 
atributos multivalorados, TADs, métodos e funções como predicados de busca em uma 
consulta.
Alguns motivos que levam a utilização desse tipo de modelo são:
» A incapacidade do modelo relacional básico de resolver os desafios e atender as 
necessidades das novas aplicações;
» A capacidade de armazenar novos tipos de dados;
» Fornecem suporte para consultas complexas sobre dados complexos
» Atendem aos requisitos das novas aplicações e da nova geração de aplicações de 
negócios
Algumas aplicações para as quais é necessário o uso desse tipo de modelo são:
» Armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital);
» Dados complexos não-convencionais em projeto de engenharia;
» Grandes informações sobre o genoma biológico
» Projetos de arquitetura;
» Dados de séries temporais em transações;
» Dados sobre o espaço (regiões geográficas, criação de mapas)
» Sistemas móveis e distribuídos, dentre outros.
Alguns bancos de dados que fazem uso do modelo objeto-relacional são Oracle 9i, 
DB2/6000, ILUSTRA e CA-Ingres.
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 
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 
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.
35
Banco de Dados
a maioria dos usuários fazia acesso aos sistemas via terminais que não possuíam poder de 
processamento, apenas a capacidade de visualização (esses terminais eram muitas vezes 
chamados de terminais-burros, justamente por não terem poder de processamento). Ou 
seja, todos os processamentos eram feitos remotamente, apenas as informações a serem 
visualizadas e os controles eram enviados do mainframe para os terminais de visualização 
(também chamados de nós), conectados a ele por uma rede de comunicação (vide Figura 
17).
Como os preços do hardware foram decrescendo, muitos usuários trocaram seus 
terminais por computadores pessoais (PCs) e estações de trabalho (tais como as estações 
unix). No começo os SGBDs usavam esses computadores da mesma maneira que usavam 
os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execução de 
programas aplicativos e processamento da interface do usuário eram executados em apenas 
uma máquina (a que centralizava tudo). A arquitetura centralizada tem como principais 
vantagens: permitir que muitos usuários manipulem grande volume de dados e que, com 
os dados totalmente isolados, se ganha consideravelmente em segurança, visto que o 
acesso aos dados é feito somente em um único local. E a sua principal desvantagem é a total 
dependência de um único sistema, podendo ocasionar uma elevada indisponibilidade em 
caso de falhas deste. 
Figura 17 - Esquema de um BD Centralizado
Com o desenvolvimento de computadores pessoais com maior capacidade de 
processamento, parte do controle da aplicação e interface junto ao usuário, que antes era de 
total responsabilidade do sistema centralizado, passou a ser realizado pelos computadores 
pessoais, cabendo ao sistema centralizado apenas satisfazer às solicitações geradas pelos 
sistemas clientes. Assim, gradualmente, os SGBDs começaram a explorar a disponibilidade 
do poder de processamento no lado do usuário, o que levou à arquitetura cliente-servidor, 
que veremos a seguir.
Arquitetura Cliente-Servidor
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de 
computação onde um grande número de PCs, estações de trabalho, servidores de arquivos, 
impressoras, servidores de banco de dados e outros equipamentos são conectados juntos 
por uma rede. 
A ideia é definir servidores especializados, tais como servidor de arquivos (que 
36
Banco de Dados
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