Banco de Dados - Linguagem SQL

Polícia Militar de Minas Gerais

Diretoria de Operações - DOP
Centro de Gerenciamento e Análise de Dados - CGA

Gilmar Rosa
<[Link]

Adriano Felipe Malaquias

<[Link]

Maria Fernanda Alves Fernandes

<[Link]

27 de novembro de 2024

2
 Sumário

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1 Conceito de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Níveis de Abstração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Modelos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Modelo Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 Modelo Lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.4 Modelo Físico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Banco de Dados Relacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Atributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[Link] →Atributo obrigatório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
[Link] →Atributo opcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Atributo Identificador ou Primary Key (PK) . . . . . . . . . . . . . . . . . 12
1.3.4 Chave estrangeria ou Foreing Key(FK) . . . . . . . . . . . . . . . . . . . . . 13
1.3.5 Chave Candidata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.6 Cardinalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[Link] →Cardinalidade Mínima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
[Link] →Cardinalidade Máxima . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.7 Relacionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Normalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Estrutura do Banco de Dados Relacional . . . . . . . . . . . . . . . . . . . . . 14
1.5.1 Tabelas (ou Entidades) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.2 Colunas (ou atributos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.3 Linhas (ou tuplas ou ocorrência de entidade) . . . . . . . . . . . . . . . 15
1.6 Dicionário de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7 Tipos de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 ÁLGEBRA RELACIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 Álgebra Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 σ Seleção/Restrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 π Projeção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 ∪ União . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 ∩ Interseção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.5 − Diferença . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.6 x Produto Cartesiano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1.7 | x | Junção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.8 / Divisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.9 ρ Renomeação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.10 ← Atribuição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 SISTEMA DE GERENCIAMENTO DE BASES DE DADOS (SGBD) . . . . . 34

3.1 Sistema de Gerenciamento de Bases de Dados (SGBD) ou Data Base Mana-
gement System (DBMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Atores de um banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 DBA - Database Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Analistas de bancos de dados (projetistas) . . . . . . . . . . . . . . . . . 35
3.2.3 Analistas de sistemas e programadores de aplicações . . . . . . . . . . . 35
3.2.4 Usuários finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 LINGUAGEM SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Linguagem SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Data Definition Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Data Manipulation Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.3 Data Control Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.4 Data Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Funções DQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 Funções básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] Where . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] Operadores Comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] Operadores Lógicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
[Link] ORDER BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Funções intermediarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
[Link] Agregação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
[Link] GROUP BY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
[Link] HAVING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
[Link] CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
[Link] DISTINCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
[Link] JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.3 Funções avançadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
[Link] SUBQUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
[Link] UNION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 VIEWS, TRIGGERS, FUNCIONS E PROCEDURES . . . . . . . . . . . . . . . 70

5.1 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Stored Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6 O MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER) . . . . . 75

6.1 Superclasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Subclasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Herança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 Especialização e Generalização . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5 Restrições e características das hierarquias de especialização e generalização 77
6.6 Hierarquias e reticulado da especialização e generalização . . . . . . . . . . . 79
6.7 Utilizando especialização e generalização no refinamento de esquemas con-
ceituais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.8 Modelagem dos tipos UNIAO usando categorias . . . . . . . . . . . . . . . . . 80

7 NOSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1 Introdução ao NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2 Diferenças entre NoSQL e bancos de dados relacionais (SQL) . . . . . . . . . 82
7.3 Fundamentos dos Bancos de Dados NoSQL . . . . . . . . . . . . . . . . . . . 84
7.3.1 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
[Link] Modelo chave-valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
[Link] Modelo de colunas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
SUMÁRIO 5

[Link] Modelo de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

[Link] Modelo de grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.4 Tipos de Bancos de Dados NoSQL . . . . . . . . . . . . . . . . . . . . . . . . 85
7.5 Ferramentas e Tecnologias Populares . . . . . . . . . . . . . . . . . . . . . . . 85
7.6 Operações Básicas e Consultas . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
 6

Apresentação

Este material foi desenvolvido pelo Grupo de Pesquisa Centro de Gerenciamento e Análise de Dados
da Polícia Militar de Minas Gerais - PMMG, com o objetivo de apoiar aqueles que têm interesse no
aprendizado de Banco de Dados Relacional e NoSql. Além deste material, o grupo também disponibiliza
apostila de Apostila de R, disponível em <[Link]

Este Guia está na sua versão inicial, dúvidas, sugestões e contribuições podem ser enviados para
<[Link]@[Link]>.

Recomendamos que você, além de ler o material, implemente os exemplos, procure outras formas
de implementação, e compare os resultados.

Agradecemos fortemente ao CGA/DOP, pelo suporte financeiro e condições para produção deste ma-
terial, sem o qual não seria possível desenvolvimento desta versão preliminar.

Agradecemos profundamente a Dênio Barbosa Junior pelo seu valioso contributo no desenvolvimento
desta apostila, que enriqueceu significativamente este trabalho.

Ao longo desta apostila, exploramos diversos aspectos fundamentais dos bancos de dados e da lin-
guagem SQL, proporcionando uma visão abrangente e prática para aqueles que desejam aprofundar
seus conhecimentos na área.

Iniciamos nossa jornada no Capítulo 1, onde introduziremos conceitos básicos de bancos de dados,
suas finalidades e a importância da organização das informações. A compreensão dessas bases sustenta
todo o conhecimento adquirido nas seções subsequentes.

No Capítulo 2, discutiremos a álgebra relacional, um dos pilares teóricos que fundamentam a mani-
pulação de dados em bancos relacionais. Serão apresentadas operações básicas, como seleção, projeção
e união, que nos prepara para compreender a complexidade do gerenciamento de dados.

A modelagem de dados, abordada no Capítulo 3, será um passo importante na a construção de bancos

de dados relacionais. Através de diagramas e representações visuais, destacamos a importância de pla-
nejar a estrutura de um banco, assegurando a integridade e a eficiência na manipulação de dados.

No Capítulo 4, mergulharemos na linguagem SQL, onde aprenderemos a criar, modificar e principal-

mente, consultar dados. As instruções SQL são ferramentas poderosas que permitem interagir com
bancos de dados relacionais.

Avançamos para o Capítulo 5, onde discutiremos sobre as Views, Triggers, Functions e Procedures.
Esses elementos auxiliam otimizando as consultas, garantindo a integridade dos dados e automatizando
processos. Tornando a gestão de bancos de dados mais eficiente e menos suscetível a erros.

No Capítulo 6, exploraremos o Modelo Entidade-Relacionamento Estendido, que nos permite repre-

sentar de forma mais rica e detalhada as relações entre diferentes entidades. Recurso valoroso na
construção de sistemas complexos e a compreensão de como as informações se inter-relacionam.

Por fim, no Capítulo 7, abordaremos noções básicas de NoSQL, uma alternativa aos bancos de da-
dos relacionais, que se destaca em cenários que exigem escalabilidade e flexibilidade. Essa visão nos
prepara para o futuro, onde os bancos de dados não relacionais estão se tornando cada vez mais rele-
SUMÁRIO 7

vantes.

Esta apostila não apenas fornece um conjunto de habilidades técnicas, mas também fomenta um pen-
samento crítico sobre a manipulação e a gestão de dados. Esperamos que os conhecimentos adquiridos
aqui sirvam como base sólida para o desenvolvimento de projetos e soluções inovadoras na área de
bancos de dados. A prática contínua e a curiosidade são essenciais para se manter atualizado em um
campo tão dinâmico e em constante evolução. Aprofundem-se, experimentem e façam da análise de
dados uma ferramenta poderosa em suas trajetórias.

Boa leitura e bons estudos!

 8

1 Introdução

1.1 Conceito de Banco de Dados

O conceito de banco de dados relaciona-se ao armazenamento, manutenção e recuperação de infor-
mações. Um banco de dados pode ser definido como uma coleção de dados inter-relacionados que
são armazenados e organizados de forma eficiente e sistemática. Os dados, via de regra, representam
algum aspecto do mundo real. O banco de dados permite o armazenamento, a coleta, a recuperação
e a manipulação dos dados de maneira estruturada. Sua organização segue uma lógica coerente, com
dados que devem atender ao mesmo propósito. Portanto, um conjunto aleatório de dados não deve ser
considerado um banco de dados.

Por exemplo, ao preenchermos um formulário de cadastro com dados como nome, usuário, senha e
data de nascimento, esses dados devem ser armazenados em um local específico para uso posterior.
Caso não tivéssemos um banco de dados, o uso e manutenibilidade dos dados se tornaria uma tarefa
difícil e não poderíamos salvar nenhuma informação, o que dificultaria a sua utilização. Neste sentido,
é como se precisássemos nos cadastrar toda vez que quiséssemos acessar o sistema.

Existem dois principais tipos de banco de dados:

• Relacional: Estruturado a partir de relações do mundo real, armazenados em tabelas, com um

conjunto de linhas e colunas, bem como chaves que conectam diferentes tabelas.

• Não Relacional: Não apresenta esquemas nem demanda relações entre os dados. São eficientes
para armazenar grandes volumes de informações em formatos não convencionais, como imagens,
áudios, vídeos e outros tipos de multimídia, por exemplo.

Nesta apostila, iremos focar em bancos de dados relacionais,

1.2 Níveis de Abstração

1.2.1 Modelos de Dados
Modelar dados consiste em desenhar o sistema de informações, concentrando-se nas entidades lógicas
e nas dependências lógicas entre essas entidades.

É a descrição formal da estrutura de um banco de dados. Há vários tipos de modelos de dados.

Alguns dos mais comuns são:

1. Modelo Entidade-Relacionamento 4. Modelo Relacional (Relational Model ):

(Entity-Relationship Model ): Representa Organiza dados em tabelas com linhas e co-
dados através de entidades e suas relações. lunas.

2. Esquema Estrela (Star Schema): Usado 5. Modelo de Rede (Network Model ): Es-
em data warehousing, organiza dados em trutura dados como um grafo, com conexões
uma estrutura centralizada em uma tabela flexíveis entre registros.
de fatos.
6. Modelo Relacional de Objeto (Object-
3. Modelo de Banco de Dados Hierárquico Relational Model ): Combina característi-
(Hierarchical Model ): Estrutura dados em cas do modelo relacional com conceitos de
uma hierarquia, como uma árvore. orientação a objetos.
1.2. NÍVEIS DE ABSTRAÇÃO 9

1.2.2 Modelo Conceitual

A modelagem conceitual baseia-se no mais alto nível e deve ser usada para envolver o usuário do Banco
de Dados, pois o foco aqui é discutir os aspectos que o usuário necessita e não da tecnologia. Os
exemplos de modelagem de dados vistos pelo modelo conceitual são mais fáceis de compreender, já que
não há aplicação ou implementação de tecnologia específica.

1.2.3 Modelo Lógico

Representa as estruturas de dados a serem implementadas e suas características considerando os limites
impostos pelo modelo de dados usado para implementação do banco de dados (banco de dados hie-
rárquico, banco de dados de rede, banco de dados relacional, etc.). As características principais deste
modelo são:

• É derivado do modelo conceitual.

• Possui entidades associativas em lugar de relacionamentos n:m.

• Define as chaves primárias das entidades.

• Define as chaves estrangeiras entre as entidades.

• Normalização até a 3a. forma normal.

• Adequado ao padrão de nomenclatura adotado pela empresa.

• As Entidades e atributos são documentados em um Dicionário de Dados.

O principal produto da fase de projeto lógico é o modelo relacional.

1.2.4 Modelo Físico

Este modelo representa a implementação do modelo lógico considerando algum tipo particular de tec-
nologia de banco de dados e os requisitos não funcionais (desempenho, disponibilidade, segurança) que
foram identificados pelo analista de requisitos. As características principais deste modelo são:

• Elaborado a partir do modelo lógico.

• Pode variar segundo a tecnologia usada para implementação do banco de dados.

• Possui tabelas físicas.

• Possui colunas físicas.

No modelo físico, a linguagem SQL (Structured Query Language) é a linguagem padrão para definição,
manipulação e controle de uso das estruturas de dados.

Em resumo, modelos de dados conceituais são diagramas de alto nível que representam os concei-
tos de dados que suportam o negócio de uma empresa, uma área de negócio ou, por exemplo, um
sistema de informações. Em projetos de TI, o objetivo principal de um modelo de dados conceitual é
fornecer uma visão geral dos requisitos de informação envolvidos no projeto.

O diagrama facilita ainda a comunicação entre os integrantes da equipe, pois oferece uma linguagem
comum utilizada tanto pelo analista, responsável por levantar os requisitos, e os desenvolvedores, res-
ponsáveis por implementar aquilo que foi modelado.
1.3. BANCO DE DADOS RELACIONAIS 10

• Proposta de Peter Chen Em sua notação original, proposta por Peter Chen (idealizador do
modelo e do diagrama), as entidades deveriam ser representadas por retângulos, seus atributos
por elipses e os relacionamentos por losangos, ligados às entidades por linhas, contendo também
sua cardinalidade (um-para-um(1..1),um-para-muitos(1..n) ou muitos-para-muitos(n..n)).

• Proposta de James Martins Em sua notação, proposta por James Martin, as entidades são
representadas por retângulos que incluem tanto o nome da entidade quanto seus atributos lis-
tados dentro do próprio retângulo. Os relacionamentos são indicados por linhas que conectam
diretamente as entidades, sem o uso de losangos intermediários. A cardinalidade é representada
por símbolos na extremidade das linhas, conhecidos como notação "pés de galinha", indicando
os tipos de relacionamentos: um-para-um (1:1), um-para-muitos (1:N) ou muitos-para-muitos
(N:N).

Figura 1 – Notações de James Martins e Peter Chen

Modelos de dados lógicos decompõem os conceitos de negócio em entidades, atributos e relacionamen-

tos atômicos, aplicando regras de normalização para evitar redundâncias e garantir a integridade dos
dados.

Embora sejam focados em requisitos funcionais e, portanto, independentes de implementações físi-

cas, são utilizados como pontos de partida para a construção de modelos de dados físicos, que espelham
bancos de dados.

Por sua vez, modelos de dados físicos representam os objetos de um banco de dados em uma pla-
taforma ou tecnologia específica. Neste tipo de modelo, as entidades, atributos e relacionamentos
correspondem a tabelas, colunas e constraints.

1.3 Banco de Dados Relacionais

A forma como os dados são armazenados e recuperados através dos bancos de dados relacionais fizeram
deste modelo o mais utilizado nas últimas décadas.

