E-Book Completo - Banco de Dados Relacionais e Não Relacionais - DIGITAL PAGES (Versão Digital)

BANCO DE DADOS BANCO DE DADOS
Banco de Dados Relacionais e não Relacionais

RELACIONAIS E RELACIONAIS E
NÃO RELACIONAIS NÃO RELACIONAIS
Ana Luiza Cerchiari de Andrade Ana Luiza Cerchiari de Andrade
Esta disciplina tem o objetivo de ensinar a mexer em bancos de dados. Para isso, você
entrará em contato com um conteúdo teórico e prático.
Dois programas no decorrer desta disciplina: o MySQL WorkBench e o Mongo DB. O
primeiro funciona para banco de dados relacional e o segundo, para banco de dados
não relacional.
Conceitos sobre tipos de SGBDs relacionais (SQL) e não relacionais (NoSQL) serão pas-
sados, além de serem explanados os tipos de servidores conhecidos e suas aplicações
principais.
Muitas empresas falham na hora de criar um sistema de banco de dados por negligen-
ciarem certas anomalias, inconsistências e redundâncias. Por isso, as tabelas devem
ser planejadas de maneira quadrada, ou seja, devem funcionar como um quebra-cabe-
ça no qual uma tabela interage com outra. Tendo isso em mente, será explicado como
evitar anomalias e inconsistências no ato da concepção das tabelas.
Conceitos de álgebra relacional e cálculo relacional serão explanados para elaborar
lógicas bem fundamentadas.
GRUPO SER EDUCACIONAL
gente criando o futuro
Capa_COD_BDRENR.indd 1,3 20/09/2019 16:26:57

Presidente do Conselho de Administração Janguiê Diniz
Diretor-presidente Jânyo Diniz
Diretoria Executiva de Ensino Adriano Azevedo
Diretoria Executiva de Serviços Corporativos Joaldo Diniz
Diretoria de Ensino a Distância Enzo Moreira
Autoria Ana Luiza Cerchiari de Andrade
Projeto Gráfico e Capa DP Content
DADOS DO FORNECEDOR
Análise de Qualidade, Edição de Texto, Design Instrucional,
Edição de Arte, Diagramação, Design Gráfico e Revisão.
© Ser Educacional 2019
Rua Treze de Maio, nº 254, Santo Amaro
Recife-PE – CEP 50100-160
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio
ou forma sem autorização.
A violação dos direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo
artigo 184 do Código Penal.
Imagens de ícones/capa: © Shutterstock
SER_COD_BDRENR_UNID1.indd 2 20/09/2019 14:10:51

Boxes
ASSISTA
Indicação de filmes, vídeos ou similares que trazem informações comple-
mentares ou aprofundadas sobre o conteúdo estudado.
CITANDO
Dados essenciais e pertinentes sobre a vida de uma determinada pessoa
relevante para o estudo do conteúdo abordado.
CONTEXTUALIZANDO
Dados que retratam onde e quando aconteceu determinado fato;
demonstra-se a situação histórica do assunto.
CURIOSIDADE
Informação que revela algo desconhecido e interessante sobre o assunto
tratado.
DICA
Um detalhe específico da informação, um breve conselho, um alerta, uma
informação privilegiada sobre o conteúdo trabalhado.
EXEMPLIFICANDO
Informação que retrata de forma objetiva determinado assunto.
EXPLICANDO
Explicação, elucidação sobre uma palavra ou expressão específica da
área de conhecimento trabalhada.

Sumário
Unidade 1 - Concepções que abrangem o mundo do Banco de Dados

Objetivos da unidade............................................................................................................ 12
Conceitos básicos de um sistema Gerenciador de Banco de Dados ......................... 13

O que é um SGBD, o que são databases, tabelas e dados..................................... 14
Ciclo de vida de SGBD................................................................................................... 15
Modelos conceituais e modelos externos....................................................................... 17

Tipos de SGBDs e Servidores...................................................................................... 17
Modelos lógicos com base em objetos...................................................................... 22
Modelos lógicos com base em registros................................................................... 24
Normalização......................................................................................................................... 25
Anomalias de inclusão.................................................................................................. 26
Anomalias de exclusão................................................................................................. 27
Anomalias de modificação........................................................................................... 28
Normalização: 1º Forma Normal, 2º Forma Normal e 3º Forma Normal................ 28
O modelo relacional: conceitos......................................................................................... 31

Instalação de Bancos de Dados.................................................................................. 32
Tipos de dados................................................................................................................ 34
Inserindo dados nas tabelas........................................................................................ 37
Modelo relacional na prática em MySQL.................................................................. 38
Sintetizando............................................................................................................................ 43
Referências bibliográficas.................................................................................................. 44

Sumário
Unidade 2 - Operações práticas em MySQL e álgebra relacional

Linguagem de definição de dados de um SGBD – DDL (Data Definition Language)...47

Create............................................................................................................................... 47
Alter com drop e ADD.................................................................................................... 51
Rename e Truncate . ..................................................................................................... 52
Linguagem de manipulação de dados de um SGBD - DML (Data Manipulation Language) 54

Insert................................................................................................................................ 54
Update.............................................................................................................................. 56
Delete............................................................................................................................... 57
Select............................................................................................................................... 58
Álgebra relacional e operadores....................................................................................... 60

Seleção............................................................................................................................ 61
Projeção........................................................................................................................... 62
União................................................................................................................................ 62
Diferença......................................................................................................................... 63
Intercessão..................................................................................................................... 63
Linguagem de controle de transações SGBD - TCL (Transaction Control Language)..... 65

Begin e Rollback............................................................................................................. 66
Commit............................................................................................................................. 66
Sintetizando............................................................................................................................ 68

Sumário
Unidade 3 - Operações teórico-práticas em NoSQL

NoSQL ..................................................................................................................................... 72
Principais características............................................................................................. 72
Técnicas de implementação NoSQL........................................................................... 75
Big Data .......................................................................................................................... 76
Banco de dados orientado a documentos..................................................................... 77

Passos práticos com MongoDB.................................................................................. 81
Ordenação, buscas avançadas, updates e agregação........................................... 82
Utilização de variáveis para operações..................................................................... 85
Exportações e importações no MongoDB................................................................. 87
Banco de dados chave-valor.............................................................................................. 89

Redis: Comandos............................................................................................................ 90
Operações com hashes................................................................................................ 93
Sintetizando............................................................................................................................ 96

Sumário
Unidade 4 - Aprofundamento em NoSQL, grafos, colunas e ACID

Banco de dados orientado a grafos: para que serve ..................................................... 100

Conhecendo os grafos................................................................................................ 100
Conhecendo a linguagem Cypher............................................................................. 102
Banco de dados orientado a grafos: como mexer.................................................... 102

Criando vértices, labels e propriedades.................................................................. 106
Usando o MATCH para fazer pesquisas................................................................... 108
Criando arestas (relacionamentos)........................................................................... 109
Editando e deletando grafos...................................................................................... 112
BASE x ACID......................................................................................................................... 113

ACID................................................................................................................................ 113
Particionamento funcional......................................................................................... 115
Teorema CAP................................................................................................................ 115
BASE x ACID: elementos diferenciadores............................................................... 117
Banco de dados orientado a colunas.............................................................................. 119

Banco de dados orientado a colunas: Teoria sobre o Big Table e o Hbase................ 120
Banco de dados orientado a colunas: teoria sobre o Cassandra....................... 123
Criação de um banco de dados no Cassandra....................................................... 124
Sintetizando.......................................................................................................................... 128
Referências bibliográficas................................................................................................ 129

BANCO DE DADOS RELACIONAIS E NÃO RELACIONAIS 8

Apresentação
Esta disciplina tem o objetivo de ensinar a mexer em bancos de dados. Para

isso, você entrará em contato com um conteúdo teórico e prático.
Dois programas no decorrer desta disciplina: o MySQL WorkBench e o Mon-
go DB. O primeiro funciona para banco de dados relacional e o segundo, para
banco de dados não relacional.
Conceitos sobre tipos de SGBDs relacionais (SQL) e não relacionais (NoSQL)
serão passados, além de serem explanados os tipos de servidores conhecidos
e suas aplicações principais.
Muitas empresas falham na hora de criar um sistema de banco de dados
por negligenciarem certas anomalias, inconsistências e redundâncias. Por isso,
as tabelas devem ser planejadas de maneira quadrada, ou seja, devem funcio-
nar como um quebra-cabeça no qual uma tabela interage com outra. Tendo
isso em mente, será explicado como evitar anomalias e inconsistências no ato
da concepção das tabelas.
Conceitos de álgebra relacional e cálculo relacional serão explanados para
elaborar lógicas bem fundamentadas.
Será explicado como criar tabelas, bancos de dados, como fazer atualiza-
ções (uploads), como deletar informações (delete e remove), como apagar tabe-
las e bancos de dados (drop), como criar gatilhos automáticos que elaboram
funções (triggers), como exportar dados para excel e demais operações de um
banco de dados.
Exemplos de bancos de dados orientados a documentos (no programa
Mongo DB) e a colunas (no programa Cassandra) serão passados.
Este enfoque prático é dado a fim de que o estudante possa ter base teórica
e prática para atuar em empresas públicas ou privadas.

A autora
A Professora Ana Luiza Cerchiari de

Andrade é Mestra em Estudos Analíticos
de Dados em Engenharia e Tecnologia
de Energia pela Universidad Europea del
Atlántico – Espanha (2017), possui For-
mação Continuada em Sql, PHP, jQuery, tuições. É professora de Linguagens de
DataScience, Html5 e CSS3 pela 4Linux Programação para aplicativos e sites,
(2017), possui Formação Específica em Banco de Dados, Redes e Administração
Redes pela Impacta (2017) e em Cisco em faculdades e colégios. Ministrou au-
pelo Senac (2017), possui Pós-graduação las em faculdades sobre Planejamento
em Análise Estatística para Auditorias de Estratégico e Tecnologia da Informação.
Ambientes e Sistemas pela Estácio de Sá Trabalhou com desenvolvimento de si-
(2016) e é Bacharela em Tecnologia da tes e sistemas tanto em empresas como
Informação pela Universidade Anhembi para empresas de 2011 a 2018.
Morumbi – UAM (2006).
Tem uma empresa de tecnologia e atual- Currículo Lattes:
mente ministra aulas em quatro insti- http://lattes.cnpq.br/5870955794360235.
Este material é dedicado a todos aqueles que buscam organização e

estratégia, pessoas sistemáticas e que pretendem ajudar as empresas a
organizarem seus dados. Também dedico este material ao meu amigo
Fabio Carmine, o qual tem trocado comigo experiências profissionais e
acadêmicas ao longo de uma década.

UNIDADE
1 INTRODUÇÃO E
APLICAÇÕES DA
INTELIGÊNCIA
ARTIFICIAL

Objetivos da unidade
Conhecer conceitos e utilidades de SGBD;

Conhecer principais SGBDs e Servidores;
Distinguir modelos de bancos de dados;
Aprender a normalizar bancos de dados;
Aprender composições de tabelas;
Conhecer diversos tipos de tabelas;
Aprender a criar tabelas e bancos de dados de forma introdutória.
Tópicos de estudo
Conceitos básicos de um Sis- Normalização
tema Gerenciador de Banco de Anomalias de inclusão
Dados Anomalias de exclusão
O que é um SGBD, o que são Anomalias de modificação
databases, tabelas e dados. Normalização: 1º Forma Nor-
Ciclo de vida de SGBD mal, 2º Forma Normal e 3º Forma
Normal
Modelos conceituais e modelos
externos O modelo relacional: conceitos
Tipos de SGBDs e Servidores Instalação de Bancos de Dados
Modelos lógicos com base em Tipos de dados
objetos Inserindo dados nas tabelas
Modelos lógicos com base em Modelo relacional na prática
registros em MySQL

Conceitos básicos de um Sistema gerenciador de Ban-
co de Dados
Sistemas Gerenciadores de Banco
de Dados, conhecidos pela sigla SGBD,
são responsáveis por armazenar dados
de empresas. Os dados quando leva-
dos a sério são valiosos, os sistemas de
banco de dados contam com progra-
mas inter-relacionados e destinados a
coletar, registrar, alterar, remover e
consultar dados.
Tanto a coleta de dados quanto o
registro podem ser feitos por meio de:
• canais de comunicação com clien-
tes, como sites, mensagens e aplicativos;
• registros de dados de clientes, co-
laboradores, estoque e de fornecedores
por funcionários específicos responsá-
veis por registrar tais dados.
A alteração e a consulta de dados,
por sua vez, podem ser feitas da seguin-
te maneira:
• pessoas responsáveis pela consulta (gerentes de banco);
• pessoas responsáveis pela alteração de dados (profissionais de Tecnologia da
Informação).
Por conta disso, pessoas com poder ou dever de alterar e consultar dados pre-
cisam ter privilégios especiais para esta função.
ASSISTA
O filme O quinto poder, do diretor Bill Condon, fala sobre
gestão estratégica e segurança em dados. Além de ser
instigante, o filme fala sobre como o compartilhamento de
informações afeta os negócios.

O que é um SGBD, o que são databases, tabelas e dados
A fim de compreender melhor o assunto que abordaremos a seguir, obser-
ve a Tabela 1, de uma empresa fictícia chamada COMNET.
TABELA 1. EXEMPLO DE REGISTROS DE COLABORADORES COM FÉRIAS NO MÊS
Nome-
Endereço Dept Nível-cargo Dias-férias
colaborador
Marcelo Fontes Rua Fito, nº 23 Comercial Operacional 30
Julia Gonzales Rua Expe, nº 37 Financeiro Gerência 20
Márcio França Rua Antunes, nº 22 P&D Analista 30
Fonte: TEOREY et. al, 2014, p. 6. (Adaptado).
Os nomes, endereços e departamentos presentes na Tabela 1 são denomi-

nados dados e a linha horizontal correspondente a cada pessoa é um registro.
Dessa forma, a tabela possui três registros, ou três tuplas (três linhas). Teorey
e alguns estudiosos, que em 2014 publicaram o livro Projeto e Modelagem de
Banco de Dados, apelidam essas tabelas de arquivos. Desse modo, para esses
autores, uma tabela pode ser chamada de arquivo.
Supondo que a COMNET possua ainda outras tabelas, como uma tabela de
registros de produtos, conforme mostrado na Tabela 2.
TABELA 2. EXEMPLO DE REGISTROS PRODUTOS
Num-produto Nome-produto Renovação Valor-mês
001 Plano Premium Anual R$ 150,00
002 Plano Smart Mensal R$ 89,00
003 Plano Família Anual R$ 180,00
004 Plano Empresa Anual R$ 200,00

A empresa ainda pode ter uma tabela de entradas financeiras, de colabora-
dores, etc. Unindo todas estas tabelas, a empresa tem um database. Assim, um
Database, ou Banco de Dados, é uma coleção de tabelas referentes a um deter-
minado grupo. As Tabelas 1 e 2, por exemplo, poderiam ser de um Banco de Dados
chamado Loja_Unidade_Norte. O Diagrama 1 representa este banco de dados.
DIAGRAMA 1. EXEMPLO DE BANCO DE DADOS
TABELA FÉRIAS JANEIRO TABELA FÉRIAS FEVEREIRO TABELA FÉRIAS MARÇO TABELA FÉRIAS ABRIL
TABELA FÉRIAS MAIO TABELA FÉRIAS JUNHO TABELA FÉRIAS JULHO TABELA FÉRIAS AGOSTO
TABELA FÉRIAS SETEMBRO TABELA FÉRIAS OUTUBRO TABELA FÉRIAS NOVEMBRO TABELA FÉRIAS DEZEMBRO
TABELA COLABORADORES
TABELA ENTRADAS FINANCEIRAS
TABELA PRODUTOS
Ciclo de vida de SGBD

Para fazer o Banco de Dados, é recomendado seguir o ciclo de vida de Banco
de Dados disposto no Diagrama 2. O ciclo de vida começa no passo 1, com o le-
vantamento dos requisitos de informação definindo o que será feito de acordo
com as necessidades internas da empresa. Para isso, é necessário fazer reuniões
e, depois dessas reuniões, é necessário ir para o passo 2 e determinar quais ta-
belas serão feitas no projeto lógico.
O passo 3, referente ao projeto físico, deve determi-
nar o hardware ideal, o leiaute e as máquinas necessá-
rias para o processamento. O passo 4, por sua vez, tem
relação com a implementação e a criação do banco em si.
O ciclo de vida serve para ordenar passos e, após sua
realização, o último passo de monitoração deve ser feito
constantemente.

DIAGRAMA 2. CICLO DE VIDA DO BANCO DE DADOS
1
REQUISITOS DE INFORMAÇÃO
FAZER REUNIÃO COM FUTUROS USUÁRIOS DO BANCO DE DADOS E COM OS
DESENVOLVEDORES PARA DESCOBRIR QUAIS DADOS SERÃO UTILIZADOS.
2
PROJETO LÓGICO
DETERMINAR QUAIS TABELAS SERÃO CRIADAS (TABELAS DE PRODUTOS, VENDEDORES,
DEPARTAMENTOS, COLABORADORES, ESTOQUE, FÉRIAS, CONTAS A RECEBER, ETC).
SUPONDO QUE OS VENDEDORES E PESSOAS DO DEPARTAMENTO DE COMPRAS

QUEIRAM CRIAR UMA TABELA DE PRODUTOS. NESSE CASO, É NECESSÁRIO
CHEGAR A UM CONSENSO QUANTO AOS DADOS EXIGIDOS.
DETERMINAR HIERARQUIAS E RELACIONAMENTOS DE TABELAS. POR EXEMPLO, AS

TABELAS “VENDEDORES” E “GERENTES” DEVEM ESTAR RELACIONADAS COM A
TABELA-MÃE CHAMADA “COLABORADORES”. ASSIM, CASO UM VENDEDOR SAIA DA
EMPRESA, TANTO A TABELA COLABORADORES QUANTO A TABELA VENDEDORES
DEVEM DAR BAIXA NA SAÍDA DESTE COLABORADOR.
DETERMINAR TIPOS DE DADOS E MEDIDAS. POR EXEMPLO, SE AS MEDIDAS DE

PRODUTOS SÃO UNIDADES OU CAIXAS, QUAIS DADOS REFERENTES A NOMES
E DADOS PESSOAIS SÃO IMPRESCINDÍVEIS, ETC.
3
PROJETO FÍSICO
DETERMINAR QUAL HARDWARE DOS COMPUTADORES QUE RECEBERÁ OS
PROGRAMAS DO SGBD, QUAL SERÁ A LARGURA DE BANDA NECESSÁRIA, QUAIS
TABELAS E RECURSOS PRECISARÃO DE MAIS DISPONIBILIDADE E ALOCÁ-LOS
NAS MÁQUINAS FÍSICAS E VIRTUAIS CORRETAS.
4
IMPLEMENTAÇÃO E MONITORAÇÃO
CRIAR TABELAS FAZENDO USO DE LINGUAGEM DE DEFINIÇÃO DE DADOS
(LDD) E FAZER CONSULTAS E SELEÇÕES COM COMANDOS DE
LINGUAGEM DE MANIPULAÇÃO DE DADOS (DML).
MONITORAR O DESEMPENHO E A CONSISTÊNCIA DO BANCO DE DADOS, BEM COMO SE O

BACKUP DE DADOS ESTÁ SENDO REALIZADO DE ACORDO COM O ESPERADO.
Fonte: TEOREY et al, 2014, pp. 6-8. (Adaptado).

Modelos conceituais e modelos externos
Antes de explicar os modelos de bancos de dados, é necessário explicar quais
são os SGBD existentes e quais são os servidores mais famosos. De forma an-
tecipada, pode-se dizer que existem alguns tipos modelos de Banco de Dados,
tais como:
• Modelos lógicos com base em objetos
• Modelo Entidade-Relacionamento (ER)
• Modelo Orientado a Objetos (OO)
• Modelos lógicos com base em registros;
• Modelo de Rede
• Modelo Hierárquico
Tipos de SGBDs e servidores

Existem vários SGBD no mercado. Falaremos sobre aqueles que possuem re-
conhecimento e aderência do mercado mundial de tecnologia.
Cabe citar que uma empresa não usa necessariamente apenas um SGBD, ou
seja, as empresas podem mudar a qualquer hora. Conforme mostrado na Tabela
3, os bancos de dados podem ser Relacionais ou Não Relacionais (NoSQL). Essa
diferença será bem explicada mais adiante, porém quando o objetivo for escala-
bilidade e gerenciar grandes volumes dinâmicos de informações, é recomenda-
do utilizar SGBD NoSQL.
TABELA 3. COMPARATIVO ENTRE SGBD FAMOSOS
Nome Saber agir Saber agir
Banco de Dados Open Source (grátis)

bastante avançado. Tem como clientes
PostgreSQL o GreenPeace, Caixa Econômica, Cisco,
Skype e muitos outros. Não exige muito
do hardware.

Banco de Dados Open Source leve,
prático e muito utilizado, talvez o
SGBD gratuito mais utilizado no mundo.
MySQL Este sistema é altamente recomendado
para aplicações web. Twitter, Facebook
e muitas outras empresas utilizam este
SGBD.
Banco de Dados proprietário (pago),

é reconhecido por sua estabilidade,
segurança e robustez. Prático e muito
Microsoft SQL
utilizado, talvez o mais utilizado no
Server
mundo. Como clientes podemos citar
a Vivo, TripAdvisor, Itaú, Microsoft e
Ambev.
Banco de Dados proprietário (pago),

é concorrente direto do SQL Server,
muito utilizado no mundo inteiro e útil
Oracle para grandes empresas. Há autores que
apontam que Oracle seja o SGBD líder
mundial. Empresas como a Amazon, Bank
of America e outras o utilizam.
Banco de dados gratuito Não

Relacional muito famoso. Ele é flexível,
Orientado a Documentos, rápido,
possui altíssima disponibilidade e
Mongo DB
capacidade de suportar enormes
quantidades de dados. Empresas como a
Globo, FourSquare e The New York Times
utilizam (ou utilizaram) este SGBD.
Banco de dados gratuito não relacional

criado pelo Facebook. Por ser orientado
a colunas é muito rápido em pesquisas,
Cassandra descentralizado, otimizado e voltado
para a criação de clusters (grupos de
semelhanças em dados). Utilizado pela
Netflix, Spotify, Instagram, Twitter etc.
Existem alguns servidores online que fazem conexão com os programas baixa-
dos na máquina de banco de dados, o servidor UOL, que dá suporte a diversos
SGBDs, assim como o servidor Azure e o servidor Amazon, que hospedam MySQL,
MongoDB, SQL Server e Postgre. Além disso, os servidores Azure e Amazon pos-
suem tempos de teste gratuitos.
O UOL Host possui vários planos de bancos de dados online bem acessíveis para
os diversos SGBDs já citados. Ao utilizar os servidores para MongoDB, MySQL ou
PostGreSQL em espaços de 512 MB, gasta-se menos que R$ 10,00 ao mês. Já para o
servidor de SQL Server, o preço chega a ser de três a quatro vezes mais caro, girando
em torno de R$ 30,00 reais ao mês. Estimar preços é um tanto arriscado, pois eles
variam. A Figura 1 mostra as opções de Bancos de Dados alocadas no UOL Host.

Figura 1. Captura de tela com locação de servidores de SGBD hospedados no UOL.
Ao escolher um SGBD, o analista e a empresa podem criar os bancos de da-

dos, tabelas e inserir dados por meio de navegadores ou de programas baixados.
No servidor UOL, supondo que a empresa opte pelo MySQL, ela será redire-
cionada para a PHPMyAdmin, conforme mostra a Figura 2, página na qual ela já
pode criar tabelas e inserir dados.
Figura 2. Captura de tela de PHPMyAdmin para MySQL.
Caso a empresa opte pelo servidor Azure, ela deve seguir os seguintes passos:
1. Criar uma conta para teste ou comprar um espaço no site do azure, es-
colhendo entre SQL Server, Mongo DB, MySQL e PostgreSQL (basta digitar em
sites de pesquisa as palavras-chave “mongo db azure” ou “sql azure” para
achar a página de compra).

2. Criar um banco de dados (conforme Figura 3, que mostra a criação em
SQL Server).
3. Baixar o programa do SGBD escolhido (os programas estão classificados
na Tabela 4).
4. Conectar o programa ao servidor.
5. Criar as tabelas e inserir dados.
Figura 3. Captura de tela mostrando como criar bancos de dados “Recebimentos” e “Teste” no servidor Azure.
O Programa SQL Server, após baixado, deve conectar com o servidor, confor-
me mostra Figura 4. É importante destacar que na parte de cima está o progra-
ma SQL Server e, na parte de baixo, está o espaço online azure.
Figura 4. Captura de tela mostrando conexão do Azure com Programa SQL Server.

Figura 5 - A. Quais programas cada SGBD utiliza.
Figura 5 - B. Quais programas cada SGBD utiliza.
Figura 5 - C. Quais programas cada SGBD utiliza.

Figura 5 - D. Quais programas cada SGBD utiliza.
Modelos lógicos com base em objetos

O modelo lógico com base em objetos se divide em Modelo Entidade-Rela-
cionamento e Modelo Orientado a Objetos.
Modelo Entidade-Relacionamento
O Modelo ER, ou Entidade-Relacionamento, considera cada tabela como uma
entidade. Supondo que temos duas tabelas: a Tabela Estoque e a Tabela Vendas.
As duas são entidades e cada tabela possui seus atributos. Supondo que cada
tabela (entidade) tenha os seguintes pontos:
Tabela Estoque (Entidade Estoque)
Cod_Produto (atributo Cod_Produto)
Nome_Produto (atributo Nome_Produto)
Quantidade_Estoque (atributo QTD_estoque)
Preço (atributo Preço)

Tabela Venda (Entidade Vendas)
Data_Venda (atributo Data_Venda)
Cod_Produto (atributo Cod_Produto)
Cliente (atributo_cliente)
Preço (atributo_Preço)
Quantidade_Estoque (atributo QTD_estoque)
Após conhecer o que é entidade, só resta entender o que é relacionamento.
Ainda, pode-se criar uma chave entre as duas tabelas na qual é possível, após
a compra de um produto, que tanto a tabela Estoque quanto a tabela Vendas
subtraiam a quantidade daquele produto no estoque. Dessa forma, se na tabela
Estoque houver duas quantidades de produtos Ecosport, quando a tabela Vendas
registrar uma venda de Ecosport, a tabela Estoque abaixará para uma unidade.
Modelo Orientado a Objetos (OO)
Existe, atualmente, uma explosão de aderência à programação orientada a
objetos por criadores de aplicativos e softwares. Esse método de trabalhar é
muito utilizado em linguagens de programação como Java, C#, PH, etc. Seguindo
esta linha de orientação a objetos, os desenvolvedores de bancos de dados não
ficaram para trás. Para manipular Banco de Dados Orientado a Objetos (BDOO),
existem algumas aplicações, tais como Ozone, CACHÉ, DB4objects e GEMSTONE.
Esse tipo de modelagem é útil para bancos com dados geoespaciais, com
dados multimídia e telecomunicações, ou seja, para dados mais complexos.
O modelo Entidade-Relacionamento (ER) é bem parecido com o Modelo
Orientado a Objetos (OO). Algumas de suas características do modelo OO são:
• Métodos: para fazer manipulações nas tabelas, é necessário criar funções,
também chamadas de métodos. Esses métodos podem ser de invocação de
um atributo, de gravação de um dado, de operações matemáticas, de inclusão,
remoção, etc.
• Herança: cada objeto (tabela) pode herdar carac-
terísticas de outro objeto-pai (tabela). Por exemplo, as
tabelas produtos_de_som e produtos_de_vídeo po-
dem herdar atributos e métodos da tabela produtos, as
tabelas Funcionário e Associados podem herdar atributos
da tabela Pessoas, etc.

• Reconhecimento de padrões: o modelo BDOO é capaz de filtrar imagens
por características visuais, por exemplo, imagens com presença maior de de-
terminadas cores.
• Persistência: os dados possuem persistência, isto é, não deixam de existir
após o encerramento do programa.
Modelos lógicos com base em registros

O modelo baseado em registros relaciona e faz consultas em cima de linhas
de dados. Cada vez que se preenche um formulário, um registro é montado.
Desse modo, a inclusão de um aluno em uma escola é um registro, a inclusão de
um colaborador no banco de dados de uma empresa é um registro, e por aí vai.
Modelo de Rede
O modelo em rede faz ligações entre dados. Se houver duas tabelas, uma de
funcionários e outra de contas a depositar salários e valor do salário, a modela-
gem em rede faz o link, conforme mostra o Diagrama 3.
DIAGRAMA 3. CAPTURA DE TELA DE MODELAGEM EM REDES
Juliana 3833-8877 Cerqueira César Assistente Conta 2241 3500
Marcelo 3833-8876 Moema Gerência Conta 2240 5000
Gabriela 3833-8875 Aclimação Qualidade Conta 2242 2000
Julio 3833-8872 Lapa Comercial Conta 2239 2000
Modelo hierárquico
O modelo hierárquico organiza os registros em árvores,
conforme mostra o Diagrama 4. Dessa forma, para
acessar os dados da funcionária Juliana, é neces-
sário acessar os dados da gerência antes e, de-
pois, os dados do departamento financeiro, fa-
zendo um filtro.

DIAGRAMA 4. MODELO HIERÁRQUICO
Gerência
Financeiro Comercial
Marcos Juliana Marcela Flávia
Normalização
A etapa de normalização é a última etapa antes de entrar na prática. En-
tretanto, ainda é importante citar o que é anomalia para então definir o que
é normalização (o contrário de anomalia).
Um exemplo de anomalia é colocar dados em tabelas erradas. Por exem-
plo, colocar o salário fi xo do vendedor na tabela de vendas, colocar dados
sobre vendas na tabela de compras, etc.
Quando não se planeja correta e detalhadamente um banco de dados
(pulando as etapas 1 e 2 do Ciclo de Vida de Banco de Dados), ocorrem as
anomalias.

Anomalias de inclusão
Vejamos dois exemplos de erros de inclusão:
Exemplo 1. Uma empresa precisa criar duas tabelas: a de colaboradores e de
premiação. Na tabela colaboradores, a empresa entendeu que seria necessário
preencher nome, salário, dados pessoais e função, conforme mostra a Tabela 4.
TABELA 4. EXEMPLO DE TABELA COLABORADORES
Nome Salário Telefone Endereço Função
11 3344-5511 Auxiliar de
João R$ 2.000,00 Rua Doze, n. 23
11 9922-8734 Produção
11 3566-5411 Consultora
Márcia R$ 2.300,00 Rua Porto, n. 24
11 9877-8788 Comercial
Na tabela Premiação, a empresa viu a necessidade de colocar o nome do

colaborador, função, salário e premiação, conforme mostra a Tabela 5.
TABELA 5. EXEMPLO DE TABELA PREMIAÇÃO
Nome Salário Função
Auxiliar de
João R$ 2.000,00
Produção
Consultora
Márcia R$ 2.300,00
Comercial
Um exemplo de erro de inclusão é permitir colocar dados na tabela Pre-

miação sem que seja obrigatório colocar na de Colaboradores antes. Caso isso
acontecesse, haveria prêmio para funcionários não cadastrados.
Exemplo 2. Se houvesse uma tabela chamada salários, outra chamada fun-
cionários e elas estivessem relacionadas no banco de dados relacional, a com-
posição delas seria a seguinte:

• Tabela funcionários: nome dos funcionários, seus cargos e seus salários.
• Tabela salários: nome dos funcionários, salário e conta de pagamento.
Desse modo, um erro de inclusão seria permitir inserir a tabela funcionários
sem os salários ou criar a tabela salário sem inserir o nome dos funcionários.
Além de se tratar de um registro incompleto, seria impossível associar duas tabe-
las, uma vez que o dado que liga as duas tabelas não estaria presente.
Anomalias de exclusão
Exemplo 1. Um exemplo de anomalia de exclusão pode ser visto na possibili-
dade de excluir um funcionário da tabela de colaboradores que tenha se desliga-
do da empresa sem que seu nome fosse automaticamente deletado da tabela de
premiação. Neste caso, se não programarmos para dar baixa em todas as tabelas
simultaneamente, a empresa pode ficar com uma lista de funcionários-fantasma.
Exemplo 2. Há outro exemplo muito inverso de erro. Imagine que existam
duas tabelas: a tabela de produtos e a tabela de pedidos, conforme mostram as
Tabelas 6 e 7.
TABELA 6. EXEMPLO DE TABELA DE PRODUTOS
Produtos Descrição Preço
001 Luva R$ 100,00
002 Calça R$ 200,00
TABELA 7. EXEMPLO DE TABELA DE PEDIDOS
Pedido Data Quantidade
002 25/01 1
001 23/02 1

Um erro de exclusão, neste caso, funcionaria como um gatilho ao excluir um
pedido por desistência do cliente na tabela de pedidos e excluísse também seu
registro na tabela de produtos. Desse modo, o produto deixaria de existir, sendo
que o que deixou de existir foi o pedido.
Anomalias de modificação
Supondo que existisse, em uma em-
presa, duas tabelas relacionadas: uma
de filmes e outra de diretores. A tabela
de filmes possui os campos Cod_Filme,
Filme, Nome_Diretor, Gênero e Sinopse
e a tabela de diretores possui os cam-
pos Cod_Diretor, Nome_Diretor, Nasci-
mento, Contato_Diretor.
Como se pode ver, as duas possuem
o nome do diretor (Nome_Diretor). Su-
ponha que, por algum descuido, esses
dois campos não estejam vinculados.
Neste caso, ao alterar o nome de um
diretor que estava escrito com o sobre-
nome errado na tabela de diretores, a tabela de filmes não seria automaticamente
atualizada, gerando um erro inconsistente no nome na tabela filme.
Normalização: 1º Forma Normal, 2º Forma Normal e

3º Forma Normal
Normalizar é reduzir os erros. Entretanto, sobre quais erros estamos falando?
Os erros de Inserção, Exclusão, Modificação e outros possíveis. Vamos ver as for-
mas padronizadas de normalização mais conhecidas na ciência de banco de dados:
1º Forma Normal – Atomizar: consiste em tornar os dados atômicos, isto é,
segmentados. Observe, no Diagrama 5, que os campos Nome, Endereço e Telefo-
ne foram atomizados.

DIAGRAMA 5. ATOMIZAÇÃO
Nome Endereço Telefones
Rua Vergueiro, 213, 11 9933-5511

Juliano Souza
Vila Mariana 11 3377-8877
Nome Sobrenome Logradouro Bairro Celular Telefone Fixo
Juliano Souza Rua Vergueiro, 213 Vila Mariana 11 9933-5511 11 3377-8877
A vantagem da atomização é facilitar a gestão de inclusões, alterações e ex-

clusões, além de criar regras para inserção feitas na programação.
2º Forma Normal – Eliminar dependências parciais: até agora não foi mos-
trado como relacionar tabelas, mas, basicamente, uma chave primária é colocada
em um campo escolhido, e ela liga duas tabelas. Assim, para que a relação entre
tabelas seja perfeita, cada tabela deve ter uma chave primária, e os outros
campos da tabela devem ter relação com o campo da chave primária (não po-
dem ser dados de outro tema diferente da chave primária). O Diagrama 6 mostra
uma tabela com duas chaves primárias e vários campos. Em seguida, ele mostra
esta tabela dividida com os campos corretos.
DIAGRAMA 6. ELIMINANDO DEPENDÊNCIAS PARCIAIS
Cod_Produto
Cod_Fornecedor Nome_ Tel_
(chave Nome_Produto Preço_Produto
(chave primária) Fornecedor Fornecedor
primária)
11 9833-5571
005 Notebook I5 R$ 3.000,00 003 Samsung
11 3377-8877
Cod_Produto
Nome_Produto Cod_Fornecedor Preço_Produto
(chave primária)
005 Notebook I5 003 R$ 3.000,00

Cod_Fornecedor
Nome_ Fornecedor Tel_ Fornecedor
(chave primária)
11 9833-5571
003 Samsung
11 3377-8877
Neste caso, deixar todas as colunas na mesma tabela acarretaria em um erro

de inserção, fazendo com que todos os dados dos fornecedores tivessem que ser
digitados novamente. Nesse sentido, é bem mais prático ter apenas o código do
fornecedor e relacionar esse código com a tabela fornecedor.
Além disso, ao fazer tudo em apenas uma tabela e deletar uma linha, pode-
ríamos cair em um erro de exclusão, uma vez que aquele fornecedor que não se
repetiu em nenhuma linha some do sistema inteiro.
3º Forma Normal – Eliminar dependências transicionais: após fazer a pri-
meira e a segunda forma normal, a terceira forma normal afirma que não deve
ter nenhuma coluna dependente de outra coluna derivada da chave primária. Ob-
serve o Diagrama 7, que mostra que a coluna Total Geral é dependente de outras,
sendo removida por isso.
DIAGRAMA 7. ELIMINANDO DEPENDÊNCIAS TRANSITIVAS
Num_Pedido Produto Quantidade Preço Total Geral
R$ 150,00
002 Bolsa 3 R$ 50,00
(3x50)
Num_Pedido Produto Quantidade Preço
002 Bolsa 3 R$ 50,00
Isto evita erros de modificação e, caso um produto que se repete várias vezes
tenha seu preço alterado, o Total Geral não muda automaticamente, pois não foi
calculado por programa, e sim pelo digitador.

O modelo relacional: conceitos
SGBSs, como Oracle, MySQL, SQL Serve, utilizam o modelo relacional. Ana-
lisando as tabelas, temos Atributos (campos), tuplas (registros) e valores (da-
dos). O Diagrama 8 exemplifica estes conceitos.
DIAGRAMA 8. ATRIBUTOS E TUPLAS
Nome da
Atributos
relação
CARGOS
Código Denominação Classe Categoria
701001 Administrador E Técnico-Administrativo
701010 Bibliotecário - Documentalista E Técnico-Administrativo
tuplas 701244 Técnico de Laboratório - Área D Técnico-Administrativo
701405 Auxiliar em Administração C Técnico-Administrativo
702001 Professor de Ensino Básico, Técnico e Tecnológico D Docente
Fonte: COSTA, 2011, p. 35. (Adaptado).
Nesse sentido, pode-se dizer que cada linha é uma tupla; as palavras “Có-
digo”, “Denominação”, “Classe” e “Categoria” são atributos; cada atributo é
um domínio, D1 é domínio de código, D2 é domínio de denominação, D3 é
domínio de classe, D4 é domínio de categoria.
Suponha que temos duas tabelas e elas possuam um campo em comum,
Cod_Departamento, conforme mostra o Diagrama 9.
DIAGRAMA 9. CHAVE PRIMÁRIA E CHAVE ESTRANGEIRA
Funcionários
Cod_Funcionário Nome Cargo Departamento Telefone

chave primária
(Primary Key)
002 João Gerente Marketing 11 77887777
Salários
Cod_Funcionário Salário
chave estrangeira
(Foreign Key)
002 R$ 5.000,00

Após criar estas duas tabelas, duas realidades irão acontecer:
1. Integridade: será possível cadastrar um salário apenas na tabela Salá-
rios se o código do funcionário estiver cadastrado na tabela Funcionários.
2. Consultas: será possível fazer consultas que combinem as duas tabelas
com o comando SELECT + INNER JOIN.
Instalação de Banco de Dados

Para abordar o modelo relacional, é necessário compreender a parte prática
de banco de dados. Por isso, será necessário fazer a instalação de dois progra-
mas: o Xampp e o Workbench MySQL.
O Xampp é o que permite o funcionamento do Workbench no computador
local, o Workbench MySQL é o programa de trabalho dos bancos de dados. Ins-
tale os dois programas.
ASSISTA
Para instalar os dois programas, siga o tutorial em vídeo
chamado Instalar MySQL e XAMPP - By Luiza Cerchiari - 2019.
Após instalar os dois programas, ative o Xampp e ative Apache e MySQL, con-
forme mostra a Figura 6.
Figura 6. Captura de tela que mostra como abrir o Xampp.

Esta etapa não deve ser pulada, uma vez que é muito mais fácil entender os pró-
ximos passos praticando. Sendo assim, gaste tempo e energia para baixar os dois
programas. Se possível, baixe a versão Workbench MySQL 6.3. Apesar de ser um
pouco mais antiga, é mais confiável.
Agora abra o programa Workbench MySQL, conforme Figura 7.
Figura 7. Captura de tela que mostra como abrir o Workbench.
Após clicar no sinal de +, conforme indica a Figura 7, deverá aparecer uma

janela igual à da Figura 8.
Em seguida, é preciso criar a primeira conexão e janela de trabalho. Digite
primeiro_teste e clique em OK, conforme Figura 8.
Figura 8. Captura de tela que mostra como criar uma nova conexão.

Após clicar em OK, basta clicar na conexão criada e então será aberta
uma parte de trabalho com o fundo branco, conforme Figura 9.
Figura 9. Captura de tela que mostra como abrir área de trabalho do Workbench MySQL.
Verifi que se o símbolo de raio está amarelo. Caso esteja, é possível co-
meçar a mexer.
Tipos de dados
Existem vários tipos de dados (datatypes). A Tabela 8 mostra os tipos mais
utilizados e fundamentais.
TABELA 8. DATATYPES MAIS UTILIZADOS
Tipo Para que serve Exemplo
Para textos com ou sem números nome varchar(30)

Varchar
que não precisam ser calculados Nome com máximo de 30 letras.
idade int
Idade com números inteiros;
Int Para números inteiros
Não precisa de quantidade máxima de
caracteres.

altura decimal (3,2)
Altura com três dígitos, mas dois
Decimal Para números quebrados (decimais)
ficam após a vírgula, por exemplo:
1,89.
Para datas em formato americano data_da_compra date

Date
(Ano-Mês-Dia-xxxx-xx-xx) Por exemplo: 2019-01-25.
Horário hora_da_compra
Time
(Hora-Minuto-Segundo-xx:xx:xx) Por exemplo: 10:00:00.
sexo ENUM (‘feminino’,’masculino’)

Tipos pré-fixados (pré-
ou
Enum determinados).
prioridade ENUM (‘baixa’,’média’,
Não é possível escolher outro.
‘alta’).
Vejamos na prática como funcionaria isso em um banco de dados. Siga os

passos das Figuras 10, 11, 12 e 13. Estes passos serão responsáveis por execu-
tar os seguintes códigos:
• create database Loja_Zona_Sul; – Criar um banco de dados chamado
Loja_Zona_Sul
• use Loja_Zona_Sul – Ativa o banco de dados
• create table vendas – Criar uma tabela com campos de vendas com da-
tatypes
• select * from vendas – Seleciona todos os dados da tabela vendas
Após digitar, clique depois do “;” e então

clique no raio da esquerda
Resultado esperado
Figura 10. Captura de tela que mostra como criar um banco de dados.

1. Ativar o banco de dados com o comando USE, conforme Figura 11.
Após digitar a sintaxe da linha 2, clique após

o “;” e aperte no raio esquerda
Figura 11. Captura de tela que mostra como ativar o Banco de Dados.
2. Criar a tabela, conforme Figura 12.
Clique após o “;” e clique no raio da

esquerda
Figura 12. Captura de tela que mostra como criar uma tabela.

3. Ver o que foi criado por meio do comando SELECT, conforme Figura 13.
Clique após o “;” e clique no raio da

esquerda
Resultado esperado após clicar no raio
Figura 13. Captura de tela que mostra como selecionar os dados.
Como pode ser visto no meio da Figura 13, a tabela foi criada e está exibida
abaixo dos códigos, mas ela ainda não foi preenchida com dados, contendo
apenas os campos:
nome_produto | preco_produto | data_compra | tipo_compra | quan-
tidade_comprada
Procure estes dados na tabela. Eles são resultados da cláusula SELECT.
Inserindo dados nas tabelas

Após criar a tabela, é chegada a etapa de inserir dados no nosso exemplo de
vendas. A Figura 14 mostra como inserir dados. Faz-se necessário utilizar aspas
simples ao inserir dados, conforme sintaxe a seguir:
insert into vendas values (‘Tv’, ‘999.99’, ‘2019-02-14’, ‘Parcelado’, ‘3’);
Em que:
• insert significa insira;

• insert into vendas significa inserir na tabela vendas;
• insert into vendas values significa inserir na tabela vendas os valores;
• ‘Tv’ equivale a nome_produto;
• ‘999,99’ equivale a preco_produto;
• ‘2019-02-14’ equivale a data_da_compra;
• ‘Parcelado’ equivale a tipo_compra;
• ‘3’ equivale a quantidade.
Digite as sintaxes das linhas 14 e 15.

A linha 14 insere dados na mesma ordem da criação da tabela.
A linha 15 seleciona estes dados.
Clique após “;” da linha 14 e clique no raio da esquerda.
Após isso, clique após “;” da linha 15 e clique no raio da esquerda.
Resultado esperado: Tabela com dados
Figura 14. Captura de tela que mostra como inserir dados em uma tabela.
Por ora, esta quantidade de prática é suficiente. Vamos prosseguir agora para
o conceito de banco de dados relacional.
Modelo Relacional na prática em MySQL

Duas coisas são realidades em um banco de dados relacional.
Supondo que temos dois bancos de dados, conforme mostra o Diagrama 10.

DIAGRAMA 10. CHAVE PRIMÁRIA E CHAVE ESTRANGEIRA PARA PRÁTICA EM MYSQL
Pessoas
ID_Pessoa Nome Cidade

chave primária
(Primary Key)
1 Juliana SP
Carros
ID_Pessoa ID_Carro Nome_Carro Marca

Chave estrangeira
(Foreign Key)
1 1 Gol Wolks
Desse modo, é importante se atentar para

os seguintes pontos:
• Integridade relacional: só será possí-
vel cadastrar um carro na tabela Carros se o
Código da pessoa estiver cadastrada na tabe-
la Pessoas.
• Consultas relacionais: será possível fazer con-
sultas que combinem as duas tabelas com o comando
SELECT + INNER JOIN.
O modelo relacional permite fazer consultas em duas tabelas ao mes-
mo tempo, desde que exista um dado idêntico nas duas tabelas, usando
geralmente um comando chamado inner_ join.
Consultas Relacionais
Será possível fazer consultas que combinem as duas
tabelas com o comando SELECT + INNER JOIN.
Primeiro veja a teoria, após isso, as
Figuras 15 e 16 mostrarão como fazer
tudo.
Primeiramente, vamos conhe-
cer a sintaxe para criar uma chave
primária (Primary Key) na tabela
Pessoas.

CREATE TABLE
Pessoas (
ID_Pessoa integer
PRIMARY KEY,
Nome varchar(255),
Cidade varchar(255)
);
Agora, vamos conhecer a sintaxe para definir a chave estrangeira (Foreign Key)
na tabela Carros, na qual ID_Pessoa é a chave estrangeira. Observe no exemplo:
CREATE TABLE Carros(

ID_Pessoa integer PRIMARY KEY,
Nome varchar(255),
Cidade varchar(255)
ID_Pessoa integer,
CONSTRAINT ligacao FOREIGN KEY (ID_Pessoa) REFERENCES
Pessoas (ID_Pessoa)
);
Após isso, é necessário incluir os dados nas duas tabelas e selecionar.
insert into Pessoas values

(1, ‘Juliana’, ‘SP’),
(2, ‘Julio’, ‘SP’),
(3, ‘Márcio’, ‘SP’);
select * from Pessoas;
A seguir, os dados 2 e 3 na tabela Carros fazem referência com os dados 2 e

3 da tabela Pessoas.
insert into Carros values
(1, ‘Gol’, ‘Wolks’,2),
(2, ‘Palio’, ‘Fiat’, 3),
select * from Carros;
Agora, só resta um comando, que fará a junção das duas tabelas: O INNER JOIN!
Este comando unirá as duas tabelas, conforme Diagrama 11.

DIAGRAMA 11. UNIÃO DE DUAS TABELAS PELO INNER JOIN
Apenas a tabela pessoas (select * from Pessoas);
ID_Pessoa Nome Cidade
1 Juliana SP
2 Julio SP
3 Márcio SP
Apenas a tabela Carros (select * from Carros)
ID_Carro Nome Marca ID_Pessoa
1 Gol Wolks 2
2 Palio Fiat 3
As duas tabelas unidas pelo INNER JOIN

select * from Pessoas INNER JOIN Carros ON (Pessoas.ID_Pessoa = Carros.ID_Pessoa);
ID_Pessoa Nome Cidade ID_Carro Nome_1 Marca ID_Pessoa
2 Julio SP 1 Gol Wolks 2
3 Márcio SP 2 Palio Fiat 3
Para ver este passo a passo no MySQL Workbench, observe as Figuras 15 e 16.
Criar tabela pessoas com o

campo ID_Pessoa como chave
primária
Inserir dados
Selecionar dados
Figura 15. Captura de tela que mostra como criar uma tabela com chave primária.

Ao colocar na tabela Carros uma chave estrangeira ligando a ID_Pessoa da ta-
bela Carros com a ID_Pessoa da tabela Pessoas, o select inner join mostrará duas
tabelas juntas em um só comando.
Chave primária
A chave estrangeira vai ligar o

ID_Pessoa da tabela Carros com a
ID_Pessoa da tabela Pessoas
A seleção Inner Join unirá duas

tabelas onde ID_Pessoa for igual
em ambas
Resultado esperado
A seleção uniu duas tabelas
Figura 16. Captura de tela que mostra uma tabela com chave estrangeira, ligando com a chave primária da outra tabela.
Veja que apareceu uma tabela relacionada com a outra. Este conceito já de-
monstra um exemplo de relacionamento entre tabelas.
Integridade Relacional
Agora, tentaremos incluir um dado na tabela carros, com um ID_Pessoa que
não existe na tabela Pessoas. Por exemplo: o ID_Pessoa 11 e 12.
insert into Carros values
(3, ‘Uno’, ‘Fiat’,11),
(4, ‘Palio’, ‘Fiat’, 12),
select * from Carros;
É possível ver o resultado do teste no MySQL na Figura 17.
Figura 17. Captura de tela que mostra os problemas com a chave estrangeira.

Sintetizando
Nesta unidade, começamos vendo o que são SGBS, e foi citado quais são
os mais famosos, desde os pagos, como Oracle e SQL SERVER, até os gratuitos,
como MySQL, MongoDB, Cassandra E PostgreSQL. Vimos quais são os servido-
res famosos, como Azure, Amazon e Uol Host. Também foi mostrado como rela-
cionar um banco de dados do programa SMSS do SQL Server com Azure.
Foi explicitada a natureza de modelo de Banco de Dados Entidade-Relaciona-
mento e do Banco de Dados Orientado a Objetos. Além disso, abordamos o mo-
delo de banco de dados de Redes e o modelo de banco de Dados de Hierarquia,
sendo o de Redes ligado por links e o de Hierarquia ligado por grupos maiores.
Foi abordada a importância do Ciclo de Vida a fim de ordenar as etapas da
criação do banco de dados para evitar retrabalhos ou problemas de inconsistên-
cia com a gestão e o modo de funcionamento da empresa.
Após isso, falamos sobre o que são anomalias de inclusão e de exclusão. Ou-
tra anomalia citada foi a anomalia de modificação, na qual se altera uma infor-
mação de uma tabela sem alterar as demais.
Após falar das anomalias, partimos para as normalizações, a fim de tornar os
dados atômicos, remover dependências parciais e transitivas, deixando as tabe-
las com as aspecto mais celular e individual e tornando mais fácil o planejamento
de relações.
Entrou-se em aspectos práticos sobre como instalar Workbench, como insta-
lar o Xampp, como criar tabelas no MySQL e incluir dados nestas tabelas para,
por fim, ensinar a fazer relações com inner join por meio das chaves primárias e
estrangeiras.
Também foi citado como funciona a integridade relacional, a qual não permi-
te que se insira dados em uma tabela dependente com chave estrangeira, sem
criar este dado na tabela-pai. O nome disto é integridade relacional.

Referências bibliográficas
COSTA, E. 2011. 64 f. Banco de Dados Relacional. Trabalho de conclusão de curso
(Tecnólogo) – Faculdade de Tecnologia de São Paulo (FATEC), São Paulo, 2011. Dispo-
nível em: <http://www.fatecsp.br/dti/tcc/tcc0025.pdf>. Acesso em: 12 jul. 2019.
INSTALAR MYSQL E XAMPP. Postado por Luiza Cerchiari. (5 min. 47 s.). color. Dis-
ponível em: <https://www.youtube.com/watch?v=srcl7b1LeCg>. Acesso em: 17 jul.
2019.
O QUINTO PODER – TRAILER LEGENDADO. Postado por Cinemaginando. (2 min.
31 s.). color. son. eng. leg. Disponível em: <https://www.youtube.com/watch?v=JV7S-
888zYm0>. Acesso em: 17 jul. 2019.
SILBERSCHATZ, A. et al. Sistema de Banco de Dados. São Paulo: Makro Books, 2004.
TEOREY, T. et al. Projeto e Modelagem de Banco de Dados. Rio de Janeiro: Elsevier,
2014.

UNIDADE
2 OPERAÇÕES PRÁTICAS
EM MySQL E ÁLGEBRA
RELACIONAL

Aprender sobre tudo relacionado a tabelas como criação e exclusão, alterar e

renomear colunas;
Fazer diversos tipos de seleção;
Aprender conceitos de álgebra relacional;
Aprender sobre a engine InnoDB.
Tópicos de estudo
Linguagem de definição de Álgebra relacional e operadores
dados de um SGBD – DDL (Data Seleção
Definition Language) Projeção
Create União
Alter com drop e ADD Diferença
Rename e Truncate Intercessão
Linguagem de manipulação de Linguagem de controle de tran-

dados de um SGBD - DML (Data sações SGBD - TCL (Transaction
Manipulation Language) Control Language)
Insert Begin e Rollback
Update Commit
Delete
Select

Linguagem de definição de dados de um SGBD – DDL
(Data Definition Language)
Exemplos de DDL – definição de dados de um SGBD são as funções create,
drop, alter e rename, as quais serão vistas agora. O create serve para criar banco
de dados e tabelas, o comando drop serve para apagá-los, já o comando alter
serve para alterar as tabelas, adicionando ou removendo colunas. Por fim, o co-
mando rename, que será explicado também, serve para renomear as tabelas
após elas terem sido criadas.
Create
Para começar a mexer nos comandos DDL, é necessário criar um banco de
dados. Abra e ative o XAMPP, conforme a Figura 1, e crie uma instância.
Figura 1. Ativação de XAMPP.
Usaremos um exemplo em que o usuário na empresa Fiat deseja criar cin-

co tabelas: carros_seminovos, carros_usados, carros_novos, funcionarios e
cliente. Vamos falar pela tabela cliente. Observe a Tabela 1 que seria criada após
o código.

create database fiat;
use fiat;
CREATE TABLE cliente (
cliente_id INT NOT NULL AUTO_INCREMENT primary key,
primeiro_nome VARCHAR(30) NOT NULL,
ultimo_nome VARCHAR(30) NOT NULL,
email VARCHAR(50),
data_aniversario DATE,
media_por_mes_de_visitas INT
);
TABELA 1. TABELA DE CLIENTES
media_por_mes_
cliente_id primeiro_nome ultimo_nome email data_aniversario
de_visitas
O código a seguir mostra informações novas, como constraints (regras) nas

sintaxes. Por exemplo, com a linha cliente_id INT NOT NULL AUTO_INCREMENT
primary key, podemos observar que:
• cliente_id é o nome do campo;
• A constraint not null, que impede de inserir dados vazios, isto é, dados null;
• A constraint Auto Increment significa que aumentará
de um em um automaticamente;
• A constraint primary key é a chave primária que se
liga com outras tabelas.
Agora execute estes códigos conforme a Figura
2, clicando no raio da esquerda no Workbench, e
não esqueça de ativar o XAMPP antes de abrir
o MySQL.

Figura 2. DDLs usadas: Create database e Create table.
Para testar se o not null está funcionando, temos que inserir dados e co-
locarmos NULL no nome. Observe o erro “Error Code: 1048. Column ‘primei-
ro_nome’ cannot be null”, dizendo que o dado primeiro_nome não pode ser
null, na Figura 3.
Figura 3. Erro ao inserir comandos nulos em sintaxes com constraint not null.
Ao criar uma tabela e utilizar a sintaxe PRIMARY_KEY, o programa proíbe

que duas linhas tenham o mesmo ID; por exemplo, um ID pode ser um CPF,
logo, não é possível ter dois CPFs. Caso sejam adicionadas duas chaves primá-
rias iguais, a seguinte mensagem de erro aparecerá: Error Code: 1062. Duplicate
entry ‘1’ for key ‘PRIMARY’.

Agora vamos falar sobre a constraint auto increment, que geralmente é uti-
lizada em chave primária, pois, caso o usuário não insira nenhuma informação,
o sistema insere aumentando sozinho 1 ponto. Por exemplo, se a última matrí-
cula foi 1, o sistema coloca 2.
Observe na sintaxe a seguir que não foi inserido nenhum cliente_ID. Após
inserir os dados sem ID e selecionar, aparece uma tabela com os valores 1 e 2,
ou seja, aumentou sozinho (auto incrementou).
INSERT INTO cliente (primeiro_nome, ultimo_nome, e-mail,

data_aniversario, media_por_mes_de_visitas) values
(‘Gabriel’, ‘Andrade’, ‘5’, ‘2000-12-11’,2),
(‘Marcelo’, ‘Andrade’, ‘5’, ‘2000-12-13’,5);
select * from cliente;
Além de usar o create para criar tabelas, pode-se utilizar para criar fun-
ções, triggers (gatilhos) e views, porém tudo isso será citado mais adiante. Caso
você queira que ninguém insira dados iguais no e-mail, por exemplo, seria ne-
cessário utilizar uma constraint chamada unique na hora da criação da tabela.

use fiat;
CREATE TABLE cliente(
telefone int unique,
email VARCHAR(50),
);
DICA
Procure criar tabelas com quantidades de dados mais enxutos para não
sobrecarregar o sistema. Se um nome tem no máximo 20 letras, não é
necessário colocar VARCHAR (30) e sim VARCHAR (20).

Alter com drop e ADD
O segundo DDL a ser citado é o
alter, que será mostrado junto com
o drop. Primeiramente, vamos supor
que a coluna data_aniversario não
seja mais desejada, então melhor
alterar (alter) apagando (drop) esta
coluna, para não usar espaço. Para
excluir é muito simples, digite a se-
guinte sintaxe:
ALTER TABLE nome_da_tabela

DROP COLUMN nome_da_coluna;
Que pode ser exemplificado assim:
ALTER TABLE cliente

DROP COLUMN data_aniversario;
Assim, a coluna data_aniversario será excluída. Agora, vamos supor

que você queira adicionar uma coluna nova depois da coluna ultimo_nome
chamada telefone:
ALTER TABLE cliente

ADD column telefone varchar(30) NOT NULL after ultimo_nome;
Agora, caso você queira adicionar uma coluna antes de todas as outras
(a tradução de primeiro do inglês é first), ela chamará Codigo_Cliente. Você
fará dessa forma:
ALTER TABLE cliente

ADD column código_cliente int NOT NULL AUTO INCREMENT primary key
FIRST;
Vendo tudo isso no MySQL, observe na tabela de se-

leção que o campo de aniversário saiu e o campo de
telefone entrou.

Figura 4. Comandos DDL alter.
Ainda falando sobre o alter, é possível modifi car o tipo do campo. Imagine
que, sem querer, você criou a coluna nome com o tipo INT, “primeiro_nome
int NOT NULL”, mas primeiro_nome é VARCHAR. Para alterar, utiliza-se:
ALTER TABLE cliente MODIFY primeiro_nome varchar(30);
Vamos supor que, ao criar a tabela, esqueceram de adicionar chave pri-

mária em cliente_id; Para adicionar, basta digitar a sintaxe a seguir:
ALTER TABLE cliente ADD PRIMARY KEY (cliente_id);
Ainda é possível apagar tabelas com o drop, ou, ainda, databases. É só

digitar a sintaxe:
DROP table cliente;
OU
DROP database FIAT;
Rename e Truncate
Há casos em que é necessário alterar o nome da tabela. Na verdade, isso é
bastante utilizado, uma vez que as formas de gestão não são estáticas e sim di-
nâmicas. Assim, muitas vezes altera-se a tabela passando, por exemplo, de clien-
tes para clientes_janeiro. Para isso, utiliza-se o rename:

RENAME TABLE
CLIENTE TO CLIENTES;
Após isso, clique no raio. Após fazer isso, o nome da tabela será alterado. Para
ver todas as tabelas existentes, digite SHOW TABLES e clique no raio.
O último DDL a ser citado é o Truncate. Este comando apaga todos os regis-
tros da tabela em uma vez só, caso você tenha criado a tabela e inserido dados,
mas depois, por algum motivo, tenha que apagar os dados, por exemplo. Vamos
criar outra tabela e inserir dados.
use fiat;
CREATE TABLE funcionarios (
funcionario_id INT NOT NULl auto_increment primary key,
email VARCHAR(50),
salario DECIMAL(6,2)
);
INSERT INTO funcionarios values
(1,’Gabriel’, ‘Andrade’, ‘GABRIEL@IG.COM’, ‘2000-12-11’,2000.00),
(2, ‘Marcelo’, ‘Andrade’, ‘MARCELO@IG.COM’, ‘2000-12-13’,5000.00);
Após digitar o SELECT * from funcionários; apareceria assim:
primeiro ultimo data_

funcionario_id email salario
_nome _nome aniversario
GABRIEL@IG.
1 Gabriel Andrade 11/12/2000 20000
COM
MARCELO@IG.
2 Marcelo Andrade 13/12/2000 50000
COM
Porém, ao digitar TRUNCATE table funcionários; e então SELECT * from

funcionários; apareceria assim:
primeiro ultimo data_

funcionario_id email salario
_nome _nome aniversario

Linguagem de manipulação de dados de um SGBD -
DML (Data Manipulation Language)
Agora, o assunto a ser abordado é DML, voltado a alterações de dados nas
tabelas. Até então, vimos alterações maiores de estruturas, porém veremos alte-
rações nos dados preenchidos. Os comandos DML são compostos por:
• Insert, que serve para inserir registros na tabela, isto é, preencher a tabela
com pessoas ou produtos, por exemplo;
• Update, cuja utilidade é atualizar um dado já inserido. Por exemplo, se o
estado civil passou de solteiro para casado, esta mudança pode ser registrada
por meio dele;
• Delete, que serve para deletar uma linha completa;
• Select, utilizado para selecionar os dados inseridos na tabela.
Insert
Há duas formas de inserir dados, dizendo quais campos serão inseridos ou
apenas digitando a palavra values, a qual determina que em todos os campos
serão adicionados os dados. Vamos ver:
Primeira forma – Determinar quais campos serão adicionados.
Pense na tabela de funcionários já criada:
primeiro ultimo
funcionario_id email data_aniversario
_nome _nome
A intenção aqui é inserir apenas em funcionario_id, primeiro_nome e email.

Para isso, a sintaxe seria:
insert into funcionarios (funcionario_id, primeiro_nome, email) values

(5, ‘Julio’, ‘julio@gmail.com’);
Note que textos devem ter aspas simples e números não.

Segunda forma – Adicionando em todos com a sintaxe VALUES.

Agora vamos inserir todos os dados, na mesma ordem que foram criados:
USE FIAT;
CREATE TABLE funcionarios (
funcionario_id INT NOT NULl auto_increment primary key,
email VARCHAR(50),
salario DECIMAL(6,2)
);
Observe a seguir que a sintaxe coloca todos os dados.
insert into funcionarios values

(2, Daniel, ‘Gonçalvez’,’daniel@gmail.com’, ‘2000-04-21’,
7000.00);
Após executar estes dois comandos, o resultado será igual ao da Figura 5.

Note, contudo, que a tabela foi apagada (drop) e depois foi recriada.
Figura 5. Duas formas diferentes de inserir dados.

Agora, como o campo funcionario_id é auto incrementado, caso pulemos a
inserção destes dados, o sistema acrescenta 1, ou seja, o próximo dado após o 2
é 3 e assim por diante.
Update
Caso um dado seja alterado, precisamos atualizar. Suponha que uma colabo-
radora da equipe de semi_novos entra em contato com o RH dizendo que seu
telefone mudou. Com isso, será necessário fazer um update, isto é, uma atuali-
zação para o número novo. Mas antes, observe que a tabela de colaboradores
possui uma nova constraint, chamada default. No exemplo a seguir, caso o ca-
dastrador não coloque nenhuma cidade, ficaria São Paulo como padrão, uma
vez que, como é possível ver na figura a seguir, na sétima linha, São Paulo está
definida como padrão no sistema.
Figura 6. Criando tabelas com a constraint default
Voltando ao exemplo de atualização, com a mudança de telefone, o usuário

do banco de dados precisa atualizar e, para isso, será necessário usar a sintaxe
descrita no Diagrama 1:

DIAGRAMA 1. FUNCIONAMENTO DO UPLOAD
SINTAXE SIGNIFICADO
UPDATE funcionarios_seminovos atualize funcionarios_seminovos
set telefone = 33996566 coloque telefone = 33996566
where primeiro_nome = ‘Gabriela’ onde primeiro_nome = ‘Gabriela’;
Na sintaxe agora citada, o telefone seria alterado, mas existe uma ferramenta
de segurança que precisa ser desativada no Workbench para fazer esta atualiza-
ção. O erro que diz que isso precisa ser liberado é escrito da seguinte forma: Error
Code: 1175. You are using safe update mode and you tried to update a table without a
WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences
-> SQL Editor and reconnect. Ele diz que, para fazer este update, é necessário libe-
rar na guia Edit e depois em Preferences.
Depois disso, para desabilitar a segurança de updates, os próximos passos
são desabilitar o modo seguro, fechar a instância e abrir novamente e fazer o
upload. Existem outras formas de atualização. Pode-se, por exemplo, mudar
duas coisas por vez, como mudar o telefone e a cidade onde o nome for igual ao
da pessoa em questão (no caso do exemplo, é Gabriela).
UPDATE funcionarios_seminovos
set telefone = ‘11955445566’, cidade = ’Osasco’
where primeiro_nome = ‘Gabriela’;
Delete
O comando delete é bem parecido com o update, veja o exemplo:
DELETE FROM ‘ funcionarios_seminovos ‘ where primeiro_nome = ‘Gabriela’;
A sintaxe citada serve para deletar da tabela funcionários seminovos pessoas

com o nome Gabriela, mas poderia ser com o outro campo, por exemplo o sobre-
nome, conforme exemplo a seguir:
DELETE FROM ‘ funcionarios_seminovos ‘ where ultimo_nome = ‘Farias’;

Usando outro exemplo, vamos imaginar que foi
criada a tabela carros_usados, que terá os seguin-
tes campos: marca, modelo, combustível, preço e ano.
Agora, supondo que inserimos cinco carros, os quais es-
tão descritos a seguir:
insert into carros_usados values

(‘FIAT’,’Idea’,’Flex’, 40000.00, 2018),
(‘FIAT’,’palio’,’Gasolina’, 25000.00, 2012),
(‘FIAT’,’TORO’,’Flex’, 80000.00, 2013),
(‘FIAT’,’Siena’,’Flex’, 30000.00, 2018),
(‘FIAT’,’Uno’,’Flex’, 20000.00, 2018);
Após inserir estes dados, vamos

supor que a empresa criará uma ou-
tra tabela chamada Carros_Usados_
Economicos. Para isso, ela terá que
deletar todos os carros que custam
menos que R$ 29.000,00. A sintaxe
correta seria:
delete from carros_usados where preco < 29000;
Será possível ver, após deletar e fazer a seleção, que os dados dos car-
ros mais baratos que R$ 29,000,00, no caso, Uno e Palio, foram deletados.
DICA
Para fazer com que o banco de dados se comunique com um site de produtos,
utiliza-se o PHP, uma linguagem de programação. Ao terminar os estudos de
banco de dados, procure aprender HTML e PHP para desenvolvimento web,
assim você fará sites com HTML e criará vínculos com bancos de dados
através do PHP.
Select
A DML select funciona de maneira idêntica ao update, porém sua função é
selecionar dados. Existem várias formas de selecionar, conforme a Tabela 2.

TABELA 2. VARIAÇÕES DO SELECT
Sintaxe Função Resultado
Seleciona todos(*)
select * from
os dados de carros_
carros_usados;
usados
select modelo Seleciona apenas

from carros_ modelos de carros_
usados; usados
select modelo, Seleciona apenas

preco from modelos e preços de
carros_usados; carros_usados
select modelo, Seleciona apenas

ano from modelos e ano de
carros_usados carros_usados onde o
where preco >= preço é maior ou igual
29000; que R$ 29.000,00
select preco
Seleciona o preço de
from carros_
carros com o modelo
usados where
Siena.
modelo = ‘siena’;
select
max(preco) from
carros_usados;
Seleciona preços
select
máximos ou mínimos
min(preco)
from carros_
usados;

Álgebra relacional e operadores
Serão mostrados diversos tipos de operações em tabelas utilizan-
do a álgebra relacional. Cabe dizer que existem vários tipos de filtros,
que são as variações de operações. Vamos abordar os seguintes:
- Seleção - seleciona os dados onde um critério é atendido.
- Projeção - seleciona os dados onde dois ou mais critérios são atendidos.
- União - faz a seleção apenas quando um dado está em duas tabelas diferentes.
- Diferenças - seleciona todos os dados exceto um.
- Interseção - descobre quais dados se repetem em duas tabelas diferentes.
Convém ainda falar de alguns conceitos, como:
• Cada tabela, contendo linhas e colunas, é bidimensional;
• As tabelas, ao serem criadas, possuem uma quantidade de linhas (também
chamadas de tuplas) variável, pois, quando se adiciona alguma pessoa, aumenta o
número de linhas;
• Tabelas são chamadas de relações;
• Já o número de colunas (também chamadas de atributos) geralmente é fixo, a
não ser que, pelo alter, seja adicionada uma coluna nova;
• O número de colunas é chamado de grau e o número de linhas é chamado de
cardinalidade. O exemplo a seguir, no Diagrama 2, tem um grau de 7 e uma cardi-
nalidade de 5.
DIAGRAMA 2. EXEMPLO DE ATRIBUTOS E TUPLAS
Nome da relação Atributos
ALUNO Nome SSN FoneResidencia Endereco FoneEscritorio Idade MPG

Benjamin Bayer 305-61-2435 373-1616 2918 Bluebonnet Lane null 16 3,21
Katherine Ashly 381-62-1245 375-4409 125 Kirby Road null 18 2,89
Tuplas
Dick Davidson 422-11-2320 null 3452 Elgin Road 749-1253 25 3,53
Charles Cooper 489-22-1100 376-9821 265 Lark Lane 749-6492 28 3,93
Barbara Benson 533-69-1238 839-8461 7384 Fontana Lane null 19 3,25
Fonte: RUIZ, 2017, p. 4. (Adaptado).

Seleção
A primeira operação fundamental é a seleção. O operador é a letra minús-
cula sigma (σ) do grego. Criando um exemplo, se criarmos uma nova tabela e
colocarmos dados nela:
use fiat;
CREATE TABLE FUNCIONARIO (
COD_FUNC INT NOT NULL,
NOME VARCHAR (30),
SALARIO decimal(6,2) NOT NULL,
VALE_COMBUSTIVEL DECIMAL(5,2)
);
INSERT INTO FUNCIONARIO VALUES
(1, ‘Juliano’, 2000.00, 200.00),
(2, ‘Julia’, 1200.00, 200.00),
(3, ‘Marcelo’, 1300.00, 200.00),
(4, ‘Gabriela’, 3000.00, 200.00);
No exemplo a seguir, o que demonstraremos em rela-

ção algébrica é o desejo de selecionar uma linha inteira
quando o nome Julia aparecer na tabela funcionários.
Primeiramente, segue em linguagem algébrica e depois em
linguagem SQL.
σ
nome = ‘Julia’(funcionario)
select * from funcionario where nome = ‘Julia’;
Ainda assim, é possível selecionar dois critérios ao mesmo tempo, por exem-
plo, salários maiores que R$ 1.300 e vale combustível maiores que R$ 100. Para
unir duas pesquisas, utiliza-se na fórmula o acento circunflexo (^). No SQL, ficaria
o operador and, deixando tudo da seguinte forma:
σ
salario > 1300 ^ vale_combustivel > 100(funcionario)
select * from funcionario where salario > 1300 AND vale_combustivel > 100;

Projeção
Imaginando que o desejo não seja selecionar uma linha e sim uma ou mais
colunas, este mecanismo chama-se projeção. Ele é representado pelo símbolo
da letra grega pi (π). Note que no exemplo a seguir serão projetadas tanto a colu-
na nome quanto a coluna salário.
π
nome, salario(funcionario)
select nome, salario from funcionario;bustivel > 100;
O resultado está representado na Tabela 3:
TABELA 3. SELEÇÃO APENAS DE NOME E SALÁRIO
Nome Salário
JULIANO 2000
JULIA 1200
Marcelo 1300
Gabriela 3000
União
Vamos supor que alguém (que se chamará Marco no exemplo a seguir) vende
carros novos e usados, e o gerente comercial quer ver tudo que ele vendeu, tan-
to na tabela de vendas de carros usados quanto na de carros novos. Para isso,
utiliza-se o comando UNION (∪).
π
nome(vendas_carros_usados), ∪ π salario(vendas_carros_novos)
Mas é impossível entender esta união sem ver as tabelas criadas e o coman-
do select funcionando. Assim, a Figura 7 ilustra a criação destas duas tabelas.

Marco vendeu um Palio
de R$ 28.000 em carros
novos
Marco vendeu um Idea

de R$ 40.000 em carros
usados
Note que o select

buscou o nome e o
valor das duas tabelas,
e utilizou o union
Seleção de duas tabelas

ao mesmo tempo
Figura 7. Union.
Diferença
Supondo que o interesse é selecionar todos os dados de uma tabela exceto
os de alguém em especial (como a Daniela no próximo exemplo), deve-se utili-
zar a sintaxe NOT IN. O resultado seria a tabela carros_usados sem a Daniela.
π
nome(vendas_carros_usados) – π nome.Daniela(vendas_carros_usados)
SELECT * from vendas_carros_usados
where valor > 20000
AND nome NOT IN (‘Daniela’);
Intercessão
Agora vamos supor que desejamos selecionar funcionários que ven-
deram tanto em uma tabela quanto em outra, ou seja, quais funcionários
estão nas duas. Para isso, primeiramente observe as sintaxes de criação
de duas tabelas:

use fiat
create table vendas_carros_usados (
nome varchar(30),
produto varchar(30),
valor decimal(7,2)
);
create table vendas_carros_novos (
nome varchar(30),
produto varchar(30),
valor decimal(7,2)
);
Agora que as duas tabelas foram criadas, duas tuplas serão inseridas em
cada uma.
insert into vendas_carros_novos values
(‘Marco’, ‘Palio’, 28000.00),
(‘Julio’, ‘Palio’, 29000.00);
insert into vendas_carros_usados values

(‘Marco’, ‘Idea’, 40000.00),
(‘Daniela’, ‘Palio’, 20000.00);
Como se pode perceber, novamente Marco aparece nas duas tabelas. Para
selecionar apenas dados que se repetem nas duas tabelas, utiliza-se o co-
mando Inner Join, conforme a Figura 8.
Selecione todos os dados da

tabela de carros usados,
Juntando com a de carros
novos, desde que os nomes
sejam iguais nas duas tabelas
Resultado
Figura 8. Inner Join.

Esta função pode ser representada da seguinte forma:
π
nome(vendas_carros_usados), ∩ π nome(vendas_carros_usados)
CITANDO
“A primeira operação em álgebra relacional que podemos definir é a
interseção de dois conjuntos (∩). Suponha que desejamos encontrar todos
os clientes que tenham tanto empréstimo quanto conta” (SILBERRSCHATZ
et al., 1999, p. 79).
Linguagem de controle de transações SGBD - TCL (Tran-

saction Control Language)
Ao criar tabelas, ao deletar, ou quando se deseja fa-
zer qualquer ação, pode-se criar tabelas com a engine
InnoDB e voltar atrás, por exemplo. Como você verá
na Figura 9, será criada a tabela clientes_novos, após
isso será digitado begin, para dizer que iniciou uma transação
e, após isso, será inserido o nome Julio na linha 13. Entretanto,
como o programador deseja desfazer esta ação de inserir, ele digi-
ta rollback no final. Isso é muito útil, pois evita erros. Quando se digita begin,
existe a possibilidade de voltar atrás com rollback, ou de confirmar com com-
mit, sem precisa usar o DML delete. Primeiramente, observe a sintaxe a seguir
e veja o InnoDB na tabela.

use fiat;
CREATE TABLE clientes_novos (
email VARCHAR(50),
) ENGINE=INNODB;

Begin e Rollback
Pudemos entender a importância dos comandos begin, rollback e commit.
Agora, observe o exemplo da Figura 9, no qual houve a inclusão de uma pessoa
e, após isso, houve o rollback. Quando selecionamos tudo, a inclusão não existe
mais, pois houve o rollback.
Início (begin)
Inserir
Rollback (voltar atrás)
Como voltou atrás na

hora de inserir, não
há dados nenhum
Figura 9. Rollback.
Commit
Agora, observe na Figura 10 que, com o commit, a operação foi confirmada e
o cliente permaneceu na tabela final. Após a tabela clientes ser criada, como pode
ser visto na linha 3, com as colunas cliente_id, nome, sobrenome, e-mail, data de
aniversário e média de visitas por mês, o programador digitou antes de tudo a
palavra begin para iniciar a transação. Depois digitou INSERT INTO CLIENTES (PRI-
MEIRO_NOME) VALUES (‘Julio’) para inserir um registro com o nome Julio e depois
confirmou e fechou a operação através do commit.

Figura 10. Commit.
Logo, o InnoDB é uma engenharia que possibilita transações e arrependimento.

Para completar, caso queira consultar a forma de uma tabela, suas constraints
e datatypes, use o describe mais o nome da tabela. Observe na Figura 11.
Função describe
Resultado
mostrando o
esqueleto da
tabela, seus
datatypes e
constraints
Figura 11. Função describe.

Sintetizando
Nessa unidade, foi possível ver grande parte da prática de MySQL. Consegui-
mos entender como criar tabelas, o que são constraints, not null, primary key,
entre outros itens. Além do mais, vimos como alterar o nome das tabelas, bem
como a forma de alterar tipos de dados. Foi passado como renomear (rename)
uma tabela, como deletar uma linha e como trocar valores (update).
Também estudamos sobre o select e vimos várias formas de fazer seleções,
o que não totaliza o tema, pois seleções são abrangentes em SQL, mas foi visto
como selecionar dados diferentes, dados maiores que um valor, máximos, mí-
nimos, etc. Sobre as operações de álgebra, vimos como fazer consultas, como
consultar dados diferentes, como fazer intercessão e união de dados.
Por fim, foi comentado que, na engine InnoDB, o commit serve para autorizar
uma transação e rollback significa voltar atrás, o que facilita a segurança na hora
de fazer transações.

TEOREY, T. et al. Projeto e Modelagem de Banco de Dados. Rio de Janeiro: Elsevier.
2014, p.6.
COSTA, E. Banco de Dados Relacional. 2011. 63 f. Trabalho de Conclusão de Curso
(Especialização) – Tecnólogo em Processamento de Dados, Faculdade de Tecnolo-
gia de São Paulo, São Paulo, 2011. Disponível em: <http://www.fatecsp.br/dti/tcc/
tcc0025.pdf>. Acesso em: 08 jul. 2019.
SILBERSCHATZ, A. et al. Sistema de Banco de Dados. São Paulo: Pearson-Makro
Books, 2004.
RUIZ, E. Modelo de Dados Relacional. São Paulo: USP, 2017.

UNIDADE
3 OPERAÇÕES
TEÓRICO-PRÁTICAS
EM NOSQL

Compreender a forma do NoSQL;

Entender o contexto do Big Data;
Conhecer operações do banco de dados orientado a documentos;
Aprender a incluir tuplas no MongoDB;
Entender as variáveis no MongoDB;
Compreender operações do banco de dados chave-valor.
VIDEOAULA
Clique aqui
Tópicos de estudo
NoSQL Banco de dados chave-valor
Principais características Redis: Comandos
Técnicas de implementação Operações com hashes
NoSQL
Big Data
Banco de dados orientado a

documentos
Passos práticos com MongoDB
Ordenação, buscas avançadas,
updates e agregação
Utilização de variáveis para
operações
Exportações e importações no
MongoDB

NoSQL
NoSQL não se define apenas por uma ferramenta de banco de dados. Por
outro lado, pode ser visto como uma maneira diferente de abordar tal assun-
to, constituindo-se como um conceito.
O mundo convive atualmente com uma quantidade exorbitante de dados.
Oceanos de dados e informações multiplicam-se progressivamente nos di-
versos segmentos empresariais, e é nesse contexto que o conceito de apren-
dizagem de máquina entra em cena.
Tendo em vista essas características, podemos concluir que, em alguns ca-
sos, um banco relacional pode ter efeitos relativamente lentos e limitadores.
Assim, novos programas operando em NoSQL possibilitam o aprendizado
instantâneo na criação de tabelas. Sim! Estamos falando também do conceito
de Big Data (dados abundantes).
Neste cenário dinâmico e acelerado, é necessário contratar, formar e
transformar tanto pessoas quanto equipes, para uma efetiva aderência aos
sistemas ágeis de gestão de dados.
Principais características
A quantidade de dados cresce exponencialmente. As tuplas (registros), os
atributos (colunas) e as relações (tabelas) tornaram-se dinâmicos, e daí decor-
re o conceito de escalabilidade horizontal (capacidade de crescer horizontal-
mente). Os bancos de dados não relacionais possibilitam uma escalabilidade
menos custosa, mais prática e ágil. Outro fator positivo é não depender de
máquinas “parrudas”, isto é, pesadas! Logo, com computadores mais leves, a
manutenção é, logicamente, menor, e a troca se torna mais fácil.
Um exemplo precursor dos bancos de dados não relacionais foi o BigTable,
criado pela Google em 2004, voltado ao gerenciamento de centenas de teraby-
tes, chegando até a petabyte de dados.
Pesquisas revelam uma significativa expansão dos bancos de dados não re-
lacionais diante dos relacionais. Existem alguns bancos NoSQL famosos, como,
por exemplo, DynamoDB, MongoDB, Redis, HBase, Neoj4 etc. As característi-
cas básicas de cada um deles serão explicadas mais adiante.

Vamos agora abordar algumas características do banco de dados não rela-
cionais.
1. Tolerância a falhas: Capacidade de contornar erros por longos períodos
de tempo, sem resultar em travamentos, e devido a eles, e responder rapida-
mente às requisições;
2. Escalabilidade: Incluir novos usuários, bancos e computadores, ligando-
-os aos usuários já existentes através de semelhanças (agrupamentos);
3. Simplicidade: Facilidade de manusear;
4. Perfomance e flexibilidade: O banco de dados não relacional é mais ágil
e performático, além de mais flexível que o relacional.
Existem alguns tipos distintos de bancos de dados NoSQL. Observe a Figura
1, que apresenta alguns conhecidos programas, bem como a categoria de ban-
co de dados à qual cada um pertence.
CHAVE-VALOR CHAVE-VALOR
ORIENTADO ORIENTADO
A GRAFOS A COLUNAS
ORIENTADO
A DOCUMENTOS
Figura 1. Bancos de dados NoSQL e seus tipos.
Serão explicadas as categorias e principais características de cada um desses

tipos de bancos de dados:
• Banco de dados chave-valor: A inserção de objetos é feita por chaves. O
método put( ) insere valores, e o método get( ) busca-os. Este modelo armazena
qualquer tipo de dado como valor de chave, tanto int e string como os demais.

Os valores são atribuídos às chaves. Dessa forma fica mais fácil encontrar va-
lores, isto é, mapeando-os pelas chaves. O DynamosDB, por exemplo, é um
serviço em nuvem ágil da Amazon (AWS).
Exemplo de programas: DynamosDB, Redis e DerkeleyDB.
• Banco de dados orientado a documentos: Armazenam e consultam pelo
método chave-valor, mas os dados são geralmente manipulados nos formatos
.JSON ou .XML, o que permite que o código usado seja o mesmo que é adotado
para linguagens de programas já existentes. O MongoDB, por exemplo, é um
software livre orientado, possui código aberto e lida com esquemas dinâmicos.
Exemplo de programas: Cassandra e Hadoop.
• Banco de dados orientado a colunas: Neste tipo de banco de dados,
cada valor é relacionado com a tabela, com a chave da coluna e da linha, sendo
mais fácil a busca e a recuperação de dados com características únicas. São
descentralizados, úteis para a formação de clusters (grupos) e, em geral, pos-
suem pouca latência.
Exemplos de programas: Cassandra e HBase.
• Banco de dados orientado a grafos: Ao invés
de guardar linhas (registros), guardam objetos, o
que é útil para conexão interna entre eles. Con-
tém vértices (nós), arestas (relacionamentos) e
atributos. Cada nó representa uma pessoa ou,
por exemplo, um produto, um fornecedor etc. As OBJETOS DE
APRENDIZAGEM
arestas são as relações entre as entidades, ou seja, Clique aqui
uma relação entre uma pessoa e outra. Por exemplo: João é amigo
de Marcela. João tem o carro Gol. Este exemplo é utilizado em redes
sociais, como no Facebook e similares.
Exemplos de programas: Sones Graph DB e Neo4j.
ASSISTA
Assista ao filme A Rede Social, de David Fincher, que
demonstra como a rede social Facebook nasceu e como VEJA +
Clique aqui
atingiu seu potencial de expansão. O filme apresenta
cenários de oportunidades em dados surpreendentes.

Técnicas de implementação NoSQL
Vamos abordar agora as principais
técnicas de implementação NoSQL:
Vector clocks: Existe uma disputa
de eventos nos sistemas. Por conse-
guinte, eventos são registrados nos
servidores como logs, que mostram
que pessoas entraram e saíram, di-
gitaram algo, optaram por algo etc.
Com base nisso, decorre que vetores,
que consistem em tabelas com apenas
uma linha e várias colunas, têm como função ordenar tais eventos: o primeiro
fica armazenado na linha 1, coluna 1; o segundo, por sua vez, na linha 1, coluna
2; o terceiro, logo, na linha 1, coluna 3, e assim sucessivamente. Então, conclui-
-se que tal tabela de uma só linha ordena as ações dos usuários por ordem de
ação, a fim de evitar que o segundo colocado ganhe o lugar do primeiro por
questões de milésimos de segundos. Por este modo, também é possível saber
quais dados são mais atuais.
MapReduce: Imagine que uma empresa tenha máquinas à venda distribuí-
das em diversas lojas de São Paulo. Os dados de compra de cada uma dessas
máquinas, independente da loja onde ocorreu a venda, são enviadas para um
servidor central da empresa. O gerente, então, pede para o cientista de da-
dos listar todas as televisões e suas receitas no último mês. O cientista faz o
mapeamento (map), visando a selecionar todas as notas de vendas. Como daí
resultariam muitas notas, com diferentes informações, a função reduce passa a
formar grupos, por exemplo:
• Grupo 1 – 7 vendas de televisões custando 1000;
• Grupo 2 – 8 vendas de televisões custando 2000.
E assim por diante. Ou seja, ao invés de listar tudo em uma só lista, mistu-
rando informações, ele as separa em grupos.
MVCC (Multiversion concurrency control) – Esta técnica impede que um
dado igual a outro substitua o antigo. Este paralelismo protege os dados de
serem removidos sem intenção explícita.

Big Data
Qual é a medida padrão para considerar uma quantidade de VIDEOAULA
Clique aqui
dados como Big Data? De onde decorrem os critérios para tal?
Dos números? Da periodicidade? Bem, vamos às respostas.
No Big Data existe uma retroalimentação constante de dados.
Logo, a periodicidade de alimentação de dados engloba intervalos menores! Ou
seja, em pouco tempo, muitos dados são inseridos.
Sabendo que os dados ocupam espaço, e espaço no mundo virtual é medido
por bytes, podemos dizer que 1000 bytes equivalem a um kilobyte, que 1000
kylobytes formam um terabyte, e, assim, que 1000 terabytes dão origem a um
petabyte. Enquanto o banco de dados relacional lida com unidades de grandeza
de aproximadamente até 90 terabytes, o Big Data lida com unidades de grande-
za maiores, conseguindo inclusive alcançar perabytes.
É provável, ainda, que novas unidades de medida sejam criadas. Por exem-
plo, vamos supor que no futuro seja necessário criar a medida millionbytes. Es-
tranho? Não! Por exemplo, cada computador tem um IPV4, que é seu endereço.
Existem IPs privados, que podem se repetir, mas os públicos não se repetem. Ou
seja: duas empresas diferentes não podem ter o mesmo IP. Considerando isso e
levando em conta que celulares, smartphones e câmeras, produzidos massiva-
mente a cada ano, também ganham seus IPs individuais, os IPV4 correm risco de
acabar. Por isso, foi criado o IPV6, para aumentar a grandeza do IP, viabilizando
a geração de mais endereços. Para acompanhar tal volume de dados novos, é
muito provável que novas medidas sejam criadas.
Enquanto o sistema tradicional analisa os dados por observação, o sistema
NoSQL o faz com inteligência artificial. Geralmente as fontes de dados para Big
Data são redes sociais, log on em sites, comentários em sites on-line etc.
Além disso, há mecanismos de registro por meio de sensores,
que muitas vezes são colocados em pessoas e VIDEOAULA
Clique aqui
animais, como em casos de tênis inteligentes,
os quais medem performances e desempe-
nho, e cujos gráficos, gerados durante os
treinos, podem ser carregados no computa-
dor através de uploads.

Outro exemplo de sensor pode ser encontrado no Hotel Crown Plaza Times
Square, que dispõe de sensores responsáveis por coletar dados acerca da luz e
da temperatura durante o dia. A partir deles, o sistema gerencia o aquecimento
e o esfriamento de forma automática, a fim de trazer mais conforto térmico e
energia ao mesmo tempo
Empresas de logística, como a FedEx, também entram neste exemplo. Carros
da frota possuem sensores, e é possível coletar dados em tempo real para recal-
cular rotas mais eficientes. Na área de aparelhos industriais, já existem sensores
que indicam a necessidade de automação e relatório de performance.
O setor financeiro analisa diariamente os dados acerca de aumentos e redu-
ções do mundo todo, e descobrem padrões estatísticos. A área de tecnologia de
informação e segurança da informação, por sua vez, pode coletar detalhes do
uso de dados relacionados a crimes e invasões já ocorridos e utilizá-los para se
proteger de possíveis ataques futuros.
Existem muitos exemplos capazes de serem aplicados. Segundo o autor e
pesquisador Thomas H. Davenport, especialista em Tecnologia da Informação,
em seu livro Big Data no trabalho, de 2017 (p. 8),
Em vez de dizer: “Estamos embarcando em uma iniciativa de Big
Data”, provavelmente seria mais construtivo dizer: “Vamos analisar
os dados de vídeo dos nossos caixas eletrônicos e agências bancá-
rias para entender melhor com os relacionamentos com os clien-
tes.” Ou, se a sua empresa atuar na área da saúde, vocês podem
decidir “Combinar os prontuários médicos eletrônicos com dados
genômicos para sugerir tratamentos personalizados aos pacientes.
Banco de dados orientado a documentos

O banco de dados MongoDB é orientado a documentos e utilizado para
aprendizado. Foi criado em 2009 e serve para qualquer sistema operacional,
tanto Linux quanto Windows, entre outros. Além disso, é gratuito.
No MongoDB, o banco de dados também recebe a denominação database. A
tabela é chamada de collection ou coleção. As linhas, por sua vez, são documents
(BSON) ou documentos. E as colunas, por fim, são referidas como fields ou, em
português, campos.

Agora vamos conhecer as sintaxes na prática: é possível manipular por linha
de comando ou pelo programa em si; vamos iniciar pelo programa. A seguir, ob-
serve o tutorial para criar um novo banco de dados, chamado “ford”, e uma tabe-
la chamada “colaboradores”.
Digite estes dados para criar

uma nova conexão
Figura 2-1. Captura de tela do MongoDB: criar conexão, banco de dados e coleção.
Clicar em Create Database

Criar um banco de dados cha-
mado “ford” e uma coleção
chamada “colaboradores”
Abrir a coleção
“colaboradores“
Agora observe na Tabela 1 a comparação entre os comandos do MySQL e os

do MongoDB.

TABELA 1. COMANDOS DO MONGODB
Inserir e selecionar no MySQL Inserir e selecionar no MongoDB
db.colaboradores.insert({
INSERT INTO colaboradores (func_id, func_id: ‘01’,
func_nome, cargo) func_nome: ‘Joao’,
VALUES (‘bcd001’, 45, ‘A’) cargo: ‘Gerente’
})
SELECT * FROM colaboradores db.colaboradores.find()
Agora, para ver estas informações no shell (linha de comandos), realize o se-
guinte procedimento:
1. Vá até a pasta Este Computador/Meu Computador no Windows;
2. Vá até o Disco Local (C:);
3. Entre na pasta Arquivos de programas;
4. Clique na pasta MongoDB;
5. Acesse a pasta Server;
6. Entre na pasta Bin;
7. Clique em mongodb.exe;
8. Na tela preta que se abrir, digite CLS;
9. Digite show databases e veja o banco de dados da ford criado.
Figura 3. Captura de tela do MongoDB: banco de dados em linha de comando.

O banco de dados orientado a documentos possui chaves e valores. Na sin-
taxe a seguir, a palavra “produto” é uma chave, enquanto a palavra “mesa” é um
valor, a palavra “preco” é uma chave e “200” é um valor.
{“produto” : “Mesa “, “preco” : 200}
Cada coleção – isto é, cada tabela – possui vários documentos (registros) que
abrigam dados de naturezas distintas. Na coleção “produtos”, por exemplo, pode
haver um documento contendo um computador e seu respectivo preço. Em outro
documento desta mesma coleção, um telefone e seu preço, e assim por diante.
Ao criar coleções, deve-se tomar cuidado com letras maiúsculas e minúscu-
las, pois o MongoDB faz distinção entre caixas altas e baixas. Essa condição faz
com que o programa seja caracterizado como case sensitive, isto é, que faz tal
distinção.
Passos práticos com MongoDB

Existem alguns tipos de dados que vale a pena mencionar. São eles – segui-
dos de exemplos:
• Strings: “Juliana”;
• Numbers: 25
• Booleans: false ou true
• Array: [‘Blusa’, ‘Calça’, ‘Luva’]
• Documents/Objects: binário
A partir de agora, as operações serão feitas em linha de comando.
Para criar coleções e inserir documentos:
Entre na linha de comando e realize os seguintes passos, de forma a ficar
como representado na Figura 4:
Passo 1: digite use ford; para ativar o banco de dados ford;
Passo 2: crie uma coleção chamada “Compradores”, com a seguinte sintaxe
db.createCollection(“Compradores”))
Passo 3: insira os respectivos dados, conforme indicado na Figura 4;
db.compradores.insert({_id:1, nome: “Gabriel”, salario: 3000, idade: 28})
Passo 4: Selecione todos os documentos com a sintaxe db.compradores.
find()
Caso queira limpar a tela, digite CLS e aperte em Enter.

Figura 4. Captura de tela do MongoDB: criação de coleção, inserção de documento e pesquisa de documentos na tabela.
Vamos supor que mais dois dados sejam inseridos:

db.compradores.insert({_id:2, nome: “Julio”, salario: 5000, idade: 33})
db.compradores.insert({_id:3, nome: “Fabio”, salario: 2000, idade: 27})
Para remover documentos:
Para remover o documento 2, basta digitar a seguinte sintaxe:
db.compradores.remove({_id: 2})
Desta forma foi removido o documento com os dados do comprador hipo-
tético de nome Julio.
Para pesquisar documentos:
Para fazer uma pesquisa por nome, utiliza-se a seguinte sintaxe:
db.compradores.find({nome:”Fabio”})
O resultado será a seleção apenas dos dados relacionados ao comprador
hipotético de nome Fábio, ou seja:
{ “_id” : 3, “nome” : “Fabio”, “salario” : 2000, “idade” : 27 }
Ordenação, buscas avançadas, updates e agregação

De maneira prática, vamos ver outras opções disponíveis em consultas e
demonstrações. Para isso, vamos inserir mais dois documentos, referente aos
compradores Flávio e Fábia, o que nos permitirá trabalhar com um número
maior de dados:
db.compradores.insert ({ _id: 4, nome : “Flávio”, salario : 5000, idade: 29 })
db.compradores.insert ({ _id : 5, nome: “Fábia”, salario : 3000, idade : 40 })
Após digitar a sintaxe de pesquisa, o resultado deve conter no mínimo qua-
tro documentos, isto é:

> db.compradores.find({})
{ “_id” : 4, “nome” : “Flávio”, “salario” : 5000, “idade” : 29 }
{ “_id” : 5, “nome” : “Fábia”, “salario” : 3000, “idade” : 40 }
{ “_id” : 1, “nome” : “Gabriel”, “salario” : 3000, “idade” : 28 }
Para pesquisar por ordem decrescente ou ascendente:
Mas, vamos supor que seja necessário pesquisar os dois salários mais bai-
xos, pois a contabilidade solicitou tais informações. Para tanto, digitaremos a
seguinte sintaxe:
Agora vamos db.compradores.find({}).sort({salario:1})
Agora, vamos supor que, ao contrário, a intenção fosse de pegar os salários
mais altos. Nesse caso, seria necessário digitar -1, indicando a ordem decres-
cente, como mostrado a seguir:
db.compradores.find({}).sort({salario:-1})
A Tabela 2, a seguir, apresenta alguns comandos de comparação por tamanho.
TABELA 2. BUSCAS AVANÇADAS
$lte Números menores ou iguais a
$lte Números menores que
$gte Números maiores ou iguais a
$gte Números maiores que
$regex “^F” Textos que começam com F
$regex “9222$” Por exemplo, telefone que terminam com 9222

Para pesquisar pela letra inicial E por tamanho do salário:
A Figura 5 expõe o comando a ser digitado para se buscar nomes iniciados por
F e, ao mesmo tempo, salários menores que 3200.
Figura 5. Captura de tela do MongoDB: pesquisas detalhadas.
Para realizar os procedimentos que apresentamos a seguir, crie outra coleção

chamada “Carros”, que permitirá manusear ainda mais dados. Para tal, utilize a
seguinte sintaxe:
>db.createCollection(“Carro”)
Para apagá-la, utilizamos:
> db.Carro.drop()
Para atualizar dados
Agora, a sintaxe a seguir mostra como criar a coleção Carros, inserir dados e
atualizar o nome do carro, alterando-o de Ecosport, por exemplo, para Ecosport 2,2:
> db.createCollection(“Carros”)
{ “ok” : 1 }
> db.Carros.insert({_id:1, nome: “Ecosport”, preco: 60000, ano: 2019})
WriteResult({ “nInserted” : 1 })
>
> db.Carros.update({‘nome’:’Ecosport’},{$set:{‘nome’:’Ecosport 2.2’}})
WriteResult({ “nMatched” : 1, “nUpserted” : 0, “nModified” : 1 })
O carro teve seu nome alterado.
Agregações de tabelas
Agora, vamos supor que o intuito seja buscar em uma coleção nova todos os
documentos contendo cargo comercial.

db.membros.insert({“nome”:”Gabriel”,”sobrenome”:”Souza”,”cargo”:
”Analista”, “empresa”:”xx”})
db.membros.insert({“nome”:”Gabriel”,”sobrenome”:”Farias”,”cargo”:”-
Gerente”, “empresa”:”xx”})
db.membros.insert({“nome”:”Daniela”,”sobrenome”:”Farias”,”cargo”:”-
Comercial”, “empresa”:”xx”})
db.membros.insert({“nome”:”Gabriela”,”sobrenome”:”Souza”,”cargo”:”-
Comercial”, “empresa”:”xx”})
Para isso utilizaríamos o comando a seguir:
>db.membros.aggregate([{“$match”:{“cargo”:”Comercial”}}])
O resultado seria uma relação apenas de pessoas com cargo comercial.
Utilização de variáveis para operações

Um banco de dados orientado a do-
cumentos possibilita a integração com
JSON e JavaScript (Js). Js é uma lingua-
gem de programação para sites, capaz
de fazer eventos e controles front end,
isto é, o usuário pode vê-los. Criar va-
riáveis é útil para colocar funções den-
tro de palavras, numa espécie de encapsulamento.
Para prosseguimos com a parte prática, devemos, antes de mais nada, apa-
gar a coleção “Carro” através do comando drop.
> db.Carro.drop()
True
Observe que a sintaxe a seguir insere um nome para o carro e estabelece
dois anos (2019 e 2018), o que significa que no estoque hipotético há um Ecos-
port de 2018 e outro de 2019.
var carro1 = { nome : “Ecosport”, “anos” : [“2019”,”2018” ]}
EXPLICANDO
Toda vez que se utilizam colchetes – isto é, [] – cria-se um array, que pode
conter vários valores em um só campo. Na sintaxe apresentada, por exemplo,
apresentamos o campo “anos” com dois valores.

No exemplo, a variável carro 1 recebeu um documento. Vamos inseri-la agora
na tabela Carro. Mas lembra-se que ela foi apagada? Aqui nos deparamos com uma
das vantagens de banco de dados orientado a documentos: ao inserir a variável na
tabela Carro, ela é recriada automaticamente.
Ao mostrar as coleções, só existe a

compradores e a colaboradores
A variável carro1 é criada
Mesmo não mais existindo a tabela

carro, a variável é inserida
Ao pesquisar com o find, os dados são exibidos,

e o id foi criado automaticamente
Figura 6. Captura de tela do MongoDB: variáveis.
Agora, seguindo a lógica das variáveis, será mostrado como fazer uma pesquisa
com $in, ou seja, que retorne documentos contendo dados pré-determinados.
Insira os seguintes dados:
> var carro2 = { nome : “Fiesta”, “anos” : [“2019”,”2018” ]}
> var carro3 = { nome : “Focus”, “anos” : [“2016”,”2017” ]}
> var carro4 = { nome : “KA”, “anos” : [“2018”,”2017” ]}
Após isso, insira estes dados na tabela:
> db.Carro.insert(carro2)
Note que, na criação das variáveis, só dois carros possuem os anos 2017. Da mes-
ma forma que poderíamos procurar amigos em comum, quando lidando com pes-
soas, podemos procurar carros que compartilhem o mesmo ano em comum (2017):
> db.Carro.find({anos : {$in : [“2017”]}})
O resultado mostrará apenas o carro 3 e o carro 4, como indicado a seguir.
{ “_id” : ObjectId(“5d35ebb22849757efe327953”), “nome” : “KA”, “anos” : [
“2018”, “2017” ] }
{ “_id” : ObjectId(“5d35ebb82849757efe327954”), “nome” : “Focus”, “anos” :
[ “2016”, “2017” ] }

Exportações e importações no MongoDB
Em banco de dados orientado a objetos é possível fazer importações de
documentos JSON e CSV pela nomenclatura mongoimport; exportações de
documentos CSV e JSON pela nomenclatura mongoexport; e backups pela
nomenclatura mongodump. Arquivos CSV e JSON podem ainda ser abertos
no Microsft Excel em forma de tabelas. Para realizar tal procedimento, abra
novamente o programa MongoDB e siga os passos indicados na Figura 7 para
exportar a coleção.
Figura 7-1. Captura de tela: exportando dados do MongoDB para Microsoft Excel.
SALVE COMO CSV

OU JSON

ABRA O ARQUIVO
EXCEL E IMPORTE
OS DADOS
Além de exportar é possível importar, e pode-se realizar estas ações por

linha de comando usando as nomenclaturas mencionadas.
Também é possível importar os dados para o MongoDB seguindo os mes-
mos passos dispostos na Figura 7, mas em vez de clicar em Export, deve-se
clicar em Import.

Banco de dados chave-valor
Para compreender o banco de
dados chave-valor, utilizaremos o
Redis, um programa extremamente
rápido, que suporta mais de 80000
get (puxar) e 110000 set (alterar) por
segundo.
O banco de dados chave-valor
se comporta como um dicionário
(hash). Cada título contém um valor.
Este modelo permite a inclusão de
dados livres, sem ter necessaria-
mente uma estrutura. Como já dito
anteriormente, qualquer dado é
aceito, seja inteiro, string, array etc.
A chave se torna o índice. Assim, para achar o valor, basta buscá-la. En-
quanto o set insere uma chave e um valor, o get chama este valor e o recupera.
Apesar do dinamismo, muitas duplicidades de dados podem ser geradas.
EXEMPLIFICANDO
Vamos supor que existam três unidades de uma academia. O banco de
dados chave-valor duplicará muitos dados por não criar atributos que se
repetem em todas as academias, como, por exemplo, o atributo “Aulas de
Ginástica”. Ora, por estarem sob a mesma direção, todas as unidades têm
as mesmas aulas, mas o banco de dados relacional não cria os atributos
aulas, o que consistiria em uma tabela só, com aulas x horário x unidade.
Agora será mostrado como utilizar os comandos a seguir:

• set insere um dado = set “chave” “valor”;
• get recupera o dado = get “chave”;
• del deleta o dado = del “chave”;
• set EX 5 = Insere um dado que será exibido por apenas cinco segundos.
A Figura 8 mostra um dado que, passado o período de exibição, dá lugar ao
código nil (= Nulo), ou seja, o dado não é mais exibido

Figura 8. Captura de tela do Redis: inserindo dados por set, chamando por get, função del e dados temporários.
Redis: Comandos
Supondo que se deseja serializar um dado e removê-lo do banco, mas deixá-lo
armazenado para futuras aplicações, ou ainda aplicações em outros servidores,
deve-se usar o dump, seguindo o seguinte script:
Serializar nome
Deletar nome
Resgatar dado pela série
Valor resgatado e exibido

pelo get
Figura 9. Captura de tela do Redis: resgatando uma chave.

A seguir, na Tabela 3, estão os significados de cada item:
TABELA 3. SERIALIZANDO UM DADO
Comando Ação
> set nome "Julio Fava" Inseriu o nome Julio Fava
Serializou o nome pelo dump

> dump nome
“\x00\nJulio Fava\x06\x00#\x1f\x0b#\x97\xd5\x8f\xe7”
del nome Nome deletado
get nome Buscar o nome (nada será achado)
Agora o nome será resgado pela série, o que vale a pena conhecer, pois esta sé-
rie pode ser utilizada em vários servidores diferentes, ou pode ainda ser utilizada
depois. Observe na Tabela 4:
TABELA 4. RESGATANDO UMA SÉRIE
Comando Ação
> restore nomeresgatado 0

Resgatar um
“\x00\nJulio Fava\x06\x00#\x1f\x0b#\x97\xd5\x8f\xe7”
> get nomeresgatado Mostra o nome agora resgatado
Isso é muito útil, pois imagine, por exemplo, que um dado precise ser deletado
de um banco de inadimplentes, mas possa ser facilmente reutilizado depois: caso
a pessoa entre de novo em dívida, é só resgatar a série do seu nome; ou então no
caso de uma transferência, supondo que uma pessoa mudou-se da unidade da
zona sul de uma empresa e foi para a da zona norte, então basta o RH serializar
este dado com o dump e passá-lo para o outro banco.
Supondo que na empresa seja necessário cadastrar novas chaves, como pro-
dutos de estoque, e antes seja necessário saber se a equipe que está no servidor
não a criou ainda, de forma que é necessário fazer uma pergunta a respeito. Para
saber se uma chave existe, utiliza-se o exists.
Como o nome resgatado voltou a existir, observe o teste no código a seguir,
onde 1 significa que o dado existe, e 0 indica que ele não existe:

> exists nomeresgatado
(integer) 1
> exists nomeresgatado3
(integer) 0
Há situações na empresa em que é necessário renomear uma chave, por
exemplo, supondo que se queira mudar o nome da coluna de nome para clien-
te, seja por terem criado a coluna com uma nomenclatura ou por estarem fa-
zendo melhorias na gestão de bancos de dados na empresa – qualquer que
seja a justificativa pela qual o TI tenha decidido organizar e normalizar as tabe-
las, então será utilizado o rename.
Para isso, é necessário escrever novas chaves com valores:
127.0.0.1:6379> set nome1 Daniel
OK
127.0.0.1:6379> set nome2 Daniela
OK
127.0.0.1:6379> set nome3 Gabriela
OK
Agora, com o comando keys *, pode-se listar as já existentes:
127.0.0.1:6379> keys *
1) “nome2”
2) “nome3”
3) “nome1”
Para renomear a chave, passando-a de nome para cliente, utiliza-se a se-
guinte sintaxe:
127.0.0.1:6379> RENAME nome1 cliente1
OK
OK
OK
127.0.0.1:6379> keys *
1) “cliente1”
2) “cliente2”
3) “cliente3”

Operações com hashes
É possível cadastrar várias chaves e valores de uma vez só e, com isso, bastante
tempo é economizado.
O comando hmset cria um grupo, uma chave e um valor de uma vez só. Por sua
vez, o comando hgetall lista todas as chaves e valores do grupo.
Observe que, por meio dos comandos a seguir, serão criadas dentro do grupo
EMPRESA a chave clientes e a chave funcionários, já com seus valores:
hmset EMPRESA funcionario1 Julio cliente1 Fabio
Assim, no grupo EMPRESA, Fabio foi inserido na chave clientes, enquanto Julio
foi inserido na chave funcionários. Agora, mais dois valores serão inseridos em
cada chave:
hmset EMPRESA funcionario2 Marcela cliente2 Gabriel
hmset EMPRESA funcionario3 Juliana cliente3 Daniela
Observe este modelo no Diagrama 1:
DIAGRAMA 1. GRUPOS (HMSET)
EMPRESA
FUNCIONÁRIOS CLIENTES
Julio (Funcionario1) Fabio (cliente1)
Marcela (Funcionario2) Gabriel (Cliente2)
Juliana (Funcionario3) Daniela (Cliente3)

Agora é possível observar todas as sequências com o comando hgetall. A seguir
será exibido chave, depois valor, e então chave, depois valor etc.
127.0.0.1:6379> hgetall EMPRESA2
1) “funcionario1”
2) “Julio”
3) “cliente1”
4) “Fabio”
6) “Marcela”
7) “cliente2”
8) “Gabriel”
10) “Juliana”
11) “cliente3”
12) “Daniela”
A partir disso, suponhamos que a empresa deseja armazenar um organogra-
ma com hierarquia de funcionários.
DIAGRAMA 2. QUADRO DA EMPRESA COM LPUSH
Daniel
(direção)
Marketing Financeiro Operacional
Gabriela Juliano Gabriel Daniela Lucas Flavia

Observe o Diagrama 2 a seguir: Para criar este organograma, utiliza-se as se-
guintes sintaxes:
127.0.0.1:6379> Lpush marketing Joao
(integer) 1
127.0.0.1:6379> Lpush marketing Gabriela
(integer) 2
127.0.0.1:6379> Lpush financeiro Juliana
(integer) 1
127.0.0.1:6379> Lpush financeiro Daniela
(integer) 2
127.0.0.1:6379> Lpush financeiro Gabriel
(integer) 3
127.0.0.1:6379> Lpush direcao Daniel
(integer) 1
127.0.0.1:6379> Lpush operacional Lucas
(integer) 1
127.0.0.1:6379> Lpush operacional Flavia
(integer) 2
E aqui concluímos esta demonstração prática, complementando também a
teoria exposta.

Sintetizando
Neste texto, foram ensinados os principais conceitos acerca da linguagem
NoSQL, cujo surgimento se dá junto ao dos bancos de dados não relacionais,
buscando escalabidade, flexibilidade, economia de máquinas e agilidade.
Focamos principalmente em demonstrar as diferenças teóricas e práticas
entre os bancos de dados orientados a documentos, a colunas w chave-valor,
bastante usuais no mundo NoSQL.
Dissertamos sobre o conceito de Big Data e como ele tem funcionado na so-
ciedade. Um dos principais efeitos do progressivo aumento do volume de in-
formações é que, atualmente, precisamos trabalhar com elas no nível de uma
unidade de medida denominada petabyte.
Na parte prática, focamos principalmente no MongoDB, um banco de dados
orientado a documentos, bem como suas funções de ordenação por ordem cres-
cente e decrescente. Para além disso, também expusemos os procedimentos
para se fazer buscas especificas em MongoDB usando o comando find.
No banco de dados chave-valor, utilizamos o Redis, para demonstrar como se
dá a criação com set e recuperação com get, bem como a utilização do comando
rename para atualizar nomes de chaves e del para deletar dados.
Ainda no Redis abordamos a criação de hashes a fim de se criar grupos, bem
como criar estruturas hierárquicas com o lpush.
VIDEOAULA
Clique aqui

A REDE SOCIAL | Trailer 2 Legendado. Postado por Sony Pictures Brasil. (1min
31s.). son. color. leg. Disponível em: <https://www.youtube.com/watch?v=kAwIKMY-
N6UU>. Acesso em: 28 ago. 2019.
DAVENPORT, T. H. Big Data no trabalho. Tradução de Cristina Yamagami. Rio de
Janeiro: Alta books. 2017.
COSTA, E. R. Banco de dados relacionais. 2011. 63 f. Trabalho de Conclusão de Cur-
so (Graduação) – Faculdade de Tecnologia de São Paulo, São Paulo, 2011. Disponível
em: <http://www.fatecsp.br/dti/tcc/tcc0025.pdf>. Acesso em: 08 jul. 2019.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. Tra-
dução de Daniel Vieira. Rio de Janeiro: Elsevier, 2012.
TEOREY, T. et al. Projeto e modelagem de banco de dados. Tradução de Daniel
Vieira. 2. ed. Rio de Janeiro: Elsevier, 2014.

UNIDADE
4 APROFUNDAMENTO
EM NOSQL, GRAFOS,
COLUNAS E ACID

Conhecer modelos de pensamento de banco de dados orientados a coluna;
Conhecer modelos de pensamento de banco de dados orientados a grafos;
Aprender a mexer em banco de dados orientado a grafos;
Compreender a estrutura ACID;
Aprender a fazer instalações avançadas.
VIDEOAULA
Clique aqui
Tópicos de estudo
Banco de dados orientado a Particionamento funcional
grafos: para que serve Teorema CAP
Conhecendo os grafos BASE x ACID: elementos dife-
Conhecendo a linguagem Cypher renciadores
Banco de dados orientado a Banco de dados orientado a

grafos: como mexer colunas
Criando vértices, labels e pro- Banco de dados orientado a
priedades colunas: Teoria sobre o Big Table
Usando o MATCH para fazer e o Hbase
pesquisas Banco de dados orientado a
Criando arestas (relacionamentos) colunas: teoria sobre o Cassandra
Editando e deletando grafos Criação de um banco de dados
no Cassandra
BASE x ACID
ACID

Banco de dados orientado a grafos: para que serve
O banco de dados orientado a grafos (GDB) é um banco de dados não re-
lacional (NoSQL) composto pelos seguintes itens:
Vértices: que são entidades;
Arestas: que são relacionamentos entre entidades;
Grafos: que representam a união entre vértices e entidades.
Conhecendo os grafos
O Diagrama 1 mostra como funciona este esquema, que é muito utilizado
em redes sociais famosas, como o Twitter, por exemplo. Nesse exemplo, os
vértices são representados pelas pessoas e o programa, enquanto as arestas
representam as relações entre esses entes.
DIAGRAMA 1. EXEMPLO DE BANCO DE DADOS COM VÉRTICES
Tipo: pessoa
Nome: Julio
Bairro: Cerqueira César
Idade: 25
Tipo: pessoa
Tipo: programa de TV
Nome: Gabriela
Nome: Esportes Radicais
Bairro: Vila Mariana
Horário: 22 h
Idade: 28
Existem alguns modelos de grafos, que serão citados a seguir:

• Grafos simples: quando dois vértices estão interligados entre si, forman-
do um par;
• Grafos aninhados: quando um vértice é filho de outro; por exemplo, o
vértice shampoo e o vértice sabonetes são filhos do vértice produtos de banho;
• Grafos de propriedades: quando existem propriedades entre os vértices
(como no Diagrama 1).

Para os fins do curso, o banco de
dados escolhido foi o Neo4j, criado
pela empresa New Technology, muito
usado, e provavelmente o mais popu-
lar que existe, em orientação a grafos.
Da mesma forma que o Redis, o Neo4j
também é composto de chave/valor,
porém possui nós (vértices) e arestas
(relacionamentos). Uma propriedade
importante dele é a capacidade de
percorrer todos os nós para buscar
uma informação.
Essa capacidade de atravessar os
dados faz do Neo4j muito eficaz. Exis-
tem três tipos de instalação dele, a en-
terprise que é para paga, a community
e a desktop, que são gratuitas. Nós
trabalharemos com a community.
A teoria dos grafos é baseada em uma multiplicação:
G = (V * A)
Onde G representa os grafos, V representa os vértices e A representa as

arestas. Na matemática, existe a teoria dos grafos, que estuda as relações
entre determinados objetos.
Um grafo pode ser utilizado pelas redes sociais para descobrir amigos, gos-
tos e grupos em comum, chegando até a gerar propagandas direcionadas para
as pessoas através dessas descobertas. Podemos pensá-lo como uma árvore,
que mostra como as pessoas interagem com as outras. Cada galho é uma inte-
ração – às vezes uma compra, às vezes uma relação de parentesco etc. A orien-
tação a grafos também é muito utilizada em genética, uma vez que os fatores
biológicos influenciam e são influenciados pelos relacionamentos.
Apesar do Neo4j ter sido desenvolvido recentemente, a matemática orien-
tada a grafos surgiu em torno de 1730 e 1740, com o objetivo de criar pontes
entre vértices através dos arcos (arestas).

Conhecendo a linguagem Cypher
Cypher é a linguagem declarativa de consulta por grafos, que possibilita con-
sultas eficientes, atualizações (updates) e algumas outras ações dispostas na lin-
guagem SQL. Ela é simples, mas influente e poderosa para fazer relações.
Mas você pode se perguntar: “Ela é boa para fazer relações? É uma linguagem
relacional?” Bem, não é assim. Cypher pode fazer muitas relações horizontais
e, nesse aspecto, a escalabilidade horizontal vem com tudo. A linguagem SQL
utiliza comandos fáceis para ações simples (por exemplo CREATE e DELETE), en-
quanto para ações difíceis ela cria triggers, funções, que são bem complexas de
escrever. Já a linguagem Cypher utiliza principalmente CREATE, MATCH, WHERE
e RETURN, e com esses quatro comandos faz tanto coisas simples quanto com-
plexas.
MATCH: serve para achar um objeto, é uma ferramenta de pesquisa;
CREATE: serve tanto para criar vértices quanto para inserir dados;
WHERE: serve para criar uma condição; por exemplo, a relação na qual o
nome for João;
RETURN: serve para exibir os dados.
Banco de dados orientado a grafos: como mexer

A primeira coisa que devemos fazer é aprender a instalar o Neo4j. Sua insta-
lação tem algumas peculiaridades. Não é difícil, mas é diferente. Detalharemos
a seguir.
1. Baixar atualização do Java SE (esta etapa é obrigatória), conforme Figura 1;
2. Baixar o aplicativo no site Neo4j, conforme Figura 2;
3. Descompactar a pasta e copiar o endereço da pasta bin, conforme Figura 3;
4. Colar o endereço no CMD e instalar o Neo4j pelo CMD, conforme Figura 4;
5. Testar o localhost:7474.
Passo 1. O JavaSE serve para ligar o programa
na porta 7474. Mesmo que o computador já o
possua, é necessário baixar a última versão.
Para isso, entre no site oficial do Oracle e baixe o
mesmo.

1. Procure no google o site com as
palavras “Oracle Baixar Java Se”
2. Clicar em Java
3. Baixe o Java
(talvez seja preciso
fazer um cadastro)
4. Instale o arquivo baixado
Figura 1. Como baixar JavaSE.
Passo 2. Com o Java instalado, entre no site do Neo4J e faça o download do

programa.
Faça o download; talvez o site peça alguns

dados, caso isso ocorra, preencha
Figura 2. Como instalar o Neo4j.

Passo 3. Com o Neo4J instalado, descompactar a pasta neo4j-commu-
nity-3.5.8 e copiar o endereço na pasta descompactada.
2. Extrair (descompactar)
1. Clicar com o botão

direito e descompactar
3. Entrar na pasta descompactada
4. Entrar na pasta neo4j-community
5. Entrar na pasta bin e

copiar o endereço
Figura 3. Descompactar a pasta do Neo4j e colar endereço da pasta bin.

Passo 4. Após copiar o endereço da pasta, abra o CMD como administrador
e digite as sintaxes marcadas na Figura 4.
1. Clicar no botão direito e executar

prompt como adminstrador
Figura 4-1. Instalar Neo4j.
2. Digitar cd e clicar com o botão direito do mouse para

colar o endereço, para entrar na pasta bin
3. Digitar
neo4j.bat
4. Serviço
install-service
instalado
5. Instalar
7. Start com sem o final
sucesso “.bat” para
6. Dar start no
garantir
Neo4j
Figura 4-2. Instalar Neo4j.
Passo 5. Para terminar a instalação, abra o navegador e teste se está abrindo

o localhost:7474, conforme a Figura 5.

1. Entre no localhost:7474
2. Tanto o usuário quanto a senha são neo4j;

o sistema pode pedir uma senha nova após
esta tela, caso ocorra isso, crie uma senha
3. Ambiente neo4j
Figura 5. Entrando no ambiente Neo4j.
Criando vértices, labels e propriedades

Agora vamos introduzir o manuseio do banco de dados em grafo na prática.
A sintaxe a seguir mostra como criar um vértice chamado “dp”. O grafo “dp”
terá dois departamentos, um para o setor de TI (Tecnologia da Informação) e
outro para o setor de marketing.
create (dp: Departamento {name: ‘TI’, empresa: ‘Fiat’})

create (dp: Departamento {name: ‘Marketing’, empresa: ‘Fiat’})
No código citado, pode se dizer que:

• O dp é o vértice (por vezes chamado de nó, ou node em inglês);
• Departamento é o label (ou tipo);
• Name e empresa são os atributos;
• Os valores TI, marketing e fiat são as propriedades;

Para exibir estes grafos, digita-se:
match (dp: Departamento) return dp
A resposta poderá ser exibida de várias formas. A Figura 6 mostra a forma

de inserção desses grafos e duas formas de exibir os dados.
{
“name”: “TI”,
“empresa”: “Fiat”
}
{
“name”: “Marketing”,
“empresa”: “Fiat”
}
Após criar o grafo “dp” com a

propriedade TI, clique em play
Resultado:
1 nó (vértice) adicionado (chamado dp)
1 label adicionado (chamado Departamento)
2 propriedades adicionadas
(name: TI e empresa: FIAT)
Após criar o grafo “dp” com a

propriedade marketing, clique em play
O comando MATCH exibe o grafo O comando MATCH exibe o grafo
Exibido
Exibido como grafo
como tabela
Figura 6. Criando e exibindo grafos em Neo4j.

Usando o MATCH para fazer pesquisas
Antes de iniciarmos nossos estudos sobre como executar as pesquisas, faz-se
necessário recapitular como foi a sintaxe da criação dos departamentos:
create (dp: Departamento {name: ‘TI’, empresa: ‘Fiat’})

Se quiséssemos pesquisar todos os departamentos escreveríamos:
match (dp: Departamento) return dp
E ele retornaria duas bolinhas, referentes aos dois departamentos.

Mas se o desejo é achar as informações relativas apenas a TI, é necessário pri-
meiro descobrir qual ID foi atribuído àquele registro. No final da Figura 6, pode-se
ver que o ID de TI é 44, logo, a pesquisa seria da seguinte forma:
match (dp: Departamento) where id(dp)=44 RETURN dp
O resultado seria apenas a bolinha do TI. Note que usamos o WHERE (onde), ou
seja, estamos dizendo para o programa pesquisar os departamentos onde (WHERE)
o ID foi 44.
Ainda assim, se quiséssemos que retornasse apenas algumas informações de TI,
por exemplo, nome ou empresa aumentaríamos o retorno, mas antes de falar como
seria, é necessário recapitular como foi a criação do TI:
Agora, poderíamos pesquisar somente ou nome:
match (dp: Departamento) where id(dp)=44 RETURN dp.name
O resultado seria:
dp.name
“TI”
Ou somente a empresa:
match (dp: Departamento) where id(dp)=44 RETURN dp.empresa

O resultado seria:
dp.empresa
“Fiat”
Criando arestas (relacionamentos)

Agora, vamos ensiná-lo a criar relacionamentos entre as entidades e visua-
lizá-los graficamente na tela. Para isso, criaremos dois usuários, a Juliana e o
Márcio, depois faremos um vínculo chamado f (mais conhecido como alias),
que conterá um relacionamento com o nome de “AMIGOS_COM”. O resultado
gráfico pode ser demonstrado a seguir.
Primeiro, observe a criação de dois usuários:
CREATE (Marcio:Usuário {nome:’Marcio’, sexo:’M’, idade:’29’})

CREATE (Juliana:Usuário {nome:’Juliana’, sexo:’F’, idade:’28’})
No exemplo citado, Márcio e Juliana são os vértices, Usuário é o label e

nome, sexo e idade são os atributos com as propriedades.
Agora, observe a criação do relacionamento (ao digitar a sintaxe a seguir,
coloque tudo na mesma linha):
match (Marcio:Ùsuário`), (Juliana:Ùsuário`)

WHERE Marcio.nome=”’Marcio”AND Juliana.nome=”Juliana”
CREATE (Marcio)-[f:AMIGOS_COM]->(Juliana) return Marcio, f, Juliana
Agora, observe a resposta que o Neo4j dará:
M AMIGOS_COM F
USUÁRIO <id>: 8 idade: 28 nome: Juliana sexo: F

Figura 7. Relacionamento entre Márcio e Juliana.

Ao deixar o mouse sobre a circunferência da esquerda, aparecerão os da-
dos de Márcio; na da direita, aparecerão os de Juliana.
Agora, vamos supor que criemos mais uma pessoa, chamada Daniela, que
será amiga do Márcio também.
CREATE (Daniela:Usuário {nome:’Daniela’, sexo:’F’, idade:’29’})
Precisamos criar um relacionamento desse novo usuário com o Márcio. Não

esqueça de fazer tudo na mesma linha.
MATCH (Marcio:Ùsuário`), (Daniela:Ùsuário`)

WHERE Marcio.nome=”’Marcio”AND Daniela.nome=”Daniela”
CREATE (Marcio)-[f:AMIGOS_COM]->(Daniela) return Marcio, f, Daniela
Finalmente, podemos pesquisar todos os relacionamentos de Márcio e

mostrá-los na tela. Para tal, digite:
MATCH (Marcio) RETURN Marcio
Figura 8. Amigos de Márcio.
Na Figura 8, Márcio está no meio, pois foi o pesquisado, Daniela está na es-
querda e Juliana, na direita. A letra que aparece no centro das circunferências
representa o sexo de cada pessoa.

Agora, vamos supor que a Juliana tem um irmão chamado Julio. Vamos criar
um vértice para ele.
CREATE (Julio:Usuário {nome:’Julio’, sexo:’M’, idade:’30’})
Bem, se a letra escolhida para amizades foi f, é necessário escolher outra

para a relação fraterna. Escolheu-se g. Observe a sintaxe a seguir (digite tudo
na mesma linha), que mostra a criação da aresta de relacionamento entre Julia-
na e Julio, colocando-os como irmãos:
MATCH (Juliana:Ùsuário`), (Julio:Ùsuário`)

WHERE Juliana.nome=”Juliana”AND Julio.nome=”Julio”
CREATE (Juliana)-[g:IRMAOS]->(Julio) return Juliana, g, Julio
Por fim, digite o código a seguir para mostrar os relacionamentos de Juliana:
match (Juliana) return Juliana
Figura 9. Rede de relacionamentos.

Editando e deletando grafos
Mas, afinal, se as relações não se mantêm as mesmas para a vida toda, os
códigos e programas também precisam da capacidade de mutação. Por esse
motivo, vamos aprender a alterar e deletar um grafo.
Supondo que criamos o seguinte vértice:
create (estante: Livro {nome:’Iniciando em java’, ano:’2019’})
Vamos exibir este nó para descobrir o ID.
match (estante) return estante
Figura 10. Buscando ID.
Agora, vamos supor que queiramos alterar o nome, mudando de “Iniciando

em java” para “Estudando Java”. Para isso, utiliza-se a seguinte sintaxe (digite
tudo na mesma linha):
match (estante:Livro)
where ID(estante)=12
set estante.nome= ‘Estudando Java’
return estante
Nesse caso, o comando set está sendo usado para alterar uma coisa para
outra. Após digitar isso, o nome do vértice será alterado para “Estudando Java”.

Para finalizar, vamos aprender como deletar um vértice. Para tal, utilizare-
mos aquele mesmo que foi alterado, que está com ID = 12 e nome “Estudando
Java”. Segue a sintaxe:
match (estante:Livro) where ID(estante)=12 delete estante
Traduzindo para a linguagem humana, estamos dizendo “procure o ID 12 no

vértice estante e delete”.
BASE x ACID
Atualmente, diversas aplicações, principalmente as que envolvem tecnolo-
gias web e mobile, vêm exigindo cada vez mais agilidade e recursos relacionados
ao tratamento e armazenamento de dados que, infelizmente, os bancos de da-
dos tradicionais não vêm atendendo.
Os SGBDRs (Sistemas Gerenciadores de Banco de Dados Relacionais) estão
bem segmentados no mercado de tecnologia há mais de 40 anos e atendem mui-
to bem às diversas demandas solicitadas pelas aplicações tradicionais de empre-
sas que utilizam sistemas para armazenar dados relacionados a seus clientes,
produtos e serviços. Essas aplicações permitem que diversos usuários consul-
tem dados e ofertam garantias de confiabilidade nas operações executadas com
uma única unidade lógica de trabalho. Essas transações podem ocorrer de forma
concorrente, sem que se possa gerar dúvidas de sua integridade. Para realizar
esse trabalho, os bancos de dados relacionais devem possuir algumas caracte-
rísticas que são comumente conhecidas como ACID (Atomicidade, Consistência,
Integridade e Durabilidade).
ACID
A sigla ACID, conceitualmente, refere-se a quatro pro-
priedades distintas:
Atomicidade: em uma operação envolvendo duas
ou mais partes de informações diferentes, ou a transação
será executada totalmente ou não será executada, oferecen-
do, assim, garantias que elas sejam totalmente atômicas.

Consistência: a transação gera um novo estado válido dos dados se a opera-
ção for efetuada com sucesso; caso contrário, deve-se retornar todos os dados
utilizados para seu estado inicial.
Isolamento: uma atividade em andamento, porém ainda não validada, deve
permanecer isolada de qualquer outra, garantindo que a transação não sofrerá
interferência das atividades paralelas.
Durabilidade: todos os dados validados dentro do banco de dados são regis-
trados pelo sistema de tal maneira que, mesmo na ocorrência de uma falha e/ou
reinício do sistema, sempre estarão disponíveis em seu estado correto.
As particularidades do ACID nas operações no banco de dados permitem que
você escreva aplicações sem se preocupar com o ambiente complexo em que a
aplicação é executada. Deve-se concentrar-se na lógica da aplicação, e não na de-
tecção de falhas.
Os bancos de dados classificados como NoSQL não se enquadram totalmente
no padrão ACID, pois utilizam as propriedades BASE (Basically Available, Soft-Sta-
te, Eventually Consistent), as quais não efetuam a consistência dos dados a cada
transação por questão de eficácia e eficiência. A responsabilidade de assegurar a
consistência é transferida para a aplicação.
Diversos aplicativos desenvolvidos para web e mobile alcançaram sucesso na úl-
tima década. Isso desencadeou um desenvolvimento maciço de apps para usuários
finais ou até mesmo para desenvolvedores de aplicativos, no caso, serviços. Com
essa ampla adoção de criação de aplicativos e plataformas de desenvolvimento,
ocorreu um crescimento transacional, gerando uma dependência de persistência,
no qual o armazenamento de dados provavelmente se tornará um gargalo.
Para solucionar esse impasse, existem duas estratégias para escalar qualquer
aplicativo. A primeira e a mais fácil é adotar o dimensionamento vertical. Essa so-
lução oferece a possibilidade de mover o aplicativo para computadores maiores e
mais potentes. O dimensionamento vertical funciona razoavelmente bem para os
dados, porém possui diversas limitações técnicas. A mais latente delas é o aumen-
to da capacidade do sistema. Infelizmente, o dimensionamento vertical revelou-se
extremamente caro, pois a adição de capacidade transacional geralmente requer
a compra de um sistema maior. Normalmente, um dimensionamento vertical cria
um bloqueio de fornecedor, pela troca constante de provedor, aumentando ainda
mais os custos.

A segunda estratégia é a escala horizontal, que oferece mais flexibilidade, po-
rém é consideravelmente mais complexa. O escalonamento horizontal de dados
pode ser realizado ao longo de dois vetores, enquanto o funcional envolve o agru-
pamento de dados por função e a disseminação de grupos funcionais em bancos
de dados. A divisão de dados em áreas funcionais de vários bancos de dados, ou
sharding, adiciona uma segunda dimensão ao dimensionamento horizontal.
Particionamento funcional
O particionamento funcional é
uma técnica muito importante para
garantir altos graus de escalabilida-
de. Uma boa arquitetura de banco de
dados irá decompor o esquema em
tabelas agrupadas por funcionalida-
de. Uma tabela contendo dados sobre
usuários, produtos, transações e comunicação são excelentes exemplos de
áreas funcionais. Aproveita-se os conceitos de banco de dados, como chaves
estrangeiras, e é uma abordagem muito comum para manter a consistência em
todas essas áreas funcionais.
Confiar nas ferramentas de restrições dos bancos de dados para garantir a
consistência entre os grupos funcionais cria uma junção do esquema a uma es-
tratégia de implantação do banco de dados. Para que as restrições sejam apli-
cadas, as tabelas devem ser armazenadas em um único servidor, impedindo
o escalonamento horizontal à medida que as taxas de transação aumentam.
Em diversos casos, a oportunidade de scale-out mais eficiente é mover grupos
funcionais de dados para servidores de bancos de dados diferentes.
Teorema CAP
O teorema CAP dita que, nos sistemas distribuídos, existe uma relação de
dependência entre consistência, disponibilidade e tolerância à partição. Ele
vem sendo, desde o começo do milênio, referência para os estudiosos do meio
acadêmico. São três os pontos que o sustentam:

1. Consistência (Consistency)
Inserido no contexto do teorema CAP, a consistência está associada à ato-
micidade e ao isolamento. De uma forma muito simples, isso implica que todos
os processos executados de forma concorrente dentro de um banco de dados
visualizam a mesma versão dos dados.
2. Disponibilidade (Availability)
Este ponto garante que o sistema esteja disponível quando é solicitado. No
ambiente de um servidor web, isso significa que cada pedido enviado eventual-
mente receberá uma resposta.
CURIOSIDADE
Segundo o teorema CAP, a possibilidade de uma resposta não ser em tem-
po real pode representar um problema (GILBERT; LYNCH, 2012, p. 55).
3. Tolerância a partição (Partition

tolerance)
Este ponto implica que o sistema
seja capaz de funcionar corretamen-
te, mesmo apresentando uma falha
em algum dos seus componentes. A
comunicação entre servidores web
não apresenta uma taxa de 100% de
confiabilidade. Caso haja alguma falha
de comunicação entre os servidores,
diversas máquinas podem ficar parti-
cionadas em grupos isolados, não sincronizando dados entre si.
DICA
O teorema CAP demostra que qualquer sistema que suporte bases de
dados distribuídas, apenas consegue, em qualquer momento, res-
ponder a dois desses pontos simultaneamente. Qualquer medida de
escalonamento horizontal é baseada no particionamento de dados;
portanto, os designers de banco de dados são obrigados a decidir
entre consistência e disponibilidade. Não resta outra opção (pelo
menos por enquanto).

BASE x ACID: elementos diferenciadores
O termo BASE foi desenvolvido e patenteado pelos alunos e seguidores de
Eric Brewer, na sequência da apresentação do teorema CAP. Como a própria
sigla sugere, a origem da mesma deve-se à vontade dos seus desenvolvedores
de salientar que as características BASE (“base”) são essencialmente opostas
às propriedades ACID (“ácido”). Contrariamente do que o jogo de palavras pos-
sa parecer, a principal diferença entre essas duas siglas não se encontra na es-
cala de Ph das suas definições etimológicas, mais sim na gama de consistência
que os sistemas gerenciadores de banco de dados devem oferecer. Os sistemas
NoSQL são amplamente fundamentados nas propriedades BASE.
Ao contrário dos sistemas ACID, que, por essência, são focados na consis-
tência, os sistemas BASE são focados na particularidade e na disponibilidade.
As propriedades BASE estão intrinsecamente associadas aos sistemas NoSQL:
[...] porque as principais metas dessas propriedades é garantir
que os novos dados que são gerados cheguem e sejam arma-
zenados imediatamente, mesmo que isso resulte em um risco
de o sistema ficar dessincronizado por um pequeno período de
tempo, gerando delays (MCCREARY, 2014, p. 27).
Esses sistemas flexibilizam as regras com a finalidade de que querys sejam
executadas, mesmo que nem todas as partes da base de dados em uso se en-
contrem devidamente sincronizadas. Os sistemas BASE são, normalmente,
mais velozes e apresentam uma estrutura muito simplificada; não é preciso
escrever o código relativo a desbloqueios e bloqueios de recursos. O principal
objetivo a ser alcançado com esses requisitos é manter todos os processos em
movimento e tratar das partes incompletas.
Destrinchando a sigla BASE, obtemos:
• Basicamente disponível (Basically available): o sistema garante a dispo-
nibilidade dos dados de acordo com as particularidades do teorema CAP. Em
contrapartida, a resposta obtida pode ser uma falha ou inconsistência, caso os
dados requeridos encontrem-se díspares ou num estado de mudança;
• Estado flexível (Soft state): significa que os dados armazenados podem
estar incorretos ou até mesmo imprecisos durante um determinado período
de tempo, e que podem apresentar mudanças significativas enquanto estão

sendo utilizados. Mesmo após grandes períodos de tempo sem alteração
ou novas adições de dados, não se garante a total consistência deles. Re-
sumindo, a consistência dos dados não pode ser atestada;
• Eventual consistência (Eventual consistency): conceitualmente, signi-
fica que o sistema irá, ocasionalmente, tornar-se consistente, uma vez que
cheguem ao fim todas as adições de dados a qualquer base de dados do
sistema. A eventual consistência é um dos padrões utilizados no âmbito da
programação paralela. Este paradigma indica que, após um longo período
de tempo sem modificações, todas as atualizações efetuadas sobre os da-
dos de um nó do sistema irão ser propagadas a todos os outros pontos dele
e todas as copias da base de dados irão atingir um estado de consistência.
O sistema de banco de dados NoSQL também apresenta, como caracte-
rística perceptível, ser altamente gerenciável, levando a níveis de escalabi-
lidade que não poderiam ser atingidos com sistemas ACID.
A disponibilidade do BASE é um processo que pode ser obtido por meio
do suporte a falhas parciais sem falha total do sistema. Poderemos explo-
rar um exemplo simples: caso os usuários sejam particionados em cinco
servidores de banco de dados, o design do BASE incentivará as operações
de criação de forma que uma falha no banco de dados do usuário afete
apenas 20% deles, ou seja 1/5, desse host. Não há truques envolvidos,
mas isso leva a uma maior disponibilidade do sistema. Consecutivamente,
teremos um custo muito alto com a disponibilização de mais servidores
para suplantar a necessidade do sistema na
atual configuração.
O BASE pode ser uma alternativa efi-
ciente quando queremos disponibilida-
de de um sistema de banco de dados. Em-
bora, inicialmente, isso seja bastante difícil
de lidar, haja vista que ele muda totalmente a ideia e
o conceito dos SGBDs relacionais, esse novo
modelo está sendo muito bem explora-
do, utilizado e melhorados, pois uma das
suas principais aplicações é na utilização
de banco de dados não relacionais NoSQL.

Escalar sistemas para uma utilização com taxas de transação tão volumo-
sas pede por uma nova maneira de refletir sobre o gerenciamento de recursos
em banco de dados. Os modelos transacionais tradicionais acabam tornando-
-se ineficientes quando as cargas precisam ser distribuídas em um grande
número de componentes. Desacoplar as transações e executá-las, por sua
vez, oferece maior disponibilidade e escala com o custo da consistência. BASE
fornece um modelo para ponderar sobre esse desacoplamento.
Bancos de dados orientado a colunas

A quantidade de dados que são gerados diariamente nos dias atuais é
enorme, se compararmos com a quantidade gerada de alguns poucos anos
atrás; e é fato que, a cada dia mais, eles são necessários para as organiza-
ções, no que tange à tomada de decisão. Isso implica que, com o elevado
número de dados gerados diariamente, surge a necessidade de criarmos
tecnologias capazes de nos ajudar na tarefa de armazená-los de forma
mais ágil. Com isso, surgem os bancos de dados não relacionais.
Os bancos de dados relacionais (BDRs) foram, por muitos anos, utiliza-
dos como as principais ferramentas para armazenamento de dados. Mas
com a explosão do número de dados gerados a partir do advento da web
em meados dos anos 1990, os bancos de dados não relacionais começa-
ram a ser tidos como alternativas para armazenar grandes quantidades de
dados que não se limitam a apenas textos e números. Isso não quer dizer
que os bancos de dados relacionais deixaram de ser utilizados, pois exis-
tem ambientes em que suas características são essenciais, principalmente
quando necessitam da garantia das propriedades ACID.
Vamos falar aqui dos bancos de dados não relacionais VIDEOAULA
Clique aqui
orientados a colunas. Esse modelo é considerado mais com-
plexo que o modelo orientado a chave-valor. O armazenamento
é realizado por meio de tabelas e os dados são agrupados em colunas. Des-
sa forma, faz com que o tempo de leitura e escrita em disco seja reduzido.
A diferença entre o modelo relacional SQL e o não relacional orientado
a colunas é que o relacional agrupa dos dados por linhas em tabelas, en-
quanto o de colunas agrupa-os em colunas, conforme a Tabela 1.

TABELA 1. DIFERENÇA DE LEITURA ENTRE BANCO DE DADOS SQL E EM COLUNAS
Relacional Não relacional – orientado a colunas
Ana Caroline 20 Cuiabá Ana Bruno Pedro Vanessa
Bruno Henrique 23 Primavera Caroline Henrique Lourenço Lourenço
Pedro Lourenço 01 São Paulo 20 23 01 27
São
Vanessa Lourenço 27 São Paulo Cuiabá Primavera São Paulo
Paulo
O banco de dados orientado a colunas é um modelo de dados não rela-

cional que teve início com o desenvolvimento do Big Table, projetado em
2004 pela Google. O Big Table foi desenvolvido com o objetivo de tentar
solucionar os problemas críticos da Big Data, fator que influenciou o de-
senvolvimento de posteriores bancos de dados NoSQL, tais como Neo4j,
MongoDB, Redis, HBase e Cassandra, além da criação de um ecossistema
de ferramentas de Big Data construídas em torno deles.
O modelo Cassandra, por ser um dos bancos de dados mais populares,
será melhor embasado e destrinchado no desenvolvimento deste estudo.
Banco de dados orientado a colunas: teoria sobre o

Big Table e o Hbase
A Big Table consiste, basicamente, em uma tabela que detém diversos
conjuntos de colunas, de modo que, em cada um deles, existam colunas
nas quais estão contidas propriedades. Além disso, a mesma pode ser vi-
sualizada como um sistema de armazenamento distribuído, que gerencia
petabytes de dados em milhares de servidores comuns. Dessa forma, o
Big Table pode ser visualizado como um mapa ordenado multidimensional
que permite a divisão de dados e forte consistência, sendo o mesmo di-
vidido por famílias. Observe o Diagrama 2, que demonstra essa definição
de dados.

DIAGRAMA 2. FAMÍLIAS DE CATEGORIAS
Julio Nome.nome
Soares Nome.sobrenome
67 kg Medidas.peso
VIDEOAULA
Clique aqui
1,68 Medidas.altura
O Big Table possui três itens importantes:

Linhas: as linhas, no Big Table, são conhecidas como tablets e possuem a
tendência de serem armazenadas no mesmo servidor, com o intuito de au-
mentar o desempenho geral e a distribuição de carga. Em suas implementa-
ções, por meio de um aplicativo interno (Chubby), um servidor-mestre auxilia
na gerência do local dos tablets em um cluster de outros servidores. Além
disso, o aplicativo também controla o bloqueio e a replicação de dados.
Colunas: no que tange o modelo colunar no Big Table, de modo geral,
os dados que estão contidos em um agrupamento de colunas compartilham
do mesmo tipo de dados. Dessa forma, a metodologia aplicada pelo Google,
por exemplo, consiste em usar as colunas na implementação do Big Table na
Web Table, com o intuito de promover o armazenamento de todas as âncoras
referentes a uma página da web. O que são ancoras? Âncoras são botões,
que quando clicados, nos levam para baixo ou para cima da página. O design
aplicado possibilita melhores e mais eficientes leitura e gravação em um am-
biente distribuído.
Timestramp: pode ser entendido como um índice de registro de data e
hora, que possibilita a cada célula do sistema conter diversas versões dos
dados indexados pelo tempo. Dessa forma, a Web Table tem a capacidade
de armazenar o tempo em que o Google rastreou um URL específico em seus
registros. Ademais, esses registros são armazenados em ordem decrescente;
portanto, é possível ler a versão mais recente antes das mais antigas.

Nesse contexto, cada valor no mapa é uma matriz ininterrupta de bytes.
Os bancos de dados orientados a colunas são indicados para mídias so-
ciais e problemas que envolvem consultas complexas. Diante disso, uma vez
que eles compreendem um agrupamento de dados, os mesmos podem em-
pregar informações para aprimorar seu comportamento de armazenamento
e acesso. Ainda que um banco de dados de documentos declare uma estrutu-
ra diferente, cada documento ainda é visto como uma única unidade. Dessa
forma, por sua utilidade, o Big Table, desde seu surgimento, é empregado em
mais de 60 aplicativos na plataforma do Google, substituindo os bancos de
dados antigos.
Como citado anteriormente, o HBase também é um banco de dados NoS-
QL orientado a colunas modelado a partir do Big Table. Ele pode ser resumido
como um datastore de Big Data de código aberto, altamente escalável e não
relacional, que, além disso, emprega uma API Java para programação do clien-
te. Ademais, esse modelo apresenta uma fácil interação com o Hadoop, visto
que é distribuído no ecossistema da Apache. Uma vez que existe essa relação,
há um facilitador na busca eficiente de dados dispersos e distribuídos, fator
que aumentou sua popularidade e proporcionou seu uso generalizado.
Além disso, o HBase também pode empregar o MapReduce, ferramenta
que possibilita a distribuição do processamento dos dados, facilitando o pro-
cessamento de diversos terabytes de dados. Dentre os recursos de proces-
samentos distribuídos pelo HBase, estão incluídos o sharding automático e
configurável de tabelas e o suporte a fail over entre servidores.
O HBase possui uma série de implementações, visto que faz parte de uma
comunidade robusta de projetos do Apache. Além do Facebook, LinkedIn
e Spotify, o mesmo também é empregado no site de Bookmarking Social e
StumbleUpon. Devido ao elevado número de instalações Hadoop existente e
seu exponencial crescimento, o HBase tende a ser uma solução de armazena-
mento NoSQL bastante empregada no futuro.
Falando de modelos de banco de dados NoSQL orientados a coluna, co-
mentaremos, a seguir, sobre o método Cassandra, visto que as supercolunas
apresentadas nessa metodologia destacam-se como as melhores dos mode-
los Big Table. Para introduzirmos essa temática, iniciaremos como uma breve
introdução acerca da metodologia em questão.

Banco de dados orientado a colunas: teoria sobre o
Cassandra
O método Cassandra teve seu desenvolvimento iniciado em 2009, pelo
Facebook, com o intuito de servir como um motor de busca para a caixa de
entrada de mensagem. O modelo de distribuição do sistema apresentado
baseia-se no Dynamo, disponibilizado pela Amazon, e além disso funda-
menta-se no Big Table para organizar os dados.
O método Cassandra apresenta um mecanismo de banco de dados que
pode ser sumarizado como descentralizado, rápido, facilmente escalável,
orientado a colunas e otimizado por clusters. As operações realizadas pe-
los clusters (agrupamentos) não apresentam um nó principal; desse modo,
qualquer operação de leitura ou gravação pode ser manipulada por qual-
quer nó existente no agrupamento.
Uma vez que o Cassandra é um banco de dados orientado a colunas, ire-
mos analisar como se estruturam os dados nele. Nessa situação, a unidade
básica de armazenamento empregada é a coluna, e as linhas da mesma
contém dados verticais. Ademais, cada coluna apresenta um par de valor
e nome, sendo que os pares de nome também se comportam como chave.
Dessa forma, cada conjunto de chave-valor pode ser estabelecido como
uma coluna, já um conjunto de colunas associadas a uma chave primária
pode ser visto como algo que compõe uma linha de uma tabela. Portanto,
as linhas não precisam ter as mesmas colunas e as colunas podem ser
adicionadas a qualquer linha, a qualquer momento, não existindo a ne-
cessidade de adicioná-las a outras linhas. Além disso, quando uma coluna
consiste em um mapa de colunas, a mesma pode ser vista como uma su-
percoluna ou um contêiner de colunas.
O timestamp detém a função de promover a expiração dos dados, ar-
mazenar o valor de data e hora, solucionar os conflitos de gravação e lidar
com os dados que se apresentam obsoletos, dentre outras funções. Des-
sa forma, quando os dados contidos nas colunas não necessitarem mais
serem usados, os espaços que antes ocupavam podem ser recuperados
durante uma compactação, fator que pode acelerar alguns tipos de pes-
quisas de dados.

No entanto, o método Cassandra não é muito aplicável em cenários
que apresentam baixa demanda de leitura e escrita, ou quando não exis-
te a possibilidade dessa demanda crescer rapidamente com o passar do
tempo. Também não se mostra muito atrativo em aplicações com banco
de dados analítico, visto que possuem limitações quando não são realiza-
das consultas empregando a chave-primária. Nessas situações, o HBase se
mostra uma melhor opção.
Criação de um banco de dados no Cassandra

A seguir, abordaremos a criação de um banco de dados no Cassandra, que se-
ria feita após realizar a instalação do mesmo. Neste momento, não abordaremos
a parte de instalação por questões de objetividade.
DICA
O programa Datastax possui uma interface bem amigável para
aqueles que desejam introduzir-se ao Cassandra. Existem vídeos na
internet que mostram como baixar o Apache Cassandra e fazer uma
ligação com o programa.
Passo 1. Primeiro, temos que criar um keyspace. Para isso, vamos utilizar o
comando abaixo:
CREATE KEYSPACE IF NOT EXISTS “MEU_KEYSPACE”

WITH REPLICATION = {‘CLASS’: ‘SIMPLESTRATEGY’, ‘REPLICATION_FACTOR’: 1};
Nota: no comando acima, foi criado um keyspace que, comparado ao Post-

gre, MsSql etc., é como se estivéssemos criando nosso banco através do coman-
do create database. Além disso, está sendo especificado como a replicação será
tratada através do parâmetro replication.
Importante lembrar que o parâmetro replication possui duas propriedades:
SimpleStrategy e NetworkTopologyStrategy, sendo que os dois são indicados
através do class. O SimpleStrategy é o método padrão, que indica que o cluster
é composto de um data center e irá criar o número de réplicas de cada partição
das tabelas do keyspace, igual ao valor definido no parâmetro replication_fac-

tor. O método NetworkTopologyStrategy permite definir um fator de replicação
para cada data center que fizer parte do cluster. Quando se utiliza esse método,
o parâmetro replication_factor não é utilizado, sendo obrigatório informar um
conjunto de chaves e valores, em que a chave é igual ao nome do data center e o
valor define a quantidade de réplicas.
Passo 2. Agora que já criamos nosso banco de dados e entendemos o que
cada parâmetro significa, vamos criar nossa primeira tabela por meio do co-
mando a seguir.
CREATE TABLE “MEU_KEYSPACE”.”PESSOA” (

PESSOA_ID UUID,
NOME TEXT,
SOBRENOME TEXT,
TELEFONE TEXT,
PRIMARY KEY(PESSOA_ID)
);
Nota: observe que chave primária é do tipo UUID (Universally Unique Iden-
tifier). Como no modelo relacional, estamos definindo que o valor será único.
Como é possível verificar por meio do código acima, os comandos no Cassandra
(CQL) são muito parecidos com os utilizados no Postgre (SQL).
Passo 3. Com a tabela criada, vamos inserir registros nela.
INSERT INTO
“MEU_KEYSPACE”.”PESSOA” (PESSOA_ID, NOME, SOBRENOME, TELEFONE)
VALUES (UUID(), ‘PEDRO’, ‘LOURENÇO’, ‘3221-2010’);
INSERT INTO
“MEU_KEYSPACE”.”PESSOA” (PESSOA_ID, NOME, SOBRENOME)
VALUES (UUID(), ‘ANA’, ‘VERDELIO’);
INSERT INTO
“MEU_KEYSPACE”.”PESSOA” (PESSOA_ID, NOME, TELEFONE)
VALUES (UUID(), ‘BRUNO’, ‘1234-2121’);
Nota: no Cassandra, as únicas colunas que precisam ser preenchidas são as

que compõem uma chave primária.
Passo 4. Vamos agora consultar os registros inseridos na tabela PESSOA.

SELECT * FROM “MEU_KEYSPACE”.”CONTATOS”;
Após digitar o comando SELECT (o mesmo utilizado no Postgre), temos

o resultado:
PESSOA_ID | NOME | SOBRENOME | TELEFONE

-------------------------------------------------------
7163cdd5a0c3 | Bruno | null | 1234-2121
950d5918ba2e | Pedro | Lourenço | 3221-2010
2deb9b335588 | Ana | Verdelio | null
No modelo relacional, caso necessitássemos acrescentar mais de um en-

dereço ou mais de um telefone de contato para as pessoas incluídas na ta-
bela PESSOA, precisaríamos criar uma tabela nova, para garantir que nosso
banco estivesse normalizado. Implica que, para realizar consultas no banco,
devemos utilizar os famosos JOINs – método muito utilizado nos modelos
relacionais, mas que geram muita lentidão.
Pelo fato dos bancos de dados não relacionais não trabalharem dessa
forma e focarem na disponibilidade dos dados para resolver esse problema,
no Cassandra, nós utilizamos a criação de uma coluna na tabela PESSOA do
tipo COLLECTION, para armazenar mais de um número de telefone para a
pessoa. Para tanto, utilizaremos o comando ALTER, conforme exibido abai-
xo:
ALTER TABLE MEU_KEYSPACE.PESSOA ADD FONE LIST<TEXT>;
ALTER TABLE MEU_KEYSPACE.PESSOA DROP TELEFONE;
Ao executar os comandos acima, estamos criando uma coluna com nome

FONE, e excluindo a coluna telefone da tabela PESSOA.
Agora vamos atualizar a tabela PESSOA e inserir novos números de tele-
fone para a PESSOA com ID 7163CDD5A0C3, que, no nosso caso, é o Bruno.
UPDATE MEU_KEYSPACE.PESSOA
SET FONE = [‘3241-5050’, ‘99996-1234’]
WHERE CONTATO_ID = 7163CDD5A0C3;

Ao realizarmos o SELECT na tabela, novamente utilizando a cláusula
WHERE, temos o seguinte resultado:
SELECT TELEFONE FROM “MEU_KEYSPACE.PESSOA”

WHERE CONTATO_ID = 7163CDD5A0C3;
telefone
----------------------------------
[‘3241-5050’, ‘99996-1234’]

Sintetizando
Nesta unidade, foi possível fazer um mergulho no mundo NoSQL, iniciando
por bancos orientados e grafos, depois abrangendo as diferenças entre ACID
e BASE e, por fim, o concluindo com teorias sobre banco de dados orientado a
colunas.
Em orientação a grafos, foi dito o que são vértices (que equivalem a tabelas),
depois sobre o que são arestas (que equivalem a relacionamentos) e, por fim,
o que são propriedades (que equivalem aos valores da tabela em si). Como
visto, os relacionamentos entre os vértices podem ser de parentesco, amizade,
compra, etc. Tais vértices, unidos aos relacionamentos, compõem o grafo, uma
nova tendência mundial em redes sociais e em sistemas de recomendação. Nis-
to, foi mostrado que o comando CREATE cria vértices, o comando MATCH sele-
ciona, o comando SET altera e o comando WHERE, juntamente com o MATCH,
fazem pesquisas apuradas.
Em ACID x BASE, abordamos as diferenças entre os sistemas e notamos
que, enquanto o primeiro possui mais tolerância e tratamento de erros, o que
permite que menos paradas ocorram, o segundo se mostra mais rígido. En-
quanto o BASE prefere o desempenho, o ACID busca a consistência, o que mui-
tas vezes o deixa pesado e impede o escalonamento propício aos ambientes
NoSQL e Big Data.
Em orientação a colunas, por fim, abordou-se o surgimento do banco de da-
dos Big Table, em 2004, que com suas colunas e supercolunas, é excelente para
aplicações web. Falamos sobre o HBase, que é útil para ligações com programa-
ção de aplicativos e sistemas MapReduce, e por fim, abordamos não só a for-
ma de ser do Cassandra, com suas sumarizações que facilitam a formação de
clusters, como também os comandos para criar, inserir e alterar tabelas nele.
VIDEOAULA
Clique aqui

BERNARDINO, J.; ABRAMOVA, V. NoSQL Databases: MongoDB vs Cassandra.
In: INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND SOFTWARE
ENGINEERING, 35., 2013, Porto, Anais… Porto: ICCSSE, p.10-12, 2013.
CELKO, J. Complete Guide to NoSQL. Burlington: Morgan Kaufmann, 2015.
KOLOMICENKO, V. Analysis and Experimental Comparison of Graph Da-
tabases. Prague: Faculty of Mathematics and Physics, p. 17, 2013.
GILBERT, S.; LYNCH, N. A. Perspectives on the CAP Theorem. Massachus-
setts: MIT, 2012.
GURU99. SQL vs NoSQL: What‘s the Difference? [s.l.]. 2019. Disponível em:
<https://www.guru99.com/sql-vs-nosql.html>. Acesso em: 28 jul. 2019.
KOLOMICENKO, V.; SVOBODA, M.; HOLUBOVÁ, I. Experimental Comparison
of Graph Databases. In: PROCEEDINGS OF INTERNATIONAL CONFERENCE
ON INFORMATION INTEGRATION AND WEB-BASED APPLICATIONS & SERVI-
CES, 15., 2013: Viena. Anais… Viena: ACM, 2013. p. 115-124.
MCCREARY, K. Making Sense of NoSQL: A Guide for Managers and the Rest
of Us. New York: Manning Publications, 2013.
OLIVEIRA, F. R.; CURA, L. M. V. Avaliação do desempenho de gerenciado-
res de bancos de dados multi modelo em aplicações com persistência
poliglota. 2015. Dissertação (mestrado em Ciência da Computação) – pro-
grama de mestrado em Ciência da Computação, FACCAMP, Campo Limpo
Paulista, 2015.
PRITCHETT, D. BASE: an Acid Alternative. Rio de Janeiro: Elsevier, 2014.
OCONNOR, C.; BARAN, E. From Bigtable to HBase and back again – history
and future. In: STRATA HADOOP. 8., 2015, London. Anais… London: Stra-
ta & Beyond, 2015. Disponível em: <https://conferences.oreilly.com/strata/
big-data-conference-uk-2015/public/schedule/detail/42456>. Acesso em: 24
jul. 2019.
TEOREY, T. et al. Projeto e modelagem de banco de dados. 2. ed. São Paulo:
Campus, 2014.
WANG, G.; TANG, J. The NoSQL Principles and Basic Application of Cassandra
Model. 2012. INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE AND
SERVICE SYSTEM, 8., 2012, Nanquin. Anais… Nanquin: ICCSSE, p. 336, 2012.

WILLIAMS, P. The NoSQL Movement – Big Table Databases. [s.l.]. 2012. Dis-
ponível em: <https://www.dataversity.net/the-nosql-movement-big-table-
-databases/>. Acesso em: 23 jul. 2019.

E-Book Completo - Banco de Dados Relacionais e Não Relacionais - DIGITAL PAGES (Versão Digital)

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

E-Book Completo - Banco de Dados Relacionais e Não Relacionais - DIGITAL PAGES (Versão Digital)

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS BANCO DE DADOS

Banco de Dados Relacionais e não Relacionais

GRUPO SER EDUCACIONAL

gente criando o futuro

Capa_COD_BDRENR.indd 1,3 20/09/2019 16:26:57

Diretor-presidente Jânyo Diniz

Diretoria Executiva de Ensino Adriano Azevedo

Diretoria Executiva de Serviços Corporativos Joaldo Diniz

Diretoria de Ensino a Distância Enzo Moreira

Autoria Ana Luiza Cerchiari de Andrade

Projeto Gráfico e Capa DP Content

Análise de Qualidade, Edição de Texto, Design Instrucional,

Edição de Arte, Diagramação, Design Gráfico e Revisão.

© Ser Educacional 2019

Rua Treze de Maio, nº 254, Santo Amaro

Recife-PE – CEP 50100-160

Informamos que é de inteira responsabilidade da autoria a emissão de conceitos.

ou forma sem autorização.

artigo 184 do Código Penal.

Imagens de ícones/capa: © Shutterstock

SER_COD_BDRENR_UNID1.indd 2 20/09/2019 14:10:51

SER_COD_BDRENR_UNID1.indd 3 20/09/2019 14:10:51

Unidade 1 - Concepções que abrangem o mundo do Banco de Dados

Conceitos básicos de um sistema Gerenciador de Banco de Dados ......................... 13

Modelos conceituais e modelos externos....................................................................... 17

O modelo relacional: conceitos......................................................................................... 31

SER_COD_BDRENR_UNID1.indd 4 20/09/2019 14:10:51

Unidade 2 - Operações práticas em MySQL e álgebra relacional

Linguagem de definição de dados de um SGBD – DDL (Data Definition Language)...47

Linguagem de manipulação de dados de um SGBD - DML (Data Manipulation Language) 54

Álgebra relacional e operadores....................................................................................... 60

Linguagem de controle de transações SGBD - TCL (Transaction Control Language)..... 65

SER_COD_BDRENR_UNID1.indd 5 20/09/2019 14:10:51

Unidade 3 - Operações teórico-práticas em NoSQL

Banco de dados orientado a documentos..................................................................... 77

Banco de dados chave-valor.............................................................................................. 89

SER_COD_BDRENR_UNID1.indd 6 20/09/2019 14:10:51

Unidade 4 - Aprofundamento em NoSQL, grafos, colunas e ACID

Banco de dados orientado a grafos: para que serve ..................................................... 100

Banco de dados orientado a grafos: como mexer.................................................... 102

BASE x ACID......................................................................................................................... 113

Banco de dados orientado a colunas.............................................................................. 119

SER_COD_BDRENR_UNID1.indd 7 20/09/2019 14:10:51

SER_COD_BDRENR_UNID1.indd 8 20/09/2019 14:10:51

Esta disciplina tem o objetivo de ensinar a mexer em bancos de dados. Para

BANCO DE DADOS RELACIONAIS E NÃO RELACIONAIS 9

SER_COD_BDRENR_UNID1.indd 9 20/09/2019 14:10:51

A Professora Ana Luiza Cerchiari de

Este material é dedicado a todos aqueles que buscam organização e

BANCO DE DADOS RELACIONAIS E NÃO RELACIONAIS 10

SER_COD_BDRENR_UNID1.indd 10 20/09/2019 14:10:52

SER_COD_BDRENR_UNID1.indd 11 20/09/2019 14:11:07

Conhecer conceitos e utilidades de SGBD;

BANCO DE DADOS RELACIONAIS E NÃO RELACIONAIS 12

SER_COD_BDRENR_UNID1.indd 12 20/09/2019 14:11:07

BANCO DE DADOS RELACIONAIS E NÃO RELACIONAIS 13

SER_COD_BDRENR_UNID1.indd 13 20/09/2019 14:11:21

TABELA 1. EXEMPLO DE REGISTROS DE COLABORADORES COM FÉRIAS NO MÊS

Marcelo Fontes Rua Fito, nº 23 Comercial Operacional 30

Julia Gonzales Rua Expe, nº 37 Financeiro Gerência 20

Márcio França Rua Antunes, nº 22 P&D Analista 30

Fonte: TEOREY et. al, 2014, p. 6. (Adaptado).