Apostila Fic Dev2 BD Final

GOVERNADOR DO ESTADO DE MATO GROSSO
Mauro Mendes Ferreira
MINISTRO DA EDUCAÇÃO
Renato Janine Ribeiro
MINISTRO DA CIÊNCIA TECNOLOGIA E INOVAÇÕES

Luciana Santos
SECRETÁRIO DE ESTADO DE CIÊNCIA TECNOLOGIA E INOVAÇÃO DE MT

Allan Kardec
SUPERINTENDENTE DE EDUCAÇÃO PROFISSIONAL E SUPERIOR

SECITECI/MT
Pollyana Cristina Peixoto Peron
REITORA DA UNIVERSIDADE DO ESTADO DE MATO GROSSO

UNEMAT
Vera Maquêa
COMISSÃO DE ELABORAÇÃO DO MATERIAL DIDÁTICO

Prof. Dr.Robson Gomes de Melo. – RISC/UNEMAT Cáceres
Prof. Dr. Nivaldi Calonego Junior – RISC/UNEMAT Cáceres
DIAGRAMAÇÃO E ARTE
João Pedro Rodrigues Vilela
Leonardo Ribeiro de Alcântara
Produção Editorial
Título: Banco de dados

Organizadores: Prof°. Dr. Robson Gomes de Melo
Prof°. Dr.- Nivaldi Calonego Júnior
Autores: Edie C. Santana
Prof. Msc. Willyan Alves
Elmo Faria
Nilsen Simões
César Eduardo
Josiel Maimone Figueiredo
Marcos Paulo de Mesquita
Arte e diagramação: João Pedro Rodrigues Vilela
Leonardo Ribeiro de Alcântara
Ficha Catalográfica
Cuiabá/MT - 2023
Texto Introdutório
Bancos de dados
SUMÁRIO
1 Introdução à Banco de Dados 6 4.1 Linguagem SQL 45
1.1 O que é um Banco de Dados? 8 4.2 Linguagem de Definição de Da-
1.2. Do BIT ao Big Data: Evolução dos dos (DDL) 45
Bancos de Dados 11 5 Data Manipulation Language (DM
1.3. Diferentes tipos de usuários de L) 50
Bancos de Dados e suas responsa- 5.1 Data Manipulation Language
bilidades 14 (DML)52
1.4. Modelagem Conceitual 17 5.2 INSERT 52
1.5. Modelo Entidade-Relaciona- 5.3 DELETE 53
mento (MER) 18 5.4 UPDATE 54
1.6. Ferramentas para modelagem 5.5 SELECT 55
21
6 O Comando SELECT: Junções 59
2 Modelagem Lógica e Modelagem
Relacional 23 6.1 Junções 61
2.1 Modelo Lógico 25 6.2 Junção Interna 63
2.2 Modelo Relacional 26 6.3 Junção Interna – USING e INNER63
3 Mapeamento do Modelo Concei- 6.4 Junção utilizando operadores
tual para o Modelo Lógico 30 (<, >) 65
3.1 Mapear entidades e seus atribu- 6.5 Junção externa 66
tos33 7 Agregação, Visão e Subconsulta
3.2 Mapear relacionamento relacio- 74
namentos e seus atributos 34 7.1 Funções Agregadas 76
3.2.1 - Relacionamento 1:1 (um para 7.1.1 Função Contador (COUNT) 77
um)34
7.1.2 Função Média (AVG) 78
3.2.2 - Mapear relacionamentos 1:n
7.1.3 Função Soma (SUM) 79
(um para n) 35
7.1.4 Funções de Mínimo e Máximo
3.2.3 Mapear relacionamentos n:n
(MIN e MAX )80
(muitos para muitos) 36
7.2 Usando GROUP BY na cláusula
3.3 Mapear Generalização/Especia-
WHERE81
lização38
7.2.1 GROUP BY com HAVING 81
3.4. Conclusão 39
7.2.2 Usando GROUP BY no padrão
4 Linguagem SQL, definição de da-
SQL82
dos (DDL) 40
5
Banco de dados
7.3 Subconsultas 83 9.3.1 Disco Lógico 112

7.3.1 Tipos de Subconsultas 83 9.3.2 Físico 114
7.3.1 Subconsulta – Regra Geral 84 10 Modelagem Lógica: Normaliza-
7.3.3 Subconsulta – Regras 84 ção 116
7.3.4 Subconsultas e o Operador IN 10.1 Normalização em Banco de Da-

85 dos Relacional 118
7.3.5 Subconsultas e o Operador NOT 10.2 Eliminando as Redundâncias119

IN86 11 Modelagem Lógica: Normaliza-
7.3.6 Múltiplos Níveis de Alinhamento ção 121
86 11.1 DDL - Manipulando índices em
7.3.7 Subconsultas E Operadores De banco de dados relacionais 123
Comparação87 11.2 Otimizando Consultas SQL 125
7.3.8 Operadores Modificadores ALL 12 CONTROLE DE USUÁRIOS 126
e ANY 88 12.1 Create User 128
7.3.9 Subconsultas correlatas 89 12.2 Grant 129
7.3.10 Criando Uma VIEW 90 12.3 Revoke 130
7.3.11 Funções e VIEWS – JOIN VIEW 93 13 CONTROLE DE TRANSAÇÕES 131
8 Dimensões de um SGBD 94 13.1 Transações 135
8.1 Arquitetura de um SGBD 96 13.2 Isolamento de Transações 135
8.1.1 Cliente/Servidor 96 13.3 Níveis de Isolamento 135
8.1.2 On Premise 96 13.4 Bloqueios 136
8.1.3 Cloud 96 13.5 MVCC 137
8.2 Modelo de Dados 97 13.6 Logs 138
8.3 Controle de Transações e Con- 14 PROCEDIMENTOS ARMAZENADOS
corrência100 139
8.4 Tipos de Dados 102 14.1 Funções 141
8.5 Dispositivos de Armazenamento 14.2 Cursores 145
105
14.3 Gatilhos (Triggers) 147
9 Projeto Físico 107
9.1 O Projeto Físico 109
9.2 Uso de Memória: Processos 110
9.3 Uso de Disco 111
6
Bancos de dados
Notas
7
Dia 1
INTRODUÇÃO À
BANCO DE DADOS
CÉSAR EDUARDO GUARIENTI
Bancos de dados
Desafio:
Criar um Diagrama de Entidade Relacionamento (Modelo Conceitual) de
acordo com o que foi pedido na Atividade 1 de Algoritmos, do exemplo da
escola com diretor, professores e disciplinas. Considere que a escola pode
ter ensino fundamental, médio e superior. Acrescente a entidade “Estudan-
te”.
Objetivos da seção
• Contextualizar o desenvolvimento dos sistemas de gerenciamento

de bancos de dados ao longo do tempo.
• Apresentar e discutir tipos de usuários de Bancos de Dados e suas

responsabilidades.
• Desenvolver de modelagem de banco de dados, aplicando o Modelo

Conceitual e o Modelo Entidade-Relacionamento.
• Exercitar a modelagem de dados com o uso de software de auxílio à

modelagem de dados.
Nesta disciplina, abordaremos os conceitos fundamentais

de bancos de dados, incluindo sua evolução histórica, defini-
ções, tipos de usuários e modelos de modelagem de dados.
Você aprenderá sobre a evolução histórica dos bancos de
dados, tipos de usuários e as principais abordagens de mo-
delagem de dados. Vamos começar!
9
Cap 1: Introdução
1.1 O que é um Banco de Dados?

Antes de explicar o que é um Banco de Dados, imagine que você
tenha coleção de livros em casa (ver Figura 1.1) e deseja organi-
zá-los de maneira eficiente para facilitar a localização e consulta
quando necessário.
Como você poderia fazer isso?
Figura 1.1 - Imagem elaborada pelo autor.
Uma sugestão para resolução deste problema seria criar um

catálogo dos seus livros em uma estante, organizando-os por:
* título;
* autor;
* gênero.
Esta estante possuirá várias prateleiras, cada uma delas eti-
quetadas com uma categoria específica (romance, ficção cientí-
fica, biografia, etc.).
Dentro de cada prateleira, você pode organizar os livros em or-
dem alfabética pelo sobrenome do autor, facilitando a busca e a
recuperação dos livros quando você precisar.
Agora, vamos considerar um exemplo real. Pense em uma bi-
blioteca pública. A biblioteca possui um sistema informatizado
que gerencia seu acervo de livros, CDs, DVDs e outros materiais.
Esse sistema é um banco de dados real que armazena informa-
ções sobre cada item do acervo, como título, autor, gênero, data
de publicação e localização na biblioteca. Assim como na estan-
te de livros, o banco de dados da biblioteca permite que os fun-
10
Bancos de dados
cionários e os usuários encontrem e acessem facilmente os

materiais de que precisam. Notas
Nesses exemplos, tanto o lúdico quanto o real, um banco de

dados é uma ferramenta essencial para armazenar, organi-
zar e gerenciar informações de maneira eficiente e acessível.
Um banco de dados é uma coleção organizada de dados
armazenados e acessados eletronicamente ou manualmen-
te. Os bancos de dados são projetados para permitir o ar-
mazenamento, recuperação, modificação e gerenciamento
eficientes de dados.
Turban, Rainer Júnior e Potter (2005, p. 523) definem um
banco de dados como um conjunto lógico de arquivos in-
ter-relacionados, que armazenam dados e suas associações
para evitar diversos problemas encontrados em ambientes
de arquivos tradicionais. Medeiros (2013, p. 15) amplia essa
definição, descrevendo um banco de dados (ou, abreviada-
mente, BD) como um conjunto de dados organizados de ma-
neira específica, com o propósito de armazenamento per-
sistente e mecanismos de manipulação para a obtenção e
recuperação de informações em um sistema de informação.
O desenvolvimento dos bancos de dados surgiu da neces-
sidade humana de registrar (armazenar) dados e informa-
ções para consulta futura sempre que necessário.
Falamos sobre o que é um banco de dados, sobre os dados
armazenados e informações, existe um outro conceito que é
o conhecimento. Vamos revisar cada um destes conceitos:
• Banco de dados. É uma coleção organizada de dados ar-

mazenados e acessados eletronicamente. Os dados em
um banco de dados são estruturados de forma a facilitar
o gerenciamento, a recuperação e a manipulação dessas
informações. Bancos de dados são essenciais para uma
ampla variedade de aplicações, como sistemas de geren-
ciamento de informações, sites, aplicativos móveis e servi-
ços empresariais.
• Dado. Os dados são a matéria-prima do mundo digi-

tal, consistindo em fatos brutos e desorganizados, como
números, textos, imagens e sons. Por si só, um dado não
possui significado ou contexto, mas quando processado e
organizado, ele se transforma em informação. Exemplo: A
temperatura medida em uma cidade em um determinado
11
Cap 1: Introdução
dia (por exemplo, 25°C) é um dado. Nesse caso, a temperatura

é um fato quantificável, mas, por si só, não nos diz muito sobre
o clima geral ou as condições na cidade.
• Informação. A informação é o resultado do processamento e

organização dos dados. Ela adquire significado e contexto, per-
mitindo que os usuários compreendam e utilizem esses dados
de maneira mais eficiente. A informação é a base para a to-
mada de decisões e para a resolução de problemas. Exemplo:
Quando combinamos o dado da temperatura (25°C) com ou-
tras informações, como a data, a localização e as condições
climáticas (ensolarado, nublado, chuvoso etc.), temos uma in-
formação mais completa sobre o clima na cidade naquele dia.
Essa informação nos ajuda a decidir, por exemplo, que tipo de
roupa usar ou se devemos levar um guarda-chuva.
• Conhecimento. O conhecimento é o entendimento e a sabe-

doria adquiridos através da análise e interpretação da infor-
mação. Ele permite que os indivíduos apliquem a informação
de maneira eficaz em diferentes situações, resolvendo pro-
blemas complexos e tomando decisões informadas. Exemplo:
Com base nas informações sobre o clima da cidade e nosso
conhecimento prévio sobre padrões climáticos e experiências
pessoais, podemos prever como o clima pode mudar ao longo
do dia e nos preparar adequadamente. Por exemplo, podemos
concluir que, se está ensolarado e quente às 10h da manhã,
provavelmente ficará ainda mais quente à tarde e, portanto,
devemos usar roupas leves e levar água para nos mantermos
hidratados.
Durante o nosso estudo, você irá se deparar com os termos “Sis-

temas de Banco de Dados (SBDs)” e “Sistemas de Gerenciamento
de Banco de Dados (SGBD)” que embora sejam frequentemente
usados de maneira intercambiável, eles têm significados distintos:
• Um sistema de banco de dados refere-se à estrutura geral e ao

conjunto de componentes usados para armazenar, gerenciar e
recuperar informações em um ambiente organizado de dados.
Ele inclui o próprio banco de dados, que contém os dados ar-
mazenados, bem como as interfaces, aplicativos e ferramentas
que permitem o acesso e a manipulação desses dados. Um
sistema de banco de dados pode ser usado para gerenciar in-
formações em diversos setores e aplicações, como negócios,
12
Bancos de dados
saúde, educação e governo.

Notas
• Um SGBD é um software específico projetado para geren-

ciar e controlar o acesso aos dados armazenados em um
banco de dados. Ele fornece uma interface entre os usu-
ários ou aplicativos e o banco de dados, facilitando a re-
alização de consultas, inserções, atualizações e exclusões
de dados de maneira eficiente e segura. O SGBD também
é responsável por manter a integridade, a consistência e a
segurança dos dados armazenados, bem como por reali-
zar tarefas de gerenciamento, como backup, recuperação
e otimização de desempenho.
Para entender como tudo isso começou é importante e ne-

cessário estudarmos o histórico dos Bancos de Dados.
1.2. Do BIT ao Big Data: Evolução dos

Bancos de Dados
A necessidade de registrar e guardar informações vem
muito antes do surgimento dos sistemas de banco de dados
atuais. Desde os tempos pré-históricos, os seres humanos
sempre tiveram a necessidade de registrar e armazenar in-
formações para uso futuro. Os primeiros exemplos de “ban-
cos de dados” incluem pinturas rupestres, que documenta-
vam a vida cotidiana, e hieróglifos egípcios, que registravam
eventos históricos e rituais religiosos. Os sistemas de registro
e armazenamento de informações na antiguidade remonta
a aproximadamente 10.000 a.C., quando os primeiros pasto-
res começaram a criar rebanhos de ovelhas. Eles precisavam
encontrar uma maneira de controlar o número de animais
em seu rebanho para garantir que não faltassem ovelhas
(perdidas ou mortas por predadores) ou que outras não se
juntassem ao rebanho inadvertidamente. O exemplo dos
pastores e seus rebanhos, ilustra a importância do registro
e do gerenciamento de informações desde os primórdios da
civilização humana. Percebe-se que a necessidade de ar-
mazenar e recuperar dados de maneira eficiente e acessível
tem sido um impulso constante para o desenvolvimento e a
evolução dos bancos de dados ao longo da história.
À medida que a sociedade se tornou mais complexa, a
quantidade e a variedade de informações a serem armaze-
nadas e gerenciadas também aumentaram. A história dos
13
Cap 1: Introdução
bancos de dados é uma história de inovação e adaptação con-

tínua que cresce conforme as demandas da sociedade e da tec-
nologia. Desde os primeiros dias do armazenamento de informa-
ções digitais até a explosão do Big Data, a evolução dos bancos
de dados tem sido marcada por avanços significativos e mudan-
ças paradigmáticas.
No início da era computacional, os dados armazenados em bits
( valor binário de 0 ou 1) eram armazenados e manipulados de
forma primitiva, geralmente usando cartões perfurados e fitas
magnéticas para guardar informações. Nesse contexto, os ban-
cos de dados eram limitados em termos de capacidade e funcio-
nalidade.
Com o tempo, os sistemas de gerenciamento de arquivos foram
modificados para organizar e gerenciar informações de manei-
ra mais eficiente. No entanto, esses sistemas ainda enfrentavam
problemas, como redundância de dados, inconsistência e dificul-
dade de acesso às informações. A necessidade de um sistema
mais robusto e eficiente levou ao desenvolvimento dos sistemas
de gerenciamento de banco de dados (SGBD). Todo este proces-
so foi realizado para solucionar o problema do gerenciamento
de grandes quantidades de informações e dados em um mundo
cada vez mais digitalizado. Vamos examinar agora, algumas das
etapas-chave nessa evolução.
Armazenamento em papel. Antes dos computadores, as infor-
mações eram armazenadas e gerenciadas em papel. Esses regis-
tros eram organizados manualmente, geralmente em arquivos ou
bibliotecas, e sua recuperação e atualização eram demoradas e
trabalhosas.
Sistemas de arquivos. Com o advento dos primeiros computa-
dores, surgiram sistemas de arquivos eletrônicos. Esses sistemas
armazenavam dados em arquivos individuais, que eram organi-
zados em diretórios e subdiretórios. Embora representasse uma
melhoria significativa em relação ao armazenamento em papel,
os sistemas de arquivos apresentavam problemas de redundân-
cia, inconsistência e dificuldade no acesso e na recuperação de
informações.
Bancos de dados hierárquicos e de rede. Na década de 1960,
os bancos de dados hierárquicos e de rede surgiram como so-
luções para os problemas associados aos sistemas de arquivos.
Eles permitiam que os dados fossem organizados em uma estru-
tura mais complexa, com registros e relacionamentos entre eles.
Porém, esses modelos tinham suas próprias limitações, como a
rigidez na organização dos dados e a complexidade na recupera-
14
Bancos de dados
ção e manipulação das informações. O IBM IMS, lançado em

1968, é um exemplo de um SGBD hierárquico. Foi desenvolvido Notas
para gerenciar informações para o programa Apollo da NASA
e ainda está em uso em algumas organizações.
Bancos de dados relacionais. Na década de 1970, o modelo
relacional de banco de dados foi proposto por Edgar F. Codd.
Nesse modelo, os dados são organizados em tabelas com li-
nhas e colunas, e as relações entre as tabelas são estabele-
cidas por meio de chaves primárias e estrangeiras. O modelo
relacional simplificou a manipulação e a recuperação de da-
dos, permitindo consultas complexas e flexíveis, e tornou-se o
padrão dominante para o gerenciamento de dados. O Ora-
cle Database, lançado em 1979, foi o primeiro SGBD comercial
baseado no modelo relacional. Hoje, é um dos SGBDs mais
populares e amplamente utilizados no mundo.
Bancos de Dados Orientados a Objetos. Na década de
1980, os bancos de dados orientados a objetos surgiram
como uma resposta à crescente complexidade dos dados e
à popularidade das linguagens de programação orientadas
a objetos. Esses bancos de dados armazenam informações
como objetos, com propriedades e métodos, em vez de ta-
belas. O ObjectStore, lançado em 1988, é um exemplo de um
SGBD orientado a objetos. Foi projetado para ser integrado
diretamente às linguagens de programação orientadas a
objetos, como C++ e Java.
Bancos de dados objeto-relacionais. Surgiram na década
de 1990 como uma tentativa de combinar os melhores aspec-
tos dos bancos de dados relacionais e orientados a objetos.
Esses bancos de dados incorporam características dos dois
modelos, permitindo que os dados sejam representados tan-
to na forma de tabelas (como no modelo relacional) quanto
na forma de objetos (como no modelo orientado a objetos).
Os bancos de dados objeto-relacionais proporcionam uma
maior flexibilidade na representação e manipulação de da-
dos complexos e heterogêneos, como dados multimídia, da-
dos geoespaciais e dados temporais. O PostgreSQL, lança-
do em 1996, é um exemplo de um SGBD objeto-relacional de
código aberto. Ele combina a simplicidade e a flexibilidade
do modelo relacional com o suporte a objetos complexos e
herança.
Bancos de dados NoSQL. Com o crescimento da internet
e o surgimento de aplicações que lidam com grandes volu-
mes de dados não estruturados, os bancos de dados NoSQL
começaram a ganhar destaque na década de 2000. Esses
15
Cap 1: Introdução
bancos de dados são projetados para serem escaláveis, flexí-

veis e distribuídos, proporcionando soluções eficientes para o ge-
renciamento de big data e aplicações de alta disponibilidade. O
MongoDB, lançado em 2009, é um exemplo de um banco de da-
dos NoSQL baseado em documentos. Ele armazena dados em um
formato semelhante ao JSON chamado BSON, o que o torna espe-
cialmente adequado para armazenar dados semi-estruturados,
como documentos de texto e registros de log.
Bancos de dados NewSQL e distribuídos. Na última década, sur-
giram bancos de dados NewSQL e distribuídos, que combinam
aspectos dos bancos de dados relacionais e NoSQL. Eles ofere-
cem escalabilidade e flexibilidade, mantendo as propriedades
de consistência e integridade dos bancos de dados relacionais,
atendendo às demandas de aplicações modernas e complexas.
O CockroachDB, lançado em 2015, é um exemplo de um banco
de dados NewSQL. Ele fornece uma camada de compatibilidade
SQL e oferece tolerância a falhas, escalabilidade e consistência
de dados em um ambiente distribuído.adas a objetos, como C++
e Java.
Na era da internet e do big data, os bancos de dados continu-
am a evoluir para atender às crescentes demandas de armaze-
namento e recuperação de informações. A evolução dos bancos
de dados de bits simples até o Big Data ilustra a incrível jornada
que a tecnologia de armazenamento e gerenciamento de infor-
mações percorreu ao longo das últimas décadas.
À medida que continuamos a gerar e consumir dados em esca-
las cada vez maiores, podemos esperar que os bancos de dados
evoluam ainda mais, adaptando-se às necessidades em cons-
tante mudança da sociedade e do mundo digital.
1.3. Diferentes tipos de usuários de Bancos