A estrutura básica dos bancos de dados relacionais são as tabelas (também conhecidas como "rela-
ções").Uma tabela é uma estrutura bidimensional formada por colunas e por linhas, sendo as linhas as
instâncias de uma entidade e as colunas os atributos desta entidade. Apresentam, portanto, uma estru-
tura similar às planilhas que muito provavelmente você já utilizou em aplicativos como o Microsoft Excel.

Outra característica importante dos bancos de dados relacionais é a capacidade de relacionar dados
entre duas ou mais tabelas, isto é, criar "relacionamentos"entre as tabelas. Isto é implementado através
de campos ou colunas com valores comuns.
1.3. BANCO DE DADOS RELACIONAIS 11

Figura 2 – As três camadas da modelagem de dados: conceitual, lógica e física.

Fonte: <[Link]

1.3.1 Entidade
Uma Entidade pode ser definida como qualquer coisa do mundo real, abstrata ou concreta, na qual se
deseja guardar informações. (Tabela, File, etc.).

Podemos classificar as entidades segundo o motivo de sua existência:

• Entidades fortes: são aquelas cuja existência independe de outras entidades, ou seja, por si só elas
já possuem total sentido de existir. Em um sistema de vendas, a entidade produto, por exemplo,
independe de quaisquer outras para existir.

• Entidades fracas: ao contrário das entidades fortes, as fracas são aquelas que dependem de
outras entidades para existirem, pois individualmente elas não fazem sentido. Mantendo o mesmo
exemplo, a entidade venda depende da entidade produto, pois uma venda sem itens não tem
sentido.

• Entidades associativas: esse tipo de entidade surge quando há a necessidade de associar uma
entidade a um relacionamento existente. Na modelagem Entidade-Relacionamento não é possível
que um relacionamento seja associado a uma entidade, então tornamos esse relacionamento uma
entidade associativa, que a partir daí poderá se relacionar com outras entidades.

Para melhor compreender esse conceito, tomemos como exemplo uma aplicação de vendas em
que existem as entidades Produto e Venda, que se relacionam na forma muitos-para-muitos, uma
vez que em uma venda pode haver vários produtos e um produto pode ser vendido várias vezes
(no caso, unidades diferentes do mesmo tipo de produto). Em determinado momento, a empresa
passou a entregar brindes para os clientes que comprassem um determinado produto.
1.3. BANCO DE DADOS RELACIONAIS 12

A entidade Brinde, então, está relacionada não apenas com a Venda, nem com o Produto, mas
sim com o item da venda, ou seja, com o relacionamento entre as duas entidades citadas anteri-
ormente. Como não podemos associar a entidade Brinde com um relacionamento, criamos então
a entidade associativa "Item da Venda", que contém os atributos identificadores das entidades
Venda e Produto, além de informações como quantidade e número de série, para casos específi-
cos. A partir daí, podemos relacionar o Brinde com o Item da Venda, indicando que aquele brinde
foi dado ao cliente por comprar aquele produto especificamente.

Algumas vezes é denominada de agregação, trata-se de uma abstração pela qual os relaciona-
mentos são tratados como entidades de nível superior.

A Figura 3 mostra que a entidade Remédio está relacionada não com a entidade Médico ou
a entidade Paciente, mas sim com a Consulta, pois é na consulta que é prescrito o medicamento.

Figura 3 – Entidade Associativa

1.3.2 Atributo
Um atributo é tudo o que se pode relacionar como propriedade da entidade (coluna, campo, etc...).
Exemplos de atributos: Código do Produto (Entidade Produto), Nome do Cliente (Entidade Cliente).

[Link] →Atributo obrigatório

- É aquele que para uma instância de uma entidade ou relacionamento obrigatoriamente deve possuir
um valor. (NOT NULL)

[Link] →Atributo opcional

- É aquele que para uma instância da entidade ou relacionamento pode ou não possuir um valor. (NULL)

1.3.3 Atributo Identificador ou Primary Key (PK)

Atributo capaz de identificar exclusivamente cada ocorrência de uma entidade. Também conhecido
como chave Primária ou Primary Key (PK). Ex: Código do Cliente, Código do Produto, etc.

Características de uma Chave Primária ou Primary Key:

1.3. BANCO DE DADOS RELACIONAIS 13

• Não pode haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na Chave
Primária.

• A chave primária não pode ser composta por atributo opcional, ou seja, atributo que aceite nulo.

• Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada instância de
uma entidade.

• Não devem ser usadas chaves externas.

• Cada atributo identificador da chave deve possuir um tamanho reduzido

• Não deve conter informação volátil.

1.3.4 Chave estrangeria ou Foreing Key(FK)

Uma coluna ou até mesmo um conjunto de colunas que permite a conexão e relação entre os dados de
duas distintas. Uma tabela pode possuir 1 ou N FKs.

1.3.5 Chave Candidata

- Atributo ou grupamento de atributos que têm a propriedade de identificar unicamente uma ocorrência
da entidade. Pode vir a ser uma chave Primária. A chave candidata que não é chave primária também
chama-se chave Alternativa. Por exemplo, em um cadastro na faculdade, que determina um número de
matrícula de cada aluno, sendo este número único, o CPF dos alunos matriculados, podem ser utilizados
como chave alternativa para identificação.

1.3.6 Cardinalidade
A Cardinalidade indica quantas ocorrências de uma Entidade participam no mínimo e no máxima do
relacionamento.

[Link] →Cardinalidade Mínima

- Define se o relacionamento entre duas entidades é obrigatório ou não.

[Link] →Cardinalidade Máxima

- Define a quantidade máxima de ocorrências da Entidade que pode participar do Relacionamento. Deve
ser maior que zero.

1.3.7 Relacionamento
Um relacionamento pode ser entendido como uma associação entre instâncias de Entidades devido a
regras de negócio. Normalmente ocorre entre instâncias de duas ou mais Entidades, podendo ocorrer
entre instâncias da mesma Entidade (auto-relacionamento).

Tipos de relacionamentos binários:

1. 1:1

2. 1:n

3. n:n

Cardinalidades máximas mais comuns: 1 e n.

1.4. NORMALIZAÇÃO 14

1. Relacionamento 1:1 (um para um): cada uma das duas entidades envolvidas referenciam obriga-
toriamente apenas uma unidade da outra. Por exemplo, em um banco de dados de currículos,
cada usuário cadastrado pode possuir apenas um currículo na base, ao mesmo tempo em que
cada currículo só pertence a um único usuário cadastrado.

2. Relacionamento 1:n ou 1:* (um para muitos): uma das entidades envolvidas pode referenciar
várias unidades da outra, porém, do outro lado cada uma das várias unidades referenciadas só
pode estar ligada uma unidade da outra entidade. Por exemplo, em um sistema de plano de saúde,
um usuário pode ter vários dependentes, mas cada dependente só pode estar ligado a um usuário
principal. Note que temos apenas duas entidades envolvidas: usuário e dependente. O que muda
é a quantidade de unidades/exemplares envolvidas de cada lado.

3. Relacionamento n:n ou *:* (muitos para muitos): neste tipo de relacionamento cada entidade, de
ambos os lados, podem referenciar múltiplas unidades da outra. Por exemplo, em um sistema de
biblioteca, um título pode ser escrito por vários autores, ao mesmo tempo em que um autor pode
escrever vários títulos. Assim, um objeto do tipo autor pode referenciar múltiplos objetos do tipo
título, e vice versa.

Situações que se deve usar o relacionamento:

• Quando existem várias possibilidades de relacionamento entre o par das entidades e se deseja
representar apenas um

• Quando ocorrer mais de um relacionamento entre o par de entidades

• Para evitar ambiguidade

• Quando houver auto-relacionamento

1.4 Normalização
Normalização é o conjunto de regras que visa minimizar as anomalias de modificação dos dados e dar
maior flexibilidade em sua utilização.

Vantagens da Normalização:

• Minimização de redundâncias e inconsistências;

• Facilidade de manipulações do Banco de Dados;

• Facilidade de manutenção do Sistema de Informações.

1.5 Estrutura do Banco de Dados Relacional

Em termos de armazenamento de dados, um banco de dados relacional é composto de Tabelas, Colunas
e Linhas.

1.5.1 Tabelas (ou Entidades)

Nos modelos de base de dados relacionais, uma tabela é um conjunto de dados com um número deter-
minado de colunas (ou campos) e um número infinito de linhas (ou registros ou tuplas).

Um banco de dados é composto de uma ou mais tabelas (podemos chamar também de entidades),
que é uma forma comum de armazenagem de dados na empresa. O correto é que, através de um
processo de modelagem de dados bem feito, todos os dados necessários ao negócio fiquem organizados
1.6. DICIONÁRIO DE DADOS 15

nestas tabelas. A criação de cada tabela de um banco de dados, deverá ser feita com coerência e
verificando o “assunto” que cada tabela irá armazenar. Cada tabela deve armazenar dados relacionados
com apenas um assunto ou conceito do negócio.

1.5.2 Colunas (ou atributos)

Cada tabela possui colunas, que são os nomes dos dados que serão armazenados. Cada coluna repre-
senta uma informação ou atributo da linha.

Cada campo (ou atributo) possuem propriedades, como por exemplo o tipo de dados a ser armaze-
nado (alfabético, numérico, alfanumérico, temporal), se é de preenchimento obrigatório e o tamanho.

1.5.3 Linhas (ou tuplas ou ocorrência de entidade)

As tabelas (ou entidades) também possuem linhas (ou tuplas) que são os registros contendo dados que
estão armazenados em cada campo da tabela.
Então podemos dizer que tabela (ou entidade) é:

• Um objeto criado para armazenar os dados fisicamente

• Os dados são armazenados em linhas (tuplas) e colunas (atributos)

• Os dados de uma tabela normalmente descrevem um único assunto tal como clientes, vendas,
produtos, curso, aluno, disciplina, bilhete, filme, cinema, sessão, viagem, hotel, voo, etc.

1.6 Dicionário de dados

Um dicionário de dados é um documento que descreve as informações representadas no modelo de
dados, descrevendo informações de suas entidades e seus atributos (tamanho, tipos de dado, obrigato-
riedade e definição).

O dicionário de dados é usado para documentar os dados da empresa e facilitar a comunicação e

entendimento entre analista de sistemas e seus usuários, além de servir de ferramenta para avaliação de
modelos de dados pelos analistas de dados corporativos que tem a responsabilidade de manter o modelo
de dados corporativo coeso, completo e de fácil manutenção.

Algumas ferramentas CASE geram dicionário de dados automaticamente a partir das informações exis-
tentes no catálogo do banco dados.

1.7 Tipos de dados

Os tipos de dados em SQL constituem um componente importante na definição das colunas em um
banco de dados. Cada coluna em uma tabela deve ser declarada com um tipo de dado específico, que
determina o tipo de valores que pode armazenar. O tipo dos dados são segmentados da seguinte forma:
1.7. TIPOS DE DADOS 16

Tabela 1 – Tipos de dados

Categoria Tipo de Dado Descrição Performance Exemplo

Numérico integer (int, int4) Inteiro assinado de Alta. Uso eficiente de armazenamento 42
quatro bytes e operações rápidas. Ex: contagem de
itens.
Numérico smallint (int2) Inteiro assinado de Muito Alta. Menor uso de armaze- 42
dois bytes namento, ideal para valores pequenos.
Ex: contagem de itens limitados.
Numérico bigint (int8) Inteiro assinado de Média. Maior uso de armazenamento, 12345678901239
oito bytes bom para grandes números. Ex: iden-
tificadores únicos globais.
Numérico double precision Número de ponto Média. Muito útil em cálculos cien- 3.141592657933
(float8) flutuante de precisão tíficos, maior precisão. Ex: medições
dupla (8 bytes) científicas.
Numérico real (float4) Número de ponto Alta. Menor precisão, porém, com re- 3.14
flutuante de precisão torno mais rápido. Frequentemente
única (4 bytes) utilizado em cálculos gráficos.
Tempo date Data do calendário Muito Alta. Simples e eficiente. Ex: ’2024-06-25’
(ano, mês, dia) datas de nascimento.
Tempo timestamp [ (p) Data e hora (sem Alta. Preciso para eventos sem fuso ’2024-06-25
] without time fuso horário) horário. Ex: registros de log locais. 14:30:00’
zone
Tempo timestamp [ (p) Data e hora, in- Média. Requer maior espaço de arma- ’2024-06-25
] with time zone cluindo fuso horário zenamento, bom para eventos globais. 14:30:00+00’
(timestamptz) Ex: agendamento internacional.
Tempo time [ (p) ] Hora do dia (sem Alta. Preciso para horas específicas. ’14:30:00’
without time fuso horário) Ex: horários de funcionamento.
zone
Tempo time [ (p) ] Hora do dia, in- Média. Mais armazenamento, útil ’14:30:00+00’
with time zone cluindo fuso horário para eventos globais, com diferenças
(timetz) de fuso. Ex: reuniões internacionais.
Texto text Sequência de ca- Alta. Flexível e eficiente para textos ’Campo descritivo’
racteres de compri- longos, como descrições de produtos.
mento variável
Texto varchar [ (n) ] Sequência de ca- Muito Alta. Melhor para limites de- ’Fulano Beltrano
racteres de compri- finidos, mais rápido para buscas. Fre- Silva’
mento variável até quentemente utilizado para campos de
‘n‘ nome de usuário.
Texto character [ (n) ] Sequência de ca- Média. Menos flexível, bom para cam- ’MG’
(char [ (n) ]) racteres de compri- pos de comprimento fixo. Ex: códigos
mento fixo de estado.
Lógico boolean (bool) Valor verdadeiro ou Muito Alta. Uso eficiente de armaze- true
falso namento, ideal para flags e status.
 17

Ferramentas de Modelagem Conceitual,

Lógica e Física de Banco de Dados

A modelagem de dados é viável sem a utilização de ferramentas computacionais, conhecidas como

CASE (Computer Aided Software Engineering). No entanto, é consensual que o uso dessas ferramentas
simplifica significativamente o processo, facilitando a modificação da estrutura de modelagem, mesmo
em fases avançadas do projeto, tornando o trabalho menos laborioso..

Autores reconhecidos no campo de modelagem de dados, como Carlos A. Heuser, têm explorado
e destacado a importância das ferramentas de modelagem para a construção de modelos Entidade-
Relacionamento (ER).

Carlos A. Heuser (2001), em sua obra "Projeto de Banco de Dados", enfatiza que as ferramentas
de modelagem são essenciais para o desenvolvimento eficiente e preciso de modelos de dados. Heuser
argumenta que essas ferramentas facilitam a criação de diagramas ER, que são cruciais para a visu-
alização e compreensão das relações entre diferentes entidades em um banco de dados. Além disso,
ele destaca que as ferramentas de modelagem ajudam a garantir a consistência e a integridade dos da-
dos desde o início do processo de design, o que é vital para a manutenção e evolução do banco de dados.

Atualmente, existem diversas ferramentas, muitas delas, permitindo desde a criação de diagramas ER
(entidade-relacionamento) que representam graficamente os dados e suas interações ao modelo físico
em SQL, facilitando a implementação no SGBD.

Para o desenvolvimento desta apostila, iremos utilizar o BRModelo, um software de código aberto
e gratuito voltado para o ensino de modelagem de banco de dados relacional amplamente utilizado no
meio acadêmico.

A ferramenta oferece uma interface intuitiva para a criação e manipulação de diagramas ER, pro-
porcionando ao usuário a capacidade de definir entidades, atributos, relacionamentos e restrições de
integridade de maneira visual e organizada, além de gerar automaticamente o código SQL para imple-
mentação.
1.7. TIPOS DE DADOS 18

Preparando o ambiente
Download e instalação do BRModelo
Para instalação do BRModelo é necessário que tenha o Java (preferencialmente, última versão) previa-
mente instalado.

Passo a Passo da instalação:

1. Acesse o site : <[Link]

2. Faça a instalação do arquivo: Aplicação brModelo 3.32 (3.3.2) - JAR - (java 8): [Link].

Figura 4 – Download BRModelo

3. Acesse o diretório em que está o download.

4. Execute o arquivo [Link].

Modelagem conceitual, lógica e física

Construiremos a modelagem e implementação de um banco de dados para uma biblioteca. Para isso,
utilizaremos o BRModelo para a criação dos diagramas de Entidade-Relacionamento (ER).

A ferramenta BRModelo tem um layout simples, de fácil navegação. Os artefatos estão na esquerda e
para configura-los individualmente, basta clicar cobre o artefato escolhido e as configurações do mesmo
abrirão na aba à direita da tela.
1.7. TIPOS DE DADOS 19

Figura 5 – Artefatos BRModelo

Criando a modelagem conceitual

A modelagem conceitual é a primeira fase do projeto de banco de dados, cujo objetivo é definir de forma
abstrata e independente do SGBD a estrutura e os relacionamentos entre os dados. O resultado dessa
fase é o Diagrama de Entidade-Relacionamento (DER).

Então, definiremos nossas entidades como:

1. Usuário:

• ID_usuario: Identificador único do usuário.

• Nome: Nome do usuário.
• Email: Endereço de e-mail do usuário.
• Telefone: Número de telefone do usuário.
• Endereco: Endereço do usuário.

2. Livro:

• ID_livro: Identificador único do livro.

• Titulo: Título do livro.
• Autor: Autor do livro.
• Editora: Editora do livro.
• Ano_publicação: Ano da publicação do livro.
• Genero: Gênero do livro.

3. Empréstimo:

• ID_emprestimo: Identificador único do empréstimo.

• Data_emprestimo: Data do empréstimo.
• Data_devolucao_prevista: Data da devolução prevista do empréstimo.
• Data_devolucao_real: Data da devolução real do empréstimo.

4. Multa:

• ID_multa: Identificador único da multa.

1.7. TIPOS DE DADOS 20

• Valor: Valor da multa.

Figura 6 – Biblioteca: Modelo conceitual

Relacionamentos:

• Usuário (1) —- (N) Empréstimo: Um usuário pode fazer um ou vários empréstimos. Cada
empréstimo pertence a um único usuário.

• Livro (0) —- (N) Empréstimo: Um livro pode ser emprestado nenhuma ou várias vezes. Cada
empréstimo envolve um único livro.

• Empréstimo (1) —- (0,1) Multa: Um empréstimo pode gerar nenhuma ou uma multa. Cada
multa está associada a um único empréstimo.

Criando a modelagem lógica

A modelagem lógica é a transformação do modelo conceitual em um modelo lógico, que é mais deta-
lhado e específico ao SGBD escolhido, mas ainda independente da implementação física. Nessa etapa,
as entidades e os relacionamentos são transformados em tabelas, e as chaves primárias e estrangeiras
são definidas.

Convertendo o modelo conceitual para o modelo lógico.

1.7. TIPOS DE DADOS 21

Figura 7 – Biblioteca: Conversão para o modelo lógico

Também é necessário definir os tipos de dados adequados para cada coluna das tabelas do banco de
dados. A escolha correta dos tipos de dados não só assegura a integridade e eficiência do banco, mas
também afeta diretamente o desempenho e a capacidade de armazenamento.

Figura 8 – Biblioteca: Modelo lógico: Onde definir os tipos de dados

Vamos aplicar os tipos de dados no contexto das tabelas da nossa biblioteca.

1.7. TIPOS DE DADOS 22

1. Usuário:

• ID_usuario: INTEGER
• Nome: VARCHAR
• Email: VARCHAR
• Telefone: VARCHAR
• Endereco: VARCHAR

2. Livro:

• ID_livro: INTEGER
• Titulo: VARCHAR
• Autor: VARCHAR
• Editora: VARCHAR
• Ano_publicação: TIMESTAMP
• Genero: VARCHAR

3. Empréstimo:

• ID_emprestimo: INTEGER
• Data_emprestimo: TIMESTAMP
• Data_devolucao_prevista: TIMESTAMP
• Data_devolucao_real: TIMESTAMP

4. Multa:

• ID_multa: INTEGER
• Valor: MONEY

Figura 9 – Biblioteca: Modelo lógico: Tipos de dados

1.7. TIPOS DE DADOS 23

Figura 10 – Biblioteca: Modelo Lógico

Criando a modelagem física

A modelagem física envolve a implementação real do modelo lógico no SGBD escolhido. Neste momento,
as tabelas, índices e constraints são criados no banco de dados.

Figura 11 – Biblioteca: Conversão modelo físico

O BRModelo gera automaticamente o código do modelo físico, porém, para inserção no SGBD é
necessaria algumas modificações no codigo, como parametrizar o tamanho dos campos e definições de
cada um deles.
 1.7. TIPOS DE DADOS 24

Código modelo físico:

1 CREATE TABLE Usuario (
2 ID_Usuario SERIAL PRIMARY KEY ,
3 Nome VARCHAR (255) ,
4 Email VARCHAR (255) ,
5 Telefone VARCHAR (255) ,
6 Endereco VARCHAR (255)
7 );
8
9 CREATE TABLE Livro (
10 ID_Livro SERIAL PRIMARY KEY ,
11 Autor VARCHAR (255) ,
12 Titulo VARCHAR (255) ,
13 Ano_publicacao TIMESTAMP ,
14 Editora VARCHAR (255) ,
15 Genero VARCHAR (255)
16 );
17
18 CREATE TABLE Emprestimo (
19 ID_Emprestimo SERIAL PRIMARY KEY ,
20 Data_emprestimo TIMESTAMP ,
21 D a ta _ d ev o l uc a o _r e a l TIMESTAMP ,
22 D a t a _ d e v o l u c a o _ p r e v i s t a TIMESTAMP ,
23 fk_ID_Usuario INTEGER ,
24 fk_ID_Livro INTEGER
25 );
26
27 CREATE TABLE Multa (
28 ID_Multa SERIAL PRIMARY KEY ,
29 Valor MONEY ,
30 fk_ID_Emprestimo INTEGER
31 );
32
33 ALTER TABLE Emprestimo ADD CONSTRAINT FK_Emprestimo_2
34 FOREIGN KEY ( fk_ID_Usuario )
35 REFERENCES Usuario ( ID_Usuario )
36 ON DELETE RESTRICT ;
37
38 ALTER TABLE Emprestimo ADD CONSTRAINT FK_Emprestimo_3
39 FOREIGN KEY ( fk_ID_Livro )
40 REFERENCES Livro ( ID_Livro )
41 ON DELETE CASCADE ;
42
43 ALTER TABLE Multa ADD CONSTRAINT FK_Multa_2
44 FOREIGN KEY ( fk_ID_Emprestimo )
45 REFERENCES Emprestimo ( ID_Emprestimo )
46 ON DELETE CASCADE ;
 25

2 Álgebra Relacional

2.1 Álgebra Relacional

A Álgebra Relacional é uma linguagem de consulta formal, porém procedimental, ou seja, o usuário dá
as instruções ao sistema para que o mesmo realize uma sequência de operações na base de dados para
calcular o resultado desejado.

A álgebra relacional recebia pouca atenção até a publicação do modelo relacional de dados de E.F
Codd, em 1970. Codd propôs a álgebra como uma base para linguagens de consulta em banco de dados.

A álgebra relacional é uma forma de cálculo sobre conjuntos ou relações ou de maneira simplista
sobre tabelas de um banco de dados relacional

O que significa estes comandos?

■ πnome_curso, carga_horaria (σano=2024 (Disciplina))

■ σdept=fisica (professor ▷◁ disciplina)

■ π[Link], [Link] (aluno × telefone)

Da maneira como está, não poderá ser interpretado, se não foi conhecida a simbologia relacionada aos
comandos.

A seguir apresentamos um paralelo entre a álgebra relacional e os comandos em SQL.

Tabela 3 – Álgebra Relacional vs Comandos SQL

Álgebra Relacional Comando SQL
1 Projeção select
2 Produto Cartesiano from
3 Seleção where
4 Junção join
5 Alias as

1. Projeção: pode ser entendida como uma operação que filtra as colunas de uma tabela;

2. Produto Cartesiano: Resulta em uma combinação de todas as tuplas entre as duas relações
(tabelas) de [Link] quando se necessita obter dados presentes em duas ou mais relações
(tabelas);

3. Seleção: Pode ser entendida como uma operação que filtra as linhas de uma tabela. É uma
operação unária, já que opera sobre um único conjunto de dados de entrada;

4. Junção: tem como objetivo unir duas tabelas, as quais possuem um atributo em comum. Este
tipo de operação é muito utilizado quando tratamos de relacionamentos com chaves estrangeiras.
Seleciona um subconjunto de registros;

5. alias: operadores de renomeação.

2.1. ÁLGEBRA RELACIONAL 26

Álgebra relacional → é a Linguagem formal para o modelo relacional.

Historicamente, a álgebra relacional foi desenvolvida antes da linguagem SQL.

Álgebra relacional: consiste em um conjunto de operações que aceitam uma ou duas relações (tabelas)
como entrada e produzem uma nova relação como seu resultado (Silberchartz/2020).

Definições:
Relação → conjunto não ordenado de tuplas
Atributo → São as colunas da tabela

Não existem tuplas duplicadas

Operações Básicas → Álgebra Relacional

■ Operações unárias

1. Projeção (π)
2. Seleção (σ)

■ Operações de Conjunto

1. União (∪)
2. Interseção (∩)
3. Diferença (−)
4. Produto Cartesiano (×)

■ Operações binárias

1. Junção (▷◁)
2. Divisão (/)

■ Outras Operações

1. Renomeação (ρ)

A seguir temos uma tabela com um resumo das operações de Álgebra Relacional.

Tabela 4 – Álgebra Relacional: Principais Operações

Símbolo Operação Sintaxe Exemplo
1 σ Seleção / Restrição σCondição (Tabela) ......
2 π Projeção πexpressões (Tabela) ......
3 ∪ União Tabela_1 ∪ Tabela_2 ......
4 ∩ Interseção Tabela_1 ∩ Tabela_2 ......
5 − Diferença Tabela_1 − Tabela_2 ......
6 x Produto Cartesiano Tabela_1 x Tabela_2 ......
7 |x| Junção Tabela_1 | x | Tabela_2 ......
8 ÷ Divisão Tabela_1 ÷ Tabela_2 .....
9 ρ Renomeação ρnome (Tabela) .....
10 ← Atribuição Variável ← Tabela .....
2.1. ÁLGEBRA RELACIONAL 27

2.1.1 σ Seleção/Restrição
Seleção (σ)

σAnoFab>2019 (TABELA_VEICULOS)

Placa Marca Modelo AnoFab

BEE4R22 Jeep Renegade 2016
ABC1C34 Fiat Palio 2019
BRA0S17 VW Gol 2020
ACI6J67 Toyota Hilux 2021
RIO2A18 Chevrolet Corsa 2000

Placa Marca Modelo AnoFab

BRA0S17 VW Gol 2020
ACI6J67 Toyota Hilux 2021

→ Comando equivalente em linguagem SQL a seleção (σ) é cláusula where.

→ É um recorte horizontal da tabela;

 2.1. ÁLGEBRA RELACIONAL 28

Exercício
Escreva algebricamente a MARCA e MODELO, de todos os táxis acima de 2019.

Placa Marca Modelo AnoFab

BEE4R22 Jeep Renegade 2016
ABC1C34 Fiat Palio 2019
BRA0S17 VW Gol 2020
ACI6J67 Toyota Hilux 2021
RIO2A18 Chevrolet Corsa 2000

πmarca,modelo (σAnoF ab>2019 (T ABELA_V EICU LOS))

2.1.2 π Projeção
Projeção (π)
π marca,modelo (VEICULOS)

Tabela 5 – Exemplo de Operação

Projeção: Tabela VEICULOS
placa marca modelo ano_fab
BEE4R22 Jeep Renegade 2016
ABC1C34 Fiat Palio 2019
BRA0S17 VW Gol 2020
ACI6J67 Toyota Hilux 2021
RIO2A18 Chevrolet Corsa 2000

Projeção é um recorte vertical, onde especifica-se as colunas. Neste exemplo foram selecionadas as
colunas marca e modelo.

Como resultado da projeção:

Tabela 6 – Resultado da Projeção

da Tabela VEICULOS
marca modelo
Jeep Renegade
Fiat Palio
VW Gol
Toyota Hilux
Chevrolet Corsa

O equivalente ao comando SQL SELECT, temos:

1 SELECT marca , modelo FROM VEICULO ;

Exercícios de Projeção
2.1. ÁLGEBRA RELACIONAL 29

1) Considere as seguintes relações:

Fornecedores(codf : inteiro, nome: string, endereco: string, cpd: inteiro)
Pecas(codp: inteiro, nome: string, cor: string)
Catalogo(codf: inteiro, codp: inteiro, preco: real)

codf: é uma chave estrangeira para Fornecedores

codp: é uma chave estrangeira para Pecas

a) π F [Link],F [Link] (F ornecedores)

b) π [Link],[Link] (Catalogo)

2.1.3 ∪ União
União (∪) → (C1 ∪ C2 )

Tabela 7 – C1
id_cliente nome
1242 João Silva
5490 Ronaldo Marques
00345 Ítalo Moreira

Tabela 8 – C2
idcliente nome
1242 João Silva
7954 Márcia Cristina
12654 Priscila Martins
00345 Ítalo Moreira

Tabela 9 – C1 ∪ C2
id_cliente nome
1242 João Silva
7954 Márcia Cristina
5490 Ronaldo Marques
12654 Priscila Martins
00345 Ítalo Moreira

→ Os duplicados serão retirados;

→ Exige que as tabelas envolvidas tenham o mesmo esquema;

2.1.4 ∩ Interseção
Interseção (∩) → (C1 ∩ C2 )

2.1.5 − Diferença
Diferença (−) → (C1 − C2 )
→ O que têm no primeiro e não têm no segundo
2.1. ÁLGEBRA RELACIONAL 30

Tabela 10 – C1
id_cliente nome
1242 João Silva
5490 Ronaldo Marques
00345 Ítalo Moreira

Tabela 11 – C2
id_cliente nome
1242 João Silva
7954 Márcia Cristina
12654 Priscila Martins
00345 Ítalo Moreira

Tabela 12 – C1 ∩ C2
id_cliente nome
1242 João Silva
00345 Ítalo Moreira

Tabela 13 – C1
idcliente nome
1242 João Silva
5490 Ronaldo Marques
00345 Ítalo Moreira

Tabela 14 – C2
idcliente nome
1242 João Silva
7954 Márcia Cristina
12654 Priscila Martins
00345 Ítalo Moreira

Tabela 15 – C1 − C2
idcliente nome
5490 Ronaldo Marques

2.1.6 x Produto Cartesiano

Produto Cartesiano (×) → (C1 × C2 )
→ todos com todos...

Tabela 16 – C1
Placa Marca
BRA0S17 VW
ACI6J67 Toyota

→ SE NÃO COLOCO A CLAUSULA WHERE NO SELECT, ISSO É UM PRODUTO CARTESIANO

2.1. ÁLGEBRA RELACIONAL 31

Tabela 17 – C2
id_cliente nome
1242 João Silva
5490 Ronaldo Marques
00345 Ítalo Moreira

Tabela 18 – C1 × C2
Placa Marca idcliente nome
BRA0S17 VW 1242 João Silva
BRA0S17 VW 5490 Ronaldo Marques
BRA0S17 VW 00345 Ítalo Moreira
ACI6J67 Toyota 1242 João Silva
ACI6J67 Toyota 5490 Ronaldo Marques
ACI6J67 Toyota 00345 Ítalo Moreira

Por exemplo:
SELECT [Link], [Link]
FROM aluno, telefone;

Na url, a seguir, está disponível uma aplicação (Relax) de Álgebra Relacional, onde podem ser testados
os comandos escritos em termos de álgebra relacional.
url: <[Link]

2.1.7 | x | Junção
Junção (▷◁)
C1 ▷◁θ C2
Onde θ é a condição de junção;

É uma espécie de produto cartesiano, com uma certa condição.

Pode ser qualquer condição (não necessariamente a chave primária com a chave estrangeira)

Tabela 19 – C1
Placa Marca Modelo AnoFab fk_idcliente
BEE4R22 Jeep Renegade 2016 1242
ABC1C34 Fiat Palio 2019 7954
BRA0S17 VW Gol 2020 5490
ACI6J67 Toyota Hilux 2021 12654
RIO2A18 Chevrolet Corsa 2000 00345

C1 ▷◁idcliente=f k_idcliente C2

C1 ▷◁θ C2
θ = {=, ̸=, ≤, ≥, >, <}
2.1. ÁLGEBRA RELACIONAL 32

Tabela 20 – C2
idcliente nome
1242 João Silva
7954 Márcia Cristina
5490 Ronaldo Marques
12654 Priscila Martins
00345 Ítalo Moreira

Tabela 21 – C1 ▷◁θ C2
Placa Marca Modelo AnoFab fkidcliente idcliente nome
BEE4R22 Jeep Renegade 2016 1242 1242 João Silva
ABC1C34 Fiat Palio 2019 7954 7954 Márcia Cristina
BRA0S17 VW Gol 2020 5490 5490 Ronaldo Marques
ACI6J67 Toyota Hilux 2021 12654 12654 Priscila Martins
RIO2A18 Chevrolet Corsa 2000 00345 00345 Ítalo Moreira

2.1.8 / Divisão
Divisão (/)
→ Sempre inclui a frase para todos...

Exemplo:

Liste o número do cliente que foram atendidos por todos os vendedores....

nr_cliente cod_vendedor
9 12
1 4 cod_vendendor
nr_cliente
1 66 66
1
4 3 4
5 11
8 74

2.1.9 ρ Renomeação
Renomeação (ρ)
→ o operador de renomeação é utilizado para alterar o nome das colunas de uma tabela. Utilizado para
relacionamentos onde possam surgir nomes iguais para as colunas, como num relacionamento da tabela
com ela mesma.

ρ(C1 ,C2 ,..,Cn )(nome_tabela)

Onde {C} são os novos nomes das colunas e nome_tabela é a relação.

Exemplo:

SELECT x as c1 ,y as c2 , z as c3 FROM nome_tabela

2.1. ÁLGEBRA RELACIONAL 33

2.1.10 ← Atribuição
→ a operação de atribuição tem por objetivo associar um identificador a uma relação derivada de
uma expressão relacional. Essa associação simplifica a referência futura a essa relação, eliminando a
necessidade de reescrever a expressão original.

variavel ← tabela(expressão_relacional)

Exemplo:

Veiculos_Recentes ← σAnoFab>=2020 (C1 ▷◁[Link]=[Link] C2)

• σAnoFab>=2020 : Operação de seleção que filtra as tuplas onde o atributo AnoFab é maior igual a
2020.

• C1 ▷◁[Link]=[Link] C2: Junção entre as relações C1 (Veículos) e C2 (Clientes) baseada na

condição de que [Link] seja igual a [Link].

• Veiculos_Recentes: Nome dado à nova relação resultante da operação de seleção.

Após a operação de atribuição, a relação Veiculos_Recentes conterá apenas os veículos fabricados a

partir de 2020.

Tabela 22 – Veículos Recentes

Placa AnoFab idcliente nome
BRA0S17 2020 5490 Ronaldo Marques
ACI6J67 2021 12654 Priscila Martins
 34

3 Sistema de Gerenciamento de Bases

de Dados (SGBD)

3.1 Sistema de Gerenciamento de Bases de Dados (SGBD) ou Data

Base Management System (DBMS)
Um banco de dados requer um programa para sua utilização, estes são conhecidos como sistema de
gerenciamento de banco de dados (SGBD). Um SGBD serve como uma interface entre o banco de da-
dos e seus usuários finais ou sistemas que o utilizam, e permite a criação, gerenciamento, modificação,
manipulação e exclusão dos dados de forma organizada e otimizada, além de, facilitar a supervisão e o
controle do banco de dados, permitindo uma variedade de operações administrativas, como monitora-
mento de desempenho, ajuste, backup e recuperação.

O SGBD desempenha também funções de segurança, protegendo a base de dados de acessos não
autorizados e contra ameaças acidentais ou intencionais. Nele são impostas regras que definem quais
usuários podem ter acesso à base de dados e, dentro dos usuários autorizados, a quais arquivos po-
dem acessar e que tipos de operações podem realizar (leitura, inserção, atualização, exclusão, etc.)
para assegurar a segurança, confiabilidade e integridade dos dados. Existem quatro tipos básicos de
segurança:

• Segurança de rede: O firewall é um separador ou restritor do tráfego de rede, que pode ser
configurado para impor políticas de segurança em uma organização, aumentando o nível de se-
gurança de um sistema operacional e sendo a primeira linha de defesa na segurança do banco de
dados.

• Gerenciamento de acesso: O gerenciamento de acesso baseia-se em três pilares. O primeiro é a

autenticação, que consiste no processo de provar que o usuário é quem afirma ser, inserindo o ID
de usuário e a senha corretos. O segundo é a autorização, que permite acessos a determinados
objetos e operações, como leitura e inserção, mas não alteração ou exclusão de dados. Por fim, o
controle de acesso atribui permissões de nível a um usuário; por exemplo, a segurança de nível
de linha permite que os administradores do banco de dados restrinjam o acesso de gravação e
exclusão a linhas de dados com base na identidade do usuário.

• Proteção contra ameaças: A detecção de ameaças investiga atividades anômalas no banco de

dados que indicam alguma possível ameaça ao banco de dados e informa ao administrador.
Proteção de informações: A criptografia protege os dados confidenciais, convertendo-os para
um formato alternativo, e apenas as partes autorizadas podem decifrá-los e acessá-los. O backup
do banco de dados e os arquivos de log são extremamente importantes para restaurar o banco de
dados em caso de violação, perda de dados ou falha de segurança. Além disso, os dados devem
estar fisicamente seguros, limitando estritamente o acesso ao servidor físico e aos componentes de
hardware. Geralmente, bancos de dados locais usam salas trancadas com acesso restrito e limitam
o acesso ao arquivo de backup, mantendo-os em um local externo e seguro.

Os SGBDs também devem assegurar a verificação das restrições de integridade, de forma a manter os
dados sempre válidos, diminuindo a redundância e maximizando a consistência dos dados. Um aspecto
importante da manutenção da integridade é a gestão de transações. Uma transação consiste em um
conjunto de ações efetuadas por um usuário ou aplicação, por exemplo, uma operação de transferência de
dinheiro entre duas contas. Se a transação for interrompida antes do fim (falha de energia, problemas
no disco etc.), o sistema deve evitar um estado de inconsistência, acionando o rollback, que é um
3.2. ATORES DE UM BANCO DE DADOS 35

mecanismo que desfaz o que foi feito até o momento do problema e devolve a base de dados ao seu
estado de consistência.

3.2 Atores de um banco de dados

Um banco de dados pode possuir diversos usuários, cada qual com uma necessidade específica e um
nível de envolvimento diferente com os dados

3.2.1 DBA - Database Administrator

DBA (Database Administrator ou Administrador de Banco de Dados) é o cargo mais especializado e
mais conhecido quando o assunto é banco de dados. O DBA é responsável pela instalação, sustentação,
manutenção, performance e segurança do banco de dados. Também é responsável por conceder acesso
à base de dados, coordenar e monitorar seu uso.

3.2.2 Analistas de bancos de dados (projetistas)

O analista de banco de dados projetista é responsável pela estrutura, identificando os dados que serão
armazenados, escolhendo a estrutura apropriada para o armazenamento, implementando novos processos
de software, métodos de acesso e dimensionamento de hardware, além de manter a segurança conforme
as políticas da empresa.

3.2.3 Analistas de sistemas e programadores de aplicações

Os analistas de sistemas determinam os requisitos dos usuários finais e desenvolvem especificações
para transações que atendam a esses requisitos. Os programadores implementam essas especificações,
desenvolvendo, testando, depurando, documentando e dando manutenção ao produto.

3.2.4 Usuários finais

