Prévia do material em texto

M
O
D
E
L
A
G
E
M
 D
E
 B
A
N
C
O
 D
E
 D
A
D
O
S
 E
 S
Q
L
Ja
im
e
 W
o
jc
ie
c
h
o
w
s
k
i
Código Logístico
I000034
Fundação Biblioteca Nacional
ISBN 978-65-5821-037-5
9 7 8 6 5 5 8 2 1 0 3 7 5
Modelagem de banco 
de dados e SQL 
Jaime Wojciechowski
IESDE BRASIL
2021
© 2021 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e do 
detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: Alexander Supertramp/whiteMocca/Shutterstock
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
W828m
Wojciechowski, Jaime
Modelagem de banco de dados e SQL / Jaime Wojciechowski. - 1. ed. 
- Curitiba [PR] : IESDE, 2021.
142 p. : il.
Inclui bibliografia
ISBN 978-65-5821-037-5
1. Banco de dados - Desenvolvimento. 2. Projeto de bancos de dados. 
3. Bancos de dados relacionais. 4. SQL (Linguagem de programação de 
computador). I. Título.
21-71228 CDD: 005.75
CDU: 004.65
Jaime Wojciechowski Doutor em Informática Aplicada em Engenharia Florestal 
pela Universidade Federal do Paraná (UFPR). Mestre 
em Informática Aplicada em Inteligência Artificial e 
graduado em Matemática (bacharelado e licenciatura) 
pela Pontifícia Universidade Católica do Paraná (PUCPR). 
Atua desde 1994 como docente no ensino superior, tendo 
ingressado na UFPR no ano de 2006, instituição na qual 
é professor titular das disciplinas de Análise e Projetos 
de Sistemas, do curso superior de Tecnologia em Análise 
e Desenvolvimento de Sistemas; Modelagem Ágil de 
Software, do curso de Especialização em Desenvolvimento 
Ágil de Software; Aprendizado de Máquina e Laboratório 
de Inteligência Artificial, do curso de Especialização em 
Inteligência Artificial Aplicada; e Sistemas Computacionais 
Aplicados, do curso de Especialização em Manejo 
Florestal. Também é vice-diretor do Setor de Educação 
Profissional e Tecnológica da mesma instituição. Foi 
analista de sistemas em ambiente de desenvolvimento 
de grande porte (mainframe). Trabalhou na área de 
desenvolvimento e treinamento para a formação de 
novos programadores dos bancos Estado do Paraná 
(Banestado), Itaú, Santander Banespa e HSBC Bank Brasil.
SUMÁRIO
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
1 Conceitos gerais de modelagem de banco de dados 9
1.1 Introdução aos bancos de dados 9
1.2 Sistemas gerenciadores de banco de dados (SGBD) 17
1.3 Conceitos gerais de modelagem de dados 25
2 Modelo relacional 36
2.1 Modelo conceitual 36
2.2 Modelo lógico 40
2.3 Primeira forma normal (1FN) 44
2.4 Segunda forma normal (2FN) 48
2.5 Terceira forma normal (3FN) 50
2.6 Relacionamentos entre as tabelas 58
3 Linguagem SQL – DDL 64
3.1 Modelo físico 64
3.2 Criação do modelo físico usando SQL – DDL 70
3.3 Criação do modelo físico no banco de dados PostgreSql 77
4 Linguagem SQL – DML 87
4.1 Comandos SQL para atualização 87
4.2 Comandos SQL para consultas básicas 93
4.3 Comandos SQL para consultas avançadas 106
5 Conceitos avançados de banco de dados 115
5.1 Visões, gatilhos e Stored Procedures 116
5.2 Processamento de transações 124
5.3 Utilização da linguagem SQL na linguagem de 
 programação Java 129
 Resolução das atividades 140
O processo de desenvolvimento de um software abrange 
várias etapas, e cada uma delas contribui para a etapa posterior, 
até a sua finalização. Independentemente do tipo de software e da 
etapa, o desenvolvedor precisa dispor de um repositório no qual os 
dados contidos no problema serão armazenados e manipulados. 
Na indústria de software, os bancos de dados fazem essa função. 
Porém, a utilização dessas estruturas requer que os dados sejam 
organizados de modo que atendam às premissas impostas por 
eles. Para que as informações sejam armazenadas em um banco 
de dados, em primeiro lugar, devemos aplicar algumas técnicas, 
a fim de garantirmos a possibilidade de manipulação dos dados 
sem causar inconsistências, nem produzir resultados errôneos.
Neste livro apresentamos as técnicas de normalização que 
organizam e colocam os dados em uma estrutura compatível 
com os bancos de dados, assim como todos os comandos 
necessários para criarmos um banco que contemple seus diversos 
componentes. Mostramos como acessar de maneira eficiente os 
dados armazenados, atendendo às necessidades do software. 
Sobretudo, a obra expõe os aspectos do gerenciamento das 
informações no banco de dados feito pelo sistema gerenciador de 
banco de dados (SGBD), que não só controla os acessos, como 
também a concorrência das solicitações, impedindo que erros 
sejam cometidos quando há um alto tráfego de dados.
Essas teorias são imprescindíveis para o sucesso de um 
software. Considerando que este é formado por diversos 
componentes, como telas, programas, arquitetura de 
comunicação, entre outros, e pelo próprio banco de dados, a 
boa organização e estruturação dos dados garante grande parte 
do sucesso do software, pois em praticamente todas as funções 
espalhadas nas diversas telas sempre haverá uma interação com o 
banco de dados. Se mal organizado ou com carência de aplicação 
das técnicas corretas, o banco de dados causará grande impacto 
no fluxo de informações não somente em termos de lentidão 
de resposta, mas principalmente de informações erradas sendo 
apresentadas ao usuário. Esses aspectos geram um impacto 
APRESENTAÇÃOVídeo
8 Modelagem de banco de dados e SQL
extremamente negativo para o software, causando depreciação e descrédito 
nas pessoas que efetivamente o utilizarão.
Ainda trouxemos vários aspectos teóricos de embasamento dos conceitos, 
com foco na sua aplicação prática. Descrevemos os comandos que devem ser 
emitidos ao banco de dados, bem como os resultados obtidos, de modo que você 
possa compreender exatamente a forma como o banco emitiu esses resultados.
Ao final do estudo, você será capaz de construir e manusear um banco 
de dados para o software que está desenvolvendo, além de compreender 
efetivamente a interação entre o software e o banco.
Bons estudos!
Conceitos gerais de modelagem de banco de dados 9
1
Conceitos gerais de modelagem 
de banco de dados
Neste capítulo, conheceremos uma importante estrutura utili-
zada em larga escala nos dias de hoje, sem a qual não teria sen-
tido o uso de sistemas de informação. Os bancos de dados estão 
presentes em praticamente todos os sistemas que utilizamos em 
nosso cotidiano.
Abordaremos os principais conceitos necessários para a tarefa 
de modelagem dos dados, com o objetivo de utilizarmos os bancos 
de dados e os softwares conhecidos como sistemas gerenciadores 
de banco de dados (SGBD).
Conheceremos o histórico do surgimento dos bancos de da-
dos, as motivações e quais problemas ocorriam para justificar a 
sua ampla utilização e todas as vantagens para os sistemas de in-
formação. Com os conceitos iniciais a serem abordados, será pos-
sível entender as formas de armazenamento dos dados, como são 
realizados os acessosno banco de dados e quais elementos são 
necessários para que os sistemas de informações possam utilizar 
essa estrutura de modo eficiente, a fim de garantir a integridade 
dos dados e o sucesso em seus objetivos.
1.1 Introdução aos bancos de dados 
Vídeo Os bancos de dados estão incorporados em praticamente todos os 
aspectos do nosso cotidiano. Dificilmente um sistema que controla o 
negócio de uma empresa ou mesmo os sistemas que tratam de aspec-
tos da vida das pessoas não necessitam armazenar dados.
Se pensarmos nas diversas redes sociais existentes, todas as infor-
mações de seus usuários, bem como todas as atividades realizadas por 
10 Modelagem de banco de dados e SQL
eles, necessitam ficar armazenadas. Quando fazemos uma postagem 
ou um comentário, eles necessariamente devem ficar guardados e 
prontos para serem recuperados no momento que forem solicitados.
A Figura 1 mostra um exemplo de postagem em uma rede social 
na qual é possível identificarmos vários elementos que precisam ser 
armazenados.
Figura 1
Exemplo de dados de uma postagem em rede social
Autor
Legenda
Imagem
Comentário
Fonte: Facebook, 2021.
Nas interações com sistemas de informações, temos a necessidade 
de manipular dados, seja para consultas seja para efetuarmos alguma 
transação. Em todos os acessos que fazemos pela internet, por exem-
plo, as páginas que consultamos nos trazem uma imensa quantidade 
de dados. Quando realizamos uma compra, uma reserva, uma matrícu-
la ou qualquer interação com empresas, também temos a necessidade 
de fornecer ou receber dados.
De acordo com Silberschatz, Korth e Sudarshan (2020), são alguns 
tipos de sistemas e seus dados:
Conceitos gerais de modelagem de banco de dados 11
Vendas: dados de 
clientes, produtos e 
vendas.
Contabilidade: dados de 
pagamentos, recebimentos, 
saldo de contas contábeis e 
patrimônio para geração de 
balanços contábeis.
Recursos humanos: dados 
de funcionários, salários e 
benefícios, para a geração 
de contracheques.
Bancos: clientes, conta 
corrente, empréstimos, 
poupança, PIX.
Cartões de crédito: 
dados das compras e 
dos pagamentos.
Companhias aéreas: 
clientes, voos, passagens 
(as companhias aéreas 
estão entre as primeiras 
empresas a utilizarem bancos 
de dados de uma forma 
geograficamente distribuída).
Bl
an
-k
/
Sh
ut
te
rs
to
ck
da
vo
od
a/
 
Sh
ut
te
rs
to
ck
da
vo
od
a/
 
Sh
ut
te
rs
to
ck
da
vo
od
a/
 
Sh
ut
te
rs
to
ck
da
vo
od
a/
 
Sh
ut
te
rs
to
ck
da
vo
od
a/
 
Sh
ut
te
rs
to
ck
Podemos perceber que, mesmo não nos dando conta, os bancos 
de dados estão presentes e são um componente essencial da vida na 
sociedade atual (ELMASRI; NAVATHE, 2013).
Antigamente, os dados dos sistemas de informações eram arma-
zenados em arquivos organizados pelos desenvolvedores dos progra-
12 Modelagem de banco de dados e SQL
mas. Tal organização carecia de uma padronização, pois cada sistema 
estruturava seus arquivos da maneira que achava mais conveniente 
para suas necessidades. Com isso, a manipulação desses arquivos fica-
va por conta dos programas responsáveis por eles.
Esse procedimento trazia certos problemas, entre eles:
 • Manutenção dos programas: como as definições do formato 
dos dados ficavam descritas dentro dos programas, cada vez que 
esse formato era alterado, seja pela inclusão/exclusão de novos 
dados ou alteração das características de um deles, todos os pro-
gramas necessitavam de alteração.
 • Acesso aos dados: todos os procedimentos para buscar os da-
dos que o programa necessitava tinham de ser colocados nos 
programas, ou seja, além da lógica própria do programa para 
tratar o problema de negócio para o qual ele foi escrito, o progra-
ma continha inúmeras linhas com procedimentos normalmente 
complexos para se ler ou atualizar dados nos arquivos.
 • Controle de acesso: também era necessário o controle para que 
vários usuários fizessem o acesso aos dados ao mesmo tempo, 
sem o risco de se perder a integridade deles.
 • Garantia da integridade dos dados: nos casos de falhas no de-
correr dos processos de atualização de um conjunto de dados, 
o programa precisava garantir que eles ficassem íntegros e sem 
erros ao final da execução.
 • Redundância e inconsistência de dados: como os programas 
eram criados por diferentes programadores, era comum que 
muitos dados iguais ficassem redundantes e armazenados em 
locais diferentes, acarretando inconsistências.
Citamos apenas alguns problemas, mas existem outros de maior 
gravidade, como problemas de segurança, anomalia de acesso, falta 
de isolamento dos dados, entre outros. Todos esses aspectos aumen-
tavam significativamente a complexidade dos programas, fazendo com 
que a maioria de suas linhas e de sua lógica fossem construídas para os 
controles de acesso em vez de tratar do seu objetivo principal (SILBERS-
CHATZ; KORTH; SUDARSHAN, 2020).
O exemplo a seguir mostra parte de um programa antigo em uma lingua-
gem de programação (COBOL) que acessava diretamente esses arquivos.
Conceitos gerais de modelagem de banco de dados 13
DATA DIVISION.
FILE SECTION.
FD ARQUIVO001.
 RECORDING MODE IS F
 LABEL RECORD IS STANDARD
 BLOCK CONTAINS 0 RECORDS.
01 REG-CLIENTE PIC X(111).
WORKING-STORAGE SECTION.
01 REG-CLIENTE.
 05 REG-CPF PIC 9(011).
 05 REG-NOME PIC X(100).
01 REG-EOF PIC X(1).
PROCEDURE DIVISION.
 OPEN INPUT STUDENT.
 PERFORM UNTIL REG-EOF='Y'
 
 READ ARQUIVO001 INTO REG-CLIENTE
 AT END MOVE 'Y' TO REG-EOF
END-PERFORM.
CLOSE STUDENT.
Nesse exemplo, podemos verificar a descrição dos dados do ar-
quivo ARQUIVO001 por seus dados (REG-CLIENTE com REG-CPF e 
 REG-NOME), indicando que contém dados de clientes. Também consta 
no exemplo o comando de leitura desses dados (READ).
Assim, percebemos que, nesse formato antigo, o programa tinha 
a definição da estrutura dos arquivos (campos) e era encarregado de 
manipular diretamente o arquivo para leitura e/ou atualizações. Isso 
acarretava um problema, pois cada programa que manipulasse um 
determinado arquivo continha sua descrição. Quando a estrutura do 
arquivo era alterada, todos os programas necessitavam de atualização. 
Segundo Elmasri e Navathe (2013, p. 7), “a estrutura dos arquivos de 
14 Modelagem de banco de dados e SQL
dados está embutida nos programas de aplicação, de modo que quais-
quer mudanças em sua estrutura podem exigir alteração em todos os 
programas que acessam esse arquivo”.
Por conta dessas dificuldades e problemas, surgiram os bancos de 
dados.
1.1.1 Objetivos do banco de dados
Nessa estrutura, os dados são definidos e organizados independen-
tes do programa. Com isso, é possível realizar alterações nas definições 
dos dados sem gerar impacto aos programas; toda a interação do pro-
grama com os dados fica simplificada.
Podemos entender banco de dados como uma coleção de dados 
relacionados a um determinado assunto. Segundo Elmasri e Navathe 
(2013, p. 3), “um banco de dados é projetado, construído e populado 
com dados para uma finalidade específica”.
Poderíamos ter um banco de dados contendo Restaurantes, Pra-
tos, Clientes e Entregadores, por exemplo, que serviria para um 
aplicativo de pedido de comida. Em outro negócio, poderíamos ter um 
banco de dados, em uma universidade, com Alunos, Professores, 
Cursos, Disciplinas e Turmas. Poderíamos, ainda, representar os 
relacionamentos entre eles, como a matrícula do aluno de um curso 
em diversas disciplinas, os professores dessas disciplinas, as turmas 
e os locais das aulas, a emissão de um histórico escolar, entre outros, 
conforme a Figura 2.
Figura 2
Ilustração de um banco de dados de uma universidade
Matej Kastelic/Shutterstock
Sala de 
aula
Universidade
Alunos
Professores
Cursos
Disciplinas
Turmas
Fonte: Elaborada pelo autor.
https://www.shutterstock.com/pt/g/kasto80
Conceitos gerais de modelagem de banco de dados 15
Podemos dizer que um sistema de informações que utiliza um ban-
co de dados promove a independência dos dados, ou seja,eles estarão 
isolados e os programas não precisam saber a forma com que o dado é 
estruturado e armazenado (RAMAKRISHNAN; GEHRKE, 2008). Isso nos 
leva à ideia de estabilidade da estrutura e do armazenamento (DATE, 
2003), que traz o conceito de persistência, no sentido de que, uma vez 
que é armazenado no banco de dados, o dado está na sua forma defi-
nitiva, estável, não transitória; em outras palavras, dizemos que é um 
dado armazenado em um banco, ele está persistido.
Em resumo, poderíamos dizer que o uso de um banco de dados tem 
os seguintes objetivos, de acordo com Elmasri e Navathe (2013):
Organização dos dados 
Para que os dados fiquem 
armazenados no banco, eles 
precisam estar estruturados 
e organizados, fazendo com 
que o acesso e a manutenção 
sejam mais eficientes.
Acesso com linguagem 
padrão 
Com os dados em um banco 
de dados, é possível o uso 
de ferramentas próprias de 
acesso a esses dados. Em vez 
de se programar esse acesso, 
é usada uma linguagem 
específica para isso.
Restrições de 
integridade
Na maioria dos sistemas de 
informações, existem regras 
de negócio em que um 
determinado dado só pode 
receber certos valores. Esse 
controle do domínio de cada 
dado pode ser feito diretamente 
no banco de dados.
Múltiplas visões ao usuário 
É possível fornecer visões de 
parte dos dados a usuários 
específicos, para que sejam 
manipulados somente os 
dados relevantes para a 
parte do negócio que é 
responsável.
16 Modelagem de banco de dados e SQL
Com esses objetivos alcançados, podemos garantir maior estabili-
dade ao sistema, confiabilidade aos resultados que ele produz e per-
formance adequada ao usuário.
1.1.2 Histórico
A preocupação com armazenar dados eficientemente vem do início 
dos sistemas de informações, na década de 1960. Na época, Charles 
Bachman, da empresa General Electric, criou um sistema de arma-
zenamento para seus sistemas chamado Integrated Date Store (depó-
sito de dados integrado). Este foi padronizado pela Conference on 
Data Systems Languages (CODASYL) naquela época (RAMAKRISHNAN; 
GEHRKE, 2008).
No final da década 1960, grandes discos rígidos eram utilizados 
para o armazenamento de dados; foram desenvolvidos os modelos de 
dados de rede e hierárquicos que permitiram o uso de estruturas de 
dados, como listas e árvores nesses discos. Os programas tinham livre 
acesso a eles.
Nessa época, a empresa IBM desenvolveu o sistema chamado 
Information Management System (IMS), usado por anos nos sistemas de 
controle de passagens aéreas da empresa American Airlines.
Em 1970, Edgar Codd, também da IBM, propôs pela primeira vez 
uma estrutura chamada modelo de dados relacional, utilizada até hoje 
como estrutura padrão dos bancos de dados.
Em 1976, Peter Chen introduziu o conceito de modelo relacional, 
que foi a base para o armazenamento em bancos de dados até os dias 
de hoje.
Na década de 1980, os bancos de dados se solidificaram como es-
trutura padrão de armazenamento de dados, e a estrutura de arquivos 
praticamente caiu em desuso, ficando restrita somente a casos especí-
ficos. A IBM lança o DB2, um banco de dados para ambientes de grande 
porte mainframe (ELMASRI; NAVATHE, 2013).
Nessa década, então, surgiram softwares encarregados de fazer 
todo o trabalho de controle do banco de dados, chamados sistemas ge-
renciadores de banco de dados (SGBD), e a linguagem padrão de acesso 
aos dados ficou conhecida como Structured Query Language (linguagem 
estruturada de consulta – SQL). Praticamente todas as linguagens de 
Conceitos gerais de modelagem de banco de dados 17
programação criaram mecanismos para acessar quaisquer bancos de 
dados usando o SQL.
A partir dos anos de 1990, houve diversos avanços nessa área, tan-
to na parte de controle de armazenamento quanto da eficiência da 
consulta.
A partir do ano de 2000, dados semiestruturados passaram a ser 
mais utilizados, devido ao tráfego de informações pela internet. Sur-
giram padrões como eXtensible Markup Language (XML) e JavaScript 
Object Notation (JSON), específicos para essa arquitetura, e os bancos 
de dados passaram a dar suporte a esse tipo de estrutura. Nesse perío-
do surgiram, também, os bancos de dados do tipo open source (código 
aberto), em que bancos de dados, como MySql e PostgreSql, puderam 
ser utilizados gratuitamente, promovendo a autoadministração do 
banco por parte das empresas.
Os bancos de dados focaram a administração de grandes volumes 
de dados, devido à gigantesca quantidade de informações que transita 
pela internet. Conceitos como DateWarehouse e Data Mining surgiram 
não só para controlar o armazenamento, mas, principalmente, para 
produzir algoritmos de busca de informações úteis nessas grandes ba-
ses de dados.
A partir de 2010, cresce o interesse em armazenagem de dados “na 
nuvem 1 ”, em que se terceiriza a gestão dos dados em servidores ex-
ternos às empresas, com o objetivo de reduzir custos (SILBERSCHATZ; 
KORTH; SUDARSHAN, 2020).
Armazenamento em nuvem 
consiste no ato de armaze-
nar um ou mais arquivos em 
um HD fora da sua máquina, 
por meio da internet.
1
O vídeo História do SQL 
Server, publicado pelo ca-
nal Diego Nogare, conta 
a história de um famoso 
banco de dados, o SQL 
Server da Microsoft. 
Muito interessante!
Disponível em: https://www.
youtube.com/watch?v=7qK 
ToaOZBd8&feature=youtu.be. 
Acesso em: 9 mar. 2021.
Vídeo
1.2 Sistemas gerenciadores de 
banco de dados (SGBD) Vídeo
Os sistemas gerenciadores de banco de dados (SGBD) são softwares 
encarregados de administrar e controlar as operações sobre os ban-
cos de dados. Basicamente, eles permitem aos usuários as seguintes 
ações: criar o banco com as definições e a estruturação de todos os 
elementos; fazer atualizações nessa estrutura; e deixar o banco dispo-
nível para uso. São encarregados, ainda, de fazer todas as operações 
sobre os dados, como inclusão, alteração, exclusão e, principalmente, 
consultas aos dados, ponto forte dessa ferramenta.
https://www.youtube.com/watch?v=7qKToaOZBd8&feature=youtu.be.
https://www.youtube.com/watch?v=7qKToaOZBd8&feature=youtu.be.
https://www.youtube.com/watch?v=7qKToaOZBd8&feature=youtu.be.
18 Modelagem de banco de dados e SQL
1.2.1 Definição de SGBD
O SGBD é responsável por todo o acesso ao banco de dados (DATE, 
2003). A Figura 3 ilustra a interação entre os programas e os dados por 
meio de um SGBD.
Figura 3
Interação com o banco de dados
Usuários Programas SGBD
Programa 1
Programa n
Programas de 
controle e acesso
Banco de 
dados
Fonte: Elaborada pelo autor.
De acordo com Date (2003), os programas de controle e acesso ci-
tados na Figura 3 são capazes de aceitar as definições dos elementos 
dos bancos de dados com todas as suas características, a fim de criar 
o banco de dados. Os comandos responsáveis por essas definições 
são conhecidos como Date Definition Language (linguagem de defini-
ção de dados – DDL). Além disso, são capazes de realizar as consultas 
aos dados que os programas precisam realizar para disponibilizar aos 
usuários, bem como as atualizações (inclusão, alteração e exclusão). 
Os comandos responsáveis por essas operações são conhecidos como 
Date Manipulation Language (linguagem de manipulação de dados 
– DML).
1.2.2 Profissional responsável pelo SGBD
Uma variedade de pessoas está relacionada ao trabalho de criação 
e manutenção do SGBD. Não estamos falando dos programadores, que 
constroem o software SGBD, mas dos profissionais que administram 
o SGBD, deixando-o pronto para a utilização dos desenvolvedores de 
Conceitos gerais de modelagem de banco de dados 19
sistemas de informação que necessitam armazenar seus dados nessa 
estrutura.
Nessas empresas, o profissional responsável por toda a administra-
ção do banco, que serve as equipes de desenvolvimento de todos os 
sistemas de informação, é chamado Database Administrator (adminis-
trador do banco de dados – DBA).
Conforme Ramakrishnan e Gehrke (2008), as tarefas mais importan-
tes do DBA são as seguintes:
 • Projeto dosesquemas do banco de dados: o DBA deve intera-
gir com o analista de sistemas que está projetando o sistema de 
informação, a fim de compreender os dados e qual será o seu 
uso. Com isso, ele é capaz de decidir o melhor esquema físico de 
armazenamento para garantir acesso rápido e eficiente no mo-
mento de sua utilização.
 • Segurança e autodescrição: o DBA é responsável por assegurar 
que o acesso não autorizado não seja permitido. Com isso, ele 
pode criar visões de dados para cada tipo de usuário.
 • Disponibilidade e recuperação dos dados: o DBA deve tomar 
medidas para garantir que, no caso de falhas, os dados sejam 
preservados e continuem íntegros. É ele o responsável por orga-
nizar as rotinas de backup (cópias de segurança) e, em caso de 
falhas, das rotinas de restore (recuperação dos dados).
 • Sintonização do banco de dados: a performance de um sistema 
