Bacharelado em Sistemas de Informao

Banco de Dados

Prof. Dory Gonzaga Rodrigues

Apostila Adaptada
Autora
Sandra de Albuquerque Siebra
Doutora em Cincia da Computao, pelo Centro de Informtica da UFPE
Professora da Universidade Federal Rural de Pernambuco (UFRPE).

Sumrio
Captulo 1 Banco de Dados...............................................................................................................4
Alguns Conceitos Bsicos...............................................................................................................4
Como era antes de surgirem os bancos de dados?...........................................................................6
Resumo da Origem dos Bancos de Dados..................................................................................7
O Sistema Gerenciador de Banco de Dados (SGBD)......................................................................9
Estrutura Geral de um SGBD........................................................................................................11
Classes de Usurios de um Sistema de Banco de Dados...............................................................12
Alguns Exemplos de SGBDs.........................................................................................................12
Captulo 2 Evoluo e Arquitetura dos Bancos de Dados...............................................................14
Evoluo do armazenamento de dados..........................................................................................14
Primeira Gerao dos Bancos de Dados........................................................................................14
Modelo de Dados Hierrquico..................................................................................................14
Modelo de Dados em Redes......................................................................................................16
Segunda Gerao dos Bancos de Dados........................................................................................17
Modelo de Dados Relacional....................................................................................................17
Terceira Gerao dos Bancos de Dados.........................................................................................18
Modelo de Dados Orientado a Objetos.....................................................................................18
Modelo de Dados Objeto-Relacional........................................................................................19
Arquiteturas de Sistemas de Banco de Dados...............................................................................19
Arquiteturas Centralizadas........................................................................................................20
Arquitetura Cliente-Servidor.....................................................................................................20
Arquitetura Distribuda.............................................................................................................22
Arquitetura Paralela..................................................................................................................23
Arquitetura Mono-Usurio........................................................................................................24
Abstrao de Dados.......................................................................................................................24

Captulo 1 Banco de Dados

Neste captulo, vamos comentar sobre os conceitos bsicos da rea de Banco de Dados. Essa uma rea muito
presente no nosso dia-a-dia e que ganha ainda mais importncia quando paramos para pensar que estamos vivendo
na chamada Era da Informao, onde o conhecimento adquirido a partir da avaliao das informaes o maior bem
de qualquer empresa ou instituio. E informaes so obtidas a partir de dados que precisam estar armazenados em
algum lugar.
Voc poderia me perguntar, mas dados e informaes no seriam a mesma coisa? No, no so. Vamos diferenciar.
Dado: um elemento que mantm a sua forma bruta (texto, imagens, sons, vdeos, etc.) e ele sozinho no levar a
compreender determinada situao. Ou seja, o termo Dado envolve fatos, imagens, sons que podem ou no serem
teis para determinado fim, eles apenas representam coisas do mundo real.
Informao: J a Informao o conjunto de dados coletados de forma a se tornarem aplicveis a determinada
situao, ou seja, sua forma e contedo so apropriados para um uso especfico. A informao no existe por si s, ela
obtida atravs de uma interpretao realizada sobre um grupo de dados. Alm disso, ela necessita de uma situao
ou objetivo que justifique a sua existncia. Vamos dar alguns exemplos. O nome de um cliente, o nmero de peas em
um estoque, o nmero de horas trabalhadas por um empregado e o valor total de um pedido so dados. J o valor
total das vendas por ms de uma loja uma informao que para ser obtida, vai precisar considerar uma srie de
dados (tais como, o ms de cada pedido e o valor total do pedido) armazenados em algum lugar.
O Banco de Dados, geralmente, ser esse lugar onde os dados estaro armazenados e a partir do qual voc ir extrair
informaes para finalidades diversas. Mas, finalmente, qual a definio de Banco de Dados?

Alguns Conceitos Bsicos

Um Banco de Dados (tambm chamado de Base de Dados) uma coleo de dados relacionados, organizados e
armazenados visando facilitar a manipulao dos dados armazenados, permitindo realizar alteraes, inseres,
remoes e consultas. Os tipos de colees de dados so ilimitados (ex: dados de um produto, de um estudante,
mapas, dados sobre genes humanos, etc), ou seja, quaisquer aplicaes do mundo real que possam ser representadas
atravs de dados computveis podero ser armazenadas em um banco de dados. Vamos ver agora, algumas definies
mais formais:
Um Banco de Dados uma coleo de dados operacionais armazenados, sendo usados pelos sistemas de aplicao
de uma determinada organizao (DATE, 2000).
Um Banco de dados um conjunto de dados armazenados, cujo contedo informativo representa a cada instante, o
estado atual de uma determinada aplicao (LAENDER, 1993).
Um banco de dados uma coleo de dados relacionados que representa alguns aspectos do mundo real, sendo
chamado, s vezes, de mini mundo. (ELMASRI e NAVATHE, 2005)
Realmente, como definiram ELMASRI e NAVATHE, um banco de dados (BD) um modelo de uma determinada parte da
realidade, geralmente denominada de Universo de Discurso ou mini mundo. Isso porque s devemos colocar no banco
de dados as informaes do domnio que sejam relevantes para a resoluo de um problema ou para obter
determinadas informaes. Vamos dar um exemplo. Suponha que precisamos criar um banco de dados para uma
Livraria. O mini mundo da Livraria englobaria diversas caractersticas que a definem como, por exemplo, o seu nome, a
sua localizao, os dados dos seus proprietrios, os dados dos funcionrios que trabalham l, os dados dos livros
disponveis e de qualquer outro produto que esteja sendo comercializado. Essas informaes so interessantes para
serem armazenadas e, posteriormente recuperadas. Porm, por exemplo, as cores das paredes da livraria, o material
de que feito o cho, no so caractersticas relevantes para serem consultadas em um sistema, logo, no fariam
parte dos dados a serem armazenados no banco de dados. Logo, o mini mundo ser justamente a especificao da

parte do mundo real que relevante para a implementao da livraria (vide Figura 1) e dever conter informaes que
caracterizem o domnio do negcio.

Figura 1 - O Mundo Real x Mini Mundo

Um banco de dados pode ser criado e mantido por um conjunto de aplicaes 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 manipulao dos dados armazenados em um BD. O SGBD tem uma gama de funes pr-implementadas que
gerenciam as operaes de insero, remoo, atualizao e consulta dos dados armazenados.
O conjunto formado por um banco de dados mais as aplicaes 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
informao. 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 usurios finais (as pessoas que o utilizaro). Num primeiro nvel as pessoas
interagem com os programas de aplicao (programas desenvolvidos em uma linguagem de aplicao), que foram
criados para os usurios finais utilizando-se uma linguagem de consulta (linguagem prpria para acesso ao banco de
dados). Esta aplicao interage com o SGBD, que possui programas responsveis por processar as consultas e acessar
os dados armazenados, dentre outras funes. Por fim, num nvel mais interno, encontra-se a base de dados, separada
em dois arquivos distintos, um contendo a definio dos dados e outro contendo os dados propriamente ditos, ou
seja, os dados armazenados.

Figura 2 - Sistema de Banco de Dados

A separao 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 caractersticas prprias altera-se pouco. Por exemplo, define-se que o endereo
do estudante deve ser um campo alfanumrico com capacidade para armazenar 80 caracteres. J os dados
armazenados mudam muito uma vez que a cada nova insero, alterao ou remoo de dados, os dados so
modificados. Por exemplo, o endereo 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 caractersticas distintas. O arquivo contendo a definio dos

dados o que podemos chamar de metadados, ou dados sobre os dados. Ou seja, so dados cujo significado reflete
caractersticas dos prprios dados, como por exemplo: de que tipo so estes dados? Qual ser o tamanho deles? Ele
pode ficar em branco ou no? Etc.

Como era antes de surgirem os bancos de dados?

