Banco de Dados

BANCO DE
DADOS
Professor Me. Edson Yanaga

Professor Esp. Victor de Marqui Pedroso
GRADUAÇÃO
Unicesumar
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor Executivo de EAD
William Victor Kendrick de Matos Silva
Pró-Reitor de Ensino de EAD
Janes Fidélis Tomelin
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância

Diretoria Executiva
Chrystiano Mincoff
James Prestes
Tiago Stachon
Diretoria de Design Educacional
Débora Leite
Diretoria de Graduação e Pós-graduação
Kátia Coelho
Diretoria de Permanência
Leonardo Spaine
Head de Produção de Conteúdos
Celso Luiz Braga de Souza Filho
Gerência de Produção de Conteúdo
Diogo Ribeiro Garcia
Gerência de Projetos Especiais
Daniel Fuverki Hey
Supervisão do Núcleo de Produção
de Materiais
Nádila Toledo
Supervisão Operacional de Ensino
Luiz Arthur Sanglard
Coordenador de Conteúdo
Danillo Xavier Saes
Design Educacional
Paulo Victor Souza e Silva
Projeto Gráfico
Jaime de Marchi Junior
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a José Jhonny Coelho
Distância; YANAGA, Edson; PEDROSO, Victor de Marqui.
Arte Capa
Banco de Dados. Edson Yanaga; Victor de Marqui Arthur Cantareli Silva
Reimpressão - 2018
Editoração
Maringá-Pr.: UniCesumar, 2016.
178 p. Melina Belusse Ramos
“Graduação - EaD”. Revisão Textual
Keren Pardini
1. Banco. 2. Dados . 3. EaD. I. Título.
ISBN 978-85-459-0100-6
Yara Martins Dias
CDD - 22 ed. 005 Simone Morais Limonta
CIP - NBR 12899 - AACR/2 Ilustração
André Luis Onishi
Ficha catalográfica elaborada pelo bibliotecário

João Vivaldo de Souza - CRB-8 - 6828
Impresso por:
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 so-
luçã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 responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar
assume o compromisso de democratizar o conhe-
cimento 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 Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-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 Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitá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; con-
solidaçã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 administrati-
va; compromisso social de inclusão; processos de
cooperação e parceria com o mundo do trabalho,
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está
iniciando um processo de transformação, pois quan-
do investimos em nossa formação, seja ela pessoal
ou profissional, nos transformamos e, consequente-
Pró-Reitor de
Ensino de EAD
mente, transformamos também a sociedade na qual
estamos inseridos. De que forma o fazemos? Criando
oportunidades e/ou estabelecendo mudanças capa-
zes de alcançar um nível de desenvolvimento compa-
tível com os desafios que surgem no mundo contem-
porâneo.
O Centro Universitário Cesumar mediante o Núcleo de
Diretoria de Graduação
e Pós-graduação Educação a Distância, o(a) acompanhará durante todo
este processo, pois conforme Freire (1996): “Os homens
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialó-
gica e encontram-se integrados à proposta pedagó-
gica, contribuindo no processo educacional, comple-
mentando sua formação profissional, desenvolvendo
competências e habilidades, e aplicando conceitos
teóricos em situação de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais
têm como principal objetivo “provocar uma aproxi-
mação entre você e o conteúdo”, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos
conhecimentos necessários para a sua formação pes-
soal e profissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser
apenas geográfica. Utilize os diversos recursos peda-
gógicos que o Centro Universitário Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA – Ambiente
Virtual de Aprendizagem, interaja nos fóruns e en-
quetes, assista às aulas ao vivo e participe das discus-
sões. Além disso, lembre-se que existe uma equipe de
professores e tutores que se encontra disponível para
sanar suas dúvidas e auxiliá-lo(a) em seu processo de
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
AUTORES

Possui graduação em Ciência da Computação pela Universidade Estadual de
Maringá (1999) e mestrado em Engenharia Elétrica e Informática Industrial
pela Universidade Tecnológica Federal do Paraná (2002). Tem experiência
na área de Ciência da Computação, com ênfase em Engenharia de Software,
atuando, principalmente, nos seguintes temas: processos, métricas, modelos,
produtos e ip.

Possui Pós-Graduação em Banco de dados Oracle e DB2 pelo Centro
Universitário de Maringá (2009), Graduação em Tecnologia em Processamento
de Dados pelo Centro Universitário de Maringá (2003). Também atua como
analista de sistemas, analista de suporte, documentador, homologador
e programador de software. Possui experiência em desenvolvimento,
utilizando a ferramenta Delphi com bancos de dados relacionais. Trabalhou
como Professor Mediador e atualmente trabalha como Professor Formador
dos cursos de Análise e Desenvolvimento de Sistemas e Sistemas para
Internet, ministrando as disciplinas de Banco de Dados e Design de Interação.
APRESENTAÇÃO
BANCO DE DADOS
SEJA BEM-VINDO(A)!
Salve, caríssimo(a) leitor(a)! Temos o enorme prazer em apresentar-lhe o livro de Banco
de Dados I, elaborado especificamente para contribuir com sua formação, como futu-
ro(a) desenvolvedor(a) de software. Esperamos que você tenha um bom proveito do
material.
Confessamos que foi um tremendo desafio escrever este material. Até certo ponto, é
uma repetição cansativa dizer que o ritmo das mudanças e das 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 de 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 informação atuais exigem que manipulemos não gigabytes
ou terabytes de informações, e sim petabytes, exabytes e zetabytes.
Os sistemas de informação das gerações anteriores tinham como objetivo gerar infor-
maçõ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 magnitu-
de dessas informações geradas cresceu. Redes sociais, smartphones, tablets, sensores
de automação e vários outros dispositivos geram inúmeros bits de informação em todo
momento. Conceitos antigos já não são soberanos nesses inóspitos ambientes atuais.
Diante desses cenários, surgiram os conceitos de Big Data e NoSQL.
Mas, para irmos mais longe e chegarmos a esse 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), esses 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 intera-
gem 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 tra-
dicionais 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: apresen-
tar-lhe sempre os conceitos de vanguarda que já são aplicados em muitos casos de uso
em aplicações modernas.
A unidade II apresentará a terminologia e outros conceitos básicos que serão utiliza-
dos no restante deste material, descrevendo o modelo relacional de banco de dados
propriamente dito que será abordado na unidade V. A partir desse ponto, você estará
apto(a) a identificar as características de modelos relacionais e passar a construir seus
próprios modelos de dados baseado(a) nos fundamentos apresentados. Na modelagem
APRESENTAÇÃO
relacional, você identificará entidades do seu domínio de negócios, suas restrições

e os relacionamentos entre as diversas entidades modeladas.
Nas unidades III e IV, 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, acreditamos que
não será um problema para você, futuro(a) desenvolvedor(a) de software. Mas con-
vém ressaltar que SQL possui uma natureza declarativa, que é diferente das lingua-
gens imperativas, como Java, C ou Pascal. 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ân-
cias de dados. Na unidade V, você terá um estudo de caso completo que o(a) ajudará
na compreensão de todo o conteúdo estudado.
E, antes que você possa apreciar o conteúdo do material, permita-nos apresentar
nosso 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 impres-
sões transmitidas, até certo ponto, em grande quantidade. Para nós 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 pro-
cesso de negócios da empresa. Isso diminui sua importância? Certamente que não!
Porém, quando você 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

Prof. Esp. Victor de Marqui Pedroso
09
SUMÁRIO
UNIDADE I
CONCEITOS DE BANCOS
DE DADOS
15 Introdução
21 Características de Sistemas de Bancos de Dados
27 Transações
31 Vantagens de se Utilizar um SGBD
38 Considerações Finais
UNIDADE II
MODELO RELACIONAL
43 Introdução
44 O Modelo Relacional
46 Introdução à Modelagem
51 Atributos
52 Tipos de Atributos
56 Domínio
57 Chave Estrangeira (Foreign Key)
58 Relacionamentos
61 Cardinalidade
SUMÁRIO
UNIDADE III
SQL BÁSICO
71 Introdução
73 Definições de Dados e Tipos em SQL
77 Restrições
79 Consultas Básicas em SQL
85 Comandos de Modificação de Dados em SQL
UNIDADE IV
MAIS SQL
99 Introdução
100 Consultas Envolvendo NULL
101 Consultas Aninhadas (Subqueries)
105 Consultas Utilizando Joins
110 Comandos de Alteração de Schema

11
SUMÁRIO
UNIDADE V
ESTUDO DE CASO
127 Introdução
132 Descrevendo o Estudo de Caso
133 Criando as Entidades e os Relacionamentos (DER)
141 Trabalhando com SQL
167 Conclusão
169 Referências
171 Gabarito
CONCEITOS DE BANCOS
I
UNIDADE
DE DADOS
Objetivos de Aprendizagem
■■ Apresentar os conceitos fundamentais envolvendo dados e bancos
de dados em sistemas computacionais.
■■ Descrever as formas de interação dos usuários com os bancos de
dados.
■■ Comparar as vantagens dessa abordagem em relação a outras
similares.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
■■ Características de Sistemas de Bancos de Dados
■■ Transações
■■ Vantagens de se utilizar um SGBD
15
INTRODUÇÃO
“Scientia potentia est”: “Conhecimento é poder”.
Sim, caro(a) leitor(a), conhecimento é poder. Informação é poder. Na sociedade

do século XXI, temos informação em abundância e chamamos as informações
armazenadas em sistemas computacionais de dados. O desafio crescente dos pró-
ximos anos é encontrar formas eficientes de processar os dados que já temos e
Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
ainda criar para gerar conhecimento e, consequentemente, riqueza.

Nas últimas décadas, boa parte do software desenvolvido envolve mais do
que 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 armaze-
nadas em um mecanismo confiável e que possibilite o acesso simples e rápido à
leitura e escrita dessas 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 abso-
lutamente 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 o armazenamento de informações em bancos de dados.
Mas de onde vem esse termo, que conhecemos como “banco de dados”?
Pois, em inglês, o termo refere-se a databases, que em uma tradução literal defi-
niríamos como “base de dados”. Um bom palpite quanto a isso, 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 à dife-
rença entre os termos “banco de dados” e os sistemas que o gerenciam. Segue
uma definição, segundo Navathe (2011, p. 3):
Introdução
16 UNIDADE I
Um banco de dados é uma coleção de dados relacionados. Os dados

são fatos que podem ser gravados e que possuem um significado im-
plí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 são uma coleção de dados com um significado implícito, conse-
quentemente, 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 relaciona-
das 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 essas 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) é uma coleção
de programas que permite aos usuários criar e manter um banco de
dados. O SGBD é, portanto, um sistema de software de propósito geral
que facilita os processos de definição, construção, manipulação e com-
partilhamento de bancos de dados entre vários usuários e aplicações. A
definição de um banco de dados implica especificar os tipos de dados,
as estruturas e as restriçõ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 con-
ceito, 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 lembrando que nossas aplicações
não geram valor, somente custo. É por esse motivo que atualmente definimos
os SGBDs em uma categoria de software que consideramos como commodity.
CONCEITOS DE BANCOS DE DADOS

17
Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem

Oracle, DB2, SQL Server, Access, PostgreSQL, MySQL, Derby e H2. Já exem-
plos 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 for-
mado pelo banco de dados e o sistema que o gerencia, o SGBD, de Sistema de
Banco de Dados.
Introdução
BANCOS DE DADOS OPEN SOURCE: PRESENTE OU FUTURO?
Cezar Taurion
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de da-
dos Open Source. Bem, tenho minha opinião pessoal e quero compartilhar com você.
Vamos ver se vai gerar muita discordância.
Os softwares de banco de dados são um dos mais importantes componentes de softwa-
re de uma organização. Nesse ambiente, as alternativas de software livre já são bastante
conhecidas e frequentemente 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 é desenvolvi-
do 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 fun-
cionalmente equivalentes, sendo diferenciadas pelo nível de suporte e certificação. In-
discutivelmente é 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 re-
centemente 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 apli-
cações pouco sofisticadas ou bem específicas.
Por sua vez, os sistemas de banco de dados proprietários buscam competir com funcio-
nalidades diferenciadoras, principalmente as relacionadas com administração de am-
bientes 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 softwares de
banco de dados proprietários, com diversas empresas independentes oferecendo ferra-
mentas 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.
19
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+reve-
nue,+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, nesse mesmo ano,
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 relacionados
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 ta-
refas 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 procedu-
res, 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 es-
truturados, 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 ecos-
sistema 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 fun-
cionalidade do software (não é mais adequado às necessidade 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 gaba-
ritado, 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 podem ser subestimados. Temos os custos da conversão de dados, custos da
codificação, testes e o que chamamos reconciliação entre as aplicações no novo e no
antigo ambiente, sempre considerando que dificilmente conseguiremos fazer uma mi-
gração estilo big bang, mas que esta será gradual.
Quanto mais complexas forem as aplicações a serem convertidas, mais custosa será a
migração. Essa 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á con-
vertidas e as que ainda estão no banco de dados antigo. Também os custos de supor-
te 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:Taurion (2007, online).
21
CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE

DADOS
Se utilizar um sistema de banco de dados parece uma solução natural, qual seria
a 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 dese-
nho etc. são alguns exemplos 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 esses sejam gravados
de modo persistente. A abordagem de arquivos tem suas vantagens, como, por
exemplo, a portabilidade dos dados. Você pode carregá-los eletrônica ou fisica-
mente para locais diferentes de modo bastante simples. Mas entre as desvantagens
dessa abordagem há todo o trabalho necessário para se criar um formato e pro-
cessar 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. Desse 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 aborda-
gem de sistemas de banco de dados da manipulaçã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
Características de Sistemas de Bancos de Dados

22 UNIDADE I
conjuntamente. Essas metainformações armazenadas contêm informações como

o tipo, o tamanho e as restrições do banco de dados. Em termos técnicos, as
metainformações são chamadas de esquema (ou schema, em seu termo origi-
nal 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 pro-
grama é altamente acoplado à sua estrutura de armazenamento de dados. Em
contraste, SBGDs permitem que o programa somente informe quais dados são
armazenados, sem se importar em como esses dados serão manipulados inter-
namente. Essa característica aumenta bastante o nível de manutenibilidade do
sistema, quando bem aplicada.
Múltiplas visões dos dados: estas não são uma característica fundamen-
tal, 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, 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 dessas abordagens
deu-se no final da década de 1990, embora ainda hoje seja possível testemu-
nhar aplicações sendo executadas sob esse 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, quando bem utilizada e de modo ade-
quada, é 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

23
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 computação, embora seja perfeitamente possível. Ao lidar-
mos 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 desses múltiplos usuários man-
tenha o banco de dados num estado consistente é o mecanismo de transações,
que será descrito no próximo tópico.
Características de Sistemas de Bancos de Dados

A REVOLUÇÃO DO BIG DATA ESTÁ PRESTES A ACONTECER
Cezar Taurion
O termo Big Data começa a despertar muita atenção, mas ainda é um conceito mal de-
finido e compreendido. Com uma rápida pesquisa no Google, identifiquei, pelo menos,
uma dúzia de definições. Neste artigo, vou falar um pouco sobre o assunto e debater
alguns desafios que temos para conseguir colocar projetos de Big Data em ação.
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 da-
dos gerados pelos objetos na Internet das Coisas, 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, vídeos,
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 o veterano Data Warehou-
se 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 múlti-
plos petabytes e mesmo as pequenas e médias empresas trabalham com dezenas de
terabytes de dados. Esse volume tende a crescer geometricamente. Em um mundo cada
vez mais competitivo e rápido, as empresas precisam tomar decisões baseadas não ape-
nas 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 competiti-
vidade 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 dos 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,
25
como tal, podem - e deverão - ser quantificados economicamente.

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 facili-
tado pelo modelo de computação em nuvem, desde, é claro, que esse imenso volume
não seja transmitido repetidamente via Internet. Só para lembrar, os modelos de co-
branç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 “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 base-
ado 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 acessassem bases de dados corporativas e, portan-
to, estruturadas. Para soluções Big Data, tornam-se necessárias várias 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 falan-
do 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 desses 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 es-
paço para dois perfis profissionais: um mais voltado para os negócios e qualificados para
tratar analiticamente as informações geradas por essas 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 sai-
bam interpretar os números usando a análise de dados, também conhecida como inte-
ligê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 ideia 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 siste-
mas e, após criar um data warehouse, dispara “queries”. Na prática, faz-se uma garim-
pagem 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, essa garimpagem
é efetuada em tempo real. Em vez de disparar queries em cima de uma base de dados
estática, coloca-se uma corrente contínua de dados (streaming data) atravessando um
conjunto de queries. Podemos pensar em inúmeras aplicações, sejam estas em finanças,
saúde e mesmo manufatura.
Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de
fabricação de semicondutores monitora em tempo real o processo de deteção e classi-
ficação de falhas. Com o stream computing, as falhas nos chips que estão sendo fabri-
cados 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 Wiki-
pedia.
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: Taurion (2012, online).
O maior evento da comunidade brasileira de NoSQL:

<http://nosqlbr.com/>. Acesso em: 27 jul. 2015.
27
TRANSAÇÕES
O conceito de transação é fundamental em muitas áreas da computação e parti-

cularmente 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. Essas 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 con-
ceito 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”. Isso permite que durante a nossa interação
com um banco de dados possamos agrupar vários comandos relacionados com
a garantia de que todos sejam executados – de modo que as informações arma-
zenadas permaneçam num estado consistente após a execução da transação.
Transações
28 UNIDADE I
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 exe-
cuçã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.
Em nossa opinião, é 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 continui-
dade do próprio negócio está em risco. Mas mais importante do que os dados
em si é o uso que se faz deles.

29
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 pro-
priedades 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, Even-
tually consistent) – traduzido literalmente como Basicamente Disponível,
Estado flexível e Eventualmente consistente. O BASE tornou-se uma sigla
bastante comum ao lidar com bancos de dados não relacionais.
Uma reflexão que vale a pena ser feita é: para os novos desafios e empreita-
das que você, futuro(a) profissional, enfrentará, em quais situações o ACID é
recomendado e em quais outras situações o BASE mostra-se mais adequa-
do?
Fonte: Pritchett (2008, online).
Transações
30 UNIDADE I
Papéis assumidos pelos usuários de SGBDs
São pessoas que projetam e codificam os SGBDs. Exem-

plos de pessoas nesses papéis incluem os funcionários
de empresas como Oracle, IBM e Microsoft que atuam
diretamente na programação do software SGBD. No caso
DESENVOLVEDORES DE de SBGDs livres, podem ser também voluntários ou pes-
SGBDS soas 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.
São pessoas que desenvolvem software que armazena as

informações em um SGBD. Tradicionalmente, em abor-
dagens mais tradicionais e conservadoras, as equipes de
DESENVOLVEDORES
desenvolvimento são separadas em desenvolvedores e
DE APLICAÇÕES E
DBAs. Os primeiros desenvolvem o software que acessa
ADMINISTRADORES
o SGBD. Os segundos projetam os bancos de dados e
DE BANCOS DE DADOS
os mantêm. Em abordagens de desenvolvimento mais
(DBAS – DATABASE
modernas, tende-se a eliminar essa distinção entre os pa-
ADMINISTRATORS)
pé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.
São pessoas que não interagem diretamente com os ban-

cos de dados, e sim com as aplicações criadas pelos de-
senvolvedores de software que armazenam suas informa-
USUÁRIOS FINAIS ções em SGBDs. A maioria das pessoas enquadra-se nessa
categoria e, embora sejam os grandes beneficiados pela
tecnologia dos sistemas de bancos de dados, raramente
possuem ciência do fato.
Quadro 1: Papéis assumidos pelos usuários de SGBDs

Fonte: os autores.

31
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 esse conceito.
Disponível em: <http://youtu.be/Car5V9l8BiQ>. Acesso em:7 jul. 2015.
VANTAGENS DE SE UTILIZAR UM SGBD

Durante os tópicos anteriores, já citamos algumas vantagens de se utilizar um

SGBD para armazenar as informações de nossas aplicações. A seguir, as enu-
meraremos de um modo mais detalhado, de forma a justificar seu uso em uma
diversidade de situações.
1. Diminuir a redundância e fornecer consistência: imagine uma situação
bastante comum em que você resolve elaborar um documento e necessita
da colaboração de várias pessoas para fazê-lo. Você então cria o esboço
desse documento e o envia por e-mail a todos os interessados. Cada pes-
soa 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? Essas são perguntas difíceis
de serem respondidas nessa abordagem e provavelmente exigirá muito
trabalho manual para se chegar à versão final do documento. Um SGBD
centraliza todas essas 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 a serem manipulados. Isso permite tam-
bém que o banco de dados sempre permaneça em um 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 anti-
gos e outro “pedaço” com a informação atual.
2. Controle de acesso: muitas informações armazenadas em sistemas são
confidenciais. Ao mesmo tempo, é necessário que essas informações sejam
compartilhadas com as pessoas para que sejam trabalhadas. Ao utilizar
arquivos, é necessário que uma cópia seja enviada aos interessados. Por
Vantagens de se Utilizar um SGBD

32 UNIDADE I
múltiplos motivos, essas cópias podem acabar sendo enviadas por e-mail
a pessoas cujo acesso é indevido ou a mesma pode ser deixada em um
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.
3. Consultas eficientes: como são aplicações de software de propósito
específico, os SGBDs são especialmente projetados para armazenar efi-
cientemente os dados a eles delegados e para permitir formas de consulta
eficientes aos mesmos dados. Cada SGBD possui sua estratégia interna
para transformar essas 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 infor-
mações. Assim, os SBGDs utilizam dispositivos como índices (que são
estruturas criadas para otimizar consultas baseadas em certos critérios)
e cachês (caches) para armazenar em memória os dados mais frequente-
mente acessados. Esses dispositivos permitem que as consultas possam
ser executadas de modo mais rápido e, em muitos SGBDs, adequar esses
dispositivos de modo otimizado chega a quase ser uma arte, tamanha a
quantidade de opções disponíveis.
4. Backup e Restore: para garantir a continuidade dos negócios, é essen-
cial 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.
Essas mesmas ferramentas suportam a restauração desses 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.

33
COMPUTAÇÃO EM NUVEM E ARQUITETURAS DE ARMAZENAMENTO EM

NUVEM
A computação em nuvem e o armazenamento em nuvem se tornaram o método pre-
ferencial para a distribuição de informações e funcionalidade online. Enquanto alguns
serviços de nuvem focam em fornecer aos consumidores uma ampla gama de funciona-
lidades e serviços, incluindo compras online, pesquisa, rede social, consumo de entrete-
nimento e proteção de documentos importantes, outros serviços de nuvem focam em
pequenas empresas, grandes corporações, governos e outras instituições.
Diversos serviços de nuvem oferecem armazenamento em nuvem gratuitamente para
os consumidores, enquanto outros cobram algum tipo de tarifa com assinatura. Há
também as nuvens privadas, pertencentes e controladas por uma organização, que for-
necem uma rede segura para o compartilhamento de softwares e dados cruciais. Por
exemplo, hospitais podem optar por usar serviços públicos de arquivamento para re-
gistros médicos eletrônicos e dados de imagem de pacientes (usando PACS) ou podem
criar a sua própria solução de arquivamento em nuvem. Além disso, hospitais podem
juntar seus orçamentos e recursos para criar um consórcio ou grupo de nuvem privada
compartilhada. Nuvens privadas são criadas usando hardware, software e outras ferra-
mentas de diferentes fornecedores, enquanto os próprios servidores são gerenciados
interna ou externamente. Nuvens híbridas, como o nome sugere, combinam vários re-
cursos de nuvem pública e privada em um serviço ou solução.
No centro de todos os serviços, produtos e soluções de nuvem estão ferramentas de sof-
tware com três pilares subjacentes de funcionalidade: ferramentas para o processamen-
to de dados e a execução de aplicativos (servidores computacionais), movimentação de
dados (redes) e preservação ou armazenamento de dados (armazenamento).
Este artigo discute as arquiteturas de armazenamento e computação em nuvem, apro-
veitando o conhecimento fundamental em armazenamento de dados de TI e corpora-
tivos.
Histórico e desafios
A computação em nuvem e o armazenamento em nuvem são os assuntos do momento
para tratar dos problemas e desafios comuns em TI, além de trazer novas oportunidades.
Para alguns ambientes, a principal meta é cortar custos e, para outros, sustentar o cres-
cimento. Além disso, alguns ambientes precisam aprimorar objetivos de nível de serviço
(SLOs) e cumprir acordos de nível de serviço (SLAs) em termos de disponibilidade, de-
sempenho, segurança e proteção de dados.
Os desafios comuns enfrentados pelas soluções em nuvem incluem:
Desafio de TI Solução em nuvem

Orçamentos fixos ou reduzidos Fazer mais com os orçamentos disponí-
veis sem deixar de promover o crescimen-
to
Demanda por nova funcionalidade Agilidade possibilitada pela implementa-
ção rápida
Promover crescimento com estabilidade Elasticidade que promova o crescimento
com resiliência
Privacidade e segurança de informações Multi-inquilino para coexistência segura
Proteção de dados Continuidade dos negócios e recupera-
ção de desastres flexíveis
Aprimorar o atendimento ao cliente Reduzir o tempo de entrada no mercado e
possibilitar novas oportunidades
Falta de mobilidade ou flexibilidade Permitir acesso de qualquer lugar a partir
de diferentes dispositivos
O que são as soluções em nuvem?

Soluções em nuvem são ferramentas para a criação e o armazenamento de conteúdo
ou informações, bem como estratégias de onde e como consumi-los. Essas soluções são
usadas para criar infraestruturas virtuais para grandes e pequenas organizações hospe-
darem aplicativos e funções comerciais, assim como um local para desenvolver e testar
novos recursos. Além disso, incluem serviços ou produtos (hardwares, softwares e redes)
pagos separadamente e soluções que você pode comprar para instalar no seu ambiente
específico.
Para começar, aqui estão alguns termos e expressões comuns relacionados às soluções
em nuvem:
• Otimizado e com boa relação custo-benefício: alinha recursos a SLOs para cum-
prir SLAs
• Menu de opções de serviço para escolher: camadas de recursos alinhados a custo
e SLAs
• Elástico, escalável com estabilidade: promove o crescimento sem adicionar com-
plexidade
• Resiliente, flexível e dinâmico: adaptar-se às necessidades do momento e man-
ter-se disponível
• Provisionamento rápido ou automático: acessa recursos e serviços rapidamente
• Seguro e multi-inquilino (multi-tenant): separação segura de usuários, manten-
do a integridade dos dados
35
• Medido e gerenciado: métricas para gerenciamento de relatórios, análises e ser-

viços
• Escala na densidade: usar capacidade de multi-inquilino e economias de escala e
cortar custos
SaaS a PaaS e IaaS
O SaaS (Software as a Service, software como serviço) que é consumido por meio das
soluções em nuvem inclui entretenimento pessoal e de consumo (Netflix), notícias e
rede social (Facebook, Skype e Twitter), compartilhamento de fotos, compartilhamento
de arquivos (Dropbox), serviços de email, música e backup online.
Além de oferecer uma funcionalidade distinta para consumidores, pequenas e grandes
empresas também utilizam as soluções em nuvem para aumentar a produtividade. Por
exemplo, compartilhamento de documentos (Google Docs), gestão de relacionamento
com o cliente ou CRM (Salesforce.com), relatórios de despesas (Concur), folha de paga-
mento (ADP), email, compartilhamento de arquivos, backup e arquivamento. Além de
apresentar o SaaS, os provedores de serviços de nuvem também oferecem ferramentas
e ambientes para PaaS (Platform as a Service, plataforma como serviço) para proporcio-
nar o desenvolvimento e a criação de serviços de SaaS entre outros.
Os tipos de camadas de armazenamento para a IaaS (Infrastructure-as-a-Service, infraes-
trutura como serviço) incluem recursos como Web ou máquinas virtuais (VMs), armaze-
namento para compartilhamento de arquivos online, backup ou arquivamento, banco
de dados, ferramentas de desenvolvimento e busca. Esses recursos possibilitam que os
próprios provedores de serviços de nuvem e terceiros criem soluções individualizadas
para combinar diversas funcionalidades ou camadas de nuvem nos serviços oferecidos.
Os serviços de armazenamento em nuvem SaaS incluem compartilhamento de arquivos,
documentos, música, fotos e vídeo, backup/restauração, continuidade dos negócios e
recuperação de desastres, juntamente com recursos de arquivamento. Outras opções
de armazenamento em nuvem incluem banco de dados, análise de dados (incluindo
serviços baseados em redução em mapa e Hadoop), unidades de nuvem e outras apli-
cações que usam armazenamento em nuvem back-end. As soluções de armazenamento
em nuvem também se estendem a produtos e soluções usados para implementar nu-
vens públicas, privadas e híbridas.
Produtos e soluções são as peças de armazenamento em nuvem mais comuns dos sis-
temas de armazenamento físico. Os serviços de nuvem privada e pública de SaaS a PaaS
e IaaS usam armazenamento em camadas, incluindo unidades de estado sólido (SSDs)
e discos rígidos (HDDs). Assim como os ambientes tradicionais de armazenamento cor-
porativo, os provedores de soluções e serviços em nuvem utilizam uma mistura de ca-
madas de tecnologia de armazenamento diferentes, que atendem a requisitos de SLO
e SLA diferentes. Por exemplo, a utilização de SSDs rápidas para consolidação de E/S
densa (oferecendo suporte a registros e índices de bancos de dados, metadados para
pesquisa rápida e outros dados transacionais) possibilita que mais trabalho seja reali-
zado com menos energia em um espaço (footprint) mais denso e com melhor relação
custo-benefício.
O uso de uma mistura de SSDs ultra-rápidas com HDDs de alta capacidade cria um equi-
líbrio de desempenho e capacidade para atender a outros requisitos de serviço com
diferentes opções de custo de serviço.
Com os serviços em nuvem, em vez de especificar qual tipo de unidade física comprar,
os provedores de serviços de nuvem cuidam disso oferecendo diversas opções de dis-
ponibilidade, custo, capacidade, funcionalidade e desempenho para atender a diferen-
tes requisitos de SLA e SLO.
Arquitetura de nuvem
No cerne da TI legada, a hospedagem, provedores de serviços gerenciados (MSP) e nu-
vens são peças comuns, que incluem tecnologias de rede, processamento e armazena-
mento.
Diferentes tipos de servidores, redes e tecnologias de armazenamento atendem a diver-
sos requisitos de armazenamento em nuvem e computação em nuvem (servidores bla-
de e em rack densos com diferentes números de soquetes e cores a velocidades de GHz,
threads, quantidade de memória e recursos de expansão de E/S diversos são apenas
alguns exemplos). As opções de rede incluem 40GbE e 100GbE rápidos para circuitos de
retorno (backhaul) e de tronco, juntamente com 10GbE e 1GbE mais comuns para redes
virtuais privadas (VPN) e otimização de largura de banda.
As opções ou camadas de armazenamento de dados incluem SSDs ultra-rápidas, bem
como HDDs rápidos de capacidade média a alta. Os recursos de gerenciamento de ar-
mazenamento incluem proteção de dados — alta disponibilidade (HA), backup (BC) e
recuperação de desastres (DR) — assim como redução de volume (footprint) para otimi-
zação de espaço, como compressão, deduplicação e provisionamento fino, o que possi-
bilita que mais informações sejam armazenadas por períodos mais longos a custos mais
baixos.
As ferramentas de software também são muito importantes na criação de serviços e
soluções e incluem APIs, middleware, banco de dados, aplicativos, hipervisores para
criação de máquinas virtuais (VMs) e infraestruturas de desktop virtual (VDI), juntamen-
te com stackware de nuvem, como OpenStack e ferramentas de gerenciamento asso-
ciadas. Alguns exemplos de hipervisores de VMs e VDI são Citrix/Xen, KVM, Microsoft
Hyper-V, Oracle e VMware ESX/vSphere.
Nos três casos, o armazenamento de dados é configurado em sistemas de armazena-
mento, equipamentos de armazenamento e servidores de computação.
As nuvens públicas são serviços acessível gratuitamente ou mediante o pagamento
de uma tarifa, que fornecem diferentes funcionalidades, como Amazon Web Services
37
(AWS), Google Docs ou software de backup de dados Seagate® EVault®. As nuvens públi-
cas são controladas por seus respectivos proprietários, cujos clientes optam por usar os
seus serviços. As nuvens privadas, por outro lado, pertencem e são operadas e controla-
das por organizações e são semelhantes aos serviços de TI legados. Entretanto, observe
que as nuvens privadas criadas usando componentes e serviços públicos e instalações
externas existentes em diferentes locais de provedores de nuvem são chamadas de nu-
vens híbridas.
A Seagate e o armazenamento em nuvem
A Seagate é líder no fornecimento de armazenamento corporativo e, sem nenhuma sur-
presa, também está no centro da infraestrutura de nuvem. Aproveitando décadas de
experiência em ambientes de co-localização e serviços gerenciados de alta densidade e
grande escala para empresas, instituições e governos, a Seagate leva esse conhecimen-
to para os ambientes de nuvem pública e privada. Além da tecnologia de armazena-
mento líder de setor, a Seagate tem décadas de experiência trabalhando com diversos
parceiros e suas respectivas soluções de armazenamento, embalagem, chassi e gabine-
te, processos de teste e verificação.
Como um fornecedor-chave para provedores de serviços gerenciados e de nuvem pú-
blica e privada, a tecnologia da Seagate pode ser encontrada em ambientes corpora-
tivos e centrais de dados em nuvem e nos provedores de serviços gerenciados para
pequenas empresas e consumidores. Em outras palavras, a Seagate já está levando o
armazenamento em nuvem e a computação em nuvem da central de dados para o seu
bolso há algum tempo!
As opções de armazenamento para os ambientes de armazenamento em nuvem e com-
putação em nuvem da Seagate incluem a família Pulsar® de SSDs de desempenho ultra-
-alto. Para complementar as unidades Pulsar oferecemos os HDDs de alto desempenho
Savvio® 10K e Savvio 15K de 2,5 polegadas para cenários de densidade mais alta, além
dos HDDs de baixo consumo de energia Constellation®, que comportam uma configu-
ração com vários terabytes.
A Tabela 1 mostra como e onde a Seagate promove o armazenamento em nuvem e a
computação em nuvem pública e privada.
Tabela 1. Como a Seagate promove a nuvem
Central de dados: pública, privada, híbrida Empresarial Pessoal

Computação em
Armazenamento em nuvem Nuvem pessoal
nuvem
Combinação de Boa relação custo-be-
Armazenamento Armazenamento
alto desempenho e nefício, alta capacidade,
local e em nuvem local e em nuvem
capacidade economia de energia
Armazenamento
Pulsar® (SSD), em rede GoFlex®
discos Savvio®15K Home, armaze-
Discos Constellation®
e Savvio 10K de namento pessoal
e Constellation ES de BlackArmor® NAS
2,5 polegadas Backup Plus e
capacidade otimizada
com desempenho armazenamento
otimizado móvel e sem fio
Satellite™
Resumo e próximos passos
Há muitas soluções em nuvem, cada uma oferecendo diferentes serviços, funcionali-
dades e recursos. A funcionalidade e os serviços em nuvem incluindo computação e
armazenamento são combinados para oferecer SaaS, PaaS e IaaS em soluções de nuvem
pública e privada. Esses recursos podem ser distribuídos como um serviço, um produto
ou um conjunto de soluções, também conhecido como ITaaS (IT as a Service, TI como
serviço). Além disso, os serviços de nuvem são reunidos em infraestruturas públicas e
privadas para criar nuvens híbridas a fim de atender às suas necessidades e requisitos
específicos.
A criatividade para satisfazer diferentes necessidades e requisitos de informações são
determinados por como você ou o seu provedor de serviços usam os recursos de nuvem.
39
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 abs-
traçã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 esses 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 denomi-
nados 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 aborda-
gens 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
desses sistemas de banco de dados, esperamos que você, como desenvolvedor(a),
possa ter argumentos suficientes para decidir adequadamente entre uma abor-
dagem 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 esses usuários podem assumir nessas interações. Uma máxima
que devemos sempre utilizar é a “técnica do espelho”. Olhe sempre para o sof-
tware 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 melhor consciência 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 sis-
temas de bancos de dados observaria argumentos bastante positivos em relação à
abordagem dos SGBDs. O papel de um desenvolvedor experiente é distanciar-se
Considerações Finais
40 UNIDADE I
desses apegos a uma determinada tecnologia ou outra e decidir sobriamente qual

a solução mais adequada para a sua aplicação.
Uma vez entendidos esses 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 esses sistemas. Tais
tópicos serão abordados em nossa próxima unidade.

41
1. Transações tradicionalmente são melhor entendidas por meio do conjunto de

suas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilida-
de). Em quais situações da vida real você consegue enxergar a necessidade de
se executar operações com essas 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. Tendenciosa-
mente, 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ê conse-
gue 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 desse isolamento? Em que outras partes do siste-
ma essa característica também pode trazer benefícios?
Prof. Esp. Victor de Marqui Pedroso
II
UNIDADE
MODELO RELACIONAL
■■ Capacitar o aluno ao entendimento dos conceitos básicos na criação
de um banco de dados.
■■ Apresentar ao aluno, a melhor maneira de aplicação dos conceitos
básicos.
Plano de Estudo
■■ Modelo Relacional
■■ Introdução à Modelagem
■■ Atributos
■■ Tipos de Atributos
■■ Domínio
■■ Chave Estrangeira (Foreign Key)
■■ Relacionamentos
■■ Cardinalidade
45
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 rela-
cional é atribuído a Ted Codd da IBM em 1970 e imediatamente se popularizou
devido à sua simplicidade e sólidos fundamentos matemáticos: é baseado na teo-
ria geral dos conjuntos e em lógica matemática.
Os primeiros SGDBs Relacionais apareceram na década de 1980 como uma
novidade boa no meio da computação, tanto que esses SGDBs acabaram suce-
dendo os bancos de dados hierárquicos em rede predominantes por mainframes.

Por serem bancos de dados com características fortes como: capacidade de inse-
rir grande quantidade de dados, rapidez na identificação e tratamento de erros,
realização de pesquisa de dados de maneira rápida e ainda garantir a integri-
dade dos dados, sua expansão foi enorme e aos poucos acabou crescendo tanto
que tornou-se sinônimo de “banco de dados”. Alguns bons exemplos de ban-
cos de dados relacionais são DB2 (IBM), Oracle e MySQL (Oracle), SQLServer
(Microsoft), Firebird (software livre), Interbase (Borland) e PostgreSQL (sof-
tware livre).
Agora que já sabemos quais são os bancos de dados relacionais existentes,
vale lembrar que devemos sempre trabalhar para uma boa operacionalização
deles e, para que isso ocorra, precisamos nos basear em normas concisas no
momento da criação de um projeto de bancos de dados. Uma vez que nos apro-
fundemos nos estudos da teoria relacional, estaremos capacitados na criação de
projetos que sejam corretos, consistentes e bem estruturados, evitando, assim,
um futuro problema ou retrabalho.
Dada a relevância do assunto, estudaremos o modelo relacional introduzindo
alguns conceitos fundamentais e importantes desse modelo, sempre mesclando a
teoria com a prática, utilizando também exemplos concretos e que estejam par-
ticipando mais proximamente da nossa rotina de trabalho e do nosso cotidiano.
Introdução
46 UNIDADE II
O MODELO RELACIONAL
Quando nos propomos a criar um banco de dados, temos que saber da importância
do modelo relacional, pois é nele que nos basearemos para uma implementa-
ção inicial. O modelo relacional é um modelo da segunda geração que surgiu
depois dos modelos pré-relacionais, hierárquicos e de rede. Os modelos que hoje
tentam substituir são os de terceira geração, os pós-relacionais, modelos orien-
tados a objetos, objeto relacional, temporal e geográfico. O Modelo relacional
tem uma sólida base formal, construído sob a teoria dos conjuntos, seu nome é
devido à relação matemática da teoria dos conjuntos e não aos relacionamen-
tos, como muitos pensam. Trata-se de um modelo com estruturas de tabelas e
alguns conceitos.
O modelo relacional permite a representação da estrutura lógica do projeto
com uma visão genérica. Sua estrutura é feita de forma clara e simples, possibili-
tando representar os dados do mundo real como objetos denominados entidades
ou conjunto de entidade.
Neste livro, estaremos utilizando a notação de Peter Chen (1990), notação
esta que fora criada, em 1976, pelo Dr. Peter Pin-Shan Chen, que é um cientista
da computação americano e professor de ciência da computação na Louisiana
State University, conhecido como criador do modelo entidade relacionamento.
MODELO RELACIONAL
47
Entidade:
Atributo: ou
Relacionamento:
Figura 2: Componentes DER (Diagrama Entidade e Relacionamento)

