Banco de Dados I

Prévia do material em texto

O desenvolvimento de novos sistemas de informação corpo-
rativos, para uso pessoal e até de aplicativos para celulares 
(apps) tem exigido – com grande frequência e dos pro-
gramadores – o conhecimento de técnicas de criação e 
manipulação dos bancos de dados. Qualquer sistema, por 
mais simples que seja, em algum momento terá a necessi-
dade de criar, manter e consultar determinado tipo de dado. 
 
A evolução das tecnologias de armazenamento, mani-
pulação e consulta a fontes de dados criou um conjunto 
específico de conhecimentos dentro da área de infor-
mática, que se chama banco de dados (BD). Esse é o tema 
abordado nesta obra, que prepara o leitor para poder com-
preender e se aprimorar nessa nova área de conhecimento. 
 
Durante o estudo desta obra, o leitor participará de uma jor-
nada que começa com os primeiros conceitos, passa por 
métodos de construção de modelos de dados – conceituais, 
lógicos ou físicos – e chega, por fim, à construção e manipu-
lação dos dados dentro de um BD.
BANCO DE DADOS I
Paulo Sérgio CougoFundação Biblioteca NacionalISBN 978-85-387-6621-6
9 7 8 8 5 3 8 7 6 6 2 1 6
Código Logístico
59337
Banco de Dados I 
Paulo Sérgio Cougo
IESDE BRASIL
2020
© 2020 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e do 
detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: DrHitch/Shutterstock
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C892b
Cougo, Paulo Sérgio
Banco de dados I / Paulo Sérgio Cougo. - 1. ed. - Curitiba [PR] : IESDE, 
2020. 
154 p. : il.
Inclui bibliografia
ISBN 978-85-387-6621-6
1. Banco de dados - Desenvolvimento. 2. Projeto de banco de dados. 
3. Banco de dados relacionais. 4. SQL (Linguagem de programação de com-
putador). I. Título.
20-63077 CDD: 005.75
CDU: 005.652.4
Paulo Sérgio Cougo Pós-graduado em Análise de Sistemas na Administração 
de Empresas pela Pontifícia Universidade Católica do 
Paraná (PUCPR). Tecnólogo em Processamento de Dados 
pela Universidade Federal do Paraná (UFPR). Profissional 
com atuação nas funções de administrador de banco 
de dados e administrador de dados. Responsável 
pela modelagem e pelo projeto e monitoramento de 
bancos de dados corporativos. Instrutor de cursos de 
modelagem de banco de dados e professor em curso de 
pós-graduação em banco de dados. Autor e revisor de 
livros sobre modelagem e projeto de banco de dados.
SUMÁRIO
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
1 Introdução a banco de dados 9
1.1 O que é e para que serve um banco de dados? 9
1.2 Vantagens e desvantagens do uso de um banco de dados 21
1.3 Criação e manutenção de bancos de dados 24
1.4 Tipos de bancos de dados 29
2 Sistema de gerência de banco de dados 34
2.1 O que é e para que serve um SGBD? 34
2.2 Vantagens e desvantagens do uso de um SGBD 38
2.3 Criação e manutenção de um SGBD 43
2.4 Tipos de SGBD 47
3 Modelagem de dados 51
3.1 O que é e para que serve um modelo de dados? 51
3.2 Vantagens e desvantagens de um modelo de dados 55
3.3 Criação e manutenção de um modelo de dados 62
3.4 Tipos de modelos de dados 72
4 Modelo relacional e normalização 76
4.1 O que é e para que serve um modelo relacional? 77
4.2 Vantagens e desvantagens de se usar um modelo relacional 89
4.3 Criação e manutenção de um modelo relacional 92
4.4 Tipos de modelos relacionais 97
5 Projeto de banco de dados 100
5.1 O que é e para que serve o projeto de banco de dados? 100
5.2 Vantagens e desvantagens de se fazer um projeto de banco de 
 dados 103
5.3 Criação e manutenção de um projeto de banco de dados 114
5.4 Tipos de projetos de bancos de dados 123
6 Linguagem estruturada para consultas 126
6.1 O que é e para que serve a SQL? 127
6.2 Vantagens e desvantagens de se usar a SQL 130
6.3 Criação e manutenção de uma SQL 133
6.4 Tipos de SQL 146
7 Gabarito 149
O desenvolvimento de novos sistemas de informação 
corporativos, para uso pessoal e até de aplicativos para 
celulares (apps) tem exigido – com grande frequência e dos 
programadores – o conhecimento de técnicas de criação e 
manipulação dos bancos de dados. Qualquer sistema, por mais 
simples que seja, em algum momento terá a necessidade de 
criar, manter e consultar determinado tipo de dado. 
A evolução das tecnologias de armazenamento, manipulação 
e consulta a fontes de dados criou um conjunto específico de 
conhecimentos dentro da área de informática, que se chama 
banco de dados (BD). Esse é o tema que abordaremos nesta 
obra, preparando você para poder compreender e se aprimorar 
nessa nova área de conhecimento.
No Capítulo 1, conheceremos a importância do uso de um 
BD como fonte de dados para sistemas, como um banco de 
dados é criado e quais são os benefícios que podemos obter de 
sua utilização. Você conhecerá um universo de informações que 
lhe permitirá prosseguir no estudo desse rico conteúdo.
No Capítulo 2, ao compreendermos o papel que um BD 
poderá ter para os sistemas de informação, será possível 
conhecermos os sistemas gerenciadores de bancos de dados 
(SGBDs), programas criados para gerenciar os bancos de dados. 
Existem diferentes abordagens de sistemas gerenciadores de 
bancos de dados, as quais incorporam diferentes recursos e 
restrições de uso. Os SGBDs podem exigir diferentes requisitos, 
e podem, ou não, atender às necessidades conforme o tipo de 
projeto a executar.
No Capítulo 3, iniciaremos o caminho rumo à construção 
de um banco de dados. O processo de criação de um BD 
não é intuitivo e livre; ele conta com uma metodologia ou um 
processo padronizado/estruturado para transportar requisitos 
de informação de acordo com as necessidades de um sistema. 
Nesse sentido, a criação de um modelo de dados conceitual é o 
alicerce de todo o processo de construção de um BD. O modelo 
APRESENTAÇÃOVídeo
de dados representa algo como o desenho da planta baixa de uma casa: ele 
não é a casa, mas a representa. Assim, o modelo de dados não é o banco de 
dados, mas o representa por intermédio de um diagrama.
Ao sabermos como construir um modelo de dados, estaremos preparados, 
no Capítulo 4, para converter esse diagrama inicial em um modelo lógico 
relacional, base do projeto do banco de dados. Conheceremos os requisitos 
do modelo relacional – as vantagens e desvantagens em utilizá-lo – e 
aprenderemos o método de conversão de um modelo de dados conceitual 
em um modelo de dados relacional. As regras de conversão são apresentadas 
para que os requisitos do modelo relacional possam ser atendidos e, 
finalmente, construir o banco de dados.
No Capítulo 5, ao termos um modelo de dados relacional definido, 
poderemos, enfim, projetar o BD, dando origem a um modelo físico, no qual 
todos os detalhes para a alocação física de uma estrutura de dados seja 
feita. Para tanto, é necessário conhecer mais alguns requisitos e conceitos 
que poderão proporcionar um desempenho adequado para o acesso aos 
dados.A aplicação desses elementos garante maior flexibilidade para o 
compartilhamento dos dados e atendimento aos requisitos de inserção, 
de atualização e de consulta aos dados, feitas por um ou mais sistemas 
de informação. Essa é a última etapa da construção de um BD; com base 
nesse ponto, é possível ter um banco de dados projetado e pronto para ser 
construído. 
No Capítulo 6, conheceremos a Structured Query Language (SQL), 
linguagem criada especificamente com a finalidade de prover meios de 
interação com o banco de dados. Ao ter em mãos o projeto físico finalizado, é 
possível construir o BD por meio de comandos SQL, os quais permitirão criar 
banco de dados, tabelas dentro do BD e colunas dentro destas, bem como 
armazenar, atualizar, excluir e consultar conteúdos. Além disso, conheceremos 
algumas sintaxes dessa rica linguagem de acesso a dados, como ela pode ser 
incorporada nos programas hospedeiros – em que lugar a SQL será agregada 
para permitir o acesso ao BD –, benefícios de seu uso, entre outros.
Com todo esse conteúdo, você participará de uma jornada que começa 
com os primeiros conceitos, passa por métodos de construção de modelos 
de dados – conceituais, lógicos ou físicos – e chega, por fim, à construção e 
manipulação dos dados dentro de um BD. 
Esperamos que você tenha uma gratificante experiência com a leitura 
desta obra. Bons estudos!
Introdução a banco de dados 9
1
Introdução a banco de dados
Neste capítulo, vamos conhecer alguns conceitos essencial-
mente importantes para a adoção de estruturas de bancos de 
dados como elementos de suporte providos para os sistemas de 
informação. Atualmente, a ideia de iniciar a criação de um sistema 
de informação ou de um app sem considerar a adoção de um ban-
co de dados como elemento de sustentação para os dados que 
serão manuseados por esse sistema é pouco aceita. O uso do ban-
co de dados é amplamente difundido e não é mais questionado.
Contudo, o fato de essa estratégia ser amplamente aceita não 
significa que é dispensável ter conhecimento dos fatores que levam 
a tal escolha. Talvez, em alguma situação particular, essa escolha 
possa ser reavaliada. Nesse sentido, é necessário ter conhecimen-
tos dos chamados critérios de avaliação.
Desse modo, vamos conhecer os principais conceitos e as fun-
ções envolvidas no processo de adoção dos bancos de dados. Esse 
será um importante ponto de partida para nossa jornada rumo à 
implantação desses mecanismos em nossos sistemas.
1.1 O que é e para que serve um banco de dados? 
Vídeo Quando tratamos de banco de dados, muitas vezes a primeira dúvi-
da que surge é se estamos falando de um software, de uma tecnologia, 
de um arquivo físico, de um conjunto de dados ou de um método de 
organização de dados.
O termo banco de dados tem sido amplamente usado para designar 
todos esses elementos citados. Ele, às vezes, é visto como um software, 
como uma tecnologia, como um arquivo físico, como um conjunto de da-
dos, ou, ainda, como um método de organização de dados. Entretanto, 
existem diferenças entre cada abordagem, as quais elencamos a seguir.
10 Banco de Dados I
1.1.1 Dados
Primeiramente, antes de definir o que são dados, pensemos: por que 
frequentemente é utilizado o termo informação em substituição ao termo 
dado? Você provavelmente já ouviu alguém dizer: “precisamos levantar as 
informações sobre essa pessoa” ao invés de “precisamos levantar os da-
dos sobre essa pessoa”. Seriam dados e informações a mesma coisa?
Dados são elementos gerados pelo registro de fatos ou de características 
de objetos/coisas. Eles permitem que possamos identificá-los, reconhecê-
-los, mapeá-los e representá-los. Os dados são inerentes aos elementos que 
representam, isto é, dados não são criados, mas sim capturados da obser-
vação desses objetos no mundo real. Quando olhamos para um objeto, o 
reconhecemos por suas características. Essas características podem ser ma-
peadas como dados de um objeto. Veja um exemplo a seguir.
Se observarmos uma pessoa (objeto), podemos identificar dados como:
Figura 1
Modelo de dados da entidade “Pessoa”
PESSOA
• nome
• data de nascimento
• altura
• peso
Fonte: Elaborada pelo autor.
Fonte: Elaborada pelo autor.
Já se observarmos um casamento – fato que envolve duas pessoas 
–, podemos também identificar dados relativos a esse evento (e não a 
pessoas).
Figura 2
Modelo de dados da entidade “Casamento”
CASAMENTO
• Data
• Horário
• Regime de comunhão de bens
• Tipo de decoração
Fonte: Elaborada pelo autor.
Com base nessas informações, temos o ponto de partida para criar 
um banco de dados. Para tanto, é necessário primeiramente identi-
ficar os objetos e fatos de interesse, e depois elencar os dados que 
pertencem a eles. Esse processo será visto detalhadamente quando 
abordarmos a modelagem de dados.
Introdução a banco de dados 11
1.1.2 Informação
Informações são elementos e conclusões geradas por meio da ma-
nipulação dos dados que dispomos. A informação é o dado trabalha-
do, isto é, o dado traduzido. A manipulação dos dados pode envolver, 
comparar, apresentar, separar e formatar dados; já a transformação 
pode envolver, somar, subtrair e contar dados. A figura a seguir sinte-
tiza esses processos:
Figura 3
Processo de transformação de dados em informações
Lista de dados mapeados
Processo de manipulação 
 ou transformação
Informações produzidas 
pela transformação
Fonte: Elaborada pelo autor.
Se ao transformar um dado pode-se gerar uma informação, isso signi-
fica que diferentes transformações de um mesmo dado podem gerar dife-
rentes e diversas informações. Nesse sentido, é importante ter o cuidado 
de guardar dados, não sendo necessário guardar informações, pois essas 
últimas não precisam ser guardadas, uma vez que podem ser geradas.
Como já citado, podemos gerar os seguintes dados para uma pessoa: 
nome, data de nascimento, altura e peso. Porém, quais informações po-
demos formar com esses dados? A figura a seguir ilustra essa questão:
Figura 4
Transformação de um dado em várias informações
Data de nascimento Transformação ou 
manipulação
Signo do zodíaco
Idade
Pessoa viva ou morta?
Transformação ou 
manipulação
Pessoa alta ou baixa 
(conforme a idade)
Índice de Massa Corporal
(risco de enfarte)
Altura
Peso
Data de nascimento
Fonte: Elaborada pelo autor.
12 Banco de Dados I
Observando a figura, não seria correto criar um campo no banco de 
dados para guardar a informação “idade” ou “signo” de uma pessoa? O 
correto seria simplesmente guardar o dado sobre a data de nascimen-
to e, por meio dele, gerar essas informações.
Desse modo, seria razoável guardar a informação “idade” no banco 
de dados? Quantos de nós já preenchemos uma ficha cadastral num 
hotel ou em uma loja em que nos foi perguntado: “qual a sua idade?” 
e “qual a sua data de nascimento?”. Geralmente, preenchemos os dois 
campos no formulário, e esses, muito provavelmente, serão digitados 
e guardados em algum banco de dados.
Há também outras situações menos aparentes, que levam as pes-
soas a criarem informações (e não dados) em um banco de dados. Es-
ses indivíduos pensam estar guardando dados, mas na verdade estão 
guardando informações. Portanto, sempre se pergunte: isto é um dado 
ou uma informação que poderia ser obtida por meio de outro dado?
A preocupação com a identificação do que realmente é um dado e 
do que são informações foi originada justamente quando os antigos 
arquivos usados para sustentar os sistemas de informação passaram a 
ser substituídos por bancos de dados.
1.1.3 Arquivos e bancos de dados
Qual a diferença entre a antiga abordagem de arquivos e a nova 
abordagem de bancos de dados?
Historicamente, quando surgiram os primeiros sistemas de infor-
mação, ainda na década de 1950, não existia muita preocupação com 
esse aspecto, pois o processamento de dados realizado era baseado 
em arquivos sequenciais, frequentemente armazenados em fitas mag-
néticas. O custo de unidades de disco era extremamente alto e suascapacidades de armazenamento eram extremamente baixas. A capaci-
dade de armazenamento de um simples aparelho de celular não estava 
sequer disponível nos discos magnéticos das maiores corporações, que 
tinham processamentos feitos em seus mainframes.
Por esse motivo, os sistemas construídos agrupavam os dados (e 
muitas vezes as informações) já prontos de modo bastante orientado 
para o resultado que deveriam produzir. Em resumo, um arquivo era 
construído para uma aplicação específica, evitando que fosse necessá-
mainframes: computadores de 
grande porte.
Glossário
Introdução a banco de dados 13
rio muito processamento ou muito trabalho para obtenção dos resul-
tados esperados.
No exemplo mencionado, se guardássemos a data de nascimento, 
poderíamos gerar automaticamente o signo da pessoa. Contudo, isso 
consumiria recursos, pois teríamos que executar, cada vez que essa 
informação fosse necessária, uma tabela de classificação de signos, es-
tabelecida de acordo com o dia e mês de nascimento. Essa ação geraria 
o consumo de processamento, de tempo e de memória, portanto de-
veria ser evitada.
Com o crescimento de recursos de hardware e sua equivalente redu-
ção de custos, bem como o surgimento de estruturas de armazenamento 
e processamento com melhor performance, a busca de um modelo de 
dados mais preciso (sem guardar informações) passou a ser viável.
Por outro lado, a proliferação de arquivos criados especificamente 
para atender à demanda de cada um dos sistemas de informação cria-
va outros problemas, embora resolvesse o das restrições de hardware. 
Essas dificuldades talvez tivessem impactos maiores, porém, não po-
diam ser evitadas, em virtude das limitações técnicas da época.
Ao surgirem as primeiras alternativas baseadas em estruturas de 
banco de dados, a adesão foi quase que imediata. As antigas estruturas 
de arquivos sequenciais passaram a ser substituídas por estruturas de 
banco de dados, trazendo inúmeros benefícios.
Criava-se, então, uma nova era: a era dos bancos de dados, isto é, 
a era dos sistemas de informação desenvolvidos com bases de dados 
e não mais com arquivos. Esses bancos ainda não eram os atuais que 
conhecemos hoje, mas já apresentavam diferenciais e facilidades.
Ao tratarmos de banco de dados, três características são sempre 
destacadas. Elas devem ser observadas e buscadas para que o agrega-
do de dados que se crie possa ser chamado de banco de dados, a saber 
(NAVATHE; ELMASRI, 2005):
 • Um banco de dados deve representar uma porção de um mun-
do real.
 • Os dados em um banco de dados devem ser logicamente coerentes.
 • Os dados e o próprio banco de dados devem ter uma finalidade 
específica.
A obra Sistemas de Bancos de Dados, 
de Ramez Elmasri e Shamkant 
Navathe, atualmente em sua sétima 
edição, tem sido considerada uma 
fonte de referência, em virtude 
de apresentar grande parte dos 
conceitos associados ao banco 
de dados. 
NAVATHE, S.; ELMASRI, R. São Paulo: 
Pearson, 2012.
Livro
14 Banco de Dados I
A primeira característica – porção do mundo real – diz respeito ao 
fato de que o processo de modelagem de dados, que dará origem ao 
banco de dados, deve ser feito com base na observação de um escopo 
definido e se preocupar em capturar as propriedades e características 
(dados) reais dos elementos observados nesse ambiente. Isso assegu-
ra que somente os dados reais dos elementos sejam armazenados no 
banco de dados, isto é, não teremos informações armazenadas, uma 
vez que elas não são observadas no mundo real, mas sim inferidas por 
meio de transformações.
Além disso, essa primeira característica procura estabelecer o fato 
de um banco de dados ser incompleto, ou seja, não ter todos os dados 
de todos os elementos de um mundo observado. Isso não é um defeito, 
mas sim uma situação esperada, pois não somos obrigados a mapear 
todos os dados de todos os elementos, mas somente aqueles que no 
momento nos sejam necessários ou úteis. A Figura 5, a seguir, mostra 
um exemplo dessa questão:
Figura 5
Seleção da porção do mundo real a ser mapeada
Data de nascimento
Tipo sanguíneo 
Peso
Altura
Data de nascimento
Pressão arterial
Peso
Nome
Altura
Temperatura
Nome
Seleção
Fonte: Elaborada pelo autor.
No exemplo da Figura 5, elencamos alguns poucos dados. Entretan-
to, sabemos que uma pessoa tem muito mais dados que poderiam ser 
observados, como tipo sanguíneo, pressão arterial e temperatura. Po-
rém, de que serviriam esses dados no nosso banco se o que desejamos 
é criar um BD 1 para processamento da folha de pagamentos de uma 
empresa? Para que serviria conhecer o tipo sanguíneo de um funcioná-
rio para gerar sua folha de pagamento?
Comumente, utilizaremos a 
sigla “BD” para nos referirmos ao 
banco de dados.
1
Introdução a banco de dados 15
Dessa forma, delimitar o escopo dos objetos observados, bem como 
o escopo dos dados a serem mapeados para cada um desses objetos 
não é um defeito, mas um objetivo do processo.
A segunda característica – dados coerentes – diz respeito ao fato 
de que somente reunir dados delimitados de alguns objetos observa-
dos em um mundo real não é suficiente. É necessário que os dados 
sejam logicamente coerentes, isto é, que exista a correlação entre os 
dados de diferentes objetos. Além disso, é necessário que esses dados 
tenham (e mantenham com o passar do tempo) uma integridade com 
os fatos do mundo real, que não existam dados iguais com nomes di-
ferentes (mapeados de modo repetido), que não sejam dados que se 
contradigam e que não existam dados representados em objetos aos 
quais eles não pertençam.
Para entendermos essas questão, voltemos ao exemplo no qual 
mapeamos dois objetos (pessoa e casamento) e vamos aprimorá-lo 
com base nesse novo requisito.
Ao observar os dados já mapeados, podemos perceber que existe 
a necessidade de agregar alguns novos dados ao objeto “casamento”: 
o nome dos noivos. Isso irá enriquecer o modelo e também o tornará 
mais real, uma vez que um casamento sem noivos seria no mínimo 
estranho. Passaríamos a ter, desse modo, em nosso BD, os seguintes 
dados:
Figura 6
Mapeamento dos dados das entidades “casamento” e “pessoa”
CASAMENTO
• Data do evento
• Horário 
• Regime de comunhão de bens
• Tipo de decoração
• Nome do noivo
• Nome da noiva
PESSOA
• Nome
• Data de nascimento
Fonte: Elaborada pelo autor.
Ao realizarmos essa ação, aparentemente teríamos um melhor ma-
peamento dos dados do casamento. Contudo, se pretendemos ter um 
BD com dados coerentes, devemos assegurar, de algum modo, que to-
16 Banco de Dados I
dos os nomes armazenados nos campos “nome do noivo” e “nome da 
noiva” também existam no campo “nome” do objeto “pessoa”, mapea-
do anteriormente.
Se tivermos um nome de noivo ou de noiva que não apareça tam-
bém no objeto “pessoa”, como faríamos para descobrir a data de nas-
cimento desse noivo ou dessa noiva no futuro? Essa ação demonstra 
uma interdependência entre os dados do casamento e os dados das 
pessoas. Porém, de modo contrário, se tivermos nomes de pessoas 
que não apareçam nenhuma vez nos nomes de noivos e noivas, não 
teríamos uma situação de falta de coerência, seriam simplesmente 
pessoas que ainda não se casaram.
Essas situações nos fazem pensar em regras de coerência – ou re-
gras de negócio – que determinam o que pode ou não ocorrer entre os 
dados interdependentes. Nesse exemplo, poderíamos estabelecer que:
 • nem todas as pessoas precisam ser noivos ou noivas;
 • um noivo ou uma noiva precisa ser uma pessoa; e
 • um casamento não pode ocorrer somente com o noivo ou so-
mente com a noiva.
Essas regras serão importantes para estabelecer os relacionamen-
tos entre os objetos do modelo (que são chamados de entidades).
E a terceira característica é o fato de os dados atenderem a uma 
finalidade específica. Tanto o escopo dos objetos observados quanto 
a amplitude do mapeamento desses objetos, o modo de mapeamento, 
a quantidade de dados a serem povoados nessa base de dados e o 
modo como serão compartilhadosos dados entre as aplicações podem 
depender da finalidade do banco de dados.
Em nosso exemplo, estamos criando um banco de dados de casa-
mentos. Mas qual será o universo de casamentos a ser abrangido por 
esse BD? Somente os casamentos realizados em uma determinada 
cidade? Casamentos de todo um estado? De todo um país? E o com-
partilhamento desses dados será somente com um seleto grupo de 
pessoas? Ou será um sistema público que deverá ser compartilhado 
com todos os cidadãos?
As respostas para todas essas perguntas podem mudar o modo 
como o banco de dados será estruturado, onde será armazenado, qual 
o mecanismo de validação de acesso que deverá ser provido, qual a 
Introdução a banco de dados 17
quantidade de registros de dados que conterá, como serão divididos 
os casamentos de cada diferente país, estado, cidade, entre outros. Em 
resumo, um pequeno BD de casamentos feitos em uma cidade ou um 
enorme BD de casamentos feitos em todo o mundo poderão requerer 
características diferenciadas.
1.1.4 Banco de dados e sistema gerenciador de 
banco de dados: diferenças
Outro ponto que merece distinção quando tratamos de bancos de 
dados é o fato de que para capturar, armazenar, manipular e disponibi-
lizar dados mapeados e definidos em um BD é necessário o uso de um 
software construído especificamente para essas funções.
Esse software – que permite que os sistemas de informação intera-
jam com o banco de dados – é denominado SGBD ou sistema gerencia-
dor de banco de dados. O SGBD não é o banco de dados, ele é o sistema 
que gerencia o BD por meio de diversas funções, a saber:
 • criar o banco;
 • criar tabelas e colunas que vão compor o banco;
 • definir os usuários que poderão ter acesso aos dados;
 • fornecer o acesso para consulta e atualização dos dados;
 • realizar cópias de segurança dos dados;
 • monitorar a performance do banco de dados;
 • permitir a execução de rotinas de compactação de espaço físico.
Existem vários fabricantes de SGBD no mercado, cada um com ca-
racterísticas distintas. Entretanto, de modo geral, todos disponibilizam 
um conjunto comum de recursos voltados à criação e à manutenção do 
banco de dados.
Com base nos padrões internacionais estabelecidos pela ANSI (Ame-
rican National Standard Institute) 2 , temos hoje uma grande compatibi-
lidade entre os diversos SGBDs existentes, principalmente no tocante 
aos recursos que eles fornecem para que os sistemas de informação 
possam interagir. Podemos dizer que atualmente possuímos um pa-
drão de linguagem de programação para acesso ao banco dados (com 
pequenas exceções).
Para conhecer o trabalho da 
ANSI, visite: https://www.ansi.
org/. Acesso em: 19 fev. 2020.
2
18 Banco de Dados I
1.1.5 Sistemas de informação
Temos tratado até aqui, por diversas vezes, de sistemas de informa-
ção como elementos de acesso ao banco de dados. Mas o que são efe-
tivamente os sistemas de informação e por que se denominam assim?
Como vimos anteriormente, um dado pode produzir diversas in-
formações por meio de transformações que venha a ser submetido. 
Quem executará essas transformações serão conjuntos de programas, 
rotinas e funções, que juntos comporão um sistema de informações.
Podemos afirmar que qualquer conjunto de funções que manuseie 
e transforme dados é um sistema de informação. Assim, um simples 
app de um smartphone que realize o controle de gastos para geren-
ciá-los pode ser um sistema de informações. Mas e o banco de dados, 
onde estará? É necessário ter um SGBD no smartphone? Não necessa-
riamente. Podemos ter um banco de dados sem um SGBD, com es-
truturas mais simples de manuseio de dados. Porém, se estivermos 
tratando de um sistema corporativo de gestão de finanças, muito pro-
vavelmente, pela complexidade e extensão dos dados a se manusear, 
faz-se necessária a presença de um SGBD.
1.1.6 Evolução das estruturas de dados
Os sistemas de informação sempre tiveram suas demandas de aces-
so e armazenamento de dados providas por algum tipo de estrutura de 
dados, mesmo antes da existência dos SGBDs. Naturalmente, com a 
evolução da tecnologia, a disponibilidade de recursos de hardware e as 
novas demandas por maiores facilidades para produção de programas 
que interagissem com os bancos dados, o mercado passou a oferecer 
alternativas mais complexas e com melhores recursos.
Figura 7
Surgimento das tecnologias para dados
Anos 1950 Anos 1960 Anos 1970 Anos 1980 Anos 1990
Sistemas 
de arquivo
BD
Hierárquico
BD
Rede
BD
Relacional
BD
Pós-relacional
Fonte: Elaborada pelo autor
Introdução a banco de dados 19
Durante a década de 1950 e até o início da década de 1960, a es-
trutura de dados predominante era a dos sistemas de arquivo, primei-
ramente sequenciais (na qual, para ler um registro de número 3, era 
necessário primeiramente ler o registro de número 1 e, em seguida, o 
de número 2), e, depois, também indexados – que permitiam acesso di-
reto a um registro sem necessidade de ler todos os registros anteriores.
Já no final da década de 1960, ocorreu o surgimento dos primeiros 
SGBDs que já implementavam um modelo hierárquico de acesso aos da-
dos como uma derivação dos mecanismos de acesso indexados, no qual 
coleções de arquivos eram reunidas e gerenciadas de modo integrado.
Durante a década de 1970 e início da década de 1980, houve a pre-
dominância dos SGBDs em rede, estrutura de organização e recupera-
ção de dados baseada em vínculos criados entre os registros por meio 
de ponteiros 3 . Voltando ao exemplo, se em um casamento há duas 
pessoas envolvidas, o registro do casamento no banco de dados apon-
ta, por meio de ponteiros, para os registros que contêm os dados da 
“pessoa 1” e da “pessoa 2”, as quais fazem parte do conjuntos de pes-
soas. Uma estrutura de encadeamento circular de dados faz o vínculo 
de armazenamento e de recuperação de dados.
Em meados da década de 1980, o mercado de SGBD passou a ser 
dominado pelos SGBDs relacionais, baseados em uma estrutura de ar-
mazenamento de dados em tabelas, com linhas e colunas, e utilizando 
operações relacionais (com origem na teoria dos conjuntos) para recu-
peração dos dados armazenados nesses conjuntos de dados (tabelas).
Por fim, ainda na década de 1980 surgiram os SGBDs orientados 
a objetos relacionais ou pós-relacionais. Esses SGBDs foram adap-
tados aos novos requisitos das linguagens orientadas a objetos e 
às novas demandas de armazenamento de dados complexos – ima-
gens, diagramas, documentos. Nesse sentido, houve a implementa-
ção de novas estruturas de armazenamento e recuperação de dados 
com estruturas complexas.
É importante considerar que o surgimento de uma nova abordagem 
de estrutura de BD não significa que a abordagem anterior deixe de 
existir. Assim, ainda há muitos sistemas que até hoje preservam estru-
turas de arquivo ou de bancos de dados hierárquicos 4 .
Ponteiros são campos inseridos 
no banco de dados para 
referenciar um outro registro 
também existente nesse mesmo 
banco dedados, criando um 
apontamento.
3
Veremos os diferentes tipos de 
BDs ainda neste capítulo.
4
20 Banco de Dados I
1.1.7 Administração de dados
Com o crescente uso de SGBDs pelos sistemas de informação – prin-
cipalmente nas grandes corporações – e com o aumento da complexi-
dade das estruturas dos BDs, surgiu a necessidade de implementação 
de uma nova categoria de profissionais que tivessem a capacidade de 
criar, manter e administrar os modelos de dados de modo eficiente.
Essa categoria de profissionais passou a ser denominada de admi-
nistradores de dados. Sua função não era ligada diretamente ao SGBD, 
mas sim a aspectos conceituais e lógicos envolvidos nos modelos de da-
dos criados. Se o modelo de dados daria origem a um banco de dados 
relacional ou a um banco de dados em rede, era uma decisão técnica 
que cabia a outro profissional, o administrador do banco de dados.
Dentre as funções do administrador de dados podemos elencar:
 • identificar as fontes de dados da organização;
 • mapear os dados identificados;• estabelecer relacionamentos entre os dados de modo coerente;
 • definir a utilização dos dados e a propriedade dos dados, isto é, 
quem deve mantê-los; e
 • identificar redundâncias e inconsistências nos dados e tratá-las.
Essas funções envolvem a gestão de dados independentemente de 
qualquer implementação física de um banco de dados. Pode parecer 
estranho, mas é possível executar as funções de administrador de da-
dos mesmo em empresas que jamais tenham um SGBD e um sistema 
de informação que use esses dados. Os dados existentes em formulá-
rios, documentos e planilhas podem fazer parte das tarefas do admi-
nistrador de dados.
1.1.8 Administração de banco de dados
Se o administrador de dados não tinha funções ligadas ao SGBD, 
um profissional deveria ser designado para executar essas funções. Foi 
assim que surgiu a figura do administrador de banco de dados. Esse 
sim é um profissional diretamente ligado ao SGBD e que, portanto, 
tem que conhecer os aspectos técnicos específicos para implementar o 
banco de dados mapeado pelo administrador de dados.
Introdução a banco de dados 21
Esses dois profissionais têm papéis complementares: um modela ou 
prepara a estrutura nativa dos dados, o outro implementa essa estru-
tura utilizando recursos do SGBD. Em empresas com equipes menores, 
um mesmo profissional pode assumir essas duas funções simultanea-
mente. Já em empresas com equipes mais especializadas é comum 
existir separadamente um administrador de dados e um administrador 
de banco de dados, uma vez que as competências são diferenciadas.
Como o administrador de banco de dados tem interação direta com 
o SGBD, é necessário que esse profissional possua um perfil bastante 
técnico e com formação específica e treinamentos para conhecer os 
recursos do SGBD escolhido. Como cada fabricante de SGBD tem suas 
particularidades, muitas vezes o conhecimento prévio pode não ser su-
ficiente. Além disso, o suporte ao uso do SGBD para os programadores, 
os analistas e as tratativas de problemas encontrados durante o uso 
são tarefas do administrador de banco de dados e não do administra-
dor de dados.
São tarefas de um administrador de banco de dados:
 • transformar o modelo de dados conceitual em modelo lógico;
 • definir o esquema interno do BD (usando a linguagem do SGBD);
 • realizar o suporte aos programadores e analistas;
 • implementar as restrições de segurança e integridade no SGBD;
 • monitorar o desempenho e responder a requisitos de mudanças;
 • definir normas de descarga e recarga do banco de dados (backup);
 • executar procedimentos operacionais no banco de dados.
