Banco de dados

Prévia do material em texto

1
 
PARTE IPARTE I
CONCEITOS BÁSICOSCONCEITOS BÁSICOS
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 tratados e 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 dedados 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 
aplicativo gené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
Devemosproteger 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 estejam atualmente 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.
1.5 DESCREVENDO E ARMAZENANDO DADOS EM UM SGBD
O usuário de um SGBD é preocupado, basicamente, com alguma empresa do mun-
do real, e os dados a ser armazenados descrevem vários aspectos desta empresa. Por 
exemplo, há alunos, professores e cursos em uma universidade, e os dados em um ban-
co de dados de uma universidade descrevem essas entidades e seus relacionamentos.
Um modelo de dados é uma coleção de construtores de alto nível para descrição 
dos dados que ocultam vários detalhes de baixo nível do armazenamento. Um SGBD 
possibilita que um usuário defina os dados a serem armazenados em termos de modelo 
de dados. A maioria dos sistemas de gerenciamento de banco de dados atuais baseia-se 
no modelo de dados relacional, que constitui o foco deste livro.
Embora o modelo de dados de um SGBD oculte vários detalhes, ele está, no entan-
to, mais próximo de como o SGBD armazena os dados do que de como o usuário pensa 
sobre a empresa em questão. Um modelo de dados semântico é um modelo de dados de 
alto nível, mais abstrato, que facilita a um usuário alcançar uma boa descrição inicial 
dos dados de uma empresa. Esses modelos contêm uma grande variedade de constru-
tores que ajudam a descrever um cenário de aplicação real. Um SGBD não é projetado 
para suportar todos esses construtores diretamente; ele é construído tipicamente sobre 
um modelo de dados com apenas alguns construtores básicos, como o modelo relacio-
nal. Um projeto de banco de dados em termos de modelo semântico serve como ponto 
de partida útil e é subseqüentemente traduzido em um projeto de banco de dados em 
termos do modelo de dados que o SGBD realmente suporta.
Um modelo de dados semântico muito utilizado, chamado modelo entidade-relacio-
namento (ER), nos permite denotar por meio de ilustrações as entidades e os relacio-
namentos entre elas. Apresentamos o modelo ER no Capítulo 2.
Visão Geral sobre Sistemas de Banco de Dados 9
Um Exemplo de Projeto Ineficiente: O esquema relacional para Alunos ilustra 
uma escolha de projeto ineficiente; nunca se deve criar um campo tal como ida-
de, cujo valor está constantemente sendo alterado. Uma escolha melhor seria 
DDN (Data Do Nascimento); a idade pode ser calculada com base nesse dado. 
Continuamos a utilizar idade em nossos exemplos, entretanto, para facilitar a 
leitura.
1.5.1 O Modelo Relacional
Nesta seção, apresentamos uma breve introdução ao modelo relacional. O construtor 
central para descrição de dados deste modelo é uma relação, que pode ser considerada 
um conjunto de registros.
Uma descrição de dados em termos de modelo de dados é chamada esquema (sche-
ma). No modelo relacional, o esquema de uma relação especifica seu nome, o nome de 
cada campo (ou atributo ou coluna), e o tipo de cada campo. Como exemplo, a infor-
mação sobre o aluno em um banco de dados de uma universidade pode ser armazenada 
em uma relação com o seguinte esquema:
 Alunos (id-aluno: stringstring, nome: stringstring, login: stringstring,idade: integerinteger, média: realreal)