São os profissionais que precisam ter acesso à base de dados para consultar, modificar ou gerar relatórios
dos dados.
O processo histórico de informatização trouxe consigo uma mudança na forma como as organizações
gerenciam seus dados, e os sistemas de gerenciamento de banco de dados (SGBDs) proporcionam
integração, eficiência e segurança, moldando a maneira como interagimos com a informação em um
mundo cada vez mais orientado a dados. Com essa evolução, surgiram diversos SGBDs, muitos deles
com similaridades, mas cada um apresentando diferenciais, seja em funcionalidades ou em comandos
[Link] acordo com o site DB-Engines , em 18 de julho de 2024, os dez SGBDs mais populares,
nesta ordem, são:

1. Oracle 6. Redis

2. MySQL 7. Snowflake

3. Microsoft SQL Server 8. Elasticsearch

4. PostgreSQL 9. IBM DB2

5. MongoDB 10. SQLite

 36

Preparando o ambiente

Nesta apostila, utilizaremos o banco de dados PostgreSQL e o sistema de gerenciamento de banco de

dados PGAdmin4, plataforma de software livre, que possui uma interface intuitiva e amigável, permitindo
ao usuário realizar tarefas de administração e desenvolvimento do banco de dados, fornecendo uma
variedade de recursos e funcionalidades.

Configuração do ambiente PostGreSql

Download e Instalação
1. Acesse o site:
Postgre SQL

2. Escolha a versão 16.3 para o seu sistema operacional. Para ’Windows x86-64 ’, clique no ícone de
download.

Figura 12 – Download PostgreSQL

3. Após o download, execute o instalador. A primeira tela que aparecerá será a tela de boas-vindas
do Setup. Clique em ’Next’.

4. Especifique o diretório onde o PostgreSQL será instalado.

O caminho padrão é C:\Program Files\PostgreSQL\16.
Clique em ’Next’.

5. Selecione os componentes que deseja instalar. Deixe marcados os componentes padrão: Post-
greSQL Server, pgAdmin 4, Stack Builder e Command Line Tools. Clique em ’Next’.

6. Especifique o diretório onde os dados do PostgreSQL serão armazenados. O caminho padrão é

C:\Program Files\PostgreSQL\16\data. Clique em ’Next’.

7. A instalação está pronta para começar. Clique em ’Next’ para iniciar a instalação.

8. Após a conclusão da instalação, a tela de conclusão será exibida. Deixe a opção ’Launch Stack
Builder at exit’ marcada apenas se desejar baixar e instalar ferramentas adicionais. Clique em
’Finish’ para concluir.
3.2. ATORES DE UM BANCO DE DADOS 37

Figura 13 – Instalação PostgreSQL

Figura 14 – Instalação PostgreSQL

Executando o modelo físico

1. Criar uma nova base de dados:

• No pgAdmin 4, expanda o servidor PostgreSQL 16 e clique com o botão direito em ’Data-

bases’.
• Selecione ’Create’ e depois ’Database...’.

2. Configurar a nova base de dados:

• Na janela ’Create - Database’, insira o nome da base de dados, por exemplo, "Biblioteca X".
3.2. ATORES DE UM BANCO DE DADOS 38

Figura 15 – Instalação PostgreSQL

Figura 16 – Instalação PostgreSQL

• Clique em ’Save’ para criar a base de dados.

3. Criar tabelas na nova base de dados:

• Com a base de dados "Biblioteca X"selecionada, clique com o botão direito e selecione
’CREATE Script’.

4. Definir as tabelas:

• Na janela do editor de scripts SQL, insira os comandos SQL para criar as tabelas. O comando
gerado no capítulo 1.7, código do modelo físico dos dados.
3.2. ATORES DE UM BANCO DE DADOS 39

Figura 17 – Instalação PostgreSQL

Figura 18 – Instalação PostgreSQL

• Clique no ícone de ’Play ’ para executar o script e criar as tabelas.

• A janela de saída de dados exibirá uma mensagem confirmando que as tabelas foram criadas
com sucesso.
3.2. ATORES DE UM BANCO DE DADOS 40

Figura 19 – Biblioteca: Criando modelo físico PostgreSQL

Figura 20 – Biblioteca: Configurando a base de dados

3.2. ATORES DE UM BANCO DE DADOS 41

Figura 21 – Biblioteca: Configurando a base de dados

Figura 22 – Biblioteca: Configurando a base de dados

 42

4 Linguagem SQL

A linguagem SQL ("linguagem de consulta estruturada") foi desenvolvida no início da década de 70 no

IBM San Jose Research Laboratory. Inicialmente chamada SEQUEL, foi criada como parte do projeto
System R, liderado por Raymond F. Boyce e Donald D. Chamberlin, para demonstrar a viabilidade do
modelo relacional de dados proposto por Edgar F. Codd na mesma década. A SEQUEL, renomeada
para SQL, foi projetada para ser intuitiva e eficiente na manipulação de dados relacionais.

Em 1986, o American National Standards Institute (ANSI) publicou o primeiro padrão oficial para
SQL, seguido pela International Organization for Standardization (ISO). Desde então, a SQL passou
por várias revisões, incluindo SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011 e, o mais
recente, SQL:2016, incorporando, a cada revisão, novas funcionalidades e melhorias de desempenho.
Dessa forma, consolidou-se como a linguagem padrão para consultas e gerenciamento de dados em
sistemas relacionais, adotada por diversos Sistemas Gerenciadores de Banco de Dados (SGBDs). Cada
um desses SGBDs tem suas próprias implementações da linguagem e pode variar a sintaxe de acordo
com a plataforma.

4.1 Linguagem SQL

As instruções SQL utilizadas para manipular os dados armazenados são divididas em quatro subconjun-
tos, cada um realizando comandos de naturezas específicas.

4.1.1 Data Definition Language

A Data Definition Language(DDL) é conjunto fundamental a criação de um banco de dados, fornece
comandos para definição e modificação da estrutura do banco e suas tabelas. Composta por quatro
comandos básicos:
• CREATE: Como vimos no capítulo anterior o ’CREATE’ é utilizado para criar novas tabelas, visões
e outros objetos de banco de dados.
Sintaxe:
1 CREATE TABLE < NOME_TABELA >
2 ( < ATRIBUTOS DA TABELA >) ;

Como criamos ao final do Capítulo 1 no nosso modelo de banco de dados da Biblioteca(1.7).

• ALTER: Empregado para modificar a estrutura de objetos de banco de dados existentes, como
tabelas.
Sintaxe:
1 ALTER TABLE < TABELA >
2 ADD < TABELA > < TIPO DE DADO >;

Exemplo:
1 ALTER TABLE Usuario
2 ADD data_nascimento TIMESTAMP ;

• DROP: Este comando é utilizado para remover objetos definidos no banco de dados, como tabelas,
índices ou até mesmo o banco de dados criado. Este comando não permite o ROLLBACK, portanto,
a exclusão é definitiva.
Sintaxe:
4.1. LINGUAGEM SQL 43

1 DROP TABLE < TABELA >;

Exemplo:
1 DROP TABLE Autor ;

• TRUNCATE: Remove todos os registros de uma tabela, liberando o espaço ocupado por esses
registros. Este comando não permite ROLLBACK
Sintaxe:
1 TRUNCATE TABLE < TABELA >;

Exemplo:
1 TRUNCATE TABLE Autor ;

4.1.2 Data Manipulation Language

Os comandos Data Manipulation Language(DML) são instruções de manipulação de dados em tabelas,
abrangendo operações como inserção, atualização e exclusão de registros em uma tabela.

• INSERT: Insere novos dados em uma tabela.

Sintaxe:
1 INSERT INTO < TABELA > ( CAMPO1 , CAMPO2 , CAMPO3 ,...)
2 VALUES ( < VALOR1 > , < VALOR2 > , < VALOR3 > ,...) ;

Exemplo:
1 INSERT INTO Usuario ( Nome , Email , Endereco , Telefone ) VALUES
2 ( ' Gustavo Ribeiro ' , ' gustavo . ri be ir o@ bi bli ot ec a . com ' , ' Rua da Bahia ,
0068 ' , ' 31123123523 ') ;

O código de inserção para desenvolvimento das atividades está disponibilizado no repositório pú-
blico do CGA no GitHub.

Clique aqui: Apostila de Banco de Dados CGA

Ou acesse pela URL:

<[Link]

• UPDATE: Atualiza dados existentes em uma tabela.

Sintaxe:
1 UPDATE < TABELA >
2 SET < CAMPO > = < VALOR > , < CAMPO > = < VALOR > ,...
3 WHERE < CONDICAO >;

Exemplo:
1 UPDATE Usuario u
2 SET u . Endereco = ' Rua dos Guajajaras , 0070 ' ,u . Telefone = ' 31123123524
'
3 WHERE u . Nome = ' Gustavo Ribeiro '
4 AND u . Telefone = ' 31123123523 ' ;
4.2. FUNÇÕES DQL 44

• DELETE: Exclui registros específicos ou todos registro de uma tabela. Permite rollback, portanto,
de fácil recuperação em caso de exclusão errônea.
Sintaxe:
1 DELETE FROM < TABELA >
2 WHERE < CONDICAO >;

Exemplo:
1 DELETE FROM Usuario
2 WHERE Nome = ' Gustavo Ribeiro '
3 AND Telefone = ' 31123123524 ';

4.1.3 Data Control Language

Data Control Language(DCL) é o conjunto de comandos que fazem o cadastramento de usuários e
determinam seu nível de acesso para objetos no banco de dados. Os principais comandos são:

• GRANT: Concede permissões de acesso aos usuários.

Sintaxe:
1 GRANT < COMANDO > , < COMANDO >... ON < TABELA > TO < USUARIO >;

Exemplo:
1 GRANT SELECT , INSERT ON Livro TO ' usuario '@ ' localhost ';

• REVOKE: Remove as permissões de acesso.

Sintaxe:
1 REVOKE < COMANDO > , < COMANDO >... ON < TABELA > TO < USUARIO >;

Exemplo:
1 REVOKE DELETE , UPDATE ON Livro TO ' usuario '@ ' localhost ';

4.1.4 Data Query Language

A Linguagem de Consulta de Dados (Data Query Language, DQL) é uma ferramenta essencial na
manipulação e na análise de dados dentro de sistemas de gestão de banco de dados.

4.2 Funções DQL

A DQL é a função que mais utilizamos no SQL, enquanto Analista de Dados. Dedicada exclusivamente
à consulta e à recuperação de informações de bancos de dados relacionais. A principal ferramenta da
DQL é o comando SELECT, ponto de início para extrair dados dos bancos de forma precisa e eficiente.
A DQL emprega uma série de cláusulas, funções, e operadores que aprimoram a capacidade de filtragem
e manipulação das consultas.

A seguir, apresentamos os principais componentes e funcionalidades da DQL.

 4.2. FUNÇÕES DQL 45

4.2.1 Funções básicas

[Link] Select
O comando SELECT, cuja tradução direta do inglês é "selecionar", é essencial na linguagem SQL, que
é utilizada para manipulação e consulta de dados em bancos de dados. Este comando é utilizado para
especificar as colunas que desejamos recuperar em uma consulta. Ele é invariavelmente acompanhado
pelo comando FROM, que indica a tabela específica dentro do banco de dados de onde os dados serão
extraídos.

Logo, a estrutura básica de uma consulta SQL inicia com estas duas palavras-chave, formando a base
para a recuperação de dados. Por exemplo, para buscar gênero literário em uma tabela de Livros, o
comando seria:
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >;

Exemplo:
1 SELECT genero FROM Livro
2 LIMIT 10;

[Link] Limit
O comando LIMIT é utilizado para especificar o número máximo de registros que devem ser retornados
em uma consulta. Controla a quantidade de dados que uma consulta retorna, especialmente útil em
situações com grandes volumes de dados, onde desejamos limitar a quantidade de informações retornadas
para uma visualização mais gerenciável ou para testar consultas durante o desenvolvimento.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 LIMIT < VALOR > ;

Exemplo:
1 SELECT Autor FROM Livro
2 LIMIT 10;

[Link] Where
O comando WHERE em SQL filtra registros, permitindo que o usuário especifique condições que os dados
devem satisfazer para serem incluídos no resultado de uma consulta. Este comando limita os resultados
apenas aos registros que atendem aos critérios especificados.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < CONDICAO >;

Exemplo:
1 SELECT Titulo FROM Livro
2 WHERE Livro . Id_livro = 1;

[Link] Operadores Comparação

Os operadores de comparação em SQL são usados para formular condições que comparam valores em
uma consulta. São eles:
4.2. FUNÇÕES DQL 46

• Igual (=)
Verifica se os valores de ambos os lados são iguais.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > = < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) = 1812;

• Diferente (!= ou <>)

Verifica se valores comparados são diferentes.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > != < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) != 1812;

• Maior que (>)

Verifica se o valor à esquerda do operador é maior que o valor à direita.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > > < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) > 1812;

• Menor que (<)

Verifica se o valor à esquerda do operador é menor que o valor à direita.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > < < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) < 1812;

• Maior ou igual a (>=)

Verifica se o valor à esquerda do operador é maior ou igual ao valor à direita.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > >= < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) >= 1812;
4.2. FUNÇÕES DQL 47

• Menor ou igual (<=)

Verifica se o valor à esquerda do operador é menor ou igual ao valor à direita.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > <= < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) <= 1812;

[Link] Operadores Lógicos

Os operadores lógicos são utilizados para combinar duas ou mais condições em uma única cláusula
WHERE. São eles:

• AND
Operador AND (em português, "e") garante que todas condições sejam verdadeiras simultanea-
mente.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < CONDICAO >
3 AND < CONDICAO >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) = 1812
3 AND l . editora = ' Abril ';

• OR
Operador AND (em português, "ou") retorna caso ao menos uma das condições sejam verdadeiras.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < CONDICAO >
3 OR < CONDICAO >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) = 1812
3 OR extract ( year from l . ano_publicacao ) = 1904;

• LIKE
Realizas buscas por padrão (pattern matching) em dados de tipo texto. Este operador é frequen-
temente usado com caracteres curinga, como ’ %’ que representa qualquer sequência de caracteres
e ’_’ que representa um único caractere.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > LIKE ' < VALOR > ';

Exemplo:
4.2. FUNÇÕES DQL 48

1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l

2 WHERE l . titulo LIKE ' Peter % ';

• IN
Este operador permite específicar multiplos valores, como uma lista, sendo ao menos um dos
valores, verdadeiro.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > IN ( < VALOR > , < VALOR >) ;

Exemplo:
1 SELECT l . titulo , l . ano_publicacao , l . editora FROM Livro l
2 WHERE l . id_livro IN (2 ,9 ,45 ,60 ,78) ;

• NOT
Inverte o resultado de uma condição, selecionando registros onde a condição NÃO é verdadeira.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > NOT IN ( < VALOR > , < VALOR >) ;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE l . id_livro NOT IN (2 ,9 ,45 ,60 ,78) ;

• BETWEEN
Em português, "entre", este operador retorna valores dentro de um intervalo especificado.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > BETWEEN < VALOR > AND < VALOR >;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE extract ( year from l . ano_publicacao ) BETWEEN 1865 AND 1904;

• NULL
Em SQL, NULL representa um valor desconhecido ou ausente. Para retornar um campo NULL,
não usamos outros operadores, como ’=’, pois NULL não é um valor, mas um estado. Portanto,
deve-se usar ’IS NULL’ ou ’IS NOT NULL’.
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > IS NULL ;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE l . autor IS NULL ;
 4.2. FUNÇÕES DQL 49

[Link] ORDER BY
A função ORDER BY como próprio nome indica, orderna os resultados de uma consulta com base em
uma ou mais colunas, em ordem ascendente(ASC) ou descendente(DESC).
Sintaxe:
1 SELECT < COLUNA > FROM < TABELA >
2 ORDER BY < COLUNA > ASC ;

Exemplo:
1 SELECT l . titulo , l . autor , l . ano_publicacao , l . editora FROM Livro l
2 WHERE l . autor IS NULL
3 ORDER BY l . ano_publicacao ASC ;

4.2.2 Funções intermediarias

[Link] Agregação
Funções de agregação são usadas para realizar cálculos em um conjunto de valores e retornam um único
valor como resultado. São elas:

• COUNT( )
Funciona como um contador, contando o número de linhas em uma coluna específica.
Sintaxe:
1 SELECT COUNT ( < COLUNA >) A FROM < TABELA >;

Exemplo:
1 SELECT COUNT ( l . id_livro ) FROM Livro l
2 WHERE l . autor IS NULL ;

• SUM( )
Esta função soma os valores em uma determinada coluna. Ao contrário do COUNT, o SUM deve
ser usado exclusivamente em colunas que contenham valores numéricos. Valores nulos não
são considerados.
Sintaxe:
1 SELECT SUM ( < COLUNA >) , < COLUNA > FROM < TABELA >;

Exemplo:
1 SELECT SUM ( m . valor ) FROM Multa m
2 WHERE id_emprestimo IN (8 ,21 ,32 ,47)

• MAX( ) /MIN( )
Retorna o maior(MAX) ou menor(MIN) valor de uma coluna, ignorando os valores nulos.
Sintaxe:
1 SELECT MAX ( < COLUNA >) , MIN ( < COLUNA >) FROM < TABELA >;

Exemplo:
1 SELECT MAX ( m . valor ) FROM Multa m
2 WHERE id_emprestimo IN (8 ,21 ,32 ,47)
 4.2. FUNÇÕES DQL 50

• AVG
Calcula a média dos valores numéricos de uma coluna. Assim como o SUM, deve ser usado
exclusivamente em colunas que contenham valores numéricos.
Sintaxe:
1 SELECT AVG ( < COLUNA >) FROM < TABELA >;

Exemplo:
1 SELECT AVG ( m . valor ) FROM Multa m
2 WHERE id_emprestimo IN (8 ,21 ,32 ,47)

[Link] GROUP BY
Esta função especifica que a busca particiona linhas de resultados em grupos, com base em seus valores
em uma ou várias colunas. Geralmente, o agrupamento é usado quando aplicamos alguma das funções
de agregação.
Sintaxe:
1 SELECT COUNT ( < COLUNA >) , < COLUNA > FROM < TABELA >
2 GROUP BY < COLUNA >;