de Dados e suas responsabilidades
Os bancos de dados desempenham um papel crucial no arma-

zenamento e gerenciamento de informações em organizações de
todos os tamanhos e setores. Para garantir que esses sistemas
funcionem de maneira eficiente e segura, diferentes tipos de usu-
ários desempenham funções específicas no gerenciamento e na
utilização dos bancos de dados. Vamos explorar essas funções e
responsabilidades em detalhes:
• Usuário Final. O usuário final é a pessoa que interage direta-
16
Bancos de dados
mente com os dados armazenados no banco de dados,

geralmente por meio de uma aplicação. Esses usuários Notas
podem incluir funcionários que acessam informações de
clientes, gerentes que analisam relatórios financeiros ou
qualquer pessoa que precise recuperar e trabalhar com
dados armazenados no banco de dados. O usuário final é,
muitas vezes, o principal beneficiário dos sistemas de ge-
renciamento de banco de dados, já que esses sistemas
foram projetados para simplificar e agilizar o acesso às in-
formações.
• Programador. O programador é responsável pelo desen-

volvimento e manutenção de aplicações que acessam e
manipulam os dados no banco de dados. Eles trabalham
com linguagens de programação e ferramentas de de-
senvolvimento de software para criar interfaces, lógicas de
negócios e funcionalidades que permitem aos usuários fi-
nais interagir com os dados. Os programadores também
são responsáveis por garantir que as aplicações funcio-
nem corretamente e se integrem de maneira eficiente ao
banco de dados.
• DBA (Database Administrator). O DBA é o profissional res-

ponsável pelo gerenciamento e manutenção dos sistemas
de gerenciamento de banco de dados. Eles garantem que
o banco de dados funcione de maneira eficiente, monito-
rando seu desempenho, otimizando consultas e ajustan-
do a infraestrutura conforme necessário. Os DBAs também
são responsáveis por garantir a integridade e a segurança
dos dados, implementando políticas de backup, recupera-
ção e proteção de dados.
• Engenheiro de Dados. O engenheiro de dados é respon-

sável pelo design e otimização da arquitetura de dados,
garantindo a qualidade e escalabilidade dos sistemas de
gerenciamento de banco de dados. Eles trabalham com
tecnologias e técnicas avançadas de armazenamento e
processamento de dados para garantir que a infraestru-
tura seja capaz de lidar com volumes crescentes de infor-
mações e demandas de desempenho. O engenheiro de
dados também colabora com outros profissionais, como
analistas de dados e cientistas de dados, para garan-
tir que os dados sejam facilmente acessíveis e utilizáveis
17
Cap 1: Introdução
para análises e insights.
• DPO (Data Protection Officer). O DPO é responsável por garan-

tir que a organização cumpra as regulamentações de prote-
ção de dados e privacidade, como o GDPR (Regulamento Geral
de Proteção de Dados) na União Europeia. Eles desenvolvem e
implementam políticas e procedimentos para proteger infor-
mações pessoais e sensíveis armazenadas no banco de da-
dos, garantindo que os dados sejam coletados, armazenados e
processados de acordo com as leis e regulamentos aplicáveis.
• CDO (Chief Data Officer). O CDO é um executivo de alto nível

responsável por definir a estratégia e as políticas de dados da
organização. Eles trabalham com outras lideranças da empre-
sa para garantir que os dados sejam usados de maneira efi-
ciente e eficaz, gerando valor e impulsionando a tomada de
decisões baseada em dados. O CDO também supervisiona a
governança de dados, garantindo que os dados sejam coleta-
dos, armazenados e gerenciados de acordo com os padrões e
regulamentações aplicáveis.
Vamos usar a analogia de um restaurante para entender os di-

ferentes tipos de usuários de bancos de dados:
• Usuário Final. Os clientes do restaurante, que consomem os

pratos servidos (dados).
• Programador. O chef que cria e prepara os pratos (aplicações).
• DBA (Database Administrator). O gerente do restaurante, res-

ponsável pelo funcionamento eficiente e pela manutenção das
instalações.
• Engenheiro de Dados. O arquiteto responsável pelo projeto e

layout do restaurante, garantindo que seja funcional e escalá-
vel.
• DPO (Data Protection Officer). A pessoa encarregada de garan-

tir que o restaurante siga todas as regulamentações de saúde
e segurança.
• CDO (Chief Data Officer). O proprietário do restaurante, que de-

fine a estratégia e as políticas de negócios.
18
Bancos de dados
Notas
Bancos de dados possuem sistemas complexos que re-
querem a colaboração de várias funções e responsabilida-
des para funcionar corretamente. Cada tipo de usuário de
banco de dados desempenha um papel crítico no gerencia-
mento e na utilização das informações armazenadas nesses
sistemas. Essa diversidade de papéis garante que os dados
sejam gerenciados de maneira eficiente, segura e conforme
as regulamentações aplicáveis, garantindo que a organiza-
ção possa extrair valor máximo de suas informações.
1.4. Modelagem Conceitual
A modelagem conceitual é uma fase fundamental no pro-

cesso de desenvolvimento de sistemas de banco de dados.
O objetivo dessa etapa é criar um modelo abstrato e de alto
nível que represente a estrutura e as relações entre os dados
a serem armazenados. A modelagem conceitual permite aos
desenvolvedores e às partes interessadas entenderem me-
lhor os requisitos do sistema e como os dados serão organi-
zados e gerenciados.
Ao criar um modelo conceitual, os desenvolvedores e ana-
listas de sistemas se concentram nos seguintes elementos:
• Entidades. As entidades são os objetos ou conceitos do

mundo real que serão representados no banco de dados.
Por exemplo, em um sistema de gerenciamento de pedi-
dos, as entidades podem incluir clientes, pedidos e produ-
tos.
• Atributos. Os atributos são as características ou proprieda-

des que descrevem as entidades. No exemplo do sistema
de gerenciamento de pedidos, os atributos de um cliente
podem incluir nome, endereço e número de telefone, en-
quanto os atributos de um produto podem incluir descri-
ção, preço e quantidade em estoque.
• Relacionamentos. Os relacionamentos descrevem como

as entidades estão associadas umas às outras. No exem-
plo do sistema de gerenciamento de pedidos, pode ha-
ver um relacionamento entre clientes e pedidos, indicando
que um cliente pode fazer vários pedidos e cada pedido
pertence a um cliente específico.
19
Cap 1: Introdução
• Restrições. As restrições são regras que definem limitações ou

condições sobre os dados e suas relações. Por exemplo, no sis-
tema de gerenciamento de pedidos, pode haver uma restrição
de que o preço de um produto deve ser maior que zero ou que
um cliente deve ter, pelo menos, um pedido.
Uma abordagem popular é a utilização do Modelo Entidade-Re-

lacionamento (MER) que possibilita a criação de diagramas visu-
ais que ilustram as entidades, atributos, relacionamentos e restri-
ções do sistema de banco de dados.
1.5. Modelo Entidade-Relacionamento (MER)
Modelo Entidade-Relacionamento (MER) é uma técnica de mo-

delagem de dados que utiliza diagrama de Entidade-Relaciona-
mento (DER) para representar visualmente a estrutura e as rela-
ções entre os dados em um sistema de banco de dados. A Figura
1.2 ilustra os principais elementos.
Figura 1.2 - Elementos de um Diagrama Entidade Relacionamento (Fonte: Peter Chen)
Os principais elementos de um Modelo Entidade-Relaciona-

mento incluem:
• Entidades. São objetos ou conceitos do mundo real que pos-

suem significância no contexto do sistema de banco de da-
dos. As entidades são representadas por retângulos nos DERs.
20
Bancos de dados
Exemplos de entidades podem incluir: Cliente, Produto, Pe-

dido, etc. Notas
• Atributos. São as propriedades ou características que des-

crevem as entidades. Os atributos são representados por
elipses conectadas às entidades correspondentes nos
DERs. Por exemplo, os atributos de um Cliente podem in-
cluir: Nome, Endereço, Telefone, etc:
• Atributo Composto. São atributos que podem

ser decompostos em outros atributos menores e
mais significativos. Por exemplo, o atributo “Ende-
reço” pode ser dividido em atributos como “Rua”,
“Número”, “Bairro”, “Cidade” e “CEP”.
• Atributo Multivalorado. São atributos que podem

ter múltiplos valores para uma única instância da
entidade. Por exemplo, em uma entidade “Clien-
te”, o atributo “Telefone” pode ser multivalorado se
um cliente tiver mais de um número de telefone.
• Atributo Derivado. São atributos cujos valores

podem ser derivados ou calculados a partir de
outros atributos. Por exemplo, em uma entidade
“Funcionário”, o atributo “Idade” pode ser deriva-
do a partir da data de nascimento.
• Chave Primária (Atributo chave). É um atributo especial (ou

conjunto de atributos) que identifica de forma única cada
instância de uma entidade. Cada entidade deve ter uma
chave primária. Nos DERs, as chaves primárias são geral-
mente sublinhadas.
• Relacionamentos. São as associações entre entidades que

indicam como elas estão interligadas. Os relacionamen-
tos são representados por losangos nos DERs, conectando
as entidades envolvidas. Por exemplo, um relacionamento
entre Cliente e Pedido pode ser chamado de “Faz”.
• Cardinalidade. A cardinalidade especifica a quantidade

de instâncias de uma entidade que pode estar associada
a outra entidade em um relacionamento específico. A car-
dinalidade pode ser expressa como “um para um” (1:1), “um
para muitos” (1:N) ou “muitos para muitos” (N:M).
21
Cap 1: Introdução
• Dependência: A participação indica se a presença de uma

entidade em um relacionamento é obrigatória ou opcional. A
participação pode ser classificada como total (obrigatória) ou
parcial (opcional).
• Generalização/Especialização: São relacionamentos de heran-

ça entre entidades, onde uma entidade é uma versão especia-
lizada ou generalizada de outra entidade. Isso permite o com-
partilhamento de atributos e relacionamentos comuns entre
entidades relacionadas.
• Entidade associativa é uma entidade intermediária que se rela-

ciona com as entidades envolvidas na relação N:M. Geralmente,
ela contém atributos que descrevem a associação entre as en-
tidades e pode incluir chaves estrangeiras que referenciam as
chaves primárias das entidades relacionadas.
Ao criar um Modelo Entidade-Relacionamento, é essencial iden-

tificar e representar corretamente todos esses elementos para
garantir que o sistema de banco de dados resultante seja eficien-
te, eficaz e fácil de entender e manter.
Veja na Figura abaixo, um exemplo de um Diagrama de Enti-
dade-Relacionamento (Modelo Conceitual), e que será utilizado
como base para atividades posteriores:
Figura 1.3 - Diagrama de Entidade-Relacionamento
Neste Diagrama pode-se observar quatro entidades: Professor,
22
Bancos de dados
Escola, Disciplina e estudante; cada entidade possui seus

respectivos atributos representados por um círculo, sendo Notas
atributo chave o círculo preenchido com a cor preta Os re-
lacionamentos são representados por losangos e ilustram a
ação que será tomada pela entidade. Vamos aprender na
próxima seção, como criar um diagrama de entidade rela-
cionamento como este.
1.6. Ferramentas para modelagem

Existem várias ferramentas disponíveis para criar Diagra-
mas Entidade-Relacionamento (DER). Essas ferramentas fa-
cilitam a criação, edição e visualização dos diagramas, aju-
dando no processo de projeto e implementação de bancos
de dados. Algumas das ferramentas mais populares incluem:
• Microsoft Visio: Uma ferramenta versátil de criação de dia-

gramas, que oferece suporte a uma ampla variedade de
modelos, incluindo MER. O Visio permite criar diagramas
personalizados e possui recursos avançados de edição e
colaboração.
• Lucidchart: Uma ferramenta baseada na web para criação

de diagramas que oferece suporte ao modelo Entidade-
-Relacionamento. O Lucidchart permite a colaboração em
tempo real e possui uma interface amigável e intuitiva.
• Dia: Uma ferramenta de desenho de diagramas de código

