Apostila Unificada - Modelagem de Banco de Dados

Prévia do material em texto

MODELAGEM E 
DESENVOLVIMENTO 
DE BANCO DE DADOS 
Fabrício Felipe Meleto Barboza
Evolução dos bancos 
de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar a evolução dos bancos de dados.
 � Reconhecer a ordem cronológica dos bancos de dados.
 � Explicar as origens dos bancos de dados.
Introdução
Um banco de dados é um conjunto de valores e arquivos que se relacio-
nam entre si e demonstram um cadastro de pessoas, vendas, produtos, 
agendas, etc. Por exemplo, uma planilha ou uma ficha cadastral podem ser 
exemplos de cadastros. O banco de dados guarda todos esses cadastros 
em formato virtual e os disponibiliza para as aplicações consultarem e 
emitirem relatórios, realizarem vendas, etc.
Neste capítulo, você vai estudar sobre a evolução dos bancos de 
dados decorrente das necessidades impostas por seus utilizadores e 
para solucionar problemas da sociedade. Adicionalmente, você verá, em 
uma escala de tempo, os principais marcos da história dos bancos de 
dados com suas características e particularidades. Por fim, irá conhecer 
o início de tudo, isto é, o que deu origem aos bancos de dados como 
são conhecidos hoje em dia.
A evolução dos bancos de dados
A evolução dos bancos de dados foi e continua sendo de constante melhoria, 
trazendo mais segurança e rapidez para as informações ou dados nele salvas. 
Para Korth, Silberschatz e Sudarshan (2012), um banco de dados “[...] é uma 
coleção de dados inter-relacionados, representando informações sobre um 
domínio específico”.
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Pense em uma situação hipotética em que você tenha uma loja de sapatos 
em um shopping. Você está verificando a implantação de um sistema para 
controlar todas as suas vendas e também as compras de reposição de estoque, 
de maneira que todas as informações da sua loja estarão salvas em um sistema 
no computador da loja que, obviamente, utiliza um banco de dados.
Agora imagine se o vendedor do sistema pedisse pra você escolher entre 1) 
um sistema rápido, que tira relatórios gigantescos em menos de um segundo, 
processa vendas também em menos de um segundo do relógio, mas, por outro 
lado, não garante que a informação está íntegra e consistente, e 2) um banco 
de dados que garante a integridade e a consistência das informações, mas 
demora dez segundos para processar alguma venda ou um minuto para criar 
o relatório complexo solicitado. Qual você, dono da loja, escolheria?
Lembre-se de que a evolução em sistemas de tecnologia da informação é importante, 
mas a segurança sempre deve vir em primeiro lugar para que, depois, possamos pensar 
em estabilidade, funcionalidade e velocidade.
Uma tendência da evolução comum é sempre mirar e colocar o foco e as 
metas em realizar a ação com mais e mais rapidez, cada vez provendo maior 
velocidade e resultados instantâneos para o usuário do sistema. Porém, ao 
decidir pela evolução de um sistema de banco de dados, é necessário pensar 
em outros fatores além da velocidade. Com toda a certeza, a velocidade é 
importante e sempre levada em consideração, mas os outros pilares precisam 
ser garantidos para toda transação de um banco de dados. Esses pilares são:
 � Atomicidade;
 � Isolamento;
 � Consistência;
 � Durabilidade.
