Banco de Dados

Prof. Me.
Edson Yanaga
BANCO DE DADOS
graduao
anlise 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 Administrao: Wilson de Matos Silva Filho
Presidente da Mantenedora: Cludio Ferdinandi
NEAD - Ncleo de Educao a Distncia

Diretoria do NEAD: Willian Victor Kendrick de Matos Silva
Coordenao Pedaggica: Gislene Miotto Catolino Raymundo
Coordenao de Marketing: Bruno Jorge
Coordenao Comercial: Helder Machado
Coordenao de Tecnologia: Fabrcio Ricardo Lazilha
Coordenao de Curso: Danillo Xavier Saes
Supervisora do Ncleo de Produo de Materiais: Nalva Aparecida da Rosa Moura
Capa e Editorao: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, Jos Jhonny Coelho, Luiz
Fernando Rokubuiti e Thayla Daiany Guimares Cripaldi
Superviso de Materiais: Ndila de Almeida Toledo
Reviso Textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janana Bicudo Kikuchi, Jaquelina
Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR

CENTRO UNIVERSITRIO DE MARING. Ncleo de Educao

a distncia:
C397 Banco de dados / Edson Yanaga. Maring - PR, 2012.
143 p.
Graduao em Anlise e Desenvolvimento de Sistemas e

Sistemas para Internet - EaD.

1. Banco de dados. 2. Arquitetura de sistemas. 3.EaD. I. Ttulo.

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. Aclimao - (44) 3027-6360 - CEP 87050-390 - Maring - Paran - www.cesumar.br
NEAD - Ncleo de Educao a Distncia - bl. 4 sl. 1 e 2 - (44) 3027-6363 - ead@cesumar.br - www.ead.cesumar.br
BANCO DE DADOS
Prof. Me. Edson Yanaga
APRESENTAO DO REITOR
Viver e trabalhar em uma sociedade global um grande desafio para todos os cidados.
A busca por tecnologia, informao, conhecimento de qualidade, novas habilidades para
liderana e soluo de problemas com eficincia tornou-se uma questo de sobrevivncia no
mundo do trabalho.
Cada um de ns tem uma grande responsabilidade: as escolhas que fizermos por ns e pelos
nossos far grande diferena no futuro.
Com essa viso, o Cesumar Centro Universitrio 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 misso promover a educao de qualidade nas diferentes reas
do conhecimento, formando profissionais cidados que contribuam para o desenvolvimento
de uma sociedade justa e solidria , o Cesumar busca a integrao do ensino-pesquisa-extenso com as demandas institucionais e sociais; a realizao de uma prtica acadmica que
contribua para o desenvolvimento da conscincia social e poltica e, por fim, a democratizao
do conhecimento acadmico com a articulao e a integrao com a sociedade.
Diante disso, o Cesumar almeja ser reconhecido como uma instituio universitria de referncia regional e nacional pela qualidade e compromisso do corpo docente; aquisio de competncias institucionais para o desenvolvimento de linhas de pesquisa; consolidao da extenso
universitria; qualidade da oferta dos ensinos presencial e a distncia; bem-estar e satisfao
da comunidade interna; qualidade da gesto acadmica e administrativa; compromisso social
de incluso; processos de cooperao e parceria com o mundo do trabalho, como tambm
pelo compromisso e relacionamento permanente com os egressos, incentivando a educao
continuada.
Professor Wilson de Matos Silva
Reitor
BANCO DE DADOS | Educao a Distncia
Caro(a) aluno(a), ensinar no transferir conhecimento, mas criar as possibilidades para a

sua produo ou a sua construo (FREIRE, 1996, p. 25). Tenho a certeza de que no Ncleo
de Educao a Distncia do Cesumar, voc ter sua disposio todas as condies 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 formao e contemplam as diretrizes curriculares dos cursos de graduao,
determinadas pelo Ministrio da Educao (MEC). Desta forma, buscando atender essas
necessidades, dispomos de uma equipe de profissionais multidisciplinares para que,
independente da distncia geogrfica que voc esteja, possamos interagir e, assim, fazer-se
presentes no seu processo de ensino-aprendizagem-conhecimento.
Neste sentido, por meio de um modelo pedaggico 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, alm do
material produzido em linguagem dialgica, aulas sobre os contedos 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 formao, tm por intuito possibilitar o desenvolvimento de novas competncias
necessrias para que voc se aproprie do conhecimento de forma colaborativa.
Portanto, recomendo que durante a realizao de seu curso, voc procure interagir com os
textos, fazer anotaes, responder s atividades de autoestudo, participar ativamente dos
fruns, ver as indicaes de leitura e realizar novas pesquisas sobre os assuntos tratados,
pois tais atividades lhe possibilitaro organizar o seu processo educativo e, assim, superar os
desafios na construo 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 igualitria.
Um grande abrao e timos momentos de construo de aprendizagem!
Professora Gislene Miotto Catolino Raymundo
Coordenadora Pedaggica do NEAD- CESUMAR
APRESENTAO
Livro: BANCO DE DADOS
Professor Me. Edson Yanaga
Salve, carssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco

de Dados, elaborado especificamente para contribuir na sua formao 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 Cincia da Computao pela
Universidade Estadual de Maring (UEM) e Mestre em Engenharia Eltrica e Informtica
Industrial pela Universidade Tecnolgica Federal do Paran (UTFPR) na rea de Telemtica.
Sou empresrio (consultor e desenvolvedor) na rea de software e trabalho com a plataforma
Java desde 1997 completando 15 anos de experincia neste ano de 2012. Trabalho tambm
como administrador de sistemas Unix (Solaris, HP-UX e Linux) desde 2000, e desde 2008
j era adepto e entusiasta da computao em nuvem (cloud computing). Participo de vrios
cursos em nvel de especializao em diversas instituies, como Cesumar, UEM, UNIPAR
e Faculdade Integrado; e sou coordenador do curso de Especializao em Desenvolvimento
Orientado a Objetos em Java do Cesumar desde 2004. Possuo as seguintes certificaes:
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 Developer for J2EE 1.4;
e Sun Certified Programmer for Java 2 Platform 1.4. Como lder do Redfoot JUG (Java Users
Group) Grupo de Usurio Java do Norte do Paran atuo desde 2004. Tive o prazer de ser
membro do comit tcnico do JavaOne Latin America nas edies de 2010 e 2011. Apresento
palestras em diversos eventos em nvel nacional e internacional, e ultimamente sou um grande
entusiasta do Artesanato de Software e do cdigo bem-feito.
Confesso que foi um tremendo desafio escrever este material. At certo ponto uma repetio
cansativa dizer que o ritmo das mudanas e inovaes cada vez mais se acelera, mas a
princpio 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 transformaes que chacoalharam os alicerces
de fundamentos criados e utilizados desde a dcada de 1970. Os desafios dos sistemas de
informao atuais exigem que manipulemos no gigabytes ou terabytes de informaes, e sim

petabytes, exabytes e zetabytes.
Sistemas de informao das geraes anteriores tinham como objetivo gerar informaes que
pudessem agregar valor aos processos de negcios. Pois bem, esse objetivo foi alcanado.
Com a to aguardada e estimulada onipresena de software, a magnitude destas informaes
geradas cresceu. Redes sociais, smartphones, tablets, sensores de automao e vrios outros
dispositivos geram inmeros bits de informao a todo momento. Conceitos antigos j no so
soberanos nesses ambientes inspitos atuais. Diante destes cenrios 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 no se engane, caro(a) leitor(a), estes
fundamentos de bancos de dados relacionais so imprescindveis para que se possa dar o
prximo passo rumo ao conhecimento de Big Data e NoSQL.
Na Unidade I teremos a apresentao de tpicos conceituais e definies sobre bancos de
dados, sistemas gerenciadores de bancos de dados e os tipos de usurios que interagem com
esses sistemas. Teremos tambm uma breve explanao sobre o conceito de transaes,
que uma ferramenta essencial no desenvolvimento de aplicaes mais tradicionais como
aquelas que envolvem dados financeiros. Como leitura complementar, temos um texto de
Cezar Taurion (Evangelista Tcnico da IBM) falando sobre Big Data. Afinal, importante
darmos um passo no presente mas sempre com um olho no futuro. Essa ser a tnica das
nossas leituras complementares e sugestes de vdeos: apresentar-lhe sempre os conceitos
de vanguarda que j so aplicados em muitos casos de uso em aplicaes modernas.
A Unidade II descrever a terminologia e outros conceitos bsicos que sero utilizados no
restante deste material, tais como a diferenciao entre schemas e instncias 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 alm de auxili-lo(a) na escolha dos diferentes tipos de produtos existentes
e tambm dos produtos concorrentes em cada tipo ofertado.
O modelo relacional de banco de dados propriamente dito ser abordado na Unidade III. A
partir deste ponto voc estar apto a identificar as caractersticas de modelos relacionais e
passar a construir seus prprios modelos de dados baseado nos fundamentos apresentados.
Na modelagem relacional, voc identificar entidades do seu domnio de negcios, suas
restries 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 no ser um problema para voc,
futuro(a) desenvolvedor(a) de software bem feito. Mas convm 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). Aps sua criao, a SQL tornou-se um
padro de facto para manipular informaes em sistemas de banco de dados por meio de seus
comandos para insero, atualizao, remoo e consulta de instncias de dados.
E antes que voc possa apreciar o contedo do material, permita-me apresentar meu ponto de
vista para reflexo: em muitas empresas o sistema de banco de dados tornou-se o repositrio
sagrado das informaes, trancado a sete chaves e reservado ao guardio denominado de
DBA (DataBase Administrator). Alis, bastante comum que os alunos aprendam ou venham
a concluir que o banco de dados o corao de um sistema de informao baseados
nessas falsas impresses transmitidas at certo ponto em grande quantidade. Para mim e
tambm para muitos autores renomados do mundo do software, o banco de dados apenas
uma ferramenta utilizada na construo de nossos sistemas de informao. E como toda
e qualquer ferramenta, no pode ficar acima do prprio cdigo que atende ao processo de
negcios da empresa. Isso diminui sua importncia? Certamente que no! Mas quando
modelar seu sistema de informao, pense primeiro no seu modelo de negcios e postergue
at o ltimo momento a sua viso sobre o banco de dados. Tenho certeza de que isso tornar
a sua aplicao muito melhor projetada e permitir que ela oferea um retorno muito melhor
ao seu negcio.
O banco de dados s um detalhe. Um detalhe importante, mas o considere um detalhe.
O corao da sua aplicao o cdigo bem feito que voc elaborar para atender ao seu
negcio. Pense nisso, e a cada batida desse corao voc poder usufruir de muito retorno (e
muito dinheiro, espero).
Um bom proveito e uma tima leitura.
Prof. Me. Edson Yanaga
Sumrio
UNIDADE I
CONCEITOS DE BANCOS DE DADOS
CARACTERSTICAS DE SISTEMAS DE BANCOS DE DADOS.............................................20
TRANSAES.........................................................................................................................27
VANTAGENS DE SE UTILIZAR UM SGBD.............................................................................31
UNIDADE II
OS BANCOS DE DADOS E O SOFTWARE
SCHEMAS, INSTNCIAS E ABSTRAES...........................................................................42
INTERFACES DOS SGBDS.....................................................................................................43
ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS....................................................46
MODELO CENTRALIZADO.....................................................................................................47
CLASSIFICAO DOS SISTEMAS DE BANCO DE DADOS.................................................56
UNIDADE III
O MODELO RELACIONAL
CONCEITUAO.....................................................................................................................68
RESTRIES DO MODELO RELACIONAL...........................................................................71
UNIDADE IV
SQL Bsico
DEFINIES DE DADOS E TIPOS EM SQL..........................................................................93
RESTRIOES..........................................................................................................................97
CONSULTAS BSICAS EM SQL.............................................................................................99
COMANDOS DE MODIFICAO DE DADOS EM SQL........................................................104
UNIDADE V
MAIS SQL
CONSULTAS ENVOLVENDO NULL...................................................................................... 118
CONSULTAS UTILIZANDO JOINS........................................................................................124
CONSULTAS COM FUNES DE AGREGAO................................................................126
COMANDOS DE ALTERAO DE SCHEMA.......................................................................128
CONCLUSO......................................................................................................................... 141
REFERNCIAS......................................................................................................................143
UNIDADE I
CONCEITOS DE BANCOS DE DADOS

Objetivos de Aprendizagem
Apresentar os conceitos fundamentais envolvendo dados e bancos de dados em
sistemas computacionais.
Descrever as formas interao dos usurios com os bancos de dados.
Comparar as vantagens desta abordagem em relao a outras similares.
Plano de Estudo
A seguir, apresentam-se os tpicos que voc estudar nesta unidade:
Conceituar bancos de dados, sistemas gerenciadores de banco de dados e
sistemas de banco de dados
Apresentar as principais caractersticas de sistemas de banco de dados
Enumerar alguns papis de usurios envolvidos na interao com sistemas
de bancos de dados
Descrever algumas vantagens na utilizao de sistemas de bancos de dados
comparados a outras abordagens
Fonte: SHUTTERSTOCK.COM
INTRODUO
Scientia potentia est: Conhecimento poder.

Sim, caro(a) leitor(a), conhecimento poder. Informao poder. Na sociedade do sculo
XXI, chamamos estas informaes armazenadas em sistemas computacionais de dados. E
temos informao em abundncia. O desafio crescente dos prximos anos encontrar formas
eficientes de processar os dados que j temos e ainda criar para gerar conhecimento e,
consequentemente, riqueza.
Nas ltimas dcadas, boa parte do software desenvolvido envolve alm do processamento
de informaes: as informaes de entrada e de sada do software (alm de outras
metainformaes intermedirias) devem ser armazenadas em um mecanismo confivel, e que
possibilite o acesso simples e rpido leitura e escrita destas informaes.
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 mudana e os modelos de negcios que surgiram
recentemente provocaram uma ruptura na forma de se pensar no armazenamento de
informaes em bancos de dados.
15
Mas de onde vem este termo que conhecemos como banco de dados? Pois em ingls, o
termo refere-se a databases, que numa traduo literal definiramos como base de dados. Um
bom palpite remete a uma viso generalizada de que as instituies denominadas de bancos
guardam de modo bastante seguro o nosso dinheiro. Os bancos de dados seriam ento
ferramentas que guardariam nossas informaes (dados) de modo tambm supostamente
seguro e confivel.
Outra confuso bastante comum e plenamente justificada refere-se diferena entre os termos
banco de dados e os sistemas que o gerenciam. Segue uma definio segundo Navathe
(2011, p.3):
Um banco de dados e uma coleo de dados relacionados. Os dados sao fatos que
podem ser gravados e que possuem um significado implicito. Por exemplo, considere
nomes, nmeros telefnicos e endereos 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 informaes sao
uma coleao de dados com um significado implicito, consequentemente, um banco de
dados.
Nossos bancos de dados podem ser colees de dados relacionados dos mais diversos
tamanhos. Desde uma pequena agenda contendo nmeros e contatos de pessoas at um
ndice gigantesco de pginas de Internet e buscas relacionadas ou todas as mensagens e
informaes trocadas entre bilhes de usurios de uma rede social.
Em termos computacionais, h uma categoria de software especializado que desenvolvido
especificamente com o propsito de se gerenciar estas colees de dados: os sistemas
gerenciadores de banco de dados popularmente reconhecidos pela sigla SGBD (ou DBMS
DataBase Management Systems, na sigla original em ingls). Segue mais uma definio de
Navathe (2011, p.3), sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) e uma coleao de programas
que permite aos usuarios criar e manter um banco de dados. O SGBD e, portanto,
um sistema de software de proposito geral que facilita os processos de definiao,
construao, manipulaao e compartilhamento de bancos de dados entre varios usuarios
e aplicaes. A definiao de um banco de dados implica especificar os tipos de dados,
16
as estruturas e as restries para os dados a serem armazenados em um banco de

dados.
Embora no seja necessrio utilizar um SGBD para se desenvolver quaisquer sistemas de

software, tal opo no se mostra vivel. Relembrando o nosso conceito de que a importncia
do software consiste em sua capacidade de se gerar valor com as informaes que manipula,
tem-se que implementar nosso prprio mecanismo de manipulao de dados em nossas
aplicaes no 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 no relacionais
(tambm conhecidos como NoSQL) incluem MongoDB, Redis, Neo4j e Riak.
Para propsitos de definio, 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
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de dados Open
Source. Bem, tenho minha opinio pessoal e quero compartilhar com vocs. Vamos ver se vai gerar
muita discordncia...
17
Os softwares de banco de dados so um dos mais importantes componentes de software de uma

organizao. Neste ambiente as alternativas de software livre j so bastante conhecidas e freqentemente so mencionadas na mdia, como MySQL, PostgreSQL, Ingres e Derby.
O MySQL um produto de uma empresa privada, a MySQL AB. Seu cdigo desenvolvido pelos
funcionrios da empresa e com isso ela garante a propriedade intelectual sobre o produto. Existe uma
comunidade envolvida, mas submisses de cdigo so restritas apenas correo de bugs. Uma
pergunta: o MySQL pode ser considerado realmente Open Source, uma vez que no adota o modelo
de desenvolvimento colaborativo? O MySQL ofertado tanto em GPL como sob licena comercial.
As duas verses so funcionalmente equivalentes, sendo diferenciadas pelo nvel de suporte e certificao. 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 tambm o Ingres, que foi um banco de dados da Computer Associates e
agora pertence a uma organizao 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 projeto Derby. O Derby (http://db.apache.org/derby/) um banco de dados em Java, geralmente embarcado em outros softwares. A IBM, por exemplo, o utiliza embutido em diversos softwares
das famlias WebSphere, Tivoli e Lotus.
Nas minhas andanas pelo mercado tenho visto que na prtica os bancos de dados Open Source s
aparecem como competidores dos produtos mais avanados nas aplicaes pouco sofisticadas ou
bem especificas.
Por sua vez, os sistemas de banco de dados proprietrios buscam competir com funcionalidades diferenciadoras, principalmente as relacionadas com administrao de ambientes complexos; escalabilidade; desempenho com grande volume de transaes; alta disponibilidade e capacidade de recuperao rpida; e recursos de data warehousing. Alm disso, foi criado um ecossistema de negcios em
torno dos principais software de banco de dados proprietrios, com diversas empresas independentes
oferecendo ferramentas de software complementares (geradores de relatrios, analisadores estatsticos e outros), servios de suporte tcnico especializado e formao de recursos humanos, e assim
por diante, o que tambm cria uma barreira de entrada difcil de transpor por qualquer novo entrante.
J o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde se gera dinheiro) ainda incipiente, sendo formado por pequenas empresas com abrangncia de atuao bastante limitada. Ano passado, a MySQL gerou cerca de 50 milhes de dlares em receita (http://news.
com.com/MySQL+hits+50+million+revenue,+plans+IPO/2100-7344_3-6179290.html), mas ainda
um trao (cerca de 0,03%) no grfico que mostra o mercado global de bancos de dados relacionais,
estimado pelo IDC em 16 bilhes de dlares. Como comparativo, o IDC estima que neste mesmo ano,
18
a receita da IBM com a famlia de produtos DB2 foi de aproximadamente 3,5 bilhes de dlares.
Qual o papel que os bancos de dados Open Source desempenharo? Na minha opinio estaro
atuando (pelo menos nos prximos 3 a 4 anos) na chamada faixa de produtos com funcionalidades
comoditizadas, onde as caractersticas de preo so as de maior importncia. Os usurios tpicos
sero organizaes e aplicaes que no precisam de recursos mais sofisticados.
Como avaliar a qualidade de um banco de dados Open Source? Existem diversos critrios que podem
e devem ser considerados em uma anlise para seleo de um banco de dados. Os nveis de importncia das variveis da anlise esto diretamente relacionadas com os objetivos do negcio e das
necessidades a serem impostas aos softwares de bancos de dados.
Alguns dos principais fatores a serem considerados so:
a) Recursos de gerenciamento e administrao. So as ferramentas de apoio s tarefas do administrador do banco de dados.
b) Desempenho e escalabilidade. Os recursos que o software oferece para garantir desempenho
adequado, nos volumes de transaes que sero demandados.
c) Recursos tcnicos. Disponibilidade de recursos como triggers, stored procedures, cursors, subqueries, capacidade de replicao, recursos de indexao, aderncia a padres (ANSI SQL), particionamento, backup/recovery, suporte a dados no estruturados, independncia de plataforma
e recursos de segurana.
d) Custos de Propriedade.
e) Suporte tcnico e disponibilidade de recursos humanos. Abrangncia do ecossistema em termos
de servios de suporte e qualificao de recursos humanos.
f)
Disponibilidade de aplicativos.
g) Recursos de data warehousing e BI.

h) Recursos de desenvolvimento de aplicaes.
i)
Modalidade de licenciamento.
j)
Viso, estratgia e road map do produto.
k) Tamanho e participao/envolvimento da comunidade.

l)
Modelo de governana adotado pela comunidade.
m) Base instalada e adoo pelo mercado.

Bem e quanto a uma pergunta que muitos me fazem... Minha empresa deve adotar um banco de dados Open Source? Para mim, para mudar um software de banco de dados deve haver uma estratgia
impulsionada por razes fortes e consistentes. Por exemplo, se houver desconfianas que o atual
fornecedor esteja saindo do mercado; falta de funcionalidade do software (no mais adequado s
19
necessidades das novas aplicaes da empresa); falta de viso estratgica por parte do fornecedor
do software atual; custos de manuteno e operao muito elevados para o resultado obtido; falta de
pessoal gabaritado, que esteja disponvel no mercado; carncia de consultorias e servios de suporte
externos; relacionamento com o fornecedor cada vez mais deteriorado... Mudar para um banco de
dados Open Source simplesmente por questes ideolgicas deve estar fora de cogitao, pois banco
de dados muito srio para ser tratado de forma simplista.
OK, e quais seriam ento os custos e riscos da migrao? Existem custos de migrao que no podem ser subestimados. Temos os custos da converso de dados, custos da codifi cao, testes, e o
que chamamos reconciliao entre as aplicaes no novo e no antigo ambiente, sempre considerando
que difi cilmente conseguiremos fazer uma migrao estilo big bang, mas que esta ser gradual.
Quanto mais complexas forem as aplicaes a serem convertidas, mais custosa ser a migrao. Esta
complexidade pode ser medida pelo nmero de programas, nmero de tabelas relacionais, restries
de integridade referencial e tamanho do banco de dados. Existem custos indiretos como a construo
de interfaces entre as aplicaes j convertidas e as que ainda esto no banco de dados antigo. Tambm os custos de suporte tcnicos aos dois ambientes implicam muitas vezes, em gastos adicionais
elevados, principalmente quando o novo banco de dados no for de completo domnio da equipe
tcnica da empresa.
Em resumo, os custos da migrao afetam os clculos de custos totais de propriedade. A maioria das
empresas extremamente cautelosa em trocar de fornecedor de softwares crticos. O perigo de uma
interrupo nos seus negcios 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
benefcios forem claramente demonstrveis.
Fonte: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/bancos_de_dados_open_source?lang=pt_br>. Acesso em: 14 ago. 2012.
CArACtErStiCAS DE SiStEmAS DE BANCOS DE DADOS

Se utilizar um sistema de banco de dados parece uma soluo natural, qual seria a outra
soluo alternativa? Pense em algumas aplicaes que voc utiliza e que no fazem uso de
SGBDs. Processadores de texto, planilhas, ferramentas de desenho etc., so alguns exemplos
20
dessas aplicaes. O que todas tm em comum? A necessidade de se armazenar a informao

manipulada por meio de arquivos.
Em qualquer aplicao que necessite do armazenamento de dados, faz-se necessrio 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 necessrio para se criar um
formato e processar a sua gravao e recuperao e acredite, no pouco trabalho!
Um SGBD, por outro lado, j dispe de uma srie de funcionalidades prontas para serem
utilizadas pelo desenvolvedor da aplicao. Deste modo, uma srie de preocupaes passa
a ser delegada a um software de terceiros (o SGBD). A seguir, apresentaremos uma srie de
caractersticas que diferenciam a abordagem de sistemas de banco de dados da manipulaao
manual das informaes (como em arquivos, por exemplo).
Natureza autodescritiva
Uma caracterstica fundamental que distingue os sistemas de bancos de dados de outras
abordagens o fato de que nos SGBDs, o banco de dados e as metainformaes sobre
o banco de dados so armazenados conjuntamente. Essas metainformaes armazenadas
contm informaes como o tipo, tamanho e restries do banco de dados. Em termos
tcnicos, as metainformaes so chamadas de esquema (ou schema, em seu termo original
em ingls).
Isolamento entre Programa e Dados
Numa aplicao que utilize arquivos para o armazenamento de dados, quaisquer alteraes na
estrutura do arquivo tambm implicaro em alteraes 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 so armazenados, sem se
21
importar em como esses dados sero manipulados internamente. Esta caracterstica aumenta
bastante o nvel de manutenibilidade do sistema, quando bem aplicada.
Mltiplas vises dos dados
Esta no uma caracterstica fundamental, mas muitos SGBDs fornecem a possibilidade de
que diferentes usurios com diferentes permisses possam acessar diferentes vises dos
dados. Essas vises (views) correspondem a estruturas virtuais criadas a partir dos dados
armazenados e podem conter, alm dos prprios dados, tambm informaes derivadas
(calculadas) a partir desses dados.
A criao de diferentes usurios com diferentes permisses a vises especficas uma
abordagem muito utilizada em sistemas cliente/servidor; ou na integrao de aplicaes
mediante banco de dados. O auge do uso destas abordagens deu-se no final da dcada
de 1990, embora ainda hoje seja possvel testemunhar aplicaes sendo executadas sob
este modelo. Recomenda-se fortemente que no desenvolvimento de novas aplicaes, a
abordagem de mltiplas vises e de integrao mediante banco de dados seja substituda
por uma abordagem orientada a servios como SOA (Service Oriented Architecture) ou como
REST (REpresentational State Transfer).
Vises no so uma m prtica. So um recurso bastante til, mas no imprescindvel. Como
toda ferramenta, bem utilizada e de modo adequada, um recurso valioso.
Acesso concorrente de mltiplos usurios
Um SGBD multiusurio, como o prprio nome j define, deve permitir o acesso de mltiplos
usurios. Alm disso, o acesso deve ser concorrente, permitindo que todos os usurios
conectados executem operaes ao mesmo tempo.
Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errnea na rea
de Tecnologia da Informao: paralelo e concorrente. Paralelismo puro algo raro em
22
computao, embora seja perfeitamente possvel. Ao lidarmos com sistemas de banco de