aberto que suporta o modelo Entidade-Relacionamento. O
Dia é leve, fácil de usar e pode ser personalizado com plu-
gins e extensões.
Nesta disciplina utilizaremos o brModelo que é uma ferra-
menta gratuita e de código aberto desenvolvida para facili-
tar a modelagem de bancos de dados relacionais, especial-
mente voltada para o contexto brasileiro. Ele é uma excelente
opção para quem busca uma ferramenta de modelagem de
bancos de dados voltada para o contexto brasileiro, com vá-
rios recursos e uma interface amigável. No site do desenvol-
vedor é possível realizar o download e verificar as principais
funcionalidades do programa.
23
Cap 1: Introdução
Figura 1.4 - brModelo: opções de uso. (Fonte: http://www.sis4.com/brModelo)
A modelagem conceitual é uma etapa crítica no processo de

desenvolvimento de sistemas de banco de dados porque ajuda
a garantir que todos os requisitos e objetivos do sistema sejam
compreendidos e abordados. Além disso, um modelo conceitual
bem projetado pode facilitar a comunicação entre desenvolve-
dores, analistas, partes interessadas e usuários finais, promoven-
do a colaboração e a compreensão compartilhada dos objetivos
e requisitos do sistema. Importante destacar que a Modelagem
Conceitual não envolve tecnologias, ou seja, nela não são especi-
ficados como os dados serão organizados no computador, então
não há preocupação com os tipos dos dados e onde serão ar-
mazenados.
24
Dia 2
Modelagem Lógica e
Modelagem Relacional
CÉSAR EDUARDO GUARIENTI
Cap 2: Modelagem Lógica e racional
Desafio:
Fazer a Modelagem Lógica de acordo com o que foi pedido na Atividade
1 de Algoritmos, do exemplo da escola com diretor, professores e discipli-
nas. Considere que a escola pode ter ensino fundamental, médio e superior.
Acrescente a entidade “Estudante”.
• Apresentar e discutir de modelagem de dados.
• Compreender e desenvolver modelos de banco de dados, aplicando

o conceito do Modelo Conceitual.
• Compreender e desenvolver modelos de banco de dados, aplicando

o conceito do Modelo Entidade-Relacionamento.
• Exercitar a modelagem de dados com o uso de software de auxílio à

modelagem de dados.
26
Bancos de dados
2.1 Modelo Lógico Notas
A modelagem lógica é uma etapa crucial no processo de

desenvolvimento de sistemas de bancos de dados. Ela con-
siste em representar a estrutura de um banco de dados de
maneira mais detalhada do que na modelagem conceitu-
al, traduzindo as abstrações do modelo conceitual para um
modelo lógico mais próximo da implementação.
Nesta fase, as entidades, relacionamentos e atributos iden-
tificados na modelagem conceitual são transformados em
tabelas, colunas e restrições que serão utilizadas no banco
de dados. É importante notar que a modelagem lógica ain-
da é independente de um Sistema Gerenciador de Banco de
Dados (SGBD) específico, ou seja, ela descreve a organização
dos dados sem se preocupar com as particularidades de um
SGBD específico. Durante a modelagem lógica, os seguintes
passos são realizados:
1. Transformação das entidades. As entidades identificadas

no modelo conceitual são convertidas em tabelas no mo-
delo lógico. Cada atributo de uma entidade se torna uma
coluna na tabela correspondente.
2. Transformação dos relacionamentos. Os relacionamen-

tos entre as entidades no modelo conceitual são repre-
sentados por chaves estrangeiras no modelo lógico. Essas
chaves estrangeiras estabelecem vínculos entre as tabe-
las e garantem a integridade referencial dos dados[a].
3. Normalização. A normalização é um processo utilizado

para otimizar a estrutura do banco de dados, eliminando
redundâncias e inconsistências. O objetivo é criar tabelas
que possuam apenas dados relacionados entre si, mini-
mizando o armazenamento de informações duplicadas e
melhorando o desempenho das consultas.
4. Definição de restrições e índices. Na modelagem lógica,

são definidas as restrições e os índices necessários para
garantir a integridade e o desempenho do banco de da-
dos. Restrições como chaves primárias e estrangeiras, as-
sim como regras de unicidade e de verificação[b], são es-
tabelecidas nesta etapa.
27
5. Análise e refinamento. Por fim, a estrutura do banco de da-

dos é analisada e refinada, verificando se o modelo lógico está
completo e coerente. É importante revisar o modelo lógico para
garantir que ele atenda às necessidades de armazenamento e
recuperação de dados do sistema.
Após a conclusão da modelagem lógica, o projeto segue para
a etapa de modelagem física, na qual são feitas adaptações es-
pecíficas para o SGBD escolhido e os detalhes de implementação
são definidos.
A modelagem lógica é essencial para garantir que o banco de
dados seja projetado de maneira eficiente, coerente e adaptável
às necessidades do sistema. Esta etapa permite que desenvol-
vedores e analistas de sistemas criem uma representação lógica
dos dados, facilitando a compreensão e a comunicação entre as
partes envolvidas no projeto.
2.2 Modelo Relacional
O modelo relacional é uma abordagem para gerenciamento de

bancos de dados que foi proposta por Edgar F. Codd em 1970. Este
modelo é amplamente utilizado e considerado o padrão para o
projeto e desenvolvimento de sistemas de bancos de dados. Ba-
seia-se na teoria matemática dos conjuntos e na álgebra rela-
cional, tendo como estrutura fundamental do Modelo Relacional,
a tabela, também chamada de relação. Uma tabela é compos-
ta por linhas (tuplas) e colunas (atributos). Cada linha em uma
tabela representa um registro único, enquanto cada coluna re-
presenta um atributo desse registro. Os valores nas colunas são
chamados de domínios, que são conjuntos de valores permitidos
para um determinado atributo. As principais características do
modelo relacional são:
• Tabelas. No modelo relacional, os dados são organizados em

tabelas, onde cada tabela representa uma entidade ou rela-
ção do domínio do problema. Cada tabela é composta por li-
nhas (registros) e colunas (atributos).
• Chaves primárias. Cada tabela possui uma chave primária,

que é um atributo ou conjunto de atributos que identifica de
forma única cada registro da tabela. A chave primária garante
a unicidade dos registros e facilita a busca e a recuperação de
informações.
28
Bancos de dados
• Chaves estrangeiras. As chaves estrangeiras são atribu-

tos em uma tabela que fazem referência à valores de ou- Notas
tra tabela. Elas estabelecem relacionamentos entre as ta-
belas e garantem a integridade referencial dos dados.
• Normalização. O modelo relacional utiliza o conceito de

normalização para eliminar redundâncias e inconsistên-
cias nos dados. A normalização divide as informações em
várias tabelas relacionadas, minimizando a duplicação de
dados e alterando a eficiência das consultas.
• Operações relacionais. O modelo relacional define um

conjunto de operações para manipular e consultar os da-
dos armazenados nas tabelas. Estas operações incluem
seleção, projeção, junção, divisão, união, interseção e di-
ferença, entre outras. A linguagem SQL (Structured Query
Language) é a linguagem de consulta padrão utilizada
para realizar essas operações em sistemas de bancos de
dados relacionais.
• Independência de dados. Uma das vantagens do modelo

relacional é a independência entre a estrutura lógica dos
dados e a forma como eles são armazenados e acessa-
dos. Isso permite que os desenvolvedores e administrado-
res de banco de dados possam modificar a estrutura do
banco de dados sem afetar as aplicações que o utilizam.
O modelo relacional é a base para a maioria dos Sistemas
Gerenciadores de Bancos de Dados (SGBDs) modernos, como
MySQL, PostgreSQL, Oracle e SQL Server. Esses sistemas ofere-
cem uma série de recursos e ferramentas para a criação, ge-
renciamento e manipulação de bancos de dados relacionais,
tornando o modelo relacional uma escolha popular para o
desenvolvimento de sistemas de informação. Considerando
o Diagrama Entidade Relacionamento da Figura 2.1, o modelo
lógico usando esse esquema é dado na Tabela 2.1.
Figura 2.1 – Diagrama Entidade-Relacionamento.
29
Tabela 2.1 - Modelo Lógico
TipoDeProduto (CodTipoProd, DescrTipoProd) ;

Produto (CodProd, DescrProd, PrecoProd, CodTipoProd) CodTipo-
Prod referencia TipoDeProduto;
Na abordagem relacional, com esquema diagramático temos a

seguinte notação:
• As relações são representadas por um retângulo.
• As colunas são listadas dentro do retângulo que representa a

relação.
• Notações adicionais especificam o domínio do campo (integer,

varchar, ...)
• Há a indicação das colunas que compõem a chave primária.
• Pode haver uma sigla;
• Pode estar sublinhada;
• Pode haver uma chave dourada;
• Há a indicação das colunas que compõem uma chave estran-

geira.
• Pode haver uma sigla ;
• Pode haver uma chave prateada;

Considerando o exemplo da Figura 2.1, em que temos produto e
tipo produto como entidades, o esquema lógico utilizando o mo-
delo relacional é apresentado na Figura 2.2.
Figura 2.2 – Modelo Relacional
30
Bancos de dados
A Figura 2.3 ilustra um exemplo do Modelo Lógico, em que

novas características (não presentes no modelo conceitual) Notas
são apresentadas, por exemplo, atributos e tipos de variáveis.
Figura 2.3 - Exemplo do Modelo Lógico
A Figura 2.3 é possível citar como exemplo a tabela Escola,

que possui variáveis do tipo inteiro, texto, e ainda possui cha-
ve estrangeira, dessa forma, estão presentes os elementos
que caracterizam o Modelo Lógico.
Nas próximas aulas você irá aprender os tipos de cada atri-
buto
31
Dia 3
Mapeamento do Modelo
Conceitual para o Modelo
Lógico
EDIE CORREIA SANTANA
Bancos de dados
Desafio:
Considere os conceitos e técnicas que serão estudados nesta aula para de-
finir o mapeamento do modelo entidade relacionamento (ver a Figura 3.1)
para o modelo relacional.
Figura 3.1 - Modelo Entidade-Relacionamento
• Mapear os seguintes conceitos: entidades, atributos e relacionamen-
tos;
• Transformar do Modelo Entidade Relacionamento (ER) para o Modelo

Relacional (MR).
• Aprender a trabalhar de forma colaborativa, expressando ideias e

resultados de forma clara e objetiva.
33
Cap 3: Mapeamento para os modelos
Ao abordarmos as etapas de um projeto de banco de dados,

observamos que as fases principais são: levantamento e análise
de requisitos, projeto conceitual, projeto lógico e projeto físico. (ver
figura 2).
Figura 3.2 - Fases do projeto de banco de dados. Fonte: (Elmasri e Navate (2005))
Nas aulas anteriores foi estudado como elaborar o modelo con-

ceitual a partir das necessidades do usuário ou da descrição de
uma situação do mundo real. Nessa aula vamos estudar como
fazer a transformação do modelo conceitual para o modelo lógi-
co.
Conforme mostra a figura 2, podemos estabelecer uma sequ-
ência entre as fases do projeto de um banco de dados. Por exem-
plo, para criar o modelo conceitual, é necessário compreender as
necessidades do usuário. Da mesma forma, para desenvolver o
modelo lógico, é preciso ter um modelo conceitual prévio. Para
isso, usaremos o modelo conceitual ilustrado na figura 3.
Para realizar essa transformação entre os modelos alguns pas-
sos/etapas precisam ser realizados:
1. Mapear entidades e seus respectivos atributos
34
Bancos de dados
2. Mapear relacionamentos e seus respectivos atributos

Notas
a. Mapear relacionamentos 1:1 (um para um)
b. Mapear relacionamentos 1:n (um para n)
c. Mapear relacionamentos n:n (muitos para muitos)
3. Mapear Generalização/Especialização.
Figura 3.3 - Modelo Conceitual. Fonte: Autoria própria.
3.1 Mapear entidades e seus atributos
Na etapa inicial, é importante mapear do modelo conceitual

para o modelo lógico todas as entidades que serão transfor-
madas em tabelas. Por exemplo, a entidade Escola (ver figura
3.4) com seus atributos idEscola, Nome e Cidade é transfor-
mada na tabela denominada Escola com colunas denomi-
nadas idEscola, Nome e Cidade. Como o atributo idEscola é
o identificador da entidade, a coluna correspondente a este
atributo é a chave primária da tabela que fica sublinhada na
representação textual do modelo lógico.
35
Figura 3.4 - Entidade Escola.
Modelo Lógico correspondente:

Escola(idEscola, Nome, Cidade)
Utilizando a ferramenta BrModelo podemos obter uma repre-

sentação visual da tabela Escola e seus atributos, como mostra a
figura 3.5.
Figura 3.5: Tabela Escola. Fonte: Autoria própria.
3.2 Mapear relacionamento relacionamen-

tos e seus atributos
3.2.1 - Relacionamento 1:1 (um para um)

Depois de mapear as entidades e os atributos do modelo con-
36
Bancos de dados
ceitual, vamos mapear os relacionamentos do tipo 1:1. A Figura

3.6 demonstra um exemplo de relacionamento um-para-um Notas
do modelo conceitual que estamos usando como exemplo.
Figura 3.6: Exemplo relacionamento 1:1. Fonte: Autoria própria.
Para mapear este relacionamento para o Modelo Lógico,

temos duas opções: (1) fazer a fusão das tabelas e (2) adi-
cionar a chave primária de uma tabela na outra como cha-
ve estrangeira. Na segunda opção, a escolha da tabela que
recebe a chave pode ser direcionada pela cardinalidade, ou
seja, a entidade/tabela que tiver menos instâncias (regis-
tros) é a que recebe a chave da outra. No nosso exemplo, a
entidade Escola provavelmente terá menos registros que a
entidade Professor, por isso, no mapeamento a tabela Escola
recebe como chave estrangeira a chave primária da tabela
Professor que vamos chamar de idDiretor.

Escola(idEscola, Nome, Cidade, idDiretor)
idDiretor referencia Professor
Professor(matricula, AreaFormacao, Especialidade,
Nome)
3.2.2 - Mapear relacionamentos 1:n (um para n)
Agora, é o momento de mapear os relacionamentos 1:n.

Nesse tipo de relação, a estratégia é adicionar na tabela re-
sultante da entidade com cardinalidade máxima igual a n,
a chave primária da entidade com cardinalidade máxima
igual a 1 como chave estrangeira. Em outras palavras, a cha-
37
ve do lado 1 vai para o lado n.

Vejamos o exemplo da figura 3.7.
Figura 3.7 - Exemplo relacionamento 1:N. Fonte: Autoria própria.

Escola(idEscola, Nome, Cidade, idDiretor)
Estudante(rga, Endereco, idEscola)
idEscola referencia Escola
Representação visual obtida na ferramenta brModelo (ver figura

3.8).
Figura 3.8 - Exemplo relacionamento 1:1. Fonte: Autoria própria.
3.2.3 Mapear relacionamentos n:n (muitos

para muitos)
38
Bancos de dados
Nesta etapa do mapeamento você deve primeiro lem-

brar que o relacionamento n:n (muitos para muitos) é usado Notas
quando várias entidades A se relacionam com várias enti-
dades B. Na figura 3.9, temos o relacionamento muitos para
muitos entre Professor e Disciplina. Nela, a entidade Professor
tem várias (N) Disciplinas atribuídas para ele. Por outro lado,
cada Disciplina pode ser atribuída para vários (N) Professo-
res. Veja que existe nesse exemplo o atributo Ano no relacio-
namento e que também deve ser mapeado.
Figura 3.9 - Exemplo relacionamento 1:1. Fonte: Autoria própria.
Para definir esse mapeamento é criada uma terceira tabe-

la que corresponde ao relacionamento entre as entidades.
Portanto, a entidade Professor e seus atributos será mapea-
da para a tabela Professor e seus atributos, a entidade Disci-
plina será mapeada para a tabela Professor e seus atributos
e o relacionamento “atribuida” e seu atributo será mapea-
do para uma tabela Professor_atribuida_Disciplina e tendo
uma chave primária composta pelas chaves primárias das
entidades relacionadas e chaves estrangeiras as chaves pri-
márias das tabelas Professor e Disciplina.

Professor(matricula, areaFormacao, Especialidade,
nome)
Disciplina(codigo, nome, cargaHoraria, area)
Professor_atribuida_Disciplina(matricula, codigo,
ano)
matricula referencia Professor
codigo referencia Disciplina
39
Representação visual obtida na ferramenta brModelo (ver figura

3.10):
3.3 Mapear Generalização/Especialização
Para a implementação de hierarquias de generalização/espe-

cialização na abordagem relacional, há 4 alternativas:
1. Tabela única - uma única tabela para toda hierarquia com
um atributo “tipo”;
2. Tabela única - uma única tabela para toda hierarquia com
múltiplos atributos booleanos “tipo”, indicando a especialização,
mais todos os campos que existem nas especializações;
3. Múltiplas tabelas - uma tabela para cada entidade - gene-
ralização e especializações.
4. Múltiplas tabelas - apenas as especializações, mais todos
os campos que existem na generalização.
Vejamos o nosso exemplo (ver figura 3.11):
40
Bancos de dados
Notas
Figura 3.11: Exemplo relacionamento 1:1.

Escola(idEscola, nome, cidade, Escola_tipo)
Representação visual correspondente (ver figura 3.12).
Figura 3.12: Exemplo relacionamento 1:1. Fonte: Autoria própria

.
3.4. Conclusão
Ao concluir a execução das etapas para todas as entida-

des, atributos e relacionamentos, espera-se obter um mode-
lo lógico semelhante ao apresentado em formato textual a
seguir e representado na figura 3.13.
41
Escola(idEscola, nome, cidade, idDiretor, tipoEscola)

Professor(matricula, areaFormacao, especialidade, nome)
Professor_trabalha_Escola(matricula, idEscola)
Disciplina(codigo, idEscola, area, cargaHoraria, nome)

Disciplina_atribuida_Professor(matricula, codigo, ano)

Estudante(matricula, nome, endereco, idEscola)

Estudante_faz_Disciplina(matricula, codigo, nota, período, fal-

ta)
rga referencia Estudante
42
Dia 4
Linguagem SQL, definição

de dados (DDL)
EDIE CORREIA SANTANA
Cap 4: Linguagem SQL
Desafio:
Uma empresa contratou uma outra empresa para criar um banco de dados
para uma rede social, mas a empresa contratada não conseguiu concluir
o serviço de modelagem. A empresa contratante agora pediu a sua ajuda
para criar/consertar as tabelas necessárias para o banco de dados. Utilize a
descrição de Mini Mundo e o Modelo Lógico deixados pela empresa contra-
tada para criar as tabelas com as respectivas colunas e chaves primárias.
Lembre-se: a empresa não conseguiu concluir o serviço
Descrição de minimundo:
Uma rede social para compartilhamento de fotos e vídeos online. A
plataforma permite que os usuários criem perfis, publiquem fotos e ví-
deos, sigam outros usuários, comentem e curtam publicações, partici-
pem de grupos de interesse e recebam notificações sobre atividades
relevantes em suas contas. Os usuários podem interagir com a plata-
forma por meio de um aplicativo móvel ou de um site.
Modelo lógico em formato textual:

Usuario( ID, Nome, Email, Senha, DataNascimento, Sexo,
FotoPerfil )
Perfil( ID, NomePerfil, Biografia, Localizacao, Website)
Publicacao( ID, Texto, DataPublicacao, ID_Usuario )
Foto( ID, NomeArquivo, Legenda, ID_Publicacao )
Video( ID, NomeArquivo, Duracao, ID_Publicacao )
Comentario(Texto, DataComentario, ID_Publicacao, ID_Usu-
ario )
Grupo( ID, Nome, Descricao )
UsuarioGrupo( ID_Usuario, ID_Grupo )
Seguidor( ID_Usuario, ID_Usuario )
Notificacao( ID, Texto, DataNotificacao, ID_Usuario )
44
Bancos de dados
• Apresentar os conceitos fundamentais da Linguagem SQL, incluindo
a sintaxe básica de comandos DDL (CREATE, ALTER, DROP);
• Aplicar os conceitos em exemplos e cenários do mundo real em um

SGBD relacional;

45
46
Bancos de dados
Notas
4.1 Linguagem SQL

A linguagem SQL (abreviatura para Structured Query Lan-
guage, traduzido para o português como Linguagem Estrutu-
rada de Consulta), é uma linguagem de consulta e manipu-
lação de dados em bancos de dados relacionais.
Podemos identificar quatro categorias de comandos na
Linguagem SQL, cada uma com um propósito bem definido
na construção do modelo de dados físico do banco de dados:
• Linguagem de Definição de Dados (DDL – Data Definition

Language): comandos para a criação do banco de dados
e dos objetos no banco de dados, como tabelas, índices,
constraints etc., e para alteração e exclusão de objetos.
• Linguagem de Manipulação de Dados (DML – Data Mani-

pulation Language): comandos para inserir, atualizar, dele-
tar e consultar dados.
• Linguagem de Controle de Dados (DCL – Data Control Lan-

guage): comandos para gerenciar permissões de acesso
para usuários e objetos, ou seja, permissões para executar
comandos DDL, DML, DCL e TCL.
• Linguagem de Controle de Transação (TCL – Transaction

Control Language): comandos para realizar controle das
transações de dados no banco de dados.
47
Nos próximos tópicos estudaremos sobre a Linguagem de Defi-

nição de Dados (DDL) e a Linguagem de Controle de Dados (DCL).
4.2 Linguagem de Definição de Dados (DDL)
A DDL é uma categoria da Linguagem SQL que contém um con-

junto de comandos para criar, alterar e excluir objetos no banco
de dados.
Na etapa de criação do modelo físico do banco de dados em
um projeto de Banco de Dados, esses comandos são utilizados
principalmente. Os comandos são:
• CREATE: criar estrutura (banco de dados ou tabelas)
• ALTER: alterar estrutura (banco de dados ou tabelas)
• DROP: remover estrutura (banco de dados ou tabelas)

O comando CREATE é utilizado para criar estruturas no banco de
dados. Com esse comando podemos criar o banco de dados, as
tabelas, as colunas, as chaves, entre outros;
Para criar um banco de dados, a sintaxe do comando SQL é:
CREATE DATABASE <Nome_do_Banco_de_Dados>;

Ao executar este comando SQL sem passar parâmetros adicio-
nais, como tamanho, conjunto de caracteres de idioma, entre ou-
tros, o banco de dados será criado com as opções padrões da
instância instalada.
Para exemplificar, se desejamos criar o banco de dados de
nome BDTESTE, devemos executar:
CREATE DATABASE BDTESTE;

Para criar as tabelas, que são as estruturas onde os dados são
inseridos, consultados e manipulados, é utilizado o comando CRE-
ATE TABLE. Sua sintaxe básica é a seguinte:
CREATE TABLE <nome_da_tabela> (
<coluna1> <tipo de dados(tamanho)> <restrições

da coluna1>,
48
Bancos de dados
<coluna2> <tipo de dados(tamanho)> <res-

Notas
trições da coluna2>,
<coluna3> <tipo de dados(tamanho)> <res-

trições da coluna3>,
<restrições da tabela>
);
Ao criar uma tabela é necessário definir para cada atributo

seu tipo, tamanho (se houver) e suas restrições. Segue exem-
plo de criação de uma tabela:
CREATE TABLE Professor (
matricula INT NOT NULL PRIMARY KEY,
areaFormacao INT,
especialidade INT,
nome INT
);
Alteração de Estruturas
O comando SQL ALTER é utilizado para alterar estruturas
do banco de dados. Com esse comando podemos alterar o
banco de dados e as tabelas. Por exemplo, para alterar um
banco de dados, a sintaxe do comando SQL é:
ALTER DATABASE <Nome_do_Banco_de_Dados> <Parâme-

tros a serem alterados>;
49
Para exemplificar, para alterarmos o nome de um banco de dados, deve-

mos executar:
ALTER DATABASE <nome do banco> RENAME TO <novo nome do ban-

co>;
Para alterar a estrutura de uma tabela a sintaxe básica é ALTER TABLE

Alteração Sintaxe
ALTER TABLE <nome da tabela> ADD <nome da

Adicionar Colunas coluna> <tipo de dado e tamanho> <restrições
da coluna>;
ALTER TABLE <nome da tabela>

Remover Colunas
DROP <nome da coluna>;

Adicionar restrições
ADD <restrição>

Remover restrições
DROP CONSTRAINT <restrição>;
Mudar valores padrões ALTER TABLE <nome da tabela> ALTER COLUMN

<nome da coluna> SET DEFAULT <novo valor>;

Mudar tipo de dado de
coluna ALTER COLUMN <nome da coluna> TYPE <novo
tipo>;
ALTER TABLE <nome da tabela> RENAME CO-

Renomear coluna LUMN <nome da coluna> TO <novo nome da
coluna>;
50
ALTER TABLE <nome da tabela> RENAME TO
Renomear tabela
<novo nome da tabela>;
<nome da tabela> seguida da alteração que se pretende fa-

zer. Para adicionar uma nova coluna, por exemplo, a sintaxe
é: Notas
ALTER TABLE <nome da tabela> ADD <nome da coluna>

<tipo de dado e tamanho> <restrições da coluna>;
Por exemplo, se precisarmos adicionar uma nova coluna o
comando SQL é:
ALTER TABLE Professor ADD Email varchar(255);

Segue no quadro 1 as principais modificações que po-
dem ser realizadas em uma tabela e suas sintaxes básicas:
Quadro 1. Principais modificações em uma tabela

Remoção de Estruturas
Um comando muito útil da Linguagem SQL, pertencente
também à categoria DDL, é o DROP. Com ele, é possível remo-
ver as estruturas de dados e outros objetos de um banco de
dados. No entanto, deve ser utilizado com cautela e atenção
para evitar a remoção acidental de estruturas importantes.
Usando o DROP, pode-se remover banco de dados, tabelas,
views, funções, índices, entre outros. Para remover um banco
de dados a sintaxe básica é:
DROP DATABASE <nome do banco>;

Portanto, para remover o banco de dados que criamos an-
teriormente usamos:
DROP DATABASE BDTESTE;

Para remover uma tabela a sintaxe básica é:
DROP TABLE <nome da tabela>;

Portanto, para remover a tabela que criamos anteriormen-
51
Dia 5
Data Manipulation
Language (DML)
MARCOS PAULO DE MESQUITA
Bancos de dados
Desafio:
O módulo de gestão de atribuição de aulas da plataforma tecnológica da
Secretaria de Ciência, Tecnologia e Inovação já está em fase de testes e
você precisa popular o banco de dados e gerar alguns relatórios. Você de-
verá cadastrar novas escolas, professores, disciplinas e fazer atribuições de
disciplinas a professores. Um relatório de atribuição para cada escola deve-
rá ser criado.
• Inserir registros numa tabela de um banco de dados;
• Excluir registros de uma tabela de um banco de dados;
• Atualizar registros de uma tabela de um banco de dados;
• Recuperar registros de tabelas de um banco de dados.
53
Cap 5: Data Manipulation Language
te devemos executar o comando SQL:
DROP TABLE Professor;

É importante saber que se a execução do comando DROP TABLE
acontecer com sucesso a tabela com sua estrutura e seus dados
Conectando o
serão removidos permanentemente.
assunto
Estas são as quatro opera-

ções básicas do desenvol-
vimento de uma aplicação
sendo utilizadas em bases
de dados relacionais (RDB-
MS) fornecidas aos utili-
zadores do sistema. Um
nome é dado a elas: CRUD:
Create, Read, Update and
Delete,
Outros acrônimos podem
ser usados para definir as
mesmas operações: 5.1 Data Manipulation Language (DML)
ABCD: Add, Browse, Change A manipulação dos dados em SQL é feita pelos comandos da
and Delete
linguagem DML. Três comandos podem ser usados para modificar
BREAD:Browse, Read, Edit,
Add and Delete as tuplas de um banco de dados: INSERT, DELETE e UPDATE. O co-
VADE(R): View, Add, Delete, mando SELECT recupera tuplas.
Edit (e Restore, para siste-
mas com processos tran- Uma tupla é uma linha na tabela, um registro no banco de da-
sacionais)
VEIA: Visualizar, Excluir, Inse-
dos.
rir, Alterar
Em banco de dados o termo Recuperar está relacionado com
a consulta, com a geração relatórios ou com a busca de dados
específicos. Por isso dizemos que o SELECT recupera registros. Este
termo não tem nenhuma relação com restauração ou correção
de dados no banco de dados.
5.2 INSERT
O INSERT é usado para incluir novas tuplas em uma tabela. Na

sua sintaxe devem ser descritos a tabela na qual se deseja realizar
a inserção e a lista de valores para tupla. Os valores devem vir na
mesma ordem dos atributos que foram especificados na criação
da tabela. Você também poderá explicitar uma ordem diferente
ou omitir algum atributo caso seja necessário.
C0: Inserir uma nova escola com os seguintes dados: Nome: Es-
cola Alan Turing. Id_Escola: 879100, Cidade: Cuiabá; Tipo: Ensino
Médio, Diretor: 500100
54
Bancos de dados
INSERT INTO Escola(nome, idEscola, cidade, ti-

Notas
poEscola, idDiretor) VALUES (‘Escola Alan Tu-
ring’,879100, ‘Cuiabá’,’Ensino Médio’, 500100);
A consulta C0 insere a Escola Alan Turing na tabela escola

com aqueles valores de atributos. Note que o atributo ‘diretor’
recebe o valor 500100 que é uma referência para a tabela
professor. Precisamos garantir que naquela tabela exista o
professor com este número de matrícula.
C1: Atribua a disciplina de código FIS02B para o professor de
matrícula 800744 no ano de 2023.
INSERT INTO Disciplina_atribuida_Professor VALUES

(800744, ‘FIS02B’,2023);
Note que em C1 não houve a descrição dos atributos , neste

caso considera-se a ordem em que eles foram criados com
CREATE TABLE: matricula, codigo, ano.
C2: Cadastre uma nova disciplina apenas com seu código
e nome.
INSERT INTO Disciplina (codigo, nome) VALUES

(‘BIO01A’, ‘Biologia 1’);
Embora a tabela Disciplina possua os atributos codigo,

idEscola, area, cargaHoraria e nome, somente aqueles dois
foram usados no INSERT da C2.
C3: Inserir 3 novos estudantes .
INSERT INTO Estudante VALUES

(100, ‘Alanis Java’, ‘Rua X, 15’, 80010),
(200, ‘Pytholomeu Gusmão’, ‘Avenida Y, 200A’,
80010),
55
(400, ‘Ruby da Silva’, ‘Pça WW, 45’, 90010);
A consulta C3 insere 3 novas tuplas na tabela Estudante. Cada

tupla vem entre parênteses e separadas por vírgulas.
5.3 DELETE
O DELETE é usado para excluir tuplas de uma tabela. Ele é usado

com a cláusula WHERE na qual um critério de exclusão apresenta-
do em expressão booleana é especificado. Somente as tuplas que
obedecem a este critério são removidas da tabela.
C4: Exclua do sistema da secretaria o professor Herman Holleri-

tch Cuyabano.
DELETE FROM professor WHERE nome = ‘Herman

Holleritch Cuyabano’;
A consulta C3 exclui os registros que atendem à condição de ter

o valor do atributo nome igual a Herman Holleritch Cuyabano’.
Por questão de boas práticas é recomen-

Alerta dado declarar o nome da constante em CAI-
! XA ALTA, isso pode diferenciar em algumas
linguagens.
C5: Apague as disciplinas que tenham carga horária inferior 25h
DELETE FROM disciplina WHERE cargaHoraria <

25;
Em SQL, os operadores básicos de comparação lógicos para

comparar valores de atributo entre si e com constantes literais
56
Bancos de dados
são =, <=, >, >= e <>. Estes correspondem, respectivamente,

aos operadores da linguagem de programação C/C++ =, <=, Notas
>, >= e !=. A principal diferença sintática é o operador diferen-
te.
C6: Exclua todos os registros da tabela estudante;
DELETE FROM Estudante;

5.4 UPDATE
O comando UPDATE é usado para modificar valores de atri-
buto de uma ou mais tuplas selecionadas. Assim como no
comando DELETE, uma cláusula WHERE no comando UPDATE
seleciona as tuplas a serem modificadas em uma única re-
lação. Uma cláusula SET adicional no comando UPDATE espe-
cifica os atributos a serem modificados e seus novos valores.
C7: Altere a carga horária da disciplina LP03C para 6H
UPDATE Disciplina SET cargaHoraria = 6

WHERE codigo = ‘LP03C’;
Em C7 a clausula WHERE seleciona a disciplina de código

‘LP03C’ então atribui o valor 6 para o seu atributo carga ho-
rária.
C8: Altere o ano de atribuição para 2023 em todos os regis-
tros do banco de dados
UPDATE Disciplina_atribuida_Professor SET

ano = 2023;
Aqui, semelhante à C5, a cláusula WHERE foi omitida de

modo que nenhum registro específico seja selecionado. Nes-
te caso a operação afeta todas as tuplas da tabela.
C9: Altere o nome do professor Neumann János Lajos para
Jonh von Neumann.
UPDATE professor SET nome=‘Jonh von Neumann’ WHE-

RE matricula_pro=800700;
57
Em C9 partimos da informação que a matricula do professor

Neumann seja 800700, então atualizamos seu nome. Atualiza-
ções utilizando na cláusula WHERE uma chave vai nos garantir que
apenas uma única tupla seja atualizada. De qualquer modo, esta
consulta poderia ser feita como segue.
UPDATE professor SET nome=‘Jonh von Neumann’ WHERE

nome= ‘Neumann János Lajos’ ;
5.5 SELECT
O SELECT é o comando básico da SQL para recuperar informa-

ções de um banco de dados. A forma básica do comando SELECT,
às vezes chamada de mapeamento ou bloco select-from-where,
é composta pelas três cláusulas SELECT, FROM e WHERE, e tem a
seguinte forma:
SELECT <lista de atributos>
FROM <lista de tabelas>
WHERE <condição>;
Onde:
• <lista de atributos> é uma lista de nomes de atributo cujos va-

lores devem ser recuperados pela consulta.
• <lista de tabelas> é uma lista dos nomes de relação exigidos

para processar a consulta.
• <condição> é uma expressão condicional (booleana) que iden-

tifica as tuplas a serem recuperadas pela consulta.
• A lista de atributos pode ser substituída pelo operador * caso

estejamos interessados em todos os atributos da tabela.
C10: Recuperar o nome e área de formação de todos os profes-

sores.
SELECT nome, areaFormacao
FROM professor;
58
Bancos de dados
Esta consulta envolve apenas a relação PROFESSOR listada

na cláusula FROM. Como nenhuma condição foi imposta na Notas
consulta, não será feito o uso da cláusula WHERE e uma lista
com o nome e área de todos os professores é retornada.
C11: Recuperar o nome e área de formação de todos os pro-
fessores da escola ‘Frei Galvão’.
Esta consulta é um caso particular da consulta C10 uma vez
que agora temos uma condição. Neste caso adicionamos à
cláusula WHERE a expressão para filtrar os professores da es-
cola Alan Turing.
SELECT professor.nome,professor.areaFormacao
FROM professor, escola
WHERE professor.idEscola = escola.idEscola AND escola.
nome = ‘Frei Galvão’;
Note como uma simples mudança no enunciado da con-
sulta nos leva a uma consulta diferente. Como na tabela de
professor não temos o nome da escola, precisamos fazer uma
junção entre as tabelas professor e escola, respectivamen-
te pelas chaves estrangeira e primária e então assim filtrar
os professores da escola desejada. Neste caso, a expressão
professor.idEscola = escola.idEscola é condição de junção.
Uma prática muito comum no select é usar um alias para
nome de tabelas e atributos. C11 poderia ser escrita na forma:
SELECT p.nome,p.areaFormacao
FROM professor AS p, escola AS e
WHERE p.idEscola = e.idEscola AND e.nome = ‘Alan Turing’;
O SELECT possui a cláusula ORDER BY que é usada para es-
pecificar uma ordem na qual os atributos serão retornados. A
Estrutura é como segue:
C12: Liste o nome e a área dos professores ordenados em
ordem alfabética
SELECT nome,areaFormacao
FROM professor
ORDER BY nome;
Por padrão os atributos são classificados em ordem ascen-
dente. Você poderá alterar para a ordem descendente utili-
59
zando a comando DESC.

C13: Recuperar o nome das 5 disciplinas que possuem as maio-
res cargas horárias.
SELECT nome, cargaHoraria
FROM Disciplina
ORDER BY cargaHoraria DESC
LIMIT 5;
A cláusula LIMIT limita a quantidade de tuplas no resultado da
consulta. Neste caso estávamos interessados nas 5 maiores car-
gas horárias. Utilizamos a ordenação descendente.
C14: Obter as escolas localizadas na cidade Cuiabá
SELECT * FROM escola WHERE cidade = ‘Cuiabá’;
O uso do operador * em C14 indica que todos os atributos da
tabela escola serão recuperados.
C15: Obter um relatório de disciplinas cujas cargas horárias es-
tejam entre 10 e 30 horas.
SELECT * FROM Disciplina
WHERE (cargaHoraria >=10 AND cargaHoraia <=30);
Em C15 combinamos os operadores de comparação com o
operador lógico AND para definir um intervalo de valores que es-
tamos interessados. Neste caso somente as disciplinas de cargas
horárias maiores ou iguais a 10 e menores ou iguais a 30 serão re-
tornadas. O operador BETWEEN também poderia ser usado nesta
consulta:
WHERE (cargaHoraria BETWEEN 10 AND 30);
C16: Gerar um relatório de todas as disciplinas de nome Física.
WHERE nome LIKE ‘Física%’;
Note que não estamos utilizando em C16 o operador = e sim o
operador LIKE. Este operador busca um padrão de string em cam-
pos textuais. Neste caso qualquer nome que comece com a pala-
vra Física será retomado. O caracter % usado indica que o nome
deve começar com Física e depois qualquer outra sequência de
60
Dia 6
O Comando SELECT:
Junções
ELMO BATISTA DE FARIA
Cap 6: O Comundo SELECT
Desafio:
Considerando o banco de dados da Escola, foram solicitadas pelos diretores
algumas informações sobre os alunos e os professores.
Qual a carga horaria das disciplinas e os professores que ministram estas
disciplinas.
Também foi detectada um problema nas informações disponíveis a Escola,
não foram identificados os cursos que a escola oferece. Sendo assim insira a
tabela curso e faça as devidas ligações com as demais tabelas.
Após a inserção da tabela curso, liste os cursos, seus professores e os alunos
matriculados em cada disciplina, destes cursos.
• Compreender o conceito de junção e desenvolver consultas com
objetivo de melhorar a gestão das escolas.
• Aprender a descrever entidades e busca de objetos ou problemas do

mundo real.

62
Bancos de dados
string poderia ocorrer como Física 1, Física 3, Física Quântica...

(Obs: um padrão ‘%Física’ poderia retornar Educação Física, Notas
por exemplo.)
6.1 Junções
Esta operação conecta as colunas entre tabelas linha a li-
nha selecionando as linhas onde a condição de junção for
verdadeira. Pode envolver poucas tabelas em consultas co-
muns ou várias tabelas como em relatórios.
Operação de junção entre as tabelas Escola e Professor:
SELECT e.nome, p.nome
FROM “ESCOLA” e
INNER JOIN “PROFESSOR” p
ON p.matricula = e.fk_professor_matricula
ORDER BY p.nome;
“nome” “nome”
“Escola central” “Josá carlos”
63
“Escola São José” “Manoel de barros”
A operação de junção passa pelo processo de produto carte-

siano entre as tabelas com uso do comando CROSS JOIN, exemplo
Tabela_1 e Tabela_2. Cada tabela tem uma coluna simples e três
linhas com letras do alfabeto, como:
Tabela_1 Tabela_2
SELECT *
FROM tabela_1
CROSS JOIN tabela_2;
COL_1 COL_1
-------- ---------
a a
b a
c a
a b
b b
64
Bancos de dados
c b
Notas
a c
b c
c c
Outros tipos de Junção (JOIN) são:
• Interna (INNER): serão incluídas somente as linhas que sa-

tisfazem a condição de junção. Também pode ser Cruzada
(CROSS) ou Natural (NATURAL, onde o servidor determina a
junção).
• Externa (OUTER): serão incluídas linhas que satisfaçam a

condição de junção e as linhas restantes de uma das ta-
belas da junção. Pode ser RIGHT, LEFT ou FULL.
6.2 Junção Interna
A Junção Interna (INNER JOIN) é utilizada para especificar

a forma de junção com uso de chave estrangeira e da sub-
cláusula ON. Se não há dado de relação, então a tupla não
aparece no resultado (se necessário mostrar, usar junção ex-
terna).
A sintaxe do SELECT com esse tipo de junção é a seguinte:
SELECT <listaCampos>
FROM <Tabela1>
INNER JOIN <Tabela2> ON t1.<pk> = t2.<fk>
[INNER JOIN <Tabela3> ON t3.<pk> =

<t2.fk> ...];
65
6.3 Junção Interna – USING e INNER
Se os nomes dos campos forem iguais nas tabelas, pode-se

usar a subcláusula USING, conforme o seguinte exemplo:
SELECT c.descrCat, p.descrProd
FROM categoria c
INNER JOIN produto p USING (codCat);
Outro ponto a ser lembrado é que a junção interna será sempre

feita por padrão, sendo, portanto, opcional utilizar INNER no co-
mando.
SELECT c.descrCat, p.descrProd
FROM categoria c
[INNER] JOIN produto p USING (codCat);
Regras para Junção
• A consulta com junção sempre inicia com a cláusula SELECT.
• A lista das colunas que devem ser mostradas das tabelas en-
volvidas é definidas após o comando SELECT.
• A operação de junção também suporta a especificação de to-

das as colunas, com o uso de um simples asterístico (*) em
uma cláusula SELECT.
• Quando o asterístico (*) for usado, a ordem de colunas mostra-

das obedece a posição das tabelas na cláusula FROM.
• Qualquer SELECT que possui duas ou mais tabelas listadas na

cláusula FROM é uma operação de Junção.
• A ordem das tabelas listadas na cláusula FROM são irrelevantes
66
Bancos de dados
a menos que na cláusula SELECT apareça o asterístico (*),

assim a lista de campos obedecerá a ordem das tabelas Notas
listadas em FROM.
• A condição de junção fica definida na cláusula FROM
• Os nomes das colunas são qualificados utilizando a com-

posição do nome da tabela com a sua respectiva coluna
separado por um ponto (.).
• O uso de alias pode ser adotado na qualificação de nomes

das colunas.
Exemplo:
SELECT e.nome, p.nome as diretor
FROM “ESCOLA” e
ORDER BY p.nome;
“nome” “diretor”
6.4 Junção utilizando operadores (<, >)
Pode-se utilizar um operador relacional na condição de
67
junção exemplo (>).
FROM “ESCOLA” e
WHERE p.nome> e.nome

Junção com mais de duas Tabelas, o exemplo mostra a junção
entre Escola, trabalha e professor.
O SELECT será definido por :
FROM “ESCOLA” e
JOIN “TRABALHA” t ON t.fk_escola_idescola = e.ides-

cola
JOIN “PROFESSOR” P ON p.matricula = t.fk_professor_

matricula
68
Bancos de dados
“Escola São José” “Josá carlos”

Notas
“Escola central” “Manoel de barros”
6.5 Junção externa
Uma junção externa (OUTER JOIN) é utilizada sempre que

se deseja ver quais linhas de uma tabela estão relacionadas
a outra tabela e quais linhas não estão. Por exemplo: numa
situação em que temos ESCOLA e seus ESTUDANTES armaze-
nados em um BD, pode ser necessário descobrir quais ESTU-
DANTES têm ESCOLA e quais não têm ESCOLA algum. A junção
externa pode também ser útil quando se deseja verificar se
existem membros órfãos em um SGBD, ou seja, tabelas cujas
PK e FK estejam sem sincronia (lembrando que SGBDs mais
modernos não permitem que isso venha a acontecer). Um
OUTER JOIN só pode ser realizado entre duas tabelas, mas
admite algumas variações, conforme veremos a seguir.
Tipos de junção externa:
• LEFT - a palavra-chave LEFT especifica que a tabela do

lado esquerdo é responsável por determinar o número de
linhas do conjunto-resultado.
• RIGHT - a palavra-chave RIGHT especifica que a tabela

do lado direito é usada para fornecer valores de consulta
sempre que uma correspondência é encontrada.
• FULL - nas pesquisas com FULL OUTER JOIN, o resultado tra-

rá todos os registros, ao menos uma vez, que estejam nas
duas tabelas, tanto a da esquerda do JOIN quanto a da
direita do JOIN.
SELECT e.nome escola, s.nome as aluno
FROM “ESCOLA” e
RIGHT OUTER JOIN “ESTUDANTE” s
69
ON s.fk_escola_idescola = e.idescola
“escola” ”aluno”
“Escola central” “Carlos”
“Escola São José” “Manoela”
“Escola central” “Maria”
“Escola São José” “Kathy”
“Escola central” “joão”
[null] “marcos”
OUTER JOINS e valores NULL
• A consulta para listar Os estudantes que não estão vinculados

a nenhuma escola aparece com valor NULL.
• Nesta situação a coluna nome da escola, pode ter valores nu-

los para estudantes basta simplesmente adicionar a cláusula
WHERE nome is NULL ou not NULL.
SELECT e.nome Escola, s.nome as Aluno
FROM “ESCOLA” e
RIGHT OUTER JOIN “ESTUDANTE” s
WHERE e.nome IS NULL
“aluno”
70
Bancos de dados
“marcos”
Notas
Operações LEFT e RIGHT OUTER JOIN
• Se a tabela de ESCOLA for relacionada através de um co-

mando de OUTER JOIN com a tabela de ESTUDANTE e os
campos de interesse forem os campo específicos da ta-
bela de ESTUDANTE a operação de junção é definida por
RIGTH OUTER JOIN.
• O caso contrário a operação será de LEFT OUTER JOIN.
LEFT OUT JOIN
SELECT e.nome Escola,s.nome as Aluno
FROM “ESCOLA” e
LEFT OUTER JOIN “ESTUDANTE” s
“escola” “aluno”
“Escola central” “Carlos”
“Escola São José” “Manoela”
“Escola central” “Maria”
“Escola São José” “Kathy”
“Escola central” “joão”
71
Operação de SELF-JOIN
• Uma operação de SELF JOIN é usada para produzir uma tabe-

la resultante com linhas que envolvam campos de junção de
uma mesma tabela.
Operação de SELF-JOIN
SELECT A1.nome, A2.nome
FROM “ESTUDANTE” A1
INNER JOIN “ESTUDANTE” A2ON (A1.rga <> A2.rga)
ORDER BY A1.nome
“Carlos” “Manoela”
“Carlos” “Maria”
“Carlos” “Kathy”
“Carlos” “joão”
“Carlos” “marcos”
“joão” “marcos”
“joão” “Kathy”
72
Bancos de dados
“joão” “Maria”
Notas
“joão” “Manoela”
“joão” “Carlos”
“Kathy” “Carlos”
“Kathy” “Manoela”
“Kathy” “Maria”
“Kathy” “joão”
“Kathy” “marcos”
“Manoela” “Carlos”
“Manoela” “marcos”
“Manoela” “joão”
“Manoela” “Kathy”
“Manoela” “Maria”
“marcos” “Carlos”
“marcos” “Manoela”
“marcos” “Maria”
“marcos” “Kathy”
“marcos” “joão”
“Maria” “marcos”
“Maria” “Manoela”
“Maria” “Kathy”
73
INNER JOIN “ESTUDANTE” A2ON (A1.rga <> A2.rga)
ORDER BY A1.nome
“Carlos” “Manoela”
“Carlos” “Kathy”
“Carlos” “joão”
“Carlos” “marcos”
“joão” “marcos”
“joão” “Kathy”
“joão” “Maria”
“joão” “Manoela”
“joão” “Carlos”
“Kathy” “Carlos”
“Kathy” “Manoela”
“Kathy” “Maria”
“Kathy” “joão”
“Kathy” “marcos”
“Manoela” “Carlos”
“Manoela” “marcos”
74
Bancos de dados
“Manoela” “joão”
Notas
“Manoela” “Kathy”
“Manoela” “Maria”
“marcos” “Carlos”
“marcos” “Manoela”
“marcos” “Maria”
“marcos” “Kathy”
“marcos” “joão”
“Maria” “marcos”
“Maria” “Manoela”
“Maria” “Kathy”
“Maria” “joão”
“Maria” “Carlos”
Exemplo 2 :
INNER JOIN “ESTUDANTE” A2 ON (A1.rga = A2.rga)
ORDER BY A1.nome
75
Dia 7
Agregação, Visão e
Subconsulta
ELMO BATISTA DE FARIA
Bancos de dados
Desafio:
Considerando o banco de dados da Escola, foram solicitadas pelo departa-
mento das escolas algumas informações, como:
1. Selecione todos os alunos que estudam na escola que o professor

José Carlos leciona?
2. Apresente a quantidade de disciplina por Escola e suas cargas ho-

rárias?
3. Quem é o diretor da Escola que possui mais estudantes?
4. Liste os estudantes com maiores notas por disciplina?
5. Listar quantas faltas tem os estudantes da escola 200?
6. Crie uma view que mostre o professor que atuou nas disciplinas de
• Compreender o conceito de Agregação, visão e subconsulta, desen-
volver consultas com objetivo de melhorar a gestão das escolas.
• Aprender a consultar a base de dados buscando objetos e solucio-

nando problemas do mundo real.

77
Cap 7: Agregação, Visão e Subconsulta
“Maria” “joão”
“Maria” “Carlos”
Exemplo 2 :
INNER JOIN “ESTUDANTE” A2 ON (A1.rga = A2.rga)
ORDER BY A1.nome
7.1 Funções Agregadas
Funções agregadas, são funções definidas para executar ope-

rações de contagem, média e soma, como:
• Mostrar a média dos salários dos funcionários da empresa?
• Qual o total de salários de todo ano?
• Quais os salários máximos e mínimos do departamento de In-

formática?
Aplicação das Funções Agregadas
Duas regras são importantes para entender as funções agrega-

das:
• As funções agregadas podem ser usadas em ambas cláusulas

SELECT e HAVING.
78
Bancos de dados
• As funções agregadas não podem ser usadas em uma

cláusula WHERE. Notas
A seguinte consulta produz um erro da classe
SELECT *
FROM “DISCIPLINA” d
WHERE AVG(d.cargahoraria) > 40000;
ERROR: aggregate functions are not allowed in

WHERE LINE 3: WHERE AVG(d.cargahoraria) > 40000;
^ SQL state: 42803 Character: 37
Para saber a contagem total de estudantes, pode-se usar

COUNT(*). A função COUNT(*) mostra todas as linhas de uma
tabela. O asterisco (*) pode ser usada como parâmetro em
uma consulta e o resultado é um único valor escalar.
Exemplo:
SELECT COUNT(*)
FROM “ESTUDANTE”;
“count”
7.1.1 Função Contador (COUNT)
79
Renomeando coluna com funções agregadas.
SELECT COUNT(*) as “Número de Estudantes”
FROM “ESTUDANTE”;
“Número de Estudantes”
Regras para Count():
• COUNT(*) seleciona todas as linhas de uma tabela.
• COUNT(nome coluna) especifica uma coluna para contagem.
• Quando colunas são especificadas , as linhas contendo valores

NULL são omitidas.
• Valores branco ou zero são considerados na contagem.
7.1.2 Função Média (AVG)
A função AVG é usada para calcular a média dos valores de

uma coluna de uma tabela.
Exemplo: Retornar a média da carga horária das cdiciplinas.
SELECT AVG(d.cargahoraria) as “Media Carga Horária”
80
Bancos de dados
Notas
“Media Carga Horária”
73.333333333333333
Algumas consultas usando funções agregadas podem ser

completas com o uso de valores sem repetição, desta forma
pode-se usar o comando Distinct.
Exemplo: Calcular a média dos salários distintos pagos pela

companhia?
SELECT AVG(distinct d.cargahoraria) as “Media

Carga Horária”
“Media Carga Horária”
73.333333333333333
7.1.3 Função Soma (SUM)
Calcula o total da soma dos valores de uma coluna.

Exemplo: retornar o total de salários pagos pela empresa.
81
SELECT sum(d.cargahoraria) as “Soma Carga Horária”
“Soma Carga Horária”
220
Exemplos:
Um gestor quer a soma de todas as notas do estudante 123123.
SELECT sum(ed.notas) as “Notas”
FROM “Estudante_Disciplina” ed
where ed.fk_estudante_rga = 123123;
“Notas”
120
7.1.4 Funções de Mínimo e Máximo (MIN e MAX )
A função de mínimo retorna o menor valor de uma coluna. E o

Max retorna o maior valor. Assim como SUM e AVG, as funções de
82
Bancos de dados
MIN e MAX trabalham com valores numéricos e caracteres

das colunas. Notas
Exemplo:
A função MIN retorna o menor valor dos nomes de estudan-
tes considerando a ordem alfabética dos dados. A função
MAX() retorna os funcionários que possui os maiores valores
em ordem alfabética.
SELECT Min(e.nome) , Max(e.nome)
FROM “ESTUDANTE” e
“min” “max”
7.2 Usando GROUP BY na cláusula

WHERE
A cláusula where trabalha eliminando as linhas da tabela

antes que qualquer agrupamento seja feito. A consulta abai-
xo mostra a quantidade de alunos para a disciplina maior
que 1.
SELECT ed.fk_disciplina_codigo as Disciplina,
COUNT(*) “numero de estudantes”
WHERE ed.fk_disciplina_codigo > 1
GROUP BY ed.fk_disciplina_codigo;
“disciplina” “numero de estudantes”
83
3 2
2 1
7.2.1 GROUP BY com HAVING

Cláusula HAVING
• A cláusula HAVING é usada para funções agregadas assim

como a cláusula Where é usada para selecionar colunas de
um Select.
• Ou seja, filtra linhas baseadas em uma condição de grupo.
• A cláusula WHERE é usada para filtrar linhas antes de uma fun-

ção de grupo.
• Uma cláusula HAVING seleciona linhas após uma função de

grupo.
Exemplo: Selecionar as disciplinas que possuem mais de 1 estu-

dante
SELECT ed.fk_disciplina_codigo as Disciplina,
COUNT(*) “numero de estudantes”
GROUP BY ed.fk_disciplina_codigo
HAVING COUNT(*) >1
“disciplina” “numero de estudantes”
84
Bancos de dados
3 2
Notas
7.2.2 Usando GROUP BY no padrão SQL
Regras do padrão SQL 99
• As colunas listadas em um select podem também ser uti-

lizadas na cláusula GROUP BY ou uma expressão envolven-
do funções agregadas.
• Uma expressão GROUP BY deve conter apenas colunas lis-

tadas em um select.
• As colunas em um HAVING devem conter:
• Valores simples de uma função agregada para a instân-

cia, ou
• As colunas listadas em um select ou na cláusula GROUP

BY .
7.3 Subconsultas
Uma subconsulta envolve uma consulta dentro de outra

consulta.
Exemplo:
SELECT ed.fk_disciplina_codigo as Disciplina
WHERE ed.fk_estudante_rga = (SELECT RGA
From “ESTUDANTE”
WHERE rga = 123123)
85
“disciplina”
7.3.1 Tipos de Subconsultas

Elas são basicamente constituídas de operadores como:
1. Operador IN com seus modificadores ANY ou ALL . Esta sub-
consulta pode retornar um grupo de valores, mas estes de-
vem ser baseados em uma coluna simples, ou seja, o coman-
do SELECT deve conter apenas uma expressão ou coluna.
2. Subconsultas que usam um modificador de comparação (=,
<, >, <>) estas consultas podem retornar apenas um simples
valor escalar.
3. Subconsultas que utilizem o comando EXISTS para testar a
existência de linhas de dados que satisfaz um critério espe-
cífico.
7.3.1 Subconsulta – Regra Geral
Uma subconsulta obedece a sintaxe definido por:
comparação [ANY | ALL] (instruçãosql)

expressão [NOT] IN (instruçãosql)
[NOT] EXISTS (instruçãosql)
A cláusula SELECT de uma subconsulta pode conter apenas

uma expressão, uma função agregada ou uma coluna.
7.3.3 Subconsulta – Regras
86
Bancos de dados
O domínio dos valores retornados de uma subconsulta de-

vem ser join-compatíveis. Dados Join-compatíveis no Pos- Notas
tgreSQL indica que algumas conversões podem ser feitas
para que os valores sejam do mesmo tipo de dados. O banco
converte automaticamente qualquer tipo numérico quando
faz comparações entre valores agrupados como:
• int (integer)
• smallint (small integer)
• decimal
• float
Colunas de duas tabelas que são inicialmente compara-

das podem ter nomes diferentes mas que possuam o mes-
mo domínio, tipos de dados ou tipo de dados conversíveis.
Algumas restrições para subconsultas:
Subconsultas não podem manipular seus resultados in-
ternamente. Ou seja, uma subconsulta não pode incluir uma
cláusula ORDER BY ou INTO.
7.3.4 Subconsultas e o Operador IN
Subconsultas que utilizem a palavra IN possui a seguinte

forma geral:
WHERE expression [NOT] IN (subquery)
A única diferença desta consulta no uso de IN é que ao in-

vés de valores de uma lista, a lista é montada por uma sub-
consulta.
87
WHERE ed.fk_estudante_rga IN (SELECT RGA
From “ESTUDANTE” e
“disciplina”
3
7.3.5 Subconsultas e o Operador NOT IN
Como no operador IN, o NOT IN pode obter resultados de uma

subconsulta, baseado em uma lista de objetos fora da lista. Exem-
plo:
WHERE ed.fk_estudante_rga not IN (SELECT RGA
WHERE rga = 123123
“disciplina”
7.3.6 Múltiplos Níveis de Alinhamento
88
Bancos de dados
Notas
Uma Subconsulta pode conter outras subconsultas. Quan-
do a cláusula WHERE de uma subconsulta possui seus objetos
ligados a uma outra subconsulta diz consultas aninhadas.
WHERE ed.fk_estudante_rga not IN (SELECT

RGA
WHERE fk_escola_idescola =
(Select es.idEscola
FROM “ESCOLA” es
WHERE es.idEscola = 200
))
“disciplina”
7.3.7 Subconsultas E Operadores De Comparação

Substituindo na consulta principal o SELECT falha.
Isto mostra que o próximo SELECT falha devido a compara-
ção com o operador maior que (>) que não pode comparar
89
Funções como (AVG, SUM, MAX, MIN, e COUNT) sempre retornam

um valor escalar. Assim, uma subconsulta com uma função agre-
gada os objetos sempre estão de acordo com a forma de sub-
consulta.
7.3.8 Operadores Modificadores ALL e ANY
• O operador ALL e ANY pode modificar uma operação de com-

paração em subconsultas fazendo com que a mesma aceite
múltiplos valores.
• A Forma geral com WHERE fica:
WHERE <expression> <comparison_operator> [ALL | ANY]

(subquery)
• Estas Subconsultas podem incluir GROUP BY e HAVING .
Comando ALL
O modificador ALL atua no comparador maior transformando-o

em maior que todos os valores.
WHERE ed.fk_estudante_rga > ALL (SELECT RGA
WHERE rga = 123123 )
“disciplina”
90
Bancos de dados
Comando ANY
Notas
• O modificador ANY não é restritivo como o comando ALL.
• Quando usado com maior que o operador “> ANY” pega

valores maior que alguns valores definidos pela subcon-
sulta.
Um operador “!= ANY”
O operador “= ANY” é idêntico ao operador IN. Porém, o

operador diferente “!= ANY” não equivale ao operador NOT IN.
7.3.9 Subconsultas correlatas
São consultas em que a subconsulta depende da consulta

externa. A consulta interna é executada repetidas vezes com
base nas colunas externas. Quando uma subconsulta usa o
operador EXISTS, a subconsulta funciona como um teste de
existência para as colunas. A cláusula WHERE da consulta ex-
terna testa a existência de linhas na subconsulta.A subcon-
sulta não produz qualquer dado, apenas retorna um valor
lógico de Verdadeiro ou Falso. O formato geral de uma sub-
consulta com comando EXISTS é da seguinte forma:
WHERE [NOT] EXISTS (subquery)
WHERE Exists (SELECT RGA
WHERE e.rga = ed.fk_estudante_rga
91
“disciplina”
Subconsulta usando um EXISTS possuem as seguintes caracte-

rísticas :
• Antes da palavra EXISTS não deve possuir nome de coluna ou

expressão.
• A cláusula select de uma subconsulta deve possuir sempre o

símbolo asterisco (*). Devido ao processo de simplesmente o
comando EXIST testar a existência de linhas.
• Uma subconsulta que utiliza um Exists pode ser uma subconsul-

ta correlata.
VIEWS
Uma view é uma tabela lógica ou virtual baseada em uma con-

sulta. Desta forma uma view é como uma consulta armazenada.
Views são criadas com o uso do comando CREATE VIEW aliado ao
uso do comando SELECT. Views são tabelas em memória.
7.3.10 Criando Uma VIEW
Syntaxe para Criar uma VIEW
92
Bancos de dados
CREATE [OR REPLACE] [FORCE|NOFORCE] VIEW <nome

Notas
da view> [(Campos alias nomes….)] AS <consulta>
[WITH [CHECK OPTION] [READ ONLY] [CONSTRAINT]];
A opção OR REPLACE é usada para alterar uma view exis-

tente. Esta opção deve ser utilizada para modificar uma view
sem ter que removê-la. A tentativa de criar uma view que já
existe sem usar o comando OR REPLACE retorna um erro.
CREATE VIEW Relatorio_professor_disciplina(Nome,

AreaFormacao, Especialidade, disciplina) AS
SELECT distinct p.Nome, p.AreaFormacao,p.Espe-

cialidade,d.nome
FROM “PROFESSOR” p JOIN “PROFESSOR_DIS-

CIPLINA” pd
ON pd.fk_professor_matricula = p.matri-
cula
JOIN “DISCIPLINA” d on pd.fk_discipli-

na_codigo = d.codigo
ORDER BY p.nome;
CREATE VIEW Query returned successfully in 63

msec.
SELECT * FROM “Relatorio_professor_disciplina”;
93
“nome” “areaformacao” “especialidade” “disciplina”
“Josá carlos” “Engenharia” “Computação” “Historia”
“Josá carlos” “Engenharia” “Computação” “Cálculo”
“Manoel de barros” “matemática” “licenciatura” “Banco de dados”
Note que apenas algumas colunas são definidas como parte da

View.
Uma consulta na view mostra os dados das disciplinas.
SELECT * FROM “Relatorio_professor_disciplina”;
“nome” “areaformacao” “especialidade” “disciplina”
“Josá carlos” “Engenharia” “Computação” “Historia”
“Josá carlos” “Engenharia” “Computação” “Cálculo”
“Manoel de barros” “matemática” “licenciatura” “Banco de dados”
É possível criar uma view que contenha a mesma estrutura de

uma tabela existente no banco de dados.A view chamada esco-
la_view possui a mesma estrutura da tabela departamento.
CREATE VIEW escola_view AS
SELECT *
FROM “ESCOLA”;
CREATE VIEW
Query returned successfully in 51 msec.
94
Bancos de dados
7.3.11 Funções e VIEWS – JOIN VIEW

Além de especificar as colunas de tabelas, você pode usar Notas
funções única composta por número de caracteres, data e
funções de grupo, assim como expressões para criar colunas
adicionais nas view. Isto pode ser extremamente útil, pois o
usuário do sistema terá acesso aos dados sem ter que en-
tender como usar as funções de base.
Dados de uma VIEW

Uma visão não armazena os dados. Os dados necessários
para as consultas da visão estão gravados no banco de da-
dos e a tabela resultante de uma view é armazenada tempo-
rariamente na memória.
• Pode ser inserido linhas em uma tabela se a view é do tipo

atualizável (não read-only).
• Uma view é atualizável se o comando de INSERT não violar

qualquer constraints.
• As violações de constraints para os comandos UPDATE e

DELETE também causa erro na criação de views.
Removendo uma VIEW

O comando para remover uma view é o comando DROP
VIEW. O seguinte comando remove a view chamada dept_
view.
DROP VIEW escola_view;

View dropped.
95
Dia 8
Dimensões de um SGBD
JOSIEL MAIMONE DE FIGUEIREDO
Bancos de dados
Desafio:
Considere as 3 demandas apresentadas a seguir:
1) É preciso armazenar as rotas de todos os ônibus da cidade de Cuiabá de
forma a auxiliar na gestão de transportes. É necessário envolver os aspectos
de pontos de ônibus, horário de passagem em cada ponto e a quantidade
de passageiros em cada ponto e horário. Deseja-se saber quais bairros pos-
suem maior demanda. Além disso, é necessário abastecer um aplicativo de
celular que mostra em tempo real o posicionamento de cada ônibus, bem
como a quantidade de passageiros.
2) Para utilização mais adequada das centenas de dispositivos de rada-
res fotográficos espalhados nas avenidas da cidade de Cuiabá, resolveu-se
capturar a imagem de todos os veículos, independente de multas. Assim
torna possível registrar o volume do tráfego bem como identificar acidentes
e/ou carros com boletins de ocorrências ativos.
3) Os setores de pronto atendimento nos hospitais municipais e postos de
saúde do Estado de MT resolveram armazenar os prontuários de todos os
pacientes, atendimentos, exames e profissionais de saúde envolvidos. Além
do controle interno, todas as informações devem ser enviadas para a Se-
cretaria Estadual de Saúde. Sabe-se que em torno de dez mil pessoas são
atendidas diariamente em cada unidade de saúde.
Apresente uma listagem envolvendo os tipos de dados, a quantidade de da-
dos e a infraestrutura computacional para cada demanda.
• Compreender os conceitos relacionados com as principais dimen-
sões de um SGBD Relacional.
• Entender as principais arquiteturas de software de um SGBD.
• Entender o funcionamento dos principais Modelos de Dados Lógicos.
• Exercitar o trabalho de forma colaborativa, expressando ideias e re-

sultados de forma clara e objetiva.
Um SGBD possui como principal característica a manipulação de da-
dos, contudo é importante destacar que algumas dimensões devem ser
entendidas de forma a se conseguir atingir todas as suas possibilidades
de armazenamento e disponibilização das informações.
Essas dimensões são destacadas neste dia.
97
Cap 8: Dimensão de um SGBD
8.1 Arquitetura de um SGBD

Um SGBD como qualquer outro software possui sua arquitetura
relacionada com a forma como se relaciona com o ambiente em
que está instalado.
8.1.1 Cliente/Servidor
É a arquitetura universal de um SGBD, no qual o mesmo fun-
ciona como um servidor de dados respondendo requisições de
um cliente. Dessa forma, o Servidor recebe uma String SQL de um
Cliente e responde com os dados.
Com a evolução das infraestruturas computacionais o servidor
de banco de dados passou a ser considerado como mais um ser-
viço a ser mantido na infraestrutura de hardware e software. Des-
sa forma, atualmente, temos uma variedade de configurações
de hardware e software, e a possibilidade de partes deles ou até
mesmo nenhum deles estarem implantados fisicamente dentro
da corporação ou fora através do uso de serviços de nuvem. Para
o servidor de banco de dados, as formas principais são listadas a
seguir.
8.1.2 On Premise
Uma arquitetura na qual tanto o hardware quanto o software
estão localizados nas instalações prediais da corporação. Dessa
forma, toda responsabilidade relacionada com a segurança, ba-
ckups e upgrades são de responsabilidade da corporação.
8.1.3 Cloud
Envolve o contexto no qual o SGBD está instalado em nuvem
computacional (que pode ser privada ou pública) e a corporação
não se preocupa com os aspectos de hardware envolvidos. Além
disso, um ambiente cloud possui a funcionalidade de elasticida-
de para atendimento das demandas, ou seja, se a demanda au-
menta, a nuvem aloca automaticamente mais hardware, que são
desalocados quando a demanda diminui.
O uso de nuvem computacional como infraestrutura envolve
várias possibilidades, sendo que tudo é tratado como um serviço
fornecido pela nuvem. Assim, podemos ter o hardware como um
serviço ou qualquer software, desde o sistema operacional até o
próprio SGBD como serviço.
Para quem utiliza o SGBD, o que muda é apenas a conexão com
98
Bancos de dados
o mesmo, ou seja, a string de conexão utiliza informações re-

lacionadas ao serviço Web, que é muito comum ser imple- Notas
mentado via protocolo REST.
Além das questões da infraestrutura na qual o SGBD fun-
ciona, é possível utilizar outras funcionalidades que garan-
tem o bom funcionamento e disponibilidade do serviço. Em
demandas de alta disponibilidade com milhares ou até mi-
lhões de solicitações é necessário utilizar novas instâncias do
servidor com cópias sincronizadas. As principais formas são:
• Replicação. O servidor SGBD possui uma ou mais cópias

(em máquinas diferentes) que são sincronizadas entre si e
atendem de forma independente as requisições dos clien-
tes. Normalmente as máquinas são semelhantes.
• Cluster. Para atender alta demanda de processamento,

várias máquinas são conectadas por rede dedicada e de
alta velocidade com o intuito de simular uma única má-
quina com maior poder de processamento. Dessa forma,
o serviço SGBD pode ser instalado em um cluster de má-
quinas, no qual cada máquina é denominada de nó e, o
conjunto delas é visto pelos clientes como uma única má-
quina.
• Distribuído. O servidor SGBD possui uma ou mais cópias

sincronizadas e distribuídas geograficamente em um con-
junto heterogêneo de máquinas. Apesar de funcionar para
os clientes da mesma forma que um cluster, ou seja, como
se fosse uma única máquina, a forma de sincronização é
diferente.
8.2 Modelo de Dados
Para manipular os dados, um SGBD utiliza um conjunto de

estruturas de dados que visam reproduzir da forma mais na-
tural um modelo de dados. Esse modelo de dados é a forma
com que os dados estão organizados e tem como principal
objetivo abstrair a forma como o SGBD organiza as informa-
ções em bits e bytes. A escolha do modelo de dados é in-
fluenciada por vários fatores, como a origem, o local de ar-
mazenamento, o volume e a variedade, sendo eles:
• Modelo Hierárquico. Considerado um dos primeiros mo-

delos de dados difundidos de forma massiva, ele foi forte-
99
mente influenciado pela forma de armazenamento na época

em que foi criado, ou seja, tem forte relação com a fita mag-
nética. Assim, os dados são organizados de forma hierárquica,
no qual o dado pai possui vários filhos, então o acesso tem de
seguir o caminho definido na hierarquia. Caso uma nova hie-
rarquia precise ser definida, então é feita uma cópia dos da-
dos. O maior representate desse modelo é o COBOL. Importan-
te destacar que grandes ambientes corporativos ainda usam
esse modelo.
• Modelo em Rede. Modelo no qual uma entidade pode se ligar

a várias outras e o acesso é genérico não precisando seguir
um único caminho. Apesar da flexibilidade este modelo possui
grande complexidade de manipulação pois aproxima muito a
estrutura de dados com a manipulação da informação.
• Modelo Relacional. Modelo no qual os dados são representa-

dos por relações (tabelas). Foi o primeiro modelo a realmente
separar a forma de manipulação interna do SGBD com a forma
com que o usuário manipula as informações, ou seja, a imple-
mentar a independência de dados. O que permitiu com que
o acesso fosse realizado por uma linguagem declarativa que
apenas lista as informações desejadas e não detalha a forma
como elas são obtidas. Este modelo foi padronizado na lingua-
gem SQL e se tornou o modelo mais difundido.
• Modelo Orientado a Objetos. Com a difusão das linguagens

Orientadas a Objeto, houve uma tendência de armazenar a in-
formação diretamente na forma como ela estava sendo mani-
pulada pelas aplicações. Apesar de diminuirmos o trabalho de
conversão de dados, os SGBD orientados a objeto não conse-
guiram se difundir para uso genérico, ficando restritos à alguns
nichos.
• Modelo Relacional-Objeto. Com as facilidades providas pelo

paradigma da orientação a objeto, bem como as fornecidas
pelo modelo relacional, percebeu-se que seria mais adequado
adicionar à segunda uma camada com as funcionalidades da
primeira. Ou seja, aproveitar todas as facilidades de acesso de-
clarativo da SQL e permitir que novos tipos de dados e compor-
tamentos funcionais fossem adicionados. A padronização ficou
conhecida como SQL-3, e é o padrão atual dos SGBD denomi-
nados relacionais. As primeiras grandes funcionalidades foram
a adição dos tipos de dados geográficos e os textos longos.
• Modelo NoSQL. Com o advento do contexto BigData, no qual
100
Bancos de dados
um imenso volume de dados variados é gerado em gran-

de velocidade, percebeu-se que converter os dados para Notas
tabelas não seria viável. Além disso, houve a necessidade
de distribuição dos dados. E a variedade dos dados de-
mandou o uso de dados semi-estruturados (ex: JSON e
XML) e também de dados complexos (ex: imagem, som e
vídeo). Com isso, o SGBD SQL não consegue atender todas
essas demandas devido à sua arquitetura e também seu
modelo de dados fixado em tabelas de quantidade fixa de
campos.
• Outro aspecto importante neste contexto é que os dados

gerados normalmente são usados somente para leituras
e não têm seus valores atualizados. Por exemplo, o com-
portamento de um usuário num determinado site, no dia
01/01/2023 fica registrado e não é alterado, pois um novo
comportamento será registrado em outro dia. Assim, te-
mos um contexto sem alterações nos dados com apenas
novos dados sendo inseridos. Nesse sentido, não há ne-
cessidade de controle de concorrência e nem de transa-
ção como é demandado pelo contexto relacional.
• Por isso, surgiram novos SGBDs, com modelos de dados

variados para atender demandas diferentes. Por questões
históricas eles foram denominados NoSQL, mas são pro-
dutos bem diferentes desde seus modelos de dados. Os
NoSQL são listados a seguir.
• Modelo Chave-Valor. É um modelo no qual um dado obri-

gatoriamente tem uma chave que tem um valor associa-
do. Na maioria dos casos para a chave é atribuída a saída
de uma função hash-distribuída, enquanto que o valor é
a informação a ser armazenada (que pode ser qualquer
coisa).
• Modelo Grafos. É um modelo no qual a informação impor-

tante é a forma como as entidades se relacionam e não os
valores das propriedades das mesmas. Assim, podemos
implementar uma rede social em forma de grafo, no qual
cada usuário se liga a outros. Interessante destacar que
diversas funcionalidades do modelo em rede foram reim-
plementadas aqui.
• Modelo Documentos. Um modelo no qual temos as infor-

mações organizadas de forma hierárquica no qual cada
nível possui uma etiqueta e um valor associado. Talvez a
101
tradução mais adequada para este tipo de modelo seria “for-

mulário” em vez de “documento”, pois a melhor analogia é a
ideia de um formulário com seus campos preenchidos. Os tipos
de dados JSON e XML são as representações mais difundidas
desse modelo. Importante destacar que diversas funcionalida-
des do modelo hierárquico foram reimplementadas aqui.
• Modelo Colunar. Um modelo no qual os dados são armazena-

dos em forma de colunas, o que facilita a consulta de informa-
ções agregadas e a geração de estatísticas.
• NewSQL. É um modelo relacional no qual as demandas Big Data

são atendidas, ou seja, mantém o controle de transações com
a política ACID, mas escala de forma distribuída.
• Multidimensional. É um modelo voltado para estatísticas nos

dados, assim os dados são organizados baseados em contas,
agregações e cruzamentos. A informação é centralizada no as-
sunto no qual as estatísticas são realizadas. Uma das vantagens
é que permite a navegação nos dados de forma a gerar relató-
rios dinâmicos, o que é denominado de OLAP- On Line Analitycal
Process. Que é diferente do contexto relacional que é voltado
para as transações (OLTP - On Line Transaction Process).
Normalmente este modelo é utilizado em ambientes de Data
Warehouse e Business Intelligence.
8.3 Controle de Transações e Concorrência
Um dos principais problemas relacionados com a integridade

na manipulação de dados é conseguir mantê-la num contexto
de acesso concorrente, ou seja, se dois ou mais usuários desejam
alterar simultaneamente o mesmo dado é preciso controlar para
que as alterações ocorram de forma a manter os dados íntegros.
A forma mais difundida para esse controle é realizado na for-
ma de transações, nas quais cada usuário realiza suas operações
dentro de blocos denominados de transações, por essa razão
também denominamos o contexto em que dados além de inse-
ridos são alterados de OLTP (Online Transaction Process). Esse é o
contexto mais comum nas operações corriqueiras de uma corpo-
ração e a forma mais comum de uso dos SGBD Relacionais como
o PostgreSQL.
Nos SGBDs Relacionais o controle de transações envolve a apli-
102
Bancos de dados
cação da política ACID:

Notas
• Atomicidade: toda transação tem seu conjunto de opera-
ções indivisíveis, ou seja, ou todas são consolidadas (“com-
mitada”) ou todas são canceladas (“abortada”). Dessa
forma, não importa se a transação possui 1 ou 1 milhão de
operações, ou todas terminam com sucesso ou nenhuma
é realizada.
• Consistência: consolidando ou abortando, toda transação

inicia em um estado consistente dos dados e termina em
estado consistente.
• Isolamento: uma transação ativa não enxerga as opera-

ções de outra transação ativa.
• Durabilidade: uma vez finalizada uma transação, todas

as suas operações são tornadas persistentes no disco.
Em caso de commit as operações são gravadas (os da-
dos são alterados) e em caso de abort são canceladas
(os dados voltam para o estado anterior da transação).
Este tipo de propriedade é importante para situações nos
quais os dados foram alterados na memória, mas antes
da gravação em disco ocorre algum problema no servidor,
tipo falta de energia. Nesse caso, ao religar o servidor, o
SGBD deve conseguir refazer as alterações que não foram
gravadas em disco.
Para manter as propriedades ACID de diversas transações
simultâneas, o SGBD usa de diversos controles e funcionali-
dades, sendo o principal o Log de Transações, que é abor-
dado em outro capítulo. Contudo é importante ressaltar que
para manter a integridade e consistência dos dados com as
transações algumas funcionalidades podem ficar em se-
gundo plano e podem ficar prejudicadas, como a questão
da velocidade de disponibilização dos dados, ou seja, em
ambientes que temos replicação dos dados, para manter a
sincronização dos servidores, muitas vezes é preciso esperar
todo o controle de transações até que consigamos acessar
um dado. Assim, ambientes com alta demanda, a falta de
disponibilidade pode inviabilizar o uso dos SGBD relacionais,
sendo essa uma das razões de difusão dos tipos NoSQL (que
serão abordados em outro capítulo), que não usam o contro-
le ACID em suas transações.
103
8.4 Tipos de Dados

No contexto computacional um tipo de dado é a forma de re-
presentar um dado específico. E para definir um tipo de dado pre-
cisamos de duas definições: operando e operador.
Operando é o dado em si e possui um domínio e uma represen-
tação computacional. Assim, um número natural pode assumir
valores inteiros maiores que zero. E sua representação computa-
cional envolve a quantidade de bits usados, ou seja, um número
com 8 bits permite representar 28=128 números diferentes.
Operador é a operação permitida para o tipo de dado, ou seja,
com um número natural podemos realizar operações como soma
e subtração. Dessa forma, um operador binário recebe de entrada
dois operandos e tem como saída um outro operando (que pode
ou não ser do mesmo tipo dos operandos de entrada).
Os tipos de dados mais comuns em SGBDs são: inteiros, reais,
alfanuméricos, booleanos e data.
A partir desses tipos primitivos, novos tipos foram incorporados
baseados em subtipos desse, como os especificados no Post-
greSQL. A Tabela 8.1, Tabela 8.2 e Tabela 8.3 apresentam os tipos
numéricos, textuais e data, respectivamente.
Tabela 8.1 – Tipos numéricos.
Tamanho em
Tipo disco Intervalo
smallint 2 bytes -32.768 a +32.767
integer -2.147.483.648 a +2.147.483.647

4 bytes
(2*109)
bigint -9.223.372.036.854.775.808
8 bytes
(9*1018) a
Até 131.072 dígitos antes da vírgula; até

decimal variável 16.383 dígitos depois da vírgula
Até 131.072 dígitos antes da vírgula; até

numeric variável 16.383 dígitos depois da vírgula
104
Bancos de dados
real 4 bytes Precisão de 6 dígitos decimais
double
precision 8 bytes Precisão de 15 dígitos decimais
smallserial 2 bytes 1 a 32.767
serial 4 bytes 1 a 2.147.483.647 (2*109)
bigserial 8 bytes 1 a 9.223.372.036.854.775.807 (9*1018)
-92.233.720.368.547.758,08 (9*1015) a
money 8 bytes
+92.233.720.368.547.758,08 (9*1015)
Tabela 8.2 - Tipos Textuais
Tipo Tamanho em disco
character varying(n),
Tamanho variável limitado a “n”
varchar(n)
character(n), char(n) Tamanho fixo limitado a “n” e preenchido

com branco se tamanho < n.
text Tamanho variável e ilimitado.
105
Tabela 8.2 - Tipos data
Tamanho em Descrição
Tipo disco (precisão) Intervalo
timestamp [ (p) ] [ 4713 AC

without time zone ] 8 bytes Data e hora (ms)
294276 DC
timestamp [ (p) ] Data e hora com fuso 4713 AC

with time zone 8 bytes horário (ms) 294276 DC
4713 AC
date 4 bytes Data (dia)
5874897 DC
00:00:00
time [ (p) ] [ without
time zone ] 8 bytes hora do dia(ms) 24:00:00
time [ (p) ] with time hora do dia com fuso horá- 00:00:00+1559
zone 12 bytes rio (ms) 24:00:00-1559
interval [ fields ] [ -178000000 anos

(p) ] 16 bytes intervalo de tempo (ms)
178000000 anos
Na evolução da computação a necessidade de manipular

tipos de dados mais complexos fez com que os SGBDs também se
adaptassem para atender essas novas demandas, assim incor-
poraram também tipos como os existentes no PostgreSQL:
• Tipos geométricos: point, lines, lseg, box, path, polygon, circle
• Tipos endereço de rede: inet, cidr, macaddr, macaddr8
• Tipos semiestruturados: XML, JSON
• Tipos binários: bit (n), bit varying(n), bytea
Para o contexto dos SGBD, além do tipo de dado (operando +
operador), é preciso definir também o tipo de índice (ou Método
de Acesso) para esse tipo. Um índice é uma estrutura de dados
que auxilia no processo de recuperação da informação daquele
tipo. O tipo de índice mais utilizado é a Árvore B, que é uma árvore
multivias balanceada voltada para acesso a disco.
Contudo, para tipos de dados complexos o índice baseado em
árvore B não funciona. Por exemplo, para textos longos, o índice
106
Bancos de dados
invertido é utilizado. Para dados espaciais, a árvore-R é utili-

zada. Para resolver essa questão o PostgreSQL fornece diver- Notas
sas funcionalidades:
• GIST (Generalized Search Tree) é um framework genérico

para indexação por árvores balanceadas (B-Tree, R-Tree,...)
• SP-GIST (Space Partitioned GIST) usado para indexação

por árvores não balanceadas (k-d trees, quad-trees,...)
• GIN (Generalized Inverted Index) usado para indexação de

itens com valores compostos, tipo documentos.
• BRIN (Block Range Index) usado para tabelas extrema-

mente grandes onde algumas colunas possuem relação
com a posição física na tabela.
• Hash usa funções hash para indexar qualquer tipo de

dado, contudo suporta somente o operador de igualdade.
8.5 Dispositivos de Armazenamento
A importância do dispositivo de armazenamento para o

SGBD está diretamente relacionado ao local onde os dados
se tornam realmente persistentes, ou seja, para o sistema
operacional os tipos de dispositivos são usados de forma ge-
nérica, mas para o SGBD, os objetivos primordiais são de ga-
rantir que as informações se tornem persistentes e que sua
recuperação seja rápida. Nesse sentido, otimizações especí-
ficas são realizadas para cada tipo de dispositivo de arma-
zenamento.
De forma bem resumida, os principais tipos de dispositivos
de armazenamento são:
• Cache: memória volátil mais veloz e normalmente próxima

da RAM ou HD. Porém, tamanho reduzido.
• RAM (ou memória principal): também volátil e onde é co-

locado tudo que a CPU vai usar nos processamentos, ou
seja, tudo passa pela RAM.
• Disco: onde as informações armazenadas se tornam per-

sistentes e não são perdidas após desligamento da máqui-
107
na, ou seja, são não voláteis e armazenam grande quantidade

de informação. Porém a velocidade de acesso é extremamente
menor que a da RAM.
• Fitas: normalmente magnéticas, são as mais baratas e que ar-

mazenam mais quantidade de informação. Contudo por sua
lentidão e acesso sequencial são mais utilizadas para backups
de dados acessados esporadicamente (offline).
As tecnologias de discos são as que têm tido mais mudanças
nos últimos tempos, de forma que novos tipos de disco têm surgi-
do. Os principais são:
• Discos Rígidos (HDD): Usam leitura/gravação magnética e são

relativamente baratos e são capazes de armazenar grandes
quantidades de dados. No entanto, eles são mais lentos do que
outros tipos de discos.
• Unidades de Estado Sólido (SSD): usam memória flash para

armazenar dados, o que os torna muito mais rápidos que os
discos rígidos, contudo não armazenam tantos dados e são
muito mais caros.
• Unidades de Estado Sólido NVM Express (NVMe): são uma evo-

lução dos SSD e tendem a alcançar velocidades de leitura e
gravação mais altas.
Um exemplo da intricada relação com o dispositivo de armaze-
namento é que a árvore-B só pode ser utilizada em dispositivos de
armazenamento com acesso aleatório, sendo bastante indicada
para uso em HD. Já em SSD, outras estruturas de dados podem
alcançar desempenho até melhor.
Outro aspecto importante em relação ao uso dos discos, é que
os mesmos podem estar em máquinas diferentes do SGBD, os
principais tipos de acesso são:
• Baseados em Rede (NAS): mais utilizados com acesso de rede

local e podem possuir dispositivos e hardware específicos para
esse tipo de serviço.
• Baseado em Nuvem: utiliza ambientes e serviços de Cloud

como local de armazenamento.
108
Dia 9
Projeto Físico
JOSIEL MAIMONE DE FIGUEIREDO
Cap 9: Projeto Físico
Desafio:
Considere o desafio do primeiro dia. Responda às seguintes perguntas:
1) Qual o espaço ocupado em disco de cada tabela?
a) ao iniciar o uso
b) após 6 meses
c) após 1 ano
2) Quais as duas consultas que mais demandam processamento. Faça a
estimativa da quantidade de dados que cada uma manipula por dia.
3) Com o projeto de crescimento das tabelas e das suas consultas, projeto
uma distribuição que utilize discos HD de diferentes velocidades e SSD.
4) Distribua as tabelas em mais de um esquema.
• Compreender os conceitos relacionados com o Projeto Físico.
• Aprender a construir um Projeto Físico de dados.
• Entender a relação dos dispositivos de armazenamento com o