O esquema anterior informa que cada registro na relação Alunos tem cinco cam-
pos, sendo os nomes e tipos dos campos conforme indicados. Um exemplo de instân-
cia da relação Alunos é ilustrado na Figura 1.1.
id-aluno nome login idade média
53666 Jones jones@cs 18 3,4
53688 Smith smith@ee 18 3,2
53650 Smith smith@math 19 3,8
53831 Madayan madayan@music 11 1,8
53832 Guldu guldu@music 12 2,0
Figura 1.1 Uma instância da relação Alunos.
Cada linha na relação Alunos é um registro que descreve um aluno. A descrição não 
está completa — por exemplo, a altura do aluno não está incluída —, mas é presumi-
velmente adequada para os aplicativos projetados no banco de dados da universidade. 
Cada linha segue o esquema da relação Alunos. O esquema pode, então, ser conside-
rado um modelo para descrever um aluno.
Podemos tornar a descrição de um conjunto de alunos mais precisa especificando as 
restrições de integridade, que são condições que os registros de uma relação devem sa-
tisfazer. Por exemplo, poderíamos especificar que todo aluno tenha um valor id-aluno 
único. Observe que não podemos capturar essa informação acrescentando simplesmen-
te outro campo ao esquema Alunos. Assim, a capacidade de especificar a unicidade dos 
valores de um campo aumenta a precisão com que podemos descrever nossos dados. A 
expressividade dos construtores disponíveis para especificar as restrições de integrida-
de é um aspecto importante de um modelo de dados.
10 CAPÍTULO 1
Outros Modelos de Dados
Além do modelo de dados relacional (que é utilizado em inúmeros sistemas, incluindo 
o DB2 da IBM, Informix, Oracle, Sybase, Access da Microsoft, FoxBase, Paradox, 
Tandem e Teradata), outros importantes modelos de dados incluem o modelo hierár-
quico (por exemplo, usado no SGBD IMS da IBM), o modelo de rede (usado no IDS e 
IDMS), o modelo orientado a objetos (por exemplo, usado no Objectstore e Versant) 
e o modelo objeto-relacional (por exemplo, usado nos produtos SGBD da IBM, Infor-
mix, ObjectStore, Oracle, Versant e outros). Embora vários bancos de dados utilizem 
os modelos hierárquico e de rede, e embora os sistemas baseados nos modelos orien-
tado a objetos e objeto-relacional estejam ganhando aceitação no mercado, o modelo 
dominante atualmente é o modelo relacional.
Neste livro, concentramo-nos no modelo relacional em razão de seu amplo uso e 
importância. Entretanto, o modelo objeto-relacional, que está ganhando popularidade, 
é o resultado de um esforço de combinar as melhores características dos modelos rela-
cional e orientado a objetos, e uma boa compreensão do modelo relacional é necessária 
para compreender os conceitos do objeto-relacional. (Discutiremos os modelos orienta-
do a objetos e objeto-relacional no Capítulo 23.)
1.5.2 Níveis de Abstração em um SGBD
Os dados em um SGBD são descritos em três níveis de abstração, conforme ilustrado 
na Figura 1.2. A descrição do banco de dados consiste em um esquema em cada um 
desses três níveis de abstração: o conceitual, o físico e o externo.
Uma linguagem de definição de dados (DDL — data definition language) é utili-
zada para definir os esquemas externos e conceituais. Discutiremos os recursos DDL da 
linguagem de banco de dados mais amplamente utilizada, a SQL, no Capítulo 3. Todos 
os fabricantes de SGBD também suportam comandos SQL para descrever aspectos do 
esquema físico, mas estes comandos não são parte da linguagem SQL padrão. As infor-
mações sobre os esquemas conceitual, externo e físico são armazenadas nos catálogos de 
sistema (Seção 12.1). Discutiremos os três níveis de abstração no restante desta seção.
Figura 1.2 Níveis de abstração em um SGBD.
Esquema Conceitual
O esquema conceitual (chamado também de esquema lógico) descreve os dados ar-
mazenados em termos do modelo de dados do SGBD. Em um SGBD relacional, o 
Visão Geral sobre Sistemas de Banco de Dados 11
esquema conceitual descreve todas as relações que estão armazenadas no banco de 
dados. Em nosso exemplo de banco de dados de universidade, essas relações contêm 
informações sobre entidades, como alunos e professores, e sobre relacionamentos, como 
a matrícula dos alunos nos cursos. Todas as entidades aluno podem ser descritas 
usando-se registros em uma relação Alunos, como vimos anteriormente. De fato, cada 
coleção de entidades e cada coleção de relacionamentos podem ser descritas como uma 
relação, levando ao seguinte esquema conceitual:
 Alunos(id-aluno: stringstring, nome: stringstring, login: stringstring, idade: integerinteger, média: realreal)
 Professores(id-prof: stringstring, nomep: stringstring, sal: realreal)
 Cursos(id-curso: stringstring, nomec: stringstring, créditos: integerinteger)
 Salas(num-sala: integerinteger, endereço: stringstring, capacidade: integerinteger)
 Matriculado(id-aluno: stringstring, id-curso: stringstring, nota: stringstring)
 Ministra(id-prof: stringstring, id-curso: stringstring)
 Aula(id-curso: stringstring, num-sala: integerinteger, horário: stringstring)