1.2 Vantagens e desvantagens do 
uso de um banco de dados Vídeo
A adoção de uma abordagem baseada em bancos de dados não 
é somente uma escolha técnica ou uma imposição da evolução tec-
nológica que aconteceu nos últimos anos. O Quadro 1, a seguir, elen-
ca as principais vantagens do uso de bancos de dados (DATE, 2004; 
SILBERSCHATZ, KORTH, SUDARSHAN, 2012).
22 Banco de Dados I
Quadro 1
Vantagens do banco de dados
Compartilhamento 
dos dados
O objetivo principal de um BD é reunir um conjunto de dados de modo coerente para 
disponibilizá-lo a um grande contingente de aplicações, as quais poderão, então, compartilhar 
esses dados. Se tivermos, por exemplo, os dados de pessoas armazenados em um BD, 
poderemos compartilhá-los com todas as aplicações que de algum modo precisem acessar 
ou atualizar dados, como “nome” e “data de nascimento”. Esse compartilhamento, segundo 
Heuser (2009), reduz o custo total de propriedade dos dados, isto é, o custo total para obter, 
manter e usar dados.
Facilidade de acesso 
aos dados
Ao utilizar um SGBD para manter um BD, passa-se a ter um método de acesso único, provido 
também por meio de uma linguagem estruturada (SQL – linguagem padrão para banco de 
dados relacionais) que padroniza e facilita o reaproveitamento de códigos gerados para 
interação com o banco de dados. Se cada aplicação tivesse o seu próprio arquivo, seria possível 
ter diferentes métodos de acesso e haveria dificuldades para compartilhar códigos e funções já 
criadas em outros sistemas.
Redução da 
redundância
Considerando uma estruturação coerente de dados e o objetivo de compartilhamento, há de 
se obter, naturalmente, um BD em que a redundância de dados seja bastante reduzida ou até 
inexista. Com a redundância sob controle, é possível produzir indiretamente outros benefícios, 
como, novamente, a redução do custo de propriedade dos dados.
Redução das 
inconsistências
Ao criar um conjunto de dados coerente, integrado e que tenha baixa ou nenhuma 
redundância, tem-se, naturalmente, a redução das possíveis inconsistências entre os dados 
existentes no BD. O estabelecimento de regras de criação, de atualização e até de exclusão de 
dados, dentro de critérios coerentes, irá permitir, por exemplo, que não tenhamos “casamentos” 
referenciando nomes que não existam no conjunto de dados de pessoas.
Disponibilidade de 
suporte a transações
Os SGBDs e as linguagens de programação que eles dispõem para a construção de funções 
de acesso, atualização e exclusão de dados proveem meios para que o acesso concorrente 
(simultâneo) de diversos programas possa ser feito a um mesmo dado sem que este 
apresente um conteúdo não íntegro.
Manutenção da 
integridade
Havendo um controle de transações, uma redução de redundância, uma redução de 
inconsistências e um modelo de dados coerente, poderemos assegurar que o banco de 
dados terá seus dados íntegros, isto é, conseguiremos manter a coerência dos dados 
planejada, mesmo que diversos programas e usuários simultaneamente estejam executando 
rotinas de inclusão, alteração e exclusão de dados. Isso será assegurado por recursos do 
próprio SGBD, no qual se pode estabelecer regras de integridade que serão sempre aplicadas 
sobre cada transação executada no BD.
Balanceamento de 
requisitos 
conflitantes
Como as várias transações concorrentes requisitarão atualizações e consultas sobre os mesmos 
dados, poderá ocorrer situações em que um mesmo dado acabe sendo requisitado de modo 
conflitante. O ambiente de banco de dados estará preparado para tratar dessas situações e 
resolvê-las de modo automático, sem que o programador precise se preocupar em escrever 
rotinas especiais.
(Continua)
Introdução a banco de dados 23
Melhoria da 
segurança
Outro importante recurso disponível nos SGBDs são os diversos mecanismos de controle de 
segurança para acesso e para atualização dos dados do BD. Tanto as permissões que definem 
quem pode ou não acessar um dado quanto os mecanismos de garantia das atualizações feitas 
no BD (redo log) irão contribuir para a segurança lógica e física dos dados. Pode-se limitar o acesso 
de uma pessoa ou um sistema a todo um conjunto de dados (uma tabela inteira) ou a somente 
parte dos dados (algumas colunas ou linhas da tabela) por meio da criação de visões de dados.
Utilização de 
padrões
A unificação dos dados em um mesmo BD gera também uma padronização de formatos, 
de regras de atualização e até de conteúdos. Quando existe redundância, podemos ter 
eventualmente o mesmo dado representado em formatos diferentes e com regras de 
atualização diferentes. A centralização de controle dos dados pelo administrador de dados 
pode assegurar que um maior nível de padronização seja criado.
Fonte: Elaborado pelo autor com base em Date, 2004; Silberschatz, Korth, Sudarshan, 2012.
Apesar de todas as características positivas na adoção de uma es-
trutura de banco de dados, temos que estar atentos a algumas pe-
culiaridades que podem trazer desvantagens ao seu uso, as quais 
descrevemos a seguir.
Quadro 2
Desvantagens do banco de dados
Perda de autonomia 
sobre os dados
Quando tratamos de centralização, 
seja de dados, de processos, 
de pessoas, de equipamentos, 
temos naturalmente a perda de 
autonomia sobre esses mesmos 
itens. Quando determinado dado 
é definido, criado, atualizado ou 
excluído e compartilhado com 
outras aplicações,é necessário 
realizar essas operações ciente de 
que outras pessoas podem vir a 
ser impactadas. Se, por exemplo, 
ao resolver mudar o número de 
identificação de 6 dígitos para 7 
dígitos, porque o sistema requer 
esse novo tamanho, qual será o 
impacto nos demais sistemas que 
já usam esse código? Talvez a troca 
não seja tão fácil como seria em um 
arquivo individual.
Interdependência 
entre os dados
A interdependência criada pela 
centralização dos dados também 
poderá afetar, de certo modo, 
determinada aplicação ou a 
aplicação de terceiros. No caso de 
somente um arquivo próprio, com 
os dados que o sistema requer, 
talvez esse arquivo nunca fosse 
impactado por outro sistema que 
resolvesse inserir outras 200 mil 
pessoas em um cadastro que tinha 
somente mil. Um BD que tinha 
somente os dados de “pessoa” e 
de “casamento” em poucos meses 
poderá ter dados de outros 100 
ou 200 objetos, relacionados com 
“pessoa” e com “casamento” de 
um modo não antes imaginado. 
Contudo, é importante lembrar que 
os dados não são mais individuais.
Sincronização dos 
dados no tempo
Imagine que foi atualizado todo um 
cadastro de pessoas, corrigindo os 
números de CEP das residências 
de cada um dos colaboradores. 
Em paralelo, outro programa foi 
executado por outra aplicação, 
mudando também os telefones dos 
colaboradores. Agora, imagine que, em 
razão de um problema no processo 
de atualização do CEP, todos os dados 
atualizados ficaram errados, sendo 
necessário voltar ao estágio anterior 
para reprocessar a atualização. Isso 
seria muito fácil de ser feito, caso 
não fosse compartilhado um BD 
com outras aplicações. É importante 
lembrar que os dados não são mais 
individuais e estar preparado para 
esse e outros tipos de situações em 
que a sincronização dos dados entre 
diferentes aplicações será dependente 
do tempo, ou de quando for feita.
Fonte: Elaborado pelo autor com base em Date, 2004; Silberschatz, Korth, Sudarshan, 2012.
24 Banco de Dados I
Ao analisar vantagens e desvantagens do uso de bancos de dados, 
pode-se perceber que os pontos positivos superam os pontos negati-
vos. Desse modo, o uso dessa abordagem é uma alternativa bastante 
viável para boa parte dos sistemas de informação.
1.3 Criação e manutenção de bancos de dados
Vídeo
O processo de criação de um banco de dados que será disponibili-
zado por meio de um SGBD, para uma ou mais aplicações, requer um 
formalismo para que tenha as três características citadas por Navathe 
e Elmasri (2005): porção do mundo real, logicamente coerentes e fina-
lidade específica.
É verdade que, em um primeiro momento, poderíamos abrir mão 
desse processo formal para criar um SGBD, mas o resultado seria, com 
o passar do tempo, a desestruturação dos dados. Muitas vezes, pela 
aparente simplicidade do processo de criação de estruturas de dados 
no SGBD (em função das ferramentas que ele fornece), pode-se pensar: 
“Por que não ir direto ao SGBD e criar as tabelas de que preciso?”. Nesse 
caso, é importante lembrar: os dados não são seus, são da organização.
Nesse sentido, apresentamos a seguir os passos que devem ser se-
guidos formalmente para ter um processo incremental de evolução do 
BD sem que ele perca sua integridade e sua coerência e para que não 
tenha redundâncias.
Mapeamento dos dados
A criação de um BD começa, como vimos, com o administrador de 
dados, que é quem conhece os dados da empresa. Esse profissional 
sabe onde os dados são gerados, quem é o responsável por sua atua-
lização, o que esses dados representam e qual padrão devem seguir. 
Desse modo, a primeira etapa na criação de um BD é identificar os 
dados envolvidos.
Para o administrador de dados, esses dados ainda não precisam ter 
a finalidade de formar um BD, eles poderiam simplesmente estar pre-
sentes na empresa. Mas esse profissional tem interesse em conhecê-
-los para que futuramente – caso alguém precise desse dado em um BD 
para sua aplicação – possa ofertá-los para compor o banco de dados.
Introdução a banco de dados 25
Isso significa que a criação de um banco de dados pode começar 
muito antes do surgimento da necessidade de um novo sistema ou de 
um novo aplicativo. Podemos perceber que se o administrador de da-
dos realmente cumprir o papel de mapear os dados da empresa, ele 
estará, na verdade, antecipando o trabalho dos futuros analistas de sis-
temas ou administradores de banco de dados no momento em que se 
tenha a demanda de criação de novos BDs.
Modelagem conceitual
O próximo passo a ser seguido na criação do banco de dados é rea-
lizar a modelagem conceitual dos dados que o escopo da demanda re-
quer. Como vimos, todo BD representa uma porção do mundo real em 
um dado momento. Precisamos, então, delimitar a nossa porção de 
mundo real e iniciar a modelagem conceitual desses dados.
Mas o que é a modelagem conceitual? Segundo Heuser (2009), ela é 
um processo de criação de uma representação gráfica e textual de basi-
camente dois elementos: as entidades e os relacionamentos. Esse pro-
cesso identifica os objetos ou fatos do mundo real a serem mapeados 
(as entidades) e os relacionamentos que existem entre esses objetos 
(por meio de regras). Em nosso exemplo, teríamos a entidade “pessoa” 
e a entidade “casamento” (que são os objetos e fatos) e a regra relacio-
namento, que seria “uma pessoa é noivo em um ou mais casamentos”.
Criando esse modelo, identificamos quais dados de quais entidades 
iremos necessitar, e o administrador de dados poderá nos dizer se já os 
conhece ou não. Se eles já foram mapeados anteriormente, obtém-se 
as informações sobre esse dado já disponível. Se não foram ainda ma-
peados, pode-se, com ajuda do administrador de dados, mapear novos 
dados corporativos, ou seja, que comporão o modelo em questão, mas 
que estarão disponíveis para toda a organização futuramente. Esse é o 
processo incremental e cíclico que gera um conjunto compartilhado e 
coerente de dados.
O que precisamos destacar é o fato de que o modelo conceitual, nes-
se momento, ainda é independente de um SGBD, ou seja, o modelo con-
ceitual não é relacional, não é rede e não é hierárquico. Ele representa os 
dados em sua estrutura inerente, sem preocupações com o que o SGBD 
irá futuramente exigir, como chaves, índices, tamanhos de campos etc.
Em Projeto de banco de 
dados, Carlos Heuser 
aborda temáticas 
conceituais de bancos 
de dados. Trata-se de 
uma obra introdutória 
e que precede a leitura 
de outros materiais mais 
densos.
HEUSER, C. A. 6. ed. Porto Alegre: 
Bookman, 2009.
Livro
26 Banco de Dados I
Modelagem lógica
Depois de finalizado o processo de modelagem conceitual, teremos 
uma estrutura gráfica e textual – algumas descrições e definições são 
feitas em texto complementando o gráfico – que será o modelo con-
ceitual. Esse modelo poderá ser derivado ou adaptado para um novo 
tipo, que é o modelo lógico.
Esse, segundo Heuser (2009), captura e incorpora os requisitos do 
SGBD escolhido para a criação do BD. Assim, caso seja escolhido o 
SQL-Server (SGBD fornecido pela Microsoft), será necessário adaptar 
o modelo conceitual aos requisitos de um banco de dados relacional, 
que são diferentes dos requisitos de um SGBD em rede (IDS-II) 5 . Muito 
mais do que requisitos impostos por fabricantes, são requisitos impos-
tos pelas arquiteturas dos bancos de dados. Desse modo, se a arquite-
tura escolhida é a de um BD relacional (e existem vários fornecedores 
no mercado), o modelo conceitual deverá ser adaptado aos requisitos 
do modelo relacional. Esse será um modelo lógico que praticamente 
servirá para qualquer SGBD relacional do mercado, com pequenas mu-
danças em relação a particularidades ou outras questões que um for-
necedor apresente.
Essa derivação de modelo será feita por meio de regras de conver-
são e não irá requerer muito tempo ou esforço. Muitas vezes, até pou-
cas mudanças acontecerão, pois muitas pessoas, ao construírem seus 
modelos conceituais, inconscientemente os criam com uma orientação 
para omodelo lógico – sabendo, por exemplo, que usarão um BD rela-
cional. Há também pessoas ou empresas que já iniciam a modelagem 
com o modelo lógico, dispensando o modelo conceitual, pois usam fer-
ramentas (softwares) que já são orientadas ao primeiro modelo. Isso 
é prejudicial? Não se pensarmos no resultado final do processo, que é 
gerar o modelo lógico, mas sim se pensarmos sob o ponto de vista da 
administração de dados.
Modelagem física
Após gerado o modelo lógico, que já está pronto para os requisitos do 
SGBD, chegamos à última etapa de construção do banco de dados, que é 
a modelagem física, também chamada de projeto do banco de dados.
Integrated Data Store II, SGBD 
produzido pela empresa francesa 
Bull.
5
Introdução a banco de dados 27
Segundo Heuser (2009), como em todo projeto, é nesse momento 
que detalhes, mecanismos de otimização, cálculos de ocupação de es-
paços, mecanismos de segurança, ente outros elementos são agrega-
dos. Até o ponto em que se tem o modelo lógico, não há preocupação 
com detalhes como:
 • Quantos registros serão armazenados em cada tabela?
 • Qual o tamanho de cada registro?
 • Qual será a necessidade de acesso a essa tabela? Eventual? 
On-line?
 • Como esse dado será compartilhado? Somente em um local? Na 
web?
Todas essas características precisam ser analisadas para que se crie 
uma estrutura física (realmente alocando espaço em disco em um ser-
vidor) para o banco de dados. Aqui, ele deixa de ser um modelo e passa 
a ser um repositório de dados.
Essa etapa do processo requer a participação do administrador de 
banco de dados, que também participa da etapa do modelo lógico, pois 
ambas as etapas requerem o conhecimento específico das característi-
cas do SGBD escolhido.
Dicionário de dados
É importante saber que todas as informações sobre o modelo de da-
dos conceitual – lógico e físico – deverão ser registradas em um reposi-
tório que chamamos de dicionário de dados. Nele temos registros de um 
determinado campo (por exemplo, “data de nascimento”), a saber:
 • A qual entidade pertence.
 • Como é alimentado.
 • Quando é atualizado.
 • Quem é o responsável pela criação.
 • Quem é o responsável pela atualização.
 • É um campo de preenchimento obrigatório?
 • Que conteúdo terá se não for preenchido? Uma data padrão?
 • Qual o formato? Tem só dia, mês e ano ou precisa de hora e 
minuto?
 • Por que foi escolhido esse formato? Existe uma norma que exige?
28 Banco de Dados I
Pode-se perceber que as informações coletadas na fase de modela-
gem conceitual, lógica e física estão aqui registradas. Elas servirão para 
o administrador de dados compartilhar futuramente esses dados, sa-
bendo de suas características previamente estabelecidas. As mudanças 
que venham a ocorrer nessas informações precisam ser divulgadas aos 
usuários desse dado – por exemplo, modificações na regra de preen-
chimento ou uma mudança de formato – para que eles avaliem os im-
pactos em suas aplicações.
Processos operacionais
Estando o BD criado fisicamente e pronto para uso, inicia-se a fase 
de definição e implementação de procedimentos operacionais de ad-
ministração do banco de dados. Entre esses processos temos:
 • monitoração do acesso aos dados;
 • monitoração da performance de acesso;
 • rotinas de salvamento (backup);
 • planos de recuperação e contingência para falhas no BD;
 • rotinas de compactação de dados (para redução do espaço em 
disco);
 • rotinas de criação e recriação de índices (melhoria de performance).
Todas essas rotinas são de responsabilidade do administrador de 
dados, que, após esse momento, passa a ter o BD como um recurso 
de compartilhamento de dados com a organização, e deve estar ciente 
dos impactos negativos que uma indisponibilidade desse recurso possa 
causar. Mesmo que em um primeiro momento o BD esteja sendo cria-
do para uma única aplicação, em breve ele estará sendo compartilhado 
com diversas aplicações e poderá ter níveis de disponibilidade diferentes 
para cada uma delas. Algumas, talvez, só o utilizem durante o dia, mas 
outras talvez requeiram disponibilidade de 24 horas por dia e 7 dias da 
semana. Tudo isso também deve estar mapeado no dicionário de dados 
e servirá de subsídio para que o administrador de banco de dados possa 
estabelecer suas rotinas operacionais de acordo com os requisitos.
Algumas das definições físicas poderão, com o passar do tempo, ser 
alteradas em razão de demandas de outras aplicações, mudanças de 
regras, normas da empresa ou até crescimento no volume de dados do 
BD. Logo, as tarefas dessa etapa serão continuamente executadas ao 
longo da vida do banco de dados.
Introdução a banco de dados 29
1.4 Tipos de bancos de dados
Vídeo O processo modelagem pode se aplicar, com pequenas adaptações, à 
construção de diferentes tipos de bancos de dados. Alguns desses tipos 
foram historicamente importantes e não são mais usados com frequên-
cia. Outros ainda têm usos isolados em aplicações desenvolvidas há mui-
to tempo, mas que se mantêm ativas, por exemplo, no setor bancário, 
o qual ainda preserva aplicações antigas, mas estáveis e em operação.
A seguir, relacionamos conceitos básicos de cada um desses tipos 
de bancos de dados, de modo a permitir, pelo menos, o reconhecimen-
to, a identificação de benefícios e possibilidades de aplicação.
1.4.1 Banco de dados hierárquico
Os bancos de dados hierárquicos foram os primeiros modelos de 
implementação de BDs derivados das estruturas de arquivos indexa-
dos. Eles já agregavam o conceito de reunir de modo único diferentes 
coleções de dados. Isso se diferenciava de um simples arquivo indexa-
do, que normalmente atendia a somente um conjunto de dados. Por 
exemplo, ao usar arquivos para armazenar dados de “pessoas” e de 
“casamentos”, fazia-se necessário ter dois arquivos indexados. Ao usar 
um banco de dados hierárquico, era possível ter os dois conjuntos de 
dados integrados em um só lugar.
É certo que esse tipo de BD ainda tinha grandes restrições para im-
plementar todo tipo de relacionamento entre diferentes conjuntos de 
dados, pois, como o próprio nome sugere, ele só era capaz de imple-
mentar hierarquias, isto é, estruturas em árvore.
Toda a estrutura de agregação dos dados era realizada por meio 
de ponteiros – campos que continham o endereço físico do outro ele-
mento a ser apontado –, o que garantia uma associação entre registros, 
mantida pelo SGBD e não pelo programador. O programador precisava 
somente indicar os elementos para que a associação se completasse.
Apesar de ser limitado, esse tipo de BD já trazia uma linguagem 
própria e unificada para manipulação dos dados, permitia o compar-
tilhamento e unificava a administração dos dados. O BD hierárquico já 
implementava boa parte dos benefícios de uso de um banco de dados.
30 Banco de Dados I
Considerando que não havia na época outra alternativa senão o uso 
de arquivos isolados, os BDs hierárquicos passaram a ser adotados no 
ambiente de corporações que manipulavam grandes volumes de dados 
em suas aplicações, e se mantiveram por muito tempo em operação.
1.4.2 Banco de dados em rede
A limitação do banco de dados hierárquico levou os pesquisadores 
da época a buscar uma alternativa para que o modelo hierárquico evo-
luísse para um modelo em rede. No modelo em rede (muito similar ao 
hierárquico), pode-se ter um conjunto de dados participando de mais 
de um relacionamento com diferentes conjuntos.
Esse novo recurso resolvia a restrição existente no modelo hierár-
quico e, por isso, passou a ser o novo modelo mais procurado para im-
plementações de bancos de dados. Por muito tempo, os BDs em rede 
dominaram o mercado, mas mesmo assim eles ainda apresentavam 
algumas restrições que precisavam ser superadas.
Assim como os modelos hierárquicos, que utilizavam ponteiros para 
fazer a associação entre os registros, o modelo rede acabava por criar uma 
estrutura muito rígida de relacionamento entre os conjuntos de dados.
Imagine que um modelo tivesse um conjunto “filho”associado a so-
mente um conjunto “pai”. Imagine também que seria criado, em segui-
da, um novo relacionamento desse mesmo conjunto “filho” com um 
novo conjunto “pai”. Como toda essa associação era feita fisicamente 
por campos gravados no registro “filho”, era necessário alterá-lo para 
que ele recebesse mais um campo de ponteiros para o novo relaciona-
mento. Para tanto, o espaço que aquele registro ocupava no disco iria 
crescer. Seria necessário descarregar todos os registros “filho” da base 
para outro arquivo e, em seguida, reinseri-los com um novo campo e 
ocupando um novo espaço.
1.4.3 Banco de dados relacional
O banco de dados com abordagem relacional surgiu para trazer 
maior flexibilidade às estruturas de dados dos BDs, permitindo que 
novas colunas (campos de dados) fossem agregadas facilmente a um 
registro já existente, bem como que novos relacionamentos pudessem 
ser agregados entre esse e outros registros, sem que isso impactasse o 
armazenamento físico do banco de dados.
Introdução a banco de dados 31
No BD relacional, deixou-se de ter ponteiros para associar registros 
– pois eles eram campos “artificiais”, usados somente com finalidade 
associativa – e passou-se a utilizar, então, associações feitas por meio 
de campos naturais. Isso significa que, por exemplo, caso seja necessá-
rio associar um “professor” a uma “disciplina” que ele ministra, basta ir 
ao registro da “disciplina” e inserir o código da matrícula do professor. 
Passamos a relacionar a disciplina com o professor com dados natu-
rais (aqueles que existem no mundo real) e não com dados artificiais 
(aqueles criados somente para viabilizar um relacionamento entre da-
dos naturais).
Essa nova abordagem relacional veio atender de modo bastante 
completo todas as restrições que existiam, além de resolvê-las utilizan-
do uma abordagem já amplamente validada: a teoria dos conjuntos 
(oriunda da matemática básica).
1.4.4 Banco de dados pós-relacionais
A partir da década de 1980, o mercado foi dominado pelos bancos 
de dados relacionais, tendência que se mantém até hoje. Porém, mes-
mo que os BDs relacionais tenham atendido grande parte das deman-
das de criação de bancos de dados, ainda tivemos uma nova onda que 
se iniciou por volta da década de 1990.
Com o advento das linguagens orientadas a objeto (C++, smalltalk, en-
tre outras), o surgimento de novas metodologias de análise de sistemas 
e o desenvolvimento de sistemas orientados a objetos, muitos passaram 
a se questionar se também os bancos de dados não deveriam usar uma 
abordagem orientada a objetos para armazenamento dos dados.
Nesse sentido, surgem os primeiros bancos de dados orientados a ob-
jetos – Objectivity/DB, Ontos, O2 e ITASCA –, com o objetivo de proverem 
meios para o armazenamento de dados complexos e serem mais fiéis à 
representação dos objetos mapeados pelas linguagens de programação.
Comercialmente, esses BDs não se estabeleceram no mercado, al-
guns serviram para projetos muito específicos (normalmente em áreas 
científicas), mas sem uma representatividade numérica quanto aos 
profissionais que os conhecem e os utilizam.
Como os modelos relacionais ainda tinham grande dominância 
no mercado, surgiram tentativas de criação de um modelo chamado 
objeto-relacional ou relacional estendido. Tratava-se de um modelo que 
incorporava algumas evoluções do relacional convencional, mas que 
32 Banco de Dados I
utilizava em grande parte os recursos dos relacionais já tão aceitos pelo 
mercado. Esse modelo também não teve predominância no mercado 
e hoje quase não é mais visto em aplicações comerciais. A verdade é 
que 99% das aplicações comerciais podem ser bem atendidas com o 
modelo relacional convencional, sendo a opção de grande parte dos 
projetos.
Em 2009, ressurgiu uma nova onda, liderada por pesquisadores que 
buscavam meios para que os BDs relacionais pudessem tratar de ques-
tões complexas, como distribuição de dados, altos volumes de arma-
zenamento (da ordem de terabytes), armazenamento e recuperação 
de dados científicos, como mapas, fotos, escâneres, entre outros. Esse 
movimento teve início em 1998, quando pela primeira vez já se falava 
em NoSQL 6 , mas somente com a viabilização de softwares e hardwa-
res mais modernos voltou a ser tratado em bancos de dados NoSQL, 
como MongoDB, Cassandra, entre outros.
Os BDs não relacionais utilizam os recursos do ambiente relacional 
(SQL), mas agregam outras facilidades típicas dos modelos orientados 
a objetos, bem como outras para gerenciamento de distribuição de da-
dos em grandes volumes. Imagine uma base de dados de indexação 
de páginas web que é usada pelo buscador Google para atender a um 
pedido de filtro feito no browser. Que tamanho deve ter essa base? E 
onde ela está localizada? Qual comando de filtro é aplicado para se-
lecionar os registros que interessam? Com certeza um banco de da-
dos relacional convencional não daria conta de tudo isso. Para tanto, o 
próprio Google, em 2003, criou uma iniciativa de um software livre de 
banco de dados chamado Hadoop, que manuseia grandes volumes de 
dados estruturados e não estruturados. Essa plataforma hoje é um dos 
grandes exemplos de soluções NoSQL.
A denominação NoSQL não implica que esse tipo de BD não utilizará 
o SQL, mas que implementará outros recursos além dele. É importante 
ressaltar que a sigla NoSQL significa “not only SQL” (“não apenas SQL”, 
em tradução livre), e não “not SQL” (“não SQL”, em tradução livre). Ele 
preserva e expande o modelo SQL.
Finalmente, nas últimas décadas, temos visto pesquisas orientadas 
para novas arquiteturas de bancos de dados que possam gerenciar 
grandes volumes de dados em função do novo conceito de big data 7 , 
que passou a ser agregado a uma série de aplicações. Esse é um tema 
em amplo desenvolvimento e que promete ainda grandes surpresas.
terabyte: “múltiplo do byte, 
que vale 1.024 gigabytes”. “Fre-
quemente arredonda-se o valor 
do terabyte para mil gigabytes” 
(HOUAISS, 2009).
Glossário
Termo genérico adotado para 
representar os bancos de dados 
não relacionais.
6
Grandes BDs que armazenam 
massas de dados de proporções 
muito grandes quando com-
paradas aos bancos de dados 
comerciais.
7
Introdução a banco de dados 33
CONSIDERAÇÕES FINAIS
Neste capítulo, vimos que a criação de um banco de dados é mais do 
que uma escolha técnica por um software de SGBD. Temos uma grande 
responsabilidade em criar algo que será compartilhado com toda a orga-
nização e não somente com nossos próprios sistemas.
Precisamos conhecer os dados, identificar suas características, verifi-
car o modo como se relacionam com outros dados e tantos outros deta-
lhes. Portanto, é importante lembrar: os dados não são seus, eles são da 
organização. Aquilo que você cria hoje poderá amanhã ser alterado e até 
mesmo excluído por outra pessoa. Assim, todo o cuidado no estabeleci-
mento de regras de utilização desses dados deve ser tomado.
Não tenha pressa de criar seu banco de dados. Aqui vale um velho 
ditado: “se você tem duas horas para cortar uma árvore, gaste uma hora 
e meia afiando seu machado”.
ATIVIDADES
1. Por que podemos afirmar que, ao criar um banco de dados, os dados 
não são nossos?
2. Por que um administrador de dados nem sempre é o profissional 
indicado para ser o administrador do banco de dados?
3. Por que um banco de dados deve ser sempre visto como uma porção 
do mundo real?
REFERÊNCIAS
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: Elsevier, 2004.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
HOUAISS, A. (org.). Houaiss eletrônico. Rio de Janeiro: Objetiva, 2009. 1 CD-ROM.
NAVATHE, S. B.; ELMASRI, R. Sistema de banco de dados. 4. ed. São Paulo: Person Brasil, 
2005.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de 
Janeiro: Elsevier, 2012.
34 Banco de Dados I
2
Sistema de gerência 
de banco de dados
Neste capítulo, vamos conhecer com mais detalhes qual é a 
estruturaque define um sistema gerenciador de banco de dados 
(SGBD) e como essa estrutura interage com os diversos agentes 
(pessoas, sistemas etc.) de modo a permitir que as funções de 
acesso e administração dos dados possam ser feitas.
Conhecer essa estrutura é o ponto de partida para a apresenta-
ção de todos os recursos que permitem construir e acessar diferentes 
BDs por meio de um software de gerenciamento de banco de dados.
2.1 O que é e para que serve um SGBD? 
Vídeo Um sistema gerenciador de banco de dados é um conjunto de pro-
gramas criado para executar as funções de manipulação física dos da-
dos armazenados em um BD. Essas funções podem ser divididas em 
externas, internas e de apoio.
Entre as funções externas, temos o pré-processamento, isto é, a 
pré-compilação dos comandos de manipulação de dados. Esses dados 
são incorporados às linguagens de programação, ocorrendo a compi-
lação da linguagem hospedeira. Essas funções são realizadas por meio 
de drivers, que consistem em bibliotecas fornecidas pelo fabricante do 
SGBD e/ou do fabricante da linguagem de programação.
Já entre as funções internas encontramos o motor de processa-
mento e de acesso aos dados, realizados por meio de um compilador 
de linguagem de manipulação de dados. Além disso, dentre essas fun-
ções, temos a execução de comandos interativos para usuários casuais 
por meio de compiladores de pesquisas, a execução de comandos de 
definição, a criação de objetos do BD e também a execução de coman-
Sistema de gerência de banco de dados 35
dos privilegiados – usados para definir regras de segurança, controles 
de acesso, definição de perfis (roles) etc.
Por fim, entre as funções de apoio, encontramos aquelas ligadas 
a controles de transações e de concorrência de acesso. Além disso, 
encontram-se funções ligadas ao subsistema de recuperação (backup 
e restore) e aos controles de performance do armazenamento e do 
acesso aos dados.
Segundo Navathe e Elmasri (2006), a arquitetura de um SGBD ge-
nérico pode ser demonstrada na Figura 1, em que podemos ver os di-
versos programas que executam funções distintas, tais como interagir 
com os usuários externos, processar comandos internos etc.
Figura 1
Arquitetura de um SGBD
COMANDOS DDL 
Compilador 
DDL
Compilador da 
linguagem hospedeira 
Compilador 
DML 
Compilador 
de pesquisa 
Gerenciamento 
dos dados 
armazenados 
Controle de concorrência / backup / 
subsistema de recuperação
Processador de 
banco de dados 
em tempo 
de execução 
(runtime)
COMANDOS 
PRIVILEGIADOS 
PESQUISA 
INTERATIVA
TRANSAÇÕES 
COMPILADAS 
(CUSTOMIZADAS)
COMANDOS 
DML 
PROGRAMAS DE 
APLICAÇÃO Equipe DBA Usuários casuais 
execução 
E A
B
D
C
execução 
Programadores 
de aplicação 
Usuários 
parametrizáveis 
Catálogo do 
sistema / 
dicionário de 
dados 
BANCO DE DADOS 
ARMAZENADO 
Pré-compilador 
Fonte: Navathe; Elmasri, 2006, p. 26. 
36 Banco de Dados I
Todas estas interações – internas, externas e de apoio –, implemen-
tadas pelo sistema gerenciador de bancos de dados, são formalizadas 
por meio de um grupo de comandos definido em uma linguagem pa-
dronizada. Essa linguagem é o Structured Query Language, mais co-
nhecido pela sigla SQL, que é dividida em quatro grandes grupos de 
comandos e são organizados de acordo com a finalidade a que se des-
tinam (Figura 2).
Select, Insert, Delete, Update etc.
Grant, Revoke, Deny
Alter, Create, Drop etc.
Commit, Rollback
Data Manipulation Language 
(DML)
Data Control Language 
(DCL)
Data Definition Language 
(DDL)
Transactional Control 
Language (TCL)
Figura 2
Grupos de comandos do SQL
Fonte: Silberschatz; Korth; Sudarshan, 2012, p. 51.
Vários SGBD fornecem interfaces gráficas que servem para a execu-
ção dos comandos de SQL. Isso ocorre com o preenchimento de telas e 
campos parametrizáveis. A Figura 3, a seguir, é um exemplo de interface 
em que se pode ver a área de manipulação e criação de campos em ta-
belas novas sendo feita por meio de preenchimento de campos na tela.
Figura 3
Interface gráfica do Ms-SqlServer para a criação de tabelas
Fonte: Elaborada pelo autor.
Sistema de gerência de banco de dados 37
Dentre os profissionais envolvidos nas atividades diretamente liga-
das ao SGBD, podemos elencar o administrador de banco de dados, 
projetistas e arquitetos de soluções. Além desses, há os usuários even-
tuais ou parametrizáveis, os analistas de sistemas e programadores, os 
fornecedores de ferramentas e as equipes de suporte e operação. O 
Quadro 1, a seguir, descreve a atribuição de cada profissional:
Quadro 1
Profissionais ligados ao SGBD e suas atribuições
Profissional Interação com o SGBD
Administrador de banco de dados Criar, monitorar, controlar e executar tarefas operacionais.
Projetistas e arquitetos de soluções
Definir arquiteturas e alternativas de uso do SGBD em diferentes 
projetos.
Usuários eventuais
Acessar os dados por meio de ferramentas interativas nas quais cada 
acesso requer diferentes dados.
Usuários parametrizáveis
Acessar os dados por meio de interfaces pré-definidas (normal-
mente telas de sistemas) nas quais cada acesso segue um padrão 
pré-programado.
Analistas de sistemas
Definir quais dados devem ser acessados e quais as transformações 
que eles deverão sofrer (especificação).
Programadores
Definir como os dados serão acessados e como eles serão transfor-
mados (codificação).
Fornecedores de ferramentas Criar softwares complementares às funções básicas do SGBD.
Equipe de suporte e operação
Executar atividades operacionais para garantir a disponibilidade e a 
usabilidade do SGBD.
Fonte: Elaborado pelo autor.
Algumas ferramentas que interagem com o SGBD têm sido criadas 
por fornecedores que complementam as funções básicas já oferecidas 
pelos próprios fabricantes do SGBD, como ferramentas para a mode-
lagem conceitual e lógica (CASE), ferramentas de engenharia reversa, 
otimizadores de acesso, monitores de desempenho, interpretadores 
de logs, entre outros.
Algumas destas ferramentas têm SGBDs específicos aos quais se co-
nectam, já outras são de uso geral, podendo se conectar a diferentes 
SGBDs de diferentes fornecedores, o que as tornam mais atrativas para 
os profissionais da área de administração de banco de dados.
38 Banco de Dados I
2.2 Vantagens e desvantagens 
do uso de um SGBD 
Vídeo Quando falamos sobre estruturas de bancos de dados, temos sem-
pre que avaliar tanto os benefícios quanto as eventuais desvantagens 
de usar uma abordagem ou tecnologia. No caso dos SGBDs, a mesma 
regra se aplica: existem pontos positivos (que se destacam) e pontos 
negativos (que precisam ser considerados). Apresentamos, a seguir, 
vantagens e desvantagens da utilização de um SGBD como plataforma 
para o gerenciamento de banco de dados.
2.2.1. Vantagens
Dentre as vantagens apontadas por Navathe e Elmasri (2006), e re-
ferenciadas também por outros autores, serão descritas as seguintes:
 • Natureza de autodescrição de um sistema de banco de dados
Antes da existência dos SGBDs, a definição das estruturas de dados 
era mantida em uma estrutura separada dos próprios dados. A descri-
ção da ordem em que os diversos campos iriam aparecer, o tamanho 
de cada um dos campos, a formatação que apresentariam, entre ou-
tras características, eram armazenadas em um local e os dados eram 
armazenados em outro.
Um programa COBOL, por exemplo, que desejasse acessar um ar-
quivo com dados de “Pessoa” tinha que repetir, em sua estrutura de 
código, a definição dos dados conforme mostra a Figura 4 a seguir.
Figura 4
Representação da estrutura de dados em um programa COBOL
01 REGISTRO-PESSOA
 05 CODIGO-PESSOA PIC 9(006)
 05 NOME-PESSOA PIC X(050)
Fonte: Elaborada pelo autor.
Nesse exemplo, caso um programa COBOL tivesse definido de 
modo equivocado o tamanho do campo “CODIGO-PESSOA” como “7 
dígitos alfanuméricos” em vez de “6 dígitos inteiros e numéricos”, tería-
COBOL: sigla para “COmmon 
Business Oriented Language”, 
em português, “linguagem 
comum orientada para os 
negócios”.Glossário
Sistema de gerência de banco de dados 39
mos um erro durante a execução desse programa, pois os dados físicos 
existentes em disco não seriam compatíveis com o mapeamento que o 
programa estava fazendo.
Com o advento dos SGBDs, passou-se a ter uma estrutura integrada de 
definição dos dados e de armazenamento dos dados, isto é, se a definição 
muda, os dados mudam. Além disso, os programas não precisam definir 
o layout (estrutura dos campos) de cada registro, como antes faziam. Essa 
consequência nos leva à próxima vantagem do uso dos SGBDs.
 • Isolamento entre programas e dados, abstração de dados
Com a nova estrutura integrada da definição de dados e dos próprios 
dados, se um certo programa referenciar o campo “NOME-PESSOA”, o 
SGBD saberá que seu tamanho é de 50 caracteres alfanuméricos, des-
se modo, o acessará fisicamente no disco, devolvendo esse dado no 
formato do programa. Caso, no dia seguinte, o tamanho desse dado 
seja alterado para 60 caracteres alfanuméricos, o programa não sofre-
rá nenhum impacto, ou seja, não precisará ser alterado e recompilado. 
O programa passa a referenciar um dado por meio de seu nome, tendo 
total abstração do formato, tamanho, modo de armazenamento, estru-
tura física, entre outros.
Um mesmo dado pode estar em um banco de dados centralizado, 
distribuído em um BD local ou remoto, ou, ainda, ser compactado (ou 
não). Tudo isso não afetará o código que o programador irá gerar para 
referenciar ou acessar esse dado, tornando o processo de codificação 
do programa mais simples e garantindo que ele continuará funcionan-
do mesmo que existam alterações na estrutura do banco de dados.
 • Suporte às múltiplas visões de dados
Se a abstração de dados já agrega um importante diferencial para o 
acesso lógico aos dados (e não mais o acesso físico aos dados), o que 
dizer da possibilidade de publicar também múltiplas visões de um mes-
mo conjunto de dados?
Essa habilidade tem grande importância quando lembramos que 
uma das características principais a serem buscadas no uso de um BD 
é o compartilhamento. Porém, ao compartilhar e criar conjuntos coe-
rentes de dados (outra característica importante), poderíamos acabar 
expondo, de modo indevido, porções dos dados que não interessam 
ou que não deveriam ser publicadas a todos os que os acessam.
40 Banco de Dados I
Para contornar essa situação, foi criada uma estrutura definida 
como view, isto é, uma visão dos dados. Por meio de uma view, é possí-
vel restringir um conjunto vertical ou horizontal de dados.
Nas tabelas a seguir, podemos ver que, para uma relação contendo 
várias colunas e várias linhas, é possível produzir diferentes views des-
tes dados, seja pela segmentação horizontal (onde os dados de algu-
mas linhas são selecionados), pela segmentação vertical (onde alguns 
dados de algumas colunas são selecionados) ou, ainda, pela combina-
ção simultânea da segmentação horizontal e vertical.
Tabela 2
View com segmentação vertical (colunas 
Nome + Sexo)
Nome pessoa Sexo
JOAO DA SILVA Masculino
MARIA DA SILVA Feminino
PEDRO DA SILVA Masculino
JOSE DA SILVA Masculino
Fonte: Elaborada pelo autor.
Tabela 1
Segmentação horizontal e vertical de uma tabela
Cód. 
Pessoa Nome pessoa
Data de 
nascimento Sexo Raça
000015 JOAO DA SILVA 25/03/1962 Masculino Branco
000017 MARIA DA SILVA 11/07/1964 Feminino Branco
000018 PEDRO DA SILVA 09/11/1992 Masculino Negro
000019 JOSE DA SILVA 11/11/1997 Masculino Branco
Tabela original
Fonte: Elaborada pelo autor.
Tabela 3
View com segmentação horizontal (filtro para “sexo masculino”)
Cód. Pessoa Nome pessoa Data de nascimento Sexo Raça
000015 JOAO DA SILVA 25/03/1962 Masculino Branco
000018 PEDRO DA SILVA 09/11/1992 Masculino Negro
000019 JOSE DA SILVA 11/11/1997 Masculino Branco
Fonte: Elaborada pelo autor.
 • Compartilhamento de dados e processamento de transação 
multiusuário
Finalmente chegamos à última vantagem apresentada por Navathe e 
Elmasri (2006). Essa é uma das características que é vantagem do próprio 
banco de dados, mas, aqui, trata-se de uma abordagem do ponto de vista 
de implementação de funções dentro do SGBD que viabilizam essa função.
Imagine o grau de complexidade com que um programador teria 
que lidar para permitir que um programa pudesse acessar, de modo 
concorrente, um mesmo conjunto de dados no qual diversos progra-
Sistema de gerência de banco de dados 41
mas realizassem operações simultâneas de atualização e exclusão 
caso, no SGBD, não tivesse um conjunto de facilidades prontas para 
essa finalidade. Pode-se dizer que seria praticamente inviável compar-
tilhar e controlar as operações de atualização simultânea se não exis-
tisse, no SGBD, esse controle já automatizado.
2.2.2. Desvantagens
Abordaremos, a seguir, as desvantagens de se utilizar um SGBD na 
implementação de uma estrutura de suporte a dados para um sistema 
de informações.
 • Recursos de infraestrutura
O primeiro ponto que nitidamente chama a atenção é o fato de que 
um SGBD requer muito mais recursos de infraestrutura para ser criado, 
mantido, publicado, compartilhado e administrado. Isso significa que é 
necessário mais poder computacional (hardware e software) para ins-
talar, configurar e disponibilizar um SGBD do que seria necessário para 
disponibilizar uma estrutura baseada em arquivos convencionais.
É necessário considerar que caso vários sistemas precisem criar, de 
modo repetido (não compartilhado), seus arquivos de dados, muito pro-
vavelmente a somatória de pequenos recursos usados em cada siste-
ma possa representar uma somatória até maior do que o próprio SGBD 
represente. Nesse sentido, a infraestrutura pode ser uma desvantagem 
para usos de um SGBD em um ambiente de pouco compartilhamento.
Se imaginarmos, por exemplo, a criação de um catálogo de contatos 
– como o de um software de gerenciamento de números de telefones 
de um smartphone –, no qual dados de pessoas e telefones serão ar-
mazenados e consultados por uma única pessoa, seria talvez inviável 
pensar na infraestrutura necessária para usar um SGBD destinado a 
essa finalidade. A opção por uma estrutura de arquivos locais seria tec-
nicamente viável e indicada.
 • Custo
A segunda desvantagem que podemos elencar é o custo, mesmo 
nos casos em que se possa pensar no uso de um SGBD open-source 
(de software livre). O SGBD em si não tem custos, na verdade, a infraes-
42 Banco de Dados I
trutura que ele usará terá seus custos (maior capacidade de hardware 
necessária, outros softwares complementares etc.). Até o administrador 
de banco de dados envolvido nessa operação terá seus custos, estes, 
normalmente, serão maiores do que o de um profissional não especia-
lista. Além disso, é importante avaliar se a somatória de menores custos 
isolados em vários sistemas poderá representar um custo final maior do 
que a de um único SGBD compartilhado entre vários sistemas.
 • Performance