SGBD Relacional.
• Exercitar o trabalho de forma colaborativa, expressando ideias e re-

sultados de forma clara e objetiva.
Apesar dos SGBD Relacionais trabalharem baseados em Independên-
cia de Dados, abstraindo a forma de organização interna dos dados é
preciso entender, bem como gerenciar a forma como essa organização
interna funciona, pois as informações em algum momento são arma-
zenadas no hardware.
Além disso, fazer a sintonia dos aspectos de software com os de har-
dware permite tirar melhor proveito do desempenho de cada um. As-
sim, o design da interação entre o SGBD e o hardware é denominado de
Projeto Físico do Banco de Dados.
110
Bancos de dados
9.1 O Projeto Físico

Notas
Um bom ambiente de Banco de Dados possui documenta-

do 3 projetos:
• Projeto Conceitual: envolve a preocupação com a intera-

ção com o mundo real e sua abstração. Não há preocupa-
ção com a tecnologia com que os dados serão manipula-
dos. E tem uma preocupação maior com o entendimento
do contexto.
• Projeto Lógico: envolve o mapeamento do projeto concei-

tual para a tecnologia que será utilizada para manipula-
ção dos dados. A preocupação já traz aspectos computa-
cionais, segurança de acesso, entre outros.
• Projeto Físico: tem uma preocupação de aliar as deman-