Exemplo:
1 SELECT COUNT ( l . id_livro ) , l . genero FROM Livro l
2 GROUP BY l . genero ;

[Link] HAVING
Filtra os grupos criados pelo GROUP BY, permitindo especificar condições que os grupos devem satisfazer
para serem incluídos no resultado final da busca.
Sintaxe:
1 SELECT COUNT ( < COLUNA >) , < COLUNA > FROM < TABELA >
2 GROUP BY < COLUNA >
3 HAVING < COLUNA > < OPERADOR > < VALOR >

Exemplo:
1 SELECT COUNT ( l . id_livro ) , l . genero FROM Livro l
2 GROUP BY l . genero
3 HAVING l . genero = ' Aventura ';

[Link] CASE
Estrutura condicional, equivalente ao (IF-ELSE/SE-SENÃO em outras linguagens de programação, que
permite executar diferentes cálculos ou formatar dados de diferentes maneiras com base em condições
especificadas.
Sintaxe:
1 CASE
2 WHEN < CONDICAO 1 > THEN < RESULTADO 1 >
3 WHEN < CONDICAO 2 > THEN < RESULTADO 2 >
4 ...
5 ELSE < RESULTADO FINAL >
6 END AS < NOME_COLUNA >

Exemplo:
 4.2. FUNÇÕES DQL 51

1 SELECT e . id_usuario ,
2 e . id_livro ,
3 e . data_devolucao_real ,
4 CASE
5 WHEN e . d a t a_ d e vo l u ca o _ re a l > e . d a t a _ d e v o l u c a o _ p r e v i s t a THEN ' Em
atraso , gerar multa ' ELSE ' Recebido '
6 END AS status_devolucao
7 FROM Emprestimo e
8 WHERE extract ( year from data_emprestimo ) = 2023

[Link] DISTINCT
Esta função remove duplicatas nos resultados de uma consulta, sendo útil para listar valores distintos
de uma coluna.
Sintaxe:
1 SELECT DISTINCT < COLUNA > FROM < TABELA >
2 WHERE < COLUNA > < OPERADOR > < VALOR >

Exemplo:
1 SELECT DISTINCT ( l . autor ) FROM Livro l
2 WHERE l . editora = ' Abril '

[Link] JOIN
Até o momento, trabalhamos apenas com uma tabela por vez. O verdadeiro poder do SQL, entretanto,
vem em trabalhar com dados de múltiplas tabelas ao mesmo tempo.

As tabelas apresentadas até agora fazem parte do mesmo esquema em um banco de dados relacional.
O termo “banco de dados relacional” refere-se ao fato de que as tabelas dentro dele “se relacionam”
entre si – elas contêm identificadores comuns que permitem que informações de múltiplas tabelas sejam
facilmente combinadas.

Junções externas vs. Junções internas

Ao executar uma junção interna(INNER), as linhas de qualquer tabela que não correspondam na outra
tabela não serão retornadas. Em uma junção externa(OUTER), linhas sem correspondência em uma ou
ambas as tabelas podem ser retornadas.

Vamos analisar abaixo, cada um dos joins:

4.2. FUNÇÕES DQL 52

• INNER JOIN

O INNER JOIN retorna registros que são comuns às duas tabelas desde que a chave de ligação
entre as tabelas atenda a condição estabelecida.

Figura 23 – Representação Inner Join

Sintaxe:
1 SELECT < COLUNA > , ... FROM < TABELA A >
2 INNER JOIN < TABELA B > ON < COLUNA A > < OPERADOR > < COLUNA B >

Exemplo:
1 SELECT u . nome ,
2 u . telefone ,
3 e . data_emprestimo ,
4 e . data_devolucao_prevista ,
5 e . d a t a_ d e vo l u ca o _ re a l
6 FROM Usuario u
7 INNER JOIN Emprestimo e
8 ON u . id_usuario = e . id_usuario
9 WHERE u . nome LIKE ' Luiza % '
4.2. FUNÇÕES DQL 53

• LEFT [OUTER] JOIN

Conhecido também apenas como LEFT JOIN, esta junção retorna todos os registros da tabela à
esquerda (Tabela A), e registros correspondentes na tabela à direita(Tabela B).

Figura 24 – Representação Left [Outer] Join

Sintaxe:
1 SELECT < COLUNA > ,...
2 FROM < TABELA A >
3 LEFT JOIN < TABELA B >
4 ON < COLUNA A > < OPERADOR > < COLUNA B >

Exemplo:
1 SELECT e . id_emprestimo ,
2 e . data_emprestimo ,
3 e . data_devolucao_prevista ,
4 e . data_devolucao_real ,
5 m . valor
6 FROM Emprestimo e
7 LEFT JOIN Multa m
8 ON e . id_emprestimo = m . id_emprestimo
9 WHERE m . valor > 2;
4.2. FUNÇÕES DQL 54

• RIGHT [OUTER] JOIN

O RIGHT JOIN retorna todos os registros da tabela á direita (Tabela B) e registros correspondentes
na tabela à esquerda(Tabela A).

Figura 25 – Representação Right [Outer] Join

Sintaxe:
1 SELECT < COLUNA > ,...
2 FROM < TABELA A >
3 LEFT JOIN < TABELA B >
4 ON < COLUNA A > < OPERADOR > < COLUNA B >

Exemplo:
1 SELECT l . id_livro ,
2 l . titulo ,
3 l . autor ,
4 l . ano_publicacao ,
5 e . data_emprestimo ,
6 e . data_devolucao_prevista ,
7 e . d a t a_ d e vo l u ca o _ re a l
8 FROM Livro l
9 RIGHT JOIN Emprestimo e
10 ON l . id_livro = e . id_livro
11 WHERE extract ( year from l . ano_publicacao ) = 1812;
4.2. FUNÇÕES DQL 55

• FULL [OUTER] JOIN

Esta junção retorna todos os registro de ambas as tabelas, sejam correspondidas ou não. Quando
não existem linhas correspondentes para a linha da tabela esquerda, as colunas da tabela direita
serão nulas. Da mesma forma ocorrerá caso inverso.

Figura 26 – Representação Full [Outer] Join

Sintaxe
1 SELECT < COLUNA > ,...
2 FROM < TABELA A >
3 FULL JOIN < TABELA B >
4 ON < COLUNA A > < OPERADOR > < COLUNA B >

Exemplo:
1 SELECT
2 u . nome ,
3 u . email ,
4 u . telefone ,
5 e . data_emprestimo ,
6 e . data_devolucao_prevista ,
7 e . d a t a_ d e vo l u ca o _ re a l
8 FROM Usuario u
9 FULL JOIN Emprestimo e
10 ON u . id_usuario = e . id_usuario
11 ORDER BY u . id_usuario , e . id_emprestimo ;

A junção do FULL [OUTER] JOIN nos permite destacar essas discrepâncias facilmente. O co-
mando pode ser ajustado para inclução uma cláusula WHERE que filtra apenas os registros que não
possuem correspondência perfeita entre as tabelas.
Sintaxe:
1 SELECT < COLUNA > ,...
2 FROM < TABELA A >
3 FULL JOIN < TABELA B >
4 ON < COLUNA A > < OPERADOR > < COLUNA B >
5 WHERE < COLUNA A > IS NULL OR < COLUNA B > IS NULL ;
4.2. FUNÇÕES DQL 56

Exemplo:
1 SELECT
2 u . nome ,
3 u . email ,
4 u . telefone ,
5 e . data_emprestimo ,
6 e . data_devolucao_prevista ,
7 e . d a t a_ d e vo l u ca o _ re a l
8 FROM Usuario u
9 FULL JOIN Emprestimo e
10 ON u . id_usuario = e . id_usuario
11 WHERE u . id_usuario IS NULL OR e . id_usuario IS NULL
12 ORDER BY u . id_usuario , e . id_emprestimo ;
4.2. FUNÇÕES DQL 57

• CROSS JOIN

Cada uma das linhas da tabela à direita(Tabela B) é combinada com as linhas da tabela à
esquerda(Tabela A), ou seja, para cada linha da Tabela A retorna todos os linhas da Tabelas B ou
vice-versa. Conhecido como produto cartesiano entre duas tabela, mas, para que ocorra é preciso
que ambas tenham o campo em comum, para que a ligação exista.

Figura 27 – Representação Cross Join

Sintaxe:
1 SELECT < COLUNA > ,... FROM < TABELA A >
2 CROSS JOIN < TABELA B >

Exemplo:
1 SELECT
2 u . nome AS nome_usuario ,
3 l . titulo AS titulo_livro ,
4 l . genero AS genero_livro
5 FROM
6 Usuario u
7 CROSS JOIN
8 Livro l
9 WHERE
10 l . genero = ' Aventura ';
4.2. FUNÇÕES DQL 58

• SELF JOIN

Junção da tabela com ela mesma, o que permite explorar relações intrínseca dos dados e rea-
lizar comparações entre os dados de uma mesma tabela.

Figura 28 – Representação Self Join

Sintaxe:
1 SELECT < COLUNA > ,... FROM < TABELA A >
2 INNER JOIN < TABELA A >
3 ON COLUNA A = COLUNA A

Exemplo:
1 SELECT
2 u1 . id_usuario AS id_usuario_1 ,
3 u1 . nome AS nome_usuario_1 ,
4 u2 . id_usuario AS id_usuario_2 ,
5 u2 . nome AS nome_usuario_2 ,
6 SPLIT_PART ( u1 . endereco , ' , ' ,1) AS endereco_comum
7 FROM
8 Usuario u1
9 INNER JOIN
10 Usuario u2
11 ON
12 SPLIT_PART ( u1 . endereco , ' , ' ,1) = SPLIT_PART ( u2 . endereco , ' , ' ,1)
13 AND u1 . id_usuario <> u2 . id_usuario ;
 4.2. FUNÇÕES DQL 59

4.2.3 Funções avançadas

[Link] SUBQUERY
Uma subconsulta é uma consulta SQL que está aninhada dentro de outra consulta e pode ser utilizada
em várias partes de uma instrução SQL no SELECT,FROM ou até mesmo no WHERE. Desta forma, se torna
possível efetuar consultas que de outra forma seriam extremamente complicadas.
Sintaxe:
1 SELECT < COLUNA > ,...
2 FROM < TABELA >
3 WHERE < COLUNA > IN ( SELECT < coluna >
4 FROM < tabela >
5 WHERE < condicao >
6 );

Exemplo:
1 SELECT
2 u . nome ,
3 u . email ,
4 u . telefone
5 FROM Usuario u
6 WHERE
7 u . id_usuario IN (
8 SELECT
9 e . id_usuario
10 FROM Emprestimo e
11 WHERE
12 e . d a t a_ d e vo l u ca o _ re a l > e . d a t a _ d e v o l u c a o _ p r e v i s t a
13 );
 4.2. FUNÇÕES DQL 60

[Link] UNION
A função de união geralmente é utilizada para combinar os resultados de duas ou mais consultas em um
único conjunto de resultados, excluindo duplicatas, o que permite a integração de dados de múltiplas
fontes.

Sintaxe:
1 SELECT < COLUNA > ,... FROM < TABELA >
2 UNION
3 SELECT < COLUNA > ,... FROM < TABELA >

Exemplo:
1 SELECT e . data_emprestimo AS data_acao ,
2 ' Emprestimo ' AS tipo_acao ,
3 u . nome AS usuario ,
4 l . titulo AS livro
5 FROM Emprestimo e
6 INNER JOIN Usuario u ON e . id_usuario = u . id_usuario
7 INNER JOIN Livro l ON e . id_livro = l . id_livro
8
9 UNION
10
11 SELECT e . d a t a_ d e vo l u ca o _ re a l AS data_acao ,
12 ' Devolucao ' AS tipo_acao ,
13 u . nome AS usuario ,
14 l . titulo AS livro
15 FROM Emprestimo e
16 INNER JOIN Usuario u ON e . id_usuario = u . id_usuario
17 INNER JOIN Livro l ON e . id_livro = l . id_livro
18 ORDER BY data_acao DESC ;
4.2. FUNÇÕES DQL 61

Recomendações
Recomendações importantes para o uso das funções:

1. Importante destacar que o uso da cláusula SELECT * nas consultas SQL não é recomendado
em ambientes de produção, especialmente em bancos de dados de grande porte. A prática de
selecionar todas as colunas de uma tabela pode levar a vários problemas como:

• Desempenho: Ao usar SELECT *, o banco de dados precisa carregar todas as colunas de

uma tabela, mesmo aquelas que não são necessárias para a análise desejada. Aumentando o
tempo de processamento e o uso de memória, e consequentemente, afetando negativamente
o desempenho das consultas e do sistema como um todo.
• Manutenção: Com o tempo, as tabelas tendem a evoluir, com a adição ou remoção de
colunas. O uso de SELECT * torna o código mais difícil de ser mantido, pois qualquer
mudança na estrutura da tabela pode ter efeitos inesperados nas consultas.
• Legibilidade do Código: Especificar explicitamente as colunas que serão selecionadas torna
o código mais claro e fácil de entender. Facilita a manutenção e a colaboração entre desen-
volvedores, além de minimizar a chance de erros.

Recomenda-se sempre listar explicitamente as colunas necessárias para a consulta.

2. O uso da cláusula LIMIT é altamente recomendada ao testar uma consulta. Benefícios do Uso
do LIMIT

• Testar Resultados: O LIMIT nos permite visualizar uma amostra dos resultados da consulta
sem processar todo o conjunto de dados. Muito útil para verificar se a lógica da consulta está
correta e se os dados retornados são os esperados. Uma vez que visualizamos uma amostra
dos resultados temos facilidade em identificar problemas na consulta, como filtros incorretos
ou junções erradas. Permitindo que façamos correções antes de executar a consulta final,
economizando tempo e recursos.
• Economizar Recursos: Executar uma consulta completa pode consumir muitos recursos do
sistema, especialmente se a consulta envolve junções complexas, agregações ou filtros em
grandes tabelas. O uso do LIMIT reduz a carga d e processamento, permitindo ajustes na
consulta de maneira mais eficiente.

3. EXISTS vs IN:
A cláusula EXISTS é utilizada para verificar se um ou mais valores estão presentes no resultado
de uma subconsulta. Por outro lado, a cláusula IN é empregada para comparar um valor com um
conjunto de valores retornados por uma subconsulta ou com um conjunto declarado de valores.
Ambas as cláusulas são especialmente usadas no comando WHERE.

A decisão entre EXISTS e IN pode impactar o desempenho da consulta, dependendo do con-

texto e da estrutura dos dados. Quanto ao processamento, a cláusula EXISTS é eficiente em
grandes volumes de dados, pois o SQL pode interromper a busca assim que encontra o primeiro
registro que satisfaz a condição. Além disso, é particularmente útil em consultas que envolvem
junções complexas e onde a mera existência de registros é suficiente para atender à condição.

Enquanto isso, a cláusula IN apresenta maior desempenho quando se trata de um conjunto de

dados menor. Em situações onde a subconsulta retorna poucos registros ou quando a comparação
é feita com uma lista declarada de valores, a cláusula IN se destaca por ser mais rápida e intuitiva.

Portanto, use :

• EXISTS: Quando a subconsulta retorna muitos registros ou quando é necessário verificar a

existência de registros em junções complexas.
4.2. FUNÇÕES DQL 62

• IN: Quando se compara valores específicos em conjuntos pequenos ou quando a subconsulta

retorna poucos registros.

4. Tipo de dado booleano

A utilização de dados booleanos em SQL traz diversas vantagens, como um menor espaço de
armazenamento de dados, já que as colunas booleanas ocupam menos espaço em comparação
com inteiros ou strings.

As variáveis booleanas simplificam a lógica condicional, pois seus valores são limitados e claros,
restringindo-se apenas a TRUE (verdadeiro) ou FALSE (falso). O que torna o código mais intuitivo
e fácil de entender, colunas como 'usuario_ativo', 'permissao_acesso' são autoexplicati-
vos. Outro benefício significativo é o desempenho, pois a comparação de valores booleanos é mais
rápida e eficiente em comparação com outros tipos de dados.

Portanto, sempre que possível, recomenda-se o uso de booleanos para representar estados
binários, melhorando tanto a clareza quanto a eficiência do código SQL.

5. JOINS × Subconsulta:
Quando trabalhamos com bancos de dados SQL, a escolha entre utilizar joins ou subconsultas
pode impactar o desempenho das suas consultas.

Os joins normalmente são utilizados para combinar dados de duas ou mais tabelas com base
em uma condição. Como estudamos, existem diferentes tipos de joins, cada um servindo a pro-
pósitos específicos. Quanto a performance, os joins geralmente são mais eficientes do que
subconsultas, especialmente quando se trata de grandes conjuntos de dados. Isso ocorre porque
os joins permitem que o banco de dados otimize a consulta e execute as operações de combinação
de maneira mais direta e eficaz.

As subconsultas, por outro lado, são consultas aninhadas dentro de outra consulta. Embora
sejam úteis em alguns casos, são menos eficientes do que os joins, particularmente quando retor-
nam grandes conjuntos de dados ou quando a lógica da consulta envolve múltiplas camadas de
subconsultas.

• Quando Usar Joins:

– Use joins quando precisar combinar dados de duas ou mais tabelas com base em uma
condição de relacionamento clara.
– Prefira joins para consultas que envolvem grandes volumes de dados.
• Quando Usar Subconsultas:
– Use subconsultas quando precisar filtrar resultados com base em condições complexas
que não são facilmente resolvidas com joins.
– As subconsultas são úteis para casos onde uma consulta interna deve ser executada
primeiro para fornecer dados à consulta externa.

Portanto, as subconsultas devem ser usadas com moderação e principalmente em casos onde a
lógica da consulta se beneficia claramente de uma abordagem aninhada e os joins são os mais
indicados.

6. Otimizando a cláusula LIKE:

A cláusula LIKE é frequentemente utilizada em consultas para buscar padrões dentro de colunas
do tipo texto. No entanto, a forma como o padrão é especificado influência na performance da
consulta.

O Que São Índices?

4.2. FUNÇÕES DQL 63

Índices são estruturas de dados que o banco de dados usa para melhorar a velocidade das ope-
rações de consulta. Permitindo que o banco de dados encontre dados mais rapidamente sem ter
que varrer todas as linhas de uma tabela. Quando usamos o LIKE para buscar padrões em uma
coluna, o comportamento do índice depende de como o padrão é especificado.
• Padrão que Não Começa com %: Se o padrão especificado não começa com um caractere
curinga %, o banco de dados pode usar o índice para acelerar a busca. Por exemplo:
LIKE ‘Ana%' pode usar um índice, pois o banco de dados sabe que está procurando por
textos que começam com "Ana".
• Padrão que começa com %: • Neste caso, quando o padrão começa com %, o índice não
pode ser utilizado de maneira eficiente. Por quê % no início significa que qualquer sequência
de caracteres pode estar antes do padrão, exigindo que o banco de dados examine linha a
linha. Exemplo: LIKE ’%na’ não pode usar o índice, pois o banco de dados teria que verificar
todas as entradas para encontrar aquelas que terminam em "na". O que obstrui muito a
performance
Quando o padrão começa com %, não há um ponto de início claro, forçando o banco de dados
a verificar cada entrada. Sendo assim, evitar padrões que começam com % é uma prática
recomendada para garantir que suas buscas sejam rápidas e eficientes.
7. A utilização de atribuição direta ‘=’ é muito vantajoso e recomendado quando comparamos
um valor único. Por ser uma operação de comparação tem um custo de processamento melhor,
portanto melhor desempenho que outras operações ou clausulas. Além de ser uma excelente
pratica pois torna o código consistente, também, facilita o entendimento da consulta pro outros
desenvolvedores.
8. Quando falamos das condições e clausulas dentro do WHERE a ordem dos fatores não altera o
resultado mas influencia na performance e desempenho do banco de dados. Então, quando
construímos um código, devemos nos atentar a ordem em que inserimos as condições e clausulas.
A ordem de priorização é:
a) Condições com Índices: Condições que utilizam índices devem ser priorizadas porque o
banco de dados consegue rapidamente localizar os registros sem a necessidade de uma ler
toda a tabela.
b) Condições de Igualdade: As condições de igualdade (=) geralmente são mais eficientes
porque reduzem o conjunto de dados antes de outras condições.
c) Condições de Faixa: Condições que restringem o intervalo de valores (BETWEEN, >=, <=).
d) Condições de Junção: As condições de junção (JOIN) podem ser otimizadas se colocadas
cedo, especialmente se forem usadas em colunas indexadas.
e) Condições de Subconsulta: Devem ser priorizadas depois das condições mais seletivas para
reduzir o número de registros que a subconsulta precisa processar.
f) Condições de IN/NOT IN: IN com uma lista pequena pode ser eficiente, mas com listas
grandes ou em tabelas grandes, são menos eficiente do que junções ou outras condições.
g) Condições de LIKE com % ao Final: Condições LIKE onde o wildcard (%) está no final
são índices, tornando-as mais rápidas que wildcards no início.
h) Condições de LIKE com % ao Início: Condições LIKE com wildcards no início (%prefixo)
não eficientes, nem recomendadas, pois não podem usar índices e exigem uma varredura
completa da tabela linha a linha.
i) Condições Complexas e Funções: Condições que envolvem funções, cálculos ou operações
complexas são deixadas por último, pois são requerem mais processamento.
Adotar estas práticas no seu fluxo de trabalho pode melhorar significativamente a eficiência e
a precisão das consulta no banco de dados.
 64