Essas quatro características são garantidas para cada transação realizada 
no banco de dados, independentemente de quem realizou o comando: o próprio 
sistema, o usuário final ou ainda alguma rotina automática.
Evolução dos bancos de dados2
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Mas o que seria uma transação em um sistema de banco de dados? Uma 
transação para um sistema de gerenciamento de banco de dados (SGBD) é 
toda e qualquer atividade que o próprio sistema de gerenciamento de banco 
de dados executa após o usuário ter uma interação com o banco.
Assim, qualquer atividade provocada pelo usuário via interface do sistema 
dispara uma transação ou uma cadeia de transações no banco de dados que 
precisam estar garantidas e ter aderência a esses pilares. Consequentemente, 
essa é a regra de ouro dos bancos de dados.
A regra de ouro dos sistemas de gerenciamento de bancos de dados é a garantia de 
que todos os pilares das transações sejam assegurados e respeitados em cada uma 
de suas transações internas.
Sabendo disso, agora, é necessário entender o que cada um desses pilares 
representa, defende e significa para os bancos de dados.
Atomicidade
Para entender o pilar da atomicidade, fazemos uma analogia à expressão “08 
ou 80”, ou seja, ou finaliza com sucesso ou tudo é abortado. Portanto, ou o 
SGBD conclui todas as ações em cascata para uma transação (commit) ou ele 
retorna ao estado anterior da transação (rollback). 
Assim, a atomicidade é a responsável por garantir que ou uma transação 
é gravada com sucesso e garantida ou é realizado o rollback de toda a transa-
ção para que o banco de dados retorne ao estado anterior daquela transação. 
Nunca um sistema de gerenciamento de banco de dados pode permitir que 
uma transação seja executada pela metade e fique sem rollback, pois isso faz 
a consistência do banco de dados ficar quebrada.
Atomicidade é a regra do “ou tudo ou nada”. Ou toda a transação é salva com sucesso 
no banco ou toda a transação é descartada.
3Evolução dos bancos de dados
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Isolamento
Este pilar representa a independência de cada transação no sistema de gerencia-
mento de banco de dados. Cada transação é única e independente, o que faz com 
que duas transações que alterem o mesmo valor de uma tabela não entrem em 
conflito. Toda transação é uma engrenagem no sistema maior, que seria o SGBD.
Conforme o sistema tem mais usuários trabalhando nele, mais esta regra 
se torna verdadeira e necessária. Imagine um e-commerce que realiza venda 
de enfeites natalinos. Quando chegar a época de procura por esses enfeites, o 
fluxo de pessoas utilizando o sistema irá aumentar consideravelmente. Agora 
imagine que existe apenas um item de Papai Noel em estoque e dois clientes 
realizam a compra desse item no mesmo segundo; como resolver? O pilar de 
isolamento garante que a transação que for processada em primeiro lugar pelo 
sistema de gerenciamento de banco de dados leve a compra e que a segunda 
pessoa receba um alerta de que o produto ficou fora de estoque.
No exemplo, duas transações estavam tentando inserir dados referentes ao 
mesmo valor único, que seria a quantidade de estoque do produto. Por tratar-se 
de duas transações isoladas e independentes, o sistema de gerenciamento de 
banco de dados rapidamente resolve essa questão, de modo que tal responsa-
bilidade não fica para a equipe de desenvolvimento.
Isolamento é a garantia de que as transações não terão disputa para edição ou escrita 
em um determinado dado ou valor.
Consistência
As regras, em sua totalidade, sempre devem ser respeitadas para que o sistema 
de gerenciamento de banco de dados tenha atendido suas características de 
base. Isso inclui, por exemplo, que o tipo de valor inserido seja correto em 
relação ao tipo do seu atributo (VARCHAR, INT, DATE, etc.).
Assim, em face da consistência, um campo do tipo Integer nunca poderá 
receber caracteres alfabéticos. Essa separação se dá para a criação de buscas e 
resultados mais rápidos em campos do tipo numérico. Computadores só sabem 
interpretar números, de modo que campos não numéricos por natureza exigem 
Evolução dos bancos de dados4
Identificação interna do documento ITB70PPNV5-KNEPN9F2
mais processamento do computador, que precisa transformar a informação 
alfabética salva em códigos e linguagem de máquinas que são representados 
por números para conseguir trabalhar.
Consistência é ter o dado certo no local esperado. Um campo do tipo Integer sempre 
deverá conter um valor de número inteiro.
Durabilidade
Quando uma transação é finalizada, seus dados estão a salvo de qualquer 
modificação. Somente outra transação podemodificar os dados. Assim, os 
dados ficam protegidos!
Imagine que a sua compra foi finalizada com sucesso e, quando você vai buscar 
seu histórico de compras, ela não aparece. Ruim, correto? A durabilidade garante 
que a informação de sua compra só seja modificada por outra transação e, dessa 
forma, consegue-se rastrear as requisições e buscar o que ou quem fez tal atividade.
O próprio sistema de gerenciamento de banco de dados não realiza nenhuma 
modificação após a conclusão de todas as transações pendentes. Portanto, 
qualquer modificação de um valor do banco de dados será de origem do 
usuário ou do sistema.
Durabilidade é a proteção dos dados contra qualquer coisa que não seja uma nova 
transação do banco de dados.
Cronologia dos bancos de dados
Há divergência na ordem cronológica do surgimento das versões dos bancos 
de dados, exceto as versões mais comumente utilizadas. Observe a Figura 1, 
que representa as etapas mais importantes da evolução dos bancos de dados.
5Evolução dos bancos de dados
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Figura 1. Cronograma de evolução dos BDs.
Fonte: Adaptado de Castelano [200--]; Rezende (2006).
Utilização de modelos em rede e hierárquico diminui
A IBM utiliza o DB2
Primeiros bancos orientados a Objeto: O2 [1988], Exodus [1986], ORION [1986]
O desenvolvimento do IBM PC ocasiona o surgimento de muitos 
produtos em BD
Há a padronização do SQL pelo American National 
Standards Institute (ANSI) [1986, 1989]
Década de 80
Com base na Figura 1, percebe-se grande concentração de lançamentos e 
popularização dos bancos de dados no período compreendido entre os anos 
1980 até os 2000. Essa intensa movimentação se deu em virtude da infor-
matização das empresas, que aconteceu ao longo desses anos. Cada empresa 
precisou incrementar seu parque tecnológico para que atendesse seus objetivos 
internos, como redução de custo, melhora do valor da entrega ao cliente, ou 
também objetivos externos, como estar de acordo com uma nova lei, receber 
auditoria de órgãos competentes ou, ainda, pela concorrência, que está em 
franca evolução e em busca por melhores resultados a todo custo.
Antes da década de 1980, temos o estágio embrionário dos bancos de dados. 
Sua evolução estava ocorrendo, mas era centralizada em forma de pesquisas 
Evolução dos bancos de dados6
Identificação interna do documento ITB70PPNV5-KNEPN9F2
e experimentos. Até porque, quando fossem apresentados para as empresas e 
para o público geral, era necessário confiar no produto oferecido ao custo de 
milhões de dólares em pesquisas.
Após os anos 2000, a evolução continua até os dias atuais, mas de forma 
menos acelerada, já que o foco, atualmente, é em estabilidade e segurança 
cada vez maiores. Partindo desse princípio, temos o surgimento de bancos 
de dados NoSQL, que fazem frente aos tradicionais bancos de dados rela-
cionais SQL.
Retome a Figura 1 e atente-se para o quadrante “Anos 2000”, no qual você 
verá que foi nesse período que surgiu o MongoDB, banco de dados NoSQL (Not 
only SQL) e com grande poder de processamento. Aí você pode se perguntar: 
“mas se ele é melhor, por que todos não migram pra ele?”. A resposta é direta: 
custo e foco do projeto.
O banco de dados NoSQL não veio para matar os bancos de dados relacio-
nais como muitos imaginavam em seu lançamento, mas para complementar 
e oferecer uma opção a mais para as empresas e desenvolvedores segundo 
Guedes (2017).
Dessa forma, podemos exemplificar o uso de cada um dos tipos de bancos 
de dados de forma mais didática: caso a aplicação tenha relacionamentos entre 
as entidades e o volume de informações não for gigantesco, os bancos de dados 
relacionais tradicionais atenderão muito bem a sua demanda por um sistema.
Agora, caso você tenha um sistema de bancos de dados grandioso, com 
muitos valores sendo escritos e lidos ao mesmo tempo, a indicação é um banco 
de dados do tipo NoSQL para que o seu sistema ganhe em desempenho e não 
frustre os usuários com telas de “carregando”, erros de timeout de conexão 
ou ainda a negação de serviço por falta de recursos ao processar uma consulta 
gigante do gerente que trabalha remoto, impedindo de abrir a agenda de 
reuniões de outro funcionário.
Lembre-se também de que, por ser uma tecnologia mais nova, o custo 
para manter um banco de dados NoSQL é grande, até pela escassez de mão 
de obra qualificada no mercado de trabalho. Portanto, mensure esse custo ao 
tomar uma decisão sobre qual tipo de sistema de gerenciamento de bancos 
de dados utilizar no projeto.
Origens dos bancos de dados
Antigamente, as empresas produziam e mantinham cadastros de tudo que 
fosse necessário em fichas e papéis armazenados em um ou vários arquivos 
7Evolução dos bancos de dados
Identificação interna do documento ITB70PPNV5-KNEPN9F2
dentro de uma ou várias salas. Portanto, cliente, fornecedor, colabora-
dor, agendas de compromisso, agendas telefônicas, inventário, controle 
de estoque, etc. estavam em um papel, em algum lugar dentro de algum 
arquivo. 
Obviamente, organizar e manter tudo atualizado era uma tarefa complexa 
demais, pois envolvia um esforço muito grande para buscar informações 
básicas e que deveriam estar acessíveis para qualquer colaborador de forma 
instantânea.
Imagine que é necessário buscar todos os registros de ponto de entrada 
e saída de um colaborador que ficou durante vinte anos na empresa pois ele 
entrou com uma ação trabalhista, por exemplo. Agora imagine essa mesma 
situação e com um prazo de cinco dias para entregar toda essa informação ao 
Ministério do Trabalho. Impossível, certo?
Além disso, as informações contidas nesses papéis ficavam facilmente ob-
soletas em virtude da demora em atualizar o registro. Portanto, nada confiável.
Imagine a probabilidade de um desastre na sala de arquivos, como um cano 
de água rompido que encharque todos os registros da empresa. Com certeza, 
a empresa em questão teria sérios problemas ou, em um caso mais extremo, 
mas não descartado, até mesmo fecharia as portas se algo dessa magnitude 
acontecesse. 
Pode-se ir mais a fundo e imaginar que algum funcionário espião ou insa-
tisfeito com a empresa roube a informação de um projeto que iria ser lançado 
no próximo ano e a venda para a concorrência. Todo o esforço empregado na 
pesquisa e no desenvolvimento daquele projeto foi praticamente em vão, pois 
o elemento surpresa, para pegar o mercado no ponto certo e os concorrentes 
ficarem desequilibrados, foi perdido.
Sempre que um problema é detectado, ele deve ser resolvido logo por meio do 
fomento de ideias para o seu contorno ou para a criação de solução definitiva.
Pense que os bancos de dados só foram inventados porque existiu uma necessidade 
latente de diminuir despesas e melhorar a confiança nas informações salvas pela 
empresa com o passar dos anos.
Evolução dos bancos de dados8
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Dessa forma, havia um problema grande e generalizado em todas as cor-
porações em que registros eram feitos em papéis e armazenados em um lugar 
qualquer, muitas vezes sem a devida importância para o dado, para o registro 
ali contido. Como grandes problemas sugerem soluções altamente lucrativas, 
iniciou-se pesquisas que apresentassem uma solução para todo esse caos vi-
venciado em cada pequeno, médio ou grande escritório ou empresa no mundo.
Na década de 1960, surge uma solução para esse caos: o banco de dados. 
Vários modelos foram apresentados à IBM, financiadora do projeto, e, entre 
os modelos propostos, estavam o hierárquico e o de rede.
Apesar disso, nada muito usual ou com uma viabilidade de escala foi 
apresentado, o que fez os projetos serem engavetados.
Segundo Alves (2013), já na década de 1970, mais precisamente no mês 
de junho, o então pesquisador da IBM Edgar Frank “Ted” Codd apresentou 
um artigo que mudaria a história dos modelos de bancos de dados para 
sempre – ele estava propondo o modelo relacional de bancos de dados. 
Em seu artigo RelationalModel of Data for Large Shared Data Banks, 
Ted descrevia como usuários leigos conseguiriam extrair os dados que 
lhes eram importantes.
No raciocínio de Alves (2013), vemos que, já no fim da década de 1970, surge 
o Sistema R, um sistema baseado nas ideias de Ted. Junto ao lançamento do 
Sistema R, veio a linguagem SQL, acrônimo para Structured Query Language, 
a linguagem que dominou o mercado. O Sistema R não foi bem comercialmente 
e acabou sendo abandonado, mas serviu, com toda a certeza, de inspiração e 
base para muitos dos bancos de dados que temos nos dias de hoje.
Finalizando seu pensamento, Alves (2013) diz que, na década de 1980, 
ocorrem dois marcos importantes na linha cronológica dos bancos de dados: 
o lançamento do Oracle 2 pela própria Oracle e, também, o lançamento do 
SQL/DS pela IBM, conhecido por DB2 atualmente.
Portanto, temos aí a origem dos bancos de dados. Com o passar de mais 
anos e décadas, os sistemas de gerenciamento de bancos de dados foram 
evoluindo segundo a necessidade dos clientes, no caso de sistemas pagos, ou 
pela produção da comunidade, no caso de sistemas opensource. 
Aliás, uma curiosidade que também permeia este cenário de evolução: 
sempre que a comunidade dos sistemas de bancos de dados opensource lança 
algo inovador, as empresas que têm bancos de dados licenciados correm atrás e 
vice-versa. Com isso, muitas funcionalidades que estão presentes em sistemas 
de bancos de dados opensource também se tornam presentes nos sistemas 
proprietários, assim como o inverso.
9Evolução dos bancos de dados
Identificação interna do documento ITB70PPNV5-KNEPN9F2
A aplicação de cada sistema de banco de dados se dará pela escolha cru-
cial de quem irá desenvolver baseado no orçamento e conhecimento daquela 
tecnologia de banco de dados específica para otimizar o tempo do projeto e 
também o seu custo.
Lembre-se de quem fez a pesquisa para obter os bancos de dados relacionais que 
conhecemos hoje: Edgar Frank “Ted” Codd, pesquisador da IBM na época e que lançou o 
artigo intitulado Relational Model of Data for Large Shared Data Banks. Ted é considerado 
o pai dos bancos de dados relacionais.
ALVES, G. F. O. A história dos bancos de dados. 01 abr. 2013. Disponível em: <https://dicas-
deprogramacao.com.br/a-historia-dos-bancos-de-dados/>. Acesso em: 21 maio 2018.
CASTELANO, C. R. História dos bancos de dados. [20--] Disponível em: http://castelano.
com.br/site/aulas/bd/Aula%2001%20-%20Introdu%C3%A7%C3%A3o.pdf. Acesso 
em: 23 jun. 2021.
GUEDES, M. SQL vs NoSQL, qual usar? 19 jul. 2017. Disponível em: <https://www.treina-
web.com.br/blog/sql-vs-nosql-qual-usar/>. Acesso em: 21 maio 2018.
KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de banco de dados. 6. ed. Rio 
de Janeiro: Campus, 2012.Leituras recomendadas
CODD, E. F. A Relational Model of Data for Large Shared Data Banks. Communications 
of the ACM, v. 13, n. 06, June 1970.
REZENDE, R. A história dos bancos de dados. 2006. Disponível em: https://www.dev-
media.com.br/a-historia-dos-banco-de-dados/1678. Acesso em: 23 jun. 2021.
REZENDE, R. Conceitos fundamentais de banco de dados. 2017. Disponível em: <https://
www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso 
em: 21 maio 2018.
Evolução dos bancos de dados10
Identificação interna do documento ITB70PPNV5-KNEPN9F2
Sistemas de Gerenciamento Sistemas de Gerenciamento 
de Banco de Dadosde Banco de Dados
Ramakrishnan • Gehrke
Tradução daTradução da
Terceira EdiçãoTerceira Edição
SISTEMAS DE GERENCIAMENTO 
DE BANCO DE DADOS
2011
Versão impressa
desta obra: 2008
Raghu Ramakrishnan
University of Wisconsin
Madison, Wisconsin, USA
Tradução da Terceira Edição
Johannes Gehrke
Cornell University
Ithaca, New York, USA
Tradução
Célia Taniwake
João Eduardo Nóbrega Tortello
Revisão Técnica
Elaine Parros Machado de Sousa
Professora Doutora do Departamento de Ciências de Computação — 
Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo
2
Reparou que todas as letras da palavra database (banco de dados, em inglês) são 
digitadas com a mão esquerda? Sabemos que a disposição do teclado da máquina de 
escrever (QWERTY) foi projetada, entre outras coisas, para facilitar o uso uniforme 
de ambas as mãos. Conclui-se, então, que escrever sobre bancos de dados, além de ser 
algo não natural, é bem mais difícil do que parece.
— Anônimo
A quantidade de informações que nos são disponíveis está literalmente explodindo, e o 
valor dos dados como um ativo organizacional é amplamente reconhecido. Para obter 
a maior parte de seus grandes e complexos conjuntos de dados, os usuários necessitam 
de ferramentas que simplifiquem as tarefas de gerenciamento dos dados e a extração 
de informações úteis de forma oportuna. Caso contrário, os dados podem se tornar 
1
VISÃO GERAL SOBREVISÃO GERAL SOBRE
SISTEMAS DE BANCO DE DADOSSISTEMAS DE BANCO DE DADOS
O que é um SGBD, em particular, um SGBD relacional?
Por que devemos utilizar um SGBD para gerenciar dados?
Como os dados da aplicação são representados em um SGBD?
Como os dados em um SGBD são recuperados e manipulados?
Como um SGBD suporta o acesso concorrente e protege os dados na ocorrência 
de falhas no sistema?
Quais são os principais componentes de um SGBD?
Quem está envolvido com bancos de dados na vida real?
 Conceitos-chave: gerenciamento de banco de dados, independência de dados, pro-