Fonte: os autores.
ENTIDADES (TABELAS)
A entidade ou tabela trata-se de uma representação gráfica de um conjunto,

conjunto este cuja representação física ou gráfica padrão é feita por meio de
um retângulo com o nome da entidade dentro dele. Para identificarmos uma
entidade, devemos considerar os objetos, coisas ou algo que seja relevante no
levantamento dos dados. Segue abaixo alguns exemplos (Figura 3 e Figura 4):
Alunos Viagem
Carros Aluguel
Figura 3: Exemplo de Entidades

Fonte: os autores.
O Modelo Relacional
48 UNIDADE II
No exemplo dado na Figura 3, temos uma entidade Alunos, em que é repre-

sentado um conjunto de Alunos. Da mesma forma, podemos dizer que a Entidade
Carros representa um conjunto de Carros, e assim sucessivamente.
Baseados no conceito de Entidade, podemos classificar as Entidades em
Concretas e Abstratas, em que entidades Concretas são entendidas como objeto do
mundo real que pode ser separado e distinguível de outro objeto. Já as Entidades
Abstratas são aquelas que não temos de maneira tangível (intangível). Com isso,
vale lembrar que, em ambos os Tipos de Entidades, a representação é a mesma.
A seguir (Figura 4), iremos classificar algumas Entidades:
Exemplos de Entidades Concretas Exemplos de Entidades Abstratas
Alunos Livro Viagem Compra
Carro Funcionário Aluguel Empréstimo
Figura 4: Exemplo de Entidades Concretas e Entidades Abstratas

Fonte: os autores.
INTRODUÇÃO À MODELAGEM
Agora que já sabemos o que é uma entidade, é importante entendermos o motivo

pelo qual ela será criada, para isso, podemos utilizar a Descrição Textual Narrativa,
sendo essa nada mais que o levantamento de requisitos junto ao cliente, ou seja,
uma entrevista em que iremos retirar as informações devidas para a implemen-
tação do nosso sistema. Nesse momento, é importante anotarmos TODAS as
necessidades do nosso cliente e, a partir dessas anotações, iremos analisar os
MODELO RELACIONAL
49
substantivos das frases e, caso esse substantivo seja relevante ao sistema, pode-
remos transformá-lo em uma entidade, por exemplo:
Na frase: “a bibliotecária empresta um livro”, podemos retirar duas possí-
veis entidades, sendo elas:
Bibliotecária Livro

Fonte: os autores.
Já na frase: “o carro percorre vários itinerários”, podemos retirar duas possíveis

entidades, sendo elas:
Carro Itinerário

Fonte: os autores.
E, assim, iremos popular o nosso sistema com as entidades necessárias para a

implementação, porém, vale lembrar que essa fase é IMPORTANTÍSSIMA e
deve ser feita com muita atenção. Você pode estar se perguntando o motivo de
tanta importância, vou exemplificar de maneira prática. A comparação dessa fase
inicial é a mesma de uma obra de uma casa, pois, uma vez que for mal dimen-
sionada a estrutura, podemos ter sérios e irreversíveis problemas no futuro. A
seguir, seguem dois exemplos de uma análise a partir de uma Descrição Textual
Narrativa.
Introdução à Modelagem
50 UNIDADE II
Exemplo 1:
O atendente solicita os dados pessoais do cliente

no momento do seu cadastro, aproveita, inclusive, para
perguntar quais são os gêneros de sua preferência.
Funcionário Cliente Gênero
Figura 7: Exemplo 1 de Descrição Textual Narrativa
Fonte: os autores.
Analisando o Exemplo 1 (Figura 7), temos como substantivos atendente, que

podemos nomear como funcionário e temos, também, as palavras cliente e gêne-
ros. Com isso, para a implementação do que fora relatado e do que é relevante,
teremos a necessidade de criação de 3 entidades, sendo elas: FUNCIONÁRIO,
CLIENTE E GÊNERO.
Exemplo 2:
O nosso cliente entra aqui na loja e escolhe o filme

que deseja ver, os filmes estão separados nas prateleiras
pelo gênero ao qual eles pertencem, facilitando assim a
sua localização
Cliente Filme Gênero
Figura 8: Exemplo 2 de Descrição Textual Narrativa

Fonte: os autores.
MODELO RELACIONAL
51
Analisando o Exemplo 2 (Figura 8), temos como substantivos as palavras cliente,

loja, filme, filmes, prateleiras e gênero. Veja que riscamos a palavra prateleiras,
pois não temos a necessidade de cadastrar as prateleiras e a localização pode ser
cadastrada diretamente na entidade Filme. Outra palavra riscada foi loja, sendo
que essa seria relevante e poderia ser aproveitada apenas se tivéssemos mais de
uma loja, ou seja, tudo varia da regra do negócio que está sendo analisado. Com
isso, concluímos que as entidades que serão implementadas serão: CLIENTE,
FILME E GÊNERO.
Dicas para uma boa modelagem:
• Ter em mente o cenário a ser modelado.
• Detectar os substantivos no momento da análise do sistema.
• Nomear apropriadamente as entidades detectadas.
• Padronizar os nomes (plural, singular, abreviações).
• Fazer o diagrama em um rascunho de próprio punho em papel.
• Definir o tipo de organização mais adequado.
• Realizar um bom levantamento do método manual e do procedimento manu-

al junto ao principal usuário.
Fonte: Roberto Yukio Nishimura
Introdução à Modelagem
52 UNIDADE II
10 curiosidades sobre o Google

O Google está na mídia o tempo todo, mas existem dados sobre a compa-
nhia que algumas pessoas ainda desconhecem. O Business Insider reuniu
10 fatos curiosos, sobre a gigante da web, que merecem atenção. Confira
abaixo.
1. O Google.com, que abriga as mais importantes empresas do mundo, con-
tém 23 erros em seu código.
2. A empresa já fotografou mais de 8 milhões de quilômetros para o Street
View.
3. Originalmente a companhia se chamaria ‘Googol’, mas os investidores es-
creveram ‘Google’ no primeiro cheque de contribuição e o nome permane-
ceu.
4. O banco de dados de buscas do Google tem mais 100 milhões de giga-
bytes. Seria necessário 100 mil HD externos de 1 terabyte para armazenar
todos esses dados.
5. O mundo assiste mais de 450 mil anos de vídeos no YouTube por mês. Isso
é mais do que o dobro de anos de existência dos humanos modernos.
6. O Google usa o captcha para ensinar computadores a ler textos digitaliza-
dos de livros. São 200 milhões de captchas resolvidos por dia.
7. A página do Google tem um layout simples, porque Sergey Brin e Larry
Page não sabiam HTML. A dupla decidiu deixar o site da mesma forma para
reforçar a identidade.
8. A gigante da web deve ser a única companhia que tem como objetivo
explícito reduzir o tempo que as pessoas passam em seu site.
9. Na média, a companhia adquiriu mais de uma empresa por semana desde
2010.
10. Em 2011, 96% dos US$ 37,6 bilhões em receita do Google vieram apenas
de anúncios.
Fonte: Olhar Digital - 10 Curiosidades (2013, online).
MODELO RELACIONAL
53
ATRIBUTOS
Os atributos são propriedades utilizadas para descrever uma entidade, podemos

afirmar que os Atributos são as características contidas nas Entidades, por exem-
plo, em uma Entidade Cliente, podemos relacionar os atributos CPF, NOME,
IDADE, ENDEREÇO, BAIRRO, CIDADE etc. Vamos ao exemplo passo a passo:
1°) Vamos imaginar uma Entidade Produto.
Ela será simbolizada da seguinte maneira:
Produto
2°) Agora, iremos relacionar alguns Atributos a essa Entidade:
Código Valor_Venda
Produto
Valor_Custo Descrição
Figura 9: Exemplo de Atributos em uma Entidade

Fonte: os autores.
3°) Outra maneira de demonstrar uma Entidade e Atributos é em forma de

Planilha:
Observando a Figura 10, verificamos que a tabela PRODUTOS contém
Atributos que são os nomes das colunas e um conceito novo chamado de TUPLA.
Definindo de modo formal, uma linha é denominada de Tupla.
Atributos
54 UNIDADE II
PRODUTOS Entidade
Código Descrição Valor_Custo Valor_Venda Atributos
01 Lápis 1,00 2,00 Tupla
02 Borracha 1,50 3,00
03 Mouse 10,00 20,00
Figura 10: Exemplo de uma entidade em formato de colunas
Fonte: os autores.
TIPOS DE ATRIBUTOS
■■ Atributo Simples: o Atributo Simples contém um único valor para cada

elemento da entidade. Nesse caso, pode ocorrer uma informação repetida,
ou seja, para uma entidade Cliente, temos um nome para cada cliente,
podendo acontecer de dois clientes terem o mesmo nome, mas infor-
mando um dado para cada Cliente. A seguir, temos a representação do
atributo simples:
MODELO RELACIONAL
55
CPF CPF
Cliente ou Cliente
Nome Nome
Funcionário ou Funcionário
Matrícula Local
Matrícula Local
Nome
Nome
Figura 11: Exemplo de tipos de atributos

Fonte: os autores.
■■ Atributo Multivalorado: o Atributo Multivalorado permite conter informa-

ções com diversos valores. É a solução do problema quando, por exemplo,
você tem vários telefones para um Funcionário. A seguir, temos a repre-
sentação do atributo multivalorado:
Matrícula Telefones
Funcionário
Sexo Data_Nascimento
Figura 12: Exemplo de um atributo do tipo multivalorado

Fonte: os autores.
Tipos de Atributos
56 UNIDADE II
■■ Atributo Composto: o Atributo Composto nos permite indicar um atributo

que pode ser dividido em outros. Um exemplo pode ser o endereço, que
podemos dividir em rua, cidade, estado e CEP. A seguir, temos a repre-
sentação do atributo composto:
Logradouro
Bairro
Matrícula Endereço
Cidade
Sexo Funcionário Complemento
Data_Nascimento
Figura 13: Exemplo de um atributo do tipo composto

Fonte: os autores.
■■ Atributo-Chave: quando temos os atributos de uma entidade, é impor-

tante sempre indicarmos um identificador, que podemos chamar também
de Atributo-Chave. Esse atributo irá identificar o item da entidade de
maneira única (sem repetição) no conjunto de elementos.
O Atributo-Chave deve ser íntegro, ou seja, sem repetições, e também não

pode ser nulo (valores vazios). A sua representação pode ser demonstrada de
maneira sublinhada ou com o círculo destacado na borda em negrito, conforme
a Figura 14:
Código ou Código
Figura 14: Exemplo de um atributo do tipo Chave
Fonte: os autores.
MODELO RELACIONAL
57
Exemplificando:
Para a entidade Funcionários, temos os seguintes atributos:
Endereço: analisando esse atributo, sabemos que pode haver mais de um
funcionário morando no mesmo endereço, logo, ele não poderia ser classificado
como atributo identificador.
Nome: esse atributo pode confundir um pouco, pois cada funcionário tem
seu nome, porém, pode haver funcionários com o mesmo nome, logo, pode-
mos perceber que o nome ser utilizado como um identificador pode nos trazer
problemas.
Matrícula: para cada funcionário, é gerado um número de matrícula que

o identificará na empresa e que não pode se repetir. Esse atributo pode sim ser
classificado como Atributo-Chave, devendo ser destacado entre os demais.
A seguir, temos a representação do exemplo Atributo-Chave em uma
Entidade (Figura 15):
Endereço Nome
Funcionário
Matrícula
Figura 15: Exemplo de um atributo Chave em uma entidade

Fonte: os autores.
Tipos de Atributos
58 UNIDADE II
DOMÍNIO
As restrições de domínio especificam que o valor de cada atributo deve ser um

valor atômico que, para cada atributo criado, devemos associar um tipo a ele. A
essa associação, damos o nome de domínio. A seguir, demonstraremos alguns
tipos:
■■ Numéricos: inteiros e reais.
■■ Caracteres.
■■ Booleanos.
■■ Cadeias de caracteres de tamanho fixo e tamanho variável.
■■ Data.
■■ Hora.
A seguir, iremos criar uma tabela chamada Funcionário, contendo NOME DO

CAMPO, TIPOS e TAMANHO para exemplificar a aplicação dos tipos.
Propriedades dos campos da tabela Funcionário:
NOME DO CAMPOS TIPO DO CAMPO TAMANHO

Matrícula Inteiro 3
Nome Caractere 40
Idade Inteiro 3
Data Admissão Data 8
Fonte: os autores.
MODELO RELACIONAL
59
CHAVE ESTRANGEIRA (FOREIGN KEY)
Em nossos estudos, não podemos deixar de estudar sobre a chave estrangeira

ou, em inglês, foreign key, a qual trata-se de um campo que aponta para a chave
primária de outra tabela. Nessa relação entre linhas (tuplas) de duas entidades, o
objetivo da chave estrangeira é garantir a integridade dos dados referenciais, pois
,nesses casos, serão permitidos valores que irão aparecer na base de dados. Vale
lembrar que, após estabelecer uma chave estrangeira, o atributo marcado não
permitirá a exclusão, inserção ou modificação de dados em tabelas que estejam
dependentes umas das outras (“foreign key”), tendo que ter uma maior atenção
dos administradores do banco de dados.
A seguir, exemplificaremos uma chave estrangeira entre duas tabelas (enti-
dades) em que o relacionamento é 1:N:
Figura 17: Exemplo da aplicação de uma chave estrangeira entre duas tabelas
Fonte: os autores.
Chave Estrangeira (Foreign Key)

60 UNIDADE II
Outro exemplo:
Tabela: Professor
Pro_Cod Pro_cpf Pro_DtNasc Pro_idade CodDepto
Tabela: Departamento
Depto_Cod Depto_Nome
Tabela: Curso
Cur_Cod Cur_Nome CodDepto
Figura 18: Exemplo da aplicação de uma chave estrangeira entre duas tabelas
Fonte: os autores.
RELACIONAMENTOS
Analisando o Modelo Relacional, as entidades não podem ficar isoladas, uma

vez que as informações estarão organizadas futuramente para o acesso de forma
integrada. Para essa organização sem perda de conteúdo, as entidades devem
estar associadas, ligadas entre si. No Modelo Entidade Relacionamento (MER),
não é permitido ligar uma entidade diretamente à outra. Quando há uma asso-
ciação, ela é representada por um relacionamento. Quando há uma associação,
ela é representada por um relacionamento e o relacionamento é apresentado na
forma de um losango e, para a associação entre entidades, deve seguir a notação
básica, que são entidades ligadas ao relacionamento por linhas retas, conforme
a Figura 19. Sempre que um relacionamento for indicado, é necessário verifi-
car validade nos 2 sentidos. Atenção! As setas não fazem parte do diagrama, são
apenas para ilustrar os sentidos.
MODELO RELACIONAL
61
Funcionário Setor
Figura 19: Exemplo de notação básica de relacionamentos

Fonte: os autores.
Para definir um relacionamento entre duas entidades, devemos verificar se há

correlação entre elas e podemos fazer isso colocando um verbo para tentar asso-
ciá-las. É importante averiguar se a associação entre as entidades é verdadeira em

ambos os sentidos. Para entender melhor, podemos, na situação a seguir (Figura
20), descrever dizendo que “o funcionário trabalha no setor”.
Funcionário Trabalhar Setor
Figura 20: Exemplo de notação básica de relacionamentos

Fonte: os autores.
Tipos de Relacionamentos:
A classificação dos relacionamentos é baseada no número de entidades que par-
ticiparem em um conjunto de relacionamentos, o que determina também o grau
desse conjunto.
■■ Autorrelacionamento ou Relacionamento Recursivo: nesse caso, são enqua-
drados relacionamentos com apenas uma entidade. Exemplo:
Alunos Pessoas
Monitorar Casar
Figura 21: Exemplo de relacionamento Recursivo ou Autorrelacionamento

Fonte: os autores.
Relacionamentos
62 UNIDADE II
■■ Relacionamento Binário: o relacionamento binário é de grau dois, pois

temos duas entidades. Exemplo:
Professor Ministrar Disciplina
Figura 22: Exemplo de relacionamento binário

Fonte: os autores.
■■ R
elacionamento Ternário: o relacionamento ternário é de grau três, pois
temos três entidades associadas no relacionamento. Exemplo:
Professor Ensinar Curso
Disciplina
Figura 23: Exemplo de relacionamento Ternário

Fonte: Cardoso (2012).
Vale lembrar que, entre duas entidades, também pode haver relacionamento, ou
seja, uma entidade pode estar associada a outra por mais de um relacionamento,
conforme o exemplo a seguir:
Gestor Executa Projetos
Gerenciar
Figura 24: Exemplo de mais de um relacionamento entre duas entidades

MODELO RELACIONAL
63
Outra particularidade de um relacionamento é que os relacionamentos podem

conter atributos, eles não fazem parte de maneira obrigatória das propriedades
das entidades, porém, quando inserimos um atributo associado a um relacio-
namento, ele deve ser comum às duas entidades. A seguir, vamos mostrar um
exemplo relativo a esse tipo de relacionamento:
Palestrante Ministrar Tema

Horário
Figura 25: Exemplo de relacionamento contendo um atributo

Conforme o exemplo citado (Figura 25), podemos dizer que o atributo horá-
rio faz parte comum às entidades associadas no relacionamento, em que esse
informa em que horário que o Palestrante ministra o referido tema.
CARDINALIDADE
A cardinalidade permite expressar o número de ocorrências com que uma enti-

dade pode tomar parte em um relacionamento. Permite também expressar as
possibilidades e restrições de associações entre uma entidade e outra.
Podemos também definir como a “regra de negócio” entre as entidades
envolvidas no relacionamento ou até mesmo a frequência com que essas fun-
cionalidades podem ocorrer.
Cardinalidade
64 UNIDADE II
Notação:
Cardinalidade Máxima
(x : y)
Cardinalidade Mínima
Cardinalidade Máxima
Trata-se do limite máximo de ocorrências de uma entidade em relação à outra:
■■ Um para Um (1:1).
■■ Um para Muitos (1:N).
■■ Muitos para Muitos (N:N) ou N:M.
Cardinalidade Um para Um (1:1):

Acontece quando a ocorrência de uma entidade se relaciona com (no máximo)
uma ocorrência de outra e vice-versa.
Exemplo:
Leitura direta: o Cliente compra no máximo 1 Produto
1 1
Cliente Compra Produto
1 1
Leitura inversa: 1 Produto é comprado pelo Cliente
Figura 26: Exemplo de Cardinalidade Um para Um

MODELO RELACIONAL
65
Cardinalidade Um para Muitos (1:N):

A ocorrência de uma entidade se relaciona com (no máximo) muitas ocor-
rências de outra, porém a ocorrência de outra entidade se relaciona com (no
máximo) uma ocorrência da primeira.
Leitura direta: o Cliente compra no máximo muitos Produtos
1 N
1 1
Leitura inversa: o Produto é comprado por no máximo um Cliente
Figura 27: Exemplo de Cardinalidade Um para N

Cardinalidade Muitos para Muitos (N:N) ou (N:M):

Acontece quando a ocorrência de uma entidade se relaciona com (no máximo)
muitas ocorrências de outra e vice-versa. Exemplo:
1 N
N 1
Leitura inversa: o Produto é comprado por no máximo vários Cliente
Figura 28: Exemplo de Cardinalidade N para N

Cardinalidade
66 UNIDADE II
Quando a leitura é feita de (1:N) em ambos os sentidos das entidades.