dados, utilizamos o termo concorrente, pois vrios usurios tm a impresso de que esto
executando instrues ao mesmo tempo quando na verdade, por se tratar de informaes
acessadas em disco ou com um nico barramento de acesso, torna-se necessrio algum
mecanismo de conteno que serialize (coloque em fila) cada uma dessas instrues.
Como idealmente a execuo dessas instrues bastante curta, tem-se a impresso do
pseudoparalelismo.
Um conceito fundamental para que o acesso destes mltiplos usurios mantenha o banco de
dados num estado consistente o mecanismo de transaes, que ser descrito na prxima
seo.
A revoluo do Big Data est prestes a acontecer
Cezar Taurion
O termo Big Data comea a despertar muita ateno, mas ainda um conceito mal defi nido e compreendido. Com uma rpida pesquisa ao Google, identifi quei, pelo menos, uma dzia de defi nies.
Neste artigo, vou falar um pouco sobre o assunto e debater alguns desafi os que temos para conseguir
colocar projetos de Big Data em ao.
23
Sem entrar em definies e nos atendo apenas a conceitos, podemos resumir com uma frmula simples o que Big Data: volume + variedade + velocidade de dados. Volume porque, alm dos dados
gerados pelos sistemas transacionais, temos a imensido de dados gerados pelos objetos na Internet
das Coisa, como sensores e cmeras, e os gerados nas mdias sociais, via PCs, smartphones e tablets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos no estruturados, como fotos, videos, emails e tutes. E, por fim, velocidade porque, muitas vezes, precisamos
responder aos eventos quase que em tempo real. Ou seja, estamos falando de criao e tratamento
de dados em volumes massivos.
Outro desafio: criar e tratar apenas de dados histricos, como os veteranos Data Warehouse e as
tecnologias de BI (Business Intelligence) comeam a se mostrar lentos demais para a velocidade com
que os negcios precisam tomar decises. Alis, 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 nmeros so gigantescos. Se olharmos globalmente, estamos falando em zetabytes, ou 10 bytes. Grandes corporaes armazenam multiplos petabytes e mesmo
as pequenas e mdias empresas trabalham com dezenas de terabytes de dados. Este volume tende
a crescer geomtricamente. Em mundo cada vez mais competitivo e rpido, as empresas precisam
tomar decises baseadas no apenas em palpites, mas em dados concretos. Assim, para um setor de
marketing faz todo sentido ter uma viso 360 de um cliente, olhando no 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 so os recursos naturais da nova Revoluo Industrial. Na atual sociedade industrial, ter apenas recursos naturais, como minrio, e export-los de forma bruta - importando
em troca produtos manufaturados, no garante a competitividade de um pas no longo prazo. O importante a tecnologia e o conhecimento que cria produtos manufaturados. Afinal, um quilo de satlite
vale imensamente mais do que um quilo de minrio de ferro.
Fazendo um paralelo, na sociedade da informao crucial saber tratar os dados na velocidade
adequada. Dados no tratados e analisados em tempo hbil so dados inteis, pois no geram informao. Dados passam a ser ativos corporativos importantes e como tal, podem - e devero - ser
quantificados econmicamente.
Big Data representa um desafio tecnolgico, pois demanda ateno infraestrutura e tecnologias
analticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de computao em nuvem, desde, claro, que este imenso volume no seja transmitido repetidamente via
Internet. S para lembrar, os modelos de cobrana pelo uso de nuvens pblicas tendem a gerar processamentos muito baratos, mas tornam caro a transmisso de muitos dados.
A principal base tecnolgica para Big Data Analytics o Hadoop e os bancos de dados NoSQL, onde
24
No significa Not Only SQL, ou seja, usa-se bases de dados SQL e no SQL. A importncia do Not
Only SQL explica-se pelo fato do modelo relacional ser baseado na poca de sua criao, no incio
dos anos 70. Nessa poca, acessar, categorizar e normalizar dados era bem mais fcil do que hoje.
Praticamente no existiam dados no estruturados circulando pelos computadores da poca. Tambm no foi desenhado para escala massiva, ou para um processamento muito rpido. Seu objetivo
bsico era possibilitar a criao de queries que acessacem bases de dados corporativas e, portanto,
estruturadas. Para solues Big Data, tornam-se necessrias varias tecnologias, desde bancos de
dados SQL, a softwares que utilizem outros modelos, que lidem melhor com documentos, grafos,
processamento paralelo, etc.
A complexidade do Big Data vem tona quando lembramos que no estamos falando apenas de
armazenamento e tratamento analtico de volumes massivos de dados, mas de reviso, ou criao,
de processos que garantam a qualidade destes dados e de processos de negcios que usufruam dos
resultados obtidos. Portanto, Big Data no apenas um debate sobre tecnologias, mas, principalmente, sobre como os negcios podero usufruir da montanha de dados que est agora sua disposio.
A emerge a questo da integrao: como integrar bases de dados estruturadas e no estruturadas
com diversos softwares envolvidos?
O Big Data abre oportunidades profissionais bem amplas. Na minha opinio, existe espao para dois
perfis profissionais: um mais voltado para os negcios e qualificados para tratar analiticamente as
informaes geradas por estas imensas bases de dados e outro com vis mais tcnico, ou Data
Architect.
Pelo vis dos negcios, um artigo interessante que foi publicado h poucos meses pelo Wall Street
Journal, na edio brasileira, aponta como problema a escassez de talentos. Ele fala que muitas
empresas americanas comearam a procurar profissionais que saibam interpretar os nmeros usando
a anlise de dados, tambm conhecida como inteligncia empresarial. Mas encontrar profissionais
qualificados tem se mostrado difcil. O resultado foi que vrias faculdades americanas, como a Faculdade de Ps-Graduao em Administrao da Universidade Fordham e a Faculdade de Administrao
Kelley, da Universidade de Indiana, comearam a oferecer disciplinas eletivas, cursos de extenso e
mestrados em anlise de dados. J o Data Architect deve lidar com tecnologias SQL e NoSQL, conhecer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto,
ter capacidade de desenhar estratgias para manusear e analisar grandes volumes de dados de
formatos diferentes, quase que em tempo real.
A idia de stream processing, ou stream computing, fantstica; um novo paradigma. No modelo
de data mining tradicional, uma empresa filtra dados dos seus vrios sistemas e, aps criar um data
warehouse, dispara queries. Na prtica, faz-se uma garimpagem em cima de dados estticos, que
no refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrs. Com o stream
computing, esta garimpagem efetuada em tempo real. Em vez de disparar queries em cima de uma
25
base de dados esttica, coloca-se uma corrente contnua de dados (streaming data) atravessando
um conjunto de queries. Podemos pensar em inmeras aplicaes, sejam estas em fi nanas, sade
e mesmo manufatura.
Vamos ver este ltimo exemplo: um projeto em desenvolvimento com uma empresa de fabricao
de semicondutores monitora em tempo real o processo de deteo e classifi cao de falhas. Com o
stream computing, as falhas nos chips que esto sendo fabricados so detetadas em minutos e no
em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda,
pode-se fazer ajustes em tempo real nos prprios processos de fabricao.
Quanto ao EDA, pode-se comear a estudar o assunto acessando seu verbete na Wikipedia.
O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Alis, j aparece no canto da tela
de um ou outro CIO, e, provavelmente, em alguns anos j ser um dos temas mais prioritrios das
tradicionais listas de tecnologias do ano. Portanto, bom estar atento sua evoluo e comear a
colocar em prtica 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/>.
26
TRANSAES
O conceito de transao fundamental em muitas reas da computao, e particularmente

fundamental em sistemas de banco de dados. Consideramos como transao uma
determinada unidade de trabalho, que realizada em qualquer sistema computacional de
um modo coerente e independente de outras transaes. Estas transaes devem permitir
que o sistema esteja num estado coerente antes e depois de sua execuo, independente de
falhas ou outros problemas que possam ocorrer. Devem permitir tambm que vrios clientes
diferentes acessem concorrentemente o sistema sem que isso possa corromper ou levar a
estados que no sejam considerados coerentes.
Uma definio clssica do conceito de transaes envolve o acrnimo ACID, oriundo das
propriedades de Atomicidade, Consistncia, Isolamento e Durabilidade.
Atomicidade
A propriedade atomicidade de banco de dados advm do conceito de tomo da fsica o qual
at recentemente supunha-se indivisvel. Essa indivisibilidade pressupe que as operaes
realizadas numa transao sejam todas realizadas por completo; ou que nenhuma seja
realizada. Popularmente seria o conceito do tudo ou nada. Isto permite que durante a nossa
interao com um banco de dados, possamos agrupar vrios comandos relacionados com
27
a garantia de que todos sejam executados de modo que as informaes armazenadas

permaneam num estado consistente aps a execuo da transao.
Consistncia
A propriedade de consistncia assegura que a execuo de qualquer transao trar o
banco de dados de um estado consistente para outro estado tambm consistente. No caso,
a consistncia implica que todos os dados de um banco de dados devem ser vlidos de
acordo com um conjunto de regras que podem incluir restries de tipo, valor, referncias entre
informaes etc.
Isolamento
A propriedade de isolamento determina que o resultado da execuo concorrente de um
conjunto de transaes ter o mesmo resultado de sua execuo em srie (uma aps a outra).
O isolamento transacional o que garante e permite o acesso concorrente de mltiplos
usurios ao mesmo SGBD.
Durabilidade
A propriedade de durabilidade garante que uma vez que uma transao tenha sido finalizada
com sucesso, os dados tero a garantia de terem sido armazenados corretamente
independentemente da eventualidade de falhas, falta de energia, erros de aplicao etc.
Na opinio deste autor, justamente a propriedade de durabilidade que faz com que os
bancos de dados sejam posicionados como ferramentas sagradas em muitas empresas.
Novamente, no h menosprezo algum em dizer que o mais importante o cdigo que atende
aos processos de negcios. Durabilidade essencial: imagine qualquer empresa perdendo
todos os seus dados. A continuidade do prprio negcio est em risco. Mas mais importante
do que os dados em si est o uso que se faz deles.
28
Sistemas tradicionais que vm sendo desenvolvidos nas ltimas dcadas sempre tiveram como premissa em seus dados sua corretitude (grau em que o software executa suas funes de modo correto).
Isso normalmente implicou na utilizao de um banco de dados que pudesse satisfazer as propriedades ACID.
Com o aumento da quantidade de informaes e usurios nas aplicaes, o fator disponibilidade passou em alguns casos a ser mais importante do que a prpria consistncia das informaes.
Alm do ACID, surgiu o acrnimo BASE (Basically Available, Soft state, Eventually consistent) traduzido literalmente como Basicamente Disponvel, Estado fl exvel e Eventualmente consistente. O BASE
tornou-se uma sigla bastante comum ao lidar com bancos de dados no relacionais.
Uma refl exo que vale a pena ser feita : para os novos desafi os e empreitadas que vocs, futuros
profi ssionais, enfrentaro, em quais situaes o ACID recomendado e em quais outras situaes o
BASE mostra-se mais adequado?
Referncia: <http://queue.acm.org/detail.cfm?id=1394128>. Acesso em 15 jul. 2012.
29
Papis assumidos pelos usurios de SGBDs

Desenvolvedores de SGBDs
So pessoas que projetam e codificam os SGBDs. Exemplos de pessoas nestes papis incluem os funcionrios de
empresas como Oracle, IBM e Microsoft que atuam diretamente na programao do software SGBD. No caso de
SBGDs livres, podem ser tambm voluntrios ou pessoas
e empresas interessadas na evoluo do software. Normalmente so programadores altamente qualificados que
trabalham no cdigo-fonte do SBGD. Mas voluntrios de
projetos de software livre tambm podem contribuir em outras atividades como documentao, por exemplo.
Desenvolvedores de aplicaes e
Administradores de Bancos de Dados (DBAs DataBase Administrators)
So pessoas que desenvolvem software que armazena

as informaes num SGBD. Tradicionalmente, em abordagens mais tradicionais e conservadoras, as equipes de
desenvolvimento so separadas em desenvolvedores e
DBAs. Os primeiros desenvolvem o software que acessa
o SGBD. Os segundos projetam os bancos de dados e os
mantm. Em abordagens de desenvolvimento mais modernas tende-se a eliminar esta distino entre os papis,
pois quanto maior a distncia entre os membros da equipe envolvidos no projeto de software, menor tende a ser a
qualidade do software entregue.
Usurios finais
So pessoas que no interagem diretamente com os

bancos de dados, e sim com as aplicaes criadas pelos
desenvolvedores de software que armazenam suas informaes em SGBDs. A maioria das pessoas enquadra-se
nesta categoria, e embora sejam os grandes beneficiados
pela tecnologia dos sistemas de bancos de dados, raramente possuem cincia do fato.
30
<http://youtu.be/Car5V9l8BiQ>.
Klaus Wuestfeld Prevayler
Neste vdeo Klaus Wuestfeld, um dos pioneiros do XP (eXtreme Programming) no Brasil e criador do
conceito de prevalncia de objetos, mostra uma abordagem inovadora e de alto desempenho para
manipulao e persistncia de objetos. Atualmente, alguns dos sistemas de transaes mais rpidos
do mundo utilizam este conceito.
vANtAgENS DE SE utiliZAr um SgBD

Durante as sees anteriores, j citamos algumas vantagens de se utilizar um SGBD para
armazenar as informaes de nossas aplicaes. A seguir, as enumeraremos de um modo
mais detalhado, de forma a justificar seu uso numa diversidade de situaes.
Diminuir a redundncia e fornecer consistncia
Imagine uma situao bastante comum: voc resolve elaborar um documento e necessita da
colaborao de vrias pessoas para faz-lo. Voc ento cria o esboo deste documento e o
envia por e-mail a todos os interessados. Cada pessoa realiza as suas modificaes em suas
prprias cpias dos documentos e depois repassa novamente por e-mail. Quem tem a ltima
verso do documento? Quais so os dados corretos? Estas so perguntas difceis de serem
respondidas nesta abordagem, e provavelmente exigir muito trabalho manual para se chegar
verso final do documento.
Um SGBD centraliza todas estas informaes, fazendo com que todos os usurios acessem
os mesmos dados. Desse modo, diminui-se a redundncia: h somente uma cpia dos dados
31
a serem manipulados. Isto permite tambm que o banco de dados sempre permanea num
estado consistente, pois todos os usurios tero sempre a ltima verso dos dados. No h
a possibilidade de algum permanecer com um pedao dos dados antigos e outro pedao
com a informao atual.
Controle de acesso
Muitas informaes armazenadas em sistemas so confidenciais. Ao mesmo tempo,
necessrio que esta informao seja compartilhada com as pessoas para que sejam
trabalhadas. Ao utilizar arquivos, necessrio que uma cpia seja enviada aos interessados.
Por mltiplos motivos, essas cpias podem acabar sendo enviadas por e-mail a pessoas
cujo acesso indevido; ou a mesma pode ser deixada num dispositivo de armazenamento
removvel esquecido em alguma mesa de reunio.
No mnimo um SGBD oferece uma combinao de login/senha para acesso a um determinado
banco de dados. Outras restries relativas a qual usurio pode acessar quais dados tambm
costumam ser implementadas pela maioria dos SBGDs. Como o acesso centralizado,
tambm tem-se uma nica cpia para proteo.
Consultas eficientes
Como so aplicaes de software de propsito especfico, os SGBDs so especialmente
projetados para armazenar eficientemente os dados a eles delegados; e para permitir formas
de consulta eficientes aos mesmos dados. Cada SGBD possui sua estratgia interna para
transformar estas informaes em bytes gravados no dispositivo de armazenamento, mas de
um modo geral, no h uma grande diferena de desempenho entre diferentes produtos em
uma quantidade razovel de aplicaes.
Em casos de usos tpicos, muito mais importante a eficincia em consultas do que a
eficincia em armazenamento de informaoes. Assim, os SBGDs utilizam dispositivos como
ndices (que so estruturas criadas para otimizar consultas baseadas em certos critrios) e
32
cachs (caches) para armazenar em memria os dados mais frequentemente acessados.

Estes dispositivos permitem que as consultas possam ser executadas de modo mais rpido, e
em muitos SGBDs, adequar estes dispositivos de modo otimizado chega a quase ser uma arte,
tamanha a quantidade de opes disponveis.
Backup e Restore
Para garantir a continuidade dos negcios, essencial executar periodicamente o backup das
informaes armazenadas no servidor. Ao invs de cpias fsicas dos arquivos do SGBD,
comum os prprios SGBDs fornecerem ferramentas que permitem a exportao dos dados
para um formato intermedirio (texto ou binrio) para backup. Estas mesmas ferramentas
suportam a restaurao destes dados em caso de necessidade.
As rotinas de backup/restore tambm so uma ferramenta bastante til na migrao ou cpia
de servidores onde o mesmo SGBD esteja instalado. Situaes de migrao costumam ocorrer
em caso de falhas ou upgrade de equipamento. Cpias costumam ser utilizadas para permitir o
teste de aplicaes em desenvolvimento.
CONSIDERAES FINAIS
Nesta unidade, pudemos perceber que os bancos de dados so uma coleo de dados
relacionados que representam, por meio de um nvel determinado de abstrao, o modelo
do mundo real de nossas aplicaes de software. Boa parte das aplicaes de software
desenvolvidas na atualidade envolve a manipulao, e principalmente, o armazenamento dos
dados estes muitas vezes em enormes quantidades. Para manipular estes bancos de dados,
criou-se uma categoria de software especfico denominada de sistemas gerenciadores de
bancos de dados (SGBDs). O banco de dados (os dados) e o sistema que o gerencia so
denominados conjuntamente de sistemas de bancos de dados.
Durante esta unidade tambm descrevemos as caractersticas 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 utilizao de arquivos como meio de armazenamento das informaes. Mas com as
informaes que detalhamos como caractersticas destes sistemas de banco de dados,
esperamos que voc, como desenvolvedor(a) possa ter argumentos suficientes para decidir
33
adequadamente entre uma abordagem e outra.

