Tipos de Bancos de Dados e

Linguagem SQL_
Guilherme Baião S. Silva
2022
SUMÁRIO
Capítulo 1. Fundamentos do Oracle ........................................................................ 5

1.1. Conceitos Iniciais................................................................................................................ 5

1.2. Estrutura do banco de dados Oracle .......................................................................... 6

1.3. Multitenant e Pluggable Database ............................................................................. 9

Capítulo 2. Instalação do Oracle ............................................................................ 12

2.1. Instalação do engine Oracle XE ................................................................................ 12

2.2. Instalação do SQL Developer ..................................................................................... 15

Capítulo 3. Acessando o Oracle com o SQL Developer................................. 18

3.1. Conectando ao banco de dados................................................................................. 18

3.2. Visualizando os objetos do banco de dados ........................................................ 21

3.3. Outras funcionalidades do SQL Developer........................................................... 24

Capítulo 4. Fundamentos do PostgreSQL .......................................................... 27

4.1. Conceitos Iniciais............................................................................................................. 27

4.2. Arquitetura do PostgreSQL ......................................................................................... 28

Capítulo 5. Instalação do PostgresQL ................................................................. 32

5.1. Instalação do PostgreSQL Server e pgAdmin..................................................... 32

5.2. Arquivos de Configurações .......................................................................................... 34

Capítulo 6. Utilizando o pgAdmin .......................................................................... 39

6.1. Inicializando e conectando a pgAdmin ................................................................. 39

6.2. Visualizando objetos do banco de dados .............................................................. 42

Capítulo 7. Introdução aos Bancos de Dados Não Relacionais

(NoSQL0)....................... ....................................................................................................... 47

7.1. Definição e tipos ............................................................................................................... 47

7.2. Bancos de dados relacionais X não-relacionais ................................................. 49

Capítulo 8. Fundamentos do MongoDB .............................................................. 53

2
 8.1. Conceitos iniciais ............................................................................................................. 53

8.2. Bancos de dados, coleções e documentos ........................................................... 54

Capítulo 9. Instalação do MongoDB ..................................................................... 57

9.1. Instalando o MongoDB e MongoDBCompass ..................................................... 57

9.2. Comandos básicos do MongoDB (linha de comando) ..................................... 59

Capítulo 10. Utilizando o MongoDB Compass .................................................. 65

10.1. Conectando ao banco de dados .............................................................................. 65

10.2. Visualizando e editando documentos.................................................................. 66

Referências ......................................................................................................................... 69

3
1
 Capítulo 1. Fundamentos do Oracle
1.1. Conceitos Iniciais
Segundo o ranking do site DB-Engines (https://db-
engines.com/en/ranking), o Oracle é o Sistema Gerenciador de Bancos de
Dados (SGBD) mais utilizado no mundo1. Foi criado em 1977 por Larry
Ellison, Bob Miner e Ed Oates, cofundadores da Oracle Corporation, que
naquela época se chamava Relational Software Inc. (RSI). Em 1979, foi
lançada a primeira versão comercial e, desde então, sua evolução tem sido
constante.

Nas duas últimas décadas, o Oracle vem se destacando graças a

seus recursos orientados para alta disponibilidade e alta performance.
Trata-se de um SGBD reconhecido no mercado por sua eficiência e por seus
atributos voltados para segurança e alto desempenho. Tais características
fazem dele um sistema indicado para aplicações críticas e de grandes
massas de dados.

O Oracle utiliza a linguagem SQL para acesso e manipulação dos

seus dados, e possui uma linguagem própria para programação de
transações e rotinas procedurais, que é a PL/SQL.

Atualmente, as principais versões do Oracle são:

• Express Edition (XE): é a versão gratuita, que pode ser utilizada por
estudantes e profissionais que querem aprender a administrar
bancos de dados Oracle ou mesmo desenvolver aplicações utilizando
esse SGBD. Possui limitações em relação ao número de threads de
CPU utilizadas, tamanho das bases armazenadas, quantidade de

1
Dados acessados em março de 2022.

5
 pluggable databases, dentre outras. Por ser uma versão
“comunidade”, o Oracle XE não possui suporte e a Oracle não libera
patches de atualização para essa versão. Existe apenas um fórum de
discussão disponível no próprio site da Oracle para que seus
usuários possam compartilhar o conhecimento a respeito dessa
versão com base em perguntas e respostas.

• Standard Edition: custo mais baixo e funcionalidades básicas.

Indicada para empresas de pequeno e médio porte.

• Enterprise Edition: versão mais completa do SGBD. Possui diversos

recursos para alto desempenho, alta disponibilidade, escalabilidade
e segurança. Indicada para aplicações críticas ou que envolvem
grandes bases de dados.

O banco de dados Oracle também pode ser contratado para ser

utilizado na nuvem, através do Oracle Cloud Infrastructure (OCI), que é um
conjunto de serviços e recursos que permitem a utilização de um ambiente
com elevados níveis de disponibilidade, desempenho, confiabilidade e
escalabilidade.

Recentemente a Oracle vem incorporando recursos de inteligência

artificial e machine learning para lançar o Oracle Autonomous Database, que
é um banco de dados no qual diversas atividades de gerenciamento do
banco podem ser automatizadas (backups, aplicação de patches,
parametrizações e tunning, por exemplo).

1.2. Estrutura do banco de dados Oracle

No banco de dados Oracle os objetos (tabelas e índices) são
armazenados em unidades lógicas chamadas tablespaces. O agrupamento
dos objetos que possuem relacionamento lógico em um mesmo tablespace
tende a garantir melhor desempenho e facilitar o gerenciamento do banco
de dados. Por exemplo, podemos criar um tablespace para cada sistema (ou

6
para cada módulo do sistema dependendo do seu tamanho) que utiliza o
banco de dados. Quando criamos uma tabela ou um índice, informamos o
tablespace ao qual este objeto deverá pertencer. Ao instalarmos o banco de
dados o Oracle cria o tablespaces “USERS” como padrão.

Cada tablespace, por sua vez, possui um ou mais datafiles, que são
os arquivos físicos que armazenam os dados propriamente ditos. Nos
datafiles, os dados são armazenados em blocos de dados, cujo tamanho é
especificado quando o banco de dados é criado (o valor padrão é 8 Kbytes).

Sob o ponto de vista de espaço lógico, cada tablespace é composta

de segmentos, que são objetos que ocupam espaço em um banco de dados.
Assim, existem diversos tipos de segmentos: de tabelas, de índices, de undo,
de dados temporários, dentre outros. Os segmentos, por sua vez, possuem
extensões, que são blocos contíguos, obtidos ao alocarmos espaço em um
determinado datafile. Ou seja, podemos resumir a estrutura lógica de
armazenamento do Oracle da seguinte forma: o banco contém tablespaces,
que contêm segmentos, que contêm extensões que contêm blocos.
Figura 1 – Estrutura Lógica do Oracle.

Fonte: www.oracle.com/br/technical-resources/articles/tablespaces-concept-
introduction.html.

7
 Além do tablespace USERS já citado, outros tablespaces são criados
quando o banco de dados é instalado:

• SYSTEM: armazena informações internas do banco, como o catálogo

do banco, por exemplo;

• TEMP: armazena dados temporários. Como exemplo podemos citar

os dados de uma consulta SQL que possui a cláusula ORDER BY e o
Oracle utiliza esse espaço para realizar a ordenação do resultado
conforme indicado na consulta;

• UNDO: armazena as alterações a serem desfeitas no caso de uma

transação incompleta ou abortada (rollback). Os dados armazenados
no tablespace UNDO garantem, também, a consistência de leitura,
ou seja, enquanto uma transação não foi finalizada, outros usuários
não visualizam as alterações feitas por ela.

No ponto de vista de estrutura física, além dos datafiles, que são os

arquivos físicos criados no sistema operacional para armazenar os dados das
estruturas lógicas do banco, encontramos no Oracle arquivos de registro de
redo (redo log files) e arquivos de controle (control files). Os arquivos de
registro de redo são utilizados pelo Oracle para registrar todas as alterações
realizadas nos dados do banco, permitindo uma maior proteção contra
falhas. Já o arquivo de controle armazena diversas informações sobre o
banco de dados (nome do banco de dados, localização dos datafiles, número
atual de sequência de log etc.). É este arquivo que garante a consistência e
integridade do banco de dados Oracle durante a sua inicialização e, por isso,
é indispensável para se inicializar e operar o banco.

8
1.3. Multitenant e Pluggable Database
A partir da versão 12c, a Oracle incorporou em seu SGBD o conceito
de arquitetura multitenant, que permite que várias bases de dados sejam
alocadas em um único container (uma única instalação do Oracle). Os
objetivos, neste caso, são: minimizar os investimentos em infraestrutura
(otimizando o uso de recursos de sistema) e simplificar algumas atividades
de administração dos bancos de dados, como a realização de backups e a
aplicação de patches, por exemplo.

Nessa arquitetura são introduzidos os conceitos de pluggable

database (PDB) e container database (CDB). O CDB (também chamado de
root container) armazena os metadados do próprio Oracle. É considerado o
alicerce da arquitetura multitenant. Dentro do CDB é possível plugar
diversos bancos de dados, os PDBs. No CDB ficam os tablespaces system,
temp, undo e os arquivos de controle, redo, archive etc. No CDB é possível,
ainda, definir usuários comuns a todos os PDBs.

Os PDBs, por sua vez, são os bancos onde são armazenados os dados
e metadados das aplicações propriamente ditos. Eles podem ser "plugados"
ou "desplugados" do CDB conforme necessidade.

Nessa arquitetura existe, ainda, o conceito de seed container, que é

um template para a criação de novos PDBs.

É importante ressaltar que antes da arquitetura multitenant, se

quiséssemos ter dois esquemas com mesmo nome, era necessário termos
dois servidores Oracle. No multitenant é possível ter esses esquemas em
PDBs distintos, mas em um mesmo CDB. Isso passou a permitir, por
exemplo, alocarmos bancos de dados de homologação e desenvolvimento
em uma mesma instalação do Oracle, com um bom nível de independência.

Apesar do conceito de arquitetura multitenant ter sido introduzido