Teremos, assim, um resultado (N:N), conforme a seguir (Figura 29):
1 N
vários Clientes Compra Produto
N 1
Leitura inversa: o Produto é comprado por no máximo vários Cliente
Figura 29: Exemplo de Cardinalidade N para N.
Cardinalidade Mínima
Trata-se do mínimo de ocorrências de uma entidade em relação à outra:
■■ Opcional (0) - é quando uma ocorrência se relaciona com (no mínimo)
nenhuma de outra entidade. Abaixo temos a representação:
■■ (0:1) - Nesse caso, a representação textual seria “no mínimo nenhuma
ocorrência em uma entidade para no máximo uma ocorrência na outra
entidade”.
■■ (0:N) - Nesse caso, a representação textual seria “no mínimo nenhuma
ocorrência em uma entidade para no máximo muitas ocorrências na
outra entidade”.
■■ Obrigatória (1) - uma ocorrência se relaciona com (no mínimo) uma de
outra entidade.
No exemplo abaixo (Figura 30), devemos analisar a regra de negócio que, de
acordo com a cardinalidade mínima ser marcada como 0 (zero), significa que o
Cliente não é obrigatório no momento da venda do produto e que o Produto é
MODELO RELACIONAL
67
comprado por, no máximo, um Cliente.
Cliente 0,N Compra 1,N Produto
Figura 30: Exemplo de Cardinalidade N para N

Nesta unidade, procuramos demonstrar os assuntos de maneira que você possa

entender melhor as questões que permeiam os conceitos básicos do Modelo
Relacional de Banco de dados.
Vale enfatizar que, nesta unidade, tivemos a oportunidade de estudar a
respeito de conceitos básicos do Modelo Relacional, como o DER (Diagrama
Entidade e Relacionamento), Tuplas, Entidades, Atributos, Relacionamentos,
Cardinalidades etc. Esses conceitos são importantes para quem deseja apren-
der, de maneira correta, a iniciar a criação de um projeto de banco de dados,
tendo como seu principal objetivo dar ao aluno uma melhor aplicabilidade no
momento da iniciação de um projeto.
Espero que esses conceitos tenham sido explanados de maneira clara e obje-
tiva, sempre buscando exemplificar para que fique claro e, assim, possa facilitar
o seu estudo, entendimento e aprendizado. Aproveito o momento para deixar
aqui o meu incentivo à fixação desse conteúdo, pois esses conceitos são impres-
cindíveis para quem deseja iniciar o desenvolvimento de um banco de dados.
Considerações Finais
1. A partir do estudado nesta unidade, defina Entidades Concretas e Entidades
Abstratas.
2. Crie uma Entidade Produtos com os seguintes atributos:
a. Código do Produto.
b. Descrição do Produto.
c. Unidade do Produto.
d. Valor do Produto.
e. Classificação do Produto.
f. Valor Custo do Produto.
3. Analise as frases abaixo e crie as possíveis entidades:
a. “o atendente matricula o aluno no curso de Administração”.
b. “ a secretária agenda pacientes para atendimento médico”.
c. “ é necessário cadastrar os produtos para realizar as vendas aos clientes”.
69
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 empre-
sas do setor financeiro e industrial do país, revela estudo.
Uma nova geração de bancos de dados livres começa a ganhar adesão de várias empre-
sas do setor financeiro e industrial do país, para aplicações específicas ou embarcadas
em equipamentos de comunicação, e já está criando um impacto positivo entre os de-
senvolvedores.
Essa é uma conclusão do consultor independente Fernando Lozano, community mana-
ger da Java.net, apresentada na quarta-feira (17/08) no Developer’s World 2005, realiza-
do 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 per-
formance, 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 comunida-
des 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 qualquer espécie de retorno financeiro, no máximo um outro patrocínio
para participar em congressos internacionais”, afirma Macieira.
Fonte: Cesar (2005, online).
MATERIAL COMPLEMENTAR
Acesse este link para assistir a uma aula do Professor Marcelo Assis sobre como deve ser feito o
Modelo Relacional Normalizado:
Disponível em: <https://www.youtube.com/watch?v=eiBbG9bVljs>.
Acesso em: 03 jul. 2015.
III
UNIDADE
SQL BÁSICO
■■ Definir o que é SQL.
■■ Apresentar os comandos de definição e uso da SQL.
Plano de Estudo
■■ Definir o que é SQL
■■ Apresentar os comandos de definição e uso da SQL
73
INTRODUÇÃO
A primeira ideia que vem à cabeça de um desenvolvedor experiente, quando

se fala de banco de dados relacionais, é SQL. Talvez uma das boas
razões pelas quais os SGBDs relacionais são tão difundidos
deva-se ao fato de que a SQL é uma ferramenta bas-
tante 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
das quais 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 dessa 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) –
por isso 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, costu-
ma-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. Nesse tipo de 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 que 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 defi-
nirmos 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, esse
seria um fator determinante para decidir entre um produto e outro. A evolu-
ção dos produtos comerciais e livres fez com que essa diferença diminuísse de
Introdução
74 UNIDADE III
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 varian-
tes 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 desse 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 interes-
sante para os fabricantes, pois se baseia 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, esse é um fato infeliz. De positivo do padrão SQL-92 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 atualizações). É uma linguagem bastante abrangente. É por
esse motivo que trataremos da SQL em duas unidades distintas. A unidade III
abordará a criação de schemas e os comandos básicos da linguagem, enquanto
que a unidade IV abordará os comandos um pouco mais avançados
SQL BÁSICO
75
DEFINIÇÕES DE DADOS E TIPOS EM SQL
Na unidade anterior, definimos os termos relação, tupla e atributo do modelo

relacional. Em SQL, esses 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 autori-
zar 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 comando é o nome da tabela sendo criada, seguido dos atributos
e de seus respectivos tipos e eventuais restrições do atributo. Restrições de inte-
gridade referencial podem ser definidas ao final do comando.
Definições de Dados e Tipos em SQL

76 UNIDADE III
contato
id nome sobrenome nascimento peso
email
id email contato_fk
telefone
id telefone contato_fk
grupo afiliação
id nome grupo_fk contato_fk
Figura 31: Exemplo da estrutura de Tabelas e seus respectivos atributos

Fonte: os autores.
Os seguintes comandos criam as tabelas definidas na Figura 31:

CREATE TABLE contato (
id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL,
sobrenome VARCHAR(30) NOT NULL,
nascimento DATE,
peso DECIMAL(10,2)
);
SQL BÁSICO
77
CREATE TABLE email (
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
CREATE TABLE telefone (
id INT PRIMARY KEY,

telefone VARCHAR(20) NOT NULL,
contato_fk INT,

);
CREATE TABLE grupo (
id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL
);
CREATE TABLE afiliacao (
grupo_fk INT NOT NULL,
contato_fk INT NOT NULL,
PRIMARY KEY (grupo_fk, contato_fk),
FOREIGN KEY (grupo_fk) REFERENCES grupo(id),
);
Em algumas situações, não é possível definir as restrições de integridade referen-

cial e chave estrangeira no próprio CREATE TABLE, pois as tabelas referenciadas
ainda não existem. Na próxima unidade, abordaremos como resolver esse impasse.
Definições de Dados e Tipos em SQL

78 UNIDADE III
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 supor-
tado, mas todos os produtos disponíveis no mercado suportam ao menos estes
tipos básicos:
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
TIPOS NUMÉRICOS em cálculos de moeda, por exemplo) são DECIMAL
ou NUMERIC, declarados como DECIMAL(a,b) ou
NUMERIC(a,b), em que “a” é o número de dígitos inteiros e
“b” é o número de dígitos decimais.
Tipos de caractere podem ser de tamanho fixo ou variável.
Os atributos de tamanho fixo podem ser declarados como
CHAR(n), em que “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, é neces-
sário entender como é a alocação de espaço desses tipos
TIPOS CARACTERE no arquivo físico. Se o tamanho for fixo (CHAR), o SGBD já
aloca esse tamanho predefinido no arquivo: as buscas po-
dem 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.
Assim como em linguagens de programação, tipos boo-
leanos podem assumir os valores TRUE ou FALSE. Muitos
TIPOS BOOLEANOS
SGBDs mapeiam esses valores em “1” e “0”, respectivamen-
te.
O tipo DATE suporta dados temporais no formato AAAA-
-MM-DD (ano, mês, dia), enquanto que o tipo TIME utiliza
TIPOS TEMPORAIS
o formato HH:MM:SS (hora, minuto e segundo). A própria
SQL assegura representações temporais válidas.
SQL BÁSICO
79
RESTRIÇÕES
Seguindo o nosso planejamento, abordaremos agora, as restrições que podem ser

declaradas em SQL no comando CREATE TABLE. Restrições adicionais especi-
ficadas 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 per-
mite que um atributo seja nulo, é necessário especificar uma restrição de NOT
NULL na declaração do atributo.
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, primeira-
mente, 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 esse 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 per-
mitirã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:
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)
);
Restrições
80 UNIDADE III
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 a seguir ):
PRIMARY KEY (grupo_fk, contato_fk)
A cláusula UNIQUE especifica chaves únicas (não primárias) em uma tabela.

Poderíamos alterar a definição da tabela email para garantir que não haja e-mails
duplicados em nossa aplicação:
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL UNIQUE,
contato_fk INT,
);
Já a integridade referencial e as chaves estrangeiras são definidas por meio da

cláusula FOREIGN KEY, como utilizada já no nosso exemplo nas tabelas email
e telefone:
SQL BÁSICO
81
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL,
contato_fk INT,
);
CREATE TABLE telefone (

id INT PRIMARY KEY,
telefone VARCHAR(20) NOT NULL,
contato_fk INT,
);
CONSULTAS 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 esse comando variam das mais simples
até as bem complicadas. Em sua forma fundamental, um comando de con-
sulta 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 em 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.
Consultas Básicas em SQL

82 UNIDADE III
3. A cláusula WHERE corresponde ao predicado envolvendo os atributos

das relações que aparecem na cláusula FROM.
As condições do comando SQL podem utilizar comparadores lógicos simila-

res 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 exem-
plos. Ao invés de nos atermos aos detalhes sintáticos e conceituais de cada tipo
de consulta, apresentaremos exemplos de como as consultas a seguir.
Todos os exemplos de consulta serão realizados tendo-se como base a defi-
nição de esquema proposta na Figura 6 .
Exemplo 1: Selecione o nome e o telefone de todos os contatos cujo sobre-
nome seja ‘Silva’.
SELECT nome, telefone FROM contato, telefone WHERE contato.id = tele-
fone.contato_fk AND contato.sobrenome = ‘Silva’;
Nesse exemplo, a condição contato.sobrenome = ‘Silva’ é um predicado que sele-

ciona 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, nesse caso, em uma chave estrangeira de um rela-
cionamento 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.con-
tato_fk AND contato.nome = ‘Edson’;
SQL BÁSICO
83
Nesse exemplo, pode-se notar que em uma consulta é permitido realizar o join
entre várias tabelas diferentes, e, novamente nesse caso, todas estão relaciona-
das por meio de uma condição de combinação baseada em chaves estrangeiras.
Exemplo 3: Selecione o id do telefone de todos os contatos cujo peso seja
maior que 70.
SELECT telefone.id
FROM contato, telefone
WHERE telefone.contato_fk = contato.id

AND contato.peso >70
O Exemplo 3 mostra como devemos definir os nomes dos atributos nas cláusu-
las 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”. Nesse 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 dessa consulta, não precisamos mais nos referenciar
a esses atributos pela referência completa, torna-se possível, então, simplesmente

84 UNIDADE III
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.
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 isso é oportuno ou não, já
que, potencialmente, a quantidade de registros em uma tabela pode chegar aos
milhões ou bilhões. Quando a cláusula WHERE é omitida, a consulta irá proces-
sar 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
SQL BÁSICO
85
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, mate-
maticamente, em conjuntos não hajam elementos repetidos, permite-se elementos
repetidos em tabelas e, consequentemente, nos resultados das consultas, esses ele-

mentos 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.
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. Nesse 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_-__-__’;
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
86 UNIDADE III
‘_’ 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.
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 adicio-
nar 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.
SQL BÁSICO
87
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. Neste tópico, abordaremos
os comandos da SQL que permitem a adição, a atualização e a remoção de tuplas
(linhas), que respectivamente correspondem ao INSERT, UPDATE e DELETE.
Abordaremos cada um deles a seguir
O comando INSERT
O comando INSERT é utilizado para inserir linhas em uma 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. Essa 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:
Comandos de Modificação de Dados em SQL

88 UNIDADE III
INSERT INTO contato
VALUES (10, ‘Edson’, ‘Yanaga’, ‘1978-04-12’, 95);
Nesse 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, de integridade nula e de integridade referencial.
INSERT INTO contato (nome, sobrenome, peso, nascimento, id)
VALUES (‘Edson’, ‘Yanaga’, 95, ‘1978-04-12’, 10);
Nessa 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 de o comando tornar-se inválido
provavelmente provocaria um erro da aplicação em tempo de execução, já que
esse tipo de bug não pode ser identificado pelo compilador.
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 esses dados provenientes do comando SELECT:
SQL BÁSICO
89
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. Nesse 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, o comando UPDATE só
pode ser aplicado em uma única tabela. Caso seja necessário modificar os valo-
res 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.
UPDATE contato
SET peso = 99, nascimento = ‘1982-04-25’
WHERE nome = ‘Carlos’;
Nesse exemplo do comando UPDATE, estamos modificando o valor de dois atri-

butos das tuplas cujo nome = ‘Carlos’. É uma prática bastante comum executarmos

90 UNIDADE III
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. Nesse caso, todas as linhas da tabela informada serão sele-
cionadas 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. Nesse 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 permitam.
Assim como o comando INSERT – vale lembrar que todas as restrições do
schema que se aplicam ao comando INSERT também são válidas para o comando
UPDATE.
O comando DELETE
O comando DELETE na SQL remove linhas de uma determinada tabela. Assim
como os comandos INSERT e UPDATE, ele 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.
SQL BÁSICO
91
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;
Cezar Taurion, da IBM, fala das vantagens da computação em nuvem

Disponível em: <http://youtu.be/HJre77TPpSw>. Acesso em: 8 jul. 2015.
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;
Em um caso extremo, esse exemplo resultaria em uma tabela contato vazia.

Entretanto como nas operações de DELETE, as restrições de integridade refe-
rencial são verificadas, esse comando falharia com um erro caso alguma outra
tabela (telefone, por exemplo) tivesse alguma chave estrangeira apontando para
uma linha da tabela contato.

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 desses bancos de dados NoSQL não relacionais:
as cinco principais vantagens e os cinco desafios.
Cinco vantagens do NoSQL
1. Escalabilidade elá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 servido-
res à medida que a carga aumenta. Entretanto à medida que os requisitos de carga de
transações e disponibilidade aumentam e os bancos 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 ge-
ração de banco de dados NoSQL é projetada para expandir-se transparentemente de
modo a tirar proveito de novos nós, e normalmente o banco de dados NoSQL é conce-
bido 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 vo-
lume de dados que está sendo armazenado também cresceu massivamente. O’Reilly
chamou isso de “revolução industrial dos dados”. A capacidade dos SGBDRs tem crescido
para se equiparar a esses 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
93
caros e altamente treinados DBAs. DBAs estão intimamente envolvidos no projeto, ins-
talação e otimização de sistemas baseados em SGBDRs.
Bancos de dados NoSQL são normalmente concebidos para requerer menos gerencia-
mento: 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 exagerados. Al-
gué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 geren-
ciar a explosão no volume de transações e dados, enquanto que SGBDRs tendem a de-
pender 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 per-
mitem que a aplicação virtualmente armazene qualquer estrutura em um 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 no-
vas 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, isso 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 geren-
ciar 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 conser-
vadoras. A seguir, listamos alguns dos principais desafios.
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 com-
petente com um tempo de resposta aceitável. Todos os fornecedores de SGBDRs traba-
lham bastante para conseguir fornecer um elevado nível de suporte corporativo.
Em contraste, muitos sistemas NoSQL são projetos open-source e, embora existam mui-
tas empresas oferecendo suporte a banco de dados NoSQL, essas empresas normal-
mente são pequenas startups sem o alcance global, recursos de suporte ou credibilida-
de de empresas como Oracle, Microsoft ou IBM.
3. Business Intelligence e Business Analytics

Banco de bancos NoSQL evoluíram para atender à demanda de escala de modernas
aplicações Web 2.0. Consequentemente, a maioria de suas funcionalidades está relacio-
nada às demandas dessas 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 forne-
cer um fácil acesso a dados em clusters Hadoop e eventualmente a 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.
95
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 é essa. 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 a programa-
ção em SGBDRs. Em contraste, praticamente todo desenvolver NoSQL ainda está em
processo de aprendizado. Essa situação será resolvida naturalmente com o passar do
tempo, mas, por enquanto, é muito mais fácil encontrar programadores ou administra-
dores 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 banco de dados e, quando utilizados de modo apropriado, podem oferecer bene-
fícios reais. Entretanto empresas devem proceder com cautela com total consciência das
limitações e problemas que estão associados com esses bancos de dados.
Guy Harrison é o diretor de pesquisa e desenvolvimento da Quest Software. Um reco-
nhecido 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 sof-
tware. 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: Harrison (2010, online).
Blog do Cezar Taurion, Evangelista da IBM no Brasil e especialista em BigData

e Cloud Computing:
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctau-
rion/?lang=pt_br>.
96 UNIDADE III
Finalizada a leitura desta unidade, já temos a convicção de que você, como pro-
fissional comprometido(a) e fluente em inglês (sim, na área de Tecnologia da
Informação, inglês é obrigatório e deveria ser o idioma principal), já abordará
seus(suas) colegas, alunos(as) e profissionais, falando “síquel” ao invés do fami-
gerado “esse-quê-ele”, quando se referir à linguagem SQL.
Como toda tecnologia e assunto novo, SQL exige prática para o domínio.
Acreditamos 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 esta unidade, pudemos estudar a for-
maçã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 abs-
trações reais do mundo que o cerca, exercite-se e execute consultas e comandos
de modificação SQL nesses seus schemas! Com a prática cotidiana, você perce-
berá 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 dessa popular linguagem.
SQL BÁSICO
97
Todas as atividades de autoestudo desta unidade baseiam-se na

figura abaixo.
aluno
id nome sobrenome ra email
professor
id nome sobrenome titulação
curso matrícula
id nome ano curso_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.
2. Elabore consultas SQL para selecionar:
a. O nome de todos os alunos matriculados no curso com
nome = ‘Banco de Dados’.
b. A titulação do professor da disciplina com nome = ‘SQL’.
c. O Nome, sobrenome e RA de todos os alunos matriculados
nas disciplinas lecionadas pelo professor com nome ‘Edson’.
d. Todos os atributos de todos os cursos com ano > 1990.
3. Elabore comandos de modificação de dados para incluir, mo-
dificar e remover linhas das diferentes tabelas desse schema.
IV
UNIDADE
MAIS SQL
■■ Definir consultas complexas em SQL.
■■ Apresentar os comandos de alteração de definições em SQL.
Plano de Estudo
■■ Consultas envolvendo NULL
■■ Consultas aninhadas (subqueries)
■■ Consultas utilizando joins
■■ Consultas com funções de agregação
■■ Comandos de alteração de schema
101
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 signi-
fica 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 relacio-
nais, que é justamente a capacidade de se executar essas consultas um pouco
mais complexas e sofisticadas.

Quando citamos essas 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 essa definição em mente que apresentaremos nesta unidade uma grande
variedade de exemplos que podem ser solucionados com essas consultas mais
elaboradas da SQL.
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.
Introdução
102 UNIDADE IV
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 uni-
dade III, 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 arma-
zenado, setando o valor NULL para representá-lo.
■■ O valor não é aplicável. Caso algum contato não tenha telefone, certa-
mente não faz sentido querer armazenar essa 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 valo-
res 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 em um terceiro valor, que é representado por NULL. Esse terceiro
valor pode ser checado de um modo especial com os operadores SQL defini-
dos, 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 simples-
mente são descartadas (com exceção da operação de OUTER JOIN, que veremos
mais adiante nesta unidade).
Comecemos com alguns exemplos ainda baseados no schema apresentado
na unidade III.
Exemplo 1: Selecione todos os contatos que não possuem data de nasci-
mento definida.
MAIS SQL
103
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 bus-

car primeiramente alguns valores das tabelas e utilizá-los posteriormente em
nossa consulta. Essas consultas diferenciadas podem ser formuladas com 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’;
Consultas Aninhadas (Subqueries)

104 UNIDADE IV
A consulta acima foi criada utilizando-se um join normal. Agora, no exemplo

