Banco de Dados

Prévia do material em texto

Prof. Me. Edson Yanaga
BANCO DE DADOS
grADuAçãO
ANáliSE E DESENvOlvimENtO DE SiStEmAS
SiStEmAS pArA iNtErNEt
mAriNgá-pr
2012
reitor: Wilson de Matos Silva
vice-reitor: Wilson de Matos Silva Filho
pró-reitor de Administração: Wilson de Matos Silva Filho
presidente da mantenedora: Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Diretoria do NEAD: Willian Victor Kendrick de Matos Silva
Coordenação pedagógica: Gislene Miotto Catolino Raymundo
Coordenação de marketing: Bruno Jorge
Coordenação Comercial: Helder Machado
Coordenação de tecnologia: Fabrício Ricardo Lazilha
Coordenação de Curso: Danillo Xavier Saes
Supervisora do Núcleo de produção de materiais: Nalva Aparecida da Rosa Moura
Capa e Editoração: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, José Jhonny Coelho, Luiz 
Fernando Rokubuiti e Thayla Daiany Guimarães Cripaldi
Supervisão de materiais: Nádila de Almeida Toledo 
revisão textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janaína Bicudo Kikuchi, Jaquelina 
Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalográfica elaborada pela Biblioteca Central - CESUMAR
 
 
 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação
 a distância:
C397 Banco de dados / Edson Yanaga. Maringá - PR, 2012.
 143 p.
 “Graduação em Análise e Desenvolvimento de Sistemas e 
 Sistemas para Internet - EaD”.
 
 1. Banco de dados. 2. Arquitetura de sistemas. 3.EaD. I. Título.
 CDD - 22 ed. 005.74 
 CIP - NBR 12899 - AACR/2
 
