banco de dados

Prof. Me. Edson Yanaga
BANCO DE DADOS
graduação
análise e desenvolvimento de sistemas
Sistemas para internet
MARINGÁ-pr
2012
Reitor: Wilson de Matos Silva
Vice-Reitor: Wilson de Matos Silva Filho
Pró-Reitor de Administração: Wilson de Matos Silva Filho
Presidente da Mantenedora: Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Diretoria do NEAD: Willian Victor Kendrick de Matos Silva
Coordenação Pedagógica: Gislene Miotto Catolino Raymundo
Coordenação de Marketing: Bruno Jorge
Coordenação Comercial: Helder Machado
Coordenação de Tecnologia: Fabrício Ricardo Lazilha
Coordenação de Curso: Danillo Xavier Saes
Supervisora do Núcleo de Produção de Materiais: Nalva Aparecida da Rosa Moura
Capa e Editoração: Daniel Fuverki Hey, Fernando Henrique Mendes, Jaime de Marchi Junior, José Jhonny Coelho, Luiz
Fernando Rokubuiti e Thayla Daiany Guimarães Cripaldi
Supervisão de Materiais: Nádila de Almeida Toledo
Revisão Textual e Normas: Cristiane de Oliveira Alves, Gabriela Fonseca Tofanelo, Janaína Bicudo Kikuchi, Jaquelina
Kutsunugi, Karla Regina dos Santos Morelli e Maria Fernanda Canova Vasconcelos.
Ficha catalográfica elaborada pela Biblioteca Central - CESUMAR
CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação
a distância:
C397 Banco de dados / Edson Yanaga. Maringá - PR, 2012.
143 p.
“Graduação em Análise e Desenvolvimento de Sistemas e Sistemas para Internet - EaD”.
1. Banco de dados. 2. Arquitetura de sistemas. 3.EaD. I. Título.
CDD - 22 ed. 005.74
CIP - NBR 12899 - AACR/2
“As imagens utilizadas neste livro foram obtidas a partir dos sites PHOTOS.COM e SHUTTERSTOCK.COM”.
Av. Guedner, 1610 - Jd. Aclimação - (44) 3027-6360 - CEP 87050-390 - Maringá - Paraná - www.cesumar.br
NEAD - Núcleo de Educação a Distância - bl. 4 sl. 1 e 2 - (44) 3027-6363 - [email protected] - www.ead.cesumar.br
BANCO DE DADOS
Prof. Me. Edson Yanaga
APRESENTAÇÃO DO REITOR
Viver e trabalhar em uma sociedade global é um grande desafio para todos os cidadãos.
A busca por tecnologia, informação, conhecimento de qualidade, novas habilidades para
liderança e solução de problemas com eficiência tornou-se uma questão de sobrevivência no
mundo do trabalho.
Cada um de nós tem uma grande responsabilidade: as escolhas que fizermos por nós e pelos
nossos fará grande diferença no futuro.
Com essa visão, o Cesumar – Centro Universitário de Maringá – assume o compromisso
de democratizar o conhecimento por meio de alta tecnologia e contribuir para o futuro dos
brasileiros.
No cumprimento de sua missão – “promover a educação de qualidade nas diferentes áreas
do conhecimento, formando profissionais cidadãos que contribuam para o desenvolvimento
de uma sociedade justa e solidária” –, o Cesumar busca a integração do ensino-pesquisa-extensão com as demandas institucionais e sociais; a realização de uma prática acadêmica que
contribua para o desenvolvimento da consciência social e política e, por fim, a democratização
do conhecimento acadêmico com a articulação e a integração com a sociedade.
Diante disso, o Cesumar almeja ser reconhecido como uma instituição universitária de referência regional e nacional pela qualidade e compromisso do corpo docente; aquisição de competências institucionais para o desenvolvimento de linhas de pesquisa; consolidação da extensão
universitária; qualidade da oferta dos ensinos presencial e a distância; bem-estar e satisfação
da comunidade interna; qualidade da gestão acadêmica e administrativa; compromisso social
de inclusão; processos de cooperação e parceria com o mundo do trabalho, como também
pelo compromisso e relacionamento permanente com os egressos, incentivando a educação
continuada.
Professor Wilson de Matos Silva
Reitor
BANCO DE DADOS | Educação a Distância
5
Caro(a) aluno(a), “ensinar não é transferir conhecimento, mas criar as possibilidades para a
sua produção ou a sua construção” (FREIRE, 1996, p. 25). Tenho a certeza de que no Núcleo
de Educação a Distância do Cesumar, você terá à sua disposição todas as condições para se
fazer um competente profissional e, assim, colaborar efetivamente para o desenvolvimento da
realidade social em que está inserido.
Todas as atividades de estudo presentes neste material foram desenvolvidas para atender o
seu processo de formação e contemplam as diretrizes curriculares dos cursos de graduação,
determinadas pelo Ministério da Educação (MEC). Desta forma, buscando atender essas
necessidades, dispomos de uma equipe de profissionais multidisciplinares para que,
independente da distância geográfica que você esteja, possamos interagir e, assim, fazer-se
presentes no seu processo de ensino-aprendizagem-conhecimento.
Neste sentido, por meio de um modelo pedagógico interativo, possibilitamos que, efetivamente,
você construa e amplie a sua rede de conhecimentos. Essa interatividade será vivenciada
especialmente no ambiente virtual de aprendizagem – AVA – no qual disponibilizamos, além do
material produzido em linguagem dialógica, aulas sobre os conteúdos abordados, atividades de
estudo, enfim, um mundo de linguagens diferenciadas e ricas de possibilidades efetivas para
a sua aprendizagem. Assim sendo, todas as atividades de ensino, disponibilizadas para o seu
processo de formação, têm por intuito possibilitar o desenvolvimento de novas competências
necessárias para que você se aproprie do conhecimento de forma colaborativa.
Portanto, recomendo que durante a realização de seu curso, você procure interagir com os
textos, fazer anotações, responder às atividades de autoestudo, participar ativamente dos
fóruns, ver as indicações de leitura e realizar novas pesquisas sobre os assuntos tratados,
pois tais atividades lhe possibilitarão organizar o seu processo educativo e, assim, superar os
desafios na construção de conhecimentos. Para finalizar essa mensagem de boas-vindas, lhe
estendo o convite para que caminhe conosco na Comunidade do Conhecimento e vivencie
a oportunidade de constituir-se sujeito do seu processo de aprendizagem e membro de uma
comunidade mais universal e igualitária.
Um grande abraço e ótimos momentos de construção de aprendizagem!
Professora Gislene Miotto Catolino Raymundo
Coordenadora Pedagógica do NEAD- CESUMAR
6
BANCO DE DADOS | Educação a Distância
APRESENTAÇÃO
Livro: BANCO DE DADOS
Professor Me. Edson Yanaga
Salve, caríssimo(a) leitor(a). Tenho um enorme prazer em apresentar-lhe o livro de Banco
de Dados, elaborado especificamente para contribuir na sua formação de futuro(a)
desenvolvedor(a) de software. Sou o Professor Edson Yanaga, autor deste livro. Espero que
você tenha um bom proveito do material.
Permita-me apresentar-me adequadamente: sou Bacharel em Ciência da Computação pela
Universidade Estadual de Maringá (UEM) e Mestre em Engenharia Elétrica e Informática
Industrial pela Universidade Tecnológica Federal do Paraná (UTFPR) na área de Telemática.
Sou empresário (consultor e desenvolvedor) na área de software e trabalho com a plataforma
Java desde 1997 – completando 15 anos de experiência neste ano de 2012. Trabalho também
como administrador de sistemas Unix (Solaris, HP-UX e Linux) desde 2000, e desde 2008
já era adepto e entusiasta da computação em nuvem (cloud computing). Participo de vários
cursos em nível de especialização em diversas instituições, como Cesumar, UEM, UNIPAR
e Faculdade Integrado; e sou coordenador do curso de Especialização em Desenvolvimento
Orientado a Objetos em Java do Cesumar desde 2004. Possuo as seguintes certificações:
Oracle Certified Professional, Java Platform, Enterprise Edition 6 Enterprise JavaBeans
Developer; Certified ScrumMaster; Sun Certified Developer for Java Web Services 5; Sun
Certified Specialist for NetBeans IDE; Sun Certified Web Component Developer for J2EE 1.4;
e Sun Certified Programmer for Java 2 Platform 1.4. Como líder do Redfoot JUG (Java Users
Group) – Grupo de Usuário Java do Norte do Paraná – atuo desde 2004. Tive o prazer de ser
membro do comitê técnico do JavaOne Latin America nas edições de 2010 e 2011. Apresento
palestras em diversos eventos em nível nacional e internacional, e ultimamente sou um grande
entusiasta do Artesanato de Software e do código bem-feito.
Confesso que foi um tremendo desafio escrever este material. Até certo ponto é uma repetição
cansativa dizer que o ritmo das mudanças e inovações cada vez mais se acelera, mas a
princípio o tema “banco de dados” aparentaria ser algo tranquilo pelo fato de ser uma área
do conhecimento bastante consolidada. Ledo engano. Nos últimos cinco anos, a disciplina
de banco de dados passou por profundas transformações que chacoalharam os alicerces
de fundamentos criados e utilizados desde a década de 1970. Os desafios dos sistemas de
BANCO DE DADOS | Educação a Distância
7
informação atuais exigem que manipulemos não gigabytes ou terabytes de informações, e sim
petabytes, exabytes e zetabytes.
Sistemas de informação das gerações anteriores tinham como objetivo gerar informações que
pudessem agregar valor aos processos de negócios. Pois bem, esse objetivo foi alcançado.
Com a tão aguardada e estimulada onipresença de software, a magnitude destas informações
geradas cresceu. Redes sociais, smartphones, tablets, sensores de automação e vários outros
dispositivos geram inúmeros bits de informação a todo momento. Conceitos antigos já não são
soberanos nesses ambientes inóspitos atuais. Diante destes cenários surgiram os conceitos
de Big Data e NoSQL.
Mas para irmos longe e chegarmos a este ponto, devemos dar o primeiro passo. Este material
aborda os conceitos que até recentemente eram considerados como as “regras sagradas” de
banco de dados: os bancos de dados relacionais. E não se engane, caro(a) leitor(a), estes
fundamentos de bancos de dados relacionais são imprescindíveis para que se possa dar o
“próximo passo” rumo ao conhecimento de Big Data e NoSQL.
Na Unidade I teremos a apresentação de tópicos conceituais e definições sobre bancos de
dados, sistemas gerenciadores de bancos de dados e os tipos de usuários que interagem com
esses sistemas. Teremos também uma breve explanação sobre o conceito de transações,
que é uma ferramenta essencial no desenvolvimento de aplicações mais tradicionais como
aquelas que envolvem dados financeiros. Como leitura complementar, temos um texto de
Cezar Taurion (Evangelista Técnico da IBM) falando sobre Big Data. Afinal, é importante
darmos um passo no presente – mas sempre com um olho no futuro. Essa será a tônica das
nossas leituras complementares e sugestões de vídeos: apresentar-lhe sempre os conceitos
de vanguarda que já são aplicados em muitos casos de uso em aplicações modernas.
A Unidade II descreverá a terminologia e outros conceitos básicos que serão utilizados no
restante deste material, tais como a diferenciação entre schemas e instâncias de dados; bem
como a arquitetura de sistemas de banco de dados. Conhecer a arquitetura permitirá que você,
como desenvolvedor(a) de software, possa explorar melhor os recursos do seu sistema de
banco de dados – além de auxiliá-lo(a) na escolha dos diferentes tipos de produtos existentes
e também dos produtos concorrentes em cada tipo ofertado.
O modelo relacional de banco de dados propriamente dito será abordado na Unidade III. A
8
BANCO DE DADOS | Educação a Distância
partir deste ponto você estará apto a identificar as características de modelos relacionais e
passar a construir seus próprios modelos de dados baseado nos fundamentos apresentados.
Na modelagem relacional, você identificará entidades do seu domínio de negócios, suas
restrições e os relacionamentos entre as diversas entidades modeladas.
Nas Unidades IV e V aprenderemos a linguagem SQL (Structured Query Language), que é uma
ferramenta dominada por 10 em cada 10 desenvolvedores de software que utilizam sistemas de
banco de dados. De conceito simples, acredito piamente que não será um problema para você,
futuro(a) desenvolvedor(a) de software bem feito. Mas convém ressaltar que SQL possui uma
natureza declarativa, que é diferente das linguagens imperativas como Java, C ou Pascal
com as quais você provavelmente está acostumado(a). Após sua criação, a SQL tornou-se um
padrão de facto para manipular informações em sistemas de banco de dados por meio de seus
comandos para inserção, atualização, remoção e consulta de instâncias de dados.
E antes que você possa apreciar o conteúdo do material, permita-me apresentar meu ponto de
vista para reflexão: em muitas empresas o sistema de banco de dados tornou-se o repositório
“sagrado” das informações, trancado a sete chaves e reservado ao guardião denominado de
DBA (DataBase Administrator). Aliás, é bastante comum que os alunos aprendam ou venham
a concluir que o banco de dados é o coração de um sistema de informação – baseados
nessas falsas impressões transmitidas até certo ponto em grande quantidade. Para mim e
também para muitos autores renomados do mundo do software, o banco de dados é apenas
uma ferramenta utilizada na construção de nossos sistemas de informação. E como toda
e qualquer ferramenta, não pode ficar acima do próprio código que atende ao processo de
negócios da empresa. Isso diminui sua importância? Certamente que não! Mas quando
modelar seu sistema de informação, pense primeiro no seu modelo de negócios e postergue
até o último momento a sua visão sobre o banco de dados. Tenho certeza de que isso tornará
a sua aplicação muito melhor projetada e permitirá que ela ofereça um retorno muito melhor
ao seu negócio.
O banco de dados é só um detalhe. Um detalhe importante, mas o considere um detalhe.
O coração da sua aplicação é o código bem feito que você elaborará para atender ao seu
negócio. Pense nisso, e a cada batida desse coração você poderá usufruir de muito retorno (e
muito dinheiro, espero).
Um bom proveito e uma ótima leitura.
Prof. Me. Edson Yanaga
BANCO DE DADOS | Educação a Distância
9
Sumário
UNIDADE I
CONCEITOS DE BANCOS DE DADOS
CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE DADOS.............................................20
TRANSAÇÕES.........................................................................................................................27
VANTAGENS DE SE UTILIZAR UM SGBD.............................................................................31
UNIDADE II
OS BANCOS DE DADOS E O SOFTWARE
SCHEMAS, INSTÂNCIAS E ABSTRAÇÕES...........................................................................42
INTERFACES DOS SGBDS.....................................................................................................43
ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS....................................................46
MODELO CENTRALIZADO.....................................................................................................47
CLASSIFICAÇÃO DOS SISTEMAS DE BANCO DE DADOS.................................................56
UNIDADE III
O MODELO RELACIONAL
CONCEITUAÇÃO.....................................................................................................................68
RESTRIÇÕES DO MODELO RELACIONAL...........................................................................71
UNIDADE IV
SQL Básico
DEFINIÇÕES DE DADOS E TIPOS EM SQL..........................................................................93
RESTRIÇÕES..........................................................................................................................97
CONSULTAS BÁSICAS EM SQL.............................................................................................99
COMANDOS DE MODIFICAÇÃO DE DADOS EM SQL........................................................104
UNIDADE V
MAIS SQL
CONSULTAS ENVOLVENDO NULL...................................................................................... 118
CONSULTAS UTILIZANDO JOINS........................................................................................124
CONSULTAS COM FUNÇÕES DE AGREGAÇÃO................................................................126
COMANDOS DE ALTERAÇÃO DE SCHEMA.......................................................................128
CONCLUSÃO......................................................................................................................... 141
REFERÊNCIAS......................................................................................................................143
UNIDADE I
CONCEITOS DE BANCOS DE DADOS
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
• Apresentar os conceitos fundamentais envolvendo dados e bancos de dados em
sistemas computacionais.
• Descrever as formas interação dos usuários com os bancos de dados.
• Comparar as vantagens desta abordagem em relação a outras similares.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Conceituar bancos de dados, sistemas gerenciadores de banco de dados e
sistemas de banco de dados
• Apresentar as principais características de sistemas de banco de dados
• Enumerar alguns papéis de usuários envolvidos na interação com sistemas
de bancos de dados
• Descrever algumas vantagens na utilização de sistemas de bancos de dados
comparados a outras abordagens
Fonte: SHUTTERSTOCK.COM
INTRODUÇÃO
“Scientia potentia est”: “Conhecimento é poder”.
Sim, caro(a) leitor(a), conhecimento é poder. Informação é poder. Na sociedade do século
XXI, chamamos estas informações armazenadas em sistemas computacionais de dados. E
temos informação em abundância. O desafio crescente dos próximos anos é encontrar formas
eficientes de processar os dados que já temos e ainda criar para gerar conhecimento e,
consequentemente, riqueza.
Nas últimas décadas, boa parte do software desenvolvido envolve além do processamento
de informações: as informações de entrada e de saída do software (além de outras
metainformações intermediárias) devem ser armazenadas em um mecanismo confiável, e que
possibilite o acesso simples e rápido à leitura e escrita destas informações.
Há alguns anos, escrever sobre o tema “banco de dados” seria uma tarefa relativamente
tranquila, pois muitos acreditavam tratar-se de um assunto absolutamente consolidado.
Mas o nosso mundo está em constante mudança e os modelos de negócios que surgiram
recentemente provocaram uma ruptura na forma de se pensar no armazenamento de
informações em bancos de dados.
BANCO DE DADOS | Educação a Distância
15
Mas de onde vem este termo que conhecemos como “banco de dados”? Pois em inglês, o
termo refere-se a databases, que numa tradução literal definiríamos como “base de dados”. Um
bom palpite remete a uma visão generalizada de que as instituições denominadas de “bancos”
guardam de modo bastante seguro o nosso dinheiro. Os “bancos de dados” seriam então
ferramentas que guardariam nossas informações (dados) de modo também supostamente
seguro e confiável.
Outra confusão bastante comum e plenamente justificada refere-se à diferença entre os termos
“banco de dados” e os sistemas que o gerenciam. Segue uma definição segundo Navathe
(2011, p.3):
Um banco de dados é uma coleção de dados relacionados. Os dados são fatos que
podem ser gravados e que possuem um significado implícito. Por exemplo, considere
nomes, números telefônicos e endereços de pessoas que você conhece. Esses dados
podem ter sido escritos em uma agenda de telefones ou armazenados em um computador,
por meio de programas como o Microsoft Access ou Excel. Essas informações são
uma coleção de dados com um significado implícito, consequentemente, um banco de
dados.
Nossos bancos de dados podem ser coleções de dados relacionados dos mais diversos
tamanhos. Desde uma pequena agenda contendo números e contatos de pessoas até um
índice gigantesco de páginas de Internet e buscas relacionadas ou todas as mensagens e
informações trocadas entre bilhões de usuários de uma rede social.
Em termos computacionais, há uma categoria de software especializado que é desenvolvido
especificamente com o propósito de se gerenciar estas coleções de dados: os sistemas
gerenciadores de banco de dados – popularmente reconhecidos pela sigla SGBD (ou DBMS
– DataBase Management Systems, na sigla original em inglês). Segue mais uma definição de
Navathe (2011, p.3), sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) é uma coleção de programas
que permite aos usuários criar e manter um banco de dados. O SGBD é, portanto,
um sistema de software de propósito geral que facilita os processos de definição,
construção, manipulação e compartilhamento de bancos de dados entre vários usuários
e aplicações. A definição de um banco de dados implica especificar os tipos de dados,
16
BANCO DE DADOS | Educação a Distância
as estruturas e as restrições para os dados a serem armazenados em um banco de
dados.
Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer sistemas de
software, tal opção não se mostra viável. Relembrando o nosso conceito de que a importância
do software consiste em sua capacidade de se gerar valor com as informações que manipula,
tem-se que implementar nosso próprio mecanismo de manipulação de dados em nossas
aplicações não gera valor: somente custo. É por este motivo que atualmente definimos os
SGBDs numa categoria de software que consideramos como commodity.
Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem Oracle, DB2, SQL
Server, Access, PostgreSQL, MySQL, Derby e H2. Já exemplos de SGBDs não relacionais
(também conhecidos como NoSQL) incluem MongoDB, Redis, Neo4j e Riak.
Para propósitos de definição, finalizaremos denominando o conjunto formado pelo banco de
dados e o sistema que o gerencia, o SGBD, de sistema de banco de dados.
Bancos de dados Open Source: presente ou futuro?
Fonte: SHUTTERSTOCK.COM
Cezar Taurion
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de dados Open
Source. Bem, tenho minha opinião pessoal e quero compartilhar com vocês. Vamos ver se vai gerar
muita discordância...
BANCO DE DADOS | Educação a Distância
17
Os softwares de banco de dados são um dos mais importantes componentes de software de uma
organização. Neste ambiente as alternativas de software livre já são bastante conhecidas e freqüentemente são mencionadas na mídia, como MySQL, PostgreSQL, Ingres e Derby.
O MySQL é um produto de uma empresa privada, a MySQL AB. Seu código é desenvolvido pelos
funcionários da empresa e com isso ela garante a propriedade intelectual sobre o produto. Existe uma
comunidade envolvida, mas submissões de código são restritas apenas à correção de bugs. Uma
pergunta: o MySQL pode ser considerado realmente Open Source, uma vez que não adota o modelo
de desenvolvimento colaborativo? O MySQL é ofertado tanto em GPL como sob licença comercial.
As duas versões são funcionalmente equivalentes, sendo diferenciadas pelo nível de suporte e certificação. Indiscutivelmente é o banco de dados Open Source mais popular, com o maior mindshare
do setor.
Outro software é o PostgreSQL, que tem suas origens no Postgres desenvolvido pela Universidade
de Berkeley. Podemos citar também o Ingres, que foi um banco de dados da Computer Associates e
agora pertence a uma organização independente, a Ingres Corporation (www.ingres.com) e o Derby,
originalmente o Cloudscape da IBM e recentemente doado para a Apache Software Foundation, onde
agora é o 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 famílias WebSphere, Tivoli e Lotus.
Nas minhas andanças pelo mercado tenho visto que na prática os bancos de dados Open Source só
aparecem como competidores dos produtos mais avançados nas aplicações pouco sofisticadas ou
bem especificas.
Por sua vez, os sistemas de banco de dados proprietários buscam competir com funcionalidades diferenciadoras, principalmente as relacionadas com administração de ambientes complexos; escalabilidade; desempenho com grande volume de transações; alta disponibilidade e capacidade de recuperação rápida; e recursos de data warehousing. Além disso, foi criado um ecossistema de negócios em
torno dos principais software de banco de dados proprietários, com diversas empresas independentes
oferecendo ferramentas de software complementares (geradores de relatórios, analisadores estatísticos e outros), serviços de suporte técnico especializado e formação de recursos humanos, e assim
por diante, o que também cria uma barreira de entrada difícil de transpor por qualquer novo entrante.
Já o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde se gera dinheiro) ainda é incipiente, sendo formado por pequenas empresas com abrangência de atuação bastante limitada. Ano passado, a MySQL gerou cerca de 50 milhões de dólares em receita (http://news.
com.com/MySQL+hits+50+million+revenue,+plans+IPO/2100-7344_3-6179290.html), mas ainda é
um traço (cerca de 0,03%) no gráfico que mostra o mercado global de bancos de dados relacionais,
estimado pelo IDC em 16 bilhões de dólares. Como comparativo, o IDC estima que neste mesmo ano,
18
BANCO DE DADOS | Educação a Distância
a receita da IBM com a família de produtos DB2 foi de aproximadamente 3,5 bilhões de dólares.
Qual o papel que os bancos de dados Open Source desempenharão? Na minha opinião estarão
atuando (pelo menos nos próximos 3 a 4 anos) na chamada faixa de produtos com funcionalidades
comoditizadas, onde as características de preço são as de maior importância. Os usuários típicos
serão organizações e aplicações que não precisam de recursos mais sofisticados.
Como avaliar a qualidade de um banco de dados Open Source? Existem diversos critérios que podem
e devem ser considerados em uma análise para seleção de um banco de dados. Os níveis de importância das variáveis da análise estão diretamente relacionadas com os objetivos do negócio e das
necessidades a serem impostas aos softwares de bancos de dados.
Alguns dos principais fatores a serem considerados são:
a) Recursos de gerenciamento e administração. São as ferramentas de apoio às tarefas do administrador do banco de dados.
b) Desempenho e escalabilidade. Os recursos que o software oferece para garantir desempenho
adequado, nos volumes de transações que serão demandados.
c) Recursos técnicos. Disponibilidade de recursos como triggers, stored procedures, cursors, subqueries, capacidade de replicação, recursos de indexação, aderência a padrões (ANSI SQL), particionamento, backup/recovery, suporte a dados não estruturados, independência de plataforma
e recursos de segurança.
d) Custos de Propriedade.
e) Suporte técnico e disponibilidade de recursos humanos. Abrangência do ecossistema em termos
de serviços de suporte e qualificação de recursos humanos.
f)
Disponibilidade de aplicativos.
g) Recursos de data warehousing e BI.
h) Recursos de desenvolvimento de aplicações.
i)
Modalidade de licenciamento.
j)
Visão, estratégia e road map do produto.
k) Tamanho e participação/envolvimento da comunidade.
l)
Modelo de governança adotado pela comunidade.
m) Base instalada e adoção pelo mercado.
Bem e quanto a uma pergunta que muitos me fazem... Minha empresa deve adotar um banco de dados Open Source? Para mim, para mudar um software de banco de dados deve haver uma estratégia
impulsionada por razões fortes e consistentes. Por exemplo, se houver desconfianças que o atual
fornecedor esteja saindo do mercado; falta de funcionalidade do software (não é mais adequado às
BANCO DE DADOS | Educação a Distância
19
necessidades das novas aplicações da empresa); falta de visão estratégica por parte do fornecedor
do software atual; custos de manutenção e operação muito elevados para o resultado obtido; falta de
pessoal gabaritado, que esteja disponível no mercado; carência de consultorias e serviços de suporte
externos; relacionamento com o fornecedor cada vez mais deteriorado... Mudar para um banco de
dados Open Source simplesmente por questões ideológicas deve estar fora de cogitação, pois banco
de dados é muito sério para ser tratado de forma simplista.
OK, e quais seriam então os custos e riscos da migração? Existem custos de migração que não podemsersubestimados.Temososcustosdaconversãodedados,custosdacodificação,testes,eo
que chamamos reconciliação entre as aplicações no novo e no antigo ambiente, sempre considerando
quedificilmenteconseguiremosfazerumamigraçãoestilobigbang,masqueestaserágradual.
Quanto mais complexas forem as aplicações a serem convertidas, mais custosa será a migração. Esta
complexidade pode ser medida pelo número de programas, número de tabelas relacionais, restrições
de integridade referencial e tamanho do banco de dados. Existem custos indiretos como a construção
de interfaces entre as aplicações já convertidas e as que ainda estão no banco de dados antigo. Também os custos de suporte técnicos aos dois ambientes implicam muitas vezes, em gastos adicionais
elevados, principalmente quando o novo banco de dados não for de completo domínio da equipe
técnica da empresa.
Em resumo, os custos da migração afetam os cálculos de custos totais de propriedade. A maioria das
empresas é extremamente cautelosa em trocar de fornecedor de softwares críticos. O perigo de uma
interrupção nos seus negócios decorrente de uma troca mal planejada ou inadequada faz com que
os custos de troca possam ser extremamente elevados e desestimuladores. Migrar de um banco de
dados para outro é sempre uma tarefa complexa e de alto risco, que só deve ser efetuada quando os
benefícios forem claramente demonstráveis.
Fonte: <https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/entry/bancos_de_dados_open_source?lang=pt_br>. Acesso em: 14 ago. 2012.
CArACtErÍStiCAS DE SiStEmAS DE BANCOS DE DADOS
Se utilizar um sistema de banco de dados parece uma solução natural, qual seria a outra
solução alternativa? Pense em algumas aplicações que você utiliza e que não fazem uso de
SGBDs. Processadores de texto, planilhas, ferramentas de desenho etc., são alguns exemplos
20
BANCO DE DADOS | Educação a Distância
dessas aplicações. O que todas têm em comum? A necessidade de se armazenar a informação
manipulada por meio de arquivos.
Em qualquer aplicação que necessite do armazenamento de dados, faz-se necessário dispor de
algum mecanismo que permita que estes sejam gravados de modo persistente. A abordagem
de arquivos tem suas vantagens, como por exemplo, a portabilidade dos dados. Você pode
carregá-los eletronicamente ou fisicamente para locais diferentes de modo bastante simples.
Mas entre as desvantagens desta abordagem há todo o trabalho necessário para se criar um
formato e processar a sua gravação e recuperação – e acredite, não é pouco trabalho!
Um SGBD, por outro lado, já dispõe de uma série de funcionalidades prontas para serem
utilizadas pelo desenvolvedor da aplicação. Deste modo, uma série de preocupações passa
a ser delegada a um software de terceiros (o SGBD). A seguir, apresentaremos uma série de
características que diferenciam a abordagem de sistemas de banco de dados da manipulação
manual das informações (como em arquivos, por exemplo).
Natureza autodescritiva
Uma característica fundamental que distingue os sistemas de bancos de dados de outras
abordagens é o fato de que nos SGBDs, o banco de dados e as metainformações sobre
o banco de dados são armazenados conjuntamente. Essas metainformações armazenadas
contêm informações como o tipo, tamanho e restrições do banco de dados. Em termos
técnicos, as metainformações são chamadas de esquema (ou schema, em seu termo original
em inglês).
Isolamento entre Programa e Dados
Numa aplicação que utilize arquivos para o armazenamento de dados, quaisquer alterações na
estrutura do arquivo também implicarão em alterações no programa. Nesse caso, dizemos que
o programa é altamente acoplado à sua estrutura de armazenamento de dados. Em contraste,
SBGDs permitem que o programa somente informe quais dados são armazenados, sem se
BANCO DE DADOS | Educação a Distância
21
importar em como esses dados serão manipulados internamente. Esta característica aumenta
bastante o nível de manutenibilidade do sistema, quando bem aplicada.
Múltiplas visões dos dados
Esta não é uma característica fundamental, mas muitos SGBDs fornecem a possibilidade de
que diferentes usuários com diferentes permissões possam acessar diferentes “visões” dos
dados. Essas visões (views) correspondem a estruturas virtuais criadas a partir dos dados
armazenados e podem conter, além dos próprios dados, também informações derivadas
(calculadas) a partir desses dados.
A criação de diferentes usuários com diferentes permissões a visões específicas é uma
abordagem muito utilizada em sistemas cliente/servidor; ou na integração de aplicações
mediante banco de dados. O auge do uso destas abordagens deu-se no final da década
de 1990, embora ainda hoje seja possível testemunhar aplicações sendo executadas sob
este modelo. Recomenda-se fortemente que no desenvolvimento de novas aplicações, a
abordagem de múltiplas visões e de integração mediante banco de dados seja substituída
por uma abordagem orientada a serviços como SOA (Service Oriented Architecture) ou como
REST (REpresentational State Transfer).
Visões não são uma má prática. São um recurso bastante útil, mas não imprescindível. Como
toda ferramenta, bem utilizada e de modo adequada, é um recurso valioso.
Acesso concorrente de múltiplos usuários
Um SGBD multiusuário, como o próprio nome já define, deve permitir o acesso de múltiplos
usuários. Além disso, o acesso deve ser concorrente, permitindo que todos os usuários
conectados executem operações “ao mesmo tempo”.
Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errônea na área
de Tecnologia da Informação: “paralelo” e “concorrente”. Paralelismo puro é algo raro em
22
BANCO DE DADOS | Educação a Distância
computação, embora seja perfeitamente possível. Ao lidarmos com sistemas de banco de
dados, utilizamos o termo “concorrente”, pois vários usuários têm a impressão de que estão
executando instruções ao mesmo tempo – quando na verdade, por se tratar de informações
acessadas em disco ou com um único barramento de acesso, torna-se necessário algum
mecanismo de contenção que serialize (coloque em fila) cada uma dessas instruções.
Como idealmente a execução dessas instruções é bastante curta, tem-se a impressão do
pseudoparalelismo.
Um conceito fundamental para que o acesso destes múltiplos usuários mantenha o banco de
dados num estado consistente é o mecanismo de transações, que será descrito na próxima
seção.
ArevoluçãodoBigDataestáprestesaacontecer
Fonte: SHUTTERSTOCK.COM
Cezar Taurion
OtermoBigDatacomeçaadespertarmuitaatenção,masaindaéumconceitomaldefinidoecompreendido.ComumarápidapesquisaaoGoogle,identifiquei,pelomenos,umadúziadedefinições.
Nesteartigo,voufalarumpoucosobreoassuntoedebateralgunsdesafiosquetemosparaconseguir
colocar projetos de Big Data em ação.
BANCO DE DADOS | Educação a Distância
23
Sem entrar em definições e nos atendo apenas a conceitos, podemos resumir com uma fórmula simples o que é Big Data: volume + variedade + velocidade de dados. Volume porque, além dos dados
gerados pelos sistemas transacionais, temos a imensidão de dados gerados pelos objetos na Internet
das Coisa, como sensores e câmeras, e os gerados nas mídias sociais, via PCs, smartphones e tablets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos não estruturados, como fotos, videos, emails e tuítes. E, por fim, velocidade porque, muitas vezes, precisamos
responder aos eventos quase que em tempo real. Ou seja, estamos falando de criação e tratamento
de dados em volumes massivos.
Outro desafio: criar e tratar apenas de dados históricos, como os veteranos Data Warehouse e as
tecnologias de BI (Business Intelligence) começam a se mostrar lentos demais para a velocidade com
que os negócios precisam tomar decisões. Aliás, o termo BI já tem mais de 50 anos. Ele foi cunhado
por Hans Peter Luhn, pesquisador da IBM em um artigo escrito nos idos de 1958.
Quando falamos em volume, os números são gigantescos. Se olharmos globalmente, estamos falando em zetabytes, ou 10²¹ bytes. Grandes corporações armazenam multiplos petabytes e mesmo
as pequenas e médias empresas trabalham com dezenas de terabytes de dados. Este volume tende
a crescer geométricamente. Em mundo cada vez mais competitivo e rápido, as empresas precisam
tomar decisões baseadas não apenas em palpites, mas em dados concretos. Assim, para um setor de
marketing faz todo sentido ter uma visão 360° de um cliente, olhando não apenas o que ele comprou
da empresa, como registrado no ERP, mas saber o que ele pensa e diz sobre a empresa e como os
faz - pelo Facebook e Twitter, por exemplo.
Hoje, já é consenso que dados são os recursos naturais da nova Revolução Industrial. Na atual sociedade industrial, ter apenas recursos naturais, como minério, e exportá-los de forma bruta - importando
em troca produtos manufaturados, não garante a competitividade de um país no longo prazo. O importante é a tecnologia e o conhecimento que cria produtos manufaturados. Afinal, um quilo de satélite
vale imensamente mais do que um quilo de minério de ferro.
Fazendo um paralelo, na sociedade da informação é crucial saber tratar os dados na velocidade
adequada. Dados não tratados e analisados em tempo hábil são dados inúteis, pois não geram informação. Dados passam a ser ativos corporativos importantes e como tal, podem - e deverão - ser
quantificados econômicamente.
Big Data representa um desafio tecnológico, pois demanda atenção à infraestrutura e tecnologias
analíticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de computação em nuvem, desde, é claro, que este imenso volume não seja transmitido repetidamente via
Internet. Só para lembrar, os modelos de cobrança pelo uso de nuvens públicas tendem a gerar processamentos muito baratos, mas tornam caro a transmissão de muitos dados.
A principal base tecnológica para Big Data Analytics é o Hadoop e os bancos de dados NoSQL, onde
24
BANCO DE DADOS | Educação a Distância
“No” significa Not Only SQL, ou seja, usa-se bases de dados SQL e não SQL. A importância do “Not
Only” SQL explica-se pelo fato do modelo relacional ser baseado na época de sua criação, no início
dos anos 70. Nessa época, acessar, categorizar e normalizar dados era bem mais fácil do que hoje.
Praticamente não existiam dados não estruturados circulando pelos computadores da época. Também não foi desenhado para escala massiva, ou para um processamento muito rápido. Seu objetivo
básico era possibilitar a criação de queries que acessacem bases de dados corporativas e, portanto,
estruturadas. Para soluções Big Data, tornam-se necessárias varias tecnologias, desde bancos de
dados SQL, a softwares que utilizem outros modelos, que lidem melhor com documentos, grafos,
processamento paralelo, etc.
A complexidade do Big Data vem à tona quando lembramos que não estamos falando apenas de
armazenamento e tratamento analítico de volumes massivos de dados, mas de revisão, ou criação,
de processos que garantam a qualidade destes dados e de processos de negócios que usufruam dos
resultados obtidos. Portanto, Big Data não é apenas um debate sobre tecnologias, mas, principalmente, sobre como os negócios poderão usufruir da montanha de dados que está agora à sua disposição.
Aí emerge a questão da integração: como integrar bases de dados estruturadas e não estruturadas
com diversos softwares envolvidos?
O Big Data abre oportunidades profissionais bem amplas. Na minha opinião, existe espaço para dois
perfis profissionais: um mais voltado para os negócios e qualificados para tratar analiticamente as
informações geradas por estas imensas bases de dados e outro com viés mais técnico, ou Data
Architect.
Pelo viés dos negócios, um artigo interessante que foi publicado há poucos meses pelo Wall Street
Journal, na edição brasileira, aponta como problema a escassez de talentos. Ele fala que muitas
empresas americanas começaram a procurar profissionais que saibam interpretar os números usando
a análise de dados, também conhecida como inteligência empresarial. Mas encontrar profissionais
qualificados tem se mostrado difícil. O resultado foi que várias faculdades americanas, como a Faculdade de Pós-Graduação em Administração da Universidade Fordham e a Faculdade de Administração
Kelley, da Universidade de Indiana, começaram a oferecer disciplinas eletivas, cursos de extensão e
mestrados em análise de dados. Já o Data Architect deve lidar com tecnologias SQL e NoSQL, conhecer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto,
ter capacidade de desenhar estratégias para manusear e analisar grandes volumes de dados de
formatos diferentes, quase que em tempo real.
A idéia de stream processing, ou stream computing, é fantástica; é um novo paradigma. No modelo
de data mining tradicional, uma empresa filtra dados dos seus vários sistemas e, após criar um data
warehouse, dispara “queries”. Na prática, faz-se uma garimpagem em cima de dados estáticos, que
não refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrás. Com o stream
computing, esta garimpagem é efetuada em tempo real. Em vez de disparar queries em cima de uma
BANCO DE DADOS | Educação a Distância
25
base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando
umconjuntodequeries.Podemospensareminúmerasaplicações,sejamestasemfinanças,saúde
e mesmo manufatura.
Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de fabricação
desemicondutoresmonitoraemtemporealoprocessodedeteçãoeclassificaçãodefalhas.Como
stream computing, as falhas nos chips que estão sendo fabricados são detetadas em minutos e não
em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda,
pode-se fazer ajustes em tempo real nos próprios processos de fabricação.
Quanto ao EDA, pode-se começar a estudar o assunto acessando seu verbete na Wikipedia.
O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Aliás, já aparece no canto da tela
de um ou outro CIO, e, provavelmente, em alguns anos já será um dos temas mais prioritários das
tradicionais listas de “tecnologias do ano”. Portanto, é bom estar atento à sua evolução e começar a
colocar em prática algumas provas de conceito.
Fonte: <http://imasters.com.br/artigo/23437/banco-de-dados/a-revolucao-do-big-data-esta-prestes-a-acontecer>. Acesso em 15 jul. 2012.
O maior evento da comunidade brasileira de NoSQL:
<http://nosqlbr.com/>.
26
BANCO DE DADOS | Educação a Distância
Fonte: SHUTTERSTOCK.COM
TRANSAÇÕES
O conceito de transação é fundamental em muitas áreas da computação, e particularmente
fundamental em sistemas de banco de dados. Consideramos como transação uma
determinada “unidade de trabalho”, que é realizada em qualquer sistema computacional de
um modo coerente e independente de outras transações. Estas transações devem permitir
que o sistema esteja num estado coerente antes e depois de sua execução, independente de
falhas ou outros problemas que possam ocorrer. Devem permitir também que vários clientes
diferentes acessem concorrentemente o sistema sem que isso possa corromper ou levar a
estados que não sejam considerados coerentes.
Uma definição clássica do conceito de transações envolve o acrônimo ACID, oriundo das
propriedades de Atomicidade, Consistência, Isolamento e Durabilidade.
Atomicidade
A propriedade atomicidade de banco de dados advém do conceito de átomo da física – o qual
até recentemente supunha-se indivisível. Essa indivisibilidade pressupõe que as operações
realizadas numa transação sejam todas realizadas por completo; ou que nenhuma seja
realizada. Popularmente seria o conceito do “tudo ou nada”. Isto permite que durante a nossa
interação com um banco de dados, possamos agrupar vários comandos relacionados com
BANCO DE DADOS | Educação a Distância
27
a garantia de que todos sejam executados – de modo que as informações armazenadas
permaneçam num estado consistente após a execução da transação.
Consistência
A propriedade de consistência assegura que a execução de qualquer transação trará o
banco de dados de um estado consistente para outro estado também consistente. No caso,
a “consistência” implica que todos os dados de um banco de dados devem ser válidos de
acordo com um conjunto de regras que podem incluir restrições de tipo, valor, referências entre
informações etc.
Isolamento
A propriedade de isolamento determina que o resultado da execução concorrente de um
conjunto de transações terá o mesmo resultado de sua execução em série (uma após a outra).
O isolamento transacional é o que garante e permite o acesso concorrente de múltiplos
usuários ao mesmo SGBD.
Durabilidade
A propriedade de durabilidade garante que uma vez que uma transação tenha sido finalizada
com sucesso, os dados terão a garantia de terem sido armazenados corretamente –
independentemente da eventualidade de falhas, falta de energia, erros de aplicação etc.
Na opinião deste autor, é justamente a propriedade de durabilidade que faz com que os
bancos de dados sejam posicionados como “ferramentas sagradas” em muitas empresas.
Novamente, não há menosprezo algum em dizer que o mais importante é o código que atende
aos processos de negócios. Durabilidade é essencial: imagine qualquer empresa perdendo
todos os seus dados. A continuidade do próprio negócio está em risco. Mas mais importante
do que os dados em si está o uso que se faz deles.
28
BANCO DE DADOS | Educação a Distância
Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas sempre tiveram como premissa em seus dados sua corretitude (grau em que o software executa suas funções de modo correto).
Isso normalmente implicou na utilização de um banco de dados que pudesse satisfazer as propriedades ACID.
Com o aumento da quantidade de informações e usuários nas aplicações, o fator disponibilidade passou em alguns casos a ser mais importante do que a própria consistência das informações.
Além do ACID, surgiu o acrônimo BASE (Basically Available, Soft state, Eventually consistent) – traduzidoliteralmentecomoBasicamenteDisponível,EstadoflexíveleEventualmenteconsistente.OBASE
tornou-se uma sigla bastante comum ao lidar com bancos de dados não relacionais.
Umareflexãoquevaleapenaserfeitaé:paraosnovosdesafioseempreitadasquevocês,futuros
profissionais,enfrentarão,emquaissituaçõesoACIDérecomendadoeemquaisoutrassituaçõeso
BASE mostra-se mais adequado?
Referência: <http://queue.acm.org/detail.cfm?id=1394128>. Acesso em 15 jul. 2012.
BANCO DE DADOS | Educação a Distância
29
Papéis assumidos pelos usuários de SGBDs
Desenvolvedores de SGBDs
São pessoas que projetam e codificam os SGBDs. Exemplos de pessoas nestes papéis incluem os funcionários de
empresas como Oracle, IBM e Microsoft que atuam diretamente na programação do software SGBD. No caso de
SBGDs livres, podem ser também voluntários ou pessoas
e empresas interessadas na evolução do software. Normalmente são programadores altamente qualificados que
trabalham no código-fonte do SBGD. Mas voluntários de
projetos de software livre também podem contribuir em outras atividades como documentação, por exemplo.
Desenvolvedores de aplicações e
Administradores de Bancos de Dados (DBAs – DataBase Administrators)
São pessoas que desenvolvem software que armazena
as informações num SGBD. Tradicionalmente, em abordagens mais tradicionais e conservadoras, as equipes de
desenvolvimento são separadas em desenvolvedores e
DBAs. Os primeiros desenvolvem o software que acessa
o SGBD. Os segundos projetam os bancos de dados e os
mantém. Em abordagens de desenvolvimento mais modernas tende-se a eliminar esta distinção entre os papéis,
pois quanto maior a distância entre os membros da equipe envolvidos no projeto de software, menor tende a ser a
qualidade do software entregue.
Usuários finais
São pessoas que não interagem diretamente com os
bancos de dados, e sim com as aplicações criadas pelos
desenvolvedores de software que armazenam suas informações em SGBDs. A maioria das pessoas enquadra-se
nesta categoria, e embora sejam os grandes beneficiados
pela tecnologia dos sistemas de bancos de dados, raramente possuem ciência do fato.
30
BANCO DE DADOS | Educação a Distância
<http://youtu.be/Car5V9l8BiQ>.
Klaus Wuestfeld – Prevayler
Neste vídeo Klaus Wuestfeld, um dos pioneiros do XP (eXtreme Programming) no Brasil e criador do
conceito de prevalência de objetos, mostra uma abordagem inovadora e de alto desempenho para
manipulação e persistência de objetos. Atualmente, alguns dos sistemas de transações mais rápidos
do mundo utilizam este conceito.
vANtAgENS DE SE utiliZAr um SgBD
Durante as seções anteriores, já citamos algumas vantagens de se utilizar um SGBD para
armazenar as informações de nossas aplicações. A seguir, as enumeraremos de um modo
mais detalhado, de forma a justificar seu uso numa diversidade de situações.
Diminuir a redundância e fornecer consistência
Imagine uma situação bastante comum: você resolve elaborar um documento e necessita da
colaboração de várias pessoas para fazê-lo. Você então cria o esboço deste documento e o
envia por e-mail a todos os interessados. Cada pessoa realiza as suas modificações em suas
próprias cópias dos documentos e depois repassa novamente por e-mail. Quem tem a última
versão do documento? Quais são os dados corretos? Estas são perguntas difíceis de serem
respondidas nesta abordagem, e provavelmente exigirá muito trabalho manual para se chegar
à versão final do documento.
Um SGBD centraliza todas estas informações, fazendo com que todos os usuários acessem
os mesmos dados. Desse modo, diminui-se a redundância: há somente uma cópia dos dados
BANCO DE DADOS | Educação a Distância
31
a serem manipulados. Isto permite também que o banco de dados sempre permaneça num
estado consistente, pois todos os usuários terão sempre a “última versão” dos dados. Não há
a possibilidade de alguém permanecer com um “pedaço” dos dados antigos e outro “pedaço”
com a informação atual.
Controle de acesso
Muitas informações armazenadas em sistemas são confidenciais. Ao mesmo tempo, é
necessário que esta informação seja compartilhada com as pessoas para que sejam
trabalhadas. Ao utilizar arquivos, é necessário que uma cópia seja enviada aos interessados.
Por múltiplos motivos, essas cópias podem acabar sendo enviadas por e-mail a pessoas
cujo acesso é indevido; ou a mesma pode ser deixada num dispositivo de armazenamento
removível esquecido em alguma mesa de reunião.
No mínimo um SGBD oferece uma combinação de login/senha para acesso a um determinado
banco de dados. Outras restrições relativas a qual usuário pode acessar quais dados também
costumam ser implementadas pela maioria dos SBGDs. Como o acesso é centralizado,
também tem-se uma única cópia para proteção.
Consultas eficientes
Como são aplicações de software de propósito específico, os SGBDs são especialmente
projetados para armazenar eficientemente os dados a eles delegados; e para permitir formas
de consulta eficientes aos mesmos dados. Cada SGBD possui sua estratégia interna para
transformar estas informações em bytes gravados no dispositivo de armazenamento, mas de
um modo geral, não há uma grande diferença de desempenho entre diferentes produtos em
uma quantidade razoável de aplicações.
Em casos de usos típicos, é muito mais importante a eficiência em consultas do que a
eficiência em armazenamento de informações. Assim, os SBGDs utilizam dispositivos como
índices (que são estruturas criadas para otimizar consultas baseadas em certos critérios) e
32
BANCO DE DADOS | Educação a Distância
cachês (caches) para armazenar em memória os dados mais frequentemente acessados.
Estes dispositivos permitem que as consultas possam ser executadas de modo mais rápido, e
em muitos SGBDs, adequar estes dispositivos de modo otimizado chega a quase ser uma arte,
tamanha a quantidade de opções disponíveis.
Backup e Restore
Para garantir a continuidade dos negócios, é essencial executar periodicamente o backup das
informações armazenadas no servidor. Ao invés de cópias físicas dos arquivos do SGBD, é
comum os próprios SGBDs fornecerem ferramentas que permitem a exportação dos dados
para um formato intermediário (texto ou binário) para backup. Estas mesmas ferramentas
suportam a restauração destes dados em caso de necessidade.
As rotinas de backup/restore também são uma ferramenta bastante útil na migração ou cópia
de servidores onde o mesmo SGBD esteja instalado. Situações de migração costumam ocorrer
em caso de falhas ou upgrade de equipamento. Cópias costumam ser utilizadas para permitir o
teste de aplicações em desenvolvimento.
CONSIDERAÇÕES FINAIS
Nesta unidade, pudemos perceber que os bancos de dados são uma coleção de dados
relacionados que representam, por meio de um nível determinado de abstração, o modelo
do mundo real de nossas aplicações de software. Boa parte das aplicações de software
desenvolvidas na atualidade envolve a manipulação, e principalmente, o armazenamento dos
dados – estes muitas vezes em enormes quantidades. Para manipular estes bancos de dados,
criou-se uma categoria de software específico denominada de sistemas gerenciadores de
bancos de dados (SGBDs). O banco de dados (os dados) e o sistema que o gerencia são
denominados conjuntamente de sistemas de bancos de dados.
Durante esta unidade também descrevemos as características que identificam as
propriedades de sistemas de bancos de dados quando comparados a abordagens tradicionais
de processamento de arquivos. Certamente que determinados casos de uso ainda exigem
a utilização de arquivos como meio de armazenamento das informações. Mas com as
informações que detalhamos como características destes sistemas de banco de dados,
esperamos que você, como desenvolvedor(a) possa ter argumentos suficientes para decidir
BANCO DE DADOS | Educação a Distância
33
adequadamente entre uma abordagem e outra.
Como existem muitos tipos de usuários diferentes que podem interagir com os sistemas de
bancos de dados, também apresentamos uma lista não exaustiva dos papéis que estes usuários
podem assumir nestas interações. Uma máxima que devemos sempre utilizar é a “técnica do
espelho”. Olhe sempre para o software que você desenvolve por meio dos olhos de quem usa.
Compreender as situações em que cada tipo de usuário interage com um sistema de banco
de dados permite que tenhamos uma consciência melhor das dificuldades e das necessidades
que os usuários possuem em cada caso de uso cotidiano da nossa vida profissional.
Por fim, tentamos discutir algumas vantagens da abordagem de sistemas de bancos de
dados em relação à implementação de aplicações sem a facilidade e funcionalidade de
um SGBD. Claro que, tendenciosamente, um estudioso de sistemas de bancos de dados
observaria argumentos bastante positivos em relação à abordagem dos SGBDs. O papel de
um desenvolvedor experiente é distanciar-se destes apegos a uma determinada tecnologia ou
outra e decidir sobriamente qual a solução mais adequada para a sua aplicação.
Uma vez entendidos estes conceitos, podemos nos dedicar a estudar melhor alguns dos
detalhes internos dos modelos utilizados pelos sistemas de bancos de dados e das arquiteturas
de software existentes que utilizam estes sistemas. Tais tópicos serão abordados em nossa
próxima unidade.
ATIVIDADE DE AUTOESTUDO
1. Transações tradicionalmente são melhor entendidas por meio do conjunto de suas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Em quais situações da vida real você consegue enxergar a necessidade de se executar operações
com estas propriedades?
2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparação com a
utilização de arquivos para armazenamento dos dados. Tendenciosamente, o SGBD
apareceu como o vencedor nas comparações. Quais seriam as situações em que os
arquivos seriam uma solução mais adequada? Você consegue exemplificar alguma
outra situação em que uma terceira alternativa seria mais viável?
3. Pense no SBGD como um módulo do sistema ou como uma outra aplicação a ser integrada (pois em muitas concepções modernas, é assim que ele deve ser tratado). Uma
das características dos SGBDs é o isolamento entre o programa e os dados. Quais
os benefícios deste isolamento? Em que outras partes do sistema esta característica
também pode trazer benefícios?
34
BANCO DE DADOS | Educação a Distância
Banco de Dados na Nuvem
Fonte: SHUTTERSTOCK.COM
Jin Zhang, Diretor de Programas da IBM
Profissionaisdedadosestãoadotandoconceitosdecomputaçãoemnuvemparaoferecerbancosde
dadoscomoumserviço–facilitandoasdificuldadesdegerenciamentoeenviandousuáriosparaa
nuvem nove.
“Levasemanasparaconfigurarumnovobancodedados.Precisodeleagora!”
“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”
Qualquerumadessasreclamaçõessoafamiliar?Provavelmentesim,sevocêforumprofissionalde
dados em uma grande empresa. Os departamentos de TI dos dias de hoje são afetados por uma lista
não processada de demandas de administração de dados. De solicitações por novos bancos de dados
de desenvolvimento e teste de aplicativos até o backup e a restauração de volumes de dados cada vez
mais crescentes, nunca há uma falta de muito trabalho para manter DBAs na correria.
Emumatentativademinimizarotempoqueosprofissionaisdedadosgastamnomodoreativo-respondendo a solicitações de usuários com tarefas sem parada de “banco de dados, clone, banco de
dados, clone” - algumas organizações estão tomando emprestado conceitos de autoatendimento do
domínio de computação em nuvem e indo em direção a um modelo de banco de dados como serviço
ou DBaaS, em que usuários podem simplesmente “acessar uma nuvem” e capturar um banco de
dados conforme necessário.
Éumaideiaprovocante—principalmenteparausuáriosfinais.Desenvolvedoresdesistemasede
software adoram o controle que eles obtêm com recursos de autoatendimento de DBaaS. Quando eles
estão na toada, em vez de esperando que o departamento de TI volte uma semana mais tarde com um
banco de dados de desenvolvimento/teste, eles podem solicitar e provisionar recursos imediatamente
— mantendo seu ímpeto ativo e suas ideias frescas.
Paratornaressavisãoumarealidade,noentanto,osprofissionaisdedadosnosbastidoresdevem
realizar uma quantia considerável de trabalho no backend. Desenvolver uma nuvem de dados privada
BANCO DE DADOS | Educação a Distância
35
e lançar com sucesso DBaaS para usuários finais requer que DBAs considerem diversos fatores, entre eles a infraestrutura de hardware subjacente da nuvem, as “boas práticas” de dados abrangentes
a serem implementadas e replicadas pela nuvem e, por fim, a interface de serviços que trará todos
esses itens de forma transparente aos usuários finais para concluir a imagem.
“Nossos dados de desenvolvimento/teste estão uma bagunça. Por que eles nunca são limpos?”
Penetrando as nuvens
Computação em nuvem refere-se a uma categoria de soluções de tecnologia que permite que usuários acessem recursos de computação (neste caso, recursos de dados) on demand, conforme necessário, sejam os recursos físicos ou virtuais, dedicados ou compartilhados e independentemente
de como são acessados (por meio de uma conexão direta, rede local [LAN], rede de longa distância
[WAN] ou a Internet).
Para oferecer DBaaS na nuvem, os departamentos de TI corporativos devem construir e gerenciar
uma nuvem de dados corporativa privada — uma plataforma que consiste em hardware de armazenamento, imagens virtuais, esquemas de banco de dados e mais — e disponibilizar essa nuvem a
usuários por meio de uma interface de serviços.
Quando esta infraestrutura estiver instaurada, à medida que necessidades de banco de dados surgem, os usuários podem simplesmente ir para a nuvem, solicitar os recursos que requerem e obter
acesso instantâneo a seu próprio banco de dados pessoal on demand. Quando eles não precisarem
mais dos ativos de dados, os ativos são reciclados de volta na nuvem para redesignação, em vez de
serem deixados desperdiçados e inativos.
Figura 1. Uma infraestrutura otimizada para entrega em nuvem do banco de dados enfatiza
simplicidade e eficiência por meio de automação e normatização de hardware.
36
BANCO DE DADOS | Educação a Distância
Etapa um: Desenvolver a base da nuvem
Sua primeira parada no caminho para construir um ambiente de computação em nuvem e entregar
DBaaS será considerar sua infraestrutura de hardware subjacente e assegurar que seja alinhada
aos objetivos de DBaaS (consulte a Figura 1). Devido à maneira como a maioria dos departamentos
de TI está estruturada, essas decisões de hardware provavelmente não ocorrerão em um vácuo. Na
verdade, a maioria do DBAs precisará colaborar com administradores de sistemas e contrapartes da
arquitetura corporativa para chegarem a um consenso sobre qual deve ser a infraestrutura de hardware. Esse processo pode requerer concessões de todos os lados, portanto, tente entrar na conversa
com um entendimento claro de suas principais prioridades de hardware e as “boas de ter”. Não tem
certeza de quais devem ser essas prioridades? Leia adiante.
Como em qualquer decisão de compra de hardware, muitos atributos afetarão a discussão — 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 possível. Como é muito
mais fácil automatizar um script em execução em um sistema aberto homogêneo do que muitos scripts
diferentes em um heterogêneo, a normatização é a chave para automação. DBaaS em seu âmago é
nada mais que automação — a automação do processo de configuração e fornecimento de um banco
de dados — de forma que quanto mais uniforme for sua plataforma de hardware, mais simples será
configurar DbaaS.
Em seguida, dê uma olhada nas opções de armazenamento disponíveis para suportar seu banco de
dados. Certifique-se de que você tenha um entendimento claro dos tipos de recursos que receberá
prontos para uso - inclusive atributos como alta disponibilidade, recuperação de desastre e autonomia
- assim como a capacidade geral de armazenamento e recursos de sua infraestrutura de hardware.
Como essa plataforma formará por fim a base de sua oferta DBaaS, é crítico entender exatamente do
que é capaz - e o que é possível passar a seus usuários finais. Se você usar uma base de armazenamento que tenha recursos excepcionais de confiabilidade, disponibilidade e capacidade de manutenção (RAS), por exemplo, estará mais bem equipado a fornecer bancos de dados na nuvem que são
resilientes e altamente disponíveis também.
Etapa dois: Identificar cargas de trabalho comuns e melhores práticas
O próximo estágio de planejamento de DBaaS fornece a você, como um profissional de dados experiente com conhecimento íntimo dos funcionamentos internos de sua organização e suas estruturas
de dados, a chance de brilhar. A etapa mais crítica para a entrega de DBaaS que realmente traz valor
a seus usuários finais é decidir antecipadamente o tipo de modelos e imagens de banco de dados que
devem ser disponibilizados na nuvem. Para tomar tais decisões, você deve identificar as cargas de trabalho comuns e os processos chaves que ocorrem em seu ambiente de negócios e coletar melhores
práticas. Esses são os principais candidatos para automação e entrega por meio de DBaaS e a chave
para seu lançamento bem-sucedido.
Por exemplo, os DBAs podem trabalhar juntamente com os gerentes de linha de negócios para identificarem os conjuntos de dados que “precisam ter” e usarem essas informações para criarem modelos
de bancos de dados que conectem de forma eficiente a sistemas front-end, funcionem bem com 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
contêm os dados mais recentes, informações atualizadas no minuto e estruturas de dados - sem criaBANCO DE DADOS | Educação a Distância
37
remasdificuldadesdeadministraçãodedadosdemudançasdeesquema,mapeamento,migração
de dados e mais.
Em outros ambientes corporativos, DBAs podem escolher imagens de bancos de dados - frequentementeincorporandometadadosespecíficosdosegmentodemercadoedadosdereferência-como
candidatos para automação. Um DBA familiarizado com os requisitos de negócios pode isolar uma instância de um banco de dados de produção que contenha um conjunto crítico de tabelas, visualizações,
acionadores e procedimentos armazenados - assim como dados de referência chave - para criar uma
imagem de banco de dados para ser automatizada por meio de DBaaS. Quando os negócios solicitam
umbancodedadosparasuportarumanovafilialouparatestarumaplicativo,nãohaveránenhuma
necessidade de esperar semanas enquanto DBAs o constroem. Em vez disso, ele estará disponível
instantaneamente por meio de DBaaS na nuvem.
Etapa três: Estabelecer um modelo de entrega
AgoraquevocêdecidiusobreasuainfraestruturadehardwareeidentificouosprocessoseprocedimentosaseremautomatizadospormeiodeDBaaS,suaetapafinalserátrabalharcomusuáriosfinais
para educar e ajudar os mesmos a selecionarem a interface por meio da qual esses serviços de dados
serão disponibilizados.
Hátrêsmétodos principais deacesso aDBaaS:pormeio deumainterface gráfica com ousuário
(GUI), uma interface da linha de comandos (CLI) ou diretamente por meio de uma interface representational state transfer (REST) padrão. Qual interface será empregada por fim dependerá muito
dapreferênciadousuáriofinal.Porexemplo,enquantoaGUIéaabordagemmaisfácilesimples
dastrês,seosusuáriosfinaisjáutilizaremaplicativosqueempregamCLI,podeserquenãoqueiram
alternar. Como alternativa, os usuários podem querer eliminar a necessidade de intervenção humana
inteiramente e promover uma integração mais forte com seu ambiente, programando aplicativos para
se comunicarem diretamente com DBaaS por meio de REST. Quando se sabe as opções, é possível
trabalhar com seus usuários e ajudar a guiá-los para a interface de DBaaS mais adequada para seus
desejosenecessidadesespecíficosejuntosselecionarowrapperqueunirátodoopacoteDBaaS.
uma nuvem com um raio de esperança
Não é nenhum segredo que gerenciar os valores de dados em rápida expansão e as necessidades
de administração de banco de dados das grandes empresas dos dias de hoje é uma grande proeza.
DBAs têm uma tarefa dura e não há outra maneira de descrever isso. A boa notícia é que com DBaaS,
osprofissionaisdedadosestãoemumaposiçãoexclusivanãosomentededaremaosusuáriosfinais
novos níveis de liberdade e serviço, mas também para saírem do ciclo vicioso de tarefas de dados
rotineiras e irem para as coisas boas. E apesar de isso poder exigir algum fundamento para chegar
lá, no que se refere a uma nuvem com um raio de esperança, isso é praticamente o melhor que se
pode obter.
Fonte: <http://www.ibm.com/developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBaaS/>. Acesso em: 14 ago. 2012.
38
BANCO DE DADOS | Educação a Distância
UNIDADE II
OS BANCOS DE DADOS E O SOFTWARE
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
• Apresentar as definições fundamentais de sistemas de bancos de dados.
• Descrever as arquiteturas de bancos de dados e suas características.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Conceituar schemas, instâncias, abstrações e as interfaces de interação com
o SGBD
• Estudo do histórico das arquiteturas de computação em geral e de sistemas
de banco de dados
• Classificação dos diferentes tipos de banco de dados de acordo com suas
características
Fonte: SHUTTERSTOCK.COM
INTRODUÇÃO
Nesta unidade, apresentaremos alguns conceitos fundamentais que serão utilizados nas demais
unidades. Para compreender adequadamente os sistemas de banco de dados, é necessário
diferenciar adequadamente os modelos das instâncias dos modelos – pois possuem ciclos de
vida e finalidades bastante distintas.
Diferentes tipos de interface de usuário são disponibilizadas para diferentes tipos de usuários
em vários produtos diferentes comercializados no mercado. Apresentaremos algumas delas
para que você, desenvolvedor(a), possa explorá-las posteriormente.
Entender como podem ser construídos sistemas com SGBDs implica em conhecer também a
história da arquitetura de sistemas de computação, que evoluíram do monolítico até o distribuído
em camadas. Cada geração possui suas particularidades, que também são refletidas na
construção dos diferentes SGBDs.
Apresentaremos também alguns critérios de classificação de SGBDs para que você, como
desenvolvedor(a) de software incumbido(a) da árdua tarefa de escolher um produto, possa
avaliar subjetivamente e objetivamente diferentes alternativas do mercado.
BANCO DE DADOS | Educação a Distância
41
SCHEMAS, INSTÂNCIAS E ABSTRAÇÕES
Uma característica fundamental de qualquer modelo de software (o que inclui o banco de
dados) é o seu nível de abstração. É impossível conseguir modelar todos os aspectos do
mundo real numa aplicação. Assim, decidimos adequadamente escolher somente os aspectos
mais relevantes para resolver um determinado problema, e representamos estes aspectos por
meio de um modelo – que é uma abstração dos dados do mundo real. Um modelo de dados
é uma coleção de conceitos que pode ser utilizada para descrever a estrutura de um banco
de dados. Por meio desses conceitos, conseguimos alcançar a abstração necessária para
construir o nosso modelo de software.
Em qualquer modelo de dados, é importante distinguir aquilo que representa a descrição do
banco de dados com o banco de dados em si. A descrição do banco de dados é denominada
de schema1, que é especificado durante o projeto do sistema de software.
Os dados realmente armazenados num banco de dados podem mudar com uma alta
frequência. No conjunto de contatos da minha agenda pessoal, esse banco de dados muda
toda vez que eu adiciono um novo contato ou altero um telefone ou e-mail deste contato. O
conjunto de dados de um banco de dados num determinado instante do tempo é denominado
de snapshot. Também é definido como o estado atual de todas as instâncias no banco de
dados. Uma instância é um item dentro do banco de dados que segue as definições de seu
schema correspondente.
A distinção entre o schema do banco de dados e o estado do banco de dados é muito importante.
No processo de desenvolvimento de software, quando definimos um novo banco de dados,
primeiro definimos o seu schema – que após criado representa um snapshot inicial vazio. Ao
manipularmos este banco de dados com operações de inserção, alteração e remoção, nós
modificamos o snapshot. O SGBD é responsável por garantir a consistência do snapshot em
O plural correto de schema é schemata, mas praticamente não é utilizado. Na área de tecnologia da informação,
costuma-se utilizar o plural schemas, mesmo sendo errado.
1
42
BANCO DE DADOS | Educação a Distância
qualquer momento do tempo.
Não é uma operação usual ter que realizar modificações no schema, mas elas são realizadas
toda vez que uma mudança nos requisitos do negócio demanda uma alteração no modelo de
dados. Este conjunto de alterações para acomodar mudanças no software é denominado de
schema evolution.
INTERFACES DOS SGBDS
Algumas das interfaces do SGBD com o usuário são:
Linha de Comando
Sem dúvida nenhuma a linha de comando é a interface mais poderosa e
flexível para a interação do usuário com o SGBD. Por este mesmo motivo,
normalmente não é uma opção que a maioria considere como amigável.
Mas desenvolvedores devem sem dúvida nenhuma dominá-la para poder
explorar os recursos do mesmo.
BANCO DE DADOS | Educação a Distância
43
Interfaces Web
44
Muitos SGBDs fornecem interfaces Web que podem ser acessadas por
meio de qualquer navegador para a administração e manipulação dos bancos de dados. Embora não sejam tão poderosas ou produtivas, são bastante amigáveis e possuem ainda a vantagem da disponibilização do acesso.
Muitos administradores de rede não se sentem confortáveis em permitir o
acesso direto ao banco de dados, mas não se importam em liberar o acesso por meio de HTTP (Web).
BANCO DE DADOS | Educação a Distância
Interfaces Desktop
São tão amigáveis quanto as Interfaces Web, mas costumam fornecer capacidades de manipulação gráfica de diagramas. Isso auxilia os desenvolvedores a “enxergar” os relacionamentos entre as entidades do banco de
dados.
BANCO DE DADOS | Educação a Distância
45
Interfaces baseadas
em formulários
O Oracle Forms é um exemplo clássico desta interface, típica de sistemas
implementados utilizando-se triggers e stored procedures. Os usuários finais conseguem executar seus processos de negócios por meio da própria
interface do SGBD, preenchendo formulários e interagindo com a interface
de controle.
ARQUITETURAS DE SISTEMAS DE BANCO DE DADOS
A arquitetura de sistemas de banco de dados confunde-se com a própria história da arquitetura
de sistemas de computação em geral. De fato, ao mesmo tempo em que as aplicações e os
modelos de arquitetura de aplicações evoluíram, também evoluíram os sistemas de banco de
dados. Dentre os fatores que influenciaram estas evoluções estão o aumento da capacidade
de processamento, o aumento da capacidade de armazenamento, o aumento da quantidade e
capacidade das redes de comunicação, a redução de custo dos equipamentos, o aumento do
número de usuários, o aumento da quantidade de informações e a universalização do acesso.
Não há como explicar adequadamente as arquiteturas de sistemas de banco de dados sem
descrever conjuntamente as arquiteturas de sistemas de computação em geral. Nas próximas
seções, apresentaremos e descreveremos concomitantemente estas diferentes arquiteturas,
da centralizada até o modelo em camadas.
46
BANCO DE DADOS | Educação a Distância
MODELO CENTRALIZADO
Os primeiros modelos computacionais eram centralizados, baseados num único mainframe
fornecendo processamento, armazenamento e interface de interação com o usuário no
mesmo equipamento/aplicação. Raros eram os mainframes (devido ao seu alto custo) e por
consequência também poucos eram os usuários que tinham acesso a aplicações baseadas
em mainframe. A interação dos usuários com as aplicações era realizada por meio de terminais
burros, que não possuíam poder de processamento: somente teclado; e exibiam telas geradas
no próprio mainframe e transmitidas até o monitor (usualmente de fósforo verde ou amarelo)
por meio de um cabo de comunicação. A Figura 1 retrata um típico sistema centralizado
baseado em mainframe.
Mainframe
Terminal
Burro
Terminal
Burro
Terminal
Burro
Figura 1
Fonte: o autor
BANCO DE DADOS | Educação a Distância
47
Costumamos retratar este modelo de computação como monolítico, pois todas as atividades
eram baseadas no mainframe. Naturalmente, as aplicações desenvolvidas para este tipo de
equipamento também foram concebidas e implementadas de modo monolítico. Isso significa
que não havia uma distinção clara entre o que era interface com o usuário ou o que era
código de negócios ou código responsável pelo armazenamento de dados. Esta situação é
denominada de sistema altamente acoplado, pois qualquer alteração numa pequena parte
do sistema costuma levar a várias outras alterações em cascata para diversas outras partes
do sistema.
Os bancos de dados eram então extensões da própria aplicação e eram baseados nos modelos
hierárquicos e em rede, que serão apresentados adiante.
Modelo cliente/servidor
Com a popularização dos PCs e o declínio de seus preços, iniciaram-se as primeiras
implantações da arquitetura cliente/servidor. A ideia é que ao invés de termos um grande
equipamento monolítico (mainframe), passamos a ter vários equipamentos menores (e de custo
e capacidade inferior) com propósito específico (banco de dados, arquivos, e-mail, impressão
etc.) interligados por meio de uma rede de comunicação. Cada servidor tornou-se um serviço
especializado (embora não seja incomum agrupar vários serviços num único equipamento,
dependendo da conveniência).
Os clientes, que também são PCs, podem acessar os recursos disponibilizados por estes
servidores por meio de rede. A Figura 2 mostra um esquema simplificado da arquitetura
cliente/servidor.
48
BANCO DE DADOS | Educação a Distância
Servidor
PC
Servidor
PC
PC
Servidor
PC
Figura 2
Fonte: o autor
Em termos de arquitetura das aplicações, denominamos o modelo cliente/servidor como modelo
de 2 camadas, respectivamente camada cliente e camada servidor. No lado cliente costumase implantar os recursos da aplicação relacionados à interface com o usuário, enquanto no
lado servidor implanta-se a lógica de negócios, armazenamento e controle transacional. Este
modelo tornou-se extremamente popular no final da década de 1980 e início da década de 1990,
e com ele também popularizou-se a prática do desenvolvimento de aplicações utilizando-se
triggers e stored procedures dentro do próprio SGBD. Cada cliente estabelece uma conexão
remota ao SGBD, que passa a executar a lógica de negócios, armazenar os dados e controlar
as transações.
O modelo cliente/servidor é bastante adequado quanto às aplicações que possuem um número
limitado de usuários concorrentes (de 100 a até 300 ou 400 usuários). A partir deste número,
BANCO DE DADOS | Educação a Distância
49
o desempenho desta arquitetura degrada-se consideravelmente, e o particionamento e
distribuição dos sistemas de banco de dados (escalabilidade horizontal) costuma ser bastante
dispendioso. Naturalmente, há um limite também para a troca do equipamento por um maior
(escalabilidade vertical). Surgiram então os modelos de 3 camadas para tentar resolver este
problema.
Modelo de 3 Camadas ou N-Camadas
Aplicações 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
aplicação
PC
Servidor de
aplicação
Servidor de Banco
de Dados
Figura 3
Fonte: o autor
50
BANCO DE DADOS | Educação a Distância
PC
Esta camada intermediária é denominada de camada de aplicação, e é responsável pela
execução da lógica de negócios. Separa-se então em 3 papéis distintos cada camada: a
camada mais próxima do usuário é responsável pela interface e interação com o usuário;
a camada intermediária é responsável pela lógica de negócios; e a camada do SGBD é
responsável pelo armazenamento dos dados. Como idealmente a camada de aplicações é
projetada de modo stateless (sem estado), a replicação horizontal torna-se bem mais simples
do que no modelo cliente/servidor. Toda a lógica de negócios que anteriormente era codificada
utilizando-se triggers e stored procedures passa a ser executada na camada intermediária
utilizando-se uma linguagem de propósito geral. A quantidade de conexões de rede com o
SGBD também diminui, pois agora os usuários não o acessam diretamente – esta tarefa passa
a ser responsabilidade da camada de aplicação.
Outras arquiteturas costumam subdividir a camada intermediária em outras 2 ou 3, criando
aplicações de 4, 5 ou N camadas. Podemos adicionar camadas de validação, auditoria,
comunicação distribuída etc. A quantidade de camadas fica a gosto do arquiteto que projeta a
arquitetura, mas a filosofia de todo este processo de divisão de camadas segue os princípios
já apresentados.
Este modelo de camadas é o modelo utilizado atualmente para suportar a imensidão de dados
e usuários das aplicações de Internet contemporâneas.
OmaioreventodacomunidadededesenvolvedoresdoBrasilereferênciaparaprofissionaisiniciantes
ou experientes nos mais variados assuntos, incluindo Arquitetura de Software, Banco de Dados, NoSQL e Cloud Computing:
<http://www.thedevelopersconference.com.br/>.
BANCO DE DADOS | Educação a Distância
51
Foto: SHUTTERSTOCK.COM
Sem Banco de Dados
Nos Estados Unidos, em 1920, a manufatura, venda e importação de bebidas alcoólicas foram proibidas por emenda constitucional. Esta emenda foi revogada treze anos depois. Durante aquele período
de proibição, a indústria de cerveja morreu.
Em 1933, quando a proibição foi encerrada, algumas gigantes empresas de grãos começaram a produzir cerveja. Eles monopolizaram completamente o mercado. E por quase 50 anos, nós nos Estados
Unidos bebemos este líquido encorpado efervescente e o chamado de “cerveja”. O único modo de
tolerar o sabor era bebê-lo bem gelado.
Comoumadolescentenosanos60,eununcaentendiaatração.Porquecerveja?Eraumfluidopálido, amarelo e desagradável derivado da urina de javalis doentes, e não possuía nenhuma qualidade
que eu pudesse observar.
Em 1984, eu fui à Inglaterra; e as escamas caíram dos meus olhos. Finalmente pude entender. Pela
primeira vez eu pude provar cerveja; e eu gostei.
Desde aqueles dias a situação da cerveja nos Estados Unidos melhorou dramaticamente. Novas
52
BANCO DE DADOS | Educação a Distância
cervejarias estão sendo criadas por todo o país; e em muitos casos a cerveja é realmente boa. Ainda
não temos nada tão 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 dúvida entre gerentes e profissionais de marketing. A
palavra “relacional” tornou-se sinônimo de “bom”; e quaisquer outros mecanismos de armazenamento
de dados foram proibidos.
Eu era o líder de equipe de uma startup naquele tempo. Nosso produto media a qualidade de linhas
de comunicação T1. Nosso modelo de dados era relativamente simples, e nós mantínhamos os dados
em arquivos texto. E funcionava bem.
Mas nosso responsável pelo marketing continuou insistindo que precisávamos 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 nós não tínhamos 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. Nós teríamos que utilizar um banco de dados relacional. Arquivos texto
estavam proibidos.
Como líder de equipe, e responsável pela qualidade do software, minha visão de um banco de dados
relacional era que ele seria um trambolho grande, indigesto, lento e caro. Nós não tínhamos consultas
complexas. Nós não precisávamos de relatórios com análises massivas. Certamente não precisávamos de um processo com múltiplos megabytes consumindo memória e desperdiçando ciclos de
processamento (lembrem-se, estávamos na década de 80). Portanto eu lutei contra esta idéia com
todos os recursos que eu tinha; porque era a solução técnica errada.
Esta não foi uma jogada politicamente acertada para mim. Durante um período de vários meses, um
engenheiro de hardware que tinha a capacidade de escrever algumas linhas de código foi alocado na
equipe de software. Gradualmente ele foi recebendo mais e mais responsabilidade, e eventualmente
foi nomeado meu cogerente. Ele e eu iríamos “dividir” a responsabilidade de liderar a equipe de
software.
Uh huh. Claro. Com certeza. Um cara de hardware com nenhuma experiência 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 mês depois e iniciei minha carreira de consultor. Foi a melhor mudança que fiz na minha
carreira profissional. A empresa que eu deixei não existe mais. E eu também 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
BANCO DE DADOS | Educação a Distância
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 audácia de comprar anúncios de televisão 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 período eu assisti com horror a como uma equipe após 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 coração
do seu projeto.
Eu testemunhei a criação de um novo tipo de emprego. O DBA! Meros programadores não eram confiáveis o suficiente para guardar os dados – assim diziam as propagandas. Os dados são tão preciosos,
tão frágeis, tão facilmente corrompíveis por estes palhaços indisciplinados. Nós 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 Usuário. Eu blasfemei incansavelmente contra a prática
de se mover toda a lógica de negócios 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 código-fonte sistema após 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 então, na primeira década no século 21, uma proibição foi revogada, e o movimento NoSQL nasceu.
Eu o considerei um milagre, uma luz brilhando no deserto. Finalmente, alguém percebeu que pode
haver alguns sistemas no mundo que não necessitam de um grande, gordo, lento e caro porco devorador de memória 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 começando a ter um gosto bom.
Mas então eu percebi algo. Alguns dos sistemas utilizando estes bons, simples e saborosos banco de
dados não relacionais estavam sendo projetados ao redor dos bancos de dados. Os bancos de dados,
encapsulados em reluzentes novos frameworks, ainda estavam no centro da concepção do projeto!
O veneno das campanhas publicitárias das empresas de banco de dados relacionais ainda estava
ecoando na mente dos arquitetos. Eles ainda estavam cometendo o erro fatal.
54
BANCO DE DADOS | Educação a Distância
“Pare!”, eu gritei. “Pare! Vocês não entendem. Vocês não entendem.” Mas a inércia era muito grande.
Uma enorme onda de frameworks cresceu e esmagou a nossa própria indústria, levando tudo pelo
caminho. Estes frameworks encapsularam os bancos de dados e brigaram com unhas e dentes para
manter o centro de nossas aplicações. 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 após ler todas estas lamentações você possa
entender o porquê do título.
O centro da sua aplicação não é o banco de dados. Nem é um ou outro framework que você possa
estar utilizando. O centro da sua aplicação são os casos de uso da sua aplicação.
Eu enlouqueço quando ouço um desenvolvedor de software descrever o seu sistema como “Um sistema no Tomcat utilizando Spring e Hibernate com Oracle.” As próprias 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
são o centro do projeto? Ou você acha que encontrará o código-fonte adaptado para encaixar nos
padrões dos frameworks? Você suspeitaria de objetos de negócios que parecem linhas de banco de
dados? Será que o schema e os frameworks poluiriam tudo?
Isso é como uma aplicação deve parecer. Os casos de uso devem estar no nível mais alto e mais
visível das entidades arquiteturais. Os casos de uso estão no centro. Sempre! Banco de dados e
frameworks são detalhes! Você não tem que decidir utilizá-los prematuramente. Você pode postergar
esta decisão, até que todos seus casos de uso e regras de negócios tenham sido elaborados, codificados e testados.
Quando é a melhor hora de se determinar o seu modelo de dados? Quando você já conhece quais
são as entidades de dados, como elas se relacionam, e como são utilizadas. Quando você sabe isso?
Quando você já tem todos os casos de uso e regras de negócios 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 não! Você
ainda focará em conseguir os casos de uso funcionando e testados antes de pensar no banco de
dados; não 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 aplicação, 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
BANCO DE DADOS | Educação a Distância
55
continuamente dizer “Não” à tentação de envolver o banco de dados logo no início.
Estamos nos aproximando de uma época interessante. Uma época em que a proibição 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ê não deve envolvê-lo logo no início.
Uncle Bob Martin é o Mestre Artesão 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
ClASSiFiCAçãO DOS SiStEmAS DE BANCO DE DADOS
Assim como na natureza, podemos utilizar vários critérios diferentes para classificar os
sistemas de banco de dados. Alguns desses critérios bastante comuns são modelos de dados,
número de usuários, número de instalações e custo. Nas próximas seções exploraremos como
utilizar esses critérios para classificação.
modelo de dados
Não tenha dúvidas: muitas pessoas relacionam o modelo relacional a banco de dados devido
à sua absoluta onipresença. Um argumento costumeiro na escolha do modelo relacional é
56
BANCO DE DADOS | Educação a Distância
que “ninguém será demitido por tê-lo escolhido”. De fato, antes do advento do termo NoSQL,
praticamente não havia outras opções a considerar.
Durante anos houve muita pesquisa e discussão sobre banco de dados orientado a objetos,
graças à grande popularização das linguagens orientadas a objetos. O pensamento da época
era que o desenvolvimento de aplicações seria muito mais simples se pudéssemos utilizar
linguagens e banco de dados orientados a objetos juntos. Mas dois fatores foram decisivos
para que isso não acontecesse. Primeiramente, o modelo relacional já era algo absolutamente
consolidado e otimizado. Baseado em fundamentos matemáticos extremamente simples, há
anos já havia obtido sua maturidade. Robustos e confiáveis, já eram utilizados em grandes
aplicações 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 rentável ao redor de si. Atualmente, são raros os exemplos de
sistemas de banco de dados deste tipo e não 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 hierárquico ou o modelo em rede. Mas não se engane ao considerar
que aplicações baseadas nestes modelos desapareceram. Grandes bancos são um segmento
tradicionalmente conservador em relação a tecnologias adotadas. É fato que boa parte deles
ainda roda seus mais importantes sistemas em mainframes com sistemas de banco de dados
hierárquicos ou em rede. É o caso, por exemplo, do Banco do Brasil. Há uma cumplicidade:
mainframes garantem a sobrevida do modelo hierárquico e em rede, e as aplicações 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 não serão abordados neste material.
BANCO DE DADOS | Educação a Distância
57
Número de usuários
Em relação ao número de usuários, sistemas de banco de dados podem ser monousuários ou
multiusuários. Alguns raros exemplos atuais de banco de dados monousuários são os banco
de dados embarcados, que são projetados para serem pequenos e rápidos o suficiente para
serem embarcados dentro de uma aplicação. Alguns exemplos que poderíamos considerar
são o Apache Derby e o H2. Mas mesmo estes dois SBGDs podem se comportar como
monousuário ou multiusuário, dependendo do seu tipo de instalação.
Naturalmente, a grande maioria dos sistemas de banco de dados modernos suporta múltiplos
usuários concorrentes com acesso mediante algum protocolo de rede.
Número de instalações
Quanto à quantidade de instalações, podemos classificar os sistemas de banco de dados em
centralizados ou distribuídos. Sistemas centralizados são aqueles em que há uma única
instância do sistema de banco de dados sendo executada. São apropriados para quantidades
pequenas de dados ou em situações em que a disponibilidade do sistema não é crucial ao
negócio.
Sistemas distribuídos são aqueles em que há mais de uma instância (com a possibilidade de
várias) sendo executada. Em sistemas de banco de dados mais tradicionais, costuma-se utilizar
uma distribuição master-slave, em que as atualizações de dados são efetuadas no master e
as leituras são efetuadas em um ou mais slaves. Como a maioria das aplicações executa mais
leituras do que atualizações, o desempenho pode aumentar de modo significativo. Outros
tipos de distribuições de banco de dados podem envolver particionamento (dividir os dados
em instalações diferentes) e/ou replicação (duplicar os dados) para aumentar o desempenho
e/ou disponibilidade.
58
BANCO DE DADOS | Educação a Distância
Custo
É no critério custo em que amplitude de diferença entre os sistemas de banco de dados é
maior. Temos desde o gratuito até exemplares que podem custar alguns milhões de dólares.
No caso dos gratuitos, vale a pena distinguir entre os sistemas livres (software livre) e os
que representam versões reduzidas de produtos mais caros. Dois produtos livres bastante
populares são o MySQL (bem mais popular) e o PostgreSQL. O modelo de negócios de ambos
permite o livre uso e redistribuição; mas quando for necessário o suporte, pode-se optar por
contratá-lo de uma empresa terceirizada ou do próprio fornecedor (Oracle), no caso do MySQL.
Ambos possuem graus de maturidade, estabilidade e funcionalidade bastante elevados e não
devem nada a desejar em relação aos produtos pagos. Provavelmente em mais de 90% dos
casos de uso de aplicações tradicionais, não haveria diferença 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 solução e outra passou a ser uma questão de gosto ao invés de uma questão
puramente técnica.
Devido ao sucesso dos sistemas de banco de dados livres, produtos comerciais que
tradicionalmente eram bastante custosos passaram a oferecer versões gratuitas (limitadas
em número de processadores, quantidade de dados, instâncias etc.). É o caso de Oracle,
DB2 e SQL Server. Trata-se de uma estratégia comercialmente interessante, pois migrar de
um SGBD para outro não é 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 negócios com uma versão gratuita poderá passar a pagar pelo uso dos
produtos mais “completos” quando a capacidade da versão gratuita for atingida. Nesse ponto
espera-se que a empresa já esteja com um faturamento considerável e provavelmente não se
importará com o investimento.
BANCO DE DADOS | Educação a Distância
59
<http://youtu.be/piSbDWeu3pM>.
Luciano Ramalho – MongoDB
Luciano Ramalho é um dos grandes experts em linguagens de programação dinâmica no Brasil, particularmente Python. Também é um dos pioneiros em NoSQL e especialista em MongoDB, um banco
de dados de documentos. Neste vídeo, Luciano apresenta as vantagens e as aplicações deste banco
de dados.
CONSiDErAçÕES FiNAiS
Nesta unidade nós aprendemos a distinguir o schema, que é um metamodelo do banco de dados,
de suas instâncias. Alterações no schema não costumam ser muito frequentes, enquanto que
as instâncias são manipuladas por meio de operações de inserção, remoção ou atualização.
A boa assimilação da distinção entre schema e instâncias é um conceito fundamental para
o uso efetivo de um sistema de banco de dados – aliás, esta diferenciação entre modelo,
metamodelo e instâncias do modelo é algo bastante frequente na área de software.
Existem diversos tipos de interfaces de interação dos usuários com o sistema de banco de
dados, e a escolha de qual interface utilizar depende muito do propósito e do papel do usuário
ao acessá-lo. Sempre há a avaliação entre os quesitos poder versus facilidade de uso. A
prática faz-se necessária para que um bom desenvolvedor possa escolher o meio de interação
mais adequado de acordo com a situação. Muitas vezes você necessitará do poder da linha
de comando; noutros, alguns cliques numa interface desktop serão mais cômodos. O seu
conhecimento permitirá que você tome a decisão acertada.
A apresentação das arquiteturas de computação em geral e das arquiteturas de sistemas
de bancos de dados pôde esclarecer a forma com que historicamente se desenvolve
estas arquiteturas de aplicações. O artigo apresentado no saiba mais promove uma
reflexão importantíssima para que você possa ponderar sabiamente durante o processo de
desenvolvimento de suas aplicações. Este autor concorda com a proposta do Uncle Bob
Martin, até porque vivemos um período em que muitos conceitos estabelecidos estão sendo
60
BANCO DE DADOS | Educação a Distância
questionados. Poder desenvolver o seu software objetivando o valor de negócios e os seus
usuários é muito mais importante do que quaisquer abstrações de armazenamento de dados
– inclusive o banco de dados. Concentre-se naquilo que é realmente importante para sua
aplicação 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 critérios diferentes para a classificação de
diferentes produtos de sistemas de bancos de dados. Diferentes fornecedores com diferentes
produtos apresentarão uma infinidade de argumentos para que você decida entre um e
outro. Claro que os critérios comerciais influenciarão bastante sua decisão, mas a lista que
assimilamos nesta unidade poderá lhe nortear com alguns argumentos importantes.
Nossa escalada para o domínio dos sistemas de bancos de dados passará na próxima unidade
para um novo degrau: o modelo relacional – que em muitos casos já foi (ou ainda é) sinônimo
de banco de dados. Veremos o porquê de suas qualidades o tornarem tão bem conceituado.
ATIVIDADES DE AUTOESTUDO
1. Defina os seguintes termos: schema, instância, snapshot e schema evolution.
2. Qual a diferença entre sistemas de computação de duas e de três ou N camadas, e como
os sistemas de banco de dados interagem com estes sistemas de computação?
3. Escolha um caso de uso da vida real para avaliar a implementação de um software.
Baseado(a) nos critérios descritos nesta unidade, quais seriam suas considerações para
decidir entre um SGBD e outro?
BANCO DE DADOS | Educação a Distância
61
Fonte: SHUTTERSTOCK.COM
vida longa ao mainframe: a trajetória de um baby boomer
Luiz Fadel, primeiro distinguished engineer da IBM no Brasil, conta sua experiência de 40 anos como
profissional especializado na tecnologia.
Poucos são os profissionais de tecnologia que conseguem sobreviver por tantos anos no mundo
corporativo, em meio às constantes transformações provocadas pela era digital. Com a revolução da
internet, TI passou a ser uma área invadida e dominada, cada vez mais, pela intrigante geração Y –
formada por jovens entre 18 e 30 anos.
Venceralinhadotempoéumdesafio,principalmenteporqueasempresasvêmprivilegiandoo“sangue novo”. Uma dura realidade que atinge quase todos os que tentam o mercado de trabalho. Neste
cenário,édifícilencontrarprofissionaisquetenhampassadoacasados50,masumalevadeexecutivos resiste bravamente.
São os chamados “dinossauros” da indústria de tecnologia no Brasil. No bom sentido, claro. O engenheiro eletrônico paulistano Luiz A. Fadel é um deles. Formado em um dos mais renomados celeiros
deprofissionaisdeengenhariadoPaís,oInstitutoTecnológicodaAeronáutica(ITA),elecontacom
umatrajetóriaprofissionalímpar.
Assistiu aos efeitos da reserva de mercado - que protegeu a indústria nacional de informática - 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 experiência em sistemas de grande porte, continua com o mesmo gás e
energia de quando começou a carreira. Reconhece que ainda tem muitos anos de estrada pela frente.
Fôlego de causar inveja a qualquer um que tenha se formado já na era digital.
“Desempregonãoéumapalavraquefazpartedovocabuláriodosespecialistasemmainframe”,afirmaFadel.“Nemmesmoparanósdageraçãobabyboomer”.Afaltadegentequalificadaparaatuar
com a tecnologia - que vive um momento de retomada no Brasil - tem trazido de volta ao mercado
muitosprofissionaisquejáhaviampenduradoaschuteiras.
62
BANCO DE DADOS | Educação a Distância
Sem planos de sair de cena, o executivo conta um pouco de sua experiência ao longo de duas décadas, toda construída na gigante IBM. Confira trechos da entrevista que Fadel concedeu à Computerworld:
Computerworld - Sua carreira foi construída em uma das tecnologias mais antigas e que ainda continua forte no mercado, sobretudo o brasileiro. Que razão o levou apostar nessa área?
Luiz A. Fadel - Sem dúvida, há muitas oportunidades interessantes que o mercado de mainframe
oferece. Em todos os meus 40 anos de carreira, só lembro um momento crítico para os profissionais
dessa tecnologia. Na década de 90, com o auge dos PCs, a demanda por sistemas de grande porte
sofreu retração. Quadro que anos depois teve recuperação.
Apesar dos percalços, a plataforma evoluiu bastante de 1964 (quando comecei) para cá. Não 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 contrário, é um sistema que completa o
parque de muitas empresas por atender a necessidade de transações 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 privilégio de
participar de projetos envolvendo grandes bancos brasileiros que, na época, tornavam-se os maiores
consumidores da tecnologia. Também estive envolvido na primeira instalação do Mainframe Operating
Systems (Mainframe OS) no País, 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 opção 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 ascensão profissional dentro da carreira técnica. Nunca
precisei mudar de rumo para dar saltos. Tanto que hoje cheguei a um cargo equivalente ao de um
diretor com carreira em negócios, que a IBM chama de distinguished engineer.
É o posto mais alto da empresa na área técnica. Na subsidiária brasileira, só três profissionais têm
esse título. Eu fui o primeiro a conquistá-lo aqui, em 2003. No mundo, existem cerca de 200 pessoas
com o posto. Ou seja, uma grande realização na carreira que não posso ignorar.
Também não podemos esquecer que a IBM sempre foi uma multinacional sólida e de peso. Além de
abrir as portas para que os funcionários possam ter experiência 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 reúne os melhores especialistas da companhia do mundo. Isso quando éramos (os brasileiros) pouco respeitados, quanto ao aspecto técnico, 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. Não há gente
BANCO DE DADOS | Educação a Distância
63
nomeiodapirâmideequempossuiexperiênciaestáempregado.PorissoaprópriaIBMfirmouparceria com as universidades do País para formar gente. Posso garantir que oportunidade é o que não
falta para especialistas em mainframe. Na empresa, por exemplo, somos extremamente valorizados.
Detalhe: há espaço para quem se aposentou e quer voltar e para quem não 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
BANCO DE DADOS | Educação a Distância
UNIDADE III
O MODELO RELACIONAL
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
• Conceituar o modelo relacional.
• Conceituar as restrições do modelo relacional.
• Descrever as operações de manipulação de instâncias do modelo relacional.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Conceituar domínio, atributos, tuplas e relações
• Conceituar os diferentes tipos de restrições do modelo relacional e de banco
de dados
• Descrever as operações de INSERT, UPDATE e DELETE do modelo relacional
e como elas interagem com as restrições do banco de dados
Fonte: SHUTTERSTOCK.COM
INTRODUÇÃO
A partir desta unidade, abordaremos o modelo de dados relacional, que é o modelo utilizado
nos bancos de dados relacionais. O advento do modelo relacional é atribuído a Ted Codd da
IBM em 1970, e imediatamente se popularizou devido à sua simplicidade e sólidos fundamentos
matemáticos: é baseado na teoria geral dos conjuntos e em lógica matemática.
Os primeiros SGBDs relacionais apareceram na década de 1980, sucedendo os bancos de
dados hierárquicos e em rede predominantes em mainframes. Desde então, sua expansão
foi enorme, e acabou tornando-se sinônimo de “banco de dados”. Exemplos de produtos
populares são DB2 (IBM), Oracle e MySQL (Oracle), SQLServer (Microsoft) e PostgreSQL
(software livre).
Dada a relevância do assunto, tanto esta quanto as próximas duas unidades focarão 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.
BANCO DE DADOS | Educação a Distância
67
CONCEITUAÇÃO
No modelo relacional, o banco de dados é representado como um conjunto de relações.
Podemos tentar entender uma relação como uma tabela ou uma planilha de cálculo.
Observando como uma tabela, cada linha representa uma coleção 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 instância
de um contato real. Os nomes das colunas (Nome, Sobrenome, Nascimento) representam
informações 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 relação. O tipo de dado que pode ser
inserido em cada coluna é denominado de domínio, e representa os valores possíveis de cada
atributo.
Características de uma Relação
A seguir analisaremos as características atribuídas a uma relação (tabela) no modelo relacional:
68
BANCO DE DADOS | Educação a Distância
1. Ordem das tuplas. Como uma relação (tabela) representa a noção matemática de
conjunto, relações não possuem ordem. Isso significa que não há uma ordem natural
particular imposta dentro da relação. Como estes dados serão 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 é caótica. Durante o desenvolvimento de aplicações, não
se deve assumir nenhuma premissa sobre a ordem dos elementos dentro de uma
relação.
2. Atomicidade dos valores e o valor NULL. No modelo relacional, cada valor de
cada atributo dentro de uma tupla é atômico. Atômico no mesmo sentido de átomo
e em transações: estes valores não podem ser divididos em outros componentes.
Assim, ao menos no modelo relacional puro, não são possíveis valores compostos
ou múltiplos 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 não se aplicar àquela
tupla; o valor não 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. Semântica de uma Relação. Relações podem representar situações factuais. Podemos considerar que cada tupla da relação Contato seja um fato: você, no mundo
real, possui um Contato verdadeiro que pode ser abstraído com os dados daquela
tupla. Algumas relações representam dados sobre entidades (como é o caso de Contato). Outras relações 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 relações
(tabelas). Isto simplifica muito o modelo e sua utilização, pois não precisamos de
notações nem de ferramentas para fazer distinção entre as entidades e os relacionamentos entre elas.
BANCO DE DADOS | Educação a Distância
69
Fonte: SHUTTERSTOCK.COM
Bancos de dados livres crescem no Brasil
Uma nova geração de bancos de dados livres começa a ganhar adesão de várias empresas do setor
financeiro e industrial do país, revela estudo.
GENILSON CEZAR, ESPECIAL PARA COMPUTERWORLD
Uma nova geração de bancos de dados livres começa a ganhar adesão de várias empresas do setor
financeiroeindustrialdopaís,paraaplicaçõesespecíficasouembarcadasemequipamentosdecomunicação, e já está criando um impacto positivo entre os desenvolvedores.
Essa é uma conclusão do consultor independente Fernando Lozano, community manager da Java.
net, apresentada na quarta-feira (17/08) no Developer’s World 2005, realizado pelo IDG Brasil, no
Hotel Jaraguá, em São Paulo.
Lozano vem trabalhando na implementação de projetos de banco de dados livres em várias empresas
como o Instituto Brasileiro de Petróleo e Gás, Elephant Internet, iBest e Amsterdam Sauer. “O banco
de dados livre é hoje uma alternativa viável e de alta performance, além 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 adoção do produto
em licitações públicas.
“Muitos desenvolvedores estão decididos a contribuir para o avanço do open source, mesmo sem ter
qualquerespéciederetornofinanceiro,nomáximoumoutropatrocínioparaparticiparemcongressos
internacionais”,afirmaMacieira.
Fonte: <http://computerworld.uol.com.br/tecnologia/2005/08/18/idgnoticia.2006-05-15.4431159825/>.
Acesso em: 1 ago. 2012.
70
BANCO DE DADOS | Educação a Distância
RESTRIÇÕES DO MODELO RELACIONAL
Restrições no modelo relacional são uma forma de se restringir os valores que os atributos
das tuplas podem possuir num determinado snapshot. Essas restrições podem ser derivadas
dos próprios relacionamentos do modelo relacional ou de restrições de valores de negócios
impostos pelo modelo de software sendo desenvolvido.
Os tipos de restrições do modelo relacional são de domínio, de chave e de valores nulos, e de
integridade e integridade referencial. Estas são descritas nas seções seguintes.
Restrições de domínio
As restrições de domínio impõem ao banco de dados quais valores podem ser permitidos
em cada atributo dentro de cada tupla em cada tabela. Algumas destas restrições podem
ser de tipo (você não pode colocar um valor String num campo inteiro ou vice-versa). Outras
restrições possíveis podem restringir valores dentro de um tipo (somente os inteiros maiores
que zero). Exploraremos melhor estas restrições de domínio quando tratarmos das restrições
do SQL.
Restrições de chave e de valores nulos
Como uma relação (tabela) representa um conjunto na definição formal da teoria dos conjuntos,
não há a possibilidade de uma relação conter elementos repetidos; pois num conjunto, todos
os elementos são distintos. Desse modo, havendo ou não a possibilidade de se haver registros
com dados semelhantes dentro do modelo de negócios, utiliza-se uma restrição denominada
de chave primária que define de modo único cada registro dentro da relação. Esta chave
primária pode ser composta de um único atributo ou mesmo de um conjunto de atributos.
Não há verdades absolutas na área de Tecnologia da Informação, mas no passado foi bastante
comum a utilização de chaves primárias compostas para representar as tuplas de uma relação.
Matematicamente, não há diferença entre uma chave primária simples (um único atributo) e
BANCO DE DADOS | Educação a Distância
71
uma chave primária composta (múltiplos atributos). Baseando-se no princípio da Navalha de
Occam, preferimos optar pela solução mais simples: chaves primárias simples.
Outra prática atual diz respeito à visibilidade por parte do usuário do valor da chave primária. Em
aplicações legadas, é bastante comum visualizar este atributo em formulários cadastrais e em
listagens. Uma corrente de pensamento pondera que este número não faz sentido ao usuário
e não deve ser exibido. Não exibi-lo também permite que a chave primária seja trocada numa
eventualidade em que o particionamento ou a replicação de banco de dados seja necessária
e implique numa troca da chave primária. Pense: o usuário deseja ou precisa saber a chave
primária ou é a sua aplicação que foi projetada para obrigar o usuário a utilizá-la?
PrincípiodaNavalhadeOccam(ouOckham)
“Se em tudo o mais forem idênticas as várias explicações de um fenômeno, a mais simples é a melhor”
- William de Occam.
Popularmente costumamos citar este princípio como: “se há mais de uma explicação para um fenômeno, e todas parecem igualmente corretas, então a mais simples é a mais correta”.
Emqueoutraspartesdasuavidaprofissionalpoderíamosaplicarcomsucessoesteprincípio?
Outro tipo de restrição são as chaves ou chaves únicas: como o próprio nome já implica,
representam atributos dentro de uma tupla que não podem ter valores repetidos.
Valores nulos (NULL) podem ser restringidos com uma restrição de non-NULL. Atributos de
uma tupla com esta restrição obrigatoriamente devem possuir um valor válido que não seja
nulo.
72
BANCO DE DADOS | Educação a Distância
Integridade, Integridade referencial e chaves estrangeiras
A restrição de integridade estabelece que nenhuma tupla pode possuir uma chave primária
com valor NULL. Como a chave primária é utilizada para identificar de modo único cada tupla
da relação, permitir o valor NULL faria com que fosse possível ter duas tuplas com a mesma
chave primária nula – sendo impossível distinguir uma da outra.
A restrição de integridade referencial é especificada entre duas relações (tabelas) distintas, e
é utilizada para manter a consistência entre tuplas pertencentes às duas relações. Isto implica
que uma restrição de integridade referencial obriga uma tupla numa relação a referenciar a
uma tupla existente em outra relação – 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
Número
443032020
4420201010
contato_id
1
3
Figura 5
Fonte: o autor
Para compreender melhor este conceito, analisemos a Figura 5. Restrições de integridade
referencial são criadas entre duas tabelas diferentes (ou excepcionalmente na mesma tabela).
Veja o relacionamento entre as tabelas Contato e Telefone. Na tabela Telefone, o atributo
BANCO DE DADOS | Educação a Distância
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.
Fonte: SHUTTERSTOCK.COM
Estudo de caso:
DetrandoCearáeconomizouR$1,7milhãocombancodedadoslivre
Tomada há cerca de dois anos pelo governo do Ceará, a decisão de substituir a solução de banco de
dados da Oracle pelo PostgreSQL fez com que o Detran economizasse gastos com pagamento de
licenças e serviço de suporte técnico.
Em 2008, o administrador de banco de dados Nabucodonosor Coutinho foi convidado pelo Detran do
Ceará para cuidar do processo de migração do banco de dados. Em apresentação 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 aplicação ligado a um servidor Oracle. Era nesta
situação que as 1.287 tabelas e 426 views do banco se encontravam. Gastava-se muito dinheiro com
o pagamento de licenças e o governador queria que o Detran utilizasse o Software Livre. Pensou-se
emutilizaroMySQL,masoptou-sepeloPostgreSQL,quejáeraobancodedadosoficialdoGoverno
do Ceará. Como trabalhava há cerca de 8 anos com o PostgreSQL, minha empresa foi chamada para
74
BANCO DE DADOS | Educação a Distância
participar do projeto.
Quaisforamasprincipaisdificuldadesencontradas?
Aprincipaldificuldadeeraqueaequipeestavaocupadacomastarefasdiáriasdemanutençãoedesenvolvimento de novas ferramentas para o órgão. Além disso, a base de dados era muito complexa
e utilizava muitos recursos que até então estavam disponíveis apenas no Oracle. Outro fator negativo
foi que poucos técnicos tinham conhecimento em PostgreSQL.
Como é a arquitetura do banco hoje?
Agora o servidor de aplicação é ligado diretamente a um balanceador de carga, que é ligado a dois
servidores do banco de dados.
Além da economia com as licenças, quais outros resultados positivos a nova arquitetura trouxe?
Asconsultasficarammaisrápidas.Temumaquelevava2horase,depoisdamigração,passouaser
realizada em 6 minutos. Na primeira vez, o responsável do Detran não 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.
Operações de atualização do modelo relacional
Existem três operações básicas de atualização que podem alterar o snapshot do banco de
dados. Vamos nos referir a estas operações em seu termo em inglês, pois eles também
correspondem aos comandos em SQL que veremos nas próximas duas unidades. As
operações são: Insert (Inserção), Update (Modificação) e Delete (Remoção). A operação de
Insert é utilizada para inserir novas tuplas numa relação; a operação Update é utilizada para
atualizar valores de uma tupla já existente dentro de uma relação; e a operação Delete é
utilizada para remover uma tupla existente de uma relação. Em cada uma dessas operações,
são verificadas as restrições descritas nas seções anteriores. Caso alguma das restrições seja
violada, o SGBD reportará um erro e a operação não será completada com sucesso.
BANCO DE DADOS | Educação a Distância
75
Insert
A operação de Insert fornece os atributos de uma nova tupla para ser adicionada
na relação.
Restrições de domínio podem ser violadas se algum dos valores atribuídos não for
do tipo apropriado do atributo.
Restrições de chave podem ser violadas se alguma outra tupla possuir a mesma
chave repetida.
Restrições de integridade podem ser violadas se a chave primária atribuída for
NULL.
Restrições de integridade referencial podem ser violadas se o valor de qualquer
chave estrangeira atribuída não existir no relacionamento referenciado.
Update
A operação de Updatemodificaosvaloresdeumoumaisatributosemumaoumais
tuplas numa relação.
Restrições semelhantes à operação de Insert podem ser violadas na execução desta operação.
Delete
A operação de Delete remove uma tupla da relação. A única restrição que pode ser
violada pela operação Delete é a restrição de integridade referencial. Neste caso, a
tupla sendo removida é referenciada por uma outra tupla num relacionamento entre
duas relações.
<http://youtu.be/gx1xT_GzH_g>.
Alexandre Porcelli – SQL, NoSQL ou NewSQL: Onde armazenar meus dados? - DevInVale 2011
76
BANCO DE DADOS | Educação a Distância
Fonte: SHUTTERSTOCK.COM
Os bancos de dados relacionais estão condenados?
Recentemente uma grande leva de bancos de dados não relacionais surgiram tanto na nuvem quanto
fora dela. Uma das principais mensagens que este cenário nos traz é “se você precisa de uma grande
escalabilidade sob demanda, você precisa de um banco de dados não relacional”.
Se isto for verdade, então é 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 estão com os dias contados
e irão declinar com o passar do tempo? Neste artigo nós analisaremos a tendência atual de se migrar
debancosdedadosrelacionaisemcertassituaçõeseoqueissosignificaparaofuturodosbancos
de dados relacionais.
Bancos de dados relacionais já estão presentes no mercado há mais de 30 anos. Durante este tempo,
muitas pseudo-revoluções surgiram e se foram, e todas elas supostamente deveriam acabar com os
bancos de dados relacionais. Todas estas revoluções fracassaram, claro, e nenhuma chegou a fazer
sequer um arranhão na dominância dos bancos de dados relacionais.
Primeiro,umpoucodehistórico
Um banco de dados relacional é essencialmente um grupo de tabelas (entidades). Tabelas são compostasdecolunaselinhas(tuplas).Estastabelaspossuemrestrições,erelacionamentossãodefinidos entre elas. Bancos de dados relacionais são consultados através da SQL, e os conjuntos de
BANCO DE DADOS | Educação a Distância
77
resultados são produzidos pelas consultas que acessam os dados de uma ou mais tabelas. Múltiplas
tabelas sendo acessadas numa única consulta são “unidas”, tipicamente por um critério definido nas
colunas de relacionamento das tabelas. Normalização é um modelo de estruturação de dados utilizado em bancos de dados relacionais que garante a consistência dos dados e remove sua duplicação.
Car
Color
Carkey
Markekey Colorkey Colorkey Year
Colorkey
Color
1
1
1
2
2003
1
Red
2
2
1
3
2005
2
Green
3
2
1
2
2005
3
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 são facilitados através de Sistemas Gerenciadores de Bancos de Dados Relacionais (SGBDR). Praticamente todos os sistemas de bancos de dados em uso atualmente
são SGBDRs, incluindo Oracle, SQL Server, MySQL, Sybase, DB2, TeraData etc.
Os motivos para a dominância do modelo relacional não são triviais. Eles têm continuamente oferecido
o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade no gerenciamento de dados genéricos.
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 possíveis
caminhos de execução de consulta, os quais o otimizador deve avaliar em tempo de execução. Tudo
isto é escondido dos usuários, mas sob o capô os SGBDRs determinam o “plano de execução” que
melhor atende nossas requisições utilizando recursos como algoritmos baseados em custo.
O problema com bancos de dados relacionais
Mesmo que os SGBDRs forneçam aos usuários o melhor conjunto de simplicidade, robustez, flexibilidade, desempenho, escalabilidade e compatibilidade, seu desempenho em cada uma destas áreas
não é necessariamente melhor que o de uma solução alternativa buscando um destes benefícios
isolado. Isto não foi um grande problema até agora, pois a dominância universal dos SGBDRs tem
78
BANCO DE DADOS | Educação a Distância
compensado a necessidade de se quebrar essas barreiras. No entanto, se você realmente tem uma
necessidade que não pode ser atendida por um banco de dados relacional genérico, sempre houve
alternativas para atender estes nichos.
Atualmente vivemos uma situação um pouco diferente. Para um grande número de aplicações, estes
benefícios estão se tornando mais e mais críticos; e embora ainda sejam considerados um nicho,
estão se tornando populares, tanto que para muitos usuários de bancos de dados estes requisitos
estão começando a sobrepor os outros em importância. Este benefício é escalabilidade. À medida
que mais e mais aplicações são implantadas em ambientes que possuem cargas de trabalho massivas, tais como serviços web, seus requisitos de escalabilidade podem mudar rapidamente e crescer
a níveis muito elevados. O primeiro cenário pode ser difícil 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, quão rapidamente você pode ampliar o seu hardware? O segundo cenário 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 é alcançada, você precisa realizar uma
escalabilidade horizontal e distribuir a carga entre múltiplos 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 invés de apenas alguns, e as complexidades tornam-se
avassaladoras, e as características que tornam os SGBDRs tão atraentes drasticamente reduzem sua
viabilidade como plataforma para grandes sistemas distribuídos.
Os fornecedores de serviços na nuvem tiveram que tratar esta limitação, pois uma plataforma na nuvem sem uma base de dados escalável não chega a ser uma plataforma viável. Assim, para fornecer
aos clientes uma plataforma escalável para armazenar seus dados, os fornecedores tiveram uma
única solução. Estes fornecedores tiveram que implementar um novo tipo de sistema de banco de
dados que focasse em escalabilidade, ao custo de outros benefícios dos bancos de dados relacionais.
Estes esforços, combinados com aqueles de fornecedores de nichos de mercado, levaram à criação
de uma nova geração de sistemas gerenciadores de banco de dados.
A nova geração
Este novo tipo de sistema gerenciador de banco de dados é comumente chamado de chave-valor. De
fato, não há ainda um nome oficial, então é possível encontrar nomes como orientado a documentos, orientado a atributos, banco de dados distribuído (embora bancos de dados distribuídos também
possam ser relacionais), arrays particionados, tabelas hash distribuídas, e bancos de dados de chave-valor. Embora cada um destes nomes aponte para peculiaridades específicas desta nova abordagem,
são todas variações do mesmo tema, que chamaremos de bancos de dados de chave-valor.
Não importa como você chame, este “novo” tipo de banco de dados já está no mercado há algum
BANCO DE DADOS | Educação a Distância
79
tempo e tem sido utilizado em aplicações especializadas para as quais os bancos de dados relacionais
não serviam. Mas sem a escala que a web e a nuvem trouxeram, este novo tipo teria fica incógnito.
Atualmente o desafio é identificar se este novo tipo de banco de dados ou um banco de dados relacional é o mais adequado para uma aplicação particular.
Bancos de dados relacionais e bancos de dados de chave-valor são fundamentalmente diferentes e
projetados para atender diferentes requisitos. Uma comparação lado-a-lado permite comparar superficialmente estas diferenças e apresentamos uma inicial abaixo:
Definições de banco de dados
Bancos de dados relacionais
Bancos de dados de chave-valor
•
Bancos de dados contêm tabelas, tabelas
contêm linhas e colunas e linhas são compostas dos valores das colunas. Linhas
dentro de uma mesma tabela possuem
todas as mesmas definições de schema.
•
•
O modelo de dados é conhecido a priori.
Um schema é fortemente tipado e possui
restrições e relacionamentos que forçam a
integridade dos dados.
Domínios podem ser visualizados inicialmente como uma tabela, mas diferentemente de uma tabela você não precisa
definir um schema para um domínio. Um
domínio é basicamente um “balde” em
que você coloca itens. Itens dentro de
um mesmo domínio podem ter diferentes
schemas.
•
Itens são identificados por chaves, e um
dado item pode ter um conjunto de atributos dinâmicos associado.
•
Em algumas implementações, atributos
são do tipo String. Em outras implementações, atributos possuem tipos simples que
refletem os tipos do código tais como ints,
arrays de String e listas.
•
Não existem relacionamentos definidos de
modo explícito entre domínios ou mesmo
dentro de um mesmo domínio.
•
•
O modelo de dados é baseado numa
representação “natural” dos dados que
contém, e não nas funcionalidades da
aplicação.
O modelo de dados é normalizado para
remover duplicações de dados. A normalização estabelece relacionamentos entre
tabelas. Estes relacionamentos associam
os dados entre as tabelas.
Sem Join de Entidades
Bancos de dados de chave-valor são orientados a itens, o que significa que todos os dados relevantes
são armazenados dentro do próprio item. Um domínio (que você pode visualizar como uma tabela)
pode conter itens muito diferentes um do outro. Por exemplo, um domínio pode conter itens de clientes
e itens de pedidos. Isto significa que comumente os dados são duplicados entre itens num mesmo
domínio. Esta é uma prática aceitável porque espaço em disco é algo relativamente barato. Mas este
modelo permite que um único item contenha todos os itens relevantes, o que aumenta a escalabilida-
80
BANCO DE DADOS | Educação a Distância
de ao eliminar a necessidade de joins entre múltiplas 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 são inevitáveis. 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. Não importa se estes dados residam no mesmo domínio ou em domínios diferentes; quando um cliente cria um pedido você provavelmente não quer armazenar os atributos tanto do
cliente quanto do produto no mesmo item do pedido.
Ao invés disso, pedidos precisam armazenar as chaves dos itens de cliente e produto. Embora isso
seja perfeitamente possível em bancos de dados chave-valor, estes relacionamentos não estão definidos no modelo de dados em si, e portanto o sistema gerenciador de banco de dados não pode forçar 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 aplicação.
Acesso a dados
Bancos de dados relacional
Banco de dados chave-valor
Dados são criados, atualizados, removidos e
consultados através de SQL.
Dados são criados, atualizados, removidos e
consultados através de APIs.
Consultas SQL podem acessar os dados de
uma única ou de múltiplas tabelas através de
joins.
Algumas implementações fornecem uma sintaxe básica parecida com SQL para definir critérios de filtragem.
Consultas SQL incluem funções de agregação
e filtros complexos.
Somente predicados básicos de filtragem podem ser aplicados na maioria das vezes.
Normalmente possuem meios de se embutir
lógica próximo aos dados através de triggers e
stored procedures.
A lógica de integridade da aplicação e seus
dados está toda implementada no código da
própria aplicação.
Interface com a aplicação
Bancos de dados relacional
Banco de dados chave-valor
Tendem a oferecer uma API própria ou uma API
genérica como o ODBC ou JDBC.
Tendem a oferecer APIs SOAP e/ou REST para
acesso aos dados.
Os dados são armazenados num formato que
representa sua estrutura natural, de modo que
deve haver um mapeamento entre as estruturas do código da aplicação e a estrutura relacional.
Os dados podem ser armazenados de modo
mais eficiente em compatibilidade com o código
da aplicação, 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 benefício é que os bancos de dados chave-valor são simples e portanto escalam melhor
que os bancos de dados relacionais atuais. Se você está desenvolvendo um sistema com uma equipe
BANCO DE DADOS | Educação a Distância
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, então considere seriamente um banco
de dados chave-valor.
Como bancos de dados chave-valor escalam facilmente e de modo dinâmico, também são os banco
de dados preferidos de serviços de fornecedores de armazenamento através de web services com
potencial de escalabilidade. Usuários 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 usuário, com pouquíssimas limitações provocadas pelo
tamanho da plataforma.
Melhor adaptado para o código
Modelos de dados relacionais e modelos de código de aplicações são tipicamente construídos de
modo diferente, o que leva a incompatibilidades. Desenvolvedores normalmente superam estas incompatibilidades com código que mapeiam os seus objetos ao modelo relacional, um processo comumente denominado de mapeamento objeto-relacional. Este processo, que essencialmente requer
muito código de infraestrutura e não possui valor de negócios imediato, pode demandar uma parcela
considerável do tempo e do esforço do desenvolvimento da aplicação.
Outros argumentos a favor deste tipo de banco de dados, tais como “bancos de dados relacionais
podem se tornar pesados ou desajeitados” não são convincentes. Mas antes de entrar de cabeça no
mundo dos bancos de dados chave-valor, considere algumas limitações existentes.
Desvantagens de bancos de dados chave-valor
As restrições inerentes de um banco de dados relacional garantem que os dados em seu nível mais
baixo possuem integridade. Dados que violam as restrições de integridade não podem ser inseridos
fisicamente no banco de dados. Estas restrições não existem em bancos de dados de chave-valor,
então a responsabilidade de garantir a integridade dos dados é da aplicação. Mas o código da aplicação pode conter bugs. Bugs num banco de dados relacional devidamente projetado normalmente
não 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 benefícios de um banco de dados relacional é que ele te força a um processo de
modelagem de dados. Se bem feito, o processo de modelagem cria uma estrutura lógica no banco
de dados que reflete os dados contidos, ao invés de refletir a estrutura da aplicação. Dados, então,
tornam-se quase que independentes de aplicação, o que reflete que outras aplicações podem utilizar o
mesmo conjunto de dados e a lógica da aplicação pode ser alterada sem modificar o modelo de dados.
Não se esqueça também da compatibilidade. Diferentemente de bancos de dados relacionais, bancos de dados na nuvem não costumam seguir padrões definidos. Embora todos tenham conceitos
similares, cada um possui sua própria API, interfaces de consulta específicas e peculiaridades. Desse
82
BANCO DE DADOS | Educação a Distância
modo, você terá que confiar em seu fornecedor, pois você não poderá simplesmente trocá-lo depois
se estiver descontente.
Limitações de análise
Na nuvem, bancos de dados chave-valor são compartilhados, o que significa que muitos usuários e
aplicações 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ê não pode executar uma consulta que leve mais que 5 segundos. Com o Google AppEngine, você não pode retornar mais que 1000 itens por consulta.
Estas limitações não são problemas para aplicações comuns com adição, atualização, remoção e
consulta de poucos itens. Mas o que ocorre quando sua aplicação torna-se bem sucedida? Você atraiu
muitos usuários e ganhou muitos dados, e agora você quer criar valor agregado para seus usuários 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. Situações como criação de padrões de
uso e fornecimento de recomendações baseado no histórico do usuário podem tornar-se difíceis e
talvez impossíveis em algumas plataformas.
Neste caso, você provavelmente irá implementar um banco de dados analítico em separado, populado
a partir de seu banco de dados chave-valor, para que estas análises sejam executadas. Planeje com
antecedência onde e como você o fará. Você o hospedaria na nuvem ou on premise? A latência entre
você e o provedor na nuvem seria um problema? Seu banco de dados chave-valor suporta isso? Se
você possui 100 milhões 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 sério a considerar, mas se esqueça da sua
necessidade de converter os dados em uma fonte de receita. Toda a escalab do mundo é inútil se os
seus usuários migrarem para seu concorrente porque ele possui funcionalidades mais interessantes.
Competidores de serviços baseados em nuvem
Um bom número de fornecedores de serviços web agora oferece bancos de dados chave-valor compartilhados no estilo pague-pelo-uso. A maioria deles atende aos critérios definidos até agora, mas
cada um possui funcionalidades únicas que variam dos padrões 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
BANCO DE DADOS | Educação a Distância
83
O SimpleDB é um banco de dados de chave-valor orientado a atributos disponível na plataforma da
Amazon Web Services.
O SimpleDB possui diversas limitações. Primeiro, uma consulta pode ser executada por no máximo
5 segundos. Segundo, não há tipos de dados além de Strings. Tudo é armazenado, recuperado e
comparado como uma String. Comparações de data não funcionarão a não ser que você converta
todas as datas para o formato ISO8601. Terceiro, o tamanho máximo de uma String é limitado a 1024
bytes, o que limita quanto de texto (por exemplo, descrições de produtos) você pode armazenar num
único atributo. Mas como o schema é dinâmico e flexível, você pode contornar este limite adicionado
“descricao1”, “descricao2” etc. O problema é que cada item é limitado em 256 atributos.
Uma característica chave do SimpleDB é o seu modelo de consistência eventual. Este modelo de
consistência é bom para concorrência, mas significa que se você alterou o atributo de um item, estas
mudanças não serão refletidas imediatamente nas operações de leitura. Embora as chances de algum
problema ocorrer em função disso sejam pequenas, você deve se preparar para estas situações. Por
exemplo, você não 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 é construído sobre o BigTable, o sistema interno do Google para
manipulação de dados estruturados. Em si, o AppEngine não é 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 contém coleções de elementos num único item.
Você provavelmente utilizará este banco de dados se planeja construir aplicações no Google AppEngine. Entretanto, diferentemente do SimpleDB, você não consegue interfacear diretamente com o
AppEngine Datastore (ou com o BigTable) utilizando uma aplicação foram da nuvem do Google.
Microsoft: SQL Data Services
84
BANCO DE DADOS | Educação a Distância
O SQL Data Services é parte da plataforma de serviços web Microsoft Azure. O serviço do SDS é
na verdade uma aplicação em si que roda sobre vários SQL Servers, que formam o mecanismo de
armazenamento da plataforma. Embora os bancos de dados de infraestrutura sejam relacionais, você
não precisa acessá-los; SDS é um banco de dados chave-valor, assim como as outras plataformas
discutidas até agora.
A Microsoft parece estar sozinha neste cenário 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 distribuição direito, e com o passar do tempo,
adicionar funcionalidades que ajudarão a diminuir a diferença entre bancos de dados chave-valor e
relacionais.
Fornecedores on-premise
Fora da nuvem, existem vários produtos de bancos de dados chave-valor que podem ser instalados
on-premise. A maioria é open source; tendo acesso ao código-fonte talvez você possa analisar e
tornar-se melhor ciente de potenciais problemas e limitações – uma vantagem que você não teria em
fornecedores de código 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 distância entre bancos de dados orientados a documentos e relacionais ao permitir que “visões”
sejam criadas dinamicamente com JavaScript. Estas visões mapeiam os dados do documento numa
estrutura parecida com tabelas que podem ser indexadas e consultadas.
Até o momento, o CouchDB não é realmente um banco de dados distribuído. Ele possui funções
de replicação que permite que os dados sejam sincronizados entre servidores, mas não é o tipo de
distribuição suficiente para construir ambientes de alta escalabilidade. A comunidade do CouchDB,
entretanto, está trabalhando disso.
Projeto Voldemort
BANCO DE DADOS | Educação a Distância
85
O projeto Voldemort é um banco de dados distribuído chave-valor cujo objetivo é escalar horizontalmente num grande número 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 também utiliza um modelo de consistência 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 invés
de ser puramente chave-valor.
tomando uma decisão
Basicamente há quatro motivos para se escolher uma plataforma de banco de dados não relacional
chave-valor para sua aplicação:
1.
Seus dados são orientados a documentos, tornando-os uma escolha natural para o modelo de
chave-valor ao invés do modelo relacional.
2.
Seu ambiente de desenvolvimento é altamente orientado a objetos, e um banco de dados chave-valor pode diminuir a quantidade de código de infraestrutura.
3.
O banco de dados é barato e integra com sua plataforma de serviços web.
4.
Sua principal preocupação é a alta escalabilidade sob demanda – ou seja, uma escalabilidade
distribuída de larga escala que não pode ser obtida com escalabilidade vertical.
Ao tomar sua decisão, lembre-se das limitações 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 não. Pelo
menos por enquanto.
Fonte: <http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php>.
Acesso em: 14 ago. 2012.
86
BANCO DE DADOS | Educação a Distância
CONSIDERAÇÕES FINAIS
Nesta unidade, inicialmente descrevemos os conceitos de domínio, tuplas, atributos e
relações do modelo relacional. A abordagem deste autor para explicar o modelo relacional
é a de tentar fugir um pouco das definições formais matemáticas do modelo e focar nos
conceitos fundamentais do modo mais próximo possível 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 série de restrições impostas para que se possa garantir a
consistência dos dados presentes nos diferentes domínios, bem como a consistência do
próprio modelo. As restrições discutidas foram de domínio, de chave, de valores nulos,
de integridade e de integridade referencial e chaves estrangeiras. Estas restrições são os
atributos que tornam o modelo relacional tão interessante e tão conceituado perante alguns
desenvolvedores e, claro, DBAs. Enxergar o sistema de banco de dados como uma aplicação
terceira que deve ser integrada ao software que desenvolvemos é uma visão que nos permite
entender o porquê de tamanha valorização das restrições. De fato, com estas restrições
(quando bem implementadas), há a garantia da integridade e consistência das informações
armazenadas.
As operações de modificação do modelo relacional descritas no modelo relacional são as
operações de Insert, Update e Delete e todas podem provocar violações do modelo – sendo
cada uma delas abordada em suas respectivas seções.
Agora que já temos toda a base conceitual do popular modelo de dados relacional, podemos
passar a interagir e executar operações com os sistemas de bancos de dados relacionais. Para
nossa sorte, há um padrão bem estabelecido e sólido de interação com os SGBDs relacionais,
que é a linguagem SQL. O assunto SQL é tão importante e será tão utilizado em sua vida
profissional que dedicaremos as duas próximas unidades para tratá-lo.
BANCO DE DADOS | Educação a Distância
87
ATIVIDADES DE AUTOESTUDO
1. Por que não existe uma ordem definida para as tuplas dentro de uma relação?
2. Quais são as situações em que é adequada a utilização de valores NULL?
3. Defina os conceitos de integridade e integridade referencial.
88
BANCO DE DADOS | Educação a Distância
UNIDADE IV
SQL Básico
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
• Definir o que é SQL.
• Apresentar os comandos de definição e uso da SQL.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Definição e histórico da SQL
• Descrição dos comandos de definição de dados e tipos em SQL
• Descrição dos comandos de consulta básicos em SQL
• Descrição dos comandos de modificação de dados em SQL
Fonte: SHUTTERSTOCK.COM
INTRODUÇÃO
A primeira ideia que vem à cabeça de um desenvolvedor experiente quando se fala de banco
de dados relacionais é SQL. Realmente, talvez uma das boas razões pelas quais os SGBDs
relacionais são tão difundidos deve-se ao fato de que a SQL é uma ferramenta bastante
madura, elaborada e bem projetada.
Em português, pronuncia-se SQL como uma sigla, com o som de cada uma das letras
separadas, “esse-quê-ele”. Porém, nas conversas em projetos internacionais que você fará,
ou em conferências que você participará em sua vida profissional, perceberá que em inglês
SQL é pronunciado como “síquel”. O motivo é curioso e não 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 Inglês Estruturado) – daí o
motivo da pronúncia como “síquel”.
SQL é uma linguagem diferente das linguagens de programação que você provavelmente
aprendeu até agora. Em qualquer curso de programação, costuma-se ensinar inicialmente
linguagens de programação imperativas (como C, Pascal, Java ou Python), em que você
é responsável por escrever os comandos na ordem de execução esperada. Neste tipo de
BANCO DE DADOS | Educação a Distância
91
linguagem, preocupamo-nos em instruir o computador no modo como ele deve executar as
tarefas. O resultado de seu processamento é uma consequência 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 reflexão sobre a natureza declarativa da SQL. Na SQL, ao definirmos somente o
que esperamos de resultado ao invés do como, permitimos que o SGBD decida como é que
ele deve executar as instruções. Há 10 anos, este seria um fator determinante para decidir
entre um produto e outro. A evolução dos produtos comerciais e livres fez com que esta
diferença diminuísse de modo significativo – embora, dependendo dos casos de uso de sua
aplicação, a diferença ainda possa ser relevante. Em alguns casos, centenas de parâmetros
de configuração 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 diferenças entre as diversas implementações 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 padrão para a SQL. A versão mais popular
deste padrão é a SQL-92, embora haja uma versão mais recente: a SQL:1999. Infelizmente, os
fabricantes de SGBDs não seguem 100% o padrão, o que torna a tarefa de migração de um
produto para outro um pouco mais difícil. Comercialmente, é uma estratégia interessante para
os fabricantes, pois baseia-se no aprisionamento do cliente: uma vez comprometido com um
produto, o custo para migração (em tempo e esforço) torna-se elevado o suficiente para que o
cliente desista da ideia. Já para os usuários, este é um fato infeliz. De positivo do padrão SQL92 temos que mesmo com as sutis diferenças entre as implementações da SQL em diferentes
produtos, as semelhanças se sobressaem e permitem que os desenvolvedores de software
possam aprender facilmente a lidar com produtos concorrentes.
A SQL possui comandos tanto para a criação de definições de dados (criação de schemas)
quanto para a execução de comandos de manipulação de banco de dados (consultas e
92
BANCO DE DADOS | Educação a Distância
atualizações). É uma linguagem bastante abrangente. É por este motivo que trataremos da
SQL em duas unidades distintas. Esta primeira abordará a criação de schemas e os comandos
básicos da linguagem, enquanto que a próxima unidade abordará os comandos um pouco
mais avançados.
DEFINIÇÕES DE DADOS E TIPOS EM SQL
Na unidade anterior, definimos os termos relação, tupla e atributo do modelo relacional. Em
SQL, estes termos são denominados respectivamente de tabela, linha e coluna. Boa parte
dos comandos SQL relacionados à criação e definição de dados utiliza o comando CREATE.
O conceito de schema
Em sua versão inicial, a SQL não possuía um mecanismo para agrupar tabelas relacionadas.
Como consequência, 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 são
finalizados por um ponto-e-vírgula:
create schema agenda;
Além de agrupar logicamente as tabelas, um schema também é convenientemente utilizado
para autorizar/restringir o acesso pelos usuários. Você pode autorizar determinados usuários
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 parâmetro do
BANCO DE DADOS | Educação a Distância
93
comando é o nome da tabela sendo criada, seguido dos atributos e seus respectivos tipos e
eventuais restrições do atributo. Restrições 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 aflição
id
nome
grupo_fk
contato_fk
Figura 6
Fonte: o autor
Os seguintes comandos criam as tabelas definidas na Figura 6:
94
BANCO DE DADOS | Educação a Distância
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,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
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),
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
BANCO DE DADOS | Educação a Distância
95
Em algumas situações, não é possível definir as restrições de integridade referencial e chave
estrangeira no próprio CREATE TABLE, pois as tabelas referenciadas ainda não existem. Na
próxima unidade, abordaremos como resolver este impasse.
Tipos de dados
A SQL define um conjunto de tipos de dados básicos para os seus atributos. Diferentes
produtos adicionam tipos de dados diferentes ao conjunto suportado, mas todos os produtos
disponíveis no mercado suportam ao menos estes tipos básicos:
Tipos numéricos
Tipos de dados numéricos suportam dados inteiros (INT e SMALLINT)
e de ponto flutuante (FLOAT e DOUBLE). Números com precisão decimal (normalmente utilizados em cálculos de moeda, por exemplo)
são DECIMAL ou NUMERIC, declarados como DECIMAL(a,b) ou
NUMERIC(a,b) onde “a” é o número de dígitos inteiros e “b” é o número
de dígitos decimais.
Tipos Caractere
Tipos de caractere podem ser de tamanho fixo ou variável. Os atributos
de tamanho fixo podem ser declarados como CHAR(n) onde “n” é o
número máximo de caracteres suportado pelo atributo. Para especificar
um atributo de tamanho variável, utiliza-se o tipo VARCHAR(n).
Para se entender o critério de uso entre um e outro, é necessário entender como é a alocação de espaço destes tipos no arquivo físico. Se
o tamanho for fixo (CHAR), o SGBD já aloca este tamanho predefinido
no arquivo: as buscas podem ser mais rápidas, pois o SGBD já sabe o
tamanho do campo ao “pular bytes” na busca sequencial. Entretanto,
se o conteúdo dos atributos não preencher todo o tamanho definido, há
o desperdício de espaço de armazenamento. Por outro lado, utilizando-se VARCHAR, o SGBD aloca um ponteiro para determinar qual o tamanho do atributo: as buscas são mais lentas, mas não há desperdício
de espaço.
Tipos booleanos
96
Assim como em linguagens de programação, tipos booleanos podem
assumir os valores TRUE ou FALSE. Muitos SGBDs mapeiam estes
valores em “1” e “0”, respectivamente.
BANCO DE DADOS | Educação a Distância
Tipos temporais
O tipo DATE suporta dados temporais no formato AAAA-MM-DD (ano,
mês, dia), enquanto que o tipo TIME utiliza o formato HH:MM:SS (hora,
minuto e segundo). A própria SQL assegura representações temporais
válidas.
RESTRIÇÕES
Seguindo o nosso planejamento, abordaremos agora as restrições que podem ser declaradas
em SQL no comando CREATE TABLE. Restrições adicionais especificadas em outros
comandos serão abordadas na próxima unidade.
Valores NULL e valores padrão
A linguagem SQL permite que todos os atributos (com exceção daqueles que compõem a
chave primária) sejam nulos. Se o seu modelo de negócios não permite que um atributo seja
nulo, é necessário especificar uma restrição de NOT NULL na declaração do atributo.
Uma outra consideração (pequena talvez) sobre o NOT NULL é que no mínimo 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, então o SGBD terá que primeiramente saber se o campo é nulo ou não,
e depois armazenar o próprio conteúdo.
Além de valores nulos, também há possibilidade de se definir um valor padrão para os atributos
utilizando-se a cláusula DEFAULT <valor>. Caso este atributo seja omitido durante a inserção
de uma linha da tabela, assume-se o valor padrão.
Por padrão na SQL, caso nenhuma cláusula seja declarada, os atributos permitirão valores
nulos e o valor padrão também será nulo.
Como exemplo, poderíamos definir ‘Silva’ como o sobrenome padrão dos nossos contatos no
comando CREATE TABLE:
BANCO DE DADOS | Educação a Distância
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 primária, utiliza-se a cláusula PRIMARY KEY. Caso a chave
primária possua um único atributo, ela pode ser declarada no próprio atributo (como no
exemplo da tabela contato):
id INT PRIMARY KEY
Havendo mais de um atributo na chave primária, é necessário declará-la ao final (como no
exemplo da tabela grupo):
PRIMARY KEY (grupo_fk, contato_fk)
A cláusula UNIQUE especifica chaves únicas (não primárias) numa tabela. Poderíamos alterar
a definição da tabela email para garantir que não haja e-mails duplicados em nossa aplicação:
CREATE TABLE email (
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL UNIQUE,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
Já a integridade referencial e as chaves estrangeiras são definidas por meio da cláusula
98
BANCO DE DADOS | Educação a Distância
FOREIGN KEY, como utilizada já no nosso exemplo nas tabelas email e telefone:
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,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
CONSULTAS BÁSICAS EM SQL
O comando em SQL para a execução de operações 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 <condições>.
De acordo com Silberschatz (1999), a expressão básica de consulta em SQL consiste de três
cláusulas: SELECT, FROM e WHERE:
1. A cláusula de SELECT é utilizada para listar os atributos desejados no resultado da
consulta.
2. A cláusula FROM lista as relações (tabelas) que devem ser examinadas na avaliação
da expressão SQL.
3. A cláusula WHERE corresponde ao predicado envolvendo os atributos das relações
que aparecem na cláusula FROM.
BANCO DE DADOS | Educação a Distância
99
As condições do comando SQL podem utilizar comparadores lógicos similares aos de outras
linguagens de programação 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 invés de
nos atermos aos detalhes sintáticos e conceituais de cada tipo de consulta, apresentaremos
exemplos de como realizá-las a seguir.
Todos os exemplos de consulta serão realizados tendo-se como base a definição 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 condição contato.sobrenome = ‘Silva’ é um predicado que seleciona
somente as linhas especificadas na tabela contato. A condição contato.id = telefone.contato_fk
é denominada de condição 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 várias tabelas
diferentes; e novamente neste caso, todas estão relacionadas por meio de uma condição de
combinação baseada em chaves estrangeiras.
100 BANCO DE DADOS | Educação a Distância
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 cláusulas quando há a
possibilidade de ambiguidade na definição 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 construção de consultas que possuem termos repetidos sendo referenciados
é a criação 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, não precisamos
mais nos referenciar a estes atributos pela referência completa, e torna-se possível então
simplesmente escrevermos a condição 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 definição de um alias não está restrita aos atributos; um
alias pode também ser definido como um apelido para uma tabela na consulta SQL.
BANCO DE DADOS | Educação a Distância
101
Exemplo 6: Selecione a data de nascimento de todos os contatos.
SELECT nascimento
FROM contato;
A cláusula WHERE de uma consulta SQL é opcional. Embora em muitos casos você, como
programador(a), deva se questionar se isto é oportuno ou não, já que potencialmente a
quantidade de registros numa tabela pode chegar aos milhões ou bilhões. Quando a cláusula
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 não 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 cláusula 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 não haja elementos repetidos, permite-se elementos repetidos em tabelas, e
consequentemente, nos resultados das consultas estes elementos repetidos são exibidos. Nas
situações em que se deseje eliminar as tuplas repetidas nos resultados das consultas, pode-se
utilizar a cláusula DISTINCT como no Exemplo 8.
102 BANCO DE DADOS | Educação a Distância
Exemplo 9: Selecione todos os telefones cujo número comece com ‘44’.
SELECT *
FROM telefone
WHERE telefone LIKE ‘44%’;
No Exemplo 9, utilizamos o comparador LIKE para definir uma busca por padrões em Strings.
O caractere ‘%’ é utilizado em condições 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 década de 1980.
SELECT *
FROM contato
WHERE nascimento LIKE ‘198_-__-__’;
Um outro caractere especial que pode ser utilizado em condições LIKE é o ‘_’. Ele representa
um único caractere arbitrário 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 condição BETWEEN da SQL pode ser utilizada para determinar intervalos de valor em
comparações.
BANCO DE DADOS | Educação a Distância
103
Exemplo 12: Selecione o nome de todos os contatos por ordem alfabética crescente.
SELECT nome
FROM contato
ORDER BY nome ASC;
A cláusula ORDER BY da SQL permite que o resultado da busca seja ordenado de acordo
com os parâmetros informados. Uma cláusula ORDER BY pode ordenar os resultados de
modo ascendente ou descendente. Para tanto, basta adicionar respectivamente o modificador
ASC ou DESC na cláusula. O valor ASC é o padrão 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
critérios diferentes. Os critérios são avaliados pela ordem em que são declarados.
COMANDOS DE MODIFICAÇÃO DE DADOS EM SQL
Até agora pudemos definir quais são os comandos básicos da SQL para a execução de
consultas básicas em nossos bancos de dados. Nesta seção abordaremos os comandos da
SQL que permitem a adição, atualização e remoção de tuplas (linhas), que respectivamente
correspondem ao INSERT, UPDATE e DELETE. Abordaremos cada um deles nas próximas
subseções.
104 BANCO DE DADOS | Educação a Distância
O comando INSERT
O comando INSERT é utilizado para inserir linhas numa determinada tabela. Devido à definição
formal do schema da tabela, precisamos informar os valores de inserção na tabela dentro de
uma ordem específica. Esta ordem pode ser a própria ordem determinada pela definição do
schema ou pode ser a ordem em que definimos os nomes das colunas da cláusula 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 cláusula VALUES seguem a mesma ordem
da definição do schema, como definido no início desta unidade. Note que durante a inserção
os valores informados devem satisfazer as condições de restrições de domínio, 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 nós especificamos explicitamente qual a ordem
desejada de inserção de cada um dos atributos da tabela contato.
Uma questão que surge para os desenvolvedores é: qual seria a forma mais adequada?
Certamente não 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
próprio comando INSERT, evita-se que este torne-se inválido quando o schema da tabela for
modificado para adição ou alteração de ordem de alguma coluna. O fato do comando tornar-se
inválido provavelmente provocaria um erro da aplicação em tempo de execução, já que este
tipo de bug não pode ser identificado pelo compilador.
BANCO DE DADOS | Educação a Distância
105
Uma terceira forma do comando INSERT permite que os valores informados para inserção
sejam determinados por uma cláusula SELECT ao invés de serem argumentos literais na
própria cláusula. 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 recém-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 cláusula WHERE determina quais são as linhas da tabela
selecionadas para modificação.
Em sua forma fundamental, um comando de modificação UPDATE assume a forma UPDATE
<tabela> SET <atributos e valores> WHERE <condições>.
Note que diferentemente do comando SELECT, um comando UPDATE só pode ser aplicado
numa única tabela. Caso seja necessário modificar os valores de atributos de mais de uma
tabela, vários comandos UPDATE terão que ser executados – todos possivelmente agrupados
dentro de uma única transação.
106 BANCO DE DADOS | Educação a Distância
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 prática bastante comum executarmos comandos UPDATE
no banco de dados somente identificando a chave primária na cláusula WHERE. Assim, temos
a garantia de que um único registro será modificado de cada vez (já que cada chave primária
é ú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 cláusula WHERE é opcional também no comando
UPDATE. Neste caso, todas as linhas da tabela informada serão selecionadas para a
execução das modificações solicitadas. No exemplo acima demonstramos que podemos
executar operações aritméticas com os valores dos atributos das tabelas. Neste exemplo,
atualizamos para 10% acima o peso de todos os contatos (no caso de uma hipotética epidemia
de obesidade).
UPDATE contato
SET nascimento = NULL;
O valor nulo também pode ser utilizado como valor de atribuição em comandos UPDATE,
desde que as restrições 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 restrições do schema que se aplicam ao comando INSERT também são válidas para o
comando UPDATE.
BANCO DE DADOS | Educação a Distância
107
O comando DELETE
O comando DELETE na SQL remove linhas de uma determinada tabela. Assim como os
comandos INSERT e UPDATE, possui uma cláusula WHERE para limitar as linhas que serão
processadas pelo comando. Novamente, assim como nos comandos INSERT e UPDATE, a
ausência da cláusula WHERE implica que todas as linhas de uma determinada tabela serão
processadas – o que no caso do comando DELETE implica que o resultado será uma tabela
vazia.
Em sua forma fundamental, um comando de modificação DELETE assume a forma DELETE
FROM <tabela> WHERE <condições>.
DELETE FROM telefone
WHERE id = 5;
O exemplo acima é a forma mais comum de execução 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
operações de DELETE, as restrições de integridade referencial são 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.
108 BANCO DE DADOS | Educação a Distância
SugestãodeVídeo:
<http://youtu.be/HJre77TPpSw>.
Cezar Taurion, da IBM, fala das vantagens da computação em nuvem.
10 coisas que você deve saber sobre banco de dados NoSQl
Por um quarto de século, os Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDRs) têm
sido o modelo dominante para gerenciamento de banco de dados. Mas hoje, não relacionais, “cloud”
ou bancos de dados “NoSQL” estão ganhando atenção como um modelo alternativo para gerenciamento de banco de dados. Neste artigo, abordaremos os 10 aspectos principais destes bancos de
dadosNoSQLnãorelacionais:ascincoprincipaisvantagenseoscincodesafios.
Cinco vantagens do NoSQl
1.Escalabilidadeelástica
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 invés da escalabilidade horizontal – distribuição dos bancos de dados em múltiplos servidores à medida que a carga aumenta.
Entretanto, à medida que os requisitos de carga de transações e disponibilidade aumentam, e os
banco de dados movem para a nuvem ou para ambientes virtualizados, as vantagens econômicas da
escalabilidade horizontal em hardware comoditizado tornam-se irresistíveis.
SGBDRs podem não escalar tão facilmente em clusters comoditizados, mas a nova geração de banco
de dados NoSQL é projetada para expandir-se transparentemente de modo a tirar proveito de novos
nós, e normalmente são concebidos com hardware de baixo custo em mente.
2. Big data
Assim como os níveis de transações cresceram absurdamente na última década, o volume de dados
BANCO DE DADOS | Educação a Distância
109
que está sendo armazenado também cresceu massivamente. O’Reilly chamou isto de “revolução industrial dos dados”. A capacidade dos SGBDRs tem crescido para se equiparar a estes aumentos,
mas assim como os níveis de transações, as restrições de volumes de dados que podem ser efetivamente gerenciados na prática por um único SGBDR tornaram-se intoleráveis 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 disponíveis.
3. Adeus DBAs (ou até logo?)
Apesar das muitas melhorias de gerenciamento alegadas pelos fornecedores de SGBDRs ao longo
dos anos, SGBDRs de alto nível só podem ser mantidos com a assistência de caros e altamente
treinados DBAs. DBAs estão intimamente envolvidos no projeto, instalação e otimização de sistemas
baseados em SGBDRs.
Bancos de dados NoSQL são normalmente concebidos para requerer menos gerenciamento: reparos
automáticos, distribuição de dados e modelos de dados mais simples tendem a requisitos de administração e otimização menores – na teoria. Na prática, é provável que os rumores da morte dos DBAs
tenham sido um pouco exagerado. Alguém sempre será responsável pelo desempenho e disponibilidade de um repositório de dados de missão crítica.
4. Economia
Bancos de dados NoSQL tipicamente utilizam clusters de servidores baratos para gerenciar a explosão
no volume de transações e dados, enquanto que SGBDRs tendem a depender de caros servidores e
dispositivos de armazenamento proprietários. O resultado é que o custo por gigabyte ou transações/
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 flexíveis
Gerência de mudança é uma grande dor de cabeça para grandes SGBDRs em produção. Cada pequena mudança no modelo de dados deve ser cuidadosamente gerenciada e pode necessitar de
downtime ou níveis de serviço reduzidos.
Bancos de dados NoSQL possuem restrições de modelos de dados muito mais flexíveis – ou inexistentes. Bancos de dados NoSQL do tipo chave-valor ou de documentos permitem que a aplicação
virtualmente armazene qualquer estrutura num elemento de dado. Mesmo um banco de dados NoSQL
definido de modo mais rígido como aqueles baseados em BigTable (Cassandra e HBase) tipicamente
permitem o acréscimo de novas colunas sem maiores problemas.
O resultado é que as mudanças na aplicação e as mudanças no schema do banco de dados não
precisam mais ser gerenciadas como uma única e complicada mudança. Na teoria, isto permite que
as aplicações possuam ciclos de iteração mais rápidos, embora claramente possa haver efeitos colaterais indesejáveis caso a aplicação falhe em gerenciar a integridade dos dados.
Cinco desafios do NoSQL
A promessa dos bancos de dados NoSQL gerou muito entusiasmo, mas ainda há obstáculos a serem
superados antes que eles possam seduzir grandes empresas mais conservadoras. A seguir listamos
alguns dos principais desafios.
110 BANCO DE DADOS | Educação a Distância
1. Maturidade
SGBDRs já estão por aí há um longo tempo. Defensores do NoSQL argumentarão que sua idade
avançada é um sinal de sua obsolescência, mas para a maioria dos CIOs, a maturidade dos SGBDRs
é reconfortante. Para a maioria, SGBDRs são estáveis e ricos em funcionalidades. Em comparação,
muitas alternativas NoSQL são versões de pré-produção em que muitas funcionalidades importantes
ainda devem ser implementadas.
2. Suporte
Empresas querem a garantia de que se um sistema chave falhar, terão um suporte competente com
um tempo de resposta aceitável. Todos os fornecedores de SGBDRs trabalham bastante para conseguirem fornecer um elevado nível de suporte corporativo.
Em contraste, muitos sistemas NoSQL são projetos open-source, e embora existam muitas empresas
oferecendo suporte a banco de dados NoSQL, estas empresas normalmente são 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 evoluíram para atender a demanda de escala de modernas aplicações Web
2.0. Consequentemente, a maioria de suas funcionalidades está relacionada às demandas destas
aplicações. Entretanto, os dados de uma aplicação têm um valor para o negócio que vai além do ciclo
de insert-read-update-delete de uma típica aplicação Web. Empresas mineram informações em banco
de dados corporativos para melhorar sua eficiência e competitividade, e business intelligence (BI) é
um ativo valioso de TI para todas as médias e grandes empresas.
Bancos de dados NoSQL oferecem poucas funcionalidades para consultas e análises ad-hoc. Mesmo
uma simples consulta exige um domínio significativo de programação, e muitas ferramentas de BI
populares não fornecem conectividade a NoSQL.
Algum alívio é trazido pelo surgimento de solução como HIVE e PIG, que podem fornecer um fácil
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. Administração
Os objetivos de projeto do NoSQL podem ser o de fornecer uma solução com custo zero de administração, mas a realidade atual ainda não é esta. O NoSQL hoje requer muita habilidade para instalar e
muito esforço de manutenção.
5. Expertise
Existem literalmente milhões de desenvolvedores no mundo todo, em praticamente todo segmento
de negócios, que estão familiarizados com os conceitos e programação em SGBDRs. Em contraste,
praticamente todo desenvolver NoSQL ainda está em processo de aprendizado. Esta situação será
resolvida naturalmente com o passar do tempo, mas por enquanto, é muito mais fácil encontrar programadores ou administradores SGBDR que um expert em NoSQL.
Conclusão
Bancos de dados NoSQL estão se tornando uma crescente e importante parte do cenário de banBANCO DE DADOS | Educação a Distância
111
co de dados, e quando utilizados de modo apropriado, podem oferecer benefícios reais. Entretanto,
empresas devem proceder com cautela com total consciência das limitações e problemas que estão
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 experiência em aplicações, administração de banco de
dados, tuning de desempenho e desenvolvimento de software. Guy é autor de vários livros e diversos
artigos em tecnologias de banco de dados e um palestrante regular em conferências técnicas.
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
e
especialista
em
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/?lang=pt_br>.
CONSiDErAçÕES FiNAiS
Finalizada a leitura desta unidade, já temos a convicção de que você, como profissional
comprometido(a) e fluente em inglês que é (sim, na área de Tecnologia da Informação
inglês é obrigatório e deveria ser o idioma principal), já abordará seus colegas, alunos(as)
e profissionais, falando “síquel” ao invés do famigerado “esse-quê-ele” quando se referir à
linguagem SQL.
Como toda tecnologia e assunto novo, SQL exige prática para o domínio. Este autor acredita
piamente na educação por meio de exemplos como a melhor forma de se formar profissionais
que consigam utilizar os conhecimentos assimilados na execução prática das tarefas. Durante
as seções desta unidade, pudemos estudar a formação dos comandos INSERT, UPDATE
e DELETE e suas respectivas sintaxes e cláusulas individuais. Em seguida, por meio de
exemplos, praticamos uma série de diferentes definições de comandos e explicamos o que se
esperava de cada um deles, bem como sua motivação. Crie seus próprios schemas baseado(a)
nas abstrações reais do mundo que o cerca. Exercite-se e execute consultas e comandos de
112 BANCO DE DADOS | Educação a Distância
modificação SQL nestes seus schemas. Com a prática cotidiana você perceberá que SQL
também é bastante simples.
Até agora fomos capazes de abordar as estruturas básicas da linguagem SQL. Na próxima
unidade, poderemos nos dedicar a alguns casos mais elaborados de uso desta popular
linguagem.
ATIVIDADE DE AUTOESTUDO
Todas as atividades de autoestudo desta unidade baseiam-se na Figura abaixo.
aluno
id
nome
sobrenome
ra
email
professor
id
nome
sobrenome
curso
id
titulação
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
definição e criação 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 titulação do professor da disciplina com nome = ‘SQL’.
BANCO DE DADOS | Educação a Distância
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 modificação de dados para incluir, modificar e remover linhas
das diferentes tabelas deste schema.
114 BANCO DE DADOS | Educação a Distância
UNIDADE V
MAIS SQL
Professor Me. Edson Yanaga
Objetivos de Aprendizagem
• Definir consultas complexas em SQL.
• Apresentar os comandos de alteração de definições em SQL.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
• Definição de consultas em SQL envolvendo NULL
• Descrição de consultas em SQL com subqueries
• Descrição de consultas em SQL com diferentes tipos de join
• Descrição de consultas em SQL com funções de agregação
• Descrição de comandos em SQL para alteração de schema
Fonte: SHUTTERSTOCK.COM
INTRODUÇÃO
Agora que já aprendemos a sintaxe básica dos comandos SQL, podemos nos aventurar
em consultas um pouco mais complexas. Em praticamente todos os sistemas de bancos de
dados disponíveis no mercado, sejam eles relacionais ou NoSQL, as funções de consulta e
manipulação básicas se equivalem. Isso significa que com o material estudado até a unidade
anterior, ainda não foi possível 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, não o fazemos com o
propósito de intimidá-lo(a). Muito pelo contrário. Aprendemos com a Teoria Geral dos Sistemas
que sempre que há um problema “complexo”, é possível dividi-lo em problemas menores até
que estes sejam de fácil resolução. É com esta definição em mente que apresentaremos nesta
unidade uma grande variedade de exemplos que podem ser solucionados com estas consultas
mais elaboradas da SQL.
BANCO DE DADOS | Educação a Distância
117
Nas próximas seções, abordaremos consultas envolvendo valores nulos, subqueries, consultas
com joins e consultas com funções de agregação; além dos comandos de alteração de schema.
CONSULTAS ENVOLVENDO NULL
Nós já abordamos na Unidade III que o valor NULL representa um valor ausente, mas que
pode ter diferentes interpretações. Algumas possibilidades de uso para o valor NULL são:
•
O valor é desconhecido. Pensando na tabela telefone do exemplo da Unidade IV, um
telefone pode ser NULL se você não sabe o valor do telefone do contato.
•
O valor não está disponível. No caso do telefone, você conhece o número do telefone
do contato, mas não gostaria que ele fosse exibido ou armazenado, setando o valor
NULL para representá-lo.
•
O valor não é aplicável. Caso algum contato não tenha telefone, certamente não faz
sentido armazenar esta informação.
A avaliação de comandos de consulta SQL com valores NULL merece uma atenção especial.
Todos os fundamentos de computação baseiam-se na lógica booleana, o que implica que as
expressões possuem sempre somente dois valores possíveis: verdadeiro (TRUE) ou falso
(FALSE).
Como em SQL os atributos podem ter valor nulo, agora as expressões 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 condições da cláusula
WHERE de comandos SQL filtram as linhas baseando-se no valor verdadeiro (TRUE) das
expressões. Nesse caso, linhas que sejam avaliadas pelas expressões da cláusula WHERE
como falso (FALSE) ou como o valor representado por NULL simplesmente são descartadas
(com exceção da operação de OUTER JOIN que veremos mais adiante nesta unidade).
118 BANCO DE DADOS | Educação a Distância
Comecemos com alguns exemplos ainda baseados no schema apresentado na Unidade IV.
Exemplo 1: Selecione todos os contatos que não possuem data de nascimento definida.
SELECT *
FROM contato
WHERE nascimento IS NULL;
Exemplo 2: Situação 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 são mais facilmente construídas se pudermos buscar
primeiramente alguns valores das tabelas e utilizá-los posteriormente em nossa consulta.
Estas consultas diferenciadas podem ser formuladas com uma certa conveniência 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.
BANCO DE DADOS | Educação a Distância
119
SELECT telefone
FROM telefone
WHERE contato_fk IN
(
SELECT id
FROM contato
WHERE sobrenome = ‘Machado’
);
Uma dúvida comum a muitos desenvolvedores está relacionada à frequência de uso de cada
opção. Matematicamente, de acordo com o modelo relacional, não há diferença entre as duas
consultas: são 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 questão de gosto, conveniência e legibilidade de código. Há alguns anos, poderia ser
argumentado que uma forma seria mais rápida que outra ou vice-versa. Entretanto, devido à
evolução dos interpretadores de SQL nos SGBDs modernos, esta diferença hoje é praticamente
nula: todos os SGBDs modificam internamente as consultas fornecidas e automaticamente já
escolhem o melhor plano de execução. Isto faz com que boa parte das supostas “otimizações”
que muitos DBAs realizam em consultas SQL tornem-se inócuas, pois o SGBD na maioria das
vezes reescreverá as consultas para a melhor forma possível2.
No exemplo acima, note o uso da cláusula IN (<subquery>). A cláusula IN espera um conjunto
de valores sendo retornado pela subquery dentro dos parênteses, que deve ser compatível
com o atributo sendo comparado pela cláusula IN. Na hipótese de você ter certeza da sua
subquery retornar um único valor ao invés de retornar um conjunto de valores, pode substituir
o IN pelo operador de igual (‘=’). Mas mesmo nas situações de um único valor sendo retornado
2
Justiça seja feita, em algumas situações (talvez 5% ou 10% dos casos), um bom conhecimento do funcionamento
do interpretador SQL do SGBD pode fazer diferença. Mas como já citou Knuth (1974, p.268), a “otimização prematura
é a raiz de todo o mal”. Primeiro implemente os casos de uso de seu software e depois, num eventual gargalo, otimize.
120 BANCO DE DADOS | Educação a Distância
o operador, IN continua equivalente. É por este motivo que muitos programadores acabam
adotando a convenção 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:
funcionário
id
nome
sobrenome
cargo
subordinado
id
nome
sobrenome
superior_fk
Figura 7
Fonte: o autor
O schema da Figura 7 pode ser construído da seguinte forma:
BANCO DE DADOS | Educação a Distância
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 funcionários 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:
SELECT f.nome, f.sobrenome
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
122 BANCO DE DADOS | Educação a Distância
SQL, pois como pode notar, a subquery utiliza atributos da consulta externa em sua cláusula
WHERE. Chamamos este caso especial de consultas aninhadas correlacionadas.
SELECT f.nome, f.sobrenome
FROM funcionario AS f
WHERE EXISTS (
SELECT *
FROM subordinado AS s
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 funcionários que não possuem
subordinados.
SELECT f.nome, f.sobrenome
FROM funcionario AS f
WHERE NOT EXISTS (
SELECT *
FROM subordinado AS s
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.
BANCO DE DADOS | Educação a Distância
123
CONSULTAS UTILIZANDO JOINS
Na Unidade IV nós vimos que o conceito de join permite que façamos consultas que
utilizam duas ou mais tabelas, unidas por meio de uma ou mais condições que unem
os elementos das duas ou mais tabelas. Em alguns casos, é mais fácil compreender as
consultas se estas forem escritas na forma com join ao invés de misturar as condições de
join na cláusula 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 cláusula FROM possui uma joined table que
contém todos os atributos de ambas as tabelas unidas pelo JOIN e pela condição do JOIN,
que é o predicado após o ON.
Na SQL o tipo de JOIN padrão quando simplesmente declarado pela cláusula JOIN é o inner
join, que descarta todas as tuplas que não possuam um valor correspondente na segunda
tabela do JOIN. Os outros tipos de JOIN disponíveis são descritos na tabela a seguir:
124 BANCO DE DADOS | Educação a Distância
Tipo de JOIN
Semântica
INNER JOIN
É o tipo de JOIN padrão. Somente
tuplas que satisfaçam a condição do
JOIN são selecionadas.
LEFT OUTER JOIN ou LEFT JOIN
Todas as tuplas da tabela do lado esquerdo do ON são selecionadas. Caso
não haja uma tupla correspondente na
tabela do lado direito do JOIN, os valores são preenchidos com NULL.
RIGHT OUTER JOIN ou RIGHT JOIN
É a condição inversa do LEFT JOIN.
Todas as tuplas da tabela do lado
direito do ON são selecionadas. Caso
não haja uma tupla correspondente na
tabela do lado esquerdo do JOIN, os
valores são preenchidos com NULL.
FULL OUTER JOIN ou FULL JOIN
Todas as tuplas dos dois lados do
JOIN são selecionadas. Caso não
haja correspondência na condição 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 não 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 típico de LEFT JOIN em que você deseja listar todos os contatos, tendo eles
telefone ou não.
BANCO DE DADOS | Educação a Distância
125
CONSULTAS COM FUNÇÕES DE AGREGAÇÃO
Uma das grandes vantagens da SQL e dos bancos de dados relacionais, se comparados
com outras alternativas não relacionais, são as suas funções de agregação. Estas funções
permitem uma análise resumida das informações armazenadas nas tabelas. Funções de
agregação populares da SQL incluem COUNT, SUM, MAX, MIN e AVG que executam as
funções matemáticas respectivas de contagem, soma, valor máximo, valor mínimo e média
aritmética.
Exemplo 8: Selecione o peso mínimo e máximo de todos os contatos.
SELECT MAX(peso), MIN(peso)
FROM contato;
As funções de agregação em SQL recebem como parâmetro o nome do atributo em que se
deseja aplicá-las. Neste exemplo, é o caso do atributo peso.
Exemplo 9: Selecione o número total de contatos cujo peso > 80;
SELECT COUNT(*)
FROM contato
WHERE peso > 80;
Neste uso da função COUNT, o asterisco (“*”) representa o número 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 cláusula
126 BANCO DE DADOS | Educação a Distância
DISTINCT não fosse aplicada, contaríamos somente a quantidade de pesos dos contatos.
Funções de agrupamento
Em muitas situações, desejamos aplicar as funções de agregação não 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 cláusula 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
condições 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 avaliação desta consulta, todas as tuplas da tabela contato são divididas em grupos cujo
sobrenome seja igual. Ao aplicarmos a função COUNT(*), ao invés dela contar todas as tuplas
da tabela, ela conta somente as tuplas de cada grupo. O resultado é uma lista que contém 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 situações, desejamos agrupar as tuplas em grupos, mas queremos selecionar
BANCO DE DADOS | Educação a Distância
127
apenas alguns destes grupos no resultado – e não todos. A cláusula que permite filtrar quais
grupos serão exibidos no resultado é a HAVING. Somente grupos que satisfaçam a condição
imposta pelo HAVING são selecionados no resultado.
É importante salientar a diferença entre as cláusulas WHERE e HAVING, pois
aparentemente ambas filtram os resultados da consulta. A cláusula WHERE filtra as tuplas
avaliadas primeiramente. Portanto, a cláusula WHERE é avaliada antes de qualquer função
de agregação ou qualquer agrupamento ser avaliado. Já a cláusula HAVING é avaliada
somente depois que os grupos já foram formados, e serve então para filtrar estes grupos
do resultado final.
COMANDOS DE ALTERAÇÃO DE SCHEMA
Nós definimos como schema evolution o processo de alterações da estrutura do schema.
Normalmente, estas alterações de estrutura não são frequentes e são motivadas por alterações
dos requisitos do negócio, e consequentemente também da aplicação.
Os comandos em SQL que podem alterar as definições de schema são os comandos para
adicionar, modificar e remover schemas, tabelas, atributos e restrições. 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 consequência, todas as tabelas dentro do schema. Há
uma certa controvérsia neste comando. Alguns SGBDs removem todas as tabelas do schema
ao remover o próprio schema. Outros só permitem a remoção do schema se ele não contiver
nenhuma tabela, sendo necessário remover todas as tabelas antecipadamente.
128 BANCO DE DADOS | Educação a Distância
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 dependências 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 à restrição de integridade referencial do banco,
sendo necessário 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 definição da tabela contato
com o tipo definido de VARCHAR(15). Quando um valor DEFAULT não é 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 padrão de ‘Senhor’.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15) DEFAULT ‘Senhor’;
O Exemplo 16 é a mesma situação do Exemplo 15, apenas definindo um valor padrão 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 definição da coluna apelido da tabela contato foi modificada e o seu tipo de dados agora
define a capacidade de 25 caracteres.
BANCO DE DADOS | Educação a Distância
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 não haja nenhuma restrição de
integridade referencial nesta coluna.
Exemplo 19: Supondo que ainda não 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 restrição de integridade referecial entre a tabela telefone e a tabela
contato.
Também é possível remover as restrições de integridade referencial por meio do comando
ALTER TABLE <tabela> DROP FOREIGN KEY <nome>, mas para tanto, é necessário saber
o nome da restrição no banco de dados. Como os comandos para exibição das restrições das
tabelas variam muito de um produto para outro, deixaremos esta solução como uma sugestão
de estudo para você.
<http://youtu.be/S2iQ2RKMw-w>.
Entrevista com Fernando de la Riva, sócio-diretor da Concrete Solutions, falando das perspectivas
para o mercado em 2012, incluindo Cloud Computing e NoSQL.
130 BANCO DE DADOS | Educação a Distância
NoSQL,semproblemas
Uma introdução a banco de dados NoSQL
Desvendar o NoSQL e tentar explicar o que é e por que você deveria se interessar ou não é uma tarefa
difícil. Este artigo tenta dar uma introdução de alto nível ao NoSQL e fornece uma comparação das
últimas tecnologias disponíveis desta área.
introdução
Desvendar o NoSQL e tentar explicar o que é e por que você deveria se interessar ou não é uma tarefa
difícil. 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 não utilize SQL, mas até agora a indústria parece ter estabelecido como “Not Only SQL”
(não somente SQL). À medida que o tempo passe, é provável que o termo cresça até o momento em
quepercaosentidoesubdivisõestornem-senecessáriasparaclarificarosignificadodotermo.
OqueéNoSQL?
O movimento NoSQL é um pedaço de um marketing de guerrilha que traz um grande grupo de tecnólogosetecnologiassobamesmabandeira.Asideiasquebaseiamainfinidadedesoluçãoqueexiste
sob o termo “NoSQL” antes estavam somente disponíveis para aqueles cujas necessidades tornaram
necessária uma implementação própria e específica. Nas áreas em que estas soluções são uma
necessidade, seu valor já foi provado, e agora o uso destas soluções passou a ser uma opção para
outros com um custo de investimento muito menor. Para qualquer organização que tenha que escolher
entre NoSQL e dados relacionais tradicionais, há a difícil questão de qual das duas utilizar. Ainda é
muitocedoparafornecerumarespostadecisivaedefinitiva,masestáclaroquemuitasorganizações
podemsebeneficiardeummodelodedadosqueseencaixemelhornostiposdearmazenamentoe
consulta que eles executam na prática do que na teoria. Também parece provável que a maioria das
soluções consistirá de um híbrido 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 estratégia.
Líderes técnicos têm um papel importante na compreensão das opções disponíveis e na adaptação do
software, produtos e serviços que mais se aplicam ao seu domínio de negócios. Possuir uma estratégia lógica e localizada para a adoção do que o NoSQL oferece de melhor será o fator que diferenciará
BANCO DE DADOS | Educação a Distância
131
o sucesso do fracasso em sua adoção.
Assim como o NoSQL apresenta novos desafios, ele também oferece recompensas significativas
àqueles que o incorporam com sucesso no seu portfolio de solução. Os principais benefícios virão
da maior compreensão sobre os dados, escalonamento flexível e produtividade. A rica variedade de
novos modelos de negócios possuem requisitos de armazenamento que são suportados pelo NoSQL
e as décadas de coerção de dados em modelos relacionais ficaram para trás.
NoSQL é uma área grande e em expansão. Para os propósitos deste artigo, as características mais
comuns de banco de dados NoSQL são:
1. Facilidade de uso em clusters com balanceamento de carga tradicionais;
2. Dados persistentes (não somente cachês);
3. Escalabilidade na memória disponível;
4. Não possuem schemas fixos e permitem a migração de schemas sem indisponibilidade;
5. Possui sistemas de consulta individuais ao invés de uma linguagem de consulta padrão;
6. São 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 características.
O que está acontecendo agora?
Movimentos em tecnologia ou em correntes de pensamento raramente acontecem de modo totalmente espontâneo. Existem três principais motivações por trás do elevado interesse em NoSQL. Primeiro
foi o surgimento de uma nova forma de perfil de tráfego 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 crítico para muitos negócios na Web nos últimos cinco anos. À medida
que o mundo torna-se mais conectado, é possível que sites recebam variações enormes de tráfego.
Algumas destas estão relacionadas a eventos previsíveis: a Copa do Mundo ou o Natal; outros são
imprevisíveis e globais, como por exemplo, o 11 de Setembro. Sites como o Facebook tornaram fácil a
escalada de popularidade de sites à medida que itens tornam-se virais e são distribuídos pelo mundo
todo.
Conteúdos criados pelo usuário causam dores de cabeça particulares, pois os problemas relacionados a websites com “leitura intensiva” já são solucionados com a utilização de conteúdo estático e
CDNs (Content Distribution Networks – Redes de Distribuição de Conteúdo). Conteúdos criados pelo
usuário significam que os sites tornam-se mais equilibrados no quesito “leitura-escrita”. Sites como
o Twitter recebem montanhas de tráfego em intervalos muito curtos de tempo (um gol validado ou
invalidado, a apuração de uma votação ou o final de um seriado ou novela de TV), e sua infraestrutura
deve se adaptar rapidamente para não ficar indisponível na hora errada. A abordagem normal para
132 BANCO DE DADOS | Educação a Distância
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 então
é comprar progressivamente um hardware cada vez mais poderoso até que o banco de dados possa
servir todo o tráfego. 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 impossível comprar o hardware e as licenças de software para atender a demanda de pico através de
um único servidor. Estes empreendimentos têm procurado uma solução de dados escalável que possa
espelhar a estrutura da própria Web.
A segunda motivação é o fato de que os dados mudam com o passar do tempo. Com a evolução do
modelo de negócios, os modelos de dados normalmente contorcem-se para evoluir e manter o ritmo
das mudanças. 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 “armazém” devido a um erro anterior, sabe que o peso do histórico no modelo de
dados pode ser um sério entrave na manutenção do sistema e na incorporação de novas ideias de
negócios.
A motivação final é que a tecnologia de NoSQL está começando a se tornar um commodity. Amazon
e Google não tiveram escolha no passado a não ser desenvolver sua própria solução para resolver
os problemas de escala. O custo de escrever tal solução impediu muitas empresas que não tinham
estes problemas no coração de seus negócios de explorar esta nova tecnologia. Recentemente uma
série de doações de código 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 código extremamente sofisticado com um baixo custo de manutenção. Tais código colocam
o NoSQL firmemente ao alcance de empresas menores. Ao invés de ser um assunto esotérico, agora
os bancos de dados NoSQL podem ser baixados e integrados à arquitetura corporativa em questão
de semanas.
Está sendo realmente utilizado?
Uma questão 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 serviços da Amazon, Yahoo
ou Google então você teve os dados fornecidos através de uma solução 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 não utiliza transações e o Twitter
utiliza um banco de dados de grafos para saber quem segue quem).
Normalmente a questão realmente significa se pessoas como eu estão realmente utilizando NoSQL.
BANCO DE DADOS | Educação a Distância
133
A resposta é que se você está enfrentando problemas lidando com certos tipos de dados, então há
um diferencial competitivo em potencial ao se avaliar uma solução NoSQL. A área é nova o suficiente
para que muitos negócios sintam-se desconfortáveis executando trabalho crítico em qualquer outro
software que não seja um maduro banco de dados relacional, mesmo que estes bancos de dados
relacionais causem vários problemas e tenham suas diversas limitações.
Por que você utilizaria um banco de dados NoSQL?
Uma das principais motivações é se você tiver problemas em seu negócio que são difíceis 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,
então há pouca necessidade de se alterar seu mecanismo de armazenamento de dados.
A seguir estão alguns casos de uso em que é subótimo utilizar um banco de dados relacional:
•
Seu banco de dados relacional não escalará seu tráfego a um custo aceitável;
•
Seus dados são fornecidos em pequenas mudanças ao longo do tempo, de modo que o número de tabelas necessárias para manter a forma normal cresceu desproporcionalmente em
relação aos dados sendo mantidos. Informalmente, se você não consegue mais imprimir o seu
DER num papel A3, você deve ter alcançado este problema ou você está armazenando muita
coisa num único banco de dados;
•
Seu modelo de negócios gera muitos dados temporários que não pertencem ao banco de
dados principal. Exemplos comuns incluem carrinhos de compras, critérios de pesquisa salvos,
personalização do site e questionários de usuário incompletos;
•
Seu banco de dados relacional está denormalizado por motivos de desempenho ou por conveniência ao manipular dados na aplicação;
•
Seus conjuntos de dados consistem em grandes quantidades de texto ou imagens e as definições de coluna são simples LOBs (CLOB ou BLOB);
•
Você tem que executar consultas em seus dados que não envolvem simples relações hierárquicas; exemplos comuns são questões de recomendações ou de business intelligence que
envolvem a ausência de dados;
•
Você possui transações de dados que não precisam de muita durabilidade. Por exemplo, o
“curtir” de itens em websites: criar transações para este tipo de interação são um exagero, pois
se a ação falhar o usuário provavelmente irá repetir a ação 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 padrão muitas
134 BANCO DE DADOS | Educação a Distância
vezes deturpado por implementações customizadas. A SQL possui muitas vantagens que os produtos
NoSQL terão que tratar ao longo do tempo. Primeiramente, ela é madura, refinada e geralmente atende às expectativas dos usuários. Possui uma sintaxe coerente e rica em funcionalidades, o que significa que pessoas que produzem consultas SQL complexas certamente reclamarão 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 não forem capazes de encontrar um
conjunto comum de operações de manipulação de dados, então é provável que uma outra implementação torne-se popular e seus usuários migrarão para este outro produto. Ou todos os fornecedores
terão que implementar o mesmo conjunto de comandos do líder de mercado para manterem-se competitivos.
Já há alguns padrões disponíveis como a SparQL, um padrão 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 não há nada que forneça 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 terão
que implementar algo muito similiar à SQL se quiserem ter o mesmo nível de utilização que os produtos de dados relacionais têm hoje. Em alguns casos este fato se esconde por trás 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 fácil se a sua aplicação possui um baixo acoplamento entre os componentes. Nesta situação é
mais fácil identificar áreas que se beneficiariam da solução NoSQL e implementar esta integração aos
poucos. Na situação em que o armazenamento de dados é monolítico e que os sistemas dependem
de certas propriedades do modelo relacional – por exemplo, tipos de dados ou consistência transacional – então o problema é muito mais difícil. Em alguns casos o desacoplamento dos dados é a primeira
tarefa a ser executada ao invés da migração do armazenamento dos dados.
Do ponto de vista da solução, há a necessidade de se analisar claramente quais dados são relacionais
e quais dados estão armazenados em bancos de dados relacionais por falta de outra alternativa. Também é importante revisar decisões históricas e verificar se estas foram feitas com restrições históricas
em mente. Um exemplo particular é o uso de bancos de dados de grafos ao invés de uma estrutura
complexa de tabelas relacionais. É perfeitamente possível criar conjuntos de relacionamentos N-N em
dados relacionais e então consultar as intersecções destes relacionamentos, mas expressar somente
os relacionamentos num banco de dados de grafos é uma solução muito mais simples.
Existem algumas áreas óbvias em que o NoSQL pode ser aplicado imediatamente. Conteúdo de
websistes pode ser geralmente expresso em bancos de dados de documentos ou de chave-valor.
BANCO DE DADOS | Educação a Distância
135
Exemplos particulares destas situações são as metáforas de formulários e de wizards de formulários.
Qualquer formulário pode ser expresso diretamente na forma de um documento. Dados de buscas são
outro exemplo, pois muitos dados de referência consistem em mapas, listas e conjuntos, referências,
países, estados, cidades etc. Analisando estes padrões nos dados, devem surgir novas oportunidades
de uso do NoSQL.
Analisando de um modo mais estratégico, sistemas que precisam evoluir e mudar seus dados com
frequência possuem uma boa chance de utilizar um banco de dados sem schema. Se a migração de
estruturas de dados sem indisponibilidade for um diferencial competitivo, então este é um forte indicador de que o uso de uma solução NoSQL seria valioso.
Tipos de bancos de dados NoSQL
As próximas seções descrevem os diferentes tipos de bancos de dados NoSQL.
Bancos de dados chave-valor
Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort e Oracle BDB.
Aplicações Típicas: Cachê de conteúdo.
Pontos Fortes: Acesso rápido.
Pontos Fracos: Os dados armazenados não têm schema.
Aplicação de exemplo: Você está escrevendo um software de fórum em que a página do perfil fornece
as estatísticas do usuário (mensagens postadas etc.) e as últimas dez mensagens escritas por ele. A
página lê estes dados baseada numa chave que é o id do usuário e recupera uma String JSON que
representa todas estas informações. Um processo em background recalcula esta informação a cada
15 minutos e grava no banco de dados de modo independente.
Banco de dados de documentos
Exemplos: CouchDB e MongoDB.
Aplicações Típicas: Aplicações Web.
Pontos Fortes: Tolerância com dados incompletos.
Pontos Fracos: Desempenho em consultas, não há uma sintaxe de consulta padrão.
Aplicação de exemplo: Você está criando um software que cria perfis de crianças refugiadas com o
propósito de reuni-las novamente com suas famílias. Os detalhes que você precisa gravar de cada
criança podem variar muito de acordo com as circunstâncias do evento e elas são construídas aos
poucos. Por exemplo, uma criança pequena pode saber o seu primeiro nome e você pode tirar uma
foto dela, mas pode não saber os nomes de seus pais. Mais tarde um conhecido pode reconhecer a
criança e fornecer informações adicionais que você pode querer gravar, mas até conseguir confirmar,
você terá que tratar estas informações com ceticismo.
136 BANCO DE DADOS | Educação a Distância
Banco de dados de grafos
Exemplos: Neo4J, InfoGrid e Infinite Graph.
Aplicações Típicas: 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. Não é simples de
clusterizar.
Aplicação de exemplo: Qualquer aplicação que requeira conectividade social é uma candidata a um
banco de dados de grafos. Este mesmo princípio pode ser estendido a qualquer aplicação em que
você precisa saber o que as pessoas estão fazendo, comprando ou curtindo de modo a recomendar
ações futuras. Em qualquer momento você pode responder a questões como “Quais restaurantes
receberam votos negativos das irmãs de pessoas com mais de 40 que gostam de esquiar e que
visitaram o Quênia?”.
Bancos de dados de XML
Exemplos: Exist, Oracle, MarkLogic.
Aplicações Típicas: Publicação.
Pontos Fortes: Tecnologias de busca maduras e validação de schema XML.
Pontos Fracos: Não é uma solução binária pura, é mais fácil reescrever um documento do que atualizá-lo.
Aplicação de exemplo: Uma editora que utiliza formatos XML para produzir versões web, impressa e
eBook de seus artigos. Os editores precisam fazer buscas rápidas tanto no texto quanto em seções
semânticas do XML. Eles armazenam o XML dos artigos finalizados no banco de dados XML e os encapsulam em web services para os sistemas de produção de documentos. Quando mudanças são necessárias, atualizações utilizando XQuery modificam todos os documentos XML para o novo formato.
Bancos de dados ponto-a-ponto distribuídos
Exemplos: Cassandra, HBase e Riak.
Aplicações Típicas: Sistemas de arquivo distribuídos.
Pontos Fortes: Buscas rápidas e boa distribuição do armazenamento dos dados.
Pontos Fracos: API de baixo nível.
Aplicação de exemplo: Você possui um site de notícias em que qualquer tipo de conteúdo (artigos,
comentários, perfis de autores etc.) pode ser votado e pode ter um comentário opcional no voto. Você
pode criar uma base por usuário e uma base por tipo de conteúdo utilizando um UUID como chave
BANCO DE DADOS | Educação a Distância
137
(gerado a partir de cada tipo de conteúdo e usuário). O “bucket” do usuário mantém cada voto dele,
enquanto que o “bucket” do conteúdo contém uma cópia de cada voto que já foi feito para aquele
conteúdo.Duranteanoite,umprocessobatchidentificaemquaisconteúdososusuáriosvotarame
você gera uma lista de conteúdo que possui muitos votos para cada usuário, mas que os usuários
aindanãovotaram.Estalistaéumalistadeartigosrecomendadosparaousuárioeficaarmazenada
no “bucket” de recomendações.
Banco de dados de objetos
Exemplos: Oracle Coherence, db4o, ObjectStore, GemStone e Polar.
AplicaçõesTípicas:Sistemasfinanceiros.
PontosFortes:Refleteoparadigmadedesenvolvimentoorientadoaobjetos,baixalatênciaACIDe
tecnologia madura.
Pontos Fracos: Consultas limitadas ou operações de múltiplas atualizações.
Aplicação de exemplo: Uma empresa de comércio internacional quer fazer transações a partir do
JapãoeNovaYorkeverificá-lasatravésdeumprocessodeanálisederiscoemLondres.Umobjeto
representando a transação é gravado no banco de dados de objetos e o analisador de riscos está
aguardandopelasnotificaçõesdeobjetosdetransações.Quandoumobjetoéreplicadonodatacenter
europeu,oanalisadorderiscoslêatransaçãoeverificaoriscodamesma.Eleentãoreescreveo
objeto para informar que a transação foi autorizada e gera uma venda. O cliente está aguardando por
mudançasnosobjetoserecebeumanotificaçãodequeasuatransaçãofoiaprovada.
Conclusão
Dados tabulares permanecem tabulares e a planilha de cálculo ainda é a ferramenta de modelagem
de dados favorita no mundo dos negócios. SQL não vai morrer tão cedo. Entretanto, até agora nós
temos criado sistemas baseados nas restrições de um típico 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.
CONSiDErAçÕES FiNAiS
Finalmente chegamos ao fim de nossa última unidade deste material. Neste ponto, você
138 BANCO DE DADOS | Educação a Distância
provavelmente já terá assimilado conteúdo suficiente para poder já desenvolver algumas
aplicações utilizando sistemas de bancos de dados.
Como descrevemos no início da unidade, é bastante provável 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 fácil solução. Utilize esta técnica e aplique os
conceitos assimilados com os exemplos apresentados nesta unidade para resolvê-los. Teoria
é importantíssima, mas a prática é uma atividade fundamental para que você possa converter
toda esta teoria aprendida em resultados – tanto pessoais quanto profissionais.
A prática das atividades de autoestudo pode auxiliá-lo(a) na trabalhosa tarefa de assimilação
dos conceitos apresentados nesta unidade. Analise-as com carinho e tenha um bom proveito.
ATIVIDADE DE AUTOESTUDO
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
definição e criação das tabelas.
2. Elabore consultas SQL para:
a. Selecione todos os beneficiários que possuem dependentes com o mesmo nome
utilizando uma condição de JOIN.
BANCO DE DADOS | Educação a Distância
139
b. Execute a mesma consulta anterior utilizando uma subquery.
c. Execute a mesma consulta anterior utilizando uma cláusula EXISTS.
d. Selecione o beneficiário que contém dependente que possui a maior altura entre
todos.
3. Utilizando a cláusula de GROUP BY, elabore consultas para:
a. Agrupe os beneficiários por nome e selecione o sobrenome e altura de cada um deles.
b. Selecione todos os beneficiários que contêm mais de um dependente com o mesmo
sobrenome.
c. Selecione todos os planos que contêm mais de um beneficiário com altura > 1.75.
140 BANCO DE DADOS | Educação a Distância
CONCLUSÃO
Se há uma palavra que possa descrever meu sentimento ao concluir este livro, esta talvez
seja “alívio”. Sim, entre outras emoções que certamente passam pela minha cabeça neste
momento, o alívio 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 esforço é lido sem prazer”.
Não posso me assegurar que você, caríssimo(a) leitor(a), conseguirá ler este material com
o prazer que eu gostaria que lhe proporcionasse – mas não duvide, certamente as palavras
organizadas neste material foram fruto de um enorme esforço. E não somente de esforço:
também de dor, privação de certas liberdades que me foram tomadas pelo tempo dedicado,
desespero por querer mais tempo para poder esculpir melhor alguns parágrafos e a angústia
de saber que na verdade o trabalho nunca termina – ele apenas possui uma data de término.
Tivesse mais seis meses ou um ano, certamente não o terminaria antes do prazo final. Mas
assim o é também em tudo aquilo que nos dedicamos.
Antoine de Saint-Exupéry escreveu que “tu te tornas eternamente responsável por aquilo que
cativas”. Espero que eu possa ter cativado algo com este material e talvez alguém, pois esforço
não faltou na elaboração do mesmo.
Certamente durante a leitura de alguns pontos do material, você pôde perceber a grande
inspiração que tenho ao falar de desenvolvimento de software. Sou partidário da corrente que
acredita que o mais importante de todo e qualquer software é o problema que ele resolve e o
quão satisfatório ele é para seus usuários. Considero a utilidade do software como mecanismo
fundamental para qualquer inovação do conhecimento humano atual. E não 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 próprio 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 inovação que o software pode proporcionar.
Ao término deste material você provavelmente já terá todas as habilidades necessárias para
integrar um sistema de banco de dados relacional ao software que você desenvolve. Saberá
escolher as opções do mercado baseado(a) nos critérios de classificação que apresentamos
BANCO DE DADOS | Educação a Distância
141
– e terá com certeza uma pontinha de dúvida se deve mesmo utilizar um banco de dados
relacional. Afinal, as leituras complementares, os vídeos e os estudos de caso apresentados no
material tinham como objetivo provocar o senso crítico para libertá-lo(a) da “prisão 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 aplicação, ao invés
de tomar decisões baseadas em medo, incerteza e dúvida.
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 graças
aos conhecimentos de SQL adquiridos. A lista deste material certamente não é exaustiva, mas
é também um bom começo. Afinal, a jornada do conhecimento nunca acaba.
Baseado(a) em tudo o que você pode aprender, aproveite bem e utilize todo o conteúdo que
tentamos transmitir para desenvolver um bom software; software inovador. É isto o que eu
sinceramente desejo para sua frutífera jornada. E que está apenas começando... Bom proveito,
boa sorte e acima de tudo, muito sucesso.
Um grande abraço.
Edson Yanaga.
142 BANCO DE DADOS | Educação a Distância
REFERÊNCIAS
DATE, C. J. Bancos de dados: tópicos avançados. 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. São Paulo: Makron Books do Brasil, 1999.
BANCO DE DADOS | Educação a Distância
143