jeto de banco de dados, modelo de dados; bancos de dados e consultas relacionais; 
esquemas, níveis de abstração; transações, concorrência e bloqueio, recuperação e 
registro em log; arquitetura de um SGBD; administrador de um banco de dados, 
programador do aplicativo, usuário final.
☛
☛
☛
☛
☛
☛
☛
➽
Visão Geral sobre Sistemas de Banco de Dados 3
um passivo, cujo custo de aquisição e gerenciamento excede em muito o valor por ele 
produzido.
Um banco de dados é uma coleção de dados que, tipicamente, descreve as ativida-
des de uma ou mais organizações relacionadas. Por exemplo, um banco de dados de 
uma universidade poderia conter informações sobre:
Entidades como alunos, professores, cursos e turmas.
Relacionamentos entre as entidades, como a matrícula dos alunos nos cursos, cur-
sos ministrados pelos professores, e o uso de salas por cursos.
Um sistema de gerenciamento de banco de dados, ou SGBD, é um software proje-
tado para auxiliar a manutenção e utilização de vastos conjuntos de dados. A neces-
sidade de tais sistemas, assim como seu uso, tem crescido rapidamente. A alternativa 
para não se usar um SGBD é armazenar os dados em arquivos e escrever código es-
pecífico do aplicativo para gerenciá-los. O uso de um SGBD tem diversas vantagens 
importantes, como veremos na Seção 1.4.
1.1 GERENCIANDO DADOS
O objetivo deste livro é apresentar uma introdução detalhada dos sistemas de geren-
ciamento de banco de dados, com ênfase em como projetar um banco de dados e como 
usar efetivamente um SGBD. Naturalmente, várias decisões sobre como utilizar um 
SGBD para um determinado aplicativo dependem de quais recursos o SGBD suporta 
de forma eficiente. Assim, para aproveitar bem um SGBD, é necessário compreender 
também como ele funciona.
Diversos tipos de sistemas de gerenciamento de banco de dados estão em uso, mas 
este livro concentra-se nos sistemas de banco de dados relacionais (SGBDRs), que com 
certeza constituem o tipo dominante de SGBD nos dias atuais. As seguintes questões 
são tratadas nos capítulos principais deste livro: 
1. Projeto de Banco de Dados e Desenvolvimento de Aplicativo: Como um usuário 
pode descrever uma empresa do mundo real (por exemplo, uma universidade) 
em termos dos dados armazenados em um SGBD? Que fatores devem ser con-
siderados ao decidir sobre a forma de organização dos dados armazenados? 
Como podemos desenvolver aplicativos que dependem de um SGBD? (Capítulos 
2, 3, 6, 7, 19, 20 e 21.)
■
■
A área de sistemas de gerenciamento de dados é um microcosmo da Ciên-
cia da Computação em geral. Os aspectos tratadose as técnicas utilizadas 
abrangem um amplo espectro, incluindo linguagens, orientação a objeto e ou-
tros paradigmas de programação, compilação, sistemas operacionais, progra-
mação concorrente, estruturas de dados, algoritmos, teoria, sistemas distri-
buídos e paralelos, interfaces do usuário, sistemas especialistas e inteligência 
artificial, técnicas estatísticas e programação dinâmica. Não podemos tratar 
todos esses aspectos de gerenciamento de banco de dados em um livro, mas 
esperamos prover ao leitor um sentido de investigação nesta disciplina rica 
e vibrante.
4 CAPÍTULO 1
2. Análise dos Dados: Como um usuário pode responder a dúvidas sobre a empresa 
formulando consultas sobre os dados do SGBD? (Capítulos 4 e 5.)1
3. Concorrência e Robustez: Como um SGBD permite que vários usuários acessem os 
dados de forma concorrente, e como ele protege os dados na ocorrência de falhas do 
sistema? (Capítulos 16, 17 e 18.)
4. Eficiência e Escalabilidade: Como um SGBD armazena grandes conjuntos de dados 
e responde a questões sobre esses dados de forma eficiente? (Capítulos 8, 9, 10, 11, 
12, 13, 14 e 15.)
Os capítulos posteriores abrangem tópicos importantes que estão evoluindo rapida-
mente, como o gerenciamento de banco de dados distribuído e paralelo, armazenagem 
de dados e consultas complexas para apoio à decisão, mineração de dados, recuperação 
de banco de dados e informações, repositórios XML, banco de dados orientado a obje-
tos, gerenciamento de dados espaciais, e extensões de SGBD orientado a regras.
No restante deste capítulo, introduziremos estes tópicos. Na Seção 1.2, começamos 
com uma breve história da área e uma discussão do papel do gerenciamento de banco 
de dados nos sistemas de informações modernos. Identificaremos, então, os benefícios 
de armazenar os dados em um SGBD em vez de em um sistema de arquivos, na Se-
ção 1.3, e, na Seção 1.4, discutiremos as vantagens de usar um SGBD para gerenciar 
dados. Na Seção 1.5, apresentaremos como as informações sobre uma empresa devem 
ser organizadas e armazenadas em um SGBD. Um usuário provavelmente pensa sobre 
as informações num alto nível, que corresponde às entidades da organização e seus rela-
cionamentos, enquanto o SGBD basicamente armazena os dados na forma de (vários e 
vários) bits. A lacuna existente entre como os usuários pensam sobre seus dados e como 
os dados são definitivamente armazenados é preenchida através de diversos níveis de 
abstração suportados pelo SGBD. Intuitivamente, um usuário pode começar descreven-
do os dados em termos totalmente de alto nível, e depois melhorar a descrição conside-
rando o armazenamento adicional e detalhes de representação conforme necessário.
Na Seção 1.6, consideraremos como os usuários podem recuperar os dados armaze-
nados em um SGBD e a necessidade de técnicas para processar eficientemente respos-
tas às consultas envolvendo tais dados. Na Seção 1.7, forneceremos uma visão geral 
sobre como um SGBD suporta o acesso concorrente aos dados por diversos usuários e 
como ele protege os dados na ocorrência de falhas do sistema.
Descreveremos, então, brevemente, a estrutura interna de um SGBD na Seção 1.8, 
e, na Seção 1.9, mencionaremos vários grupos de pessoas associadas com o desenvolvi-
mento e uso de um SGBD.
1.2 UMA PERSPECTIVA HISTÓRICA
Desde os primeiros computadores, armazenar e manipular dados têm sido o principal 
foco dos aplicativos. O primeiro SGBD de propósito geral, projetado por Charles Ba-
chman, na General Electric, no início da década de 1960, foi chamado Depósito de Da-
dos Integrados (Integrated Data Store). Ele constituiu a base do modelo de dados de 
rede, que foi padronizado pela Conference on Data Systems Languages (CODASYL) 
e influenciou bastante os sistemas de banco de dados na década de 1960. Bachman foi 
o primeiro a ser contemplado pelo Prêmio Turing da ACM (o equivalente ao Prêmio 
Nobel na Ciência da Computação) pelo trabalho na área de banco de dados; ele rece-
beu o prêmio em 1973.
1 Um capítulo on-line sobre Consulta por Exemplo (QBE — Query-by-Example) também está disponível. 
Veja mais informações no Prefácio.
Visão Geral sobre Sistemas de Banco de Dados 5
No final da década de 1960, a IBM desenvolveu o SGBD Sistema de Gerenciamento 
de Informação (IMS — Information Management System), ainda usado atualmente 
em diversas instalações. O IMS constituiu a base da estrutura de representação al-
ternativa de dados, chamada modelo de dados hierárquico. O sistema SABRE para 
reservas de passagens aéreas foi desenvolvido em conjunto pela American Airlines e 
pela IBM nessa mesma época, e permitiu que diversas pessoas acessassem os mesmos 
dados através de uma rede de computadores. Interessante observar que, atualmente, o 
mesmo sistema SABRE é utilizado para fornecer serviços populares de viagens basea-
dos na Web, tais como o Travelocity.
Em 1970, Edgar Codd, do Laboratório de Pesquisa de San Jose, da IBM, propôs 
uma nova estrutura de representação de dados chamada modelo de dados relacional, 
que veio a ser um marco histórico no desenvolvimento de sistemas de banco de da-
dos. Ele impulsionou o rápido desenvolvimento de vários SGBDs baseados no modelo 
relacional, juntamente com um rico conjunto de resultados teóricos que consolidaram 
firmemente a área. Codd ganhou o Prêmio Turing de 1981 pelo seu trabalho original. 
Os sistemas de banco de dados amadureceram como uma disciplina acadêmica, e a 
popularidade dos SGBDs relacionais alterou o cenário comercial. Seus benefícios fo-
ram amplamente reconhecidos, e o uso de SGBDs para gerenciar dados corporativos 
tornou-se uma prática padrão.
Na década de 1980, o modelo relacional consolidou sua posição como o paradigma 
dominante de SGBD, e o uso dos sistemas de banco de dados continuou a se difundir 
cada vez mais. A linguagem de consulta SQL para banco de dados relacional, desen-
volvida como parte do projeto System R, da IBM, passou a ser a linguagem de consul-
ta padrão. A SQL foi padronizada no final dos anos 80, e o padrão atual, SQL:1999 foi 
adotado pelo American National Standards Institute (ANSI) e pela International Or-
ganization for Standardization (ISO). É possível argumentar que a forma mais ampla-
mente utilizada de programação concorrente é a execução concorrente de programas 
de banco de dados (chamados transações). Os usuários escrevem os programas como 
se eles fossem executar isoladamente, e a responsabilidade de executá-los de forma 
concorrente é atribuída ao SGBD. James Gray ganhou o Prêmio Turing de 1999 pelas 
suas contribuições ao gerenciamento de transações de banco de dados.
No final da década de 1980 e na década de 1990, houve avanços em diversas áreas 
dos sistemas de banco de dados. Pesquisas consideráveis foram conduzidas para desen-
volver linguagens de consulta mais poderosas e modelos de dados mais ricos, com ênfa-
se no suporte à análise complexa de dados provenientes de todas as áreas da empresa. 
Diversos fabricantes (como o DB2 da IBM, Oracle 8, Informix2 UDS) estenderam seus 
sistemas com a capacidade de armazenar novos tipos de dados, como imagens e texto, 
e a possibilidade de consultas mais complexas. Sistemas especializados têm sido desen-
volvidos por inúmeros fabricantes para criação de data warehouses, consolidando os 
dados de diversos bancos de dados, com o intuito de conduzir análise especializada.
Um fenômeno interessante é a emergência de diversos pacotes de planejamento de 
recurso empresarial (ERP — enterprise resource planning) e de planejamento de re-
curso de gerenciamento (MRP — management resource planning), que acrescentaram 
uma camada substancial de recursos orientados a aplicativos acima de um SGBD. Os 
pacotes largamente utilizados incluem sistemas da Baan, Oracle, PeopleSoft, SAP 
e Siebel. Esses pacotes identificam um conjunto de tarefas comuns (por exemplo, 
gerenciamento de inventário, planejamento de recursos humanos, análise financeira) 
desempenhadas por um grande número de organizações e fornecem uma camada de 
aplicativogenérica para realizar essas tarefas. O dado é armazenado em um SGBD 
2 A Informix foi recentemente adquirida pela IBM.
6 CAPÍTULO 1
relacional, e a camada de aplicativo pode ser customizada para empresas diferentes, 
diminuindo os custos totais para as organizações, comparados ao custo de criar uma 
camada de aplicativo a partir do zero.
O fato histórico mais significativo, talvez, seja a entrada dos SGBDs na Era Inter-
net. Enquanto a primeira geração de web sites armazenava seus dados exclusivamente 
em arquivos dos sistemas operacionais, o uso de um SGBD para armazenar dados 
acessados através de um navegador Web tem se difundido cada vez mais. As consultas 
são geradas através de formulários acessíveis na Web e as respostas são formatadas 
usando uma linguagem de marcação como o HTML para serem facilmente exibidas em 
um navegador. Todos os fabricantes de banco de dados estão acrescentando recursos 
aos seus SGBDs com o objetivo de torná-los mais adequados para desenvolvimento 
para Internet.
O gerenciamento de banco de dados continua a ganhar importância conforme mais 
e mais dados tornam-se disponíveis on-line e ainda ma is acessíveis através da rede 
de computadores. Atualmente, a área está sendo impulsionada por ideais excitantes. 
Entre eles temos: banco de dados multimídia, vídeo interativo, fluxos de dados, biblio-
tecas digitais, um hospedeiro de projetos científicos, como o esforço de mapeamento 
do genoma humano, e o projeto de Sistema de Observação Terrestre da NASA, além 
do desejo das empresas de consolidar seus processos de tomada de decisão e minerar 
seus repositórios de dados por informações úteis sobre seus negócios. Comercialmente, 
os sistemas de gerenciamento de banco de dados representam um dos maiores e mais 
ativos segmentos de mercado. Assim, o estudo de sistemas de banco de dados pode vir 
a ser ricamente gratificante e não apenas de uma maneira, mas de várias!
1.3 ARQUIVOS DE SISTEMAS VERSUS UM SGBD
Para compreendermos a necessidade de um SGBD, consideremos um cenário motiva-
dor: uma empresa tem uma grande coleção (digamos 500 GB3) de dados sobre os fun-
cionários, departamentos, produtos, vendas e assim por diante. Esse dado é acessado 
concorrentemente por diversos funcionários. As consultas sobre os dados devem ser 
respondidas rapidamente, as alterações realizadas nos dados pelos diferentes usuários 
devem ser aplicadas consistentemente, e o acesso a determinadas partes dos dados 
(por exemplo, salários) deve ser restrito.
Podemos experimentar gerenciar os dados armazenando-os em arquivos do sistema 
operacional. Essa abordagem tem várias desvantagens, que incluem:
Provavelmente, não teremos 500 GB de memória principal para armazenar todos os 
dados. Devemos, então, armazenar os dados em um dispositivo de armazenamento, 
como disco ou fita, e carregar partes relevantes dos dados na memória principal 
conforme necessário.
Mesmo que tivéssemos 500 GB de memória principal, num sistema computacional 
de 32 bits de endereçamento, não podemos nos referir diretamente a mais do que 
aproximadamente 4 GB de dados. Temos que programar algum método de identi-
ficação de todos os itens de dados.
Devemos escrever programas especiais para responder a cada pergunta que um 
usuário pode desejar fazer sobre os dados. Esses programas provavelmente serão 
complexos em razão do grande volume de dados a ser pesquisado.
3 Um kilobyte (KB) são 1024 bytes, um megabyte (MB) são 1024 KBs, um gigabyte (GB) são 1024 MBs, 
um terabyte (TB) são 1024 GBs, e um petabyte (PB) são 1024 terabytes.
■
■
■
Visão Geral sobre Sistemas de Banco de Dados 7
Devemos proteger os dados de alterações inconsistentes realizadas por usuários 
diferentes acessando os dados de forma concorrente. Se os aplicativos devem tratar 
dos detalhes desse acesso concorrente, isto aumenta significativamente a sua com-
plexidade.
Devemos assegurar que os dados sejam restaurados a um estado consistente se o 
sistema falhar enquanto as alterações estão sendo realizadas.
Os sistemas operacionais provêm apenas um mecanismo de senha para segurança. 
Isso não é suficientemente flexível para reforçar as políticas de segurança nas quais 
usuários diferentes têm permissão de acessar subconjuntos diferentes dos dados.
Um SGBD é um pacote de software projetado para executar mais facilmente as 
tarefas mencionadas anteriormente. Armazenando-se dados em um SGBD em vez de 
em uma coleção de arquivos do sistema operacional, é possível utilizar os recursos do 
SGBD para gerenciar os dados de uma forma robusta e eficiente. À medida que cresce 
o volume de dados e o número de usuários — centenas de gigabytes de dados e milha-
res de usuários são comuns nos bancos de dados corporativos atuais —, o suporte de 
um SGBD torna-se indispensável.
1.4 VANTAGENS DE UM SGBD 
Usar um SGBD para gerenciar dados tem várias vantagens:
Independência de Dados: Os programas aplicativos não devem, idealmente, ser 
expostos aos detalhes de representação e armazenamento de dados. O SGBD provê 
uma visão abstrata dos dados que oculta tais detalhes.
Acesso Eficiente aos Dados: Um SGBD utiliza uma variedade de técnicas sofisti-
cadas para armazenar e recuperar dados eficientemente. Este recurso é especial-
mente importante se os dados são armazenados em dispositivos de armazenamen-
to externos.
Integridade e Segurança dos Dados: Se os dados são sempre acessados através 
do SGBD, ele pode forçar restrições de integridade. Por exemplo, antes de in-
serir informações sobre o salário de um funcionário, o SGBD pode verificar se o 
orçamento do departamento não está se excedendo. Além disso, ele pode forçar 
controles de acesso que governam quais dados estão visíveis a diferentes classes 
de usuários.
Administração de Dados: Quando diversos usuários compartilham dados, cen-
tralizar a administração dos dados pode oferecer melhorias significativas. Profis-
sionais experientes que compreendem a natureza dos dados sendo gerenciados, e 
como os diferentes grupos de usuários os utilizam, podem ser responsáveis por 
organizar a representação dos dados para minimizar a redundância e para realizar 
as sintonizações finas do armazenamento dos dados para garantir uma eficiente 
recuperação.
Acesso Concorrente e Recuperação de Falha: Um SGBD planeja o acesso concor-
rente aos dados de maneira tal que os usuários podem achar que os dados estão 
sendo acessados por apenas um único usuário de cada vez. Além disso, o SGBD 
protege os usuários dos efeitos de falhas de sistema.
Tempo Reduzido de Desenvolvimento de Aplicativo: Obviamente, o SGBD supor-
ta funções importantes que são comuns a vários aplicativos que acessam os dados 
no SGBD. Isso, em conjunto com uma interface de alto nível aos dados, facilita 
o desenvolvimento rápido de aplicativos. Os aplicativos de SGBD tendem a ser 
■
■
■
■
■
■
■
■
■
8 CAPÍTULO 1
mais robustos do que os aplicativos similares independentes porque muitas tarefas 
importantes são tratadas pelo SGBD (e não precisam ser depuradas e testadas no 
aplicativo).
Dadas todas essas vantagens, há alguma razão para não se utilizar um SGBD? Al-
gumas vezes, sim. Um SGBD é um software complexo, otimizado para alguns tipos de 
processamento (por exemplo, responder a consultas complexas ou tratar várias requisi-
ções concorrentes), e seu desempenho pode não ser adequado para determinados apli-
cativos especializados. Exemplos incluem aplicativos com restrições rígidas de tempo 
real ou algumas operações críticas bem definidas para as quais um código customizado 
eficiente deve ser escrito. Uma outra razão para não se utilizar um SGBD é que o apli-
cativo pode precisar manipular os dados de maneiras não suportadas pela linguagem 
de consulta. Em tais casos, a visualização abstrata dos dados apresentada pelo SGBD 
pode não corresponder às necessidades do aplicativo e realmente impossibilitar o seu 
uso. Como um exemplo, os bancos de dados relacionais não suportam a análise flexível 
de dados textuais (embora os fabricantes estejamatualmente estendendo seus produtos 
nesta direção).
Se o desempenho especializado ou solicitações de manipulação de dados são essen-
ciais num aplicativo, pode-se optar por não utilizar um SGBD, especialmente se os 
benefícios de um SGBD (por exemplo, consulta flexível, segurança, acesso concorrente 
e recuperação de falha) não forem exigidos. Entretanto, na maioria das situações 
em que é necessário gerenciamento de dados em grande escala, os SGBDs têm se 
tornado uma ferramenta indispensável.
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra. 
ADMINISTRAÇÃO 
DE BANCO DE 
DADOS
Márcio Motta
4
OBJETIVOS DE APRENDIZAGEM 
Ao final deste texto, você deve apresentar os seguintes aprendizados:
• Identificar os desafios da administração de banco de dados.
• Conhecer comandos que auxiliam na administração do banco de dados.
• Reconhecer as técnicas de administração de banco de dados.
INTRODUÇÃO
O banco de dados é um dos elementos da administração de um ambiente de 
informação. Para um usuário final a organização do banco de dados é invisível, 
apenas aparecendo os seus resultados quando este é bem formatado 
e executado. No caso de problemas, o usuário final identificará dados 
inconsistentes ou problemas com a sua performance, mas não visualizando 
o banco de dados em si.
Três áreas continuam a ser os maiores desafios de gerenciamento para os 
administradores de banco de dados. São elas.
TECNOLOGIAS
Nos últimos anos, o surgimento de forças, como a TI híbrida, virtualização, 
computação em nuvem, convergência continuada de infraestrutura e BYOD 
(traga seu próprio dispositivo) ofereceram aos profissionais de tecnologia 
novas formas de trabalhar, revolucionando o modelo tradicional até então 
praticado na área. A expectativa é de que as pessoas que trabalham nessa 
área consigam colocar em prática conceitos e tendências tecnológicas, como 
bancos de dados embutidos, Internet das Coisas (IoT) e Cloud Computing, mas 
sem deixar de lado as habilidades de gerenciar tecnologias e infraestruturas 
tradicionais.
Cabe ao Administrador de Banco de Dados e sua equipe considerarem as 
possibilidades para então definir o uso de SGBD físico ou a utilização de um 
serviço na nuvem, sobre essa decisão pesarão diversos fatores que deverão ser 
analisados antes de tomar uma decisão final. O mesmo vale para o tipo de SGBD 
escolhido de acordo com as suas características, funções, desempenho e custos.
5
Com sua promessa de economia de custos e maior flexibilidade e agilidade, 
a Nuvem está atraindo muitas organizações como uma alternativa para 
a implantação de novos aplicativos, incluindo aqueles com altos requisitos 
de desempenho de banco de dados. Entretanto, essa transição cria novas 
complexidades e desafios para os DBAs, especialmente porque os DBAs 
ainda são, em última análise, os responsáveis tanto pelo desempenho dos 
bancos de dados quanto pela segurança dos dados, independentemente de 
eles estarem nas próprias instalações ou na nuvem.
São algumas considerações para o gerenciamento dos dados na nuvem que 
os DBAs devem ponderar antes de sua escolha:
• Ao considerar quais bancos de dados são migrados para a nuvem, levar 
em conta o processo de transferência de dados e a latência, além de como 
manter os bancos de dados em sincronia, se necessário, especialmente se 
for preciso integrar os aplicativos com outros que não residam na mesma 
implantação na nuvem.
• Um banco de dados com desempenho insatisfatório nas instalações 
também apresentará um mau desempenho na nuvem. Mudar o problema de 
lugar não é solução. O escalonamento na nuvem para compensar um mau 
desempenho pode sair caro rapidamente, além de ser a abordagem incorreta.
• Entender os serviços e as capacidades do provedor de serviços, avaliar a 
arquitetura recomendada e estar atento à manutenção programada.
• Refletir, planejar e gerencar o backup e recuperação para garantir que 
dados importantes não sejam perdidos caso ocorra uma falha ou interrupção 
no fornecedor.
• Mantenha-se à frente da segurança, percebendo que a criptografia é 
apenas a ponta do iceberg – considere quem monitorará o acesso ao banco 
de dados impedindo o acesso mal-intencionado ou não autorizado, prepare-
se para o pior e tenha um plano de ação documentado para o caso de violação 
da segurança ou perda de dados.
• Se é importante monitorar e otimizar as implantações nas instalações, 
isso é ainda mais importante na nuvem, dada sua natureza dinâmica, sendo 
ideal usar um conjunto de ferramentas consistente em ambos os lados dos 
ambientes de TI híbrida.
6
A Figura 1 a seguir procura relatar o ranking dos SGBDs mais utilizados e 
traçar uma relação entre as suas tecnologias:
Figura nº 1 – Ranking dos SGBDs
 