Como existem muitos tipos de usurios diferentes que podem interagir com os sistemas de
bancos de dados, tambm apresentamos uma lista no exaustiva dos papis que estes usurios
podem assumir nestas interaes. Uma mxima que devemos sempre utilizar a tcnica do
espelho. Olhe sempre para o software que voc desenvolve por meio dos olhos de quem usa.
Compreender as situaes em que cada tipo de usurio interage com um sistema de banco
de dados permite que tenhamos uma conscincia melhor das dificuldades e das necessidades
que os usurios 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 relao implementao de aplicaes sem a facilidade e funcionalidade de
um SGBD. Claro que, tendenciosamente, um estudioso de sistemas de bancos de dados
observaria argumentos bastante positivos em relao abordagem dos SGBDs. O papel de
um desenvolvedor experiente distanciar-se destes apegos a uma determinada tecnologia ou
outra e decidir sobriamente qual a soluo mais adequada para a sua aplicao.
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 tpicos sero abordados em nossa
prxima unidade.
ATIVIDADE DE AUTOESTUDO
1. Transaes tradicionalmente so melhor entendidas por meio do conjunto de suas propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade). Em quais situaes da vida real voc consegue enxergar a necessidade de se executar operaes
com estas propriedades?
2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparao com a
utilizao de arquivos para armazenamento dos dados. Tendenciosamente, o SGBD
apareceu como o vencedor nas comparaes. Quais seriam as situaes em que os
arquivos seriam uma soluo mais adequada? Voc consegue exemplificar alguma
outra situao em que uma terceira alternativa seria mais vivel?
3. Pense no SBGD como um mdulo do sistema ou como uma outra aplicao a ser integrada (pois em muitas concepes modernas, assim que ele deve ser tratado). Uma
das caractersticas dos SGBDs o isolamento entre o programa e os dados. Quais
os benefcios deste isolamento? Em que outras partes do sistema esta caracterstica
tambm pode trazer benefcios?
34
Banco de Dados na Nuvem
Jin Zhang, Diretor de Programas da IBM
Profi ssionais de dados esto adotando conceitos de computao em nuvem para oferecer bancos de
dados como um servio facilitando as difi culdades de gerenciamento e enviando usurios para a
nuvem nove.
Leva semanas para confi gurar um novo banco de dados. Preciso dele agora!
Nossos dados de desenvolvimento/teste esto uma baguna. Por que eles nunca so limpos?
Qualquer uma dessas reclamaes soa familiar? Provavelmente sim, se voc for um profi ssional de
dados em uma grande empresa. Os departamentos de TI dos dias de hoje so afetados por uma lista
no processada de demandas de administrao de dados. De solicitaes por novos bancos de dados
de desenvolvimento e teste de aplicativos at o backup e a restaurao 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 - respondendo a solicitaes de usurios com tarefas sem parada de banco de dados, clone, banco de
dados, clone - algumas organizaes esto tomando emprestado conceitos de autoatendimento do
domnio de computao em nuvem e indo em direo a um modelo de banco de dados como servio
ou DBaaS, em que usurios podem simplesmente acessar uma nuvem e capturar um banco de
dados conforme necessrio.
uma ideia provocante principalmente para usurios fi nais. Desenvolvedores de sistemas e de
software adoram o controle que eles obtm com recursos de autoatendimento de DBaaS. Quando eles
esto 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 viso uma realidade, no entanto, os profi ssionais de dados nos bastidores devem
realizar uma quantia considervel de trabalho no backend. Desenvolver uma nuvem de dados privada
35
e lanar com sucesso DBaaS para usurios finais requer que DBAs considerem diversos fatores, entre eles a infraestrutura de hardware subjacente da nuvem, as boas prticas de dados abrangentes
a serem implementadas e replicadas pela nuvem e, por fim, a interface de servios que trar todos
esses itens de forma transparente aos usurios finais para concluir a imagem.
Nossos dados de desenvolvimento/teste esto uma baguna. Por que eles nunca so limpos?
Penetrando as nuvens
Computao em nuvem refere-se a uma categoria de solues de tecnologia que permite que usurios acessem recursos de computao (neste caso, recursos de dados) on demand, conforme necessrio, sejam os recursos fsicos ou virtuais, dedicados ou compartilhados e independentemente
de como so acessados (por meio de uma conexo direta, rede local [LAN], rede de longa distncia
[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 armazenamento, imagens virtuais, esquemas de banco de dados e mais e disponibilizar essa nuvem a
usurios por meio de uma interface de servios.
Quando esta infraestrutura estiver instaurada, medida que necessidades de banco de dados surgem, os usurios podem simplesmente ir para a nuvem, solicitar os recursos que requerem e obter
acesso instantneo a seu prprio banco de dados pessoal on demand. Quando eles no precisarem
mais dos ativos de dados, os ativos so reciclados de volta na nuvem para redesignao, em vez de
serem deixados desperdiados e inativos.
Figura 1. Uma infraestrutura otimizada para entrega em nuvem do banco de dados enfatiza
simplicidade e eficincia por meio de automao e normatizao de hardware.
36
Etapa um: Desenvolver a base da nuvem

Sua primeira parada no caminho para construir um ambiente de computao 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 decises de hardware provavelmente no ocorrero em um vcuo. 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 hardware. Esse processo pode requerer concesses de todos os lados, portanto, tente entrar na conversa
com um entendimento claro de suas principais prioridades de hardware e as boas de ter. No tem
certeza de quais devem ser essas prioridades? Leia adiante.
Como em qualquer deciso de compra de hardware, muitos atributos afetaro a discusso plataforma, 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 possvel. Como muito
mais fcil automatizar um script em execuo em um sistema aberto homogneo do que muitos scripts
diferentes em um heterogneo, a normatizao a chave para automao. DBaaS em seu mago
nada mais que automao a automao do processo de configurao 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 opes de armazenamento disponveis 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, recuperao 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, crtico entender exatamente do
que capaz - e o que possvel passar a seus usurios finais. Se voc usar uma base de armazenamento que tenha recursos excepcionais de confiabilidade, disponibilidade e capacidade de manuteno (RAS), por exemplo, estar mais bem equipado a fornecer bancos de dados na nuvem que so
resilientes e altamente disponveis tambm.
Etapa dois: Identificar cargas de trabalho comuns e melhores prticas
O prximo estgio de planejamento de DBaaS fornece a voc, como um profissional de dados experiente com conhecimento ntimo dos funcionamentos internos de sua organizao e suas estruturas
de dados, a chance de brilhar. A etapa mais crtica para a entrega de DBaaS que realmente traz valor
a seus usurios finais decidir antecipadamente o tipo de modelos e imagens de banco de dados que
devem ser disponibilizados na nuvem. Para tomar tais decises, voc deve identificar as cargas de trabalho comuns e os processos chaves que ocorrem em seu ambiente de negcios e coletar melhores
prticas. Esses so os principais candidatos para automao e entrega por meio de DBaaS e a chave
para seu lanamento bem-sucedido.
Por exemplo, os DBAs podem trabalhar juntamente com os gerentes de linha de negcios para identificarem os conjuntos de dados que precisam ter e usarem essas informaes para criarem modelos
de bancos de dados que conectem de forma eficiente a sistemas front-end, funcionem bem com ferramentas 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
contm os dados mais recentes, informaes atualizadas no minuto e estruturas de dados - sem criaBANCO DE DADOS | Educao a Distncia
37
rem as difi culdades de administrao de dados de mudanas de esquema, mapeamento, migrao

de dados e mais.
Em outros ambientes corporativos, DBAs podem escolher imagens de bancos de dados - frequentemente incorporando metadados especfi cos do segmento de mercado e dados de referncia - como
candidatos para automao. Um DBA familiarizado com os requisitos de negcios pode isolar uma instncia de um banco de dados de produo que contenha um conjunto crtico de tabelas, visualizaes,
acionadores e procedimentos armazenados - assim como dados de referncia chave - para criar uma
imagem de banco de dados para ser automatizada por meio de DBaaS. Quando os negcios solicitam
um banco de dados para suportar uma nova fi lial ou para testar um aplicativo, no haver nenhuma
necessidade de esperar semanas enquanto DBAs o constroem. Em vez disso, ele estar disponvel
instantaneamente por meio de DBaaS na nuvem.
Etapa trs: Estabelecer um modelo de entrega
Agora que voc decidiu sobre a sua infraestrutura de hardware e identifi cou os processos e procedimentos a serem automatizados por meio de DBaaS, sua etapa fi nal ser trabalhar com usurios fi nais
para educar e ajudar os mesmos a selecionarem a interface por meio da qual esses servios de dados
sero disponibilizados.
H trs mtodos principais de acesso a DBaaS: por meio de uma interface grfi ca com o usurio
(GUI), uma interface da linha de comandos (CLI) ou diretamente por meio de uma interface representational state transfer (REST) padro. Qual interface ser empregada por fi m depender muito
da preferncia do usurio fi nal. Por exemplo, enquanto a GUI a abordagem mais fcil e simples
das trs, se os usurios fi nais j utilizarem aplicativos que empregam CLI, pode ser que no queiram
alternar. Como alternativa, os usurios podem querer eliminar a necessidade de interveno humana
inteiramente e promover uma integrao mais forte com seu ambiente, programando aplicativos para
se comunicarem diretamente com DBaaS por meio de REST. Quando se sabe as opes, possvel
trabalhar com seus usurios e ajudar a gui-los para a interface de DBaaS mais adequada para seus
desejos e necessidades especfi cos e juntos selecionar o wrapper que unir todo o pacote DBaaS.
uma nuvem com um raio de esperana
No nenhum segredo que gerenciar os valores de dados em rpida expanso e as necessidades
de administrao de banco de dados das grandes empresas dos dias de hoje uma grande proeza.
DBAs tm uma tarefa dura e no h outra maneira de descrever isso. A boa notcia que com DBaaS,
os profi ssionais de dados esto em uma posio exclusiva no somente de darem aos usurios fi nais
novos nveis de liberdade e servio, mas tambm para sarem 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 esperana, isso praticamente o melhor que se
pode obter.
Fonte: <http://www.ibm.com/developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBaaS/>. Acesso em: 14 ago. 2012.
38
UNIDADE II
OS BANCOS DE DADOS E O SOFTWARE

Apresentar as definies fundamentais de sistemas de bancos de dados.
Descrever as arquiteturas de bancos de dados e suas caractersticas.
Plano de Estudo
Conceituar schemas, instncias, abstraes e as interfaces de interao com
o SGBD
Estudo do histrico das arquiteturas de computao em geral e de sistemas
de banco de dados
Classificao dos diferentes tipos de banco de dados de acordo com suas
caractersticas
INTRODUO
Nesta unidade, apresentaremos alguns conceitos fundamentais que sero utilizados nas demais
unidades. Para compreender adequadamente os sistemas de banco de dados, necessrio
diferenciar adequadamente os modelos das instncias dos modelos pois possuem ciclos de
vida e finalidades bastante distintas.
Diferentes tipos de interface de usurio so disponibilizadas para diferentes tipos de usurios
em vrios produtos diferentes comercializados no mercado. Apresentaremos algumas delas
para que voc, desenvolvedor(a), possa explor-las posteriormente.
Entender como podem ser construdos sistemas com SGBDs implica em conhecer tambm a
histria da arquitetura de sistemas de computao, que evoluram do monoltico at o distribudo
em camadas. Cada gerao possui suas particularidades, que tambm so refletidas na
construo dos diferentes SGBDs.
Apresentaremos tambm alguns critrios de classificao 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.
41
SCHEMAS, INSTNCIAS E ABSTRAES

Uma caracterstica fundamental de qualquer modelo de software (o que inclui o banco de
dados) o seu nvel de abstrao. impossvel conseguir modelar todos os aspectos do
mundo real numa aplicao. 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 abstrao dos dados do mundo real. Um modelo de dados
uma coleo de conceitos que pode ser utilizada para descrever a estrutura de um banco
de dados. Por meio desses conceitos, conseguimos alcanar a abstrao necessria para
construir o nosso modelo de software.
Em qualquer modelo de dados, importante distinguir aquilo que representa a descrio do
banco de dados com o banco de dados em si. A descrio 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
frequncia. 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. Tambm definido como o estado atual de todas as instncias no banco de
dados. Uma instncia um item dentro do banco de dados que segue as definies de seu
schema correspondente.
A distino 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 aps criado representa um snapshot inicial vazio. Ao
manipularmos este banco de dados com operaes de insero, alterao e remoo, ns
modificamos o snapshot. O SGBD responsvel por garantir a consistncia do snapshot em
O plural correto de schema schemata, mas praticamente no utilizado. Na rea de tecnologia da informao,
costuma-se utilizar o plural schemas, mesmo sendo errado.
42
qualquer momento do tempo.

No uma operao usual ter que realizar modificaes no schema, mas elas so realizadas
toda vez que uma mudana nos requisitos do negcio demanda uma alterao no modelo de
dados. Este conjunto de alteraes para acomodar mudanas no software denominado de
schema evolution.
INTERFACES DOS SGBDS

Algumas das interfaces do SGBD com o usurio so:
Linha de Comando
Sem dvida nenhuma a linha de comando a interface mais poderosa e

flexvel para a interao do usurio com o SGBD. Por este mesmo motivo,
normalmente no uma opo que a maioria considere como amigvel.
Mas desenvolvedores devem sem dvida nenhuma domin-la para poder
explorar os recursos do mesmo.
43
Interfaces Web
44
Muitos SGBDs fornecem interfaces Web que podem ser acessadas por
meio de qualquer navegador para a administrao e manipulao dos bancos de dados. Embora no sejam to poderosas ou produtivas, so bastante amigveis e possuem ainda a vantagem da disponibilizao do acesso.
Muitos administradores de rede no se sentem confortveis em permitir o
acesso direto ao banco de dados, mas no se importam em liberar o acesso por meio de HTTP (Web).
Interfaces Desktop
So to amigveis quanto as Interfaces Web, mas costumam fornecer capacidades de manipulao grfica de diagramas. Isso auxilia os desenvolvedores a enxergar os relacionamentos entre as entidades do banco de
dados.
45
Interfaces baseadas
em formulrios
O Oracle Forms um exemplo clssico desta interface, tpica de sistemas

implementados utilizando-se triggers e stored procedures. Os usurios finais conseguem executar seus processos de negcios por meio da prpria
interface do SGBD, preenchendo formulrios 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 prpria histria da arquitetura
de sistemas de computao em geral. De fato, ao mesmo tempo em que as aplicaes e os
modelos de arquitetura de aplicaes evoluram, tambm evoluram os sistemas de banco de
dados. Dentre os fatores que influenciaram estas evolues esto o aumento da capacidade
de processamento, o aumento da capacidade de armazenamento, o aumento da quantidade e
capacidade das redes de comunicao, a reduo de custo dos equipamentos, o aumento do
nmero de usurios, o aumento da quantidade de informaes e a universalizao do acesso.
No h como explicar adequadamente as arquiteturas de sistemas de banco de dados sem
descrever conjuntamente as arquiteturas de sistemas de computao em geral. Nas prximas
sees, apresentaremos e descreveremos concomitantemente estas diferentes arquiteturas,
da centralizada at o modelo em camadas.
46
MODELO CENTRALIZADO
Os primeiros modelos computacionais eram centralizados, baseados num nico mainframe
fornecendo processamento, armazenamento e interface de interao com o usurio no
mesmo equipamento/aplicao. Raros eram os mainframes (devido ao seu alto custo) e por
consequncia tambm poucos eram os usurios que tinham acesso a aplicaes baseadas
em mainframe. A interao dos usurios com as aplicaes era realizada por meio de terminais
burros, que no possuam poder de processamento: somente teclado; e exibiam telas geradas
no prprio mainframe e transmitidas at o monitor (usualmente de fsforo verde ou amarelo)
por meio de um cabo de comunicao. A Figura 1 retrata um tpico sistema centralizado
baseado em mainframe.
Mainframe
Terminal
Burro
Terminal
Burro
Terminal
Burro
Figura 1
Fonte: o autor
47
Costumamos retratar este modelo de computao como monoltico, pois todas as atividades
eram baseadas no mainframe. Naturalmente, as aplicaes desenvolvidas para este tipo de
equipamento tambm foram concebidas e implementadas de modo monoltico. Isso significa
que no havia uma distino clara entre o que era interface com o usurio ou o que era
cdigo de negcios ou cdigo responsvel pelo armazenamento de dados. Esta situao
denominada de sistema altamente acoplado, pois qualquer alterao numa pequena parte
do sistema costuma levar a vrias outras alteraes em cascata para diversas outras partes
do sistema.
Os bancos de dados eram ento extenses da prpria aplicao e eram baseados nos modelos
hierrquicos e em rede, que sero apresentados adiante.
Modelo cliente/servidor
Com a popularizao dos PCs e o declnio de seus preos, iniciaram-se as primeiras
implantaes da arquitetura cliente/servidor. A ideia que ao invs de termos um grande
equipamento monoltico (mainframe), passamos a ter vrios equipamentos menores (e de custo
e capacidade inferior) com propsito especfico (banco de dados, arquivos, e-mail, impresso
etc.) interligados por meio de uma rede de comunicao. Cada servidor tornou-se um servio
especializado (embora no seja incomum agrupar vrios servios num nico equipamento,
dependendo da convenincia).
Os clientes, que tambm so PCs, podem acessar os recursos disponibilizados por estes
servidores por meio de rede. A Figura 2 mostra um esquema simplificado da arquitetura
cliente/servidor.
48
Servidor
PC
Servidor
PC
PC
Servidor
PC
Figura 2
Fonte: o autor
Em termos de arquitetura das aplicaes, denominamos o modelo cliente/servidor como modelo

de 2 camadas, respectivamente camada cliente e camada servidor. No lado cliente costumase implantar os recursos da aplicao relacionados interface com o usurio, enquanto no
lado servidor implanta-se a lgica de negcios, armazenamento e controle transacional. Este
modelo tornou-se extremamente popular no final da dcada de 1980 e incio da dcada de 1990,
e com ele tambm popularizou-se a prtica do desenvolvimento de aplicaes utilizando-se
triggers e stored procedures dentro do prprio SGBD. Cada cliente estabelece uma conexo
remota ao SGBD, que passa a executar a lgica de negcios, armazenar os dados e controlar
as transaes.
O modelo cliente/servidor bastante adequado quanto s aplicaes que possuem um nmero
limitado de usurios concorrentes (de 100 a at 300 ou 400 usurios). A partir deste nmero,
49
o desempenho desta arquitetura degrada-se consideravelmente, e o particionamento e

distribuio dos sistemas de banco de dados (escalabilidade horizontal) costuma ser bastante
dispendioso. Naturalmente, h um limite tambm para a troca do equipamento por um maior
(escalabilidade vertical). Surgiram ento os modelos de 3 camadas para tentar resolver este
problema.
Modelo de 3 Camadas ou N-Camadas
Aplicaes baseadas na Internet (web) costumam adicionar uma camada de software adicional
entre o cliente e o SGBD, como ilustrado na Figura 3.
PC
PC
Servidor de
aplicao
PC
Servidor de
aplicao
Servidor de Banco
de Dados
Figura 3
Fonte: o autor
50
PC
Esta camada intermediria denominada de camada de aplicao, e responsvel pela

execuo da lgica de negcios. Separa-se ento em 3 papis distintos cada camada: a
camada mais prxima do usurio responsvel pela interface e interao com o usurio;
a camada intermediria responsvel pela lgica de negcios; e a camada do SGBD
responsvel pelo armazenamento dos dados. Como idealmente a camada de aplicaes
projetada de modo stateless (sem estado), a replicao horizontal torna-se bem mais simples
do que no modelo cliente/servidor. Toda a lgica de negcios que anteriormente era codificada
utilizando-se triggers e stored procedures passa a ser executada na camada intermediria
utilizando-se uma linguagem de propsito geral. A quantidade de conexes de rede com o
SGBD tambm diminui, pois agora os usurios no o acessam diretamente esta tarefa passa
a ser responsabilidade da camada de aplicao.
Outras arquiteturas costumam subdividir a camada intermediria em outras 2 ou 3, criando
aplicaes de 4, 5 ou N camadas. Podemos adicionar camadas de validao, auditoria,
comunicao distribuda etc. A quantidade de camadas fica a gosto do arquiteto que projeta a
arquitetura, mas a filosofia de todo este processo de diviso de camadas segue os princpios
j apresentados.
Este modelo de camadas o modelo utilizado atualmente para suportar a imensido de dados
e usurios das aplicaes de Internet contemporneas.
O maior evento da comunidade de desenvolvedores do Brasil e referncia para profi ssionais iniciantes
ou experientes nos mais variados assuntos, incluindo Arquitetura de Software, Banco de Dados, NoSQL e Cloud Computing:
<http://www.thedevelopersconference.com.br/>.
51
Foto: SHUTTERSTOCK.COM
Sem Banco de Dados
Nos Estados Unidos, em 1920, a manufatura, venda e importao de bebidas alcolicas foram proibidas por emenda constitucional. Esta emenda foi revogada treze anos depois. Durante aquele perodo
de proibio, a indstria de cerveja morreu.
Em 1933, quando a proibio foi encerrada, algumas gigantes empresas de gros comearam a produzir cerveja. Eles monopolizaram completamente o mercado. E por quase 50 anos, ns nos Estados
Unidos bebemos este lquido encorpado efervescente e o chamado de cerveja. O nico modo de
tolerar o sabor era beb-lo bem gelado.
Como um adolescente nos anos 60, eu nunca entendi a atrao. Por que cerveja? Era um fl uido plido, amarelo e desagradvel derivado da urina de javalis doentes, e no possua nenhuma qualidade
que eu pudesse observar.
Em 1984, eu fui Inglaterra; e as escamas caram dos meus olhos. Finalmente pude entender. Pela
primeira vez eu pude provar cerveja; e eu gostei.
Desde aqueles dias a situao da cerveja nos Estados Unidos melhorou dramaticamente. Novas
52
cervejarias esto sendo criadas por todo o pas; e em muitos casos a cerveja realmente boa. Ainda
no temos nada to bom quanto a cerveja inglesa; mas estamos chegando l.
Nos anos 80 algumas poucas gigantes empresas de banco de dados monopolizaram o mercado.
Elas o fizeram ao promover o medo, incerteza e dvida entre gerentes e profissionais de marketing. A
palavra relacional tornou-se sinnimo de bom; e quaisquer outros mecanismos de armazenamento
de dados foram proibidos.
Eu era o lder de equipe de uma startup naquele tempo. Nosso produto media a qualidade de linhas
de comunicao T1. Nosso modelo de dados era relativamente simples, e ns mantnhamos os dados
em arquivos texto. E funcionava bem.
Mas nosso responsvel pelo marketing continuou insistindo que precisvamos utilizar um banco de
dados relacional. Ele disse que os clientes iriam demandar um banco de dados relacional. Eu achei
tudo aquilo um pedido estranho pois ns no tnhamos vendido nenhum sistema at aquele momento,
e nenhum cliente havia sequer questionado a nossa tecnologia de armazenamento de dados. Mas o
cara do marketing foi taxativo. Ns teramos que utilizar um banco de dados relacional. Arquivos texto
estavam proibidos.
Como lder de equipe, e responsvel pela qualidade do software, minha viso de um banco de dados
relacional era que ele seria um trambolho grande, indigesto, lento e caro. Ns no tnhamos consultas
complexas. Ns no precisvamos de relatrios com anlises massivas. Certamente no precisvamos de um processo com mltiplos megabytes consumindo memria e desperdiando ciclos de
processamento (lembrem-se, estvamos na dcada de 80). Portanto eu lutei contra esta idia com
todos os recursos que eu tinha; porque era a soluo tcnica errada.
Esta no foi uma jogada politicamente acertada para mim. Durante um perodo de vrios meses, um
engenheiro de hardware que tinha a capacidade de escrever algumas linhas de cdigo foi alocado na
equipe de software. Gradualmente ele foi recebendo mais e mais responsabilidade, e eventualmente
foi nomeado meu cogerente. Ele e eu iramos dividir a responsabilidade de liderar a equipe de
software.
Uh huh. Claro. Com certeza. Um cara de hardware com nenhuma experincia real em software iria me
ajudar a liderar a equipe. E qual voc acha que foi o primeiro problema? Foi o de inserir um banco
de dados relacional no nosso sistema!
Eu sa um ms depois e iniciei minha carreira de consultor. Foi a melhor mudana que fiz na minha
carreira profissional. A empresa que eu deixei no existe mais. E eu tambm acredito que eles nunca
faturaram um centavo sequer.
Eu assisti ao crescimento do mercado de banco de dados relacionais durante os anos 90. Eu assisti s
outras tecnologias de armazenamento de dados, como banco de dados de objetos, e banco de dados
B-tree morrendo; assim como as cervejarias nos anos 20. Ao fim dos anos 90, sobraram somente os
53
gigantes.
Estes gigantes estavam criando uma tempestade. Eles eram deuses. Eles eram soberanos. Durante a
bolha ponto com, um deles chegou a ter a audcia de comprar anncios de televiso que diziam que
seu produto era o poder que movia a Internet. Isto me lembrou de um comercial de cerveja dos anos
80 Ya gotta grab for all the gusto in life ya can. Meu deus.
Durante este perodo eu assisti com horror a como uma equipe aps a outra colocava o banco de dados no centro do seu sistema. Eles foram convencidos por um monte de propaganda que o modelo de
dados era o aspecto mais importante da arquitetura, e que o banco de dados era a alma e o corao
do seu projeto.
Eu testemunhei a criao de um novo tipo de emprego. O DBA! Meros programadores no eram confiveis o suficiente para guardar os dados assim diziam as propagandas. Os dados so to preciosos,
to frgeis, to facilmente corrompveis por estes palhaos indisciplinados. Ns precisamos de pessoas especiais para gerenciar os dados. Pessoas treinadas pelos fornecedores de banco de dados.
Pessoas que iriam garantir e divulgar a mensagem de marketing das grandes empresas de banco de
dados: que o banco de dados pertence ao centro. Ao centro do sistema, da empresa, do mundo e do
universo. MUAHAHAHAHAHAHAHA!
Eu assisti ao SQL ser enfiado em cada buraco e fenda do sistema. Eu fugi correndo de sistemas em
que o SQL havia contaminado a Interface do Usurio. Eu blasfemei incansavelmente contra a prtica
de se mover toda a lgica de negcios em stored procedures. Eu fraquejei, tremi, resmunguei e rugi
enquanto observava programas de mala direta sendo escritos em SQL.
Eu ataquei e ataquei medida que vi tabelas e linhas invadindo o cdigo-fonte sistema aps sistema.
Eu avisei sobre o perigo. Eu avisei que o schema havia se tornado o Blob, consumindo tudo sua
vista. Mas eu sabia que meus ataques eram como jogar pedrinhas num behemoth.
E ento, na primeira dcada no sculo 21, uma proibio foi revogada, e o movimento NoSQL nasceu.
Eu o considerei um milagre, uma luz brilhando no deserto. Finalmente, algum percebeu que pode
haver alguns sistemas no mundo que no necessitam de um grande, gordo, lento e caro porco devorador de memria chamado banco de dados relacional!
Eu assisti com alegria ao nascimento de BigTable, Mongo, CouchDB, e a todos os outros pequenos
sistemas de armazenamento de dados florescendo; assim como as pequenas microcervejarias nos
anos 80. A cerveja estava de volta! E estava comeando a ter um gosto bom.
Mas ento eu percebi algo. Alguns dos sistemas utilizando estes bons, simples e saborosos banco de
dados no relacionais estavam sendo projetados ao redor dos bancos de dados. Os bancos de dados,
encapsulados em reluzentes novos frameworks, ainda estavam no centro da concepo do projeto!
O veneno das campanhas publicitrias das empresas de banco de dados relacionais ainda estava
ecoando na mente dos arquitetos. Eles ainda estavam cometendo o erro fatal.
54
Pare!, eu gritei. Pare! Vocs no entendem. Vocs no entendem. Mas a inrcia era muito grande.
Uma enorme onda de frameworks cresceu e esmagou a nossa prpria indstria, levando tudo pelo
caminho. Estes frameworks encapsularam os bancos de dados e brigaram com unhas e dentes para
manter o centro de nossas aplicaes. Eles afirmavam que eram o senhor e mestre dos banco de
dados. Eles at alegavam serem capazes de transformar um banco de dados num banco de dados
NoSQL. E os frameworks gritaram com uma poderosa voz ecoada por toda a a terra: Dependa de
mim, e eu os libertarei!
---------O nome deste artigo Sem Banco de Dados. Talvez aps ler todas estas lamentaes voc possa
entender o porqu do ttulo.
O centro da sua aplicao no o banco de dados. Nem um ou outro framework que voc possa
estar utilizando. O centro da sua aplicao so os casos de uso da sua aplicao.
Eu enlouqueo quando ouo um desenvolvedor de software descrever o seu sistema como Um sistema no Tomcat utilizando Spring e Hibernate com Oracle. As prprias palavras colocam os frameworks
e o banco de dados no centro.
Com o que voc acha que a arquitetura desse sistema se parece? Voc acredita que os casos de uso
so o centro do projeto? Ou voc acha que encontrar o cdigo-fonte adaptado para encaixar nos
padres dos frameworks? Voc suspeitaria de objetos de negcios que parecem linhas de banco de
dados? Ser que o schema e os frameworks poluiriam tudo?
Isso como uma aplicao deve parecer. Os casos de uso devem estar no nvel mais alto e mais
visvel das entidades arquiteturais. Os casos de uso esto no centro. Sempre! Banco de dados e
frameworks so detalhes! Voc no tem que decidir utiliz-los prematuramente. Voc pode postergar
esta deciso, at que todos seus casos de uso e regras de negcios tenham sido elaborados, codificados e testados.
Quando a melhor hora de se determinar o seu modelo de dados? Quando voc j conhece quais
so as entidades de dados, como elas se relacionam, e como so utilizadas. Quando voc sabe isso?
Quando voc j tem todos os casos de uso e regras de negcios escritas e testadas. Neste momento
voc j ter identificado todas as consultas, todos os relacionamentos, todos os elementos de dados,
e estar capaz de construir um modelo de dados que encaixe perfeitamente no seu banco de dados.
Isso muda alguma coisa se voc estiver utilizando um banco de dados NoSQL? Claro que no! Voc
ainda focar em conseguir os casos de uso funcionando e testados antes de pensar no banco de
dados; no importa qual banco de dados voc acabe escolhendo.
Se voc envolve o banco de dados muito cedo, ele deturpar o seu projeto. Ele lutar para ganhar o
controle do centro da aplicao, e uma vez l ele guardar o centro como um cachorro bravo. Voc
tem que trabalhar duro para manter o banco de dados fora do centro de seus sistemas. Voc deve
55
continuamente dizer No tentao de envolver o banco de dados logo no incio.

Estamos nos aproximando de uma poca interessante. Uma poca em que a proibio contra diferentes mecanismos de armazenamento foi revogada e em que estamos livres para experimentar muitas
abordagens novas e inovadoras. Mas medida que brincamos com nossos CouchDBs, Mongos e
BigTables, lembrem-se: o banco de dados s um detalhe e voc no deve envolv-lo logo no incio.
Uncle Bob Martin o Mestre Arteso de Software da 8th Light. Ele um autor premiado, renomado
palestrante e super geek de software desde 1970.
Fonte: <http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html>. Acesso em: 12 ago. 2012.
Foto: SHUTTERSTOCK.COM
ClASSiFiCAO DOS SiStEmAS DE BANCO DE DADOS
Assim como na natureza, podemos utilizar vrios critrios diferentes para classificar os
sistemas de banco de dados. Alguns desses critrios bastante comuns so modelos de dados,
nmero de usurios, nmero de instalaes e custo. Nas prximas sees exploraremos como
utilizar esses critrios para classificao.
modelo de dados
No tenha dvidas: muitas pessoas relacionam o modelo relacional a banco de dados devido
sua absoluta onipresena. Um argumento costumeiro na escolha do modelo relacional
56
que ningum ser demitido por t-lo escolhido. De fato, antes do advento do termo NoSQL,
praticamente no havia outras opes a considerar.
Durante anos houve muita pesquisa e discusso sobre banco de dados orientado a objetos,
graas grande popularizao das linguagens orientadas a objetos. O pensamento da poca
era que o desenvolvimento de aplicaes seria muito mais simples se pudssemos utilizar
linguagens e banco de dados orientados a objetos juntos. Mas dois fatores foram decisivos
para que isso no acontecesse. Primeiramente, o modelo relacional j era algo absolutamente
consolidado e otimizado. Baseado em fundamentos matemticos extremamente simples, h
anos j havia obtido sua maturidade. Robustos e confiveis, j eram utilizados em grandes
aplicaes por empresas dos mais variados segmentos. O outro motivo foi que realmente os
bancos de dados orientados a objetos nunca se popularizaram comercialmente o suficiente
para criar um ecossistema rentvel ao redor de si. Atualmente, so raros os exemplos de
sistemas de banco de dados deste tipo e no possuem uma fatia que possa ser considerada
significativa do mercado.
Sistemas de bancos de dados mais antigos (particularmente os baseados em mainframe)
utilizam o modelo hierrquico ou o modelo em rede. Mas no se engane ao considerar
que aplicaes baseadas nestes modelos desapareceram. Grandes bancos so um segmento
tradicionalmente conservador em relao a tecnologias adotadas. fato que boa parte deles
ainda roda seus mais importantes sistemas em mainframes com sistemas de banco de dados
hierrquicos ou em rede. o caso, por exemplo, do Banco do Brasil. H uma cumplicidade:
mainframes garantem a sobrevida do modelo hierrquico e em rede, e as aplicaes baseadas
nestes modelos garantem a longevidade do mainframe.
H outros modelos de dados bastante recentes (os oriundos do NoSQL), como os baseados
em chave-valor, baseados em grafos, baseados em documentos etc. Esses modelos mais
recentes no sero abordados neste material.
57
Nmero de usurios
Em relao ao nmero de usurios, sistemas de banco de dados podem ser monousurios ou
multiusurios. Alguns raros exemplos atuais de banco de dados monousurios so os banco
de dados embarcados, que so projetados para serem pequenos e rpidos o suficiente para
serem embarcados dentro de uma aplicao. Alguns exemplos que poderamos considerar
so o Apache Derby e o H2. Mas mesmo estes dois SBGDs podem se comportar como
monousurio ou multiusurio, dependendo do seu tipo de instalao.
Naturalmente, a grande maioria dos sistemas de banco de dados modernos suporta mltiplos
usurios concorrentes com acesso mediante algum protocolo de rede.
Nmero de instalaes
Quanto quantidade de instalaes, podemos classificar os sistemas de banco de dados em
centralizados ou distribudos. Sistemas centralizados so aqueles em que h uma nica
instncia do sistema de banco de dados sendo executada. So apropriados para quantidades
pequenas de dados ou em situaes em que a disponibilidade do sistema no crucial ao
negcio.
Sistemas distribudos so aqueles em que h mais de uma instncia (com a possibilidade de
vrias) sendo executada. Em sistemas de banco de dados mais tradicionais, costuma-se utilizar
uma distribuio master-slave, em que as atualizaes de dados so efetuadas no master e
as leituras so efetuadas em um ou mais slaves. Como a maioria das aplicaes executa mais
leituras do que atualizaes, o desempenho pode aumentar de modo significativo. Outros
tipos de distribuies de banco de dados podem envolver particionamento (dividir os dados
em instalaes diferentes) e/ou replicao (duplicar os dados) para aumentar o desempenho
e/ou disponibilidade.
58
Custo
no critrio custo em que amplitude de diferena entre os sistemas de banco de dados
maior. Temos desde o gratuito at exemplares que podem custar alguns milhes de dlares.
No caso dos gratuitos, vale a pena distinguir entre os sistemas livres (software livre) e os
que representam verses reduzidas de produtos mais caros. Dois produtos livres bastante
populares so o MySQL (bem mais popular) e o PostgreSQL. O modelo de negcios de ambos
permite o livre uso e redistribuio; mas quando for necessrio o suporte, pode-se optar por
contrat-lo de uma empresa terceirizada ou do prprio fornecedor (Oracle), no caso do MySQL.
Ambos possuem graus de maturidade, estabilidade e funcionalidade bastante elevados e no
devem nada a desejar em relao aos produtos pagos. Provavelmente em mais de 90% dos
casos de uso de aplicaes tradicionais, no haveria diferena no uso entre um sistema de
banco de dados livre e outro pago. Nosso mercado consolidou-se a um ponto em que optar
entre uma soluo e outra passou a ser uma questo de gosto ao invs de uma questo
puramente tcnica.
Devido ao sucesso dos sistemas de banco de dados livres, produtos comerciais que
tradicionalmente eram bastante custosos passaram a oferecer verses gratuitas (limitadas
em nmero de processadores, quantidade de dados, instncias etc.). o caso de Oracle,
DB2 e SQL Server. Trata-se de uma estratgia comercialmente interessante, pois migrar de
um SGBD para outro no uma tarefa simples, e permitir que empresas avaliem e usem
seus produtos de modo gratuito pode ajudar na tarefa de aprisionar o cliente. Assim, uma
startup que inicie seus negcios com uma verso gratuita poder passar a pagar pelo uso dos
produtos mais completos quando a capacidade da verso gratuita for atingida. Nesse ponto
espera-se que a empresa j esteja com um faturamento considervel e provavelmente no se
importar com o investimento.
59
<http://youtu.be/piSbDWeu3pM>.
Luciano Ramalho MongoDB
Luciano Ramalho um dos grandes experts em linguagens de programao dinmica no Brasil, particularmente Python. Tambm um dos pioneiros em NoSQL e especialista em MongoDB, um banco
de dados de documentos. Neste vdeo, Luciano apresenta as vantagens e as aplicaes deste banco
de dados.
CONSiDErAES FiNAiS
Nesta unidade ns aprendemos a distinguir o schema, que um metamodelo do banco de dados,
de suas instncias. Alteraes no schema no costumam ser muito frequentes, enquanto que
as instncias so manipuladas por meio de operaes de insero, remoo ou atualizao.
A boa assimilao da distino entre schema e instncias um conceito fundamental para
o uso efetivo de um sistema de banco de dados alis, esta diferenciao entre modelo,
metamodelo e instncias do modelo algo bastante frequente na rea de software.
Existem diversos tipos de interfaces de interao dos usurios com o sistema de banco de
dados, e a escolha de qual interface utilizar depende muito do propsito e do papel do usurio
ao acess-lo. Sempre h a avaliao entre os quesitos poder versus facilidade de uso. A
prtica faz-se necessria para que um bom desenvolvedor possa escolher o meio de interao
mais adequado de acordo com a situao. Muitas vezes voc necessitar do poder da linha
de comando; noutros, alguns cliques numa interface desktop sero mais cmodos. O seu
conhecimento permitir que voc tome a deciso acertada.
A apresentao das arquiteturas de computao em geral e das arquiteturas de sistemas
de bancos de dados pde esclarecer a forma com que historicamente se desenvolve
estas arquiteturas de aplicaes. O artigo apresentado no saiba mais promove uma
reflexo importantssima para que voc possa ponderar sabiamente durante o processo de
desenvolvimento de suas aplicaes. Este autor concorda com a proposta do Uncle Bob
Martin, at porque vivemos um perodo em que muitos conceitos estabelecidos esto sendo
60
questionados. Poder desenvolver o seu software objetivando o valor de negcios e os seus

usurios muito mais importante do que quaisquer abstraes de armazenamento de dados
inclusive o banco de dados. Concentre-se naquilo que realmente importante para sua
aplicao e deixe o banco de dados como aquilo que ele realmente : um detalhe. Um detalhe
importante, verdade mas continua sendo um detalhe.
Finalizando esta unidade, pudemos listar alguns critrios diferentes para a classificao de
diferentes produtos de sistemas de bancos de dados. Diferentes fornecedores com diferentes
produtos apresentaro uma infinidade de argumentos para que voc decida entre um e
outro. Claro que os critrios comerciais influenciaro bastante sua deciso, mas a lista que
assimilamos nesta unidade poder lhe nortear com alguns argumentos importantes.
Nossa escalada para o domnio dos sistemas de bancos de dados passar na prxima unidade
para um novo degrau: o modelo relacional que em muitos casos j foi (ou ainda ) sinnimo
de banco de dados. Veremos o porqu de suas qualidades o tornarem to bem conceituado.
ATIVIDADES DE AUTOESTUDO
1. Defina os seguintes termos: schema, instncia, snapshot e schema evolution.
2. Qual a diferena entre sistemas de computao de duas e de trs ou N camadas, e como
os sistemas de banco de dados interagem com estes sistemas de computao?
3. Escolha um caso de uso da vida real para avaliar a implementao de um software.
Baseado(a) nos critrios descritos nesta unidade, quais seriam suas consideraes para
decidir entre um SGBD e outro?
61
vida longa ao mainframe: a trajetria de um baby boomer
Luiz Fadel, primeiro distinguished engineer da IBM no Brasil, conta sua experincia de 40 anos como
prossional especializado na tecnologia.
Poucos so os profi ssionais de tecnologia que conseguem sobreviver por tantos anos no mundo
corporativo, em meio s constantes transformaes provocadas pela era digital. Com a revoluo da
internet, TI passou a ser uma rea invadida e dominada, cada vez mais, pela intrigante gerao Y
formada por jovens entre 18 e 30 anos.
Vencer a linha do tempo um desafi o, principalmente porque as empresas vm privilegiando o sangue novo. Uma dura realidade que atinge quase todos os que tentam o mercado de trabalho. Neste
cenrio, difcil encontrar profi ssionais que tenham passado a casa dos 50, mas uma leva de executivos resiste bravamente.
So os chamados dinossauros da indstria de tecnologia no Brasil. No bom sentido, claro. O engenheiro eletrnico paulistano Luiz A. Fadel um deles. Formado em um dos mais renomados celeiros
de profi ssionais de engenharia do Pas, o Instituto Tecnolgico da Aeronutica (ITA), ele conta com
uma trajetria profi ssional mpar.
Assistiu aos efeitos da reserva de mercado - que protegeu a indstria nacional de informtica - e ao
sobe e desce de uma tecnologia que depois de altos e baixos continua forte no Brasil o mainframe.
Agora, aos 63 anos, e 40 de experincia em sistemas de grande porte, continua com o mesmo gs e
energia de quando comeou a carreira. Reconhece que ainda tem muitos anos de estrada pela frente.
Flego de causar inveja a qualquer um que tenha se formado j na era digital.
Desemprego no uma palavra que faz parte do vocabulrio dos especialistas em mainframe, afi rma Fadel. Nem mesmo para ns da gerao baby boomer. A falta de gente qualifi cada para atuar
com a tecnologia - que vive um momento de retomada no Brasil - tem trazido de volta ao mercado
muitos profi ssionais que j haviam pendurado as chuteiras.
62
Sem planos de sair de cena, o executivo conta um pouco de sua experincia ao longo de duas dcadas, toda construda na gigante IBM. Confira trechos da entrevista que Fadel concedeu Computerworld:
Computerworld - Sua carreira foi construda em uma das tecnologias mais antigas e que ainda continua forte no mercado, sobretudo o brasileiro. Que razo o levou apostar nessa rea?
Luiz A. Fadel - Sem dvida, h muitas oportunidades interessantes que o mercado de mainframe
oferece. Em todos os meus 40 anos de carreira, s lembro um momento crtico para os profissionais
dessa tecnologia. Na dcada de 90, com o auge dos PCs, a demanda por sistemas de grande porte
sofreu retrao. Quadro que anos depois teve recuperao.
Apesar dos percalos, a plataforma evoluiu bastante de 1964 (quando comecei) para c. No falo da
base dela, que permanece a mesma, mas do que adicionado a ela, exigindo do profissional estar
sempre se atualizando. Todo dia h coisas novas.
E engana-se quem pensa que o mainframe morreu. Pelo contrrio, um sistema que completa o
parque de muitas empresas por atender a necessidade de transaes mais robustas. Prova disso
que ainda existe uma forte demanda.
CW Desde que ingressou na IBM, que momentos o senhor elenca como os mais marcantes?
Fadel Quando entrei, em 1969, a empresa era umas das poucas - fora ela, existiam s outras duas
- a atuar com sistemas de grande porte, os conhecidos mainframes. Logo de cara tive o privilgio de
participar de projetos envolvendo grandes bancos brasileiros que, na poca, tornavam-se os maiores
consumidores da tecnologia. Tambm estive envolvido na primeira instalao do Mainframe Operating
Systems (Mainframe OS) no Pas, assim que fui promovido analista de sistemas.
CW Hoje acabou o tempo em que os profissionais vestiam a camisa da empresa. Como o senhor
enxerga a opo de ter feito carreira em uma nica companhia?
Fadel - Comecei como trainee em vendas, assim que sa da faculdade, e estou na empresa at hoje
porque sempre vi grandes oportunidades de ascenso profissional dentro da carreira tcnica. Nunca
precisei mudar de rumo para dar saltos. Tanto que hoje cheguei a um cargo equivalente ao de um
diretor com carreira em negcios, que a IBM chama de distinguished engineer.
o posto mais alto da empresa na rea tcnica. Na subsidiria brasileira, s trs profissionais tm
esse ttulo. Eu fui o primeiro a conquist-lo aqui, em 2003. No mundo, existem cerca de 200 pessoas
com o posto. Ou seja, uma grande realizao na carreira que no posso ignorar.
Tambm no podemos esquecer que a IBM sempre foi uma multinacional slida e de peso. Alm de
abrir as portas para que os funcionrios possam ter experincia profissional fora do Brasil. Eu mesmo
estive por duas vezes trabalhando nos Estados Unidos, somando um total de seis anos a primeira
fase entre 1977 e 1980; a segunda de 1988 a 1991.
Nos dois casos, em Poughkeepsie, ao norte do estado de Nova York, onde est o centro de pesquisa
da IBM, que rene os melhores especialistas da companhia do mundo. Isso quando ramos (os brasileiros) pouco respeitados, quanto ao aspecto tcnico, no exterior.
CW fato que, por um lado, existe uma forte demanda de projetos e por outro, poucos profissionais
para desenvolv-los. Esse quadro valoriza o profissional de mainframe, inclusive os mais seniores?
Fadel Sim. A falta de pessoal especializado em sistemas de grande porte enorme. No h gente
63
no meio da pirmide e quem possui experincia est empregado. Por isso a prpria IBM fi rmou parceria com as universidades do Pas para formar gente. Posso garantir que oportunidade o que no
falta para especialistas em mainframe. Na empresa, por exemplo, somos extremamente valorizados.
Detalhe: h espao para quem se aposentou e quer voltar e para quem no pretende pendurar as
chuteiras.
Fonte: <http://computerworld.uol.com.br/carreira/2009/09/03/vida-longa-ao-mainframe-a-trajetoria-de-um-baby-boomer/>. Acesso em: 1 ago. 2012.
64
UNIDADE III
O MODELO RELACIONAL
Conceituar o modelo relacional.
Conceituar as restries do modelo relacional.
Descrever as operaes de manipulaao de instncias do modelo relacional.
Plano de Estudo
Conceituar domnio, atributos, tuplas e relaes
Conceituar os diferentes tipos de restries do modelo relacional e de banco
de dados
Descrever as operaes de INSERT, UPDATE e DELETE do modelo relacional
e como elas interagem com as restries do banco de dados
INTRODUO
A partir desta unidade, abordaremos o modelo de dados relacional, que o modelo utilizado
nos bancos de dados relacionais. O advento do modelo relacional atribudo a Ted Codd da
IBM em 1970, e imediatamente se popularizou devido sua simplicidade e slidos fundamentos
matemticos: baseado na teoria geral dos conjuntos e em lgica matemtica.
Os primeiros SGBDs relacionais apareceram na dcada de 1980, sucedendo os bancos de
dados hierrquicos e em rede predominantes em mainframes. Desde ento, sua expanso
foi enorme, e acabou tornando-se sinnimo de banco de dados. Exemplos de produtos
populares so DB2 (IBM), Oracle e MySQL (Oracle), SQLServer (Microsoft) e PostgreSQL
(software livre).
Dada a relevncia do assunto, tanto esta quanto as prximas duas unidades focaro no modelo
relacional de dados. Nesta unidade, introduziremos alguns conceitos fundamentais do modelo
relacional tentando nos distanciar um pouco da teoria geral dos conjuntos e nos aproximando
mais do nosso mundo cotidiano.
67
CONCEITUAO
No modelo relacional, o banco de dados representado como um conjunto de relaes.
Podemos tentar entender uma relao como uma tabela ou uma planilha de clculo.
Observando como uma tabela, cada linha representa uma coleo de valores relacionados.
De fato, cada linha de uma tabela no modelo relacional costuma representar uma entidade do
mundo real ou um relacionamento entre duas entidades.
Contato
Nome
Sobrenome
Nascimento
Ademir
Santos
20/12/1984
Carlos
Silva
26/04/1970
Justino
Carvalho
11/07/1981
Marcela
Moreno
03/06/1999
Figura 4
Fonte: o autor
Observando a Figura 4, verificamos que a tabela se chama Contato, pois representa um

conjunto de contatos numa agenda pessoal. Cada linha da tabela representa uma instncia
de um contato real. Os nomes das colunas (Nome, Sobrenome, Nascimento) representam
informaes sobre um Contato. Dentro de uma determinada coluna, todos os dados possuem
o mesmo tipo (String, data, inteiro, real etc.).
Definido de modo formal, uma linha denominada de tupla, o nome de uma coluna
denominado de atributo e a tabela denominada de relao. O tipo de dado que pode ser
inserido em cada coluna denominado de domnio, e representa os valores possveis de cada
atributo.
Caractersticas de uma Relao
A seguir analisaremos as caractersticas atribudas a uma relao (tabela) no modelo relacional:
68
1. Ordem das tuplas. Como uma relao (tabela) representa a noo matemtica de
conjunto, relaes no possuem ordem. Isso significa que no h uma ordem natural
particular imposta dentro da relao. Como estes dados sero gravados em algum
dispositivo de armazenamento, natural que sequencialmente eles estejam dispostos em alguma ordem mas para efeitos do modelo relacional, deve-se assumir que
a ordem dos elementos catica. Durante o desenvolvimento de aplicaes, no
se deve assumir nenhuma premissa sobre a ordem dos elementos dentro de uma
relao.
2. Atomicidade dos valores e o valor NULL. No modelo relacional, cada valor de
cada atributo dentro de uma tupla atmico. Atmico no mesmo sentido de tomo
e em transaes: estes valores no podem ser divididos em outros componentes.
Assim, ao menos no modelo relacional puro, no so possveis valores compostos
ou mltiplos valores dentro de um mesmo atributo. Um conceito essencial e bastante
utilizado em atributos o valor definido como NULL. NULL um valor utilizado em
colunas para definir casos especiais em que: o valor pode no se aplicar quela
tupla; o valor no possui valor definido; ou o valor desconhecido. No caso da tabela
Contato, podemos definir como NULL o atributo Nascimento quando desconhecemos o dia em que nosso Contato nasceu.
3. Semntica de uma Relao. Relaes podem representar situaes factuais. Podemos considerar que cada tupla da relao Contato seja um fato: voc, no mundo
real, possui um Contato verdadeiro que pode ser abstrado com os dados daquela
tupla. Algumas relaes representam dados sobre entidades (como o caso de Contato). Outras relaes podem representar relacionamentos (como seriam os e-mails
ou os telefones de cada Contato). No modelo relacional, tanto entidades quanto relacionamentos entre entidades podem ser igualmente representados por relaes
(tabelas). Isto simplifica muito o modelo e sua utilizao, pois no precisamos de
notaes nem de ferramentas para fazer distino entre as entidades e os relacionamentos entre elas.
69
Bancos de dados livres crescem no Brasil
Uma nova gerao de bancos de dados livres comea a ganhar adeso de vrias empresas do setor
nanceiro e industrial do pas, revela estudo.
GENILSON CEZAR, ESPECIAL PARA COMPUTERWORLD
Uma nova gerao de bancos de dados livres comea a ganhar adeso de vrias empresas do setor
fi nanceiro e industrial do pas, para aplicaes especfi cas ou embarcadas em equipamentos de comunicao, e j est criando um impacto positivo entre os desenvolvedores.
Essa uma concluso do consultor independente Fernando Lozano, community manager da Java.
net, apresentada na quarta-feira (17/08) no Developers World 2005, realizado pelo IDG Brasil, no
Hotel Jaragu, em So Paulo.
Lozano vem trabalhando na implementao de projetos de banco de dados livres em vrias empresas
como o Instituto Brasileiro de Petrleo e Gs, Elephant Internet, iBest e Amsterdam Sauer. O banco
de dados livre hoje uma alternativa vivel e de alta performance, alm de comercialmente atraente,
pois pode utilizar qualquer ferramenta de desenvolvimento para acesso aos dados, diz ele.
Para Thiago Jos Macieira, desenvolvedor central do KDE, uma das principais comunidades de open
source do mundo, com quase 20 colaboradores brasileiros, o interesse pelo software livre no Brasil
cada vez maior, principalmente depois que o governo federal decidiu estimular a adoo do produto
em licitaes pblicas.
Muitos desenvolvedores esto decididos a contribuir para o avano do open source, mesmo sem ter
qualquer espcie de retorno fi nanceiro, no mximo um outro patrocnio para participar em congressos
internacionais, afi rma Macieira.
Fonte: <http://computerworld.uol.com.br/tecnologia/2005/08/18/idgnoticia.2006-05-15.4431159825/>.
Acesso em: 1 ago. 2012.
70
RESTRIES DO MODELO RELACIONAL

Restries no modelo relacional so uma forma de se restringir os valores que os atributos
das tuplas podem possuir num determinado snapshot. Essas restries podem ser derivadas
dos prprios relacionamentos do modelo relacional ou de restries de valores de negcios
impostos pelo modelo de software sendo desenvolvido.
Os tipos de restries do modelo relacional so de domnio, de chave e de valores nulos, e de
integridade e integridade referencial. Estas so descritas nas sees seguintes.
Restries de domnio
As restries de domnio impem ao banco de dados quais valores podem ser permitidos
em cada atributo dentro de cada tupla em cada tabela. Algumas destas restries podem
ser de tipo (voc no pode colocar um valor String num campo inteiro ou vice-versa). Outras
restries possveis podem restringir valores dentro de um tipo (somente os inteiros maiores
que zero). Exploraremos melhor estas restries de domnio quando tratarmos das restries
do SQL.
Restries de chave e de valores nulos
Como uma relao (tabela) representa um conjunto na definio formal da teoria dos conjuntos,
no h a possibilidade de uma relao conter elementos repetidos; pois num conjunto, todos
os elementos so distintos. Desse modo, havendo ou no a possibilidade de se haver registros
com dados semelhantes dentro do modelo de negcios, utiliza-se uma restrio denominada
de chave primria que define de modo nico cada registro dentro da relao. Esta chave
primria pode ser composta de um nico atributo ou mesmo de um conjunto de atributos.
No h verdades absolutas na rea de Tecnologia da Informao, mas no passado foi bastante
comum a utilizao de chaves primrias compostas para representar as tuplas de uma relao.
Matematicamente, no h diferena entre uma chave primria simples (um nico atributo) e
71
uma chave primria composta (mltiplos atributos). Baseando-se no princpio da Navalha de

Occam, preferimos optar pela soluo mais simples: chaves primrias simples.
Outra prtica atual diz respeito visibilidade por parte do usurio do valor da chave primria. Em
aplicaes legadas, bastante comum visualizar este atributo em formulrios cadastrais e em
listagens. Uma corrente de pensamento pondera que este nmero no faz sentido ao usurio
e no deve ser exibido. No exibi-lo tambm permite que a chave primria seja trocada numa
eventualidade em que o particionamento ou a replicao de banco de dados seja necessria
e implique numa troca da chave primria. Pense: o usurio deseja ou precisa saber a chave
primria ou a sua aplicao que foi projetada para obrigar o usurio a utiliz-la?
Princpio da Navalha de Occam (ou Ockham)

Se em tudo o mais forem idnticas as vrias explicaes de um fenmeno, a mais simples a melhor
- William de Occam.
Popularmente costumamos citar este princpio como: se h mais de uma explicao para um fenmeno, e todas parecem igualmente corretas, ento a mais simples a mais correta.
Em que outras partes da sua vida profi ssional poderamos aplicar com sucesso este princpio?
Outro tipo de restrio so as chaves ou chaves nicas: como o prprio nome j implica,
representam atributos dentro de uma tupla que no podem ter valores repetidos.
Valores nulos (NULL) podem ser restringidos com uma restrio de non-NULL. Atributos de
uma tupla com esta restrio obrigatoriamente devem possuir um valor vlido que no seja
nulo.
72
Integridade, Integridade referencial e chaves estrangeiras

A restrio de integridade estabelece que nenhuma tupla pode possuir uma chave primria
com valor NULL. Como a chave primria utilizada para identificar de modo nico cada tupla
da relao, permitir o valor NULL faria com que fosse possvel ter duas tuplas com a mesma
chave primria nula sendo impossvel distinguir uma da outra.
A restrio de integridade referencial especificada entre duas relaes (tabelas) distintas, e
utilizada para manter a consistncia entre tuplas pertencentes s duas relaes. Isto implica
que uma restrio de integridade referencial obriga uma tupla numa relao a referenciar a
uma tupla existente em outra relao para as quais a integridade referencial foi definida.
Contato
ID
1
2
3
4
Nome
Ademir
Carlos
Justino
Marcela
Sobrenome
Santos
Silva
Carvalho
Moreno
Nascimento
20/12/1984
26/04/1970
11/07/1981
03/06/1999
Telefone
ID
1
2
Nmero
443032020
4420201010
contato_id
1
3
Figura 5
Fonte: o autor
Para compreender melhor este conceito, analisemos a Figura 5. Restries de integridade

referencial so criadas entre duas tabelas diferentes (ou excepcionalmente na mesma tabela).
Veja o relacionamento entre as tabelas Contato e Telefone. Na tabela Telefone, o atributo
73
contato_id referencia o contato ao qual o Telefone pertence. Neste caso, definimos que o
atributo contato_id uma chave estrangeira da tabela Contato que referencia o relacionamento
entre as duas tabelas.
Estudo de caso:
Detran do Cear economizou R$ 1,7 milho com banco de dados livre

Tomada h cerca de dois anos pelo governo do Cear, a deciso de substituir a soluo de banco de
dados da Oracle pelo PostgreSQL fez com que o Detran economizasse gastos com pagamento de
licenas e servio de suporte tcnico.
Em 2008, o administrador de banco de dados Nabucodonosor Coutinho foi convidado pelo Detran do
Cear para cuidar do processo de migrao do banco de dados. Em apresentao no IV Encontro
Nordestino de Software Livre, realizado semana passada em Natal (RN), ele explicou o projeto.
Como o Detran chegou ao seu nome?
O Detran tinha a seguinte arquitetura: um servidor de aplicao ligado a um servidor Oracle. Era nesta
situao que as 1.287 tabelas e 426 views do banco se encontravam. Gastava-se muito dinheiro com
o pagamento de licenas e o governador queria que o Detran utilizasse o Software Livre. Pensou-se
em utilizar o MySQL, mas optou-se pelo PostgreSQL, que j era o banco de dados ofi cial do Governo
do Cear. Como trabalhava h cerca de 8 anos com o PostgreSQL, minha empresa foi chamada para
74
participar do projeto.
Quais foram as principais difi culdades encontradas?
A principal difi culdade era que a equipe estava ocupada com as tarefas dirias de manuteno e desenvolvimento de novas ferramentas para o rgo. Alm disso, a base de dados era muito complexa
e utilizava muitos recursos que at ento estavam disponveis apenas no Oracle. Outro fator negativo
foi que poucos tcnicos tinham conhecimento em PostgreSQL.
Como a arquitetura do banco hoje?
Agora o servidor de aplicao ligado diretamente a um balanceador de carga, que ligado a dois
servidores do banco de dados.
Alm da economia com as licenas, quais outros resultados positivos a nova arquitetura trouxe?
As consultas fi caram mais rpidas. Tem uma que levava 2 horas e, depois da migrao, passou a ser
realizada em 6 minutos. Na primeira vez, o responsvel do Detran no acreditou e acabamos gastando as 2 horas tentando convencer que a consulta tinha sido mesmo realizada em 6 minutos.
Fonte: <http://www.softwarelivre.gov.br/noticias/detran-do-ceara-economizou-r-1-7-milhao-com-banco-de-dados-livre/>. Acesso em: 1 ago. 2012.
Operaes de atualizao do modelo relacional

Existem trs operaes bsicas de atualizao que podem alterar o snapshot do banco de
dados. Vamos nos referir a estas operaes em seu termo em ingls, pois eles tambm
correspondem aos comandos em SQL que veremos nas prximas duas unidades. As
operaes so: Insert (Insero), Update (Modificao) e Delete (Remoo). A operao de
Insert utilizada para inserir novas tuplas numa relao; a operao Update utilizada para
atualizar valores de uma tupla j existente dentro de uma relao; e a operao Delete
utilizada para remover uma tupla existente de uma relao. Em cada uma dessas operaes,
so verificadas as restries descritas nas sees anteriores. Caso alguma das restries seja
violada, o SGBD reportar um erro e a operao no ser completada com sucesso.
75
Insert
A operao de Insert fornece os atributos de uma nova tupla para ser adicionada
na relao.
Restries de domnio podem ser violadas se algum dos valores atribudos no for
do tipo apropriado do atributo.
Restries de chave podem ser violadas se alguma outra tupla possuir a mesma
chave repetida.
Restries de integridade podem ser violadas se a chave primria atribuda for
NULL.
Restries de integridade referencial podem ser violadas se o valor de qualquer
chave estrangeira atribuda no existir no relacionamento referenciado.
Update
A operao de Update modifi ca os valores de um ou mais atributos em uma ou mais

tuplas numa relao.
Restries semelhantes operao de Insert podem ser violadas na execuo desta operao.
Delete
A operao de Delete remove uma tupla da relao. A nica restrio que pode ser
violada pela operao Delete a restrio de integridade referencial. Neste caso, a
tupla sendo removida referenciada por uma outra tupla num relacionamento entre
duas relaes.
<http://youtu.be/gx1xT_GzH_g>.
Alexandre Porcelli SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011
76
Os bancos de dados relacionais esto condenados?
Recentemente uma grande leva de bancos de dados no relacionais surgiram tanto na nuvem quanto
fora dela. Uma das principais mensagens que este cenrio nos traz se voc precisa de uma grande
escalabilidade sob demanda, voc precisa de um banco de dados no relacional.
Se isto for verdade, ento um sinal de que o outrora todo poderoso banco de dados relacional perdeu seu trono? Seria este um sinal de que os bancos de dados relacionais esto com os dias contados
e iro declinar com o passar do tempo? Neste artigo ns analisaremos a tendncia atual de se migrar
de bancos de dados relacionais em certas situaes e o que isso signifi ca para o futuro dos bancos
de dados relacionais.
Bancos de dados relacionais j esto presentes no mercado h mais de 30 anos. Durante este tempo,
muitas pseudo-revolues surgiram e se foram, e todas elas supostamente deveriam acabar com os
bancos de dados relacionais. Todas estas revolues fracassaram, claro, e nenhuma chegou a fazer
sequer um arranho na dominncia dos bancos de dados relacionais.
Primeiro, um pouco de histrico
Um banco de dados relacional essencialmente um grupo de tabelas (entidades). Tabelas so compostas de colunas e linhas (tuplas). Estas tabelas possuem restries, e relacionamentos so defi nidos entre elas. Bancos de dados relacionais so consultados atravs da SQL, e os conjuntos de
77
resultados so produzidos pelas consultas que acessam os dados de uma ou mais tabelas. Mltiplas
tabelas sendo acessadas numa nica consulta so unidas, tipicamente por um critrio definido nas
colunas de relacionamento das tabelas. Normalizao um modelo de estruturao de dados utilizado em bancos de dados relacionais que garante a consistncia dos dados e remove sua duplicao.
Car
Color
Carkey
Markekey Colorkey Colorkey Year
Colorkey
Color
2003
Red
2005
Green
2005
Blue
MakeModel
Modelkey Makekey
1
1
1
2
2
1
Model
Pathfinder
Bluebird
Civic
Make
Makekey
1
2
Make
Nissan
Honda
Example of a Typical Data Model

Bancos de dados relacionais so facilitados atravs de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDR). Praticamente todos os sistemas de bancos de dados em uso atualmente
so SGBDRs, incluindo Oracle, SQL Server, MySQL, Sybase, DB2, TeraData etc.
Os motivos para a dominncia do modelo relacional no so triviais. Eles tm continuamente oferecido
o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade no gerenciamento de dados genricos.
Entretanto, para oferecer tudo isto, os bancos de dados tornaram-se incrivelmente complexos internamente. Por exemplo, um relativamente simples comando SELECT pode ter centenas de possveis
caminhos de execuo de consulta, os quais o otimizador deve avaliar em tempo de execuo. Tudo
isto escondido dos usurios, mas sob o cap os SGBDRs determinam o plano de execuo que
melhor atende nossas requisies utilizando recursos como algoritmos baseados em custo.
O problema com bancos de dados relacionais
Mesmo que os SGBDRs forneam aos usurios o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade, seu desempenho em cada uma destas reas
no necessariamente melhor que o de uma soluo alternativa buscando um destes benefcios
isolado. Isto no foi um grande problema at agora, pois a dominncia universal dos SGBDRs tem
78
compensado a necessidade de se quebrar essas barreiras. No entanto, se voc realmente tem uma
necessidade que no pode ser atendida por um banco de dados relacional genrico, sempre houve
alternativas para atender estes nichos.
Atualmente vivemos uma situao um pouco diferente. Para um grande nmero de aplicaes, estes
benefcios esto se tornando mais e mais crticos; e embora ainda sejam considerados um nicho,
esto se tornando populares, tanto que para muitos usurios de bancos de dados estes requisitos
esto comeando a sobrepor os outros em importncia. Este benefcio escalabilidade. medida
que mais e mais aplicaes so implantadas em ambientes que possuem cargas de trabalho massivas, tais como servios web, seus requisitos de escalabilidade podem mudar rapidamente e crescer
a nveis muito elevados. O primeiro cenrio pode ser difcil de gerenciar se voc possui um banco de
dados relacional implantado em um nico servidor. Por exemplo, se sua carga triplica de um dia para o
outro, quo rapidamente voc pode ampliar o seu hardware? O segundo cenrio pode ser complicado
demais para ser gerenciado por um banco de dados relacional de um modo geral.
Bancos de dados relacionais escalam bem, mas isto somente quando a escalada acontece num nico servidor. Quando a capacidade daquele nico servidor alcanada, voc precisa realizar uma
escalabilidade horizontal e distribuir a carga entre mltiplos servidores. Este o momento em que a
complexidade dos bancos de dados relacionais limita o seu potencial de escalabilidade. Tente escalar
para centenas ou milhares de servidores, ao invs de apenas alguns, e as complexidades tornam-se
avassaladoras, e as caractersticas que tornam os SGBDRs to atraentes drasticamente reduzem sua
viabilidade como plataforma para grandes sistemas distribudos.
Os fornecedores de servios na nuvem tiveram que tratar esta limitao, pois uma plataforma na nuvem sem uma base de dados escalvel no chega a ser uma plataforma vivel. Assim, para fornecer
aos clientes uma plataforma escalvel para armazenar seus dados, os fornecedores tiveram uma
nica soluo. Estes fornecedores tiveram que implementar um novo tipo de sistema de banco de
dados que focasse em escalabilidade, ao custo de outros benefcios dos bancos de dados relacionais.
Estes esforos, combinados com aqueles de fornecedores de nichos de mercado, levaram criao
de uma nova gerao de sistemas gerenciadores de banco de dados.
A nova gerao
Este novo tipo de sistema gerenciador de banco de dados comumente chamado de chave-valor. De
fato, no h ainda um nome oficial, ento possvel encontrar nomes como orientado a documentos, orientado a atributos, banco de dados distribudo (embora bancos de dados distribudos tambm
possam ser relacionais), arrays particionados, tabelas hash distribudas, e bancos de dados de chave-valor. Embora cada um destes nomes aponte para peculiaridades especficas desta nova abordagem,
so todas variaes do mesmo tema, que chamaremos de bancos de dados de chave-valor.
No importa como voc chame, este novo tipo de banco de dados j est no mercado h algum
79
tempo e tem sido utilizado em aplicaes especializadas para as quais os bancos de dados relacionais
no serviam. Mas sem a escala que a web e a nuvem trouxeram, este novo tipo teria fica incgnito.
Atualmente o desafio identificar se este novo tipo de banco de dados ou um banco de dados relacional o mais adequado para uma aplicao particular.
Bancos de dados relacionais e bancos de dados de chave-valor so fundamentalmente diferentes e
projetados para atender diferentes requisitos. Uma comparao lado-a-lado permite comparar superficialmente estas diferenas e apresentamos uma inicial abaixo:
Definies de banco de dados
Bancos de dados relacionais
Bancos de dados de chave-valor
Bancos de dados contm tabelas, tabelas

contm linhas e colunas e linhas so compostas dos valores das colunas. Linhas
dentro de uma mesma tabela possuem
todas as mesmas definies de schema.
O modelo de dados conhecido a priori.

Um schema fortemente tipado e possui
restries e relacionamentos que foram a
integridade dos dados.
Domnios podem ser visualizados inicialmente como uma tabela, mas diferentemente de uma tabela voc no precisa
definir um schema para um domnio. Um
domnio basicamente um balde em
que voc coloca itens. Itens dentro de
um mesmo domnio podem ter diferentes
schemas.
Itens so identificados por chaves, e um

dado item pode ter um conjunto de atributos dinmicos associado.
Em algumas implementaes, atributos

so do tipo String. Em outras implementaes, atributos possuem tipos simples que
refletem os tipos do cdigo tais como ints,
arrays de String e listas.
No existem relacionamentos definidos de

modo explcito entre domnios ou mesmo
dentro de um mesmo domnio.
O modelo de dados baseado numa

representao natural dos dados que
contm, e no nas funcionalidades da
aplicao.
O modelo de dados normalizado para
remover duplicaes de dados. A normalizao estabelece relacionamentos entre
tabelas. Estes relacionamentos associam
os dados entre as tabelas.
Sem Join de Entidades

Bancos de dados de chave-valor so orientados a itens, o que significa que todos os dados relevantes
so armazenados dentro do prprio item. Um domnio (que voc pode visualizar como uma tabela)
pode conter itens muito diferentes um do outro. Por exemplo, um domnio pode conter itens de clientes
e itens de pedidos. Isto significa que comumente os dados so duplicados entre itens num mesmo
domnio. Esta uma prtica aceitvel porque espao em disco algo relativamente barato. Mas este
modelo permite que um nico item contenha todos os itens relevantes, o que aumenta a escalabilida-
80
de ao eliminar a necessidade de joins entre mltiplas tabelas. Com um banco de dados relacional, os
dados teriam que ser unidos para poder reagrupar todos os atributos relevantes.
Embora a necessidade de relacionamentos seja bastante reduzida com bancos de dados chave-valor, alguns ainda so inevitveis. Estes relacionamentos costumam existir entre entidades chave
do modelo. Por exemplo, um sistema de pedidos pode ter itens que contenham dados sobre clientes,
produtos e outros. No importa se estes dados residam no mesmo domnio ou em domnios diferentes; quando um cliente cria um pedido voc provavelmente no quer armazenar os atributos tanto do
cliente quanto do produto no mesmo item do pedido.
Ao invs disso, pedidos precisam armazenar as chaves dos itens de cliente e produto. Embora isso
seja perfeitamente possvel em bancos de dados chave-valor, estes relacionamentos no esto definidos no modelo de dados em si, e portanto o sistema gerenciador de banco de dados no pode forar a
integridade dos relacionamentos. Isto significa que voc pode excluir clientes e produtos que possuem
pedidos feitos. A responsabilidade por garantir a integridade dos dados cai toda sobre a aplicao.
Acesso a dados
Bancos de dados relacional
Banco de dados chave-valor
Dados so criados, atualizados, removidos e

consultados atravs de SQL.
Dados so criados, atualizados, removidos e

consultados atravs de APIs.
Consultas SQL podem acessar os dados de

uma nica ou de mltiplas tabelas atravs de
joins.
Algumas implementaes fornecem uma sintaxe bsica parecida com SQL para definir critrios de filtragem.
Consultas SQL incluem funes de agregao

e filtros complexos.
Somente predicados bsicos de filtragem podem ser aplicados na maioria das vezes.
Normalmente possuem meios de se embutir

lgica prximo aos dados atravs de triggers e
stored procedures.
A lgica de integridade da aplicao e seus

dados est toda implementada no cdigo da
prpria aplicao.
Interface com a aplicao

Bancos de dados relacional
Banco de dados chave-valor
Tendem a oferecer uma API prpria ou uma API

genrica como o ODBC ou JDBC.
Tendem a oferecer APIs SOAP e/ou REST para

acesso aos dados.
Os dados so armazenados num formato que

representa sua estrutura natural, de modo que
deve haver um mapeamento entre as estruturas do cdigo da aplicao e a estrutura relacional.
Os dados podem ser armazenados de modo

mais eficiente em compatibilidade com o cdigo
da aplicao, requerendo pouca infraestrutura
para suport-lo.
Vantagens de bancos de dados chave-valor

Existem duas claras vantagens dos bancos de dados chave-valor sobre os bancos de dados relacionais.
Adequado para a nuvem
O primeiro benefcio que os bancos de dados chave-valor so simples e portanto escalam melhor
que os bancos de dados relacionais atuais. Se voc est desenvolvendo um sistema com uma equipe
81
interna e pretende colocar dezenas ou centenas de servidores na sua base de dados para atender o
que voc acredita que seja uma quantidade massiva de dados, ento considere seriamente um banco
de dados chave-valor.
Como bancos de dados chave-valor escalam facilmente e de modo dinmico, tambm so os banco
de dados preferidos de servios de fornecedores de armazenamento atravs de web services com
potencial de escalabilidade. Usurios tipicamente pagam somente pelo que usam, mas seu uso aumenta medida em que a demanda aumenta. Enquanto isso o fornecedor pode escalar a plataforma
dinamicamente baseado na carga total do usurio, com pouqussimas limitaes provocadas pelo
tamanho da plataforma.
Melhor adaptado para o cdigo
Modelos de dados relacionais e modelos de cdigo de aplicaes so tipicamente construdos de
modo diferente, o que leva a incompatibilidades. Desenvolvedores normalmente superam estas incompatibilidades com cdigo que mapeiam os seus objetos ao modelo relacional, um processo comumente denominado de mapeamento objeto-relacional. Este processo, que essencialmente requer
muito cdigo de infraestrutura e no possui valor de negcios imediato, pode demandar uma parcela
considervel do tempo e do esforo do desenvolvimento da aplicao.
Outros argumentos a favor deste tipo de banco de dados, tais como bancos de dados relacionais
podem se tornar pesados ou desajeitados no so convincentes. Mas antes de entrar de cabea no
mundo dos bancos de dados chave-valor, considere algumas limitaes existentes.
Desvantagens de bancos de dados chave-valor
As restries inerentes de um banco de dados relacional garantem que os dados em seu nvel mais
baixo possuem integridade. Dados que violam as restries de integridade no podem ser inseridos
fisicamente no banco de dados. Estas restrioes no existem em bancos de dados de chave-valor,
ento a responsabilidade de garantir a integridade dos dados da aplicao. Mas o cdigo da aplicao pode conter bugs. Bugs num banco de dados relacional devidamente projetado normalmente
no levam a problemas de integridade de dados; bugs num banco de dados chave-valor, entretanto,
facilmente levam a problemas de integridade de dados.
Um dos principais benefcios de um banco de dados relacional que ele te fora a um processo de
modelagem de dados. Se bem feito, o processo de modelagem cria uma estrutura lgica no banco
de dados que reflete os dados contidos, ao invs de refletir a estrutura da aplicao. Dados, ento,
tornam-se quase que independentes de aplicao, o que reflete que outras aplicaes podem utilizar o
mesmo conjunto de dados e a lgica da aplicao pode ser alterada sem modificar o modelo de dados.
No se esquea tambm da compatibilidade. Diferentemente de bancos de dados relacionais, bancos de dados na nuvem no costumam seguir padres definidos. Embora todos tenham conceitos
similares, cada um possui sua prpria API, interfaces de consulta especficas e peculiaridades. Desse
82
modo, voc ter que confiar em seu fornecedor, pois voc no poder simplesmente troc-lo depois
se estiver descontente.
Limitaes de anlise
Na nuvem, bancos de dados chave-valor so compartilhados, o que significa que muitos usurios e
aplicaes utilizam o mesmo sistema. Para prevenir que um nico processo sobrecarregue o ambiente
compartilhado, muitos fornecedores na nuvem limitam o impacto total que uma consulta simples pode
causar. Por exemplo, no SimpleDB, voc no pode executar uma consulta que leve mais que 5 segundos. Com o Google AppEngine, voc no pode retornar mais que 1000 itens por consulta.
Estas limitaes no so problemas para aplicaes comuns com adio, atualizao, remoo e
consulta de poucos itens. Mas o que ocorre quando sua aplicao torna-se bem sucedida? Voc atraiu
muitos usurios e ganhou muitos dados, e agora voc quer criar valor agregado para seus usurios ou
utilizar os dados para gerar outras fontes de receita. Neste caso talvez os limites de consulta impostos
pelos fornecedores de nuvem possam limit-lo severamente. Situaes como criao de padres de
uso e fornecimento de recomendaes baseado no histrico do usurio podem tornar-se difceis e
talvez impossveis em algumas plataformas.
Neste caso, voc provavelmente ir implementar um banco de dados analtico em separado, populado
a partir de seu banco de dados chave-valor, para que estas anlises sejam executadas. Planeje com
antecedncia onde e como voc o far. Voc o hospedaria na nuvem ou on premise? A latncia entre
voc e o provedor na nuvem seria um problema? Seu banco de dados chave-valor suporta isso? Se
voc possui 100 milhes de itens em seu banco de dados chave-valor, e voc pode somente consultar
1000 de cada vez, quantas consultas isso levaria?
Em ltimo caso, embora escalabilidade seja um fator srio a considerar, mas se esquea da sua
necessidade de converter os dados em uma fonte de receita. Toda a escalab do mundo intil se os
seus usurios migrarem para seu concorrente porque ele possui funcionalidades mais interessantes.
Competidores de servios baseados em nuvem
Um bom nmero de fornecedores de servios web agora oferece bancos de dados chave-valor compartilhados no estilo pague-pelo-uso. A maioria deles atende aos critrios definidos at agora, mas
cada um possui funcionalidades nicas que variam dos padres que descrevemos at agora. Descreveremos agora de um modo geral alguns bancos de dados particulares, como o SimpleDB, Google
AppEngine Datastore e SQL Data Services.
Amazon: SimpleDB
83
O SimpleDB um banco de dados de chave-valor orientado a atributos disponvel na plataforma da

Amazon Web Services.
O SimpleDB possui diversas limitaes. Primeiro, uma consulta pode ser executada por no mximo
5 segundos. Segundo, no h tipos de dados alm de Strings. Tudo armazenado, recuperado e
comparado como uma String. Comparaes de data no funcionaro a no ser que voc converta
todas as datas para o formato ISO8601. Terceiro, o tamanho mximo de uma String limitado a 1024
bytes, o que limita quanto de texto (por exemplo, descries de produtos) voc pode armazenar num
nico atributo. Mas como o schema dinmico e flexvel, voc pode contornar este limite adicionado
descricao1, descricao2 etc. O problema que cada item limitado em 256 atributos.
Uma caracterstica chave do SimpleDB o seu modelo de consistncia eventual. Este modelo de
consistncia bom para concorrncia, mas significa que se voc alterou o atributo de um item, estas
mudanas no sero refletidas imediatamente nas operaes de leitura. Embora as chances de algum
problema ocorrer em funo disso sejam pequenas, voc deve se preparar para estas situaes. Por
exemplo, voc no deseja vender o ltimo ingresso de um show para cinco pessoas diferentes no seu
sistema de eventos.
Google AppEngine Data Store
O Google AppEngine Datastore construdo sobre o BigTable, o sistema interno do Google para
manipulaao de dados estruturados. Em si, o AppEngine no um mecanismo de acesso direto ao
BigTable, mas pode ser considerado como uma interface simplificada sobre o BigTable.
O AppEngine Datastore suporta muito mais tipos de dados que os itens do SimpleDB, incluindo tipos
de lista, que contm colees de elementos num nico item.
Voc provavelmente utilizar este banco de dados se planeja construir aplicaes no Google AppEngine. Entretanto, diferentemente do SimpleDB, voc no consegue interfacear diretamente com o
AppEngine Datastore (ou com o BigTable) utilizando uma aplicao foram da nuvem do Google.
Microsoft: SQL Data Services
84
O SQL Data Services parte da plataforma de servios web Microsoft Azure. O servio do SDS
na verdade uma aplicao em si que roda sobre vrios SQL Servers, que formam o mecanismo de
armazenamento da plataforma. Embora os bancos de dados de infraestrutura sejam relacionais, voc
no precisa acess-los; SDS um banco de dados chave-valor, assim como as outras plataformas
discutidas at agora.
A Microsoft parece estar sozinha neste cenrio ao concordar que embora bancos de dados chave-valor sejam timo para escalabilidade, esta escalabilidade vem ao custo do gerenciamento de dados,
quando comparado a SGBDRs. A abordagem da Microsoft parece ser focar no fundamental para conseguir implementar os mecanismos de escalabilidade e distribuio direito, e com o passar do tempo,
adicionar funcionalidades que ajudaro a diminuir a diferena entre bancos de dados chave-valor e
relacionais.
Fornecedores on-premise
Fora da nuvem, existem vrios produtos de bancos de dados chave-valor que podem ser instalados
on-premise. A maioria open source; tendo acesso ao cdigo-fonte talvez voc possa analisar e
tornar-se melhor ciente de potenciais problemas e limitaes uma vantagem que voc no teria em
fornecedores de cdigo fechado.
CouchDB
CouchDB um banco de dados orientado a documentos livre e open-source. Derivado de um banco

de dados chave-valor, utiliza JSON para definir o schema de seus itens. O CouchDB tenta diminuir
a distncia entre bancos de dados orientados a documentos e relacionais ao permitir que vises
sejam criadas dinamicamente com JavaScript. Estas vises mapeiam os dados do documento numa
estrutura parecida com tabelas que podem ser indexadas e consultadas.
At o momento, o CouchDB no realmente um banco de dados distribudo. Ele possui funes
de replicao que permite que os dados sejam sincronizados entre servidores, mas no o tipo de
distribuio suficiente para construir ambientes de alta escalabilidade. A comunidade do CouchDB,
entretanto, est trabalhando disso.
Projeto Voldemort
85
O projeto Voldemort um banco de dados distribudo chave-valor cujo objetivo escalar horizontalmente num grande nmero de servidores. Ele surgiu como um trabalho desenvolvido no LinkedIn e
utilizado no LinkedIn em alguns poucos sistemas que possuem requisitos elevados de escalabilidade.
O projeto Voldemort tambm utiliza um modelo de consistncia eventual.
mongoDB
O MongoDB um sistema de banco de dados desenvolvido pela 10gen por Geir Magnusson e Dwight
Merriman. Assim como o CouchDB, o MongoDB um banco de dados orientado a documentos baseado em JSON, excetuando-se o fato de que ele um verdadeiro banco de dados de objetos ao invs
de ser puramente chave-valor.
tomando uma deciso
Basicamente h quatro motivos para se escolher uma plataforma de banco de dados no relacional
chave-valor para sua aplicao:
1.
Seus dados so orientados a documentos, tornando-os uma escolha natural para o modelo de
chave-valor ao invs do modelo relacional.
2.
Seu ambiente de desenvolvimento altamente orientado a objetos, e um banco de dados chave-valor pode diminuir a quantidade de cdigo de infraestrutura.
3.
O banco de dados barato e integra com sua plataforma de servios web.
4.
Sua principal preocupao a alta escalabilidade sob demanda ou seja, uma escalabilidade
distribuda de larga escala que no pode ser obtida com escalabilidade vertical.
Ao tomar sua deciso, lembre-se das limitaes e dos riscos que voc corre ao sair da zona de conforto do modelo relacional.
Para todos os outros requisitos, provavelmente voc estar melhor servidor pelo bom e velho modelo
relacional. Portanto, estariam os bancos de dados relacionais condenados? Claramente no. Pelo
menos por enquanto.
Fonte: <http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php>.
Acesso em: 14 ago. 2012.
86
CONSIDERAES FINAIS
Nesta unidade, inicialmente descrevemos os conceitos de domnio, tuplas, atributos e
relaes do modelo relacional. A abordagem deste autor para explicar o modelo relacional
a de tentar fugir um pouco das definies formais matemticas do modelo e focar nos
conceitos fundamentais do modo mais prximo possvel ao cotidiano de desenvolvimento de
software. Propositadamente deixamos de lado aspectos de lgebra relacional, que podem ser
aprofundados em excelentes livros como o de Silberschatz (1999) e Date (1988).
No modelo relacional h uma srie de restries impostas para que se possa garantir a
consistncia dos dados presentes nos diferentes domnios, bem como a consistncia do
prprio modelo. As restries discutidas foram de domnio, de chave, de valores nulos,
de integridade e de integridade referencial e chaves estrangeiras. Estas restries so os
atributos que tornam o modelo relacional to interessante e to conceituado perante alguns
desenvolvedores e, claro, DBAs. Enxergar o sistema de banco de dados como uma aplicao
terceira que deve ser integrada ao software que desenvolvemos uma viso que nos permite
entender o porqu de tamanha valorizao das restries. De fato, com estas restries
(quando bem implementadas), h a garantia da integridade e consistncia das informaes
armazenadas.
As operaes de modificao do modelo relacional descritas no modelo relacional so as
operaes de Insert, Update e Delete e todas podem provocar violaes do modelo sendo
cada uma delas abordada em suas respectivas sees.
Agora que j temos toda a base conceitual do popular modelo de dados relacional, podemos
passar a interagir e executar operaes com os sistemas de bancos de dados relacionais. Para
nossa sorte, h um padro bem estabelecido e slido de interao com os SGBDs relacionais,
que a linguagem SQL. O assunto SQL to importante e ser to utilizado em sua vida
profissional que dedicaremos as duas prximas unidades para trat-lo.
87
ATIVIDADES DE AUTOESTUDO
1. Por que no existe uma ordem definida para as tuplas dentro de uma relao?
2. Quais so as situaes em que adequada a utilizao de valores NULL?
3. Defina os conceitos de integridade e integridade referencial.
88
UNIDADE IV
SQL Bsico
Definir o que SQL.
Apresentar os comandos de definio e uso da SQL.
Plano de Estudo
Definio e histrico da SQL
Descrio dos comandos de definio de dados e tipos em SQL
Descrio dos comandos de consulta bsicos em SQL
Descrio dos comandos de modificao de dados em SQL
INTRODUO
A primeira ideia que vem cabea de um desenvolvedor experiente quando se fala de banco
de dados relacionais SQL. Realmente, talvez uma das boas razes pelas quais os SGBDs
relacionais so to difundidos deve-se ao fato de que a SQL uma ferramenta bastante
madura, elaborada e bem projetada.
Em portugus, pronuncia-se SQL como uma sigla, com o som de cada uma das letras
separadas, esse-qu-ele. Porm, nas conversas em projetos internacionais que voc far,
ou em conferncias que voc participar em sua vida profissional, perceber que em ingls
SQL pronunciado como squel. O motivo curioso e no tem a ver com a sigla SQL, e sim
com o nome original desta linguagem. Atualmente, a sigla SQL significa Structured Query
Language (Linguagem de Consulta Estruturada), mas originalmente seu nome era SEQUEL:
Structured English QUEry Language (Linguagem de Consulta em Ingls Estruturado) da o
motivo da pronncia como squel.
SQL uma linguagem diferente das linguagens de programao que voc provavelmente
aprendeu at agora. Em qualquer curso de programao, costuma-se ensinar inicialmente
linguagens de programao imperativas (como C, Pascal, Java ou Python), em que voc
responsvel por escrever os comandos na ordem de execuo esperada. Neste tipo de
91
linguagem, preocupamo-nos em instruir o computador no modo como ele deve executar as

tarefas. O resultado de seu processamento uma consequncia daquilo que comandamos.
J a SQL uma linguagem declarativa, pois nela define-se o qu deve ser retornado como
resultado do processamento, sem especificar o como isso ser feito.
Permita uma reflexo sobre a natureza declarativa da SQL. Na SQL, ao definirmos somente o
que esperamos de resultado ao invs do como, permitimos que o SGBD decida como que
ele deve executar as instrues. H 10 anos, este seria um fator determinante para decidir
entre um produto e outro. A evoluo dos produtos comerciais e livres fez com que esta
diferena diminusse de modo significativo embora, dependendo dos casos de uso de sua
aplicao, a diferena ainda possa ser relevante. Em alguns casos, centenas de parmetros
de configurao do produto permitem alterar a forma com que o SGBD executa o como:
uma tarefa que muitas vezes chega a ser minuciosa tudo isso para conseguir aumentar o
desempenho do seu SGBD.
Para tentar diminuir as diferenas entre as diversas implementaes e variantes da SQL utilizadas
em produtos distintos, a ANSI (American National Standards Institute) e a ISO (International
Standards Organization) uniram-se para criar um padro para a SQL. A verso mais popular
deste padro a SQL-92, embora haja uma verso mais recente: a SQL:1999. Infelizmente, os
fabricantes de SGBDs no seguem 100% o padro, o que torna a tarefa de migrao de um
produto para outro um pouco mais difcil. Comercialmente, uma estratgia interessante para
os fabricantes, pois baseia-se no aprisionamento do cliente: uma vez comprometido com um
produto, o custo para migrao (em tempo e esforo) torna-se elevado o suficiente para que o
cliente desista da ideia. J para os usurios, este um fato infeliz. De positivo do padro SQL92 temos que mesmo com as sutis diferenas entre as implementaes da SQL em diferentes
produtos, as semelhanas se sobressaem e permitem que os desenvolvedores de software
possam aprender facilmente a lidar com produtos concorrentes.
A SQL possui comandos tanto para a criao de definies de dados (criao de schemas)
quanto para a execuo de comandos de manipulao de banco de dados (consultas e
92
atualizaes). uma linguagem bastante abrangente. por este motivo que trataremos da
SQL em duas unidades distintas. Esta primeira abordar a criao de schemas e os comandos
bsicos da linguagem, enquanto que a prxima unidade abordar os comandos um pouco
mais avanados.
DEFINIES DE DADOS E TIPOS EM SQL

Na unidade anterior, definimos os termos relao, tupla e atributo do modelo relacional. Em
SQL, estes termos so denominados respectivamente de tabela, linha e coluna. Boa parte
dos comandos SQL relacionados criao e definio de dados utiliza o comando CREATE.
O conceito de schema
Em sua verso inicial, a SQL no possua um mecanismo para agrupar tabelas relacionadas.
Como consequncia, todas as tabelas no SGBD coexistiam dentro de um mesmo ambiente.
A partir do SQL-92, criou-se o conceito de schema, que simplesmente um conjunto de
tabelas relacionadas. Do mesmo modo que em UML um pacote um conjunto de classes
relacionadas, um schema um conjunto de tabelas relacionadas. Por exemplo, o seguinte
comando cria um schema denominado de agenda. Todos os comandos em SQL so
finalizados por um ponto-e-vrgula:
create schema agenda;
Alm de agrupar logicamente as tabelas, um schema tambm convenientemente utilizado

para autorizar/restringir o acesso pelos usurios. Voc pode autorizar determinados usurios
a acessar um schema e restringir o acesso a outros.
O comando CREATE TABLE
O comando CREATE TABLE utilizado para criar uma nova tabela. O primeiro parmetro do
93
comando o nome da tabela sendo criada, seguido dos atributos e seus respectivos tipos e
eventuais restries do atributo. Restries de integridade referencial podem ser definidas ao
final do comando.
contato
id
nome
sobrenome
nascimento
peso
email
id
email
contato_fk
telefone
contato_fk
telefone
id
grupo aflio
id
nome
grupo_fk
contato_fk
Figura 6
Fonte: o autor
Os seguintes comandos criam as tabelas definidas na Figura 6:
94
CREATE TABLE contato (

id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL,
sobrenome VARCHAR(30) NOT NULL,
nascimento DATE,
peso DECIMAL(10,2)
);
CREATE TABLE email (
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
CREATE TABLE telefone (
id INT PRIMARY KEY,
telefone VARCHAR(20) NOT NULL,
contato_fk INT,
);
CREATE TABLE grupo (
id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL
);
CREATE TABLE afiliacao (
grupo_fk INT NOT NULL,
contato_fk INT NOT NULL,
PRIMARY KEY (grupo_fk, contato_fk),
FOREIGN KEY (grupo_fk) REFERENCES grupo(id),
);
95
Em algumas situaes, no possvel definir as restries de integridade referencial e chave

estrangeira no prprio CREATE TABLE, pois as tabelas referenciadas ainda no existem. Na
prxima unidade, abordaremos como resolver este impasse.
Tipos de dados
A SQL define um conjunto de tipos de dados bsicos para os seus atributos. Diferentes
produtos adicionam tipos de dados diferentes ao conjunto suportado, mas todos os produtos
disponveis no mercado suportam ao menos estes tipos bsicos:
Tipos numricos
Tipos de dados numricos suportam dados inteiros (INT e SMALLINT)

e de ponto flutuante (FLOAT e DOUBLE). Nmeros com preciso decimal (normalmente utilizados em clculos de moeda, por exemplo)
so DECIMAL ou NUMERIC, declarados como DECIMAL(a,b) ou
NUMERIC(a,b) onde a o nmero de dgitos inteiros e b o nmero
de dgitos decimais.
Tipos Caractere
Tipos de caractere podem ser de tamanho fixo ou varivel. Os atributos

de tamanho fixo podem ser declarados como CHAR(n) onde n o
nmero mximo de caracteres suportado pelo atributo. Para especificar
um atributo de tamanho varivel, utiliza-se o tipo VARCHAR(n).
Para se entender o critrio de uso entre um e outro, necessrio entender como a alocao de espao destes tipos no arquivo fsico. Se
o tamanho for fixo (CHAR), o SGBD j aloca este tamanho predefinido
no arquivo: as buscas podem ser mais rpidas, pois o SGBD j sabe o
tamanho do campo ao pular bytes na busca sequencial. Entretanto,
se o contedo dos atributos no preencher todo o tamanho definido, h
o desperdcio de espao de armazenamento. Por outro lado, utilizando-se VARCHAR, o SGBD aloca um ponteiro para determinar qual o tamanho do atributo: as buscas so mais lentas, mas no h desperdcio
de espao.
Tipos booleanos
96
Assim como em linguagens de programao, tipos booleanos podem

assumir os valores TRUE ou FALSE. Muitos SGBDs mapeiam estes
valores em 1 e 0, respectivamente.
Tipos temporais
O tipo DATE suporta dados temporais no formato AAAA-MM-DD (ano,

ms, dia), enquanto que o tipo TIME utiliza o formato HH:MM:SS (hora,
minuto e segundo). A prpria SQL assegura representaes temporais
vlidas.
RESTRIOES
Seguindo o nosso planejamento, abordaremos agora as restries que podem ser declaradas
em SQL no comando CREATE TABLE. Restrioes adicionais especificadas em outros
comandos sero abordadas na prxima unidade.
Valores NULL e valores padro
A linguagem SQL permite que todos os atributos (com exceo daqueles que compem a
chave primria) sejam nulos. Se o seu modelo de negcios no permite que um atributo seja
nulo, necessrio especificar uma restrio de NOT NULL na declarao do atributo.
Uma outra considerao (pequena talvez) sobre o NOT NULL que no mnimo o SGBD ter
que gravar um bit (ou um byte) a mais em cada atributo em casos de campos NULL. Se um
atributo permitir nulos, ento o SGBD ter que primeiramente saber se o campo nulo ou no,
e depois armazenar o prprio contedo.
Alm de valores nulos, tambm h possibilidade de se definir um valor padro para os atributos
utilizando-se a clusula DEFAULT <valor>. Caso este atributo seja omitido durante a insero
de uma linha da tabela, assume-se o valor padro.
Por padro na SQL, caso nenhuma clusula seja declarada, os atributos permitiro valores
nulos e o valor padro tambm ser nulo.
Como exemplo, poderamos definir Silva como o sobrenome padro dos nossos contatos no
comando CREATE TABLE:
97
CREATE TABLE contato (

id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL,
sobrenome VARCHAR(30) NOT NULL DEFAULT Silva,
nascimento DATE,
peso DECIMAL(10,2)
);
Chaves e integridade referencial

Para especificar uma chave primria, utiliza-se a clusula PRIMARY KEY. Caso a chave
primria possua um nico atributo, ela pode ser declarada no prprio atributo (como no
exemplo da tabela contato):
id INT PRIMARY KEY
Havendo mais de um atributo na chave primria, necessrio declar-la ao final (como no

exemplo da tabela grupo):
PRIMARY KEY (grupo_fk, contato_fk)
A clusula UNIQUE especifica chaves nicas (no primrias) numa tabela. Poderamos alterar
a definio da tabela email para garantir que no haja e-mails duplicados em nossa aplicao:
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL UNIQUE,
contato_fk INT,
);
J a integridade referencial e as chaves estrangeiras so definidas por meio da clusula
98
FOREIGN KEY, como utilizada j no nosso exemplo nas tabelas email e telefone:
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL,
contato_fk INT,
);
CREATE TABLE telefone (
id INT PRIMARY KEY,
telefone VARCHAR(20) NOT NULL,
contato_fk INT,
);
CONSULTAS BSICAS EM SQL