O terceiro ponto a ser avaliado é a performance final que se deseja 
obter com uma mesma infraestrutura. Se considerarmos que a infraes-
trutura onde o SGBD será executado é limitada – o que pode ocorrer, 
por exemplo, em um smartphone ou em uma estação de atendimento 
do tipo toten –, haverá uma perda de performance cada vez maior, isto 
é, quanto maior for a complexidade do SGBD utilizado, maior será a 
perda de performance.
Vimos, na Figura 1, que o SGBD é um conjunto de programas que 
executam diversas funções. Logo, quanto mais programas tivermos 
para executar em uma mesma infraestrutura limitada, menor será a 
performance final obtida. Por isso, muitas vezes, em ambientes com 
restrições de infraestrutura, estruturas de arquivos convencionais são 
utilizados em vez de SGBDs.
Como pode-se perceber, tanto as vantagens quanto as desvanta-
gens do uso de um gerenciador de banco de dados irão depender di-
retamente das características do ambiente onde serão utilizados. Usos 
corporativos, em ambientes de grande porte, poderão potencializar 
vantagens e minimizardesvantagens. O uso em ambientes de proces-
samento pessoal poderá inverter essa relação, minimizando vanta-
gens, mas destacando desvantagens.
A escolha por usar ou não um SGBD, ou até mesmo a escolha de 
qual SGBD usar (já que existe uma grande variedade e tipos disponí-
veis), irá depender da análise de vários requisitos e recursos disponí-
veis no projeto. Um arquiteto de soluções, nesse momento, pode ser 
uma figura importante para, junto com o administrador de banco de 
dados, ajudar o analista de sistemas a definir a topologia e as tecnolo-
gias que serão usadas para atender a cada demanda.
Sistema de gerência de banco de dados 43
2.3 Criação e manutenção de um SGBD 
Vídeo Dentre as funções do SGBD, podemos destacar o fato de ele servir 
como ferramenta para integrar três níveis existentes na arquitetura de 
três esquemas (NAVATHE; ELMASRI, 2006).
A arquitetura de três níveis foi proposta de modo a isolar os dife-
rentes aspectos de manipulação de dados envolvidos em um banco de 
dados. O primeiro nível, chamado de nível interno, 
é representado por um esquema interno que des-
creve toda a estrutura de armazenamento e manipu-
lação física dos dados, ou seja, em um nível próximo 
do hardware. Sem esse nível, gerenciado pelo SGBD, 
teríamos que transferir essa complexa tarefa para o 
programador, aumentando em muito a dificuldade 
para interação dos sistemas de informação com os 
dados que eles viessem a utilizar.
O segundo nível, chamado de nível conceitual, 
está associado ao esquema conceitual e descreve 
de modo integral a estrutura do banco de dados – 
descrição das entidades, relacionamentos, tipos de 
dados, regras de acesso, regras de segurança etc. 
Nesse nível, os detalhes da estrutura física não são 
relevantes, precisamos conhecer os dados que temos disponíveis para 
acesso, porém não é necessário saber como estão fisicamente armaze-
nados. Desse modo, se temos um campo numérico que pode armaze-
nar até oito dígitos inteiros e dois dígitos decimais, não saberemos – e 
não precisaremos saber – quantos bytes são consumidos para guardar 
esse conteúdo em disco quando ele é salvo.
Finalmente o terceiro nível, conhecido como nível externo ou de 
visão, associado ao esquema externo, se apresenta por meio de uma 
série de esquemas (ou visões) que publicarão partes de um banco de 
dados que seja de interesse de um ou mais grupos de usuários. No item 
2.2.1., mais especificamente no tópico “Suporte às múltiplas visões de 
dados”, vimos um exemplo do processo de geração de views, criadas 
por meio da segmentação vertical, horizontal e combinadas entre si; 
essas visões são justamente aquelas gerenciadas pelo esquema exter-
no. Por meio desse esquema, podemos proteger o acesso a partes do 
Livro
O livro Projeto, Desenvol-
vimento de Aplicações e 
Administração de Banco de 
Dados, de Michael V. Man-
nino, apresenta a base 
para entender a tecnolo-
gia de banco de dados, as 
tecnologias elementares 
de cada ambiente de 
processamento e discute, 
ainda, o relacionamento 
de cada tecnologia com 
os avanços do comércio 
eletrônico e da computa-
ção corporativa.
MANNINO, M. V. Porto Alegre: 
AMGH, 2008.
44 Banco de Dados I
BD ou simplificar o acesso a conjuntos de dados (ocultando aquilo que 
não seja relevante).
A existência desses três níveis acaba por prover o que é definido 
como independência de dados, ou seja, a capacidade de ter acesso aos 
dados existentes no BD sem a necessidade de conhecer os detalhes 
físicos – que eventualmente podem até mudar sem impactar nossos 
programas – ou as estruturas completas que compõem um banco de 
dados. Se forem criados ou removidos campos, os programas poderão 
ficar isolados por essas mudanças, caso esses campos não façam parte 
da visão dos dados que utilizamos.
Durante o processo de criação de um banco de dados em um 
SGBD, podemos perceber, nas figuras a seguir, a sua atuação sobre 
os três níveis descritos. A primeira etapa, ligada ao nível físico, está 
representada pela criação física de um espaço em disco para alocação 
das estruturas de dados.
Figura 5
Criação da estrutura física do banco de dados
Fonte: Elaborada pelo autor.
Sistema de gerência de banco de dados 45
Na Figura 5, podemos ver a alocação de 5 megabytes para uma área 
de dados, chamada Exemplo, com incrementos de 1 megabyte em um 
diretório físico localizado em “C:\ProgramFiles\MicrosoftSQLServer”. 
Há também uma segunda área física com 1 megabyte, chamada 
Exemplo_log, com incrementos de 10% em outro diretório da rede. Es-
ses são todos os aspectos físicos que o SGBD gerencia no nível físico 
para que tenhamos sempre o banco de dados como capaz de armaze-
nar novos dados.
Figura 6
Criação de usuários e esquemas
Fonte: Elaborada pelo autor.
Na Figura 6, podemos ver, no nível lógico, alguns exemplos dos 
recursos que o SGBD oferece para que sejam criados “Usuarios” e 
“Esquemas” que serão usados durante a criação das estruturas de da-
dos (“Tabelas”). Esses usuários poderão ser proprietários de esquemas, 
que por sua vez poderão ser agrupadores de tabelas; essas poderão 
ser vistas pelo usuário associado ao esquema.
Essa abordagem garante um ambiente de gestão integrado/centra-
lizado dos objetos que o SGBD gerencia e permite que o administrador 
do banco de dados crie e realize a manutenção de todas as estruturas 
de dados. Assim como o banco de dados “Exemplo” foi criado, pode-
mos criar outros BDs de modo similar.
46 Banco de Dados I
Figura 7
Criação de uma tabela no esquema EX
Fonte: Elaborada pelo autor.
Na Figura 7, podemos ver a criação de uma tabela por meio do mé-
todo baseado em comandos SQL (“CREATE TABLE”) – a criação pode-
ria também ser realizada por meio de telas interativas. Logo após a 
criação da tabela “EX.AUTOR”, podemos ver na coluna à esquerda de-
talhes sobre os dados que serão armazenados, como “Nome_AUTOR” 
que terá 40 caracteres armazenados em um campo de tamanho va-
riável (“VARCHAR”) e que não poderá ter o conteúdo nulo (regra de 
preenchimento).
Podemos ver também a existência de índices de acesso (estruturas 
físicas para melhorar a performance) criadas automaticamente pelo 
SGBD para o campo “ID_AUTOR”, pelo fato de esse campo ter sido 
declarado como chave primária, isto é, campo principal para identifi-
cação única do registro. Todas essas estruturas mostram a integração 
que o SGBD é capaz de fazer automaticamente entre os níveis físico, 
lógico e externo.
Sistema de gerência de banco de dados 47
2.4 Tipos de SGBD 
Vídeo
Após termos definido que iremos usar um SGBD para dar suporte 
aos dados de nossas aplicações, chega o momento 
da definição de qual será o SGBD escolhido. Muitas 
características podem influenciar essa escolha: a 
oferta de SGBDs no mercado é ampla, há diversos 
fornecedores e um mesmo fabricante pode oferecer 
diversos modelos de SGBD. Em resumo, não basta 
escolher o fornecedor, é necessário atentar ao mo-
delo oferecido e verificar o que mais se adéqua a 
nossa necessidade. Na Figura 8, a seguir, podemos 
ver que o fornecedor Microsoft tem várias edições 
para o SGBD SQL-Server 2017 (modelos), cada um 
aplicável a um perfil de projeto.
Vídeo
O vídeo Banco de Dados – Sexta 
Aula – SGBD – Sistemas Geren-
ciadores de Banco de Dados, pu-
blicado pelo canal Wopenheimer, 
apresenta um resumo de todas 
as características de um SGBD 
e pode ser bastante útil como 
elemento de fixação dos conceitos 
apresentados neste capítulo.
Disponível em: https://youtu.be/
Fw5Ulwo6NvQ. 
Acesso em: 27 fev. 2020.
Figura 8
Edições disponíveis no SQL-Server 2017
Acesse recursos de 
missão crítica para 
alcançar escala, 
segurança, alta 
disponibilidade e 
performance líder 
incomparáveis para seus 
workloads de nível 1 
de Advanced Analytics, 
business intelligence e 
bancos de dados.
Encontre recursos de 
programação avançados, 
inovações de segurança 
e performance rápida 
para aplicativos de nível 
intermediário e data 
marts. Faça upgrade 
facilmente para a 
Enterprise Edition semprecisar alterar nenhum 
código.
Crie pequenos aplicativos 
web e móveis, controlados 
por dados de até 10 GB, 
com esse banco de dados 
de nível básico. Disponível 
gratuitamente.
Crie, teste e demonstre 
aplicativos em um 
ambiente que não seja de 
produção com esta edição 
completa do SQL Server 
2017.
Enterprise Standard Express Developer
Fonte: Microsoft, 2020.
Dentre os vários fatores que devem ser considerados na escolha 
de um SGBD, um deles é a quantidade de usuários que estarão conec-
tados para obter e atualizar dados por uma ou mais aplicações. Aqui, 
podemos mencionar aplicações monousuário, com dezenas, centenas 
e até milhares de usuários simultâneos. É certo que quanto maior for 
a quantidade de usuários simultâneos, maior é a preocupação com a 
escolha de um SGBD robusto em performance, em segurança, em utili-
zação de recursos de infraestrutura etc.
48 Banco de Dados I
Um segundo fator a ser considerado é o crescimento da base de 
dados com o passar do tempo. Nesse aspecto, tanto um crescimento 
rápido quanto um crescimento lento, porém contínuo, pode ser um 
elemento de preocupação. SGBDs de pequeno porte, mesmo que para 
um atendimento inicial de poucos usuários, podem, com o passar do 
tempo, não suportar a demanda por armazenamento e recuperação 
de dados, se o volume dos dados inseridos crescer de modo descon-
trolado. Eventuais cargas de dados – por importação e por integração 
com outros sistemas – podem fazer com que poucos usuários sejam 
capazes de criar grandes massas de dados no SGBD.
Como terceiro ponto de análise, temos a estabilidade do SGBD. Este 
critério tem correlação com os aspectos de robustez, desempenho e 
segurança. Um SGBD que não ofereça desempenho homogêneo em si-
tuações de baixa, média e alta demanda por dados não oferecerá, con-
sequentemente, estabilidade. Além disso, um SGBD que não ofereça 
segurança também pode sofrer ataques e invasões que levem à perda 
de estabilidade. Portanto, analisar a estabilidade pode consistir em ana-
lisar outros fatores que levam ao resultado definido como estabilidade.
Um quarto ponto essencial para a análise – muitas vezes decisi-
vo na seleção de um SGBD – é o custo total de propriedade (CTP) do 
SGBD. Por custo de propriedade entende-se o quanto gastamos para 
adquirir (mesmo que no modelo as a service ou locação), implantar 
e manter o SGBD em operação. Mesmo que o hardware ou software 
incorporados ao SGBD já existam, o fato de serem alocados à operação 
deste SGBD os fazem compor o CTP.
O CTP envolve não apenas custos com software, mas também cus-
tos com hardware e, principalmente, custos com mão de obra (talvez 
o mais significante dos três custos). Optar por um SGBD open-source 
(sem custos de aquisição) muitas vezes pode trazer outros custos indi-
retos que o façam ter um custo de propriedade final maior do que o de 
uma ferramenta proprietária (com custos de aquisição).
No artigo TOP 10 principais SGBDs do mercado global, publicado pelo Be 
Code, é discutido como as empresas gerenciam grandes bancos de dados e 
apresenta quais são os principais Sistemas de Gerenciamento de Banco de 
Dados. Vale a leitura!
Acesso em: 2 jun. 2020.
https://becode.com.br/principais-sgbds/
Artigo
As a service: do inglês, 
software como serviço. Trata-se 
de uma forma de distribuição e 
comercialização de softwares.
Glossário
Sistema de gerência de banco de dados 49
Também podemos considerar o fator da padronização de softwares 
– um requisito de governança de TI – como um elemento forte na deci-
são por um SGBD. Muitas vezes, a empresa para a qual iremos criar um 
novo sistema já adota um modelo ou diferentes modelos de um SGBD 
de um mesmo fabricante, e, consequentemente, a definição para um 
novo projeto irá ser conduzida para que se escolha um SGBD da mesma 
família de produtos. Se uma empresa optou por uma linha de produtos 
da Microsoft, por exemplo, o SGBD escolhido será o SQL Server, seja 
qual for a edição que se pretenda usar. Não se trata somente de man-
ter um padrão, mas, sim, de reduzir o custo de propriedade, pois pode-
remos ter um único administrador de banco de dados para gerenciar 
todos os SGBDs dentro da empresa. Além disso, o compartilhamento 
de recursos pode ser facilitado tanto entre equipes de desenvolvedo-
res quanto equipes de suporte, instrutores etc.
Atualmente, um outro fator tem surgido como forte influenciador: 
a oferta de SGBDs na nuvem. Assim, alguns provedores de serviços na 
nuvem eventualmente oferecem alguns modelos e marcas de SGBD 
conforme suas políticas comerciais de modo diferenciado, induzindo 
algumas empresas a diversificar suas escolhas ou até a manter um 
parque heterogêneo de SGBDs, já que os serviços de administração e 
suporte estarão inclusos nos serviços contratados, reduzindo o custo 
de propriedade. Isso nos faz considerar que a topologia ou arquitetura 
tecnológica também exercerá um papel importante na seleção de um 
SGBD. Um sistema de uso corporativo construído para uma empresa 
local ou nacional terá requisitos muito diferentes de um sistema cons-
truído para uso global por meio de um modelo baseado na nuvem.
CONSIDERAÇÕES FINAIS
Neste capítulo, pudemos conhecer as características, a aplicabilidade e 
os diversos tipos de sistemas gerenciadores de bancos de dados. Esse co-
nhecimento permitirá a escolha correta do SGBD para cada projeto, caso 
você opte por ser um administrador de banco de dados ou um arquiteto 
de soluções. Vimos que esta escolha dependerá de muitos fatores e que 
a oferta de opções de SGBD no mercado é bastante ampla.
Recomendamos que você procure avaliar de modo equilibrado os ato-
res envolvidos nessa escolha e que, se necessário, busque o auxílio de 
um administrador de banco de dados experiente. Profissionais com mais 
experiência poderão ter maior facilidade em identificar benefícios e restri-
ções em uma avaliação final.
50 Banco de Dados I
ATIVIDADES
1. Justifique por que o uso de um SGBD não é obrigatório no 
desenvolvimento de todos os sistemas de informação.
2. Se o objetivo de um BD é compartilhar dados, por qual razão um SGBD 
oferece recursos para criação de views que ocultam parte dos dados 
de um BD?
3. Qual é a vantagem de trabalharmos com uma arquitetura de três 
níveis – físico, conceitual e externo?
4. Quais são os fatores que impactam o custo de propriedade de um SGBD?
REFERÊNCIAS
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: Elsevier, 2004.
EDIÇÕES disponíveis do SQL Server 2017. Microsoft. Disponível em: https://www.microsoft.
com/pt-br/sql-server/sql-server-2017-editions#CP_StickyNav_1. Acesso em: 26 fev. 2020.
ELMASRI, R.; NAVATHE, S. Sistemas de banco de dados. 4. ed. São Paulo: Pearson; Addison 
Wesley, 2006.
SILBERSCHATZ, A.; KORTH; H. F.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de 
Janeiro: Elsevier, 2012.
Modelagem de dados 51
3
Modelagem de dados
Muitas pessoas imaginam que a criação de um banco de dados 
seja uma tarefa essencialmente intuitiva, na qual basta ter acesso 
a um sistema gerenciador de banco de dados e, então, criar todas 
as tabelas de que necessitam para armazenar seus dados, sem um 
planejamento prévio. No entanto, isso não se aplica caso nosso ob-
jetivo seja a criação de um conjunto de tabelas inter-relacionadas 
de modo coerente e que expressem um conjunto de dados que 
realmente representem uma porção do mundo real.
Até é possível criar tabelas aleatórias por meio de um método 
intuitivo e não planejado, mas isso resulta em um simples conjunto 
de tabelas, não necessariamente em um banco de dados. Para a 
criação de um conjunto coerente de tabelas, é necessário um mé-
todo planejado, denominado modelagem de dados.
Neste capítulo, estudaremos os objetivos, os benefícios, os mé-
todos de criação e os tipos de modelos de dados que poderemos 
produzir, por meio do uso de técnicas formais de modelagem de 
dados, para que sejamos capazes de produzir estruturas de ban-
cos de dados com um excelente desempenho.3.1 O que é e para que serve um 
modelo de dados? 
Vídeo Se observarmos outras áreas da ciência, possivelmente constatare-
mos que o ser humano sempre buscou a representação de elementos 
e objetos do mundo real de modos alternativos. Desde as mais remo-
tas eras, como no tempo das cavernas, o ser humano usava modelos 
gráficos, por meio de desenhos, para documentar ou representar as 
histórias que vivenciava ou para repassar o conhecimento que detinha 
a seus descendentes.
52 Banco de Dados I
Antes desse advento, somente a descrição verbal de informações 
era usada para representar pessoas e fatos. Desse modo, se alguém 
precisasse descrever uma pessoa, precisaria elaborar um descritivo 
textual ou verbal, enumerando todas as características do indivíduo. 
Embora esse seja um método possível, podemos concordar que não é 
o mais sintético e objetivo em muitas situações.
Com o decorrer do tempo, outros tipos de representação de porções 
do mundo real passaram a ser usadas. O homem deixou de desenhar 
nas paredes das cavernas para criar representações tridimensionais de 
animais, pessoas e deuses. Nesse momento, surgiram as estátuas, os 
bonecos, os vodus, as esculturas etc. Com isso, os modelos deixaram 
de ser somente visualizados, podendo ser manuseados, tocados, sen-
tidos, medidos, pesados e comparados, além de incorporarem caracte-
rísticas cada vez mais realistas e tornarem-se mais representativos da 
realidade.
Evoluímos mais um pouco e, então, modelos matemáticos foram 
desenvolvidos para representar leis, fatos, regras etc. Criaram-se tam-
bém animações, diagramas, fluxogramas, gráficos, clones, jogos, robôs 
e fórmulas matemáticas para representar e reproduzir o comporta-
mento de objetos e mundos reais. Passamos a comprovar, provar, cal-
cular, simular e até prever o comportamento dos objetos reais que eles 
representavam.
Todos esses exemplos são, de um modo ou de outro, modelos cria-
dos pelo homem, que podem ter maior ou menor complexidade, maior 
ou menor grau de fidelidade com o objeto representado, maior ou me-
nor facilidade de ser gerado etc., compartilhando de um mesmo obje-
tivo: representar um objeto do mundo real. Usando essas analogias do 
nosso dia a dia, podemos começar a definir e a entender os conceitos 
básicos do que é, efetivamente, um modelo e para que ele serve.
Podemos, portanto, dizer que um modelo é, de modo geral, uma representação de 
um ou mais objetos do mundo real realizada por meio de uma técnica específica, 
com uma finalidade específica.
O desenho de um homem é uma representação gráfica bidimen-
sional de um homem. O manequim de uma vitrine de loja é uma re-
presentação tridimensional de um homem. Um mapeamento de DNA 
Modelagem de dados 53
humano é uma representação biológica de um homem. Uma fotografia 
é uma representação pictórica de um homem. Uma pintura é uma re-
presentação formal ou abstrata de um homem, conforme o estilo que 
o próprio pintor utiliza, e assim por diante. Todas essas representações 
podem até ser do mesmo homem, mas elas conterão diferentes níveis 
de informação, de detalhes, de fidelidade com o objeto real e, principal-
mente, diferentes finalidades.
Ao tratarmos de finalidade do uso de um modelo, podemos abor-
dar também a escolha da técnica de representação para a criação do 
modelo. Muitas vezes, as pessoas pensam que é importante utilizar al-
guma técnica, independentemente de qual seja. No entanto, isso não 
é o mais adequado. Vamos continuar com nossa analogia para enten-
dermos melhor. Se alguém busca uma simples representação de um 
homem e de uma mulher, para poder diferenciar suas características, 
muito provavelmente um desenho ou até um manequim de loja seja 
suficiente. Porém, se alguém busca identificar características étnicas de 
um homem ocidental e de um homem oriental, talvez um simples ma-
nequim não seja suficiente, sendo necessária, por exemplo, uma foto 
ou uma coleção de fotos como o modelo mais ideal para se obter uma 
comparação mais eficiente.
Isso significa que, em função do resultado que desejarmos obter, 
deveremos escolher uma técnica diferente para elaboração do nosso 
modelo. Essa mesma abordagem se aplica à criação dos modelos de 
dados, em que existem várias técnicas e que cada uma irá agregar di-
ferentes níveis de informação ao modelo produzido e, por conseguin-
te, gerar diferentes níveis de entendimento do mundo real que está 
representando.
Um modelo, independentemente da técnica que tenha sido aplica-
da para sua construção, precisa respeitar algumas premissas. Pode-
mos, por exemplo, incluir ou excluir algumas características inerentes 
do objeto que estamos representando, mas devemos, acima de tudo, 
manter a coerência com o objeto que está sendo representado. Nova-
mente utilizando a ideia da representação de um homem, podemos, 
por exemplo, criar uma estátua de um homem, omitindo detalhes 
como cor dos olhos e cabelos ou até detalhes da face. No entanto, não 
poderemos criar uma estátua que não possua uma cabeça ou mesmo 
que represente uma pessoa com duas cabeças, principalmente se o 
objeto que estamos reproduzindo é um homem convencional.
54 Banco de Dados I
Quando um modelo incorpora características que não pertencem 
realmente ao objeto observado, ele passa a ser incoerente ou até erra-
do. Além disso, se ele deixa de representar as características mínimas 
do objeto observado, o modelo criado deixa de ser verídico.
Podemos dizer, então, que um modelo de dados é a representação de uma porção 
do mundo real que consegue reproduzir e manter as características essenciais dos 
objetos e das relações existentes entre esses objetos.
Essa representação precisa ser capaz de fazer uso de técnicas pa-
dronizadas para construção e interpretação desse modelo, de modo 
que sejamos capazes de utilizar essa representação como meio de re-
ter e compartilhar conhecimento sobre o mundo real que ela repre-
senta. Em outras palavras, precisamos criar um modelo que possa ser 
entendido por quem o observa. Se criarmos um modelo que não pode 
ser interpretado e reconhecido, ele também perderá seu valor. Seria 
o mesmo que criar um modelo de homem cujo observador não seja 
capaz de reconhecer onde ficam os braços e onde ficam as pernas. Ele 
perderia seu poder de representação.
Essa facilidade de reconhecimento estará, certamente, associada à 
utilização de padrões e à ampla divulgação dos elementos utilizados 
na construção dos modelos. Por isso, durante o desenvolvimento dos 
nossos modelos de dados, utilizaremos métodos e representações 
gráficas específicas e amplamente conhecidas no mercado, tais como 
aquelas existentes no modelo entidade-relacionamento.
Esses elementos gráficos foram criados para permitir que uma 
maior quantidade de informações possa ser representada por um con-
junto menor de elementos, como os elementos gráficos usados para 
retratar as entidades e os relacionamentos na modelagem proposta 
por Chen (1990). Caso não existisse essa representação gráfica, nos 
restaria descrever, por meio de linguagem escrita ou verbal, todas as 
características do ambiente que desejamos representar. Imagine o 
que isso poderia representar se nosso objetivo fosse revelar todo o 
ambiente de uma empresa de telecomunicações, com suas complexas 
relações com o mercado, com clientes, com fornecedores etc. Podería-
mos estar falando de páginas e mais páginas de extensos textos sendo 
Modelagem de dados 55
usados para descrever o mesmo conteúdo que talvez em uma única 
página de representação gráfica poderia ser igualmente descrito.
No artigo Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Re-
lacionamento (DER), escrito por Gonçalves (2014), você observará alguns 
novos conceitos sobre a modelagem entidade-relacionamento, bem como 
um exemplo prático de um modelo construído com a aplicação da teoria 
estudada nesta seção.
Acesso em: 30 mar. 2020.
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-
 relacionamento-der/14332
Artigo3.2 Vantagens e desvantagens 
de um modelo de dados 
Vídeo A utilização de um modelo de dados durante o ciclo de construção e 
manutenção de um banco de dados já não é mais vista como um item 
que não agrega benefícios em sua utilização. Ao contrário disso, a prá-
tica, ao longo de anos e anos, demonstrou que já não podemos mais 
abrir mão desse elemento para mapeamento e estruturação dos dados 
em nosso banco de dados.
Essa prática apresenta tanto vantagens quanto desvantagens, con-
forme observaremos a seguir.
3.2.1 Vantagens
Dentre as diversas vantagens que podemos apontar na criação de 
um modelo de dados, temos a capacidade de planejar a estrutura do 
banco de dados. Como toda atividade de planejamento, nessa fase, 
com pequenos custos e com grande flexibilidade, poderemos experi-
mentar alternativas de solução para criação de nosso banco de dados.
Vamos utilizar como analogia a área de construção civil. Quando 
um arquiteto cria a planta baixa de uma casa, ele está criando um mo-
delo. É nessa fase que teremos o menor custo e a maior flexibilidade 
para mudar, por exemplo, o local ou o tamanho da cozinha, além de 
incorporar ou remover um quarto no andar superior. Caso o imóvel 
fosse construído sem esse modelo, só veríamos que a cozinha estava 
pequena quando já estivesse com as paredes levantadas, por exemplo, 
56 Banco de Dados I
ou descobriríamos que seria impossível criar um novo quarto no pavi-
mento superior, pois não havíamos preparado a fundação da casa para 
suportar esse peso extra.
Em um modelo de dados, poderemos também criar e alterar o pla-
nejamento da estrutura de nosso banco de dados, sem que isso repre-
sente impacto real em uma estrutura física já construída. Se precisamos 
expandir ou remover elementos de dados, ou se precisamos criar ou 
remover relacionamentos entre esses elementos, tudo será mais fácil 
se executado em uma fase na qual o banco de dados ainda não está 
construído, em que tudo não passa de uma representação gráfica feita 
em um diagrama. Logo, a flexibilidade de ajustes na estrutura de da-
dos que estamos planejando por meio do modelo de dados é essencial 
para que possamos, com menor esforço e custo, obter a melhor estru-
tura de banco de dados.
Isso nos permite afirmar que uma das vantagens de se criar um 
modelo de dados é reduzir custos e prazos na criação de uma estrutura 
de banco de dados e que o uso de modelos de dados nos permite ter 
flexibilidade na experimentação de estruturas de dados.
Outra vantagem que podemos destacar pelo uso de um modelo de 
dados é a capacidade de prototipagem das estruturas de dados que te-
remos. Novamente pensando na construção de um imóvel, seria muito 
útil podermos criar um modelo tridimensional da planta baixa e poder-
mos caminhar por dentro do imóvel, como se já estivéssemos visuali-
zando a obra. Isso garantiria que uma janela com tamanho indevido, 
ou uma escada mal posicionada, pudesse ser vista ao vivo, mesmo em 
um modelo virtual.
Do mesmo modo, se pudermos utilizar nosso modelo de dados para 
prototipar diferentes estruturas de dados do banco de dados, simulan-
do o acesso que os programadores poderão fazer a todas as tabelas, 
os filtros que poderão aplicar na seleção de dados, os requisitos que te-
rão que cumprir para poder armazenar um novo registro no banco de 
dados, teremos, então, um elemento de grande utilidade ainda nessa 
fase, que antecede a construção do próprio banco de dados, novamen-
te reduzindo custos e prazos para o desenvolvimento das aplicações 
que utilizarão o banco de dados planejado.
De modo similar, podemos utilizar os modelos de dados para validar 
as estruturas de dados que construiremos futuramente, ou seja, pode-
Modelagem de dados 57
mos, por meio do modelo construído ainda em papel, verificar se as futu-
ras estruturas do banco de dados, construídas por meio de um Sistema 
de Gerenciamento de Banco de Dados (SGBD), terão a capacidade de 
atender a nossas demandas de informação. Essa, talvez, possa ser apon-
tada como uma das principais vantagens em questão. Antes da adoção 
dos modelos de dados, restava ao administrador de dados (ou naquela 
época ainda ao analista de sistemas) realizar entrevistas, questionários e 
levantamentos das fontes dos dados que ele iria consumir ou alimentar 
por meio do sistema de informação que criaria. 
Como resultado desses levantamentos, ele estruturaria arquivos 
ou até bancos de dados com base no entendimento que havia tido. 
Porém, como poderíamos assegurar que o entendimento do analista 
de sistema estaria correto? Quem poderia interpretar as estruturas de 
dados que ele iria criar e afirmar que estavam corretas? Consideran-
do serem atividades de alta complexidade técnica, os entrevistados, 
normalmente de áreas de negócio da organização, não tinham como 
validar o entendimento dos analistas e, com isso, o risco de não confor-
midades e necessidades de futuros ajustes era quase certo.
Também tem sido esse o propósito dos arquitetos quando cons-
troem plantas e maquetes eletrônicas ou até maquetes reais. Eles pre-
tendem validar com seus clientes se os requisitos que o contratante 
desejava foram corretamente compreendidos e incorporados pelo ar-
quiteto no produto final que irá produzir. Podemos perceber que va-
lidar o entendimento de conceitos, de demandas, de requisitos etc. é 
algo vital para o sucesso de um projeto. Se esse entendimento puder 
ser antecipado para uma fase na qual mudanças possam ser feitas com 
poucos impactos, teremos muito mais chances de obter um produto 
alinhado com as necessidades reais.
Imagine o seguinte cenário: um programador descobre, já na fase 
de construção de uma tela para o cadastramento de um funcionário, 
que não poderá realizar essa tarefa de modo simples, pois não é ca-
paz de associar esse funcionário ao departamento onde ele trabalha e, 
simultaneamente, nomeá-lo como gerente desse departamento; isso 
porque o administrador de dados, ao conceber o modelo de dados, 
não identificou corretamente essa necessidade. Do modo como o ban-
co de dados foi criado, o programador só conseguirá estabelecer um 
único relacionamento entre o departamento e o funcionário. Esse rela-
cionamento representará o fato de que o funcionário trabalha naquele 
58 Banco de Dados I
departamento ou representará o fato de que é o chefe do departa-
mento, mas não ambas as informações simultaneamente. O impacto 
será alterar a estrutura do banco de dados, a documentação gerada, o 
dicionário de dados, as especificações feitas pelos analistas etc.
Ao tratar de documentação e dicionário de dados, não menos im-
portante do que validar o entendimento das necessidades de informa-
ção a serem supridas para os sistemas de informação, a modelagem de 
dados cumpre o importante papel de documentar os dados. Se enten-
der corretamente os dados que iremos manipular é importante, tanto 
mais importante será documentar esse entendimento e compartilhá-lo. 
A representação gráfica gerada pelo modelo de dados e a representa-
ção textual produzida pelo dicionário de dados, que é criado junto com 
o modelo de dados, transformam-se com o passar do tempo em um 
elemento fundamental de documentação e de retenção da informação.
Conforme estudamos há pouco, o administrador de dados, ou ana-
lista de sistemas, que está coletando os dados sobre os dados (me-
tadados) tem importante papel na compreensão e na construção dos 
modelos de dados. Mas se esse administrador ou analista investir seu 
precioso tempo na compreensão e não for capaz de reter esse conheci-
mento ao longo do tempo, pouco adiantará. O modelo de dados pode 
ser visto como um repositório de informações que poderá ser futura-
mente compartilhado com outras pessoas.
Sabemos que o processo de construção de um banco de dados é 
incremental e evolutivo, ou seja, precisamos obter uma estrutura que 
possa ser continuamente incrementada com novos elementos, mas 
que, acima de tudo, mantenha a coerência entre os elementos exis-
tentes e os elementos novos que estãosendo agregados. Como garan-
tir que teremos coerência se não tivermos a capacidade de conhecer 
e entender aquilo que já existe no modelo atual? Se não possuirmos 
essa documentação e não formos capazes de compartilhar esse conhe-
cimento, os novos elementos que venham a ser agregados no nosso 
banco de dados poderão ser redundâncias ou cópias dos elementos 
que já existam lá, simplesmente porque não fomos capazes de perce-
ber sua similaridade.
Imagine que um banco de dados já possui uma tabela chamada 
fornecedor. Suponha que outro projeto requer uma tabela chamada 
franqueador e que um terceiro projeto requer uma tabela denomina-
Modelagem de dados 59
da cliente. Aparentemente, seriam três tabelas distintas se o modelo 
de dados, complementado pelo dicionário de dados, não mostrasse 
que, na verdade, as três tabelas poderiam ser representadas por uma 
única denominada empresa e que, conforme o papel que essa empre-
sa desempenhasse em um processo, ela poderia ser qualificada como 
fornecedor, franqueador ou cliente. Isso demonstra a importância de 
compartilharmos o entendimento sobre o que ou quem é um fornece-
dor, um franqueado ou um cliente.
Podemos ter vários tipos de sistemas gerenciadores de bancos de 
dados, passando por diferenças de arquitetura de implementação (hie-
rárquicos, em rede e relacionais) e até por diferentes implementações 
feitas por diferentes fornecedores com suas peculiaridades. Esse é 
mais um motivo para adotarmos uma etapa prévia de modelagem de 
dados durante o ciclo de construção de nosso banco de dados.
Caso não tenhamos esse modelo prévio e partamos diretamente 
para o sistema gerenciador de banco de dados para a construção das 
tabelas, teremos muito pouca, ou nenhuma, flexibilidade para migrar 
futuramente nosso banco de dados de uma plataforma para outra. 
Muitos fornecedores, hoje, já oferecem ferramentas de conversão de 
bancos de dados, ou seja, você está com seu banco de dados implan-
tado no produto X e deseja migrar para o produto Y. O fornecedor do 
produto Y, com objetivo de favorecer sua migração, oferece a você um 
programa utilitário que faz toda a adaptação das estruturas de dados 
do banco de dados do formato X para o formato Y. No entanto, isso 
nem sempre será possível, principalmente se a mudança pretendida 
for entre um modelo rede (com base em estruturas de ponteiros) e um 
modelo relacional (baseado em tabelas relacionadas), por exemplo.
Caso tivéssemos, primeiramente, construído um modelo de da-
dos independente do SGBD (o que é sempre uma boa recomendação, 
como veremos mais à frente), poderíamos utilizar o modelo de dados 
original para derivar a estrutura ao banco de dados X e depois para 
derivar a estrutura ao banco de dados Y. Não dependeríamos de regras 
de conversão entre X e Y, que podem ser sempre muito mais comple-
xas por envolverem, eventualmente, até dois fornecedores diferentes, 
em duas plataformas diferentes. Hoje, boa parte das ferramentas de 
modelagem de dados já possui recursos para criar estruturas de ban-
cos de dados para vários fornecedores de SGBD. Assim, você constrói 
um único modelo de dados usando uma ferramenta independente de 
60 Banco de Dados I
fornecedores que, depois, é capaz de derivar modelos físicos para os 
principais fornecedores de mercado.
Por meio dos pontos apresentados até aqui, pudemos compreen-
der que existem vários bons motivos para se criar um modelo de da-
dos antes de partir diretamente para um sistema gerenciador de banco 
de dados e começar logo a criar tabelas e mais tabelas, sem um pla-
nejamento prévio. Contudo, como nosso objetivo é fazer uma análise 
completa das vantagens e desvantagens do uso dos modelos de dados, 
precisamos também abordar as possíveis desvantagens que essa abor-
dagem pode apresentar.
3.2.2 Desvantagens
Se, por um lado, documentar e planejar as estruturas de dados, 
antes de criá-las efetivamente em uma ferramenta de gerenciamen-
to de banco de dados, podem ser apontados como vantagem, pelos 
benefícios que a documentação produz, por outro, algumas pessoas 
podem apontar justamente a atividade como uma desvantagem, pelo 
tempo que ela demanda. Realmente, a tarefa de documentação, seja 
na criação de um banco de dados ou em qualquer outra etapa do ci-
clo de construção de um sistema de informação, sempre é vista como 
um gasto de tempo adicional, mas isso não significa que ela não seja 
importante ou que não deva ser feita. O equilíbrio entre o que pode e 
o que precisa ser documentado é possível de ser obtido com a práti-
ca. Esse deve ser um ponto a ser observado com cuidado, pois quanto 
mais experiente se torna um administrador de banco de dados, mais 
tendência ele tem em pensar que a simples agregação de mais uma ta-
bela no banco de dados pode ser uma tarefa simples e que não deman-
da muito formalismo. Se a falta de prática pode trazer riscos, a prática 
também pode. Contudo, com a prática podemos adquirir habilidades 
para que a tarefa de documentação seja feita de modo mais objetivo e 
produtivo.
Algumas pessoas também argumentam que um modelo de dados 
é um tipo de representação que os leigos não entendem e que os pro-
fissionais dispensam, ou seja, em um extremo é muito complexo para 
ser entendido por leigos; no outro extremo é muito simples para ser 
útil para quem é um especialista no tema. Logo, seria dispensável, e o 
Modelagem de dados 61
tempo gasto em sua criação poderia ter sido aplicado para criar o ban-
co de dados mais cedo.
Diferentemente desse argumento, no entanto, um modelo de da-
dos não é realmente complexo para ser entendido por um leigo, desde 
que este seja apresentado aos padrões de diagrama que o modelo usa. 
Além disso, à medida que um leigo recebe orientação acerca de como 
interpretar o diagrama, essa tarefa passa a ser tão fácil como interpre-
tar um fluxograma ou a planta de uma casa. Também, para os profis-
sionais da área, o modelo de dados não é dispensável, pois, embora 
seja considerado simples, é capaz de carregar em si muitas informa-
ções de modo objetivo, o que, para um profissional, pode se traduzir 
em aumento de sua produtividade ou diminuição do tempo gasto para 
entender algo, o que, convenhamos, não é nunca uma má ideia.
Ainda, um terceiro ponto que tem sido levantado sobre a desvan-
tagem de fazer um modelo de dados é o fato de que, depois de criado 
o banco de dados físico, o modelo de dados deixaria de ser útil, assim 
como a planta de uma casa logo após a construção e entrega para o 
morador. No entanto, vamos imaginar o processo de desenvolvimento 
de uma aplicação cujo modelo de dados é construído para produzir um 
sistema que será liberado para os usuários finais. Podemos considerar 
que, após a liberação do sistema, embora o modelo de dados deixe de 
ser utilizado, esse modelo daria utilidade ao banco de dados ao qual 
ele deu origem.
Contudo, se em um próximo momento imaginarmos que esse mes-
mo sistema liberado para uso entrará em uma fase de manutenção 
corretiva ou manutenção evolutiva, voltaremos a ver o papel essencial 
que o modelo de dados possui. Evoluir ou corrigir qualquer processo 
ou função dentro de um sistema, sem conhecer o modelo de dado no 
qual se baseia o banco de dados que ele utiliza, é um desafio muito 
grande, principalmente se o analista ou programador que terá essa ta-
refa não tiver participado do desenvolvimento do próprio sistema. Isso 
demonstra que a ideia de que o modelo de dados pode se transformar 
em algo não útil após a criação do banco de dados não é realmente ver-
dadeira, se observarmos o ciclo de desenvolvimento de sistemas como 
mais complexo do que simplesmente algo que tem começo, meio e fim.
Desse modo, podemos concluir que a utilização dos modelos de 
dados durante a fase de análise e projeto de nossos sistemas de in-
62 Banco de Dados I
formação pode ser uma excelente estratégia para favorecer a futura 
criação de estruturas de bancos de dados que realmente suportem as 
necessidades de informação desses sistemas.
3.3 Criaçãoe manutenção de 
um modelo de dados 
Vídeo O processo de criação de um modelo de dados foi definido original-
mente por Chen 1 em sua obra denominada A abordagem entidade-re-
lacionamento para o projeto lógico, em 1977. Esse mesmo método vem 
sendo aprimorado e aperfeiçoado, mas mantém sua estrutura básica 
até os dias de hoje. Isso demonstra que a base conceitual que ele de-
finia há mais de 40 anos era muito robusta e consistente. Chen (1990) 
propunha, já naquela época, que o processo de mapeamento dos da-
dos que dariam origem a um banco de dados fosse baseado em uma 
visão estruturada do mundo real que o modelo representaria.
Podemos compreender hoje que Chen (1990) foi capaz de elabo-
rar uma proposta muito simples e, talvez por isso mesmo, definitiva. 
Sabemos que as grandes invenções, principalmente aquelas que são 
insubstituíveis, são as que mantêm a simplicidade. Vamos tomar como 
exemplo a invenção dos clipes: um simples pedaço de arame dobrado 
em formato espiral, contendo duas espirais, uma externa maior e uma 
interna menor, nas quais pode ser aprisionado um conjunto de folhas 
de papel. Existe invenção mais simples? Existe invenção mais definitiva? 
É verdade que com o passar dos anos o material usado para criar o 
clipe pode ter mudado, o formato das espirais pode ter sido alterado e 
até diferentes tamanhos foram propostos; mas o princípio de tudo foi 
mantido e é quase impossível imaginarmos solução melhor.
A proposta de Chen (1990) para a criação dos modelos de dados 
também era muito simples. Ele dizia que todos os elementos de um 
mundo real observado poderiam ser mapeados por somente dois 
conceitos: as entidades (ou coisas) e os relacionamentos (associações 
entre coisas), conforme podemos observar na Figura 1. Sua proposta 
consistia em aplicar um processo de abstração 2 para extrair do mundo 
real as entidades e os relacionamentos que o compunham.
Peter Pin-Shan Chen é um cien-
tista nascido em Taiwan, profes-
sor de ciência da computação 
na Louisiana State University; é 
conhecido como criador do mo-
delo entidade-relacionamento.
1
O processo de abstração é uma 
operação intelectual em que um 
objeto de reflexão é isolado de 
fatores que comumente estão 
relacionados a ele na realidade.
2
Modelagem de dados 63
Figura 1
Elementos utilizados para a modelagem de dados
Mundo real 
observado Abstração
Entidade
Relacionamento
Fonte: Elaborada pelo autor com base em Chen, 1990.
Essa abordagem acabou por se tornar conhecida como modelo enti-
dade-relacionamento ou modelagem entidade-relacionamento, pois todo 
o processo se baseava em conseguir representar em um diagrama as 
entidades (coisas) e os relacionamentos (associações) observados no 
mundo real que se estava modelando, usando para isso dois elemen-
tos gráficos distintos: um para representar as entidades (um retângulo) 
e um para representar os relacionamentos (um losango), conforme a 
Figura 2. Nela, podemos ver um modelo entidade-relacionamento que 
representa o mundo real, no qual os proprietários de automóveis são 
relacionados aos seus veículos. Nesse mundo real, após observar as re-
gras que regem os relacionamentos, tivemos a identificação de que um 
veículo pode ter como proprietário somente uma pessoa, mas que uma 
pessoa pode ser, ao mesmo tempo, proprietária de vários veículos.
Figura 2
Modelo entidade-relacionamento para proprietários e veículos
PROPRIETARIO VEICULO
N1
possui
Fonte: Elaborada pelo autor com base em Chen, 1990.
Podemos perceber nesse modelo que poucos elementos gráficos 
são capazes de representar muitos conceitos envolvidos no mundo 
real, tais como critérios dos conjuntos, regras de relacionamento, res-
trições etc. Podemos ver no modelo as seguintes regras:
64 Banco de Dados I
 • Existe um conjunto de pessoas que são proprietários de veículos.
 • Pessoas que não possuem veículos não fazem parte do nosso 