“As imagens utilizadas neste livro foram obtidas a partir dos sites pHOtOS.COm e SHuttErStOCK.COm”.
Av. Guedner, 1610 - Jd. Aclimação - (44) 3027-6360 - CEP 87050-390 - Maringá - Paraná - www.cesumar.br
NEAD - Núcleo de Educação a Distância - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br
BANCO DE DADOS
Prof. Me. Edson Yanaga
5BANCO DE DADOS | Educação a Distância
AprESENtAçãO DO rEitOr
Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos. 
A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para 
liderança e solução de problemas com eficiência tornou-se uma questão de sobrevivência no 
mundo do trabalho.
Cada um de nós tem uma grande responsabilidade: as escolhas que fizermos por nós e pelos 
nossos fará grande diferença no futuro.
Com essa visão, o Cesumar – Centro Universitário de Maringá – assume o compromisso 
de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos 
brasileiros.
No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas 
do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento 
de uma sociedade justa e solidária” –, o Cesumar busca a integração do ensino-pesquisa-ex-
tensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que 
contribua para o desenvolvimento da consciência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e a integração com a sociedade.
Diante disso, o Cesumar almeja ser reconhecido como uma instituição universitária de referên-
cia regional e nacional pela qualidade e compromisso do corpo docente; aquisição de compe-
tências institucionais para o desenvolvimento de linhas de pesquisa; consolidação da extensão 
universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação 
da comunidade interna; qualidade da gestão acadêmica e administrativa; compromisso social 
de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também 
pelo compromisso e relacionamento permanente com os egressos, incentivando a educação 
continuada.
Professor Wilson de Matos Silva
Reitor
6 BANCO DE DADOS | Educação a Distância
Caro(a) aluno(a), “ensinar não é transferir conhecimento, mas criar as possibilidades para a 
sua produção ou a sua construção” (FREIRE, 1996, p. 25). Tenho a certeza de que no Núcleo 
de Educação a Distância do Cesumar, você terá à sua disposição todas as condições para se 
fazer um competente profissional e, assim, colaborar efetivamente para o desenvolvimento da 
realidade social em que está inserido.
Todas as atividades de estudo presentes neste material foram desenvolvidas para atender o 
seu processo de formação e contemplam as diretrizes curriculares dos cursos de graduação, 
determinadas pelo Ministério da Educação (MEC). Desta forma, buscando atender essas 
necessidades, dispomos de uma equipe de profissionais multidisciplinares para que, 
independente da distância geográfica que você esteja, possamos interagir e, assim, fazer-se 
presentes no seu processo de ensino-aprendizagem-conhecimento.
Neste sentido, por meio de um modelo pedagógico interativo, possibilitamos que, efetivamente, 
você construa e amplie a sua rede de conhecimentos. Essa interatividade será vivenciada 
especialmente no ambiente virtual de aprendizagem – AVA – no qual disponibilizamos, além do 
material produzido em linguagem dialógica, aulas sobre os conteúdos abordados, atividades de 
estudo, enfim, um mundo de linguagens diferenciadas e ricas de possibilidades efetivas para 
a sua aprendizagem. Assim sendo, todas as atividades de ensino, disponibilizadas para o seu 
processo de formação, têm por intuito possibilitar o desenvolvimento de novas competências 
necessárias para que você se aproprie do conhecimento de forma colaborativa.
Portanto, recomendo que durante a realização de seu curso, você procure interagir com os 
textos, fazer anotações, responder às atividades de autoestudo, participar ativamente dos 
fóruns, ver as indicações de leitura e realizar novas pesquisas sobre os assuntos tratados, 
pois tais atividades lhe possibilitarão organizar o seu processo educativo e, assim, superar os 
desafios na construção de conhecimentos. Para finalizar essa mensagem de boas-vindas, lhe 
estendo o convite para que caminhe conosco na Comunidade do Conhecimento e vivencie 
a oportunidade de constituir-se sujeito do seu processo de aprendizagem e membro de uma 
comunidade mais universal e igualitária.
Um grande abraço e ótimos momentos de construção de aprendizagem!
Professora Gislene Miotto Catolino Raymundo
Coordenadora Pedagógica do NEAD- CESUMAR
7BANCO DE DADOS | Educação a Distância
AprESENtAçãO
livro: BANCO DE DADOS
Professor Me. Edson Yanaga
Salve, caríssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco 
de Dados, elaborado especificamente para contribuir na sua formação de futuro(a) 
desenvolvedor(a) de software. Sou o Professor Edson Yanaga, autor deste livro. Espero que 
você tenha um bom proveito do material.
Permita-me apresentar-me adequadamente: sou Bacharel em Ciência da Computação pela 
Universidade Estadual de Maringá (UEM) e Mestre em Engenharia Elétrica e Informática 
Industrial pela Universidade Tecnológica Federal do Paraná (UTFPR) na área de Telemática. 
Sou empresário (consultor e desenvolvedor) na área de software e trabalho com a plataforma 
Java desde 1997 – completando 15 anos de experiência neste ano de 2012. Trabalho também 
como administrador de sistemas Unix (Solaris, HP-UX e Linux) desde 2000, e desde 2008 
já era adepto e entusiasta da computação em nuvem (cloud computing). Participo de vários 
cursos em nível de especialização em diversas instituições, como Cesumar, UEM, UNIPAR 
e Faculdade Integrado; e sou coordenador do curso de Especialização em Desenvolvimento 
Orientado a Objetos em Java do Cesumar desde 2004. Possuo as seguintes certificações: 
Oracle Certified Professional, Java Platform, Enterprise Edition 6 Enterprise JavaBeans 
Developer; Certified ScrumMaster; Sun Certified Developer for Java Web Services 5; Sun 
Certified Specialist for NetBeans IDE; Sun Certified Web Component Developerfor J2EE 1.4; 
e Sun Certified Programmer for Java 2 Platform 1.4. Como líder do Redfoot JUG (Java Users 
Group) – Grupo de Usuário Java do Norte do Paraná – atuo desde 2004. Tive o prazer de ser 
membro do comitê técnico do JavaOne Latin America nas edições de 2010 e 2011. Apresento 
palestras em diversos eventos em nível nacional e internacional, e ultimamente sou um grande 
entusiasta do Artesanato de Software e do código bem-feito.
Confesso que foi um tremendo desafio escrever este material. Até certo ponto é uma repetição 
cansativa dizer que o ritmo das mudanças e inovações cada vez mais se acelera, mas a 
princípio o tema “banco de dados” aparentaria ser algo tranquilo pelo fato de ser uma área 
do conhecimento bastante consolidada. Ledo engano. Nos últimos cinco anos, a disciplina 
de banco de dados passou por profundas transformações que chacoalharam os alicerces 
de fundamentos criados e utilizados desde a década de 1970. Os desafios dos sistemas de 
8 BANCO DE DADOS | Educação a Distância
informação atuais exigem que manipulemos não gigabytes ou terabytes de informações, e sim 
petabytes, exabytes e zetabytes.
Sistemas de informação das gerações anteriores tinham como objetivo gerar informações que 
pudessem agregar valor aos processos de negócios. Pois bem, esse objetivo foi alcançado. 
Com a tão aguardada e estimulada onipresença de software, a magnitude destas informações 
geradas cresceu. Redes sociais, smartphones, tablets, sensores de automação e vários outros 
dispositivos geram inúmeros bits de informação a todo momento. Conceitos antigos já não são 
soberanos nesses ambientes inóspitos atuais. Diante destes cenários surgiram os conceitos 
de Big Data e NoSQl.
Mas para irmos longe e chegarmos a este ponto, devemos dar o primeiro passo. Este material 
aborda os conceitos que até recentemente eram considerados como as “regras sagradas” de 
banco de dados: os bancos de dados relacionais. E não se engane, caro(a) leitor(a), estes 
fundamentos de bancos de dados relacionais são imprescindíveis para que se possa dar o 
“próximo passo” rumo ao conhecimento de Big Data e NoSQL.
Na Unidade I teremos a apresentação de tópicos conceituais e definições sobre bancos de 
dados, sistemas gerenciadores de bancos de dados e os tipos de usuários que interagem com 
esses sistemas. Teremos também uma breve explanação sobre o conceito de transações, 
que é uma ferramenta essencial no desenvolvimento de aplicações mais tradicionais como 
aquelas que envolvem dados financeiros. Como leitura complementar, temos um texto de 
Cezar Taurion (Evangelista Técnico da IBM) falando sobre Big Data. Afinal, é importante 
darmos um passo no presente – mas sempre com um olho no futuro. Essa será a tônica das 
nossas leituras complementares e sugestões de vídeos: apresentar-lhe sempre os conceitos 
de vanguarda que já são aplicados em muitos casos de uso em aplicações modernas.
A Unidade II descreverá a terminologia e outros conceitos básicos que serão utilizados no 
restante deste material, tais como a diferenciação entre schemas e instâncias de dados; bem 
como a arquitetura de sistemas de banco de dados. Conhecer a arquitetura permitirá que você, 
como desenvolvedor(a) de software, possa explorar melhor os recursos do seu sistema de 
banco de dados – além de auxiliá-lo(a) na escolha dos diferentes tipos de produtos existentes 
e também dos produtos concorrentes em cada tipo ofertado.
O modelo relacional de banco de dados propriamente dito será abordado na Unidade III. A 
9BANCO DE DADOS | Educação a Distância
partir deste ponto você estará apto a identificar as características de modelos relacionais e 
passar a construir seus próprios modelos de dados baseado nos fundamentos apresentados. 
Na modelagem relacional, você identificará entidades do seu domínio de negócios, suas 
restrições e os relacionamentos entre as diversas entidades modeladas.
Nas Unidades IV e V aprenderemos a linguagem SQL (Structured Query Language), que é uma 
ferramenta dominada por 10 em cada 10 desenvolvedores de software que utilizam sistemas de 
banco de dados. De conceito simples, acredito piamente que não será um problema para você, 
futuro(a) desenvolvedor(a) de software bem feito. Mas convém ressaltar que SQL possui uma 
natureza declarativa, que é diferente das linguagens imperativas como Java, C ou Pascal 
com as quais você provavelmente está acostumado(a). Após sua criação, a SQL tornou-se um 
padrão de facto para manipular informações em sistemas de banco de dados por meio de seus 
comandos para inserção, atualização, remoção e consulta de instâncias de dados.
E antes que você possa apreciar o conteúdo do material, permita-me apresentar meu ponto de 
vista para reflexão: em muitas empresas o sistema de banco de dados tornou-se o repositório 
“sagrado” das informações, trancado a sete chaves e reservado ao guardião denominado de 
DBA (DataBase Administrator). Aliás, é bastante comum que os alunos aprendam ou venham 
a concluir que o banco de dados é o coração de um sistema de informação – baseados 
nessas falsas impressões transmitidas até certo ponto em grande quantidade. Para mim e 
também para muitos autores renomados do mundo do software, o banco de dados é apenas 
uma ferramenta utilizada na construção de nossos sistemas de informação. E como toda 
e qualquer ferramenta, não pode ficar acima do próprio código que atende ao processo de 
negócios da empresa. Isso diminui sua importância? Certamente que não! Mas quando 
modelar seu sistema de informação, pense primeiro no seu modelo de negócios e postergue 
até o último momento a sua visão sobre o banco de dados. Tenho certeza de que isso tornará 
a sua aplicação muito melhor projetada e permitirá que ela ofereça um retorno muito melhor 
ao seu negócio.
O banco de dados é só um detalhe. Um detalhe importante, mas o considere um detalhe. 
O coração da sua aplicação é o código bem feito que você elaborará para atender ao seu 
negócio. Pense nisso, e a cada batida desse coração você poderá usufruir de muito retorno (e 
muito dinheiro, espero).
Um bom proveito e uma ótima leitura.
Prof. Me. Edson Yanaga
SumáriO
uNiDADE i
CONCEITOS DE BANCOS DE DADOS
CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE DADOS ............................................20
TRANSAÇÕES ........................................................................................................................27
VANTAGENS DE SE UTILIZAR UM SGBD ............................................................................31
uNiDADE ii
OS BANCOS DE DADOS E O SOFTWARE
SCHEMAS, INSTÂNCIAS E ABSTRAÇÕES ..........................................................................42
INTERFACES DOS SGBDS ....................................................................................................43
ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS ...................................................46
MODELO CENTRALIZADO ....................................................................................................47
CLASSIFICAÇÃO DOS SISTEMAS DE BANCO DE DADOS ................................................56
uNiDADE iii
O MODELO RELACIONAL
CONCEITUAÇÃO ....................................................................................................................68
RESTRIÇÕES DO MODELO RELACIONAL ..........................................................................71
uNiDADE iv
SQL BáSICO
DEFINIÇÕES DE DADOS E TIPOS EM SQL .........................................................................93
RESTRIÇÕES .........................................................................................................................97
CONSULTAS BáSICAS EM SQL ............................................................................................99
COMANDOS DE MODIFICAÇÃO DE DADOS EM SQL .......................................................104uNiDADE v
MAIS SQL
CONSULTAS ENVOLVENDO NULL ..................................................................................... 118
CONSULTAS UTILIZANDO JOINS .......................................................................................124
CONSULTAS COM FUNÇÕES DE AGREGAÇÃO ...............................................................126
COMANDOS DE ALTERAÇÃO DE SCHEMA ......................................................................128
CONCluSãO ........................................................................................................................ 141
rEFErÊNCiAS .....................................................................................................................143
uNiDADE i
CONCEitOS DE BANCOS DE DADOS
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
•	 Apresentar	os	conceitos	fundamentais	envolvendo	dados	e	bancos	de	dados	em	
sistemas computacionais.
•	 Descrever	as	formas	interação	dos	usuários	com	os	bancos	de	dados.
•	 Comparar	as	vantagens	desta	abordagem	em	relação	a	outras	similares.
plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
•	 Conceituar	bancos	de	dados,	sistemas	gerenciadores	de	banco	de	dados	e	
sistemas de banco de dados
•	 Apresentar	as	principais	características	de	sistemas	de	banco	de	dados
•	 Enumerar	alguns	papéis	de	usuários	envolvidos	na	interação	com	sistemas	
de bancos de dados
•	 Descrever	algumas	vantagens	na	utilização	de	sistemas	de	bancos	de	dados	
comparados a outras abordagens
15BANCO DE DADOS | Educação a Distância
iNtrODuçãO
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
“Scientia potentia est”: “Conhecimento é poder”.
Sim, caro(a) leitor(a), conhecimento é poder. Informação é poder. Na sociedade do século 
XXI, chamamos estas informações armazenadas em sistemas computacionais de dados. E 
temos informação em abundância. O desafio crescente dos próximos anos é encontrar formas 
eficientes de processar os dados que já temos e ainda criar para gerar conhecimento e, 
consequentemente, riqueza.
Nas últimas décadas, boa parte do software desenvolvido envolve além do processamento 
de informações: as informações de entrada e de saída do software (além de outras 
metainformações intermediárias) devem ser armazenadas em um mecanismo confiável, e que 
possibilite o acesso simples e rápido à leitura e escrita destas informações.
Há alguns anos, escrever sobre o tema “banco de dados” seria uma tarefa relativamente 
tranquila, pois muitos acreditavam tratar-se de um assunto absolutamente consolidado. 
Mas o nosso mundo está em constante mudança e os modelos de negócios que surgiram 
recentemente provocaram uma ruptura na forma de se pensar no armazenamento de 
informações em bancos de dados.
16 BANCO DE DADOS | Educação a Distância
Mas de onde vem este termo que conhecemos como “banco de dados”? Pois em inglês, o 
termo refere-se a databases, que numa tradução literal definiríamos como “base de dados”. Um 
bom palpite remete a uma visão generalizada de que as instituições denominadas de “bancos” 
guardam de modo bastante seguro o nosso dinheiro. Os “bancos de dados” seriam então 
ferramentas que guardariam nossas informações (dados) de modo também supostamente 
seguro e confiável.
Outra confusão bastante comum e plenamente justificada refere-se à diferença entre os termos 
“banco de dados” e os sistemas que o gerenciam. Segue uma definição segundo Navathe 
(2011, p.3):
Um banco de dados é uma coleção de dados relacionados. Os dados são fatos que 
podem ser gravados e que possuem um significado implícito. Por exemplo, considere 
nomes, números telefônicos e endereços de pessoas que você conhece. Esses dados 
podem ter sido escritos em uma agenda de telefones ou armazenados em um computador, 
por meio de programas como o Microsoft Access ou Excel. Essas informações são 
uma coleção de dados com um significado implícito, consequentemente, um banco de 
dados.
Nossos bancos de dados podem ser coleções de dados relacionados dos mais diversos 
tamanhos. Desde uma pequena agenda contendo números e contatos de pessoas até um 
índice gigantesco de páginas de Internet e buscas relacionadas ou todas as mensagens e 
informações trocadas entre bilhões de usuários de uma rede social.
Em termos computacionais, há uma categoria de software especializado que é desenvolvido 
especificamente com o propósito de se gerenciar estas coleções de dados: os sistemas 
gerenciadores de banco de dados – popularmente reconhecidos pela sigla SGBD (ou DBMS 
– DataBase Management Systems, na sigla original em inglês). Segue mais uma definição de 
Navathe (2011, p.3), sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) é uma coleção de programas 
que permite aos usuários criar e manter um banco de dados. O SGBD é, portanto, 
um sistema de software de propósito geral que facilita os processos de definição, 
construção, manipulação e compartilhamento de bancos de dados entre vários usuários 
e aplicações. A definição de um banco de dados implica especificar os tipos de dados, 
17BANCO DE DADOS | Educação a Distância
as estruturas e as restriçõ es para os dados a serem armazenados em um banco de 
dados.
Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer sistemas de 
software, tal opção não se mostra viável. Relembrando o nosso conceito de que a importância 
do software consiste em sua capacidade de se gerar valor com as informações que manipula, 
tem-se que implementar nosso próprio mecanismo de manipulação de dados em nossas 
aplicações não gera valor: somente custo. É por este motivo que atualmente definimos os 
SGBDs numa categoria de software que consideramos como commodity.
Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem Oracle, DB2, SQL 
Server, Access, PostgreSQL, MySQL, Derby e H2. Já exemplos de SGBDs não relacionais 
(também conhecidos como NoSQL) incluem MongoDB, Redis, Neo4j e Riak.
Para propósitos de definição, finalizaremos denominando o conjunto formado pelo banco de 
dados e o sistema que o gerencia, o SGBD, de sistema de banco de dados.
Bancos de dados Open Source: presente ou futuro?
Cezar Taurion
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de dados Open 
Source. Bem, tenho minha opinião pessoal e quero compartilhar com vocês. Vamos ver se vai gerar 
muita discordância...
18 BANCO DE DADOS | Educação a Distância
Os softwares de banco de dados são um dos mais importantes componentes de software de uma 
organização. Neste ambiente as alternativas de software livre já são bastante conhecidas e freqüente-
mente são mencionadas na mídia, como MySQL, PostgreSQL, Ingres e Derby. 
O MySQL é um produto de uma empresa privada, a MySQL AB. Seu código é desenvolvido pelos 
funcionários da empresa e com isso ela garante a propriedade intelectual sobre o produto. Existe uma 
comunidade envolvida, mas submissões de código são restritas apenas à correção de bugs. Uma 
pergunta: o MySQL pode ser considerado realmente Open Source, uma vez que não adota o modelo 
de desenvolvimento colaborativo? O MySQL é ofertado tanto em GPL como sob licença comercial. 
As duas versões são funcionalmente equivalentes, sendo diferenciadas pelo nível de suporte e cer-
tificação.	Indiscutivelmente	é	o	banco	de	dados	Open	Source	mais	popular,	com	o	maior	mindshare	
do setor.
Outro software é o PostgreSQL, que tem suas origens no Postgres desenvolvido pela Universidade 
de Berkeley. Podemos citar também o Ingres, que foi um banco de dados da Computer Associates e 
agora pertence a uma organização independente, a Ingres Corporation (www.ingres.com) e o Derby, 
originalmente o Cloudscape da IBM e recentemente doado para a Apache Software Foundation, onde 
agora é o projetoDerby. O Derby (http://db.apache.org/derby/) é um banco de dados em Java, geral-
mente embarcado em outros softwares. A IBM, por exemplo, o utiliza embutido em diversos softwares 
das famílias WebSphere, Tivoli e Lotus. 
Nas minhas andanças pelo mercado tenho visto que na prática os bancos de dados Open Source só 
aparecem	como	competidores	dos	produtos	mais	avançados	nas	aplicações	pouco	sofisticadas	ou	
bem	especificas.	
Por sua vez, os sistemas de banco de dados proprietários buscam competir com funcionalidades di-
ferenciadoras, principalmente as relacionadas com administração de ambientes complexos; escalabi-
lidade; desempenho com grande volume de transações; alta disponibilidade e capacidade de recupe-
ração rápida; e recursos de data warehousing. Além disso, foi criado um ecossistema de negócios em 
torno dos principais software de banco de dados proprietários, com diversas empresas independentes 
oferecendo ferramentas de software complementares (geradores de relatórios, analisadores estatís-
ticos e outros), serviços de suporte técnico especializado e formação de recursos humanos, e assim 
por diante, o que também cria uma barreira de entrada difícil de transpor por qualquer novo entrante. 
Já o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde se gera di-
nheiro) ainda é incipiente, sendo formado por pequenas empresas com abrangência de atuação bas-
tante limitada. Ano passado, a MySQL gerou cerca de 50 milhões de dólares em receita (http://news.
com.com/MySQL+hits+50+million+revenue,+plans+IPO/2100-7344_3-6179290.html), mas ainda é 
um	traço	(cerca	de	0,03%)	no	gráfico	que	mostra	o	mercado	global	de	bancos	de	dados	relacionais,	
estimado pelo IDC em 16 bilhões de dólares. Como comparativo, o IDC estima que neste mesmo ano, 
19BANCO DE DADOS | Educação a Distância
a receita da IBM com a família de produtos DB2 foi de aproximadamente 3,5 bilhões de dólares.
Qual o papel que os bancos de dados Open Source desempenharão? Na minha opinião estarão 
atuando (pelo menos nos próximos 3 a 4 anos) na chamada faixa de produtos com funcionalidades 
comoditizadas, onde as características de preço são as de maior importância. Os usuários típicos 
serão	organizações	e	aplicações	que	não	precisam	de	recursos	mais	sofisticados.	
Como avaliar a qualidade de um banco de dados Open Source? Existem diversos critérios que podem 
e devem ser considerados em uma análise para seleção de um banco de dados. Os níveis de impor-
tância das variáveis da análise estão diretamente relacionadas com os objetivos do negócio e das 
necessidades a serem impostas aos softwares de bancos de dados.
Alguns dos principais fatores a serem considerados são:
a) Recursos de gerenciamento e administração. São as ferramentas de apoio às tarefas do admi-
nistrador do banco de dados.
b) Desempenho e escalabilidade. Os recursos que o software oferece para garantir desempenho 
adequado, nos volumes de transações que serão demandados.
c) Recursos técnicos. Disponibilidade de recursos como triggers, stored procedures, cursors, sub-
queries, capacidade de replicação, recursos de indexação, aderência a padrões (ANSI SQL), par-
ticionamento, backup/recovery, suporte a dados não estruturados, independência de plataforma 
e recursos de segurança.
d) Custos de Propriedade.
e) Suporte técnico e disponibilidade de recursos humanos. Abrangência do ecossistema em termos 
de	serviços	de	suporte	e	qualificação	de	recursos	humanos.
f) Disponibilidade de aplicativos.
g) Recursos de data warehousing e BI.
h) Recursos de desenvolvimento de aplicações.
i) Modalidade de licenciamento.
j) Visão, estratégia e road map do produto.
k) Tamanho e participação/envolvimento da comunidade.
l) Modelo de governança adotado pela comunidade.
m) Base instalada e adoção pelo mercado.
Bem e quanto a uma pergunta que muitos me fazem... Minha empresa deve adotar um banco de da-
dos Open Source? Para mim, para mudar um software de banco de dados deve haver uma estratégia 
impulsionada	por	 razões	 fortes	e	consistentes.	Por	exemplo,	se	houver	desconfianças	que	o	atual	
fornecedor esteja saindo do mercado; falta de funcionalidade do software (não é mais adequado às 
20 BANCO DE DADOS | Educação a Distância
necessidades das novas aplicações da empresa); falta de visão estratégica por parte do fornecedor 
do software atual; custos de manutenção e operação muito elevados para o resultado obtido; falta de 
pessoal gabaritado, que esteja disponível no mercado; carência de consultorias e serviços de suporte 
externos; relacionamento com o fornecedor cada vez mais deteriorado... Mudar para um banco de 
dados Open Source simplesmente por questões ideológicas deve estar fora de cogitação, pois banco 
de dados é muito sério para ser tratado de forma simplista.
OK, e quais seriam então os custos e riscos da migração? Existem custos de migração que não po-
dem	ser	subestimados.	Temos	os	custos	da	conversão	de	dados,	custos	da	codifi	cação,	testes,	e	o	
que chamamos reconciliação entre as aplicações no novo e no antigo ambiente, sempre considerando 
que	difi	cilmente	conseguiremos	fazer	uma	migração	estilo	big	bang,	mas	que	esta	será	gradual.
Quanto mais complexas forem as aplicações a serem convertidas, mais custosa será a migração. Esta 
complexidade pode ser medida pelo número de programas, número de tabelas relacionais, restrições 
de integridade referencial e tamanho do banco de dados. Existem custos indiretos como a construção 
de interfaces entre as aplicações já convertidas e as que ainda estão no banco de dados antigo. Tam-
bém os custos de suporte técnicos aos dois ambientes implicam muitas vezes, em gastos adicionais 
elevados, principalmente quando o novo banco de dados não for de completo domínio da equipe 
técnica da empresa. 
Em resumo, os custos da migração afetam os cálculos de custos totais de propriedade. A maioria das 
empresas é extremamente cautelosa em trocar de fornecedor de softwares críticos. O perigo de uma 
interrupção nos seus negócios decorrente de uma troca mal planejada ou inadequada faz com que 
os custos de troca possam ser extremamente elevados e desestimuladores. Migrar de um banco de 
dados para outro é sempre uma tarefa complexa e de alto risco, que só deve ser efetuada quando os 
benefícios forem claramente demonstráveis.
Fonte: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/bancos_de_da-
dos_open_source?lang=pt_br>. Acesso em: 14 ago. 2012.
CArACtErÍStiCAS DE SiStEmAS DE BANCOS DE DADOS
Se utilizar um sistema de banco de dados parece uma solução natural, qual seria a outra 
solução alternativa? Pense em algumas aplicações que você utiliza e que não fazem uso de 
SGBDs. Processadores de texto, planilhas, ferramentas de desenho etc., são alguns exemplos 
21BANCO DE DADOS | Educação a Distância
dessas aplicações. O que todas têm em comum? A necessidade de se armazenar a informação 
manipulada por meio de arquivos.
Em qualquer aplicação que necessite do armazenamento de dados, faz-se necessário dispor de 
algum mecanismo que permita que estes sejam gravados de modo persistente. A abordagem 
de arquivos tem suas vantagens, como por exemplo, a portabilidade dos dados. Você pode 
carregá-los eletronicamente ou fisicamente para locais diferentes de modo bastante simples. 
Mas entre as desvantagens desta abordagem há todo o trabalho necessário para se criar um 
formato e processar a sua gravação e recuperação – e acredite, não é pouco trabalho!
Um SGBD, por outro lado, já dispõe de uma série de funcionalidades prontas para serem 
utilizadas pelo desenvolvedor da aplicação. Deste modo, uma série de preocupações passa 
a ser delegada a um software de terceiros (o SGBD). A seguir, apresentaremos uma série de 
características que diferenciam a abordagem de sistemas de banco de dados da manipulação 
manual das informações (como em arquivos, por exemplo).
Naturezaautodescritiva
Uma característica fundamental que distingue os sistemas de bancos de dados de outras 
abordagens é o fato de que nos SGBDs, o banco de dados e as metainformações sobre 
o banco de dados são armazenados conjuntamente. Essas metainformações armazenadas 
contêm informações como o tipo, tamanho e restrições do banco de dados. Em termos 
técnicos, as metainformações são chamadas de esquema (ou schema, em seu termo original 
em inglês).
isolamento entre programa e Dados
Numa aplicação que utilize arquivos para o armazenamento de dados, quaisquer alterações na 
estrutura do arquivo também implicarão em alterações no programa. Nesse caso, dizemos que 
o programa é altamente acoplado à sua estrutura de armazenamento de dados. Em contraste, 
SBGDs permitem que o programa somente informe quais dados são armazenados, sem se 
22 BANCO DE DADOS | Educação a Distância
importar em como esses dados serão manipulados internamente. Esta característica aumenta 
bastante o nível de manutenibilidade do sistema, quando bem aplicada.
múltiplas visões dos dados
Esta não é uma característica fundamental, mas muitos SGBDs fornecem a possibilidade de 
que diferentes usuários com diferentes permissões possam acessar diferentes “visões” dos 
dados. Essas visões (views) correspondem a estruturas virtuais criadas a partir dos dados 
armazenados e podem conter, além dos próprios dados, também informações derivadas 
(calculadas) a partir desses dados.
A criação de diferentes usuários com diferentes permissões a visões específicas é uma 
abordagem muito utilizada em sistemas cliente/servidor; ou na integração de aplicações 
mediante banco de dados. O auge do uso destas abordagens deu-se no final da década 
de 1990, embora ainda hoje seja possível testemunhar aplicações sendo executadas sob 
este modelo. Recomenda-se fortemente que no desenvolvimento de novas aplicações, a 
abordagem de múltiplas visões e de integração mediante banco de dados seja substituída 
por uma abordagem orientada a serviços como SOA (Service Oriented Architecture) ou como 
REST (REpresentational State Transfer).
Visões não são uma má prática. São um recurso bastante útil, mas não imprescindível. Como 
toda ferramenta, bem utilizada e de modo adequada, é um recurso valioso.
Acesso	concorrente	de	múltiplos	usuários
Um SGBD multiusuário, como o próprio nome já define, deve permitir o acesso de múltiplos 
usuários. Além disso, o acesso deve ser concorrente, permitindo que todos os usuários 
conectados executem operações “ao mesmo tempo”.
Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errônea na área 
de Tecnologia da Informação: “paralelo” e “concorrente”. Paralelismo puro é algo raro em 
23BANCO DE DADOS | Educação a Distância
computação, embora seja perfeitamente possível. Ao lidarmos com sistemas de banco de 
dados, utilizamos o termo “concorrente”, pois vários usuários têm a impressão de que estão 
executando instruções ao mesmo tempo – quando na verdade, por se tratar de informações 
acessadas em disco ou com um único barramento de acesso, torna-se necessário algum 
mecanismo de contenção que serialize (coloque em fila) cada uma dessas instruções. 
Como idealmente a execução dessas instruções é bastante curta, tem-se a impressão do 
pseudoparalelismo.
Um conceito fundamental para que o acesso destes múltiplos usuários mantenha o banco de 
dados num estado consistente é o mecanismo de transações, que será descrito na próxima 
seção.
A	revolução	do	Big	Data	está	prestes	a	acontecer
Cezar Taurion
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
O	termo	Big	Data	começa	a	despertar	muita	atenção,	mas	ainda	é	um	conceito	mal	defi	nido	e	com-
preendido.	Com	uma	rápida	pesquisa	ao	Google,	identifi	quei,	pelo	menos,	uma	dúzia	de	defi	nições.	
Neste	artigo,	vou	falar	um	pouco	sobre	o	assunto	e	debater	alguns	desafi	os	que	temos	para	conseguir	
colocar projetos de Big Data em ação. 
24 BANCO DE DADOS | Educação a Distância
Sem	entrar	em	definições	e	nos	atendo	apenas	a	conceitos,	podemos	resumir	com	uma	fórmula	sim-
ples o que é Big Data: volume + variedade + velocidade de dados. Volume porque, além dos dados 
gerados pelos sistemas transacionais, temos a imensidão de dados gerados pelos objetos na Internet 
das Coisa, como sensores e câmeras, e os gerados nas mídias sociais, via PCs, smartphones e ta-
blets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos não estru-
turados,	como	fotos,	videos,	emails	e	tuítes.	E,	por	fim,	velocidade	porque,	muitas	vezes,	precisamos	
responder aos eventos quase que em tempo real. Ou seja, estamos falando de criação e tratamento 
de dados em volumes massivos.
Outro	desafio:	criar	e	 tratar	apenas	de	dados	históricos,	como	os	veteranos	Data	Warehouse	e	as	
tecnologias de BI (Business Intelligence) começam a se mostrar lentos demais para a velocidade com 
que os negócios precisam tomar decisões. Aliás, o termo BI já tem mais de 50 anos. Ele foi cunhado 
por Hans Peter Luhn, pesquisador da IBM em um artigo escrito nos idos de 1958.
Quando falamos em volume, os números são gigantescos. Se olharmos globalmente, estamos fa-
lando em zetabytes, ou 10²¹ bytes. Grandes corporações armazenam multiplos petabytes e mesmo 
as pequenas e médias empresas trabalham com dezenas de terabytes de dados. Este volume tende 
a crescer geométricamente. Em mundo cada vez mais competitivo e rápido, as empresas precisam 
tomar decisões baseadas não apenas em palpites, mas em dados concretos. Assim, para um setor de 
marketing faz todo sentido ter uma visão 360° de um cliente, olhando não apenas o que ele comprou 
da empresa, como registrado no ERP, mas saber o que ele pensa e diz sobre a empresa e como os 
faz - pelo Facebook e Twitter, por exemplo. 
Hoje, já é consenso que dados são os recursos naturais da nova Revolução Industrial. Na atual socie-
dade industrial, ter apenas recursos naturais, como minério, e exportá-los de forma bruta - importando 
em troca produtos manufaturados, não garante a competitividade de um país no longo prazo. O im-
portante	é	a	tecnologia	e	o	conhecimento	que	cria	produtos	manufaturados.	Afinal,	um	quilo	de	satélite	
vale imensamente mais do que um quilo de minério de ferro. 
Fazendo um paralelo, na sociedade da informação é crucial saber tratar os dados na velocidade 
adequada. Dados não tratados e analisados em tempo hábil são dados inúteis, pois não geram in-
formação. Dados passam a ser ativos corporativos importantes e como tal, podem - e deverão - ser 
quantificados	econômicamente.
Big	Data	 representa	um	desafio	 tecnológico,	 pois	 demanda	atenção	à	 infraestrutura	e	 tecnologias	
analíticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de com-
putação em nuvem, desde, é claro, que este imenso volume não seja transmitido repetidamente via 
Internet. Só para lembrar, os modelos de cobrança pelo uso de nuvens públicas tendem a gerar pro-
cessamentos muito baratos, mas tornam caro a transmissão de muitos dados. 
A principal base tecnológica para Big Data Analytics é o Hadoop e os bancos de dados NoSQL, onde 
25BANCO DE DADOS | Educação a Distância
“No”	significa	Not	Only	SQL,	ou	seja,	usa-se	bases	de	dados	SQL	e	não	SQL.	A	importância	do	“Not	
Only” SQL explica-se pelo fato do modelo relacional ser baseado na época de sua criação, no início 
dos anos 70. Nessa época, acessar, categorizar e normalizar dados era bem mais fácil do que hoje. 
Praticamente não existiam dados não estruturados circulando pelos computadores da época. Tam-
bém não foi desenhado para escala massiva, ou para um processamento muito rápido. Seu objetivo 
básico era possibilitar a criação de queries que acessacem bases de dados corporativas e, portanto, 
estruturadas. Para soluções Big Data, tornam-se necessárias varias tecnologias, desde bancos de 
dados SQL, a softwares que utilizemoutros modelos, que lidem melhor com documentos, grafos, 
processamento paralelo, etc.
A complexidade do Big Data vem à tona quando lembramos que não estamos falando apenas de 
armazenamento e tratamento analítico de volumes massivos de dados, mas de revisão, ou criação, 
de processos que garantam a qualidade destes dados e de processos de negócios que usufruam dos 
resultados obtidos. Portanto, Big Data não é apenas um debate sobre tecnologias, mas, principalmen-
te, sobre como os negócios poderão usufruir da montanha de dados que está agora à sua disposição. 
Aí emerge a questão da integração: como integrar bases de dados estruturadas e não estruturadas 
com diversos softwares envolvidos? 
O	Big	Data	abre	oportunidades	profissionais	bem	amplas.	Na	minha	opinião,	existe	espaço	para	dois	
perfis	profissionais:	um	mais	voltado	para	os	negócios	e	qualificados	para	 tratar	analiticamente	as	
informações geradas por estas imensas bases de dados e outro com viés mais técnico, ou Data 
Architect.
Pelo viés dos negócios, um artigo interessante que foi publicado há poucos meses pelo Wall Street 
Journal, na edição brasileira, aponta como problema a escassez de talentos. Ele fala que muitas 
empresas	americanas	começaram	a	procurar	profissionais	que	saibam	interpretar	os	números	usando	
a	análise	de	dados,	 também	conhecida	como	 inteligência	empresarial.	Mas	encontrar	profissionais	
qualificados	tem	se	mostrado	difícil.	O	resultado	foi	que	várias	faculdades	americanas,	como	a	Facul-
dade de Pós-Graduação em Administração da Universidade Fordham e a Faculdade de Administração 
Kelley, da Universidade de Indiana, começaram a oferecer disciplinas eletivas, cursos de extensão e 
mestrados em análise de dados. Já o Data Architect deve lidar com tecnologias SQL e NoSQL, conhe-
cer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto, 
ter capacidade de desenhar estratégias para manusear e analisar grandes volumes de dados de 
formatos diferentes, quase que em tempo real.
A idéia de stream processing, ou stream computing, é fantástica; é um novo paradigma. No modelo 
de	data	mining	tradicional,	uma	empresa	filtra	dados	dos	seus	vários	sistemas	e,	após	criar	um	data	
warehouse, dispara “queries”. Na prática, faz-se uma garimpagem em cima de dados estáticos, que 
não	refletem	o	momento,	mas	sim	o	contexto	de	horas,	dias	ou	mesmo	semanas	atrás.	Com	o	stream	
computing, esta garimpagem é efetuada em tempo real. Em vez de disparar queries em cima de uma 
26 BANCO DE DADOS | Educação a Distância
base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando 
um	conjunto	de	queries.	Podemos	pensar	em	inúmeras	aplicações,	sejam	estas	em	fi	nanças,	saúde	
e mesmo manufatura. 
Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de fabricação 
de	semicondutores	monitora	em	tempo	real	o	processo	de	deteção	e	classifi	cação	de	falhas.	Com	o	
stream computing, as falhas nos chips que estão sendo fabricados são detetadas em minutos e não 
em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda, 
pode-se fazer ajustes em tempo real nos próprios processos de fabricação.
Quanto ao EDA, pode-se começar a estudar o assunto acessando seu verbete na Wikipedia. 
O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Aliás, já aparece no canto da tela 
de um ou outro CIO, e, provavelmente, em alguns anos já será um dos temas mais prioritários das 
tradicionais listas de “tecnologias do ano”. Portanto, é bom estar atento à sua evolução e começar a 
colocar em prática algumas provas de conceito.
Fonte: <http://imasters.com.br/artigo/23437/banco-de-dados/a-revolucao-do-big-data-esta-prestes-a-
-acontecer>. Acesso em 15 jul. 2012.
O maior evento da comunidade brasileira de NoSQL:
<http://nosqlbr.com/>. 
27BANCO DE DADOS | Educação a Distância
trANSAçÕES
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
O conceito de transação é fundamental em muitas áreas da computação, e particularmente 
fundamental em sistemas de banco de dados. Consideramos como transação uma 
determinada “unidade de trabalho”, que é realizada em qualquer sistema computacional de 
um modo coerente e independente de outras transações. Estas transações devem permitir 
que o sistema esteja num estado coerente antes e depois de sua execução, independente de 
falhas ou outros problemas que possam ocorrer. Devem permitir também que vários clientes 
diferentes acessem concorrentemente o sistema sem que isso possa corromper ou levar a 
estados que não sejam considerados coerentes.
Uma definição clássica do conceito de transações envolve o acrônimo ACID, oriundo das 
propriedades de Atomicidade, Consistência, Isolamento e Durabilidade.
Atomicidade
A propriedade atomicidade de banco de dados advém do conceito de átomo da física – o qual 
até recentemente supunha-se indivisível. Essa indivisibilidade pressupõe que as operações 
realizadas numa transação sejam todas realizadas por completo; ou que nenhuma seja 
realizada. Popularmente seria o conceito do “tudo ou nada”. Isto permite que durante a nossa 
interação com um banco de dados, possamos agrupar vários comandos relacionados com 
28 BANCO DE DADOS | Educação a Distância
a garantia de que todos sejam executados – de modo que as informações armazenadas 
permaneçam num estado consistente após a execução da transação.
Consistência
A propriedade de consistência assegura que a execução de qualquer transação trará o 
banco de dados de um estado consistente para outro estado também consistente. No caso, 
a “consistência” implica que todos os dados de um banco de dados devem ser válidos de 
acordo com um conjunto de regras que podem incluir restrições de tipo, valor, referências entre 
informações etc.
isolamento
A propriedade de isolamento determina que o resultado da execução concorrente de um 
conjunto de transações terá o mesmo resultado de sua execução em série (uma após a outra).
O isolamento transacional é o que garante e permite o acesso concorrente de múltiplos 
usuários ao mesmo SGBD.
Durabilidade
A propriedade de durabilidade garante que uma vez que uma transação tenha sido finalizada 
com sucesso, os dados terão a garantia de terem sido armazenados corretamente – 
independentemente da eventualidade de falhas, falta de energia, erros de aplicação etc.
Na opinião deste autor, é justamente a propriedade de durabilidade que faz com que os 
bancos de dados sejam posicionados como “ferramentas sagradas” em muitas empresas. 
Novamente, não há menosprezo algum em dizer que o mais importante é o código que atende 
aos processos de negócios. Durabilidade é essencial: imagine qualquer empresa perdendo 
todos os seus dados. A continuidade do próprio negócio está em risco. Mas mais importante 
do que os dados em si está o uso que se faz deles.
29BANCO DE DADOS | Educação a Distância
Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas sempre tiveram como pre-
missa em seus dados sua corretitude (grau em que o software executa suas funções de modo correto). 
Isso normalmente implicou na utilização de um banco de dados que pudesse satisfazer as proprieda-
des ACID.
Com o aumento da quantidade de informações e usuários nas aplicações, o fator disponibilidade pas-
sou em alguns casos a ser mais importante do que a própria consistência das informações.
Além do ACID, surgiu o acrônimo BASE (Basically Available, Soft state, Eventually consistent) – tradu-
zido	literalmente	como	Basicamente	Disponível,	Estado	fl	exível	e	Eventualmente	consistente.	O	BASE	
tornou-se uma sigla bastante comum ao lidar com bancos de dados não relacionais.
Uma	refl	exão	que	vale	a	pena	ser	feita	é:	para	os	novos	desafi	os	e	empreitadas	que	vocês,	futuros	
profi	ssionais,	enfrentarão,	em	quais	situações	o	ACID	é	recomendado	e	em	quais	outras	situaçõeso	
BASE mostra-se mais adequado?
Referência: <http://queue.acm.org/detail.cfm?id=1394128>. Acesso em 15 jul. 2012.
30 BANCO DE DADOS | Educação a Distância
Papéis	assumidos	pelos	usuários	de	SGBDs
Desenvolvedores de SGBDs São	pessoas	que	projetam	e	codificam	os	SGBDs.	Exem-
plos de pessoas nestes papéis incluem os funcionários de 
empresas como Oracle, IBM e Microsoft que atuam dire-
tamente na programação do software SGBD. No caso de 
SBGDs livres, podem ser também voluntários ou pessoas 
e empresas interessadas na evolução do software. Nor-
malmente	são	programadores	altamente	qualificados	que	
trabalham no código-fonte do SBGD. Mas voluntários de 
projetos de software livre também podem contribuir em ou-
tras atividades como documentação, por exemplo.
Desenvolvedores de aplicações e 
Administradores de Bancos de Da-
dos (DBAs – DataBase Administra-
tors)
São pessoas que desenvolvem software que armazena 
as informações num SGBD. Tradicionalmente, em abor-
dagens mais tradicionais e conservadoras, as equipes de 
desenvolvimento são separadas em desenvolvedores e 
DBAs. Os primeiros desenvolvem o software que acessa 
o SGBD. Os segundos projetam os bancos de dados e os 
mantém. Em abordagens de desenvolvimento mais mo-
dernas tende-se a eliminar esta distinção entre os papéis, 
pois quanto maior a distância entre os membros da equi-
pe envolvidos no projeto de software, menor tende a ser a 
qualidade do software entregue.
Usuários	finais São pessoas que não interagem diretamente com os 
bancos de dados, e sim com as aplicações criadas pelos 
desenvolvedores de software que armazenam suas infor-
mações em SGBDs. A maioria das pessoas enquadra-se 
nesta	categoria,	e	embora	sejam	os	grandes	beneficiados	
pela tecnologia dos sistemas de bancos de dados, rara-
mente possuem ciência do fato.
31BANCO DE DADOS | Educação a Distância
<http://youtu.be/Car5V9l8BiQ>.
Klaus Wuestfeld – Prevayler
Neste vídeo Klaus Wuestfeld, um dos pioneiros do XP (eXtreme Programming) no Brasil e criador do 
conceito de prevalência de objetos, mostra uma abordagem inovadora e de alto desempenho para 
manipulação e persistência de objetos. Atualmente, alguns dos sistemas de transações mais rápidos 
do mundo utilizam este conceito.
vANtAgENS DE SE utiliZAr um SgBD
Durante as seções anteriores, já citamos algumas vantagens de se utilizar um SGBD para 
armazenar as informaçõ es de nossas aplicações. A seguir, as enumeraremos de um modo 
mais detalhado, de forma a justificar seu uso numa diversidade de situações.
Diminuir a redundância e fornecer consistência
Imagine uma situação bastante comum: você resolve elaborar um documento e necessita da 
colaboração de várias pessoas para fazê-lo. Você então cria o esboço deste documento e o 
envia por e-mail a todos os interessados. Cada pessoa realiza as suas modificações em suas 
próprias cópias dos documentos e depois repassa novamente por e-mail. Quem tem a última 
versão do documento? Quais são os dados corretos? Estas são perguntas difíceis de serem 
respondidas nesta abordagem, e provavelmente exigirá muito trabalho manual para se chegar 
à versão final do documento.
Um SGBD centraliza todas estas informações, fazendo com que todos os usuários acessem 
os mesmos dados. Desse modo, diminui-se a redundância: há somente uma cópia dos dados 
32 BANCO DE DADOS | Educação a Distância
a serem manipulados. Isto permite também que o banco de dados sempre permaneça num 
estado consistente, pois todos os usuários terão sempre a “última versão” dos dados. Não há 
a possibilidade de alguém permanecer com um “pedaço” dos dados antigos e outro “pedaço” 
com a informação atual.
Controle de acesso
Muitas informações armazenadas em sistemas são confidenciais. Ao mesmo tempo, é 
necessário que esta informação seja compartilhada com as pessoas para que sejam 
trabalhadas. Ao utilizar arquivos, é necessário que uma cópia seja enviada aos interessados. 
Por múltiplos motivos, essas cópias podem acabar sendo enviadas por e-mail a pessoas 
cujo acesso é indevido; ou a mesma pode ser deixada num dispositivo de armazenamento 
removível esquecido em alguma mesa de reunião.
No mínimo um SGBD oferece uma combinação de login/senha para acesso a um determinado 
banco de dados. Outras restrições relativas a qual usuário pode acessar quais dados também 
costumam ser implementadas pela maioria dos SBGDs. Como o acesso é centralizado, 
também tem-se uma única cópia para proteção.
Consultas eficientes
Como são aplicações de software de propósito específico, os SGBDs são especialmente 
projetados para armazenar eficientemente os dados a eles delegados; e para permitir formas 
de consulta eficientes aos mesmos dados. Cada SGBD possui sua estratégia interna para 
transformar estas informações em bytes gravados no dispositivo de armazenamento, mas de 
um modo geral, não há uma grande diferença de desempenho entre diferentes produtos em 
uma quantidade razoável de aplicações.
Em casos de usos típicos, é muito mais importante a eficiência em consultas do que a 
eficiência em armazenamento de informações. Assim, os SBGDs utilizam dispositivos como 
índices (que são estruturas criadas para otimizar consultas baseadas em certos critérios) e 
33BANCO DE DADOS | Educação a Distância
cachês (caches) para armazenar em memória os dados mais frequentemente acessados. 
Estes dispositivos permitem que as consultas possam ser executadas de modo mais rápido, e 
em muitos SGBDs, adequar estes dispositivos de modo otimizado chega a quase ser uma arte, 
tamanha a quantidade de opções disponíveis.
Backup e Restore
Para garantir a continuidade dos negócios, é essencial executar periodicamente o backup das 
informações armazenadas no servidor. Ao invés de cópias físicas dos arquivos do SGBD, é 
comum os próprios SGBDs fornecerem ferramentas que permitem a exportação dos dados 
para um formato intermediário (texto ou binário) para backup. Estas mesmas ferramentas 
suportam a restauração destes dados em caso de necessidade.
As rotinas de backup/restore também são uma ferramenta bastante útil na migração ou cópia 
de servidores onde o mesmo SGBD esteja instalado. Situações de migração costumam ocorrer 
em caso de falhas ou upgrade de equipamento. Cópias costumam ser utilizadas para permitir o 
teste de aplicações em desenvolvimento.
CONSiDErAçÕES FiNAiS
Nesta unidade, pudemos perceber que os bancos de dados são uma coleção de dados 
relacionados que representam, por meio de um nível determinado de abstração, o modelo 
do mundo real de nossas aplicações de software. Boa parte das aplicações de software 
desenvolvidas na atualidade envolve a manipulação, e principalmente, o armazenamento dos 
dados – estes muitas vezes em enormes quantidades. Para manipular estes bancos de dados, 
criou-se uma categoria de software específico denominada de sistemas gerenciadores de 
bancos de dados (SGBDs). O banco de dados (os dados) e o sistema que o gerencia são 
denominados conjuntamente de sistemas de bancos de dados.
Durante esta unidade também descrevemos as características que identificam as 
propriedades de sistemas de bancos de dados quando comparados a abordagens tradicionais 
de processamento de arquivos. Certamente que determinados casos de uso ainda exigem 
a utilização de arquivos como meio de armazenamento das informações. Mas com as 
informações que detalhamos como características destes sistemas de banco de dados, 
esperamos que você, como desenvolvedor(a) possa ter argumentos suficientes para decidir 
34 BANCO DE DADOS | Educação a Distância
adequadamente entre uma abordagem e outra.
Como existem muitos tipos de usuários diferentes que podem interagir com os sistemas de 
bancos de dados, também apresentamos uma lista não exaustiva dos papéis que estes usuários 
podem assumir nestas interações. Uma máxima que devemos sempre utilizar é a “técnicado 
espelho”. Olhe sempre para o software que você desenvolve por meio dos olhos de quem usa. 
Compreender as situações em que cada tipo de usuário interage com um sistema de banco 
de dados permite que tenhamos uma consciência melhor das dificuldades e das necessidades 
que os usuários possuem em cada caso de uso cotidiano da nossa vida profissional.
Por fim, tentamos discutir algumas vantagens da abordagem de sistemas de bancos de 
dados em relação à implementação de aplicações sem a facilidade e funcionalidade de 
um SGBD. Claro que, tendenciosamente, um estudioso de sistemas de bancos de dados 
observaria argumentos bastante positivos em relação à abordagem dos SGBDs. O papel de 
um desenvolvedor experiente é distanciar-se destes apegos a uma determinada tecnologia ou 
outra e decidir sobriamente qual a solução mais adequada para a sua aplicação.
Uma vez entendidos estes conceitos, podemos nos dedicar a estudar melhor alguns dos 
detalhes internos dos modelos utilizados pelos sistemas de bancos de dados e das arquiteturas 
de software existentes que utilizam estes sistemas. Tais tópicos serão abordados em nossa 
próxima unidade.
AtiviDADE DE AutOEStuDO
1. Transações tradicionalmente são melhor entendidas por meio do conjunto de suas pro-
priedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Em quais situ-
ações da vida real você consegue enxergar a necessidade de se executar operações 
com estas propriedades?
2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparação com a 
utilização de arquivos para armazenamento dos dados. Tendenciosamente, o SGBD 
apareceu como o vencedor nas comparações. Quais seriam as situações em que os 
arquivos seriam uma solução mais adequada? Você consegue exemplificar alguma 
outra situação em que uma terceira alternativa seria mais viável?
3. Pense no SBGD como um módulo do sistema ou como uma outra aplicação a ser inte-
grada (pois em muitas concepções modernas, é assim que ele deve ser tratado). Uma 
das características dos SGBDs é o isolamento entre o programa e os dados. Quais 
os benefícios deste isolamento? Em que outras partes do sistema esta característica 
também pode trazer benefícios?
35BANCO DE DADOS | Educação a Distância
Banco de Dados na Nuvem
Jin Zhang, Diretor de Programas da IBM
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
Profi	ssionais	de	dados	estão	adotando	conceitos	de	computação	em	nuvem	para	oferecer	bancos	de	
dados	como	um	serviço	–	facilitando	as	difi	culdades	de	gerenciamento	e	enviando	usuários	para	a	
nuvem nove.
“Leva	semanas	para	confi	gurar	um	novo	banco	de	dados.	Preciso	dele	agora!”
“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”
Qualquer	uma	dessas	reclamações	soa	familiar?	Provavelmente	sim,	se	você	for	um	profi	ssional	de	
dados em uma grande empresa. Os departamentos de TI dos dias de hoje são afetados por uma lista 
não processada de demandas de administração de dados. De solicitações por novos bancos de dados 
de desenvolvimento e teste de aplicativos até o backup e a restauração de volumes de dados cada vez 
mais crescentes, nunca há uma falta de muito trabalho para manter DBAs na correria.
Em	uma	tentativa	de	minimizar	o	tempo	que	os	profi	ssionais	de	dados	gastam	no	modo	reativo	-	res-
pondendo a solicitações de usuários com tarefas sem parada de “banco de dados, clone, banco de 
dados, clone” - algumas organizações estão tomando emprestado conceitos de autoatendimento do 
domínio de computação em nuvem e indo em direção a um modelo de banco de dados como serviço 
ou DBaaS, em que usuários podem simplesmente “acessar uma nuvem” e capturar um banco de 
dados conforme necessário.
É	uma	ideia	provocante	—	principalmente	para	usuários	fi	nais.	Desenvolvedores	de	sistemas	e	de	
software adoram o controle que eles obtêm com recursos de autoatendimento de DBaaS. Quando eles 
estão na toada, em vez de esperando que o departamento de TI volte uma semana mais tarde com um 
banco de dados de desenvolvimento/teste, eles podem solicitar e provisionar recursos imediatamente 
— mantendo seu ímpeto ativo e suas ideias frescas.
Para	tornar	essa	visão	uma	realidade,	no	entanto,	os	profi	ssionais	de	dados	nos	bastidores	devem	
realizar uma quantia considerável de trabalho no backend. Desenvolver uma nuvem de dados privada 
36 BANCO DE DADOS | Educação a Distância
e	lançar	com	sucesso	DBaaS	para	usuários	finais	requer	que	DBAs	considerem	diversos	fatores,	en-
tre eles a infraestrutura de hardware subjacente da nuvem, as “boas práticas” de dados abrangentes 
a	serem	implementadas	e	replicadas	pela	nuvem	e,	por	fim,	a	interface	de	serviços	que	trará	todos	
esses	itens	de	forma	transparente	aos	usuários	finais	para	concluir	a	imagem.
“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”
penetrando as nuvens
Computação em nuvem refere-se a uma categoria de soluções de tecnologia que permite que usu-
ários acessem recursos de computação (neste caso, recursos de dados) on demand, conforme ne-
cessário, sejam os recursos físicos ou virtuais, dedicados ou compartilhados e independentemente 
de como são acessados (por meio de uma conexão direta, rede local [LAN], rede de longa distância 
[WAN] ou a Internet).
Para oferecer DBaaS na nuvem, os departamentos de TI corporativos devem construir e gerenciar 
uma nuvem de dados corporativa privada — uma plataforma que consiste em hardware de armaze-
namento, imagens virtuais, esquemas de banco de dados e mais — e disponibilizar essa nuvem a 
usuários por meio de uma interface de serviços.
Quando esta infraestrutura estiver instaurada, à medida que necessidades de banco de dados sur-
gem, os usuários podem simplesmente ir para a nuvem, solicitar os recursos que requerem e obter 
acesso instantâneo a seu próprio banco de dados pessoal on demand. Quando eles não precisarem 
mais dos ativos de dados, os ativos são reciclados de volta na nuvem para redesignação, em vez de 
serem deixados desperdiçados e inativos.
Figura 1. uma infraestrutura otimizada para entrega em nuvem do banco de dados enfatiza 
simplicidade	e	eficiência	por	meio	de	automação	e	normatização	de	hardware.	
37BANCO DE DADOS | Educação a Distância
Etapa um: Desenvolver a base da nuvem
Sua primeira parada no caminho para construir um ambiente de computação em nuvem e entregar 
DBaaS será considerar sua infraestrutura de hardware subjacente e assegurar que seja alinhada 
aos objetivos de DBaaS (consulte a Figura 1). Devido à maneira como a maioria dos departamentos 
de TI está estruturada, essas decisões de hardware provavelmente não ocorrerão em um vácuo. Na 
verdade, a maioria do DBAs precisará colaborar com administradores de sistemas e contrapartes da 
arquitetura corporativa para chegarem a um consenso sobre qual deve ser a infraestrutura de hardwa-
re. Esse processo pode requerer concessões de todos os lados, portanto, tente entrar na conversa 
com um entendimento claro de suas principais prioridades de hardware e as “boas de ter”. Não tem 
certeza de quais devem ser essas prioridades? Leia adiante.
Como em qualquer decisão de compra de hardware, muitos atributos afetarão a discussão — plata-
forma, tamanho de armazenamento, velocidade, custo e mais. Para suportar DBaaS na nuvem, acima 
de tudo você irá querer assegurar que seu hardware seja o mais padronizado possível. Como é muito 
mais fácil automatizar um script em execução em um sistema aberto homogêneo do que muitos scripts 
diferentes em um heterogêneo, a normatização é a chave para automação. DBaaS em seu âmago é 
nada	mais	que	automação	—	a	automação	do	processo	de	configuração	e	fornecimento	de	um	banco	
de dados — de forma que quanto mais uniforme for sua plataforma de hardware, mais simples será 
configurar	DbaaS.
Em seguida, dê uma olhada nas opções de armazenamento disponíveis para suportar seu banco de 
dados.Certifique-se	de	que	você	tenha	um	entendimento	claro	dos	tipos	de	recursos	que	receberá	
prontos para uso - inclusive atributos como alta disponibilidade, recuperação de desastre e autonomia 
- assim como a capacidade geral de armazenamento e recursos de sua infraestrutura de hardware. 
Como	essa	plataforma	formará	por	fim	a	base	de	sua	oferta	DBaaS,	é	crítico	entender	exatamente	do	
que	é	capaz	-	e	o	que	é	possível	passar	a	seus	usuários	finais.	Se	você	usar	uma	base	de	armazena-
mento	que	tenha	recursos	excepcionais	de	confiabilidade,	disponibilidade	e	capacidade	de	manuten-
ção (RAS), por exemplo, estará mais bem equipado a fornecer bancos de dados na nuvem que são 
resilientes e altamente disponíveis também.
Etapa	dois:	Identificar	cargas	de	trabalho	comuns	e	melhores	práticas
O	próximo	estágio	de	planejamento	de	DBaaS	fornece	a	você,	como	um	profissional	de	dados	expe-
riente com conhecimento íntimo dos funcionamentos internos de sua organização e suas estruturas 
de dados, a chance de brilhar. A etapa mais crítica para a entrega de DBaaS que realmente traz valor 
a	seus	usuários	finais	é	decidir	antecipadamente	o	tipo	de	modelos	e	imagens	de	banco	de	dados	que	
devem	ser	disponibilizados	na	nuvem.	Para	tomar	tais	decisões,	você	deve	identificar	as	cargas	de	tra-
balho comuns e os processos chaves que ocorrem em seu ambiente de negócios e coletar melhores 
práticas. Esses são os principais candidatos para automação e entrega por meio de DBaaS e a chave 
para seu lançamento bem-sucedido.
Por exemplo, os DBAs podem trabalhar juntamente com os gerentes de linha de negócios para identi-
ficarem	os	conjuntos	de	dados	que	“precisam	ter”	e	usarem	essas	informações	para	criarem	modelos	
de	bancos	de	dados	que	conectem	de	forma	eficiente	a	sistemas	front-end,	funcionem	bem	com	ferra-
mentas de consulta e possam ser facilmente clonados para fornecimento futuro por meio de DBaaS. 
Em seguida, a equipe e os sistemas podem acessar a nuvem e ter acesso a todos os modelos que 
contêm os dados mais recentes, informações atualizadas no minuto e estruturas de dados - sem cria-
38 BANCO DE DADOS | Educação a Distância
rem	as	difi	culdades	de	administração	de	dados	de	mudanças	de	esquema,	mapeamento,	migração	
de dados e mais.
Em outros ambientes corporativos, DBAs podem escolher imagens de bancos de dados - frequente-
mente	incorporando	metadados	específi	cos	do	segmento	de	mercado	e	dados	de	referência	-	como	
candidatos para automação. Um DBA familiarizado com os requisitos de negócios pode isolar uma ins-
tância de um banco de dados de produção que contenha um conjunto crítico de tabelas, visualizações, 
acionadores e procedimentos armazenados - assim como dados de referência chave - para criar uma 
imagem de banco de dados para ser automatizada por meio de DBaaS. Quando os negócios solicitam 
um	banco	de	dados	para	suportar	uma	nova	fi	lial	ou	para	testar	um	aplicativo,	não	haverá	nenhuma	
necessidade de esperar semanas enquanto DBAs o constroem. Em vez disso, ele estará disponível 
instantaneamente por meio de DBaaS na nuvem.
Etapa três: Estabelecer um modelo de entrega
Agora	que	você	decidiu	sobre	a	sua	infraestrutura	de	hardware	e	identifi	cou	os	processos	e	procedi-
mentos	a	serem	automatizados	por	meio	de	DBaaS,	sua	etapa	fi	nal	será	trabalhar	com	usuários	fi	nais	
para educar e ajudar os mesmos a selecionarem a interface por meio da qual esses serviços de dados 
serão disponibilizados.
Há	 três	métodos	principais	de	acesso	a	DBaaS:	por	meio	de	uma	 interface	gráfi	ca	com	o	usuário	
(GUI), uma interface da linha de comandos (CLI) ou diretamente por meio de uma interface repre-
sentational	 state	 transfer	 (REST)	padrão.	Qual	 interface	será	empregada	por	fi	m	dependerá	muito	
da	preferência	do	usuário	fi	nal.	Por	exemplo,	enquanto	a	GUI	é	a	abordagem	mais	 fácil	e	simples	
das	três,	se	os	usuários	fi	nais	já	utilizarem	aplicativos	que	empregam	CLI,	pode	ser	que	não	queiram	
alternar. Como alternativa, os usuários podem querer eliminar a necessidade de intervenção humana 
inteiramente e promover uma integração mais forte com seu ambiente, programando aplicativos para 
se comunicarem diretamente com DBaaS por meio de REST. Quando se sabe as opções, é possível 
trabalhar com seus usuários e ajudar a guiá-los para a interface de DBaaS mais adequada para seus 
desejos	e	necessidades	específi	cos	e	juntos	selecionar	o	wrapper	que	unirá	todo	o	pacote	DBaaS.
uma nuvem com um raio de esperança
Não é nenhum segredo que gerenciar os valores de dados em rápida expansão e as necessidades 
de administração de banco de dados das grandes empresas dos dias de hoje é uma grande proeza. 
DBAs têm uma tarefa dura e não há outra maneira de descrever isso. A boa notícia é que com DBaaS, 
os	profi	ssionais	de	dados	estão	em	uma	posição	exclusiva	não	somente	de	darem	aos	usuários	fi	nais	
novos níveis de liberdade e serviço, mas também para saírem do ciclo vicioso de tarefas de dados 
rotineiras e irem para as coisas boas. E apesar de isso poder exigir algum fundamento para chegar 
lá, no que se refere a uma nuvem com um raio de esperança, isso é praticamente o melhor que se 
pode obter.
Fonte: <http://www.ibm.com/developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBa-
aS/>. Acesso em: 14 ago. 2012.
uNiDADE ii
OS BANCOS DE DADOS E O SOFtWArE
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
•	 Apresentar	as	definições	fundamentais	de	sistemas	de	bancos	de	dados.
•	 Descrever	as	arquiteturas	de	bancos	de	dados	e	suas	características.
plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
•	 Conceituar	schemas,	instâncias,	abstrações	e	as	interfaces	de	interação	com	
o SgBD
•	 Estudo	do	histórico	das	arquiteturas	de	computação	em	geral	e	de	sistemas	
de banco de dados
•	 Classificação	dos	diferentes	 tipos	de	banco	de	dados	de	acordo	com	suas	
características
41BANCO DE DADOS | Educação a Distância
iNtrODuçãO
Fo
nte
: S
HU
TT
ER
ST
OC
K.
CO
M
Nesta unidade, apresentaremos alguns conceitos fundamentais que serão utilizados nas demais 
unidades. Para compreender adequadamente os sistemas de banco de dados, é necessário 
diferenciar adequadamente os modelos das instâncias dos modelos – pois possuem ciclos de 
vida e finalidades bastante distintas.
Diferentes tipos de interface de usuário são disponibilizadas para diferentes tipos de usuários 
em vários produtos diferentes comercializados no mercado. Apresentaremos algumas delas 
para que você, desenvolvedor(a), possa explorá-las posteriormente.
Entender como podem ser construídos sistemas com SGBDs implica em conhecer também a 
história da arquitetura de sistemas de computação, que evoluíram do monolítico até o distribuído 
em camadas. Cada geração possui suas particularidades, que também são refletidas na 
construção dos diferentes SGBDs.
Apresentaremos também alguns critérios de classificação de SGBDs para que você, como 
desenvolvedor(a) de software incumbido(a) da árdua tarefa de escolher um produto, possa 
avaliar subjetivamente e objetivamente diferentes alternativas do mercado.
42 BANCO DE DADOS | Educação a Distância
SCHEMAS,	INSTÂNCIAS	E	ABSTRAÇÕES
Uma característica fundamental de qualquer modelo de software (o que inclui o banco de 
dados) é o seu nível de abstração. É impossível conseguir modelar todos os aspectos do 
mundo real numa aplicação. Assim, decidimos adequadamente escolher somente os aspectos 
mais relevantes para resolver um determinado problema, e representamos estes aspectos por 
meio de um modelo – que é uma abstração dos dados do mundo real. Um modelo de dados 
é uma coleção de conceitos que pode ser utilizada para descrever a estrutura de um banco 
de dados. Por meio desses conceitos, conseguimos alcançar a abstração necessária para 
construir o nosso modelo de software.
Em qualquer modelo de dados, é importante distinguiraquilo que representa a descrição do 
banco de dados com o banco de dados em si. A descrição do banco de dados é denominada 
de schema1, que é especificado durante o projeto do sistema de software.
Os dados realmente armazenados num banco de dados podem mudar com uma alta 
frequência. No conjunto de contatos da minha agenda pessoal, esse banco de dados muda 
toda vez que eu adiciono um novo contato ou altero um telefone ou e-mail deste contato. O 
conjunto de dados de um banco de dados num determinado instante do tempo é denominado 
de snapshot. Também é definido como o estado atual de todas as instâncias no banco de 
dados. Uma instância é um item dentro do banco de dados que segue as definições de seu 
schema correspondente.
A distinção entre o schema do banco de dados e o estado do banco de dados é muito importante. 
No processo de desenvolvimento de software, quando definimos um novo banco de dados, 
primeiro definimos o seu schema – que após criado representa um snapshot inicial vazio. Ao 
manipularmos este banco de dados com operações de inserção, alteração e remoção, nós 
modificamos o snapshot. O SGBD é responsável por garantir a consistência do snapshot em 
1 O plural correto de schema é schemata, mas praticamente não é utilizado. Na área de tecnologia da informação, 
costuma-se utilizar o plural schemas, mesmo sendo errado.
43BANCO DE DADOS | Educação a Distância
qualquer momento do tempo.
Não é uma operação usual ter que realizar modificações no schema, mas elas são realizadas 
toda vez que uma mudança nos requisitos do negócio demanda uma alteração no modelo de 
dados. Este conjunto de alterações para acomodar mudanças no software é denominado de 
schema evolution.
iNtErFACES DOS SgBDS
Algumas das interfaces do SGBD com o usuário são:
Linha de Comando Sem dúvida nenhuma a linha de comando é a interface mais poderosa e 
flexível	para	a	interação	do	usuário	com	o	SGBD.	Por	este	mesmo	motivo,	
normalmente não é uma opção que a maioria considere como amigável. 
Mas desenvolvedores devem sem dúvida nenhuma dominá-la para poder 
explorar os recursos do mesmo.
44 BANCO DE DADOS | Educação a Distância
Interfaces Web Muitos SGBDs fornecem interfaces Web que podem ser acessadas por 
meio de qualquer navegador para a administração e manipulação dos ban-
cos de dados. Embora não sejam tão poderosas ou produtivas, são bastan-
te amigáveis e possuem ainda a vantagem da disponibilização do acesso. 
Muitos administradores de rede não se sentem confortáveis em permitir o 
acesso direto ao banco de dados, mas não se importam em liberar o aces-
so por meio de HTTP (Web).
45BANCO DE DADOS | Educação a Distância
Interfaces Desktop São tão amigáveis quanto as Interfaces Web, mas costumam fornecer ca-
pacidades	de	manipulação	gráfica	de	diagramas.	Isso	auxilia	os	desenvol-
vedores a “enxergar” os relacionamentos entre as entidades do banco de 
dados.
46 BANCO DE DADOS | Educação a Distância
Interfaces baseadas 
em formulários
O Oracle Forms é um exemplo clássico desta interface, típica de sistemas 
implementados utilizando-se triggers e stored procedures.	Os	usuários	fi-
nais conseguem executar seus processos de negócios por meio da própria 
interface do SGBD, preenchendo formulários e interagindo com a interface 
de controle.
ArQuitEturAS DE SiStEmAS DE BANCO DE DADOS
A arquitetura de sistemas de banco de dados confunde-se com a própria história da arquitetura 
de sistemas de computação em geral. De fato, ao mesmo tempo em que as aplicações e os 
modelos de arquitetura de aplicações evoluíram, também evoluíram os sistemas de banco de 
dados. Dentre os fatores que influenciaram estas evoluções estão o aumento da capacidade 
de processamento, o aumento da capacidade de armazenamento, o aumento da quantidade e 
capacidade das redes de comunicação, a redução de custo dos equipamentos, o aumento do 
número de usuários, o aumento da quantidade de informações e a universalização do acesso. 
Não há como explicar adequadamente as arquiteturas de sistemas de banco de dados sem 
descrever conjuntamente as arquiteturas de sistemas de computação em geral. Nas próximas 
seções, apresentaremos e descreveremos concomitantemente estas diferentes arquiteturas, 
da centralizada até o modelo em camadas.
47BANCO DE DADOS | Educação a Distância
mODElO CENtrAliZADO
Os primeiros modelos computacionais eram centralizados, baseados num único mainframe 
fornecendo processamento, armazenamento e interface de interação com o usuário no 
mesmo equipamento/aplicação. Raros eram os mainframes (devido ao seu alto custo) e por 
consequência também poucos eram os usuários que tinham acesso a aplicações baseadas 
em mainframe. A interação dos usuários com as aplicações era realizada por meio de terminais 
burros, que não possuíam poder de processamento: somente teclado; e exibiam telas geradas 
no próprio mainframe e transmitidas até o monitor (usualmente de fósforo verde ou amarelo) 
por meio de um cabo de comunicação. A Figura 1 retrata um típico sistema centralizado 
baseado em mainframe.
Mainframe
Terminal
Burro
Terminal
Burro
Terminal
Burro
Figura 1
Fonte: o autor
48 BANCO DE DADOS | Educação a Distância
Costumamos retratar este modelo de computação como monolítico, pois todas as atividades 
eram baseadas no mainframe. Naturalmente, as aplicações desenvolvidas para este tipo de 
equipamento também foram concebidas e implementadas de modo monolítico. Isso significa 
que não havia uma distinção clara entre o que era interface com o usuário ou o que era 
código de negócios ou código responsável pelo armazenamento de dados. Esta situação é 
denominada de sistema altamente acoplado, pois qualquer alteração numa pequena parte 
do sistema costuma levar a várias outras alterações em cascata para diversas outras partes 
do sistema.
Os bancos de dados eram então extensões da própria aplicação e eram baseados nos modelos 
hierárquicos e em rede, que serão apresentados adiante.
Modelo cliente/servidor
Com a popularização dos PCs e o declínio de seus preços, iniciaram-se as primeiras 
implantações da arquitetura cliente/servidor. A ideia é que ao invés de termos um grande 
equipamento monolítico (mainframe), passamos a ter vários equipamentos menores (e de custo 
e capacidade inferior) com propósito específico (banco de dados, arquivos, e-mail, impressão 
etc.) interligados por meio de uma rede de comunicação. Cada servidor tornou-se um serviço 
especializado (embora não seja incomum agrupar vários serviços num único equipamento, 
dependendo da conveniência).
Os clientes, que também são PCs, podem acessar os recursos disponibilizados por estes 
servidores por meio de rede. A Figura 2 mostra um esquema simplificado da arquitetura 
cliente/servidor.
49BANCO DE DADOS | Educação a Distância
Servidor Servidor Servidor
PC PC PC PC
Figura 2
Fonte: o autor
Em termos de arquitetura das aplicações, denominamos o modelo cliente/servidor como modelo 
de 2 camadas, respectivamente camada cliente e camada servidor. No lado cliente costuma-
se implantar os recursos da aplicação relacionados à interface com o usuário, enquanto no 
lado servidor implanta-se a lógica de negócios, armazenamento e controle transacional. Este 
modelo tornou-se extremamente popular no final da década de 1980 e início da década de 1990, 
e com ele também popularizou-se a prática do desenvolvimento de aplicações utilizando-se 
triggers e stored procedures dentro do próprio SGBD. Cada cliente estabelece uma conexão 
remota ao SGBD, que passa a executar a lógica de negócios, armazenar os dados e controlar 
as transações.
O modelo cliente/servidor é bastante adequado quanto às aplicações que possuem um número 
limitado de usuários concorrentes (de 100 a até 300 ou 400 usuários). A partir deste número, 
50 BANCO DE DADOS | Educação a Distância
o desempenho desta