Antes de existirem os bancos de dados, qualquer sistema, programa ou aplicao que precisasse armazenar e
manipular dados fazia uso de um sistema de arquivos. Ou seja, cada sistema, programa ou aplicao desenvolvido
tinha seus prprios 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 implicao 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 programao diferentes. Qual o problema com isso? O problema com isso que entre os diversos
sistemas desenvolvidos gradualmente para uma determinada empresa ou instituio poderiam haver dados em
comum. Vamos dar um exemplo: suponha uma fbrica que possui um Sistema de Vendas, um Sistema de Produo e
um Sistema de Engenharia (vide Figura 3). Cada um deles teria seus prprios arquivos e nesses arquivos poderia existir
em comum, por exemplo, os dados de um produto, que por causa dessa organizao precisaria ser replicado em cada
sistema de arquivos. E qual a consequncia dessa replicao de dados dentro de uma mesma fbrica?

Figura 3 - Exemplo de sistemas que fazem uso de um

Sistema de Arquivos

A consequncia que essa redundncia poderia acarretar inconsistncia dos dados, uma vez que a mesma informao
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
consistncia, eu teria de entrar nos arquivos de Produo e de Engenharia e fazer a mesma atualizao. Se no fizesse,
os dados do produto na fbrica ficariam inconsistentes, pois dependendo do sistema acessado o produto 01 poderia
ser Mesa ou Cadeira. Ficou claro?
Alm disso, a duplicao 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 redigitao de dados (e esse
trabalho repetitivo pode levar a erros, que tambm geram inconsistncias entre os dados). Adicionalmente, o uso de
sistemas de arquivos possui outros problemas tais como:
Dificuldade do acesso a dados a gerao de informao pode surgir, durante o tempo em que o sistema
est em produo, sob diferentes aspectos. Cada requisio de informao diferente, no sistema de arquivos, vai gerar
a necessidade da criao de um programa aplicativo, de uma nova consulta ou de um novo relatrio. Dessa forma, a
recuperao de informao no atendida de modo eficiente. Haveria dificuldade em apagar informaes dos
sistemas. Poderia novamente ocorrer casos de inconsistncia, onde um produto poderia ser deletado dos arquivos de
Vendas, mas no dos outros dois arquivos (Engenharia e Produo).
Isolamento dos dados os dados esto armazenados em arquivos distintos, que no possuem qualquer
tipo de relacionamento direto, e ainda, podem conter diferentes formatos para o mesmo dado. Por exemplo, o cdigo

do produto nos arquivos de venda poderia ser representado s por nmeros e nos arquivos de Produo por letras e
nmeros.
Problemas de integridade fica difcil manter restries de integridade automaticamente. E o que so
essas restries de integridade? Seriam checagens de determinadas condies a serem feitas pelo sistema sobre os
dados armazenados (por exemplo, a quantidade de produtos em estoque no pode ser inferior a um valor X). Essas
restries teriam de ser mantidas pelo sistema, implicando em implementao do cdigo apropriado para fazer esse
tipo de checagem em CADA UM dos sistemas afetados. O problema seria que a cada incluso de uma nova restrio de
integridade, um novo cdigo deveria ser escrito EM CADA SISTEMA para poder mant-la, j que cada sistema trabalha
com um diferente sistema de arquivos.
Problemas de segurana Nem todos os usurios do sistema devem estar autorizados a ver/acessar todos
os dados armazenados. Porm, uma vez que os programas de aplicao so inseridos no sistema como um todo, de
forma aleatria ( medida que a necessidade surge, lembra?) difcil implementar e garantir a efetividade de regras de
segurana.
Anomalias no acesso concorrente a melhora de desempenho em um sistema pode ocorrer pela execuo
simultnea de diversas operaes. Geralmente, nos sistemas de arquivos, esta melhoria seria difcil de implementar
sem levar a danos na consistncia dos dados. Ou seja, seria difcil permitir que mltiplos usurios possam ter acesso
aos dados ao MESMO TEMPO. Vamos dar um exemplo. Considere um sistema bancrio (com a existncia de contas
correntes, agncias, transaes bancrias, etc) e a seguinte situao: suponha que o saldo de uma conta bancria 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 execuo das duas instncias do programa de dbito, ambos os clientes lerem
o saldo inicial original e retirarem, cada um, seu valor correspondente, e seja ento 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
esto realizando a operao em cima dos 500 reais iniciais que foi lido;
3. Dependendo de qual execuo do programa de dbito 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 so:
A definio das estruturas dos arquivos est inserida no prprio cdigo dos programas, sistemas ou
aplicativos, dificultando a manuteno;
Compartilhamento de um arquivo por vrios programas fica comprometido. H a necessidade de duplicar a
definio 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 programao diferentes.
Justamente a necessidade de resolver diversos desses problemas motivou a criao 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

Resumo da Origem dos Bancos de Dados

No incio da computao, os programas tinham o nico objetivo de armazenar e manipular dados. Esses programas
gravavam seus dados em arquivos em disco, segundo estruturas de dados prprias (vide Figura 5). Programas que no
conhecessem a estrutura dos dados no podiam utilizar os dados.

Figura 5 - Programa acessando seu arquivo

Se vrios 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 definio dos dados deveria estar dentro dos
programas que os manipulariam.

Figura 6 - Vrios programas acessando os

dados tinham de conhecer sua estrutura

Se um programa precisasse realizar alguma mudana na estrutura de dados, todos os programas que acessam os
dados tinham que ser alterados, mesmo que a alterao ocorresse em dados no manipulados pelos outros
programas. Isso gerava um grande problema: Como garantir a unicidade das estruturas de dados entre os diversos
programas devido existncia de redundncias? Para evitar esse problema, colocou-se um sistema intermedirio 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 atravs de um

sistema intermedirio

Agora, atravs do uso desse sistema intermedirio:

Os programas passariam a enxergar apenas os dados que lhes interessam.
Os programas no precisariam conhecer os detalhes de como seus dados esto gravados fisicamente.
Os programas no precisariam ser modificados se a estrutura de dados que utilizam no for modificada.
As alteraes ficariam concentradas nesse sistema intermedirio.
Com o tempo, esse sistema intermedirio passou a gerenciar vrios arquivos (vide Figura 8) e a essa coleo de
arquivos foi dado o nome de Banco de Dados e ao sistema intermedirio deu-se o nome de Sistema Gerenciador de
Banco de Dados (SGBD).

Figura 8 - SGBD gerenciando o acesso aos

arquivos usados pelos programas

O Sistema Gerenciador de Banco de Dados (SGBD)

Vimos anteriormente neste captulo que um Sistema de Banco de Dados (SBD) o conjunto formado por um banco de
dados (BD) mais as aplicaes que o manipulam (o SGBD). Assim, um SGBD uma coleo de programas que habilitam
usurios a criar e manter um banco de dados. Ele um software de propsito geral, que facilita o processo de
definio, construo e manipulao de um banco de dados.
Definio do banco de dados envolve especificar estruturas e tipos de dados para serem gravados no banco
de dados, com uma descrio detalhada de cada tipo de dado.

Construo do banco de dados o processo de consistir e gravar inicialmente dados no banco de dados.
Manipulao de um banco de dados inclui funes como consulta por dados especficos e atualizao para
refletir as alteraes no mundo real.

Quais caractersticas esse software deve ter? Vamos apresent-las a seguir:

Independncia de Dados consiste na capacidade de tornar as caractersticas fsicas dos dados (como
localizao, estrutura e tamanho) transparentes para a aplicao. Ou seja, os SGBD devem ser dotados de recursos que
possibilitem a descrio das estruturas de dados (layout de arquivos e/ou tabelas) de forma independente dos
procedimentos de manipulao (leitura e gravao) de dados no BD. Isto possibilita tornar transparente para os
programas que acessam o BD as alteraes que, por ventura, venham a ocorrer nas estruturas de dados, como, por
exemplo, o acrscimo de um novo campo de informao ao banco. Da mesma forma, alteraes em lgicas de
programas que acessam o BD no 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 especficos e independentes para as
tarefas de criao e alterao de tabelas (DDL Data Definition Language) e leitura e atualizao do BD (DML Data
Manipulation Language).
Reduo ou Eliminao de Redundncias Em um sistema tradicional de controle de arquivos cada usurio
normalmente apresenta seus prprios arquivos armazenando o conjunto de dados que de seu interesse e, nestes
casos, comum ocorrer redundncia de dados. Esta redundncia consiste no armazenamento de uma mesma
informao em locais diferentes. Por exemplo, o nome do funcionrio poderia estar nos arquivos dos Sistemas de
Cadastro, de Folha de Pagamento e de Avaliao em uma empresa, se esses no tivessem uma nica base de dados
compartilhada. A redundncia danosa para o ambiente computacional, pois ela leva a um aumento de esforo
computacional para realizar a atualizao dos dados redundantes e aumento do espao necessrio para o
armazenamento destes dados. Porm, o problema mais srio que a representao dos dados desta forma pode
tornar-se inconsistente, pois duas informaes podem aparecer em locais distintos, mas apresentando valores
diferentes. Dessa forma, um SGBD deve prover meios para que seja possvel o controle da redundncia de dados nos
diversos arquivos administrados por ele. Para isso, os dados que eventualmente so comuns a mais de um sistema
devem ser compartilhados por eles, fazendo-os acessar um mesmo banco de dados. Alm disso, deve haver uma
centralizao da definio dos dados num Dicionrio de Dados ou Catlogo, que vai servir como base para a operao
do SGBD.
Eliminao de Inconsistncias Geralmente causada pela redundncia de dados, a inconsistncia ocorre
quando um mesmo campo tem valores diferentes em sistemas diferentes. Por exemplo, o estado civil de um
funcionrio 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 no o atualizou em outro. Quando o dado
armazenado em um nico local (no caso, o banco de dados) e compartilhado pelos sistemas, este problema no
ocorre.
Compartilhamento dos Dados Permite a utilizao simultnea e segura de um dado, por mais de uma
aplicao ou usurio (atravs do tratamento de concorrncia), independente da operao que esteja sendo realizada.
O compartilhamento de dados visa diminuir a redundncia de dados. Para implementar o compartilhamento de dados

10

 necessrio que o SGBD possua um competente sistema de segurana, para que se estabelea a privacidade de