Fonte: Austrian IT Consulting, disponível em: http://db-engines.com/en/ 
Acesso em: 28/05/2017
Nas 4 primeiras posições desse ranking são vistos 2 modelos de SGBDs de 
licença proprietária (Oracle e SQL Server) e 2 de licença Open Source (Livre, de 
código aberto, MySQL e MondoDB). O MondoDB vem em forte crescimento 
no mercado mundial, ocupando já a quarta posição superando o também 
bastante utilizado PostreSQL. Um dos motivos dessa ascensão é o fato do 
MongoDB não trabalhar com o modo Relacional de tabelas como os outros 
SGBDs, mas com um sistema de Índices também conhecido como NO-SQL.
PERFORMANCE
A performance do banco de dados é um fator de grandes desafios para o BDA. 
O conjunto que envolve Hardware+Sistema+SGBD deve estar equacionado 
para uma performance satisfatória. Porém, conforme o crescimento e a 
demanda das informações armazenadas essa tarefa torna-se cadê vez 
mais complexa. Muitas vezes a escolha inicial de infraestrutura pode não 
ser mais suficiente, não atendendo as demandas necessárias necessitando 
de migração ou atualização, ou a sua manutenção e configuração não 
7
estão ocorrendo de forma organizada e coerente com as necessidades da 
plataforma, causando transtornos e inconsistências.
A modelagem dos dados e a construção de consultas otimizadas são 
extremamente importantes no desempenho do banco de dados. Campos mal 
definidos, com tamanhos de dados equivocados tanto para textos quanto 
para números são determinantes para a performance, toda a definição dos 
dados (DDL) deve ser dimensionada para o tipo de dado que cada registro 
receberá. O mesmo vale para a organização das consultas. Índices e 
constraints (restrições) já devem ser criados na etapa de definição para que 
possam ser utilizadas de forma ágil durante a manipulação dos dados(DML) 
com consultas simplificadas e de resultados diretos. Muitas vezes uma 
base possui milhares ou até milhões de registros, se uma consulta não for 
restrita ao que se deseja, o tempo de espera poderá ser bastante demorado, 
prejudicando todo o sistema.
Uma das formas de monitorar o desempenho de um SGBD (MySQL neste 
exemplo) é através da ferramenta MYTOP (Linux/Open Source). Para usá-la é 
necessário executar o comando:
mytop -u <usuario> -p <senha> -h <host>
Ao executá-lo, serão mostradas todas as informações dos bancos de dados 
armazenados assim como os tempos de acesso e possíveis problemas, como 
são apresentados na Figura 2 abaixo:
Figura nº 2 – Tela do MyTOP no Linux
Fonte: autor
8
Um erro bastante comum é se preocupar com segurança e desempenho 
apenas diante da reclamação dos usuários de um dado alterado indevidamente 
ou lentidão na utilização do sistema, pois um monitoramento pontual não 
terá fundamento para mostrar que o banco de dados não é o culpado. É 
necessário monitoramento e relatórios constantes que auxiliem o DBA a 
identificar gargalos, tomando as ações necessárias preventivamente, ou 
mesmo comprovando que o problema não está no banco de dados, podendo 
direcionar o tratamento do problema para o local correto.
SEGURANÇA
A preocupação com a criação e manutenção de ambientes seguros se tornou 
a ocupação principalde administradores de redes, de sistemas operacionais 
e de bancos de dados. Pesquisas mostram que a maioria dos ataques, 
roubos de informações e acessos não- autorizados são feitos por pessoas 
que pertencentes à organização alvo. De modo geral, os mecanismos de 
segurança referem-se às regras impostas pelo subsistema de segurança do 
SGBD, que verifica todas as solicitações de acesso, comparando-as com as 
restrições de segurança armazenadas no catálogo do sistema. Entretanto 
existem brechas no sistema e ameaças externas que podem resultar em um 
servidor de banco de dados comprometido ou na possibilidade de destruição 
ou no roubo de dados confidenciais.
As ameaças aos bancos de dados podem resultar na perda ou degradação de 
alguns ou de todos os objetivos de segurança aceitos, são eles: integridade, 
disponibilidade, confidencialidade. A integridade do banco de dados se refere 
ao requisito de que a informação seja protegida contra modificação imprópria.
Os bancos de dados SQL implementam mecanismos que restringem ou 
permitem acessos aos dados de acordo com papeis ou roles fornecidos 
pelo administrador. O comando GRANT concede privilégios específicos para 
um objeto (tabela, visão, seqüência, banco de dados, função, linguagem 
procedural, esquema ou espaço de tabelas) para um ou mais usuários ou 
grupos de usuários.
São tipos de controles que podem ser implementados para garantir maior 
segurança nos bancos de dados:
9
Controle de Acesso
É todo controle feito quanto ao acesso ao BD, impondo regras de restrição, 
através das contas dos usuários. O DBA é o responsável superior por declarar 
as regras dentro do SGBD. Ele é o responsável por conceder ou remover 
privilégios, criar ou excluir usuários, e atribuição de um nível de segurança 
aos usuários do sistema, de acordo com a política da empresa.
Controle de Inferência
É um mecanismo de segurança para banco de dados estatísticos que atua 
protegendo informações estatísticas de um individuo ou de um grupo. Bancos 
de dados estatísticos são usados principalmente para produzir estatísticas 
sobre várias populações. O banco de dados pode conter informações 
confidenciais sobre indivíduos. Os usuários têm permissão apenas para 
recuperar informações estatísticas sobre populações e não para recuperar 
dados individuais, como, por exemplo, a renda de uma pessoa específica.
Controle de Fluxo
É um mecanismo que previne que as informações fluam por canais secretos 
e violem a política de segurança ao alcançarem usuários não autorizados. 
Ele regula a distribuição ou fluxo de informação entre objetos acessíveis. Um 
fluxo entre o objeto A e o objeto B ocorre quando um programa lê valores de 
A e escreve valores em B. Os controles de fluxo têm a finalidade de verificar se 
informações contidas em alguns objetos não fluem explicita ou implicitamente 
para objetos de menor proteção. Dessa maneira, um usuário não pode obter 
indiretamente em B aquilo que ele ou ela não puder obter diretamente de A.
Criptografia de Dados
Você pode ler aqui um pouco mais sobre criptografia. É uma medida de 
controle final, utilizada para proteger dados sigilosos que são transmitidos 
por meio de algum tipo de rede de comunicação. Ela também pode ser 
usada para oferecer proteção adicional para que partes confidenciais de um 
banco de dados não sejam acessadas por usuários não autorizados. Para 
isso, os dados são codificados através da utilização de algum algoritmo de 
codificação. Assim, um usuário não autorizado terá dificuldade para decifrá-
los, mas os usuários autorizados receberão chaves para decifrar esses dados. 
A criptografia permite o disfarceda mensagem para que, mesmo com o desvio 
da transmissão, a mensagem não seja revelada.
10
Privilégios
Os privilégios são permissões únicas dadas a cada usuário ou grupo. Eles 
definem permissões para tipos de autorização. Pelos privilégios é possível 
autorizar o usuário a modificar ou alcançar determinado recurso do Banco de 
Dados.
O SGBD deve oferecer acesso seletivo a cada relação do banco de dados 
baseando-se em contas específicas. As operações também podem ser 
controladas; assim, possuir uma conta não necessariamente habilita o 
possuidor a todas as funcionalidades oferecidas pelo SGBD. Informalmente 
existem dois níveis para a atribuição de privilégios para o uso do sistema de 
banco de dados:
• Nível de conta: Nesse nível, o DBA estabelece os privilégios 
específicos que cada conta tem, independente das relações no banco 
de dados.
• Nível de relação (ou tabela): Nesse nível, o DBA pode controlar o 
privilégio para acessar cada relação ou visão individual no banco de 
dados.
Em alguns casos, interessa conceder um privilégio temporário a um usuário. 
Por exemplo, o proprietário de uma relação pode querer conceder o privilégio 
SELECT a um usuário para uma tarefa específica e depois revogar aquele 
privilégio quando a tarefa estiver completada. Por isso, é necessário um 
mecanismo para a revogação de privilégios. Em SQL, um comando REVOKE é 
introduzido com o intento de cancelar privilégios.
11
REFERÊNCIAS 
Embarcadero - Database Trends Survey Report. Disponível em: http://www.
embarcadero.com/images/dm/technical-papers/database-survey-report.
pdf. Acessado em: 28 de maio de 2017.
PFLEEGER, Charles P.; PFLEEGER, Shari L. - Security in computing. 4ª ed. 
Massachusetts: Editora Prentice Hall, 2012.
SHASHA, DENNIS, BONNET, PHILIPPE - Database Tuning, Morgan Kaufmann 
Publishers, 2003.
FUNDAMENTOS 
COMPUTACIONAIS
Ramiro Córdova Júnior
Banco de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Conceituar banco de dados.
 � Identificar os tipos de banco de dados.
 � Classificar os tipos de linguagens de bancos de dados.
