banco_de_dados ECID

Prévia do material em texto

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
O desenvolvimento de novos sistemas de informação 
corporativos, para uso pessoal e até de aplicativos para 
celulares (apps) tem exigido – com grande frequência e dos 
programadores – o conhecimento de técnicas de criação e 
manipulação dos bancos de dados. Qualquer sistema, por mais 
simples que seja, em algum momento terá a necessidade de 
criar, manter e consultar determinado tipo de dado. 
A evolução das tecnologias de armazenamento, manipulação 
e consulta a fontes de dados criou um conjunto específico de 
conhecimentos dentro da área de informática, que se chama 
banco de dados (BD). Esse é o tema que abordaremos nesta 
obra, preparando você para poder compreender e se aprimorar 
nessa nova área de conhecimento.
No Capítulo 1, conheceremos a importância do uso de um 
BD como fonte de dados para sistemas, como um banco de 
dados é criado e quais são os benefícios que podemos obter de 
sua utilização. Você conhecerá um universo de informações que 
lhe permitirá prosseguir no estudo desse rico conteúdo.
No Capítulo 2, ao compreendermos o papel que um BD 
poderá ter para os sistemas de informação, será possível 
conhecermos os sistemas gerenciadores de bancos de dados 
(SGBDs), programas criados para gerenciar os bancos de dados. 
Existem diferentes abordagens de sistemas gerenciadores de 
bancos de dados, as quais incorporam diferentes recursos e 
restrições de uso. Os SGBDs podem exigir diferentes requisitos, 
e podem, ou não, atender às necessidades conforme o tipo de 
projeto a executar.
No Capítulo 3, iniciaremos o caminho rumo à construção 
de um banco de dados. O processo de criação de um BD 
não é intuitivo e livre; ele conta com uma metodologia ou um 
processo padronizado/estruturado para transportar requisitos 
de informação de acordo com as necessidades de um sistema. 
Nesse sentido, a criação de um modelo de dados conceitual é o 
alicerce de todo o processo de construção de um BD. O modelo 
APRESENTAÇÃOVídeo
de dados representa algo como o desenho da planta baixa de uma casa: ele 
não é a casa, mas a representa. Assim, o modelo de dados não é o banco de 
dados, mas o representa por intermédio de um diagrama.
Ao sabermos como construir um modelo de dados, estaremos preparados, 
no Capítulo 4, para converter esse diagrama inicial em um modelo lógico 
relacional, base do projeto do banco de dados. Conheceremos os requisitos 
do modelo relacional – as vantagens e desvantagens em utilizá-lo – e 
aprenderemos o método de conversão de um modelo de dados conceitual 
em um modelo de dados relacional. As regras de conversão são apresentadas 
para que os requisitos do modelo relacional possam ser atendidos e, 
finalmente, construir o banco de dados.
No Capítulo 5, ao termos um modelo de dados relacional definido, 
poderemos, enfim, projetar o BD, dando origem a um modelo físico, no qual 
todos os detalhes para a alocação física de uma estrutura de dados seja 
feita. Para tanto, é necessário conhecer mais alguns requisitos e conceitos 
que poderão proporcionar um desempenho adequado para o acesso aos 
dados. A aplicação desses elementos garante maior flexibilidade para o 
compartilhamento dos dados e atendimento aos requisitos de inserção, 
de atualização e de consulta aos dados, feitas por um ou mais sistemas 
de informação. Essa é a última etapa da construção de um BD; com base 
nesse ponto, é possível ter um banco de dados projetado e pronto para ser 
construído. 
No Capítulo 6, conheceremos a Structured Query Language (SQL), 
linguagem criada especificamente com a finalidade de prover meios de 
interação com o banco de dados. Ao ter em mãos o projeto físico finalizado, é 
possível construir o BD por meio de comandos SQL, os quais permitirão criar 
banco de dados, tabelas dentro do BD e colunas dentro destas, bem como 
armazenar, atualizar, excluir e consultar conteúdos. Além disso, conheceremos 
algumas sintaxes dessa rica linguagem de acesso a dados, como ela pode ser 
incorporada nos programas hospedeiros – em que lugar a SQL será agregada 
para permitir o acesso ao BD –, benefícios de seu uso, entre outros.
Com todo esse conteúdo, você participará de uma jornada que começa 
com os primeiros conceitos, passa por métodos de construção de modelos 
de dados – conceituais, lógicos ou físicos – e chega, por fim, à construção e 
manipulação dos dados dentro de um BD. 
Esperamos que você tenha uma gratificante experiência com a leitura 
desta obra. Bons estudos!
Introdução a banco de dados 9
1
Introdução a banco de dados
Neste capítulo, vamos conhecer alguns conceitos essencial-
mente importantes para a adoção de estruturas de bancos de 
dados como elementos de suporte providos para os sistemas de 
informação. Atualmente, a ideia de iniciar a criação de um sistema 
de informação ou de um app sem considerar a adoção de um ban-
co de dados como elemento de sustentação para os dados que 
serão manuseados por esse sistema é pouco aceita. O uso do ban-
co de dados é amplamente difundido e não é mais questionado.
Contudo, o fato de essa estratégia ser amplamente aceita não 
significa que é dispensável ter conhecimento dos fatores que levam 
a tal escolha. Talvez, em alguma situação particular, essa escolha 
possa ser reavaliada. Nesse sentido, é necessário ter conhecimen-
tos dos chamados critérios de avaliação.
Desse modo, vamos conhecer os principais conceitos e as fun-
ções envolvidas no processo de adoção dos bancos de dados. Esse 
será um importante ponto de partida para nossa jornada rumo à 
implantação desses mecanismos em nossos sistemas.
1.1 O que é e para que serve um banco de dados? 
Vídeo Quando tratamos de banco de dados, muitas vezes a primeira dúvi-
da que surge é se estamos falando de um software, de uma tecnologia, 
de um arquivo físico, de um conjunto de dados ou de um método de 
organização de dados.
O termo banco de dados tem sido amplamente usado para designar 
todos esses elementos citados. Ele, às vezes, é visto como um software, 
como uma tecnologia, como um arquivo físico, como um conjunto de da-
dos, ou, ainda, como um método de organização de dados. Entretanto, 
existem diferenças entre cada abordagem, as quais elencamos a seguir.
10 Banco de Dados I
1.1.1 Dados
Primeiramente, antes de definir o que são dados, pensemos: por que 
frequentemente é utilizado o termo informação em substituição ao termo 
dado? Você provavelmente já ouviu alguém dizer: “precisamos levantar as 
informações sobre essa pessoa” ao invés de “precisamos levantar os da-
dos sobre essa pessoa”.Seriam dados e informações a mesma coisa?
Dados são elementos gerados pelo registro de fatos ou de características 
de objetos/coisas. Eles permitem que possamos identificá-los, reconhecê-
-los, mapeá-los e representá-los. Os dados são inerentes aos elementos que 
representam, isto é, dados não são criados, mas sim capturados da obser-
vação desses objetos no mundo real. Quando olhamos para um objeto, o 
reconhecemos por suas características. Essas características podem ser ma-
peadas como dados de um objeto. Veja um exemplo a seguir.
Se observarmos uma pessoa (objeto), podemos identificar dados como:
Figura 1
Modelo de dados da entidade “Pessoa”
PESSOA
• nome
• data de nascimento
• altura
• peso
Fonte: Elaborada pelo autor.
Fonte: Elaborada pelo autor.
Já se observarmos um casamento – fato que envolve duas pessoas 
–, podemos também identificar dados relativos a esse evento (e não a 
pessoas).
Figura 2
Modelo de dados da entidade “Casamento”
CASAMENTO
• Data
• Horário
• Regime de comunhão de bens
• Tipo de decoração
Fonte: Elaborada pelo autor.
Com base nessas informações, temos o ponto de partida para criar 
um banco de dados. Para tanto, é necessário primeiramente identi-
ficar os objetos e fatos de interesse, e depois elencar os dados que 
pertencem a eles. Esse processo será visto detalhadamente quando 
abordarmos a modelagem de dados.
Introdução a banco de dados 11
1.1.2 Informação
Informações são elementos e conclusões geradas por meio da ma-
nipulação dos dados que dispomos. A informação é o dado trabalha-
do, isto é, o dado traduzido. A manipulação dos dados pode envolver, 
comparar, apresentar, separar e formatar dados; já a transformação 
pode envolver, somar, subtrair e contar dados. A figura a seguir sinte-
tiza esses processos:
Figura 3
Processo de transformação de dados em informações
Lista de dados mapeados
Processo de manipulação 
 ou transformação