dados, atravs de mecanismos de restrio de acesso.
Tratamento de Concorrncia para que seja possvel um compartilhamento simultneo dos dados
armazenados no banco de dados, o SGBD implementa o tratamento de concorrncia. Ou seja, o SGBD deve possuir
mecanismos para a identificao e tratamento dos acessos concorrentes, para garantir a consistncia das informaes
do BD no sentido de sua veracidade. Os sistemas de bloqueio (LOCK) e desbloqueio (UNLOCK) so os mecanismos
utilizados para evitar que uma informao que est sendo manipulada por um determinado usurio U1, seja alterada
por outro usurio U2. Enquanto o primeiro usurio U1 estiver acessando um dado no BD, o segundo usurio U2 no
ter acesso ao mesmo ou o ter apenas para leitura e receber um aviso do SGBD de que a informao est sendo
acessada por outro usurio e pode estar sendo modificada.
Privacidade dos Dados um SGBD deve fornecer um subsistema de autorizao e segurana (por exemplo,
atravs de senhas e sistemas de LOG e AUDIT, o qual utilizado pelo DBA para criar contas e especificar as restries
destas contas; o controle de restries se aplica tanto ao acesso aos dados quanto ao uso de softwares inerentes ao
SGBD. Dessa forma, torna-se possvel definir, para cada usurio, o nvel de acesso a ele concedido (leitura, leitura e
gravao ou sem acesso) a tabela e/ou campo. Este recurso impede que pessoas no autorizadas utilizem ou atualizem
uma determinada tabela ou campo, bem como que utilizem softwares inadequados ao seu perfil.
Segurana dos Dados o SGBD deve oferecer meios que resguardem a base de dados nos casos de falha de
programa, equipamento ou acidentes. Tambm deve ser possvel que alteraes indevidas feitas pelos usurios
durante a operao dos aplicativos sejam desfeitas sem prejuzo da coerncia dos dados. A segurana fsica dos dados
poder ser obtida a partir de utilitrios e aplicativos que os fabricantes colocam em seus produtos, visando facilitar o
trabalho de proteo aos dados contra danos fsicos, que podem ser causados por falhas de hardware ou queda da
rede. Nessa linha destacam-se as rotinas de backup (cpias de segurana dos dados armazenados) e a gravao com
espelhamento (voc ter duas mquinas diferentes com o banco de dados instalado e periodicamente ele ser replicado
de uma mquina para outra, para se uma sair do ar, a outra j assumir).
Padronizao 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 comunicao e a cooperao entre vrios departamentos,
projetos e usurios. Padres podem ser definidos para formatos de nomes, elementos de dados, telas, relatrios,
terminologias, etc. O DBA pode obrigar a padronizao em um ambiente de base de dados centralizado, muito mais
facilmente que em um ambiente onde cada usurio ou grupo tem o controle de seus prprios arquivos e software;
Controle de Transaes Uma Transao um conjunto de operaes sobre o BD que devem ser
executadas integralmente e sem falhas ou interrupes. Caso contrrio, devem ser desfeitas. Todo SGBD deve realizar
o controle das Transaes.
Integridade dos Dados A integridade de dados refere-se a mecanismos que esto disponveis nos SGBD,
que garantem a consistncia dos dados armazenados no SGBD, segundo parmetros de validao, especificados no
momento de criao do BD, em conjunto com as estruturas de dados. Ou seja, esses mecanismos garantem que o
contedo dos dados armazenados no Banco de Dados possua valores coerentes ao objetivo do campo, no permitindo
que valores absurdos sejam cadastrados. Por exemplo: No permite que uma data final seja menor do que uma data
inicial.
Representao de Relacionamento Complexo entre Dados uma base de dados pode possuir uma
variedade de dados que esto inter-relacionados 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 fcil e eficiente
Possibilidade de Mltiplas Interfaces Vrios usurios representam tambm necessidades diversas no que
se refere aos tipos de interfaces fornecidas pelo SGBD. Interfaces para consultas de dados, programao, e interfaces
baseadas em menus ou em linguagem natural so exemplos de alguns tipos que podem estar disponveis.

11

Estrutura Geral de um SGBD

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

Figura 9 - Estrutura Geral do SGBD

Pr-compilador da DML converte comandos da DML 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 cdigo apropriado.
Compilador DDL converte comandos da DDL em um conjunto de tabelas contendo metadados (dados
sobre dados), que so armazenados no Dicionrio de Dados.
Processador de consultas traduz os comandos em uma linguagem de consulta para instrues de baixo
nvel que o gerenciador do banco de dados pode interpretar. Alm disso, o processador de consultas tenta transformar
uma requisio do usurio em uma forma compatvel e mais eficiente com respeito ao banco de dados, encontrando
uma boa estratgia para executar a consulta.
Gerenciador do banco de dados fornece a interface entre os dados de baixo nvel armazenados no disco e
os programas aplicativos e de consulta submetidos ao sistema.
Gerenciador de arquivos gerencia a alocao do espao na armazenagem do disco e as estruturas de
dados usadas para representar a informao armazenada no disco. o gerenciador de memria quem traduz os
diversos comandos DML em comandos de baixo nvel para atuar sobre os dados armazenados na base de dados.
Adicionalmente, diversas estruturas de dados so requeridas como parte da implementao do sistema fsico,
incluindo:
Arquivos de dados armazenam o banco de dados propriamente dito.
Dicionrio de dados armazena informaes sobre a estrutura do banco de dados. Tambm chamado de
catlogo de dados, contm os metadados, isto , as informaes a respeito dos componentes do banco de dados:
tabelas, ndices, procedimentos, restries e outros.
ndices proporcionam acesso rpido aos itens de dados com valores especficos. So estruturas que
permitem um acesso mais eficiente aos dados.

12

Classes de Usurios de um Sistema de Banco de Dados

Um Banco de Dados pode apresentar diversos usurios cada qual com uma necessidade em particular, e com um
envolvimento diferente com os dados do BD. Voc sabe quais so eles? No? Que tal conhecer um pouco mais? Os
usurios podem ser classificados nas seguintes categorias:
Administrador de Bancos de Dados (DBA DataBase Administrator) em qualquer organizao onde
muitas pessoas compartilham diversos recursos, existe a necessidade de um administrador chefe (sempre existe o que
vai ficar frente, no ?) para supervisionar e gerenciar estes recursos (em um ambiente de base de dados, o recurso
primrio a prpria base de dados e os recursos secundrios so o prprio SGBD e software relacionados). A
administrao desses recursos de responsabilidade do DBA. Ele responsvel, entre outras coisas, por autorizar
acesso base de dados e coordenar e monitorar seu uso. Adicionalmente, ele responsvel por problemas, tais como,
quebra de segurana ou baixo desempenho do BD.
Projetista de Bancos de Dados tambm 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 responsvel pelo projeto de construo e utilizao do BD, envolvendo
as tarefas de definio de quais dados devero ser construdos e como eles sero construdos. Pode existir um nico
projetista ou um grupo deles e ele(s) ir(ao) interagir com outras classes de usurios, tanto os analistas e
programadores, como os chamados usurios finais do sistema, a fim de obter a viso dos dados que cada um possui,
integrando-as de forma a se obter uma representao adequada de todos os dados.
Usurios Finais existem profissionais que precisam ter acesso base de dados para consultar, modificar e
gerar relatrios. A base de dados existe para estes usurios.
Existem algumas categorias de usurios finais:
Usurios ocasionais: ocasionalmente fazem acesso base de dados, mas eles podem necessitar de
diferentes informaes a cada vez que fazem acesso. Eles podem usar uma linguagem de consulta sofisticada
para especificar suas requisies e so, tipicamente, gerentes de mdio ou alto nvel;
Usurios comuns ou paramtricos: estes usurios realizam operaes padres de consultas e atualizaes,
chamadas transaes permitidas, que foram cuidadosamente programadas e testadas. Estes usurios
constantemente realizam recuperaes e modificaes na base de dados;
Usurios sofisticados: incluem engenheiros, analistas de negcios e outros que procuraram familiarizar-se
com as facilidades de um SGBD para atender aos seus complexos requisitos;
Analistas de Sistemas e Programadores de Aplicaes: so os Engenheiros de Software, aquelas pessoas
que determinam as necessidades dos usurios finais e desenvolvem as especificaes para as transaes que
iro atender a estas necessidades. Os programadores das aplicaes so as pessoas que iro realmente
implementar estas especificaes, criando os programas que iro constituir o sistema e fazer acesso ao BD.
Adicionalmente, os programadores tambm so os responsveis por testar os programas criados. Muitos de
ns nos enquadramos nessa ltima categoria de usurios (usurios finais).
Podem existir ainda alguns profissionais de apoio ou suporte para realizar tarefas especficas como tirar
backup (cpia de segurana) dos dados armazenados no Banco de Dados.

Alguns Exemplos de SGBDs

Alguns dos principais SGBDs disponveis no mercado nos ltimos anos so:
Oracle um sistema comercial, mas possui verses gratuitas para uso acadmico e/ou domstico (em
casa). Ele foi o primeiro Banco de Dados Corporativo (cliente/servidor) possuindo grande variedade de distribuies

13

(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 padro a SQL, mas possui tambm uma linguagem prpria para
desenvolvimento de aplicaes, a PL/SQL4. A participao do Oracle no mercado de Banco de Dados bastante
acentuada, principalmente em grandes empresas e em conjunto com sistemas de mdio e grande porte. um SGBD
robusto e seguro, quando bem administrado. Alm da base de dados, a Oracle desenvolve uma sute de
desenvolvimento chamada de Oracle Developer Suite, utilizada na construo 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 verses atuais so independentes e operam
exclusivamente sobre Windows. um software proprietrio e pago, como a maioria dos produtos Microsoft. Algumas
empresas que usam o MS SQL Server. 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 verses do DB2 que rodam desde num simples PDA (computador de mo), at em potentes mainframes e
funcionam em servidores baseados em sistemas Unix, Windows ou Linux. DB2 vendido em diversos tipos de edies
ou licenas. Pela escolha de uma verso com menos recursos, a IBM evita que os consumidores paguem por coisas que
no iriam usar. Informaes em http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
Interbase um sistema gerenciador de banco de dados relacionais da Borland. Foi includo, 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. Alm de no ser pesado relativamente rpido e
suporta bancos de dados de grande tamanho (maiores que 2 Gigabytes).Em 2000 a Borland liberou o cdigo da verso
6.0, mas as posteriores voltaram a ter licena proprietria. Desta verso 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 cdigo 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 Fundao FirebirdSQL coordena a manuteno e
desenvolvimento do Firebird, sendo que os cdigos fonte so disponibilizados sob o CVS da SourceForge. O produto
bastante seguro e confivel, suportando sistemas com centenas de usurios simultneos e bases de dados com
dezenas/centenas de gigabytes. H suporte gratuito na Internet atravs de vrios sites. O Firebird amplamente
utilizado em todo o mundo, com a maior base de usurios no Brasil, Rssia e Europa. Site Oficial em
http://www.firebirdsql.org/
MySQL , atualmente, um dos bancos de dados mais populares, com mais de 10 milhes de instalaes
pelo mundo. Ele possui verses para Windows, Solaris, Unix, FreeBSD, Linux e gratuito para uso no-comercial.
Algumas das empresas mais famosas que fazem uso deste banco esto: NASA, Banco Bradesco, Dataprev, HP, Nokia,
Sony e Lufthansa. O MySQL usado principalmente para desenvolvimento WEB como servidor de dados para
comrcio eletrnico. Passou a ser considerado um SGBD de verdade (com conceito de transao) a partir da verso 5.
Site Oficial em http://www.mysql.com/
PostgreSQL um sistema gerenciador de banco de dados objeto relacional (SGBDOR), desenvolvido como
projeto de cdigo aberto. Ele um dos SGBDs (Sistema Gerenciador de Bancos de Dados) de cdigo aberto mais
avanados, grautito e tem uma boa aceitao no mercado. Originalmente concebido para rodar em Linux, ele possui
verses para Windows. usando, principalmente, para comrcio eletrnico juntamente com linguagem PHP. O
PostgreSQL um projeto open source coordenado pelo PostgreSQL Global Development Group. Site Oficial em
http://www.postgresql.org/
Dos SGBDs listados acima vale ressaltar que o SQL Server e o Oracle tem verses gratuitas, porm limitadas. O Firebird
e o PostgreSQL so open source, o DB2 pago e o MySQL gratuito para desenvolvimento, mas pago para produo.
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
vrios sistemas de instituies pblicas vm adotando o mesmo. J no mundo corporativo o Oracle tem sido um dos

14

mais adotados, por ser um dos mais robustos.

15

Captulo 2 Evoluo e Arquitetura dos Bancos de Dados

Neste captulo, vamos estudar a evoluo dos SGBDs no tempo, que deram origem a geraes diferentes de banco de
dados, alm de estudar a forma como os bancos de dados esto organizados internamente, ou seja, a sua arquitetura.

Evoluo do armazenamento de dados

Como visto no captulo anterior, no comeo, no existiam bancos de dados, mas apenas os sistemas de arquivos. Ou
seja, cada aplicao ou programa desenvolvido para uma organizao tinha seu prprio conjunto de dados e a
descrio desses dados ficava dentro das prprias aplicaes. Dessa forma, no havia compartilhamento de dados
entre as mesmas. Devido a isso, diversos problemas surgiam, tais como redundncia de dados, inconsistncias, falta de
padronizao, falta de segurana no acesso aos dados, limitaes no compartilhamento dos dados, entre outros. Os
bancos de dados surgiram como forma de tentar resolver esses problemas. Os bancos de dados no foram sempre os
mesmos, inclusive so subdivididos em trs geraes bem definidas (vide Figura 10), cada uma com caractersticas
prprias. Na primeira gerao, que surgiu no final dos anos 60, esto os bancos de dados hierrquicos e em rede. Na
segunda gerao que nasceu no final dos anos 70 est o banco de dados relacional. E, por fim, a gerao mais atual
que data desde o final dos anos 80 esto os bancos de dados orientado a objetos e objeto-relacional. A seguir,
detalharemos cada uma dessas geraes.

Figura 10 - Evoluo dos Bancos de Dados

Primeira Gerao dos Bancos de Dados

Os primeiros bancos de dados surgiram nos anos 60, com o surgimento dos bancos de dados hierrquicos e em rede,
com acesso sequencial aos dados e processamento em batch (em lote, vrias instrues de uma vez), essa foi a
chamada primeira gerao. Os dois modelos da poca eram o Hierrquico e o em Rede, ambos orientados a registros,
isto , qualquer acesso base de dados insero, consulta, alterao ou remoo era feita em um registro de cada
vez. Vamos detalhar agora, cada um desses modelos.

Modelo de Dados Hierrquico

O modelo hierrquico foi o primeiro a ser reconhecido como um modelo de dados. Nesse modelo de dados, os dados
so estruturados em hierarquias ou rvores (lembra das rvores que voc estudou na disciplina de estrutura de
dados?). Os ns das hierarquias contm ocorrncias de registros, onde cada registro uma coleo de campos

16

(atributos), cada qual contendo somente um valor.

Os registros so conectados uns aos outros por meio de uma ligao, tambm chamada de link (associao essa entre
exatamente dois registros). O registro da hierarquia que precede a outros o registro-pai, os outros so chamados de
registros-filhos. O relacionamento entre um registro-pai e vrios 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
representao da Figura 11).

Figura 11 - Relao 1-N entre registro-pai e registros-filhos

Os dados organizados, segundo este modelo, podem ser acessados segundo uma sequncia hierrquica com uma
navegao do topo (raiz) para as folhas (ns sem filhos) e da esquerda para a direita dentro de cada n ou registro. Um
mesmo registro pode estar associado a vrios registros diferentes, desde que seja replicado. Porm, a replicao
possui duas grandes desvantagens: pode causar inconsistncia de dados quando houver atualizao e causar
desperdcio de espao.
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
contedo, serve apenas para iniciar a rvore). Teramos ns 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 ns que
representariam as contas (com valores para o nmero 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 duplicao de registros,
devido representao em rvore. Por exemplo, suponhamos que Silvia e Rui possuem a conta conjunta de nmero
7556 (vide Figura 12, os ns com o nmero 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.

Figura 12 - Exemplo de Modelo Hierrquico

Figura 13 - Representao dos ns

usada no exemplo

Alm de poder causar inconsistncia de dados quando houver atualizao e causar desperdcio de espao, outros
problemas encontrados no modelo hierrquico so:

17

 Nem tudo pode ser representado como uma hierarquia;

Complexidade dos diagramas de estrutura de rvore;
No pode haver ciclos no grfico bsico de um diagrama de estrutura de rvore;
Restries cardinalidade dos links (no pode haver ligaes de muitos para muitos (N:M) e de muitos para um
(N:1));
Ausncia de facilidades de consultas declarativas (no h linguagem ou recurso especfico para isso), logo a
realizao de consultas uma atividade complexa;
Necessidade de navegao por ponteiros para acesso informaes;
O sistema comercial mais divulgado no modelo hierrquico 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 esto entre os primeiros a tratarem caractersticas como concorrncia, recuperao,
integridade e processamento eficiente de consultas. Alm dele, outros bancos que usavam o modelo hierrquico
foram: UNIVAC 1100, CDC 6000, CYBER 70 e 170.

Modelo de Dados em Redes

O modelo em redes surgiu como uma extenso ao modelo hierrquico, eliminando o conceito de hierarquia e
permitindo que um mesmo registro estivesse envolvido em vrias associaes. E que benefcios trs isso? Bem, isso faz
com que seja possvel construir relaes menos restritivas entre os registros. No modelo em rede, os registros so
organizados em grafos onde aparece um nico tipo de associao (set) que define uma relao 1:N entre 2 tipos de
registros: proprietrio e membro. Desta maneira, dados dois relacionamentos 1:N entre os registros A e D e entre os
registros C e D possvel construir um relacionamento M:N (muitos para muitos) entre A e D, o que no era possvel
no modelo hierrquico. Adicionalmente, ao contrrio do Modelo Hierrquico, 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 so organizados no banco de dados por um conjunto arbitrrio de
grafos. Na Figura 14, podemos ver o mesmo exemplo de registros de clientes e contas apresentado antes como
exemplo do modelo hierrquico, agora sendo representados pelo modelo em redes. Note que no h mais duplicao
do registro que representa a conta 7556 em negrito na Figura 14), por ser permitida mais de uma ligao (o que no
era possvel no modelo hierrquico). Note tambm a ausncia do registro falso (raiz).

Figura 14 - Exemplo de Modelo em Rede

As restries impostas pelo Modelo de Redes podem ser descritas como de ordem de Entrada e de Existncia. Em
relao s restries de entrada citamos a obrigatoriedade de cada novo registro estar conectado ao conjunto
indicado. Em relao a restries de Existncia 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 identificao de um conjunto pode ser verificada atravs do esquema
de ligao entre o registro pai e o registro filho, assim sendo, cada instncia de conjunto apresenta um elemento de
distino, o tal registro pai, e os registros filhos devidamente ordenados e, portanto, passveis de serem acessados
pelos seus elementos.
Alguns problemas do modelo em redes so:
O modelo de rede fortemente dependente da implementao.

18

 As consultas so complicadas: o programador forado a pensar em termos de links e, em como percorr-los para
obter as informaes de que necessita. Essa manipulao de dados chamada navegacional.
No Modelo em Rede o sistema comercial mais divulgado o CAIDMS da Computer Associates. Alm dele, h o
DBMS10, o IDS II, o DMS II e o IMAGE

Segunda Gerao 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 operao deve ser realizada, se no o for, deve ser desfeita, esse o conceito de transao).
Nos anos 80, foram lanadas as bases do modelo relacional (dando origem segunda gerao) 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 independncia de dados nos sistemas gerenciadores de banco de dados;
prover um conjunto de funes apoiadas em lgebra relacional para armazenamento e recuperao de dados;
permitir processamento ad-hoc
O Modelo Relacional (MR) considerado o primeiro modelo de dados efetivamente usado em aplicaes 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 relao (tabela). Na verdade, o modelo composto por uma coleo
de tabelas de nomes nicos. Cada relao ou tabela constituda por uma ou mais colunas chamadas de atributos
(campos) que so os tipos dos dados contidos na relao. O conjunto de valores passveis de serem assumidos por um
atributo ser intitulado de domnio. Cada linha da relao chamada de tupla (registro). O esquema de uma relao
nada mais do que os campos (colunas) existentes em uma relao ou tabela. J a instncia da relao consiste no
conjunto de valores que cada atributo assume em um determinado instante. As relaes no podem ser duplicadas
(por exemplo, no podem existir dois estados de Pernambuco, no conjunto de estados brasileiros) e a ordem de
entrada de dados no Banco de Dados no dever ter qualquer importncia para as relaes, no que concerne ao seu
tratamento.
Diferentemente dos modelos que o precederam o modelo relacional no tem caminhos pr-definidos para se fazer
acesso aos dados. Os relacionamentos entre as tabelas so feitos atravs do uso de valores de atributos. Por exemplo,
na Figura 15, a Tabela de Empregados precisa usar valores que esto, 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 restries precisaram ser impostas para evitar aspectos indesejveis, como:

19

Repetio de informao, incapacidade de representar parte da informao e perda de informao. Essas restries
so: integridade referencial, chaves e integridade de junes de relaes. Veremos em detalhes isso tudo no volume II
da disciplina. O modelo relacional faz uso da linguagem SQL para definio e manipulao 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 so: PostGreSQL, Oracle, SQLServer, MySql, entre
outros.

Terceira Gerao dos Bancos de Dados

Devido s necessidades do mundo moderno de manipular dados complexos, surgiu a terceira gerao 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 comearam a se tornar comercialmente viveis em meados de 1980. A
motivao para seu surgimento est em funo dos limites de armazenamento e representao semntica impostas no
modelo relacional. Um exemplo de modelo orientado a objetos so os sistemas de informaes geogrficas (SIG) que
so mais facilmente construdos usando tipos complexos de dados. A habilidade para criar os tipos de dados
necessrios uma caracterstica das linguagens de programao orientadas a objetos.
Contudo, estes sistemas necessitam guardar representaes das estruturas de dados que utilizam no armazenamento
permanente. A estrutura padro 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 disponveis
comercialmente. Membros do grupo tm o compromisso de incorporar o padro em seus produtos. O termo Modelo
de Dados Orientado a Objetos usado para documentar o padro que contm a descrio geral das facilidades de um
conjunto de linguagens de programao 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 perceptveis do modelo
relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se que tais bancos de dados ganhariam
grande parcela do mercado.
Hoje, porm, acredita-se que os Bancos de Dados Orientados a Objetos sero usados em aplicaes especializadas,
enquanto os sistemas relacionais continuaro a sustentar os negcios tradicionais, onde as estruturas de dados
baseadas em relaes so suficientes.
Alguns exemplos de banco de dados que fazem uso desse modelo so: O2, OBJECTSTORE, Cach e IRIS.
O diagrama de classes UML, usado na anlise 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 hierrquico e em rede, na Figura 16).

