Banco de Dados I

BANCO DE DADOS I
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.
Paulo Sérgio Cougo
Código Logístico Fundação Biblioteca Nacional

ISBN 978-85-387-6621-6
59337 9 788538 766216

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
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.
CDD: 005.75
20-63077
CDU: 005.652.4
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
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.
Vídeos
em
QR code!
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áfica 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.
SUMÁRIO
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
Vídeo APRESENTAÇÃO
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
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!
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.
Introdução a banco de dados 9

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.
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
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.
10 Banco de Dados I
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
Processo de manipulação Informações produzidas

Lista de dados mapeados
ou transformação pela transformação
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
Signo do zodíaco
Data de nascimento Transformação ou Idade

manipulação
Pessoa viva ou morta?
Altura Pessoa alta ou baixa

(conforme a idade)
Peso Transformação ou
manipulação
Índice de Massa Corporal
Data de nascimento (risco de enfarte)

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 suas
capacidades de armazenamento eram extremamente baixas. A capaci-
Glossário
dade de armazenamento de um simples aparelho de celular não estava
mainframes: computadores de
sequer disponível nos discos magnéticos das maiores corporações, que
grande porte.
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á-
12 Banco de Dados I
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 Livro

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- A obra Sistemas de Bancos de Dados,
de Ramez Elmasri e Shamkant
do de dados que se crie possa ser chamado de banco de dados, a saber
Navathe, atualmente em sua sétima
(NAVATHE; ELMASRI, 2005): edição, tem sido considerada uma
fonte de referência, em virtude
•• Um banco de dados deve representar uma porção de um mun- de apresentar grande parte dos
do real. conceitos associados ao banco
de dados.
•• Os dados em um banco de dados devem ser logicamente coerentes.
NAVATHE, S.; ELMASRI, R. São Paulo:
•• Os dados e o próprio banco de dados devem ter uma finalidade Pearson, 2012.
específica.

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
Data de nascimento
Peso
Peso
Seleção
Altura
Altura
Pressão arterial
Nome
Nome
Temperatura

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-
1 rém, de que serviriam esses dados no nosso banco se o que desejamos
é criar um BD
1
Comumente, utilizaremos a para processamento da folha de pagamentos de uma
sigla “BD” para nos referirmos ao empresa? Para que serviria conhecer o tipo sanguíneo de um funcioná-
banco de dados.
rio para gerar sua folha de pagamento?
14 Banco de Dados I
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 PESSOA
• Data do evento • Nome
• Horário • Data de nascimento
• Regime de comunhão de bens
• Tipo de decoração
• Nome do noivo
• Nome da noiva
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-

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 compartilhados os 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
16 Banco de Dados I
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-

2
rican National Standard Institute) , temos hoje uma grande compatibi- 2
lidade entre os diversos SGBDs existentes, principalmente no tocante Para conhecer o trabalho da
ANSI, visite: https://www.ansi.
aos recursos que eles fornecem para que os sistemas de informação
org/. Acesso em: 19 fev. 2020.
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).

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
Sistemas BD BD BD BD
de arquivo Hierárquico Rede Relacional Pós-relacional
Anos 1950 Anos 1960 Anos 1970 Anos 1980 Anos 1990
Fonte: Elaborada pelo autor
18 Banco de Dados I
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
3
de ponteiros 3 . Voltando ao exemplo, se em um casamento há duas
pessoas envolvidas, o registro do casamento no banco de dados apon- Ponteiros são campos inseridos
no banco de dados para
ta, por meio de ponteiros, para os registros que contêm os dados da referenciar um outro registro
“pessoa 1” e da “pessoa 2”, as quais fazem parte do conjuntos de pes- também existente nesse mesmo
soas. Uma estrutura de encadeamento circular de dados faz o vínculo banco dedados, criando um
apontamento.
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 4

de estrutura de BD não significa que a abordagem anterior deixe de
Veremos os diferentes tipos de
existir. Assim, ainda há muitos sistemas que até hoje preservam estru- BDs ainda neste capítulo.
4
turas de arquivo ou de bancos de dados hierárquicos .

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.
20 Banco de Dados I
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

Vídeo uso de um banco de dados
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).

Quadro 1
Vantagens do banco de 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,
Compartilhamento poderemos compartilhá-los com todas as aplicações que de algum modo precisem acessar
dos dados 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.
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
Facilidade de acesso dados relacionais) que padroniza e facilita o reaproveitamento de códigos gerados para
aos dados 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.
Considerando uma estruturação coerente de dados e o objetivo de compartilhamento, há de

Redução da 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,
redundância
como, novamente, a redução do custo de propriedade dos dados.
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
Redução das
existentes no BD. O estabelecimento de regras de criação, de atualização e até de exclusão de
inconsistências 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.
Os SGBDs e as linguagens de programação que eles dispõem para a construção de funções

Disponibilidade de de acesso, atualização e exclusão de dados proveem meios para que o acesso concorrente
suporte a transações (simultâneo) de diversos programas possa ser feito a um mesmo dado sem que este
apresente um conteúdo não íntegro.
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
Manutenção da
planejada, mesmo que diversos programas e usuários simultaneamente estejam executando
integridade 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.
Como as várias transações concorrentes requisitarão atualizações e consultas sobre os mesmos

Balanceamento de
dados, poderá ocorrer situações em que um mesmo dado acabe sendo requisitado de modo
requisitos conflitante. O ambiente de banco de dados estará preparado para tratar dessas situações e
conflitantes resolvê-las de modo automático, sem que o programador precise se preocupar em escrever
rotinas especiais.
(Continua)
22 Banco de Dados I
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
Melhoria da quem pode ou não acessar um dado quanto os mecanismos de garantia das atualizações feitas
segurança 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.
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
Utilização de
eventualmente o mesmo dado representado em formatos diferentes e com regras de
padrões 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 Interdependência Sincronização dos