Informações produzidas 
pela transformação
Fonte: Elaborada pelo autor.
Se ao transformar um dado pode-se gerar uma informação, isso signi-
fica que diferentes transformações de um mesmo dado podem gerar dife-
rentes e diversas informações. Nesse sentido, é importante ter o cuidado 
de guardar dados, não sendo necessário guardar informações, pois essas 
últimas não precisam ser guardadas, uma vez que podem ser geradas.
Como já citado, podemos gerar os seguintes dados para uma pessoa: 
nome, data de nascimento, altura e peso. Porém, quais informações po-
demos formar com esses dados? A figura a seguir ilustra essa questão:
Figura 4
Transformação de um dado em várias informações
Data de nascimento Transformação ou 
manipulação
Signo do zodíaco
Idade
Pessoa viva ou morta?
Transformação ou 
manipulação
Pessoa alta ou baixa 
(conforme a idade)
Índice de Massa Corporal
(risco de enfarte)
Altura
Peso
Data de nascimento
Fonte: Elaborada pelo autor.
12 Banco de Dados I
Observando a figura, não seria correto criar um campo no banco de 
dados para guardar a informação “idade” ou “signo” de uma pessoa? O 
correto seria simplesmente guardar o dado sobre a data de nascimen-
to e, por meio dele, gerar essas informações.
Desse modo, seria razoável guardar a informação “idade” no banco 
de dados? Quantos de nós já preenchemos uma ficha cadastral num 
hotel ou em uma loja em que nos foi perguntado: “qual a sua idade?” 
e “qual a sua data de nascimento?”. Geralmente, preenchemos os dois 
campos no formulário, e esses, muito provavelmente, serão digitados 
e guardados em algum banco de dados.
Há também outras situações menos aparentes, que levam as pes-
soas a criarem informações (e não dados) em um banco de dados. Es-
ses indivíduos pensam estar guardando dados, mas na verdade estão 
guardando informações. Portanto, sempre se pergunte: isto é um dado 
ou uma informação que poderia ser obtida por meio de outro dado?
A preocupação com a identificação do que realmente é um dado e 
do que são informações foi originada justamente quando os antigos 
arquivos usados para sustentar os sistemas de informação passaram a 
ser substituídos por bancos de dados.
1.1.3 Arquivos e bancos de dados
Qual a diferença entre a antiga abordagem de arquivos e a nova 
abordagem de bancos de dados?
Historicamente, quando surgiram os primeiros sistemas de infor-
mação, ainda na década de 1950, não existia muita preocupação com 
esse aspecto, pois o processamento de dados realizado era baseado 
em arquivos sequenciais, frequentemente armazenados em fitas mag-
néticas. O custo de unidades de disco era extremamente alto e suas 
capacidades de armazenamento eram extremamente baixas. A capaci-
dade de armazenamento de um simples aparelho de celular não estava 
sequer disponível nos discos magnéticos das maiores corporações, que 
tinham processamentos feitos em seus mainframes.
Por esse motivo, os sistemas construídos agrupavam os dados (e 
muitas vezes as informações) já prontos de modo bastante orientado 
para o resultado que deveriam produzir. Em resumo, um arquivo era 
construído para uma aplicação específica, evitando que fosse necessá-
mainframes: computadores de 
grande porte.
Glossário
Introdução a banco de dados 13
rio muito processamento ou muito trabalho para obtenção dos resul-
tados esperados.
No exemplo mencionado, se guardássemos a data de nascimento, 
poderíamos gerar automaticamente o signo da pessoa. Contudo, isso 
consumiria recursos, pois teríamos que executar, cada vez que essa 
informação fosse necessária, uma tabela de classificação de signos, es-
tabelecida de acordo com o dia e mês de nascimento. Essa ação geraria 
o consumo de processamento, de tempo e de memória, portanto de-
veria ser evitada.
Com o crescimento de recursos de hardware e sua equivalente redu-
ção de custos, bem como o surgimento de estruturas de armazenamento 
e processamento com melhor performance, a busca de um modelo de 
dados mais preciso (sem guardar informações) passou a ser viável.
Por outro lado, a proliferação de arquivos criados especificamente 
para atender à demanda de cada um dos sistemas de informação cria-
va outros problemas, embora resolvesse o das restrições de hardware. 
Essas dificuldades talvez tivessem impactos maiores, porém, não po-
diam ser evitadas, em virtude das limitações técnicas da época.
Ao surgirem as primeiras alternativas baseadas em estruturas de 
banco de dados, a adesão foi quase que imediata. As antigas estruturas 
de arquivos sequenciais passaram a ser substituídas por estruturas de 
banco de dados, trazendo inúmeros benefícios.
Criava-se, então, uma nova era: a era dos bancos de dados, isto é, 
a era dos sistemas de informação desenvolvidos com bases de dados 
e não mais com arquivos. Esses bancos ainda não eram os atuais que 
conhecemos hoje, mas já apresentavam diferenciais e facilidades.
Ao tratarmos de banco de dados, três características são sempre 
destacadas. Elas devem ser observadas e buscadas para que o agrega-
do de dados que se crie possa ser chamado de banco de dados, a saber 
(NAVATHE; ELMASRI, 2005):
 • Um banco de dados deve representar uma porção de um mun-
do real.
 • Os dados em um banco de dados devem ser logicamente coerentes.
 • Os dados e o próprio banco de dados devem ter uma finalidade 
específica.
A obra Sistemas de Bancos de Dados, 
de Ramez Elmasri e Shamkant 
Navathe, atualmente em sua sétima 
edição, tem sido considerada uma 
fonte de referência, em virtude 
de apresentar grande parte dos 
conceitos associados ao banco 
de dados. 
NAVATHE, S.; ELMASRI, R. São Paulo: 
Pearson, 2012.
Livro
14 Banco de Dados I
A primeira característica – porção do mundo real – diz respeito ao 
fato de que o processo de modelagem de dados, que dará origem ao 
banco de dados, deve ser feito com base na observação de um escopo 
definido e se preocupar em capturar as propriedades e características 
(dados) reais dos elementos observados nesse ambiente. Isso assegu-
ra que somente os dados reais dos elementos sejam armazenadosno 
banco de dados, isto é, não teremos informações armazenadas, uma 
vez que elas não são observadas no mundo real, mas sim inferidas por 
meio de transformações.
Além disso, essa primeira característica procura estabelecer o fato 
de um banco de dados ser incompleto, ou seja, não ter todos os dados 
de todos os elementos de um mundo observado. Isso não é um defeito, 
mas sim uma situação esperada, pois não somos obrigados a mapear 
todos os dados de todos os elementos, mas somente aqueles que no 
momento nos sejam necessários ou úteis. A Figura 5, a seguir, mostra 
um exemplo dessa questão:
Figura 5
Seleção da porção do mundo real a ser mapeada
Data de nascimento
Tipo sanguíneo 
Peso
Altura
Data de nascimento
Pressão arterial
Peso
Nome
Altura
Temperatura
Nome
Seleção
Fonte: Elaborada pelo autor.
No exemplo da Figura 5, elencamos alguns poucos dados. Entretan-
to, sabemos que uma pessoa tem muito mais dados que poderiam ser 
observados, como tipo sanguíneo, pressão arterial e temperatura. Po-
rém, de que serviriam esses dados no nosso banco se o que desejamos 
é criar um BD
1 para processamento da folha de pagamentos de uma 
empresa? Para que serviria conhecer o tipo sanguíneo de um funcioná-
rio para gerar sua folha de pagamento?
Comumente, utilizaremos a 
sigla “BD” para nos referirmos ao 
banco de dados.
1
Introdução a banco de dados 15
Dessa forma, delimitar o escopo dos objetos observados, bem como 
o escopo dos dados a serem mapeados para cada um desses objetos 
não é um defeito, mas um objetivo do processo.
A segunda característica – dados coerentes – diz respeito ao fato 
de que somente reunir dados delimitados de alguns objetos observa-
dos em um mundo real não é suficiente. É necessário que os dados 
sejam logicamente coerentes, isto é, que exista a correlação entre os 
dados de diferentes objetos. Além disso, é necessário que esses dados 
tenham (e mantenham com o passar do tempo) uma integridade com 
os fatos do mundo real, que não existam dados iguais com nomes di-
ferentes (mapeados de modo repetido), que não sejam dados que se 
contradigam e que não existam dados representados em objetos aos 
quais eles não pertençam.
Para entendermos essas questão, voltemos ao exemplo no qual 
mapeamos dois objetos (pessoa e casamento) e vamos aprimorá-lo 
com base nesse novo requisito.
Ao observar os dados já mapeados, podemos perceber que existe 
a necessidade de agregar alguns novos dados ao objeto “casamento”: 
o nome dos noivos. Isso irá enriquecer o modelo e também o tornará 
mais real, uma vez que um casamento sem noivos seria no mínimo 
estranho. Passaríamos a ter, desse modo, em nosso BD, os seguintes 
dados:
Figura 6
Mapeamento dos dados das entidades “casamento” e “pessoa”
CASAMENTO
• Data do evento
• Horário 
• Regime de comunhão de bens
• Tipo de decoração
• Nome do noivo
• Nome da noiva
PESSOA
• Nome
• Data de nascimento
Fonte: Elaborada pelo autor.
Ao realizarmos essa ação, aparentemente teríamos um melhor ma-
peamento dos dados do casamento. Contudo, se pretendemos ter um 
BD com dados coerentes, devemos assegurar, de algum modo, que to-
16 Banco de Dados I
dos os nomes armazenados nos campos “nome do noivo” e “nome da 
noiva” também existam no campo “nome” do objeto “pessoa”, mapea-
do anteriormente.
Se tivermos um nome de noivo ou de noiva que não apareça tam-
bém no objeto “pessoa”, como faríamos para descobrir a data de nas-
cimento desse noivo ou dessa noiva no futuro? Essa ação demonstra 
uma interdependência entre os dados do casamento e os dados das 
pessoas. Porém, de modo contrário, se tivermos nomes de pessoas 
que não apareçam nenhuma vez nos nomes de noivos e noivas, não 
teríamos uma situação de falta de coerência, seriam simplesmente 
pessoas que ainda não se casaram.
Essas situações nos fazem pensar em regras de coerência – ou re-
gras de negócio – que determinam o que pode ou não ocorrer entre os 
dados interdependentes. Nesse exemplo, poderíamos estabelecer que:
 • nem todas as pessoas precisam ser noivos ou noivas;
 • um noivo ou uma noiva precisa ser uma pessoa; e
 • um casamento não pode ocorrer somente com o noivo ou so-