Figura 16 - Exemplo de Modelo de Dados Orientado a Objetos

20

Alguns problemas do modelo orientado a objetos so: ele no tem base terica (formalismo) como os modelos
anteriores e no existe linguagem padronizada para acesso e manipulao dos dados (tal qual o SQL). Isso fez com que
esse paradigma no fosse aceito no mercado. Como soluo surgiu o paradigma objeto-relacional.

21

Modelo de Dados Objeto-Relacional

A rea de atuao 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 semntica e construes
de modelagens. Neste modelo de dados, toda a informao 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 construdo combinando tipos de dados alfanumricos bsicos. Um suporte para tipos de
dados abstratos atrativo porque as operaes e funes associadas com o novo tipo podem ser usadas para indexar,
armazenar, e recuperar registros baseados no ndice do novo tipo de dado (por exemplo, multimdia).
Diferente do modelo orientado a objetos, o modelo objeto-relacional foi desenvolvido com base no modelo relacional.
Dessa forma, foi possvel unir conceitos de OO (tais como: supertabelas, supertipos, herana, reutilizao de cdigos
de criao, encapsulamento, controle de identidade de objetos e referncia a objetos) com conceitos do modelo
relacional (tais como: capacidade de consulta avanada e a alta proteo a dados). Assim, os modelos ObjetoRelacional combinam os benefcios do modelo Relacional com a capacidade de modelagem do modelo OO.
A linguagem de consulta objeto relacional uma extenso da linguagem SQL para suportar o modelo de objetos. As
extenses incluem consultas envolvendo objetos, atributos multivalorados, TADs, mtodos e funes como predicados
de busca em uma consulta.
Alguns motivos que levam a utilizao desse tipo de modelo so:
A incapacidade do modelo relacional bsico de resolver os desafios e atender as necessidades das novas aplicaes;
A capacidade de armazenar novos tipos de dados;
Fornecem suporte para consultas complexas sobre dados complexos
Atendem aos requisitos das novas aplicaes e da nova gerao de aplicaes de negcios
Algumas aplicaes para as quais necessrio o uso desse tipo de modelo so:
Armazenamento de imagens (obtidas por satlite ou de alguma outra forma digital);
Dados complexos no-convencionais em projeto de engenharia;
Grandes informaes sobre o genoma biolgico;
Projetos de arquitetura;
Dados de sries temporais em transaes;
Dados sobre o espao (regies geogrficas, criao de mapas);
Sistemas mveis e distribudos, dentre outros.
Alguns bancos de dados que fazem uso do modelo objeto-relacional so 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 considerao aspectos como:
Redes de computadores cujo surgimento colaborou para a diviso de tarefas entre mquinas 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 transaes por segundo;
Distribuio em que os dados residem na localidade em que so gerados ou em que sero mais teis, por meio de
diversas cpias do banco de dados. Uma arquitetura distribuda possibilita uma maior disponibilidade dos dados, que
podem ser acessados ainda que uma determinada localidade enfrente problemas e se torne indisponvel.

22

Como consequncia do emprego desses aspectos, temos as arquiteturas centralizadas, cliente-servidor, distribuda e
paralela que ser descrito a seguir.

Arquiteturas Centralizadas
As primeiras arquiteturas usavam mainframes6 para executar o processamento principal e de todas as funes do
sistema, incluindo os programas aplicativos, programas de interface com o usurio, bem como a funcionalidade dos
SGBDs. Esta a razo pela qual a maioria dos usurios fazia acesso aos sistemas via terminais que no possuam poder
de processamento, apenas a capacidade de visualizao (esses terminais eram muitas vezes chamados de terminaisburros, justamente por no terem poder de processamento). Ou seja, todos os processamentos eram feitos
remotamente, apenas as informaes a serem visualizadas e os controles eram enviados do mainframe para os
terminais de visualizao (tambm chamados de ns), conectados a ele por uma rede de comunicao (vide Figura
17).
Como os preos do hardware foram decrescendo, muitos usurios trocaram seus terminais por computadores pessoais
(PCs) e estaes de trabalho (tais como as estaes unix). No comeo os SGBDs usavam esses computadores da
mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, execuo de
programas aplicativos e processamento da interface do usurio eram executados em apenas uma mquina (a que
centralizava tudo). A arquitetura centralizada tem como principais vantagens: permitir que muitos usurios manipulem
grande volume de dados e que, com os dados totalmente isolados, se ganha consideravelmente em segurana, visto
que o acesso aos dados feito somente em um nico local. E a sua principal desvantagem a total dependncia 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
aplicao e interface junto ao usurio, que antes era de total responsabilidade do sistema centralizado, passou a ser
realizado pelos computadores pessoais, cabendo ao sistema centralizado apenas satisfazer s solicitaes geradas
pelos sistemas clientes. Assim, gradualmente, os SGBDs comearam a explorar a disponibilidade do poder de
processamento no lado do usurio, o que levou arquitetura cliente-servidor, que veremos a seguir.

Arquitetura Cliente-Servidor
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computao onde um grande nmero de PCs,
estaes de trabalho, servidores de arquivos, impressoras, servidores de banco de dados e outros equipamentos so
conectados juntos por uma rede.
A ideia definir servidores especializados, tais como servidor de arquivos (que mantm os arquivos de mquinas
clientes) ou servidores de impresso (que podem estar conectados a vrias impressoras), assim, quando se desejar
imprimir algo, todas as requisies de impresso so enviadas a este servidor. As mquinas clientes disponibilizam
para o usurio as interfaces apropriadas para utilizar esses servidores, bem como poder de processamento para
executar aplicaes locais. Esta arquitetura se tornou muito popular por algumas razes.
Primeiro, a facilidade de implementao dada clara separao das funcionalidades e dos servidores;

23

 Segundo, um servidor inteligentemente utilizado porque as tarefas mais simples so delegadas s mquinas
