BANCO DE DADOS UNICESUMAR

Prévia do material em texto

BANCO DE 
DADOS
Professor Me. Edson Yanaga
Professor Esp. Victor de Marqui Pedroso
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; YANAGA, Edson; PEDROSO, Victor de Marqui.
 Banco de Dados. Edson Yanaga; Victor de Marqui 
Maringá-Pr.: UniCesumar, 2016. Reimpresso em 2019.
 176 p.
“Graduação - EaD”.
 
 1. Banco. 2. Dados . 3. EaD. I. Título.
ISBN 978-85-459-0100-6
CDD - 22 ed. 005
CIP - NBR 12899 - AACR/2
Ficha catalográica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Impresso por:
Reitor
Wilson de Matos Silva
Vice-Reitor
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 Minco�
James Prestes
Tiago Stachon 
Diretoria de Graduação e Pós-graduação 
Kátia Coelho
Diretoria de Permanência 
Leonardo Spaine
Diretoria de Design Educacional
Débora Leite
Head de Produção de Conteúdos
Celso Luiz Braga de Souza Filho
Head de Curadoria e Inovação
Tania Cristiane Yoshie Fukushima
Gerência de Produção de Conteúdo
Diogo Ribeiro Garcia
Gerência de Projetos Especiais
Daniel Fuverki Hey
Gerência de Processos Acadêmicos
Taessa Penha Shiraishi Vieira
Supervisão de Produção de Conteúdo
Nádila Toledo
Coordenador de Conteúdo
Danillo Xavier Saes
Design Educacional
Paulo Victor Souza e Silva
Projeto Gráico
Jaime de Marchi Junior
José Jhonny Coelho
Arte Capa
Arthur Cantareli Silva
Editoração
Melina Belusse Ramos
Revisão Textual
Keren Pardini
Yara Martins Dias
Simone Morais Limonta
Ilustração
André Luis Onishi
Viver e trabalhar em uma sociedade global é um 
grande desaio 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 eiciê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 izermos 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 proissionais 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 im, 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 proissional, nos transformamos e, consequente-
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 desaios que surgem no mundo contem-
porâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
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 proissional, 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 proissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser 
apenas geográica. 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.
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 proissional, nos transformamos e, consequente-
mente, transformamos também a sociedade na qual 
estamos inseridos. De que forma o fazemos? Crian-
do oportunidades e/ou estabelecendo mudanças 
capazes de alcançar um nível de desenvolvimento 
compatível com os desaios que surgem no mundo 
contemporâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
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ógi-
ca e encontram-se integrados à proposta pedagógica, 
contribuindo no processo educacional, complemen-
tando sua formação proissional, desenvolvendo com-
petências e habilidades, e aplicando conceitos teóricos 
em situação de realidade, de maneira a inseri-lo no 
mercado de trabalho. Ou seja, estes materiais têm 
como principal objetivo “provocar uma aproximação 
entre você e o conteúdo”, desta forma possibilita o 
desenvolvimento da autonomia em busca dos conhe-
cimentos necessários para a sua formação pessoal e 
proissional.
Portanto, nossa distância nesse processo de cresci-
mento e construção do conhecimento deve ser apenas 
geográica. Utilize os diversos recursos pedagógicos 
que o Centro Universitário Cesumar lhe possibilita. 
Ou seja, acesse regularmente o Studeo, que é o seu 
Ambiente Virtual de Aprendizagem, interaja nos fó-
runs e enquetes, assista às aulas ao vivo e participe 
das discussões. Além disso, lembre-se que existe uma 
equipe de professores e tutores que se encontra dis-
ponível para sanar suas dúvidas e auxiliá-lo(a) em 
seu processo de aprendizagem, possibilitando-lhe 
trilhar com tranquilidade e segurança sua trajetória 
acadêmica.
A
U
T
O
R
E
S
Professor Esp. Victor de Marqui Pedroso
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.
Professor Me. Edson Yanaga
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.
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 especiicamente 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 desaio 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 desaios 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 deiniçõ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 inanceiros. Como leitura complementar, 
temos um texto de Cezar Taurion (Evangelista Técnico da IBM) falando sobre Big Data. 
Ainal, é 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 identiicar as características de modelos relacionais e passar a construir seus 
próprios modelos de dados baseado(a) nos fundamentos apresentados. Na modelagem 
relacional, você identiicará 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 relexã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 icar 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
APRESENTAÇÃO
SUMÁRIO
09
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 
39 Considerações Finais 
UNIDADE II
MODELO RELACIONAL
45 Introdução
46 O Modelo Relacional 
48 Introdução à Modelagem 
53 Atributos 
54 Tipos de Atributos 
58 Domínio 
59 Chave Estrangeira (Foreign Key) 
60 Relacionamentos 
63 Cardinalidade 
67 Considerações Finais 
SUMÁRIO
UNIDADE III
SQL BÁSICO
73 Introdução
75 Deinições de Dados e Tipos em SQL 
79 Restrições 
81 Consultas Básicas em SQL 
87 Comandos de Modiicação de Dados em SQL 
96 Considerações Finais 
UNIDADE IV
MAIS SQL
101 Introdução
102 Consultas Envolvendo NULL 
103 Consultas Aninhadas (Subqueries) 
107 Consultas Utilizando Joins 
112 Comandos de Alteração de Schema 
124 Considerações Finais 
SUMÁRIO
11
UNIDADE V
ESTUDO DE CASO
129 Introdução
134 Descrevendo o Estudo de Caso 
135 Criando as Entidades e os Relacionamentos (DER) 
143 Trabalhando com SQL 
162 Considerações Finais 
169 CONCLUSÃO
172 GABARITO
U
N
ID
A
D
E I
Professor Me. Edson Yanaga
CONCEITOS DE BANCOS 
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
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 desaio crescente dos pró-
ximos anos é encontrar formas eicientes de processar os dados que já temos e 
ainda criar para gerar conhecimento e, consequentemente, riqueza.
Nas últimas décadas, boa parte do sotware desenvolvido envolve mais do 
que processamento de informações. As informações de entrada e de saída do 
sotware (além de outras metainformações intermediárias) devem ser armaze-
nadas em um mecanismo coniá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 dei-
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 coniável.
Outra confusão bastante comum e plenamente justiicada refere-se à dife-
rença entre os termos “banco de dados” e os sistemas que o gerenciam. Segue 
uma deinição, segundo Navathe (2011, p. 3):
Introdução
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
15
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E16
Um banco de dados é uma coleção de dados relacionados. Os dados 
são fatos que podem ser gravados e que possuem um signiicado im-
plí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 Microsot Access ou Excel. Essas informa-
ções são uma coleção de dados com um signiicado implí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 sotware especializado que 
é desenvolvido especiicamente 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 deinição de Navathe (2011, p. 3) sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) é uma coleção 
de programas que permite aos usuários criar e manter um banco de 
dados. O SGBD é, portanto, um sistema de sotware de propósito geral 
que facilita os processos de deinição, construção, manipulação e com-
partilhamento de bancos de dados entre vários usuários e aplicações. A 
deiniç̃o de um banco de dados implica especiicar os tipos de dados, 
as estruturas e as restrições para os dados a serem armazenados em um 
banco de dados.
Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer 
sistemas de sotware, tal opção não se mostra viável. Relembrando o nosso con-
ceito, de que a importância do sotware 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 deinimos 
os SGBDs em uma categoria de sotware que consideramos como commodity.
Introdução
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 deinição, inalizaremos denominando o conjunto for-
mado pelo banco de dados e o sistema que o gerencia, o SGBD, de Sistema de 
Banco de Dados.
BANCOS DE DADOS OPEN SOURCE: PRESENTE OU FUTURO?
Cezar Taurion
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de 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 certiicaçã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 soisticadas ou bem especíicas. 
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 dedó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áico 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 soisticados. 
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 qualiicaçã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 desconianç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 
codiicação, testes e o que chamamos reconciliação entre as aplicações no novo e no 
antigo ambiente, sempre considerando que diicilmente 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).
Características de Sistemas de Bancos de Dados
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 isica-
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 sotware 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çã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 
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E22
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íicas 
é 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 inal 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.
Características de Sistemas de Bancos de Dados
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
23
Acesso concorrente de múltiplos usuários: um SGBD multiusuário, como 
o próprio nome já deine, deve permitir o acesso de múltiplos usuários. Além 
disso, o acesso deve ser concorrente, permitindo que todos os usuários conec-
tados executem operações “ao mesmo tempo”.
Vale a pena reletir 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 ila) 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.
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-
inido e compreendido. Com uma rápida pesquisa no Google, identiiquei, pelo menos, 
uma dúzia de deinições. Neste artigo, vou falar um pouco sobre o assunto e debater 
alguns desaios que temos para conseguir colocar projetos de Big Data em ação. 
Sem entrar em deiniçõ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 im, 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 desaio: 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. Ainal, 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, 
como tal, podem - e deverão - ser quantiicados economicamente.
25 
Big Data representa um desaio 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” signiica 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 proissionais bem amplas. Na minha opinião, existe es-
paço para dois peris proissionais: um mais voltado para os negócios e qualiicados 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 proissionais que sai-
bam interpretar os números usando a análise de dados, também conhecida como inte-
ligência empresarial. Mas encontrar proissionais qualiicados tem se mostrado difícil. 
O resultado foi que váriasfaculdades 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 iltra 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 reletem 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 inanç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-
icaçã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.
Transações
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 deiniçã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.
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E28
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 inalizada 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.
Transações
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 lexível e Eventualmente consistente. O BASE tornou-se uma sigla 
bastante comum ao lidar com bancos de dados não relacionais.
Uma relexão que vale a pena ser feita é: para os novos desaios e empreita-
das que você, futuro(a) proissional, 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). 
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E30
Papéis assumidos pelos usuários de SGBDs
Quadro 1: Papéis assumidos pelos usuários de SGBDs
DESENVOLVEDORES DE 
SGBDS
São pessoas que projetam e codiicam 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 
de SBGDs livres, podem ser também voluntários ou pes-
soas e empresas interessadas na evolução do software. 
Normalmente são programadores altamente qualiicados 
que trabalham no código-fonte do SBGD. Mas voluntários 
de projetos de software livre também podem contribuir 
em outras atividades, como documentação, por exemplo.
DESENVOLVEDORES 
DE APLICAÇÕES E 
ADMINISTRADORES 
DE BANCOS DE DADOS 
(DBAS – DATABASE 
ADMINISTRATORS)
São pessoas que desenvolvem software que armazena as 
informações em um SGBD. Tradicionalmente, em abor-
dagens mais tradicionais e conservadoras, as equipes de 
desenvolvimento são separadas em desenvolvedores e 
DBAs.Os primeiros desenvolvem o software que acessa 
o SGBD. Os segundos projetam os bancos de dados e 
os mantêm. Em abordagens de desenvolvimento mais 
modernas, tende-se a eliminar essa distinção entre os pa-
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.
USUÁRIOS FINAIS
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-
ções em SGBDs. A maioria das pessoas enquadra-se nessa 
categoria e, embora sejam os grandes beneiciados pela 
tecnologia dos sistemas de bancos de dados, raramente 
possuem ciência do fato.
Fonte: os autores.
Vantagens de se Utilizar um SGBD
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
31
VANTAGENS DE SE UTILIZAR UM SGBD
Durante os tópicos anteriores, já citamos algumas vantagens de se utilizar um 
SGBD para armazenar as informações de nossas aplicações. A seguir, as enu-
meraremos de um modo mais detalhado, de forma a justiicar 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 modiicaçõ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 inal 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 
conidenciais. 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 
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.
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E32
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 eicientes: como são aplicações de sotware de propósito 
especíico, os SGBDs são especialmente projetados para armazenar ei-
cientemente os dados a eles delegados e para permitir formas de consulta 
eicientes 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 
eiciência em consultas do que a eiciência em armazenamento de infor-
maçõ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 desaios
A computação em nuvem e o armazenamento em nuvem são os assuntos do momento 
para tratar dos problemas e desaios 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 desaios comuns enfrentados pelas soluções em nuvem incluem:
Desaio de TI Solução em nuvem
Orçamentos ixos ou reduzidos Fazer mais com os orçamentos disponíveis 
sem deixar de promover o crescimento
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 lexíveis
Aprimorar o atendimento ao cliente Reduzir o tempo de entrada no mercado e 
possibilitar novas oportunidades
Falta de mobilidade ou lexibilidade 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íico.
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, lexí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 (Netlix), 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 especiicar 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 ino, 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 é conigurado 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 semelhantesaos 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 veriicaçã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 conigu-
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 
nuvem
Armazenamento em nuvem Nuvem pessoal
Combinação de 
alto desempenho e 
capacidade
Boa relação custo-be-
nefício, alta capacidade, 
economia de energia
Armazenamento 
local e em nuvem
Armazenamento 
local e em nuvem
Pulsar® (SSD), 
discos Savvio®15K 
e Savvio 10K de 
2,5 polegadas 
com desempenho 
otimizado
Discos Constellation® 
e Constellation ES de 
capacidade otimizada
BlackArmor® NAS
Armazenamento 
em rede GoFlex® 
Home, armaze-
namento pessoal 
Backup Plus e 
armazenamento 
móvel e sem io 
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 im de atender às suas necessidades e requisitos 
especíicos.
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.
Considerações Finais
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 sotware. Boa parte das 
aplicações de sotware 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 
sotware especíico 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 identiicam 
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 suicientes 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 diiculdades e das 
necessidades que os usuários possuem em cada caso de uso cotidiano da nossa 
vida proissional.
CONCEITOS DE BANCOS DE DADOS
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IU N I D A D E40
Por im, 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 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 sotware 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, izemos 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 exempliicar 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?
U
N
ID
A
D
E II
Prof. Esp. Victor de Marqui Pedroso
MODELO RELACIONAL
Objetivos de Aprendizagem
 ■ 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
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Modelo Relacional
 ■ Introdução à Modelagem
 ■ Atributos
 ■ Tipos de Atributos
 ■ Domínio
 ■ Chave Estrangeira (Foreign Key)
 ■ Relacionamentos
 ■ Cardinalidade
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 identiicaçã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 
(Microsot), Firebird (sotware 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
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
45
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E46
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áico. 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.
O Modelo Relacional
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
47
Entidade:
ouAtributo:
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áica de um conjunto, 
conjunto este cuja representação física ou gráica padrão é feita por meio de 
um retângulo com o nome da entidade dentro dele. Para identiicarmos 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
Carros
Viagem
Aluguel
Figura 3: Exemplo de Entidades
Fonte: os autores.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E48
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 classiicar 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 classiicar algumas Entidades:
Alunos
Carro
Livro
Funcionário
Viagem
Aluguel
Compra
Empréstimo
Exemplos de Entidades Concretas Exemplos de Entidades Abstratas
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 
Introdução à Modelagem
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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
Figura 5: Exemplo de Entidades
Fonte: os autores.
Já na frase: “o carro percorre vários itinerários”, podemos retirar duas possíveis 
entidades, sendo elas:
 
Carro Itinerário
Figura 6: Exemplo de Entidades
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 exempliicar 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.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E50
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 necessidadede 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 �lme
que deseja ver, os �lmes 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.
Introdução à Modelagem
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
51
Analisando o Exemplo 2 (Figura 8), temos como substantivos as palavras cliente, 
loja, ilme, ilmes, 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.
• Deinir 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
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E52
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. Conira 
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).
Atributos
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
53
ATRIBUTOS
Os atributos são propriedades utilizadas para descrever uma entidade, podemos 
airmar 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:
Produto
Código
Descrição
Valor_Venda
Valor_Custo
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, veriicamos que a tabela PRODUTOS contém 
Atributos que são os nomes das colunas e um conceito novo chamado de TUPLA. 
Deinindo de modo formal, uma linha é denominada de Tupla.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E54
Código Descrição Valor_Custo Valor_Venda
Entidade
Atributos
Tupla01 Lápis 1,00 2,00
02 Borracha 1,50 3,00
03 Mouse 10,00 20,00
PRODUTOS
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:
Tipos de Atributos
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
55
Funcionário
Nome
Nome
CPF
Matrícula Local
ou
ou
Cliente
Nome
CPF
Cliente
Funcionário
Nome
Matrícula Local
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:
Funcionário
Matrícula
Data_Nascimento
Telefones
Sexo
Figura 12: Exemplo de um atributo do tipo multivalorado
Fonte: os autores.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E56
 ■ 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:
 