abaixo, a reescreveremos utilizando uma subquery.
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ên-
cia 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, essa diferença hoje é prati-
camente nula: todos os SGBDs modificam internamente as consultas fornecidas
e automaticamente já escolhem o melhor plano de execução. Isso faz 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ível .
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ên-
teses, 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, o
operador IN continua equivalente. É por esse motivo que muitos programadores
MAIS SQL
105
acabam adotando a convenção de se utilizar o operador IN em todas as consul-

tas que envolvem subqueries.
Considere nos exemplos a partir de agora o seguinte schema representado
pela Figura 32:
funcionário
id nome sobrenome cargo
subordinado
id nome sobrenome superior_fk
Figura 32: Exemplo das tabelas Funcionário e Subordinado

Fonte: os autores.
O schema da Figura 32 pode ser construído da seguinte forma:
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)
);
Consultas Aninhadas (Subqueries)

106 UNIDADE IV
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:
FROM funcionario AS f
WHERE id IN(
SELECT superior_fk
FROM subordinado AS s
WHERE f.nome = s.nome
);
Esse exemplo reescrito com uma subquery é um caso especial de consulta ani-
nhada em SQL, pois, como pode notar, a subquery utiliza atributos da consulta
externa em sua cláusula WHERE. Chamamos esse caso especial de consultas
aninhadas correlacionadas.
WHERE EXISTS (
SELECT *
WHERE f.nome = s.nome
);
MAIS SQL
107
Apresentamos a mesma consulta do exemplo reescrito acima com um novo ope-

rador denominado de EXISTS. Esse 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.
WHERE NOT EXISTS (
SELECT *
WHERE s.superior_fk = f.id
);
A exemplo do operador EXISTS, o operador NOT EXISTS retorna o oposto do

operador EXISTS, sendo falso (FALSE), se o resultado possui ao menos uma
linha, e verdadeiro (TRUE), se o resultado for vazio.
CONSULTAS UTILIZANDO JOINS
Na unidade III, 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 III em nossos exemplos
a seguir.
Consultas Utilizando Joins

108 UNIDADE IV
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 essa mesma consulta reescrita com um JOIN:

SELECT nome
FROM (contato JOIN telefone ON contato.id = telefone.contato_fk)
WHERE telefone.telefone LIKE ‘44%’;
Nesse 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áu-
sula 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 abaixo:
TIPO DE JOIN SEMÂNTICA

É o tipo de JOIN padrão. Somente tuplas que satisfa-
INNER JOIN
çam a condição do JOIN são selecionadas.
Todas as tuplas da tabela do lado esquerdo do ON são
LEFT OUTER JOIN ou selecionadas. Caso não haja uma tupla corresponden-
LEFT JOIN te, na tabela do lado direito do JOIN, os valores são
preenchidos com NULL.
É a condição inversa do LEFT JOIN. Todas as tuplas da
tabela do lado direito do ON são selecionadas. Caso
RIGHT OUTER JOIN ou
não haja uma tupla correspondente na tabela do lado
RIGHT JOIN
esquerdo do JOIN, os valores são preenchidos com
NULL.
Todas as tuplas dos dois lados do JOIN são seleciona-
FULL OUTER JOIN ou
das. Caso não haja correspondência na condição do
FULL JOIN
JOIN, o lado vazio é preenchido com NULL.
MAIS SQL
109
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.
CONSULTAS COM FUNÇÕES DE AGREGAÇÃO
Uma das grandes vantagens da SQL e dos bancos de dados relacionais, se compa-
rados com outras alternativas não relacionais, são as suas funções de agregação.
Essas 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 conta-
gem, 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. Nesse exemplo, é o caso do atributo peso.

110 UNIDADE IV
Exemplo 9: Selecione o número total de contatos cujo peso > 80;
SELECT COUNT(*)
FROM contato
WHERE peso > 80;
Nesse 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;
Nesse exemplo, contamos a quantidade de pesos distintos de nossos contatos.

Caso a cláusula DISTINCT não fosse aplicada, contaríamos somente a quanti-
dade 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 – sepa-
rados dentro da tabela, baseados em um determinado valor. Para conseguir esse
objetivo em SQL, utilizamos a cláusula GROUP BY. Ao utilizarmos o GROUP
BY, separamos as tuplas em grupos distintos em que todas as 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.
MAIS SQL
111
SELECT sobrenome, COUNT(*)
FROM contato
GROUP by sobrenome;
Na avaliação dessa 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 conta-

tos com cada sobrenome.
Exemplo 12: Selecione o sobrenome e a quantidade de contatos que pos-
suem 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 apenas alguns desses grupos no resultado – e não todos. A cláu-
sula 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 selecio-
nados 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 forma-
dos e serve, então, para filtrar esses grupos do resultado final.

112 UNIDADE IV
COMANDOS DE ALTERAÇÃO DE SCHEMA
Nós definimos como schema evolution o processo de alterações da estrutura do

schema. Normalmente essas alterações de estrutura não são frequentes e são
motivadas por alterações dos requisitos do negócio e, consequentemente, tam-
bé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 res-
trições. Vamos abordá-los nos exemplos seguintes.
Exemplo 13: Remova o schema agenda do banco de dados.
DROP SCHEMA agenda;
Esse comando remove o schema e, por consequência, todas as tabelas dentro do

schema. Há certa controvérsia nesse 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.
Exemplo 14: Remova a tabela telefone do schema.
DROP TABLE telefone;
Nesse exemplo, a tabela telefone seria removida do schema. É importante notar

que a tabela sendo removida do schema pode conter dependências de integri-
dade referencial e chave estrangeira em outras tabelas. Nesse caso, se alguma
outra tabela depender da tabela removida, esse comando irá falhar devido à res-
trição de integridade referencial do banco, sendo necessário primeiro remover
à integridade referencial.
MAIS SQL
113
Exemplo 15: Adicione uma coluna apelido na tabela contato contendo 15

caracteres.
ALTER TABLE contato ADD COLUMN apelido VARCHAR(15);
Esse 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 que está 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.
Exemplo 18: Remova a coluna apelido da tabela contato.
ALTER TABLE contato DROP COLUMN apelido;
Comandos de Alteração de Schema

114 UNIDADE IV
A coluna apelido é removida da tabela contato desde que não haja nenhuma res-
trição de integridade referencial nessa 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);
Esse comando adiciona a restrição de integridade referecial entre a tabela tele-
fone 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 essa solução como uma sugestão de estudo para você.
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.
Disponível em: <http://youtu.be/S2iQ2RKMw-w>. Acesso em: 8 jul. 2015.
MAIS SQL
115
NOSQL, SEM PROBLEMAS

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 dessa á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 pen-
samento ou uma tecnologia particular. Mesmo o nome é confuso, pois, para alguns, isso
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 que perca
o sentido e subdivisões tornem-se necessárias para clarificar o significado do termo.
O que é NoSQL?
O movimento NoSQL é um pedaço de um marketing de guerrilha que traz um grande
grupo de tecnólogos e tecnologias sob a mesma bandeira. As ideias que baseiam a infi-
nidade de solução que existe sob o termo “NoSQL” antes estavam somente disponíveis
para aqueles cujas necessidades tornaram necessária uma implementação própria e es-
pecífica. Nas áreas em que essas soluções são uma necessidade, seu valor já foi provado,
e agora o uso dessas 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 é muito cedo para fornecer uma resposta decisiva e definitiva, mas está claro que
muitas organizações podem se beneficiar de um modelo de dados que se encaixe me-
lhor nos tipos de armazenamento e consulta que eles executam na prática do que na te-
oria. 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 ne-
gó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á o sucesso do fracasso em sua adoção.
Assim como o NoSQL apresenta novos desafios, ele também oferece recompensas sig-
nificativas àqueles que o incorporam com sucesso no seu portfólio de solução. Os prin-
cipais 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ís-
ticas 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 indispo-
nibilidade.
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 essas propriedades, mas a maioria
dos bancos de dados que discutiremos suporta boa parte dessas 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 planejamen-
to, escala e provisionamento que tornou-se crítico para muitos negócios na Web nos úl-
timos 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 popula-
ridade 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 proble-
mas 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 equi-
librados 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
117
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 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) tor-
na-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 invali-
da esse 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 impos-
sível comprar o hardware e as licenças de software para atender à demanda de pico por
meio de um único servidor. Esses 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 de se o valor for menor ou maior que 10 ou que “padaria”, na verdade, sig-
nifica “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 so-
lução impediu muitas empresas que não tinham esses problemas no coração de seus
negócios de explorar essa 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ódigos 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 por meio
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 utili-
zando NoSQL. 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 so-
lução NoSQL. A área é nova o suficiente para que muitos negócios sintam-se desconfor-
táveis executando trabalho crítico em qualquer outro software que não seja um maduro
banco de dados relacional, mesmo que esses 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 di-
fíceis de 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 meca-
nismo de armazenamento de dados.
A seguir, estão alguns casos de uso em que é ótimo utilizar um banco de dados relacio-
nal:
• 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 despro-
porcionalmente em relação aos dados sendo mantidos. Informalmente, se você não
consegue mais imprimir o seu DER em um papel A3, você deve ter alcançado esse
problema ou você está armazenando muita coisa em um ú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á desnormalizado 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 esse tipo de interaçã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.
119
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 vezes deturpado por implementações customizadas. A SQL possui mui-
tas vantagens de que os produtos NoSQL terão que tratar ao longo do tempo. Primeira-
mente, 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 produ-
zem consultas SQL complexas certamente reclamarão se tiverem que replicar operado-
res como SUM, ORDER BY e GROUP em uma tarefa do tipo map-reduce em JavaScript.
Mesmo os fornecedores reconhecem esse problema. Se eles não forem capazes de en-
contrar um conjunto comum de operações de manipulação de dados, então é provável
que outra implementação torne-se popular e seus usuários migrarão para esse outro
produto. Ou todos os fornecedores terão que implementar o mesmo conjunto de co-
mandos 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 documen-
tos 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 cha-
ve-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, esse 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 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 com-
ponentes. Nessa situação, é mais fácil identificar áreas que se beneficiariam da solução
NoSQL e implementar essa integração aos poucos. Na situação em que o armazenamen-
to de dados é monolítico e que os sistemas dependem de certas propriedades do mo-
delo relacional – por exemplo, tipos de dados ou consistência transacional – 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 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
consultar as intersecções desses relacionamentos, mas expressar somente os relaciona-
mentos em um banco de dados de grafos é uma solução muito mais simples.
Existem algumas áreas óbvias em que o NoSQL pode ser aplicado imediatamente. Con-
teúdo de websistes pode ser geralmente expresso em bancos de dados de documentos
ou de chave-valor. Exemplos particulares dessas situações são as metáforas de formu-
lá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 esses 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