modelo.
 • Temos um conjunto de veículos que pertencem a um proprietário.
 • Um veículo não pode ter mais de um proprietário.
 • Veículos que não pertencem a um proprietário não fazem parte 
do modelo.
O poder de representação do modelo entidade-relacionamento 
vem, desde então, sendo reconhecido e não sofre questionamentos. 
Ele é tão simples e, por isso, inquestionável. Hoje, podemos dizer que, 
usando o princípio de entidades e relacionamentos, uma lei poderia 
ser criada para representar todo o mundo. Ela poderia simplesmente 
dizer que o mundo é composto de coisas que eventualmente se rela-
cionam entre si. Essa lei seria aplicável desde o mundo microscópico 
até o mundo macroscópico. Poderíamos ver um átomo se relacionan-
do com outro átomo (para se agregar a ele), ou um vírus se relacionan-
do com uma célula (para atacá-la), ou um planeta se relacionando com 
uma galáxia (para compô-la). Vamos do micro ao macro e conseguimos 
continuar a ver somente dois elementos: entidades e relacionamentos.
Se isso é verdade, então a criação de bancos de dados contendo da-
dos sobre essas coisas do mundo e sobre os relacionamentos que elas 
possuem seria uma mera questão de mapear as características dessas 
coisas e as características desses relacionamentos como atributos (ou 
campos) para os quais atribuiríamos valores. Surge, então, a base para 
a modelagem de dados que levaria à criação de estruturas de dados 
coerentes, o que é um dos requisitos para um banco de dados. Se a 
lei do mundo é verdadeira, reproduzir esse mundo em um banco de 
dados, aplicando-se a mesma lei, só poderia resultar na criação de uma 
estrutura coerente, pois o mundo observado seria a fonte da coerência 
buscada. Sendo fiel ao mundo observado, o modelo construído seria 
também coerente.
O processo de observação do mundo real, para que se pudesse abs-
trair quais elementos estavam lá presentes e como se relacionavam, 
era a chave do sucesso nessa modelagem. Caso houvesse observações 
distorcidas ou não fossem percebidos todos os elementos e seus reais 
relacionamentos, poderíamos chegar a um modelo não coerente e, 
Modelagem de dados 65
portanto, um banco de dados não coerente. Havia o risco de, mesmo 
aplicando o modelo entidade-relacionamento, criarem-se bancos de 
dados não coerentes.
Hoje, sabemos que a abstração das entidades pode ser feita por 
meio de cinco critérios básicos, ou seja, podemos procurar no mundo 
real por cinco tipos de elementos (Quadro 1) e, se os encontrarmos, 
podemos estabelecê-los como entidades e representá-los em nossos 
modelos (COUGO, 1997).
Elementos Descrição Exemplos
Objetos 
concretos
Coisas que conseguimos ver, pegar, manusear, 
medir ou pesar, pois existem concretamente no 
mundo real. Podem ser seres vivos ou inanimados.
Pessoa, veículo, árvore, caneta, 
átomo etc.
Fatos
Coisas que conseguimos ver, presenciar, partici-
par, conhecer ou documentar, pois aconteceram, 
acontecem ou acontecerão.
Casamento, acidente de trânsi-
to, fusão de átomos etc.
Funções
Papéis exercidos por pessoas, veículos, animais ou 
coisas concretas. Podem ser seres vivos ou inani-
mados, porém com qualificação de função.
Médico (pessoa com função 
de prestar serviços de saúde), 
trator (veículo com função de 
prestar serviços rurais) etc.
Interações
Operações em que duas ou mais entidades 
participam. Podem ser originadas por entidades 
das demais categorias aqui descritas, em qualquer 
combinação entre elas. Muitas vezes, podem ser 
confundidas com um fato (o que não significa um 
erro de abstração, pois continuaria a ser uma enti-
dade). Poderia ser, eventualmente, substituído por 
um relacionamento (que veremos a seguir).
Compra (uma pessoa adquire 
um carro), venda (uma empresa 
vende um produto), troca (um 
produto é trocado por outro) 
etc.
Especificações
Representam os modelos ou tipos de coisas, não 
propriamente as coisas. Além disso, guardam da-
dos sobre os tipos de coisas, não sobre as coisas.
Tipo de funcionário (estagiário, 
contratado, terceirizado); guar-
daria dados como: se recebe ou 
não 13º salário,se tem férias ou 
não, quantas horas por semana 
deve trabalhar etc.
Quadro 1
Elementos indicativos de entidades
Fonte: Cougo, 1997.
66 Banco de Dados I
Ao observar o Quadro 1, podemos sintetizar um conceito principal: 
entidades são elementos sobre os quais podemos identificar e arma-
zenar dados ou são elementos que possuem dados de interesse para 
nosso modelo. Observaremos mais à frente que, automaticamente, 
uma entidade se transformará em uma tabela em nosso banco de da-
dos e que os dados mapeados para essa entidade serão, então, arma-
zenados nessa tabela.
Lembre-se de que nossa intenção nesse processo é reconhecer 
quais elementos estamos observando no mundo real e mapeá-los 
como entidades. Portanto, se estamos mapeando o ambiente de um 
hospital, poderemos perceber um médico como “função” ou como “ob-
jeto concreto”; ainda, poderemos ver uma cirurgia como “fato” (algo 
que aconteceu em um dia, hora, local) ou como “interação” (entre mé-
dico, paciente, sala de cirurgia). Independentemente do modo como 
tenhamos detectado a entidade, o importante será reconhecer os atri-
butos (ou características) que pertencem a ela.
Atributos (ou campos) são, portanto, as características que nos fa-
zem perceber uma entidade. Se um carro não tivesse uma cor, uma 
marca, um tamanho, um peso, uma altura, uma largura, um tipo de 
combustível que usa, uma potência de motor etc., não o reconhecería-
mos como “objeto concreto” no mundo real. Se uma venda não tivesse 
um código de produto, uma data, um valor, um modo de entrega, uma 
modalidade de pagamento, também não a reconheceríamos como 
uma “interação” ou como um “fato”.
Cada um desses atributos estará associado a uma entidade por 
meio de uma lista e deverá ter suas propriedades definidas com o uso 
de um dicionário de dados. Por exemplo, um atributo que poderíamos 
elencar para a entidade carro seria “quantidade de portas”. Esse atribu-
to seria do tipo numérico, podendo ter números válidos entre 0 e 5 e 
seria um campo com um conteúdo obrigatório.
Perceba que, nesse instante da modelagem, ainda não teremos 
preocupação com detalhes de implementação, como tamanho do cam-
po numérico (um dígito, dois dígitos etc.), modo como será representa-
do (se é compactado ou não) e assim por diante.
Outro atributo da entidade carro poderia ser o número do chassi. 
Um atributo obrigatório, com um valor alfanumérico (permite letras e 
números), mas com uma importância especial que o atributo “quanti-
Modelagem de dados 67
dade de portas” não tinha. O atributo “número do chassi” poderá ser 
indicado também como identificador único da entidade. Um identi-
ficador único é um atributo que servirá para distinguir um elemento 
do conjunto dos carros de modo único entre os demais elementos do 
mesmo grupo. Ao referenciar o “número do chassi”, identificaremos de 
modo único um carro dentre todos os demais.
Uma entidade pode ter mais de um atributo que seja candidato a 
identificador único. No caso do carro, talvez não tenhamos outro atri-
buto com essa característica, mas, ao olharmos para a entidade pessoa, 
poderemos ver vários atributos com essa característica, como “número 
do RG”, “número do CPF”, “número do cartão PIS”, “número do título de 
eleitor” etc. Todos eles teriam potencial para identificar de modo único 
uma pessoa dentre todas as demais de seu grupo.
Além de termos as “coisas do mundo” sendo percebidas por meio 
de suas características, elas também poderão ser agrupadas em classes 
ou entidades por causa da similaridade de suas características. Duas 
pessoas que têm a mesma profissão, atendem aos mesmos requisitos 
e têm características pessoais compatíveis etc. podem ser agrupadas 
na entidade “médico”. Porém, não colocaríamos na entidade “médi-
co” alguém que trabalha consertando carros e alguém que trabalha 
executando cirurgias. Só agruparíamos como coisas (ou instâncias) 
da entidade “médico” dois profissionais que, no mundo real, possam 
ser reconhecidos pelas mesmas características ou por características 
compatíveis.
Esse tipo de particularidade na compatibilidade de atributos é o 
que, muitas vezes, faz-nos perceber e modelar um “médico” e um “me-
cânico” separadamente, em vez de simplesmente modelá-los como 
“pessoas”. Esse conceito de segmentação de objetos em subgrupos, 
de acordo com suas funções ou especificidades, foi uma das caracte-
rísticas agregadas ao modelo entidade-relacionamento com evolução 
de sua abordagem. Ao perceber que temos subgrupos dentro de um 
grupo maior, passamos a identificar em nosso modelo um novo tipo de 
representação para essas entidades. Podemos dizer que temos uma 
“especialização” ou “generalização” da entidade. 3
A Figura 3 demonstra um exemplo de modelo entidade-relaciona-
mento com a extensão da semântica de generalização-especialização. 
Nela, a entidade “médico” e a entidade “paciente” são especializações 
Esse conceito foi muito 
explorado quando a modelagem 
orientada a objetos e a análise 
orientada a objetos surgiram nos 
anos 90; foi incorporado como 
uma extensão do modelo enti-
dade-relacionamento original, a 
fim de aperfeiçoar a semântica 
que ela busca representar.
3
68 Banco de Dados I
da entidade “pessoa”. A figura demonstra que em uma “cirurgia” po-
demos ter vários médicos, mas somente 1 paciente; entretanto, por 
outro lado, um paciente pode participar de muitas cirurgias, assim 
como um médico.
Figura 3
Modelo entidade-relacionamento com generalização-especialização
PESSOA CIRURGIA
N
N
M
1
MEDICO
PACIENTE
executa
participa
Fonte: Elaborada pelo autor com base em Chen, 1990.
Já tendo capacidade de identificarmos as entidades, com ou sem 
generalizações e especializações e seus respectivos atributos (ou ca-
racterísticas), resta-nos agora desenvolver a capacidade de reconhecer 
e mapear os relacionamentos que essas entidades possuem entre si.
Para esse fim, Chen (1990) também definiu alguns simples elemen-
tos gráficos que poderiam agregar a semântica necessária ao modelo 
de dados criado. Basicamente, o único elemento gráfico utilizado é um 
losango. A ele são atribuídos valores representativos da cardinalidade 
do relacionamento, ou seja, o número de elementos que o relaciona-
mento envolve, baseado na regra de associação que o próprio mundo 
real observado possui.
Desse modo, poderemos representar relacionamentos de três car-
dinalidades distintas. A primeira, conforme demonstra a Figura 4, tem 
o grau de 1:1 (leia-se 1 para 1). Esse tipo de cardinalidade representa re-
lacionamentos em que um elemento da entidade A tem somente uma 
associação com um elemento da entidade B e vice-versa. Por exemplo, 
se em determinada empresa uma vaga pode ser ocupada por somente 
um funcionário (de cada vez) e cada funcionário só pode ocupar uma 
vaga, então nosso modelo seria como o representado a seguir.
Modelagem de dados 69
Figura 4
Exemplo de um relacionamento de cardinalidade 1:1
VAGA FUNCIONARIO
N1
é ocupada
Fonte: Elaborada pelo autor com base em Chen, 1990.
A próxima representação de cardinalidade possível é aquela em que 
um elemento da entidade A pode possuir associações com vários ele-
mentos da entidade B, enquanto cada elemento da entidade B só pode 
estar associado a um único elemento da entidade A. Esse tipo de car-
dinalidade é definido como de grau 1:N (leia-se 1 para N ou 1 para mui-
tos). Se em uma empresa, por exemplo, um departamento puder ter 
vários funcionários alocados a ele, mas cada funcionário só puder ser 
alocado em um único departamento, então nosso modelo seria como 
o representado na Figura 5.
Figura 5
Exemplo de um relacionamento de cardinalidade 1:N
DEPARTAMENTO FUNCIONARIO
N1
tem alocado
Fonte: Elaborada pelo autor com base em Chen, 1990.
Finalmente, a terceira cardinalidade disponível para ser represen-
tada em nosso modelo de dados é a de grau M:N (leia-se M para N ou 
muitos para muitos). Nesse tipo de relacionamento, um elemento da 
entidade A pode estar associado a vários elementos da entidade B, en-
quanto cadaelemento da entidade B pode também estar associado a 
vários elementos da entidade A. Esse tipo de relacionamento equivale 
a uma estrutura matricial, em que linhas e colunas se interceptam e 
criam uma associação entre um item de uma linha e um item de uma 
coluna. Por exemplo, se um funcionário pode executar várias tarefas e 
uma dada tarefa pode ser executada por vários funcionários, então o 
modelo seria representado pela Figura 6.
70 Banco de Dados I
Figura 6
Exemplo de um relacionamento de grau M:N
FUNCIONARIO TAREFA
NM
executa
Fonte: Elaborada pelo autor com base em Chen, 1990.
A interseção entre funcionários e tarefas seria uma coleção de itens 
que demonstraria a alocação de funcionários a cada uma das tarefas. 
Já olhando-se do ponto de uma tarefa, poderíamos descobrir quais fun-
cionários foram alocados para ela (podem ser vários). Essa estrutura 
que demonstra uma alocação de funcionários a determinadas tarefas 
poderia também ser representada por uma estrutura diferente, em 
que o relacionamento de grau M:N fosse substituído por dois relacio-
namentos 1:N, ocorrendo entre as entidades A e B com uma nova en-
tidade C, que passaria a ser representativa do relacionamento, agora 
transformado em uma entidade do tipo “interação” (Figura 7).
Figura 7
Mapeamento do relacionamento M
FUNCIONARIO ALOCACAO TAREFA
1 1N N
participa e de uma
Fonte: Elaborada pelo autor com base em Chen, 1990.
Como podemos observar na Figura 7, um funcionário pode parti-
cipar de uma ou de várias alocações e cada uma delas está associada 
a uma tarefa. Quando olhamos do ponto de uma tarefa, podemos ver 
que ela pode estar vinculada a uma ou várias alocações e que cada alo-
cação, por sua vez, é associada a somente um funcionário.
Essa transformação de um relacionamento de grau M:N em dois re-
lacionamentos de grau 1:N não é um acaso, mas uma regra que sempre 
poderá ser aplicada para simplificar o modelo. Porém, não é obrigató-
rio que se use esse artifício, já que do ponto de vista de modelagem 
Modelagem de dados 71
conceitual, proposto por Chen (1990), não há restrições em manter os 
relacionamentos com grau M:N no modelo.
Ainda outro elemento poderia ser agregado ao relacionamento: a 
indicação da sua opcionalidade; ou seja, se ele é obrigatório ou não. 
Essa é uma melhoria da semântica do modelo que pode ser agregada 
por meio de elementos gráficos adicionais.
Todos esses exemplos descritos envolveram sempre uma entidade 
A e uma entidade B. Contudo, é bom destacar aqui que existe um tipo 
especial de relacionamento chamado autorrelacionamento, no qual o 
vínculo de elementos se dá entre diferentes elementos da mesma en-
tidade. Todas as características já apresentadas até aqui para as cardi-
nalidades 1:1, 1:N e M:N continuam válidas no autorrelacionamento.
No exemplo da Figura 8, podemos ver um autorrelacionamento en-
tre a entidade funcionário e a entidade funcionário. Podemos interpre-
tá-lo assim: um funcionário gerencia N funcionários, e N funcionários 
são gerenciados por um funcionário. Assim como esse, outros autorre-
lacionamentos podem ser criados.
Figura 8
Exemplo de um autorrelacionamento.
N
1
FUNCIONARIO gerencia
Fonte: Elaborada pelo autor com base em Chen, 1990.
Assim, podemos entender que poucos elementos gráficos propos-
tos pela abordagem “entidade-relacionamento” são capazes de repre-
sentar uma infinidade de situações práticas do mundo real, registrando 
suas características e inter-relacionamentos, uma excelente ferramen-
ta para a modelagem de dados.
72 Banco de Dados I
3.4 Tipos de modelos de dados
Vídeo O modelo de dados proposto por Chen (1990) na abordagem en-
tidade-relacionamento é independente de arquitetura de implemen-
tação, ou seja, não é hierárquico, nem rede nem relacional. Ele é um 
modelo conceitual.
Esse modelo conceitual, porém, deverá ser transformado, por meio 
de regras de conversão, em um modelo lógico que implemente a arqui-
tetura hierárquica, rede ou relacional, conforme a necessidade do pro-
jeto. Como o modelo relacional, hoje, detém grande parte do mercado 
como sendo o mais utilizado, observaremos as regras de conversão do 
modelo conceitual para o modelo relacional.
Futuramente, esse modelo lógico (relacional) será transformado 
também em um modelo físico, com a definição de características físi-
cas, como tamanho para alocação de espaço em disco, estruturas de 
índices etc.
O objetivo de conversão é transformar, portanto, um modelo ge-
nérico e com mais semântica em um modelo específico de uma tecno-
logia; nesse caso, a tecnologia relacional. Para cumprir essa tarefa de 
conversão, deveremos respeitar os requisitos da tecnologia relacional.
A primeira regra de conversão determina que cada entidade do mo-
delo conceitual deve ser transformada em uma tabela, ou seja, tere-
mos tantas tabelas quanto o número de entidades do modelo. 4
Já a segunda regra de conversão determina que cada atributo (cam-
po) associado a uma entidade deverá ser transformado em uma coluna 
na tabela, em que ele aparece localizado no modelo conceitual. Segun-
do Heuser (2009), deveremos escolher um dentre os atributos que per-
mitem o campo como identificador único para a entidade. Isso deve 
ocorrer a fim de que este se transforme em chave da tabela (o modelo 
relacional exige um ou mais campos para formar sua chave de aces-
so), ou chave primária. Os demais campos que poderiam ser as chaves, 
mas não foram escolhidos, são chamados de chaves candidatas. Criadas 
as tabelas, com suas devidas chaves e suas demais colunas, devemos 
partir para a próxima fase, que é a da conversão dos relacionamentos. 
Cada relacionamento será convertido com o uso de colunas especiais 
chamadas chaves estrangeiras.
Acesse o vídeo Bancos de 
Dados - Aula 02 – Modelo 
Entidade-Relacionamento 
(MER) - Parte I, do canal 
UNIVESP. Nele, é apre-
sentada uma aula sobre o 
processo de modelagem 
conceitual e de modela-
gem lógica, por meio de 
uma abordagem bastante 
objetiva e abrangente do 
assunto.
Disponível em: https://www.you-
tube.com/watch?v=oPlXecD-gZM. 
Acesso em: 31 mar. 2020.
Vídeo
Não abordaremos aqui as regras 
de conversão de estruturas de 
especialização e generalização, 
pois são estruturas mais avança-
das de modelagem.
4
Modelagem de dados 73
Por outro lado, a terceira regra de conversão se aplica ao relaciona-
mento de grau 1:1. Ela determina que, sempre que existir um relaciona-
mento 1:1 entre a entidade A e B, deveremos criar, na entidade B, uma 
nova coluna que seja cópia da coluna chave da entidade A ou vice-versa. 
Como a relação é do grau 1:1, tanto faz se importarmos para a entidade 
A a chave da entidade B ou da entidade B para a entidade A. Se, por 
exemplo, importamos a chave da entidade A para a entidade B, dizemos 
que esta tem, agora, a chave estrangeira da entidade A (Figura 9).
Figura 9
Processo de conversão de um relacionamento 1:1
CARRO PESSOA
11
pertence a
Num_chassis (Ident. Único)
Qtde. de portas
Potência
Cor
Tabela carro Tabela pessoa
Num_chassis (Chave primária) CPF (Chave primária)
Qtde. de portas Nome
Potência Data de nascimento
Cor Sexo
CPF (Chave estrangeira de pessoa)
CPF (Ident. Único)
Nome
Data nascimento
Sexo
Fonte: Elaborada pelo autor com base em Chen, 1990.
De modo similar, a quarta regra de conversão se aplica ao relacio-
namento 1:N. Essa regra define que, existindo um relacionamento de 
grau 1:N entre a entidade A e B, sendo A a entidade de grau 1 e B a en-
tidade de grau N, deverá ser criada, na entidade B, uma coluna que seja 
cópia da coluna chave da entidade A (chave estrangeira de A). Nesse 
caso, a inversão de papéis entre A e B não se aplica. Sempre a chave da 
entidade A deverá ser importada para a entidade B, nunca o contrário.
Por fim, a quinta e última regra determina que, havendo uma re-
lação de grau de M:N entre as entidades A e B (já transformadas em 
tabelas A e B), deve-se criar uma tabela C, que receberá as colunas cha-
ves da entidade A e da entidade B, sendoessas duas colunas (chave 
estrangeira de A e chave estrangeira de B) a nova chave da tabela C.
O vídeo Construindo um 
modelo de Banco de dados 
lógico utilizando BRMode-
lo, do canal Infordiversao, 
apresenta o processo de 
criação de um modelo de 
dados utilizando uma fer-
ramenta de modelagem 
gráfica, com recursos de 
especialização-generali-
zação, relacionamentos, 
entidades e atributos.
Disponível em: https://www.you-
tube.com/watch?v=sItFiqAN5YY. 
Acesso em: 31 mar. 2020.
Vídeo
74 Banco de Dados I
Portanto, entendemos que a aplicação de poucas regras de con-
versão sobre um modelo conceitual poderá produzir um modelo ló-
gico orientado a uma topologia, seja ela relacional ou não, de modo 
a permitir que a implementação de um banco de dados físico seja 
concretizada.
CONSIDERAÇÕES FINAIS
Neste capítulo, pudemos conhecer o processo de modelagem de da-
dos usando a abordagem entidade-relacionamento, que foi aperfeiçoada 
ao longo de muitos anos de utilização.
Podemos aqui destacar que, além de conhecer os detalhes de um 
sistema gerenciador de banco de dados, o mais importante no proces-
so de construção de um modelo de dados coerente é ter a capacidade 
de observar o “mundo real” que iremos modelar e sermos capazes de 
abstrair as entidades e relacionamentos que o compõem. Caso nosso mo-
delo entidade-relacionamento tenha sido construído de modo coerente, 
sua conversão em um modelo relacional será uma tarefa muito simples, 
baseada em poucas regras padronizadas.
Assim, é necessária concentração na tarefa de observação e abstra-
ção de entidades e relacionamentos, para assegurar futuramente que seu 
modelo de dados esteja estável, coerente, fidedigno e realista.
Além disso, podemos destacar que a criação de modelos de entidade-
-relacionamento é uma tarefa, como as demais, que se aprimora com a 
experiência. Essa tarefa de modelagem é desafiadora no sentido de que 
exige cada vez mais conhecimento dos “mundos reais”, os quais nunca 
tínhamos parado para observar. O desafio do aprendizado terá, então, 
sido transformado no prazer de descobrir tantas informações antes 
desconhecidas.
ATIVIDADES
1. Justifique por que a criação de um banco de dados não é uma atividade 
intuitiva que possa ser realizada sem planejamento.
2. Explique por que a atividade de modelagem pode ser vista, ao mesmo 
tempo, como benefício por alguns e desvantagem por outros.
3. Explique por que uma entidade não pode existir sem pelo menos um 
atributo.
4. Qual é a vantagem de se utilizar o processo de derivação para obtenção 
do modelo lógico?
Modelagem de dados 75
REFERÊNCIAS
COUGO, P. Modelagem conceitual e projeto de bancos de dados. Rio de Janeiro: Elsevier, 
1997.
CHEN, P. Gerenciando banco de dados: a abordagem entidade-relacionamento para projeto 
lógico. São Paulo: McGraw-Hill, 1990.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
76 Banco de Dados I
4
Modelo relacional e 
normalização
O modelo relacional é, hoje, a principal alternativa para a cons-
trução de um banco de dados de um sistema de informação, seja 
de uso pessoal, corporativo, um app para celular ou, ainda, para 
um grande sistema de gestão empresarial a ser executado e aces-
sado por meio de nuvem.
A grande quantidade de fornecedores e produtos oferecidos na 
categoria de sistemas gerenciadores de BD relacionais (SGBDR) – 
que vão desde as opções open-source (aquelas que podemos usar 
sem pagar) até aquelas que podem custar milhares ou milhões 
de dólares – faz com que mesmo um simples sistema de gestão 
de finanças pessoais, por exemplo, possa utilizar uma plataforma 
relacional para armazenar seus dados. De outro lado, podemos 
encontrar sistemas que integram milhares de pessoas em torno de 
gigantescas bases de dados.
Isso demonstra que esse ambiente relacional não apresenta 
maior complexidade para sua compreensão nem para sua adoção 
como uma tecnologia para desenvolvimento de sistemas. Também 
demonstra que este ambiente é flexível e escalável para atender a 
pequenas, médias e grandes demandas.
Assim, vamos conhecer, neste capítulo, os principais conceitos 
utilizados para estabelecer as regras e o modo de funcionamento 
de todo o modelo relacional. Se você está curioso para conhecer 
mais sobre este assunto, acompanhe-nos em mais esta etapa.
Modelo relacional e normalização 77
4.1 O que é e para que serve um 
modelo relacional? 
Vídeo O ponto de partida do modelo relacional está baseado em conceitos 
muito simples que certamente você já viu nos seus primeiros anos na 
escola, em especial no ensino fundamental. Esse conteúdo ao qual nos 
referimos é a teoria dos conjuntos.
A teoria dos conjuntos foi elaborada pelo mate-
mático russo Georg Cantor (1845-1918), nos anos 
1870. Ele publicou materiais que tratavam do estudo 
das propriedades dos conjuntos, das suas relações, 
das relações entre seus elementos e do próprio 
conjunto. Em uma definição simples, mas formal, 
podemos definir conjunto como o agrupamento de 
elementos que possuem características semelhan-
tes, ou uma coleção de objetos.
Se você parar para observar essa definição, verá 
que ela cita alguns elementos importantes, os quais 
já vimos quando definimos o que era entidade no 
processo de modelagem entidade-relacionamento. 
Vimos, por exemplo, que é possível observar vários 
objetos ou “coisas” no mundo real e reconhecer pro-
priedades ou características comuns que eles possuem.
Assim sendo, não lhe parece que o conceito de entidade se confunde 
com o conceito de conjunto? Além disso, não parece que uma entidade 
poderia ser um conjunto de elementos que têm as mesmas caracterís-
ticas? Sim, os conceitos são similares.
Seguindo mais adiante, se observarmos a teoria dos conjuntos, ve-
remos que os elementos que compõem determinado conjunto podem 
se relacionar com elementos de outros conjuntos e que essa associa-
ção é chamada de relação entre conjuntos. Mais uma vez, não lhe parece 
que esse conceito se assemelha com o conceito de relacionamento da 
modelagem entidade-relacionamento? Sim, existe total semelhança.
Com base nessas similaridades, Edgar Frank Codd (1923-2003), pes-
quisador da empresa IBM, publicou, em 1970, um artigo denominado
Vídeo
No vídeo Teoria dos 
conjuntos, publicado pelo 
canal Matemática em 
Exercícios, você terá a 
oportunidade de rever 
conceitos básicos sobre 
conjuntos e opera-
ções que podem ser 
realizadas. Você poderá 
identificar como a teoria 
relacional se aproveita 
desses conceitos para 
estabelecer seu modo 
de funcionamento.
Disponível em: https://www.
youtube.com/watch?v=Z92-qwA-
ZJgY. Acesso em: 22 abr. 2020.
78 Banco de Dados I
Modelo relacional de dados para grandes bancos de dados compartilha-
dos 1 , no qual apresentou uma proposta para que o armazenamento 
e a manipulação de grandes bases de dados pudessem ser feitos uti-
lizando-se todos os princípios matemáticos da teoria dos conjuntos.
Podemos dizer, assim, que Codd foi o responsável pelo surgimento 
do modelo relacional aplicado hoje a todos os BDs relacionais, mas não o 
criador da teoria relacional. A teoria relacional é, na verdade, uma trans-
posição da teoria dos conjuntos criada quase 100 anos antes por Cantor.
É precisamente o conhecimento dessa teoria – ou a revisão dos seus 
conceitos – que fará com que possamos entender claramente o quão 
simples foi toda a concepção do modelo relacional e como podemos 
ter certeza de que ele realmente é coerente e íntegro.
A palavra integridade é justamente um dos pontos centrais de todo o 
modelo relacional, pois, até antes de sua adoção, o principal problema 
encontrado com os BDs da época era o fato de seus dados perderem 
a integridade ao longo do tempo. Considere o seguinte exemplo: no 
registro de um funcionário em um banco de dados, poderíamos inserir 
a informação de que ele nasceu na cidade do Rio de Janeiro. Porém, ao 
buscarmos os dados dessa cidade em outra porção do BD, descobri-
mos que alguém a excluiu porque achou que nãohavia mais nenhum 
funcionário nascido no Rio de Janeiro. Nesse caso, podemos dizer que 
perdemos a integridade em relação às informações dos funcionários e 
perdemos, também, as informações das cidades.
Com o advento do modelo relacional e com base na própria teoria 
dos conjuntos, fica claro que não poderíamos excluir as informações 
sobre a cidade do Rio de Janeiro enquanto existisse pelo menos um 
funcionário associado a esse registro no banco de dados. Isso garanti-
ria a integridade atual e futura dos nossos dados.
O quadro a seguir elenca os principais conceitos oriundos da teoria 
dos conjuntos que são aplicados no modelo relacional.
Em inglês, Relational model of 
data for large shared data banks.
1
Modelo relacional e normalização 79
Quadro 1
Conceitos da teoria dos conjuntos usados no modelo relacional
Conceito Definição Elemento do modelo relacional
Conjunto
Agrupamento de elementos com 
 características semelhantes.
• Tabela
Relação
Associação, vínculo ou correspondência 
entre elementos de diferentes conjuntos.
• Relacionamento
• Chave estrangeira
Elementos Itens que compõem um conjunto • Linha
Características 
dos elementos
Propriedades comuns que cada elemento 
possui com os demais do seu conjunto.
• Coluna
• Chave primária
• Chave secundária
• Chave candidata
• Índice
Operação
União, intersecção, diferença ou produto 
cartesiano de elementos de diferentes con-
juntos com base em critérios associativos.
• Operação
Integridade
Garantia de que valores ou referências 
entre elementos sejam sempre válidos.
• Integridade de identidade
• Integridade referencial 
• Integridade de domínio
Fonte: Elaborado pelo autor.
O primeiro conceito incorporado ao modelo relacional é o de con-
junto, que, na teoria relacional, transforma-se em uma tabela. Uma 
tabela reúne os dados de todos os elementos que têm características 
semelhantes. Quando tivermos uma tabela FUNCIONARIO no nosso 
banco de dados, teremos lá reunidos todos os dados de elementos que 
tenham características semelhantes (são funcionários na vida real).
O segundo conceito é a relação, que, na teoria relacional, converte-
-se em um relacionamento entre duas tabelas. Se a relação vincula ele-
mentos de diferentes conjuntos, o relacionamento vincula diferentes 
elementos de diferentes tabelas.
Para ilustrar, analise o seguinte exemplo: quando tivermos que re-
lacionar um FUNCIONARIO com a CIDADE onde ele nasceu, teremos 
duas tabelas distintas: uma para agrupar funcionários e outra para 
agrupar cidades. Cada tabela representa um diferente conjunto – o 
80 Banco de Dados I
conjunto dos funcionários e o conjunto das cidades. Dessa forma, tere-
mos que gerar uma associação entre eles, a qual respeitará a cardina-
lidade (quantidade de elementos) do relacionamento. Nesse exemplo, 
temos um relacionamento de grau 1:N (um para muitos) entre cidade e 
funcionário, no qual uma cidade pode ter vários funcionários nascidos 
nela, mas um funcionário só pode ter nascido em uma única cidade.
Na figura a seguir, podemos ver modelo E-R e sua representação do 
ponto de vista de conjuntos.
Figura 1
Modelo E-R entre CIDADE e FUNCIONARIO e sua representação em formato de conjuntos e 
tabelas
Modelo E-R Representação dos conjuntos Tabelas
CIDADE
FUNCIONARIO
1
N
nascem
CWB RJ SP
Jose Joao Maria
TABELA CIDADE
Cód. Nome Pop.
01 CWB 3 m.
02 RJ 5 m.
03 SP 10 m.
TABELA FUNCIONARIO
Cód. Nome Sexo Cidade
15 Jose M 01
23 Joao M 02
37 Maria F 02
Fonte: Elaborada pelo autor.
O terceiro conceito são os elementos que compõem o conjunto 
e que se transformam, no modelo relacional, em tuplas ou linhas 
da tabela. Se observarmos o conjunto dos FUNCIONARIOS, ele será, 
no exemplo anterior, formado por três elementos, e o conjunto das 
 CIDADES também será formado por três elementos. Isso produz, em 