a partir da versão 12c, ela não é obrigatória, podendo-se optar, também, pelo

9
modelo tradicional (Non-CDB) ou single tenant (permite apenas um PDB), já
que o modelo multitenant só está disponível na versão enterprise e tem um
custo mais elevado de licenciamento.

Esse conceito de arquitetura multitenant é fundamental para

usuários que pretendem utilizar o Oracle Cloud Infraestructure (OCI).

Figura 2 – Arquitetura Multitenant.

Fonte: www.oracle.com/br/technical-resources/articles/database-
performance/database-multitenant-oracle-12cr1.html.

10
2
Capítulo 2. Instalação do Oracle
2.1. Instalação do engine Oracle XE
A seguir, veremos os passos para instalação do Oracle Express
Edition 21c (gratuito) no sistema operacional Windows.

O primeiro passo é acessar a página de downloads dos bancos de

dados no site oficial da Oracle:
https://www.oracle.com/database/technologies/xe-downloads.html. Se
preferir navegar pelo site a partir do endereço principal (www.oracle.com),
você deverá clicar no menu “Products”, depois na seção “Hardware e
Software” clicar em “Oracle Database”, em seguida, na nova página, clicar
em “Download Oracle Database 19c”. Na página de downloads que será
exibida, rolar a tela para baixo até aparecer o link para "Oracle Database
Express Edition".

Iremos escolher para o download a versão 21c para Windows 64 bits,

conforme imagem da tela abaixo:

Figura 3 – Download do Oracle Express Edition.

O arquivo que será baixado tem o tamanho aproximado de 1,8 GB.

Trata-se de um arquivo compactado em formato .ZIP e, por isso, após

12
finalizado o download, é preciso extrai-lo para uma pasta do computador.
Após a extração, para dar início à instalação, execute o arquivo “setup.exe”
que fica na primeira subpasta da pasta onde foi realizada a extração.

Na primeira tela do instalador aparece a mensagem "Preparando

para instalar". Neste momento o programa está verificando se seu
computador atende todos os pré-requisitos para a instalação. Aguarde até
que apareça a tela de boas-vindas. Assim que ela aparecer, basta clicar em
"Avançar". Na tela seguinte, basta selecionar o aceite dos termos de
licenciamento e clicar novamente em “Avançar”. Na próxima tela é possível
selecionar o diretório onde o Oracle será instalado. Após selecioná-lo, basta
clicar em "Avançar".

Será exibida, então, uma tela onde será necessário informar uma
senha para os usuários administradores do banco. É importante ficar atento
a essa senha, pois ela é essencial para o acesso e utilização posterior do
banco de dados.

Na tela seguinte o instalador exibirá um resumo informando a pasta

onde o programa será instalado, a pasta configurada como "Oracle Home" e
a pasta configurada como "Oracle Base". Ao clicar em instalar, a instalação
será iniciada. O tempo de instalação pode variar. Em média, esse tempo
costuma ser de 30 minutos.

Ao final da instalação será exibida uma tela informando que a

instalação foi concluída. Nessa tela são exibidas algumas informações
importantes para acesso ao banco de dados. São elas: (a) banco de dados do
container multitenant, (b) nome do banco de dados plugável criado durante
a instalação e (c) a URL para acesso ao banco através do Enterprise Manager.
É aconselhável o armazenamento dessas informações para posterior acesso
e utilização. Abaixo estão as informações que costumam ser exibidas:

Banco de dados container multitenant: localhost:1521

Banco de dados plugável: localhost:1521/XEPDB1

13
URL do EM Express: http://localhost:5500/em

Ao clicar em "Finalizar" a instalação será encerrada. Caso ocorra

algum erro durante a instalação, na tela final estará uma mensagem
informando que a “Instalação foi concluída com erros”. Nesse caso é
importante consultar os arquivos de log da instalação para tentar identificar
a causa do erro, pois o Oracle não terá sido instalado. Os arquivos com log
da instalação ficam dentro do diretório do ORACLE HOME, subpasta
cfgtoollogs\oui. Lá haverá uma pasta com a data e hora de cada tentativa de
instalação e arquivos de log dentro dela.

Finalizada a instalação, é possível conferir se o servidor do banco de

dados está sendo executado através do gerenciador de serviços do
Windows. O Oracle instala vários serviços, dentre os quais os principais são:
OracleServiceXE e o OracleOraDB21HomeTNSListener (o listener em
bancos Oracle é o processo responsável pelo tratamento de requisições de
conexão de clientes remotos).

Pode-se utilizar o cliente SQL Plus (instalado por padrão juntamente

com o engine do banco) para realizar uma primeira conexão e verificar se o
banco de dados está disponível para utilização. Para isso, basta executar o
arquivo “sqlplus.exe” que fica na pasta "bin", dentro do diretório do ORACLE
HOME. Será solicitado usuário e senha para conexão. No usuário, digite "sys
as sysdba" e na senha informe a mesma senha que foi criada durante
instalação. Se a conexão estiver ok, serão exibidos dados da versão do banco
e um prompt para digitação de comandos SQL.

Você pode exibir, por exemplo, os PDBs que estão disponíveis,

utilizando o comando "show pdbs" (observe que existe um PDB$SEED que é
somente leitura; este PDB é criado como padrão e serve como uma espécie
de template para criação de novos PDBs em ambientes Oracle multitenant).
O outro PDB é o banco de dados propriamente dito, que foi criado na
instalação para ser usado por outros usuários e aplicações.

14
 Um outro comando simples que pode ser testado no SQL Plus é o
comando para exibição da data e hora atuais:

> select to_char(sysdate, 'dd/mm/yyyy hh:mi:ss') from dual;

Pelo SQL Plus podemos, ainda, parar e iniciar novamente o servidor

do banco de dados com os dois comandos abaixo, respectivamente.

SQL> shutdown immediate

SQL> startup

Após iniciar o banco é necessário abrir os bancos de dados plugáveis

que estiverem disponíveis. Para isso, basta utilizar o comando abaixo:

SQL> ALTER PLUGGABLE DATABASE ALL OPEN;

Para sair do SQL PLus, é só digitar "exit".

Por fim, podemos testar o acesso ao banco através do Enterprise

Manager (EM). Para isso, utiliza-se a URL que foi informada na tela final da
instalação. Na tela inicial do EM será necessário informar usuário e senha.
Pode-se utilizar tanto o usuário “sys” quanto o usuário “system”, ambos com
a senha que foi definida durante a instalação do Oracle. Também haverá
nessa tela um campo para que seja informado o nome do container.
Podemos deixar em branco para que a conexão seja estabelecida com o CDB
(root container).

Ao abrir o EM, serão exibidas informações sobre o status do banco.

O Enterprise Manager é muito útil para acompanhar performance do banco
e gerenciamento de recursos (armazenamento, uso de cpu, memória etc.).

2.2. Instalação do SQL Developer

Após instalado o banco de dados Oracle, podemos instalar o SQL
Developer para acessá-lo e manipulá-lo. O download do SQL Developer pode
ser realizado na seguinte URL:
https://www.oracle.com/tools/downloads/sqldev-downloads.html.

15
 O primeiro passo é selecionar a versão. Aqui utilizaremos a versão
para Windows 64bit com JDK 8 incluso. O arquivo para download tem cerca
de 430 MB. Ao clicar no link da versão escolhida, será necessário dar o aceite
nos termos de licenciamento.

Em seguida, para continuar o download, a Oracle exige que seja feito

login em uma conta Oracle. Essa conta é gratuita e, caso você não possua,
poderá criar em poucos passos: (a) no final da tela de login na conta Oracle,
clicar em “Criar conta”; (b) preencher o formulário de cadastro com os dados
pessoais, profissionais, endereço e uma senha para acesso; (c) após enviar
os dados, acessar o e-mail informado no primeiro campo do formulário e
abrir a mensagem enviada pela Oracle para validação da conta; (d) ao abrir o
e-mail, clicar em “Confirmar endereço de e-mail”. Você será direcionado a
uma tela informando que a conta foi atualizada e está pronta para ser
utilizada.

Volte à tela de download inicial do SQL Developer e faça login na

conta que acabou de criar. Agora será possível baixar o arquivo.

O SQL Developer não precisa ser instalado. Basta descompactar o

arquivo .zip que acabou de ser baixado em uma pasta qualquer à sua escolha
e, em seguida, utilizar o executável sqldeveloper.exe (na pasta raiz onde
você descompactou o zip) para iniciar a execução da ferramenta.

Ao abrir o SQL Developer pela primeira vez é exibida uma tela

solicitando sua autorização para rastreamento de uso pela Oracle. Essa
opção pode ser desmarcada e, logo em seguida, clicar no botão “Ok”. A partir
daí o SQL Developer estará pronto para uso. O primeiro passo é configurar a
conexão com o banco de dados, conforme veremos nos tópicos a seguir.

16
3
Capítulo 3. Acessando o Oracle com o SQL Developer
3.1. Conectando ao banco de dados
O primeiro passo para a utilização do SQL Developer é a criação de
uma nova conexão com o banco de dados. No SQL Developer é possível
definir uma conexão com o banco de diferentes formas, sendo que as mais
utilizadas são: (a) o modo básico, (b) utilizando um arquivo de TNSNames e
(c) utilizando strings JDBC. No modo básico é necessário informar o nome
do host, a porta e o SID ou nome do serviço. Já no TNSNames basta informar
o nome da conexão que está cadastrado no arquivo tnsnames.ora e neste
arquivo estarão todas as características da conexão. Inicialmente criaremos
uma conexão utilizando o modo básico e depois faremos utilizando um
arquivo tnsnames.

Para uma nova conexão, basta clicar no sinal “+” verde que aparece
no canto superior esquerdo da tela, conforme mostrado na imagem abaixo.

Figura 4 – Criando uma conexão no SQL Developer.

O SQL Developer irá exibir um formulário para que sejam informados

os dados da nova conexão. O primeiro dado a ser preenchido é o nome da
conexão. Nesse caso é indicado escolhermos um nome que identifique com

18
 facilidade o banco no qual estamos conectando e o usuário que iremos