O comando em SQL para a execuo de operaes de consulta o SELECT, e as consultas que
podem ser elaboradas com este comando variam das mais simples at as bem complicadas.
Em sua forma fundamental, um comando de consulta SELECT assume a forma SELECT
<atributos> FROM <tabelas> WHERE <condies>.
De acordo com Silberschatz (1999), a expresso bsica de consulta em SQL consiste de trs
clusulas: SELECT, FROM e WHERE:
1. A clusula de SELECT utilizada para listar os atributos desejados no resultado da
consulta.
2. A clusula FROM lista as relaes (tabelas) que devem ser examinadas na avaliao
da expresso SQL.
3. A clusula WHERE corresponde ao predicado envolvendo os atributos das relaes
que aparecem na clusula FROM.
99
As condies do comando SQL podem utilizar comparadores lgicos similares aos de outras
linguagens de programao j conhecidas, tais como = (igual), < (menor), <= (menor ou igual),
> (maior), >= (maior ou igual) e <> (diferente).
Provavelmente, uma das melhores formas de se aprender por meio de exemplos. Ao invs de
nos atermos aos detalhes sintticos e conceituais de cada tipo de consulta, apresentaremos
exemplos de como realiz-las a seguir.
Todos os exemplos de consulta sero realizados tendo-se como base a definio de esquema
proposta na Figura 6.
Exemplo 1: Selecione o nome e o telefone de todos os contatos cujo sobrenome seja Silva.
SELECT nome, telefone FROM contato, telefone WHERE contato.id = telefone.contato_fk AND contato.sobrenome = Silva;
Neste exemplo, a condio contato.sobrenome = Silva um predicado que seleciona