Introdução
Atualmente, os sistemas de informação são desenvolvidos juntamente 
com uma base de dados. Essa base é responsável por gerenciar a manipu-
lação dos dados utilizados. Por isso, é fundamental que os profissionais da 
área de desenvolvimento de sistemas tenham o conhecimento adequado 
sobre os bancos de dados. Assim, esses profissionais podem integrar 
sistemas e bancos de dados de maneira conveniente.
Neste capítulo, você vai conhecer a definição de banco de dados, 
associando-a a exemplos. Além disso, vai ver os diferentes tipos de banco 
de dados e a linguagem utilizada neles.
Conceito de banco de dados
Um banco de dados é uma coleção de informações organizadas para que 
possam ser facilmente acessadas, gerenciadas e atualizadas. Os dados são 
organizados em linhas, colunas e tabelas e são indexados para facilitar a 
localização de informações relevantes. Os dados são atualizados e excluídos 
à medida que novas informações são adicionadas. Os bancos de dados pro-
cessam informações e permitem a consulta dos dados armazenados. Além 
disso, permitem a execução de aplicações na base de dados.
Os bancos de dados computacionais geralmente contêm registros agrega-
dos ou arquivos de dados, que representam transações de vendas, catálogos 
de produtos, inventários, perfis de clientes, etc. Normalmente, um sistema 
gerenciador de banco de dados (SGBD) fornece aos usuários a capacidade 
de controlar o acesso de leitura/gravação, definir a geração de relatórios e 
realizar procedimentos de análise dos dados. Bancos de dados são predomi-
nantes em grandes sistemas de mainframe, mas também estão presentes em 
estações de trabalho distribuídas menores e sistemas de médio porte, como 
em computadores pessoais.
Um banco de dados pode ser considerado um software estruturado para 
coletar e armazenar informações que possam ser recuperadas, adicionadas, 
atualizadas ou removidas de maneira automática. Os programas de banco de 
dados são aplicativos projetados para que os usuários criem bancos de dados 
e toda a programação necessária para preenchê-los ou excluí-los, conforme 
necessário. A estrutura de um banco de dados (Figura 1) é baseada em tabelas, 
que consistem em linhas e colunas de informações.As colunas identificam 
os dados (atributos) na tabela e as linhas são os registros de informações. As 
tabelas se parecem com uma planilha, mas podem ser manipuladas e atuali-
zadas de uma forma que as planilhas não podem. Como você pode imaginar, 
isso torna um banco de dados uma ferramenta muito valiosa.
Figura 1. Estrutura do banco de dados.
NumEmp NomeEmp Salário Dept
032
074
089
092
112
121
130
J Silva
M Reis
C Melo
R Silva
R Pinto
V Simão
J Neves
380
400
520
480
390
905
640
21
25
28
25
21
28
28
Linhas
Colunas
Uma estrutura de banco de dados é definida pelo modelo de banco de dados. 
O modelo mais usado é o modelo de banco de dados relacional. Nesse modelo, as 
tabelas devem relacionar-se ou vincular-se umas às outras. Cada tabela contém 
informações específicas ou atributos (colunas) para cada registro (linha). Por 
exemplo, um banco de dados de uma clínica veterinária pode ter uma tabela 
Pacientes — com colunas intituladas Nome do paciente, Tipo de paciente e 
Banco de dados174
Número de ID — e uma segunda tabela chamada Proprietário do paciente — 
com as colunas intituladas Número de identificação, Nome do proprietário, 
Endereço do proprietário e Número de telefone do proprietário. A primeira 
tabela é vinculada à segunda tabela pelo número de ID. O relacionamento do 
número de ID permite a localização de registros dos pacientes vinculando 
com seus proprietários, retornando uma resposta precisa na realização de 
consultas no banco de dados.
O projeto de um banco de dados deve ser baseado nos requisitos de negócio. 
Os requisitos de negócio, por sua vez, devem ser perfeitamente compreendidos 
antes que um banco de dados seja projetado. Os requisitos de negócio também 
podem ser chamados de regras de negócios. As tabelas devem conter no 
máximo um conjunto de informações. No caso do exemplo anterior, a tabela 
Paciente não deve conter informações sobre as visitas dos pacientes. Em vez 
disso, uma tabela separada manteria um número de ID de visita e a data e a 
hora da visita, juntamente com o número de ID do paciente, para vincular os 
dois. Uma quarta tabela, intitulada Faturamento, seria criada para identificar 
o valor do pagamento, o tipo de pagamento e o ID da visita, que está sendo 
pago juntamente com o ID do paciente. As tabelas Faturamento e Visitas 
fazem parte da regra de negócio.
A inserção de registros preenche um banco de dados com dados. Depois 
que o banco de dados é estruturado corretamente, uma interface é construí da. 
Essa interface é colocada entre as tabelas e o usuário. A interface dá ao 
usuário uma visão diferente do banco de dados. Usando o exemplo da clínica 
veterinária, uma interface pode fornecer ao usuário uma página de entrada 
chamada Novo usuário. Nessa página, o usuário pode inserir o nome e o 
tipo do animal de estimação, as informações do proprietário e a data e o tipo 
da primeira visita. Todas essas informações estão contidas em três tabelas 
diferentes localizadas atrás da interface, mas o usuário só precisa interagir 
com a página de entrada (um único formulário), enquanto os dados são 
armazenados nas tabelas corretas. Isso é conseguido conectando as tabelas 
por meio de recursos de programação.
Acesse o link a seguir e leia mais sobre conceitos de banco de dados.
https://goo.gl/faJXMp
175Banco de dados
Tipos de banco de dados
Segundo Geremia (2010), são quatro os tipos de banco de dados existentes: (1) 
banco de dados relacional; (2) banco de dados hierárquico; (3) banco de dados 
em rede; e (4) banco de dados objeto-relacional. A seguir, você vai conhecer 
melhor cada um deles.
Banco de dados relacional
O banco de dados do tipo relacional funciona como uma coleção de relações, 
em que cada linha representa um conjunto de dados relacionados entre si. 
Os dados contidos em uma linha do banco de dados representam fatos do 
mundo real. Um banco de dados relacional é uma coleção de itens de dados 
organizados como um conjunto de tabelas formalmente descritas. A partir 
desse conjunto, os dados podem ser acessados ou remontados de muitas 
maneiras diferentes sem a necessidade de se reorganizarem as tabelas do 
banco de dados. Além de ser relativamente fácil de se criar e acessar, um 
banco de dados relacional tem a importante vantagem de ser fácil de estender. 
Após a criação do banco de dados original, uma nova categoria de dados 
pode ser adicionada sem a exigência de que todos os aplicativos existentes 
sejam modificados. 
Um banco de dados relacional é um conjunto de tabelas contendo dados 
ajustados em categorias predefinidas. Cada tabela contém uma ou mais ca-
tegorias de dados nas colunas. Cada linha contém uma instância única de 
dados para as categorias definidas pelas colunas. Por exemplo, um banco 
de dados de entrada de pedidos comerciais típico incluiria uma tabela que 
descreve um cliente com colunas para nome, endereço, número de telefone e 
assim por diante. Outra tabela descreveria um pedido: produto, cliente, data, 
preço de venda e assim por diante. Um usuário do banco de dados poderia 
obter uma visão do banco de dados que atendesse às suas necessidades. Por 
exemplo, um gerente da filial poderia gostar de visualizar ou relatar todos os 
clientes que compraram produtos após determinada data. Já um gerente de 
serviços financeiros da mesma empresa poderia, nas mesmas tabelas, obter 
um relatório sobre as contas que precisam ser pagas.
Banco de dados hierárquico
Um banco de dados hierárquico usa diferentes níveis de dados que seguem 
um padrão semelhante a uma hierarquia. Em outras palavras, você começa 
Banco de dados176
em uma tabela e, dependendo do registro consultado, obtém acesso a outras 
tabelas de informações. No entanto, essas tabelas são vinculadas apenas à 
tabela acima ou à tabela abaixo. Isso as torna incrivelmente úteis para coletar 
informações que seguem uma ordem específica.
Bancos de dados hierárquicos são úteis quando duas condições são aten-
didas. Em primeiro lugar, os dados devem seguir um padrão hierárquico 
(Figura 2). Isso significa que deve haver relacionamentos entre os dados que 
poderiam estar “empilhados”, como em uma árvore genealógica. Em segundo 
lugar, os dados que estão sendo empilhados devem estar acessíveis apenas 
por meio de um único caminho.
Figura 2. Hierarquia em bancos de dados.
Fábrica Financeiro Comercial
Injeção Extrusão Pagar Receber Contábil Vendas Marketing
Paulo Vinícius Vilma Sílvia João Pedro Carlos
Banco de dados em rede
O banco de dados em rede (Figura 3) é um modelo de banco de dados 
que permite que vários registros sejam vinculados ao mesmo arquivo de 
proprietário. O modelo pode ser visto como uma árvore invertida, onde os 
ramos são as informações do membro ligadas ao proprietário, que é a parte 
inferior da árvore. As múltiplas conexões permitem que o banco de dados 
de rede seja muito flexível. Além disso, a relação que a informação tem 
com o banco de dados de rede é definida como relação muitos para muitos, 
porque um arquivo proprietário pode ser vinculado a vários arquivos de 
membros e vice-versa.
177Banco de dados
Figura 3. Rede de banco de dados.
Departamento Empregado
032 J Silva 380
074 M Reis 400
089 C Melo 520
092 R Silva 480
112 R Pinto 390
121 V Simão 905
130 J Neves 640
21 Pessoal 142
25 Financeiro 143
28 Técnico 144
Banco de dados objeto-relacional
O modelo relacional de objeto é projetado para fornecer um gerenciamento de 
banco de dados relacional que permite aos desenvolvedores integrar bancos 
de dados com seus tipos e métodos de dados. É essencialmente um modelo 
relacional que permite aos usuários integrarem nele recursos de programação 
orientada a objetos. A principal função desse tipo de banco de dados é dar 
maior flexibilidade, melhor desempenho e maior integridade de dados que os 
demais tipos de bancode dados. A seguir, você pode ver alguns dos benefícios 
proporcionados pelo banco de dados objeto-relacional.
 � Expansibilidade: é possível ampliar a capacidade do servidor de banco 