sobre os dados entre os dados dados no tempo
Quando tratamos de centralização, A interdependência criada pela Imagine que foi atualizado todo um
seja de dados, de processos, centralização dos dados também cadastro de pessoas, corrigindo os
de pessoas, de equipamentos, poderá afetar, de certo modo, números de CEP das residências
temos naturalmente a perda de determinada aplicação ou a de cada um dos colaboradores.
autonomia sobre esses mesmos aplicação de terceiros. No caso de Em paralelo, outro programa foi
itens. Quando determinado dado somente um arquivo próprio, com executado por outra aplicação,
é definido, criado, atualizado ou os dados que o sistema requer, mudando também os telefones dos
excluído e compartilhado com talvez esse arquivo nunca fosse colaboradores. Agora, imagine que, em
outras aplicações, é necessário impactado por outro sistema que razão de um problema no processo
realizar essas operações ciente de resolvesse inserir outras 200 mil de atualização do CEP, todos os dados
que outras pessoas podem vir a pessoas em um cadastro que tinha atualizados ficaram errados, sendo
ser impactadas. Se, por exemplo, somente mil. Um BD que tinha necessário voltar ao estágio anterior
ao resolver mudar o número de somente os dados de “pessoa” e para reprocessar a atualização. Isso
identificação de 6 dígitos para 7 de “casamento” em poucos meses seria muito fácil de ser feito, caso
dígitos, porque o sistema requer poderá ter dados de outros 100 não fosse compartilhado um BD
esse novo tamanho, qual será o ou 200 objetos, relacionados com com outras aplicações. É importante
impacto nos demais sistemas que “pessoa” e com “casamento” de lembrar que os dados não são mais
já usam esse código? Talvez a troca um modo não antes imaginado. individuais e estar preparado para
não seja tão fácil como seria em um Contudo, é importante lembrar que esse e outros tipos de situações em
arquivo individual. os dados não são mais individuais. 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.

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

O processo de criação de um banco de dados que será disponibili-
Vídeo
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.
24 Banco de Dados I
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.
Livro
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

Em Projeto de banco de
iremos necessitar, e o administrador de dados poderá nos dizer se já os
dados, Carlos Heuser
conhece ou não. Se eles já foram mapeados anteriormente, obtém-se aborda temáticas
conceituais de bancos
as informações sobre esse dado já disponível. Se não foram ainda ma-
de dados. Trata-se de
peados, pode-se, com ajuda do administrador de dados, mapear novos uma obra introdutória
e que precede a leitura
dados corporativos, ou seja, que comporão o modelo em questão, mas
de outros materiais mais
que estarão disponíveis para toda a organização futuramente. Esse é o densos.
processo incremental e cíclico que gera um conjunto compartilhado e HEUSER, C. A. 6. ed. Porto Alegre:
coerente de dados. Bookman, 2009.
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.

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,
5 5
que são diferentes dos requisitos de um SGBD em rede (IDS-II) . Muito
Integrated Data Store II, SGBD mais do que requisitos impostos por fabricantes, são requisitos impos-
produzido pela empresa francesa
tos pelas arquiteturas dos bancos de dados. Desse modo, se a arquite-
Bull.
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 o modelo 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.
26 Banco de Dados I
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?

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.
28 Banco de Dados I
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.

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.
30 Banco de Dados I
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

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-
Glossário
tões complexas, como distribuição de dados, altos volumes de arma-
terabyte: “múltiplo do byte, zenamento (da ordem de terabytes), armazenamento e recuperação
que vale 1.024 gigabytes”. “Fre-
quemente arredonda-se o valor de dados científicos, como mapas, fotos, escâneres, entre outros. Esse
do terabyte para mil gigabytes” movimento teve início em 1998, quando pela primeira vez já se falava
(HOUAISS, 2009). 6
em NoSQL , mas somente com a viabilização de softwares e hardwa-
res mais modernos voltou a ser tratado em bancos de dados NoSQL,
6 como MongoDB, Cassandra, entre outros.
Termo genérico adotado para Os BDs não relacionais utilizam os recursos do ambiente relacional
representar os bancos de dados (SQL), mas agregam outras facilidades típicas dos modelos orientados
não relacionais.
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
7
preserva e expande o modelo SQL.
Grandes BDs que armazenam
massas de dados de proporções Finalmente, nas últimas décadas, temos visto pesquisas orientadas
muito grandes quando compara novas arquiteturas de bancos de dados que possam gerenciar
paradas aos bancos de dados 7
comerciais. grandes volumes de dados em função do novo conceito de big data ,
que passou a ser agregado a uma série de aplicações. Esse é um tema
em amplo desenvolvimento e que promete ainda grandes surpresas.
32 Banco de Dados I
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.

2
Sistema de gerência
de banco de dados
Neste capítulo, vamos conhecer com mais detalhes qual é a
estrutura que 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-
34 Banco de Dados I
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
Programadores
de aplicação
PROGRAMAS DE Usuários
Equipe DBA Usuários casuais APLICAÇÃO parametrizáveis
Pré-compilador
COMANDOS PESQUISA
COMANDOS DDL
PRIVILEGIADOS INTERATIVA
Compilador da
linguagem hospedeira
TRANSAÇÕES
Compilador COMANDOS
COMPILADAS
de pesquisa DML
(CUSTOMIZADAS)
E Catálogo do A
Compilador
sistema /
DDL dicionário de B Compilador
dados DML
Processador de
C banco de dados
em tempo execução
execução de execução
(runtime)
Gerenciamento D Controle de concorrência / backup /

dos dados subsistema de recuperação
armazenados
BANCO DE DADOS
ARMAZENADO
Fonte: Navathe; Elmasri, 2006, p. 26.
Sistema de gerência de banco de dados 35

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).
Figura 2
Grupos de comandos do SQL
Data Manipulation Language Data Definition Language

(DML) (DDL)
Select, Insert, Delete, Update etc. Alter, Create, Drop etc.
Data Control Language Transactional Control

(DCL) Language (TCL)
Grant, Revoke, Deny Commit, Rollback
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
36 Banco de Dados I
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.
Definir arquiteturas e alternativas de uso do SGBD em diferentes

Projetistas e arquitetos de soluções
projetos.
Acessar os dados por meio de ferramentas interativas nas quais cada