das dos dados com o hardware disponível, bem como
atender aos aspectos de desempenho.
Neste contexto, o Projeto Físico expande as questões iniciais
dos dados e tenta extrapolar o crescimento na quantidade
dos deles em tempos futuros. Nesse aspecto, são geradas
estimativas relacionadas com o espaço de armazenamento,
quantidade de registros de cada tabela, bem como quanti-
dade e frequência das consultas.
Para construção do Projeto Físico temos de listar cada ta-
bela, estimando o tamanho de cada registro, a quantida-
de de registros e o crescimento. Importante destacar que o
crescimento da quantidade de tuplas é específico de cada
tabela, por exemplo a quantidade de clientes cresce diferen-
te da quantidade de vendas. A tabela 9.1 ilustra um exemplo,
contudo não está sendo levado em conta os espaços ocupa-
dos pelos arquivos de índice.
111
Tabela 9.1 - Exemplo de mapeamento da ocupação em disco e do seu crescimento.
Ano 1 Ano 2
Tamanho
Tabela Campo Tipo (bytes) Qtd. Tuplas
Espaço
Qtd. Tuplas
Espaço
Ocupado Ocupado
codigo serial 4 100 2000
nome Varchar(50) 50 100 5000 500 25000

Cliente
idade smallint 2 200 1000
Subtotal 52 100 5600 1500 28000
valor money 8 80000 800000
timestamp
data [ (p) ] com 8 10000 80000 100000 800000
fuso
Venda
cliente integer 4 40000 400000
Subtotal 16 10000 200000 100000 2000000
TOTAL 68 10100 205600 101500 2028000
Com o tamanho de cada tabela é possível estimar o custo de