de dados. Isso pode ser feito definindo novos tipos de dados, bem como 
por meio de padrões definidos pelo usuário. Esse recurso permite que 
o usuário armazene e gerencie dados.
 � Tipos de dados complexos: os usuários podem definir novos tipos de 
dados que combinam um ou mais tipos de dados existentes no momento. 
Os tipos complexos garantem melhor flexibilidade na organização dos 
dados em uma estrutura composta de colunas e tabelas.
 � Herança: os usuários podem definir objetos ou tipos e tabelas que 
adquirem as propriedades de outros objetos, além de adicionar novas 
propriedades específicas ao objeto que foi definido.
Banco de dados178
Leia mais sobre sistemas de banco de dados na obra “Sistemas de banco de dados” 
(ELMASRI, R.; NAVATHE, S. B., 2005).
Linguagens de banco de dados
Um sistema gerenciador de banco de dados deve prover linguagens e inter-
faces apropriadas para que cada categoria de usuários realize consultas e 
atualizações no banco de dados. As linguagens de banco de dados são usadas 
para a criação e a manutenção do banco de dados. Há um grande número de 
linguagens de banco de dados, como Oracle, MySQL, MS Access, dBase, 
FoxPro, etc. As instruções SQL usadas em um banco de dados podem ser 
categorizadas como linguagem de definição de dados (DDL), linguagem de 
controle de dados (DCL) e linguagem de manipulação de dados (DML). Você 
vai conhecer melhor cada uma delas a seguir. 
Linguagem de definição de dados (DDL)
É uma linguagem que permite aos usuários definir dados e sua relação com outros 
tipos de dados. É usada principalmente para criar arquivos, bancos de dados, dicio-
nário de dados e tabelas dentro de bancos de dados. Também serve para especificar 
a estrutura de cada tabela, o conjunto de valores associados a cada atributo, as 
restrições de integridade, as informações de segurança e autorização para cada 
tabela e o armazenamento físico da estrutura de cada tabela no disco. A seguir, 
você pode ver uma lista de instruções SQL que são categorizadas como DDL.
 � Para criar a instância do banco de dados — CREATE
 � Para alterar a estrutura do banco de dados — ALTER
 � Para descartar instâncias do banco de dados — DROP
 � Para excluir tabelas em uma instância de banco de dados — TRUNCATE
 � Para renomear instâncias do banco de dados — RENAME