Usuários eventuais
acesso requer diferentes dados.
Acessar os dados por meio de interfaces pré-definidas (normal-

Usuários parametrizáveis mente telas de sistemas) nas quais cada acesso segue um padrão
pré-programado.
Definir quais dados devem ser acessados e quais as transformações

Analistas de sistemas
que eles deverão sofrer (especificação).
Definir como os dados serão acessados e como eles serão transfor-

Programadores
mados (codificação).
Fornecedores de ferramentas Criar softwares complementares às funções básicas do SGBD.
Executar atividades operacionais para garantir a disponibilidade e a

Equipe de suporte e operação
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.

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
Glossário
armazenados em outro.
COBOL: sigla para “COmmon
Business Oriented Language”,
Um programa COBOL, por exemplo, que desejasse acessar um ar-
em português, “linguagem quivo com dados de “Pessoa” tinha que repetir, em sua estrutura de
comum orientada para os código, a definição dos dados conforme mostra a Figura 4 a seguir.
negócios”.
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)
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-
38 Banco de Dados I
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.

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 1 Tabela 2
Segmentação horizontal e vertical de uma tabela View com segmentação vertical (colunas
Tabela original Nome + Sexo)
Cód. Data de
Nome pessoa Sexo Raça Nome pessoa Sexo
Pessoa nascimento
000015 JOAO DA SILVA 25/03/1962 Masculino Branco JOAO DA SILVA Masculino
000017 MARIA DA SILVA 11/07/1964 Feminino Branco MARIA DA SILVA Feminino
000018 PEDRO DA SILVA 09/11/1992 Masculino Negro PEDRO DA SILVA Masculino
000019 JOSE DA SILVA 11/11/1997 Masculino Branco JOSE DA SILVA Masculino
Fonte: Elaborada pelo autor. 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
•• 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-
40 Banco de Dados I
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-

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 minimizar desvantagens. 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.
42 Banco de Dados I
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,
Livro
é representado por um esquema interno que des-
O livro Projeto, Desenvol-
creve toda a estrutura de armazenamento e manipu- vimento de Aplicações e
lação física dos dados, ou seja, em um nível próximo Administração de Banco de
Dados, de Michael V. Man-
do hardware. Sem esse nível, gerenciado pelo SGBD, nino, apresenta a base
teríamos que transferir essa complexa tarefa para o para entender a tecnolo-
gia de banco de dados, as
programador, aumentando em muito a dificuldade tecnologias elementares
para interação dos sistemas de informação com os de cada ambiente de
processamento e discute,
dados que eles viessem a utilizar. ainda, o relacionamento
de cada tecnologia com
O segundo nível, chamado de nível conceitual, os avanços do comércio
está associado ao esquema conceitual e descreve eletrônico e da computa-
ção corporativa.
de modo integral a estrutura do banco de dados –
MANNINO, M. V. Porto Alegre:
descrição das entidades, relacionamentos, tipos de AMGH, 2008.
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

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
44 Banco de Dados I
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
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.

Figura 7
Criação de uma tabela no esquema EX
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.
46 Banco de Dados I
2.4 Tipos de SGBD
Após termos definido que iremos usar um SGBD para dar suporte
Vídeo
aos dados de nossas aplicações, chega o momento
da definição de qual será o SGBD escolhido. Muitas Vídeo
características podem influenciar essa escolha: a O vídeo Banco de Dados – Sexta
oferta de SGBDs no mercado é ampla, há diversos Aula – SGBD – Sistemas Geren-
ciadores de Banco de Dados, pu-
fornecedores e um mesmo fabricante pode oferecer blicado pelo canal Wopenheimer,
diversos modelos de SGBD. Em resumo, não basta apresenta um resumo de todas
escolher o fornecedor, é necessário atentar ao mo- as características de um SGBD
e pode ser bastante útil como
delo oferecido e verificar o que mais se adéqua a elemento de fixação dos conceitos
nossa necessidade. Na Figura 8, a seguir, podemos apresentados neste capítulo.
ver que o fornecedor Microsoft tem várias edições Disponível em: https://youtu.be/
Fw5Ulwo6NvQ.
para o SGBD SQL-Server 2017 (modelos), cada um
Acesso em: 27 fev. 2020.
aplicável a um perfil de projeto.
Figura 8
Edições disponíveis no SQL-Server 2017
Enterprise Standard Express Developer
Acesse recursos de Encontre recursos de Crie pequenos aplicativos Crie, teste e demonstre
missão crítica para programação avançados, web e móveis, controlados aplicativos em um
alcançar escala, inovações de segurança por dados de até 10 GB, ambiente que não seja de
segurança, alta e performance rápida com esse banco de dados produção com esta edição
disponibilidade e para aplicativos de nível de nível básico. Disponível completa do SQL Server
performance líder intermediário e data gratuitamente. 2017.
incomparáveis para seus marts. Faça upgrade
workloads de nível 1 facilmente para a
de Advanced Analytics, Enterprise Edition sem
business intelligence e precisar alterar nenhum
bancos de dados. código.
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.

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
Glossário SGBD. Por custo de propriedade entende-se o quanto gastamos para
As a service: do inglês, adquirir (mesmo que no modelo as a service ou locação), implantar
software como serviço. Trata-se e manter o SGBD em operação. Mesmo que o hardware ou software
de uma forma de distribuição e
comercialização de softwares. 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).
Artigo
https://becode.com.br/principais-sgbds/
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.
48 Banco de Dados I
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.
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.

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
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
50 Banco de Dados I
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.
Modelagem de dados 51
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
52 Banco de Dados I
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.
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
54 Banco de Dados I
usados para descrever o mesmo conteúdo que talvez em uma única
página de representação gráfica poderia ser igualmente descrito.
Artigo
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-
relacionamento-der/14332
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.
3.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,
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-
56 Banco de Dados I
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
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ão sendo 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-
58 Banco de Dados I
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
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
60 Banco de Dados I
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-
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ção e manutenção de