memória das consultas. Porém neste caso é importante identifi-
car a forma como o SGBD montou a consulta, o que pode ser feito
com o comando EXPLAIN, que é abordado em outro momento.
9.2 Uso de Memória: Processos
Para cada vez que um cliente abre uma conexão com o SGBD,
uma sessão é iniciada. Essa sessão representa uma área de me-
mória do servidor na qual as requisições serão processadas. Nes-
se sentido, um servidor deve possuir memória suficiente para
atender as várias sessões abertas pelos vários clientes.
Nessas sessões são armazenados dados relativos às consultas
demandadas, ou seja, além da SQL da consulta, são armazena-
dos dados intermediários e dados dos resultados finais. Caso a
112
Bancos de dados
memória fique cheia, ações como uso de memória virtual em

disco são realizadas. Notas
Aqui é importante destacar que diversas operações em

consultas geram dados temporários, sendo os mais comuns
os relacionados com ordenação. Operações como junções
e agregações podem gerar dados intermediários que preci-
sem ser ordenados e as técnicas de ordenação normalmen-
te demandam bastante processamento, por isso a memória
deve ser suficiente para atender ordenações.
Na figura 9.1 temos os processos do PostgreSQL, a área
Postgres Backend e a Shared Memory são as afetadas pe-
las sessões. Na Postgres Backend, temos a área de trabalho
(WORK_MEM) que possui as instruções do cliente e a área
TEMP_BUFFERS os dados temporários. Já a Shared Memory é
uma área compartilhada entre as sessões, possuindo duas
partes. A Shared Buffer que compartilha entre as sessões da-
dos comumente acessados e o WAL Buffer compartilha infor-
mações de transações.
Figura 9.1 - Ilustração dos processos e áreas de memória do servidor PostgreSQL.
9.3 Uso de Disco
Do ponto de vista de um sistema de gerenciamento de ban-

co de dados, a organização dos dados ocorre em dois níveis:
o nível lógico, que trata de uma abstração que determina o
como ocorre os acesso do ponto de vista da programação
113
do banco de dados; o nível físico, que trata do como o sistema de

gerenciamento de banco de dados vincula os dados dos progra-
mas aos dados efetivamente armazenados em arquivos.
9.3.1 Disco Lógico

O armazenamento dos dados em si, seguem a organização es-
tabelecida no projeto lógico, ou seja, temos atributos distribuídos
em tabelas que são ligadas por chaves estrangeiras. Contudo,
para melhor organizar um conjunto de tabelas e facilitar a ma-
nutenção, os SGBD dividem logicamente os dados em dois níveis:
database e schema. A Figura 9.2 ilustra o relacionamento entre
database, esquemas, objetos e as tablespaces.
Figura 9.2 - ilustração do relacionamento entre database, schema e tablespaces.
Nesse contexto, o projeto da base de dados deve contemplar

também a possibilidade de colocar as tabelas em databases ou
schemas diferentes. O principal direcionador é colocar em data-
bases diferentes conjunto de tabelas que envolvem um sistema
específico e as mesmas não precisam acessar dados de outro
conjunto de tabelas. Enquanto que a divisão em esquemas en-
volve a questão de módulo, ou seja, tabelas de módulos diferen-
tes podem ser agrupadas em esquemas diferentes. E por fim, as
tabelas de um mesmo módulo, ou tabelas que se referenciam
por chave estrangeira devem ser colocadas no mesmo esquema.
Portanto os aspectos lógicos das bases de dados podem e devem
ser tratadas pelo Programador.
A forma como o PostgreSQL trata esses níveis é explicada a se-
guir.
114
Bancos de dados
Database (base de dados).

Notas
Envolve o nível lógico mais alto e armazena todas as in-
formações necessárias para o bom funcionamento do SGBD.
Um database não acessa dados de outro database. No Post-
greSQL uma instância pode atender diversos databases, que
são agrupados em cluster.
Para criar um database usamos o comando CREATE DATA-
BASE e quem cria a base é o owner (dono) da mesma.
#CREATE DATABASE fic;
Schema(esquema).
É onde os objetos de armazenamento dão organizados.
É possível fazer analogia de que um esquema é uma pasta
onde incluímos nossos objetos (tabelas e outros recursos de
armazenamento). Um esquema pode acessar objetos de ou-
tros esquemas desde que dentro do mesmo database. Para
criação de um esquema usamos o comando CREATE SCHE-
MA.
#CREATE SCHEMA escola;
Como uma tabela está dentro de um esquema, então po-