Linguagem de manipulação de dados (DML)
É uma linguagem que fornece um conjunto de operações para suportar as 
operações básicas de manipulação nos dados mantidos nos bancos de dados. 
179Banco de dados
As instruções DML permitem que os usuários insiram, atualizem, excluam 
e recuperem dados do banco de dados. A parte do DML que envolve a recu-
peração de dados é chamada de linguagem de consulta. A seguir, você pode 
ver algumas instruções SQL que são do tipo DML.
 � Para buscar registros da(s) tabela(s) — SELECT
 � Para inserir registros na(s) tabela(s) — INSERT
 � Para atualizar os dados na(s) tabela(s) — UPDATE
 � Para excluir os registros da tabela — DELETE
Linguagem de controle de dados (DCL)
As instruções do tipo DCL controlam o acesso aos dados e ao banco de dados 
usando instruções SQL como GRANT e REVOKE. Um privilégio pode ser 
concedido a um usuário com a ajuda da instrução GRANT. Os privilégios 
atribuídos podem ser instruções do tipo SELECT, ALTER, DELETE, EXE-
CUTE, INSERT, INDEX, etc. Além da concessão de privilégios, também é 
possível revogar usando o comando REVOKE.
Na prática, as linguagens de definição de dados e de manipulação de 
dados não são separadas. Em vez disso, elas formam partes de uma única 
linguagem de banco de dados, como SQL (Structured Query Language). O 
SQL representa uma combinação de DDL e DML, além de instruções para 
especificação de restrições e avaliação de esquemas.
GEREMIA, J. Tutorial de introdução a banco de dados. 2010. Disponível em: <http://
www.telecom.uff.br/pet/petws/downloads/tutoriais/db/Tut_DB.pdf>. Acesso em; 
22 abr. 2018.
Leituras recomendadas
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: Pearson, 2005.
REZENDE, R. Conceitos fundamentais de banco de dados. [201-?]. Disponível em: <ht-
tps://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. 
Acesso em; 22 abr. 2018.
SANTANCHÈ, A.; CAVOTO, P. Banco de dados. Campinas: [S.n.], (2013).
Referência
Banco de dados180
MODELAGEM E 
DESENVOLVIMENTO 
DE BANCO DE 
DADOS
Fabrício Felipe 
Meleto Barboza
Conceitos de banco 
de dados
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
 � Identificar a importância da utilização do banco de dados no contexto 
organizacional.
 � Reconhecer as principais ferramentas de administração de banco 
de dados.
 � Relacionar os principais ambientes de banco de dados.