um modelo de dados
Vídeo O processo de criação de um modelo de dados foi definido original-
1
mente por Chen 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-
1
finia há mais de 40 anos era muito robusta e consistente. Chen (1990)
Peter Pin-Shan Chen é um cien-
propunha, já naquela época, que o processo de mapeamento dos da-
tista nascido em Taiwan, profes-
sor de ciência da computação dos que dariam origem a um banco de dados fosse baseado em uma
na Louisiana State University; é visão estruturada do mundo real que o modelo representaria.
conhecido como criador do mo-
delo entidade-relacionamento. 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

2 também era muito simples. Ele dizia que todos os elementos de um
O processo de abstração é uma mundo real observado poderiam ser mapeados por somente dois
operação intelectual em que um
objeto de reflexão é isolado de
conceitos: as entidades (ou coisas) e os relacionamentos (associações
fatores que comumente estão entre coisas), conforme podemos observar na Figura 1. Sua proposta
relacionados a ele na realidade. 2
consistia em aplicar um processo de abstração para extrair do mundo
real as entidades e os relacionamentos que o compunham.
62 Banco de Dados I
Figura 1
Elementos utilizados para a modelagem de dados
Entidade
Mundo real
Abstração
observado
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
1 N
PROPRIETARIO possui VEICULO
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:
•• 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,
64 Banco de Dados I
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).
Quadro 1
Elementos indicativos de entidades
Elementos Descrição Exemplos
Coisas que conseguimos ver, pegar, manusear,

Objetos Pessoa, veículo, árvore, caneta,
medir ou pesar, pois existem concretamente no
concretos átomo etc.
mundo real. Podem ser seres vivos ou inanimados.
Coisas que conseguimos ver, presenciar, partici-

Casamento, acidente de trânsi-
Fatos par, conhecer ou documentar, pois aconteceram,
to, fusão de átomos etc.
acontecem ou acontecerão.
Médico (pessoa com função

Papéis exercidos por pessoas, veículos, animais ou
de prestar serviços de saúde),
Funções coisas concretas. Podem ser seres vivos ou inani-
trator (veículo com função de
mados, porém com qualificação de função.
prestar serviços rurais) etc.
Operações em que duas ou mais entidades

participam. Podem ser originadas por entidades
Compra (uma pessoa adquire
das demais categorias aqui descritas, em qualquer
um carro), venda (uma empresa
combinação entre elas. Muitas vezes, podem ser
Interações vende um produto), troca (um
confundidas com um fato (o que não significa um
produto é trocado por outro)
erro de abstração, pois continuaria a ser uma enti-
etc.
dade). Poderia ser, eventualmente, substituído por
um relacionamento (que veremos a seguir).
Tipo de funcionário (estagiário,

contratado, terceirizado); guar-
Representam os modelos ou tipos de coisas, não
daria dados como: se recebe ou
Especificações propriamente as coisas. Além disso, guardam da-
não 13º salário, se tem férias ou
dos sobre os tipos de coisas, não sobre as coisas.
não, quantas horas por semana
deve trabalhar etc.
Fonte: Cougo, 1997.
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-
66 Banco de Dados I
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- 3
rísticas agregadas ao modelo entidade-relacionamento com evolução Esse conceito foi muito
de sua abordagem. Ao perceber que temos subgrupos dentro de um explorado quando a modelagem
grupo maior, passamos a identificar em nosso modelo um novo tipo de orientada a objetos e a análise
orientada a objetos surgiram nos
representação para essas entidades. Podemos dizer que temos uma anos 90; foi incorporado como
3
“especialização” ou “generalização” da entidade. uma extensão do modelo enti-
dade-relacionamento original, a
A Figura 3 demonstra um exemplo de modelo entidade-relaciona- fim de aperfeiçoar a semântica
mento com a extensão da semântica de generalização-especialização. que ela busca representar.
Nela, a entidade “médico” e a entidade “paciente” são especializações
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
M N
MEDICO executa
PESSOA CIRURGIA
1
N
PACIENTE participa
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.
68 Banco de Dados I
Figura 4
Exemplo de um relacionamento de cardinalidade 1:1
1 N
VAGA é ocupada FUNCIONARIO
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
1 N
DEPARTAMENTO tem alocado FUNCIONARIO
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 cada elemento 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.
Figura 6
Exemplo de um relacionamento de grau M:N
M N
FUNCIONARIO executa TAREFA
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
1 N N 1
FUNCIONARIO participa ALOCACAO e de uma TAREFA
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
70 Banco de Dados I
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.
FUNCIONARIO gerencia
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.
3.4 Tipos de modelos de dados
O modelo de dados proposto por Chen (1990) na abordagem en-
Vídeo
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
Vídeo como sendo o mais utilizado, observaremos as regras de conversão do
Acesse o vídeo Bancos de modelo conceitual para o modelo relacional.
Dados - Aula 02 – Modelo
Entidade-Relacionamento
Futuramente, esse modelo lógico (relacional) será transformado
(MER) - Parte I, do canal também em um modelo físico, com a definição de características físi-
UNIVESP. Nele, é apre-
sentada uma aula sobre o
cas, como tamanho para alocação de espaço em disco, estruturas de
processo de modelagem índices etc.
conceitual e de modela-
gem lógica, por meio de O objetivo de conversão é transformar, portanto, um modelo ge-
uma abordagem bastante
nérico e com mais semântica em um modelo específico de uma tecno-
objetiva e abrangente do
assunto. logia; nesse caso, a tecnologia relacional. Para cumprir essa tarefa de
Disponível em: https://www.you- conversão, deveremos respeitar os requisitos da tecnologia relacional.
tube.com/watch?v=oPlXecD-gZM.
Acesso em: 31 mar. 2020. A primeira regra de conversão determina que cada entidade do mo-
delo conceitual deve ser transformada em uma tabela, ou seja, tere-
4
4 mos tantas tabelas quanto o número de entidades do modelo.
Não abordaremos aqui as regras Já a segunda regra de conversão determina que cada atributo (cam-
de conversão de estruturas de
po) associado a uma entidade deverá ser transformado em uma coluna
especialização e generalização,
pois são estruturas mais avança- na tabela, em que ele aparece localizado no modelo conceitual. Segun-
das de modelagem. 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.
72 Banco de Dados I
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
1 1
CARRO pertence a PESSOA
Num_chassis (Ident. Único) CPF (Ident. Único)