utilizar nesta conexão. Podemos utilizar, por exemplo, o nome “LOCAL_SYS”.
No tipo de autenticação manteremos o valor “Padrão”, no nome do usuário
informaremos o usuário “sys”, na atribuição (que fica logo na frente do nome
do usuário) selecionaremos a opção “SYSDBA” e na senha informaremos a
senha que foi informada durante a instalação do Oracle. No nome do host
manteremos o “localhost”, uma vez que estamos executando o SQL
Developer no mesmo computador em que o banco de dados foi instalado, na
porta manteremos o valor “1521” que é o valor padrão do Oracle, e no SID,
que é o nome identificador da instância, informaremos “xe”. 2 Após fornecer
esses valores, você pode clicar no botão testar para ver se a conexão será
estabelecida com sucesso. Em caso afirmativo, podemos salvá-la e ela
passará a ser exibida no canto esquerdo da tela, na lista de “Oracle
Conexões”.

Para utilizar essa conexão, basta dar um duplo clique sobre ela (ou
clicar com o botão direito e selecionar a opção “conectar”) e, em seguida,
informar novamente a senha do usuário que foi informado na configuração
da conexão. Ao conectar, será exibida no canto esquerdo a árvore de objetos
pertencentes ao esquema do usuário que estamos utilizando para conexão
(por enquanto, estamos utilizando “sys”).

Para criar uma conexão utilizando o arquivo tnsnames, primeiro

iremos criar este arquivo. Abra um novo arquivo no bloco de notas e insira
os dados abaixo. Observe que estamos definindo os dados de uma conexão

2
Para conferir o SID de uma instalação Oracle, você pode se conectar com o usuário SYS via
SQL Plus e digitar a seguinte consulta: select instance_name from v$instance ;

19
 que chamamos de “BDLOCAL”, utilizando service name ao invés de SID3. Em
seguida, salve esse arquivo com o nome de “tnsnames.ora” na subpasta
“network/admin” que fica dentro do diretório ORACLE HOME (esse é sempre
o caminho padrão do tnsnames.ora).

BDLOCAL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = XE)
)
)

Antes de criarmos a nova conexão, vamos carregar esse novo arquivo

tnsnames no SQL Developer. Para isso, basta selecionar a opção “Carregar
um arquivo TNS” na tela inicial do SQL Developer, conforme imagem abaixo,
e selecionar o arquivo tnsnames.ora que acabamos de criar.

Figura 5 – Carregando um arquivo TNS no SQL Developer.

Agora selecionaremos novamente o botão “+” para criar uma nova

conexão. Assim como na primeira, informaremos um nome para essa
conexão (podemos colocar “LOCAL_SYS_TNS”, por exemplo), informaremos

3
Para conferir os services names disponíveis em uma instalação, você pode se conectar com
o usuário SYS via SQL Plus e digitar a seguinte consulta: select value from v$parameter where
name like '%service_name%'.

20
 novamente o tipo de autenticação “Padrão”, o usuário “sys” com atribuição
“SYSDBA” e sua respectiva senha. No tipo de conexão selecionaremos a
opção “TNS” e no aliás da rede selecionaremos o nome que demos à conexão
que configuramos no arquivo tnsnames.ora (BDLOCAL). Por fim, podemos
testar a conexão criada e, em seguida, salvá-la.

3.2. Visualizando os objetos do banco de dados

Ao conectar ao banco de dados no SQL Developer, o canto esquerdo
da tela passa a exibir os objetos (tabelas, views, procedimentos, tipos,
sequências etc.) armazenados no esquema do usuário que está sendo
utilizado para a conexão. Como essa primeira conexão foi realizada com o
usuário administrador do sistema (“sys”), não faremos alterações nesses
objetos. Nos passos a seguir, criaremos um novo usuário no banco e,
automaticamente, é criado um esquema com o mesmo nome do usuário para
armazenar os objetos criados por ele. Utilizaremos este novo usuário e seu
esquema para testar a criação e visualização dos objetos.

Para criar um novo usuário, executaremos os comandos abaixo na

seção da tela destinada à execução de comandos SQL (ainda logados com o
usuário “sys”).

ALTER SESSION SET CONTAINER = "XEPDB1";

CREATE USER igti IDENTIFIED BY igti2022 DEFAULT TABLESPACE "USERS" TEMPORARY
TABLESPACE "TEMP" ACCOUNT UNLOCK;
GRANT CREATE SESSION TO igti;
GRANT CREATE TABLE TO igti;
ALTER USER igti QUOTA 2M ON "USERS";

Observe que antes de criar o usuário, estamos setando o PDB da

sessão atual para o XEPDB1. Assim, o usuário que iremos criar não terá
acesso ao root container, somente ao XEPDB1. Observe também que
estamos indicando o tablespace padrão deste usuário como “USERS”, ou
seja, sempre que o usuário criar algum objeto sem indicar um tablespace
específico, ele será criado no “USERS”. Também estamos indicando que o
tablespace temporário do usuário será o “TEMP” e que a conta deverá ser
criada já desbloqueada (pronta para uso). Os três últimos comandos

21
 concedem ao novo usuário a permissão para criar novas sessões no banco,
criar novas tabelas e utilizar até 2MB de espaço no tablespace “USERS”,
respectivamente.

A tela abaixo mostra como executar os comandos no SQL Developer:

Figura 6 – Executando comandos SQL no SQL Developer.

Como o usuário foi criado apenas no PDB XEPDB1, antes de criarmos

uma nova conexão para ele no SQL Developer precisaremos criar uma nova
entrada no nosso arquivo tnsnames.ora que seja específica para esse PDB.
Essa nova entrada será semelhante à anterior, modificando apenas o nome
(que precisa ser único para cada conexão) e o service name que deverá ter o
mesmo nome do PDB. Ou seja, o conteúdo do nosso novo tnsnames.ora
passará a ser o seguinte:

BDLOCAL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = XE)
)
)

BDLOCAL_XEPDB1 =

22
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = XEPDB1)
)
)

Agora podemos criar uma nova conexão no SQL Developer utilizando

o usuário “igti” que acabamos de criar, a senha “igti2022” e o tipo de conexão
será “TNS”, selecionando o alias “BDLOCAL_XEPDB1”. Ao conectar com esse
usuário, observe que ele ainda não possui objetos (nenhuma tabela, view
etc.). Faremos a partir de agora a criação de alguns objetos para fins de teste.

Ao executar o comando a seguir, criaremos uma nova tabela

“TBTESTE” no esquema do usuário “igti”.

CREATE TABLE TBTESTE

(
C1 number(8,2) not null primary key,
C2 varchar2(30) not null
);

Após criá-la, atualize a relação de tabelas na árvore de objetos do

canto esquerdo da tela para visualizá-la. Observe que, ao clicar nessa tabela,
uma série de informações a respeito da mesma são exibidas no lado direito
da tela (colunas, dados, restrições, índices, dentre vários outros). Clicando
sobre os índices, você pode visualizar também que foi criado um índice para
a coluna “C1” que é a chave primária da tabela. Podemos, inclusive, inserir
alguns registros nessa nova tabela para visualizarmos esses dados através
do SQL Developer:

INSERT INTO TBTESTE (C1, C2)

VALUES(1, 'primeiro teste');
INSERT INTO TBTESTE (C1, C2)
VALUES(2, 'segundo teste');
COMMIT;

Observe que no banco de dados Oracle, sempre que executamos

algum comando SQL para alterar dados armazenados (comandos DML)
precisamos, em seguida, executar o comando “commit” para confirmar a

23
alteração. Antes da execução do commit, os dados alterados ainda não
estarão gravados em disco e não estarão disponíveis para demais sessões
de usuários do banco. Se o “commit” não for executado, quando a sessão
atual for finalizada, as alterações serão desfeitas automaticamente
(rollback). Após executar os comandos, clique novamente sobre a tabela
para visualizar os dados inseridos através do SQL Developer.

3.3. Outras funcionalidades do SQL Developer

Além de acessar o banco de dados, visualizar os objetos e executar
comandos SQL, o SQL Developer possui uma série de outras funcionalidades
que são úteis, sobretudo, para a administração dos bancos de dados Oracle.

Algumas dessas funcionalidades podem ser acessadas clicando com

o botão direito sobre a conexão com o banco que fica na árvore do lado
esquerdo da tela. Algumas opções que podemos destacar são:

• “Gerenciar banco de dados” que irá exibir algumas informações

sobre o uso da memória e o status atual do armazenamento (cada
um dos tablespaces com seus respectivos tamanhos, espaços
utilizados e disponíveis);

• “Obter estatísticas do esquema” que irá disparar uma procedure

para atualizar as estatísticas de todos os objetos desse esquema.
Essas estatísticas são utilizadas pelo otimizador de consultas para
definir o algoritmo mais eficiente para execução de uma
determinada consulta do usuário.

• “Browser do esquema” exibirá uma outra aba com outra forma de

exibição dos objetos do esquema selecionado.

• “Localizar objetos do BD” que exibe uma seção para facilitar a busca
por um objeto específico no banco com base no seu nome (ou parte
do nome).

24
 No canto inferior esquerdo existe uma seção dedicada a relatórios.
Muitos desses relatórios são úteis para a administração e monitoramento do
banco de dados, como por exemplo: exibição dos datafiles e status de cada
um deles; exibição de bloqueios (locks) no banco de dados, caso existam;
estatísticas de uso da memória do computador pelo Oracle; visualização dos
parâmetros do banco de dados; diversos tipos de relatórios para sessões de
usuários no banco; relatórios relacionados à segurança do banco de dados,
com destaque para relatórios de auditoria e também relatórios de
permissões atuais dos usuários; relatórios de objetos do banco de dados.

Uma outra funcionalidade do SQL Developer que merece ser

comentada é o Data Modeler: ferramenta que pode ser utilizada para auxiliar
no processo de modelagem do banco de dados. O processo de modelagem
define a estrutura das tabelas do banco e as referências entre elas para que
os dados sejam armazenados de forma correta e eficiente. O Data Modeler
ajuda na criação diagramas que irão apresentar as tabelas e os
relacionamentos entre elas, na definição do dicionário de dados etc.

25
4
 Capítulo 4. Fundamentos do PostgreSQL