demos ter tabelas de mesmo nome em esquemas diferentes.
Para fazer esse acesso, o PostgreSQL utiliza a variável sear-
ch_path, que determina o caminho percorrido nos esque-
mas para achar uma tabela.
Outra forma é explicitamente informar o esquema da tabe-
la (ou objeto):
SELECT *
FROM unemat.professor; // acessa a tabela pro-
fessor que está dentro do esquema unemat
115
SELECT *
FROM ufmt.professor;// acessa a tabela professor que
está dentro do esquema ufmt
9.3.2 Físico
Além da questão lógica de organização dos dados, tabelas e
objetos; é preciso saber onde no dispositivo de armazenamen-
to, normalmente arquivos no disco, que os database, esquemas e
objetos estão armazenados. Normalmente, esses aspectos físicos
são tratados pelo DBA que é quem gerencia os aspectos gerais
do SGBD. A ligação entre o lógico e o físico é feita pela tablespace.
a) Tablespace.
Uma tablespace é quem faz a ligação entre o lógico e o físi-
co, fazendo a ponte dos objetos com seus arquivos no disco. No
caso do PostgreSQL, uma tablespace corresponde a uma pasta.
Pode-se criar uma tablespace ou direcionar nossos objetos para
serem armazenados em tablespaces diferentes. Sendo pastas, as
tablespaces pode existir em discos diferentes, ou seja, podemos
direcionar objetos para HD, ou para SSD ou qualquer tipo de local
de armazenamento que o PostgreSQL tenha acesso. Pode-se criar
uma tablespace com o comando CREATE TABLESPACE (que deve
apontar para uma pasta vazia), e seu uso pelos objetos envolve a
cláusula TABLESPACE nos comandos CREATE ou ALTER.
CREATE TABLESPACE tbs_fic LOCATION /disco1/data’;

CREATE TABLE aluno (varchar(50) nome, login var-
char(20), data timestamp) TABLESPACE tbs_fic;
No contexto do PostgreSQL, três tablespaces merecem desta-

que:
• Tablespace pg_default: onde os dados das bases são coloca-

dos por padrão.
116
Bancos de dados
• Tablespace pg_global: envolve os objetos globais nos da-

tabases. Notas
• Tablespace temp: são tablespaces que possuem a pro-

priedade TEMP_TABLESPACES, e são utilizadas no armaze-
namento de dados temporários.
b) Logs de Transações (arquivos de WAL)

Os arquivos WAL envolvem um conjunto de arquivos que
armazenam os controles das transações ativas, por essa ra-
zão também são importantes no aspecto de seu local de ar-
mazenamento. Esses arquivos são importantes porque em
caso de algum tipo de desastre, a recuperação da base se
inicia por eles, ou seja, um desligamento não previsto do ser-
viço do SGBD obriga que ao ser religado o mesmo tem de re-
tornar a base para um estado consistente, assim os logs são
percorridos para garantir essa recuperação nos dados. Esses
arquivos de WAL também são utilizados nas funcionalidades
de replicação e backup online.
117
Dia 10
Modelagem Lógica:
Normalização
NIELSEN CASSIANO SIMÕES
Bancos de dados
Desafio:
Considerando a imagem abaixo como modelo para a emissão de Nota Fis-
cal de Serviços de uma determinada cidade, proponha um esquema re-
lacional normalizado para o armazenamento dos dados das NFS-e dessa
cidade.
• Compreender o conteúdo de normalização em banco de dados;
• Aprender a aplicar normalização em um banco de dados em produ-

ção.
119
Cap 10: Modelagem Lógica
10.1 Normalização em Banco de Dados Rela-