está ligada diretamente à eficiência no acesso aos dados. O DBA 
é encarregado de organizar o banco de modo a permitir o acesso 
rápido e adequado pelos usuários.
Esse profissional é de extrema importância em uma empresa, pois 
sua especialidade atenderá diversos sistemas que necessitam utilizar 
bancos de dados, evitando que essas tarefas sejam executadas des-
centralizadamente e por profissionais que atuam também em outras 
atividades.
1.2.3 Vantagens do uso de SGBD
Sem o uso de um banco de dados, os sistemas teriam que definir 
seus próprios arquivos e essas definições estariam espalhadas no cor-
po dos diversos programas. Esse modelo traz dificuldades nos mo-
20 Modelagem de banco de dados e SQL
mentos em que ocorrem alterações nos dados, já que é necessária 
a manutenção em todos os programas que contêm suas definições. 
Outro fator negativo é que todo o acesso aos dados dos arquivos fica 
também centralizado nos programas, aumentando sua complexidade.
A seguir, apresentaremos algumas vantagens do uso de um SGBD.
Administração dos dados dos sistemas
As principais vantagens em utilizarmos bancos de dados e um SGBD 
é a centralização e administração dos dados, pois os sistemas não ne-
cessitam manter arquivos próprios. Todos os dados e suas definições 
saem dos programas para ficarem centralizados no banco e todo o 
acesso é administrado pelo SGBD. O programa, então, necessita so-
mente fazer requisições dos dados, e o SGBD se encarrega de fazer a 
busca ou a atualização.
A Figura 4 ilustra a situação dos dados sendo armazenados em ar-
quivos sem SGBD, e a Figura 5, com o uso de um SGBD.
Figura 4
Interação entre programas e arquivos (sem SGBD)
Programa 1
Definição do arquivo 1
Definição do arquivo 2
Acesso ao arquivo 1
Acesso ao arquivo 2
Programa 2
Definição do arquivo 3
Acesso ao arquivo 3
Programa n
Definição do arquivo 2
Acesso ao arquivo 2
Arquivo 1
Dados do arquivo 1
Arquivo 2
Dados do arquivo 2
Arquivo 3
Dados do arquivo 3
Fonte: Elaborada pelo autor.
Nessa figura, podemos perceber que as definições e as rotinas de 
acesso se encontram nos programas do sistema.
Conceitos gerais de modelagem de banco de dados 21
Figura 5
Interação entre programas e dados (com SGBD)
Dados
SGBD
Programa 1
Acesso aos dados
.
.
.
Programa 2
Acesso aos dados
Programa n
Acesso aos dados
Fonte: Elaborada pelo autor.
Já nessa estrutura, com o SGBD, as definições dos dados não estão 
nos programas, elas fazem parte do banco de dados e todo o acesso é 
controlado por ele.
Controle de redundância
Em um sistema de arquivos tradicional, poderia acontecer que da-
dos iguais fossem armazenados em diversos arquivos, o que acarre-
taria problemas no uso desses dados. Em um banco de dados, com 
os dados armazenados em um único local, é possível ter um melhor 
controle para que não ocorra redundância de dados.
Restrição a acesso não autorizado
Em um banco de dados, é possível restringir o acesso a usuários que 
têm autorização para visualizar ou alterar determinados dados.
É comum haver diversos perfis de usuários, cada um com uma de-
terminada responsabilidade. Em uma empresa, por exemplo, um di-
retor poderia ter acesso a qualquer tipo de dado, já um funcionário 
operacional não poderia ter acesso a dados estratégicos ou sigilosos. É 
possível colocar todas essas restrições no banco de dados.
Controle de backup e restore
É comum que ocorram falhas em hardwares responsáveis pelo 
armazenamento dos dados e nos programas que os acessam. É im-
portante para um sistema que todos os seus dados estejam íntegros e 
22 Modelagem de banco de dados e SQL
sempre disponíveis. Para isso, um procedimento obrigatório é fazer có-
pias de segurança, comumente chamadas de backups. Essas cópias po-
dem ser feitas manualmente, o que não é aconselhável pelo trabalho 
dispendido e a incidência de falhas. Para isso, todos os SGBD fornecem 
o serviço, não só de backup, mas também de restore (recuperação dos 
dados). Todas as cópias de segurança (backup) e de recuperação dos 
dados (restore), em caso de problemas, são centralizadas, ficando a 
cargo de um software específico, que mantém o controle sobre o banco 
de dados.
Autodescrição
A autodescrição é um princípio importante dos bancos de dados, 
em que o banco não só guarda os dados dos sistemas, mas todas as 
informações do próprio banco, necessárias para o seu gerenciamento. 
As definições, os índices e as restrições são armazenadas em um catá-
logo no banco de dados (ELMASRI; NAVATHE, 2013), e a consulta a esse 
catálogo fornece todas as informações da estrutura do banco.
Voltando ao exemplo no início do capítulo, percebemos que as in-
formações sobre o arquivo que o programa COBOL acessaria estavam 
escritas diretamente no programa. No caso de um SGBD, essas infor-
mações e o mapa de acesso a elas ficam no catálogo do banco. Com 
isso, um SGBD pode garantir o isolamento dos dados e as definições 
dos programas que os manipulam.
Controle de concorrência
É possível, também, administrar o compartilhamento dos dados en-
tre diversos programas e até mesmo diversos sistemas de informação, 
garantindo a integridade dos dados. Esse princípio é de vital impor-
tância para garantir o acesso concorrente, principalmente nas atuali-
zações dos dados em que um determinado usuário pode estar, em um 
determinado instante, tentando atualizar o mesmo registro que outro 
programa.
O SGBD, nesse caso, encarrega-se de bloquear o registro para um 
programa até que ele termine a tarefa, fazendo com que os demais 
programas aguardem e usem o registro já com a nova atualização.
Suponhamos que o Usuário 1 deseja atualizar o endereço do 
cliente José e, no mesmo instante, o Usuário 2 deseja fazer a mesma 
atualização.
Conceitos gerais de modelagem de banco de dados 23
Vamos supor que o Usuário 1 recebeu a informação de que o 
endereço de José a ser atualizado seja Rua das Américas, n. 415, 
ap. 13, Bloco D, e o Usuário 2 está com a mesma informação, mas 
incompleta, tendo somente Rua das Américas, n. 415.
Caso não houvesse um mecanismo que garantisse a atualização 
completa de cada usuário, o Usuário 1 poderia efetivar a alteração 
para o endereço completo que digitou na tela, mas como o Usuário 
2 também digitou o endereço, mas incompleto – entretanto em um 
instante imediatamente posterior –, o endereço que estaria no banco 
de dados ficaria incompleto, e o Usuário 1 iria imaginar que estaria 
completo.
Utilização de índices
Quando um usuário necessita fazer uma consulta ao banco de da-
dos, essa requisição é analisada por um programa otimizador, que ve-
rifica na estrutura do banco qual é a forma mais eficiente de realizar a 
consulta. Essa eficiência dependerá de como os dados foram organiza-
dos na criação do banco. Se a consulta estava prevista no planejamento 
e estruturação do banco, alguns componentes foram criados na forma 
de “mapas”, para que o acesso seja mais rápido e direto. Caso essas 
definições não tenham sido feitas, o SGBD realiza o acesso, porém mais 
lentamente, já que todo o percurso dos dados será feito em tempo de 
execução da consulta.
Esse “mapa” citado é um conjuntode índices contendo os endereços 
dos dados. Quando um banco é criado prevendo a necessidade de uma 
determinada consulta, esses índices são gerados fazendo com que, no 
momento da efetiva execução da consulta dos dados, o SGBD primeiro 
percorra o índice e acesse o endereço do dado, para então efetivamen-
te recuperá-lo. Caso esse índice não exista, a busca é feita diretamente 
em todos os dados, o que causa um tempo maior de recuperação.
A Figura 6 mostra o exemplo de uma entidade chamada Aluno com 
algumas informações a seu respeito.
Na Figura 6a, teríamos os dados do aluno armazenados no banco 
de dados sem a existência de um índice de acesso. Note que, na busca 
por um determinado aluno, o banco necessita ler toda a tabela até en-
contrar o aluno desejado.
24 Modelagem de banco de dados e SQL
Figura 6a
Acesso aos dados sem a utilização de índice
CPF Nome
87644364762 Maria Cândida
93826154655 Joaquim José
37656198657 Rafaela Augusta
09864541324 Alcides Alcântara
Aluno
Encontre os dados do 
aluno com 
CPF “37656198657”
Fonte: Elaborada pelo autor
Já na Figura 6b, teríamos um índice contendo somente um dos atri-
butos do aluno, que foi escolhido por não haver repetição de valores 
e identificar de maneira única um determinado aluno. Nesse caso, o 
banco percorre primeiramente o índice e, em seguida, após descobrir 
o seu endereço na tabela, vai em busca dos demais dados.
Figura 6b
Acesso aos dados com a utilização de índice
CPF
87644364762
93826154655
37656198657
09864541324
Índice
CPF Nome
87644364762 Maria Cândida
93826154655 Joaquim José
37656198657 Rafaela Augusta
09864541324 Alcides Alcântara
Aluno
Encontre os dados do 
aluno com 
CPF “37656198657”
Fonte: Elaborada pelo autor.
Normalmente, os índices ficam armazenados em locais onde são 
acessados mais rapidamente do que os dados da tabela. Assim, apesar 
de realizar dois acessos, primeiro no índice e depois nos dados, essa 
busca tem um desempenho muito mais rápido.
Conceitos gerais de modelagem de banco de dados 25
Outras vantagens
São inúmeras as vantagens de se utilizar um SGBD. De acordo com 
Ramakrishnan e Gehrke (2008), as principais são:
Independência 
dos dados
Acesso 
eficiente Integridade
Facilidade na 
administração das 
definições
Segurança
Controle 
de acesso 
concorrente
Recuperação 
de falhas
Facilidade no 
desenvolvimento 
do sistema
Poderíamos dizer que as vantagens de utilizar SGBD são tantas a 
ponto de, atualmente, ser inviável produzir um sistema de informação 
sem o seu uso. A capacidade de gerenciamento dos dados é tão grande 
que o trabalho de se implementar as rotinas feitas por ele inviabilizaria 
os projetos de desenvolvimento de software.
O texto intitulado 10 
Interesting Facts About Da-
tabase Management Sys-
tems apresenta algumas 
curiosidades interessan-
tes sobre SGBD.
Disponível em: https://
aequortechnologies.wordpress.
com/2015/08/21/10-interesting-
facts-about-database-
management-systems/. Acesso em: 
9 mar. 2021.
Leitura
1.3 Conceitos gerais de modelagem de dados 
Vídeo Antes de iniciar o trabalho de modelagem dos dados propriamente 
dito, conheceremos os principais conceitos que envolvem o processo, 
necessários para todas as etapas, desde o levantamento desses dados 
até a implementação no banco de dados.
1.3.1 Níveis de abstração 
A tarefa de modelar o banco de dados deve ser feita considerando 
três níveis de abstração: conceitual, lógico e físico. Essa separação faci-
lita a estruturação dos dados, pois, no início da atividade, é comum não 
termos uma visão detalhada daquilo que devemos organizar, então os 
dados são levantados de um modo mais geral e, à medida que o enten-
26 Modelagem de banco de dados e SQL
dimento sobre a solução do problema vai aumentando, os elementos 
mais detalhados vão sendo inseridos em níveis mais específicos. Veja-
mos cada um deles.
1.3.1.1 Nível conceitual (externo)
O projeto do banco de dados de um sistema começa na fase de 
levantamento dos requisitos, quando é necessário entender quais 
dados serão armazenados e quais operações serão realizadas so-
bre eles, ou seja, devemos descobrir o que os usuários desejam 
com os dados. Para essa fase, a análise é informal e utiliza as téc-
nicas da etapa de levantamento dos requisitos (RAMAKRISHNAN; 
GEHRKE, 2008).
Normalmente, partimos de uma visão mais geral, procurando 
fazer uma análise sob a visão dos usuários que manipularão esses 
dados na forma de telas do sistema. No nível conceitual, os dados 
são analisados em conjunto com os usuários que irão usá-los no 
sistema a ser construído. Nesse nível, há a investigação de quais 
dados serão e qual será a sua finalidade, quais regras devem ser 
observadas e como serão organizados segundo a visão do usuário. 
Esse nível está diretamente ligado à fase de levantamento dos re-
quisitos, no ciclo de desenvolvimento do sistema.
Se estivermos desenvolvendo um sistema para uma universi-
dade, por exemplo, na fase de levantamento de requisitos, prova-
velmente teríamos as funcionalidades de cadastro de entidades, 
como Alunos, Professores, Cursos, Disciplinas, Tur-
mas, entre outros. Também teríamos de organizar telas para rea-
lizar a Matrícula dos alunos e outras funções necessárias para a 
administração da parte acadêmica da instituição. Nesse nível de 
abstração, iríamos investigar quais atributos seriam necessários 
para cada uma das entidades, quais são as relações entre eles, 
quais regras de negócio deveriam ser aplicadas e quais são os cri-
térios de aceitação de valores nesses atributos.
O Quadro 1 mostra uma lista de requisitos de uma escola de na-
tação. Esse artefato foi produzido na fase de levantamento de re-
quisitos do ciclo de desenvolvimento do sistema. Na última coluna 
do quadro, podemos perceber os dados que estarão relacionados 
Conceitos gerais de modelagem de banco de dados 27
com cada requisito. Essa abordagem já começa a dar uma ideia ao 
analista de quais dados deverão ser organizados segundo a teoria 
de modelagem de dados e que serão inseridos no banco de dados.
Quadro 1
Problema da escola de natação
Requisito Descrição Regras de negócio Atributos
R1 – Manter 
cadastro dos 
alunos
Permitir o cadastro completo 
dos alunos.
Permitir pesquisar, incluir, 
alterar e consultar.
Não permitir a exclusão de 
um aluno, somente marcar 
como inativo.
CPF, Nome, 
Endereço.
R2 – Manter 
cadastro dos 
professores
Permitir o cadastro completo 
dos professores.
Permitir pesquisar, incluir, 
alterar, excluir e consultar.
CPF, Nome, Data de 
Admissão, Modalidade 
(Natação ou Hidroginástica)
R3 – Manter 
cadastro das 
turmas
Permitir o cadastro completo 
das turmas, sua modalidade 
(natação ou hidroginástica), 
seus dias/horários e o professor 
responsável.
Não permitir o cadastro de 
duas turmas da mesma mo-
dalidade no mesmo horário.
Uma Turma deve ter um 
Nome (Turma 1, Turma 2 etc.), 
a modalidade (Natação ou 
Hidroginástica), os dias da 
semana, a Turma, o Horário, 
o Professor e o valor da 
Mensalidade.
R4 – Matricular 
alunos
Matricular os alunos nas turmas.
Pessoas com mais de 
80 anos só podem se 
matricular na modalida-
de Hidroginástica.
Número da Matrícula, 
Data, Turma e Aluno.
R5 – Registrar 
frequência
Registrar frequência no diário 
de classe de cada aula.
Aluno, Data, 
Frequência.
Fonte: Elaborado pelo autor.
É de extrema importância a abordagem conceitual no início do 
processo de desenvolvimento, pois uma lista de requisitos, como os 
elencados no Quadro 1, irá balizar a continuidade do trabalho de mo-
delagem dos dados.
1.3.1.2 Nível lógico
Nesse nível, os dados começam a ser organizados e preparados para 
serem armazenados em um banco de dados. Procura-se uma estrutura 
em que já se identificam entidades com seus atributos e, principalmen-
te, os relacionamentos entre elas. Nessa fase, já é possível listar com 
mais detalhes os dados levantados no nível anterior, porém fazemos 
uma descrição de alto nível, sem muitos detalhes, mas já registrandoas restrições que podem existir sobre os dados.
28 Modelagem de banco de dados e SQL
No exemplo da escola de natação, os dados poderiam ser escritos 
na seguinte forma:
Alunos (CPF, nome, data de nascimento, índice de 
rendimento)
Professores (CPF, nome, salário)
Turmas (nome, horário, professor)
Modalidade (nome, turmas)
Matrícula (número, aluno, turma)
No nível lógico, já é possível construir o modelo de dados, que é um 
diagrama no qual essas entidades são organizadas em retângulos, com 
ligações entre eles simbolizando o relacionamento que existe entre as 
entidades. Podemos notar na entidade Turmas que existe um atributo 
chamado Professor, que, por sua vez, trata-se de outra entidade, ou 
seja, está explícito que existe uma relação entre essas duas entidades. 
O mesmo ocorre com a entidade Matrícula, relacionada a Aluno e 
Turma.
Esse diagrama (modelo de dados) será visto em detalhes nas seções 
posteriores, por enquanto estamos somente mostrando os níveis de 
abstração para o tratamento dos dados.
1.3.1.3 Nível físico (interno)
Esse nível é o mais detalhado de todos e procura mostrar informações 
que irão balizar a criação da estrutura no banco de dados, tratando de ca-
racterísticas de entidades e atributos que determinarão o funcionamento 
do acesso aos dados. É de grande importância para a modelagem, pois 
interfere diretamente na performance do sistema e na forma com que os 
dados serão armazenados e recuperados. Especifica detalhes de armaze-
namento, e estruturas auxiliares são criadas com o objetivo de melhorar o 
desempenho do sistema e acelerar a recuperação dos dados.
Além disso, consiste em um refinamento dos esquemas gerados, 
a fim de ajustar entidades e atributos, alterar relacionamentos, criar 
entidades auxiliares, entre outros, com o foco em melhoria de perfor-
mance do sistema. Também faz uma previsão de carga do banco em re-
lação à quantidade de dados que serão inseridos, em seguida, há uma 
análise de distribuição dessa carga em diversos servidores, inclusive 
Conceitos gerais de modelagem de banco de dados 29
prevendo o caso de redundância controlada dos dados. Dizemos que 
nessa etapa é feito um processo de “sintonia”, comumente chamada de 
tuning no banco de dados.
Nesse nível, o SGBD a ser utilizado já foi definido e o esquema ge-
rado pode ser submetido a ele para ser cadastrado no seu catálogo 
(RAMAKRISHNAN; GEHRKE, 2008).
1.3.2 Modelo relacional
Existem diversas estruturas para armazenamento dos dados. Anti-
gamente, antes do surgimento dos bancos de dados, quando os dados 
ficavam em simples arquivos, técnicas que exploravam as caracterís-
ticas desses arquivos eram utilizadas. Duas delas eram chamadas de 
modelo em rede e modelo hierárquico.
Com o surgimento dos bancos de dados, a estrutura de armazena-
mento adotada foi o modelo relacional, por isso, em muitos casos, o 
banco é chamado de banco de dados relacional.
O conceito básico nesse modelo é o de relação. Por meio do nome 
da relação, é possível relacionar os registros que farão parte dela e 
cada registro descreve um elemento. Uma relação pode conter um ou 
mais campos. Como exemplo, considere a relação Alunos, a qual pode 
possuir os seguintes campos:
Alunos (CPF, Nome, Endereço, Carteira de Motorista, Estado Civil).
No Quadro 2, podemos relacionar alguns registros com informa-
ções dos alunos.
Quadro 2
Exemplo da relação Alunos
Aluno
CPF Nome Endereço Carteira de motorista Estado civil
87644364762 Maria Cândida Rua das Andorinhas, 12 6476376898 Solteira
93826154655 Joaquim José Rua dos Periquitos, 49 Casado
37656198657 Rafaela Augusta Rua das Pombas, 75 8746253655 Divorciada
09864541324 Alcides Alcântara Av. dos Pelicanos, 21 2387578288 Solteiro
Fonte: Elaborado pelo autor.
30 Modelagem de banco de dados e SQL
Cada registro da relação descreve completamente um determinado 
aluno, por meio do conteúdo dos seus campos. Dizemos que a relação 
é um modelo para descrever um aluno.
Como veremos em detalhes, existem mais informações que po-
dem ser colocadas na relação para uma descrição mais completa dos 
elementos, como os tipos de cada um dos campos, o domínio de um 
campo (conjunto de valores que ele pode assumir), as regras que po-
dem ser adotadas para eles e, principalmente, as interações entre as 
diversas relações de um sistema. Pode acontecer, também, em alguns 
casos, de alguns campos de uma relação não possuírem nenhum valor 
em um determinado momento; esse conteúdo, nesse caso, é chamado 
de valor nulo. Na relação Alunos do Quadro 2, por exemplo, o aluno 
Joaquim José não possui carteira de motorista, então o valor desse 
campo, para esse aluno, seria nulo.
1.3.3 Tabelas, linhas, atributos e domínio 
Em um banco de dados relacional, as relações recebem o nome de 
tabela, devido ao formato que são representadas, em forma de tabelas 
com linhas e colunas. Esse termo é amplamente utilizado na modela-
gem e no manuseio do banco e, com isso, o termo relação não será 
mais utilizado no texto.
Uma tabela é composta de linhas e colunas. As linhas correspon-
derão aos registros da entidade, e as colunas, aos seus atributos. Na 
nomenclatura de banco de dados, temos:
Tabela
Sinônimo de relação ou entidade, 
representa um conjunto de elementos 
do mundo real distinguíveis uns dos 
outros, cujos dados necessitam ser 
armazenados no banco de dados. 
Cada linha da tabela representa um 
determinado elemento. Por exemplo, 
em uma escola de natação, a relação 
Alunos é um exemplo de tabela.
Linha
Sinônimo de registro ou tupla, 
corresponde a todos os dados 
de um determinado elemento 
da tabela. Todas as informações 
do aluno Joaquim José (CPF, 
nome, endereço, carteira de 
motorista) são um exemplo de 
linha.
Atributo
Sinônimo de campo, 
propriedade ou 
coluna, corresponde 
a uma determinada 
característica do 
elemento da tabela. O 
nome de um aluno é um 
exemplo de atributo.
Conceitos gerais de modelagem de banco de dados 31
Domínio
Corresponde a todos os 
valores possíveis para um 
determinado atributo. Por 
exemplo, o atributo Estado 
Civil, na tabela de alunos, 
tem um conjunto limitado 
de valores que podem ser 
atribuídos a ele (solteiro, 
casado, divorciado). Dizemos 
que essa lista de valores é o 
domínio do atributo.
Chave
É um conjunto de um ou mais atributos 
escolhidos para representar os elementos da 
tabela. A chave identifica univocamente um 
elemento. Pode haver mais de um atributo 
(ou conjunto de atributos) com essa condição; 
nesse caso, teremos várias chaves, chamadas 
candidatas. Ao escolhermos uma delas, 
passamos a chamá-la de chave primária da 
tabela. No exemplo da tabela Aluno, o atributo 
CPF poderia ser a chave primária, já que não 
existe um CPF igual a outro.
Os atributos podem ser de vários tipos. Vejamos:
 • Simples ou compostos:
 • Simples: quando um atributo não pode ser dividido em 
outros. Por exemplo, o cpf do aluno.
 • Composto: quando pode ser dividido. Por exemplo, o Nome 
do aluno, que pode ser dividido em Primeiro Nome, Nome 
Intermediário e Sobrenome. Também o Endereço, que 
pode ser dividido em Rua, Número, Cidade, Estado e CEP.
 • Monovalorado ou multivalorado:
 • Monovalorado: quando um atributo só pode assumir um único 
valor. Por exemplo, o cpf, Nome e Estado Civil do aluno.
 • Multivalorado: quando um atributo pode ter vários valores. 
Por exemplo, o Número do Telefone do aluno, já que ele 
pode ter vários telefones; o atributo Endereço, já que ele 
pode ter o endereço residencial e o comercial.
 • Nulo: quando não se deseja informar nenhum valor para o atri-
buto. Por exemplo, o atributo Carteira de Motorista pode 
ficar com o valor nulo para o aluno que não possui a carteira.
 • Derivado: quando o atributo pode ser obtido por meio de outro 
atributo. Por exemplo, o atributo Idade do aluno, que pode ser 
obtido pela data de nascimento; o atributo Tempo na escola, 
que pode ser obtido pela Data da matrícula.
32 Modelagem de banco de dados e SQL
A Figura 7 ilustra os conceitos abordados.
Figura7
Exemplo da relação Alunos com os conceitos
Atributos
CPF Nome Endereço Telefone Carteira de motorista
Estado
civil
87644364762 Maria Cândida Rua das Andorinhas, 12 988746655 6476376898 Solteira
93826154655 Joaquim José Rua dos Periquitos, 49 876563544 Casado
37656198657 Rafaela Augusta Rua das Pombas, 75
788765546
876764666
8746253655 Divorciada
09864541324 Alcides Alcântara Av. dos Pelicanos, 21 2387578288 Solteiro
Aluno
Atributos com 
domínio
Tabela
Linhas
Atributo 
monovalorado
Valor nulo
Atributo 
multivalorado
 Atributo 
