Banco de Dados

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 
(Reimpressão revista e atualizada)
 Maringá-Pr.: UniCesumar, 2016. 
 171 p.
“Graduação - EaD”.
 
 1. Banco. 2. Dados . 3. EaD. I. Título.
CDD - 22 ed. 005
CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Direção Operacional de Ensino
Kátia Coelho
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida 
Direção de Relacionamento
Alessandra Baron
Gerência de Produção de Conteúdo
Juliano de Souza
Supervisão do Núcleo de Produção de 
Materiais
Nádila de Almeida Toledo
Coordenador de Conteúdo
Danillo Xavier Saes
Design Educacional
Paulo Victor Souza e Silva
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
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 desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quan-
do investimos em nossa formação, seja ela pessoal 
ou profissional, nos transformamos e, consequente-
mente, transformamos também a sociedade na qual 
estamos inseridos. De que forma o fazemos? Criando 
oportunidades e/ou estabelecendo mudanças capa-
zes de alcançar um nível de desenvolvimento compa-
tível com os desafios que surgem no mundo contem-
porâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialó-
gica e encontram-se integrados à proposta pedagó-
gica, contribuindo no processo educacional, comple-
mentando sua formação profissional, desenvolvendo 
competências e habilidades, e aplicando conceitos 
teóricos em situação de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais 
têm como principal objetivo “provocar uma aproxi-
mação entre você e o conteúdo”, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos 
conhecimentos necessários para a sua formação pes-
soal e profissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser 
apenas geográfica. Utilize os diversos recursos peda-
gógicos que o Centro Universitário Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA – Ambiente 
Virtual de Aprendizagem, interaja nos fóruns e en-
quetes, assista às aulas ao vivo e participe das discus-
sões. Além disso, lembre-se que existe uma equipe de 
professores e tutores que se encontra disponível para 
sanar suas dúvidas e auxiliá-lo(a) em seu processo de 
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
Diretoria Operacional 
de Ensino
Diretoria de 
Planejamento de Ensino
A
U
TO
RE
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 especificamente para contribuir com sua formação, como futu-
ro(a) desenvolvedor(a) de software. Esperamos que você tenha um bom proveito do 
material.
Confessamos que foi um tremendo desafio escrever este material. Até certo ponto, é 
uma repetição cansativa dizer que o ritmo das mudanças e das inovações cada vez mais 
se acelera, mas, a princípio, o tema “Banco de Dados” aparentaria ser algo tranquilo, pelo 
fato de ser uma área de conhecimento bastante consolidada. Ledo engano. Nos últimos 
cinco anos, a disciplina de Banco de Dados passou por profundas transformações que 
chacoalharam os alicerces de fundamentos criados e utilizados desde a década de 1970. 
Os desafios dos sistemas de informação atuais exigem que manipulemos não gigabytes 
ou terabytes de informações, e sim petabytes, exabytes e zetabytes.
Os sistemas de informação das gerações anteriores tinham como objetivo gerar infor-
mações que pudessem agregar valor aos processos de negócios. Pois bem, esse objetivo 
foi alcançado. Com a tão aguardada e estimulada “onipresença” de software, a magnitu-
de dessas informações geradas cresceu. Redes sociais,smartphones, tablets, sensores 
de automação e vários outros dispositivos geram inúmeros bits de informação em todo 
momento. Conceitos antigos já não são soberanos nesses inóspitos ambientes atuais. 
Diante desses cenários, surgiram os conceitos de Big Data e NoSQL.
Mas, para irmos mais longe e chegarmos a esse ponto, devemos dar o primeiro passo. 
Este material aborda os conceitos que até recentemente eram considerados como as 
“regras sagradas” de banco de dados: os bancos de dados relacionais. E não se engane, 
caro(a) leitor(a), esses fundamentos de bancos de dados relacionais são imprescindíveis 
para que se possa dar o “próximo passo” rumo ao conhecimento de Big Data e NoSQL.
Na unidade I, teremos a apresentação de tópicos conceituais e definições sobre bancos 
de dados, sistemas gerenciadores de bancos de dados e os tipos de usuários que intera-
gem com esses sistemas. Teremos também uma breve explanação sobre o conceito de 
transações, que é uma ferramenta essencial no desenvolvimento de aplicações mais tra-
dicionais como aquelas que envolvem dados financeiros. Como leitura complementar, 
temos um texto de Cezar Taurion (Evangelista Técnico da IBM) falando sobre Big Data. 
Afinal, é importante darmos um passo no presente, mas sempre com um olho no futuro. 
Essa será a tônica das nossas leituras complementares e sugestões de vídeos: apresen-
tar-lhe sempre os conceitos de vanguarda que já são aplicados em muitos casos de uso 
em aplicações modernas.
A unidade II apresentará a terminologia e outros conceitos básicos que serão utiliza-
dos no restante deste material, descrevendo o modelo relacional de banco de dados 
propriamente dito que será abordado na unidade V. A partir desse ponto, você estará 
apto(a) a identificar as características de modelos relacionais e passar a construir seus 
próprios modelos de dados baseado(a) nos fundamentos apresentados. Na modelagem 
relacional, você identificará entidades do seu domínio de negócios, suas restrições 
e os relacionamentos entre as diversas entidades modeladas.
Nas unidades III e IV, aprenderemos a linguagem SQL (Structured Query Language), 
que é uma ferramenta dominada por 10 em cada 10 desenvolvedores de software 
que utilizam sistemas de banco de dados. De conceito simples, acreditamos que 
não será um problema para você, futuro(a) desenvolvedor(a) de software. Mas con-
vém ressaltar que SQL possui uma natureza declarativa, que é diferente das lingua-
gens imperativas, como Java, C ou Pascal. Após sua criação, a SQL tornou-se um 
padrão de facto para manipular informações em sistemas de banco de dados por 
meio de seus comandos para inserção, atualização, remoção e consulta de instân-
cias de dados. Na unidade V, você terá um estudo de caso completo que o(a) ajudará 
na compreensão de todo o conteúdo estudado.
E, antes que você possa apreciar o conteúdo do material, permita-nos apresentar 
nosso ponto de vista para reflexão: em muitas empresas, o sistema de banco de 
dados tornou-se o repositório “sagrado” das informações, trancado a sete chaves 
e reservado ao guardião denominado de DBA (DataBase Administrator). Aliás, é 
bastante comum que os alunos aprendam ou venham a concluir que o banco de 
dados é o coração de um sistema de informação – baseados nessas falsas impres-
sões transmitidas, até certo ponto, em grande quantidade. Para nós e também para 
muitos autores renomados do mundo do software, o banco de dados é apenas uma 
ferramenta utilizada na construção de nossos sistemas de informação. E, como toda 
e qualquer ferramenta, não pode ficar acima do próprio código que atende ao pro-
cesso de negócios da empresa. Isso diminui sua importância? Certamente que não! 
Porém, quando você modelar seu sistema de informação, pense primeiro no seu 
modelo de negócios e postergue até o último momento a sua visão sobre o banco 
de dados. Tenho certeza de que isso tornará a sua aplicação muito melhor projetada 
e permitirá que ela ofereça um retorno muito melhor ao seu negócio.
O banco de dados é só um detalhe, um detalhe importante, mas o considere um 
detalhe. O coração da sua aplicação é o código bem feito que você elaborará para 
atender ao seu negócio. Pense nisso e, a cada batida desse coração, você poderá 
usufruir de muito retorno (e muito dinheiro, espero).
Um bom proveito e uma ótima leitura!
Prof. Me. Edson Yanaga
Prof. Esp. Victor de Marqui Pedroso
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 
38 Considerações Finais 
UNIDADE II
MODELO RELACIONAL
43 Introdução
44 O Modelo Relacional 
46 Introdução à Modelagem 
51 Atributos 
52 Tipos de Atributos 
56 Domínio 
57 Chave Estrangeira (Foreign Key) 
58 Relacionamentos 
61 Cardinalidade 
65 Considerações Finais 
SUMÁRIO
UNIDADE III
SQL BÁSICO
71 Introdução
73 Definições de Dados e Tipos em SQL 
77 Restrições 
79 Consultas Básicas em SQL 
85 Comandos de Modificação de Dados em SQL 
94 Considerações Finais 
UNIDADE IV
MAIS SQL
99 Introdução
100 Consultas Envolvendo NULL 
101 Consultas Aninhadas (Subqueries) 
105 Consultas Utilizando Joins 
110 Comandos de Alteração de Schema 
122 Considerações Finais 
SUMÁRIO
11
UNIDADE V
ESTUDO DE CASO
127 Introdução
132 Descrevendo o Estudo de Caso 
133 Criando as Entidades e os Relacionamentos (DER) 
141 Trabalhando com SQL 
160 Considerações Finais 
167 Conclusão
169 Referências 
171 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 desafio crescente dos pró-
ximos anos é encontrar formas eficientes de processar os dados que já temos e 
ainda criar para gerar conhecimento e, consequentemente, riqueza.
Nas últimas décadas, boa parte do software desenvolvido envolve mais do 
que processamento de informações. As informações de entrada e de saída do 
software (além de outras metainformações intermediárias) devem ser armaze-
nadas em um mecanismo confiável e que possibilite o acesso simples e rápido à 
leitura e escrita dessas informações.
Há alguns anos, escrever sobre o tema “banco de dados” seria uma tarefa 
relativamente tranquila, pois muitos acreditavam tratar-se de um assunto abso-
lutamente consolidado. Mas o nosso mundo está em constante mudança e os 
modelos de negócios que surgiram recentemente provocaram uma ruptura na 
forma de se pensar o armazenamento de informações em bancos de dados.
Mas de onde vem esse termo, que conhecemos como “banco de dados”? 
Pois, em inglês, o termo refere-se a databases, que em uma tradução literal defi-
niríamos como “base de dados”. Um bom palpite quanto a isso, remete a uma 
visão generalizada de que as instituições denominadas de “bancos”, guardam de 
modo bastante seguro o nosso dinheiro. Os “bancos de dados” seriam, então, 
ferramentas que guardariam nossas informações (dados) de modo também 
supostamente seguro e confiável.
Outra confusão bastante comum e plenamentejustificada refere-se à dife-
rença entre os termos “banco de dados” e os sistemas que o gerenciam. Segue 
uma definição, segundo Navathe (2011, p. 3):
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
15
CONCEITOS DE BANCOS DE DADOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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 significado 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 Microsoft Access ou Excel. Essas informa-
ções são uma coleção de dados com um significado 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 software especializado que 
é desenvolvido especificamente com o propósito de se gerenciar essas coleções de 
dados: os sistemas gerenciadores de banco de dados – popularmente reconhecidos 
pela sigla SGBD (ou DBMS – DataBase Management Systems, na sigla original 
em inglês). Segue mais uma definição de Navathe (2011, p. 3) sobre o termo:
Um sistema gerenciador de banco de dados (SGBD) é uma coleção 
de programas que permite aos usuários criar e manter um banco de 
dados. O SGBD é, portanto, um sistema de software de propósito geral 
que facilita os processos de definição, construção, manipulação e com-
partilhamento de bancos de dados entre vários usuários e aplicações. A 
definição de um banco de dados implica especificar os tipos de dados, 
as estruturas e as restrições para os dados a serem armazenados em um 
banco de dados.
Embora não seja necessário utilizar um SGBD para se desenvolver quaisquer 
sistemas de software, tal opção não se mostra viável. Relembrando o nosso con-
ceito, de que a importância do software consiste em sua capacidade de se gerar 
valor com as informações que manipula, tem-se que implementar nosso pró-
prio mecanismo de manipulação de dados lembrando que nossas aplicações 
não geram valor, somente custo. É por esse motivo que atualmente definimos 
os SGBDs em uma categoria de software que consideramos como commodity.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
17
Exemplos de SGBDs relacionais (mais tradicionais e consolidados) incluem 
Oracle, DB2, SQL Server, Access, PostgreSQL, MySQL, Derby e H2. Já exem-
plos de SGBDs não relacionais (também conhecidos como NoSQL) incluem 
MongoDB, Redis, Neo4j e Riak.
Para propósitos de definição, finalizaremos denominando o conjunto for-
mado pelo banco de dados e o sistema que o gerencia, o SGBD, de Sistema de 
Banco de Dados.
BANCOS DE DADOS OPEN SOURCE: PRESENTE OU FUTURO?
Cezar Taurion
Nos eventos sobre Open Source, volta e meia surge uma pergunta sobre bancos de da-
dos Open Source. Bem, tenho minha opinião pessoal e quero compartilhar com você. 
Vamos ver se vai gerar muita discordância.
Os softwares de banco de dados são um dos mais importantes componentes de softwa-
re de uma organização. Nesse ambiente, as alternativas de software livre já são bastante 
conhecidas e frequentemente são mencionadas na mídia, como MySQL, PostgreSQL, 
Ingres e Derby. 
O MySQL é um produto de uma empresa privada, a MySQL AB. Seu código é desenvolvi-
do pelos funcionários da empresa e com isso ela garante a propriedade intelectual sobre 
o produto. Existe uma comunidade envolvida, mas submissões de código são restritas 
apenas à correção de bugs. Uma pergunta: o MySQL pode ser considerado realmente 
Open Source, uma vez que não adota o modelo de desenvolvimento colaborativo? O 
MySQL é ofertado tanto em GPL como sob licença comercial. As duas versões são fun-
cionalmente equivalentes, sendo diferenciadas pelo nível de suporte e certificação. In-
discutivelmente é o banco de dados Open Source mais popular, com o maior mindshare 
do setor.
Outro software é o PostgreSQL, que tem suas origens no Postgres desenvolvido pela 
Universidade de Berkeley. Podemos citar também o Ingres, que foi um banco de dados 
da Computer Associates e agora pertence a uma organização independente, a Ingres 
Corporation (<www.ingres.com>) e o Derby, originalmente o Cloudscape da IBM e re-
centemente doado para a Apache Software Foundation, onde agora é o projeto Derby. 
O Derby (<http://db.apache.org/derby/>) é um banco de dados em Java, geralmente 
embarcado em outros softwares. A IBM, por exemplo, o utiliza embutido em diversos 
softwares das famílias WebSphere, Tivoli e Lotus. 
Nas minhas andanças pelo mercado tenho visto que na prática os bancos de dados 
Open Source só aparecem como competidores dos produtos mais avançados nas apli-
cações pouco sofisticadas ou bem específicas. 
Por sua vez, os sistemas de banco de dados proprietários buscam competir com funcio-
nalidades diferenciadoras, principalmente as relacionadas com administração de am-
bientes complexos; escalabilidade; desempenho com grande volume de transações; alta 
disponibilidade e capacidade de recuperação rápida; e recursos de data warehousing. 
Além disso, foi criado um ecossistema de negócios em torno dos principais softwares de 
banco de dados proprietários, com diversas empresas independentes oferecendo ferra-
mentas de software complementares (geradores de relatórios, analisadores estatísticos 
e outros), serviços de suporte técnico especializado e formação de recursos humanos, 
e assim por diante, o que também cria uma barreira de entrada difícil de transpor por 
qualquer novo entrante. 
19 
Já o ecossistema empresarial criado em torno dos bancos de dados Open Source (onde 
se gera dinheiro) ainda é incipiente, sendo formado por pequenas empresas com 
abrangência de atuação bastante limitada. Ano passado, a MySQL gerou cerca de 50 
milhões de dólares em receita (<http://news.com.com/MySQL+hits+50+million+reve-
nue,+plans+IPO/2100-7344_3-6179290.html>), mas ainda é um traço (cerca de 0,03%) 
no gráfico que mostra o mercado global de bancos de dados relacionais, estimado pelo 
IDC em 16 bilhões de dólares. Como comparativo, o IDC estima que, nesse mesmo ano, 
a receita da IBM com a família de produtos DB2 foi de aproximadamente 3,5 bilhões de 
dólares.
Qual o papel que os bancos de dados Open Source desempenharão? Na minha opinião, 
estarão atuando (pelo menos nos próximos 3 a 4 anos) na chamada faixa de produtos 
com funcionalidades comoditizadas, onde as características de preço são as de maior 
importância. Os usuários típicos serão organizações e aplicações que não precisam de 
recursos mais sofisticados. 
Como avaliar a qualidade de um banco de dados Open Source? Existem diversos crité-
rios que podem e devem ser considerados em uma análise para seleção de um banco de 
dados. Os níveis de importância das variáveis da análise estão diretamente relacionados 
com os objetivos do negócio e das necessidades a serem impostas aos softwares de 
bancos de dados.
Alguns dos principais fatores a serem considerados são:
a. Recursos de gerenciamento e administração. São as ferramentas de apoio às ta-
refas do administrador do banco de dados.
b. Desempenho e escalabilidade. Os recursos que o softwareoferece para garantir 
desempenho adequado, nos volumes de transações que serão demandados.
c. Recursos técnicos. Disponibilidade de recursos como triggers, stored procedu-
res, cursors, subqueries, capacidade de replicação, recursos de indexação, aderência 
a padrões (ANSI SQL), particionamento, backup/recovery, suporte a dados não es-
truturados, independência de plataforma e recursos de segurança.
d. Custos de Propriedade.
e. Suporte técnico e disponibilidade de recursos humanos. Abrangência do ecos-
sistema em termos de serviços de suporte e qualificação de recursos humanos.
f. Disponibilidade de aplicativos.
g. Recursos de data warehousing e BI.
h. Recursos de desenvolvimento de aplicações.
i. Modalidade de licenciamento.
j. Visão, estratégia e road map do produto.
k. Tamanho e participação/envolvimento da comunidade.
l. Modelo de governança adotado pela comunidade.
m. Base instalada e adoção pelo mercado.
Bem e quanto a uma pergunta que muitos me fazem... Minha empresa deve adotar um 
banco de dados Open Source? Para mim, para mudar um software de banco de dados 
deve haver uma estratégia impulsionada por razões fortes e consistentes. Por exemplo, 
se houver desconfianças que o atual fornecedor esteja saindo do mercado; falta de fun-
cionalidade do software (não é mais adequado às necessidade das novas aplicações da 
empresa); falta de visão estratégica por parte do fornecedor do software atual; custos de 
manutenção e operação muito elevados para o resultado obtido; falta de pessoal gaba-
ritado, que esteja disponível no mercado; carência de consultorias e serviços de suporte 
externos; relacionamento com o fornecedor cada vez mais deteriorado... Mudar para um 
banco de dados Open Source simplesmente por questões ideológicas deve estar fora de 
cogitação, pois banco de dados é muito sério para ser tratado de forma simplista.
OK. E quais seriam então os custos e riscos da migração? Existem custos de migração 
que não podem ser subestimados. Temos os custos da conversão de dados, custos da 
codificação, testes e o que chamamos reconciliação entre as aplicações no novo e no 
antigo ambiente, sempre considerando que dificilmente conseguiremos fazer uma mi-
gração estilo big bang, mas que esta será gradual.
Quanto mais complexas forem as aplicações a serem convertidas, mais custosa será a 
migração. Essa complexidade pode ser medida pelo número de programas, número de 
tabelas relacionais, restrições de integridade referencial e tamanho do banco de dados. 
Existem custos indiretos como a construção de interfaces entre as aplicações já con-
vertidas e as que ainda estão no banco de dados antigo. Também os custos de supor-
te técnicos aos dois ambientes implicam, muitas vezes, em gastos adicionais elevados, 
principalmente quando o novo banco de dados não for de completo domínio da equipe 
técnica da empresa. 
Em resumo, os custos da migração afetam os cálculos de custos totais de propriedade. A 
maioria das empresas é extremamente cautelosa em trocar de fornecedor de softwares 
críticos. O perigo de uma interrupção nos seus negócios decorrente de uma troca mal 
planejada ou inadequada faz com que os custos de troca possam ser extremamente 
elevados e desestimuladores. Migrar de um banco de dados para outro é sempre uma 
tarefa complexa e de alto risco, que só deve ser efetuada quando os benefícios forem 
claramente demonstráveis.
Fonte:Taurion (2007, online).
Características de Sistemas de Bancos de Dados
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
21
CARACTERÍSTICAS DE SISTEMAS DE BANCOS DE 
DADOS
Se utilizar um sistema de banco de dados parece uma solução natural, qual seria 
a solução alternativa? Pense em algumas aplicações que você utiliza e que não 
fazem uso de SGBDs. Processadores de texto, planilhas, ferramentas de dese-
nho etc. são alguns exemplos dessas aplicações. O que todas têm em comum? A 
necessidade de se armazenar a informação manipulada por meio de arquivos.
Em qualquer aplicação que necessite do armazenamento de dados, faz-se 
necessário dispor de algum mecanismo que permita que esses sejam gravados 
de modo persistente. A abordagem de arquivos tem suas vantagens, como, por 
exemplo, a portabilidade dos dados. Você pode carregá-los eletrônica ou fisica-
mente para locais diferentes de modo bastante simples. Mas entre as desvantagens 
dessa abordagem há todo o trabalho necessário para se criar um formato e pro-
cessar a sua gravação e recuperação – e, acredite, não é pouco trabalho!
Um SGBD, por outro lado, já dispõe de uma série de funcionalidades prontas 
para serem utilizadas pelo desenvolvedor da aplicação. Desse modo, uma série 
de preocupações passa a ser delegada a um software de terceiros (o SGBD). A 
seguir, apresentaremos uma série de características que diferenciam a aborda-
gem de sistemas de banco de dados da manipulaçã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
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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íficas 
é uma abordagem muito utilizada em sistemas cliente/servidor ou na integra-
ção de aplicações mediante banco de dados. O auge do uso dessas abordagens 
deu-se no final da década de 1990, embora ainda hoje seja possível testemu-
nhar aplicações sendo executadas sob esse modelo. Recomenda-se fortemente 
que, no desenvolvimento de novas aplicações, a abordagem de múltiplas visões 
e de integração mediante banco de dados seja substituída por uma abordagem 
orientada a serviços como SOA (Service Oriented Architecture) ou como REST 
(REpresentational State Transfer).
Visões não são uma má prática. São um recurso bastante útil, mas não 
imprescindível. Como toda ferramenta, quando bem utilizada e de modo ade-
quada, é um recurso valioso.
Acesso concorrente de múltiplos usuários: um SGBD multiusuário, como 
o próprio nome já define, deve permitir o acesso de múltiplos usuários. Além 
disso, o acesso deve ser concorrente, permitindo que todos os usuários conectados 
Características de Sistemas de Bancos de Dados
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
ale
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
23
executem operações “ao mesmo tempo”.
Vale a pena refletir sobre dois termos muitas vezes utilizados de forma errô-
nea na área de Tecnologia da Informação: “paralelo” e “concorrente”. Paralelismo 
puro é algo raro em computação, embora seja perfeitamente possível. Ao lidar-
mos com sistemas de banco de dados, utilizamos o termo “concorrente”, pois 
vários usuários têm a impressão de que estão executando instruções ao mesmo 
tempo – quando na verdade, por se tratar de informações acessadas em disco 
ou com um único barramento de acesso, torna-se necessário algum mecanismo 
de contenção que serialize (coloque em fila) cada uma dessas instruções. Como 
idealmente a execução dessas instruções é bastante curta, tem-se a impressão 
do pseudoparalelismo.
Um conceito fundamental para que o acesso desses múltiplos usuários man-
tenha o banco de dados num estado consistente é o mecanismo de transações, 
que será descrito no próximo tópico.
A REVOLUÇÃO DO BIG DATA ESTÁ PRESTES A ACONTECER
Cezar Taurion
O termo Big Data começa a despertar muita atenção, mas ainda é um conceito mal de-
finido e compreendido. Com uma rápida pesquisa no Google, identifiquei, pelo menos, 
uma dúzia de definições. Neste artigo, vou falar um pouco sobre o assunto e debater 
alguns desafios que temos para conseguir colocar projetos de Big Data em ação. 
Sem entrar em definições e nos atendo apenas a conceitos, podemos resumir com uma 
fórmula simples o que é Big Data: volume + variedade + velocidade de dados. Volume 
porque, além dos dados gerados pelos sistemas transacionais, temos a imensidão de da-
dos gerados pelos objetos na Internet das Coisas, como sensores e câmeras, e os gerados 
nas mídias sociais, via PCs, smartphones e tablets. Variedade porque estamos tratando 
tanto de dados textuais estruturados quanto dos não estruturados, como fotos, vídeos, 
emails e tuítes. E, por fim, velocidade porque, muitas vezes, precisamos responder aos 
eventos quase que em tempo real. Ou seja, estamos falando de criação e tratamento de 
dados em volumes massivos.
Outro desafio: criar e tratar apenas de dados históricos, como o veterano Data Warehou-
se e as tecnologias de BI (Business Intelligence) começam a se mostrar lentos demais 
para a velocidade com que os negócios precisam tomar decisões. Aliás, o termo BI já tem 
mais de 50 anos. Ele foi cunhado por Hans Peter Luhn, pesquisador da IBM em um artigo 
escrito nos idos de 1958.
Quando falamos em volume, os números são gigantescos. Se olharmos globalmente, 
estamos falando em zetabytes ou 10²¹ bytes. Grandes corporações armazenam múlti-
plos petabytes e mesmo as pequenas e médias empresas trabalham com dezenas de 
terabytes de dados. Esse volume tende a crescer geometricamente. Em um mundo cada 
vez mais competitivo e rápido, as empresas precisam tomar decisões baseadas não ape-
nas em palpites, mas em dados concretos. Assim, para um setor de marketing, faz todo 
sentido ter uma visão 360° de um cliente, olhando não apenas o que ele comprou da 
empresa, como registrado no ERP, mas saber o que ele pensa e diz sobre a empresa e 
como os faz - pelo Facebook e Twitter, por exemplo. 
Hoje, já é consenso que dados são os recursos naturais da nova Revolução Industrial. Na 
atual sociedade industrial, ter apenas recursos naturais, como minério, e exportá-los de 
forma bruta - importando em troca produtos manufaturados - não garante a competiti-
vidade de um país no longo prazo. O importante é a tecnologia e o conhecimento que 
cria produtos manufaturados. Afinal, um quilo de satélite vale imensamente mais do 
que um quilo de minério de ferro. 
Fazendo um paralelo, na sociedade da informação, é crucial saber tratar dos dados na 
velocidade adequada. Dados não tratados e analisados em tempo hábil são dados inú-
teis, pois não geram informação. Dados passam a ser ativos corporativos importantes e, 
25 
como tal, podem - e deverão - ser quantificados economicamente.
Big Data representa um desafio tecnológico, pois demanda atenção à infraestrutura e 
tecnologias analíticas. O processamento de volumes massivos de dados pode ser facili-
tado pelo modelo de computação em nuvem, desde, é claro, que esse imenso volume 
não seja transmitido repetidamente via Internet. Só para lembrar, os modelos de co-
brança pelo uso de nuvens públicas tendem a gerar processamentos muito baratos, mas 
tornam caro a transmissão de muitos dados. 
A principal base tecnológica para Big Data Analytics é o Hadoop e os bancos de dados 
NoSQL, onde “No” significa Not Only SQL, ou seja, usa-se bases de dados SQL e não SQL. 
A importância do “Not Only” SQL explica-se pelo fato do modelo relacional ser base-
ado na época de sua criação, no início dos anos 70. Nessa época, acessar, categorizar 
e normalizar dados era bem mais fácil do que hoje. Praticamente não existiam dados 
não estruturados circulando pelos computadores da época. Também não foi desenhado 
para escala massiva ou para um processamento muito rápido. Seu objetivo básico era 
possibilitar a criação de queries que acessassem bases de dados corporativas e, portan-
to, estruturadas. Para soluções Big Data, tornam-se necessárias várias tecnologias, desde 
bancos de dados SQL a softwares que utilizem outros modelos, que lidem melhor com 
documentos, grafos, processamento paralelo etc.
A complexidade do Big Data vem à tona quando lembramos que não estamos falan-
do apenas de armazenamento e tratamento analítico de volumes massivos de dados, 
mas de revisão, ou criação, de processos que garantam a qualidade desses dados e de 
processos de negócios que usufruam dos resultados obtidos. Portanto, Big Data não 
é apenas um debate sobre tecnologias, mas, principalmente, sobre como os negócios 
poderão usufruir da montanha de dados que está agora à sua disposição. Aí emerge a 
questão da integração: como integrar bases de dados estruturadas e não estruturadas 
com diversos softwares envolvidos? 
O Big Data abre oportunidades profissionais bem amplas. Na minha opinião, existe es-
paço para dois perfis profissionais: um mais voltado para os negócios e qualificados para 
tratar analiticamente as informações geradas por essas imensas bases de dados e outro 
com viés mais técnico ou Data Architect.
Pelo viés dos negócios, um artigo interessante que foi publicado há poucos meses pelo 
Wall Street Journal, na edição brasileira, aponta como problema a escassez de talentos. 
Ele fala que muitas empresas americanas começaram a procurar profissionais que sai-
bam interpretar os números usando a análise de dados, também conhecida como inte-
ligência empresarial. Mas encontrar profissionais qualificados tem se mostrado difícil. 
O resultado foi que várias faculdades americanas, como a Faculdade de Pós-Graduação 
em Administração da Universidade Fordham e a Faculdade de Administração Kelley, da 
Universidade de Indiana, começaram a oferecer disciplinas eletivas, cursos de extensão 
e mestrados em análise de dados. Já o Data Architect deve lidar com tecnologias SQL 
e NoSQL, conhecer profundamente conceitos como stream processing e Event Driven 
Architecture (EDA) e, portanto, ter capacidade de desenhar estratégias para manusear 
e analisar grandes volumes de dados de formatos diferentes, quase que em tempo real.
A ideia de stream processing, ou stream computing, é fantástica; é um novo paradigma. 
No modelo de data mining tradicional, uma empresa filtra dados dos seus vários siste-
mas e, após criar um data warehouse, dispara “queries”. Na prática, faz-se uma garim-
pagem em cima de dados estáticos, que não refletem o momento, mas sim o contexto 
de horas, dias ou mesmo semanas atrás. Com o stream computing, essa garimpagem 
é efetuada em tempo real. Em vez de disparar queries em cima de uma base de dados 
estática, coloca-se uma corrente contínuade dados (streaming data) atravessando um 
conjunto de queries. Podemos pensar em inúmeras aplicações, sejam estas em finanças, 
saúde e mesmo manufatura. 
Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de 
fabricação de semicondutores monitora em tempo real o processo de deteção e classi-
ficação de falhas. Com o stream computing, as falhas nos chips que estão sendo fabri-
cados são detetadas em minutos e não em horas ou semanas. Os wafers defeituosos 
podem ser reprocessados e, mais importante ainda, pode-se fazer ajustes em tempo real 
nos próprios processos de fabricação.
Quanto ao EDA, pode-se começar a estudar o assunto acessando seu verbete na Wiki-
pedia. 
O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Aliás, já aparece no 
canto da tela de um ou outro CIO, e, provavelmente, em alguns anos, já será um dos 
temas mais prioritários das tradicionais listas de “tecnologias do ano”. Portanto, é bom 
estar atento à sua evolução e começar a colocar em prática algumas provas de conceito.
Fonte: Taurion (2012, online). 
O maior evento da comunidade brasileira de NoSQL:
<http://nosqlbr.com/>. Acesso em: 27 jul. 2015.
Transações
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
TRANSAÇÕES
O conceito de transação é fundamental em muitas áreas da computação e parti-
cularmente fundamental em sistemas de banco de dados. Consideramos como 
transação uma determinada “unidade de trabalho”, que é realizada em qualquer 
sistema computacional de um modo coerente e independente de outras transa-
ções. Essas transações devem permitir que o sistema esteja num estado coerente 
antes e depois de sua execução, independente de falhas ou outros problemas que 
possam ocorrer. Devem permitir também que vários clientes diferentes acessem 
concorrentemente o sistema sem que isso possa corromper ou levar a estados 
que não sejam considerados coerentes.
Uma definição clássica do conceito de transações envolve o acrônimo 
ACID, oriundo das propriedades de Atomicidade, Consistência, Isolamento e 
Durabilidade.
Atomicidade: a propriedade atomicidade de banco de dados advém do con-
ceito de átomo da física – o qual até recentemente supunha-se indivisível. Essa 
indivisibilidade pressupõe que as operações realizadas numa transação sejam 
todas realizadas por completo ou que nenhuma seja realizada. Popularmente 
seria o conceito do “tudo ou nada”. Isso permite que durante a nossa interação 
com um banco de dados possamos agrupar vários comandos relacionados com 
a garantia de que todos sejam executados – de modo que as informações arma-
zenadas permaneçam num estado consistente após a execução da transação.
CONCEITOS DE BANCOS DE DADOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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 finalizada com sucesso, os dados terão a garantia de terem 
sido armazenados corretamente – independentemente da eventualidade de falhas, 
falta de energia, erros de aplicação etc.
Em nossa opinião, é justamente a propriedade de durabilidade que faz com 
que os bancos de dados sejam posicionados como “ferramentas sagradas” em 
muitas empresas. Novamente, não há menosprezo algum em dizer que o mais 
importante é o código que atende aos processos de negócios. Durabilidade é 
essencial: imagine qualquer empresa perdendo todos os seus dados. A continui-
dade do próprio negócio está em risco. Mas mais importante do que os dados 
em si é o uso que se faz deles.
Transações
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
29
Sistemas tradicionais que vêm sendo desenvolvidos nas últimas décadas 
sempre tiveram como premissa em seus dados sua corretitude (grau em 
que o software executa suas funções de modo correto). Isso normalmente 
implicou na utilização de um banco de dados que pudesse satisfazer as pro-
priedades ACID.
Com o aumento da quantidade de informações e usuários nas aplicações, o 
fator disponibilidade passou em alguns casos a ser mais importante do que 
a própria consistência das informações.
Além do ACID, surgiu o acrônimo BASE (Basically Available, Soft state, Even-
tually consistent) – traduzido literalmente como Basicamente Disponível, 
Estado flexível e Eventualmente consistente. O BASE tornou-se uma sigla 
bastante comum ao lidar com bancos de dados não relacionais.
Uma reflexão que vale a pena ser feita é: para os novos desafios e empreita-
das que você, futuro(a) profissional, enfrentará, em quais situações o ACID é 
recomendado e em quais outras situações o BASE mostra-se mais adequa-
do?
Fonte: Pritchett (2008, online). 
CONCEITOS DE BANCOS DE DADOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E30
Papéis assumidos pelos usuários de SGBDs
DESENVOLVEDORES DE 
SGBDS
São pessoas que projetam e codificam os SGBDs. Exem-
plos de pessoas nesses papéis incluem os funcionários 
de empresas como Oracle, IBM e Microsoft que atuam 
diretamente na programação do software SGBD. No caso 
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 qualificados 
que trabalham no código-fonte do SBGD. Mas voluntários 
de projetos de software livre também podem contribuir 
em outras atividades, como documentação, por exemplo.
DESENVOLVEDORES 
DE APLICAÇÕES E 
ADMINISTRADORES 
DE BANCOS DE DADOS 
(DBAS – DATABASE 
ADMINISTRATORS)
São pessoas que desenvolvem software que armazena as 
informações 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 beneficiados pela 
tecnologia dos sistemas de bancos de dados, raramente 
possuem ciência do fato.
Quadro 1: Papéis assumidos pelos usuários de SGBDs
Fonte: os autores.
Vantagens de se Utilizar um SGBD
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
31
VANTAGENS DE SEUTILIZAR 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 justificar seu uso em uma 
diversidade de situações.
1. Diminuir a redundância e fornecer consistência: imagine uma situação 
bastante comum em que você resolve elaborar um documento e necessita 
da colaboração de várias pessoas para fazê-lo. Você então cria o esboço 
desse documento e o envia por e-mail a todos os interessados. Cada pes-
soa realiza as suas modificações em suas próprias cópias dos documentos 
e, depois, repassa novamente por e-mail. Quem tem a última versão do 
documento? Quais são os dados corretos? Essas são perguntas difíceis 
de serem respondidas nessa abordagem e provavelmente exigirá muito 
trabalho manual para se chegar à versão final do documento. Um SGBD 
centraliza todas essas informações, fazendo com que todos os usuários 
acessem os mesmos dados. Desse modo, diminui-se a redundância: há 
somente uma cópia dos dados a serem manipulados. Isso permite tam-
bém que o banco de dados sempre permaneça em um estado consistente, 
pois todos os usuários terão sempre a “última versão” dos dados. Não há 
a possibilidade de alguém permanecer com um “pedaço” dos dados anti-
gos e outro “pedaço” com a informação atual.
2. Controle de acesso: muitas informações armazenadas em sistemas são 
confidenciais. Ao mesmo tempo, é necessário que essas informações sejam 
compartilhadas com as pessoas para que sejam trabalhadas. Ao utilizar 
arquivos, é necessário que uma cópia seja enviada aos interessados. Por 
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
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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 eficientes: como são aplicações de software de propósito 
específico, os SGBDs são especialmente projetados para armazenar efi-
cientemente os dados a eles delegados e para permitir formas de consulta 
eficientes aos mesmos dados. Cada SGBD possui sua estratégia interna 
para transformar essas informações em bytes gravados no dispositivo de 
armazenamento, mas, de um modo geral, não há uma grande diferença 
de desempenho entre diferentes produtos em uma quantidade razoá-
vel de aplicações. Em casos de usos típicos, é muito mais importante a 
eficiência em consultas do que a eficiência em armazenamento de infor-
mações. Assim, os SBGDs utilizam dispositivos como índices (que são 
estruturas criadas para otimizar consultas baseadas em certos critérios) 
e cachês (caches) para armazenar em memória os dados mais frequente-
mente acessados. Esses dispositivos permitem que as consultas possam 
ser executadas de modo mais rápido e, em muitos SGBDs, adequar esses 
dispositivos de modo otimizado chega a quase ser uma arte, tamanha a 
quantidade de opções disponíveis.
4. Backup e Restore: para garantir a continuidade dos negócios, é essen-
cial executar periodicamente o backup das informações armazenadas 
no servidor. Ao invés de cópias físicas dos arquivos do SGBD, é comum 
os próprios SGBDs fornecerem ferramentas que permitem a exportação 
dos dados para um formato intermediário (texto ou binário) para backup. 
Essas mesmas ferramentas suportam a restauração desses dados em caso 
de necessidade. As rotinas de backup/restore também são uma ferramenta 
bastante útil na migração ou cópia de servidores onde o mesmo SGBD 
esteja instalado. Situações de migração costumam ocorrer em caso de 
falhas ou upgrade de equipamento. Cópias costumam ser utilizadas para 
permitir o teste de aplicações em desenvolvimento.
33 
COMPUTAÇÃO EM NUVEM E ARQUITETURAS DE ARMAZENAMENTO EM 
NUVEM
A computação em nuvem e o armazenamento em nuvem se tornaram o método pre-
ferencial para a distribuição de informações e funcionalidade online. Enquanto alguns 
serviços de nuvem focam em fornecer aos consumidores uma ampla gama de funciona-
lidades e serviços, incluindo compras online, pesquisa, rede social, consumo de entrete-
nimento e proteção de documentos importantes, outros serviços de nuvem focam em 
pequenas empresas, grandes corporações, governos e outras instituições.
Diversos serviços de nuvem oferecem armazenamento em nuvem gratuitamente para 
os consumidores, enquanto outros cobram algum tipo de tarifa com assinatura. Há 
também as nuvens privadas, pertencentes e controladas por uma organização, que for-
necem uma rede segura para o compartilhamento de softwares e dados cruciais. Por 
exemplo, hospitais podem optar por usar serviços públicos de arquivamento para re-
gistros médicos eletrônicos e dados de imagem de pacientes (usando PACS) ou podem 
criar a sua própria solução de arquivamento em nuvem. Além disso, hospitais podem 
juntar seus orçamentos e recursos para criar um consórcio ou grupo de nuvem privada 
compartilhada. Nuvens privadas são criadas usando hardware, software e outras ferra-
mentas de diferentes fornecedores, enquanto os próprios servidores são gerenciados 
interna ou externamente. Nuvens híbridas, como o nome sugere, combinam vários re-
cursos de nuvem pública e privada em um serviço ou solução.
No centro de todos os serviços, produtos e soluções de nuvem estão ferramentas de sof-
tware com três pilares subjacentes de funcionalidade: ferramentas para o processamen-
to de dados e a execução de aplicativos (servidores computacionais), movimentação de 
dados (redes) e preservação ou armazenamento de dados (armazenamento).
Este artigo discute as arquiteturas de armazenamento e computação em nuvem, apro-
veitando o conhecimento fundamental em armazenamento de dados de TI e corpora-
tivos.
Histórico e desafios
A computação em nuvem e o armazenamento em nuvem são os assuntos do momento 
para tratar dos problemas e desafios comuns em TI, além de trazer novas oportunidades. 
Para alguns ambientes, a principal meta é cortar custos e, para outros, sustentar o cres-
cimento. Além disso, alguns ambientes precisam aprimorar objetivos de nível de serviço 
(SLOs) e cumprir acordos de nível de serviço (SLAs) em termos de disponibilidade, de-
sempenho, segurança e proteção de dados.
Os desafios comuns enfrentados pelas soluções em nuvem incluem:
Desafio de TI Solução em nuvem
Orçamentos fixos ou reduzidos Fazer mais com os orçamentos disponí-
veis sem deixar de promover o crescimen-
to
Demanda por nova funcionalidade Agilidade possibilitada pela implementa-
ção rápida
Promover crescimento com estabilidade Elasticidade que promova o crescimento 
com resiliência
Privacidade e segurança de informações Multi-inquilino para coexistência segura
Proteção de dados Continuidade dos negócios e recupera-
ção de desastres flexíveis
Aprimorar o atendimento ao cliente Reduzir o tempo de entrada no mercado e 
possibilitar novas oportunidades
Falta de mobilidade ou flexibilidade Permitir acesso de qualquer lugar a partir 
de diferentes dispositivos
O que são as soluções em nuvem?Soluções em nuvem são ferramentas para a criação e o armazenamento de conteúdo 
ou informações, bem como estratégias de onde e como consumi-los. Essas soluções são 
usadas para criar infraestruturas virtuais para grandes e pequenas organizações hospe-
darem aplicativos e funções comerciais, assim como um local para desenvolver e testar 
novos recursos. Além disso, incluem serviços ou produtos (hardwares, softwares e redes) 
pagos separadamente e soluções que você pode comprar para instalar no seu ambiente 
específico.
Para começar, aqui estão alguns termos e expressões comuns relacionados às soluções 
em nuvem:
• Otimizado e com boa relação custo-benefício: alinha recursos a SLOs para cum-
prir SLAs
• Menu de opções de serviço para escolher: camadas de recursos alinhados a custo 
e SLAs
• Elástico, escalável com estabilidade: promove o crescimento sem adicionar com-
plexidade
• Resiliente, flexível e dinâmico: adaptar-se às necessidades do momento e man-
ter-se disponível
• Provisionamento rápido ou automático: acessa recursos e serviços rapidamente
• Seguro e multi-inquilino (multi-tenant): separação segura de usuários, manten-
do a integridade dos dados
35 
• Medido e gerenciado: métricas para gerenciamento de relatórios, análises e ser-
viços
• Escala na densidade: usar capacidade de multi-inquilino e economias de escala e 
cortar custos
SaaS a PaaS e IaaS
O SaaS (Software as a Service, software como serviço) que é consumido por meio das 
soluções em nuvem inclui entretenimento pessoal e de consumo (Netflix), notícias e 
rede social (Facebook, Skype e Twitter), compartilhamento de fotos, compartilhamento 
de arquivos (Dropbox), serviços de email, música e backup online.
Além de oferecer uma funcionalidade distinta para consumidores, pequenas e grandes 
empresas também utilizam as soluções em nuvem para aumentar a produtividade. Por 
exemplo, compartilhamento de documentos (Google Docs), gestão de relacionamento 
com o cliente ou CRM (Salesforce.com), relatórios de despesas (Concur), folha de paga-
mento (ADP), email, compartilhamento de arquivos, backup e arquivamento. Além de 
apresentar o SaaS, os provedores de serviços de nuvem também oferecem ferramentas 
e ambientes para PaaS (Platform as a Service, plataforma como serviço) para proporcio-
nar o desenvolvimento e a criação de serviços de SaaS entre outros.
Os tipos de camadas de armazenamento para a IaaS (Infrastructure-as-a-Service, infraes-
trutura como serviço) incluem recursos como Web ou máquinas virtuais (VMs), armaze-
namento para compartilhamento de arquivos online, backup ou arquivamento, banco 
de dados, ferramentas de desenvolvimento e busca. Esses recursos possibilitam que os 
próprios provedores de serviços de nuvem e terceiros criem soluções individualizadas 
para combinar diversas funcionalidades ou camadas de nuvem nos serviços oferecidos.
Os serviços de armazenamento em nuvem SaaS incluem compartilhamento de arquivos, 
documentos, música, fotos e vídeo, backup/restauração, continuidade dos negócios e 
recuperação de desastres, juntamente com recursos de arquivamento. Outras opções 
de armazenamento em nuvem incluem banco de dados, análise de dados (incluindo 
serviços baseados em redução em mapa e Hadoop), unidades de nuvem e outras apli-
cações que usam armazenamento em nuvem back-end. As soluções de armazenamento 
em nuvem também se estendem a produtos e soluções usados para implementar nu-
vens públicas, privadas e híbridas.
Produtos e soluções são as peças de armazenamento em nuvem mais comuns dos sis-
temas de armazenamento físico. Os serviços de nuvem privada e pública de SaaS a PaaS 
e IaaS usam armazenamento em camadas, incluindo unidades de estado sólido (SSDs) 
e discos rígidos (HDDs). Assim como os ambientes tradicionais de armazenamento cor-
porativo, os provedores de soluções e serviços em nuvem utilizam uma mistura de ca-
madas de tecnologia de armazenamento diferentes, que atendem a requisitos de SLO 
e SLA diferentes. Por exemplo, a utilização de SSDs rápidas para consolidação de E/S 
densa (oferecendo suporte a registros e índices de bancos de dados, metadados para 
pesquisa rápida e outros dados transacionais) possibilita que mais trabalho seja reali-
zado com menos energia em um espaço (footprint) mais denso e com melhor relação 
custo-benefício.
O uso de uma mistura de SSDs ultra-rápidas com HDDs de alta capacidade cria um equi-
líbrio de desempenho e capacidade para atender a outros requisitos de serviço com 
diferentes opções de custo de serviço.
Com os serviços em nuvem, em vez de especificar qual tipo de unidade física comprar, 
os provedores de serviços de nuvem cuidam disso oferecendo diversas opções de dis-
ponibilidade, custo, capacidade, funcionalidade e desempenho para atender a diferen-
tes requisitos de SLA e SLO.
Arquitetura de nuvem
No cerne da TI legada, a hospedagem, provedores de serviços gerenciados (MSP) e nu-
vens são peças comuns, que incluem tecnologias de rede, processamento e armazena-
mento.
Diferentes tipos de servidores, redes e tecnologias de armazenamento atendem a diver-
sos requisitos de armazenamento em nuvem e computação em nuvem (servidores bla-
de e em rack densos com diferentes números de soquetes e cores a velocidades de GHz, 
threads, quantidade de memória e recursos de expansão de E/S diversos são apenas 
alguns exemplos). As opções de rede incluem 40GbE e 100GbE rápidos para circuitos de 
retorno (backhaul) e de tronco, juntamente com 10GbE e 1GbE mais comuns para redes 
virtuais privadas (VPN) e otimização de largura de banda.
As opções ou camadas de armazenamento de dados incluem SSDs ultra-rápidas, bem 
como HDDs rápidos de capacidade média a alta. Os recursos de gerenciamento de ar-
mazenamento incluem proteção de dados — alta disponibilidade (HA), backup (BC) e 
recuperação de desastres (DR) — assim como redução de volume (footprint) para otimi-
zação de espaço, como compressão, deduplicação e provisionamento fino, o que possi-
bilita que mais informações sejam armazenadas por períodos mais longos a custos mais 
baixos.
As ferramentas de software também são muito importantes na criação de serviços e 
soluções e incluem APIs, middleware, banco de dados, aplicativos, hipervisores para 
criação de máquinas virtuais (VMs) e infraestruturas de desktop virtual (VDI), juntamen-
te com stackware de nuvem, como OpenStack e ferramentas de gerenciamento asso-
ciadas. Alguns exemplos de hipervisores de VMs e VDI são Citrix/Xen, KVM, Microsoft 
Hyper-V, Oracle e VMware ESX/vSphere.
Nos três casos, o armazenamento de dados é configurado em sistemas de armazena-
mento, equipamentos de armazenamento e servidores de computação.
As nuvens públicas são serviços acessível gratuitamente ou mediante o pagamento 
de uma tarifa, que fornecem diferentes funcionalidades, como Amazon Web Services 
37 
(AWS), Google Docs ou software de backup de dados Seagate® EVault®. As nuvens públi-
cas são controladas por seus respectivos proprietários, cujos clientes optam por usar os 
seus serviços. As nuvens privadas, por outro lado, pertencem e são operadas e controla-
das por organizações e são semelhantes aos serviços de TI legados. Entretanto, observe 
que as nuvens privadas criadas usando componentes e serviços públicos e instalações 
externas existentes em diferentes locais de provedores de nuvem são chamadas de nu-
vens híbridas.
A Seagate e o armazenamento em nuvem
A Seagate é líder no fornecimento de armazenamento corporativo e, sem nenhuma sur-
presa, também está no centro da infraestrutura de nuvem. Aproveitando décadas de 
experiência em ambientes de co-localização e serviços gerenciados de alta densidade e 
grande escala para empresas, instituições e governos, a Seagate leva esse conhecimen-
to para os ambientes de nuvem pública e privada. Além da tecnologia de armazena-
mento líder de setor, a Seagatetem décadas de experiência trabalhando com diversos 
parceiros e suas respectivas soluções de armazenamento, embalagem, chassi e gabine-
te, processos de teste e verificação.
Como um fornecedor-chave para provedores de serviços gerenciados e de nuvem pú-
blica e privada, a tecnologia da Seagate pode ser encontrada em ambientes corpora-
tivos e centrais de dados em nuvem e nos provedores de serviços gerenciados para 
pequenas empresas e consumidores. Em outras palavras, a Seagate já está levando o 
armazenamento em nuvem e a computação em nuvem da central de dados para o seu 
bolso há algum tempo!
As opções de armazenamento para os ambientes de armazenamento em nuvem e com-
putação em nuvem da Seagate incluem a família Pulsar® de SSDs de desempenho ultra-
-alto. Para complementar as unidades Pulsar oferecemos os HDDs de alto desempenho 
Savvio® 10K e Savvio 15K de 2,5 polegadas para cenários de densidade mais alta, além 
dos HDDs de baixo consumo de energia Constellation®, que comportam uma configu-
ração com vários terabytes.
A Tabela 1 mostra como e onde a Seagate promove o armazenamento em nuvem e a 
computação em nuvem pública e privada.
Tabela 1. Como a Seagate promove a nuvem
Central de dados: pública, privada, híbrida Empresarial Pessoal
Computação em 
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 fio 
Satellite™
Resumo e próximos passos
Há muitas soluções em nuvem, cada uma oferecendo diferentes serviços, funcionali-
dades e recursos. A funcionalidade e os serviços em nuvem incluindo computação e 
armazenamento são combinados para oferecer SaaS, PaaS e IaaS em soluções de nuvem 
pública e privada. Esses recursos podem ser distribuídos como um serviço, um produto 
ou um conjunto de soluções, também conhecido como ITaaS (IT as a Service, TI como 
serviço). Além disso, os serviços de nuvem são reunidos em infraestruturas públicas e 
privadas para criar nuvens híbridas a fim de atender às suas necessidades e requisitos 
específicos.
A criatividade para satisfazer diferentes necessidades e requisitos de informações são 
determinados por como você ou o seu provedor de serviços usam os recursos de nuvem.
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
39
CONSIDERAÇÕES FINAIS
Nesta unidade, pudemos perceber que os bancos de dados são uma coleção de 
dados relacionados que representam, por meio de um nível determinado de abs-
tração, o modelo do mundo real de nossas aplicações de software. Boa parte das 
aplicações de software desenvolvidas na atualidade envolve a manipulação e, 
principalmente, o armazenamento dos dados – estes muitas vezes em enormes 
quantidades. Para manipular esses bancos de dados, criou-se uma categoria de 
software específico denominada de sistemas gerenciadores de bancos de dados 
(SGBDs). O banco de dados (os dados) e o sistema que o gerencia são denomi-
nados conjuntamente de sistemas de bancos de dados.
Durante esta unidade também descrevemos as características que identificam 
as propriedades de sistemas de bancos de dados quando comparados a aborda-
gens tradicionais de processamento de arquivos. Certamente que determinados 
casos de uso ainda exigem a utilização de arquivos como meio de armazenamento 
das informações. Mas com as informações que detalhamos como características 
desses sistemas de banco de dados, esperamos que você, como desenvolvedor(a), 
possa ter argumentos suficientes para decidir adequadamente entre uma abor-
dagem e outra.
Como existem muitos tipos de usuários diferentes que podem interagir com 
os sistemas de bancos de dados, também apresentamos uma lista não exaustiva 
dos papéis que esses usuários podem assumir nessas interações. Uma máxima 
que devemos sempre utilizar é a “técnica do espelho”. Olhe sempre para o sof-
tware que você desenvolve por meio dos olhos de quem usa. Compreender as 
situações em que cada tipo de usuário interage com um sistema de banco de 
dados permite que tenhamos uma melhor consciência das dificuldades e das 
necessidades que os usuários possuem em cada caso de uso cotidiano da nossa 
vida profissional.
Por fim, tentamos discutir algumas vantagens da abordagem de sistemas de 
bancos de dados em relação à implementação de aplicações sem a facilidade e 
funcionalidade de um SGBD. Claro que, tendenciosamente, um estudioso de sis-
temas de bancos de dados observaria argumentos bastante positivos em relação à 
abordagem dos SGBDs. O papel de um desenvolvedor experiente é distanciar-se 
CONCEITOS DE BANCOS DE DADOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E40
desses apegos a uma determinada tecnologia ou outra e decidir sobriamente qual 
a solução mais adequada para a sua aplicação.
Uma vez entendidos esses conceitos, podemos nos dedicar a estudar melhor 
alguns dos detalhes internos dos modelos utilizados pelos sistemas de bancos de 
dados e das arquiteturas de software existentes que utilizam esses sistemas. Tais 
tópicos serão abordados em nossa próxima unidade.
41 
1. Transações tradicionalmente são melhor entendidas por meio do conjunto de 
suas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilida-
de). Em quais situações da vida real você consegue enxergar a necessidade de 
se executar operações com essas propriedades?
2. Ao enumerar as vantagens de se utilizar um SBGD, fizemos uma comparação 
com a utilização de arquivos para armazenamento dos dados. Tendenciosa-
mente, o SGBD apareceu como o vencedor nas comparações. Quais seriam as 
situações em que os arquivos seriam uma solução mais adequada? Você conse-
gue exemplificar alguma outra situação em que uma terceira alternativa seria 
mais viável?
3. Pense no SBGD como um módulo do sistema ou como uma outra aplicação a 
ser integrada (pois, em muitas concepções modernas, é assim que ele deve ser 
tratado). Uma das características dos SGBDs é o isolamento entre o programa e 
os dados. Quais os benefícios desse isolamento? Em que outras partes do siste-
ma essa característica também pode trazer benefícios?
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 identificação e tratamento de erros, 
realização de pesquisa de dados de maneira rápida e ainda garantir a integri-
dade dos dados, sua expansão foi enorme e aos poucos acabou crescendo tanto 
que tornou-se sinônimo de “banco de dados”. Alguns bons exemplos de ban-
cos de dados relacionais são DB2 (IBM), Oracle e MySQL (Oracle), SQLServer 
(Microsoft), Firebird (software livre), Interbase (Borland) e PostgreSQL (sof-
tware livre).
Agora que já sabemos quais são os bancos de dados relacionais existentes, 
vale lembrar que devemos sempre trabalhar para uma boa operacionalização 
deles e, para que isso ocorra, precisamos nos basear em normas concisas no 
momento da criação de um projeto de bancos de dados. Uma vez que nos apro-
fundemos nos estudos da teoria relacional, estaremos capacitados na criação de 
projetos que sejam corretos, consistentes e bem estruturados, evitando, assim, 
um futuro problema ou retrabalho.
Dada a relevância do assunto, estudaremos o modelo relacional introduzindo 
alguns conceitos fundamentais e importantes desse modelo, sempre mesclando a 
teoria com a prática, utilizando também exemplos concretos e que estejam par-
ticipando mais proximamente da nossa rotina de trabalho e do nosso cotidiano.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
45
MODELO RELACIONAL
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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áfico. O Modelo relacional 
tem uma sólida base formal, construído sob a teoria dos conjuntos, seu nome é 
devido à relação matemática da teoria dos conjuntos e não aos relacionamen-
tos, como muitos pensam. Trata-se de um modelo com estruturas de tabelas e 
alguns conceitos.
O modelo relacional permite a representação da estrutura lógica do projeto 
com uma visão genérica. Sua estrutura é feita de forma clara e simples, possibili-
tando representar os dados do mundo real como objetos denominados entidades 
ou conjunto de entidade. 
Neste livro, estaremos utilizando a notação de Peter Chen (1990), notação 
esta que fora criada, em 1976, pelo Dr. Peter Pin-Shan Chen, que é um cientista 
da computação americano e professor de ciência da computação na Louisiana 
State University, conhecido como criador do modelo entidade relacionamento.
O Modelo Relacional
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
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áfica de um conjunto, 
conjunto este cuja representação física ou gráfica padrão é feita por meio de 
um retângulo com o nome da entidade dentro dele. Para identificarmos uma 
entidade, devemos considerar os objetos, coisas ou algo que seja relevante no 
levantamento dos dados. Segue abaixo alguns exemplos (Figura 3 e Figura 4):
 
Alunos
Carros
Viagem
Aluguel
Figura 3: Exemplo de Entidades
Fonte: os autores.
MODELO RELACIONAL
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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 classificar as Entidades em 
Concretas e Abstratas, em que entidades Concretas são entendidas como objeto do 
mundo real que pode ser separado e distinguível de outro objeto. Já as Entidades 
Abstratas são aquelas que não temos de maneira tangível (intangível). Com isso, 
vale lembrar que, em ambos os Tipos de Entidades, a representação é a mesma. 
A seguir (Figura 4), iremos classificar algumas Entidades:
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
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
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 exemplificar de maneira prática. A comparação dessa fase 
inicial é a mesma de uma obra de uma casa, pois, uma vez que for mal dimen-
sionada a estrutura, podemos ter sérios e irreversíveis problemas no futuro. A 
seguir, seguem dois exemplos de uma análise a partir de uma Descrição Textual 
Narrativa.
MODELO RELACIONAL
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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 necessidade de criação de 3 entidades, sendo elas: FUNCIONÁRIO, 
CLIENTE E GÊNERO.
Exemplo 2:
O nosso cliente entra aqui na loja e escolhe o �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
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P