Qtde. de portas Nome
Potência Data nascimento
Cor Sexo
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)
Vídeo
O vídeo Construindo um
De modo similar, a quarta regra de conversão se aplica ao relacio- modelo de Banco de dados
lógico utilizando BRMode-
namento 1:N. Essa regra define que, existindo um relacionamento de
lo, do canal Infordiversao,
grau 1:N entre a entidade A e B, sendo A a entidade de grau 1 e B a en- apresenta o processo de
criação de um modelo de
tidade de grau N, deverá ser criada, na entidade B, uma coluna que seja
dados utilizando uma fer-
cópia da coluna chave da entidade A (chave estrangeira de A). Nesse ramenta de modelagem
gráfica, com recursos de
caso, a inversão de papéis entre A e B não se aplica. Sempre a chave da
especialização-generali-
entidade A deverá ser importada para a entidade B, nunca o contrário. zação, relacionamentos,
entidades e atributos.
Por fim, a quinta e última regra determina que, havendo uma re-
Disponível em: https://www.you-
lação de grau de M:N entre as entidades A e B (já transformadas em tube.com/watch?v=sItFiqAN5YY.
tabelas A e B), deve-se criar uma tabela C, que receberá as colunas cha- Acesso em: 31 mar. 2020.
ves da entidade A e da entidade B, sendo essas duas colunas (chave

estrangeira de A e chave estrangeira de B) a nova chave da tabela C.
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.
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?
74 Banco de Dados I
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.
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.
76 Banco de Dados I
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-

Vídeo
mático russo Georg Cantor (1845-1918), nos anos
No vídeo Teoria dos
1870. Ele publicou materiais que tratavam do estudo
conjuntos, publicado pelo
das propriedades dos conjuntos, das suas relações, canal Matemática em
Exercícios, você terá a
das relações entre seus elementos e do próprio
oportunidade de rever
conjunto. Em uma definição simples, mas formal, conceitos básicos sobre
conjuntos e opera-
podemos definir conjunto como o agrupamento de
ções que podem ser
elementos que possuem características semelhan- realizadas. Você poderá
identificar como a teoria
tes, ou uma coleção de objetos.
relacional se aproveita
Se você parar para observar essa definição, verá desses conceitos para
estabelecer seu modo
que ela cita alguns elementos importantes, os quais de funcionamento.
já vimos quando definimos o que era entidade no Disponível em: https://www.
processo de modelagem entidade-relacionamento. youtube.com/watch?v=Z92-qwA-
ZJgY. Acesso em: 22 abr. 2020.
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
Modelo relacional e normalização 77

Modelo relacional de dados para grandes bancos de dados compartilha-
1 1
dos , no qual apresentou uma proposta para que o armazenamento
Em inglês, Relational model of
data for large shared data banks. 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ão havia 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.
78 Banco de Dados I
Quadro 1
Conceitos da teoria dos conjuntos usados no modelo relacional
Conceito Definição Elemento do modelo relacional
Agrupamento de elementos com

Conjunto • Tabela
características semelhantes.
Associação, vínculo ou correspondência • Relacionamento

Relação
entre elementos de diferentes conjuntos. • Chave estrangeira
Elementos Itens que compõem um conjunto • Linha
• Coluna
• Chave primária
Características Propriedades comuns que cada elemento
• Chave secundária
dos elementos possui com os demais do seu conjunto.
• Chave candidata
• Índice
União, intersecção, diferença ou produto

Operação cartesiano de elementos de diferentes con- • Operação
juntos com base em critérios associativos.
• Integridade de identidade
Garantia de que valores ou referências
Integridade • Integridade referencial
entre elementos sejam sempre válidos.
• Integridade de domínio
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

Vídeo conjunto dos funcionários e o conjunto das cidades. Dessa forma, tere-
No vídeo Mapeamen- mos que gerar uma associação entre eles, a qual respeitará a cardina-
to MER para modelo
lidade (quantidade de elementos) do relacionamento. Nesse exemplo,
relacional, publicado pelo
canal Geraldo Corrêa, temos um relacionamento de grau 1:N (um para muitos) entre cidade e
você poderá rever em
funcionário, no qual uma cidade pode ter vários funcionários nascidos
detalhes vários exemplos
de modelos E-R sendo nela, mas um funcionário só pode ter nascido em uma única cidade.
convertidos para os
seus devidos modelos Na figura a seguir, podemos ver modelo E-R e sua representação do
relacionais por meio da ponto de vista de conjuntos.
aplicação de regras de
derivação.
Disponível em: https://www.you-

tube.com/watch?v=LqmJOAwTc0U. Figura 1
Acesso em: 22 abr. 2020. 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
TABELA CIDADE
CIDADE CWB RJ SP
Cód. Nome Pop.
01 CWB 3 m.
1 02 RJ 5 m.
03 SP 10 m.
nascem
TABELA FUNCIONARIO
Jose Joao Maria Cód. Nome Sexo Cidade

N
15 Jose M 01
23 Joao M 02
37 Maria F 02
FUNCIONARIO
O terceiro conceito são os elementos que compõem o conjunto

Glossário e que se transformam, no modelo relacional, em tuplas ou linhas
Tupla: cada linha formada por da tabela. Se observarmos o conjunto dos FUNCIONARIOS, ele será,
uma lista ordenada de colunas
no exemplo anterior, formado por três elementos, e o conjunto das
representa um registro ou tupla.
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.
80 Banco de Dados I
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).

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.
82 Banco de Dados I
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-

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.
Figura 2
Junção de duas tabelas no modelo relacional
TABELA CIDADE TABELA FUNCIONARIO
Cód. Nome Pop. Cód. Nome Sexo Cidade