composto
Chave 
primária Atributo 
simples
Fonte: Elaborada pelo autor.
Tais definições serão de grande importância no processo de mode-
lagem, pois as definições subsequentes irão utilizar esses conceitos em 
suas explicações e detalhamentos.
1.3.4 Relacionamentos
Os relacionamentos têm o objetivo de fazer as ligações entre ele-
mentos das tabelas.
Vamos considerar o exemplo da escola de natação, em que, além 
dos dados dos alunos, precisamos armazenar no banco de dados as 
informações de professores, turmas, modalidades, matrícula e diário 
de classe. Elas seriam as tabelas do banco.
Podemos perceber que, para representar o negócio de uma escola 
de natação, algumas tabelas deverão, obrigatoriamente, fazer referên-
cia a outras, para que sua informação fique completa.
Os atributos de um professor, por exemplo, seriam seu cpf, Nome 
e Data de admissão. Esses são seus atributos básicos, porém preci-
Conceitos gerais de modelagem de banco de dados 33
samos saber quais modalidades (natação e/ou hidroginástica) o professor 
pode atuar. As modalidades, por sua vez, também estarão em uma ta-
bela. Então, dizemos que existe um relacionamento entre as tabelas 
Professor e Modalidade.
Se representarmos uma tabela em um retângulo, a linha que as se-
para será a representação do relacionamento entre elas.
A imagem a seguir representa o relacionamento entre as tabelas Pro-
fessor e Modalidade. Nessa representação, foi inserido apenas o nome 
da tabela, sem os seus atributos.
Professor Modalidade
Da mesma forma, se analisarmos a tabela Turmas, poderemos per-
ceber que uma Turma tem um Professor como responsável e tam-
bém tem a informação de a qual Modalidade pertence aquela turma. 
A imagem a seguir mostra esses relacionamentos.
Professor Modalidade
Turma
Os relacionamentos nos fornecem algumas respostas a questiona-
mentos que podemos fazer sobre os dados, por exemplo:
 • Em quais modalidades um professor atua?
 • Quais professores atuam na modalidade natação aqui na escola?
 • Quantas turmas de hidroginástica existem na escola?
 • Quais turmas pertencem a um determinado professor?
Alguns relacionamentos podem ser considerados tabelas. Veja o 
relacionamento que existe entre as tabelas Aluno e Turma. Um alu-
no pertence a uma determinada turma que, por sua vez, tem diversos 
alunos. Esse relacionamento poderia bem ser uma tabela de Matrí-
culas, já que uma matrícula deve, além de guardar suas informações 
próprias, como “número da matrícula” e “data da matrícula”, guardar 
também qual é o aluno matriculado e em qual turma.
34 Modelagem de banco de dados e SQL
Essa representação está no esquema a seguir.
Aluno Turma
Matrícula
Os relacionamentos e todos os seus detalhes serão vistos no mode-
lo lógico de dados.
Finalmente, o conjunto de todas as tabelas e seus relacionamentos 
é chamado de modelo de dados e pode ser feito em diversos níveis, de-
pendendo do momento do ciclo de desenvolvimento do sistema.
CONSIDERAÇÕES FINAIS 
Apresentamos, neste capítulo, todas as bases da estrutura conhecida 
como banco de dados, assim como seus principais conceitos e vantagens 
de uso. Além disso, conhecemos os sistemas gerenciadores de banco de 
dados (SGBD), um importante software utilizado em grande escala nos 
sistemas de informações. Sem ele, atualmente, seria impossível processar 
os dados dos sistemas, devido à grande quantidade de informações ma-
nipuladas pelos sistemas.
Conhecemos os conceitos iniciais necessários para a modelagem dos 
dados e a posterior utilização dos bancos de dados; vimos, também, as 
principais tarefas dos SGBD e como elas são importantes para manter a 
integridade dos dados e o sucesso dos sistemas de informações.
ATIVIDADES
1. O que são os sistemas gerenciadores de banco de dados (SGBD)? 
Comente.
2. Quais são as vantagens da utilização de um banco de dados? Cite cinco.
3. Conceitue tabela, linha e atributo.
Como curiosidade, assista 
ao vídeo O que é BANCO 
DE DADOS e porque IN-
TERESSA APRENDER isso?, 
publicado pelo canal 
DBA PRO. Ele mostra, de 
uma maneira dinâmica e 
interativa, os principais 
conceitos de bancos de 
dados. Vale conferir!
Disponível em: https://
www.youtube.com/
watch?v=XfO3TRvESBo. Acesso em: 
9 mar. 2021.
Vídeo
Vídeo
Conceitos gerais de modelagem de banco de dados 35
REFERÊNCIAS 
AMADEU, C. Banco de dados. São Paulo: Pearson Education do Brasil, 2014.
DATE, C. J. Introdução a sistemas de banco de dados. 8. ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, R.; NAVATHE, S. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Education 
do Brasil, 2013.
FACEBOOK. Apaixonados por aviões!! Facebook: Lourdes Cavalcante. Disponível em: https://
www.facebook.com/groups/401297713387007. Acesso em: 9 mar. 2021.
LAUDON, K.; LAUDON, J. Sistemas de informação gerenciais. 11. ed. São Paulo: Pearson 
Education do Brasil, 2015.
MEDEIROS, L. Banco de dados: princípios e prática. Curitiba: Intersaberes, 2013.
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de gerenciamento de banco de dados. 3. ed. São 
Paulo: McGraw-Hill, 2008.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de 
Janeiro: LTC, 2020.
36 Modelagem de banco de dados e SQL
2
Modelo relacional
O modelo relacional tem esse nome vindo das teorias mate-
máticas com os conceitos de relações e funções, haja vista que os 
dados serão armazenados em uma estrutura de relações. A partir 
dessa base, começaremos a construir os modelos conceitual e ló-
gico, necessários para organizar os dados que serão colocados em 
um banco de dados.
Após a tarefa de levantamento de requisitos, na qual todos 
os dados necessários para a solução do problema foram levan-
tados, partiremos para a construção do modelo conceitual de 
dados, com a finalidade de analisar os requisitos e os dados re-
lacionados a eles, bem como as regras de negócio que devem 
ser aplicadas. Assim, teremos uma primeira versão dos dados 
que devemos modelar.
Na sequência, os dados serão organizados em tabelas, para 
a aplicação de uma técnica chamada normalização, que procu-
ra organizar essas tabelas a fim de evitar anomalias na utiliza-
ção desses dados.
Por fim, após a aplicação das técnicas e a colocação dos 
relacionamentos entre as tabelas, teremos o modelo lógico de 
dados, cujo desenvolvimento é o objetivo deste capítulo.
2.1 Modelo conceitual 
Vídeo O processo de modelagem dos dados envolve diversas etapas. A 
primeira delas é a fase de levantamento dos requisitos, quando deve-
mos ter contato com o problema a ser resolvido e realizar as tarefas de 
análise do sistema. Nessa etapa, além de conhecer o problema que o 
usuário deseja que seja resolvido, tomamos conhecimento dos dados 
envolvidos, tanto no problema como na solução.
Modelo relacional 37
O modelo conceitual, então, nada mais é do que entender os 
conceitos relacionados ao problema e representar suas relações e 
características.
Para entendermos todas as etapas da modelagem, assim como o 
local em que se encontra o modelo conceitual, vejamos a Figura 1, que 
ilustra todas as etapas: desde o contato com o problema, passando 
pela fase de levantamento dos requisitos e até os diversos modelos de 
dados que serão criados.
Figura 1
Etapas da modelagem de dados
Levantamento
de requisitos
Minimundo
Modelo
conceitual
Modelo
lógico
Modelo
físico
Fonte: Elaborada pelo autor.
Na primeira etapa de levantamento de requisitos, os projetistas de 
banco de dados entrevistamos usuários, para entenderem o minimun-
do e, principalmente, os dados envolvidos (ELMASRI; NAVATHE, 2013).
O termo minimundo representa o contexto do problema a ser resolvido. 
Em quase todas as organizações, existem diversos assuntos envolvidos na 
administração do seu negócio. Por exemplo, no caso do negócio de uma 
loja que vende produtos, poderíamos ter diversos contextos, como admi-
nistração dos funcionários, contas a pagar, contas a receber, contabilidade, 
controle das vendas da loja, logística de entrega, entre outros. 
Seria possível dizer que todo o negócio seria o mundo dessa empresa. 
No momento que um desses contextos é escolhido para ser informatiza-
do, por meio da produção de um sistema de informação, podemos chamar 
esse contexto de minimundo. Esse termo é meramente conceitual e outros 
semelhantes poderiam ser usados para representar a mesma ideia. Essa 
descrição de minimundo foi sugerida por Elsmari (2013). O que realmente 
importará é a delimitação correta do contexto em que o sistema deve focar.
38 Modelagem de banco de dados e SQL
Partindo desse contexto, e com os requisitos definidos, o primeiro 
modelo a ser produzido é o modelo conceitual dos dados.
2.1.1 Transformação do minimundo em um modelo 
conceitual
Primeiramente, devemos analisar o minimundo e a lista de requisi-
tos produzida. Vários conceitos estão descritos, bem como suas regras 
de negócio, e, principalmente, os dados que devem ser organizados.
É importante não esquecer que a fase de modelagem dos dados vem 
depois de todo o trabalho de análise do sistema, ou seja, teremos à dis-
posição diversos diagramas produzidos, para analisar e retirar os dados.
Para entender melhor a confecção do modelo conceitual, vamos 
usar como exemplo uma escola de natação. Nesse negócio, existem 
diversos contextos, tais como as aulas que os alunos terão, a adminis-
tração dos professores e demais funcionários da escola, a manutenção 
das piscinas, os materiais que devem ser usados para a limpeza, o con-
trole da parte financeira, a contabilidade, entre outros. Desse modo, 
vamos supor que o dono da escola solicitou a informatização de todo 
o contexto das aulas: o cadastro dos alunos; as matrículas; e o controle 
de frequência. Nesse “minimundo”, poderíamos analisar como seria o 
modelo conceitual de dados.
A descrição do minimundo seria a seguinte:
 • Os alunos devem ser cadastrados no sistema para que possam 
se matricular.
 • O cadastro de todos os professores da escola e quais modalida-
des cada um está apto a trabalhar também deve ser feito, para 
que eles sejam devidamente alocados nas turmas segundo a 
especialidade.
 • As turmas já devem estar previamente definidas e cadastradas 
com seus dias/horários e com o professor definido.
 • Todas as opções de modalidade, turmas, dias/horários e profes-
sores disponíveis, para que o aluno tenha a possibilidade de vi-
sualização, devem constar no processo de matrícula.
 • O professor, durante as aulas, deve ter condições de controlar a 
frequência dos alunos.
O processo de levantamento dos requisitos desse problema deve 
ter produzido uma lista de requisitos, como mostra o Quadro 1.
Modelo relacional 39
Quadro 1
Lista de requisitos: escola de natação
Requisito Descrição Regras de negócio Atributos
R1 – Manter cadastro 
dos alunos
Permitir o cadastro com-
pleto dos alunos.
Permitir pesquisar, incluir, 
alterar e consultar.
Não permitir a exclusão de 
um aluno, somente marcar 
como inativo.
cpf, Nome, Telefone, 
Endereço.
R2 – Manter cadastro 
dos professores
Permitir o cadastro com-
pleto dos professores.
Permitir pesquisar, incluir, 
alterar, excluir e consultar.
cpf, Nome, Data de 
Admissão, Modalidade 
(Natação ou Hidroginástica).
R3 – Manter cadastro 
das turmas
Permitir o cadastro 
completo das turmas, 
sua modalidade (natação 
ou hidroginástica), seus 
dias/horários e qual é o 
professor responsável.
Não permitir o cadastro 
de duas turmas da mesma 
modalidade no mesmo 
horário.
Uma turma deve ter um 
Nome (Turma 1, Turma 2 etc.), 
Modalidade (Natação ou 
Hidroginástica), os dias da 
semana, a Turma, os Horários, 
o Professor e o valor da 
Mensalidade.
R4 – Matricular 
alunos
Matricular os alunos nas 
turmas.
Pessoas com mais de 
80 anos só podem se 
matricular na modalidade 
hidroginástica.
Número da Matrícula, 
Data, Turma e Aluno.
R5 – Registrar 
frequência
Registrar frequência no 
diário de classe de cada 
aula.
Aluno, Data, Frequência.
Fonte: Elaborado pelo autor.
Podemos perceber nesse quadro um maior detalhamento das fun-
ções do sistema. Em cada requisito, temos uma ideia de quais serão os 
dados envolvidos (última coluna do quadro). Devemos, agora, identifi-
car as entidades e seus atributos. Para isso, por exemplo, pegamos o 
primeiro requisito:
 • R1 – Manter cadastro dos alunos
Podemos fazer uma relação dos atributos necessários para o aluno, 
conforme consta no Quadro 1.
Aluno (cpf, nome, telefone, endereço)
 • R2 – Manter cadastro dos professores
Professor (cpf, nome, data de admissão, modalidades)
Regras de negócio:
40 Modelagem de banco de dados e SQL
 • Na escola de natação as modalidades são natação ou 
hidroginástica.
 • Um professor pode atuar nessas duas modalidades.
 • R3 – Manter cadastro das turmas
Turma (código, nome, modalidade, descrição do dia e 
horário, professor,valor da mensalidade)
Regra de negócio: o atributo descrição do dia e horário deve 
ser preenchido seguindo o padrão destes exemplos:
 • Seg/Ter/Sex, das 9h às 10h.
 • Ter/Qui, das 7h às 8h.
 • R4 – Matricular alunos
Matrícula (número, data, turma, aluno)
 • R5 – Registrar frequência
Frequência (matrícula, data, frequentou)
Assim, após essa análise, poderíamos ter a relação de entidades do 
sistema.
Aluno (cpf, nome, telefone, endereço).
Professor (cpf, nome, data de admissão, modalidade).
Turma (código, nome, modalidade, descrição do dia e 
horário, professor, valor da mensalidade).
Matrícula (número, data, turma, aluno).
Frequência (matrícula, data, frequentou).
De posse dessas entidades identificadas com seus atributos, parti-
mos para um detalhamento de seus componentes e os relacionamen-
tos entre elas, por meio do modelo lógico e físico.
2.2 Modelo lógico 
Vídeo Antes de partirmos para a transformação do modelo conceitual em 
modelo lógico, precisamos entender a estrutura de armazenamento 
que usaremos, pois os dados, após organizados, serão colocados em 
um banco de dados relacional.
O vídeo História do SQL 
Server, publicado pelo 
canal Diego Nogare, 
conta a história de 
um famoso banco de 
dados: o SQL Server da 
Microsoft.
Disponível em: https://
www.youtube.com/
watch?v=7qKToaOZBd8 
&feature=youtu.be. Acesso em: 
31 mar. 2021.
Vídeo
Modelo relacional 41
2.2.1 Banco de dados relacional
Segundo Silberschatz, Korth e Sudarshan (2020, p. 22), “um banco de 
dados relacional consiste em uma coleção de tabelas, cada qual receben-
do um nome exclusivo”. O termo relação é usado para se referir a uma 
tabela, com seus atributos e suas linhas (também chamados de colunas e 
tuplas).
O uso de banco de dados relacional é a principal forma de armaze-
namento utilizada em bancos de dados. É um modelo simples e de fácil 
entendimento pelos programadores, se comparado aos modelos em 
rede e hierárquico (mais antigos). Como exemplo, imagine uma univer-
sidade e a relação de cursos que ela oferece.
Quadro 2
Relação de cursos de uma universidade
Código Curso Coordenador
TADS Tecnologia em Análise e Desenvolvimento de Sistemas Joaquim José
BAM Bacharelado em Matemática João da Silva
DIR Bacharelado em Direito Amanda Rodrigues
Fonte: Elaborado pelo autor.
As tabelas podem estar relacionadas para que informações de uma 
tabela sejam detalhadas em outras tabelas. Nesse exemplo, imagine a 
relação de alunos da universidade com a informação de seu respectivo 
curso, constante no Quadro 3.
Quadro 3
Relação de alunos
Código Nome Código do curso
001 Flávio Gonçalves DIR
002 Maria José BAM
003 Gabriel HenriqueTADS
Fonte: Elaborado pelo autor.
Dessa forma, ao levantarmos todas as tabelas necessárias para um 
determinado sistema, com todas as relações entre elas, teremos um 
banco de dados relacional.
42 Modelagem de banco de dados e SQL
Com o modelo conceitual visto na seção anterior, temos que come-
çar a organizar as entidades em forma de tabelas, a fim de prepará-las 
para que sejam colocadas em um banco de dados relacional.
O modelo lógico de dados procura organizar as entidades em tabelas 
e seus atributos, além de aplicar técnicas de organização desses dados, 
com o intuito de evitar anomalias nos processos de inclusão, alteração e 
exclusão de dados que poderiam acarretar falta de integridade dos dados. 
Nesse nível também são identificados os atributos que irão compor a chave 
da tabela, bem como os relacionamentos que devem existir entre elas.
2.2.2 Organização em tabelas
Devemos organizar, agora, as entidades em forma de tabelas e, em 
seguida, aplicar uma técnica chamada normalização.
As tabelas serão representadas por retângulos, nos quais, no topo, co-
locamos o nome da tabela e, na sequência, a relação dos seus atributos. 
Para este nível, o nome dos atributos deve ser abreviado e não conter 
espaços ou traços entre as palavras. Por padrão da maioria dos bancos de 
dados, esses nomes de atributos devem ser escritos com letras minúscu-
las. Nesse diagrama, também, as palavras não são acentuadas, já que no 
banco de dados e nas linguagens de programação isso não é permitido.
A Figura 2 mostra as entidades do problema da escola de natação 
organizadas em forma de tabelas. Tais tabelas foram extraídas do mo-
delo conceitual.
aluno
cpf
nome
telefone
endereco
professor
cpf
nome
data_
admissao
modalidade
frequencia
matricula
data
frequentou
matricula
numero
data
turma
aluno
turma
codigo
nome
modalidade
descricao_dia_horario
professor
Figura 2
Tabelas do problema da escola de natação
Fonte: Elaborada pelo autor.
Modelo relacional 43
A seguir, a fim de continuarmos a organização das tabelas e che-
garmos ao modelo lógico, analisaremos o processo de normalização 
das tabelas. Para esse processo, elas devem ser identificadas com suas 
chaves primárias.
Como vimos, uma chave primária é composta por um ou mais atri-
butos, que identificam de modo único um determinado elemento. Por 
exemplo, na tabela aluno, podemos perceber que não existem alunos 
com o mesmo CPF, ou seja, o CPF pode ser utilizado para identificar um 
aluno, então, o atributo cpf será a chave primária dessa tabela.
Para simbolizar a chave primária, usaremos um sublinhado no 
nome do atributo, como apresentado na Figura 2.
2.2.3 Normalização
Normalização é um processo de análise das tabelas e de aplicação 
das técnicas. Seu objetivo é organizar essas tabelas antes de seu arma-
zenamento no banco de dados. O armazenamento incorreto das tabe-
las não normalizadas leva a um problema de anomalias de inserção, 
exclusão e atualização (ELMASRI; NAVATHE, 2013).
Como exemplo de anomalia, podemos analisar a tabela professor. 
Como nela existe o atributo modalidade, só é possível incluir uma 
nova modalidade quando tivermos um professor para ela. E se quiser-
mos somente cadastrar uma modalidade? Nesse modelo, isso não se-
ria possível, por isso é uma anomalia. Da mesma forma, se excluirmos 
o professor de uma determinada modalidade, perdemos a informação 
dessa modalidade. Além disso, se quisermos alterar o nome de uma 
determinada modalidade, temos de fazer essa alteração em todos os 
professores dessa modalidade.
Basicamente, o processo de normalização avalia cada tabela e apli-
ca os critérios das formas normais, decompondo em uma ou mais ta-
belas, conforme a necessidade, gerando novas tabelas que sigam os 
critérios das formas (ELMASRI; NAVATHE, 2013).
A seguir, iremos conhecer e aplicar as três formas normais que são 
aplicadas nas tabelas.
44 Modelagem de banco de dados e SQL
2.3 Primeira forma normal (1FN) 
Vídeo Com o objetivo de entender o processo de normalização, na 1FN e 
nas demais, faremos a análise e a aplicação das regras em duas etapas. 
Em primeiro lugar, apresentaremos a regra da 1FN e, em seguida, a 
forma de aplicá-la.
2.3.1 Regra da 1FN
Segundo Date (2003), uma tabela está na 1FN se, e somente se, em 
todo valor válido dessa tabela cada linha contém exatamente um valor 
para cada atributo.
Em termos práticos, uma tabela está na 1FN se:
 • contém somente atributos simples;
 • não contém atributos totalizadores (que podem ser obtidos por 
operações sobre outros atributos);
 • não contém atributos repetidos;
 • todas as linhas são diferentes em relação à chave primária.
Para exemplificar a 1FN, temos a tabela aluno e, para melhor en-
tendimento, colocamos algumas linhas na tabela.
Tabela aluno
cpf nome telefone endereco
12345678901 Joaquim José 41-987463666
Rua das Carmelitas, 2213, 
sobrado 1, Esmeraldas, 
800000, Curitiba/PR
54355656566 Maria Andrade 41-987455565
Rua XV de Novembro, 415 
ap. 10, 80000, Curitiba/PR
Ao analisar o atributo endereço nessa tabela, podemos perceber 
que se trata de um atributo composto, ou seja, pode ser subdividido 
em vários outros, pois um endereço é a composição do nome da rua, 
número, complemento, bairro, cep, cidade e estado. Então, no modelo 
lógico, devemos decompor esse atributo.
Como 1FN exige que todos os atributos sejam simples, devemos de-
compor em diversos atributos simples, e a tabela ficaria desta forma:
Modelo relacional 45
aluno
cpf
nome
telefone
rua
numero
complemento
cep
cidade
estado
O exemplo da tabela ficaria do seguinte modo:
Tabela aluno
cpf nome telefone rua numero complemento cep cidade estado
12345678901
Joaquim 
José
41-987463666
Rua das 
Carme-
litas
2213 Sobrado 1 800000 Curitiba PR
54355656566
Maria 
Andra-
de
41-987455565
Rua 
XV de 
Novem-
bro
415 Ap. 10 800000 Curitiba PR
Outro atributo que poderia ferir a 1FN seria o telefone nessa mesma 
tabela. Caso se queira armazenar mais de um telefone do aluno – o que 
pode ocorrer –, não se poderia incluir atributos como telefone1, tele-
fone 2..., telefone n. Isso iria ferir o terceiro item da 1FN: não contém 
atributos repetitivos. Nesse caso, o que poderia ser feito é colocar os atri-
butos telefone_celular, telefone_comercial etc.
Finalmente, a verificação mais importante para 1FN é a última regra: 
todas as linhas são diferentes em relação à chave primária.
Se analisarmos agora a tabela professor segundo a regra de 
negócio do sistema, que diz “um professor pode atuar em várias 
modalidades”, o atributo modalidades presente na tabela faz com que 
ocorram duas linhas iguais em relação à chave primária, caso um pro-
fessor atue em mais de uma modalidade.
Veja o exemplo de um professor com cpf 98615457689, que é profes-
sor de natação e também de hidroginástica. Para colocarmos essas duas 
informações na linha desse professor, teríamos um atributo com mais de 
46 Modelagem de banco de dados e SQL
um valor, o que não é permitido na 1FN. Seria necessário repetir a linha 
desse professor para colocarmos a segunda modalidade em que ele atua.
professor
cpf
nome
data_admissao
modalidades
Tabela professor
cpf nome data_admissao modalidade
98615457689 Augusto Araújo 19/03/2010 Natação
98615457689 Augusto Araújo 19/03/2010 Hidroginástica
Perceba que, com relação ao cpf (chave primária), temos duas li-
nhas com o mesmo número, o que não é permitido em 1FN. Isso foi ne-
cessário para incluir mais uma linha informando que o professor atua 
também na modalidade hidroginástica.
Há outro ponto causando problema: da forma que está, não existe 
possibilidade de realizar o cadastro das modalidades até que se tenha 
um professor cadastrado. Vale ressaltar que, no momento que todos os 
professores forem excluídos, todas as modalidades também serão.
2.3.2 Como aplicar a 1FN
Para eliminar o problema e deixar a tabela na 1FN, devemos retirar o 
atributo modalidade dessa tabela (já que é ele quem causa a repetição 
da chave) e criar uma tabela na qual achave será composta do cpf e de 
um novo atributo chamado código da modalidade, com sua descrição.
As tabelas, então, ficariam do seguinte modo:
professor
cpf
nome
data_admissao
modalidade_professor
professor_cpf
modalidade_codigo
descricao_modalidade
Modelo relacional 47
E os dados, desta forma:
Tabela professor
cpf nome data_admissao
98615457689 Augusto Araújo 19/03/2010
Tabela modalidade_professor
professor_cpf modalidade_codigo descricao_modalidade
98615457689 1 Natação
98615457689 2 Hidroginástica
Perceba que na nova tabela, modalidade_professor, não há re-
petição com relação à chave, já que ela é composta dos dois atributos 
(sublinhados): professor_cpf e modalidade_codigo.
Analisando as demais tabelas, não existem mais atributos ferindo a 1FN.
Figura 3
Tabelas do problema da escola de natação na 1FN
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade
estado
professor
cpf
nome
data_admissao
matricula
numero
data
turma
aluno
modalidade_professor
professor_cpf
modalidade_codigo
descricao_modalidade
turma
codigo
nome
modalidade
descricao_dia_horario
professor
frequencia
matricula
data
frequentou
Fonte: Elaborada pelo autor.
48 Modelagem de banco de dados e SQL
Então, podemos dizer que o modelo lógico na primeira forma nor-
mal é esse. Agora, continuamos no processo de normalização aplican-
do as demais formas normais.
2.4 Segunda forma normal (2FN) 
Vídeo Primeiramente, apresentaremos a regra da 2FN e, em seguida, a 
forma de aplicá-la.
2.4.1 Regra da 2FN
Conforme Date (2003), uma tabela está na 2FN se estiver na 1FN e 
se todo atributo não chave for irredutivelmente dependente da tota-
lidade chave primária. Assim, analisamos cada um dos atributos que 
não pertencem à chave primária e verificamos se esse atributo é uma 
informação de todos os atributos da chave.
Como consequência, devemos analisar somente as tabelas com 
mais de um atributo na chave primária, já que as tabelas com somente 
um atributo na chave jamais irão ferir essa regra.
Primeiramente, verificamos no modelo que está na 1FN quais tabelas 
têm mais de um atributo na chave primária. No caso do nosso exemplo, 
somente a tabela modalidade_professor se encaixa nesse quesito.
modalidade_professor
professor_cpf
modalidade_codigo
descricao_modalidade
O único atributo que não pertence à chave primária é descricao_
modalidade. Então a dúvida é: esse atributo é uma informação de to-
dos os atributos da chave (professor_cpf e modalidade_codigo)? 
É importante ressaltar que descricao_modalidade pode conter os 
valores Natação e Hidroginástica.
Esses nomes variam de professor para professor? A resposta é não; 
a descricao_modalidade é uma informação somente da modalida-
de, e não do professor. Como a modalidade está representada pelo 
atributo modalidade_codigo, podemos deduzir que o atributo des-
Modelo relacional 49
cricao_modalidade é uma informação somente da modalidade, e 
não depende do professor. Deduzimos, então, que esse atributo não é 
a informação da totalidade da chave e está ferindo a 2FN.
2.4.2 Como aplicar a 2FN
Nesse caso, devemos criar uma tabela para acomodar este atributo 
descricao_modalidade, levando também a parte da chave que lhe 
diz respeito, no caso, modalidade_codigo, e na tabela original retirar 
esse atributo.
A tabela modalidade_professor e a nova tabela, que chamare-
mos de modalidade, ficariam desta forma:
modalidade_professor
professor_cpf
modalidade_codigo
modalidade
codigo
descricao
Note que mudamos os nomes dos atributos na nova tabela moda-
lidade para somente codigo e descrição, já que, por se tratar da 
tabela modalidade, não há mais a necessidade de colocar esse sufixo 
no nome dos atributos. Exemplificando essas duas novas tabelas com 
dados, teríamos:
Tabela modalidade_professor
professor_cpf modalidade_codigo
98615457689 1
98615457689 2
Tabela modalidade
codigo descricao
1 Natação
2 Hidroginástica
3 Recreação na piscina
Assim, como não existem mais tabelas com mais de um atributo na 
chave primária para analisarmos, o modelo na 2FN fica como mostra 
a Figura 4.
50 Modelagem de banco de dados e SQL
Figura 4
Tabelas do problema da escola de natação na 2FN
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade
estado
professor
cpf
nome
data_admissao
matricula
numero
data
turma
aluno
modalidade_professor
professor_cpf
modalidade_codigo
turma
codigo
nome
modalidade
descricao_dia_horario
professor
frequencia
matricula
data
frequentou
modalidade
codigo
descricao
Fonte: Elaborada pelo autor.
Após aplicarmos a 2FN, resolvemos o problema que aparecia na 
1FN, em que só era possível cadastrar uma nova modalidade se tivés-
semos um professor nessa modalidade. Na 2FN, como criamos uma 
tabela de modalidades, agora é possível cadastrar novas, mesmo não 
tendo ainda um professor para elas. É o caso da terceira linha colocada 
na tabela modalidade no exemplo da Figura 4.
2.5 Terceira forma normal (3FN) 
Vídeo Finalmente, será aplicada a terceira forma normal. Como nas ante-
riores, primeiramente, apresentaremos a regra da 3FN e, em seguida, 
a forma de aplicar a regra.
Modelo relacional 51
2.5.1 Regra da 3FN
Para Date (2003), uma tabela está na 3FN se estiver na 2FN e se todo 
atributo não chave for dependente de maneira não transitiva da cha-
ve primária. Em outras palavras, um atributo não pode ser uma nova 
tabela, ele deve ser dependente somente da chave, e não de outro atri-
buto não chave.
No exemplo, as tabelas turma, matricula, aluno e frequencia 
estão ferindo a 3FN, por isso é necessário analisar cada uma delas.
Primeira tabela que fere a 3FN – turma:
turma
codigo
nome
modalidade
descricao_dia_horario
professor
Em termos de ilustração com dados, a tabela turma seria:
Tabela turma
codigo nome modalidade descricao_dia_horario professor
10 Turma 1 Natação Seg/Qua/Sex das 9h às 19h Augusto Araújo
20 Turma 2 Hidroginástica Ter/Qui das 7h às 8h Augusto Araújo
Essa tabela contém o atributo modalidade, que, por sua vez, é 
uma tabela do modelo. Desse modo, temos o caso de um atributo ser 
uma tabela, o que fere a 3FN. O mesmo ocorre com o atributo profes-
sor, já que temos uma tabela com esse nome.
2.5.2 Como aplicar a 3FN
No lugar desses atributos, incluímos a chave primária das respecti-
vas tabelas, acrescentando o nome da tabela ao nome do atributo-cha-
ve. No caso da modalidade, substituímos por modalidade_codigo; 
no caso de professor, substituímos pelo professor_cpf.
Então a tabela turma ficaria assim:
52 Modelagem de banco de dados e SQL
turma
codigo
nome
modalidade_codigo
descricao_dia_horario
professor_cpf
Em termos de ilustração com dados, colocamos as tabelas profes-
sor, modalidade e turma.
Tabela professor
cpf nome data_admissao
98615457689 Augusto Araújo 19/03/2010
Tabela modalidade
codigo descricao
1 Natação
2 Hidroginástica
3 Recreação na piscina
Tabela turma
codigo nome modalidade_codigo descricao_dia_horario professor_cpf
10 Turma 1 1 Seg/Qua/Sex das 9h às 19h 98615457689
20 Turma 2 2 Ter/Qui das 7h às 8h 98615457689
Segunda tabela que fere a 3FN – matricula:
matricula
numero
data
turma
aluno
Modelo relacional 53
Em termos de ilustração com dados, a tabela de matricula seria:
Tabela matricula
numero data turma aluno
100 25/01/2021 Turma 1 Joaquim José
200 01/02/2021 Turma 2 Maria Andrade
Essa tabela contém o atributo turma que, por sua vez, é uma tabela 
do modelo. Sendo assim, temos o caso de um atributo ser uma tabela, 
o que fere a 3FN. O mesmo ocorre com o atributo aluno, já que temos 
uma tabela com esse nome.
Substituímos a turma por turma_codigo e, no caso de aluno, 
substituímos por aluno_cpf.
Então, a tabela matricula ficaria assim:
matricula
numero
data
turma_codigo
aluno_cpf
Em termos de ilustração com dados, as tabelas turma, aluno e 
matricula ficariam:
Tabela turma
codigo nome modalidade_codigo descricao_dia_horario professor_cpf
10 Turma 1 1 Seg/Qua/Sex das 9h às 19h 98615457689
20 Turma 2 2 Ter/Qui das 7h às 8h98615457689
Tabela aluno
cpf nome telefone rua numero complemento cep cidade estado
12345678901
Joaquim 
José
41-
987463666
Rua das 
Carmelitas
2213 Sobrado 1 800000 Curitiba PR
54355656566
Maria 
Andrade
41-
987455565
Rua XV de 
Novembro
415 Ap. 10 800000 Curitiba PR
54 Modelagem de banco de dados e SQL
Tabela matricula
numero data turma_codigo aluno_cpf
100 25/01/2021 10 12345678901
200 01/02/2021 20 54355656566
Terceira tabela que fere a 3FN – aluno:
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade
estado
Em termos de ilustração com dados, a tabela de aluno seria:
Tabela aluno
cpf nome telefone rua numero complemento cep cidade estado
12345678901
Joaquim 
José
41-
987463666
Rua das 
Carmelitas
2213 Sobrado 1 800000 Curitiba PR
54355656566
Maria 
Andra-
de
41-
987455565
Rua XV de 
Novembro
415 Ap. 10 800000 Curitiba PR
Nessa tabela, além existir um atributo que é uma tabela, haverá tam-
bém o atributo cidade, que, por sua vez, na nova tabela terá o atributo 
estado. Ambas serão novas tabelas, já que ainda não constam do modelo.
Substituímos a cidade por cidade_codigo e criamos a tabela 
cidade levando o atributo estado para ela, já que esse é um atributo 
de uma cidade.
Modelo relacional 55
Desse modo, a tabela aluno ficaria desta forma:
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
E uma nova tabela cidade seria criada:
cidade
codigo
nome
estado
Essa nova tabela, porém, também fere a 3FN, já que o atributo estado 
se refere a uma tabela. Assim, nessa tabela cidade substituímos o estado 
pelo atributo estado_sigla e este será a chave da nova tabela estado.
cidade
codigo
nome
estado_sigla
estado
sigla
nome
Em termos de ilustração com dados, as tabelas aluno, cidade e 
estado ficariam:
Tabela aluno
cpf nome telefone rua numero complemento cep
cidade_
codigo
12345678901
Joaquim 
José
41-
987463666
Rua das 
Carmelitas
2213 Sobrado 1 800000 1
54355656566
Maria 
Andrade
41-
987455565
Rua XV de 
Novembro
415 Ap. 10 800000 1
56 Modelagem de banco de dados e SQL
Tabela cidade
codigo nome estado_sigla
1 Curitiba PR
2 São Paulo SP
Tabela estado
sigla nome
PR Paraná
SP São Paulo
Quarta tabela que fere a 3FN – frequencia:
frequencia
matricula
data
frequentou
Em termos de ilustração com dados, a tabela frequencia seria:
Tabela frequencia
matricula data frequentou
100 15/02/2021 Sim
100 17/02/2021 Não
Essa tabela contém o atributo matricula, que, por sua vez, é uma 
tabela do modelo. Desse modo, temos o caso de um atributo ser uma 
tabela, o que fere a 3FN.
No lugar desse atributo, substituímos pela chave primária da tabela 
matricula, acrescentando o nome da tabela ao nome do atributo-cha-
ve, então o atributo matricula é substituído por matricula_numero.
Assim, a tabela frequencia ficaria da seguinte forma:
frequencia
matricula_numero
data
frequentou
Modelo relacional 57
Em termos de ilustração com dados, temos:
Tabela frequencia
matricula_numero data frequentou
100 15/02/2021 Sim
100 17/02/2021 Não
Com isso, nenhuma tabela está ferindo as três formas normais, e as 
tabelas ficam como mostra a Figura 5.
Figura 5
Tabelas do problema da escola de natação na 3FN
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
professor
cpf
nome
data_admissao
matricula
numero
data
turma_codigo
aluno_cpf
modalidade_professor
professor_cpf
modalidade_codigo
turma
codigo
nome
professor_cpf
modalidade_codigo
descricao_dia_horario
frequencia
matricula_numero
data
frequentou
modalidade
codigo
descricao
estado
sigla
nome
cidade
codigo
nome
estado_sigla
Fonte: Elaborada pelo autor.
Com as tabelas definidas e na 3FN, o último passo da construção do 
modelo lógico é a inserção dos relacionamentos.
58 Modelagem de banco de dados e SQL
2.6 Relacionamentos entre as tabelas 
Vídeo Para finalizar o modelo lógico, devemos verificar a maneira como as 
tabelas se relacionam e fazer uma ligação entre elas para representar 
essa forma.
De acordo com Date (2003, p. 355), um relacionamento é “uma as-
sociação entre entidades”.
Podemos perceber que muitos dos atributos fazem referência a ou-
tras tabelas, justamente para complementar os dados de uma linha e 
que, por força da aplicação das formas normais, tiveram que ser colo-
cados em outras tabelas.
Se olharmos a tabela aluno, por exemplo, e desejarmos saber o 
nome da cidade na qual ele mora, essa informação não estará explícita 
na tabela. Ali existe somente o código da cidade; com esse código é 
possível acessar a tabela cidade para buscar seu nome.
É possível perceber, então, que essas tabelas estão relacionadas. 
Nesta seção, aprenderemos os tipos de relacionamentos que podem 
existir entre tabelas e como representá-los no modelo lógico.
2.6.1 Relacionamento 1-para-muitos
Nesse tipo de relacionamento, também chamado de 1:n (lê-se “um 
para n”), uma determinada linha de uma tabela pode estar relacionada 
a nenhuma, a uma ou a mais linhas de outra tabela.
Citaremos como exemplo a tabela de cidade e a tabela de aluno. Se 
escolhermos uma determinada cidade na tabela cidade e verificarmos 
a tabela aluno, teremos que uma determinada cidade pode ter diversos 
alunos que moram nela, ou seja, uma cidade tem muitos alunos. Assim, 
acabamos de constatar um relacionamento entre essas duas tabelas.
Para efeito de visualização com dados, colocamos duas cidades na 
tabela cidade (Curitiba e São Paulo) e vários alunos na tabela aluno 
com o código de uma dessas cidades (Joaquim José e Maria Andrade, 
que moram em Curitiba). Também temos o aluno Arnaldo Antunes, 
que mora em São Paulo.
Modelo relacional 59
Tabela cidade
código nome estado_sigla
1 Curitiba PR
2 São Paulo SP
3 Joinville SC
Tabela aluno
cpf nome telefone rua numero complemento cep
cidade_ 
codigo
12345678901
Joaquim 
José
41-
987463666
Rua das 
Carmelitas
2213 Sobrado 1 800000 1
54355656566
Maria 
Andrade
41-
987455565
Rua XV de 
Novembro
415 Ap. 10 800000 1
34265536666
Arnaldo 
Antunes
11-
987656535
Rua das 
Amélias
23 110000 2
Nesse exemplo, podemos perceber que a primeira cidade, Curitiba, 
está relacionada a dois alunos (Joaquim José e Maria Andrade); a segun-
da cidade, São Paulo, está relacionada a um aluno (Arnaldo Antunes); e 
a terceira, Joinville, a nenhum aluno.
Em termos de representação no modelo lógico, quando existe um re-
lacionamento 1-para-muitos, colocamos uma linha entre as tabelas e, ao 
lado da tabela que representa o “muitos” (tabela aluno, nesse exemplo), 
acrescentamos três linhas pequenas, como mostra a Figura 6.
Figura 6
Exemplo de relacionamento 1-para-muitos
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
cidade
codigo
nome
estado_sigla
Fonte: Elaborada pelo autor.
60 Modelagem de banco de dados e SQL
A referida notação de relacionamento é normalmente chamada de 
notação pé de galinha, já que a extremidade colocada na tabela e que 
representa “muitos” se parece com o pé de uma galinha.
2.6.2 Relacionamento 1-para-1
Também chamado de 1:1 (lê-se “um para um”), nesse tipo de re-
lacionamento uma determinada linha de uma tabela está relacionada 
somente a uma linha de outra tabela.
No exemplo da escola de natação, não temos esse tipo de situação, en-
tão analisaremos duas tabelas: uma contendo todos os países do mundo 
e outra contendo todas as capitais dos países, por exemplo.
Nesse exemplo, um país tem somente uma capital e uma capital é 
capital de um único país, por isso temos um relacionamento 1-para-1 
entre essas duas tabelas.
Tabela pais
codigo nome capital_codigo
1 Brasil 10
2 Argentina 20
3 Chile 30
Tabela capital
codigo nome
10 Brasília
20 Buenos Aires
30 Santiago
Em termos de representação no modelo lógico, quando existe um 
relacionamento 1-para-1, colocamos somente uma linha entre as tabe-
las, como mostra a Figura 7.
Figura 7
Exemplo de relacionamento 1-para-1
pais
codigo
nome
capital_codigo
capital
codigo
nome
Fonte: Elaborada pelo autor.
Modelo relacional61
Existe também o relacionamento muitos-para-muitos, mas esse não 
é permitido para uso em bancos de dados, somente no diagrama de 
classes da UML 1 , e por isso não o estudaremos nesta seção.
2.6.3 Modelo lógico final com os relacionamentos
Agora, podemos finalizar o modelo lógico do exemplo da escola de 
natação com a inserção dos relacionamentos entre todas as tabelas, 
como é apresentado na Figura 8.
Figura 8
Modelo lógico final da escola de natação
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
professor
cpf
nome
data_admissao
matricula
numero
data
turma_codigo
aluno_cpf
modalidade_professor
professor_cpf
modalidade_codigo
turma
codigo
nome
descricao_dia_horario
professor_cpf
modalidade_codigo
frequencia
matricula_numero
data
frequentou
modalidade
codigo
descricao
estado
sigla
nome
cidade
codigo
nome
estado_sigla
Fonte: Elaborada pelo autor.
A leitura que podemos fazer de todos os relacionamentos apresen-
tados é a seguinte:
A UML é uma linguagem-padrão 
para a elaboração da estrutura 
de projetos de software. Ela 
poderá ser empregada para a 
visualização, a especificação, a 
construção e a documentação 
de artefatos que façam uso de 
sistemas complexos de software.
1
62 Modelagem de banco de dados e SQL
 • um estado tem muitas cidades;
 • uma cidade tem muitos alunos;
 • um aluno pode ter muitas matrículas;
 • uma matrícula tem muitos registros de frequência (um por aula);
 • uma turma pode ter muitas matrículas;
 • um professor pode atuar em muitas modalidades, e uma modali-
dade pode ter muitos professores;
 • pode haver muitas turmas de uma modalidade/ um professor.
Com isso, encerramos a importante construção de um modelo que 
servirá de base para a passagem ao modelo físico e ao banco de dados.
O artigo Normalização em bancos de dados, de Diego Machado, apresenta o 
processo de normalização, trazendo um exemplo diferente do que vimos 
neste capítulo.
Acesso em: 31 mar. 2021.
https://medium.com/@diegobmachado/normaliza%C3%A7%C3%A3o-em-banco-de-dados-5647cdf84a12 
Artigo
CONSIDERAÇÕES FINAIS
Neste capítulo, apresentamos os modelos conceitual e lógico de 
dados, passos iniciais para a construção de um modelo capaz de ser 
cadastrado em um banco de dados.
Para o banco de dados suportar as tabelas e seus relacionamentos, apli-
camos aos dados uma técnica chamada normalização, sem a qual diversos 
problemas poderiam acontecer no momento da utilização dos dados.
Por fim, produzimos o modelo lógico de dados, um importante diagra-
ma que servirá de base para o próximo passo do processo: a construção 
do modelo físico e a posterior implantação em um banco de dados.
ATIVIDADES 
1. O que é a normalização de tabelas? Comente.
2. Qual é a regra da primeira forma normal? 
3. Qual é o conceito de relacionamento entre as tabelas de um banco de 
dados? 
Vídeo
https://medium.com/@diegobmachado/normaliza%C3%A7%C3%A3o-em-banco-de-dados-5647cdf84a12
Modelo relacional 63
REFERÊNCIAS 
DATE, C. J. Introdução a sistemas de banco de dados. 8. ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, R.; NAVATHE, S. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Education 
do Brasil, 2013.
SILBERSCHATZ, A; KORTH, H. F; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de 
Janeiro: LTC, 2020.
64 Modelagem de banco de dados e SQL
3
Linguagem SQL – DDL
Neste capítulo, detalharemos ainda mais os modelos conceitual 
e lógico de dados. Novos componentes serão inseridos no modelo 
lógico a fim de possibilitar o cadastro das tabelas em um sistema 
gerenciador de banco de dados (SGBD). Esses componentes são 
necessários para que o SGBD tenha condições de responder a to-
das as consultas, manipulação e administração dos dados.
Com o modelo lógico tendo suas tabelas organizadas, as téc-
nicas de normalização aplicadas e os relacionamentos entre as 
tabelas instituídos, torna-se possível avançar nos estudos para 
aprender a maneira de informar ao banco de dados quais os tipos 
de atributos das tabelas, quais são as chaves, quais as restrições 
que podem ser impostas aos atributos para que, por fim, as tabe-
las estejam em condições de serem cadastradas no banco.
Também apresentaremos um importante SGBD, amplamente 
utilizado no mercado, o PostgreSql. Aprenderemos a instalar o 
software, a criar um banco de dados e a criar as tabelas com todos 
os seus componentes, deixando o banco pronto para que um sis-
tema de informação possa utilizá-lo.
3.1 Modelo físico 
Vídeo Com o modelo lógico construído com as tabelas normalizadas, indica-
ção de chave primária e relacionamento entre as tabelas, devemos inserir 
novos componentes no modelo, a fim de prepará-lo para ser incluído em 
um sistema de gerenciamento de banco de dados.
Linguagem SQL – DDL 65
O modelo físico, assim chamado por tratar de questões físicas de 
armazenamento, prepara as tabelas para que sejam cadastradas no 
SGBD. Como vimos, um SGBD é um software com a capacidade de ad-
ministrar os dados dos sistemas de informação e é dotado de diversas 
funcionalidades para servir aos sistemas. Também é capaz de armaze-
nar e recuperar os dados da forma que o usuário desejar, provê uma 
linguagem de acesso (que veremos nas seções seguintes) para selecio-
nar dados com as condições que o usuário deseja, garante a integrida-
de dos dados, faz automaticamente cópias de segurança e recuperação 
e é responsável por toda a administração dos dados.
No entanto, para que o SGBD execute suas funções de modo eficien-
te, necessita de que algumas condições sejam satisfeitas. As tabelas de-
vem estar normalizadas, os tipos dos atributos devem ser informados, 
as chaves, as restrições de atributos e a integridade referencial devem 
ser indicadas no modelo.
As informações mencionadas serão abordadas nas próximas seções.
3.1.1 Tipos de dados
A primeira tarefa a se fazer para transformar o modelo lógico em 
modelo físico de dados é a indicação do tipo de dado de cada atributo. 
Isso é importante e necessário, porque o banco de dados só aceitará o 
atributo que tenha valores compatíveis com seus tipos.
Os quadros a seguir apresentam os principais tipos usados no SGBD 
PostgreSql.
Tipos para armazenamento de dados numéricos inteiros
Tipo Tamanho Faixa de valores que o tipo comporta
smallint 2 bytes –32.768 até +32767
integer 4 bytes –2.147.483.648 até +2.147.483.647 (mais usado)
bigint 8 bytes –9223372036854775808 até 9223372036854775807
Tipos para armazenamento de dados numéricos fracionários
Tipo Tamanho Faixa de valores que o tipo comporta
Decimal Variável Sem limites (mais usado)
double precision 8 bytes 15 casas decimais depois da vírgula
66 Modelagem de banco de dados e SQL
Tipos para armazenamento de qualquer caractere (letras, nú-
meros e caracteres especiais)
Tipo Descrição
caracter varying(n) comprimento variável com limite (depende do SGBD)
varchar(n) comprimento variável com limite (depende do SGBD)
character(n) comprimento fixo (depende do SGBD), completado com espaços
char(n) comprimento fixo (depende do SGBD), completado com espaços
Text comprimento variável não limitado (mais usado)
Tipos para armazenamento de data e hora
Tipo Descrição
Timestamp without Time Zone Armazena tanto data quanto hora
Timestamp with Time Zone Armazena tanto data quanto hora
Interval Intervalos de tempo
Date Armazena somente datas (mais usado)
Time without Time Zone Armazena somente a hora do dia
Time with Time Zone Armazena somente a hora do dia
Tipos para armazenamento de variável com valor verdadeiro ou falso
Tipo Descrição
boolean
‘t’, ‘true’, ‘y’, ‘yes’, ‘1’ para verdadeiro 
‘f’, ‘false’, ‘n’, ‘no’, ‘0’ para falso
A informação do tipo de dado de cada atributo será importante para 
a criação do banco de dados no SGBD, que necessitará dessa informa-
ção para todas as consistências que garantirão a integridade dos dados.
3.1.2 Chave estrangeira e integridade referencial
Após a colocação dos relacionamentos entre as tabelas no modelo 
lógico de dados, podemos perceber que todas as tabelasrelacionadas 
têm um atributo em comum, justamente para fazer a ligação entre elas.
No exemplo da escola de natação, o modelo lógico de dados é o 
mostrado na Figura 1.
Linguagem SQL – DDL 67
Figura 1
Modelo lógico final da escola de natação
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
professor
cpf
nome
data_admissao
matricula
numero
data
turma_codigo
aluno_cpf
modalidade_professor
professor_cpf
modalidade_codigo
turma
codigo
nome
descricao_dia_horario
professor_cpf
modalidade_codigo
frequencia
matricula_numero
data
frequentou
modalidade
codigo
descricao
estado
sigla
nome
cidade
codigo
nome
estado_sigla
Fonte: Elaborada pelo autor.
Se analisarmos o atributo cidade_codigo da tabela aluno, po-
deremos perceber que seu conteúdo será um código de cidade per-
tencente à tabela cidade. Quando desejamos saber em qual cidade 
o aluno reside, basta usarmos o atributo cidade_codigo, acessar a 
tabela cidade buscando no seu atributo codigo e ler o nome da cida-
de. Dessa forma, as duas tabelas estão relacionadas por esse atributo.
O mesmo ocorre, por exemplo, com o atributo aluno_cpf na tabe-
la matricula para obtermos os dados do aluno de determinada ma-
trícula. Usamos aluno_cpf para ler a tabela aluno com esse valor e 
buscarmos os demais dados.
68 Modelagem de banco de dados e SQL
É dessa forma que todas as informações estão interligadas em um 
banco de dados relacional.
Os atributos que fazem a ligação com a chave primária da ta-
bela são chamados de chave estrangeira; por exemplo, o atributo 
cidade_codigo da tabela aluno.
Segundo Ramakrishnan e Gehrke (2008), a chave estrangeira em 
uma tabela deve corresponder à chave primária de outra a que a ta-
bela esteja relacionada. Os atributos devem ter a mesma característica 
e conteúdo, porém podem ter nomes diferentes. A chave estrangei-
ra produz uma condição conhecida como restrição de integridade, que 
impede a entrada de informações incorretas no banco, ou seja, não é 
possível incluir um aluno com um código de cidade que não conste na 
tabela cidade. Se isso fosse possível, ao tentarmos buscar o nome da 
cidade de um aluno cujo código não estivesse na tabela cidade, essa 
informação não estaria disponível para ser apresentada, indicando, en-
tão, falta de integridade nos dados.
A notação para essa chave é a colocação do símbolo FK (abreviatura 
do inglês foreign key, que significa chave estrangeira) ao lado do nome 
do atributo.
Usando novamente o exemplo das tabelas aluno e cidade, no qual 
o atributo cidade_codigo é chave estrangeira na tabela aluno, a no-
tação para ela seria o que mostra a figura a seguir.
Figura 2
Exemplo de chave estrangeira
aluno
cpf
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo (FK)
cidade
codigo
nome
estado_sigla
Fonte: Elaborada pelo autor.
Registrar os atributos que são chaves estrangeiras é de grande 
importância para garantir o que é chamado de integridade referencial, 
pois, por exemplo, sem esse registro não seria possível incluir um aluno 
Linguagem SQL – DDL 69
com um código de cidade que não consta na tabela de cidades. Da mes-
ma forma, não seria possível excluir uma cidade, caso tivesse um aluno 
que residisse nessa cidade. Essa integridade deve ser garantia sob risco 
de perder informações essenciais. No caso de excluir uma cidade, se 
houvesse um aluno que residisse nela, no momento da apresentação 
do endereço desse aluno, não seria possível informar o nome de sua 
cidade, o que seria um grave problema de falta de integridade.
3.1.3 Modelo físico da escola de natação: versão final
O modelo físico de dados, apresentado na Figura 3, complementa o 
modelo lógico com a colocação dos tipos dos atributos e a indicação de 
todas as chaves estrangeiras. Para a confecção do modelo físico, diver-
sas ferramentas de design podem ser utilizadas, no exemplo foi usada 
a ferramenta Vertabelo 1 .
Note que nos atributos que compõem a chave primária foi colocada 
a notação PK; e nos atributos que são chaves estrangeiras foi inserida 
a notação FK.
Figura 3
Modelo físico da escola de natação
Fonte: Elaborada pelo autor.
aluno professor
professor
frequencia
cidade
estado
modalidade
modalidade_professor
turma
cpf 
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
cpf
nome
data_admissao
numero
data
aluno_cpf
turma_codigo
matricula_numero
data
frequentou
codigo
nome
estado_sigla
sigla
nome
codigo
descricao
professor_cpf
modalidade_codigo
codigo
nome
descricao_dia_horario
professor_cpf
modalidade_codigo
text PK
text
text
text
text
text
text
int
int FK
text PK
text
date
int PK
date
text FK
int FK
int PK FK
date PK
boolean
int PK
text
text FK
text PK
text
int PK
text
text PK FK
int PK FK
int PK
text
text
text FK
int FK
Disponível em: https://
my.vertabelo.com/drive. 
Acesso em: 13 maio 2021.
1
https://my.vertabelo.com/drive
https://my.vertabelo.com/drive
70 Modelagem de banco de dados e SQL
Com isso, estamos prontos para incluir as tabelas com todas as suas 
informações em um SGBD.
3.2 Criação do modelo físico usando SQL – DDL 
Vídeo Antigamente, quando os dados eram armazenados em arquivos 
do próprio sistema, os comandos para manipular os dados eram 
próprios de cada linguagem de programação. Quando passaram 
a ser armazenados nos bancos de dados, mostrou-se a necessida-
de de que as linguagens ficassem independentes dos bancos de 
dados. Surgiu, então, uma linguagem cuja finalidade exclusiva era 
fazer todos os acessos aos dados, uma ponte ligando a linguagem 
de programação aos bancos de dados, essa linguagem foi chamada 
de SQL – Structured Query Language ou, em português, linguagem 
de consulta estruturada.
Desde então, SQL é a linguagem padrão de mercado para esse 
fim, praticamente todas as linguagens implementam o acesso ao 
banco pelo uso de SQL e todos os bancos aceitam serem acessados 
por ela.
O grande sucesso dos bancos de dados relacionais pode ser 
atribuído ao uso da linguagem SQL (ELMASRI; NAVATHE, 2013), vis-
to que é a linguagem mais amplamente utilizada em sistemas co-
merciais (RAMAKRISHNAN; GEHRKE, 2008).
A linguagem SQL apresenta duas partes principais: a DDL – 
Data Definition Language –, foco deste capítulo, e a DML – Data 
Manipulation Language.
A DDL objetiva fazer as definições no banco de dados; permite 
a definição de todo o modelo físico (tabelas, atributos, relaciona-
mentos, integridade referencial, entre outros) e fornece coman-
dos para criar, alterar ou excluir tabelas (SILBERSCHATZ; KORTH; 
SUDARSHAN, 2020).
Também é possível indicarmos algumas restrições para as ta-
belas. As restrições fazem com que o próprio banco de dados 
faça consistências e evite a entrada de dados inconsistentes nos 
atributos. Na linguagem DDL, essas restrições são denominadas 
constraint e são derivadas das regras no minimundo que o banco 
precisa representar (ELMASRI; NAVATHE, 2013).
Linguagem SQL – DDL 71
A seguir, vamos conhecer cinco tipos de restrições.
a. Checagem do valor do atributo – check
É possível permitir que um atributo receba somente alguns valores 
definidos. Para isso, nos comandos de criação e alteração de tabelas, 
podemos colocar uma constraint do tipo check.
Por exemplo, o atributo gênero, que só pode assumir os valores M 
e F, poderia ser assinalado da seguinte forma:
CONSTRAINT genero_chek CHECK (gênero IN (‘M’, ‘F’))
b. Checagem para que um atributo não tenha repetição de 
valor – unique
É possível indicarmos que um atributo não tenha valores repeti-
dos, ou seja, que não existam duas linhas com o mesmo conteúdo. Por 
exemplo, na tabela estado da escola de natação, caso não desejemos 
permitir que sejam incluídos dois estados com o mesmo nome, pode-
mos colocar uma constraint do tipo unique da seguinte forma:
CONSTRAINT nome_unique UNIQUE (nome)
c. Restrição de chave primária
A própria chave primária da tabela, no DDL, é indicada ao utilizar-
mos uma constraint. Por exemplo, na tabela estado da escola de nata-
ção, a chave primária seria indicadada seguinte forma:
CONSTRAINT estado_pk PRIMARY KEY (sigla)
d. Restrição de chaves estrangeiras
As chaves estrangeiras também são indicadas ao utilizarmos uma 
constraint. Por exemplo, a tabela cidade da escola de natação tem 
o atributo estado_sigla como chave estrangeira. Então, a definição 
dessa tabela teria essa chave estrangeira indicada da seguinte forma:
CONSTRAINT estado_sigla_fk FOREIGN KEY (estado_sigla) 
REFERENCES estado(sigla)
e. Nulidade nos valores dos atributos
Um conteúdo que pode ser concedido aos atributos e que aparecerá 
nos comandos DDL é o valor nulo. Este indica que o atributo pode não ter 
72 Modelagem de banco de dados e SQL
nenhum valor em algum momento (nem zero para atributos numéricos, 
nem espaços em branco para alfanuméricos). Os valores nulos são usa-
dos para representar os valores de atributos que podem ser desconheci-
dos ou não se aplicarem à determinada linha (ELMASRI; NAVATHE, 2013).
No modelo físico e nos comandos DDL, a indicação de que o atri-
buto é nulo, ou não, será pela colocação do termo NULL ou NOT NULL 
ao lado do tipo de atributo. No modelo físico do exemplo da escola de 
natação, nenhum atributo estava com essa indicação.
A seguir, veremos em detalhes todos os comandos do DDL que rea-
lizam essas funções.
3.2.1 Comando Create Table
Esse comando, como o nome já diz, é usado para se criar uma ta-
bela com todos os seus atributos (com seus tipos), indicação de chave 
primária e chaves estrangeiras.
O comando será apresentado por meio de um exemplo da tabe-
la estado do modelo físico da escola de natação, como mostrado no 
exemplo a seguir.
Exemplo 1:
Tabela estado
estado
sigla textPK 
nome text
Comando create dessa tabela:
CREATE TABLE estado (
sigla text NOT NULL,
nome text NOT NULL,
CONSTRAINT estado_pk PRIMARY KEY (sigla)
);
Detalhamento do comando
O comando inicia com o termo CREATE e, em seguida, TABLE, indi-
cando a criação de uma nova tabela.
Linguagem SQL – DDL 73
Temos a seguir o nome da tabela (estado) e a abertura de um 
parêntese. Dentro dele, temos a lista de atributos. Para cada atribu-
to, temos seu nome; em seguida, o seu tipo; e, depois, a informação 
NOT NULL (indicando que esse atributo não aceita valores nulos).
Finalmente, o termo CONSTRAINT é usado para indicar quais atribu-
tos fazem parte da chave primária. É atribuído um nome a essa chave, 
no caso, estado_pk, a indicação PRIMARY KEY (indicando que é uma 
constraint para indicação de chave primária) e, por fim, entre parênte-
ses, os atributos que compõem a chave primária, nesse caso, o atributo 
sigla.
Exemplo 2:
Tabela cidade
cidade
codigo int PK 
nome text 
estado_sigla text FK
Comando create dessa tabela:
CREATE TABLE cidade (
codigo int NOT NULL,
nome text NOT NULL,
estado_sigla text NOT NULL,
CONSTRAINT cidade_pk PRIMARY KEY (codigo),
CONSTRAINT estado_sigla_fk FOREIGN KEY (estado_sigla) 
 REFERENCES estado(sigla)
);
Detalhamento do comando
Além dos comandos explicados no primeiro exemplo, nesse apare-
ce a CONSTRAINT de indicação da chave estrangeira.
Após esse termo, aparece o nome da constraint (estado_sigla_fk); 
em seguida, o termo FOREIGN KEY, indicando tratar-se de uma constraint 
de chave estrangeira; depois, o nome do atributo da tabela cidade, 
que é a chave estrangeira propriamente dita (estado_sigla); na se-
quência, o termo REFERENCES, indicando a qual tabela se deseja fazer 
74 Modelagem de banco de dados e SQL
referência; e, por fim, o nome da tabela e do atributo-chave que será a 
ligação, nesse caso, estado(sigla).
Listamos a seguir todos os comandos de criação de todas as tabelas 
do modelo físico da escola de natação.
Tabela aluno
CREATE TABLE aluno (
cpf text NOT NULL,
nome text NOT NULL,
telefone text NOT NULL,
rua text NOT NULL,
numero text NOT NULL,
complemento text NOT NULL,
bairro text NOT NULL,
cep int NOT NULL,
cidade_codigo int NOT NULL,
CONSTRAINT aluno_pk PRIMARY KEY (cpf),
CONSTRAINT cidade_codigo_fk FOREIGN KEY (cidade_codigo) 
 REFERENCES cidade(codigo)
);
Tabela professor
CREATE TABLE professor (
cpf text NOT NULL,
nome text NOT NULL,
data_admissao date NOT NULL,
CONSTRAINT professor_pk PRIMARY KEY (cpf)
);
Linguagem SQL – DDL 75
Tabela modalidade
CREATE TABLE modalidade (
codigo int NOT NULL,
descricao text NOT NULL,
CONSTRAINT modalidade_pk PRIMARY KEY (codigo)
);
Tabela modalidade_professor
CREATE TABLE modalidade_professor (
professor_cpf text NOT NULL,
modalidade_codigo int NOT NULL,
CONSTRAINT modalidade_professor_pk PRIMARY KEY 
 (professor_cpf,modalidade_codigo),
CONSTRAINT professor_cpf_fk FOREIGN KEY (professor_cpf) 
 REFERENCES professor(cpf),
CONSTRAINT modalidade_codigo_fk FOREIGN KEY 
 (modalidade_codigo) REFERENCES 
 modalidade(codigo)
);
Tabela turma
CREATE TABLE turma (
codigo int NOT NULL,
nome text NOT NULL,
descricao_dia_horario text NOT NULL,
professor_cpf text NOT NULL,
modalidade_codigo int NOT NULL,
CONSTRAINT turma_pk PRIMARY KEY (codigo),
CONSTRAINT professor_cpf_fk FOREIGN KEY (professor_cpf) 
 REFERENCES professor(cpf),
CONSTRAINT modalidade_codigo_fk FOREIGN KEY 
 (modalidade_codigo) REFERENCES 
 modalidade(codigo)
);
76 Modelagem de banco de dados e SQL
Tabela matricula
CREATE TABLE matricula (
numero int NOT NULL,
data date NOT NULL,
aluno_cpf text NOT NULL,
turma_codigo int NOT NULL,
CONSTRAINT matricula_pk PRIMARY KEY (numero),
CONSTRAINT aluno_cpf_fk FOREIGN KEY (aluno_cpf) 
 REFERENCES aluno(cpf),
CONSTRAINT turma_codigo_fk FOREIGN KEY 
 (turma_codigo) REFERENCES 
 turma(codigo)
);
Tabela frequencia
CREATE TABLE frequencia (
matricula_numero int NOT NULL,
data date NOT NULL,
frequentou boolean NOT NULL,
CONSTRAINT frequencia_pk PRIMARY KEY 
 (matricula_numero,data),
CONSTRAINT matricula_numero_fk FOREIGN KEY 
 (matricula_numero) REFERENCES 
 matricula(numero)
);
Esses foram todos os comandos necessários para criarmos o banco 
de dados da escola de natação em um SGBD.
3.2.2 Comando Alter Table
Esse comando, como o nome já diz, faz alterações em definições de 
tabelas já criadas. A estrutura e as opções do comando são as seguintes:
Linguagem SQL – DDL 77
ALTER TABLE <nome-da-tabela>
DROP COLUMN <nome-do-atributo>
ADD <nome-do-atributo> <tipo-do-dado> [NOT NULL]
RENAME <nome-do-atributo> TO <novo-nome-do-atributo>
RENAME TO <novo-nome-tabela>
MODIFY <nome-do-atributo> <tipo-do-dado> [NULL]
ADD <constraint>
Detalhamento das opções:
 • DROP: exclui determinado atributo.
 • ADD: inclui um novo atributo ou uma constraint.
 • RENAME: altera o nome do atributo ou da tabela.
 • MODIFY: altera o tipo de dado do atributo.
O comando Alter Table deve ser usado com cuidado, pois ao excluir, 
por exemplo, determinado atributo, o conteúdo de todas as linhas 
desse atributo desaparecerá.
3.2.3 Comando Drop Table
Esse comando tem por finalidade excluir uma tabela. A estrutura do 
comando é a seguinte:
DROP TABLE <nome-da-tabela>
Ao excluirmos uma tabela, todo o seu conteúdo é perdido.
Você sabia que existem 
outras formas de ar-
mazenamento que não 
em bancos de dados 
relacionais e que não 
são acessados por SQL? 
São os bancos de dados 
NoSQL. Confira no vídeo 
NoSQL: dicionário do pro-
gramador , publicado no 
canal Código Fonte TV.
Disponível em: https://
www.youtube.com/
watch?v=1B64oqE8PLs. Acesso em: 
13 maio 2021.
Vídeo
3.3 Criação do modelo físico no 
banco de dados PostgreSql Vídeo
Um dos SGBD gratuitos e mais utilizados no mundo é o PostgreSql. 
Segundo Milani (2008, p. 25): “o PostgreSql é um Sistema Gerenciador 
de Banco de Dados (SGBD) Relacional, utilizado para armazenar infor-
mações de soluções de informática em todas as áreas de negócios exis-
tentes, bem como administrar o acesso a essas informações”.
78 Modelagem de banco de dadose SQL
De acordo com a página oficial do fabricante 2 , esse SGBD está na 
versão 13.2.
Veremos a seguir como instalar e criar um banco de dados e suas 
tabelas nesse SGBD.
3.3.1 Instalando o PostgreSql
Primeiro, devemos acessar a página do fabricante, baixar última 
versão do SGBD e instalar no computador, conforme as orientações 
padrões de instalação de qualquer software. Além do SGBD PostgreSql 
propriamente dito, a instalação fornece um software administrador 
chamado PGADMIN4, que facilita a criação e a manipulação do banco 
de dados e das tabelas, com uma tela amigável e de fácil manuseio.
Após completarmos a instalação, é preciso acessar o programa 
PGADMIN4, que foi instalado na sua máquina. A tela da Figura 4 será 
apresentada.
Figura 4
Tela inicial do PGADMIN4
Fonte: PGADMIN4, 2021.
Essa tela apresenta a versão 9.3 do PostgreSql. No momento da sua 
instalação, essa versão pode estar diferente, mas isso não inviabilizará 
as próximas instruções.
3.3.2 Criando o banco de dados da escola de natação
A primeira ação é criarmos um banco de dados. No caso do nosso 
estudo, criaremos o banco chamado EscolaNatacao. Para isso, na tela 
da Figura 4, devemos clicar com o botão direito em PostgreSQL 9.3, locali-
zado no canto superior esquerdo, e selecionar a opção Create/Database. 
Disponível em: https://
www.postgresql.org/. 
Acesso em: 13 maio 2021.
2
https://www.postgresql.org/
https://www.postgresql.org/
Linguagem SQL – DDL 79
A tela da Figura 5 será apresentada. Em seguida, precisamos inserir o 
nome do banco, conforme a figura, e clicar em Save.
Figura 5
Criação do banco de dados da escola de natação
Fonte: PGADMIN4, 2021.
Ao abrirmos a lista de Databases na coluna da esquerda, clican-
do no botão + ao lado da palavra, deverá aparecer o banco de dados 
EscolaNatacao criado.
3.3.3 Criando as tabelas do banco de 
dados da escola de natação
O próximo passo, agora, é criarmos as tabelas do banco, com base 
nas tabelas do modelo físico de dados.
A sugestão é de que se crie primeiro as tabelas que não tenham 
chaves estrangeiras.
80 Modelagem de banco de dados e SQL
Para iniciar a criação das tabelas, devemos clicar no botão +, ao lado 
do nome do banco EscolaNatacao, para expandir o menu disponível. 
A tela da Figura 6 será apresentada.
Figura 6
Expansão do menu do banco de dados da escola de natação
Fonte: PGADMIN4, 2021.
A opção indicada pela seta listará todas as tabelas criadas.
3.3.3.1 Criação da tabela estado
Para criar uma tabela, devemos clicar com o botão direito na palavra 
Tables, indicada pela seta da Figura 6. Em seguida, escolhemos a opção 
Create/Table. A tela da Figura 7 será apresentada. Devemos colocar o nome 
da tabela estado, como mostra a figura (não devemos pressionar o botão 
Save ainda).
Linguagem SQL – DDL 81
Figura 7
Tela para criação da tabela estado
Fonte: PGADMIN4, 2021.
Após digitarmos o nome da tabela, selecionamos a aba Columns, 
conforme indicação da seta (Figura 7). A tela da Figura 8 será apresen-
tada para a inclusão dos atributos da tabela.
Figura 8
Tela para criação dos atributos de uma tabela
Fonte: PGADMIN4, 2021.
Para a inclusão dos atributos, pressionamos o botão +, conforme 
indica a seta na Figura 8. A tela da Figura 9 será apresentada para a 
inclusão das informações de um novo atributo da tabela. Devemos 
preencher os campos conforme a figura. Após a informação do campo 
82 Modelagem de banco de dados e SQL
sigla, pressionamos o botão + para a inclusão do segundo campo: 
nome.
Figura 9
Tela com as informações dos atributos da tabela estado
Fonte: PGADMIN4, 2021.
Após informar os dois atributos, pressionamos o botão Save. A nova ta-
bela aparecerá na lista de tabelas do banco de dados e, ao selecionarmos 
a tabela, o seu comando DDL create será mostrado, conforme a Figura 10.
Figura 10
Tela com as informações da nova tabela estado em SQL
Fonte: PGADMIN4, 2021.
Linguagem SQL – DDL 83
Esse comando create gerado pelo PostgreSql traz alguns compo-
nentes a mais que o padrão mostrado, porém são para a sua própria 
administração no banco e não interferem no entendimento geral do 
comando.
3.3.3.2 Criação da tabela cidade
Esse exemplo difere do anterior, uma vez que aprenderemos a criar 
uma chave estrangeira no banco de dados, haja vista que essa tabela 
tem o atributo estado_sigla como chave estrangeira.
Novamente, para iniciar o processo, clicamos com o botão direito na 
palavra Tables e selecionamos Create/Table. Devemos informar o nome 
da tabela cidade, pressionar a aba Columns, informar os atributos da tabe-
la, como mostra a Figura 11 (não devemos pressionar o botão Save ainda).
Figura 11
Tela com as informações da nova tabela cidade em SQL
Fonte: PGADMIN4, 2021.
Agora, para a criação da constraint de chave estrangeira, devemos 
selecionar a aba Constraints e, em seguida, a aba Foreign Key. Na tela 
que aparecerá, pressionamos o botão + na parte superior direita e 
preenchemos o campo Name, como mostra a figura a seguir.
84 Modelagem de banco de dados e SQL
Figura 12
Tela com as informações da Foreign Key da tabela cidade
Fonte: PGADMIN4, 2021.
Agora, devemos pressionar o botão com o ícone Editar (ao lado do 
símbolo de lixeira), como mostra a seta, para colocarmos as informa-
ções da FK. Em seguida, selecionamos a aba Columns, preenchendo 
conforme a Figura 13, e pressionamos o botão + do quadro pequeno a 
seguir para incluir a FK.
Figura 13
 Tela com as informações da Foreign Key da tabela cidade
Fonte: PGADMIN4, 2021.
Linguagem SQL – DDL 85
Finalmente, ao pressionarmos o botão Save, a nova tabela estará na 
lista de Tables. Clicando sobre o nome da tabela, aparecerá o código 
SQL Create da tabela, como mostra a Figura 14.
Figura 14
Comando Create da tabela cidade
Fonte: PGADMIN4, 2021.
Com esses dois exemplos, é possível fazermos a criação das demais 
tabelas do banco de dados da escola de natação, já que elas se asseme-
lham aos exemplos e nenhuma outra tabela tem algum componente 
diferente dessas duas.
Assim, conhecemos um SGBD bastante utilizado no mercado e fina-
lizamos o cadastro das tabelas, deixando o banco pronto para ser utili-
zado diretamente no banco ou por alguma linguagem de programação 
em um sistema de informação.
O artigo intitulado Comparativo de desempenho entre bancos de dados de código 
aberto, de autoria de Ana Carolina Salgado, Carlos Eduardo Santos Pires e 
Rilson Oscar do Nascimento, mostra algumas comparações entre PostgreSql 
e outros bancos.
Acesso em: 26 abr. 2021.
https://www.researchgate.net/profile/Ana-Carolina-Salgado/publication/242213657_Comparativo_
de_Desempenho_entre_Bancos_de_Dados_de_Codigo_Aberto/links/004635296426ba710e000000/
Comparativo-de-Desempenho-entre-Bancos-de-Dados-de-Codigo-Aberto.pdf
Artigo
86 Modelagem de banco de dados e SQL
CONSIDERAÇÕES FINAIS
Apresentamos a transformação do modelo lógico em modelo físico de 
dados, com a introdução de diversos componentes nas tabelas, necessá-
rios para o seu cadastramento em SGBD.
Conhecemos também o SGBD PostgreSql, um importante software 
amplamente utilizado pelo mercado de trabalho. Além disso, indicamos 
como colocar todas as tabelas do exemplo da escola de natação no ban-
co, com todos os seus atributos e componentes, para que esteja em con-
dições de ser utilizado pelos sistemas de informação.
ATIVIDADES
1. Qual é a finalidade de se criar um modelo físico de dados? Comente.
2. O que são chaves estrangeiras? Explique.
3. O que é a linguagem SQL? Comente.
REFERÊNCIAS
DATE, C. J. Introdução a sistemas de banco de dados. 8 ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, R.; NAVATHE, S. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Education 
do Brasil, 2013.
MILANI, A. PosgreSQL: guia do programador. São Paulo: Novatec, 2008.
PGADMIN4. Software. Disponível em: http://127. 0.0.1:55457/browser/. Acesso em: 29 abr. 2021.
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de gerenciamento de banco de dados. 3 ed. São 
Paulo: McGraw-Hill, 2008.
SILBERSCHATZ, A.; KORTH, H.F; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de 
Janeiro: LTC, 2020.
Vídeo
Linguagem SQL – DML 87
4
Linguagem SQL – DML
Este capítulo traz um aspecto extremamente prático da ma-
nipulação dos dados em um banco de dados. Com as tabelas 
organizadas, estruturadas segundo as regras de normalização e 
cadastradas no SGBD com o uso de comandos SQL/DDL, é possí-
vel disponibilizá-las para a inclusão e manipulação de dados.
Serão abordados os comandos para inclusão de linhas nas ta-
belas e alteração e exclusão por meio de comandos SQL/DML que 
serão vistos no decorrer do capítulo.
Também serão conhecidos os principais comandos para busca 
dos dados cadastrados na tabela, por meio do comando SELECT, 
um comando extremamente simples, amplo, versátil e capaz de 
buscar dados segundo diversas condições, atendendo, na sua 
maioria, as necessidades dos sistemas de informação.
4.1 Comandos SQL para atualização 
Vídeo O Data Manipulation Language (DML) é uma parte da linguagem 
SQL encarregada de manipular os dados, seja para consultar, para in-
cluir, alterar ou excluir dados no banco de dados. Segundo Date (2003, 
p. 71), “a SQL inclui operações de definição de dados e operações de 
manipulação de dados”, referindo-se ao DML.
A linguagem SQL não é uma mera linguagem de consulta a um ban-
co de dados, ela pode fazer muito mais do que isso. Segundo Silbers-
chatz, Korth e Sudarshan (2020, p. 37): “ela pode definir a estrutura dos 
dados, modificar dados no banco de dados e especificar restrições de 
segurança”.
Para o aprendizado de todos os comandos DML, utilizaremos o es-
tudo de caso da escola de natação. A figura a seguir mostra o modelo 
físico de dados com as tabelas e os relacionamentos desse problema.
88 Modelagem de banco de dados e SQL
Figura 1
Modelo físico de dados da escola de natação
Fonte: Elaborada pelo autor.
aluno professor
professor
frequencia
cidade
estado
modalidade
modalidade_professor
turma
cpf 
nome
telefone
rua
numero
complemento
bairro
cep
cidade_codigo
cpf
nome
data_admissao
numero
data
aluno_cpf
turma_codigo
matricula_numero
data
frequentou
codigo
nome
estado_sigla
sigla
nome
codigo
descricao
professor_cpf
modalidade_codigo
codigo
nome
descricao_dia_horario
professor_cpf
modalidade_codigo
text PK
text
text
text
text
text
text
int
int FK
text PK
text
date
int PK
date
text FK
int FK
int PK FK
date PK
boolean
int PK
text
text FK
text PK
text
int PK
text
text PK FK
int PK FK
int PK
text
text
text FK
int FK
A seguir serão mostrados os comandos DML responsáveis pelas 
atualizações nas tabelas.
4.1.1 Comando INSERT
Como o nome já indica, o comando INSERT é utilizado para incluir 
dados nas tabelas.
Observe a estrutura do comando a seguir.
INSERT INTO tabela (atributo1, atributo1,..., atributoN) 
 VALUES (valor1, valor2,..., valorN)
Em que: atributo1, atributo2, ..., atributoN são os no-
mes dos atributos da tabela e valor1, valor2, ..., valorN são 
valores correspondentes a cada um deles.
Linguagem SQL – DML 89
Exemplo 1: Considere a Tabela estado
sigla nome
PR Paraná
SC Santa Catarina
SP São Paulo
RS Rio Grande do Sul
O comando para incluir a primeira linha seria:
INSERT INTO estado (sigla,nome) 
 VALUES (‘PR’, ‘Paraná’)
Para as demais linhas, teríamos:
INSERT INTO estado (sigla,nome) 
 VALUES (‘SC’, ‘Santa Catarina’)
INSERT INTO estado (sigla,nome) 
 VALUES (‘SP’, ‘São Paulo’)
INSERT INTO estado (sigla,nome) 
 VALUES (‘RS’, ‘Rio Grande do Sul’)
Exemplo 2: Considere a Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
90 Modelagem de banco de dados e SQL
O comando para incluir a primeira linha seria:
INSERT INTO
aluno(cpf,nome,telefone,rua,numero,complemento,
 bairro,cep,cidade_codigo) 
 VALUES (‘12345678901’,’Joaquim José’, 
 ‘41-87654568’,’Rua A’,’123’,’’,
 ‘Batel’,80000,1)
Para as demais linhas, basta substituir os valores no comando 
apresentado.
4.1.2 Comando UPDATE
Como o nome já indica, o comando UPDATE atualiza os dados de 
uma tabela.
Estrutura do comando:
UPDATE tabela SET atributo1 = valor1,
 atributo2 = valor2,
 atributoN = valorN
 WHERE condições
Em que: campo1, campo2, ..., campoN são os nomes dos atri-
butos da tabela e valor1, valor2, ..., valorN são valores cor-
respondentes a cada um deles.
As condições serão verificadas e a atualização ocorrerá somente 
nas linhas que forem verdadeiras.
Exemplo 1: Alterar o nome do aluno Gabriel Henrique para Ga-
briel Henrique Cardoso.
Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
(Continua)
Linguagem SQL – DML 91
cpf nome telefone rua numero complemento bairro cep cidade_codigo
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Comando:
UPDATE aluno SET nome = ’Gabriel Henrique Cardoso’
 WHERE cpf = ‘98576524546’
Exemplo 2: Alterar o código de todos os alunos da cidade = 1 para 
cidade = 2.
Comando:
UPDATE aluno SET código_cidade = 2
 WHERE código_cidade = 1
Esse comando atualizará o código da cidade para 2 das 4 primeiras 
linhas.
Exemplo 3: Alterar o nome da rua de todos os alunos para Rua A.
Comando:
UPDATE aluno SET rua = ‘Rua A’
Observações:
Cuidado: quando não colocamos a cláusula WHERE, o comando 
atualiza todas as linhas da tabela.
Não é permitida a alteração do valor dos atributos que compõem a 
chave primária. Quando for necessário, deve-se excluir a linha e incluir 
novamente com a chave correta.
92 Modelagem de banco de dados e SQL
4.1.3 Comando DELETE
Como o nome já indica, o comando DELETE exclui linhas de uma 
tabela.
Estrutura do comando:
DELETE FROM tabela
 WHERE condições
As condições serão verificadas e a exclusão ocorrerá somente nas 
linhas que forem verdadeiras.
Exemplo 1: Excluir o estado do Rio Grande do Sul.
Tabela estado
sigla nome
PR Paraná
SC Santa Catarina
SP São Paulo
RS Rio Grande do Sul
Comando:
DELETE FROM estado
 WHERE sigla = ‘RS’
Observações:
Cuidado: quando não colocamos a cláusula WHERE, o comando ex-
cluirá todas as linhas da tabela, ou seja, a tabela ficará vazia.
Nesse exemplo, como a tabela estado está relacionada à tabela 
cidade, caso exista alguma cidade cadastrada com a sigla do estado 
RS que está se tentando excluir, o comando retorna um erro e não 
permite a exclusão justamente para garantir a integridade referencial 
entre as tabelas.
Linguagem SQL – DML 93
4.2 Comandos SQL para consultas básicas 
Vídeo Primeiramente, conheceremos a forma de se realizar consultas bá-
sicas no banco de dados a fim de se familiarizar com o comando que 
faz todas as consultas, o comando SELECT.
4.2.1 Comando SELECT
O comando SELECT tem por objetivo recuperar linhas das tabelas 
do banco de dados. É um comando extremamente simples e, ao mes-
mo tempo, muito versátil. É capaz de trazer os dados da maneira que 
o usuário precisa. Além disso, oferece diversas opções para busca dos 
dados, atendendo quaseque na totalidade as necessidades dos siste-
mas de informação.
É capaz de selecionar somente algumas linhas, segundo diversos 
critérios com a colocação de condições sobre as linhas que se deseja 
buscar, e de ordenar o resultado da forma que se desejar, também 
pode filtrar e fazer operações sobre colunas, agrupar e totalizar valores 
delas e juntar estas de diversas tabelas.
O comando consegue produzir automaticamente resultados que 
seriam de grande complexidade para serem programados em uma lin-
guagem de programação. Além disso, a velocidade de recuperação dos 
dados é extremamente satisfatória, dada a complexidade de algumas 
consultas.
Todas essas variações do comando serão vistas em detalhes nas 
subseções seguintes com a explicação do comando, os dados da(s) ta-
bela(s) e o resultado do comando.
Na sequência, conheceremos a estrutura básica do comando 
SELECT e, em seguida, diversos exemplos de sua utilização.
O comando será emitido no SGBD PostgreSql e o resultado forneci-
do por ele será colocado na sequência do comando.
4.2.1.1 Estrutura básica do comando SELECT
De acordo com Elmasri e Navathe (2013), a estrutura básica do co-
mando SELECT é a seguinte:
94 Modelagem de banco de dados e SQL
SELECT atributos 
FROM tabela
Os atributos desejados da tabela indicados na cláusula FROM de-
vem ser separados por vírgulas.
Exemplo 1: Dada a tabela aluno, listar o CPF e o nome de todos os 
alunos.
Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Comando:
SELECT cpf,nome 
FROM aluno
Observe o resultado a seguir.
cpf nome
12345678901 Joaquim José
87654567365 Maria Cândida
98756514522 Ronaldo Antunes
98576524546 Gabriel Henrique
64514343456 Gustavo Lacerda
98576543656 Tiago Alcântara
95876756512 Célia Justina
Linguagem SQL – DML 95
Essa estrutura básica, apesar de simples, fornece uma visão rápida 
de todas as linhas das tabelas. A seguir, serão incorporadas novas cláu-
sulas ao comando para refinar as buscas.
4.2.1.2 Condições sobre as linhas e ordenação
Para filtrar linhas que satisfaçam determinadas condições e trazer 
o resultado conforme uma ordenação, é possível colocar as cláusulas 
WHERE e ORDER BY.
SELECT atributos 
FROM tabela
WHERE condição
ORDER BY atributos <DESC>
Exemplo 1: Dada a tabela aluno, listar o CPF e o nome de todos, 
cujo código da cidade seja igual a 1 e listar em ordem alfabética.
Comando:
SELECT cpf,nome 
FROM aluno
WHERE cidade_codigo = 1
ORDER BY nome
Observe o resultado a seguir.
cpf nome
98576524546 Gabriel Henrique
12345678901 Joaquim José
87654567365 Maria Cândida
98756514522 Ronaldo Antunes
Observações:
Para selecionar todos os atributos da tabela, basta utilizar SELECT *.
Exemplo 2: Dada a tabela aluno, listar todos os atributos do aluno 
Gustavo Lacerda.
Comando:
SELECT *
FROM aluno
WHERE nome = ‘Gustavo Lacerda’
96 Modelagem de banco de dados e SQL
Resultado:
cpf nome telefone rua numero complemento bairro cep cidade_codigo
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
Podemos perceber, nesse resultado, que a busca retornou o nome 
exatamente como foi solicitado na cláusula WHERE.
4.2.1.3 Operadores da cláusula WHERE 
A cláusula WHERE admite outros operadores e não somente o de 
igualdade.
Operadores matemáticos
A cláusula WHERE aceita os seguintes operadores matemáticos:
= Igual
<> Diferente
> Maior
>= Maior ou Igual
< Menor
<= Menor ou Igual
Exemplo 1: Dada a tabela turma, listar as turmas com valor de men-
salidade maior que R$ 200,00.
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10 Turma 1 de Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20 Turma 2 de Natação
Ter/Qui das 8h às 
9h
56254566711 1 200 10
30
Turma 1 de Hidrogi-
nástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40 Turma 3 de Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50 Turma 4 de Natação
Ter/Qui das 10h às 
11h
56254566711 1 190 10
60
Turma 2 de Hidrogi-
nástica
Ter/Qui das 7h às 
8h
56254566711 2 350 30
Linguagem SQL – DML 97
Comando:
SELECT *
FROM turma
WHERE valor_mensalidade > 200
Resultado:
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Exemplo 2: Dada a tabela turma, listar as turmas que não sejam do 
professor com CPF 72345678901.
Comando:
SELECT *
FROM turma
WHERE professor_cpf <> ‘72345678901’
Resultado:
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Operadores AND e OR
A cláusula WHERE também aceita várias condições, para isso, po-
dem ser usados os operadores booleanos AND E OR.
98 Modelagem de banco de dados e SQL
Exemplo 1: Dada a tabela turma, listar as turmas com código de mo-
dalidade igual a 1 e valor de mensalidade menor ou igual a R$ 200,00.
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Comando:
SELECT *
FROM turma
WHERE modalidade_codigo = 1
AND valor_mensalidade <= 200
Observe o resultado a seguir.
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
Operador IN
É possível substituir diversos operadores OR pelo operador IN. 
Quando se deseja avaliar se determinado valor pertence a uma lista de 
valores, pode-se usar o operador IN.
Linguagem SQL – DML 99
Exemplo 1: Dada a tabela aluno, todos os atributos dos alunos que 
moram na cidade 1 ou 2.
Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Comando:
SELECT * 
FROM aluno
WHERE cidade_codigo IN (1,2)
Observe o resultado a seguir.
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
100 Modelagem de banco de dados e SQL
Operadores IS NULL e IS NOT NULL
Usados quando se deseja listar atributos cujos conteúdos sejam nu-
los ou não.
Exemplo 1: Dada a tabela aluno, listar todos os atributos dos alu-
nos cujo complemento esteja com o valor NULO.
Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Observe o comando a seguir.
SELECT * 
FROM aluno
WHERE complemento IS NULL
Resultado:
cpf nome telefone rua numero complemento bairro cep cidade_codigo
Observações:
Nesse caso, o comando não retornou nenhuma linha, indicando 
que nenhum valor do atributo complemento é nulo.
Operador LIKE
Esse operador atua sobre atributos do tipo texto e tem por finalida-
de filtrar partes de um texto.
Usa-se o símbolo “%” para substituir um conjunto de caracteres e “_”, 
um carácter específico.
Linguagem SQL – DML 101
Exemplos:
 • Selecionar todos os alunos cujos nomes iniciam com a letra G, 
usar:
WHERE nome LIKE ‘G% ‘
Retorna: Gabriel Henrique e Gustavo Lacerda
 • Selecionar todos os nomes que terminam com unes, usar:
WHERE nome LIKE ‘%unes ‘
Retorna: Ronaldo Antunes
 • Selecionar todos os nomes que começam com determinada letra 
e depois a letra a, usar:
WHERE nome LIKE ‘_a% ‘
Retorna: Maria Cândida e Gabriel Henrique
Exemplo 1: Para este último exemplo, teríamos:
Tabela aluno
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Comando:
SELECT * 
FROM aluno
WHERE nome LIKE ‘_a%’
102 Modelagem de banco de dados e SQL
Resultado:
cpf nome telefone rua numero complemento bairro cep cidade_codigo
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
Valores calculados
É possível selecionar valores calculados tanto no atributo como na 
cláusula WHERE. Para isso, basta colocar a expressão matemática dese-
jada. Para se dar um nome ao atributo com o resultado da expressão, 
pode-se usar o que é chamado de álias, colocando a cláusula AS antes 
dele.
Exemplo 1: Dada a tabela turma, listar o nome da turma e o valor 
da mensalidade menos o valor do desconto, mas somente se esse valor 
for menor que R$ 200,00.
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Comando:
SELECT nome, valor_mensalidade - valor_desconto 
AS valor_liquido
FROM turma
WHERE valor_mensalidade - valor_desconto < 200
Linguagem SQL – DML 103
Resultado:
nome valor_liquido
Turma 2 de Natação 190
Turma 3 de Natação 190
Turma 4 de Natação 180
Estes foram importantes operadores usados na cláusula WHERE, 
amplamente utilizados nas consultas.
4.2.2 Funções agregadas e agrupamento
As funções agregadas transformam os dados de todas as linhas de 
determinado atributo em um único valor, aplicando uma das funções 
matemáticas a seguir:
SUM Soma dos valores de todas as linhas do atributo
AVG Média dos valores de todas as linhas do atributo
MIN Menor valor de todas as linhas do atributo
MAX Maior valor de todas as linhas do atributo
COUNT Número de linhas do atributo
Exemplo 1: Dada a tabela turma, mostrar a soma dos valores das 
mensalidades das turmas cuja modalidade_codigo seja igual a 1.
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
104 Modelagem de banco de dados e SQL
Comando:
SELECT SUM(valor_mensalidade) as total_mensalidade
FROM turma
WHERE modalidade_codigo = 1
Observe o resultado a seguir.
total_mensalidade
800
Exemplo 2: Saber quantas matrículas há atualmente na escola.
Tabela matricula
numero data aluno_cpf turma_codigo
100 12/05/2020 12345678901 10
101 01/12/2021 87654567365 10
102 05/01/2021 98756514522 10
103 31/01/2021 98576524546 20
104 02/11/2020 64514343456 20
105 10/01/2021 98576543656 30
106 20/12/2020 95876756512 30
Comando:
SELECT COUNT(*) AS total_de_matriculas
FROM matricula
Resultado:
total_de_matriculas
7
Agrupamento – GROUP BY
É possível combinar as funções agregadas para fazer agrupamento 
de valores. Para isso, pode-se usar a cláusula GROUP BY para indicar 
por qual atributo deseja-se agrupar.
Linguagem SQL – DML 105
Exemplo: Dada a tabela turma, mostrar a soma dos valores das 
mensalidades para cada modalidade_codigo.
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Comando:
SELECT modalidade_codigo, SUM(valor_mensalidade) 
AS total_mensalidade
FROM turma
GROUP BY modalidade_codigo
Resultado:
modalidade_codigo total_mensalidade
1 800
2 680
Observações:
Nesse resultado, a soma dos valores da mensalidade do código 1 foi 
de R$ 800,00 e do código 2 foi de R$ 680,00.
Cláusula HAVING
A cláusula HAVING funciona como a cláusula WHERE, com a diferen-
ça de que aplica a condição sobre os grupos.
Suponha que no exemplo anterior seja preciso mostrar o total por 
código (grupo), mas somente se esse total for maior do que R$ 700,00, 
por exemplo. Nesse caso, não teria sentido usar a cláusula WHERE, pois 
ela atua sobre as linhas. Para que essa condição seja aplicada sobre os 
grupos, devemos usar a cláusula HAVING.
106 Modelagem de banco de dados e SQL
Exemplo 1: Dada a tabela turma, mostrar a soma dos valores das 
mensalidades para cada modalidade_codigo, mas somente se essa 
soma for maior que R$ 700,00.
Comando:
SELECT modalidade_codigo,SUM(valor_mensalidade) 
AS total_mensalidade
FROM turma
GROUP BY modalidade_codigo
HAVING SUM(valor_mensalidade) > 700
Resultado:
modalidade_codigo total_mensalidade
1 800
Observações:
Nesse resultado, somente foi apresentado o total do código 1, por 
ser maior que R$ 700,00.
4.3 Comandos SQL para consultas avançadas 
Vídeo Até o momento, trabalhamos com a seleção atuando somente so-
bre uma tabela. Porém é comum termos consultas com informações 
de várias tabelas. Nesta seção conheceremos funções mais elabora-
das do comando SQL, que permitem a seleção de atributos de duas 
O vídeo 10 comandos 
essenciais em SQL para 
estudantes, publica-
do pelo canal Bóson 
Treinamentos, apre-
senta uma aula com a 
explicação de diversos 
comandos SQL que com-
plementam os exemplos 
mencionados neste 
capítulo. Vale assistir!
Disponível em: https://
www.youtube.com/
watch?v=64kPRsD22w4. Acesso 
em: 25 maio 2021.
Vídeo
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Linguagem SQL – DML 107
ou mais tabelas. Para isso, verificaremos os relacionamentos entre as 
tabelas e as suas chaves estrangeiras.
4.3.1 Junções
O comando SQL que permite a seleção em duas ou mais tabelas é o 
comando JOIN. Com ele, além de consultarmos atributos de várias ta-
belas, também é possível fazer as ligações entre elas por meio de suas 
chaves primárias e estrangeiras.
A estrutura do comando JOIN é a seguinte:
SELECT tabela_a.atributos, tabela_b.atributos
FROM tabela_a
INNER JOIN tabela_b
ON tabela_a.Key = tabela_b.ForeignKey
Na cláusula SELECT, devem ser colocados os atributos que se de-
seja. Como envolve a consulta a várias tabelas, é necessário qualificar 
o atributo colocando como prefixo o nome da tabela (ou um apelido) 
seguido de um ponto e depois o nome do atributo.
Na cláusula FROM, deve ser colocada a primeira tabela e, na cláusu-
la INNER JOIN, a segunda.
Para se fazer a ligação das duas tabelas (que devem estar relaciona-
das por meio da CONSTRAINT FOREIGN KEY), na cláusula ON, deve-se 
colocar a chave primária da primeira tabela igualada à sua respectiva 
chave estrangeira na segunda tabela.
Exemplo 1: Dadas as tabelas cidade e estado, listar no nome da 
cidade, a sigla e o nome do seu estado.
Tabela cidade
codigo nome estado_sigla
1 Curitiba PR
2 Foz do Iguaçu PR
3 São Paulo SP
4 Porto Alegre RS
108 Modelagem de banco de dados e SQL
Tabela estado
sigla nome
PR Paraná
SC Santa Catarina
SP São Paulo
RS Rio Grande do Sul
Comando:
SELECT cidade.nome as nome_cidade, estado.sigla as 
sigla_estado, estado.nome as nome_estado 
FROM estado
INNER JOIN cidade 
ON estado.sigla=cidade.estado_sigla
Resultado:
nome_cidade sigla_estado nome_estado
Curitiba PR Paraná
Foz do Iguaçu PR Paraná
São Paulo SP São Paulo
Porto Alegre RS Rio Grande do Sul
Exemplo 2: Dadas as tabelas matricula e aluno, listar todas as 
matrículas com os nomes dos alunos matriculados.
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Linguagem SQL – DML 109
Tabela matricula
numero data aluno_cpf turma_codigo
100 12/05/2020 12345678901 10
101 01/12/2021 87654567365 10
102 05/01/2021 98756514522 10
103 31/01/2021 98576524546 20
104 02/11/2020 64514343456 20
105 10/01/2021 98576543656 30
106 20/12/2020 95876756512 30
Comando:
select matricula.numero as numero_matricula, 
matricula.data as data_matricula, 
aluno.nome as nome_aluno
FROM aluno
INNER JOIN matricula
ON aluno.cpf = matricula.aluno_cpf
Resultado:
numero_matricula data_matricula nome_aluno
100 12/05/2020 Joaquim José
101 01/12/2021 Maria Cândida
102 05/01/2021 Ronaldo Antunes
103 31/01/2021 Gabriel Henrique
104 02/11/2020 Gustavo Lacerda
105 10/01/2021 Tiago Alcântara
106 20/12/2020 Célia Justina
Cláusula JOIN com mais de duas tabelas
A cláusula JOIN pode atuar sobre mais de duas tabelas. Nesse caso, 
basta colocarmos a indicação de um INNER JOIN para cada nova tabela, 
como mostra o exemplo a seguir.
Exemplo 1: Dadas as tabelas aluno, matricula e turma, listar 
todas as matrículas com os nomes dos alunos matriculados, suas res-
pectivas turmas com descrição dos dias e horários, bem como o valor 
da mensalidade. Listar somente as matrículas da modalidade Natação.
110 Modelagem de banco de dados e SQL
cpf nome telefone rua numero complemento bairro cep cidade_codigo
12345678901
Joaquim 
José
41-87654568 Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-87476567 Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-98765367 Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-91245678 Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-98754612 Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcântara
11-76542314 Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-98751234 Rua G 123 Beira Rio 55000 4
Tabela matricula
numero data aluno_cpf turma_codigo
100 12/05/2020 12345678901 10
101 01/12/2021 87654567365 10
102 05/01/2021 98756514522 10
103 31/01/2021 98576524546 20
104 02/11/2020 64514343456 20
105 10/01/2021 98576543656 30
106 20/12/2020 95876756512 30
Tabela turma
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Linguagem SQL – DML 111
Comando:
SELECT matricula.numero as numero_matricula, 
matricula.data as data_matricula, 
aluno.nome as nome_aluno,
turma.nome as nome_turma,
turma.descricao_dia_horario as dia_horario,
turma.valor_mensalidade as mensalidade
FROM aluno
INNER JOIN matricula ON aluno.cpf = matricula.aluno_cpf
INNER JOIN turma ON turma.codigo = matricula.turma_codigo
WHERE turma.modalidade_codigo = 1
Resultado:
numero_matricula data_matricula
nome_alu-
no
nome_turma dia_horario mensalidade
100 12/05/2020
Joaquim 
José
Turma 1 de Natação
Seg/Qua/Sex 
das 7h às 8h
210
101 01/12/2021
Maria 
Cândida
Turma 1 de Natação
Seg/Qua/Sex 
das 7h às 8h
210
102 05/01/2021
Ronaldo 
Antunes
Turma 1 de Natação
Seg/Qua/Sex 
das 7h às 8h
210
103 31/01/2021
Gabriel 
Henrique
Turma 2 de Natação
Ter/Qui das 8h 
às 9h
200
104 02/11/2020
Gustavo 
Lacerda
Turma 2 de Natação
Ter/Qui das 8h 
às 9h
200
As junções, por meio do comando JOIN, são extremamente úteis e 
amplamente utilizadas nos acessos às tabelas. Na maioria dos acessos, 
existe a necessidade de buscar dados de duas ou mais tabelas.
4.3.2 Subconsultas
As subconsultas permitem que sejam colocados comandos SELECT 
como condições da cláusula WHERE.
112 Modelagem de banco de dados e SQL
Esse comando atua em conjunto com o operador IN da cláusula 
WHERE, indicando que a condição seráatendida se estiver na lista de 
resultado do comando SELECT utilizado.
Como exemplo, imagine um comando para selecionar o CPF dos 
professores. O comando SELECT seria:
SELECT cpf FROM professor
Esse comando teria como resultado uma lista de CPFs de todos os 
professores da tabela.
Então, caso desejemos listar as turmas cujos CPFs dos professores 
estejam nessa lista, usaremos a estrutura do comando para subconsul-
ta. Observe ela a seguir.
SELECT tabela_a.atributos
FROM tabela_a
WHERE tabela_a.atributo 
IN (SELECT tabela_b.atributo FROM tabela_b)
Exemplo 1: Dadas as tabelas turma e professor, listar todas as 
turmas, mas somente dos professores que estão na tabela professor.
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Linguagem SQL – DML 113
Turma professor
cpf nome data_admissao
72345678901 Cleber Custódio 09/12/2005
56254566711 Suzana Azevedo 03/01/2007
Comando:
SELECT *
FROM turma
WHERE professor_cpf IN (SELECT cpf FROM professor)
Resultado:
codigo nome descricao_dia_horario professor_cpf modalidade_codigo valor_mensalidade valor_desconto
10
Turma 1 de 
Natação
Seg/Qua/Sex das 
7h às 8h
72345678901 1 210 10
20
Turma 2 de 
Natação
Ter/Qui das 8h 
às 9h
56254566711 1 200 10
30
Turma 1 de 
Hidroginástica
Seg/Qua/Sex das 
10h às 11h
56254566711 2 330 20
40
Turma 3 de 
Natação
Seg/Qua/Sex das 
8h às 9h
72345678901 1 200 10
50
Turma 4 de 
Natação
Ter/Qui das 10h 
às 11h
56254566711 1 190 10
60
Turma 2 de 
Hidroginástica
Ter/Qui das 7h 
às 8h
56254566711 2 350 30
Com isso, encerramos as principais variações do comando SE-
LECT capazes de produzir a maioria das consultas que os sistemas 
necessitam.
O vídeo SQL // Dicionário 
do Programador, publi-
cado pelo canal Código 
Fonte TV, apresenta um 
panorama geral sobre a 
linguagem SQL de uma 
forma didática e ilustrati-
va. Não deixe de conferir 
no link a seguir.
Disponível em: https://
www.youtube.com/
watch?v=kMznyI7r2Tc&t=32s. 
Acesso em: 25 maio 2021.
Vídeo
CONSIDERAÇÕES FINAIS
Este capítulo apresentou em detalhes e de maneira bastante prática 
os principais comandos DML e suas variações com o objetivo de manipu-
lar os dados das tabelas do banco de dados.
Por meio dos comandos SQL/DML, foi possível administrar os dados 
com a possibilidade de inclusão de linhas, alteração e exclusão.
Também vimos um dos comandos mais importantes do SQL, o co-
mando SELECT, o qual é extremamente versátil e oferece múltiplas pos-
sibilidades de busca aos dados. Vimos desde a busca básica de dados 
114 Modelagem de banco de dados e SQL
de uma tabela, filtrando linhas com operadores relacionais, matemáticos, 
booleanos, até a opção de agrupamento de atributos, junção de tabelas 
e subconsultas.
Com isso, uma importante abordagem de banco de dados foi cumpri-
da neste capítulo, já que a maioria dos sistemas se utiliza da linguagem 
SQL para acesso aos dados.
ATIVIDADES
1. O que é Data Manipulation Language (DML)?
2. Qual é a estrutura básica do comando SELECT?
3. Quais são os comandos SQL para incluir, alterar e excluir linhas em 
tabelas?
REFERÊNCIAS
DATE, C. J. Introdução a sistemas de banco de dados. 8. ed. Rio de Janeiro: Elsevier, 2003.
ELMASRI, R; NAVATHE, S. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Education 
do Brasil, 2013.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de 
Janeiro: LTC, 2020.
Vídeo
Conceitos avançados de banco de dados 115
5
Conceitos avançados 
de banco de dados
Neste capítulo traremos, em primeiro lugar, os conceitos e 
as estruturas avançadas que podem ser utilizados nos bancos 
de dados. Em seguida, trataremos do funcionamento interno 
que possibilita o controle das transações solicitadas pelos sis-
temas de informações para que elas sejam executadas. Por fim, 
veremos a forma como as linguagens de programação acessam 
o banco.
As estruturas avançadas são as visões, os gatilhos e as 
Stored Procedures, os quais possibilitam a colocação de de-
terminadas rotinas no banco que, originalmente, teriam que 
ser programadas na linguagem de programação com a qual o 
sistema foi implementado. Por isso, muitas dessas rotinas de 
acesso e administração dos dados podem ficar centralizadas 
no próprio banco de dados, possibilitando melhor controle e 
administração dos seus códigos-fontes.
Também conheceremos os mecanismos que o SGBD utili-
za para o controle de execução das transações. Mostraremos 
todos os desafios de se executar centenas e até milhares de 
transações, muitas delas de maneira concorrente e simultânea. 
Esses mecanismos devem ser capazes de fornecer uma execu-
ção segura, correta e que mantenha a integridade dos dados 
sem cometer falhas.
Finalmente, aprenderemos como acessar o banco de dados 
PostgreSql da linguagem de programação Java. Com isso, será 
possível conhecermos o modelo utilizado por muitas empresas 
para se ter um sistema de informação que emprega um banco 
de dados.
116 Modelagem de banco de dados e SQL
5.1 Visões, gatilhos e Stored Procedures 
Vídeo Nesta seção conheceremos algumas estruturas avançadas que 
podem ser utilizadas nos bancos de dados. Elas serão programadas 
internamente no banco de dados, fazendo com que os programado-
res não necessitem escrever essas rotinas nos programas do siste-
ma de informação.
Apresentaremos três estruturas: as visões (views), os gatilhos 
(triggers) e as Stored Procedures (funções ou procedimentos).
5.1.1 Visões (views)
Podemos entender como visão (view) uma nova tabela que não 
existe fisicamente. As visões são criadas com base nas tabelas do 
banco de dados com o objetivo de visualizar um subconjunto de 
seus atributos e suas linhas.
Também chamadas de tabelas derivadas, já que são criadas com 
base em uma tabela original, elas não são novas tabelas, mas sim uma 
maneira de enxergar parte da tabela original. As visões ainda podem 
ser consideradas tabelas virtuais (ELMASRI; NAVATHE, 2013).
A estrutura de criação de uma visão é a seguinte:
CREATE VIEW <nome-da-visao> AS
 --Comando SELECT que se deseja para a visão
Como exemplo, podemos utilizar a tabela aluno do problema da 
escola de natação:
aluno
cpf text PK
nome text
telefone text
rua text
numero text
complemento text
bairro text
cep int
cidade_codigo int FK
Conceitos avançados de banco de dados 117
Digamos que, em determinado momento, as linhas dessa tabela se-
jam as seguintes:
cpf
text
nome
text
telefone
text
rua
text
numero
text
complemento
text
bairro
text
cep
integer
cidade_
codigo
integer
12345678901
Joaquim 
José
41-
87654568
Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-
87476567
Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-
98765367
Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-
91245678
Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-
98754612
Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcantara
11-
76542314
Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-
98751234
Rua G 123 Beira Rio 55000 4
Suponhamos que desejamos ter uma visão somente dos atributos 
cpf e nome e só dos alunos que moram na cidade cujo cidade_codigo 
seja igual a 1.
Poderíamos criar, então, uma visão chamada alunoscuritiba. O 
comando para essa criação seria:
CREATE VIEW alunoscuritiba AS 
SELECT cpf,nome FROM aluno WHERE cidade_codigo = 1 
Desse ponto em diante, podemos considerar que existe uma ta-
bela chamada alunoscuritiba e que é possível emitir qualquer 
comando SQL dela.
Por exemplo,se executarmos o seguinte comando:
SELECT * FROM alunoscuritiba
Teremos como resultado:
118 Modelagem de banco de dados e SQL
cpf
text
nome 
text
12345678901 Joaquim José
87654567365 Maria Cândida
98756514522 Ronaldo Antunes
98576524546 Gabriel Henrique
Nesse resultado foram selecionados somente os atributos cpf e 
nome dos alunos cujo atributo cidade_codigo é igual a 1.
Um detalhe importante sobre as visões é que, como não é criada 
uma tabela, somente temos uma visão diferente (um subconjunto) da 
tabela original e qualquer operação de inclusão, alteração ou exclusão 
de linhas sobre a visão afeta essa tabela, não somente a visão.
5.1.2 Gatilhos (triggers)
Os gatilhos (triggers) são mecanismos utilizados para que, sempre 
que certos eventos ocorrerem e certas condições forem satisfeitas, um 
tipo de ação possa ser tomado (ELMASRI; NAVATHE, 2013). Esses even-
tos e condições referem-se a comandos SQL para a inclusão, alteração 
e exclusão de linhas em tabelas.
Pode ser útil especificarmos uma condição que, se violada, faça com 
que um usuário específico seja notificado. Também é possível que, quan-
do uma condição seja satisfeita, uma ou mais tabelas sejam atualizadas.
Segundo Silberschatz, Korth e Sudarshan (2020, p. 113), um gatilho 
(trigger) “é um comando que o sistema executa automaticamente como 
um efeito colateral de uma modificação no Banco de Dados”.
A criação de um gatilho deve obedecer a dois requisitos, que são:
 • determinar o momento em que ele deve ser executado;
 • determinar as ações que devem ser executadas nele.
A estrutura de criação de gatilhos é a seguinte:
CREATE TRIGGER <nome-do-gatilho>
ON <nome-da-tabela>
[FOR/AFTER/INSTEAD OF] [INSERT/UPDATE/DELETE]
AS
 --Corpo do gatilho
Conceitos avançados de banco de dados 119
Exemplo:
No problema da escola de natação, sempre que um aluno for cadas-
trado, será criada automaticamente uma matrícula para ele na moda-
lidade natação.
Para esse fim, em primeiro lugar, definimos o gatilho no qual, sem-
pre que ocorrer uma inclusão na tabela aluno, uma inclusão também 
será feita na tabela matricula.
Tabela aluno:
cpf
text
nome
text
telefone
text
rua
text
numero
text
complemento
text
bairro
text
cep
integer
cidade_
codigo
integer
12345678901
Joaquim 
José
41-
87654568
Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-
87476567
Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-
98765367
Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-
91245678
Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-
98754612
Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcantara
11-
76542314
Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-
98751234
Rua G 123 Beira Rio 55000 4
Tabela matricula:
numero
integer
data
date
aluno_cpf
text
turma_codigo
integer
100 2020-05-12 12345678901 10
101 2021-12-01 87654567365 10
102 2021-01-05 98756514522 10
103 2021-01-31 98576524546 20
104 2020-11-02 64514343456 20
105 2021-01-10 98576543656 30
106 2020-12-20 95876756512 30
120 Modelagem de banco de dados e SQL
O gatilho terá a seguinte especificação:
CREATE TRIGGER incluiMatricula
ON aluno
FOR INSERT
AS
BEGIN
 DECLARE
 @numero_matricula INTEGER
 @aluno_cpf TEXT
 SELECT MAX(@numero_matricula = numero) 
 FROM matricula
 SELECT @aluno_cpf = aluno_cpf, FROM INSERTED
 INSERT INTO matricula (numero, data, aluno_cpf, 
 turma_codigo)
 VALUES ( @numeromatricula+1,
 GETDATE(),
 @aluno_cpf,
 1)
END
Explicação dos comandos:
Foi criado um gatilho chamado incluiMatricula, o qual, a cada 
comando INSERT na tabela aluno, faz os procedimentos que estão 
abaixo da cláusula BEGIN.
Primeiro, são declaradas duas variáveis que serão utilizadas no cor-
po do gatilho: @numero_matricula e @aluno_cpf. Em seguida, são 
colocados dois comandos SELECT.
No primeiro, é feita uma busca do último número de matrícula ca-
dastrado na tabela matricula e seu conteúdo fica armazenado na va-
riável @numero_matricula. No segundo, é feita a leitura do atributo 
@aluno_cpf do aluno que acabou de ser inserido na tabela aluno.
Conceitos avançados de banco de dados 121
Essas duas variáveis serão necessárias para a inclusão da linha na 
tabela matricula.
Finalmente, o comando INSERT incluirá efetivamente a linha na ta-
bela matricula, somando uma unidade ao número de matrícula lido, 
a data do dia, o CPF do aluno inserido e a turma número 1.
Existem outras maneiras de utilizarmos gatilhos, mas basicamen-
te esse exemplo mostra como um evento em uma tabela (nesse caso, 
uma inclusão na tabela aluno) pode disparar outros eventos em ou-
tras tabelas (nesse caso, uma inclusão na tabela matricula).
É importante ressaltarmos que podem existir diferenças de sintaxes 
dos comandos em cada SGBD. Aconselhamos verificar no manual do 
SGBD com o qual estiver trabalhando qual é a sintaxe correta.
5.1.3 Stored Procedures
As Stored Procedures são funções criadas no próprio banco de da-
dos, as quais podem ser chamadas por meio do comando SELECT.
Segundo Silberschatz, Korth e Sudarshan (2020, p. 108), as Stored 
Procedures “permitem que a lógica do negócio fique armazenada no 
Banco de Dados e seja executada a partir de comandos SQL”.
Primeiro, é necessário construir a Stored Procedure atribuindo um 
nome e armazenando-a no banco de dados. O comando SELECT se re-
ferirá a esse nome no momento da chamada.
A estrutura de criação da Stored Procedure é a seguinte:
CREATE FUNCTION <nome-da-stored-procedure> (parâmetros)
RETURNS <tipo-de-dado>
BEGIN
 DECLARE <variável>
 <comando-select>
 RETURN <variável>
END 
122 Modelagem de banco de dados e SQL
Como exemplo, vamos criar uma Stored Procedure usando a tabela aluno do problema da 
escola de natação:
cpf
text
nome
text
telefone
text
rua
text
numero
text
complemento
text
bairro
text
cep
integer
cidade_
codigo
integer
12345678901
Joaquim 
José
41-
87654568
Rua A 123 Guabirotuba 80000 1
87654567365
Maria 
Cândida
41-
87476567
Rua B 456 Batel 80000 1
98756514522
Ronaldo 
Antunes
41-
98765367
Rua C 123 Xaxim 80000 1
98576524546
Gabriel 
Henrique
41-
91245678
Rua D 456
Jardim das 
Américas
80000 1
64514343456
Gustavo 
Lacerda
41-
98754612
Rua E 123 Itaipu 83000 2
98576543656
Tiago 
Alcantara
11-
76542314
Rua F 456 Itaquera 11000 3
95876756512
Célia 
Justina
55-
98751234
Rua G 123 Beira Rio 55000 4
Exemplo:
Vamos supor que desejamos listar a quantidade de alunos de 
determinada cidade. A Stored Procedure que criaremos receberá como 
parâmetro um código de cidade e devolverá a quantidade de alunos que 
tem esse valor no atributo cidade_codigo.
CREATE FUNCTION 
buscaQtdeAlunosPorCidade(par_cidade_codigo integer)
RETURNS integer
BEGIN
 DECLARE qtde_alunos integer
 SELECT COUNT(*) INTO qtde_alunos
 FROM aluno
 WHERE cidade_codigo = par_cidade_codigo
 RETURN qtde_alunos
END 
Explicação dos comandos:
Foi criada a Stored Procedure buscaQtdeAlunosPorCidade, 
que recebe como parâmetro determinado código de cidade na va-
Conceitos avançados de banco de dados 123
riável par_cidade_codigo, cujo tipo de dado é um integer (valor 
numérico inteiro).
A cláusula RETURNS indica que será devolvido um valor do tipo 
integer para quem chamar a Stored Procedure; a cláusula BEGIN 
indica o início dos comandos; e a cláusula DECLARE cria a variável 
qtde_alunos do tipo integer, que será usada para armazenar a 
quantidade lida.
Em seguida, é colocado o comando SELECT, responsável por buscar 
a quantidade de alunos que atende à condição de que o código da sua 
cidade é igual ao valor recebido como parâmetro. Essa quantidade é 
colocada na variável qtde_alunos.
Finalmente, a cláusula RETURN encerra a Stored Procedure, devol-
vendo essa quantidade de alunos para quem a chamou.
Com a Stored Procedure criada no banco de dados, já podemos 
usar o comando SELECT para chamá-la.
Oseguinte exemplo chama a Stored Procedure buscaQtdeAlu-
nosPorCidade, transmitindo o código de cidade igual a 1:
SELECT cpf, nome FROM aluno
WHERE buscaQtdeAlunosPorCidade(1) > 3 
Teremos como resultado:
cpf
text
nome 
text
12345678901 Joaquim José
87654567365 Maria Cândida
98756514522 Ronaldo Antunes
98576524546 Gabriel Henrique
Nesse resultado, como a cidade com código igual a 1 tem mais de 
três alunos, eles retornaram na seleção.
Esse foi um exemplo de uma Stored Procedure que, embora simples, 
demonstra o potencial desse tipo de estrutura, em que funções neces-
sárias a um sistema de informações podem ser construídas e armazena-
das no banco de dados, a fim de centralizá-las em um local apropriado, 
retirando todos esses procedimentos dos programas da linguagem.
124 Modelagem de banco de dados e SQL
5.2 Processamento de transações 
Vídeo Os bancos de dados precisam ter extremo controle das requisições 
que chegam para serem executadas, sejam elas as solicitações de consul-
ta às tabelas por meio do comando SELECT, sejam elas, principalmente, as 
atualizações por meio dos comandos INSERT, UPDATE e DELETE.
Segundo Elmasri e Navathe (2013, p. 14), “uma transação é uma 
execução qualquer de um programa de usuário em um SGBD”. Enten-
demos como execução qualquer comando advindo de uma linguagem 
de programação com o objetivo de selecionar ou manipular dados do 
banco para servirem a um sistema de informação.
Em um sistema executado na web ou em um aplicativo para dispo-
sitivos móveis é comum ocorrerem acessos simultâneos aos mesmos 
recursos (tabelas, índices, entre outros).
O banco de dados sempre deve permanecer íntegro, ou seja, não 
é aceitável que após as atualizações em tabelas ocorram erros por 
falta de informação, os quais não garantem a integridade referencial. 
Também durante a execução das atualizações não deve haver conflitos 
entre as solicitações, fazendo com que uma delas impeça a execução 
de outra. Para isso, os bancos são dotados de importantes rotinas de 
controle de processamento das transações.
Podemos mencionar como exemplo uma empresa aérea que vende 
passagens por diversos meios on-line. Consideremos que um cliente 
encontre certo voo para a compra de uma passagem e esteja no mo-
mento de escolher um assento. Não é possível permitir que outro clien-
te, no mesmo instante, visualize esse assento como disponível, sob o 
risco de dois clientes escolherem o mesmo assento na mesma fração 
de segundo. Esse seria um problema de falta de integridade nas tabe-
las (ELMASRI; NAVATHE, 2013).
Da mesma forma, o SGBD deve proteger os usuários dos efeitos de 
falhas do sistema, garantindo que todos os dados estejam restaurados 
à situação original, anterior à falha. Suponhamos, nesse caso, que deter-
minado cliente informe os dados de pagamento de uma passagem aé-
rea (número do cartão de crédito) e que a comunicação com a operadora 
de cartão falhe. O SGBD deve garantir que todas as informações relativas 
a essa venda sejam desfeitas, sob o risco de se ter uma passagem indica-
da no sistema como vendida, porém sem o devido pagamento.
Conceitos avançados de banco de dados 125
5.2.1 Propriedades ACID
Um SGBD deve garantir quatro propriedades toda vez que execu-
tar transações, tanto para o acesso concorrente quanto para evitar 
falhas. Essas propriedades são chamadas ACID, uma sigla para repre-
sentar os termos: atômica, consistente, isolada e durável (ELMASRI, 
NAVATHE, 2013). Observemos cada um dos elementos:
A
Na execução de uma transação, devemos garantir 
que todas as ações sejam executadas ou nenhuma 
delas. Os usuários não podem ser penalizados por 
transações incompletas, isto é, não devemos colocar 
nos programas rotinas que tratam da situação de 
uma transação não completar todas as suas ações.
C
Cada transação executada de modo independente 
deve preservar a consistência dos dados, ou seja, não 
podemos permitir que dados inconsistentes sejam 
imputados nas tabelas do banco.
I
D
Uma transação deve ser vista pelo usuário sem con-
siderar o efeito de outra, uma vez que ele não tem 
controle das transações que podem ser executadas 
ao mesmo tempo que a sua. As transações devem 
ser isoladas (ou protegidas) do efeito do plano de 
execução de outras transações.
Muitas vezes o banco de dados, por questão de 
desempenho, divide os passos de uma transação 
para ser executado em vários momentos. Assim, 
o SGBD deve garantir que, uma vez informada ao 
usuário a conclusão da transação, seus efeitos se-
jam persistidos, isto é, mesmo que o sistema falhe 
após essa comunicação, todas as ações devem ser 
refletidas no banco pelo SGBD.
Ok
si
Ok
si
/S
hu
tte
rs
to
ck
Essas propriedades são básicas em todos os SGBDs e não se admite 
que ocorram falhas que possam as ferir.
126 Modelagem de banco de dados e SQL
5.2.2 Controle de concorrência de transações
Uma transação é executada em uma única unidade lógica de 
processamento no banco de dados, e isso inclui operações de sele-
ção, inclusão, alteração ou exclusão de linhas em tabelas (ELMASRI; 
NAVATHE, 2013).
Também é comum que existam acessos concorrentes ao mes-
mo recurso em determinado instante, pois os bancos de dados são 
multiusuários, ou seja, atendem a transações de várias pessoas 
simultaneamente. Para isso, o SGBD deve promover o devido en-
fileiramento das ações, a fim de garantir a integridade dos dados 
e a execução correta da transação, sem prejuízo aos dados e ao 
desempenho da execução.
As transações executadas simultaneamente utilizam duas es-
tratégias, dependendo da arquitetura da máquina na qual o SGBD 
está instalado.
Na primeira estratégia, em um único processador, há uma si-
mulação de execução simultânea (Figura 1), já que as execuções 
das transações são intercaladas. Digamos que no momento (m1) 
iniciem duas transações A e B. A transação A é iniciada e executa 
uma parte de suas operações. No momento em que ela necessita 
aguardar algum recurso (que deve ser lido em um hardware de dis-
co, por exemplo), é suspensa e a transação B iniciada. Da mesma 
forma, esta executa uma parte e é suspensa. A transação A retorna 
até que, em determinado momento (m2), ambas encerram.
Figura 1
Exemplo de transações simultâneas em um único processador
A A
B B
m2m1
Fonte: Elaborada pelo autor com base em Elmasri; Navathe, 2013.
Conceitos avançados de banco de dados 127
Na segunda estratégia, com vários processadores, cada um assume 
uma transação e elas são efetivamente executadas de maneira simul-
tânea (Figura 2).
Figura 2
Exemplo de transações simultâneas com vários processadores
A
Processador 2
Processador 1
B
m2m1
Fonte: Elaborada pelo autor com base em Elmasri; Navathe, 2013.
Nas duas abordagens as transações são executadas, logo, devemos 
adotar a estratégia mais apropriada para os casos específicos.
5.2.3 Problemas no controle de concorrência
Vários problemas podem ocorrer durante a execução simultânea 
de transações, e o controle de concorrência do SGBD deve ser eficaz. 
De acordo com Elmasri e Navathe (2013), os problemas principais são:
Atualização perdida 
 Ocorre quando duas transações tentam acessar o mesmo recurso do banco 
de dados (determinada tabela, por exemplo), de modo que o acesso a certa 
linha da tabela por uma das transações torna o dado incorreto para a se-
gunda. Como exemplo, digamos que a transação A acesse o valor 80 de um 
atributo de determinada linha. No mesmo instante, a transação B faz uma 
atualização desse atributo, alterando o valor para 70. Quando a transação A 
volta a executar e utiliza o valor 80, esse dado já está desatualizado e pode 
causar erros no sistema que a executou.
Atualização temporária (ou leitura suja)
Ocorre quando uma transação atualiza determinado atributo e depois falha. 
Antes do tempo de desfazer essa atualização para o valor original, anterior à 
falha, outra transação utiliza-se do valor que, em última análise, está incorreto 
e será desfeito.
(Continua)
128 Modelagem de banco de dados e SQL
Resumoincorreto
Ocorre quando uma transação está calculando certa função que utiliza uma 
série de itens de diversas tabelas enquanto outras transações estão atuali-
zando esses itens. Ao final da transação, seu resumo estará incorreto.
Leitura não repetitiva
Ocorre quando uma transação faz a leitura de uma linha duas vezes e, no 
intervalo entre as duas leituras, outra transação altera a linha. A transação 
tem dois valores para a mesma linha.
Esses e outros problemas são conhecidos e evitados por meca-
nismos colocados no SGBD. O principal deles é o conceito de pren-
der um recurso (lock) toda vez que for utilizado, para evitar que 
durante a execução da transação outra solicite o mesmo recurso. 
Com isso, a maioria das falhas descritas é evitada.
Os recursos podem ser as tabelas ou as linhas. Assim, quando 
determinada linha é solicitada por uma transação que irá atualizar 
seu valor, essa linha fica bloqueada para que nenhuma outra faça a 
leitura. Ao final de uma transação bem-sucedida, a linha é liberada. 
Nesse espaço de tempo, todas as demais transações que necessi-
tam do mesmo recurso ficam aguardando a finalização.
Certas verificações devem ser feitas diretamente pelos sistemas 
de informação, pois algumas vezes o SGBD não tem o conhecimen-
to de que o recurso deve ou não ser bloqueado. Assim, quando 
uma transação faz uma simples leitura de uma linha da tabela, essa 
linha não é bloqueada. Caso a mesma aplicação, em um momen-
to posterior, decida utilizar esse valor para uma atualização, por 
exemplo, deve verificar se o dado continua com o valor lido e, em 
caso contrário, informar ao usuário que o dado foi atualizado e 
assumiu outro valor nesse intervalo de tempo.
Um problema grave a que os SGBDs têm especial atenção e im-
plementam mecanismos sofisticados de prevenção são os chama-
dos impasses (deadlock). Eles ocorrem quando uma transação T1 
estabelece um bloqueio sobre o recurso A, e a transação T2 sobre o 
recurso B. Agora T1 solicita um bloqueio sobre B, que está bloquea-
Conceitos avançados de banco de dados 129
do, e é enfileirada (fica aguardando). Nesse momento, T2 solicita 
um bloqueio sobre o recurso A, sendo também enfileirada, já que 
ele está bloqueado pela T1. Ou seja, uma transação fica esperando 
a liberação de outra indefinidamente e nunca elas serão liberadas. 
Os SGBDs evitam essa situação, impondo um tempo limite de blo-
queio, e cancelam transações com essas características.
O processamento das transações em um SGBD é a sua principal 
tarefa. O software é considerado robusto se produz poucas falhas, 
que são evitadas com inúmeros algoritmos e estratégias capazes 
de oferecer ao usuário final os resultados desejados em um tempo 
aceitável e sem a incidência de falhas.
O vídeo O que é deadlock 
e como monitorar no SQL 
Server, publicado pelo 
canal DBA PRO, ilustra de 
maneira interessante o 
problema do impasse e 
ensina como evitá-lo.
Disponível em: https://
www.youtube.com/
watch?v=wg7FV61LVGo. Acesso 
em: 28 maio 2021.
Vídeo
5.3 Utilização da linguagem SQL na 
linguagem de programação Java Vídeo
A linguagem SQL tornou-se o padrão de mercado para acesso 
aos bancos de dados. Praticamente todas as linguagens de progra-
mação acessam os bancos usando essa linguagem por meio de um 
conjunto de comandos que possibilita o acesso.
Segundo Ramakrishnan e Gehrke (2008, p. 155), “os aplicativos 
que se baseiam em SGBD para gerenciar dados são executados 
como processos separados que se conectam ao SGBD para intera-
gir com ele”. Com essa conexão estabelecida, é possível solicitar ao 
SGBD a execução de comandos SQL, como SELECT, INSERT, UPDA-
TE e DELETE.
Assim, se por um lado todos os comandos DML (Data 
Manipulation Language) usados para administrar os dados das ta-
belas cadastradas no SGBD podem ser emitidos diretamente no 
console de comandos do banco, os mesmos comandos também 
podem ser colocados nas estruturas de comandos das linguagens 
de programação, de modo que esses dados possam ser manipula-
dos e apresentados por elas nos sistemas de informação.
A Figura 3 mostra um esquema de como os dados transitam 
desde o SGBD até um sistema de informação.
130 Modelagem de banco de dados e SQL
Figura 3
Interação entre o sistema de informação e o banco de dados por meio da linguagem SQL
Tela web ou 
mobile
Recebe os dados 
do banco
Alunos
João
Maria
Carlos
Select * from 
aluno
Tela do sistema
1
4 3
2
Listar alunos
Programa Banco de dados
Linguagem de programação SGBD
Fonte: Elaborada pelo autor.
A seguir, conheceremos a interação entre a linguagem de pro-
gramação Java e o banco de dados PostgreSql. Essa linguagem 
é uma das mais utilizadas no mundo, tanto em aplicações para 
desktop quanto em aplicações na web e em dispositivos móveis. 
Ela dispõe de todos os comandos necessários para os acessos aos 
dados, como a seleção de atributos em tabelas e a manutenção das 
linhas.
5.3.1 Conexão com o banco de 
dados PostgreSql
A linguagem Java dispõe de uma Application Program 
Interface (API) capaz de se conectar e se comunicar com o banco 
de dados PostgreSql. Para isso, o driver do banco de dados deve 
estar instalado no projeto da aplicação, de maneira que os coman-
dos de acesso ao banco possam ser utilizados nos programas. Nor-
malmente isso é feito no ambiente de desenvolvimento integrado 
(Integrated Development Environment – IDE) de programação 
em Java por meio da instalação de uma biblioteca com os drivers 
necessários.
Com o driver instalado, no momento de acessar o banco de da-
dos, é necessário fazer a conexão informando o nome do banco e a 
senha de acesso.
Conceitos avançados de banco de dados 131
O comando para realizar essa conexão é o seguinte:
1. protected Connection con = null;
2.
3. Class.forName(“org.postgresql.Driver”);
4.
5. this.con = DriverManager.getConnection(
“jdbc:postgresql://localhost:5432/EscolaNatacao”,
“postgres”, “root”); 
Explicação dos comandos:
 • Linha 1: definição da variável con que irá receber o objeto da 
conexão.
 • Linha 3: assinalamento de que se trata do banco de dados 
postgresql.
 • Linha 5: comando que faz a conexão com o banco 
EscolaNatacao indicado, passando como parâmetro o usuá-
rio postgres e a senha root.
Dessa forma, o banco estará disponível para a aplicação de qual-
quer comando SQL/DML para a manipulação dos dados de suas tabe-
las. Com a conexão aberta, é possível executar os comandos SELECT, 
INSERT, UPDATE e DELETE.
5.3.2 Comando para seleção em tabelas (SELECT)
O comando SELECT faz a leitura de dados em tabelas do banco. 
No exemplo a seguir, leremos os dados da tabela aluno do banco 
EscolaNatacao, a qual, como vimos no modelo físico de dados, possui 
os seguintes atributos:
aluno
cpf text PK
nome text
telefone text
rua text
numero text
complemento text
bairro text
cep int
cidade_codigo int FK
132 Modelagem de banco de dados e SQL
Vamos supor que desejemos ler todos os alunos que moram na ci-
dade cujo código seja igual a 1.
O comando SELECT para essa leitura seria:
SELECT * FROM aluno WHERE codigo_cidade = 1
Os comandos para fazermos a leitura dos dados dessa tabela na 
linguagem Java seriam os seguintes:
1. import java.sql.Connection;
2. import java.sql.DriverManager;
3. import java.sql.PreparedStatement;
4. import java.sql.ResultSet;
5. import java.sql.SQLException;
6. 
7. int codigoCidade = 1;
8.
9. PreparedStatement p = 
 this.con.prepareStatement(“SELECT * FROM aluno 
 WHERE codigo_cidade = ?”);
10. 
11. p.setInt(1, codigoCidade);
12.
13.ResultSet rs = p.executeQuery();
14.
15.while(rs.next()){
16. String cpf = rs.getString(“cpf”));
17. String nome = rs.getString(“nome”));
18. String telefone = rs.getString(“telefone”));
19. String rua = rs.getString(“rua”));
20. String numero = rs.getString(“numero”));
21. String complemento = rs.getString(“complemento”));
22. String bairro = rs.getString(“bairro “));
23. int cep = rs.getInt(“cep”));
24. int codigo_cidade = rs.getInt(“codigo_cidade”));
25.}
26.rs.close();27.p.close();
28.con.close(); 
Conceitos avançados de banco de dados 133
Explicação dos comandos:
 • Linhas 1 a 5: importações dos pacotes necessários para a execu-
ção dos comandos que serão utilizados.
 • Linha 7: criação da variável Java com o nome codigoCidade, ini-
ciada com o valor 1, que será usada como critério de leitura no 
comando SELECT;
 • Linha 9: principal comando da estrutura, a variável PreparedS-
tatement p receberá o comando SQL propriamente dito, que 
será submetido ao banco para ser executado, nesse caso, o co-
mando SELECT * FROM aluno WHERE codigo_cidade = ?.
 • Linha 11: no comando SELECT foi colocada uma interrogação 
ao final, a qual indica um parâmetro que deve ser preenchido 
com o valor da condição WHERE. Nesse caso, a condição é que o 
codigo_cidade seja igual a um valor determinado. Esse valor é 
o conteúdo da variável Java criada na linha 7, cujo conteúdo foi 
colocado como igual a 1, ou seja, o comando SELECT deseja que 
sejam lidos todos os alunos com o código 1 da cidade.
 • Linha 13: execução efetiva do comando SELECT por meio do co-
mando p.executeQuery(). A lista de alunos selecionados será 
colocada na variável ResultSet rs.
 • Linha 15: comando Java que implementa uma repetição que irá 
percorrer a lista de alunos contida na variável rs.
 • Linhas 16 a 24: para cada linha contendo um aluno, os valores de 
seus atributos serão armazenados em variáveis Java. Foi criada 
uma variável para cada atributo da tabela.
 • Linhas 26 a 28: comandos para fechar as conexões com o banco.
Com isso, podemos usar essas variáveis para o propósito do progra-
ma, seja para apresentá-las em uma tela ou para fazer qualquer tipo de 
operação com seus valores.
5.3.3 Inclusão de linhas em tabelas (INSERT)
O comando INSERT, como vimos, é o SQL responsável pela inclusão 
de linhas em tabelas. Vamos usar o mesmo exemplo da tabela aluno 
do banco EscolaNatacao e inserir um novo aluno na tabela.
O comando INSERT para essa inclusão será:
134 Modelagem de banco de dados e SQL
INSERT INTO 
aluno(cpf,nome,telefone,rua,numero,complemento,
 bairro,cep,cidade_codigo) 
 VALUES (‘12345678901’,’Joaquim José’, 
 ‘41-87654568’,’Rua A’,’123’,’’,
 ‘Batel’,80000,1)
Os comandos na linguagem Java para fazermos essa inclusão são:
1. import java.sql.Connection;
2. import java.sql.DriverManager;
3. import java.sql.PreparedStatement;
4. import java.sql.ResultSet;
5. import java.sql.SQLException;
6. 
7. String cpf = “12345678901”;
8. String nome = “Joaquim José”;
9. String telefone = “41-987654568”;
10. String rua = “Rua A”;
11. String numero = “123”;
12. String complemento = “”;
13. String bairro = “Batel”;
14. int cep = 80000;
15. int codigo_cidade = 1;
16.
17. PreparedStatement p = 
 this.con.prepareStatement(“INSERT INTO 
 aluno(cpf,nome,telefone,rua,numero,complemento,
 bairro,cep,código_cidade)
 VALUES(?,?,?,?,?,?,?,?,?)”);
18.
19. p.setString(1, cpf);
20. p.setString(2, nome);
21. p.setString(3, telefone);
22. p.setString(4, rua);
23. p.setString(5, numero);
24. p.setString(6, complemento);
25. p.setString(7, bairro);
26. p.setInt(8, cep);
27. p.setInt(9, código_cidade);
28.
29. ResultSet rs = p.executeQuery();
30.
31. p.close(); 
32. con.close(); 
Conceitos avançados de banco de dados 135
Explicação dos comandos:
 • Linhas 1 a 5: importações dos pacotes necessários para a execu-
ção dos comandos.
 • Linhas 7 a 15: declarações de variáveis Java com os valores dos 
atributos que desejamos incluir na tabela. Nesse exemplo, os va-
lores estão fixos nas variáveis, porém, na prática, são digitados na 
tela do sistema responsável pela inclusão de um aluno.
 • Linha 17: principal comando da estrutura, a variável Prepa-
redStatement p receberá o comando SQL propriamente dito, 
que será submetido ao banco para ser executado, nesse caso, o 
comando INSERT INTO aluno(cpf, nome, telefone, rua, 
numero, complemento, bairro, cep, código_cidade)
VALUES(?,?,?,?,?,?,?,?,?).
 • Linhas 19 a 27: no comando INSERT foram colocadas interroga-
ções no lugar dos conteúdos dos atributos, as quais indicam um 
parâmetro que deve ser preenchido com os valores de cada atri-
buto no comando. Nesse caso, nessas linhas são colocadas, em 
cada um dos atributos, as variáveis que receberam esses valores.
 • Linha 29: execução do comando INSERT por meio do comando 
p.executeQuery(). Esse é o momento que a linha é efetiva-
mente incluída na tabela.
 • Linhas 31 e 32: comandos para fechar as conexões com o banco.
Vimos em detalhes os comandos na linguagem Java para se fazer a 
inclusão de linhas em uma tabela.
5.3.4 Alteração de linhas em tabelas (UPDATE)
O comando UPDATE, como vimos, é o SQL responsável pela alte-
ração de linhas em tabelas. Vamos usar o mesmo exemplo da tabela 
aluno do banco EscolaNatacao e alterar os atributos de um aluno 
na tabela.
Digamos que desejemos alterar o nome do aluno cujo CPF é 
98576524546’ para Gabriel Henrique Cardoso.
O comando UPDATE para essa alteração seria:
UPDATE aluno SET nome = ’Gabriel Henrique Cardoso’
 WHERE cpf = ‘98576524546’
136 Modelagem de banco de dados e SQL
Os comandos na linguagem Java para fazermos essa alteração 
seriam:
1. import java.sql.Connection;
2. import java.sql.DriverManager;
3. import java.sql.PreparedStatement;
4. import java.sql.ResultSet;
5. import java.sql.SQLException;
6. 
7. String cpf = “98576524546’”;
8. String nome = “ Gabriel Henrique Cardoso “;
9.
10. PreparedStatement p = 
 this.con.prepareStatement(“UPDATE aluno SET nome = ?
 WHERE cpf = ?”);
11.
12. p.setString(1, nome);
13. p.setString(2, cpf);
14.
15. p.executeUpdate();
16.
17. p.close(); 
18. con.close(); 
Explicação dos comandos:
 • Linhas 1 a 5: importações dos pacotes necessários para a execu-
ção dos comandos.
 • Linhas 7 e 8: declarações de variáveis Java com os valores dos atri-
butos que desejamos buscar e alterar na tabela. Nesse exemplo, 
os valores estão fixos nas variáveis, porém, na prática, são digita-
dos na tela do sistema responsável pela alteração de um aluno.
 • Linha 10: principal comando da estrutura, a variável Prepa-
redStatement p receberá o comando SQL propriamente dito, 
que será submetido ao banco para ser executado, nesse caso, o 
comando UPDATE aluno SET nome = ? WHERE cpf = ?.
 • Linha 12: no comando UPDATE foi colocada uma interrogação 
no lugar do conteúdo do atributo nome, a qual indica um parâ-
metro que deve ser preenchido com o valor do atributo colo-
cado na linha 8.
 • Linha 13: o mesmo ocorre com a condição WHERE, em que foi co-
locada uma interrogação no lugar do conteúdo do atributo cpf. 
Conceitos avançados de banco de dados 137
Essa notação é um parâmetro que deve ser preenchido com o 
valor do atributo colocado na linha 7.
 • Linha 15: execução do comando UPDATE por meio do comando 
p.executeUpdate(). Esse é o momento que a linha é efetiva-
mente alterada na tabela.
 • Linhas 17 e 18: comandos para fechar as conexões com o banco.
Vimos em detalhes os comandos na linguagem Java para se fazer a 
alteração de linhas em uma tabela.
5.3.5 Exclusão de linhas em tabelas (DELETE)
O comando DELETE, como vimos, é o SQL responsável pela exclusão 
de linhas em tabelas. Vamos usar o mesmo exemplo da tabela aluno 
do banco EscolaNatacao e excluir uma linha da tabela.
Digamos que desejemos excluir o aluno cujo CPF é 98576524546’.
O comando DELETE para essa exclusão seria:
DELETE FROM aluno
 WHERE cpf = ‘98576524546’’
Os comandos na linguagem Java para fazermos essa exclusão 
seriam:
1. import java.sql.Connection;
2. import java.sql.DriverManager;
3. import java.sql.PreparedStatement;
4. import java.sql.ResultSet;
5. import java.sql.SQLException;
6. 
7. String cpf = “98576524546’”;
8.
9. PreparedStatement p = 
 this.con.prepareStatement(“DELETE FROM aluno 
 WHERE cpf = ?”);
10.
11. p.setString(1, cpf);
12.13. p.executeUpdate();
14.
15. p.close(); 
16. con.close(); 
138 Modelagem de banco de dados e SQL
Explicação dos comandos:
 • Linhas 1 a 5: importação dos pacotes necessários para a execu-
ção dos comandos.
 • Linha 7: declaração de variável Java com o valor do atributo que 
desejamos buscar para excluir na tabela. Nesse exemplo, o valor 
está fixo nas variáveis, porém, na prática, é digitado na tela do 
sistema responsável pela exclusão de um aluno.
 • Linha 9: principal comando da estrutura, a variável PreparedS-
tatement p receberá o comando SQL propriamente dito, que 
será submetido ao banco para ser executado, nesse caso, o co-
mando DELETE FROM aluno WHERE cpf = ?.
 • Linha 11: no comando DELETE foi colocada uma interrogação no 
lugar do conteúdo do atributo cpf, a qual indica um parâmetro que 
deve ser preenchido com o valor do atributo inserido na linha 7.
 • Linha 13: execução do comando UPDATE por meio do comando 
p.executeUpdate(). Esse é o momento que a linha é efetiva-
mente excluída da tabela.
 • Linhas 15 e 16: comandos para fechar as conexões com o banco.
Com isso, conhecemos a maneira de se utilizar comandos SQL/
DML dentro da linguagem de programação Java. Essas estruturas são 
amplamente utilizadas em sistemas de informação programados com 
essa linguagem. Embora existam diversas estruturas com o mesmo 
fim e muitas linguagens, a estrutura vista em Java é uma das mais 
empregadas no mercado.
CONSIDERAÇÕES FINAIS
Neste capítulo detalhamos conceitos avançados utilizados nos ban-
cos de dados, bem como acerca das ferramentas disponíveis ao usuário, 
possibilitando que muitas rotinas de manipulação de dados sejam feitas 
no próprio banco, em vez de serem colocadas nos programas do sistema.
Também mostramos o conceito e o funcionamento de transações que 
chegam ao banco para serem executadas e o controle que devemos ter 
para garantir uma execução segura e sem falhas, principalmente pela falta 
de integridade dos dados.
Por fim, conhecemos uma estrutura modelo para acesso ao banco de 
dados PostgreSql com a linguagem de programação Java, modelo ampla-
mente utilizado pelo mercado nos sistemas de informação.
A obra PostgreSQL: guia 
do programador apre-
senta diversos exemplos 
de acesso ao banco de 
dados PostgreSql não 
somente com a lingua-
gem Java, mas também 
com outras linguagens 
de programação. 
Ainda mostra diversos 
exemplos de criação de 
visões, gatilhos e Stored 
Procedures nesse SGBD.
MILANI, A. São Paulo: Novatec, 2008.
Livro
Conceitos avançados de banco de dados 139
ATIVIDADES
1. O que são Stored Procedures e qual é sua função?
2. Cite quatro problemas no controle de concorrência de transações e 
explique-os.
3. Quais são as quatro propriedades ACID de uma transação? Comente 
cada uma delas.
REFERÊNCIAS
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. 6. ed. São Paulo: Pearson 
Education do Brasil, 2013.
RAMAKRISHNAN, R.; GEHRKE, J. Sistemas de gerenciamento de banco de dados. 3. ed. São 
Paulo: McGraw-Hill, 2008.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 7. ed. Rio de 
Janeiro: LTC, 2020.
Vídeo
140 Modelagem de banco de dados e SQL
Resolução das atividades 
1 Conceitos gerais de modelagem de banco
1. O que são os sistemas gerenciadores de banco de dados (SGBD)? 
Comente.
SGBD são softwares encarregados de administrar e controlar as 
operações sobre os bancos de dados. 
2. Quais são as vantagens da utilização de um banco de dados? 
Cite cinco.
Controle de redundância, restrição a acesso não autorizado, acesso 
eficiente, controle de backup e recuperação, múltiplas visões ao 
usuário, restrições de integridade.
3. Conceitue tabela, linha e atributo.
Tabela: sinônimo de relação ou entidade, representa um conjunto de 
elementos do mundo real, distinguíveis uns dos outros, cujos dados 
necessitam ser armazenados no banco de dados. Cada linha da tabela 
representa um determinado elemento. Em uma escola de natação, a 
relação Alunos é um exemplo de tabela.
Linha: sinônimo de registro ou tupla, corresponde a todos os dados 
de um determinado elemento da tabela. As informações do aluno 
Joaquim José (CPF, nome, endereço, carteira de motorista) são um 
exemplo de linha.
Atributo: sinônimo de campo, propriedade ou coluna, corresponde a 
um determinado valor de todas as linhas da tabela. O nome de um 
aluno é um exemplo de atributo.
2 Modelo relacional
1. O que é a normalização de tabelas?
Normalização é um processo de análise das tabelas e da aplicação 
de técnicas com o objetivo de organizar as tabelas antes de seu 
armazenamento no banco de dados, a fim de evitar anomalias de 
inserção, exclusão e atualização.
2. Qual é a regra da primeira forma normal?
Uma tabela está na 1FN se, e somente se, em todo valor válido dessa 
tabela, cada linha contém exatamente um valor para cada atributo.
3. Qual é o conceito de relacionamento entre as tabelas de um 
banco de dados?
Relacionamento é uma associação entre entidades.
Resolução das atividades 141
3 Linguagem SQL - DDL
1. Qual é a finalidade de se criar um modelo físico de dados? 
Comente.
O modelo físico trata de questões físicas de armazenamento, 
preparando as tabelas para que sejam cadastradas no SGBD.
2. O que são chaves estrangeiras? Explique.
A chave estrangeira em uma tabela deve corresponder à chave primária 
de outra a que a tabela esteja relacionada. Os atributos devem ter a 
mesma característica e conteúdo, porém podem ter nomes diferentes. 
A chave estrangeira produz uma condição conhecida como restrição 
de integridade, que impede a entrada de informações incorretas no 
banco.
3. O que é a linguagem SQL? Comente.
Structured Query Language (SQL), ou linguagem de consulta 
estruturada, tem finalidade exclusiva de fazer todos os acessos aos 
dados, como uma ponte ligando a linguagem de programação aos 
bancos de dados.
4 Linguagem SQL – DML
1. O que é Data Manipulation Language (DML)? Comente.
Data Manipulation Language (DML) é uma parte da linguagem SQL 
encarregada de manipular os dados, seja para consultar, seja para 
incluir, alterar ou excluir dados no banco de dados.
2. Qual é a estrutura básica do comando SELECT? 
A estrutura básica do comando SELECT é:
SELECT atributos
FROM tabela
3. Quais são os comandos SQL para incluir, alterar e excluir linhas 
em tabelas?
Os comandos SQL são: INSERT (incluir), UPDATE (alterar) e DELETE 
(excluir).
5 Conceitos avançados de banco de dados
1. O que são Stored Procedures e qual é sua função?
Stored Procedures são funções que podem ser criadas no próprio 
banco de dados com o intuito de permitir que a lógica do negócio 
fique armazenada no banco de dados e seja executada por meio de 
comandos SQL.
142 Modelagem de banco de dados e SQL
2. Cite quatro problemas no controle de concorrência de 
transações e explique-os.
O problema da atualização perdida ocorre quando duas transações 
tentam acessar o mesmo recurso do banco de dados (determinada 
tabela, por exemplo), de modo que o acesso a certa linha da tabela por 
uma das transações torna o dado incorreto para a segunda.
O problema da atualização temporária (ou leitura suja) ocorre quando 
uma transação atualiza determinado atributo e depois falha. Antes do 
tempo de desfazer essa atualização para o valor original, anterior à 
falha, outra transação utiliza-se do valor que, em última análise, está 
incorreto e será desfeito.
O problema do resumo incorreto ocorre quando uma transação está 
calculando certa função que utiliza uma série de itens de diversas 
tabelas enquanto outras transações estão atualizando esses itens. Ao 
final da transação, seu resumo estará incorreto.
O problema da leitura não repetitiva ocorre quando uma transação faz 
a leitura de uma linha duas vezes e, no intervalo entre as duas leituras, 
outra altera a linha. A transação tem dois valores para a mesma linha.
3. Quais são as quatro propriedades ACID de uma transação? 
Comente cada uma delas.
 • Atômica: na execução de uma transação, devemosgarantir que 
todas as ações sejam executadas ou nenhuma delas. Os usuários 
não podem ser penalizados por transações incompletas, ou seja, 
não devemos colocar em seus programas rotinas que tratam da 
situação de uma transação não completar todas as suas ações.
 • Consistente: cada transação executada de modo independente 
deve preservar a consistência dos dados, ou seja, não é possível 
permitir que dados inconsistentes sejam imputados nas tabelas 
do banco.
 • Isolada: uma transação deve ser vista pelo usuário sem consi-
derar o efeito de outra, uma vez que ele não tem controle das 
transações que podem ser executadas ao mesmo tempo que a 
sua. As transações devem ser isoladas (ou protegidas) do efeito 
do plano de execução de outras transações.
 • Durável: muitas vezes o banco de dados, por questão de desem-
penho, divide os passos de uma transação para ser executado 
em vários momentos. Assim, o SGBD deve garantir que, uma vez 
informado ao usuário que a transação foi concluída, seus efeitos 
persistam, isto é, mesmo que o sistema falhe após essa comuni-
cação, o SGBD deve garantir que todas as ações sejam refletidas 
no banco.
M
O
D
E
L
A
G
E
M
 D
E
 B
A
N
C
O
 D
E
 D
A
D
O
S
 E
 S
Q
L
Ja
im
e
 W
o
jc
ie
c
h
o
w
s
k
i
Código Logístico
I000034
Fundação Biblioteca Nacional
ISBN 978-65-5821-037-5
9 7 8 6 5 5 8 2 1 0 3 7 5
	Página em branco
	Página em branco