somente as linhas especificadas na tabela contato. A condio contato.id = telefone.contato_fk
denominada de condio de join, pois combina duas tabelas diferentes baseadas, neste
caso, numa chave estrangeira de um relacionamento entre ambas.
Exemplo 2: Selecione o nome, o telefone e o e-mail de todos os contatos cujo nome seja
Edson.
SELECT nome, telefone, email
FROM contato, telefone, email
WHERE contato.id = telefone.contato_fk AND contato.id = email.contato_fk AND contato.nome =
Edson;
Neste exemplo pode-se notar que numa consulta permitido realizar o join entre vrias tabelas
diferentes; e novamente neste caso, todas esto relacionadas por meio de uma condio de
combinao baseada em chaves estrangeiras.
100 BANCO DE DADOS | Educao a Distncia
Exemplo 3: Selecione o id do telefone de todos os contatos cujo peso seja maior que 70.
SELECT telefone.id
FROM contato, telefone
WHERE contato.peso > 70;
O exemplo 3 mostra como devemos definir os nomes dos atributos nas clusulas quando h a
possibilidade de ambiguidade na definio dos nomes. Tanto a tabela contato quanto a tabela
telefone possuem um atributo denominado de id. Neste caso, devemos informar SQL qual
o atributo id que desejamos obter, prefixando o atributo com o nome de sua respectiva tabela.
No caso do exemplo, eliminamos a ambiguidade descrevendo o atributo como telefone.id.
Exemplo 4: Selecione o nome do grupo e o nome do contato de todos os contatos cujo nome
seja Joaquim.
SELECT contato.nome as n, grupo.nome as g
FROM contato, grupo, afiliacao
WHERE contato.id = afiliacao.contato_fk AND grupo.id = afiliacao.grupo_fk AND n = Joaquim;
Uma facilidade na construo de consultas que possuem termos repetidos sendo referenciados
a criao de um alias. Um alias um apelido definido para um determinado termo da consulta
SQL. No Exemplo 4, definimos que o atributo contato.nome possui um alias n e que o atributo
grupo.nome possui um alias g. Desse modo, no restante desta consulta, no precisamos
mais nos referenciar a estes atributos pela referncia completa, e torna-se possvel ento
simplesmente escrevermos a condio final da consulta como sendo n = Joaquim.
Exemplo 5: Selecione o peso de todos os contatos com peso < 100.
SELECT c.peso
FROM contato c
WHERE c.peso < 100;
No exemplo 5, demonstramos que a definio de um alias no est restrita aos atributos; um