01 CWB 3 m. 15 Jose M 01
02 RJ 5 m. 23 Joao M 02
03 SP 10 m. 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.
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.
84 Banco de Dados I
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

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, poderia parecer 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
Glossário algum processo. Isso não exclui a possibilidade de geração de tabelas
perenes com produtos cartesianos em situações particulares.
Perene: que permanece
durante longo tempo. 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.
86 Banco de Dados I
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.

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.
Figura 3
Implementação da integridade referencial no modelo relacional
TABELA 2 – FUNCIONARIO
TABELA 1 – CIDADE
Chave Nome Sexo Chave Estrangeira
Chave Nome Pop.
15 Jose M 01 (com integridade)
01 CWB 3 m.
23 Joao M 02 (com integridade)
02 RJ 5 m.
37 Maria F 02 (com integridade)
03 SP 10 m.
43 Carlos M 05 (sem integridade)
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.
88 Banco de Dados I
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 dados
sobre 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.

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).
90 Banco de Dados I
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.

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
92 Banco de Dados I
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ção se deu.
Com base nessas informações, observe a figura a seguir.
Figura 4
Modelo E-R com um relacionamento 1:N tendo atributos
1 N
PESSOA E dona de AUTOMOVEL
CPF Data aquisicao Placa do Carro

Nome pessoa Valor aquisicao Cor
Data nascimento Marca
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-

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
M N
ALUNO faz matricula CURSO
CPF Data da matricula Codigo do curso