mente com a noiva.
Essas regras serão importantes para estabelecer os relacionamen-
tos entre os objetos do modelo (que são chamados de entidades).
E a terceira característica é o fato de os dados atenderem a uma 
finalidade específica. Tanto o escopo dos objetos observados quanto 
a amplitude do mapeamento desses objetos, o modo de mapeamento, 
a quantidade de dados a serem povoados nessa base de dados e o 
modo como serão 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 
Introdução a banco de dados 17
quantidade de registros de dados que conterá, como serão divididos 
os casamentos de cada diferente país, estado, cidade, entre outros. Em 
resumo, um pequeno BD de casamentos feitos em uma cidade ou um 
enorme BD de casamentos feitos em todo o mundo poderão requerer 
características diferenciadas.
1.1.4 Banco de dados e sistema gerenciador de 
banco de dados: diferenças
Outro ponto que merece distinção quando tratamos de bancos de 
dados é o fato de que para capturar, armazenar, manipular e disponibi-
lizar dados mapeados e definidos em um BD é necessário o uso de um 
software construído especificamente para essas funções.
Esse software – que permite que os sistemas de informação intera-
jam com o banco de dados – é denominado SGBD ou sistema gerencia-
dor de banco de dados. O SGBD não é o banco de dados, ele é o sistema 
que gerencia o BD por meio de diversas funções, a saber:
 • criar o banco;
 • criar tabelas e colunas que vão compor o banco;
 • definir os usuários que poderão ter acesso aos dados;
 • fornecer o acesso para consulta e atualização dos dados;
 • realizar cópias de segurança dos dados;
 • monitorar a performance do banco de dados;
 • permitir a execução de rotinas de compactação de espaço físico.
Existem vários fabricantes de SGBD no mercado, cada um com ca-
racterísticas distintas. Entretanto, de modo geral, todos disponibilizam 
um conjunto comum de recursos voltados à criação e à manutenção do 
banco de dados.
Com base nos padrões internacionais estabelecidos pela ANSI (Ame-
rican National Standard Institute)
2 , temos hoje uma grande compatibi-
lidade entre os diversos SGBDs existentes, principalmente no tocante 
aos recursos que eles fornecem para que os sistemas de informação 
possam interagir. Podemos dizer que atualmente possuímos um pa-
drão de linguagem de programação para acesso ao banco dados (com 
pequenas exceções).
Para conhecer o trabalho da 
ANSI, visite: https://www.ansi.
org/. Acesso em: 19 fev. 2020.
2
18 Banco de Dados I
1.1.5 Sistemas de informação
Temos tratado até aqui, por diversas vezes, de sistemas de informa-
ção como elementos de acesso ao banco de dados. Mas o que são efe-
tivamente os sistemas de informação e por que se denominam assim?
Como vimos anteriormente, um dado pode produzir diversas in-
formações por meio de transformações que venha a ser submetido. 
Quem executará essas transformações serão conjuntos de programas, 
rotinas e funções, que juntos comporão um sistema de informações.
Podemos afirmar que qualquer conjunto de funções que manuseie 
e transforme dados é um sistema de informação. Assim, um simplesapp de um smartphone que realize o controle de gastos para geren-
ciá-los pode ser um sistema de informações. Mas e o banco de dados, 
onde estará? É necessário ter um SGBD no smartphone? Não necessa-
riamente. Podemos ter um banco de dados sem um SGBD, com es-
truturas mais simples de manuseio de dados. Porém, se estivermos 
tratando de um sistema corporativo de gestão de finanças, muito pro-
vavelmente, pela complexidade e extensão dos dados a se manusear, 
faz-se necessária a presença de um SGBD.
1.1.6 Evolução das estruturas de dados
Os sistemas de informação sempre tiveram suas demandas de aces-
so e armazenamento de dados providas por algum tipo de estrutura de 
dados, mesmo antes da existência dos SGBDs. Naturalmente, com a 
evolução da tecnologia, a disponibilidade de recursos de hardware e as 
novas demandas por maiores facilidades para produção de programas 
que interagissem com os bancos dados, o mercado passou a oferecer 
alternativas mais complexas e com melhores recursos.
Figura 7
Surgimento das tecnologias para dados
Anos 1950 Anos 1960 Anos 1970 Anos 1980 Anos 1990
Sistemas 
de arquivo
BD
Hierárquico
BD
Rede
BD
Relacional
BD
Pós-relacional
Fonte: Elaborada pelo autor
Introdução a banco de dados 19
Durante a década de 1950 e até o início da década de 1960, a es-
trutura de dados predominante era a dos sistemas de arquivo, primei-
ramente sequenciais (na qual, para ler um registro de número 3, era 
necessário primeiramente ler o registro de número 1 e, em seguida, o 
de número 2), e, depois, também indexados – que permitiam acesso di-
reto a um registro sem necessidade de ler todos os registros anteriores.
Já no final da década de 1960, ocorreu o surgimento dos primeiros 
SGBDs que já implementavam um modelo hierárquico de acesso aos da-
dos como uma derivação dos mecanismos de acesso indexados, no qual 
coleções de arquivos eram reunidas e gerenciadas de modo integrado.
Durante a década de 1970 e início da década de 1980, houve a pre-
dominância dos SGBDs em rede, estrutura de organização e recupera-
ção de dados baseada em vínculos criados entre os registros por meio 
de ponteiros 3 . Voltando ao exemplo, se em um casamento há duas 
pessoas envolvidas, o registro do casamento no banco de dados apon-
ta, por meio de ponteiros, para os registros que contêm os dados da 
“pessoa 1” e da “pessoa 2”, as quais fazem parte do conjuntos de pes-
soas. Uma estrutura de encadeamento circular de dados faz o vínculo 
de armazenamento e de recuperação de dados.
Em meados da década de 1980, o mercado de SGBD passou a ser 
dominado pelos SGBDs relacionais, baseados em uma estrutura de ar-
mazenamento de dados em tabelas, com linhas e colunas, e utilizando 
operações relacionais (com origem na teoria dos conjuntos) para recu-
peração dos dados armazenados nesses conjuntos de dados (tabelas).
Por fim, ainda na década de 1980 surgiram os SGBDs orientados 
a objetos relacionais ou pós-relacionais. Esses SGBDs foram adap-
tados aos novos requisitos das linguagens orientadas a objetos e 
às novas demandas de armazenamento de dados complexos – ima-
gens, diagramas, documentos. Nesse sentido, houve a implementa-
ção de novas estruturas de armazenamento e recuperação de dados 
com estruturas complexas.
É importante considerar que o surgimento de uma nova abordagem 
de estrutura de BD não significa que a abordagem anterior deixe de 
existir. Assim, ainda há muitos sistemas que até hoje preservam estru-
turas de arquivo ou de bancos de dados hierárquicos 4 .
Ponteiros são campos inseridos 
no banco de dados para 
referenciar um outro registro 
também existente nesse mesmo 
banco dedados, criando um 
apontamento.
3
Veremos os diferentes tipos de 
BDs ainda neste capítulo.
4
20 Banco de Dados I
1.1.7 Administração de dados
Com o crescente uso de SGBDs pelos sistemas de informação – prin-
cipalmente nas grandes corporações – e com o aumento da complexi-
dade das estruturas dos BDs, surgiu a necessidade de implementação 
de uma nova categoria de profissionais que tivessem a capacidade de 
criar, manter e administrar os modelos de dados de modo eficiente.
Essa categoria de profissionais passou a ser denominada de admi-
nistradores de dados. Sua função não era ligada diretamente ao SGBD, 
mas sim a aspectos conceituais e lógicos envolvidos nos modelos de da-
dos criados. Se o modelo de dados daria origem a um banco de dados 
relacional ou a um banco de dados em rede, era uma decisão técnica 
que cabia a outro profissional, o administrador do banco de dados.
Dentre as funções do administrador de dados podemos elencar:
 • identificar as fontes de dados da organização;
 • mapear os dados identificados;
 • estabelecer relacionamentos entre os dados de modo coerente;
 • definir a utilização dos dados e a propriedade dos dados, isto é, 
quem deve mantê-los; e
 • identificar redundâncias e inconsistências nos dados e tratá-las.
Essas funções envolvem a gestão de dados independentemente de 
qualquer implementação física de um banco de dados. Pode parecer 
estranho, mas é possível executar as funções de administrador de da-
dos mesmo em empresas que jamais tenham um SGBD e um sistema 
de informação que use esses dados. Os dados existentes em formulá-
rios, documentos e planilhas podem fazer parte das tarefas do admi-
nistrador de dados.
1.1.8 Administração de banco de dados
Se o administrador de dados não tinha funções ligadas ao SGBD, 
um profissional deveria ser designado para executar essas funções. Foi 
assim que surgiu a figura do administrador de banco de dados. Esse 
sim é um profissional diretamente ligado ao SGBD e que, portanto, 
tem que conhecer os aspectos técnicos específicos para implementar o 
banco de dados mapeado pelo administrador de dados.
Introdução a banco de dados 21
Esses dois profissionais têm papéis complementares: um modela ou 
prepara a estrutura nativa dos dados, o outro implementa essa estru-
tura utilizando recursos do SGBD. Em empresas com equipes menores, 
um mesmo profissional pode assumir essas duas funções simultanea-
mente. Já em empresas com equipes mais especializadas é comum 
existir separadamente um administrador de dados e um administrador 
de banco de dados, uma vez que as competências são diferenciadas.
Como o administrador de banco de dados tem interação direta com 
o SGBD, é necessário que esse profissional possua um perfil bastante 
técnico e com formação específica e treinamentos para conhecer os 
recursos do SGBD escolhido. Como cada fabricante de SGBD tem suas 
particularidades, muitas vezes o conhecimento prévio pode não ser su-
ficiente. Além disso, o suporte ao uso do SGBD para os programadores, 
os analistas e as tratativas de problemas encontrados durante o uso 
são tarefas do administrador de banco de dados e não do administra-
dor de dados.
São tarefas de um administrador de banco de dados:
 • transformar o modelo de dados conceitual em modelo lógico;
 • definir o esquema interno do BD (usando a linguagem do SGBD);
 • realizar o suporte aos programadores e analistas;
 • implementar as restrições de segurança e integridade no SGBD;
 • monitorar o desempenho e responder a requisitos de mudanças;
 • definir normas de descarga e recarga do banco de dados (backup);
 • executar procedimentos operacionais no banco de dados.