clientes, que so mais baratas;
Terceiro, o usurio pode executar uma interface grfica que lhe familiar, ao invs de usar a interface do servidor.
Diferentes tcnicas foram propostas para implementar essa arquitetura, sendo que a mais adotada pelos SGBDs
relacionais comerciais a incluso da funcionalidade de um SGBD centralizado no lado do servidor. A realizao de
consultas e a funcionalidade transacional (voc lembra do que uma transao?) permanecem no servidor, sendo que
este chamado de servidor de consulta ou servidor de transao. assim que um servidor SQL fornecido aos
clientes. Cada cliente tem que formular suas consultas (usando a linguagem SQL), prover a interface para o usurio e
as funes da interface usando uma linguagem de programao. Comumente, o servidor SQL tambm chamado de
back-end machine e a mquina 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 usurio (tela e processamento de entrada e sada), ferramentas de relatrio,
gerao de formulrios, anlise e minerao de dados. J o servidor (back_end machine) executa as consultas no SGBD
e retorna os resultados ao cliente, ficando responsvel por tarefas como o controle de acesso, otimizao de consultas,
controle de concorrncia, recuperao, etc. Como SQL prov uma linguagem padro para os SGBDs Relacionais, esta
criou o ponto de diviso lgica entre o cliente e o servidor. Dessa forma, a comunicao 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 conexo e a
comunicao entre as mquinas cliente e servidora. Exemplos de APIs so os padres ODBC8, JDBC9 que vo
justamente servir para a comunicao de programas escritos em uma linguagem de programao com os SGBDs.
Quando um programa escrito em uma linguagem de programao faz uso de uma API (tudo isso no lado do cliente)
para acesso a um banco de dados que est em uma mquina servidora (vide Figura 18), dizemos que se est usando
uma arquitetura clienteservidor de 2 camadas. Ou seja, a comunicao direta do cliente para o servidor. J a
arquitetura cliente-servidor em trs camadas, conta com a mquina cliente na qual um navegador web, atua como
front-end junto ao usurio para acessar um servidor de aplicao (tambm conhecido como servidor Web). Esse
servidor de aplicao atua em uma camada intermediria (a segunda camada), processando as solicitaes dos
usurios e fornecendo respostas obtidas atravs do acesso ao servidor de banco de dados (que a terceira camada),
que continua sendo o responsvel pela realizao de consultas e transaes no SGBD. Sistemas que lidam com grande
quantidade de usurios adotam essa arquitetura em trs camadas.

Figura 18 - Esquema de uma arquitetura em 2 camadas

Figura 19 - Esquema de uma arquitetura em 3 camadas

24

A principal vantagem da arquitetura cliente-servidor a diviso do processamento entre dois ou mais sistemas, o que
reduz o trfego de dados na rede.

Arquitetura Distribuda
A tecnologia de Banco de Dados Distribudos (BDDs) surgiu como uma intercalao de duas tecnologias: tecnologia de
banco de dados e tecnologia de comunicao de dados e de rede. Com as novas tecnologias de comunicao de
dados, atendendo necessidade da descentralizao, possvel se trabalhar com bancos de dados no mais
centralizados em um servidor, mas sim distribudos em vrios servidores. Podendo esses servidores estar na mesma
rede, assim como podem estar em pases diferentes, compartilhando informaes de uma maneira transparente para
os usurios. Assim, em um sistema de banco de dados distribudos, o banco de dados armazenado em diversos
computadores, que se comunicam uns com os outros atravs de vrios meios de comunicao, tais como redes de alta
velocidade ou linhas de telefone, em que cada qual pode participar na execuo de transaes que acessam dados em
um ou diversos ns (vide Figura 20).

Figura 20 - Esquema de um banco de dados distribudo

Nesta arquitetura, cada servidor atua como no sistema cliente-servidor, porm as consultas oriundas dos aplicativos
so feitas para qualquer servidor indistintamente. Caso a informao solicitada seja mantida por outro servidor ou
servidores, o sistema encarrega-se de obter a informao necessria, de maneira transparente para o aplicativo, que
passa a atuar consultando a rede, independente de conhecer seus servidores. Exemplos tpicos so as bases de dados
corporativas, em que o volume de informao muito grande e, por isso, deve ser distribudo em diversos servidores.
De forma simplificada, pode-se dizer que a principal diferena entre sistemas de bancos de dados centralizados e
distribudos que no primeiro os dados esto 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 distribudo alm de
ser mais confivel, tem a capacidade de resolver da melhor maneira os problemas grandes e complexos com os quais
nos defrontamos hoje, usando uma variao 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 vrios elementos de processamento.
Esses grupos de software devem colaborar de forma eficaz para a execuo de uma tarefa em comum. Outros motivos
para distribuir so:
Disponibilidade pois se um site sai do ar, os demais sites podem continuar em operao. Isso devido ao fato
que, como os dados so replicados em vrios ns, uma transao que necessita de um particular item de dado pode
encontr-lo em qualquer outro n. Com isso, a falha de um n no necessariamente implica na parada de
funcionamento de um sistema, aumentando a confiabilidade e disponibilidade do sistema.
Desempenho otimizado o desempenho otimizado dos SGBDs distribudos se baseia em dois pontos: Um SGBD
distribudo fragmenta o banco de dados, permitindo que os dados fiquem armazenados prximos a seus pontos de
utilizao, reduzindo o atraso de acesso remoto, alm disso, cada site manipula apenas uma parte do banco de dados,

25

tornando a administrao deste mais simples. O paralelismo inerente de sistemas distribudos pode ser explorado para
se obter paralelismo entre consultas e intraconsulta, assim possvel executar vrias consultas ao mesmo tempo e o
paralelismo intraconsulta alcanado desmembrando uma nica consulta em vrias subconsultas que sero
executadas em locais diferentes.
Facilidade de Expanso um sistema distribudo pode crescer mais facilmente que um sistema centralizado. Se for
necessrio expandir o sistema porque o volume de dados cresceu ou o volume de processamento aumentou, mais
fcil acrescentar um novo n rede de computadores, desde que os ns sejam autnomos, do que substituir um
sistema centralizado j existente por outro maior.
Porm, tudo na vida tem pontos positivos e negativos. Dessa forma, nos sistemas distribudos h um acrscimo de
complexidade para assegurar a coordenao entre os sites e h um custo para desenvolver os softwares de aplicao e
gerenciamento do sistema como um todo.

Arquitetura Paralela
Sistemas gerenciadores de bancos de dados paralelos so compostos por diversos processadores, memrias e discos,
utilizados em aplicaes crticas, que necessitam lidar com quantidades muito grandes de dados e oferecer baixos
tempos de resposta. A arquitetura paralela adequada aos seguintes casos:
Quando necessrio consultar bancos de dados extremamente grandes (na ordem de terabytes);
Quando necessrio processar um nmero muito grande de transaes por segundo (na ordem de milhares de
transaes por segundo).
Existem vrios modelos de arquitetura paralela. So eles:
Memria compartilhada Em um modelo de memria compartilhada, diversos processadores acessam uma nica
memria, por meio de barramento ou rede de interconexo (vide Figura 21). Esse modelo tem como vantagem o fato
de que os processadores podem trocar rapidamente mensagens entre si atravs da memria comum. E possui como
desvantagem o fato que o modelo no pode ser expandido a um nmero superior a 32 ou 64 processadores, visto que
o barramento ou a rede de interconexo entre processadores e memria se tornaria um gargalo e os processadores
passariam mais tempo aguardando pela sua vez para acessar memria do que realizando o processamento.

Figura 21 - Esquema do modelo paralelo de memria

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 interconexo, contudo, cada processador possui sua prpria memria
privada e exclusiva. Esse modelo tem como vantagens o fato de que, como cada processador possui sua prpria
memria, no h problemas de gargalo de acesso memria e pode-se maximizar o nmero de processadores
utilizados. Alm disso, h uma boa tolerncia a falhas, visto que caso um processador falhe, todos os demais
continuaro trabalhando normalmente e acessando os dados nos discos compartilhados de forma natural. Como
desvantagem, temos que, em relao ao modelo de memria compartilhada, a troca de mensagens entre os
processadores muito mais lenta, uma vez que necessrio que as mensagens trafeguem pela rede de interconexo
(tanto para acessar o disco, como para haver a comunicao entre os processadores).

26