Abaixo há a descrição dos 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ê esses dados baseada em uma chave que é o id
do usuário e recupera uma String JSON que representa todas essas informações. Um
processo em background recalcula essa 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.
121
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 re-
fugiadas 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ân-
cias 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 dessas informações com ceticismo.
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 can-
didata a um banco de dados de grafos. Esse mesmo princípio pode ser estendido a qual-
quer 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 finali-
zados 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 con-
teúdo (artigos, comentários, perfis de autores etc.) pode ser votado e pode ter um co-
mentá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 (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. Duran-
te a noite, um processo batch identifica em quais conteúdos os usuários votaram e você
gera uma lista de conteúdo que possui muitos votos para cada usuário, mas que os usu-
ários ainda não votaram. Essa lista é uma lista de artigos recomendados para o usuário e
fica armazenada no “bucket” de recomendações.
Banco de dados de objetos

Exemplos: Oracle Coherence, db4o, ObjectStore, GemStone e Polar.
Aplicações Típicas: Sistemas financeiros.
Pontos Fortes: Reflete o paradigma de desenvolvimento orientado a objetos, baixa la-
tência ACID e 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ão e Nova York e verificá-las por meio de um processo de análise de risco
em Londres. Um objeto representando a transação é gravado no banco de dados de
objetos e o analisador de riscos está aguardando pelas notificações de objetos de tran-
sações. Quando um objeto é replicado no datacenter europeu, o analisador de riscos lê
a transação e verifica o risco da mesma. Ele então reescreve o objeto para informar que
a transação foi autorizada e gera uma venda. O cliente está aguardando por mudanças
nos objetos e recebe uma notificação de que a sua transação foi aprovada.
123
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 diferen-
te sobre os dados e é uma possibilidade extremamente excitante.
Fonte: adaptado de Rees (2010, online).

124 UNIDADE IV
Finalmente, chegamos ao fim de nossa unidade. Nesse ponto, você provavel-

mente já terá assimilado conteúdo suficiente para poder 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 de que todo problema pode ser decomposto em partes menores
de fácil solução. Utilize essa técnica e aplique os conceitos assimilados com os
exemplos apresentados nesta unidade para resolvê-los. A teoria é importantís-
sima, mas a prática é uma atividade fundamental para que você possa converter
toda essa 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 cari-
nho e tenha um bom proveito.
MAIS SQL
125
Todas as atividades de autoestudo desta unidade baseiam-se na figura abaixo.
beneficiário
id nome sobrenome altura plano_fk
dependente
id nome sobrenome beneficiário_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.
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 a 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.
V
UNIDADE
ESTUDO DE CASO
■■ Demonstrar ao aluno a prática na criação de um Banco de dados.
Plano de Estudo
■■ Descrevendo o Estudo de Caso
■■ Criando as Entidades e os Relacionamentos (DER)
■■ Trabalhando com SQL
129
INTRODUÇÃO
Caro(a) aluno(a), até o momento estudamos os conceitos de Bancos de dados,

englobando alguns assuntos como: SGDBS (Sistemas Gerenciadores de Banco
de Dados), em que vimos os tipos existentes e como funcionam; vimos também
a Teoria Relacional, em que englobamos toda análise de como iniciar a criação
de um banco de dados e seus respectivos relacionamentos; aprendemos tam-
bém a respeito de SQL (Structured Query Language) tanto os tipos DML (Data
Manipulation Language) como DDL (Data Definition Language), sendo esses
conceitos imprescindíveis para a implementação prática de Bancos de dados

Relacionais.
Em nossa disciplina de Banco de Dados, saber a respeito dos conceitos é
muito importante, porém, para uma melhor aplicabilidade da disciplina, temos
que fazer que essa teoria estudada seja concretizada e a melhor maneira de fazer
isso é realizando as atividades de maneira prática.
Nesta unidade, teremos como objetivo principal o estudo e a demonstração
prática de tudo que fora aprendido nas unidades anteriores. Espero que você
tenha esta unidade como um auxiliador no processo de criação de um projeto
de banco de dados, podendo realizar consultas constantes.
Introdução
9 ÁREAS DA TECNOLOGIA COM CARREIRAS PROMISSORAS (E COMO
APROVEITÁ-LAS)
Trabalhar com tecnologia vai muito além do que estamos acostumados a imaginar. Não
são somente as empresas que trabalham com esse segmento do mercado que preci-
sam dela e por isso é importante saber que excelentes vagas podem estar onde menos
imaginamos. Por exemplo: grandes instituições bancárias precisam de especialistas em
construção de sistemas digitais e segurança avançada e isso exige profissionais qualifi-
cados.
Mas não são apenas os bancos que precisam desses trabalhadores, praticamente qual-
quer empresa que trabalha com informações e isso também cria um mercado em ascen-
são. Quer saber quais outras habilidades podem fazer sua carreira decolar? Então confira
agora mesmo a seleção que trouxemos com os principais segmentos da tecnologia para
quem quer ter bons salários.
1. Programação ainda em alta

Assim como aconteceu no ano anterior, em 2014 grande parte das empresas de tec-
nologia disseram que estão em busca de bons programadores e desenvolvedores de
aplicações. De acordo com pesquisas realizadas nos Estados Unidos, 48% das empresas
ligadas a esse mercado planejam abrir novas vagas em 2015, sendo que nem todas elas
serão preenchidas tão rapidamente.
Diversas empresas enfrentam dificuldades para encontrar colaboradores com as habili-
dades desejadas para certos projetos. Segundo o VentureBeat, uma das linguagens que
mais vem sendo procurada atualmente é a R (uma linguagem voltada para objetos). Há
cargos desse tipo que ultrapassam a faixa dos R$ 350 mil anuais, sendo que pessoas com
mais experiência em gerenciamento podem ir ainda além.
2. Gerenciamento de banco de dados

O termo RDBMS significa “Relational Database Management System” (Sistema de Geren-
ciamento de Bancos de Dados Relacionados). O trabalhador é mais conhecido em todo
o mundo pela redução ao “Database”, que exige amplos conhecimentos em sistemas
de bancos de dados — como Oracle, Microsoft SQL Server ou IBM DB2. Há mais de mil
vagas desse tipo nos EUA e a média salarial é de US$ 365 mil ao ano.
Administrar bancos de dados não é uma tarefa fácil, mas rentável. Mais de 25% das com-
panhias de tecnologia dos Estados Unidos estão em busca de gerentes para database.
Mais do que isso, no ano passado, um estudo da Robert Half Technology apontava para
um número bem impressionante: 52% dos executivos de TI dizem que conhecimentos
no assunto são vitais para os melhores empregos.
131
3. Gerenciamento de projetos
Um bom gerente de projetos precisa ter conhecimentos amplos no mercado de negó-
cios e de tecnologia. Essa exigência acaba excluindo muitos concorrentes das melhores
vagas, pois é difícil encontrar quem tenha experiência nesse quesito. Alguns executivos
afirmam que compreendem o aumento da demanda por causa de necessidades cada
vez mais específicas.
Há empresas que precisam de gerentes de projetos com metodologias Agile e outras
com Waterfall. É quase impossível encontrar quem domine perfeitamente os dois con-
ceitos e ainda consiga aplicar isso ao mundo Tech. Não é à toa que bons trabalhadores
nessa área conseguem ganhar mais de R$ 300 mil por ano — sem contar os grandes
ganhos em consultoria.
4. Suporte técnico de novas ferramentas

Colaboradores para suporte técnico já foram mais requisitados, mas ainda fazem parte
de um grande volume de vagas de emprego em todo o mundo. Mas é preciso ter em
mente que isso não significa apenas trabalhar com assistência para resolver problemas
genéricos de máquinas e periféricos. O mercado de suporte vai muito além do que esta-
mos acostumados a imaginar. Em resumo: é preciso renovação.
Como já dissemos, o mercado de tecnologia está cada vez mais fragmentado — em
questão de linguagens, métodos e mesmo hardware. Com isso, torna-se mais necessária
a especialização em determinados campos, uma vez que grandes empresas trabalham
cada vez com mais tipos de equipamentos. Por essa razão, ter capacidades de suporte
para novas ferramentas pode ser um grande diferencial no mercado.
5. Governança de segurança
Com sistemas baseados em computadores e grandes volumes de dados circulando a
todo instante, não há como imaginar uma empresa que não invista em segurança digi-
tal. A quantidade de dinheiro que pode ser perdida em vazamentos e invasões faz valer
a injeção de dinheiro e grandes empresas têm sido prova disso. Como o Computer World
lembra, a HMS dos EUA triplicou a equipe de segurança digital nos últimos cinco anos.
Mais do que apenas localizar bugs e neutralizar ameaças, há também uma exigência
cada vez maior por pessoas que saibam lidar com as situações de crise. A mesma HMS
afirma que sempre está em busca de especialistas que sejam capazes de gerenciar as
situações de incidentes, pois esse é um grande diferencial atualmente. Ou seja, bons
trabalhadores na área de segurança não ficarão desempregados.
6. Desenvolvimento para a Web
Muitos desenvolvedores conseguiram crescer no mercado offline, mas em relação ao
desenvolvimento web, os números ainda são menos impressionantes. Existe uma gran-
de demanda por pessoas com habilidades em diversos tipos de aplicação e isso reflete
no aumento das ofertas salariais. Como mostra o VentureBeat, isso também anda junto
com a Computação em Nuvens.
Muitas das empresas que vendem tecnologia nos Estados Unidos estão investindo pe-
sado em plataformas PaaS (Plataforma como um Serviço, em português). Trata-se de um
sistema de computação em nuvens, que leva os desenvolvedores a programarem dire-
tamente na nuvem, sendo que ele fica disponível no mesmo local. Há empregos nessa
área nos EUA que pagam mais de R$ 400 mil ao ano.
7. Mobile: crescimento constante

Como você já sabe, os portáteis fazem cada dia mais parte da vida dos consumidores e
aos poucos eles vão tomando o lugar dos computadores em nível de importância. Logo,
as empresas de tecnologia também estão se adaptando a essas novas demandas e já
buscam desenvolvedores e especialistas em segurança que consigam criar bons siste-
mas voltados aos dispositivos Mobile.
A criação de ferramentas que permitam o controle de sistemas por meio de smartpho-
nes e tablets é um grande desafio e quem souber fazer isso com qualidade, certamente
será recompensado. Algumas das linguagens em que isso será evidenciado em breve
são ABAP (Advanced Business Application Programming) e Cassandra (database de alto
volume voltado às nuvens).
8. Big Data
Esse termo se refere à grande quantidade de informações e à demanda por velocidade
no atendimento às requisições. As empresas precisam entregar dados e precisam fazer
isso na hora que os consumidores exigem. Vagas de emprego relacionadas à “Big Data”
aumentam todos os anos e o motivo para isso é bem claro: cada dia existem mais pes-
soas conectadas à internet e as conexões mais velozes fazem que a demanda por dados
cresça ainda mais.
Mas não basta saber como isso acontece para prosperar no mercado, pois é preciso
saber como fazer tudo funcionar corretamente. Por isso, o domínio de sistemas como
Sqoop vem sendo cada vez mais exigido pelos empregadores. A já mencionada pro-
gramação em R também diz respeito a amplos volumes de transmissão, assim como o
gerenciamento de databases.
Por causa do crescimento do Big Data, o profissional “analista de dados” voltou a ser
133
valorizado sob o nome de “cientista de dados” — sendo exigido um bom conhecimento

para transformar “números e informações em dados relevantes”. Outro cargo bem valo-
rizado nesse segmento é o dos “Arquitetos de Informação” — responsáveis pelo design
dos sistemas de TI para o armazenamento e acesso dinâmico ao que for requisitado.
9. Computação em nuvens
Apesar de a computação em nuvens estar presente em quase tudo o que falamos ante-
riormente, é importante falar sobre ela em separado. Atualmente, muitas informações
passam a ser colocadas em servidores externos para facilitar o acesso de consumidores
e clientes, ao mesmo tempo em que isso pode tornar sistemas mais seguros — depen-
dendo da contratação de cada serviço, é claro.
Hoje, alguns dos grandes serviços e gerenciadores de Cloud Computing podem ser aces-
sados por qualquer pessoa por serem opensource — como o CloudStack, OpenStack e
a aclamada Hadoop. Mas também há algumas plataformas fechadas, como a NoSQL e a
Cloudera (uma versão mais comercial do Hadoop). Além de fazer o controle dos dados
entre nuvem e cliente, esses serviços também podem ser usados para uma série de so-
luções de segurança digital. Vale a pena investir!
.....
Como você pôde perceber, existem muitos conhecimentos que podem ser alimentados
para que uma carreira de sucesso seja construída. É claro que você não precisa saber
tudo o que foi mencionado aqui para conseguir um emprego, mas vale a pena ir atrás
de novas ferramentas nas áreas em que você deseja trabalhar. Isso certamente fará dife-
rença na hora de enviar o seu currículo.
Você já sabe em que área pretende trabalhar? A tecnologia pode ser uma aliada na hora
de fazer que seu trabalho se transforme em uma carreira? Esperamos que as dicas que
trouxemos hoje possam ajudar você nessa guinada.
Fonte: Hamann (2015, online).

134 UNIDADE V
No link abaixo, você terá mais informações sobre o gerenciador de banco de

dados POSTGRE, neste link, teremos incluída toda a documentação, infor-
mações de eventos, downloads e muitas outras informações:
Fonte: PostgreSQL (online). Disponível em: <http://www.postgresql.org.br>.
Acesso em: 8 jul. 2015.
DESCREVENDO O ESTUDO DE CASO
A empresa TOP UNIFORMES deseja um sistema que gerencie as vendas da

empresa. Nestas vendas, seria importante termos o controle dos clientes que
compraram, um controle de produtos com seus respectivos preços e também
um controle de vendedores para que seja possível a distribuição da comissão.
Restrições e premissas:
■■ Uma Venda pode ter apenas um Cliente.
■■ Uma Venda pode ter apenas um Vendedor.
■■ Uma Venda pode ter vários itens, porém, esses itens podem ter apenas
um produto cada.
■■ Não teremos cadastros de Empresas, pois não temos Filiais.
Vamos analisar o Estudo de Caso:

O passo inicial que podemos tomar é a análise dos substantivos, no estudo
de caso, conforme vimos na unidade II. Vamos à análise:
A empresa TOP UNIFORMES deseja um sistema que gerencie as vendas

da empresa, nestas vendas seria importante termos o controle dos clientes
que compraram, um controle de produtos com seus respectivos preços e
também um controle de vendedores para que seja possível a distribuição
da comissão.
ESTUDO DE CASO
135
Após a análise, retiramos as possíveis entidades:

■■ Empresa
■■ Vendas
■■ Produtos
■■ Clientes
■■ Vendedores
Importante: a entidade Empresa existe no texto do estudo de caso, porém

conforme a restrição nos determina, não será criada por não haver Filiais.
CRIANDO AS ENTIDADES E OS RELACIONAMENTOS

(DER)
Para facilitar o mapeamento do DER, é importante que ele seja feito em etapas,
para não perdermos nenhuma informação e restrição imposta pelo projeto. De
acordo com as restrições passadas no estudo de caso, iremos abordar cada um
dos casos:
1° Relacionamento:
■■ Uma venda pode ter apenas um Cliente.
(1,1) (1,N)
Clientes Possui Venda
Figura 33: Exemplo de Relacionamento em que uma venda pode ter apenas um Cliente
Fonte: o autor.
Criando as Entidades e os Relacionamentos (DER)

136 UNIDADE V
CLIENTES
VENDA
Figura 34: Exemplo de Relacionamento em que uma Venda pode ter apenas um Vendedor demonstrado em
formato de tabela
Fonte: os autores.
No exemplo acima, temos a representação em forma de tabela do relacionamento

entre as entidades CLIENTE e VENDA, em que a representação simboliza que
a tabela VENDA receberá o código do cliente.
2° Relacionamento:
■■ Uma venda pode ter apenas um Vendedor.
(1,1) (1,N)
Vendedor Contém Venda
Figura 35: Exemplo de Relacionamento em que uma Venda pode ter apenas um Vendedor.
Fonte: os autores.
ESTUDO DE CASO
137
VENDEDOR
VENDA
Figura 36: Exemplo de Relacionamento em que uma Venda pode ter apenas um Vendedor demonstrado em
formato de tabelas
Fonte: os autores.

entre as entidades VENDEDOR e VENDA, em que a representação simboliza
que a tabela VENDA receberá o código do vendedor.
3° Relacionamento:
■■ Uma venda pode ter vários itens.
(1,1) (1,N)
Venda Contém Venda_Itens
Figura 37: Exemplo de Relacionamento em que uma Venda pode ter apenas vários itens
Fonte: os autores.
No exemplo a seguir, temos a representação em forma de tabela do relaciona-

mento entre as entidades VENDA e VENDA_ITENS, em que a representação
simboliza que a tabela VENDA_ITENS receberá o código da venda e não há
problemas em haver repetições, pois vale lembrar que a chave nessa tabela é
composta (VDI_CHAVE_VDA e VDI_NSEQUEN) e o campo VDI_NSEQUEN
deverá ser preenchido de maneira sequencial e, assim, não teremos o risco de
haver tuplas (linhas) duplicadas.

138 UNIDADE V
VENDA
VENDA_ITENS
Figura 38: Exemplo de Relacionamento em que uma Venda pode ter apenas vários itens demonstrado em
formato de tabelas.
Fonte: os autores.
4° Relacionamento:
■■ Um produto pode estar em vários itens.
(1,1) (1,1)
Produtos Está Venda_Itens
Figura 39: Exemplo de Relacionamento em que um produto pode estar em vários itens
Fonte: os autores.
ESTUDO DE CASO
139
PRODUTOS
VENDA_ITENS
Figura 40: Exemplo de Relacionamento em que um produto pode estar em vários itens demonstrado em
formato de tabelas
Fonte: os autores.

entre as entidades PRODUTOS e VENDA_ITENS, em que a representação sim-
boliza que a tabela VENDA_ITENS receberá o código do produto.
DER (Diagrama de Entidade e Relacionamento) - Completo

Para uma melhor visualização dos relacionamentos das entidades, utilizamos o
DER (Diagrama de Entidade e Relacionamento). Veja, na sequência, a represen-
tação completa das entidades relativas ao nosso estudo de caso:

140 UNIDADE V
Clientes Vendedor
(1,1) (1,1)
(1,N) (1,N)
Possui Venda Contém
(1,1)
Contém
(1,N)
(1,1) (1,1)
Produtos Está Venda_Itens
Figura 41: DER (Diagrama de Entidade e Relacionamento)

Fonte: os autores.
AS ENTIDADES E SEUS ATRIBUTOS
A seguir, do lado esquerdo, teremos a descrição das entidades e seus atributos

de maneira individual, conforme o modelo lógico, e, do lado direito, temos a
representação da entidade e seus atributos no modelo conceitual, conforme a
notação de Peter Chen (1976).
ESTUDO DE CASO
141
Figura 42: Exemplo da tabela Produtos e seus atributos

Fonte: os autores.
Figura 43: Exemplo da tabela Clientes e seus atributos

Fonte: os autores.

142 UNIDADE V
Figura 44: Exemplo da tabela Vendedor e seus atributos
Fonte: os autores.
Figura 45: Exemplo da tabela Venda e seus atributos

Fonte: os autores.
ESTUDO DE CASO
143
Figura 46: Exemplo da tabela Venda_Itens e seus atributos

Fonte: os autores.
TRABALHANDO COM SQL
Neste tópico, vamos trabalhar com a implementação das entidades criadas

no Estudo de Caso, abordando tanto as metodologias do modelo DDL (Data
Definition Language) e DML (Data Manipulation Language).
TRABALHANDO COM DDL – DATA DEFINITION LANGUAGE
■■ Criando as Tabelas
Para criar tabelas, utilizamos o comando CREATE TABLE. A seguir, demons-

traremos cada tabela:
Trabalhando com SQL

144 UNIDADE V
■■ PRODUTOS
CREATE TABLE PRODUTOS (
PROD_CHAVE INTEGER PRIMARY KEY,
PROD_DESCRI VARCHAR(60),
PROD_VPRECO NUMERIC(18,4),
PROD_UNIDAD VARCHAR(5),
PROD_FAMILI VARCHAR(10)
);
■■ CLIENTES
CREATE TABLE CLIENTES (
CLI_CHAVE INTEGER PRIMARY KEY,
CLI_TIPOPESSOA CHAR(1),
CLI_STATUS VARCHAR(15),
CLI_BAIRRO VARCHAR(30),
CLI_ESTADO CHAR(2),
CLI_PAIS VARCHAR(6),
CLI_INSCRESTADUAL VARCHAR(25),
CLI_CEP VARCHAR(9),
CLI_CIDADE VARCHAR(35),
CLI_CNPJ_CPF VARCHAR(18),
CLI_ENDERE VARCHAR(60),
CLI_RAZAOSOCIAL VARCHAR(60),
CLI_NOMEFANTASIA VARCHAR(30),
CLI_EMAIL VARCHAR(60)
);
ESTUDO DE CASO
145
■■ VENDEDOR
CREATE TABLE VENDEDOR (
VEN_CHAVE INTEGER PRIMARY KEY,
VEN_NOME VARCHAR(30),
VEN_CNPJ_CPF VARCHAR(18),
VEN_TIPOPESSOA CHAR(1),
VEN_INSCRESTADUAL VARCHAR(25),
VEN_STATUS VARCHAR(15),
VEN_EMAIL VARCHAR(60),
VEN_VPERCENT_COMIS NUMERIC(5,4)
);
■■ VENDA
CREATE TABLE VENDA (
VDA_CHAVE INTEGER PRIMARY KEY,
VDA_DMOVTO DATE,
VDA_VDINHEIRO NUMERIC(18,2),
VDA_VCARTAO NUMERIC(18,2),
VDA_VCHEQUE NUMERIC(18,2),
VDA_VPRAZO NUMERIC(18,2),
VDA_VOUTROS NUMERIC(18,2),
VDA_VTOTAL NUMERIC(18,2),
VDA_VRECEB NUMERIC(18,2),
VDA_VTROCO NUMERIC(18,2),
VDA_CODCLI_CLI INTEGER,
VDA_CODVEN_VEN INTEGER,
VDA_VDESC NUMERIC(18,2),
FOREIGN KEY (VDA_CODCLI_CLI) REFERENCES CLIENTES(CLI_CHAVE),
FOREIGN KEY (VDA_CODVEN_VEN) REFERENCES VENDEDOR(VEN_CHAVE));
Trabalhando com SQL

146 UNIDADE V
■■ VENDA_ITENS
CREATE TABLE VENDA_ITENS (
VDI_CHAVE_VDA INTEGER,
VDI_NSEQUEN INTEGER,
VDI_CODPRO_PROD INTEGER,
VDI_QQUANTI NUMERIC(18,2),
VDI_VPREUNI NUMERIC(18,2),
VDI_VALORITEM NUMERIC(18,2),
VDI_PERCENTDESC NUMERIC(5,2),
VDI_QTDEDEVOLV NUMERIC(18,2),
VDI_DESCPROD VARCHAR(255),
PRIMARY KEY(VDI_CHAVE_VDA,VDI_NSEQUEN),
FOREIGN KEY (VDI_CHAVE_VDA) REFERENCES VENDA (VDA_CHAVE),
FOREIGN KEY (VDI_CODPRO_PROD) REFERENCES PRODUTOS (PROD_CHAVE));
■■ Inserindo Atributos nas Tabelas
Para inserir ATRIBUTOS nas tabelas, utilizamos o comando ALTER TABLE

ADD. A seguir, estaremos incluindo alguns atributos para cada tabela:
■■ PRODUTOS
ALTER TABLE PRODUTOS ADD PROD_DTVENCIMENTO DATE;
ALTER TABLE PRODUTOS ADD PROD_DESCRCOMPLETA VARCHAR(255);
ALTER TABLE PRODUTOS ADD PROD_PRECOVENDA NUMERIC(18,4);
■■ CLIENTES
ALTER TABLE CLIENTES ADD CLI_FONECONTATO VARCHAR(14);
ALTER TABLE CLIENTES ADD CLI_CONTATO VARCHAR(30);
ALTER TABLE CLIENTES ADD CLI_COMPLEMENTOEND VARCHAR(30);
ESTUDO DE CASO
147
■■ VENDEDOR
ALTER TABLE VENDEDOR ADD VEN_FONECONTATO VARCHAR(14);
ALTER TABLE VENDEDOR ADD VEN_ENDERECO VARCHAR(60);
ALTER TABLE VENDEDOR ADD VEN_ESTADO VARCHAR(2);
■■ VENDA
ALTER TABLE VENDA ADD VDA_STATUS CHAR(1);
ALTER TABLE VENDA ADD VDA_CFOP VARCHAR(7);

ALTER TABLE VENDA ADD VDA_DTENVIO DATE;
■■ VENDA_ITENS
ALTER TABLE VENDA_ITENS ADD VDI_PERCENTICMS NUMERIC(5,4);
ALTER TABLE VENDA_ITENS ADD VDI_TOTALICMS NUMERIC(18,4);
ALTER TABLE VENDA_ITENS ADD VDI_VALORIPI NUMERIC(18,4);
■■ Deletando os Atributos nas Tabelas
Para deletar ATRIBUTOS nas tabelas, utilizamos o comando ALTER TABLE

DROP. A seguir, estaremos excluindo alguns atributos para cada tabela:
■■ PRODUTOS
ALTER TABLE PRODUTOS DROP PROD_FAMILI;
ALTER TABLE PRODUTOS DROP PROD_UNIDAD;
ALTER TABLE PRODUTOS DROP PROD_VPRECO;
Trabalhando com SQL

148 UNIDADE V
■■ CLIENTES
ALTER TABLE CLIENTES DROP CLI_PAIS;
ALTER TABLE CLIENTES DROP CLI_BAIRRO;
ALTER TABLE CLIENTES DROP CLI_STATUS;
■■ VENDEDOR
ALTER TABLE VENDEDOR DROP VEN_EMAIL;
ALTER TABLE VENDEDOR DROP VEN_INSCRESTADUAL;
ALTER TABLE VENDEDOR DROP VEN_STATUS;
■■ VENDA
ALTER TABLE VENDA DROP VDA_VTROCO;
ALTER TABLE VENDA DROP VDA_VPRAZO;
ALTER TABLE VENDA DROP VDA_VOUTROS;
■■ VENDA_ITENS:
ALTER TABLE VENDA_ITENS DROP VDI_QQUANTI;
ALTER TABLE VENDA_ITENS DROP VDI_VPREUNI;
ALTER TABLE VENDA_ITENS DROP VDI_VALORITEM;
ESTUDO DE CASO
149
■■ Deletando as Tabelas
Para deletar as TABELAS, utilizamos o comando DROP TABLE. A seguir, esta-

remos excluindo as tabelas do sistema:
DROP TABLE PRODUTOS;
DROP TABLE CLIENTES;
DROP TABLE VENDEDOR;
DROP TABLE VENDA_ITENS;
DROP TABLE VENDA;

Trabalhando com DML – DATA MANIPULATION LANGUAGE

Agora, iremos trabalhar com os comandos de manipulação de dados. Esses
comandos nos ajudam a implementar e trabalhar com o conteúdo das tabelas
e, para isso, utilizaremos comandos de inserção, alteração, seleção e deleção.
■■ Inserindo novos registros nas Tabelas
Para inserir registros em uma tabela, utilizamos o comando INSERT. A seguir,

estaremos demonstrando a cada tabela como devemos proceder:
■■ PRODUTOS
/* Inserindo Registros na tabela Produtos*/
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (1, ‘NOBREAK’, 200, ‘UN’, ‘ESCRITÓRIO’);
UNIDAD, PROD_FAMILI) VALUES (2, ‘NOTEBOOK’, 2500, ‘UN’, ‘ESCRITÓRIO’);
UNIDAD, PROD_FAMILI) VALUES (3, ‘SABÃO EM PÓ’, 9.00, ‘UN’, ‘LIMPEZA’);
Trabalhando com SQL

150 UNIDADE V
■■ CLIENTES
/* Inserindo Registros na tabela Clientes*/
INSERT INTO CLIENTES (CLI_CHAVE, CLI_TIPOPESSOA, CLI_STATUS, CLI_
BAIRRO, CLI_ESTADO, CLI_PAIS, CLI_INSCRESTADUAL, CLI_CEP, CLI_CIDADE,
CLI_CNPJ_CPF, CLI_ENDERE, CLI_RAZAOSOCIAL, CLI_NOMEFANTASIA, CLI_EMAIL)
VALUES (1, ‘F’, ‘ATIVO’, ‘JARDIM COLINA’, ‘SP’, ‘BRASIL’, ‘ISENTO’,
‘67009-490’, ‘CAMPINAS’, ‘090.345.729-49’, ‘RUA JOÃO DE BARRO 946’,
‘RONALDO DA SILVA’, ‘RONALDO DA SILVA’, ‘ronaldoteste@hotmail.com’);
VALUES (2, ‘J’, ‘ATIVO’, ‘ZONA 1’, ‘PR’, ‘BRASIL’, ‘123.123.234’, ‘87009-
678’, ‘MARINGÁ’, ‘73.486.451/0001-54’, ‘AV. BRASIL 1001’, ‘MERCADO REDE
CIDADE LTDA’, ‘MERCADO REDE CIDADE’, ‘adm@redecidade.com.br’);
■■ VENDEDOR
/* Inserindo Registros na tabela Vendedor*/
INSERT INTO VENDEDOR (VEN_CHAVE, VEN_NOME, VEN_CNPJ_CPF, VEN_
TIPOPESSOA, VEN_INSCRESTADUAL, VEN_STATUS, VEN_EMAIL, VEN_VPERCENT_COMIS)
VALUES (1, ‘MARIA DAS GRAÇAS’, ‘302.027.591-13’, ‘F’, ‘ISENTO’, ‘ATIVO’,
‘vendas@hotmail.com’, 1.5);
VALUES (2, ‘MALU REPRESENTAÇÃO’, ‘48.825.337/0001-64’, ‘J’, ‘ISENTO’,
‘ATIVO’, ‘comercial@malurepresenta.com.br’, 2.0);
ESTUDO DE CASO
151
■■ VENDA
/* Inserindo Registros na tabela Venda*/
INSERT INTO VENDA (VDA_CHAVE, VDA_DMOVTO, VDA_VDINHEIRO, VDA_VCARTAO,
VDA_VCHEQUE, VDA_VPRAZO, VDA_VOUTROS, VDA_VTOTAL, VDA_VRECEB, VDA_VTROCO,
VDA_CODCLI_CLI, VDA_CODVEN_VEN, VDA_VDESC) VALUES (1, ‘23/01/2015’, 0,
0, 0, 0, 0, 10900, 10900, 0, 1, 1, 0);