4.1. Conceitos Iniciais
O PostgreSQL é um SGBD objeto-relacional gratuito (para fins
comerciais ou não) e open source. É considerado uma boa solução para
aplicações que precisam de confiabilidade, desempenho e com baixos
custos de licenciamento.

Segundo ranking do portal DB-Engines4, o PotsgreSQL é o quarto

SGBD mais utilizado no mundo e seguindo uma tendência de alta, desde
2013, quando os dados começaram a ser registrados.

A história do PostgreSQL iniciou-se com o desenvolvimento do

projeto INGRES na Universidade da Califórnia, no final da década de 70 e
início da década de 80. Em 1986, a partir do INGRES, iniciou-se o
desenvolvimento do POSTGRES, que já era a proposta de um banco de dados
objeto-relacional e que foi lançado em 1989. Em 1995, ele passa a ter
suporte a linguagem SQL e recebe o nome de Postgres95. Em 1996, passou
a se chamar PostgreSQL e começou a ser disponibilizado para download na
internet. Nessa época, a versão disponível era a 6.0.

Atualmente o PostgreSQL está na versão 14 e é mantido por uma

comunidade que possui membros ao redor de quase todo o mundo, o
PostgreSQL Global Development Group. Além da manutenção, a
comunidade desenvolve novas funcionalidades e dá suporte ao uso do SGBD
através de fóruns, listas de e-mails e sites colaborativos.

Dentre as aplicações de grande porte e alta criticidade que utilizam

esse SGBD, podemos citar o Processo Judicial Eletrônico (PJE) desenvolvido

4
Dados acessados em março de 2022 – https://db-engines.com/en/ranking

27
pelo Conselho Nacional de Justiça (CNJ) e utilizado em vários tribunais de
justiça estaduais.

Por se tratar de um banco de dados objeto-relacional, os dados são

armazenados em tabelas (como nos bancos relacionais), mas tratados como
objetos com atributos e comportamentos (como na orientação a objetos). O
suporte à linguagem padrão ANSI-SQL para manipulação dos dados
também é mantido. A modelagem, operação e administração do banco de
dados é muito semelhante aos bancos de dados relacionais, mas permite a
definição de colunas cujo tipo é uma classe.

4.2. Arquitetura do PostgreSQL

O PostgreSQL utiliza a arquitetura cliente-servidor. O servidor é
implementado em um processo de nome "postgres" e esse processo é
responsável por gerenciar os arquivos do banco, estabelecer as conexões
dos clientes, criar um novo processo para cada conexão e disparar as ações
solicitadas por esses clientes.

Os clientes serão as aplicações que irão se conectar ao banco para

executar operações. Alguns exemplos de clientes do PostgreSQL são o
"psql" (ferramenta em modo caractere) e o pgAdmin (ferramenta gráfica).

Alguns outros processos executados no servidor postgres são:

• walwriter: gerencia os commits quando o parâmetro

"synchronous_commit" estiver desligado. Neste caso, as alterações
são enviadas primeiro para o sistema operacional e posteriormente
para o log transacional.

• checkpointer: grava em disco as alterações do WAL que ainda não

foram gravadas pelo background writer, com o objetivo de permitir
que o WAL seja reutilizado até aquele ponto. O WAL (Write Ahead
Log) é o log de transações do PostgreSQL.

28
 • background writer: é um processo que move dados modificados da
memória (shared buffer) para o disco em background, reduzindo a
carga do checkpoint.

• autovacuum launcher: processo que detecta automaticamente

objetos sobre os quais é preciso executar o "vacuum" (reciclagem
dos espaços utilizados pelas tabelas e atualização de estatísticas).

• stats collector: coleta estatísticas relevantes para a otimização de

consultas.

• logger: responsável pelo registro de erros e alertas do banco.

Importante não confundir com o registro de logs transacionais que
é feito pelo WAL.

• Logical laucher: processo responsável pela replicação de dados em

ambientes clusterizados.

Os dados de todos os bancos de um servidor PostgreSQL são

armazenados em um único diretório, também chamado de agrupamento de
banco de dados. Esse diretório é definido no momento da instalação.
Também existe uma variável de ambiente chamada PGDATA que armazena
esse caminho. Dentro do PGDATA existe uma subpasta "base" que, por sua
vez, possui um subdiretório para armazenamento dos dados de cada um dos
bancos de dados criados no PostgreSQL. Esses diretórios são identificados
pelo OID (um identificador interno que cada banco de dados recebe no
PostgreSQL).

Além da subpasta "base", algumas outras subpastas e arquivos de

controle também ficam armazenados dentro do agrupamento, dentre os
quais podemos citar: "global" (subpasta que armazena os dados comuns a

29
 todos os bancos), "pg_wal" (subpasta que armazena os arquivos de WAL)5,
PG_VERSION (arquivo que identifica a versão do banco), pg_hba.conf e
postgresql.conf que são arquivos de configuração.

Um cluster do banco de dados PostgreSQL6 pode possuir diversos

bancos de dados. Cada banco de dados, por sua vez, pode possuir vários
esquemas (schemas), que é onde ficam os objetos da aplicação (tabelas,
views, funções, types etc.). As principais vantagens da organização dos
objetos em esquemas são: (a) agrupar em termos lógicos objetos
relacionados, facilitando o gerenciamento deles; (b) possuir mais de um
objeto com mesmo nome dentro do mesmo banco de dados (desde que em
esquemas distintos); (c) permitir uma camada a mais no gerenciamento de
permissões de usuários, pois usuários podem ter permissões relacionadas a
esquemas específicos.

5
Antes da versão 10, a pasta “pg_wal” recebia o nome de “pg_xlog”.
6
Atualmente tratamos uma instalação de um SGBD como um cluster do banco de dados;
mesmo quando estamos trabalhando com um servidor único, é comum referenciá-lo como
cluster.

30
5
Capítulo 5. Instalação do PostgresQL
5.1. Instalação do PostgreSQL Server e pgAdmin
A URL para download do PostgreSQL é
https://www.postgresql.org/download/. Nesta página, o primeiro passo é
escolher o sistema operacional. No nosso caso trabalharemos com o
Windows (há versões disponíveis também para Linux, macOS, BSD e Solaris).

Após escolher o sistema operacional, basta clicar no link “Download

the installer” que aparece logo no início da página. Será exibida uma
observação informando que o instalador é hospedado nos servidores da
Enterprise DB, que é uma das empresas que integram a comunidade
PostgreSQL. Na tela seguinte deve ser selecionada a versão, que no nosso
caso será a mais recente (14.2) para Windows 64 bits, conforme imagem
abaixo:

Figura 7 – Seleção da versão a ser instalada.

Fonte: O próprio autor

O arquivo a ser baixado tem cerca de 290MB. Após finalizado o

download, execute-o para dar início à instalação. A primeira tela do
instalador é apenas uma tela de boas-vindas. Basta clicar em "Next". Na
segunda tela você deverá selecionar o caminho onde o PostgreSQL deverá
ser instalado. O valor padrão sugerido é "C:\Program Files\PostgreSQL\14".

32
 Na tela seguinte você seleciona os componentes a serem instalados.
Para nosso cenário instalaremos o "PostgreSQL Server" que é o “engine” do
banco propriamente dito, o "pgAdmin 4" que é o cliente gráfico que
utilizaremos e "Command Line Tools" que são os utilitários para operação
do banco de dados utilizando linha de comando. A opção "Stack Builder"
deverá ser desmarcada. Trata-se de uma interface gráfica para facilitar a
instalação de módulos complementares do PostgreSQL, tais como
extensões, plugins e drivers.

Após clicar em "Next" novamente, o instalador passará para a

próxima tela onde deveremos informar o diretório padrão em que o
PostgreSQL armazenará os dados (trata-se do PGDATA que foi comentado
na unidade anterior). O valor padrão sugerido pelo instalador é "C:\Program
Files\PostgreSQL\14\data".

Na tela seguinte é necessário definir uma senha para o super usuário

do banco, que no caso do PostgreSQL é chamado de "postgres". Recomenda-
se que a senha seja armazenada em local seguro, pois ela será requisitada
posteriormente para a utilização do banco. Em ambientes de produção,
recomenda-se que sejam utilizadas senhas fortes, por se trata de um super
usuário do banco. Após digitar a senha e confirmá-la, clique em "Next".

A tela seguinte é para seleção da porta que será utilizada para

comunicação com o servidor. O valor padrão é 5432. Após clicar em "Next"
mais uma vez, serão exibidas opções de "locale" para o servidor que estamos
instalando. O "locale" é o conjunto de preferências em relação a símbolos do
alfabeto, formatação de números, moeda, datas e regras de classificação de
caracteres. Sugere-se, no nosso contexto, que seja mantido o valor padrão
("Default locale"). Clique em "Next" novamente.

As duas telas seguintes são para exibição do resumo das opções de

instalação e confirmação, respectivamente. Podemos clicar no botão "Next"
de ambas. Será iniciada a instalação do PostgreSQL. O tempo estimado para

33
instalação é de 5 minutos, mas esse tempo pode variar bastante de acordo
com os recursos disponíveis na máquina em que a instalação está sendo
feita.

Ao final, é exibida uma tela informando que o PostgreSQL foi

instalado. Basta clicar em "Finish" para finalizar o processo de instalação.
Uma das possibilidades para conferência se a instalação realmente foi
finalizada com sucesso é verificar se o pgAdmin 4 está instalado e se na
relação de serviços do Windows aparece o serviço referente ao PostgreSQL
(nome padrão do serviço da versão 14: postgresql-x64-14).

5.2. Arquivos de Configurações

Após a instalação do PostgreSQL, devemos ficar atentos a dois
arquivos de configurações principais:

• pg_hba.conf: neste arquivo indicamos quais usuários podem

acessar o banco e a partir de quais IPs o acesso pode ser realizado.
Em cada linha do arquivo pode ser configurada uma permissão de
acesso, informando os valores para os 5 parâmetros a seguir:

– TYPE: tipo de conexão. Geralmente utiliza-se o valor "local"

se a conexão for realizada em uma rede local, ou "host" nos
casos em que a conexão for realizada pela internet.