Nome pessoa Valor da matricula Nome do curso
Data nascimento Carga horaria
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
94 Banco de Dados I
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.
Artigo
https://medium.com/@diegobmachado/
normaliza%C3%A7%C3%A3o-em-banco-de-dados-5647cdf84a12
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.
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

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-
96 Banco de Dados I
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 eles
sã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-

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.
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.
98 Banco de Dados I
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.
NAVATHE, S. B.; ELMASRI, R. Sistemas de bancos de dados. São Paulo: Pearson Education, 2005.

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-
100 Banco de Dados I

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ários que 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?”.
Projeto de banco de dados 101

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.

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
Site
que seja um simples repositório de dados. Afinal, um BD apropriado
Mapa de acesso lógico
é aquele que consegue combinar a coerência e integridade lógica de (MAL)
seus dados com os mecanismos e facilidades de acesso, e, finalmente, Nesse material, você po-
derá rever, em detalhes,
com a performance esperada. o processo de criação do
projeto físico, conhe-
Em resumo, nesta etapa, vamos executar o projeto físico para de- cendo uma ferramenta
finir as tabelas e as visões que o banco de dados terá. Vamos definir chamada MAL (mapa
de acesso lógico), a qual
as regras de restrição de integridade e os mecanismos de acesso por permite mapear as tran-
meio de índices, além de calcular e alocar espaços físicos para arma- sações de negócio.
zenamento de dados e índices. Ademais, vamos projetar a distribui- Disponível em: https://www.
devmedia.com.br/projeto-fisico-
ção desses dados considerando aspectos como velocidade de acesso, -de-banco-de-muito-alem-do-
largura de banda de conexão de rede e tipos de dados que trafegarão -create-table/3581.
Acesso em: 6 maio 2020.
(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.
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.

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-

Vídeo
jeto de banco de dados mal elaborado é o suporte em relação ao au-
No vídeo Como otimizar
um banco MySQL usando mento do número de transações simultâneas que serão executadas
índices, publicado pelo com os dados desse BD. Isso significa que não apenas o crescimento
canal Gustavo Gallas,
você poderá ver, na prá- da quantidade de registros existentes em um banco de dados pode
tica, como a criação de passar a gerar aumento no tempo de execução de comandos de inser-
um índice em uma tabela
pode trazer uma grande ção ou de recuperação de dados. Significa também que, mesmo que o
redução dos recursos BD preserve seu tamanho, ao aumentarmos a quantidade de acessos
dispendidos pelo banco
de dados para recuperar feitos sobre este mesmo volume de dados, teremos aumento no tem-
um dado. po de resposta a cada um dos comandos submetidos para execução
Disponível em: https:// pelo SGBD. Inserir ou recuperar um registro pode se tornar uma tarefa
www.youtube.com/
watch?v=zOPzmjQSBYQ. Acesso cada vez mais demorada, simplesmente porque mais comandos estão
em: 6 maio 2020. sendo executados na mesma unidade de tempo, por exemplo, em um
segundo.

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

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

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
Estrutura normalizada Estrutura desnormalizada
VENDA VENDA
TIPO PAGAMENTO
Data Tipo Valor Data Tipo Valor
Cód. Nome
01/01 1 10,00 01/01 à vista 10,00
1 à vista
02/01 1 15,00 02/01 à vista 15,00
2 parcelado
03/01 2 12,00 03/01 parcelado 12,00
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.

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? Prever um
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-

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,

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.
Artigo
https://www.devmedia.com.br/entendendo-e-usando-indices/6567
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.
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-

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

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-

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.

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
Em relação a um processo contínuo e cíclico, que é a criação de um
Vídeo
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 chaves
alternativas 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.

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.

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

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

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-

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

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

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 para se 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

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

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.

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 de cada 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.
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-

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.
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

6
Linguagem estruturada
para consultas
Todas as etapas de construção de um banco de dados s omam-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.

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
Vídeo
– não só para laboratório –, baseado no modelo rela-
No vídeo Análise de desem-
cional. Esse projeto se chamava System R, uma refe-
penho de consultas SQL em
rência ao sistema relacional proposto por Codd. bancos de dados Oracle,
publicado pelo canal
Acredita-se que a IBM planejava lançar o seu Leonardo Mairene Muniz,
você poderá ver como é
SGBD relacional com base na linguagem SQL como
realizada a monitoração
o primeiro do mercado. Porém, não foi o que acon- da execução de comandos
SQL e como podem ser
teceu. Outros concorrentes também trabalhavam
executados ajustes que
em paralelo nesse mercado buscando oferecer otimizem a estrutura de
sistemas gerenciadores de banco de dados relacio- acesso aos dados.
nais. Isso fez com que, no ano de 1979, a Oracle – Disponível em: https://youtu.be/
I604SeSK_d8. Acesso em: 27 maio
2020.
Linguagem estruturada para consultas 127

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.

Figura 1
Exemplo da execução de um comando SQL
BOX 2
BOX 1
BOX 3
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.
Figura 2
Comandos SQL divididos por grupos de comandos
DDL: Data Definition Language
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
(Continua)

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,
tabela
CALL Chamar um subprograma PL/SQL
EXPLAIN PLAN Explicar o caminho de acesso aos dados
LOCK TABLE Controle de concorrência
DCL: Data Control Language (DCL)
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
TCL: Transaction Control Language
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
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

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
Glossário
praticamente de uma linguagem fluente que, ao utilizar da língua in-
glesa como base, oferece muita facilidade para ser lida e interpretada. Mnemônico: conjunto de
técnicas utilizadas para auxiliar o
Isso implica não termos mnemônicos e abreviaturas que dificultam o processo de memorizaçã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

Linguagem fluente
FUNCIONARIO onde as siglas dos estados são iguais a “PR”
SELECT Nome, Cidade, SiglaEstado FROM FUNCIONARIO

SQL
WHERE SiglaEstado = “PR”

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 com uma 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

SQL simples
WHERE SiglaEstado = “PR”
SELECT Nome, Cidade, SiglaEstado, NomeEstado FROM

SQL complexo FUNCIONARIO, ESTADO
WHERE Funcionario.SiglaEstado = “PR”
AND FUNCIONARIO.SiglaEstado = ESTADO.SiglaEstado
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

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.

Saiba mais Apresentamos, a seguir, somente para fins de ilustração dos recursos
Sintaxe dos comandos que cada um deles oferece, a sintaxe de formação de alguns dos coman-
SQL do banco de dados dos SQL mais comumente usados. Sugerimos que, caso precise aprender
PostgreSQLe Oracle
sobre a sintaxe de todos os comandos do SGBD escolhidos para imple-
Neste material, você po-
mentar seu projeto, você procure a documentação oferecida pelo forne-
derá conhecer a sintaxe
SQL implementada pelos cedor do SGBD. Apesar de o SQL ser uma linguagem padrão, pequenas
SGBDs PostgreSQL e
diferenças de sintaxe podem existir entre um e outro fornecedor.
Oracle, além de verificar
algumas de suas particu-
laridades, embora esses
sistemas se pareçam
bastante com os diversos
6.3.1. Comando CREATE <objeto>
SGDBs disponíveis no Nesse comando, o objeto pode ser um dos elementos dispostos a
mercado.
seguir. Cada um deles terá uma sintaxe complementar específica.
Disponíveis em: http://pgdocptbr.
sourceforge.net/pg82/sql- • CREATE CLUSTER • CREATE PACKAGE BODY
commands.html; https://docs.
oracle.com/cd/B28359_01/ • CREATE CONTEXT • CREATE PFILE
server.111/b28286/toc.htm. Acesso
em: 27 maio 2020. • CREATE CONTROLFILE • CREATE PROCEDURE
• CREATE DATABASE • CREATE PROFILE
• CREATE DATABASE LINK • CREATE RESTORE POINT
• CREATE DIMENSION • CREATE ROLE
• CREATE DIRECTORY • CREATE ROLLBACK SEGMENT
• CREATE DISKGROUP • CREATE SCHEMA
• CREATE FLASHBACK ARCHIVE • CREATE SEQUENCE
• CREATE FUNCTION • CREATE SPFILE
• CREATE INDEX • CREATE SYNONYM
• CREATE INDEXTYPE • CREATE TABLE
• CREATE JAVA • CREATE TABLESPACE
• CREATE LIBRARY • CREATE TRIGGER
• CREATE MATERIALIZED VIEW • CREATE TYPE
• CREATE MATERIALIZED VIEW LOG • CREATE TYPE BODY
• CREATE OPERATOR • CREATE USER
• CREATE OUTLINE • CREATE VIEW
• CREATE PACKAGE
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.

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.

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 MATERIALIZED VIEW • ALTER SEQUENCE

• ALTER DATABASE LOG • ALTER SESSION
• ALTER DIMENSION • ALTER OPERATOR • ALTER SYSTEM
• ALTER DISKGROUP • ALTER OUTLINE • ALTER TABLE
• ALTER FLASHBACK ARCHIVE • ALTER PACKAGE • ALTER TABLESPACE
• ALTER FUNCTION • ALTER PROCEDURE • ALTER TRIGGER
• ALTER INDEX • ALTER PROFILE • ALTER TYPE
• ALTER INDEXTYPE • ALTER RESOURCE COST • ALTER USER
• ALTER JAVA • ALTER ROLE • ALTER VIEW
• ALTER MATERIALIZED VIEW • ALTER ROLLBACK SEGMENT

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.
supanut piyakanont/Shutterstock
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 critério de aceitar/não aceitar valores nulos em

uma coluna.
Mudar o valor default de uma coluna.
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.

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;
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);
Para mudar o nome de uma coluna existente:

ALTER TABLE distribuidores RENAME COLUMN
endereco TO cidade;
Para mudar o nome de uma tabela existente:

ALTER TABLE distribuidores RENAME TO
fornecedores;
Para adicionar uma restrição de não nulo a uma coluna:

ALTER TABLE distribuidores ALTER COLUMN
logradouro SET NOT NULL;
Para remover a restrição de não nulo da coluna:

ALTER TABLE distribuidores ALTER COLUMN
logradouro DROP NOT NULL;
Para adicionar uma restrição de verificação à tabela:

ADD CONSTRAINT chk_cep
CHECK (char_length(cod_cep) = 8);

Para remover uma restrição de verificação de uma tabela e de todas as suas
descendentes:
ALTER TABLE distribuidores DROP
CONSTRAINT chk_cep;
Para adicionar uma restrição de chave estrangeira a uma tabela:

ADD CONSTRAINT fk_dist_end
FOREIGN KEY (endereco)
REFERENCES enderecos (endereco)
MATCH FULL;
Para adicionar uma restrição de unicidade (multicoluna) à tabela:

ADD CONSTRAINT unq_id_dist_cod_cep
UNIQUE (id_dist, cod_cep);
Para mover a tabela para outro espaço de tabelas:
ALTER TABLE distribuidores SET TABLESPACE

espaco_de_tabelas_rapido;
Para mover a tabela para outro esquema:
ALTER TABLE meu_esquema.distribuidores

SET SCHEMA seu_esquema;
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.

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.

•• 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
ORDER BY Name ASC;
Restrições de registros que serão recuperados do banco de dados 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
WHERE ProductLine = ‘R’
AND DaysToManufacture < 4
ORDER BY Name ASC;

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;
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.

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.

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 [, ...]
GRANT OPTION ]
GRANT { { CREATE | CONNECT | TEMPORARY | TEMP } [,...] | ALL [

PRIVILEGES ] }
ON DATABASE nome_do_banco_de_dados [, ...]
GRANT OPTION ]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }

ON FUNCTION nome_da_função ( [ [ modo_do_argumento ] [
nome_do_argumento ] tipo_do_argumento [, ...] ] ) [, ...]
GRANT OPTION ]
GRANT { USAGE | ALL [ PRIVILEGES ] }

ON LANGUAGE nome_da_linguagem [, ...]
GRANT OPTION ]
GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }

ON SCHEMA nome_do_esquema [, ...]
GRANT OPTION ]
GRANT { CREATE | ALL [ PRIVILEGES ] }

ON TABLESPACE nome_do_espaço_de_tabelas [, ...]
GRANT OPTION ]
GRANT role [, ...] TO nome_do_usuário [, ...] [ WITH ADMIN OPTION ]
Fonte: PostgreSQL, 2020d.

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.
Artigo
https://kb.elipse.com.br/linguagem-sql-capitulo-6-comandos-sql/
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.

6.4 Tipos de SQL
Vídeo Entre os exemplos de sintaxes apresentadas, utilizamos diversas 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
Saiba mais dados, isolando, dessa maneira, o código do programa da camada SQL
Você pode conhecer um de um ou de outro fabricante. Um exemplo desse tipo de recurso é o
pouco mais sobre a plataforma Hibernate, plataforma em que se escrevem comandos para acesso a
Hibernate acessando o site: dados usando uma linguagem parecida com a SQL, mas que, na ver-
https://hibernate.org/. Acesso
em: 28 maio 2020. 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.

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 ?

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

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 todo o 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.
Gabarito 149
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

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.
Gabarito 151
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

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.
Gabarito 153
BANCO DE DADOS I
Paulo Sérgio Cougo
Código Logístico Fundação Biblioteca Nacional

ISBN 978-85-387-6621-6
59337 9 788538 766216

Banco de Dados I

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Banco de Dados I

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS I

O desenvolvimento de novos sistemas de informação corpo-

A evolução das tecnologias de armazenamento, mani-

Durante o estudo desta obra, o leitor participará de uma jor-

Paulo Sérgio Cougo

Código Logístico Fundação Biblioteca Nacional

59337 9 788538 766216

Paulo Sérgio Cougo

CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO

Cougo, Paulo Sérgio

1. Banco de dados - Desenvolvimento. 2. Projeto de banco de dados.

Todos os direitos reservados.

IESDE BRASIL S/A.

Acesse os vídeos automaticamente, direcionando

Em alguns dispositivos é necessário ter instalado

2 Sistema de gerência de banco de dados 34

4 Modelo relacional e normalização 76

5 Projeto de banco de dados 100

6 Linguagem estruturada para consultas 126

1.1 O que é e para que serve um banco de dados?

O termo banco de dados tem sido amplamente usado para designar

Introdução a banco de dados 9

Dados são elementos gerados pelo registro de fatos ou de características

Se observarmos uma pessoa (objeto), podemos identificar dados como:

Já se observarmos um casamento – fato que envolve duas pessoas

Com base nessas informações, temos o ponto de partida para criar

Processo de manipulação Informações produzidas

Fonte: Elaborada pelo autor.

Se ao transformar um dado pode-se gerar uma informação, isso signi-

Como já citado, podemos gerar os seguintes dados para uma pessoa:

Data de nascimento Transformação ou Idade

Pessoa viva ou morta?

Altura Pessoa alta ou baixa

Fonte: Elaborada pelo autor.

Introdução a banco de dados 11

Desse modo, seria razoável guardar a informação “idade” no banco

Há também outras situações menos aparentes, que levam as pes-

A preocupação com a identificação do que realmente é um dado e

1.1.3 Arquivos e bancos de dados

Historicamente, quando surgiram os primeiros sistemas de infor-

Por esse motivo, os sistemas construídos agrupavam os dados (e

No exemplo mencionado, se guardássemos a data de nascimento,

Com o crescimento de recursos de hardware e sua equivalente redu-

Por outro lado, a proliferação de arquivos criados especificamente

Ao surgirem as primeiras alternativas baseadas em estruturas de Livro

Ao tratarmos de banco de dados, três características são sempre

Introdução a banco de dados 13

Fonte: Elaborada pelo autor.

A segunda característica – dados coerentes – diz respeito ao fato

Para entendermos essas questão, voltemos ao exemplo no qual

Ao observar os dados já mapeados, podemos perceber que existe

Fonte: Elaborada pelo autor.

Ao realizarmos essa ação, aparentemente teríamos um melhor ma-

Introdução a banco de dados 15

Se tivermos um nome de noivo ou de noiva que não apareça tam-

Essas situações nos fazem pensar em regras de coerência – ou re-

Essas regras serão importantes para estabelecer os relacionamen-

E a terceira característica é o fato de os dados atenderem a uma

Em nosso exemplo, estamos criando um banco de dados de casa-

As respostas para todas essas perguntas podem mudar o modo

1.1.4 Banco de dados e sistema gerenciador de

Esse software – que permite que os sistemas de informação intera-

Existem vários fabricantes de SGBD no mercado, cada um com ca-

Com base nos padrões internacionais estabelecidos pela ANSI (Ame-