A escolha de relações e a escolha dos campos de cada relação nem sempre são 
óbvias, e o processo de produzir um bom esquema conceitual é chamado projeto con-
ceitual de banco de dados. Discutiremos o projeto conceitual de banco de dados nos 
capítulos 2 e 19.
Esquema Físico
O esquema físico especifica os detalhes adicionais de armazenamento. Essencialmente, 
o esquema físico resume como as relações descritas no esquema conceitual são realmen-
te armazenadas em dispositivos de armazenamento secundário como discos e fitas.
Devemos decidir quais organizações de arquivos utilizar para armazenar as relações 
e criar estruturas de dados auxiliares, chamadas índices, para acelerar as operações 
de recuperação de dados. Um exemplo de esquema físico para o banco de dados da 
universidade:
Armazene todas as relações como arquivos não ordenados de registros. (Um arquivo 
em um SGBD é ou uma coleção de registros ou uma coleção de páginas, em vez de 
uma cadeia de caracteres como em um sistema operacional.)
Crie índices na primeira coluna das relações Alunos, Professores e Cursos, na colu-
na sal de Professores e na coluna capacidade de Salas.
Decisões sobre o esquema físico baseiam-se em uma compreensão de como o dado 
é normalmente acessado. O processo de produzir um bom esquema físico é chamado 
projeto físico de banco de dados. Discutiremos o projeto físico de banco de dados no 
Capítulo 20.
Esquema Externo
Esquemas externos, que normalmente também são representados em termos do mo-
delo de dado do SGBD, permitem que o acesso aos dados seja customizado (e autori-
zado) no nível dos usuários individuais ou em grupos. Qualquer banco de dados tem 
exatamente um esquema conceitual e um esquema físico porque ele tem apenas um 
conjunto de relações armazenadas, mas pode ter diversos esquemas externos, cada 
um adaptado a um grupo particular de usuários. Cada esquema externo consiste em 
■
■
12 CAPÍTULO 1
uma coleção de uma ou mais visões e relações do esquema conceitual. Uma visão concei-
tualmente é uma relação, mas os registros de uma visão não são armazenados no SGBD. 
Ao contrário, eles são processados usando uma definição para a visão, baseada nas relações 
armazenadas no SGBD. Discutiremos visões com mais detalhes nos capítulos 3 e 25.
O projeto de esquema externo é orientado pelos requisitos do usuário final. Por 
exemplo, podemos permitir que os alunos localizem os nomes dos professores que 
ministram cursos, assim como as matrículas no curso. Isso pode ser feito definindo a 
seguinte visão:
 InfoCurso(id-curso: stringstring, nomep: stringstring, matriculados: integerinteger)
Um usuário pode tratar uma visão assim como uma relação e fazer perguntas sobre 
os registros da visão. Embora os registros da visão não sejam armazenados explicita-
mente, eles são processados sempre que necessário.Não incluímos InfoCurso no esque-
ma conceitual porque podemos processar InfoCurso com base nas relações do esquema 
conceitual, e, além disso, armazená-la seria redundante. Tal redundância, além do 
desperdício de espaço, poderia gerar inconsistências. Por exemplo, uma tupla pode ser 
inserida na relação Matriculado, indicando que um aluno em particular se matriculou 
em algum curso, sem incrementar o valor do campo matriculados do registro corres-
pondente de InfoCurso (se esse último também for parte do esquema conceitual e suas 
tuplas estiverem armazenadas no SGBD).
1.5.3 Independência de Dados
Uma vantagem muito importante de usar um SGBD é a independência de dados que 
ele oferece. Ou seja, os programas de aplicativos são isolados das alterações no modo 
como o dado é estruturado e armazenado. A independência dos dados é adquirida 
através do uso dos três níveis de abstração de dados; em particular, o esquema concei-
tual e o esquema externo fornecem benefícios distintos nesta área.
As relações no esquema externo (relações de visões) são em princípio geradas por 
demanda a partir das relações correspondentes ao esquema conceitual.4 Se os dados 
correspondentes são reorganizados, isto é, se o esquema conceitual é alterado, a de-
finição de uma relação de visão pode ser modificada de forma que a mesma relação 
seja processada como antes. Por exemplo, suponha que a relação Professores em nosso 
banco de dados de universidade seja substituída pelas duas relações a seguir:
 Professores-público (id-prof: stringstring, nomep: stringstring, escritório: integerinteger)
 Professores-particular(id-prof: stringstring, sal: realreal)
