Sistema de Banco de Dados

Prévia do material em texto

Sistema de Banco de Dados 
Marcio Quirino - 1 
 
SUMÁRIO 
Sistema de Banco de Dados ................................................................................................................. 8 
Definição .................................................................................................................................................... 8 
Propósito .................................................................................................................................................... 8 
1. Histórico dos bancos de dados e suas tecnologias ................................................................ 8 
Definição de Banco De Dados ................................................................................................................... 8 
Evolução dos Sistemas de Informação em Computador ............................................................................ 8 
Era do processamento de dados ............................................................................................................ 8 
Primórdios dos sistemas de banco de dados ....................................................................................... 10 
Estágio atual dos sistemas de informação (na Web) ........................................................................... 11 
Evolução dos Sistemas de Banco De Dados ........................................................................................... 12 
Bancos de dados navegacionais .......................................................................................................... 12 
O modelo relacional de banco de dados .............................................................................................. 12 
Principais SGBDs relacionais ............................................................................................................... 13 
Outros modelos de SGBDs .................................................................................................................. 14 
Verificando o aprendizado ........................................................................................................................ 15 
2. Características dos Sistemas de Banco de Dados (SBD) .................................................... 16 
Diferenças entre sistema de arquivos e sistema de banco de dados....................................................... 16 
Vantagens e desvantagens da abordagem de banco de dados .............................................................. 18 
Papéis em sistemas de bancos de dados ................................................................................................ 19 
Verificando o aprendizado ........................................................................................................................ 21 
3. Arquitetura dos sistemas de gerência de banco de dados (SGBD) ..................................... 21 
Componentes de um sistema de banco de dados ................................................................................... 21 
Módulos de um sistema de gerência de banco de dados ........................................................................ 22 
Um exemplo de SGBD relacional: PostgreSQL ....................................................................................... 25 
Verificando o aprendizado ........................................................................................................................ 27 
Considerações finais ................................................................................................................................ 27 
Referências .............................................................................................................................................. 27 
Explore+ ................................................................................................................................................... 28 
Exercícios ................................................................................................................................................. 29 
Projeto de Banco de Dados: Modelagem Conceitual ......................................................................... 30 
Definição .................................................................................................................................................. 30 
Propósito .................................................................................................................................................. 30 
Preparação ............................................................................................................................................... 30 
Introdução ................................................................................................................................................ 30 
1. Projeto de Banco De Dados .................................................................................................. 30 
Levantamento de requisitos ..................................................................................................................... 31 
Projeto conceitual ..................................................................................................................................... 31 
Outra notação para DER: diagrama de classes UML ........................................................................... 32 
Projeto lógico............................................................................................................................................ 33 
Sistema de Banco de Dados 
Marcio Quirino - 2 
 
Projeto físico............................................................................................................................................. 34 
Resumindo ............................................................................................................................................... 35 
Verificando o aprendizado ........................................................................................................................ 35 
2. Diagrama de Entidade e Relacionamento ............................................................................. 36 
Entidade ................................................................................................................................................... 36 
Relacionamento ....................................................................................................................................... 36 
Autorrelacionamento ............................................................................................................................ 36 
Cardinalidade de relacionamentos ....................................................................................................... 37 
Relacionamento ternário ...................................................................................................................... 38 
Atributo ..................................................................................................................................................... 38 
Cardinalidade em atributo .................................................................................................................... 39 
Atributo obrigatório e monovalorado ..................................................................................... 39 
Atributo composto.................................................................................................................. 39 
Modelo de entidade e relacionamento estendido ................................................................. 39 
Especialização/Generalização ................................................................................................................. 39 
Classificações para especialização/generalização ............................................................................... 40 
Entidade associativa................................................................................................................................ 41 
Resumindo ............................................................................................................................................... 42 
Verificando o aprendizado ........................................................................................................................ 42 
3. Modelagem de Entidades e Relacionamentos ...................................................................... 42 
Objetivos ao construir um DER ................................................................................................................ 42 
Modelagem de Entidades E Relacionamentos ......................................................................................... 43 
Equivalência entre modelos ................................................................................................................. 43 
Modelagem de entidade isolada............................................................................................................... 45 
Quando manter histórico ...................................................................................................................... 45 
Mais sobre modelagem de entidades e relacionamentos ........................................................................ 46 
Resumindo ............................................................................................................................................... 47 
Verificando o aprendizado ........................................................................................................................ 47 
4. Modelagem de atributos......................................................................................................... 48 
Atributo X Entidade .................................................................................................................................. 48 
Atributo X Especialização ......................................................................................................................... 49 
Atributo Opcional ...................................................................................................................................... 49 
Atributo Multivalorado ............................................................................................................................... 50 
Atributo X Redundância ........................................................................................................................... 51 
Atributo Composto .................................................................................................................................... 52 
Resumindo ............................................................................................................................................... 53 
Verificando o aprendizado ........................................................................................................................ 53 
Considerações Finais ............................................................................................................................... 54 
Referências .............................................................................................................................................. 54 
Explore+ ................................................................................................................................................... 54 
Sistema de Banco de Dados 
Marcio Quirino - 3 
 
Exercícios ................................................................................................................................................. 54 
Projeto de Banco de Dados: Modelagem Lógica e Física .................................................................. 56 
Definição .................................................................................................................................................. 56 
Propósito .................................................................................................................................................. 56 
Preparação ............................................................................................................................................... 56 
Introdução ................................................................................................................................................ 56 
1. Modelo Relacional .................................................................................................................. 56 
Componentes de uma tabela ................................................................................................................... 56 
Nome de tabelas .................................................................................................................................. 57 
Colunas de tabelas ............................................................................................................................... 57 
Linhas de tabelas ................................................................................................................................. 58 
Chave Primária ..................................................................................................................................... 58 
Vamos estudar um exemplo de chave primária simples? .................................................... 58 
Chave Estrangeira ................................................................................................................................ 60 
Restrições impostas pela chave estrangeira ........................................................................ 61 
Esquema diagramático de banco de dados relacional ............................................................................. 61 
Esquema textual de banco de dados relacional ................................................................................... 62 
Verificando o aprendizado ........................................................................................................................ 62 
2. Formas Normais ..................................................................................................................... 63 
Normalização ........................................................................................................................................... 63 
Tabela não normalizada ....................................................................................................................... 64 
Primeira Forma Normal (1FN) .................................................................................................................. 66 
Dependência funcional ......................................................................................................................... 67 
Dependência funcional parcial ............................................................................................................. 67 
Segunda Forma Normal (2FN) ................................................................................................................. 68 
Dependência funcional transitiva .......................................................................................................... 70 
Terceira Forma Normal (3FN) .................................................................................................................. 70 
Verificando o aprendizado ........................................................................................................................ 72 
3. Mapeamento conceitual-lógico .............................................................................................. 73 
Mapeamento conceitual-lógico ................................................................................................................. 73 
Regras de mapeamento....................................................................................................................... 73 
Mapeamento de entidades ....................................................................................................................... 73 
Exemplo de mapeamento de entidades: .............................................................................................. 73 
Mapeamento de relacionamentos ............................................................................................................ 74 
Exemplos de mapeamento de relacionamento 1:1: ............................................................................. 75 
Exemplo de mapeamento de relacionamento 1:N: ............................................................................... 76 
Exemplo de mapeamento de relacionamento N:N: .............................................................................. 77 
Exemplo de mapeamento de relacionamento ternário: ........................................................................ 78 
Mapeamento de atributos multivalorados ................................................................................................. 79 
Mapeamento de especialização/generalização ........................................................................................ 80 
Sistema de Banco de Dados 
Marcio Quirino - 4 
 
Exemplos de mapeamento de especialização/generalização: ............................................................. 81 
Verificando o aprendizado ........................................................................................................................ 83 
4. Aspectos físicos para implementação do modelo no SGBD ................................................ 84 
Consultas ................................................................................................................................................. 84 
Transações............................................................................................................................................... 85 
Indexação em banco de dados ................................................................................................................ 85 
Projeto físico em bancos de dados relacionais ........................................................................................ 86 
Consultas e transações de banco de dados......................................................................................... 87 
Frequência de chamada de consultas e transações esperada ............................................................ 88 
Restrições de tempo de consulta e transações .................................................................................... 88 
Frequências esperadas de operações de atualização ......................................................................... 88 
Restrições de exclusividade em colunas da tabela .............................................................................. 88 
Consultas envolvendo mais de uma tabela .............................................................................................. 88 
Desnormalizar para ganhar desempenho ................................................................................................ 89 
Verificando o aprendizado ........................................................................................................................ 90 
Considerações Finais ............................................................................................................................... 90 
Referências .............................................................................................................................................. 90 
Explore+ ................................................................................................................................................... 91 
Exercícios ................................................................................................................................................. 91 
Criação e Manipulação de Objetos no PostgreSQL ........................................................................... 93 
Definição .................................................................................................................................................. 93 
Propósito .................................................................................................................................................. 93 
Preparação ............................................................................................................................................... 93 
Introdução ................................................................................................................................................ 93 
1. Processo de instalação do PostgreSQL ................................................................................ 93 
Breve histórico.......................................................................................................................................... 93 
Arquitetura do PostgreSQL ...................................................................................................................... 94 
Instalação do PostgreSQL no Linux ......................................................................................................... 94 
Instalação do PostgreSQL no Windows ................................................................................................... 95 
Interfaces para interagir com o PostgreSQL ............................................................................................ 98 
Criando databases com o pgAdmin 4 e com o psql ............................................................................. 98 
Verificando o aprendizado ...................................................................................................................... 100 
2. Comandos para criação e alteração de tabelas .................................................................. 100 
Breve histórico da SQL .......................................................................................................................... 100 
Acesso ao PostgreSQL .......................................................................................................................... 100 
Criando um banco de dados .................................................................................................................. 101 
Criando tabelas ...................................................................................................................................... 101 
Tipos de dados ....................................................................................................................................... 102 
Exemplo envolvendo criação de tabelas ............................................................................................ 102 
Gerenciamento de scripts na prática .................................................................................................. 103 
Sistema de Banco de Dados 
Marcio Quirino - 5 
 
SGBD PostgreSQL nos bastidores .................................................................................................... 103 
Alteração de tabela ................................................................................................................................ 104 
Remoção de tabela ............................................................................................................................ 105 
Criação e alteração de tabelas relacionadas ......................................................................................... 105 
Cuidados ao manipular tabelas relacionadas ..................................................................................... 106 
Verificando o aprendizado ......................................................................................................................106 
3. Comandos para manipular linhas nas tabelas .................................................................... 107 
Manipulação de linhas nas tabelas ........................................................................................................ 107 
Modelo para os exemplos .................................................................................................................. 108 
Inserção de linhas em tabela .............................................................................................................. 108 
Mecanismo de chave primária em ação ................................................................................................. 109 
Atualização de linhas em tabela ............................................................................................................. 110 
Atualização de coluna chave primária .................................................................................................... 110 
Remoção de linhas em tabela ................................................................................................................ 111 
Verificando o aprendizado ...................................................................................................................... 112 
4. Comandos de controle de transação ................................................................................... 113 
Transações em banco de dados ............................................................................................................ 113 
Propriedades de uma transação ........................................................................................................ 115 
Estados de uma transação ................................................................................................................. 115 
Transações no PostgreSQL ................................................................................................................... 115 
Um pouco mais sobre atualização temporária ................................................................................... 118 
UM POUCO MAIS SOBRE TRANSAÇÃO DE LEITURA ................................................................... 119 
Verificando o aprendizado ...................................................................................................................... 119 
Considerações finais .............................................................................................................................. 120 
Referências ............................................................................................................................................ 120 
Explore+ ................................................................................................................................................. 120 
Consultas em uma tabela no PostgreSQL ........................................................................................ 121 
Definição ................................................................................................................................................ 121 
Propósito ................................................................................................................................................ 121 
Preparação ............................................................................................................................................. 121 
Introdução .............................................................................................................................................. 121 
1. Consultas com o comando SELECT ................................................................................... 121 
Estrutura básica de um comando SELECT ............................................................................................ 121 
Funções de data e hora ......................................................................................................................... 123 
Exibindo o nome do dia da semana ................................................................................................... 124 
Calculando idade e faixa etária .......................................................................................................... 125 
Funções de resumo ou de agregação .................................................................................................... 125 
Listando resumos em uma linha ......................................................................................................... 126 
Criando tabela a partir de consulta ......................................................................................................... 127 
Criando view a partir de consulta ........................................................................................................... 127 
Sistema de Banco de Dados 
Marcio Quirino - 6 
 
Verificando o aprendizado ...................................................................................................................... 128 
2. Consultas usando a cláusula WHERE ................................................................................ 128 
Cláusula Where e operadores da SQL ................................................................................................... 128 
Recuperando dados com Select/From/Where/Order By ........................................................................ 129 
Recuperando dados com o uso do operador IN ..................................................................................... 130 
Recuperando dados com o uso do operador Between .......................................................................... 130 
Recuperando dados com o uso do operador Like .................................................................................. 131 
Recuperando dados com o uso do operador NULL ............................................................................... 132 
Recuperando dados usando ordenação dos resultados ........................................................................ 133 
Verificando o aprendizado ...................................................................................................................... 134 
3. Consultas envolvendo agrupamento de dados ................................................................... 134 
Consultas com GROUP BY e HAVING .................................................................................................. 134 
Grupo de dados...................................................................................................................................... 135 
Grupo de dados com GROUP BY .......................................................................................................... 136 
Grupo de dados com GROUP BY e HAVING ........................................................................................ 138 
Verificando o aprendizado ...................................................................................................................... 139 
Considerações finais .............................................................................................................................. 139 
Referências ............................................................................................................................................ 140 
Explore+ ................................................................................................................................................. 140 
Consulta Com Várias Tabelas no PostgreSQL ................................................................................. 141 
Definição ................................................................................................................................................ 141 
Propósito ................................................................................................................................................141 
Preparação ............................................................................................................................................. 141 
Introdução .............................................................................................................................................. 141 
1. Consultas envolvendo junções interior e exterior ................................................................ 141 
Operação de junção de tabelas.............................................................................................................. 141 
Operação de produto cartesiano ............................................................................................................ 143 
Junção interna .................................................................................................................................... 144 
Junção externa ................................................................................................................................... 145 
Verificando o aprendizado ...................................................................................................................... 147 
2. Subconsultas aninhadas e correlatas .................................................................................. 148 
Subconsultas .......................................................................................................................................... 148 
Exemplo de tabelas ............................................................................................................................ 148 
Subconsultas aninhadas .................................................................................................................... 149 
Subconsultas correlatas ..................................................................................................................... 151 
Consulta correlacionada com uso de [NOT] EXISTS ......................................................................... 153 
Verificando o aprendizado ...................................................................................................................... 154 
3. Consultas com o uso de operadores de conjunto ............................................................... 155 
Operadores de conjunto ......................................................................................................................... 155 
Consultas com o operador UNION ..................................................................................................... 156 
Sistema de Banco de Dados 
Marcio Quirino - 7 
 
Consultas com o operador INTERSECT ............................................................................................ 158 
Verificando o aprendizado ...................................................................................................................... 160 
Considerações finais .............................................................................................................................. 161 
Referências ............................................................................................................................................ 161 
Explore+ ................................................................................................................................................. 161 
Sistema de Banco de Dados 
Marcio Quirino - 8 
 
Sistema de Banco de Dados 
Sistema de Banco de Dados 
Definição 
Apresentação da evolução histórica dos bancos de dados, abordando as características dos sistemas 
de banco de dados (SBD) e a arquitetura dos sistemas de gerência de banco de dados (SGBD). 
Propósito 
Compreender a origem e as características dos SBDs, bem como suas funcionalidades, vantagens 
e desvantagens, além de conhecer a arquitetura dos SGBDs e os sistemas mais utilizados em bancos de 
dados. 
1. Histórico dos bancos de dados e suas tecnologias 
Definição de Banco De Dados 
Você certamente já leu sobre o termo banco de dados em algum contexto técnico ou geral na mídia 
tradicional ou na internet. 
Mas o que é um banco de dados? 
O termo banco de dados, no sentido técnico, origina-se de database, do inglês, e o livro-texto de 
edição norte-americana mais adotado no mundo o define de maneira simples e direta: “banco de dados é 
uma coleção de dados relacionados” (ELMASRI; NAVATHE, 2019), em que dados são fatos conhecidos que 
podem ser registrados e possuem significado implícito. 
Exemplo 
Nome, data de nascimento, endereço e telefone são dados relacionados entre si, inerentes a uma pessoa 
conhecida em certo contexto. Antes de elaboramos mais essa definição, vamos relembrar um pouco da história dos 
bancos de dados. 
O conceito de banco de dados como uma coleção de dados relacionados sempre existiu como 
componente central dos sistemas de informação. Estes, por sua vez, sempre existiram desde que a 
humanidade se organizou como sociedade. Segundo afirmam Melo, Silva e Tanaka (1998), o que tem 
mudado rapidamente ao longo da história é a tecnologia que permite a sua implementação e que se 
confunde com o próprio conceito de sistemas de informação. 
Assim, antes da existência do computador, bancos de dados existiam sob a forma de registros físicos 
em papel, organizados em pastas dentro de armários, que formavam os arquivos dos sistemas de 
informação, operados manualmente pelos seus usuários. Será que ainda existem sistemas de informação 
desse tipo em pleno século XXI? 
Evolução dos Sistemas de Informação em Computador 
Era do processamento de dados 
Historicamente, o computador, inventado na década de 1940 ao fim da Segunda Guerra Mundial, era 
usado primordialmente como uma máquina para cálculos matemáticos complexos, a exemplo da máquina 
diferencial de Charles Babbage, do século XIX. 
 
Sistema de Banco de Dados 
Marcio Quirino - 9 
 
Charles Babbage 
Charles Babbage (1791-1871) é um dos mais célebres ícones no mundo da computação. As suas notáveis 
contribuições para a área fizeram dele o pioneiro dos computadores. A Máquina Diferencial N. 1 foi a primeira 
calculadora automática a ser inventada e ainda é considerada uma peça única pela precisão que na época apresentava. 
Fonte: Pplware. 
Logo se percebeu que, graças à arquitetura criada pelo seu inventor, John von Neumann, baseada 
em uma unidade central de processamento que armazena programas e dados, o computador também serve 
para o processamento de dados e não apenas para cálculos. 
John von Neumann 
John von Neumann (1903-1957) foi um matemático húngaro, naturalizado norte-americano, considerado o pai 
da Teoria dos Jogos. Seus interesses abrangiam lógica, assuntos militares, computação, economia, entre outros. 
Essa utilidade do computador foi impulsionada com a invenção do disco magnético pela IBM, em 
1957, que o denominou de Dispositivo de Armazenamento de Acesso Direto (DASD, do inglês Direct Acess 
Storage Device). 
Fundamentalmente, o que esse dispositivo – atualmente conhecido como disco rígido e pela sigla 
HD (Hard Disk) – apresentou de novidade, à época, foi a capacidade de leitura de dados externos à unidade 
central de processamento de forma direta, sem a necessidade de leitura sequencial, como em fitas 
magnéticas. 
Com o advento do armazenamento externo em disco rígido, nasceu a era do processamento de 
dados por computador. 
Você já ouviu falar em Centro de Processamento de Dados (CPD), denominação que ainda persiste 
em organizações tradicionais? 
Nessa era, os programas de aplicação, desenvolvidos em uma linguagem de programação 
(usualmente COBOL, em aplicações empresariais, ou Fortran, em aplicações científicas), manipulavam 
dados armazenados em arquivos hospedados em disco magnético, utilizados pelo sistema operacional e 
formando o que se denomina sistema de arquivos. 
A figura a seguir mostra a evolução obtida ao possibilitar que os programas acessassem os dadosexternamente em arquivos no disco (configurando um avanço em relação aos programas que continham 
internamente os próprios dados) para execução em lotes (batch, em inglês), na fase inicial do uso do 
computador. 
Sistema de Banco de Dados 
Marcio Quirino - 10 
 
 
Esse modelo de processamento de dados com sistema de arquivos foi largamente utilizado no início 
do emprego do computador em sistemas de informação empresariais, após o advento do disco magnético, 
persistindo até os dias atuais, nos chamados sistemas legados. Exemplo disso, foi a maior demanda por 
programadores da linguagem COBOL durante a pandemia de COVID-19 para realizar manutenção em 
sistemas da Administração Pública do governo dos EUA. 
Saiba mais 
Para saber mais sobre o aumento da procura por programadores COBOL durante a pandemia de COVID-19, 
não deixe de verificar a indicação feita no Explore + ao fim deste tema. 
Primórdios dos sistemas de banco de dados 
Seguindo na história, o advento dos bancos de dados foi uma evolução natural dos sistemas de 
arquivos. Observe na figura anterior que os programas os quais manipulam os arquivos de dados, além de 
implementarem a lógica da aplicação, têm de conter um módulo para a gerência dos arquivos de dados. 
Esse módulo deve ser repetido em todos os programas que precisam acessar e manipular o mesmo arquivo 
de dados. 
Por exemplo, o departamento de pessoal de uma organização mantém o arquivo com os dados dos 
empregados. Suponha que o departamento de produção também precise usar dados desse arquivo para 
alocar empregados em projetos. Nesse caso, os programas de aplicação que atendem aos dois 
departamentos deverão conter o mesmo módulo de gerência do arquivo de empregados, causando uma 
repetição de código de programação e dificultando a sua manutenção. 
Assim, os sistemas de banco de dados (SBD) vieram para mitigar esse problema, a partir de 1960, 
tirando dos programas de aplicação a responsabilidade de gerenciar os arquivos de dados, tarefa que 
passou a ser delegada a um software intermediário, denominado de sistema de gerência de banco de dados 
(SGBD), como mostra a figura a seguir. 
Essa propriedade dos sistemas de banco de dados é denominada de independência entre dados e 
programas, uma diferença primordial em relação aos sistemas de arquivos. 
Sistema de Banco de Dados 
Marcio Quirino - 11 
 
 
Em outras palavras, ocorreu uma modularização do sistema de informação, com a distribuição de 
responsabilidades entre os programas de aplicação e o SGBD. Os programas de aplicação passaram a se 
ocupar exclusivamente das funcionalidades da aplicação propriamente dita, deixando as tarefas de acesso 
e manipulação dos dados armazenados em disco para o SGBD, um software tipicamente auxiliar, de 
bastidores ou, como se costuma dizer no jargão do mercado, um serviço de back end. 
Atenção 
Perceba a diferença entre o sistema de banco de dados (SBD) e o sistema de gerência de banco de dados 
(SGBD), pois o primeiro é mais amplo, englobando o SGBD, os próprios programas de aplicação e os bancos de dados 
manipulados por eles. 
Neste ponto, cabe um questionamento importante, cada vez mais válido em face dos avanços das 
tecnologias de hardware de memória, tanto de memória principal (RAM) quanto de memória secundária 
(discos magnéticos ou hard disk drives (HDD) e de semicondutores ou solid state drives (SSD)). 
A questão é: qual dos três modelos de sistemas é o mais eficiente para uma aplicação com o mesmo 
volume de dados, ou seja, o modelo monolítico com dados junto dos programas; o modelo com sistemas de 
arquivos; ou o modelo com sistemas de bancos de dados? 
Adiaremos a resposta a essa questão para o final deste módulo. 
Estágio atual dos sistemas de informação (na Web) 
Antes de discorrer sobre o histórico dos SBDs, vale completar a evolução dos sistemas de informação 
até os dias atuais, fortemente influenciada pela revolução tecnológica causada pela World Wide Web no 
final do século XX. 
Com a popularização da interface Web no desenvolvimento das aplicações, surgiram novas 
linguagens de programação e novas formas de armazenamento e acesso a dados em fontes com diferentes 
formatos. Assim, o SGBD das aplicações tradicionais pode ser considerado atualmente como um gênero de 
software básico, com papel intermediário, que denominamos na figura a seguir de middleware, em que se 
incluem servidores de aplicações das diferentes linguagens e ambientes de desenvolvimento Web. 
 
Sistema de Banco de Dados 
Marcio Quirino - 12 
 
Essa figura resume o atual estágio dos sistemas de informação na Web, em que as fontes de dados 
não se restringem a dados estruturados, como em bancos de dados tradicionais, admitindo volumes 
gigantescos em diversos formatos, localizações e velocidade de produção, características marcantes do 
conceito de Big Data. Igualmente, as aplicações via Web são desenvolvidas em uma diversidade de 
plataformas digitais, de smartphones a supercomputadores, que têm em comum a conexão com a internet 
e, em consequência, a computação em nuvem (Cloud Computing). 
Evolução dos Sistemas de Banco De Dados 
Bancos de dados navegacionais 
Há uma controvérsia sobre qual foi o primeiro SGBD implementado e utilizado comercialmente na 
década de 1960. Sabe-se que duas iniciativas independentes ocorreram paralelamente, resultando em dois 
produtos comerciais: 
IDS (Integrated Data System) 
1. Criado por Charles Bachman (1924-2017) no âmbito de um comitê que padronizou a 
linguagem COBOL (CODASYL, de Committee on Data Systems Languages). 
IMS (Information Management Systems) 
1. Criado pela IBM na esteira do sucesso da invenção do disco magnético anos antes. 
O IDS e o IMS tinham em comum a característica de que os dados eram acessados por meio de 
programas que “navegam” de registro em registro pela estrutura dos dados armazenados em disco. Por 
causa dessa característica, atualmente aqueles SGBDs e outros que seguiram a mesma abordagem são 
denominados de navegacionais. 
Observe a diferença entre eles: 
IDS 
1. Usava a estrutura de dados de grafos ou redes, daí a denominação de network databases. 
IMS 
1. Adotava a estrutura de dados de árvores, que é um tipo de grafo mais restrito do que as 
redes, baseado em hierarquias, originando a denominação hierarchical databases. 
Vários SGBDs foram implementados com variantes desses modelos de banco de dados, como o 
DMS (Data Management System) e o IDMS (Integrated Database Management System). Vale relembrar que 
muitos sistemas de informação legados daquela época ainda utilizam esses SGBDs navegacionais, a 
exemplo da demanda por programadores COBOL em meio à pandemia de COVID-19. 
O modelo relacional de banco de dados 
A grande revolução na história dos bancos de dados ocorreu na virada das décadas de 1960 e 1970, 
com a publicação do artigo seminal do matemático pesquisador da IBM, Edgar Codd, intitulado A Relational 
Model of Data for Large Shared Data Banks, que introduziu o modelo relacional de banco de dados. 
Edgar Codd 
Edgar Frank Codd (1923-2003) foi um cientista da computação e matemático americano que inventou o modelo 
de dados relacionais, que levou à criação do banco de dados relacional, um método padrão de recuperação e 
armazenamento de dados do computador. 
O artigo de Codd, uma das obras mais citadas na comunidade da computação em todos os tempos, 
foi o marco do chamado modelo relacional de banco de dados, cuja estrutura de dados, diferentemente dos 
grafos dos bancos de dados navegacionais, é uma função matemática denominada relação. 
Sistema de Banco de Dados 
Marcio Quirino - 13 
 
Codd criou uma Álgebra Relacional e um Cálculo Relacional, nos quais baseou toda a teoria 
matemática das relações em que fundamentou o modelo relacional. Apesar da base teórica do modelo, a 
estrutura de dados subjacente tem o mérito de ser muito simples, pois uma relação nada mais é do que uma 
tabela formada por colunas elinhas, em cujas células estão armazenados os dados, conceito compreensível 
pelo senso comum de qualquer leigo em Matemática ou computação, como podemos ver a seguir. 
 
A solidez da fundamentação matemática do modelo relacional disparou uma série de iniciativas de 
implementação em empresas, como a própria IBM, e no meio acadêmico, principalmente nas universidades 
do estado da Califórnia, onde se localizava o centro de pesquisas da IBM. A partir de então, a IBM patrocinou 
o projeto System R (de Relational), enquanto a Universidade da Califórnia em Berkeley (UCB) deu início à 
implementação acadêmica de um SGBD relacional denominado de Ingres (Interactive Graphics Retrieval 
System). 
Principais SGBDs relacionais 
O projeto System R deu origem ao SGBD comercial da IBM, inicialmente denominado SQL/DS 
(Structured Query Language/Data System), depois renomeado de DB2, atualmente um dos líderes no 
mercado de bancos de dados corporativos, com versões em diferentes plataformas de hardware/software e 
na nuvem. 
Saiba mais 
A linguagem SQL, criada pela IBM como uma linguagem de consulta e manipulação de dados dos bancos de 
dados relacionais, passou a ser conhecida como sinônimo de SGBD relacional, chegando a ser confundida com 
produtos que levam a sigla em seu nome. 
No âmbito comercial, também despontou, como decorrência do sucesso do modelo relacional, o 
desenvolvimento de um SGBD pela empresa inicialmente denominada Software Development Laboratories 
(SDL), depois renomeada Relational Software Inc. (RSI) e, finalmente, Oracle Corporation, nome pelo qual 
é atualmente reconhecido como o SGBD líder do mercado global de banco de dados. 
Em 2010, com a aquisição da Sun Microsystems, uma grande empresa de hardware tradicionalmente 
incentivadora de projetos de software livre, a Oracle incorporou entre seus produtos o MySQL, um SGBD 
relacional de reconhecida liderança na comunidade de desenvolvimento de sistemas para a Web. O SGBD 
MySQL, associado ao sistema operacional Linux, ao servidor Web Apache e à linguagem de programação 
PHP, formou o quarteto de software conhecido pela sigla LAMP, de grande sucesso no desenvolvimento de 
aplicações Web até os dias atuais. 
Na frente acadêmica, o projeto Ingres, da UCB (Universidade da Califórnia, Berkeley) deu origem a 
versões comunitárias mediante licença livre da própria universidade junto com seu sistema operacional Unix, 
denominado BSD (Berkeley Software Distribution). O projeto acadêmico originou um produto comercial de 
mesmo nome, Ingres DBMS, que concorreu diretamente com o Oracle e o SQL/DS nos primórdios dos 
SGBDs relacionais. 
O esforço de desenvolvimento do Ingres envolveu muitos pesquisadores, professores e estudantes, 
os quais acabaram levando o seu código livre em linguagem C para implementação em outros produtos 
Sistema de Banco de Dados 
Marcio Quirino - 14 
 
comerciais, notadamente o SGBD Sybase que, na década de 1990, associou-se à Microsoft, dando origem 
ao SQL Server, atualmente um dos líderes no mercado de bancos de dados relacionais. 
A continuidade do projeto Ingres deu frutos também na área acadêmica com a evolução para um 
modelo de dados além do relacional, estendido com conceitos da programação orientada a objetos, 
denominado Postgres (de Post Ingres). 
Saiba mais 
Após a incorporação da linguagem SQL na década de 1990, o Postgres foi rebatizado como PostgreSQL, 
atualmente reconhecido como o mais avançado SGBD open source do mundo. Para saber mais sobre o PostgreSQL, 
não deixe de verificar a indicação feita no Explore+ ao fim deste tema. 
O PostgreSQL e o MySQL são os SGBDs mais utilizados no aprendizado dos bancos de dados 
relacionais pela sua popularidade e pelo fato de disponibilizarem versões com licença e documentação 
livres. 
Outros modelos de SGBDs 
No ranking de popularidade dos SGBDs, disponibilizado pelo DB-Engines em seu website, destacam-
se, entre os que adotam o modelo relacional: Oracle, MySQL, Microsoft SQL Server, PostgreSQL e IBM 
DB2. 
Cabe observar que esse ranking não trata exclusivamente de SGBDs do modelo relacional de dados. 
Os próprios SGBDs relacionais, mencionados como líderes de mercado, são classificados no ranking como 
“multimodelos”, porque implementam funcionalidades que vão além do modelo relacional. Vejamos: 
ações. 
1. Oracle 
a. Relacional e multimodelo (documentos, grafos e RDF) 
2. MYSQL 
a. Relacional e multimodelo (documentos) 
3. Microsoft SQL Server 
a. Relacional e multimodelo (documentos e grafos) 
4. PostgreSQL 
a. Relacional e multimodelo (documentos) 
5. IBM DB2 
a. Relacional e multimodelo (documentos e RDF) 
E o que são esses outros modelos de banco de dados, além do relacional? 
Não resta dúvida de que o modelo relacional se firmou no mundo corporativo, sendo utilizado na 
grande maioria dos sistemas de informação empresariais pela sua popularidade e robustez dos produtos 
disponíveis ao longo de décadas de desenvolvimento, bem como pela padronização e pelo uso da linguagem 
de consulta e manipulação de dados SQL. 
Entretanto, existem aplicações em sistemas de informação que requerem muito mais recursos de 
armazenamento e manipulação de dados do que as tabelas do modelo relacional, em especial aplicações 
Web e de cunho científico que processam grandes quantidades de dados em formatos diversos, com as 
atuais tendências como Big Data, Internet of Things e Data Science. 
Assim, vários modelos de banco de dados não relacionais vêm surgindo no mercado, sendo 
denominados de NoSQL, termo traduzido como “Não SQL” ou “Não somente SQL” (de Not Only SQL). 
São, de fato, bancos de dados que não adotam o modelo relacional de dados e, portanto, não usam 
a linguagem SQL, embora alguns possuam implementações do comando SELECT da SQL para fins de 
compatibilidade de linguagem de consulta com os bancos de dados relacionais. 
Sistema de Banco de Dados 
Marcio Quirino - 15 
 
O estudo de bancos de dados NoSQL está fora do escopo deste tema, constituindo-se em um tema 
à parte pela diversidade dos seus conceitos e de suas tecnologias. 
É importante conhecer a importância dessa tendência dos SGBDs, como demonstra o site DB-
Engines Ranking, que apresenta mais de uma dúzia de modelos de bancos de dados NoSQL com seus 
principais produtos, muitos deles multimodelos. 
Saiba mais 
Confira a lista de multimodelos 
• Chave-Valor: Redis, Amazon DynamoDB, Microsoft Azure CosmosDB. 
• Documentos: MongoDB, Amazon DynamoDB, Microsoft Azure CosmosDB. 
• Séries temporais: InfluxDB, KDB+, Prometheus. 
• Grafos: Neo4J, Microsoft Azure CosmosDB, ArangoDB. 
• Orientado a objetos: InterSystems Caché. Versant Object Database, ObjectStore. 
• Motores de busca: Elasticsearch, Splunk, Solr. 
• RDF (Resource Description Framework): Marklogic, Apache Jena, Virtuoso. 
• Colunar: Cassandra, HBase, Microsoft Azure CosmosDB. 
• Multivalores: Adabas, UniData/UniVerse, jBASE. 
• XML nativo: Marklogic, Oracle Berkeley DB, Virtuoso. 
• Eventos: Event Store, IBM DB2 Event Store, NEventStore. 
• Conteúdos: JackRabbit, ModeShape. 
• Navegacional: IMS, IDMS. 
 
Comentário 
O modelo navegacional é exatamente aquele dos primórdios dos sistemas de banco de dados, da década de 
1960, antes do advento do modelo relacional, cujos produtos ainda continuam sendo utilizados, principalmente em 
sistemas de informação legados daquela época. 
Verificando o aprendizado 
1. Ao final deste módulo, é um bom momento para retornar à questão levantada durante 
a descrição dos modelos de computação em sistemas de informação. Qual modelo é o mais 
eficiente para uma aplicação na mesma linguagem de programação, com o mesmo volume de 
dados, sob a mesma infraestrutura de hardware? 
Modelo monolítico com os dados junto dos programas. 
Consideradas as mesmas condições de aplicação, volume de dados e infraestrutura, conforme o 
enunciado, o modelo monolítico será mais eficiente, pois todo o processamento será realizado navelocidade de processamento junto à memória principal (RAM), que é muito mais rápida do que o 
acesso à memória secundária ou à nuvem. 
Na verdade, as alternativas dessa questão estão na sequência de eficiência dos modelos de 
computação sob as mesmas condições. Isso não significa que os bancos de dados são ineficientes, 
pois eles se aplicam adequadamente a cenários com volumes de dados que não cabem na memória 
principal, como é o caso de sistemas de informação corporativos. 
2. Qual o nome da linguagem de consulta e manipulação de banco de dados que se tornou 
sinônimo do modelo relacional de banco de dados? 
 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 16 
 
SQL 
Todas as demais alternativas referem-se a nomes de SGBDs que implementam o modelo relacional 
e, portanto, implementam a linguagem SQL (Structured Query Language), chegando a confundir o 
nome do produto com a linguagem. 
2. Características dos Sistemas de Banco de Dados (SBD) 
Diferenças entre sistema de arquivos e sistema de banco de dados 
No módulo anterior, verificamos que uma característica primordial que distingue os sistemas de 
banco de dados dos sistemas baseados de arquivos é a independência dos dados em relação a programas. 
Essa, na verdade, é apenas uma espécie da característica dos sistemas de banco de dados denominada 
independência de dados. 
O conceito de independência de dados deriva da arquitetura de três esquemas do banco de dados 
que separa as aplicações dos usuários finais do banco de dados físico armazenado. 
A figura a seguir é uma adaptação da arquitetura ANSI/SPARC, que considera três níveis de 
esquemas: o nível externo, que contém o esquema conceitual externo, integrando as diferentes visões dos 
usuários das aplicações; o nível conceitual, o qual contém o esquema conceitual lógico ou de 
implementação, descrevendo a estrutura lógica do banco de dados; e o nível interno, que contém o esquema 
interno ou físico do banco de dados armazenado em disco. 
 
Essa arquitetura serve para definir dois tipos de independência de dados, além da independência 
entre dados e programas já estudada: 
 
Sistema de Banco de Dados 
Marcio Quirino - 17 
 
Independência lógica de dados 
Consiste na capacidade de se alterar o esquema conceitual lógico, por exemplo, acrescentando um item de 
dado, sem alterar o esquema conceitual externo, isto é, as visões externas dos usuários através dos programas de 
aplicação. 
Independência física de dados 
Consiste na capacidade de se alterar o esquema interno, por exemplo, reorganizando os arquivos físicos que 
armazenam os dados, sem alterar o esquema conceitual lógico e, em consequência, o esquema conceitual externo. 
Outras características, entre muitas, que diferenciam os sistemas de bancos de dados dos sistemas de 
arquivos são descritas a seguir. 
Natureza autocontida 
Significa que, além dos dados, o SBD contém a descrição completa de suas estruturas e restrições. Como se 
verá na arquitetura do SGBD, a descrição da estrutura e das restrições de dados, conhecida como metadados, isto é, 
dados que descrevem dados, é armazenada no catálogo do sistema de banco de dados. 
Abstração de dados 
Permite a representação conceitual dos dados por meio de modelos de dados que ocultam detalhes de 
armazenamento e implementação, os quais não interessam aos diferentes usuários, dando suporte a múltiplas visões 
lógicas dos dados e à independência de dados. 
Suporte ao compartilhamento de dados e processamento de transações concorrentes 
Permite que múltiplos usuários acessem o banco de dados simultaneamente. 
Os modelos de dados que suportam a abstração de dados e permitem sua independência lógica e 
física são classificados em modelos físicos, lógicos e conceituais. 
Modelos Físicos 
Descrevem como os dados são armazenados no computador mediante informações como tipos de arquivos, 
formatos e ordenação de registros, caminhos de acesso. São as várias formas de estruturas de arquivos que dependem 
do SGBD e do sistema operacional em que estão instaladas. 
Modelos Lógicos 
São aqueles que representam, de maneira abstrata, a implementação dos bancos de dados, ocultando detalhes 
de como os dados são armazenados e acessados no disco. O modelo lógico mais tradicional, largamente utilizado na 
grande maioria dos sistemas de informação organizacionais, é o modelo relacional criado por Edgar Codd, mencionado 
no módulo anterior. A estrutura de dados do modelo relacional é a tabela (relação matemática) e deve ser estudada 
em profundidade em tema específico, assim como as implementações de SGBD relacional. Como vimos, há outros 
modelos lógicos de implementação do banco de dados entre aqueles que atualmente se denominam de modelos não 
relacionais ou NoSQL. 
Modelos Conceituais 
São aqueles que representam a visão dos dados do ponto de vista do usuário final, no nível de abstração mais 
próximo do mundo real. Dentre esses, destaca-se o modelo de entidades e relacionamentos, criado pelo pesquisador 
Peter Chen, em 1976. O chamado modelo ER, segundo o próprio autor, foi criado para prover um melhor entendimento 
do modelo relacional, de modo a servir como uma etapa inicial no processo de projeto de banco de dados, denominada 
de modelagem conceitual dos dados. 
Vale destacar que a modelagem conceitual de dados realizada com o modelo ER foi incorporada na linguagem 
UML (Unified Modeling Language), criada no final da década de 1990 para uniformizar a modelagem orientada a objetos 
sob a forma do modelo de classes, em que as entidades são representadas pelas classes de objetos e os 
relacionamentos pelas associações entre as classes. Na prática atual do processo de desenvolvimento de sistemas de 
informação, é comum a utilização do modelo de classes da UML como substituto do modelo ER nas fases iniciais do 
projeto de banco de dados. 
Sistema de Banco de Dados 
Marcio Quirino - 18 
 
Atenção 
Nesse ponto, vale a pena revisitar a definição de banco de dados citada no início do primeiro módulo, 
complementando-a com as principais características aqui mencionadas. Assim, podemos definir banco de dados como 
uma coleção autodescritiva de dados relacionados, com significado lógico inerente, que pode ser manipulada 
concorrentemente por usuários com visões diferentes. 
Vantagens e desvantagens da abordagem de banco de dados 
A abordagem de SBD possui funcionalidades que conferem vantagens adicionais em relação a 
sistemas sem banco de dados, além das características que a diferenciam da abordagem de sistemas de 
arquivos. Algumas dessas funcionalidades do SBD são listadas a seguir e podem ser objeto de estudo em 
temas sobre implementação e administração de banco de dados. 
Controle da redundância de dados 
Previne a possibilidade de inconsistência dos dados, a duplicação de esforço para manter os dados atualizados 
e o desperdício de espaço de armazenamento. O SGBD permite controlar o trade off entre o armazenamento em um 
único local no banco de dados versus a redundância forçada para melhorar o desempenho das consultas. 
Compartilhamento de dados 
Sendo os SBD multiusuários, realizam controle de concorrência de acesso aos dados compartilhados para 
garantir as propriedades de atomicidade, consistência, isolamento e durabilidade (propriedades ACID) das transações 
de banco de dados. 
Controle de acesso 
Mecanismos de segurança e autorização, como senhas para usuários e para grupos de usuários; restrição de 
acesso a partes do banco de dados; proibição de executar certas operações privilegiadas; acesso de usuário restrito 
apenas a transações autorizadas; proibição de uso de software privilegiado, como o software de administração do SBD. 
Múltiplas interfaces de usuários e aplicações 
Provê diferentes linguagens de consulta para usuários casuais; linguagens de programação para 
programadores de aplicações; interfaces gráficas com formulários (telas) e menus para usuários de aplicações; 
interfacespara administração do banco de dados; interfaces de linguagem natural. 
Representação de relacionamentos entre os dados 
Permite representar os relacionamentos existentes entre dados no mundo real, mediante mecanismos que 
dependem do modelo lógico de implementação do SBD. 
Cumprimento de restrições de integridade dos dados 
Previne a violação de restrições como tipo de dado ou domínio de valores admissíveis; unicidade de itens de 
dados por meio de chaves únicas; integridade referencial entre dados relacionados e restrições derivadas da semântica 
dos dados. Aqui também o SGBD permite controlar o trade off entre garantir o cumprimento automático das restrições 
ou deixar a sua especificação para os programas de aplicação. 
Capacidade de backup e recuperação de dados: 
Em caso de ocorrência de falhas de hardware ou de software, os mecanismos de cópia de segurança (backup) 
e posterior restauração (recovery) garantem a consistência de estado do banco de dados antes e depois da falha. 
Compartilhamento de dados entre múltiplos usuários simultâneos 
É uma característica primordial do SBD e tem como resultado o controle de concorrência das transações. 
É responsabilidade do SGBD garantir as propriedades das transações, conhecidas pela sigla ACID, 
relaxando-as quando necessário para manter o desempenho sob seu controle e para não violar a integridade 
do banco de dados. 
Sistema de Banco de Dados 
Marcio Quirino - 19 
 
Atomicidade (Atomicity) 
Cada transação é tratada como uma unidade composta de uma sequência de operações, de modo que deve 
executar completamente com sucesso ou falhar completamente. 
Consistência (Consistency) 
Uma transação só pode levar o banco de dados de um estado válido para outro, de acordo com suas regras 
de integridade. 
Isolamento (Isolation) 
Cada transação é isolada das demais, isto é, essa propriedade assegura que transações executadas 
concorrentemente levem o banco de dados ao mesmo estado que chegaria se as transações fossem executadas 
sequencialmente. 
Durabilidade (Durability) 
Uma vez que a transação é aceita (committed), o que significa que seu resultado foi gravado em memória não 
volátil, esse resultado permanecerá válido mesmo em caso de falhas do sistema. 
Vantagens 
• As vantagens decorrentes dessas funcionalidades do SBD são várias: potencial para o 
estabelecimento de padrões de uso dos dados na organização; redução do tempo de desenvolvimento 
de aplicações; flexibilidade na manutenção dos dados; disponibilidade dos dados atualizados no 
âmbito de toda a organização; economia de escala, entre outras. 
Desvantagens 
• Agora, vejamos as desvantagens da abordagem de banco de dados. Como já foi observado, a 
presença do SGBD como um software intermediário entre as aplicações e os dados armazenados 
provoca uma sobrecarga no desempenho do sistema como um todo. Além disso, há de se levar em 
conta o custo e o esforço adicional na capacitação e no oferecimento de funcionalidades sofisticadas 
como as já citadas anteriormente. 
Assim, pode-se dizer que é preferível não usar a abordagem de SBD em algumas aplicações, tais 
como: 
1. Aplicações muito simples com dados estáticos e bem definidos, que se espera que não 
sejam alterados (exemplo: censo demográfico); 
2. Aplicações de tempo real com requisitos rígidos os quais não possam ser atendidos com o 
overhead causado pelo SGBD (exemplo: controle de tráfego aéreo); 
3. Sistemas embarcados, com poucos dados e com requisitos estritos de tempo real (exemplo: 
piloto automático); 
4. Sistemas monousuários de uso sem concorrência, típicos de aplicações em desktop 
(exemplo: prontuário eletrônico de um único consultório médico). 
Poderiam ser enquadradas nessa lista as aplicações que requerem dados volumosos com dinâmica 
não processável por SGBDs tradicionais, como a Internet das Coisas (IoT, de Internet of Things), porém, o 
advento de bancos de dados NoSQL, com modelos de dados específicos para tratamento de Big Data, 
busca a atender a esses tipos de aplicações incompatíveis com os modelos tradicionais de SGBD. 
Papéis em sistemas de bancos de dados 
A figura a seguir mostra as camadas de um sistema de computação desde o hardware, onde são 
armazenados os arquivos com programas e dados, até as aplicações disponíveis aos usuários finais, que 
Sistema de Banco de Dados 
Marcio Quirino - 20 
 
podem ser desenvolvidas com ou sem a utilização de um SGBD. Na ilustração, podemos ver também a 
existência de diferentes papéis de usuários ao longo das camadas de software. 
 
Em um sistema de computação corporativo de grandes organizações, é possível separar os 
diferentes papéis desempenhados como mostra a figura. 
Usuários finais 
Beneficiários dos sistemas que rodam no sistema de computação, seja por aplicações desenvolvidas com a 
abordagem de banco de dados ou não. 
Administrador de aplicações 
Função técnico-gerencial responsável pela manutenção dos sistemas de aplicação e pelo suporte aos seus 
usuários, podendo ser exercida por vários administradores. Exemplo: administrador do sistema integrado de gestão 
empresarial, conhecido pela sigla ERP (Enterprise Resource Planning). 
Administrador de desenvolvimento 
Função técnica que pode ser desdobrada em equipes de desenvolvimento do sistema de aplicação, 
dependendo do porte e da complexidade do sistema, que se utilizam das ferramentas disponíveis no ambiente de 
desenvolvimento de sistemas. 
Administrador de dados 
Função gerencial responsável pelo ambiente de dados da organização, que define políticas e 
responsabilidades sobre os recursos de dados, assim como as regras do negócio e os padrões de dados a serem 
seguidos no desenvolvimento. 
Administrador do banco de dados 
Função técnica responsável pela criação e manutenção dos bancos de dados no SGBD, dando suporte às 
equipes de desenvolvimento no tocante aos objetos dos bancos de dados. 
Administrador de sistema 
Responsável por manter no ar o sistema de computação como um todo, com foco no hardware e no sistema 
operacional, bem como nas interfaces deste com os demais softwares instalados. 
Cabe observar que nem todos os papéis de administração podem ser exercidos por uma única 
pessoa, mas uma pessoa pode exercer mais de um papel. A distribuição desses papéis por pessoas e 
equipes dependerá do porte da organização e do sistema de computação, variando desde uma única pessoa 
Sistema de Banco de Dados 
Marcio Quirino - 21 
 
exercendo todos os papéis de administração até todo um departamento de TI encarregado da administração 
e do suporte aos diversos sistemas em operação. 
Verificando o aprendizado 
1. Analise as seguintes afirmações e responda qual alternativa corresponde a características 
que distinguem os sistemas de banco de dados dos sistemas de arquivos. 
I. Natureza autocontida dos dados 
II. Volatilidade dos dados 
III. Abstração de dados 
Somente as afirmações I e III. 
A natureza autocontida dos dados, com o armazenamento junto aos metadados, e a abstração 
de dados, permitindo a independência dos dados, são características que diferenciam os SBD 
dos sistemas de arquivos. Já a volatilidade dos dados não é uma característica dos SBD. 
2. Qual das alternativas abaixo não é uma funcionalidade dos sistemas de banco de dados? 
Armazenamento de dados estáticos. 
O armazenamento de dados estáticos é uma das situações em que não é recomendável o uso 
da abordagem de banco de dados, pois não se trata de uma funcionalidade típica dos SBDs, 
como as demais alternativas. 
3. Arquitetura dos sistemas de gerência de banco de dados 
(SGBD) 
Componentes de um sistema de banco de dados 
A figura a seguir mostra uma visão simples do ambiente de banco de dados, compreendendo 
programas de aplicação ou consultas de usuários que acessam os dados e metadados armazenados em 
disco através do SGBD. Este, por sua vez, compõe-se, simplificadamente, de um software para processar 
consultas e programas eoutro para acessar os dados e metadados armazenados. 
Nota-se, na figura, que não se confundem o SBD e o SGBD, visto que este é um componente daquele 
que engloba também os programas e as consultas, bem como os dados e metadados armazenados. 
A fronteira do SBD engloba os programas que implementam as aplicações, bem como as consultas 
provenientes de usuários com acesso a linguagens e interfaces de consulta. O SGBD é o software 
intermediário, uma caixa preta a ser aberta no próximo módulo. A fronteira do SBD envolve os metadados 
armazenados no catálogo (às vezes chamado de dicionário de dados) e o próprio conteúdo armazenado no 
banco de dados. 
Sistema de Banco de Dados 
Marcio Quirino - 22 
 
 
Costuma-se definir metadados como o esquema do banco de dados, estruturado de acordo com o 
modelo lógico de implementação. Assim, modelar um banco de dados consoante ao modelo lógico de 
implementação equivale a esquematizar o banco de dados conforme os construtores desse modelo. Por 
exemplo, no modelo relacional, o esquema é composto por tabelas e suas colunas. Cada comando de 
definição de dados, criando, alterando ou removendo uma tabela, provoca uma mudança no esquema do 
banco de dados. 
Por outro lado, chama-se de estado ou instância o conteúdo do banco de dados armazenado em um 
momento. Cada manipulação no banco de dados mediante comandos de inserção, atualização ou remoção 
de dados provoca uma mudança de estado, gerando uma nova instância do banco de dados. 
Como vimos, o termo banco de dados é correntemente usado com o sentido do original, em inglês, database, 
cuja origem, segundo o Oxford English Dictionary, remonta a 1962 num relatório de uma empresa na Califórnia. Raras 
são as referências ao termo data bank como, por exemplo, no mencionado artigo de Edgar Codd sobre o modelo 
relacional (CODD, 1970). 
Em espanhol, usa-se base de datos, no francês base de données, enquanto em alemão se diz Datenbank, e 
em italiano banca dati. 
Em português, existem os dois termos, sendo banco de dados usado no sentido geral do ambiente que engloba 
o sistema, como na figura anterior, enquanto base de dados tem o sentido mais restrito do conteúdo do banco, isto é, 
corresponde ao estado ou à instância do banco de dados. Por exemplo, costuma-se referir à base de dados da Receita 
Federal como o conjunto de dados armazenados sobre os contribuintes e não como o sistema que gerencia os dados. 
Módulos de um sistema de gerência de banco de dados 
A figura a seguir ilustra, em detalhes, os diversos módulos que compõem um SGBD, sendo a parte 
superior correspondente ao processamento das consultas e aplicações, e a parte inferior ao acesso a 
metadados e dados armazenados (a base de dados). 
Sistema de Banco de Dados 
Marcio Quirino - 23 
 
 
Vamos conferir a descrição desses módulos. 
Usuários 
Da esquerda para a direita, vemos os usuários, começando com os administradores de banco de dados (ABD, 
do inglês DBA – Database Administrator). 
ABD 
O ABD usa comandos da linguagem de definição de dados (LDD, do inglês DDL – Data Definition Language) 
para criar, alterar ou remover objetos do banco de dados (comandos CREATE, ALTER, DROP no padrão SQL), os 
quais ficam armazenados no catálogo do sistema, que contém os metadados. 
O ABD também possui privilégio para executar comandos de controle de dados, conhecidos por alguns autores 
como linguagem de controle de dados (LCD, do inglês DCL – Data Control Language), para conceder e revogar 
permissões de acesso aos dados (comandos GRANT e REVOKE no padrão SQL), entre outros. Note que o destino 
desses comandos privilegiados é um nó central do SGBD, por onde passam todos os comandos destinados ao 
processador de banco de dados em tempo de execução, denominado de processador de runtime ou runtime engine. 
Usuários casuais 
Seguindo para a direita, vemos os usuários casuais, os quais fazem consultas interativas através de uma 
interface para consultas ad hoc, ou seja, consultas não programadas previamente. As consultas são feitas tipicamente 
com o comando SELECT no padrão SQL do modelo relacional e provido de modo similar em outros modelos de 
implementação de banco de dados. Esses comandos são compilados por um compilador da linguagem de consulta e 
passam por um otimizador de consulta antes de chegar ao nó central do SGBD. 
Programadores de aplicações 
Mais à direita, aparecem os programadores de aplicações que escrevem os programas em uma linguagem de 
programação hospedeira, como por exemplo, Java, PHP ou Python, nos quais estão embutidos comandos de consulta 
(SELECT), inserção, atualização e exclusão de dados em uma linguagem de manipulação de dados (LMD, do inglês 
DML – Data Manipulation Language). 
Sistema de Banco de Dados 
Marcio Quirino - 24 
 
No padrão SQL, esses comandos são, respectivamente, INSERT, UPDATE e DELETE. Note que eles 
manipulam dados, diferentemente dos comandos da linguagem de definição de dados (CREATE, ALTER, DROP), que 
manipulam metadados. 
Programas de aplicação 
Os programas de aplicação, portanto, possuem comandos híbridos, da linguagem hospedeira e da linguagem 
de consulta e manipulação de dados. 
Pré-compilador 
Os programas de aplicação são processados, inicialmente, por um pré-compilador, responsável por separar os 
comandos e os repassar para os compiladores das respectivas linguagens. 
Compiladores 
Cabe a esses compiladores produzirem o código das aplicações sob a forma de transações executáveis, que 
ficam à disposição dos usuários paramétricos. 
Usuários paramétricos 
Os usuários paramétricos são assim chamados porque interagem com o sistema através de parâmetros 
passados em interfaces apropriadas. Por exemplo, um agente de viagens faz uma reserva de passagem aérea 
passando ao sistema os dados do passageiro, data e hora da viagem, número do voo, número do assento e outros 
parâmetros necessários para efetivar a reserva. 
Transações compiladas 
Uma vez executadas as transações compiladas, assim como os demais comandos provenientes de usuários 
ou aplicações, são passadas ao nó central do SGBD para posterior processamento do processador de runtime. 
Atenção! Antes de prosseguir na parte de baixo da figura, note que alguns processos da parte de cima, como 
o otimizador de consulta e o compilador da LMD, estão ligados ao catálogo por linhas tracejadas, que denotam fluxos 
de controle, enquanto as linhas cheias representam fluxos de dados, além de controle. Isso é necessário porque as 
referências a objetos do banco de dados existentes no catálogo devem ser consistentes com os objetos, criados e 
mantidos pelo ABD mediante comandos da LDD. 
Processamento do acesso aos dados armazenados 
Prosseguindo para a parte do processamento do acesso aos dados armazenados, observamos que o 
processador de runtime é o coração do SGBD. De fato, o diferencial dos produtos de SGBD reside na eficiência e na 
funcionalidade desse processador, segredo industrial em muitos dos SGBDs proprietários, a ponto de exigir rigorosos 
termos de confidencialidade das pessoas que têm acesso ao seu código. 
Acesso a base de dados 
O processador de runtime também precisa acessar e, por vezes, modificar o catálogo, dependendo da natureza 
dos comandos, das consultas ou transações que estiver processando. Como mostra a figura, ele acessa a base de 
dados diretamente, sob controle de subsistemas de controle de concorrência, backup e recovery. Quando precisa 
realizar operações de entrada e saída (gravação e leitura) na base de dados, o processador de runtime se vale de um 
gerenciador de dados armazenados. 
A descrição dada, embora simplificada, denota a complexidade de um SGBD, software que evoluiu 
desde a década de 1960 a ponto de se tornar um recurso robusto, eficiente e indispensável para a maioria 
das organizações privadas ou públicas, principalmente com base no modelo relacional de banco de dados. 
Existe uma grande quantidade de SGBDs disponíveisno mercado, como mostrou o DB-Engines 
Ranking, ao listar mais de 300 SGBDs, sendo cerca de 130 deles do modelo relacional. 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 25 
 
Saiba mais 
A excelente entrada na Wikipédia, intitulada Comparison of relational database management systems, faz uma 
comparação de diversas características de SGBDs relacionais, contendo informações detalhadas sobre mais de 60 
produtos. 
Um exemplo de SGBD relacional: PostgreSQL 
Como vimos anteriormente na evolução histórica dos SGBDs, o PostgreSQL originou-se do projeto 
Ingres da Universidade da Califórnia em Berkeley, na década de 1970, tendo sido sucessivamente 
renomeado de Postgres (Post Ingres), depois Postgres 95 e, finalmente, PostgreSQL. 
Embora fossem implementações do modelo relacional proposto por Edgard Codd (CODD, 1970), o 
Ingres e o Postgres originalmente usavam uma linguagem diferente da SQL, adotada pela IBM, conhecida 
como QueL (Query Language). Por muitos anos, a QueL persistiu nesses SGBDs em concorrência direta 
com a SQL da IBM, até que o ANSI (American National Standard Institute) e depois a ISO (International 
Standard Organization) reconheceram a SQL como a linguagem padrão para o banco de dados relacional. 
A partir de então, a SQL foi implementada no Postgres, passando a ser chamada de PostgreSQL. 
O PostgreSQL, além de ser reconhecido como the world's most advanced open source relational 
database, possui uma completa documentação igualmente reconhecida como referência global para os 
conceitos de SGBD relacional. Não é sem razão que o PostgreSQL, por ser open source e ter licença livre, 
é vastamente utilizado no ensino de banco de dados, além de ser adotado comercialmente em grandes 
organizações ao redor do mundo. 
O PostgreSQL é um típico SGBD relacional-objeto, isto é, um SGBD cuja estrutura de dados básica é a relação 
(tabela), porém contempla extensões de tipos de dados e características próprias da orientação a objetos. Assim, 
possui suporte em grande parte ao padrão SQL e implementa extensões úteis como: consultas complexas, gatilhos 
(triggers), visões materializadas atualizáveis, controle de concorrência multiversionado. Além disso, pode ser estendido 
de muitas formas, por exemplo, gerando novos tipos de dados, funções genéricas e agregadas, operadores, métodos 
de indexação e linguagens procedurais. 
Em jargão de sistemas, o PostgreSQL usa um modelo de computação cliente/servidor, assim como 
a maioria dos SGBDs relacionais empresariais. Uma sessão PostgreSQL consiste dos seguintes processos 
cooperativos (programas): 
Back end 
• Um processo servidor (back end), responsável por gerenciar os arquivos do banco de dados, aceitar 
conexões por aplicações clientes e executar ações sobre o SBD em nome dos clientes. O programa 
servidor é chamado postgres. 
Front end 
• As aplicações clientes de usuários (front end) que desejam executar operações no banco de dados. 
Aplicações clientes podem ser diversas em natureza, como uma ferramenta orientada a texto, uma 
aplicação gráfica, um servidor Web que acessa o banco de dados para exibir páginas Web, ou uma 
ferramenta especializada de manutenção. Algumas aplicações clientes são fornecidas com a 
distribuição PostgreSQL (psql, pgadmin). 
O PostgreSQL roda em todos os sistemas operacionais importantes, incluindo Linux, UNIX (AIX, 
BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) e Windows. Possui todas as propriedades ACID das 
transações (atomicidade, consistência, isolamento e durabilidade) e tem completo suporte para chaves 
estrangeiras, junções, visões, funções, triggers, e procedimentos armazenados em múltiplas linguagens de 
programação, incluindo Java, Perl, Python, Ruby, Tcl, C/C++, e sua própria PL/pgSQL, similar à PL/SQL do 
Oracle. 
Sistema de Banco de Dados 
Marcio Quirino - 26 
 
Como banco de dados de classe empresarial, PostgreSQL possui características sofisticadas como 
controle de concorrência multiversão (Multi Version Concurrency Control), recuperação "point in time" (PiTR 
– Point in Time Recovery), tablespaces, replicação assíncrona, transações aninhadas (savepoints), 
online/hot backups, um sofisticado planejador/otimizador de consultas, e write ahead logging (WAL) para 
tolerância a falhas. 
O PostgreSQL é altamente escalável tanto na quantidade de dados que pode gerenciar como no 
número de usuários concorrentes que pode acomodar. Existem sistemas PostgreSQL em ambientes de 
produção que gerenciam centenas de usuários simultâneos com dezenas de terabytes de dados 
armazenados. 
Além de possuir um catálogo de sistema totalmente relacional, capaz de suportar múltiplos schemas 
por database, o catálogo do PostgreSQL é também acessível através do Information Schema, um conjunto 
de visões de metadados definido no padrão SQL. 
Atenção 
PostgreSQL suporta índices compostos, parciais e funcionais que podem usar seus métodos de 
armazenamento B-tree, R-tree, hash ou GiST. Este último é um sofisticado framework que serve de base para muitos 
projetos públicos que usam PostgreSQL, como o OpenFTS (Open Source Full Text Search engine), que provê 
indexação online de dados e ranking de relevância para pesquisa em bancos de dados, e o PostGIS, um projeto que 
adiciona suporte para objetos geográficos, permitindo seu uso como banco de dados espacial para Sistemas 
Geográficos de Informação. 
Outras características avançadas do PostgreSQL incluem herança de tabelas, sistema de regras e 
eventos de banco de dados. 
Herança de tabelas 
Coloca um "sabor" orientado a objeto na criação de tabelas, permitindo a projetistas de banco de dados derivar 
novas tabelas de outras tabelas, tratando-as como classe base. Esse esquema suporta tanto herança simples como 
múltipla. 
Sistema de regras 
Também chamado de sistema de reescrita de consultas, permite ao projetista de banco de dados criar regras 
que identificam operações específicas para uma dada tabela ou visão e dinamicamente transformá-las em operações 
alternativas quando são processadas (cláusula INSTEAD OF). 
Sistema de eventos 
É um sistema de comunicação interprocessos em que mensagens e eventos podem ser transmitidos entre 
clientes usando os comandos LISTEN e NOTIFY, permitindo tanto comunicação simples peer to peer como avançadas 
coordenações entre eventos de banco de dados. Clientes PostgreSQL podem monitorar eventos de banco de dados, 
como atualizações, inserções e exclusões em tabelas, enquanto eles acontecem. 
Atenção 
O código fonte do PostgreSQL é disponível sob a licença open source BSD. Essa licença dá a liberdade de 
usar, modificar e distribuir o PostgreSQL da forma que se desejar, com código aberto ou fechado. Quaisquer 
modificações, melhoramentos ou mudanças que você faça serão seus para fazer o que quiser. Por isso, o PostgreSQL 
não é somente um poderoso SGBD capaz de rodar o negócio da empresa. Também é uma plataforma de 
desenvolvimento sobre a qual se pode desenvolver produtos de software in-house que requeiram um suporte adequado 
a banco de dados. 
Com a grande aceitação do PostgreSQL no mercado, desde 2004, um grupo de contribuidores do 
seu desenvolvimento fundou a empresa Enterprise DB, que fornece uma versão empresarial de mesmo 
nome, com consideráveis extensões ao PostgreSQL. 
Sistema de Banco de Dados 
Marcio Quirino - 27 
 
Verificando o aprendizado 
1. Qual é o principal módulo componente de um SGBD, pelo qual passam todas as consultas 
e transações de usuários, sejam administradores, usuários casuais ou paramétricos? 
Processador de run time. 
O processador do banco de dados em tempo de execução (run time) recebe todas as requisições 
dos usuários e as processa para acessar o catálogo e a base de dados. 
2. Qual é o modelo de computação utilizado pelo PostgreSQL, assim como pela maioria dos 
SGBDs relacionais empresariais? 
Cliente/Servidor. 
O PostgreSQL usa um modelo de computação cliente/servidor, em que uma sessão consisteem 
um processo servidor (back end), que gerencia os arquivos do banco de dados, aceita conexões 
por aplicações clientes e executa ações sobre o banco de dados em nome dos clientes, e 
aplicações clientes de usuários (front end) que desejam executar operações no banco de dados. 
Considerações finais 
Este tema abordou uma introdução aos sistemas de banco de dados, resumindo sua evolução 
histórica desde a invenção do disco magnético, que possibilitou o início da era de processamento de dados 
por computador. 
Foram examinadas as principais características do sistema de banco de dados (SBD), com ênfase 
naquelas que o diferenciam dos sistemas de arquivos, bem como nas suas funcionalidades, vantagens e 
desvantagens. 
Finalizamos o tema com a descrição da arquitetura de um sistema de gerência de banco de dados 
(SGBD), componente central do SBD, terminando com um exemplo de SGBD relacional, amplamente 
utilizado no ensino e no mercado, o PostgreSQL. 
Encerraremos este tema aprofundando um pouco mais sobre sistema de banco de dados. 
Referências 
BALIEIRO, R. Banco de Dados. 1. ed. Rio de Janeiro: SESES, 2015 
BOOCH, G; RUMBAUGH, J; JACOBSON, I. The Unified Modeling Language User Guide. Reading: 
Addison-Wesley. 1998. 
CHEN, P. The Entity–Relationship Model – Toward A Unified View of Data. In: ACM Transactions on 
Database Systems. 1 (1): 9–36, 1976. 
CODD, E. F. A Relational Model of Data for Large Shared Data Banks. In: Communications of the 
ACM. 13 (6): 377–387, 1970. 
DB-ENGINES. DB-Engines Ranking of Relational DBMS. Consultado em meio eletrônico em: 3 jun. 
2020. 
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7. ed. São Paulo: Pearson, 2019. 
IBM. SQL: The language of Db2. 
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 9075-1:2016: Information 
technology - Database languages - SQL - Part 1: Framework (SQL/Framework). Publicado em: dez. 2016. 
Sistema de Banco de Dados 
Marcio Quirino - 28 
 
KLUG, A.; TSICHRITZIS, D. The ANSI/X3/SPARC DBMS framework: report of the study group on 
database management systems. In: Information Systems. Data: creations, management and utilization. v. 3, 
3. Elsevier Journal, 1978. 
MELO, R; SILVA, S.; TANAKA, A. Banco de Dados em Aplicações Cliente-Servidor. Rio de Janeiro: 
Infobook, 1998. 
PPLWARE. Charles Babbage – O pioneiro dos computadores. Publicado em: 28 set. 2017. 
POSTGRESQL. PostgreSQL: o banco de dados relacional de código aberto mais avançado do 
mundo. Consultado em meio eletrônico em: 3 jun. 2020. 
TANAKA, A. Notas de Aula sobre Banco de Dados do professor Asterio Tanaka. Disponível sob 
licença Creative Commons BR Atribuição – CC BY, 2018. 
WIKIPEDIA. Comparison of relational database management systems. Consultado em meio 
eletrônico em: 6 jun. 2020. 
YUGE, C. Crise da COVID-19 aumenta a procura por programadores de COBOL. In: Canaltech. 
Publicado em: 13 abr. 2020. 
Explore+ 
Para reforçar o conteúdo visto, todo bom livro-texto de fundamentos de banco de dados possui uma 
introdução ao assunto, nos moldes deste tema. Recomendamos o livro-texto mais adotado mundialmente: 
Sistemas de Banco de Dados, de Ramez Elmasri e Shamkant B. Navathe. Vale a leitura da parte 1, sobre 
introdução a banco de dados, formada pelos capítulos: 1 – Bancos de Dados e Usuários de Bancos de 
Dados; 2 – Conceitos e Arquitetura do Sistema de Banco de Dados 
Sugerimos uma visita ao excelente DB-Engines Ranking, que possui uma vasta classificação dos 
SGBDs mais populares, nos diversos modelos de dados, com breves explicações sobre cada modelo e 
informações sobre cada produto. 
Como dissemos, a documentação do PostgreSQL, disponível em website de mesmo nome, é 
reconhecidamente um material de referência para o modelo relacional-objeto em geral, servindo como 
excelente ponto de partida para o entendimento do tema. Sugerimos iniciar pela seção About e prosseguir 
fazendo o Tutorial, que inclui Getting Started, The SQL Language e Advanced Features. 
Leia a matéria Crise da COVID-19 aumenta a procura por programadores de COBOL, de Claudio 
Yuge. 
Como dissemos, o PostgreSQL é reconhecido como como o mais avançado SGBD open source do 
mundo. Acesse o website do PostgreSQL, onde você encontrará a possibilidade de baixá-lo e saber sobre 
as últimas atualizações. 
Leia o artigo The ANSI/X3/SPARC DBMS framework report of the study group on database 
management systems, de Dennis Tsichritzis e Anthony Klug, e aprofunde seus conhecimentos sobre a 
arquitetura ANSI/SPARC. 
Acesso o site da Wikipedia e busque por Comparison of relational database management systems, 
que traz uma excelente comparação de diversas características de SGBDs relacionais, contendo 
informações detalhadas sobre mais de 60 produtos. 
Acesse o website da ISO (International Standard Organization) e busque pela resolução ISO/IEC 
9075-1:2016, na qual a SQL é reconhecida como a linguagem padrão para o banco de dados relacional. 
Sistema de Banco de Dados 
Marcio Quirino - 29 
 
Exercícios 
1. Que invenção da IBM permitiu a utilização dos computadores na implementação de 
sistemas de informação, inaugurando a chamada era do processamento de dados? 
O disco magnético. 
2. Qual conjunto de comandos da SQL abaixo serve para o administrador do banco de dados 
gerenciar os metadados de um banco de dados? 
CREATE, ALTER, DROP. 
3. Analise as afirmações abaixo e responda qual alternativa corresponde a afirmações 
verdadeiras sobre os módulos de um SGBD: 
I - O catálogo armazena os metadados do sistema de banco de dados. 
II - Os programas de aplicação são pré-compilados para separar os comandos da 
linguagem de programação dos comandos de manipulação de dados. 
III - As transações são compiladas após passarem pelo otimizador de consultas. 
Somente as afirmações I e II estão corretas. 
4. (ESPP/2013 - Adaptada) É responsabilidade do SGBD garantir as propriedades das 
transações, conhecidas pela sigla ACID, relaxando-as quando necessário para manter o 
desempenho sob seu controle. A integridade de uma transação depende dessas 4 
propriedades conhecidas como ACID, são elas: 
I. Atomicidade. 
II. Consciência. 
III. Isolamento. 
IV. Durabilidade. 
 
Assinale a alternativa correta. 
I, III e IV, apenas. 
Explicação: 
Atomicidade (Atomicity): Cada transação é tratada como uma unidade composta de uma 
sequência de operações, de modo que deve executar completamente com sucesso ou falhar 
completamente. 
Consistência (Consistency): Uma transação só pode levar o banco de dados de um estado válido 
para outro, de acordo com suas regras de integridade. 
Isolamento (Isolation): Cada transação é isolada das demais, isto é, essa propriedade assegura 
que transações executadas concorrentemente levem o banco de dados ao mesmo estado que 
chegaria se as transações fossem executadas sequencialmente. 
Durabilidade (Durability): Uma vez que a transação é aceita (committed), o que significa que seu 
resultado foi gravado em memória não volátil, esse resultado permanecerá válido mesmo em 
caso de falhas do sistema. 
5. Qual conjunto de comandos da SQL abaixo serve para manipular o estado ou a instância 
do banco de dados? 
INSERT, UPDATE, DELETE. 
 
Sistema de Banco de Dados 
Marcio Quirino - 30 
 
Projeto de Banco de Dados: Modelagem Conceitual 
Definição 
Descrição das etapas de um projeto de banco de dados e dos componentes de um diagrama de 
entidade e relacionamento, além da modelagem de entidades e relacionamentos e de atributos. 
Propósito 
Identificar as etapas de um projeto de banco de dados a fim de destacar a importância da modelagem 
conceitual com o uso de diagrama de entidade e relacionamento, atividade comum aos profissionais da área 
de análise de negócio e administração de dados. 
Preparação 
É recomendável que você reproduza os exemplos práticos usando uma ferramenta para modelagem 
de dados como a brModelo, que pode ser baixada gratuitamente para essa tarefa. 
IntroduçãoQueremos construir um banco de dados. Por onde começamos? 
Em primeiro lugar, é necessário esclarecer que, ao construirmos um banco de dados, estamos 
automatizando algum tipo de negócio, ou mesmo parte dele. Segundo Elmasri e Navathe (2019), um banco 
de dados representa algum aspecto do mundo real, às vezes chamado de minimundo ou de universo de 
discurso. É fundamental conhecermos como o negócio funciona. 
Veremos, neste tema, que a construção de um banco de dados é uma atividade dividida em fases 
bem definidas. Ao longo delas, costumamos usar modelos de dados, que servem para que o usuário tenha 
facilidade para entender a organização da estrutura do banco de dados sendo construído. Perceberemos 
que isso ocorre porque o modelo não possui informações muito detalhadas a respeito da representação 
física dos dados. 
A etapa de projeto conceitual servirá para a construção de diagrama de entidade e relacionamento 
(DER), em que há dois conceitos essenciais: entidades e relacionamentos. Trabalharemos alterações em 
um DER com objetivo de comportar novos requisitos de dados e perceberemos que a construção desse 
diagrama é um processo incremental e sempre sujeito a revisões. 
No último módulo, voltaremos nossa atenção para a modelagem de atributos para fecharmos o nosso 
ciclo de aprendizagem. 
1. Projeto de Banco De Dados 
Projetar um banco de dados, de maneira simplificada, envolve as seguintes fases: 
1. Levantamento de requisitos; 
2. Projeto conceitual; 
3. Projeto lógico; e 
4. Projeto físico. 
Ao construir um banco de dados para alguma corporação, devemos ter em mente que há 
colaboradores desempenhando diversas tarefas associadas ao negócio em questão. 
Assim, temos que adquirir conhecimento sobre o funcionamento das rotinas e tarefas para 
capturarmos as necessidades associadas à gestão de dados. Veremos que esse conhecimento ocorre na 
fase de levantamento de requisitos. 
Sistema de Banco de Dados 
Marcio Quirino - 31 
 
Levantamento de requisitos 
Ao longo da etapa de levantamento de requisitos, o profissional de dados entrevista usuários para 
entender sobre o funcionamento do negócio e documentar os requisitos de dados de maneira completa e 
detalhada. Depois disso, pode dar início à próxima etapa: o projeto conceitual. 
Exemplo 
Imagine que você foi convidado a participar de um projeto que objetiva construir um banco de dados para 
controlar inscrições de alunos em uma escola de treinamentos na área de Tecnologia de Informação. Após realizar 
entrevistas junto aos colaboradores, você identifica os seguintes requisitos de dados da escola: 
• A escola planeja diversos cursos. Cada um deles possui nome, descrição, carga horária e é identificado 
por um código único. 
• A escola armazena o nome, a data de nascimento, o CPF, o e-mail e um telefone de cada cliente, que 
é identificado por um código único. 
• Quando um cliente faz inscrição em determinado curso, é necessário que se armazene a data. Caso 
seja cancelada a inscrição, é preciso saber quando ocorreu esse evento. Um cliente pode fazer 
diversos cursos. 
Com os requisitos de dados em mãos, usaremos um modelo de dados gráfico para formalizar entendimento 
mais preciso a respeito dos requisitos de dados. Essa atividade ocorrerá na próxima fase do projeto de banco de dados: 
projeto conceitual. 
Projeto conceitual 
O projeto ou esquema conceitual envolve construir um modelo de dados de alto nível a partir dos 
requisitos de dados que contêm os principais objetos e seus relacionamentos, mapeados na etapa de 
levantamento de requisitos. Nesta etapa, não há preocupação em saber detalhes sobre como os dados 
devem ser armazenados. 
O projeto conceitual usa um diagrama gráfico, conhecido por Diagrama de Entidade e 
Relacionamento (DER), que possui três elementos essenciais: 
1. Entidades; 
2. Relacionamentos; e 
3. Atributos. 
Em um DER, cada entidade é representada por um retângulo com o seu nome. De forma semelhante, 
cada relacionamento, por um losango ligado por linhas aos retângulos das entidades participantes do 
relacionamento. 
Os atributos são expressos graficamente ligados à entidade ou ao relacionamento ao qual fazem 
parte. A Figura 1 representa um DER construído a partir dos requisitos de dados obtidos na etapa de 
levantamento de requisitos. 
 
Figura 1 – DER construído a partir dos requisitos de dados da Escola. 
Sistema de Banco de Dados 
Marcio Quirino - 32 
 
A partir desse diagrama, é possível concluir que o modelo possui duas entidades (CLIENTE e 
CURSO) cuja função é armazenar os dados dos clientes e dos cursos da escola. Além disso, essas 
entidades possuem uma relação entre si, de maneira que um cliente pode fazer inscrição em um ou mais 
cursos. 
[...] O esquema conceitual de alto nível (DER) pode ser utilizado como uma referência para garantir que todos 
os requisitos de dados dos usuários sejam atendidos e que não estejam em conflito. 
(ELMASRI; NAVATHE, 2019) 
Isso acontece porque a representação dos requisitos de dados a partir do DER permite um 
aprendizado mais preciso a respeito do funcionamento do negócio sendo modelado, quando comparado aos 
requisitos de dados. 
Outra notação para DER: diagrama de classes UML 
Ao longo da sua atuação profissional, você perceberá que não há uma notação-padrão para 
representação dos conceitos do modelo de entidade e relacionamento. Normalmente, a notação depende 
de preferência dos profissionais ou mesmo de regras estabelecidas pela empresa de desenvolvimento. As 
ferramentas CASE fazem uso de várias notações. Por exemplo, a utilizada na ferramenta brModelo é muito 
próxima da notação original para modelos de entidade e relacionamento. 
Em projetos de software, é comum o uso da UML para visualização e documentação dos seus 
componentes. De certa forma, um diagrama de classes da UML pode ser considerado uma notação 
alternativa para representar os conceitos de um DER. No diagrama de classes UML, cada classe é 
representada por uma caixa que possui três seções: 
A. Superior 
• Exibe o nome da classe. 
B. Central 
• Exibe os atributos. Além disso, o desenvolvedor pode, se desejar, adicionar informações sobre o 
tipo de dados de algum atributo, colocando um sinal de dois pontos “:” e em seguida o nome do 
tipo de dados. 
C. Inferior 
• Inclui as operações associadas aos objetos da classe, a serem designadas numa etapa posterior, 
quando do projeto das aplicações do banco de dados. 
Na terminologia da UML, o relacionamento entre classes é chamado de associação. Assim, uma 
associação é representada por uma linha que conecta as classes participantes. Além disso, atributos dos 
relacionamentos são colocados em uma caixa conectada à associação por uma linha tracejada. A Figura 2 
mostra como o DER construído a partir dos requisitos de dados da escola pode ser exibido sob a forma de 
diagrama de classes UML. 
 
Figura 2 – Esquema conceitual Escola na notação do diagrama de classes UML. 
Sistema de Banco de Dados 
Marcio Quirino - 33 
 
Após as etapas de levantamento de requisitos e criação do DER, estamos quase prontos para 
conhecermos a construção do banco de dados propriamente dito. Construiremos um modelo de dados de 
mais baixo nível, que vai depender da escolha do SGBD. Faremos isso na próxima fase: o projeto lógico. 
Projeto lógico 
O projeto lógico, também conhecido por modelo de dados de baixo nível, objetiva transformar o 
modelo conceitual em um modelo lógico, que depende do tipo de SGBD escolhido. Existem diversos 
modelos lógicos, por exemplo: Rede, hierárquico, relacional, orientado a objeto, grafos, chave-valor e XML. 
No entanto, atualmente, o mais popular é o relacional. Como exemplos de SGBD que fazem uso do modelo 
relacional, podemos citar: Oracle, MySQL, PostgreSQL, SQlite e Sql Server. 
Atenção 
É importante acompanharmos as tendências de mercado sobre o uso de tecnologias de banco de dados. No 
Explore +, no fim do tema, há indicaçãopara pesquisar sobre o portal que tem um ranking com atualização mensal 
sobre o uso de SGBDs. Confira. 
O modelo relacional de banco de dados surgiu na década de 1970 e representa os dados em 
estruturas chamadas tabelas. Cada tabela possui um nome e coluna(s) que compõe(m) a sua estrutura. 
Nossa tarefa é converter o modelo conceitual para o lógico relacional. Para isso, utilizaremos regras bem 
definidas, que dependem dos elementos do DER. 
No dia a dia, a conversão DER para o modelo lógico relacional é realizada com o auxílio de alguma 
ferramenta de modelagem. No entanto, todo profissional de tecnologia da informação precisa conhecer os 
princípios utilizados nessa conversão. A Figura 3 exibe as tabelas originadas das entidades do DER do 
nosso exemplo, construído na etapa de projeto conceitual. 
 
Figura 3 – Tabelas originadas do DER da Escola. 
No modelo relacional, as entidades de um DER são representadas sob o formato de tabelas, por 
isso, no exemplo, aparecem as tabelas CLIENTE e CURSO. Em especial, a mesma decisão foi tomada para 
representar o relacionamento INSCRICAO. Perceba que nesse ponto do projeto ainda não definiremos as 
características dos atributos, tais como tipos de dados e tamanho. Basta apenas que eles estejam vinculados 
às suas tabelas. 
Além da representação visual do projeto lógico, as tabelas podem ser expressas com o uso de 
representação textual. 
Exemplo 
A descrição a seguir corresponde às tabelas originadas das entidades do DER: 
• CLIENTE (idcliente, nome, datanascimento, CPF, email, telefone) 
• CURSO (idcurso, nome, cargahoraria, descricao) 
• INSCRICAO (idcurso,idcliente, datainscricao, datacancelamento) 
Sistema de Banco de Dados 
Marcio Quirino - 34 
 
Observe que, com base na representação textual, podemos dizer que: 
• Um cliente é caracterizado por um identificador, além de possuir as propriedades nome, data de 
nascimento, CPF, e-mail e telefone. 
• Um curso possui um identificador, além das propriedades nome, carga horária e descrição. 
• Uma inscrição associa um cliente a determinado curso, além de possuir as propriedades data de 
inscrição e data de cancelamento. 
Estamos finalizando a nossa jornada nas fases de um projeto de banco de dados. É chegada a hora 
de construir o projeto físico. 
Projeto físico 
Durante o projeto físico, definimos os detalhes de implementação dos objetos do banco de dados. 
No caso das tabelas, escolhemos os tipos de dados e tamanho das colunas, e especificamos se elas são 
opcionais ou obrigatórias. 
Os relacionamentos são definidos por uma restrição especial em alguma(s) coluna(s) da tabela em 
questão. Esse tipo de restrição é denominado chave estrangeira. Em geral, o projeto físico é realizado com 
o auxílio de alguma ferramenta gráfica de modelagem. Há inclusive ferramentas que funcionam online, 
muitas vezes com a política de oferecer acesso limitado a diversos recursos. 
Dica 
Para o nosso exemplo, escolhemos a ferramenta online denominada Vertabelo por ser bastante funcional e 
sem custos para fins educacionais. 
Ao iniciar o design do modelo, escolhemos o SGBD PostgreSQL como produto-alvo da modelagem. 
A Figura 4 representa o modelo físico enriquecido com detalhes de implementação compatíveis com o SGBD 
escolhido. 
 
Figura 4 – Modelo físico do estudo de caso Escola. 
Observe que, diferentemente do modelo lógico, cada coluna de tabela no modelo está especificada 
com detalhes relativos ao tipo de dados, além de restrições em algumas colunas indicadas pelos marcadores 
FK, PK e N. 
Na criação do esquema do banco de dados, nós utilizamos uma linguagem declarativa, denominada 
linguagem de consulta estruturada SQL. A parte da SQL que fornece essas funcionalidades é denominada 
Linguagem de Definição de Dados. A Figura 5 apresenta um script DDL SQL compatível com o modelo 
escola. 
Sistema de Banco de Dados 
Marcio Quirino - 35 
 
 
Figura 5 – Script DDL SQL compatível com o estudo de caso Escola. 
Um script SQL DDL é um conjunto de comandos que, no contexto do nosso exemplo, servirão para 
criar as tabelas do banco de dados escola. 
Vamos entender o propósito desse código? 
Observe que: 
• A declaração de cada tabela inicia com o comando CREATE TABLE ≪nometabela≫, conforme 
linhas 1, 9 e 15; 
• Todo cliente possui um identificador único (idcliente especificado na linha 8); 
• Todo curso possui um identificador único (idcurso especificado na linha 14); 
• Cada inscrição possui um identificador único, nesse caso composto por um par de colunas 
(idcurso, idcliente especificado na linha 20); 
• As linhas 21 e 22 garantem que a inscrição será processada envolvendo necessariamente um 
cliente e um curso previamente existentes no banco de dados. 
Resumindo 
Ao longo deste módulo, estudamos as fases de um projeto de banco de dados. Percebemos que 
esta é uma atividade que envolve as seguintes tarefas: 
1. Levantar requisitos de dados 
2. Construir um modelo de entidade e relacionamento 
3. Construir um modelo lógico 
4. Implementar o modelo físico 
As tarefas de um projeto de banco de dados não são estáticas, visto que os requisitos de dados 
podem evoluir, por exemplo, a partir da necessidade de adaptar o negócio a algum tipo de legislação, ou 
mesmo para tornar o trabalho do usuário mais eficiente. 
Verificando o aprendizado 
1. O projeto de banco de dados é dividido em várias etapas. Uma delas envolve a construção 
de um modelo que descreve a estrutura do banco de dados, com seus objetos, atributos e 
relacionamentos inerentes ao funcionamento do negócio alvo da modelagem, 
Sistema de Banco de Dados 
Marcio Quirino - 36 
 
independentemente de limitações tecnológicas, implementação ou até mesmo 
dispositivos de armazenamento. Esse modelo é denominado: 
Conceitual 
O modelo conceitual, construído na etapa de projeto conceitual, tem foco na criação de uma visão 
abstrata do banco de dados, facilitando o entendimento do modelo por parte do usuário final. Essa 
visão oculta detalhes de implementação, por exemplo, a respeito de como os dados serão 
armazenados. 
2. Assinale a afirmativa correta acerca das etapas de um projeto de banco de dados: 
Projeto físico: Descreve detalhes sobre tipos de dados e tamanho de colunas. É dependente 
da escolha de um SGBD. 
Na etapa de projeto físico, a partir da escolha de um SGBD, são definidos detalhes de mais baixo 
nível, dependentes das funcionalidades ofertadas pelo SGBD escolhido, visto que o resultado 
dessa etapa corresponde ao banco de dados físico. 
2. Diagrama de Entidade e Relacionamento 
Entidade 
De acordo com Heuser (2009), a entidade corresponde a uma representação do conjunto de objetos 
da realidade modelada sobre os quais se deseja manter informações no banco de dados. Em um DER, a 
entidade é representada por um retângulo e dentro dele definimos o nome da entidade. Vamos observar um 
exemplo na Figura 6. 
 
Figura 6 – Exemplo de representação gráfica de entidade. Nesse caso, o retângulo representa o conjunto de todos os alunos 
sobre os quais há interesse em manter informações no banco de dados. 
Relacionamento 
Heuser (2009) afirma que a propriedade de entidade que especifica as associações entre objetos é 
o relacionamento, o qual corresponde a um conjunto de associações entre ocorrências de entidades. Em 
um DER, representamos o relacionamento por meio de um losango ligado por linhas conectadas às 
entidades envolvidas. Vamos observar um exemplo na Figura 7. 
 
Figura 7 – Exemplo de representação gráfica de relacionamento. Nesse caso, há duas entidades, além do relacionamento 
POSSUI. Todo relacionamento pressupõe a existência dos objetos das entidades participantes. 
Autorrelacionamento 
Há casos em que um relacionamento envolve ocorrências de uma mesma entidade 
(autorrelacionamento). Em especial, é importante diferenciar o papel que cada ocorrência da entidade 
cumpre no contexto do relacionamento em questão. 
 
 
 
Sistemade Banco de Dados 
Marcio Quirino - 37 
 
Exemplo 
Suponha que, para cursar a disciplina Cálculo II, seja necessário ter conhecimentos em Cálculo I. Esse tipo de 
situação é conhecido por pré-requisito. A Figura 8 apresenta um autorrelacionamento envolvendo pré-requisitos a partir 
da entidade DISCIPLINA: 
 
Figura 8 – Exemplo de representação gráfica de autorrelacionamento. 
Podemos verificar que o modelo contempla: 
• Um conjunto de objetos classificados como disciplinas (entidade DISCIPLINA). 
• Um conjunto de associações. Cada associação (relacionamento PREREQUISITO) relaciona uma 
disciplina liberadora (que o aluno precisa ter cumprido) e uma disciplina liberada (que o aluno poderá 
cursar). 
Em nosso exemplo, Cálculo II é a disciplina liberada e Cálculo I, a liberadora. 
Cardinalidade de relacionamentos 
Até o momento, identificamos um relacionamento (POSSUI) entre as entidades CURSO e 
DISCIPLINA. No entanto, surgiram quatro importantes perguntas: 
1. Toda disciplina, para existir no banco de dados, tem de estar associada a algum curso? 
2. Uma disciplina pode estar associada a, no máximo, quantos cursos? 
3. Todo curso, para existir no banco de dados, tem que estar associado a alguma disciplina? 
4. Um curso pode estar associado a, no máximo, quantas disciplinas? 
Expressaremos essas respostas no DER, usando o conceito de cardinalidade em relacionamentos. 
A cardinalidade é um par ordenado sob a forma (mínima, máxima): 0 ou 1 para a mínima e 1 ou N para a 
máxima, com N representando valores maiores que a unidade. Vejamos um exemplo na Figura 8. 
 
Figura 8 – Exemplo de representação gráfica do relacionamento POSSUI, com as cardinalidades definidas. 
Podemos então responder: 
1. Toda disciplina, para existir no banco de dados, tem de estar associada a algum curso? 
• Não (cardinalidade mínima 0 expressa ao lado da entidade CURSO); 
2. Uma disciplina pode estar associada a, no máximo, quantos cursos? 
• Vários (cardinalidade máxima n expressa ao lado da entidade CURSO); 
3. Todo curso, para existir no banco de dados, tem que estar associado a alguma disciplina? 
• Não (cardinalidade mínima 0 expressa ao lado da entidade DISCIPLINA); 
4. Um curso pode estar associado a, no máximo, quantas disciplinas? 
• Várias (cardinalidade máxima n expressa ao lado da entidade DISCIPLINA). 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 38 
 
Atenção 
Cardinalidade de relacionamento 
Por convenção, cada par ordenado da cardinalidade diz respeito à participação da entidade localizada no lado 
oposto do relacionamento em questão. 
Relacionamento ternário 
Vamos modelar orientações de alunos em projetos, realizadas por docentes. Há três tipos de 
informações: 
1. Projeto; 
2. Aluno; e 
3. Docente. 
Estamos, portanto, diante de um relacionamento ternário. A Figura 9 apresenta a parte do DER 
contemplando esse requisito de dados. 
 
Figura 9 – Exemplo de relacionamento ternário. 
Cada ocorrência do relacionamento ORIENTACAO vincula três ocorrências de entidade: um projeto, 
um aluno a ser orientado e um docente orientador. Em um relacionamento ternário, especificamos cada par 
de cardinalidade com base na relação existente entre o par de cardinalidade restante. Veja a seguir o que 
expressa cada par de cardinalidade: 
A. Cardinalidade máxima 1 
✓ Expressa no modelo ao lado da entidade DOCENTE, diz respeito ao par (ALUNO, 
PROJETO). Um aluno participante de um projeto pode ser orientado por no máximo um 
docente. 
B. Cardinalidade máxima n 
✓ Expressa no modelo ao lado da entidade ALUNO, diz respeito ao par (DOCENTE, 
PROJETO). Um docente participante de um projeto pode orientar diversos alunos. 
C. Cardinalidade máxima n 
✓ Expressa no modelo ao lado da entidade PROJETO, diz respeito ao par (ALUNO, 
DOCENTE). Um aluno e um docente podem participar de vários projetos. 
Atributo 
Entidades e relacionamentos podem ter propriedades, que são especificadas pelos atributos. 
[...] Atributo corresponde a um dado que é associado a cada ocorrência de uma entidade ou de um 
relacionamento. 
(HEUSER, 2009) 
Vamos especificar algumas propriedades para as entidades CURSO e DISCIPLINA: 
• Todo curso possui um código único, nome e, opcionalmente, data de criação. 
• Toda disciplina possui um código único, nome e carga horária. 
A Figura 10 apresenta a parte do DER contemplando esses requisitos de dados: 
Sistema de Banco de Dados 
Marcio Quirino - 39 
 
 
Figura 10 – DER contemplando atributos das entidades CURSO e DISCIPLINA. 
Percebemos que os atributos CODIGOCURSO e CODIGODISCIPLINA são únicos em suas 
respectivas entidades. Na prática, essa unicidade significa que: 
• Todo curso possui valor para o atributo CODIGOCURSO diferente dos demais 
• Toda disciplina possui valor para o atributo CODIGODISCIPLINA diferente das demais 
Esse tipo especial de atributo é conhecido por atributo identificador e sua representação gráfica é 
dada por um traço com uma das extremidades contendo um círculo preenchido. De acordo com os requisitos 
de dados, DATADECRIACAO é um atributo opcional, ou seja, não obrigatório. Sua representação gráfica é 
dada por um traço com uma das extremidades contendo um círculo pontilhado. Os demais atributos são 
obrigatórios. 
Cardinalidade em atributo 
No DER anterior, ao lado do atributo DATACRIACAO, há um par de cardinalidade com valor (0,1). A 
cardinalidade 0 expressa que o atributo é opcional. A cardinalidade 1 expressa que o atributo é 
monovalorado. Cada combinação de cardinalidade tem um significado especial, conforme Tabela 1: 
Cardinalidade Mínima Cardinalidade Máxima Significado 
0 1 Opcional, Monovalorado 
0 N Opcional, Multivalorado 
1 1 Obrigatório, Monovalorado 
1 N Obrigatório, Multivalorado 
Tabela 1 – Propriedade de atributo de acordo com a cardinalidade. 
Atributo obrigatório e monovalorado 
Na construção de um DER, a maioria dos atributos é monovalorado e obrigatório. Assim, adotaremos 
a convenção de, nesses casos, não expressar no modelo a cardinalidade (1,1) por motivos de legibilidade. 
Assim, de agora em diante, quando não houver cardinalidade expressa em atributos de um DER, considere 
que eles são monovalorados e obrigatórios. 
Atributo composto 
Em modelagem, é comum surgirem atributos mais complexos, que podem ser subdivididos em partes 
menores; eles são conhecidos por atributos compostos. Por exemplo, um atributo endereço pode ser 
subdividido em logradouro, complemento, CEP e cidade. 
Modelo de entidade e relacionamento estendido 
O modelo de entidade e relacionamento estendido traz novos componentes semânticos. 
Estudaremos a especialização/generalização, além da entidade associativa. 
Especialização/Generalização 
Imagine que, além dos docentes, seja necessário gerenciar outros funcionários da instituição, como 
os analistas. Podemos deixar previsto que a IES pode ter funcionários que não são analistas nem docentes. 
Sistema de Banco de Dados 
Marcio Quirino - 40 
 
Queremos, ainda, saber a formação de graduação de cada docente. Surge, então, uma hierarquia, 
visto que docente é um subtipo de funcionário. Funcionário é um objeto mais genérico, estando, portanto, 
na posição superior da hierarquia. 
O mecanismo de especialização/generalização é representado por um triângulo, com a entidade 
mais genérica localizada na parte superior e a(s) entidade(s) especializada(s) na parte inferior. Vamos 
observar o DER na Figura 11 com os novos requisitos de dados. 
 
Figura 11 – DER com mecanismo de especialização/generalização. 
Nós podemos perceber que: 
• Todo funcionário possui um código único, além de nome e pelo menos um telefone 
• Há duas entidades especializadas: DOCENTE e ANALISTA. A entidade DOCENTE possui 
um atributo obrigatório GRADUACAO 
No mecanismo de especialização/generalização há o uso de herança de propriedades: Cada 
entidade especializada herda as propriedades da entidade mais genérica. Assim, todo docente herda as 
propriedadesde funcionário. 
Classificações para especialização/generalização 
Observe que perguntas surgem quando analisamos o DER apresentado anteriormente. 
• Pode existir funcionário que não seja nem docente nem analista? 
• Pode existir funcionário que seja docente e analista? 
A classificação total/parcial responde ao primeiro questionamento: Se a resposta for não, a 
especialização é total. Caso contrário, parcial. O segundo é respondido com auxílio da classificação 
exclusiva/compartilhada: Se a resposta for não, a especialização é exclusiva. Caso contrário, compartilhada. 
As combinações das classes estão expressas na Tabela 2: 
 Exclusiva(x) Compartilhada(c) 
Total(t) tx tc 
Parcial(p) px pc 
Tabela 2 – Classificação do mecanismo de especialização/generalização. 
Exemplo 
Vamos convencionar respostas às perguntas realizadas: 
1. Pode existir funcionário que não seja nem docente nem analista? Sim. 
2. Pode existir funcionário que seja docente e analista? Sim. 
Agora vamos observar o DER na Figura 12, já com a com informação (pc) sobre a classificação do mecanismo 
de especialização/generalização. 
Sistema de Banco de Dados 
Marcio Quirino - 41 
 
 
Figura 12 – DER com mecanismo de especialização/generalização fazendo uso das classificações parcial e compartilhada. 
No exemplo, parcial significa que pode existir funcionário não especializado, ou seja, não classificado 
como docente ou analista. Por fim, compartilhado significa que no contexto da IES pode existir funcionário 
que atue como docente e na função de analista. 
Entidade associativa 
É comum a necessidade de vincular entidade a algum relacionamento. Ao modelarmos a inscrição 
de alunos em disciplinas, criaremos turmas para serem associadas às disciplinas que serão liberadas para 
inscrição. Suponha que: 
• Toda turma possui código, descrição e data de criação. Além disso, pode estar associada a 
diversas disciplinas. Uma disciplina pode ser ofertada em várias turmas. 
• Ao ofertar uma disciplina, é necessário saber o número de vagas e quando o aluno fez 
inscrição na mesma. 
Haverá um relacionamento (OFERTA) entre TURMA e DISCIPLINA. OFERTA deverá estar 
associada a ALUNO, via relacionamento INSCRICAO. Como resolver esse impasse? O objeto entidade 
associativa surgiu como alternativa de modelagem em situações dessa natureza. Ela é representada por um 
losango desenhado dentro de um retângulo. 
Observe o modelo na Figura 13: 
 
Figura 13 – DER com os novos requisitos de dados, fazendo uso de entidade associativa. 
É necessário enxergar OFERTA sob duas perspectivas: 
A. Relacionamento 
✓ OFERTA possui atributo VAGAS, útil no planejamento das turmas e disciplinas que serão 
ofertadas para inscrição. 
B. Entidade 
✓ OFERTA útil para identificar a turma e a disciplina escolhida pelo aluno quando do momento 
de uma inscrição. 
Sistema de Banco de Dados 
Marcio Quirino - 42 
 
Resumindo 
No segundo módulo, estudamos os componentes de um diagrama de entidade e relacionamento 
(DER). Além disso, conhecemos elementos do modelo de entidade e relacionamento estendido. 
Verificando o aprendizado 
1. Considere o DER a seguir sobre inscrição em concurso público. Qual proposição está 
correta? 
 
De acordo com o modelo apresentado, um CANDIDATO pode inscrever-se em mais de um 
EXAME. 
A proposição da alternativa C está correta, pois a informação sobre o número de vezes em que 
um CANDIDATO pode fazer inscrição em exames é definido pela cardinalidade máxima n, 
expressa ao lado da entidade EXAME. 
2. Considere o DER a seguir. Quais proposições estão corretas? 
 
I. Todo funcionário está alocado em um departamento. 
II. Não pode existir mais de um cargo com o mesmo salário. 
III. SALARIO é considerado um atributo obrigatório em CARGO. 
IV. CODIGOCARGO é considerado um atributo obrigatório na entidade CARGO. 
V. O atributo nome da entidade FUNCIONARIO é do tipo composto. 
III e IV 
A proposição III está correta, pois, em nosso estudo, convencionamos que todo atributo sem a 
cardinalidade explícita será considerado obrigatório e monovalorado. A proposição IV está 
correta, pois todo atributo identificador por padrão é obrigatório. 
3. Modelagem de Entidades e Relacionamentos 
Objetivos ao construir um DER 
Um DER deve capturar as partes mais importantes do negócio sendo modelado, pois pessoas 
diferentes precisam ter o mesmo entendimento do modelo. Manter um DER atualizado facilita a vida dos 
profissionais de TI, já que, com a documentação atualizada, a curva de aprendizado sobre a organização 
pode ser minimizada. 
Sistema de Banco de Dados 
Marcio Quirino - 43 
 
Apesar de ser relativamente simples construir um DER, é comum identificarmos propriedades 
desejáveis no banco de dados que precisam ser registradas, mas não podem ser expressas diretamente no 
modelo. Na linguagem técnica de banco de dados, regras que devem ser obedecidas pelo SGBD em relação 
ao banco de dados são conhecidas por restrições de integridade. 
Há restrições de integridade expressas por meio de algum elemento do próprio DER, por exemplo, 
ao definirmos cardinalidade para algum atributo. No entanto, há restrições que precisam ser expressas em 
separado, normalmente usando linguagem natural. Essas, normalmente, são conhecidas como restrições 
semânticas. 
Exemplo 
Podemos estabelecer que, no relacionamento de orientação realizado por docentes aos alunos no contexto de 
um projeto, a data de término da orientação nunca deve ser menor que a data de início. Estamos diante de uma 
restrição que leva em conta dois atributos de relacionamento definidos no DER. Nós especificamos essa restrição no 
DER com o uso de linguagem natural sob a forma de um texto. Veja na Figura 14 como ficou o modelo: 
 
Figura 14 – DER com uma restrição semântica adicionada sob o formato de um texto. 
Atenção 
O quanto devo modificar um DER para registrar restrições de integridade? 
O objetivo fundamental na construção de um DER é projetar um banco de dados e não descrever todas as 
restrições de integridade. 
Modelagem de Entidades E Relacionamentos 
A partir de agora, daremos ênfase no processo de modelagem de entidades e relacionamentos. 
No entanto, modelos diferentes podem obter o mesmo resultado prático? 
Equivalência entre modelos 
[...] Para fins de projeto de banco de dados, dois modelos ER são equivalentes quando ambos geram o mesmo 
esquema de banco de dados. 
(HEUSER, 2009) 
Exemplo 
Observe o DER expresso na Figura 15: 
 
Figura 15 – DER associando disciplinas a cursos, com uso de relacionamento N:N. 
Sistema de Banco de Dados 
Marcio Quirino - 44 
 
Ao analisarmos o DER, percebemos que a cardinalidade máxima do relacionamento POSSUI é do tipo N:N. 
Sendo assim, um modelo equivalente sem uso de relacionamento N:N será criado, onde POSSUI será modelado como 
entidade, conforme expresso na Figura 16: 
 
Figura 16 – DER associando disciplinas a cursos, sem relacionamento N:N. 
Generalizando, todo relacionamento N:N pode ser transformado em entidade. Para isso, basta seguir 
as etapas a seguir. 
1. Representar o relacionamento N:N como uma entidade. 
2. Relacionar a entidade criada na etapa 1 às entidades participantes do relacionamento 
original. 
3. Adicionar à entidade criada na etapa 1 o(s) atributo(s) − caso exista(m) − do relacionamento 
original. 
4. A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades 
participantes do relacionamento original. 
5. Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento 
vinculado a ela. 
Saiba mais 
Para complementar o nosso entendimento, a seguir adicionamos observações sobre o nosso modelo, de 
acordo com as etapas apresentadas anteriormente. 
1. Representar o relacionamento N:N como uma entidade: Foi criada a entidade POSSUI. 
2. Relacionar a entidade criada na etapa 1 às entidades participantes do relacionamento original: A entidade 
POSSUI foi relacionadaàs entidades CURSO e DISCIPLINA. 
3. Adicionar à entidade criada na etapa 1 o(s) atributo(s) − caso exista(m) − do relacionamento original: Como 
não havia atributos no relacionamento original, a entidade POSSUI foi criada sem atributos. 
4. A entidade criada na etapa 1 será identificada pelos relacionamentos com as entidades participantes do 
relacionamento original: Esta identificação está representada no modelo com as linhas mais espessas 
saindo da entidade POSSUI. 
5. Estabelecer a cardinalidade (1,1) da entidade criada na etapa 1 para cada relacionamento vinculado a ela: 
As cardinalidades estão representadas ao lado da entidade POSSUI. 
Atenção 
O relacionamento POSSUI só será cadastrado no banco de dados se houver tanto uma disciplina quanto um 
curso. Essa observação é consequência da definição de relacionamento em modelagem de dados. Assim, quando 
transformamos um relacionamento em entidade, essa restrição deve ser mantida. De que maneira? 
No DER modificado, as linhas mais espessas saindo da entidade POSSUI representam a restrição de que toda 
ocorrência desta entidade é dependente da existência tanto de uma disciplina quanto de um curso. Alguns autores 
chamam entidade fraca a uma entidade que depende de outra(s) para existir. 
Sistema de Banco de Dados 
Marcio Quirino - 45 
 
Modelagem de entidade isolada 
O DER que nós estamos modelando é referente ao funcionamento de uma única IES. Em função 
disso, não há necessidade de informar no banco de dados em qual instituição o aluno está cadastrado ou 
mesmo à qual IES os cursos estão relacionados. 
[...] Uma entidade isolada é uma entidade que não apresenta relacionamento com outras entidades. 
HEUSER, 2009. 
No contexto do nosso DER, uma entidade isolada pode servir para modelar características da IES, 
tais como código e CNPJ. Portanto, se decidirmos adicionar uma entidade INSTITUICAO ao nosso modelo, 
esta deverá permanecer isolada, dado que, de acordo com os requisitos de dados, o banco de dados refere-
se a uma única IES. A Figura 17 representa a entidade isolada INSTITUICAO e seus atributos: 
 
Figura 17 – DER com entidade isolada IES. 
Observe que com a entidade INSTITUICAO criada, caso haja necessidade de acrescentar outras 
características simples à IES, basta adicionar atributos. Por exemplo, poderíamos adicionar informações 
sobre data de criação, nome da IES, telefone, entre outras. 
Quando manter histórico 
Em nosso modelo acadêmico, vamos considerar que surgiu a necessidade de associar docente a 
departamento. Essa é uma necessidade comum em praticamente toda IES: Saber quais professores 
pertencem a qual departamento. 
Vamos supor que, após o surgimento dessa demanda, nós levantamos os seguintes requisitos de 
dados: 
• Todo departamento é identificado por um código e possui um nome. 
• Um docente pode estar associado a, no máximo, um departamento. 
Com base nos requisitos, construímos o DER mostrado na Figura 18. 
 
Figura 18 – DER associando docente a departamento. 
Nós podemos perceber que o DER construído está de acordo com os novos requisitos de dados, 
pois: 
• As informações dos departamentos estão expressas na entidade DEPARTAMENTO. 
• A restrição de que um docente está associado a, no máximo, 1 departamento está expressa 
na cardinalidade máxima 1 ao lado da entidade DEPARTAMENTO. 
Sistema de Banco de Dados 
Marcio Quirino - 46 
 
Ora, os requisitos de dados associados a um projeto de banco de dados podem sofrer alterações ao 
longo do tempo. Assim, é necessário planejarmos uma estratégia para refletir as restrições impostas pelo 
novo cenário. Vamos supor, então, o surgimento de novo requisito de dados: 
• É necessário armazenar no banco de dados a movimentação de docentes entre 
departamentos. 
• A atuação do docente em um departamento possui uma data de início e uma data de fim. 
Esse novo requisito de dados pode ser interpretado como uma necessidade institucional de manter 
histórico das movimentações de docentes entre departamentos. O DER contemplando o novo requisito está 
expresso na figura a seguir: 
 
Figura 19 – DER associando docente a departamento, contendo histórico das movimentações. 
Podemos perceber que, no novo DER: 
• A cardinalidade máxima N expressa ao lado da entidade DEPARTAMENTO indica que ao 
longo do seu ciclo profissional um docente pode ter passado por diversos departamentos da 
IES. 
• A atuação do docente em um departamento é caracterizada por uma data de início e uma 
data de fim. 
Perceba que o DER contemplando o novo requisito de dados é semelhante ao DER original. A 
diferença foi a alteração de uma cardinalidade máxima, além da adição de dois atributos no relacionamento. 
Mais sobre modelagem de entidades e relacionamentos 
Você deve ter notado que um DER não é construído em uma única etapa. Em projetos de banco de 
dados reais, a construção de um DER é um processo incremental, ou seja, o modelo vai sendo modificado 
e enriquecido de forma gradativa à medida que novos requisitos de dados sejam levantados. 
Ao longo dos exemplos que construímos, nós utilizamos uma estratégia que envolveu a modelagem 
de conceitos mais abstratos que em seguida foram sendo detalhados. Em geral, identificamos algumas 
entidades e depois definimos seus atributos e relacionamentos. Esta estratégia de modelagem que 
escolhemos é conhecida por estratégia descendente. O passo a passo a seguir resume etapas utilizadas 
ao adotarmos esse tipo de estratégia para construção do diagrama de entidade e relacionamento. 
1. Modelo inicial 
• Identificar entidades; 
• Identificar relacionamentos, especializações e cardinalidade máxima de relacionamentos; 
• Mapear atributos de entidades e relacionamentos; 
• Mapear identificadores de entidades e relacionamentos. 
2. Modelo detalhado 
• Definir as cardinalidades dos relacionamentos; 
Sistema de Banco de Dados 
Marcio Quirino - 47 
 
• Identificar outras restrições de integridade. 
3. Validação 
• Revisar o modelo; 
• Validar o modelo junto ao usuário. 
É importante observarmos que em qualquer etapa é possível retornar à etapa anterior, dado que 
estamos diante de uma construção que envolve um DER que ocorre de forma gradativa. 
Resumindo 
Ao longo deste módulo, estudamos a construção de um DER com ênfase na modelagem de 
entidades e relacionamentos. Percebemos que modelos diferentes podem ser gerados a partir dos mesmos 
requisitos de dados. Outro importante item que exploramos diz respeito a modificações em um DER com 
objetivo de registrar histórico de informações. Aprendemos, ainda, que a construção de um DER é um 
processo sistemático e incremental, em que é possível refinar o modelo em cada etapa. 
Verificando o aprendizado 
1. Uma cafeteria que comercializa produtos alimentícios realiza compras diárias de uma 
cooperativa e está enfrentando dificuldades por causa de gestão do prazo de validade de 
seus produtos. 
O proprietário vai investir em um sistema que realizará o controle do estoque e do prazo 
de validade tomando como base a data de compra de cada produto adquirido da 
cooperativa. O DER parcial a seguir representa a modelagem de dados proposta por um 
profissional, sendo que o atributo código em cada entidade é único. 
 
A partir das informações, é correto afirmar que: 
É possível construir um novo DER modelando estoque como entidade, sem perda de 
informação em relação ao modelo original. 
De fato, quando o DER tem relacionamento N:N, é possível construir um modelo equivalente, 
em que o relacionamento em questão será substituído por uma entidade, mantendo a semântica 
do modelo original. 
2. Uma rede de operadoras de planos de saúde necessita de um sistema para controlar seus 
contratos junto à rede credenciada de hospitais. Cada contrato entre a operadora e um 
hospital tem duração de dois anos. Após o término desse prazo, um novo poderá ser 
emitido, caso haja interesse entre as partes. Qual alternativa a seguir representaum DER 
adequado aos requisitos de dados apresentados? 
Sistema de Banco de Dados 
Marcio Quirino - 48 
 
 
De fato, de acordo com os requisitos de dados, uma operadora pode realizar diversos contratos 
com o mesmo hospital e vice-versa. Isso implica que a cardinalidade máxima do relacionamento 
CONTRATO seja do tipo N:N. Além disso, os atributos DATAINICIO e DATAFIM são 
propriedades associadas ao relacionamento CONTRATO, permitindo recuperar informações 
históricas. 
4. Modelagem de atributos 
Atributo X Entidade 
Em todos os exemplos que desenvolvemos até o momento, caracterizamos entidades e 
relacionamentos com o auxílio da especificação de atributos. No entanto, em algumas situações, modelar 
um objeto como atributo pode não ser a melhor alternativa. 
No contexto do nosso exemplo acadêmico, é necessário que todo docente tenha pelo menos uma 
graduação registrada no banco de dados. Esse requisito está expresso no modelo a seguir. 
 
Figura 20 – DER com informação sobre o docente [graduação mapeada como atributo]. 
Precisamos lembrar que a graduação do docente está expressa sob o formato de atributo. 
• A cardinalidade mínima 1 significa que a informação é obrigatória. 
• A cardinalidade máxima N representa a informação de que é possível registrar no banco de 
dados diversos cursos associados ao docente. 
Exemplo 
Se diversos docentes são formados em Ciência da Computação, não faz muito sentido entrar com essa 
informação no sistema diversas vezes. Mesmo porque, em se tratando de informação textual, daria possibilidade de 
mais de uma forma de representação para o mesmo item. 
Caso, além da informação referente ao nome da graduação, quiséssemos saber o ano em que o docente se 
formou, estaríamos diante de uma situação em que o mais adequado seria modelar o objeto graduação como uma 
entidade. Assim, diante do novo cenário, o modelo modificado está representado na Figura 21. 
Sistema de Banco de Dados 
Marcio Quirino - 49 
 
 
Figura 21 – DER com informação sobre o docente [graduação mapeada como entidade]. 
Vamos perceber que no novo DER: 
• O objeto graduação foi mapeado sob o formato de entidade. 
• É possível cadastrar graduações sem vínculo algum a qualquer docente. Essa conclusão ocorre em 
função da cardinalidade mínima 0 expressa ao lado da entidade DOCENTE. 
• Todo docente necessariamente possui uma graduação. Essa conclusão ocorre em função da 
cardinalidade mínima 1 expressa ao lado da entidade GRADUACAO. 
Finalmente, se estivéssemos interessados em modelar um atributo ANOFIM com objetivo de saber o ano de 
término da graduação pelo docente, bastaria adicionarmos esse atributo ao relacionamento DOCENTEGRAD. 
Atributo X Especialização 
Uma situação comum durante a construção de um DER é decidir entre modelar um objeto sob o 
formato de atributo ou especialização. O critério a ser usado na decisão é simples: Caso o objeto em questão 
possua atributo(s) ou mesmo relacionamento(s), usa-se a especialização. 
No DER apresentado, a entidade FUNCIONARIO foi especializada. Devemos perceber que a 
entidade DOCENTE está relacionada com a entidade GRADUACAO. Portanto, houve escolha coerente com 
o critério apresentado. 
Atributo Opcional 
Há situações em que surgem diversos atributos opcionais em uma entidade. Devemos, portanto, 
estar atentos para perceber se os atributos em questão indicam prováveis entidades especializadas. 
Exemplo 
Suponha que, a partir de agora, tenhamos que saber se determinado funcionário tem registro na Ordem dos 
Advogados do Brasil (OAB) ou na Associação Brasileira de Odontologia (ABO). Assim, diante do novo cenário, o 
modelo modificado está representado na Figura 22. 
Sistema de Banco de Dados 
Marcio Quirino - 50 
 
 
Figura 22 – DER com informação sobre OAB e ABO. 
No DER, foram adicionados os atributos OAB e ABO à entidade FUNCIONARIO. Devemos perceber que 
ambos são opcionais, no entanto, não sabemos quais combinações de atributos são válidas. Por exemplo, um 
funcionário pode ter atributos ABO e OAB? 
Se realizarmos uma análise mais criteriosa no modelo, vamos perceber que os atributos ABO e OAB parecem 
ocultar diferentes categorias: Advogados e odontólogos. Sendo assim, vamos modificar o modelo optando por modelar 
os atributos ABO e OAB como entidades especializadas de FUNCIONARIO. Logo, o modelo a seguir representa as 
mudanças. 
 
Figura 23 – DER com informação sobre OAB e ABO modeladas com uso do mecanismo de especialização. 
Finalmente, devemos perceber que a estratégia adotada tem a vantagem de modelar a realidade com mais 
fidelidade, ao mesmo tempo que evitou modelagem de atributos opcionais na entidade FUNCIONARIO. 
Atributo Multivalorado 
Em nosso DER, vamos supor que, a partir de agora, seja necessário modelar que um funcionário 
pode ter dependente(s). Ora, vamos perceber que uma primeira linha de raciocínio para realizar a 
modelagem desse novo requisito de dados é adicionar um atributo opcional na entidade FUNCIONARIO, 
conforme expresso na Figura 24. 
 
Figura 24 – DER com informação sobre dependente(s) modelada sob a forma de atributo multivalorado. 
Há dois motivos para evitarmos esse tipo de modelagem: 
• Ao construirmos o modelo físico, vamos perceber que não existe uma implementação direta 
para atributos multivalorados em um SGBD relacional 
Sistema de Banco de Dados 
Marcio Quirino - 51 
 
• Na maioria dos casos, atributos multivalorados escondem atributos e relacionamentos 
É desejável que o banco de dados possa controlar, por exemplo, o nome e a data de nascimento de 
cada dependente. De forma semelhante, seria igualmente desejável diferenciar o tipo ou a categoria de cada 
telefone pertencente ao funcionário. 
Exemplo 
O DER a seguir apresenta tanto a modelagem de dependentes quanto a de telefone sob a perspectiva de 
entidades relacionadas à entidade FUNCIONARIO: 
 
Figura 25 – DER com informações sobre dependente(s) e telefone(s) modeladas sob o formato de entidade. 
Podemos observar que, após a decisão de modelar os objetos dependente e telefone como entidades 
relacionadas à entidade FUNCIONARIO, além de termos eliminado atributos opcionais, conseguimos deixar o modelo 
mais preciso, legível e com a possibilidade de adicionar novos atributos para as entidades de maneira mais natural. 
Atributo X Redundância 
Estamos chegando ao final do nosso módulo e do tema referente ao assunto de modelagem 
conceitual. No entanto, é necessário observar a uma situação muito comum em modelagem de dados: 
atributos redundantes. 
Atributos redundantes 
Atributos redundantes são atributos deriváveis a partir da execução de procedimentos de busca de dados e/ou 
cálculos sobre o banco de dados (HEUSER, 2009). 
Exemplo 
Em nosso exemplo acadêmico, vamos supor que seja necessário sabermos a quantidade de dependentes de 
cada funcionário. Além disso, precisamos identificar, para cada dependente, o número de matrícula do funcionário 
responsável. 
O uso de atributos redundantes está expresso na figura a seguir, propositalmente em destaque: 
Sistema de Banco de Dados 
Marcio Quirino - 52 
 
 
Figura 26 – DER com atributos redundantes. 
Devemos perceber que: 
• Não é necessário manter o atributo QTDEDEPENDENTES na entidade FUNCIONARIO, pois a 
informação sobre a quantidade de funcionários pode ser obtida a partir de um simples processo de 
cálculo envolvendo o relacionamento. 
• Não é necessário manter o atributo CODIGOFUNCIONARIO na entidade DEPENDENTE, pois seu 
valor pode ser obtido ao acessar a entidade FUNCIONARIO através do relacionamento. 
Finalmente, atributos redundantes devem ser omitidos do DER, uma vez que esse tipo de modelo não 
diferencia atributos redundantes dos sem redundância. 
Atributo Composto 
O atributo composto pode ser dividido em subpartes ou atributos básicos com significados próprios. 
Exemplo 
Em nosso DER, para fins ilustrativos, nós inicialmente modelamos o endereço do aluno através de umatributo 
composto subdividido em logradouro e complemento. Se adicionarmos mais alguns atributos básicos representativos 
de outras partes de um endereço, teremos um DER como a seguir. 
 
Figura 27 – DER representando a entidade ALUNO com atributo composto endereço. 
Como desvantagem, o modelo ficou com um visual bastante denso. Por outro lado, é comum modelarmos o 
objeto alvo do atributo composto sob o formato de entidade relacionada à entidade principal. Vamos então observar 
essa mudança na figura a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 53 
 
 
Figura 28 – DER representando endereço como entidade. 
Perceba que, após eliminarmos o atributo composto, o modelo ficou menos poluído visualmente, tornando-se 
mais legível. 
Resumindo 
Ao longo da nossa jornada neste módulo, demos ênfase ao processo de modelagem de atributos. 
Estudamos diretrizes importantes que devemos levar em consideração ao nos depararmos com atributos 
opcionais, multivalorados ou mesmo compostos. Percebemos, ainda, que devemos evitar a modelagem de 
atributos redundantes. 
Verificando o aprendizado 
1. O DER a seguir representa informações sobre clientes. 
 
No que se refere à modelagem dos atributos, assinale a alternativa verdadeira: 
É mais adequado modelar telefone em uma entidade separada, relacionada à entidade 
CLIENTE. 
Em um SGBD relacional não há implementação direta para atributo multivalorado, como é o caso 
de TELEFONE. Além disso, o modelo fica mais legível quando modelamos TELEFONE em 
entidade própria. 
2. O DER a seguir representa informações sobre funcionários e seus dependentes. 
 
No que se refere à modelagem dos atributos, assinale a alternativa verdadeira: 
O atributo CODIGOFUNCIONARIO da entidade DEPENDENTE é redundante. 
Sistema de Banco de Dados 
Marcio Quirino - 54 
 
De fato, há redundância, visto que é possível localizar o funcionário responsável por cada 
dependente ao acessar a entidade FUNCIONARIO através do relacionamento. 
Considerações Finais 
Este tema apresentou as principais etapas de um projeto de banco de dados, iniciando pelo 
levantamento de requisitos e, em seguida, passando pelos projetos conceitual, lógico e físico. Foram 
examinados os elementos presentes em um DER, bem como o mecanismo de especialização/generalização 
e o de entidade associativa, pertencentes ao modelo de entidade e relacionamento estendido. 
Finalmente, praticamos a atividade de modelagem, inicialmente com foco em entidades e 
relacionamentos, terminando com o estudo de exemplos envolvendo a modelagem de atributos. 
Referências 
CANDIDO, C. H. brModelo 3.20. GitHub, 2019. 
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7. ed. São Paulo: Pearson, 2019. 
HEUSER, C. A. Projeto de Banco de Dados. 6. ed. Porto Alegre: Bookman, 2009. 
Explore+ 
Como vimos, um projeto de banco de dados envolve diversas etapas bem definidas. Além disso, a 
construção de um DER é um processo incremental, sendo possível que o diagrama seja revisado e alterado 
para atender a novos requisitos de dados. Por isso, é importante você pesquisar o Guia da Modelagem de 
Dados: introdução & modelo conceitual, de Felipe Almeida. 
Pesquise sobre a ferramenta Vertabelo, citada neste tema. 
Visite o portal DB-engines para ver o ranking, atualizado mensalmente, sobre o uso de SGBDs. 
Exercícios 
1. Logo da análise dos requisitos de um projeto de banco de dados para representar as 
estradas de um País, obteve-se as seguintes especificações: 
As estradas são descritas pelo nome oficial, apelido (pode ser mais de um), tipo, extensão. 
As estradas se classificam em: Federais, estaduais e municipais. 
As estradas se dividem em trechos. Porém um trecho pertence sempre a única estrada e 
não poderá fazer parte de outra estrada. Existe o trecho inicial e trecho final de uma 
estrada. 
Na criação de um modelo de entidades-relacionamento para o problema descrito acima, 
marque a alternativa correta: 
TRECHO pode ser modelada como uma entidade fraca com relação a ESTRADA. 
2. Em Modelo de Entidade de Relacionamento, possuímos entidades e atributos. A esse 
respeito, analise as assertivas e assinale a alternativa que aponta a(s) correta(s). 
 
I. O objeto básico de um MER é uma entidade, "algo" do mundo real, com uma existência 
independente. 
II. Uma entidade pode ser um objeto com uma existência física (por exemplo, uma pessoa, 
um carro, uma casa ou um funcionário) ou um objeto com uma existência conceitual (por 
exemplo, uma empresa, um trabalho ou um curso universitário). 
III. Os valores dos atributos que descrevem cada entidade se tornarão a maior parte dos 
dados armazenados no banco de dados. 
Sistema de Banco de Dados 
Marcio Quirino - 55 
 
IV. Cada entidade tem atributos ¿ propriedades particulares que a descrevem. Por 
exemplo, uma entidade empregada pode ser descrita pelo nome do empregado, idade, 
endereço, salário e trabalho (função). 
I, II, III e IV. 
3. Em alguns casos, dois ou mais valores de atributos em um modelo de Entidade-
Relacionamento estão relacionados. Por exemplo, os atributos Idade e Data de Nascimento 
de uma pessoa. Para uma Entidade − Pessoa em particular, o valor de Idade pode ser 
determinado pela data corrente e o valor de Data de Nascimento da pessoa. Portanto, o 
atributo Idade é chamado atributo ...I... do atributo Data de Nascimento, que, por sua vez, 
é chamado atributo ...II... . 
 
As lacunas I e II são, correta e respectivamente, preenchidas com: 
derivado – armazenado 
4. Na nomenclatura de banco de dados, restrição corresponde a uma regra que deve ser 
obedecida pelo SGBD. Seja a restrição "um funcionário não pode ter salário maior que seu 
chefe imediato", esta deve ser classificada como restrição de: 
Semântica 
5. Em relação aos conceitos de bancos de dados, é correto afirmar que: 
Em uma generalização/especialização total, para cada ocorrência da entidade genérica, 
existe sempre uma ocorrência em uma das entidades especializadas. 
 
Sistema de Banco de Dados 
Marcio Quirino - 56 
 
Projeto de Banco de Dados: Modelagem Lógica e 
Física 
Definição 
Componentes do modelo relacional. Formas normais e normalização de dados. 
Mapeamento conceitual-lógico: 
Entidades, relacionamentos, atributos e especialização/generalização. Diretrizes para 
implementação do modelo no SGBD (Sistema de Gerenciamento de Banco de Dados). 
Propósito 
Conhecer os elementos do modelo relacional e as formas normais é essencial para aprender sobre 
as regras utilizadas no mapeamento conceitual-lógico. É importante compreender os aspectos físicos que 
influenciam a implementação do modelo no SGBD, pois são atividades da rotina dos profissionais de banco 
de dados. 
Preparação 
É recomendável que você reproduza os exemplos práticos usando uma ferramenta para modelagem 
de dados. Certifique-se de ter baixado para seu computador a ferramenta livre BrModelo. 
Introdução 
Ao longo deste tema, vamos conhecer os principais conceitos e componentes do modelo relacional. 
Aprenderemos que o modelo relacional representa o banco de dados sob o formato de tabelas, estando 
presente em diversos sistemas gerenciadores de banco de dados (SGBD), tais como MySQL, Oracle, 
PostgreSQL e SQL Server. 
Ainda, vamos estudar o processo de Normalização como forma de avaliar a qualidade de um projeto 
de banco de dados relacional. Em seguida, aprenderemos regras que deverão ser aplicadas para obtermos 
um modelo lógico a partir de um modelo conceitual. 
Finalmente, investigaremos alguns aspectos físicos que devem ser levados em consideração na 
implementação do modelo no SGBD. 
1. Modelo Relacional 
Relação é um termo usado na literatura formal da área de banco de dados. No contexto comercial, 
usa-se informalmente o termo tabela. 
O modelo relacional representa o banco de dados como uma coleção de relações 
(ELMASRI; NAVATHE, 2019). 
Componentes de uma tabela 
Uma tabela corresponde a um conjunto não ordenadode linhas, que, na terminologia acadêmica, 
são conhecidas por tuplas. 
As linhas de uma tabela são divididas em campos ou colunas, que, na academia, são chamados de 
atributos. Os campos são nomeados com objetivo de facilitar a interpretação dos dados armazenados. 
Observe a tabela ALUNO a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 57 
 
 
Figura: Componentes de uma tabela de banco de dados. 
Nome de tabelas 
Em um banco de dados relacional, toda tabela deve possuir um nome único. Além disso, ao longo 
do nosso estudo, vamos perceber que a maioria das tabelas de um banco de dados representa entidades 
de um diagrama de entidade e relacionamento (DER). 
Atenção 
É importante que, na medida do possível, o nome da tabela represente com clareza o objeto modelado. Por 
exemplo, ao lermos o nome ALUNO, criamos a expectativa natural de que a tabela em questão armazene informações 
sobre alunos. 
Colunas de tabelas 
A primeira linha da tabela de exemplo contém os seguintes campos ou cabeçalhos de coluna: 
CODIGOALUNO, NOME, NOMEMAE, CPF e DTNASCIMENTO. Além disso, o nome de coluna deve ser 
único em cada tabela. 
Com isso, percebe-se que o nome de coluna ajuda a entender o papel ou a finalidade dela. Por 
exemplo, podemos concluir que DTNASCIMENTO identifica a data de nascimento do aluno. 
Outro ponto é que as colunas de uma tabela são monovaloradas, ou seja, é permitido manter no 
máximo um item de informação por vez. Por exemplo, é possível existir até uma ocorrência de data de 
nascimento na coluna DTNASCIMENTO. 
As colunas de uma tabela possuem valores atômicos, ou seja, não admitem colunas compostas de 
outras. Por exemplo, não é possível subdividir CODIGODOALUNO em outros campos. 
Ao implementar uma tabela em um banco de dados, é necessário definir um tipo de dado para cada coluna. 
Os mais comuns são: caractere, numérico, data e booleano. 
Alguns SGBDs permitem a definição do tipo de dados feita pelo usuário. Em uma linguagem mais técnica, o 
conjunto de valores que uma coluna pode assumir é denominado domínio da coluna ou domínio do campo. 
Quando criarmos uma tabela, devemos definir se o valor da coluna é opcional ou obrigatório, em que 
especificar que uma coluna é opcional significa que os valores admitem vazio (NULL) ou nulo. Na tabela 
ALUNO, a coluna NOMEMAE da linha correspondente à aluna de código 1 está vazia. 
Sistema de Banco de Dados 
Marcio Quirino - 58 
 
Linhas de tabelas 
As linhas da tabela, da segunda em diante, representam um item de informação cadastrado no banco 
de dados. Dizemos então que um item de informação corresponde a uma unidade básica que servirá para 
armazenamento e recuperação de dados. Isto é, se uma tabela de cadastro de alunos contém 10.000 linhas 
ou registros, podemos dizer que ela armazena dados de 10.000 alunos. 
As linhas de uma tabela permitem o armazenamento de dados sempre de acordo com a semântica 
ou o significado do objeto. No caso em tela, a tabela armazena informações de ALUNOS, portanto queremos 
dizer que essa mesma tabela não deve ser utilizada para armazenar outros tipos de objetos, como disciplinas 
ou docentes. 
Chave Primária 
Em uma tabela, um SGBD precisa diferenciar uma linha das demais, isso é feito a partir da definição 
de uma restrição de integridade. Na prática, escolheremos uma ou mais coluna(s) para que seu(s) valores 
se torne(m) únicos no banco de dados. 
Atenção 
Quando escolhemos uma coluna para ser chave primária, dizemos que estamos diante de uma chave simples. 
Se escolhermos mais de uma coluna, a chave é dita composta. 
Vamos estudar um exemplo de chave primária simples? 
Para diferenciar um estudante dos demais na tabela ALUNO, podemos estabelecer a restrição de 
chave primária associada à coluna CODIGOALUNO. Ao fazermos isso, na prática, estamos delegando ao 
SGBD a responsabilidade de gerenciar essa restrição durante todo o ciclo de vida do banco de dados. Na 
tabela a seguir, deixamos em destaque a coluna CODIGOALUNO: 
 
Figura: Tabela ALUNO com destaque à coluna CODIGOALUNO, escolhida como chave primária simples. 
Assim, podemos dizer que toda chave primária tem as seguintes propriedades: 
Unicidade 
O valor da chave primária não permite repetição. 
Monovalorado 
Toda linha da tabela possui no máximo um valor de chave primária. 
Obrigatório 
Toda linha da tabela necessariamente tem que ter um valor para a coluna que é chave primária. Em outras 
palavras, nenhum valor de chave primária deve ser vazio. Esta propriedade é conhecida por restrição de integridade 
de entidade. 
Ao longo do nosso estudo, iremos aprender que alguns SGBDs permitem associar uma propriedade 
especial a um campo, denominada autoincremento. Por meio dessa propriedade, o SGBD incrementa 
Sistema de Banco de Dados 
Marcio Quirino - 59 
 
automaticamente o valor de uma coluna quando um registro é adicionado à tabela. Trata-se de um 
mecanismo útil para gerar um valor único para cada registro. 
Agora, vamos estudar um exemplo contendo chave primária composta. 
Considere a tabela a seguir, que representa dados de dependentes de funcionários: 
Dependente 
 
Figura: Tabela DEPENDENTE com destaque às colunas CODIGOFUNCIONARIO, NRDEPENDENTE escolhida como chave 
primária composta. 
A tabela possui uma chave primária composta pelo par de colunas CODIGOFUNCIONARIO, 
NRDEPENDENTE. Devemos notar que nenhuma das colunas que compõem a chave é suficiente para, 
isoladamente, diferenciar uma linha das demais, visto que: 
• Um CODIGOFUNCIONARIO pode aparecer em diferentes linhas da tabela; 
• Um NRDEPENDENTE pode aparecer em diferentes linhas da tabela. 
 
A. Chave Mínima 
✓ Uma chave primária deve ser mínima. Com isso, queremos dizer que todas as colunas que a 
formam devem ser necessárias e suficientes para diferenciar uma linha das demais na tabela. 
Outro ponto importante é que uma chave mínima não diz respeito ao quantitativo de colunas 
que a forma. 
✓ A chave primária simples (coluna CODIGOALUNO) da tabela ALUNO é mínima. Cada valor 
de CODIGOALUNO é suficiente para diferenciar um aluno dos demais. Perceba que, se 
decidíssemos definir o par de colunas CODIGOALUNO, CPF como chave primária composta 
para a tabela ALUNO, a chave não seria mínima, visto que CODIGOALUNO por si só é 
suficiente para diferenciar um estudante dos outros. 
✓ A chave primária composta (CODIGOFUNCIONARIO, NRDEPENDENTE) da tabela 
DEPENDENTE é mínima. Somente a coluna CODIGOFUNCIONARIO não diferencia um 
dependente dos demais, pois um funcionário pode ter diversos dependentes. De modo 
semelhante, somente a coluna NRDEPENDENTE não diferencia um dependente dos outros, 
dado que o valor dela aparece em mais de uma linha da tabela DEPENDENTE. 
B. Chave Candidata 
✓ Ao projetarmos uma tabela, pode ser que mais de uma coluna sirva para diferenciar uma linha 
das demais. Por exemplo, na tabela ALUNO, tanto CODIGOALUNO quanto CPF poderiam 
ser utilizados como chave primária. Logo, podemos dizer que CODIGOALUNO e CPF são 
chaves candidatas. 
C. Chave Alternativa 
✓ A partir do momento em que escolhemos CODIGOALUNO para ser a chave primária da 
tabela ALUNO, passamos a considerar CPF como uma chave alternativa. 
Sistema de Banco de Dados 
Marcio Quirino - 60 
 
✓ Alguns desenvolvedores preferem escolher para chave primária uma coluna artificial, ou seja, 
que não tenha dependência das colunas criadas, com objetivo de manter alguma informação 
referente ao negócio sendo modelado. 
Chave Estrangeira 
Um banco de dados relacional é composto por um conjunto de tabelas. Na maioria dos casos, existe 
algum tipo de relacionamento entre elas. O relacionamento entre tabelas é um dos conceitos fundamentais 
em projeto de banco de dados relacionais. 
 
Em geral, uma empresa possui informações sobre funcionários e seus dependentes. Vamos observar 
então a figura a seguir: 
 
Figura: Relacionamento entre FUNCIONARIO e DEPENDENTE. 
A figura permite as seguintes interpretações:• Todo dependente está associado a um funcionário. Por exemplo, o valor (1) de 
CODIGOFUNCIONARIO na tabela DEPENDENTE permite identificar o funcionário 
responsável, neste caso José Maciel; 
• Um funcionário pode ter diversos dependentes. Por exemplo, o valor (2) de 
CODIGOFUNCIONARIO nas duas últimas linhas da tabela DEPENDENTE permite concluir 
que o funcionário Pedro Antônio possui dois dependentes; 
• Um funcionário pode não ter dependentes. Por exemplo, o valor (3) de 
CODIGOFUNCIONARIO na tabela FUNCIONARIO não aparece na tabela DEPENDENTE. 
Sistema de Banco de Dados 
Marcio Quirino - 61 
 
Uma chave estrangeira é uma coluna ou uma combinação de colunas, cujos valores aparecem 
necessariamente na chave primária de uma tabela. 
(HEUSER, 2009). 
Atenção 
No exemplo, CODIGOFUNCIONARIO da tabela DEPENDENTE é chave estrangeira, pois todo valor dessa 
coluna necessariamente aparece como valor da coluna CODIGOFUNCIONARIO, chave primária de FUNCIONARIO. 
Como consequência, podemos concluir que todo dependente está vinculado a um funcionário. 
Deve-se notar que, mesmo que a coluna CODIGOFUNCIONARIO de DEPENDENTE tenha o mesmo 
nome da coluna que é chave primária em FUNCIONARIO, é possível nomeá-la de forma distinta. No entanto, 
usar o mesmo nome facilita na identificação das colunas relacionadas. 
Restrições impostas pela chave estrangeira 
Percebemos que a chave estrangeira serve para implementar relacionamentos entre tabelas. Para 
que o banco de dados permaneça íntegro, algumas restrições devem ser controladas e obedecidas pelo 
SGBD: 
1. Inclusão de linha na tabela que possui chave estrangeira: o sistema deve garantir que 
o valor da chave estrangeira exista como valor da coluna da chave primária referenciada. 
Em nosso exemplo, ao incluir um dependente, a coluna CODIGOFUNCIONARIO só pode 
assumir um dos valores (1,2,3,4). 
2. Alteração de valor da chave estrangeira: o sistema deve garantir que o novo valor da 
chave estrangeira exista como valor de coluna da chave primária referenciada. Em nosso 
exemplo, ao alterar um responsável de algum dependente, a coluna 
CODIGOFUNCIONARIO só pode assumir um dos valores (1,2,3,4). 
3. Exclusão de linha em tabela que contém chave primária referenciada pela chave 
estrangeira: o sistema deve garantir que todo valor de chave estrangeira sempre faça 
referência para o valor de alguma chave primária. Em nosso exemplo, os funcionários que 
têm código 1 ou 2 não devem ser excluídos, pois possuem vínculo com a tabela de 
dependentes. 
4. Alteração de valor da chave primária referenciada pela chave estrangeira: o sistema 
deve garantir que o novo valor da chave primária da tabela principal seja replicado nas 
respectivas dependências. Em nosso exemplo, se alterarmos o valor de 
CODIGOFUNCIONARIO (tabela FUNCIONARIO) de 2 para 5, o sistema deve garantir a 
propagação da atualização nas duas últimas linhas de DEPENDENTE. 
5. Os exemplos estudados representam o que conhecemos por integridade referencial, ou 
seja, os valores de chave estrangeira devem aparecer na chave primária da tabela 
referenciada. 
Esquema diagramático de banco de dados relacional 
Diversas ferramentas de modelagem permitem o uso de alguma notação gráfica para representar 
um banco de dados relacional. Na figura a seguir, temos um diagrama que foi construído a partir de uma 
ferramenta comercial. 
Sistema de Banco de Dados 
Marcio Quirino - 62 
 
 
Figura: Esquema diagramático “pé de galinha” envolvendo as tabelas FUNCIONARIO e DEPENDENTE. 
A notação utilizada é conhecida por pé de galinha. Nesse esquema diagramático: 
1. Cada tabela é representada por um retângulo com duas divisões; 
2. Na primeira subdivisão, adicionamos o nome da tabela; 
3. Na segunda subdivisão, aparecem as colunas da tabela, com as informações sobre o nome, 
o tipo de dados, além de símbolos representativos de chave primária PK (do Inglês, Primary 
Key) e chave estrangeira FK (do Inglês, Foreign Key); 
4. O símbolo “colado” na tabela DEPENDENTE, semelhante a um pé de galinha, representa o 
lado N do relacionamento entre as tabelas. 
Esquema textual de banco de dados relacional 
O banco de dados mostrado no diagrama anterior, pode ser declarado sob o formato textual, 
conforme exemplo a seguir: 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME, CPF, SEXO, DTNASCIMENTO) 
DEPENDENTE (CODIGOFUNCIONARIO, NRDEPENDENTE, NOME, DTNASCIMENTO) 
CODIGOFUNCIONARIO REFERENCIA FUNCIONARIO 
Observe que, no esquema textual, as tabelas são declaradas com informações sobre o nome, além 
de uma lista contendo as suas respectivas colunas. As chaves primárias são sublinhadas. Por fim, as chaves 
estrangeiras são declaradas usando o padrão nomecoluna(s) referencia nometabela(s). 
Neste módulo, estudamos os principais elementos do modelo relacional de banco de dados. 
Verificando o aprendizado 
1. A respeito dos tipos de chaves em projeto de banco de dados relacional, analise as 
proposições a seguir: 
I. Quando mais de uma coluna servir para diferenciar uma linha das demais em uma tabela 
relacional e uma delas é escolhida como chave primária, as restantes são denominadas 
chaves alternativas. 
II. Uma chave primária corresponde a uma coluna ou uma combinação de colunas cujos 
valores servem para diferenciar uma linha das demais de uma tabela. 
III. A chave estrangeira permite a implementação de relacionamentos em um banco de 
dados relacional. 
 
Assinale a alternativa verdadeira: 
Todas as proposições são corretas. 
2. Considere que em uma instituição de ensino superior (IES) exista um banco de dados 
relacional denominado BDIES que possui a tabela ALUNO cujos campos estão assim 
descritos: 
Sistema de Banco de Dados 
Marcio Quirino - 63 
 
 
De acordo com os fundamentos do modelo relacional, é correto afirmar que: 
O banco de dados BDIES pode possuir uma coleção de tabelas, todas com nome 
exclusivo, com colunas que podem conter valores dentro de um domínio. 
2. Formas Normais 
Normalização 
Ao longo da nossa jornada, conhecemos os principais elementos do modelo relacional. Quando 
trabalhamos com modelagem das tabelas de um banco de dados, ao criarmos as tabelas, é natural 
definirmos colunas que têm relação com as características do objeto sendo modelado. 
No entanto, modelar um banco de dados relacional não se resume simplesmente a usar uma 
ferramenta CASE e adicionar tabelas e relacionamentos sem que haja algum critério para essa construção. 
Ao longo deste módulo, estudaremos o assunto normalização, que ajudará a responder se um banco 
de dados foi bem projetado. Além disso, é possível executar o processo de normalização a partir de qualquer 
representação de dados. Isso significa que podemos iniciar o processo a partir de uma tela de sistema, ou 
mesmo um relatório. 
A normalização é um processo baseado no conceito de forma normal (FN), que pode ser vista como 
uma regra, a qual deve ser observada na semântica de uma tabela, para que a considerem bem projetada. 
Atenção 
Na literatura de banco de dados, há diversas formas normais: 1FN, 2FN, 3FN, FNBC, 4FN e 5FN. No entanto, 
para fins práticos, no contexto da maior parte dos projetos de banco de dados relacionais, costumamos executar o 
processo de normalização até a 3FN. 
Dividiremos o processo de normalização até a 3FN de acordo com o seguinte roteiro: 
1. Identificar a origem dos dados; 
2. Construir tabela não normalizada a partir dos dados; 
3. Aplicar as regras da primeira forma normal (1FN); 
4. Aplicar as regras da segunda forma normal (2FN); 
5. Aplicar as regras da terceira forma normal (3FN). 
Vamos estudar um exemplo? 
Considere o relatório expresso na figura, que informa os docentes participantes em projetos de 
pesquisa de uma instituição de ensino superior (IES): 
Sistema de Banco de Dados 
Marcio Quirino - 64 
 
 
Figura: Alocação de docentes a projetos de pesquisa em uma IES. 
De acordo com o relatório, nós podemos perceber que: 
• Os projetos sãocaracterizados por código, descrição e categoria (tipo). 
• Para cada docente alocado em projeto, aparecem os seguintes campos: código e nome do 
docente, sua categoria e salário, além da data de início de atuação no projeto, bem como o 
tempo alocado. 
Agora nós executaremos o segundo passo do roteiro, que corresponde a criar tabela não normalizada 
a partir do relatório. 
Tabela não normalizada 
A figura a seguir representa uma tabela não normalizada, denominada PROJETO, criada a partir do 
relatório: 
Sistema de Banco de Dados 
Marcio Quirino - 65 
 
 
Figura: Representação dos dados do relatório em tabela não normalizada. 
A representação textual da tabela está expressa a seguir: 
PROJETO (CODIGOPROJETO, TIPO, DESCRICAO, (CODIGODOCENTE, NOME, CATEGORIA, SALARIO, 
DATAINICIO, TEMPOMESES)) 
Nessa representação, a coluna CODIGOPROJETO diferencia cada projeto dos demais. A coluna 
CODIGODOCENTE diferencia os docentes alocados no contexto de um projeto. 
Agora, observe com atenção a figura representativa da tabela não normalizada: 
• Cada linha da tabela não normalizada representa a informação de alocação de um docente a 
um projeto de pesquisa; 
• Note que a coluna DOCENTE é composta por um conjunto de colunas: 
o CODIGODOCENTE, NOME, CATEGORIA, SALARIO, DATAINICIO e 
TEMPOMESES. Estamos diante de uma coluna composta; 
• Perceba, também, que se olharmos isoladamente para os valores das colunas que compõem 
a coluna DOCENTE, vamos perceber repetição. Isso acontece no caso dos funcionários José 
e Marta. A mesma informação está representada mais de uma vez, o que representa 
redundância. 
Agora que construímos a tabela não normalizada, vamos à próxima etapa, que terá como saída um 
conjunto de tabelas na 1FN. 
Sistema de Banco de Dados 
Marcio Quirino - 66 
 
Primeira Forma Normal (1FN) 
Uma tabela está de acordo com a 1FN quando não possui atributo(s) multivalorado(s) nem atributo(s) 
composto(s). 
Devemos recordar que, como resultado da etapa anterior, foi criada tabela não normalizada. Para 
ficar de acordo com a 1FN, nós executaremos os passos a seguir: 
1. Criar tabela na 1FN com a mesma chave primária da tabela não normalizada, além das 
colunas atômicas da própria tabela não normalizada. 
2. Criar uma tabela na 1FN para cada coluna composta, identificada na tabela não 
normalizada. Cada tabela terá uma chave primária composta pela chave primária da tabela 
criada no passo anterior e pela coluna identificada como composta. Além disso, terá as 
colunas membro da coluna em questão. 
3. Criar uma tabela na 1FN para cada coluna multivalorada. Cada tabela terá uma chave 
primária composta pela chave primária da tabela não normalizada e pela coluna identificada 
como multivalorada. 
Ao aplicarmos os passos à tabela PROJETO, teremos como resultado as seguintes tabelas em 1FN: 
PROJETO (CODIGOPROJETO, TIPO, DESCRICAO) 
PROJETODOCENTE (CODIGOPROJETO, CODIGODOCENTE, NOME, CATEGORIA, SALARIO, DATAINICIO, 
TEMPOMESES) 
Ainda, de acordo com a representação textual, devemos perceber que: 
• A coluna CODIGOPROJETO da tabela PROJETO diferencia um projeto dos demais. 
• As colunas CODIGOPROJETO, CODIGODOCENTE compõem a chave primária da 
tabela PROJETODOCENTE, visto que um mesmo docente pode atuar em diversos 
projetos. 
A figura a seguir representa o conteúdo das tabelas, com base nos dados originalmente expressos 
no relatório de alocação docente a projetos: 
Projeto 
 
ProjetoDocente 
Sistema de Banco de Dados 
Marcio Quirino - 67 
 
 
Figura: Representação dos dados do relatório em tabelas na 1FN. 
Dependência funcional 
Se observarmos os dados da tabela PROJETODOCENTE, vamos concluir que o nome do docente 
é o mesmo para cada código de docente. Parece então existir uma relação de dependência entre as colunas 
NOME e CODIGODOCENTE. 
Assim, podemos expressar essa relação da seguinte maneira: 
CODIGODOCENTE → NOME. 
Com isso, dizemos que a coluna CODIGODOCENTE é determinante da coluna NOME. 
Podemos dizer também que NOME é dependente de CODIGODOCENTE, isto é, determinado por 
CODIGODOCENTE. 
Atenção 
A generalização dessa informação representa o conceito de dependência funcional. 
Dessa forma, seja X um conjunto de atributos e Y um atributo; X → Y significa que o conjunto de atributos X 
determina o atributo Y. 
Dependência funcional parcial 
Observe novamente a tabela PROJETODOCENTE expressa na figura: 
ProjetoDocente 
Sistema de Banco de Dados 
Marcio Quirino - 68 
 
 
Figura: Representação dos dados da tabela PROJETODOCENTE. 
Se analisarmos a relação CODIGOPROJETO, CODIGODOCENTE → NOME, iremos perceber que 
NOME é dependente somente de CODIGODOCENTE, ou seja, não é necessária a existência do par 
CODIGOPROJETO, CODIGODOCENTE para determinar o nome do docente. Estamos diante de uma 
dependência funcional parcial, visto que identificamos uma coluna dependente somente de parte da chave 
primária composta. 
Segunda Forma Normal (2FN) 
Uma tabela está na 2FN, caso esteja na 1FN e não haja dependências funcionais parciais. 
Se analisarmos com um pouco mais de atenção cada coluna não chave da tabela 
PROJETODOCENTE, iremos perceber que, além da coluna NOME, as colunas CATEGORIA e SALARIO 
também só dependem da coluna CODIGODOCENTE. 
Para ficar de acordo com a 2FN, será necessário eliminarmos as dependências parciais, conforme 
os passos a seguir: 
1. Manter no modelo cada tabela que possua chave primária simples; 
2. Identificar cada dependência parcial; 
3. Criar uma tabela para cada dependência parcial identificada. 
A figura a seguir identifica as colunas dependentes de parte da chave primária na tabela 
PROJETODOCENTE: 
 
Figura: Representação das dependências parciais na tabela PROJETODOCENTE. 
Sistema de Banco de Dados 
Marcio Quirino - 69 
 
Ao aplicarmos os passos ao modelo, teremos como resultado as seguintes tabelas na 2FN: 
PROJETO (CODIGOPROJETO, TIPO, DESCRICAO) 
PROJETODOCENTE (CODIGOPROJETO, CODIGODOCENTE, DATAINICIO, TEMPOMESES) 
DOCENTE (CODIGODOCENTE, NOME, CATEGORIA, SALARIO) 
A figura a seguir representa o conteúdo das tabelas na 2FN, com base nos dados, originalmente, 
expressos no relatório de alocação docente a projetos: 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 70 
 
 
Figura: Representação dos dados do relatório em tabelas em 2FN. 
O modelo está na 2FN, pois, além de estar na 1FN, não existem dependências parciais. 
Dependência funcional transitiva 
Se observarmos os dados da tabela DOCENTE gerada na etapa anterior, podemos concluir que o 
valor do salário é o mesmo em cada categoria. Perceba que parece então existir uma relação de 
dependência entre as colunas CATEGORIA e SALARIO. Assim, podemos expressar essa relação da 
seguinte maneira: 
CATEGORIA → SALARIO. 
Com isso, dizemos que a coluna CATEGORIA é determinante da coluna SALARIO. Podemos dizer 
também que SALARIO é dependente de CATEGORIA. 
Atenção 
Estamos diante de um exemplo de dependência funcional, em que o determinante é uma coluna que não 
pertence à chave primária da tabela. 
Uma dependência funcional transitiva ocorre quando uma coluna é dependente de alguma coluna não-chave 
da tabela. 
Terceira Forma Normal (3FN) 
Uma tabela está em 3FN caso esteja na 2FN e não possua dependências transitivas. 
A figura a seguir identifica a dependência transitiva na tabela PROJETODOCENTE: 
 
Figura: Representação da dependência transitiva na tabela PROJETODOCENTE. 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 71 
 
Para ficar de acordo com a 3FN, será necessário eliminarmos as dependências transitivas, conforme 
os passos a seguir: 
1. Manter no modelo cada tabela que tenha menos de duas colunas não chave; 
2. Identificar cada dependência transitiva; 
3. Criar uma tabela para cada dependência transitiva identificada. 
Ao aplicarmos os passos ao modelo, teremos como resultado as seguintes tabelas na 3FN: 
PROJETO (CODIGOPROJETO, TIPO, DESCRICAO) 
PROJETODOCENTE (CODIGOPROJETO,CODIGODOCENTE, DATAINICIO, TEMPOMESES) 
DOCENTE (CODIGODOCENTE, NOME, CATEGORIA) 
CATEGORIA (CATEGORIA, SALARIO) 
A figura a seguir representa o conteúdo das tabelas na 3FN, com base nos dados originalmente 
expressos no relatório de alocação de docentes a projetos: 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 72 
 
 
 
Figura: Representação dos dados do relatório em tabelas na 3FN. 
O modelo está na 3FN, pois, além de estar na 2FN, não existem dependências transitivas. 
Neste módulo, nós aprendemos que o processo de normalização é útil para refinarmos a construção 
de um banco de dados relacional. Estudamos três formas normais e percebemos que, ao normalizarmos o 
nosso modelo, o número de tabelas tende a aumentar, minimizando assim redundância nos dados. 
Verificando o aprendizado 
1. O processo de Normalização objetiva eliminar dados redundantes, além de garantir que a 
dependência de dados faça sentido. A respeito da terceira forma normal em uma tabela 
relacional, assinale a alternativa verdadeira: 
A tabela precisa estar na 2FN e não deve possuir coluna(s) com dependência(s) 
transitiva(s). 
De fato, para estar na 3FN a tabela tem que respeitar as regras da 2FN, pois uma forma engloba 
as restrições da forma anterior. Além disso, não pode haver dependências entre colunas não-
chave. 
2. Seja uma relação R (C1, C2, C3, C4, C5) com chave primária composta pelas colunas C1 e 
C2 e as seguintes dependências funcionais: 
 
C1 → C3 
C3 → C4 
C2 → C5 
 
Podemos afirmar que o esquema R atende à: 
Sistema de Banco de Dados 
Marcio Quirino - 73 
 
1 FN 
De fato, se C1 determina C3, temos então uma dependência parcial da chave primária, o que é 
proibido na 2FN. Como cada FN, a partir da segunda, depende da anterior, a relação R atende 
à 1FN. 
3. Mapeamento conceitual-lógico 
Mapeamento conceitual-lógico 
No projeto de banco de dados, há etapas que devem ser seguidas para a construção de um modelo 
conceitual. Para tanto, é usual a adoção do diagrama de entidade e relacionamento (DER) - tipo de modelo 
conceitual em que os principais objetos do negócio modelado se tornam entidades caracterizadas por 
atributos e relacionamentos. 
Estudamos os principais componentes do modelo relacional, um modelo lógico que é base para a 
implementação de bancos de dados relacionais. 
Neste módulo, construiremos a ponte entre os modelos conceitual e lógico. 
Passaremos, então, a aplicar regras formais de mapeamento do modelo conceitual, visando a construção do 
modelo lógico. Na prática, projetaremos um banco de dados relacional a partir de um DER. 
Regras de mapeamento 
Podemos dividir o mapeamento conceitual-lógico em quatro etapas: 
1. Entidades 
2. Relacionamentos 
3. Atributos multivalorados 
4. Especialização/generalização 
A seguir, conheceremos as regras de cada etapa do mapeamento e a sua respectiva aplicação por 
meio de exemplos. 
Mapeamento de entidades 
O mapeamento de entidades envolve: 
A. Entidade forte ou independente 
✓ Cada entidade E vira uma tabela T; 
✓ Cada atributo simples da entidade E vira uma coluna na tabela T; 
✓ O atributo identificador da entidade E vira chave primária na tabela T. 
B. Entidade fraca ou dependente: 
✓ Cada entidade fraca F vira uma tabela T; 
✓ Cada atributo simples da entidade F vira uma coluna na tabela T; 
✓ A tabela T possuirá chave estrangeira originada a partir da chave primária da tabela 
proprietária; 
✓ A tabela T possuirá chave primária composta pela coluna chave estrangeira criada no passo 
anterior e pela coluna mapeada do atributo identificador da entidade F na tabela T. 
Exemplo de mapeamento de entidades: 
Conhecidas as regras para o mapeamento de entidades, observe no exemplo a seguir um diagrama 
de entidade e relacionamento (DER) contendo duas entidades: 
Sistema de Banco de Dados 
Marcio Quirino - 74 
 
FUNCIONARIO (entidade forte) e FONEFUNC (entidade fraca). 
 
Figura: Diagrama de Entidade e Relacionamento (DER) contendo duas entidades. 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo entidade. 
Note que a tabela FUNCIONARIO corresponde à aplicação da regra para entidade forte. De modo 
semelhante, a tabela FONEFUNC corresponde à aplicação da regra para entidade fraca. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
FUNCIONARIO (CODGOFUNCIONARIO, NOME) 
FONEFUNC (CODIGOFUNCIONARIO, NUMERO, TIPO) 
CODIGOFUNCIONARIO REFERENCIA FUNCIONARIO 
Mapeamento de relacionamentos 
O mapeamento de relacionamentos dependerá da cardinalidade máxima: 
A. Relacionamentos 1:1: 
✓ Cardinalidade (0,1):(0,1): priorizar adição de coluna(s). Alternativa: tabela própria. 
✓ Cardinalidade (0,1):( 1,1): priorizar fusão de tabelas. Alternativa: adição de colunas. 
✓ Cardinalidade (1,1):( 1,1): fusão de tabelas. 
B. Relacionamentos 1:N: 
✓ Identificar a tabela T do lado N. 
✓ Adicionar chave estrangeira na tabela T do lado N referente à chave primária da tabela do 
lado 1. 
✓ Cada atributo simples do relacionamento vira uma coluna na tabela T. 
C. Relacionamentos N:N: 
✓ Cada relacionamento vira uma tabela T. 
✓ A tabela T possuirá chaves estrangeiras originadas das chaves primárias das tabelas 
participantes do relacionamento. 
✓ A tabela T possuirá chave primária composta pelas chaves estrangeiras criadas no passo 
anterior. 
✓ Cada atributo simples do relacionamento vira uma coluna na tabela T. 
D. Relacionamentos N-ários (análogo a relacionamentos N:N): 
✓ Cada relacionamento vira uma tabela T. 
✓ A tabela T possuirá chaves estrangeiras originadas das chaves primárias das tabelas 
participantes do relacionamento. 
✓ A tabela T possuirá chave primária composta pelas chaves estrangeiras criadas no passo 
anterior. 
Sistema de Banco de Dados 
Marcio Quirino - 75 
 
✓ Cada atributo simples do relacionamento vira uma coluna na tabela T. 
Exemplos de mapeamento de relacionamento 1:1: 
Conhecidas as regras para o mapeamento de relacionamentos 1:1, observe no exemplo a seguir um 
diagrama de entidade e relacionamento (DER) contendo duas entidades: FUNCIONARIO e NOTEBOOK. 
Há um relacionamento 1:1 no qual ambas as entidades possuem participação opcional (cardinalidades (0,1): 
(0,1)): 
 
Figura: DER contendo relacionamento 1:1 – ambas as entidades com participação opcional. 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento 1:1 - ambas as entidades com 
participação opcional. 
Para esse tipo de relacionamento, o mais adequado é priorizar adição de coluna(s), o que ocorreu 
ao criarmos a coluna CODIGONOTEBOOK como chave estrangeira na tabela FUNCIONARIO. Vale lembrar 
que estamos diante de uma coluna opcional. 
A seguir, a representação textual do modelo: 
NOTEBOOK (CODIGONOTEBOOK, DESCRICAO) 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME, CODIGONOTEBOOK) 
CODIGONOTEBOOK REFERENCIA NOTEBOOK 
A figura a seguir apresenta um DER contendo um relacionamento 1:1 no qual há uma entidade com 
participação obrigatória e a outra opcional (cardinalidades (0,1): (1,1)): 
 
Figura DER contendo relacionamento 1:1 – uma entidade com participação obrigatória e a outra opcional. 
A figura a seguir exibe o modelo lógico gerado: 
Sistema de Banco de Dados 
Marcio Quirino - 76 
 
 
Figura: Tabela criada com base no mapeamento conceitual-lógico envolvendo relacionamento 1:1 - uma entidade com 
participação obrigatória e a outra opcional. 
Para esse tipo de relacionamento, o mais adequado é priorizar fusão de tabelas, o que ocorreu ao 
criarmos as colunas CODIGONOTEBOOK e DESCRICAO na tabela FUNCIONARIO, ambas opcionais. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME, CODIGONOTEBOOK, DESCRICAO) 
A figura a seguir apresenta um DER parcial contendo um relacionamento1:1 e ambas as entidades 
com participação obrigatória (cardinalidades (1,1): (1,1)): 
 
Figura: DER parcial contendo relacionamento 1:1 – ambas as entidades com participação obrigatória. 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento 1:1 – ambas as entidades com 
participação obrigatória. 
Para esse tipo de relacionamento, o mais adequado é priorizar fusão de tabelas, o que ocorreu ao 
criarmos as colunas CODIGONOTEBOOK e DESCRICAO na tabela FUNCIONARIO, ambas obrigatórias. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME, CODIGONOTEBOOK, DESCRICAO) 
Exemplo de mapeamento de relacionamento 1:N: 
Conhecidas as regras para o mapeamento de relacionamentos 1:N, observe no exemplo a seguir um 
diagrama de entidade e relacionamento (DER) contendo duas entidades: NIVEL e CURSO. 
A figura a seguir mostra um DER parcial contendo um relacionamento 1:N: 
Sistema de Banco de Dados 
Marcio Quirino - 77 
 
 
Figura: DER contendo relacionamento 1:N. 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento 1:N. 
Para esse tipo de relacionamento, foi utilizada adição de coluna(s) na tabela do lado N, o que ocorreu 
ao criarmos a chave estrangeira CODIGONIVEL na tabela CURSO. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
NIVEL (CODGONIVEL, DESCRICAO) 
CURSO (CODIGOCURSO, NOME, DATACRIACAO, CODIGONIVEL) 
CODIGONIVEL REFERENCIA NIVEL 
Exemplo de mapeamento de relacionamento N:N: 
Conhecidas as regras para o mapeamento de relacionamentos N:N, observe no exemplo a seguir 
um diagrama de entidade e relacionamento (DER) contendo duas entidades: CURSO e DISCIPLINA. 
A figura a seguir mostra um DER parcial contendo um relacionamento N:N: 
 
Figura: DER parcial contendo relacionamento N:N. 
A figura a seguir exibe o modelo lógico gerado: 
Sistema de Banco de Dados 
Marcio Quirino - 78 
 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento N:N 
Para esse tipo de relacionamento, foi utilizada tabela própria, o que ocorreu ao criarmos 
CURSODISCIPLINA, contendo duas chaves estrangeiras: CODIGOCURSO e CODIGODISCIPLINA. Ao 
mesmo tempo, a combinação das duas colunas forma a chave primária composta da tabela. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
CURSO (CODIGOCURSO, NOME, DATACRIACAO, CODIGONIVEL) 
CODIGONIVEL REFERENCIA NIVEL 
DISCIPLINA (CODIGODISCIPLINA, NOME, CARGAGORARIA) 
CURSODISCIPLINA (CODIGOCURSO, CODIGODISCIPLINA) 
CODIGOCURSO REFERENCIA CURSO 
CODIGODISCIPLINA REFERENCIA DISCIPLINA 
Observação sobre entidade associativa 
O mapeamento de entidade associativa, isto é, relacionamento com atributos, segue as regras 
utilizadas no mapeamento de relacionamentos N:N. 
Observação sobre autorrelacionamento 
O mapeamento de autorrelacionamento segue as regras utilizadas no mapeamento de 
relacionamentos. Basta, então, você ficar atento ao tipo de cardinalidade máxima em questão. 
Exemplo de mapeamento de relacionamento ternário: 
Conhecidas as regras para o mapeamento de relacionamentos, ao nos depararmos com 
relacionamentos ternários, precisaremos avaliar as cardinalidades máximas em questão. Observe no 
exemplo a seguir um diagrama de entidade e relacionamento (DER) contendo um relacionamento ternário 
entre as entidades PROJETO, DOCENTE e ALUNO. 
A figura a seguir mostra um DER parcial contendo um relacionamento ternário. 
 
Figura DER parcial contendo relacionamento ternário. 
Sistema de Banco de Dados 
Marcio Quirino - 79 
 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo relacionamento ternário. 
Para esse tipo de relacionamento, foi utilizada tabela própria, o que ocorreu ao criarmos 
ORIENTACAO, contendo três chaves estrangeiras: CODIGOFUNCIONARIO, CODIGOALUNO e 
CODIGOPROJETO. Além disso, foram criadas as colunas DATAINICIO e DATAFIM, as quais representam 
informações importantes sob o contexto de um registro de orientação. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
PROJETO (CODIGOPROJETO, DESCRICAO) 
DOCENTE (CODIGOFUNCIONARIO, NOME) 
ALUNO (CODIGOALUNO, NOME, CPF) 
ORIENTACAO (CODIGOPROJETO, CODIGOALUNO, CODIGOFUNCIONARIO, DATAINICIO, DATAFIM) 
CODIGOPROJETO REFERENCIA PROJETO 
CODIGOALUNO REFERENCIA ALUNO 
CODIGOFUNCIONARIO REFERENCIA DOCENTE 
Mapeamento de atributos multivalorados 
O mapeamento de atributos multivalorados envolve: 
1. Criar uma tabela T para cada atributo multivalorado. 
2. Criar coluna(s) para o(s) atributo(s) multivalorado(s). 
3. A tabela T possuirá chave estrangeira originada da chave primária da tabela original. 
4. A tabela T possuirá chave primária composta pela chave estrangeira criada no passo 
anterior e pela(s) coluna(s) referente(s) ao(s) atributo multivalorado(s). 
A figura a seguir mostra um DER parcial contendo atributo multivalorado. 
Sistema de Banco de Dados 
Marcio Quirino - 80 
 
 
Figura DER parcial contendo atributo multivalorado. 
A figura a seguir exibe o modelo lógico gerado: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo atributo multivalorado. 
Note que para mapear o atributo multivalorado TELEFONE, foi criada tabela própria denominada 
FONEALUNO. A coluna CODIGOALUNO de FONEALUNO é chave estrangeira. Além disso, as colunas 
CODIGOALUNO, NUMERO, TIPO representam uma chave primária composta. A coluna TIPO, criada na 
tabela FONEALUNO, representa a categoria do telefone, por exemplo, residencial, comercial ou móvel. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
ALUNO (CODIGOALUNO, NOME, CPF) 
FONEALUNO (CODIGOALUNO, NUMETO, TIPO) 
CODIGOALUNO REFERENCIA ALUNO 
Mapeamento de especialização/generalização 
O mapeamento de especialização/generalização envolve: 
A. Solução I 
Tabela única. 
✓ Criar uma tabela única que contenha todos os atributos das entidades genérica e 
especializadas. 
✓ Criar uma coluna TIPO, caso não exista, para identificar a entidade especializada. 
B. Solução II 
Uma tabela para cada entidade (genérica ou especializada) que compõe a hierarquia. 
✓ Criar uma tabela para a entidade genérica, com coluna(s) referente(s) ao(s) atributo(s) da 
entidade genérica. 
✓ Criar uma tabela para cada entidade especializada, com coluna(s) referentes ao(s) atributo(s) 
da entidade especializada. 
✓ Cada tabela de entidade especializada possuirá chave estrangeira originada da chave 
primária da tabela da entidade genérica. Esta também será a sua chave primária. 
C. Solução III 
Subdivisão da entidade genérica. 
Sistema de Banco de Dados 
Marcio Quirino - 81 
 
✓ Nesta implementação, não será criada tabela para a entidade genérica. 
✓ Criar uma tabela para cada entidade especializada, com coluna(s) referentes ao(s) atributo(s) 
da entidade especializada. 
✓ Em cada tabela, criar colunas referentes aos atributos da entidade genérica, sendo sua chave 
primária originada do atributo identificador da entidade genérica. 
✓ Caso a hierarquia seja parcial, será necessário criar uma tabela adicional para abarcar as 
entidades genéricas que não estão nas entidades especializadas. Essa tabela conterá 
somente os atributos da entidade genérica. 
✓ Importante notar que esta solução pode gerar redundância de dados, no caso de hierarquia 
sobreposta, requerendo um tratamento adicional para controle de redundância. 
Exemplos de mapeamento de especialização/generalização: 
Conhecidas as regras para o mapeamento de especialização/generalização, observe no exemplo a 
seguir um diagrama de entidade e relacionamento (DER) com esse mecanismo: 
 
Figura: DERcontendo especialização/generalização. 
A figura a seguir exibe o modelo lógico gerado após a aplicação da solução I expressa nas regras de 
mapeamento: 
 
Figura: Tabela criada com base no mapeamento conceitual-lógico envolvendo especialização/generalização – solução I. 
No exemplo, foi criada tabela única (FUNCIONARIO) contendo colunas referentes à entidade 
genérica, além da coluna TIPO, para identificar a categoria de cada colaborador. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME, TIPO) 
A figura a seguir exibe o modelo lógico gerado após a aplicação da solução II das regras de 
mapeamento: 
Sistema de Banco de Dados 
Marcio Quirino - 82 
 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo especialização/generalização – solução II. 
No exemplo, foram criadas três tabelas: uma (FUNCIONARIO) referente à entidade genérica. As 
restantes, DOCENTE e ANALISTA, referentes às entidades especializadas em questão. Cada 
CODIGOFUNCIONARIO presente nas tabelas DOCENTE e ANALISTA exerce o papel de chave 
estrangeira. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
FUNCIONARIO (CODIGOFUNCIONARIO, NOME) 
DOCENTE (CODIGOFUNCIONARIO ) 
CODIGOFUNCIONARIO REFERENCIA FUNCIONARIO 
ANALISTA (CODIGOFUNCIONARIO) 
CODIGOFUNCIONARIO REFERENCIA FUNCIONARIO 
A figura a seguir exibe o modelo lógico gerado após a aplicação da solução III das regras de 
mapeamento: 
 
Figura: Tabelas criadas com base no mapeamento conceitual-lógico envolvendo especialização/generalização – solução III. 
No exemplo, foram criadas três tabelas, sendo OUTROSFUNCIONARIOS onde devem ser mantidos 
funcionários que não sejam docentes nem analistas. As restantes, DOCENTE e ANALISTA, são referentes 
às entidades especializadas em questão. 
Após a aplicação das regras de mapeamento, foi gerada a representação textual a seguir: 
DOCENTE (CODIGOFUNCIONARIO, NOME) 
ANALISTA (CODIGOFUNCIONARIO, NOME) 
OUTROSFUNCIONARIOS (CODIGOFUNCIONARIO, NOME) 
Convém ressaltar que a tabela OUTROSFUNCIONARIOS seria necessária somente se o mecanismo 
de generalização/especialização fosse parcial, ou seja, se houvesse algum colaborador não enquadrado 
nas categorias docente ou analista. 
Atenção 
Como dica prática, devemos ter cuidado especial caso seja escolhida a solução III. Ao incluir um novo 
funcionário, será necessário verificar todas as tabelas criadas para as especializações para garantir a unicidade da 
chave primária. No exemplo, é preciso verificar os valores de chave primária nas tabelas DOCENTE, ANALISTA e 
OUTROSFUNCIONARIOS. 
Por fim, convém ressaltar que a solução II é a mais usual, por ser mais flexível, dada a facilidade 
existente em contemplar novas especializações. Além disso, a solução I tende a gerar diversas ocorrências 
de valores nulos em colunas. Ao mesmo tempo, a solução III apresenta maior possibilidade de gerar 
redundância de dados. 
Estudo de caso 
Sistema de Banco de Dados 
Marcio Quirino - 83 
 
Para praticar as principais regras de mapeamento estudadas, vamos realizar um estudo de caso. Tendo como 
base os requisitos a seguir, foi construído o diagrama de entidade e relacionamento (DER) da figura abaixo. A partir 
desse DER, realize o mapeamento conceitual-lógico, sob a forma de descrição textual. 
Deseja-se informatizar os processos de empréstimo e devolução de livros de uma biblioteca da rede pública 
municipal: 
1. Cada pessoa habilitada a emprestar livros é identificada por um código. Além disso, são armazenados 
o RG, o CPF e o nome. Uma pessoa pode ter diversos endereços cadastrados, inclusive, nenhum. 
Cada endereço possui complemento, logradouro, UF, cidade e um tipo que o identifica. 
2. Cada livro possui um código, ano, título e edição. Além disso, um livro pode ter vários autores. Cada 
autor é identificado por um código e possui um nome. Um livro pode ser inicialmente cadastrado sem 
a informação do autor. Um livro pode possuir vários exemplares, inclusive nenhum. Os exemplares 
serão emprestados. 
3. Todo livro está associado a no máximo uma editora. Cada editora é identificada por um código e possui 
um nome. 
4. Uma pessoa pode realizar diversos empréstimos, inclusive nenhum. Todo empréstimo possui um 
código que o identifica, além da data de empréstimo e data de previsão de devolução. Em um 
empréstimo a pessoa pode levar diversos exemplares. É necessário registrar a devolução de cada 
exemplar emprestado. 
Modelo de entidade e relacionamento resultante do projeto conceitual: 
 
Figura: Modelo de entidade e relacionamento referente ao estudo de caso. 
Verificando o aprendizado 
1. Considere um relacionamento entre TURMA e DISCIPLINA (N:N) denominado OFERTA. 
Para cada disciplina ofertada por uma turma é necessário saber o número de vagas. Qual 
Sistema de Banco de Dados 
Marcio Quirino - 84 
 
alternativa a seguir representa corretamente o modelo lógico derivado do modelo 
conceitual? 
Três tabelas: uma para TURMA, uma para DISCIPLINA e uma para OFERTA. Além disso, 
o atributo que representa o número de vagas deve estar modelado na tabela OFERTA. 
Diante da cardinalidade máxima N:N, a solução é criar três tabelas: duas para as entidades 
participantes e uma para o relacionamento. O atributo que representa o número de vagas, pelo 
fato de fazer parte do relacionamento, deve ser modelado na tabela OFERTA. 
2. Considere o projeto conceitual parcial a seguir: 
 
Para construir o projeto lógico a partir do DER, é correto afirmar que serão criadas: 
Quatro tabelas. 
No mapeamento lógico-conceitual, cada entidade vira tabela. O mesmo ocorrerá no LA, por ter 
cardinalidade máxima N:N. O relacionamento EL, por ter cardinalidade máxima 1:N será 
implementado na tabela LIVRO. 
4. Aspectos físicos para implementação do modelo no SGBD 
Consultas 
A partir de agora, conheceremos diretrizes que devem ser consideradas quando formos implementar 
um banco de dados relacional. As diretrizes abrangem aspectos que influenciam no desempenho do banco 
de dados. Assim, o projeto lógico pode sofrer ajustes para adaptar-se ao sistema gerenciador de banco de 
dados (SGBD) escolhido para a implementação. 
Planejar um banco de dados que tenha um bom desempenho pressupõe adquirir conhecimento sobre 
as consultas e transações que serão realizadas pela aplicação. 
Um SGBD tipicamente processa e devolve dados requisitados em consultas para diversas 
finalidades, tais como recuperação, inclusão, exclusão ou mesmo atualização de dados. As consultas são 
implementadas com o auxílio da linguagem SQL (do Inglês, Structured Query Language – linguagem de 
consulta estruturada). 
Dica 
Um código típico de consulta para recuperar dados em SQL envolve o comando SELECT com as cláusulas 
FROM e WHERE. 
Por exemplo, dada a tabela DOCENTE (CODIGODOCENTE, NOME, SEXO), o código a seguir 
recupera os registros de todas as professoras: 
SELECT CODIGODOCENTE, NOME 
FROM DOCENTE 
WHERE SEXO='F' 
Sistema de Banco de Dados 
Marcio Quirino - 85 
 
A primeira linha do comando informa ao SGBD as colunas que devem ser exibidas após o 
processamento da consulta. Na segunda, especificamos o nome da tabela que contém os dados. 
Finalmente, na terceira linha, adicionamos uma condição de filtro que será processada pelo SGBD para 
recuperar as linhas de interesse. 
Transações 
Diversos SGBDs modernos permitem a especificação de operações de transação. 
Uma transação corresponde a uma série de operações que, quando submetidas ao SGBD, devem 
ser consideradas como uma unidade lógica de trabalho. Isso significa que todas as operações que compõem 
uma transação precisam ser executadas. Caso contrário, é necessário serem canceladas e nenhuma 
modificação ocorrerá no banco de dados. 
Por exemplo, em um processo de inscrição em disciplinas, em geral, o aluno tem a liberdade para 
compor seu quadro de horáriode disciplinas, para, em seguida, confirmar inscrição em diversas matérias. 
Assim, a inscrição em disciplinas deve ser considerada como um único processo ou transação. Trata-se de 
um procedimento atômico: ou todas as operações são confirmadas ou nenhuma delas é realizada. 
Indexação em banco de dados 
O desempenho de consultas é um assunto vasto que faz uso de diversas estratégias de acesso a 
dados, semelhantes às utilizadas em nosso dia a dia. 
Por exemplo, ao buscarmos por determinada informação em algum livro, para ganharmos tempo, é 
comum primeiro consultar o índice remissivo do livro, que indicará a página onde se localiza o termo 
buscado. 
Atenção 
Em banco de dados, índices funcionam como estruturas auxiliares utilizadas para tornar mais eficiente a 
recuperação de registros em resposta a determinadas condições de busca. 
Normalmente, ao projetamos uma tabela com chave primária, os registros de dados são gravados 
em disco sem nenhum critério de ordenação das linhas da tabela. Para facilitar a consulta pelo valor da 
chave primária, o SGBD cria uma estrutura de índice para a chave primária de cada tabela. 
A estrutura de índice poderá ser utilizada pelo SGBD caso seja necessário realizar consulta que 
envolva, por exemplo, uma condição de igualdade na coluna de chave primária da tabela. Quando isso 
ocorre, o desempenho da consulta em geral é melhor do que caso não existisse a estrutura de índice. 
Exemplo prático envolvendo indexação: 
Visando ressaltar a importância dos índices, realizamos um pequeno experimento, que consiste em 
submeter duas consultas ao SGBD, uma sem índice, e a segunda com uma coluna indexada. 
Vamos perceber que, quando o SGBD processa uma consulta com o auxílio de um índice, o tempo 
de resposta tende a ser mais otimizado se comparado à execução da mesma consulta sem esse recurso. 
Suponha então a existência de uma tabela DM_DOCENTE (CO_IES, NO_IES, CO_DOCENTE_IES, 
CO_MUNICIPIO_NASCIMENTO) - apresentada aqui com quatro colunas para fins de exemplo – 
originalmente, extraída do Censo da Educação Superior Brasileira de 2016. 
A tabela contém 367.980 registros. Cada registro corresponde a um docente vinculado a uma 
instituição de ensino superior (IES). Ainda, originalmente, os registros de DM_DOCENTE estão fisicamente 
ordenados pela coluna CO_IES e a tabela não possui chave primária definida. 
Sistema de Banco de Dados 
Marcio Quirino - 86 
 
Nosso objetivo é recuperar todas as colunas da tabela, referentes ao docente que possui o valor 
850516 para a coluna CO_DOCENTE_IES. 
O comando SQL executado na consulta I a seguir, serve para esse propósito: 
SELECT * 
FROM DM_DOCENTE 
WHERE CO_DOCENTE_IES=850516; 
Essa consulta demorou 2,5 segundos para ser executada. 
Agora, criaremos uma tabela chamada DM_DOCENTE_2, contendo os mesmos registros de 
DM_DOCENTE, no entanto com os registros ordenados pela coluna CO_DOCENTE_IES, conforme código 
SQL a seguir: 
/* 
Tabela DM_DOCENTE_2 com registros ordenados por 
CO_DOCENTE_IES; 
*/ 
CREATE TABLE DM_DOCENTE_2 AS 
SELECT * 
FROM DM_DOCENTE 
ORDER BY CO_DOCENTE_IES; 
Adicionaremos chave primária à tabela DM_DOCENTE_2, escolhendo a coluna 
CO_DOCENTE_IES, conforme código SQL a seguir: 
/* 
Ao adicionar chave primária na tabela DM_DOCENTE_2, o SGBD 
cria um índice para a coluna CO_DOCENTE_IES. 
*/ 
ALTER TABLE DM_DOCENTE_2 ADD PRIMARY KEY (CO_DOCENTE_IES); 
Finalmente, executaremos a consulta II: 
SELECT * 
FROM DM_DOCENTE_2 
WHERE CO_DOCENTE_IES=850516; 
Essa consulta demorou 0,06 segundos para ser executada. 
O resultado do processamento das consultas é igual, uma vez que temos os mesmos registros em 
ambas as tabelas. Contudo, a consulta 2 foi processada com mais eficiência. 
Após breve contextualização envolvendo consulta, transação e indexação, passaremos a estudar os 
fatores que influenciam no projeto de bancos de dados relacionais. 
Projeto físico em bancos de dados relacionais 
Projetar um banco de dados é um processo que envolve as seguintes etapas: 
1. Levantamento de requisitos 
2. Projeto conceitual 
3. Projeto lógico 
4. Projeto físico 
Projetar fisicamente um banco de dados é o mesmo que “colocar a mão na massa”, ou seja, acessar 
recursos do sistema gerenciador de banco de dados (SGBD) para atividades de criação da estrutura física 
do banco, que, na maioria das vezes, ocorre com o auxílio de alguma ferramenta CASE capaz de gerar 
códigos na linguagem SQL para criar as tabelas, relacionamentos e demais componentes do banco de 
dados. 
Sistema de Banco de Dados 
Marcio Quirino - 87 
 
É comum que haja mais de uma alternativa para implementar um banco de dados tomando como 
base o esquema conceitual. Ainda, o projeto físico de banco de dados é comumente influenciado pelos 
seguintes fatores: 
Consultas e transações de banco de dados 
É necessário planejar as consultas e transações que deverão ocorrer no banco de dados. De um 
modo geral, para cada consulta de recuperação de dados, é necessário conhecer: 
1. As tabelas acessadas pela consulta; 
2. As colunas que serão utilizadas em condições de seleção; 
3. A natureza da condição de seleção: intervalo, igualdade ou desigualdade; 
4. Colunas utilizadas na composição de operações de junção; 
5. Colunas cujos valores aparecerão nos resultados da consulta. 
Em se tratando de tabelas de um banco de dados, é comum criarmos índices para determinadas 
colunas. Em especial, colunas relacionadas aos itens 2 e 4 são boas candidatas para serem indexadas. 
 
Figura: Tabelas NIVEL e CURSO. 
SELECT * 
FROM CURSO 
WHERE NOME='Medicina' OR NOME='Nutrição'; 
O SGBD precisa avaliar se há algum registro na tabela CURSO cujo conteúdo da coluna NOME seja 
“Medicina” ou “Nutrição.” Trata-se de uma consulta enquadrada no item 2: há uma condição de seleção na 
cláusula WHERE envolvendo a coluna NOME: uma boa candidata para criação de índice. 
Veja a consulta II a seguir, que objetiva recuperar o nome do curso e o nível ao qual ele pertence: 
SELECT NOME, DESCRICAO 
FROM CURSO JOIN NIVEL ON (CURSO.CODIGONIVEL=NIVEL.CODIGONIVEL); 
A consulta usa um comando de junção (JOIN). 
A condição (CURSO.CODIGONIVEL=NIVEL.CODIGONIVEL) será avaliada diversas vezes ao longo 
do processamento da consulta. Trata-se de uma consulta enquadrada no item 4: as colunas CODIGONIVEL 
presentes na tabela são boas candidatas para criação de índices. 
No caso de operações de atualização de dados, é necessário conhecer: 
6. As tabelas alvo da atualização; 
7. A categoria da atualização em cada tabela: exclusão, atualização ou inserção; 
8. Colunas utilizadas em condições de seleção para exclusão ou atualização; 
9. Colunas alvo das operações de atualização. 
Ainda no contexto de indexação, colunas relacionadas ao item 3 são boas candidatas para serem 
indexadas. Ao mesmo tempo, o ideal é não criar índices para as colunas relacionadas ao item 4. Vamos 
estudar um exemplo? 
Veja a consulta III a seguir, que objetiva excluir todos os cursos que tenham a string “Engenharia”. 
DELETE FROM CURSO 
Sistema de Banco de Dados 
Marcio Quirino - 88 
 
WHERE CURSO LIKE '%ENGENHARIA%'; 
O SGBD precisa localizar os registros para então apagá-los do banco de dados. Para tanto, 
executará a condição de seleção presente no WHERE. Trata-se de uma consulta enquadrada no item 3: a 
coluna NOME presente na tabela é boa candidata para criação de índice. 
Frequência de chamada de consultas e transações esperada 
Vimos a importância de identificar detalhes sobre as consultas de recuperação e transações de 
atualização esperadas. No entanto, saber a respeito da frequência de uso esperada para operações de 
consulta e transações também é uma boa estratégia para obter desempenho. 
Atenção 
Aplicando-se a “regra do 80/20”, conhecida como Princípio de Pareto, em um sistema de banco de dados, 
estima-se que 80% do processamento é originado de somente 20% das consultas e transações. Por isso, é rara a 
necessidadede coletar informações estatísticas completas e taxas de chamada para todas as consultas e transações, 
bastando priorizar 20% das mais relevantes. 
Restrições de tempo de consulta e transações 
Dependendo da natureza da aplicação, podem existir consultas e transações com restrições de 
desempenho bastante rigorosas. Para exemplificar, poderia existir a restrição de que uma transação de 
compras tenha que terminar o seu processamento de pagamento dentro de sete segundos em 90% das 
vezes em que é chamada, e que ela nunca deve ultrapassar quinze segundos. 
Essas restrições referentes ao tempo têm forte impacto nas colunas candidatas a serem indexadas. 
Em especial, tais colunas devem ser priorizadas quando da decisão da criação de índices para as tabelas. 
Frequências esperadas de operações de atualização 
Se a tabela é atualizada com frequência, deve-se evitar a criação de índices nas colunas, pois a 
atualização de colunas indexadas, frequentemente, requer atualização na estrutura de índice. 
Exemplo 
Por exemplo, se uma tabela possui cinco colunas indexadas, a inserção de um novo registro requer a 
atualização dos índices, o que pode causar lentidão nesse tipo de operação. 
Restrições de exclusividade em colunas da tabela 
É útil criar índice para cada coluna com restrição de unicidade na tabela. Em uma operação típica de 
inserção, o SGBD pode validar essa restrição de exclusividade fazendo consulta à estrutura de índice, 
rejeitando a inserção caso o valor da coluna seja encontrado no índice. 
Consultas envolvendo mais de uma tabela 
Você perceberá que, em geral, a maior parte das consultas para recuperar informações de um banco 
de dados envolve diversas tabelas. Isso ocorre, principalmente, quando o projeto leva em conta as regras 
de normalização. 
Considere a estrutura de duas tabelas relacionadas, conforme a seguir: 
MUNICIPIO (CO_MUNICIPIO, NOME) 
DM_DOCENTE_2 (CO_DOCENTE_IES, CO_IES, NO_IES, CO_MUNICIPIO_NASCIMENTO) 
CO_MUNICIPIO_NASCIMENTO REFERENCIA MUNICIPIO 
A relação entre as tabelas está representada pela coluna de chave estrangeira 
CO_MUNICIPIO_NASCIMENTO da tabela DM_DOCENTE_2, a qual faz referência para a coluna chave 
primária CO_MUNICIPIO da tabela MUNICIPIO. 
Nosso objetivo é recuperar o código do docente e nome do município de nascimento dele. 
Sistema de Banco de Dados 
Marcio Quirino - 89 
 
Perceba que as colunas alvo do resultado estão presentes em tabelas distintas: NOME, na tabela 
MUNICIPIO e CO_DOCENTE_IES, na tabela DM_DOCENTE_2. 
O código em SQL que recupera os dados de interesse está expresso a seguir: 
SELECT CODIGO_DOCENTE_IES, NOME 
FROM DM_DOCENTE_2, MUNICIPIO 
WHERE 
MUNICIPIO.CO_MUNICIPIO=DM_DOCENTE_2.CO_MUNICIPIO_NASCIMENTO; 
A primeira linha do comando serve para declararmos as colunas que farão parte do resultado da 
consulta. Na segunda, informamos as tabelas de interesse. Finalmente, na última linha, há uma condição 
de filtro, envolvendo uma igualdade entre a chave primária da tabela MUNICIPIO e a chave estrangeira da 
tabela DM_DOCENTE_2. 
Para processar a consulta anterior, o SGBD cria uma estrutura de tabela temporária que contém a 
combinação de cada linha da tabela DM_DOCENTE_2 com cada linha da tabela MUNICIPIO. Se 
considerarmos os 367.980 registros de DM_DOCENTE_2 e os 5.570 registros da tabela MUNICIPIO, a 
tabela temporária teria mais de dois bilhões de linhas (367.980*5.570). Finalmente, a partir da tabela 
temporária, o SGBD executa o filtro especificado no comando WHERE para então exibir as colunas listadas 
no comando SELECT. O processo anterior é bastante custoso para o SGBD, ainda que cada sistema 
internamente use técnicas para otimizar o processamento. 
Atenção 
Note que, se esse tipo de consulta for frequente, haverá grande probabilidade de lentidão no sistema. 
A seguir, apresentaremos uma alternativa para minimizar esse custo, no entanto tendo como 
consequência a introdução de algum nível de redundância nos dados. 
Desnormalizar para ganhar desempenho 
Quando um esquema de banco de dados está normalizado até a 3FN, os problemas com 
redundância de dados são minimizados, pois, em geral, existe uma tabela para cada objeto modelado. 
Ao mesmo tempo, vimos que processar a consulta anterior requer acesso às duas tabelas para 
recuperar as informações - o que gera um custo adicional de processamento. 
Logo, se quisermos priorizar desempenho, teremos que sacrificar as vantagens de um modelo 
normalizado. Esse processo é conhecido por desnormalização. 
Nossa intenção a partir de agora é gerar uma estrutura que permita obter os mesmos resultados da 
consulta anterior, no entanto, usando somente uma tabela. Esse tipo de situação é comum quando temos a 
necessidade de produzir relatórios em um sistema. 
Ao desnormalizar o modelo, ficamos com a seguinte tabela: DM_DOCENTE_2 (CO_DOCENTE_IES, 
CO_IES, NO_IES, CO_MUNICIPIO_NASCIMENTO, NOME). Note que a coluna NOME é dependente da 
coluna CO_MUNICIPIO_NASCIMENTO, ou seja, precisamos ter em mente que estamos diante de uma 
dependência funcional parcial, violando a 2FN. 
Diante da nova estrutura, o código a seguir recupera as informações, agora envolvendo somente 
uma tabela: 
SELECT CODIGO_DOCENTE_IES, NOME 
FROM DM_DOCENTE_2; 
Atenção 
O processo de desnormalização deve ser planejado com critério, visto que, ao mesmo tempo em que há 
potencial de ganho em relação ao desempenho de determinadas consultas, a desnormalização introduz redundância 
Sistema de Banco de Dados 
Marcio Quirino - 90 
 
nos dados e, ao mesmo tempo, é necessária atualização adicional visando manter a consistência das colunas 
redundantes. 
Ao longo deste módulo, percebemos que a criação do modelo físico em um SGBD está atrelada ao 
objetivo de criar um banco de dados de maneira que problemas de baixo desempenho sejam evitados. Para 
isso, é necessário mapear as principais consultas e transações a serem processadas ao longo do ciclo de 
vida do banco de dados. 
Verificando o aprendizado 
1. Acerca do processo de desnormalização, assinale a proposição verdadeira. 
Ao desnormalizar um modelo da 3FN para a 2FN, introduz-se redundância de dados, tendo 
vantagem aumento do desempenho no acesso aos dados. 
De fato, quando aplicamos a desnormalização em um banco de dados, o conteúdo de uma ou 
mais tabelas é movido para outra tabela. Com isso, certa redundância é inserida no sistema. Por 
outro lado, consultas que, anteriormente, envolviam diversas tabelas, em geral passam a ser 
executadas diretamente na tabela desnormalizada 
2. Os índices são usados em bancos de dados com a mesma finalidade dos índices de livros, 
isto é, para acelerar a consulta a determinados dados. Como se tratam de estruturas 
auxiliares que ocupam espaço e geram redundância de dados, é preciso critério na escolha 
dos dados a serem indexados. 
Qual das alternativas abaixo menciona elementos de um banco de dados que são 
candidatos a serem indexados? 
Colunas mais usadas em condições de seleção. 
Para acelerar o processamento de consultas ao banco de dados, uma das técnicas mais usadas 
é criar índices para as colunas de tabelas que mais aparecem nas cláusulas WHERE dos 
comandos de consulta SELECT. 
Considerações Finais 
Este tema iniciou com o estudo dos componentes do modelo relacional de banco de dados. Além 
das tabelas e seus componentes, foram apresentadas as definições de chave primária e de chave 
estrangeira como elementos importantes na implementação de relacionamentos. 
Investigamos as três primeiras formas normais, como modos de construir modelos livres das 
redundâncias que aparecem em algumas dependências funcionais. Depois, analisamos uma série de regras 
usadas para o mapeamento do modelo conceitual para o modelo lógico. 
Finalmente, investigamos diretrizes que devem ser levadas em consideração quando da 
implementação do modelo físico em um SGBD. 
Referências 
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7.Ed. São Paulo:Pearson, 2019. 
HEUSER, Carlos A. Projeto de Banco de Dados. 6.Ed. Porto Alegre: Bookman, 2009. 
SOUZA, Odécio. Edgar Frank Codd and the Relational Database: a contribution to the History of 
Computing. 2015. 155 f. Dissertação (Mestrado em História da Ciência) - Pontifícia Universidade Católica 
de São Paulo, São Paulo, 2015. 
Sistema de Banco de Dados 
Marcio Quirino - 91 
 
Explore+ 
Para aprofundar seu conhecimento sobre a ferramenta BrModelo, acesse o portal GitHub e obtenha 
informações sobre a correção de bugs e outras funcionalidades. 
Caso tenha interesse em continuar estudando as ferramentas comerciais, acesse o site Vertabelo. 
Observe como funcionam as ferramentas de modelagem, as quais permitem o uso de alguma notação 
gráfica para representar um banco de dados relacional, conforme mencionado na seção Esquema 
diagramático de banco de dados relacional. 
Para complementar seu estudo, leia o texto Edgar Frank Codd e o Banco de Dados Relacional: uma 
contribuição para a História da Computação, de Odécio Souza, publicado pela Pontifícia Universidade 
Católica de São Paulo, São Paulo, 2015. O material fala sobre o modelo relacional que foi introduzido por 
Ted Codd, pesquisador visionário que apresentou em 1970 as bases científicas sobre as quais a maior parte 
dos SGBDs relacionais fazem uso. Trata-se de um trabalho completo sobe as contribuições de Codd para a 
Ciência da Computação. 
Recomendamos ainda que você leia na referência (ELMASRI e NAVATHE, 2019) o capítulo que trata 
sobre indexação. O desempenho de um banco de dados relacional em termos de recuperação de 
informações a partir de determinada consulta tem relação direta com o projeto dos mecanismos de 
indexação. 
Exercícios 
1. Qual dos fatores a seguir não deve ser levado em consideração ao implementarmos um 
banco de dados levando em conta questões de desempenho? 
Organização de políticas de acesso a dados. 
2. Formar novas relações, separando-as a partir de grupos de repetição antes existentes 
dentro de uma relação, é objetivo da: 
1FN 
3. A figura acima apresenta o modelo entidade relacionamento (ER) de uma situação 
hipotética que considera eleitores votando em candidatos a cargo público em uma eleição. 
O processo de mapeamento do modelo ER para o modelo relacional gera relações. 
Assinale a opção que apresenta as relações corretas que serão geradas ao mapear o 
modelo ER apresentado para o modelo relacional. Considere a seguinte notação: (PK) - 
atributos que compõem a chave primária e (FK) - atributos que compõe a chave 
estrangeira. 
 
Sistema de Banco de Dados 
Marcio Quirino - 92 
 
 
eleitor (id_eleitor(pk), nome, titulo) 
candidato (id_eleitor(pk)(fk), numero, legenda, id_cargo(fk)) 
votação((id_eleitor_eleitor(fk), id_eleitor_candidato(fk))(pk)) 
cargo(id_cargo(pk), desc_cargo) 
4. Em um projeto de banco de dados, a desnormalização é recomendada quando: 
Há necessidade de reduzir o número de tabelas envolvidas em consultas que acontecem 
com frequência, com a consequente redução do uso de recursos pelo SGBD. 
5. O Modelo Relacional usa: 
Uma coleção de tabelas para representar os dados e as relações entre eles. 
 
Sistema de Banco de Dados 
Marcio Quirino - 93 
 
Criação e Manipulação de Objetos no PostgreSQL 
Definição 
Instalação do PostgreSQL. Tipos de dados. Criação de tabelas. Manipulação de linhas. Controle de 
transação. 
Propósito 
Compreender a instalação do PostgreSQL é importante para conhecer um ambiente computacional 
típico de banco de dados em ambientes corporativos. Entender sobre tipos de dados é a base para escolhas 
compatíveis com a natureza dos dados a serem armazenados. Para desenvolver sistemas com uso de 
banco de dados, é necessário conhecer os comandos para manipulação de linhas nas tabelas, além de 
identificar como eles são controlados a partir do conceito de transação. 
Preparação 
Antes de iniciar o conteúdo deste tema, certifique-se de ter baixado o SGBD PostgreSQL em seu 
computador. 
Introdução 
Ao longo deste tema, vamos analisar as características básicas do sistema gerenciador de banco de 
dados (SGBD) PostgreSQL, envolvendo as etapas utilizadas para instalar esse SGBD no Linux e no 
Windows. 
O PostgreSQL é um SGBD de código aberto desenvolvido em linguagem C e está disponível para 
ser utilizado em diversos ambientes de sistemas operacionais, tais como Linux, Unix, Windows, OS X, 
Solaris, entre outros. 
Vamos explorar vários recursos da linguagem SQL, com foco na aprendizagem de comandos 
classificados como DDL. Aprenderemos também comandos CRUD, sigla em inglês que faz referência a 
quatro operações básicas: criação, consulta, atualização e remoção de dados, respectivamente. 
Por fim, vamos entender que, internamente, o SGBD trata de diversas operações de maneira 
atômica, ou seja, um conjunto de comandos deve ser executado como uma unidade lógica de trabalho, ou 
nenhuma operação deve ser realizada. Trata-se do conceito de transação. Aprenderemos, então, os 
principais comandos que gerenciam transações. 
1. Processo de instalação do PostgreSQL 
Breve histórico 
O PostgreSQL surgiu a partir de um projeto denominado POSTGRES, assim denominado por ser 
originário do projeto INGRES (Post INGRES), de responsabilidade da Universidade da Califórnia em 
Berkeley. 
A implementação do POSTGRES foi iniciada em 1986, tornando-se operacional em 1987. Sua 
primeira versão foi lançada ao público externo em 1989. Nos dois anos seguintes, foram lançadas a segunda 
e terceira versões. 
Em 1995, foi disponibilizado o Postgres95, com revisão no código do projeto e a adoção da linguagem 
SQL como interface padrão. 
Sistema de Banco de Dados 
Marcio Quirino - 94 
 
Em 1996, o produto foi renomeado para PostgreSQL, começando pela versão 6, considerado 
continuidade do Postgres95, a versão 5. O projeto ganhou visibilidade e, atualmente, o PostgreSQL é 
conhecido como um dos principais SGBDs de código aberto, com versões para Windows, Mac OS e Linux. 
Arquitetura do PostgreSQL 
Antes de instalarmos o PostgreSQL, é importante entendermos sua arquitetura básica. O 
PostgreSQL utiliza o modelo cliente-servidor. Sob esse contexto, destacamos os seguintes processos que 
cooperam entre si: 
Processo servidor, responsável por funções, tais como: 
• Gerenciar os arquivos do banco de dados; 
• Gerenciar as conexões entre os aplicativos e o SGBD; 
• Avaliar e executar no banco de dados os comandos submetidos pelos clientes. 
Aplicativo cliente do usuário, responsável por funções, tais como: 
• Solicitar acesso ao SGBD; 
• Enviar comandos para manipulação de linhas em tabelas. A manipulação pode envolver, por 
exemplo, inserção, alteração ou mesmo remoção de dados; 
• Enviar comandos para consulta em uma ou diversas tabelas, com objetivo de recuperar 
informações do banco de dados. 
Em um ambiente cliente-servidor, tanto o cliente quanto o servidor podem estar localizados em 
máquinas diferentes, em uma rede local ou mesmo geograficamente distantes. 
Em geral, a comunicação entre cliente e servidor ocorre por meio de uma conexão de rede utilizando 
o protocolo TCP/IP. Esse protocolo tem por objetivo a padronização das comunicações em rede, em especial 
as comunicações na Web. 
O PostgreSQL suporta várias conexões simultâneas de clientes. Para isso, um processo para cada 
conexão é iniciado. Em seguida, o cliente e o novo processo realizam comunicação. 
Como instalar o PostgreSQL em seu computador? 
Resposta 
Recomendamos que você acompanhe as versões do PostgreSQL na página oficial do produto para escolher 
uma versão de acordo com seu sistema operacional e que lhe interesse. 
Instalação do PostgreSQL no Linux 
Para instalação em Linux com código fonte, você pode executar os passos a seguir: 
Fazer download do arquivo .tar.gz 
• Se considerarmos o Ubuntu, o download pode ser realizado a partir do site do PostgreSQL, na 
seção relativa a esse sistema operacional. Usaremoso qualificador “--" para comentários a 
respeito dos comandos. 
Obter o código fonte 
• No prompt do Linux, executar os dois comandos a seguir: 
o gunzip postgresql-12.3.tar.gz 
▪ -- descompacta o arquivo .gz gerando o arquivo .tar 
o tar xf postgresql-12.3.tar 
▪ -- abre o arquivo .tar criando o diretório postgresql-12.3 
Sistema de Banco de Dados 
Marcio Quirino - 95 
 
Acessar o diretório criado pelo tar 
• Após a conclusão da etapa anterior, deve-se executar o comando a seguir para ter acesso ao 
diretório criado pelo tar: 
o cd postgresql-12.3 
▪ -- cd (change directory) 
Realizar o processo de instalação 
• Após a conclusão da etapa anterior, é preciso executar os comandos a seguir para realizar o 
processo de instalação do PostgreSQL: 
o ./configure 
▪ -- script para configurar a árvore de diretórios (cria o diretório /usr/local/psql) 
o gmake 
▪ -- GNU make: inicializa o build, pode levar de 5 a 30 minutos e termina com a 
mensagem: 
▪ – All of PostgreSQL is successfully made. Ready to install. 
o su 
▪ -- muda login de usuário para o superusuário root (pede a senha do root) 
o gmake install 
▪ -- realiza a instalação como root 
Checar a instalação 
• Após a conclusão da etapa anterior, deve-se executar os comandos a seguir para checar 
instalação do PostgreSQL: 
o adduser postgres 
▪ -- cria usuário postgres, superusuário do PostgreSQL (seuseradd no Fedora) 
o mkdir /usr/local/pgsql/data 
▪ -- cria o diretório data onde ficarão as bases de dados 
o chown postgres /usr/local/pgsql/data 
▪ -- muda o dono do diretório data para postgres 
o su - postgres 
▪ -- muda login de usuário para postgres 
o /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data 
▪ -- cria um grupo de BD no diretório data 
o /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 & 
▪ -- inicializa o servidor em segundo plano 
o /usr/local/pgsql/bin/createdb test 
▪ -- cria um database test 
o /usr/local/pgsql/bin/psql test 
▪ -- inicia uma sessão no PostgreSQL, usando a interface de linha de comandos 
psql, como usuário postgres no database test 
Instalação do PostgreSQL no Windows 
Atenção 
O procedimento para instalação do PostgreSQL no sistema operacional Windows é bastante trivial e 
basicamente segue o padrão (Next → Next → ... → Finish). 
Após fazer o download do arquivo instalador para Windows (postgresql-12.3-1-windows-x64.exe, 
com cerca de 195 MB, no caso da versão 12), deve-se executar o arquivo como usuário administrador. Após 
a tela de inicialização da instalação, será mostrada a de localização do diretório de instalação que, por 
padrão, criará a pasta C:\Program Files\PostgreSQL\12, onde 12 é a versão do PostgreSQL. 
Sistema de Banco de Dados 
Marcio Quirino - 96 
 
 
Tela de definição do diretório de instalação. 
A seguir, o instalador perguntará quais componentes serão instalados junto com o servidor 
PostgreSQL. Por padrão, são instalados: 
O pgAdmin 
Uma interface gráfica de administração; 
O psql 
Uma ferramenta de linha de comando para administração; 
O Stack Builder 
Uma ferramenta útil para gerenciar a instalação de módulos complementares, tais como utilitários, drivers e 
extensões. 
 
Tela de seleção de componentes a instalar. 
Em seguida, o instalador determina o diretório onde ficarão armazenados os dados no seu servidor. 
Na instalação padrão do Windows, os dados ficam armazenados no diretório C:\Program 
Files\PostgreSQL\12\data. Nesse diretório, é criado um subdiretório C:\Program Files\ PostgreSQL\ 12\ data\ 
Sistema de Banco de Dados 
Marcio Quirino - 97 
 
base, dentro do qual será criada uma pasta numerada para cada database, a começar pelo database padrão 
do servidor, denominado postgres, criado com a instalação. 
Atenção 
Cada pasta correspondente a um database armazena arquivos numerados contendo metadados do catálogo 
do SGBD, assim como arquivos numerados para cada tabela criada dentro do database. 
 
Tela de localização do diretório de dados. 
Concluído o processo de instalação do PostgreSQL, será possível visualizar no pgAdmin 4 a árvore 
de diretórios da instalação padrão, contendo: 
Servers (1) PostgreSQL 12 
 Databases (1) postgres 
 Schemas (1) public 
 Tables 
 
Tela do pgAdmin 4 com a árvore de diretórios da instalação padrão do PostgreSQL. 
Sistema de Banco de Dados 
Marcio Quirino - 98 
 
Interfaces para interagir com o PostgreSQL 
Atenção 
Ao longo deste e dos próximos módulos, será necessário o uso de algum tipo de interface que permita conexão 
ao servidor e, em seguida, o acesso aos objetos de interesse. 
Além do pgAdmin 4, a interface gráfica própria que provê acesso aos recursos do SGBD via 
navegador, o PostgreSQL disponibiliza o psql, uma interface de linha de comando sobre a qual o usuário 
submete interativamente comandos ao SGBD, via terminal. 
O PostgreSQL possui uma excelente documentação disponível on-line, aplicável tanto para 
instalação em Linux quanto para Windows, considerada uma verdadeira enciclopédia de bancos de dados 
relacionais. Essa documentação é válida para uso dos recursos do PostgreSQL através de quaisquer 
interfaces. 
Alternativamente, você pode optar por baixar e usar interfaces projetadas por outros 
desenvolvedores. Por exemplo, o aplicativo DBeaver possui uma versão livre com excelentes 
funcionalidades. Trata-se de um aplicativo útil no desenvolvimento de atividades de administração de banco 
de dados. 
Criando databases com o pgAdmin 4 e com o psql 
Tendo instalado o PostgreSQL, para nos certificarmos de que o SGBD está funcionando de maneira 
adequada, realizaremos um teste envolvendo a criação de databases, conforme a seguir: 
• database BDTESTEPGADMIN, a ser criado usando o pgAdmin 4. 
• database BDTESTEPSQL, a ser criado usando o psql. 
No Windows, selecione o botão Iniciar, digite “pgAdmin 4” e tecle <enter>. Em seguida, o navegador 
será aberto, e você terá acesso a um ambiente onde aparece um único database denominado postgres, 
criado pelo instalador. 
 
Tela do pgAdmin 4 com o database postgres criado pelo instalador. 
Com o foco no database postgres, clique em Tools e em Query Tool para abrir um editor (Query 
Editor) onde você codificará e submeterá (utilizando a tecla F5 ou o botão correspondente com uma seta) 
comandos SQL ao servidor. 
Sistema de Banco de Dados 
Marcio Quirino - 99 
 
Vamos criar o database BDTESTEPGADMIN a partir do ambiente do pgAdmin 4. Digite o código a 
seguir no Query Editor e, em seguida, pressione a tecla F5 para executar o comando: 
CREATE DATABASE BDTESTEPGADMIN; 
Alternativamente, o database poderia ser criado usando a interface do pgAdmin 4, pressionado o 
botão direito do mouse sobre a pasta Databases e clicando em Create. 
Agora, vamos criar um database usando a interface de terminal psql. No Windows, a partir do botão 
Iniciar, digite “psql” e tecle <enter>. Logo um terminal será aberto e você executará o seguinte comando 
(teclando <enter> após o comando): 
CREATE DATABASE BDTESTEPSQL; 
Após o SGBD executar o comando, a tela do psql ficará conforme vemos a seguir: 
 
Tela do psql após criação do database BDTESTEPSQL. 
Ao final desse processo, podemos verificar, no pgAdmin 4, a criação dos dois databases conforme 
mostrado na imagem abaixo. 
 
Tela do pgAdmin 4 mostrando os databases recém-criados 
Neste módulo, apresentamos um breve histórico a respeito do PostgreSQL, além de detalhes sobre 
a arquitetura deste SGBD. Em seguida, mostramos o processo de instalação do SGBD no Linux e no 
Windows. Finalmente, verificamos a criação de databases utilizando as ferramentas pgAdmin 4 e psql, com 
objetivo de confirmarmos que a instalação foi realizada de maneira correta. 
Maiores detalhes sobre a utilização do pgAdmin 4 e do psql podem ser pesquisados nas respectivas 
documentações que acompanham os softwares. 
Sistema de Banco de Dados 
Marcio Quirino - 100 
 
Verificando o aprendizado 
1. Acercado SGBD PostgreSQL, assinale a proposição verdadeira. 
O PostgreSQL é um SGBD de código aberto, com versões compatíveis com diversos 
sistemas operacionais, tais como Windows, MAC OS e diversas distribuições Linux. 
2. Analise as seguintes proposições a respeito do PostgreSQL: 
 
I - O comando “create user bteste superuser inherit createdb createrole; ” cria um banco 
de dados denominado bteste. 
II - Ao Instalar o PostgreSQL versão 12 no Windows, a pasta padrão de instalação é 
“C:/Program Files/PostgreSQL/12”. 
III - O comando “create table cliente (codigoc int not null, nome char(80), constraint 
chavecliente primary key (codigoc));” cria uma tabela denominada cliente com as colunas 
codigoc e nome, sendo que a coluna codigoc é chave estrangeira. 
 
Identifique as proposições falsas: 
I e III. 
O comando expresso na primeira proposição cria um usuário denominado bteste, e não um banco 
de dados. O comando expresso na terceira proposição cria uma tabela denominada cliente. No 
entanto, a coluna codigoc é chave primária, e não chave estrangeira. 
2. Comandos para criação e alteração de tabelas 
Breve histórico da SQL 
A SQL foi criada na IBM na década de 1970, sendo originalmente chamada de SEQUEL, inspirada, 
principalmente, na aparente facilidade de uso do comando SELECT para consulta a tabelas dos bancos de 
dados relacionais. 
Com a evolução dos sistemas gerenciadores de banco de dados (SGBDs), diversas empresas 
lançaram produtos incorporando funcionalidades à SQL, o que ocasionou problemas de compatibilidade. 
Buscando uma solução, o instituto ANSI definiu padrões para a linguagem SQL, a qual passou a ser 
referenciada ANSI-SQL. 
Atualmente, há diversos SGBDs compatíveis com o padrão ANSI SQL, que vai muito além de 
consultas com o comando SELECT, englobando sublinguagens para definição de dados (CREATE, ALTER, 
DROP) e para manipulação de dados (INSERT, UPDATE, DELETE), além de comandos de controle típicos 
para administração do banco de dados. Ao mesmo tempo, vários produtos de SGBDs relacionais 
apresentam extensões à linguagem, como modo de facilitar o dia a dia dos desenvolvedores. 
Acesso ao PostgreSQL 
Quero criar tabelas em um SGBD PostgreSQL. Por onde começo? 
1. Executando o pgAdmin 4, o navegador será aberto, e você terá acesso ao ambiente que 
permite manipular os objetos do PostgreSQL. 
2. Depois, escolha um database na hierarquia e dê um clique com o botão inverso do mouse. 
Em seguida, escolha a opção Query Tool. 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 101 
 
Dica 
O pgAdmin é a interface Web padrão do PostgreSQL, mas você pode escolher o utilitário de sua preferência 
para praticar os comandos que aprenderemos ao longo das próximas seções. 
Criando um banco de dados 
Após escolher um utilitário para acessar o servidor PostgreSQL, será necessário criar um database 
para, em seguida, manipular tabelas. Por exemplo, para criarmos um database denominado bdestudo, é 
necessário executar o comando a seguir: 
-- Comando para criar um database. 
CREATE DATABASE BDESTUDO; 
No comando acima, a linha com “--” corresponde a comentário e seu conteúdo não é processado 
pelo SGBD. Caso haja necessidade de remover o database bdestudo, basta executar o comando a seguir: 
-- Comando para remover um database. 
DROP DATABASE BDESTUDO; 
Antes de prosseguirmos com a criação de tabelas, principal objetivo deste módulo, é preciso 
compreender que todo database criado no PostgreSQL possui um schema padrão denominado public, onde 
as tabelas a serem criadas no database serão armazenadas. Assim, se não especificarmos a qual schema 
do database pertence uma tabela que estamos criando, esta será armazenada no schema public. Para 
especificarmos um schema diferente do public, antes de criar uma tabela, devemos criar o respectivo 
schema, com o comando CREATE SCHEMA. 
Exemplo 
CREATE SCHEMA esquema; 
A partir de então, qualquer tabela pertencente ao schema esquema deverá ser especificada pelo seu 
nome completo: esquema.tabela 
Criando tabelas 
Já sabemos que um banco de dados, em geral, possui diversas tabelas. As tabelas são criadas com 
auxílio do comando CREATE TABLE. Usaremos esse comando para implementar o modelo expresso na 
figura a seguir, dentro do database bdestudo anteriormente criado: 
 
Modelo relacional com as tabelas CURSO e NIVEL. 
Veja a seguir a sintaxe básica do comando CREATE TABLE: 
CREATE TABLE NOMETABELA ( 
COLUNA1 - TIPODEDADOS [RESTRIÇÃO], 
COLUNAN - TIPODEDADOS [RESTRIÇÃO], 
PRIMARY KEY (COLUNA), 
FOREIGN KEY (COLUNA) REFERENCES NOMETABELA (COLUNA) 
CONSTRAINT RESTRIÇÃO); 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 102 
 
Vamos agora analisar o significado de cada item na sintaxe apresentada anteriormente: 
NOMETABELA representa o nome da tabela que será criada 
COLUNA1 e COLUNAN representa a(s) coluna(s) da tabela 
TIPODEDADOS indica tipo de dados ou domínio da coluna 
RESTRIÇÃO 
aponta alguma propriedade associada à coluna em questão. Por exemplo, 
podemos definir se a coluna é obrigatória ou opcional 
PRIMARY KEY indica a coluna, ou conjunto de colunas, representativa da chave primária 
FOREIGN KEY sinaliza a coluna, ou conjunto de colunas, com restrição de chave estrangeira 
CONSTRAINT RESTRIÇÃO indica alguma restrição que poderá ser declarada 
A sintaxe completa a respeito do comando CREATE TABLE no PostgreSQL pode ser encontrada no site oficial do 
PostgreSQL. Ao final da sintaxe, são descritas as características compatíveis com o padrão SQL. 
 
Tipos de dados 
Cada coluna de tabela deve pertencer a um tipo de dados. No PostgreSQL, os tipos mais comuns 
são: 
bigint valores inteiros compreendidos entre -9.223.372.036.854.775.808 e 9.223.372.036.854.775.807 
char(comprimento) 
útil para sequências de caracteres de tamanho fixo. O parâmetro comprimento determina o valor da 
sequência. Esse tipo de dado preenche a coluna com espaços em branco até completar o total de 
caracteres definidos, caso a totalidade do tamanho do campo não esteja preenchida 
date data de calendário no formato AAAA-MM-DD 
decimal determina a precisão do valor de casas decimais 
double precisão do valor de até 15 casas decimais 
int ou integer valores inteiros compreendidos entre -2.147.483.648 e 2.147.483.647 
money valores monetários compreendidos entre –92.233.720.368.547.758.08 e 92.233.720.368.547.758.07 
numeric precisão do valor de casas decimais 
real precisão do valor de até seis casas decimais 
serial gera valor único inteiro sequencial para um novo registro entre 1 e 2.147.483.647 
smallint representa valores compreendidos entre 32.768 e 32.767 
time representa horário no intervalo de tempo entre 00:00:00 e 24:00:00 
varchar(comprimento) 
útil para sequência de dados de caracteres com comprimento variável. Não armazena espaços em 
branco não utilizados para compor string (em branco) em seu lado direito 
 
Dica 
Para maiores detalhes sobre os tipos de dados, sugerimos que você acesse a documentação do PostgreSQL, 
disponível no site oficial do produto. 
Exemplo envolvendo criação de tabelas 
Veja a seguir o código SQL que permite a criação das tabelas NIVEL e CURSO, respectivamente: 
 
Sistema de Banco de Dados 
Marcio Quirino - 103 
 
A tabela NIVEL está especificada no bloco de comandos entre as linhas 2 e 6. As duas colunas da 
tabela são obrigatórias. 
A tabela CURSO está especificada no bloco de comandos entre as linhas 8 e 15. As colunas 
DATACRIACAO e CODIGONIVEL são opcionais. Em especial, CODIGONIVEL significa que um curso pode 
ser criado e, em outro momento, ser associado à informação que caracteriza o nível dele. 
Atenção 
Note que, como não foi especificado um schema para armazenar essas tabelas, elas pertencerão ao schema 
padrão public do database bdestudo. 
Finalmente, observe que, na linha 5, a coluna NOME foi declarada com o qualificador UNIQUE. Na 
prática, o SGBD controlará a propriedade de unicidade na referida coluna, proibindoque haja mais de uma 
ocorrência da mesma ao longo de todo o ciclo de vida do banco de dados. 
Gerenciamento de scripts na prática 
Note que o script SQL acima possui 15 linhas. Esse é um exemplo didático que possui somente duas 
tabelas. No entanto, você vai perceber que no dia a dia os projetos reais possuem quantidade de tabelas 
que facilmente podem ultrapassar dois dígitos. 
É importante que você conheça comandos DDL, mas o uso prático ocorrerá com auxílio de 
ferramentas que automatizam o processo de gestão e administração de dados. Tais ferramentas permitem 
- manipulando elementos visuais - criar tabelas, relacionamentos e restrições, além de executar outras 
atividades. As ferramentas permitem gerar código DDL referente ao projeto como um todo, ou parte dele. 
São exemplos: DBeaver, Vertabelo, SQL Power Architect, Toad for SQL, Erwin, entre outras. 
SGBD PostgreSQL nos bastidores 
Aprendemos a criar um database com o uso do comando CREATE DATABASE. No entanto, a 
submissão de um simples CREATE DATABASE ao PostgreSQL gera uma série de etapas gerenciadas pelo 
servidor. 
Se considerarmos a instalação padrão no Windows, ao criar um database o servidor cria uma pasta 
identificada por um número (OID), dentro do diretório C:\Program Files\PostgreSQL\12\data\base. 
 
Pastas representativas de databases, antes da criação do database TESTEBANCO. 
Após a execução do comando CREATE DATABASE TESTEBANCO; foi criada a pasta 41017, 
conforme imagem a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 104 
 
 
Pastas representativas de databases, após da criação de TESTEBANCO. 
Ainda, o PostgreSQL mantém informações sobre todos os databases em um database especial 
denominado catálogo, cujas tabelas possuem nomes iniciados com o prefixo PG_. Por exemplo, informações 
sobre os databases existentes em um servidor são armazenadas na tabela PG_DATABASE. Assim, caso 
você queira identificar o nome correspondente ao OID do PostgreSQL, basta executar o comando a seguir: 
SELECT OID, DATNAME FROM PG_DATABASE; 
O resultado desse comando pode ser visualizado na tabela a seguir: 
 
Resultado de consulta à tabela PG_DATABASE. 
Precisamos ressaltar que, em seu computador, o resultado poderá ser diferente do apresentado, 
tendo em vista as operações que você tenha realizado no SGBD. 
Alteração de tabela 
Você vai se deparar com situações em que será necessário alterar a estrutura de uma tabela já 
existente. 
Vamos estudar um exemplo? 
Suponha que surgiu a necessidade de modelar a informação sobre a data de primeiro 
reconhecimento do curso. Podemos, então, alterar a estrutura da tabela CURSO, adicionando uma coluna 
opcional denominada DTRECONH. O comando ALTER TABLE é útil no contexto dessa tarefa. 
A seguir, sintaxe básica do comando ALTER TABLE: 
ALTER TABLE <NOMETABELA> ADD <COLUNA><TIPODEDADOS>; 
Na sintaxe apresentada: 
<NOMETABELA> 
Representa o nome da tabela sobre a qual haverá a modificação. 
<COLUNA> 
Representa o nome da coluna. 
Sistema de Banco de Dados 
Marcio Quirino - 105 
 
<TIPODEDADOS> 
Representa o domínio da coluna. 
A sintaxe completa a respeito do comando ALTER TABLE pode ser encontrada no site oficial do 
PostgreSQL. 
A seguir, veja o código SQL que permite a alteração da tabela CURSO: 
-- Comando para alterar a tabela CURSO, adicionando coluna DTRECONH 
ALTER TABLE CURSO ADD DTRECONH DATE; 
Por padrão, o SGBD cria a coluna como opcional. É como se o comando estivesse com o qualificador 
NULL declarado imediatamente antes do “;”. 
E se desejarmos remover uma coluna da tabela? Podemos usar a sintaxe a seguir: 
-- Comando para alterar a tabela CURSO, removendo a coluna DTRECONH 
ALTER TABLE CURSO DROP DTRECONH; 
Remoção de tabela 
Você vai se deparar com situações em que será necessário remover uma tabela do banco de dados. 
Esta ação é realizada com o auxílio do comando DROP TABLE, cuja sintaxe está expressa a seguir: 
DROP TABLE <NOMETABELA>; 
Vamos agora remover a tabela CURSO com o devido código SQL: 
-- Comando para remover a tabela CURSO 
DROP TABLE CURSO; 
Agora, vamos conhecer alguns cuidados que devem ser tomados quando formos manipular a 
estrutura de tabelas relacionadas. 
Criação e alteração de tabelas relacionadas 
No exemplo envolvendo criação de tabelas, o relacionamento entre as tabelas NIVEL e CURSO foi 
declarado no bloco CREATE TABLE da tabela CURSO (linha 14). No entanto, nós poderíamos ter optado 
por criar as tabelas NIVEL e CURSO sem relacionamento, para, em seguida, alterar a tabela CURSO, 
adicionando a restrição de chave estrangeira. 
Na hipótese dessa estratégia, o script SQL ficaria do seguinte modo: 
 
Atenção 
Note que, no script anterior, as tabelas foram criadas sem chave estrangeira (linhas 1 a 12). Na linha 14, o 
comando ALTER TABLE modifica a estrutura da tabela CURSO, implementando a restrição de chave estrangeira que 
representa o relacionamento entre CURSO e NIVEL. 
Sistema de Banco de Dados 
Marcio Quirino - 106 
 
Cuidados ao manipular tabelas relacionadas 
Aprendemos que um banco de dados relacional é composto por diversas tabelas e que cada tabela 
em geral possui várias colunas. Vimos também que o relacionamento entre tabelas é implementado com o 
uso do mecanismo de chave estrangeira. 
Quando definimos que alguma coluna é uma chave estrangeira, na prática, estamos criando uma 
dependência entre as tabelas envolvidas, pois toda chave estrangeira aponta para o valor de alguma chave 
primária. 
Ao mesmo tempo, todo SGBD precisa manter a integridade dos dados durante todo o ciclo de vida 
do banco de dados. Com isso, não basta somente conhecermos a estrutura dos comandos para alteração 
de tabelas. 
Resumindo 
Queremos dizer que, em algumas situações, mesmo que o comando para alteração ou exclusão esteja correto 
sob o ponto de vista sintático, o SGBD sempre prioriza a integridade dos dados e pode inibir sua execução caso o 
resultado tenha potencial para gerar inconsistência nos dados. 
Vamos estudar um exemplo? 
Suponha que temos interesse em remover a tabela NIVEL. Para isso, executaremos o seguinte 
comando SQL: 
-- Comando para remover a tabela NIVEL 
DROP TABLE NIVEL; 
O SGBD não removerá a tabela NIVEL e retornará uma mensagem de erro, informando que há um 
objeto (tabela CURSO) que depende da tabela NIVEL. 
Perceba que se o SGBD removesse a tabela NIVEL, a tabela CURSO ficaria inconsistente, visto que 
sua chave estrangeira (CODIGONIVEL) faz referência à chave primária da tabela NIVEL. Assim, antes de 
remover uma tabela do banco de dados, é necessário avaliar todos os relacionamentos desta. 
E se ainda assim quiséssemos remover a tabela NIVEL? 
Resposta 
Antes, precisaríamos remover as dependências, para em seguida excluí-la do banco de dados. No entanto, 
como, no banco de dados, pode haver várias dependências envolvendo a tabela NIVEL – o que tornaria o processo 
mais demorado – o SGBD dispõe de um recurso que realiza essa tarefa automaticamente. Trata-se de remoção em 
cascata. 
Nesse caso, poderíamos usar o comando SQL a seguir: 
-- Comando para remover a tabela NIVEL - remoção em cascata 
DROP TABLE NIVEL CASCADE; 
Internamente, o comando altera a estrutura da tabela CURSO, removendo a restrição de chave 
estrangeira da coluna CODIGONIVEL. Em seguida, a tabela NIVEL é removida do banco de dados. 
Ao longo deste módulo, aprendemos comandos básicos da linguagem SQL, úteis para a criação de 
tabelas no SGBD PostgreSQL. Ainda, conhecemos os tipos de dados mais comuns do PostgreSQL. Em 
seguida, estudamos comandos para a alteração e a remoção de tabelas do banco de dados. 
Verificando o aprendizado 
1. Analise o script a seguir e assinale a proposição verdadeira: 
Sistema de Banco de Dados 
Marcio Quirino - 107 
 
 
A execução dos comandos entre as linhas 18 e 24 cria dois relacionamentos: o primeiro 
envolve as tabelas CURSODISCIPLINA e CURSO. O segundo, as tabelas 
CURSODISCIPLINA e DISCIPLINA. 
De fato,há dois blocos de comando entre as linhas 18 e 24. O primeiro altera a estrutura da 
tabela CURSODISCIPLINA adicionando à coluna CODIGOCURSO uma restrição de chave 
estrangeira que implementa o relacionamento entre as tabelas CURSODISCIPLINA e CURSO. 
O segundo altera a estrutura da tabela CURSODISCIPLINA, adicionando à coluna 
CODIGODISCIPLINA uma restrição de chave estrangeira que implementa o relacionamento 
entre as tabelas CURSODISCIPLINA e DISCIPLINA. 
2. Analise o modelo a seguir e assinale a proposição verdadeira: 
 
Admitindo a existência das tabelas CURSODISCIPLINA e CURSO, a execução do script a 
seguir relaciona CURSODISCIPLINA à CURSO. 
ALTER TABLE CURSODISCIPLINA ADD FOREIGN KEY (CODIGOCURSO) 
REFERENCES CURSO (CODIGOCURSO) 
De fato, se observarmos o modelo, há um relacionamento entre as tabelas CURSO e 
CURSODISCIPLINA. Ao executar o ALTER TABLE, a coluna CODIGOCURSO da tabela 
CURSODISCIPLINA passa a funcionar como chave estrangeira, fazendo referência à tabela 
CURSO. 
3. Comandos para manipular linhas nas tabelas 
Manipulação de linhas nas tabelas 
Quando usamos o termo manipulação, fazemos referência às operações de inserção, atualização ou 
mesmo eliminação de dados. Em uma linguagem mais comercial, existe o termo CRUD, que representa 
quatro operações básicas: criação, consulta, atualização e remoção de dados, respectivamente. 
No contexto da SQL, costumamos usar o seguinte mapeamento dos comandos: 
1. Create: INSERT 
2. Read: SELECT 
3. Update: UPDATE 
4. Delete: DELETE 
Sistema de Banco de Dados 
Marcio Quirino - 108 
 
Ainda, os comandos da linguagem SQL que aprenderemos fazem parte da DML e são usados para 
inserir, modificar e remover dados. 
Modelo para os exemplos 
Ao longo da nossa aprendizagem, nós vamos admitir que o modelo a seguir está criado no banco de 
dados: 
 
Tabelas CURSO, CURSODISCIPLINA e DISCIPLINA. 
Dica 
Recomendamos que você crie as tabelas e insira algumas linhas, o que pode ser feito usando o script a seguir, 
a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar conectado ao PostgreSQL 
e ao database bdestudo criado anteriormente. 
 
O modelo é útil para gerenciar os dados de cursos, disciplinas e do relacionamento entre esses 
objetos. Em especial, cada linha da tabela CURSODISCIPLINA representa uma associação entre curso e 
disciplina. 
Inserção de linhas em tabela 
A inserção de linhas em tabela é realizada com o auxílio do comando INSERT da SQL. Sua sintaxe 
básica está expressa a seguir: 
INSERT INTO <NOMETABELA> (COLUNA1, COLUNA2,…,COLUNAn) VALUES (VALOR1, VALOR2,…,VALORn); 
Na sintaxe, <NOMETABELA> representa a tabela alvo da inserção. Em seguida, são declaradas as 
colunas que receberão os dados; por último, os dados em si. Note que deve haver uma correspondência 
entre cada par COLUNA/VALOR, ou seja, o conteúdo de cada coluna deve ser compatível com o tipo de 
dados ou domínio dela. 
A sintaxe completa a respeito do comando INSERT pode ser encontrada no site oficial do 
PostgreSQL. 
Vamos estudar um exemplo? 
Iremos cadastrar quatro cursos. O comando SQL a seguir pode ser utilizado: 
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) 
VALUES( 1,'Sistemas de Informação','19/06/1999'); 
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) 
Sistema de Banco de Dados 
Marcio Quirino - 109 
 
VALUES( 2,'Medicina','10/05/1990'); 
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) 
VALUES( 3,'Nutrição','19/02/2012'); 
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) 
VALUES( 4,'Pedagogia','19/06/1999'); 
Atenção 
Note que, dentro dos parênteses representativos dos conteúdos, o primeiro valor, por ser do tipo inteiro, foi 
informado sem aspas. Já o segundo valor, por ser do tipo char, foi informado com aspas. Finalmente, o valor referente 
ao tipo date também foi informado entre aspas. Internamente, o PostgreSQL converte o texto para o formato de data. 
Agora, faremos um procedimento semelhante, cadastrando quatro disciplinas. O comando SQL a 
seguir pode ser utilizado: 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA,NOME,CARGAHORARIA) 
VALUES( 1,''Leitura e Produção de Textos',60); 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA,NOME,CARGAHORARIA) 
VALUES( 2,''Redes de Computadores',60); 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA,NOME,CARGAHORARIA) 
VALUES( 3,'Computação Gráfica',40); 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA,NOME,CARGAHORARIA) 
VALUES( 4,'Anatomia',60); 
Agora, vamos registrar na tabela CURSODISCIPLINA algumas associações entre cursos e 
disciplinas. O comando SQL a seguir pode ser utilizado: 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (1,1); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (1,2); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (1,3); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (2,1); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (2,3); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (3,1); 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (3,3); 
E se submetermos ao SGBD o comando a seguir? 
INSERT INTO CURSODISCIPLINA(CODIGOCURSO,CODIGODISCIPLINA) VALUES (3,30); 
Resposta 
O SGBD não realizará a inserção e retornará uma mensagem de erro informando que 30 não é um valor 
previamente existente na chave primária da tabela DISCIPLINA. Isso acontece porque, quando definimos (linha 16 do 
script da seção anterior) a chave estrangeira da tabela CURSODISCIPLINA, nós delegamos ao SGBD a tarefa de 
realizar esse tipo de validação com objetivo de sempre manter a integridade dos dados do banco de dados. Note que 
não existe disciplina identificada de código 30 na tabela DISCIPLINA. 
Mecanismo de chave primária em ação 
Já vimos que o SGBD é responsável por manter a integridade dos dados ao longo de todo o ciclo de 
vida do banco de dados. A consequência disso pode ser percebida ao tentarmos executar (novamente) o 
comando a seguir: 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA, NOME, CARGAHORARIA) VALUES (4,'Anatomia',60); 
Como já existe um registro com valor de CODIGODISCIPLINA igual a 4, o SGBD exibirá mensagem 
de erro informando que o referido valor já existe no banco de dados. Semelhantemente, devemos lembrar 
que todo valor de chave primária é obrigatório. 
Vamos agora tentar inserir uma disciplina sem valor para CODIGODISCIPLINA, conforme comando 
SQL a seguir: 
INSERT INTO DISCIPLINA (CODIGODISCIPLINA, NOME, CARGAHORARIA) VALUES (NULL,'Biologia Celular 
e Molecular',60); 
Sistema de Banco de Dados 
Marcio Quirino - 110 
 
O SGBD exibirá mensagem de erro informando que o valor da coluna CODIGODISCIPLINA não 
pode ser nulo. 
Atualização de linhas em tabela 
A atualização de linhas em tabela é realizada com o auxílio do comando UPDATE da SQL. Sua 
sintaxe básica está expressa a seguir: 
UPDATE <NOMETABELA> 
SET COLUNA1=VALOR1, COLUNA2=VALOR2,…,COLUNAn=VALORn 
WHERE <CONDIÇÃO>; 
Na sintaxe, <NOMETABELA> representa a tabela alvo da atualização. Em seguida, é declarada uma 
lista contendo a coluna e o seu respectivo valor novo. Por último, uma condição lógica, caso seja necessário. 
Isso ocorre porque, em geral, estamos interessados em alterar somente um subconjunto de linhas que é 
obtido a partir do processamento da cláusula WHERE. A sintaxe completa a respeito do comando UPDATE 
pode ser encontrada no site oficial do PostgreSQL. 
Vamos estudar alguns exemplos? 
Alteraremos para 70 a carga horária da disciplina Redes de Computadores. Para isso, basta executar 
o comando a seguir: 
UPDATE DISCIPLINA SET CARGAHORARIA=70 WHERE CODIGODISCIPLINA=2; 
No comando, o SGBD busca na tabela a disciplina cujo valor da coluna CODIGODISCIPLINA seja 
igual a 2. Em seguida, atualiza o valor da coluna CARGAHORARIA para 70. Note também que poderíamos 
ter executado o comando a seguir: 
UPDATE DISCIPLINA SET CARGAHORARIA=70 WHERE NOME='Redes de Computadores';Suponha agora que houve a necessidade de alterar em 20% a carga horária de todas as disciplinas 
cadastradas no banco de dados. Podemos executar o seguinte comando: 
UPDATE DISCIPLINA SET CARGAHORARIA=CARGAHORARIA*1.2; 
Note que, no último comando, não foi necessária a cláusula WHERE, visto que o nosso interesse era 
o de atualizar todas as linhas da tabela DISCIPLINA. Ainda, para obter o novo valor, nós utilizamos a 
expressão CARGAGORARIA*1.2. 
Atualização de coluna chave primária 
Devemos ter especial cuidado ao planejarmos alterar o valor de coluna com o papel de chave 
primária em uma tabela. 
Vamos supor que seja necessário alterar para 6 o valor de CODIGOCURSO referente ao curso de 
Pedagogia. Podemos, então, executar o comando a seguir: 
UPDATE CURSO SET CODIGOCURSO=6 WHERE CODIGOCURSO=4; 
Perceba que o SGBD processará a alteração, visto que não há vínculo na tabela CURSODISCIPLINA 
envolvendo este curso. No entanto, o que aconteceria se tentássemos alterar para 10 o valor de 
CODIGOCURSO referente ao curso de Sistemas de Informação? 
Seguindo a mesma linha de raciocínio da última alteração, vamos submeter o comando a seguir: 
UPDATE CURSO SET CODIGOCURSO=10 WHERE CODIGOCURSO=1; 
Atenção 
O SGBD não realizará a alteração e retornará uma mensagem de erro indicando que o valor 1 está registrado 
na tabela CURSODISCIPLINA, coluna CODIGOCURSO. Isso significa que, se o SGBD aceitasse a alteração, a tabela 
CURSODISCIPLINA ficaria com dados inconsistentes, o que não deve ser permitido. 
Sistema de Banco de Dados 
Marcio Quirino - 111 
 
Assim, de modo semelhante ao que aprendemos na seção Mecanismo de chave primária em ação, 
deixaremos o SGBD realizar as alterações necessárias para manter a integridade dos dados. Vamos, então, 
submeter o comando a seguir: 
ALTER TABLE CURSODISCIPLINA 
DROP CONSTRAINT CURSODISCIPLINA_CURSO, 
ADD CONSTRAINT CURSODISCIPLINA_CURSO 
FOREIGN KEY (CODIGOCURSO) REFERENCES CURSO (CODIGOCURSO) 
ON UPDATE CASCADE; 
O que fizemos? Usamos o comando ALTER TABLE para alterar a estrutura da tabela 
CURSODISCIPLINA, removemos a chave estrangeira (comando DROP CONSTRAINT) e, por último, 
recriamos a chave (ADD CONSTRAINT), especificando a operação de atualização (UPDATE) em cascata. 
Assim, após o processamento da alteração anterior, podemos então submeter o comando, conforme 
a seguir: 
UPDATE CURSO SET CODIGOCURSO=10 WHERE CODIGOCURSO=1; 
Remoção de linhas em tabela 
A remoção de linhas em tabela é realizada com o auxílio do comando DELETE da SQL. Sua sintaxe 
básica está expressa a seguir: 
DELETE FROM <NOMETABELA> 
WHERE <CONDIÇÃO>; 
Na sintaxe, <NOMETABELA> representa a tabela alvo da operação de deleção de linha(s). Por 
último, há uma condição lógica, caso seja necessário. Isso ocorre porque, em geral, estamos interessados 
em remover somente um subconjunto de linhas que é obtido a partir do processamento da cláusula WHERE. 
A sintaxe completa a respeito do comando DELETE pode ser encontrada no site oficial do PostgreSQL. 
Vamos estudar alguns exemplos? 
Suponha que temos interesse em apagar do banco de dados a disciplina de Anatomia. Podemos, 
então, submeter o código a seguir: 
DELETE FROM DISCIPLINA WHERE CODIGODISCIPLINA=4; 
O SGBD localiza na tabela DISCIPLINA a linha cujo conteúdo da coluna CODIGODISCIPLINA seja 
igual a 4. Em seguida, remove do banco de dados a linha em questão. 
Agora vamos imaginar que tenha surgido a necessidade de remover do banco de dados a disciplina 
de Leitura e Produção de Textos. Podemos, então, submeter o código a seguir: 
DELETE FROM DISCIPLINA WHERE CODIGODISCIPLINA=1; 
O SGBD não realizará a remoção e retornará uma mensagem de erro indicando que o valor 1 está 
registrado na tabela CURSODISCIPLINA, coluna CODIGODISCIPLINA. Se o SGBD aceitasse a remoção, 
a tabela CURSODISCIPLINA ficaria com dados inconsistentes, o que não deve ser permitido. 
Assim, de modo semelhante ao que aprendemos na seção Mecanismo de chave primária em ação, 
deixaremos o SGBD realizar as alterações necessárias para manter a integridade dos dados. Vamos, então, 
submeter o comando a seguir: 
ALTER TABLE CURSODISCIPLINA 
DROP CONSTRAINT CURSODISCIPLINA_DISCIPLINA, 
ADD CONSTRAINT CURSODISCIPLINA_DISCIPLINA 
FOREIGN KEY (CODIGODISCIPLINA) REFERENCES DISCIPLINA (CODIGODISCIPLINA) 
ON DELETE CASCADE; 
Sistema de Banco de Dados 
Marcio Quirino - 112 
 
O que fizemos? Usamos o comando ALTER TABLE para alterar a estrutura da tabela 
CURSODISCIPLINA:, removemos a chave estrangeira (comando DROP CONSTRAINT) e, por último, 
recriamos a chave (ADD CONSTRAINT), especificando operação de remoção (DELETE) em cascata. 
Assim, após o processamento da alteração anterior, podemos submeter o comando conforme a 
seguir: 
DELETE FROM DISCIPLINA WHERE CODIGODISCIPLINA=1; 
Ao processar o comando, o SGBD verifica se existe alguma linha da tabela CURSODISCIPLINA com 
valor 1 para a coluna CODIGODISCIPLINA. Caso encontre, cada ocorrência é então removida do banco de 
dados. 
E se quiséssemos eliminar todos os registros de todas as tabelas do banco de dados? 
Resposta 
Para realizarmos esta operação, precisaremos identificar quais tabelas são mais independentes e quais são 
as que possuem vínculos de chave estrangeira. 
No caso do nosso exemplo, CURSODISCIPLINA possui duas chaves estrangeiras, portanto, é a 
tabela mais dependente. As demais, não possuem chave estrangeira. De posse dessa informação, podemos 
submeter os comandos a seguir para completar a tarefa: 
DELETE FROM CURSODISCIPLINA; 
DELETE FROM CURSO; 
DELETE FROM DISCIPLINA; 
Perceba que a primeira tabela que foi usada no processo de remoção de linhas foi a 
CURSODISCIPLINA, pois essa é a responsável por manter as informações sobre o relacionamento entre 
as tabelas CURSO e DISCIPLINA. Após eliminar os registros de CURSODISCIPLINA, o SGBD removerá 
com sucesso os registros das tabelas CURSO e DISCIPLINA. 
Ao longo deste módulo, aprendemos os comandos básicos da linguagem SQL, os quais são úteis 
para a manipulação de linhas no SGBD PostgreSQL. Também estudamos comandos para inserir, alterar e 
eliminar linhas em tabelas. 
Verificando o aprendizado 
1. Analise o script a seguir e assinale a proposição correta: 
 
Após a execução com sucesso do trecho entre as linhas 1 e 16, se executarmos o 
comando expresso na linha 25, o SGBD retornará uma mensagem de erro. 
Sistema de Banco de Dados 
Marcio Quirino - 113 
 
De fato, se observarmos as inserções em CURSO e DISCIPLINA, vamos perceber que os 
valores de chave primária são os inteiros 1 e 2 em ambos os casos. Ainda, a tabela 
CURSODISCIPLINA possui duas chaves estrangeiras: uma referência à tabela CURSO; a outra, 
referência à tabela DISCIPLINA. Portanto, o valor para CÓDIGODISCIPLINA da tabela 
CURSODISCIPLINA não pode ser diferente de 1 ou 2. 
2. Analise o script a seguir e assinale a proposição correta: 
 
Após a execução, com sucesso, do trecho entre as linhas 1 e 26, se executarmos o 
comando expresso na linha 28, quantas linhas serão removidas do SGBD? 
Três. 
De fato, a chave estrangeira declarada na linha 15 foi criada de maneira a permitir a deleção em 
cascata. Ao executar o comando da linha 28, o SGBD eliminará tanto os dois registros da tabela 
CURSODISCIPLINA (cujo valor de CODIGOCURSO é igual a 1) quanto o registro referente ao 
curso Sistemas de Informação. 
4. Comandos de controle de transação 
Transações em banco de dados 
Ao longo do nosso estudo, aprendemos uma série de comandos SQL envolvendo desde a criação 
de tabelas até operações de manipulação de dados, tais como inserções, atualizações e exclusões. 
Basicamente, um comando era codificado e submetido ao SGBD PostgreSQL, que em seguida o executava 
e devolvia algum resultado. 
Perceba que, sob o contexto dos exemplos que estudamos, poderíamos concluir que, de certa 
maneira, havia somente um usuário acessando a totalidade dos recursos do SGBD. 
No entanto, em um ambiente deprodução, o SGBD gerencia centenas de requisições das aplicações. 
Com isso, concluímos que há acesso simultâneo a vários recursos que são gerenciados pelo SGBD. 
Ao mesmo tempo, o usuário de uma aplicação que faz uso de recursos de um banco de dados, 
normalmente, está preocupado com o resultado dos processos de negócio que estão automatizados. 
Para exemplificar, digamos que um sistema acadêmico disponibiliza a inscrição em diversas 
disciplinas; determinado aluno, após consultar a oferta e escolher um conjunto de matérias para inscrição, 
tem expectativa de conseguir inscrever-se em todas as disciplinas alvo da escolha. 
No entanto, sob o ponto de vista do SGBD, prover a inscrição em todas as disciplinas escolhidas 
pelo estudante requer a execução, na totalidade, de diversas instruções de inserção de dados em alguma 
Sistema de Banco de Dados 
Marcio Quirino - 114 
 
tabela. Além disso, deve existir cuidado especial para, por exemplo, inibir inscrição em disciplina caso não 
haja mais disponibilidade de vagas. 
Atenção 
É uma situação típica sobre a qual o SGBD precisa prover uma forma de realizar diversas operações como 
uma unidade lógica de processamento. Vamos aprender, então, que essa unidade de processamento é denominada 
transação. 
Em sistemas de banco de dados, uma transação corresponde a um programa em execução que forma uma 
unidade de trabalho. 
Os limites de uma transação são especificados por meio dos comandos begin transaction (que indica 
o início de uma transação) e end transaction (que indica o término de uma transação) em um programa de 
aplicação. 
Ainda, se a transação não atualiza o banco de dados, é denominada somente de leitura; caso 
contrário, é chamada de leitura-gravação. 
Para fins didáticos, um modelo simplificado do banco de dados - coleção de itens nomeados - é 
usado para estudo dos conceitos de processamento de transações. Cada item de dados pode representar 
um registro, bloco ou valor de coluna. 
Em se tratando de SGBDs multiusuários, várias transações podem ser executadas simultaneamente. 
No entanto, caso essa execução ocorra de maneira descontrolada, poderão surgir problemas de 
inconsistências, tais como: 
Atualização perdida 
Quando duas transações que acessam os mesmos itens de dados têm operações intercaladas de modo a 
tornar incorretos alguns itens do banco de dados. 
Atualização temporária 
Quando uma transação atualiza um item do banco de dados e, depois, falha por algum motivo, enquanto, nesse 
meio tempo, o item é lido por outra transação antes de ser alterado de volta para seu valor original. 
Resumo incorreto 
Quando uma transação calcula uma função de resumo de agregação em uma série de itens enquanto outras 
transações atualizam alguns desses itens. 
Leitura não repetitiva 
Quando uma transação lê o mesmo item duas vezes e o item é alterado por outra transação entre as duas 
leituras. 
É importante sabermos que, quando o SGBD processa uma transação, todas as operações que a 
formam devem ser completadas com sucesso para, somente depois, haver a gravação permanente das 
alterações no banco de dados. Além disso, caso haja falha em uma ou mais operações de uma transação, 
as demais operações não devem ser executadas, e a transação deve ser cancelada. 
Se uma transação for cancelada, deve ser executado um processo denominado rollback, o qual 
força o SGBD a trazer de volta os valores antigos dos registros antes da transação ter iniciado. Finalmente, 
caso a transação seja executada com sucesso, as atualizações devem ser confirmadas por meio do 
comando commit. 
Estas são as falhas que podem ocorrer durante o processamento de uma transação: 
1. Falha do computador 
2. Erro de transação ou sistema 
3. Condições de exceção detectadas pela transação 
4. Falha de disco, problemas físicos e catástrofes 
Sistema de Banco de Dados 
Marcio Quirino - 115 
 
A seguir, conheceremos as propriedades das transações. 
Propriedades de uma transação 
Com objetivo de garantir a integridade dos dados contidos no banco de dados, o SGBD mantém um 
conjunto de propriedades das transações, denominado ACID, que representam as características de 
atomicidade, consistência, isolamento e durabilidade, respectivamente. 
Atomicidade 
A transação precisa ser realizada completamente ou não realizada. 
Consistência 
A transação deve levar o banco de dados de um estado consistente para outro. 
Isolamento 
A execução de uma transação não deve ser interferida por quaisquer outras transações. 
Durabilidade 
As mudanças no banco de dados em função da confirmação da transação devem persistir. 
Estados de uma transação 
Uma transação pode passar pelos seguintes estados ao longo do seu processamento: 
Ativo 
Ocorre imediatamente após o início da transação, podendo executar operações de leitura e gravação. 
Parcialmente confirmado 
Quando a transação termina. 
Confirmado 
Após verificação bem-sucedida, as mudanças são gravadas permanentemente no banco de dados. 
Falha 
Se uma das verificações falhar ou se a transação for abortada durante seu estado ativo. 
Confirmado 
Transação sai do sistema. 
Para poder recuperar-se de falhas que afetam transações, normalmente, o SGBD mantém um log 
para registrar todas as operações de transação que afetam os vários itens do banco de dados. As entradas 
em um registro de log de uma determinada transação possuem informações de valores antigos e novos do 
item de dados do banco de dados, bem como se a transação foi concluída com sucesso ou se foi abortada. 
Transações no PostgreSQL 
De maneira geral, uma transação no PostgreSQL possui a estrutura a seguir: 
BEGIN-- início da transação 
-- comandos 
COMMIT-- transação confirmada 
ROLLBACK-- transação cancelada 
END-- mesma função do COMMIT 
No entanto, nos SGBDs, a inicialização de uma transação ocorre implicitamente quando executamos 
alguns comandos. 
Vamos estudar um exemplo? 
 
 
 
Sistema de Banco de Dados 
Marcio Quirino - 116 
 
Seja a tabela CURSO, conforme a seguir: 
 
A execução de um INSERT na tabela ocorre dentro do contexto implícito de uma transação: 
-- BEGIN implícito 
INSERT INTO CURSO (CODIGOCURSO,NOME,DATACRIACAO) VALUES (5,'Engenharia de Computação',NULL); 
-- COMMIT implícito 
Estudamos que, quando uma transação é desfeita, qualquer operação que faz parte da transação 
deve ser cancelada. Vamos, então, ver como podemos fazer isso no PostgreSQL. Veja o exemplo a seguir, 
construído com objetivo de inserir um registro na tabela CURSO e, em seguida, indicar que a operação de 
inserção ser desfeita pelo SGBD: 
 
Após o processamento do comando da linha 1, visualizaremos o conteúdo da tabela CURSO da 
seguinte maneira: 
 
Tabela CURSO após a execução do comando da linha 1. 
Após o processamento dos comandos da linha 2 à linha 4, que já representam a inserção de um 
registro na tabela CURSO sob o contexto de uma transação explícita, teremos este resultado: 
 
Tabela CURSO após a execução do comando da linha 4. 
Finalmente, após o processamento dos comandos da linha 5 à linha 7, onde a transação é desfeita, 
teremos o resultado conforme a tabela a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 117 
 
 
Tabela CURSO após a execução do comando da linha 7. 
Perceba que o comando da linha 2 (BEGIN) iniciou explicitamente uma transação, a qual foi abortada 
quando da execução do comando da linha 5 (ROLLBACK). 
Atenção 
No exemplo anterior, programamos uma transação que envolveu somente uma operação, a saber, inserção de 
uma linha na tabela CURSO. No entanto, uma transação pode envolver diversas linhas de uma tabela do banco de 
dados. 
Vamos, então, programar uma transação que consistirá em duas operações de atualização 
envolvendo a tabela que contém as disciplinas, apresentada conforme a seguir: 
 
Inicialmente, vamos listar o conteúdo da tabela DISCIPLINA. Podemos, então, usar o comando a 
seguir: 
SELECT * FROM DISCIPLINA; 
Após o processamentodo comando, teremos o seguinte resultado: 
 
Conteúdo da tabela DISCIPLINA com os dados originais. 
Agora, nossa intenção é alterar a carga horária das disciplinas de acordo com os critérios a seguir: 
• Disciplinas que possuem 60 horas: aumento em 20% 
• Disciplinas que possuam 40 horas: aumento em 10% 
O código a seguir expressa uma transação envolvendo operações de atualização de dados na tabela 
DISCIPLINA: 
Sistema de Banco de Dados 
Marcio Quirino - 118 
 
 
Após a execução do trecho entre as linhas 1 e 3, o conteúdo da tabela disciplina estará conforme a 
seguir: 
 
Conteúdo da tabela DISCIPLINA após a execução da linha 3. 
Após a execução da transação, o conteúdo da tabela disciplina estará conforme a seguir: 
 
Conteúdo da tabela DISCIPLINA após o término da transação. 
Outro ponto interessante no projeto de transações é a utilização de pontos de salvamento 
(SAVEPOINT). Observe o exemplo a seguir: 
 
Na linha 4, adicionamos um SAVEPOINT denominado CARGA60. Quando a linha 6 for executada, 
o SGBD vai desfazer a operação de UPDATE da linha 5. 
Um pouco mais sobre atualização temporária 
Estudamos que uma transação não deve atrapalhar o andamento de outra. Pense na execução da 
nossa última transação, que envolveu dois comandos de atualização na tabela DISCIPLINA. 
Vimos que, logo após a execução da linha 3, a única disciplina que não sofreu alteração foi a de 
Computação Gráfica. Perceba que o SELECT da linha 3 está sendo executado no contexto da transação. 
No entanto, o que aconteceria se tivéssemos em paralelo outra aplicação que submetesse consulta 
para acessar os registros da tabela DISCIPLINA no mesmo momento da execução da linha 3 da transação? 
 
Sistema de Banco de Dados 
Marcio Quirino - 119 
 
Resposta 
A consulta em questão enxergaria os dados “originais”, sem quaisquer alterações. Por qual razão? Para não 
haver o problema da atualização temporária. Queremos dizer que, se a transação fosse desfeita por qualquer motivo, 
o UPDATE da linha 2 seria também desfeito. 
UM POUCO MAIS SOBRE TRANSAÇÃO DE LEITURA 
Vimos que uma transação que não modifica dados é denominada transação somente de leitura 
(READ ONLY). Caso contrário, é denominada leitura-gravação (READ WRITE). 
Para especificar o tipo de transação, usaremos o comando SET TRANSACTION 
<TIPOTRANSAÇÃO>. No PostgreSQL, quando iniciamos uma transação, o padrão é READ WRITE. 
Vamos analisar um exemplo envolvendo uma transação READ ONLY: 
 
Na transação acima, propositalmente, inserimos um comando de atualização em uma transação que 
não permite essa categoria de comando. Logo, após a execução da linha 3, o SGBD retornará uma 
mensagem informando ao usuário que não é possível executar comando de atualização em uma transação 
do tipo somente leitura. 
Ao longo deste módulo, aprendemos o conceito de transação, que representa uma sequência de 
comandos que devem ser executados na totalidade, ou, caso contrário, desfeitos. 
Vimos que, por padrão, o SGBD PostgreSQL implicitamente gera uma transação quando 
submetemos algum comando de inserção, atualização ou remoção de dados. Por fim, aprendemos 
comandos para gerenciar transações no PostgreSQL. 
Verificando o aprendizado 
1. A respeito de transações no PostgreSQL e, considerando o modelo a seguir, assinale a 
proposição verdadeira: 
 
O comando DELETE FROM CURSODISCIPLINA(; pode ser executado sem erro em uma 
transação PostgreSQL do tipo READ WRITE. 
De fato, se uma transação no PostgreSQL é definida como READ WRITE, ela aceita comandos 
de inserção, atualização e remoção de dados. Logo, a instrução que contém o comando DELETE 
poderá ser executada sem erro. 
2. Suponha que um profissional programou no PostgreSQL os seguintes comandos em uma 
tabela denominada empregado: 
 
Sistema de Banco de Dados 
Marcio Quirino - 120 
 
Suponha também que, após a execução da linha 2, o profissional percebeu que não deveria 
ter aumentado o salário de Maria nesse valor. Qual comando é adequado adicionar à linha 
3 para desfazer essa operação? 
ROLLBACK; 
De fato, como a transação não foi concluída, é possível desfazer a operação da linha 2, bastando 
para isso adicionar o comando ROLLBACK. Após isso, a tabela funcionário ficará com os 
registros iguais à situação imediatamente anterior à execução da transação. 
Considerações finais 
Ao longo do nosso estudo, fizemos uma introdução aos recursos do SGBD PostgreSQL, envolvendo 
características desse SGBD, bem como sua instalação. 
Foram apresentados comandos, classificados como DDL, para a criação e a alteração de tabelas. 
Em seguida, conhecemos diversos comandos SQL para manipulação de linhas em tabelas. Tais comandos, 
classificados como DML, são úteis para inserção, alteração e remoção de dados. 
Finalizamos com uma breve contextualização a respeito do conceito, uso e importância das 
transações, com destaque aos comandos do PostgreSQL utilizados para esse fim. 
Referências 
DBEAVER COMMUNITY. Consultado em meio eletrônico em: 30 mai. 2020. 
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7. ed. São Paulo: Pearson, 2019. 
MANZANO, J.A.M.G., Microsoft SQL Server 2016 Express Edition Interativo. 1. ed. São Paulo: 
Saraiva, 2017. 
POSTGRESQL. PostgreSQL 12.3 Documentation. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Create Table. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Data Type. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Delete. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Download. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Insert. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Ubuntu. Consultado em meio eletrônico em: 30 mai. 2020. 
POSTGRESQL. Update. Consultado em meio eletrônico em: 30 mai. 2020. 
Explore+ 
Para aprofundar seus conhecimentos sobre o assunto deste tema, leia: 
CHAMBERLIN, D. D. Early History of SQL In: IEEE Annals of the History of Computing n 4, 2012. 
Como vimos, a linguagem SQL tornou-se um padrão para uso em sistemas gerenciadores de bancos de 
dados relacionais. O artigo indicado é um interessante material sobre a história da SQL. 
 
Sistema de Banco de Dados 
Marcio Quirino - 121 
 
Consultas em uma tabela no PostgreSQL 
Definição 
Consultas com expressões no comando SELECT. Consultas com o uso da cláusula WHERE. 
Agrupamento de dados. 
Propósito 
Saber construir comandos SQL com o uso de expressões no comando SELECT, bem como a 
especificação de condições na cláusula WHERE, que representam tarefas importantes no projeto de 
consultas em sistemas gerenciadores de banco de dados (SGBD). Para o desenvolvimento de relatórios e 
consultas analíticas, é fundamental saber trabalhar com agrupamento de dados. Essas atividades são 
relacionadas ao dia a dia de programadores, analistas de sistemas e desenvolvedores. 
Preparação 
Antes de iniciar o conteúdo deste tema, certifique-se de ter baixado e instalado o SGBD PostgreSQL 
em seu computador. 
Introdução 
Ao longo deste tema, vamos explorar diversos exemplos de consultas envolvendo uma tabela. 
Aprenderemos a codificar consultas abrangendo tanto a recuperação de colunas da própria tabela quanto o 
uso de expressões no comando SELECT. Quando projetamos um banco de dados para determinado 
domínio de negócio, em geral, são criadas diversas tabelas que serão manipuladas pelas aplicações 
desenvolvidas para acessar os recursos do banco de dados. 
Diversas operações que manipulam tabelas em um banco de dados necessariamente estão 
associadas a alguma operação de consulta. Por exemplo, se resolvermos aumentar em 10% o salário de 
todos os funcionários que ganham até R$ 4.000, será necessário programarmos um comando de consulta 
para que o sistema gerenciador de banco de dados (SGBD) selecione os registros dos funcionários alvo da 
atualização. Assim, aprender de maneira efetiva a programar consultas trará benefícios, tanto para 
atividadesde construção de relatórios, quanto para o projeto de operações de remoção e atualização de 
dados. 
1. Consultas com o comando SELECT 
Estrutura básica de um comando SELECT 
O comando SELECT é usado para exibir dados resultantes de uma consulta. Os dados podem ser 
colunas físicas de uma tabela, colunas calculadas ou mesmo resultado do uso de expressões e funções. 
Uma sintaxe básica para o comando SELECT está expressa a seguir: 
SELECT COLUNA1 [[AS] APELIDOCOLUNA1], 
COLUNA2 [[AS] APELIDOCOLUNA2], 
… 
COLUNAN [[AS] APELIDOCOLUNAN] 
FROM TABELA; 
É importante ressaltar que estamos diante de uma sintaxe simplificada o suficiente para 
entendimento dos exemplos que iremos explorar ao longo do módulo. A sintaxe completa abrange todos os 
recursos do PostgreSQL. 
Uma sintaxe complexa envolve uma série de cláusulas e recursos bastante úteis para consultas de 
maior complexidade. 
Sistema de Banco de Dados 
Marcio Quirino - 122 
 
Na prática, o comando SELECT, dependendo da consulta desejada, pode ser usado de diferentes 
formas para obter o mesmo resultado. É importante frisar que a cláusula SELECT realiza a operação de 
projeção da Álgebra Relacional. 
Caso haja interesse em exibir todas as colunas especificadas em uma consulta, basta adicionar um 
“*”, conforme a seguir: SELECT * FROM TABELA; 
Você sabia 
Alguns SGBDs, como o PostgreSQL, implementam uma forma simplificada do comando SELECT * FROM 
TABELA, que é simplesmente TABLE tabela (você pode testar isso no PostgreSQL). 
Vamos estudar alguns exemplos? 
Construiremos as consultas com base na tabela ALUNO, conforme figura a seguir: 
 
Recomendamos que você crie a tabela e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. 
Para isso, tenha em mente que é necessário estar conectado ao PostgreSQL e acessando algum 
database criado por você. 
 
Vamos ver alguns exemplos de consultas? 
Consulta 01 
Exibir todas as informações dos alunos. 
SELECT * FROM ALUNO; 
A tabela a seguir apresenta os resultados da consulta. 
 
Resultados da consulta 01. 
Ao executar a consulta, o SGBD percorre todos os registros da tabela ALUNO e exibe as colunas 
dessa tabela. 
 
Sistema de Banco de Dados 
Marcio Quirino - 123 
 
Consulta 02 
Retornar o código, o nome e a data de nascimento de todos os alunos. 
SELECT CODIGOALUNO, NOME, DTNASCIMENTO 
FROM ALUNO; 
 
Resultados da consulta 02. 
Na consulta 02, foram especificadas três colunas da tabela ALUNO para serem exibidas ao usuário. 
Em especial, pode ser interessante “renomear” as colunas resultantes da consulta, visando tornar os 
resultados mais “apresentáveis” ao usuário da aplicação. Por exemplo, a consulta 02 pode ser reescrita 
conforme a seguir: 
SELECT CODIGOALUNO AS "Matrícula", 
NOME AS "Nome do discente", 
DTNASCIMENTO AS "Data de nascimento" 
FROM ALUNO; 
O resultado dessa consulta seria este: 
 
Resultados da segunda versão da consulta 02. 
É importante ressaltar que, na tabela anterior, o nome apresentado para cada coluna não existe 
fisicamente no banco de dados. 
Vamos aprender a seguir que nem toda coluna resultante de uma consulta representa 
necessariamente uma coluna de alguma tabela. 
Funções de data e hora 
Quando desenvolvemos consultas, é comum manipularmos colunas e funções que envolvem dados 
representativos de datas. 
Sistema de Banco de Dados 
Marcio Quirino - 124 
 
 
Um quadro completo contendo informações sobre funções de data e hora pode ser encontrado na 
documentação oficial do PostgreSQL. 
Vamos estudar alguns exemplos? 
Observe com atenção o código: 
 
Agora veja na tabela a seguir os resultados da consulta: 
 
Resultados da consulta envolvendo funções de data e hora. 
Observe que utilizamos o qualificador AS “Apelido” para facilitar o entendimento do retorno de cada 
função. Note também que não há cláusula FROM na consulta, visto que todas as colunas retornadas 
representam o resultado de funções do PostgreSQL sem envolver qualquer tabela do domínio da aplicação. 
Atenção 
Convém ressaltar que, no padrão SQL, a cláusula FROM é obrigatória. No entanto, o PostgreSQL permite 
executar um comando SELECT sem a cláusula FROM. Experimente executar SELECT 5+5; 
Exibindo o nome do dia da semana 
Perceba que a linha 6 do código acima retorna um inteiro representativo do dia da semana. No 
entanto, se houver necessidade de exibir o dia da semana, você pode usar o código a seguir: 
 
Sistema de Banco de Dados 
Marcio Quirino - 125 
 
Observe que construímos uma lógica utilizando o comando CASE, que é equivalente ao comando 
IF:, cada linha com a cláusula WHEN avalia expressão que retorna um inteiro representativo do dia da 
semana, caso a expressão tenha valor lógico verdadeiro. 
Calculando idade e faixa etária 
Em geral, quando estamos diante de alguma coluna representativa da data de nascimento de uma 
pessoa, é comum extrair informações derivadas, tais como idade e faixa etária. Por exemplo, o código a 
seguir retorna o nome, a data de nascimento e a idade dos alunos: 
 
Perceba que na linha 3 utilizamos a função AGE, que retorna uma frase representativa da informação 
sobre a idade em questão. Na linha 4, usamos a função EXTRACT para exibir a idade do aluno. A figura a 
seguir apresenta o resultado dessa consulta: 
 
Exibindo a idade dos alunos. 
Muito bem, agora, vamos exibir o nome, a idade e a faixa etária dos alunos. 
Observe o código SQL a seguir: 
 
Perceba que cada linha com a cláusula WHEN avalia a expressão que retorna uma faixa etária de 
acordo com a idade do aluno. 
A seguir, o resultado da consulta: 
 
Resultados da consulta envolvendo idade e faixa etária dos alunos. 
Funções de resumo ou de agregação 
As funções a seguir são úteis para obtermos resumo dos dados de alguma tabela: 
Sistema de Banco de Dados 
Marcio Quirino - 126 
 
Função O que retorna? 
COUNT(*) número de linhas da consulta 
MIN(COLUNA/EXPRESSÃO) menor de uma coluna ou expressão 
AVG(COLUNA/EXPRESSÃO) valor médio da coluna ou expressão 
MAX(COLUNA/EXPRESSÃO) maior valor de uma coluna ou expressão 
SUM(COLUNA/EXPRESSÃO) soma dos valores de uma coluna ou expressão 
STDDEV(COLUNA/EXPRESSÃO) desvio padrão dos valores de uma coluna ou expressão 
VARIANCE(COLUNA/EXPRESSÃO) variância dos valores de uma coluna ou expressão 
Vamos estudar um exemplo? 
Observe o código a seguir: 
 
Perceba que, como estamos usando somente o comando SELECT/FROM, cada função é calculada 
levando em consideração todos os registros da tabela. 
Veja na figura a seguir, o resultado da consulta: 
 
Resultado da consulta envolvendo funções para extrair resumo a partir da tabela aluno. 
Atenção 
Perceba, também, que o código da linha 6 é equivalente ao da linha 4: ambos calculam a idade média dos 
alunos. 
Listando resumos em uma linha 
Suponha que haja interesse em conhecer os quantitativos de cursos, disciplinas e alunos do nosso 
banco de dados. 
Poderíamos submeter ao SGBD as consultas a seguir: 
A. Curso 
SELECT COUNT(*) NCURSOS FROM CURSO; 
B. Disciplina 
SELECT COUNT(*) NDISCIPINAS FROM DISCIPLINA; 
C. Aluno 
SELECT COUNT(*) NALUNOS FROM ALUNO; 
Estamos diante de três consultas. No entanto, pode ser mais interessante mostrarmos os resultados 
em apenas uma linha. 
Podemos, então, submeter o código a seguir: 
O que fizemos? 
Como cada consulta (linhas 2 a 4) retorna somente um valor, utilizamos um SELECT externo (linha 
1) para exibir cada coluna resultante. 
Observe o resultado a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 127 
 
 
Resultado da consulta envolvendo quantitativos de cursos, alunos e disciplinas. 
Convém ressaltar que o comando é válido, visto que, no PostgreSQL, a cláusula FROM não é 
obrigatória. 
Criando tabela a partir de consulta 
Em alguns momentos, você terá interesse em salvar os resultados de uma consulta em uma nova 
tabela. 
Para isso, basta usar o comando CREATE TABLE<CONSULTA>. 
 
No exemplo apresentado, o SGBD criará uma tabela denominada TTESTE e armazenará os dados 
resultantes da consulta (linhas 2 a 11) em questão. 
Criando view a partir de consulta 
Outro recurso interessante, diretamente relacionado ao processo de construção de consultas, é o 
objeto view (visão). Uma view encapsula a complexidade da consulta SQL, que a forma. Para criar esse 
objeto, usa-se o comando CREATE VIEW <CONSULTA>. 
 
No exemplo, o SGBD criará uma view denominada VTESTE. Na prática, quando usuário submeter, 
por exemplo, a consulta SELECT * FROM VTESTE, o SGBD executará o código associado à view em 
questão. 
Atenção: Antes de assistir o vídeo a seguir realizar o download do arquivo EMPRESA.SQL e criar o 
banco de dados utilizando o PGADMIN. 
Ao longo da nossa jornada, estudamos a construção de consultas envolvendo a extração de 
informação a partir de uma tabela. Além disso, foram exibidas funções de data e funções para resumir dados 
de uma tabela. 
Agora é com você! Vamos realizar as atividades a seguir? 
Sistema de Banco de Dados 
Marcio Quirino - 128 
 
Verificando o aprendizado 
1. Considere a tabela e o código SQL a seguir: 
 
Analise as seguintes proposições: 
I - A consulta retorna informações sobre cinco colunas existentes na tabela ALUNO. 
II - A consulta retorna informações sobre todos os alunos cadastrados. 
III - Pode existir registro com valor “Masculino” armazenado na coluna SEXO. 
IV - O resultado de CURRENT_DATE (linha 1) está armazenado em uma coluna da tabela 
ALUNO. 
V - A consulta retorna informações sobre quatro colunas existentes na tabela ALUNO. 
 
São proposições verdadeiras: 
II e V. 
A proposição II é verdadeira, pois não há condição de filtro na consulta. A proposição V é 
verdadeira, pois retorna informações a respeito de todas as colunas da tabela ALUNO. As 
demais proposições são falsas. 
2. Seja uma tabela assim definida: FUNCIONARIO (IDFUNC, NOME, DATANASCIMENTO, 
SALARIO). Qual consulta SQL retorna o maior salário? 
SELECT MAX(SALARIO) FROM FUNCIONARIO. 
2. Consultas usando a cláusula WHERE 
Cláusula Where e operadores da SQL 
Em nossas consultas, usaremos como base a tabela ALUNO, conforme figura a seguir: 
 
Recomendamos que você crie a tabela e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar 
conectado ao PostgreSQL e acessando algum database criado por você. 
Sistema de Banco de Dados 
Marcio Quirino - 129 
 
 
Recuperando dados com Select/From/Where/Order By 
Uma sintaxe básica para o comando SELECT, com o uso das cláusulas WHERE e ORDER BY, está 
expressa a seguir: 
SELECT COLUNA1 [[AS] APELIDOCOLUNA1], 
COLUNA2 [[AS] APELIDOCOLUNA2], 
… 
COLUNAN [[AS] APELIDOCOLUNAN] 
FROM TABELA 
WHERE <CONDIÇÃO> 
ORDER BY EXPRESSÃO1[ASC|DESC] [NULLS {FIRST|LAST}], [EXPRESSÃO2[ASC|DESC] [NULLS 
{FIRST|LAST}…]; 
O propósito do SELECT é declararmos as colunas da consulta. No FROM, informamos a tabela alvo 
da consulta. No WHERE, especificamos alguma condição, simples ou composta, para filtrar registros que 
serão recuperados pelo SGBD. No ORDER BY, declaramos uma ou mais colunas como critério de 
ordenação, com possibilidade de especificarmos se valores NULL aparecem no início ou no final do 
resultado. 
É importante frisar que a cláusula WHERE realiza a operação de restrição da Álgebra Relacional, 
também conhecida como seleção – não confundir com o comando SELECT. 
Ainda, a construção de uma condição na cláusula WHERE envolve operadores relacionais, conforme 
tabela a seguir: 
Operador Significado 
< menor 
<= menor ou igual a 
> maior 
>= maior ou igual a 
= igual 
<> ou != > diferente 
Além dos operadores relacionais, a construção de uma condição na cláusula WHERE pode fazer uso 
dos seguintes operadores lógicos: 
Operador Significado 
AND conjunção 
OR disjunção 
NOT negação 
Vamos estudar alguns exemplos de consultas com o uso da cláusula WHERE? 
CONSULTA 01 + RESULTADO 
Mostrar o nome e a data de nascimento das professoras. 
 
Sistema de Banco de Dados 
Marcio Quirino - 130 
 
 
Resultado consulta 01. 
Perceba que foi criada uma condição simples de igualdade envolvendo a coluna SEXO da tabela 
ALUNO. O SGBD percorre cada registro da tabela ALUNO, avalia a condição (linha 3) e exibe as colunas 
NOME e DTNASCIMENTO para cada registro cuja avaliação da condição retorne verdadeiro. 
CONSULTA 02 + RESULTADO 
Mostrar o nome e a data de nascimento das professoras que fazem aniversário em novembro. 
 
 
Resultado consulta 02. 
Perceba que foi criada uma condição composta envolvendo uma conjunção. O SGBD retornará os 
registros que possuem o valor “F” para a coluna SEXO e o inteiro 11 como valor do mês referente à data de 
nascimento. 
Recuperando dados com o uso do operador IN 
O operador [NOT] IN pode ser utilizado em consultas que envolvam comparações usando uma lista 
de valores. 
CONSULTA 03 + RESULTADO 
Listar o nome dos alunos que fazem aniversário no segundo semestre. 
 
 
Resultado consulta 03. 
Note que a expressão na cláusula WHERE compara o mês de nascimento de cada aluno junto aos 
valores da lista contendo os inteiros correspondentes aos meses do segundo semestre. 
Recuperando dados com o uso do operador Between 
O operador [NOT] BETWEEN verifica se determinado valor encontra-se no intervalo entre dois 
valores. 
Sistema de Banco de Dados 
Marcio Quirino - 131 
 
Por exemplo, X BETWEEN Y AND Z é equivalente a X>=Y AND X<=Z. De modo semelhante, X NOT 
BETWEEN Y AND Z é equivalente a X<Y OR X>Z. 
CONSULTA 04 + RESULTADO 
Listar o nome dos alunos nascidos entre 1985 e 2005. 
 
 
Resultado consulta 04. 
Note que a expressão na cláusula WHERE compara o ano de nascimento de cada aluno junto ao 
intervalo especificado pelo operador BETWEEN. Caso quiséssemos extrair o mesmo resultado sem o uso 
do BETWEEN, poderíamos programar um comando equivalente, conforme a seguir: 
 
Recuperando dados com o uso do operador Like 
O uso do [NOT] LIKE permite realizar buscas em uma cadeia de caracteres. 
Trata-se de um recurso bastante utilizado em buscas textuais. Você pode utilizar os símbolos 
especiais a seguir: 
• _ para ignorar qualquer caractere específico; 
• % para ignorar qualquer padrão. 
Vamos estudar alguns exemplos? 
CONSULTA 05 + RESULTADO 
Listar o nome dos alunos que possuem a string COSTA em qualquer parte do nome. 
 
 
Resultado consulta 05. 
Saiba mais 
O uso do padrão ‘%COSTA%’ significa que não importa o conteúdo localizado antes e depois da string 
“COSTA”. 
CONSULTA 06 + RESULTADO 
Listar o nome dos alunos que possuem a letra “A” na segunda posição do nome. 
Sistema de Banco de Dados 
Marcio Quirino - 132 
 
 
 
Resultado consulta 06. 
Note que, para especificar o “A” na segunda posição, o SGBD desprezará qualquer valor na primeira 
posição da string, não importando o que estiver localizado à direita do “A”. 
CONSULTA 07 + RESULTADO 
Listar o nome e a data de nascimento dos alunos que não possuem a string “MARIA” fazendo parte do nome. 
 
 
Resultado consulta 07. 
Estamos diante de um caso semelhante ao da consulta 05. 
No entanto, utilizamos o operador de negação para retornar os registros de interesse. 
CONSULTA 08 + RESULTADO 
Quantos alunos possuem conta de e-mail no gmail? 
 
 
Resultado consulta 08. 
Note que, mais uma vez, estamos diante de um caso semelhante ao da consulta 05. Buscamos pela 
string “@GMAIL. ” em qualquer posição da coluna EMAIL. 
Recuperando dados com o uso do operador NULL 
Quando uma coluna é opcional, significa que existe possibilidade de que algum registro não possua 
valor cadastrado para a coluna em questão. Nessa hipótese, há entendimento de que o valor da coluna é 
“desconhecido” ou “não aplicável”. 
Para testar se uma coluna possui valor cadastrado, usa-se a expressão COLUNA IS NOT NULL. 
Vamos estudar algunsexemplos? 
CONSULTA 09 + RESULTADO 
Listar o nome, a data de nascimento e o e-mail dos alunos que têm endereço eletrônico cadastrado. 
Sistema de Banco de Dados 
Marcio Quirino - 133 
 
 
 
Resultado consulta 09. 
O SGBD retorna os registros onde há algum conteúdo cadastrado na coluna EMAIL. 
CONSULTA 10 + RESULTADO 
Retornar o nome dos alunos sem e-mail cadastrado no banco de dados. 
 
 
Resultado consulta 10. 
O SGBD retorna os registros sobre os quais não há valor cadastrado na coluna EMAIL. 
Recuperando dados usando ordenação dos resultados 
Para melhor organizar os resultados de uma consulta, nós podemos especificar critérios de 
ordenação. Vejamos alguns exemplos: 
CONSULTA 11 + RESULTADO 
Retornar o nome e a data de nascimento dos alunos, ordenando os resultados por nome, de maneira 
ascendente. 
 
 
Resultado consulta 11. 
O SGBD retorna os registros da tabela ALUNO, obedecendo ao critério de ordenação especificado 
na linha 3 da consulta. O padrão ascendente (ASC) é opcional. 
CONSULTA 12 + RESULTADO 
Retornar o nome e a data de nascimento dos alunos, ordenando os resultados de modo ascendente pelo mês 
de nascimento e, em seguida, pelo nome, também de modo ascendente. 
 
Sistema de Banco de Dados 
Marcio Quirino - 134 
 
 
Resultado consulta 12. 
O SGBD retorna os registros da tabela ALUNO, levando em conta o critério de ordenação 
especificado na linha 3 da consulta. Foi realizada ordenação pelo mês de nascimento; em seguida, pelo 
nome. 
Trabalhamos o uso de consultas com auxílio da cláusula WHERE, fazendo uso de operadores 
relacionais e lógicos na composição de condições lógicas. Além disso, estudamos como estabelecer critérios 
para ordenação dos resultados de consultas. 
Agora é com você! Vamos realizar as atividades a seguir? 
Verificando o aprendizado 
1. Gabriel é analista de sistemas de uma empresa de tecnologia de informação e recebeu a 
tarefa de recuperar todos os registros da tabela CLIENTE onde o valor da coluna 
“NOMECLIENTE” contenha a cadeia “da Silva” em qualquer parte do nome. Assinale a 
alternativa correta que permita a Gabriel executar sua tarefa. 
SELECT * FROM CLIENTE WHERE NOMECLIENTE LIKE '%da Silva% '. 
Para recuperar os registros que contenham “da Silva” em qualquer parte do nome, utiliza-se o 
comando LIKE com auxílio do “%” como forma do SGBD desconsiderar qualquer padrão à 
esquerda e à direita da string de interesse. 
2. Um programador recuperou os dados dos bairros Penha, Ipanema, Flamengo e Centro 
gravados na coluna BAIRRO da tabela CLIENTE, a seguir especificada. 
CLIENTE (IDCLIENTE, NOME, ENDERECO, BAIRRO, CIDADE, UF, CEP) 
A sintaxe SQL correta usada por ele para realizar essa atividade foi SELECT * FROM 
CLIENTE 
WHERE BAIRRO IN ('Penha ', 'Ipanema ', 'Flamengo ', 'Centro'). 
Para recuperar os registros de interesse, foi utilizado o operador IN com o uso de uma lista 
contendo os bairros em questão. O SGBD compara o bairro do cliente junto aos elementos 
especificados na lista de bairros em questão. 
3. Consultas envolvendo agrupamento de dados 
Consultas com GROUP BY e HAVING 
Em nossas consultas, usaremos como base a tabela FUNCIONARIO, conforme figura a seguir: 
 
Sistema de Banco de Dados 
Marcio Quirino - 135 
 
Recomendamos que você crie a tabela e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar 
conectado ao PostgreSQL e acessando algum database criado por você. 
 
Após a criação da tabela e a inserção dos registros, podemos utilizar o código a seguir para exibir 
todo o seu conteúdo: 
 
O resultado da consulta será semelhante a este: 
 
Registros da tabela FUNCIONARIO. 
Grupo de dados 
Nas próximas seções, vamos aprender a projetar consultas com o uso de agrupamento de dados, 
com auxílio dos comandos GROUP BY e HAVING. 
Vamos perceber que a maior parte dessas consultas está atrelada ao uso de alguma função de 
resumo, por exemplo, SUM, AVG, MIN e MAX, as quais representam, respectivamente, soma, média, 
mínimo e máximo. 
Logo, essas consultas são úteis para quem tem interesse em construir relatórios e aplicações de 
natureza mais gerencial e analítica. Os valores de determinada coluna podem formar grupos sobre os quais 
podemos ter interesse em recuperar dados. 
Por exemplo, se avaliarmos o resultado da consulta anterior, podemos naturalmente dividir os 
registros de acordo com o valor da coluna sexo. Teríamos, então, uma estrutura conforme a seguir: 
M {4,5} {MARCOS PEREIRA BRASIL, HEMERSON SILVA BRASIL} {…} 
F {1,2,3} {ROBERTA SILVA BRASIL, MARIA SILVA BRASIL, GABRIELLA PEREIRA LIMA} {…} 
Saiba mais 
Todas as linhas com o mesmo valor para a coluna sexo formam um grupo. Representamos as linhas com mais 
de um valor com o uso de chaves para fins ilustrativos, dado que estamos diante de linhas dentro de colunas, uma 
representação que não existe no modelo relacional. 
A estrutura anterior possui somente um grupo, o qual é formado pela coluna SEXO da tabela 
FUNCIONARIO. Como exibir esse grupo em SQL? 
Uma solução é adicionar a cláusula DISTINCT ao comando SELECT, conforme a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 136 
 
 
O resultado da consulta anterior pode ser visualizado na figura a seguir: 
 
Grupo de dados baseado na coluna SEXO da tabela FUNCIONARIO. 
Vamos perceber que em SQL a cláusula mais adequada para trabalhar com agrupamento de dados 
é o GROUP BY. 
Grupo de dados com GROUP BY 
A cláusula GROUP BY serve para exibir resultados de consulta de acordo com um grupo 
especificado. Ela é declarada após a cláusula FROM, ou após a cláusula WHERE, caso exista na consulta. 
Por exemplo, para obter o mesmo resultado do comando anterior, podemos usar o código a seguir: 
 
No entanto, vamos perceber que o uso mais conhecido da cláusula GROUP BY ocorre quando 
associada a funções de agregação, tais como COUNT, MIN, MAX e AVG. 
Uma tabela com o nome e o significado dessas funções foi apresentada na seção “Funções de 
resumo ou agregação” no módulo 1. 
Vamos estudar alguns exemplos? 
CONSULTA 01 + RESULTADO 
Retornar o número de funcionários por sexo. 
 
 
Resultado consulta 01. 
O SGBD realiza o agrupamento de dados de acordo com os valores da coluna SEXO. Em seguida, 
para cada grupo encontrado, a função COUNT(*) é executada e o resultado exibido. 
E se tivéssemos interesse em exibir os resultados da consulta anterior em uma única linha? 
Poderíamos usar o código a seguir: 
 
Sistema de Banco de Dados 
Marcio Quirino - 137 
 
 
Número de funcionários por sexo: informações exibidas em uma única linha. 
CONSULTA 02 + RESULTADO 
Retornar a média salarial por sexo. 
 
 
Resultado consulta 02. 
O SGBD realiza o agrupamento de dados de acordo com os valores da coluna SEXO. Em seguida, 
para cada grupo encontrado, a função AVG (SALARIO) é executada; e o resultado, exibido. 
CONSULTA 03 + RESULTADO 
Retornar, por mês de aniversário, a quantidade de colaboradores, o menor salário, o maior salário e o salário 
médio. Ordene os resultados por mês de aniversário. 
 
 
Resultado consulta 03. 
O SGBD realiza o agrupamento de dados de acordo com o mês de nascimento dos funcionários. 
Depois, para cada grupo encontrado, as funções de agregação são executadas e, em seguida, exibidos os 
resultados. Perceba também que, na linha 4, utilizamos a função ROUND com objetivo de mostrar ao usuário 
final somente a parte inteira dos valores resultantes da média salarial. 
CONSULTA 04 + RESULTADO 
Retornar, por mês de aniversário, o mês, o sexo e a quantidade de colaboradores. 
Apresentar os resultados ordenados pelo mês. 
Sistema de Banco de Dados 
Marcio Quirino - 138 
 
 
 
Resultado consulta 04. 
O SGBD realiza o agrupamento de dados de acordo com os valores do mês de aniversário. Em 
seguida, no contexto de cada mês encontrado, mais um grupo é construído por sexo. Finalmente,para cada 
ocorrência mês/sexo, o número de colaboradores é calculado. 
Grupo de dados com GROUP BY e HAVING 
Até o momento, utilizamos a cláusula WHERE para programar filtros em consultas, com condições 
simples ou compostas envolvendo colunas da tabela ou funções de data. 
Contudo, você vai vivenciar situações onde será necessário estabelecer algum tipo de filtro, tendo 
como base um cálculo originado a partir de uma função de agregação, não sendo possível usar a cláusula 
WHERE. Nesses casos, utilizamos a cláusula HAVING, que serve justamente para esse propósito. 
Vamos ver a seguir um exemplo de quando utilizar essa cláusula. 
CONSULTA 05 + RESULTADO 
Suponha que o departamento de recursos humanos esteja estudando a viabilidade de oferecer bônus de 5% 
aos funcionários por mês de nascimento, mas limitado somente aos casos onde há mais de um colaborador 
aniversariando. Assim, para cada mês em questão, deseja-se listar o mês, o número de colaboradores e o valor do 
bônus. 
Solução: 
 
 
Resultado consulta 05. 
Note que estamos diante de uma estrutura de consulta muito similar ao código da consulta 03. Porém, 
estamos interessados em retornar somente o(s) registro(s) cujo valor da coluna quantidade seja maior que 
a unidade. Acontece que quantidade é uma coluna calculada com auxílio de uma função de agregação, não 
sendo possível programar um filtro na cláusula WHERE (WHERE QUANTIDADE>1). Assim, declaramos o 
filtro de interesse fazendo uso da cláusula HAVING, conforme linha 6 da consulta. 
Ao longo da nossa jornada, estudamos o projeto de consultas com o uso de agrupamento de dados. 
Percebemos que esse recurso é imprescindível quando temos interesse na extração de informações de 
Sistema de Banco de Dados 
Marcio Quirino - 139 
 
caráter mais analítico a partir de alguma tabela, fazendo uso de funções de agregação associadas a uma 
ou diversas colunas. 
Ainda, percebemos que, às vezes, a natureza do problema que estamos resolvendo requer o uso de 
filtro tendo como base o uso de alguma função de agregação. Para isso, fizemos uso da cláusula HAVING. 
Agora é com você! Vamos realizar as atividades a seguir? 
Verificando o aprendizado 
1. Suponha que exista em um banco de dados uma tabela denominada CLIENTE, assim 
estruturada: CLIENTE (CODIGOCLIENTE, NOME, SEXO, BAIRRO, RENDA). Você foi 
solicitado a escrever um comando SQL para obter a renda média dos clientes por bairro. 
O comando correto é: 
SELECT BAIRRO, AVG(RENDA) 
FROM CLIENTE 
GROUP BY BAIRRO 
Para recuperar corretamente os registros de interesse, é necessário agrupar os dados pela 
coluna BAIRRO e em seguida usar a função de média (AVG), tendo como base a coluna RENDA. 
2. Suponha a existência de uma tabela no PostgreSQL com a seguinte estrutura: PRODUTO 
(CODIGOP, NOME, ANO QUANTIDADE). Suponha também que a tabela tenha os seguintes 
registros: 
CODIGO P NOME ANO QUANTIDADE 
1 VIRTUS 2020 3 
2 FIESTA 2014 1 
3 CRUZE 2020 4 
4 CAMARO 2018 1 
5 KOMBI 1996 4 
6 FOCUS 2016 3 
Qual consulta a seguir retorna mais de dois resultados? 
SELECT ANO,SUM(QUANTIDADE) AS TOTAL 
FROM PRODUTO 
GROUP BY ANO 
HAVING SUM(QUANTIDADE)>1; 
Para recuperar os registros de interesse, a consulta em questão retorna o total de automóveis 
por ano, no entanto, levando em conta somente os grupos em que o total seja maior que 1. Na 
prática, os anos 2014 e 2018 não farão parte dos resultados da consulta e os demais o farão, 
totalizando três resultados. 
Considerações finais 
Neste tema, tratamos do comando SELECT da SQL no PostgreSQL. Vimos a sua sintaxe básica 
para consulta a uma tabela, no formato SELECT ... FROM ... WHERE. 
Reconhecemos que, na cláusula SELECT, são especificadas as colunas da tabela a serem 
selecionadas, o que corresponde à operação de projeção da Álgebra Relacional. 
Aprendemos que é possível especificar expressões e funções nesta cláusula. No caso específico do 
PostgreSQL, vimos que a execução de funções pré-definidas é realizada especificando o nome e os 
parâmetros da função na cláusula SELECT, omitindo as demais cláusulas do comando, inclusive a cláusula 
FROM. Em seguida, estudamos o uso da cláusula WHERE, que especifica a condição de seleção de linhas 
da tabela, o que corresponde à operação de restrição ou seleção da Álgebra Relacional. Por fim, aplicamos 
Sistema de Banco de Dados 
Marcio Quirino - 140 
 
cláusulas adicionais do comando SELECT, como ORDER BY, GROUP BY e HAVING, todas implementadas 
no PostgreSQL em compatibilidade com o padrão da linguagem SQL. 
Referências 
AWS. Tarefas comuns do administrador de banco de dados para PostgreSQL. In: AWS. Consultado 
em meio eletrônico em: 30 mai. 2020. 
BILECKI, L. F.; KALEMPA, V. C. EasyRA: Uma ferramenta para tradução de consultas em álgebra 
relacional para SQL. In: Computer On The Beach, 2015, Florianópolis. Computer on the Beach, 2015. p. 21-
30. 
CAMPOS, N. S. Notas de Aula sobre Banco de Dados da professora Nathielly Campos. 
Disponível sob licença Creative Commons BR Atribuição – CC BY, 2020. 
ELMASRI, R.; NAVATHE, S. Sistemas de Banco de Dados. 7. ed. São Paulo: Pearson, 2019. 
POSTGRESQL. Chapter 9. Functions and Operators. In: PostgreSQL. Consultado em meio 
eletrônico em: 30 mai. 2020. 
POSTGRESQL. PostgreSQL Downloads. In: PostgreSQL. Consultado em meio eletrônico em: 30 
mai. 2020. 
POSTGRESQL. SELECT. In: PostgreSQL. Consultado em meio eletrônico em: 30 mai. 2020. 
Explore+ 
Para aprofundar os seus conhecimentos sobre o assunto deste tema, leia: 
“Tarefas comuns do administrador de banco de dados para PostgreSQL”, um interessante material 
sobre tarefas do dia a dia de um administrador de banco de dados que atue com o PostreSQL. Você pode 
encontrá-lo no site da Amazon Web Services. 
BILECKI, L. F.; KALEMPA, V. C. EasyRA: Uma ferramenta para tradução de consultas em álgebra 
relacional para SQL. In: Computer on the Beach, 2015. É importante saber que parte considerável da 
linguagem SQL é baseada na teoria de Álgebra Relacional. Trata-se de uma álgebra que envolve diversos 
operadores sobre relações. Neste trabalho, você aprenderá sobre as operações básicas da Álgebra 
Relacional, e conhecerá uma ferramenta para praticar comandos em álgebra e visualizar o respectivo 
comando na linguagem SQL. 
 
Sistema de Banco de Dados 
Marcio Quirino - 141 
 
Consulta Com Várias Tabelas no PostgreSQL 
Definição 
Junções interior e exterior. Consultas correlatas e aninhadas. Operadores de conjunto. 
Propósito 
Projetar consultas envolvendo diversas tabelas com diferentes tipos de junção e a utilização de 
mecanismos de subconsultas aninhadas, correlatas ou mesmo com o uso de operadores de conjunto. 
Preparação 
Antes de iniciar o conteúdo deste tema, certifique-se de ter baixado e instalado o SGBD PostgreSQL 
em seu computador. 
Introdução 
Ao longo deste tema, aprenderemos a executar consultas envolvendo mais de uma tabela. Quando 
projetamos um banco de dados relacional, em geral, o esquema final possuirá diversas tabelas relacionadas. 
Além disso, algumas tabelas são mais independentes do que outras. Na prática, podemos afirmar 
que uma tabela que não contenha restrição de chave estrangeira em alguma coluna é mais independente 
do que a(s) que a tem. 
Assim, é comum a necessidade de projetarmos consultas que recuperem dados de diferentes 
tabelas. Vamos perceber que será fundamental entendermos de que maneira se dá o provável 
relacionamento entre as tabelas envolvidas. 
Aprenderemos também que, na maior parte dos casos, o entendimento sobre o relacionamento entre 
tabelas ficará mais explícito quando localizarmos as colunas envolvidas na relação entre elas: chave primária 
de uma tabela e a respectiva chave estrangeira em outra ou na mesma tabela (no caso de 
autorrelacionamento). 
1. Consultas envolvendo junções interior e exterior 
Operação de junção de tabelas 
A junção de tabelas é uma das operações mais importantes criadas pelo modelo relacionalde banco 
dados. Na definição matemática, o resultado da junção de duas tabelas é um subconjunto do produto 
cartesiano entre essas tabelas. A especificação desse subconjunto é feita por uma condição de junção entre 
colunas das duas tabelas. 
Veremos que existem dois tipos de junção: interna, denominada INNER JOIN; e externa, denominada 
OUTER JOIN que, por sua vez, pode ser LEFT, FULL ou RIGHT OUTER JOIN. 
Exemplos de tabelas 
Construiremos algumas consultas com base nas tabelas NIVEL e CURSO, conforme figura a seguir: 
 
Tabelas NIVEL e CURSO. 
Sistema de Banco de Dados 
Marcio Quirino - 142 
 
Recomendamos que você crie as tabelas e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar 
conectado ao PostgreSQL e acessando algum database criado por você. 
 
No script, foram usados três comandos: CREATE, ALTER e INSERT. A sintaxe completa desses 
comandos no PostgreSQL pode ser encontrada com a indicação disponibilizada no Explore + ao final do 
tema. 
A figura a seguir apresenta o conteúdo da tabela NIVEL após a execução do comando SELECT * 
FROM NIVEL; 
 
Conteúdo da tabela NIVEL. 
A figura a seguir apresenta o conteúdo da tabela CURSO após a execução do comando TABLE 
CURSO; 
 
Conteúdo da tabela CURSO. 
Observe que as tabelas NIVEL e CURSO estão relacionadas. A tabela NIVEL é a mais independente, 
visto que não possui chave estrangeira. Consequência disso é a possibilidade de um usuário cadastrar 
diversos níveis na tabela, sem a preocupação com qualquer outra tabela do banco de dados. O 
relacionamento entre NIVEL e CURSO está implementado na tabela CURSO, por meio da coluna 
CODIGONIVEL, que exerce o papel de chave estrangeira. 
Por fim, note também que o fato da coluna CODIGONIVEL ser opcional na tabela CURSO representa 
a possibilidade de cadastrar um curso sem, em um primeiro momento, relacioná-lo a determinado nível 
Sistema de Banco de Dados 
Marcio Quirino - 143 
 
existente. É justamente o que ocorreu após a execução dos comandos das linhas 20 e 23, nos quais o valor 
inserido para a coluna CODIGONIVEL é NULL. 
A seguir, algumas observações sobre o que acontece quando declaramos mais de uma tabela em 
uma consulta SQL. 
Operação de produto cartesiano 
Em termos estruturais, a tabela NIVEL possui duas colunas e quatro registros. De forma semelhante, 
a tabela CURSO possui quatro colunas e seis registros. Você pode chegar a essa conclusão ao analisar o 
script anterior. 
Vamos, agora, executar a seguinte consulta SQL: SELECT * FROM CURSO, NIVEL; cujo resultado 
está expresso na figura a seguir: 
 
Resultado da consulta SELECT * FROM CURSO, NIVEL; 
O resultado da consulta anterior é uma tabela - em memória principal - originada da operação de 
produto cartesiano. Nessa operação, o sistema gerenciador de banco de dados (SGBD) combinou cada 
linha da tabela CURSO com cada registro da tabela NIVEL. 
Note que a quantidade de (seis) colunas na tabela resultante é a soma das colunas das tabelas 
envolvidas. De forma semelhante, a quantidade (vinte e quatro) de registros da tabela é igual ao produto 
entre o número de linhas de CURSO e NIVEL. 
Perceba que, ao longo do nosso estudo, temos interpretado cada linha de uma tabela como sendo 
um fato registrado no banco de dados, correspondendo a uma realidade do contexto do negócio sendo 
modelado. 
Exemplo: ao visualizarmos o conteúdo da tabela NIVEL, afirmamos que há quatro registros ou 
ocorrências de nível no banco de dados. De forma semelhante, há seis cursos cadastrados na tabela 
CURSO. 
Sistema de Banco de Dados 
Marcio Quirino - 144 
 
No entanto, o mesmo raciocínio não pode ser aplicado à tabela resultante da consulta, já que temos 
todas as combinações possíveis entre as linhas, além de envolver todas as colunas das tabelas CURSO e 
NIVEL. 
Comentário 
Cabe aqui um alerta sobre o cuidado que se deve ter ao usar esse tipo de consulta, que resulta em produto 
cartesiano. Suponha uma tabela CLIENTES com 1.000.000 de linhas e uma tabela PEDIDOS com 10.000.000 de 
linhas. O comando SELECT * FROM CLIENTES, PEDIDOS retornaria 10.000.000.000.000 de linhas e, provavelmente, 
ocuparia longas horas de processamento no servidor, além de retornar um resultado inútil! 
Há outra maneira de obtermos os mesmos resultados de SELECT * FROM CURSO, NIVEL;? 
Sim. Basta executar o código equivalente: SELECT * FROM CURSO CROSS JOIN NIVEL; 
A seguir, vamos estudar uma forma de extrair informações úteis a partir do resultado dessa consulta. 
Junção interna 
Estamos interessados em obter informações úteis para o nosso usuário. Perceba que, por exemplo, 
o curso de Sistemas de Informação está classificado como um curso pertencente ao nível de graduação. 
Como chegamos a essa conclusão? Avalie o conteúdo das linhas 14 e 18 do script que insere 
informações nas tabelas NIVEL e CURSO. 
Agora, examine as quatro primeiras linhas da tabela resultante da consulta anterior, expressa na 
figura a seguir: 
 
Subconjunto da tabela resultante do produto cartesiano entre CURSO e NIVEL. 
Note que, se examinarmos cada linha como um fato, vamos perceber que somente a primeira 
corresponde à realidade cadastrada no banco de dados. Não por coincidência, perceba que os valores das 
colunas CODIGONIVEL são os mesmos. Nas três últimas, diferentes. 
Assim, nós podemos eliminar as linhas falsas se programarmos uma condição de igualdade 
envolvendo as colunas em questão. Devemos lembrar que as quatro primeiras colunas vêm da tabela 
CURSO. As duas últimas são originadas na tabela NIVEL. 
Para recuperar as linhas que correspondem à realidade cadastrada no banco de dados, você pode 
executar o comando a seguir: 
SELECT * 
FROM CURSO, NIVEL 
WHERE NIVEL.CODIGONIVEL=CURSO.CODIGONIVEL; 
O resultado dessa consulta está expresso na figura a seguir: 
 
Resultado da consulta envolvendo as tabelas CURSO e NIVEL. 
Sistema de Banco de Dados 
Marcio Quirino - 145 
 
Perceba que foram recuperadas as linhas que de fato relacionam cursos aos seus respectivos níveis. 
No entanto, a forma mais usada para retornar os mesmos resultados é com o auxílio da cláusula de junção 
interna, o qual possui sintaxe básica conforme a seguir: 
SELECT * 
FROM TABELA1 [INNER] JOIN TABELA2 ON (CONDIÇÃOJUNÇÃO) [USING (COLUNA_DE_JUNÇÃO)] 
Na sintaxe apresentada, declaramos a cláusula de junção entre as tabelas. Em seguida, a preposição 
“ON” e a condição da junção. Na maioria das vezes, essa condição corresponderá a uma igualdade 
envolvendo a chave primária de uma tabela e a chave estrangeira correspondente. A sintaxe completa do 
comando SELECT no PostgreSQL pode ser encontrada com a indicação disponibilizada no Explore + ao 
final do tema. 
Veja, a seguir, o código SQL correspondente ao nosso exemplo: 
SELECT * 
FROM CURSO INNER JOIN NIVEL ON(NIVEL.CODIGONIVEL=CURSO.CODIGONIVEL); 
Note também que é possível declarar a cláusula USING especificando a coluna alvo da junção. No 
caso do nosso exemplo, a coluna CODIGONIVEL. A consulta pode ser reescrita conforme a seguir: 
SELECT * 
FROM CURSO INNER JOIN NIVEL USING(CODIGONIVEL); 
Se desejarmos exibir o código e o nome do curso, além do código e o nome do nível, podemos, então 
executar o código a seguir: 
SELECT CURSO.CODIGOCURSO, CURSO.NOME, 
FROM CURSO INNER JOIN NIVEL USING(CODIGONIVEL); 
 
SELECT C.CODIGOCURSO, C.NOME,N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO INNER JOIN NIVEL ON 
NIVEL.CODIGONIVEL=CURSO.CODIGONIVEL; 
Perceba que, no comando SELECT, usamos uma referência mais completa: 
NOMETABELA.NOMECOLUNA. Essa referência só é obrigatória para a coluna CODIGONIVEL, uma vez 
que é necessário especificar de qual tabela o SGBD irá buscar os valores. No entanto, em termos de 
organização de código, é interessante usar esse tipo de referência para cada coluna. 
Finalmente, observe que poderíamos também, no contexto da consulta, renomearas tabelas 
envolvidas, deixando o código mais elegante e legível, conforme a seguir: 
SELECT C.CODIGOCURSO, C.NOME,N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO C INNER JOIN NIVEL N ON(N.CODIGONIVEL=C.CODIGONIVEL); 
O resultado da consulta está expresso na figura a seguir: 
 
Resultado da consulta envolvendo as tabelas CURSO e NIVEL. 
O resultado de uma junção interna corresponde somente aos registros que atendem à condição da 
junção, ou seja, os registros que de fato estão relacionados no contexto das tabelas envolvidas. 
Junção externa 
O resultado da consulta anterior exibe somente os cursos para os quais há registro de informação 
sobre o nível associado a eles. E se quiséssemos incluir na listagem todos os registros da tabela CURSO? 
Para incluir no resultado da consulta todas as ocorrências da tabela CURSO, podemos usar a 
cláusula LEFT JOIN (junção à esquerda). Nesse tipo de junção, o resultado contém todos os registros da 
Sistema de Banco de Dados 
Marcio Quirino - 146 
 
tabela declarada à esquerda da cláusula JOIN, mesmo que não haja registros correspondentes na tabela 
da direita. Em especial, quando não há correspondência, os resultados são retornados com o valor NULL. 
Veja a seguir exemplo de uso de junção à esquerda: 
SELECT C.CODIGOCURSO, C.NOME, 
N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO C LEFT JOIN NIVEL N ON (N.CODIGONIVEL=C.CODIGONIVEL); 
A figura a seguir apresenta o resultado da consulta anterior: 
 
Cursos e níveis, exibindo todos os registros da tabela CURSO. 
Observe que o número de linhas do resultado da consulta coincide com o número de linhas da tabela 
CURSO, visto que todos os registros dessa tabela fazem parte do resultado e a chave estrangeira que 
implementa o relacionamento está localizada na tabela CURSO. Em especial, as linhas 3 e 6 correspondem 
a cursos onde não há informação sobre o nível associado a eles. 
Perceba também que, de forma semelhante, poderíamos ter interesse em exibir todos os registros 
da tabela à direita da cláusula JOIN. Em nosso exemplo, a tabela NIVEL. A cláusula RIGHT JOIN (junção à 
direita) é usada para essa finalidade. Nesse tipo de junção, o resultado contém todos os registros da tabela 
declarada à direita da cláusula JOIN, mesmo que não haja registros correspondentes na tabela da esquerda. 
Em especial, quando não há correspondência, os resultados são retornados com o valor NULL. 
Veja a seguir exemplo de uso de junção à direita: 
SELECT C.CODIGOCURSO, C.NOME, 
N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO C RIGHT JOIN NIVEL N ON 
(N.CODIGONIVEL=C.CODIGONIVEL); 
A figura a seguir apresenta o resultado da consulta anterior: 
 
Cursos e níveis, exibindo todos os registros da tabela NIVEL. 
Note que todos os registros da tabela NIVEL aparecem no resultado. As quatro primeiras linhas do 
resultado da consulta correspondem aos registros que efetivamente estão relacionados à tabela CURSO. 
As duas últimas linhas são registros que não estão relacionados a qualquer curso existente no banco de 
dados. 
Perceba que o mesmo resultado pode ser obtido se usarmos junção à esquerda e junção à direita, 
alternando a posição das tabelas envolvidas. Com isso, queremos dizer que TABELA1 LEFT JOIN TABELA2 
é equivalente a TABELA2 RIGHT JOIN TABELA1. 
Veja exemplo a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 147 
 
SELECT C.CODIGOCURSO, C.NOME, 
N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO C LEFT JOIN NIVEL N ON (N.CODIGONIVEL=C.CODIGONIVEL); 
 
SELECT C.CODIGOCURSO, C.NOME, 
N.CODIGONIVEL, N.DESCRICAO 
FROM NIVEL N RIGHT JOIN CURSO C ON (N.CODIGONIVEL=C.CODIGONIVEL); 
 
Outro tipo de junção externa, denominada FULL OUTER JOIN (junção completa), apresenta todos 
os registros das tabelas à esquerda e à direita, mesmo os registros não relacionados. Em outras palavras, 
a tabela resultante exibirá todos os registros de ambas as tabelas, além de valores NULL no caso dos 
registros sem correspondência. Veja exemplo a seguir: 
SELECT C.CODIGOCURSO, C.NOME, 
N.CODIGONIVEL, N.DESCRICAO 
FROM CURSO C FULL OUTER JOIN NIVEL N ON 
(N.CODIGONIVEL=C.CODIGONIVEL); 
A figura a seguir apresenta o resultado da consulta anterior: 
 
Resultado do FULL OUTER JOIN entre CURSO e NIVEL. 
Note que, no resultado, aparecem os registros de cada tabela. Além disso, valores NULL são exibidos 
nos casos em que não há correspondência entre as tabelas (linhas 3, 6, 7 e 8). 
Neste módulo, aprendemos que, quando há necessidade de extrair informações de mais de uma 
tabela, utilizamos a cláusula de junção. Estudamos diversos tipos de junção, que serão utilizados de acordo 
com a necessidade do usuário, visto que cada tipo de junção possui uma especificidade. 
Atenção: 
Antes de iniciar o vídeo, realize o download do arquivo EMPRESA.SQL e realize a criaçäo do banco de dados 
utilizando o PGADMIN. 
Verificando o aprendizado 
1. Considere as tabelas e o código SQL a seguir: 
 
A consulta retorna: 
Registros, tanto dos alunos com telefone, quanto dos alunos sem telefone. 
Sistema de Banco de Dados 
Marcio Quirino - 148 
 
A consulta usa junção à esquerda. Logo, todos os registros de ALUNO farão parte do resultado: 
alunos com e sem telefone cadastrado no banco de dados. 
2. Considere as tabelas e o código SQL a seguir: 
 
A consulta retorna: 
A descrição dos projetos e nomes de professores e alunos envolvidos em orientação. 
A consulta envolve somente junções internas. Retorna informações sobre todas as orientações 
cadastradas no banco de dados. 
2. Subconsultas aninhadas e correlatas 
Subconsultas 
Podemos admitir que o resultado de uma consulta SQL corresponde a uma tabela, mesmo que esteja 
temporariamente armazenada na memória principal do computador. 
Vamos construir consultas que dependem dos - ou usam - resultados de outras consultas para 
recuperar informações de interesse. Essa categoria é conhecida por subconsulta, uma consulta sobre o 
resultado de outra consulta. 
Ao longo do nosso estudo, vamos explorar dois tipos de subconsultas: aninhadas e correlatas. No 
primeiro caso, a consulta mais externa realizará algum tipo de teste junto aos dados originados da consulta 
mais interna. No segundo, a subconsulta utiliza valores da consulta externa. Nesse tipo de consulta, a 
subconsulta é executada para cada linha da consulta externa. 
Exemplo de tabelas 
Construiremos as consultas com base nas tabelas FUNCIONARIO E DEPARTAMENTO, conforme 
figura a seguir. 
Recomendamos que você crie as tabelas e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar 
conectado ao PostgreSQL e acessar algum database criado por você. 
 
Sistema de Banco de Dados 
Marcio Quirino - 149 
 
Tabelas FUNCIONARIO e DEPARTAMENTO. 
 
A figura a seguir apresenta o conteúdo da tabela DEPARTAMENTO após a execução do comando 
SELECT * FROM DEPARTAMENTO; 
 
Conteúdo da tabela DEPARTAMENTO. 
A figura a seguir apresenta o conteúdo da tabela FUNCIONARIO após a execução do comando 
TABLE FUNCIONARIO; (equivalente a SELECT * FROM FUNCIONARIO;) 
 
Conteúdo da tabela FUNCIONARIO. 
Perceba que, originalmente, existe um relacionamento do tipo 1:N entre DEPARTAMENTO e 
FUNCIONARIO. A implementação desse relacionamento ocorre por meio da chave estrangeira 
CODIGODEPARTAMENTO da tabela FUNCIONARIO. 
Subconsultas aninhadas 
Uma subconsulta aninhada ocorre quando é necessário obter dados que dependem do resultado de 
uma - ou mais - consulta(s) mais interna(s). Para isso, cria-se uma condição na cláusula WHERE de forma 
a envolver o resultado da subconsulta em algum tipo de teste. 
Vamos estudar alguns exemplos? 
Consulta 01: Retornar o código e o nome do(s) funcionário(s) que ganha(m) o maior salário. 
Solução: 
Sistema de Banco de Dados 
Marcio Quirino - 150 
 
 
O resultado da consulta 01 está expresso na figura a seguir: 
 
Resultado da consulta 01. 
Comentário 
Inicialmente, oSGBD processa a subconsulta, a qual retorna o valor do maior salário registrado na tabela 
FUNCIONARIO. Em seguida, esse resultado é utilizado na avaliação da cláusula WHERE. Finalmente, são exibidos 
os registros dos funcionários cujo valor de SALARIO satisfaz a condição da cláusula WHERE. 
Consulta 02: Retornar o código, o nome e o salário do(s) funcionário(s) que ganha(m) mais que a 
média salarial dos colaboradores. 
Solução: 
 
O resultado da consulta 02 está expresso na figura a seguir: 
 
Resultado da consulta 02. 
Comentário 
Inicialmente, o SGBD processa a subconsulta, a qual retorna a média salarial a partir da tabela FUNCIONARIO. 
Em seguida, esse resultado é utilizado na avaliação da cláusula WHERE. Finalmente, são exibidas as linhas da tabela 
FUNCIONARIO com as colunas CODIGOFUNCIONARIO, NOME e SALARIO, cujo valor de SALARIO satisfaz a 
condição da cláusula WHERE. 
Consulta 03: Retornar o código, o nome e o salário do(s) funcionário(s) que ganha(m) menos que a 
média salarial dos colaboradores do departamento de Tecnologia da Informação. 
Solução: 
 
O resultado da consulta 03 está expresso na figura a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 151 
 
 
Resultado da consulta 03. 
Comentário 
Perceba que, para retornar os resultados de interesse, o SGBD precisa calcular a média salarial dos 
funcionários do departamento de Tecnologia da Informação. Para isso, a subconsulta da linha 4 – que calcula essa 
média - utiliza o resultado da subconsulta da linha 6, a qual recupera o código do departamento de Tecnologia da 
Informação). 
Há outra maneira de resolver a consulta 03? 
Sim, você pode trocar uma subconsulta por uma junção. O código a seguir produz os mesmos 
resultados: 
 
Consulta 04: Quantos funcionários recebem menos que a funcionária que possui o maior salário entre 
as colaboradoras de sexo feminino? 
Solução: 
 
O resultado da consulta 04 está expresso na figura a seguir: 
 
Comentário 
No exemplo, o SGBD recupera o maior salário entre as funcionárias. Em seguida, conta os registros cujo valor 
da coluna SALARIO é menor que o valor do salário em questão. 
Subconsultas correlatas 
Uma subconsulta correlata – ou correlacionada – é um tipo especial de consulta aninhada. Uma 
consulta correlata ocorre quando é necessário obter dados que dependem do resultado de uma - ou mais - 
consulta(s) mais interna(s). Para isso, cria-se uma condição na cláusula WHERE de forma a envolver o 
resultado da subconsulta em algum tipo de teste. 
Vamos estudar alguns exemplos? 
Sistema de Banco de Dados 
Marcio Quirino - 152 
 
Consulta 05: Retornar o código, o nome e o salário do(s) funcionário(s) que ganha(m) mais que a 
média salarial dos colaboradores do departamento ao qual pertencem. 
Solução: 
 
O resultado da consulta 05 está expresso na figura a seguir: 
 
Resultado da consulta 05. 
Trata-se de uma consulta com lógica de construção semelhante ao que foi desenvolvido na consulta 
02. No entanto, a média salarial é calculada levando em consideração somente os funcionários de cada 
departamento. Isso ocorre em função da condição WHERE declarada na linha 6. 
Há outra maneira de resolver a consulta 05? 
Sim, você pode trocar uma subconsulta por uma junção. O código a seguir produz os mesmos 
resultados: 
 
O exemplo a seguir mostra o uso de uma consulta correlacionada em uma operação de atualização 
(UPDATE) nos dados. 
Consulta 06: suponha que surgiu a necessidade de equiparar os salários dos funcionários que atuam 
no mesmo departamento. Os funcionários de cada departamento terão salário atualizado em função do 
maior salário dos seus setores. 
Observe na figura a seguir os salários “antes” da atualização. 
 
Tabela FUNCIONARIO antes da atualização dos salários. 
Perceba que a listagem está ordenada pela coluna CODIGODEPARTAMENTO. O maior salário de 
funcionário pertencente ao departamento 1 é R$ 7.000; em relação ao departamento 2, R$ 9.500. Note 
também que há um funcionário sem a informação sobre departamento. 
Solução: 
Sistema de Banco de Dados 
Marcio Quirino - 153 
 
 
Observe na figura a seguir os salários após a atualização salarial. 
 
Tabela FUNCIONARIO depois da atualização dos salários. 
Trata-se de uma consulta com objetivo de recuperar o maior salário dentro do contexto de cada 
departamento e, em seguida, usar esse valor para atualização salarial na tabela FUNCIONARIO, de acordo 
com o departamento de cada colaborador. Perceba também que a atualização ocorre somente para os 
funcionários para os quais existe alocação a departamento, ou seja, a cláusula WHERE da linha 6 inibe 
atualização de salário caso não haja departamento associado a algum colaborador. 
A sintaxe completa do comando UPDATE no PostgreSQL A sintaxe completa do comando UPDATE 
pode ser encontrada com a indicação disponibilizada no Explore + ao final do tema. 
Consulta correlacionada com uso de [NOT] EXISTS 
Podemos utilizar o operador EXISTS em uma consulta correlacionada. Tal operador testa a 
existência de linha(s) retornada(s) por alguma subconsulta. Veja o exemplo a seguir: 
Consulta 07: exibir o código e o nome do departamento onde há pelo menos um funcionário alocado. 
Solução: 
 
Observe na figura a seguir os resultados da consulta. 
 
Departamentos onde há pelo menos um funcionário alocado. 
A subconsulta correlacionada (linhas 4 a 6) é executada. Caso haja pelo menos uma linha em seu 
retorno, a avaliação da cláusula WHERE retorna verdadeiro e as colunas especificadas na linha 1 são 
exibidas. 
Finalmente, se estivéssemos interessados em saber se há departamento sem ocorrência de 
colaborador alocado, bastaria usar a negação (NOT), conforme a seguir: 
 
Observe na figura a seguir os resultados da consulta. 
Sistema de Banco de Dados 
Marcio Quirino - 154 
 
 
Departamento onde não há funcionário alocado. 
Durante o estudo deste módulo, aprendemos a desenvolver consultas que dependem dos resultados 
de outras consultas para exibir de maneira correta os seus resultados aos usuários. Tais consultas são 
denominadas aninhadas. 
Ainda, conhecemos a estrutura de consultas correlacionadas, vistas como um tipo especial de 
consulta aninhada, na qual cada linha da consulta externa é testada junto à consulta interna. 
Verificando o aprendizado 
1. Considere as tabelas e o código SQL a seguir: 
 
 
A consulta retorna: 
O(s) registro(s) de aluno(s) com pelo menos um telefone. 
Há o uso de uma subconsulta correlata, junto a cláusula EXISTS, que testa a existência de algum 
retorno da subconsulta. Assim, caso haja retorno da consulta, significa que o aluno em questão 
possui pelo menos um telefone. 
2. Considere a tabela e o código SQL a seguir: 
 
A consulta retorna: 
O número de empregados que ganham menos que o empregado de maior salário. 
A cláusula WHERE compara o salário de cada funcionário junto ao do colaborador que tem maior 
renda. Caso o salário do funcionário seja menor que o maior salário, esse funcionário é 
considerado na contagem. 
 
Sistema de Banco de Dados 
Marcio Quirino - 155 
 
3. Consultas com o uso de operadores de conjunto 
Operadores de conjunto 
Vamos aprender que os resultados de diversas consultas podem ser combinados em um único 
conjunto de dados, caso sigam regras específicas dos operadores utilizados para essa finalidade. Estamos 
falando dos operadores de conjunto, que incluem UNION, INTERSECT e EXCEPT. 
Exemplo de tabelas 
Construiremos as consultas com base nas tabelas FUNCIONARIO, ALUNO e CLIENTE, conforme 
figura a seguir: 
 
Tabelas FUNCIONARIO, ALUNO e CLIENTE. 
Recomendamos que você crie as tabelas e insira algumas linhas, o que pode ser feito usando o script 
a seguir, a partir da ferramenta de sua preferência. Para isso, tenha em mente que é necessário estar 
conectado ao PostgreSQL e acessar algum database criado por você. 
 
Criação das tabelas FUNCIONARIO, ALUNO e CLIENTE. 
O script a seguir pode serutilizado para inserção de registros nas tabelas. 
 
Inserção de dados nas tabelas FUNCIONARIO, ALUNO e CLIENTE. 
Sistema de Banco de Dados 
Marcio Quirino - 156 
 
A figura a seguir apresenta o conteúdo da tabela FUNCIONARIO após a execução do comando 
SELECT * FROM FUNCIONARIO; 
 
Conteúdo da tabela FUNCIONARIO. 
A figura a seguir apresenta o conteúdo da tabela ALUNO após a execução do comando TABLE 
ALUNO; 
 
Conteúdo da tabela ALUNO. 
A figura a seguir apresenta o conteúdo da tabela CLIENTE após a execução do comando TABLE CLIENTE; 
 
Conteúdo da tabela CLIENTE. 
Convém esclarecer que, em todos os registros, os dados são puramente fictícios. Além disso, os 
dados da coluna CPF estão com somente quatro caracteres e não representam um CPF válido. No entanto, 
vamos considerar, para efeitos do nosso estudo, que registros com mesmo valor de CPF representam a 
informação de um mesmo cidadão. De forma complementar, estamos levando em consideração que cada 
tabela pertence a um banco de dados – e um domínio de aplicação – diferente. 
Consultas com o operador UNION 
O operador de união serve para consolidar linhas resultantes de consultas. Para isso, todas as 
consultas envolvidas devem possuir a mesma quantidade de colunas e deve haver compatibilidade de tipo 
de dados. Além disso, linhas repetidas são eliminadas do resultado, uma vez que o resultado é uma tabela 
que não permite duplicata de linhas. O operador de união possui a seguinte forma geral: 
CONSULTASQL UNION [ALL|DISTINCT] CONSULTASQL 
A sintaxe completa do comando SELECT no PostgreSQL pode ser pode ser encontrada com a 
indicação disponibilizada no Explore + ao final do tema. 
Consulta 01: Retornar o nome e o CPF de todos os funcionários e clientes. 
Solução: 
 
O resultado da consulta 01 está expresso na figura a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 157 
 
 
Resultado da consulta 01. 
Comentário 
Perceba que há cinco funcionários cadastrados (linhas 1 a 10 do script de inserção) e, de forma semelhante, 
três clientes (linhas 18 a 20 do script de inserção). Note também que todos os clientes cadastrados também são 
funcionários. Após o processamento da operação de união, somente cinco registros foram exibidos, uma vez que as 
repetições por padrão são eliminadas. 
E se quiséssemos que todos registros aparecessem no resultado? 
Bastaria usar o UNION ALL, conforme a seguir: 
 
O resultado da consulta 01 modificada está expresso na figura a seguir: 
 
Resultado da consulta 01 modificada para contemplar todos os registros das tabelas. 
Finalmente, se quiséssemos especificar a “origem” de cada registro, poderíamos alterar o nosso 
código conforme a seguir: 
 
O resultado da consulta 01 modificada está expresso na figura a seguir: 
 
Resultado da consulta 01 modificada para contemplar todos os registros das tabelas exibir a tabela de origem. 
Sistema de Banco de Dados 
Marcio Quirino - 158 
 
Consultas com o operador INTERSECT 
O operador de interseção serve para exibir linhas que aparecem em ambos os resultados das 
consultas envolvidas. Para isso, todas as consultas devem possuir a mesma quantidade de colunas e deve 
haver compatibilidade de tipo de dados. Além disso, linhas repetidas são eliminadas do resultado. O 
operador de interseção possui a seguinte forma geral: 
CONSULTASQL INTERSECT [ALL|DISTINCT] CONSULTASQL 
Vamos estudar alguns exemplos? 
Consulta 02: Retornar o nome e o CPF de todos os cidadãos que são funcionários e clientes. 
Solução: 
 
O resultado da consulta 02 está expresso na figura a seguir: 
 
Resultado da consulta 02. 
A consulta retorna três linhas que são fruto da interseção entre as tabelas FUNCIONARIO e 
CLIENTE. Como visto, todos os clientes são funcionários. 
Consulta 03: Retornar o nome e o CPF de todos os cidadãos que são funcionários, clientes e alunos. 
Solução: 
 
O resultado da consulta 03 está expresso na figura a seguir: 
 
Resultado da consulta 03. 
A consulta retorna duas linhas que são fruto da interseção entre as tabelas FUNCIONARIO, CLIENTE 
e ALUNO. 
Um aspecto importante é que uma consulta sob o formato X UNION Y INTERSECT Z é interpretada 
sendo X UNION (Y INTERSECT Z). Veja o exemplo a seguir: 
Sistema de Banco de Dados 
Marcio Quirino - 159 
 
 
O resultado da consulta envolvendo as três tabelas está expresso na figura a seguir: 
 
Resultado da consulta envolvendo três tabelas. 
Consultas com o operador EXCEPT 
O operador EXCEPT implementa a operação de subtração da Teoria dos Conjuntos e serve para 
exibir linhas que aparecem em uma consulta e não aparecem na outra. Para isso, todas as consultas devem 
possuir a mesma quantidade de colunas e deve haver compatibilidade de tipo de dados. Além disso, linhas 
repetidas são eliminadas do resultado. O operador de subtração possui a seguinte forma geral: 
CONSULTASQL EXCEPT [ALL|DISTINCT] CONSULTASQL 
Convém ressaltar que alguns SGBDs implementam a mesmo operador, usando um nome diferente. 
O Oracle, por exemplo, utiliza o operador MINUS, significando subtração ou diferença. 
Vamos estudar alguns exemplos? 
Consulta 04: Retornar o nome e o CPF dos funcionários que não são clientes. 
Solução: 
 
O resultado da consulta 04 está expresso na figura a seguir: 
 
Resultado da consulta 04. 
A consulta retorna duas linhas que são fruto da subtração entre as tabelas FUNCIONARIO e 
CLIENTE. 
Perceba que uma operação X EXCEPT Y é diferente de Y EXCEPT X. Veja o código a seguir: 
 
A consulta retorna vazio pois todos os clientes são funcionários. 
Consulta 05: Retornar o nome e o CPF dos cidadãos que são somente funcionários. 
Sistema de Banco de Dados 
Marcio Quirino - 160 
 
Solução: 
 
O resultado da consulta 05 está expresso na figura a seguir: 
 
Resultado da consulta 05. 
Comentário 
Inicialmente, o SGBD processa a operação de subtração da linha 3. Em seguida, o resultado da operação é 
usado na subtração da linha 6. 
Ao longo deste módulo, aprendemos a construir consultas envolvendo operadores de conjunto. 
Foram analisados os operadores UNION, INTERSECT e EXCEPT. Todos têm em comum a obrigatoriedade 
de serem usadas consultas com o mesmo número de colunas, além da compatibilidade entre os tipos de 
dados delas. 
Verificando o aprendizado 
1. Considere que cada tabela a seguir pertence a um banco de dados distinto. 
 
Qual consulta retorna o nome e o CPF dos alunos que não são clientes? 
SELECT NOME, CPF FROM ALUNO 
EXCEPT 
SELECT NOME, CPF FROM CLIENTE; 
Para recuperar os alunos que não são clientes, basta utilizar o operador de subtração, que, no 
contexto da questão, retornará os registros resultantes da consulta envolvendo a tabela ALUNO 
que não estão presentes nos resultados da consulta envolvendo a tabela CLIENTE. 
2. Considere que cada tabela a seguir pertence a um banco de dados distinto. 
 
Qual consulta retorna o nome e o CPF dos clientes que são alunos? 
SELECT NOME, CPF FROM CLIENTE 
INTERSECT 
Sistema de Banco de Dados 
Marcio Quirino - 161 
 
SELECT NOME, CPF FROM ALUNO; 
Para recuperar os clientes que são alunos, basta utilizar o operador de interseção, que, no 
contexto da questão, retornará os registros resultantes da consulta envolvendo a tabela 
CLIENTE que não estão presentes nos resultados da consulta envolvendo a tabela ALUNO. 
Considerações finais 
Neste tema, vimos que as consultas SQL envolvem, em geral, mais de uma tabela. Nessas consultas, 
é essencial a operação de junção entre as tabelas, que tem dois tipos: junção interna (INNER JOIN) e 
externa (OUTER JOIN), dependendo do resultado que se deseja obter da consulta. 
Vimos, também, que as consultas em SQL podem ser aninhadas, em decorrência da propriedade de 
que o resultado de uma consulta é uma tabela e, por isso, pode estar sucessivamente sujeito a novas 
consultas. Dentre as consultas aninhadas, vimos um tipo especial denominado de consulta correlata. 
Finalmente, aplicamos as operações de união,interseção e diferença da Teoria Matemática dos 
Conjuntos nas consultas SQL, através dos operadores UNION, INTERSECT e EXCEPT. 
Referências 
POSTGRESQL. Manual de referência do PostgreSQL. IN: POSTGRESQL. Consultado em meio 
eletrônico em: 11 Ago 2020. 
Explore+ 
Para saber mais sobre os comandos CREATE, ALTER E INSERT explorados neste tema, acesse: 
Postgresql em create table; altertable; sql-altertable. 
Postgresql em sql-select, e entenda o comando INSERT. 
Postgresql em sql-uptade, e entenda o comando UPDATE.