cional
Algumas vezes, precisamos lidar com dados gerados por ou-
tros sistemas, ou mesmo “digitalizar” processos que antigamente
eram realizados por meios físicos ou por diversos sistemas lega-
dos (cujos arquivos de dados eram armazenados em formatos
específicos, definidos pelo próprio programa ou sistema.
A incorporação desses dados, ou até mesmo o processo de “en-
genharia reversa” dos dados, é um processo que demanda um
procedimento de normalização, reduzindo a redundância dos da-
dos e sua consequente padronização. A normalização é funda-
mental para a organização dos dados em um SGBD relacional,
permitindo usufruir de todo o seu recurso.
Imagine uma Loja com diversas filiais que utiliza um determina-
do modelo de registro de ponto, ilustrado pela Figura 10.1.
Data: 03/02/2022 Setor: AD45 Administração - Loja 45
Empregado HIniP1 HFimP1 HIniP2 HFimP2 TotalHr HoraExtra Autorizado Por:
MARCOS ROBERTO DE JESUS 08:00 11:58 13:15 17:04 7,78 - -

NIVALDO FERREIRA 08:02 12:10 13:30 17:25 8,05 - -
SERGIO DOS SANTOS 08:00 11:50 13:25 17:37 8,03 - -
EDUARDO RIBEIRO SANTANA 08:00 12:00 13:22 18:00 8,63 0,43 EDUARDO RIBEIRO SANTANA
Data: 04/02/2022 Setor: AD45 Administração - Loja 45
Empregado HIniP1 HFimP1 HIniP2 HFimP2 TotalHr HoraExtra Autorizado Por:
ROBSON FERNANDES MARTINS 08:00 12:02 13:18 17:08 7,87 - -

NIVALDO FERREIRA 08:01 12:05 13:12 17:04 7,93 - -
EDUARDO RIBEIRO SANTANA 08:15 12:30 13:45 17:44 8,23 - -
SERGIO DOS SANTOS 08:22 12:29 13:30 17:02 7,65 - -
MARCOS ROBERTO DE JESUS 08:10 12:16 13:17 17:07 7,93 - -
Figura 10.1: Registro de ponto manual de uma filial de uma

empresa.
120
Bancos de dados
Note que podemos identificar alguns problemas de redun-

dância na tabela da Figura 10.1. Para um banco de dados re-
lacional, será necessário identificar os campos com redun-
dâncias para tentar eliminar esse problema nos dados. Além
disso, a inserção manual dos dados permite erros de digi-
tação, como no caso de SANTANA e SANT’ANA, ilustrado na
figura.
10.2 Eliminando as Redundâncias
A primeira etapa do processo é construir uma única tabela

com os dados com redundância, como ilustrado na Figura
10.2. A partir dessa tabela podemos identificar as entidades e
os possíveis relacionamentos que nos permitirão remover a
redundância dos dados para seu armazenamento no SGBD.
Autorizado
SetorID Setor Data Empregado HIniP1 HFimP1 HIniP2 HFimP2 TotalHr HoraExtra
Por:
AD45
Administração
Loja 45
03/02/2022
MARCOS ROBERTO
DE JESUS 08:00 11:58 13:15 17:04 7,78 - -
AD45
Administração
Loja 45
03/02/2022 NIVALDO FERREIRA 08:02 12:10 13:30 17:25 8,05 - -
AD45
Administração
Loja 45
03/02/2022
SERGIO DOS
SANTOS 08:00 11:50 13:25 17:37 8,03 - -
AD45
Administração
Loja 45
03/02/2022
EDUARDO RIBEIRO
SANTANA 08:00 12:00 13:22 18:00 8,63 0,43 EDUARDO RIBEIRO
SANTANA
AD45
Administração
Loja 45
04/02/2022
ROBSON FERNAN-
DES MARTINS 08:00 12:02 13:18 17:08 7,87 - -
AD45
Administração
Loja 45
04/02/2022 NIVALDO FERREIRA 08:01 12:05 13:12 17:04 7,93 - -
AD45
Administração
Loja 45
04/02/2022
EDUARDO RIBEIRO
SANTANA 08:15 12:30 13:45 17:44 8,23 - -
AD45
Administração
Loja 45 04/02/2022
SERGIO DOS
SANTOS 08:22 12:29 13:30 17:02 7,65 - -
AD45
Administração
Loja 45
04/02/2022
MARCOS ROBERTO
DE JESUS 08:10 12:16 13:17 17:07 7,93 - -
Figura 10.2: Tabela com redundância dos dados.
Note que os dados dos empregados podem ser substituí-

dos por um código, definindo uma entidade relacional para
este empregado. Da mesma forma, podemos remover o tex-
to descritivo do setor, deixando apenas seu identificador. O
resultado nos permite produzir uma tabela com os dados
do registro de ponto de cada funcionário sem redundância,
apenas com as referências de cada uma das entidades re-
lacionadas com o registro do ponto. Esse resultado pode ser
observado nas Tabelas 10.1, 10.2 e 10.3.
121
Cap 10: Modelagem Lógica
SetorID Setor
AD45 Administração-Loja 45
Tabela 10.1: Setores
ID Empregado
E001 MARCOS ROBERTO DE JESUS
E002 NIVALDO FERREIRA

E003 SERGIO DOS SANTOS
E004 EDUARDO RIBEIRO SANTANA
E004 ROBSON FERNANDES MARTINS
Tabela 10.2: Empregados
Note que a Tabela 10.3 possui os códigos do Setor (SetorID) e do

Empregado (EmpregadoID), substituindo as redundâncias ante-
riormente encontradas nos dados. O modelo relacional resultante
desse processo de normalização será:
Setores(SetorID, Setor)
Empregados(EmpregadoID, NomeEmpreado)
Ponto(SetorID, Data, EmpregadoID, HIniP1, HFimP1, HIniP2, HFImP2,
TotalHoras, HoraExtra, AutorizadoPor)
Observe agora que as redundâncias foram eliminadas, e nosso

modelo relacional já está “normalizado” e pronto para ser utiliza-
do em um SGBD relacional.
122
Dia 11
DDL e Otimização de
Consultas
NIELSEN CASSIANO SIMÕES
Cap 11: DDL e Otimização de Consultas
• Compreender os comandos de Data Definition Language (DDL) da

linguagem SQL;
• Compreender e identificar os problemas que requerem otimização

de consultas;
• Aprender quanto às vantagens e desvantagens da utilização de ín-

dices em SGBDs;
• Aprender a aplicar a otimização de consultas em um banco de da-

dos relacional.
124
Bancos de dados
11.1 DDL - Manipulando índices em banco

de dados relacionais Notas
Geralmente pensamos em utilizar índices quando temos a

necessidade de retornar algum conteúdo de uma tabela de
forma ordenada ou para garantir a unicidade de algum atri-
buto específico, como por exemplo o CPF de uma pessoa.
Entretanto, a utilização de índices vai além. O SGBD trata
os dados de forma organizada, relacionando tabelas em di-
ferentes arquivos de dados. Para garantir que o acesso aos
dados seja otimizado, o SGBD sempre armazena os dados de
forma não ordenada. Em disco, os dados são armazenados
sequencialmente sem qualquer ordem inicialmente definida.
Entretanto, os primeiros índices utilizados pelos SGBDs e pela
representação lógica do modelo relacional são para chaves
primárias. Os índices permitem que o SGBD encontre mais ra-
pidamente a posição em disco do registro de uma tabela. Por
exemplo, se o existe um índice por ordem alfabética, mesmo
que o campo chave seja o código do cliente, é possível rapi-
damente organizar os dados em ordem crescente alfabética
percorrendo o índice correspondente.
A linguagem SQL possui comandos específicos para a defi-
nição de índices no conjunto de comandos da Linguagem de
Definição de Dados (DDL). Os comandos CREATE INDEX, ALTER
INDEX e DROP INDEX são responsáveis pela manipulação de
índices no SGBD relacional. A seguir, serão apresentados de
forma resumida, cada um desses comandos.
CREATE INDEX ON tabelaNome (listDeCampos);
Cria um determinado índice para a tabela tabelaNome uti-

lizando os campos definidos em listaDeCampos, separados
por vírgula. Para se criar um índice único, deve-se acrescen-
tar o termo CREATE UNIQUE INDEX ao invés de CREATE INDEX. A
sinopse simplificada para o CREATE INDEX é:
125
Cap 11: DDL e Otimização de Consultas
CREATE [ UNIQUE ] INDEX [ [ IF NOT EXISTS ] name ]

ON [ ONLY ] table_name [ USING method ]
( { column_name | ( expression ) } ) ] ] [ ASC |
DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
[ NULLS [ NOT ] DISTINCT ]
ALTER INDEX nome RENAME TO novoNome;
De forma geral, é utilizado para renomear um índice específico.

A sinopse simplificada é:
ALTER INDEX [ IF EXISTS ] name RENAME TO new_name

DROP INDEX
Serve para remover um índice de uma tabela. A sinopse simpli-

ficada é:
DROP INDEX [ IF EXISTS ] name [, ...]
Utilizando o psql, podemos exibir a estrutura de uma tabela e

ver a lista de seus índices utilizando o comando \d nomeTabela. O
PostgreSQL armazena as informações dos índices em uma tabela
chamada pg_indexes. Portanto, para um determinado esquema
e tabela, pode-se usar o comando:
SELECT * FROM pg_indexes WHERE (schemaname = nomeDo-

Esquema AND tablename = nomeDaTabela);
126
Bancos de dados
11.2 Otimizando Consultas SQL

O processo de otimização de consultas não é simples, exige Notas
muita concentração e análise de cada etapa da construção

de uma consulta. O PostgreSQL fornece uma ferramenta para
analisarmos como os dados de uma consulta estão sendo
manipulados. Entretanto, é necessário que as configurações
de estatística do banco estejam ativas, pois estas estatísticas
serão utilizadas no processo decisório do motor de consultas
do PostgreSQL, o que influencia na escolha da estratégia de
solucionar a consulta.
ANALYZE;
Gera para todas as estatísticas das tabelas do SGBD. Pode

ser executado para apenas um conjunto de tabelas da forma
ANALYZE [ table_name [, ...] ]

EXPLAIN consulta_sql;
Realiza a preparação para a consulta_sql a ser executada

e exibe o plano de execução desta consulta.
VACUUM;
Libera os espaços ocupados por tuplas obsoletas ou exclu-

ídas em todo o banco.
VACUUM [FULL] [FREEZE] [VERBOSE] [ANALYZE] [ ta-

ble_name [, ...] ]
127
Dia 12
CONTROLE DE
USUÁRIOS
WILLYAN ALVES DA SILVA
Bancos de dados
Desafio:
Com a nova lei de LGPD (Lei Geral de Proteção aos Dados) e visando o evitar
a possibilidade de alteração indevida de de um registro, foi solicitado que
fossem criados usuários para os programadores Júnior com permissão de
apenas leitura.
• Criar usuários para acessar o banco de dados.
• Conceder permissões para o usuário para operações específicas.
• Retirar permissões para o usuário para operações específicas.

O controle de usuários em banco de dados é uma medida de segurança im-
portante para a proteção de suas informações. O principal objetivo é garantir
que somente usuários autorizados tenham acesso aos dados, evitando assim
o acesso não autorizado e a violação da privacidade das informações.
Para controlar o acesso dos usuários ao banco de dados, é necessário definir
permissões e privilégios específicos para cada usuário. Neste caso é impor-
tante definir diferentes níveis de permissões para diferentes tipos de usuários.
Por exemplo, é comum criar usuários com privilégios de leitura e gravação,
enquanto outros usuários têm apenas privilégios de leitura.
O controle de usuários é uma medida de segurança importante, que deve
ser bem implementada visando proteger as informações armazenadas, isso
inclui a atribuição de privilégios.
O controle pode ser aplicado a usuários e grupos. O controle de usuários em
banco de dados permite o gerenciamento de quem tem acesso ao banco de
dados. O controle de grupos permite a organização dos usuários em grupos
com permissões de acesso semelhantes.
Para melhor entendimento, deve-se conhecer alguns conceitos:
Objeto: é qualquer elemento do banco de dados, como tabelas, visões, pro-
cedimentos armazenados, esquemas, entre outros.
Usuário: é um indivíduo que se autentica no sistema e tem um identificador
único para acesso ao banco de dados.
Papel (Role): é um grupo de usuários com privilégios semelhantes.
Privilégio: é um direito de acesso a um objeto ou recurso do banco de dados,
como SELECT, INSERT, UPDATE, DELETE, entre outros.
O controle de privilégios também pode ser usado para garantir a integrida-
de dos dados. Por exemplo, é possível definir uma restrição evitando que os
usuários inseriram dados inválidos em uma tabela.
129
Cap 12: Controle de Usuários
12.1 Create User
Os usuários de um banco de dados podem ser criados e geren-

ciados, assim como suas permissões de acesso, permitindo que
apenas credenciais autorizadas possam acessar o banco de da-
dos. O usuário criado pode ser usado para autenticação e autori-
zação de acesso aos objetos e recursos do banco de dados.
O comando ‘CREATE USER’ é usado para criar um usuário no

banco de dados.
CREATE USER nome_do_usuario [OPTIONS];
É possível incluir algumas opções como:
• PASSWORD: permite a definição da senha do usuário;
• CREATEDB: concede o privilégio do usuário criar novos bancos

de dados;
• CREATEUSER: concede o privilégio do usuário criar outros usuá-

rios;
• VALID UNTIL: permite definir uma data de expiração para o usu-

ário.
Há outras opções que podem ser utilizadas combinado ao co-
mando CREATE USER.
Exemplo:
CREATE USER usuario_aluno PASSWORD ‘123456’ CREATEDB;
No exemplo é criado um usuário chamado “usuario_aluno” com

a senha “123456” e este usuário tem permissão para criar bancos
de dados.
É importante ressaltar que o PostgreSQL controla as permissões
por meio de ROLES, sendo o CREATE USER uma escrita alternativa.
Exemplo no PostgreSQL:
130
Bancos de dados
CREATE ROLE usuario_aluno LOGIN PASSWORD ‘123456’

Notas
VALID UNTIL ‘2023-05-15’;
No exemplo acima é criado um usuário chamado “usuario_

aluno” com a senha “123456” e expiração em “15/05/2023”.
Vale lembrar que, após a criação de um usuário, deve-se
definir suas permissões de acesso aos objetos e recursos do
banco de dados usando os comandos GRANT e REVOKE.
12.2 Grant
Quando um banco de dados é criado, ou algum objeto em

um banco, ele possui um proprietário (OWNER). O proprietário
possui direito de fazer qualquer alteração em sua base, con-
tudo se outro usuário desejar fazê-lo, ele deve possuir esse
privilégio.
O comando GRANT é usado para conceder privilégios a um
usuário ou papel em um objeto do banco de dados, como
tabelas, funções, esquemas, entre outros.
Exemplos:
O comando abaixo dá permissão de consultar (select) para
o usuário “usuario_aluno” na tabela “disciplina”.
GRANT SELECT ON disciplina TO usuario_aluno;

O comando abaixo é concedido o privilégio de consulta(-
select) para um grupo de usuários.
GRANT SELECT ON disciplina TO grupo_usuarios_rh;
O comando subsequente concedendo o direito de EXECUTE

em uma função para um papel.
GRANT EXECUTE ON FUNCTION limparAtribuicoes() TO

papel1;
131
Cap 12: Controle de Usuários
12.3 Revoke
O comando REVOKE é usado para revogar privilégios concedi-
dos. Por exemplo, para revogar o direito de SELECT concedido ao
usuário “usuario_aluno” na tabela “disciplina”, o seguinte coman-
do pode ser utilizado:
REVOKE SELECT ON disciplina TO usuario_aluno;
Abaixo é mostrado um comando que revoga a permissão de

exclusão de uma tabela para um papel.
REVOKE DELETE ON disciplina FROM papel2;
Revogando o direito de EXECUTE em uma função para um usu-

ário:
REVOKE EXECUTE ON FUNCTION limparAtribuicoes() FROM

usuario_aluno;
O PostgreSQL oferece outras formas de controle de privilégios,

como o uso de papéis (roles), que permitem agrupar usuários
com características semelhantes e facilitar o gerenciamento de
privilégios de acesso.
132
Dia 13
CONTROLE DE
TRANSAÇÕES
WILLYAN ALVES DA SILVA
Cap 13: Controle de Transações
Desafio:
Considere uma situação em que um sistema web é usado por milhares
de usuários simultaneamente, ocorrendo que em período de fechamento,
muitos usuários começaram a manipular dados na mesma tabela. Embora
cada usuário geralmente altere um registro diferente, houve um impasse
(deadlock) impedindo os demais usuários de continuar utilizando o ban-
co. Com base nestas informações identifique uma situação que poderia ter
ocorrido e qual estratégia poderia ser adotada?
• Entender o conceito de transações concorrentes;
• Criar transações explícitas e cancelá-las.
O Controle de Transações em Bancos de Dados é um fundamental na

gestão de dados em sistemas complexos. É responsável por garantir a
integridade e consistência dos dados durante a execução de operações
simultâneas, garantindo que uma transação seja executada como se
fosse a única operação a ser realizada no sistema.
Os bancos de dados modernos oferecem diversos mecanismos de
controle de transações, como o controle de concorrência, por exem-
plo. Os bancos de dados também oferecem recursos adicionais, como
o controle de isolamento, que ajuda a evitar que as transações sejam
executadas de forma incompleta.
O Controle de Transações em Bancos de Dados é essencial para ga-
rantir a integridade e consistência dos dados em sistemas complexos.
É elementar que bancos de dados relacionais tenham quatro caracte-
rísticas ou propriedades importantes, pois são fundamentais para apli-
cações complexas. Trata-se das propriedades ACID, que é um acrônimo
que representa as quatro propriedades fundamentais para garantir a
consistência e integridade dos dados em um sistema de banco de da-
dos:
A – Atomicidade. Uma transação deve ser considerada como uma
operação atômica, ou seja, ela é executada por completo ou não é exe-
cutada. Se uma transação falhar em algum ponto, todas as alterações
134
Bancos de dados
que foram realizadas naquela transação devem ser des-

feitas. Notas
C – Consistência. O banco de dados deve garantir que

todas as transações executadas mantenham a integri-
dade dos dados e respeitem as restrições definidas.
I – Isolamento. Cada transação deve ser executada de
forma isolada, sem interferir em outras transações que
estão sendo executadas simultaneamente.
D – Durabilidade. As alterações realizadas em uma
transação devem ser permanentes, mesmo em caso de
falhas do sistema, quedas de energia ou outros proble-
mas.
A ideia de transação equivale a atomicidade, pois visa
a execução de um conjunto de instruções como um todo.
135
Bancos de dados
13.1 Transações
Uma transação em banco de dados é uma unidade lógica Notas
de trabalho que consiste em um conjunto de operações que

são executadas de forma sequencial e que precisam ser exe-
cutadas de forma completa ou não executadas de forma al-
guma. Essas operações podem incluir inserção, atualização
ou remoção de dados de uma ou mais tabelas em um banco
de dados.
Uma transação é um mecanismo que garante que as ope-
rações em um banco de dados sejam executadas de forma
confiável e segura. Uma transação deve garantir a integri-
dade dos dados, ou seja, que as operações realizadas não
violam as restrições do banco de dados, e deve garantir a
consistência dos dados, ou seja, que os dados permaneçam
em um estado coerente antes e depois da transação.
13.2 Isolamento de Transações
Refere-se à capacidade de executar transações concor-

rentes de forma isolada, ou seja, sem que uma transação in-
terfira na execução de outras transações em andamento.
Dirty Read - “Leitura suja” está relacionado aos principais
problemas de integridade dos dados. Ocorre quando uma
transação altera um valor, uma outra transação lê o mesmo
valor, porém a primeira transação não confirma a gravação
dos dados.
Nonrepeatable read - Dados alterados em uma transação
e confirmados são “refletidos” em outra transação que não
foi gravada.
Phantom Read - Se um dado é inserido em uma transação,
reflete em outra transação. A distinção entre o Nonrepeatab-
le read é que se aplica para inserções de registros.
13.3 Níveis de Isolamento
Existem quatro níveis de isolamento de transações defi-

nidos pelo padrão ANSI SQL: Serializable, Repeatable Read,
Read Committed e Read Uncommitted. Cada um desses ní-
veis oferece um grau diferente de isolamento de transações,
137
sendo o nível mais alto o Serializable e o mais baixo o Read Un-

committed.
Read Uncommited.
Uma transação lê os dados de uma tabela sem bloqueá-los,
o que significa que os dados podem ser modificados por outra
transação durante a leitura. Isso pode resultar em problemas de
consistência, como leitura suja (dirty read).
Read Commited
Uma transação lê os dados de uma tabela e bloqueia esses da-
dos para evitar que outra transação possa modificá-los. No en-
tanto, diferentemente do nível Repeatable Read, os dados bloque-
ados são liberados imediatamente após a transação atual ser
concluída.
Repeatable Readed
Uma transação lê um conjunto de dados e bloqueia esses da-
dos para evitar que outra transação possa modificá-los até que a
primeira transação seja concluída.
Serializable
Todas as transações são executadas de forma sequencial e
sem interferência, como se fossem executadas uma de cada vez,
mesmo que várias transações estejam sendo executadas simul-
taneamente.
13.4 Bloqueios
Bloqueios em bancos de dados são mecanismos utilizados para

garantir a integridade dos dados e prevenir conflitos de acesso
entre transações. Quando uma transação precisa acessar um de-
terminado recurso, ela pode solicitar um bloqueio exclusivo (wri-
te lock) ou compartilhado (read lock) sobre o recurso em ques-
tão, impedindo que outras transações possam modificar ou ler os
mesmos dados simultaneamente.
No PostgreSQL, existem vários tipos de bloqueios que podem ser
utilizados para controlar o acesso aos dados:
• AccessShareLock. Bloqueio compartilhado de leitura, que per-

mite que outras transações também possam ler o recurso si-
multaneamente.
138
Bancos de dados
• RowShareLock. Bloqueio compartilhado de leitura em nível

de linha, permitindo que outras transações leiam outras li- Notas
nhas ao mesmo tempo.
• RowExclusiveLock. Bloqueio exclusivo de escrita em nível de

linha, permitindo que apenas a transação que obteve o
bloqueio possa modificar a linha em questão.
• ShareUpdateExclusiveLock. Bloqueio misto de compartilha-

do e exclusivo, utilizado em casos específicos de atualiza-
ção em cascata.
• ShareLock. Bloqueio compartilhado, que é menos restritivo

do que o RowShareLock e AccessShareLock.
• ExclusiveLock. Bloqueio exclusivo, que impede que outras

transações possam ler ou modificar o recurso em questão.
Além desses tipos de bloqueios, o PostgreSQL também su-
porta bloqueios em nível de tabela e de banco de dados,
como ShareRowExclusiveLock e ShareUpdateExclusiveLock,
que permitem controlar o acesso simultâneo a múltiplos re-
cursos.
13.5 MVCC
MVCC (Multi-Version Concurrency Control) é um mecanis-

mo utilizado em bancos de dados para permitir que várias
transações possam acessar os mesmos dados simultanea-
mente, sem que haja conflitos de acesso ou perda de inte-
gridade dos dados. Cada transação visualiza uma “versão”
consistente dos dados, de acordo com o momento em que
ela iniciou. Isso é possível porque, em vez de sobrescrever di-
retamente os dados existentes, as transações criam novas
versões dos dados, que são armazenadas em uma estrutura
conhecida como “histórico de versões”.
Esse mecanismo permite que várias transações possam
acessar os mesmos dados simultaneamente, sem que haja
bloqueios excessivos ou perda de integridade dos dados.
Além disso, como cada transação enxerga uma versão con-
sistente dos dados, é possível executar transações em para-
lelo, melhorando a performance do sistema como um todo.
139
13.6 Logs
Os logs em bancos de dados são registros que armazenam in-
formações sobre as operações realizadas no banco de dados. Es-
ses registros permitem que seja possível recuperar informações
em caso de falhas ou erros no sistema, garantindo assim a inte-
gridade dos dados.
Os logs podem ser utilizados para diferentes propósitos, como:
• Recuperação de desastres (Disaster Recovery). os logs permi-

tem que seja possível recuperar os dados em caso de falhas
no sistema, como quedas de energia, panes no hardware ou
erros de software. Com os logs, é possível restaurar o banco de
dados para um ponto anterior ao ocorrido, minimizando o im-
pacto no sistema e nos dados.
• Replicação de dados. Em sistemas distribuídos, os logs podem

ser utilizados para replicar dados entre diferentes nós do siste-
ma, garantindo assim a consistência dos dados em diferentes
pontos do sistema.
• Auditoria. Os logs podem ser utilizados para registrar as opera-

ções realizadas no banco de dados, permitindo que seja possí-
vel auditar o sistema e garantir a conformidade com as políti-
cas de segurança e privacidade.
140
Dia 14
PROCEDIMENTOS
ARMAZENADOS
MARCOS PAULO DE MESQUITA
Cap 14: Procedimentos Armazenados
Desafio:
Para aumentar a performance do sistema e incrementar a segurança sobre
os dados, algumas novas funcionalidades foram adicionadas ao módulo de
gestão de atribuição de aulas da plataforma tecnológica da Secretaria de
Ciência, Tecnologia e Inovação. Deseja-se que a quantidade de disciplinas
alocadas a um professor seja atualizada automaticamente a cada atribui-
ção feita para ele e por questões legais nenhum professor poderá ter mais
que 40h de aulas semanais atribuídas a ele.
Você deverá implementar no banco de dados estes dois novos requisitos.
• Automatizar funcionalidades no banco de dados;
• Manipular cursores no intuito de controlar os resultados retornados com

consultas SELECT;
• Implementar regras de negócio em banco de dados.

Para muitas aplicações, às vezes é útil criar módulos de programa de banco
de dados — procedimentos ou funções — que são armazenados e executados
pelo SGBD no servidor de banco de dados. Estes são historicamente conhe-
cidos como procedimentos armazenados (ou stored procedures) do banco
de dados, embora possam ser funções ou procedimentos. Os procedimentos
armazenados são úteis nas seguintes circunstâncias:
• Se um programa de banco de dados é necessário por várias aplicações, ele

pode ser armazenado no servidor e invocado por qualquer um dos progra-
mas de aplicação. Isso reduz a duplicação de esforço e melhora a modu-
laridade do software.
• A execução de um programa no servidor pode reduzir a transferência de

dados e o custo de comunicação entre o cliente e o servidor em certas si-
tuações.
• Esses procedimentos podem melhorar o poder de modelagem fornecido

pelas visões ao permitir que tipos mais complexos de dados derivados es-
tejam disponíveis aos usuários do banco de dados. Além disso, eles podem
ser usados para verificar restrições complexas que estão além do poder de
especificações de gatilhos. (Elmarsri e Navathe, 2011, p. 321)
Um procedimento por se escrito em uma linguagem de programação geral,
SQL puro ou alguma linguagem própria do SGBD.
142
Bancos de dados
14.1 Funções
Notas
Podemos dizer que uma função é um procedimento arma-

zenado que possui um retorno. Qualquer coleção de coman-
dos na linguagem SQL pode ser juntado e definido como uma
função. Como alternativa, se for desejado definir uma função
SQL que realiza ações mas não retorna um valor útil, a função
pode ser definida como retornando VOID. Uma função é cria-
da no bloco:
CREATE FUNCTION nome_função (lista de parâme-

tros)
RETURNS tipo de retornor AS
$$
DECLARE
Declaração de variáveis
BEGIN
Corpo da função
RETURN retorno da função;
END;
$$ LANGUAGE linguagem;
Vamos a exemplos.
F1: Estamos interessados numa função que soma dois nú-
meros inteiros. A soma de dois inteiros sempre retorna um
inteiro.
143
CREATE FUNCTION somar (x int, y int)
-- esta funcao tem dois inteiros como parâmetros
RETURNS int AS
-- esta funcao retorna um inteiro
$$
DECLARE
z int;
-- vamos usar uma variável para armazenar a soma e

utilizá-la no retorno da função
BEGIN
z = x + y;
RETURN z;
END; $$ LANGUAGE plpgSQL;
Para executar a função usamos o SELECT.
SELECT somar (56,30);
F2: Deseja-se uma função que busque o nome de um professor

a partir de seu número de matrícula. Note que isso poderia ser fei-
to com um SELECT, mas o encapsulamento é uma das vantagens
do uso de funções.
144
Bancos de dados
CREATE FUNCTION getProfessor(matriculaPro INT)

Notas
RETURNS text AS
$$
DECLARE
nomePro text;
BEGIN
SELECT INTO nomePro nome FROM professor WHERE

matricula= matriculaPro;
RETURN nomePro;
END;
$$ LANGUAGE plpgSQL;
F3: Implementar uma função que retorna a quantidade de

disciplinas atribuídas para um determinado professor.
CREATE FUNCTION contar_disciplinas(matriculaP

int) RETURNS int
AS
$$
DECLARE
total int;
BEGIN
SELECT INTO total count(*) FROM Disciplina_atri-

buida_Professor WHERE matricula = matriculaP;
145
RETURN total;
END;
$$ LANGUAGE plpgsql;
Esta função conta quantas tuplas daquele determinado profes-

sor aparecem na tabela de atribuição. Passamos como parâme-
tro da função a matrícula do professor de interesse.
A linguagem PL/Pgsql dá suporte a estruturas de controle LOOP,
FOR, IF e tipos de dados bem elaborados. Consulte o material extra
para saber mais sobre este assunto.
! Melhoria do Projeto: A tabela de professor não possui uma co-

luna que descreve a quantidade de disciplinas atribuída. Vamos
criá-la:
ALTER TABLE professor ADD nroDisciplinas int DEFAULT 0;
F4: Agora que a coluna foi adicionada, como poderia ser uma
função para atualizar cada tupla com a quantidade de disciplinas
que eles têm atribuída?
CREATE or REPLACE FUNCTION atualiza_nroDisciplinas()

RETURNS void
AS
$$
DECLARE matriculaPro int;
DECLARE total int;
146
Bancos de dados
BEGIN
Notas
FOR matriculaPro in select matricula from Pro-
fessor LOOP
SELECT into total contar_disciplinas(matricu-

laPro)
UPDATE professor SET nroDisciplinas = total WHE-

RE matricula=matriculaPro;
END LOOP;
END; $$ LANGUAGE plpgsql;
SELECT atualiza_nroDisciplinas();
F4 faz uma chamada à F3. A estrutura de controle FOR...

LOOP percorre cada tupla da tabela professor e pelo núme-
ro de matrícula invoca F3 com este parâmetro contando as
disciplinas e atualizando a coluna de quantidade com o valor
que fora retornado.
14.2 Cursores
Um cursor pode ser visto como um ponteiro que aponta

para uma única tupla de um conjunto de tuplas. Eles são par-
ticularmente interessantes quando se trabalha com consul-
tas que retornam um número bem elevado de registros. Os
cursores também são úteis para um melhor uso da memória.
É por meio de cursores que uma aplicação escrita numa
linguagem geral como C ou Java manipulará os resultados
das consultas quando se tem SQL embutida em seu código.
147
Um cursor pode ser visto com uma tabela temporária na qual

você acessa os registros por meio de offset (deslocamento) rela-
tivos a uma posição relativa ou a uma posição absoluta. A variá-
vel do cursor é basicamente um iterador (iterator) que percorre as
(por loop) tuplas no resultado da consulta — uma tupla de cada
vez. A seguir alguns exemplos de uso de cursores.
Suponha que na página da plataforma da secretaria você de-
seja listar detalhes de cada escola. No entanto a cada página
você está interessado em exibir 5 escolas por vez. Sua página de
navegação então deve permitir avançar e retroagir entre os resul-
tados da consulta. Este é um exemplo prático onde você poderia
aplicar cursores.
begin;
-- em Postgresql os cursores são manipulados dentro

de uma transação
declare cur CURSOR for select * from escola;
-- um cursor para todos os registros da tabela escola
fetch first in cur;
-- seleciona o primeiro registro
fetch last in cur;
-- seleciona o último registro
fetch relative -3 in cur;
-- seleciona o 3o registro anterior ao atual
move first in cur;
-- movimenta o cursor sem retornar dados
close cur;
-- fecha o cursor
148
Bancos de dados
end;
Notas
14.3 Gatilhos (Triggers)
Nos sistemas de banco de dados relacionais de hoje é pos-

sível associar gatilhos (ou triggers) a tabelas. Um gatilho é
uma forma de regra ativada por atualizações na tabela, que
resulta na realização de algumas operações adicionais em
algumas outras tabelas, envio de mensagens, e assim por
diante. A funcionalidade mais poderosa é fornecida por sis-
temas de banco de dados ativos, que oferecem regras ativas
que podem automaticamente iniciar ações quando ocorrem
certos eventos e condições (Elmasri e Navathe).
Os gatilhos, diferentemente das funções, trabalham com
objetos que armazenam dados com determinada ação pro-
gramada. As ações que disparam um gatilho são: INSERT, UP-
DATE e DELETE. As variáveis NEW e OLD são as mais comumen-
te usadas em gatilhos. O objeto NEW é um ponteiro para os
novos registros do banco de dados. Depois de uma operação
INSERT ou UPDATE este objeto estará disponível. O objeto OLD
é um ponteiro para os registros excluídos ou modificados no
banco de dados. Depois de uma operação de DELETE ou UP-
DATE este objeto estará disponível.
Uma trigger é criada no bloco:
CREATE FUNCTION nome_função (lista de parâme-

tros)
RETURNS trigger AS
$$
DECLARE
Declaração de variáveis
BEGIN
Corpo da função
149
RETURN new/old;
END;
$$ LANGUAGE linguagem;
Note a diferença em relação a uma função padrão no tipo

de retorno e no retorno da função trigger.
Além da função que desempenhará uma operação espe-
cífica, há de se criar o gatilho propriamente dito. Devemos
explicitar em que circunstâncias essa função será chama-
da. Uma trigger pode ser ativada em dois momentos: BEFO-
RE (antes) ou AFTER (depois) de alguma ação. Uma trigger
pode ser executada em dois modos de execução: uma vez
a cada registro afetado pela ação que ativou a trigger (FOR
EACH ROW), ou apenas uma vez por execução da ação (FOR
EACH STATEMENT);
CREATE TRIGGER nome_da_trigger
[BEFORE/AFTER] [INSERT/UPDATE/DELETE] ON tb_ta-

bela_de_atuacao_da_trigger
FOR EACH [ROW/STATEMENT] EXECUTE PROCEDURE

nome_da_funcao();
T1: Com a mudança que fizemos no projeto, agora o banco

de dados possui a quantidade total de disciplinas para cada
professor. A questão agora é um pouco diferente: Novas atri-
buições continuarão sendo feitas, e não queremos ter que
atualizar novamente todos os registros. Nosso objetivo então
é atualizar, no momento que a atribuição é feita, a quantida-
de de disciplinas atribuídas daquele professor.
150
Bancos de dados
Notas
151

Apostila Fic Dev2 BD Final

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Fic Dev2 BD Final

Enviado por

Direitos autorais:

Formatos disponíveis

GOVERNADOR DO ESTADO DE MATO GROSSO

Mauro Mendes Ferreira

MINISTRO DA CIÊNCIA TECNOLOGIA E INOVAÇÕES

SECRETÁRIO DE ESTADO DE CIÊNCIA TECNOLOGIA E INOVAÇÃO DE MT

SUPERINTENDENTE DE EDUCAÇÃO PROFISSIONAL E SUPERIOR

REITORA DA UNIVERSIDADE DO ESTADO DE MATO GROSSO

COMISSÃO DE ELABORAÇÃO DO MATERIAL DIDÁTICO

Título: Banco de dados

7.3 Subconsultas 83 9.3.1 Disco Lógico 112

7.3.4 Subconsultas e o Operador IN 10.1 Normalização em Banco de Da-

7.3.5 Subconsultas e o Operador NOT 10.2 Eliminando as Redundâncias119

• Contextualizar o desenvolvimento dos sistemas de gerenciamento

• Apresentar e discutir tipos de usuários de Bancos de Dados e suas

• Desenvolver de modelagem de banco de dados, aplicando o Modelo

• Exercitar a modelagem de dados com o uso de software de auxílio à

Nesta disciplina, abordaremos os conceitos fundamentais

1.1 O que é um Banco de Dados?

Como você poderia fazer isso?

Figura 1.1 - Imagem elaborada pelo autor.

Uma sugestão para resolução deste problema seria criar um

cionários e os usuários encontrem e acessem facilmente os

Nesses exemplos, tanto o lúdico quanto o real, um banco de

• Banco de dados. É uma coleção organizada de dados ar-

• Dado. Os dados são a matéria-prima do mundo digi-

dia (por exemplo, 25°C) é um dado. Nesse caso, a temperatura

• Informação. A informação é o resultado do processamento e

• Conhecimento. O conhecimento é o entendimento e a sabe-

Durante o nosso estudo, você irá se deparar com os termos “Sis-

• Um sistema de banco de dados refere-se à estrutura geral e ao

saúde, educação e governo.

• Um SGBD é um software específico projetado para geren-

Para entender como tudo isso começou é importante e ne-

1.2. Do BIT ao Big Data: Evolução dos

bancos de dados é uma história de inovação e adaptação con-

ção e manipulação das informações. O IBM IMS, lançado em

bancos de dados são projetados para serem escaláveis, flexí-

1.3. Diferentes tipos de usuários de Bancos

Os bancos de dados desempenham um papel crucial no arma-

• Usuário Final. O usuário final é a pessoa que interage direta-

mente com os dados armazenados no banco de dados,

• Programador. O programador é responsável pelo desen-

• DBA (Database Administrator). O DBA é o profissional res-

• Engenheiro de Dados. O engenheiro de dados é respon-

para análises e insights.

• DPO (Data Protection Officer). O DPO é responsável por garan-

• CDO (Chief Data Officer). O CDO é um executivo de alto nível

Vamos usar a analogia de um restaurante para entender os di-

• Usuário Final. Os clientes do restaurante, que consomem os

• Programador. O chef que cria e prepara os pratos (aplicações).

• DBA (Database Administrator). O gerente do restaurante, res-

• Engenheiro de Dados. O arquiteto responsável pelo projeto e

• DPO (Data Protection Officer). A pessoa encarregada de garan-

• CDO (Chief Data Officer). O proprietário do restaurante, que de-

1.4. Modelagem Conceitual

A modelagem conceitual é uma fase fundamental no pro-

• Entidades. As entidades são os objetos ou conceitos do

• Atributos. Os atributos são as características ou proprieda-

• Relacionamentos. Os relacionamentos descrevem como

• Restrições. As restrições são regras que definem limitações ou

Uma abordagem popular é a utilização do Modelo Entidade-Re-

1.5. Modelo Entidade-Relacionamento (MER)

Modelo Entidade-Relacionamento (MER) é uma técnica de mo-

Figura 1.2 - Elementos de um Diagrama Entidade Relacionamento (Fonte: Peter Chen)

7.3 Subconsultas 83 9.3.1 Disco Lógico 112

7.3.5 Subconsultas e o Operador NOT 10.2 Eliminando as Redundâncias119