1.2 Vantagens e desvantagens do 
uso de um banco de dados Vídeo
A adoção de uma abordagem baseada em bancos de dados não 
é somente uma escolha técnica ou uma imposição da evolução tec-
nológica que aconteceu nos últimos anos. O Quadro 1, a seguir, elen-
ca as principais vantagens do uso de bancos de dados (DATE, 2004; 
SILBERSCHATZ, KORTH, SUDARSHAN, 2012).
22 Banco de Dados I
Quadro 1
Vantagens do banco de dados
Compartilhamento 
dos dados
O objetivo principal de um BD é reunir um conjunto de dados de modo coerente para 
disponibilizá-lo a um grande contingente de aplicações, as quais poderão, então, compartilhar 
esses dados. Se tivermos, por exemplo,os dados de pessoas armazenados em um BD, 
poderemos compartilhá-los com todas as aplicações que de algum modo precisem acessar 
ou atualizar dados, como “nome” e “data de nascimento”. Esse compartilhamento, segundo 
Heuser (2009), reduz o custo total de propriedade dos dados, isto é, o custo total para obter, 
manter e usar dados.
Facilidade de acesso 
aos dados
Ao utilizar um SGBD para manter um BD, passa-se a ter um método de acesso único, provido 
também por meio de uma linguagem estruturada (SQL – linguagem padrão para banco de 
dados relacionais) que padroniza e facilita o reaproveitamento de códigos gerados para 
interação com o banco de dados. Se cada aplicação tivesse o seu próprio arquivo, seria possível 
ter diferentes métodos de acesso e haveria dificuldades para compartilhar códigos e funções já 
criadas em outros sistemas.
Redução da 
redundância
Considerando uma estruturação coerente de dados e o objetivo de compartilhamento, há de 
se obter, naturalmente, um BD em que a redundância de dados seja bastante reduzida ou até 
inexista. Com a redundância sob controle, é possível produzir indiretamente outros benefícios, 
como, novamente, a redução do custo de propriedade dos dados.
Redução das 
inconsistências
Ao criar um conjunto de dados coerente, integrado e que tenha baixa ou nenhuma 
redundância, tem-se, naturalmente, a redução das possíveis inconsistências entre os dados 
existentes no BD. O estabelecimento de regras de criação, de atualização e até de exclusão de 
dados, dentro de critérios coerentes, irá permitir, por exemplo, que não tenhamos “casamentos” 
referenciando nomes que não existam no conjunto de dados de pessoas.
Disponibilidade de 
suporte a transações
Os SGBDs e as linguagens de programação que eles dispõem para a construção de funções 
de acesso, atualização e exclusão de dados proveem meios para que o acesso concorrente 
(simultâneo) de diversos programas possa ser feito a um mesmo dado sem que este 
apresente um conteúdo não íntegro.
Manutenção da 
integridade
Havendo um controle de transações, uma redução de redundância, uma redução de 
inconsistências e um modelo de dados coerente, poderemos assegurar que o banco de 
dados terá seus dados íntegros, isto é, conseguiremos manter a coerência dos dados 
planejada, mesmo que diversos programas e usuários simultaneamente estejam executando 
rotinas de inclusão, alteração e exclusão de dados. Isso será assegurado por recursos do 
próprio SGBD, no qual se pode estabelecer regras de integridade que serão sempre aplicadas 
sobre cada transação executada no BD.
Balanceamento de 
requisitos 
conflitantes
Como as várias transações concorrentes requisitarão atualizações e consultas sobre os mesmos 
dados, poderá ocorrer situações em que um mesmo dado acabe sendo requisitado de modo 
conflitante. O ambiente de banco de dados estará preparado para tratar dessas situações e 
resolvê-las de modo automático, sem que o programador precise se preocupar em escrever 
rotinas especiais.
(Continua)
Introdução a banco de dados 23
Melhoria da 
segurança
Outro importante recurso disponível nos SGBDs são os diversos mecanismos de controle de 
segurança para acesso e para atualização dos dados do BD. Tanto as permissões que definem 
quem pode ou não acessar um dado quanto os mecanismos de garantia das atualizações feitas 
no BD (redo log) irão contribuir para a segurança lógica e física dos dados. Pode-se limitar o acesso 
de uma pessoa ou um sistema a todo um conjunto de dados (uma tabela inteira) ou a somente 
parte dos dados (algumas colunas ou linhas da tabela) por meio da criação de visões de dados.
Utilização de 
padrões
A unificação dos dados em um mesmo BD gera também uma padronização de formatos, 
de regras de atualização e até de conteúdos. Quando existe redundância, podemos ter 
eventualmente o mesmo dado representado em formatos diferentes e com regras de 
atualização diferentes. A centralização de controle dos dados pelo administrador de dados 
pode assegurar que um maior nível de padronização seja criado.
Fonte: Elaborado pelo autor com base em Date, 2004; Silberschatz, Korth, Sudarshan, 2012.
Apesar de todas as características positivas na adoção de uma es-
trutura de banco de dados, temos que estar atentos a algumas pe-
culiaridades que podem trazer desvantagens ao seu uso, as quais 
descrevemos a seguir.
Quadro 2
Desvantagens do banco de dados
Perda de autonomia 
sobre os dados
Quando tratamos de centralização, 
seja de dados, de processos, 
de pessoas, de equipamentos, 
temos naturalmente a perda de 
autonomia sobre esses mesmos 
itens. Quando determinado dado 
é definido, criado, atualizado ou 
excluído e compartilhado com 
outras aplicações, é necessário 
realizar essas operações ciente de 
que outras pessoas podem vir a 
ser impactadas. Se, por exemplo, 
ao resolver mudar o número de 
identificação de 6 dígitos para 7 
dígitos, porque o sistema requer 
esse novo tamanho, qual será o 
impacto nos demais sistemas que 
já usam esse código? Talvez a troca 
não seja tão fácil como seria em um 
arquivo individual.
Interdependência 
entre os dados
A interdependência criada pela 
centralização dos dados também 
poderá afetar, de certo modo, 
determinada aplicação ou a 
aplicação de terceiros. No caso de 
somente um arquivo próprio, com 
os dados que o sistema requer, 
talvez esse arquivo nunca fosse 
impactado por outro sistema que 
resolvesse inserir outras 200 mil 
pessoas em um cadastro que tinha 
somente mil. Um BD que tinha 
somente os dados de “pessoa” e 
de “casamento” em poucos meses 
poderá ter dados de outros 100 
ou 200 objetos, relacionados com 
“pessoa” e com “casamento” de 
um modo não antes imaginado. 
Contudo, é importante lembrar que 
os dados não são mais individuais.
Sincronização dos 
dados no tempo
Imagine que foi atualizado todo um 
cadastro de pessoas, corrigindo os 
números de CEP das residências 
de cada um dos colaboradores. 
Em paralelo, outro programa foi 
executado por outra aplicação, 
mudando também os telefones dos 
colaboradores. Agora, imagine que, em 
razão de um problema no processo 
de atualização do CEP, todos os dados 
atualizados ficaram errados, sendo 
necessário voltar ao estágio anterior 
para reprocessar a atualização. Isso 
seria muito fácil de ser feito, caso 
não fosse compartilhado um BD 
com outras aplicações. É importante 
lembrar que os dados não são mais 
individuais e estar preparado para 
esse e outros tipos de situações em 
que a sincronização dos dados entre 
diferentes aplicações será dependente 
do tempo, ou de quando for feita.
Fonte: Elaborado pelo autor com base em Date, 2004; Silberschatz, Korth, Sudarshan, 2012.
24 Banco de Dados I
Ao analisar vantagens e desvantagens do uso de bancos de dados, 
pode-se perceber que os pontos positivos superam os pontos negati-
vos. Desse modo, o uso dessa abordagem é uma alternativa bastante 
viável para boa parte dos sistemas de informação.
1.3 Criação e manutenção de bancos de dados
Vídeo
O processo de criação de um banco de dados que será disponibili-
zado por meio de um SGBD, para uma ou mais aplicações, requer um 
formalismo para que tenha as três características citadas por Navathe 
e Elmasri (2005): porção do mundo real, logicamente coerentes e fina-
lidade específica.
É verdade que, em um primeiro momento, poderíamos abrir mão 
desse processo formal para criar um SGBD, mas o resultado seria, com 
o passar do tempo, a desestruturação dos dados. Muitas vezes, pela 
aparente simplicidade do processo de criação de estruturas de dados 
no SGBD (em função das ferramentas que ele fornece), pode-se pensar: 
“Por que não ir direto ao SGBD e criar as tabelas de que preciso?”. Nesse 
caso, é importante lembrar: os dados não são seus, são da organização.
Nesse sentido, apresentamos a seguir os passos que devem ser se-
guidos formalmente para ter um processo incremental de evolução do 
BD sem que eleperca sua integridade e sua coerência e para que não 
tenha redundâncias.
Mapeamento dos dados
A criação de um BD começa, como vimos, com o administrador de 
dados, que é quem conhece os dados da empresa. Esse profissional 
sabe onde os dados são gerados, quem é o responsável por sua atua-
lização, o que esses dados representam e qual padrão devem seguir. 
Desse modo, a primeira etapa na criação de um BD é identificar os 
dados envolvidos.
Para o administrador de dados, esses dados ainda não precisam ter 
a finalidade de formar um BD, eles poderiam simplesmente estar pre-
sentes na empresa. Mas esse profissional tem interesse em conhecê-
-los para que futuramente – caso alguém precise desse dado em um BD 
para sua aplicação – possa ofertá-los para compor o banco de dados.
Introdução a banco de dados 25
Isso significa que a criação de um banco de dados pode começar 
muito antes do surgimento da necessidade de um novo sistema ou de 
um novo aplicativo. Podemos perceber que se o administrador de da-
dos realmente cumprir o papel de mapear os dados da empresa, ele 
estará, na verdade, antecipando o trabalho dos futuros analistas de sis-
temas ou administradores de banco de dados no momento em que se 
tenha a demanda de criação de novos BDs.
Modelagem conceitual
O próximo passo a ser seguido na criação do banco de dados é rea-
lizar a modelagem conceitual dos dados que o escopo da demanda re-
quer. Como vimos, todo BD representa uma porção do mundo real em 
um dado momento. Precisamos, então, delimitar a nossa porção de 
mundo real e iniciar a modelagem conceitual desses dados.
Mas o que é a modelagem conceitual? Segundo Heuser (2009), ela é 
um processo de criação de uma representação gráfica e textual de basi-
camente dois elementos: as entidades e os relacionamentos. Esse pro-
cesso identifica os objetos ou fatos do mundo real a serem mapeados 
(as entidades) e os relacionamentos que existem entre esses objetos 
(por meio de regras). Em nosso exemplo, teríamos a entidade “pessoa” 
e a entidade “casamento” (que são os objetos e fatos) e a regra relacio-
namento, que seria “uma pessoa é noivo em um ou mais casamentos”.
Criando esse modelo, identificamos quais dados de quais entidades 
iremos necessitar, e o administrador de dados poderá nos dizer se já os 
conhece ou não. Se eles já foram mapeados anteriormente, obtém-se 
as informações sobre esse dado já disponível. Se não foram ainda ma-
peados, pode-se, com ajuda do administrador de dados, mapear novos 
dados corporativos, ou seja, que comporão o modelo em questão, mas 
que estarão disponíveis para toda a organização futuramente. Esse é o 
processo incremental e cíclico que gera um conjunto compartilhado e 
coerente de dados.
O que precisamos destacar é o fato de que o modelo conceitual, nes-
se momento, ainda é independente de um SGBD, ou seja, o modelo con-
ceitual não é relacional, não é rede e não é hierárquico. Ele representa os 
dados em sua estrutura inerente, sem preocupações com o que o SGBD 
irá futuramente exigir, como chaves, índices, tamanhos de campos etc.
Em Projeto de banco de 
dados, Carlos Heuser 
aborda temáticas 
conceituais de bancos 
de dados. Trata-se de 
uma obra introdutória 
e que precede a leitura 
de outros materiais mais 
densos.
HEUSER, C. A. 6. ed. Porto Alegre: 
Bookman, 2009.
Livro
26 Banco de Dados I
Modelagem lógica
Depois de finalizado o processo de modelagem conceitual, teremos 
uma estrutura gráfica e textual – algumas descrições e definições são 
feitas em texto complementando o gráfico – que será o modelo con-
ceitual. Esse modelo poderá ser derivado ou adaptado para um novo 
tipo, que é o modelo lógico.
Esse, segundo Heuser (2009), captura e incorpora os requisitos do 
SGBD escolhido para a criação do BD. Assim, caso seja escolhido o 
SQL-Server (SGBD fornecido pela Microsoft), será necessário adaptar 
o modelo conceitual aos requisitos de um banco de dados relacional, 
que são diferentes dos requisitos de um SGBD em rede (IDS-II) 5 . Muito 
mais do que requisitos impostos por fabricantes, são requisitos impos-
tos pelas arquiteturas dos bancos de dados. Desse modo, se a arquite-
tura escolhida é a de um BD relacional (e existem vários fornecedores 
no mercado), o modelo conceitual deverá ser adaptado aos requisitos 
do modelo relacional. Esse será um modelo lógico que praticamente 
servirá para qualquer SGBD relacional do mercado, com pequenas mu-
danças em relação a particularidades ou outras questões que um for-
necedor apresente.
Essa derivação de modelo será feita por meio de regras de conver-
são e não irá requerer muito tempo ou esforço. Muitas vezes, até pou-
cas mudanças acontecerão, pois muitas pessoas, ao construírem seus 
modelos conceituais, inconscientemente os criam com uma orientação 
para 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.
Integrated Data Store II, SGBD 
produzido pela empresa francesa 
Bull.
5
Introdução a banco de dados 27
Segundo Heuser (2009), como em todo projeto, é nesse momento 
que detalhes, mecanismos de otimização, cálculos de ocupação de es-
paços, mecanismos de segurança, ente outros elementos são agrega-
dos. Até o ponto em que se tem o modelo lógico, não há preocupação 
com detalhes como:
 • Quantos registros serão armazenados em cada tabela?
 • Qual o tamanho de cada registro?
 • Qual será a necessidade de acesso a essa tabela? Eventual? 