0, 0, 0, 0, 4800, 5000, 0, 2, 2, 200);
Trabalhando com SQL

152 UNIDADE V
■■ VENDA_ITENS
/* Inserindo Registros na tabela Venda_Itens*/
INSERT INTO VENDA_ITENS (VDI_CHAVE_VDA, VDI_NSEQUEN, VDI_CODPRO_PROD,
VDI_QQUANTI, VDI_VPREUNI, VDI_VALORITEM, VDI_PERCENTDESC, VDI_QTDEDEVOLV,
VDI_DESCPROD) VALUES (1, 1, 1, 5, 200, 1000, 0, 0, ‘NOBREAK’);
VDI_DESCPROD) VALUES (1, 2, 1, 9, 1000, 9000, 0, 0, ‘NOTEBOOK’);
VDI_DESCPROD) VALUES (1, 3, 1, 100, 9.00, 900, 0, 0, ‘SABAO EM PÓ’);
■■ Alterando registros das Tabelas
Para realizarmos alterações nos registros em uma tabela, utilizamos o comando

UPDATE. Vale lembrar que temos que ter uma certa atenção com esse comando,
pois ele normalmente vem acompanhado da cláusula WHERE, o que causa uma
restrição/limite nas alterações. Por isso, caso você omita o comando WHERE
dentro do comando UPDATE, o mesmo será executado em TODA a TABELA,
e caso esta não seja a pretensão, o dano pode ser grande, portanto, atenção ao
executar esse comando. A seguir, estarei demonstrando, em algumas tabelas,
como devemos proceder para alterarmos algum registro:
ESTUDO DE CASO
153
■■ PRODUTOS
/* Neste comando iremos modificar a descrição do produto cujo código
chave é igual a 1*/
UPDATE PRODUTOS
SET PROD_DESCRI = ‘NOBREAK 700VA’
WHERE PROD_CHAVE = 1;
/* Neste comando iremos modificar a família do produto cujo código
chave é igual a 1*/

UPDATE PRODUTOS
SET PROD_FAMIL = ‘CONSUMO’
■■ CLIENTES
/* Neste comando iremos modificar o Status de TODOS os Clientes para
INATIVO*/
UPDATE CLIENTES
SET CLI_STATUS = ‘INATIVO’;
/* Neste comando iremos modificar o Bairro do cliente 1 para Jardim
Paulista III*/
UPDATE CLIENTES
SET CLI_BAIRRO = ‘JARDIM PAULISTA III’
WHERE CLI_CHAVE = 1;
Trabalhando com SQL

154 UNIDADE V
■■ VENDEDOR
/* Neste comando iremos modificar o nome do vendedor 1 para Maria
das Graças da Silva*/
UPDATE VENDEDOR
SET VEN_NOME = ‘MARIA DAS GRAÇAS DA SILVA’
WHERE VEN_CHAVE = 1;
/* Neste comando iremos modificar o percentual de comissão do ven-
dedor 1 para 2.0*/
UPDATE VENDEDOR
SET VEN_VPERCENT_COMIS = 2.0
■■ Deletando registros das Tabelas
Em um banco de dados, podemos excluir os registros em uma tabela utilizando o

comando DELETE. É importante lembrar que a exclusão só é possível se não há
nenhuma dependência desse registro em outra tabela. Vamos a alguns exemplos:
■■ PRODUTOS
/* Com o comando abaixo, iremos apagar todos os registros da Tabela
Produtos*/
DELETE FROM PRODUTOS;
/*Neste comando será deletado o produto cujo código chave é igual
a 1 */
DELETE FROM PRODUTOS
ESTUDO DE CASO
155
■■ CLIENTES
/*Neste comando será deletado o cliente cujo código chave deste
cliente é igual a 1*/
DELETE FROM CLIENTES
■■ VENDEDOR
/*Neste comando será deletado o Vendedor cujo código chave deste

Vendedor é igual a 1*/
DELETE FROM VENDEDOR
É IMPORTANTE saber que os comandos UPDATE e DELETE devem ser utili-

zados de maneira cuidadosa, pois alguns dados, depois de inseridos no sistema,
não podem ser modificados e/ou excluídos. Um exemplo claro do nosso dia-a-dia
é a NF-e (Nota Fiscal Eletrônica), em que, após o envio dessa nota à SEFAZ
(Secretaria da Fazenda), ela não pode ser modificada e, caso haja a modificação
e a empresa sofra uma auditoria, essa pode ser acusada de fraude e responder
gravemente por essa modificação, portanto, tenha sempre em mente que é muito
grande a nossa responsabilidade com os dados inseridos em um banco de dados.
■■ Selecionando os registros de Tabelas
Demonstraremo agora o comando SELECT, comando este que nos ajuda no

momento da busca de dados no banco de dados de maneira organizada. Seguem
alguns exemplos:
Trabalhando com SQL

156 UNIDADE V
■■ CLIENTES
/*Este comando seleciona todos os registros da tabela juntamente com
todos os seus atributos */
SELECT * FROM CLIENTES;
/*Seleciona o Cliente cuja chave é igual a 1, juntamente com todos
os seus campos por conta do * (asterisco) */
SELECT *
FROM CLIENTES
/*Seleciona o Cliente cujo Nome fantasia inicia com M, trazendo os
respectivos atributos específicos conforme descrito abaixo*/
SELECT
CLI_CHAVE,
CLI_TIPOPESSOA,
CLI_STATUS,
CLI_NOMEFANTASIA,
CLI_ESTADO,
CLI_PAIS
FROM CLIENTES
WHERE CLI_NOMEFANTASIA LIKE ‘M%’;
ESTUDO DE CASO
157
■■ VENDAS
/* Selecionando todas as vendas cuja Data da Venda seja maior que
01/01/2015 */
SELECT *
FROM VENDA
WHERE VDA_DMOVTO > ‘01/01/2015’;
/* Selecionando a data da Venda cujo valor total seja maior que
6000.00 */
SELECT VDA_DMOVTO
FROM VENDA
WHERE VDA_VTOTAL > 6000.00;
/* Selecionando o valor da maior venda */
SELECT MAX(VDA_VTOTAL)
FROM VENDA;
■■ VENDA e VENDAS_ITENS
/* Na consulta a seguir, temos a seleção de campos da tabela Venda e
Venda_itens. neste caso utilizamos o JOIN para que independente se temos
itens correspondentes ou não a aquela venda a mesma seja retornada. */
SELECT
VENDA.VDA_CHAVE AS “Cód. Venda”,
VENDA.VDA_DMOVTO AS “Dt. Movimento”,
VENDA.VDA_VTOTAL AS “Total da Venda”,
VENDA_ITENS.VDI_CODPRO_PROD AS “Código do Produto”,
VENDA_ITENS.VDI_QQUANTI AS “Quantidade”,
VENDA_ITENS.VDI_VPREUNI AS “Preço Unitário”,
VENDA_ITENS.VDI_VALORITEM AS “Valor Item”
FROM VENDA INNER JOIN VENDA_ITENS ON VENDA.VDA_CHAVE = VENDA_ITENS.
VDI_CHAVE_VDA;
Trabalhando com SQL

MATERIAL COMPLEMENTAR
Nos links abaixo, temos duas vídeoaulas com que você pode complementar seus estudos,
revisando e aprendendo novos conceitos, estudando a criação de bancos de dados, de tabelas e
de alguns conceitos novos, utilizando o PostgreSQL:
VIDEOAULA 1: <https://www.youtube.com/watch?v=IBiw9xXO5_Y>. Acesso em: 8 jul. 2015.
VIDEOAULA 2: <https://www.youtube.com/watch?v=zgFoOg9N43s>. Acesso em: 8 jul. 2015.
Sistemas de Banco de Dados

Elmasri e Navathe
Editora: Person
Sinopse: disponibilizado na Biblioteca Pearson, esse livro
reúne teoria e exemplos práticos com as mais modernas
tecnologias. Ele introduz os conceitos fundamentais
necessários para projetar, usar e implementar os sistemas
de banco de dados e suas aplicações. De fácil compreensão,
o texto aborda com profundidade a modelagem e o projeto
de banco de dados, suas linguagens e as funcionalidades
dos sistemas de gerenciamento de banco de dados e as
técnicas de implementação desses sistemas. Data mining.
Sistemas de banco de dados destina-se a estudantes de graduação, pós-graduação ou a usuários
familiarizados com programação e conceitos de estruturação de dados e organização básica de
computadores.
159
POSTGRESQL: UM BANCO DE DADOS PARA TODOS

Por Cláudio Bezerra Leopoldino, graduado em Computação, mestre em Administração,
especialista em Banco de Dados e Analista de Desenvolvimento de Software do Serpro
desde 2004. Utiliza o PostgreSQL como ferramenta de ensino de Banco de Dados, mas
de vez em quando implementa alguma coisa. É colunista dos sítios “Meu Blog de Post-
greSQL” e “Planeta PostgreSQL-BR”.
Receber, processar e realizar consultas a informações são as operações fundamentais

de qualquer banco de dados. A essas funções básicas podem ser adicionadas a gestão
de disponibilidade, a confiabilidade, a segurança e a escalabilidade. Em um mundo de
bancos de dados complexos, com centenas de tabelas, compostos por vários terabytes
de dados e que são acessados por milhares de usuários simultâneos, que são uma rea-
lidade, a ferramenta livre PostgreSQL é uma alternativa atual, viável e dotada de muitos
recursos para os desenvolvedores de soluções informatizadas de todas as naturezas.
Histórico
O PostgreSQL, que pode ser chamado simplesmente de Postgres, é um software de
banco de dados livre. Seu mascote é o elefante, o animal que “nunca esquece”. Uma
das razões do sucesso dessa ferramenta é o seu extenso período de desenvolvimento
razoavelmente contínuo.
Em 1986, surge o projeto Postgres, liderado por Michael Stonebraker, financiado princi-
palmente por verbas militares e de pesquisas científicas. Influenciado pelo sucesso do
banco de dados relacional Ingres, o desenvolvimento visava criar um banco de dados
com recursos “pós-ingres”, daí o nome empregado até os dias atuais. Em 1994, foi adi-
cionado um interpretador de SQL ao Postgres em substituição à linguagem PostQUEL,
criando o Postgres95. O nome foi alterado já no ano seguinte para PostgreSQL. A data
oficial de aniversário é 8 de julho.
Após um relativo sucesso no ambiente unix/linux, o PostgreSQL passou a ser disponi-
bilizado para windows a partir da versão 8.0.0, lançada oficialmente em 19 de janeiro
de 2005. O grande aumento na difusão do Postgres, com a conquista do ambiente win-
dows, consolidou-se nas versões posteriores. A versão mais atual é a 8.4, lançada oficial-
mente em 2009, mas já está disponível a versão alfa da futura 8.5.
Visão Geral
O PostgreSQL é um banco de dados cliente-servidor, padrão utilizado pela maioria das
aplicações atuais. Trata da entrada, do processamento e da saída de grandes quantida-
des de dados e implementa a linguagem SQL – Structured Query Language, o padrão
mundial para consulta, definição e manipulação de informações. Implementa tanto o
padrão relacional quanto os recursos de gerenciamento de dados objeto-relacionais.
Permite a criação de tabelas, visões, índices e triggers. Implementa a integridade refe-
rencial por meio de chaves primárias e estrangeiras, além de outras constraints diversas
definíveis pelos desenvolvedores.
Suporta diversos sistemas operacionais, facilitando a migração, reutilização e atualiza-
ção de servidores – Linux, Unix, computadores com Mac e Windows são contemplados.
Também é compatível com plataformas de hardware de 32 bits e 64 bits, além de siste-
mas RAID, o que permite grande variedade de fornecedores e arquiteturas.
Para os desenvolvedores, além da implementação de padrões SQL 92 e 99, o Postgres
oferece linguagens para funções armazenadas no banco e nas interfaces de programa-
ção para praticamente todas as principais linguagens do mercado: C/C++, Java, .Net,
Perl, Python, Ruby, TCL, PHP, entre outras. Trabalha em conjunto com frameworks como
Struts, Hibernate e o brasileiro Demoiselle.
Por ser software livre, mantido por uma comunidade bastante ativa, esse banco de da-
dos tem crescido em sofisticação, confiabilidade e performance. Cada nova versão tam-
bém oferece novos recursos de gerenciamento.
Funcionalidades
Para o desenvolvedor de soluções de banco de dados, a
variedade de funcionalidades oferecidas permite toda
uma gama de opções, o que torna essa ferramenta um
bom concorrente para qualquer banco de dados livre ou
comercial. As funcionalidades que destaco nesta seção são
apenas relatório bastante sumário.
Utilitários nativos tratam de backup e recuperação de
dados. A implementação de tablespaces e schemas
permite a organização física e lógica dos componentes
de um banco de dados de forma simplificada. As opções
para a padronização de segurança de acesso são bastante robustas e os recursos de
indexação oferecidos compreendem, além dos índices básicos, os parciais e os basea-
dos em expressões – recursos de desempenho pouco explorados por outros bancos de
dados.
161
A implementação do conceito de transações assegura sua atomicidade, sua consistên-

cia, seu isolamento e sua durabilidade. As facilidades para replicação assíncrona e recu-
peração pós-falha permitem a recuperação da consistência do banco de dados mesmo
após quedas de sistema catastróficas.
O suporte aos padrões SQL 92 e SQL 99 facilita a aprendizagem, e a possibilidade das
codificações de funções dentro do banco permite que o servidor de banco de dados
hospede parte das lógicas de negócio das aplicações. Todos os tipos de dados tradi-
cionais são suportados, além do suporte ao armazenamento de large objects (BLOBs e
CLOBs). O Postgres apresenta ainda recursos como window functions, que permitem
ranqueamento, geração de numeração e classificação de dados, cláusulas que expan-
dem a função dos comandos SQL tradicionais e comandos exclusivos, como o COPY.
Todas essas funcionalidades se completam com opções avançadas para monitoramen-
to, configuração e administração de bancos de dados.
Conclusão: Qual é a sua Necessidade?

Se você precisa de um banco de dados, acredito que o Postgres é uma boa opção – pela
falta de limitações de uso; pela disponibilidade de opções que é oferecida; pela credi-
bilidade de uma ferramenta com mais de uma década de desenvolvimento sem inter-
rupções, com uma comunidade ativa e produtiva; pela crescente base de usuários que
muitas vezes desconhecem o banco de dados que utilizam, pela ausência de problemas
em produção.
Empresas privadas, instituições sem fins lucrativos, órgãos públicos das esferas muni-
cipal, estadual e federal já apresentam cases de utilização dentro e fora do país. Não
importa a sua aplicação de banco de dados, essa é uma opção a ser considerada.
DataWarehouse, aplicações cliente-servidor ou na web? O Postgres suporta.
Sistema operacional? O Postgres está em todos os maiores, incluindo Windows e Linux.
Hardware? Não há incompatibilidades.
Curva de aprendizado? Esse é o menor obstáculo. Existem cursos nas faculdades e em-
presas especializadas, sítios oficiais e não oficiais com grande quantidade de conteúdo.
Fonte: Campos (2009, online).

162 UNIDADE V
No estudo de banco de dados, nada melhor que a prática aliada à teoria. Nesta
unidade, tivemos como objetivo demonstrar um passo-a-passo de como é a cria-
ção de um banco de dados, partindo desde o momento em que as características
são passadas pelo cliente (Análise dos Requisitos) até o momento da criação prá-
tica utilizando a linguagem SQL (Structured Query Language ou Linguagem de
Consulta Estruturada).
Nesta unidade, demonstramos alguns comandos que nos ajudam tanto na
criação como na manutenção de um banco de dados. Um ponto importante a
respeito desta unidade é tê-la como base de consulta em seus estudos diários,
assim poderá não apenas saber os comandos ensinados, mas também aplicá-los
de maneira correta, sempre que necessário.
Contudo vale enfatizar que o aprendizado de Banco de dados e SQL demanda
muita leitura e também muita prática/treino. Nossa sugestão é que você tente
sempre fazer os exercícios e, em seguida, possa revisá-los para que a fixação do
conteúdo seja ainda melhor.
ESTUDO DE CASO
163
1. A atividade a seguir propõe colocar em prática o conteúdo estudado, será dispo-

nibilizado na sequência o SCRIPT e os comandos em ordem para que você possa
digitar e executar a criação de um banco de dados. Lembro que a proposta deste
exercício é que não seja apenas digitado, mas compreendido.
Algumas dicas ou sugestões:
• Você pode digitar isto em um arquivo texto e abrir no Gerenciador de banco
de dados onde pode ser executado como script.
• Você pode digitar diretamente no gerenciador, mas tem que ser executado
como SCRIPT.
DROP TABLE VENDA;
DROP TABLE VENDA_ITENS;
DROP TABLE PRODUTOS;
DROP TABLE CLIENTES;
DROP TABLE VENDEDOR;
CREATE TABLE PRODUTOS (
PROD_CHAVE INTEGER PRIMARY KEY,
PROD_DESCRI VARCHAR(60),
PROD_VPRECO NUMERIC(18,4),
PROD_UNIDAD VARCHAR(5),
PROD_FAMILI VARCHAR(10)
);
CREATE TABLE CLIENTES (
CLI_CHAVE INTEGER PRIMARY KEY,
CLI_TIPOPESSOA CHAR(1),
CLI_STATUS VARCHAR(15),
CLI_BAIRRO VARCHAR(30),
CLI_ESTADO CHAR(2),
CLI_PAIS VARCHAR(6),
CLI_INSCRESTADUAL VARCHAR(25),
CLI_CEP VARCHAR(9),
CLI_CIDADE VARCHAR(35),
CLI_CNPJ_CPF VARCHAR(18),
CLI_ENDERE VARCHAR(60),
CLI_RAZAOSOCIAL VARCHAR(60),
CLI_NOMEFANTASIA VARCHAR(30),
CLI_EMAIL VARCHAR(60)
);
CREATE TABLE VENDEDOR (
VEN_CHAVE INTEGER PRIMARY KEY,
VEN_NOME VARCHAR(30),
VEN_CNPJ_CPF VARCHAR(18),
VEN_TIPOPESSOA CHAR(1),
VEN_INSCRESTADUAL VARCHAR(25),
VEN_STATUS VARCHAR(15),
VEN_EMAIL VARCHAR(60),
VEN_VPERCENT_COMIS NUMERIC(5,4)
);
165
CREATE TABLE VENDA (
VDA_CHAVE INTEGER PRIMARY KEY,
VDA_DMOVTO DATE,
VDA_VDINHEIRO NUMERIC(18,2),
VDA_VCARTAO NUMERIC(18,2),
VDA_VCHEQUE NUMERIC(18,2),
VDA_VPRAZO NUMERIC(18,2),
VDA_VOUTROS NUMERIC(18,2),
VDA_VTOTAL NUMERIC(18,2),
VDA_VRECEB NUMERIC(18,2),
VDA_VTROCO NUMERIC(18,2),
VDA_CODCLI_CLI INTEGER,
VDA_CODVEN_VEN INTEGER,
VDA_VDESC NUMERIC(18,2),
FOREIGN KEY (VDA_CODCLI_CLI) REFERENCES VENDA(CLI_CHAVE),
FOREIGN KEY (VDA_CODVEN_VEN) REFERENCES VENDEDOR(VEN_CHAVE));
CREATE TABLE VENDA_ITENS (
VDI_CHAVE_VDA INTEGER,
VDI_NSEQUEN INTEGER,
VDI_CODPRO_PROD INTEGER,
VDI_QQUANTI NUMERIC(18,2),
VDI_VPREUNI NUMERIC(18,2),
VDI_VALORITEM NUMERIC(18,2),
VDI_PERCENTDESC NUMERIC(5,2),
VDI_QTDEDEVOLV NUMERIC(18,2),
VDI_DESCPROD VARCHAR(255),
PRIMARY KEY(VDI_CHAVE_VDA,VDI_NSEQUEN),
FOREIGN KEY (VDI_CHAVE_VDA) REFERENCES VENDA(VEN_CHAVE),
FOREIGN KEY (VDI_CODPRO_PROD) REFERENCES PRODUTOS (PROD_CHAVE));