Funcionário
Data_Nascimento
Sexo
Matrícula Endereço
Logradouro
Complemento
Cidade
Bairro
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 identiicador, que podemos chamar também 
de Atributo-Chave. Esse atributo irá identiicar 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.
Tipos de Atributos
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
57
Exempliicando: 
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 classiicado 
como atributo identiicador.
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 identiicador pode nos trazer 
problemas.
Matrícula: para cada funcionário, é gerado um número de matrícula que 
o identiicarána empresa e que não pode se repetir. Esse atributo pode sim ser 
classiicado como Atributo-Chave, devendo ser destacado entre os demais.
A seguir, temos a representação do exemplo Atributo-Chave em uma 
Entidade (Figura 15):
Funcionário
Endereço Nome
Matrícula
Figura 15: Exemplo de um atributo Chave em uma entidade
Fonte: os autores.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E58
DOMÍNIO
As restrições de domínio especiicam 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 ixo e tamanho variável.
 ■ Data. 
 ■ Hora.
A seguir, iremos criar uma tabela chamada Funcionário, contendo NOME DO 
CAMPO, TIPOS e TAMANHO para exempliicar 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.
Chave Estrangeira (Foreign Key)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 modiicaçã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, exempliicaremos 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.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E60
Outro exemplo:
 