On-line?
 • Como esse dado será compartilhado? Somente em um local? Na 
web?
Todas essas características precisam ser analisadas para que se crie 
uma estrutura física (realmente alocando espaço em disco em um ser-
vidor) para o banco de dados. Aqui, ele deixa de ser um modelo e passa 
a ser um repositório de dados.
Essa etapa do processo requer a participação do administrador de 
banco de dados, que também participa da etapa do modelo lógico, pois 
ambas as etapas requerem o conhecimento específico das característi-
cas do SGBD escolhido.
Dicionário de dados
É importante saber que todas as informações sobre o modelo de da-
dos conceitual – lógico e físico – deverão ser registradas em um reposi-
tório que chamamos de dicionário de dados. Nele temos registros de um 
determinado campo (por exemplo, “data de nascimento”), a saber:
 • A qual entidade pertence.
 • Como é alimentado.
 • Quando é atualizado.
 • Quem é o responsável pela criação.
 • Quem é o responsável pela atualização.
 • É um campo de preenchimento obrigatório?
 • Que conteúdo terá se não for preenchido? Uma data padrão?
 • Qual o formato? Tem só dia, mês e ano ou precisa de hora e 
minuto?
 • Por que foi escolhido esse formato? Existe uma norma que exige?
28 Banco de Dados I
Pode-se perceber que as informações coletadas na fase de modela-
gem conceitual, lógica e física estão aqui registradas. Elas servirão para 
o administrador de dados compartilhar futuramente esses dados, sa-
bendo de suas características previamente estabelecidas. As mudanças 
que venham a ocorrer nessas informações precisam ser divulgadas aos 
usuários desse dado – por exemplo, modificações na regra de preen-
chimento ou uma mudança de formato – para que eles avaliem os im-
pactos em suas aplicações.
Processos operacionais
Estando o BD criado fisicamente e pronto para uso, inicia-se a fase 
de definição e implementação de procedimentos operacionais de ad-
ministração do banco de dados. Entre essesprocessos temos:
 • monitoração do acesso aos dados;
 • monitoração da performance de acesso;
 • rotinas de salvamento (backup);
 • planos de recuperação e contingência para falhas no BD;
 • rotinas de compactação de dados (para redução do espaço em 
disco);
 • rotinas de criação e recriação de índices (melhoria de performance).