DELETE FROM VENDA_ITENS;
DELETE FROM VENDA;
DELETE FROM PRODUTOS;
DELETE FROM CLIENTES;
DELETE FROM VENDEDOR;
COMMIT;
/* Inserindo Registros na tabela Produtos*/
UNIDAD, PROD_FAMILI) VALUES (1, ‘NOBREAK’, 200, ‘UN’, ‘ESCRITÓRIO’);
UNIDAD, PROD_FAMILI) VALUES (2, ‘NOTEBOOK’, 2500, ‘UN’, ‘ESCRITÓRIO’);
UNIDAD, PROD_FAMILI) VALUES (3, ‘SABÃO EM PÓ’, 9.00, ‘UN’, ‘LIMPEZA’);
/* Inserindo Registros na tabela Clientes*/

VALUES (1, ‘F’, ‘ATIVO’, ‘JARDIM COLINA’, ‘SP’, ‘BRASIL’, ‘ISENTO’,
‘67009-490’, ‘CAMPINAS’, ‘090.345.729-49’, ‘RUA JOÃO DE BARRO 946’,

‘RONALDO DA SILVA’, ‘RONALDO DA SILVA’, ‘ronaldoteste@hotmail.com’);
VALUES (2, ‘J’, ‘ATIVO’, ‘ZONA 1’, ‘PR’, ‘BRASIL’, ‘123.123.234’, ‘87009-
678’, ‘MARINGÁ’, ‘73.486.451/0001-54’, ‘AV. BRASIL 1001’, ‘MERCADO REDE
CIDADE LTDA’, ‘MERCADO REDE CIDADE’, ‘adm@redecidade.com.br’);

167
/* Inserindo Registros na tabela Vendedor*/
VALUES (1, ‘MARIA DAS GRAÇAS’, ‘302.027.591-13’, ‘F’, ‘ISENTO’, ‘ATIVO’,

‘vendas@hotmail.com’, 1.5);
VALUES (2, ‘MALU REPRESENTAÇÃO’, ‘48.825.337/0001-64’, ‘J’, ‘ISENTO’,
‘ATIVO’, ‘comercial@malurepresenta.com.br’, 2.0);
0, 0, 0, 0, 10900, 10900, 0, 1, 1, 0);
0, 0, 0, 0, 4800, 5000, 0, 2, 2, 200);
VDI_DESCPROD) VALUES (1, 1, 1, 5, 200, 1000, 0, 0, ‘NOBREAK’);


VDI_DESCPROD) VALUES (1, 3, 1, 100, 9.00, 900, 0, 0, ‘SABAO EM PÓ’);
COMMIT;
ALTER TABLE PRODUTOS ADD PROD_DTVENCIMENTO DATE;
ALTER TABLE PRODUTOS ADD PROD_DESCRCOMPLETA VARCHAR(255);
ALTER TABLE PRODUTOS ADD PROD_PRECOVENDA NUMERIC(18,4);
ALTER TABLE CLIENTES ADD CLI_FONECONTATO VARCHAR(14);
ALTER TABLE CLIENTES ADD CLI_CONTATO VARCHAR(30);
ALTER TABLE CLIENTES ADD CLI_COMPLEMENTOEND VARCHAR(30);
ALTER TABLE VENDEDOR ADD VEN_FONECONTATO VARCHAR(14);
ALTER TABLE VENDEDOR ADD VEN_ENDERECO VARCHAR(60);
ALTER TABLE VENDEDOR ADD VEN_ESTADO VARCHAR(2);
ALTER TABLE VENDA ADD VDA_STATUS CHAR(1);
ALTER TABLE VENDA ADD VDA_CFOP VARCHAR(7);
ALTER TABLE VENDA ADD VDA_DTENVIO DATE;
ALTER TABLE VENDA_ITENS ADD VDI_PERCENTICMS NUMERIC(5,4);
ALTER TABLE VENDA_ITENS ADD VDI_TOTALICMS NUMERIC(18,4);
ALTER TABLE VENDA_ITENS ADD VDI_VALORIPI NUMERIC(18,4);

169
CONCLUSÃO
Se há uma palavra que possa descrever meu sentimento ao concluir este livro, essa
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 preten-
diam produzir qualquer texto: “o que é escrito sem esforço é lido sem prazer”.
Não posso 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, certamen-
te, as palavras organizadas neste material foram fruto de um enorme esforço. E não
somente de esforço, mas também de dor, privação de certas liberdades que me fo-
ram 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 a que nos dedicamos.
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. Não me agrada observar alguns programadores
valorizando uma ferramenta qualquer em detrimento da utilidade do software
sendo desenvolvido. Esse é 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 ne-
cessá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 – e terá, com certeza, uma pontinha de dúvida a
respeito de 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(a) nos requisitos e utilidade da sua apli-
caçã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 re-
lacionais, graças aos conhecimentos de SQL adquiridos. A lista deste material certa-
mente não é exaustiva, mas é um bom começo. Afinal, a jornada do conhecimento
nunca acaba.
CONCLUSÃO
Baseado(a) em tudo o que você pôde aprender, aproveite bem e utilize todo o con-
teúdo que tentamos transmitir para desenvolver um bom software, software inova-
dor. É isso o que nós, sinceramente, desejamos para sua frutífera jornada, que está
apenas começando. Bom proveito, boa sorte e, acima de tudo, muito sucesso!
Um grande abraço!
171
REFERÊNCIAS
10 curiosidades sobre o Google. Olhar Digital. Disponível em: <http://olhardigi-

tal.uol.com.br/noticia/10-fatos-curiosos-sobre-o-google/34841>. Acesso em: 6 jul.
2015.
CAMPOS, M. M. PostgreSQL: um banco de dados para todos. Serpro. Disponível
em: <http://www4.serpro.gov.br/imprensa/publicacoes/tema-1/antigas%20temas/
tema-200/materias/artigos>. Acesso em: 9 jul. 2015.
CARDOSO, V.; CARDOSO, G. Sistema de Banco de Dados: uma abordagem introdu-
tória e aplicada. São Paulo: Saraiva, 2012.
CESAR. G. Bancos de Dados Livres Crescem no Brasil. ComputerWorld. 2005.
Disponível em: <http://computerworld.com.br/tecnologia/2005/08/18/idgnoti-
cia.2006-05-15.4431159825>. Acesso em: 16 jul. 2015.
CHEN, Peter. Gerenciando Banco de Dados: A Abordagem Entidade-Relaciona-
mento para Projeto Lógico. São Paulo: McGraw-Hill, 1990. 80 p.
DATE, C. J. Bancos de dados: tópicos avançados. Rio de Janeiro: Campus, 1988.
HAMANN, R. 9 áreas da tecnologia com carreiras promissoras (e como aproveitá-las).
Tecmundo. Disponível em: <http://www.tecmundo.com.br/mercado/77008-9-are-
as-tecnologia-carreiras-promissoras-aproveita-las.htm>. Acesso em: 8 jul. 2015.
HARRISON, G. 10 things you should know about NoSQL. TechRepublic. Disponível
em: <http://www.techrepublic.com/blog/10things/10-things-you-should-know-
-about-nosql-databases/1772>. Acesso em: 8 jul. 2015.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
KNUTH, D. Structured Programming with go to Statements. ACM Journal Comput-
ing Surveys, 6 (4): 268. Dez. 1974.
NAVATHE, S. B.; ELMASRI, R. Sistemas de Banco de Dados.
6. ed. Pearson - Addison Wesley, 2011.
PRITCHET, E. Base: an acid alternative. ACMQUEUE. Disponível em: <http://queue.
acm.org/detail.cfm?id=1394128>. Acesso em: 7 jul. 2015.
REES, R. NoSQL Comparison. Thoughtworks. Disponível em: <http://www.though-
tworks.com/articles/nosql-comparison>. Acesso em: 8 jul. 2015.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco
de dados. São Paulo: Makron Books do Brasil, 1999.
TAURION, C. A revolução do Big Data está prestes a acontecer. iMaster. Disponível
em: <http://imasters.com.br/artigo/23437/banco-de-dados/a-revolucao-do-big-
-data-esta-prestes-a-acontecer>. Acesso em: 7 jul. 2015.
REFERÊNCIAS
TAURION, C. Banco de dados Open Source: presente ou futuro? IBM. Disponível em:
<https://www.ibm.com/developerworks/mydeveloperworks/blogs/ctaurion/en-
try/bancos_de_dados_open_source?lang=pt_br>. Acesso em: 6 jul. 2015.
ZHANG, J. Banco de dados na nuvem. IBM. Disponível em: <http://www.ibm.com/
developerworks/br/data/library/dmmag/DMMag_2011_Issue2/cloudDBaaS/>.
Acesso em: 6 jul. 2015..
173
GABARITO
UNIDADE I
1. Atomicidade se reflete, por exemplo, em transações bancárias. Enquanto o com-
provante ou outra forma de confirmação da transação não é recebido por um clien-
te em um caixa eletrônico, a transação não é concretizada, pois esta característica
visa garantir que as operações sempre ocorram por completo.
Consistência se aplica a situações onde a impressão de um extrato bancário só é
impresso se todos os dados que devam estar contidos nele já tenham sido proces-
sados de forma confiável, garantindo que a informação exibida é fiel aos dados reais
do banco de dados.
Isolamento é extremamente útil em bancos de dados com acesso remoto de mul-
tiusuários como ocorre em terminais de autoatendimento de bancos onde mais de
uma pessoa pode estar simultaneamente acessando os mesmos dados, como em
sistemas de consulta de preços em lojas.
Durabilidade se refere a situações como a de transações bancárias terem a garantia
de terem ocorrido de maneira completa, e sem o risco de interrupções não progra-
madas que possam gerar a perda de informações parciais ou totais da transação
por motivos diversos como interrupções na corrente elétrica, ou incidentes naturais.
2. Quando há a necessidade do armazenamento de apenas um tipo de dado, um

arquivo comum de texto pode resolver o problema, sem a necessidade de imple-
mentação de um sistema de gerenciamento destes dados, ou em casos onde os
dados armazenados sejam extremamente simples como na configuração e um ma-
quinário.
Uma combinação destes tipos de sistemas de armazenamento de dados em um
sistema pode ocorrer devido a diferentes formas de tratamento de dados, sendo
por exemplo possível a existência de arquivos de texto contendo entradas de dados
vindos de um equipamento ser um SGBD que serve para alimentar um SGBD mais
complexo como pode ocorrer em sistemas de monitoramento de maquinário em
uma indústria, por exemplo.
3. Uma base de dados pode ser acessada por mais de um sistema SGBD simulta-
neamente, e este isolamento, aumenta a consistência da base de dados, pois cada
acesso de um SGBD a base funciona de forma mais segura.
GABARITO
UNIDADE II
1) A partir do estudado nesta unidade, defina Entidades Concretas e Entidades Abs-
tratas.
R: Entidades Concretas são entendidas como objetos do mundo real que podem ser
separadas e distinguíveis de outro objeto. Já as Entidades Abstratas são aquelas que
não temos de maneira tangível (intangível).
2) Crie uma Entidade Produtos com os seguintes atributos:
a) Código do Produto
b) Descrição do Produto
c) Unidade do Produto
d) Valor do Produto
e) Classificação do Produto
f ) Valor Custo do Produto
3) Analise as frases abaixo e crie as possíveis entidades:

a) “... o atendente matricula o aluno no curso de Administração...”.
Atendente Matrícula Aluno Curso
b) “... a secretária agenda pacientes para atendimento médico…”.
Agenda ou
Secretária Pacientes Médico
Atendimento
175
GABARITO
c) “...é necessário cadastrar os produtos para realizar as vendas aos clientes...”
Produtos Vendas Clientes
UNIDADE III
1. CREATE TABLE aluno (

id INT PRIMARY KEY,
nome VARCHAR(30),
sobrenome VARCHAR(30),
ra DECIMAL(8),
email VARCHAR(30)
);
CREATE TABLE professor (
id INT PRIMARY KEY,
nome VARCHAR(30),
titulacao VARCHAR(30)
);
CREATE TABLE curso (
id INT PRIMARY KEY,
nome VARCHAR(30),
ano DECIMAL(4)
);
CREATE TABLE matricula (
curso_fk INT NOT NULL,
aluno_fk INT NOT NULL,
PRIMARY KEY (curso_fk, aluno_fk),
FOREIGN KEY (curso_fk) REFERENCES curso(id),
FOREIGN KEY (aluno_fk) REFERENCES aluno(id)
);
GABARITO
CREATE TABLE disciplina (

id INT PRIMARY KEY,
nome VARCHAR(30),
curso_fk INT NOT NULL,
professor_fk INT NOT NULL,
FOREIGN KEY (curso_fk) REFERENCES curso(id),
FOREIGN KEY (professor_fk) REFERENCES professor(id)
);
2.a. SELECT aluno.nome FROM aluno, curso, matricula WHERE curso.

nome=”Banco de Dados” AND curso.id=matricula.curso_fk AND matricula.
aluno_fk=aluno.id;
2.b. SELECT professor.titulacao FROM professor, disciplina WHERE disciplina.

nome=”SQL” AND disciplina.professor_fk=professor.id;
2.c. Select aluno.nome, aluno.sobrenome, aluno.ra from aluno, matricula,

curso, disciplina, professor where matricula.aluno_fk=aluno.id AND matricula.
curso_fk=curso.id AND disciplina.curso_fk=curso.id AND disciplina.professor_
fk=professor.id AND professor.nome=’Edson’;
2.d. SELECT id, nome, ano FROM curso WHERE ano>1990;
3. Exemplos de comandos para esta atividade, lembrando que podemos gerar

inúmeros comandos, INSERT para ter maior quantidade de dados para mani-
pular com os comandos UPDATE e DELETE
INSERT INTO aluno (id, nome, sobrenome, ra, email) VALUES (“1”, “João”, “Silva”,
“100000”, “jao@email.com”);
UPDATE curso SET ano=”2016” WHERE nome=”Banco de Dados”
DELETE FROM professor WHERE id=”5”

177
GABARITO
UNIDADE IV
1.
CREATE TABLE plano (
id INT PRIMARY KEY,
nome VARCHAR(30),
valor DECIMAL(7,2)
);
CREATE TABLE beneficiario (
id INT PRIMARY KEY,
nome VARCHAR(30),
altura DECIMAL(3,2),
plano_fk INT,
FOREIGN KEY (plano_fk) REFERENCES plano(id)
);
CREATE TABLE dependente (
id INT PRIMARY KEY,
nome VARCHAR(30),
beneficiario_fk INT NOT NULL,
FOREIGN KEY (beneficiario_fk) REFERENCES beneficiario(id)
);
2.a. SELECT beneficiario.nome FROM beneficiario INNER JOIN dependente

ON beneficiario.nome = dependente.nome;
2.b. SELECT beneficiario.nome FROM beneficiario WHERE nome IN ( SELECT

nome FROM dependente WHERE beneficiario.nome = dependente.nome );
2.c. SELECT beneficiario.nome FROM beneficiario WHERE EXISTS ( SELECT *

FROM dependente WHERE beneficiario.nome = dependente.nome );
GABARITO
2.d. SELECT nome FROM beneficiario WHERE ( SELECT MAX(altura) from

dependente );
3.a. SELECT sobrenome, altura FROM beneficiario GROUP BY nome;
3.b. SELECT beneficiario.nome FROM beneficiario WHERE ( SELECT COUNT(*)

FROM dependente WHERE dependente.beneficiario_fk=beneficiario.id and
dependente.sobrenome=beneficiario.sobrenome
GROUP BY beneficiario.nome) > 1
3.c. SELECT plano.nome FROM plano WHERE ( SELECT COUNT(*) FROM benefi-
ciario WHERE beneficiario.altura > 1.75 AND beneficiario.plano_fk = plano.id );

Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE

Professor Me. Edson Yanaga

NEAD - Núcleo de Educação a Distância

Ficha catalográfica elaborada pelo bibliotecário

Professor Me. Edson Yanaga

Professor Esp. Victor de Marqui Pedroso

relacional, você identificará entidades do seu domínio de negócios, suas restrições

Um bom proveito e uma ótima leitura!

Prof. Me. Edson Yanaga

21 Características de Sistemas de Bancos de Dados

31 Vantagens de se Utilizar um SGBD

57 Chave Estrangeira (Foreign Key)

73 Definições de Dados e Tipos em SQL

79 Consultas Básicas em SQL

85 Comandos de Modificação de Dados em SQL

100 Consultas Envolvendo NULL

101 Consultas Aninhadas (Subqueries)

105 Consultas Utilizando Joins

110 Comandos de Alteração de Schema

122 Considerações Finais

132 Descrevendo o Estudo de Caso

133 Criando as Entidades e os Relacionamentos (DER)

141 Trabalhando com SQL

160 Considerações Finais

“Scientia potentia est”: “Conhecimento é poder”.

Sim, caro(a) leitor(a), conhecimento é poder. Informação é poder. Na sociedade

ainda criar para gerar conhecimento e, consequentemente, riqueza.

Um banco de dados é uma coleção de dados relacionados. Os dados

Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer

CONCEITOS DE BANCOS DE DADOS

Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem

CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE

Características de Sistemas de Bancos de Dados

conjuntamente. Essas metainformações armazenadas contêm informações como

CONCEITOS DE BANCOS DE DADOS

executem operações “ao mesmo tempo”.

idealmente a execução dessas instruções é bastante curta, tem-se a impressão

Características de Sistemas de Bancos de Dados

como tal, podem - e deverão - ser quantificados economicamente.

O maior evento da comunidade brasileira de NoSQL:

O conceito de transação é fundamental em muitas áreas da computação e parti-

Consistência: a propriedade de consistência assegura que a execução de

CONCEITOS DE BANCOS DE DADOS

Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas

a própria consistência das informações.

Papéis assumidos pelos usuários de SGBDs

São pessoas que projetam e codificam os SGBDs. Exem-

São pessoas que desenvolvem software que armazena as

São pessoas que não interagem diretamente com os ban-

Quadro 1: Papéis assumidos pelos usuários de SGBDs

CONCEITOS DE BANCOS DE DADOS

VANTAGENS DE SE UTILIZAR UM SGBD

Durante os tópicos anteriores, já citamos algumas vantagens de se utilizar um

Vantagens de se Utilizar um SGBD

CONCEITOS DE BANCOS DE DADOS

COMPUTAÇÃO EM NUVEM E ARQUITETURAS DE ARMAZENAMENTO EM

Desafio de TI Solução em nuvem

O que são as soluções em nuvem?

• Medido e gerenciado: métricas para gerenciamento de relatórios, análises e ser-

Central de dados: pública, privada, híbrida Empresarial Pessoal

desses apegos a uma determinada tecnologia ou outra e decidir sobriamente qual

CONCEITOS DE BANCOS DE DADOS

1. Transações tradicionalmente são melhor entendidas por meio do conjunto de

21 Características de Sistemas de Bancos de Dados

31 Vantagens de se Utilizar um SGBD

57 Chave Estrangeira (Foreign Key)

73 Definições de Dados e Tipos em SQL

79 Consultas Básicas em SQL

85 Comandos de Modificação de Dados em SQL

100 Consultas Envolvendo NULL

101 Consultas Aninhadas (Subqueries)

105 Consultas Utilizando Joins

110 Comandos de Alteração de Schema

122 Considerações Finais

132 Descrevendo o Estudo de Caso

133 Criando as Entidades e os Relacionamentos (DER)

141 Trabalhando com SQL

160 Considerações Finais