cada tabela, o equivalente a três linhas, cada uma representando os 
dados de cada elemento.
No vídeo Mapeamen-
to MER para modelo 
relacional, publicado pelo 
canal Geraldo Corrêa, 
você poderá rever em 
detalhes vários exemplos 
de modelos E-R sendo 
convertidos para os 
seus devidos modelos 
relacionais por meio da 
aplicação de regras de 
derivação.
Disponível em: https://www.you-
tube.com/watch?v=LqmJOAwTc0U. 
Acesso em: 22 abr. 2020.
Vídeo
Tupla: cada linha formada por 
uma lista ordenada de colunas 
representa um registro ou tupla.
Glossário
Modelo relacional e normalização 81
A coleção de colunas que dará origem a uma tabela será depen-
dente da coleção de atributos que foram levantados no momento da 
modelagem entidade-relacionamento. Adicionalmente à lista dos atri-
butos inerentes a cada entidade, devemos lembrar que, também em 
nossas tabelas, teremos que incorporar dois tipos de colunas adicio-
nais: as chaves primárias e as chaves estrangeiras.
A chave primária será naturalmente um dos campos inerentes à en-
tidade (um dos campos candidatos à chave). Porém, frequentemente, 
apesar de existir um campo candidato à chave para uma tabela, cria-se 
um novo campo “artificial” (que não apareceu na modelagem E-R) para 
ser a chave primária da tabela. Ele é, normalmente, um campo numéri-
co, sequencial, gerado pelo próprio SGBD e incrementado automatica-
mente a cada nova linha que gravamos no banco dados.
Imagine a seguinte situação: a tabela FUNCIONARIO pode conter 
colunas como CPF, RG, número do título de eleitor ou outros campos 
candidatos à chave primária (pois são identificadores únicos) e até a 
chaves secundárias, isto é, chaves que também servem para acesso, 
porém não serão referenciadas nas chaves estrangeiras.
Imagine, também, que criaremos um novo campo de nome “codigo 
do funcionario” que será a chave primária de nossa tabela e iniciado 
em 0001. Esse campo será incrementado automaticamente para cada 
novo funcionário cadastrado e se transformará, talvez, em um número 
agregado ao crachá do funcionário e em um código de identificação 
dentro da empresa. Percebe-se com isso, que, muitas vezes, uma chave 
artificial acaba se transformando em um campo de uso dos processos 
de negócio, isto é, ela não é somente um artifício usado pelo admi-
nistrador do banco de dados para facilitar os relacionamentos entre 
tabelas.
O uso de campos artificiais do tipo código – como no exemplo do 
funcionário – é muito utilizado para simplificar a criação das futuras 
chaves estrangeiras em outras tabelas. Assim, sempre que outra tabela 
precisar se relacionar com a tabela FUNCIONARIO, ela poderá usar o 
“codigo do funcionario” – um campo número e sequencial, logo sim-
ples – em vez de ter que usar o número do CPF, que é mais complexo, 
envolve regras de preenchimento, tem dígito verificador e ocupa mais 
espaço (um CPF tem 11 dígitos).
82 Banco de Dados I
Todas as colunas em uma linha – que venham, de algum modo, a 
ser referenciadas como chave primária, chave secundária ou chave es-
trangeira e que terão, portanto, finalidade de permitir o acesso direto 
a um registro dentro do banco de dados – terão que ter uma estrutura 
de índices associada a seus valores.
Índices são estruturas de dados especialmente criadas pelo SGBD, 
ou seja, não precisam ser controladas pelo programador, para permitir 
o acesso rápido a um registro sem ter que ler todo o banco de dados 
para encontrá-lo. Eles consomem recursos do banco de dados tanto 
para armazenamento em disco quanto para processamento. Quanto 
maior a quantidade de índices criados sobre as colunas de uma tabe-
la, maior será o consumo extra de recursos para mantê-los. Eles são 
obrigatórios para as chaves primárias e para as chaves estrangeiras, 
logo não há muito a questionar sobre usá-los ou não. Entretanto, para 
as demais colunas da tabela, durante a fase de projeto do banco de 
dados, teremos que avaliar se eles são vantajosos.
O quarto conceito são as características de cada elemento. Ele não 
é facilmente observado no conjunto que fizemos (Figura 1), mas, quan-
do convertidos em colunas da tabela, ficam bem evidentes.Em nosso 
exemplo, podemos ver que cada cidade possui um nome e uma quanti-
dade de população – essas são as características que a definem. Todas 
as cidades possuem essas características, ou seja, não teremos cidades 
sem nome ou sem uma quantidade de população, mesmo que a quan-
tidade seja zero. Por outro lado, todos os funcionários têm nome, sexo 
e nasceram em uma cidade. O vínculo com a cidade onde nasceram 
é feito por meio de uma chave estrangeira, um campo que existe na 
tabela funcionário, mas que contém o valor de uma chave da tabela “ci-
dade”. Sendo assim, a integridade está garantida, pois não poderemos 
vincular um funcionário a um código que não exista na tabela “cidade”.
Conforme já discorrido nos parágrafos anteriores – quando falamos 
sobre a escolha das chaves primárias e da criação das chaves estran-
geiras –, as características dos elementos se transformarão nas colunas 
das tabelas, que formarão suas linhas. Alguns detalhes precisarão ser 
agregados futuramente às definições dessas colunas. Por exemplo, se 
elas têm preenchimento obrigatório ou não, se permitem duplicação de 
valores em suas linhas etc. Durante a fase de projeto do banco de da-
dos, esses requisitos acabarão sendo agregados ao modelo relacional.
Modelo relacional e normalização 83
O último conceito são as operações que acontecem por meio das 
funções de união (ou junção), intersecção, diferença ou produto car-
tesiano entre dois conjuntos ou entre duas tabelas, já que as tabelas 
acabam por representar os conjuntos. Vejamos cada um dos casos.
A união entre dois conjuntos permite que dois conjuntos seme-
lhantes (algo relevante de se destacar) – isto é, que contenham dife-
rentes elementos com as mesmas características – sejam unidos, 
resultando em um novo conjunto. Uma propriedade importante, po-
rém, deve ser observada: os elementos que se repetem nos dois con-
juntos não se duplicam. Somente um elemento distinto de cada objeto 
será mantido no conjunto final.
Vamos pensar em um exemplo genérico, no qual temos dois con-
juntos de frutas: o conjunto das frutas grandes e o conjunto das frutas 
com casca verde. Perceba que, nos dois conjuntos, temos sempre fru-
tas, por isso podemos uni-los.
Se no primeiro conjunto tivermos, por exemplo, as frutas melancia, 
melão e jaca e fizermos a união com o segundo conjunto, formado por 
melancia, jaca e limão, ficaremos com um conjunto de quatro frutas dis-
tintas: melancia, melão, jaca e limão. Após a união, dois conjuntos de 
três elementos deram origem a um conjunto final de quatro elementos. 
A melancia e a jaca – que são frutas grandes e de casca verde – não apa-
recem duas vezes no conjunto final, pois nossa intenção não é contar 
quantas melancias ou jacas temos, mas criar uma lista das frutas que 
existem e que podem ser grandes e de casca verde. A melancia e a jaca 
aparecem uma vez só nessa lista, mesmo atendendo aos dois critérios.
Em uma operação de união feita sobre o modelo relacional, devería-
mos ter dois conjuntos de dados similares obtidos de duas tabelas dife-
rentes, mas que consigam produzir listas com características similares. 
Um exemplo seria termos contratos vigentes em uma tabela chamada 
CONTRATO VIGENTE e, depois, acessarmos outra tabela, chamada HIS-
TORICO DE CONTRATOS. Poderíamos obter, de ambas as tabelas, duas 
listas: número do contrato, data de criação e CPF do proprietário. Ao final 
da operação, poderíamos ter uma lista de todos os contratos com seus 
CPFs, sejam eles vigentes ou já encerrados (que estariam no histórico).
Outra operação interessante é a intersecção ou junção de dois 
conjuntos, operação na qual se consegue, por meio de dois conjuntos, 
como o próprio nome sugere, produzir um terceiro conjunto. Esse ter-
84 Banco de Dados I
ceiro conjunto é a somatória dos dados que lhe deram origem quando 
um elemento comum entre os dois for encontrado. Existe, portanto, 
uma intersecção entre eles.
Quando essa operação é aplicada ao modelo relacional, ela se trans-
forma em um meio de agregar dados de duas tabelas, o que é muito 
útil. Considere uma situação na qual precisamos criar um relatório em 
que os dados dos funcionários e das cidades onde eles nasceram de-
vam ser apresentados em uma tela. Podemos fazer uma junção entre 
as tabelas FUNCIONARIO e CIDADE, vistos na Figura 1. Teremos, então, 
uma nova tabela como resultado.
TABELA CIDADE
Cód. Nome Pop.
01 CWB 3 m.
02 RJ 5 m.
03 SP 10 m.
TABELA FUNCIONARIO
Cód. Nome Sexo Cidade
15 Jose M 01
23 Joao M 02
37 Maria F 02
TABELA JUNCAO
Cód. Nome Sexo Cód. Nome Pop.
15 Jose M 01 CWB 3 m.
23 Joao M 02 RJ 5 m.
37 Maria F 02 RJ 5 m.
Figura 2
Junção de duas tabelas no modelo relacional
Fonte: Elaborada pelo autor.
Esse exemplo demonstra que agora, com a tabela JUNCAO – que 
pode ser temporária ou definitiva –, teremos todos os dados necessá-
rios para criar o relatório solicitado. Poderemos mostrar os dados so-
bre cada funcionário e a cidade onde ele reside; dessa maneira, temos 
todos os dados agregados.
O ponto importante nessa operação relacional é que o conjunto re-
sultante será aquele ao qual tenhamos a possibilidade de agregar da-
dos de cada um dos conjuntos de origem por meio de um campo que 
permita relacioná-los – no caso, o campo “código da cidade”. Perceba 
que, no conjunto resultante, não temos qualquer referência aos da-
dos de “SP”, pois não havia nenhum funcionário nascido nessa cidade. 
Modelo relacional e normalização 85
Isso significa que a junção utilizará um relacionamento ou uma relação 
existente entre os dois conjuntos para somar os dados das tabelas ori-
ginais em torno da relação que pôde ser estabelecida.
A terceira operação é a diferença entre conjuntos. Em uma operação 
na qual um conjunto denominado conjunto 3 é o resultado, um conjunto 1 
de elementos será removido de dentro de outro conjunto 2, resultando 
em um novo conjunto 3, que é menor do que o conjunto 2 original.
Vamos aplicar a esse exemplo os mesmos conjuntos anteriores. O 
conjunto 1, que deverá ser subtraído, é agora o conjunto das frutas 
verdes. Ele será subtraído do conjunto das frutas grandes, que será o 
conjunto 2. Teremos como resultado um conjunto 3, que será o das fru-
tas grandes que não tenham casca verde. Se temos três frutas grandes 
(melancia, jaca e melão) e retiramos desse conjunto as frutas verdes 
(melancia e jaca), ficaremos somente com a fruta melão, que é grande, 
mas não é verde.
Esse mesmo conceito – aplicado ao modelo relacional – nos permite 
realizar, em nosso banco de dados, uma operação sobre a tabela de 
HISTORICOS DE CONTRATO, subtraindo dele, por exemplo, todos os 
contratos que estejam na tabela CONTRATO VIGENTE. Isso resultaria 
em uma lista de contratos históricos, na qual o cliente hoje não tenha 
pelo menos um (1) contrato vigente com a empresa. Nesse sentido, 
teríamos apenas contratos de clientes que abandonaram a empresa e 
não estão sendo atendidos.
A última operação que temos é o produto cartesiano. Essa opera-
ção, como diz o nome, combina todos os N elementos de um conjunto 1 
com todos os M elementos de um conjunto 2, produzindo um novo 
conjunto com M × N elementos. Em outras palavras, multiplicam-se os 
elementos de um conjunto por aqueles de outro conjunto.
Considere um exemplo no qual nosso objetivo fosse, por meio do 
acesso à nossa base de dados de CLIENTES e PRODUTOS, enviar um 
e-mail diferente para cada cliente – cada correspondência eletrônica se-
ria uma campanha específica para cada produto da empresa. Se tiver-
mos mil clientes e cinco produtos, teremos que enviar 5 mil e-mails. Isso 
é um exemplo de um produto cartesiano.
Essa operação equivale a pegar cada um dos elementos do conjun-
to A e combiná-los com todos os elementos do conjunto B. O conjun-
to gerado (normalmente temporário) agregará os dados de ambos os 
86 Banco de Dados I
conjuntos. Em outras palavras, em cada e-mail, teríamos todos os da-
dos do cliente e todos os dados do produto oferecido. Olhando para 
o resultado, poderiaparecer que temos uma enorme redundância de 
informações, pois os dados de um cliente apareceriam repetidos cinco 
vezes (considerando cinco produtos a divulgar). Já os dados de um cer-
to produto estariam em mil e-mails diferentes.
Frequentemente, o produto cartesiano entre conjuntos é usado 
para gerar conjuntos temporários de dados que serão consumidos em 
algum processo. Isso não exclui a possibilidade de geração de tabelas 
perenes com produtos cartesianos em situações particulares.
Resta-nos, agora, um último tema, a integridade, que consiste na 
garantia de que os conjuntos e tabelas tenham coerência neles e entre 
eles. Quando falamos sobre integridade dentro de um conjunto, esta-
mos preocupados em garantir que somente elementos com caracterís-
ticas semelhantes estejam agrupados em um mesmo conjunto.
Podemos perceber esse conceito na teoria do conjunto, quando ob-
servamos o conjunto das FRUTAS, por exemplo. Se enumerarmos os 
elementos e tivermos, nesse conjunto, itens como melancia, melão e 
cachorro, teremos uma de duas situações: ou cachorro não é um ele-
mento correto nesse conjunto (pois ele é um animal), ou existe uma 
fruta que se chama cachorro. Se tivermos a primeira situação, o con-
junto de FRUTAS não tem integridade, pois nele não podemos ter um 
animal. Esse fato viola as regras de integridade.
O conceito de integridade é implementado no modelo relacional por 
meio de dois elementos: a integridade de identidade e a integridade 
de domínio. Esses dois elementos procuram assegurar que, em uma 
tabela criada para armazenar FRUTAS, não possamos, por exemplo, ar-
mazenar dados de um animal. A integridade de identidade requer que 
duas regras sejam observadas: não podemos ter linhas armazenadas 
em uma tabela sem que a chave primária esteja preenchida e não po-
demos ter linhas armazenadas com chaves primárias duplicadas.
O que aconteceria se, na tabela FRUTAS – na qual a chave primária 
seria “nome da fruta” –, desejássemos armazenar dados de um cachor-
ro? Não teríamos um nome de fruta para preencher, pois um cachorro 
não tem seu nome de fruta, certo? Com essa regra, seríamos impedi-
dos de cadastrar um cachorro nessa tabela, cumprindo, assim, a restri-
ção de integridade de identidade.
Perene: que permanece 
durante longo tempo.
Glossário
Modelo relacional e normalização 87
A regra diz, também, que não podemos cadastrar chaves primárias 
duplicadas. Isso atende a outro requisito da teoria dos conjuntos que 
diz, por exemplo, que, no conjunto das FRUTAS, não podemos ter os 
elementos melancia, melão, jaca e, novamente, melancia. Não faz sen-
tido criar uma lista de nomes de frutas e cadastrar duas vezes o mesmo 
elemento. Então, em uma tabela do modelo relacional, também não 
é permitido que um mesmo elemento (com o mesmo valor de chave 
primária) seja cadastrado duas vezes.
Imagine um sistema de informações com dados de FUNCIONÁRIOS 
contendo uma tabela na qual o mesmo funcionário apareça cadastra-
do duas vezes: isso não faria sentido, pois não atende à regra de in-
tegridade de identidade. Um funcionário só pode ser identificado na 
tabela uma única vez, fato que traz coerência ao modelo e garante que, 
ao longo do tempo, alguém não consiga cadastrar o mesmo funcioná-
rio duas vezes na mesma tabela.
A integridade de domínio também é uma garantia de que os da-
dos armazenados não percam sua coerência com o passar do tempo 
e, consequentemente, sua utilidade. Se tivermos que informar a colu-
na “Data de nascimento” para armazenar um FUNCIONARIO em uma 
tabela, seria errado imaginar que alguém tivesse liberdade de, nesse 
campo, cadastrar a informação sobre o nome da cidade onde nasceu. 
O que esperamos encontrar futuramente nesse campo são datas; se 
encontrarmos algo como “Curitiba”, teremos encontrado uma falha de 
integridade, pois Curitiba não é uma data. Também não seria coerente 
encontrar uma informação como 30/02/2020. Apesar de parecer uma 
data, podemos perceber que o dia 30 de fevereiro não tem integridade 
para a informação “data de nascimento”.
Na teoria dos conjuntos, esse conceito equivaleria a um conjunto 
de FRUTAS, no qual uma de suas características seria “Local onde foi 
produzida”. Se perguntássemos “onde essa fruta foi produzida?” e al-
guém respondesse “é doce”, perceberíamos que não há coerência na 
informação recebida. “É doce” não é uma informação válida para “Local 
onde foi produzida”, o que caracterizaria uma falta de integridade de 
domínio da informação. Talvez essa falha não seja muito frequente no 
mundo da teoria dos conjuntos, mas, no mundo do modelo relacional, 
poderíamos facilmente ter situações de perda de integridade caso o 
SGBD não garantisse que, em um campo previsto para armazenar da-
tas, tivéssemos somente datas válidas.
88 Banco de Dados I
Até aqui, vimos duas situações de garantia de integridade dentro de 
um conjunto ou tabela. Agora, veremos o caso específico da manuten-
ção da integridade referencial, no qual a integridade se estabelece 
entre diferentes conjuntos – portanto, entre diferentes tabelas. Esse 
conceito diz que uma chave estrangeira não pode conter um valor 
de uma chave primária que não exista. Se relembrarmos o conceito 
dessas duas chaves, veremos que uma chave estrangeira é uma coluna 
criada em uma tabela 2 para associar uma linha dessa tabela a uma 
linha de uma tabela 1. A coluna da tabela 2 terá uma chave primária 
equivalente com o mesmo conteúdo na tabela 1.
No exemplo a seguir, podemos ver que, ao tentarmos associar o 
funcionário Carlos a uma cidade na qual a chave estrangeira é igual a 
5, encontraremos uma situação de falta de integridade, pois a cidade 5 
não existe. O SGBD interromperá o armazenamento dos dados do fun-
cionário Carlos, impedindo que criemos uma informação incoerente no 
banco de dados.
TABELA 1 – CIDADE
Chave Nome Pop.
01 CWB 3 m.
02 RJ 5 m.
03 SP 10 m.
TABELA 2 – FUNCIONARIO
Chave Nome Sexo Chave Estrangeira
15 Jose M 01 (com integridade)
23 Joao M 02 (com integridade)
37 Maria F 02 (com integridade)
43 Carlos M 05 (sem integridade)
Figura 3
Implementação da integridade referencial no modelo relacional
Fonte: Elaborada pelo autor.
Dada a complexidade de relacionamentos entre tabelas que o mo-
delo relacional nos permite gerenciar, podemos dizer que garantia de 
integridade referencial talvez seja um dos pontos mais importantes 
a serem garantidos pelo SGBD. Em pouco tempo, sem essa garantia, 
 nosso banco de dados poderia passar a conter dados incoerentes e 
perder sua confiabilidade e utilidade.
Modelo relacional e normalização 89
4.2 Vantagens e desvantagens de se 
usar um modelo relacional 
Vídeo Após definir o modelo relacional, Codd estabeleceu um total de 12 
regras para avaliar o grau de aderência de cada sistema gerenciador 
de banco relacional fornecido no mercado de software. O objetivo des-
sas regras é orientar os fabricantes quanto aos recursos importantes 
de serem observados, de modo que o SGBD criado pudesse oferecer 
os benefícios esperados. Nessa época, muitos fabricantes já tinham 
produtos orientados ao modelo relacional. Com isso, muita discussão 
surgiu em torno do tema, pois nem todos os SGBDs existentes proviam 
todas as facilidades requeridas.
Essas regras foram e são, até hoje, usadas para verificar a fidelidade 
de um banco de dados ao modelo relacional. Elas servem para avaliar 
qual SGBD está mais ou menos próximo de fornecer os benefícios es-
perados. Se você está buscando um SGBD relacional, poderá usá-las 
como mais um critério de seleção. Descreveremos cada regra a seguir.
1. Toda informação em um banco de dados relacional é apresentada 
de maneira lógica na forma de tabelas.
Essa regra estabelece que toda a estrutura de funcionamento do 
SGBD relacional deve utilizar o conceito de tabela – linhas, colunas, 
chaves primárias, chaves estrangeiras, integridades etc. Nesse sentido, 
não estarão em tabelas apenas os dados armazenados por um sistema 
de informação, mas também a própria definição das tabelas, os dadossobre quem pode ou não acessá-las, as regras de segurança, os índices 
e tudo mais de que o SGBD precisa para funcionar.
2. Todo dado em um BD relacional tem a garantia de ser logicamente 
acessível, recorrendo-se a uma combinação do nome da tabela, 
um valor de chave e o nome da coluna.
Ter um método de acesso único que permita acessar qualquer dado 
armazenado em um BD facilita a futura construção de aplicações e 
garante que todo e qualquer dado existente, independentemente de 
quem o criou, poderá estar à disposição sem que seja necessário al-
gum algoritmo ou chave de acesso especial.
90 Banco de Dados I
3. Tratamento sistemático de valores nulos (ausência de informação).
Nos casos em que uma informação esteja ausente em uma coluna, 
precisamos ter um método único – e provido pelo próprio SGBD – para 
reconhecê-la e até mesmo para validar se ela é ou não permitida. Uma 
chave primária, por exemplo, nunca poderá ter um valor nulo, mas um 
campo como “Data de óbito” só será preenchido quando o funcioná-
rio falecer. Desde o seu cadastramento até esse dia, o campo ficará 
com valor nulo, o que será uma condição esperada, pois trata-se de um 
dado desconhecido.
4. O catálogo dinâmico on-line é baseado no modelo relacional.
Reforçando o que já foi dito na regra 1, a regra 4 define que qual-
quer documentação gerada sobre o BD, como seu dicionário de dados 
– local em que poderemos documentar cada tabela e cada coluna do 
BD –, também deverá ser armazenada como uma tabela, tendo linhas 
e colunas que possam ser acessadas como uma tabela convencional.
5. Há uma linguagem não procedural para a definição, a manipulação 
e o controle dos dados.
O SGBD deve prover uma linguagem de alto nível para definição dos 
dados no BD (criação de tabelas, colunas e índices, alteração de tabe-
las, entre outros), manipulação (leitura, atualização, exclusão de dados 
nas tabelas), bem como para definição de permissões ou remoção dos 
direitos de acesso. Isso evitará que seja necessário construir progra-
mas complexos ou conhecer várias linguagens diferentes.
6. Tratamento das atualizações de visões dos dados.
Visões de dados são elementos criados no BD que consistem em “recor-
tes” de parte de uma ou mais tabelas – esses recortes são representados 
em uma nova tabela, que é a visão. Ao acessar essa visão, será encontrada 
uma “tabela fictícia”, que mostra somente as colunas desejadas. A regra 6 
diz que a visão deve permitir que seus dados sejam atualizados, isto é, ao 
atualizar um dado em uma visão, ele será indiretamente atualizado nas 
tabelas que deram origem a ela (tabela 1 e tabela 2).
Modelo relacional e normalização 91
7. Tratamento de alto nível para inserção, atualização e eliminação 
de dados.
O SGBD deverá prover meios para que operações que afetam não 
somente uma linha de uma tabela (ou de várias tabelas) possam ser 
executadas por meio de um comando único e padronizado. Incluir, al-
terar ou excluir registros no banco de dados é uma ação que pode afe-
tar um ou vários registros simultaneamente por meio de uma mesma 
linguagem de programação.
8. Independência física dos dados.
Os programas criados por meio de uma linguagem de alto nível de 
manipulação de dados devem estar isolados de mudanças físicas que 
acontecem no armazenamento dos dados. Se uma tabela é segmen-
tada em mais de um espaço físico no disco onde é armazenada, se os 
dados passam a ser gravados em modo compactado ou ocorra qual-
quer mudança física no BD, não será percebida pelos programas que 
acessam esses dados.
9. Independência lógica dos dados.
Se, por exemplo, um programa recupera três colunas – a1, b1 e c1 
– em uma tabela-1, e, de repente, essa mesma tabela passa a ter uma 
quarta coluna (d1) e o tamanho da coluna b1 é mudado de 50 caracte-
res para 100 caracteres, não haverá qualquer necessidade de ajustar o 
programa ou recompilá-lo para que ele continue funcionando. O pro-
grama vai se adaptar automaticamente às mudanças, o que é um gran-
de benefício para a equipe de desenvolvimento, pois suas aplicações 
se tornam estáveis.
10. Restrição de Integridade (identidade, referencial e domínio).
O SGBD deverá ser capaz de gerenciar automaticamente os aspec-
tos relativos ao controle de integridade, não permitindo, por exemplo, 
que uma chave primária seja nula ou tenha valor duplicado. Não deve-
rá permitir, também, que uma chave estrangeira referencie um valor 
inexistente de uma chave primária, e assim por diante.
92 Banco de Dados I
11. Independência de distribuição dos dados.
Qualquer mudança nos critérios de distribuição dos dados – desde 
um BD não ser originalmente distribuído e passar a ter distribuição, ter 
uma distribuição entre dois diferentes nós de uma rede e passar a ter 
três diferentes nós, por exemplo – será transparente para o programa 
que acessa esses dados.
12. Não subversão das regras de integridade ou restrições quando se 
usa uma linguagem hospedeira.
Mesmo que exista um meio de uma linguagem de mais baixo nível 
– e não apenas a de alto nível provida pelo SGBD – manipular os dados 
do BD, não deverá ser possível deixar de manter ativos todos os contro-
les e as regras de integridade asseguradas pelo SGBD.
Após as 12 regras terem sido estabelecidas, surgiu uma décima ter-
ceira regra, que passou a ser chamada de regra zero. Essa regra fun-
damental diz:
0. Um SGBD relacional deve gerenciar seus dados usando apenas 
suas capacidades relacionais.
Antes de avaliar se um SGBD relacional cumpre os requisitos das 12 
regras, temos que avaliar se ele realmente as implementa utilizando 
suas propriedades de relacionamento entre tabelas. Todo o gerencia-
mento dos dados de um SGBD deve ser realizado exclusivamente por 
meio de conceitos do modelo relacional.
4.3 Criação e manutenção de 
um modelo relacional 
Vídeo Segundo Navathe e Elmasri (2005), a criação de um banco de dados 
relacional – que, como sabemos, será implementado por meio de tabe-
las, com linhas e colunas, chaves e índices – é, na verdade, uma etapa 
que está vinculada à derivação do modelo entidade-relacionamento 
 ( E-R) para um modelo relacional.
As regras de derivação do modelo E-R para um modelo relacio-
nal podem ser aplicadas em dois momentos. O primeiro consiste no 
Modelo relacional e normalização 93
instante em que o modelo está sendo concebido, pois algumas ferra-
mentas de construção já o fazem orientado para o modelo relacional e, 
portanto, já incorporam as chaves primárias, chaves estrangeiras etc. 
O segundo momento ocorre quando o modelo E-R já está pronto e se 
deseja iniciar a criação das tabelas no SGBD. Dessa maneira, as regras 
genéricas de derivação do modelo E-R podem agregar novos conceitos 
do modelo relacional (chaves primárias, chaves estrangeiras etc.), com-
plementando o processo de derivação.
A primeira regra – que trata da conversão de entidades e menciona 
que todos os atributos dessa entidade serão transformados em colu-
nas nas tabelas – requer atenção especial quanto à escolha da chave 
primária e das chaves secundárias, que agora são essenciais. É impor-
tante, ainda, que os atributos convertidos em colunas tenham seus ti-
pos de dados definidos de modo a minimizar o consumo de espaço em 
disco e, ao mesmo tempo, promovam consultas eficientes e garantam 
que suas propriedades inerentes não sejam comprometidas.
Uma situação especial que pode surgir em alguns modelos e que 
pode ser resolvida nesta etapa de derivação é o fato de que alguns re-
lacionamentos podem ter atributos. Imagine um relacionamento entre 
uma entidade PESSOA e uma entidade AUTOMOVEL. Esse relacionamen-
to indica quais pessoas são proprietárias de quais carros. Em vez de criar 
uma nova entidade COMPRA (um fato) no modelo proposto, a pessoa 
que elaborou o modelo escolheu armazenar no próprio relacionamento 
os atributos “data da aquisição” e “valor da aquisição”. Isso significa que, 
ao relacionarmos a PESSOA com o AUTOMOVEL, indicamos no relaciona-
mento em que data e por qual valor a aquisiçãose deu.
Com base nessas informações, observe a figura a seguir.
Figura 4
Modelo E-R com um relacionamento 1:N tendo atributos
PESSOA AUTOMOVEL
1 N
E dona de
CPF Data aquisicao 
Nome pessoa Valor aquisicao 
Data nascimento 
Placa do Carro
Cor
Marca
Fonte: Elaborada pelo autor.
No caso da Figura 4, além de aplicar a regra já conhecida de que a 
chave primária da tabela PESSOA seja transferida como chave estran-
94 Banco de Dados I
geira para a tabela AUTOMOVEL, devemos aplicar uma nova regra, de 
acordo com a qual os atributos do relacionamento devem ser transfe-
ridos para a entidade AUTOMOVEL. Em outras palavras, os atributos 
de um relacionamento 1:N são sempre transferidos para a entidade 
em que o grau N está vinculado. Ficaremos, então, somente com duas 
tabelas e com as seguintes colunas: PESSOA (CPF, nome e data nasci-
mento) e AUTOMOVEL (placa, cor, marca, data de aquisição, valor de 
aquisição e CPF_pessoa)
Adicionalmente, podemos enumerar mais duas regras que se apli-
cam ao processo de derivação dos atributos de relacionamentos de 
grau 1:1 e de grau M:N. A primeira regra diz que, em um relacionamen-
to de grau 1:1 com atributos, estes podem ser transferidos para qual-
quer uma das tabelas que participam do relacionamento, não havendo 
preferência ou exigência de que vá para uma ou para outra.
A próxima regra – que diz respeito à derivação dos atributos de re-
lacionamentos de grau M:N – estabelece que os atributos do relaciona-
mento deverão ser mantidos no próprio relacionamento, que, nesse 
caso, irá se transformar em uma nova tabela (tabela associativa).
Na figura a seguir, temos um exemplo no qual um ALUNO pode fa-
zer matrícula em vários CURSOS, e um CURSO poderá ter vários ALU-
NOS matriculados. Isso gera um relacionamento de grau M:N com os 
seguintes atributos: data da matrícula e valor da matrícula.
Figura 5
Modelo E-R com um relacionamento M:N tendo atributos
ALUNO CURSO
M N
faz matricula
CPF Data da matricula 
Nome pessoa Valor da matricula 
Data nascimento 
Codigo do curso
Nome do curso
Carga horaria
Fonte: Elaborada pelo autor.
Ficamos, após a derivação com três tabelas em nosso modelo re-
lacional, com as seguintes colunas: ALUNO (CPF, nome e data nasci-
mento), CURSO (código do curso, nome do curso e carga horária) e 
ALUNO_CURSO (CPF, código do curso, data da matrícula e valor da ma-
trícula). As colunas CPF e CODIGO DO CURSO são chaves estrangeiras 
Modelo relacional e normalização 95
que referenciam valores, respectivamente, de ALUNO e de CURSO, mas 
também formam a chave primária da tabela associativa, o que implica 
não ser possível ter um relacionamento duplicado entre aluno e curso 
(chaves primárias não permitem duplicação).
Além das regras de conversão do modelo E-R em um modelo re-
lacional, temos um outro método disponível para nos auxiliar a obter 
tabelas relacionais com estruturas íntegras. Esse método se chama 
normalização de tabelas e visa reduzir a redundância e aumentar a 
integridade das tabelas que serão criadas. Esse método era tradicio-
nalmente aplicado a estruturas de arquivos ditos desnormalizados, ou 
seja, que não tinham uma estrutura de modelagem adequada. É muito 
provável que, se você tiver criado um modelo E-R com o cuidado de 
observar os reais objetos do “mundo real”, já tenha obtido um modelo 
normalizado e não precisará realizar nenhuma etapa complementar.
O artigo Normalização de banco de dados, de Diego Machado, publicado na 
plataforma Medium, apresenta as quatros principais formas normais, suas 
regras e exemplos de derivação de estruturas de diferentes tabelas, servindo 
de complemento aos conceitos já apresentados.
Acesso em: 23 abr. 2020. 
https://medium.com/@diegobmachado/
normaliza%C3%A7%C3%A3o-em-banco-de-dados-5647cdf84a12
Artigo
Vejamos, a seguir, quais regras estabelecem as três formas normais. 
Essas regras devem ser aplicadas, sucessivamente, sobre uma estrutu-
ra de dados que esteja sendo normalizada. Assim, teremos três pro-
cessos sequenciais sendo feitos um após o outro. Ao aplicar a primeira 
regra, diremos que nossa tabela está na primeira forma normal; ao 
aplicar a segunda regra, teremos a segunda forma normal; e, ao aplicar 
a terceira regra, obteremos uma tabela na terceira forma normal.
A primeira forma normal (1FN) estabelece que, em uma tabela, 
todos os atributos devem ser atômicos, ou seja, não podem ser itens 
de repetição nem agrupamentos de outros atributos. Se, por exemplo, 
tivermos uma tabela PESSOA com um atributo “numero do telefone”, 
que pode possuir até três números distintos, ele deverá ser transfe-
rido para outra tabela chamada CONTATO, que terá três linhas e um 
único atributo “numero do telefone”. O grau de relacionamento entre 
 PESSOA e CONTATO será de 1:N. Esse requisito é compatível com a 
96 Banco de Dados I
estrutura tabular proposta por Codd (1970), segundo a qual todos os 
dados de um BD relacional devem ser armazenados exclusivamente 
por meio de linhas e colunas.
A segunda forma normal (2FN) diz que a tabela deverá estar pri-
meiramente na 1FN, logo todos os atributos não pertencentes à cha-
ve primária deverão depender totalmente da chave primária. Aqueles 
que dependem parcialmente da chave primária deverão dar origem 
a outra tabela, na qual o atributo da chave que gerou a dependência 
parcial será a chave primária da nova tabela. Já o atributo que tem a 
dependência parcial será um atributo dessa tabela. Por exemplo, ima-
gine uma tabela COMPRA, na qual a chave primária é composta de dois 
atributos, “placa do carro + CPF”, indicando qual pessoa comprou qual 
carro.
Se tivermos, nessa tabela, os atributos “valor de compra” e “cor do 
carro”, veremos que, para saber o valor de compra de uma transação, 
precisamos da chave completa (placa do carro + CPF) – o mesmo não 
se aplica a “cor do carro”, que somente com “placa do carro” pode ser 
determinado. Isso indica que uma nova tabela com a chave primária 
“placa do carro” deve ser criada, e que o atributo “cor do carro” deve ser 
movido para lá. Dessa forma, teremos criado a tabela CARRO por meio 
do processo de normalização, caso ainda não a tivéssemos mapeado 
pelo método de modelagem E-R.
Finalmente, a terceira forma normal (3FN) diz que a tabela deverá 
estar na 2FN e que, entre os atributos não pertencentes à chave primá-
ria, não deverá existir uma dependência transitiva de valores, isto é, uma 
coluna (não chave) não poderá dar origem a outra coluna na mesma ta-
bela. Caso isso aconteça, a coluna que gerou a transitividade deverá dar 
origem a uma nova tabela, sendo ela a chave primária dessa tabela, e a 
coluna dependente dessa chave também deverá ser migrada para essa 
nova tabela. Um exemplo disso seria se tivéssemos, na tabela CARRO, 
os seguintes atributos: “placa do carro”, “cor do carro”, “código do fabri-
cante” e “nome do fabricante”, sendo o atributo “placa do carro” a chave 
primária.
Podemos perceber que a coluna “cor do carro” é dependente ape-
nas da chave primária, e não do “código do fabricante” ou do “nome do 
fabricante”, portanto não há transitividade. Porém, a coluna “nome do 
fabricante”, além de depender da chave primária “placa do carro”, de-
Modelo relacional e normalização 97
pende da coluna “código do fabricante”. Assim, temos a seguinte transi-
tividade: “nome do fabricante” depende de “código do fabricante” que, 
por sua vez, depende de “placa do carro”. Nesse caso, criamos uma 
nova tabela com a chave “código do fabricante” e com a coluna “nome 
do fabricante”. Com isso, damos origem à tabela FABRICANTE pelo pro-
cesso de normalização. Na tabela CARRO, mantemos somente a coluna 
“código do fabricante” como chave estrangeira.
4.4 Tipos de modelos relacionais 
Vídeo Após Codd (1970) ter publicado as regras para avaliar os sistemas 
gerenciadores de BDs, Chris Date (1941-) – também pesquisador dos la-
boratórios da IBM e companheiro de Codd – sugeriu uma classificação 
para os SGBDs relacionais de acordo com o nível de aderência que elessão capazes de implementar.
Como o conjunto com 12 regras era muito complexo para comparar 
sistemas gerenciadores de banco de dados, Date (2004) imaginou seg-
mentá-las em quatro grandes grupos de características, a saber:
 • possuir estrutura tabular;
 • implementar operadores relacionais;
 • implementar requisitos de integridades;
 • implementar demais itens.