Todas essas rotinas são de responsabilidade do administrador de 
dados, que, após esse momento, passa a ter o BD como um recurso 
de compartilhamento de dados com a organização, e deve estar ciente 
dos impactos negativos que uma indisponibilidade desse recurso possa 
causar. Mesmo que em um primeiro momento o BD esteja sendo cria-
do para uma única aplicação, em breve ele estará sendo compartilhado 
com diversas aplicações e poderá ter níveis de disponibilidade diferentes 
para cada uma delas. Algumas, talvez, só o utilizem durante o dia, mas 
outras talvez requeiram disponibilidade de 24 horas por dia e 7 dias da 
semana. Tudo isso também deve estar mapeado no dicionário de dados 
e servirá de subsídio para que o administrador de banco de dados possa 
estabelecer suas rotinas operacionais de acordo com os requisitos.
Algumas das definições físicas poderão, com o passar do tempo, ser 
alteradas em razão de demandas de outras aplicações, mudanças de 
regras, normas da empresa ou até crescimento no volume de dados do 
BD. Logo, as tarefas dessa etapa serão continuamente executadas ao 
longo da vida do banco de dados.
Introdução a banco de dados 29
1.4 Tipos de bancos de dados
Vídeo O processo modelagem pode se aplicar, com pequenas adaptações, à 
construção de diferentes tipos de bancos de dados. Alguns desses tipos 
foram historicamente importantes e não são mais usados com frequên-
cia. Outros ainda têm usos isolados em aplicações desenvolvidas há mui-
to tempo, mas que se mantêm ativas, por exemplo, no setor bancário, 
o qual ainda preserva aplicações antigas, mas estáveis e em operação.
A seguir, relacionamos conceitos básicos de cada um desses tipos 
de bancos de dados, de modo a permitir, pelo menos, o reconhecimen-
to, a identificação de benefícios e possibilidades de aplicação.
1.4.1 Banco de dados hierárquico
Os bancos de dados hierárquicos foram os primeiros modelos de 
implementação de BDs derivados das estruturas de arquivos indexa-
dos. Eles já agregavam o conceito de reunir de modo único diferentes 
coleções de dados. Isso se diferenciava de um simples arquivo indexa-
do, que normalmente atendia a somente um conjunto de dados. Por 
exemplo, ao usar arquivos para armazenar dados de “pessoas” e de 
“casamentos”, fazia-se necessário ter dois arquivos indexados. Ao usar 
um banco de dados hierárquico, era possível ter os dois conjuntos de 
dados integrados em um só lugar.
É certo que esse tipo de BD ainda tinha grandes restrições para im-
plementar todo tipo de relacionamento entre diferentes conjuntos de 
dados, pois, como o próprio nome sugere, ele só era capaz de imple-
mentar hierarquias, isto é, estruturas em árvore.
Toda a estrutura de agregação dos dados era realizada por meio 
de ponteiros – campos que continham o endereço físico do outro ele-
mento a ser apontado –, o que garantia uma associação entre registros, 
mantida pelo SGBD e não pelo programador. O programador precisava 
somente indicar os elementos para que a associação se completasse.
Apesar de ser limitado, esse tipo de BD já trazia uma linguagem 
própria e unificada para manipulação dos dados, permitia o compar-
tilhamento e unificava a administração dos dados. O BD hierárquico já 
implementava boa parte dos benefícios de uso de um banco de dados.
30 Banco de Dados I
Considerando que não havia na época outra alternativa senão o uso 
de arquivos isolados, os BDs hierárquicos passaram a ser adotados no 
ambiente de corporações que manipulavam grandes volumes de dados 
em suas aplicações, e se mantiveram por muito tempo em operação.
1.4.2 Banco de dados em rede
A limitação do banco de dados hierárquico levou os pesquisadores 
da época a buscar uma alternativa para que o modelo hierárquico evo-
luísse para um modelo em rede. No modelo em rede (muito similar ao 
hierárquico), pode-se ter um conjunto de dados participando de mais 
de um relacionamento com diferentes conjuntos.
Esse novo recurso resolvia a restrição existente no modelo hierár-
quico e, por isso, passou a ser o novo modelo mais procurado para im-
plementações de bancos de dados. Por muito tempo, os BDs em rede 
dominaram o mercado, mas mesmo assim eles ainda apresentavam 
algumas restrições que precisavam ser superadas.
Assim como os modelos hierárquicos, que utilizavam ponteiros para 
fazer a associação entre os registros, o modelo rede acabava por criar uma 
estrutura muito rígida de relacionamento entre os conjuntos de dados.
Imagine que um modelo tivesse um conjunto “filho” associado a so-
mente um conjunto “pai”. Imagine também que seria criado, em segui-
da, um novo relacionamento desse mesmo conjunto “filho” com um 
novo conjunto “pai”. Como toda essa associação era feita fisicamente 
por campos gravados no registro “filho”, era necessário alterá-lo para 
que ele recebesse mais um campo de ponteiros para o novo relaciona-
mento. Para tanto, o espaço que aquele registro ocupava no disco iria 
crescer. Seria necessário descarregar todos os registros “filho” da base 
para outro arquivo e, em seguida, reinseri-los com um novo campo e 
ocupando um novo espaço.
1.4.3 Banco de dados relacional
O banco de dados com abordagem relacional surgiu para trazer 
maior flexibilidade às estruturas de dados dos BDs, permitindo que 
novas colunas (campos de dados) fossem agregadas facilmente a um 
registro já existente, bem como que novos relacionamentos pudessem 
ser agregados entre esse e outros registros, sem que isso impactasse o 
armazenamento físico do banco de dados.
Introdução a banco de dados 31
No BD relacional, deixou-se de ter ponteiros para associar registros 
– pois eles eram campos “artificiais”, usados somente com finalidade 
associativa – e passou-se a utilizar, então, associações feitas por meio 
de campos naturais. Isso significa que, por exemplo, caso seja necessá-
rio associar um “professor” a uma “disciplina” que ele ministra, basta ir 
ao registro da “disciplina” e inserir o código da matrícula do professor. 
Passamos a relacionar a disciplina com o professor com dados natu-
rais (aqueles que existem no mundo real) e não com dados artificiais 
(aqueles criados somente para viabilizar um relacionamento entre da-
dos naturais).
Essa nova abordagem relacional veio atender de modo bastante 
completo todas as restrições que existiam, além de resolvê-las utilizan-
do uma abordagem já amplamente validada: a teoria dos conjuntos 
(oriunda da matemática básica).
1.4.4 Banco de dados pós-relacionais
A partir da década de 1980, o mercado foi dominado pelos bancos 
de dados relacionais, tendência que se mantém até hoje. Porém, mes-
mo que os BDs relacionais tenham atendido grande parte das deman-
das de criação de bancos de dados, ainda tivemos uma nova onda que 
se iniciou por volta da década de 1990.
Com o advento das linguagens orientadas a objeto (C++, smalltalk, en-
tre outras), o surgimento de novas metodologias de análise de sistemas 
e o desenvolvimento de sistemas orientados a objetos, muitos passaram 
a se questionar se também os bancos de dados não deveriam usar uma 
abordagem orientada a objetos para armazenamento dos dados.
Nesse sentido, surgem os primeiros bancos de dados orientados a ob-
jetos – Objectivity/DB, Ontos, O2 e ITASCA –, com o objetivo de proverem 
meios para o armazenamento de dados complexos e serem mais fiéis à 
representação dos objetos mapeados pelas linguagens de programação.
Comercialmente, esses BDs não se estabeleceram no mercado, al-
guns serviram para projetos muito específicos (normalmente em áreas 
científicas), mas sem uma representatividade numérica quanto aos 
profissionais que os conhecem e os utilizam.
Comoos modelos relacionais ainda tinham grande dominância 
no mercado, surgiram tentativas de criação de um modelo chamado 
objeto-relacional ou relacional estendido. Tratava-se de um modelo que 
incorporava algumas evoluções do relacional convencional, mas que 
32 Banco de Dados I
utilizava em grande parte os recursos dos relacionais já tão aceitos pelo 
mercado. Esse modelo também não teve predominância no mercado 
e hoje quase não é mais visto em aplicações comerciais. A verdade é 
que 99% das aplicações comerciais podem ser bem atendidas com o 
modelo relacional convencional, sendo a opção de grande parte dos 
projetos.
Em 2009, ressurgiu uma nova onda, liderada por pesquisadores que 
buscavam meios para que os BDs relacionais pudessem tratar de ques-
tões complexas, como distribuição de dados, altos volumes de arma-
zenamento (da ordem de terabytes), armazenamento e recuperação 
de dados científicos, como mapas, fotos, escâneres, entre outros. Esse 
movimento teve início em 1998, quando pela primeira vez já se falava 
em NoSQL
6 , mas somente com a viabilização de softwares e hardwa-
res mais modernos voltou a ser tratado em bancos de dados NoSQL, 
como MongoDB, Cassandra, entre outros.
Os BDs não relacionais utilizam os recursos do ambiente relacional 
(SQL), mas agregam outras facilidades típicas dos modelos orientados 
a objetos, bem como outras para gerenciamento de distribuição de da-
dos em grandes volumes. Imagine uma base de dados de indexação 
de páginas web que é usada pelo buscador Google para atender a um 
pedido de filtro feito no browser. Que tamanho deve ter essa base? E 
onde ela está localizada? Qual comando de filtro é aplicado para se-
lecionar os registros que interessam? Com certeza um banco de da-
dos relacional convencional não daria conta de tudo isso. Para tanto, o 
próprio Google, em 2003, criou uma iniciativa de um software livre de 
banco de dados chamado Hadoop, que manuseia grandes volumes de 
dados estruturados e não estruturados. Essa plataforma hoje é um dos 
grandes exemplos de soluções NoSQL.
A denominação NoSQL não implica que esse tipo de BD não utilizará 
o SQL, mas que implementará outros recursos além dele. É importante 
ressaltar que a sigla NoSQL significa “not only SQL” (“não apenas SQL”, 
em tradução livre), e não “not SQL” (“não SQL”, em tradução livre). Ele 
preserva e expande o modelo SQL.
Finalmente, nas últimas décadas, temos visto pesquisas orientadas 
para novas arquiteturas de bancos de dados que possam gerenciar 
grandes volumes de dados em função do novo conceito de big data
7
, 
que passou a ser agregado a uma série de aplicações. Esse é um tema 
em amplo desenvolvimento e que promete ainda grandes surpresas.
terabyte: “múltiplo do byte, 
que vale 1.024 gigabytes”. “Fre-
quemente arredonda-se o valor 
do terabyte para mil gigabytes” 
(HOUAISS, 2009).
Glossário
Termo genérico adotado para 
representar os bancos de dados 
não relacionais.
6
Grandes BDs que armazenam 
massas de dados de proporções 
muito grandes quando com-
paradas aos bancos de dados 
comerciais.
7
Introdução a banco de dados 33
CONSIDERAÇÕES FINAIS
Neste capítulo, vimos que a criação de um banco de dados é mais do 
que uma escolha técnica por um software de SGBD. Temos uma grande 
responsabilidade em criar algo que será compartilhado com toda a orga-
nização e não somente com nossos próprios sistemas.
Precisamos conhecer os dados, identificar suas características, verifi-
car o modo como se relacionam com outros dados e tantos outros deta-
lhes. Portanto, é importante lembrar: os dados não são seus, eles são da 
organização. Aquilo que você cria hoje poderá amanhã ser alterado e até 
mesmo excluído por outra pessoa. Assim, todo o cuidado no estabeleci-
mento de regras de utilização desses dados deve ser tomado.
Não tenha pressa de criar seu banco de dados. Aqui vale um velho 
ditado: “se você tem duas horas para cortar uma árvore, gaste uma hora 
e meia afiando seu machado”.
ATIVIDADES
1. Por que podemos afirmar que, ao criar um banco de dados, os dados 
não são nossos?
2. Por que um administrador de dados nem sempre é o profissional 
indicado para ser o administrador do banco de dados?
3. Por que um banco de dados deve ser sempre visto como uma porção 
do mundo real?
REFERÊNCIAS
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: Elsevier, 2004.
HEUSER, C. A. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.
HOUAISS, A. (org.). Houaiss eletrônico. Rio de Janeiro: Objetiva, 2009. 1 CD-ROM.
NAVATHE, S. B.; ELMASRI, R. Sistema de banco de dados. 4. ed. São Paulo: Person Brasil, 
2005.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio de 
Janeiro: Elsevier, 2012.
34 Banco de Dados I
2
Sistema de gerência 
de banco de dados
Neste capítulo, vamos conhecer com mais detalhes qual é a 
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-
Sistema de gerência de banco de dados 35
dos privilegiados – usados para definir regras de segurança, controles 
de acesso, definição de perfis (roles) etc.
Por fim, entre as funções de apoio, encontramos aquelas ligadas 
a controles de transações e de concorrência de acesso. Além disso, 
encontram-se funções ligadas ao subsistema de recuperação (backup 
e restore) e aos controles de performance do armazenamento e do 
acesso aos dados.
Segundo Navathe e Elmasri (2006), a arquitetura de um SGBD ge-
nérico pode ser demonstrada na Figura 1, em que podemos ver os di-
versos programas que executam funções distintas, tais como interagir 
com os usuários externos, processar comandos internos etc.
Figura 1
Arquitetura de um SGBD
COMANDOS DDL 
Compilador 
DDL
Compilador da 
linguagem hospedeira 
Compilador 
DML 
Compilador 
de pesquisa 
Gerenciamento 
dos dados 
armazenados 
Controle de concorrência / backup / 
subsistema de recuperação
Processador de 
banco de dados 
em tempo 
de execução 
(runtime)
COMANDOS 
PRIVILEGIADOS 
PESQUISA 
INTERATIVA
TRANSAÇÕES 
COMPILADAS 
(CUSTOMIZADAS)
COMANDOS 
DML 
PROGRAMAS DE 
APLICAÇÃO Equipe DBA Usuários casuais 
execução 
E A
B
D
C
execução 
Programadores 
de aplicação 
Usuários 
parametrizáveis 
Catálogo do 
sistema / 
dicionário de 
dados 
BANCO DE DADOS 
ARMAZENADO 
Pré-compilador 
Fonte: Navathe; Elmasri, 2006, p. 26. 
36 Banco de Dados I
Todas estas interações – internas, externas e de apoio –, implemen-
tadas pelo sistema gerenciador de bancos de dados, são formalizadaspor meio de um grupo de comandos definido em uma linguagem pa-
dronizada. Essa linguagem é o Structured Query Language, mais co-
nhecido pela sigla SQL, que é dividida em quatro grandes grupos de 
comandos e são organizados de acordo com a finalidade a que se des-
tinam (Figura 2).
Select, Insert, Delete, Update etc.
Grant, Revoke, Deny
Alter, Create, Drop etc.
Commit, Rollback
Data Manipulation Language 
(DML)
Data Control Language 
(DCL)
Data Definition Language 
(DDL)
Transactional Control 
Language (TCL)
Figura 2
Grupos de comandos do SQL
Fonte: Silberschatz; Korth; Sudarshan, 2012, p. 51.
Vários SGBD fornecem interfaces gráficas que servem para a execu-
ção dos comandos de SQL. Isso ocorre com o preenchimento de telas e 
campos parametrizáveis. A Figura 3, a seguir, é um exemplo de interface 
em que se pode ver a área de manipulação e criação de campos em ta-
belas novas sendo feita por meio de preenchimento de campos na tela.
Figura 3
Interface gráfica do Ms-SqlServer para a criação de tabelas
Fonte: Elaborada pelo autor.
Sistema de gerência de banco de dados 37
Dentre os profissionais envolvidos nas atividades diretamente liga-
das ao SGBD, podemos elencar o administrador de banco de dados, 
projetistas e arquitetos de soluções. Além desses, há os usuários even-
tuais ou parametrizáveis, os analistas de sistemas e programadores, os 
fornecedores de ferramentas e as equipes de suporte e operação. O 
Quadro 1, a seguir, descreve a atribuição de cada profissional:
Quadro 1
Profissionais ligados ao SGBD e suas atribuições
Profissional Interação com o SGBD
Administrador de banco de dados Criar, monitorar, controlar e executar tarefas operacionais.
Projetistas e arquitetos de soluções
Definir arquiteturas e alternativas de uso do SGBD em diferentes 
projetos.
Usuários eventuais
Acessar os dados por meio de ferramentas interativas nas quais cada 
acesso requer diferentes dados.
Usuários parametrizáveis
Acessar os dados por meio de interfaces pré-definidas (normal-
mente telas de sistemas) nas quais cada acesso segue um padrão 
pré-programado.
Analistas de sistemas
Definir quais dados devem ser acessados e quais as transformações 
que eles deverão sofrer (especificação).
Programadores
Definir como os dados serão acessados e como eles serão transfor-
mados (codificação).
Fornecedores de ferramentas Criar softwares complementares às funções básicas do SGBD.
Equipe de suporte e operação
Executar atividades operacionais para garantir a disponibilidade e a 
usabilidade do SGBD.
Fonte: Elaborado pelo autor.
Algumas ferramentas que interagem com o SGBD têm sido criadas 
por fornecedores que complementam as funções básicas já oferecidas 
pelos próprios fabricantes do SGBD, como ferramentas para a mode-
lagem conceitual e lógica (CASE), ferramentas de engenharia reversa, 
otimizadores de acesso, monitores de desempenho, interpretadores 
de logs, entre outros.
Algumas destas ferramentas têm SGBDs específicos aos quais se co-
nectam, já outras são de uso geral, podendo se conectar a diferentes 
SGBDs de diferentes fornecedores, o que as tornam mais atrativas para 
os profissionais da área de administração de banco de dados.
38 Banco de Dados I
2.2 Vantagens e desvantagens 
do uso de um SGBD 
Vídeo Quando falamos sobre estruturas de bancos de dados, temos sem-
pre que avaliar tanto os benefícios quanto as eventuais desvantagens 
de usar uma abordagem ou tecnologia. No caso dos SGBDs, a mesma 
regra se aplica: existem pontos positivos (que se destacam) e pontos 
negativos (que precisam ser considerados). Apresentamos, a seguir, 
vantagens e desvantagens da utilização de um SGBD como plataforma 
para o gerenciamento de banco de dados.
2.2.1. Vantagens
Dentre as vantagens apontadas por Navathe e Elmasri (2006), e re-
ferenciadas também por outros autores, serão descritas as seguintes:
 • Natureza de autodescrição de um sistema de banco de dados