Atividade Linguagem SQL

Nesta seção, você aplicará os conhecimentos adquiridos sobre comandos SQL em um exemplo de banco
de dados de uma biblioteca.

As atividades cobrem a inserção de dados, consultas, atualizações e exclusões, permitindo um aprendi-

zado prático em cada uma das áreas abordadas. Iniciaremos com a inserção de dados nas tabelas Livro,
Usuario, Emprestimo e Multa.

Vamos começar!

Inserção
Inserir dados na tabela Emprestimo.
1 INSERT INTO Emprestimo ( Data_do_emprestimo , Data_devolucao_real ,
Data_devolucao_prevista )
2 VALUES
3 ( ' 2023 -12 -08 14:42:46 ' , ' 2023 -12 -20 14:42:46 ' , ' 2023 -12 -17 14:42:46 ') ,
4 ...

Inserir dados na tabela Livro

1 INSERT INTO Livro ( Titulo , Autor , Editora , Genero , Ano_publicacao ,
fk_Emprestimo_ID_do_emprestimo )
2 VALUES
3 ( ' Peter Rabbit ' , ' Beatrix Potter ' , ' Rocco ' , ' Conto ' , ' 1959 -10 -19 17:30:38 '
, NULL ) ,
4 ( ' Percy Jackson e o Ladrao de Raios ' , ' Rick Riordan ' , ' Rocco ' , ' Fabula ' , '
2018 -01 -02 07:47:07 ' , 30) ,
5 ...

Inserir dados na tabela Usuário

1 INSERT INTO Usuario ( Nome , E_mail , Endereco , Telefone ,
fk_Emprestimo_ID_do_emprestimo )
2 VALUES
3 ( ' Joao Alves ' , ' joo . alves@biblioteca . com ' , ' Contagem ' , ' (31) 747154406 ' ,
47) ,
4 ...

Inserir dados na tabela Multa

1 INSERT INTO Multa ( Valor , f k _ E m p r e s t i m o _ I D _ d o _ e m p r e s t i m o ) VALUES
2 (4.54 , 58) ,
3 ...

Execute os inserts. Após a execução, será apresentada uma mensagem no prompt, retornando que a
execução deu certo.
1 Query returned successfully in < tempo de execucao >
4.2. FUNÇÕES DQL 65

Consulta
Vamos executar comandos de consulta:

1. Consultar todos os livros e seus autores:

1 SELECT titulo , autor FROM Livro ;

2. Consultar a data de devolução prevista e real empréstimos realizados no mês de Abril(4).

1 SELECT e . id_emprestimo ,
2 e . data_emprestimo ,
3 e . data_devolucao_prevista ,
4 e . d a t a_ d e vo l u ca o _ re a l
5 FROM Emprestimo e
6 WHERE extract ( month from e . data_emprestimo ) = 04;

3. Consultar todos os empréstimos que estão atrasados (data de devolução real é maior que a data
da devolução prevista):
1 SELECT e . id_emprestimo ,
2 e . data_devolucao_prevista ,
3 e . d a t a_ d e vo l u ca o _ re a l
4 FROM Emprestimo e
5 WHERE e . d a t a_ d e vo l u ca o _ re a l > e . d a t a _ d e v o l u c a o _ p r e v i s t a ;

4. Consultar todos os livros que nunca foram emprestados:

1 SELECT l . titulo ,
2 l . autor ,
3 l . ano_publicacao
4 FROM Livro l
5 LEFT JOIN Emprestimo e
6 ON l . id_livro = e . id_livro
7 WHERE e . id_livro IS NULL ;

5. Consultar todos os livros que foram emprestados, incluindo as informações do empréstimo:

1 SELECT l . titulo ,
2 e . data_emprestimo ,
3 e . data_devolucao_prevista ,
4 e . d a t a_ d e vo l u ca o _ re a l
5 FROM Livro l
6 JOIN Emprestimo e
7 ON l . id_livro = e . id_livro ;

6. Consultar os usuários que têm multas associadas aos seus empréstimos:

1 SELECT u . nome , u . telefone ,
2 e . data_emprestimo ,
3 e . data_devolucao_prevista ,
4 e . data_devolucao_real ,
5 m . valor
6 FROM Usuario u
7 JOIN Emprestimo e
8 ON u . id_usuario = e . id_usuario
9 RIGHT JOIN Multa m
10 ON e . id_emprestimo = m . id_emprestimo
4.2. FUNÇÕES DQL 66

7. Consultar a soma total das multas de todos os usuários:

1 SELECT SUM ( m . valor ) AS TOTALMULTA
2 FROM Multa m ;

8. Consultar a lista de usuários que pegaram livros de um determinado gênero (por exemplo, "Aven-
tura"):
1 SELECT u . nome , u . telefone , l . genero
2 FROM Usuario u
3 JOIN Emprestimo e
4 ON u . id_usuario = e . id_usuario
5 JOIN Livro l
6 ON e . id_livro = l . id_livro
7 WHERE l . Genero = ' Aventura ';

9. Utilizando CTE para listar empréstimos com a duração mais longa

1 WITH D u ra c a o_ e m pr e s ti m o s AS (
2 SELECT e . id_emprestimo ,
3 u . nome ,
4 l . titulo ,
5 e . data_emprestimo ,
6 e . data_devolucao_real ,
7 ( e . d a t a_ d e vo l u ca o _ re a l - e . data_emprestimo ) AS Duracao
8 FROM Emprestimo e
9 JOIN Usuario u
10 ON e . id_usuario = u . id_usuario
11 JOIN Livro l
12 ON e . id_livro = l . id_livro
13 WHERE e . D a t a_ d e vo l u ca o _re a l IS NOT NULL
14 )
15 SELECT nome ,
16 titulo ,
17 Duracao
18 FROM D u ra c a o_ e m pr e s ti m o s
19 ORDER BY Duracao DESC ;

10. Gerar um relatório que retorne a quantidade de dias em atraso de devolução por gênero literário.
1 SELECT l . genero ,
2 SUM ( DATE_PART ( ' day ' , e . d at a _ de v o lu c a o_ r e al - e . d a t a _ d e v o l u c a o _ p r e v i s t a
) ) AS qtde_dias_atraso
3 FROM Livro l
4 JOIN Emprestimo e ON l . id_livro = e . id_livro
5 WHERE e . d a t a_ d e vo l u ca o _ re a l > e . d a t a _ d e v o l u c a o _ p r e v i s t a
6 GROUP BY l . genero ;
4.2. FUNÇÕES DQL 67

11. Selecione o histórico completo de todos os empréstimos realizados no ano de 2023 e o nome dos
usuários que o fizeram.
1 SELECT l . titulo ,
2 u . nome ,
3 e . data_emprestimo ,
4 e . d a t a_ d e vo l u ca o _ re a l
5 FROM Livro l
6 JOIN Emprestimo e ON l . id_livro = e . id_livro
7 JOIN Usuario u ON e . id_usuario = u . id_usuario
8 WHERE extract ( year from e . data_emprestimo ) = 2023
9 ORDER BY l . titulo , e . data_emprestimo ;

12. Crie uma classificação dos livros baseado no número de empréstimos realizados.

• Caso o livro possua Null ou 0(zero) empréstimos, ’Ruim’

• Caso o livro possua 1(um) empréstimo, ’Bom’
• Caso o livro possua 2(dois) ou mais empréstimos, ’Recomendado’

1 SELECT l . titulo ,
2 l . genero ,
3 CASE
4 WHEN ( COUNT ( e . id_livro ) = 0 OR COUNT ( e . id_livro ) IS NULL ) THEN
' Ruim '
5 WHEN COUNT ( e . id_livro ) = 1 THEN ' Bom '
6 ELSE ' Recomendado '
7 END AS Classificao
8 FROM Livro l
9 LEFT JOIN Emprestimo e
10 ON e . id_livro = l . id_livro
11 GROUP BY l . titulo , l . genero
4.2. FUNÇÕES DQL 68

Atualização
1. Atualizar todos os livros de um determinado gênero para outra gênero literário
1 UPDATE Livro
2 SET Genero = ' Fantasia / Aventura '
3 WHERE Genero = ' Aventura ';

2. Atualizar nome de um usuário

1 UPDATE Usuario
2 SET Nome = ' Novo Nome '
3 WHERE id_usuario = 1;

3. Atualizar o valor das multas de empréstimos com a mais de 7(sete) dias de atraso
1 UPDATE Multa
2 SET Valor = Valor * 1.10 -- Aumento de 10% no valor da multa
3 WHERE id_emprestimo
4 IN ( SELECT id_emprestimo
5 FROM Emprestimo
6 WHERE (( d at a _ de v o lu c a o_ r e al - d a t a _ d e v o l u c a o _ p r e v i s t a )
> '7 days ')
7 );

4. Atualizar os livros aumentando o ano de publicação em um ano

1 UPDATE Livro
2 SET Ano_publicacao = Ano_publicacao + INTERVAL '1 year '
3 WHERE id_livro = 3;

5. Atualizar o endereço de usuários que tiveram mudança de em seus CEP devido a reorganização
municipal.
1 UPDATE Usuario
2 SET endereco = REPLACE ( endereco , ' Rua da Bahia ' , ' Rua Nova Bahia ')
3 WHERE endereco LIKE ' Rua da Bahia % ';
4.2. FUNÇÕES DQL 69

Exclusão
1. Delete os registros de empréstimos que não foram devolvidos em um período superior a 5(cinco)
anos.
1 DELETE FROM Emprestimo
2 WHERE d at a _ d ev o l uc a o _r e a l IS NULL
3 AND data_emprestimo < CURRENT_DATE - INTERVAL '5 years '; -- A funcao '
CURRENT_DATE ' extrai a data / hora atual do sistema .

2. Delete todos os livros da editora ’Abril’ que fechou, juntamente com as multas e empréstimo
associados.
1 DELETE FROM Multa
2 WHERE id_emprestimo IN
3 (
4 SELECT id_emprestimo
5 FROM Emprestimo
6 WHERE id_livro IN
7 (
8 SELECT id_livro
9 FROM Livro
10 WHERE editora = ' Abril '
11 )
12 );
13
14 DELETE FROM Emprestimo
15 WHERE id_livro IN
16 (
17 SELECT id_livro
18 FROM Livro
19 WHERE editora = ' Abril '
20 );
21
22 DELETE FROM Livro
23 WHERE editora = ' Abril ';

3. Deletar a coluna de endereço da tabela Usuário.

1 ALTER TABLE Usuario
2 DROP endereco ;

4. Excluir a tabela Multa do banco de dados.

1 DROP TABLE Multa
 70

5 Views, Triggers, Funcions e Procedu-

res

5.1 Views
Uma view é um objeto que permite a criação de conjuntos de dados a partir de consultas em uma
ou mais tabelas, gerando uma tabela virtual apenas para visualização. Nela, não é possível adicionar,
excluir ou atualizar dados, no entanto, é possível selecionar as informações exibidas, mostrando apenas
as desejadas para o usuário.

As linhas e colunas da view são geradas dinamicamente apenas quando referenciadas, funcionando como
uma "consulta viva", desta forma, não ocupam espaço na memória e podem ser reutilizadas várias vezes.

Sintaxe:
1 CREATE VIEW < nome_view > AS
2 -- Corpo da view
3 ....
4 ;

5.2 Trigger
No contexto de um sistema de gerenciamento de banco de dados, um trigger, em português ’gatilho’, é
um procedimento automático que se ativa em resposta a determinados eventos em tabelas ou visões de
bases de dados, estes eventos podem ser inserções, atualizações ou eliminações. Esta medida automatiza
ações a fim de garantir a integridade e consistência das informações armazenadas no banco de dados,
como, por exemplo, atualizar a ’Tabela Y’ quando algo na ’Tabela X’ for modificado. As triggers po-
dem ser ativadas em três instâncias a respeito do seu acionamento: ’BEFORE’(antes), ’AFTER’(depois)
ou ’INSTEAD OF’(no lugar da instrução que ativa o gatilho).

Os triggers do tipo BEFORE e AFTER podem ser utilizados com qualquer instrução DML (INSERT,
UPDATE, DELETE), além de permitir o uso da declaração TRUNCATE. Já os triggers definidos com a
instrução INSTEAD OF podem ser usados para instruções DML em tabelas virtuais (views).

Os triggers disparados antes ou depois das instruções DML, podem ser definidos para executar apenas
uma vez para qualquer instrução SQL (STATEMENT) ou a nível de linha (ROW).No caso dos triggers do
tipo INSTEAD OF nas instruções DML, eles podem ser executados apenas a nível de linha (ROW).
 5.2. TRIGGER 71

Sintaxe PostgreSQL:
1 CREATE TRIGGER < nome_trigger >
2 [ BEFORE | AFTER | INSTEAD OF ][ INSERT | UPDATE | DELETE ]
3 ON < nome_tabela >
4 [ FOR EACH ROW ]
5 EXECUTE FUNCTION nome_funcao (...) ;
6
7 -- A instrucao CREATE TRIGGER especifica o nome de uma trigger .
8 -- A clausula BEFORE | AFTER | INSTEAD OF especifica o momento em que a regra
sera disparada .
9 -- A ON determina a relacao em que a regra especificada .
10 -- Existem duas palavras chaves FOR EACH ROW e ' FOR EACH STATEMENT ', que
especificam como a regra sera disparada .
11 -- ' EXECUTE FUNCTION n ( ) ' corpo da funcao a aplicar na tabela ou View

Porém possuem certas limitações, são elas:

• CREATE TRIGGER deve ser sempre a primeira instrução no lote e a aplicação deve ser feita em
apenas a uma tabela.

• As seguintes instruções não são permitidas em um trigger DML:

– ALTER DATABASE
– CREATE DATABASE
– DROP DATABASE

• As instruções a seguir não são permitidas em um trigger DML usado em uma tabela ou View que
seja alvo da ação de trigger.

– CREATE INDEX
– ALTER INDEX
– DROP INDEX
– DROP TABLE
– ALTER TABLE quando:
∗ Adiciona, modifica ou descarta colunas.
∗ Alterna partições.
∗ Adiciona ou descarta restrições PRIMARY KEY ou UNIQUE.

• Os triggers INSTEAD OF DELETE/UPDATE não podem ser definidos em uma tabela que tenha uma
chave estrangeira com uma cascata na ação DELETE/UPDATE definida.

• Um triggers é criado apenas no banco de dados atual; mas, pode referenciar objetos fora do banco
de dados atual.

As triggers são um recurso muito útil em tarefas que podem ser automatizadas, pois reduzem a quanti-
dade de código necessária e diminuem o potencial de erro humano. Além de preservarem a integridade
dos dados, assegurando que determinadas condições sejam atendidas antes que os dados sejam modifi-
cados, inseridos ou até mesmo deletados. Além disso, possibilitam a localização de alterações realizadas,
por isto, são amplamente utilizadas em auditorias de dados.
 5.3. FUNCTIONS 72

5.3 Functions
Uma função definida pelo usuário (User Defined Function, UDF) é uma função de código ou cálculo que
você pode salvar no seu banco de dados e executar quando necessário. Essa rotina executa uma ação e
retorna o resultado como um valor. O valor de retorno pode ser único ou uma tabela. As funções são
usadas em diversas linguagens de programação, incluindo SQL, permitindo a execução de cálculos ou
operações específicas sem a necessidade de reescrever o código repetidamente.

As funções de usuário podem ser de três tipo:

• Scalar Function: Esta função retorna um único valor para cada chamada e pode ser usada em
cláusulas ’SELECT’, ’WHERE’ e ’HAVING’.

• Multi-statement Table-valued Function: Uma função valor-tabela de múltiplas instruções retorna

uma tabela e pode conter várias instruções entre ’BEGIN’ e ’END’.

• In-Line Table-valued Function: Funciona internamente como uma ’VIEW’ e possui apenas uma
instrução de ’SELECT’ em seu código, podendo utilizar um parâmetro desde que esteja declarado
na especificação da function.

Sintaxe Function em PostgreSQL:

1 CREATE [ OR REPLACE ] FUNCTION nome_funcao ( nome_parametro tipo_parametro [ ,
...])
2 RETURNS tipo_retorno AS $$
3 BEGIN
4 -- Corpo da funcao : logica , declaracoes SQL , etc .
5 RETURN valor_retorno ;
6 END ;
7 $$ LANGUAGE plpgsql ;
8
9 -- Primeiro , deve definir um nome para funcao apos o comando ' CREATE
FUNCTION ' ou para substituir a funcao existente use ' OR REPLACE '.
10 -- Liste os parametros apos o nome da funcao . A funcao pode possuir zero
ou N parametros .
11 -- Defina o tipo de dado retornado .
12 -- Adicione o corpo da funcao entre BEGIN e ' END '.
13 -- Use o ' LANGUAGE plpgsql ' para definir a linguagem da funcao .

As funções definidas pelo usuário (UDFs) proporcionam flexibilidade e eficiência na execução de opera-
ções geralmente complexas.
 5.4. STORED PROCEDURE 73

5.4 Stored Procedure

Procedimento Armazenado (Stored Procedure, ou apenas Procedure) é um conjunto de comandos em
SQL que podem ser executados de uma só vez, semelhante a uma função. Ele armazena tarefas repe-
titivas e aceita parâmetros de entrada para a execução dessas tarefas.

As Procedures contribuem para a performance do banco de dados. Ao invés de enviar várias instruções
SQL separadas, que precisam ser interpretadas a cada execução, as Procedures são armazenadas no
banco de dados. Isso reduz o tempo de processamento e melhora a eficiência das consultas.

Há dois tipos básicos de procedures que podemos criar:

1. Procedimentos Locais: São criados a partir de um banco de dados do próprio usuário.

2. Procedimentos Remotos: São procedimentos executados em um servidor de banco de dados

remoto. Isso significa que, em vez de executar a função ou procedimento localmente no servidor
onde a solicitação foi feita, a execução ocorre em um servidor diferente.

Ao criar procedimentos podemos definir diferentes tipos de parâmetros para controlar como os dados
são passados e manipulados. Existem três principais tipos de parâmetros:

O primeiro é o IN este parâmetro de entrada que fornecem valores ao procedimento. O parâmetro

OUT de saída que retorna valores do procedimento para o chamador geralmente são utilizados quando
o procedimento retorna múltiplos valores. E o último,INOUT atua tanto como entrada quanto como
saída, permitindo passar um valor para o procedimento, modificar esse valor dentro do procedimento, e
retornar o valor modificado ao chamador.

Sintaxe Procedure:
1 CREATE [ OR REPLACE ] PROCEDURE nome_procedure (
2 parametro1 tipo_parametro1 tipo_dado1 ,
3 parametro2 tipo_paramtro2 tipo_dado2 )
4 LANGUAGE plpgsql
5 AS $$
6 BEGIN
7 -- Instrucao SQL
8 END ;
9 $$ ;
10
11 -- Para criarmos uma procedure , utilizamos a declaracao CREATE PROCEDURE .
12 -- Declaramos os parametros e definimos o tipo de dado ( a declaracao de
parametros e opcional ) .
13 -- Inserimos intrucao SQL que desejamos executar dentro entre BEGIN e END .

Apesar de semelhantes, estes comandos apresentam diferenças, principalmente a forma que são execu-
tados e circunstância. Outras diferenças são:
5.4. STORED PROCEDURE 74

Tabela 23 – Comparação entre Trigger, Function e Procedure

Característica Trigger Function Procedure

Propósito Automação de respostas a eventos Retornar um valor calculado Encapsular lógica de
DML ou resultado de uma opera- negócios ou opera-
ção ções complexas
Quando é execu- Automaticamente em resposta a Quando chamada explicita- Quando chamada
tado um evento (INSERT, UPDATE, mente explicitamente
DELETE)
Retorno de Valor Não retorna valor diretamente Retorna um valor escalar ou Pode ou não retor-
tabela nar valores, mas não
retorna diretamente
em consultas
Uso em Consultas Não pode ser chamada direta- Pode ser usada diretamente Não pode ser cha-
SQL mente em consultas em consultas SQL mada diretamente
em consultas
Parâmetros Não aceita parâmetros Aceita apenas parâmetros Aceita parâmetros de
de entrada (IN) entrada (IN), saída
(OUT) e entrada/-
saída (INOUT)
Tipo de Retorno Nenhum Tipo de dado específico ou Nenhum tipo de re-
tabela torno específico
Escopo de Uso Manter a integridade referencial e Encapsular cálculos ou ope- Encapsular lógica de
automatizar tarefas rações reutilizáveis negócios e operações
complexas
Chamado explicita- Não Sim Sim
mente
Tabela/View Asso- Sim, está associado a uma tabela Não necessariamente asso- Não necessariamente
ciada ou view ciado a uma tabela associado a uma ta-
bela
 75

6 O modelo Entidade-Relacionamento
Estendido (EER)

Devido à crescente necessidade de bancos de dados mais precisos, capazes de representar de forma fiel
aplicações cada vez mais complexas, como projetos de engenharia e sistemas de informações geográficas,
tornou-se essencial o desenvolvimento de propriedades de dados e restrições com a máxima precisão.
Esse cenário levou ao surgimento de um novo conceito conhecido como modelagem semântica de dados
e à criação do Modelo Entidade-Relacionamento Estendido (EER), uma extensão do tradicional
Modelo Entidade-Relacionamento (ER).

Segundo C.J. Date, a modelagem semântica é uma abordagem que visa representar fielmente o mundo
real no modelo de dados. Portanto, esta modelagem busca capturar o significado dos dados e suas
relações de forma mais rica e precisa.

O modelo abrange relações complexas de alto nível entre entidades, que não são facilmente capturadas
por modelos convencionais, e incorpora conceitos de herança e hierarquia entre entidades, permitindo a
definição de subclasses e superclasses.

Além disso, a modelagem semântica de dados especifica restrições de integridade complexas, garan-
tindo a validade e a consistência dos dados no Banco de Dados, e inclui propriedades adicionais que
proporcionam uma compreensão profunda dos dados. Dessa forma, a modelagem semântica de dados,
conforme explicada por Date, é uma evolução importante para lidar com a complexidade crescente das
aplicações.

Figura 29 – Modelo EER Veículo

6.1 Superclasse
Uma superclasse é uma entidade genérica do mundo real que agrupa características comuns a várias
entidades mais específicas. Por exemplo, a entidade VEÍCULO descreve os atributos e relacionamentos
pertinentes a todos os tipos de veículos.
6.2. SUBCLASSE 76

6.2 Subclasse
Um tipo de entidade pode ser dividido em várias subclasses que são significativas e precisam ser re-
presentadas explicitamente devido à sua importância na construção do modelo do banco de dados.
Assim, uma subclasse é uma entidade e possui seus próprios atributos e relacionamentos exclusivos, que
também herda os atributos e relacionamentos da superclasse.

6.3 Herança
Uma entidade não pode existir no banco de dados apenas como um membro de uma subclasse; ela
também precisa ser um membro da superclasse. Partindo deste principio, um importante conceito rela-
cionado às subclasses é o de herança de tipo. O tipo de uma entidade é definido pelos atributos que ela
possui e pelos tipos de relacionamento de que participa. Como uma entidade na subclasse representa a
mesma entidade do mundo real que a superclasse, ela deve possuir valores para seus atributos específi-
cos, bem como valores para os atributos da superclasse.

A herança no modelo EER permite que uma subclasse herde todos os atributos e relacionamentos
da sua superclasse, facilitando a reutilização de atributos comuns e assegurando a consistência dos
dados.

Continuando com nosso exemplo, podemos definir subclasses como CARRO e MOTO, que herdam os
atributos da superclasse VEÍCULO, mas possuem atributos específicos, como número de portas para
CARRO e tipo de capacete para MOTO.

O relacionamento entre uma superclasse e qualquer uma de suas subclasses é conhecido como rela-
cionamento superclasse/subclasse, ou ainda supertipo/subtipo, ou simplesmente classe/subclasse. Este
relacionamento é comumente descrito pelo termo É_UM, do inglês IS-A. Portanto, dizemos que um
CARRO é um VEÍCULO.

6.4 Especialização e Generalização

A especialização é o processo de definição de um conjunto de subclasses a partir de um tipo de enti-
dade. Esse tipo de entidade é denominado superclasse da especialização. As subclasses que formam essa
especialização são determinadas com base em características distintas das entidades da superclasse. Por
exemplo, as subclasses MOTO e CARRO são especializações da superclasse VEÍCULO, diferenciando-se
pelo tipo de veículo que representam. Diversas especializações podem ser criadas para o mesmo tipo
de entidade, baseando-se em diferentes características.

Existem dois principais motivos para incluir relacionamentos de classe/subclasse e especializações em

um modelo de dados:

1. Atributos Específicos: Certos atributos podem ser aplicáveis apenas a algumas entidades da super-
classe. Assim, uma subclasse é criada para agrupar as entidades que compartilham esses atributos
específicos, embora ainda possam compartilhar a maioria dos atributos com os outros membros
da superclasse.

2. Relacionamentos Específicos: Alguns tipos de relacionamentos podem ser pertinentes apenas para
entidades que pertencem à subclasse. Portanto, subclasses permitem a definição de relaciona-
mentos específicos que não seriam aplicáveis a toda a superclasse.

O processo de especialização, portanto, nos permite:

• Definir um conjunto de subclasses a partir de um tipo de entidade.

6.5. RESTRIÇÕES E CARACTERÍSTICAS DAS HIERARQUIAS DE ESPECIALIZAÇÃO E GENERALIZAÇÃO 77

• Estabelecer atributos adicionais específicos para cada subclasse.

• Estabelecer tipos de relacionamento específicos entre cada subclasse e outros tipos de entidade
ou outras subclasses.

Já generalização é o processo inverso da especialização. Neste processo, suprimimos as diferenças

entre vários tipos de entidade, identificamos suas características comuns e as generalizamos em uma
única superclasse, da qual os tipos de entidade originais se tornam subclasses.

Por exemplo, considere os tipos de entidade CARRO e CAMINHÃO. Como ambos possuem vários atri-
butos em comum, podem ser generalizados no tipo de entidade VEÍCULO. Assim, CARRO e CAMINHÃO
tornam-se subclasses da superclasse generalizada VEÍCULO. O termo generalização refere-se, portanto,
ao processo de definição de um tipo de entidade generalizado com base nos tipos de entidade dados.

Figura 30 – Modelo EER Veículo

6.5 Restrições e características das hierarquias de especialização e ge-

neralização
As subclasses definidas por predicado (ou definidas por condição) são entidades nas quais podemos
identificar e determinar exatamente a qual subclasse o membro pertence ao aplicarmos critérios sobre
valores. Se todas as subclasses em uma especialização tiverem sua condição de membro no mesmo
atributo da superclasse, a especialização é chamada de especialização definida por atributo. Nesse
caso, todas as entidades com o valor que corresponde aos critérios pertencem à mesma subclasse.

Por exemplo, se o tipo de entidade VEÍCULO possuir um atributo Tipo_veiculo, podemos especificar a
condição de membro na subclasse CARRO pela condição (Tipo_veiculo = 'Carro'), que chamamos
de predicado de definição da subclasse.

Não possuindo um critério definido para determinar os membros em uma subclasse, esta é,
então, determinada pelo usuário do banco de dados quando aplicam a operação para incluir uma
6.5. RESTRIÇÕES E CARACTERÍSTICAS DAS HIERARQUIAS DE ESPECIALIZAÇÃO E GENERALIZAÇÃO 78

entidade à subclasse. Suponhamos que, para o tipo de entidade PESSOA, o usuário defina um critério
de idade, o qual define como CRIANÇA menores de 12 anos, ADOLESCENTE de 12 a 17 anos e ADULTO
pessoas com idade maior ou igual a 18 anos.

Existem duas restrições quando ao uso, a primeira é a restrição de disjunção, do inglês ’disjoint’,
que especifica que as subclasses da especialização devem ser disjuntas. Isso significa que uma entidade
pode ser um membro de, no máximo, uma das subclasses da especialização.

Se as subclasses não forem restringidas a serem disjuntas, seus conjuntos de entidades podem ser
sobrepostos (overlapping); ou seja, a mesma entidade pode ser um membro de mais de uma subclasse
da especialização, sendo o oposto do conceito de "disjoint", onde uma entidade só pode pertencer a
uma única subclasse. Imagine que temos uma superclasse, FUNCIONÁRIO, e duas subclasses, GERENTE e
ANALISTA. No caso de subclasses disjoint, um funcionário pode ser ou Gerente ou Analista, mas não
ambos. No entanto, em um cenário overlapping, um funcionário pode ser tanto um Gerente quanto
um Analista simultaneamente.

Figura 31 – Modelo EER Funcionários

A segunda restrição sobre a especialização é chamada de restrição de totalidade, que pode ser total ou
parcial. Essa restrição especifica que toda entidade na superclasse precisa ser membro de pelo menos
uma subclasse na especialização. No entanto, a especialização parcial permite que uma entidade não
pertença a nenhuma das subclasses.

As restrições são independentes e podem se combinar da seguinte forma:

6.6. HIERARQUIAS E RETICULADO DA ESPECIALIZAÇÃO E GENERALIZAÇÃO 79

• Disjunção total.

• Disjunção parcial.

• Sobreposição total

• Sobreposição parcial.

A escolha da restrição correta é feita com base no significado do mundo real que se aplica a cada
especialização. Geralmente, uma superclasse identificada por meio do processo de generalização costuma
ser total, pois a superclasse é derivada das subclasses. Existem algumas regras que nos guiam quanto
às restrições. Algumas delas são:

• A exclusão da entidade de uma superclasse implica que ela seja automaticamente excluída de
todas as subclasses às quais pertence.

• Inserir uma entidade em uma superclasse implica que a entidade seja obrigatoriamente inserida em
todas as subclasses definidas por predicado (ou definidas por atributo) para as quais a entidade
satisfaz o predicado de definição.

• Inserir uma entidade em uma superclasse de uma especialização total implica que a entidade seja
obrigatoriamente inserida em, pelo menos, uma das subclasses da especialização.

6.6 Hierarquias e reticulado da especialização e generalização

Uma subclasse pode ter mais subclasses especificadas nela, formando uma hierarquia ou um reticulado
de especializações. Por exemplo, um DESENVOLVEDOR é uma subclasse de FUNCIONÁRIO e também uma
superclasse de DESENVOLVEDOR_WEB, que representa a restrição do mundo real de que cada desenvol-
vedor web precisa ser um desenvolvedor. A hierarquia de especialização restringe que cada subclasse
tenha apenas um pai, resultando em uma estrutura de árvore; portanto, ela pode se relacionar como
uma subclasse apenas com uma superclasse. No sentido inverso, em um reticulado de especialização,
uma subclasse pode ser uma subclasse em mais de um relacionamento de superclasse/subclasse.

Seja reticulado ou hierarquia de especialização, uma subclasse herda os atributos de todas as suas
superclasses predecessoras, até chegar à raiz da hierarquia ou reticulado, se necessário. Por exemplo,
uma entidade em DESENVOLVEDOR_WEB_FULL_STACK herda todos os atributos dessa entidade como um
DESENVOLVEDOR e como FUNCIONÁRIO. Uma entidade pode existir em vários nós folha da hierarquia; o
nó folha é a representação de uma classe que não tem subclasses próprias.
Por exemplo, um membro de DESENVOLVEDOR_WEB_BACKEND também pode ser um membro de
ANALISTA_DE_DADOS_BIG_DATA.

Outro conceito importante é o de herança múltipla, na qual uma subclasse com mais de uma superclasse
é chamada de subclasse compartilhada. Por exemplo, GERENTE_DESENVOLVIMENTO herda diretamente
atributos e relacionamentos de múltiplas classes. Observe que a existência de pelo menos uma subclasse
compartilhada leva a um reticulado, portanto, à herança múltipla. Não existindo a subclasse comparti-
lhada, temos uma hierarquia em vez de um reticulado, e somente a herança simples existiria.

Há uma regra importante quanto à herança múltipla, que pode ser ilustrada pelo exemplo da sub-
classe compartilhada GERENTE_DESENVOLVIMENTO, que herda atributos de DESENVOLVEDOR e GERENTE.
Tanto DESENVOLVEDOR quanto GERENTE herdam os mesmos atributos de FUNCIONÁRIO. A regra declara
que, se um atributo (ou relacionamento) originado na mesma superclasse (FUNCIONÁRIO) é herdado
mais de uma vez por subclasses diferentes (DESENVOLVEDOR e GERENTE) no reticulado, então ele de-
verá ser incluído apenas uma vez na subclasse compartilhada (GERENTE_DESENVOLVIMENTO). Logo, os
atributos de FUNCIONÁRIO são herdados apenas uma vez na subclasse GERENTE_DESENVOLVIMENTO.
6.7. UTILIZANDO ESPECIALIZAÇÃO E GENERALIZAÇÃO NO REFINAMENTO DE ESQUEMAS CONCEITUAIS 80

Importante ressaltar que alguns modelos não permitem que uma entidade tenha tipos múltiplos, e,
portanto, uma entidade pode ser membro de apenas uma classe folha. Isso torna necessária a criação
de subclasses adicionais como nós folha para suprir as combinações possíveis de classes.

É importante destacar que os conceitos apresentados nesta seção se aplicam igualmente tanto à es-
pecialização quanto à generalização. Portanto, também podemos falar de hierarquias de generalização
e reticulados de generalização.

6.7 Utilizando especialização e generalização no refinamento de esque-

mas conceituais
Existem algumas diferenças entre os processos de especialização e generalização, e como são usados
para refinar os esquemas conceituais. No processo de especialização, normalmente começamos com
um tipo de entidade e depois definimos subclasses desse tipo de entidade pela especialização sucessiva;
ou seja, definimos repetidamente agrupamentos mais específicos do tipo de entidade. Esse processo é
conhecido como refinamento conceitual de cima para baixo (top-down).

No processo inverso, de baixo para cima (bottom-up), é possível atingir a mesma hierarquia ou re-
ticulado através do processo de generalização.

Em termos estruturais, hierarquias ou reticulados são muito semelhantes; a única diferença relaciona-se
à forma e ordem de criação da superclasse/subclasse. Na prática, é pouco provável que os processos de
especialização e generalização sejam rigidamente seguidos. Geralmente, ocorre a combinação dos dois
processos, nos quais as classes são incorporadas de maneira contínua durante a execução do projeto de
modelagem.

6.8 Modelagem dos tipos UNIAO usando categorias

Quando é necessário representar um relacionamento de superclasse/subclasse envolvendo mais de uma
superclasse, onde as superclasses representam diferentes tipos de entidades (ou seja, coleções de obje-
tos), denominamos essa subclasse de tipo de união ou categoria. Uma categoria pode ser criada com a
finalidade de unir duas ou mais superclasses (conjuntos de dados) distintas. Por exemplo, a categoria
PROPRIETÁRIO representa a união dos três conjuntos de entidades EMPRESA, BANCO e PESSOA. A cate-
goria, portanto, é um subconjunto da união de suas superclasses. Assim, uma entidade que é membro
da categoria PROPRIETÁRIO deve existir em apenas uma das superclasses, representando a restrição de
que um PROPRIETÁRIO pode ser uma EMPRESA, um BANCO ou uma PESSOA.

A herança de atributos funciona de maneira mais seletiva no caso de categorias. Por exemplo, cada
entidade PROPRIETÁRIO herda os atributos de uma EMPRESA, uma PESSOA ou um BANCO, depen-
dendo da superclasse à qual a entidade pertence, mas não de todas. É importante também definir
que a herança abrange apenas o universo descrito e não todos os possíveis atributos; por exemplo,
VEÍCULO_REGISTRADO inclui alguns carros e alguns caminhões, mas não outros tipos de entidade.

A categoria se divide em dois tipos: total e parcial. A categoria total mantém a união de todas as
entidades em suas superclasses, enquanto a categoria parcial pode manter um subconjunto dessa união.
Uma categoria total é representada em diagramas por uma linha dupla que conecta a categoria e o
círculo, ao passo que uma categoria parcial é indicada por uma linha simples.

As superclasses de uma categoria podem ter diferentes atributos-chave, como demonstrado pela ca-
tegoria PROPRIETÁRIO. Quando uma categoria é total (não parcial), ela pode ser representada alterna-
6.8. MODELAGEM DOS TIPOS UNIAO USANDO CATEGORIAS 81

tivamente como uma especialização total ou uma generalização total. Nesse caso, a escolha de qual
representação usar é subjetiva. Se as superclasses representam o mesmo tipo de entidades e comparti-
lham diversos atributos, incluindo os mesmos atributos-chave, a especialização/generalização é preferida;
caso contrário, a categorização (tipo de união) é mais apropriada.
O modelo entidade-relacionamento estendido é um grande trunfo ao ser aplicado para a resolução de
projetos complexos, por exemplo, em sistemas de informações geográficas e projetos de engenharia, pois
oferece uma estrutura clara e organizada para a gestão de informações complexas, onde a precisão e a
riqueza de detalhes são fundamentais.
 82

7 NoSql

O termo NoSQL, abreviação de "Not Only SQL", em tradução direta para o português "Não apenas
SQL", refere-se a uma categoria de sistemas de gerenciamento de banco de dados que não se baseiam
exclusivamente no modelo relacional tradicional. Esses sistemas oferecem alternativas mais flexíveis e
escaláveis para o armazenamento e manipulação de grandes volumes de dados.

7.1 Introdução ao NoSQL

A história dos bancos de dados NoSQL é marcada por inovações e a necessidade de adaptação às cres-
centes demandas tecnológicas. O termo NoSQL, reflete a evolução além dos sistemas tradicionais de
gerenciamento de banco de dados relacionais (RDBMS), que utilizam tabelas com linhas e colunas e
uma estrutura de dados rigidamente definida, os bancos NoSQL permitem a armazenagem de dados de
forma mais flexível e frequentemente mais eficiente para certos tipos de aplicações. São projetados para
lidar com grandes volumes de dados e suportam escalabilidade horizontal, ou seja, a adição de novos
servidores para aumentar a capacidade do sistema.

A expressão "NoSQL"foi utilizada pela primeira vez em 1998 por Carlo Strozzi para descrever seu banco
de dados Strozzi NoSQL, que não utilizava uma interface SQL tradicional (Strozzi, 1998). Contudo, foi
somente em 2009 que o termo ganhou popularidade como uma denominação para uma nova geração de
bancos de dados projetados para lidar com grandes volumes de dados distribuídos, alta escalabilidade e
flexibilidade de esquema.

O movimento NoSQL ganhou força com a publicação de artigos técnicos por gigantes da tecnologia.
Em 2003, o Google publicou um artigo sobre o Bigtable, um banco de dados distribuído altamente esca-
lável, usado internamente para diversos serviços (Chang et al., 2006). Em 2007, a Amazon apresentou
o Dynamo, um sistema de armazenamento distribuído chave-valor, que enfatizava alta disponibilidade
e escalabilidade (DeCandia et al., 2007).

Desde então, o NoSQL tem firmemente se estabelecido como uma tecnologia fundamental no panorama
do gerenciamento de dados. Empresas como Facebook, Twitter e LinkedIn utilizam bancos de dados
NoSQL para suportar suas operações diárias, demonstrando a robustez e a eficácia desses sistemas em
ambientes de alta demanda. A contínua evolução e inovação no campo do NoSQL garantem que ele
permanecerá uma escolha relevante e poderosa para o gerenciamento de dados em um mundo cada vez
mais orientado por dados.

7.2 Diferenças entre NoSQL e bancos de dados relacionais (SQL)

Os bancos de dados NoSQL e os bancos de dados relacionais (SQL) representam duas abordagens distin-
tas para o gerenciamento de dados. Cada um possui características próprias, vantagens e desvantagens,
adequando-se a diferentes tipos de aplicações e requisitos. As principais diferenças entre esses dois tipos
de bancos de dados.
7.2. DIFERENÇAS ENTRE NOSQL E BANCOS DE DADOS RELACIONAIS (SQL) 83

Tabela 25 – Comparação entre Bancos de Dados Relacionais (SQL) e NoSQL

Tópico Bancos de Dados Relacionais (SQL) Bancos de Dados NoSQL
Modelo de Dados
• Utilizam um modelo tabular, onde • Utilizam diversos modelos de dados, in-
os dados são armazenados em ta- cluindo chave-valor, documento, colunar e
belas com linhas e colunas. grafos.

• Os dados são organizados e relacio- • Oferecem flexibilidade no esquema, per-

nados por meio de chaves primárias mitindo alterações dinâmicas na estrutura
e estrangeiras. dos dados sem a necessidade de redefinir
um esquema rígido.
• A estrutura dos dados deve ser pre-
definido antes da inserção dos da- • São ideais para armazenar dados não es-
dos. truturados ou semi-estruturados.

Escalabilidade
• Escalam verticalmente, ou seja, • Projetados para escalar horizontalmente,
melhoram o desempenho ao adicio- permitindo a adição de mais servidores
nar mais recursos (CPU, memória) para distribuir a carga de trabalho.
a um único servidor.
• Oferecem alta disponibilidade e tolerância
• Escalabilidade horizontal é possível, a falhas, facilitando a gestão de grandes
mas pode ser complexa e cara de- volumes de dados distribuídos.
vido à necessidade de replicação e
fragmentação de dados.

Consistência e Dis-
ponibilidade
• Seguem o modelo ACID (Atomi- • Muitas vezes seguem o modelo BASE
cidade, Consistência, Isolamento, (Basicamente Disponível, Estado Suave,
Durabilidade) para garantir transa- Eventualmente Consiste), que prioriza a
ções seguras e consistentes. disponibilidade e a performance sobre a
consistência imediata.
• Focado em manter a integridade
dos dados, mesmo em cenários de • A consistência eventual é adequada para
falha. aplicações onde a alta disponibilidade é
mais crítica do que a consistência imediata
dos dados.

Linguagem de Utilizam a linguagem de consulta estrutu- Cada tipo de banco de dados NoSQL pode ter
Consulta rada (SQL) para definir, manipular e con- sua própria linguagem de consulta ou API.
sultar os dados.
7.3. FUNDAMENTOS DOS BANCOS DE DADOS NOSQL 84

7.3 Fundamentos dos Bancos de Dados NoSQL

7.3.1 Modelo de Dados
A modelagem de dados em bancos de dados NoSQL evoluiu significativamente ao longo do tempo,
cada abordagem surgindo em resposta a necessidades específicas de armazenamento e processamento
de dados.

Figura 32 – Modelo de dados NoSql.

Fonte: Logap

[Link] Modelo chave-valor

O modelo chave-valor é uma das primeiras e a mais simples formas de armazenamento de dados. Foi
inspirado por sistemas de armazenamento distribuído como o Amazon Dynamo (DeCandia et al., 2007),
e se tornou um exemplo e referência para muitos bancos de dados NoSQL. Seu intuito era garantir a
alta disponibilidade e escalabilidade horizontal em sistemas distribuídos.

Este modelo armazena dados como pares chave-valor, onde cada chave é única e mapeia diretamente
para um valor, em uma analogia simples, podemos entender esta estrutura como a recepção de um hotel.
Ao chegarmos no hotel e informamos a hospedagem, recebemos uma chave que contém o número do
nosso quarto e de posse desta chave temos acesso direto ao quarto.

Este modelo é comumente usado em informações que sejam uma unidade, como dados de sessão
de um usuário, carrinhos de compra em um e-commerce e preferências de configuração e caches.

[Link] Modelo de colunas

Inspirado pelo Bigtable do Google (Chang et al., 2006), o modelo de colunas foi desenvolvido para
otimizar o armazenamento e a consulta de grandes volumes de dados distribuídos. Criado para melhorar
a eficiência de leitura e escrita em grandes conjuntos de dados, especialmente para análise de big data,
este modelo armazena dados em colunas, onde cada coluna pode conter muitos elementos. As colunas
são agrupadas em famílias de colunas. O modelo de colunas se destaca em análises de big data e
processamento de grandes volumes de dados transacionais; os exemplos mais conhecidos e utilizados
deste modelo de dados são o Apache Cassandra e HBase.

[Link] Modelo de documentos

Em meados dos anos 2000, emergiu este modelo que ganhou bastante popularidade através de sistemas
como MongoDB e CouchDB. Ele foi concebido para manejar dados semi-estruturados e proporcionar
flexibilidade de esquema, permitindo que os dados sejam facilmente atualizados e evoluam com o tempo.
Nesse modelo, os dados são armazenados em documentos, geralmente nos formatos JSON, BSON ou
7.4. TIPOS DE BANCOS DE DADOS NOSQL 85

XML. Cada documento pode conter estruturas complexas e aninhadas.

* * *

[Link] Modelo de grafos

O modelo de grafos começou a ganhar destaque com a crescente necessidade de representar e consultar
redes complexas de dados. Neo4j, lançado em 2007, foi um dos primeiros bancos de dados a popularizar
essa abordagem. Ele foi desenvolvido para lidar com relações complexas e altamente interconectadas
entre dados. Este modelo utiliza estruturas de grafos para representar e armazenar dados. Os dados são
armazenados como nós, arestas e propriedades. Sua funcionalidade capacita buscas em redes complexas
de relacionamentos, como redes sociais, sistemas de recomendação e gerenciamento de fraudes.

7.4 Tipos de Bancos de Dados NoSQL

Os bancos de dados NoSQL, conforme descrito por Fowler (2015), são caracterizados pela flexibilidade
em relação ao esquema dos dados, permitindo que os registros sejam distribuídos em hardware comum
sem seguir o modelo matemático dos bancos de dados relacionais. De acordo com Kabakus e Kara
(2017), os bancos de dados relacionais (RDBMS) utilizam o modelo ACID para assegurar a consistência
e a integridade dos dados. Em contrapartida, os bancos de dados NoSQL operam com base no princípio
BASE, priorizando desempenho, disponibilidade e escalabilidade.

Contudo, muitos bancos de dados NoSQL têm incorporado suporte ao modelo ACID nos últimos anos,
conforme observado por Fowler (2015).

Classificação dos Bancos de Dados NoSQL

• Bancos de dados chave-valor: Os BD desta categoria possibilitam a visualização da base de

dados através de uma tabela hash. É um modelo considerado de facíl integração, possibilitando que
os dados sejam acessados rapidamente através da sua chave, quanto a manipulação, geralmente
baseada em get() e set(), as quais respectivas funções é de obter e entrar com valores.

• Bancos de dados de documentos: Os banco de dados de documentos são semelhantes aos BDs
de chave-valor, porém, no banco de documentos, o valor é estruturado e possui hierarquia.

• Bancos de dados de colunas: Os bancos de dados de colunas possuem estrutura similar a de

bancos de dados ER, porém, as informações armazenadas estão organizadas em colunas ao invés
de em linha, otimizando o banco.

• Bancos de dados de grafos: Este banco de dados armazena as informações compostas por três
elementos: sujeito, propriedade ou relacionamento e valor. Seu foco é na criação de relaciona-
mentos entre dados. Porém, diferentemente dos bancos de dados ER, os dados são armazenados
em registros triplos, composto por sujeito, predicado e objeto.

7.5 Ferramentas e Tecnologias Populares

Existem diversas ferramentas e tecnologias no campo dos banco de dados NoSql, cada uma adaptada
a diferentes tipos de dados e caso de uso.
7.6. OPERAÇÕES BÁSICAS E CONSULTAS 86

Tabela 26 – Indicação de Casos de uso de Bancos de Dados

Ferramenta Tipo Casos de Uso
MongoDB Documentos Aplicações web, big data, sistemas de geren-
ciamento de conteúdo
Cassandra Colunar Análise de big data, aplicações de alta dis-
ponibilidade, streaming de dados em tempo
real
Neo4j Grafos Redes sociais, motores de recomendação, de-
tecção de fraudes
Amazon Chave-Valor Comércio eletrônico, jogos, internet das coi-
DynamoDB sas (IoT)
Redis Chave-Valor Cache, filas de mensagens, sessões de usuá-
rio
Tabela 27 – Comparação de Ferramentas e Tecnologias Populares NoSQL

7.6 Operações Básicas e Consultas

Cada banco de dados NoSql pode possuir uma linguagem. Para esta apostila iremos adotar o MongoDB
para exemplificação.

O MongoDB é um banco de dados NoSQL baseado em documentos que utiliza documentos JSON-
like (BSON) para armazenar dados.

1. Inserção de documentos:

Sintaxe:
1 db . collection . insertOne ({
2 < campo >: < valor > ,
3 ...
4 }) ;

Exemplo:
1 db . collection . insertOne ({
2 nome : " Joao " ,
3 idade : 30 ,
4 cidade : " Sao Paulo "
5 }) ;

2. Consulta de documentos:

Sintaxe:
1 db . collection . find ({ < campo >: < valor >}) ;

Exemplo:
1 db . collection . find ({ cidade : " Sao Paulo " }) ;

3. Atualizar documento:

Sintaxe:
7.6. OPERAÇÕES BÁSICAS E CONSULTAS 87

1 db . collection . updateOne (
2 { < variavel >: < valor >} ,
3 { $set :{ < campo >: < valor >}}
4 );

Exemplo:
1 db . collection . updateOne (
2 { nome : " Joao " } ,
3 { $set : { idade : 31 } }
4 );

4. Deletar documentos:

Sintaxe:
1 db . collection . deleteOne ({ < campo >: < valor >}) ;

Exemplo:
1 db . collection . deleteOne ({ nome : " Joao " }) ;

A análise do ecossistema NoSQL revela uma evolução na forma como os dados são geridos e utilizados
em aplicações modernas. Com sua flexibilidade e capacidade de escalabilidade horizontal, os bancos
de dados NoSQL se adaptam às demandas de armazenamento e processamento de grandes volumes de
dados, superando as limitações dos sistemas relacionais tradicionais. A diversidade de modelos, como
chave-valor, colunar, de documentos e de grafos, proporciona às organizações a possibilidade de escolher
a solução mais adequada às suas necessidades específicas. Assim, ao considerar a implementação de
um sistema de gerenciamento de dados, é essencial avaliar as características únicas do NoSQL, que
prometem não apenas atender, mas também impulsionar a inovação em um mundo cada vez mais
orientado por dados.
 88

Referências

ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. Pearson, 2019.

KORTH, H.; SILBERCHATS, A. Sistemas de Bancos de Dados. 7a. Edição, LTC, 2020.

RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de Gerenciamentos de Bancos de Dados. 3a ed.,

McGraw Hill Brasil, 2008.

HEUSER, Carlos Alberto. Projeto de banco de dados. 6a. ed. Porto Alegre: Sagra, 2009. 282 p.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados.

Editora Campus. 5a Edição, 2006.

DATE, Christopher J. Introdução a Sistemas de Banco de Dados. Editora Campus. 1a Edição, 2004.

ROB, Peter; CORONEL, Carlos. Sistemas de Banco de Dados: Projeto, Implementação e

Administração. 1ª Edição, 2010.