Para que pudesse ser considerado minimamente relacional, o SGBD 
deveria atender, pelo menos, ao primeiro quesito (estrutura tabular): 
se não tiver tabelas, o SGBD não pode ser relacional.
O nível mais básico, menos aderente às 12 regras de Codd, é clas-
sificado como SGBD tabular. Como o próprio nome diz, esse tipo de 
SGBD é capaz de suportar uma estrutura física na qual todos os dados 
são armazenados em tabelas (com linhas e colunas). Entretanto, o SGDB 
tabular não tem a capacidade de gerenciar esses dados, e o acesso a eles 
ocorre por meio de operadores relacionais (união, intersecção, diferença 
etc.). Para Date (2004), esse tipo de SGBD atende à regra 1 de Codd.
O segundo nível, mais completo, também suporta uma estrutura 
tabular e já é capaz de implementar operadores relacionais, mas não 
todos. Desse modo, esse tipo de SGDB ganhou o nome de minima-
98 Banco de Dados I
mente relacional. Como esse SGDB não tinha todos os operadores 
necessários, continuava a impor restrições.
No terceiro nível de classificação, encontramos os chamados SGBDs 
relacionais. Eles recebem essa nomenclatura porque, além de imple-
mentar uma estrutura tabular, são capazes de executar todos os ope-
radores da álgebra relacional propostos por Codd. Entretanto, esse tipo 
de SGDB não atende a algumas das 12 regras, como as relacionadas à 
garantia de integridade. Trata-se, portanto, de SGBDs que permitem 
o uso da arquitetura relacional, mas que ainda exigem alguns cuida-
dos extras. Esses cuidados eram tomados para que, com o passar do 
tempo, a perda de integridade dos dados não comprometesse o con-
teúdo armazenado nas tabelas. Para pequenos bancos de dados, com 
poucos usuários e com poucas mudanças de estrutura – entradas de 
novas tabelas, mudanças de colunas etc. –, podem oferecer recursos 
suficientes.
O quarto e último grupo de SGBDs é classificado como completa-
mente relacional (fully-relational). Esse modelo é capaz de prover 
praticamente todos os recursos sugeridos por Codd, incluindo uma 
estrutura totalmente tabular, todos os operadores da álgebra relacio-
nal, gerenciamento de integridade de domínio, integridade referencial, 
entre outros.
Desde sua criação, essas classificações têm sido amplamente utili-
zadas no mercado para que possamos identificar o potencial de recur-
sos relacionais oferecidos pelos SGBDs existentes.
CONSIDERAÇÕES FINAIS
Neste capítulo, vimos que o modelo relacional – hoje amplamente utili-
zado na implementação de sistemas de informação – evoluiu naturalmen-
te da estrutura de dados sugerida para a construção de BDs. Isso ocorre 
em virtude de esse modelo ter uma simplicidade e uma comprovação 
matemática de seus conceitos e operações. Ao aliar simplicidade e for-
malismo, o modelo relacional se tornou irrefutável e confiável, o que nos 
leva a acreditar que será, por muito tempo, predominante no mercado de 
sistemas de informação.
Modelo relacional e normalização 99
ATIVIDADES 
1. Explique quais benefícios são obtidos ao se aplicar a teoria dos 
conjuntos à teoria relacional.
2. Por que as 12 regras de Codd podem ser vistas como um referencial 
para a identificação dos benefícios do modelo relacional?
3. Justifique por que o processo de normalização pode, eventualmente, 
ser dispensado na criação de alguns modelos relacionais.
4. Por que um SGBD precisa ter pelo menos uma estrutura tabular para 
ser considerado relacional?
REFERÊNCIAS
CODD, E. F. A relational model of data for large shared data banks. Communications of the 
ACM, Nova Iorque, NY, v. 13, n. 6, jun.1970.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: Elsevier, 2004.
NAVATHE, S. B.; ELMASRI, R. Sistemas de bancos de dados. São Paulo: Pearson Education, 2005.
100 Banco de Dados I
5
Projeto de banco de dados
A criação de um banco de dados passa por diversas etapas, 
incluindo o levantamento de dados, a modelagem das entidades e 
relacionamentos, a derivação do modelo relacional, a normalização 
e, finalmente, a definição do modelo físico.
Muitos autores usam os termos projeto conceitual, projeto lógico 
e projeto físico para determinar cada uma destas fases, portanto, 
cada uma delas seria parte do projeto do banco de dados. Outras 
vezes temos a nomenclatura projeto do banco de dados associada 
somente à etapa do projeto físico, sendo as duas etapas anteriores 
definidas como modelagem conceitual e modelagem lógica. Não há 
conflito entre essas duas maneiras de referenciar as etapas, pois 
podemos entender que a modelagem conceitual é uma atividade 
da etapa de projeto conceitual, logo, elas se confundem.
Neste capítulo, nossa abordagem – quando nos referenciarmos 
ao projeto de banco de dados – será associada ao projeto físico 
do banco de dados. Vamos tratar dos temas ligados ao projeto de 
banco de dados sempre focando nos aspectos físicos que ele en-
volve, nos seus requisitos, em como esta atividade é executada, 
nos benefícios que ela pode trazer e nas considerações que devem 
ser observadas para que se obtenham os resultados esperados. 
Esperamos que você nos acompanhe nesta jornada.
5.1 O que é e para que serve o 
projeto de banco de dados? 
Vídeo Segundo Navathe e Elmasri (2005), o projeto físico do banco de da-
dos é uma atividade na qual o objetivo não é apenas obter uma estru-
tura de dados apropriada para o armazenamento, mas desenvolvê-lo 
de modo que garanta um bom desempenho. Essa visão inicial já nos 
apresenta os dois principais elementos do projeto físico: definir a es-
Projeto de banco de dados 101
trutura física para armazenamento dos dados e assegurar o correto 
desempenho do BD.
Até atingir este ponto no processo de construção do banco de da-
dos, foi necessária uma evolução gradual da complexidade de cada ta-
refa. Primeiramente, foi preciso a construção de um modelo E-R, na 
qual a maior preocupação foi obter uma visão coerente do mundo real 
e mapeá-la. Em seguida, foi necessário agregar uma nova etapa de 
complexidade, que foi entender que o modelo precisaria ser orientado 
ao modelo relacional, logo, iria demandar de chaves primárias, chaves 
estrangeiras etc. Agora, neste último momento, o processo será finali-
zado agregando ainda mais alguns elementos de complexidade ligados 
ao armazenamento físico – consumo de espaço em disco, crescimento 
de espaço de armazenamento, retenção de históricos, compactação, 
rotinas de expurgo etc. –, além de um pequeno detalhe que faz toda a 
diferença: a garantia de desempenho adequado.
Nesse sentido, não só temos que escolher uma série de parâmetros 
e topologias possíveis para armazenar os dados de todas as entidades 
e relacionamentos que antes identificamos, como precisamos avaliar 
quem os usará, quantas vezes eles serão acessados por dia, por hora, 
por minuto ou até mesmo por quanto tempo eles deverão ser manti-
dos on-line para serem acessados.
Realizar o projeto físico passa a ter um novo elemento de complexi-
dade que, muitas vezes, é extremamente difícil de identificar: o padrão 
de uso destes dados. Como serão usados? Quando e por quem serão 
usados? Em que volume serão usados? No modelo conceitual, pode-
mos ter identificado, por exemplo, que teremos uma entidade FUN-
CIONARIO com alguns atributos como CPF, nome, data de nascimento 
e endereço. Já no modelo lógico definimos que a chave primária dessa 
tabela seria o CPF. Mas, agora, precisamos definir: onde estes dados 
serão armazenados (em quais discos? Em qual servidor? Em qual nó da 
rede?) e quantos megabytes, gigabytes ou terabytes ocuparão? E uma 
pergunta difícil de responder: quantas vezes por dia alguém irá pesqui-
sar todos os funcionáriosque moram em um determinado endereço?
Você deve estar se perguntando: “como é que iremos saber qual 
será a demanda de acesso futura de um banco de dados que ainda 
nem construímos?”. Além disso, talvez se questionando: “como execu-
tar um projeto físico se não temos ainda todos os detalhes para subsi-
diar as decisões que terão que ser tomadas?”.
102 Banco de Dados I
Aqui surge um primeiro ponto a ser discutido e que muitas vezes pa-
rece até controverso: a estrutura física de um banco de dados pode ser 
definida em um determinado momento do projeto e se manterá estável? 
Ou ela estará constantemente exigindo ajustes ao longo do tempo?
A criação de um banco de dados não é um processo puramente se-
quencial, com começo, meio e fim. Ele é um processo cíclico e que, de 
modo incremental, será executado agregando progressivamente no-
vas entidades, novos relacionamentos, e, portanto, fazendo o BD físico 
também crescer. Isso nos faz concluir que esta tarefa realmente não 
é pontual, ela é cíclica. A escolha dos parâmetros de criação física do 
BD será sempre dependente do perfil de uso corrente que teremos. A 
estrutura hoje adequada ao perfeito funcionamento da aplicações que 
se conectam com o banco de dados poderá, em alguns meses ou anos, 
não ser mais adequada.
Imagine que seu banco de dados é acessado somente por uma apli-
cação departamental, que usa os dados de funcionários para processar 
a folha de pagamento. Imagine também que, em alguns meses, um 
aplicativo para celular é liberado a todos os funcionários para que eles 
mesmos tenham acesso a seus dados pessoais e possam atualizá-los 
e consultá-los. O que mudaria no projeto físico? Teríamos que mudar 
os métodos de acesso aos dados e passar a controlar níveis de segu-
rança de acesso diferenciados? Além disso, teríamos que imaginar um 
aumento de quantidade de acessos por dia aos cadastros de funcioná-
rios? Com certeza.
Responder a todas essas perguntas nos leva a identificar qual é o 
papel do projeto físico dentro do ciclo de atividades executadas para 
criar um banco de dados. Basicamente, neste momento da criação 
do banco de dados, temos que definir os aspectos técnicos ligados ao 
SGBD. Se essa definição não for adequada, poderemos ter um modelo 
E-R que represente 100% da visão do mundo real, isto é, um modelo re-
lacional que atenda a todos os requisitos implementados em um SGBD 
“completamente relacional”, atendendo a todas as regras definidas por 
Codd (1970). Contudo, mesmo assim entregaremos para os programa-
dores e analistas de sistemas um banco de dados que não lhes oferece, 
de modo adequado, os resultados que seus usuários esperam. Pode-
remos ter consultas que são muito demoradas para serem executadas, 
relatórios que geram muito consumo de memória para serem proces-
sados ou informações históricas difíceis de serem compartilhadas.
Projeto de banco de dados 103
Deste modo, queremos concretizar a entrega de um banco de da-
dos que seja coerente do ponto de vista conceitual, que respeite os re-
quisitos do modelo relacional, mas que, acima de tudo, seja adequado 
para a construção de sistemas de informação e que tenha desempe-
nho adequado. Isso definitivamente é o que fará a diferença entre um 
BD que seja considerado útil para o desenvolvimento de aplicações ou 
que seja um simples repositório de dados. Afinal, um BD apropriado 
é aquele que consegue combinar a coerência e integridade lógica de 
seus dados com os mecanismos e facilidades de acesso, e, finalmente, 
com a performance esperada.
Em resumo, nesta etapa, vamos executar o projeto físico para de-
finir as tabelas e as visões que o banco de dados terá. Vamos definir 
as regras de restrição de integridade e os mecanismos de acesso por 
meio de índices, além de calcular e alocar espaços físicos para arma-
zenamento de dados e índices. Ademais, vamos projetar a distribui-
ção desses dados considerando aspectos como velocidade de acesso, 
largura de banda de conexão de rede e tipos de dados que trafegarão 
(vídeos, áudio, imagens, mapas etc.), garantindo que, ao final, o BD seja 
útil e apropriado ao acesso de todos os que têm demandas a serem 
atendidas.
Mapa de acesso lógico 
(MAL)
Nesse material, você po-
derá rever, em detalhes, 
o processo de criação do 
projeto físico, conhe-
cendo uma ferramenta 
chamada MAL (mapa 
de acesso lógico), a qual 
permite mapear as tran-
sações de negócio.
Disponível em: https://www.
devmedia.com.br/projeto-fisico-
-de-banco-de-muito-alem-do-
-create-table/3581. 
Acesso em: 6 maio 2020.
Site
5.2 Vantagens e desvantagens de se fazer 
um projeto de banco de dados
Vídeo Você já deve ter visto algum tutorial de criação de bancos de dados 
no qual rapidamente alguém define um conjunto de duas ou três tabe-
las e, para cada uma delas, cria também duas ou três colunas, sendo 
uma dessas a chave primária e as demais alguns campos textuais sim-
ples. Em poucos minutos, está criada também a estrutura do BD.
Se tudo é tão simples, por que estamos discutindo tantos detalhes 
de modelagem conceitual, modelagem lógica, escolha e definição de 
chaves primárias, bem como insistindo em questões sobre o projeto 
físico? Toda a diferença está, na verdade, na finalidade de uso do ban-
co de dados. Veremos, neste capítulo, que principalmente o volume 
de acessos e a complexidade de manuseio dos dados determinarão 
se nossas estruturas físicas do banco de dados precisarão ser mais ou 
menos elaboradas.
104 Banco de Dados I
Por esse motivo, construir um banco de dados pode realmente de-
mandar ou não cuidados especiais. Se tudo o que você deseja é uma es-
trutura temporária para um pequeno experimento, como, por exemplo, 
demonstrar para alguém um conceito ou fazer um teste de acesso a um 
pequeno conjunto de dados, então, realmente a ideia de prototipar seu 
banco de dados pode ser viável. Agora, se você precisa de uma estrutura 
perene que deverá dar atendimento a requisições reais, será necessário 
todo um processo formal para a criação do banco de dados.
Vamos, deste ponto em diante, abordar o processo de projeto de 
um BD considerando um ambiente de média ou alta complexidade. Um 
ambiente para o qual tenhamos requisitos de desempenho já estabe-
lecidos e no qual usuários tenham expectativas de atendimento com 
qualidade assegurada. Logo, uma estrutura de banco de dados bem 
planejada será essencial e terá que ser cuidadosamente elaborada.
Um primeiro benefício, obtido por um projeto de banco de dados 
adequado, é o fato de que seu desempenho, ou seja, sua performance, 
será adequado com pequenos, médios e grandes volumes de dados. 
Muitas vezes, um BD planejado para um baixo volume de dados pode 
entrar em colapso quando cresce gradualmente pela inserção ou im-
portação sucessiva de novos dados. O tempo de execução de um úni-
co comando para inserção ou recuperação de dados já inseridos pode 
crescer exponencialmente e não linearmente. Isso significa que, se o 
volume de dados dobra, o tempo de acesso pode não só dobrar, mas 
ficar bem mais lento.
Outro fator de degradação que pode surgir quando temos um pro-
jeto de banco de dados mal elaborado é o suporte em relação ao au-
mento do número de transações simultâneas que serão executadas 
com os dados desse BD. Isso significa que não apenas o crescimento 
da quantidade de registros existentes em um banco de dados pode 
passar a gerar aumento no tempo de execução de comandos de inser-
ção ou de recuperação de dados. Significa também que, mesmo que o 
BD preserve seu tamanho, ao aumentarmos a quantidade de acessos 
feitos sobre este mesmo volume de dados, teremos aumento no tem-
po de resposta a cada um dos comandos submetidos para execução 
pelo SGBD. Inserir ou recuperar um registro pode se tornar uma tarefa 
cada vez mais demorada, simplesmente porque mais comandos estão 
sendo executados na mesma unidade de tempo, por exemplo, em um 
segundo.
No vídeo Como otimizar 
um banco MySQL usando 
índices, publicado pelo 
canal Gustavo Gallas, 
você poderá ver, na prá-
tica,como a criação de 
um índice em uma tabela 
pode trazer uma grande 
redução dos recursos 
dispendidos pelo banco 
de dados para recuperar 
um dado.
Disponível em: https://
www.youtube.com/
watch?v=zOPzmjQSBYQ. Acesso 
em: 6 maio 2020.
Vídeo
Projeto de banco de dados 105
Agora imagine que esses dois fatores possam acontecer simulta-
neamente, o que é muito provável que venha a acontecer em boa parte 
das aplicações comerciais. Podemos ter, com o passar do tempo, mais 
dados inseridos no BD e também maior volume de acessos a esses 
dados. Neste cenário, podemos imaginar que o tempo de acesso ao 
banco de dados venha a sofrer uma dupla degradação caso um projeto 
não tenha sido feito adequadamente.
Entretanto, em muitos casos, ao se iniciar a criação de um banco de 
dados, ainda não teremos todos os elementos que nos permitam julgar 
de que modo estes dados serão acessados, por quantas pessoas serão 
acessados, qual será a taxa de crescimento dos dados armazenados ou 
mesmo quantos registros serão gerados diariamente ou mensalmente. 
O levantamento dessas informações deverá ser parte do projeto do 
BD e serão elementos investigados ou solicitados pelo administrador 
de banco de dados (ABD) ao analista de sistemas que esteja com o en-
cargo de construir o sistema de informações que dará origem ou que 
manipulará o BD.
Outro fator dificultador da criação de uma estrutura física adequa-
da para os bancos de dados é o fato de que, muitas vezes, o próprio 
cenário de uso se altera com o passar do tempo. Um BD é uma estrutu-
ra de dados que tem como objetivo a agregação e o compartilhamento 
dos dados que ele detém, entre diversas aplicações, de modo coerente 
e integrado. Isso significa que, eventualmente, o sistema que deu ori-
gem a um banco de dados em um curto espaço de tempo já não tem 
mais o domínio sobre esses dados. O volume de dados que se acredi-
tava existir muda, pois outros sistemas passam também a armazenar 
dados no mesmo BD. A quantidade de acessos previstos por um siste-
ma não é o mesmo que o previsto pelos sistemas que irão compartilhar 
este mesmo banco de dados. E, somando finalmente todas as deman-
das, o volume final de acessos pode ser muito maior que o estimado.
Mas, então, como resolver esta questão? A resposta está na figura 
do administrador do banco de dados. Ele deverá ser capaz de consoli-
dar todas as demandas dos diversos sistemas e planejar uma estrutura 
que atenda, de modo uniforme, a todos os sistemas com suas especifi-
cidades. Em outras palavras, o projeto físico deve levar em considera-
ção vários cenários de várias aplicações que já estejam usando ou que 
venham a usar o mesmo banco de dados. Isso naturalmente implica no 
fato de que, com o passar do tempo, o próprio projeto físico terá que ser 
106 Banco de Dados I
ajustado continuamente. Ele não é uma etapa que tenha começo, meio 
e fim. Trata-se de um processo cíclico que exige constante monitoração 
e ajuste, mas que, como resultado, produzirá sempre um desempenho 
adequado no momento em que estejamos realizando sua avaliação e 
seus ajustes.
Alguns dos ajustes que o administrador de banco de dados pode 
sugerir, visando melhorar a performance de um BD, podem impactar 
diretamente o modelo de dados relacional criado na etapa anterior ao 
projeto. Na etapa da derivação do modelo relacional, algumas tarefas, 
como escolha das chaves primárias e normalização das tabelas, eram 
requeridas para trazer integridade ou até para a redução do consumo 
de espaço físico. Em outras palavras, preparamos nosso modelo re-
lacional de acordo com as melhores práticas, mas, agora, no projeto 
físico, veremos este modelo relacional ser alterado pelo administrador 
de banco de dados para conseguir adequá-lo a uma ou outra demanda. 
Isto é um contrassenso? Não.
A modelagem relacional deve ser orientada pelas melhores práti-
cas, como a normalização das tabelas. Isto não significa, porém, que to-
das as iniciativas de normalização poderão ser mantidas no projeto do 
BD. Muitas vezes, quando desnormalizamos uma tabela, conseguimos 
obter um melhor desempenho de uma transação ou de uma consulta 
no banco de dados. E isso pode justificar a mudança realizada.
A normalização pode trazer maior estabilidade ao modelo de dados, 
garantir uma maior integridade dos dados armazenados e assegurar 
que uma transação tenha total garantia de que não vai produzir dados 
inconsistentes no BD. Por outro lado, a busca de um modelo ideal do 
ponto de vista de integridade nem sempre irá justificar o consumo de 
recursos de processamento ou a complexidade de acesso aos dados.
Imagine uma situação na qual a normalização, por exemplo, tenha 
nos levado a criar uma tabela TIPO PAGAMENTO. Nela, temos duas li-
nhas compostas de um código e um texto, conforme mostra a Figura 
1. Esses códigos seriam agregados a cada um dos 200 mil registros de 
vendas realizados todo dia. Agora, imagine que, para cada uma das 
100 mil consultas realizadas todo dia pelos gerentes das lojas, tenha-
mos que converter o código “1” no texto “à vista” ou o código “2” no 
texto “parcelado”. Não seria razoável pensar em remover este código 
“1” do registro de vendas substituindo-o pelo texto “à vista” já pronto 
Projeto de banco de dados 107
para ser exibido após a consulta dos dados do registro? Isto é uma 
desnormalização.
Vamos gastar mais espaço em disco para armazenar esta informa-
ção? Sim. Contudo, vamos ter um processo mais simples de consulta 
diária? Sim também; então talvez ele se justifique. Veja a estrutura pre-
sente na Figura 1.
Figura 1
Tabela normalizada e tabela desnormalizada
VENDA
Data Tipo Valor
01/01 1 10,00
02/01 1 15,00
03/01 2 12,00
VENDA
Data Tipo Valor
01/01 à vista 10,00
02/01 à vista 15,00
03/01 parcelado 12,00
 TIPO PAGAMENTO
Cód. Nome 
1 à vista
2 parcelado
Estrutura normalizada Estrutura desnormalizada
Fonte: Elaborada pelo autor.
São mudanças como essas que impactam o modelo relacional e que 
acabarão por serem sugeridas pelo administrador de banco de dados 
após conhecer o perfil de uso dos dados, mas que, acima de tudo, terá 
que ter um controle contínuo sobre o resultado que está produzindo. 
Não adiantaria, por exemplo, desnormalizarmos uma estrutura como 
aquela vista no exemplo acima, e, de outro lado, gerar algum tipo de 
prejuízo maior para outros usuários do mesmo banco de dados. Toda 
a escolha de uma estratégia de normalização ou desnormalização sem-
pre precisará ser feita com base na avaliação dos custos e dos benefí-
cios que ela trará ao maior conjunto de usuários do BD. Sabemos que 
eventualmente não conseguiremos ter todos os casos atendidos com 
100% de eficiência e eficácia, mas devemos buscar maximizar os re-
sultados para a maioria das situações ou, pelo menos, para aquelas 
consideradas prioritárias.
Talvez, a desvantagem de gastar mais espaço físico em disco para 
armazenamento de uma tabela desnormalizada possa ser relevada se a 
performance de acesso for melhor. Afinal, o custo do espaço em disco 
está cada vez mais barato se comparado a décadas anteriores, enquanto 
a exigência por menores tempos de processamento e de espera para 
obter uma informação são cada vez mais críticas nos projetos atuais.
108 Banco de Dados I
Muitos dos detalhes que o administrador de banco de dados utilizará 
para definir estratégias de armazenamento para um determinado BD es-
tão intimamente ligados a questões puramente técnicas e tecnológicas. 
O ABD deve ter a preocupação, por exemplo, de verificar qual é o tipo de 
dado mais apropriado para armazenar uma coluna que conterá nomes de 
funcionários em uma tabela sabendo que existem nomes de funcionários 
muito “curtos” (com poucos caracteres), como “João da Silva”, enquanto 
outros nomes podem ser bastante “longos” (muitos caracteres), por exem-
plo, “Wellington Roberto de Magalhães Albuquerque e Souza”.
O que é melhor em uma situação destas? Prever um campo com 100 
caracteres que na maior parte das vezes será subutilizado? Preverum 
campo com 50 caracteres e exigir que os nomes sejam abreviados? Pre-
ver um campo de tamanho variável que se adapte ao tamanho de cada 
nome, sendo somente o espaço real de cada nome, mas pagando um 
preço extra por ter que gerenciar tamanhos diferentes?
Perceba que temos várias opções para uma simples coluna que 
armazene um nome. Essa mesma preocupação pode acontecer para 
uma coluna que armazene um número, uma data, um texto longo ou 
até uma imagem. Cada situação pode ter impactos de consumo de es-
paço em disco e de recursos de processamento para o tratamento do 
conteúdo que está armazenado em uma determinada coluna.
Saber, por exemplo, quantos bytes são consumidos para cada coluna 
conforme o tipo de dado escolhido para mapeá-la, quais são as estrutu-
ras de headers (campos de controle do banco de dados) e de ponteiros 
(estruturas internas do banco de dados) que serão usadas ou até qual é 
o tempo consumido em milissegundos para que um bloco de dados seja 
lido em disco e transferido para a memória podem fazer com que uma ou 
outra estratégia de armazenamento de dados seja escolhida pelo ABD. 
Somado a essa complexidade, podemos ainda ter as particularidades de 
cada diferente sistema gerenciador de banco de dados (SGDB). Talvez o 
modo como um fabricante tenha implementado sua estrutura física in-
terna seja diferente do modo como outro fabricante a realize, mudando, 
desse modo, o resultado final da estrutura que iremos construir.
Todos estes aspectos, é bem verdade, são muito mais impactantes 
quanto maior for o volume de dados que iremos tratar em nosso BD. 
Talvez uma estrutura de uma coluna chamada “nome do funcionário”, 
escolhida de modo não ideal, possa gerar pouco impacto para um ban-
Projeto de banco de dados 109
co de dados de uma empresa com 50 ou 100 funcionários. Por outro 
lado, se estivermos criando uma base de dados para um sistema de 
gerenciamento de aposentadorias do INSS, no qual os nomes de mais 
de 100 milhões de funcionários terão que ser armazenados, mantidos 
e acessados ao longo de mais de 30 anos, podemos imaginar que um 
único byte economizado possa representar 100 megabytes trafegando, 
sendo salvos, copiados, acessados etc.
Além disso, os tempos de acesso a disco – que são todos infinitesimais 
se comparados aos tempos de uma consulta feita por um APP no celular, 
que pode levar de 3 a 5 segundos e ainda parecer rápida – podem come-
çar a ser impactantes no exemplo dado acima, no qual 100 milhões de 
registros terão que ser lidos para que se identifique quais funcionários 
se encontram em uma determinada situação. Se, na leitura de cada um 
destes 100 milhões de registros, economizarmos 0,0001 segundos, tere-
mos uma economia final de quase 3 horas de processamento.
Isso só confirma que um projeto de um banco de dados requer 
realmente o conhecimento de detalhes sobre o perfil de uso deste BD 
e principalmente sobre volumes e quantidades de dados e transações. 
Um excelente projeto para uma tabela com 100 funcionários poderá ser 
um péssimo projeto para uma tabela com 100 milhões de funcionários.
Até este ponto, nos concentramos em um dos elementos que im-
pacta diretamente o projeto de um banco de dados, ou seja, a questão 
de estrutura física dos dados nas tabelas, tanto em nível de normali-
zação e desnormalização quanto em nível de escolha dos tipos de da-
dos que serão usados para armazenar cada coluna. Outro elemento, 
porém, tem também uma importância tão grande como as estruturas 
físicas já mencionadas: os índices de acesso aos dados das tabelas.
Segundo Heuser (2009, p. 98),
para a implementação eficiente do controle da unicidade da 
chave primária, o SGBD usa normalmente uma estrutura de 
acesso auxiliar, um índice, para cada chave primária. Índices, 
pela forma que são implementados, tendem a ocupar espaço 
considerável em disco. Além disso, a inserção ou remoção de en-
tradas em um índice podem exigir diversos acessos a disco.
Nessa afirmação, podemos identificar três importantes pontos de 
atenção em nosso projeto físico: unicidade, consumo de espaço e custo 
de manuseio dos índices. O primeiro deles, a unicidade, significa que, 
110 Banco de Dados I
para cada chave primária teremos obrigatoriamente a criação de um 
índice. Em outras palavras, os índices estarão sempre presentes em 
nossos bancos de dados e teremos, portanto, que identificá-los, tra-
tá-los e otimizá-los. O índice tem, portanto, um papel essencial, que é 
garantir, em um primeiro momento, que duas linhas de uma mesma 
tabela não tenham conteúdos de chave primária duplicados.
O artigo Entendendo como os índices funcionam, publicado na plataforma 
DevMedia, apresenta como os dados são armazenados fisicamente em um 
banco de dados e como os índices permitem que eles sejam acessados mais 
rapidamente.
Acesso em: 6 mai. 2020. 
 https://www.devmedia.com.br/entendendo-e-usando-indices/6567