Antes da existência dos SGBDs, a definição das estruturas de dados 
era mantida em uma estrutura separada dos próprios dados. A descri-
ção da ordem em que os diversos campos iriam aparecer, o tamanho 
de cada um dos campos, a formatação que apresentariam, entre ou-
tras características, eram armazenadas em um local e os dados eram 
armazenados em outro.
Um programa COBOL, por exemplo, que desejasse acessar um ar-
quivo com dados de “Pessoa” tinha que repetir, em sua estrutura de 
código, a definição dos dados conforme mostra a Figura 4 a seguir.
Figura 4
Representação da estrutura de dados em um programa COBOL
01 REGISTRO-PESSOA
 05 CODIGO-PESSOA PIC 9(006)
 05 NOME-PESSOA PIC X(050)
Fonte: Elaborada pelo autor.
Nesse exemplo, caso um programa COBOL tivesse definido de 
modo equivocado o tamanho do campo “CODIGO-PESSOA” como “7 
dígitos alfanuméricos” em vez de “6 dígitos inteiros e numéricos”, tería-
COBOL: sigla para “COmmon 
Business Oriented Language”, 
em português, “linguagem 
comum orientada para os 
negócios”.
Glossário
Sistema de gerência de banco de dados 39
mos um erro durante a execução desse programa, pois os dados físicos 
existentes em disco não seriam compatíveis com o mapeamento que o 
programa estava fazendo.
Com o advento dos SGBDs, passou-se a ter uma estrutura integrada de 
definição dos dados e de armazenamento dos dados, isto é, se a definição 
muda, os dados mudam. Além disso, os programas não precisam definir 
o layout (estrutura dos campos) de cada registro, como antes faziam. Essa 
consequência nos leva à próxima vantagem do uso dos SGBDs.
 • Isolamento entre programas e dados, abstração de dados