Figura 22 Esquema do modelo paralelo de disco compartilhado

Nenhum compartilhamento Neste modelo (vide Figura 23), cada n possui seus prprios discos, processador e
memria, comunicando-se com os demais ns por meio de uma rede de interconexo de alta velocidade. Aqui, cada
n assume o papel de servidor em relao aos demais ns, oferecendo como servio o acesso aos dados que esto em
seus discos. A vantagem que esse modelo altamente escalvel, podendo admitir facilmente uma grande
quantidade de processadores. A desvantagem que o custo para comunicao e acesso aos dados em discos no
locais muito maior que nos modelos de memria e discos compartilhados, visto que, alm de ser necessria a
transmisso por rede, tambm h a interao entre os softwares, em ambas as extremidades.

Figura 23 - Esquema do modelo paralelo sem

compartilhamento

Hierrquico este modelo combina caractersticas do modelo de memria compartilhada, disco compartilhado e
com nenhum compartilhamento. Em um nvel superior, pode-se ter ns que no compartilham memria ou discos
entre si, trabalhando em um modelo sem nenhum compartilhamento, porm, cada n poderia ser um sistema de
memria compartilhada entre dois ou mais processadores. Ou seja, no nvel mais alto os ns so conectados por uma
rede, sem compartilhar recursos. E, no nvel mais baixo, cada n constitudo de sistemas de compartilhamento (vide
Figura 24).

Figura 24 - Esquema de modelo paralelo hierrquico

Arquitetura Mono-Usurio
Aqui, o banco de dados encontra-se no mesmo computador em que so executadas as aplicaes e no h mltiplos
usurios. Geralmente utilizada com computadores pessoais, no comeo esse processamento era bastante limitado,

27

porm, com a evoluo do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles utilizam o
padro Xbase e quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta maneira, possuem um
nico aplicativo a ser executado na mquina. A principal vantagem desta arquitetura a simplicidade.

Abstrao de Dados
Abstrair dados significa omitir a complexidade do sistema de modo a facilitar a interao dos usurios com ele. Como
um dos principais objetivos de um SGBD simplificar a interao do usurio com o sistema, ele deve prover uma viso
abstrata dos dados, ou seja, omitir detalhes de como os dados so armazenados e mantidos. Na verdade, uma das
caractersticas fundamentais da abordagem de banco de dados que ela fornece algum nvel de abstrao de dados,
pela omisso de detalhes de armazenamento de dados que no so necessrios para a maioria dos usurios. O
modelo de dados a principal ferramenta que fornece esta abstrao.
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 restries pertinentes aos
dados. Muitos modelos de dados tambm definem um conjunto de operaes para especificar como recuperar e
modificar a base de dados.
Em qualquer modelo de dados importante distinguir entre a descrio do banco de dados e o banco de dados
propriamente dito. A descrio 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 mudanas no grande. A
forma de visualizao de um esquema chamada Diagrama do Esquema. Muitos modelos de dados tm certas
convenes para, diagramaticamente, mostrar esquemas especificados no modelo.
Os dados existentes em um banco de dados podem mudar com relativa frequncia. Os dados contidos em um banco
de dados em um momento especfico do tempo so chamados Instncias do Banco de Dados (ou Ocorrncias ou
Estados). A base-esquema algumas vezes chamada de Base-Intencional e uma instncia chamada de BaseExtensional do esquema.
Para prover abstrao um SGBD prov a definio de esquemas em trs nveis (vide Figura 25): o nvel de viso, o nvel
conceitual e o nvel fsico. Estes nveis facilitam a manuteno do sistema e a interao dos usurios com os sistemas.
Vamos detalhar mais cada um deles a seguir.

Figura 25 - Nveis de Abstrao providos por um SGBD

O nvel fsico tambm chamado nvel interno, possui um esquema interno que descreve como os dados esto de
fato armazenados no(s) disco(s) rgido(s) (ex: formato dos registros, ordem em que aparecem, etc). Ou seja, descreve a
estrutura de armazenamento fsico dos dados do BD, fornecendo um modelo fsico dos dados que inclui detalhes
sobre os caminhos de acesso aos dados internamente. Os desenvolvedores de Banco de Dados devem ter noo desse

28

nvel.
O nvel conceitual tambm chamado nvel lgico, um nvel mdio de abstrao e possui um esquema conceitual
que descreve quais dados esto armazenados no banco de dados e quais so os interrelacionamentos entre eles. Ou
seja, descreve a estrutura de todo o BD para uma determinada comunidade de usurios, ocultando detalhes sobre a
organizao fsica dos dados e apresentando a descrio lgica dos dados e das ligaes existentes entre eles. Esse
esquema se concentra na descrio de entidades, tipos de dados, relacionamentos e restries. a viso dos
administradores de banco de dados e dos programadores.
O nvel de viso tambm chamado nvel externo, possui esquemas externos ou vises dos usurios. Ele o mais
alto nvel de abstrao. Cada esquema externo descreve a viso do banco de dados de um grupo de usurios deste
banco. Cada viso descreve, tipicamente, a parte do banco de dados que um grupo particular de usurios est
interessado e esconde deste o restante do banco de dados. Ou seja, vai existir uma viso diferente para cada grupo de
usurios finais. Ele descreve apenas parte do BD, pois os usurios normalmente no precisam conhecer todo o banco,
eles acabam utilizando apenas parte dele.
Essa diviso em nveis conhecida como arquitetura Three-Schema (tambm conhecida como arquitetura
ANSI/SPARC) e foi proposta por Tsichritzis & Klug em 1978. A meta desta arquitetura separar as aplicaes de
usurios do banco de dados fsico (meio que deixar cada macaco no seu galho)
Como os trs nveis apresentam descries diferentes para os mesmos dados, torna-se necessrio converter uma
representao em outra, ou seja, definir mapeamentos de dados entre os nveis.
Esses mapeamentos so mantidos pelo DBA.
Muitos SGBDs no separam os trs nveis completamente. Pode acontecer que alguns SGBDs incluam detalhes do nvel
interno no esquema conceitual. Em muitos SGBDs que permitem vises, os esquemas externos so especificados com
o mesmo modelo de dados usado no nvel conceitual.
Estes trs nveis podem ser utilizados para explicar conceitos de independncia de dados. Mas o que independncia
de dados? Independncia de dados se refere imunidade de aplicativos dos usurios a mudanas na definio e na
organizao de dados, e vice-versa. Em outras palavras, ela pode ser definida como a capacidade de alterar o esquema
de um nvel de abstrao sem ter que alterar o esquema do prximo nvel superior. Voc s vai ter ideia da
importncia disso quando comear realmente a manipular um banco de dados!
Pode-se dividir a independncia de dados em dois tipos: a independncia de dados lgica e a independncia de dados
fsica.
A independncia de dados lgica a capacidade de alterar o esquema conceitual sem ter que mudar os esquemas
externos (nvel de viso) ou programas de aplicao que fazem uso do banco de dados. Pode-se mudar o esquema
conceitual para expandir o banco de dados, com a adio 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 no foram alterados) no devem ser afetados. Assim possvel modificar a organizao
conceitual com impacto mnimo nas aplicaes (construdas sobre os esquemas externos ou vises).
A independncia de dados fsica a capacidade de alterar o esquema interno (nvel fsico) sem ter que alterar o
esquema conceitual (nvel lgico). Mudanas no esquema interno podem ser necessrias devido a alguma
reorganizao de arquivos fsicos para melhorar o desempenho nas recuperaes e/ou modificaes. Aps a
reorganizao, se nenhum dado foi adicionado ou perdido, no haver necessidade de modificar o esquema
conceitual. Em outras palavras, a independncia de dados fsica lida com a ocultao dos detalhes da estrutura de
armazenamento em relao aos aplicativos do usurio, ou seja, quando um aplicativo escrito, ele no deve se
preocupar com os detalhes da organizao fsica dos dados. Assim, possvel modificar as estruturas de
armazenamento sem impactar nas aplicaes que fazem uso do BD.

29