Intuitivamente, algumas informações confidenciais sobre professores foram posicio-
nadas em uma relação separada e as informações sobre escritórios foram acrescentadas. 
A relação de visão InfoCurso pode ser redefinida em termos de Professores-publico e 
Professores-particular, as quais, juntas, contêm todas as informações em Professores, de 
forma que um usuário que consulte InfoCurso obterá as mesmas respostas de antes.
Assim, os usuários podem ser protegidos das alterações na estrutura lógica dos da-
dos, ou das alterações na escolha das relações a serem armazenadas. Essa propriedade é 
chamada independência lógica dos dados.
4 Na prática, elas poderiam ser pré-processadas e armazenadas para acelerar as consultas nas relações de 
visão, mas as relações de visão processadas devem ser atualizadas sempre que as relações correspondentes forem 
modificadas.
Visão Geral sobre Sistemas de Banco de Dados 13
Por outro lado, o esquema conceitual isola os usuários das alterações nos detalhes 
do armazenamento físico. Esta propriedade refere-se à independência física dos dados. 
O esquema conceitual oculta detalhes sobre como os dados são realmente dispostos no 
disco, sobre a estrutura de arquivos, e sobre a escolha de índices, por exemplo. Desde 
que o esquema permaneça o mesmo, podemos alterar estes detalhes sem alterar os 
aplicativos. (Obviamente, o desempenho poderia ser afetado por tais alterações.)
1.6 CONSULTAS EM UM SGBD
A facilidade com a qual as informações podem ser obtidas de um banco de dados nor-
malmente determina seu valor a um usuário. Em contraste aos sistemas antigos de 
banco de dados, os sistemas de banco de dados relacionais permitem que uma rica va-
riedade de questões seja formulada facilmente; este recurso contribuiu em muito para 
sua popularidade. Considere o exemplo do banco de dados da universidade na Seção 
1.5.2. Eis algumas perguntas que um usuário poderia fazer:
1. Qual é o nome do aluno que tem o id-aluno 123456?
2. Qual é o salário médio de professores que ministram o curso CS564?
3. Quantos alunos estão matriculados em CS564?
4. Qual a porcentagem de alunos de CS564 que obtiveram uma nota maior do que B?
5. Há algum aluno com média inferior a 3,0 matriculado em CS564?
Tais perguntas envolvendo os dados armazenados em um SGBD são chamadas 
consultas. Um SGBD provê uma linguagem especializada, chamada linguagem de con-
sulta, com a qual as consultas podem ser elaboradas. Um recurso muito atrativo do 
modelo relacional é o suporte a linguagens de consulta poderosas. O cálculo relacional 
é uma linguagem de consulta formal baseada na lógica matemática, e as consultas 
nesta linguagem têm um significado intuitivo e preciso. A álgebra relacional é outra 
linguagem de consulta formal, baseada em uma coleção de operadores para manipular 
relações, que é equivalente em poder ao cálculo.
Um SGBD preocupa-se em processar as consultas de forma tão eficiente quanto 
possível. Discutiremos a otimização e avaliação de consultas nos Capítulos 12, 14 e 15. 
Obviamente, a eficiência da avaliação da consulta é determinada em grande parte por 
como os dados são armazenados fisicamente. Os índices podem ser usados para acele-
rar muitas consultas — de fato, uma boa escolha de índices para as relações correspon-
dentes pode acelerar cada consulta da lista anterior. Discutiremos o armazenamento 
de dados e a indexação nos Capítulos 8, 9, 10 e 11.
Um SGBD possibilita aos usuários criar, modificar e consultar dados através de 
uma linguagem de manipulação de dados (DML — data manipulation language). 
Assim, a linguagem de consulta é apenas uma parte da DML, que também fornece 
construtores para inserir, excluir e modificar dados. Discutiremos os recursos DML 
da SQL no Capítulo 5. A DML e a DDL são coletivamente referenciadas como 
sublinguagens de dados quando embutidas dentro de uma linguagem hospedeira 
(por exemplo, C ou COBOL).
1.7 GERENCIAMENTO DE TRANSAÇÕES
Considere um banco de dados que armazena informações sobre reservas de passagens 
aéreas. Em um certo instante qualquer, é possível (e bem provável) que diversos agen-
tes de viagem estejam procurando informações sobre assentos disponíveis nos vários 
vôos e fazendo reservas de novos assentos. Quando vários usuários acessam (e possi-
14 CAPÍTULO 1
velmente modificam) um banco de dados de forma concorrente, o SGBD deve coman-
dar cuidadosamente suas solicitações para evitar conflitos. Por exemplo, quando um 
agente de viagem procura o Vôo 100 de determinado dia e encontra um assento vazio, 
um outro agente de viagem pode estar fazendo uma reserva desse assento simultanea-
mente, tornando obsoleta a informação vista pelo primeiro agente.
Um outro exemplo de uso concorrente é o banco de dados de um banco. Enquanto 
o programa de aplicativo de um usuário está calculando o total de depósitos, um outro 
aplicativo pode transferir dinheiro de uma conta que o primeiro aplicativo acabou de 
consultar para uma conta que ainda não foi consultada, fazendo assim com que o to-
tal apareça maior do que ele realmente deve ser. Evidentemente, a ocorrência de tais 
anomalias não deve ser permitida. Entretanto, desabilitar o acesso concorrente pode 
degradar o desempenho.
Além disso, o SGBD deve proteger os usuários dos efeitos de falhas do sistema 
assegurando que todos os dados (e o status dos aplicativos ativos) sejam restaurados 
para um estado consistente quando o sistema for reiniciado após uma falha. Por exem-
plo, se um agente de viagens solicitar uma reserva, e o SGBD responder que a reserva 
foi realizada, a reserva não deve ser perdida se o sistema falhar. Por outro lado, se o 
SGBD ainda não respondeu à solicitação, mas está fazendo as alterações necessárias 
nos dados quando a falha ocorrer, as alterações parciais devem ser desfeitas quando o 
sistema voltar a funcionar.
Uma transação é uma execução qualquer de um programa de usuário em um SGBD. 
(A execução de um mesmo programa diversas vezes gerará diversas transações.) Esta 
é a unidade básica de alteração reconhecida pelo SGBD: transações parciais não são 
permitidas, e o efeito de um grupo de transações é equivalente a uma execução serial 
de todas as transações. Resumimos brevemente como estas propriedadessão garanti-
das, postergando uma discussão detalhada para os capítulos posteriores.
1.7.1 Execução Concorrente de Transações
Uma importante tarefa de um SGBD é planejar os acessos concorrentes aos dados de 
forma que cada usuário possa seguramente ignorar o fato de que há outros usuários 
acessando os dados concorrentemente. A importância dessa tarefa não pode ser su-
bestimada porque um banco de dados normalmente é compartilhado por um grande 
número de usuários, que submetem suas requisições ao SGBD de modo independente e 
simplesmente não esperam que devam tratar de alterações arbitrárias sendo realizadas 
de forma concorrente por outros usuários. Um SGBD permite que os usuários pensem 
em seus programas como se eles estivessem sendo executados isoladamente, um após 
o outro, em determinada ordem escolhida pelo SGBD. Por exemplo, se um programa 
que deposita um valor em uma conta é submetido ao SGBD ao mesmo tempo em que 
um outro programa debita dinheiro da mesma conta, qualquer um desses programas 
poderia ser executado primeiro pelo SGBD, mas seus passos não podem ser intercala-
dos de maneira que eles interfiram entre si.
Um protocolo de bloqueio é um conjunto de regras que devem ser seguidas por cada 
transação (e forçadas pelo SGBD) para assegurar que, mesmo que ações de diversas 
transações possam ser intercaladas, o efeito geral seja idêntico à execução de todas 
as transações em alguma ordem serial. Um bloqueio é um mecanismo utilizado para 
controlar o acesso aos objetos do banco de dados. Dois tipos de bloqueios são normal-
mente suportados por um SGBD: bloqueios compartilhados em um objeto podem ser 
mantidos por duas transações diferentes ao mesmo tempo, mas um bloqueio exclusivo 
em um objeto assegura que nenhuma outra transação mantenha nenhum bloqueio 
nesse objeto.
Visão Geral sobre Sistemas de Banco de Dados 15
Suponha que o seguinte protocolo de bloqueio seja seguido: Toda transação tem 
início obtendo um bloqueio compartilhado em cada objeto de dado que ele necessita ler 
e um bloqueio exclusivo em cada objeto de dado que ele precisa modificar, e então li-
bera todos os seus bloqueios após completar todas as ações. Considere duas transações 
T 1 e T 2 tais que T 1 deseja modificar um objeto de dado e T 2 deseja ler o mesmo 
objeto. Intuitivamente, se a solicitação de T 1 por um bloqueio exclusivo no objeto for 
atendida primeiro, T 2 não pode ter sua execução continuada até que T 1 libere esse 
bloqueio, pois a solicitação de T 2 por um bloqueio compartilhado não será atendida 
pelo SGBD até então. Assim, todas as ações de T 1 serão completadas antes que qual-
quer uma das ações de T2 sejam iniciadas. Trataremos de bloqueio com mais detalhes 
nos capítulos 16 e 17.
1.7.2 Transações Incompletas e Falhas de Sistema
As transações podem ser interrompidas antes de executadas por completo por uma va-
riedade de razões, por exemplo, uma falha de sistema. Um SGBD deve assegurar que 
as alterações realizadas por tais transações incompletas sejam removidas do banco de 
dados. Por exemplo, se o SGBD estiver no meio da transferência do valor em dinhei-
ro da conta A para a conta B, e debitou da primeira conta, mas ainda não creditou 
na segunda quando ocorreu a falha, o valor debitado da conta A deve ser restaurado 
quando o sistema voltar a funcionar após a falha.
Para fazer isso, o SGBD mantém um log de todas as escritas no banco de dados. 
Uma propriedade crucial do log é a de que cada ação de escrita deve ser registrada no 
log (em disco) antes que a alteração correspondente seja refletida no banco de dados 
propriamente dito — caso contrário, se o sistema falhar exatamente após a alteração 
ser feita no banco de dados, mas antes da alteração ser registrada no log, o SGBD 
será incapaz de detectar e desfazer essa alteração. Essa propriedade é chamada Write-
Ahead Log (Gravação Antecipada do Log) ou WAL. Para assegurar essa propriedade, 
o SGBD deve ser capaz de forçar seletivamente a escrita de uma página da memória 
no disco.
O log também é utilizado para assegurar que as alterações realizadas por uma tran-
sação completada com sucesso não sejam perdidas por causa de uma falha no sistema, 
como explicado no Capítulo 18. Restaurar o banco de dados a um estado consistente 
após uma falha no sistema pode ser um processo lento, uma vez que o SGBD deve 
assegurar que os efeitos de todas as transações que completaram antes da falha sejam 
restaurados, e que os efeitos das transações incompletas sejam desfeitos. O tempo ne-
cessário para a recuperação de uma falha pode ser reduzido forçando periodicamente o 
registro de alguma informação no disco; esta operação periódica é chamada ponto de 
verificação (checkpoint).
1.7.3 Pontos a Observar
Em resumo, há três pontos a lembrar com respeito ao suporte de SGBD ao controle 
de concorrência e à recuperação:
1. Todo objeto que é lido ou escrito por uma transação é primeiro bloqueado em modo 
compartilhado ou exclusivo, respectivamente. Bloquear um objeto restringe sua 
disponibilidade para outras transações e, assim, afeta o desempenho.
2. Para a manutenção de um log eficiente, o SGBD deve ser capaz de forçar seleti-
vamente a escrita de uma coleção de páginas da memória principal no disco. O 
suporte do sistema operacional a esta operação nem sempre é satisfatório.
16 CAPÍTULO 1
3. O uso de pontos de verificação periódicos pode reduzir o tempo necessário de recu-
peração de uma falha. Obviamente, isso deve ser balanceado contra o fato de que o 
uso de pontos de verificação com muita freqüência possa diminuir a velocidade da 
execução normal.
1.8 ESTRUTURA DE UM SGBD
A Figura 1.3 ilustra a estrutura (com alguma simplificação) de um SGBD típico com 
base no modelo de dados relacional.
Usuários inexperientes (clientes, agentes de viagem etc.)
Usuários experientes, programadores de
aplicativo, administradores de banco de dados
Formulários Web Front-ends dos Aplicativos Interface SQL
COMANDOS SQL
ilustra o fluxo de comando
ilustra interaçãoExecutor de Plano Analisador Sintático
Avaliador de Operador Otimizador
Mecanismo
de Avaliação
de Consulta
Gerenciador
de Transações
Arquivos e Métodos de Acesso
Gerenciador
de
Recuperação
Gerenciador de Buffer
Gerenciador de Espaço em Disco
Gerenciador
de Bloqueio
SGBDControle deConcorrência
Arquivos
de Índices
Catálogo de Sistema
ilustra referências
BANCO DE DADOSArquivos de Dados
Figura 1.3 Arquitetura de um SGBD.
O SGBD aceita comandos SQL gerados de uma variedade de interfaces de usuário, 
produz planos de avaliação de consulta, executa estes planos no banco de dados, e 
retorna as respostas. (Esta é a simplificação: os comandos SQL podem ser embutidos 
em programas de aplicativo em linguagem hospedeira, como, por exemplo, programas 
Java ou COBOL. Ignoramos esses aspectos para concentrar-nos na funcionalidade 
básica do SGBD.)
Quando um usuário emite uma consulta, a consulta sintaticamente analisada é 
apresentada a um otimizador de consulta, que usa a informação sobre como o dado é 
armazenado para produzir um plano de execução eficiente para processar a consulta. 
Um plano de execução é um projeto para processar uma consulta, normalmente repre-
sentado como uma árvore de operadores relacionais (com anotações que contêm infor-
mações detalhadas adicionais sobre quais métodos de acesso usar etc.). Discutimos a 
otimização de consulta nos Capítulos 12 e 15. Os operadores relacionais servem como 
blocos de construção para processar consultas elaboradas sobre os dados. A implemen-
tação desses operadores é discutida nos Capítulos 12 e 14.
O código que implementa os operadores relacionais situa-se acima da camada de 
arquivos e métodos de acesso. Essa camada suporta o conceito de um arquivo, que, em 
um SGBD, é uma coleção de páginas ou uma coleção de registros. Os arquivos heap, 
Visão Geral sobre Sistemasde Banco de Dados 17
ou arquivos de páginas não ordenadas, assim como os índices, são suportados. Além 
de controlar as páginas de um arquivo, essa camada organiza as informações dentro de 
uma página. Os aspectos relacionados a arquivos e armazenamento no nível de página 
são tratados no Capítulo 9. As organizações de arquivo e os índices são tratados no 
Capítulo 8.
O código da camada de arquivos e métodos de acesso situa-se acima do gerenciador 
de buffer, que carrega as páginas do disco para a memória principal conforme neces-
sário em resposta às solicitações de leitura. O gerenciamento de buffer é discutido no 
Capítulo 9.
A camada mais inferior do software do SGBD trata do gerenciamento do espaço no 
disco, onde os dados são armazenados. As camadas superiores alocam, liberam, lêem e 
escrevem páginas através de rotinas fornecidas por essa camada, chamada gerenciador de 
espaço em disco. Essa camada é discutida no Capítulo 9.
O SGBD suporta a concorrência e a recuperação de falha planejando cuidadosa-
mente as solicitações de usuário e mantendo um log de todas as alterações realizadas 
no banco de dados. Os componentes de SGBD associados com o controle de concorrên-
cia e recuperação incluem o gerenciador de transações, que assegura que as transações 
solicitem e liberem bloqueios de acordo com um protocolo adequado de bloqueio e pla-
neja a execução das transações; o gerenciador de bloqueio, que controla as requisições 
por bloqueio e concede o direito de bloqueio nos objetos de banco de dados quando eles 
se tornam disponíveis; e o gerenciador de recuperação, que é responsável por manter 
um log e restaurar o sistema a um estado consistente após a ocorrência de uma falha. 
O gerenciador de espaço em disco, gerenciador de buffer e as camadas de arquivo e 
métodos de acesso devem interagir com esses componentes. Discutiremos o controle de 
concorrência e recuperação com mais detalhes no Capítulo 16.
1.9 PESSOAL QUE TRABALHA COM BANCO DE DADOS
Uma grande variedade de pessoas está relacionada com a criação e uso de banco de da-
dos. Obviamente, há desenvolvedores de banco de dados que constroem o software do 
SGBD, e usuários finais que desejam armazenar e utilizar os dados de um SGBD. Os 
desenvolvedores de banco de dados trabalham para fabricantes como IBM ou Oracle. 
Os usuários finais vêm de um crescente número de áreas diversas. Conforme os dados 
crescem em complexidade e volume, e têm sido cada vez mais reconhecidos como um 
ativo principal, a importância de mantê-los profissionalmente em um SGBD está se 
difundindo amplamente. Vários usuários finais simplesmente utilizam aplicativos es-
critos por programadores de aplicativo de banco de dados (veja a seguir) e, portanto, 
requerem pouco conhecimento técnico sobre o software do SGBD. É óbvio que os usuários 
mais experientes, que fazem uso mais extensivo de um SGBD, como escrever suas próprias 
consultas, requerem uma compreensão mais aprofundada de seus recursos.
Além dos usuários finais e desenvolvedores, duas outras classes de pessoas estão 
relacionadas com um SGBD: programadores de aplicativo e administradores de banco 
de dados.
Os programadores de aplicativo de banco de dados desenvolvem pacotes que faci-
litam o acesso aos dados pelos usuários finais, que normalmente não são profissionais 
em computação, utilizando as linguagens hospedeiras ou de dados e ferramentas de 
software fornecidas pelos fabricantes de SGBD. (Tais ferramentas incluem editores 
de relatórios, planilhas, pacotes estatísticos e assim por diante.) Os programas de 
aplicativo devem acessar os dados idealmente através do esquema externo. É possível 
escrever aplicativos que acessam dados em um nível inferior, mas tais aplicativos com-
prometeriam a independência dos dados.
18 CAPÍTULO 1
Um banco de dados pessoal é mantido tipicamente pelo indivíduo que o possui e 
o utiliza. Entretanto, bancos de dados corporativos ou empresariais normalmente são 
importantes e complexos o suficiente para que a tarefa de projetar e manter o banco de 
dados seja confiada a um profissional, chamado administrador de banco de dados (DBA 
— database administrator). O DBA é responsável por várias tarefas críticas:
Projeto dos Esquemas Conceitual e Físico: O DBA é responsável por interagir com 
os usuários do sistema para compreender quais dados devem ser armazenados no 
SGBD e como eles serão mais provavelmente utilizados. Baseado nesse conhecimen-
to, o DBA deve projetar o esquema conceitual (decidir quais relações armazenar) e 
o esquema físico (decidir como armazená-las). O DBA também pode projetar partes 
extensamente utilizadas do esquema externo, embora os usuários provavelmente 
estendam esse esquema criando visões adicionais.
Segurança e Autorização: O DBA é responsável por assegurar que o acesso não 
autorizado aos dados não seja permitido. Em geral, nem todos devem ser capazes 
de acessar todos os dados. Em um SGBD relacional, os usuários podem ganhar 
permissão de acesso apenas a determinadas visões e relações. Por exemplo, embora 
se possa permitir que os alunos localizem as matrículas do curso e quem ministra 
determinado curso, não é desejável que os alunos vejam os salários dos professores 
ou as informações de notas dos demais alunos. O DBA pode forçar essa política 
concedendo permissão de apenas leitura para a visão InfoCurso.
Disponibilidade de Dados e Recuperação de Falhas: O DBA deve tomar medidas 
para assegurar que, caso o sistema falhe, os usuários possam continuar a acessar o 
máximo possível dos dados não corrompidos. O DBA também deve restaurar os 
dados a um estado consistente. O SGBD fornece suporte de software para essas 
funções, mas o DBA é responsável por implementar os procedimentos para realizar 
o backup dos dados periodicamente e manter os logs da atividade do sistema (para 
facilitar a recuperação de uma falha).
Sintonização de Banco de Dados: É bem provável que as necessidades dos usuários 
evoluam ao longo do tempo. O DBA é responsável por modificar o banco de dados, 
em particular os esquemas conceituais e físicos, para assegurar desempenho adequa-
do conforme os requisitos sofrem alterações.
1.10 QUESTÕES DE REVISÃO
As respostas a essas questões de revisão podem ser encontradas nas seções listadas.
Quais são os benefícios principais de utilizar um SGBD para gerenciar os dados de 
um aplicativo envolvendo muito acesso aos dados? (Seções 1.1, 1.4)
Quando você armazenaria dados em um SGBD em vez de em arquivos de sistema 
operacional e vice-versa? (Seção 1.3)
O que é um modelo de dados? O que é um modelo de dados relacional? O que é 
independência de dados e como um SGBD a suporta? (Seção 1.5)
Explique as vantagens de utilizar uma linguagem de consulta em vez de programas 
personalizados para processar dados. (Seção 1.6)
O que é uma transação? Que garantias um SGBD oferece com respeito a transa-
ções? (Seção 1.7)
O que são bloqueios em um SGBD e por que eles são utilizados? O que é um re-
gistro de log write-ahead, e por que ele é utilizado? O que é o uso de pontos de 
verificação e por que são utilizados? (Seção 1.7)
■
■
■
■
■
■
■
■
■
■
Visão Geral sobre Sistemas de Banco de Dados 19
Identifique os diferentes papéis de administradores de banco de dados, programa-
dores de aplicativo e usuários finais de um banco de dados. Quem necessita ter o 
maior conhecimento sobre sistemas de banco de dados? (Seção 1.9)
EXERCÍCIOS
Exercício 1.1 Por que você escolheria um sistema de banco de dados em vez de armazenar os dados em 
arquivos de sistema operacional? Quando faria sentido não utilizar um sistema de banco de dados?
Exercício 1.2 O que é independência lógica de dados e por que isso é importante?
Exercício 1.3 Explique a diferença entre independência lógica e física de dados.
Exercício 1.4 Explique a diferença entre esquemas externos, físicos e conceituais. Como essascama-
das diferentes de esquema se relacionam aos conceitos de independência lógica e física dos dados?
Exercício 1.5 Quais são as responsabilidades de um DBA? Se assumirmos que o DBA nunca estará 
interessado em executar suas próprias consultas, o DBA ainda assim precisaria compreender a oti-
mização de consultas? Por quê?
Exercício 1.6 Scrooge McNugget deseja armazenar informações (nomes, endereços, descrições de 
momentos desagradáveis etc.) sobre os vários funcionários de sua folha de pagamentos. Não surpre-
endentemente, o volume de dados o compele a comprar um sistema de banco de dados. Para econo-
mizar dinheiro, ele deseja comprar um com o menor número possível de recursos, e planeja executá-lo 
como um aplicativo independente em seu PC. Naturalmente, Scrooge não planeja compartilhar sua 
lista com ninguém. Indique quais dos seguintes recursos de SGBD justificam a compra do sistema; em 
cada caso, também indique por que Scrooge deve (ou não deve) pagar por esse recurso do sistema.
1. Ferramenta de segurança.
2. Controle de concorrência.
3. Recuperação de falha.
4. Um mecanismo de visão.
5. Uma linguagem de consulta.
Exercício 1.7 Qual dos seguintes itens desempenha um papel importante na representação de infor-
mações sobre o mundo real em um banco de dados? Explique brevemente.
1. A linguagem de definição de dados.
2. A linguagem de manipulação de dados.
3. O gerenciador de buffer.
4. O modelo de dados.
Exercício 1.8 Descreva a estrutura de um SGBD. Se seu sistema operacional for atualizado para 
suportar algumas funções novas sobre os arquivos de SO (por exemplo, a capacidade de forçar algu-
ma seqüência de bytes no disco), quais camadas do SGBD você deveria reescrever para aproveitar 
a vantagem dessas novas funções?
Exercício 1.9 Responda às seguintes questões:
1. O que é uma transação?
2. Por que um SGBD intercala as ações de diferentes transações em vez de executar as transações 
uma após a outra?
■
20 CAPÍTULO 1
3. O que deve um usuário garantir com respeito à consistência de uma transação e do banco de 
dados? O que deve um SGBD garantir com respeito à execução concorrente de diversas tran-
sações e consistência de banco de dados?
4. Explique o protocolo de bloqueio de duas fases.
5. O que é a propriedade WAL, e por que ela é importante?
EXERCÍCIO COM BASE EM PROJETO
Exercício 1.10 Use um navegador Web para examinar a documentação HTML do Minibase. Tente 
reconhecer a sua arquitetura global.
NOTAS BIBLIOGRÁFICAS
A evolução dos sistemas de gerenciamento de banco de dados é investigada em [289]. O uso de 
modelos de dados para descrever dados do mundo real é discutido em [423], e [425] contém uma 
taxonomia dos modelos de dados. Os três níveis de abstração foram introduzidos em [186, 712]. O 
modelo de dados de rede é descrito em [186], e [775] discute diversos sistemas comerciais baseados 
neste modelo. [721] contém uma boa coleção anotada de artigos orientados a sistema sobre geren-
ciamento de banco de dados.
Outros textos que tratam de sistemas de gerenciamento de banco de dados incluem [204, 245, 
305, 339, 475, 574, 689, 747, 762]. [204] fornece uma discussão detalhada do modelo relacional do 
ponto de vista conceitual e é notável pela sua extensa bibliografia com anotações. [574] apresenta 
uma perspectiva orientada a desempenho, com referências a diversos sistemas comerciais. [245] e 
[689] oferecem uma ampla cobertura sobre os conceitos de sistemas de banco de dados, incluindo 
uma discussão dos modelos de dados hierárquico e de rede. [339] enfatiza a conexão entre linguagens 
de consulta de banco de dados e a programação lógica. [762] enfatiza os modelos de dados. Desses 
textos, [747] fornece a discussão mais detalhada dos aspectos teóricos. Os textos dedicados aos 
aspectos teóricos incluem [3, 45, 501]. O manual [744] inclui uma seção sobre bancos de dados que 
contém artigos introdutórios de pesquisa sobre vários tópicos.