Artigo
Como poderíamos assegurar a unicidade em uma tabela com 100 
milhões de funcionários sem um índice? Ao armazenar o funcionário de 
número 100.000.001, cujo CPF é 123.456.789-00, como poderíamos ter 
certeza de que este CPF já não foi utilizado em qualquer um dos outros 
funcionários armazenados? Este é o papel do índice: ele facilmente identi-
ficará entre os 100 milhões de registros qual é o lugar onde este novo CPF 
se localizará (como se fosse uma lista ordenada) e verificará se esse lugar já 
está (ou não) ocupado por um registro de algum funcionário.
Na verdade, a estrutura de dados mais utilizada para criação dos 
índices não é uma simples lista ordenada como citamos acima. O que 
frequentemente vemos é uma combinação de árvores binárias com 
múltiplos níveis e no nível “folha”, ou seja, no último nível de gerencia-
mento dos dados da árvore, uma lista ordenada. Essa estrutura de cria-
ção de armazenamento de índices é, na verdade, um segredo muitas 
vezes mantido pelos fornecedores de cada SGBD, pois justamente se 
traduz em um modo de acesso mais rápido ou em um modo que con-
suma menor quantidade de espaço físico para o próprio índice, sendo 
assim um diferencial competitivo. Segundo Silberschatz (2012), para 
obter um acesso aleatório rápido aos registros em um arquivo, pode-
mos usar uma estrutura de índices. Esse passa a ser um outro papel 
importante dos índices.
Em algumas versões do próprio Ms-Sql-Server, da Microsoft, alguns 
dos pontos que já foram apontados como novidade ou como melhoria 
em relação à versão anterior foram os algoritmos de gerenciamento de ín-
Projeto de banco de dados 111
dices. Em alguns casos, esses puderam gerar tempos até cinco vezes me-
nores para recuperação de um registro no banco de dados pela simples 
mudança de estrutura interna ou de método de manuseio desses índices.
Aqui, chegamos ao segundo ponto que merece atenção em nosso 
projeto físico, que é o fato de as estruturas de índices consumirem 
espaço físico no próprio banco de dados. Se os índices precisam de 
árvores binárias e de listas ordenadas, é claro que essas estruturas de 
dados consumirão também espaço físico. Se os índices precisam ma-
pear de modo ágil todas as chaves primárias de uma tabela (para saber 
se elas são únicas), podemos também imaginar que um índice sobre 
uma tabela com 100 registros consuma menos espaço físico do que um 
índice sobre uma tabela com 100 milhões de registros. Um índice sobre 
100 milhões de registros cuja chave primária tenha 10 bytes consome 
menos espaço físico do que um índice sobre a mesma tabela com uma 
chave primária sobre uma coluna com 50 bytes, afinal, esses 50 bytes 
terão que ser representados na árvore binária e nas listas ordenadas.
Tudo isso nos leva, durante essa fase de projeto, a avaliar quais são 
as chaves primárias não só sobre o ponto de vista conceitual e relacio-
nal, mas também sobre o ponto de vista físico. Será que não devería-
mos mudar nossa chave primária de uma tabela que usa 50 bytes na 
coluna X para outra chave primária na coluna Y que só tenha 10 bytes? 
Isso reduziria nossos índices?Isso é relevante para o volume de dados 
que vamos manipular e que trará redução de espaço em disco? Além 
do mais, isso vai trazer redução de consumo de memória? Considere 
que, muitas vezes, os índices são carregados em memória para serem 
acessados mais agilmente pelos algoritmos de busca. São todas per-
guntas que o ABD deverá avaliar e responder.
Temos ainda um terceiro ponto a considerar: o custo de manu-
seio dos índices. Esse custo é, na verdade, traduzido em tempo. Uma 
estrutura de índice mais complexa e mais extensa (com vários níveis 
na árvore) pode consumir mais tempo para ser reestruturada a cada 
vez que um novo registro é inserido ou excluído da tabela que esse 
índice representa. Lembre-se de que o índice deve sempre estar em 
sincronismo com a tabela que ele representa. Todas as linhas inseri-
das ou excluídas de uma tabela requerem que o índice seja também 
atualizado sincronamente, o que pode gerar um consumo de tempo 
adicional sobre a própria operação de inserção dos dados na própria 
tabela. Quando falamos sobre o modelo relacional, o índice da chave 
112 Banco de Dados I
primária é obrigatório, portanto sempre teremos esse custo associado 
às nossas operações de inserção e exclusão.
Se temos um índice obrigatório sobre a chave primária de uma tabela e 
precisamos otimizar sua criação e manipulação, o que dizer então dos de-
mais índices não obrigatórios? Sim, existem outros índices que podemos 
criar em uma tabela e que não são obrigatórios. Contudo, eles podem nos 
ajudar a trazer maior consistência para nossos dados e também assegurar 
melhor performance no acesso aos dados. Como dissemos há pouco, um 
índice é um meio de assegurar que os valores de uma coluna sejam úni-
cos, ou seja, que não exista duplicação de valores nesta coluna.
Imagine um caso prático onde na tabela FUNCIONARIO temos uma 
chave primária que é o CPF do funcionário. Porém, devem existir outras 
colunas nesta tabela que também não devem permitir duplicação de 
valores, como “RG”, “Título de Eleitor”, “Carteira de Motorista”, “Matrí-
cula”, entre outros. Como assegurar que dois funcionários diferentes, 
mesmo tendo CPFs distintos na chave primária, não terão um número 
de título de eleitor duplicado? É simples: colocando um índice sobre a 
coluna que guarda essa informação. Podemos fazer assim em todas 
as demais colunas onde não queremos valores duplicados. O próprio 
SGBD irá assegurar que o valor é único e conseguirá fazer isso de modo 
rápido usando o índice criado.
No exemplo acima, também podemos imaginar que, para um deter-
minado sistema de informação a ser desenvolvido com esse banco de 
dados e com a tabela FUNCIONARIO, iremos requerer que um determi-
nado gerente possa acessar os dados de um dos seus subordinados, de 
modo rápido, por meio de sua matrícula e não por meio de seu CPF. Já vi-
mos aqui que o fato de existir um índice sobre uma coluna também nos 
assegura poder recuperar o registro que contém a informação desejada 
na tabela quase que imediatamente. É o que chamamos de acesso direto 
em comparação ao acesso sequencial, que iria requerer que procurás-
semos em todos os registros da tabela até encontrarmos o identificador 
desejado. Esse, com certeza, é mais um motivo para criarmos um índice 
sobre a coluna que contém os dados de matrícula.
Temos, nesse sentido, duas situações distintas e que podem ser 
combinadas entre si onde um índice será útil para nosso projeto: para 
evitar valores repetidos e para propiciar acesso direto aos dados. Po-
rém, não somente colunas que tenham valores únicos podem ter ín-
Projeto de banco de dados 113
dices, podemos ter também índices sobre colunas que têm valores 
repetidos. Com certeza, nesse caso, ele não tem o objetivo de proibir 
duplicação. Assim, temos índices únicos e índices não únicos.
Vamos dar um exemplo: imagine que, na mesma tabela FUNCIONARIO 
– onde já criamos vários índices únicos (que não permitem valores repeti-
dos na coluna) –, temos uma coluna que indica a “placa do carro” que um 
funcionário utiliza para se deslocar ao trabalho. Imagine que dois funcio-
nários, irmãos ou até vizinhos, se utilizem do mesmo carro para ir até a 
empresa. Isso com certeza não pode ser proibido, é uma situação espera-
da em nosso sistema. Teremos a mesma placa do mesmo carro repetida 
em mais de uma linha da mesma tabela. Entretanto, se precisarmos criar 
uma consulta que rapidamente mostre todos os funcionários que utilizam 
um determinado carro, como faremos?
Podemos criar um índice sobre a coluna “placa do carro”. Ao forne-
cer uma placa AAA-1010, por exemplo, o índice será usado para percor-
rer rapidamente a tabela com mais de 10.000 funcionários e recuperar 
aquelas duas ou três pessoas que usam esse mesmo carro para se des-
locar. Essa é a aplicabilidade de um índice não único.
Entretanto, devemos lembrar que todo e qualquer índice – seja 
de chave primária ou não, seja único ou não – irá acarretar todas as 
desvantagens já citadas anteriormente: consumo de espaço para ar-
mazenamento e consumo de tempo para serem criados e atualizados. 
Nesse sentido, temos uma situação contraditória que frequentemente 
tem que ser avaliada pelo administrador de banco de dados. Se, por 
um lado, o índice pode nos trazer ganho de performance para acesso 
aos dados, ele pode também, por outro lado, nos trazer perda de per-
formance durante a criação e a atualização do BD. Desse modo, como 
definir o que devemos fazer? A resposta é simples: avaliando o perfil de 
uso do banco de dados.
Se tivermos um banco de dados no qual a inserção e a atualização 
de dados são muito frequentes, feitas por muitas pessoas simultanea-
mente e precisam de um tempo de resposta muito baixo, a criação de 
índices pode ser uma desvantagem para esse processo. Já, se tivermos 
um BD no qual consultas são feitas com muita frequência, diferentes 
critérios de seleção são usados, grandes volumes de dados são filtrados 
para se recuperar poucos registros ao final e o tempo de resposta para 
uma consulta é crítico, a criação de índices pode ser uma vantagem.
114 Banco de Dados I
Concluímos, desse modo, que definir o que possa ser vantagem ou 
desvantagem durante o projeto de um banco de dados é uma questão 
de ponto de vista. O que pode ser visto como vantagem para um sistema 
de informação pode ser visto como desvantagem para outro e assim por 
diante. O equilíbrio entre custo e benefício de cada estratégia adotada 
no projeto é o que definirá qual é a solução para esta difícil equação a ser 
resolvida. Temos que lembrar que o próprio perfil de uso do BD irá se al-
terar com o passar do tempo e que vantagens ou desvantagens também 
poderão se alterar. Esse processo deve ser tratado como um processo 
contínuo e cíclico que exigirá constante monitoração.
5.3 Criação e manutenção de um 
projeto de banco de dados
Vídeo
Em relação a um processo contínuo e cíclico, que é a criação de um 
banco de dados, vamos ver quais são as tarefas que devem ser executa-
das na etapa de projeto do BD. Muitas vezes, para simplificar nossa linha 
de raciocínio sobre o processo de criação de um banco de dados, nós 
dizemos que cada etapa tem um começo, um meio e um fim distintos. 
Ao finalizar uma delas, naturalmente daremos início à próxima que, tam-
bém ao ser completada, liberará a próxima etapa. Trata-se realmente 
de uma simplificação de conceitos, pois o que acontece na prática é que 
várias dessas tarefas de cada etapa acabam sendo executadas de modo 
interdependente, e, muitas vezes, até concorrentemente.
Vejamos um exemplo para tudo ficar mais claro. Imagine que você 
já tem experiência na criação de bancos de dados e conhece todos os 
requisitos desde o modelo lógico, o modelo relacional e o projeto físi-
co, assim você inicia a criação de um novo modelo conceitual de um 
novo BD. Sabendo que, ao chegar à etapa do modelo relacional será 
necessário escolher uma chave primária – e que, na fase do projeto, 
poderá também eleger outras colunas da sua tabela para serem chavesalternativas ou chaves secundárias (colunas que terão índices únicos) 
–, você com certeza já terá seus olhos voltados, na fase de projeto con-
ceitual, para quais atributos suas entidades poderão ter e que servirão 
para futuras chaves de acesso. Assim, também na etapa de derivação 
do modelo relacional, acabará por escolher as melhores chaves primá-
rias para as tabelas, já conhecendo o impacto que essa escolha terá no 
momento em que os índices venham a ser definidos.
Projeto de banco de dados 115
Podemos concluir que a experiência que acumulamos em um proces-
so de criação de um banco de dados será importante para que, nos próxi-
mos processos, possamos atingir mais rapidamente o objetivo de ter uma 
estrutura de BD adequada. Isso não significa que, por exemplo, tenhamos 
que abrir mão de alguns formalismos e requisitos da fase de derivação do 
modelo relacional somente porque, no projeto físico, sabemos que isso irá 
gerar algum impacto negativo. Mas, se pudermos evitar o retrabalho ou os 
ajustes, sabendo que eles virão a ocorrer, por que não evitá-los?
Dentre as atividades executadas no processo de criação do projeto 
físico do banco de dados, temos uma que é essencial e que trata do 
dimensionamento de espaço físico para as áreas de dados, de índices 
e de arquivos de trabalho utilizados pelo sistema gerenciador de banco 
de dados. Estes três espaços físicos podem variar conforme as carac-
terísticas de cada BD e dos sistemas de informação que os utilizarão. 
Por exemplo, um banco de dados pode ter um crescimento vegetativo 
– aquele que acontece naturalmente no dia a dia em função das tran-
sações de negócio – pequeno, mas uma carga inicial de dados muito 
grande. Pode ainda ocorrer o contrário: uma carga inicial pequena com 
um crescimento vegetativo enorme.
Imagine que sua empresa irá carregar os dados de todos os funcioná-
rios de um antigo arquivo para um BD recém-criado (novo) e que depois 
irá inserir novos funcionários quando forem contratados. Se sua empre-
sa hoje já tem 10.000 funcionários, mas, no próximo ano, em função da 
crise econômica, praticamente não irá contratar mais ninguém, você terá 
um banco de dados que começa grande e que cresce muito pouco. Já no 
outro extremo, em uma situação inversa, imagine que sua empresa está 
lançando um novo curso on-line em uma plataforma de EaD (ensino a 
distância) e que seu banco de dados de alunos começará sem nenhum 
registro prévio, mas que, em um ano, deve atingir um grande crescimen-
to vegetativo, chegando, talvez, a 150.000 alunos cadastrados.
Cada situação dessas exige um tipo de abordagem do administrador 
de banco de dados. Cargas iniciais grandes, com pouca atualização, irão 
demandar uma estratégia de gerenciamento de espaço diferente daque-
la que seria usada para BDs que começam com poucos registros, mas 
crescem rapidamente. Existe ainda uma situação que pode ser pior: ca-
sos nos quais, em situações eventuais – e muitas vezes não conhecidas –, 
o banco de dados precisa se adaptar a grandes crescimentos de volume. 
Essas são situações bem mais complexas de serem gerenciadas.
116 Banco de Dados I
Imagine que sua empresa vende produtos on-line em um site de 
e-commerce e que seu volume de vendas é de 100 mil pedidos por 
mês. Porém, em função de uma campanha ou até de uma situação 
isolada que fuja do nosso controle, em um determinado mês, o site 
registra um volume de vendas de 500 mil pedidos. Como você imagina 
que a estrutura física do seu BD irá se comportar? Ela estará preparada 
para este crescimento fora da média? Teremos capacidade para rece-
ber, no banco de dados, todos esses pedidos? Ele terá que ser expandi-
do? Precisará de cinco vezes mais tempo para que possamos executar 
uma cópia de segurança do BD no final do dia? Podemos perceber que 
crescimentos não previstos podem ser muito mais complexos de se-
rem gerenciados do que crescimentos planejados.
O dimensionamento de espaço físico deverá ser feito considerando 
volumes iniciais, taxas de crescimento e volumes finais previstos. Se 
nossa média de vendas é de 100 mil pedidos por mês e começamos 
hoje a vender, ao final de 12 meses teremos 1.200.000 pedidos. Por 
quanto tempo desejamos manter os pedidos em histórico? Se a res-
posta for três anos, nosso histórico será de 36 meses. Desse modo, pre-
cisaremos de um banco de dados que suporte 3.600.000 pedidos em 
suas tabelas, para que, a partir deste volume, todo mês sejam incluídos 
novos 100 mil pedidos e expurgados outros 100 mil pedidos que já não 
precisam mais ficar no histórico.
Parece simples quando trabalhamos com números estáveis, mas 
temos que lembrar que uma média de 100 vendas em um mês pode 
significar que, em um mês, teremos só 50 mil pedidos; já em outro te-
remos 150 mil ou três vezes mais pedidos. Podemos aumentar nosso 
BD em 150 mil novos pedidos e expurgar somente 50 mil pedidos. Que 
desequilíbrio isso pode gerar? O gerenciamento passa a ser não tão 
simples como somar e subtrair o mesmo número todo mês.
Além de calcular o tamanho inicial e o tamanho final de nossas áreas 
físicas – e de gerenciá-las para que se mantenham próximas do tama-
nho final previsto –, temos ainda outra complicação gerada pelas novas 
facilidades oferecidas por novas tecnologias de armazenamento distri-
buído de dados. Antigamente, se estivéssemos dimensionando um BD 
para 3.600.000 pedidos, teríamos somente a preocupação de escolher, 
por exemplo, onde ficariam armazenados nossos 3,6 gigabytes de da-
dos referentes a esses pedidos. Contudo, a questão se complica com 
outra pergunta: de que modo vamos distribuir estes 3.6 gigabytes em 
Projeto de banco de dados 117
diferentes locais físicos para que eles tenham uma melhor performan-
ce de acesso? Será que os pedidos recebidos do Brasil devem ficar ar-
mazenados em um servidor ABC situado no país enquanto os pedidos 
recebidos da Europa deveriam ficar em um servidor XYZ situado nesse 
continente? Será que os pedidos dos últimos seis meses deveriam ficar 
no servidor ABC enquanto os pedidos com mais de seis meses de his-
tórico deveriam ficar no servidor XYZ?
Temos agora não só o dimensionamento de espaço físico, mas a 
segmentação desse espaço físico. É bem verdade que hoje muitos pro-
vedores de serviços de BD na nuvem procuram oferecer facilidades de 
gerenciamento dinâmico de espaço físico que, de certo modo, masca-
ram toda essa complexidade e permitem que os bancos de dados cres-
çam dinamicamente conforme surja a demanda por mais espaço. Além 
disso, muitos provedores também oferecem meios de tornar o local 
físico do armazenamento praticamente invisível para o usuário leigo, 
pois o conceito de nuvem de dados nos dá estes recursos.
Porém, para toda facilidade criada, temos um preço a pagar. Imagi-
nar que o espaço físico do seu banco de dados poderá crescer indefi-
nidamente sem que ninguém perceba é um mito. Algumas operações 
que o BD executa – por exemplo, a alocação de mais espaço físico em 
disco para que ele cresça – geram instantes de degradação de perfor-
mance na operação normal de um sistema de informações.
Muitas pessoas imaginam que um BD pode crescer automaticamen-
te – por exemplo, 10% de seu tamanho atual – cada vez que estiver 
sem espaço físico para armazenar seus dados. Desse modo, poderiam 
alocar inicialmente um pequeno espaço e depois deixar que ele cresça 
automaticamente quando for necessário. Isto é verdade? Sim, isso real-
mente ocorrerá. Mas a qual custo?
A cada vez que o SGDB tiver que alocar novos 10% de espaço, ele 
irá interromper todas as atividades de acesso a dados no BD. Neste 
tempo em que a interrupção estiver ativa, novas páginas (unidades de 
alocação física para guardar dados) estarão sendo formatadas e agre-
gadas ao espaço físico gerenciado. Isso significa que, nesse período, 
haverá uma degradação percebida pelas aplicações que requisitam ou 
que desejam armazenar dados novos no BD. Podemos falar de milisse-
gundos ou de segundos, tudo vai depender de quanto espaço terá que 
118 Bancode Dados I
ser alocado e de quantas vezes por mês, por dia ou até por hora esse 
processo se repetirá.
No cenário descrito acima, fica claro que, se soubermos que nos-
so banco de dados terá a necessidade de alocar 1.2 gigabytes por 
ano para armazenar seus 1.200.000 pedidos, criá-lo inicialmente com 
somente 100 megabytes e esperar que todo mês sejam necessárias 
expansões automáticas pode não ser a melhor estratégia. Pior ainda, 
se as expansões automáticas forem de só 10% dos 100 megabytes ini-
ciais, começaremos com 100 megabytes e, já no segundo mês de ope-
ração, teremos 10 expansões de 10 megabytes sendo feitas durante o 
mês (1 a cada 3 dias), para poder fechar o mês com os 200 megabytes 
previstos para 200 mil pedidos.
Tudo o que falamos até aqui sobre as estratégias de alocação inicial, 
a taxa de crescimento e a alocação final esperada aplica-se não somen-
te para a área de dados, mas também para os índices que consumirão 
espaço. Eles também terão uma alocação inicial, crescimento e aloca-
ção final prevista. Além disso, também poderão ser segmentados e fi-
car no mesmo servidor de dados ou em outro servidor apartado. O 
mesmo se aplica aos demais arquivos de trabalho que o banco de da-
dos gera, por exemplo, os arquivos de redo log.
Os arquivos de redo log são estruturas que guardam imagens de 
atualizações feitas no BD, de modo que seja possível refazer essas 
atualizações automaticamente caso o banco de dados seja perdido 
e seja necessário aplicar uma imagem anterior (backup) dos dados. 
BDs com baixo volume de atualizações têm arquivos de redo log 
pequenos, já BDs com grandes volumes de atualização têm arquivos 
de redo log grandes. Mas o que dizer da situação em que nossa em-
presa tinha previsto gerar somente 100 pedidos em um mês, mas 
gerou 500 mil pedidos? O arquivo de redo log estava preparado para 
crescer 500%? Esse é um desdobramento das questões de dimensio-
namento e da segmentação de espaços físicos que também deverão 
ser levados em conta.
Considerando que a complexidade do dimensionamento do espa-
ço físico tenha sido compreendida e devidamente equacionada, temos 
ainda outra tarefa importante a ser executada no processo do projeto 
físico do banco de dados: a análise de transações. Talvez possamos 
dizer que essa atividade vem até antes ou que seja executada em pa-
Projeto de banco de dados 119
ralelo ao próprio dimensionamento. Não podemos ter o dimensio-
namento se não realizarmos a análise de transações. Assim como o 
processo, o projeto físico de um BD é composto de um conjunto de 
tarefas inter-relacionadas. E, aqui, temos um exemplo real desta inter-
dependência de tarefas: uma estará vinculada à outra. Ao dimensionar, 
conhecemos o perfil das transações e, conhecendo os perfis das tran-
sações, podemos melhor dimensionar.
Essas transações que desejamos conhecer e analisar são justamente 
aquelas ligadas à criação inicial dos dados no BD (carga inicial), ao cres-
cimento vegetativo, à manutenção de dados históricos e ao expurgo de 
dados obsoletos. Teremos que identificar alguns elementos essenciais 
para cada um desses quatro grandes grupos de transações. Eles serão 
a fonte de referência para nossa tomada de decisão no projeto físico.
O primeiro elemento a identificar é a carga de trabalho que 
cada transação irá oferecer ao banco de dados. Em outras palavras, 
qual será o volume de dados que será processado em cada transa-
ção, quantas transações serão executadas por unidade de tempo e 
quando serão executadas. Considere uma transação de fechamento 
mensal que seja executada uma única vez por mês, durante a ma-
drugada, após o fechamento de todas as lojas e que irá manipular 
os 100 mil pedidos gerados no mês. Essa transação será comparada 
à outra de fechamento diário de caixa, que será executada todos os 
dias úteis do mês após as 18h – antes do fechamento de cada uma 
das 50 lojas em todo o Brasil – e com um volume de aproximada-
mente 100 pedidos por dia.
O primeiro passo é conhecer as transações que competem por re-
cursos no banco de dados bem como suas características. Mas ainda 
restam outras perguntas a serem respondidas: qual é o grau de im-
portância dessa transação? Ela é obrigatória? É essencial naquele mo-
mento? Poderá ser adiada ou refeita em outro momento? Consumirá 
quanto tempo para ser executada? Todas essas respostas somente a 
área de negócio pode nos dar ou nos ajudar a descobrir baseando-
-se em cases e experiências similares. Entretanto, com o conhecimento 
dessas respostas, poderemos nos preparar para os corretos dimen-
sionamento e segmentação do banco de dados. Podemos identificar, 
na comparação das duas transações mencionadas, que o fechamento 
diário da loja é muito mais prioritário, pois, caso não seja concluído no 
120 Banco de Dados I
final do expediente, o lojista estará impedido de abrir seu caixa no dia 
seguinte em virtude da falta das informações do dia anterior.
Com base em todas as informações coletadas neste momento, o 
administrador de banco de dados poderá buscar uma alternativa que 
maximize os resultados para a maioria das transações prioritárias. 
Mesmo que todas as transações não consigam ter a estrutura 100% 
adequada aos seus requisitos, poderemos, ainda, utilizar outros recur-
sos, como a criação de visões (views) do BD para propiciar algum tipo 
de estrutura diferenciada para essas transações. A desnormalização de 
tabelas pode também ser uma opção a ser considerada, de modo a 
prover melhor performance para acesso a conjuntos de dados que fre-
quentemente terão de ser agrupados.
Esse processo de adequação de demandas para inserção e recu-
peração de dados por diversos tipos de aplicações, cada um com suas 
particularidades, precisa ser realizado não só no momento inicial da 
concepção do projeto físico, mas também de modos cíclico e contínuo 
ao longo do tempo. Podemos imaginar que a realidade de cada uma 
das aplicações irá se alterar com o passar do tempo. Podemos ter no-
vos requisitos ou alterações nos requisitos atuais, seja pela mudança 
nos volumes de dados envolvidos, na frequência de execução das tran-
sações ou até na quantidade de pessoas que venham a utilizar os siste-
mas que compartilham esse banco de dados.
As transações mapeadas nesta fase irão também estabelecer cri-
térios e indicar quando e como deverão ser definidos os índices sobre 
cada uma das tabelas. Sabendo que os índices têm um papel essencial 
na performance de acesso aos dados de uma tabela, principalmente 
no acesso direto, e identificando transações prioritárias que exigem 
tempos de acesso baixos, teremos a indicação de que o uso de um ou 
mais índices poderá ser recomendada. Esses índices têm também suas 
particularidades físicas a serem selecionadas, pois, conforme o SGBD 
escolhido, poderemos ter configurações diferenciadas para sua criação 
e seu armazenamento, como a definição de se eles serão agrupados 
ou não – os termos clusterizado e não clusterizado também são usados.
A distribuição dos arquivos de dados nos diferentes discos e dife-
rentes servidores da rede também poderá influenciar o desempenho 
global das transações que tenham suas demandas mapeadas. Peque-
nos detalhes físicos, como permitir que dois servidores possam prover 
Projeto de banco de dados 121
dados simultaneamente (em paralelo) para uma mesma demanda, po-
derão acelerar o resultado final de uma transação crítica que manipule 
volumes muito grandes de dados. No momento em que temos grandes 
volumes de dados sendo manuseados e demandas por tempos de res-
posta baixos esperados por uma aplicação, qualquer pequeno ganho na 
execução de um simples comando de acesso ao BD poderá ser decisivo.
Aspectos operacionais também precisam ser levados em conta 
no momento em que está sendo criado nosso projeto físico. Entre 
esses aspectos operacionais temos, por exemplo, a definição das ne-
cessidades relativas à segurança, à disponibilidade e à recuperação 
de falhas no banco de dados. Imagine que todo um esforço foi apli-
cado parase obter uma estrutura que agora oferece performance 
adequada à boa parte das aplicações que o acessam. Porém, um 
simples evento de falha em um servidor pode deixar o BD indisponí-
vel por horas ou dias até que o servidor seja reparado. Em um cená-
rio também catastrófico, imagine que esse mesmo banco de dados 
acabe sendo invadido e tendo seus dados capturados para usos não 
autorizados. Nos dois casos, teríamos deixado de prover, na etapa 
de projeto físico, recursos que auxiliassem a área de segurança da 
informação a proteger e disponibilizar de modo contínuo os dados 
existentes no banco de dados.
Isso demonstra que o projeto físico não é só impactado pelas carac-
terísticas das transações de negócio que um banco de dados deverá 
atender, mas também por critérios de disponibilidade e de segurança 
da informação. Muitas vezes, esses próprios critérios poderão ser, de 
certo modo, contraditórios em relação às demandas das aplicações. 
Garantir a redundância de um BD pode significar reduzir a performan-
ce de sua operação, o que, em um primeiro momento, é uma demanda 
das aplicações, mas pode também garantir que essas mesmas aplica-
ções continuem a funcionar após eventos de falhas.
Realizar procedimentos de cópias físicas do banco de dados para 
garantir que, em caso de alguma falha, também tenhamos meios de 
recuperar os dados originais e aplicar sobre eles os redo logs, de modo 
a recompor as transações de negócio executadas, também pode impli-
car um consumo adicional de recursos e uma ligeira queda de perfor-
mance das aplicações que, naquele momento, estejam acessando os 
dados. Isso ocorre mesmo que a cópia física seja feita sem interromper 
completamente o acesso físico ao banco de dados (hot backup). Mas 
122 Banco de Dados I
que opção nos restaria? Não executar cópias físicas de segurança do 
banco de dados é uma opção que está fora de cogitação.
Outro ponto a ser avaliado no projeto físico diz respeito ao expur-
go de dados históricos. Isso pode significar efetivamente a remoção 
de dados que não tenham mais aplicabilidade a qualquer processo de 
negócio (atual ou futuro) ou alternativamente a transferência de parte 
dos dados da base de dados para uma outra estrutura de banco de 
dados que não aquela que originou os dados.
Vamos ver aqui um exemplo. Voltando ao caso de uma empresa 
que gere 1.200.000 pedidos de vendas e que precise manter um his-
tórico por 3 anos, podemos imaginar que uma venda realizada há 37 
meses poderá estar submetida a dois tratamentos: exclusão definiti-
va da base de dados sem que uma cópia destes dados seja guardada 
ou exportação para uma planilha de todos os pedidos de vendas com 
37 ou mais meses de vigência com posterior exclusão dos dados do 
banco de dados. Assim, caso seja necessário no futuro ter acesso a 
estes pedidos de vendas excluídos, eles estarão disponíveis em uma 
planilha ou em outro meio similar. Esses procedimentos de exporta-
ção de dados serão também transações que precisarão ser avaliadas 
pelo administrador de banco de dados.
Os pontos que vimos até aqui são tarefas executadas pelo ABD nas 
estruturas que estão sendo planejadas e construídas na fase de projeto 
do banco de dados. Existe, porém, outra atividade da qual o adminis-
trador de banco de dados participa, mas que não interfere na estrutura 
do BD e sim nos programas que serão criados ou nos programas que 
já existem e que hoje manipulam o banco de dados. Essa atividade é 
o ajuste dos comandos SQL (structured query language) que são utili-
zados pelos programadores para consultar e atualizar dados no BD. 
Muitas vezes, a performance final, que é desejada para uma transação 
de negócio que interage com o banco de dados, pode não estar sendo 
atingida apesar dos cuidados já tomados na criação das estruturas do 
BD. Nesse caso, será necessário rever e alterar os comandos SQL usa-
dos nos programas.
Um programa que interage com o banco de dados utiliza uma lingua-
gem padrão para consultar e atualizar dados no BD. Essa linguagem é 
bastante simples e flexível, de modo que, muitas vezes, o programador 
escreve um comando correto que efetivamente retorna ou atualiza os 
Projeto de banco de dados 123
dados necessários, mas que não utiliza os melhores recursos do banco 
de dados para atingir seus objetivos. Desse modo, temos um programa 
cuja performance não é a ideal, implicando uma transação de negócio 
que também não terá a performance necessária.
Muitas vezes, uma simples revisão do código do programa ou uma 
monitoração do banco de dados no momento em que o programa está 
rodando permitirá que se encontre um melhor modo de acessar o BD 
com menor consumo de recursos e de tempo. Consideramos que essa 
tarefa de apoio à programação também faz parte das atividades cíclicas 
e contínuas que terão de ser executadas na fase de projeto físico do 
banco de dados.
5.4 Tipos de projetos de bancos de dados 
Vídeo As etapas de modelagem conceitual e de modelagem relacional são 
bastante independentes da escolha do sistema gerenciador de banco 
de dados que venhamos a fazer, pois seguem conceitos genéricos. O 
mesmo não pode ser dito da etapa do projeto físico, que, apesar de 
também se utilizar de alguns conceitos genéricos, depende diretamen-
te dos recursos oferecidos pelo fabricante de SGDB.
O sistema gerenciador de banco de dados escolhido por uma em-
presa para dar suporte às suas estruturas do BD terá como caracterís-
tica de fabricação o atendimento de um conjunto de requisitos dentre 
aqueles apresentados nas 12 regras de Codd (1970). Porém, para o 
administrador de banco de dados, outros elementos adicionais serão 
importantes. Podemos ter, por exemplo, dois SGBDs diferentes que 
implementam os mesmos recursos sob o ponto de vista das regras de 
Codd, mas que se utilizam de diferentes estruturas internas, modos de 
implementação e outras particularidades internas.
Quando falamos em particularidades internas, temos, por exem-
plo, diferentes algoritmos e estruturas de manipulação de índices. 
Podemos ter também diferentes métodos de compactação de dados, 
métodos de criação de cópias de segurança (backup), métodos de im-
portação ou exportação de dados, entre outros. Todas essas caracterís-
ticas internas precisam ser conhecidas em detalhes pelo administrador 
de banco de dados para que, durante a fase de projeto físico, ele possa 
definir qual é o recurso mais adequado a um ou outro projeto.
124 Banco de Dados I
Nem sempre todos os projetos irão demandar o uso dos mesmos 
recursos; podemos ter projetos físicos orientados para diferentes fina-
lidades. Imagine, por exemplo, um projeto de um aplicativo móvel (para 
smartphone) que será utilizado somente por uma pessoa em modo 
local (sem compartilhamento de dados). Agora imagine outro projeto 
corporativo com uma base de dados que será compartilhada por mais 
de mil pessoas simultaneamente. Cada um desses projetos terá carac-
terísticas próprias que poderão nos levar a diferentes projetos físicos.
Os recursos do banco de dados que podem ser necessários a um 
destes projetos podem não ser aplicáveis ao outro. O tipo de projeto 
que teremos que conduzir para um aplicativo poderá não ser similar ao 
tipo de projeto que conduziremos para um sistema corporativo. Avaliar 
as transações prioritárias é uma tarefa essencial para um sistema cor-
porativo; já para um aplicativo móvel (APP) talvez seja desnecessário, 
pois o nível de concorrência entre processos será diferente.
Outros fatores também podem afetar o tipo de projeto físico que 
teremos que desenvolver. Para que tenham a performance desejada, 
projetos que manipulem grandes volumes de dados terão requisitos 
especiais que precisarão do conhecimento mais detalhado do SGBD 
escolhido. Projetos que envolvem distribuição física de dados em di-
versas localidades também demandarão conhecimentos específicos do 
administrador de banco de dados. Esses exemplos demonstram que a 
etapa de projeto físico pode ser bastante variada em função da carac-
terística decada projeto, e que, portanto, não podemos imaginar que 
as estratégias usadas para um projeto físico de um banco de dados 
possam ser totalmente aproveitadas em todos os futuros projetos que 
venhamos a fazer.
CONSIDERAÇÕES FINAIS
O projeto físico tem um papel vital no processo de criação de um ban-
co de dados. Ele exige um amplo conhecimento dos recursos oferecidos 
pelo SGBD. As vantagens e benefícios obtidos pelo uso de um ou outro 
recurso nem sempre serão aplicáveis a todos os projetos. Assim, o traba-
lho do administrador de banco de dados precisa ser realizado sempre de 
modo coerente com as demandas de cada projeto.
Entretanto, atribuir a responsabilidade pelo sucesso da criação de um 
BD somente ao administrador de banco de dados não é correto. Como vi-
Projeto de banco de dados 125
mos, ele depende de muitas informações para a tomada de decisão sobre 
qual estrutura irá criar. Ele depende também do analista de sistemas para 
identificar processos de negócio prioritários, e do administrador de dados 
para identificar regras de criação e atualização que deve garantir. Além 
disso, estão inclusos, nesse processo, profissionais da área de segurança 
da informação (para conhecer os requisitos de segurança que os dados 
deverão respeitar), programadores (para desenvolver programas com o 
objetivo de otimizar os acessos ao banco de dados) e todo o time de TI 
(para operar e disponibilizar o BD para o ambiente de produção).
O sucesso de um projeto físico é, portanto, o resultado de um proces-
so colaborativo que se inicia com um modelo conceitual bem elaborado, 
com a derivação de um modelo relacional e com a coleta de inúmeras in-
formações com confiabilidade para permitir criar, desse modo, estruturas 
com as melhores performance, segurança e disponibilidade.
ATIVIDADES
1. Explique por que o uso de índices nem sempre pode ser a melhor 
solução para melhorar a performance de um banco de dados.
2. Por que o administrador de banco de dados não pode realizar o 
projeto físico sem a colaboração de vários outros profissionais da área 
de informática?
3. Justifique por que uma transação de negócio prioritária deve ter 
seus requisitos avaliados com maior importância do que outra não 
prioritária.
4. Por que cada projeto físico pode ser diferente de outro já realizado 
anteriormente?
REFERÊNCIAS
CODD, E. F. A relational model of data for large shared data banks. Communications of the 
ACM, Nova Iorque, NY, v. 13, n. 6, jun.1970.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
NAVATHE, S.; ELMASRI, R. Sistemas de bancos de dados. São Paulo: Pearson, 2005.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de 
Janeiro: Elsevier, 2012.
126 Banco de Dados I
6
Linguagem estruturada 
para consultas
Todas as etapas de construção de um banco de dados somam-se 
de modo que, ao final, tenhamos uma estrutura física disponível 
para que os programadores possam criar seus programas com a 
 finalidade de incluir, alterar, excluir e consultar dados no BD.
Assim, veremos, neste capítulo, de que forma os programadores 
poderão incorporar, em seus programas, novos comandos que os 
permitam manipular os dados de um BD. Esta nova linguagem não 
é, como estamos acostumados a pensar, uma linguagem de progra-
mação cuja finalidade é executar operações matemáticas, transfor-
mações em dados ou mesmo validações. Para esse fim, continuamos 
a utilizar as linguagens de programação que já conhecemos, como 
Delphi, Java, C++, Visual Basic e similares. Temos disponível, agora, 
outro conjunto de comandos de programação que serão agregados a 
essas linguagens já conhecidas.
Para aqueles que já estão habituados a utilizar linguagens de pro-
gramação convencionais, podemos dizer que esse novo conhecimen-
to não deve ser motivo de preocupação, pois, de modo geral, ele é 
muito mais simples e fácil de ser utilizado. Essa nova linguagem é tão 
versátil que, além de servir de meio para que os programadores criem 
seus programas, ela também poderá ser utilizada pelo administrador 
de banco de dados no momento em que ele precise criar novas ta-
belas e colunas ou alterar essas estruturas. Trata-se, portanto, de um 
conjunto de comandos que serve para todas as finalidades de intera-
ção com o banco de dados.
Deste modo, seja bem-vindo, neste capítulo, ao mundo da SQL 
(Structured Query Language) ou linguagem estruturada de consultas. 
Segundo Navathe e Elmasri (2005), a SQL foi baseada nas linguagens 
de álgebra e cálculo relacional e inicialmente denominada SEQUEL 
(Structured English Query Language), além de ser mais inteligível do 
que suas linguagens hospedeiras (aquelas nas quais a SQL será in-
corporada), consideradas técnicas demais para o usuário.
Linguagem estruturada para consultas 127
6.1 O que é e para que serve a SQL? 
Vídeo Segundo Silberschatz, Korth e Sudarshan (2012), em 1970, a IBM – 
uma das maiores fabricantes de computadores da época – desenvolvia 
mais um de seus tantos projetos de novas tecnologias. Esse projeto tinha 
como objetivo criar uma linguagem de manipulação de dados que se 
adequasse ao modelo relacional, que surgia e vinha tomando corpo em 
um mercado carente de alternativas para o gerenciamento de grandes 
volumes de dados. As equipes de pesquisadores dos laboratórios de San 
José, na Califórnia, eram desafiadas a encontrar um meio de permitir 
que os bancos de dados fossem facilmente utilizados pelos programado-
res. Se o objetivo fosse atingido, mais um ponto de resistência à adoção 
dos novos BDs relacionais seria superado. Os sistemas de arquivos con-
vencionais da época, em sua maior parte utilizados por linguagens como 
o COBOL, tinham comandos extremamente simples para manipular da-
dos, logo, qualquer nova solução que fosse proposta deveria também 
manter este nível de facilidade, sob o risco de perder admiradores caso 
não o fizesse.
Outra premissa que esse projeto tinha era a de que a linguagem 
criada pudesse se transformar em um padrão para o mercado de 
SGBDs, e não somente uma linguagem específica da própria IBM. Por 
isso, todos os resultados da pesquisa estavam sendo compartilhados e 
validados com o mercado. Isso fazia com que outros concorrentes 
igualmente pudessem se interessar em absorver o novo padrão que 
seria criado e publicado. Também nos laboratórios da IBM, em um pro-
jeto paralelo, desenvolviam-se pesquisas com o objetivo de criar e pro-
ver, para o mercado, um produto de uso comercial 
– não só para laboratório –, baseado no modelo rela-
cional. Esse projeto se chamava System R, uma refe-
rência ao sistema relacional proposto por Codd.
Acredita-se que a IBM planejava lançar o seu 
SGBD relacional com base na linguagem SQL como 
o primeiro do mercado. Porém, não foi o que acon-
teceu. Outros concorrentes também trabalhavam 
em paralelo nesse mercado buscando oferecer 
sistemas gerenciadores de banco de dados relacio-
nais. Isso fez com que, no ano de 1979, a Oracle – 
Vídeo
No vídeo Análise de desem-
penho de consultas SQL em 
bancos de dados Oracle, 
publicado pelo canal 
Leonardo Mairene Muniz, 
você poderá ver como é 
realizada a monitoração 
da execução de comandos 
SQL e como podem ser 
executados ajustes que 
otimizem a estrutura de 
acesso aos dados.
Disponível em: https://youtu.be/
I604SeSK_d8. Acesso em: 27 maio 
2020.
128 Banco de Dados I
que até hoje é um dos principais fornecedores de SGBDs relacionais 
– lançasse o primeiro SGBD relacional baseado no padrão de lingua-
gem SQL.
Após lançado o primeiro produto comercial fundamentado no pa-
drão SQL, entramos em uma nova fase que, de certo modo, teve im-
portância definitiva para que a SQL se transformasse em um padrão. 
O padrão “de fato” já estava se estabelecendo a partir do momento em 
que um ou mais fornecedores podiam utilizar as pesquisas da IBM para 
incorporar a SQL em seus produtos. Contudo, ainda havia dúvidas se 
este padrão seria um padrão “de fato” ou “de direito”.
A dúvida deixou de existir quando,já no início dos anos 1980, o Ins-
tituto Americano de Padronização (ANSI – American National Standarts 
Institute) iniciou o desenvolvimento de uma versão padronizada da 
SQL, publicando-a no ano de 1986. Em 1987, a Organização Interna-
cional para Padronização (ISO – International Standarts Organization) 
também publicava essa primeira versão padronizada da SQL. Poste-
riormente, outras versões padronizadas pelo ANSI/ISO foram lançadas, 
ficando conhecidas como SQL-89, SQL-92, SQL-99, SQL-2003, SQL-2008 
e SQL-2011 e SQL-2016. Cada um desses nomes é um indicativo do ano 
em que essas versões foram revisadas e publicadas.
A SQL é, portanto, um conjunto de comandos padronizados que exe-
cuta funções ligadas diretamente ao banco de dados. Esses comandos 
podem ser incorporados a outras linguagens de programação, chama-
das de linguagens hospedeiras, para permitir que os programadores pos-
sam executar funções de criação, atualização e recuperação de dados no 
BD. Alguns desses comandos podem, ainda, ser utilizados pelo adminis-
trador de banco de dados para criar objetos no BD e para administrá-lo.
Os comandos SQL podem também ser utilizados isoladamente, sem 
estarem necessariamente incorporados a outras linguagens de progra-
mação. Isso pode acontecer desde que estejamos diretamente conecta-
dos ao banco de dados por meio de uma ferramenta que possa receber, 
por intermédio da digitação direta, os comandos a serem executados, 
conforme mostra a Figura 1 a seguir. Perceba que, sem que tenhamos 
de criar um programa prévio, podemos nos conectar ao banco de dados 
Exemplo (BOX-1 da figura) e nele podemos recuperar todos os registros 
da tabela AUTOR por meio do comando Select * (BOX-2 da figura). A lista 
de registros recuperados do BD é apresentada com as colunas ID  AUTOR 
e Nome_AUTOR, como resultado desse comando no BOX-3.
Linguagem estruturada para consultas 129
BOX 1
BOX 2
BOX 3
Figura 1
Exemplo da execução de um comando SQL
Fonte: Elaborada pelo autor.
Por meio de uma ferramenta como a exibida na Figura 1, podemos 
recuperar dados do BD, editá-los ou até exclui-los acessando um regis-
tro específico de cada vez ou grupos de registros que tenham caracte-
rísticas similares.
Podemos dividir os comandos da SQL em quatro grandes grupos 
conforme suas funções. Esses grupos podem estar relacionados às fun-
ções de administração do banco de dados ou de manipulação de dados 
por meio de programas e aplicações. Cada um dos comandos depende 
de permissões de acesso que também são providas por comandos SQL. 
Os comandos e os grupos estão representados na figura a seguir.
Utilizado para definir a estrutura do banco de dados ou esquema. 
CREATE Criar objetos no banco de dados
ALTER Alterar a estrutura da base de dados
TRUNCATE Remover todos os registros de uma tabela
COMMENT Adicionar comentários ao dicionário de dados
RENAME Renomear um objeto
DDL: Data Definition Language 
Figura 2
Comandos SQL divididos por grupos de comandos
(Continua)
130 Banco de Dados I
Utilizado para o gerenciamento de dados dentro de objetos do BD.
SELECT Recuperar dados do banco de dados
INSERT Inserir dados em uma tabela
UPDATE Atualizar os dados existentes em uma tabela
DELETE Excluir registros de uma tabela,
CALL Chamar um subprograma PL/SQL
EXPLAIN PLAN Explicar o caminho de acesso aos dados
LOCK TABLE Controle de concorrência
DML: Data Manipulation Language 
Utilizado para o gerenciamento de dados dentro de objetos do BD.
SELECT Recuperar dados do banco de dados
INSERT Inserir dados em uma tabela
UPDATE Atualizar os dados existentes em uma tabela
DELETE Excluir registros de uma tabela
CALL Chamar um subprograma PL/SQL
EXPLAIN PLAN Explicar o caminho de acesso aos dados
LOCK TABLE Controle de concorrência
DML: Data Manipulation Language 
Utilizado para definir as permissões de acesso.
GRANT Atribuir privilégios de acesso do usuário a objetos do BD
REVOKE Remover os privilégios de acesso aos objetos do BD
DCL: Data Control Language (DCL) 
Utilizado para agrupar e gerenciar as mudanças feitas por instruções DML. 
COMMIT Salvar o trabalho feito
SAVEPOINT Criar um ponto de retorno em uma transação
ROLLBACK Restaurar o BD ao original desde o último COMMIT
TCL: Transaction Control Language
Fonte: Elaborado pelo autor.
Ao observar a coleção desses comandos SQL, você identificará o uso 
de verbos em inglês que traduzem exatamente a função que será exe-
cutada em cada um deles. Isso favorece o aprendizado e a compreen-
são de sua aplicabilidade.
6.2 Vantagens e desvantagens de se usar a SQL 
Vídeo Desde seu surgimento, a SQL tem sido reconhecida como uma lin-
guagem universal para acesso a bancos de dados relacionais. Além do 
reconhecimento obtido entre os diversos fornecedores de SGBD, prin-
cipalmente impulsionado pelas chancelas da ANSI e ISO, a SQL passou 
a ser amplamente conhecida e utilizada pelos programadores dos mais 
diversos ambientes de desenvolvimento. Seja na elaboração de siste-
mas pessoais, de aplicativos para celular ou até de sistemas corporati-
vos, a SQL tem sido utilizada como linguagem universal para acesso a 
Linguagem estruturada para consultas 131
dados em praticamente todo BD criado com qualquer modelo de siste-
ma gerenciador de banco de dados.
Essa unificação de linguagem de acesso a dados permite, hoje, que 
qualquer programador – conhecendo qualquer linguagem de progra-
mação como Delphi, C++, Visual Basic, Java ou outra qualquer – possa 
ter a mesma facilidade de acesso a um banco de dados, seja para um 
sistema de pequeno, médio ou grande porte.
Outra característica importante que a SQL apresenta é o fato de ser 
uma linguagem não procedural. Isso significa que, ao utilizar um co-
mando SQL para acessar, editar, incluir ou até excluir um dado no BD, 
não precisamos informar como isso deve ser feito, mas somente dizer 
o que deve ser feito. Podemos, por exemplo, codificar um comando 
informando “recupere todos os funcionários que moram no estado do 
Paraná”. Não precisamos informar qual é o melhor caminho para obter 
esses dados, se um índice deve ou não ser usado e assim por diante, 
pois a SQL tem a capacidade de ser objetiva, concisa e precisa. Resolver 
como os dados que desejamos manipular serão acessados fará parte 
das tarefas que ficam a cargo de um complexo algoritmo interno, o 
qual é totalmente controlado pelo SGBD.
O fato de a SQL ser uma linguagem declarativa nos leva a outra 
característica que também traz grande facilidade de uso: ela se utiliza 
praticamente de uma linguagem fluente que, ao utilizar da língua in-
glesa como base, oferece muita facilidade para ser lida e interpretada. 
Isso implica não termos mnemônicos e abreviaturas que dificultam o 
aprendizado, a memorização e a interpretação dos comandos SQL.
Imagine um comando que descreva a seguinte demanda de infor-
mação: “selecione Nome, Cidade e Sigla do Estado com base na tabela 
FUNCIONARIO onde as siglas dos estados são iguais a PR”. É pratica-
mente desse modo que você escreverá seu comando em SQL. Assim, 
teríamos a seguinte transposição:
Figura 3
Transposição da linguagem fluente para um comando SQL
Selecione Nome, Cidade e Sigla do Estado a partir da tabela 
FUNCIONARIO onde as siglas dos estados são iguais a “PR”
SELECT Nome, Cidade, SiglaEstado FROM FUNCIONARIO 
WHERE SiglaEstado = “PR”
Linguagem fluente
SQL
Fonte: Elaborada pelo autor.
Mnemônico: conjunto de 
técnicas utilizadas para auxiliar o 
processo de memorização. 
Glossário
132 Banco de Dados I
Assim como nesse exemplo em questão – no qual utilizamos o co-
mando SELECT para selecionar do BD alguns dados (Nome, Cidade e 
Estado) com base em um conjunto de dados (FUNCIONARIO) e apli-
camos um critério de seleção, que é o fato de que só deveriam ser 
escolhidos aqueles registros nos quais o Estado referenciado fosse o 
Paraná –, teremos inúmeros outros comandos SQL que se assemelha-
rão muito à estrutura gramatical da língua inglesa.
Justamente por essa semelhança comuma estrutura gramatical de 
uma linguagem fluente, os comandos SQL permitem que tenhamos bas-
tante flexibilidade na construção dos mais variados comandos derivados 
de um único comando básico. Podemos, por exemplo, em um coman-
do SELECT, expandir a lista dos dados solicitados indicando uma lista de 
campos a serem recuperados, indicar uma ou mais fontes para obtenção 
de dados simultaneamente ou até ter critérios de restrição múltiplos. No 
exemplo a seguir, podemos ver essa transformação.
Figura 4
Exemplo de um SQL simples sendo expandido
SELECT Nome, Cidade, SiglaEstado FROM FUNCIONARIO 
WHERE SiglaEstado = “PR”
SELECT Nome, Cidade, SiglaEstado, NomeEstado FROM 
FUNCIONARIO, ESTADO 
WHERE Funcionario.SiglaEstado = “PR”
AND FUNCIONARIO.SiglaEstado = ESTADO.SiglaEstado
SQL simples
SQL complexo
Fonte: Elaborada pelo autor.
Veja que, por meio da simples adição de novos campos na lista de 
dados a serem recuperados e de novos critérios para junção de dados 
entre as tabelas FUNCIONARIO e ESTADO, fomos capazes de retornar 
à informação NomeEstado da tabela ESTADO, podendo, dessa manei-
ra, mostrar não somente a sigla “PR”, mas também o nome “Paraná” 
junto aos dados recuperados. No entanto, mesmo tendo aumentado a 
complexidade do comando elaborado, notamos que ele praticamente 
permite uma leitura fluente, como “Selecione nome, cidade, sigla do 
estado e nome do estado das tabelas FUNCIONARIO e ESTADO onde a 
sigla do estado na tabela FUNCIONARIO seja igual a PR” e que essa sigla 
tenha o mesmo valor na tabela ESTADO.
É essa capacidade de interpretação fluente de um comando SQL 
que nos permite reconhecer e compreender facilmente um comando 
Linguagem estruturada para consultas 133
codificado com esse padrão, seja ele envolvendo uma ou mais colunas, 
uma ou mais tabelas e uma ou mais condições de inter-relacionamento 
entre as tabelas.
Como toda a estruturação do modelo relacional se baseia em um 
formato tabular (representação por meio de tabelas), podemos assegu-
rar que qualquer linguagem que consiga referenciar uma ou mais colu-
nas de uma ou mais linhas de uma tabela conseguirá sempre abranger 
todo o universo de dados dentro de um BD relacional. Se conseguirmos 
estabelecer, ainda, uma linguagem que possa relacionar (criar relacio-
namentos) com o uso de referências entre valores de tabelas, podemos 
também assegurar que será possível agregar dados de diferentes ta-
belas que tenham um elo por meio de uma ou mais colunas. Isso nos 
dará capacidade de “navegação” (deslocamento) dentro de um modelo 
relacional.
Considere este exemplo: se com a matrícula de um funcionário 
(“João da Silva”) conseguirmos acessar seus dados e, com esses dados, 
constatarmos que ele nasceu no estado do “Paraná”, podemos desco-
brir – por meio dos relacionamentos existentes entre as entidades do 
modelo – que esse estado está vinculado à região “Sul”. Sabendo que 
o estado do Paraná pertence à região Sul, podemos constatar nova-
mente a qual país essa região está vinculada – no caso, “Brasil”. Com 
isso, obtemos a informação de que o funcionário “João da Silva” nas-
ceu no “Brasil”. Essa informação, antes, não estava disponível na tabela 
 FUNCIONARIO, mas agora foi obtida por meio da navegação no mo-