Tabela: Professor
Tabela: Departamento
Tabela: Curso
Depto_Cod
Pro_Cod
Cur_Cod Cur_Nome
Depto_Nome
CodDepto
CodDeptoPro_idadePro_cpf Pro_DtNasc
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 icar 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 verii-
car validade nos 2 sentidos. Atenção! As setas não fazem parte do diagrama, são 
apenas para ilustrar os sentidos.
Relacionamentos
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
61
 
Funcionário Setor
Figura 19: Exemplo de notação básica de relacionamentos
Fonte: os autores.
Para deinir um relacionamento entre duas entidades, devemos veriicar 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 classiicaçã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
Monitorar
Pessoas
Casar
Figura 21: Exemplo de relacionamento Recursivo ou Autorrelacionamento
Fonte: os autores.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E62
 ■ 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.
 ■ Relacionamento 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
Gerenciar
Projetos
Figura 24: Exemplo de mais de um relacionamento entre duas entidades
Fonte: Cardoso (2012).
Cardinalidade
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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:
 
Horário
Palestrante Ministrar Tema
Figura 25: Exemplo de relacionamento contendo um atributo
Fonte: Cardoso (2012).
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 deinir 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.
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E64
Notaç̃o:
 
( x : y )
Cardinalidade Máxima
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
Leitura inversa: 1 Produto é comprado pelo ClienteCliente
1
1
1
1
ProdutoCompra
Figura 26: Exemplo de Cardinalidade Um para Um
Fonte: Cardoso (2012).
Cardinalidade
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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
Leitura inversa: o Produto é comprado por no máximo um Cliente
Cliente
1
1
N
1
ProdutoCompra
Figura 27: Exemplo de Cardinalidade Um para N
Fonte: Cardoso (2012).
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:
Leitura direta: o Cliente compra no máximo muitos Produtos
Leitura inversa: o Produto é comprado por no máximo vários Cliente
Cliente
1
N
N
1
ProdutoCompra
Figura 28: Exemplo de Cardinalidade N para N
Fonte: Cardoso (2012).
MODELO RELACIONAL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIU N I D A D E66
Quando a leitura é feita de (1:N) em ambos os sentidos das entidades. 
Teremos, assim, um resultado (N:N), conforme a seguir (Figura 29):
Leitura direta: o Cliente compra no máximo muitos Produtos
Leitura inversa: o Produto é comprado por no máximo vários Cliente
vários Clientes
1
N
N
1
ProdutoCompra
Figura 29: Exemplo de Cardinalidade N para N.
Fonte: Cardoso (2012).
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), signiica que o 
Cliente não é obrigatório no momento da venda do produto e que o Produto é 
comprado por, no máximo, um Cliente.
Considerações Finais
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
67
Cliente
0,N 1,N
ProdutoCompra
Figura 30: Exemplo de Cardinalidade N para N
Fonte: Cardoso (2012).
CONSIDERAÇÕES FINAIS
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 exempliicar para que ique claro e, assim, possa facilitar 
o seu estudo, entendimento e aprendizado. Aproveito o momento para deixar 
aqui o meu incentivo à ixação desse conteúdo, pois esses conceitos são impres-
cindíveis para quem deseja iniciar o desenvolvimento de um banco de dados. 
1. A partir do estudado nesta unidade, deina 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. Classiicaçã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 inanceiro 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 inanceiro e industrial do país, para aplicações especíicas 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 inanceiro, no máximo um outro patrocínio 
para participar em congressos internacionais”, airma 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.
U
N
ID
A
D
E III
Professor Me. Edson Yanaga
SQL BÁSICO
Objetivos de Aprendizagem
 ■ Deinir o que é SQL.
 ■ Apresentar os comandos de deinição e uso da SQL.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Deinir o que é SQL
 ■ Apresentar os comandos de deinição e uso da SQL
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 proissional, 
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 signiica 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 deine-se o que deve ser retornado como 
resultado do processamento, sem especiicar o como isso será feito.
Permita uma relexão sobre a natureza declarativa da SQL. Na SQL, ao dei-
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
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
73
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E74
modo signiicativo – 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 coniguraçã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 suiciente 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 sotware 
possam aprender facilmente a lidar com produtos concorrentes.
A SQL possui comandos tanto para a criação de deiniçõ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
Deinições de Dados e Tipos em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
75
DEFINIÇÕES DE DADOS E TIPOS EM SQL
Na unidade anterior, deinimos 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 deiniçã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 inalizados 
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 deinidas ao inal do comando.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E76
contato
email
telefone
grupo a�liação
id nome
id nome
sobrenome
id email contato_fk
id telefone contato_fk
grupo_fk contato_fk
nascimento peso
Figura 31: Exemplo da estrutura de Tabelas e seus respectivos atributos 
Fonte: os autores.
Os seguintes comandos criam as tabelas deinidas 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)
);
Deinições de Dados e Tipos em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
CREATE TABLE grupo (
id INT PRIMARY KEY,
nome VARCHAR(30) NOT NULL
);
CREATE TABLE ailiacao (
grupo_fk INT NOT NULL,
contato_fk INT NOT NULL,
PRIMARY KEY (grupo_fk, contato_fk),
FOREIGN KEY (grupo_fk) REFERENCES grupo(id),
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
Em algumas situações, não é possível deinir 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.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E78
TIPOS DE DADOS
A SQL deine 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 NUMÉRICOS
Tipos de dados numéricos suportam dados inteiros (INT 
e SMALLINT) e de ponto lutuante (FLOAT e DOUBLE). 
Números com precisão decimal (normalmente utilizados 
em cálculos de moeda, por exemplo) são DECIMAL 
ou NUMERIC, declarados como DECIMAL(a,b) ou 
NUMERIC(a,b), em que “a” é o número de dígitos inteiros e 
“b” é o número de dígitos decimais.
TIPOS CARACTERE
Tipos de caractere podem ser de tamanho ixo ou variável. 
Os atributos de tamanho ixo podem ser declarados como 
CHAR(n), em que “n” é o número máximo de caracteres 
suportado pelo atributo. Para especiicar 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 
no arquivo físico. Se o tamanho for ixo (CHAR), o SGBD já 
aloca esse tamanho predeinido 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 
deinido, há o desperdício de espaço dearmazenamento. 
Por outro lado, utilizando-se VARCHAR, o SGBD aloca um 
ponteiro para determinar qual o tamanho do atributo: as 
buscas são mais lentas, mas não há desperdício de espaço.
TIPOS BOOLEANOS
Assim como em linguagens de programação, tipos boo-
leanos podem assumir os valores TRUE ou FALSE. Muitos 
SGBDs mapeiam esses valores em “1” e “0”, respectivamen-
te.
TIPOS TEMPORAIS
O tipo DATE suporta dados temporais no formato AAAA-
-MM-DD (ano, mês, dia), enquanto que o tipo TIME utiliza 
o formato HH:MM:SS (hora, minuto e segundo). A própria 
SQL assegura representações temporais válidas.
Restrições
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
79
RESTRIÇÕES
Seguindo o nosso planejamento, abordaremos agora, as restrições que podem ser 
declaradas em SQL no comando CREATE TABLE. Restrições adicionais especi-
icadas 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 especiicar 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 deinir 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 deinir ‘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)
);
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E80
Chaves e integridade referencial
Para especiicar 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 inal 
(como no exemplo a seguir ):
PRIMARY KEY (grupo_fk, contato_fk)
A cláusula UNIQUE especiica chaves únicas (não primárias) em uma tabela. 
Poderíamos alterar a deinição da tabela email para garantir que não haja e-mails 
duplicados em nossa aplicação:
CREATE TABLE email (
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL UNIQUE,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
Já a integridade referencial e as chaves estrangeiras são deinidas por meio da 
cláusula FOREIGN KEY, como utilizada já no nosso exemplo nas tabelas email 
e telefone:
 Consultas Básicas em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
81
CREATE TABLE email (
id INT PRIMARY KEY,
email VARCHAR(60) NOT NULL,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
CREATE TABLE telefone (
id INT PRIMARY KEY,
telefone VARCHAR(20) NOT NULL,
contato_fk INT,
FOREIGN KEY (contato_fk) REFERENCES contato(id)
);
 CONSULTAS BÁSICAS EM SQL
O comando em SQL para a execução de operações de consulta é o SELECT, e as 
consultas que podem ser elaboradas com 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.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E82
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 dei-
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 especiicadas na tabela contato. A condição contato.id 
= telefone.contato_k é 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’;
 Consultas Básicas em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 deinir os nomes dos atributos nas cláusu-
las quando há a possibilidade de ambiguidade na deiniçã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, preixando 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, ailiacao
WHERE contato.id = ailiacao.contato_fk AND grupo.id = ailiacao.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 deinido para um 
determinado termo da consulta SQL. No Exemplo 4, deinimos 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 atributospela referência completa, torna-se possível, então, simplesmente 
escrevermos a condição inal da consulta como sendo n = ‘Joaquim’.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E84
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 deinição de um alias não está restrita 
aos atributos; um alias pode também ser deinido 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 
os atributos de todas as tabelas da cláusula FROM no resultado da consulta SQL.
 Consultas Básicas em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
85
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 deinir uma busca por padrões 
em Strings. O caractere ‘%’ é utilizado em condições LIKE para deinir 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 
‘_’ para preencher os campos da nossa busca.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E86
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 modiicador ASC ou DESC na cláusula. O valor ASC é o 
padrão e o valor assumido caso o modiicador seja omitido.
Exemplo 13: Selecione o nome e o sobrenome de todos os contatos cujo 
sobrenome inicie com ‘A’ e ordene por sobrenome em ordem decrescente e por 
nome em ordem crescente.
SELECT nome, sobrenome 
FROM contato 
WHERE sobrenome LIKE ‘A%’ 
ORDER BY sobrenome DESC, nome ASC;
Comandos de Modiicação de Dados em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
87
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 deinir 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 à deinição formal do schema da tabela, precisamos informar os valores 
de inserção na tabela dentro de uma ordem especíica. Essa ordem pode ser a 
própria ordem determinada pela deinição do schema ou pode ser a ordem em 
que deinimos os nomes das colunas da cláusula de INSERT.
O comando INSERT, em sua forma mais simples, pode ser exempliicado 
do seguinte modo:
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 deinição do schema, como deinido 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.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E88
INSERT INTO contato (nome, sobrenome, peso, nascimento, id) 
VALUES (‘Edson’, ‘Yanaga’, 95, ‘1978-04-12’, 10);
Nessa segunda forma do comando INSERT, nós especiicamos 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 é especiicada no próprio comando INSERT, evita-se que 
este torne-se inválido, quando o schema da tabela for modiicado 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 identiicado 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:
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’;
Comandos de Modiicação de Dados em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
89
O comando UPDATE
O comando UPDATE modiica 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 modiicação. Em sua forma fundamental, 
um comando de modiicaçã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 modiicar 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 modiicando o valor de dois 
atributos das tuplas cujo nome = ‘Carlos’. É uma prática bastante comum execu-
tarmos comandos UPDATE no banco de dados somente identiicando a chave 
primária na cláusula WHERE. Assim temos a garantia de que um único regis-
tro será modiicado 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 modiicaçõ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).
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E90
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.
Em sua forma fundamental, um comando de modiicação DELETE assume 
a forma DELETE FROM <tabela> WHERE <condições>.
DELETE FROM telefone 
WHERE id = 5;
O exemplo acima é a forma mais comum de execução do comando DELETE. A 
exemplo do comando UPDATE, o comando DELETE só pode ser aplicado em 
uma única tabela de cada vez.
DELETE FROM contato;
Comandos de Modiicação de Dados em SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
91
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 veriicadas, esse comando falharia com um erro caso alguma outra 
tabela (telefone, por exemplo) tivesse alguma chave estrangeira apontando para 
uma linha da tabela contato.
Cezar Taurion, da IBM, fala das vantagens da computação em nuvem
Disponível em: <http://youtu.be/HJre77TPpSw>. Acesso em: 8 jul. 2015.
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 desaios.
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 lexí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 lexí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 deinido 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 desaios do NoSQL
A promessa dos bancos de dados NoSQL gerou muitoentusiasmo, mas ainda há obstá-
culos a serem superados antes que eles possam seduzir grandes empresas mais conser-
vadoras. A seguir, listamos alguns dos principais desaios.
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 eiciê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 signiicativo 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>.
SQL BÁSICO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IIIU N I D A D E96
CONSIDERAÇÕES FINAIS
Finalizada a leitura desta unidade, já temos a convicção de que você, como pro-
issional comprometido(a) e luente 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 proissionais, 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 proissionais 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 deiniçõ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 modiicaçã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.
97 
Todas as atividades de autoestudo desta unidade baseiam-se na igura abaixo.
aluno
professor
curso
disciplina
matrícula
id nome
id nome curso_fk professor_fk
sobrenome
id nome sobrenome titulação
id nome ano curso_fk aluno_fk
ra email
1. Considere o exemplo de schema da igura apresentada. Crie os comandos SQL 
para deiniçã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 modiicação de dados para incluir, modiicar e remover 
linhas das diferentes tabelas desse schema.
U
N
ID
A
D
E IV
Professor Me. Edson Yanaga
MAIS SQL
Objetivos de Aprendizagem
 ■ Deinir consultas complexas em SQL.
 ■ Apresentar os comandos de alteração de deinições em SQL.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Consultas envolvendo NULL
 ■ Consultas aninhadas (subqueries)
 ■ Consultas utilizando joins
 ■ Consultas com funções de agregação
 ■ Comandos de alteração de schema
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-
ica 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 soisticadas.
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 deiniçã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, consultascom joins e consultas com funções de agregação, além dos comandos de altera-
ção de schema.
Introdução
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
101
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E102
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 deini-
dos, como IS e IS NOT. Ademais, todas as condições da cláusula WHERE de 
comandos SQL iltram 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 deinida.
Consultas Aninhadas (Subqueries)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 deinida.
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’;
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E104
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 modiicam 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 
Consultas Aninhadas (Subqueries)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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
subordinado
id nome sobrenome
id nome sobrenome superior_fk
cargo
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)
);
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E106
Exemplo 4: Selecione o nome e sobrenome de todos os funcionários que 
possuem subordinados com o mesmo nome.
SELECT f.nome, f.sobrenome
FROM funcionario AS f, subordinado AS s
WHERE f.id = s.superior_fk AND f.nome = s.nome;
Reescrevendo o exemplo acima com uma subquery:
SELECT f.nome, f.sobrenome
FROM funcionario AS f
WHERE id IN(
SELECT superior_fk
FROM subordinado AS s
WHERE f.nome = s.nome
);
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.
SELECT f.nome, f.sobrenome
FROM funcionario AS f
WHERE EXISTS (
SELECT *
FROM subordinado AS s
WHERE f.nome = s.nome
);
Consultas Utilizando Joins
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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.
SELECT f.nome, f.sobrenome
FROM funcionario AS f
WHERE NOT EXISTS (
SELECT *
FROM subordinado AS s
WHERE s.superior_fk = f.id
);
A exemplo do operador EXISTS, o operador NOT EXISTS retorna o oposto do 
operador EXISTS, sendo falso (FALSE), seo 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 deinido na unidade III em nossos exemplos 
a seguir.
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E108
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
INNER JOIN
É o tipo de JOIN padrão. Somente tuplas que satisfa-
çam a condição do JOIN são selecionadas.
LEFT OUTER JOIN ou 
LEFT JOIN
Todas as tuplas da tabela do lado esquerdo do ON são 
selecionadas. Caso não haja uma tupla corresponden-
te, na tabela do lado direito do JOIN, os valores são 
preenchidos com NULL.
RIGHT OUTER JOIN ou 
RIGHT JOIN
É a condição inversa do LEFT JOIN. Todas as tuplas da 
tabela do lado direito do ON são selecionadas. Caso 
não haja uma tupla correspondente na tabela do lado 
esquerdo do JOIN, os valores são preenchidos com 
NULL.
FULL OUTER JOIN ou 
FULL JOIN
Todas as tuplas dos dois lados do JOIN são seleciona-
das. Caso não haja correspondência na condição do 
JOIN, o lado vazio é preenchido com NULL.
Consultas Utilizando Joins
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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.
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E110
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.
Consultas Utilizando Joins
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 iltrar 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 iltram os resultados da consulta. A cláusula WHERE 
iltra 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 iltrar esses grupos do resultado inal.
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E112
COMANDOS DE ALTERAÇÃO DE SCHEMA
Nós deinimos 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 deinições de schema são os 
comandos para adicionar, modiicar 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 tabelasendo 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.
Comandos de Alteração de Schema
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 inal da deinição 
da tabela contato com o tipo deinido de VARCHAR(15). Quando um valor 
DEFAULT não é especiicado 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 deinindo 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 deinição da coluna apelido da tabela contato foi modiicada e o seu tipo de 
dados agora deine a capacidade de 25 caracteres.
Exemplo 18: Remova a coluna apelido da tabela contato.
ALTER TABLE contato DROP COLUMN apelido;
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E114
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.
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 clariicar o signiicado 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 ini-
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íica. 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 deinitiva, mas está claro que 
muitas organizações podem se beneiciar 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 desaios, ele também oferece recompensas sig-
niicativas à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 lexí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 icaram 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 ixos 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 peril 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 signiicam que os sites tornam-se mais equi-
librados no quesito “leitura-escrita”. Sites como o Twitter recebem montanhas de tráfego 
em intervalos muitocurtos de tempo (um gol validado ou invalidado, a apuração de 
117 
uma votação ou o inal de um seriado ou novela de TV), e sua infraestrutura deve se 
adaptar rapidamente para não icar 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 icará 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 signiicado diferente 
dependendo de se o valor for menor ou maior que 10 ou que “padaria”, na verdade, sig-
niica “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 inal é 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 soisticado com um baixo custo de manutenção. 
Tais códigos colocam o NoSQL irmemente 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 signiica 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 suiciente 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 relacional:
• Seu banco de dados relacional não escalará seu tráfego a um custo aceitável.
• Seus dados são fornecidos em pequenas mudanças ao longo do tempo, de modo 
que o número de tabelas necessárias para manter a forma normal cresceu 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 deiniçõ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, reinada e geralmente atende às expectativas dos usuários. Possui 
uma sintaxe coerente e rica em funcionalidades, o que signiica 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 desaios
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 identiicar áreas que se beneiciariam 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 propriedadesdo 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 veriicar 
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 peril 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 peris 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 conirmar, você 
terá que tratar dessas informações com ceticismo.
Banco de dados de grafos
Exemplos: Neo4J, InfoGrid e Ininite 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 inali-
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 modiicam 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, peris 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 identiica 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 
ica armazenada no “bucket” de recomendações.
Banco de dados de objetos
Exemplos: Oracle Coherence, db4o, ObjectStore, GemStone e Polar.
Aplicações Típicas: Sistemas inanceiros.
Pontos Fortes: Relete 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 veriicá-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 notiicações de objetos de tran-
sações. Quando um objeto é replicado no datacenter europeu, o analisador de riscos lê 
a transação e veriica 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 notiicaçã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).
MAIS SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
IVU N I D A D E124
CONSIDERAÇÕES FINAIS
Finalmente, chegamos ao im de nossa unidade. Nesse ponto, você provavel-
mente já terá assimilado conteúdo suiciente para poder desenvolver algumas 
aplicações utilizando sistemas de bancosde dados.
Como descrevemos no início da unidade, é bastante provável que você se 
depare, em sua vida proissional, 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 proissionais.
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.
125 
Todas as atividades de autoestudo desta unidade baseiam-se na igura abaixo.
bene�ciário
dependente
plano
id nome sobrenome
id nome sobrenome bene�ciário_fk
id nome valor
altura plano_fk
1. Considere o exemplo de schema da igura apresentada. Crie os comandos 
SQL para deinição e criação das tabelas.
2. Elabore consultas SQL para:
a. Selecione todos os beneiciá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 beneiciá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 beneiciários por nome e selecione o sobrenome e a altura de 
cada um deles.
b. Selecione todos os beneiciários que contêm mais de um dependente com 
o mesmo sobrenome.
c. Selecione todos os planos que contêm mais de um beneiciário com altura 
> 1.75.
U
N
ID
A
D
E V
Professor Esp. Victor de Marqui Pedroso
ESTUDO DE CASO
Objetivos de Aprendizagem
 ■ Demonstrar ao aluno a prática na criação de um Banco de dados. 
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Descrevendo o Estudo de Caso
 ■ Criando as Entidades e os Relacionamentos (DER)
 ■ Trabalhando com SQL
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 Deinition 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
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
129
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 proissionais qualii-
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 conira 
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 diiculdades 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 signiica “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 
airmam que compreendem o aumento da demanda por causa de necessidades cada 
vez mais especíicas.
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 signiica 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 
airma 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 icarão desempregados.
6. Desenvolvimento para a Web
Muitos desenvolvedores conseguiram crescer no mercado oline, 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 relete 
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 ica 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 desaio 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 proissional “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). 
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E134
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.
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.
Criando as Entidades e os Relacionamentos (DER)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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, ño será criada por ñ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.
Clientes
(1,1) (1,N)
VendaPossui
Figura 33: Exemplo de Relacionamento em que uma venda pode ter apenas um Cliente
Fonte: o autor.
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E136
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.
Vendedor
(1,1) (1,N)
VendaContém
Figura 35: Exemplo de Relacionamento em que uma Venda pode ter apenas um Vendedor.
Fonte: os autores.
Criando as Entidades e os Relacionamentos(DER)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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.
No exemplo acima, temos a representação em forma de tabela do relacionamento 
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.
Venda
(1,1) (1,N)
Venda_ItensContém
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.
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E138
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. 
 
Produtos
(1,1) (1,1)
Venda_ItensEstá
Figura 39: Exemplo de Relacionamento em que um produto pode estar em vários itens
Fonte: os autores.
Criando as Entidades e os Relacionamentos (DER)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
139
VENDA_ITENS
PRODUTOS
Figura 40: Exemplo de Relacionamento em que um produto pode estar em vários itens demonstrado em 
formato de tabelas
Fonte: os autores.
No exemplo acima, temos a representação em forma de tabela do relacionamento 
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:
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E140
Produtos
(1,1) (1,1)
Venda_ItensEstá
Contém
Clientes
Venda
(1,1)
(1,1)
(1,N) (1,N)
(1,N)
(1,1)
Vendedor
ContémPossui
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).
Criando as Entidades e os Relacionamentos (DER)
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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.
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E142
Figura 44: Exemplo da tabela Vendedor e seus atributos
Fonte: os autores.
Figura 45: Exemplo da tabela Venda e seus atributos
Fonte: os autores.
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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 
Deinition 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:
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E144
 ■ 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)
);
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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));
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E146
 ■ 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);
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
147
 ■ VENDEDOR
ALTER TABLE VENDEDOR ADDVEN_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;
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E148
 ■ 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;
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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’);
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (2, ‘NOTEBOOK’, 2500, ‘UN’, ‘ESCRITÓRIO’);
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (3, ‘SABÃO EM PÓ’, 9.00, ‘UN’, ‘LIMPEZA’);
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E150
 ■ 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’);
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 (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); 
INSERT INTO VENDEDOR (VEN_CHAVE, VEN_NOME, VEN_CNPJ_CPF, VEN_
TIPOPESSOA, VEN_INSCRESTADUAL, VEN_STATUS, VEN_EMAIL, VEN_VPERCENT_COMIS) 
VALUES (2, ‘MALU REPRESENTAÇÃO’, ‘48.825.337/0001-64’, ‘J’, ‘ISENTO’, 
‘ATIVO’, ‘comercial@malurepresenta.com.br’, 2.0);
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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);
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 (2, ‘15/02/2015’, 0, 
0, 0, 0, 0, 4800, 5000, 0, 2, 2, 200);
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E152
 ■ 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’);
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, 2, 1, 9, 1000, 9000, 0, 0, ‘NOTEBOOK’);
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, 3, 1, 100, 9.00, 900, 0, 0, ‘SABAO EM PÓ’);
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 (2, 1, 1, 5, 1000, 5000, 0, 0, ‘NOTEBOOK’);
 ■ 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:
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
153
 ■ PRODUTOS
/* Neste comando iremos modiicar 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 modiicar a família do produto cujo código 
chave é igual a 1*/
UPDATE PRODUTOS 
SET PROD_FAMIL = ‘CONSUMO’
WHERE PROD_CHAVE = 1;
 ■ CLIENTES
/* Neste comando iremos modiicar o Status de TODOS os Clientes para 
INATIVO*/
UPDATE CLIENTES 
SET CLI_STATUS = ‘INATIVO’;
/* Neste comando iremos modiicar o Bairro do cliente 1 para Jardim 
Paulista III*/
UPDATE CLIENTES 
SET CLI_BAIRRO = ‘JARDIM PAULISTA III’
WHERE CLI_CHAVE = 1;
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 19
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E154
 ■ VENDEDOR
/* Neste comando iremos modiicar 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 modiicar o percentual de comissão do ven-
dedor 1 para 2.0*/
UPDATE VENDEDOR 
SET VEN_VPERCENT_COMIS = 2.0
WHERE VEN_CHAVE = 1;
 ■ 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
WHERE PROD_CHAVE = 1;
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
155
 ■ CLIENTES
/*Neste comando será deletado o cliente cujo código chave deste 
cliente é igual a 1*/
DELETE FROM CLIENTES
WHERE CLI_CHAVE = 1;
 ■ VENDEDOR
/*Neste comando será deletado o Vendedor cujo código chave deste 
Vendedor é igual a 1*/
DELETE FROM VENDEDOR
WHERE VEN_CHAVE = 1;
É 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 modiicados 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 modiicada e, caso haja a modiicação 
e a empresa sofra uma auditoria, essa pode ser acusada de fraude e responder 
gravemente por essa modiicaçã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:
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E156
 ■ 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
WHERE CLI_CHAVE = 1;
/*Seleciona o Cliente cujo Nome fantasia inicia com M, trazendo os 
respectivos atributos especíicos conforme descrito abaixo*/
SELECT 
CLI_CHAVE, 
CLI_TIPOPESSOA, 
CLI_STATUS, 
CLI_NOMEFANTASIA,
CLI_ESTADO, 
CLI_PAIS 
FROM CLIENTES
WHERE CLI_NOMEFANTASIA LIKE ‘M%’;
Trabalhando com SQL
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt
. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 L
e
i 9
.6
1
0
 d
e
 1
9
 d
e
 f
e
v
e
re
ir
o
 d
e
 1
9
9
8
.
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;
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 coniabilidade, 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, inanciado princi-
palmente por verbas militares e de pesquisas cientíicas. Inluenciado 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 
oicial 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 oicialmente 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 oicial-
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, deinição e manipulação de informações. Implementa tanto o 
padrão relacional quanto os recursosde 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 
deiní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 soisticação, coniabilidade 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 simpliicada. 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óicas.
O suporte aos padrões SQL 92 e SQL 99 facilita a aprendizagem, e a possibilidade das 
codiicaçõ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 classiicaçã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, coniguraçã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 ins 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 oiciais e não oiciais com grande quantidade de conteúdo.
Fonte: Campos (2009, online). 
ESTUDO DE CASO
R
e
p
ro
d
u
çã
o
 p
ro
ib
id
a
. A
rt. 1
8
4
 d
o
 C
ó
d
ig
o
 P
e
n
a
l e
 Le
i 9
.6
1
0
 d
e
 1
9
 d
e
 fe
v
e
re
iro
 d
e
 1
9
9
8
.
VU N I D A D E162
CONSIDERAÇÕES FINAIS
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 ixação do 
conteúdo seja ainda melhor. 
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*/
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (1, ‘NOBREAK’, 200, ‘UN’, ‘ESCRITÓRIO’);
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (2, ‘NOTEBOOK’, 2500, ‘UN’, ‘ESCRITÓRIO’);
INSERT INTO PRODUTOS (PROD_CHAVE, PROD_DESCRI, PROD_VPRECO, PROD_
UNIDAD, PROD_FAMILI) VALUES (3, ‘SABÃO EM PÓ’, 9.00, ‘UN’, ‘LIMPEZA’);
/* 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’);
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 (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*/
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); 
INSERT INTO VENDEDOR (VEN_CHAVE, VEN_NOME, VEN_CNPJ_CPF, VEN_
TIPOPESSOA, VEN_INSCRESTADUAL, VEN_STATUS, VEN_EMAIL, VEN_VPERCENT_COMIS) 
VALUES (2, ‘MALU REPRESENTAÇÃO’, ‘48.825.337/0001-64’, ‘J’, ‘ISENTO’, 
‘ATIVO’, ‘comercial@malurepresenta.com.br’, 2.0);
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);
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 (2, ‘15/02/2015’, 0, 
0, 0, 0, 0, 4800, 5000, 0, 2, 2, 200);
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’);
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, 2, 1, 9, 1000, 9000, 0, 0, ‘NOTEBOOK’);
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, 3, 1, 100, 9.00, 900, 0, 0, ‘SABAO EM PÓ’);
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 (2, 1, 1, 5, 1000, 5000, 0, 0, ‘NOTEBOOK’);
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);
CONCLUSÃO
169
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 inal. 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 classiicação que apresentamos – e terá, com certeza, uma pontinha de dúvida a 
respeito de se deve mesmo utilizar um banco de dados relacional. Ainal, 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. Ainal, 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!
REFERÊNCIAS
171
10 curiosidades sobre o Google. Olhar Digital. Disponível em: <http://olhardigital.
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.
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..
GABARITO
UNIDADE I
1. Atomicidade se relete, por exemplo, em transações bancárias. Enquanto o com-
provante ou outra forma de conirmaçã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 coniável, garantindo que a informação exibida é iel 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 ar-
quivo comum de texto pode resolver o problema, sem a necessidade de implemen-
tação de um sistema de gerenciamento destes dados, ou em casos onde os dados 
armazenados sejam extremamente simples como na coniguração e um maquiná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.
UNIDADE II
1) A partir do estudado nesta unidade, deina Entidades Concretas e Entidades Abstratas.
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).
GABARITO
173
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) Classii caçã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…”.
Secretária Pacientes Médico
Agenda ou
 Atendimento
c) “...é necessário cadastrar os produtos para realizar as vendas aos clientes...”
Vendas ClientesProdutos
GABARITO
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),
 sobrenome 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)
 );
 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)
 );
GABARITO
175
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”
UNIDADE IV
1. CREATE TABLE plano (
 id INT PRIMARY KEY,
 nome VARCHAR(30),
 valor DECIMAL(7,2)
 );
 CREATE TABLE beneiciario (
 id INT PRIMARY KEY,
 nome VARCHAR(30),
GABARITO
 sobrenome 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),
 sobrenome VARCHAR(30),
 beneiciario_fk INT NOT NULL,
 FOREIGN KEY (beneiciario_fk) REFERENCES beneiciario(id)
 );
2.a. SELECT beneiciario.nome FROM beneiciario INNER JOIN dependente 
ON beneiciario.nome = dependente.nome;
2.b. SELECT beneiciario.nome FROM beneiciario WHERE nome IN ( SELECT 
nome FROM dependente WHERE beneiciario.nome = dependente.nome );
2.c. SELECT beneiciario.nome FROM beneiciario WHERE EXISTS ( SELECT* 
FROM dependente WHERE beneiciario.nome = dependente.nome );
2.d. SELECT nome FROM beneiciario WHERE ( SELECT MAX(altura) from 
dependente );
3.a. SELECT sobrenome, altura FROM beneiciario GROUP BY nome;
3.b. SELECT beneiciario.nome FROM beneiciario WHERE ( SELECT COUNT(*) 
FROM dependente WHERE dependente.beneiciario_fk=beneiciario.id and 
dependente.sobrenome=beneiciario.sobrenome 
GROUP BY beneiciario.nome) > 1
3.c. SELECT plano.nome FROM plano WHERE ( SELECT COUNT(*) FROM benei-
ciario WHERE beneiciario.altura > 1.75 AND beneiciario.plano_fk = plano.id );