Introdução
Neste capítulo, você vai estudar a necessidade do uso de banco de dados 
no lugar de outra forma de guardar as informações, como, por exemplo, 
planilhas eletrônicas ou documentos de textos.
Adicionalmente, você também conseguirá vislumbrar a diferença 
entre os sistemas de bancos de dados existentes atualmente, suas apli-
cações mais comumente utilizadas nas corporações em geral e, também, 
os aspectos positivos e negativos de cada opção de uso dos sistemas 
abordados.
Necessidade de uso dos bancos de dados
Imagine que você trabalha em uma pequena loja que tem como principal 
fonte de receita a comercialização de capinhas de celulares. A cada entrada 
de mercadoria no estoque ou baixa ao realizar uma venda, é registrada a 
respectiva ação em um caderno de registros. Tome por base que essa lojinha 
venda uma capinha de celular por dia: ao longo de um mês, haverá 30 registros 
de venda e de 2 a 3 registros de entrada de mercadoria. Bem fácil controlar 
na caderneta, certo?
Mas então o dono da lojinha recebeu uma herança e resolveu comprar um 
espaço no shopping mais movimentado da cidade para expandir os negócios. 
De 30 capinhas ao mês, agora a venda aumentou para três mil capinhas. O seu 
trabalho de registro na caderneta começou a ficar complexo e a tomar cada 
vez mais tempo do seu dia. Para resolver o problema, um sobrinho do dono 
da loja fez uma planilha eletrônica linda, cheia de fórmulas e que resolve mais 
rapidamente seu problema de cadastro.
Como um excelente homem de negócios, seu chefe resolveu abrir 20 filiais 
novas. Temos, então, 60 mil registros de venda de capinhas mais os registros 
de entrada de estoque por mês. Se colocarmos que a quantidade de linhas 
que uma planilha eletrônica suporta atualmente é cerca de um milhão, você 
iria enchê-la em menos de 18 meses (ou um ano e meio). Além disso, essa 
planilha ocuparia muito espaço no computador e você levaria muito tempo 
para recuperar as informações inseridas ali em cada momento de venda.
Então você se cansa de trabalhar nessa loja, entra em uma empresa de tele-
fonia multinacional e se pega imaginando quantas planilhas eles possuem para 
controlar todas as ligações que seus clientes fazem a cada minuto. Segundo a 
ANATEL (BRASIL, 2018), a quantidade de linhas telefônicas fixas no Brasil já 
passou a marca de 40 milhões e meio. Coloque nessa equação a quantidade de 
linhas telefônicas móveis (celulares) e temos o caos das planilhas eletrônicas.
A solução para qualquer um dos casos apresentados, desde a lojinha que 
vendia 30 capinhas de celular por mês até a grande companhia telefônica com 
milhões de novos registros que precisam ser processados a cada segundo, é 
uma só: banco de dados.
Acesse o link a seguir e leia a notícia da ANATEL, que apresenta a enorme quantidade 
de linhas fixas existentes em todos os estados brasileiros.
https://goo.gl/6wcb8D
Da mesma forma, a atividade pertinente a qualquer área de uma organização 
requer um poder grande de armazenamento de informações, ordenação, busca 
e edição. Pense em um sistema on-linepopular qualquer, como, por exemplo, o 
Conceitos de banco de dados2
Facebook. Inúmeros bancos de dados são utilizados para prover a plataforma 
da rede social, cada qual com seu objetivo: um banco de dados somente para 
o cadastro dos usuários, outro banco de dados para as postagens dos usuários, 
um terceiro banco de dados para armazenar as fotos dos usuários, mais outro 
banco de dados para o feed de notícias, um quinto banco de dados para o chat 
da plataforma, etc.
Cada sistema tem sua própria divisão de banco de dados, mas você pode 
ter certeza de que é necessário um ou mais banco de dados para suportar um 
blog, por mais simplista que possa parecer — até mesmo para grandes plata-
formas, como Facebook, LinkedIn, Instagram, WhatsApp, Twitter, sistemas 
bancários e demais sistemas.
Quando você efetua a compra de um produto qualquer para o qual é 
emitida uma nota fiscal eletrônica, o fluxo de funcionamento daquele ponto 
de venda (PDV) com a ação do colaborador do estabelecimento ao registrar 
seu CPF na nota, por exemplo, seria o que está visualmente representado 
na Figura 1.
Figura 1. Fluxo de relações entre banco de dados.
Vendedor realiza a venda e insere o CPF 
do comprador no sistema da loja
O sistema de banco de dados
da loja:
1. Baixa a quantidade vendida
2. Veri�ca se atingiu o limite
mínimo de estoque e alerta
o gerente
3. Conclui a venda e envia
sinal para emissão da nota �scal
O banco de dados da Receita Estadual
ou Federal recebe a solicitação de
emissão de nota e:
1. Confere se o sistema da loja está apto
a realizar a venda
2. Pega a informação do CPF informado
e consulta se é válido
3. Realiza os cálculos de impostos em
cima da venda para a exibição no cupom
�scal
4. Cadastra a nota/cupom �scal na base
de dados
5. Informa o sistema CPF na nota desta
nova compra daquele CPF
O banco de dados do sistema
de CPF na nota:
1. Recebe a emissão da nova
nota e grava no banco de dados
2. Calcula o valor de retorno de
crédito para o consumidor
3. Disponibiliza a consulta desse
crédito no seu sistema on-line
4. Caso tenha, insere cupons para
participar de sorteios de prêmios
Sendo assim, com a utilização de banco de dados, tanto o cadastro de novos 
registros, como a venda de uma capinha de celular do exemplo anterior, quanto 
3Conceitos de banco de dados
uma nova ligação por parte do cliente da grande companhia telefônica resulta 
em um novo registro no próprio banco de dados — portanto, uma nova linha 
da “planilha”. Como os bancos de dados, em sua maioria, estão conectados aos 
sistemas, esse registro é feito de forma automática e é garantida a integridade 
da informação.
Imagine o sistema de uma loja virtual ou sites de compra e venda. O relacionamento 
entre bancos de dados ocorre por segundo, muitas vezes, para o envio, troca, edição, 
exclusão e informe de operações. Sites como o do Mercado Livre, por exemplo, precisam 
de um banco de dados robusto e confiável.
Como administrar um banco de dados
A questão da administração de um banco de dados é ampla e complexa, sendo 
debatida por diversos autores. Em resumo, você deve ter conhecimento de 
que tipo de informação está alocada nas tabelas do seu banco de dados e, 
principalmente, como manipular as informações que ali estão inseridas da 
forma que necessita.
Um sistema de banco de dados é formado pelo software de banco de dados, 
o repositório de tabelas denominado database e as próprias tabelas em si ou 
tables. Dessa forma, um banco de dados para um sistema de agenda telefônica 
teria o serviço do banco de dados executado, uma database e, dentro desta, 
estariam as tabelas para gravar as informações de nome, endereço, contato 
telefônico, e-mail, aniversário, foto, etc.
Portanto, para você conseguir realizar uma boa administração do banco 
de dados, é necessário conhecer o negócio ou o projeto ao qual ele servirá. 
De nada adianta ter tabelas que não são necessárias, pois isso impacta na 
performance do serviço. No exemplo da agenda telefônica, se não existisse 
o campo “contato telefônico”, o sistema ficaria inútil, pois uma agenda tele-
fônica precisa, obrigatoriamente, conter o campo para cadastro do telefone 
do contato.
Conceitos de banco de dados4
No exemplo da agenda telefônica, existem campos obrigatórios e campos opcionais. 
Os campos “nome” e “contato telefônico” são obrigatórios. Já os campos “endereço”, 
“e-mail”, “aniversário” e “foto” são opcionais.
Essa diferenciação se deve ao fato de que uma agenda telefônica precisa, no mínimo, 
gravar o nome e o telefone de contato da pessoa. Portanto, o banco deve respeitar 
essa regra para ser bem construído.
Como passo fundamental na administração correta de um banco de dados, 
é essencial que você tenha a documentação base do sistema que utilizará 
do banco de dados sob sua administração. Esse documento contemplará a 
modelagem do banco de dados, os relacionamentos entre tabelas, como será 
gravada cada informação, quais campos são obrigatórios e quais são opcionais, 
a necessidade de indexação para melhorar a velocidade de consulta, etc.
A seguir, na Figura 2, você verá um exemplo simples de uma modelagem 
de banco de dados, na forma de entidade-relacionamento, para compreensão. 
Essa forma de ilustração do banco de dados é a mais comumente utilizada em 
documentações e projetos. Nela, cada retângulo representa uma tabela, cujo 
título é o seu nome. Para cada tabela, há uma relação de atributos (linhas abaixo 
do título) e linhas ligando essas tabelas, que representam os relacionamentos 
entre elas. Por ora, você precisa atentar para o nome e cada atributo das tabelas a 
seguir, pois iremos estudar esse e outros modelos de banco de dados mais adiante.
Figura 2. Exemplo de banco de dados.
Cliente
Nome
Telefone
Endereço
Cidade
Estado
CPF
Código
Nome
Preço
Qtd Estoque
Produto
Venda
Código
CPF_Cliente
Código_produto
Data
Valor
Código_nfe
5Conceitos de banco de dados
Note que existem três tabelas ou tables no banco de dados da Figura 2: tabela 
“Cliente”, tabela “Produto” e tabela “Venda”. O relacionamento entre elas é 
executado quando o colaborador registra uma venda; então, o banco de dados 
cria um registro na tabela “venda” contendo os dados do produto comprado 
e os do cliente que comprou. Cada tabela tem atributos próprios, que seriam 
suas colunas, nas quais ficam as informações correspondentes. Ou seja, pela 
tabela “Cliente” foi mapeado que o cadastro de cliente terá os campos “Nome”, 
“Telefone”, “Endereço”, “Cidade”, “Estado” e “CPF”. Já na tabela “Produto”, os 
atributos (colunas) são “Código”, “Nome”, “Preço” e “Quantidade Estoque”. Por 
fim, temos a tabela “Venda” com os atributos (colunas) “Código”, “CPF_cliente”, 
“Código_produto”, “Data”, “Valor” e “Código_nfe”.
Para otimizar a quantidade de registros no banco de dados, existe a chave 
primária e a chave estrangeira. A chave primária é um campo que é definido 
como único e não pode repetir-se naquela tabela. Como exemplo de chave 
primária para a tabela “Cliente”, pode-se utilizar o CPF, que é um número 
único por pessoa (ninguém no Brasil tem o mesmo CPF que o seu). Para a 
tabela “Produto”, foi criado um atributo chamado “Código”. Já a tabela “Venda” 
pode usar o seu campo “Código”.
A chave estrangeira ocorre quando pegamos um atributo de outra tabela 
que é chave primária nela. Veja novamente a Figura 2 e observe que, na tabela 
“Venda”, existem duas possíveis chaves estrangeiras: “CPF_cliente”, que 
vem da tabela “Cliente”, e “Código_produto”, que vem da tabela “Produto”. 
Isso se dá para que, quando alguém pedir relatório de vendas, ao consultar a 
tabela “Venda”, o sistema consiga buscar, por meio do campo “CPF_cliente”, 
os dados do cliente na tabela “Cliente” e os dados do produto por meio do 
campo “Código_produto” na tabela “Produto”.
A dúvida que surge é a de por que realizar esses relacionamentos e não 
simplesmente criar mais atributos na tabela “Venda” para comportar os dados 
do cliente e dos produtos nessa própria tabela. A resposta é bem simples: