Prévia do material em texto

BANCO DE DADOS
CURSOS DE GRADUAÇÃO – EAD
Banco de Dados – Prof. Dr. Alexandre Leite Rangel, Profª Claudia Vicci Amadeu, Prof. Ms. Thiago Wellington Joazeiro de Almei-
da e Prof. Ms. Geraldo Henrique Neto 
Meu nome é Alexandre Leite Rangel. Sou doutor e mestre pela Escola de Enfermagem de Ribeirão 
Preto da Universidade de São Paulo (EERP/USP), na área de Informática na Saúde e na Enfermagem. 
Minha formação é em Análise de Sistemas, com especialização na mesma área. Leciono a disciplina 
Banco de Dados nos cursos de Sistemas de Informação e Licenciatura em Computação. Sou também 
analista de sistemas do Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto da USP.
e-mail: alexandrerangel@claretiano.edu.br
Meu nome é Claudia Vicci Amadeu. Sou especialista em Análise de Sistemas com ênfase em Arquite-
tura Cliente-Servidor pela Pontifícia Universidade Católica de Campinas (PUC-Campinas) e graduada 
em Análise de Sistemas. Atuo como docente no curso de Ciência da Computação da Universidade de 
Franca (Unifran) e ministro as disciplinas de Modelagem de Sistemas, Banco de Dados e Engenharia de 
Software. 
e-mail: claudia_vicci@yahoo.com.br
Meu nome é Geraldo Henrique Neto. Sou mestre pela Faculdade de Medicina de Ribeirão Preto da 
Universidade de São Paulo (FMRP/USP), na área de Informática Médica. Minha formação é em Ciência 
da Computação, com especialização em Desenvolvimento Web pela Universidade Federal de São Car-
los (UFSCar). Leciono diversas disciplinas relacionadas a Banco de Dados em cursos de graduação da 
FATEC Mococa, FAFRAM e UNIP de Ribeirão Preto. Sou também Consultor em Tecnologia da Informa-
ção em Ribeirão Preto e região.
e-mail: geraldohenrique@usp.br
Meu nome é Thiago Almeida. Sou mestre em Física Aplicada em Medicina e Biologia pela Universida-
de de São Paulo, especialista em Projetos de Circuitos Integrados Digitais pelo Instituto Eldorado e 
graduado em Engenharia da Computação pela Universidade Federal de Itajubá-MG. Sou professor no 
Claretiano – Centro Universitário nos cursos EaD de Computação.
e-mail: thiagoalmeida@claretiano.edu.br
Fazemos parte do Claretiano - Rede de Educação
BANCO DE DADOS
Alexandre Leite Rangel
Claudia Vicci Amadeu
Geraldo Henrique Neto
Thiago Wellington Joazeiro de Almeida
Batatais
Claretiano
2015
Fazemos parte do Claretiano - Rede de Educação
© Ação Educacional Claretiana, 2011 – Batatais (SP)
Versão: ago./2015
 
005.75 B161 
 
 Banco de dados / Alexandre Leite Rangel ... [et al.] – Batatais, SP : Claretiano, 2015. 
 278 p. 
 
 ISBN: 978-85-8377-386-3 
 
 1. Introdução aos Sistemas de Banco de Dados. 2. Modelo Entidade-Relacionamento. 
 3. Modelo de Dados Relacional. 4. SQL. 5. Álgebra Relacional. 6. Noções básicas 
 sobre Gerenciamento de Transação. 7. Controle de Concorrência. 8. Recuperação. 
 9. Segurança e distribuição de dados. I. Rangel, Alexandre Leite. II. Amadeu, Claudia 
 Vicci. III. Henrique Neto, Geraldo. IV. Almeida, Thiago Wellington Joazeiro de. V. Banco 
 de dados. 
 
 
 
 CDD 005.75 
 
 
 
 
 
 
 
Corpo Técnico Editorial do Material Didático Mediacional
Coordenador de Material Didático Mediacional: J. Alves
Preparação 
Aline de Fátima Guedes
Camila Maria Nardi Matos 
Carolina de Andrade Baviera
Cátia Aparecida Ribeiro
Dandara Louise Vieira Matavelli
Elaine Aparecida de Lima Moraes
Josiane Marchiori Martins
Lidiane Maria Magalini
Luciana A. Mani Adami
Luciana dos Santos Sançana de Melo
Patrícia Alves Veronez Montera
Raquel Baptista Meneses Frata
Rosemeire Cristina Astolphi Buzzelli
Simone Rodrigues de Oliveira
Revisão
Cecília Beatriz Alves Teixeira
Eduardo Henrique Marinheiro
Felipe Aleixo
Filipi Andrade de Deus Silveira
Juliana Biggi
Paulo Roberto F. M. Sposati Ortiz
Rafael Antonio Morotti
Rodrigo Ferreira Daverni
Sônia Galindo Melo
Talita Cristina Bartolomeu
Vanessa Vergani Machado
Projeto gráfico, diagramação e capa 
Eduardo de Oliveira Azevedo
Joice Cristina Micai 
Lúcia Maria de Sousa Ferrão
Luis Antônio Guimarães Toloi 
Raphael Fantacini de Oliveira
Tamires Botta Murakami de Souza
Wagner Segato dos Santos
Todos os direitos reservados. É proibida a reprodução, a transmissão total ou parcial por qualquer forma 
e/ou qualquer meio (eletrônico ou mecânico, incluindo fotocópia, gravação e distribuição na web), ou o 
arquivamento em qualquer sistema de banco de dados sem a permissão por escrito do autor e da Ação 
Educacional Claretiana.
Claretiano - Centro Universitário
Rua Dom Bosco, 466 - Bairro: Castelo – Batatais SP – CEP 14.300-000
cead@claretiano.edu.br
Fone: (16) 3660-1777 – Fax: (16) 3660-1780 – 0800 941 0006
www.claretianobt.com.br
SUMÁRIO
CADERNO DE REFERÊNCIA DE CONTEÚDO
1 INTRODUÇÃO ..............................................................................................................................................9
2 ORIENTAÇÕES PARA ESTUDO .....................................................................................................................10
3 E-REFERÊNCIA .............................................................................................................................................20
4 REFERÊNCIA BIBLIOGRÁFICA ....................................................................................................................20
UNIDADE 1 – INTRODUÇÃO AOS SISTEMAS DE BANCO DE DADOS
1 OBJETIVOS ...................................................................................................................................................21
2 CONTEÚDOS ................................................................................................................................................21
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................21
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................23
5 DADOS VERSUS INFORMAÇÕES .................................................................................................................24
6 SISTEMAS DE ARQUIVOS VERSUS SGBDS .................................................................................................27
7 DADOS EM SGBDS: DESCRIÇÃO E ARMAZENAMENTO ............................................................................31
8 ARQUITETURA EM UM SGBD .....................................................................................................................45
9 CONSULTAS EM UM SGBD ..........................................................................................................................48
10 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................49
11 CONSIDERAÇÕES ........................................................................................................................................50
12 E-REFERÊNCIAS ...........................................................................................................................................50
13 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................50
UNIDADE 2 – MODELAGEM DOS DADOS UTILIZANDO O MODELO ENTIDADE-RELACIONAMENTO
1 OBJETIVOS ...................................................................................................................................................51
2 CONTEÚDOS................................................................................................................................................51
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................51
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................52
5 MODELOS DE BANCO DE DADOS ...............................................................................................................52
6 DEFINIÇÕES DE OBJETOS DO MODELO ENTIDADE-RELACIONAMENTO (MER) .....................................54
7 CARACTERÍSTICAS ADICIONAIS DO MODELO ENTIDADE-RELACIONAMENTO ......................................64
8 PROJETO CONCEITUAL DE BANCO DE DADOS COM O MODELO ENTIDADE-RELACIONAMENTO........64
9 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) ...................................................................................66
10 EXEMPLOS DE DIAGRAMAS ENTIDADE-RELACIONAMENTO ...................................................................67
11 MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER) ...................................................................69
12 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................72
13 CONSIDERAÇÕES .........................................................................................................................................74
14 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................74
UNIDADE 3 – MODELO DE DADOS RELACIONAL
1 OBJETIVO .....................................................................................................................................................75
2 CONTEÚDOS ................................................................................................................................................75
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................75
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................76
5 MODELO RELACIONAL ................................................................................................................................76
6 NOTAÇÃO DO MODELO RELACIONAL ........................................................................................................81
7 ATRIBUTOS-CHAVE DE UMA RELAÇÃO ......................................................................................................82
8 ESQUEMA DE BANCO DE DADOS RELACIONAL ........................................................................................85
9 RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES ....................................................................................86
10 OPERADORES DO CONJUNTO RELACIONAL .............................................................................................87
11 RELACIONAMENTOS DENTRO DO BANCO DE DADOS RELACIONAL .......................................................93
12 PROJETO LÓGICO DE BANCO DE DADOS: MAPEAMENTO DO MODELO ENTIDADE-RELACIONAMENTO 
PARA O MODELO RELACIONAL ..................................................................................................................98
13 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................105
14 CONSIDERAÇÕES ........................................................................................................................................106
15 E-REFERÊNCIAS ...........................................................................................................................................107
16 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................107
UNIDADE 4 – SQL – UMA LINGUAGEM DE CONSULTA
1 OBJETIVOS ...................................................................................................................................................109
2 CONTEÚDOS ................................................................................................................................................109
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................109
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................110
5 LINGUAGEM SQL .........................................................................................................................................110
6 HISTÓRICO DO POSTGRESQL ......................................................................................................................112
7 PRINCIPAIS OPERAÇÕES PARA MANIPULAÇÃO DE DADOS .....................................................................112
8 ESTRUTURA DA LINGUAGEM SQL – DML ..................................................................................................128
9 ESTRUTURA DA LINGUAGEM SQL – DDL ...................................................................................................184
10 INTRODUÇÃO ÀS VISÕES ...........................................................................................................................188
11 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................192
12 CONSIDERAÇÕES .........................................................................................................................................194
13 E-REFERÊNCIA .............................................................................................................................................194
14 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................194
UNIDADE 5 – NORMALIZAÇÃO E DESEMPENHO EM SISTEMA DE BANCO DE DADOS 
RELACIONAL
1 OBJETIVOS ...................................................................................................................................................195
2 CONTEÚDOS ................................................................................................................................................195
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................195
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................196
5 DEPENDÊNCIA FUNCIONAL DE UM BANCO DE DADOS RELACIONAL ....................................................196
6 NORMALIZAÇÃO ..........................................................................................................................................198
7 PROCESSO DE NORMALIZAÇÃO .................................................................................................................200
8 FATORES A SEREM CONSIDERADOS NO PROJETO FÍSICO DE BANCO DE DADOS RELACIONAL ...........209
9 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................214
10 CONSIDERAÇÕES ........................................................................................................................................215
11 E-REFERÊNCIA .............................................................................................................................................215
12 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................................215UNIDADE 6 – GERENCIAMENTO DE TRANSAÇÕES E CONTROLE DE CONCORRÊNCIA
1 OBJETIVOS ...................................................................................................................................................217
2 CONTEÚDOS ................................................................................................................................................217
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................217
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................218
5 POR QUE GERENCIAR UMA TRANSAÇÃO? ................................................................................................218
6 TRANSAÇÃO E IMPORTÂNCIA DO CONTROLE DE CONCORRÊNCIA ........................................................220
7 PROPRIEDADES DAS TRANSAÇÕES – ACID ................................................................................................222
8 FALHAS E A NECESSIDADE DE UMA RECUPERAÇÃO ................................................................................223
9 ESTADOS DE UMA TRANSAÇÃO .................................................................................................................224
10 PLANOS DE EXECUÇÃO DE TRANSAÇÕES ..................................................................................................224
11 TÉCNICAS DE BLOQUEIO PARA CONTROLE DE CONCORRÊNCIA ............................................................225
12 REGRAS PARA O ESQUEMA DE BLOQUEIO COMPARTILHADO/EXCLUSIVO ...........................................226
13 DEADLOCK....................................................................................................................................................226
14 TIMESTAMPS ...............................................................................................................................................227
15 CONTROLE DE CONCORRÊNCIA DE VALIDAÇÃO (OTIMISTA) ..................................................................228
16 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................228
17 CONSIDERAÇÕES .........................................................................................................................................229
18 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................229
UNIDADE 7 – RECUPERAÇÃO DE BANCO DE DADOS E SEGURANÇA 231
1 OBJETIVOS ...................................................................................................................................................231
2 CONTEÚDOS ................................................................................................................................................231
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................232
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................232
5 FUNÇÕES DE UM DBA ................................................................................................................................232
6 BACKUP E RECUPERAÇÃO...........................................................................................................................233
7 CACHING DE DISCO .....................................................................................................................................234
8 TRANSAÇÕES: CHECKPOINTS, ROLLBACK .................................................................................................234
9 RECUPERAÇÃO BASEADA NA ATUALIZAÇÃO ADIADA ..............................................................................235
10 RECUPERAÇÃO BASEADA NA ATUALIZAÇÃO IMEDIATA...........................................................................235
11 PAGINAÇÃO SHADOW.................................................................................................................................236
12 RECUPERAÇÃO DE FALHAS EM BANCOS DE DADOS MÚLTIPLOS ............................................................236
13 RECUPERAÇÃO DE FALHAS POR MOTIVOS DE CATÁSTROFE ...................................................................236
14 SEGURANÇA DE DADOS ..............................................................................................................................237
15 MEDIDAS DE PROTEÇÃO AOS BANCOS DE DADOS...................................................................................240
16 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................241
17 CONSIDERAÇÕES .........................................................................................................................................242
18 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................242
UNIDADE 8 – BANCO DE DADOS DISTRIBUÍDOS
1 OBJETIVOS ...................................................................................................................................................243
2 CONTEÚDOS ................................................................................................................................................243
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................243
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................244
5 POR QUE USAR BANCOS DE DADOS DISTRIBUÍDOS?...............................................................................246
6 PROCESSAMENTO DISTRIBUÍDO E BANCO DE DADOS DISTRIBUÍDO .....................................................248
7 CLASSIFICAÇÃO DOS SGBDDS ....................................................................................................................252
8 CONSULTAS EM BANCO DE DADOS DISTRIBUÍDO ....................................................................................253
9 TRANSAÇÕES DISTRIBUÍDAS ......................................................................................................................253
10 CONTROLE DE CONCORRÊNCIA E DE RECUPERAÇÃO ..............................................................................254
11 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................255
12 CONSIDERAÇÕES FINAIS .............................................................................................................................255
13 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................256
APÊNDICE 1 .....................................................................................................................................................257
APÊNDICE 2 .....................................................................................................................................................270
Claretiano - Centro Universitário
CRC
Caderno de 
Referência de 
Conteúdo
Ementa ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Introdução aos Sistemas de Banco de Dados. Modelo Entidade-Relacionamento. Modelo de Dados Relacional. SQL. 
Álgebra Relacional. Noções básicas sobre Gerenciamento de Transação, Controle de Concorrência, Recuperação, 
Segurança e Distribuição de Dados.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1. INTRODUÇÃO
Seja bem-vindo!
Você iniciará o estudo de Bancode Dados, a qual fornecerá a você conteúdos específicos 
para a projeção de bancos de dados. Para facilitar sua compreensão, o conteúdo foi segmentado 
em oito unidades. 
Além disso, você terá a oportunidade de conhecer conceitos fundamentais para a elabora-
ção e a construção de bancos de dados, como o projeto conceitual, o projeto lógico e o projeto 
físico, e a manipulação e a manutenção de bancos de dados por meio de linguagem SQL básica 
e avançada.
Outro aspecto relevante para o desenvolvimento de banco de dados bem estruturados é a 
aplicação da normalização, tema estritamente relacionado ao desempenho (acesso aos dados). 
Com o conteúdo estudado, além de criar bancos de dados estruturados, você saberá aplicar as 
fases de normalização até a 4ª forma normal.
Além disso, é imprescindível que você, como administrador de bancos de dados, acompa-
nhe a evolução dos Sistemas Gerenciadores de Bancos de Dados (SGBDs), não tomando apenas 
esta obra como fonte de aprendizagem. É importante que você complemente sua formação 
© Banco de Dados10
consultando outras fontes, como livros, revistas e páginas web. Não se esqueça de compartilhar 
suas experiências por meio dos Fóruns e da Lista na Sala de Aula Virtual, pois, assim, você não só 
contribuirá para o aprendizado de outras pessoas, mas também solidificará seu conhecimento.
Após essa introdução aos conceitos principais, apresentaremos, a seguir, no Tópico Orien-
tações para estudo, algumas orientações de caráter motivacional, dicas e estratégias de apren-
dizagem que poderão facilitar seu estudo.
2. ORIENTAÇÕES PARA ESTUDO
Abordagem Geral
Prof. Ms. Geraldo Henrique Neto
Neste tópico, apresenta-se uma visão geral do que será estudado. Aqui, você entrará em 
contato com os assuntos principais deste conteúdo de forma breve e geral e terá a oportunidade 
de aprofundar essas questões no estudo de cada unidade. Desse modo, essa Abordagem Geral 
visa fornecer-lhe o conhecimento básico necessário a partir do qual você possa construir um 
referencial teórico com base sólida – científica e cultural – para que, no futuro exercício de sua 
profissão, você a exerça com competência cognitiva, ética e responsabilidade social.
Banco de Dados tem como objetivo principal sua iniciação na elaboração e na construção 
de bancos de dados, no qual você conhecerá as fases constituintes de um projeto bem estrutu-
rado de banco de dados, como também terá contato com a linguagem SQL.
Antes de iniciar o estudo sobre banco de dados, é importante definir o que é um banco 
de dados. Pois bem, o banco de dados se constitui em um sistema de armazenamento de da-
dos cujo objetivo é registrar e salvaguardar informações relevantes que poderão ser acessadas 
quando necessário. Os bancos de dados são amplamente utilizados e constituem a parte essen-
cial de quase todas as empresas, independentemente do seu ramo de atividade. A importância 
dos bancos de dados foi impulsionada nos últimos anos devido ao crescimento das aplicações 
web, das implantações de ERP's (Enterprise Resourcing Process), de BI (Businnes Intelligence), 
dentre outras. Todas essas tecnologias são dependentes do banco de dados por envolverem ar-
mazenamento de grandes volumes de dados, recuperação de dados no menor tempo possível, 
segurança de acesso, backup de dados em tempo real, dentre outras funcionalidades. 
Conforme comentado, o banco de dados é extremamente importante para o armaze-
namento de dados. Mas, afinal, qual a definição de dados? Existe diferença entre dados e in-
formações? Para o bom entendimento, é fundamental entender a diferença entre esses dois 
conceitos. Os dados são considerados fatos brutos, o que indica que os fatos ainda não foram 
processados para revelar seu significado. Como exemplo, imagine que você queira saber o que 
os usuários de um laboratório de informática pensam a respeito do serviço prestado. Normal-
mente, você começaria entrevistando os usuários para avaliar o desempenho do laboratório. 
Você poderia usar um formulário na web, o que permitiria que os usuários respondessem as 
suas questões. Quando o formulário estiver preenchido, os dados, nesse exato momento, são 
considerados como brutos, armazenados em um repositório de dados. Embora você já tenha os 
fatos em mãos, eles não possuem nenhuma utilidade específica nesse formato. Portanto, é ne-
cessário transformar os dados brutos em dados lapidados, permitindo obter respostas rápidas e 
objetivas das questões oriundas do formulário, como: "Qual é a composição da base de clientes 
de nosso laboratório?".
11© Caderno de Referência de Conteúdo
Claretiano - Centro Universitário
Para revelar seu significado, os dados brutos são processados de maneira apropriada, ge-
rando, assim, as informações. Esse processamento pode ser considerado simples (como exem-
plo podemos citar a organização dos dados para extrair padrões) ou complexo (como a realiza-
ção de estimativas, empregando variáveis estatísticas). As informações necessitam conhecer seu 
contexto para revelar seu significado adequado. 
As informações são consideradas fundamentais para a tomada de decisão nas empresas, 
seja governamental, de serviços ou filantrópicas. Um resumo dos dados extraídos das questões 
referentes a cada formulário de entrevista pode demonstrar os pontos fortes e fracos de um 
serviço, por exemplo, e auxiliar na tomada de decisões para melhor atender às necessidades de 
seus clientes.
Você já ouviu falar em FAT, FAT32, NTFS, SQL Server, Oracle e MySQL? Todas essas siglas 
têm um objetivo em comum: organizar e armazenar dados em sistemas computacionais. Elas 
fazem parte de dois sistemas para controle de informação: Sistema de Arquivos e Sistema Ge-
renciador de Banco de Dados (SGBD).
Sistema de arquivos é o método de organizar e armazenar informações seguindo uma es-
trutura lógica para alocação física dos arquivos em dispositivos de armazenamento, tais como: 
disco rígido ou CD-ROM. Em outras palavras, o sistema de arquivos é a estrutura que indica 
como os arquivos devem ser gravados e guardados em algum sistema de armazenamento.
Já, o SGBD é uma coleção de programas que permite ao usuário definir, construir e ma-
nipular bases de dados para as mais diversas finalidades. Os programas ou softwares SGBDs 
mais conhecidos são Microsoft SQL Server, MySQL, Oracle, FireBird e PostgreSQL. No Sistema 
Gerenciador de Banco de Dados, o acesso aos dados e o seu gerenciamento são realizados pelo 
próprio SGBD, o qual funciona como uma interface entre o banco de dados e os programas apli-
cativos, isto é, o SGBD está localizado entre o banco de dados físico e os usuários.
Um modelo de banco de dados nada mais é do que uma descrição dos tipos de informa-
ções que serão armazenadas em um banco de dados. Para que possamos construir um modelo 
de dados é necessário o uso de uma linguagem de modelagem de dados. Essas linguagens são 
classificadas em linguagens textuais ou gráficas. Cada representação de um modelo de dados 
por meio de uma linguagem de modelagem de dados recebe a denominação de esquema de 
banco de dados. 
Em um projeto de banco de dados, comumente são utilizados dois níveis de abstração, 
sendo eles: o modelo conceitual e o modelo lógico. Um modelo conceitual é uma descrição do 
banco de dados de forma independente de implementação em um SGBD. O modelo conceitual 
registra quais dados podem aparecer no banco de dados, mas não registra como estes dados 
serão armazenados em nível do SGBD.
A técnica de modelagem conceitual mais difundida é a abordagem entidade-relaciona-
mento (ER). Utilizando-se esta técnica, um modelo conceitual é usualmente representado por 
meio de um diagrama, denominado diagrama entidade-relacionamento (DER). 
Um modelo lógico é uma descrição de um banco de dados no nível de abstração visto pelo 
usuário do SGBD, de forma que este modelo é dependente do SGBD que será usado. Em um 
modelo lógico devem ser definidas quais as tabelas contidas pelo banco e, para cada tabela, os 
nomes das colunas.
Nodecorrer das unidades, veremos que o minimundo representa o domínio relacionado 
aos dados que o banco deve armazenar. Um levantamento dos requisitos desse minimundo é 
© Banco de Dados12
efetuado e, a partir da análise de requisitos, é criado o projeto conceitual, representado pelo 
modelo entidade-relacionamento, o qual não contém detalhes de implementação, tratando-se, 
portanto, de um modelo de dados de alto nível, e independente do SGBD a ser adotado. O pró-
ximo passo, diz respeito à criação do projeto lógico, que é realizada por meio do mapeamento 
do modelo entidade-relacionamento para o modelo relacional. A partir dessa fase, você já pode 
pensar em um modelo de dados de implementação do SGBD. E, para finalizar, o último passo 
corresponde à fase nomeada de projeto físico, quando são definidos as estruturas de armaze-
namento interno, os índices, além de outras atividades desenvolvidas paralelamente, tal como 
a implementação dos programas de aplicação.
Você já ouviu falar em modelo entidade-relacionamento? Pois bem, o modelo entidade-
-relacionamento (MER) foi criado por Peter Chen na década de 1970, podendo ser considerado 
um padrão para a modelagem conceitual. Esse modelo é baseado na percepção do mundo real, 
e tem como finalidade a construção de objetos denominados entidades e a promoção o relacio-
namento entre eles.
O MER tem a intenção de descrever, de maneira conceitual, os dados que serão utilizados 
em um sistema de informação. Essa descrição acontece na fase conceitual do projeto de banco 
de dados e será utilizada pelo sistema de informação em questão. O modelo possui conceitos 
intuitivos que permitem aos projetistas de bancos de dados capturarem os conceitos inerentes 
aos dados da aplicação, independente de qualquer tecnologia utilizada para desenvolvimento 
de bancos de dados. O esquema conceitual criado utilizando-se os conceitos do modelo entida-
de-relacionamento é denominado de diagrama entidade-relacionamento (DER).
O diagrama entidade-relacionamento é composto por entidades, atributos e relaciona-
mentos. As entidades representam objetos do mundo real; os atributos representam suas ca-
racterísticas; e os relacionamentos representam a forma como esses objetos estão ligados entre 
si. Uma entidade é um objeto existente e distinto de qualquer outro objeto. Sua finalidade é 
representar um conjunto de objetos da realidade modelada. Por exemplo, uma pessoa chamada 
de José Ribeiro Neves possui um número de CPF único, CPF nº 123.321.987-00; este número de 
CPF é uma entidade, uma vez que identifica a pessoa de uma forma única em relação às outras 
pessoas. Uma entidade pode ser concreta, como uma pessoa ou uma empresa, ou abstrata, 
como um conceito.
Dessa maneira, você pode perceber que um conjunto de entidades é um grupo de entida-
des do mesmo tipo. O conjunto de alunos de sua turma, por exemplo, pode ser definido como o 
conjunto de entidades ALUNOS. A representação gráfica de uma entidade é obtida por meio de 
um retângulo identificado por um nome da entidade.
Uma das propriedades sobre as quais pode ser desejável manter associações é a asso-
ciação entre objetos. Por exemplo, você pode achar válido conhecer apenas as pessoas de um 
determinado departamento. Entretanto, uma pessoa teria que estar associada/vinculada a um 
departamento para que esta classificação obtenha êxito. Um relacionamento não ocorre, neces-
sariamente, entre entidades diferentes, podemos notar a existência do autorrelacionamento, 
ou seja, um relacionamento entre ocorrências de uma mesma entidade. Um detalhe importante 
em um autorrelacionamento é a identificação e compreensão do conceito de papel da entidade 
no relacionamento. Esse papel de entidade em relacionamento exerce a função que uma instân-
cia da entidade cumpre dentro de uma instância do relacionamento.
Você já deve ter percebido que um diagrama entidade-relacionamento pode definir n res-
trições com as quais o banco de dados deve estar de acordo. Uma dessas restrições é a cardina-
13© Caderno de Referência de Conteúdo
Claretiano - Centro Universitário
lidade do mapeamento, que expressa o número de entidades relacionadas a outras entidades 
por meio de um conjunto de relacionamentos. Basicamente, existem três tipos de relaciona-
mentos entre entidades binárias: um-para-um (uma entidade de A está associada a apenas uma 
entidade de B, e uma entidade de B está associada a apenas uma entidade de A), um-para-
-muitos (uma entidade de A está associada a muitas entidades de B, entretanto, uma entidade 
de B está associada a apenas uma entidade de A), muitos-para-muitos (uma entidade de A está 
associada a qualquer quantidade de entidades de B, e uma entidade de B está associada a qual-
quer número de entidades de A).
Não nós limitamos apenas aos relacionamentos e seus atributos, podemos ainda abstrair-
mos propriedades à entidades por meio do uso do conceito de generalização/especialização. 
Isso nos permite atribuir propriedades específicas a um subconjunto de ocorrências (especiali-
zação) de uma entidade considerada genérica. Para exemplificar o conceito de generalização/
especialização, imagine que a entidade CLIENTE seja segmentada em dois subconjuntos, esses 
representados pelas entidades nomeadas respectivamente de PESSOA FÍSICA e PESSOA JURÍDI-
CA, em que cada uma possui propriedades específicas. A aplicação da generalização/especiali-
zação implica que a entidade PESSOA FÍSICA, além de possuir suas características específicas, 
possui também todas aquelas contidas na entidade CLIENTE, ou seja, a entidade PESSOA FÍSICA 
possui os seguintes atributos: CPF, sexo, nome e código, sendo os dois últimos provenientes da 
entidade genérica CLIENTE. De modo similar, a entidade PESSOA JURÍDICA possui os seguintes 
atributos: CGC, tipo de organização, bem como o nome e código, sendo estes, oriundos da en-
tidade CLIENTE.
Vimos que um relacionamento é uma associação entre entidades, certo? Na modelagem 
ER não foi prevista a possibilidade de associar uma entidade a um relacionamento, ou então, de 
associar dois relacionamentos entre si. Na prática, quando construímos um novo DER ou modi-
ficamos um DER existente, surgem situações em que se deseja flexibilizar a associação de uma 
entidade a um relacionamento. Uma entidade associativa nada mais é que a redefinição de um 
relacionamento, que passa a ser tratado como se fosse também uma entidade.
A linguagem SQL (Structured Query Language) não é uma linguagem de programação de 
computadores criada com o propósito de desenvolver sistemas, como as linguagens Pascal, C, 
Basic, Cobol, Java, C/C++, C#, dentre outras. É uma linguagem declarativa, cuja finalidade é fa-
cilitar o acesso às informações por meio de consultas, atualizações e manipulações de dados 
armazenados em bancos de dados relacionais.
Devido a sua boa aceitação no mercado, surgiram os primeiros problemas operacionais, 
pois cada empresa passou a incorporar funcionalidades e comandos próprios à linguagem SQL, 
diferenciando-a da sua forma original. Na tentativa de reduzir esses problemas, surge, nesse ce-
nário, o ANSI (American National Standards Institute), o qual passou a estabelecer, por meio de 
um Comitê, normativas e critérios para definição de padrões para a linguagem SQL, que a partir 
desse período começou a ser referenciada por ANSI/SQL.
Apesar dos inúmeros esforços de entidades e institutos de padronização para construir 
um padrão de trabalho adequado, infelizmente, ainda existem empresas que implementam ro-
tinas, funções e comandos totalmente fora do padrão estabelecido, dificultando a vida dos pro-
fissionais da área de Tecnologia da Informação (TI). Em alguns casos isolados, utilizam mais de 
um Sistema de Gerenciamento de Banco de dados em um mesmo ambiente operacional.
A linguagem SQL utilizada no SGBD PostgreSQL é segmentada em quatro subconjuntos 
que formam a base das instruções: DDL (Data Definition Language), DML (Data Manipulation 
© Banco de Dados14
Language), DCL (Data ControlLanguage) e DQL (Data Query Language) – podendo, ainda, in-
cluir os subconjuntos SRC (Stored Routines Commands).
O subconjunto DDL (Data Definition Language) oferece recursos para definir objetos e con-
trolar os dados. São comandos responsáveis pela estruturação do banco de dados, por exemplo: 
a criação do próprio banco de dados (database), a criação das tabelas, dos índices, entre outros 
objetos. Você utilizará a maioria dos comandos que constituem a DDL, como: CREATE TABLE, 
CREATE VIEW, CREATE DATABASE, entre outros, durante este estudo.
Já, o subconjunto DML (Data Manipulation Language) tem como objetivo promover me-
canismos para manipulação e gerenciamento dos bancos de dados, inserindo, alterando e re-
movendo os dados. Os comandos que formam esse subconjunto são: DELETE, INSERT, UNION e 
UPDATE.
No que se refere ao controle de acesso aos dados, o DCL (Data Control Language) oferece 
recursos de controle de acesso de usuários ao sistema e aos dados, promovendo regras para 
realização de consultas, inserções, modificações e exclusões de dados do banco de dados. Essa 
linguagem é formada por comandos como GRANT e REVOKE, entre outros.
O comando SELECT faz parte da DQL (Data Query Language), considerado por alguns auto-
res como um comando pertencente ao subconjunto DML (Data Manipulation Language). 
Os SRC (Stored Routines Commands) são comandos que permitem a utilização de códigos 
de sub-rotinas armazenados no SGBD formados por AFTER, AS, BEFORE, BEGIN, CALLED, CREA-
TE, DECLARE, entre outros.
E por fim, o DTC (Data Type Commands) é o grupo de comandos responsáveis por estabe-
lecer o tipo de dado que uma coluna armazenará em uma tabela específica. O DTC é formado 
pelos comandos BIGINT, BIGSERIAL, CHAR, CHARACTER, DATE, DECIMAL, DOUBLE, INTEGER, INT, 
MONEY, NUMERIC, entre outros.
Além dos comandos descritos anteriormente, existe um conjunto de funções predefini-
das, com uma série de operadores, que promovem facilitadores nas diversas ações realizadas 
pelos aplicativos.
Antes mesmo de você explorar as fases de normalização de um banco de dados, você de-
verá conhecer as restrições de integridade conhecidas como dependências funcionais. A norma-
lização está relacionada intimamente com aspectos importantes como desempenho do banco 
de dados.
Segundo Takai; Italiano e Ferreira (2005), a dependência funcional:
[...] é uma propriedade do significado ou semântica dos atributos em um esquema de relação R. Utiliza-
-se o entendimento da semântica de atributos de R, isto é, como eles se relacionam, para especificar as 
dependências funcionais envolvidas em todas as instâncias da relação r (extensão) de R. As instâncias 
r satisfazem as restrições legais, pois obedecem as restrições de dependência funcional. Assim, a prin-
cipal utilização das dependências funcionais é a de descrever um esquema de relação R especificando 
restrições sobre seus atributos que devem ser validados todas às vezes. 
A função da normalização é atuar como um filtro sobre as entidades e os relacionamentos, 
eliminando alguns elementos sem causar perda de informação nas entidades e nas relações. 
No decorrer deste estudo, você verá como isso é realizado por meio das formas normais, as 
quais foram introduzidas para atuar em cada caso em que a informação se encontra disponível 
para ser tratada, deixando os dados mais bem organizados dentro de um banco de dados. Ao 
aplicarmos a normalização, deseja-se evitar: grupos repetitivos de dados; variação temporal de 
certos atributos, dependências funcionais totais ou parciais em relação a uma chave concate-
15© Caderno de Referência de Conteúdo
Claretiano - Centro Universitário
nada; redundâncias de dados desnecessários; perdas acidentais de informação; dificuldade na 
representação de fatos da realidade observada e dependências transitivas entre atributos.
A normalização tem sua atuação por meio das formas normais. Os primeiros estágios do 
processo de normalização são: primeira forma normal (1FN), segunda forma normal (2FN) e 
terceira forma normal (3FN). Nesses três estágios, sob um ponto de vista estrutural, a forma 
normal maior apresenta-se melhor sobre sua antecessora, logo a 3FN é melhor que a 2FN, que 
por sua vez é melhor que a 1FN.
Embora a normalização seja de grande relevância para o sucesso de um Projeto de Banco 
de Dados, não devemos assumir que seu nível alto seja sempre o mais adequado a se utilizar. O 
êxito do projeto dá-se, mediante a análise da demanda do usuário para com um desempenho 
satisfatório.
O objetivo da normalização é garantir que todas as tabelas atendam ao conceito de re-
lações bem estabelecidas, ou seja, que tenham as seguintes características: cada tabela deve 
apresentar um único assunto, por exemplo, uma tabela de disciplina deverá possuir apenas as 
informações pertinentes à disciplina; nenhum item de dado deverá ser armazenado de forma 
desnecessária em mais de uma tabela, como mencionado anteriormente, a redundância, se 
houver necessidade desta, deve ser minuciosamente controlada; todos os atributos não perti-
nentes à tabela deverão ser dependentes da chave primária, garantindo assim a identificação 
exclusiva dos dados; e, para finalizar, todas as tabelas deverão estar livres das anomalias (ano-
malias de atualização, inserção e exclusão), de modo a garantir a integridade e a consistência 
dos dados.
Uma relação se encontra na primeira forma normal (1FN) se todos os seus atributos são 
monovalorados e atômicos. Entretanto, se utilizarmos a 1FN e a tabela resultante possuir chave 
primária com apenas um atributo, a tabela está automaticamente na 2FN.
Semelhante ao processo de normalização, um modelo antes de ser convertido à terceira 
forma normal (3FN) deve, primeiro, estar enquadrado na 2FN. Existe uma forma normal mais 
restritiva do que a 3FN, que é a forma normal de Boyce-Codd (BCNF), a qual foi proposta como 
uma forma mais simples que a 3FN. A BCNF é considerada mais restritiva, pois, à medida que 
toda relação está na BCNF, também estará na 3FN; entretanto, o inverso não é considerado ver-
dadeiro.
É desejável que um projeto de banco de dados alcance a 3FN ou BCNF para todo esquema 
da relação. Alcançar o status de normalização somente na 1FN ou na 2FN não é considerado 
adequado, uma vez que essas formas foram desenvolvidas como caminho para a 3FN. Uma 
tabela é dita na 3FN se, e somente se, estiver na 2FN e não possuir, em hipótese alguma, depen-
dências transitivas.
Não podemos pensar em um banco de dados como um sistema único, pois, dificilmente, 
ele fica isolado em uma máquina e é acessado apenas por uma pessoa, ou de apenas um lugar. 
Ao pensar em banco de dados, devemos ter em mente que informações armazenadas podem 
ser acessadas por muitas pessoas, as quais podem, ainda, estar em locais diferentes.
Em uma instituição financeira, como os muitos bancos que temos espalhados pelo Brasil 
(considerando apenas o território nacional), você pode ter uma conta que foi aberta em deter-
minada agência, mas pode fazer as operações bancárias a partir de qualquer local em que haja 
um caixa eletrônico dessa instituição financeira.
© Banco de Dados16
Além disso, você pode ter uma conta com outra pessoa, isto é, duas pessoas podem fazer 
as mesmas operações na mesma conta bancária. Se ambas, a partir de lugares diferentes, resol-
verem fazer um saque, no mesmo momento, da mesma conta corrente, quem sacará primeiro? 
O usuário poderia receber uma informação incorreta e, muitas vezes, sem lógica.
Para que não ocorra esse caos no sistema, existe a transação, que é uma unidade de exe-
cução de programa que acessa e, possivelmente, atualiza vários itens de dados. 
Analisando do ponto de vista do SGBD, uma transação é uma sequência de operações que 
são tratadas como um bloco único e indivisível (atômico), quanto à sua recuperação, ou seja, a 
execução parcial de transações não é permitida.
As responsabilidades do DBA variam a cada organização, mas, de modo geral, o DBA de-
verá planejar a estratégia deadministração de dados. Sua função, de modo direto, consiste em 
definir, implementar e aplicar as políticas, padrões e procedimentos pertinentes a uma melhor 
conduta para o zelo das informações contidas em um banco de dados.
Sabe-se que um dos maiores ativos das organizações é o seu contingente informacional, e 
quando uma organização necessita acessar determinada informação que não está prontamente 
disponível, perdas podem ser geradas. Por isso, procedimentos de backup e restauração são im-
prescindíveis para assegurar a proteção e a constante disponibilidade das informações obtidas e 
acumuladas ao longo do tempo.
Os procedimentos de backup e restauração são muito importantes em qualquer SGBD uti-
lizado. O DBA em questão deve garantir que os dados possam ser recuperados totalmente em 
caso de perda física ou de integridade dos dados.
As atividades do DBA inclui o gerenciamento de desastres, de modo a garantir a disponi-
bilidade dos dados após um possível desastre, seja ele físico ou uma falha de integridade. Para 
tanto, é necessário um planejamento sistêmico dentro da organização, o que deverá compreen-
der planos de testes e planejamento de ações, procedimentos necessários à recuperação.
A computação distribuída pode ser aplicada não somente a banco de dados, mas a quais-
quer componentes que se encontram em computadores ou em locais diferentes e que, de algu-
ma forma, se relacionam.
Um sistema de computação distribuída pode ser entendido como vários componentes 
que estão ligados por uma rede de computadores e que se relacionam para executarem tarefas 
em comum.
Segundo Elmasri e Navathe (2005, p. 579), banco de dados distribuídos pode ser definido 
como "uma coleção de múltiplos bancos de dados logicamente inter-relacionados, distribuídos 
por uma rede de computadores".
Um Sistema de Gerenciamento de Banco de Dados Distribuídos (SGBDD) tem por finalida-
de controlar o armazenamento e processamento de dados relacionados logicamente por meio 
de sistemas computacionais interconectados. Neste contexto, tanto os dados como as funções 
de processamento são distribuídos entre os diversos locais, também nomeados, eventualmen-
te, de nós.
Bem, chegamos ao final de nossa abordagem e esperamos que você tenha aproveitado 
ao máximo os tópicos aqui apresentados, mesmo que de forma sucinta. É importante destacar 
que apenas o estudo teórico da linguagem SQL não será suficiente para o seu aprendizado: é 
fundamental que você pratique exaustivamente! Para tanto, crie o cenário instalando o SGBD 
PostgreSQL, conforme orientações descritas no Apêndice 1.
17© Caderno de Referência de Conteúdo
Claretiano - Centro Universitário
Glossário de Conceitos 
O Glossário de Conceitos permite a você uma consulta rápida e precisa das definições con-
ceituais, possibilitando-lhe um bom domínio dos termos técnico-científicos utilizados na área de 
conhecimento dos temas tratados em Banco de Dados. Veja, a seguir, a definição dos principais 
conceitos: 
1) Atributo: abstração de uma propriedade de uma entidade ou de um relacionamento.
2) Banco de Dados: sistema de armazenamento de dados cujo objetivo é registrar e 
guardar informações importantes que poderão ser acessadas quando necessário. 
3) Banco de Dados Espaciais: aquele que permite consultar objetos localizados em um 
espaço multidimensional. É o caso dos bancos de dados geográficos, que armazenam 
informações sobre mapas para localização de rios, cidades, estados, estradas, entre 
outros. 
4) Banco de Dados Especialistas: também conhecido como sistemas baseados em co-
nhecimento, é aquele que, por meio de técnicas aplicadas na área da Inteligência Ar-
tificial, incorpora raciocínio e inferência (capacidade de dedução).
5) Banco de Dados Meteorológicos: banco que armazena informações sobre o tempo. 
6) Banco de Dados Multimídias: banco que armazena os dados sob a forma de imagem, 
clipes de filmes, músicas, textos falados ou escritos, entre outros.
7) Banco de Dados Temporais: é aquele que permite ao usuário consultar estados atuais 
e passados do banco de dados, pois armazena históricos das alterações.
8) Base de Dados: representado por um conjunto de banco de dados. Base de dados e 
banco de dados não são sinônimos.
9) BI (Business Intelligence ou Inteligência de Negócios): utiliza conceitos em que as 
informações são coletadas, armazenadas e analisadas, tendo como base fatos reais 
e/ou hipóteses. Esses sistemas auxiliam na gestão organizacional e no processo de 
tomada de decisões.
10) Dado atômico: tipo de dado considerado básico, ou seja, indivisível.
11) Dado não atômico: tipo de dado considerado complexo, divisíveis (fragmentados).
12) Entidade: abstração de um fato do mundo real para o qual se deseja manter seus da-
dos no banco de dados.
13) ERP’s: são sistemas de gestão empresarial que possibilitam a integração de todos os 
dados e processos de uma empresa, melhorando o fluxo de informações. 
14) Gerenciamento de Banco de Dados: utiliza Sistemas Gerenciadores de Banco de Da-
dos (SGBDs).
15) Gerenciamento de Base de Dados: utiliza ferramentas de apoio integradas à tomada 
de decisão organizacional (ERP – Enterprise Resource Planning) ou Datawarehouse.
16) Integridade Semântica: garantia de dados sempre corretos com relação ao domínio 
de aplicação. 
17) Modelagem Conceitual: nível mais alto de abstração cujo objetivo é representar os 
requisitos de dados do domínio da aplicação (independente do modelo de banco de 
dados).
18) Modelagem Física: constitui um esquema SQL para a modelagem lógica (depende 
exclusivamente do SGBD).
19) Modelagem Lógica: representação da modelagem conceitual em um modelo de ban-
co de dados.
20) Relacionamento: abstração de uma associação entre (ocorrências de) entidades.
21) Sistema Gerenciador de Banco de Dados (SGBD): coleção de programas responsáveis 
pela criação e manutenção de banco de dados.
© Banco de Dados18
Esquema dos Conceitos-chave 
Para que você tenha uma visão geral dos conceitos mais importantes deste estudo, apre-
sentamos, a seguir (Figura 1), um Esquema dos Conceitos-chave. O mais aconselhável é que 
você mesmo faça o seu esquema de conceitos-chave ou até mesmo o seu mapa mental. Esse 
exercício é uma forma de você construir o seu conhecimento, ressignificando as informações a 
partir de suas próprias percepções. 
É importante ressaltar que o propósito desse Esquema dos Conceitos-chave é representar, 
de maneira gráfica, as relações entre os conceitos por meio de palavras-chave, partindo dos 
mais complexos para os mais simples. Esse recurso pode auxiliar você na ordenação e na se-
quenciação hierarquizada dos conteúdos de ensino. 
Com base na teoria de aprendizagem significativa, entende-se que, por meio da organiza-
ção das ideias e dos princípios em esquemas e mapas mentais, o indivíduo pode construir o seu 
conhecimento de maneira mais produtiva e obter, assim, ganhos pedagógicos significativos no 
seu processo de ensino e aprendizagem. 
Aplicado a diversas áreas do ensino e da aprendizagem escolar (tais como planejamentos 
de currículo, sistemas e pesquisas em Educação), o Esquema dos Conceitos-chave baseia-se, 
ainda, na ideia fundamental da Psicologia Cognitiva de Ausubel, que estabelece que a apren-
dizagem ocorre pela assimilação de novos conceitos e de proposições na estrutura cognitiva 
do aluno. Assim, novas ideias e informações são aprendidas, uma vez que existem pontos de 
ancoragem. 
Tem-se de destacar que "aprendizagem" não significa, apenas, realizar acréscimos na es-
trutura cognitiva do aluno; é preciso, sobretudo, estabelecer modificações para que ela se con-
figure como uma aprendizagem significativa. Para isso, é importante considerar as entradas de 
conhecimento e organizar bem os materiais de aprendizagem. Além disso, as novas ideias e os 
novos conceitos devem ser potencialmente significativos para o aluno, uma vez que, ao fixar 
esses conceitos nas suas já existentes estruturas cognitivas, outros serão também relembrados. 
Nessaperspectiva, partindo-se do pressuposto de que é você o principal agente da cons-
trução do próprio conhecimento, por meio de sua predisposição afetiva e de suas motivações 
internas e externas, o Esquema dos Conceitos-chave tem por objetivo tornar significativa a sua 
aprendizagem, transformando o seu conhecimento sistematizado em conteúdo curricular, ou 
seja, estabelecendo uma relação entre aquilo que você acabou de conhecer com o que já fazia 
parte do seu conhecimento de mundo (adaptado do site disponível em: <http://penta2.ufrgs.
br/edutools/mapasconceituais/utilizamapasconceituais.html>. Acesso em: 11 mar. 2010). 
Como poderá observar, esse Esquema oferecerá a você, como dissemos anteriormente, 
uma visão geral dos conceitos mais importantes deste estudo. Ao segui-lo, será possível transi-
tar entre os principais conceitos e descobrir o caminho para construir o seu processo de ensino-
-aprendizagem. Dentre esses conceitos, há o de Projeto de Banco de Dados, o qual implica o co-
nhecimento dos modelos conceitual, lógico e físico, além dos detalhes inclusos em cada modelo 
mencionado. 
19© Caderno de Referência de Conteúdo
Claretiano - Centro Universitário
 
Projeto 
de 
Banco de Dados 
Banco 
de 
Dados 
Modelo 
Conceitual Modelo 
Lógico 
Modelo 
Físico 
Entidade 
Relacionamento 
Atributos 
Cardinalidade 
Modelo Relacional 
Modelo Hierárquico 
e XML 
Modelo Orientado a 
Objetos 
DDL 
DML 
DCL 
 
Normalização 
1ª FN 2ª FN 3ª FN 
Esquema 
SQL 
Figura 1 Esquema dos Conceitos-chave de Banco de Dados. 
O Esquema dos Conceitos-chave é mais um dos recursos de aprendizagem que vem se 
somar àqueles disponíveis no ambiente virtual, por meio de suas ferramentas interativas, bem 
como àqueles relacionados às atividades didático-pedagógicas realizadas presencialmente no 
polo. Lembre-se de que você, aluno EaD, deve valer-se da sua autonomia na construção de seu 
próprio conhecimento. 
Questões Autoavaliativas
No final de cada unidade, você encontrará algumas questões autoavaliativas sobre os con-
teúdos ali tratados, as quais podem ser de múltipla escolha, abertas objetivas ou abertas dis-
sertativas. 
Responder, discutir e comentar essas questões, bem como relacioná-las com a prática 
do ensino de Banco de Dados pode ser uma forma de você avaliar o seu conhecimento. Assim, 
mediante a resolução de questões pertinentes ao assunto tratado, você estará se preparando 
para a avaliação final, que será dissertativa. Além disso, essa é uma maneira privilegiada de você 
testar seus conhecimentos e adquirir uma formação sólida para a sua prática profissional. 
Você encontrará, ainda, no final de cada unidade, um gabarito, que lhe permitirá conferir 
as suas respostas sobre as questões autoavaliativas de múltipla escolha. 
As questões de múltipla escolha são as que têm como resposta apenas uma alternativa correta. Por 
sua vez, entendem-se por questões abertas objetivas as que se referem aos conteúdos matemáticos 
ou àqueles que exigem uma resposta determinada, inalterada. Já as questões abertas dissertativas 
obtêm por resposta uma interpretação pessoal sobre o tema tratado; por isso, normalmente, não há 
nada relacionado a elas no item Gabarito. Você pode comentar suas respostas com o seu tutor ou com 
seus colegas de turma.
© Banco de Dados20
Bibliografia Básica
É fundamental que você use a Bibliografia Básica em seus estudos, mas não se prenda só 
a ela. Consulte, também, as bibliografias complementares.
Figuras (ilustrações, quadros...)
Neste material instrucional, as ilustrações fazem parte integrante dos conteúdos, ou seja, 
elas não são meramente ilustrativas, pois esquematizam e resumem conteúdos explicitados no 
texto. Não deixe de observar a relação dessas figuras com os conteúdos abordados, pois relacio-
nar aquilo que está no campo visual com o conceitual faz parte de uma boa formação intelectual. 
Dicas (motivacionais)
Este estudo convida você a olhar, de forma mais apurada, a Educação como processo de 
emancipação do ser humano. É importante que você se atente às explicações teóricas, práticas e 
científicas que estão presentes nos meios de comunicação, bem como partilhe suas descobertas 
com seus colegas, pois, ao compartilhar com outras pessoas aquilo que você observa, permite-
-se descobrir algo que ainda não se conhece, aprendendo a ver e a notar o que não havia sido 
percebido antes. Observar é, portanto, uma capacidade que nos impele à maturidade. 
Você, como aluno do curso de graduação na modalidade EaD, necessita de uma formação 
conceitual sólida e consistente. Para isso, você contará com a ajuda do tutor a distância, do tutor 
presencial e, sobretudo, da interação com seus colegas. Sugerimos, pois, que organize bem o 
seu tempo e realize as atividades nas datas estipuladas. 
É importante, ainda, que você anote as suas reflexões em seu caderno ou no Bloco de 
Anotações, pois, no futuro, elas poderão ser utilizadas na elaboração de sua monografia ou de 
produções científicas.
Leia os livros da bibliografia indicada, para que você amplie seus horizontes teóricos. Co-
teje-os com o material didático, discuta a unidade com seus colegas e com o tutor e assista às 
videoaulas. 
No final de cada unidade, você encontrará algumas questões autoavaliativas, que são im-
portantes para a sua análise sobre os conteúdos desenvolvidos e para saber se estes foram 
significativos para sua formação. Indague, reflita, conteste e construa resenhas, pois esses pro-
cedimentos serão importantes para o seu amadurecimento intelectual.
Lembre-se de que o segredo do sucesso em um curso na modalidade a distância é parti-
cipar, ou seja, interagir, procurando sempre cooperar e colaborar com seus colegas e tutores.
Caso precise de auxílio sobre algum assunto, entre em contato com seu tutor. Ele estará 
pronto para ajudar você. 
3. E-REFERÊNCIA
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução a Banco de Dados. 2005. Disponível em: <http://pt.scribd.com/
doc/51228653/9/Arquiteturas>. Acesso em: 22 out. 2012.
4. REFERÊNCIA BIBLIOGRÁFICA 
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
11
Introdução aos Sistemas de 
Banco de Dados
1. OBJETIVOS
• Compreender o conceito básico de Sistemas Gerenciadores de Bancos de Dados (SGBD), 
sua importância, utilização e aplicação. 
• Conhecer os SGBDs mais utilizados no mercado, os problemas de armazenamento e 
recuperação de dados (redundâncias, inconsistências, integridade, compartilhamento 
e segurança) e os requisitos básicos que devem ser atendidos para um bom desempe-
nho.
2. CONTEÚDOS
• Perspectiva histórica.
• Sistemas de arquivos versus SGBDs.
• Dados em SGBDs: descrição e armazenamento.
• Arquitetura em um SGBD.
• Consultas em um SGBD.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE 
Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
© Banco de Dados22
1) Tenha sempre à mão o significado dos conceitos explicitados no Glossário e suas liga-
ções pelo Esquema de Conceitos-chave para o estudo de todas as unidades deste CRC. 
Isso poderá facilitar sua aprendizagem e seu desempenho.
2) É importante que você fique sempre atento às informações contidas na unidade. Pro-
grame-se, organize seus estudos e participe ativamente na Sala de Aula Virtual. Ser 
disciplinado para estudar pode ajudar você a tirar o máximo de proveito em seu curso 
de Educação a Distância.
3) Antes de iniciar os estudos desta unidade, pode ser interessante conhecer um pouco 
sobre a evolução das formas de armazenamento de dados. Para saber mais, acesse os 
sites indicados nas E-referências. 
4) O início do estudo desta unidade envolve alguns aspectos teóricos que serão funda-
mentais ao longo de todo o aprendizado. Dessa maneira, faça uso de um bloco de 
anotações para destacar os principais conceitos, tais como: banco de dados, dados 
e informações, sistemas de arquivos, Sistemas Gerenciadores de Bancos de Dados 
(SGBD) etc.
5) Lembre-seque dado é o que está armazenado no banco de dados e informação é o 
significado dos dados. 
6) O best-seller O mundo é plano, de Thomas Friedman, mostra que, devido ao avanço 
tecnológico, uma informação inédita é disponibilizada para o mundo todo em segun-
dos, colocando em igualdade de conhecimento populações de países desenvolvidos 
e países em desenvolvimento. Reflita sobre a importância dos dados e seu armazena-
mento no mundo globalizado. 
7) Os conceitos apresentados nesta unidade serão trabalhados na prática nas unidades 
seguintes. Preocupe-se, a princípio, em compreender as diferenças entre os conceitos 
apresentados. Se necessário, anote os termos e suas definições em um caderno para 
retomá-los posteriormente.
Perspectiva Histórica ––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Em algum momento da história, as empresas descobriram que estava muito caro empregar um número grande de 
pessoas para fazer certos trabalhos, como armazenar e indexar (organizar) arquivos. Por este motivo, valia a pena 
empregar esforços e investir em pesquisas em busca de um meio mais barato e uma solução mecânica eficiente. 
Na década de 1970, Ted Codd, um pesquisador renomado da IBM, publicou o primeiro artigo 
referente a bancos de dados relacionais. Este artigo discorria sobre o uso de cálculo e álgebra 
relacional, recursos que possibilitavam que usuários não técnicos manipulassem grande 
quantidade de informações. Codd projetava em sua mente um sistema computacional em que 
fosse factível ao usuário acessar os dados armazenados em tabelas através de comandos 
específicos. Na época, ninguém percebeu que as teorias obscuras de Codd desencadeariam 
uma revolução tecnológica comparável ao desenvolvimento dos computadores pessoais e da 
internet. Don Chamberlin, coinventor da SQL, a mais popular linguagem de computador utili-
zada pelos sistemas de bancos de dados de hoje, explica: "Havia aquele cara, Ted Codd, que 
usava um tipo de notação matemática estranha, mas ninguém a levava muito a sério". Então, 
Ted Codd organizou um simpósio e Chamberlin ouviu como ele conseguiu resumir cinco pági-
nas de programas complicados em uma única linha. "E eu disse: Uau!", relembra Chamberlin.
O simpósio convenceu a IBM (Internacional Business Machines) a fundar o System R (Sistema R), um projeto de 
pesquisa que construiu um protótipo de banco de dados relacional e que levaria à criação da SQL (Strutured Query 
Language) e do DB2. Esta linguagem tornou-se um padrão na indústria para bancos de dados relacionais e, hoje 
em dia, é um padrão ISO (International Organization for Standardization). Os primeiros protótipos foram utilizados 
por muitas organizações, como o MIT Sloan School of Management (escola norte-americana conhecida na área 
de negócios). Novas versões do sistema foram testadas com empresas de aviação para rastreamento do manufa-
turamento de estoque. A IBM, no entanto, manteve o System R em segundo plano por vários e decisivos anos. O 
interesse da empresa voltava-se para o IMS, um sistema de banco de dados confiável, de alta tecnologia, que havia 
surgido em 1968. Sem perceber o potencial de mercado daquela pesquisa, a IBM permitiu que sua equipe publicasse 
seus trabalhos.
Entre os leitores estava Larry Ellison, que havia acabado de fundar uma pequena empresa. Recrutando programadores 
do System R e da Universidade da Califórnia, Ellison conseguiu colocar no mercado, bem antes da IBM, o primeiro ban-
co de dados relacional com base em SQL, em 1979. Em 1983, a empresa laçou uma versão portátil do banco de dados, 
tendo um faturamento bruto anual de US$ 5.000.000 e alterou seu nome para Oracle. Impedida pela concorrência, a 
IBM finalmente lançou o SQL/DS (Structured Query Language/Data System), seu primeiro banco de dados relacional, 
em 1980 (imagem disponível em: <http://www.answers.com/topic/edgar-f-codd>. Acesso em: 18 maio 2012.). 
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Claretiano - Centro Universitário
23© U1 – Introdução aos Sistemas de Banco de Dados
4. INTRODUÇÃO À UNIDADE
Nesta unidade, você terá a oportunidade de estudar alguns conceitos de banco de dados, 
bem como aprender a importância dos Sistemas Gerenciadores de Banco de Dados em sistemas 
de informações. Para tanto, veja a definição a seguir:
Figura 1 Banco de Dados.
Banco de dados é um sistema de armazenamento de dados cujo objetivo é registrar e 
guardar informações importantes que poderão ser acessadas quando necessário. Os bancos 
de dados são amplamente usados, formando uma parte essencial de quase todas as empresas. 
Veja alguns exemplos de onde são empregados os bancos de dados:
1) Instituições Financeiras (bancos): utilizam o banco de dados para o devido armaze-
namento de informações de seus clientes, suas respectivas contas, empréstimos e 
transações bancárias.
2) Linhas Aéreas: seu banco de dados armazena reservas e informações de horários dos 
voos. Sistemas computacionais de gerenciamento de linhas aéreas foram os primeiros 
aplicativos a utilizar o banco de dados de maneira geograficamente distribuída.
3) Universidades: empregam o banco de dados para manipular informações dos alunos, 
registros de cursos e notas.
4) Transações de Cartão de Crédito: constantemente utilizam bancos de dados para ge-
renciar compras com cartão de crédito e geração de faturas mensais.
5) Telecomunicação: o banco de dados é aplicado para manter registros de chamadas re-
alizadas, gerar cobranças mensais, gerenciar saldos de cartões telefônicos pré-pagos e 
armazenar informações sobre status das redes de comunicações.
6) Finanças: na área financeira, o banco de dados é utilizado para armazenar informações 
pertinentes aos valores mobiliários ou vendas e compras de instrumentos financeiros, 
como ações e títulos. O banco de dados também é empregado no armazenamento 
e gerenciamento de dados oriundos do mercado financeiro em tempo real, cuja fi-
nalidade é permitir aos clientes realizar negócios on-line e às empresas, transações 
automatizadas.
7) Vendas: é imprescindível o uso de banco de dados para gerenciar e armazenar infor-
mações de cliente, produto e compra.
8) Indústria: utiliza o banco de dados para o gerenciamento da cadeia de suprimentos e 
para o controle da produção de itens, estoques e pedidos nas fábricas.
9) Recursos Humanos: emprega banco de dados para armazenar e gerenciar informa-
ções referentes aos funcionários, salários, descontos em folha de pagamento, benefí-
cios, e também para a geração de contracheques.
© Banco de Dados24
Essa forma organizada de armazenamento permite a fácil manipulação dos dados, incluin-
do alterações, inserções, remoções, além das consultas.
É comum empregar os termos banco de dados e base de dados como sinônimos. De certa 
forma é um erro, pois o gerenciamento de uma base de dados utiliza, normalmente, ferramen-
tas de apoio integradas à tomada de decisão organizacional; como exemplo, podem ser citados 
o ERP (Enterprise Resource Planning) e o Data warehouse. Entretanto, o gerenciamento de um 
banco de dados é o obtido por meio de sistemas de gerenciamento de bancos de dados.
Em geral, o gerenciamento eficiente de dados necessita do uso de um banco de dados 
computacional (digital), que pode ser considerado como uma estrutura compartilhada e inte-
grada, a qual armazena um conjunto de:
• Dados brutos oriundos do usuário.
• Metadados, os quais permitem integrar e gerenciar os dados.
Os metadados fornecem uma descrição detalhada das características dos dados e do seu 
conjunto de relacionamentos, responsáveis por conectar os dados encontrados no banco de 
dados. Por exemplo, o componente de metadados armazena informações como o nome de cada 
elemento de dados, seu respectivo tipo (numérico, data ou texto) armazenado, a possibilidade 
ou não de deixar esse elemento vazio, dentre outras possibilidades. Desse modo, os metadados 
fornecem informações que complementam e expandem o valor e a utilização dos dados, ou 
seja, trazemuma representação mais completa dos dados no banco de dados.
A importância do banco de dados no cenário da Tecnologia da Informação (TI) aumentou 
consideravelmente nos últimos anos, impulsionada pelo crescimento das aplicações web, das 
implantações de ERP’s (Enterprise Resourcing Process), de BI (Business Intelligence) etc. Todas 
essas tecnologias são dependentes do banco de dados por envolverem o armazenamento de 
grandes volumes de dados, a recuperação de dados no menor tempo possível (principalmente 
no comércio eletrônico), a segurança de acesso, o backup de dados em tempo real, dentre ou-
tras funções. 
5. DADOS VERSUS INFORMAÇÕES
É importante que você entenda a diferença entre dados e informações. Os dados são con-
siderados fatos brutos, o que indica que os fatos ainda não foram processados para revelar seu 
significado. Como exemplo, imagine que você queira saber o que os usuários de um laboratório 
de informática pensam a respeito do serviço prestado. Normalmente, você começaria entrevis-
tando os usuários para avaliar o desempenho do laboratório. Você poderia usar um formulário 
na web, o qual permitiria que os usuários respondessem às suas questões. Quando o formulário 
estiver preenchido, os dados, nesse momento considerados como brutos, são armazenados em 
um repositório de dados. Embora você já tenha os fatos em mãos, eles não possuem nenhuma 
utilidade específica nesse formato. Portanto, é necessário transformar os dados brutos em da-
dos lapidados, o que permitirá a obtenção de respostas rápidas e objetivas das questões oriun-
das do formulário, como: "Qual é a composição da base de clientes de nosso laboratório?".
Para revelar seu significado, os dados brutos são processados de maneira apropriada, ge-
rando, assim, as informações. Esse processamento pode ser considerado simples (a organização 
dos dados para extrair padrões, por exemplo) ou complexo (como a realização de estimativas, 
empregando variáveis estatísticas). As informações necessitam conhecer seu contexto para re-
velar seu significado adequado. O simples fato de obtermos uma temperatura média de 95°, por 
Claretiano - Centro Universitário
25© U1 – Introdução aos Sistemas de Banco de Dados
exemplo, pode ser considerado um dado específico sem significado algum, a menos que saiba-
mos seu contexto: encontra-se em graus Fahrenheit ou Celsius? Está vinculada à temperatura de 
um hardware ou de um corpo humano?
Na maioria das vezes, as informações são pilares fundamentais para a tomada de decisões 
nas empresas, sejam elas governamentais, de serviços ou filantrópicas. No exemplo anterior, 
o resumo dos dados extraídos das questões referentes a cada formulário de entrevista pode 
demonstrar os pontos fortes e fracos do laboratório de informática, auxiliando, dessa forma, na 
tomada de decisões confiáveis para melhor atender às necessidades de seus clientes.
De acordo com as características e a aplicabilidade dos dados armazenados, os bancos são 
classificados de diferentes maneiras: podem se basear no número de usuários, na localização 
(ou localizações) e no tipo e extensão do uso esperado. 
Veja a classificação dos bancos de dados por número de usuários:
1) Banco de dados monousuário (de um único usuário): suporta apenas um usuário por 
vez. Por exemplo, se o usuário Pedro estiver utilizando o banco de dados, os usuários 
Regina e Douglas precisam esperar o usuário Pedro finalizar sua consulta.
2) Banco de dados multiusuário: dá suporte a diversos usuários simultaneamente. Por 
exemplo, os usuários Pedro, Regina e Douglas poderão utilizar o banco de dados ao 
mesmo tempo.
Outra característica importante dos bancos de dados pode ser estabelecida levando em 
consideração sua localização. Observe:
1) Banco de dados centralizado: estabelece suporte a dados centralizados em um único 
local.
2) Banco de dados distribuído: suporta dados distribuídos por vários locais, normalmen-
te, geograficamente distintos. 
Atualmente, a maneira mais usual de classificar os bancos de dados baseia-se no modo 
como estes serão utilizados e na sensibilidade ao tempo das informações nele coletadas. Pode-
mos detalhar essa classificação como:
1) Bancos de dados operacionais: projetados especialmente para suportar operações 
diárias de uma empresa. Também podem ser referenciados como bancos de dados 
transacionais ou de produção.
2) Data Warehouse (armazém de dados): tem a finalidade de armazenar os dados uti-
lizados para a geração de informações necessárias à tomada de decisões táticas e 
estratégicas. Essas decisões exigem que os dados sejam "lapidados" (manipulação de 
dados), a fim de extrair informações úteis para a formulação de decisões, previsões 
de vendas, posicionamento no mercado, dentre outros. Sua estrutura difere-se muito 
de um banco de dados operacional ou transacional, promovendo facilitadores para a 
recuperação desses dados.
3) Bancos de dados temporais: são aqueles que permitem ao usuário a consulta dos 
estados atuais e passados do banco de dados, pois armazenam históricos das altera-
ções. Veja alguns exemplos de aplicações, em que o controle e acesso a informações 
temporais são fundamentais: área médica (evolução do paciente), área empresarial 
(aplicações financeiras, controle de produção, gerenciamento de vendas, gestão de 
pessoas), controle acadêmico, sistemas de informações geográficas, sistemas de re-
servas, entre outros. 
4) Bancos de dados espaciais: são aqueles que permitem consultas a objetos localiza-
dos em um espaço multidimensional. É o caso dos bancos de dados geográficos, que 
armazenam informações sobre mapas para localização de rios, cidades, estados, es-
tradas, entre outros.
© Banco de Dados26
5) Bancos de dados meteorológicos: são aqueles que armazenam informações sobre o 
tempo.
6) Bancos de dados de multimídias: são aqueles que armazenam os dados sob a forma 
de imagens, vídeos, músicas, textos falados ou escritos, entre outros.
7) Bancos de dados especialistas: também conhecidos como sistemas baseados em co-
nhecimento, são aqueles que, por meio de técnicas aplicadas na área da Inteligência 
Artificial, incorporam raciocínio e inferência (capacidade de dedução).
Os bancos de dados também podem ser classificados de acordo como os dados são estru-
turados. Dados não estruturados são aqueles que existem em seu estado original (estado bruto), 
no formato em que foram coletados. Entretanto, esse formato não permite o processamento 
adequado para produzir informações. Já os dados estruturados são o resultado da obtenção de 
dados não estruturados, como também sua formatação, facilitando, assim, o armazenamento, a 
manipulação e a geração de informações. O formato (estrutura) é utilizado baseando-se no tipo 
de processamento que desejamos realizar nos dados. Alguns dados podem não estar prontos 
(não estruturados) para determinados tipos de processamento, todavia, podem estar prontos 
(estruturados) para outros tipos. Podemos utilizar, como exemplo, o valor de um dado específi-
co, como o valor 140070131, o qual pode referir-se a um CEP, um valor de vendas ou um código 
de um determinado produto. Por um lado, caso represente um CEP ou um código de produto e 
for armazenado como texto, não será permitido a realização de cálculos matemáticos com ele. 
Por outro lado, se o mesmo valor representar uma transação de vendas, torna-se necessário 
formatá-lo como numérico.
Contudo, a maioria dos dados encontrados são classificados como semiestruturados, que 
são aqueles parcialmente processados.
Recentemente, as necessidades de armazenamento e gerenciamento de dados não es-
truturados e semiestruturados estão sendo atendidas pela nova geração de bancos de dados, 
nomeados de XML. A XML (sigla em inglês para Extensible Markup Language) é considerada 
uma linguagem especial utilizada para representar e manipular elementos de dados em formato 
textual. Os bancos de dados em XML suportam o armazenamento e gerenciamento de dados 
semiestruturados em XML. A Tabela 1 realiza a comparaçãodos Sistemas de Gerenciamento de 
Bancos de Dados mais conhecidos no mercado.
Tabela 1 Tipos de bancos de dados.
PRODUTO
NÚMERO DE USUÁRIOS LOCALIZAÇÃO DE DADOS UTILIZAÇÃO DE DADOS
XXML
Monousuário Multiusuário Centralizado Distribuído Operacional Data Warehouse
PostgreSQL X X X X X X X*
MS SQL Server X** X X X X X X
DB2 X** X X X X X X
MySQL X X X X X X X*
Oracle (SGBDR) X** X X X X X X
* Promove suporte apenas a funções de XML. Os dados em XML são armazenados em grandes objetos de texto.
** O fornecedor oferece versão específica do SGBD.
Ao analisarmos a Tabela 1, podemos perceber as especificidades que cada produto apre-
senta em relação à classificação dos bancos de dados. 
Claretiano - Centro Universitário
27© U1 – Introdução aos Sistemas de Banco de Dados
6. SISTEMAS DE ARQUIVOS VERSUS SGBDS
Você já ouviu falar em FAT, FAT 32, NTFS? E SQL Server, Oracle e MySQL?
Todas essas siglas têm um objetivo em comum: organizar e armazenar dados em sistemas 
computacionais. Elas fazem parte de dois sistemas para controle de informação, o Sistema de 
Arquivos e o Sistema Gerenciador de Banco de Dados (SGBD).
Sistema de arquivos é o método de organizar e armazenar informações seguindo uma es-
trutura lógica para alocação física dos arquivos em dispositivos de armazenamento, tais como: 
disco rígido ou CD-ROM. Em outras palavras, o sistema de arquivos é a estrutura que indica como 
os arquivos devem ser gravados e guardados em algum sistema de armazenamento. A maioria 
dos sistemas de arquivos utiliza recursos de armazenamento de dados que se apresentam como 
um conjunto de blocos com tamanho fixo, denominado de setores, cada qual com 512 bytes.
O controle de acesso aos discos de armazenamento é realizado por sistemas operacionais 
como MS-DOS, Windows, Linux ou Unix. O software dos sistemas de arquivos é responsável por 
organizar esses setores em arquivos e diretórios, além de manter a informação sobre a qual se-
tor pertence um arquivo e qual setor está disponível.
Existem sistemas de arquivos que você provavelmente utiliza no seu dia a dia, conhecidos 
como FAT (File Allocation Table), FAT32 e NTFS (New Technology File System), presentes no sis-
tema operacional Windows. A diferença entre eles está relacionada às limitações da tecnologia 
que foram superadas e à necessidade de melhorias, como segurança e capacidade de arma-
zenamento. Devido à confiabilidade presente no sistema de arquivos, o FAT e o FAT32 foram 
incorporados ao sistema de arquivos NTFS. 
Os sistemas de arquivos funcionam por meio de uma espécie de tabela, que contém in-
dicações da localização das informações de cada arquivo. Quando um arquivo é salvo em um 
disquete, por exemplo, o FAT divide a área do disco em pequenos blocos. Assim, um arquivo 
ocupa vários desses blocos, mas eles não precisam estar em uma sequência. Os blocos de deter-
minados arquivos podem estar em várias posições diferentes. Por isso, existe a necessidade de 
uma tabela para indicar cada bloco. 
Observe, na Figura 2, a representação de um sistema de arquivos. É importante lembrar 
que aplicativos são programas computacionais desenvolvidos que utilizam uma linguagem de 
programação com a finalidade de solucionar problemas e auxiliar nas atividades computacio-
nais.
© Banco de Dados28
Figura 2 Sistema de Arquivos. 
Arquitetura de sistemas é a forma como o sistema terá os seus componentes organizados 
e estruturados para realizar a tarefa determinada. A arquitetura contém um plano e uma lógica, 
em que o sistema desenvolvido executará suas atividades.
O sistema de arquivos foi uma das primeiras arquiteturas de sistemas para armazenamen-
to e manipulação de dados e geração de informação, e, ao longo do tempo, sofreu alterações e 
foi adaptado conforme a evolução tecnológica. No entanto, alguns problemas ainda são encon-
trados, tais como: 
1) A manutenção: ela é prejudicada, pois a estrutura de arquivos é definida e padroniza-
da no próprio código do aplicativo. 
2) O compartilhamento de um arquivo por vários programas: apresenta dificuldades 
para gerenciar o acesso a esses arquivos e seu controle. 
3) As incompatibilidades nos aplicativos: o desenvolvimento de arquivos e programas 
de um mesmo sistema operacional, ao ser realizado isoladamente por diferentes pro-
gramadores, e até mesmo em linguagens diferentes, causa tais incompatibilidades, 
prejudicando as funcionalidades do sistema. 
4) A inconsistência (aplicativos com informações incorretas), o isolamento de dados (for-
matos distintos), a redundância (dados repetidos) e os problemas com segurança (fá-
cil acesso aos registros do sistema).
5) A falta de gerenciamento para acessos concorrentes (vários usuários acessando a 
mesma informação) aos dados e recuperação de dados.
Observe, a seguir, um exemplo que engloba a inconsistência e a falta de gerenciamento 
de acesso. Suponha que dois alunos estejam consultando o acervo de uma biblioteca digital à 
procura do mesmo livro. A biblioteca possui um único exemplar disponível para empréstimo, e 
essa informação é apresentada para os dois alunos que consultam o acervo. Ambos realizam a 
consulta e fazem a reserva no mesmo instante. Isso causará um problema no sistema, pois have-
rá inconsistência de dados. A inconsistência e a falta do gerenciamento da informação geraram 
Claretiano - Centro Universitário
29© U1 – Introdução aos Sistemas de Banco de Dados
uma falha: o sistema não foi capaz de bloquear a reserva de um dos estudantes e dizer que o 
livro já havia sido reservado para o outro.
Você percebe a necessidade das informações serem atualizadas em tempo real? Caso con-
trário, o que aconteceria com os sistemas bancários, os sistemas que realizam vendas pela inter-
net ou reservas de voos aéreos?
Com as exigências e necessidades de novos conceitos e estruturas nos sistemas de arqui-
vos, percebeu-se um aumento significativo nos custos de equipamentos, manutenção e tempo 
de trabalho para atender todas essas novas demandas. Dessa forma, os Sistemas de Geren-
ciamento de Banco de Dados (SGBD) surgiram como uma evolução dos Sistemas de Arquivos, 
criando novas estruturas de dados com o objetivo de gerenciar todo o armazenamento de in-
formações. 
O SGBD é uma coleção de programas que permite ao usuário definir, construir e manipular 
bases de dados para as mais diversas finalidades. Os programas ou softwares SGBDs mais co-
nhecidos são Microsoft Access, MySQL, Oracle, FireBird, SQL Server e PostgreSQL.
No Sistema de Gerenciamento de Banco de Dados (SGBD), o acesso aos dados e seu geren-
ciamento são realizados pelo próprio sistema, o qual funciona como uma interface (ponto que 
delimita e estabelece a relação entre dois sistemas independentes) entre o banco de dados e os 
programas aplicativos, isto é, o SGDB está localizado entre o banco de dados físico e os usuários. 
Um Sistema Gerenciador de Banco de Dados é responsável por receber as requisições 
provenientes de diversas aplicações e realizar a tradução, quebrando a complexidade das solici-
tações e permitindo o atendimento a essas requisições adequadamente. O SGBD consegue ocul-
tar dos usuários e aplicativos grande parte da complexidade existente em um banco de dados. 
Normalmente, os aplicativos computacionais que interagem com os bancos de dados por meio 
de um Sistema Gerenciador de Banco de Dados podem ser implementados pelos programado-
res utilizando diversas linguagens de programação, como por exemplo, o Visual Basic, Dot Net, 
Java, PHP ou C++. Além do uso de linguagens de programação específicas, existe a possibilidade 
de desenvolver aplicativos baseando-se exclusivamente em ferramentas proprietárias dos Siste-
mas Gerenciadores de Banco de Dados, como por exemplo, o Forms e Reports da Oracle.
Como vimos anteriormente, os dados constituem um material bruto fundamental a partir 
do qual as informações são obtidas, e requerem um excelente método para gerenciá-los. Você 
descobrirá que o SGBD torna o gerenciamento de dados mais eficientes e eficazes.Como exem-
plo, mencionamos suas diversas vantagens na utilização em aplicações computacionais. O SGBD:
1) Permite o compartilhamento dos dados para diversas aplicações e usuários.
2) Integra as visões dos dados dos diferentes usuários em um único repositório de dados.
3) Fornece modelos adequados para melhor aplicar as políticas de privacidade e segu-
rança de dados.
4) Reduz a inconsistência dos dados, que ocorre quando diferentes versões dos mesmos 
dados aparecem em locais distintos. Por exemplo, quando o departamento de ma-
rketing de uma determinada empresa armazena o nome de uma funcionária como 
"Gisele Ap. da Silva" e o departamento de recursos humanos, por sua vez, armazena o 
nome da mesma funcionária como "Gisele A. Silva".
5) Dados bem gerenciados e com acesso aprimorado permitem a geração de informa-
ções de melhor qualidade, que, por sua vez, auxiliam na tomada de decisões.
As vantagens da utilização de um SGBD não se limitam aos itens listados. Certamente, 
você descobrirá inúmeras utilidades ao conhecer os detalhes dos bancos de dados e seu projeto 
adequado.
© Banco de Dados30
O SGBD apresenta uma visualização única e integrada ao usuário (ou aplicativos), confor-
me pode ser visualizado na Figura 3. 
Figura 3 Sistema de Banco de Dados.
O SGBD solucionou problemas dos sistemas de arquivos, tais como: integração de dados 
(mesmo local), dados duplicados, independência de dados e aplicativos e representação das 
perspectivas do usuário.
Desenvolvedores, administradores e usuários que trabalham diretamente com SGBDs de-
vem ter conhecimento e domínio dos recursos para usufruir de todas as vantagens que o siste-
ma proporciona, como:
1) Rapidez no acesso às informações presentes no banco de dados.
2) Redução de problemas de integridade e redundância.
3) Diminuição do esforço humano no desenvolvimento.
4) Utilização dos dados e controle integrado de informações distribuídas fisicamente. 
Desconhecer o funcionamento do SGBD pode acarretar o mau desenvolvimento e afetar a 
segurança de acesso às informações.
Uma das comparações realizadas entre o sistema de arquivos e o SGBD está relacionada 
ao desempenho. O sistema de arquivos é programado para uma aplicação específica, o que gera 
um bom desempenho. Já o SGBD é programado para aplicações mais genéricas, podendo aten-
der a aplicações diferentes.
Em outras palavras, podemos dizer que os SGBDs vieram para eliminar todo o trabalho 
realizado anteriormente por um programador de aplicação, responsável pelo controle do aces-
so, da integridade e da redundância dos dados; contudo, ainda há alguns itens que são melhor 
atendidos pelos sistemas de arquivos. 
Claretiano - Centro Universitário
31© U1 – Introdução aos Sistemas de Banco de Dados
7. DADOS EM SGBDS: DESCRIÇÃO E ARMAZENAMENTO
Os dados são informações que podem ser gravadas e que possuem um significado implíci-
to. O banco de dados (BD) é uma coleção de dados relacionados que: 
• Representa aspectos do mundo real (minimundo ou universo de discurso). Portanto, as 
mudanças que ocorrem no mundo real devem ser refletidas no BD.
• Descreve uma coleção lógica e coerente de dados com algum significado inerente. Uma 
organização randômica, ou seja, aleatória, de dados não pode ser considerada um BD.
• Constrói em atendimento a uma proposta específica.
Um Sistema Gerenciador de Banco de Dados (SGBD) é uma coleção de programas que per-
mite aos usuários criarem e manterem um banco de dados. Ele foi definido para ser um sistema 
de software de propósito geral que facilita os processos de definição, construção, manipulação 
e compartilhamento de bancos de dados entre vários usuários e aplicações.
São características oferecidas pelos SGBDs: 
1) Rapidez: agilidade na execução das consultas on-line.
2) Disponibilidade total: significa que todas as vezes que uma informação for solicitada, 
ela deve estar disponível e atualizada.
3) Flexibilidade: facilidade na implementação de mudanças.
4) Integridade: garantia da consistência dos dados quando atualizações são efetuadas 
no banco.
Para atingir os objetivos propostos pelo SGBD, você verá que é necessário ter uma estru-
tura com níveis bem definidos e utilizar um modelo de dados adequado para descrever o banco 
de dados.
Níveis de Abstração de Dados
Normalmente, quando constituímos um projeto de banco de dados, iniciamos a partir de 
uma visão abstrata do ambiente como um todo, acrescentando detalhes à medida que o projeto 
evolui para a sua implementação. Utilizar níveis de abstração de dados pode ser extremamente 
útil no que diz respeito à integração de visões múltiplas de dados, como podemos presenciar em 
distintos níveis de uma empresa. 
O Comitê de Planejamento e Exigência de Padrões (SPARC) do Instituto Nacional America-
no de Padrões (ANSI) definiu, no início da década de 1970, uma estrutura de modelagem com 
base em níveis de abstração de dados. A arquitetura ANSI/SPARC define três níveis de abstração 
de dados: externo, conceitual e interno.
Modelo Externo
Esse modelo é considerado a perspectiva dos usuários finais do ambiente de dados. Usu-
ários finais é o termo dado às pessoas que fazem uso de aplicativos para manipular os dados, 
gerando, assim, as informações necessárias para o cenário empresarial. 
Normalmente, as empresas são segmentadas em diversas unidades comerciais, como: 
vendas, finanças e marketing, em que cada unidade pode estar sujeita a restrições e exigências 
específicas. Dessa maneira, os usuários finais podem visualizar apenas seus subconjuntos de 
dados específicos, separados das outras unidades da empresa.
 
© Banco de Dados32
Registro de alunos
Um aluno pode pegar até seis 
turmar por registro.
Uma turma limita-se a 
35 alunos.
Figura 4 Modelos externos de uma instituição acadêmica Sistema de Banco 
de Dados.
Na Figura 4, imagine os esquemas externos de duas unidades comerciais corresponden-
tes a uma instituição acadêmica: registro de alunos e agendamento de turmas. Cada esquema 
externo inclui as entidades, relacionamentos e restrições determinadas pela unidade comercial 
(departamento). Observamos que, embora as visões das aplicações sejam isoladas, cada visão 
compartilha sua unidade com a outra (os esquemas externos pertinentes ao registro de alunos 
e o agendamento de turmas compartilham as entidades TURMA e DISCIPLINA).
Em detalhes, podemos descrever as entidades-relacionamentos representados pela Figu-
ra 4:
1) Um PROFESSOR ensina muitas TURMAs, porém, cada TURMA é ensinada por apenas 
um PROFESSOR. Ou seja, existe um relacionamento 1:M entre PROFESSOR e TURMA.
2) Uma TURMA pode receber a MATRÍCULA de diversos alunos, e para cada aluno é per-
mitida a MATRÍCULA em várias TURMAs, formando, assim, um relacionamento M:N 
entre ALUNO e TURMA.
3) Para cada DISCIPLINA é permitida a geração de muitas TURMAs, mas cada TURMA 
se refere apenas a uma DISCIPLINA, conforme pode ser observado na cardinalidade 
mínima e máxima. 
4) Por fim, uma TURMA normalmente necessita de uma SALA, mas uma SALA pode ser 
reservada para várias TURMAs. Ou seja, cada sala de aula pode ser utilizada por diver-
sas turmas, uma em cada horário, por exemplo. Dessa forma, podemos identificar a 
existência de um relacionamento 1:M entre SALA e TURMA.
Claretiano - Centro Universitário
33© U1 – Introdução aos Sistemas de Banco de Dados
Modelo Conceitual
Após a identificação das visões externas, utilizamos o modelo conceitual, o qual é repre-
sentado graficamente pelo diagrama de entidade e relacionamento (DER) que, na prática, cons-
titui a planta básica do banco de dados. O modelo conceitual tem como objetivo realizar a inte-
gração de todas essas visões externas (entidades, relacionamentos e restrições) em uma visão 
global de todos os dados da empresa.
O ER (entidade-relacionamento) é o modelo conceitual mais utilizado. Dentre as vanta-
gens apresentadas pelo modelo conceitual, podemos destacar:
• Fornecimento de uma visão macroscópica de fácil entendimento sobre o ambiente de 
dados.• Independência de software: o modelo não depende da tecnologia do Sistema de Ge-
renciamento de Banco de Dados (SGBD) utilizado em sua implementação, ou seja, as 
alterações provenientes do software não refletirão sobre o projeto de banco de dados 
no nível conceitual.
• Independência de hardware: o modelo não depende do hardware utilizado em sua 
implementação, ou seja, as alterações provenientes do hardware não refletirão sobre 
o projeto de banco de dados no nível conceitual.
Modelo Interno
Nessa fase, normalmente já definimos qual tecnologia de Sistema de Gerenciamento de 
Banco de Dados (SGBD) será utilizada. O modelo interno realiza o mapeamento do modelo con-
ceitual para o SGBD específico.
Quando utilizamos o modelo relacional (o qual será detalhado adiante), escolhemos um 
banco de dados que suporta esse tipo para implementar o modelo interno, o qual se resume no 
mapeamento do modelo conceitual para as tabelas do modelo relacional. O esquema interno 
é constituído pela SQL (linguagem padrão) quando selecionamos o banco de dados relacional. 
Como exemplo, a Figura 5 apresenta o modelo interno implementado, criando-se as tabelas 
PROFESSOR, DISCIPLINA, TURMA, ALUNO, MATRÍCULA e SALA.
Devido à dependência do modelo interno a um software de SGBD específico, dizemos que 
ele é dependente de software. Qualquer alteração realizada na tecnologia do SGBD exigirá que 
o modelo interno sofra algum tipo de alteração a fim de se adequar às novas características e 
exigências de implementação do modelo de banco de dados. Em alguns casos, é possível alte-
rarmos o modelo interno sem interferir no modelo conceitual, obtendo, assim, a independência 
lógica. Entretanto, o modelo interno possui independência de hardware, ou seja, esse modelo 
não sofrerá nenhum tipo de alteração/modificação pela escolha do computador em que o sof-
tware (SGBD) será instalado.
© Banco de Dados34
Create Table DISCIPLINA (
DIS_ID CHAR(8) PRIMARY KEY,
DIS_NOME CHAR(25),
DIS_CREDITO NUMBER);
Create Table SALA (
SALA_ID CHAR(8) PRIMARY KEY,
SALA_TIPO CHAR(3));
Create Table TURMA (
TURMA_ID NUMBER PRIMARY KEY,
DIS_ID CHAR(8) REFERENCES DISCIPLINA,
PROF_ID NUMBER REFERENCES PROFESSOR,
PROF_NOME CHAR(8) REFERENCES SALA);
Create Table PROFESSOR (
PROF_ID NUMBER PRIMARY KEY,
PROF_SOBRENOME CHAR(15),
PROF_INICIAL CHAR(1),
PROF_NOME CHAR(15));
 
 
 
Figura 5 Modelo Interno (Instituição Acadêmica).
Modelo Físico
Este modelo trabalha nos níveis mais baixos de abstração, ou seja, descreve a maneira 
como os dados são gravados em meios de armazenamento, como discos e fitas magnéticas. O 
modelo físico carece da definição dos dispositivos de armazenamento físico, como também seus 
métodos de acesso a esse meio. Consequentemente, podemos dizer que esse modelo é depen-
dente tanto do software (SGBD) como do hardware. 
Mesmo que no modelo relacional o projetista do banco de dados não precise se preocu-
par com as características inerentes ao armazenamento físico dos dados, a implementação de 
um modelo relacional poderá exigir sintonização (tuning) refinada no nível físico para otimizar 
o desempenho.
Sabemos que o modelo físico depende da tecnologia do SGBD, dos mecanismos de acesso 
aos arquivos e dos tipos de dispositivos utilizados para efetuar o armazenamento. Eventual-
mente, quando é possível realizar qualquer tipo de alteração no modelo físico sem influenciar o 
modelo interno, ocorre o que chamamos de independência física.
Modelo de Dados
Um modelo de dados é uma representação relativamente simples, em geral gráfica, de es-
truturas mais complexas de dados reais. Normalmente, o modelo é uma abstração de um objeto 
ou até mesmo um evento real com um maior grau de complexidade. Tem como função principal 
auxiliar na compreensão das regras de negócios complexos existentes em um ambiente real. Em 
Claretiano - Centro Universitário
35© U1 – Introdução aos Sistemas de Banco de Dados
um cenário de bancos de dados, um modelo representa estruturas de dados e suas característi-
cas, como: relações, restrições, transformações, dentre outros elementos que possuem o mesmo 
objetivo, ou seja, dar suporte ao problema específico de um determinado domínio de negócios.
Habitualmente, os projetistas de bancos de dados confiam no bom senso na hora de de-
senvolver bons modelos. Por exemplo, se os estudantes de uma turma têm de criar, individual-
mente, um modelo de dados para uma locadora de filmes, é muito provável que cada um apre-
sente um modelo diferente. Qual estaria correto? A resposta é simples: "aquele que atender a 
todas as necessidades do usuário final", podendo haver mais de uma solução correta.
Um modelo de dados bem desenvolvido pode inclusive promover uma compreensão apri-
morada da organização para a qual o banco está sendo desenvolvido. Em resumo, os modelos 
de dados são uma ferramenta de comunicação. Esse aspecto importante da modelagem foi 
sintetizado claramente por um cliente, cuja reação foi a seguinte: "Eu criei esta empresa, traba-
lhei nela por anos e esta é a primeira vez em que eu realmente entendi como todas as partes se 
encaixam na prática".
Da mesma forma que a planta de uma casa é uma abstração, o modelo de dados é, de 
modo similar, uma abstração; não é possível obter os dados necessários a partir do modelo. Se 
dificilmente se construirá uma boa casa sem uma planta, é também improvável criar um bom 
banco de dados sem a prévia criação de um modelo de dados adequado.
Objetos Básicos
Os blocos básicos de construção de todos os modelos de dados são as entidades, os atri-
butos, os relacionamentos e as restrições. 
Uma entidade é algo (pessoa, local, objeto ou evento) sobre o qual são coletados e arma-
zenados dados. Ela representa um tipo particular de objeto no mundo real. Por isso, as entidades 
são distinguíveis, ou seja, cada ocorrência de entidade é única e distinta. Por exemplo, uma enti-
dade Cliente teria muitas ocorrências de clientes distinguíveis, como Manoel Ribeiro, Pedro José 
da Silva, Dinorá Fernandes Junqueira etc. As entidades podem ser objetos físicos, como clientes 
e produtos, mas também podem ser abstrações, como rotas de voo ou apresentações musicais.
Um atributo é considerado uma característica de uma entidade. Por exemplo, uma entida-
de Cliente seria caracterizada pelos atributos nome, sobrenome, telefone, endereço e limite de 
crédito. Os atributos são equivalentes aos campos nos sistemas de arquivos.
Um relacionamento descreve uma associação (conectividade) entre entidades (uma ou 
n). Por exemplo, um relacionamento entre clientes e corretores pode ser descrito da seguinte 
maneira: um corretor pode atender muitos clientes, mas cada cliente pode ser atendido apenas 
por um corretor. Os modelos de dados utilizam três tipos de relacionamentos: um para muitos 
(1:M ou 1..*), muitos para muitos (M:N ou *..*) e um para um (1:1 ou 1..1).
Veja, a seguir, exemplos que ilustram as distinções entre os três tipos de relacionamentos 
permitidos.
• Relacionamento um para muitos (1:M ou 1..*): um pintor faz várias pinturas, mas cada 
uma é criada por apenas um artista; o pintor (uma entidade) relaciona-se com as pin-
turas (várias entidades). Portanto, podemos definir o relacionamento PINTOR pinta 
PINTURA como sendo 1:M. De modo similar, um cliente (entidade) pode gerar muitas 
faturas (várias entidades), mas cada fatura é gerada apenas por um cliente. O relacio-
namento CLIENTE gera FATURA também seria identificado como 1:M.
© Banco de Dados36
• Relacionamento muitos para muitos (M:N ou *..*): um funcionário pode aprender 
várias habilidades profissionais e cada habilidade profissional pode ser aprendida por 
vários funcionários. Esse tipo nos permite identificar o relacionamento FUNCIONÁRIO 
aprende HABILIDADE como M:N. De modo similar, um aluno pode frequentar várias 
turmas e cada turma pode ser frequentada por vários alunos, conferindo-se, assim, a 
identificação M:N ao relacionamento expresso por ALUNO frequenta TURMA.
• Relacionamento um para um(1:1 ou 1..1): a estrutura de gerenciamento de uma empre-
sa de varejo pode exigir que cada uma de suas lojas seja gerenciada por um único funcio-
nário. Por sua vez, cada gerente de loja, que é um funcionário, gerencia apenas uma loja. 
Portanto, o relacionamento FUNCIONÁRIO gerencia LOJA é identificado como 1:1.
A discussão precedente identificou cada relacionamento em duas direções, ou seja, os 
relacionamentos são bidirecionais (grau dois ou binário). Veja:
• Um CLIENTE pode gerar diversas faturas.
• Cada uma das várias FATURAS é gerada apenas por um CLIENTE.
A restrição é uma limitação imposta aos dados. As restrições são importantes, pois aju-
dam a assegurar a integridade dos dados. Elas normalmente são expressas na forma de regras. 
Por exemplo:
• O salário de um funcionário possui valores entre R$ 1.000,00 e R$ 5.000,00.
• A média de nota de um aluno deve estar entre o intervalo 0,0 e 10,0.
• Cada turma deve ter um e apenas um professor.
Como é possível identificar, de maneira adequada, as entidades, os atributos, os relacio-
namentos e as restrições? A primeira etapa é identificar as regras de negócio para o domínio do 
problema que está sendo modelado.
Uma regra de negócio é uma descrição breve, precisa e sem ambiguidade de uma política, 
procedimento ou princípio em uma determinada organização. As regras de negócio se aplicam 
a qualquer tipo de organização, seja ela grande ou pequena – uma empresa, uma instituição 
pública, um grupo religioso ou um laboratório de pesquisa – que armazene e manipule dados 
para gerar informações importantes na tomada de decisões.
Regras de negócio adequadas são utilizadas para definir entidades, atributos, relaciona-
mentos e restrições. Sempre que você vir uma descrição de relacionamento como "um corretor 
pode atender muitos clientes, mas cada cliente pode ser atendido por apenas um corretor", 
você verá as regras de negócio em ação.
Essas regras descrevem, em linguagem simples, as principais características dos dados 
conforme vistos pela empresa. Os seguintes itens são exemplos de regras de negócio:
• Um cliente pode gerar muitas faturas.
• Uma fatura é gerada por apenas um cliente.
• Uma seção de treinamento não pode ser agendada para menos de 10 funcionários ou 
mais de 30.
Observe que essas regras de negócio estabelecem entidades, relacionamentos e restri-
ções. Por exemplo, as duas primeiras regras estabelecem duas entidades (CLIENTE e FATURA) e 
um relacionamento 1:M entre elas. A terceira regra de negócio estabelece uma restrição (não 
menos de 10 pessoas e não mais de 30), duas entidades (FUNCIONÁRIO e TREINAMENTO) e um 
relacionamento entre FUNCIONÁRIO e TREINAMENTO.
Claretiano - Centro Universitário
37© U1 – Introdução aos Sistemas de Banco de Dados
Convertendo Regras de Negócio em Modelos de Dados
As regras de negócio constituem um cenário adequado para a identificação correta dos 
objetos do modelo de dados, como suas entidades, atributos, relacionamentos e restrições. 
Em um cenário real, os nomes são utilizados para identificar objetos. Se o ambiente de negócio 
desejar rastrear os objetos, haverá regras específicas para eles. Geralmente, um substantivo em 
uma regra de negócio será traduzido como entidade no modelo de dados, e um verbo que asso-
cie substantivos será traduzido como um relacionamento entre entidades. Por exemplo, a regra 
de negócio "um CLIENTE pode GERAR várias FATURAS" contém dois substantivos (CLIENTES e 
FATURAS) e um verbo (GERAR) que associa os substantivos. Conclui-se a partir dessa regra que:
• CLIENTE e FATURA são objetos de interesse para o ambiente e devem ser representa-
dos por suas respectivas entidades.
• Há um relacionamento GERAR entre as entidades CLIENTE e FATURA.
Para identificar adequadamente o tipo, deve-se considerar que os relacionamento são 
bidirecionais, ou seja, valem em ambos os sentidos. Por exemplo, a regra "um CLIENTE pode 
GERAR várias FATURAS" é complementada pela regra "uma FATURA é gerada por apenas um 
CLIENTE". Nesse caso, o relacionamento é um para muitos (1:M). O CLIENTE é o lado um e a 
FATURA, o lado muitos. Normalmente, para fazer essa identificação do tipo de relacionamento, 
devemos fazer duas perguntas:
• Quantas instâncias de B são relacionadas a uma instância de A?
• Quantas instâncias de A são relacionadas a uma instância de B?
É possível avaliar o relacionamento entre ALUNO e DISCIPLINA fazendo as seguintes per-
guntas:
• Em quantas disciplinas um aluno pode se matricular? Resposta: várias disciplinas.
• Quantos alunos podem se matricular em uma disciplina? Resposta: vários alunos.
Portanto, o relacionamento entre ALUNO e DISCIPLINA é de muitos para muitos (M:N).
A busca por um melhor gerenciamento de dados gerou vários modelos que tentaram re-
solver as falhas fundamentais do sistema de arquivos. Na Tabela 2 podemos ter uma visão geral 
dos principais modelos de dados, em ordem cronológica.
Tabela 2 Detalhes sobre a evolução dos principais modelos de dados.
geração Época modelo exemplos comentários
Primeira Década de 1960 
a 1970
Sistema de 
arquivos
VMS/VSAM Utilizado pela IBM nos sistemas de 
mainframe.
Sem utilizar relacionamentos, gerenciava os 
registros.
Segunda Década de 1970 Modelo 
de dados 
hierárquico e em 
rede
IMS
ADABAS
IDS-II
Caracterizavam os primeiros bancos de dados.
Terceira Década de 1970 
até o presente
Modelo de 
dados relacional
DB2
Oracle
MS SQL Server
MySQL
PostgreSQL
Conceitos básicos simples e objetivos.
Modelagem entidade-relacionamento (ER) e 
suporte à modelagem relacional de dados.
© Banco de Dados38
geração Época modelo exemplos comentários
Quarta Década de 1980 
até o presente
Orientado 
a objetos 
relacionais 
estendidos
Versant
Caché
FastObjects.Net
Objectivity/DB
DB/2 UDB
Promove suporte a dados complexos.
Produtos relacionais estendidos com suporte 
a warehouse de dados e objetos.
Propagação de banco de dados na web.
Próxima geração Do presente ao 
futuro
XML dbXML
Tamino
DB2 UDB
Oracle 10g
MS SQL Server
PostgreSQL
Promove organização e gerenciamento de 
dados não estruturados.
Modelos relacionais e de objetos adicionam 
suporte a documentos em XML.
Modelo Hierárquico 
Desenvolvido na década de 1960, o modelo hierárquico tinha por objetivo gerenciar gran-
des quantidades de dados provenientes de projetos complexos. Podemos mencionar como 
exemplo o foguete Apollo, que aterrissou na Lua em 1969. Sua estrutura lógica é representada 
por uma estrutura semelhante à de uma árvore, visualizada de cima para baixo, onde identifi-
camos seus níveis ou segmentos. Um segmento é semelhante ao tipo de registro em um siste-
ma de arquivos qualquer. Internamente, por hierarquia, a camada considerada superior (raiz) é 
identificada como pai do segmento imediatamente abaixo dela. Na Figura 6 podemos visualizar 
o segmento considerado Raiz como o pai dos segmentos do Nível 1 que, por sua vez, são pais 
dos segmentos do Nível 2, e assim sucessivamente. Os segmentos encontrados abaixo de outros 
segmentos são identificados como filhos. Resumidamente, podemos considerar que o modelo 
hierárquico representa um conjunto de relacionamentos um para muitos (1:M) entre um pai e 
seus filhos, ou seja, cada pai pode ter muitos filhos, entretanto, cada filho possui apenas um 
pai.
 Montagem 
Final 
Componente A Componente B Componente C 
Montagem A 
Parte A Parte B 
Montagem B Montagem C 
Parte D Parte E Parte C 
Segmento de Nível 3 
(Filhos da Nível 2)
Segmento de Nível 2 
(Filhos da Nível 1)
Segmento de Nível 1 
(Filhos da Raiz)
Segmento Raiz
 
 
 
 
Figura 6 Estrutura Hierárquica.
O banco de dados hierárquico tornou-se referência na década de 1970, somando uma 
série de vantagens em relação aos sistemas de arquivo. Consequentemente, gerou uma base 
significante para o desenvolvimento de aplicações comerciais. Porém, o modelo hierárquico 
apresentava diversas limitações, entre elas a dificuldade de implementação e gerenciamento, 
Claretiano - Centro Universitário
39©U1 – Introdução aos Sistemas de Banco de Dados
a falta de independência estrutural e o fato de a maioria dos relacionamentos de dados mais 
comuns se adaptarem à forma 1:M.
Modelo em Rede
O modelo em rede foi criado para representar, exclusivamente, relacionamentos de dados 
complexos com maior eficiência (em comparação ao modelo hierárquico), otimizando o desem-
penho dos bancos de dados e determinando um padrão para os mesmos. 
No modelo em rede, em geral, o usuário visualiza o banco de dados em rede como uma 
coleção de registros em relacionamentos 1:M. Ao contrário do modelo hierárquico, esse modelo 
permite que um registro tenha mais de um pai. Um exemplo desse relacionamento é apresen-
tado na Figura 7.
Figura 7 Modelo de dados de rede.
A Figura 7 ilustra um modelo de dados em rede de uma empresa de vendas qualquer. Nes-
se modelo podemos identificar os tipos de registros: CLIENTE, REPCOMERCIAL, FATURA, FAT_LI-
NHA, PRODUTO e PAGAMENTO. Observe que a FATURA é propriedade tanto do REPCOMERCIAL 
como do CLIENTE. De maneira similar, FAT_LINHA possui dois proprietários, PRODUTO e FATURA.
A ausência de um recurso de consulta ad hoc não permitia aos desenvolvedores a geração 
do código necessário para a produção de simples relatórios. Outra desvantagem considerável é 
a independência de dados totalmente limitada: qualquer tipo de alteração estrutural, por mais 
simples que fosse, poderia devastar todos os aplicativos que obtinham dados do banco. Devido 
a essas restrições, os modelos hierárquicos e em rede foram, consequentemente, substituídos 
pelo modelo de dados relacional na década de 1980.
Modelo Relacional
O modelo relacional foi apresentado, em 1970, por Codd (da IBM), em seu famoso artigo 
A Relational Model Data for Large Shared Data Banks (Um modelo relacional de dados para 
grandes bancos de dados compartilhados).
A base do modelo relacional é calcada no conceito matemático conhecido como relação. 
Na tentativa de diminuir a complexidade da teoria matemática abstrata, podemos pensar uma 
relação (também chamada de tabela) como sendo uma matriz composta por linhas e colunas. 
© Banco de Dados40
O modelo relacional é normalmente implementado por meio de um Sistema de Gerencia-
mento de Banco de Dados Relacionais (SGBDR). Na prática, o SGBDR executa as mesmas funções 
básicas fornecidas pelos Sistemas de Gerenciamento de Banco de Dados Hierárquico e de Rede, 
incorporando também outras funções que tornam o modelo relacional mais simples de enten-
der e implantar.
Uma das vantagens mais significantes do SGBDR é a maneira de ocultar do usuário as 
complexidades do modelo relacional, gerenciando todos os detalhes físicos e permitindo que o 
usuário apenas visualize o banco de dados relacional como uma coleção de tabelas nas quais os 
dados são armazenados.
Por meio do compartilhamento de um determinado atributo comum (valor de uma colu-
na), as tabelas são relacionadas entre si. A Figura 8 apresenta a tabela nomeada de CLIENTE que 
contém um número de corretor, que, por sua vez, também está contida na tabela CORRETOR.
 Nome da Tabela: CORRETOR 
 AGENT_CODE AGENT_NAME AGENT_FNAME AGENT_INITIAL AGENT_AREACODE AGENT_PHONE 
501 Alby Alex B 713 123-3456 
502 Hahn Leah F 615 245-5455 
503 Okon John T 615 234-2353 
 
 Nome da Tabela: CLIENTE 
 
CUS_CODE CUS_LNAME CUS_FNAME CUS_INITIAL 
CUS_AREA_
CODE CUS_PHONE 
CUS_INSURE
_AMT ATEND_CODE 
10010 Ramas Alfred A 713 123-3456 100 502 
10011 Dunne Leona K 615 245-5455 250 501 
10012 Smith Kathy W 615 234-2353 313 502 
10013 Olowski Paul F 456 456-3434 452 502 
10014 Orlando Myron 324 342-5633 346 501 
10015 O’Brian Amy B 657 345-3212 466 503 
10016 Brown James G 864 345-3456 233 502 
10017 Williams George 342 345-5644 322 503 
10018 Farriss Anne G 567 246-3344 34 501 
10019 Smith Olette K 343 247-3456 455 503 
 
 
Ligação por meio de AGENT_CODE 
Figura 8 Relacionamento entre tabelas.
O relacionamento entre as tabelas CLIENTE e CORRETOR permite que você relacione o 
cliente com seu corretor de vendas, mesmo que os dados dos clientes estejam armazenados em 
uma tabela e os dos corretores estejam localizados em outra. Por exemplo, é possível vincular 
facilmente o cliente Leona Dunne com seu respectivo corretor, ora identificado como Alex Alby, 
pois, para o cliente Leona Dunne, o código AGENT_CODE (código do corretor) da tabela CLIENTE 
é 501 (que, por sua vez, corresponde ao AGENT_CODE de Alex Alby na tabela CORRETOR).
Podemos afirmar que o modelo relacional tornou-se a base fundamental de uma revolu-
ção real dos bancos de dados existentes hoje em dia, especialmente pelo fato de incorporar a 
poderosa e flexível linguagem de consulta conhecida como SQL (Structured Query Language), 
a qual permite que o usuário especifique o que deve ser feito sem a necessidade de especificar 
como se deve fazê-lo. 
Claretiano - Centro Universitário
41© U1 – Introdução aos Sistemas de Banco de Dados
Modelo Entidade-Relacionamento
Embora o modelo relacional represente um aprimoramento em relação aos modelos hie-
rárquico e em rede, alguns recursos ainda eram escassos para que ele fosse avaliado como uma 
ferramenta de projeto eficiente. Como é mais objetivo representar estruturas gráficas em vez de 
descrevê-las em texto, os projetistas de bancos de dados preferem utilizar a ferramenta gráfica, 
pois esta permite que as entidades e seus relacionamentos sejam visualizados de maneira sim-
plificada. Dessa forma, o modelo de entidade-relacionamento (ER) ou MER (ERM, sigla em inglês 
para Entity Relationship Model) tornou-se um padrão aceito mundialmente para modelagem de 
dados.
O famoso Peter Chen apresentou pela primeira vez, em 1976, o modelo de dados ER, o 
qual tratava da representação gráfica clara e intuitiva de entidades e seus respectivos relaciona-
mentos em uma estrutura de banco de dados. Tal representação tornou-se popular, pois com-
plementava de forma satisfatória os conceitos do modelo relacional, o qual foi mesclado com o 
MER para construir uma base sólida do projeto de bancos de dados fortemente estruturado. Os 
modelos ER são, geralmente, simbolizados por um diagrama de entidade-relacionamento (DER), 
que utiliza representações gráficas para modelar os componentes do banco de dados.
Veja, a seguir, os componentes que constituem o modelo ER:
• Entidade: representada no DER por um retângulo, e sua identificação é feita por um 
substantivo, escrito de maneira centralizada. Normalmente, é escrito em letras maiús-
culas e no singular: PROFESSOR em vez de PROFESSORES e FUNCIONÁRIO em vez de 
FUNCIONÁRIOS. Quando utilizamos o DER no modelo relacional, é frequente que uma 
entidade seja mapeada para uma tabela relacional, onde cada linha é nomeada como 
instância de entidade ou ocorrência de entidade no modelo ER.
Cada entidade é definida por um conjunto de atributos que descrevem suas caracte-
rísticas específicas. Por exemplo, a entidade FUNCIONÁRIO possuirá como atributos o 
nome e data de nascimento.
• Relacionamento: tem como principal objetivo realizar a associação entre os dados. 
A grande parte dos relacionamentos faz a conexão (relaciona) entre duas entidades. 
Sua identificação, em geral, é realizada por um verbo. São exemplos: um PINTOR pinta 
várias PINTURAS; um FUNCIONÁRIO aprende várias HABILIDADES; um FUNCIONÁRIO 
gerencia uma LOJA.
Nas Figuras 9 e 10 podem ser visualizados os diferentes tipos de relacionamento. Os dois 
casos fazem uso de notações de ER: a notação original de Peter Chen e a notação Crow’s Foot 
(pé de galinha), considerada a notação mais atual.
A Figura 9 apresenta a notação de Peter Chen, em que as conectividades (relacionamen-
tos) são descritas próximas a cada entidade. Graficamente, os relacionamentos são represen-
tados por um losango, o qual é conectado às entidades relacionadas por meio de uma reta. A 
identificação de um relacionamento é escrito no interior do losango.
Já a Figura 10 ilustra a notação pé de galinha. Esse nome é consequência da utilização do 
símbolode três pontas, o qual representa o lado muitos do relacionamento. Podemos observar 
que as conectividades oriundas do DER básico que usa a notação pé de galinha são representa-
das por símbolos. No exemplo, o 1 é representado por um curto segmento de reta e o M, por 
uma forca de três "pés de galinha". Também podemos notar que o nome do relacionamento é 
escrito sobre a reta do relacionamento.
© Banco de Dados42
No exemplo constituinte das Figuras 9 e 10, as entidades e relacionamentos são demons-
trados em um formato horizontal, embora possam ser representados verticalmente. A localiza-
ção, como a ordem de representação das entidades, é irrelevante.
Figura 9 Apresentação da notação de Peter Chen.
Figura 10 Apresentação da notação Pés de Galinha (Crow´s Foot).
Modelo Orientado a Objetos
No modelo de dados orientado a objetos, os dados e seus respectivos relacionamentos 
são contidos em uma única estrutura, conhecida como objeto. Como não poderia deixar de ser, 
o modelo de dados orientado a objetos constitui a base para o SGBDOO.
Diferente do que ocorre com uma entidade, o objeto também inclui, internamente, in-
formações pertinentes aos relacionamentos entre os fatos, assim como informações sobre os 
relacionamentos com outros objetos. Esse tipo de modelo permite que um determinado objeto 
possua todas as ações que podem ser executadas sobre ele, como a alteração, a busca ou a im-
pressão de seus dados.
Os seguintes componentes constituem o modelo de dados orientado a objetos:
1) Objeto: abstração de uma entidade real, podendo ser considerado similar à entidade 
no modelo de ER.
2) Atributos: descrevem propriedades de um objeto. Exemplo: o objeto PESSOA inclui os 
atributos Nome, RG, CPF e Data de Nascimento.
3) Classe: representa um conjunto de objetos comuns, os quais compartilham os atribu-
tos (estrutura) e seus comportamentos (métodos).
4) Método: representa uma ação real. Exemplo: a ação de encontrar uma PESSOA sele-
cionada, alterar o nome da PESSOA ou até mesmo realizar a impressão de seu ende-
reço. Portanto, os métodos correspondem aos procedimentos da linguagem de pro-
gramação tradicional.
5) Hierarquia de classes: assemelha-se a uma estrutura de árvore de cima para baixo, 
em que cada classe possui apenas um pai. Por exemplo, as classes CLIENTE e EMPRE-
GADO herdam características compartilhadas de sua classe pai PESSOA (semelhante 
ao modelo hierárquico).
6) Herança: destina-se à capacidade de um objeto herdar os atributos e seus respecti-
vos métodos das classes superiores (pai). Por exemplo, podemos citar as duas classes 
CLIENTE e FUNCIONÁRIO, as quais podem ser criadas como subclasses da mesma clas-
se PESSOA (pai ou superclasse), herdando todos os atributos e métodos de PESSOA.
A UML (Unified Modeling Language, ou seja, Linguagem de Modelagem Unificada) é uma 
linguagem baseada em conceitos de orientação a objetos que descreve um conjunto de diagra-
Claretiano - Centro Universitário
43© U1 – Introdução aos Sistemas de Banco de Dados
mas e símbolos utilizados para modelar graficamente um sistema computacional. Ele é usado, 
também, para representar o diagrama de classe dos modelos de dados orientados a objetos.
A Figura 11 apresenta os objetos necessários para um cenário simples de faturamento, 
bem como o diagrama de classes equivalente em UML e seu respectivo modelo de ER. Os ob-
jetos da FATURA incluem todos os objetos a ela relacionados. Observamos que seus relaciona-
mentos (1 e M) representam a conectividade dos objetos relacionados com a FATURA, em que 
o número 1, próximo ao objeto CLIENTE, indica que cada FATURA se relaciona única e exclusiva-
mente com apenas um CLIENTE. Enquanto a letra M, localizada próxima ao objeto LINHA, indica 
que cada FATURA contém muitas LINHAS.
O diagrama de classes em UML utiliza três classes distintas de objetos (CLIENTE, FATURA 
e LINHA) e dois relacionamentos. É possível notar que as conexões dos relacionamentos são 
representadas pelos símbolos 1..1, 0..* e 1..*, em que os relacionamentos são expostos na duas 
extremidades permitindo a reprodução de diversos "papéis" que os objetos possam executar. 
Já o modelo ER faz uso, também, de três entidades segmentadas e dois relacionamentos para 
constituir o mesmo cenário.
Figura 11 Diferenças entre os modelos de OO, UML e ER.
Modelo de Dados Relacionais Estendido
Devido à complexidade incremental das aplicações computacionais, o modelo de dados 
relacionais estendido foi criado por meio da utilização dos melhores recursos do modelo orien-
tado a objeto (OO) em um ambiente estrutural de banco de dados relacional. Um SGBD baseado 
em um modelo de dados relacional estendido é, geralmente, representado como um Sistema de 
Gerenciamento de Bancos de Dados Relacionais/Objeto (SGBDR-O).
Esse modelo destina-se, exclusivamente, a aplicações comerciais, enquanto o modelo de 
dados orientado a objeto concentra-se em aplicações científicas e/ou aplicações computacio-
nais específicas (a manipulação e o gerenciamento de imagens médicas, por exemplo).
Para que todo o esquema, as regras armazenadas e controladas pelos SGBDs funcionem 
corretamente, é necessário conhecermos os componentes de processamento de consulta e ad-
ministração de memória. Os componentes de processamento de consultas são softwares que 
promovem interface, de mais alto nível, entre os usuários – sejam eles DBAs (Database Adminis-
trators), usuários finais ou programas de aplicações (também conhecidos como front-end). Os 
componentes incluem:
1) Compilador DML (Data Manipulation Language): realiza a tradução dos comandos 
DML em instruções de baixo nível para o componente de execução de comandos. 
© Banco de Dados44
Possui também a responsabilidade de otimizar, transformando a requisição do usuário 
em uma equivalente, porém mais eficiente, de acordo com o projeto implementado 
pelo banco de dados. É importante lembrar que os dados de baixo nível são dados no 
formato binário ou no formato de linguagem de máquina (a linguagem Assembly, por 
exemplo).
2) Pré-compilador para comandos DML: o pré-compilador atua paralelamente com o 
compilador DML, traduzindo comandos DML manipulados em programas de aplica-
ção, gerando a codificação adequada.
3) Interpretador DDL (Data Definition Language): realiza a interpretação dos comandos 
DDL, armazenando esses registros (metadados) em tabelas internas apropriadas. Me-
tadado é uma abstração do dado capaz, por exemplo, de indicar se determinada base 
de dados existe, quais os atributos de uma tabela e suas características (tamanho e/
ou formato).
4) Pré-compilador DML (Data Manipulation Language ou Linguagem de Manipulação 
de Dados): compila comandos DML em rotinas da linguagem do host. Precisa interagir 
com o processador de consultas para gerar o código apropriado. Host ou Hospedeiro 
é qualquer computador capaz de interpretar e executar rotinas de linguagens que 
convertam o código-fonte em um código- objeto apropriado, isto é, o compilador da 
linguagem interage com o processador, o qual irá dizer sob quais regras o código deve-
rá ser criado e alocado fisicamente, para que este possa ser executado corretamente 
pelo host.
5) Componentes para tratamento de consultas: tem como objetivo principal executar 
instruções de baixo nível geradas pelo compilador DML.
Figura 12 Sistema Gerenciador de Banco de Dados.
Os componentes de administração de memória são responsáveis pelo gerenciamento de 
memória e arquivos do Sistema Gerenciador de Banco de Dados e estabelecem a comunicação 
em baixo nível entre os componentes de processamento de consulta e o repositório de dados. 
Esses componentes são constituídos pelo:
1) Gerenciador de Autorizações e Integridade: aplicativos que realizam os testes ade-
quados para garantir o cumprimento das regras de integridade e as permissões dos 
usuários para acessar os dados.
Claretiano - Centro Universitário
45© U1 – Introdução aos Sistemas de Banco de Dados
2) Gerenciador de Transações: garante que os arquivos de dadossejam mantidos de 
maneira consistente, independentemente de falhas no sistema ou transações concor-
rentes (executadas paralelamente), evitando conflitos entre os procedimentos.
3) Gerenciador de Arquivos: gerencia a alocação de espaço de armazenamento em dis-
co, como suas estruturas utilizadas para representar as informações. 
4) Gerenciador de Buffer: gerencia os dados oriundos do disco (meio de armazenamen-
to), colocando-os na memória principal ou na memória cache.
Além das estruturas apresentadas anteriormente, existem outras estruturas em discos, 
implementadas pelo Sistema Gerenciador de Bancos de Dados, consideradas relevantes. São 
elas:
1) Arquivos de Dados: seria o banco de dados propriamente dito.
2) Dicionário de Dados: realiza o armazenamento das informações relativas à estrutura 
do banco de dados. O dicionário de dados é frequentemente requisitado por várias 
aplicações que constituem o SGBD. É importante destacar que o dicionário de dados 
é um espaço reservado dentro de um banco de dados, utilizado para armazenar in-
formações sobre o próprio banco de dados. Um dicionário de dados pode conter in-
formações como: informações do banco de dados, procedimentos SQL armazenados, 
permissões de usuários, estatísticas do usuário, desempenho e crescimento.
3) Arquivos de Índices: aperfeiçoam o acesso aos dados, auxiliando os algoritmos de 
consulta, por meio da indexação de determinados dados contidos no arquivo de da-
dos.
4) Estatística de Dados: arquivo responsável pelo armazenamento de variáveis referen-
tes às estatísticas relativas aos dados. Essas variáveis são utilizadas pelo processador 
de consultas para selecionar os meios mais eficientes na realização de uma consulta 
específica.
A centralização dos recursos em um SGBD (Figura 12) aumenta a vulnerabilidade do siste-
ma, pois uma falha poderá ocasionar a interrupção das atividades do sistema. 
8. ARQUITETURA EM UM SGBD
Vejamos o que Takai; Italiano e Ferreira (2005) dizem sobre a arquitetura em um Sistema 
Gerenciador de Banco de Dados.
As primeiras arquiteturas utilizavam mainframes para executar o processamento principal e de todas as 
funções do sistema, incluindo os programas aplicativos, os programas de interface com o usuário, bem 
como a funcionalidade dos SGBDs. Esta é a razão pela qual a maioria dos usuários fazia acesso aos sis-
temas via terminais que não possuíam poder de processamento, apenas a capacidade de visualização. 
Todos os processamentos eram feitos remotamente, apenas as informações a serem visualizadas e os 
controles eram enviados do mainframe para os terminais de visualização, conectados a ele por redes 
de comunicação. 
Como os preços do hardware foram decrescendo, muitos usuários trocaram seus terminais por com-
putadores pessoais (PC) e estações de trabalho. No começo, os SGBDs usavam esses computadores da 
mesma maneira que usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade, 
execução de programas aplicativos e processamento da interface do usuário eram executados em ape-
nas uma máquina. 
© Banco de Dados46
Figura13 Arquitetura Cliente-Servidor.
Gradualmente, os SGBDs começaram a explorar a disponibilidade do poder de processamento no lado 
do usuário, o que levou à arquitetura cliente-servidor. 
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de computação onde um grande 
número de PCs, estações de trabalho, servidores de arquivos, impressoras, servidores de banco de da-
dos e outros equipamentos estão conectados juntos por uma rede. 
[...]Desta maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais. Diferentes téc-
nicas foram propostas para se implementar essa arquitetura, sendo que a mais adotada pelos Sistemas 
Gerenciadores de Banco de Dados Relacionais (SGBDR) comerciais é a inclusão da funcionalidade de 
um SGBD centralizado no lado do servidor. As consultas e a funcionalidade transacional permanecem 
no servidor, sendo que este é chamado de servidor de consulta ou servidor de transação. É assim que 
um servidor SQL é fornecido aos clientes. Cada cliente tem que formular suas consultas SQL, prover a 
interface do usuário e as funções de interface usando uma linguagem de programação. 
Figura 14 Sistemas Gerenciadores de Banco de Dados Relacionais.
Claretiano - Centro Universitário
47© U1 – Introdução aos Sistemas de Banco de Dados
Comumente o servidor SQL também é chamado de back-end machine e o cliente de front-end machine. 
Como o SQL provê uma linguagem padrão para os SGBDRs, esta criou o ponto de divisão lógica entre o 
cliente e o servidor. 
Atualmente, existem várias tendências para arquitetura de Banco de Dados, nas mais diversas direções.
Por isso, as arquiteturas de SGBDs podem ter as seguintes configurações:
Plataformas centralizadas. Na arquitetura centralizada, existe um computador com grande capacidade 
de processamento, o qual é o hospedeiro do SGBD e emuladorres para os vários aplicativos. Esta arqui-
tetura tem como principal vantagem a de permitir que muitos usuários manipulem grande volume de 
dados. Sua principal desvantagem está no seu alto custo, pois exige ambiente especial para mainframes 
e soluções centralizadas.
Figura 15 Plataformas Centralizadas.
Sistemas de Computador Pessoal – PC. Os computadores pessoais trabalham em sistema stand-alone, 
ou seja, fazem seus processamentos sozinhos. No começo esse processamento era bastante limitado, 
porém, com a evolução do hardware, tem-se hoje PCs com grande capacidade de processamento. Eles 
utilizam o padrão Xbase e, quando se trata de SGBDs, funcionam como hospedeiros e terminais. Desta 
maneira, possuem um único aplicativo a ser executado na máquina. A principal vantagem desta arqui-
tetura é a simplicidade.
Figura 16 Sistemas de Computador Pessoal.
Banco de Dados Cliente-Servidor. Na arquitetura Cliente-Servidor, o cliente (front_end) executa as ta-
refas do aplicativo, ou seja, fornece a interface do usuário (tela, e processamento de entrada e saída). 
O servidor (back_end) executa as consultas no DBMS e retorna os resultados ao cliente. Apesar de ser 
uma arquitetura bastante popular, são necessárias soluções sofisticadas de software que possibilitem: 
o tratamento de transações, as confirmações de transações (commits), desfazer transações (rollbacks), 
linguagens de consulta (stored procedures) e gatilhos (triggers). A principal vantagem desta arquitetura 
é a divisão do processamento entre dois sistemas, o que reduz o tráfego de dados na rede. 
Banco de Dados Distribuídos (N camadas). Nesta arquitetura, a informação está distribuída em diver-
sos servidores. [...] Cada servidor atua como no sistema cliente-servidor, porém as consultas oriundas 
dos aplicativos são feitas para qualquer servidor indistintamente. Caso a informação solicitada seja 
© Banco de Dados48
mantida por outro servidor ou servidores, o sistema encarrega-se de obter a informação necessária, de 
maneira transparente para o aplicativo, que passa a atuar consultando a rede, independentemente de 
conhecer seus servidores. 
Exemplos típicos dessa configuração são as bases de dados corporativas, em que o volume de informa-
ção é muito grande e, por isso, deve ser distribuído em diversos servidores.
[...]A característica básica é a existência de diversos programas aplicativos consultando a rede para 
acessar os dados necessários, porém, sem o conhecimento explícito de quais servidores dispõem des-
ses dados. 
Figura 17 Banco de Dados Distribuídos.
9. CONSULTAS EM UM SGBD
Os Sistemas de Gerenciamento de Bases de Dados foram criados com o objetivo de ma-
nusear corretamente os dados que gerenciam, e as funções mais executadas em um SGBD são: 
preservar os dados que são guardados em memória e fornecer recursos que possibilitem a sua 
recuperação. 
A responsabilidade dos SGBDs no que diz respeito às informações é grande, pois nenhum 
dado pode sofrer alterações em seu armazenamento ou em sua recuperação. É comum um 
dado ter um carátermodificado devido ao mau funcionamento da memória ou do hardware, 
por onde trafegam as informações.
A estrutura de consulta é o fator de maior influência no desempenho de um sistema e 
representa grande parte dos problemas, uma vez que todas as funcionalidades que recuperam 
dados o fazem por meio de consultas. 
Como parte dos desenvolvedores não tem experiência para determinar qual a melhor 
forma de se estruturar uma consulta, visto que isso, em geral, depende da plataforma em uso, 
esta tarefa quase sempre fica a cargo dos DBAs (Database Administrator ou Administrador de 
Banco de Dados). 
Existem duas formas de realizar a consulta em uma base de dados: 
• utilizando uma linguagem específica de trabalho com base de dados como, por exem-
plo a SQL (Structured Query Language);
• realizando a consulta por meio de exemplo – QBE (Query By Example).
Claretiano - Centro Universitário
49© U1 – Introdução aos Sistemas de Banco de Dados
Mas o que seria realizar uma consulta, quando falamos em banco de dados?
Realizar uma consulta é fazer uma pergunta ao banco de dados, especificando alguns cri-
térios, como: "Quais os nomes dos professores cuja disciplina é Matemática?".
Observe como seria a pergunta em SQL: 
SELECT NomeProfessor FROM Professores WHERE Disciplina= matemática. 
Observe o raciocínio, de acordo com o site Murall (2012), disponível em <http://murall.
com.br/banco-de-dados/>. Acesso em: 23 out. 2012. 
O que acontece se a pergunta for feita de forma errada ou tão confusa, capaz de fazer o sistema a se 
perder na resposta? 
Se a pergunta for incorreta ou confusa o sistema se perde ou, muitas vezes demora em responder ao 
que se deseja, causando queda do desempenho de busca de informações do banco de dados, gerando 
assim, demora no fornecimento da informação ou erro por não encontrar as respostas. Vale lembrar 
que existe um recurso que auxilia na melhoria do desempenho de um dado no processo de busca. Esse 
recurso é conhecido por ÍNDEX ou ÍNDICE, que trabalha como indicador da posição que apresenta a in-
formação que está sendo procurada. O tempo de acesso às linhas de uma tabela é acelerado com esse 
recurso, pois apresenta ponteiros que indicam o local exato da tabela. 
10. QUESTÕES AUTOAVALIATIVAS
Sugerimos que você procure responder, discutir e comentar as questões a seguir que tra-
tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho. 
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão desta 
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de 
forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta 
unidade:
1) O que é um banco de dados?
2) Sabemos que banco de dados e base de dados não são sinônimos. Explique sua diferença.
3) Defina e exemplifique dados e informação. 
4) Como os bancos de dados são classificados? Cite alguns tipos de bancos de dados.
5) Defina um banco de dados temporal.
6) O que é um Sistema Gerenciador de Banco de Dados (SGBD)?
7) Defina os seguintes conceitos:
a) Modelo Conceitual.
b) Modelo Lógico.
c) Modelo Físico.
8) Um desenvolvedor recebe um documento que detalha de maneira precisa e estruturada um banco de dados. O 
desenvolvedor deverá criar um software para acessar o banco de dados por meio de um SGBD. Esse documento 
é um modelo conceitual, um modelo lógico ou um modelo físico?
9) Defina o modelo entidade-relacionamento (MER), detalhando seus principais componentes.
© Banco de Dados50
11. CONSIDERAÇÕES 
Nesta unidade, você teve a oportunidade de compreender a importância e a necessidade 
indiscutível de um Sistema de Gerenciamento de Banco de Dados no mundo atual, o qual de-
pende da tecnologia para realizar o controle das informações.
Você tem ideia da quantidade de informações que é trocada, armazenada e buscada, dia-
riamente, em todos os setores da sociedade? Pode-se dizer que é algo imensurável. É funda-
mental, portanto, que existam regras, arquiteturas, estruturas com níveis bem definidos e mo-
delos de dados para organizar e controlar essa grande quantidade de informação. 
Como futuro projetista de banco de dados, é necessário que você conheça e domine os 
modelos conceituais de banco de dados. Na próxima unidade, você estudará o modelo entida-
de-relacionamento, um modelo conceitual amplamente difundido e utilizado pelos projetistas 
de bancos de dados. 
12. E-REFERÊNCIAS
Lista de figuras 
Figura 1 Banco de Dados. Disponível em: <http://segundoepmedici.blogspot.com.br/2011/08/banco-de-dados-br-modelo.
html>. Acesso em: 01 out. 2012.
Figura 17 Banco de Dados Distribuídos. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=5530>. 
Acesso em: 01 out. 2012.
Sites pesquisados 
MURALL. Banco de Dados. Disponível em: <http://murall.com.br/banco-de-dados/>. Acesso em: 23 out. 2012. 
TAKAI, O. K.; ITALIANO, I. C.; FERREIRA, J. E. Introdução a Banco de Dados. 2005. Disponível em: <http://pt.scribd.com/
doc/51228653/9/Arquiteturas>. Acesso em: 22 out. 2012.
13. REFERÊNCIAS BIBLIOGRÁFICAS
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
RAMAKRISHNAN, R.; GEHRKE, J. Database management systems. 2. ed. Boston: McGraw-Hill, 2000.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementação e Administração. 8. ed. São Paulo: Cengage Learning, 
2011.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de Dados. 5. ed. Rio de Janeiro: Elsevier, 2006.
2
Modelagem dos Dados 
utilizando o Modelo 
Entidade-Relacionamento
1. OBJETIVOS
• Conhecer e analisar as fases de um projeto de banco de dados.
• Desenvolver um projeto conceitual de banco de dados empregando o Modelo Entida-
de-Relacionamento.
• Compreender o Modelo Entidade-Relacionamento Estendido.
2. CONTEÚDOS
• Modelos de banco de dados.
• Definições de objetos do Modelo Entidade-Relacionamento (MER).
• Características adicionais do Modelo Entidade-Relacionamento.
• Projeto conceitual de banco de dados com o Modelo Entidade-Relacionamento.
• Diagrama Entidade-Relacionamento (DER).
• Exemplos de Diagramas Entidade-Relacionamento.
• Modelo Entidade-Relacionamento Estendido (EER).
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE 
Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
© Banco de Dados52
1) O conteúdo desta unidade discorre sobre a modelagem de dados utilizando o Modelo 
Entidade-Relacionamento. Esse modelo é considerado um modelo clássico, ou seja, 
um dos mais utilizados na modelagem de dados.
2) Observe atentamente as definições dos objetos do Modelo Entidade-Relacionamento 
(MER), como também suas características adicionais. Isso, sem dúvida, fará diferença 
em seu aprendizado, sobretudo na elaboração de bancos de dados bem estruturados.
3) Atente-se ao desenvolvimento do projeto conceitual de banco de dados com a aplica-
ção do Modelo Entidade-Relacionamento. Você vai perceber que somente colocando 
a "mão na massa", sua abstração do tema será facilitada.
4) Utilize várias ferramentas para a criação dos DER (Diagrama Entidade-Relacionamen-
to), como o brModelo, Dia etc. Isso facilitará a elaboração dos exercícios propostos.
5) Uma vez que a prática dessa unidade é extremamente importante, faça e refaça, 
quantas vezes forem necessárias, os diversos exemplos de diagramas entidade-rela-
cionamento.
6) Antes de iniciar os estudos desta unidade, é interessante que você conheça um pouco 
sobre Peter Chen. Por isso, sugerimos que leia a breve biografia apresentada a seguir 
e acesseos sites indicados. 
Peter Chen
A notação original para o Modelo Entidade-Relacionamento foi proposta por Peter Chen e é 
composta de entidades (retângulos), relacionamentos (losangos), atributos (círculos) e linhas 
de conexão (linhas) que indicam a cardinalidade de uma entidade em um relacionamento. 
Chen ainda propõe símbolos para entidades fracas e entidades associativas (imagem dispo-
nível em: <http://sankofa.loc.edu/savur/web/peterchen.jpg>. Acesso em: 02 out. 2012. Texto 
adaptado do site disponível em: <http://erealityhome.wordpress.com/2008/08/23/modelo-enti-
dade-relacionamento-mer-peter-chen-1976-2/>. Acesso em: 02 out. 2012). 
4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você aprendeu que os Sistemas Gerenciadores de Bancos de Dados 
foram criados para solucionar os problemas existentes nos sistemas de arquivos, tais como: re-
dundância, inconsistência, compartilhamento e segurança dos dados e das informações.
Nesta unidade, você terá a oportunidade de entender como se desenvolve um projeto 
conceitual de um banco de dados por meio do modelo entidade-relacionamento.
Para facilitar a sua compreensão, antes de iniciarmos nossos estudos sobre o modelo en-
tidade-relacionamento, é fundamental que você conheça detalhadamente as fases que com-
põem um projeto de banco de dados e o que é um modelo de banco de dados. 
5. MODELOS DE BANCO DE DADOS
Um modelo de banco de dados nada mais é do que uma descrição dos tipos de informa-
ções que serão armazenadas em um banco de dados. 
Para que seja possível a construção de um modelo de dados estruturado e consistente, tor-
na-se necessário a utilização de uma linguagem de modelagem de dados. Essas linguagens são 
classificadas baseando-se na maneira em que são representados os modelos de dados, por exem-
plo, a representação por meio de linguagens textuais ou gráficas. Tais linguagens são utilizadas 
para representar modelos de dados em distintos níveis de abstração e com vários objetivos.
Claretiano - Centro Universitário
53© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
Dessa maneira, um esquema de banco de dados pode ser denominado como sendo uma 
representação de um modelo de dados utilizando-se uma linguagem de modelagem de dados 
específica.
O objetivo de um modelo de dados é ser útil na explicação, a um usuário leigo em infor-
mática, sobre a organização utilizada em um determinado banco de dados, pois ele não conterá 
informações detalhadas sobre a representação física das informações. É diferente do que ocorre 
com um modelo de dados usado por um técnico, pois este deverá conter os detalhes sobre a 
organização interna das informações e, portanto, será menos abstrato.
Em um projeto de banco de dados, comumente são utilizados dois níveis de abstração: o 
modelo conceitual e o modelo lógico.
Modelo conceitual
Um modelo conceitual é uma descrição do banco de dados de forma independente de im-
plementação em um SGBD; trata-se um modelo de dados abstrato. O modelo conceitual regis-
tra quais dados podem aparecer no banco de dados, mas não registra como estes dados serão 
armazenados em nível de SGBD; é uma generalização.
Uma das técnicas mais utilizadas mundialmente na modelagem conceitual é a abordagem 
Entidade-Relacionamento (ER). Por meio dela, uma modelagem conceitual é normalmente re-
presentada por um diagrama, este denominado Diagrama Entidade e Relacionamento (DER). A 
Figura 1 ilustra este modelo:
Figura 1 Exemplo de modelo conceitual.
Entre outras coisas, este modelo nos faz entender que o banco de dados contém dados 
sobre produtos e sobre tipos de produtos. Para cada produto, o banco de dados armazena o 
código, a descrição e o preço, bem como o tipo de produto em que está associado. 
Modelo lógico
Um modelo lógico é uma descrição de um banco de dados no nível de abstração visto pelo 
usuário do SGBD, de forma que este modelo é dependente do SGBD que será usado.
Em um modelo lógico, devem ser definidas as tabelas contidas pelo banco e, para cada 
tabela, os nomes das colunas, tais como: 
TipoDeProduto(CodTipoProd, descTipo)
Produto(codProd, descProd, precoProd, codTipoProd)
© Banco de Dados54
O modelo lógico descreve a estrutura do banco de dados, conforme vista pelo usuário di-
reto do SGBD. São detalhes de armazenamento interno de informações, que não têm influencia 
sobre a programação de aplicações no SGBD, mas podem afetar o desempenho da aplicação. 
Fases do projeto de banco de dados
Vimos, anteriormente, que o minimundo representa o domínio relacionado aos dados 
que o banco deve armazenar. Um levantamento dos requisitos desse minimundo é efetuado 
e, a partir da análise de requisitos, é criado o projeto conceitual, representado pelo modelo 
entidade-relacionamento, o qual não contém detalhes de implementação. Trata-se, portanto, 
de um modelo de dados de alto nível, e independente do SGBD a ser adotado. 
A próxima etapa refere-se à criação do projeto lógico, que é realizada por meio do mape-
amento do modelo entidade-relacionamento para o modelo relacional. A partir dessa fase, já se 
pensa em um modelo de dados de implementação do SGBD.
Por fim, a última etapa corresponde à fase do projeto físico, quando são definidos as 
estruturas de armazenamento interno, os índices, além de outras atividades desenvolvidas pa-
ralelamente, como a implementação dos programas de aplicação.
6. DEFINIÇÕES DE OBJETOS DO MODELO ENTIDADE-RELACIONAMENTO 
(MER)
Você já ouviu falar em modelo entidade-relacionamento?
Pois bem, o modelo entidade-relacionamento (MER) foi criado por Peter Chen na década 
de 1970, podendo ser considerado um padrão para a modelagem conceitual. Esse modelo é 
baseado na percepção do mundo real e tem como finalidade a construção de objetos denomi-
nados entidades e a promoção do relacionamento entre eles. 
O MER tem o objetivo de descrever, de maneira conceitual, os dados que serão utilizados 
em um sistema de informações. 
O modelo possui conceitos intuitivos que permitem aos projetistas de bancos de dados 
capturarem os conceitos inerentes aos dados da aplicação, independente de qualquer tecnolo-
gia utilizada para desenvolvimento de bancos de dados. O esquema conceitual criado utilizan-
do-se os conceitos do modelo entidade-relacionamento é denominado de diagrama entidade-
-relacionamento (DER).
Veja, a seguir, a representação do diagrama entidade-relacionamento.
Claretiano - Centro Universitário
55© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
Professor
leciona
Código
Nome
Título
Código
Nome
Disciplina
oferecida
Nome
Código
Curso
Possui
Turma
Aluno
matricula-se
Código
Período Letivo
Início
Término
Idade
Telefone
Endereço
Rua
Número
BairroCódigo
Nome
Sexo
Nascimento
Número Alunos
Data Matrícula
Data Cancelamento
Motivo Cancelamento
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M) (1, M)
Figura 2 Diagrama Entidade-Relacionamento. 
O diagrama entidade-relacionamento é composto por entidades, atributos e relaciona-
mentos. As entidades representam objetos do mundo real; os atributos representam suas ca-
racterísticas; e os relacionamentos, a forma como esses objetos estão ligados entre si. 
Embora o diagrama entidade-relacionamento possua um elemento chamado entidade, 
representado por um retângulo, ele não tem relação com a entidade externa do diagrama de 
fluxo de dados.
Entidade
Uma entidade é um objeto existente e distinto de qualquer outro objeto. Ela tem por fi-
nalidade representar um conjunto de objetos da realidade modelada. Por exemplo, uma pessoa 
chamada João da Silva possui um número de RG único, RG nº. 12.345.678-SP; este número de 
RG é uma entidade, uma vez que identifica a pessoa de uma forma única em relação às outras 
pessoas. Uma entidade pode ser concreta, como uma pessoa ou uma empresa, ou abstrata, 
como um conceito.
Dessa forma, podemos perceber que um conjunto de entidades é um grupo de entidades 
do mesmo tipo. O conjunto de alunos de sua turma, por exemplo,pode ser definido como o 
conjunto de entidades ALUNOS.
Em um DER, uma entidade é representada por um retângulo que contém seu nome, con-
forme demonstrado na Figura 3:
Figura 3 Representação gráfica de entidades.
© Banco de Dados56
Relacionamento
Uma das propriedades sobre as quais pode ser desejável manter associações é a associa-
ção entre objetos. Na Figura 3, por exemplo, pode ser válido conhecer apenas as pessoas de um 
dado departamento. Logo, uma pessoa tem de estar associada a um departamento para que 
esta classificação obtenha êxito. 
No modelo de representação DER, um relacionamento é apresentado por meio de um 
losango, ligado por linhas aos retângulos.
A Figura 4 demonstra o relacionamento existente entre as entidades FUNCIONÁRIO e PESSOA:
Figura 4 Representação gráfica de relacionamento.
A partir do relacionamento entre as entidades (Figura 4), é possível nos referirmos a asso-
ciações específicas dentro de um conjunto. No caso do relacionamento ASSOCIAÇÃO, uma ocor-
rência seria um par específico formado por uma determinada ocorrência da entidade PESSOA e 
por outra da entidade DEPARTAMENTO.
Um relacionamento não ocorre, necessariamente, entre entidades diferentes. Também é 
possível um relacionamento entre ocorrências de uma mesma entidade, ou seja, o autorrelacio-
namento (conforme demonstrado na Figura 5). 
Figura 5 Demonstração do autorrelacionamento.
Para se entender melhor o conceito de autorrelacionamento, é importante compreender 
o conceito de papel da entidade no relacionamento.
Papel de entidade em relacionamento exerce a função que uma instância da entidade 
cumpre dentro de uma instância do relacionamento.
No exemplo do relacionamento de CASAMENTO, uma ocorrência de pessoa exerce o papel 
de marido e a outra ocorrência de pessoa exerce o papel de esposa.
Cardinalidade de relacionamentos
Um diagrama entidade-relacionamento pode definir restrições com as quais o banco de 
dados deve estar de acordo. Uma dessas restrições é a cardinalidade do mapeamento, que ex-
pressa o número de entidades relacionadas a outras entidades por meio de um conjunto de 
relacionamentos. 
Tomemos por referência o DER representado pela Figura 4. Considere as cardinalidades 
máximas: 
1) A entidade PESSOA tem cardinalidade máxima 1 no relacionamento ASSOCIAÇÃO. Isso 
significa que uma ocorrência de PESSOA pode estar associada à, no máximo, uma 
ocorrência de DEPARTAMENTO ou, em outras palavras, que um empregado pode estar 
associado à, no máximo, um departamento.
Claretiano - Centro Universitário
57© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
2) A entidade DEPARTAMENTO tem cardinalidade máxima 120 no relacionamento ASSO-
CIAÇÃO. Isso significa que uma ocorrência de DEPARTAMENTO pode estar associada 
à, no máximo, 120 ocorrências de PESSOA, ou seja, um departamento pode associar 
apenas 120 pessoas.
3) A cardinalidade máxima é 1.
4) A cardinalidade máxima ilimitada, usualmente chamada de cardinalidade máxima 
"muitos" é referia pela letra n ou m.
Disciplina Professor Código
Nome
Título
lecionaCódigo
Nome
(1, M) (1, M)
Figura 6 Cardinalidade de Mapeamento. 
No exemplo demonstrado na Figura 6, temos as cardinalidades mínima e máxima para 
o relacionamento. Observe que um ALUNO pode MATRICULAR-SE em várias TURMAS, e uma 
TURMA pode ter vários ALUNOS MATRICULADOS. Portanto, a cardinalidade máxima desse rela-
cionamento é muitos-para-muitos.
Veja os tipos de relacionamentos entre entidades binárias:
• Um-para-um: uma entidade de EMPREGADO está associada a apenas uma entidade de 
MESA, conforme a Figura 7:
1 1
Figura 7 Relacionamento 1:1.
• Um-para-muitos: uma entidade de CURSO está associada a muitas entidades de ALU-
NO; entretanto, uma entidade de ALUNO está associada a apenas uma entidade de 
CURSO (Figura 8):
N 1
Figura 8 Relacionamento 1:N.
• Muitos-para-muitos: uma entidade de MÉDICO está associada a qualquer quantidade 
de entidades de PACIENTE, e uma entidade de PACIENTE está associada a qualquer nú-
mero de entidades de MÉDICO, conforme ilustrado na Figura 9:
N N
Figura 9 Relacionamento N:N.
© Banco de Dados58
Relacionamento ternário
Até o momento, os exemplos demonstraram relacionamentos binários, ou seja, entre ape-
nas duas entidades. A abordagem ER permite maiores graus entre as relações, como pode ser 
observado na Figura 10, na qual temos um exemplo de relacionamento ternário:
Figura 10 Relacionamento ternário.
No relacionamento nomeado de DISTIBUIÇÃO, cada ocorrência vincula outras três ocor-
rências de entidade, isto é, um produto a ser distribuído, uma cidade na qual é realizada a distri-
buição, e por fim, um distribuidor. Quando possuímos relacionamentos superiores a dois (biná-
rios), como ternário e "n"ário a cardinalidade é semelhante à cardinalidade de relacionamentos 
binários, ou seja, quando temos um relacionamento ternário, a cardinalidade trabalha com pa-
res de entidades. Para exemplificar, imagine a existência de um relacionamento identificado de 
R entre as entidades X, Y e Z. A cardinalidade máxima obtida entre X e Y dentro de R indica a 
quantidade de ocorrências de Z que podem estar vinculadas a um par de ocorrências de X e Y.
De acordo com o relacionamento verificado na Figura 11, o número 1 na linha que liga o 
retângulo representativo da entidade DISTRIBUIDOR ao losango representativo do relaciona-
mento expressa que cada par de ocorrências (CIDADE, PRODUTO) está associado a, no máximo, 
um distribuidor.
N
N
1
Figura 11 Cardinalidade em relacionamento ternários.
Claretiano - Centro Universitário
59© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
Generalização/especialização 
Não nós limitamos apenas aos relacionamentos e seus atributos, podemos ainda abstrair-
mos propriedades à entidades por meio do uso do conceito de generalização/especialização. 
Parece complicado? Não tanto! Isso nos permite atribuir propriedades específicas a um sub-
conjunto de ocorrências (especialização) de uma entidade considerada genérica. A simbologia 
utilizada para representar generalização/especialização é um triângulo isósceles, conforme você 
pode visualizar na Figura 12. Nessa mesma figura, o conceito de generalização/especialização 
sinaliza que a entidade CLIENTE é segmentada em dois subconjuntos, esses representados pelas 
entidades nomeadas respectivamente de PESSOA FÍSICA e PESSO JURÍDICA, em que cada uma 
possui propriedades específicas.
Figura 12 Exemplo de generalização/especialização. 
Ao analisar a Figura 12 podemos observar a aplicação do conceito de herança, por meio 
do seguinte raciocínio, baseado no paradigma da orientação a objetos: PESSOA FÍSICA é um 
CLIENTE, da mesma forma que PESSOA JURÍDICA, pois, ambos os subconjuntos herdam carac-
terísticas gerais da entidade CLIENTE, e em conformidade com o tipo do cliente, acrescentam 
propriedades específicas.
A aplicação da generalização/especialização implica que a entidade PESSOA FÍSICA, além 
de possuir suas características específicas, possui também todas aquelas contidas da entidade 
CLIENTE, ou seja, a entidade PESSOA FÍSICA possui os seguintes atributos: CIC, sexo, nome e 
código, sendo os dois últimos provenientes da entidade genérica CLIENTE.
De modo similar, a entidade PESSOA JURÍDICA, possui os seguintes atributos: CGC, tipo de 
organização, bem como o nome e código, sendo estes, oriundos da entidade CLIENTE.
Ao fazermos uso da generalização/especialização, esta pode ser classificada nos seguintes 
tipos: total ou parcial. Esta classificação dá-se mediante a obrigatoriedade ou não, dos atributos 
de uma entidade genérica fazer correspondência à ocorrência de uma entidade especialista.
A classificação total implica que, sempre que houver um registro na entidade genérica, 
CLIENTE, deverá implicar em um registro em uma das entidades especialistas. Tomando como 
exemplo o diagrama expresso na Figura 12, sempre que houver uma ocorrência de um CLIEN-
TE, espera-se que uma ocorrência de PESSOA FÍSICAou PESSOA JURÍDICA se realize também. A 
classificação total pode ser indicada graficamente na modelagem, por meio da inserção de um t 
como símbolo, conforme indicado na Figura 13.
© Banco de Dados60
Figura 13 Exemplo de generalização/especialização total.
Uma vez que entendemos o processo de generalização/especialização total, entendere-
mos, agora, como a parcial funciona. A classificação parcial implica que nem toda ocorrência 
de registros na entidade genérica deve possuir uma ocorrência em algum dos subconjuntos 
pertinentes (entidades especialistas). De forma análoga à generalização/especialização total, a 
parcial é representada no diagrama na forma de letra p. Veja, na Figura 14, a aplicação.
Como você pode observar na Figura 14, e seguindo o conceito de parcialidade, entende-se 
que nem todo FUNCIONARIO necessariamente deve ser também um MOTORISTA ou uma SE-
CRETARIA, ou seja, o conceito inverso ao conceito de totalidade. Geralmente na especialização 
parcial verifica-se um atributo na entidade genérica que tem por finalidade identificar o tipo de 
ocorrência. Em especializações totais, este atributo normalmente é dispensável, pois há a cer-
teza de que a existência de um registro na entidade genérica está necessariamente associada a 
um registro em uma entidade especialista qualquer.
Figura 14 Exemplo de generalização/especialização parcial.
A especialização de entidades, a priori, não é limitada quanto a quantidade de entidades 
especialistas, podendo ser a partir de 1 até N. Analisando o diagrama na Figura 14, podemos 
perceber que se a entidade SECRETARIA não apresentar atributos característicos a sua desig-
nação, a existência da mesma seria desnecessária, permanecendo assim apenas uma entidade 
especialista MOTORISTA.
Claretiano - Centro Universitário
61© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
É importante ressaltar que também não se verifica limitação quanto ao número de hie-
rarquias, ou níveis hierárquicos. Ou seja, uma entidade já especialista de uma genérica também 
pode conter outras entidades que são especialistas desta. Por exemplo, a entidade MOTORISTA 
é uma especialização da entidade FUNCIONÁRIO, todavia, nada impede que a entidade MOTO-
RISTA tenha outras entidades especialistas.
Nesse relacionamento, a generalização/especialização exclusiva, é aplicado quando da ne-
cessidade que uma ocorrência de uma entidade genérica, seja associada a uma e apenas uma 
entidade especialista. A Figura 15 demonstra o emprego desta necessidade, tomando como re-
ferencial a entidade AUTOMOVEL, observamos que esta é uma entidade especialista de VEICULO 
TERRESTRE, e esta é especialista da entidade VEICULO. Considerando os conceitos aprendidos 
até o momento, podemos dizer que a entidade AUTOMOVEL possui além de suas propriedades 
específicas, as propriedades de VEICULO TERRESTRE e VEICULO.
Figura 15 Exemplo de generalização/especialização com múltiplos níveis de herança.
Entidade associativa 
Até agora, você pôde compreender que um relacionamento nada mais é que associações 
entre uma ou mais entidades; o DER que empregamos para a construção do modelo de dados 
não previu situações em que fosse possível associar uma entidade diretamente a um relaciona-
mento. Outro contexto que também não se faz possível é a associação de dois relacionamentos, 
um com o outro.
No uso cotidiano das ferramentas e técnicas de modelagem de dados, frequentemente 
nos deparamos com situações em que se faz necessário os relacionamentos descritos. Nos apro-
fundaremos nessa assunto, para isso, observe a Figura 16.
Ao analisarmos a Figura 16 verificamos a relação N:N, por meio do relacionamento CON-
SULTA entre MEDICO e PACIENTE, ou seja, um médico pode consultar vários pacientes, e um 
paciente pode ser consultado por vários médicos. Em cada uma das consultas, provavelmente, 
medicamentos serão prescritos aos pacientes. Vamos supor que seja necessário catalogar cada 
medicamento indicado nas consultas, no primeiro momento, você pode estar pensando em 
constituir uma outra entidade, algo como MEDICAMENTO. Até então tudo bem, mas pense, 
onde deve ser realizado o relacionamento com a nova entidade? Com a entidade MEDICO ou 
PACIENTE? Se relacionarmos a nova entidade, MEDICAMENTO, com a entidade MEDICO, sa-
beríamos apenas os medicamentos prescritos por determinado médico, sem a indicação do 
paciente. Caso associássemos com PACIENTE saberíamos quais medicamentos foram prescritos 
para cada PACIENTE mais não saberíamos qual foi o médico. A solução para o problema seria re-
lacionarmos a entidade MEDICAMENTO com a CONSULTA, onde será possível obter informações 
tanto do médico quanto do paciente.
© Banco de Dados62
Para suprir a necessidade de relacionar uma entidade diretamente com um relacionamen-
to foi criado o conceito de entidade associativa. O conceito de entidade associativa é simples, é 
uma redefinição do relacionamento existente, onde este passa a assumir o papel de uma entida-
de. Para indicarmos graficamente, basta adicionar um retângulo em torno do losango indicativo 
do relacionamento, como demonstrado na Figura 16.
Uma entidade associativa nada mais é do que a redefinição de um relacionamento, que 
passa a ser tratado como se fosse também uma entidade. Graficamente, isso é feito como mos-
trado na Figura 16. Veja:
Figura 16 Exemplo de entidade associativa.
Observe que até então apenas relacionamento CONSULTA passou a ser considerado como 
uma entidade associativa e, para identificarmos isto, existe a figura do losango no entorno do 
relacionamento CONSULTA. Neste momento, o relacionamento passa a ser entendido em con-
formidade com o conceito de entidade, como uma entidade pode ser associada a outras, o 
problema que descrevemos anteriormente está resolvido. Basta que a entidade MEDICAMENTO 
seja associada à entidade associativa CONSULTA, por meio do relacionamento PRESCRICAO.
Tipos de atributos
Após conhecer a definição de atributos, veja, no Quadro 1, os vários tipos de atributos e 
suas aplicações específicas. 
Quadro 1 Descrição dos Tipos de Atributos.
TIPOS DE ATRIBUTOS DESCRIÇÃO
Atributo Simples É um atributo que contém uma informação atômica, ou seja, uma informação que não pode ser subdividida
Atributo Composto
É um atributo que contém várias informações que podem ser decompostas e separadas em 
outros atributos, e devem ser do tipo simples, ou seja, indivisíveis. Vejamos, por exemplo, o 
atributo Endereço, que, provavelmente, conterá uma informação do tipo Rua das Margaridas, 
125 – Jardim Primavera – Green Ville. Em alguns casos, o endereço pode conter o CEP e o Estado, 
embora seja menos comum. Esse atributo é conhecido como atributo composto, pois pode ser 
dividido em cinco atributos, a saber:
tipo do logradouro: Rua;
logradouro: das Margaridas;
número: 125;
bairro: Jardim Primavera;
cidade: Green Ville. 
Claretiano - Centro Universitário
63© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
TIPOS DE ATRIBUTOS DESCRIÇÃO
Atributo Multivalorado
Este atributo pode receber muitos valores para uma única entidade. Um exemplo clássico deste 
tipo de atributo é o número de telefone de uma pessoa. Atualmente, é comum a pessoa possuir 
telefone fixo e celular. Nesse caso, dizemos que o atributo Telefone é um atributo multivalorado. 
Outro exemplo para esse caso é um atributo para armazenar o e-mail de uma pessoa. É bastante 
comum uma pessoa possuir mais de um endereço de e-mail e, portanto, este também pode ser 
considerado um atributo multivalorado.
Atributo Derivado 
Este atributo representa uma informação que pode ser obtida por meio de um processamento 
no banco de dados. Vejamos: se você tem uma entidade chamada Pedido e nela é criado 
um atributo para armazenar o Total do Pedido, este atributo (Total do Pedido) é um atributo 
derivado porque seu valor pode ser obtido multiplicando-se a quantidade do produto pelo preço 
unitário para cada produto constante no pedido. 
ATENÇÃO! 
O valor nuloé utilizado quando o atributo não tem um valor aplicável ou quando seu valor é 
desconhecido. É importante frisar que NULO (Null) não é 0 (zero).
Atributo-Chave
Toda entidade deve ter, ao menos, um atributo-chave que será utilizado para identificá-la de 
forma única, não importando se este atributo é simples ou composto.
Considere, como exemplo, uma entidade de Pessoas: pode ser um atributo-chave o RG, o CPF ou 
um código.
Um atributo correlaciona informações à ocorrência de entidades ou até mesmo de rela-
cionamentos. Normalmente, os atributos são representados graficamente, conforme você pode 
visualizar na Figura 17, entretanto, na prática isso não é aplicado devido a possibilidade de so-
brecarregar os diagramas, visto que, frequentemente, as entidades podem possuir um grande 
número de características.
Figura 17 Atributos de uma entidade.
Do mesmo modo que entidades podem possuir atributos, relações também podem apre-
sentá-los. A Figura 18 mostra um DER, no qual um relacionamento, ATUAÇÃO, possui um atribu-
to, a função que um engenheiro exerce dentro de um projeto:
Figura 18 Atributo de relacionamento n:n.
© Banco de Dados64
7. CARACTERÍSTICAS ADICIONAIS DO MODELO ENTIDADE-RELACIONAMENTO
As entidades do modelo entidade-relacionamento são classificadas em entidades e enti-
dades-fracas. Entidades são aquelas que não dependem de nenhuma outra entidade e entida-
des-fracas são as dependentes de outra entidade.
Todavia, duas ou mais entidades podem ser associadas por meio de um relacionamento, 
no qual devem estar indicadas as Cardinalidades de Mapeamento do Relacionamento. As cardi-
nalidades expressam a quantidade de entidades associadas. 
Tipos de entidade
As entidades têm um ou mais atributos-chave que, juntos, a identificam de forma única. 
Porém, alguns tipos de entidade não possuem atributos-chave e são chamados de entidades-
-fracas. 
As entidades-fracas, em síntese, dependem de outras entidades. Sua identificação é possí-
vel por meio da associação dos atributos-chave da entidade proprietária e de sua chave parcial. 
Em algumas situações, uma entidade-fraca pode ser substituída por atributos multivalorados.
Observe, na Figura 19, um exemplo de entidade-fraca. A entidade DEPENDENTE é uma 
entidade-fraca, pois depende de um FUNCIONÁRIO.
Funcionário
Código
Nome
Dependente
Nome
Sexo
possui(1, M)
(1, 1)
Data Nascimento
Figura 19 Entidade-Fraca.
8. PROJETO CONCEITUAL DE BANCO DE DADOS COM O MODELO ENTIDADE-
-RELACIONAMENTO
A partir deste tópico, você acompanhará o desenvolvimento de um diagrama entidade-
-relacionamento para um sistema de bancos de dados. Mas, primeiro, é necessário que você 
conheça os símbolos utilizados em um DER.
Quadro 2 Símbolos utilizados em um modelo-relacionamento.
ELEMENTO SÍMBOLO DESCRIÇÃO
Entidade
 
Representada por um retângulo.
Claretiano - Centro Universitário
65© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
ELEMENTO SÍMBOLO DESCRIÇÃO
Entidade-Fraca Representada por um retângulo com linhas duplas.
Relacionamento
 
Representado por um losango.
Atributo Simples
 
Representado por uma elipse.
Atributo Multivalorado Representado por uma elipse com linhas duplas.
Atributo Derivado
 
Representado por uma elipse com 
linhas tracejadas.
Atributo Composto
 
Representado pela junção de vários 
atributos que podem ser simples, 
compostos ou derivados.
Atributo-Chave
 
CHAVE 
Representado por uma elipse, como 
o atributo simples, e o texto deve 
estar sublinhado.
Observe, na Figura 20, um exemplo de diagrama entidade-relacionamento.
Código
Turma
Período Letivo
Início
Término
matricula-se Aluno
Idade
Telefone
Endereço
Código
Nome
Sexo
Nascimento
Rua
Número
Bairro
Número Alunos
Data Matrícula
Data Cancelamento
Motivo Cancelamento
(1, M) (1, M)
Figura 20 Diagrama Entidade-Relacionamento.
© Banco de Dados66
9. DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)
Agora que você conhece os símbolos utilizados em um diagrama entidade-relacionamen-
to, é fundamental compreender que este deve ser construído com base nos dados obtidos com 
o usuário na fase de Análise do Sistema de Informação. Após obter todas as informações neces-
sárias (os requisitos), inicia-se a construção propriamente dita do DER. 
Para desenvolver o DER para um Sistema Escolar, é preciso definir as entidades (Professor, 
Disciplina, Turma, Curso e Aluno) que serão utilizadas no projeto do banco de dados, as quais 
são representadas por um retângulo. Veja que o nome de uma entidade é sempre um substan-
tivo no singular. 
Pressman (1995, p. 324) propõe seis regras para a definição de objetos para modelos 
orientados a objetos, que podem ser aplicadas para as entidades dos bancos de dados relacio-
nais com grande sucesso. Confira a seguir:
Informação Retida: o objeto em potencial será útil durante a análise se a informação sobre ele precisar 
ser lembrada de forma que o sistema possa funcionar.
Exemplo: Aluno, Curso.
Serviços Necessários: o objeto em potencial deve ter um conjunto de operações identificáveis que po-
dem mudar o valor de seus atributos de alguma maneira.
Exemplo: Inclusão, Alteração.
Múltiplos Atributos: durante a análise de requisitos, o foco deve recair sobre informações "importantes", 
um objeto com um único atributo pode, de fato, ser útil durante a fase de projeto, mas provavelmente ele 
será mais bem representado como um atributo de um outro objeto durante a atividade de análise. 
Exemplo: estoque (Quantidade). Este atributo ficaria mais bem modelado como o atributo QUANTIDA-
DE_ESTOQUE da entidade PRODUTO.
Atributos Comuns: os atributos definidos para um objeto em potencial; esses atributos aplicam-se a 
todas as ocorrências do objeto.
Exemplo: na entidade ALUNO, o atributo NUMERO_RESERVISTA não se encaixaria em todas as ocor-
rências, pois esse documento é solicitado apenas a alunos do sexo masculino. O ideal, nesse caso, é 
repensar o modelo e remover esse atributo da entidade ALUNO.
Operações Comuns: as operações definidas para um objeto em potencial; essas operações aplicam-se 
a todas as ocorrências do objeto.
Exemplo: as operações Inclusão ou Alteração podem ser feitas em todas as ocorrências da entidade 
ALUNO.
Requisitos Essenciais: entidades externas que aparecem no espaço problema e produzem ou conso-
mem informações que são essenciais à operação de qualquer solução para o sistema quase sempre 
serão definidas como objetos no modelo de requisitos.
Exemplo: a entidade externa ALUNO, que certamente estaria definida no DFD, consome e gera informa-
ções no sistema e, portanto, foi especificada como uma entidade no Diagrama Entidade-Relacionamento. 
Nas regras definidas por Pressman, troque objeto por entidade e você perceberá que elas 
se aplicam totalmente.
Após definir as entidades, é preciso compreender que os atributos são representados por 
elipses. Lembre-se que o atributo é um substantivo no singular, assim como a definição de uma 
entidade. Ele pode ser:
1) simples: linha contínua;
2) composto: quando têm mais atributos ligados a si;
3) chave: quando o nome do atributo está sublinhado;
4) multivalorado: quando as linhas são duplas; 
5) derivado: quando as linhas são tracejadas. 
Claretiano - Centro Universitário
67© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
Para definir quais atributos adicionar a uma entidade, o projetista de bancos de dados uti-
liza como critério as informações necessárias obtidas no levantamento realizado com o usuário 
que solicitou o sistema de informações.
Lembre-se de que os relacionamentos são representados por losangos e podem ser utili-
zados para nomear verbos, advérbios ou preposições, de modo que a sequência das entidades 
tenha sentido, quase como uma frase. 
Veja o caso do relacionamento leciona entre as entidades PROFESSOR e DISCIPLINA. Len-
do-se como uma frase, temos: PROFESSOR-LECIONA-DISCIPLINA. Outro exemplo é o relacio-
namento matricula-se, entre ALUNO e TURMA. Lendo-se a partir da entidade ALUNO,temos: 
ALUNO-MATRICULA-SE-TURMA.
10. EXEMPLOS DE DIAGRAMAS ENTIDADE-RELACIONAMENTO
Veja, a seguir, alguns exemplos de diagramas entidade-relacionamento:
a) Sistema Escolar:
Professor
leciona
Código
Nome
Título
Código
Nome
Disciplina
oferecida
Nome
Código
Curso
Possui
Turma
Aluno
matricula-se
Código
Período Letivo
Início
Término
Idade
Telefone
Endereço
Rua
Número
BairroCódigo
Nome
Sexo
Nascimento
Número Alunos
Data Matrícula
Data Cancelamento
Motivo Cancelamento
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M) (1, M)
Figura 21 Diagrama Entidade-Relacionamento para um Sistema Escolar.
O exemplo anterior representa o projeto de um banco de dados simples para uma 
escola. Na entidade ALUNO, podemos observar alguns detalhes, tais como: o atributo 
TELEFONE é multivalorado (elipse com borda dupla), pois o aluno pode ter telefone 
fixo, celular, de recados etc.; o atributo ENDEREÇO é composto, pois é formado por 
Rua, Número e Bairro.
No relacionamento MATRICULA-SE, há o atributo derivado NÚMERO ALUNOS. Esse 
atributo não será criado na estrutura das tabelas do futuro banco de dados, porque 
essa informação pode ser obtida a partir da contagem dos alunos matriculados na 
turma e certificando-se que a data de cancelamento esteja vazia (null).
Dessa forma, percebemos que a data de matrícula é um atributo multivalorado, pois 
o aluno pode se matricular em várias turmas e, para cada matrícula é gravada a data 
em que ela foi efetivada.
© Banco de Dados68
b) Controle de Estoque:
Figura 22 Diagrama Entidade-Relacionamento para um sistema de controle de estoque.
Neste exemplo, temos o controle de estoque de produtos de uma empresa de com-
pra e venda. Na entidade COMPRA, há um atributo derivado VALOR_TOTAL, que re-
presenta o valor total de todos os produtos comprados. No relacionamento POSSUI 
também há um atributo derivado chamado VALOR_TOTAL_PAGO, que é resultado da 
multiplicação dos atributos QTDE_COMPRADA e PREÇO_PAGO. Como você pode per-
ceber, uma solução semelhante é observada na entidade VENDA e no relacionamento 
VALOR_TOTAL_COBRADO.
c) Projetos de um Departamento:
Figura 23 Diagrama Entidade-Relacionamento para um sistema de gerenciamento de projetos. 
Na Figura 23 temos a representação dos empregados que trabalham em um depar-
tamento, bem como dos projetos em que eles trabalham. Observe que há uma enti-
dade-fraca chamada DEPENDENTE, que representa os cônjuges, filhos e outros que 
Claretiano - Centro Universitário
69© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
possam depender legalmente do funcionário. Essa é uma entidade-fraca, uma vez que 
não há a necessidade de registrar as informações dos dependentes se antes não fo-
rem registradas as informações do empregado.
Nesse diagrama há, também, um autorrelacionamento na entidade EMPREGADO, 
que representa qual empregado é o supervisor dos demais. Fique atento, pois, nesse 
exemplo, foram indicadas apenas as cardinalidades máximas.
d) Atendimento a Pacientes:
Figura 24 Diagrama Entidade-Relacionamento para um sistema de controle de pacientes.
Nesse exemplo, temos como característica marcante a agregação, que é o retângulo 
existente em MÉDICO atende PACIENTE. Ela foi utilizada porque a RECEITA, que é uma 
entidade-fraca, somente passa a existir depois que o médico atende o paciente. Antes 
disso, não há a necessidade da receita. A cardinalidade mínima nesse relacionamento 
é 0 (zero), pois existem consultas que não necessitam de receitas de medicamentos.
Você sabe por que, nesse caso, foi utilizada uma agregação? 
Ela foi utilizada porque a entidade-fraca RECEITA precisa se relacionar com o relaciona-
mento ATENDE (que contém as informações de qual médico atendeu qual paciente). 
Além disso, devemos nos lembrar de que não é permitido haver um relacionamento 
com outro relacionamento. Assim, agrega-se o relacionamento com suas entidades 
participantes e relaciona-se a entidade-fraca com a agregação.
11. MODELO ENTIDADE-RELACIONAMENTO ESTENDIDO (EER)
Quase todas as aplicações de bancos de dados podem ser representadas por meio do 
modelo entidade-relacionamento. Entretanto, alguns bancos de dados são mais complexos e 
exigem, para sua melhor representação, alguns aspectos adicionais.
Para solucionar esse problema, o modelo ER é expandido para o modelo EER. Esse modelo 
inclui, além dos novos conceitos, todos os conceitos de modelagem do modelo ER.
Veja, a seguir, os conceitos relacionados ao modelo EER.
Subclasse
Estudamos, anteriormente, que um conjunto de entidades possui entidades do mesmo 
tipo, caracterizando um tipo entidade. Ao pensar em um banco de dados de uma universidade, 
© Banco de Dados70
consideramos que ALUNO seja um tipo entidade. Se pudermos dividir os alunos em alunos de 
graduação e alunos de pós-graduação, teríamos, então, duas subclasses de ALUNO, ou seja, as 
subclasses ALUNOGRAD e ALUNOPOSGRAD. 
Superclasse
De acordo com o exemplo anterior, podemos dizer que ALUNO é superclasse de ALUNO-
GRAD e ALUNOPOSGRAD.
Herança
Ao conceito de superclasse e subclasse está associado o conceito de herança. Isso significa 
que uma entidade de uma subclasse representa a mesma entidade da superclasse, ou seja, os 
membros de uma subclasse herdam todos os atributos e relacionamentos da sua superclasse. 
No exemplo do banco de dados de uma universidade, isso indica que todo aluno de gra-
duação é um aluno, e que todo aluno de pós-graduação também é um aluno. Cada membro de 
ALUNOGRAD e de ALUNOPOSGRAD herda todos os atributos definidos para ALUNO, assim como 
seus relacionamentos. Vale lembrar, ainda, que os atributos das subclasses de uma mesma su-
perclasse são diferentes, e que uma subclasse pode se relacionar com uma classe que não se 
relaciona com outra subclasse da mesma superclasse.
Especialização
Entende-se por especialização a definição de um conjunto de subclasses de um tipo de 
entidade, a partir de uma superclasse.
Generalização
Generalização é a definição de um tipo entidade (superclasse) a partir de suas subclasses, 
ou seja, com base nas características comuns a todas as subclasses cria-se uma superclasse, e 
essas características são atribuídas apenas à superclasse.
Observe exemplos de generalização nas Figuras 25 e 26.
 
ALUNOPOSGRAD
 
 posgrad 
 
anodefesa
 
 nome 
 RA 
endereco 
 
ALUNOGRAD 
 curso 
 turma 
 turno 
 nome 
 RA 
 endereco 
Figura 25 Dois tipos de entidade em Processo de Generalização.
Claretiano - Centro Universitário
71© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
 
 
ALUNO 
 RA 
 nome 
 endereco 
d 
 
 
ALUNOGRAD 
 
 
ALUNOPOSGRAD
 
 anodefesa 
 posgrad 
 turno 
 turma 
 curso 
Figura 26 Generalizando ALUNOGRAD e ALUNOPOSGRAD na superclasse ALUNO.
A Figura 26 também pode ser considerada uma Especialização, caso essa especialização 
esteja sendo definida pelo atributo TIPOALUNO, por exemplo.
Uma especialização pode ser definida por predicado, quando há uma condição no valor 
de algum atributo da superclasse. É o caso explicado no parágrafo anterior, ou seja, um aluno 
pertencerá à subclasse ALUNOGRAD ou ALUNOPOSGRAD dependendo do valor contido no atri-
buto TIPOALUNO.
Quando não existe essa condição, dizemos que a subclasse é definida pelo usuário.
Restrições na especialização e generalização
Duas restrições devem ser consideradas na especialização:
1) Restrição de disjunção: especifica que as subclasses da especialização devem ser mu-
tuamente exclusivas, ou seja, uma entidade pode pertencer a somente uma subclasse 
da especialização. Este é o caso do nosso exemplo: um aluno é, obrigatoriamente, alu-
no de graduação ou de pós-graduação. O círculo com a letra d (do inglês disjointness) 
dentro especifica essa situação. 
Contrária a essa situação, temos que uma entidade pode pertencer a mais de uma 
subclasse ao mesmo tempo.Nesse caso, dizemos que há uma sobreposição, ou seja, 
uma mesma entidade pode pertencer a mais de uma subclasse da especialização. 
Seria o caso de um aluno fazer pós-graduação e uma graduação em outra área, ao 
mesmo tempo. A representação é feita por um círculo com a letra o dentro (overlap).
Se uma superclasse tiver apenas uma subclasse, não há necessidade de colocar o cír-
culo com a letra dentro, pois, nesse caso, nunca haverá disjunção ou sobreposição.
2) Restrição de integralidade: pode ser total ou parcial. Será total quando toda entidade 
de uma superclasse pertencer a, pelo menos, uma das subclasses dessa superclasse; 
neste caso, é representada por um traço duplo. A restrição será parcial quando uma 
entidade da superclasse não pertencer a nenhuma das subclasses definidas; é repre-
sentada por um traço simples.
© Banco de Dados72
Há quatro possibilidades de restrições, considerando-se que os dois tipos (total e par-
cial) de restrições são independentes:
a) Disjunção total.
b) Disjunção parcial.
c) Sobreposição total.
d) Sobreposição parcial.
12. QUESTÕES AUTOAVALIATIVAS
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta 
unidade:
1) Quais são as fases constituintes de um projeto de banco de dados?
2) Defina e exemplifique os seguintes conceitos:
a) Entidade.
b) Relacionamento.
c) Atributo.
d) Cardinalidade.
3) Além de relacionamentos e atributos, propriedades podem ser atribuídas a entidades fazendo-se uso do concei-
to de generalização/especialização. Dê pelo menos três exemplos de entidade genérica e especializada.
4) O que é uma entidade associativa? Exemplifique.
5) Quais são os principais tipos de atributos? Cite pelo menos um exemplo de cada.
6) Escolha a opção que representa corretamente, no Modelo Entidade-Relacionamento, a afirmação: Todo jogador 
deve pertencer a um único clube. 
a) 
Figura 27 Modelo Entidade-Relacionamento I.
b) 
Figura 28 Modelo Entidade-Relacionamento II.
c) 
Figura 29 Modelo Entidade-Relacionamento III.
d) 
Figura 30 Modelo Entidade-Relacionamento IV.
Claretiano - Centro Universitário
73© U2 – Modelagem dos Dados utilizando o Modelo Entidade-Relacionamento
e) 
Figura 31 Modelo Entidade-Relacionamento V.
7) Considere o Modelo Entidade-Relacionamento (Figura 32), em que o relacionamento Ocupa indica o Cargo que 
o Empregado ocupa atualmente, e o relacionamento Ocupado indica os cargos anteriormente ocupados pelo 
empregado, se houver. Para cada afirmação a seguir, assinale V (verdadeira) ou F (falsa).
Empregado Cargo
Ocupa
Ocupado
(1,1)(0,N)
(0,N) (0,N)
Figura 32 Modelo Entidade-Relacionamento Empregado - 
Cargo.
O modelo está incorreto porque não pode haver 2 relacionamentos entre as mesmas entidades;
Pode haver um Empregado que não ocupa um Cargo;
Para que o modelo contenha a data em que um Empregado deixou de ocupar um Cargo essa data deve ser 
colocada como atributo do relacionamento Ocupado;
O relacionamento Ocupado permite identificar todos os cargos que um Empregado já ocupou, menos o cargo 
que ocupa atualmente;
Todo Cargo tem pelo menos um Empregado que o ocupa;
8) Constitua a modelagem das especificações mencionadas a seguir utilizando o MER, juntamente às suas respec-
tivas cardinalidades. (Observação: defina os atributos que julgar necessário).
a) Administradora de Imóveis:
Uma entrevista com o gerente da administradora resultou nas seguintes informações:
I. A administradora administra condomínios formados por unidades condominiais (lotes).
II. Cada unidade condominial é de propriedade de uma ou mais pessoas. Uma pessoa pode possuir diversas 
unidades.
III. Cada unidade pode estar alugada para, no máximo, uma pessoa. Uma pessoa pode alugar diversas uni-
dades.
b) Clínica:
I. Em uma clínica trabalham médicos e existem pacientes internados.
II. Cada médico é identificado pelo seu CRM, possui um nome e recebe um salário na clínica.
III. Um médico tem formação em diversas especialidades (ortopedia, traumatologia etc), entretanto, só 
exerce uma delas na clínica.
IV. Para todo paciente internado na clínica são cadastrados alguns dados pessoais: nome, RG, CPF, endere-
ço, telefone(s) para contato e data de nascimento.
V. Um paciente tem sempre um determinado médico como responsável (com horário de visita diária pre-
determinado), porém, vários outros médicos podem participar do seu tratamento.
VI. Pacientes estão sempre internados em quartos individuais, que são identificados por um número e ficam 
em um andar da clínica.
c) Biblioteca:
I. Uma biblioteca mantém um conjunto de livros, de diversas categorias.
II. Conforme as suas categorias, eles estão dispostos em estantes apropriadas.
III. Um livro tem vários exemplares na biblioteca.
IV. São mantidos dados detalhados sobre autores e editoras dos livros para fins de consulta.
V. Na biblioteca trabalham várias bibliotecárias.
VI. Cada bibliotecária é responsável por organizar periodicamente sempre o mesmo conjunto de estantes e 
realizar empréstimos de exemplares para os clientes.
VII. Empréstimos cadastrados no banco de dados devem conter a data da devolução e o valor diário da mul-
ta, permanecendo no banco de dados até o cliente realizar a entrega do exemplar.
VIII. O nome da bibliotecária que realizou o empréstimo também deve ser mantido no banco de dados.
© Banco de Dados74
IX. Algumas bibliotecárias são estagiárias.
X. Uma bibliotecária estagiária está sempre sob a responsabilidade de uma bibliotecária efetiva.
XI. Deve-se saber também a instituição de ensino de onde vem a estagiária.
Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
6) c.
7) 
F.
F.
V.
V.
F.
13. CONSIDERAÇÕES
O modelo entidade-relacionamento apresentado nesta unidade é utilizado pelos projetis-
tas de bancos de dados na fase do projeto conceitual, pois é um modelo de dados de alto nível.
Os conceitos do modelo entidade-relacionamento foram apresentados e demonstrados 
por meio de um exemplo de aplicação específica simplificada para uma escola, com o objetivo 
de facilitar a sua explanação e demonstrar que o modelo conceitual depende das regras e restri-
ções definidas pelos analistas de negócios.
O projeto lógico necessita da adoção de um modelo de dados lógico específico, e o mo-
delo adotado neste estudo é o modelo relacional, devido a sua larga utilização no mercado. O 
modelo relacional será o assunto estudado na próxima unidade.
14. REFERÊNCIAS BIBLIOGRÁFICAS
ELMASRI, R.; NAVATHE, S. B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. 4. ed. Porto Alegre: Sagra Luzzatto, 2001.
KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
RAMAKRISHNAN, R; GEHRKE, J. Database Management Systems. 2. ed. Boston: McGraw-Hill, 2000.
ROB, P.; CORONEL, C. Sistemas de Banco de Dados: Projeto, Implementação e Administração. São Paulo: Cengage Learning, 2011. 
3
Modelo de Dados Relacional
1. OBJETIVO
• Construir o conhecimento básico necessário para o desenvolvimento de um projeto 
lógico de Banco de Dados Relacional baseado no Modelo Conceitual.
2. CONTEÚDOS
• Modelo Relacional.
• Notação do Modelo Relacional.
• Atributos-chave de uma relação.
• Esquema de Banco de Dados Relacional.
• Restrições de integridade sobre relações.
• Projeto lógico de banco de dados: Entidade-Relacionamento para Relacional.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE 
Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Lembre-se de que sua participação é fundamental para a construção do conhecimen-
to. Discuta com seus colegas e tutor sobre diferentes situações a fim de conhecer a 
realidade das salas de aula.
© Banco de Dados76
2) Realize as interatividades e atividades propostas. Participe! Interaja com seus colegas 
de curso e com seu tutor. Lembre-se de que é fundamental que vocêentregue as ati-
vidades nas datas previstas.
3) Fique atento a todo o conteúdo desta unidade, no qual você encontrará conceitos 
importantes para sua aprendizagem, como: modelo relacional, notação do modelo re-
lacional, atributos-chave de uma relação, esquema de banco de dados relacional etc.
4) Se necessário, retorne às unidades anteriores para entender e recordar os conceitos 
propostos. Consulte sempre o Glossário de conceitos-chave quando surgirem ideias 
que ainda não foram completamente abstraídas.
5) Entender álgebra relacional é importante para que você compreenda adequadamente 
o modelo relacional (E. F. Codd – 1970), o qual é baseado na lógica dos predicados e 
na teoria dos conjuntos.
4. INTRODUÇÃO À UNIDADE
Na unidade anterior, você teve a oportunidade de estudar o modelo entidade-relaciona-
mento (MER) e conhecer o que é entidade, atributos e conjuntos de entidades. Também pôde 
aprender como é a estrutura do diagrama entidade-relacionamento e como formular um proje-
to conceitual de banco de dados utilizando o MER.
Nesta unidade, você estudará o projeto lógico de um banco de dados relacional, cuja base 
é o modelo conceitual.
5. MODELO RELACIONAL
O modelo relacional, baseado na lógica dos predicados e na teoria dos conjuntos, foi apre-
sentado por E. F. Codd em 1970 e representa os dados contidos em um banco de dados por meio 
de relações (tabelas). 
A lógica dos predicados, amplamente utilizada pela matemática, fornece um modelo em 
que uma proposição (afirmação de um fato) pode ser verificada como verdadeira ou falsa. Por 
exemplo, suponha que uma estudante com ID 12345678 se chame Melissa Mendes. Essa pro-
posição pode ser facilmente demonstrada como verdadeira ou falsa. 
A teoria dos conjuntos é a parte da ciência matemática que lida com conjuntos (grupos 
de coisas), sendo utilizada como base para a manipulação de dados no modelo relacional. Por 
exemplo, suponha que o conjunto A contenha três números: 16, 24 e 77. Esse conjunto é repre-
sentado por A(16, 24, 77). O conjunto B, por sua vez, contém quatro números: 44, 77, 90 e 11, 
sendo, portanto, representado por B(44, 77, 90, 11). Com base nessas informações, é possível 
concluir que a intersecção de A e B dará origem a um terceiro conjunto, formado apenas pelo 
número 77. Esse resultado pode ser expresso por A ∩ B = 77. Em outras palavras, A e B com-
partilham um valor comum, 77.
Segundo Alvarenga (2012): 
O Modelo Relacional é claramente baseado no conceito de matrizes, onde as chamadas linhas (das 
matrizes) seriam os registros e as colunas (das matrizes) os campos. Os nomes das tabelas e dos cam-
pos são de fundamental importância para sua compreensão entre o que estamos armazenando, onde 
estamos armazenando e qual a relação existente entre os dados armazenados. 
Para esclarecer melhor essa questão, observe os nomes na Tabela 1, na qual serão feitas 
as comparações necessárias. Você pode notar que os nomes são diferentes para cada área de 
atuação, mas têm o mesmo significado em cada uma delas.
Claretiano - Centro Universitário
77© U3 – Modelo de Dados Relacional
Tabela 1 Comparações e convenções em banco de dados.
INFORMÁTICA TRADICIONAL BASE DE DADOS RELACIONAL ÁLGEBRA RELACIONAL
Arquivo Tabela Relação
Registro Linha Tupla
Campo Coluna Atributo
Existem algumas convenções importantes para a utilização dos nomes, quer para as tabe-
las, quer para os atributos que as constituem. Uma convenção não tem sentido obrigatório, no 
entanto deve ser respeitada para evitar incompatibilidades ou erros.
Determinados SGBD, como, por exemplo, o Microsoft Access, permitem alguma flexibili-
dade com os nomes das tabelas e os nomes dos atributos, ao contrário de outros. Essa flexibili-
dade pode trazer pequenos problemas quando pretendemos realizar a migração de um SGBD em 
MySQL ou Access, por exemplo, para um SGBD em Oracle. 
Os SGBDs que utilizam o modelo relacional são denominados SGBD Relacionais. Algumas 
convenções devem ser seguidas em um modelo relacional. Por exemplo, os nomes das tabelas 
deverão ter por base as entidades que representam. É necessário que o nome de cada tabela 
seja único, ou seja, não deve haver duplicação de nomes de tabelas dentro da mesma base de 
dados.
Existem diferentes convenções quanto à singularidade ou pluralidade dos nomes das ta-
belas. Não importa a convenção adotada, mas é importante manter a coerência do método ado-
tado em todas as tabelas; isto é, se a opção for um nome no singular, devem-se utilizar nomes 
no singular em todas as tabelas e vice-versa. 
Por convenção, para os nomes, devemos utilizar unicamente letras minúsculas e o unders-
core ( _ ) para separar palavras. Underscore também é conhecido como underline. 
Devemos usar abreviaturas quando necessário, por exemplo, para diminuir os nomes que 
atinjam o número máximo de caracteres permitidos pelo SGBD.
Os nomes dos campos devem basear-se no nome do atributo definido no desenho lógico, 
os quais devem ser únicos dentro da tabela; é necessário atenção, pois alguns SGBDs podem ser 
sensíveis ao fato de o nome do campo estar escrito em maiúsculas e/ou minúsculas.
Para que você entenda alguns nomes utilizados em uma relação, veja a Figura 1. Cada 
linha da relação será chamada de tupla, e cada coluna da relação será chamada de atributo. O 
conjunto de valores passíveis de serem assumidos por um atributo será intitulado de domínio. 
ALUNO NumMec Nome Curso
798764544 João Pinto CC
345673451 Carlos Semedo ERSI
487563546 Maria Silva EG
452212348 Pedro Costa MAT
relação
nome da relação atributos
tuplas
Figura 1 Exemplo da Relação ALUNO.
© Banco de Dados78
O esquema de uma relação nada mais são que as colunas existentes em uma tabela. Já 
a instância da relação consiste no conjunto de valores que cada atributo assume em um de-
terminado instante. Portanto, os dados armazenados no banco de dados são formados pelas 
instâncias das relações. 
Uma relação esquema R, dada por R(A1, A2, A3, ..., An), é um conjunto de atributos de R: {A1, 
A2, A3, ..., An }. Cada atributo Ai possui um domínio D(Ai). O grau de uma relação é definido como 
o número de atributos que ele contém.
Observando a Figura 1, podemos dizer que:
1) ALUNO (NumMec, Nome, Curso) é a relação esquema.
2) ALUNO é o nome da relação.
3) O grau da relação é 3.
4) Os domínios dos atributos são:
a) D(NumMec): números que representam o código dos alunos.
b) D(Nome): caracteres compostos de letras que formam o nome dos alunos.
c) D(Curso): caracteres que representam a sigla da disciplina.
É necessário destacar que as relações não podem ser duplicadas (não podem existir dois 
códigos idênticos de alunos no conjunto de Código de Alunos), e a ordem de entrada de dados 
no banco de dados não deverá ter qualquer importância para as relações, no que concerne ao 
seu tratamento. Os atributos deverão ser atômicos, isto é, indivisíveis. 
Tabela
A perspectiva lógica do banco de dados relacional é facilitada pela criação de relaciona-
mento de dados com base em uma estrutura conhecida como relação. Como a relação é uma 
estrutura matemática, os usuários finais consideram mais fácil pensar na relação como uma 
tabela, vista como uma estrutura bidimensional composta de linhas e colunas. Ela é chamada 
de relação, pois o criador do modelo relacional, E. F. Codd, utilizou esse termo como sinônimo 
de tabela.
Uma tabela pode conter um grupo de ocorrências de entidades relacionadas, ou seja, um 
conjunto de entidades. Por exemplo, uma tabela ALUNO contém um conjunto de ocorrências de 
entidades, cada uma representando um aluno.
As tabelas possuem várias características que devem ser compreendidas. Veja algumas 
destas características na Tabela 2:
Tabela 2 Características de uma tabela.
ITEM CARACTERÍSTICA
1 A tabela deve ser entendida como uma estrutura bidimensional composta de linhas e colunas.
2 Cada linha (tupla) representa uma única ocorrência de entidade no interior do conjunto de entidades.
3 Cada coluna da tabela representa um atributo e devepossuir um nome diferente.
4 Cada intersecção entre linha e coluna representa um único valor.
5 Todos os valores em uma coluna devem ser de um mesmo formato (número, data).
6 Cada coluna possui uma faixa específica de valores conhecida como domínio de atributos.
7 A ordem das linhas e das colunas é insignificante para o SGBD.
8
Cada tabela deve apresentar um atributo ou uma combinação deles que identifique o registro de forma exclusiva 
(CPF, por exemplo).
Claretiano - Centro Universitário
79© U3 – Modelo de Dados Relacional
A tabela representada pela Figura 2 apresenta uma exemplificação que aborda as caracte-
rísticas listadas na Tabela 2.
Figura 2 Exemplo de Tabela.
A Figura 2 demonstra um exemplo de tabela para cadastro de ALUNOS, em que cada co-
luna representa:
STU_NUM: Número do aluno.
STU_LNAME: Sobrenome do aluno.
STU_FNAME: Primeiro nome do aluno.
STU_CLASS: Classificação do aluno.
STU_DOB: Data de nascimento do aluno.
STU_GPA: Média das notas.
STU_HRS: Créditos-hora obtidos.
STU_INIT: Letra inicial do nome do meio do aluno.
STU_PHONE: Extensão de quatro dígitos do telefone do campus.
STU_TRANSFER: Aluno que foi transferido de outra instituição.
DEPT_CODE: Código do departamento.
PROF_NUM: Número do professor que é o orientador do aluno.
De acordo com os itens enumerados na Tabela 2, e utilizando a tabela ALUNO apresentada 
na Figura 2, podemos concluir que: 
1) A tabela ALUNO é vista como uma estrutura bidimensional composta de sete linhas 
(tuplas) e doze colunas (atributos).
© Banco de Dados80
2) Cada linha da tabela ALUNO descreve uma única ocorrência de entidade no interior 
do conjunto de entidades (esse conjunto é representado por toda a tabela ALUNO). 
Observe que a linha (entidade ou registro) definida por STU_NUM = 324561 define as 
características (atributos ou campos) de um aluno chamado João C. Silva. Já a Linha 4 
da Figura 2, por exemplo, descreve um aluno chamado Walter H. Ortolani; de modo si-
milar, a Linha 3 descreve uma aluna chamada Juliana Bravo. Dado o conteúdo da tabe-
la, o conjunto de entidade ALUNO inclui sete entidades (linhas) ou alunos diferentes.
3) Cada coluna representa um atributo e possui um nome diferente. Conforme pode ser 
observado, não se verifica nenhuma coluna cujo nome seja repetido.
4) Todos os valores de uma coluna atendem às características do atributo. Por exemplo, 
a coluna média das notas (STU_GPA) contém apenas entradas de STU_GPA em todas 
as linhas da tabela, ou seja, todas as entradas são relativas unicamente à média. Os 
dados devem ser classificados de acordo com seu formato e função.
Embora diferentes SGBDs possam dar suporte a diferentes tipos de dados, a maioria 
aceita, pelo menos, os seguintes dados:
a) Numéricos: são aqueles com os quais é possível executar procedimentos aritméti-
cos com significado. Por exemplo, as colunas STU_HRS e STU_GPA da Figura 2 são 
atributos numéricos. Por outro lado, STU_PHONE não é um atributo numérico, 
pois a adição ou subtração de números telefônicos não produz um resultado arit-
meticamente significativo.
b) Caracteres: conhecidos como dados de texto ou de string, podem conter quais-
quer caracteres ou símbolos não destinados à manipulação matemática. Na Figu-
ra 2, por exemplo, as colunas STU_LNAME, STU_FNAME, STU_INIT, STU_CLASS e 
STU_PHONE são atributos de caracteres.
c) Data: contêm datas de calendário armazenadas em um formato especial. Embora 
o armazenamento físico da data seja insignificante para o usuário ou o projetis-
ta, esse formato permite a execução de um tipo especial de aritmética conheci-
do como aritmética das datas. Utilizando-a, é possível determinar o número de 
dias que se passaram entre duas datas, como 12 de maio de 1999 e 20 de março 
de 2008, simplesmente subtraindo a primeira da segunda. Na Figura 2, a coluna 
STU_DOB pode ser classificada adequadamente como um atributo do tipo data. A 
maioria dos SGBDs relacionais permite a personalização do formato de apresen-
tação de dados. Por exemplo, os usuários de Oracle podem especificar o formato 
"dd/mmm/aaaa" para mostrar o primeiro valor de STU_DOB na Figura 2 como 12/
Fev/1975 (ao examinar os valores dessa coluna, você pode ver que esse formato 
foi selecionado para a apresentação da saída).
d) Lógicos: dados lógicos podem ser apenas uma condição verdadeira ou falsa (sim 
ou não). Por exemplo, um aluno é terceiro anista transferido? Na Figura 2, o atri-
buto STU_TRANSFER utiliza o formato de dados lógico, que também é conhecido 
como booleano. A maioria dos pacotes de software de bancos de dados relacio-
nais suporta esse formato.
5) A faixa de valores permitidos para a coluna é conhecida como domínio. Os valores de 
STU_GPA estão limitados na faixa 0-4, inclusive o domínio [0,4].
6) A ordem das linhas e das colunas é insignificante para o usuário.
7) Cada tabela deve ter uma chave primária. Em termos gerais, a chave primária (PK, do 
inglês Primary Key) é um atributo (ou uma combinação de atributos) que identifica 
exclusivamente uma determinada linha. Nesse caso, STU_NUM (o número do aluno) é 
a chave primária. Utilizando os dados representados na Figura 2, observe que o sobre-
nome de um aluno (STU_LNAME) não seria uma boa chave primária, pois é possível 
encontrar vários alunos com o sobrenome Smith, por exemplo. Mesmo a combinação 
de nome (STU_FNAME) e sobrenome não constituiria uma chave primária adequada, 
pois também é possível encontrar mais de um aluno chamado João Silva.
Claretiano - Centro Universitário
81© U3 – Modelo de Dados Relacional
6. NOTAÇÃO DO MODELO RELACIONAL
Algumas notações e conceitos devem ser considerados para apresentar o modelo relacio-
nal. Veja-os a seguir:
Relação
1) Conjunto não ordenado de tuplas.
2) Corresponde a entidades-tipo ou relacionamentos da base de dados. 
3) É definida por esquemas do tipo R(A1, A2, A3, ..., An), em que R é o nome da relação, e 
A1, A2, A3, ..., An é a lista de atributos. 
4) Corresponde a uma tabela de valores.
Atributo
1) Identifica uma característica/propriedade de uma relação.
Exemplo: 
R.Ai representa o atributo Ai da relação R. 
Domínio
1) Conjunto de valores atômicos que caracterizam um atributo.
Exemplo: 
D(Ai) representa o domínio do atributo Ai. 
Tuplas
1) Sequência ordenada de valores.
2) Todas as tuplas de uma relação são diferentes, pois representam entidades ou relacio-
namentos específicos da base de dados.
3) São definidas por sequência do tipo <v1, v2, v3, ..., vi>, em que cada vi corresponde ao 
valor da tupla para o atributo Ai ou valor null.
a) vi Є D(Ai) ou vi = NULL. Lê-se: vi, 1<= i <= n, ou é nulo ou pertence ao domínio D(Ai). 
Figura 3 Tuplas.
© Banco de Dados82
b) t[Ai] ou t[i] representa o valor da tupla para o atributo Ai.
4) Os nomes de atributos são, algumas vezes, qualificados com o nome da relação à qual 
pertencem, por exemplo: ALUNO.Nome ou ALUNO.Curso.
Exemplo:
• Considere a tupla t= <798764544, João Pinto, CC> da relação ALUNO da Figura 1. 
Temos que:
• t[NumMec] = 798764544 e t[Nome,Curso]=<João Pinto, CC>.
7. ATRIBUTOS-CHAVE DE UMA RELAÇÃO
Até o momento, você estudou vários conceitos importantes sobre o modelo de dados 
relacional. Neste tópico, iniciaremos o estudo de mais um conceito essencial para o seu apren-
dizado, que são os atributos-chave de uma relação. Fique atento!
No modelo relacional as chaves são importantes, pois sua utilização garante que cada 
linha da tabela seja identificável de modo exclusivo, facilitando buscas posteriores, além de 
assegurar a consistência e integridade dos dados. Elas também são utilizadas para estabelecer 
relacionamentos entre tabelas. 
Para cada relação, deve existir uma chave, que vai ser constituída por um atributo ou um 
conjunto de atributos e que identifica cada tupla (ou instância da relação) de um modo único, 
pois essa chave permite que seja estabelecido um relacionamento com outras tabelas. 
É importante lembrar que não podem existir duas tuplas com os mesmos dados para o 
mesmo atributo ou conjuntode atributos.
O papel da chave baseia-se em um conceito conhecido como determinação. No contexto 
de tabela de bancos de dados, a afirmação "A determina B" indica que conhecer o valor do atri-
buto A possibilita verificar (determinar) o valor de B. Por exemplo, conhecer apenas o identifi-
cador de um registro, como no exemplo da tabela ALUNO (Figura 2) – o STU_NUM –, é bastante 
útil, pois, a partir dele, torna-se possível obter (determinar) qualquer informação pertinente ao 
aluno cujo STU_NUM se faz conhecido: o sobrenome, a média das notas, o número de telefo-
ne, entre outros. A notação abreviada para "A determina B" é A à B. Se A determina B, C e D, 
escreve-se AàB, C, D. Portanto, utilizando os atributos da tabela ALUNO da Figura 2, é possível 
representar a afirmação "STU_NUM determina STU_LNAME", escrevendo:
STU_NUMSTU_LNAME
De fato, o valor STU_NUM da tabela ALUNO determina todos os valores de atributos do 
aluno. Por exemplo, é possível escrever:
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT
e
STU_NUMSTU_LNAME, STU_FNAME, STU_INIT, STU_DOB, STU_TRANSFER
Fica claro que uma vez conhecido o identificador de um registro de uma tabela, é possível 
identificar, a partir dele, quaisquer atributos pertinentes a esse registro. Deste modo, conhecen-
do-se STU_NUM, podemos determinar qualquer atributo pertencente a um aluno; em contra-
partida, não é possível conhecer STU_NUM a partir de STU_LNAME, pois é possível que vários 
alunos tenham o mesmo sobrenome (por exemplo, Silva).
Claretiano - Centro Universitário
83© U3 – Modelo de Dados Relacional
O princípio de determinação é importante, pois é utilizado na definição de um conceito 
central de bancos de dados relacionais, conhecido como dependência funcional, o qual pode 
ser definido da seguinte maneira: o atributo B é funcionalmente dependente de A se A determi-
na B. Mais precisamente: o atributo B é funcionalmente dependente do atributo A se cada valor 
da coluna A determina um (e somente um) valor da coluna B.
Quando uma chave é composta apenas por um atributo, podemos dizer que se trata de 
uma chave simples. No exemplo da Tabela ALUNO, demonstrada na Figura 2, observa-se a exis-
tência de apenas uma chave. Uma chave constituída por mais de um atributo é denominada 
chave composta.
Para entender melhor o que são as chaves e como funcionam no modelo relacional, é 
necessário compreender alguns conceitos, tais como: chave candidata, chave primária e chave 
estrangeira. Observe suas definições a seguir:
Chave candidata é todo atributo ou conjuntos de atributos que permite identificar, de 
modo único, cada tupla. No entanto, para proceder a esta seleção de chaves candidatas, é ne-
cessário conhecer bem a realidade de cada um dos atributos da relação e qual o seu domínio.
Dentre todas as chaves candidatas, apenas uma será escolhida para identificar cada tupla 
de forma única. A chave selecionada dentre as chaves candidatas é designada chave primária 
da relação. Em todas as tabelas deve existir sempre uma chave primária, e os atributos que a 
constituem não podem conter valores nulos.
Uma chave candidata pode ser descrita como uma superchave sem atributos desnecessá-
rios, ou seja, uma superchave mínima.
A superchave é qualquer chave que identifique cada linha exclusivamente. Em resumo, 
ela determina funcionalmente todos os atributos de uma linha. Na tabela ALUNO, a superchave 
poderia ser qualquer uma das seguintes colunas:
STU_NUM
STU_NUM, STU_LNAME
STU_NUM, STU_LNAME, STU_INIT
De fato, STU_NUM, com ou sem valores adicionais, pode ser uma superchave, mesmo 
quando os atributos adicionais são redundantes.
Tomando como exemplo a chave composta STU_NUM, STU_LNAME, pode-se dizer que 
esta é uma superchave, mas não uma chave candidata. Para que esta chave pudesse ser uma 
chave candidata, teríamos que nos assegurar que não haveria nenhum sobrenome de aluno em 
duplicidade na tabela ALUNO.
Portanto, a chave primária é a chave candidata escolhida para construir o identificador 
exclusivo da linha. Podemos afirmar que uma chave primária é tanto uma superchave como uma 
chave candidata.
A chave primária possui algumas características, tais como:
• Ser unívoca: os atributos definidos para ser chave primária, por definição, devem ter 
valor único para cada registro ou tupla na relação, de modo a garantir que todas as 
linhas sejam identificadas exclusivamente por essa chave. Nesse caso, diz-se que a ta-
bela apresenta integridade de entidade.
© Banco de Dados84
• Não nula: nenhum dos atributos que formam uma chave primária poderá conter um 
valor nulo em um registro.
• Não redundante: no caso de uma chave primária ser composta, não devem ser incluí-
dos mais atributos do que os mínimos necessários para identificar os registros de modo 
unívoco.
Chave estrangeira (forasteira ou externa) é todo atributo ou conjunto de atributos que é a 
chave primária em outra tabela, ou seja, quando um atributo surge em mais do que uma tabela, 
estamos perante um relacionamento de tuplas. 
A redundância controlada faz com que o banco de dados relacional funcione. As tabelas 
no banco de dados compartilham atributos comuns que permitem sua ligação. Por exemplo, ob-
serve que as tabelas PRODUTO e FORNECEDOR na Figura 4 compartilham um atributo comum 
chamado VEND_CODE. Note também que o VEND_CODE com valor 232 na tabela PRODUTO 
ocorre mais de uma vez, assim como o 235. 
Como a tabela PRODUTO está relacionada a FORNECEDOR por meio desses valores VEND_
CODE, sua ocorrência múltipla é necessária para fazer com que o relacionamento 1:M entre 
FORNECEDOR e PRODUTO funcione. Cada valor VEND_CODE da tabela FORNECEDOR é exclu-
sivo, e o FORNECEDOR é o lado 1 do relacionamento FORNECEDOR-PRODUTO. Mas qualquer 
valor VEND_CODE da tabela FORNECEDOR pode ocorrer mais de uma vez na tabela PRODUTO, 
evidenciando que PRODUTO é o lado M desse relacionamento. Em termos de bancos de dados, 
as múltiplas ocorrências dos valores VEND_CODE na tabela PRODUTO não são redundantes, 
pois são necessárias para que o relacionamento funcione.
Figura 4 Exemplo de um banco de dados relacional simples.
Claretiano - Centro Universitário
85© U3 – Modelo de Dados Relacional
Na Figura 4, observe que o valor VEND_CODE em uma tabela pode ser utilizado para in-
dicar o valor correspondente em outra tabela. Desta forma, além de manter-se a integridade 
dos dados, evitamos repetições desnecessárias. Por exemplo, o valor VEND_CODE 235 na ta-
bela PRODUTO indica o fornecedor Henry Ortozo da tabela FORNECEDOR. Consequentemente, 
descobre-se que o produto Houselite chain saw, 16-in bar (motosserra Houselite com barra de 
16 polegadas) é fornecido por Henry Ortozo, o qual pode ser contatado pelo número 615-123-
5529. A mesma relação pode ser feita para o produto Steel tape, 12-ft legth (fita de aço com 12 
pés de comprimento) da tabela PRODUTO.
8. ESQUEMA DE BANCO DE DADOS RELACIONAL
No tópico anterior, você pôde observar um esquema de relação e uma relação associada. 
Agora, você conhecerá um sistema de banco de dados relacional e perceberá que ele contém, 
normalmente, várias relações em que as tuplas relacionam-se de diversas maneiras.
Um esquema de banco de dados relacional S é um conjunto de esquemas de relação S= 
{R1, R2, ..., Rm} e um conjunto RI de restrições de integridade. Já um banco de dados relacional 
BD de S é um conjunto de relações BD={r1, r2, ..., rm}, tal que cada ri é uma relação associada ao 
esquema Ri e satisfaz as restrições de integridade em RI.
No próximo tópico desta unidade, você verá mais detalhes sobre restrições de integridade.
Um esquema relacional é uma representação textual das tabelas de bancos de dados em 
que cada tabela PE relacionada com seu nome é seguida pela lista de seus atributos entre pa-
rênteses. O(s) atributo(s) de chave primária deve(m) aparecer sublinhado(s). Por exemplo, o 
esquema relacional para a Figura 4 seria representado como:
FORNECEDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE, VEND_PHONE)
PRODUTO (PROD_CODE, PROD_DESCRIPT,PROD_PRICE, PROD_ON_HAND, VEND_CODE)
A ligação entre as tabelas PRODUTO e FORNECEDOR da Figura 4 também pode ser repre-
sentada pelo diagrama relacional exibido na Figura 5. Nesse caso, a ligação é indicada pela linha 
que conecta as tabelas.
Figura 5 Diagrama relacional.
Observe que a ligação na Figura 5 é equivalente à reta de relacionamento de um DER. 
Ela é criada quando duas tabelas compartilham um atributo com valores comuns. Mais especi-
ficamente, a chave primária de uma tabela (FORNECEDOR) aparece como a chave estrangeira 
© Banco de Dados86
de uma tabela relacionada (PRODUTO). Uma chave estrangeira FK (do inglês Foreign Key) é um 
atributo cujos valores correspondem aos da chave primária na tabela relacionada. Por exemplo, 
na Figura 5, VEND_CODE é a chave primária da tabela FORNECEDOR e aparece como chave es-
trangeira da tabela PRODUTO.
Se a chave estrangeira contém valores correspondentes ou nulos, diz-se que a tabela que 
contém essa chave apresenta integridade referencial. Em outras palavras, integridade referen-
cial significa que se a chave estrangeira contém um valor, esse valor se refere a uma tupla (linha) 
válida existente em outra relação.
9. RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES
As restrições de integridades mencionadas anteriormente correspondem às regras as 
quais toda relação de uma base de dados (relacional) deve obedecer. Tais regras são muito 
importantes para um projeto de bancos de dados e são aplicadas automaticamente por muitos 
SGBDs. 
Existem várias restrições que podem ser especificadas no modelo de dados relacional, 
conforme demonstra a Tabela 3: 
Tabela 3 Regras de integridade.
INTEGRIDADE DE ENTIDADES DESCRIÇÃO
Exigência Todas as entradas de chave primária são únicas e nenhuma parte dessa chave pode ser nula.
Finalidade Cada linha terá uma identidade exclusiva, e valores de chave estrangeira podem referenciar de modo adequado os valores de chave primária.
Exemplo Nenhum vendedor pode ter número duplicado nem ser nulo. Portanto, todos os vendedores são identificados de modo exclusivo por seu número.
INTEGRIDADE REFERENCIAL DESCRIÇÃO
Exigência
Uma chave estrangeira pode ter uma entrada nula, contanto que não faça parte de 
uma chave primária de suas tabelas, ou uma entrada que coincida com o valor de chave 
primária de uma tabela que esteja relacionada (todo valor não nulo de chave estrangeira 
deve referenciar um valor de chave primária existente).
Finalidade
É possível que um atributo não tenha valor correspondente, mas é impossível que tenha 
uma entrada inválida. A aplicação da regra de integridade referencial torna impossível a 
exclusão de uma linha de uma tabela cuja chave primária tenha valores obrigatórios de 
chave estrangeira em outra tabela.
Exemplo Um cliente pode ainda não ter recebido a atribuição de um representante de vendas (número), mas é impossível que tenha um representante de vendas inválido (número).
Uma definição formal da restrição de integridade referencial exige a definição de Chave 
Estrangeira (CE). Um conjunto de tributos CE em um esquema de relação R1 é uma chave es-
trangeira que referencia um esquema de relação R2 se ele satisfaz as seguintes propriedades: 
• Os atributos de CE possuem o mesmo domínio dos atributos da Chave Primária (CP) da 
outra relação de esquema R2. Diz-se que os atributos em CE referenciam ou referem-se 
a R2.
• Uma CE na Tupla t1 de r(R1) ou tem um valor que ocorre como CP de alguma Tupla t2 
de r(R2) ou tem o valor nulo. No primeiro caso, tem-se t1[CE] = t2[CP] e diz-se que t1 
referencia ou refere-se a t2.
Normalmente, as restrições de integridade referencial derivam-se dos relacionamentos 
entre conjuntos de entidades representadas pelos esquemas de relação. 
Claretiano - Centro Universitário
87© U3 – Modelo de Dados Relacional
Outras regras de integridade que podem ser aplicadas no modelo relacional são as restri-
ções not null e unique. A restrição not null pode ser aplicada a uma coluna para garantir que 
todas as linhas da tabela apresentem um valor para essa coluna, enquanto a restrição unique é 
aplicada a uma coluna para garantir que não haja nenhum valor duplicado.
10. OPERADORES DO CONJUNTO RELACIONAL
As operações da Álgebra Relacional são utilizadas para selecionar tuplas de uma deter-
minada relação ou para combinar tuplas relacionadas a diversas relações, com o propósito de 
especificar uma consulta (uma requisição de recuperação) sobre a base de dados. 
A Álgebra Relacional é uma coleção de operadores que tomam relações com seus ope-
randos e retornam uma relação como resultado. Desta forma, por meio de seus operadores 
específicos e adequados, é possível fazer a combinação de tuplas, relacionadas ou não, e obter 
a resultante desejada. 
A Álgebra Relacional é uma linguagem teórica que trabalha com operações que conte-
nham uma ou mais relações, a partir das quais outra relação é criada de modo a não alterar 
a relação originária. É importante mencionar que a Álgebra Relacional é uma linguagem abs-
trata, o que significa que as queries formuladas por ela não são destinadas à execução em 
um computador; portanto, o uso desta linguagem permite a compreensão da execução das 
queries no banco de dados. Somam oito os operadores relacionais: Union, Intersect, Diference, 
Product, Select, Project, Join e Divide.
Union
Este operador combina todas as linhas de duas tabelas, excluindo as duplicadas. As tabelas 
devem apresentar as mesmas características de atributos (as colunas e os domínios devem ser 
idênticos) para serem utilizadas no operador union. Um exemplo da utilização do union é apre-
sentado na Figura 6:
 P_CODE P_DESCRIPT PRICE 
345678 Mocrowave 160.00 
345679 Dishwasher 500.00 
 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
345678 Mocrowave 160.00 
345679 Dishwasher 500.00 
 
UNION 
resulta em 
Figura 6 Union.
© Banco de Dados88
Intersect
O operador intersect resulta apenas em linhas que aparecem em ambas as tabelas. Assim 
como no union, só se produzirão resultados se as tabelas forem compatíveis para união. Por 
exemplo, não é possível utilizar intersect se um dos atributos for numérico e o outro for baseado 
em caracteres. Veja o efeito do intersect apresentado na Figura 7.
 F-NAME 
George 
Jane 
Elaine 
Wilfred 
Jorge 
 
F-NAME 
Jane 
William 
Jorge 
Dennis 
 
F-NAME 
Jane 
Jorge 
 
INTERSECT 
resulta em 
Figura 7 Intersect. 
Difference
O resultado deste operador será todas as linhas de uma tabela que não se encontram na 
outra tabela, ou seja, uma tabela é subtraída da outra. Como no caso do union, só se produ-
zirão resultados válidos se as tabelas forem compatíveis para união. O efeito do difference é 
apresentado na Figura 8. No entanto, observe que subtrair a primeira tabela da segunda não 
é igual a subtrair a segunda da primeira.
 F-NAME 
George 
Jane 
Elaine 
Wilfred 
Jorge 
 
F-NAME 
Jane 
William 
Jorge 
Dennis 
 
F-NAME 
George 
Elaiine 
Wilfred 
 
DIFFERENCE 
resulta em 
Figura 8 Difference.
Product
Resultará em todos os pares de linhas possíveis a partir de duas tabelas. Essa operação 
também é conhecida como produto cartesiano. Portanto, se uma tabela tiver seis linhas e a ou-
tra tiver três, o product resulta em uma lista composta de 6x3=18 linhas. O efeito do product é 
apresentado na Figura 9.
Claretiano - Centro Universitário
89© U3 – Modelo de Dados Relacional
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
213345 9v Battery 1.99 
 
STORE AILSE SHELF 
23 W 5 
24 K 9 
25 Z 6 
 
P_CODE P_DESCRIPT PRICE STORE AILSE SHELF 
123456 Flashlight 5.26 23 W 5 
123457 Flashlight 5.27 24 K 9 
123458 Flashlight 5.28 25 Z 6 
123457 Lamp 25.15 23 W 5 
123458 Lamp 25.16 24 K 9 
123459 Lamp 25.17 25 Z 6 
123458 Box Fan 10.9923 W 5 
123459 Box Fan 10.100 24 K 9 
123460 Box Fan 10.101 25 Z 6 
213345 9v Battery 1.99 23 W 5 
213346 9v Battery 1.100 24 K 9 
213347 9v Battery 1.101 25 Z 6 
 
PRODUCT 
resulta em 
Figura 9 Product.
Select
Este operador, também conhecido como restrict, resulta nos valores de todas as linhas 
de uma tabela que satisfaçam uma dada condição. O select pode ser utilizado para listar todos 
os valores de linha ou apenas aqueles que atenderem a um critério especificado. Em outras 
palavras, select produz um subconjunto horizontal de uma tabela, e seu efeito é apresentado na 
Figura 10.
© Banco de Dados90
 Tabela original 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
Nova tabela ou lista 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
SELECT ALL resulta 
em 
SELECT apenas atributo PRICE inferior a US$ 2,00 resulta em 
P_CODE P_DESCRIPT PRICE 
123459 9v Battery 1.99 
 
SELECT apenas atributo P_CODE = 123457 resulta em 
P_CODE P_DESCRIPT PRICE 
123457 Lamp 25.15 
 
Figura 10 Operador Select.
Project
A resultante deste operador será todos os valores de atributos selecionados. Em outras 
palavras, o project produz um subconjunto vertical de uma tabela. Seu efeito é apresentado na 
Figura 11:
 Tabela original 
 P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
PROJECT PRICE 
resulta em 
PRICE 
5.26 
25.15 
10.99 
1.99 
34.99 
 
Nova lista de tabelas 
P_CODE P_DESCRIPT PRICE 
123456 Flashlight 5.26 
123457 Lamp 25.15 
123458 Box Fan 10.99 
123459 9v Battery 1.99 
123460 Powerdrill 34.99 
 
PROJECT P_DESCRIPT e 
PRICE resulta em 
P_DESCRIPT PRICE 
Flashlight 5.26 
Lamp 25.15 
Box Fan 10.99 
9v Battery 1.99 
Powerdrill 34.99 
 
Figura 11 Operador Project.
Claretiano - Centro Universitário
91© U3 – Modelo de Dados Relacional
Join
O operador join possibilita a combinação de informações de duas ou mais tabelas. Trata-
-se da potência real por trás dos bancos de dados relacionais, e permite a utilização de tabelas 
independentes ligadas por atributos comuns. As tabelas CLIENTE e CORRETOR, apresentadas na 
Figura 12, ilustram vários tipos de utilização do operador join (junções).
 Nome da tabela: CLIENTE 
 CUS_CODE CUS_LNAME CUS_ZIP AGENT_CODE 
1234 Walker 31145 231 
1235 Adares 32145 125 
1236 Rakowski 34129 167 
1237 Rodriguez 37134 125 
1238 Smithson 37134 421 
1239 Vanloo 32145 231 
 
Nome da tabela: CORRETOR 
AGENT_CODE AGENT_PHONE 
125 6152439887 
167 6153426778 
231 6152431124 
333 9041234445 
 
Figura 12 Tabelas para demonstrar o operador Join.
A junção natural (natural join) liga tabelas selecionando apenas as linhas com valores co-
muns em seu(s) atributo(s) comum(ns). É o resultado de um processo em três estágios:
a) Aplica-se o operador product nas tabelas.
b) Executa-se uma operação select sobre o resultado da Etapa a para se obter apenas as 
linhas para as quais os valores AGENT_CODE são iguais. As colunas comuns são cha-
madas de colunas de junção.
c) Executa-se uma operação project sobre os resultados da Etapa b para produzir uma 
única cópia de cada atributo, eliminando-se, assim, as colunas duplicadas.
O resultado da operação join entre CLIENTE e CORRETOR é demonstrado na Figura 13:
Figura 13 Tabela resultado do Join entre CLIENTE e CORRETOR.
O resultado de uma junção natural produz uma tabela que não inclui pares sem corres-
pondência. O resultado fornece apenas as cópias das correspondências.
Outra forma de junção, conhecida como junção por igualdade (equijoin), tem por fina-
lidade realizar a ligação entre tabelas com base em uma condição de igualdade que compara 
colunas especificadas de cada tabela. O resultado da junção por igualdade não elimina colunas 
duplicadas, e a condição ou critério utilizado para unir as tabelas deve ser definido explicitamen-
te. Esse tipo de junção recebe seu nome em função do operador de comparação de igualdade 
(=) utilizado na condição.
Em uma junção externa (outer join), os pares com correspondência são mantidos e os va-
lores em correspondência na outra tabela são deixados nulos. De modo mais específico, se for 
realizado uma junção externa para as tabelas CLIENTE e CORRETOR, há duas situações possíveis:
© Banco de Dados92
• Junção externa à esquerda (left outer join): resulta em todas as linhas da tabela CLIEN-
TE, inclusive aquelas que não apresentam um valor correspondente na tabela CORRE-
TOR. Um exemplo dessa junção é apresentado na Figura 14:
Figura 14 Junção externa à esquerda.
• Junção externa à direita (right outer join): resulta em todas as linhas da tabela CORRE-
TOR, inclusive aquelas que não apresentam um valor correspondente na tabela CLIEN-
TE. Veja o exemplo na Figura 15:
Figura 15 Junção externa à direita.
Junções externas são especialmente úteis quando se tenta determinar qual(is) valor(es) 
de tabelas relacionadas causa(m) problemas de integridade referencial. Esses problemas são 
criados quando valores de chave estrangeira não correspondem a valores de chave primária 
da(s) tabela(s) relacionada(s).
Você deve estar se perguntando por que as junções externas são identificadas como à 
esquerda e à direita. Esses nomes se referem à ordem em que as tabelas são relacionadas no 
comando SQL.
Divide
A operação divide utiliza uma tabela com uma única coluna (por exemplo, a coluna A) 
como o divisor e uma tabela de duas colunas (por exemplo, as colunas A e B) como o dividendo. 
As tabelas devem ter uma coluna em comum (por exemplo, a coluna A). A saída da operação 
divide é uma única coluna com os valores da coluna A e as linhas da tabela de dividendo, em que 
o valor da coluna comum (por exemplo, a coluna A) coincide em ambas as tabelas. A Figura 16 
apresenta a operação divide:
Claretiano - Centro Universitário
93© U3 – Modelo de Dados Relacional
 CODE LOC 
A 5 
A 9 
A 4 
B 5 
B 3 
C 6 
D 7 
D 8 
E 8 
 
CODE 
A 
B 
 
LOC 
A 
 
DIVIDE 
Resulta em 
Figura 16 Divide.
No exemplo apresentado na Figura 16, observe que:
• A Tabela 1 é dividida pela Tabela 2 para produzir a Tabela 3. As Tabelas 1 e 2 contêm a 
coluna CODE, mas não compartilham a LOC.
• Para ser incluído na Tabela 3 resultante, um valor de uma coluna não compartilhada 
(LOC) deve estar associada (na Tabela 2 de divisão) a todos os valores da Tabela 1.
• O único valor associado tanto a A como a B é 5.
11. RELACIONAMENTOS DENTRO DO BANCO DE DADOS RELACIONAL
Até o momento compreendemos a importância de se manter a integridade dos dados e 
quais os seus tipos em um banco de dados. Conhecemos também os operadores básicos que 
embasam os operadores SQL para a manipulação dos dados.
Estudaremos neste tópico os tipos de relacionamentos que podem ser utilizados para a 
modelagem de um projeto de banco de dados, a fim de garantir melhor perfomance e, acima de 
tudo, manter a integridade dos dados.
Você já sabe que os relacionamentos são classificados como um para um (1:1), um para 
muitos (1:M) e muitos para muitos (M:N ou M:M). Veja, a seguir, mais informações sobre cada 
um desses relacionamentos.
Relacionamento 1:M
O relacionamento 1:M é a norma do banco de dados relacional. Para ver como esse re-
lacionamento é modelado e implementado, considere o exemplo "o PINTOR cria a PINTURA". 
Compare o modelo de dados na Figura 17 com sua implementação, na Figura 18:
Figura 17 Relacionamento 1:M entre PINTOR e PINTURA.
© Banco de Dados94
 Nome da Tabela: PINTOR 
 Chave primária: PAINTER_NUM 
 Chave estrangeira: nenhuma 
 PAINTER_NUM PAINTER_LNAME PAINTER_FNAME PAINTER_INITIAL 
123 Ross Georgette P 
126 Itero Julio G 
 
Nome da Tabela: PINTURA 
 Chave primária: PAINTING_NUM 
 Chave estrangeira: PAINTER_NUM 
 PAINTING_NUM PAINTING_TITLE PAINTER_NUM 
1338 Dawn Thunder 123 
1339 Vanilla Roses To Nowhere 123 
1340 Tired Flounders126 
1341 Hasty Exit 123 
1342 Plastic Paradise 126 
 
Figura 18 Relacionamento 1:M implementado entre PINTOR e PINTURA.
Ao examinar o conteúdo da tabela PINTOR e PINTURA na Figura 18, observe os seguintes 
aspectos:
• Cada pintura é criada por um e somente um pintor, mas cada pintor pode ter criado 
várias pinturas. Observe que a Pintora 123 (Georgette P. Ross) possui três pinturas ar-
mazenadas na tabela PINTURA.
• Há apenas uma linha da tabela PINTOR para qualquer linha da tabela PINTURA, mas há 
várias linhas da tabela PINTURA para qualquer linha da tabela PINTOR.
Relacionamento 1:1
Como o próprio nome diz, no relacionamento 1:1 uma entidade pode ser relacionada à 
apenas outra entidade e vice-versa. Por exemplo, um chefe de departamento – um professor 
– pode chefiar apenas um departamento, e um departamento pode ter apenas um chefe. As 
entidades PROFESSOR e DEPARTAMENTO apresentam, portanto, um relacionamento 1:1.
O relacionamento 1:1 básico é modelado na Figura 19 e sua implementação é apresentada 
na Figura 20.
Figura 19 Relacionamento 1:1 entre PROFESSOR e DEPARTAMENTO.
Claretiano - Centro Universitário
95© U3 – Modelo de Dados Relacional
 Nome da Tabela: PROFESSOR 
 Chave primária: EMP_NUM 
 Chave estrangeira: DEPT_CODE 
 EMP_NUM DEPT_CODE PROF_OFFICE PROF_EXTENSION PROF_HIGH_DEGREE 
103 HIST DRE 156 3296 Ph.D. 
104 ENG DRE 102 3328 MA 
106 ACCT KLR 229 3392 Ph.D. 
110 MKT/MGT KLR 229B 3520 Ph.D. 
114 BIOL KLR 126 3648 Ph.D. 
155 ACCT AAJ 89 4960 Ph.D. 
160 MATH DBE 988 5120 Ph.D. 
162 ENG KLR 1898 5184 Ph.D. 
191 CIS DRE 293 6112 DBA 
195 MKT/MGT AAK 192 6240 Ph.D. 
209 PXYCH BBG 277 6688 Ph.D. 
228 CIS DK 123 7296 Ph.D. 
297 CIS DFK 134 9504 Ph.D. 
299 MATH AAC 182 9568 Ph.D. 
301 ECON/FUN ACE 282 9632 Ph.D. 
335 ACCT CDE 122 10720 Ph.D. 
342 ENG DKD 312 10944 Ph.D. 
387 SOC RTE 152 12384 Ph.D. 
401 BIOL DK 234 12832 MA 
425 HIST DFR 13600 MBA 
435 ECON/FUN DDF 39 13920 Ph.D. 
 
Nome da Tabela: DEPARTAMENTO 
 Chave primária: DEPT_CODE 
 Chave estrangeira: EMP_NUM 
 DEPT_CODE DEPT_NAME SCHOOL_CODE EMP_NUM DEPT_EXTENSION 
ACCT Accounting BUS 114 2933 
ART FineArts ASCI 435 2832 
BIOL Biology ASCI 387 4813 
CIS Computer Info. Systems BUS 209 4821 
ECON/FIN Economics/Finance BUS 299 3845 
ENG English ASCI 160 2482 
HIST History ASCI 103 3365 
MATH Mathematics ASCI 297 3461 
MKT/MGT Marketing/Management BUS 106 3471 
PSYCH Psychology ASCI 195 5732 
SOC Sociology ASCI 342 5735 
 
O relacionamento 1:M “o DEPARTAMENTO emprega o PROFESSOR” é implementado por meio da 
inserção da chave estrangeira DEPT_CODE na tabela PROFESSOR 
O relacionamento 1:1 “o PROFESSOR chefia o 
DEPARTAMENTO” é implementado por meio da inserção 
da chave estrangeira EMP_NUM na tabela 
DEPARTAMENTO 
Figura 20 Relacionamento 1:1 implementado entre PROFESSOR e DEPARTAMENTO.
Ao examinar as tabelas da Figura 20, observe que há vários aspectos importantes:
• Cada professor é um funcionário da Tiny College. Portanto, a identificação do professor 
se dá por meio de EMP_NUM (número de funcionário). No entanto, observe que nem 
todos os funcionários são professores, existindo outro relacionamento opcional.
• O relacionamento 1:1 "o PROFESSOR gerencia o DEPARTAMENTO" é implementado 
com o EMP_NUM como chave estrangeira da tabela DEPARTAMENTO. Observe que 
o relacionamento 1:1 é tratado como um caso particular do relacionamento 1:M, no 
qual o lado muitos está restrito a uma única ocorrência. Nesse caso, DEPARTAMENTO 
contém EMP_NUM como um chave estrangeira para indicar que é o departamento que 
possui um gestor.
© Banco de Dados96
• Observe também que a tabela PROFESSOR contém a chave estrangeira DEPT_CODE 
para implementar o relacionamento 1:M "o DEPARTAMENTO emprega o PROFESSOR". 
Esse é um bom exemplo de como duas entidades podem participar de dois (ou mais) 
relacionamentos simultâneos.
Relacionamento M:N
Para explorar o relacionamento muitos para muitos (M:N), considere um ambiente típico 
de faculdade em que cada ALUNO possa estar em várias TURMAs e cada TURMA possa conter 
vários ALUNOs. O modelo ER da Figura 21 mostra esse relacionamento M:N.
Figura 21 Relacionamento M:N do ER entre ALUNO e TURMA.
Observe os aspectos do ER da Figura 21:
• Cada TURMA pode ter vários ALUNOs e cada ALUNO pode estar em várias TURMAs.
• Pode haver muitas linhas na tabela TURMA para qualquer linha da tabela ALUNO e 
pode haver muitas linhas da tabela ALUNO para qualquer linha da tabela TURMA.
Os problemas inerentes aos relacionamentos muitos para muitos (M:N) podem ser fa-
cilmente evitados, criando-se uma entidade composta (também chamada de entidade ponte 
ou entidade associativa). Como essa tabela é utilizada para ligar as tabelas originalmente no 
relacionamento M:N, a estrutura da entidade composta inclui, como chaves estrangeiras, pelo 
menos as chaves primárias das tabelas que estão sendo ligadas.
É possível criar a tabela composta MATRÍCULA, exibida na Figura 22, para ligar as tabelas 
TURMAS e ALUNO. Nesse exemplo, a chave primária da tabela é a combinação de suas chaves 
estrangeiras CLASS_CODE e STU_NUM.
Claretiano - Centro Universitário
97© U3 – Modelo de Dados Relacional
Figura 22 Conversão de um relacionamento M:N em dois relacionamentos 1:M.
Observe na Figura 23 que a entidade composta chamada MATRÍCULA representa a tabela 
de ligação entre ALUNO e TURMA.
Figura 23 Alteração do relacionamento M:N em dois relacionamentos 1:M.
Índices
Suponha que se queira localizar um livro específico em uma biblioteca. Faria sentido olhar 
todos os livros até encontrar o desejado? É claro que não: utiliza-se o catálogo da biblioteca, 
que apresenta índices por título, assunto e autor. O índice (tanto em um sistema manual como 
em computadores) aponta para o local do livro, transformando sua localização em uma solução 
rápida e simples. Um índice é uma disposição ordenada utilizada para acessar logicamente as 
linhas de uma tabela.
Suponha, ainda, que você queira encontrar um assunto como, por exemplo, o modelo ER 
neste livro. Faria sentido ler todas as páginas até encontrar o tópico acidentalmente? Certamen-
te não. É muito mais simples recorrer ao índice do livro, procurar a expressão modelo ER e ler 
as referências que apontam para a(s) página(s) adequada(s). Em cada caso, o índice é utilizado 
para localizar rapidamente um item necessário.
© Banco de Dados98
De modo geral, um índice é uma disposição ordenada de chaves e ponteiros. Cada chave 
aponta para a localização dos dados identificados por ela.
Imagine que você queira procurar as pinturas criadas por determinado pintor no banco de 
dados da Figura 24. Sem um índice, é necessário ler todas as linhas da tabela PINTURA e ver se 
o atributo PAINTER_NUM corresponde ao pintor solicitado. No entanto, indexando-se a tabela 
PINTOR e utilizando-se a chave de índice PAINTER_NUM, basta procurar o valor adequado desse 
atributo no índice e encontrar os ponteiros correspondentes. Em termos conceituais, o índice se 
assemelha à apresentação ilustrada na Figura 24.
Figura 24 Componentes de um índice.
Ao examinar a Figura 24, observe que o primeiro valor da chave de índice PAINTER_NUM 
(123) encontra-se nos registros 1, 2 e 4 da tabela PINTURA da Figura 18. O segundo valor PAIN-
TER_NUM (126) encontra-se nos registros 3 e 5 dessa mesma tabela.
Os SGBDs utilizam índices para finalidades muito diferentes. Você pôde aprender que os 
índices podem ser utilizados para recuperar dados de modo mais eficiente, mas os SGBDs tam-
bém podem aplicá-los para recuperar dados ordenados por um ou vários atributos específicos. 
A criação de um índice de sobrenome de clientes, por exemplo, permitirá a recuperação alfabé-
tica dos dados de clientes a partir de seus sobrenomes. Além disso, a chave de índice pode ser 
composta por um ou mais atributos.
Os índices executam um papel importante nos SGBDs para a implantação das chaves pri-
márias. Ao se definir a chave primária de uma tabela, o SGBD cria automaticamente um índice 
exclusivo para a(s) coluna(s)dessa chave.
12. PROJETO LÓGICO DE BANCO DE DADOS: MAPEAMENTO DO MODELO 
ENTIDADE-RELACIONAMENTO PARA O MODELO RELACIONAL
Anteriormente, foram definidas as relações para o projeto de um banco de dados simples 
para uma escola, cujo modelo entidade-relacionamento foi demonstrado na Unidade 2. Neste 
tópico, mostraremos, passo a passo, como converter o projeto conceitual de um banco de dados 
para o projeto lógico.
Você deve ter em mente as fases de construção de um banco de dados para facilitar as con-
versões do DER (diagrama entidade-relacionamento) para o modelo relacional. Vale relembrar 
que o modelo entidade-relacionamento é utilizado durante o projeto conceitual e o modelo de 
dados relacional, durante o projeto lógico da base. Com isso, é natural pensar em um algoritmo 
Claretiano - Centro Universitário
99© U3 – Modelo de Dados Relacional
que traduza os conceitos de um dos modelos (DER) nos conceitos do outro (relacional). Isso pode 
ser realizado de acordo com os seguintes passos:
1) Para cada tipo de entidade-forte E no diagrama entidade-relacionamento (DER), crie 
um esquema de relação R que inclua todos os atributos simples de E. Sobre os atribu-
tos compostos, inclua os atributos simples que os compõem. Escolha um dos atribu-
tos-chave de E como chave primária de R. Se a chave escolhida é composta, o conjunto 
dos atributos simples dessa chave forma a chave primária de R. Através do diagrama 
entidade-relacionamento representado pela Figura 25, você pode identificar que o 
atributo código constitui a chave primária da entidade ora nomeada de aluno, e o 
atributo endereço é composto pelos atributos simples rua, número e bairro.
Aluno
Idade
Telefone
Endereço
Código
Nome
Sexo
Rua
Bairro
Número
Nascimento
Figura 25 ALUNO (Código, Nome, Sexo, Nascimento, Rua, Número, Bairro).
2) Para cada tipo de entidade-fraca F no diagrama ER, crie um esquema de relação R 
que inclua todos os atributos simples de F. Além disso, inclua como chave estrangeira 
de R os atributos que formam a chave primária do esquema de relação associado à 
entidade proprietária E de F. A chave primária de R é uma combinação da chave pri-
mária de E com a chave parcial de F. A Figura 26, através do diagrama-relacionamento, 
apresenta um exemplo de entidade-fraca chamada de dependente, a qual possui uma 
chave primária composta formada pelos atributos NSS e Nome, onde o atributo NSS 
é uma chave estrangeira que referencia a chave primária da entidade identificada de 
empregado.
© Banco de Dados100
Figura 26 DEPENDENTE (NSS, Nome, Data_nasc, Relação, Sexo).
3) O diagrama ER identificado na Figura 27 demonstra cada tipo de relacionamento bi-
nário R 1:1 no diagrama ER. Identifique os esquemas de relação S e T que dele parti-
cipam. Escolha uma das relações, digamos S, e inclua como chave estrangeira de S a 
chave primária de T. Inclua todos os atributos simples de R como atributos de S. Ou 
seja, você pode identificar que o atributo nome forma a chave primária da entidade 
departamento. Como se trata de um relacionamento 1:1, no qual um empregado 
pode apenas gerenciar um único departamento e, por sua vez, um departamento 
pode ser gerenciado por no máximo um empregado, torna-se necessário inserirmos 
uma chave estrangeira em departamento. Essa chave é identificada de NSS, que refe-
rencia a chave primária da entidade empregado.
Figura 27 DEPARTAMENTO (Nome, Número, NSS).
CE
CE
Claretiano - Centro Universitário
101© U3 – Modelo de Dados Relacional
Nesse caso, em que a cardinalidade é 1:1, escolhe-se o lado no qual se deve colocar a 
chave estrangeira. Na prática, é melhor fazer essa "escolha" no momento do DER, que deixaria 
o relacionamento conforme demonstrado na Figura 28:
Figura 28 Mapeamento de relacionamento binário (cardinalidade 1:M).
4) Para cada tipo de relacionamento binário R 1:M, identifique o esquema S que repre-
senta o tipo de entidade do lado M de R. Inclua como chave estrangeira de S a chave 
primária do esquema T que representa o outro tipo de entidade (do Lado 1). Inclua 
todos os atributos simples de R como atributos de S. Você pode perceber que, ao 
realizamos o mapeamento da entidade turma, representada pela Figura 29, foi neces-
sário incluir o atributo codigo_curso, que, devido à cardinalidade 1:M, é uma chave 
estrangeira que referencia a chave primária da entidade curso.
Nome
Período Letivo
Início
Término
(1,M) (1,1)
Código
Código
Curso TurmaPossui
Figura 29 TURMA (Codigo_Tur, Periodo_letivo, Dta_inicio, Dta_termino, Codigo_curso).
5) Para cada tipo de relacionamento binário R M:M, crie um novo esquema de relação 
S para representá-lo. Inclua como chave estrangeira de S as chaves primárias dos es-
quemas de relação que representam os tipos de entidade participantes do relacio-
namento. A combinação dessas chaves forma a chave primária de S. Inclua todos os 
atributos simples de R como atributos de S. Na Figura 30, que ilustra um exemplo 
de um diagrama ER, você constatará a necessidade de criarmos um novo esquema, 
este identificado de professor_leciona_disciplina, que é formado pelos atributos co-
digo_prof e codigo_disc. Ambos formam a chave primária composta dessa entidade 
e também são chave estrangeira, ou seja, codigo_prof referencia a chave primária da 
entidade professor e codigo_disc referencia a chave primária da entidade disciplina.
CE
© Banco de Dados102
Professor
Disciplinas
Código
Código
Nome
Nome
Título
(1,M)
(1,M)
(1,M)
leciona
oferecida
Figura 30 PROFESSOR_LECIONA_DISCIPLINA (Codigo_prof, Codigo_disc). 
6) Para cada atributo multivalorado A, crie um novo esquema de relação R. Esse esque-
ma incluirá dois atributos: um correspondente a A e outro correspondente à chave 
primária K do esquema que representa o tipo de entidade que possui A como atribu-
to. A chave primária de R é a combinação de A e K. Perceba que, quando realizamos o 
mapeamento da entidade aluno, ilustrada na Figura 31, torna-se necessário a criação 
de um esquema, esse identificado de telefone_aluno, formado pelos atributos codi-
go_alu e telefone, onde codigo_alu é a chave estrangeira que referencia a chave pri-
mária da entidade aluno, pelo simples fato de o atributo telefone ser multivalorado.
Aluno
Idade
Telefone
Endereço
Código
Nome
Sexo
Rua
Bairro
Número
Nascimento
Figura 31 TELEFONE_ALUNO (Codigo_alu, Telefone).
7) Para cada tipo de relacionamento m-ário R, em que M>2, crie um novo esquema de 
relação S para representar R. Inclua como chaves estrangeiras em S as chaves primá-
rias dos esquemas de relação relacionados aos tipos de entidades que participam do 
relacionamento. Inclua todos os atributos simples de R como atributos de S. A chave 
primária de S corresponde à combinação de todas as chaves estrangeiras que referen-
ciam os esquemas de relação das entidades participantes do relacionamento. A Figura 
32 representa esse tipo de relacionamento, tornando-se necessário a realização do 
mapeamento do relacionamento identificado de matricula-se, que, a partir de agora, 
passa a ser uma entidade, a qual é nomeada de matrícula, formada pelos atributos 
CE
CE
Claretiano - Centro Universitário
103© U3 – Modelo de Dados Relacional
codigo_tur, codigo_disc, codigo_prof e codigo_alu. Todos esses atributos, chaves es-
trangeiras, referenciam respectivamente suas chaves primárias correspondentes.
Turma
Professor
Disciplina
Aluno
Media_Final
dsc_turma
nom_aluno
end_aluno
fone_aluno
dta_nascimento
cod_turma
cod_aluno
cod_disc
cod_prof
nome_prof
end_prof
fone_prof
nom_disc
carga_horaria_disc
Nota_1B
Nota_B
(1,M)
(1,M)
(1,M)
(1,M)
matricula-se
Desempenho
Figura 32 MATRICULA (Codigo_tur, Codigo_Disc, Codigo_Prof, Codigo_alu).
O relacionamento descrito é um relacionamento quaternário. Quando há três entidades 
envolvidas, chamamos de relacionamento ternário.
Considerando o banco de dados escolar demonstrado na Unidade 2, você verá, a seguir, 
um exemplo de banco de dados lógico.
De acordo com os sete passosmencionados anteriormente, definiremos, agora, as entida-
des e os atributos das entidades. 
Por exemplo, no caso do banco de dados escolar (Figura 33), você deve, inicialmente, se-
guir o Passo 1. Logo você terá as seguintes entidades:
CE CE CE CE
© Banco de Dados104
Professor
leciona
Código
Nome
Título
Código
Nome
Disciplina
oferecida
Nome
Código
Curso
Possui
Turma
Aluno
matricula-se
Código
Período Letivo
Início
Término
Idade
Telefone
Endereço
Rua
Número
BairroCódigo
Nome
Sexo
Nascimento
Número Alunos
Data Matrícula
Data Cancelamento
Motivo Cancelamento
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M)
(1, M) (1, M)
Figura 33 DER Sistema Escolar.
1) PROFESSOR (Codigo, Nome, Titulo). 
2) DISCIPLINA (Codigo, Nome).
3) CURSO (Codigo, Nome).
4) TURMA (Codigo, Periodo_letivo, Inicio, Termino).
5) ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade).
Na sequência, vá para o Passo 2; veja que, neste exemplo, não temos nenhuma entidade-
-fraca. Seguindo as instruções dos Passos 3, 4 e 5, teremos as seguintes chaves estrangeiras em 
cada relação:
PROFESSOR (Codigo, Nome, Titulo)
DISCIPLINA (Codigo, Nome)
PROFESSOR_LECIONA_DISCIPLINA (Codigo_prof, Codigo_disc)
CURSO (Codigo, Nome)
TURMA (Codigo, Codigo_curso, Periodo_letivo, Inicio, Termino)
DISCIPLINA_OFERECIDA_TURMA (Codigo_disc, Codigo_tur)
ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade)
MATRÍCULA (Codigo_alu, Codico_tur, Dta_matricula, Dta_cancelamento, Mot_
cancelamento)
Note que a relação MATRICULA não tem "número de alunos", que é um atributo derivado, 
ou seja, ele pode ser consultado por meio de uma pesquisa contando-se o número de alunos. 
Assim, ele só existe no DER, e o mesmo acontece com a IDADE do aluno, que pode ser calculada 
subtraindo sua data de nascimento da data atual. 
CE CE
CE
CE CE
CE CE
Claretiano - Centro Universitário
105© U3 – Modelo de Dados Relacional
No Passo 6, é fundamental que você localize cada atributo multivalorado e crie uma nova 
relação. Dessa forma, foi criada a relação TELEFONE_ALUNO. Para a relação MATRICULA, a "data 
da matrícula" fará parte da chave primária, uma vez que a MATRICULA já é uma nova relação e, 
por fazer parte da chave primária, será possível cadastrar várias datas de matrícula. 
O banco de dados escolar terá a seguinte estrutura: 
PROFESSOR (Codigo, Nome, Titulo)
DISCIPLINA (Codigo, Nome)
PROFESSOR_LECIONA_DISCIPLINA (Codigo_Prof, Codigo_disc)
CURSO (Codigo, Nome)
TURMA (Codigo, Codigo_curso, Periodo_letivo, Inicio, Termino)
DISCIPLINA_OFERECIDA_TURMA (Codigo_disc, Codigo_tur)
ALUNO (Codigo, Nome, Sexo, Nascimento, Rua, Numero, Bairro, Cidade)
TELEFONE_ALUNO (Código_alu, Telefone)
MATRICULA (Codigo_alu, Codigo_tur, Dta_matricula, Dta_cancelamento, Mot_
cancelamento)
Considerando o modelo escolar, para o Passo 7, não há nenhum relacionamento M-ário. 
Na próxima unidade, você aprenderá como gerar o SQL deste banco de dados aplicando restri-
ções e todos os conceitos envolvidos até o momento.
13. QUESTÕES AUTOAVALIATIVAS
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta 
unidade:
1) Defina e exemplifique os seguintes conceitos
a) Chave candidata.
b) Chave estrangeira.
2) Quais são as principais regras de integridade de entidades?
3) Quais são as principais regras de integridade referencial?
4) Quais são os principais operadores pertinentes ao conjunto relacional?
5) Exemplifique os seguintes relacionamentos:
a) Relacionamento 1:M.
b) Relacionamento 1:1.
c) Relacionamento M:N.
6) A questão a seguir utilizou os dados de um banco de dados simplificado, apresentado pelas tabelas CLIENTE, 
PEDIDO e ITEM, dispostos na Figura 34. 
CE CE
CE
CE CE
CE
CE CE
© Banco de Dados106
Figura 34 Tabelas CLIENTE, PEDIDO e ITEM.
No modelo apresentado, a especificação de chave primária correta é:
a) atributo id_item na tabela Item.
b) atributo id_loja na tabela Pedido.
c) atributo id_pedido na tabela Item.
d) atributo nome na tabela Cliente.
e) Atributos id_pedido, id_item na tabela Item.
7) Pode-se afirmar que os relacionamentos entre as tabelas Cliente e Pedido e entre as tabelas Pedido e Item são, 
respectivamente: 
a) 1:1 e 1:N.
b) 1:N e 1:1.
c) 1:N e 1:N.
d) 1:N e N:N.
e) N:N e 1:N.
Gabarito 
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
6) e.
7) c.
14. CONSIDERAÇÕES 
Nesta unidade, você teve a oportunidade de conhecer o Modelo Relacional, ou seja, um 
Modelo de Dados Lógico para o ambiente escolar.
Claretiano - Centro Universitário
107© U3 – Modelo de Dados Relacional
O aprendizado passo a passo do processo de mapeamento do esquema conceitual para o 
esquema relacional permitiu a compreensão de como iniciar a formulação e criação do banco 
de dados relacional.
As relações do banco de dados para uma escola, apresentadas na Unidade 2, foram utili-
zadas para exemplificar as tabelas e aplicar restrições de integridade. Nesta unidade, também 
foram apresentados alguns comandos básicos da linguagem SQL. A confecção de consultas mais 
completas e complexas exigirá o conhecimento de Álgebra Relacional (ver Apêndice 3) e o uso 
da linguagem SQL, que será discutida na próxima unidade.
Para que compreenda melhor os conceitos apresentados, sugerimos que você retorne a 
esta unidade após o estudo da Unidade 4. 
Bons estudos!
15. E-REFERÊNCIAS
ALVARENGA, J. P. Informática: Banco de Dados I. Disponível em :<http://pt.scribd.com/doc/34137068/9/RELACIONAL>. Acesso 
em: 23 out. 2012.
DFC-UFMS. Disponível em: <http://www.dct.ufms.br/~said/disciplinas/bd/bd.html>. Acesso em: 14 jan. 2008.
16. REFERÊNCIAS BIBLIOGRÁFICAS
ELMASRI, R.; NAVATHE, S.B. Sistemas de bancos de dados. São Paulo: Pearson (Addison Wesley), 2005.
KORTH, H.; SILBERCHATZ, A. Sistemas de bancos de dados. 3. ed. São Paulo: Makron Books, 1998.
PRESSMAN, R. S. Engenharia de software. São Paulo: Makron Books, 1995.
RAMAKRISHNAN, R. GEHRKE, J. Database management systems. 2. ed. Boston: McGraw-Hill, 2000.
Claretiano - Centro Universitário
4
SQL – Uma Linguagem de 
Consulta
1. OBJETIVOS
• Compreender os conceitos da Linguagem SQL, seu funcionamento e aplicações práti-
cas.
• Construir aplicações utilizando a Linguagem SQL.
2. CONTEÚDOS
• Linguagem SQL.
• Principais operações para atualização dos dados.
• Estrutura da Linguagem SQL.
• Aplicação da Linguagem utilizando PostgreSQL.
• Introdução à Linguagem SQL avançada.
• Introdução às Visões.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE 
Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Sua formação é essencial, pois ela determinará posturas e escolhas no desenvolvi-
mento de sua prática. Invista em você, faça da pesquisa e da interação com seus cole-
gas de curso e tutor um hábito, o qual poderá ajudá-lo a ampliar e a aprofundar seus 
conhecimentos. 
© Banco de Dados110
2) Para executar os comandos SQL, apresentados nesta unidade, você deverá ter insta-
lado o SGBD PostgreSQL. Veja, no Apêndice 1, todos os passos para a sua instalação.
3) Conheça o site do American National Standards Institute (ANSI), disponível em: 
<http://www.ansi.org>. Acesso em: 4 out. 2012.
4) Para que você possa dar continuidade aos estudos das demais unidades, é fundamen-
tal ter pleno conhecimento dos conceitos da linguagem SQL. Para isso, sugerimos que 
você pratique os exemplos apresentados no decorrer desta unidade.
5) Além dos exercícios apresentados neste estudo, consulte outras referências. Fique à 
vontade para compartilhar listas de exercícios e trocar ideias sobre como resolvê-los 
com seus colegas de turma e com seu tutor pela Sala de Aula Virtual. 
6) Atente para algumas observações importantes para o estudo desta unidade: introdu-
ção à linguagem SQL básica e avançada e principais operações para atualização dos 
dados utilizando o PostgreSQL. Recorra aos exemplos apresentados na unidade, faça 
consultas usando vários recursos, pois isso torna seu aprendizadomais estimulante e 
desafiador.
4. INTRODUÇÃO À UNIDADE
Na unidade 3, você teve a oportunidade de aprender que os Sistemas Gerenciadores de 
Bancos de Dados baseiam-se no modelo relacional e que é, a partir dele, que se desenvolve um 
modelo de banco de dados relacional, fazendo o mapeamento do modelo entidade-relaciona-
mento para o modelo relacional.
Nesta unidade, você trabalhará com a linguagem SQL, que é a linguagem utilizada para 
criação e manipulação de bancos de dados a partir dos Sistemas Gerenciadores de Bancos de 
Dados Relacionais.
5. LINGUAGEM SQL
A linguagem SQL (Structured Query Language – Linguagem de Consulta Estruturada) não é 
uma linguagem de programação de computadores criada com o propósito de desenvolver siste-
mas, como as linguagens Pascal, C, Basic, Cobol, Java, C/C++, C#, dentre outras. Trata-se de uma 
linguagem declarativa, cuja finalidade é facilitar o acesso às informações por meio de consultas, 
atualizações e manipulações de dados, os quais são armazenados em bancos de dados relacionais.
A linguagem SQL foi criada pela IBM (International Business Machine) e desenvolvida pelo 
PhD Donald D. Chamberlin, em 1974, com o nome Structured English Query Language (SEQUEL). 
A linguagem de consulta estruturada SEQUEL foi disponibilizada para uso de um banco de dados 
relacional da própria IBM, agora denominada de SEQUEL-XRM (1974-1975). Entre o período 
correspondente a 1976 e 1977, a IBM realizou uma revisão da linguagem SEQUEL, nomeando-
-a de SEQUEL/2, a qual, posteriormente, passou a ser conhecida e referenciada pela sigla SQL.
Em 1979, participantes do projeto de desenvolvimento do SYSTEM/R fundaram uma em-
presa, por ocasião denominada Relational Software Inc., que disponibilizou o primeiro Sistema 
de Gerenciamento de Banco de Dados Relacional Comercial, totalmente baseado na linguagem 
SQL. Esse SGBD, intitulado de Oracle (o mesmo Oracle atualmente conhecido), foi pioneiro na 
forte concorrência junto à IBM.
Entre 1980 e 1981, a IBM implementou a linguagem SQL nos seus Sistemas de Geren-
ciamento de Bancos de Dados Comerciais (BD2 – DataBase2 e SQL/Data), garantindo que essa 
linguagem de consulta estruturada SQL se tornasse um padrão. 
Claretiano - Centro Universitário
111© U4 – SQL – Uma Linguagem de Consulta
Devido a sua boa aceitação no mercado, surgiram os primeiros problemas operacionais, 
pois cada empresa passou a incorporar funcionalidades e comandos próprios à linguagem SQL, 
diferenciando-a da sua forma original. Na tentativa de anular tais problemas, surge, nesse ce-
nário, o ANSI (American National Standards Institute), o qual passou a estabelecer, por meio de 
um Comitê, normativas e critérios para definição de padrões para a linguagem SQL, que a partir 
desse período passou a ser referenciada ANSI/SQL. Em 1986, foi criado o primeiro padrão oficial 
para a linguagem SQL, nomeado de SQL/86. No ano seguinte, o ANSI, junto à ISO (International 
Standards Organizations), desenvolveu uma extensão ao padrão SQL, constituindo o segundo 
padrão para a linguagem SQL (SQL/89). Em 1992, firmando a parceria estabelecida entre ANSI 
e ISO, um novo padrão foi apresentado, agora denominado SQL2 (SQL/92). O quarto padrão foi 
oficialmente apresentado em 1999, intitulado de SQL3 (SQL/99). Por fim, em 2003, foi apresen-
tada a última revisão da linguagem SQL, com a definição do padrão SQL/2003, que incorporava, 
dentre outros recursos diferenciais, recursos relacionados ao padrão XML (Extensible Markup 
Language).
Apesar dos inúmeros esforços de entidades e institutos de padronização para construir 
um padrão de trabalho adequado, infelizmente ainda existem empresas que implementam ro-
tinas, funções e comandos totalmente fora do padrão estabelecido, dificultando a vida dos pro-
fissionais da área de Tecnologia da Informação (TI). Em alguns casos isolados, essas empresas 
utilizam mais de um Sistema de Gerenciamento de Banco de Dados em um mesmo ambiente 
operacional.
A linguagem SQL utilizada no SGBD PostgreSQL é segmentada em quatro subconjuntos 
que formam a base das instruções – DDL (Data Definition Language), DML (Data Manipulation 
Language), DCL (Data Control Language) e DQL (Data Query Language) –, podendo, ainda, in-
cluir os subconjuntos SRC (Stored Routines Commands) e DTC (Data Type Commands). Veja suas 
características a seguir:
DDL – Data Definition Language (Linguagem de Definição de Dados)
Este subconjunto oferece recursos para definir objetos e controlar dados, ou seja, são 
comandos responsáveis pela estruturação do banco de dados, como a própria criação do banco 
de dados (database), criação das tabelas, dos índices, dentre outras possibilidades. Podemos 
mencionar alguns comandos que constituem a DDL, como: ALTER TABLE, CREATE DATABASE, 
CREATE INDEX, CREATE TABLE, CREATE VIEW, DROP DATABASE, DROP INDEX, DROP TABLE, DROP 
VIEW, entre outros. 
DML – Data Manipulation Language (Linguagem de Manipulação de Dados) 
Subconjunto de comandos que tem como finalidade promover mecanismos para mani-
pulação e gerenciamento dos bancos de dados, inserindo, alterando e removendo os dados. Os 
comandos que constituem esse subconjunto são: DELETE, INSERT, UNION E UPDATE. 
DCL – Data Control Language (Linguagem de Controle de Dados) 
Comandos responsáveis por oferecer recursos de controle de acesso de usuários ao sis-
tema e aos dados, estabelecendo regras para realização de consultas, inserções, modificações 
e exclusões de dados do banco de dados. A linguagem DCL é constituída pelos comandos: AL-
TER USER, CREATE GROUP, CREATE ROLE, DROP GROUP, CREATE USER, DROP ROLE, DROP USER, 
GRANT E REVOKE.
© Banco de Dados112
DQL – Data Query Language (Linguagem de Pesquisa de Dados) 
É considerado por alguns autores como um comando pertencente ao subconjunto Data 
Manipulation Language, pelo simples fato de ser manipulado em conjunto com outros coman-
dos DML. É formado apenas pelo comando SELECT.
SRC – Stored Routines Commands (Comandos de Rotinas Armazenadas) 
Comandos que permitem a utilização de códigos de sub-rotinas armazenadas no SGBD, 
tais como: AFTER, AS, BEFORE, BEGIN, CALLED, CREATE, DECLARE, DEFINER, EACH, ELSE, EL-
SIF, END, EXCEPTION, EXECUTE, EXTERNAL, FOR, FUNCTION, IF, IMMUTABLE, INPUT, INVOKER, 
LANGUAGE, LOOP, NEW, NOTICE, NULL, OLD, ON, OR, PROCEDURE, RAISE, REPLACE, RETURN, 
RETURNS, ROW, SECURITY, entre outros.
DTC – Data Type Commands (Comandos de Tipos de Dados) 
Grupo de comandos responsáveis por estabelecer o tipo de dado que uma coluna (campo/
atributo) armazena em uma tabela específica. Os comandos que formam o DTC são: BIGINT, BI-
GSERIAL, CHAR, CHARACTER, DATE, DECIMAL, DOUBLE, INTEGER, INT, MONEY, NUMERIC, REAL, 
SERIAL, SMALLINT, TIME E VARCHAR.
É importante destacar que além dos comandos descritos, existe um conjunto de funções 
predefinidas, como uma série de operadores que promovem facilitadores nas diversas ações 
realizadas pelos aplicativos.
6. HISTÓRICO DO POSTGRESQL
O software PostgreSQL é um Sistema de Gerenciamento de Banco de Dados Objeto-Rela-
cional (SGBDOR), desenvolvido no Departamento de Ciência da Computação da Universidade da 
Califórnia, em Berkeley. Sua distribuição é realizada em regime open source, como uma conside-
rável alternativa aos Sistemas de Gerenciamento de Banco de Dados Oracle, SQL Server, MySQL, 
dentre outros.
No início de 1987, com objetivo de demonstrar o SGBD, uma versão preliminar foi liberada. 
Entretanto, foi apenas no final de 1987 que ocorreu a liberação da versão 1.0 na Conferência ACM-
-SIGMOD, para um grupo restrito de usuários. Em 1990, a versão 2.0 foi liberada com inúmeras 
melhorias em relação à primeira versão. A última versão oficial (versão 4.2) foi desenvolvida pela 
Universidade da Califórnia em Berkeley. Andrew Yu e Jolly Chen, em 1994, incluíram ao SGBD um 
interpretador da linguagem SQL, lançando um novo produto, ora nomeado de Postgres95.
O SGBD Postgres95 decolou rapidamente pelo fato de ter sido liberado livremente pela 
internet e por apresentarmelhor desempenho (cerca de 30% a 50%) comparado ao Postgres4.2. 
Devido à associação do nome ao ano de 1995 (Postgres95), o grupo de desenvolvimento decidiu 
alterar seu nome para PostgreSQL, nome pelo qual é conhecido atualmente. A versão utilizada 
nesta obra para o Sistema de Gerenciamento de Banco de Dados PostgreSQL é a versão 9.0, 
disponibilizada em setembro de 2011.
7. PRINCIPAIS OPERAÇÕES PARA MANIPULAÇÃO DE DADOS
Para interagirmos com as principais operações de manipulação de dados, é necessário ini-
ciar a ferramenta pgAdmin III, realizar a conexão com o Sistema Gerenciador de Banco de Dados 
Claretiano - Centro Universitário
113© U4 – SQL – Uma Linguagem de Consulta
por meio da autenticação (login), utilizando o usuário root, nomeado de Postgres, e informar o 
respectivo password, configurado na instalação do SGBD (conforme Anexo 1).
O primeiro passo para o desenvolvimento de um banco de dados é definir seu esquema. 
Para isso, utiliza-se o comando CREATE DATABASE. 
Exemplo: 
CREATE DATABASE NOME 
[ARGUMENTOS]
Em que:
1) Apenas o valor da variável NOME é obrigatório (representa o nome do banco de dados 
(database) que será criado).
a) NOME: espaços em branco e caracteres especiais devem ser evitados.
2) Argumentos opcionais podem ser usados, como:
a) OWNER: usuário responsável pelo banco de dados que será criado.
b) TEMPLATE: permite criar um banco de dados seguindo um modelo estrutural pre-
existente.
c) ENCODING: indica qual o conjunto de caracteres que o banco de dados utilizará 
(moeda corrente e acentuação).
d) TABLESPACE: define a qual tablespace este banco de dados pertencerá.
e) CONNECTION LIMIT: permite limitar o número de conexões simultâneas (-1 cor-
responde a infinitas conexões).
Exemplo: 
CREATE DATABASE "FACULDADE"
TEMPLATE = TEMPLATE0
ENCODING 'WIN1252'
CONNECTION LIMIT -1;
Os comandos anteriores criam o banco de dados nomeado FACULDADE. Na sequência, 
é necessário trocar de banco de dados (database), visto que o banco de dados Postgres não 
poderá conter nenhum objeto. Ou seja, esse banco de dados é utilizado apenas para funções 
administrativas, como a criação de novos bancos de dados, realização de tuning, dentre outras 
funcionalidades. 
A remoção de um banco de dados (esquema) é proveniente do comando DROP DATABASE 
via interface pgAdmin III e/ou via interface de linha de comando (psql), por meio do comando 
DROPDB. A seguir, temos um exemplo do comando que realiza a remoção do database (esque-
ma) identificado como FACULDADE, via interface pgAdmin III.
Exemplo: 
DROP DATABASE "FACULDADE"
Observação: na necessidade de desconectar-se do banco de dados, o qual queremos ex-
cluir/remover, normalmente utilizamos o banco de dados (esquema/database) padrão nomea-
do Postgres.
Já conectado corretamente ao banco de dados FACULDADE, talvez seja necessário extrair 
algum tipo de informação das variáveis de ambiente do SGBD. Por exemplo, a identificação da 
versão do servidor de banco de dados, por meio da instrução SELECT VERSION(), composta pelo 
instrução SELECT juntamente à função VERSION(). 
© Banco de Dados114
Exemplo: 
SELECT VERSION();
Imagine, agora, que necessitamos obter informações sobre a data atual do SGBD. De acor-
do com o exemplo a seguir, podemos extrair esse tipo de informação utilizando a instrução 
SELECT CURRENT_DATE, obtendo, assim, a informação da data de acordo com as regras norte-
-americanas (AAAA-MM-DD), em que AAAA corresponde ao ano, MM ao mês e DD ao dia. 
Exemplo: 
SELECT CURRENT_DATE;
Exibida a data, seria também oportuno obter a hora atual do servidor (SGBD), por meio da 
instrução SELECT CURRENT_TIME, formada pelo comando SELECT e a função CURRENT_TIME. 
Observe que a hora será exibida no formato HH:MM:SS, em que HH corresponde às horas, MM 
aos minutos e SS aos segundos. 
Exemplo: 
SELECT CURRENT_TIME;
A função NOW() é utilizada para exibir a data e a hora simultaneamente, podendo ser uti-
lizada junto à instrução SELECT, formando o comando SELECT NOW().
Exemplo: 
SELECT NOW();
Além das informações de data e hora (NOW()), hora atual do servidor (CURRENT_TIME) 
e versão atual do servidor de banco de dados (VERSION()), é permitido, também, extrairmos 
informações sobre o usuário atual conectado no banco de dados, por meio da instrução SQL. 
Veja a seguir:
Exemplo: 
SELECT CURRENT_USER();
Calculadora do PostgreSQL
Por meio da instrução SELECT, o PostgreSQL permite a realização de diversas operações 
aritméticas como adição (+), subtração (-), multiplicação (*), divisão (/) e resto de divisão (%). O 
comando a seguir obtém o resultado de quatro operações aritméticas em uma única instrução 
SELECT. Podemos lançar uso de parênteses, alterando a prioridade com que as operações serão 
executadas. 
Exemplo: 
SELECT 3 + 8.3, 4 - 2.3, 5 * 3.21, 6 / 0.23; 
SELECT (3 * 6) + 0.24;
Claretiano - Centro Universitário
115© U4 – SQL – Uma Linguagem de Consulta
Além das operações aritméticas básicas, o PostgreSQL possui um conjunto de funções 
matemáticas internas, como funções para: calcular um valor absoluto, obter o resto da divisão, 
realizar arredondamento de valores numéricos, exponencial, logaritmo, potência, dentre ou-
tras. Veja essas funções na Tabela 1:
Tabela 1 Funções matemáticas internas.
OPERADOR OPERAÇÃO TIPO RESULTADO
+ Manutenção de sinal Operador aritmético Positivo
- Inversão de sinal Operador aritmético Negativo
POWER(X, N) Exponenciação Função Real
SQRT(X) Raiz quadrada de X Função Real
POWER(X, (1/N)) Raiz de índice qualquer Função Real
TRUNC(X / N) Divisão de X por N com quociente inteiro Função Inteiro
MOD(X, N) Resto da divisão de X por N Função Inteiro
/ Divisão com quociente real Operador aritmético Real
* Multiplicação Operador aritmético Inteiro ou Real
+ Adição Operador aritmético Inteiro ou Real
- Subtração Operador aritmético Inteiro ou Real
% Resto da divisão Operador aritmético Inteiro
A precedência de processamento dos operadores aritméticos segue de acordo com sua 
prioridade matemática. Por exemplo, a realização das operações de radiação e exponenciação 
precede as operações de multiplicação, divisão, adição e subtração, consecutivamente.
Um banco de dados é formado por tabelas, as quais são criadas por meio do comando 
CREATE TABLE. Para definir este comando, utilizaremos como base o modelo relacional, já nor-
malizado, ou seja, já extraídas as anomalias de inserção, exclusão e alteração. Para cada relação 
constante no modelo relacional, você deverá criar um comando CREATE TABLE: cada uma das 
relações é, na verdade, uma tabela do banco de dados. 
Para tanto, utilizaremos, nesta obra, o PostgreSQL, que é um gerenciador de bancos de 
dados (que está descrito no Apêndice 1). Ele instalará em seu computador todas as ferramentas 
necessárias para que você possa acompanhar plenamente o conteúdo. Para acessar suas bases 
de dados, é necessário utilizar uma ferramenta de manipulação e gerenciamento de bases de 
dados, que, neste caso, corresponde ao pgAdmin III.
Os componentes mais importantes de um banco de dados são as tabelas, pois permitem a 
manipulação dos registros e a manutenção de bancos de dados, ou seja, local onde uma coleção 
de dados é inserida. A criação de tabelas por meio da linguagem SQL utiliza a instrução CREATE 
TABLE, seguida do nome da tabela, bem como de outros argumentos para determinação de sua 
estrutura. A sintaxe básica do comando CREATE TABLE é:
CREATE TABLE nome da tabela (
COLUNA1 TIPO DE DADOS [restrição],
COLUNA2 TIPO DE DADOS [restrição],
PRIMARY KEY (coluna1, coluna2),
FOREIGN KEY (coluna1) REFERENCES nome da tabela (colunas)
CONSTRAINT restrição
);
© Banco de Dados116
O nome da tabela é a indicação do nome da tabela a ser criada no banco de dados, co-
luna1 e coluna2 (campo) são a indicação dos nomes dos campos a serem definidos e tipo de 
dados define o tipo de dado a partir de uma lista de tipos padrão.
O PostgreSQL trabalha com diversos tipos de dados, classificados de acordo com o con-
teúdo que será utilizadoem uma determinada coluna. Os principais tipos de dados suportados 
pelo nosso SGBD, ou seja, os tipos de dados (atributos) mais usuais podem ser visualizados no 
Quadro 1. 
Quadro 1 Tipos de dados.
TIPO DE DADO DESCRIÇÃO
Bigint
Representa valores inteiros da faixa de 
-9.223.372.036.854.775.808 até 9.223.372.036.854.775.807.
BigSerial Gera um valor único sequencial para um novo registro entre 1 e 9.223.372.036.854.775.807.
Char (tamanho) ou 
Character (tamanho)
São sequências de caracteres de tamanho fixo limitados a 255 
caracteres de comprimento. O parâmetro tamanho determina o 
valor máximo em caracteres que pode conter a sequência. Esse tipo de dado, 
quando definido, preenche o campo com espaços em branco até completar o 
total de caracteres definidos, quando a totalidade do tamanho do campo não 
é preenchida.
Date Data de calendário no formato AAAA-MM-DD (formato ANSI) com intervalo de tempo de 4.713 AC a 5.874.897 DC.
Decimal Determina a precisão do valor de casas decimais.
Double Determina a precisão do valor de até 15 casas decimais.
Integer ou Int Representa valores inteiros na faixa de -2.147.483.648 até 2.147.483.647.
Money
Define valores monetários na faixa numérica de 
-92.233.720.368.547.758.08 até 92.233.720.368.547.758.07.
Numeric Determina a precisão do valor de casas decimais.
Real Determina a precisão do valor de até seis casas decimais.
Serial Gera um valor único inteiro sequencial para o novo registro entre 1 e 2.147.483.647.
Smallint Representa valores inteiros na faixa de -32.768 até 32.767.
Time Representa um determinado horário de relógio no intervalo de tempo entre 00:00:00 e 24:00:00.
Varchar (tamanho)
Sequência de caracteres de tamanho variável que esteja limitada a 255 
caracteres de comprimento. A principal diferença existente entre o tipo 
char é que, neste caso, os espaços em branco excedentes do lado direito 
da sequência de caracteres não utilizados são desprezados. O 
parâmetro tamanho determina o valor máximo da sequência.
Blob Campo do tipo blob com tamanho máximo de 65535.
A partir de agora, já podemos definir uma grande variedade de campos para a construção 
das tabelas utilizadas na disciplina. Em nosso banco de dados, identificado como FACULDADE, 
será criado um conjunto de tabelas, conforme visualizado no modelo disposto na Figura 1.
Claretiano - Centro Universitário
117© U4 – SQL – Uma Linguagem de Consulta
Figura 1 Modelo de banco de dados utilizado na disciplina.
Após a instalação do PostgreSQL (passo a passo demonstrado no Apêndice 1) conforme 
sugerido, existirá em seu desktop um ícone com a imagem de um elefante azul, identificado 
como pgAdmin III (Figura 2).
Figura 2 Acessando a interface pgAdmin III.
© Banco de Dados118
Dê um duplo clique com o botão esquerdo do mouse sobre qualquer um dos ícones em 
destaque. Esse procedimento exibirá a interface do pgAdmin III, como demonstrado na Figura 3.
Figura 3 Tela principal do pgAdmin III.
É necessário conectarmos no SGBD; para isso, dê um clique com o botão direito do mouse 
sobre o servidor, nomeado PostgreSQL 9.0 (localhost:5432), selecionando a opção connect/
conectar ou apenas dê um duplo clique com o botão esquerdo do mouse. Na sequência, será ne-
cessário informar a senha fornecida na instalação do PostgreSQL, conforme exibido na Figura 4.
Figura 4 Conectando-se ao SGBD PostgreSQL. 
Após obtermos êxito na conexão com o nosso SGBD, uma tela semelhante à Figura 5 será 
exibida. Perceba que existe apenas um banco de dados (database/esquema) em nosso servidor, 
chamado postgres. Selecione o banco de dados postgres e clique com o botão esquerdo do 
mouse sobre o ícone Query Tool (Ctrl + E). 
Claretiano - Centro Universitário
119© U4 – SQL – Uma Linguagem de Consulta
Figura 5 Abrindo uma sessão SQL para o banco de dados postgres.
Após a criação da sessão SQL para o banco de dados postgres, podemos criar um novo 
banco de dados (schema/database): indique o nome e seus principais argumentos, conforme 
exemplificado na Figura 6:
Figura 6 Tela de digitação de comandos SQL no pgAdmin III / Criação de um novo banco de dados. 
Após clicar no botão/ícone Execute Query (F5), o banco de dados será criado, e a tela será 
semelhante à exibida na Figura 7.
© Banco de Dados120
Figura 7 Visualização de objetos no pgAdmin III .
Para criar os objetos (tabelas), selecione o banco de dados FACULDADE e clique com o bo-
tão esquerdo do mouse sobre o ícone Query Tool (Ctrl + E), criando uma nova sessão SQL, agora 
para o banco de dados FACULDADE. A partir daí, podemos inserir os comandos SQL a serem 
aplicados para o banco de dados corrente (atual).
O primeiro objeto a ser criado para o banco de dados FACULDADE será a tabela respon-
sável pelo armazenamento de dados oriundos dos clientes, ora identificada de CLIENTES. Na 
Tabela 2 podemos identificar os detalhes da estrutura da tabela CLIENTES.
Tabela 2 Clientes.
CAMPO TIPO DESCRIÇÃO
ID_CLIENTE integer Identificador do cliente (não nulo)
NM_CLIENTE varchar(10) Nome do cliente (não nulo)
SOBRENOME varchar(10) Sobrenome do cliente (não nulo)
DT_NASCIMENTO timestamp Data de nascimento do cliente 
TELEFONE varchar(12) Telefone do cliente
FG_ATIVO integer Status do cliente (ativo/inativo)
Chave Primária Campo/Atributo ID_CLIENTE
Claretiano - Centro Universitário
121© U4 – SQL – Uma Linguagem de Consulta
O campo/atributo ID_CLIENTE será definido como chave primária, fazendo com que não 
seja permitido inserir dois clientes com o mesmo código. Eventualmente, caso deseje definir 
uma tabela com mais de um campo contendo registros exclusivos (únicos), basta utilizar a cláu-
sula UNIQUE.
Em seguida, será criada a tabela CLIENTES a partir da interface do pgAdmin III, utilizada 
anteriormente para a criação do banco de dados FACULDADE. Escreva a sequência de instruções 
exatamente como nos comandos a seguir, dentro da sessão SQL do banco de dados FACULDADE. 
Para criar a tabela (essa e as próximas que serão apresentadas), clique no botão/ícone Execute 
Query (F5), como demonstrado na Figura 8.
Figura 8 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela CLIENTES.
Criando a tabela CLIENTES
Para a criação da tabela CLIENTES, siga os comandos a seguir:
CREATE TABLE CLIENTES(
id_cliente INTEGER,
nm_cliente VARCHAR(10) NOT NULL,
sobrenome VARCHAR(10) NOT NULL,
dt_nascimento TIMESTAMP,
telefone VARCHAR(12),
fg_ativo INTEGER,
PRIMARY KEY(ID_CLIENTE)
);
A segunda tabela a ser criada em nosso banco de dados será a tabela responsável pelo 
armazenamento de dados pertinentes aos tipos de produtos vendidos, nomeada TIPOS_PRO-
DUTOS. Observe, na Tabela 3, a estrutura da tabela TIPOS_PRODUTOS:
© Banco de Dados122
Tabela 3 Tipos Produtos.
CAMPO TIPO DESCRIÇÃO
ID_TIPO_PRODUTO integer Identificador do tipo do produto (não nulo)
DS_TIPO_PRODUTO varchar(10) Descrição do tipo do produto (não nulo)
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chave Primária Campo/Atributo ID_TIPO_PRODUTO
Após identificarmos com detalhes o conteúdo da tabela TIPOS_PRODUTOS, escreva a se-
quência de instruções como nos comandos a seguir, dentro da sessão SQL do banco de dados 
FACULDADE. Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, con-
forme visualizado na Figura 9. 
Figura 9 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela TIPOS_PRODUTOS.
Criando a tabela TIPOS_PRODUTOS
Para a criação da tabela TIPO_PRODUTOS, siga os comandos a seguir:
CREATE TABLE TIPOS_PRODUTOS(
id_tipo_produto INTEGER,
ds_tipo_produto VARCHAR(10) NOT NULL,
fg_ativo INTEGER,
PRIMARY KEY(ID_TIPO_PRODUTO)
);
A terceira tabela a ser criada em nosso banco de dados armazenará os dados referentes 
aos produtos comercializados, a qual identificaremos como PRODUTOS. Observe, na Tabela 4, a 
estrutura da tabela PRODUTOS.
Tabela 4 Produtos.
CAMPO TIPO DESCRIÇÃO
ID_PRODUTO integer Identificador do produto (não nulo)
ID_TIPO_PRODUTO integerIdentificador do tipo do produto (não nulo)
Claretiano - Centro Universitário
123© U4 – SQL – Uma Linguagem de Consulta
CAMPO TIPO DESCRIÇÃO
NM_PRODUTO varchar(30) Nome do produto a ser comercializado (não nulo)
DS_PRODUTO varchar(50) Descrição do produto a ser comercializado
PRECO numeric(5,2) Preço praticado para comercialização do produto
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chave Primária Campo/Atributo ID_PRODUTO
Chave Estrangeira Campo/Atributo ID_TIPO_PRODUTO
Na sequência, insira as instruções dentro da sessão SQL do banco de dados FACULDADE. 
Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, como demonstrado 
na Figura 10. 
Figura 10 Tela de digitação do comando SQL no pgAdmin III / Criação da tabela PRODUTOS.
Criando a tabela PRODUTOS
CREATE TABLE PRODUTOS(
id_produto INTEGER NOT NULL,
id_tipo_produto INTEGER,
nm_produto VARCHAR(30) NOT NULL,
ds_produto VARCHAR(50),
preco NUMERIC(5,2),
fg_ativo INTEGER,
PRIMARY KEY(ID_PRODUTO),
FOREIGN KEY (ID_TIPO_PRODUTO) 
 REFERENCES TIPOS_PRODUTOS(ID_TIPO_PRODUTO)
);
© Banco de Dados124
Veja que na Tabela 4 foram indicadas uma chave primária e uma chave estrangeira. A cha-
ve primária é uma chave primária simples, ou seja, composta por apenas um campo/atributo, 
ID_PRODUTO. O campo ID_TIPO_PRODUTO é a chave estrangeira, definida por meio da cláusula 
FOREIGN KEY.
Para especificar por qual tabela a chave estrangeira foi criada, utilizamos REFERENCES, 
permitindo que o SGBD aceite apenas valores pré-cadastrados no campo indicado da tabela 
referenciada.
A tabela FUNCIONARIOS será a quarta tabela a ser criada em nosso banco de dados. Essa 
tabela será responsável por armazenar dados referentes aos funcionários. Observe a estrutura 
utilizada para a tabela FUNCIONARIOS:
Tabela 5 Funcionários.
CAMPO TIPO DESCRIÇÃO
ID_FUNCIONARIO integer Identificador do funcionário (não nulo)
ID_GERENTE integer Identificador do gerente
NM_FUNCIONARIO varchar(10) Nome do funcionário (não nulo)
SOBRENOME_FUNCIONARIO varchar(10) Sobrenome do funcionário (não nulo)
CARGO varchar(20) Cargo do funcionário
SALARIO numeric(6,0) Salário do funcionário
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chave Primária Campo/Atributo ID_FUNCIONARIO
Novamente, escreva a sequência de instruções dentro da sessão SQL do banco de dados 
FACULDADE. Clique no botão/ícone Execute Query (F5) para efetivar a criação da tabela, como 
demonstrado na Figura 11. 
Figura 11 Tela de digitação do comando SQL no pgAdmin III / Criação da FUNCIONARIOS.
Claretiano - Centro Universitário
125© U4 – SQL – Uma Linguagem de Consulta
Criando a tabela FUNCIONARIOS
CREATE TABLE FUNCIONARIOS(
id_funcionario INTEGER,
id_gerente INTEGER,
nm_funcionario VARCHAR(10) NOT NULL,
sobrenome_funcionario VARCHAR(10) NOT NULL,
cargo VARCHAR(20),
salario NUMERIC(6,0),
fg_ativo INTEGER,
PRIMARY KEY(ID_FUNCIONARIO)
);
A quinta tabela a ser criada em nosso banco de dados armazenará dados referentes às 
compras efetuadas pelos clientes. Vamos identificar esta tabela como COMPRAS. A estrutura da 
tabela pode ser visualizada na Tabela 6.
Tabela 6 Compras.
CAMPO TIPO DESCRIÇÃO
ID_PRODUTO integer Identificador do produto (não nulo)
ID_CLIENTE integer Identificador do cliente (não nulo)
QUANTIDADE integer Representa a quantidade de produtos comprados
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chaves Primárias Campo/Atributo ID_PRODUTO e ID_CLIENTE
Chaves Estrangeiras Campo/Atributo ID_ PRODUTO e ID_CLIENTE
Em seguida, para criar a tabela definitivamente, insira as instruções dentro da sessão SQL 
do banco de dados FACULDADE. Clique no botão/ícone Execute Query (F5), como demonstrado 
na Figura 12. 
Figura 12 Tela de digitação do comando SQL no pgAdmin III / Criação da COMPRAS.
© Banco de Dados126
Criando a tabela COMPRAS
CREATE TABLE COMPRAS(
id_produto INTEGER,
id_cliente INTEGER,
quantidade INTEGER,
fg_ativo INTEGER,
FOREIGN KEY(ID_PRODUTO) REFERENCES PRODUTOS(ID_PRODUTO),
FOREIGN KEY(ID_CLIENTE) REFERENCES CLIENTES(ID_CLIENTE),
PRIMARY KEY(ID_PRODUTO, ID_CLIENTE)
);
Nessa tabela foi indicada uma chave primária composta (constituída por dois campos/
atributos), em que as mesmas também são chaves estrangeiras. A chave primária é uma chave 
composta pelos campos ID_PRODUTO e ID_CLIENTE. Os campos ID_PRODUTO e ID_CLIENTE são 
chaves estrangeiras, definidas pela cláusula FOREIGN KEY.
A palavra-chave REFERENCES é utilizada para indicar que uma referência (vínculo) foi cria-
da, fazendo com que o SGBD somente aceite valores previamente cadastrados no campo indi-
cado da tabela referenciada.
A tabela GRADES_SALARIOS é a sexta e última tabela pertinente ao nosso banco de dados 
FACULDADE. Essa tabela armazenará informação dos limites salariais mínimos e máximos. Ob-
serve, na Tabela 7, a estrutura da tabela GRADES_SALARIOS:
Tabela 7 Grades Salários.
CAMPO TIPO DESCRIÇÃO
ID_SALARIO integer Identificador do salário (não nulo)
SALARIO_MAXIMO number(6,0) Armazena valor máximo do salário
SALARIO_MINIMO number(6,0) Armazena valor mínimo do salário
FG_ATIVO integer Status do tipo do produto (ativo/inativo)
Chave Primária Campo/Atributo ID_SALARIO
Para finalizar a criação dos objetos (tabelas), escreva a sequência de instruções dentro 
da sessão SQL do banco de dados FACULDADE. Clique no botão/ícone Execute Query (F5) para 
consolidar a criação da tabela, como demonstrado na Figura 13. 
Figura 13 Tela de digitação do comando SQL no pgAdmin III / Criação da GRADES_SALARIOS.
Claretiano - Centro Universitário
127© U4 – SQL – Uma Linguagem de Consulta
Criando a tabela GRADES_SALARIOS
CREATE TABLE GRADES_SALARIOS(
id_salario INTEGER,
salario_maximo NUMERIC(6,0),
salario_minimo NUMERIC(6,0),
fg_ativo INTEGER,
PRIMARY KEY(ID_SALARIO)
);
Atente-se para as seguintes observações:
• Os campos que fazem parte da chave primária (PRIMARY KEY) não podem ficar vazios, 
então coloca-se NOT NULL em sua declaração. Talvez o SGBD faça isso automaticamen-
te para você.
• No final de cada linha do comando CREATE TABLE, coloca-se uma "," (vírgula).
• A chave estrangeira (FOREIGN KEY) não está escrita errada, é IGN e não ING.
Na unidade anterior, aprendemos a importância de utilizarmos de maneira adequada as 
regras de integridade de entidades e integridade referencial em um banco de dados relacional. 
Atualmente, a linguagem SQL dá suporte à implementação de ambas as regras. Um exemplo é 
a tabela FUNCIONARIOS, em que a regra de integridade é aplicada, automaticamente, quando 
criamos a chave primária PRIMARY KEY (ID_FUNCIONARIO). É possível identificarmos também, 
na tabela COMPRAS, a aplicação da integridade referencial por meio da criação das duas chaves 
estrangeiras: FOREIGN KEY(ID_CLIENTE) REFERENCES CLIENTES e FOREIGN KEY(ID_PRODUTO) 
REFERENCES PRODUTOS. 
Quando definimos uma restrição de chave estrangeira, estamos certificando que:
• Não é possível excluir um produto da respectiva tabela se pelo menos uma tupla da 
tabela COMPRAS referenciar esse produto.
• Entretanto, se uma alteração for realizada em produtos, essa alteração refletirá, auto-
maticamente, em qualquer referência desse atributo na tabela COMPRAS. Dessa ma-
neira, essa restrição impossibilita a existência de um valor para o campo ID_PRODUTO, 
na tabela COMPRAS, que aponte para um valor de ID_PRODUTO inexistente da tabela 
PRODUTOS.
A SQL ANSI dá suporte à utilização das cláusulas ON DELETE e ON UPDATE para cobrir as 
funções de CASCADE, SET NULL ou SET DEFAULT, garantindo, assim, a preservação da integrida-
de referencial.
Além da chave primária (PRIMARY KEY) e da chave estrangeira (FOREIGN KEY), podemos 
definir as seguintes restrições a partir do padrão ANSI, aplicadas sempre que uma tupla/linha for 
inserida, atualizada ou removida em uma determinada tabela:
• NOT NULL: certifica que valoresnulos não sejam aceitos para a coluna. Essa restrição 
pode ser especificada apenas para a coluna, não para a tabela.
• UNIQUE: garante exclusividade de valor a uma coluna ou a um conjunto de colunas. A 
restrição UNIQUE permite a entrada de valores nulos, exceto se você definir, simultane-
amente, a restrição NOT NULL.
• CHECK: determina uma condição que cada tupla/linha deverá satisfazer para efetiva-
mente ser inserida ou alterada.
© Banco de Dados128
Quando se cria uma tabela, o PostgreSQL, automaticamente, cria o índice para cada cha-
ve primária (PRIMARY KEY). Contudo, existem situações em que se faz necessária a criação de 
outro índice para que o SGBD possa realizar pesquisas no banco de dados mais rapidamente. É 
o caso, por exemplo, de quando se cria um índice para a coluna NM_FUNCIONARIO na tabela 
FUNCIONARIOS, pois, certamente, serão realizadas pesquisas pelo nome dos funcionários. Va-
mos explorar, em detalhes e em um tópico exclusivo, a criação e gerenciamento de índices em 
tabelas no PostgreSQL.
8. ESTRUTURA DA LINGUAGEM SQL – DML
A linguagem DML é a parte da linguagem SQL utilizada para manipular os dados em um 
banco de dados. A manipulação dos dados refere-se às quatro operações básicas possíveis: in-
serir novos dados, alterar dados existentes, pesquisar os dados existentes no banco de dados e 
apagar os dados. Os comandos responsáveis por essas quatro operações são, respectivamente: 
INSERT, UPDATE, SELECT e DELETE.
Inserir novos dados – INSERT
A instrução INSERT é responsável por inserir novas tuplas/linhas (registros) nas tabelas 
existentes no banco de dados. Sua sintaxe é bastante simples, como demonstrado a seguir:
 
INSERT INTO <TABELA> (CAMPO1, CAMPO2, …, CAMPOn 
VALUES (VALOR1, VALOR2, …, VALORn);
Cada valor informado no comando INSERT deve ser do mesmo tipo do campo respectivo, 
ou seja, se o primeiro campo do comando for do tipo integer, o primeiro valor deverá ser do tipo 
integer. Se o segundo campo for do tipo date, o segundo valor também deverá ser do tipo date 
e, assim, sucessivamente. Se essa regra não for obedecida, o SGBD emitirá uma mensagem de 
erro e não efetuará a inserção. Podemos tornar as operações permanentes usando a instrução 
COMMIT e/ou desfazê-las com a instrução ROLLBACK.
Após a exposição de alguns detalhes sobre a instrução INSERT, podemos adicionar algu-
mas tuplas/linhas para as tabelas CLIENTES, TIPOS_PRODUTOS, PRODUTOS, COMPRAS, FUN-
CIONARIOS e GRADES_SALARIOS . 
Exemplo:
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (1, 'João', 'Queiroz', '01-01-1965', '800-555-1211', 1);
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (2, 'Silvia', 'Mendes', '05-02-1968', '800-555-1212', 1);
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (3, 'Marcelo', 'Ribeiro', '16-03-1971', '800-555-1213', 1);
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (4, 'Henrique', 'Figueira', NULL, '800-555-1214', 1);
Claretiano - Centro Universitário
129© U4 – SQL – Uma Linguagem de Consulta
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (5, 'Dolores', 'Silva', '20-05-1970', NULL, 1);
INSERT INTO CLIENTES (ID_CLIENTE, NM_CLIENTE, SOBRENOME, DT_NASCIMENTO, 
TELEFONE, FG_ATIVO)
VALUES (6, 'Frederico', 'Vaz', '01-01-1970', '800-555-1215', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)
VALUES (1, 'Livro', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)
VALUES (2, 'Vídeo', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)
VALUES (3, 'DVD', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)
VALUES (4, 'CD', 1);
INSERT INTO TIPOS_PRODUTOS (ID_TIPO_PRODUTO, DS_TIPO_PRODUTO, FG_ATIVO)
VALUES (5, 'Revista', 1);
INSERT INTO PRODUTOS(ID_PRODUTO, ID_TIPO_PRODUTO, NM_PRODUTO, DS_
PRODUTO, PRECO, FG_ATIVO)
VALUES (1, 1, 'Ciência Moderna', 'Uma descrição da ciência moderna', 
19.95, 1);
INSERT INTO PRODUTOS(ID_PRODUTO, ID_TIPO_PRODUTO, NM_PRODUTO, DS_
PRODUTO, PRECO, FG_ATIVO)
VALUES (2, 1, 'Química', 'Introdução à Química', 30, 1);
INSERT INTO PRODUTOS(ID_PRODUTO, ID_TIPO_PRODUTO, NM_PRODUTO, DS_
PRODUTO, PRECO, FG_ATIVO)
VALUES (3, 2, 'Supernova', 'Uma estrela explosiva', 25.99, 1);
INSERT INTO PRODUTOS(ID_PRODUTO, ID_TIPO_PRODUTO, NM_PRODUTO, DS_
PRODUTO, PRECO, FG_ATIVO)
VALUES (4, 2, 'Tanque de Guerra', 'Filme de ação sobre uma possível 
guerra', 13.95,1 );
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)
VALUES (1, 1, 1, 1);
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)
VALUES (2, 1, 3, 1);
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)
VALUES (1, 4, 1, 1);
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)
VALUES (2, 2, 1, 1);
INSERT INTO COMPRAS (ID_CLIENTE, ID_PRODUTO, QUANTIDADE, FG_ATIVO)
VALUES (1, 3, 1, 1);
INSERT INTO FUNCIONARIOS (ID_FUNCIONARIO, ID_GERENTE, NM_FUNCIONARIO, 
SOBRENOME_FUNCIONARIO, CARGO, SALARIO, FG_ATIVO)
VALUES (1, NULL, 'Jaime', 'Tenório', 'Diretor Executivo', 800000, 1);
© Banco de Dados130
INSERT INTO FUNCIONARIOS (ID_FUNCIONARIO, ID_GERENTE, NM_FUNCIONARIO, 
SOBRENOME_FUNCIONARIO, CARGO, SALARIO, FG_ATIVO)
VALUES (2, 1, 'Rubens', 'Cardoso', 'Gerente de Vendas', 600000, 1);
INSERT INTO FUNCIONARIOS (ID_FUNCIONARIO, ID_GERENTE, NM_FUNCIONARIO, 
SOBRENOME_FUNCIONARIO, CARGO, SALARIO, FG_ATIVO)
VALUES (3, 2, 'Frederico', 'Munhoz', 'Vendedor', 150000,1 );
INSERT INTO FUNCIONARIOS (ID_FUNCIONARIO, ID_GERENTE, NM_FUNCIONARIO, 
SOBRENOME_FUNCIONARIO, CARGO, SALARIO, FG_ATIVO)
VALUES (4, 2, 'Susana', 'Coimbra', 'Vendedor', 500000,1 );
INSERT INTO GRADES_SALARIOS (ID_SALARIO, SALARIO_MINIMO, SALARIO_MAXIMO, 
FG_ATIVO) 
VALUES (1, 1, 25000, 1);
INSERT INTO GRADES_SALARIOS (ID_SALARIO, SALARIO_MINIMO, SALARIO_MAXIMO, 
FG_ATIVO) 
VALUES (2, 250001, 500000, 1);
INSERT INTO GRADES_SALARIOS (ID_SALARIO, SALARIO_MINIMO, SALARIO_MAXIMO, 
FG_ATIVO) 
VALUES (3, 500001, 750000, 1);
INSERT INTO GRADES_SALARIOS (ID_SALARIO, SALARIO_MINIMO, SALARIO_MAXIMO, 
FG_ATIVO) 
VALUES (4, 750001, 999999, 1);
Talvez você tenha achado estranho o campo/atributo DT_NASCIMENTO, existente na ta-
bela CLIENTES, receber uma data em um formato não convencional e entre aspas, como se fosse 
um texto. A explicação é simples: quando criamos a tabela CLIENTES, definimos o campo/atribu-
to DT_NASCIMENTO com o tipo timestamp, que armazena datas no formato DD-MM-AAAA, ou 
seja, ano com quatro dígitos, mês e dia do mês com dois dígitos. Quanto às aspas, o PostgreSQL 
converte, automaticamente, o texto, que está no formato de data e hora, para uma data. Deste 
modo, sempre que precisar inserir uma data, coloque como instrução um texto, seguindo o 
formato de data especificado, de acordo com o tipo de dado utilizado na construção da tabela.
Modificar registros (Alterar dados existentes) – UPDATE
A instrução UPDATE é utilizada para alterar tuplas/linhas existentes em tabelas do banco 
de dados. É fundamental que você não altere os valores de campos que façam parte da chave 
primária, pois erros graves de inconsistência podem ocorrer. Em uma instrução UPDATE, pode-
mos especificar as seguintes informações:
• A tabela que contém as tuplas/linhas a serem alteradas.
• Uma cláusula WHERE, especificando as tuplas/linhas a serem alteradas.
• Uma lista de nomes de colunas, junto com seus novos valores, especificado com a cláu-
sula SET, conforme podemos identificar na sintaxe a seguir: 
Sintaxe
UPDATE <TABELA> SET
 CAMPO1 = VALOR1,
 CAMPO2 = VALOR2,
 (...)
 CAMPOn = VALORn
WHERE <CONDIÇÃO LÓGICA>
Claretiano - Centro Universitário
131© U4 – SQL – Uma Linguagem de Consulta
Como exemplo, atualizaremos o sobrenome do cliente cujo ID_CLIENTE corresponde ao Nú-
mero 2 para "Queiroz". Cuidado para não seesquecer de adicionar a cláusula WHERE, senão todas 
as tuplas/linhas serão atualizadas. Caso uma alteração indesejada ocorra, ROLLBACK poderá ser acio-
nado para desfazer as alterações feitas nas tuplas/linhas (se você estiver utilizando uma transação).
Tabela 8 Identificação Clientes
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Mendes 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Exemplo:
UPDATE CLIENTES
 SET SOBRENOME = 'Queiroz'
WHERE ID_CLIENTE = 2;
Pesquisar dados existentes – SELECT 
SELECT é uma instrução utilizada para recuperar informações das tabelas do banco de 
dados. Em sua forma mais simples, são especificadas a tabela e as colunas (atributos) das quais 
se deseja extrair informação.
Para exemplificar o uso da instrução SELECT, serão recuperada as colunas ID_CLIENTE, 
NM_CLIENTE, SOBRENOME, DT_NASCIMENTO e TELEFONE da tabela CLIENTES.
SELECT id_cliente, 
 nm_cliente, 
 sobrenome, 
 dt_nascimento, 
 telefone
FROM clientes;
A seguir, podemos visualizar as tuplas/linhas resultantes da consulta (SELECT) realizada. 
Independentemente do número de colunas (atributos) existentes na tabela CLIENTES, solicita-
mos apenas, em nossa consulta, os valores correspondentes às colunas ID_CLIENTE, NM_CLIEN-
TE, SOBRENOME, DT_NASCIMENTO e TELEFONE.
Tabela 9 Tabela I da consulta SELECT.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE
1 João Queiroz 01/01/1965 00:00 800-555-1211
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213
4 Henrique Figueira 800-555-1214
5 Dolores Silva 20/05/1970 00:00
6 Frederico Vaz 01/01/1970 00:00 800-555-1215
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212
© Banco de Dados132
Outra possibilidade de utilização da instrução SELECT diz respeito à recuperação de todas 
as colunas (atributos) de uma determinada tabela. 
Utilizando o caractere especial asterisco (*), podemos, por exemplo, recuperar todas as 
colunas (atributos) da tabela CLIENTES.
SELECT *
FROM clientes;
Tabela 10 Tabela II da consulta SELECT.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Ainda é permitido, utilizando a instrução SELECT, especificar as tuplas/linhas a serem re-
cuperadas por meio da cláusula WHERE. Mesmo que o SGBD PostgreSQL possua a capacidade 
de armazenamento de uma grande quantidade de tuplas/linhas em uma tabela (*), talvez você 
esteja interessado apenas em um subconjunto muito pequeno de tuplas/linhas.
Para exemplificar a mesclagem da instrução SELECT com a cláusula WHERE, utilizaremos 
a cláusula WHERE para recuperar a tupla/linha da tabela CLIENTES, em que a coluna (atributo) 
ID_CLIENTE seja equivalente ao Número 2.
SELECT *
FROM clientes
WHERE id_cliente = 2;
Tabela 11 Tabela da consulta SELECT e WHERE.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Apagar registro – DELETE 
A instrução DELETE é responsável por remover as tuplas/linhas de uma determinada tabe-
la no banco de dados. A cláusula WHERE possui função semelhante à instrução UPDATE, isto é, 
limita as tuplas/linhas que se deseja excluir (caso contrário, todas as tuplas/linhas serão excluí-
das da tabela). Sua sintaxe é muito simples, conforme mostrado a seguir:
DELETE FROM <TABELA> 
WHERE <CONDIÇÃO LÓGICA>
Vamos remover o cliente armazenado na tabela CLIENTES, em que o identificador do clien-
te (ID_CLIENTE) corresponda ao Número 3. Não se esqueça de incluir a cláusula WHERE, senão 
todas as tuplas/linhas serão removidas de sua tabela. 
Claretiano - Centro Universitário
133© U4 – SQL – Uma Linguagem de Consulta
Tabela 12 Tabela da consulta DELETE e WHERE.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Mendes 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Exemplo:
DELETE 
FROM clientes
WHERE id_cliente = 3;
Observe que serão removidos todos os registros (tuplas/linhas) cujo resultado da condi-
ção lógica for verdadeiro (cláusula WHERE).
Cálculos Aritméticos
A maioria dos SGBDs permite a realização de cálculos em instruções SQL usando expres-
sões aritméticas, as quais consistem em dois operandos (números ou datas) e um operador 
aritmético.
Os quatro operadores aritméticos são:
Quadro 2 Operadores Aritméticos.
OPERADOR DESCRIÇÃO
+ Adição
- Subtração
* Multiplicação
/ Divisão
Nos exemplos a seguir, você verá a instrução proposta e, logo após, o resultado da execução.
Como primeiro exemplo do uso de cálculos em instruções SQL, utilizaremos o operador 
de multiplicação (*) para calcular 2 multiplicado por 6. Os números 2 e 6 são os operandos. 
Observe:
SELECT 2 * 6;
?column?
12
As regras normais de precedência de operador aritmético se aplicam na linguagem SQL. 
Multiplicação e divisão são efetuadas primeiro, seguidas pela adição e subtração.
Por exemplo, a expressão 10 * 12 / 3 – 1 é executada usando a instrução SELECT.
SELECT 10 * 12 / 3 - 1;
© Banco de Dados134
?column?
39
É possível utilizarmos parênteses () para especificar a ordem de execução dos operadores. 
No exemplo a seguir, os parênteses são usados para efetuar primeiro o cálculo de 12 / 3 – 1, cujo 
resultado será, então, multiplicado por 10.
SELECT 10 * (12 / 3 - 1);
?column?
30
Além dos cálculos aritméticos efetuados nos exemplos anteriores, é permitido utilizar 
operadores de adição e subtração com datas, como adicionar um número, representando um 
determinado número de dias a uma data.
Para exemplificar, somaremos dois dias a 25 de julho de 2011, exibindo a data resultante:
SELECT DATE('25-JUL-2011') + 2;
?column?
27/07/2011
Nesse outro exemplo, subtrairemos três dias de 02 de agosto de 2011.
SELECT DATE('02/08/2011') - 3;
?column?
30/07/2011
Agora, subtrairemos uma data de outra, produzindo o número de dias entre elas. Para 
isso, subtrairemos 01 de janeiro de 2011 de 31 de maio de 2011.
SELECT DATE('31/05/2011') - DATE('01/01/2011');
?column?
150
É possível também utilizar valores armazenados em colunas na realização dos cálculos 
aritméticos. Ou seja, os operandos não precisam ser números literais ou datas; podem ser ope-
randos extraídos de colunas de uma determinada tabela.
Como exemplo, utilizaremos as colunas NM_PRODUTO e PRECO recuperadas da tabela 
PRODUTOS, em que serão acrescidos R$ 2,00 aos valores pertinentes à coluna PRECO:
SELECT nm_produto,
 preco + 2.00
FROM produtos;
Claretiano - Centro Universitário
135© U4 – SQL – Uma Linguagem de Consulta
nm_produto ?column?
Ciência Moderna 21.95
Química 32.00
Supernova 27.99
Tanque de Guerra 15.95
Como segundo exemplo, combinaremos mais de um operador em uma expressão. Os va-
lores correspondentes à coluna PRECO serão multiplicados por 3 e, então, 1 é somado ao valor 
resultante:
SELECT nm_produto,
 preco * 3 + 1
FROM produtos;
nm_produto ?column?
Ciência Moderna 60.85
Química 91.00
Supernova 78.97
Tanque de Guerra 42.85
Usando apelidos (alias) de coluna
Não estamos limitados a usar o cabeçalho padrão gerado pelos SGBDs. É possível fornecer 
o seu próprio cabeçalho, usando um apelido (alias). No exemplo a seguir, a expressão PRECO * 
2.00 recebe o apelido DOBRO_PREÇO. Veja:
SELECT nm_produto,
 preco,
 preco * 2 DOBRO_PREÇO
FROM produtos;
nm_produto preco dobro_preço
Ciência Moderna 19.95 39.90
Química 30.00 60.00
Supernova 25.99 51.98
Tanque de Guerra 13.95 27.90Para preservar a caixa do texto (maiúsculo e minúsculo) e usar espaços em nomes com-
postos do seu nome alternativo (apelido), basta envolvê-lo entre aspas duplas, conforme o 
exemplo a seguir:
SELECT nm_produto,
 preco,
 preco * 2 "DoBrO dO PrEço"
FROM produtos;
nm_produto preco DoBrO dO PrEço
Ciência Moderna 19.95 39.90
Química 30.00 60.00
© Banco de Dados136
nm_produto preco DoBrO dO PrEço
Supernova 25.99 51.98
Tanque de Guerra 13.95 27.90
A palavra-chave AS antes do nome alternativo (apelido) é opcional, conforme podemos 
visualizar no exemplo a seguir:
SELECT 10 * (12 / 3 - 1) AS "Resultado da Expressão";
Resultado da Expressão
30
Concatenação entre Colunas
A concatenação permite combinarmos os valores de colunas, criando, assim, uma saída 
mais amigável. O operador utilizado para realizar a concatenação entre colunas é o pipe duplo 
||. Na tabela CLIENTES, as colunas NM_CLIENTE e SOBRENOME contêm o nome do cliente. Não 
seria ideal combinar as duas colunas a fim de apresentar o nome completo do cliente? O exem-
plo a seguir demonstra essa facilidade, explorando juntamente o uso de um nome alternativo 
para a coluna resultante:
SELECT nm_cliente || ' ' || sobrenome AS "Nome completo dos Clientes"
FROM clientes;
Nome completo dos Clientes
João Queiroz
Marcelo Ribeiro
Henrique Figueira
Dolores Silva
Frederico Vaz
Silvia Queiroz
Valores Nulos
Como podemos identificar um valor desconhecido (valor nulo) no banco de dados? Um 
valor nulo não é uma string em branco, e sim um valor único cujo significado do valor da coluna 
é desconhecido. Observe o exemplo a seguir: o cliente correspondente ao Número 4 tem um 
valor nulo na coluna DT_NASCIMENTO, e o cliente identificado com o Número 5 tem um valor 
nulo na coluna TELEFONE. Vamos consultar novamente a tabela CLIENTES para constatar essa 
afirmativa:
SELECT *
FROM clientes;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
Claretiano - Centro Universitário
137© U4 – SQL – Uma Linguagem de Consulta
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
Para verificar a existência de valores nulos, utilizamos IS NULL. Na instrução SELECT, a se-
guir, o cliente correspondente ao Número 4 é recuperado, pois seu valor da DT_NASCIMENTO é 
um valor nulo:
SELECT id_cliente,
 nm_cliente,
 sobrenome,
 dt_nascimento
FROM clientes
WHERE dt_nascimento IS NULL;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO
4 Henrique Figueira
Em outro exemplo, o cliente cujo número equivale a 5 é recuperado, pois seu valor perti-
nente à coluna TELEFONE também corresponde a um valor nulo:
SELECT id_cliente,
 nm_cliente,
 sobrenome,
 telefone
FROM clientes
WHERE telefone IS NULL;
ID_CLIENTE NM_CLIENTE SOBRENOME TELEFONE
5 Dolores Silva
Exibindo tuplas/linhas distintas
Antes de qualquer coisa, listaremos os clientes que efetuaram compras em nossa loja vir-
tual, constituída a partir do esquema (database) identificado de FACULDADE, exibindo apenas a 
coluna ID_CLIENTE da tabela COMPRAS.
SELECT id_cliente
FROM compras;
ID_CLIENTE
1
2
1
2
1
É possível identificar que alguns clientes fizeram mais de uma compra e, portanto, apare-
cem duplicados.
© Banco de Dados138
Como eliminar as tuplas/linhas duplicadas que contêm a mesma identificação? DISTINCT 
é utilizado para suprimir as tuplas/linhas duplicadas. Para exemplificar a utilização do DISTINCT, 
repetiremos a consulta anterior; porém, agora, incluiremos o comando DISTINCT.
SELECT DISTINCT id_cliente
FROM compras;
ID_CLIENTE
1
2
Comparando Valores
Para explorarmos o uso dos operadores de comparação, citaremos os mais usuais no Qua-
dro 3:
Quadro 3 Operadores de Comparação.
OPERADOR DESCRIÇÃO
= Igual
<> ou != Diferente
< Menor que
> Maior que
<= Menor ou igual a
>= Maior ou igual a
ANY Compara um valor com qualquer valor em uma lista
SOME Idêntico ao operador ANY (você deve usar ANY "mais legível")
ALL Compara um valor com todos os valores em uma lista
Como primeiro exemplo, podemos recuperar as tuplas/linhas da tabela CLIENTES, cujo 
valor correspondente à coluna ID_CLIENTE seja diferente do número 2. Observe:
SELECT *
FROM clientes
WHERE id_cliente <> 2;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Outro exemplo é recuperarmos as colunas ID_PRODUTO e NM_PRODUTO da tabela PRO-
DUTOS, em que o valor correspondente à coluna ID_PRODUTO seja maior do que o Número 2.
SELECT id_produto, nm_produto
FROM produtos
WHERE id_produto > 2;
Claretiano - Centro Universitário
139© U4 – SQL – Uma Linguagem de Consulta
ID_PRODUTO NM_PRODUTO
3 Supernova
4 Tanque de Guerra
No próximo exemplo, o operador <= (menor ou igual a) é utilizado para recuperar os pro-
dutos da tabela PRODUTOS, cujos valores pertinentes à coluna ID_PRODUTO sejam <= (menor 
ou igual a) ao Número 3.
SELECT id_produto, nm_produto
FROM produtos
WHERE id_produto <= 3;
ID_PRODUTO NM_PRODUTO
1 Ciência Moderna
2 Química
3 Supernova
Agora, o operador ANY será utilizado em uma cláusula WHERE para comparar um valor 
com qualquer um dos valores de uma lista. Como pré-requisito, devemos inserir um operador, 
=, <>, <, >, <= ou >=, antes de ANY. Veja como recuperar as tuplas/linhas da tabela CLIENTES, 
onde os valores correspondentes à coluna ID_CLIENTE sejam maiores do que qualquer um dos 
valores 2, 3 ou 4:
SELECT *
FROM clientes
WHERE id_cliente > ANY (SELECT id_cliente
 FROM clientes
 WHERE id_cliente = 2
 OR id_cliente = 3
 OR id_cliente = 4);
Usamos uma subconsulta (subquery) para recuperar a lista de valores pertinentes aos 
identificadores dos clientes.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
O operador ALL é utilizado na cláusula WHERE para comparar um determinado valor com 
todos os valores de uma lista. Semelhante ao ANY, é necessário inserir um operador (=, <>, <, >, 
<= ou >=) antes do ALL. Recuperaremos as tuplas/linhas da tabela CLIENTES, onde o valor asso-
ciado à coluna ID_CLIENTE seja maior do que os valores 2, 3 ou 4:
SELECT *
FROM clientes
WHERE id_cliente > ALL (SELECT id_cliente
 FROM clientes
 WHERE id_cliente = 2
 OR id_cliente = 3
 OR id_cliente = 4);
© Banco de Dados140
Idêntico ao exemplo anterior, lançamos uso de uma subconsulta (subquery) a fim de re-
cuperar uma lista de valores, os quais serão utilizados para comparar os identificadores dos 
clientes.
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Usando os Operadores SQL
Ao utilizarmos os operadores SQL, temos a possibilidade de limitar as tuplas/linhas com 
base na correspondência de padrão de strings, listas de valores, intervalos de valores e até mes-
mo valores nulos. A seguir, detalhamos alguns dos operadores SQL mais utilizados:
Quadro 4 Operadores SQL.
OPERADOR DESCRIÇÃO
LIKE Corresponde a padrões em strings
IN Corresponde a listas de valores
BETWEEN Corresponde a um intervalo de valores
IS NULL Corresponde a valores nulos
Existe também a possibilidade de utilizarmos NOT para inverter o significado de um deter-
minado operador, por exemplo: NOT LIKE, NOTIN, NOT BETWEEN e IS NOT NULL.
O uso do operador LIKE em uma cláusula WHERE é implementado para procurar um pa-
drão em uma string. Os padrões são especificados mediante a combinação de caracteres nor-
mais e os dois caracteres considerados curingas:
• Sublinhado ( _ ): corresponde a um caractere em uma posição específica.
• Porcentagem ( % ): corresponde a qualquer número de caracteres a partir da posição 
especificada.
Exemplo de uso do padrão: 
'_o%'
De acordo com o exemplo:
• O sublinhado corresponde a qualquer caractere na primeira posição.
• O o corresponde a um caractere o, na segunda posição.
• Porcentagem corresponde a todos os caracteres após o caractere o.
Para exemplificar o uso do operador LIKE, procuraremos o padrão '_o%' na coluna NM_
CLIENTE, da tabela CLIENTES:
SELECT *
FROM clientes
WHERE nm_cliente LIKE '_o%';
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
5 Dolores Silva 20/05/1970 00:00 1
Claretiano - Centro Universitário
141© U4 – SQL – Uma Linguagem de Consulta
Se, eventualmente, for necessário procurar os caracteres de sublinhado ou porcentagem 
reais em uma string, devemos utilizar a opção ESCAPE para identificá-los.
Exemplo: 
%\\%%
O caractere de escape (barra invertida) diz ao banco de dados como diferenciar os ca-
racteres a serem pesquisados dos caracteres curingas. O primeiro caractere % é tratado como 
curinga, correspondendo a qualquer número de caracteres; o segundo % é tratado como um 
caractere real a ser procurado; e, por fim, o terceiro caractere % é tratado como curinga, corres-
pondendo a qualquer número de caracteres.
Antes mesmo de aplicarmos um exemplo pertinente ao uso do caractere de escape, cria-
remos uma nova tabela em nosso banco de dados e, na sequência, serão inseridos alguns regis-
tros para essa tabela. Observe:
CREATE TABLE promocao(
id_promocao INTEGER,
nome VARCHAR NOT NULL,
duracao VARCHAR,
PRIMARY KEY(id_promocao)); 
INSERT INTO promocao(id_promocao, nome, duracao)
VALUES
(1, '10%', '9 dias'),
(2, '15%', '8 dias'),
(3, '20%', '7 dias'),
(4, '25%', '6 dias'),
(5, '30%', '5 dias'),
(6, '35%', '4 dias'),
(7, '40%', '3 dias'),
(8, '45%', '2 dias'),
(9, '50%', '1 dia');
Agora, com a estrutura pronta, podemos utilizar o caractere de escape para procurar o 
padrão '%\\%%' na coluna NOME, da tabela PROMOCAO:
SELECT *
FROM promocao
WHERE nome LIKE '%\\%%';
ID_PROMOCAO NOME DURACAO
1 10% 9 dias
2 15% 8 dias
3 20% 7 dias
4 25% 6 dias
5 30% 5 dias
6 35% 4 dias
7 40% 3 dias
8 45% 2 dias
9 50% 1 dia
© Banco de Dados142
Para recuperar tuplas/linhas cujo valor da coluna esteja em uma lista de valores, utiliza-
mos o operador IN em uma cláusula WHERE. Por exemplo, podemos recuperar as tuplas/linhas 
da tabela CLIENTES, em que os valores associados à coluna ID_CLIENTE corresponda aos Núme-
ros 2, 3 ou 5:
SELECT *
FROM clientes
WHERE id_cliente IN (2, 3, 5);
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
O operador NOT permite-nos inverter a consulta, ou seja, usando o NOT IN recuperamos 
as tuplas/linhas não recuperadas por IN, no exemplo anterior:
SELECT *
FROM clientes
WHERE id_cliente NOT IN (2, 3, 5);
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
4 Henrique Figueira 800-555-1214 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Devemos observar que NOT IN retornará falso se o valor que estiver na lista for nulo. O 
próximo exemplo não recupera nenhuma tupla/linha, pois o valor nulo está incluído na lista:
SELECT *
FROM clientes
WHERE id_cliente NOT IN (2, 3, 5, NULL);
O operador BETWEEN também é utilizado em uma cláusula WHERE, cujo objetivo é recu-
perar as tuplas/linhas onde o valor vinculado à coluna encontra-se em um determinado inter-
valo. O intervalo inclui valores das duas extremidades. Para exemplificar o uso do operador BE-
TWEEN, recuperaremos as tuplas/linhas da tabela CLIENTES, onde valores da coluna ID_CLIENTE 
estejam entre o intervalo de 1 a 3:
SELECT *
FROM clientes
WHERE id_cliente BETWEEN 1 AND 3;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
Similar ao operador IN, o BETWEEN também permite realizar a forma negativa, ou seja, re-
cuperar as tuplas/linhas não recuperadas no exemplo anterior, por meio do uso de NOT BETWEEN.
Claretiano - Centro Universitário
143© U4 – SQL – Uma Linguagem de Consulta
SELECT *
FROM clientes
WHERE id_cliente NOT BETWEEN 1 AND 3;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
Os operadores lógicos permitem limitar as tuplas/linhas com base em condições lógicas. 
O Quadro 5 descreve os principais operadores lógicos.
Quadro 5 Operadores Lógicos.
OPERADOR DESCRIÇÃO
x AND y Retorna verdadeiro quando x e y são verdadeiros
x OR y Retorna verdadeiro quando x ou y são verdadeiros
NOT x Retorna verdadeiro se x for falso e retorna falso se x for verdadeiro
Como exemplo de uso do operador AND, recuperaremos as tuplas/linhas da tabela CLIEN-
TES, onde as duas condições são verdadeiras:
• 1ª condição: valores da coluna DT_NASCIMENTO maior que 1º de janeiro de 1970.
• 2ª condição: valores da coluna ID_CLIENTE maior do que 3.
SELECT *
FROM clientes
WHERE dt_nascimento > '01/01/1970'
AND id_cliente > 3;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
5 Dolores Silva 20/05/1970 00:00 1
Para exemplificar o uso do operador OR, nossa próxima consulta recuperará as tuplas/
linhas da tabela CLIENTES, onde uma das duas condições é verdadeira:
• 1ª condição: valores da coluna DT_NASCIMENTO maior que 1º de janeiro de 1970.
• 2ª condição: valores da coluna ID_CLIENTE maior do que 3.
SELECT *
FROM clientes
WHERE dt_nascimento > '01/01/1970'
OR id_cliente > 3;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
4 Henrique Figueira 800-555-1214 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
© Banco de Dados144
Quando você for utilizar os dois operadores, ou seja, mesclar AND e OR em uma mesma 
expressão, AND terá precedência sobre OR (no caso, ter precedência significa ser executado 
primeiro). Operadores de comparação terão precedência sobre AND. Caso deseje anular essa 
precedência, faça uso de parênteses, o qual indicará a ordem de execução das expressões. A fim 
de demonstrar o uso da mesclagem de operadores, o exemplo a seguir recupera as tuplas/linhas 
da tabela CLIENTES, onde uma das três condições é verdadeira:
• 1ª condição: valores da coluna DT_NASCIMENTO maior que 1º de janeiro de 1970.
• 2ª condição: valores da coluna ID_CLIENTE menor que 2.
• 3ª condição: valores da coluna TELEFONE deverão possuir o número 1211 no final.
SELECT *
FROM clientes
WHERE dt_nascimento > '01/01/1970'
OR id_cliente < 2
AND telefone LIKE '%1211';
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
A cláusula ORDER BY
A cláusula ORDER BY é usada para classificar as tuplas/linhas recuperadas por uma consul-
ta. Pode especificar uma ou mais colunas nas quais os dados serão classificados.
Em nosso primeiro exemplo, usaremos a cláusula ORDER BY para classificar por SOBRENO-
ME as tuplas/linhas recuperadas da tabela CLIENTES:
SELECT *
FROM clientes
ORDER BY sobrenome;
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
4 Henrique Figueira 800-555-1214 1
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
2 Silvia Queiroz05/02/1968 00:00 800-555-1212 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
A palavra-chave DESC pode ser utilizada para classificar as colunas em ordem decrescente, e 
a palavra-chave ASC para especificar, explicitamente, uma classificação crescente (padrão/default). 
No segundo exemplo, a cláusula ORDER BY é utilizada para classificar as tuplas/linhas re-
cuperadas da tabela CLIENTES por NM_CLIENTE em ordem crescente e SOBRENOME em ordem 
decrescente:
SELECT *
FROM clientes
ORDER BY nm_cliente ASC, sobrenome DESC;
Claretiano - Centro Universitário
145© U4 – SQL – Uma Linguagem de Consulta
ID_CLIENTE NM_CLIENTE SOBRENOME DT_NASCIMENTO TELEFONE FG_ATIVO
5 Dolores Silva 20/05/1970 00:00 1
6 Frederico Vaz 01/01/1970 00:00 800-555-1215 1
4 Henrique Figueira 800-555-1214 1
1 João Queiroz 01/01/1965 00:00 800-555-1211 1
3 Marcelo Ribeiro 16/03/1971 00:00 800-555-1213 1
2 Silvia Queiroz 05/02/1968 00:00 800-555-1212 1
O número da posição de coluna na cláusula ORDER BY pode ser utilizado para indicar qual 
coluna deve ser classificada. Utilize 1 para classificar pela primeira coluna, 2 para classificar pela 
segunda coluna, e assim sucessivamente. Para exemplificar o uso do ORDER BY posicional, a co-
luna ID_CLIENTE, que em nosso caso corresponde à primeira coluna (1), é usada para classificar 
as tuplas/linhas recuperadas da tabela CLIENTES:
SELECT id_cliente, nm_cliente, sobrenome
FROM clientes
ORDER BY 1;
ID_CLIENTE NM_CLIENTE SOBRENOME
1 João Queiroz
2 Silvia Queiroz
3 Marcelo Ribeiro
4 Henrique Figueira
5 Dolores Silva
6 Frederico Vaz
Junção (Join)
Quando trabalhamos em um banco de dados normalizado, é comum manipularmos in-
formações armazenadas em diversas tabelas simultaneamente. Como exemplo, podemos citar 
a necessidade de obter o nome do produto e o nome do tipo de produto. As tabelas PRODU-
TOS e TIPOS_PRODUTOS são relacionadas entre si por meio da coluna de chave estrangeira 
ID_TIPO_PRODUTO. A coluna ID_TIPO_PRODUTO (chave estrangeira – foreign key) da tabela 
PRODUTOS aponta para a coluna ID_TIPO_PRODUTO (chave primária – primary key) da tabela 
TIPOS_PRODUTOS.
Para ilustrar melhor a necessidade de realizar uma junção entre tabelas, segmentaremos 
as informações que necessitamos, recuperando nessa instrução SELECT apenas as colunas NM_
PRODUTO e ID_TIPO_PRODUTO da tabela PRODUTOS para o produto cujo identificador corres-
ponda ao Número 3:
SELECT nm_produto, id_tipo_produto
FROM produtos
WHERE id_produto = 3;
NM_PRODUTO ID_TIPO_PRODUTO
Supernova 2
Na sequência, recuperaremos a coluna DS_TIPO_PRODUTO da tabela TIPOS_PRODUTOS 
para o ID_TIPO_PRODUTO equivalente ao Número 2. Observe:
© Banco de Dados146
SELECT ds_tipo_produto
FROM tipos_produtos
WHERE id_tipo_produto = 2;
DS_TIPO_PRODUTO
Vídeo
Agora que você entendeu a necessidade de realizar a junção de duas tabelas (PRODUTOS 
e TIPOS_PRODUTOS), já estamos prontos para recuperar o nome do produto e a descrição do 
tipo de produto usando apenas uma consulta, por meio de uma junção (JOIN). É simples: basta 
incluirmos as duas tabelas na cláusula FROM da consulta e incluir as colunas relacionadas de 
cada tabela na cláusula WHERE.
Exemplo:
FROM produtos, tipos_produtos
E na cláusula WHERE:
WHERE produtos.id_tipo_produto = tipos_produtos.id_tipo_produto
AND produtos.id_produto = 3;
A instrução SELECT da consulta:
SELECT produtos.nm_produto, tipos_produtos.ds_tipo_produto
No exemplo, podemos visualizar que a junção (JOIN) é a primeira condição da cláusula 
WHERE (produtos.id_tipo_produto = tipos_produtos.id_tipo_produto). Normalmente, as duas 
colunas na junção (JOIN) são chave primária (primary key) de uma tabela e uma chave estran-
geira (foreign key) de outra tabela.
Como o operador de igualdade (=) é utilizado na condição de junção (JOIN), esta junção é 
nomeada de EQUIJOIN. 
No exemplo, existe uma coluna ID_TIPO_PRODUTO na tabela PRODUTOS e outra na tabela 
TIPOS_PRODUTOS. Dessa forma, é necessário informar ao banco de dados em qual tabela está 
a coluna que se deseja utilizar. Se as colunas tivessem nomes distintos, não seria necessário in-
formar os nomes das tabelas em questão.
Como dica, aconselhamos que você inclua sempre os nomes das tabelas para tornar claro 
de onde originam as colunas. Para finalizar nosso exemplo, incluímos todos os fragmentos an-
teriores em uma única consulta, evidenciando o uso de junção em uma instrução SELECT. Veja:
SELECT produtos.nm_produto, 
 tipos_produtos.ds_tipo_produto
FROM produtos, tipos_produtos
WHERE produtos.id_tipo_produto = tipos_produtos.id_tipo_produto
AND produtos.id_produto = 3; 
NM_PRODUTO DS_TIPO_PRODUTO
Supernova Vídeo
Claretiano - Centro Universitário
147© U4 – SQL – Uma Linguagem de Consulta
Para darmos prosseguimento aos nossos exemplos de junção entre tabelas, será necessá-
rio incluirmos mais registros na tabela PRODUTOS, conforme as instruções INSERT. Veja a seguir:
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (6, 2, 'Arquivos Z', 'Série sobre atividades misteriosas', 49.99, 
1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (7, 2, '2412: O Retorno', 'Alien O Retorno', 14.95, 1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo)
VALUES (8, 3, 'Força G', 'Aventuras dos heróis', 13.49, 1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (9, 3, 'De outro planeta', 'Alienígena de outro planeta na 
Terra', 12.99, 1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo)
VALUES (10, 4, 'Música clássica', 'O melhor da música clássica', 10.99, 
1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (11, 4, 'Pop 3', 'O melhor da música popular', 15.99, 1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (12, 4, 'Yell criativo', 'Álbum de estréia', 14.99, 1);
INSERT INTO produtos (id_produto, id_tipo_produto, nm_produto, 
ds_produto, preco, fg_ativo) 
VALUES (13, NULL, 'My Front Line', 'Seus maiores sucessos', 13.49, 1); 
Como segundo exemplo do uso de junção entre tabelas, realizaremos a junção entre as 
tabelas PRODUTOS e TIPOS_PRODUTOS, obtendo todos os produtos ordenados pela coluna 
NM_PRODUTO:
SELECT produtos.nm_produto, 
 tipos_produtos.ds_tipo_produto
FROM produtos, tipos_produtos
WHERE produtos.id_tipo_produto = tipos_produtos.id_tipo_produto
ORDER BY produtos.nm_produto; 
NM_PRODUTO DS_TIPO_PRODUTO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
© Banco de Dados148
NM_PRODUTO DS_TIPO_PRODUTO
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Observe que o produto My Front Line encontra-se ausente das tuplas/linhas resultantes. 
Isso se deve ao fato de que o valor correspondente ao ID_TIPO_PRODUTO para essa tupla/linha 
de produto corresponde a um valor nulo e a condição da junção (JOIN) não retorna o registro. 
Como solução, é necessário utilizar uma junção externa (OUTER JOIN), recurso explorado ainda 
nesse tópico.
A sintaxe de junção (JOIN) vista até o momento utiliza a sintaxe no padrão SQL/86 ANSI.
Para facilitar nossa vida quanto à realização de junção, a SQL permite utilizarmos apelidos 
(alias) para as tabelas. Isso significa que podemos inserir nomes alternativos nas tabelas, por 
exemplo: as tabelas PRODUTOS e TIPOS_PRODUTOS nas cláusulas SELECT e WHERE, evitando, 
assim, a digitação redundante do nome das tabelas.
A consulta a seguir utiliza o apelido p para referenciar a tabela PRODUTOS e tp para refe-
renciar a tabela TIPOS_PRODUTOS.
SELECT p.nm_produto, tp.ds_tipo_produto
FROM produtos p, tipos_produtos tp
WHERE p.id_tipo_produto= tp.id_tipo_produto
ORDER BY p.nm_produto; 
NM_PRODUTO DS_TIPO_PRODUTO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Produto Cartesiano
A ausência da condição JOIN promove a união de todas as tuplas/linhas de uma tabela 
com todas as tuplas/linhas da outra tabela. Esse conjunto resultante é nomeado de produto 
cartesiano.
Imagine que exista uma Tabela A contendo 50 tuplas/linhas, e uma segunda Tabela B con-
tendo 100 tuplas/linhas. Se selecionássemos as colunas das duas tabelas sem uma condição de 
junção adequada (JOIN), obteríamos, como resultado, 5000 tuplas/linhas (cada linha da Tabela 
A seria juntada a cada linha da Tabela B).
Claretiano - Centro Universitário
149© U4 – SQL – Uma Linguagem de Consulta
A fim de elucidar melhor este exemplo, utilizaremos nosso cenário (banco de dados FA-
CULDADE) para apresentar um subconjunto das tuplas/linhas de um produto cartesiano entre 
as tabelas PRODUTOS e TIPOS_PRODUTOS:
SELECT p.nm_produto, tp.ds_tipo_produto
FROM produtos p, tipos_produtos tp; 
NM_PRODUTO DS_TIPO_PRODUTO
Ciência Moderna Livro
Química Livro
Supernova Livro
Tanque de Guerra Livro
Arquivos Z Livro
2412: O Retorno Livro
Força G Livro
De outro planeta Livro
Música clássica Livro
Pop 3 Livro
Yell criativo Livro
My Front Line Livro
Ciência Moderna Vídeo
Química Vídeo
Supernova Vídeo
Tanque de Guerra Vídeo
Arquivos Z Vídeo
2412: O Retorno Vídeo
Força G Vídeo
De outro planeta Vídeo
Música clássica Vídeo
Pop 3 Vídeo
Yell criativo Vídeo
My Front Line Vídeo
Ciência Moderna DVD
Química DVD
Supernova DVD
Tanque de Guerra DVD
Arquivos Z DVD
2412: O Retorno DVD
Força G DVD
De outro planeta DVD
Música clássica DVD
Pop 3 DVD
Yell criativo DVD
My Front Line DVD
Ciência Moderna CD
Química CD
Supernova CD
© Banco de Dados150
NM_PRODUTO DS_TIPO_PRODUTO
Tanque de Guerra CD
Arquivos Z CD
2412: O Retorno CD
Força G CD
De outro planeta CD
Música clássica CD
Pop 3 CD
Yell criativo CD
My Front Line CD
Ciência Moderna Revista
Química Revista
Supernova Revista
Tanque de Guerra Revista
Arquivos Z Revista
2412: O Retorno Revista
Força G Revista
De outro planeta Revista
Música clássica Revista
Pop 3 Revista
Yell criativo Revista
My Front Line Revista
Realizando SELECT entre várias tabelas (JOINs)
A instrução SELECT também permite selecionar atributos de diversas tabelas, desde que 
mesclada com a instrução JOIN, que, por sua vez, é utilizada para conectar n tabelas.
Para exemplificar, recorreremos a uma consulta considerada complexa, a qual utilizará 
quatro tabelas e que exigirá a realização de três JOINs. Essa consulta recuperará as seguintes 
informações:
a) As compras realizadas por cada cliente (tabela COMPRAS).
b) O nome e o sobrenome do cliente (tabela CLIENTES).
c) O nome do produto que eles compraram (tabela PRODUTOS).
d) O nome do tipo de produto (tabela TIPOS_PRODUTOS).
Para obter essas informações, será necessário consultar as tabelas COMPRAS, CLIENTES, 
PRODUTOS e TIPOS_PRODUTOS. As junções (JOINs) usarão os relacionamentos de chave estran-
geira (foreign key) entre as tabelas. Observe:
SELECT c.nm_cliente, 
 c.sobrenome, 
 p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO
FROM clientes c, compras co, produtos p, tipos_produtos tp
WHERE c.id_cliente = co.id_cliente
AND p.id_produto = co.id_produto
AND p.id_tipo_produto = tp.id_tipo_produto
ORDER BY p.nm_produto; 
Claretiano - Centro Universitário
151© U4 – SQL – Uma Linguagem de Consulta
NM_CLIENTE SOBRENOME PRODUTO TIPO
João Queiroz Ciência Moderna Livro
Silvia Queiroz Ciência Moderna Livro
Silvia Queiroz Química Livro
João Queiroz Supernova Vídeo
João Queiroz Tanque de Guerra Vídeo
JOIN e seus tipos
Existem dois tipos de condições de JOIN, as quais são baseadas no operador utilizado.
1) EQUIJOINS: utilizam o operador de igualdade (=).
2) NÃO EQUIJOINS: utilizam operadores que não correspondem ao operador de = (igual-
dade), por exemplo, < (menor que), > (maior que), BETWEEN, dentre outros.
a) JOINS INTERNAS (INNER): retornam uma tupla/linha somente quando as colunas 
da junção (JOIN) contêm valores que satisfazem essa condição. Se uma tupla/
linha possui um valor nulo em uma das colunas na condição de junção (JOIN), ela 
não é retornada.
b) JOINS EXTERNAS (OUTER): retornam uma tupla/linha mesmo quando uma das 
colunas na condição de junção (JOIN) contém um valor nulo.
c) AUTOJOINS: retornam linhas unidas na mesma tabela.
A NÃO EQUIJOINS utiliza um operador que não corresponde ao de igualdade (=), na con-
dição de junção (JOIN). 
Os operadores utilizados por esse tipo de junção são: diferente (<>), menor que (<), maior 
que (>), menor ou igual a (<=), maior ou igual a (>=), LIKE, IN e BETWEEN.
Exemplificaremos a utilização desse tipo de junção (NÃO EQUIJOIN) obtendo, inicialmen-
te, os níveis salariais dos funcionários. Veja a seguir:
SELECT id_salario,
 salario_minimo,
 salario_maximo,
 fg_ativo
FROM grades_salarios; 
ID_SALARIO SALARIO_MINIMO SALARIO_MAXIMO FG_ATIVO
1 1 25000 1
2 250001 500000 1
3 500001 750000 1
4 750001 999999 1
A consulta a seguir exemplifica a utilização de uma NÃO EQUIJOIN, a qual recupera o salá-
rio e os níveis salariais dos funcionários. O nível salarial é determinado pelo operador BETWEEN.
SELECT f.nm_funcionario, 
 f.sobrenome_funcionario, 
 f.cargo, f.salario, 
 gs.id_salario
FROM funcionarios f, grades_salarios gs
WHERE f.salario BETWEEN gs.salario_minimo AND gs.salario_maximo
ORDER BY gs.id_salario; 
© Banco de Dados152
NM_FUNCIONARIO SOBRENOME_FUNCIONARIO CARGO SALARIO ID_SALARIO
Susana Coimbra Vendedor 500000 2
Rubens Cardoso Gerente de Vendas 600000 3
Jaime Tenório Diretor Executivo 800000 4
Já a junção externa (OUTER JOIN) recupera uma tupla/linha mesmo quando uma de suas 
colunas contém um valor nulo. No próximo exemplo, o produto My Front Line, cujo ID_TIPO_
PRODUTO é nulo, é recuperado por meio da junção externa.
SELECT p.nm_produto AS PRODUTO, 
 tp.ds_tipo_produto AS TIPO
FROM produtos p
LEFT OUTER JOIN tipos_produtos tp ON(p.id_tipo_produto = tp.id_tipo_
produto)
ORDER BY p.nm_produto; 
PRODUTO TIPO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
My Front Line
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
As junções externas (OUTER JOIN) podem ser segmentadas em dois tipos: junção externa 
esquerda (LEFT OUTER JOIN) e junção externa direita (RIGHT OUTER JOIN). Sua sintaxe pode ser 
compreendida como:
SELECT ...
FROM TABELA_1
...
Suponha que as tabelas sejam unidas em tabela_1.coluna_1 e tabela_2.coluna_2, e que 
a tabela_1 contenha uma tupla/linha com um valor nulo na coluna_1. Então, para realizar uma 
junção externa esquerda (LEFT OUTER JOIN), a instrução SQL ficaria:
LEFT OUTER JOIN tabela_2 ON (tabela_1.coluna_1 = tabela_2.coluna_2)
Por outro lado, suponha que a tabela_2 contenha uma tupla/linha com um valor nulo 
na coluna_2. A instrução SQL seria modificada para realizar uma junção externa direita (RIGHT 
OUTER JOIN):
RIGHT OUTER JOIN tabela_2 ON (tabela_1.coluna_1 = tabela_2.coluna_2)
Claretiano - Centro Universitário
153© U4 – SQL – Uma Linguagem de Consulta
Para exemplificar o uso da junção externa direita (RIGHT OUTER JOIN), a tabela TIPOS_
PRODUTOS contém um tipo de produto não referenciado na tabela PRODUTOS, ou seja, não 
existem produtos do tipo REVISTA na tabela PRODUTOS. Veja:
SELECT id_tipo_produto,
 ds_tipo_produto,
 fg_ativo
FROM tipos_produtos; 
ID_TIPO_PRODUTO DS_TIPO_PRODUTO FG_ATIVO
1 Livro 1
2 Vídeo 1
3 DVD 1
4 CD 1
5 Revista 1
Veja como recuperar uma REVISTA em uma das tabelas, PRODUTOS e TIPOS_PRODUTOS, 
utilizando a instrução SQL a seguir.
SELECT p.nm_produto AS PRODUTO,tp.ds_tipo_produto AS TIPO
FROM produtos p
RIGHT OUTER JOIN tipos_produtos tp ON(p.id_tipo_produto = tp.id_tipo_
produto)
ORDER BY p.nm_produto; 
PRODUTO TIPO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Revista
A autojunção (AUTOJOIN) é realizada na mesma tabela, ou seja, é uma consulta recursiva. 
Nesse tipo de junção, torna-se imprescindível a utilização de apelidos (alias) distintos para iden-
tificar cada referência à tabela.
A tabela FUNCIONARIOS possui uma coluna ID_GERENTE para cada funcionário. Caso um 
determinado funcionário não seja gerenciado por ninguém, o ID_GERENTE será nulo. O funcio-
nário cujo nome corresponde a Jaime é considerado o Diretor Executivo CEO (Chief Executive 
Officer), tendo um valor nulo para o ID_GERENTE. Usaremos o AUTOJOIN para exibir os nomes 
de cada funcionário e seu respectivo gerente:
© Banco de Dados154
SELECT f.nm_funcionario || ' ' 
 || f.sobrenome_funcionario || ' trabalha para ' 
 || g.nm_funcionario
FROM funcionarios f, funcionarios g
WHERE f.id_gerente = g.id_funcionario
ORDER BY f.nm_funcionario; 
?column?
Frederico Munhoz trabalha para Rubens
Rubens Cardoso trabalha para Jaime
Susana Coimbra trabalha para Rubens
O padrão SQL/92 introduz as cláusulas INNER JOIN e ON para realizar uma junção interna. 
A instrução SQL, a seguir, ilustra o uso do padrão SQL/92 para recuperar o nome do produto 
(tabela PRODUTOS) e a descrição do tipo do produto (tabela TIPOS_PRODUTOS).
SELECT p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO
FROM produtos p
INNER JOIN tipos_produtos tp ON (p.id_tipo_produto = tp.id_tipo_produto)
ORDER BY p.nm_produto; 
PRODUTO TIPO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Já vimos como realizar uma consulta utilizando operadores de NÃO EQUIJOIN com a cláu-
sula ON no padrão SQL/86. Agora, traduziremos a consulta para o padrão SQL/92. Observe:
SELECT f.nm_funcionario,
 f.sobrenome_funcionario,
 f.cargo, 
 f.salario,
 gs.id_salario 
FROM funcionarios f
INNER JOIN grades_salarios gs ON(f.salario BETWEEN gs.salario_minimo AND 
gs.salario_maximo)
ORDER BY gs.id_salario; 
O padrão SQL/92 permite simplificar ainda mais a condição de JOIN com a cláusula USING. 
Algumas limitações devem ser evidenciadas, como: a consulta deve usar uma EQUIJOIN, e as 
colunas na EQUIJOIN devem ter o mesmo NOME. A próxima consulta implementa o uso de 
Claretiano - Centro Universitário
155© U4 – SQL – Uma Linguagem de Consulta
USING substituindo ON, para exibir o nome do produto (tabela PRODUTOS) e seu respectivo tipo 
(tabela TIPOS_PRODUTOS).
SELECT p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO
FROM produtos p
INNER JOIN tipos_produtos tp
USING(id_tipo_produto); 
PRODUTO TIPO
Ciência Moderna Livro
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Arquivos Z Vídeo
2412: O Retorno Vídeo
Força G DVD
De outro planeta DVD
Música clássica CD
Pop 3 CD
Yell criativo CD
Caso seja necessário exibir o ID_TIPO_PRODUTO, será imprescindível fornecer o nome da 
coluna sozinho, ou seja, sem o nome ou apelido da tabela na cláusula SELECT.
SELECT p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO,
 id_tipo_produto
FROM produtos p
INNER JOIN tipos_produtos tp
USING(id_tipo_produto); 
PRODUTO TIPO ID_TIPO_PRODUTO
Ciência Moderna Livro 1
Química Livro 1
Supernova Vídeo 2
Tanque de Guerra Vídeo 2
Arquivos Z Vídeo 2
2412: O Retorno Vídeo 2
Força G DVD 3
De outro planeta DVD 3
Música clássica CD 4
Pop 3 CD 4
Yell criativo CD 4
O nome da coluna dentro da cláusula USING deverá, também, permanecer sozinho, con-
forme visualizado no exemplo a seguir, onde um erro é retornado.
© Banco de Dados156
SELECT p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO,
 id_tipo_produto
FROM produtos p
INNER JOIN tipos_produtos tp
USING(p.id_tipo_produto); 
Figura 14 Utilização indevida da cláusula USING.
É possível utilizar junções internas envolvendo mais de duas tabelas usando o padrão 
SQL/92, conforme a consulta a seguir, a qual recupera o nome e sobrenome do cliente (tabela 
CLIENTES), nome do produto (tabela PRODUTOS) e descrição do tipo de produto (tabela TIPOS_
PRODUTOS), com a identificação dos clientes e suas respectivas compras.
SELECT c.nm_cliente,
 c.sobrenome,
 p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO
FROM clientes c
INNER JOIN compras co USING (id_cliente)
INNER JOIN produtos p USING (id_produto)
INNER JOIN tipos_produtos tp USING (id_tipo_produto)
ORDER BY p.nm_produto;
NM_CLIENTE SOBRENOME PRODUTO TIPO
João Queiroz Ciência Moderna Livro
Silvia Queiroz Ciência Moderna Livro
Silvia Queiroz Química Livro
João Queiroz Supernova Vídeo
João Queiroz Tanque de Guerra Vídeo
As junções internas que fazem uso de diversas colunas também podem usufruir do padrão 
SQL/92. Se uma junção (JOIN) utiliza mais de uma coluna nas duas tabelas, forneça essas colu-
nas em sua cláusula ON, utilizando, paralelamente, o operador AND. 
Para exemplificar, considere duas tabelas nomeadas de TABELA_1 e TABELA_2, as quais 
necessitamos juntar usando colunas chamadas de COLUNA_1 e COLUNA_2 nas duas tabelas. 
Observe:
Claretiano - Centro Universitário
157© U4 – SQL – Uma Linguagem de Consulta
SELECT ...
FROM TABELA_1
INNER JOIN TABELA_2 ON (TABELA_1.COLUNA_1 = TABELA_2.COLUNA_2
AND TABELA_1.COLUNA_2 = TABELA_2.COLUNA_2);
Com o objetivo de simplificar nossas vidas, poderíamos acrescentar, na consulta, a cláu-
sula USING, mas somente se estivermos realizando EQUIJOIN e os nomes das colunas forem 
idênticos, conforme a sintaxe a seguir.
SELECT ...
FROM TABELA_1
INNER JOIN TABELA_2
USING (COLUNA_1, COLUNA_2);
Para detalhar as junções externas, consideramos a sintaxe a seguir:
SELECT ...
FROM TABELA_1 { LEFT | RIGHT | FULL }
OUTER JOIN TABELA_2
Onde: 
1) TABELA_1 e TABELA_2: são as tabelas pertinentes à junção.
2) LEFT: realiza uma JOIN externa esquerda.
3) RIGHT: realiza uma JOIN externa direita.
4) FULL: realiza uma JOIN externa completa (utiliza todas as tuplas/linhas da TABELA_1 e 
TABELA_2, incluindo os valores nulos nas colunas usadas na junção).
O exemplo a seguir ilustra o uso da junção externa completa (FULL OUTER JOIN) empre-
gando o padrão SQL/92, a qual permite incluir as tuplas/linhas das tabelas unidas, inclusive 
aqueles valores nulos em uma ou outra das colunas usadas na JOIN. Veja:
SELECT p.nm_produto AS PRODUTO,
 tp.ds_tipo_produto AS TIPO
FROM produtos p
FULL OUTER JOIN tipos_produtos tp 
USING (id_tipo_produto)
ORDER BY p.nm_produto;
PRODUTO TIPO
2412: O Retorno Vídeo
Arquivos Z Vídeo
Ciência Moderna Livro
De outro planeta DVD
Força G DVD
Música clássica CD
My Front Line
Pop 3 CD
Química Livro
Supernova Vídeo
Tanque de Guerra Vídeo
Yell criativo CD
Revista
© Banco de Dados158
O produto cartesiano, ou melhor, a junção cruzada, também pode usufruir do padrão 
SQL/92 para simplificar a instrução SQL. Usando a sintaxe de junção (JOIN) SQL/92, evitamos 
a produção acidental de um produto cartesiano, simplesmente ao se utilizar a cláusula ON ou 
USING. Dessa maneira, para forçarmos um produto cartesiano por meio do padrão SQL/92, usa-
mos explicitamente as palavras-chave CROSS JOIN, conforme a consulta a seguir, a qual realiza 
um produto cartesiano (junção cruzada) entre as tabelas TIPOS_PRODUTOS e PRODUTOS.
SELECT tp.id_tipo_produto,
 tp.ds_tipo_produto, 
 p.nm_produto,
 p.ds_produto,
 p.preco 
FROM tipos_produtos tp
CROSS JOIN produtos p;
ID_TIPO_PRODUTO DS_TIPO_PRODUTO NM_PRODUTO DS_PRODUTO RECO
1 Livro Ciência Moderna Uma descrição da ciência moderna 19.95
1 Livro Química Introdução à Química30.00
1 Livro Supernova Uma estrela explosiva 25.99
1 Livro Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
1 Livro Arquivos Z Série sobre atividades misteriosas 49.99
1 Livro 2412: O Retorno Alien O Retorno 14.95
1 Livro Força G Aventuras dos heróis 13.49
1 Livro De outro planeta Alienígena de outro planeta na Terra 12.99
1 Livro Música clássica O melhor da música clássica 10.99
1 Livro Pop 3 O melhor da música popular 15.99
1 Livro Yell criativo Álbum de estréia 14.99
1 Livro My Front Line Seus maiores sucessos 13.49
2 Vídeo Ciência Moderna Uma descrição da ciência moderna 19.95
2 Vídeo Química Introdução à Química 30.00
2 Vídeo Supernova Uma estrela explosiva 25.99
2 Vídeo Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
2 Vídeo Arquivos Z Série sobre atividades misteriosas 49.99
2 Vídeo 2412: O Retorno Alien O Retorno 14.95
2 Vídeo Força G Aventuras dos heróis 13.49
2 Vídeo De outro planeta Alienígena de outro planeta na Terra 12.99
2 Vídeo Música clássica O melhor da música clássica 10.99
2 Vídeo Pop 3 O melhor da música popular 15.99
2 Vídeo Yell criativo Álbum de estréia 14.99
2 Vídeo My Front Line Seus maiores sucessos 13.49
3 DVD Ciência Moderna Uma descrição da ciência moderna 19.95
3 DVD Química Introdução à Química 30.00
3 DVD Supernova Uma estrela explosiva 25.99
3 DVD Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
3 DVD Arquivos Z Série sobre atividades misteriosas 49.99
3 DVD 2412: O Retorno Alien O Retorno 14.95
3 DVD Força G Aventuras dos heróis 13.49
3 DVD De outro planeta Alienígena de outro planeta na Terra 12.99
Claretiano - Centro Universitário
159© U4 – SQL – Uma Linguagem de Consulta
ID_TIPO_PRODUTO DS_TIPO_PRODUTO NM_PRODUTO DS_PRODUTO RECO
3 DVD Música clássica O melhor da música clássica 10.99
3 DVD Pop 3 O melhor da música popular 15.99
3 DVD Yell criativo Álbum de estréia 14.99
3 DVD My Front Line Seus maiores sucessos 13.49
4 CD Ciência Moderna Uma descrição da ciência moderna 19.95
4 CD Química Introdução à Química 30.00
4 CD Supernova Uma estrela explosiva 25.99
4 CD Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
4 CD Arquivos Z Série sobre atividades misteriosas 49.99
4 CD 2412: O Retorno Alien O Retorno 14.95
4 CD Força G Aventuras dos heróis 13.49
4 CD De outro planeta Alienígena de outro planeta na Terra 12.99
4 CD Música clássica O melhor da música clássica 10.99
4 CD Pop 3 O melhor da música popular 15.99
4 CD Yell criativo Álbum de estréia 14.99
4 CD My Front Line Seus maiores sucessos 13.49
5 Revista Ciência Moderna Uma descrição da ciência moderna 19.95
5 Revista Química Introdução à Química 30.00
5 Revista Supernova Uma estrela explosiva 25.99
5 Revista Tanque de Guerra Filme de ação sobre uma possível guerra 13.95
5 Revista Arquivos Z Série sobre atividades misteriosas 49.99
5 Revista 2412: O Retorno Alien O Retorno 14.95
5 Revista Força G Aventuras dos heróis 13.49
5 Revista De outro planeta Alienígena de outro planeta na Terra 12.99
5 Revista Música clássica O melhor da música clássica 10.99
5 Revista Pop 3 O melhor da música popular 15.99
5 Revista Yell criativo Álbum de estréia 14.99
5 Revista My Front Line Seus maiores sucessos 13.49
Funções Simples - SQL
Uma função poderá aceitar zero ou mais parâmetros de entrada, retornando um parâme-
tro de saída. No PostgreSQL existem dois tipos de funções, identificadas como:
• Funções de uma única linha: operam uma tupla/linha por vez e retornam uma tupla/
linha de saída para cada tupla/linha de entrada.
Exemplo: 
CONCAT(x, y)
O comando retorna uma string resultante.
• Funções de Agregação: operam sobre várias tuplas/linhas por vez e retornam uma tu-
pla/linha de saída.
Exemplo:
AVG(x)
© Banco de Dados160
O comando retorna a média de x, em que x pode ser uma coluna e/ou uma expressão.
As funções de uma única linha são segmentadas em cinco tipos principais, detalhadas a 
seguir:
1) Funções de caractere: manipulam strings de caracteres.
2) Funções numéricas: efetuam cálculos.
3) Funções de conversão: convertem um valor de um tipo para outro.
4) Funções de data: processam data e hora.
5) Funções de expressão regular: utilizam expressões regulares para procurar dados.
As funções de caractere aceitam a entrada de caractere (coluna ou expressão). Um exem-
plo é a função de caractere ASCII(x), utilizada para obter o valor ASCII do caractere x. Veja a 
seguir:
SELECT ASCII('a'), 
 ASCII('A'),
 ASCII('z'),
 ASCII('Z'),
 ASCII('0'),
 ASCII('9'); 
ASCII ASCII ASCII ASCII ASCII ASCII
97 65 122 90 48 57
Para realizar o inverso da função ASCII(x), a função CHR(x) permite obter o caractere com 
o valor ASCII. Observe:
SELECT CHR(97),
 CHR(65),
 CHR(122),
 CHR(90),
 CHR(48),
 CHR(57); 
CHR CHR CHR CHR CHR CHR
A A z Z 0 9
A função INITCAP(x) converte a letra inicial de cada palavra de x em maiúsculas. Para 
exemplificar o uso da função INITCAP(x), os registros associados à coluna DS_PRODUTO terão 
sua primeira letra de cada palavra convertidas em maiúsculas. Veja:
SELECT id_produto,
 INITCAP(ds_produto)
FROM produtos
ORDER BY id_produto; 
ID_PRODUTO INITCAP
1 Uma Descrição Da Ciência Moderna
2 Introdução À Química
3 Uma Estrela Explosiva
4 Filme De Ação Sobre Uma Possível Guerra
Claretiano - Centro Universitário
161© U4 – SQL – Uma Linguagem de Consulta
ID_PRODUTO INITCAP
6 Série Sobre Atividades Misteriosas
7 Alien O Retorno
8 Aventuras Dos Heróis
9 Alienígena De Outro Planeta Na Terra
10 O Melhor Da Música Clássica
11 O Melhor Da Música Popular
12 Álbum De Estréia
13 Seus Maiores Sucessos
LENGTH(x) é uma função que obtém o número de caracteres em x. No exemplo a seguir, 
observe o uso da função LENGHT(x) para obter o comprimento dos strings na coluna NM_PRO-
DUTO da tabela PRODUTOS:
SELECT nm_produto, 
 LENGTH(nm_produto)
FROM produtos; 
NM_PRODUTO LENGTH
Ciência Moderna 15
Química 7
Supernova 9
Tanque de Guerra 16
Arquivos Z 10
2412: O Retorno 15
Força G 7
De outro planeta 16
Música clássica 15
Pop 3 5
Yell criativo 13
My Front Line 13
A função LOWER(x) converte as letras de x para minúsculas e a função UPPER(x) converte 
as letras de x para maiúsculas. Para exemplificar o uso das duas funções que manipulam carac-
teres, serão convertidos os strings da coluna NM_FUNCIONARIO em maiúsculas e os strings 
associados à coluna SOBRENOME_FUNCIONARIO em minúsculas.
SELECT UPPER(nm_funcionario) AS NOME,
 LOWER(sobrenome_funcionario) AS SOBRENOME
FROM funcionarios; 
NOME SOBRENOME
JAIME tenório
RUBENS cardoso
FREDERICO munhoz
SUSANA coimbra
© Banco de Dados162
As duas funções a seguir fornecem facilitadores na formatação de relatórios oriundos de 
um banco de dados. A função LPAD(x, largura, string preenchimento) preenche x com espaços 
à esquerda até atingir o comprimento total da string (largura). Ela permite fornecer a string de 
preenchimento (parâmetro opcional). A função RPAD(x, largura, string preenchimento) preen-
che x com espaços à direita até atingir o comprimento total da string (largura). Semelhante à 
função LPAD(x, largura, string preenchimento), o RPAD(x, largura, string preenchimento) tam-
bém permite fornecer a string de preenchimento (parâmetro opcional). Para exemplificar o uso 
dessas duas funções, a coluna NM_PRODUTO será preenchida à direita (comprimento igual a 
30 – string pontos (.)) e a coluna DS_PRODUTO será preenchida à esquerda (comprimento igual 
a 50 – string (*+)):
SELECT RPAD(nm_produto, 30, '.'),
 LPAD(ds_produto, 50, '*+')
FROM produtos
ORDER BY id_produto;
RPAD LPAD
Ciência Moderna............... *+*+*+*+*+*+*+*+*+Uma descrição da ciência moderna
Química....................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Introdução à Química
Supernova..................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*Uma estrela explosiva
Tanque de Guerra.............. *+*+*+*+*+*Filme de ação sobre uma possívelguerra
Arquivos Z.................... *+*+*+*+*+*+*+*+Série sobre atividades misteriosas
2412: O Retorno............... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*Alien O Retorno
Força G....................... *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Aventuras dos heróis
De outro planeta.............. *+*+*+*+*+*+*+Alienígena de outro planeta na Terra
Música clássica............... *+*+*+*+*+*+*+*+*+*+*+*O melhor da música clássica
Pop 3......................... *+*+*+*+*+*+*+*+*+*+*+*+O melhor da música popular
Yell criativo................. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+Álbum de estréia
My Front Line................. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*Seus maiores sucessos
A função LTRIM(x, string de corte) corta a esquerda de x, permitindo fornecer a string de 
corte (parâmetro opcional). Caso não seja informada a string de corte, os espaços serão corta-
dos por padrão. RTRIM(x, string de corte) é o oposto da função LTRIM(x, string de corte), cortan-
do a direita de x, permitindo também fornecer a string de corte (parâmetro opcional). Caso não 
seja informada a string de corte, os espaços também serão cortados por padrão.
Uma função que corta ambos os lados (DIREITO e ESQUERDO) simultaneamente é nomea-
da de TRIM(x, string de corte). Idêntica às funções LTRIM(x, string de corte) e RTRIM(x, string de 
corte), TRIM(x, string de corte) também permite fornecer a string de corte (parâmetro opcional) 
e, caso não seja informada a string de corte, os espaços também serão cortados por padrão em 
ambos os lados. 
O próximo exemplo demonstra o uso das três funções simultaneamente: LTRIM(x, string 
de corte), RTRIM(x, string de corte) e TRIM(x, string de corte):
SELECT 
 LTRIM(' Olá pessoal, tudo joia?'),
 RTRIM('Olá tudo bem!abc', 'abc'),
 TRIM('x' FROM 'xxxAula de BDxxxxx'); 
Claretiano - Centro Universitário
163© U4 – SQL – Uma Linguagem de Consulta
LTRIM RTRIM BTRIM
Olá pessoal, tudo joia? Olá tudo bem! Aula de BD
Para procurar uma string qualquer e substituí-la por outra, utilizamos a função REPLACE(x, 
string de busca, string substituta), onde é realizada a busca baseando-se na string de busca em 
x e substituída pela string substituta. O exemplo a seguir utiliza o produto cujo ID_PRODUTO 
corresponda ao Número 1 (Ciência Moderna – a string Ciência será substituído por Física). Um 
detalhe importante é que não é alterada a tupla/linha real no banco de dados; somente a tupla/
linha retornada pela função é modificada. Veja a seguir:
SELECT REPLACE(nm_produto,
 'Ciência',
 'Física')
FROM produtos
WHERE id_produto = 1;
REPLACE
Física Moderna
Eventualmente, torna-se necessário extrair partes de uma string qualquer. A função 
SUBSTR(x, início, comprimento) retorna uma substring de x que inicia na posição especificada 
pelo parâmetro início. Essa função também permite fornecer um comprimento (parâmetro op-
cional) para a substring. Para ilustrar a funcionalidade da função SUBSTR(x, início, comprimen-
to), a tabela PRODUTOS será utilizada para obtermos a substring de sete caracteres a partir da 
Posição 2 da coluna NM_PRODUTO.
SELECT nm_produto AS Original, 
 SUBSTR(nm_produto, 2, 7) AS Substring
FROM produtos
ORDER BY id_produto;
ORIGINAL SUBSTRING
Ciência Moderna iência 
Química uímica
Supernova upernov
Tanque de Guerra anque d
Arquivos Z rquivos
2412: O Retorno 412: O 
Força G orça G
De outro planeta e outro
Música clássica úsica c
Pop 3 op 3
Yell criativo ell cri
My Front Line y Front
É possível também fornecer qualquer expressão válida que seja avaliada como uma string. 
No próximo exemplo – do uso de SUBSTR(x, início, comprimento) –, utilizaremos a função para 
obter a substring DBA da string Administrador de Banco de Dados - DBA.
© Banco de Dados164
SELECT SUBSTR('Administrador de Banco de Dados - DBA', 
 34, 
 4); 
SUBSTR
DBA
Em uma instrução SQL é possível utilizar uma combinação de funções. Por exemplo, ima-
gine que é preciso combinar as funções UPPER(x) e SUBSTR(x, início, comprimento), em que a 
saída da função SUBSTR() é passada para a função UPPER(x). Veja a seguir:
SELECT nm_produto, 
 UPPER(SUBSTR(nm_produto, 2, 8))
FROM produtos
ORDER BY id_produto;
NM_PRODUTO UPPER
Ciência Moderna IÊNCIA M
Química UÍMICA
Supernova UPERNOVA
Tanque de Guerra ANQUE DE
Arquivos Z RQUIVOS 
2412: O Retorno 412: O R
Força G ORÇA G
De outro planeta E OUTRO 
Música clássica ÚSICA CL
Pop 3 OP 3
Yell criativo ELL CRIA
My Front Line Y FRONT 
As funções numéricas realizam diversos cálculos, sejam esses utilizando expressões ou 
valores atrelados às colunas de uma determinada tabela. A função ABS(x) permite obtermos um 
valor absoluto de x, que é o número sem o sinal (positivo/negativo).
Para exemplificar o uso da função ABS(x), será subtraído 30 dos valores correspondentes 
à coluna PRECO da tabela PRODUTOS.
SELECT id_produto,
 preco,
 preco - 30,
 ABS(preco - 30)
FROM produtos; 
ID_PRODUTO PRECO ?COLUMN? ABS
1 19.95 -10.05 10.05
2 30.00 0.00 0.00
3 25.99 -4.01 4.01
4 13.95 -16.05 16.05
6 49.99 19.99 19.99
7 14.95 -15.05 15.05
Claretiano - Centro Universitário
165© U4 – SQL – Uma Linguagem de Consulta
ID_PRODUTO PRECO ?COLUMN? ABS
8 13.49 -16.51 16.51
9 12.99 -17.01 17.01
10 10.99 -19.01 19.01
11 15.99 -14.01 14.01
12 14.99 -15.01 15.01
13 13.49 -16.51 16.51
A função identificada como CEIL(x) é oriunda, também, da família das funções numéricas, 
cuja finalidade é obter o número menor inteiro, maior ou igual a x. Para ilustrar sua utilização, 
a função CEIL(x) será utilizada para obter os valores absolutos de 5,8 e -5,2. O teto de 5,8 é 6, 
porque corresponde ao número menor inteiro, maior do que 5,8, e o teto de -5,2 é -5, porque 
-5,2 é negativo e o número menor inteiro, maior do que ele é -5.
SELECT CEIL(5.8),
 CEIL(-5.2); 
CEIL Ceil
6 -5
Oposto à função CEIL(x), a função FLOOR(x), por sua vez, obtém o maior número inteiro, 
menor ou igual a x. Como exemplos serão utilizados os mesmos parâmetros da função anterior, 
em que a função FLOOR(x) obterá o valor absoluto de 5,8 e -5,2. O piso de 5,8 é 5, porque 5 é 
maior número inteiro, menor do que 5,8 e o piso de -5,2 é -6, porque -5,2 é negativo e o maior 
número inteiro, menor do que este valor é -6.
SELECT FLOOR(5.8),
 FLOOR(-5.2); 
Floor floor
5 -6
A função MOD(x, y) obtém o resto da divisão de x por y. Essa função é frequentemente uti-
lizada para descobrir se um determinado número é par ou ímpar, ou até mesmo se um número 
qualquer é múltiplo de outro. Como exemplo, a função MOD(x, y) será utilizada para obtermos 
o resto da divisão, quando 8 for dividido por 3 e por 4. Acompanhe a seguir:
SELECT MOD(8, 3),
 MOD(8, 4); 
Mod mod
2 0
A função POWER(x, y) é uma função numérica que obtém o resultado de x elevado à po-
tência y. A função POWER(x, y) obterá 2 elevado às potências 1 e 3 como exemplo. Observe:
SELECT POWER(2, 1),
 POWER(2, 3); 
© Banco de Dados166
Power power
2 8
A função ROUND(x, [y]) é utilizada para obter o arredondamento de x com y casas deci-
mais (parâmetro opcional). Se o y for omitido, x será arredondado com zero casa decimal e se y 
for negativo, x será arredondado à esquerda do ponto decimal.
Como exemplo, ROUND(x, [y]) será utilizado para obter o resultado do arredondamento 
de 5,75 com zero, 1 e -1 casas decimais. Acompanhe:
SELECT ROUND(5.75),
 ROUND(5.75, 1),
 ROUND(5.75, -1); 
Round round round
6 5.8 10
SIGN(x) é uma função cujo objetivo é obter o sinal de x. A função retorna -1 se x for nega-
tivo, retorna 1 se x for positivo e retorna 0 (zero) se x for zero. Um exemplo é o uso da função 
SIGN(x) para obter o sinal dos valores -5, 5 e 0. Observe:
SELECT SIGN(-5),
 SIGN(5),
 SIGN(0); 
Sign sign sign
-1 1 0
Para obter a raiz quadrada de um determinado número, você poderá recorrer à função 
SQRT(x). Como exemplo, a função obterá a raizquadrada de 25 e 5, respectivamente. Veja a 
seguir:
SELECT SQRT(25),
 SQRT(5); 
SQRT SQRT
5 2.23606797749979
Percebe-se que o resultado proveniente da raiz quadrada de 5 não se encontra forma-
tado adequadamente. Para isso, a função TRUNC(x, [y]) é utilizada para obter o resultado do 
truncamento do número x com y casas decimais (parâmetro opcional). Caso y seja omitido, x 
será truncado com zero casa decimal. Se y for negativo, y será truncado à esquerda do ponto 
decimal. Vejamos o uso da função TRUNC(x, [y]): ela realizará o truncamento de 5,75 com zero, 
1 e -1 casas decimais.
SELECT TRUNC(5.75),
 TRUNC(5.75, 1),
 TRUNC(5.75, -1); 
Claretiano - Centro Universitário
167© U4 – SQL – Uma Linguagem de Consulta
TRUNC TRUNC TRUNC
5 5.7 0
Agora que encerramos a apresentação e os exemplos pertinentes às funções numéricas, 
podemos iniciar a exploração das funções de conversão. Para dar início às funções de conversão, 
vejamos a função TO_CHAR(x, [format]), que converte x em uma string e permite fornecer o for-
mato de saída de x (parâmetro opcional). A estrutura do formato depende de x ser um número 
ou uma data.
Como exemplo, a função TO_CHAR(x, [format]) realiza a conversão de um número em uma 
string usando o formato 99.999.99.
SELECT TO_CHAR(12345.67, 
 '99,999.99'); 
TO_CHAR
12,345.67
O parâmetro 9 retorna dígitos na posição especificada, com um sinal negativo à esquerda 
se o número for negativo. O exemplo a seguir apresenta a importância de manipularmos ade-
quadamente o parâmetro 9. Observe:
SELECT TO_CHAR(12345.67, 
 '99999.99'); 
TO_CHAR
12345.67
O parâmetro 0 (zero) retorna um número com zeros à esquerda e/ou à direita. O uso do 
parâmetro 0 (zero) pode ser visualizado no exemplo a seguir. Observe:
SELECT TO_CHAR(12345.67, 
 '099,999.99');
TO_CHAR
012,345.67
O parâmetro . (ponto), por sua vez, retorna para a função um ponto decimal na posição 
específica. Já o parâmetro , (vírgula) retorna uma vírgula também na posição especificada pela 
função. Nos exemplos explorados até o momento, com a função TO_CHAR(x, [format]), utiliza-
mos um (somente o . (ponto)) ou ambos os parâmetros (. (ponto) e , (vírgula)).
A letra L também pode ser utilizada como parâmetro para a função TO_CHAR(x, [format]), 
retornando o símbolo de moeda local na posição especificada. O símbolo vem da variável do 
SGBD lc_monetary. No exemplo a seguir o parâmetro L é utilizado para inserir o símbolo da 
moeda local. Veja:
SELECT TO_CHAR(12345.67, 
 'L99,999.99');
© Banco de Dados168
TO_CHAR
R$ 12,345.67
Um parâmetro muito interessante utilizado na função TO_CHAR(x, [format]) é o RN, o qual 
retorna para a função o número em algarismos romanos. O RN retorna números maiúsculos e M 
retorna números minúsculos. O número deve ser um valor inteiro entre o intervalo de 1 a 3999. 
No próximo exemplo, a função TO_CHAR(x, [format]) é utilizada para converter o número 2011 
em algarismos romanos. Acompanhe:
SELECT TO_CHAR(2011, 
 'RN');
TO_CHAR
MMXI
A função TO_CHAR(x, [format]) retornará uma string de caracteres # se, eventualmente, 
for formatado um número contendo dígitos a mais para o formato. Por exemplo, o número 
12345678.90 para o formato 99,999.99.
SELECT TO_CHAR(12345678.90, 
 '99,999.99');
TO_CHAR
##,###.##
O próximo exemplo de uso da função TO_CHAR(x, [format]) converte valores de colunas 
contendo números em strings, ou seja, nesse exemplo serão convertidos valores atrelados à 
coluna PRECO da tabela PRODUTOS em uma string, utilizando, paralelamente, o parâmetro L 
(símbolo de moeda local).
SELECT id_produto, 'O preço do produto é: ' ||
 TO_CHAR(preco, 'L99.99')
FROM produtos
ORDER BY id_produto;
ID_PRODUTO ?COLUMN?
1 O preço do produto é: R$ 19.95
2 O preço do produto é: R$ 30.00
3 O preço do produto é: R$ 25.99
4 O preço do produto é: R$ 13.95
6 O preço do produto é: R$ 49.99
7 O preço do produto é: R$ 14.95
8 O preço do produto é: R$ 13.49
9 O preço do produto é: R$ 12.99
10 O preço do produto é: R$ 10.99
11 O preço do produto é: R$ 15.99
12 O preço do produto é: R$ 14.99
13 O preço do produto é: R$ 13.49
Claretiano - Centro Universitário
169© U4 – SQL – Uma Linguagem de Consulta
Com a funcionalidade exatamente inversa, a função TO_CHAR(x, [format]), TO_NUMBER(x, 
[format]) converte x em um número, permitindo fornecer uma string de formato para indicar o 
formato de x (parâmetro opcional). Para exemplificar o uso da função TO_NUMBER(x, [format]), 
a string 970,13 será convertida em número. Veja:
SELECT TO_NUMBER('970.13', 
 '999.99');
TO_NUMBER
970.13
Finalizando as funções de conversão, a função CAST(x AS tipo) é utilizada para converter 
x em um tipo de dado compatível, especificado por tipo. Para exemplificar o uso dessa função, 
CAST(x AS tipo) será utilizada diversas vezes para realizar a conversão adequada de tipo de dado.
SELECT
 CAST(12345.67 AS VARCHAR(10)),
 CAST('01-12-2009' AS DATE),
 CAST(12345.678 AS NUMERIC(10,2));
VARCHAR DATE NUMERIC
12345.67 01/12/2009 12345.68
As funções agregadas operam em um grupo de tuplas/linhas e retornam uma tupla/linha 
de saída. Essas funções de agregação também são conhecidas como funções de grupo pelo fato 
de trabalhar em grupo de tuplas/linhas. Algumas observações devem ser feitas:
• Possibilidade de utilizar funções agregadas com qualquer expressão válida, por exem-
plo, COUNT(), MAX() e MIN() com números, strings e data/hora.
• Valores nulos são ignorados pelas funções agregadas (nulo indica um valor desconhe-
cido).
• Uso da palavra DISTINCT em uma função agregada para excluir entradas duplicadas.
Para falar sobre as funções de agregação, iniciaremos pela função AVG(x), que obtém o 
valor médio de x. Para ilustrar o uso dessa função, será obtido o preço médio dos produtos ca-
dastrados na tabela PRODUTOS. Acompanhe a seguir:
SELECT AVG(preco)
FROM produtos;
AVG
19.7308333333333
A função COUNT(x) também faz parte das funções agregadas; ela obtém o número de 
tuplas/linhas retornadas por uma consulta. Para exemplificar, utilizaremos a função COUNT(x) 
para obter o número de tuplas/linhas na tabela PRODUTOS.
SELECT COUNT(id_produto)
FROM produtos;
© Banco de Dados170
COUNT
12
As funções MAX(x) e MIN(x) obtêm, respectivamente, o valor máximo e mínimo de x. Para 
visualizar sua aplicabilidade, o próximo exemplo mostra o valor máximo e o valor mínimo da 
coluna PRECO da tabela PRODUTOS.
SELECT MAX(preco), 
 MIN(preco)
FROM produtos;
MAX MIN
49.99 10.99
As funções MAX(x) e MIN(x) permitem utilizar qualquer tipo de dado, inclusive strings e 
datas. A função MAX(x) com strings são classificadas em ordem alfabética, com a string máxima 
no final da lista e a string mínima no início. Para ilustrar essa funcionalidade, o exemplo a seguir 
obtém as strings máxima e mínima pertinentes à coluna NM_PRODUTO, da tabela PRODUTOS:
SELECT MAX(nm_produto), 
 MIN(nm_produto)
FROM produtos;
MAX MIN
Yell criativo 2412: O Retorno
A data máxima ocorre no ponto mais recente no tempo e a data mínima, no ponto mais 
antigo. Para exemplificar o uso das funções agregadas MAX(x) e MIN(x) manipulando datas, se-
rão obtidos os valores mínimo e máximo dos valores associados à coluna DT_NASCIMENTO, da 
tabela CLIENTES.
SELECT MAX(DT_NASCIMENTO),
 MIN(DT_NASCIMENTO)
FROM clientes;
MAX MIN
16/03/1971 00:00 01/01/1965 00:00
A função agregada que permite obter o desvio padrão de um determinado número é iden-
tificada como STDDEV(x). O desvio padrão é uma função estatística, definido como raiz quadra-
da da variância. 
Um exemplo prático é o uso da função STDDEV(x) para obter o desvio padrão dos valores 
da coluna PRECO da tabela PRODUTOS. Veja:
SELECT STDDEV(preco)
FROM produtos;
STDDEV
11.0896302572459215
Claretiano - Centro Universitário
171© U4 – SQL – Uma Linguagem de Consulta
A função SUM(x) permite somar todos os valores presentes em x, retornando a somatotal. O exemplo a seguir realiza o somatório dos valores atrelados à coluna PRECO da tabela 
PRODUTOS.
SELECT SUM(preco) AS "SOMA TOTAL DA COLUNA"
FROM produtos;
SOMA TOTAL DA COLUNA
236.77
A variância é uma função estatística definida como a dispersão ou a variação de um grupo 
de números em uma amostra, ou seja, é equivalente ao quadrado do desvio padrão. A função 
agregada SQL utilizada para obter a variância de um número qualquer e/ou de valores associa-
dos a uma determinada coluna é identificada como VARIANCE(x). Similar ao exemplo anterior, a 
coluna PRECO será utilizada para extrairmos a variância dos valores vinculados a essa coluna da 
tabela PRODUTOS. Acompanhe:
SELECT VARIANCE(preco) AS "VARIÂNCIA DA COLUNA"
FROM produtos;
VARIÂNCIA DA COLUNA
122.979899242424242
Manipulando Data e Hora
O tipo de dado date armazena o século, todos os quatro dígitos de um ano, o mês, o dia, a 
hora, o minuto e o segundo. Já o tipo timestamp armazena o século, todos os quatro dígitos de 
um ano, o mês, o dia, a hora, o minuto e o segundo, tendo como vantagem o armazenamento 
de frações de segundo e fuso horário.
Utilizar datas no padrão ANSI em instruções SQL é conveniente, pois permite que tais ins-
truções possam ser executadas em qualquer SGBD, independente do fabricante.
As funções TO_CHAR(x, string) e DATE são utilizadas para realizar a conversão de uma de-
terminada data/hora em uma string e vice-versa. A função DATE sem parênteses realiza a forma-
tação de uma sequência de caracteres em um determinado formato, esse indicado à sua direita. 
No exemplo a seguir, TO_CHAR(x, string) converte a data associada à coluna DT_NASCIMENTO 
da tabela CLIENTES em uma string com o formato MONTH DD, YYYY.
SELECT id_cliente,
 TO_CHAR(dt_nascimento, 'MONTH DD YYYY')
FROM clientes;
ID_CLIENTE TO_CHAR
1 JANUARY 01 1965
3 MARCH 16 1971
4
5 MAY 20 1970
6 JANUARY 01 1970
2 FEBRUARY 05 1968
© Banco de Dados172
O próximo exemplo obtém a data e a hora atual do servidor de BD utilizando a função 
NOW(). Na sequência é realizada a conversão dessa data e hora em uma string usando a função 
TO_CHAR() com o formato de 24 horas.
SELECT TO_CHAR(now(), 
 'MONTH DD YYYY, HH24:MI:SS');
TO_CHAR
JANUARY 29 2010, 17:38:16
Agora, converteremos a data 5 de fevereiro de 1967 em uma string com o formato MON-
TH DD, YYYY, utilizando em conjunto a função TO_CHAR() e DATE. Veja a seguir:
SELECT TO_CHAR(DATE('05-02-1967'), 
 'MONTH DD, YYYY');
TO_CHAR
FEBRUARY 05, 1967
A função DATE também pode ser utilizada em conjunto com os operadores relacionais. Por 
exemplo, imagine que desejamos recuperar todos os CLIENTES que possuem data de nascimen-
to (coluna DT_NASCIMENTO) posterior à data de 01 janeiro de 1971. A instrução SQL exemplifi-
ca o uso da função DATE que resolveria nosso problema: 
SELECT nm_cliente,
 dt_nascimento 
FROM clientes
WHERE dt_nascimento > DATE '1971-01-01';
nm_cliente dt_nascimento
Marcelo 16/03/1971 00:00
A função EXTRACT() é responsável por extrair, por exemplo, o dia, o mês, o ano, a hora, o 
minuto e o segundo de uma determinada data ou hora. No próximo exemplo, observaremos o 
uso da função EXTRACT() para obter o dia, mês e ano da data de nascimento dos registros asso-
ciados à coluna nomeada de DT_NASCIMENTO da tabela CLIENTES. Acompanhe:
SELECT dt_nascimento,
 EXTRACT(day FROM DT_NASCIMENTO) AS Dia,
 EXTRACT(month FROM DT_NASCIMENTO) AS Mês,
 EXTRACT(year FROM DT_NASCIMENTO) AS Ano
FROM clientes;
dt_nascimento dia mês ano
01/01/1965 00:00 1 1 1965
16/03/1971 00:00 16 3 1971
20/05/1970 00:00 20 5 1970
01/01/1970 00:00 1 1 1970
05/02/1968 00:00 5 2 1968
Claretiano - Centro Universitário
173© U4 – SQL – Uma Linguagem de Consulta
Esse exemplo também explora a função EXTRACT(). Observe as horas, minutos e segundos 
do horário atual do sistema, obtido por meio da função NOW():
SELECT now(),
 EXTRACT(hour FROM now()) AS Hora,
 EXTRACT(minute FROM now()) AS Minuto,
 EXTRACT(second FROM now()) AS Segundo;
now hora minuto Segundo
2011-11-12 15:14:15.786-03 15 14 15.786
A função AGE(), por sua vez, retorna a diferença de tempo entre duas datas. Para exempli-
ficar o uso dessa função, utilizaremos duas datas (coluna DT_NASCIMENTO e '2007-09-15') para 
que seja retornada a diferença de tempo entre elas. Veja a seguir:
SELECT nm_cliente, 
 AGE('2011-12-31', dt_nascimento) 
FROM clientes;
nm_cliente age
João 46 years 11 mons 30 days
Marcelo 40 years 9 mons 15 days
Henrique
Dolores 41 years 7 mons 11 days
Frederico 41 years 11 mons 30 days
Silvia 43 years 10 mons 26 days
Agrupando Tuplas/Linhas
Imagine que é preciso obter o preço médio dos diferentes tipos de produtos da tabela 
PRODUTOS. Para facilitar essa tarefa, a cláusula GROUP BY deverá ser utilizada para agrupar as 
tuplas/linhas semelhantes, ou seja, GROUP BY permite agrupar tuplas/linhas em uma tabela e 
obter alguma informação sobre esses grupos de tuplas/linhas. Pensemos em um exemplo em 
que a cláusula GROUP BY é utilizada para agrupar tuplas/linhas em blocos com um valor comum 
de coluna, agrupando as tuplas/linhas da tabela PRODUTOS em blocos com o mesmo valor de 
ID_TIPO_PRODUTO. Acompanhe a seguir:
SELECT id_tipo_produto
FROM produtos
GROUP BY id_tipo_produto;
id_tipo_produto
4
1
3
2
Outro exemplo é imaginar várias colunas sendo utilizadas, em que as colunas ID_PRODU-
TO e ID_CLIENTE da tabela COMPRAS são incluídas na cláusula GROUP BY. Veja:
© Banco de Dados174
SELECT id_produto, 
 id_cliente
FROM compras
GROUP BY id_produto, id_cliente;
id_produto id_cliente
4 1
2 2
3 1
1 2
1 1
Mais um exemplo é a cláusula GROUP BY sendo mesclada com a função agregada COUNT(x), 
permitindo efetuar o cálculo no grupo de tuplas/linhas em cada bloco, retornando um valor por 
bloco. O resultado é o número de tuplas/linhas com o mesmo valor de ID_TIPO_PRODUTO da 
tabela PRODUTOS. Observe:
SELECT id_tipo_produto,
 COUNT(id_produto) AS "Total por Tipo de Produto"
FROM produtos
GROUP BY id_tipo_produto
ORDER BY id_tipo_produto;
id_tipo_produto Total por Tipo de Produto
1 2
2 4
3 2
4 3
1
No próximo exemplo, GROUP BY se junta à função agregada AVG(x). Elas são utilizadas 
para obter o preço médio dos diferentes tipos de produtos da tabela PRODUTOS.
SELECT id_tipo_produto,
 AVG(preco) AS "Média dos Preços"
FROM produtos
GROUP BY id_tipo_produto
ORDER BY id_tipo_produto;
id_tipo_produto Média dos Preços
1 24.9750000000000000
2 26.2200000000000000
3 13.2400000000000000
4 13.9900000000000000
13.4900000000000000
A utilização incorreta das chamadas funções agregadas ocorre quando a consulta contém 
uma função agregada e recupera colunas não inseridas dentro da função agregada. Essas colu-
nas devem ser colocadas em uma cláusula GROUP BY. Para ilustrar o uso incorreto das chamadas 
Claretiano - Centro Universitário
175© U4 – SQL – Uma Linguagem de Consulta
funções agregadas, tentaremos recuperar a coluna ID_TIPO_PRODUTO e AVG(preco) e omitir 
uma cláusula GROUP BY para o ID_TIPO_PRODUTO, gerando, assim, uma mensagem de erro, 
conforme apresentado na Figura 15: 
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos;
Figura 15 Utilização inadequada da cláusula GROUP BY.
Portanto, quando uma consulta contém uma função agregada e recupera colunas não 
inseridas dentro de uma função agregada, essas colunas devem ser colocadas em uma cláusula 
GROUP BY. 
Também não é permitido utilizar a função agregada para limitar uma cláusula WHERE, 
como podemos identificar na mensagem de erro (Figura 16) gerada a partir da consulta a seguir:
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
WHERE AVG(preco) > 20
GROUP BY id_tipo_produto;
Figura 16 Erro pertinente o uso impróprio da função agregada na cláusula WHERE.
A cláusula HAVING é usada para filtrar grupos de tuplas/linhas e inserida posteriormente à 
cláusula GROUP BY. Uma observação importante é que GROUP BY pode ser usada sem HAVING, 
mas HAVINGsempre deve ser usada em conjunto à GROUP BY. 
Como exemplo, suponha que seja necessário recuperar os tipos de produtos que têm pre-
ços médios maiores que R$ 20,00. Nesse caso:
© Banco de Dados176
• GROUP BY é utilizado para agrupar as tuplas/linhas em blocos com o mesmo valor de 
ID_TIPO_PRODUTO.
• HAVING é utilizado para limitar os resultados retornados aos grupos que têm preços 
médios superiores a R$ 20,00.
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
GROUP BY id_tipo_produto
HAVING AVG(preco)> 20;
id_tipo_produto Avg
1 24.9750000000000000
2 26.2200000000000000
No próximo exemplo, as cláusulas WHERE e GROUP BY serão mescladas em uma mesma 
consulta, simultaneamente. Primeiro, a cláusula WHERE filtra as tuplas/linhas retornadas. Pos-
teriormente, a cláusula GROUP BY agrupa as tuplas/linhas restantes em blocos, ou seja:
• WHERE filtra as tuplas/linhas da tabela PRODUTOS, selecionando apenas os produtos 
cujo valor do preço seja inferior a R$ 15,00.
• GROUP BY agrupa as tuplas/linhas restantes pela coluna ID_TIPO_PRODUTO.
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
WHERE preco < 15
GROUP BY id_tipo_produto
ORDER BY id_tipo_produto;
id_tipo_produto AVG
2 14.4500000000000000
3 13.2400000000000000
4 12.9900000000000000
13.4900000000000000
Para finalizar os exemplos aplicados no agrupamento de tuplas/linhas, as cláusulas WHE-
RE, GROUP BY e HAVING serão utilizadas juntas em uma única consulta. Primeiro, a cláusula 
WHERE filtra as tuplas/linhas; em seguida, a cláusula GROUP BY agrupa as tuplas/linhas restan-
tes em blocos e, finalmente, a cláusula HAVING filtra os grupos de tuplas/linhas.
• WHERE filtra as tuplas/linhas da tabela PRODUTOS, selecionando os produtos cujo pre-
ço seja menor que R$ 45,00.
• GROUP BY agrupa as tuplas/linhas restantes pela coluna ID_TIPO_PRODUTO.
• HAVING filtra os grupos de tuplas/linhas, selecionando aqueles cujo preço médio seja 
superior a R$ 13,00.
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
WHERE preco < 15
Claretiano - Centro Universitário
177© U4 – SQL – Uma Linguagem de Consulta
GROUP BY id_tipo_produto
HAVING AVG(preco) > 13
ORDER BY id_tipo_produto;
id_tipo_produto AVG
2 14.4500000000000000
3 13.2400000000000000
13.4900000000000000
Subconsultas
Basicamente, existem dois tipos de subconsultas, como detalharemos a seguir:
• Única tupla/linha: retornam zero ou uma tupla/linha para a instrução SQL externa. 
Existe um caso especial de subconsulta de uma única tupla/linha que contém exata-
mente uma coluna, a qual é chamada de subconsulta escalar.
• Várias tuplas/linhas: retornam uma ou mais tuplas/linhas para a instrução SQL externa.
Além disso, dentre as subconsultas que podem retornar uma ou várias tuplas/linhas, três 
tipos são identificadas como:
• Correlacionadas: referenciam uma ou mais colunas na instrução SQL externa. Elas são 
chamadas de subconsultas correlacionadas porque são relacionadas à instrução SQL 
externa por meio das mesmas colunas.
• Aninhadas: inseridas dentro de outra subconsulta. É permitido aninhar subconsultas 
até uma profundidade de 255.
• Várias colunas: retornam mais de uma coluna para a instrução SQL externa.
Uma subconsulta de uma única tupla/linha pode ser inserida em uma cláusula WHERE, 
HAVING ou FROM de uma instrução SELECT. Imagine que é necessário recuperar os registros de 
NM_CLIENTE e SOBRENOME da tabela CLIENTES, cujo valor do SOBRENOME corresponda, por 
exemplo, a Ribeiro. A seguinte instrução SQL poderia ser utilizada:
SELECT nm_cliente,
 sobrenome
FROM clientes
WHERE id_cliente = (SELECT id_cliente
 FROM clientes
 WHERE sobrenome = 'Ribeiro');
nm_cliente sobrenome
Marcelo Ribeiro
Analisando essa consulta, podemos observar que a subconsulta na cláusula WHERE é:
SELECT id_cliente
FROM clientes
WHERE sobrenome = 'Ribeiro';
id_cliente
3
© Banco de Dados178
Essa subconsulta é executada primeiro (e apenas uma única vez), retornando o ID_CLIEN-
TE da coluna cujo valor do SOBRENOME corresponda a Ribeiro. O valor do ID_CLIENTE para essa 
tupla/linha é 3, o qual é passado para a cláusula WHERE da consulta externa.
É possível utilizar outros operadores de comparação (<>, <, >, <= e >=) em uma subcon-
sulta de uma única tupla/linha, por exemplo, para obter o preço médio dos produtos, sendo ele 
passado para a cláusula WHERE da consulta externa. A consulta interna retorna os valores de 
ID_PRODUTO, NM_PRODUTO e PRECO dos produtos cujo preço seja maior do que a média de 
preços. Acompanhe:
SELECT id_produto,
 nm_produto, 
 preco
FROM produtos
WHERE preco > (SELECT AVG(preco)
 FROM produtos);
id_produto nm_produto preco
1 Ciência Moderna 19.95
2 Química 30.00
3 Supernova 25.99
6 Arquivos Z 49.99
O exemplo a seguir apresenta a decomposição da consulta anterior, executando a subcon-
sulta separadamente:
SELECT AVG(preco)
FROM produtos;
AVG
19.7308333333333
Podemos observar que essa subconsulta é um exemplo de subconsulta escalar, pois re-
torna exatamente uma tupla/linha contendo apenas uma coluna. O valor retornado por uma 
subconsulta escalar é tratado como um único valor escalar.
Existe também a possibilidade de inserir uma subconsulta na cláusula HAVING de uma 
consulta externa, permitindo filtrar grupos de tuplas/linhas com base no resultado retornado 
por sua subconsulta. Como exemplo, recuperaremos o valor do ID_TIPO_PRODUTO e o preço 
médio dos produtos cujo preço médio seja inferior ao preço correspondente aos produtos. Veja:
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
GROUP BY id_tipo_produto
HAVING AVG(preco) < (SELECT MAX(preco)
 FROM produtos)
ORDER BY id_tipo_produto;
id_tipo_produto AVG
1 24.975000000000000
2 26.220000000000000
Claretiano - Centro Universitário
179© U4 – SQL – Uma Linguagem de Consulta
id_tipo_produto AVG
3 13.240000000000000
4 13.990000000000000
13.490000000000000
As consultas identificadas como in line são aquelas que permitem inserir uma subconsulta 
na cláusula FROM de uma consulta externa. Para ilustrar essa técnica, a próxima instrução SQL 
recuperará os registros pertinentes às colunas ID_PRODUTO e NM_PRODUTO da tabela PRODU-
TOS, cujo valor da coluna ID_PRODUTO seja inferior ao número três.
SELECT id_produto, nm_produto
FROM (SELECT *
 FROM produtos
 WHERE id_produto < 3) AS Interna;
No que diz respeito à cláusula FROM da consulta externa, a saída da subconsulta é apenas 
outra fonte de dados.
No próximo exemplo, dotado de maior complexidade, recuperamos os valores correspon-
dentes às colunas ID_PRODUTO e PRECO da tabela PRODUTOS na consulta externa. A subcon-
sulta recupera o número de vezes que um determinado produto foi comprado:
SELECT produtos.id_produto,
 preco,
 Dados_Compra.Contagem_Produto
FROM produtos, (SELECT id_produto,
 COUNT(id_produto) AS Contagem_Produto
 FROM compras
 GROUP BY id_produto) AS Dados_Compra
WHERE produtos.id_produto = Dados_Compra.id_produto;
id_produto preco contagem_produto
4 13.95 1
1 19.95 2
3 25.99 1
2 30.00 1
Uma consulta de várias tuplas/linhas retorna uma ou mais tuplas/linhas para uma instru-
ção SQL externa. Os operadores IN, ANY e ALL são utilizados para realizar o tratamento de uma 
subconsulta que retorna várias tuplas/linhas, permitindo verificar se o valor de uma coluna está 
contido em uma lista de valores.
A lista de valores pode vir dos resultados retornados por uma subconsulta. O exemplo a 
seguir utiliza o operador IN para verificar se um valor de ID_PRODUTO da tabela PRODUTOS está 
na lista de valores retornada pela subconsulta.
SELECT id_produto,
 nm_produto
FROM produtos 
WHERE id_produto IN (SELECT id_produto
 FROM produtos
 WHERE nm_produto LIKE '%e%');
© Banco de Dados180
id_produto nm_produto
1 Ciência Moderna
3 Supernova
4 Tanque de Guerra
7 2412: O Retorno
9 De outro planeta
12Yell criativo
13 My Front Line
No próximo exemplo, é utilizado o operador NOT IN para executar a lógica oposta de IN, 
ou seja, obter os produtos que não estão na tabela COMPRAS.
SELECT id_produto,
 nm_produto
FROM produtos 
WHERE id_produto NOT IN (SELECT id_produto
 FROM compras);
id_produto nm_produto
6 Arquivos Z
7 2412: O Retorno
8 Força G
9 De outro planeta
10 Música clássica
11 Pop 3
12 Yell criativo
13 My Front Line
O operador ANY é utilizado para comparar um valor com qualquer valor presente em uma 
lista. Podemos, ainda, inserir um operador (=, <>, >, <, <= ou >=) antes de ANY. Para exemplificar 
sua aplicabilidade, recuperaremos os funcionários cujo salário seja menor do que qualquer um 
dos salários mais baixos da tabela GRADES_SALARIOS. Observe:
SELECT id_funcionario,
 nm_funcionario,
 salario
FROM funcionarios
WHERE salario < ANY (SELECT salario_minimo
 FROM grades_salarios);
id_funcionario nm_funcionario salario
2 Rubens 600000
3 Frederico 150000
4 Susana 500000
Por sua vez, o operador ALL é utilizado para comparar um valor com todos os valores pre-
sentes em uma lista. Semelhante ao operador ANY, ALL também permite inserir um operador (=, 
<>, >, <, <= ou >=) antes dele. Modificamos o exemplo anterior para obter os funcionários cujo 
salário seja superior a todos os salários mais altos da tabela GRADES_SALARIOS. Veja a seguir:
Claretiano - Centro Universitário
181© U4 – SQL – Uma Linguagem de Consulta
SELECT id_funcionario,
 nm_funcionario,
 salario
FROM funcionarios
WHERE salario > ALL (SELECT salario_maximo
 FROM grades_salarios);
Como podemos identificar, não existe nenhum funcionário que tenha o salário maior do 
que o salário mais alto da tabela GRADES_SALARIOS.
Quanto às subconsultas que manipulam várias tuplas/linhas, existe ainda a possibilida-
de de escrevermos subconsultas que retornam várias colunas. Por exemplo, suponha que seja 
necessário recuperarmos os produtos com o menor preço para cada grupo de tipo de produto. 
Nesse caso, são retornados o valor correspondente ao ID_TIPO_PRODUTO e o valor do PRECO 
mínimo para cada grupo de produtos, onde os mesmos são comparados com os valores ID_
TIPO_PRODUTO e PRECO para cada produto na cláusula WHERE da consulta externa.
SELECT id_produto,
 id_tipo_produto,
 nm_produto, 
 preco
FROM produtos
WHERE (id_tipo_produto, preco) IN (SELECT id_tipo_produto,
 MIN(preco)
 FROM produtos
 GROUP BY id_tipo_produto);
id_produto id_tipo_produto nm_produto preco
1 1 Ciência Moderna 19.95
4 2 Tanque de Guerra 13.95
9 3 De outro planeta 12.99
10 4 Música clássica 10.99
Uma subconsulta considerada correlacionada referencia uma ou mais colunas na instru-
ção SQL. São nomeadas de correlacionadas, pois são vinculadas à instrução SQL externa por 
meio das mesmas colunas. A subconsulta correlacionada é executada uma vez para cada tu-
pla/linha na consulta externa, diferenciando-se da subconsulta não correlacionada, a qual é 
executada apenas uma única vez antes da execução da consulta externa. Esse tipo de consulta 
também nos permite trabalhar com valores nulos. Por exemplo, para o uso de uma subconsulta 
correlacionada, recuperaremos todos os produtos que possuem preço maior do que a média 
para o tipo de produto. Veja a seguir:
SELECT id_produto,
 id_tipo_produto,
 nm_produto,
 preco
FROM produtos externa
WHERE preco > (SELECT AVG(preco)
 FROM produtos interna
 WHERE interna.id_tipo_produto = externa.id_tipo_produto);
© Banco de Dados182
id_produto id_tipo_produto nm_produto preco
2 1 Química 30.00
6 2 Arquivos Z 49.99
8 3 Força G 13.49
11 4 Pop 3 15.99
12 4 Yell criativo 14.99
Utilizamos o apelido externa para rotular a consulta externa e o apelido interna para a 
subconsulta interna. A referência à coluna ID_TIPO_PRODUTO nas partes interna e externa é o 
que torna a subconsulta interna correlacionada à consulta externa. Em uma subconsulta corre-
lacionada, cada tupla/linha da consulta externa é passada por vez para a subconsulta.
A subconsulta lê uma tupla/linha de cada vez da consulta externa e a aplica na subconsulta 
até que todas as tuplas/linhas da consulta externa sejam processadas. Em nosso exemplo, a con-
sulta externa recupera cada tupla/linha da tabela PRODUTOS e passa para a consulta interna. 
Cada tupla/linha é lida pela consulta interna, a qual calcula o preço médio de cada produto onde 
o valor de ID_TIPO_PRODUTO na consulta interna corresponda ao valor de ID_TIPO_PRODUTO 
na consulta externa.
Os operadores EXISTS e NOT EXISTS podem ser utilizados em uma subconsulta correlacio-
nada. O operador EXISTS verifica a existência de tuplas/linhas retornadas por uma subconsulta. 
Embora você possa usar EXISTS em subconsultas não correlacionadas, em geral ele é utilizado 
em subconsultas correlacionadas. O operador NOT EXISTS executa a lógica oposta de EXISTS. 
Como exemplo do uso do operador EXISTS em uma subconsulta, recuperaremos os funcionários 
que gerenciam outros funcionários. Acompanhe:
SELECT id_funcionario,
 nm_funcionario
FROM funcionarios externa
WHERE EXISTS (SELECT id_funcionario
 FROM funcionarios interna
 WHERE interna.id_gerente = externa.id_funcionario);
id_funcionario nm_funcionario
1 Jaime
2 Rubens
Como EXISTS apenas verifica a existência de tuplas/linhas retornadas pela subconsulta, 
uma subconsulta não precisa retornar uma coluna (ela pode retornar um valor literal), e essa 
característica pode melhorar o desempenho da consulta. Agora, reescreveremos o exemplo an-
terior com a subconsulta retornando o valor literal 1.
SELECT id_funcionario,
 nm_funcionario
FROM funcionarios externa
WHERE EXISTS (SELECT 1
 FROM funcionarios interna
 WHERE interna.id_gerente = externa.id_funcionario); 
Claretiano - Centro Universitário
183© U4 – SQL – Uma Linguagem de Consulta
id_funcionario nm_funcionario
1 Jaime
2 Rubens
Independente de a subconsulta retornar uma ou mais tuplas/linhas, o operador EXISTS 
retornará verdadeiro. Caso a subconsulta não retorne uma tupla/linha, EXISTS retornará falso.
Para demonstrar o uso do NOT EXISTS, a próxima instrução SQL recuperará os produtos 
que não foram comprados. Veja:
SELECT id_produto,
 nm_produto
FROM produtos externa
WHERE NOT EXISTS (SELECT 1
 FROM compras interna
 WHERE interna.id_produto = externa.id_produto); 
id_produto nm_produto
6 Arquivos Z
7 2412: O Retorno
8 Força G
9 De outro planeta
10 Música clássica
11 Pop 3
12 Yell criativo
13 My Front Line
Portanto, o operador EXISTS verifica a existência de tuplas/linhas, enquanto IN verifica os 
valores reais. É importante comentar que EXISTS oferece um desempenho melhor em subcon-
sultas, se comparado com o operador IN.
É possível, ainda, aninharmos subconsultas dentro de outras subconsultas até uma pro-
fundidade de 255 subconsultas. Essa técnica deve ser utilizada com moderação, pois o uso de 
junções de tabelas reduz o desempenho da consulta. Para exemplificar o uso de subconsultas 
aninhadas, observe a próxima instrução SQL, que contém três consultas (uma subconsulta ani-
nhada, uma subconsulta e a consulta externa).
SELECT id_tipo_produto,
 AVG(preco)
FROM produtos
GROUP BY id_tipo_produto
HAVING AVG(preco) < (SELECT MAX(preco)
 FROM produtos
 WHERE id_tipo_produto IN (SELECT id_produto
 FROM compras
 WHERE quantidade > 1)
 GROUP BY id_tipo_produto)
ORDER BY id_tipo_produto; 
© Banco de Dados184
id_tipo_produto AVG
1 24.9750000000000000
2 26.2200000000000000
3 13.2400000000000000
4 13.9900000000000000
13.4900000000000000Para finalizar o uso de subconsultas, é possível, em uma instrução UPDATE, definir uma 
coluna com o resultado retornado por uma subconsulta de uma única tupla/linha. Por exem-
plo, definir o salário do funcionário cujo número (ID_FUNCIONARIO) corresponda ao Número 4 
como a média dos níveis salariais altos retornados por uma subconsulta:
UPDATE funcionarios
 SET salario = (SELECT AVG(salario_maximo)
 FROM grades_salarios)
WHERE id_funcionario = 4; 
O exemplo a seguir utiliza as tuplas/linhas retornadas por uma subconsulta na cláusula 
WHERE de uma instrução DELETE, removendo o funcionário cujo valor salarial seja maior do que 
a média dos níveis salariais altos. Veja a seguir:
DELETE 
FROM funcionarios
WHERE salario > (SELECT AVG(salario_maximo)
 FROM grades_salarios);
9. ESTRUTURA DA LINGUAGEM SQL – DDL
Neste tópico, estudaremos como modificar a estrutura das tabelas. 
Modificando a Estrutura das Tabelas
Quando criamos uma tabela qualquer e na sequência, constatamos que cometemos al-
gum tipo de equívoco, ou se, eventualmente, torna-se imprescindível modificar a estrutura da 
mesma, você, normalmente, poderá remover a tabela e criá-la novamente. 
Entretanto, esta não é uma alternativa muito conveniente, sobretudo se a tabela já con-
tiver dados, ou se a tabela é referenciada por outros objetos de banco de dados (por exemplo, 
uma restrição de chave estrangeira). Nesses casos, o PostgreSQL fornece uma gama de coman-
dos para realizar as modificações em tabelas existentes. Percebe-se de que este conceito é to-
talmente distinto se compararmos com as alterações de dados contidos na tabela: nesse tópico 
estamos interessados exclusivamente em alterar a definição, ou estrutura, de uma determinada 
tabela.
Por meio dos comandos pertinentes a DDL, podemos:
• adicionar e remover colunas;
• adicionar e remover restrições;
• alterar valores configurados como padrão (default);
• alterar tipos de dados (domínio) de uma determinada coluna;
Claretiano - Centro Universitário
185© U4 – SQL – Uma Linguagem de Consulta
• renomear colunas; 
• renomear tabelas.
Basicamente, todas essas ações são implementadas utilizando o comando ALTER TABLE.
Adicionando uma Coluna 
Para adicionarmos uma determinada coluna em uma tabela qualquer, utilizamos o coman-
do exemplificado a seguir:
ALTER TABLE tb_produtos
ADD COLUMN descricao_produto TEXT;
A nova coluna intitulada de descricao_produto será adicionada na tb_produtos, com valores 
nulos (NULL), caso você não especifique uma cláusula DEFAULT.
Eventualmente, você poderá, simultaneamente, adicionar uma restrição (CONSTRAINT) 
de verificação (CHECK) para a coluna, conforme sintaxe apresentada a seguir:
ALTER TABLE tb_produtos
ADD COLUMN descricao_produto TEXT CHECK (descricao_produto <> '');
No caso anterior, uma nova coluna é adicionada na tb_produtos, paralelamente a inclusão 
de uma restrição de verificação, ou seja, a restrição CHECK garantirá que os valores associados a 
essa nova coluna, não poderão ser valores nulos.
É importante mencionar que, essa restrição de checagem poderia ser adicionar no mo-
mento da criação da tabela (CREATE TABLE). Apenas tenha em mente de que o valor padrão 
(DEFAULT), obrigatoriamente, deverá satisfazer as restrições indicadas ou a inclusão da coluna 
irá acarretar em falha. Normalmente, você poderá adicionar as restrições posteriormente ao 
definir uma nova coluna.
Removendo uma Coluna
Para remover uma coluna específica, por exemplo, remover a coluna nomeada de descri-
cao_produto, adicionada anteriormente na tb_produtos, utilize o comando a seguir:
ALTER TABLE tb_produtos
DROP COLUMN descricao_produto;
Repare que, os dados presentes na coluna, ora removida, desaparecem, juntamente com 
as eventuais restrições presentes na tabela e vinculadas à coluna descricao_produto.
É permitida a remoção em cascata, ou seja, remover eventuais dependências vinculadas a 
coluna, adicionando CASCADE, conforme apresentado a seguir:
ALTER TABLE tb_produtos
DROP COLUMN descricao_produto CASCADE;
Adicionando uma Restrição (Constraint)
Para incluir uma restrição qualquer em uma tabela, utilizamos as sintaxes a seguir. Por 
exemplo, imagine a necessidade de adicionar uma restrição de checagem na coluna chamada 
de nm_produto para certificar-se de que não será aceito nomes de produtos em branco, e ou 
nulos, para essa coluna.
© Banco de Dados186
ALTER TABLE tb_produtos ADD CHECK (nm_produto <> '');
Como outro exemplo, podemos considerar a necessidade de adicionar uma restrição de 
unicidade à coluna intitulada de nro_produto, conforme comando a seguir:
ALTER TABLE tb_produtos 
ADD CONSTRAINT nome_restricao
UNIQUE (nr_produto);
Note que associamos um nome para essa restrição (nome_restricao), promovendo faci-
lidades no que tange eventuais futuras manutenções aplicadas a essa restrição em particular. 
Quando não identificamos as restrições impostas às tabelas, o SGBD se encarrega de nomeá-las, 
entretanto, fazendo uso de nomenclaturas não tão amigáveis, mesclando números e letras.
Em nosso próximo exemplo, adicionaremos uma restrição de chave-estrangeira, associada 
a coluna id_grupo_produto, conforme apresentado a seguir:
ALTER TABLE tb_produtos
ADD FOREIGN KEY (id_grupo_produto)
REFERENCES tb_grupos_produtos;
Para adicionar uma restrição não-nulo, que também pode ser produzida como uma restri-
ção de tabela, faça uso da seguinte sintaxe:
ALTER TABLE tb_produtos
ALTER COLUMN nr_produto SET NOT NULL;
A restrição não-nulo anterior, será verificada imediatamente, sendo assim, os dados pre-
sentes na tabela e, especificamente vinculados a essa coluna, devem satisfazer a restrição antes 
que ela possa ser adicionada.
Removendo uma Restrição
Para remover uma restrição, é necessário conhecer previamente o seu nome. Se você 
forneceu-lhe um nome, no momento da sua criação, essa tarefa torna-se mais fácil. Caso contrá-
rio, o SGBD será responsável por gerar um nome, normalmente, não familiar, e, você precisará 
descobrir antes de realizar qualquer tipo de manutenção/operação. Eventualmente, o comando 
psql \d nome_tabela poderá ser útil na obtenção dessa informação, inspecionando os detalhes 
das estruturas das tabelas. A seguir, um exemplo de como remover uma restrição, ora nomeada 
pelo administrador de banco de dados (DBA):
ALTER TABLE tb_produtos
DROP CONSTRAINT nome_restricao;
Outro exemplo, imagine a necessidade de remover uma restrição não-nulo da coluna inti-
tulada de nr_produto, essa nomeada de nn_tb_produtos_nm_produto.
ALTER TABLE tb_produtos
DROP CONSTRAINT nn_tb_produtos_nm_produto;
Claretiano - Centro Universitário
187© U4 – SQL – Uma Linguagem de Consulta
Alterando um Valor Padrão de uma Coluna
Para configurar um novo valor padrão atrelado a uma coluna qualquer, o comando a se-
guir poderá ser utilizado. Nesse exemplo, imagine a necessidade de configurar um valor padrão 
para a coluna nomeada de preco.
ALTER TABLE tb_produtos
ALTER COLUMN preco SET DEFAULT 1.99;
Repare que o comando anterior não afetará todas as tuplas existentes na tabela, apenas 
irá alterar o valor padrão para futuras instruções INSERT.
Para remover qualquer valor padrão, você poderá utilizar o comando a seguir:
ALTER TABLE tb_produtos
ALTER COLUMN preco DROP DEFAULT;
O exemplo anterior é basicamente o mesmo que configura o valor padrão para nulo 
(NULL). Entretanto, não é considerado um erro remover um valor padrão que não tenha sido 
definido, sobretudo, pelo valor padrão ser implicitamente o valor nulo.
Alterando o Tipo de Dado de uma Coluna
O comando a seguir poderá ser utilizado para converter uma coluna para um tipo de dado 
distinto. Imagine à necessidade de converter para NUMERIC, precisão (10,2) a coluna, ora iden-
tificada de preco:
ALTER TABLE tb_produtos
ALTER COLUMN preco TYPE NUMERIC(10,2);
A instrução anterior, apenas obterá êxito se cada dado existente na coluna preco for pas-
sível de conversão para o novo tipo, por meio de uma conversão implícita. Caso seja necessária