delo de dados. Se a SQL nos permite elaborar comandos que explici-
tamente criem esse processo de navegação, ela servirá para qualquer 
propósito de relacionamento e obtenção de dados.
6.3 Criação e manutenção de uma SQL 
Vídeo A codificação dos comandos SQL deverá ser feita respeitando-se 
uma sintaxe específica que, conforme já vimos, assemelha-se muito 
ao inglês fluente. Os comandos poderão ser compilados e submeti-
dos para execução tanto por meio de programas criados com lingua-
gens hospedeiras (aquelas nas quais os comandos SQL são agregados) 
quanto pelo intermédio de programas utilitários ou ambientes de ge-
renciamento do banco de dados.
134 Banco de Dados I
Apresentamos, a seguir, somente para fins de ilustração dos recursos 
que cada um deles oferece, a sintaxe de formação de alguns dos coman-
dos SQL mais comumente usados. Sugerimos que, caso precise aprender 
sobre a sintaxe de todos os comandos do SGBD escolhidos para imple-
mentar seu projeto, você procure a documentação oferecida pelo forne-
cedor do SGBD. Apesar de o SQL ser uma linguagem padrão, pequenas 
diferenças de sintaxe podem existir entre um e outro fornecedor.
6.3.1. Comando CREATE <objeto>
Nesse comando, o objeto pode ser um dos elementos dispostos a 
seguir. Cada um deles terá uma sintaxe complementar específica.
• CREATE CLUSTER
• CREATE CONTEXT
• CREATE CONTROLFILE
• CREATE DATABASE
• CREATE DATABASE LINK
• CREATE DIMENSION
• CREATE DIRECTORY
• CREATE DISKGROUP
• CREATE FLASHBACK ARCHIVE
• CREATE FUNCTION
• CREATE INDEX
• CREATE INDEXTYPE
• CREATE JAVA
• CREATE LIBRARY
• CREATE MATERIALIZED VIEW
• CREATE MATERIALIZED VIEW LOG
• CREATE OPERATOR
• CREATE OUTLINE
• CREATE PACKAGE
• CREATE PACKAGE BODY
• CREATE PFILE
• CREATE PROCEDURE
• CREATE PROFILE
• CREATE RESTORE POINT
• CREATE ROLE
• CREATE ROLLBACK SEGMENT
• CREATE SCHEMA
• CREATE SEQUENCE
• CREATE SPFILE
• CREATE SYNONYM
• CREATE TABLE
• CREATE TABLESPACE
• CREATE TRIGGER
• CREATE TYPE
• CREATE TYPE BODY
• CREATE USER
• CREATE VIEW
Para exemplificar como cada um desses comandos se comple-
menta, apresentaremos em detalhes a sintaxe de dois comandos: 
CREATE DATABASE (Figura 5) e CREATE TABLE (Figura 6). Eles são co-
mandos básicos utilizados para criar um novo BD e uma nova tabela, 
respectivamente.
Sintaxe dos comandos 
SQL do banco de dados 
PostgreSQLe Oracle
Neste material, você po-
derá conhecer a sintaxe 
SQL implementada pelos 
SGBDs PostgreSQL e 
Oracle, além de verificar 
algumas de suas particu-
laridades, embora esses 
sistemas se pareçam 
bastante com os diversos 
SGDBs disponíveis no 
mercado.
Disponíveis em: http://pgdocptbr.
sourceforge.net/pg82/sql-
commands.html; https://docs.
oracle.com/cd/B28359_01/
server.111/b28286/toc.htm. Acesso 
em: 27 maio 2020.
Saiba mais
Linguagem estruturada para consultas 135
Figura 5
Sintaxe do comando CREATE DATABASE
CREATE DATABASE nome
 [ [ WITH ] [ OWNER [=] dono_do_banco_de_dados ]
 [ TEMPLATE [=] modelo ]
 [ ENCODING [=] codificação ]
 [ TABLESPACE [=] espaço_de_tabelas ]
 [ CONNECTION LIMIT [=] limite_de_conexões ] ]
Fonte: PostgreSQL, 2020c.
Como vários dos campos são opcionais, podemos ter como exem-
plo prático a execução de um comando com a seguinte sintaxe: CREATE 
DATABASE TESTE, no qual o nome TESTE é o nome do BD criado.
Figura 6
Sintaxe do comando CREATE TABLE
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE 
nome_da_tabela ( [
 { nome_da_coluna tipo_de_dado [ DEFAULT expressão_padrão ] [ 
restrição_de_coluna [ ... ] ]
 | restrição_de_tabela
 | LIKE tabela_ancestral [ { INCLUDING | EXCLUDING } { DEFAULTS | 
CONSTRAINTS } ] ... }
 [, ... ]
] )
[ INHERITS ( tabela_ancestral [, ... ] ) ]
[ WITH ( parâmetro_de_armazenamento [= valor] [, ... ] ) | WITH 
OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE espaço_de_tabelas ]
onde restrição_de_coluna é:
[ CONSTRAINT nome_da_restrição ]
{ NOT NULL |
 NULL |
 UNIQUE parâmetros_do_índice |
 PRIMARY KEY parâmetros_do_índice |
 CHECK ( expressão ) |
 REFERENCES tabela_referenciada [ ( coluna_referenciada ) ] [ 
 MATCH FULL | MATCH PARTIAL | MATCH SIMPLE ]
 [ ON DELETE ação ] [ ON UPDATE ação ] }
[ DEFERRABLE | NOT DEFERRABLE ] [ INITIALLY DEFERRED | INITIALLY 
IMMEDIATE ]
Fonte: PostgreSQL, 2020c.
136 Banco de Dados I
Também nesse caso, como muitos dos campos apresentados na 
sintaxe são opcionais, podemos ter um exemplo prático de criação de 
uma tabela, mostrado na figura a seguir.
Figura 7
Exemplo de um comando CREATE TABLE
CREATE TABLE hr.admin_emp (
 empno NUMBER(5) PRIMARY KEY,
 ename VARCHAR2(15) NOT NULL,
 ssn NUMBER(9) ENCRYPT,
 job VARCHAR2(10),
 mgr NUMBER(5),
 hiredate DATE DEFAULT(sysdate),
 photo BLOB,
 sal NUMBER(7,2),
 hrly_rate NUMBER(7,2) GENERATED ALWAYS AS (sal/2080),
 comm NUMBER(7,2),
 deptno NUMBER(3) NOT NULL
 CONSTRAINT admin_dept_fkey REFERENCES hr.departments
 (department_id))
 TABLESPACE admin_tbs
 STORAGE ( INITIAL 50K);
Fonte: ORACLE® Help Center, 2020. 
A definição de vários parâmetros importantes para a tabela e suas 
colunas pode ser realizada já no momento de sua criação. Ela pode ser 
feita também posteriormente, por meio do comando ALTER TABLE.
6.3.2. Comando ALTER <objeto>
Comando no qual o objeto pode ser um dos elementos a seguir:
• ALTER CLUSTER
• ALTER DATABASE
• ALTER DIMENSION
• ALTER DISKGROUP
• ALTER FLASHBACK ARCHIVE
• ALTER FUNCTION
• ALTER INDEX
• ALTER INDEXTYPE
• ALTER JAVA
• ALTER MATERIALIZED VIEW
• ALTER MATERIALIZED VIEW 
LOG
• ALTER OPERATOR
• ALTER OUTLINE
• ALTER PACKAGE
• ALTER PROCEDURE
• ALTER PROFILE
• ALTER RESOURCE COST
• ALTER ROLE
• ALTER ROLLBACK SEGMENT
• ALTER SEQUENCE
• ALTER SESSION
• ALTER SYSTEM
• ALTER TABLE
• ALTER TABLESPACE
• ALTER TRIGGER
• ALTER TYPE
• ALTER USER
• ALTER VIEW
Linguagem estruturada para consultas 137
A seguir, vemos um exemplo do comando ALTER TABLE, que possui, 
em sua sintaxe, diversas opções que permitem alterar vários aspectos 
de uma tabela já existente, a saber:
Adicionar uma coluna na tabela.
Adicionar uma restrição para a tabela.
Excluir uma coluna da tabela.
Excluir uma restrição da tabela.
Aumentar o tamanho de um campo VARCHAR. 
Mudar o valor default de uma coluna.
Mudar o critério de aceitar/não aceitar valores nulos em 
uma coluna.
su
pa
nu
t p
iya
ka
no
nt
/S
hu
tte
rs
to
ck
A sintaxe do comando ALTER TABLE segue o modelo da figura a 
seguir:
Figura 8
Sintaxe do comando ALTER TABLE
ALTER TABLE table-Name
{
 ADD COLUMN column-definition |
 ADD CONSTRAINT clause |
 DROP [ COLUMN ] column-name [ CASCADE | RESTRICT ]
 DROP { PRIMARY KEY | FOREIGN KEY constraint-name | UNIQUE 
 constraint-name |
 CHECK constraint-name | CONSTRAINT constraint-name }
 ALTER [ COLUMN ] column-alteration | LOCKSIZE { ROW | TABLE }
}
Fonte: ALTER TABLE..., 2020.
138 Banco de Dados I
São alguns exemplos do comando ALTER TABLE:
Para adicionar uma coluna do tipo varchar a uma tabela:
ALTER TABLE distribuidores ADD COLUMN 
 endereco varchar(30);
Fonte: PostgreSQL, 2020a.
Para remover uma coluna da tabela:
ALTER TABLE distribuidores DROP COLUMN 
endereco RESTRICT;
Fonte: PostgreSQL, 2020a.
Para mudar o tipo de duas colunas existentes em uma única operação:
ALTER TABLE distribuidores
 ALTER COLUMN endereco TYPE varchar(80),
 ALTER COLUMN nome TYPE varchar(100);
Fonte: PostgreSQL, 2020a.
Para mudar o nome de uma coluna existente:
ALTER TABLE distribuidores RENAME COLUMN 
endereco TO cidade;
Fonte: PostgreSQL, 2020a.
Para mudar o nome de uma tabela existente:
ALTER TABLE distribuidores RENAME TO 
 fornecedores;
Fonte: PostgreSQL, 2020a.
Para adicionar uma restrição de não nulo a uma coluna:
ALTER TABLE distribuidores ALTER COLUMN 
logradouro SET NOT NULL;
Fonte: PostgreSQL, 2020a.
Para remover a restrição de não nulo da coluna:
ALTER TABLE distribuidores ALTER COLUMN 
logradouro DROP NOT NULL;
Fonte: PostgreSQL, 2020a.
Para adicionar uma restrição de verificação à tabela:
ALTER TABLE distribuidores
 ADD CONSTRAINT chk_cep
 CHECK (char_length(cod_cep) = 8);
Fonte: PostgreSQL, 2020a.
Linguagem estruturada para consultas 139
Para remover uma restrição de verificação de uma tabela e de todas as suas 
descendentes:
ALTER TABLE distribuidores DROP 
 CONSTRAINT chk_cep;
Fonte: PostgreSQL, 2020a. 
Para adicionar uma restrição de chave estrangeira a uma tabela:
ALTER TABLE distribuidores
 ADD CONSTRAINT fk_dist_end
 FOREIGN KEY (endereco)
 REFERENCES enderecos (endereco)
 MATCH FULL;
Fonte: PostgreSQL, 2020a. 
Para adicionar uma restrição de unicidade (multicoluna) à tabela:
ALTER TABLE distribuidores
 ADD CONSTRAINT unq_id_dist_cod_cep
 UNIQUE (id_dist, cod_cep);
Fonte: PostgreSQL, 2020a. 
Para mover a tabela para outro espaço de tabelas:
ALTER TABLE distribuidores SET TABLESPACE 
espaco_de_tabelas_rapido;
Fonte: PostgreSQL, 2020a. 
Para mover a tabela para outro esquema:
ALTER TABLE meu_esquema.distribuidores 
SET SCHEMA seu_esquema;
Fonte: PostgreSQL, 2020a. 
Os comandos Create e Alter pertencem ao grupo de comandos 
DDL (Data Definition Language) utilizados para criação e alteração dos 
principais objetos do banco de dados. Na sequência, conheceremos al-
guns dos comandos do grupo DML (Data Manipulation Language). O 
 primeiro deles é o comando SELECT, responsável pela recuperação de 
dados de uma ou mais tabelas do BD.
140 Banco de Dados I
6.3.3. Comando SELECT
Dentre os comandos DML (Data Manipulation Language), temos o 
SELECT como um dos mais conhecidos e utilizados. É por meio dele 
que toda a recuperação de dados de um banco de dados é realizada. A 
figura a seguir mostra a sintaxe do comando SELECT.
Figura 9
Sintaxe do comando SELECT
SELECT [ ALL | DISTINCT ] 
[ TOP ( expression ) [ PERCENT ] [ WITH TIES ] ] 
<select_list> 
<select_list> ::= 
 { 
 * 
 | { table_name | view_name | table_alias }.* 
 | { 
 [ { table_name | view_name | table_alias }. ] 
 { column_name | $IDENTITY | $ROWGUID } 
 | udt_column_name [ { . | :: } { { property_name | field_name } 
 | method_name ( argument [ ,...n] ) } ] 
 | expression 
 [ [ AS ] column_alias ] 
 } 
 | column_alias = expression 
 } [ ,...n ] 
Fonte: Microsoft, 2017a.
 • ALL: especifica quais linhas duplicadas podem aparecer no con-
junto de resultados; ALL é o padrão.
 • DISTINCT: especifica que só linhas exclusivas podem aparecer 
no conjunto de resultados. Valores nulos são considerados iguais 
para os propósitos da palavra-chave DISTINCT.
 • TOP ( expression ) [ PERCENT ] [ WITH TIES ]: indica que apenas 
um primeiro conjunto ou uma porcentagem de linhas especifi-
cadas será retornado de um conjunto de resultados de consul-
ta.  Expression  pode ser um número ou uma porcentagem das 
linhas.
 • <select_list>: indica a lista de colunas a serem selecionadas para 
o conjunto de resultados. A lista de seleções é uma série de ex-
pressões separadas por vírgulas. O número máximo de expres-
sões que pode ser especificado na lista de seleção é 4096.
Linguagem estruturada para consultas 141
 • O uso do caractere “*” especifica que todas as colunas das ta-
belas e exibições na cláusula FROM devem ser retornadas.  As 
colunas são retornadas por tabela ou exibição, conforme especi-
ficado na cláusula FROM, e na ordem em que existem na tabela 
ou na exibição (MICROSOFT, 2017a).
A combinação desses diferentes parâmetros no comando SELECT pode 
produzir diferentes resultados na recuperação de dados de uma mesma 
tabela. É possível recuperar todos ou somente parte das linhas de uma 
tabela pela simples inserção de um complemento em sua sintaxe. Para 
compreender o uso desse comando SQL, observe o exemplo a seguir.
Imagine uma tabela chamada PRODUCT. Para recuperar todos os campos dessa ta-
bela, que está associada ao schema Production, é necessário gerar como saída uma 
lista classificada pela coluna Name:
SELECT *
FROM Production.Product
ORDER BY Name ASC;
Ou
SELECT p.*
FROM Production.Product AS p
ORDER BY Name ASC;
Fonte: Microsoft, 2017b.
Para recuperar somente algumas das colunas da tabela PRODUCT, podemos enume-
rar as colunas desejadas, por exemplo, Name, ProductNumber e ListPrice. Isso re-
duzirá o total de colunas recuperadas e apresentadas na lista que será gerada como 
saída, economizando, desse modo, recursos de processamento e memória. Também 
nesse caso, a coluna ListPrice (nome original) terá seu nome modificado na lista 
gerada como saída para o novo nome (Price).
SELECT Name, ProductNumber, ListPrice AS Price
FROM Production.Product
ORDER BY Name ASC;
Fonte: Microsoft, 2017b.
Restrições de registros que serão recuperados do banco dedados também poderão 
ser aplicadas à lista a ser gerada como saída por meio da cláusula WHERE, con-
forme a seguir. Nesse caso, somente os produtos com a coluna ProductLine = R e 
que tenham, também, a coluna DaysToManufacture < 4 serão recuperados do BD e 
incluídos na lista de saída.
SELECT Name, ProductNumber, ListPrice AS Price
FROM Production.Product
WHERE ProductLine = ‘R’
AND DaysToManufacture < 4
ORDER BY Name ASC;
Fonte: Microsoft, 2017b.
142 Banco de Dados I
Até este ponto, vimos somente exemplos em que os dados de uma única tabela 
foram selecionados para recuperação e apresentação, mas temos também a possibi-
lidade de executar comandos SELECT que executam junções entre dados de duas ou 
mais tabelas. O relacionamento entre as tabelas (Product e SalesOrderDetail) pode 
ser estabelecido entre dois ou mais campos com conteúdos comuns entre as tabelas 
(p.ProductID e sod.ProductID).
SELECT p.Name AS ProductName,
 NonDiscountSales = (OrderQty * UnitPrice),
 Discounts = ((OrderQty * UnitPrice) * UnitPrice 
 Discount)
FROM Production.Product AS p
INNER JOIN Sales.SalesOrderDetail AS sod
ON p.ProductID = sod.ProductID
ORDER BY ProductName DESC;
Fonte: Microsoft, 2017b.
Outros dois comandos bastante utilizados no grupo dos comandos 
DML são o INSERT e o UPDATE, os quais realizam as funções de inserir 
e de atualizar dados nas tabelas, respectivamente.
6.3.4. Comando INSERT
Em sua sintaxe básica, o comando INSERT tem os seguintes parâ-
metros: nome da tabela, lista de colunas que receberão os valores e 
lista de valores que serão armazenados. No exemplo a seguir, a tabe-
la PRODUCTS receberá, nas colunas ProductId, ProductName, Price e 
ProductDescription, os valores 1, “Clamp”, 12.48 e “Workbench clamp”.
INSERT dbo.Products (ProductID, ProductName, Price, 
ProductDescription)
 VALUES (1, ‘Clamp’, 12.48, ‘Workbench clamp’)
Fonte: Microsoft., 2017c.
A ordem das colunas pode ser alterada sem restrições, desde que 
na lista de valores seja realizada a mesma alteração de ordem, ou seja, 
os nomes e valores precisam possuir uma equivalência direta. Todas 
as colunas que tenham indicativo de “not null” (não aceitam ficar sem 
conteúdo) deverão ter seus dados informados na lista de colunas do 
comando INSERT. Somente as colunas nas quais esteja definida a regra 
de restrição “null” (aceitam valores nulos) poderão ficar sem valores 
durante a inserção de um registro na tabela.
Linguagem estruturada para consultas 143
6.3.5 Comando UPDATE
O comando UPDATE permite que realizemos a atualização de uma 
ou mais linhas de uma tabela em uma ou mais colunas dessa mesma 
tabela. Com esse recurso, podemos atualizar todas as linhas de uma 
tabela por meio da execução de um único comando que afetará simul-
taneamente todas as linhas que respeitem a regra de restrição codifi-
cada no comando.
No comando a seguir, o produto cujo código é igual a 50 terá seu 
nome alterado para “Flat Head Screwdriver”. Esse é um exemplo de um 
comando que afeta somente uma linha da tabela, mas, caso a cláusula 
WHERE indicasse outra condição mais genérica – por exemplo, todos 
os produtos que tenham código superior a 50 –, estaríamos trocando 
o nome de vários produtos de uma única vez. Caso se deseje, também, 
alterar várias colunas em um mesmo comando, uma lista de cláusulas 
SET poderia ser codificada no mesmo comando.
UPDATE dbo.Products
 SET ProductName = ‘Flat Head Screwdriver’
 WHERE ProductID = 50
Fonte: Microsoft, 2017c.
Uma variação do comando acima – que altera somente um valor 
em uma única linha – pode ser vista no comando a seguir, no qual 
várias linhas da mesma tabela (todas onde o código seja maior que 
50) terão dois valores alterados simultaneamente (ProductName e 
ProductDescription):
UPDATE dbo.Products
 SET ProductName = ‘Flat Head Screwdriver’
 ProductDescription = ‘Workbench clamp’
 WHERE ProductID > 50
Fonte: Microsoft, 2017c.
Os comandos DCL (Data Control Language) que serão usados 
para definir as permissões de acesso de um usuário a diversos tipos 
de objetos do banco de dados são os comandos GRANT (assegurar) 
e REVOKE (revogar).
Como exemplo, vamos apresentar diversas sintaxes possíveis para o 
comando GRANT. Podemos ver que é possível definir permissões para 
cada um dos comandos DML (Select, Insert, Update etc.) ou para criar e 
se conectar a um BD e até para executar funções.
144 Banco de Dados I
6.3.6. Comando GRANT
Todo o controle de segurança que será implementado dentro de 
um banco de dados se utilizará também de comandos SQL para ser 
ativado ou removido. Essa característica nos permite dar e remover 
permissões de acesso a vários objetos do banco de dados. O comando 
GRANT terá a função de criar as permissões, já o comando REVOKE terá 
a função de removê-las. A figura a seguir mostra suas sintaxes.
Figura 10
Sintaxes do comando GRANT
GRANT { { SELECT | INSERT | UPDATE | DELETE | REFERENCES | TRIGGER }
 [,...] | ALL [ PRIVILEGES ] }
 ON [ TABLE ] nome_da_tabela [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { { USAGE | SELECT | UPDATE }
 [,...] | ALL [ PRIVILEGES ] }
 ON SEQUENCE nome_da_seqüência [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [,...] | ALL [ 
PRIVILEGES ] }
 ON DATABASE nome_do_banco_de_dados [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
 ON FUNCTION nome_da_função ( [ [ modo_do_argumento ] [ 
nome_do_argumento ] tipo_do_argumento [, ...] ] ) [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }
 ON LANGUAGE nome_da_linguagem [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
 ON SCHEMA nome_do_esquema [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT { CREATE | ALL [ PRIVILEGES ] }
 ON TABLESPACE nome_do_espaço_de_tabelas [, ...]
 TO { nome_do_usuário | GROUP nome_do_grupo | PUBLIC } [, ...] [ WITH 
GRANT OPTION ]
GRANT role [, ...] TO nome_do_usuário [, ...] [ WITH ADMIN OPTION ]
Fonte: PostgreSQL, 2020d.
Linguagem estruturada para consultas 145
Finalmente, no grupo dos comandos TCL (Transaction Control 
 Language), veremos a sintaxe dos comandos COMMIT e ROLLBACK, 
que são utilizados, respectivamente, para efetivar uma transação ou 
para desfazê-la. Tanto um quanto o outro são bastante simples, sen-
do o mais importante a definição do ponto do processo em que serão 
inseridos.
6.3.7 Comandos COMMIT e ROLLBACK
Nas sintaxe a seguir, as palavras Work e Transaction são opcionais. 
Quando inseridas, elas não têm efeito para diferenciar o comporta-
mento dos comandos.
Figura 11
Sintaxe dos comandos COMMIT e ROLLBACK
 COMMIT [ WORK | TRANSACTION ]
 ROLLBACK [ WORK | TRANSACTION ]
Fonte: PostgreSQL, 2020b.
Com base nesses exemplos, é possível perceber que a linguagem 
SQL é bastante flexível e abrangente. Ela nos permite realizar todas as 
atividades necessárias em um banco de dados desde sua criação, defi-
nição de critérios de segurança, inserção de dados e atualização até re-
moção de dados e objetos desse mesmo BD. Conhecer e explorar todo 
o potencial da SQL será, certamente, um grande diferencial para que 
você se torne um excelente administrador de dados ou programador.
O artigo Linguagem SQL: Capítulo 6 – Comandos SQL, publicado na plataforma 
Elipse Knowlegedbase, traz um exemplo de criação de um BD e suas tabelas, 
a inserção de dados nessas tabelas e a recuperação deles por meio de 
vários comandos, sempre exemplificando o resultado das operações.
Acesso em: 27 maio 2020. 
https://kb.elipse.com.br/linguagem-sql-capitulo-6-comandos-sql/ 
Artigo
146 Banco de Dados I
6.4 Tipos de SQL 
Vídeo Entre os exemplos de sintaxes apresentadas, utilizamosdiversas re-
ferências ao SGBD Oracle, ao SGBD SQL-Server (Microsoft) e ao SGBD 
PostgreSQL. Existem muitos outros no mercado, mas cada um conta 
com pequenos detalhes que os diferenciam tanto nas questões de im-
plementação dos recursos da tecnologia relacional quanto na imple-
mentação da linguagem SQL.
Originalmente, a ideia era criar uma linguagem padrão para o manu-
seio dos bancos de dados relacionais. Porém, procurando se distinguir 
um dos outros, os fabricantes acabaram criando pequenos diferenciais 
na implementação de suas SQLs. Desse modo, apesar de manterem 
grande similaridade, nem todas as SQLs que podem ser executadas 
em um SGBD de um fabricante poderão ser executadas exatamente 
com a mesma sintaxe em um SGBD de outro. Em linhas gerais, eles se 
assemelham; contudo, na prática, podem gerar problemas de compi-
lação, acusando erros ou falhas de sintaxe. Portanto, se você criar um 
programa, utilizar a SQL de um fabricante e futuramente decidir trocar 
o SGBD, será necessário realizar uma revisão de cada comando para 
adequá-lo ao novo fabricante.
Pensando nessa situação, surgiram alguns frameworks (ambiente 
de desenvolvimento) que utilizam interfaces genéricas para acesso aos 
dados, isolando, dessa maneira, o código do programa da camada SQL 
de um ou de outro fabricante. Um exemplo desse tipo de recurso é o 
Hibernate, plataforma em que se escrevem comandos para acesso a 
dados usando uma linguagem parecida com a SQL, mas que, na ver-
dade, não é uma SQL de um fabricante, mas sim uma SQL genérica. O 
Hibernate criará um mecanismo automático de conversão para poder 
interagir com a SQL de um fornecedor A, B ou C.
A grande vantagem desse método é que o código criado pelo progra-
mador não terá vínculo com nenhuma SQL de nenhum fornecedor. Se o 
SGBD utilizado por um programa for alterado futuramente, não haverá 
impacto no código previamente escrito, pois ele continuará a ter a mes-
ma sintaxe do Hibernate. Assim, bastará que um novo conversor para 
um novo BD seja aplicado e o programa continuará funcionando nor-
malmente. Toda a inteligência a ser aplicada no processo de conversão 
de SQLs estará a cargo de uma camada que fará essa tarefa automatica-
mente, dando flexibilidade ao programador na construção de soluções.
Você pode conhecer um 
pouco mais sobre a plataforma 
 Hibernate acessando o site: 
https://hibernate.org/. Acesso 
em: 28 maio 2020.
Saiba mais
Linguagem estruturada para consultas 147
CONSIDERAÇÕES FINAIS
Como vimos neste capítulo, o uso da SQL (Structure Query Langua-
ge) é um fator decisivo no manuseio das estruturas de bancos de dados 
criadas. Sem essa linguagem, poderíamos criar estruturas de BD bem di-
mensionadas e bem projetadas, mas não tiraríamos proveito da arquite-
tura projetada. Sem a SQL, também não poderíamos ter flexibilidade para 
incluir, alterar, excluir e consultar os dados de um BD. Ela é, portanto, o 
elo entre a estrutura física dos dados e os sistemas de informação que 
consomem esses dados.
Conhecer e dominar os recursos que essa linguagem oferece poderá 
ser diferencial entre um programa que tenha excelente desempenho e 
um programa que, apesar de realizar as funções desejadas, não execute 
as tarefas de modo adequado. Nesse sentido, tanto programadores quan-
to administradores de bancos de dados precisam estar constantemente 
monitorando e avaliando de que forma as operações de manipulação de 
dados estão sendo executadas no BD. Para esse objetivo, o administrador 
de banco de dados conta com ferramentas que conseguem gerar relató-
rios e indicadores dos caminhos que estão sendo percorridos pelo SGBD 
para buscar um dado no BD. Analisando esses relatórios, o administrador 
de banco de dados será capaz de sugerir alguma mudança na codificação 
de um comando SQL, a criação de algum índice adicional em uma tabela 
ou outras iniciativas que possam otimizar o acesso ao banco de dados.
Como, eventualmente, diferentes SGBDs podem apresentar recursos 
diferenciados, com sintaxes de SQL diferenciadas, será importante sem-
pre avaliar qual será o SGBD a ser usado em um projeto de construção 
de um sistema de informações, de modo a obter o máximo desempenho 
em cada situação.
ATIVIDADES
1. Explique o motivo de a padronização proposta para a linguagem SQL 
não ter sido mantida integralmente por todos os fornecedores de 
sistemas gerenciadores de bancos de dados.
2. Por que os comandos SQL se tornaram facilmente compreensíveis, 
reconhecidos e utilizados pelos programadores?
3. Explique o que significa o fato de o padrão SQL ser um padrão de 
direito e não somente um padrão de fato.
4. Por que alguns comandos, como o CREATE, têm tantas sintaxes 
diferentes ?
148 Banco de Dados I
REFERÊNCIAS
ALTER TABLE statement. Disponível em: https://docs.oracle.com/javadb/10.8.3.0/ref/
rrefsqlj81859.html. Acesso em: 28 maio 2020.
MICROSOFT. Cláusula SELECT (Transact-SQL). Microsoft Docs. 2017a. Disponível em: https://
docs.microsoft.com/pt-br/sql/t-sql/queries/select-clause-transact-sql?view=sql-server-
ver15. Acesso em: 28 maio 2020.
MICROSOFT. Exemplos de SELECT (Transact-SQL). Microsoft Docs. 2017b. Disponível em: 
https://docs.microsoft.com/pt-br/sql/t-sql/queries/select-examples-transact-sql?view=sql-
server-ver15. Acesso em: 28 maio 2020.
MICROSOFT. Inserindo e atualizando dados em uma tabela (tutorial). Microsoft Docs. 
2017c. Disponível em: https://docs.microsoft.com/pt-br/sql/t-sql/lesson-1-3-inserting-and-
updating-data-in-a-table?view=sql-server-2014. Acesso em: 28 maio 2020.
NAVATHE, S.; ELMASRI, R. Sistemas de bancos de dados. São Paulo: Pearson, 2005.
ORACLE® Help Center. Example: Creating tables. Disponível em: https://docs.oracle.com/
cd/B28359_01/server.111/b28310/tables003.htm#ADMIN11004. Acesso em: 28 maio 
2020.
POSTGRESQL. Documentação do PostgreSQL 8.2.0: ALTER TABLE. Disponível em: http://
pgdocptbr.sourceforge.net/pg82/sql-altertable.html. Acesso em: 28 maio 2020a.
POSTGRESQL. Documentação do PostgreSQL 8.2.0: COMMIT Disponível em: http://
pgdocptbr.sourceforge.net/pg82/sql-commit.html. Acesso em: 28 maio 2020b.
POSTGRESQL. Documentação do PostgreSQL 8.2.0: CREATE DATABASE. Disponível em: http://
pgdocptbr.sourceforge.net/pg82/sql-createdatabase.html. Acesso em: 28 maio 2020c.
POSTGRESQL. Documentação do PostgreSQL 8.2.0: GRANT. Disponível em: http://pgdocptbr.
sourceforge.net/pg82/sql-grant.html. Acesso em: 28 maio 2020d.
SILBERSCHATZ, A.; KORTH; H. F.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de 
Janeiro: Elsevier, 2012.
Gabarito 149
GABARITO 
1 Introdução a banco de dados
1. Toda a filosofia de estruturação de um banco de dados parte do 
princípio do compartilhamento de dados e da criação de um conjunto 
único e coerente de dados para a organização. Os dados criados na 
verdade são agregados a um único repositório que servirá não só a 
um sistema, mas a todos os sistemas atuais e futuros que possam vir 
a ser desenvolvidos.
2. Porque o perfil das atividades são bastante distintos. O administrador 
de dados é um profissional que não precisa ter um perfil técnico, ele 
executa funções de gestão de dados globais da organização, mesmo 
aqueles que nem venham a ser parte de um banco de dados. Já o 
administrador de banco de dados precisa de um perfil muito técnico, 
pois ele precisa conhecer os detalhes do SGBD e se preocupar 
somente com dados que estejam em um BD. Encontrar um profissional 
que equilibre esses dois perfis pode ser difícil, pois sempre teremos 
profissionais com tendência a um desses perfis, deixando de fazer o 
papel da outra parte de modo mais completo.
3. O processo de modelagem é incremental e contínuo tanto na variedade 
dos dados que vão sendo incorporados ao banco de dados quanto na 
amplitude que esses dados podem ter. Por exemplo, um BD em que 
há somente dados de colaboradores de uma cidade posteriormente 
pode ter dados de colaboradores de todo o estado e chegar até os 
dados de colaboradores de todo o país.
2 Sistema de gerência de banco de dados
1. Nem todoo sistema de informação necessariamente requer o 
compartilhamento de dados ou a gestão de grandes e complexas 
estruturas de dados, como as gerenciadas em um BD. Sistemas de 
informação de pequeno porte poderão conviver com uma gestão local 
de seus dados, mantidos em estruturas de arquivos mais simples. 
Um aplicativo para smartphone, por exemplo, pode ter dados locais 
como o de um catálogo de nomes e telefones de pessoas mantidos 
localmente no próprio celular, sem que eles sejam compartilhados 
com outras pessoas ou sem a necessidade de um SGBD.
150 Banco de Dados I
2. O compartilhamento pode ser, e normalmente é, seletivo. Isso significa 
que é possível compartilhar dados, mas não necessariamente todo 
o escopo daqueles mapeados e carregados no BD. Se o SGBD é o 
elemento que provê o controle de acesso aos dados existentes no banco 
de dados, necessariamente ele deve prover algum tipo de recurso que 
permita ocultar algumas linhas e colunas das tabelas a serem criadas. 
Isso também contribui para aspectos de segurança, o que é, novamente, 
uma função do SGBD.
3. A arquitetura de três níveis – baseada no esquema físico, conceitual e 
externo – permite que possamos isolar a complexidade de cada nível. 
Ao ocultar detalhes físicos de alocação de espaço em disco para um 
banco de dados, por exemplo, o programador tem responsabilidade 
em escrever um programa que acesse de modo mais eficiente o 
BD, fazendo que ele se concentre na sua tarefa principal e deixe os 
detalhes físicos para o administrador de banco de dados. Enquanto o 
administrador de banco de dados se concentra nos detalhes físicos, 
esse profissional não precisa se preocupar em qual será a lógica de 
acesso aos dados que o programador utilizará.
4. O custo de propriedade de um SGBD é composto de diversos 
fatores correlacionados a sua escolha, implantação, operação e 
até sua remoção (caso um dia venha a ser substituído por outro). 
Todos os custos de mão de obra envolvidos na escolha do SGBD 
estão relacionados a instalação, configuração, treinamento, execução 
de atividades (diárias, semanais e mensais), bem como custos de 
licenciamento, compra de servidores, nobreaks (equipamentos de 
energia), locação de links de comunicação, entre outros.
3 Modelagem de dados
1. Como todo processo de construção, seja de um sistema, de uma 
casa, ou de outro artefato, a construção de um banco de dados deve 
também ser precedida de um projeto ou planejamento. Desse modo, 
será mais fácil adequar e ajustar o plano antes que se inicie a efetiva 
construção, fase na qual todos os impactos de mudança são mais 
complexos e mais custosos para serem realizados.
2. De um lado, algumas pessoas entendem como desvantagem o tempo 
consumido para gerar qualquer tipo de documentação que anteceda 
ou complemente a criação de um banco de dados. O argumento para 
essa visão desfavorável é o atraso para a efetiva criação. Já de outro 
Gabarito 151
lado, há pessoas que entendem o tempo gasto em documentação 
como algo vantajoso, uma vez que existe um ganho de tempo na fase 
de manutenção da estrutura criada.
3. Porque a abstração de uma entidade do “mundo real” só será possível 
se visualizarmos as características dessa entidade por sua observação. 
Havendo pelo menos uma característica que possamos reconhecer, 
esta será automaticamente agregada à lista de atributos da entidade 
em questão. Uma entidade sem atributos não poderia ser, portanto, 
reconhecida sem o próprio atributo ser primeiramente reconhecido.
4. O processo de derivação do modelo lógico com base no modelo 
conceitual é vantajoso porque se utiliza de regras predefinidas que 
podem ser aplicadas até mesmo de modo automático sobre as 
definições de um modelo conceitual. Ferramentas podem executar a 
derivação sem qualquer risco de omissão ou de aplicação de regras 
indevidas, assegurando uma maior consistência no modelo produzido.
4 Modelo relacional e normalização
1. A teoria dos conjuntos é validada e aceita há anos. Simples, formal 
e com embasamento matemático, pode ser aplicada a modelos 
relacionais, pois conta com operadores apropriados para a 
manipulação de conjuntos de dados.
2. Para atender às 12 regras estabelecidas por Codd, um fabricante de 
SGBDs precisa implementar recursos que se traduzam em benefícios 
para o programador, para o analista e para o administrador de banco 
de dados. Esses benefícios podem estar relacionados à programação, 
ao gerenciamento e à manutenção da integridade do BD, bem como à 
sua acessibilidade e à sua expansão.
3. Um modelo de dados criado com a estrita observância das 
características do “mundo real” produzirá um resultado teoricamente 
já normalizado. Desse modo, dispensaria a revisão das estruturas das 
tabelas por meio de regras de normalização.
4. A teoria relacional exige a presença de tabelas para representar os 
conjuntos e elementos e, assim, também deve estar coerente com 
todos os conceitos da teoria dos conjuntos. Qualquer outra estrutura 
não representada sob a forma de tabelas não será adequada à teoria 
dos conjuntos.
152 Banco de Dados I
5 Projeto de banco de dados
1. Índices podem melhorar a performance somente em situações nas 
quais o acesso aleatório e direto aos dados de uma tabela é requerido. 
Porém, outras situações nas quais a performance esteja sendo 
comprometida podem requerer outros tipos de intervenção, como 
segmentar os dados em diferentes servidores ou até eventualmente 
remover índices que estejam causando sobrecarga nas atividades de 
inserção ou exclusão de registros.
2. O administrador de banco de dados não pode realizar o projeto físico 
sem a colaboração de vários outros profissionais da área de informática. 
Isso ocorre em razão de muitos dos requisitos e informações que ele 
irá utilizar para o projeto dependem de profissionais como analista de 
sistemas, equipe da área de segurança da informação ou programadores 
que estejam desenvolvendo aplicações que utilizam esse BD.
3. Para configurar um banco de dados que atenda de modo adequado 
a variadas demandas de diversos sistemas de uma organização, 
devemos focar na prioridade dos processos de negócio como elemento 
de diferenciação, pois o BD tem como finalidade atender não a um 
sistema, mas aos processos de negócio da organização.
4. Porque projetos anteriores podem ter tido diferentes requisitos ou 
características que exigiram outras estratégias de projeto que agora não 
poderão ser aproveitadas na íntegra. As diferenças entre os requisitos 
e características dos sistemas a serem construídos poderão levar a 
estratégias completamente diferentes no projeto do banco de dados.
6 Linguagem estruturada para consultas
1. O motivo de cada fornecedor ter buscado algum tipo de diferenciação 
nos comandos SQL que originalmente eram padronizados foi o fato 
de que os seus gerenciadores de banco de dados implementam 
algumas características exclusivas que não são oferecidas por outros 
fornecedores. Portanto, os comandos SQL podem requerer algum 
ajuste na sintaxe dos seus comandos SQL.
2. Porque essa linguagem se utiliza de comandos com sintaxes que 
praticamente reproduzem a linguagem fluente em inglês, formando 
frases facilmente compreensíveis.
3. Quando a SQL surgiu, ela foi sugerida de fato como um padrão. 
Desejava-se que o padrão fosse incorporado naturalmente pela 
Gabarito 153
comunidade de banco de dados. Porém, passado algum tempo, 
entidades certificadoras e criadoras de padrões, como a ANSI e a ISO, 
formalizaram o padrão e ele passou a ser um padrão de direito.
4. Porque são comandos que podem efetuar a mesma operação, por 
exemplo, a criação (comando CREATE) de diversos tipos de objetos 
existentes no banco de dados, como tabelas, índices, restrições etc., 
tendo, assim, cada um deles parâmetros diferentes associados a esses 
objetos.
BANCO DE DADOS I
Paulo Sérgio CougoFundação Biblioteca NacionalISBN 978-85-387-6621-6
9 7 8 8 5 3 8 7 6 6 2 1 6
Código Logístico
59337
	Página em branco
	Página em branco