– DATABASE: define o banco de dados que poderá ser

acessado. Pode-se utilizar a palavra "all" para que seja
liberado o acesso a todos os bancos.

– USER: usuários que poderão realizar o acesso. Também é

possível utilizar a palavra "all" para que a regra seja aplicada
a todos os usuários do banco.

– ADDRESS: especifica os IPs que poderão realizar o acesso. O

valor 127.0.0.1/32 equivale ao localhost. Pode-se utilizar

34
 máscaras para especificar intervalos de IP que podem
acessar. Exemplo: o número 32, após a barra que aparece
depois do IP, indica que a conexão deve partir daquele IP
exato. Já o valor 24, no lugar do 32, indicaria que qualquer IP
do intervalo 127.0.0.xxxx poderia acessar. O valor 16
indicaria a necessidade de validação somente dos dois
primeiros números do IP (ou seja, qualquer IP que iniciasse
com 127.0.) Esse parâmetro não precisa ser informado se o
"TYPE" for igual a "local".

– METHOD: indica o método de autenticação a ser aplicado na

conexão com o banco. Os valores mais comuns utilizados
neste parâmetro são: "md5" (necessário validar a senha
informada pelo usuário), "trust" (não depende da senha para
a conexão) e "reject" (não permite a conexão com os valores
informados nos demais parâmetros).

A imagem abaixo mostra algumas linhas de exemplo em um arquivo

pg_hba.conf:

Figura 8 – Exemplo de conteúdo do pg_hba.conf.

35
 • postgresql.conf: No arquivo postgresql.conf são definidos todos os
valores de parâmetros referentes ao funcionamento do PostgreSQL.
Cada valor atribuído a um parâmetro deve estar em uma linha,
utilizando-se a sintaxe:

nome_parametro = valor

Os parâmetros desse arquivo se referem, principalmente, a:

localização dos arquivos (arquivos de dados do banco, pg_hba.conf,
pg_ident.conf), conexões e autenticação (número máximo de conexões
simultâneas, tempo de timeout durante a autenticação, dentre outros),
utilização de recursos (tamanho dos buffers, tamanho máximo de arquivos
temporários, por exemplo), configurações do WAL (tipo de WAL, tamanho
máximo etc.), configurações do otimizador de consultas (se são permitidos
hints em consultas SQL, tamanho do cache de consultas, dentre outros),
configurações do log de alertas e erros (nome do arquivo de log, tipos de
erros e alertas a serem registrados etc.), configurações do autovacuum
(habilitado ou não, quantidade máxima de subprocessos que podem ser
utilizados), valores padrão para conexões de clientes (timeout de sessões
"idle in trasaction", timezone e caracter set padrão etc.), além de vários
outros parâmetros que podem ser configurados.

Para visualizar os valores atuais de cada parâmetro, também é

possível utilizar a view "pg_settings" ou o comando "SHOW
<nome_parametro>". Veja os exemplos abaixo:

SHOW log_filename;

select * from pg_settings

where upper(name) like '%TIMEOUT%';

O primeiro comando mostrado acima irá exibir o valor atual do

parâmetro cujo nome é “log_filename”. O segundo irá exibir as informações
de todos os parâmetros que possuem a expressão “timeout” no nome.

36
 A view pg_settings exibe, além do nome e do valor atual do
parâmetro, outras informações úteis, tais como: tipo de dado aceito no valor
do parâmetro, unidade de medida para o caso de parâmetros numéricos,
descrição do parâmetro, dentre outros.

37
6
Capítulo 6. Utilizando o pgAdmin
6.1. Inicializando e conectando a pgAdmin
Antes de utilizarmos o pgAdmin, é necessário garantir que o servidor
do banco de dados PostgreSQL esteja sendo executado. No Windows é
possível conferir, através do gerenciador de serviços do próprio sistema
operacional, se o serviço do PostgreSQL está em execução e utilizar o
gerenciador de tarefas para verificar se os processos do PostgreSQL estão
ativos, conforme imagens abaixo:

Figura 9 – Serviço do PostgreSQL no Windows.

39
 Figura 10 – Processos do PostgreSQL no Windows.

Após iniciado o servidor do banco de dados, podemos abrir o

pgAdmin para acessar e operar o banco. O primeiro passo é configurar uma
nova conexão com o servidor. Ao abrir o pgAdmin, a partir da versão 4, a
primeira tela que aparece é a solicitação de uma senha para utilização do
próprio pgAdmin (não é senha referente ao banco de dados propriamente
dito). Essa senha é utilizada para criptografar as senhas de acesso aos
bancos que podem ser salvas no pgAdmin, portanto, o uso dela é
recomendado caso você queira salvar as senhas das conexões criadas no
pgAdmin. No primeiro acesso você poderá defini-la.7

Em seguida, será exibida a tela inicial do pgAdmin. Para criar uma

nova conexão, podem ser utilizados diferentes caminhos. Um deles é o menu
“Object > Create > Server” (para que este caminho esteja habilitado, o grupo
de servidores padrão chamado “Servers”, que aparece no canto superior
esquerdo da tela, precisa estar selecionado). O pgAdmin abrirá uma tela,

7
É possível desabilitar essa senha modificando o valor do parâmetro
MASTER_PASSWORD_REQUIRED para “False” no arquivo config.py que fica localizado na
subpasta “web” do diretório de instalação do pgAdmin ( C:\Program
Files\PostgreSQL\14\pgAdmin 4\, por exemplo).

40
igual à imagem abaixo, para que sejam informados os parâmetros da
conexão com o banco.

Figura 11 – Criando uma nova conexão no pgAdmin.

Na primeira aba dessa tela, chamada “General”, o único valor a ser

obrigatoriamente informado é o nome do servidor. Você deverá colocar um
nome que facilite a identificação do servidor que você está acessando. Se
estiver executando o pgAdmin na mesma máquina onde o banco foi
instalado, pode utilizar o nome “Local”, por exemplo. Na segunda aba,
“Connection”, é necessário informar o nome ou IP do servidor (ou
“localhost”), a porta que será utilizada para acesso (valor definido na
instalação; padrão é 5432), o nome do banco de dados que será acessado
(padrão no primeiro acesso é “postgres”), o nome do usuário (também
padrão “postgres”) e a senha deste usuário que foi informada na instalação.
Habilite a opção “save password” se você não quiser digitar a senha sempre
que for se conectar a esse banco de dados. Após informar todos esses
valores, basta clicar no botão “Save” para que essa nova conexão seja criada
dentro do grupo de servidores “Servers” que já aparecia como padrão.

41
 Sempre que o servidor aparecer junto ao ícone do elefante (símbolo
do PostgreSQL), significa que a conexão com o servidor já está ativa. Caso
apareça um ícone que representa três dispositivos de armazenamento com
um “x” vermelho, indica que aquela conexão não está ativa (neste caso é
possível clicar com o botão direito sobre o servidor e selecionar a opção
“Connect server”).

6.2. Visualizando objetos do banco de dados

Após estabelecida a conexão com o banco de dados, o pgAdmin
exibirá os objetos deste banco de dados de forma hierárquica no lado
esquerdo da tela. Clica-se sobre a seta que aparece do lado esquerdo de cada
item da hierarquia para expandi-lo ou retrai-lo. Logo ao expandir a conexão
criada, os itens exibidos no primeiro nível da hierarquia são os bancos de
dados, usuários/roles e tablespaces.

No item bancos de dados é exibido, inicialmente, o banco de dados

“postgres” que é criado por padrão quando o banco é instalado. Nos itens
do banco de dados podemos destacar os esquemas (“schemas”), que é onde
ficam armazenados os objetos dos usuários e aplicações.

Para criação de um novo banco de dados, podemos utilizar o menu

“Object > Create > Database”, conforme imagem abaixo (este caminho
estará habilitado somente se o item “Databases” estiver selecionado na
árvore de objetos que aparece no canto esquerdo da tela).

O pgAdmin abrirá, então, uma tela para que sejam informados os

parâmetros do novo banco que será criado, sendo o nome o único parâmetro
de preenchimento obrigatório, pois para os demais podem ser utilizados os
valores padrão. Pode-se utilizar o nome “BD_Teste”, por exemplo. Também é
possível criar um novo banco utilizando o comando SQL abaixo. Para
executar comandos SQL no pgAdmin utiliza-se o editor de comandos SQL
chamado “Query Tool”, que é acessado através do menu “Tools > Query Tool”

42
ou através do ícone no canto superior esquerdo da tela. No Query Tool,
utiliza-se a seta ícone do “play” ou a tecla F5 para executar o comando.

CREATE DATABASE "BD_Teste"

WITH
OWNER = postgres
ENCODING = 'UTF8'
CONNECTION LIMIT = -1;

No novo banco de dados é criado um esquema padrão “public”. Mas

também podemos criar um novo esquema utilizando uma sequência de
passos bem parecida com a criação do banco de dados: ou utilizamos o menu
“Object > Create > Schema” (habilitado somente se o item “Schemas” estiver
selecionado na árvore de objetos) ou executando no Query Tool o comando
SQL para este fim, conforme abaixo:

CREATE SCHEMA "SC_Teste"

AUTHORIZATION postgres;
GRANT ALL ON SCHEMA "SC_Teste" TO postgres;

Observe que, para criar um novo esquema, é necessário informar as

permissões de acesso a pelo menos um usuário (no exemplo acima
atribuímos permissão total do usuário “postgres”). Também é importante
ficar atento que no Query Tool, antes de executar o comando SQL, é
importante conferir o banco de dados em que o comando será executado.
Para criar o novo esquema no “BD_Teste” que foi criado no passo anterior,
por exemplo, este banco de dados deverá estar sendo exibido nas
propriedades da conexão do Query Tool, conforme destacado no print da tela
abaixo:

43
 Figura 12 – Conferência do banco de dados no Query Tool.

Criado um novo esquema, agora podemos criar tabelas nele. Pode-

se utilizar, por exemplo, o comando SQL abaixo para criação de uma nova
tabela “TB_Teste” com apenas dois campos: um código (numérico) e uma
descrição (alfanumérica).

CREATE TABLE "SC_Teste"."TB_Teste"

(
codigo integer NOT NULL,
descricao character varying NOT NULL,
CONSTRAINT "PK_TB_Teste" PRIMARY KEY (codigo)
);

ALTER TABLE IF EXISTS "SC_Teste"."TB_Teste"

OWNER to postgres;

Para criação da tabela, há um assistente gráfico, semelhante ao que

foi citado para a criação do banco de dados e do esquema. Para acessá-lo,
basta clicar com o botão direito sobre o esquema no qual a tabela deverá ser
criada e, em seguida, selecionar a opção “Create > Table”. Será apresentada,
então, uma tela para preenchimento de todas as características da nova
tabela a ser criada.

Depois de criada a tabela, podemos visualizá-la na árvore de objetos

do canto esquerdo da tela, bem como suas propriedades (colunas, chaves,
índices etc.). Para visualizar e manipular os dados da tabela, existe duas
opções: utilização do assistente gráfico ou utilização do Query Tool para
execução dos comandos SQL. O assistente gráfico é acessando clicando com

44
o botão direito sobre a tabela e selecionando a opção “View / Data > All rows”.
Essa opção abrirá uma tela mostrando os dados atuais da tabela e permitirá
que você altere esses dados sem a utilização de comandos SQL. Já no Query
Tool, pode-se realizar as mesmas operações utilizando comandos SQL.
Abaixo estão listados, por exemplo, comandos SQL que permitem,
respectivamente: inserir dois novos registros na tabela criada, exibir os
dados da tabela e excluir um dos registros que foram inseridos.

INSERT INTO "SC_Teste"."TB_Teste" (codigo, descricao)

VALUES (1, 'Teste');
INSERT INTO "SC_Teste"."TB_Teste" (codigo, descricao)
VALUES (2, 'Novo Teste');

SELECT codigo, descricao from "SC_Teste"."TB_Teste";

DELETE FROM "SC_Teste"."TB_Teste"

WHERE codigo = 1;

45
7
 Capítulo 7. Introdução aos Bancos de Dados Não Relacionais
(NoSQL)
7.1. Definição e tipos
Os bancos de dados não relacionais são também conhecidos como
NoSQL8. Esse modelo de banco de dados começou a ganhar força em
meados da primeira década dos anos 2000, quando o volume de dados
disponíveis na web já estava crescendo de forma exponencial e as
organizações começaram a perceber a necessidade de fazer análises e
armazenar parte desses dados. Entretanto, os bancos de dados relacionais,
além de pouco escaláveis, apresentavam dificuldades para armazenar
algumas estruturas de dados mais complexas, tais como colunas aninhadas
e tabelas dinâmicas.

Os bancos de dados não relacionais são considerados mais

escaláveis, pois exigem menos recursos de processamento das máquinas e
os dados podem ser mais facilmente replicados entre os servidores.

Diferentemente do que ocorre nos bancos de dados relacionais, nos

bancos não relacionais não se define uma estrutura prévia para
armazenamento dos dados (tabelas, colunas, chaves etc.). Por esse motivo,
esses bancos de dados às vezes são chamados de não estruturados ou
semiestruturados. Alguns autores defendem que essa dinamicidade do
esquema dos bancos não relacionais faz deles mais adaptados ao
desenvolvimento ágil, que demanda iterações significativas e rápidas.

8
Alguns autores e profissionais da área consideram o termo NoSQL como “Não SQL” e outros
consideram como “Não somente SQL” (do inglês “Not Only SQL”).

47
 Em 2004, o Google lançou o BigTable, que era uma proposta de
banco de dados de alto desempenho e grande escalabilidade. Vários autores
apontam esse projeto como a primeira grande aplicação de bancos de dados
não relacionais. Em 2005, o CouchDB foi lançado pela Apache, utilizando o
formato JSON para o armazenamento de dados. A partir daí várias outras
propostas surgiram nesse sentido, dentre as quais podemos citar: o Dynamo
da Amazon, lançado em 2007, o Cassandra, lançado pelo Facebook em 2008,
e o MongoDB, lançado em 2009.

Atualmente podemos encontrar diferentes tipos de bancos de dados

não relacionais:

• chave-valor: armazena os dados como um conjunto de pares chave-

valor e cada uma das chaves faz o papel de identificador. Neste tipo
de banco, o banco de dados pode ser visto como uma grande tabela
hash e os dados podem ser acessados rapidamente pela chave. A
principal desvantagem destes bancos de dados é a impossibilidade
de se construir consultas mais elaboradas. Alguns exemplos deste
modelo são: Amazon DynamoDB, Redis, dentre outros.

• orientado a documentos: nestes bancos de dados os dados são

armazenados em documentos que, por sua vez, são definidos
através de pares chave-valor, geralmente utilizando o padrão JSON.
Diferentemente dos bancos de chave-valor, em que cada valor
armazenado no banco possui uma chave identificadora, nos bancos
orientados a documentos cada documento possui uma chave
identificadora. Os documentos não possuem estrutura rígida, como
nos bancos relacionais; pode-se adicionar ou excluir novos campos
aos documentos de forma dinâmica, sem maiores problemas. O
banco mais conhecido neste modelo é o MongoDB.

• colunar: este modelo permite que cada registro tenha uma

quantidade variável de colunas. Como os dados armazenados

48
 agrupados por colunas (e não por registros como nos bancos
relacionais), tendem a ser mais lentos para escrita dos dados e mais
ágeis para a leitura, o que faz com que sejam considerados uma boa
opção para aplicações OLAP. Alguns exemplos mais conhecidos
deste modelo são o Cassandra e o HBase.

• orientado a grafo: neste modelo os dados são armazenados em

objetos representados por nós (entidades de dados propriamente
ditas; são os vértices do grafo e possuem atributos) e arestas
(relacionamento entre as entidades). Permitem a representação de
relacionamentos dinâmicos em grandes volumes e, por isso,
costumam ser utilizados em aplicações que demandam constante
navegação pelos dados armazenados através de seus
relacionamentos, como redes sociais, por exemplo. O exemplo mais
conhecido deste tipo de banco de dados é o Neo4J.

• orientado a busca: estes bancos utilizam índices para organizar

dados semelhantes e facilitar a busca. Costumam ser eficazes para
buscas em textos completos e ranqueamento de resultados. O
Elasticsearch é o exemplo mais conhecido deste modelo atualmente.

Não podemos afirmar que os bancos de dados NoSQL irão suprimir

as bases relacionais. A tendência que podemos observar no momento é de
que cada um desses modelos tende a ser utilizados em tipos de aplicações
específicos. No próximo tópico faremos uma comparação entre os bancos
relacionais e não relacionais, o que nos ajudará a entender o contexto em
que cada um é mais indicado.

7.2. Bancos de dados relacionais X não-relacionais

O quadro abaixo resume as principais diferenças entre os bancos de
dados relacionais e os não-relacionais.

49
 RELACIONAIS
As estruturas para armazenamento dos
dados e os tipos são definidos
previamente.
Maior segurança e integridade dos
dados, graças às restrições de
integridade.
Escalabilidade vertical, ou seja, requer
maior infraestrutura de hardware
quando o volume de dados aumenta
muito.
Um único modelo de armazenamento
baseado em tabelas e relacionamentos
entre elas.
Transações ACID para garantir a
consistência dos dados.
NÃO RELACIONAIS
Não possui definição de estrutura e
tipos, ou a definição é feita de forma
dinâmica.
Não possui restrições de integridade
dos dados.
Escalabilidade horizontal, com maior
facilidade para criação de ambientes
clusterizados, graças a uma maior
facilidade para particionamento e
replicação dos dados.
Vários modelos de armazenamento
(documentos, grafos, colunas, chave-
valor).
A consistência é eventual e relativa.
Leva em conta o teorema CAP. O
teorema CAP defende que, em um
sistema distribuído, só podemos ter
duas das três características desejadas:
“C” (consistência), “A” (disponibilidade,
ou no inglês availability) e “P”
(tolerância ao particionamento, ou seja,
o cluster continua a funcionar mesmo
em casos de falhas de comunicação
entre os nós do sistema).
Assim, de acordo com o teorema, os
bancos relacionais seriam sistemas CA
(valorizam a consistência e a
disponibilidade e abrem mão da
tolerância a partição) e os bancos
NoSQL seriam sistemas AP (valorizam
50

Consulta e manipulação dos dados por
meio da linguagem SQL.
São capazes de trabalhar com
aplicações OLTP e OLAP.
A performance é influenciada por
diversos fatores, dentre os quais os
principais são: capacidade do hardware
(principalmente velocidade do disco),
otimização de consultas, utilização
correta de índices e modelagem correta
da estrutura de armazenamento.
disponibilidade e tolerância ao
particionamento).
Não há uma linguagem padrão para
acesso e manipulação dos dados.
Utilizam APIs baseadas em objetos que
permitem às aplicações acessarem os
dados.
Indicados para aplicações de baixa
latência, que fazem pesquisa e análise
em grandes volumes de dados
semiestruturados.
A performance varia em função do
tamanho do cluster, da latência de rede
e da aplicação que acessa os dados.
51
8
Capítulo 8. Fundamentos do MongoDB
8.1. Conceitos iniciais
O MongoDB é um banco de dados não relacional (NoSQL) orientado
a documentos. Segundo o ranking do DB-Engines, é o banco de dados não
relacional mais utilizado atualmente.

O MongoDB possui 3 opções de edições: Community Server

(gratuita), Enterprise Server (versão comercial que inclui recursos avançados
de performance, segurança e disponibilidade) e Atlas (é a versão de banco
de dados como serviço, que pode ser utilizado nos principais provedores de
nuvem).

É reconhecido no mercado como um banco de dados de bom

desempenho, alta escalabilidade e grande capacidade de armazenamento
de grandes volumes de dados. Tais características fazem com que o
MongoDB seja uma boa opção para armazenamento de dados de aplicações
que precisam lidar com estatísticas e cruzamento de informações em
grandes massas de dados.

A ideia de se criar o MongoDB surgiu dentro da empresa Doubleclick

(empresa de publicidade na internet). A empresa tinha, até então,
dificuldades para lidar com a falta de desempenho e de escalabilidade das
soluções disponíveis e decidiu criar um banco de dados capaz de superar
tais deficiências. Em 2007, fundaram, então, a 10gen, que somente em 2013
passaria a se chamar MongoDB Inc. Em 2009, foi lançada a primeira versão
do banco. O nome MongoDB surgiu da palavra "Humongous" que significa
algo muito grande; enorme.

O MongoDB utiliza o formato JavaScript Object Notation (JSON)

para armazenar os documentos. Trata-se de um formato para representação

53
de informações e intercâmbio de dados entre sistemas, assim como o XML.
Porém, o JSON é considerado mais simples que o XML.

No JSON os objetos são representados sempre com "chave-valor",

onde a chave é o identificador do conteúdo e o valor é o conteúdo
propriamente dito, podendo ser de diferentes tipos de dados (string,
número, booleano etc.). A formatação de arquivos JSON é bastante simples
e tem como regras principais:

• Utiliza-se dois pontos (":") para separar a chave do seu valor;

• As chaves são sempre do tipo string e devem ser colocadas entre

aspas duplas;

• Cada par "chave-valor" deve ser separado por vírgula;

• Utiliza-se chaves {} para delimitar um objeto JSON;

• Valores de um array devem ser colocados entre colchetes [].

Veja abaixo um exemplo de objeto especificado utilizando JSON:

{
"sequencial":1,
"tipo":"Livro",
"nome":"Introdução ao MongoDB",
"ano": 2022,
"autores": ["Guilherme Baião", "José da Silva"]
}

Na realidade, MongoDB utiliza internamente o padrão BSON (Binary

JSON), que suporta alguns tipos de dados não suportados no JSON (tais
como datas e objetos binários).

8.2. Bancos de dados, coleções e documentos

No MongoDB os documentos ficam armazenados em coleções
(collection). Um servidor MongoDB pode possuir diversos bancos de dados.
Cada banco de dados, por sua vez, pode possuir diversas coleções (cada

54
coleção está contida sempre em um único banco). E cada coleção pode
possuir diversos documentos. Cada documento, conforme já comentado, é
um conjunto de pares "chave:valor". Vale lembrar que os documentos
possuem estrutura dinâmica, ou seja, os campos e tipos de dados podem
variar de um documento para outro.

Alguns autores chegam a comparar o conceito de coleção no

MongoDB o de tabelas em bancos de dados relacionais. Entretanto, são
paradigmas completamente distintos e essa analogia perde relevância, uma
vez que as diferenças entre tabelas e coleções são muitas. A figura abaixo
ilustra essa relação entre bancos de dados coleções e documentos no
MongoDB.

Figura 13 – Arquitetura Lógica do banco de dados MongoDB.

Em termos de armazenamento físico dos dados, cada banco de

dados possui arquivos físicos próprios no sistema operacional. O caminho
onde os arquivos ficam armazenados é definido no momento da instalação
do banco.

55
9
Capítulo 9. Instalação do MongoDB
9.1. Instalando o MongoDB e MongoDBCompass
O primeiro passo é fazer o download do instalador do banco. Para
isso, basta acessar o site do MongoDB (mongodb.com), clicar em "Products"
e, em seguida, clicar no link “Community Server”. No canto direito da nova
página que será exibida, selecionamos a versão a ser instalada e o sistema
operacional. Neste exemplo utilizamos a versão 5.0.6 e a plataforma
Windows. Selecionados esses parâmetros, clica-se no botão “Download”,
conforme tela da imagem abaixo.

Figura 14 – Download do instalador do MongoDB.

Ao finalizar o download do instalador, cujo tamanho do arquivo é de

aproximadamente 290MB, execute-o. A primeira tela exibida pelo programa
de instalação é uma tela de boas-vindas. Basta clicar em “Next”. Na segunda
tela é necessário marcar o “aceite” dos termos de licenciamento e clicar em
“Next”. Na tela seguinte selecionamos o modo de instalação completa.

Logo em seguida é apresentada a tela de configuração do serviço do

MongoDB. Nela mantemos a opção de executar o serviço como usuário de

57
rede (opção que vem selecionada por default). O nome do serviço no
Windows e os diretórios onde os arquivos de dados e de log serão
armazenados podem ser alterados se necessário. Neste exemplo iremos
alterar o nome do serviço para MongoDB5 e manteremos os diretórios
informados como padrão. Veja a tela na imagem abaixo:

Figura 15 – Configuração do serviço do MongoDB.

Após clicar em “Next” será exibida uma nova tela do instalador onde
é possível indicar se o MongoDB Compass deverá ser instalado ou não. O
Compass é a interface gráfica que permite acessar e interagir com o servidor
do MongoDB. Portanto, manteremos esta opção selecionada e clicaremos
em “Next” mais uma vez. A tela exibida na sequência é apenas uma
confirmação da instalação e, ao clicarmos no botão “Install”, a instalação
será iniciada. Ao finalizar a instalação, será exibida uma nova tela
informando o término. Basta clicar em “Finish” para encerrar a execução do
instalador.

Para conferir se a instalação foi finalizada com sucesso, pode-se

utilizar a tela de gerenciamento de serviços do Windows, verificando se o

58
 serviço referente ao MongoDB Server está sendo exibido. Também pode ser
verificado se o software MongoDB Compass foi instalado.

9.2. Comandos básicos do MongoDB (linha de comando)

Antes de iniciar a execução de comandos do MongoDB propriamente
dito, precisamos garantir que o processo do servidor esteja sendo
executado. Esse processo pode ser executado pelo próprio serviço do
MongoDB no Windows ou, se o serviço não estiver em execução, podemos
iniciar o processo do servidor manualmente utilizando o comando “mongod”
na linha do prompt de comandos. Para executar o “mongod” é preciso
garantir, antes, que o diretório atual do prompt de comandos é o diretório
onde ficam localizados os arquivos executáveis do MongoDB (o caminho
padrão é C:\Program Files\MongoDB\Server\5.0\bin).9

Para iniciar a utilização do banco de dados, digitamos na linha de

comando o comando “mongo”. Em seguida, serão exibidas na tela
informações básicas sobre a conexão e o processo servidor (como o horário
em que o servidor foi iniciado, por exemplo) e um prompt (símbolo “>”) para
que sejam digitados os comandos do Mongo propriamente ditos. Podemos
digitar o comando “show dbs” para listar os bancos de dados já existentes.
Inicialmente serão exibidos somente os bancos de dados internos do
MongoDB: “admin”, “config” e “local”.

No MongoDB existe um único comando para setar o banco de dados

corrente ou criar um novo banco, que é o comando “use”. Ou seja, quando
utilizamos o comando “use bd_teste”, por exemplo, se já existir um banco de
dados com este nome, ele será setado como banco de dados corrente. Caso
não exista, ele será criado. Podemos executar, então, o comando “use” para
criar um novo banco de dados a ser utilizado nos exemplos de comandos

9
Caso o processo servidor tenha sido iniciado pelo “mongod” e não pelo serviço do Windows,
a janela que iniciou esse processo deverá permanecer aberta durante a utilização do banco.

59
abaixo. É importante ressaltar que se executarmos o “show dbs” logo após a
criação de um novo banco, ele não será listado, pois ainda está vazio. Mas
podemos utilizar o comando “db” para exibir o banco de dados corrente e,
neste caso, poderemos conferir se já estamos no banco de dados que
acabamos de criar.

Vimos anteriormente que no MongoDB os documentos são

armazenados em coleções. Portanto, dentro do novo banco de dados que
criamos precisamos fazer uma nova coleção para podermos iniciar o
armazenamento dos documentos e seus dados. Para criarmos uma coleção
com o nome “colecao_teste”, podemos utilizar o comando a seguir:

> db.createCollection("colecao_teste")

Para conferir se a coleção foi criada, podemos utilizar o comando

“show collections”. Após criada a coleção, podemos iniciar a inserção de
documentos. O comando utilizado é o “insert”, que deve ser precedido do
nome da coleção onde o documento deverá ser inserido. Lembrando que
para descrever os dados do documento a ser inserido utilizamos o padrão
JSON já comentado anteriormente. Exemplo:

> db.colecao_teste.insert(
{
"nome" : "Carlos Aguiar",
"idade" : 32,
"telefone" : "(31) 99999-9999"
})
Observe que após executar o comando de inserção, o Mongo exibe
uma mensagem ( WriteResult({ "nInserted" : 1 }) ) para confirmar a inserção
de um novo documento. O comando para exibir os documentos de uma
coleção é o “find”. Os dados também são exibidos utilizando o padrão JSON.
O primeiro dos dois comandos abaixo exibe os documentos da coleção que
acabamos de criar. O segundo utiliza ainda o procedimento “pretty”
juntamente com o “find” para formatar os dados exibidos:

> db.colecao_teste.find()
> db.colecao_teste.find().pretty()

60
 Ao exibir os dados, podemos perceber que o Mongo cria
automaticamente, para cada documento armazenado, um identificador
único, que é mostrado na chave “_id”. Cabe ressaltar que em momento algum
foi necessário definirmos a estrutura que o documento teria antes de iniciar
a inserção dos dados (como acontece nos bancos relacionais em que temos
que definir a estrutura das tabelas antes de iniciarmos o armazenamento
dos dados). Observe que agora o banco de dados que criamos anteriormente
já possui um documento armazenado e, por isso, se executarmos o comando
“show dbs” novamente, ele será listado. Com o comando abaixo iremos
inserir mais um documento em nossa coleção.

> db.colecao_teste.insert(
{
"nome" : "Marta Maria",
"idade" : 43,
"estado civil": "casada"
})
Podemos utilizar o “find” novamente para visualizar os dados
armazenados. Como parâmetro do “find” podemos utilizar uma grande
variedade de filtros para restringir os documentos a serem exibidos. Esses
filtros incluem operadores lógicos, operadores de comparação, dentre
outros. Veja, por exemplo, os comandos “find” abaixo:

> db.colecao_teste.find({nome: /t/}).pretty()

> db.colecao_teste.find({"idade": {$lt : 40}}).pretty()

O primeiro deles exibe os documentos cujo valor do nome possui a

letra ‘t’. O segundo exibe os documentos cujo valor da idade é menor que 40.

Para atualizar dados de documentos já armazenados, utilizamos o

comando “update”. Esse comando exige basicamente dois parâmetros: o
primeiro será o filtro, para indicar os documentos que deverão ser
atualizados, e o segundo irá descrever a atualização que precisará ser feita.
Os filtros do primeiro parâmetro funcionam de forma idêntica aos filtros do
comando find. Já o segundo parâmetro precisa informar qual a chave
(atributo) a ser atualizado e que tipo de operação deverá ser feita. As
operações mais comuns no update são: “set” para substituir o valor antigo

61
por um novo valor (ou inserir um novo par chave-valor caso a chave
informada não exista), “push” para acrescentar um novo valor à lista de
valores (no caso de valores do tipo array) e “inc” para acrescentar um valor
ao valor atual da chave. Veja como exemplo os três comandos abaixo:

> db.colecao_teste.update(
{"nome": /^M/},
{
$inc : {
"idade" : 15
}
}
)

> db.colecao_teste.update(
{},
{
$set :
{"email" : ["nao informado"]}
},
{multi : true}

> db.colecao_teste.update(
{"idade": 32},
{
$push :
{"email" : "teste@teste.com.br"}
}
)

O primeiro dos três comandos acima incrementa 15 ao valor da idade

dos documentos cujo valor do nome começam com a letra ‘M’. O segundo
cria em todos os documentos uma nova chave chamada “email” com o valor
definido inicialmente como “não informado”. Observe que nesse update foi
utilizado um terceiro parâmetro “multi : true” para indicar que todos os
documentos encontrados para o filtro fornecido (que nesse caso estava
vazio) deveriam ser afetados. Caso o parâmetro “multi : true” não seja
informado, apenas o primeiro do documento encontrado será atualizado.
Observe, também, que o valor dessa nova chave foi informado utilizando
colchetes, sinalizando que essa chave pode receber um conjunto de valores
(array). No terceiro comando acrescentamos nos documentos cuja idade é
igual a 32 um novo valor para a chave e-mail que foi criada pelo comando

62
anterior. Sugere-se a execução do find novamente para visualização dessas
alterações.

O comando para excluir documentos de uma coleção no MongoDB é

o “remove”. Nele passamos como parâmetro apenas o filtro identificando os
documentos a serem removidos. O comando abaixo, por exemplo, remove da
coleção todos os documentos cujo valor da idade seja igual a 32. Caso o filtro
esteja em branco, todos os documentos da coleção serão excluídos.

> db.colecao_teste.remove({"idade":32})

Para finalizar, apresentamos os comandos para exclusão da coleção

e do banco de dados, respectivamente, lembrando que o interpretador de
comandos do MongoDB é case sensitive (maiúsculas e minúsculas são
diferenciadas):

> db.colecao_teste.drop()
> db.dropDatabase()

Para sair do interpretador de comandos, basta utilizar o comando

“exit”.

63
10
 Capítulo 10. Utilizando o MongoDB Compass
10.1. Conectando ao banco de dados
Antes de iniciarmos o MongoDB Compass, é importante conferir se
o serviço do banco de dados está em execução. Ao iniciarmos a execução do
Compass, a primeira coisa que precisamos fazer é criar uma nova conexão
com o banco de dados. No endereço
https://www.mongodb.com/docs/manual/reference/connection-string/ é
possível conferir todos os detalhes sobre opções e parâmetros possíveis
para a criação dessa conexão. Entretanto, de forma simplificada, podemos
utilizar a string abaixo, já que neste exemplo acessaremos um servidor local,
instalado na mesma máquina em que o Compass está sendo executado.

mongodb://localhost:27017

Ao clicar no botão “Connect”, somos direcionados para a página

principal do Compass que detalharemos a seguir. A qualquer momento da
navegação pelo Compass é possível retornar a essa tela inicial simplesmente
clicando sobre o botão “Local”, que fica no canto superior esquerdo da tela.

Figura 16 – Tela inicial do MongoDB Compass.

Na tela inicial temos duas abas principais: “Databases” e

“Performance”. Na primeira são exibidos os bancos de dados existentes no

65
servidor e algumas informações resumidas de cada um deles (tamanho,
quantidade de coleções e quantidade de índices). Ao clicar sobre qualquer
um desses bancos são exibidas as informações principais sobre as coleções
que estão contidas nele (tamanho, quantidade de documentos, tamanho
médio dos documentos, dentre outras). Há também um botão “Create
Database” que permite a criação de um novo banco e uma nova coleção no
Mongo apenas informando o nome de ambos, sem a necessidade de
digitação de comandos.

A segunda aba, “Performance”, exibe de forma gráfica algumas

informações relevantes sobre o desempenho do MongoDB, tais como:
volume de operações que estão sendo executadas (insert, update, query
etc.), volume de leituras e escritas em disco, uso de memória e tráfego de
dados na rede. É possível, por exemplo, fazer um teste mantendo essa tela
aberta e abrindo uma nova tela com prompt de comando para realizar
operações em documentos do banco a fim de observar o comportamento
desses gráficos.

10.2. Visualizando e editando documentos

No MongoDB Compass é possível visualizar os dados de documentos
e até alterá-los. Para isso, após se conectar ao banco de dados, basta
navegar até a coleção desejada utilizando a árvore de objetos do lado
esquerdo da tela ou clicando, na tela principal, sobre o banco de dados em
questão e em seguida sobre a coleção.

Quando os documentos são listados, o Compass exibe também

ferramentas para pesquisa de documentos, edição de dados dos
documentos exibidos, inserção de novos documentos e exclusão de
documentos existentes.

Para a realização de pesquisas entre os documentos da coleção,

utiliza-se filtros no formato JSON, semelhante aos que são utilizados nos
comandos find, update e remove. Clicando no botão “Options” que fica à

66
direita do termo de busca, também é possível definir parâmetro de projeção
(Project), ordenação (sort), regras para comparação de string (collation),
limite de documentos a serem exibidos (limit), quantidade de documentos a
serem ignorados (skip) e o tempo máximo permitido para execução da
pesquisa. A projeção é usada para especificar os campos (chaves) que devem
ser exibidos no resultado da pesquisa (“0” ou “false” indica que o campo não
deve ser exibido; “1” ou “true” indica que o campo deve ser exibido). No sort
especifica-se o(s) campo(s) que deve(m) servir de referência para ordenação
dos resultados e o tipo de ordenação (“1” para ascendente ou “-1” para
descendente). No collation existe a possibilidade de se utilizar um valor
referente a vários idiomas ou países. O valor mais comum utilizado é o
“simple” para ordenação binária padrão. No campo “limit” pode-se informar
uma quantidade limite de documentos a serem exibidos, utilizando o “0”
para indicar que não haverá limite. No campo de tempo máximo de execução
da consulta, informa-se o tempo máximo permitido para execução da
consulta em milissegundos e, se a consulta não for encerrada nesse tempo,
ela será abortada. O valor padrão é de 60000 ms (60 segundos). No skip
indica-se a quantidade de documentos a serem ignorados, ou seja, se uma
consulta retornaria 15 documentos, por exemplo, com o skip igual a 3 ela
passa a retornar apenas 12, pois os 3 primeiros documentos não serão
exibidos. Os argumentos skip e limit podem ser utilizados em conjunto
dentro de códigos de páginas web para a paginação dos resultados.

Veja alguns exemplos de pesquisa abaixo. A primeira exibe o nome e

a idade dos 10 primeiros documentos ordenados pela idade de forma
decrescente. A segunda mostra os documentos cujo telefone contém “31”,
ignorando os 5 primeiros.

67
 Figura 17 – Primeiro exemplo de pesquisa no MongoDB Compass.

Figura 18 – Segundo exemplo de pesquisa no MongoDB Compass.

Para cada documento exibido como resultado, o Compass mostra, no

canto direito da tela, ícones para edição, cópia, clonagem e exclusão do
mesmo. Ao clicar no link de edição, o Compass passa a exibir os dados do
documento em modo de edição e possibilita a alteração dos dados de forma
bem simples. Basta realizar a alteração desejada (é possível alterar tanto os
valores quanto as descrições das chaves) e, em seguida, clicar em “Update”.
O botão de cópia do documento irá carregar no clipboard todos os dados do
documento em questão no formato JSON. O botão de clonagem abrirá uma
nova tela com todos os dados do documento, bastando clicar no botão
“insert” para que seja criado no banco de dados um documento idêntico ao
inicial (apenas o “_id” será diferente, pois não tem como dois documentos
terem o mesmo “_id” no MongoDB). E, por fim, o botão de exclusão permitirá
a exclusão do documento selecionado, bastando confirmar a exclusão no
botão “Delete”.

68
Referências
O QUE é NoSQL?. AWS, c2022. Disponível em:
<https://aws.amazon.com/pt/nosql/>. Acesso em: 27 abr. 2022.

GONZAGA, Jorge Luiz. Dominando o PostgreSQL. 1. ed. Rio de Janeiro:

Ciência Moderna, 2020.

HOWS, David et al. Introdução ao MongoDB. 1. ed. São Paulo: Novatec,

2015.

MONGODB. Disponível em: <https://www.mongodb.com/>. Acesso em: 27

abr. 2022.

DATABASE Concepts - Introduction to the Multitenant Architecture. Docs

Oracle. Disponível em: <https://docs.oracle.com/en/database/oracle/oracle-
database/12.2/cncpt/introduction-to-the-multitenant-architecture.html>.
Acesso em: 27 abr. 2022.

PANIZ, David. NOSQL: Como armazenar os dados de uma aplicação

moderna. Casa do Código, 2016.

PRICE, Jason. Oracle Database 12c SQL. 1. ed. Mc Graw Hill, 2013.

DB-ENGINES Ranking. DB- Engines, abr. 2022. Disponível em: <https://db-

engines.com/en/ranking>. Acesso em: 27 abr. 2022.

THE PostgreSQL Global Development Group. PostgreSQL 14.2

Documentation, c1996-2022. Disponível em:
<https://www.postgresql.org/files/documentation/pdf/14/postgresql-14-
A4.pdf>. Acesso em: 27 abr. 2022.

69