alias pode tambm ser definido como um apelido para uma tabela na consulta SQL.
101
Exemplo 6: Selecione a data de nascimento de todos os contatos.

SELECT nascimento
FROM contato;
A clusula WHERE de uma consulta SQL opcional. Embora em muitos casos voc, como
programador(a), deva se questionar se isto oportuno ou no, j que potencialmente a
quantidade de registros numa tabela pode chegar aos milhes ou bilhes. Quando a clusula
WHERE omitida, a consulta ir processar todos os registros das tabelas referenciadas. No
Exemplo 6 demonstramos como obter todas as datas de nascimento por meio do processamento
de todas as linhas da tabela contato.
Exemplo 7: Selecione todos os atributos de contatos cujo peso = 75.
SELECT *
FROM contato
WHERE peso = 75;
Quando no se deseja limitar quais atributos devem ser retornados na consulta, pode-se
utilizar um asterisco (*) para determinar ao SQL que processe todos os atributos de todas as
tabelas da clusula FROM no resultado da consulta SQL.
Exemplo 8: Selecione todos os sobrenomes distintos de todos os contatos.
SELECT DISTINCT sobrenome
FROM contato;
Embora o modelo relacional seja baseado na teoria geral dos conjuntos e matematicamente
em conjuntos no haja elementos repetidos, permite-se elementos repetidos em tabelas, e
consequentemente, nos resultados das consultas estes elementos repetidos so exibidos. Nas
situaes em que se deseje eliminar as tuplas repetidas nos resultados das consultas, pode-se
utilizar a clusula DISTINCT como no Exemplo 8.
Exemplo 9: Selecione todos os telefones cujo nmero comece com 44.

SELECT *
FROM telefone
WHERE telefone LIKE 44%;
No Exemplo 9, utilizamos o comparador LIKE para definir uma busca por padres em Strings.
O caractere % utilizado em condies LIKE para definir zero ou mais caracteres. Neste
exemplo, o 44% determina que a String deve iniciar com 44 e pode possuir zero ou mais
caracteres posteriores.
Exemplo 10: Selecione todos os contatos que nasceram na dcada de 1980.
SELECT *
FROM contato
WHERE nascimento LIKE 198_-__-__;
Um outro caractere especial que pode ser utilizado em condies LIKE o _. Ele representa
um nico caractere arbitrrio utilizado na busca. Como as datas em SQL podem ser
representadas como uma String AAAA-MM-DD, utilizamos o _ para preencher os campos
da nossa busca.
Exemplo 11: Selecione todos os contatos cujo peso esteja entre 90 e 100.
SELECT *
FROM contato
WHERE peso BETWEEN 90 AND 100;
A condio BETWEEN da SQL pode ser utilizada para determinar intervalos de valor em
comparaes.
103
Exemplo 12: Selecione o nome de todos os contatos por ordem alfabtica crescente.
SELECT nome
FROM contato
ORDER BY nome ASC;
A clusula ORDER BY da SQL permite que o resultado da busca seja ordenado de acordo
com os parmetros informados. Uma clusula ORDER BY pode ordenar os resultados de
modo ascendente ou descendente. Para tanto, basta adicionar respectivamente o modificador
ASC ou DESC na clusula. O valor ASC o padro e o valor assumido caso o modificador
seja omitido.
Exemplo 13: Selecione o nome e o sobrenome de todos os contatos cujo sobrenome inicie
com A e ordene por sobrenome em ordem decrescente e por nome em ordem crescente.
SELECT nome, sobrenome
FROM contato
WHERE sobrenome LIKE A%
ORDER BY sobrenome DESC, nome ASC;
No exemplo 13 demonstramos como ordenar o resultado de uma consulta a partir de dois

critrios diferentes. Os critrios so avaliados pela ordem em que so declarados.
COMANDOS DE MODIFICAO DE DADOS EM SQL

At agora pudemos definir quais so os comandos bsicos da SQL para a execuo de
consultas bsicas em nossos bancos de dados. Nesta seo abordaremos os comandos da
SQL que permitem a adio, atualizao e remoo de tuplas (linhas), que respectivamente
correspondem ao INSERT, UPDATE e DELETE. Abordaremos cada um deles nas prximas
subsees.
O comando INSERT
O comando INSERT utilizado para inserir linhas numa determinada tabela. Devido definio
formal do schema da tabela, precisamos informar os valores de insero na tabela dentro de
uma ordem especfica. Esta ordem pode ser a prpria ordem determinada pela definio do
schema ou pode ser a ordem em que definimos os nomes das colunas da clusula de INSERT.
O comando INSERT em sua forma mais simples pode ser exemplificado do seguinte modo:
INSERT INTO contato
VALUES (10, Edson, Yanaga, 1978-04-12, 95);
Neste exemplo, determinamos que os valores da clusula VALUES seguem a mesma ordem
da definio do schema, como definido no incio desta unidade. Note que durante a insero
os valores informados devem satisfazer as condies de restries de domnio, integridade,
nulo e integridade referencial.
INSERT INTO contato (nome, sobrenome, peso, nascimento, id)
VALUES (Edson, Yanaga, 95, 1978-04-12, 10);
Nesta segunda forma do comando INSERT ns especificamos explicitamente qual a ordem

desejada de insero de cada um dos atributos da tabela contato.
Uma questo que surge para os desenvolvedores : qual seria a forma mais adequada?
Certamente no h uma resposta que possa ser considerada melhor ou pior, mas um argumento
a favor da segunda forma estabelece que quando a ordem dos argumentos especificada no
prprio comando INSERT, evita-se que este torne-se invlido quando o schema da tabela for
modificado para adio ou alterao de ordem de alguma coluna. O fato do comando tornar-se
invlido provavelmente provocaria um erro da aplicao em tempo de execuo, j que este
tipo de bug no pode ser identificado pelo compilador.
105
Uma terceira forma do comando INSERT permite que os valores informados para insero
sejam determinados por uma clusula SELECT ao invs de serem argumentos literais na
prpria clusula. Podemos criar uma tabela adicional no nosso schema para armazenar estes
dados provenientes do comando SELECT:
CREATE TABLE lista_de_nomes (
nome varchar(30),
sobrenome varchar(30)
);
Baseando-se nos dados j existentes na tabela contato, a recm-criada tabela lista_de_nomes

poderia ser populada com o seguinte comando INSERT:
INSERT INTO lista_de_nomes (nome,sobrenome)
SELECT nome,sobrenome
FROM contato
WHERE nascimento > 1980-01-01;
O comando UPDATE
O comando UPDATE modifica os valores de uma ou mais tuplas (linhas) das tabelas
selecionadas. Neste comando a clusula WHERE determina quais so as linhas da tabela
selecionadas para modificao.
Em sua forma fundamental, um comando de modificao UPDATE assume a forma UPDATE
<tabela> SET <atributos e valores> WHERE <condies>.
Note que diferentemente do comando SELECT, um comando UPDATE s pode ser aplicado
numa nica tabela. Caso seja necessrio modificar os valores de atributos de mais de uma
tabela, vrios comandos UPDATE tero que ser executados todos possivelmente agrupados
dentro de uma nica transao.
UPDATE contato
SET peso = 99, nascimento = 1982-04-25
WHERE nome = Carlos;
Neste exemplo do comando UPDATE, estamos modificando o valor de dois atributos das
tuplas cujo nome = Carlos. uma prtica bastante comum executarmos comandos UPDATE
no banco de dados somente identificando a chave primria na clusula WHERE. Assim, temos
a garantia de que um nico registro ser modificado de cada vez (j que cada chave primria
nica dentro de uma mesma tabela), se assim for o caso de uso desejado.
UPDATE contato
SET peso = peso * 1.1;
Assim como no comando SELECT, a clusula WHERE opcional tambm no comando

UPDATE. Neste caso, todas as linhas da tabela informada sero selecionadas para a
execuo das modificaes solicitadas. No exemplo acima demonstramos que podemos
executar operaes aritmticas com os valores dos atributos das tabelas. Neste exemplo,
atualizamos para 10% acima o peso de todos os contatos (no caso de uma hipottica epidemia
de obesidade).
UPDATE contato
SET nascimento = NULL;
O valor nulo tambm pode ser utilizado como valor de atribuio em comandos UPDATE,
desde que as restries do schema do banco de dados assim o permita.
Assim como o comando INSERT e de acordo com o j explanado na Unidade III todas
as restries do schema que se aplicam ao comando INSERT tambm so vlidas para o
comando UPDATE.
107
O comando DELETE
O comando DELETE na SQL remove linhas de uma determinada tabela. Assim como os
comandos INSERT e UPDATE, possui uma clusula WHERE para limitar as linhas que sero
processadas pelo comando. Novamente, assim como nos comandos INSERT e UPDATE, a
ausncia da clusula WHERE implica que todas as linhas de uma determinada tabela sero
processadas o que no caso do comando DELETE implica que o resultado ser uma tabela
vazia.
Em sua forma fundamental, um comando de modificao DELETE assume a forma DELETE
FROM <tabela> WHERE <condies>.
DELETE FROM telefone
WHERE id = 5;
O exemplo acima a forma mais comum de execuo do comando DELETE. A exemplo do

comando UPDATE, o comando DELETE s pode ser aplicado em uma nica tabela de cada
vez.
DELETE FROM contato;
Um caso extremo, este exemplo resultaria numa tabela contato vazia. Entretanto, como nas
operaes de DELETE, as restries de integridade referencial so verificadas, este comando
falharia com um erro caso alguma outra tabela (telefone, por exemplo) tivesse alguma chave
estrangeira apontando para uma linha da tabela contato.
Sugesto de Vdeo:
<http://youtu.be/HJre77TPpSw>.
Cezar Taurion, da IBM, fala das vantagens da computao em nuvem.
10 coisas que voc deve saber sobre banco de dados NoSQl

Por um quarto de sculo, os Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) tm
sido o modelo dominante para gerenciamento de banco de dados. Mas hoje, no relacionais, cloud
ou bancos de dados NoSQL esto ganhando ateno como um modelo alternativo para gerenciamento de banco de dados. Neste artigo, abordaremos os 10 aspectos principais destes bancos de
dados NoSQL no relacionais: as cinco principais vantagens e os cinco desafi os.
Cinco vantagens do NoSQl
1. Escalabilidade elstica
Por anos, administradores de banco de dados apoiaram-se na escalabilidade vertical que consiste
na compra de servidores maiores medida que a carga aumenta ao invs da escalabilidade horizontal distribuio dos bancos de dados em mltiplos servidores medida que a carga aumenta.
Entretanto, medida que os requisitos de carga de transaes e disponibilidade aumentam, e os
banco de dados movem para a nuvem ou para ambientes virtualizados, as vantagens econmicas da
escalabilidade horizontal em hardware comoditizado tornam-se irresistveis.
SGBDRs podem no escalar to facilmente em clusters comoditizados, mas a nova gerao de banco
de dados NoSQL projetada para expandir-se transparentemente de modo a tirar proveito de novos
ns, e normalmente so concebidos com hardware de baixo custo em mente.
2. Big data
Assim como os nveis de transaes cresceram absurdamente na ltima dcada, o volume de dados
109
que est sendo armazenado tambm cresceu massivamente. OReilly chamou isto de revoluo industrial dos dados. A capacidade dos SGBDRs tem crescido para se equiparar a estes aumentos,
mas assim como os nveis de transaes, as restries de volumes de dados que podem ser efetivamente gerenciados na prtica por um nico SGBDR tornaram-se intolerveis para algumas empresas.
Atualmente, os volumes de big data que podem ser manipulados por sistemas NoSQL como o Hadoop superam em muito o que pode ser manipulado pelos maiores SGBDRs disponveis.
3. Adeus DBAs (ou at logo?)
Apesar das muitas melhorias de gerenciamento alegadas pelos fornecedores de SGBDRs ao longo
dos anos, SGBDRs de alto nvel s podem ser mantidos com a assistncia de caros e altamente
treinados DBAs. DBAs esto intimamente envolvidos no projeto, instalao e otimizao de sistemas
baseados em SGBDRs.
Bancos de dados NoSQL so normalmente concebidos para requerer menos gerenciamento: reparos
automticos, distribuio de dados e modelos de dados mais simples tendem a requisitos de administrao e otimizao menores na teoria. Na prtica, provvel que os rumores da morte dos DBAs
tenham sido um pouco exagerado. Algum sempre ser responsvel pelo desempenho e disponibilidade de um repositrio de dados de misso crtica.
4. Economia
Bancos de dados NoSQL tipicamente utilizam clusters de servidores baratos para gerenciar a exploso
no volume de transaes e dados, enquanto que SGBDRs tendem a depender de caros servidores e
dispositivos de armazenamento proprietrios. O resultado que o custo por gigabyte ou transaes/
segundo para o NoSQL pode ser muitas vezes menor que o custo de SGBDRs, permitindo que voc
armazene e processe os dados com um custo muito menor.
5. Modelos de dados flexveis
Gerncia de mudana uma grande dor de cabea para grandes SGBDRs em produo. Cada pequena mudana no modelo de dados deve ser cuidadosamente gerenciada e pode necessitar de
downtime ou nveis de servio reduzidos.
Bancos de dados NoSQL possuem restries de modelos de dados muito mais flexveis ou inexistentes. Bancos de dados NoSQL do tipo chave-valor ou de documentos permitem que a aplicao
virtualmente armazene qualquer estrutura num elemento de dado. Mesmo um banco de dados NoSQL
definido de modo mais rgido como aqueles baseados em BigTable (Cassandra e HBase) tipicamente
permitem o acrscimo de novas colunas sem maiores problemas.
O resultado que as mudanas na aplicao e as mudanas no schema do banco de dados no
precisam mais ser gerenciadas como uma nica e complicada mudana. Na teoria, isto permite que
as aplicaes possuam ciclos de iterao mais rpidos, embora claramente possa haver efeitos colaterais indesejveis caso a aplicao falhe em gerenciar a integridade dos dados.
Cinco desafios do NoSQL
A promessa dos bancos de dados NoSQL gerou muito entusiasmo, mas ainda h obstculos a serem
superados antes que eles possam seduzir grandes empresas mais conservadoras. A seguir listamos
alguns dos principais desafios.
1. Maturidade
SGBDRs j esto por a h um longo tempo. Defensores do NoSQL argumentaro que sua idade
avanada um sinal de sua obsolescncia, mas para a maioria dos CIOs, a maturidade dos SGBDRs
reconfortante. Para a maioria, SGBDRs so estveis e ricos em funcionalidades. Em comparao,
muitas alternativas NoSQL so verses de pr-produo em que muitas funcionalidades importantes
ainda devem ser implementadas.
2. Suporte
Empresas querem a garantia de que se um sistema chave falhar, tero um suporte competente com
um tempo de resposta aceitvel. Todos os fornecedores de SGBDRs trabalham bastante para conseguirem fornecer um elevado nvel de suporte corporativo.
Em contraste, muitos sistemas NoSQL so projetos open-source, e embora existam muitas empresas
oferecendo suporte a banco de dados NoSQL, estas empresas normalmente so pequenas startups
sem o alcance global, recursos de suporte ou credibilidade de empresas como Oracle, Microsoft ou
IBM.
3. Business Intelligence e Business Analytics
Banco de bancos NoSQL evoluram para atender a demanda de escala de modernas aplicaes Web
2.0. Consequentemente, a maioria de suas funcionalidades est relacionada s demandas destas
aplicaes. Entretanto, os dados de uma aplicao tm um valor para o negcio que vai alm do ciclo
de insert-read-update-delete de uma tpica aplicao Web. Empresas mineram informaes em banco
de dados corporativos para melhorar sua eficincia e competitividade, e business intelligence (BI)
um ativo valioso de TI para todas as mdias e grandes empresas.
Bancos de dados NoSQL oferecem poucas funcionalidades para consultas e anlises ad-hoc. Mesmo
uma simples consulta exige um domnio significativo de programao, e muitas ferramentas de BI
populares no fornecem conectividade a NoSQL.
Algum alvio trazido pelo surgimento de soluo como HIVE e PIG, que podem fornecer um fcil
acesso a dados em clusters Hadoop e eventualmente outros bancos de dados NoSQL. A Quest Software desenvolveu um produto Toad for Cloud Databases que pode fornecer a capacidade de
consultas ad-hoc em uma boa variedade de bancos de dados NoSQL.
4. Administrao
Os objetivos de projeto do NoSQL podem ser o de fornecer uma soluo com custo zero de administrao, mas a realidade atual ainda no esta. O NoSQL hoje requer muita habilidade para instalar e
muito esforo de manuteno.
5. Expertise
Existem literalmente milhes de desenvolvedores no mundo todo, em praticamente todo segmento
de negcios, que esto familiarizados com os conceitos e programao em SGBDRs. Em contraste,
praticamente todo desenvolver NoSQL ainda est em processo de aprendizado. Esta situao ser
resolvida naturalmente com o passar do tempo, mas por enquanto, muito mais fcil encontrar programadores ou administradores SGBDR que um expert em NoSQL.
Concluso
Bancos de dados NoSQL esto se tornando uma crescente e importante parte do cenrio de banBANCO DE DADOS | Educao a Distncia
111
co de dados, e quando utilizados de modo apropriado, podem oferecer benefcios reais. Entretanto,
empresas devem proceder com cautela com total conscincia das limitaes e problemas que esto
associados com estes bancos de dados.
Guy Harrison o diretor de pesquisa e desenvolvimento da Quest Software. Um reconhecido expert
em banco de dados com mais de 20 anos de experincia em aplicaes, administrao de banco de
dados, tuning de desempenho e desenvolvimento de software. Guy autor de vrios livros e diversos
artigos em tecnologias de banco de dados e um palestrante regular em conferncias tcnicas.
Fonte: <http://www.techrepublic.com/blog/10things/10-things-you-should-know-about-nosql-databases/1772>. Acesso em: 12 ago. 2012.
Blog do Cezar Taurion,

BigData e Cloud Computing:
Evangelista
da
IBM
no
Brasil
especialista
em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/?lang=pt_br>.
CONSiDErAES FiNAiS
Finalizada a leitura desta unidade, j temos a convico de que voc, como profissional
comprometido(a) e fluente em ingls que (sim, na rea de Tecnologia da Informao
ingls obrigatrio e deveria ser o idioma principal), j abordar seus colegas, alunos(as)
e profissionais, falando squel ao invs do famigerado esse-qu-ele quando se referir
linguagem SQL.
Como toda tecnologia e assunto novo, SQL exige prtica para o domnio. Este autor acredita
piamente na educao por meio de exemplos como a melhor forma de se formar profissionais
que consigam utilizar os conhecimentos assimilados na execuo prtica das tarefas. Durante
as sees desta unidade, pudemos estudar a formao dos comandos INSERT, UPDATE
e DELETE e suas respectivas sintaxes e clusulas individuais. Em seguida, por meio de
exemplos, praticamos uma srie de diferentes definies de comandos e explicamos o que se
esperava de cada um deles, bem como sua motivao. Crie seus prprios schemas baseado(a)
nas abstraes reais do mundo que o cerca. Exercite-se e execute consultas e comandos de
modificao SQL nestes seus schemas. Com a prtica cotidiana voc perceber que SQL
tambm bastante simples.
At agora fomos capazes de abordar as estruturas bsicas da linguagem SQL. Na prxima
unidade, poderemos nos dedicar a alguns casos mais elaborados de uso desta popular
linguagem.
Todas as atividades de autoestudo desta unidade baseiam-se na Figura abaixo.
aluno
id
nome
sobrenome
ra
email
professor
id
nome
sobrenome
curso
id
titulao
matricula
nome
ano
disciplina_fk
aluno_fk
disciplina
id
nome
curso_fk
professor_fk
1. Considere o exemplo de schema da figura apresentada. Crie os comandos SQL para

definio e criao das tabelas.
a. Elabore consultas SQL para selecionar:
b. O nome de todos os alunos matriculados no curso com nome = Banco de Dados.
c. A titulao do professor da disciplina com nome = SQL.
113
d. O nome, sobrenome e ra de todos os alunos matriculados nas disciplinas lecionadas pelo professor com nome Edson.
e. Todos os atributos de todos os cursos com ano > 1990.
3. Elabore comandos de modificao de dados para incluir, modificar e remover linhas
das diferentes tabelas deste schema.
UNIDADE V
MAIS SQL
Definir consultas complexas em SQL.
Apresentar os comandos de alterao de definies em SQL.
Plano de Estudo
Definio de consultas em SQL envolvendo NULL
Descrio de consultas em SQL com subqueries
Descrio de consultas em SQL com diferentes tipos de join
Descrio de consultas em SQL com funes de agregao
Descrio de comandos em SQL para alterao de schema
INTRODUO
Agora que j aprendemos a sintaxe bsica dos comandos SQL, podemos nos aventurar
em consultas um pouco mais complexas. Em praticamente todos os sistemas de bancos de
dados disponveis no mercado, sejam eles relacionais ou NoSQL, as funes de consulta e
manipulao bsicas se equivalem. Isso significa que com o material estudado at a unidade
anterior, ainda no foi possvel perceber um dos bons diferenciais competitivos dos bancos de
dados relacionais, que justamente a capacidade de se executar estas consultas um pouco
mais complexas e sofisticadas.
Quando citamos estas consultas um pouco mais complexas do SQL, no o fazemos com o
propsito de intimid-lo(a). Muito pelo contrrio. Aprendemos com a Teoria Geral dos Sistemas
que sempre que h um problema complexo, possvel dividi-lo em problemas menores at
que estes sejam de fcil resoluo. com esta definio em mente que apresentaremos nesta
unidade uma grande variedade de exemplos que podem ser solucionados com estas consultas
mais elaboradas da SQL.
117
Nas prximas sees, abordaremos consultas envolvendo valores nulos, subqueries, consultas
com joins e consultas com funes de agregao; alm dos comandos de alterao de schema.
CONSULTAS ENVOLVENDO NULL

Ns j abordamos na Unidade III que o valor NULL representa um valor ausente, mas que
pode ter diferentes interpretaes. Algumas possibilidades de uso para o valor NULL so:

O valor desconhecido. Pensando na tabela telefone do exemplo da Unidade IV, um

telefone pode ser NULL se voc no sabe o valor do telefone do contato.
O valor no est disponvel. No caso do telefone, voc conhece o nmero do telefone

do contato, mas no gostaria que ele fosse exibido ou armazenado, setando o valor
NULL para represent-lo.
O valor no aplicvel. Caso algum contato no tenha telefone, certamente no faz

sentido armazenar esta informao.
A avaliao de comandos de consulta SQL com valores NULL merece uma ateno especial.
Todos os fundamentos de computao baseiam-se na lgica booleana, o que implica que as
expresses possuem sempre somente dois valores possveis: verdadeiro (TRUE) ou falso
(FALSE).
Como em SQL os atributos podem ter valor nulo, agora as expresses que envolvem os
atributos podem resultar em valores verdadeiros (TRUE), falso (FALSE) ou um terceiro valor
que representado por NULL. Este terceiro valor pode ser checado de um modo especial com
os operadores SQL definidos, como IS e IS NOT. Ademais, todas as condies da clusula
WHERE de comandos SQL filtram as linhas baseando-se no valor verdadeiro (TRUE) das
expresses. Nesse caso, linhas que sejam avaliadas pelas expresses da clusula WHERE
como falso (FALSE) ou como o valor representado por NULL simplesmente so descartadas
(com exceo da operao de OUTER JOIN que veremos mais adiante nesta unidade).
Comecemos com alguns exemplos ainda baseados no schema apresentado na Unidade IV.
Exemplo 1: Selecione todos os contatos que no possuem data de nascimento definida.
SELECT *
FROM contato
WHERE nascimento IS NULL;
Exemplo 2: Situao oposta a do Exemplo 1, selecionaremos todos os contatos que possuem

uma data de nascimento definida.
SELECT *
FROM contato
WHERE nascimento IS NOT NULL;
Consultas aninhadas (Subqueries)

Algumas consultas em SQL so mais facilmente construdas se pudermos buscar
primeiramente alguns valores das tabelas e utiliz-los posteriormente em nossa consulta.
Estas consultas diferenciadas podem ser formuladas com uma certa convenincia por meio
de consultas aninhadas (uma consulta dentro de outra) ou, como popularmente denominadas,
de subqueries.
Exemplo 3: Selecione todos os telefones de contatos com sobrenome = Machado.
SELECT telefone
FROM telefone, contato
WHERE contato.id = telefone.contato_fk and sobrenome = Machado;
A consulta acima foi criada utilizando-se um join normal. Agora no exemplo abaixo a
reescreveremos utilizando uma subquery.
119
SELECT telefone
FROM telefone
WHERE contato_fk IN
(
SELECT id
FROM contato
WHERE sobrenome = Machado
);
Uma dvida comum a muitos desenvolvedores est relacionada frequncia de uso de cada
opo. Matematicamente, de acordo com o modelo relacional, no h diferena entre as duas
consultas: so equivalentes. Toda consulta que utiliza um join pode ser reescrita na forma
de uma consulta aninhada (com subqueries). Decidir entre uma forma e outra passa a ser
uma questo de gosto, convenincia e legibilidade de cdigo. H alguns anos, poderia ser
argumentado que uma forma seria mais rpida que outra ou vice-versa. Entretanto, devido
evoluo dos interpretadores de SQL nos SGBDs modernos, esta diferena hoje praticamente
nula: todos os SGBDs modificam internamente as consultas fornecidas e automaticamente j
escolhem o melhor plano de execuo. Isto faz com que boa parte das supostas otimizaes
que muitos DBAs realizam em consultas SQL tornem-se incuas, pois o SGBD na maioria das
vezes reescrever as consultas para a melhor forma possvel2.
No exemplo acima, note o uso da clusula IN (<subquery>). A clusula IN espera um conjunto
de valores sendo retornado pela subquery dentro dos parnteses, que deve ser compatvel
com o atributo sendo comparado pela clusula IN. Na hiptese de voc ter certeza da sua
subquery retornar um nico valor ao invs de retornar um conjunto de valores, pode substituir
o IN pelo operador de igual (=). Mas mesmo nas situaes de um nico valor sendo retornado
2
Justia seja feita, em algumas situaes (talvez 5% ou 10% dos casos), um bom conhecimento do funcionamento
do interpretador SQL do SGBD pode fazer diferena. Mas como j citou Knuth (1974, p.268), a otimizao prematura
a raiz de todo o mal. Primeiro implemente os casos de uso de seu software e depois, num eventual gargalo, otimize.
o operador, IN continua equivalente. por este motivo que muitos programadores acabam
adotando a conveno de se utilizar o operador IN em todas as consultas que envolvem
subqueries.
Considere nos exemplos a partir de agora o seguinte schema representado pela Figura 7:

funcionrio
id
nome
sobrenome
cargo
subordinado
id
nome
sobrenome
superior_fk
Figura 7
Fonte: o autor
O schema da Figura 7 pode ser construdo da seguinte forma:
121
CREATE TABLE funcionario (

id int primary key,
nome varchar(30),
sobrenome varchar(30),
cargo varchar(30)
);
CREATE TABLE subordinado (
id int primary key,
nome varchar(30),
sobrenome varchar(30),
superior_fk int,
FOREIGN KEY (superior_fk) REFERENCES funcionario(id)
);
Exemplo 4 Selecione o nome e sobrenome de todos os funcionrios que possuem subordinados

com o mesmo nome.
SELECT f.nome, f.sobrenome
FROM funcionario AS f, subordinado AS s
WHERE f.id = s.superior_fk AND f.nome = s.nome;
Reescrevendo o exemplo acima com uma subquery:

FROM funcionario AS f
WHERE id IN(
SELECT superior_fk
FROM subordinado AS s
WHERE f.nome = s.nome
);
Este exemplo reescrito com uma subquery um caso especial de consulta aninhada em
SQL, pois como pode notar, a subquery utiliza atributos da consulta externa em sua clusula
WHERE. Chamamos este caso especial de consultas aninhadas correlacionadas.
WHERE EXISTS (
SELECT *
WHERE f.nome = s.nome
);
Apresentamos a mesma consulta do exemplo reescrita acima com um novo operador

denominado de EXISTS. Este operador retorna um resultado verdadeiro (TRUE) se a sua
subquery retornar ao menos uma linha de resultado e falso (FALSE) se o resultado for vazio.
Exemplo 5: Selecione o nome e o sobrenome de todos os funcionrios que no possuem
subordinados.
WHERE NOT EXISTS (
SELECT *
WHERE s.superior_fk = f.id
);
A exemplo do operador EXISTS, o operador NOT EXISTS retorna o oposto do operador

EXISTS, sendo falso (FALSE) se o resultado possui ao menos uma linha e verdadeiro (TRUE)
se o resultado for vazio.
123
CONSULTAS UTILIZANDO JOINS

Na Unidade IV ns vimos que o conceito de join permite que faamos consultas que
utilizam duas ou mais tabelas, unidas por meio de uma ou mais condies que unem
os elementos das duas ou mais tabelas. Em alguns casos, mais fcil compreender as
consultas se estas forem escritas na forma com join ao invs de misturar as condies de
join na clusula WHERE.
Voltemos a utilizar o schema definido na Unidade IV em nossos exemplos abaixo.
Exemplo 6: Selecione o nome de todos os contatos cujo telefone inicie com 44.
SELECT nome
FROM contato, telefone
WHERE contato.id = telefone.contato_fk and telefone.telefone LIKE 44%;
Agora vejamos esta mesma consulta reescrita com um JOIN:

SELECT nome
FROM (contato JOIN telefone ON contato.id = telefone.contato_fk)
WHERE telefone.telefone LIKE 44%;
Neste caso do exemplo reescrito com JOIN, a clusula FROM possui uma joined table que
contm todos os atributos de ambas as tabelas unidas pelo JOIN e pela condio do JOIN,
que o predicado aps o ON.
Na SQL o tipo de JOIN padro quando simplesmente declarado pela clusula JOIN o inner
join, que descarta todas as tuplas que no possuam um valor correspondente na segunda
tabela do JOIN. Os outros tipos de JOIN disponveis so descritos na tabela a seguir:
Tipo de JOIN
Semntica
INNER JOIN
o tipo de JOIN padro. Somente

tuplas que satisfaam a condio do
JOIN so selecionadas.
LEFT OUTER JOIN ou LEFT JOIN
Todas as tuplas da tabela do lado esquerdo do ON so selecionadas. Caso

no haja uma tupla correspondente na
tabela do lado direito do JOIN, os valores so preenchidos com NULL.
RIGHT OUTER JOIN ou RIGHT JOIN
a condio inversa do LEFT JOIN.

Todas as tuplas da tabela do lado
direito do ON so selecionadas. Caso
no haja uma tupla correspondente na
tabela do lado esquerdo do JOIN, os
valores so preenchidos com NULL.
FULL OUTER JOIN ou FULL JOIN
Todas as tuplas dos dois lados do

JOIN so selecionadas. Caso no
haja correspondncia na condio do
JOIN, o lado vazio preenchido com
NULL.
Exemplo 7: Selecione todos os nomes de contatos que iniciem com a letra A e seus
respectivos telefones. Se o contato no tiver um telefone, mostre somente o nome e NULL
como o valor do telefone.
SELECT nome, telefone
FROM contato LEFT JOIN telefone ON contato.id = telefone.contato_fk
WHERE contato.nome LIKE A%;
Um caso tpico de LEFT JOIN em que voc deseja listar todos os contatos, tendo eles
telefone ou no.
125
CONSULTAS COM FUNES DE AGREGAO

Uma das grandes vantagens da SQL e dos bancos de dados relacionais, se comparados
com outras alternativas no relacionais, so as suas funes de agregao. Estas funes
permitem uma anlise resumida das informaes armazenadas nas tabelas. Funes de
agregao populares da SQL incluem COUNT, SUM, MAX, MIN e AVG que executam as
funes matemticas respectivas de contagem, soma, valor mximo, valor mnimo e mdia
aritmtica.
Exemplo 8: Selecione o peso mnimo e mximo de todos os contatos.
SELECT MAX(peso), MIN(peso)
FROM contato;
As funes de agregao em SQL recebem como parmetro o nome do atributo em que se

deseja aplic-las. Neste exemplo, o caso do atributo peso.
Exemplo 9: Selecione o nmero total de contatos cujo peso > 80;
SELECT COUNT(*)
FROM contato
WHERE peso > 80;
Neste uso da funo COUNT, o asterisco (*) representa o nmero de linhas do resultado da
consulta, e bastante utilizado para se determinar a quantidade de resultados retornados.
Exemplo 10: Selecione a quantidade de pesos distintos de todos os contatos.
SELECT COUNT(DISTINCT peso)
FROM contato;
Neste exemplo contamos a quantidade de pesos distintos de nossos contatos. Caso a clusula
DISTINCT no fosse aplicada, contaramos somente a quantidade de pesos dos contatos.

Funes de agrupamento
Em muitas situaes, desejamos aplicar as funes de agregao no em todos os itens
das tuplas selecionadas, mas em determinados grupos de tuplas separados dentro da
tabela baseados em um determinado valor. Para conseguir este objetivo em SQL, utilizamos
a clusula GROUP BY. Ao utilizarmos o GROUP BY, separamos as tuplas em grupos distintos
em que todas tuplas dentro de um determinado grupo possuem o mesmo valor avaliado pelas
condies do GROUP BY.
Exemplo 11: Selecione o sobrenome e quantidade de contatos que possuem o mesmo
sobrenome.
SELECT sobrenome, COUNT(*)
FROM contato
GROUP by sobrenome;
Na avaliao desta consulta, todas as tuplas da tabela contato so divididas em grupos cujo
sobrenome seja igual. Ao aplicarmos a funo COUNT(*), ao invs dela contar todas as tuplas
da tabela, ela conta somente as tuplas de cada grupo. O resultado uma lista que contm os
sobrenomes e as quantidades de contatos com cada sobrenome.
Exemplo 12: Selecione o sobrenome e quantidade de contatos que possuem o mesmo
sobrenome, desde que haja pelo menos dois contatos com o mesmo sobrenome.
SELECT sobrenome, COUNT(*)
FROM contato
GROUP by sobrenome
HAVING COUNT(*) > 1;
Em algumas situaes, desejamos agrupar as tuplas em grupos, mas queremos selecionar
127
apenas alguns destes grupos no resultado e no todos. A clusula que permite filtrar quais
grupos sero exibidos no resultado a HAVING. Somente grupos que satisfaam a condio
imposta pelo HAVING so selecionados no resultado.
importante salientar a diferena entre as clusulas WHERE e HAVING, pois
aparentemente ambas filtram os resultados da consulta. A clusula WHERE filtra as tuplas
avaliadas primeiramente. Portanto, a clusula WHERE avaliada antes de qualquer funo
de agregao ou qualquer agrupamento ser avaliado. J a clusula HAVING avaliada
somente depois que os grupos j foram formados, e serve ento para filtrar estes grupos
do resultado final.
COMANDOS DE ALTERAO DE SCHEMA

Ns definimos como schema evolution o processo de alteraes da estrutura do schema.
Normalmente, estas alteraes de estrutura no so frequentes e so motivadas por alteraes
dos requisitos do negcio, e consequentemente tambm da aplicao.
Os comandos em SQL que podem alterar as definies de schema so os comandos para
adicionar, modificar e remover schemas, tabelas, atributos e restries. Vamos abord-los nos
exemplos seguintes.
Exemplo 13: Remova o schema agenda do banco de dados.
DROP SCHEMA agenda;
Este comando remove o schema, e por consequncia, todas as tabelas dentro do schema. H
uma certa controvrsia neste comando. Alguns SGBDs removem todas as tabelas do schema
ao remover o prprio schema. Outros s permitem a remoo do schema se ele no contiver
nenhuma tabela, sendo necessrio remover todas as tabelas antecipadamente.
Exemplo 14: Remova a tabela telefone do schema.

DROP TABLE telefone;
Neste exemplo, a tabela telefone seria removida do schema. importante notar que a tabela
sendo removida do schema pode conter dependncias de integridade referencial e chave
estrangeira em outras tabelas. Nesse caso, se alguma outra tabela depender da tabela sendo
removida, este comando ir falhar devido restrio de integridade referencial do banco,
sendo necessrio primeiro remover a integridade referencial.
Exemplo 15: Adicione uma coluna apelido na tabela contato contendo 15 caracteres.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15);
Este exemplo adiciona uma coluna denominada apelido no final da definio da tabela contato
com o tipo definido de VARCHAR(15). Quando um valor DEFAULT no especificado no ALTER
TABLE, todas as tuplas existentes na tabela recebem um valor NULL na coluna adicionada.
Exemplo 16: Adicione uma coluna apelido na tabela contato contendo 15 caracteres e com
valor padro de Senhor.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15) DEFAULT Senhor;
O Exemplo 16 a mesma situao do Exemplo 15, apenas definindo um valor padro para a
coluna sendo adicionada.
Exemplo 17: Altere o tamanho da coluna apelido para 25 caracteres.
ALTER TABLE contato ALTER COLUMN apelido VARCHAR(25);
A definio da coluna apelido da tabela contato foi modificada e o seu tipo de dados agora
define a capacidade de 25 caracteres.
129
Exemplo 18: Remova a coluna apelido da tabela contato.

ALTER TABLE contato DROP COLUMN apelido;
A coluna apelido removida da tabela contato desde que no haja nenhuma restrio de
integridade referencial nesta coluna.
Exemplo 19: Supondo que ainda no houvesse uma integridade referencial entre a tabela
telefone e a tabela contato, adicione-a.
ALTER TABLE telefone ADD FOREIGN KEY (contato_fk) REFERENCES contato(id);
Este comando adiciona a restrio de integridade referecial entre a tabela telefone e a tabela
contato.
Tambm possvel remover as restries de integridade referencial por meio do comando
ALTER TABLE <tabela> DROP FOREIGN KEY <nome>, mas para tanto, necessrio saber
o nome da restrio no banco de dados. Como os comandos para exibio das restries das
tabelas variam muito de um produto para outro, deixaremos esta soluo como uma sugesto
de estudo para voc.
<http://youtu.be/S2iQ2RKMw-w>.
Entrevista com Fernando de la Riva, scio-diretor da Concrete Solutions, falando das perspectivas
para o mercado em 2012, incluindo Cloud Computing e NoSQL.
NoSQL, sem problemas

Uma introduo a banco de dados NoSQL
Desvendar o NoSQL e tentar explicar o que e por que voc deveria se interessar ou no uma tarefa
difcil. Este artigo tenta dar uma introduo de alto nvel ao NoSQL e fornece uma comparao das
ltimas tecnologias disponveis desta rea.
introduo
Desvendar o NoSQL e tentar explicar o que e por que voc deveria se interessar ou no uma tarefa
difcil. O termo cobre uma grande variedade de tecnologias, arquitetura de dados e prioridades; ele
representa tanto um movimento quanto a uma escola de pensamento ou uma tecnologia particular.
Mesmo o nome confuso, pois para alguns, isto representa qualquer mecanismo de armazenamento
de dados que no utilize SQL, mas at agora a indstria parece ter estabelecido como Not Only SQL
(no somente SQL). medida que o tempo passe, provvel que o termo cresa at o momento em
que perca o sentido e subdivises tornem-se necessrias para clarifi car o signifi cado do termo.
O que NoSQL?
O movimento NoSQL um pedao de um marketing de guerrilha que traz um grande grupo de tecnlogos e tecnologias sob a mesma bandeira. As ideias que baseiam a infi nidade de soluo que existe
sob o termo NoSQL antes estavam somente disponveis para aqueles cujas necessidades tornaram
necessria uma implementao prpria e especfi ca. Nas reas em que estas solues so uma
necessidade, seu valor j foi provado, e agora o uso destas solues passou a ser uma opo para
outros com um custo de investimento muito menor. Para qualquer organizao que tenha que escolher
entre NoSQL e dados relacionais tradicionais, h a difcil questo de qual das duas utilizar. Ainda
muito cedo para fornecer uma resposta decisiva e defi nitiva, mas est claro que muitas organizaes
podem se benefi ciar de um modelo de dados que se encaixe melhor nos tipos de armazenamento e
consulta que eles executam na prtica do que na teoria. Tambm parece provvel que a maioria das
solues consistir de um hbrido misto de tecnologias de armazenamento, assim como um misto
de estruturas de N-camadas e cliente-servidor tende a ser mais comum do que comprometimentos
absolutos com uma nica estratgia.
Lderes tcnicos tm um papel importante na compreenso das opes disponveis e na adaptao do
software, produtos e servios que mais se aplicam ao seu domnio de negcios. Possuir uma estratgia lgica e localizada para a adoo do que o NoSQL oferece de melhor ser o fator que diferenciar
131
o sucesso do fracasso em sua adoo.