Com a nova estrutura integrada da definição de dados e dos próprios 
dados, se um certo programa referenciar o campo “NOME-PESSOA”, o 
SGBD saberá que seu tamanho é de 50 caracteres alfanuméricos, des-
se modo, o acessará fisicamente no disco, devolvendo esse dado no 
formato do programa. Caso, no dia seguinte, o tamanho desse dado 
seja alterado para 60 caracteres alfanuméricos, o programa não sofre-
rá nenhum impacto, ou seja, não precisará ser alterado e recompilado. 
O programa passa a referenciar um dado por meio de seu nome, tendo 
total abstração do formato, tamanho, modo de armazenamento, estru-
tura física, entre outros.
Um mesmo dado pode estar em um banco de dados centralizado, 
distribuído em um BD local ou remoto, ou, ainda, ser compactado (ou 
não). Tudo isso não afetará o código que o programador irá gerar para 
referenciar ou acessar esse dado, tornando o processo de codificação 
do programa mais simples e garantindo que ele continuará funcionan-
do mesmo que existam alterações na estrutura do banco de dados.
 • Suporte às múltiplas visões de dados
Se a abstração de dados já agrega um importante diferencial para o 
acesso lógico aos dados (e não mais o acesso físico aos dados), o que 
dizer da possibilidade de publicar também múltiplas visões de um mes-
mo conjunto de dados?
Essa habilidade tem grande importância quando lembramos que 
uma das características principais a serem buscadas no uso de um BD 
é o compartilhamento. Porém, ao compartilhar e criar conjuntos coe-
rentes de dados (outra característica importante), poderíamos acabar 
expondo, de modo indevido, porções dos dados que não interessam 
ou que não deveriam ser publicadas a todos os que os acessam.
40 Banco de Dados I
Para contornar essa situação, foi criada uma estrutura definida 
como view, isto é, uma visão dos dados. Por meio de uma view, é possí-
vel restringir um conjunto vertical ou horizontal de dados.
Nas tabelas a seguir, podemos ver que, para uma relação contendo 
várias colunas e várias linhas, é possível produzir diferentes views des-
tes dados, seja pela segmentação horizontal (onde os dados de algu-
mas linhas são selecionados), pela segmentação vertical (onde alguns 
dados de algumas colunas são selecionados) ou, ainda, pela combina-
ção simultânea da segmentação horizontal e vertical.
Tabela 2
View com segmentação vertical (colunas 
Nome + Sexo)Nome pessoa Sexo
JOAO DA SILVA Masculino
MARIA DA SILVA Feminino
PEDRO DA SILVA Masculino
JOSE DA SILVA Masculino
Fonte: Elaborada pelo autor.
Tabela 1
Segmentação horizontal e vertical de uma tabela
Cód. 
Pessoa Nome pessoa
Data de 
nascimento Sexo Raça
000015 JOAO DA SILVA 25/03/1962 Masculino Branco
000017 MARIA DA SILVA 11/07/1964 Feminino Branco
000018 PEDRO DA SILVA 09/11/1992 Masculino Negro
000019 JOSE DA SILVA 11/11/1997 Masculino Branco
Tabela original
Fonte: Elaborada pelo autor.
Tabela 3
View com segmentação horizontal (filtro para “sexo masculino”)
Cód. Pessoa Nome pessoa Data de nascimento Sexo Raça
000015 JOAO DA SILVA 25/03/1962 Masculino Branco
000018 PEDRO DA SILVA 09/11/1992 Masculino Negro
000019 JOSE DA SILVA 11/11/1997 Masculino Branco
Fonte: Elaborada pelo autor.
 • Compartilhamento de dados e processamento de transação 
multiusuário
Finalmente chegamos à última vantagem apresentada por Navathe e 
Elmasri (2006). Essa é uma das características que é vantagem do próprio 
banco de dados, mas, aqui, trata-se de uma abordagem do ponto de vista 
de implementação de funções dentro do SGBD que viabilizam essa função.
Imagine o grau de complexidade com que um programador teria 
que lidar para permitir que um programa pudesse acessar, de modo 
concorrente, um mesmo conjunto de dados no qual diversos progra-
Sistema de gerência de banco de dados 41
mas realizassem operações simultâneas de atualização e exclusão 
caso, no SGBD, não tivesse um conjunto de facilidades prontas para 
essa finalidade. Pode-se dizer que seria praticamente inviável compar-
tilhar e controlar as operações de atualização simultânea se não exis-
tisse, no SGBD, esse controle já automatizado.
2.2.2. Desvantagens
Abordaremos, a seguir, as desvantagens de se utilizar um SGBD na 
implementação de uma estrutura de suporte a dados para um sistema 
de informações.
 • Recursos de infraestrutura
O primeiro ponto que nitidamente chama a atenção é o fato de que 
um SGBD requer muito mais recursos de infraestrutura para ser criado, 
mantido, publicado, compartilhado e administrado. Isso significa que é 
necessário mais poder computacional (hardware e software) para ins-
talar, configurar e disponibilizar um SGBD do que seria necessário para 
disponibilizar uma estrutura baseada em arquivos convencionais.
É necessário considerar que caso vários sistemas precisem criar, de 
modo repetido (não compartilhado), seus arquivos de dados, muito pro-
vavelmente a somatória de pequenos recursos usados em cada siste-
ma possa representar uma somatória até maior do que o próprio SGBD 
represente. Nesse sentido, a infraestrutura pode ser uma desvantagem 
para usos de um SGBD em um ambiente de pouco compartilhamento.
Se imaginarmos, por exemplo, a criação de um catálogo de contatos 
– como o de um software de gerenciamento de números de telefones 
de um smartphone –, no qual dados de pessoas e telefones serão ar-
mazenados e consultados por uma única pessoa, seria talvez inviável 
pensar na infraestrutura necessária para usar um SGBD destinado a 
essa finalidade. A opção por uma estrutura de arquivos locais seria tec-
nicamente viável e indicada.
 • Custo
A segunda desvantagem que podemos elencar é o custo, mesmo 
nos casos em que se possa pensar no uso de um SGBD open-source 
(de software livre). O SGBD em si não tem custos, na verdade, a infraes-
42 Banco de Dados I
trutura que ele usará terá seus custos (maior capacidade de hardware 
necessária, outros softwares complementares etc.). Até o administrador 
de banco de dados envolvido nessa operação terá seus custos, estes, 
normalmente, serão maiores do que o de um profissional não especia-
lista. Além disso, é importante avaliar se a somatória de menores custos 
isolados em vários sistemas poderá representar um custo final maior do 
que a de um único SGBD compartilhado entre vários sistemas.
 • Performance
O terceiro ponto a ser avaliado é a performance final que se deseja 
obter com uma mesma infraestrutura. Se considerarmos que a infraes-
trutura onde o SGBD será executado é limitada – o que pode ocorrer, 
por exemplo, em um smartphone ou em uma estação de atendimento 
do tipo toten –, haverá uma perda de performance cada vez maior, isto 
é, quanto maior for a complexidade do SGBD utilizado, maior será a 
perda de performance.
Vimos, na Figura 1, que o SGBD é um conjunto de programas que 
executam diversas funções. Logo, quanto mais programas tivermos 
para executar em uma mesma infraestrutura limitada, menor será a 
performance final obtida. Por isso, muitas vezes, em ambientes com 
restrições de infraestrutura, estruturas de arquivos convencionais são 
utilizados em vez de SGBDs.
Como pode-se perceber, tanto as vantagens quanto as desvanta-
gens do uso de um gerenciador de banco de dados irão depender di-
retamente das características do ambiente onde serão utilizados. Usos 
corporativos, em ambientes de grande porte, poderão potencializar 
vantagens e 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.
Sistema de gerência de banco de dados 43
2.3 Criação e manutenção de um SGBD 
Vídeo Dentre as funções do SGBD, podemos destacar o fato de ele servir 
como ferramenta para integrar três níveis existentes na arquitetura de 
três esquemas (NAVATHE; ELMASRI, 2006).
A arquitetura de três níveis foi proposta de modo a isolar os dife-
rentes aspectos de manipulação de dados envolvidos em um banco de 
dados. O primeiro nível, chamado de nível interno, 
é representado por um esquema interno que des-
creve toda a estrutura de armazenamento e manipu-
lação física dos dados, ou seja, em um nível próximo 
do hardware. Sem esse nível, gerenciado pelo SGBD, 
teríamos que transferir essa complexa tarefa para o 
programador, aumentando em muito a dificuldade 
para interação dos sistemas de informação com os 
dados que eles viessem a utilizar.
O segundo nível, chamado de nível conceitual, 
está associado ao esquema conceitual e descreve 
de modo integral a estrutura do banco de dados – 
descrição das entidades, relacionamentos, tipos de 
dados, regras de acesso, regras de segurança etc. 
Nesse nível, os detalhes da estrutura física não são 
relevantes, precisamos conhecer os dados que temos disponíveis para 
acesso, porém não é necessário saber como estão fisicamente armaze-
nados. Desse modo, se temos um campo numérico que pode armaze-
nar até oito dígitos inteiros e dois dígitos decimais, não saberemos – e 
não precisaremos saber – quantos bytes são consumidos para guardar 
esse conteúdo em disco quando ele é salvo.
Finalmente o terceiro nível, conhecido como nível externo ou de 
visão, associado ao esquema externo, se apresenta por meio de uma 
série de esquemas (ou visões) que publicarão partes de um banco de 
dados que seja de interesse de um ou mais grupos de usuários. No item 
2.2.1., mais especificamente no tópico “Suporte às múltiplas visões de 
dados”, vimos um exemplo do processo de geração de views, criadas 
por meio da segmentação vertical, horizontal e combinadas entre si; 
essas visões são justamente aquelas gerenciadas pelo esquema exter-
no. Por meio desse esquema, podemos proteger o acesso a partes do 
Livro
O livro Projeto, Desenvol-
vimento de Aplicações e 
Administração de Banco de 
Dados, de Michael V. Man-
nino, apresenta a base 
para entender a tecnolo-
gia de banco de dados, as 
tecnologias