Assim como o NoSQL apresenta novos desafios, ele tambm oferece recompensas significativas
queles que o incorporam com sucesso no seu portfolio de soluo. Os principais benefcios viro
da maior compreenso sobre os dados, escalonamento flexvel e produtividade. A rica variedade de
novos modelos de negcios possuem requisitos de armazenamento que so suportados pelo NoSQL
e as dcadas de coero de dados em modelos relacionais ficaram para trs.
NoSQL uma rea grande e em expanso. Para os propsitos deste artigo, as caractersticas mais
comuns de banco de dados NoSQL so:
1. Facilidade de uso em clusters com balanceamento de carga tradicionais;
2. Dados persistentes (no somente cachs);
3. Escalabilidade na memria disponvel;
4. No possuem schemas fixos e permitem a migrao de schemas sem indisponibilidade;
5. Possui sistemas de consulta individuais ao invs de uma linguagem de consulta padro;
6. So ACID dentro de um n no cluster e eventualmente consistentes dentro do cluster.
Nem todos os produtos deste artigo possuem todas estas propriedades, mas a maioria dos bancos de
dados que discutiremos suporta boa parte destas caractersticas.
O que est acontecendo agora?
Movimentos em tecnologia ou em correntes de pensamento raramente acontecem de modo totalmente espontneo. Existem trs principais motivaes por trs do elevado interesse em NoSQL. Primeiro
foi o surgimento de uma nova forma de perfil de trfego provocada pelo que pode ser chamado de
Web 2.0 ou de Web Social, assim como a Internet de varejo.
Web Scale, como comumente referido, o problema de capacidade de planejamento, escala e
provisionamento que tornou-se crtico para muitos negcios na Web nos ltimos cinco anos. medida
que o mundo torna-se mais conectado, possvel que sites recebam variaes enormes de trfego.
Algumas destas esto relacionadas a eventos previsveis: a Copa do Mundo ou o Natal; outros so
imprevisveis e globais, como por exemplo, o 11 de Setembro. Sites como o Facebook tornaram fcil a
escalada de popularidade de sites medida que itens tornam-se virais e so distribudos pelo mundo
todo.
Contedos criados pelo usurio causam dores de cabea particulares, pois os problemas relacionados a websites com leitura intensiva j so solucionados com a utilizao de contedo esttico e
CDNs (Content Distribution Networks Redes de Distribuio de Contedo). Contedos criados pelo
usurio significam que os sites tornam-se mais equilibrados no quesito leitura-escrita. Sites como
o Twitter recebem montanhas de trfego em intervalos muito curtos de tempo (um gol validado ou
invalidado, a apurao de uma votao ou o final de um seriado ou novela de TV), e sua infraestrutura
deve se adaptar rapidamente para no ficar indisponvel na hora errada. A abordagem normal para
escalabilidade tem sido adicionar novos servidores web, que funciona at o ponto em que o banco de
dados (que historicamente tem sido um nico grande servidor) torna-se o gargalo. A resposta ento
comprar progressivamente um hardware cada vez mais poderoso at que o banco de dados possa
servir todo o trfego. A Web Scale invalida este modelo quando voc tem que enfrentar o dilema de
comprar um hardware caro para atender sua demanda de pico (Natal ou Copa do Mundo), mas que
ficar quase que totalmente ocioso no dia a dia. Para alguns empreendimentos, simplesmente impossvel comprar o hardware e as licenas de software para atender a demanda de pico atravs de
um nico servidor. Estes empreendimentos tm procurado uma soluo de dados escalvel que possa
espelhar a estrutura da prpria Web.
A segunda motivao o fato de que os dados mudam com o passar do tempo. Com a evoluo do
modelo de negcios, os modelos de dados normalmente contorcem-se para evoluir e manter o ritmo
das mudanas. O resultado normalmente uma estrutura de dados repleta de linguagens arcaicas e
remendadas com dados adaptados. Qualquer um que j teve que explicar que o valor de uma coluna
possui um significado diferente dependendo se o valor for menor ou maior que 10 ou que padaria
na verdade significa armazm devido a um erro anterior, sabe que o peso do histrico no modelo de
dados pode ser um srio entrave na manuteno do sistema e na incorporao de novas ideias de
negcios.
A motivao final que a tecnologia de NoSQL est comeando a se tornar um commodity. Amazon
e Google no tiveram escolha no passado a no ser desenvolver sua prpria soluo para resolver
os problemas de escala. O custo de escrever tal soluo impediu muitas empresas que no tinham
estes problemas no corao de seus negcios de explorar esta nova tecnologia. Recentemente uma
srie de doaes de cdigo para entidades como a Apache Foundation ou outros grupos de open
source que fornecem desenvolvimento e suporte baseado em comunidades trouxe a possibilidade de
se utilizar cdigo extremamente sofisticado com um baixo custo de manuteno. Tais cdigo colocam
o NoSQL firmemente ao alcance de empresas menores. Ao invs de ser um assunto esotrico, agora
os bancos de dados NoSQL podem ser baixados e integrados arquitetura corporativa em questo
de semanas.
Est sendo realmente utilizado?
Uma questo comum que se pergunta sobre o NoSQL se ele realmente est sendo utilizado ou se
somente uma moda. A resposta que se voc alguma vez j utilizou servios da Amazon, Yahoo
ou Google ento voc teve os dados fornecidos atravs de uma soluo NoSQL. Se voc j utilizou
o eBay ou o Twitter, voc indiretamente j utilizou bancos de dados que possuem muito pouco em
comum com bancos de dados tradicionais, (por exemplo, o eBay no utiliza transaes e o Twitter
utiliza um banco de dados de grafos para saber quem segue quem).
Normalmente a questo realmente significa se pessoas como eu esto realmente utilizando NoSQL.
133
A resposta que se voc est enfrentando problemas lidando com certos tipos de dados, ento h
um diferencial competitivo em potencial ao se avaliar uma soluo NoSQL. A rea nova o suficiente
para que muitos negcios sintam-se desconfortveis executando trabalho crtico em qualquer outro
software que no seja um maduro banco de dados relacional, mesmo que estes bancos de dados
relacionais causem vrios problemas e tenham suas diversas limitaes.
Por que voc utilizaria um banco de dados NoSQL?
Uma das principais motivaes se voc tiver problemas em seu negcio que so difceis de se
resolver utilizando a tecnologia de banco de dados relacional. Se voc possui um excelente modelo
relacional com um banco de dados maduro que fornece todas as funcionalidades que voc precisa,
ento h pouca necessidade de se alterar seu mecanismo de armazenamento de dados.
A seguir esto alguns casos de uso em que subtimo utilizar um banco de dados relacional:

Seu banco de dados relacional no escalar seu trfego a um custo aceitvel;
Seus dados so fornecidos em pequenas mudanas ao longo do tempo, de modo que o nmero de tabelas necessrias para manter a forma normal cresceu desproporcionalmente em
relao aos dados sendo mantidos. Informalmente, se voc no consegue mais imprimir o seu
DER num papel A3, voc deve ter alcanado este problema ou voc est armazenando muita
coisa num nico banco de dados;
Seu modelo de negcios gera muitos dados temporrios que no pertencem ao banco de
dados principal. Exemplos comuns incluem carrinhos de compras, critrios de pesquisa salvos,
personalizao do site e questionrios de usurio incompletos;
Seu banco de dados relacional est denormalizado por motivos de desempenho ou por convenincia ao manipular dados na aplicao;
Seus conjuntos de dados consistem em grandes quantidades de texto ou imagens e as definies de coluna so simples LOBs (CLOB ou BLOB);
Voc tem que executar consultas em seus dados que no envolvem simples relaes hierrquicas; exemplos comuns so questes de recomendaes ou de business intelligence que
envolvem a ausncia de dados;
Voc possui transaes de dados que no precisam de muita durabilidade. Por exemplo, o
curtir de itens em websites: criar transaes para este tipo de interao so um exagero, pois
se a ao falhar o usurio provavelmente ir repetir a ao at que funcione. Websites com
muito AJAX tendem a ter muitos desses casos de uso.
Maturidade da linguagem de consultas

Uma das queridinhas que corre o risco de ser deixada de lado a SQL. O NoSQL escolheu a SQL
como o monstro a ser derrotado, mesmo que na realidade a SQL seja somente um padro muitas
vezes deturpado por implementaes customizadas. A SQL possui muitas vantagens que os produtos
NoSQL tero que tratar ao longo do tempo. Primeiramente, ela madura, refinada e geralmente atende s expectativas dos usurios. Possui uma sintaxe coerente e rica em funcionalidades, o que significa que pessoas que produzem consultas SQL complexas certamente reclamaro se tiverem que replicar operadores como SUM, ORDER BY e GROUP numa tarefa do tipo map-reduce em JavaScript.
Mesmo os fornecedores reconhecem este problema. Se eles no forem capazes de encontrar um
conjunto comum de operaes de manipulao de dados, ento provvel que uma outra implementao torne-se popular e seus usurios migraro para este outro produto. Ou todos os fornecedores
tero que implementar o mesmo conjunto de comandos do lder de mercado para manterem-se competitivos.
J h alguns padres disponveis como a SparQL, um padro para fazer consultas em RDF ou dados
em tuplas. Este poderia ser adaptado para bancos de dados de documentos e grafos, mas mesmo
assim ainda no h nada que fornea um conjunto modular de comandos de consulta que possa ser
comparado SQL.
uma ironia que os produtos NoSQL mais complexos que os bancos de dados de chave-valor tero
que implementar algo muito similiar SQL se quiserem ter o mesmo nvel de utilizao que os produtos de dados relacionais tm hoje. Em alguns casos este fato se esconde por trs do slogan Not Only
SQL, concordando que simplesmente jogar fora a SQL seria doloroso demais.
Novas tecnologias, novos desafios
Na tentativa de se incorporar o NoSQL em sistemas de larga escala existentes, v-se que obviamente mais fcil se a sua aplicao possui um baixo acoplamento entre os componentes. Nesta situao
mais fcil identificar reas que se beneficiariam da soluo NoSQL e implementar esta integrao aos
poucos. Na situao em que o armazenamento de dados monoltico e que os sistemas dependem
de certas propriedades do modelo relacional por exemplo, tipos de dados ou consistncia transacional ento o problema muito mais difcil. Em alguns casos o desacoplamento dos dados a primeira
tarefa a ser executada ao invs da migrao do armazenamento dos dados.
Do ponto de vista da soluo, h a necessidade de se analisar claramente quais dados so relacionais
e quais dados esto armazenados em bancos de dados relacionais por falta de outra alternativa. Tambm importante revisar decises histricas e verificar se estas foram feitas com restries histricas
em mente. Um exemplo particular o uso de bancos de dados de grafos ao invs de uma estrutura
complexa de tabelas relacionais. perfeitamente possvel criar conjuntos de relacionamentos N-N em
dados relacionais e ento consultar as interseces destes relacionamentos, mas expressar somente
os relacionamentos num banco de dados de grafos uma soluo muito mais simples.
Existem algumas reas bvias em que o NoSQL pode ser aplicado imediatamente. Contedo de
websistes pode ser geralmente expresso em bancos de dados de documentos ou de chave-valor.
135
Exemplos particulares destas situaes so as metforas de formulrios e de wizards de formulrios.

Qualquer formulrio pode ser expresso diretamente na forma de um documento. Dados de buscas so
outro exemplo, pois muitos dados de referncia consistem em mapas, listas e conjuntos, referncias,
pases, estados, cidades etc. Analisando estes padres nos dados, devem surgir novas oportunidades
de uso do NoSQL.
Analisando de um modo mais estratgico, sistemas que precisam evoluir e mudar seus dados com
frequncia possuem uma boa chance de utilizar um banco de dados sem schema. Se a migrao de
estruturas de dados sem indisponibilidade for um diferencial competitivo, ento este um forte indicador de que o uso de uma soluo NoSQL seria valioso.
Tipos de bancos de dados NoSQL
As prximas sees descrevem os diferentes tipos de bancos de dados NoSQL.
Bancos de dados chave-valor
Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort e Oracle BDB.
Aplicaes Tpicas: Cach de contedo.
Pontos Fortes: Acesso rpido.
Pontos Fracos: Os dados armazenados no tm schema.
Aplicao de exemplo: Voc est escrevendo um software de frum em que a pgina do perfil fornece
as estatsticas do usurio (mensagens postadas etc.) e as ltimas dez mensagens escritas por ele. A
pgina l estes dados baseada numa chave que o id do usurio e recupera uma String JSON que
representa todas estas informaes. Um processo em background recalcula esta informao a cada
15 minutos e grava no banco de dados de modo independente.
Banco de dados de documentos
Exemplos: CouchDB e MongoDB.
Aplicaes Tpicas: Aplicaes Web.
Pontos Fortes: Tolerncia com dados incompletos.
Pontos Fracos: Desempenho em consultas, no h uma sintaxe de consulta padro.
Aplicao de exemplo: Voc est criando um software que cria perfis de crianas refugiadas com o
propsito de reuni-las novamente com suas famlias. Os detalhes que voc precisa gravar de cada
criana podem variar muito de acordo com as circunstncias do evento e elas so construdas aos
poucos. Por exemplo, uma criana pequena pode saber o seu primeiro nome e voc pode tirar uma
foto dela, mas pode no saber os nomes de seus pais. Mais tarde um conhecido pode reconhecer a
criana e fornecer informaes adicionais que voc pode querer gravar, mas at conseguir confirmar,
voc ter que tratar estas informaes com ceticismo.
Banco de dados de grafos

Exemplos: Neo4J, InfoGrid e Infinite Graph.
Aplicaes Tpicas: Redes sociais.
Pontos Fortes: Algoritmos de grafos, por exemplo: caminho mais curto, conectividade, graus de relacionamento etc.
Pontos Fracos: Tem que percorrer todo o grafo de modo a encontrar uma resposta. No simples de
clusterizar.
Aplicao de exemplo: Qualquer aplicao que requeira conectividade social uma candidata a um
banco de dados de grafos. Este mesmo princpio pode ser estendido a qualquer aplicao em que
voc precisa saber o que as pessoas esto fazendo, comprando ou curtindo de modo a recomendar
aes futuras. Em qualquer momento voc pode responder a questes como Quais restaurantes
receberam votos negativos das irms de pessoas com mais de 40 que gostam de esquiar e que
visitaram o Qunia?.
Bancos de dados de XML
Exemplos: Exist, Oracle, MarkLogic.
Aplicaes Tpicas: Publicao.
Pontos Fortes: Tecnologias de busca maduras e validao de schema XML.
Pontos Fracos: No uma soluo binria pura, mais fcil reescrever um documento do que atualiz-lo.
Aplicao de exemplo: Uma editora que utiliza formatos XML para produzir verses web, impressa e
eBook de seus artigos. Os editores precisam fazer buscas rpidas tanto no texto quanto em sees
semnticas do XML. Eles armazenam o XML dos artigos finalizados no banco de dados XML e os encapsulam em web services para os sistemas de produo de documentos. Quando mudanas so necessrias, atualizaes utilizando XQuery modificam todos os documentos XML para o novo formato.
Bancos de dados ponto-a-ponto distribudos
Exemplos: Cassandra, HBase e Riak.
Aplicaes Tpicas: Sistemas de arquivo distribudos.
Pontos Fortes: Buscas rpidas e boa distribuio do armazenamento dos dados.
Pontos Fracos: API de baixo nvel.
Aplicao de exemplo: Voc possui um site de notcias em que qualquer tipo de contedo (artigos,
comentrios, perfis de autores etc.) pode ser votado e pode ter um comentrio opcional no voto. Voc
pode criar uma base por usurio e uma base por tipo de contedo utilizando um UUID como chave
137
(gerado a partir de cada tipo de contedo e usurio). O bucket do usurio mantm cada voto dele,
enquanto que o bucket do contedo contm uma cpia de cada voto que j foi feito para aquele
contedo. Durante a noite, um processo batch identifi ca em quais contedos os usurios votaram e
voc gera uma lista de contedo que possui muitos votos para cada usurio, mas que os usurios
ainda no votaram. Esta lista uma lista de artigos recomendados para o usurio e fi ca armazenada
no bucket de recomendaes.
Banco de dados de objetos
Exemplos: Oracle Coherence, db4o, ObjectStore, GemStone e Polar.
Aplicaes Tpicas: Sistemas fi nanceiros.
Pontos Fortes: Refl ete o paradigma de desenvolvimento orientado a objetos, baixa latncia ACID e
tecnologia madura.
Pontos Fracos: Consultas limitadas ou operaes de mltiplas atualizaes.
Aplicao de exemplo: Uma empresa de comrcio internacional quer fazer transaes a partir do
Japo e Nova York e verifi c-las atravs de um processo de anlise de risco em Londres. Um objeto
representando a transao gravado no banco de dados de objetos e o analisador de riscos est
aguardando pelas notifi caes de objetos de transaes. Quando um objeto replicado no datacenter
europeu, o analisador de riscos l a transao e verifi ca o risco da mesma. Ele ento reescreve o
objeto para informar que a transao foi autorizada e gera uma venda. O cliente est aguardando por
mudanas nos objetos e recebe uma notifi cao de que a sua transao foi aprovada.
Concluso
Dados tabulares permanecem tabulares e a planilha de clculo ainda a ferramenta de modelagem
de dados favorita no mundo dos negcios. SQL no vai morrer to cedo. Entretanto, at agora ns
temos criado sistemas baseados nas restries de um tpico banco de dados relacional. O NoSQL
oferece a chance de se pensar de um modo diferente sobre os dados e uma possibilidade extremamente excitante.
Robert Rees.
Fonte: <http://www.thoughtworks.com/articles/nosql-comparison>. Acesso em: 13 ago. 2012.
CONSiDErAES FiNAiS
Finalmente chegamos ao fim de nossa ltima unidade deste material. Neste ponto, voc
provavelmente j ter assimilado contedo suficiente para poder j desenvolver algumas

aplicaes utilizando sistemas de bancos de dados.
Como descrevemos no incio da unidade, bastante provvel que voc se depare em sua
vida profissional com consultas um tanto quanto complexas. Lembre-se que todo problema
pode ser decomposto em partes menores de fcil soluo. Utilize esta tcnica e aplique os
conceitos assimilados com os exemplos apresentados nesta unidade para resolv-los. Teoria
importantssima, mas a prtica uma atividade fundamental para que voc possa converter
toda esta teoria aprendida em resultados tanto pessoais quanto profissionais.
A prtica das atividades de autoestudo pode auxili-lo(a) na trabalhosa tarefa de assimilao
dos conceitos apresentados nesta unidade. Analise-as com carinho e tenha um bom proveito.
Todas as atividades de autoestudo desta unidade baseiam-se na Figura abaixo.
beneficiario
id
nome
sobrenome
altura
plano_fk
dependente
id
nome
sobrenome
beneficiario_fk
plano
id
nome
valor
1. Considere o exemplo de schema da figura apresentada. Crie os comandos SQL para

definio e criao das tabelas.
2. Elabore consultas SQL para:
a. Selecione todos os beneficirios que possuem dependentes com o mesmo nome
utilizando uma condio de JOIN.
139
b. Execute a mesma consulta anterior utilizando uma subquery.

c. Execute a mesma consulta anterior utilizando uma clusula EXISTS.
d. Selecione o beneficirio que contm dependente que possui a maior altura entre
todos.
3. Utilizando a clusula de GROUP BY, elabore consultas para:
a. Agrupe os beneficirios por nome e selecione o sobrenome e altura de cada um deles.
b. Selecione todos os beneficirios que contm mais de um dependente com o mesmo
sobrenome.
c. Selecione todos os planos que contm mais de um beneficirio com altura > 1.75.
CONCLUSO
Se h uma palavra que possa descrever meu sentimento ao concluir este livro, esta talvez
seja alvio. Sim, entre outras emoes que certamente passam pela minha cabea neste
momento, o alvio de poder concluir este material se destaca. J dizia um antigo ditado sobre a
arte da escrita, e que era direcionado queles que pretendiam produzir qualquer texto: o que
escrito sem esforo lido sem prazer.
No posso me assegurar que voc, carssimo(a) leitor(a), conseguir ler este material com
o prazer que eu gostaria que lhe proporcionasse mas no duvide, certamente as palavras
organizadas neste material foram fruto de um enorme esforo. E no somente de esforo:
tambm de dor, privao de certas liberdades que me foram tomadas pelo tempo dedicado,
desespero por querer mais tempo para poder esculpir melhor alguns pargrafos e a angstia
de saber que na verdade o trabalho nunca termina ele apenas possui uma data de trmino.
Tivesse mais seis meses ou um ano, certamente no o terminaria antes do prazo final. Mas
assim o tambm em tudo aquilo que nos dedicamos.
Antoine de Saint-Exupry escreveu que tu te tornas eternamente responsvel por aquilo que
cativas. Espero que eu possa ter cativado algo com este material e talvez algum, pois esforo
no faltou na elaborao do mesmo.
Certamente durante a leitura de alguns pontos do material, voc pde perceber a grande
inspirao que tenho ao falar de desenvolvimento de software. Sou partidrio da corrente que
acredita que o mais importante de todo e qualquer software o problema que ele resolve e o
quo satisfatrio ele para seus usurios. Considero a utilidade do software como mecanismo
fundamental para qualquer inovao do conhecimento humano atual. E no me agrada observar
alguns programadores valorizando uma ferramenta qualquer em detrimento da utilidade do
software sendo desenvolvido. Este um dos motivos pelos quais eu considero o banco de
dados como apenas um detalhe diante de um projeto maior, que o uso do prprio software.
Como j enfatizado nas unidades do material, o banco de dados apenas um detalhe. Um
detalhe importante, verdade. Mas apenas um detalhe dentro de um escopo muito maior que
a inovao que o software pode proporcionar.
Ao trmino deste material voc provavelmente j ter todas as habilidades necessrias para
integrar um sistema de banco de dados relacional ao software que voc desenvolve. Saber
escolher as opes do mercado baseado(a) nos critrios de classificao que apresentamos
141
e ter com certeza uma pontinha de dvida se deve mesmo utilizar um banco de dados
relacional. Afinal, as leituras complementares, os vdeos e os estudos de caso apresentados no
material tinham como objetivo provocar o senso crtico para libert-lo(a) da priso relacional.
Abra a sua mente e liberte-se de paradigmas preestabelecidos. Saiba decidir qual sistema de
banco de dados deve escolher baseado nos requisitos e utilidade da sua aplicao, ao invs
de tomar decises baseadas em medo, incerteza e dvida.
Se optar por manter-se no ambiente dos sistemas de bancos de dados relacionais, j ter
todos os meios para criar, manipular, popular e consultar bancos de dados relacionais graas
aos conhecimentos de SQL adquiridos. A lista deste material certamente no exaustiva, mas
tambm um bom comeo. Afinal, a jornada do conhecimento nunca acaba.
Baseado(a) em tudo o que voc pode aprender, aproveite bem e utilize todo o contedo que
tentamos transmitir para desenvolver um bom software; software inovador. isto o que eu
sinceramente desejo para sua frutfera jornada. E que est apenas comeando... Bom proveito,
boa sorte e acima de tudo, muito sucesso.
Um grande abrao.
Edson Yanaga.
REFERNCIAS
DATE, C. J. Bancos de dados: tpicos avanados. Rio de Janeiro: Campus, 1988.
KNUTH, Donald. Structured Programming with go to Statements. ACM Journal Computing
Surveys, 6 (4): 268. Dezembro de 1974.
NAVATHE, Shamkant B.; ELMASRI, Ramez. Sistemas de Banco de Dados.
6. ed. Pearson - Addison Wesley, 2011.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco
de dados. So Paulo: Makron Books do Brasil, 1999.
143

Banco de Dados

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

Prof. Me.

Reitor: Wilson de Matos Silva

NEAD - Ncleo de Educao a Distncia

Ficha catalogrfica elaborada pela Biblioteca Central - CESUMAR

CDD - 22 ed. 005.74

BANCO DE DADOS | Educao a Distncia

Caro(a) aluno(a), ensinar no transferir conhecimento, mas criar as possibilidades para a

BANCO DE DADOS | Educao a Distncia

Salve, carssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco

informao atuais exigem que manipulemos no gigabytes ou terabytes de informaes, e sim

BANCO DE DADOS | Educao a Distncia

CONCEITOS DE BANCOS DE DADOS

Scientia potentia est: Conhecimento poder.

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

as estruturas e as restries para os dados a serem armazenados em um banco de

Embora no seja necessrio utilizar um SGBD para se desenvolver quaisquer sistemas de

Bancos de dados Open Source: presente ou futuro?

Os softwares de banco de dados so um dos mais importantes componentes de software de uma

BANCO DE DADOS | Educao a Distncia

g) Recursos de data warehousing e BI.

Viso, estratgia e road map do produto.

k) Tamanho e participao/envolvimento da comunidade.

Modelo de governana adotado pela comunidade.

m) Base instalada e adoo pelo mercado.

BANCO DE DADOS | Educao a Distncia

CArACtErStiCAS DE SiStEmAS DE BANCOS DE DADOS

BANCO DE DADOS | Educao a Distncia

dessas aplicaes. O que todas tm em comum? A necessidade de se armazenar a informao

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

computao, embora seja perfeitamente possvel. Ao lidarmos com sistemas de banco de

A revoluo do Big Data est prestes a acontecer

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

O maior evento da comunidade brasileira de NoSQL:

BANCO DE DADOS | Educao a Distncia

O conceito de transao fundamental em muitas reas da computao, e particularmente

BANCO DE DADOS | Educao a Distncia

a garantia de que todos sejam executados de modo que as informaes armazenadas

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

Papis assumidos pelos usurios de SGBDs

So pessoas que desenvolvem software que armazena

So pessoas que no interagem diretamente com os

BANCO DE DADOS | Educao a Distncia

vANtAgENS DE SE utiliZAr um SgBD

BANCO DE DADOS | Educao a Distncia

BANCO DE DADOS | Educao a Distncia

cachs (caches) para armazenar em memria os dados mais frequentemente acessados.

adequadamente entre uma abordagem e outra.

BANCO DE DADOS | Educao a Distncia

Banco de Dados na Nuvem

Jin Zhang, Diretor de Programas da IBM

BANCO DE DADOS | Educao a Distncia

Etapa um: Desenvolver a base da nuvem

rem as difi culdades de administrao de dados de mudanas de esquema, mapeamento, migrao

BANCO DE DADOS | Educao a Distncia

OS BANCOS DE DADOS E O SOFTWARE

BANCO DE DADOS | Educao a Distncia

SCHEMAS, INSTNCIAS E ABSTRAES

BANCO DE DADOS | Educao a Distncia

qualquer momento do tempo.