Introduo

Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a
um conjunto de programas para acesso a esses dados. O conjunto de dados, comumente chamado banco de
dados, contm informaes sobre uma empresa em particular. O principal objetivo de um SGBD proporcionar
um ambiente tanto conveniente quanto eficiente para a recuperao e armazenamento das informaes dos
bancos de dados.
Sistemas de banco de dados so projetados para gerir grandes volumes de informaes. O gerenciamento
de informaes implica a definio das estruturas de armazenamento de informaes e a definio dos
mecanismos para a manipulao dessas informaes. Ainda, um sistema de banco de dados deve garantir a
segurana das informaes armazenadas contra eventuais problemas com o sistema, alm de impedir tentativas
de acesso no autorizadas. Se os dados so compartilhados por diversos usurios, o sistema deve evitar a
ocorrncia de resultados anmalos.
A importncia da informao na maioria das organizaes que estabelece o valor do banco de dados
tem determinado o desenvolvimento de um grande conjunto de conceitos e tcnicas para a administrao eficaz
desses dados.
Objetivos de um Sistema de Banco de dados
Considere a rea de um banco responsvel por todas as informaes de seus cliente e de suas contaspoupana. Um modo de guardar as informaes no computador armazen-las em sistemas de arquivos
permanentes. Para permitir aos usurios a utilizao dessas informaes, o sistema deve apresentar um conjunto
de programas de aplicaes que tratam esses arquivos, incluindo:
Um programa para dbito e crdito na contabilidade.
Um programa para incluir novos registros na contabilidade.
Um programa para balano da contabilidade.
Um programa para gerar relatrios mensais.
Essas aplicaes foram desenvolvidas por programadores a fim de atender s necessidades das
organizaes bancrias.
Novos programas foram incorporados a esses sistemas para atender a necessidades que foram surgindo.
Por exemplo, suponha que novas regras sejam promulgadas pelo governo obrigando que os bancos ofeream
meios para a checagem de suas contas. Com isso, novos arquivos permanentes sero criados contendo dados
para checagem de todas as contas mantidas pelo banco e novos programas de aplicaes sero necessrios a fim
de adequar-se a nova situao, que de fato no foi originada pela caderneta de poupana, como o tratamento de
saldos negativos. Assim, conforme passa o tempo, mais arquivos e mais programas de aplicaes so adicionados
ao sistema.
O sistema de processamento de arquivos tpico que acabamos de descrever pode ser aceito pelos
sistemas operacionais convencionais. Registros permanentes so armazenados em vrios arquivos e diversos
programas de aplicao so escritos para extrair e gravar registros nos arquivos apropriados. Antes do advento
dos SGBDs, as organizaes usavam esses sistemas para armazenar informaes.
Obter informaes organizacionais em sistemas de processamento de arquivos apresenta numerosas
desvantagens:
Inconsistncia e redundncia de dados. J que arquivos e aplicaes so criados mantidos por diferentes
programadores, em geral durando longos perodos de tempo, comum que os arquivos possuam
formatos diferentes e os programas sejam escritos em diversas linguagens de programao. Ainda mais, a
mesma informao pode ser repetida em diversos lugares (arquivos). Por exemplo, o endereo e o
telefone de um cliente em particular pode aparecer tanto no arquivo de contas quanto no arquivo de
checagem de contas. Esta redundncia aumenta os custos de armazenamento e acesso. Ainda, pode
originar inconsistncia de dados; isto , as vrias cpias dos dados podero divergir ao longo do tempo.
74

Por exemplo, a mudana de endereo de um cliente pode refletir nos arquivos de contas, mas no ser
alterada no sistema como um todo.
Dificuldade de acesso aos dados. Suponha que um dos empregados da empresa precise de uma relao
com os nomes de todos os cliente que moravam em determinada rea de acidade cujo CEP 78733. O
empregado pede, ento, ao departamento de processamento de dados que crie tal relao. Como esse
tipo de solicitao no foi prevista no projeto do sistema no h nenhuma aplicao disponvel para
atende-la. No entanto, h uma aplicao para gerar a relao de todos os clientes da empresa. Assim, o
empregado tem duas alternativas: separar manualmente da lista de todos os clientes aqueles de que
necessita ou requisitar ao departamento de processamento de dados um programador para escrever o
programa necessrio. Ambas as alternativas so, obviamente, insatisfatrias. Suponha que o tal programa
seja escrito e que dias depois o mesmo empregado necessite selecionar os clientes que possuem saldo
superior a dez mil dlares. Como esperado, tal programa no existe. Novamente o empregado tem as
mesmas duas opes, nenhuma delas insatisfatria. O fato que um ambiente com um sistema de
processamento de arquivos convencional no atende s necessidades de recuperao de informaes de
modo eficiente. Sistemas mais efetivos (com respostas mais rpidas e adequadas) para a recuperao de
informaes precisam ser desenvolvidos.
Isolamento de dados. Como os dados esto dispersos em vrios arquivos, e estes arquivos podem
apresentar diferentes formatos, difcil escrever novas aplicaes para recuperao apropriada dos
dados.
Problema de integridade. Os valores dos dados atribudos e armazenados em um banco de dados devem
satisfazer certas restries para manuteno da consistncia. Por exemplo, o balano de uma conta
bancaria no pode cair abaixo de um determinado valor. Os programadores determinam o cumprimento
dessas restries por meio da adio de cdigo apropriado aos vrios programas de aplicaes.
Entretanto, quando aparecem novas restries difcil alterar todos os programas para increment-las. O
problema ampliado quando as restries atingem diversos itens de dados em diferentes arquivos.
Problemas de atomicidade. Um sistema computacional, como qualquer outro dispositivo mecnico ou
eltrico, est sujeito a falhas. Em muitas aplicaes crucial assegurar que, uma vez detectada uma falha,
os dados sejam salvos em seu ltimo estado consistente, anterior a ela. Considere um programa para
transferir 50 dlares da conta A para uma conta B. Se ocorrer falha no sistema durante sua execuo,
possvel que os 50 dlares sejam debitados da conta A sem serem creditados na conta B, criando um
estado inconsistente no banco de dados. Logicamente, essencial para a consistncia do banco de dados
que ambos, dbito e crdito, ocorram ou nenhum deles seja efetuado. Isto , a transferncia de fundos
deve ser uma operao atmica deve ocorrer por completo ou no ocorrer. difcil garantir essa
propriedade em um sistema convencional de processamento de arquivos.
Anomalias no acesso concorrente. Muitos sistemas permitem atualizaes simultneas nos dados para
aumento do desempenho do sistema como um todo e para melhores tempos de resposta. Nesses tipos
de ambiente, a interao entre atualizaes concorrentes pode resultar em inconsistncia de dados.
Suponha que o saldo de uma conta bancria A seja 500 dlares. Se dois clientes retiram fundos da conta
A (digamos 50 e 100 dlares, respectivamente), essas operaes, ocorrendo simultaneamente, podem
resultar em erro (ou gerar inconsistncia). Suponha que, na execuo dos programas, ambos os clientes
leiam o saldo antigo e retirem, cada um, seu valor correspondente, sendo o resultado armazenado. Os
dois programas concorrendo, ambos leem o valor 500 dlares, resultado, em 450 e 400 dlares,
respectivamente. Dependendo de qual deles registre seu resultado primeiro, o saldo da conta A ser 450
ou 400 dlares, em vez do valor correto de 350 dlares. Para resguardar-se dessa possiblidade, o sistema
deve manter algum tipo de superviso. Como os dados podem sofrer acesso de diferentes programas, os
quais no foram coordenados previamente, a superviso bastante dificultada.
Problemas de segurana. Nem todos os usurios de banco de dados esto autorizados ao acesso a todos
os dados. Por exemplo, em um sistema bancrio, os funcionrios do departamento pessoal devem ter
75

acesso apenas ao conjunto de pessoas que trabalham no banco. Uma vez que os programas de aplicao
so inseridos no sistema como um todo, difcil garantir a efetividade das regras de segurana.
Estas dificuldades, entre outras, provocaram o desenvolvimento dos SGBDs. A seguir mostraremos os
conceitos e algoritmos que foram desenvolvidos para os sistemas de banco de dados que resolvem os problemas
mencionados anteriormente. Uma aplicao tpica em banco de dados armazena um grande nmero de registros,
sendo que estes registros so frequentemente simples e pequenos.
Viso dos Dados
Um SGBD uma coleo de arquivos e programas inter-relacionados que permitem ao usurio o acesso
para consultas e alteraes desses dados. O maior benefcio de um banco de dados proporcionar ao usurio
uma viso abstrata dos dados. Isto , o sistema acaba por ocultar determinados detalhes sobre a forma de
armazenamento e manuteno desses dados.
Abstrao de Dados
Para que se possa usar um sistema, ele precisa ser eficiente na recuperao de informaes. Esta
eficincia est relacionada forma pela qual foram projetadas as complexas estruturas de representao desses
dados no banco de dados. J que muitos dos usurios dos sistemas de banco de dados no so treinados em
computao, os tcnicos em desenvolvimento de sistemas omitem essa complexidade desses usurios por meio
dos diversos nveis de abstrao de modo a facilitar a interao dos usurios com o sistema:
Nvel fsico. o mais baixo nvel de abstrao que descreve como esses dados esto de fato
armazenados. No nvel fsico, estruturas de dados complexas de nvel baixo so descritas em detalhes.
Nvel lgico. Este nvel mdio de abstrao descreve quais dados esto armazenados no banco de dados
e quais os inter-relacionamentos entre eles. Assim, o banco de dados como um todo descrito em
termos de um nmero relativamente pequeno de estruturas simples. Embora a implementao dessas
estruturas simples no nvel lgico possa envolver estruturas complexas no nvel fsico, o usurio do nvel
lgico no necessariamente precisa estar familiarizado com essa complexidade. O nvel lgico de
abstrao utilizado pelos administradores do banco de dados que precisam decidir quais informaes
devem pertencer ao banco de dados.
Nvel de viso. O mais alto nvel de abstrao descreve apenas parte do banco de dados. A despeito das
estruturas simples do nvel lgico, alguma complexidade permanece devido ao tamanho dos banco de
dados. Muitos dos usurios do banco de dados no precisam conhecer todas as suas informaes. Pelo
contrrio, os usurios normalmente utilizam apenas parte do banco de dados. Assim, para que estas
interaes sejam simplificadas, um nvel de viso definido. O sistema pode proporcionar diversas vises
do mesmo banco de dados.

76

O inter-relacionamento entre esses trs nveis de abstrao est ilustrado na fig. 1.1.
Uma analgica com o conceito de tipos de dados em linguagens de programao pode ajudar a esclarecer
a distino entre os nveis de abstrao. As linguagens de programao de mais alto nvel do suporte noo de
tipos de dados. Por exemplo, nas linguagens semelhantes ao Pascal, podemos declarar um registro como se
segue:

Esse cdigo define um novo registro chamado cliente com quatro campos. Cada campo tem um nome e
um tipo a ele associado. Um banco pode ter diversos tipos de registro, incluindo:
conta, com os campos nmero_conta e saldo;
empregado, com os campos nome_empregado e salario.
No nvel fsico, um registro de cliente, conta ou empregado pode ser descrito como um bloco consecutivo
de memria (p.e., palavras ou bytes). O compilador esconde esse nvel de detalhes dos programadores.
Analogamente, o sistema de banco de dados esconde muitos dos detalhes de armazenamento em nvel mais
baixo dos programadores do banco de dados. Os administradores de banco de dados podem estar familiarizados
com certos detalhes da organizao fsica dos dados.
No nvel lgico, cada registro descrito por um tipo definido, como ilustrado no segmento de cdigo de
programa visto, assim como definida a inter-relao entre esses tipos de registros. Os programadores trabalham
com a linguagem de programao nesse nvel de abstrao. Da mesma forma, os administradores de banco de
dados, usualmente, trabalham nesse nvel de abstrao.
Finalmente, no nvel de viso, os usurios do computador veem um conjunto de programas de aplicao
que esconde os detalhes dos tipos de dados. Nesse nvel, algumas vises do banco de dados so definidas e os
usurios tm acesso a essas vises. Mais do que esconder detalhes prprios do nvel lgico, essas vises tambm
fornecem mecanismos de segurana, de modo a restringir o acesso dos usurios a determinadas partes do banco
de dados. Por exemplo, em um banco, as telefonistas devem ter acesso apenas s informaes dos extratos
bancrios dos clientes, no devem ter acesso a informaes salariais dos empregados do banco.
Instncias e Esquemas
Um banco de dados muda ao longo do tempo por meio das informaes que neles so inseridas ou
excludas. O conjunto de informaes contidas em determinado banco de dados, em um dado momento
chamado instncia do banco de dados. O projeto geral do banco de dados chamado esquema. Os esquemas so
alterados com pouca frequncia.
Analogias com conceitos de linguagem de programao, como tipos de dados, variveis e valores, so
teis aqui. Voltando definio do registro clientes, note que, na declarao de seu tipo, no definimos qualquer
varivel. Para declarar uma varivel em linguagens semelhantes ao Pascal, escrevemos
var cliente1: cliente;
A varivel cliente1 corresponde agora a uma rea de memria que contm um registro tipo cliente.
Um esquema de banco de dados corresponde definio do tipo em uma linguagem de programao.
Uma varivel de um tipo tem um valor em particular em dado instante. Assim, esse valor corresponde a uma
instncia do esquema do banco de dados.
Os sistemas de banco de dados apresentam diversos esquemas, referentes aos nveis de abstrao que
discutimos. No nvel mais baixo h o esquema fsico; no nvel intermedirio, o esquema lgico; e no nvel mais
77

alto, os subesquemas. Em geral, os sistemas de banco de dados do suporte a um esquema fsico, um esquema
lgico e vrios subesquemas.
Independncia de Dados
Os sistemas de banco de dados apresentam diversos esquemas, referentes ao nveis de abstrao j
discutidos. No nvel mais baixo h o esquema fsico; no nvel intermedirio, o esquema lgico; e no nvel mais
alto, os subesquemas. Em geral, os sistemas de banco de dados do suporte a um esquema fsico, um esquema
lgico e vrios subesquemas.
Independncia de Dados
A capacidade de modificar a definio dos esquemas em determinado nvel, sem afetar o esquema
superior, chamado independncia de dados. Existem dois nveis de independncia de dados:
1. Independncia de dados fsica a capacidade de modificar o esquema fsico sem que, com isso, qualquer
programa de aplicao precise ser reescrito. Modificaes no nvel fsico so necessrias, ocasionalmente,
para aprimorar o desempenho.
2. Independncia de dados lgica a capacidade de modificar o esquema lgica sem que, com isso,
qualquer programa de aplicao precise ser reescrito. Modificaes no nvel lgico so necessrias
sempre que uma estrutura lgica do banco de dados alterada (p.e., quando novas moedas so inseridas
no sistema de um banco).
A independncia de dados lgica mais difcil de ser alcanada que a independncia fsica, uma vez que
os programas de aplicao so mais fortemente dependentes da estrutura lgica dos dados do que de seu acesso.
O conceito de independncia de dados de vrias formas similar ao conceito de tipo de dados
empregado nas linguagens modernas de programao. Ambos os conceitos omitem detalhes de implementao
do usurio, permitindo que ele se concentre em sua estrutura geral em vez de se concentrar nos detalhes
tratados no nvel mais baixo.
Modelo de Dados
Sob a estrutura do banco de dados est o modelo de dados: um conjunto de ferramentas conceituais
usadas para a descrio dos dados, relacionamentos entre dados, semntica de dados e regras de consistncia.
Os vrios modelos que vm sendo desenvolvidos so classificados em trs diferentes grupos: modelos lgicos
com base em objetos, modelos lgicos com base em registros e modelos fsicos.
Modelos Lgicos com Base em Objetos
Os modelos lgicos com base em objetos so usados na descrio do nvel lgico e de vises. So
caracterizados por dispor de recursos de estruturao bem mais flexveis e por viabilizar a especificao explcita
das restries de dados. Existem vrios modelos nessa categoria, e outros ainda esto por surgir. Alguns so
amplamente conhecidos, como:
Modelo entidade-relacionamento.
Modelo orientado a objeto.
Modelo semntico de dados.
Modelo funcional de dados.
Modelo Entidade-Relacionamento
O modelo de dados entidade-relacionamento (E-R) tem por base a percepo do mundo real como um
conjunto de objetos bsicos, chamados entidades, e do relacionamento entre eles. Uma entidade uma coisa
ou um objeto do mundo real que pode ser identificado por outros objetos. Por exemplo, cada pessoa uma
entidade, as contas dos clientes de um banco tambm podem ser consideradas entidades. As entidades soa
78

descritas no banco de dados por meio de seus atributos. Por exemplo, os atributos nmero_conta e saldo
descrevem uma conta bancria em particular. Um relacionamento uma associao entre entidades. Por
exemplo, um relacionamento depositante associa um cliente a cada conta que ele possui. O conjunto de todas as
entidades de um mesmo tipo, assim como o conjunto de todos os relacionamentos de mesmo tipo so
denominados conjunto de entidades e conjunto de relacionamentos, respectivamente.
Alm das entidades e dos relacionamento, o modelo E-R representa certas regras, as quais o contedo do
banco de dados precisa respeitar. Uma regra importante o mapeamento das cardinalidades, as quais expressam
o nmero de entidades s quais a outra entidade se relaciona por meio daquele conjunto de relacionamentos.
Toda estrutura lgica do banco de dados pode ser expressa graficamente por meio do diagrama E-R, cujo
construtores dos seguintes componentes so:
Retngulos, que representam os conjuntos de entidades.
Elipses, que representam os atributos.
Losangos, que representam os relacionamentos entre os conjuntos de entidades.
Linhas, que unem os atributos aos conjuntos de entidades e o conjunto de entidades aos seus
relacionamentos.
Cada componente rotulado com o nome da entidade ou relacionamento que representa. Como ilustrao,
considere uma parte do sistema bancrio composta pelos clientes e suas respectivas contas. O diagrama E-R
correspondente mostrado na fig. 1.2.

Modelo Orientado a Objetos

Como o modelo E-R, o modelo orientado a objetos tem por base um conjunto de objetos. Um objeto
contm valores armazenados em variveis instncias dentro do objeto. Um objeto tambm contm conjuntos de
cdigos que operam esse objeto. Esses conjuntos de cdigos so chamados mtodos.
Os objetos que contm os mesmos tipos de valores e os mesmos mtodos so agrupados em classes.
Uma classe pode ser vista como uma definio de tipo para objetos. Essa combinao compacta de dados e
mtodos abrangendo uma definio de tipo similar ao tipo abstrato em uma linguagem de programao.
O nico modo pelo qual um objeto pode conseguir acesso aos dados de outro objeto por meio do
mtodo desse outro objeto. Essa ao chamada de enviar mensagem ao objeto. Assim, a interface de mtodos
de um objeto define a parte externa visvel de um objeto. A parte interna de um objeto as instncias variveis e
o cdigo do mtodo no so visveis externamente. O resultado so dois nveis de abstrao de dados.
Modelos Lgicos com Base em Registros
Modelos lgicos com base em registros so usados para descrever os dados no nvel lgico e de viso. Em
contraste com os modelos com base em objetos, este tipo de modelo usado tanto para especificar a estrutura
lgica do banco de dados quanto para implementar uma descrio de alto nvel.

79

Os modelos com base em registro so assim chamados porque o banco de dados estruturado por meio
de registros de formato fixo de todos os tipos. Cada registro define um nmero fixo de campos ou atributos, e
cada atributo tem um tamanho fixo.
Modelo Relacional
O modelo relacional usa um conjunto de tabelas para representar tanto os dados com a relao entre
eles. Cada tabela possui mltiplas colunas e cada uma possui um nome nico. A fig. 1.3 apresenta um exemplo de
banco de dados relacional condensado em duas tabelas: uma mostrando os clientes do banco e a outra, suas
contas.
Modelo de Rede
Os dados no modelo de rede so representados por um conjunto de registros (como no Pascal) e as
relaes entre estes registros so representados por links (ligaes), as quais podem ser vistas pelos ponteiros. Os
registros so organizados no banco de dados por um conjunto arbitrrio de grficos. A fig. 1.4 apresenta um
exemplo de banco de dados em rede, usando as mesmas informaes da fig. 1.3.
Modelo Hierrquico
O modelo hierrquico similar ao modelo em rede, pois os dados e suas relaes so representados,
respectivamente, por registros e links. A diferena que no modelo hierrquico os registros esto organizados em
arvores em vez de grficos arbitrrios. A fig. 1.5 apresenta um exemplo de modelo de banco de dados
hierrquico, usando as mesmas informaes da fig. 1.4.

80

Diferena entre Modelos

O modelo relacional difere dos modelos hierrquico e em rede por no usar nem ponteiros nem links. Ele
relaciona os registros por valores prprios a eles. Como no necessrio o uso de ponteiros, houve a
possibilidade do desenvolvimento de fundamentos matemticos para sua definio.

81

Modelos Fsicos de Dados

Os modelos fsicos de dados so usados para descrev-los no nvel mais baixo. Em contraste com os
modelos lgicos, h poucos modelos fsicos de dados em uso. Dois deles so amplamente conhecidos: o modelo
unificado (unifying model) e o modelo de partio de memria (frame-memory model).
Os modelos fsicos captam os aspectos de implementao do sistema de banco de dados.
Linguagens de Banco de Dados
Um sistema de banco de dados proporciona dois tipos de linguagens: uma especfica para os esquemas
do banco de dados e outra para expressar consultas e atualizaes.
Linguagens de Definicao de Dados
Um esquema de dados especificado por um conjunto de vises expressas por uma linguagem especial
chamada linguagem de definio de dados (data-definition language DDL). O resultado da compilao dos
parmetros DDLs armazenado em um conjunto de tabelas que constituem um arquivo especial chamado
dicionrio de dados ou diretrio de dados.
Um dicionrio de dados um arquivo de metadados isto , dados a respeito de dados. Em um sistema
de banco de dados, esse arquivo ou diretrio consultado antes que o dado real seja modificado.
A estrutura de memria e o mtodo de acesso usados pelo banco de dados so especificados por um
conjunto de definies em um tipo especial de DDL, chamado linguagem de definio e armazenamento de dados
(data storage and definition language). O resultado da compilao dessas definies um conjunto de instrues
para especificar os detalhes de implementao dos esquemas do banco de dados os detalhes normalmente so
ocultados dos usurios.
Linguagem de Manipulao dos Dados
Os nveis de abstrao j discutidos no se aplicam apenas definio ou estrutura dos dados, mas
tambm a sua manipulao.
Por manipulao de dados entendemos:
82

A recuperao das informaes armazenadas no banco de dados.

Insero de novas informaes no banco de dados.
A remoo de informaes do banco de dados.
A modificao das informaes do banco de dados.

No nvel fsico, precisamos definir algoritmos que permitam o acesso eficiente aos dados. Nos nveis mais
altos de abstrao, enfatizamos a facilidade de uso. O objetivo proporcionar uma interao eficiente entre
homens e sistema.
A linguagem de manipulao de dados (DML) a linguagem que viabiliza o acesso a manipulao dos
dados de forma compatvel ao modelo de dados apropriado. So basicamente dois tipos:
DMLs procedurais exigem que o usurio especifique quais dados so necessrios e como obt-los.
DMLs no procedurais exige que o usurio especifique quais dados so necessrios, sem especificar
como obt-los.
As DMLs no procedurais so normalmente mais fceis de aprender e de usar. Entretanto, como o
usurio no especifica como obter os dados, essas linguagens pode gerar cdigo menos eficiente que os gerados
por linguagens procedurais. Podemos resolver esse tipo de problema por meio de vrias tcnicas de otimizao.
Uma consulta uma solicitao para recuperao de informaes. A parte de uma DML responsvel pela
recuperao de informao chamada linguagem de consultas (query language). Embora tecnicamente incorreto,
comum o uso do termo linguagem de consultas como sinnimo de linguagem de manipulao de dados.
Gerenciamento de Transaes
Frequentemente, muitas operaes em um banco de dados constituem uma nica unidade lgica de
trabalho. Voltamos ao exemplo usado na transferncia de fundos entre contas bancrias, responsvel pelo dbito
na conta A e crdito na conta B. Antes de mais nada, essencial que ocorram ambas as operaes, de crdito e
dbito, ou nenhuma delas dever ser realizada. Isto , ou a transferncia de fundos acontece como um todo ou
nada deve ser feito. Esse tudo-ou-nada chamado atomicidade. Ainda mais, necessrio que a transferncia de
fundos preserve a consistncia do banco de dados. Ou seja, a soma de A+B deve ser preservada. Essas exigncias
de corretismo so chamadas de consistncia. Finalmente, depois da execuo com sucesso da transferncia de
fundos, os novos valores de A e B devem persistir, a despeito das possibilidades de falhas no sistema. Esta
persistncia chamada durabilidade.
Uma transao uma coleo de operaes que desempenha uma funo lgica nica dentro de uma
aplicao do sistema de banco de dados. Cada transao uma unidade de atomicidade e consistncia. Assim,
exigimos que as transaes no violem nenhuma das regras de consistncia do banco de dados. Ou seja, o banco
de dados estava consistente antes do incio da transao e deve permanecer consistente aps o trmino com
sucesso de uma transao. Entretanto, durante a execuo de uma transao, ser necessrio aceitar
inconsistncias temporariamente. Essa inconsistncia temporria, embora necessria pode gerar problemas caso
ocorra uma falha.
responsabilidade do programador definir, de modo apropriado, as diversas transaes, tais que cada
uma preserve a consistncia do banco de dados. Por exemplo, a transao para a transferncia de fundos da
conta A para a conta B poderia ser composta por dois programas distintos: um para dbito na conta A e outro
para crdito na conta B. A execuo destes dois programas um aps o outro ir manter a consistncia do banco
de dados. Entretanto, cada programa executado isoladamente no leva o banco de dados de um para outro
estado inconsistente. Logo, esses programas separados no so transaes.
Assegurar as propriedades de atomicidade e durabilidade tambm responsabilidade do sistema de
banco de dados especialmente, os componentes de gerenciamento de transaes. Na ausncia de falhas, todas
as transaes se completam com sucesso e a atomicidade garantida. No entanto, devido aos vrios tipos de
falhas possveis, uma transao pode no se completar com sucesso. Se estivermos empenhados em garantir a
83

atomicidade, uma transao incompleta no poder comprometer o estado do banco de dados. Assim, o banco
de dados precisa retornar ao estado anterior em que se encontrava antes do incio dessa transao.
responsabilidade do sistema de banco de dados detectar as falhas e recuperar o banco de dados,
garantindo seu retorno a seu ltimo estado consistente.
Por fim, quando muitas transaes atualizam o banco de dados concorrentemente, a consistncia do
banco de dados pode ser violada, mesmo que essas transaes, individualmente, estejam corretas.
responsabilidade do gerenciador de controle de concorrncia controlar a interao entre transaes concorrentes
de modo a garantir a consistncia do banco de dados.
Os sistemas de banco de dados projetados para o uso em computadores pessoais podem no apresentar
todas essas funes.
Administrao de Memria
Normalmente, os banco de dados exigem um grande volume de memria. Um banco de dados
corporativo usualmente medido em termos de gigabytes ou, para banco de dados de grande porte (largest
database), terabytes. Um gigabyte corresponde a 1000 megabytes (1 bilho de bytes) e um terabyte 1 milho
de megabytes (1 trilho de bytes). J que a memria do computador no pode armazenar volumes to grandes de
dados, as informaes so armazenadas em discos. Os dados so transferidos dos discos para a memria quando
necessrio. Uma vez que essa transferncia relativamente lenta comparada velocidade do processador,
imperativo que o sistema de banco de dados estruture os dados de forma a minimizar a necessidade de
movimentao entre disco e memria.
O objetivo de um sistema de banco de dados simplificar e facilitar o acesso aos dados. Vises de alto
nvel ajudam a alcanar esses objetivos. Os usurios do sistema no devem desnecessariamente importunados
com detalhes fsicos relativos implementao do sistema. Todavia, um dos fatores mais importantes de
satisfao ou insatisfao do usurio com um sistema de banco de dados justamente seu desempenho. Se o
tempo de resposta demasiado, o valor do sistema diminui. O desempenho de um sistema de banco de dados
depende da eficincia das estruturas usadas para a representao dos dados, e do quanto esse sistema est apto
a operar essas estruturas de dados. Como acontece com outras reas dos sistemas computacionais, no se trata
somente do consumo de espao e tempo, mas tambm da eficincia de um tipo de operao sobre outra.
Um gerenciador de memria um mdulo de programas para interface entre o armazenamento de dados
em um nvel baixo e consultas e programas de aplicao submetidos ao sistema. O gerenciamento de memria
responsvel pela interao com o gerenciamento de arquivos. Uma linha de dados armazenada no disco usando
os sistema de arquivos que, convencionalmente, fornecido pelo sistema operacional. O gerenciador de memria
traduz os diversos comandos DML em comandos de baixo nvel de sistema de arquivos. Assim, o gerenciador de
memria responsvel pelo armazenamento, recuperao e atualizao de dados no banco de dados.
O Administrador de Banco de Dados
Uma das principais razoes que motivam o uso do SGBDs o controle centralizado tanto dos dados quanto
dos programas de acesso a esses dados. A pessoa que centraliza esse controle do sistema chamado
administrador de dados (DBA). Dentre as funes de um DBA destacamos as seguintes:
Definicao do esquema. O DBA cria o esquema do banco de dados original escrevendo um conjunto de
definies que so transformadas pelo compilador DDL em um conjunto de tabelas armazenadas de
modo permanente no dicionrio de dados.
Esquema e modificaes na organizao fsica. Os programadores realizam relativamente poucas
alteraes no esquema do banco de dados ou na descrio da organizao fsica de armazenamento por
meio de um conjunto de definies que sero usadas ou pelo compilador DDL ou pelo compilador de
armazenamento de dados e definio de dados, gerando modificaes na tabela apropriada, interna ao
sistema (p.e., no dicionrio de dados).

84

Fornecer autorizao de acesso ao sistema. O fornecimento de diferentes tipos de autorizao no acesso

aos dados permite que o administrador de dados regule o acesso dos diversos usurios s diferentes
partes do sistema. Os dados referentes autorizao de acesso so armazenados em uma estrutura
especial do sistema que consultada pelo sistema de banco de dados toda vez que o acesso quele dado
for solicitado.
Especificao de regras de integridade. Os valores dos dados armazenados no banco de dados devem
satisfazer certas restries para manuteno de sua integridade. Por exemplo, o nmero de horas que um
empregado pode trabalhar durante uma semana no deve ser superior a um limite especificado
(digamos, 40 horas). Tal restrio precisa ser explicitada pelo administrador de dados. As regras de
integridade so tratadas por uma estrutura especial do sistema que consultada pelo sistema de banco
de dados sempre que uma atualizao est em curso no sistema.

Usurios de Banco de Dados

A meta bsica de um sistema de banco de dados proporcionar um ambiente para recuperao de
informaes e para o armazenamento de novas informaes no banco de dados. H quatro tipos de usurios de
sistemas de banco de dados, diferenciados por suas expectativas de interao com o sistema.
Programadores de aplicao: so profissionais em computao que interagem com o sistema por meio
de chamadas DML, as quais so envolvidas por programas escritos na linguagem hospedeira (p.e., COBOL,
PL/1, C). Esses programas so comumente referidos como programas de aplicao. Exemplos em um
sistema bancrio incluem programas para gerar relao de cheques pagos, para crdito em contas, para
dbitos em conta ou para transferncia de fundos entre contas.
Uma vez que a sintaxe da DML , em geral, completamente diferente de uma linguagem hospedeira, as chamadas
DML so, normalmente, precedidas por um caractere especial antes que o cdigo apropriado possa ser gerado.
Um pr-processamento, chamado pr-compilador DML, converte os comandos DML para as chamadas normais
em procedimentos da linguagem hospedeira. O programa resultante , ento, submetido ao compilador da
linguagem hospedeira, a qual gera o cdigo de objeto apropriado.
Existem tipos especiais de linguagem de programao que combinam estruturas de controle de
linguagens semelhantes ao Pascal com estruturas de controle para manipulao dos objetos do banco de dados
(p.e., relaes). Estas linguagens, muitas vezes chamadas linguagens de quarta gerao, frequentemente incluem
recursos especiais para facilitar a gerao de formulrios e a apresentao de dados no monitor. A maior parte
dos sistemas de banco de dados comerciais inclui linguagens de quarta gerao.
Usurios sofisticados: interagem com o sistema sem escrever programas. Formulam suas solicitaes ao
banco de dados por meio de linguagens de consultas. Cada uma dessas solicitaes submetida ao
processador de consultas cuja funo quebrar as instrues DML em instrues que o gerenciador de
memria entenda. Os analistas que submetem consultas para explorar dados no banco de dados caem
nessa categoria.
Usurios especialistas: so usurios sofisticados que escrevem aplicaes tradicionais especializadas de
banco de dados que no podem ser classificadas como aplicaes tradicionais em processamento de
dados. Dentre elas esto os sistemas para projetos auxiliados por computador, sistemas especialistas e
sistemas de base de conhecimento, sistemas que armazenam dados de tipos complexos (por exemplo,
dados grficos e de udio) e sistemas para modelagem de ambiente (environment-modeling systems).
Usurios navegantes: so usurios comuns que interagem com o sistema chamando um dos programas
aplicativos permanentes j escritos, como, por exemplo, um usurio que pede a transferncia de 50
dlares da conta A para a B por telefone, usando para isso um programa chamado transfer. Esse
programa pede ao usurio o valor a ser transferido, o nmero da conta para crdito e o nmero da conta
para dbito.
Viso Geral da Estrutura do Sistema
85

Um sistema de banco de dados est dividido em mdulos especficos, de modo a atender a todas as
funes do sistema. Algumas das funes do sistema de banco de dados podem ser fornecidas pelo sistema
operacional. Na maioria das vezes, o sistema operacional do computador fornece apenas as funes essenciais, e
o sistema de banco de dados deve ser construdo nessa base. Assim, o projeto do banco de dados deve considerar
a interface entre o sistema de banco de dados e o sistema operacional.
Os componentes funcionais do sistema de banco de dados podem ser divididos pelos componentes de
processamento de consultas e pelos componentes de administrao de memria. Os componentes de
processamento de consultas incluem:

Compilador DML, que traduz comando DML da linguagem de consulta em instrues de baixo nvel,
inteligveis ao componente de execuo de consultas. Alm disso, o compilador DML tenta transformar a
solicitao do usurio em uma solicitao equivalente, mas mais eficiente, buscando, assim, uma boa
estratgia para execuo da consulta.
Pr-compilador para comandos DML inseridos em programas de aplicao, que convertem comandos
DML em chamadas de procedimentos normais da linguagem hospedeira. O pr-compilador precisa
interagir com o compilador DML de modo a gerar o cdigo apropriado.
Interpretador DDL, que interpreta os comandos DDL e registra-os em um conjunto de tabelas que
contm metadados.
Componentes para o tratamento de consultas, que executam instrues de baixo nvel geradas pelo
compilador DML.

Os componentes para administrao do armazenamento de dados proporcionam a interface entre os dados de

baixo nvel, armazenados no banco de dados, os programas de aplicaes e as consultas submetidas ao sistema.
Os componentes de administrao de armazenamento de dados incluem:
Gerenciamento de autorizaes e integridade, que testam o cumprimento das regras de integridade e a
permisso ao usurio no acesso ao dado.
Gerenciamento de transaes, que garante que o banco de dados permanecer em estado consistente
(correto) a despeito de falhas no sistema e que transaes concorrentes sero executadas sem conflitos
em seus procedimentos.
Administrao de arquivos, que gerencia a alocao de espao no armazenamento em disco e as
estruturas de dados usadas para representar estas informaes armazenadas em disco.
Administrao de buffer, responsvel pela intermediao de dados do disco para a memria principal e
pela deciso de quais dados colocar em memria cache.

Alm disso, algumas estruturas de dados so exigidas como parte da implementao fsica do sistema:
Arquivo de dados, que armazena o prprio banco de dados.
Dicionrio de dados, que armazena os metadados relativos estrutura do banco de dados. O dicionrio
de dados muito usado. Portanto, grande nfase dada ao desenvolvimento de um bom projeto com
uma implementao eficiente do dicionrio.
ndices, que proporcionam acesso rpido aos itens de dados que so associados a valores determinados.
Estatsticas de dados, armazenam as informaes estatsticas relativas aos dados contidos no banco de
dados. Essas informaes so usadas pelo processador de consultas para seleo de meios eficientes para
execuo de uma consulta.

86

Modelo Entidade-Relacionamento
O modelo entidade-relacionamento (E-R) tem por base a percepo de que o mundo real formado por
um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre esses objetos. Foi
desenvolvido para facilitar o projeto do banco de dados, permitindo a especificao do esquema da empresa, que
representa toda estrutura lgica do banco de dados. O modelo E-R um dos modelos com maior capacidade
semntica; os aspectos semnticos do modelo se referem tentativa de representar o significado dos dados. O
modelos E-R extremamente til para mapear, sobre um esquema conceitual, o significado e interaes das
empresas reais. Devido a essa utilidade, muitas das ferramentas de projeto foram concebidas para o modelo E-R.
Conceitos Bsicos
Existem trs noes bsicas empregadas pelo modelo E-R: conjunto de entidades, conjunto de
relacionamentos e os atributos.
Conjunto de Entidades
Um entidade uma coisa ou um objeto no mundo real que pode ser identificada de forma unvoca
em relao a todos os outros objetos. Por exemplo, cada pessoa na empresa uma entidade. Uma entidade tem
um conjunto de propriedades, e os valores para alguns conjuntos dessas propriedades devem ser nicos. Por
exemplo, o nmero social 677-89-9011 identifica uma nica pessoa na empresa. Tambm, pode-se pensar em
emprstimos como entidades, e o emprstimo nmero L-15 referente agncia Perryridge identifica
univocamente uma entidade emprstimo. Uma entidade pode ser concreta, como uma pessoa ou um livro, ou
pode ser abstrata, como um emprstimo, uma viagem de frias ou um conceito.
Um conjunto de entidades um conjunto que abrange entidades de mesmo tipo que compartilham as
mesmas propriedades: os atributos. O conjunto de todas as pessoas que so clientes de um banco de dados, por
exemplo, pode ser definido como o conjunto de entidades clientes. Analogamente, o conjunto de entidades
emprstimo poderia representar o conjunto de todos os emprstimos que o banco em questo viabiliza. As
entidades individuais que constituem um conjunto so chamadas extenses do conjunto de entidades. Assim,
todos os clientes do banco so as extenses do conjunto de entidades cliente.
Os conjuntos de entidades no so necessariamente separados. Por exemplo, possvel definir um
conjunto de entidades com todos os empregados do banco (empregado) e um conjunto de entidades com todos
os clientes do banco (cliente). A entidade pessoa pode pertencer ao conjunto de entidades empregado, ou ao
conjunto de entidades cliente, ou a ambos, ou a nenhum.
Uma entidade representada por um conjunto de atributos. Atributos so propriedades descritivas de
cada membro de um conjunto de entidades. A designao de um atributo para um conjunto de entidades
expressa que o banco de dados mantm informaes similares de cada uma das entidades do conjunto de
entidades; entretanto, cada entidade pode ter seu prprio valor em cada atributo. Atributos possveis ao
conjunto de entidades clientes so nome_cliente, seguro_social, rua_cliente, e cidade_cliente. Atributos possveis
para o conjunto de entidades emprstimo so nmero_emprstimo e conta. Para cada atributo existe um
conjunto de valores possveis, chamado domnio, ou conjunto de valores, daquele atributo. O domnio do atributo
nome_cliente pode ser o conjunto de todos os textos string de um certo tamanho. Similarmente, o domnio do
atributo nmero_emprstimo pode ser o conjunto de todos os inteiros positivos.
Desse modo, um banco de dados inclui uma coleo de conjuntos de entidades, cada qual contendo um
nmero de entidades de mesmo tipo. A fig. 2.1 mostra parte do banco de dados de uma empresa bancria
contendo dois conjuntos entidades: cliente e emprstimo.

87

Formalmente, um atributo de um conjunto de entidades uma funo que relaciona o conjunto de

entidades a seu domnio. Desde que um conjunto de entidades possua alguns atributos, cada entidade pode ser
descrita pelo conjunto formado pelos pares (atributos, valores de dados), um par para cada atributo do conjunto
de entidades. Por exemplo, uma entidade em particular de cliente pode ser descrita pelo conjunto {(nome,
Hayes), (seguro_social, 677-89-9011), (rua_cliente, Main), (cidade_cliente, Harrison)}, o que significa que essa
entidade descreve o cliente Hayes, que possui o seguro social nmero 677-89-90211 e mora na Rua Main em
Harrison. Podemos notar, a esta altura, uma integrao entre o esquema abstrato e a empresa real que est
sendo modelada. Os valores dos atributos que descrevem as entidades constituem uma poro significativa dos
dados que sero armazenados no banco de dados. Um atributo, como usado no modelo E-R, pode ser
caracterizado pelos seguintes tipos:
Atributos simples ou compostos. Em nosso exemplo anterior, todos os atributos eram simples: isto , no
eram divididos em partes. Os atributos compostos, por outro lado, podem ser divididos em partes (isto ,
outros atributos). Por exemplo, nome_cliente pode ser estruturado em prenome, nome_intermediario e
sobrenome. O uso de atributos compostos ajudam-nos a agrupar atributos correlacionados, tornando o
modelo mais claro.
Note que os atributos compostos podem estar hierarquizados. Retornando o exemplo do atributo
composto endereo_cliente, seu atributo rua pode vir a ser subdividido posteriormente em nmero_rua,
nome_rua, e nmero_apto. Esses exemplos de atributos compostos para clientes so apresentados na fig. 2.2.

Atributos monovalorados ou multivalorados. Os atributos usados em nossos exemplos foram todos de

valores simples para uma entidade em particular. Ou seja, o atributo nmero_emprstimo de uma
entidade especfica refere-se apenas a um nmero de emprstimo. Esses atributos so chamados
monovalorados. Pode haver instncias em que um atributo possua um conjunto de valores para uma
nica entidade. Considere o conjunto de entidades empregado com o atributo nome_dependente.
Qualquer empregado em particular pode ter um, nenhum ou vrios dependentes; entretanto, diferentes
entidades empregado dentro do conjunto e empregados tero diferentes nmeros de valores para o
atributo nome_dependente. Esse tipo de atributo dito multivalorado. Quando necessrio, pode-se
estabelecer limites inferiores e superiores para o nmero de ocorrncias em um atributo multivalorado.
Por exemplo, um banco pode ter um nmero limite de registros de endereos para um cliente normal,
um ou dois endereos. O estabelecimento de limites, neste caso, exprime que o atributo
endereo_cliente do conjunto de entidades cliente pode possuir de zero a dois valores.
Atributos nulos. Um atributo nulo usado quando uma entidade no possui valor para determinado
atributo. Por exemplo, se um empregado em particular no possui dependentes, o valor do atributo
88

nome_dependente para esse dependente dever ser nulo, e isso significa que esse atributo no
aplicvel. Nulo tambm pode significar que o valor do atributo desconhecido. Um valor desconhecido
pode caracterizar omisso (o valor existe de fato, mas no temos essa informao) ou no conhecimento
(no sabemos se o valor existe de fato). Por exemplo, se o valor do seguro_social de determinado cliente
nulo, assume-se que seu valor foi omitido, j que exigido para efeitos de impostos. Um valor nulo para
o atributo nmero_apartamento pode significar que o nmero do apartamento foi omitido, ou que o
nmero existe mas no sabemos qual , ou que o endereo no um prdio de apartamentos e,
portanto, no faz parte do endereo do cliente.

Atributo derivado. O valor desse tipo de atributo pode ser derivado de outros atributos ou entidades a
ele relacionados. Por exemplo, digamos que o conjunto de entidades cliente possui o atributo
emprstimos_tomados, que representa o nmero de emprstimos tomados do banco por um cliente.
Podemos derivar o valor desse atributo contando o nmero das entidades emprstimos associadas ao
cliente em questo. Como outro exemplo, consideremos que o conjunto de entidades empregado est
relacionado aos atributos data_contratao e tempo_de_casa, os quais representam o primeiro dia de
emprego no banco e o tempo total que o empregado est trabalhando, respectivamente. O valor do
tempo_de_casa pode ser derivado do valor da data_contratao e tempo_de_casa, os quais representam
o primeiro dia de emprego no banco e o tempo total que o empregado est trabalhando,
respectivamente. O valor do tempo_de_casa pode ser derivado do valor data_contratao e da
data_corrente. Neste caso, a data_contratao pode ser referida como um atributo da base ou um
atributo armazenado.

Um banco de dados para uma empresa bancria pode incluir um nmero diferente de conjuntos de entidades.
Por exemplo, aliado ao que foi dito sobre clientes e emprstimos, um banco tambm possui contas, que esto
representadas pelo conjunto de entidades conta com os atributos nmero_conta e saldo. Tambm, se um banco
tem um nmero diferente de agncias, ento deveramos captar informaes sobre todas essas agncias. Cada
conjunto de entidades agncia pode ser descrito pelos atributos nome_agncia, cidade_agncia e fundos.
Conjuntos de Relacionamentos
Um relacionamento uma associao entre uma ou vrias entidades. Por exemplo, podemos definir um
relacionamento que associa o cliente Hayes com o emprstimo L-15. Esse relacionamento especifica que o cliente
Hayes cliente com o emprstimo nmero L-15.
Um conjunto de relacionamentos um conjunto de relacionamentos do mesmo tipo. De modo formal, a
relao matemtica com n2 conjunto de entidades (podendo ser no-distintos). Se E1, E2, ..., Em so conjuntos
de entidades, ento um conjunto de relacionamentos R um subconjunto de
em que (e1, e2, ..., en) so relacionamentos.
Considere dois conjuntos de entidades da fig. 2.1, cliente e emprstimo. Definimos o conjunto de
relacionamentos devedor para denotar a associao entre clientes e emprstimos bancrios contrados pelo
clientes. Essa associao apresentada na fig. 2.3.

89

Como exemplo, consideremos dois tipos de conjuntos de entidades, emprstimo e agncia. Podemos
definir o conjunto de relacionamento agncia_emprstimo denotando a associao entre um emprstimo
bancrio e a agncia onde esse emprstimo mantido.
A associao entre os conjuntos de entidades referida como uma participao; isto , o conjunto de
entidade E1, E2, ..., En participa do conjunto de relacionamentos R. Uma instncia de relacionamento em um
esquema E-R representa a existncia de uma associao entre essa entidade e o mundo real no qual insere a
empresa que est sendo modelada. Ilustramos a entidade cliente chamada Hayes, que possui o seguro social
nmero 677-89-9011, e a entidade emprstimo L-15 participam na instncia do relacionamento devedor.
Essa instncia do relacionamento representa que, no mundo real da empresa, uma pessoa chamada
Hayes que possui o seguro social nmero 677-89-9011 tomou um emprstimo que tem o nmero L-15.
A funo que uma entidade desempenha em um relacionamento chamada papel. Uma vez que os
conjunto de entidades participantes em um conjunto de relacionamentos so geralmente distintos, papis so
implcitos e no so, em geral, especificados. Entretanto, so uteis quando o significado de um relacionamento
precisa ser esclarecido. Este o caso quando os conjuntos de entidades e os conjuntos de relacionamentos mais
de uma vez, em diferentes papis.
Nesse tipo de conjunto de relacionamentos, que algumas vezes chamado conjunto de relacionamentos
recursivos, nomes explcitos de papis so necessrios para especificar como uma entidade participa de uma
instncia de relacionamento. Por exemplo, considere o conjunto de entidades empregado que mantm
informaes sobre todos os empregados do banco. Podemos ter um conjunto de relacionamentos trabalha_para
que modelado para ordenar os pares de entidades de empregado. O primeiro empregado de um par tem o
papel de gerente, enquanto o outro tem o papel de empregado. Deste modo, todos os relacionamentos de
trabalha_para so caracterizados pelos pares (gerente, empregado); os pares (empregado, gerente) so
excludos.
Um relacionamento tambm pode ter atributos descritos. Considere o conjunto de relacionamentos
depositante com o conjunto das entidades cliente e conta. Poderemos associar o atributo data_acesso a essa
relao para especificar a data do ltimo aceso feito pelo cliente em sua conta. O relacionamento depositante
entre as entidades correspondentes ao cliente Jones e conta A-217 descrita por {(data-acesso, 23 de maio de
2013)}, a qual significa que o mais recente acesso que Jones fez a sua conta A-217 foi em 23 de maio de 2013.

O conjunto de relacionamentos devedor e agncia_emprstimo um exemplo de conjunto de

relacionamentos binrio isto , um relacionamento que envolve dois conjuntos de entidades. A maior parte dos
conjuntos de relacionamentos nos sistemas de banco de dados so binrios. Ocasionalmente, entretanto, os
conjuntos de relacionamentos envolvem mais de dois conjuntos de entidades. Como exemplo, podemos
combinar os conjuntos de relacionamentos devedor e agncia_emprstimo formado o conjunto de
90

relacionamentos CEA, envolvendo os conjuntos de entidades cliente, emprstimo e agncia. Assim, o

relacionamento ternrio entre as entidades correspondente ao cliente Hayes, o emprstimo nmero L-15, e a
agncia Perryridge especifica que o cliente Hayes tem o emprstimo L-15 na agncia Perryridge.
O nmero de conjuntos de entidades que participa de um conjunto de relacionamento tambm o grau
desse conjunto de relacionamento. Um conjunto de relacionamento binrio de grau dois; um relacionamento
ternrio de grau trs.
Metas de Projeto
Um conjunto de entidades e um conjunto de relacionamento no so noes precisas e possvel definir
um conjunto de entidades e de relacionamentos entre eles de vrias formas diferentes.
Uso de Conjuntos de Entidades ou Atributos
Considere o conjunto de entidades empregado com os atributos nome_empregado e nmero_telefone.
Pode ser facilmente verificado que o telefone uma entidade sujeita a seus prprios atributos, como
nmero_telefone e localizao (o escritrio onde o telefone est instalado). Sob esse ponto de vista, o conjunto
de entidades deve ser redefinido, conforme segue:
O conjunto de entidades empregado com o atributo nome_empregado.
O conjunto de entidades telefone com os atributos nmero_telefone e localizao.
O conjunto de relacionamentos emp_telefone, o qual denota a associao entre os empregados e os
telefones que podem ter.
Qual , ento, a principal diferena entre essas duas definies de um empregado? No primeiro caso, a definio
implica que todo empregado possui, precisamente, um nmero de telefone a ele associado. No segundo caso,
entretanto, a definio estabelece que o empregado pode ter vrios nmeros de telefones (incluindo zero) a ele
associados. Assim, a segunda definio mais geral que a primeira e pode refletir com maior preciso as
situaes reais.
Mesmos se nos for dado que cada empregado tem, precisamente, um nmero de telefone a ele
associado, a segunda definio pode, ainda assim, ser mais apropriada, caso um mesmo telefone possa ser
compartilhado por diversos empregados.
No seria apropriado, no entanto, aplicar a mesma tcnica ao atributo nome_empregado; difcil
sustentar que nome_empregado seja uma entidade por si s (em contraste com telefone). Assim, apropriado
manter nome_empregado como atributo do conjunto de entidades empregado.
Duas questes aparecem naturalmente: o que constitui um atributo e o que constitui um conjunto de
entidades? Infelizmente, no existe uma resposta simples. As distines dependem, principalmente, da estrutura
real da empresa que est sendo modelada e da semntica associada aos atributos em questo.
Uso dos Conjuntos de Entidades e Conjunto de Relacionamentos
Nem sempre fica claro se um objeto melhor expresso por um conjunto de entidades ou por um
conjunto de relacionamentos. J assumimos anteriormente que um emprstimo bancrio modelado como uma
entidade. Uma alternativa modelar o emprstimo no como uma entidade, mas como um relacionamento entre
clientes e agncias, com nmero_emprstimo e conta como atributos descritivos. Cada emprstimo
representado por um relacionamento entre um cliente e uma agncia.
Se todo emprstimo tomado por exatamente um cliente e est associado a exatamente uma agncia,
podemos resolver o projeto de modo satisfatrio caso o emprstimo seja representado como relacionamento.
Entretanto, com um projeto assim, no poderemos representar convenientemente uma situao na qual vrios
clientes tomam um emprstimo conjunto. Precisaremos definir um relacionamento em separado para cada
componente de um emprstimo conjunto. Ento, precisaremos replicar os valores dos atributos descritivos,
nmero_emprstimo e conta, para cada um dos relacionamentos. Dois problemas so consequncia dessa
91

replicao: (1) os dados so armazenados diversas vezes, desperdiando espao em memria; e (2) as
atualizaes deixam, potencialmente, os dados em um estado inconsistente, quando os valores diferem nos
atributos de dois relacionamentos que deveriam, supostamente, possuir valores iguais. O meio pelo qual se
evitam tais replicaes aplicado formalmente pela teoria da normalizao.
Uma linha mestra possvel na opo pelo uso de um conjunto de entidades ou pelo uso de um conjunto
de relacionamentos recorrer ao conjunto de relacionamentos para descrever uma ao que ocorre entre
entidades. Essa abordagem pode ser til tambm para decidir se certos atributos podem ser expressos de
maneira mais apropriada como relacionamentos.
Conjunto de relacionamentos Binrios versus n-simos
sempre possvel recompor um conjunto de relacionamentos no-binrios (n-simos, com n>2) por um
nmero de conjuntos de relacionamentos binrios distintos. Para simplificar, considere o conjunto de
relacionamento ternrio (n=3) abstrato R, relacionados aos conjuntos de entidades A, B e C. Poderemos recompor
o conjunto R em um conjunto de entidades E, e criar trs conjuntos de relacionamentos:
RA, relacionando E e A
RB, relacionando E e B
RC, relacionando E e C
Se o conjunto de relacionamentos R possui quaisquer atributos, estes so designados pelo conjunto de entidades
E (j que todo o conjunto de entidades deve ter ao menos um atributo para distinguir seus membros). Para cada
relacionamento (ai, bi, ci) do conjunto de relacionamentos R, podemos criar uma nova entidade ei no conjunto de
entidades E. Ento, em cada um dos trs novos conjuntos de relacionamentos, inserimos um relacionamento,
como segue:
(ei, ai) em RA
(ei, bi) em RA
(ei, ci) em RA
Podemos generalizar esse processo de modo direto para os conjuntos de relacionamentos n-simo.
Assim, conceitualmente podemos restringir o modelo E-R para conter apenas conjuntos de relacionamentos
binrios. Entretanto, essa restrio nem sempre desejvel.
Pode ser que seja necessria a criao de um atributo de identificao para o conjunto de entidades
criado para substituir o conjunto de relacionamentos. Este atributo, juntamente com o conjunto extra de
relacionamentos criados, aumenta a complexidade do projeto e as necessidades de armazenamento
como um todo.
Um conjunto de relacionamentos n-simo mostra claramente todos os conjuntos de entidades que
participam de uma determinada relao. O projeto correspondente, usando somente conjunto de
relacionamentos binrios, torna mais difcil estabelecer as restries dessa participao.
Mapeamento de Restries
O esquema E-R de uma empresa pode definir certas restries, as quais o contedo do banco de dados
deve respeitar.
Mapeamento das Cardinalidades
O mapeamento das cardinalidades, ou rateio de cardinalidades, expressa o nmero de entidades s quais
outra entidade pode estar associada via um conjunto de relacionamentos.
O mapeamento de cardinalidades mais til na descrio dos conjuntos de relacionamentos binrios,
embora, ocasionalmente, possam contribuir para a descrio de conjuntos de relacionamentos que envolvam
mais de dois conjuntos de entidades.
92

Para um conjunto de relacionamentos R binrio entre os conjuntos de entidades A e B, o mapeamento

das cardinalidades deve seguir uma das instrues abaixo:
Um para um. Uma entidade em A est associada no mximo a uma entidade em B, e uma entidade em B
est associada a no mximo uma entidade em A (fig. 2.4a).
Um para muitos. Uma entidade em A est associada a vrias entidades em B. Uma entidade em B,
entretanto, pode estar associada a qualquer nmero de entidades em B e uma entidade em B est
associada a um nmero qualquer de entidades em A (fig. 2.5a).

O mapeamento apropriado de cardinalidades para um conjunto de relacionamentos em particular ,

obviamente, dependente das situaes reais que esto sendo modeladas pelo conjunto de relacionamentos.
Como ilustrao, considere o conjunto de relacionamentos devedor. Se, em um banco em particular, um
emprstimo pode se destinar a apenas um cliente e um cliente pode contrair diversos emprstimos, ento o
conjunto de relacionamentos entre cliente e emprstimo de um para muitos. Esse tipo de relacionamento
apresentado na fig. 2.3. Se um emprstimo puder ser tomado por mais de um cliente (como normalmente
acontece com os vrios scios de um negcio), o relacionamento seria de muitos para muitos.

O rateio de cardinalidades de um relacionamento pode afetar a colocao dos atributos nos

relacionamentos. Atributos em conjuntos de relacionamentos um para um ou um para muitos deve ser
associados a um dos conjuntos de entidades participantes, em vez de serem associados ao conjunto de
relacionamentos. Por exemplo, consideremos depositante como um conjunto de relacionamentos um para
muitos, tal que um cliente pode possuir diversas contas, mas cada conta est vinculada a apenas um cliente.
Nesse caso, o atributo data_acesso poderia estar associado ao conjunto de entidades conta, como mostrados na
93

fig. 2.6; de modo a tornar a figura mais clara, so apresentados apenas alguns dos atributos dos dois conjuntos de
entidades. J que cada entidade conta participa de um relacionamento com no mximo uma instncia de cliente,
fazer esta designao de atributo pode ter o mesmo significado que colocar data_acesso no conjunto de
relacionamentos depositante. Atributos de conjuntos de relacionamentos um para muitos podem apenas ser
reposicionados no conjunto de entidades do lado muitos desse relacionamento. Em conjuntos de
relacionamentos um para um, o atributo do relacionamento pode ser associado a qualquer uma das entidades
participantes.

As decises de projeto, como decidir onde colocar atributos descritivos como um atributo de entidade
ou relacionamento devem refletir as caractersticas da empresa que est sendo modelada. O projetista pode
optar por manter data_acesso como um atributo de depositante para explicitar que um acesso ocorreu em uma
interao entre os conjuntos de entidades cliente e conta.
A escolha de onde colocar um atributo mais clara quando se trata de conjuntos de relacionamentos
muitos para muitos. Retornando ao exemplo, especifiquemos o que talvez seja um dos mais realsticos casos de
conjuntos de relacionamentos muitos para muitos, depositante, que expressa que um cliente pode ter uma ou
mais contas e que uma conta pode estar vinculada a um ou mais clientes.
Se quisermos expressar a data do ltimo acesso de um cliente a uma dada conta, o atributo data_acesso
dever ser atribudo ao conjunto de relacionamentos depositante, em vez de ser alocado a uma das duas
entidades participantes. Se data_acesso fosse atributo de conta, no poderamos determinar qual dos clientes
responsvel pelo acesso mais recente conta em questo.
Quando um atributo determinado pela combinao dos conjuntos de entidades participantes em vez de
estar associado a cada uma das entidades, separadamente, esse atributo precisa ser associado ao conjunto de
relacionamentos muitos para muitos. A colocao de data_acesso como atributo do conjunto de relacionamentos
mostrada na fig. 2.7; novamente, para tornar a figura mais simples, so apresentados apenas alguns dos
atributos dos dois conjuntos de entidades.

94

Dependncia de Existncia
Outra classe importante de restries a dependncia de existncia. Especificamente, se a existncia da
entidade x depende da existncia da entidade y, ento x dito dependente da existncia de y. Operacionalmente,
se y for excludo, o mesmo deve acontecer com x. A entidade y chamada entidade dominante e a x chamada
entidade subordinada. Como ilustrao, considere o conjunto de entidades emprstimo e o conjunto de
entidades pagamento, que mantm todas as informaes dos pagamentos realizados para um determinado
emprstimo. O conjunto de entidades pagamento descrito pelos atributos nmero_pagamento,
data_pagamento e total_pagamento. Criamos um conjunto de relacionamentos pagamento_emprstimo entre
esses dois conjuntos de entidades pagamento descrito pelos atributos nmero_pagamento, data_pagamento e
total_pagamento. Criamos um conjunto de relacionamentos pagamento_emprstimo entre estes dois conjuntos
de entidade que de um para muitos do emprstimo para o pagamento. Toda entidade pagamento est
associada a uma entidade emprstimo. Se uma entidade emprstimo excluda, ento todas as entidades
pagamento a ela associadas devero ser excludas tambm. Em contraste, uma entidade pagamento pode ser
excluda do banco de dados sem afetar em nada qualquer emprstimo. O conjunto de entidades emprstimo,
portanto, dominante e pagamento subordinado ao conjunto de relacionamentos pagamento_emprstimo.
A participao de um conjunto de entidades E no conjunto de relacionamentos R dita total se todas as
entidades em E participam de pelo menos um relacionamento R. Se somente algumas entidades em E participam
do relacionamento R, a participao do conjunto de entidades em E participam do relacionamento R, a
participao do conjunto de entidades E no relacionamento R dito parcial. A participao total est
estreitamente relacionada existncia de dependncia. Por exemplo, desde que toda entidade pagamento esteja
associada a alguma entidade emprstimo pelo relacionamento pagamento_emprstimo, a participao de
pagamento no conjunto de relacionamentos pagamento_emprstimo total. Por outro lado, um indivduo pode
ser cliente de um banco, tendo ou no contrado um emprstimo nele. Da, possvel que apenas parte do
conjunto de entidades cliente esteja relacionada ao conjunto de entidades emprstimo e a participao de cliente
no conjunto de relacionamentos devedor , portanto, parcial.
Chaves

95

 importante especificar como as entidades dentro de um dado conjunto de entidades e os

relacionamentos dentro de um conjunto de relacionamentos podem ser identificados. Conceitualmente,
entidades e relacionamentos individuais so distintos, entretanto, na perspectiva do banco de dados, a diferena
entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chave permite-nos fazer tais
distines.
Conjunto de Entidades
Uma superchave um conjunto de um ou mais atributos que, tomados coletivamente, nos permitem
identificar de maneira unvoca uma entidade em um conjunto de entidades. Por exemplo, o atributo
seguro_social do conjunto de entidades cliente suficiente para distinguir uma entidade cliente de outra. Assim,
o seguro_social uma superchave. Do mesmo modo, a combinao de nome_cliente e seguro_social
superchave para o conjunto de entidades cliente. O atributo nome_cliente no superchave de cliente, pois
algumas pessoas podem ter o mesmo nome.
O conceito de superchave no suficiente para nossos propsitos, j que, como vimos, uma superchave
pode conter atributos externos. Se K uma superchave, entoa qualquer superconjunto de K. Nosso interesse
por superchaves para as quais nenhum subconjunto possa ser uma superchave. Essas superchaves so chamadas
chaves candidatas. possvel que vrios conjuntos diferentes de atributos possam servir como superchave.
Suponha que uma combinao de nome_cliente e rua_cliente seja suficiente para distinguir todos os membros do
conjunto de entidades cliente. Ento, (seguro_social) e (nome_cliente, rua_cliente) so chaves candidatas.
Embora os atributos seguro_social e nome_cliente, juntos, possam distinguir as entidades cliente, sua
combinao no forma uma chave candidata, uma vez que seguro_social, sozinho, uma chave candidata.
Chaves candidatas precisam ser escolhidas com cuidado. Como notamos, obviamente o nome de uma
pessoa no suficiente, j que homnimos so possveis. Nos Estados Unidos, o nmero de seguro_social pode
ser uma chave candidata. Em outros pases onde os habitantes normalmente no possuem nmero de seguro
social, as empresas podem gerar seu prprio nmero de identificao, como nmero do cliente ou nmero de
identificao de estudantes ou nmero de identificao, como nmero do cliente ou nmero de identificao de
estudantes ou qualquer outra combinao nica de outros atributos como chave. Uma das combinaes mais
frequentemente usadas o nome, data de nascimento e endereo, j que extremamente difcil que mais de
uma pessoa tenha os mesmos valores para todos esses atributos.
Podemos usar o termo chave primria para caracterizar a chave candidata que escolhida pelo projetista
do banco de dados como de significado principal para a identificao de entidades dentro de um conjunto de
entidades. Uma chave (primria, candidata e super) duas entidades individuais em um conjunto no podem ter,
simultaneamente, mesmos valores em seus atributos-chave. A especificao de uma chave representa uma
restrio ao mundo real da empresa que est sendo modelada.
Conjuntos de Relacionamentos
A chave primria de um conjunto de entidades permite-nos distinguir as vrias entidades de um conjunto.
Precisamos, de modo similar, de um mecanismo para a identificao dos vrios relacionamentos em um conjunto
de relacionamentos.
Seja R um conjunto de relacionamentos envolvendo os conjuntos de entidades E1, E2, ..., En. Seja uma
chave_primria (Ei) denotando o conjunto de atributos que formam a chave primrias sejam nicos (se no
forem, use um esquema apropriado para rebatiz-los). A composio da chave primria para um conjunto de
relacionamentos depende de uma estrutura de atributos associada ao conjunto de relacionamentos R.
Se o relacionamento R no possui atributo, ento o conjunto de atributos:
descreve um relacionamento individual do conjunto R.
Se o conjunto de relacionamento r possui os atributos a1, a2, ..., an a ele associados, ento o conjunto de
atributos:
96

descreve um relacionamento em particular do conjunto R.

Em ambos os casos acima, o conjunto de atributos:
forma uma superchave do conjunto de relacionamentos.
A estrutura da chave primria para o conjunto de relacionamentos depende do mapeamento da
cardinalidade do conjunto de relacionamentos. Como ilustrao, considere o conjunto de entidades cliente e
empregado e um conjunto de relacionamentos cliente_bancrio que representa a associao entre um cliente e
um bancrio (uma entidade empregado). Suponha que um conjunto de relacionamentos seja de muitos para
muitos, suponha tambm que o conjunto de relacionamentos possui o atributo tipo a ele associado,
representando a natureza do relacionamento (como um agente de emprstimo ou como um atendente pessoal).
A chave primria cliente_bancrio constitui-se da unio das chaves primrias de cliente e empregado. Entretanto,
se um cliente pode ser atendido exclusivamente por um bancrio isto , se um relacionamento cliente_bancrio
muitos para um ento, a chave primria de cliente_bancrio simplesmente a chave primria de cliente. Para
relacionamentos um para um, qualquer uma das chaves primrias pode ser usada.
A designao de chaves primrias mais complicada para relacionamentos no-binrios.
Diagrama Entidade-Relacionamento
Toda estrutura lgica do banco de dados pode ser expressa graficamente pelo diagrama E-R. A relativa
simplicidade e clareza desta tcnica de diagramao pode explicar, em grande parte, a ampla disseminao do
uso do modelo E-R.
A seguir so apresentados seus principais componentes:
Retngulos, que representam os conjuntos de entidades.
Elipses, que representam os atributos.
Losangos, que representam os conjuntos de relacionamentos.
Linhas, que unem os atributos aos conjuntos de entidades e os conjuntos de entidades aos conjuntos de
relacionamentos.
Elipses duplas, que representam atributos multivalorados.
Linhas duplas, que indicam a participao total de uma entidade em um conjunto de relacionamentos.
Como mostrado na fig. 2.8, os atributos de um conjunto de entidades que so membros de uma chave
primria devem ser sublinhados.
Considere o diagrama entidade-relacionamento da fig. 2.8, que consiste de dois conjuntos de entidades,
cliente e emprstimo, relacionados pelo conjunto de relacionamentos devedor. Os atributos associados a cliente
so nome_cliente, seguro_social, rua_cliente e cidade_cliente. Os atributos associados a emprstimo so
nmero_emprstimo e total.
O conjunto de relacionamentos devedor pode ser muitos para muitos, um para um, muitos para um ou
um para um. Para fazer a distino entre esses tipos, desenhamos uma linha direcionada (
) ou uma linha sem
direcionamento (-) entre o conjunto de relacionamentos e o conjunto de entidades em questo.
Uma linha direcionada do conjunto de relacionamentos devedor para o conjunto de entidades
emprstimo especifica que devedor um conjunto de relacionamentos um para um ou muitos para um,
de cliente para emprstimo; devedor no pode ser um conjunto de relacionamentos muitos para muitos
ou um para muitos, de cliente para emprstimo.
Uma linha no direcionada do conjunto de relacionamentos devedor para o conjunto de entidades
emprstimo especifica que devedor um conjunto de relacionamentos muitos para muitos ou um para
muitos, de cliente para emprstimo.

97

Voltando ao diagrama E-R da fig. 2.8, podemos ver que o conjunto de relacionamentos devedor muitos
para muitos. Se o conjunto de relacionamentos dever for um para muitos, de cliente para emprstimo, ento a
linha de devedor para cliente deveria ser direta, com a seta apontando para o conjunto de entidades cliente (fig.
2.9a). Similarmente, se o conjunto de relacionamentos devedor for muitos para um, de cliente para emprstimo,
ento a linha de devedor para emprstimo deveria ser uma seta pontando para o conjunto de entidades
emprstimo (fig. 2.9b).
Finalmente, se o conjunto de relacionamentos devedor for um para um, ento ambas as linhas de
devedor deveriam ser setas: uma apontando para o conjunto de entidades emprstimo e outra apontando para o
conjunto de entidades clientes (fig. 2.10).
Se um conjunto de relacionamentos tambm tem atributos a ele relacionados, ento deveremos fazer a
ligao desses atributos com o conjunto de relacionamentos. Por exemplo, na fig. 2.11, temos o atributo descrito
data_acesso atrelado ao conjunto de relacionamentos depositante para especificar a data mais recente de acesso
do cliente conta.
Indicamos os papeis desempenhados no diagrama E-R por meio da denominao nas linhas que ligam os
losangos aos retngulos. A fig. 2.12 mostra os papeis desempenhados, gerente e empregado, entre o conjunto de
entidades empregado e o conjunto de relacionamentos trabalha_para.
Conjuntos de relacionamentos no-binrios podem ser facilmente especificados no diagrama E-R. A fig.
2.13 apresenta trs conjuntos de entidades, cliente, emprstimo e agncia, interligados pelo conjunto de
relacionamentos CEA.
Esse diagrama especifica que um cliente pode contrair diversos emprstimos e que um emprstimo pode
pertencer a diferentes clientes.
Esse diagrama especifica que um cliente pode contrair diversos emprstimos e que um emprstimo pode
pertencer a diferentes clientes.
A seguir, vemos uma seta apontando para agncia indicando que cada par emprstimo-cliente est
associado a uma agncia bancria especfica. Se o diagrama tem uma seta apontando para cliente e outra
apontando para agncia, o diagrama especificaria que cada emprstimo est associado a um cliente especfico de
uma determinada agncia bancria.

98

99

Conjunto de Entidades Fracas

Um conjunto de entidades pode no ter atributos suficientes para formar uma chave primria. Esse tipo
de conjunto de entidades denominado conjunto de entidades fracas. Um conjunto de entidades que tem uma
chave primria chamado um conjunto de entidades fortes. Como ilustrao, considere o conjunto de entidades
pagamento, com trs atributos: nmero_pagamento, data_pagamento e total_pagamento. Embora cada
100

entidade pagamento seja distinta, os pagamentos de emprstimos no tem uma chave primria; este um
conjunto de entidades fracas. Para um conjunto de entidades fracas ser significativo, ele deve fazer parte de um
conjunto de relacionamentos um para muitos. Esse conjunto de relacionamentos no deve ter nenhum atributo
significativo, j que qualquer atributo exigido pelo conjunto de relacionamentos no deve ter nenhum atributo
significativo, j que qualquer atributo exigido pelo conjunto de relacionamentos pode ser associado ao conjunto
de entidades fracas.
Os conceitos de conjuntos de entidades fortes e fracas no possuir chave primria, precisamos, todavia,
de um significado para a distino entre todas aquelas entidades em um conjunto de entidades que dependem de
uma entidade forte em particular. O identificador de um conjunto de entidades fracas um conjunto de atributos
que permite que essa distino seja feita. Por exemplo, o identificador do conjunto de entidades fracas
pagamento o atributo nmero_pagamento, assim, para cada emprstimo, um nmero de pagamento identifica
um determinado pagamento para aquele emprstimo. O identificador de um conjunto de entidades fracas
tambm chamado de chave parcial de um conjunto de entidades fracas tambm de chave parcial de um
conjunto de entidades.
A chave primaria de um conjunto de entidades fracas formado pela chave primria, precisamos, todavia,
de um significado para a distino entre todas aquelas entidades fortes ao qual a existncia do conjunto de
entidades fracas est vinculada mais o identificador do conjunto de entidades fracas. No caso do conjunto de
entidades pagamento, sua chave primria {nmero_emprstimo, nmero_pagamento}, em que
nmero_emprstimo identifica a entidade dominante pagamento e nmero_pagamento identifica a entidade
pagamento dentro de determinado emprstimo.
O conjunto de entidades dominantes de identificao dito proprietrio do conjunto de entidades fracas
por ele identificada. O relacionamento que associa o conjunto de entidades fracas a seu proprietrio o
relacionamento identificador. Em nosso exemplo, pagamento_emprstimo o relacionamento identificador de
pagamento.
Um conjunto de entidades fracas identificado no diagrama E-R pela linha dupla usada no retngulo e no
losango do relacionamento correspondente. Na fig. 2.14, o conjunto de entidades fracas pagamento
dependente do conjunto de entidades fortes emprstimo pelo conjunto de relacionamentos
pagamento_emprstimo. A figura tambm apresenta o uso de linhas duplas para identificar participao total a
participao do conjunto de entidades (fracas) pagamento no relacionamento pagamento_emprstimo total,
significando que todo pagamento precisa estar relacionado via pagamento_emprstimo a alguma conta.
Finalmente, a seta de pagamento_emprestimo para emprstimo indica que cada pagamento para um nico
emprstimo. O identificador de um conjunto de entidades fracas. Mesmo que um conjunto de entidades fracas
tenha sempre sua existncia dependente de uma entidade dominante, a dependncia de existncia no resulta,
necessariamente, em um conjunto de entidades fracas; isto , o conjunto de entidades subordinadas pode ter
uma chave primria.

101

Em alguns casos, o projetista do banco de dados pode optar por expressar um conjunto de entidades
fracas como um atributo composto multivalorado do conjunto de entidades proprietrio. Em nosso exemplo, essa
alternativa exigiria que o conjunto de entidades emprstimo tivesse um atributo composto multivalorado
pagamento, consistindo de nmero_pagamento, data_pagamento e total_pagamento. Um conjunto de entidades
fracas pode ser modelado de forma mais apropriada, como um atributo, se ele apenas participar da identificao
do relacionamento e ele tiver poucos atributos. Por outro lado, ser mais conveniente optar por um conjunto de
entidades fracas quando os conjuntos participantes no relacionamento no constiturem o relacionamento
identificador e quando o conjunto de entidades fracas possuir diversos atributos.
Recursos de Extenso do E-R
Apesar de ser possvel modelar a maioria dos banco de dados apenas com os conceitos bsicos do E-R,
alguns aspectos de um banco de dados podem ser expressos de modo mais conveniente por meio de algumas
extenses do modelo bsico do E-R.
Especializao
Um conjunto de entidades pode conter subgrupos de entidades que so, de alguma forma, diferentes de
outras entidades do conjunto. Por exemplo, um subconjunto de entidades dentro de um conjunto de entidades
pode possuir atributos que no so compartilhados pelas demais entidades do conjunto. O modelo E-R
proporciona um significado para a representao desses agrupamentos distintos entre as entidades.
Considere o conjunto de entidades conta com os atributos nmero_conta e saldo. Um saldo
futuramente classificado como um dos seguintes grupos:
conta_poupana
conta_movimento
Cada um desses tipos de contas descrito como um conjunto de atributos que, alm de todos os
atributos do conjunto de entidades conta, possui outros atributos adicionais. Por exemplo, as entidades
conta_poupana podem ser descritas pelo atributo taxa_juros, enquanto as entidades conta_movimento podero
possuir o limite_cheque_especial. O processo de especializao de conta permite-nos distinguir os tipos de
contas.
Um conjunto de entidades pode ser especializado por mais de uma caracterstica de diferenciao. Em
nosso exemplo, a distino entre as entidades conta seu tipo. Em nosso exemplo, a distino entre as entidades
conta seu tipo. Outra especializao coexistente poderia ser estabelecida entre os cheques especiais, resultando
nos conjuntos de entidades pessoa_fsica e pessoa_juridica. Quando mais de um tipo de especializao formado
em um conjunto de entidades, uma entidade em particular pode pertencer a pessoa_fisica e conta_movimento.
Podemos aplicar o agrupamento por especializao, repetidamente, para refinar o esquema que est
sendo projetado. Por exemplo, um banco pode oferecer os trs tipos de conta movimento:
1. Conta movimento padro com taxa de trs dlares mensais e 25 folhas de cheques por ms gratuitas.
Para essas contas, o banco emite o extrato bancrio mensal com os nmeros dos cheques.
2. Conta movimento especial que exige um saldo mnimo de mil dlares, pagando 2% em juros, e sem
limites na emisso de cheques. Neste caso, o banco monitora o saldo mnimo e os juros mensais pagos.
3. Conta movimento snior para clientes com idade superior a 65 anos que no pagam taxa de servios e
permite uso ilimitado de cheques, sem custo. Um registro sobre a data de aniversario do cliente
associado a esse tipo de conta.
A especializao da conta_movimento pelo tipo de conta cria os seguintes conjuntos de entidades:
1. Padro, com o atributo nmero_cheque.
2. Especial, com o atributo saldo_mnimo e taxa_juros.
3. Snior, com o atributo data_aniversrio.
102

Em termos de diagrama E-R, a especializao representada pelo tringulo rotulado de ISA, como demonstrado
na fig. 2.15. Este rtulo-padro ISA indica que, por exemplo, uma conta poupana uma conta. Este
relacionamento ISA pode ser tambm entendido como um relacionamento de super ou subclasse. Os conjuntos
de entidades em nvel superior e inferior so representados do mesmo modo que os conjuntos de entidades
regulares, ou seja, por um retngulo contendo o nome do conjunto de entidades.

Generalizao
O refinamento do conjunto de entidades em nveis sucessivos de subgrupos indica um processo top-down
de projeto, no qual as diferenciaes so feitas de modo explcito. O projeto pode ser realizado de modo bottomup, no qual vrios conjuntos de entidades so sintetizados em um conjunto de entidades em alto nvel, com base
em atributos comuns. O projetista do banco de dados poderia identificar, em uma primeira modelagem, o
conjunto de entidades conta_padro com os atributos nmero_conta, saldo e saldo_negativo e o conjunto de
entidades conta_poupanca com os atributos nmero_conta, saldo e taxa_juros.
Existem similaridades entre o conjunto de entidades conta_movimento e o conjunto de entidades
conta_poupana, j que possuem atributos comuns. Esse compartilhamento de atributos pode ser expresso pela
generalizao, que exprime o relacionamento existente entre os conjuntos de entidades de nvel superior e um
ou mais conjuntos de entidades de nvel inferior. E no nosso exemplo, conta um conjunto de entidades de nvel
superior e conta_poupana e conta)movimento so conjuntos de entidades de nvel inferior. Conjuntos de
entidades superiores e inferiores podem tambm ser designados em termos de super e subclasses,
respectivamente. O conjunto de entidades conta uma superclasse de conta_poupanca e conta_movimento so
subclasses.
Na prtica, a generalizao simplesmente o inverso da especializao. Aplicaremos ambos os processos,
combinados, ao longo do projeto do esquema E-R de uma empresa. Em termos do diagrama E-R propriamente
103

dito, no faremos distino entre a especializao e a generalizao. Novos nveis de representao de entidades
sero diferenciadas (especializao) ou sintetizadas (generalizao) de modo que o esquema possa expressar
totalmente a aplicao do banco de dados e atender s necessidades de seus usurios. As diferenas das duas
abordagens podem ser caracterizadas pelo ponto de partida e seus objetivos gerais.
A especializao parte de um nico conjunto de entidades; ela enfatiza as diferenas entre as entidades
pertencentes ao conjunto por meio do estabelecimento das diferenas expressas nos conjuntos de entidades de
nvel inferior. Estes conjuntos de entidades de nvel inferior podem possuir atributos, ou mesmo participar de
relacionamentos que no podem ser aplicados a todas as entidades do conjunto de entidades de nvel superior.
De fato, o projetista usa especializao justamente para representar tais distines. Se conta_poupana e
conta_movimento no possuem atributos nicos; no h necessidade de especializar o conjunto de entidades
conta.
O uso da generalizao procede para o reconhecimento de um nmero de conjunto de entidades que
compartilham caractersticas comuns (so descritos pelos mesmos atributos e participam dos mesmos conjuntos
de relacionamentos). Com base nessas caractersticas comuns, a generalizao sintetiza esses conjuntos de
entidades de nvel superior. A generalizao suada para enfatizar as similaridades entre os conjuntos de
entidades de nvel inferior, omitindo suas diferenas; isso permite tambm uma representao mais econmica,
evitando repeties de atributos compartilhados.
Herana de Atributos
Uma propriedade decisiva das entidades de nveis superior e inferior criadas pela especializao e pela
generalizao a herana de atributos. Os atributos dos conjuntos de entidades de nvel superior so herdados
pelos conjuntos de entidade de nvel inferior. Por exemplo, conta_poupana e conta_movimento herdam os
atributos de conta. Assim, conta_poupana identificado por seus atributos nmero_conta, saldo e taxa_juros;
conta_movimento identificado por seus atributos nmero_conta, saldo e limite_cheque_especial. Os conjuntos
de entidade de nvel inferior (ou subclasses) tambm herdam a participao em conjuntos de relacionamentos
dos quais participam seus conjuntos de entidades de nvel superior(ou superclasse). Tanto que o conjunto de
entidades conta_poupana e conta_movimento participam do conjunto de relacionamentos depositante. Os
conjuntos de entidades padro, especial e snior de nvel inferior herdam os atributos e a participao nos
relacionamentos de conta_movimento e conta.
Se uma dada poro do modelo E-R chegou especializao ou generalizao, os resultados so
basicamente os mesmos:
Conjuntos de entidades de nvel superior com atributos e relacionamentos que so aplicados a todos os
seus conjuntos de entidades de nvel inferior.
Conjunto de entidades de nvel inferior com caractersticas distintas que so apenas aplicadas a um
conjunto de entidades de nvel inferior em particular.
Como se percebe, embora frequentemente nos refiramos apenas generalizao, as propriedades que
discutimos pertencem totalmente a ambos os processos.
A fig. 2.15 apresenta uma hierarquia nos conjuntos de entidades. Na figura, conta_movimento um
conjunto de entidades de nvel superior aos conjuntos de entidades padro, especial e snior. Hierarquicamente,
um dado conjunto de entidades somente poder ser envolvido, como um conjunto de entidades de nvel inferior,
por meio de um relacionamento ISA. Se um conjunto de entidades um conjunto de entidades de nvel inferior
em mais de um relacionamento ISA, a estrutura resultante chamada reticulada.
Restries de Projeto
Para modelagem mais apurada de uma empresa, o projetista do banco de dados pode optar por definir
algumas restries em uma generalizao em particular. Um tipo de restrio envolve a determinao das

104

entidades que podem participar de um dado conjunto de entidades de nvel inferior. Tais escolhas podem ser
uma das seguintes:
Definida por condio. Um conjunto de entidades de nvel inferior definido por condio selecionado
com base na satisfao ou no de condies ou predicados preestabelecidos. Por exemplo, considere que
o conjunto de entidades de nvel superior conta possui o atributo tipo_conta. Todas as entidades conta
evoluem para um dos atributos tipo_conta. Somente aquelas entidades que satisfaam a condio
tipo_conta = conta_poupana, podem pertencer ao conjunto de entidades de nvel inferior
conta_poupana. Todas as entidades que satisfaam a condio tipo_conta = conta_movimento so
includas em conta movimento. Desde que todas as entidades de nvel inferior sejam classificadas com
base nos mesmos atributos (neste caso, tipo_conta), esse tipo de generalizao chamado
definida_por_atributo.
Definida pelo usurio. Um conjunto de entidades de baixo nvel definido pelo usurio no tem seus
membros classificados por uma condio; as entidades so designadas a um determinado conjunto de
entidades por usurios do banco de dados. Por exemplo, suponhamos que, depois de trs meses de
trabalho, os empregados do banco sejam convocados para compor um dentre os quatro grupo de
trabalho existentes. Esses grupos so representados por quatro conjuntos de entidades de baixo nvel,
derivados do conjunto de entidades de alto nvel empregado. A escolha de um determinado empregado
para participar de um conjunto de entidades de um grupo especfico no originada automaticamente
pela definio de uma condio explcita. Pelo contrrio, a escolha para compor determinado grupo
feita por critrios individuais, pesando na deciso a opinio do usurio, e sua implementao feita por
uma operao que adiciona a entidade ao conjunto de entidades.
O segundo tipo de restrio determina se uma entidade pode ou no pertencer a mais de um conjunto de
entidades de nvel inferior dentro de uma generalizao simples. Os conjuntos de entidades de nvel inferior
podem ser um dos seguintes:
Manuteno exclusivos. Restries mutuamente exclusivas exigem que uma entidade pertena a apenas
um conjunto de entidades de nvel inferior. Em nosso exemplo, uma entidade conta pode satisfazer a
apenas uma condio para o atributo tipo_conta; uma entidade pode ser tanto uma conta poupana
como uma conta movimento, mas nunca ambas.
Sobrepostos. Em generalizaes sobrepostas, uma mesma entidade pode pertencer a mais de um
conjunto de entidades de nvel inferior dentro de uma generalizao simples. Para ilustrao, retornemos
ao exemplo dos grupos de trabalho dos empregados do banco e suponhamos que determinados gerentes
participem de mais de um desses grupos. Um determinado empregado pode, portanto, pertencer a mais
de um conjunto de entidades formadas pelos grupos de trabalho.
Conjuntos de entidades de nvel inferior com sobreposio o caso-padro; restries mutuamente
exclusivas devem ser apresentadas explicitamente em uma generalizao (ou especializao).
Uma restrio final, a restrio de totalidade em uma generalizao, determina se uma entidade de nvel
superior pertence ou no a, no mnimo, um dos conjuntos de entidades de nvel inferior dentro da generalizao.
Essa restrio pode ser uma das seguintes:
Total. Cada entidade do conjunto de entidades de nvel superior deve pertencer a um conjunto de
entidades de nvel inferior.
Parcial. Qualquer entidade de nvel superior pode pertencer a qualquer um dos conjuntos de entidades
de nvel inferior.
A generalizao conta total: todas as entidades contas devem ser contas de poupana ou contas movimento.
Como os conjuntos de entidades de alto nvel de uma generalizao so, geralmente, compostos somente pelas
entidades de nvel inferior. O conjunto de entidades dos grupos de trabalho ilustram uma especializao parcial.
105

Desde que os empregados participem de um dos grupos somente aps trs meses de trabalho, algumas
entidades empregados podem no ser membros de qualquer um dos conjuntos de entidades de grupos de nvel
inferior.
Podemos caracterizar os conjuntos de entidades de grupos de modo completo como especializao
parcial e sobreposta de empregado. A generalizao conta_movimento e conta_poupana de conta total,
generalizao mutuamente exclusiva. As restries de totalidade e de sobreposio, entretanto, ano so
dependentes uma das outra. Os padres de generalizao podem ser parcial-mutuamente-exclusivas e totalsobrepostas.
Podemos ver que certas exigncias para inseres e excluses seguem restries que so aplicadas a
dadas generalizaes ou especializaes. Por exemplo, quando uma restrio total aplicada, uma entidade
inserida em um conjunto de entidades de nvel superior dever ser inserida em pelo menos um de seus conjuntos
de entidades de nvel inferior. Em restries definidas por condio, todas as entidades de nvel superior que
satisfaam tal condio devem ser inseridas nos conjuntos de entidades de nvel inferior. Finalmente, uma
entidade excluda de um conjunto de entidades de nvel superior tambm dever ser excluda de todos os
conjuntos de entidades de nvel inferior s quais pertencem.
Agregao
Uma das limitaes do modelo E-R que no possvel expressar relacionamentos entre
relacionamentos. Para ilustrar a necessidade desse tipo de construtor, consideremos novamente um banco de
dados descrevendo informaes sobre clientes e seus emprstimos. Suponha que cada par emprstimo-cliente
possui um bancrio, ou agente-emprstimo, responsvel pelo acompanhamento de determinado emprstimo.
Usando os construtores do modelo E-R bsico, obteramos o diagrama apresentado na fig. 2.16. Nota-se que o
conjunto de relacionamentos devedor e agente_emprstimo poderia ser combinado em um nico conjunto de
relacionamentos. No entanto, no podemos faz-lo, porque isso tornaria obscura a estrutura lgica desse
esquema. Por exemplo, se combinarmos os conjuntos de relacionamentos devedor e agente_emprestimo, essa
combinao deveria especificar que um agente-emprstimo especfico responsvel por uma par emprstimocliente, o que no ocorre. A separao em dois conjuntos de relacionamentos distintos resolve esse problema.
Entretanto, existe redundncia de informaes na figura resultante, uma vez que todo par emprstimocliente em agente_emprstimo est tambm em devedor. Se o agente_emprstimo fosse um valor, em vez de
uma entidade de empregado, poderamos fazer de agente_emprstimo um atributo multivalorado do
relacionamento devedor. Mas, assim, seria ainda mais difcil (nos custos de lgica e execuo) encontrar, por
exemplo, o par emprstimo-cliente pelo qual determinado bancrio responsvel.
J que um agente de emprstimo uma entidade empregado, essa alternativa descartada em qualquer
caso.

106

O melhor modo de modelar a situao acima descrita usando a agregao. Agregao a abstrao por
meio da qual os relacionamentos so tratados como entidades de nvel superior. Assim, em nosso exemplo,
simbolizamos o conjunto de relacionamentos devedor e o conjunto de entidades cliente e emprstimo como um
conjunto de entidades de nvel superior, chamado devedor.
Como um conjunto de entidades, tratado da mesma forma que qualquer outro conjunto de entidades.
A notao mais comum para a agregao mostrada na fig. 2.17.

107

Projeto de um Esquema de Banco de Dados E-R

O modelo de dados E-R nos d uma flexibilidade substancial par ao projeto de um esquema de banco de
dados na modelagem de determinada empresa. Vamos agora considerar quais as opes possveis para o
projetista dentre o grande nmero de possibilidades. Algumas das possveis opes so:
Optar pelo uso de um atributo ou de um conjunto de entidades para representao de um objeto.
Se uma concepo real expressa de modo mais preciso por um conjunto de entidades ou por um
conjunto de relacionamentos.
Optar por um conjunto de relacionamentos ternrio ou por um par de relacionamento binrio.
Se se deve usar um conjunto de entidades forte. Um conjunto de entidades forte e seus conjuntos de
entidades fracas dependentes podem ser visto como um nico objeto do banco de dados, j que as
entidades fracas tm sua existncia vinculada de uma entidade forte.
Se o uso da generalizao apropriado. A generalizao, ou uma hierarquia de relacionamentos ISA,
contribui para a modularidade, j que atributos comuns a conjuntos de entidades similares podem ser
representados em apenas um local do diagrama E-R.
Se o uso da agregao for apropriado, agregar grupos de uma parte do diagrama E-R em um conjunto de
entidades simples, permitindo-nos tratar do conjunto de entidades agregadas como uma unidade
simples, sem abordar os detalhes de suas estruturas internas.
Podemos notar que um projetista de banco de dados necessidade de um bom entendimento da empresa
que est sendo modelada para que possa tomar essas decises.
Fases de Projeto
108

Um modelo de dados de alto nvel proporciona ao projetista uma base conceitual na qual se pode
especificar, de modo sistemtico, quais as necessidades dos usurios do banco de dados e como este banco de
dados ser estruturado para atender plenamente a todas estas necessidades. A fase inicial do projeto
caracterizar todos os dados necessrios na perspectiva do usurio. O resultado dessa fase a especificao das
necessidades do usurio (ou levantamento de requisitos).
A seguir, o projetista escolhe o modelo de dados e, por meio da aplicao de seus conceitos, transcreve as
necessidades especificadas em um esquema conceitual de banco de dados. O esquema desenvolvido nessa fase
chamado projeto conceitual e proporcional uma viso detalhada da empresa. Como s estudamos o modelo E-R
at agora, iremos us-lo para o desenvolvimento do esquema conceitual. Empregando os termos do modelo E-R,
o esquema deve especificar todos os conjuntos de entidades, relacionamentos, atributos e o mapeamento das
restries. O projetista rev o esquema para confirmar se todos os dados exigidos esto de fato representados e
se no h conflitos entre eles. Ele dever tambm examinar o projeto para remover qualquer tipo de
redundncia. Neste momento, seu enfoque descrever os dados e seus relacionamentos, em vez de especificar
os detalhes fsicos de armazenamento.
O desenvolvimento completo do esquema conceitual ir indicar tambm as necessidades funcionais da
empresa. Na especificao das necessidades funcionais, os usurios descrevem os tipos de operaes (ou
transaes) que sero realizados nos dados. Os exemplos dessas operaes incluem modificao para atualizao
dos dados, pesquisa para recuperao de um determinado dado e remoo de dados. Dever ser feita, nesse
estgio do projeto conceitual, uma reviso do esquema dos dados em funo das necessidades funcionais.
O transporte do modelo de dados abstrato, para sua implementao, ocorre nas duas fases finais do
projeto. Na fase de projeto lgico, o esquema conceitual de alto nvel mapeado para o modelo de
implementao de dados do SGBD que ser usado. O esquema de dados resultante usado para a fase
subsequente, que a do projeto fsico, especificamente dependente dos recursos do SGBD usado. Esses recursos
incluem as formas de organizao de arquivos e estruturas internas de armazenamento.
Vamos abordar somente os conceitos do modelo E-R como usados na fase do projeto do esquema
conceitual.
Dados Necessrios a uma Empresa da rea Bancria
A especificao dos requisitos dos usurios pode ser apurada por meio de entrevistas unidas prpria
avaliao do projetista sobre a empresa.
A descrio resultante dessa fase do projeto a base para a especificao da estrutura conceitual do
banco de dados. A lista de itens que se segue apresenta as principais necessidades de uma empresa da rea
bancria.
Um banco organizado em agncias. Cada agncia localizada em uma cidade e identificada por um
nome nico. O banco controla os fundos de cada uma dessas agncias.
Os clientes do banco so identificados pelo nmero do seu seguro social. O banco mantm dados como
nome, rua, e cidade do cliente. Os clientes podem possuir contas e contrair emprstimos. O cliente pode
estar associado a um bancrio especfico que cuida de seus negcios ou atua como um agente de
emprstimos.
Os empregados do banco tambm so identificados por meio do seu seguro social. A administrao do
banco mantm o nome e o nmero do telefone de cada um de seus empregados, os nomes de seus
dependentes e o nmero do seguro social de seu gerente. O banco tambm possui a data de contrata do
empregado e, com isso, seu tempo de trabalho.
O banco oferece dois tipos de contas contas poupana e contas movimento. As contas movimento
podem possuir mais de um correntista, e um correntista pode possuir mais de uma conta. Cada conta
possui um nico nmero. O banco controla o saldo de cada conta, assim como a data mais recente de
acesso a essa conta. Por outro lado, cada conta poupana possui a taxa de juros associada, assim como
so tambm registrados os excessos nos limites da conta movimento.
109

Um emprstimo originado em uma agncia em particular pode ter sido obtido por um ou mais clientes.
Um emprstimo identificado por um nmero nico. Para cada emprstimo o banco mantm o
montante emprestado, assim como os pagamentos das parcelas. Embora o nmero das parcelas de um
emprstimos no identifique de modo nico um pagamento especfico dentre os muitos realizados no
banco, o nmero da parcela identifica um pagamento especfico dentre os muitos realizados no banco, o
nmero da parcela identifica um pagamento efetuado para um emprstimo em particular. A data e o
montante so registrados no pagamento de cada parcela.

Em um banco real, poderia ser de interesse manter informaes sobre depsitos e retiradas tanto para as contas
poupana quanto para as contas movimento, assim como se mantm informaes sobre o pagamento de
parcelas dos emprstimos. Uma vez que a modelagem dos requisitos dos usurios nas necessidades descritas a
pouco so semelhantes quelas feitas no incio, podemos optar por um exemplo de aplicao mais reduzido, no
fazendo, em nosso modelo, o acompanhamento dos depsitos e das retiradas.
Designao de Conjuntos de Entidades em Empresas Bancrias
Nossa especificao dos requisitos de dados servem como base inicial para a construo de um esquema
conceitual do banco de dados.
Para as especificaes relacionadas, comeamos por identificar os conjuntos de dados e seus atributos.
O conjunto de entidades agncia, com os atributos:
nome_agncia, cidade_agncia, e fundos
O conjunto de entidades cliente, com os atributos:
nome_cliente, seguro_social, rua_cliente e cidade_cliente
Com a possibilidade do atributo adicional nome_bancrio.
O conjunto de entidades empregado, com os atributos:
seguro_social_empregado, nome_empregado, nmero_telefone, salario e gerente.
Recursos adicionais descritivos so os atributos multivalorados nome_dependentes, o atributo bsico
data_incio e o atributo descritivo tempo_de_trabalho.
Dois conjuntos de entidades contas conta_poupana e conta_movimento com os atributos comuns
nmero_conta e saldo; tambm, conta_poupana possui o atributo taxa_de_juros e conta_movimento, o
atributo limite_cheque_especial.
O conjunto de entidades emprstimo, com os atributos:
nmero_emprstimo, total e agncia_origem
So possveis os seguintes atributos adicionais: pagamento_emprstimo, composto multivalorado; com os
seguintes atributos componentes:
nmero_pagamento, data_pagamento e total_pagamento
Designao dos conjuntos de Relacionamentos de uma Empresa da rea Bancria
Retornemos agora ao esquema do projeto descrito para especificar os seguintes conjuntos de
relacionamentos e mapeamentos de cardinalidades:
devedor, como conjunto de relacionamentos muitos para um que indica qual a agncia responsvel pelo
emprstimo.
pagamento_emprstimo, relacionamento um para muitos entre emprstimo e pagamento, que
documento que um pagamento est sendo feito para um determinado emprstimo.
depositante, com os atributos de relacionamento data_acesso, um conjunto de relacionamentos muitos
para muitos entre cliente e conta, indicando que um cliente possui uma conta.

110

agente_cliente, com o atributo de relacionamento tipo, um conjunto de relacionamentos muitos para um

expressando que um cliente pode ser atendido por determinado empregado do banco e que um
empregado do banco pode atender a um ou mais clientes.
trabalha_para, conjunto de relacionamentos entre entidades empregado que determina se se trata de
gerente ou empregado; o mapeamento da cardinalidade expressa que um empregado trabalha para um
gerente especfico e que um gerente supervisiona um ou mais empregados.

Note que trocamos o atributo nome_agente do conjunto de entidades cliente pelo conjunto de relacionamentos
agente_cliente, e o atributo gerente do conjunto de entidades empregado pelo conjunto de relacionamentos
trabalha_para. Optamos por manter o conjunto de entidades emprstimo. O conjunto de relacionamentos
agncia_emprstimo e pagamento_emprstimo foi substitudo, respectivamente, pelos atributos agncia_origem
e pagamento_emprstimo do conjunto de entidades emprstimo.
Digrama E-R de uma Emprstimo de uma Empresa da rea Bancria
Esquematizando, apresentamos agora o diagrama E-R completo para nosso exemplo de empresa da rea
bancria. A fig. 2.18 mostra a representao de um modelo conceitual de um banco, expresso nos termos
conceituais de E-R. O diagrama inclui os conjuntos de entidades, atributos, conjuntos de relacionamentos e o
mapeamento das cardinalidades concludas durante o processo descrito anteriormente, e j refinado.

111

Reduo de um Esquema E-R a Tabelas

Um banco de dados em conformidade com o esquema de banco de dados E-R pode ser representado por
uma coleo de tabelas. Para cada conjunto de entidades e para cada relacionamentos, dentro de um banco de
dados, existe uma tabela nica registrando o nome do conjunto de entidades ou relacionamentos
correspondentes. Cada tabela possui vrias colunas, cada uma delas com um nico nome.
Tanto o modelo E-R quanto o modelo relacional so abstratos, ou seja, representaes lgicas de
empresas reais. Como esses dois modelos empregam princpios de projetos similares, podemos converte o
projeto E-R em projeto relacional. Converter a representao de um banco de dados de um diagrama E-R para um
formato de tabela a base para a derivao de um diagrama E-R de um projeto a partir de um banco de dados
relacional. Embora existam importantes diferenas entre uma relao e uma tabela, informalmente, uma relao
pode ser considerada uma tabela de valores.
Representao Tabular dos Conjuntos de Entidades Fortes

112

Seja E um conjunto de entidades fortes descrito pelos atributos a1, a2, ..., an. Representamos essa
entidade por uma tabela chamada E com n colunas distintas, cada uma delas correspondendo a um dos atributos
de E. Cada linha da tabela corresponde a uma entidade do conjunto de entidades E.
Como ilustrao, considere o conjunto de entidades emprstimo do diagrama E-R mostrado na fig. 2.8.
Esse conjunto de entidades possui dois atributos: nmero_emprstimo e total. Representaremos esse conjunto
de entidades pela tabela chamada emprstimo, com duas colunas, como mostra a fig. 2.19. A linha (L-17, 1000)
da tabela emprstimo significa que o emprstimo de nmero L-17 de mil dlares. Podemos adicionar uma nova
entidade ao banco de dados pela insero de uma linha na tabela. Tambm podemos excluir ou modificar as
linhas.

Denotaremos como D1 o conjunto de todos os nmeros de emprstimos e D2 o conjunto de todos os

saldos. Qualquer linha da tabela emprstimo deve consistir de uma 2-tupla (v1, v2), em que v1 um emprstimo
(isto , v1 est no conjunto D1) e v2 um total (isto , v2 est no conjunto D2). No geral, a tabela emprstimo
conter somente o subconjunto de todas as linhas possveis. Iremos nos referir ao conjunto de todas as linhas
possveis de emprstimo como o produto cartesiano de D1 e D2, denotado por: D1xD2.
No geral, se tivermos uma tabela com n colunas, denotaremos o produto cartesiano de D1, D2, ..., Dn por:
Como outro exemplo, considere o conjunto de entidades cliente do diagrama E-R mostrado na fig. 2.8.
Esse conjunto de entidades tem os atributos nome_cliente, seguro_social, rua_cliente e cidade_cliente. A tabela
correspondente a cliente tem quatro colunas, como mostra a fig. 2.20.

Representao Tabular dos Conjuntos de Entidades Fracas

Seja A um conjunto de entidades fracas com os atributos a1, a2, ..., an. Seja B um conjunto de entidades
fortes, do qual A dependente. Seja a chave primria de B composta pelos atributos b1, b2, ..., bn. Representamos
o conjunto de entidades A pela tabela chamada A com uma coluna para cada um dos atributos do conjunto:
113

Como ilustrao, considere o conjunto de entidades pagamento mostrado no diagrama E-R da fig. 2.14.
Esse conjunto de entidades tem trs atributos: nmero_pagamento, data_pagamento e total_pagamento. A
chave primria do conjunto de entidades emprstimo, do qual pagamento dependente, o
nmero_emprstimo. Assim, pagamento representado por uma tabela com quatro colunas chamadas
nmero_emprstimo, nmero_pagamento, data_pagamento e total_pagamento, como mostrado na fig. 2.21.

Representao Tabular do Conjunto de Relacionamentos

Seja R um conjunto de relacionamentos; seja a1, a2, ..., an o conjunto de atributos formado pela unio das
chaves primarias de cada um dos conjuntos de entidades participantes de R; e seja os atributos descritivos b1, b2,
..., bn (se houver) de R. Representamos esse conjunto de relacionamentos pela tabela chamada R, com uma
coluna para cada atributo do conjunto:
Para ilustrar, considere o conjunto de relacionamentos devedor no diagrama E-R da fig. 2.8. Esse conjunto
de relacionamentos envolve os dois conjuntos de entidades seguintes:
cliente, com a chave primria seguro_social.
Emprstimo, com a chave primria nmero_emprstimo.
Uma vez que o conjunto de relacionamentos no possui atributos prprios, a tabela devedor possui duas colunas,
a de seguro_social e nmero_emprstimo, como mostra a fig. 2.22.

Tabelas Redundantes
114

O caso do conjunto de relacionamentos unindo um conjunto de entidades fracas ao seu conjunto de

entidades fortes correspondente um caso especial. Como pudemos ver anteriormente, esses relacionamentos
so muitos para um e no possuem atributos descritivos. Alm disso, a chave primria de um conjunto de
entidades fracas inclui a chave primria do conjunto de entidades fortes. No diagrama E-R da fig. 2.14, o conjunto
de entidades fracas pagamento dependente do conjunto de entidades fortes emprstimo por meio do conjunto
de relacionamentos pagamento_emprstimo. A chave primria de pagamento {nmero_emprstimo,
nmero_pagamento} e a chave primria de emprstimo {nmero_emprstimo}. Desde que
pagamento_emprstimo no possui atributos descritivos, a tabela para pagamento_emprstimo poderia ter duas
colunas, nmero_emprstimo e nmero_pagamento. A tabela para o conjunto de entidades pagamento tem
quatro colunas, nmero_emprstimo, nmero_pagamento, data_pagamento e total_pagamento. Assim, a tabela
pagamento_emprstimo redundante. Em geral, a tabela para o conjunto de relacionamentos unindo o conjunto
de entidades fracas com seu conjunto de entidades fortes correspondente redundante e no precisa ser
apresentada em uma representao tabular do diagrama E-R.
Combinao de tabelas
Considere um conjunto de relacionamento muitos para um AB entre os conjuntos de entidades A e B.
Usando nosso esquema de construo de tabelas previamente descrito, teremos trs tabelas: A, B e AB.
Entretanto, se existe dependncia de A sobre B (isto , para cada entidade a em A, a existncia de a depende da
existncia de alguma entidade b em B), ento podemos combinar as tabelas A e AB para formar uma tabela
simples consistindo da unio das colunas de ambas as tabelas.
Como ilustrao, considere o diagrama E-R da fig. 2.23. O conjunto de relacionamentos entre conta e
agncia, agncia_conta, muitos para um. Daqui para frente, uma linha dupla no diagrama E-R indica que a
participao de conta em conta_agncia total. Da, uma conta no pode existir sem que esteja associada a uma
agncia em particular. Portanto, necessitamos somente de duas tabelas:
conta, com os atributos nmero_conta, saldo e nome_agncia.
agncia, com atributos nome_agncia, cidade_agncia e fundos.

Atributos Multivalorados
Vimos que, em geral, os atributos do diagrama E-R so mapeados diretamente em colunas nas tabelas
apropriadas. Atributos multivalorados, entretanto, constituem uma exceo; novas tabelas so criadas para esses
tipos de atributos.
Para um atributo multivalorado M, criamos a tabela T com uma coluna C que corresponde a M e as
colunas correspondentes chave primria do conjunto de entidades ou conjunto de relacionamento do qual M
atributo. Como ilustrao, considere o diagrama E-R apresentado na fig. 2.18. o diagrama inclui o atributo
multivalorado nome_dependente. Para esse atributo multivalorado, criamos a tabela nome_dependente com as
colunas nomed, referente ao atributo nome_dependente do empregado, e seguro_social_empregado,

115

representando a chave primria do conjunto de entidades empregado. Cada dependente de um empregado

representado por uma nica linha na tabela.
Representao Tabular da Generalizao
Existem dois modos diferentes de transformar um diagrama E-R que contenha generalizao em tabelas.
Embora nos refiramos generalizao mostrada na fig. 2.15, preferimos simplificar essa discusso incluindo
somente o primeiro grupo dos conjuntos de entidades de nvel inferior isto , os atributos conta_poupana e
conta_movimento.
1. Criar a tabela para o conjunto de entidades de nvel superior. Para cada conjunto de entidades de nvel
inferior, criar uma tabela que inclua uma coluna para cada um dos coluna para cada um dos atributos
daquele conjunto de entidades mais uma coluna para cada atributo da chave primria do conjunto de
entidades mais uma coluna para cada atributo da chave primria do conjunto de entidades de nvel
superior. Assim, para o diagrama da fig. 2.15, teremos trs tabelas:
conta, com os atributos nmero_conta e saldo.
conta_poupana, com os atributos nmero_conta e taxa_juros.
conta_movimento, com os atributos nmero_conta e limite_cheque_especial.
2. Se a generalizao mutuamente exclusiva e total isto , se nenhuma entidade membro de mais de
um conjunto de entidades de nvel imediatamente inferior ao conjunto de entidades de nvel superior e
se todas as entidades do conjunto de entidades de nvel inferior , ento, uma outra representao
alternativa possvel. Para cada conjunto de entidades de nvel inferior, cria-se uma tabela que inclua
uma coluna para cada um dos atributos do conjunto de entidades mais uma coluna para cada atributo do
conjunto de entidades de nvel superior. Ento, para o diagrama E-R da fig. 2.15, teremos duas tabelas.
Conta_poupana, com atributos nmero_conta, saldo e taxa_juros.
Conta_movimento, com os atributos nmero_conta, saldo e limite_cheque_especial.
As relaes correspondentes a conta_poupana e conta_movimento para essas tabelas tm, ambas, saldo
como chave primria.
Se o segundo mtodo for usado para generalizaes com sobreposio, alguns valores, como saldo,
podem ser armazenados duas vezes sem necessidade. Similarmente, se a generalizao no for total isto , se
algumas contas no forem nem de poupana nem de movimento, ento tais contas no podero ser
representadas usando o segundo mtodo.
Representao Tabular da Agregao
A transformao de um diagrama E-R com agregao para forma tabular bastante direta. Considere o
diagrama da fig. 2.17. A tabela para o conjunto de relacionamentos agente_emprstimo inclui uma coluna para
cada atributo, uma para a chave primria do conjunto de entidades empregado e uma para o conjunto de
relacionamentos devedor. Poderia tambm incluir uma coluna para cada um dos atributos descritivos do
conjunto de relacionamentos agente_emprstimo, se eles existirem. Usando o mesmo procedimento anterior
para o resto do diagrama, criamos as seguintes tabelas:
cliente, com os atributos nome_cliente, seguro_social, rua_cliente e cidade_cliente.
emprstimo, com os atributos nmero_emprstimo e total.
devedor, com os atributos seguro_social e nmero_emprstimo.
empregado, com os atributos seguro_social_empregado, nome_empregado, e nmero_telefone.
agente_emprstimo, com os atributos seguro_social, nmero_emprstimo e seguro_social_empregado.

116

Arquiteturas de Sistemas de Banco de Dados

A arquitetura de um sistema de banco de dados fortemente influenciada pelo sistema bsico
computacional sobre o qual o sistema de banco de dados executado. Aspectos da arquitetura de computadores
como rede, paralelismo e distribuio tm influncia na arquitetura do banco de dados.
Rede de computadores permite que algumas tarefas sejam executadas no servidor do sistema e outras
sejam executadas no cliente. Essa diviso de trabalho tem levado ao desenvolvimento de sistemas de
banco de dados cliente-servidor.
Processamento paralelo em um sistema de computadores permite que atividades do sistema de banco de
dados sejam realizadas com mais rapidez, reduzindo o tempo de resposta das transaes e, assim,
aumentando o nmero de transaes processadas por segundo. Consultas podem ser processadas de
forma a explorar o paralelismo oferecido pelo sistema operacional. A necessidade de processamento
paralelo de consultas tem levado ao desenvolvimento de sistemas de banco de dados paralelos.
A distribuio de dados pelos ns da rede ou pelos diversos departamentos de uma organizao
permitem que esses dados residam onde so gerados ou mais utilizados, mas, ainda assim, estejam
acessveis para outros ns de outros departamentos. Dispor de diversas cpias de um banco de dados em
diferentes ns tambm permite a organizaes de grande porte manter operaes em seus bancos de
dados mesmo quando um n afetado por um desastre natural, como inundaes, incndios ou
terremotos. Sistemas de banco de dados distribudos tm se desenvolvido para tratar dados distribudos
geogrfica ou administrativamente por diversos sistemas de banco de dados.
Vamos agora estudar a arquitetura dos sistemas de banco de dados, comeando com os sistemas
centralizados tradicionais e passando por sistemas de banco de dados cliente-servidor, paralelos e distribudos.
Sistemas Centralizados
Sistemas de banco de dados centralizados so aqueles executados sobre um nico sistema computacional
que n ao interagem com outros sistemas. Tais sistemas podem ter a envergadura de um sistema de banco de
dados de um s usurio executado em um computador pessoal at sistemas de alto desempenho em sistema de
grande porte.
Um sistema computacional genrico moderno consiste em uma ou poucas CPUs e dispositivos de controle
que so conectados por meio de um bus comum que proporciona acesso memria compartilhada (fig. 16.1). As
CPUs tm memrias cache locais que armazenam cpias de partes da memria para acesso rpido aos dados.
Cada dispositivo de controle atende a um tipo especfico de dispositivo (por exemplo, um drive de disco, um
dispositivo de udio ou de vdeo). A CPU e os dispositivos de controle podem trabalhar concorrentemente,
competindo pelo acesso memria. A memria cache parcialmente reduz a conteno de acesso memria,
uma vez que reduz o nmero de tentativas de acesso da CPU memria compartilhada.

117

Dividimos em dois modos a forma pela qual os computadores so usados: por um sistema de um nico
usurio e sistemas multiusurios. Computadores pessoais e estaes de trabalho caem na primeira categoria. Um
sistema monousurio tpico uma unidade de trabalho de uma nica pessoa, com uma nica CPU e um ou dois
discos rgidos, com um sistema operacional que pode dar suporte a apenas um nico usurio. Um sistema
multiusurio tpico, por outro lado, possui um nmero maior de discos e rea de memria, podendo ter diversas
CPUs e um sistema operacional multiusurio. Atende a um grande nmero de usurios que esto conectados ao
sistema por meio de terminais. Tais sistemas so frequentemente chamados de sistemas servidor.
Sistemas de banco de dados projetados para ser monousurios, como os de computadores pessoais,
normalmente no proporcionam muitos recursos comuns aos banco de dados multiusurios. Em particular, ele
no do suporte ao controle de concorrncia, o que no necessrio quando somente um usurio pode gerar
atualizaes.
A recuperao de perdas nesse tipo de sistema , seno inexistente, primitiva por exemplo, fazendo um
backup do banco de dados antes de qualquer atualizao. Muitos desses sistemas no do suporte SQL,
fornecendo linguagens de consulta bem mais simples, como uma variante da QBE.
Embora os sistemas de computadores de propsito geral possuam atualmente mltiplos processadores,
eles tm paralelismo de granulao-grossa, com um nmero limitado de processadores (entre dois e quatro,
normalmente), todos compartilhando a memria principal. Os banco de dados rodando em tais equipamentos
normalmente no promovem o particionamento de uma consulta entre processadores: ao contrrio, cada
consulta roda em um nico processador, permitindo que diversas consultas sejam executada concorrentemente.
Assim, tais sistemas proporcionam alto throughput, isto , um grande nmero de transaes processador por
segundo, embora uma transao, individualmente, no seja necessariamente processada com maior rapidez.
Banco de dados processados em equipamento de um s processador j dispem de recursos multitarefas,
nos quais diversos processos podem ser executados em um mesmo processador de modo compartilhado, dando
ao usurio a impresso de que diversos processos so executados em paralelo. Assim, equipamentos com
paralelismo de granulao-grossa parecem, na lgica, idnticos a um equipamento de um nico processador;
sistemas de banco de dados projetados para equipamentos time-shared podem facilmente ser adaptados para
esse ambiente.
Em contrate, os equipamentos de granulao-fina tm um grande nmero de processadores, e os
sistemas de banco de dados rodando nesse tipo de equipamento podem processar unidades de tarefas
(consultas, por exemplo) submetidas pelos usurios em paralelo.
118

Sistemas Cliente-Servidor
Como os computadores pessoais tm se tornado mais rpidos, mais poderosos e baratos, h uma
tendncia de seu uso nos sistemas centralizados. Terminais conectados a sistemas centralizados esto sendo
substitudos por computadores pessoais. Simultaneamente, interfaces com o usurio usadas funcionalmente para
manuseio direto com sistemas centralizados esto sendo adequadas ao trato com computadores pessoais.
Como resultado, sistemas centralizados atualmente agem como sistemas servidores que atendem a
solicitaes de sistemas clientes. A estrutura geral de um sistema cliente-servidor exibida na fig. 16.2.
As funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias
front-end e back-end como mostra a fig. 16.3. O back-end gerencia as estruturas de acesso, desenvolvimento e
otimizao de consultas, controle de concorrncia e recuperao. O front-end dos sistemas de banco de dados
consiste em ferramentas como formulrios, gerador de relatrios e recursos de interface grfica. A interface
entre front-end e o back-end feita por meio da SQL ou de um programa de aplicao.

Sistemas servidores podem ser caracterizados, de modo geral, como servidores de transaes e
servidores de dados.
Sistemas servidores de transaes, tambm chamados sistemas servidores de consultas (query-server),
proporcionam uma interface por meio da qual os clientes podem enviar pedidos para determinada ao
e, em resposta, eles executam a ao e mandam de volta os resultados ao cliente. Usurios podem
especificar pedidos por SQL ou por meio de um programa de aplicao usando um mecanismo de
chamada de procedimento remota (remote-procedure-call).
Sistemas servidores de dados permitem que os servidores interajam com clientes que fazem solicitaes
de leitura e atualizao de dados em unidades como arquivos ou pginas. Por exemplo, servidores de
arquivos que proporcionam uma interface sistema-arquivo na qual os clientes podem criar, atualizar, ler e
remover arquivos. Servidores de dados para sistemas de banco de dados oferecem muito mais recursos:
do suporte a unidades de dados como pginas, tuplas ou objetos menores que um arquivo.
Proporcionam meios para indexao de dados e transaes, tal que os dados nunca se tornem
inconsistentes se um equipamento cliente ou processo falhar.

119

Servidores de Transaes
Em sistemas centralizados, o front-end e o back-end so ambos executados dentro de um nico sistema.
Entretanto, a arquitetura de servidores de transaes segue a diviso funcional entre front-end e back-end.
Devido grande exigncia de processamento para cdigo de interface grfica e ao aumento do poder de
processamento dos computadores pessoais, o recurso para front-end possvel em computadores pessoais. Os
computadores pessoais agem como clientes de sistemas servidores, os quais armazenam grandes volumes de
dados e do suporte aos recursos de back-end. Clientes enviam solicitaes ao sistema servidor no qual essas
transaes so executadas e os resultados so enviados de volta ao cliente que tem a responsabilidade de exibir
esses dados.
Padres do tipo ODBC (open database connectivity) visam atender interface de clientes e servidores.
ODBC so programas de aplicao de interface que possibilitam aos clientes a criao de comandos SQL que so
enviados para o servidor, no qual so executados. Qualquer cliente que use uma interface ODBC pode se conectar
a qualquer servidor que fornea essa interface. Nas primeiras geraes de sistemas de banco de dados, a falta
desse tipo de padro levou ao uso de software de mesmo fabricante tanto para back-end quanto para front-end.
Com a difuso de padres para interfaces, diversos fabricantes passaram a disponibilizar ferramentas de
front-end e os servidores back-end. Gupta SQL e PowerBuilder so exemplos de sistemas front-end
independentes dos servidores back-end. Logo, alguns programas de aplicao, como as planilhas eletrnicas e
pacotes para anlise estatstica, usaro interfaces cliente-servidor para acesso direto aos dados de um servidor
back-end. Com efeito, eles funcionam como front-ends especializados para tarefas especficas.
Interfaces cliente-servidor no ODBC so tambm usadas para alguns sistemas de processamento de
transaes. So definidas por uma interface de programa de aplicao na qual os clientes enviam chamadas de
procedimento transacional remota (transactional remote procedure call) para o servidor. Essas chamadas
parecem chamadas de procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de
procedimentos simples feitas por programas, mas, na verdade, todas as chamadas de procedimentos remotas
feitas pelo cliente so encapsuladas em uma nica transao para o servidor. Assim, se a transao for abortada,
o servidor poder reverter os resultados da chamada de procedimento remota.
Como os equipamentos pequenos e individuais apresentam atualmente custo bem menor de aquisio e
manuteno, as grandes corporaes tendem a adotar o down-sizing. Muitas empresas esto substituindo seus
equipamentos de grande porte por redes de computadores com estacoes de trabalho ou computadores pessoais
conectados a equipamentos servidores back-end. Algumas das vantagens so a maior funcionalidade e o menor
custo, mais flexibilidade na disseminao, expanso e alocao dos recursos, melhores interfaces com os usurios
e manuteno mais fcil.
Servidores de dados
Sistemas servidores de dados so usados em redes locais, nas quais h conexes de alta velocidade entre
clientes e servidores, os equipamentos clientes so comparveis, em poder de processamento, aos equipamentos
servidores e as tarefas executadas so do tipo processamento intensivo. Em tal ambiente, faz sentido o trfego de
dados para o equipamento cliente, para o processamento local (o que pode levar certo tempo) e ento o envio
dos dados de volta para o servidor. Note que essa arquitetura exige ampla funcionalidade back-end (fig. 16.3) nos
clientes. Arquiteturas de servidores de dados tm sido comuns nos sistemas de banco de dados orientados a
objetos.
A origem do interesse nesse tipo de arquitetura surge a partir do momento em que o custo, relativo ao
consumo de tempo, da comunicao entre cliente e servidor alta comparada ao tempo de referncia memria
local (milissegundos versus menos de cem nanossegundos).
Transmisso de pginas versus transferncia de itens. A unidade de comunicao para os dados pode ser
de granularidade grossa, como uma pgina, ou de granularidade fina, como uma tupla (ou um objeto, no
contexto de banco de dados orientado a objetos).

120

Se a unidade de comunicao um nico item, o overhead para a troca de mensagens alto se

comparado ao volume de dados transmitido. Quando um item solicitado, faz sentido tambm enviar
outros itens que certamente sero usados em um futuro prximo. A busca de itens antes mesmo que
sejam solicitados chamada prefetching. A transferncia de pginas pode ser considerada uma forma de
prefetching se diversos itens residirem em uma mesma pgina, j que todos os itens na pgina so
transferidos quando um processo deseja ter acesso a um nico item de uma pgina.
Bloqueio. Os bloqueios, em geral, so utilizados pelo servidor em itens de dados transitando entre
clientes. Uma desvantagem da transferncia de pginas que as mquinas clientes precisam bloquear a
unidade da granularidade um bloqueio de uma pgina implica o bloqueio de todos os itens dessa
pgina. Mesmo que o cliente no esteja acessando mais de um item dessa pgina, fica implcito o
bloqueio sobre todos os itens reservados. Outro cliente que solicite bloqueio nesses itens ser impedido
desnecessariamente. Algumas tcnicas para escala de liberao de bloqueio (lock deescalation) j foram
propostas, nas quais o servidor pode solicitar de volta para seus clientes a transferncia dos bloqueios
dos itens reservados. Se o cliente no precisar de um item reservado, ele pode transferir o bloqueio do
item de volta ao servidor, que ento pode ser bloqueado por outro cliente.
Data caching. Os dados que navegam para um cliente durante uma transao pode ser cached no cliente,
mesmo depois de completada a transao, se houver espao suficiente disponvel. Transaes sucessivas
em um mesmo cliente podem acarretar o uso de dados cached. Entretanto, o uso de cache exige certa
coerncia: mesmo que uma transao ache um dado cached, preciso ter certeza de que esse dado
esteja atualizado, uma vez que ele pode ter sido alterado por um outro cliente depois de ter sido
colocado em cache. Assim, uma mensagem precisar ainda ser trocada com o servidor para checar a
validade e conseguir um bloqueio sobre o dado.
Bloqueio cache (lock caching). Se os dados forem bem particionados entre os clientes, com um cliente
raramente solicitando um dado ao mesmo tempo que outro, os bloqueios podem tambm ser
armazenados localmente (cached) no equipamento cliente. Suponha que um item de dado esteja em
cache e que o bloqueio solicitado para acesso a esse dado tambm esteja em cache. Ento, o acesso pode
ser realizado sem qualquer comunicao com o servidor. Entretanto, o servidor precisa controlar os
bloqueios em cache: se um cliente solicita um bloqueio ao servidor, o servidor precisa recuperar todos os
bloqueios em conflito de itens de dados de qualquer outro equipamento cliente que possua bloqueio em
cache. Essa tarefa torna-se muito mais complicada quando so consideradas as falhas de equipamento.
Essa tcnica difere da escala de liberao de bloqueios apenas pelo fato de ser realizada ao longo da
transao; de resto, ambas as tcnicas so similares.

Sistemas Paralelos
Sistemas paralelos imprimem velocidade ao processamento e I/O por meio do uso em paralelos de
diversas CPUs e discos. Equipamentos paralelos esto se tornando bastante comuns, fazendo com que o estudo
de sistema de bancos de dados paralelos seja tambm cada vez mais importante. O direcionamento das atenes
para os sistemas de banco de dados paralelos proveem da demanda de aplicaes que geram consultas em banco
de dados muito grandes (da ordem de terabytes isto , 1012 bytes) ou que tenham de processar um volume
enorme de transaes por segundo (da ordem de milhares de transaes por segundo). Sistemas de banco de
dados centralizados e cliente-servidor no so poderosos o suficiente para tratar desse tipo de aplicao.
No processamento paralelo, muitas operaes so realizadas simultaneamente, ao contrrio do
processamento serial, no qual os passos do processamento so sucessivos. Um equipamento paralelo de
granulao-grossa consiste em poucos e poderosos processadores; um paralelismo intensivo ou de granulaofina usa milhares de pequenos processadores; um paralelismo intensivo ou de granulao-fina usa milhares de
pequenos processadores. A maioria das mquinas high-end, atualmente, oferece algum grau de paralelismo de
granulao-grossa: dois a quatro processadores em uma nica mquina j comum. Computadores de
paralelismo intensivo podem ser diferenciados dos equipamentos de paralelismo de granulao-grossa pelo grau
121

de paralelismo muito mais alto que podem oferecer. Computadores paralelos com centenas de CPUs e discos j
esto disponveis comercialmente.
So duas as principais formas de avaliar o desempenho de um sistema de banco de dados. A primeira o
throughput: o nmero de tarefas realizadas em um dado intervalo de tempo. A segunda o tempo de resposta: o
tempo total que o sistema leva para completar uma nica tarefa. Um sistema que processa um grande nmero de
pequenas transaes pode aumentar o throughput por meio do processamento de diversas transaes em
paralelo. Um sistema que processa um grande volume de transaes pode aumentar o tempo de resposta, assim
como o throughput por meio do processamento em paralelo.
Acelerao e Escalabilidade
Duas metas so importantes no estudo do paralelismo, a acelerao e a escalabilidade. A acelerao
refere-se reduo do tempo de execuo de uma tarefa por meio do aumento do grau de paralelismo. A
escalabilidade diz respeito ao manuseio de um maior nmero de tarefas por meio do aumento do grau de
paralelismo.
Considere uma aplicao de banco de dados rodando em um sistema paralelo com um certo nmero de
processadores e discos. Agora, suponha que incrementemos o nmero de processadores ou discos e outros
componentes do sistema. A meta processar a tarefa em tempo inversamente proporcional aos processadores e
discos alocados. Suponha que o tempo de execuo de uma tarefa em um equipamento de grande porte seja TL e
que o tempo de execuo da mesma tarefa em uma mquina de menor porte seja TS. A acelerao em funo do
paralelismo definida por Ts/TL.
O sistema paralelo apresenta um comportamento de acelerao linear se a acelerao for N quando um
sistema de maior porte tiver N vezes mais recursos (CPU, disco e assim por diante) que o sistema de menor porte.
Se a acelerao menor que N, diz-se que o sistema apresenta comportamento de acelerao sublinear. A fig.
16.4 ilustra as aceleraes linear e sublinear.

A escalabilidade relaciona-se capacidade de processar grande volume de tarefas em um mesmo

intervalo de tempo por meio do aumento dos recursos. Seja Que uma tarefa e QN uma tarefa que N vezes maior
que Q. Suponha que o tempo de execuo de Que em um determinado equipamento MS seja TS e o tempo de
execuo da tarefa QN em um equipamento paralelo ML, que N vezes maior que MS, seja TL.
A escalabilidade , ento, definida como TS /TL. o sistema paralelo ML apresenta um comportamento de
escalabilidade linear na tarefa Q se TL = TS. Se TL > TS, o sistema apresenta um comportamento de escalabilidade
sublinear. A fig. 16.5 ilustra a escalabilidade linear e sublinear. H dois tipos de escalabilidade relevantes em
sistemas de banco de dados paralelos, dependendo de como se mede a tarefa:
Na escalabilidade em lote (batch), o tamanho do banco de dados aumenta e as tarefas so grandes jobs
cujo tempo de execuo depende do tamanho do banco de dados. Um exemplo de tarefa desse tipo a
pesquisa em uma relao cujo tamanho proporcional ao tamanho do banco de dados. Assim, o
tamanho do banco de dados determinante para a medio do problema. A escalabilidade no
122

processamento em lote tambm vale para as aplicaes cientficas, como na execuo de uma consulta
com refinamento de N vezes ou a execuo de uma simulao com N repeties.
Na escalabilidade de transao, a taxa de submisso das transaes para o banco de dados aumenta e o
tamanho do banco de dados aumenta proporcionalmente taxa de transaes. Esse tipo de
escalabilidade o que relevante nos sistemas de processamento de transaes nos quais as transaes
so pequenas atualizaes por exemplo, um depsito ou saque de uma conta e a taxa de transaes
cresce medida que mais contas so criadas. Esse tipo de processamento de transaes especialmente
adequado para execuo em paralelo, uma vez que as transaes podem ser executadas concorrente e
independentemente em processadores separados, e cada transao leva, aproximadamente, o mesmo
tempo, at mesmo se o banco de dados crescer.

A escalabilidade a mais importante mtrica para medir a eficincia de um sistema de banco de dados
paralelo. Normalmente, o objetivo do paralelismo em sistemas de banco de dados garantir um desempenho
aceitvel, mesmo se o tamanho do banco de dados e o volume de transaes crescerem. O aumento da
capacidade do sistema em funo do paralelismo proporciona um caminho mais suave para o crescimento de
uma empresa que a transferncia do sistema centralizado para um equipamento mais rpido (mesmo supondo
que tal mquina exista).
Entretanto, devemos tambm dar uma olhada nos nmeros relativos ao desempenho absoluto quando
avaliamos a escalabilidade: uma mquina cujo crescimento da escalabilidade seja linear pode resultar em um
desempenho pior que outra cuja escala de crescimento seja menor que a linear, porque se partiu de uma
premissa indevida.
Alguns fatores trabalham contra a eficincia das operaes em paralelo e podem reduzir tanto a
acelerao quanto a escalabilidade.
Custo inicial. Existe um custo inicial associado inicializao de um processo. Em operaes paralelas
consistindo de milhares de processos, o tempo de iniciao (startup time) pode se sobrepor ao tempo
real de processamento, afetando de modo negativo a acelerao.
Interferncia. Uma vez que os processos executando em um sistema paralelo frequentemente mantem
seus acessos a recursos compartilhados, alguma lentido pode resultar da interferncia de cada novo
processo, j que ele disputar os recursos comuns com os processos existentes, tais como cabos, discos
compartilhados ou mesmo bloqueios. Tanto a acelerao quanto a escalabilidade so afetadas por esse
fenmeno.
Distoro (skew). Com a quebra de uma tarefa em um nmero determinado de passos paralelos
reduzimos o tamanho do passo mdio. Nem sempre o tempo de servio do passo mais lento determinar
o tempo de servio para a tarefa como um todo. Frequentemente, difcil dividir uma tarefa em partes
iguais e o modo de estabelecer essas partes , portanto, distorcido. Por exemplo, se uma tarefa de
tamanho menor que 10 ou de tamanho maior que 10; mesmo que uma tarefa tenha tamanho 20, a
123

acelerao obtida executando as tarefas em paralelo de apenas 5, em vez de 10, como poderia ser
esperado.
Interconexo de Redes
Os sistemas paralelos so conjuntos de componentes (processadores, memria, e discos) que podem se
comunicar entre si via redes interconectadas. Exemplos de interconexo de redes incluem:
Bus. Todos os componentes do sistema podem enviar e receber dados em um nico bus (cabo) de
comunicao. O bus pode ser uma ethernet ou um interconector paralelo. Arquiteturas com bus
trabalham bem com um pequeno nmero de processadores. Entretanto, no respondem bem ao
aumento do paralelismo, j que o bus s pode servir a uma comunicao por vez.
Malha (mesh). Os componentes so organizados como ns de uma grade, e cada componente
conectado na grade a todos os componentes adjacentes. Em uma malha bidimensional, cada n
conectado a quatro ns adjacentes, enquanto em uma malha tridimensional, cada n conectado a seis
ns adjacentes. Os ns que no esto diretamente interconectados podem se comunicar roteando
mensagens por meios dos ns intermedirios. O nmero de ligaes para comunicao cresce com o
crescimento do nmero de componentes e a capacidade de comunicao da malha, portanto responde
melhor ao aumento do paralelismo.
Hipercbica (hypercube). Os componentes so numerados em binrios e um componente conectado a
outro se a representao binaria de seus nmeros diferirem em exatamente um bit. Assim, cada um dos n
componentes est conectado a log(n) outros componentes. Isso pode ser verificado quando em uma
interconexo hipercbica uma mensagem de um componente pode alcanar outro por meio de, no
mximo, log(n) ligaes. Em contraste, em uma malha, um componente pode manter -1 ligacoes com
algum outro componente (ou /2 ligacoes, se a interconexo pela malha alcanar as bordas da grade).
Assim, atrasos na comunicao em um hipercubo so significativamente menores que em uma malha.
Arquiteturas de Banco de Dados Paralelo
H diversos modelos arquitetnicos para mquinas paralelas. Entre elas, as mais promissoras so
mostradas na fig. 16.6 (na figura, M denota memria, P, processador e os discos so representados por cilindros):
Memria compartilhada. Todos os processadores compartilham uma mesma memria. Esse modelo
mostrado na fig. 16.6a.
Disco compartilhado. Todos os processador compartilham o mesmo disco. Esse modelo mostrado na
fig. 16.6b. Sistemas com discos compartilhados so, s vezes, chamados de clusters.
Ausncia de compartilhamento. Os processadores no compartilham nem a memria nem disco. Esse
modelo apresentado na figura 16.6c.
Hierrquico. Esse modelo mostrado na fig. 16.6d; ele um hibrido das arquiteturas anteriores.

124

Memria compartilhada
Na arquitetura com memria compartilhada, os processadores e os discos acessam a memria comum,
normalmente, por meio de cabo ou por meio de rede de interconexo. A vantagem da memria compartilhada
sua extrema eficincia na comunicao entre processadores qualquer processador pode ter acesso aos dados
em memria compartilhada sem necessidade de ser movido por software. Um processador pode enviar
mensagens a outro processador usando a memria. Essas trocas de mensagens so bem mais rpidas
(normalmente, menos de um microssegundo) se comparadas s que usam mecanismos de comunicao. O
problema das mquinas com memria compartilhada que a arquitetura no adequada ao uso de mais de 32
ou 64 processadores, uma vez que o bus ou a interconexo por rede torna-se um gargalo (pois compartilhado
por todos os processadores). Aps determinado ponto, adicionar mais processadores no resolve; eles gastaro a
maior parte de seu tempo esperando sua vez de usar o bus para acesso memria. Arquiteturas de memria
compartilhada utilizam, normalmente, grande memria cache em cada processador para que o acesso memria
compartilhada seja evitado sempre que possvel. Porm, pelo menos alguns desses dados no estaro em
memria cache e os acessos sero dirigidos memria compartilhada. Consequentemente, mquinas com
memria compartilhada no possibilitam aumento de escala alm de determinado ponto; as mquinas de
memria compartilhada, atualmente, no do suporte a mais de 64 processadores.
Disco Compartilhado
No modelo de disco compartilhado, todos os processadores podem ter acesso direto a todos os discos, via
interconexo por rede, mas os processadores possuem memrias prprias. H duas vantagens da arquitetura de
discos compartilhados sobre a de memria compartilhada. Primeiro, uma vez que cada processador possui
memria exclusiva, o bus de memria no representa um gargalo. Segundo, essa arquitetura oferece um modo
barato de aumentar a tolerncia a falhas: se o processador (ou sua memria) falha, o outro processador pode
assumir suas tarefas, j que o banco de dados residente nos discos acessvel a todos os processadores. Podemos
fazer o subsistema de discos, ele prprio, tolerante a falhas usando a arquitetura RAID. A arquitetura de discos
compartilhados vem obtendo aceitao em diversos tipos de aplicaes; os sistemas construdos sobre
arquitetura desse tipo so frequentemente chamados de clusters.

125

O principal problema dos sistemas de discos compartilhados , novamente, o grau de crescimento.

Embora o bus de memria no represente mais um gargalo, a restrio agora a interconexo com o subsistema
de discos; esse caso particularmente determinante quando o banco de dados acessa muito os discos.
Comparando aos sistemas de memria compartilhada, os sistemas de discos compartilhados podem ser usados
com um nmero maior de processadores, mas a comunicao entre os processadores lenta (um pouco acima de
milissegundos quando no h hardware especfico para a comunicao), uma vez que ela tem de atravessar a
rede.
Cluster DEC rodando Rdb foi um dos primeiros usurios comerciais a utilizar a arquitetura de discos
compartilhados (o Rdb atualmente propriedade da Oracle e chamado de Oracle Rdb).
Ausncia de Compartilhamento
Em um sistema sem compartilhamento, cada equipamento de um n consiste em um processador, uma
memria e discos. O processador de um n pode comunicar-se com outros processadores de outros ns usando
intercomunicao de rede de alta velocidade. Um n serve de servidor dos dados alocados em seus discos. Uma
vez que as referncias aos discos so atendidas em cada processador por discos locais, o modelo sem
compartilhamento transpe os percalos de submeter todos os I/Os por meio de uma nica rede de
interconexo; somente consultas, acessos a discos remotos e o resultado das relaes so transportados por
meio da rede. Alm disso, as redes de interconexo dos sistemas sem compartilhamento so normalmente
projetadas para permitir o crescimento de escala, o que significa que sua capacidade aumenta quanto mais ns
so acrescidos. Consequentemente, arquiteturas sem compartilhamento so mais flexveis quanto escala e
podem, facilmente, dar suporte a um grande nmero de processadores. Os principais problemas dos sistemas
sem compartilhamento so os custos de comunicao e os acessos a discos remotos, que so maiores que no
arquitetura com memria ou discos compartilhados, j que a transmisso de dados envolve interao feita por
software em ambos os lados.
A mquina de banco de dados Teradata foi um dos primeiros sistemas comerciais a usar a arquitetura de
banco de dados com ausncia de compartilhamento.
Hierrquica
A arquitetura hierrquica combina as caractersticas das arquiteturas de compartilhamento de memria e
discos com a arquitetura sem compartilhamento. Em seu nvel mais alto, o sistema constitui-se de ns que so
conectados por uma rede sem compartilhar discos ou memria entre si. O topo de linha um sistema sem
compartilhamento. Cada n do sistema pode ser um sistema com memria compartilhada entre poucos
processadores. Alternativamente, cada n poderia ser um sistema de discos compartilhados e cada um desses
sistemas que compartilham um conjunto de discos poderia tambm compartilhar memria. Desse modo, o
sistema poderia ser construdo obedecendo a uma hierarquia, com o compartilhamento de memria por alguns
processadores na base e sem compartilhamento algum no nvel mais alto, com possivelmente uma arquitetura de
compartilhamento de discos intermediaria. A fig. 16.6d ilustra uma arquitetura hierrquica de ns com memria
compartilhada conectada por uma arquitetura com ausncia de compartilhamento. Sistemas de banco de dados
paralelos comerciais atualmente rodam em diversas dessas arquiteturas.
Tentativas para reduo da complexidade de programao desse tipo de sistema resultaram em
arquiteturas de memria virtual distribuda, nas quais h uma nica memria lgica compartilhada, mas
fisicamente h diversos sistemas de memria separados; o acoplamento de hardware com mapeamento da
memria virtual por meio de suporte extra de memria oferece uma visa nica de rea de memria virtual dessas
memrias separadas.
Sistemas Distribudos
Em um sistema de banco de dados distribudo, o banco de dados armazenado em diversos
computadores. Os computadores de um sistema de banco de dados distribudo comunica-se com outros por
126

intermdio de vrios meios de comunicaes, como redes de alta velocidade ou linhas telefnicas. Eles no
compartilha memria principal ou discos. Os computadores em um sistema de banco de dados distribudo podem
variar, quanto ao tamanho e funes, desde estacoes de trabalho at sistemas de grande porte (mainframe).
Os computadores de um sistema de banco de dados distribudo recebem diversos nomes, como sites ou
ns, dependendo do contexto no qual so inseridos. Usaremos preferencialmente o termo site (local, stio) para
enfatizar a distribuio fsica desses sistemas. A estrutura geral do sistema distribudo mostrada na fig. 16.7.
As principais diferenas entre os banco de dados paralelos sem compartilhamento e os banco de dados
distribudos so que, nos banco de dados distribudos, h a distribuio fsica geogrfica, administrao separada
e uma intercomunicao menor. Outra importante diferena que, nos sistemas distribudos, distinguimos
transaes locais de globais. Uma transao local acessa um nico site, justamente no qual ela se inicia. Uma
transao global, por outro lado, aquela que busca acesso a diferentes sites, ou a outro site alm daquele em
que se inicia.

Exemplo Ilustrativo
Considere o sistema de uma empresa da rea bancria que consiste em quatro agncias em quatro
cidades diferentes. Cada agncia possui seu prprio computador, com um banco de dados abrangendo todas as
contas referentes quela agncia.
Cada uma dessas instalaes , assim, um site. H tambm um nico site que mantem informaes sobre
todas as agncias do banco. Cada agncia mantm (entre outras) uma relao conta (Esquema_conta), em que:
Esquema_conta = (nome_agncia, nmero_conta, saldo)
O site que mantm informaes sobre as quatro agncias possui a relao agncia(Esquema_agncia), em
que:
Esquema_agncia = (nome_agncia, cidade_agncia, fundos)
H outras relaes nos diversos sites; ns a ignoramos em nosso exemplo.
Para ilustrar a diferena entre os dois tipos de transaes, consideramos a transao de adicionar 50
dlares conta A-177 localizada na agncia Valleyview. Se uma transao foi iniciada na agncia Valleyview, ela
ento considerada local; caso contrrio, ser considerada global. Uma transao para transferir 50 dlares da
conta A-177 para a conta A-305, a qual est localizada na agncia Hillside, uma transao global, uma vez que
conta em sites diferentes sofrem acessos como resultado de sua execuo.
O que faz dessa configurao um sistema de banco de dados distribudo so os seguintes aspectos:
127

Os vrios sites esto disponveis entre si.

Os sites compartilham um esquema global comum, embora algumas relaes possam estar armazenadas
em alguns sites.
Cada site proporciona um ambiente para execuo tanto de transaes locais quanto de transaes
globais.
Cada site roda o mesmo software para o gerenciamento de banco de dados.

Se houver sistemas gerenciadores de banco de dados diferentes rodando nos sites, torna-se difcil o
gerenciamento de transaes globais. Tais sistemas so chamados de sistemas de banco de dados mltiplos
(multidatabase) ou sistemas de banco de dados distribudos heterogneos.
Tradeoffs
H diversas razoes para a utilizao de sistemas de banco de dados distribudos, como o
compartilhamento de dados, a autonomia e a disponibilidade.
Compartilhamento de dados. A maior vantagem de um sistema de banco de dados distribudo criar um
ambiente no qual os usurios de um site podem ter acesso a dados residentes em outros sites. Por
exemplo, no sistema distribudo bancrio usado como exemplo, os usurios de uma agncia podem ter
acesso aos dados de outra agncia. Sem essa disponibilidade, um usurio que desejasse transferir fundos
de uma agncia para outra teria de recorrer a algum mecanismo externo.
Autonomia. A primeira vantagem do compartilhamento dos dados por meio da distribuio dos dados
que cada site pode manter certo nvel de controle sobre os dados que esto armazenados localmente. Em
sistemas centralizados, o administrado do banco de dados central quem gerencia o banco de dados. Em
sistemas de banco de dados distribudos h um administrador geral responsvel pelo banco como um
todo. Uma parte dessa responsabilidade delegada ao administrador local de cada site. Dependendo do
projeto do banco de dados distribudo, os administradores podem possuir diferentes graus de autonomia
local provavelmente uma das maiores vantagens dos banco de dados distribudos.
Disponibilidade. Se um site sai do ar em um sistema distribudo, os demais sites podem continuar em
operao. Particularmente, se os itens de dados so replicados em diversos sites, uma transao que
precise de um item de dado em particular pode encontrar tal item presente em diversos sites. Assim, a
queda de um site no implica, necessariamente, a queda do sistema.
A queda de um site precisa ser detectada pelo sistema, assim como determinadas aes devem ser
executadas para recuper-lo da falha. O sistema no poder mais usar os servios do site fora do ar. Finalmente,
quando um site volta a funcionar ou quando consertado, necessrio dispor de mecanismos para integr-lo
paulatinamente ao sistema.
Embora a recuperao de uma falha seja mais complexa nos sistemas distribudos que nos sistemas
centralizados, a capacidade da maioria dos sistemas manter-se em operao a despeito da falha de um site acaba
por aumentar a disponibilidade. A disponibilidade crucial para os sistemas de banco de dados usados em
aplicaes de tempo real. A perda do acesso aos dados em, por exemplo, uma companhia area pode fazer com
que um cliente em potencial prefira viajar com uma companhia concorrente.
A principal desvantagem dos sistemas de banco de dados distribudos o acrscimo de complexidade
necessrio para assegurar a coordenao entre os sites. Esse aumento de complexidade toma diversas formas:
Custo de desenvolvimento de software. mais difcil implementar sistemas de banco de dados
distribudos, portanto, o custo mais alto.
Maior possibilidade de bugs. Uma vez que os sites que constituem o sistema distribudo operam em
paralelo, difcil assegurar a preciso dos algoritmos, especialmente durante a ocorrncia e recuperao
de falha em parte do sistema. H, potencialmente, a chance de bugs extremamente sutis.
128

Aumento do processamento e overhead. A troca de mensagens e processamento adicional necessrios

coordenao entre sites so uma forma de overhead que no ocorre nos sistemas centralizados.

Na escolha do projeto do sistema de banco de dados, o projetista deve ponderar as vantagens e

desvantagens da distribuio dos dados. H diversas abordagens para um projeto de banco de dados distribudo,
partindo de projetos totalmente distribudos at os que mantm alto nvel de centralizao.
Tipos de Redes
Sistemas de banco de dados distribudos e sistemas cliente-servidor so apoiados em redes de
comunicao. H basicamente dois tipos de redes: redes locais (local-area networks LAN) e redes de longa
distncia (wide-area networks WAN). A principal diferena entre as duas o modo pelo qual so distribudas
geograficamente. Redes locais so compostas por processadores distribudos sobre pequenas extenses
geogrficas, como um nico edifcio ou alguns prdios prximos. Redes de longa distncia, por outro lado, so
compostas por determinado nmero de processadores autnomos, distribudos por uma extensa rea geogrfica.
Essas diferenas envolvem maiores variaes na velocidade e confiabilidade das redes de comunicao e se
refletem no projeto do sistema operacional.
Redes Locais
As redes locais (LANs) apareceram no incio dos anos 70 como meio de comunicao entre computadores
e para compartilhamento de dados. Percebeu-se que, em diversas empresas, numerosos pequenos
computadores, cada um com suas prprias aplicaes, so mais econmicos que um nico grande sistema. Como
cada pequeno equipamento provavelmente necessita de acesso a um grande nmero de dispositivos perifricos
(como discos e impressoras) e como a necessidade de alguma forma de compartilhamento de dados
frequentemente em uma empresa, a consequncia natural foi a conexo desses pequenos sistemas em uma rede
de computadores.
As LANs so normalmente projetadas para cobrir uma pequena rea geogrfica e so, geralmente, usadas
me escritrios. Todos os sites deste tipo de sistema esto prximos entre si, assim a comunicao entre eles
tende a manter velocidades mais altas e menores taxas de erro que as apresentadas pelas redes de longa
distncia. O tipo de ligao mais comum entre os computadores de uma rede local o par tranado, cabo coaxial
de banda larga e fibra tica. A velocidade de comunicao gira em torno de um megabyte por segundo, para rede
como Appletalk e IBM, redes lentas em anel (token ring), at um gigabit por segundo, para redes ticas
experimentais. Dez megabits por segundo bastante comum, essa a velocidade da Ethernet. As redes de fibra
tica FDDI (optical-fiber-based) e Fast Ethernet rodam a cem megabits por segundo. Redes com base no
protocolo chamado protocolo assncrono (asynchronous transfer mode ATM) podem alcanar velocidades
superiores, como 144 megabits por segundo, e esto se tornando bastante populares.
Uma LAN tpica consiste em diferentes estaes de trabalho, um ou mais sistemas servidores, vrios
dispositivos perifricos compartilhados (como impressora a laser ou unidades de fita magntica) e um ou mais
gateways (processadores especializados) que proporcionam acesso a outras redes (fig. 16.8). o esquema Ethernet
usado com frequncia em LANs.

129

Redes de Longa Distncia

As redes de longa distncia (WANs) apareceram no final da dcada de 1960, principalmente em projetos
de pesquisas acadmicas para comunicao eficiente entre sites, permitindo que o hardware e o software
pudessem ser compartilhados conveniente e economicamente entre a grande comunidade de usurios. Os
sistemas que permitiram a conexo de terminais remotos com um computador central via linhas telefnicas
foram desenvolvidos no incio da dcada de 1960, embora no fossem de fato uma WAN. A primeira WAN
projetada e desenvolvida foi a Arpanet. Os trabalhos na Arpanet comearam em 1968. A Arpanet desenvolveu-se
a partir de quatro redes experimentais at chegar rede mundial, a Internet, compreendendo milhes de
sistemas computacionais. A ligao caracterstica da WAN so circuitos telefnicos que usam linhas de fibra tica
e (por vezes) canais de satlite.
Como exemplo, consideremos a Internet, que conecta computadores pelo mundo. O sistema possibilita
que hosts em sites geograficamente separados comuniquem-se entre si. Os computadores hosts diferem uns dos
outros no tipo, velocidade, tamanho da palavra, sistema operacional, etc. Os hosts so, geralmente, LANs
conectadas a redes regionais. As redes regionais so interligadas a roteadores para formar a rede mundial. As
conexes entre as redes usam frequentemente o servio de telefonia chamado T1, que oferece taxas de
transferncia de cerca de 44.736 megabits por segundo. As mensagens enviadas para a rede so roteadas por
sistemas chamados de roteadores, que controlam o caminho percorrido por cada mensagem atravs da rede.
Esse roteamento pode ser dinmico, para aumentar a eficincia da comunicao, ou esttico, para reduzir riscos
ou permitir que a carga de comunicao seja processada mais facilmente.
Outras WANs em operao usam linhas telefnicas padro como principal meio de comunicao. Os
modems so dispositivos que recebem sinal digital de um computador e convertem esses dados em sinais
analgicos, que so usados pelo sistema de telefonia. Um modem no site de destino converte o sinal analgico
em digital e, assim, o equipamento de destino recebe o dado. A velocidade dos modems varia de 2400 bips a 32
kilobits por segundo. Os sistemas de telefonia que aceitam o padro Rede Digital de Servios Integrados
(Integrated Services Digital Network ISDN) permitem que os dados sejam transferidos ponto a ponto a altas
taxas, normalmente 128 kilobits por segundo.
A rede UNIX, UUCCP, permite que os sistemas se comuniquem uns com os outros um nmero limitado de
vezes (e, geralmente, predeterminado), via modems, para troca de mensagens. Essas mensagens so roteadas
para outro sistema prximo e, dessa forma, propagadas para todos os hosts da rede (mensagens publicas) ou
transferidas para seu destino (mensagens particulares).
130

As WANs so classificadas em dois tipos:

WAN conexo descontnua, como aquelas que tm por base a UUCP, em que os hosts esto conectados
rede somente por determinados perodos.
WAN conexo contnua, como a Internet, cujos hosts esto conectados rede o tempo todo.

O projeto de um sistema de banco de dados distribudo fortemente influenciado pelo tipo de WAN de
apoio. Os verdadeiros sistemas de banco de dados distribudos podem rodar apenas sobre as redes conectadas
continuamente pelo menos durante as horas em que o banco de dados distribudo est operacional.
Redes que no esto continuamente conectadas, geralmente, no permitem transaes entre sites, mas
tomam cpias locais dos dados remotos e atualizam periodicamente essas cpias (toda noite, por exemplo). Para
aplicaes cuja consistncia no seja crtica, como compartilhamento de documentos, sistemas de trabalho em
grupo (groupware systems) como o Lotus Notes, permitem atualizaes em dados remotos feitos localmente e
essas atualizaes retornam periodicamente ao site remoto. H conflito potencial de atualizaes entre sites que
precisa ser detectado e resolvido. Um mecanismo para deteces de atualizaes conflitantes existe; o
mecanismo para resoluo de conflitos de atualizao, entretanto, dependente da aplicao.
Arquitetura de sistemas de bancos de dados
INTRODUO
Agora temos condies de apresentar uma arquitetura para um sistema de bancos de dados. Nosso
objetivo ao apresentar essa arquitetura fornecer um arcabouo sobre o qual possamos desenvolver os captulos
subsequentes. Esse arcabouo til para descrever conceitos gerais de bancos de dados e explicar a estrutura de
sistemas de bancos de dados especficos mas no afirmamos que todo sistema pode se enquadrar bem nesse
arcabouo em particular, nem queremos sugerir que essa arquitetura prev o nico arcabouo possvel. Em
especial, provvel que sistemas pequenos (ver Captulo 1) no ofeream suporte para todos os aspectos da
arquitetura. Porm, a arquitetura em questo de fato parece se ajustar razoavelmente bem maior parte dos
sistemas; alm disso, ela basicamente idntica arquitetura proposta pelo ANSI/SPARC Study Group on Data
Base Management Systems (a chamada arquitetura ANSI/SPARC consulte as referncias [2.1-2.2]). Contudo,
optamos por no seguir a terminologia ANSI/SPARC em todos os detalhes.
OS TRS NVEIS DA ARQUITETURA
A arquitetura ANSI/SPARC se divide em trs nveis, conhecidos como nvel interno, nvel conceitual e nvel
externo, respectivamente (ver Figura 2.1). De modo geral:
O nvel interno (tambm conhecido como nvel fsico) o mais prximo do meio de armazenamento fsico ou
seja, aquele que se ocupa do modo como os dados so fisicamente armazenados.
O nvel externo (tambm conhecido como nvel lgico do usurio) o mais prximo dos usurios ou seja,
aquele que se ocupa do modo como os dados so vistos por usurios individuais.
O nvel conceitual (tambm conhecido como nvel lgico comunitrio, ou s vezes apenas nvel indireto, sem
qualificao) um nvel de simulao entre os outros dois.
Observe que o nvel externo se preocupa com as percepes dos usurios individuais, enquanto o nvel
conceitual est preocupado com uma percepo da comunidade de usurios. Em outras palavras, haver muitas
vises externas distintas, cada qual consistindo em uma representao mais ou menos abstrata de alguma
parte do banco de dados completo, e haver exatamente uma viso conceitual, consistindo em uma
representao analogamente abstrata do banco de dados em sua totalidade.* (Lembre-se de que a maioria dos
usurios no estar interessada em todo o banco de dados, mas somente em alguma poro restrita do banco de
dados.) Do mesmo modo, haver precisamente uma viso interna, representando o modo como o banco de
dados est fisicamente armazenado.

131

Um exemplo ajudar a esclarecer essas ideias. A Figura 2.2 mostra a viso conceitual, a viso interna
correspondente e duas vises externas correspondentes (uma para um usurio PL/I e outra para um usurio
COBOL), todas para um simples banco de dados de pessoal. claro que o exemplo inteiramente hipottico
ele no pretende se assemelhar a qualquer sistema real e muitos detalhes irrelevantes foram deliberadamente
omitidos. Explicao:
No nvel conceitual, o banco de dados contm informaes relativas a um tipo de entidade chamada
EMPREGADO. Cada empregado individual tem um NUMERO_EMPREGADO (seis caracteres), um
NUMERO_DEPARTAMENTO (quatro caracteres) e um SALARIO (cinco dgitos decimais).
No nvel interno, os empregados so representados por um tipo de registro armazenado, denominado
EMP_ARMAZENADO, com vinte bytes de comprimento. EMP_ARMAZENADO contm quatro campos
armazenados: um prefixo de seis bytes (presumivelmente contendo informaes de controle, tais como flags ou
ponteiros) e trs campos de dados correspondentes s trs propriedades de empregados. Alm disso, os registros
EMP_ARMAZENADO so indexados sobre o campo EMP# por um ndice chamado EMPX, cuja definio no
mostrada.
O usurio PL/I tem uma viso externa do banco de dados na qual cada empregado representado por um
registro PL/I que contm dois campos (nmeros de departamentos no so de interesse para esse usurio, e por
isso foram omitidos da viso). O tipo de registro definido por uma declarao de estrutura PL/I comum, de
acordo com as regras normais de PL/I.
De modo semelhante, o usurio COBOL tem uma viso externa em que cada empregado representado por um
registro COBOL contendo, mais uma vez, dois campos (agora, foram omitidos os salrios). O tipo de registro
definido por uma descrio comum de registro COBOL, de acordo com as regras normais do COBOL.

Observe que itens de dados correspondentes podem ter nomes diferentes em pontos diferentes. Por
exemplo, a referncia ao nmero do empregado chamada EMP# na viso externa de PL/I, EMPNO na viso
externa COBOL, NUMERO EMPREGADO na viso conceitual e novamente EMP# na viso interna. claro que o
sistema deve estar ciente das correspondncias; por exemplo, ele tem de ser informado de que o campo EMPNO
do COBOL derivado do campo conceitual Por abstrata, queremos dizer nesse caso apenas que a representao

132

em questo envolve construes como registros e campos, mais orientadas para o usurio, em oposio a
construes como bits e bytes, mais orientadas para a mquina.
Observe que faz pouca diferena para as finalidades deste captulo saber se o sistema que est sendo
considerado relacional ou no. Contudo, pode ser til indicar de forma resumida como os trs nveis da
arquitetura
so
em
geral
percebidos
especificamente
em
um
sistema
relacional:
Primeiro, o nvel conceitual em tal sistema ser definitivamente relacional, no sentido de que os objetos visveis
nesse nvel sero tabelas relacionais, e os operadores sero operadores relacionais (incluindo, em especial, os
operadores de restrio e projeo examinados de forma abreviada no Captulo 1).
Em segundo lugar, uma determinada viso externa tambm ser tipicamente relacional, ou algo muito prximo
disso; por exemplo, as declaraes de registros PL/I ou COBOL da Figura 2.2 podem ser consideradas de maneira
informal, respectivamente, os equivalentes PL/I ou COBOL da declarao de uma tabela relacional em um sistema
relacional.
Nota: devemos mencionar de passagem que o termo viso externa (em geral abreviado apenas como viso)
infelizmente tem um significado bastante especfico em contextos relacionais que no idntico ao significado
atribudo ao termo neste captulo. Consulte os Captulos 3 e 9 para ver uma explicao e uma descrio do
significado relacional.
Terceiro, o nvel interno no ser relacional, porque os objetos nesse nvel no sero apenas tabelas relacionais
(armazenadas) em vez disso, eles sero os mesmos tipos de objetos encontrados no nvel interno de qualquer
outra espcie de sistema (registros armazenados, ponteiros, ndices, hashing etc.). De fato, o modelo relacional
em si no tem absolutamente nenhuma relao com o nvel interno; ele se preocupa, como vimos no Captulo 1,
com o modo como o banco de dados visto pelo usurio.
Agora vamos prosseguir com o exame dos trs nveis da arquitetura com um nvel muito maior de
detalhes, comeando pelo nvel externo. Em toda a nossa descrio, faremos repetidas referncias Figura 2.3,
que mostra os principais componentes da arquitetura e seus inter-relacionamentos pelo administrador de banco
de dados (DBA) .

133

O NVEL EXTERNO
O nvel externo o nvel do usurio individual. Como foi explicado no Captulo 1, um determinado usurio
pode ser ou programador de aplicaes ou um usurio final com qualquer grau de sofisticao. (O DBA um caso
especial importante; porm, diferentemente de outros usurios, o DBA tambm precisar estar interessado nos
nveis conceitual e interno. Consulte as duas sees seguintes.)
Cada usurio tem uma linguagem sua disposio:
Para o programador de aplicaes, essa linguagem ser uma linguagem de programao convencional (como
PL/I, C+ +, Java) ou uma linguagem proprietria especfica para o sistema em questo. Essas linguagens
proprietrias so frequentemente chamadas de linguagens de quarta gerao (L4Gs), pelo fato (muito difuso!)
de que (a) o cdigo de mquina, a linguagem assembler e a linguagem PL/I podem ser consideradas como trs
geraes mais antigas de linguagens e (b) as linguagens proprietrias representam o mesmo tipo de
aperfeioamento em relao s linguagens de terceira gerao (L3Gs) que essas linguagens representavam em
relao linguagem assembler e esta ltima, por sua vez, representava em relao ao cdigo de mquina.
Para o usurio final, a linguagem ser uma linguagem de consulta ou alguma linguagem de uso especial, talvez
dirigida por formulrios ou menus, adaptada aos requisitos desse usurio e com suporte de algum programa
aplicativo on-line.
Para nossos propsitos, o ponto importante sobre todas essas linguagens que elas incluiro uma
sublinguagem de dados isto , um subconjunto da linguagem completa relacionado de modo especfico aos
objetos e s operaes do banco de dados. A sublinguagem de dados (abreviada como DSL data sublanguage
na Figura 2.3) dita embutida na linguagem hospedeira correspondente. A linguagem hospedeira
responsvel pelo fornecimento de diversos recursos no relacionados com bancos de dados, como variveis
locais, operaes de clculo, lgica de desvios condicionais (if-then-else), e assim por diante. Um dado sistema
poderia admitir qualquer nmero de linguagens hospedeira e qualquer nmero de sublinguagens de dados;
porm, uma determinada sublinguagem de dados reconhecida por quase todos os sistemas atuais a linguagem
SQL, discutida brevemente no Captulo 1. A maioria desses sistemas permite que a SQL seja usada tanto de modo
interativo como uma linguagem de consulta autnoma, quanto incorporada a outras linguagens como PL/I ou
Java
(consulte
o
Captulo
4
para
ver
detalhes
adicionais).
Observe que, embora seja conveniente para propsitos arquiteturais distinguir entre a sublinguagem de dados e
134

a linguagem hospedeira que a contm, as duas podem de fato no ser distintas para o usurio; na verdade, talvez
seja prefervel sob a perspectiva do usurio que elas no sejam distintas. Se elas no forem distintas, ou se s
puderem ser distinguidas com dificuldade, diremos que elas esto fortemente acopladas. Se forem clara e
facilmente distinguveis, dizemos que elas esto fracamente acopladas. Apesar de alguns sistemas comerciais (em
especial sistemas de objetos ver Captulo 24) admitirem o acoplamento forte, a maioria no o aceita. Em
particular, os sistemas SQL costumam oferecer suporte apenas para o acoplamento fraco. (O acoplamento forte
oferece um conjunto de recursos mais uniforme para o usurio, mas sem dvida envolve maior esforo por parte
dos desenvolvedores de sistemas, um fato que presumivelmente contribui para o status quo.)
Em princpio, qualquer sublinguagem de dados determinada , na realidade, uma combinao de pelo menos
duas linguagens subordinadas uma linguagem de definio de dados (DDL Data Definition Language), que d
suporte definio ou declarao de objetos dos bancos de dados, e uma linguagem de manipulao de dados
(DML Data Manipulation Language), que admite a manipulao ou o processamento desses objetos. Por
exemplo, considere o usurio PL/I da Figura 2.2, na Seo 2.2. A sublinguagem de dados para esse usurio
consiste
nos
recursos
de
PL/I
utilizados
para
a
comunicao
com
o
SGBD:
A parte de DDL consiste nas construes declarativas de PL/I necessrias para se declararem objetos do banco
de dados a prpria instruo DECLARE(DEL), certos tipos de dados de PL/I, possivelmente extenses especiais
de PL/I para oferecer suporte a novos objetos no manipulados pela PL/I existente.
A parte da DML consiste nas instrues executveis de PL/I que transferem informaes de e para o banco de
dados mais uma vez incluindo, possivelmente, novas instrues especiais.
Nota: mas precisamente, devemos dizer que a PL/I no inclui na realidade nenhum recurso especfico de bancos
de dados na poca em que este livro foi escrito. Em particular, as instrues de DML costumam ser apenas
instrues CALL de PL/I que invocam o SGBD (embora essas chamadas possam estar sintaticamente disfaradas
de algum modo, a fim de torn-las um pouco mais amistosas para o usurio consulte a discusso sobre a SQL
embutida no Captulo 4).
Voltando arquitetura: j indicamos que um usurio individual geralmente s estar interessado em
alguma parte do banco de dados como um todo; alm disso, a viso que esse usurio tem dessa parte ser em
geral um tanto abstrata quando comparada com o modo como os dados esto fisicamente armazenados. O termo
ANSI/SPARC para a viso de um usurio individual viso externa. Uma viso externa , portanto, o contedo do
banco de dados visto por algum usurio determinado (ou seja, para esse usurio a viso externa o banco de
dados). Por exemplo, um usurio do Departamento de Pessoal poderia considerar o banco de dados uma coleo
de ocorrncias de registros de departamentos e empregados, e ele poderia no ter nenhum conhecimento das
ocorrncias de registros de fornecedores e peas vistas pelos usurios do Departamento de Compras.
Nvel Conceitual
A viso conceitual uma representao de todo contedo de informao de informaes do banco de
dados, mais uma vez (como no caso de uma viso externa) em uma forma um tanto abstrata, em comparao
com o modo como os dados so visualizados por qualquer usurio em particular. Em termos gerais, a viso
conceitual pretende ser uma viso dos dados como eles realmente so, em vez de forar os usurios a v-los
pelas limitaes (por exemplo) da linguagem ou do hardware que eles possam estar utilizando.
A viso conceitual consiste em muitas ocorrncias de cada um dos vrios tipos de registros conceituais.
Por exemplo, ela pode consistir em uma coleo de ocorrncias de registros de departamentos, junto com uma
coleo de ocorrncias de registros de empregados, junto com uma coleo de ocorrncias de registros de
fornecedores, mais uma coleo de ocorrncias de registros de peas, e assim por diante. Um registro conceitual
no necessariamente o mesmo que um registro externo, nem o mesmo que um registro armazenado.
A viso conceitual definida por meio do esquema conceitual, que inclui definies de cada um dos vrios
tipos de registros conceituais (mais uma vez, observe um exemplo simples da fig. 2.2). o esquema conceitual
escrito por meio de outra linguagem de definio de dados, a DDL conceitual. Se quisermos alcanar a
independncia fsica dos dados, ento essas definies de DDL conceitual no devero envolver quaisquer
consideraes sobre a representao fsica ou a tcnica conceitual, no dever haver nenhuma referncia a
representaes de campos armazenados, sequencias de registros armazenados, ndices, esquemas de hashing,
ponteiros ou quaisquer outros detalhes de armazenamento e acesso. Se o esquema conceitual se tornar
verdadeiramente independente de dados dessa maneira, ento os esquemas externos, definidos em termos do
esquema conceitual, tambm so independentes dos dados.
Portanto, a viso conceitual uma viso do contedo total do banco de dados, e o esquema conceitual
uma definio dessa viso. Porm, seria enganoso sugerir que o esquema conceitual nada mais do que um
135

conjunto de definies muito semelhante s definies de registros simples, encontradas hoje em (por exemplo)
um programa COBOL. As definies no esquema conceitual tm por finalidade incluir muitos recursos adicionais,
como as restries de segurana e integridade. Algumas autoridades no assunto chegariam at a sugerir que o
objetivo final do esquema conceitual descrever a empresa inteira no apenas seus dados em si, mas tambm
o modo como esses dados so usados; como eles fluem de um ponto para outro dentro da empresa, para q eles
so usados em cada ponto, quais controles de auditoria ou outros controles devem ser aplicados em cada ponto,
e assim por diante. No entanto, devemos enfatizar que nenhum sistema atual admite realmente um esquema
conceitual q sequer se aproxime desse grau de complexidade; na maior parte dos sistemas existentes, o
esquema conceitual , na verdade, pouco mais que uma simples unio de todos os esquemas externos
individuais, juntamente com determinadas restries de segurana e integridade. Porm, sem dvida, possvel q
sistemas futuros eventualmente se tornem muito mais sofisticados em seu suporte ao nvel conceitual.
O NVEL INTERNO
O terceiro nvel da arquitetura o nvel interno. A viso interna uma representao de baixo nvel do
banco de dados por inteiro; ela consiste em muitas ocorrncias de cada um dos vrios tipos de registros internos.
Registro interno o termo ANSI/SPARC que representa a construo que temos chamado de registro
armazenado (e continuaremos a usar essa ltima forma). Assim, a viso interna ainda est muito afastada do
nvel fsico, pois ela no lida com registros fsicos tambm chamados blocos ou pginas nem com quaisquer
consideraes especficas de dispositivos, como tamanhos de cilindros ou trilhas. Em outras palavras, a viso
interna pressupe efetivamente um espao de endereos linear infinito; os detalhes de como esse espao de
endereos mapeado no meio de armazenamento fsico so bastante especficos para cada sistema e foram
deliberadamente omitidos da arquitetura geral. Nota: o bloco, ou a pgina, a unidade de entrada e sada (E/S)
isto , ele representa a quantidade de dados transferidos entre o meio de armazenamento secundrio e a
memria principal em uma nica operao de E/S. Os tamanhos de pginas tpicos so 1 K, 2 K ou 4 K bytes (K =
1.024).
A viso interna descrita por meio do esquema interno, que no somente define os diversos tipos de
registros armazenados mas tambm especifica quais ndices existem, como os campos armazenados esto
representados, em que sequncia fsica esto os registros armazenados, e assim por diante (mais uma vez, veja
na Figura 2.2 um exemplo simples). O esquema interno escrito usando-se ainda outra linguagem de definio de
dados a DDL interna. Nota: neste livro, usaremos normalmente os termos mais intuitivos estrutura de
armazenamento ou banco de dados armazenado em vez de viso interna, e ainda definio de estrutura de
armazenamento em lugar de esquema interno.
Para encerrar lembramos que, em certas situaes excepcionais, os programas aplicativos em
particular as aplicaes de natureza utilitria (ver Seo 2.11) podem ter permisso para operar diretamente
no nvel interno, e no no nvel externo. No preciso dizer que essa prtica no recomendvel; ela representa
um risco de segurana (pois as restries de segurana so ignoradas) e um risco de integridade (pois tambm as
restries de integridade so ignoradas), e o programa ter uma inicializao dependente dos dados; porm, s
vezes essa poder ser a nica maneira de obter a funcionalidade ou o desempenho exigido do mesmo modo o
usurio em uma linguagem de programao de alto nvel poderia ter a necessidade ocasional de descer at a
linguagem assembler para satisfazer certos objetivos de funcionalidade ou desempenho.

MAPEAMENTOS
Alm dos trs nveis bsicos, a arquitetura da Figura 2.3 envolve, em geral, certos mapeamentos
um mapeamento conceitual/interno e vrios mapeamentos externos/conceituais:
O mapeamento conceitual/interno define a correspondncia entre a viso conceitual e o banco de
dados armazenado; ele especifica o modo como os registros e campos conceituais so representados no
nvel interno. Se a estrutura do banco de dados armazenado for alterada isto , se for efetuada uma
mudana na definio do banco de dados armazenado o mapeamento conceitual/interno ter de ser
alterado de acordo, a fim de q o esquema conceitual possa permanecer invarivel. ( responsabilidade
do DBA, ou provavelmente, do SGBD, administrar tais alteraes.) Em outras palavras, os efeitos dessas
mudanas devem ser isolados abaixo do nvel conceitual, a fim de preservar a independncia de dados
fsica.
Definir o esquema interno
136

O DBA tambm deve decidir como sero representados os dados no banco de dados
armazenado. Em geral, esse processo chamado projeto de banco de dados fsico.* Tendo elaborado o
projeto fsico, o DBA deve ento criar a definio da estrutura de armazenamento correspondente (isto
, o esquema interno), usando a DDL interna. Alm disso, ele tambm deve definir o mapeamento
conceitual/interno associado. Na prtica, a DDL conceitual ou a DDL interna mais provavelmente a
primeira dever incluir os meios para definir esse mapeamento, mas as duas funes (criao do
esquema, definio do mapeamento) devem ser claramente distinguveis. Como no caso do esquema
conceitual, o esquema interno e o mapeamento correspondente existiro tanto na forma de fonte
quanto de objeto.
Ligao com usurios
tarefa do DBA fazer a ligao com os usurios, a fim de garantir que os dados de que eles
necessitam estaro disponveis, e escrever (ou ajudar os usurios a escreverem) os esquemas externos
necessrios, usando a DDL externa aplicvel. (Como j foi dito, um dado sistema pode admitir vrias
DDLs externas distintas.) Alm disso, os mapeamentos externos/conceituais correspondentes tambm
devem ser definidos. Na prtica, a DDL externa provavelmente incluir os meios para especificar esses
mapeamentos, mas, de novo, os esquemas e os mapeamentos devem ser claramente distinguveis. Cada
esquema externo e o mapeamento correspondente devero existir tanto na forma de fonte quanto de
objeto.
Outros aspectos da funo de ligao com o usurio incluem a consultoria em projeto de
aplicaes, o fornecimento de instruo tcnica, a assistncia para determinao e resoluo de
problemas e servios profissionais semelhantes.
Definir restries de segurana e integridade
Como j vimos, as restries de segurana e integridade podem ser consideradas uma parte do
esquema conceitual. A DDL conceitual deve incluir recursos para a especificao de tais restries.
Definir normas de descarga e recarga
Uma vez que uma empresa esteja comprometida com um sistema de banco de dados, ela se
torna dependente de modo crtico do sucesso desse sistema. Em caso de danos a qualquer parte do
banco de dados provocados por erro humano, digamos, ou por uma falha de hardware ou do sistema
operacional essencial ser capaz de reparar os dados em questo com um mnimo de demora e com
o menor efeito possvel sobre o restante do sistema. Por exemplo, em condies ideais, a
disponibilidade dos dados que no tenham sido danificados no deve ser afetada. O DBA tem de definir
e implementar um esquema apropriado de controle de danos, em geral envolvendo (a) descarga
peridica ou dumping do banco de dados para o meio de armazenamento de backup e (b)
recarregamento do banco de dados quando necessrio, a partir do dump mais recente.
A propsito, a discusso anterior fornece uma razo pela qual seria uma boa ideia espalhar a
coleo total de dados por vrios bancos de dados, em vez de manter tudo em um nico lugar; o banco
de dados individual poderia muito bem formar a unidade para finalidades de descarga e
recarregamento. Nessa linha, observe que j existem sistemas terabyte** isto , instalaes de
bancos de dados comerciais que armazenam bem mais de um trilho de bytes de dados, em termos
informais e que os sistemas do futuro devero ser muito maiores. E desnecessrio dizer que tais
sistemas VLDB (banco de dados muito grande very large database) exigem administrao muito
cuidadosa e sofisticada, em especial se houver um requisito de disponibilidade contnua (que
normalmente existe). No obstante, por simplicidade, continuaremos a falar como se de fato houvesse
um nico banco de dados.
* Observe a sequncia: primeiro, defina que dados voc deseja; depois, decida como represent-los no
meio de armazenamento.
O projeto fsico sempre deve ser feito depois do projeto lgico.
**1.o24 bytes = um kilobyte (KB); 1.024 KB = um megabyte (MB); 1.024 MB = um gigabyte (GB); 1.024
GB um terabyte (TB); 1.024 TB = um petabyte (PB); 1.024 PB = um exabyte (EB). Observe que,
informalmente, um gigabyte equivale a um bilho de bytes (a abreviatura BB empregada s vezes em
lugar de GB).
137

 Monitorar o desempenho e responder a requisitos de mudanas

Como foi indicado na Seo 1.4, o DBA responsvel pela organizao do sistema de modo a
obter o desempenho que seja o melhor para a empresa, e por fazer os ajustes apropriados isto , a
sintonia fina (tuning) conforme os requisitos se alterarem. Por exemplo, poderia ser necessrio
reorganizar o banco de dados armazenado de tempos em tempos para assegurar que os nveis de
desempenho permanecero aceitveis. Como j mencionamos, qualquer mudana no nvel de
armazenamento fsico (interno) do sistema deve ser acompanhada por uma mudana correspondente
na definio do mapeamento de nvel conceitual/interno, de modo que o esquema conceitual possa
permanecer
constante.
E claro que a lista anterior no esgota o assunto ela pretende apenas dar uma ideia da
extenso e da natureza das responsabilidades do DBA.
O SISTEMA DE GERENCIAMENTO DE BANCOS DE DADOS
O sistema de gerenciamento de bancos de dados (SGBD) o software que trata de todo o acesso
ao banco de dados. Conceitualmente, o que ocorre o seguinte (observe mais uma vez a Figura 2.3):
1. Um usurio faz um pedido de acesso usando uma determinada sublinguagem de dados (em geral,
SQL).
2. O SGBD intercepta o pedido e o analisa.
3. O SGBD inspeciona, por sua vez, o esquema externo (ou as verses objeto desse esquema) para esse
usurio, o mapeamento externo/conceitual correspondente, o esquema conceitual, o mapeamento
conceitual/interno e a definio da estrutura de armazenamento.
4. O SGBD executa as operaes necessrias sobre o banco de dados armazenado.
Como exemplo, considere as aes relacionadas com a busca de uma determinada ocorrncia de
registro externo. Em geral, sero necessrios campos de vrias ocorrncias de registros conceituais e,
por sua vez, cada ocorrncia de registro conceitual exigir campos de vrias ocorrncias de registros
armazenados. Ento, conceitualmente, o SGBD deve primeiro buscar todas as ocorrncias necessrias
de registros armazenados, depois construir as ocorrncias de registros conceituais exigidas e, em
seguida, construir a ocorrncia de registro externo. Em cada estgio, podem ser necessrias converses
de tipos de dados ou outras converses.
Naturalmente, a descrio anterior muito simplificada; em particular, ela implica que todo o
processo interpretativo, medida que sugere que os processos de anlise do pedido, inspeo dos
diversos esquemas etc., so todos realizados durante a execuo. A interpretao, por sua vez, em geral
implica um desempenho sofrvel devido sobrecarga em tempo de execuo. Porm, na prtica talvez
seja possvel fazer os pedidos de acesso serem compilados antes do momento da execuo (em
particular, diversos produtos atuais de SQL fazem isso consulte as anotaes relativas s referncias
[4.12] e [4.26] do Captulo 4).
Vamos examinar agora as funes do SGBD com um pouco mais de detalhes. Essas funes
incluiro o suporte a pelo menos todos os itens a seguir (observe a Figura 2.4):
Definio de dados
O SGBD deve ser capaz de aceitar definies de dados (esquemas externos, o esquema
conceitual, o esquema interno e todos os mapeamentos associados) em forma fonte e convert-los para
a forma objeto apropriada. Em outras palavras, o SGBD deve incluir componentes de processador de
DDL ou compilador de DDL para cada uma das diversas linguagens de definio de dados (DDLs). O SGBD
tambm deve entender as definies da DDL, no sentido de que, por exemplo, ele entende que os
registros externos EMPREGADO incluem um campo SALARIO; ele deve ento ser capaz de usar esse
conhecimento para analisar e responder a pedidos de manipulao de dados (por exemplo, obtenha
todos os empregados com salrio < R$ 50.000,00).
Manipulao de dados
O SGBD deve ser capaz de lidar com solicitaes do usurio para buscar, atualizar ou excluir
dados existentes no banco de dados, ou para acrescentar novos dados ao banco de dados. Em outras
138

palavras, o SGBD deve incluir um componente processador de DML ou compilador de DML para lidar
com a linguagem de manipulao de dados (DML data manipulation language).
Em geral, as solicitaes de DML podem ser planejadas ou no-planejadas:
a. Uma solicitao planejada aquela para a qual a necessidade foi prevista com bastante antecedncia
em relao ao momento em que a solicitao executada. O DBA provavelmente ter ajustado o
projeto de banco de dados fsico de modo a garantir um bom desempenho para solicitaes planejadas.
b. Em contraste, uma solicitao no-planejada uma consulta ad hoc, isto , uma solicitao cuja
necessidade no foi prevista com antecedncia mas, em vez disso, surgiu no ltimo instante. O projeto
de banco de dados fsico pode estar ou no adaptado de forma ideal para a solicitao especfica sendo
considerada.
Para usar a terminologia introduzida no Captulo 1 (Seo 1.3), as solicitaes planejadas so
caractersticas de aplicaes operacionais ou de produo, ao passo que as solicitaes noplanejadas so caractersticas de aplicaes para apoio deciso. Alm disso, as solicitaes
planejadas em geral sero emitidas a partir de programas aplicativos escritos previamente, enquanto as
solicitaes no-planejadas sero, por definio, emitidas de modo interativo por meio de algum
processador de linguagem de consulta. Nota: como vimos no Captulo 1, o processador de linguagem de
consulta na realidade uma aplicao on-line embutida, no uma parte do SGBD per se; ele foi includo
na Figura 2.4 por completitude.
Otimizao e execuo
As requisies de DML, planejadas ou no-planejadas, devem ser processadas pelo componente
otimizador, cujo propsito determinar um modo eficiente de implementar a requisio. A otimizao
discutida em detalhes no Captulo 17. As requisies otimizadas so ento executadas sob o controle do
gerenciador em tempo de execuo (run time). Nota: na prtica, o gerenciador em tempo de execuo
provavelmente invocar algum tipo de gerenciador de arquivos para obter acesso aos dados
armazenados. Os gerenciadores de arquivos so descritos resumidamente no final desta seo.
Segurana e integridade de dados
O SGBD deve monitorar requisies de usurios e rejeitar toda tentativa de violar as restries
de segurana e integridade definidas pelo DBA (consulte a seo anterior). Essas tarefas podem ser
executadas em tempo de compilao ou em tempo de execuo, ou ainda em alguma mistura dos dois.
Recuperao e concorrncia de dados
O SGBD ou, mais provavelmente, algum outro componente de software relacionado, cm geral
chamado gerenciador de transaes ou monitor de processamento de transaes (monitor TP) deve
impor certos controles de recuperao e concorrncia. Os detalhes desses aspectos do sistema esto
alm do escopo deste captulo; consulte a Parte IV deste livro, que contm uma descrio em
profundidade do assunto. Nota: o gerenciador de transaes no mostrado na Figura 2.4 porque, em
geral, ele no faz parte do SGBD propriamente dito.
Dicionrio de dados
O SGBD deve fornecer uma funo de dicionrio de dados. O dicionrio de dados pode ser
considerado um banco de dados em si (mas um banco de dados do sistema, no um banco de dados
impem restries - de segurana e integridade do usurio), O dicionrio contm dados sobre os
dados (s vezes chamados metadados ou descritores) ou seja, definies de outros objetos do
sistema, em vez de dados brutos somente. Em particular, todos os vrios esquemas e mapeamentos
(externos, conceituais etc.) e todas as diversas restries de segurana e integridade estaro
armazenados, tanto na forma de fonte quanto de objeto, no dicionrio. Um dicionrio completo
tambm incluir muitas informaes adicionais mostrando, por exemplo, os programas que utilizam
determinadas partes do banco de dados, os usurios que exigem certos relatrios, os terminais
conectados ao sistema, e assim por diante. O dicionrio poderia at estar na verdade, provavelmente
deve estar integrado ao banco de dados que define e, portanto, incluir sua prpria definio. Por
certo, deve haver a opo de consultar o dicionrio como qualquer outro banco de dados para que, por
exemplo, seja possvel saber que programas e/ou usurios tero maior probabilidade de serem afetados
139

por alguma alterao proposta no sistema. Consulte o Captulo 3 para ver uma discusso adicional sobre
o assunto.
Nota: estamos entrando agora em uma rea sobre a qual existe muita confuso de terminologia.
Algumas pessoas fariam referncia ao que estamos chamando de dicionrio como um diretrio ou
catlogo, o que implica que diretrios ou catlogos so de algum modo inferiores a um verdadeiro
dicionrio e reservariam o termo dicionrio para designar uma variedade especfica (importante) de
ferramenta para desenvolvimento de aplicaes. Outros termos que tambm so algumas vezes
empregados para designar essa ltima variedade de objetos so repositrio de dados (ver Captulo 13) e
enciclopdia de dados.

desnecessrio dizer que o SGBD deve realizar todas as funes identificadas anteriormente de forma
to eficiente quanto possvel.
Podemos resumir tudo o que foi mencionado antes afirmando que a funo geral do SGBD fornecer a
interface do usurio para o sistema de banco de dados. A interface do usurio pode ser definida como a fronteira
no sistema abaixo da qual tudo invisvel para o usurio. Por definio, portanto, a interface do usurio est no
nvel externo. Contudo, como veremos no Captulo 9, h algumas situaes em que improvvel que a viso
externa seja significativamente diferente da poro relevante da viso conceitual subjacente, pelo menos nos
produtos SQL comerciais de hoje.
Conclumos esta seo com uma breve comparao entre os sistemas de gerenciamento de bancos de
dados discutidos anteriormente e os sistemas de gerenciamento de arquivos (gerenciadores de arquivos ou
servidores de arquivos). Em linhas gerais, o gerenciador de arquivos o componente do sistema operacional
bsico que administra arquivos armazenados; portanto, em termos informais, ele est mais prximo ao disco
que o SGBD. (Na verdade, o SGBD costuma ser montado sobre algum tipo de gerenciador de arquivos.) Desse
140

modo, o usurio de um sistema de gerenciamento de arquivos ser capaz de criar e destruir arquivos
armazenados e de executar operaes simples de busca e atualizao sobre registros armazenados em tais
arquivos. No entanto, em contraste com o SGBD:
Os gerenciadores de arquivos no tm conhecimento da estrutura interna dos registros armazenados e, por
isso, no podem lidar com requisies que dependam de um conhecimento dessa estrutura.
Em geral, eles fornecem pouco ou nenhum suporte para restries de segurana e integridade.
Em geral, eles fornecem pouco ou nenhum suporte para controles de recuperao e concorrncia.
No h verdadeiramente um conceito de dicionrio de dados no nvel do gerenciador de arquivos.
Eles proporcionam muito menos independncia de dados que o SGBD.
Em geral, os arquivos no esto integrados ou compartilhados no mesmo sentido que o banco de dados
(normalmente, eles so privativos de algum usurio ou alguma aplicao em particular).
O GERENCIADOR DE COMUNICAES DE DADOS
Nesta seo, consideraremos resumidamente o tpico de comunicaes de dados. As requisies a
bancos de dados de um usurio final so, na verdade, transmitidas da estao de trabalho do usurio que pode
estar fisicamente afastada do prprio sistema de banco de dados para alguma aplicao on-line (embutida ou
no), e da at o SGBD, sob a forma de mensagens de comunicao. De modo semelhante, as respostas do SGBD e
da aplicao on-line para a estao de trabalho do usurio tambm so transmitidas sob a forma de mensagens.
Todas essas transmisses de mensagens tm lugar sob o controle de outro componente de software, o
gerenciador de comunicaes de dados (gerenciador DE data communications).
O gerenciador DE no faz parte do SGBD, mas um sistema autnomo. Porm, como o gerenciador DE e
o SGBD so claramente obrigados a trabalhar em harmonia, s vezes os dois so considerados parceiros de igual
nvel em um empreendimento cooperativo de nvel mais alto, denominado sistema de banco de
dados/comunicaes de dados (sistema DB/DE), no qual o SGBD toma conta do banco de dados e o gerenciador
DE manipula todas as mensagens de e para o SGBD ou, mais precisamente, de e para aplicaes que utilizam o
SGBD. Porm, neste livro, teremos pouco a dizer sobre o manejo de mensagens como essas (o que, por si s,
um assunto extenso). A Seo 2.12 descreve resumidamente a questo das comunicaes entre sistemas distintos
(ou seja, entre mquinas diferentes em uma rede de comunicaes, como a Internet), mas esse , na realidade,
um tpico parte.
ARQUITETURA CLIENTE/SERVIDOR
Descrevemos at agora neste captulo os sistemas de bancos de dados sob o ponto de vista da chamada
arquitetura ANSI/SPARC. Em particular, a Figura 2.3 forneceu uma representao simplificada dessa arquitetura.
Nesta seo, examinaremos os sistemas de bancos de dados sob uma perspectiva um pouco diferente.
Naturalmente, o objetivo geral desses sistemas fornecer suporte ao desenvolvimento e execuo de
aplicaes de bancos de dados. Portanto, sob um ponto de vista de mais alto nvel, um sistema de banco de
dados pode ser considerado como tendo uma estrutura muito simples em duas partes, consistindo em um
servidor (tambm chamado back end) e um conjunto de clientes (tambm chamados front ends). Consulte a
Figura 2.5. Explicao:
O servidor o prprio SGBD. Ele admite todas as funes bsicas de SGBDs discutidas na Seo 2.8 definio
de dados, manipulao de dados, segurana e integridade de dados, e assim por diante. Em particular, ele oferece
todo o suporte de nvel externo, conceitual e interno que examinamos nas Sees 2.3 a 2.6. Assim, o termo
servidor neste contexto to-somente um outro nome para o SGBD.
Os clientes so as diversas aplicaes executadas sobre o SGBD tanto aplicaes escritas por usurios quanto
aplicaes internas, ou seja, aplicaes fornecidas pelo fabricante do SGBD ou por produtores independentes. No
que se refere ao servidor, claro que no existe nenhuma diferena entre aplicaes escritas pelo usurio e
aplicaes internas todas elas empregam a mesma interface para o servidor, especificamente a interface de
nvel externo discutida na Seo 2.3.

141

Nota: certas aplicaes especiais chamadas utilitrios poderiam constituir uma exceo ao que vimos antes,
pois s vezes elas podem precisar operar diretamente no nvel interno do sistema (conforme mencionamos na
Seo 2.5). Esses utilitrios devem ser considerados componentes integrais do SGBD, em vez de aplicaes no
sentido usual. Os utilitrios sero discutidos com mais detalhes na prxima seo.
Vamos aprofundar o exame da questo de aplicaes escritas pelo usurio versus aplicaes fornecidas
pelo
fabricante:
Aplicaes escritas pelo usurio so basicamente programas aplicativos comuns, escritos (em geral) em uma
linguagem de programao convencional de terceira gerao (L3G), como C ou COBOL, ou ento em alguma
linguagem proprietria de quarta gerao (L4G) embora em ambos os casos a linguagem precise ser de algum
modo acoplada a uma sublinguagem de dados apropriada, conforme explicamos na Seo 2.3.
Banco de dados
Aplicaes fornecidas por fabricante (chamadas frequentemente de ferramentas tools) so aplicaes cuja
finalidade bsica auxiliar na criao e execuo de outras aplicaes! As aplicaes criadas so aplicaes
adaptadas a alguma tarefa especfica (elas podem no ser muito semelhantes s aplicaes no sentido
convencional; de fato, a finalidade das ferramentas permitir aos usurios, em especial aos usurios finais, criar
aplicaes sem ter de escrever programas em uma linguagem de programao convencional). Por exemplo, uma
das ferramentas fornecidas pelo fabricante ser um gerador de relatrios, cuja finalidade permitir que os
usurios finais obtenham relatrios formatados a partir do sistema sob solicitao. Qualquer solicitao de
relatrio pode ser considerada um pequeno programa aplicativo, escrito em uma linguagem de gerao de
relatrios
de
nvel
muito
alto
(e
finalidade
especial).
As ferramentas fornecidas pelo fabricante podem ser divididas em diversas classes mais ou menos
distintas:
a. Processadores de linguagem de consulta.
b. Geradores de relatrios.
c. Subsistemas grficos de negcios.
d. Planilhas eletrnicas.
e. Processadores de linguagem natural.
f. Pacotes estatsticos.
g. Ferramentas para gerenciamento de cpias ou extrao de dados.
h. Geradores de aplicaes (inclusive processadores L4G).
i. Outras ferramentas para desenvolvimento de aplicaes, inclusive produtos de engenharia de software
auxiliada pelo computador (CASE computer-aided software engineering).
Os detalhes dessas ferramentas e de vrias outras esto alm do escopo deste livro; entretanto,
observamos que, tendo em vista que (como foi dito antes) toda a importncia de um sistema de banco de dados
est em dar suporte criao e execuo de aplicaes, a qualidade das ferramentas disponveis , ou deve ser,
um fator preponderante na deciso sobre o banco de dados (isto , o processo de escolha do produto de banco
de dados apropriado). Em outras palavras, o SGBD em si no o nico fator que precisa ser levado em
considerao,
nem
mesmo

necessariamente
o
fator
mais
significativo.
Encerramos esta seo com uma referncia para o que se segue. Como o sistema por completo pode
estar to claramente dividido em duas partes, servidores e clientes, surge a possibilidade de executar os dois em
142

mquinas diferentes. Em outras palavras, existe o potencial para o processamento distribudo. O processamento
distribudo significa que mquinas diferentes podem estar conectadas entre si para formar algum tipo de rede de
comunicaes, de tal modo que uma nica tarefa de processamento de dados possa ser dividida entre vrias
mquinas na rede. Na verdade, essa possibilidade to atraente por urna variedade de razes, principalmente
de ordem econmica que o termo cliente/servidor passou a se aplicar a quase exclusivamente ao caso em
que o cliente e o servidor esto de fato localizados em mquinas diferentes. Examinaremos o processamento
distribudo com mais detalhes na Seo 2.12.
UTILITRIOS
Utilitrios so programas projetados para auxiliar o DBA com diversas tarefas administrativas. Como
mencionamos na seo anterior, alguns programas utilitrios operam no nvel externo do sistema e, portanto, so
na verdade apenas aplicaes de uso especial; alguns podem nem mesmo ser fornecidos pelo fabricante do
SGBD, mas sim por algum fabricante independente. Porm, outros utilitrios operam diretamente no nvel
interno (em outras palavras, eles realmente fazem parte do servidor) e, desse modo, devem ser oferecidos pelo
fornecedor do SGBD.
Aqui esto alguns exemplos dos tipos de utilitrios que costumam ser necessrios na prtica:
Rotinas de carga, a fim de criar a verso inicial do banco de dados a partir de um ou mais arquivos do sistema
operacional.
Rotinas de descarregamento/recarregamento, a fim de descarregar o banco de dados, ou partes dele, para o
meio de armazenamento de backup e recarregar dados dessas cpias de backup ( claro que o utilitrio de
recarregamento basicamente idntico ao utilitrio de carga que acabamos de mencionar).
Rotinas de reorganizao, a fim de rearranjar os dados no banco de dados armazenado por vrias razes (em
geral, relacionadas com o desempenho) por exemplo, para agrupar dados de algum modo particular no disco,
ou para reaver o espao ocupado por dados que se tornaram obsoletos.
Rotinas estatsticas, a fim de calcular diversas estatsticas de desempenho, tais como tamanhos de arquivos e
distribuio de valores de dados ou contagens de E/S etc.
Rotinas de anlise, a fim de analisar as estatsticas mencionadas antes. A lista precedente representa apenas
uma pequena amostra das funes em geral oferecidas pelos utilitrios; existe uma srie de outras possibilidades.

PROCESSAMENTO DISTRIBUDO
Repetindo o que mencionamos na Seo 2.10, a expresso processamento distribudo significa que
mquinas diferentes podem estar conectadas entre si em uma rede de comunicaes como a Internet, de tal
modo que uma nica tarefa de processamento de dados possa se estender a vrias mquinas na rede. (A
expresso processamento paralelo tambm utilizada algumas vezes com significado quase idntico, exceto
pelo fato de que as diferentes mquinas tendem a manter uma certa proximidade fsica em um sistema
paralelo e no precisam estar to prximas em um sistema distribudo por exemplo, elas poderiam estar
geograficamente dispersas no ltimo caso.) A comunicao entre as vrias mquinas efetuada por algum tipo
de software de gerenciamento de rede possivelmente uma extenso do gerenciador DE discutido na Seo 2.9
ou, com maior probabilidade, um componente de software separado.
So possveis muitos nveis ou variedades de processamento distribudo. Conforme mencionamos na
Seo 2.10, um caso simples envolve a execuo do back end do SGBD (o servidor) em uma das mquinas e dos
front ends da aplicao (os clientes) em outra. Ver Figura 2.6.
Como vimos no final da Seo 2.10, o termo cliente/servidor, embora seja estritamente uma expresso
relacionada com a arquitetura, passou a ser quase um sinnimo da disposio ilustrada na Figura 2.6, na qual o
cliente e o servidor funcionam em mquinas diferentes. De fato, h muitos argumentos em favor de um esquema
desse tipo:
O primeiro basicamente o argumento usual sobre o processamento paralelo: especificamente, muitas
unidades de processamento esto sendo agora aplicadas na tarefa global, enquanto o processamento do servidor
(o banco de dados) e o processamento do cliente (a aplicao) esto sendo feitos em paralelo. O tempo de
resposta e a vazo (throughput) devem assim ser melhorados.
Alm disso, a mquina servidora pode ser uma mquina feita por encomenda para se ajustar funo de SGBD
(uma mquina de banco de dados) e pode assim fornecer melhor desempenho de SGBD.

143

 Do mesmo modo, a mquina cliente poderia ser uma estao de trabalho pessoal, adaptada s necessidades do
usurio final e, portanto, capaz de oferecer interfaces melhores, alta disponibilidade, respostas mais rpidas e, de
modo geral, maior facilidade de utilizao para o usurio.

Vrias mquinas clientes distintas poderiam ser capazes (na verdade, normalmente sero capazes) de obter
acesso mesma mquina servidora. Assim, um nico banco de dados poderia ser compartilhado entre vrios
sistemas clientes distintos (ver Figura 2.7).
Alm dos argumentos anteriores, existe tambm o fato de que a execuo do(s) cliente(s) e do servidor
em mquinas diferentes combina com a maneira como as empresas operam na realidade. E bastante comum que
uma nica empresa um banco, por exemplo opere muitos computadores, de tal modo que os dados
correspondentes a uma parte da empresa sejam armazenados em um computador e os dados de outra parte
sejam armazenados em outro computador. Prosseguindo com o exemplo do banco, muito provvel que os
usurios de uma agncia precisem ocasionalmente obter acesso a dados armazenados em outra agncia.
Portanto, observe que as mquinas clientes poderiam ter seus prprios dados armazenados, e a mquina
servidora poderia ter suas prprias aplicaes. Dessa forma, em geral caia maquina atuar como um servidor para
alguns usurios e como cliente para outros (ver Figura 2.8); em outras palavras, cada mquina admitir um
sistema de banco de dados por inteiro, no sentido estudado em sees anteriores deste captulo.
O ltimo ponto a mencionar que uma nica mquina cliente poderia ser capaz de obter acesso a vrias
mquinas servidoras diferentes (a recproca do caso ilustrado na Figura 2.7). Esse recurso desejvel porque,
como mencionamos antes, as empresas em geral operam de tal maneira que a totalidade de seus dados no fica
armazenada em uma nica mquina, mas se espalha por muitas mquinas diferentes, e as aplicaes s vezes
precisaro ter a capacidade de conseguir acesso a dados de mais de uma mquina. Basicamente, esse acesso
pode ser fornecido de dois modos distintos:
Um dado cliente pode ser capaz de obter acesso a qualquer nmero de servidores, mas somente um de cada
vez (ou seja, cada requisio individual ao banco de dados tem de ser direcionada para apenas um servidor). Em
um sistema desse tipo no possvel, dentro de uma nica requisio, combinar dados de dois ou mais servidores
diferentes. Alm disso, o usurio de tal sistema tem de saber qual mquina em particular contm cada um dos
fragmentos de dados.
O cliente pode ser capaz de obter acesso a muitos servidores simultaneamente (isto , uma nica solicitao ao
banco de dados poderia ter a possibilidade de combinar dados de vrios servidores). Nesse caso, os servidores
aparentam para o cliente de um ponto de vista lgico ser realmente um nico servidor, e o usurio no
precisa saber qual mquina contm cada um dos itens de dados.

144

Esse ltimo caso constitui um exemplo daquilo que se costuma chamar sistema de banco de dados
distribudo, O tema de bancos de dados distribudos um grande tpico por si s; levado a sua concluso lgica, o
suporte completo a bancos de dados distribudos implica que uma nica aplicao deve ser capaz de operar de
modo transparente sobre dados espalhados por uma variedade de bancos de dados diferentes, gerenciados por
uma variedade de SGBDs diferentes, funcionando em uma variedade de mquinas distintas, com suporte de uma
variedade de sistemas operacionais diferentes e conectados entre si por meio de uma variedade de redes de
comunicaes diferentes onde de modo transparente significa que a aplicao opera, de um ponto de vista
lgico, como se os dados fossem todos gerenciados por um nico SGBD funcionando em uma nica mquina. Esse
recurso pode parecer algo muito difcil de conseguir, mas altamente desejvel de uma perspectiva prtica, e os
fabricantes esto trabalhando arduamente para tornar realidade esses sistemas. Discutiremos em detalhes os
sistemas de bancos de dados distribudos no Captulo 20.

145

Normalizao
O conceito de normalizao foi introduzido por E. F. Codd em 1970 (primeira forma normal). Esta tcnica
um projeto matemtico formal, que tem seus fundamentos na teoria dos conjuntos.
Atravs deste processo pode-se, gradativamente, substituir um conjunto de entidades e relacionamentos
por um outro, o qual se apresenta purificado em relao s anomalias de atualizao (incluso, alterao e
excluso) as quais podem causar certos problemas, tais como: grupos repetitivos (atributos multivalorados) de
dados, dependncias parciais em relao a uma chave concatenada, redundncia de dados desnecessrios,
perdas acidentais de informao, dificuldade na representao de fatos da realidade observada e dependncias
transitivas entre atributos.
Os conceitos abordados podem ser aplicados s duas formas de utilizao da normalizao:
- sentido de cima para baixo (TOP-DOWN):
Aps a definio de um modelo de dados, aplica-se a normalizao para se obter uma sntese dos dados,
bem como uma decomposio das entidades e relacionamentos em elementos mais estveis, tendo em vista sua
implementao fsica em um banco de dados;
- sentido de baixo para cima (BOTTON-UP):
Aplicar a normalizao como ferramenta de projeto do modelo de dados, usando os relatrios,
formulrios e documentos utilizados pela realidade em estudo, constituindo-se em uma ferramenta de
levantamento.
Anomalias de Atualizao
Observando-se o formulrio de PEDIDO apresentado na fig. 12.1, podemos considerar que uma entidade
formada com os dados presentes ter a seguinte apresentao:
Atributos da entidade PEDIDO:
o nmero do pedido
o prazo de entrega
o cliente
o endereo
o cidade
o UF
o CGC
o inscrio estadual
o cdigo do produto (*)
o unidade do produto (*)
o quantidade do produto (*)
o descrio do produto (*)
o valor unitrio do produto (*)
o valor total do produto (*)
o valor total do pedido (*)
o cdigo do vendedor
o nome do vendedor
(*) Atributos que se repetem no documento

146

Caso a entidade fosse implementada como uma tabela em um banco de dados, as seguintes anomalias
iriam aparecer:
anomalia de incluso: ao ser includo um novo cliente, o mesmo tem que estar relacionado a uma venda;
anomalia de excluso: ao ser excludo um cliente, os dados referentes as suas compras sero perdidos;
anomalia de alterao: caso algum fabricante de produto altere a faixa de preo de uma determinada
classe de produtos, ser preciso percorrer toda a entidade para se realizar mltiplas alteraes.
Primeira forma normal (1FN)
Em uma determinada realidade, s vezes encontramos algumas informaes que se repetem (atributos
multivalorados), retratando ocorrncias de um mesmo fato dentro de uma nica linha e vinculadas a sua chave
primria.
Ao observarmos a entidade PEDIDO, apresentada acima, visualizamos um certo grupo de atributos
(produtos solicitados) se repete (nmero de ocorrncias no definidas) ao longo do processo de entrada de dados
na entidade.
A 1FN diz que: cada ocorrncia da chave primria deve corresponder a uma e somente uma informao
de cada atributo, ou seja, a entidade no deve conter grupos repetitivos (multivalorados).

147

Para se obter entidades na 1FN, necessrio decompor cada entidade no normalizada em tantas
entidades quanto for o nmero de conjuntos de atributos repetitivos. Nas novas entidades criadas, a chave
primria a concatenao da chave primria da entidade original mais o(s) atributo(s) do grupo repetitivo
visualizado(s) como chave primria desse grupo.
Para a entidade PEDIDO, temos:
Entidade no normalizada:

Ao aplicarmos a 1FN sobre a entidade PEDIDO, obtemos mais uma entidade chamada de ITEM-DEPEDIDO, que herdar os atributos repetitivos e destacados da entidade PEDIDO.

148

Um PEDIDO possui no mnimo 1 e no mximo N elementos de ITEM-DE-PEDIDO e um ITEM-DE-PEDIDO

pertence a 1 e somente 1 PEDIDO, logo o relacionamento POSSUI do tipo 1:N.
Variao Temporal e a Necessidade de Histrico
Observamos que normalmente, ao se definir um ambiente de armazenamento de dados, seja ele um
banco de dados ou no, geralmente se mantm a ltima informao cadastrada, que s vezes, por sua prpria
natureza, possui um histrico de ocorrncias. Mas como a atualizao sempre feita sobre esta ltima
informao, perdem-se totalmente os dados passados.
A no-observao deste fato leva a um problema na hora de uma auditoria de sistemas, que em vez de
utilizar uma pesquisa automatizada sobre os histricos, se v obrigada a uma caada manual cansativa sobre um
mar imenso de papeis e relatrios, e que na maioria das vezes se apresenta incompleta ou inconsistente devido a
valores perdidos (documentos extraviados) ou no documentados.
Com a no-utilizao de histricos e a natural perda destas informaes, a tomada de decises por parte
da alta administrao de uma empresa pode levar a resultados catastrficos para a corporao.
Toda vez que a deciso de armazenar o histrico de algum atributo for tomada, cria-se explicitamente um
relacionamento de um para muitos (1-N), entre a entidade que contm o atributo e a entidade criada para conter
o histrico deste atributo. Passa a existir ento uma entidade dependente, contendo (no mnimo) toda data em
que houve alguma alterao do atributo bem como o respectivo valor do atributo para cada alterao. A chave
desta entidade de histrico ser concatenada, e um de seus atributos ser a data de referncia.
149

Com base nesta necessidade de armazenamento de histricos, aps a aplicao da 1FN devemos observar
para cada entidade definida, quais de seus atributos se transformaro com o tempo, se preciso armazenar
dados histricos deste atributo e em caso afirmativo, observar o perodo de tempo que devemos conservar este
histrico, ou atravs de quantas alteraes foram realizadas neste atributo.
Dependncia Funcional
Para descrevermos as prximas formas normais, se faz necessria a introduo do conceito de
dependncia funcional, sobre o qual a maior parte da teoria de normalizao foi baseada.
Dada uma entidade qualquer, dizemos que um atributo ou conjunto de atributos A dependente
funcional de um outro atributo B contido na mesma entidade, se a cada valor de B existir nas linhas da entidade
em que aparece, um nico valor de A. Em outras palavras, A depende funcionalmente de B.
Ex.: Na entidade PEDIDO, o atributo PRAZO-DE-ENTREGA depende funcionalmente de NMERO-DOPEDIDO.
O exame das relaes existentes entre os atributos de uma entidade deve ser feito a partir do
conhecimento (conceitual) que se tem sobre a realidade a ser modelada.
Dependncia Funcional Total (Completa) e Parcial
Na ocorrncia de uma chave primria concatenada, dizemos que um atributo ou conjunto de atributos
depende de forma completa ou total desta chave primria concatenada, se e somente se, a cada valor da chave (e
no parte dela), est associado um valor para cada atributo, ou seja, um atributo no (dependncia parcial) se
apresenta com dependncia completa ou total quando s dependente de parte da chave primria concatenada e
no dela como um todo.
Ex.: dependncia total na entidade ITEM-DO-PEDIDO, o atributo QUANTIDADE-DO-PRODUTO depende
de forma total ou completa da chave primria concatenada (NMERO-DO-PEDIDO+CODIGO-DO-PRODUTO).
A dependncia total ou completa s ocorre quando a chave primria for composta por vrios
(concatenados) atributos, ou seja, em uma entidade chave primria composta de um nico atributo no ocorre
este tipo de dependncia.
Dependncia Funcional Transitiva
Quando um atributo ou conjunto de atributos A depende de outro atributo B que no pertence chave
primria, mas dependente funcional desta, dizemos que A dependente transitivo de B.
Ex.: dependncia transitiva na entidade PEDIDO, os atributos ENDEREO, CIDADE, UF, CGC e INSCRIOESTATUAL so dependentes transitivos do atributo CLIENTE. Nesta mesma entidade, o atributo NOME-DOVENDEDOR dependente transitivo do atributo CODIGO-DO-VENDEDOR.
Com base na teoria sobre as dependncias funcionais entre atributos de uma entidade, podemos
continuar com a apresentao das outras formas normais.
Segunda Forma Normal (2FN)
Devemos observar se alguma entidade possui chave primria concatenada, e para aqueles que
satisfizerem esta condio, analisar se existe algum atributo ou conjunto de atributos que dependem desta chave
parcial, ou seja, uma entidade para estar na 2FN no pode ter atributos com dependncia parcial em relao
chave primria.
Ex.: A entidade ITEM-DO-PEDIDO apresenta uma chave primria concatenada e por observao, notamos
que os atributos UNIDADE-DO-PRODUTO, DESCRIO-DO-PRODUTO e VALOR-UNITARIO depende de forma
parcial do atributo CODIGO-DO-PRODUTO, que faz parte da chave primria. Logo devemos aplicar a 2FN sobre
esta entidade. Quando aplicamos a 2FN sobre ITEM-DO-PEDIDO, ser criada a entidade PRODUTO que herdar os
atributos UNIDADE-DO-PRODUTO, DESCRIO-DO-PRODUTO e VALOR-UNITRIO e ter como chave primria o
CODIGO-DO-PRODUTO.
150

Um PRODUTO participa de no mnimo 1 e no mximo N elementos de ITEM-DE-PEDIDO e um ITEM-DEPRODUTO s pode conter 1 e somente 1 PRODUTO. Logo, o novo relacionamento criado do tipo N:1.
Terceira Forma Normal (3FN)
Uma entidade est na 3FN se nenhum de seus atributos possui dependncia transitiva em relao a outro
atributo da entidade que no participe da chave primria, ou seja, no exista nenhum atributo intermedirio
entre a chave primria e o prprio atributo observado.
Terceira Forma Normal (3FN)
Uma entidade est na 3FN se nenhum de seus atributos possui dependncia transitiva em relao a outro
atributo da entidade que no participe da chave primria, ou seja, no exista nenhum atributo intermedirio
entre a chave primria e o prprio atributo observado.

151

Ao retirarmos a dependncia transitiva, devemos criar uma nova entidade que contenha os atributos que
contenha os atributos que dependem transitivamente de outro e sua chave primria o atributo que causou esta
dependncia.
Alm de no conter atributos com dependncia transitiva, entidades na 3FN no devem conter atributos
que sejam o resultado de algum clculo sobre outro atributo, que de certa forma pode ser encarada como uma
dependncia funcional.
Ex.: Na entidade PEDIDO, podemos observar que o atributo NOME-DO-VENDEDOR depende
transitivamente do atributo CODIGO-DO-VENDEDOR que no pertence chave primria. Para eliminarmos esta
anomalia devemos criar a entidade VENDEDOR, com o atributo NOME-DO-VENDEDOR e tendo como chave
primria o atributo CODIGO-DO-VENDEDOR.
Encontramos ainda o conjunto de atributos formados por ENDEREO, CIDADE, UF, CGC e INSCRIOESTADUAL que dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a entidade
VENDEDOR, com o atributo NOME-DO-VENDEDOR e tendo como chave primria o atributo CODIGO-DOVENDEDOR.
Encontramos ainda o conjunto de atributos formados por ENDEREO, CIDADE, UF, CGC e INSCRIOESTADUAL que dependem transitivamente do atributo CLIENTE. Neste caso, devemos criar a entidade CLIENTE
que conter os atributos ENDEREO, CIDADE, UF, CGC e INSCRIO-ESTADUAL. Para chave primria desta
entidade vamos criar um atributo chamado CODIGO-DO-CLIENTE que funcionar melhor como chave primria do
que NOME-DO-CLIENTE, deixa este ltimo como simples atributo da entidade CLIENTE.

152

Um PEDIDO s feito por um e somente um CLIENTE e um CLIENTE pode fazer de zero (clientes que
devem ser contatados mais frequentemente pelos vendedores) at N elementos de PEDIDO. Um PEDIDO s
tirado por um e somente um VENDEDOR e um VENDEDOR pode tirar de zero (vendedores que devem ser
reciclados em termos de treinamento, para aumentar o poder de venda) a N elementos de PEDIDO.
Forma Normal de BOYCE/CODD (FNBC)
As definies da 2FN e 3FN, desenvolvidas por Codd, no cobriam certos casos. Esta inadequao foi
apontada por Raymond Boyce em 1974. Os casos no cobertos pelas definies de Codd somente ocorrem
quando trs condies aparecem juntas:
a entidade tenha vrias chaves candidatas;
estas chaves candidatas sejam concatenadas (mais de um atributo);
as chaves concatenadas compartilham pelo menos um atributo comum.
Na verdade, a FNBC uma extenso da 3FN, que no resolvia certas anomalias presentes na informao contida
em uma entidade. O problema foi observado porque a 2FN e a 3FN s tratavam dos casos de dependncia parcial
e transitiva de atributos fora de qualquer chave, porm quando o atributo observado estiver contido em uma
chave (primria ou candidata), ele no captado pelo verificao da 2FN e 3FN.
A definio da FNBC a seguinte: uma entidade est na FNBC se e somente se todos os determinantes
forem chaves candidatas. Notem que esta definio em termos de chaves candidatas e no sobre chaves
primrias.
Considere a seguinte entidade FILHO:

153

Por hiptese, vamos assumir que um professor possa estar associado a mais de uma escola e uma sala.
Sob esta suposio, tanto a chave (candidata) concatenada NOME-DA-ESCOLA+SALA-DA-ESCOLA bem como
NOME-DA-ESCOLA+NOME-DO-PROFESSOR podem ser determinantes. Logo esta entidade atende s trs
condies relacionadas anteriormente:
as chaves candidatas para a entidade FILHO so: NOME-DO-FILHO+ENDEREO-DO-FILHO+NMERO-DASALA e NOME-DO-FILHO+NOME-DO-PROFESSOR;
todas as trs chaves apresentam mais de um atributo (concatenados);
todas as trs chaves compartilham um mesmo atributo: NOME-DO-FILHO.
Neste exemplo, NOME-DO-PROFESSOR no completamente dependente funcional do NMERO-DASALA, nem NMERO-DA-SALA completamente dependente funcional do NOME-DO-PROFESSOR. Neste caso,
NOME-DO-PROFESSOR realmente completamente dependente funcional da chave candidata concatenada
NOME-DO-FILHO+NOME-DO-PROFESSOR.
Ao se aplicar FNBC, a entidade FILHO deve ser dividida em duas entidades, uma que contm todos os
atributos que descrevem o FILHO, e uma segunda que contm os atributos que designam um professor em uma
particular escola e nmero de sala.

Quarta Forma Normal (4FN)

Na grande maioria dos casos, as entidades normalizadas at a 3FN so fceis de entender, atualizar e de
se recuperar dados. Mas s vezes podem surgir problemas com relao a algum atributo no chave, que recebe
valores mltiplos para um mesmo valor de chave. Esta nova dependncia recebe o nome de dependncia
multivalorada que existe somente se a entidade contiver no mnimo trs atributos.
Uma entidade que esteja na 3FN tambm est na 4FN, se ela no contiver mais do que um fato
multivalorado a respeito da entidade descrita. Esta dependncia no o mesmo que uma associao M:N entre
atributos, geralmente descrita desta forma em algumas literaturas.
154

Ex.: Dada a entidade hipottica a seguir:

Como podemos observar, esta entidade tenta conter dois fatos multivalorados: as diversas peas
compradas e os diversos compradores. Com isso apresenta uma dependncia multivalorada entre CODIGOFORNECEDOR e o CODIGO-PEA e entre CDIGO-FORNECEDOR e o CODIGO-COMPRADOR. Embora esteja na 3FN,
ao conter mais de um fato multivalor, torna sua atualizao muito difcil, bem como a possibilidade de problemas
relativos ao espao fsico de armazenamento poderem ocorrer, causados pela ocupao desnecessria de rea de
memria (primria ou secundria), podendo acarretar situaes crticas em termos de necessidade de mais
espao para outras aplicaes.
Para passarmos a entidade acima para a 4FN, necessria a realizao de uma diviso da entidade
original, em duas outras, ambas herdando a chave CODIGO-FORNECEDOR e concatenado, em cada nova entidade,
com os atributos CODIGO-PEA e CODIGO-COMPRADOR.

Quinta Forma Normal (5FN)

Esta ltima forma normal trata do conceito de dependncia de juno, quando a noo de normalizao
aplicada decomposio, devido a uma operao de projeo, e aplicada na reconstruo devido a uma juno.
A 5FN trata de casos bastantes particulares, que ocorrem na modelagem de dados, que so os
relacionamentos mltiplos (ternrios, quaternrios, ..., n-rios). Ela fala que um registro est na sua 5FN, quando
o contedo deste mesmo registro no puder ser reconstrudo (juno) a partir de outros registros menores,
extrados deste registro principal. Ou seja, se ao particionar um registro, e sua juno posterior no conseguir
recuperar as informaes contidas no registro original, ento este registro est na 5FN.
Vamos ilustrar o uso da 5FN utilizando um exemplo de relacionamento ternrio:
Ex.: Uma empresa constri equipamentos complexos. A partir de desenhos de projeto desses
equipamentos, so feitos documentos de requisies de materiais, necessrios para a construo do
equipamento; toda a requisio de um material d origem a um ou mais pedidos de compra. A modelagem deste
exemplo, ir mostrar quais materiais de que requisies geraram quais pedidos. Na fig. 12.2 apresentado este
relacionamento ternrio.

155

A tabela 2, representante do relacionamento ternrio M-R-P, poderia conter os seguintes dados:

Utilizando uma soma de visualizao da dependncia de juno, obtemos o seguinte grfico de

dependncia de juno, mostrado na fig. 12.3.

Uma pergunta surge sobre este problema: possvel substituir o relacionamento ternrio por
relacionamentos binrios, como os apresentados na fig. 12.4.

Como resposta, podemos dizer que geralmente no possvel criar esta decomposio sem perda de
informao, armazenada no relacionamento ternrio.
Realizando uma projeo na tabela anterior, chegamos s entidades apresentadas na fig. 12.5.

156

Se realizarmos, agora, um processo de juno destas trs entidades, teremos:

Inicialmente, vamos juntar a entidade 1 com a entidade 2, atravs do campo pedido de compra. Obtemos
ento a entidade 4, mostrada na fig. 12.6:

Podemos observar que o registro apontado pela seta no existia na tabela original, ou seja, foi criado pela
juno das tabelas parciais. Devemos juntar a entidade 4, resultante da primeira juno, com a entidade
3, atravs dos campos material e requisio. Aps esta ltima operao de juno, obtemos a entidade 5,
mostrada na fig. 12.7.

157

Como se pode notar, ao se juntar as trs entidades, fruto da decomposio da entidade original, as
informaes destas foram preservadas. Isto significa que o relacionamento M-R-P no est na 5FN, sendo
necessrio decomp-lo em relacionamento binrios, os quais estaro na 5FN.
A definio da 5FN diz que: uma relao de 4FN estar em 5FN, quando seu contedo no puder ser
reconstrudo (existir perda de informao) a partir das diversas relaes menores que no possuam a mesma
chave primria. Esta forma normal trata especificamente dos casos de perda de informao, quando da
decomposio de relacionamentos mltiplos.
Com a 5FN, algumas redundncias podem ser retiradas, como a informao de que o ROTOR 1BW est
presente na requisio R3192, ser armazenada uma nica vez, a qual na forma no normalizada pode ser
repetida inmeras vezes.
Roteiro de Aplicao da Normalizao
Entidade ou documento no normalizado, apresentando grupos repetitivo e certas anomalias de
atualizao.
Aplicao da 1FN
- Decompor a entidade em uma ou mais entidades, sem grupos repetitivos;
- Destacar um ou mais atributos como chave primria da(s) nova(s) entidade(s), e este ser concatenado com a
chave primria da entidade original;
- Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s) gerada(s) e a entidade geradora;
- Verificar a questo da variao temporal de certos atributos e criar relacionamentos 1:N entre a entidade
original e a entidade criada por questes de histrico.
Entidades na 1FN
Aplicao da 2FN
- Para entidades que contenham chaves primrias concatenadas, destacar os atributos que tenham dependncia
parcial em relao chave primria concatenada;
- Criar uma nova entidade que conter estes atributos, e que ter como chave primria o(s) atributo(s) do(s)
qual(quais) se tenha dependncia parcial;
- Sero criadas tantas entidades quanto forem os atributos da chave primria concatenada, que gerem
dependncia parcial;
- Estabelecer o relacionamento e a cardinalidade entre a(s) nova(s) entidade(s) gerada(s) e a entidade geradora.
Entidades na 2FN
- Verificar se existem atributos que sejam dependentes transitivos de outros que no pertencem chave
primria, sendo ela concatenada ou no, bem como atributos que sejam dependentes de clculo realizado a
partir de outros atributos;
- Destacar os atributos com dependncia transitiva, gerando uma nova entidade com este atributo e cuja chave
primria o atributo que originou a dependncia;
158

- Eliminar os atributos obtidos atravs de clculos realizados a partir de outros atributos.

Entidades na 3FN
aplicao da FNBC
- S aplicvel em entidades que possuam chaves primrias e candidatas concatenadas;
- Verificar se alguma chave candidata concatenada um determinante, e em caso afirmativo, criar uma entidade
com os que dependam funcionalmente deste determinante e cuja chave primria o prpria determinante.
Entidades na FNBC
- Aplicao da 4FN
- Para se normalizar em 4FN, a entidade tem que estar (obrigatoriamente) na 3FN;
- Verificar se a entidade possui atributos que no sejam participantes da chave primria e que sejam
multivalorados e independentes em relao a um mesmo valor da chave primria;
- Retirar estes atributos no chaves e multivalorados, criando novas entidades individuais para cada um deles,
herdando a chave primria da entidade desmembrada.
Entidades na 4FN
- aplicao da 5FN
- Aplicada em elemento que estejam na 4FN;
- A ocorrncia deste tipo de forma normal est vinculada aos relacionamentos mltiplos (ternrios, etc.) ou
entidades que possuam chave primria concatenada com trs ou mais atributos;
- Verificar se possvel reconstruir o contedo do elemento original a partir de elementos decompostos desta;
- Se no for possvel, o elemento observado no est na 5FN, caso contrrio os elementos decompostos
representam um elemento na 5FN.
Entidades na forma normal final
O processo de normalizao leva ao refinamento das entidades, retirando delas grande parte das redundncias e
inconsistncias. Naturalmente, para que haja uma associao entre entidades preciso que ocorram
redundncias mnimas de atributos que evidenciam estes relacionamentos entre entidades.
Desnormalizao
Parece um tanto quanto incoerente apresentar um item falando sobre desnormalizao. Porm os
processos de sntese de entidades vistos at aqui levam criao de novas entidades e relacionamentos.
Os novos elementos criados podem trazer prejuzos na hora de serem implementados em um SGBD.
Devido as caractersticas de construo fsica de certos banco de dados, algumas entidades e relacionamentos
devem ser desnormalizados para que o SGBD tenha um melhor desempenho.
Hoje em dia, existe um grande debate sobre as chamadas semnticas da normalizao, sua utilidade e
facilidade em relao implementao fsica em um sistema operacional.
Vrios estudos e algumas consideraes esto sendo realizados, e se chega at a utilizao de banco de
dados relacionais no normalizados, por apresentarem maior ligao com a realidade e por terem vnculos
matemticos mais amenizados.
Outro aspecto da normalizao que todas as definies sobre as formas normais aps a 1FN, ainda no
foram exaustivamente examinadas, propiciando assim grandes controvrsias. A reduo das anomalias de
atualizao devido s formas normais de alta ordem sofre os ataques bvios dos grandes problemas (fsicos) de
atualizao, pois as relaes esto excessivamente normalizadas e com isso uma simples alterao pode encadear
um efeito cascata bastante profundo no banco de dados, ocasionando um aumento bastante significativo no
tempo.

159

Infelizmente, os argumentos que podem viabilizar o processo de desmoralizao sofrem de uma

deficincia e aderncia matemtica.
Pesquisas recentes indicam que as estruturas desnormalizadas (apelidadas de forma normal no primeira)
tm um atrativo matemtico similar ao que foi o da normalizao. Estas pesquisas esto provendo recentes
definies sobre lgebra relacional desnormalizada e extenses linguagem SQL para a manipulao de relaes
desnormalizadas.
Ao se optar pela desnormalizao, deve-se levar em conta o custo da redundncia de dados e as
anomalias de atualizao decorrentes.
Chegou-se concluso tambm que o esprito da normalizao contradiz vrios princpios importantes,
relativos modelagem semntica e construo de bases de dados em SGBD orientados por objeto.
Consideraes Finais sobre Normalizao
Antes de qualquer concluso, podemos observar que as formas normais nada mais so do que restries
de integridade, e medida que se alimenta este grau de normalizao, torna-se cada vez mais restritivas.
Dependendo do SGBD relacional utilizado, essas restries podem se tornar benficas ou no.
A forma de atuao da normalizao no ciclo de vida de um projeto de banco de dados pode ser mais
satisfatria no desenvolvimento (botton-up) de modelos preliminares, a partir da normalizao da documentao
existente no ambiente analisado, bem como de arquivos utilizados em alguns processos automatizados neste
ambiente.
No caso do desenvolvimento top-down, no qual um modelo de dados criado a partir da visualizao da
realidade, a normalizao serve para realizar um aprimoramento deste modelo, tornando-o menos redundante e
inconsistente. No caso desta viso, a normalizao torna-se um poderoso aliado da implementao fsica do
modelo.
Por experincia, podemos afirmar que a construo de um modelo de dados j leva naturalmente ao
desenvolvimento de entidades e relacionamentos na 3FN, ficando as demais (FNBC, 4FN, e 5FN) para melhorias e
otimizaes.
A criao de modelos de dados, partindo-se da normalizao de documentos e arquivos pura e
simplesmente, no o mais indicado, pois na verdade estaremos observando o problema e no dando uma
soluo para ele. Neste caso, estaremos projetando estruturas de dados que se baseiam na situao atual (muitas
vezes catica) e que certamente no vo atender s necessidades reais do ambiente em anlise. Ao passo que, se
partimos para a criao do modelo de dados com entidades e relacionamentos aderentes realidade em estudo
(mundo real), vamos naturalmente desenvolver uma base de dados ligada viso da realidade e como
consequncia iremos solucionar o problema de informao.
A aplicao da modelagem de dados, ao longo da nossa vida profissional, tem sido bastante gratificante,
mostrando principalmente, que a tcnica de normalizao uma ferramenta muito til como apoio ao
desenvolvimento do modelo de dados. Seja ela aplicada como levantamento inicial (documentos e arquivos) bem
como otimizador do modelo de dados, tendo em vista certas restries quanto implementao fsica nos banco
de dados conhecidos.
Todas as ideias sobre eficincia da normalizao passam necessariamente sobre tempo e espao fsico,
em funo, principalmente, das consultas efetuadas pelos usurios bem como a quantidade de bytes necessrios
para guardar as informaes.
Nota-se, atravs da observao, que o projeto do modelo conceitual nem sempre pode ser derivado para
o modelo fsico final. Com isso, de grande importncia que o responsvel pela modelagem (analista, AD, etc.)
no conhea s a teoria iniciada por Peter Chen, mas tambm tenha bons conhecimentos a respeito do ambiente
do banco de dados utilizado pelo local em anlise.

160

Regras de Integridade
As regras de integridade fornecem a garantia de que mudanas feitas no banco de dados por usurios
autorizados no resultem em perda de consistncia de dados. Assim, as regras de integridade protegem o banco
de dados de danos acidentais.
J vimos regras de integridade para o modelo E-R. Essas regras possuem a seguinte forma:
Declarao de variveis a determinao de certos atributos, como chave candidata, para um dado
conjunto de entidades. O conjunto de inseres e atualizaes vlidas restrito quelas que no criem
duas entidades com o mesmo valor de chave candidata.
Forma de um relacionamento muitos para muitos, um para muitos, um para um. O conjunto de
relacionamentos um para um ou um para muitos restringe o conjunto de relacionamentos vlidos entre
os diversos conjuntos de entidades.
Em geral, uma regra de integridade constitui um predicado arbitrrio pertencente ao banco de dados. Entretanto,
predicados arbitrrios podem representar altos custos para serem testados. Assim, normalmente, as regras de
integridade so limitadas s que podem ser verificadas com o mnimo tempo de processamento.
Restries de Domnios
Vimos que um domnio de valores vlidos pode ser associado a qualquer atributo. Vimos tais restries
so especificadas em SQL DDL. Restries de domnio so as mais elementares formas de restries de
integridade. Elas so facilmente verificadas pelo sistema sempre que um novo item de dado incorporado ao
banco de dados.
possvel que diversos atributos tenham um mesmo domnio. Por exemplo, os atributos nome_cliente e
nome_empregado podem ter o mesmo domnio: o conjunto de todos os nomes de pessoas. Entretanto, os
domnios de saldo e nome_agncia certamente sero distintos. Ser, talvez, menos claro o caso nome_cliente e
nome_agncia que podem ter o mesmo domnio. No nvel de implementao, os nomes de agncia e clientes so
strings de caracteres. No entanto, essas linguagens inibem os quebra-galhos, que so frequentemente
necessrios na programao de sistemas. Uma vez que os sistemas de banco de dados so projetados para
atender a diversos usurios que no so especialistas em banco de dados, os benefcios de tipos fortemente
definidos geralmente apresentam mais desvantagens do que vantagens. Apesar disso, muito dos sistemas
existentes permitem apenas um reduzido nmero de domnios de tipos. Poucos sistemas, particularmente os
sistemas de banco de dados orientado a objeto, oferecem um conjunto rico de tipos de domnios que podem ser
facilmente ampliados.
A clusula check da SQL-92 permite modos poderosos de restries de domnios que a maioria dos
sistemas de tipos das linguagens de programao no permite. Especificamente, a clusula check permite ao
projeto do esquema determinar um predicado que deva ser satisfeito por qualquer valor designado a uma
varivel cujo tipo seja o domnio. Por exemplo, uma clusula check pode garantir que o domnio relativo ao turno
de trabalho de um operrio contenha somente valores maiores que um dado valor (turno mnimo), como
ilustrado aqui:
create domain turno_trabalho numeric (5,2)
o domnio de turno_trabalho declarado como um nmero decimal com um total de cinco dgitos, dois
dos quais colocados aps o ponto decimal, e o domnio possui uma restrio que assegura que o turno de
trabalho no seja inferior a 4,00. A clusula constraint valor_teste_turno opcional e usada para dar o nome
valor_teste_turno restrio. O nome usado para indicar quais restries foram violadas em determinada
atualizao.
A clusula check pode tambm ser usada para restringir os valores nulos em um domnio, como ilustrado
a seguir:

161

Como outro exemplo, o domnio pode ser restrito a determinado conjunto de valores por meio do uso da
clusula in:

Integridade Referencial
Frequentemente, desejamos garantir que um valor que aparece em uma relao para um dado conjunto
de atributos tambm aparea para um certo conjunto de atributos de outra relao. Essa condio chamada
integridade referencial
Conceitos Bsicos
Considere um par de relaes r(R) e s(S) e a juno natural
. Pode existir uma tupla tr em r que no
possa ser combinada a nenhuma tupla em s. Isto , no existe nenhum tS em s tal que
. Tais
tuplas so chamadas de tuplas pendentes. Dependendo do conjunto de entidades ou relacionamentos que est
sendo modelado, tuplas pendentes podem ou no ser aceitveis.
Sabemos que existe um tipo diferente de juno a juno externa para operar relaes contendo
tuplas pendentes. No estamos abordando consultas aqui, mas o modo de tratar a existncia, quando desejada,
de tuplas pendentes no banco de dados.
Suponha que exista a tupla t1 na relao conta, com t1[nome_agncia] = Lunartown, mas que no haja
nenhuma tupla na relao agncia para Lunartown. Essa situao pode ser indesejvel.
Esperamos que a relao agncia possua todas as agncias do banco. Portanto, a tupla t1 faz referncia a
uma conta de uma agncia inexistente. Obviamente, gostaramos de implementar uma regra de integridade que
proba tuplas pendentes desse tipo.
No entanto, nem todos os tipos de tuplas pendentes so indesejveis. Suponha que exista uma tupla t2 na
relao agncia, com t2[nome_agncia]= Mokan, mas no h nenhuma tupla da relao conta com referncia
agncia Mokan. Nesse caso, existe uma agncia que no possui nenhum conta.
Embora essa seja uma situao incomum, pode ocorrer quando uma agncia est sendo aberta ou
fechada. Assim, no devemos proibir esse tipo de situao.
A diferena entre esses dois exemplos tem origem em dois fatos:
O atributo nome_agncia do Esquema_conta uma chave estrangeira (foreign key) cuja referncia a
chave primria do Esquema_agncia.
O atributo nome_agncia do Esquema_agncia no uma chave estrangeira.
No exemplo de Lunartown, a tupla t1 de conta tem um valor para a chave estrangeira nome_agncia que
no aparece em agncia. No exemplo da agncia Mokan, a tupla t2 de agncia tem um valor nome_agncia que
no aparece em conta, mas nome_agncia no uma chave estrangeira. Assim, a diferena entre nossos dois
exemplos de tuplas pendentes a existncia de uma chave estrangeira.
Seja r1(R1) e r2(R2) relaes com chaves primrias K1 e K2, respectivamente. Dizemos que um subconjunto
de R2 uma chave estrangeira associada a K1 em relao a r1 se garantido que, para todo t2 em r2, existe uma
tupla t1 em r1, tal que t1[K1] = t2[]. Exigncias desse tipo so chamadas de regras de integridade referencial ou
subconjunto dependente. O ltimo termo advm do fato de ser possvel escrever a regra de integridade
referencial anterior como
deve ser igual a K1.

(r1). Note que, para a regra de integridade referencial ter sentido, cada

Integridade Referencial no Modelo E-R

Regras de integridade referencial aparecem com frequncia. Se derivarmos nosso esquema de bancos de
dados relacional em tabelas originadas de diagramas E-R, ento toda relao resultante de um conjunto de
relacionamentos possui regras de integridade referencial. A fig. 6.1 mostra um conjunto de relacionamentos R de
162

n elementos, relacionando os conjuntos de entidades E1, E2, ..., En. Seja Ki a chave primria de Ei. Os atributos para
o esquema da relao referente ao conjunto de relacionamentos R incluem K1K2... Kn. Cada Ki do esquema de
R uma chave estrangeira que leva a uma regra de integridade referencial.

Outra fonte de regras de integridade referencial so os conjuntos de entidades fracas. Vimos que o
esquema da relao para um conjunto de entidades fracas precisa incluir a chave primria do conjunto de
entidades do qual ele dependente. Assim, o esquema da relao para cada conjunto de entidades fracas inclui
uma chave estrangeira que leva a uma regra de integridade referencial.
Modificaes no Banco de Dados
As modificaes no banco de dados podem originar violao das regras de integridade referencial.
Colocamos aqui a verificao necessria a cada tipo de modificao no banco de dados para que se possa
preservar a seguinte regra de integridade referencial:

Insero. Se uma tupla t2 inserida em r2, o sistema deve garantir que exista uma tupla t1 em r1 tal que

t1[K]=t2[]. Isto :
Remoo. Se uma tupla t1 removida de r1, o sistema deve tratar tambm no conjunto de tuplas em r2

que so referidos por t1:

.
Se esse conjunto vazio, o comando de remoo foi rejeitado devido a algum erro ou a tupla que faz
referncia a t1 deve ser removida. Esta ltima alternativa pode levar a uma remoo em cascata se
algumas tuplas fizerem referncia a tuplas que se referem a t1 e assim por diante.
Atualizao. Precisamos considerar duas situaes de atualizaes: as que se referem relao (r2) e as
referidas pela relao (r1).
o Se uma tupla t2 da relao r2 atualizada e a atualizao modifica os valores da chave estrangeira
, ento feita uma verificao similar insero. Seja t2 o novo valor da tupla t2. O sistema
o

dever assegurar que:

Se uma tupla t1 da relao r1 atualizada e a atualizao modifica os valores de uma chave
primria (K), ento dever ser feito um teste similar ao realizado para a remoo. O sistema
dever computar
usando o valor antigo de t1 (o valor existente antes da aplicao
da atualizao). Se esse conjunto no for vazio, a atualizao ser rejeitada como uma ocorrncia
de erro ou as atualizaes sero realizadas em cascata, de modo similar ao que ocorre na
remoo.

Integridade Referencial em SQL

possvel definir chaves primrias, secundrias e estrangeiras como parte do comando create table da
SQL:
163

A clusula primary key do comando create table inclui a lista dos atributos que constituem a chave
primria.
A clusula unique do comando create table inclui a lista dos atributos que constituem uma chave
candidata.
A clusula foreign key do comando create table inclui a lista dos atributos que constituem a chave
estrangeira quanto o nome da relao qual a chave estrangeira faz referncia.

Ilustramos as declaraes de chaves estrangeiras e primrias usando definies de parte de nosso banco em SQL
DDL, mostrado na fig. 6.2. Note que no nos detivemos em modelar de modo preciso o mundo real no exemplo
do banco de dados de uma empresa da rea bancria. No mundo real, diversas pessoas podem ter o mesmo
nome, assim nome_cliente no pode ser chave primria para cliente. No mundo real, alguns outros atributos,
como o nmero do seguro social, ou uma combinao de atributos como nome e endereo, poderiam ser usados
como chave primria. Usamos nome_cliente como chave primria para conferir simplicidade e conciso a nosso
esquema de banco de dados.
Podemos usar a forma simplificada para declarar que uma nica coluna uma chave estrangeira:
A SQL tambm d suporte a uma outra maneira de formular a clusula chave estrangeira, em que uma
lista de atributos da relao por ela referida pode ser explicitamente especificada, e esses atributos so usados no
lugar da chave primria; essa lista de atributos precisa ser declarada como chave candidata de uma relao
referida.

Quando uma regra de integridade referencial violada, o procedimento normal rejeitar a ao que
ocasionou essa violao. Entretanto, a clusula relativa a foreign key em SQL-92 pode especificar que, se uma
remoo ou atualizao na relao a que ela faz referncia violar uma regra de integridade, ento, em vez de
rejeitar a ao, executam-se passos para modificao da tupla na relao que contm a referncia, de modo a
garantir a regra de integridade. Considere a seguinte definio de regra de integridade para a relao conta:
164

Devido clusula on delete cascade associada declarao da chave estrangeira, se a remoo de uma
tupla de agncia resultar na violao da regra de integridade anterior, a remoo no ser rejeitada. Ao contrrio,
a remoo feita em cascata na relao conta, de modo que as tuplas que se referirem a uma agncia
removida sejam tambm removidas. De modo similar, a atualizao de um campo referido por uma regra de
integridade no ser rejeitada se ela violar uma regra de integridade; pelo contrrio, o campo nome_agncia das
tuplas da relao conta ser tambm atualizado. A SQL-92 permite, tambm, que a clusula foreign key
especifique outros tipos de aes alm de cascata, como alterar o campo em questo (no caso, nome_agncia)
com nulos, ou um valor-padro, caso a regra seja violada.
Se houver uma cadeia de dependncias entre chaves estrangeiras de diversas relaes, uma remoo ou
uma atualizao em uma das extremidades poder propagar-se ao longo de toda a cadeia. Se uma atualizao ou
remoo em cascata provoca a violao de uma regra de integridade que no pode ser tratada por uma operao
de cascata seguinte, o sistema aborta a transao. Como resultado, todas as mudanas causadas pela transao,
assim como as aes em cascata decorrentes, sero desfeitas.
A semntica de chaves em SQL torna-se mais complexa pelo fato da SQL permitir valores nulos. As
seguintes regras, algumas das quais arbitrrias, so usadas para tratar esses valores nulos.
Todos os atributos de uma chave primria so declarados implicitamente como not null.
Atributos de uma declarao unique (isto , atributos de uma chave candidata) podem ser nulos,
contanto que no sejam declarados no-nulos de outro modo. A restrio para garantia da unicidade em
uma relao violada somente se duas tuplas da relao tm o mesmo valor para todos os atributos da
regra unique e todos os valores forem no-nulos. Assim, qualquer nmero de tuplas pode ser igual em
todas as colunas declaradas como nicas, sem que haja violao da regra de integridade, contanto que ao
menos uma das colunas tenha um valor nulo.
Atributos nulos em chaves estrangeiras so permitidos, contanto que no tenha sido declarados como
no-nulos de outro modelo. Se todas as colunas de uma chave estrangeira so no-nulas em uma
determinada tupla, a definio usual de regra de integridade em chave estrangeira ser empregada
naquela tupla. Se qualquer uma das colunas da chave nula, a tupla automaticamente aprovada na
regra de integridade. Essa definio arbitrria e nem sempre uma boa opo, assim a SQL fornece,
tambm, construtores que possibilitam mudana de comportamento em relao aos valores nulos.
Dada a complexidade e arbitrariedade natural das formas e comportamentos de restries (ou regras) de
integridade SQL em relao a valores nulos, melhor assegurar que todas as colunas especificadas em unique e
foreign key sejam declaradas, no permitindo nulos.
Asseres
Uma assero um predicado que expressa uma condio que desejamos que seja sempre satisfeita no
banco de dados. Restries de domnio e regras de integridade referencial so formas especiais de asseres.
Dispensamos substancial ateno a essas formas de asseres, porque so facilmente verificadas e aplicadas em
grande parte das aplicaes em banco de dados. Entretanto, existem muitas restries que no podem ser
expressas usando somente essas formas especiais. Exemplos dessas restries compreendem:
A soma de todos os totais em conta emprstimo de cada uma das agncias deve ser menor que a soma
de todos os saldos da contas dessa agncia.
165

Todo emprstimo deve ter ao menos um cliente que mantenha uma conta com saldo mnimo de mil
dlares.
Uma assero em SQL-92 toma a seguinte forma:

As duas regras mencionadas podem ser escritas como mostrado a seguir. J que a SQL no oferece um
construtor para todo X, P(X) (em que P um predicado), somos forados a implementar o construtor usando o
construtor no existe X tal que nenhum P(X), pode ser escrito em SQL.

Quando uma assero criada, o sistema verifica sua validade. Se as asseres so vlidas ento qualquer
modificao posterior no banco de dados ser permitida somente quando a assero no for violada. Quando as
asseres so complexas, a verificao pode gerar um aumento significativo em tempo de processamento. Por
isso, as asseres so usadas com muito cuidado.
Esse grande overhead para teste e manuteno de asseres tem levado alguns profissionais ligados ao
desenvolvimento de sistemas de banco de dados a excluir as asseres gerais ou a fornecer apenas formas
especiais de asseres, que possam ser verificadas facilmente.
Gatilhos (Triggers)
Um gatilho um comando que executado pelo sistema automaticamente, em consequncia de uma
modificao no banco de dados. Duas exigncias devem ser satisfeitas para a projeo de um mecanismo de
gatilho:
1. Especificar as condies sob as quais o gatilho deve ser executado.
2. Especificar as aes que sero tomadas quando um gatilho for disparado.
Os gatilhos so mecanismos teis para avisos a usurios ou para executar automaticamente determinadas
tarefas quando as condies para isso so criadas. Como ilustrao, suponha que, em vez de permitir saldos
negativos em conta, o banco crie condies para que a conta corrente seja zerada e o saldo negativo seja
transferido para uma conta emprstimo. Essa conta emprstimo ter o mesmo nmero da conta corrente em
questo. Para esse exemplo, a condio para o disparo de um gatilho uma atualizao na relao conta que
resulta em um valor negativo para saldo.
Suponha que Jones tenha feito um resgate em uma conta que gerou um saldo negativo. Suponha que t
denote a tupla de conta com um valor negativo para saldo. As aes a tomar so as seguintes:
Inserir uma nova tupla s na relao emprstimo com:

166

(Note que, se t[saldo] for negativo, impedimos que t[saldo] receba um valor positivo em um total de
emprstimo.)
Inserir uma nova tupla u na relao devedor com:

Tornar t[saldo] igual a 0.

O padro SQL-92 no dispe de gatilhos, embora a proposta original da SQL do Sistema R proponha
alguns recursos para gatilhos. Alguns sistemas existentes possuem seus prprios recursos de gatilho no
padronizados. Ilustraremos, aqui, como um gatilho para saldo negativo poderia ser escrito na verso original de
SQL.

167

A palavra-chave new usada antes de T.saldo indica que o valor de T.saldo aps a atualizao dever ser
usado; se ele for omitido, o valor existente antes da atualizao ser, ento, usado.
Os gatilhos so chamados, algumas vezes, de regras (rules), ou regras ativas (active rules), mas no devem
ser confundidos com as regras da Datalog, que tratam realmente de definies de vises.
Dependncia Funcional
A noo de dependncia funcional uma generalizao da noo de chave. Dependncias funcionais
representam um papel importante no projeto de banco de dados.
Conceitos Bsicos
Dependncias funcionais so restries ao conjunto de relaes vlidas. Elas permitem expressar
determinados fatos em nosso banco de dados relativos empresa que desejamos modelar.
Eis o conceito de superchave como segue. Seja R o esquema de uma relao. Um subconjunto K de R
uma superchave de R em qualquer relao vlida r(R) para todos os pares de t1 e t2 de tuplas em r tal que t1t2,
ento t1[K]t2[K]. isto , nenhum par de tuplas em qualquer relao validade r(R) deve ter o mesmo valor no
conjunto de atributos K.
A noo de dependncia funcional generaliza a noo de superchave. Seja R e R. A dependncia
funcional:
realiza-se em R se, em qualquer relao validade r(R), para todos os pares de tuplas t1 e t2 em r,
tal que t1[] = t2[], t1[] = t2[] tambm ser verdade.
Usando a notao de dependncia funcional, dizemos que K uma superchave de R se K
R. isto , K
uma superchave se, para todo t1[K]=t2[K], t1[R]=t2[R] (isto , t1=t2).
A dependncia funcional permite-nos expressar restries que as superchaves no expressam. Considere
o esquema:
esquema_info_emprstimo=(nome_agncia, nmero_emprstimo, nome_cliente, total)
O conjunto de dependncias funcionais que queremos garantir para esse esquema relao :

Entretanto, no esperamos realizar dependncia funcional para:

j que, em geral, um emprstimo pode ser contrado por mais de um cliente (por exemplo, para ambos os
membros de um casal, marido-mulher).
Podemos usar dependncia funcional de dois modos:
1. Usando-as para o estabelecimento de restries sobre um conjunto de relaes vlidas. Devemos, assim,
concentr-las somente quelas relaes que devem satisfazer um dado conjunto de dependncias
funcionais. Se desejarmos restringi-las a relaes do esquema R que satisfaam um conjunto F de
dependncias funcionais, dizemos que F realiza-se em R.
2. Usando-as para verificao de relaes, de modo a saber se as ltimas so vlidas sob um dado conjunto
de dependncias funcionais. Se desejarmos restringi-las a relaes do esquema R que satisfaam um
conjunto F de dependncias funcionais, dizemos que r satisfaz F.
Consideremos a relao r da fig. 6.3 para verificar quais dependncias funcionais so satisfeitas. Observe que
A
C satisfeita. Duas tuplas tm valor a1 em A. essas tuplas tm um mesmo valor de C denominado cI. de
modo similar, duas tuplas com valor a2 em A tm mesmo valor c2 em C, mas eles possuem valor diferentes em A,
a2 e a3, respectivamente. Assim, encontramos um par de tuplas t1 e t2 tal que t1[C]=t2[C], mas t1[A]t2[A].

168

Diversas outras dependncias funcionais so satisfeitas por r, incluindo, por exemplo, a dependncia
funcional AB
D. Note que usamos AB como notao simplificada para [A,B], reduzindo-se a um padro mais
prtico. Observe que no existe nenhum par de tuplas distintas t1 e t2 tal que t1[AB]=t2[AB]. Portanto, se
t1[AB]=t2[AB], entoa necessrio que t1=t2 e, assim, t1[D]=t2[D]. Logo, r satisfaz AB
D.
Algumas dependncias funcionais so consideradas triviais porque so satisfeitas por todas as relaes.
Por exemplo, A
A satisfeita por todas as relaes que contm o atributo A. Na leitura literal da definio de
dependncia funcional, podemos notar que, para todos os atributos t1 e t2 tal que t1[A]=t2[A] ser tambm
verdade. De modo similar, AB
A satisfeita para todas as relaes envolvendo o atributo A. Em geral, uma
dependncia funcional da forma
trivial se .
Para distinguir os conceitos de uma relao que satisfaz uma dependncia e de uma dependncia
realizando-se em um esquema, retornaremos ao exemplo do banco. Se considerarmos a relao cliente (com o
esquema_cliente), como mostrado na fig. 6.4, notamos que rua_cliente
cidade_cliente satisfeita. Entretanto,
acreditamos que, no mundo real, duas cidades podem possuir duas ou mais ruas com o mesmo nome. Assim,
possvel, em algum tempo, haver uma instncia da relao cliente na qual rua_cliente
cidade_cliente no
satisfeita. Logo, no incluiremos rua_cliente
cidade_cliente no conjunto das dependncias funcionais que so
realizadas no Esquema_cliente.

Na relao emprstimo (do esquema_emprstimo) na fig. 6.5, vemos que nmero_emprstimo
total
satisfeita. Ao contrrio do que ocorre em cidade_cliente e rua_cliente no esquema_cliente, acreditamos que, em
empresas reais, eles so modelados de modo a garantir que cada conta tenha somente um total. Portanto,
queremos que a condio nmero_emprstimo
total seja sempre satisfeita para a relao emprstimo. Em
outras palavras, necessitamos da restrio nmero_emprstimo
total para o esquema_emprstimo.

169

Na relao agncia da fig. 6.6, vemos que nome_agncia
fundos satisfeita, assim como
fundos
nome_agncia. Gostaramos de garantir que nome_agncia
fundos fosse realizada em
esquema_agncia. Entretanto, no queremos que fundos
nome_agncia seja realiza, uma vez que possvel
haver diversas agncias com o mesmo valor de fundos.
Embora a SQL no fornea um modo simples para especificao de dependncia funcional podemos
escrever consultas para verificao de dependncias funcionais, assim como criar asseres para garantia de
dependncias funcionais.

Conforme segue, consideramos que, quando projetamos um banco de dados relacional, primeiro
relacionamos as dependncias funcionais que sempre precisam ser realizadas. No exemplo do banco, nossa
relao de dependncias funcionais engloba as seguintes:
No esquema_agncia:
nome_agncia
cidade_agncia
nome_agncia
fundos
No esquema_cliente:
nome_cliente
cidade_cliente
nome_cliente
rua_cliente
No esquema_emprstimo:
nmero_emprstimo
total
nmero_emprstimo
nome_agncia
No esquema_devedor:
nenhuma dependncia funcional

170

No esquema_conta:
nmero_conta
nome_agncia
nmero_conta
saldo
No esquema_depositante:
nenhuma dependncia funcional

Clausura de um Conjunto de Dependncias Funcionais

No basta considerar um dado conjunto de dependncias funcionais. preciso considerar todos os
conjuntos de dependncias funcionais que so realizados. Podemos mostrar que, dado um conjunto F de
dependncias funcionais, prova-se que outras dependncias funcionais realizam-se. Dizemos que esse tipo de
dependncia funcional logicamente implcito em F.
Suponha um dado esquema de relao R = (A, B, C, G, H, I) o conjunto de dependncias funcionais:
A
B
A
C
CG
H
CG
I
B
H
A dependncia funcional:
A
H
logicamente implcita. Isto , podemos mostrar que, sempre que um dado conjunto de dependncias
funcionais se realiza, A
H tambm se realiza. Suponha que t1 e t2 so duas tuplas, tais que:
t1[A] = t2[A]
J que dado que A
B, dessa definio de dependncia funcional decorre que:
t1[B] = t2[B]
Ento, desde que B
H seja dada, decorre desta definio de dependncia funcional que:
t1[H]=t2[H]
Portanto, mostramos que, sempre que t1 e t2 forem tuplas, tais que t1[A]=t2[A], necessariamente t1[H] =
t2[H]. Mas essa exatamente a definio de A
H.
Seja F um conjunto de dependncias funcionais. A clausura de F o conjunto de todas as dependncias
funcionais logicamente implcitas em F. Denotamos a clausura de F por F+. Dado F, podemos computar F+
diretamente da definio formal de dependncia funcional. Se F for grande, esse processo pode tornar-se lento e
difcil. Tal qual a computao de F+, exige argumentos do tipo dado anteriormente para mostrar que A
H est
em clausura em nosso conjunto de exemplo de dependncias. Existem tcnicas mais simples para o raciocnio da
dependncia funcional.
A primeira tcnica tem por base trs axiomas ou regras para inferncia da dependncia funcional. Para
aplicao dessas regras, precisamos encontrar todos os F+ de um dado F. Nas regras a seguir, adotamos a
conveno do uso de letras gregas para conjuntos de atributos e de letras maisculas do alfabeto romano para
atributos individuais. Usamos para denotar
.
Regra de reflexividade. Se um conjunto de atributos e
, ento
realiza-se.
Regra de incremento. Se
realiza-se e um conjunto de atributos, ento
tambm realizase.
Regra de transitividade. Se
realiza-se e
realiza-se, ento
realiza-se.

171

Essas regras so slidas, porque elas no geram nenhuma dependncia funcional incorreta. As regras so
completas, porque, para um dado conjunto F de dependncias funcionais, elas nos permitem criar todo F+. Para
simplificar, relacionamentos regras adicionais:
Regra de unio. Se
e
, ento
tambm realiza-se.
Regra de decomposio. Se
realiza-se, ento
e
tambm realizam-se.
Regra pseudotransitiva. Se
e
, ento
tambm realiza-se.
Apliquemos nossas regras ao esquema do exemplo apresentado anteriormente R=(A, B, C, G, H, I) e ao conjunto F
de dependncias funcionais {A
B, A
C, CG
H, CG
I, B
H}. Relacionamos diversos membros de F+ aqui:
A
H. Desde que A
B e B
H realizam-se, aplicamos a regra da transitividade. Observe que foi mais fcil
aplicar os axiomas de Armstrong para mostrar que A
H se realiza do que raciocinando diretamente
sobre as definies, como fizemos anteriormente.
CG
HI. J que CG
H e CG
I, a regra da pseudotransitividade implica a realizao de AG
I.
Clausura de Conjunto de Atributos
Para verificar se um conjunto uma superchave, precisamos conceber um algoritmo para computar o
conjunto de atributos determinados funcionalmente por . Podemos deduzir que esse algoritmo tambm til
como parte do processamento da clausura de um conjunto de dependncias funcionais F.
Seja um conjunto de atributos. Chamamos o conjunto dos atributos funcionalmente determinados por
, sob um conjunto de dependncias funcionais F, de clausura de sob F, denotada por +. A fig. 6.7 mostra um
algoritmo, escrito em pseudo-Pascal, para computar +. O conjunto de dependncias funcionais F e o conjunto
de atributos funcionam como entrada. A sada armazenada na varivel resultado.
Para ilustrao de como o algoritmo da fig. 6.7 funciona, iremos us-lo para processar (AG)+ com as
dependncias funcionais definidas anteriormente. Comearemos com resultado = AG. A primeira execuo do
lao while para verificao da dependncia funcional ir chegar a:
A
B obriga-nos a incluir B no resultado. Para perceber esse fato, observemos que A
B est em F, A
resultado (o que AG), assim, resultado := resultado B.
A
C obriga que resultado se torne ABCG.
CG
H obriga que resultado se torne ABCGH.
CG
I obriga que resultado se torne ABCGHI.
Na segunda vez em que executamos o lao while, no ser adicionado nenhum outro atributo a
resultado, e o algoritmo terminar.

Vejamos por que o algoritmo da fig. 6.7 est correto. J que
sempre se realiza (pela regra da
reflexidade), o primeiro passo correto. Exigimos que, para qualquer subconjunto de resultado,
. J que
comeamos o lao while com
resultado sendo verdadeiro, podemos adicionar ao resultado somente se
resultado e
. Mas, ento, pela regra reflexiva, resultado
e, pela transitividade,
. Outra aplicao
da transitividade mostra que
(usando
e
). A regra da unio implica que
resultado
, assim
determina, funcionalmente, qualquer resultado novo gerado pelo lao while. Dessa forma, qualquer atributo
obtido pelo algoritmo est em +.

172

 fcil perceber que o algoritmo encontra todos os atributos de +. Se h um atributo de + que no esteja
ainda em resultado, ento preciso que haja uma dependncia funcional
, para a qual
resultado, e que
ao menos um atributo em no esteja em resultado.
Por outro lado, no pior caso, esse algoritmo pode tomar tempo proporcional ao quadrado do tamanho de
F. H um algoritmo mais rpido (embora ligeiramente mais complexo) que consome tempo proporcionalmente
linear ao tamanho de F.
Cobertura Cannica
Suponha que tenhamos um conjunto de dependncias funcionais F sobre o esquema de uma relao.
Sempre que uma atualizao realizada na relao, o sistema de banco de dados deve garantir que todas as
dependncias funcionais em F sejam satisfeitas no novo estado do banco de dados, ou dever reverter as
alteraes caso no o sejam.
Podemos reduzir os esforos exigidos para o teste por meio da simplificao de um dado conjunto de
dependncias funcionais, com ou sem a alterao daquele conjunto de clausura. Qualquer banco de dados que
satisfaa um conjunto simplificado de dependncias funcionais deve tambm satisfazer o conjunto original e viceversa, uma vez que os dois conjuntos tm a mesma clausura. Entretanto, o conjunto simplificado mais
facilmente verificado. O conjunto simplificado pode ser construdo com descrevemos a seguir. Primeiro,
precisamos de algumas definies.
Um atributo de uma dependncia funcional extrnseco se podemos remov-lo sem alterar a clausura do
conjunto de dependncias funcionais. Formalmente, atributos extrnsecos so definidos conforme segue.
Considere um conjunto de dependncias funcionais F e a dependncia funcional
em F.
O atributo A extrnseco a se A , e F implica logicamente (F {
}) {( A)
}.
O atributo A extrnseco a se A , e o conjunto de dependncias funcionais (F {
}) {( A)}
implica logicamente F.
Uma cobertura cannica Fc para F o conjunto de dependncias tal que F implique logicamente todas as
dependncias de FC e FC implique logicamente todas as dependncias em F. Alm disso, FC deve apresentar as
seguintes propriedades:
Nenhuma dependncia funcional em FC contm um atributo extrnseco.
Cada lado esquerdo da dependncia funcional em FC nico. Isto , no h duas dependncias 1
1 e
2
2 em Fc tal que 1= 2.
Uma cobertura cannica para um conjunto de dependncias funcionais F pode ser computada como:

Pode-se mostrar que a cobertura cannica de F, FC, possui a mesma clausura de F; ento, verificar se F
satisfeita. Entretanto, Fc mnima em certo sentido ela no contm atributos extrnsecos e as dependncias
funcionais, com mesmo lado esquerdo, foram combinadas. mais econmico verificar FC que testar o prprio F.
Considere o seguinte conjunto de dependncias funcionais F do esquema (A, B, C):
A
BC
B
C
A
B
AB
C
Vejamos como computar a cobertura cannica para F.
173

H duas dependncias funcionais com o mesmo conjunto de atributos do lado esquerdo da seta:
A
BC
A
B
Combinamos essas dependncias funcionais em A
BC.
A extrnseco em AB
C porque F implica logicamente (F {AB
C}) {B
C}. Essa assero verdadeira
porque B
C j est em nosso conjunto de dependncias funcionais.
C extrnseco em A
BC, uma vez que A
BC est implcita logicamente por A
B e B
C.
Assim, nossa cobertura cannica :
A
B
B
C

Dado um conjunto F de dependncias funcionais, pode ser que uma dependncia funcional total no
conjunto seja extrnseca, no sentido de que, tirando-as, no h mudana na clausura de F. podemos mostrar que
uma cobertura cannica FC de F no contm nenhuma dependncia funcional extrnseca. Suponha que, de modo
contrrio, houvesse tal dependncia funcional extrnseca em FC. O lado direito dos atributos da dependncia
poderia ser extrnseco, o que no possvel na definio da cobertura cannica.

174

Projeto e implementao de um banco de dados relacional

Genericamente, o objetivo do projeto de um banco de dados relacional gerar um conjunto de esquemas
de relaes que nos permita armazenar informaes sem redundncia desnecessria e, ainda, nos permita
recuperar informaes facilmente. Uma das abordagens possveis seria projetar esquemas na forma normal
apropriada. Para determinar se um esquema de relao atende a uma das formas normais, precisamos de
informaes adicionais sobre a empresa real cujo banco de dados estamos modelando. J vimos como podemos
usar dependncias funcionais para expressar fatos acerca dos dados.
Armadilhas no Projeto de banco de dados Relacional
Antes de prosseguir com nossa discusso sobre formas normais e dependncias de dados, vejamos o que
determina a qualidade de um projeto de banco de dados. Entre as propriedades indesejveis em um bom projeto
de banco de dados de banco de dados temos:
Informaes repetidas.
Inabilidade para representao de certas informaes.
Podemos discutir esses problemas usando uma modificao no projeto de banco de dados. Entre as
propriedades indesejveis em um bom projeto de banco de dados temos:
Informaes repetidas.
Inabilidade para representao de certas informaes.
Podemos discutir esses problemas usando uma modificao no projeto de banco de dados no exemplo que temos
usado de uma empresa de rea bancria; diferente do usado anterior, a informao acerca de emprstimos ser
agora representada em uma nica relao, linha_de_crdito, que ser definido pelo esquema de relao:
esquema_linha_de_crdito=(nome_agncia, cidade_agncia, fundos, nome_cliente, nmero_emprstimo, total)
A fig. 7.1 mostra uma instncia da relao linha_de_crdito (esquema_linha_de_crdito). Uma tupla t da
relao linha_de_crdito tem o seguinte significado intuitivo:
t[fundos] so os fundos totais de uma determinada agncia cujo nome t[nome_agncia].
t[cidade_agncia] a cidade onde determinada agncia de nome t[nome_agncia] est localizada.
t[nmero_emprstimo] o nmero atribudo ao emprstimo feito na agncia denominada
t[nome_agncia] para o cliente de nome t[nome_cliente].
t[total] o montante da dvida do emprstimo cujo nmero t[nmero_emprstimo].

Suponha que desejamos adicionar um novo emprstimo ao nosso banco de dados. Digamos que o
175

emprstimo, no valor de 1,5 mil dlares, foi contrado na agncia Perryridge para o cliente Adams. O
nmero_emprstimo ser L-31. Em nosso projeto, precisamos de uma tupla com valores em todos os atributos do
esquema_linha_de_crdito. Assim, necessrio repetir os dados sobre fundos e cidade referentes agncia
Perryridge na adio da tupla
(Perryridge, Horseneck, 1700000, Adams, L-31, 1500)
na relao linha_de_crdito. De modo geral, dados sobre fundos e localizao da agncia devem aparecer toda
vez que um emprstimo contrado naquela agncia.
A necessidade de repetio de informaes imposta pelo nosso projeto alternativo indesejvel.
Repeties desperdiam espao. Alm disso, dificulta atualizaes no banco de dados. Suponha, por exemplo,
que a agncia Perryridge se mude de Horseneck para Newtown. Em nosso projeto original, uma tupla da relao
agncia ser alterada. Nesse projeto alternativo, diversas tuplas da relao linha_de_crdito devero sofrer
alteraes. Assim, as atualizaes sero mais custosas no novo projeto que no original. Quando realizarmos a
alterao no projeto alternativo, precisamos ter certeza de que todas as tuplas pertencentes agncia Perryridge
sero alteradas, seno nosso banco de dados ir apresentar duas cidades para a agncia Perryridge.
Essa observao fundamental para entender por que o projeto considerado ruim. Sabemos que uma
agncia bancria est localizada em apenas uma cidade, naturalmente. Por outro lado, sabemos que uma agncia
pode
conceder
diversos
emprstimos.
Em
outras
palavras,
a
dependncia
funcional
nome_agncia
cidade_agncia se realiza no esquema_linha_de_crdito, mas no esperamos que a dependncia
funcional pode ser usada para especificao formal quando o projeto de banco de dados bom.
Outro problema com o projeto esquema_linha_de_crdito que no podemos representar diretamente a
informao relativa a uma agncia (nome_agncia, cidade_agncia, fundos), salvo se houver ao menos um
emprstimo concedido pela agncia. O problema que as tuplas da relao linha_de_crdito exigem valores para
nmero_emprstimo, total e nome_cliente.
Uma soluo para esse problema introduzir valores nulos para tratar as atualizaes por meio de vises.
Recorde-se, entretanto, de que difcil trabalhar com valores nulos. Se no estamos dispostos a tratar com
valores nulos, ento s poderemos criar informaes sobre as agncias quando o primeiro emprstimo na
agncia for realizado. Pior, poderemos perder essa informao quando todos os emprstimos da agncia forem
pagos. Logicamente, essa situao impensvel, j que, em nosso projeto original, as informaes a respeito das
agncias esto disponveis independente de existirem ou no emprstimos mantidos pela agncia, e sem a
necessidade de usar valores nulos.
Decomposio
O exemplo de um maus projeto sugere que poderamos decompor um esquema de relao com diversos
atributos em vrios esquemas com diversos atributos em vrios esquemas com menor nmero de atributos.
Decomposies descuidadas, entretanto, podem gerar outro tipo de projeto de m qualidade.
Considere uma alternativa de projeto, em que esquema_linha_de_crdito decomposto nos dois
esquemas que se seguem:
esquema_agncia_cliente = (nome_agncia, cidade_agncia, fundos, nome_cliente)
esquema_cliente_emprstimo = (nome_cliente, nmero_emprstimo, total)
Usando a relao linha_de_crdito da fig. 7.1, construmos nossas novas relaes cliente_agncia
(esquema_agncia_cliente) e cliente_emprstimo (esquema_cliente_emprstimo), como se segue:

Mostramos as relaes resultados agncia_cliente e nome_cliente nas fig. 7.2 e 7.3, respectivamente.
Naturalmente, h casos em que precisamos reconstruir a relao emprstimo. Por exemplo, suponha que
desejamos encontrar todas as agncias que tenham emprstimos cujos totais sejam inferiores a mil dlares.
176

Nenhuma relao em nosso banco de dados alternativo contm esses dados. Precisamos reconstruir a relao
linha_de_crdito. Parece que podemos faz-lo escrevendo:

A fig. 7.4 mostra o resultado do processamento de agncia_cliente

cliente_emprstimo. Quando
comparamos essa relao e a primeira relao linha_de_crdito (fig. 7.1), notamos algumas diferenas. Embora
todas as tuplas que aparecem em linha_de_crdito apaream em agncia_cliente
h tuplas em agncia_cliente
exemplo, agncia_cliente

cliente_emprstimo,

cliente_emprstimo que no esto em linha_de_crdito. Em nosso

cliente_emprstimo tem as seguintes tuplas adicionais:

177

Considere a consulta encontre todas as agncias que tenham feito um emprstimo com totais menores
que mil dlares. Se olharmos a fig. 7.1, veremos que somente as agncias Mianus e Round Hill possuem totais de
emprstimo menores que mil dlares. Entretanto, quando aplicamos a expresso
obtemos trs nomes de agncias: Mianus, Round Hill e Downtown.
Examinaremos esse exemplo mais de perto. Se acontecer de um cliente contrariar vrios emprstimo em
diferentes agncias, no poderemos identificar a qual agncia pertence qual emprstimo. Assim, da juno de
agncia_cliente e cliente_emprstimo, no obtemos somente as tuplas que tnhamos originalmente em
linha_de_crdito, mas tambm diversas tuplas adicionais. Embora haja mais tuplas em agncia_cliente
cliente_emprstimo, temos, na verdade, menos informao. De qualquer modo, no poderemos representar nas
informaes do banco de dados quais clientes so devedores de quais agncias. Devido a essa perda de
informao, chamamos a decomposio do esquema_linha_de_crdito em esquema_agncia_cliente e
esquema_cliente_emprstimo de decomposio com perda (lossy decomposition), ou uma decomposio com
perda na juno (lossy-join decomposition). Quando a decomposio no implica perda de informao, ela
chamada decomposio sem perda na juno (lossless-join decomposition). Deve estar claro diante de nosso
exemplo que uma decomposio com perda na juno , em geral, uma m opo de projeto de banco de dados.
Examinaremos essa decomposio mais atentamente para descobrir por que ela representa perda. H um
atributo comum entre esquema_agncia_cliente e esquema_cliente_emprstimo:
O nico modo de representarmos um relacionamento entre, por exemplo, nmero_emprstimo e
nome_agncia por meio de nome_cliente. Essa representao no adequada, porque um cliente pode
contrair diversos emprstimos e, ainda, esses emprstimos no so necessariamente obtidos na mesma agncia.
Consideremos outra alternativa de projeto, na qual esquema_linha_de_crdito decomposta nos dois
esquemas seguintes:

H um atributo em comum entre os dois esquemas:

178

Assim, o nico modo de representar um relacionamento entre, por exemplo, nome_cliente e fundos por
meio de nome_agncia. A diferena entre esse exemplo e o precedente que o valor dos fundos de uma agncia
o mesmo, qualquer que seja o cliente em questo, enquanto a linha de crdito oferecida pela agncia,
especialmente no montante envolvido, depende do cliente em questo. Para um dado nome_agncia, h
exatamente um valor de fundos e exatamente uma cidade_agncia; j um tratamento similar no pode ser
oferecido para nome_cliente. Isto , a dependncia funcional:
nome_agncia
fundos cidade_agncia
realiza-se, mas nome_cliente no determina funcionalmente nmero_emprstimo.
A noo de juno sem perda fundamental para a maioria dos projetos de banco de dados. Portanto,
refaremos o exemplo anterior de modo mais precisa e mais formal. Seja R um esquema de relao. Um conjunto
de esquemas de relaes {R1, R2, ..., Rn} uma decomposio de R se:
Isto , {R1, R2, ..., Rn} uma decomposio de R se, para i = 1, 2, ..., n, cada Ri um subconjunto de R e
todo atributo de R aparece ao menos uma vez em Ri.
Seja r uma relao do esquema R, e seja ri =
para i=1,2,..., n. Isto , {r1, r2, ..., rn} o banco de dados
que resulta da decomposio de R em {R1, R2, ..., Rn}. Neste caso, sempre vlido:
Para verificar se essa declarao verdadeira, considere uma tupla t da relao r. quando computamos as
relaes r1, r2, ..., rn, a tupla t origina uma tupla ti em cada ri, i=1, 2, ..., n. Essas n tuplas podem ser combinadas
.
para reconstruir t quando computamos r1 r2 ... rn. Portanto, toda tupla em r aparece em

De modo geral, r
. Como ilustrao, considere nosso exemplo anterior, no qual:
n=2
R = esquema_linha_de_crdito
R1 = esquema_agncia_cliente
R2 = esquema_cliente_emprstimo
r = a relao mostrada na fig. 7.1.
r1 = a relao mostrada na fig. 7.2.
r2 = a relao mostrada na fig. 7.3.
r1
r2 = a relao mostrada na fig. 7.4.

Note que as relaes das fig. 7.1 a 7.4 no so as mesmas.

Para decomposies sem perda, precisamos impor restries ao conjunto das relaes possveis.
Conclumos
que
a
decomposio
do
esquema_linha_de_crdito
em
esquema_agncia
e
esquema_info_emprstimos ocorre sem perdas porque a dependncia funcional
nome_agncia
cidade_agncia fundos
realiza-se em esquema_agncia.
Seja C a representao de um conjunto de restries do banco de dados. Uma decomposio {R1, R2, ...,
Rn} do esquema de relao R uma decomposio sem perda na juno de R se para todas as relaes r no
esquema R vlido sob C:

Normalizao usando dependncias funcionais

Podemos usar um dado conjunto de dependncias funcionais para projetar um banco de dados relacional,
evitando a maior das propriedades no desejadas, j discutidas. Quando projetamos tais sistemas, pode tornar-se
desnecessrio decompor uma relao em diversas relaes menores. Usando a dependncia funcional, podemos
definir algumas formas normais que representam bons projetos de banco de dados.
179

Propriedades Desejveis da Decomposio

Podemos ilustrar nossos conceitos por meio do esquema_linha_de_crdito:

O conjunto de dependncias funcionais F que desejamos que se realizem para o

esquema_linha_de_crdito so:
nome_agncia
fundos cidade_agncia
nmero_emprstimo
total nome_agncia
O esquema_linha_de_crdito um exemplo de projeto ruim de banco de dados. Suponha que tenhamos
decomposto esse esquema nas trs relaes a seguir:
esquema_agncia= (nome_agncia, fundos, cidade_agncia)
esquema_emprstimo= (nome_agncia, nmero_emprstimo, total)
esquema_devedor= (nome_cliente, nmero_emprstimo)
Afirmamos que essa decomposio apresenta diversas propriedades desejveis.
Decomposio sem Perda na Juno
J sustentamos que, quando decompomos uma relao em outras relaes menores, crucial que a
decomposio no resulte em perda de informao. Afirmamos que a decomposio crucial que a
decomposio no resulte em perda de informao.
Seja R um esquema de relao e F um conjunto de dependncias funcionais sobre R. Sejam R1 e R2 formas
de decomposio de R. Essa decomposio uma decomposio sem perda na juno de R se ao menos uma das
seguintes dependncias funcionais est em F+:

Mostraremos agora que nossa decomposio para o esquema_linha_de_crdito uma decomposio

sem perda na juno mostrando uma sequncia de passos que geraram essa decomposio. Comecemos pela
decomposio do esquema_linha_de_crdito em dois esquemas:
esquema_agncia = (nome_agncia, cidade_agncia, fundos)
esquema_info_emprstimo = (nome_agncia, nome_cliente, nmero_emprstimo, total)
Uma vez que nome_agncia
cidade_agncia fundos, a regra incremental (augmentation) para a
dependncia funcional implica:
nome_agncia
nome_agncia cidade_agncia fundos
J que esquema_agncia
esquema_info_emprstimo = {nome_agncia}, ento nossa decomposio
inicial uma decomposio sem perda na juno.
A seguir, decomporemos esquema_info_emprstimo em:

Esse passo resulta em uma decomposio sem perda na juno, desde que nmero_emprstimo seja um
atributo comum e nmero_emprstimo
total nome_agncia.
Preservao da dependncia
Outra meta do projeto de um banco de dados relacional a preservao da dependncia. Quando ocorre
uma atualizao no banco de dados, o sistema deve checar se ele criar uma relao ilegal isto , uma relao
que no que no satisfaa todas as dependncias funcionais. Se checarmos de modo eficiente essas atualizaes,
180

poderemos projetar esquemas de banco de dados relacionais capazes de validar atualizaes sem necessidade de
junes.
Para decidir se uma juno ou no necessria, precisamos determinar quais dependncias funcionais
devem ser testadas, verificando cada uma das relaes individualmente. Seja F um conjunto de dependncias
funcionais de um esquema R e seja R1, R2, ..., Rn uma decomposio de R. A restrio de F para Ri o conjunto Fi
de todas as dependncias funcionais em F+ que contenha somente os atributos de Ri. J que todas as
dependncias funcionais em uma restrio contm atributos de apenas um esquema de relao, possvel testar
se tais dependncias so satisfeitas checando somente uma relao.
O conjunto de restries F1, F2, ..., Fn o conjunto das dependncias que podem ser checadas
eficientemente. Agora precisamos nos certificar de que suficiente testar somente as restries. Seja F =
. F um conjunto de dependncias funcionais do esquema R, mas, em geral, FF. Entretanto,
mesmo que FF, pode ser que F+=F+. Se o ltimo verdadeiro, ento toda a dependncia de F est
compreendida logicamente em F, e, se verificarmos que F satisfeita, podemos verificar que F tambm o .
Dizemos que uma decomposio decomposio com preservao da dependncia se possui a propriedade
F+=F+. A fig. 7.5 mostra um algoritmo para o teste da preservao da dependncia. A entrada o conjunto dos
esquemas das relaes decompostas D = {R1, R2, ..., Rn} e um conjunto de dependncias funcionais F.
Podemos agora mostrar que nossa decomposio do esquema_linha_de_crdito uma decomposio
com preservao de dependncia. Consideramos cada membro do conjunto F das dependncias funcionais que
desejamos impostas sobre esquema_linha_de_crdito e mostraremos que cada uma pode ser testada em ao
menos uma relao da decomposio.
Podemos testar a dependncia funcional: nome_agncia
cidade_agncia fundos usando
esquema_agncia= (nome_agncia, cidade_agncia, fundos).
Podemos testar a dependncia funcional: nmero_emprstimo
total nome_agncia usando
esquema_emprstimo= (nome_agncia, nmero_emprstimo, total).
Como no exemplo mostrado anteriormente, frequentemente mais fcil no aplicar o algoritmo da fig.
7.5 para o teste da preservao da dependncia, j que o primeiro passo, o processamento de F+, toma tempo
exponencial.

Redundncia de Informaes
A decomposio do esquema_linha_de_crdito no sofre o problema da repetio da informao que foi
discutido anteriormente. No esquema_linha_de_crdito necessrio repetir, em cada emprstimo, a cidade e os
fundos relativos agncia.

181

A decomposio separa os dados a respeito da agncia e do emprstimo em relaes distintas

eliminando, desse modo, a redundncia. Similarmente, observe que, se um nico emprstimo feito para
diversos clientes, repetiremos o total do emprstimo para cada um dos clientes (assim como a cidade e os fundos
da agncia). Na decomposio, a relao do esquema esquema_devedor contm o relacionamento
nmero_do_emprstimo e nome_do_cliente que nenhum outro esquema contm.
Temos, portanto, somente na relao do esquema esquema_devedor contm o relacionamento
nmero_do_emprstimo e nome_do_cliente que nenhum outro esquema contm.
Temos, portanto, somente na relao do esquema esquema_devedor, uma tupla para cada cliente com
um emprstimo. Nas outras relaes que contm o atributo nmero_emprstimo (as dos esquemas
esquema_emprstimo, e esquema_devedor) aparece somente uma tupla por emprstimo.
Evidentemente, desejvel a ausncia de redundncia mostrada nessa decomposio. O grau alcanado
por essa ausncia de redundncia representado pelas diversas formas normais.
Forma Normal de Boyce-Codd
Uma das mais procuradas formas normais a forma normal de Boyce-Codd (FNBC). Uma relao do
esquema R est na FNBC com respeito a um conjunto F de dependncias funcionais se para todas as
dependncias funcionais em F+ da forma
, em que R e R, ao menos uma das seguintes realiza-se:

uma dependncia funcional trivial (isto , ).
uma superchave para o esquema R.
Um projeto de banco de dados est na FNBC se cada membro do conjunto de relaes dos esquemas que
constituem o projeto est na FNBC.
Como exemplo, consideremos os seguintes esquemas de relaes e suas respectivas dependncias
funcionais:

Afirmamos que o esquema_cliente est na FNBC. Notamos que uma chave candidata para o esquema
nome_cliente. A nica dependncia funcional no trivial no que se realiza no esquema_cliente tem nome_cliente
chave candidata, dependncias funcionais com nome_cliente do lado esquerdo da seta no violam a definio
da FNBC. Analogamente, pode-se mostrar facilmente que a relao do esquema esquema_agncia est na FNBC.
O esquema esquema_info_emprstimo, entretanto, no est na FNBC. Primeiro, note que
nmero_emprstimo no superchave do esquema_info_emprstimo, j que poderia haver um par de tuplas
representando um nico emprstimo adquirido por duas pessoas por exemplo:

Como no fizemos a lista das dependncias funcionais que no so admitidas no caso precedente,
nmero_emprstimo no uma chave candidata. Entretanto, a dependncia funcional
nmero_emprstimo
total no trivial. Portanto, esquema_info_esquema no satisfaz a definio FNBC.
Afirmamos que o esquema_info_emprstimo no conveniente, uma vez que est sujeito ao problema
de informaes redundantes j descrito. Observemos que, se existir diversos nomes de clientes associados a um
emprstimo, em uma relao do esquema_info_emprstimo, ento somos foradas a repetir o nome da agncia
e o total do emprstimo a cada cliente.
182

Podemos eliminar essa redundncia redesenhando nosso banco de dados de modo que todos os
esquemas estejam em FNBC. Uma abordagem para esse problema tomar um projeto que no est na FNBC
como ponto de partida e decompor os esquemas necessrios. Considere a decomposio do
esquema_info_emprstimo em dois outros esquemas:

Essa decomposio uma decomposio sem perda na juno.

Para determinar se esses esquemas esto na FNBC, precisamos determinar quais dependncias funcionais
se aplicam a elas. Nesse exemplo, fcil perceber que:
nmero_emprstimo
total nome_agncia
aplica-se a esquema_emprstimo e que somente dependncias funcionais aplicam-se a esquema_devedor.
Embora nmero_emprstimo no seja uma superchave para esquema_info_emprstimo, ele chave candidata
para esquema_emprstimo. Assim, ambos os esquemas de nossa decomposio esto em FNBC.
Assim, possvel evitar redundncia quando h diversos clientes associados a um nico emprstimo. H
exatamente uma tupla para cada emprstimo na relao do esquema_emprstimo e uma tupla para cada
emprstimo de cada cliente na relao do esquema_devedor. Logo, no precisamos repetir o nome da agncia e
o total para cada cliente associado a um emprstimo.
Podemos agora determinar um mtodo geral para criar uma coleo de esquemas na FNBC. Se R no est
na FNBC, podemos decompor R em um grupo de esquemas R1, R2, ..., Rn na FNBC usando o algoritmo da fig. 7.6,
que no s gera decomposies na FNBC, como todas as decomposies sem perda na juno. Para perceber por
que nosso algoritmo gera somente decomposies sem perda na juno, note que, quando substitumos um
esquema Ri por (Ri ) e (,), a dependncia
realiza-se e

Vejamos a aplicao do algoritmo de decomposio FNBC no esquema_linha_de_crdito que usamos

anteriormente como exemplo de um projeto deficiente de banco de dados:
esquema_linha_de_crdito = (nome_agncia, cidade_agncia, fundos, nome_cliente, nmero_emprstimo, total)
O conjunto de dependncias funcionais que exigimos que se realizem so:

Uma chave candidata para esse esquema {nmero_emprstimo, nome_cliente}.

Aplicamos o algoritmo da fig. 7.6 para o exemplo com esquema_linha_de_crdito, conforme segue:
A dependncia funcional nome_agncia
fundos cidade_agncia
realiza-se no esquema_linha_de_crdito, mas nome_agncia no uma superchave.
Assim, esquema_linha_de_crdito no est na FNBC. Substitumos o esquema_linha_de_crdito por:

183

A nica dependncia funcional no trivial que se realiza no esquema_agncia contm nome_agncia no

lado esquerdo da seta. Uma vez que nome_agncia uma chave para o esquema_agncia, a relao
esquema_agncia est na FNBC.
A dependncia funcional
nmero_emprstimo
total nome_agncia
realiza-se no esquema_info_emprstimo, mas nmero_emprstimo no chave para o
esquema_info_emprstimo. Substitumos esquema_info_emprstimo por:

esquema_emprstimo e esquema_devedor esto na FNBC.

Assim, a decomposio do esquema_linha_de_crdito resulta nos trs esquemas de relaes

esquema_agncia, esquema_emprstimo, e esquema_devedor, cada um dos quais na FNBC. Esses esquemas de
relao so os mesmos j usados anteriormente.
Nem toda decomposio na forma FNBC tem dependncia preservada. Considere a seguinte relao:
esquema_bancrio= (agncia_nome, nome_cliente, nome_bancrio)
que informa que um cliente possui atendimento personalizado, de responsabilidade de um bancrio
determinado, em uma dada agncia. O conjunto F de dependncias funcionais necessrias ao esquema_bancrio
so:

Naturalmente, esquema_bancrio no est na FNBC, uma vez que nome_bancrio no uma superchave.
Se aplicarmos o algoritmo da fig. 7.6, obtemos a seguinte decomposio em FNBC:

A decomposio dos esquemas preserva somente nome_bancrio
nome_agncia (e as dependncias

triviais), mas a clausura {nome_bancrio
nome_agncia} no engloba nome_cliente nome_agncia

nome_bancrio. Uma violao dessa dependncia pode ser detectada somente por meio de uma juno.
Para verificar se a decomposio de esquema_bancrio nos esquemas esquema_bancrio_agncia e
esquema_cliente_bancrio no acontece com preservao da dependncia, aplicamos o algoritmo da fig. 7.5.
Consideremos que as restries F1 e F2 de F para cada um dos esquemas so:

Assim, uma cobertura cannica para o conjunto F F1.

fcil perceber que a dependncia funcional nome_cliente nome_agncia
nome_bancrio no est
+
em F mesmo que esteja em F+. Portanto, F+F+ e a decomposio no preserva a dependncia.
O exemplo precedente demostra que nem toda decomposio FNBC preserva a dependncia. Alm disso,
ela demonstra que nem sempre as trs metas de projeto podem ser satisfeitas:
1. FNBC
2. Sem perda na juno
3. Preservao da dependncia
No podemos realiza-las neste exemplo porque toda decomposio FNBC do esquema_bancrio falha na
preservao de nome_cliente nome_agncia
nome_bancrio.
184

Terceira Forma Normal

Nos caos em que no conseguimos alcanar todos os trs critrios de projeto, abandonamos FNBC e
aceitamos uma forma normal mais fraca chamada terceira forma normal (3FN). Vemos que sempre possvel
alcanar decomposio sem perda na juno, decomposio com preservao da dependncia que est na 3FN.
A FNBC exige que todas as dependncias no triviais sejam da forma
, em que uma superchave. A
3FN suaviza essa restrio permitindo dependncias funcionais no-triviais cujo lado esquerdo da seta no seja
superchave.
Um esquema de relao R est na 3FN com respeito a um conjunto de dependncias funcionais F se, para
todas as dependncias funcionais F+ da forma
, em que R e R, ao menos uma das seguintes
condies for realizada:

uma dependncia funcional trivial.
uma superchave de R.
Cada atributo de A em est contido em uma chave candidata de R.
A definio da 3FN permite algumas dependncias funcionais que no so permitidas na FNBC. A
dependncia
, que satisfaz apenas a terceira condio da definio da 3FN, no permitida na FNBC, mas
permitida na 3FN. Essas dependncias so um exemplo de dependncias transitivas.
Observe que, se um esquema de relao est na FNBC, ento todas as dependncias funcionais so da
forma superchave determina um conjunto de atributos, ou a dependncia trivial. Assim, um esquema FNBC
no pode conter nenhuma dependncia transitiva. Como resultado, todo esquema FNBC tambm da 3FN, e a
FNBC, portanto, mantm regras mais restritivas que a 3FN.
Retornemos ao nosso exemplo do esquema_bancrio. Mostramos que esse esquema de relao no tem
a dependncia preservada, com decomposio sem perda da juno em FNBC. Esse esquema, entretanto, sai da
3FN. Para essa verificao, notamos que {nome_cliente, nome_agncia} uma chave candidata para
esquema_bancrio, assim o nico atributo no contido em chave candidata de esquema_bancrio
nome_bancrio. As nicas dependncias funcionais no-triviais da forma
nome_bancrio incluem
{nome_cliente, nome_agncia} como parte de . J que {nome_cliente, nome_agncia} chave candidata, essas
dependncias no violam a definio da 3FN.
A fig. 7.7 mostra um algoritmo para chegar preservao de dependncia, com decomposio sem perda
na juno em 3FN. O fato de cada esquema de relao Ri estar na 3FN decorre diretamente de nossa exigncia de
que o conjunto de dependncias funcionais F seja da forma cannica. O algoritmo assegura a preservao das
dependncias explicitando um esquema para cada dependncia. Ele assegura que a decomposio sem perda
na juno por meio da garantia de que ao menos um esquema contm uma chave candidata para o esquema que
est sendo decomposto.
Para ilustrar o algoritmo da fig. 7.7 consideramos a seguinte extenso do esquema_bancrio:
esquema_info_bancrio= (nome_agncia, nome_cliente, nome_bancrio, nmero_seo)
A principal diferena aqui que inclumos o nmero da seo do bancrio como parte da informao. As
dependncias funcionais para esse esquema de relao so:

Uma vez que esquema_bancrio contm uma chave candidata para o esquema_info_bancrio,
terminamos o processo de decomposio.

185

Comparao entre FNBC e 3FN

Vimos duas formas normais de esquemas de banco de dados relacionais: 3FN e FNBC. Uma vantagem de
um projeto na 3FN saber que sempre possvel obt-la sem sacrificar uma decomposio sem perda na juno
ou preservao da dependncia. Apesar disso, h uma desvantagem na 3FN. Se no a eliminarmos todas as
dependncias transitivas, teremos de usar valores nulos para representao de alguns dos possveis
relacionamentos significativos entre itens de dados, e h ainda o problema da repetio da informao.
Como ilustrao, considere novamente o esquema_bancrio e suas dependncias funcionais associadas.
Dado nome_bancrio
nome_agncia, podemos desejar representar em nosso banco de dados relacionamentos
entre valores de nome_bancrio e valores de nome_agncia. No entanto, se fizermos isso, ser preciso ter um
valor correspondente para nome_cliente ou usar valores nulos para o atributo nome_cliente.
Outra dificuldade com esquema_bancrio a repetio da informao. Como ilustrao, considere uma
instncia de esquema_bancrio mostrada na fig. 7.8. Note que a informao de que Johnson est trabalhando na
agncia Perryridge repetida.

Se formos forados a escolher entre FNBC e preservao da dependncia com 3FN, geralmente
prefervel optar pela 3FN. Se no pudermos verificar eficientemente a preservao da dependncia, termos de
pagar alto custo em desempenho do sistema ou corremos riscos em relao integridade de dados de nosso
banco de dados. Nenhuma dessas opes atraente. Com tais alternativas, o limite redundncia imposto pelas
dependncias transitivas sob a 3FN o menos pior. Assim, normalmente optamos por manter a preservao da
dependncia e sacrificar a FNBC.
Em resumo, repetimos que as trs metas de projeto para um banco de dados relacional so:
1. FNBC
186

2. Juno sem perda

3. Preservao da dependncia
Se no pudermos alcanar as trs, aceitamos:
1. 3FN
2. Juno sem perda
3. Preservao da dependncia
Normalizao usando Dependncias Multivaloradas
H esquemas de relao na FNBC que no esto normalizados o bastante, no sentido de que eles ainda
sofrem de problemas de repetio de informao. Considere novamente nosso exemplo relativo ao banco.
Assuma que, como alternativa de projeto para o esquema de um banco de dados de uma empresa na rea
bancria, tenhamos o esquema:
esquema_BC = (nmero_emprstimo, nome_cliente, rua_cliente, cidade_cliente)
Podemos perceber que esse esquema no est na FNBC por causa da dependncia funcional
nome_cliente
rua_cliente cidade_cliente
que afirmamos anteriormente, e porque nome_cliente no uma chave do esquema_BC. Entretanto,
consideremos que nosso banco est atraindo clientes ricos que possuem diversos endereos (digamos, casa de
inverno e casa de vero). Ento, no desejaremos mais a dependncia funcional nome_cliente
rua_cliente
cidade_cliente. Se retirarmos essa dependncia funcional, concluiremos que o esquema_BC est na FNBC com
respeito ao nosso conjunto de dependncias funcionais modificadas. Ainda, mesmo que o esquema_BC esteja na
FNBC com respeito ao nosso conjunto de dependncias funcionais modificadas. Ainda, mesmo que o
esquema_BC esteja na FNBC, ns teremos o problema da repetio de informaes que tnhamos anteriormente.
Para tratar esse problema, precisamos definir uma nova forma de restrio, chamada dependncia
multivalorada. Como fizemos com as dependncias funcionais, usaremos as dependncias funcionais
multivaloradas para definir uma forma normal para os esquemas das relaes. Essa forma normal, chamada
quarta forma normal (4FN), mais restritiva que a FNBC. Podemos ver que todo esquema na 4FN est tambm na
FNBC, mas h esquemas na FNBC que no esto na 4FN.
Dependncias Multivaloradas
As dependncias funcionais rejeitam certas tuplas como participantes de uma relao. Se A
B, ento
no podemos ter duas tuplas com os mesmos valores de A, mas diferentes valores de B. Dependncias
multivaloradas no rejeitam a existncia de certas tuplas. Pelo contrrio, elas exigem que outras tuplas, de uma
certa forma, estejam presentes na relao. Por essa razo, por vezes, as dependncias funcionais so chamadas
dependncias geradas por igualdade (equality-generating dependencies) e dependncias multivaloradas so
referidas como dependncias geradas por tuplas (tuple-generating dependencies).
Seja R um esquema de relao e seja R e R. A dependncia multivalorada

realiza-se em R
se, para qualquer relao r(R), para todos os pares de tuplas t1 e t2 de r, tal que t1[] =t2 [], existem tuplas t3 e t4
em r tal que

Essa definio menos complexa do que parece. Na fig. 7.9, damos uma apresentao tabular para t1, t2,
t3 e t4. Intuitivamente, a dependncia multivalorada

diz que um relacionamento entre e
independente do relacionamento entre e R . Se uma dependncia multivalorada

satisfeita para
todas as relaes do esquema R, ento

uma dependncia multivalorada trivial do esquema R. Assim,


trivial se =R.
187

Para ilustrar as diferenas entre dependncia funcional e multivalorada, consideremos novamente o

esquema_BC e a relao bc (esquema_BC) da fig. 7.10. Precisamos repetir o nmero do emprstimo de um
mesmo cliente. Essa repetio desnecessria, j que o relacionamento entre o cliente e seu endereo
independente do relacionamento entre o cliente e um emprstimo. Se um cliente (digamos, Smith) tem um
emprstimo (digamos, o de nmero L-23), queremos que o emprstimo seja associado a todos os endereos de
Smith. Assim, a relao da fig. 7.11 no validade. Para tornar essa relao vlida, precisamos adicionar as tuplas
(L-23, Smith, Main, Manchester) e (L-27, Smith, North, Rye) relao bc da fig. 7.11.

Comparando o exemplo anterior com nossa definio de dependncia multivalorada, percebemos que
desejamos que a dependncia multivalorada nome_cliente

rua_cliente cidade_cliente se realize (a
dependncia multivalorada nome_cliente

nmero_emprstimo faz a mesma coisa. Assim, verificamos que
so equivalentes).
Como fizemos para as dependncias funcionais, podemos usar a dependncia multivalorada de dois
modos:
1. Para testar relaes para determinar se elas so validades sob um dado conjunto de dependncias
funcionais e multivaloradas.
2. Para especificar restries sobre um conjunto de relaes vlidas; devemos, assim, nos restringir somente
quelas relaes que satisfazem um dado conjunto de dependncias funcionais e multivaloradas.
Note que, se uma relao r no satisfaz uma dada dependncia multivalorada, podemos criar uma relao r que
satisfaa a dependncia multivalorada adicionando tuplas a r.
Teoria das Dependncias Multivaloradas
Como foi feito para a dependncia funcional, para 3FN e para FNBC, precisamos determinar todas as
dependncias multivaloradas que esto logicamente implcitas em um dado conjunto de dependncias
multivaloradas.
Adotamos o mesmo enfoque tomado anteriormente para as dependncias funcionais. Seja D um
conjunto de dependncias funcionais e multivaloradas. A clausura D+ de D o conjunto de todas as dependncias
188

funcionais e multivaloradas logicamente implcitas em D. Como fizemos para as dependncias funcionais,

podemos computar D+ por meio de D, usando a definio formal de dependncias funcionais e dependncias
multivaloradas. Entretanto, normalmente mais fcil ponderar acerca de conjuntos de dependncias
multivaloradas. Entretanto, normalmente mais fcil ponderar acerca de conjuntos de dependncias usando um
sistema de regras de inferncias.
A seguinte lista de regras de inferncias para dependncias funcionais e dependncias multivaloradas
slida e completa. Recorde que as regras para solidez no criam qualquer dependncia que no esteja
logicamente implcita em D e regras completas permite-nos criar todas as dependncias em D+.

Seja R= (A, B, C, G, H, I) um esquema de relao. Suponha que A

BC realiza-se. A definio de

dependncia multivalorada implica que, se t1[A] = t2[A], ento existem as tuplas t3 e t4 tal que:

A regra de complementao coloca que, se A

BC, ento A

GHI. Observe que t3 e t4 satisfazem a
definio de que A

GHI simplesmente mudando os subescritos.
Podemos proporcionar uma justificativa similar para as regras 5 e 6 usando a definio de dependncia
multivalorada.
Regra 7, a regra da replicao, envolve dependncias funcionais e multivaloradas. Suponha que A
BC
realiza-se em R. Se t1[A] =t2[A] e t1[BC] =t2[BC], ento as prprias t1 e t2 podem ser as tuplas t3 e t4 exigidas na
definio da dependncia multivalorada A

BC.
Regra 8, a regra da coalescncia, a mais difcil de se verificar entre as oito regras.
Podemos simplificar a computao da clausura de D usando as seguintes regras, as quais podemos provar
usando as regras 1 a 8.
Regra da unio multivalorada. Se

e

realizam-se, ento
tambm realiza-se.
Regra da interseo. Se

e

realizam-se, ento

realiza-se.
Regra da diferena. Se

e

realizam-se, ento

realiza-se e

realiza-se.
Apliquemos nossas regras no seguinte exemplo. Seja R = (A, B, C, G, H, I) com o seguinte conjunto de
dependncias D dado:

Relacionamos alguns membros de D+ aqui:

189

A

CGHI: desde que A

B, a regra da complementao (regra 4) implica que A

R B A, R B
A = CGHI, assim A

CGHI.
A

HI: desde que A

B e B

HI, a regra da transitividade multivalorada (regra 6) implica que
A

HI B. Desde que HI B = HI, A

HI.
B
H: para mostrar isso, precisamos aplicar a regra da transitividade multivalorada (regra 6) implica que
A

HI B. Desde que HI B = HI, A

HI.
B
H: para mostrar isso, precisamos aplicar a regra da coalescncia (regra 8). B
HI realiza-se. Desde que
H HI e CG
H e CG HI = , satisfazemos a regra da coalescncia, com estando em B, estando em
HI, estando em CG e estando em H. Conclumos que B
H.
A

CG: tambm sabemos que A

CGHI e A

HI. Pela regra da diferena, A

CGHI. Desde que
CGHI HI = CG. A
CG.

Quarta Forma Normal

Retornemos a nosso exemplo esquema_BC no qual a dependncia multivalorada nome_cliente


rua_cliente cidade_cliente realiza-se, mas nenhuma dependncia funcional no-trivial realiza-se. Vimos
anteriormente que, embora esquema_BC esteja na FNBC, o projeto no adequado, uma vez que precisamos
repetir as informaes acerca do endereo do cliente a cada emprstimo. Podemos ver que possvel usar a
dependncia multivalorada dada para melhorar o projeto do banco de dados, por meio da decomposio
esquema_BC em uma decomposio na quarta forma normal (4FN).
Um esquema de relao R est na 4FN com respeito a um conjunto D de dependncias funcionais e
multivaloradas se, para todas as dependncias multivaloradas em D+ da forma

, em que R e R, ao
menos uma das seguintes condies se realize:


uma dependncia multivalorada trivial.
uma superchave para o esquema R.
Um projeto de banco de dados est na 4FN se cada membro do conjunto dos esquemas de relaes que
constituem o projeto estiver na 4FN.
Note que a definio da 4FN difere da definio da FNBC somente no uso de dependncias multivaloradas
em vez de dependncias funcionais. Todo esquema na 4FN est na FNBC.
Para constatar esse fato, notamos que, se um esquema R no est na FNBC, ento h uma dependncia
funcional no-trivial
realizando-se em R, na qual no superchave. Desde que
implica que


(pela regra da replicao), R no poder estar na 4FN.
A analogia entre 4FN e FNBC aplica-se ao algoritmo para a decomposio de um esquema para a 4FN. A
fig. 7.12 mostra o algoritmo para a decomposio na 4FN. Ele idntico ao algoritmo de decomposio para FNBC
mostrado na fig. 7.6, exceto pelo fato de usar dependncia multivalorada em vez da dependncia funcional.
Se aplicarmos o algoritmo da fig. 7.12 para o esquema_BC, conclumos que nome_cliente


nmero_emprstimo uma dependncia multivalorada no-trivial e nome_cliente no uma superchave para o
esquema_BC pelos dois esquemas:
esquema_devedor = (nome_cliente, nmero_emprstimo)
esquema_cliente = (nome_cliente, rua_cliente, cidade_cliente)
Esse par de esquemas, que esto na 4FN, eliminam o problema encontrado anteriormente em relao
redundncia do esquema_BC.
Como no caso em que tratamos somente das dependncias funcionais, estamos interessados em
decomposies sem perda na juno e com preservao das dependncias. Os fatos seguintes sobre
dependncias multivaloradas e sem perda na juno mostram que o algoritmo da fig. 7.12 cria somente
decomposies sem perda na juno:

190

Seja o esquema de relao R e seja D um conjunto de dependncias funcionais e multivaloradas de R. Seja

R1 e R2 decomposies de R. Esta decomposio sem perda na juno de R se e somente se ao menos
uma das seguintes dependncias multivaloradas estiver em D+:

Lembre-se de que estabelecemos anteriormente que, se R1 R2
R1 ou R1 R2
R2, ento R1 e R2 so

decomposies sem perda na juno de R. O fato precedente ressalta que as dependncias multivaloradas
constituem uma forma mais genrica de juno sem perda. Ele indica que, para toda decomposio sem perda na
juno de R em dois esquemas R1 e R2, uma das duas dependncia R1 R2

R1 ou R1 R2
R2 deve se realizar.
A questo da preservao da dependncia quando temos dependncia multivalorada no to simples
quanto quando temos somente dependncias funcionais. Seja R um esquema de relao e sejam R1, R2, ..., Rn
decomposies de R. Lembre-se de que, para um conjunto de dependncias funcionais F, a restrio F1 de F para
Ri so todas as dependncias funcionais em F+ que incluem somente atributos de Ri. Agora, consideremos um
conjunto D, tanto de dependncias funcionais quanto de dependncias multivalorados. A restrio de D para R1
o conjunto Di, consistindo:
Todas as dependncias funcionais em D+ que incluem somente atributos de Ri.
Todas as dependncias multivaloradas da forma.

Ri em que

Ri e

est em D+.

Uma decomposio do esquema R nos esquemas R1, R2, ..., Rn uma decomposio com preservao da
dependncia com respeito ao conjunto D de dependncias funcionais e multivaloradas se, para todo conjunto de
relaes r1(R1), r2(R2), ..., rn (Rn), tal que, para todo i, ri satisfaa Di, l houver uma relao r(R) que satisfaa D e
para qual ri= Ri(r) para todo i.
Apliquemos o algoritmo para decomposio na 4FN da fig. 7.12 em nosso exemplo de R = (A, B, C, G, H, I)
com D = {A

B, B

HI, CG
H}. Podemos, ento, testar a decomposio resultante em relao preservao
da dependncia.
R no est na 4FN. Observe que A

B no trivial, ainda A no uma superchave. Usando A

B na
primeira iterao do while, substitumos R por dois esquemas, (A, B) e (A, C, G, H, I). fcil perceber que (A,B)
est na 4FN desde que todas as dependncias multivaloradas que valem em (A, B) sejam triviais. Entretanto, o
esquema (A, C, G, H, I) no est na 4FN. Aplicando a dependncia multivalorada CG

H (que decorre na
dependncia funcional dada CG

H pela regra da replicao), substitumos (A, C, G, H, I) pelos dois esquemas,
(C, G, H) e (A, C, G, I). O esquema (C, G, H) est na 4FN, mas o esquema (A, C, G, I) no est. Para perceber que (A,
C, G, I) no est na 4FN, lembremos que foi mostrado anteriormente que A

HI est em D+. Portanto, A

I
est na restrio de D para (A, C, G, I). Assim, na terceira iterao do lao while, substitumos (A, C, G, I) pelos dois
esquemas (A, I) e (A, C, G). O algoritmo ento termina e a decomposio 4FN {(A, B), (C, G, H), (A, I), (A, C, G)}.
191

Essa decomposio para a 4FN no preserva a dependncia, uma vez que ela falha na preservao da
dependncia multivalorada B

HI. Considere a fig. 7.13m que mostra as quatro relaes que poderiam resultar
da projeo de uma relao em (A, B, C, G, H, I) nos quatro esquemas de nossa decomposio. A restrio de D
para (A, B) A

B e algumas dependncias triviais. fcil perceber que r1 satisfaz A

B porque no h
nenhum par de tuplas com o mesmo valor de A. Observe que r2 tenha os mesmos valores em qualquer atributo.
Um comando similar pode ser feito para r3 e r4. Portanto, a verso decomposta de nosso banco de dados satisfaz
a todas as dependncias da restrio de D. Entretanto, no h nenhuma relao r em (A, B, C, G, H, I) que
. A relao
satisfaa D e possa ser decomposta em r1, r2, r3 e r4. A fig. 7.14 mostra a relao r =
r no satisfaz B

HI. Qualquer relao s contendo r e satisfazendo B

HI deve incluir a tupla (a2, b1, c2, g2, h1,
i1). Entretanto, CGH(s) inclui uma tupla (c2, g2, h1) que no est em r2. Assim, nossa decomposio falha da
deteco da violao de B

HI.

Vimos que, se estamos definindo um conjunto de dependncias funcionais e multivaloradas, vantajoso

chegar a um projeto de banco de dados que tenha como critrios:
1. 4FN
2. Preservao de dependncia
3. Juno sem perda
Se tudo o que tivermos forem dependncias funcionais, ento o primeiro critrios ser apenas a FNBC.
Vimos tambm que nem sempre possvel alcanar todas as trs condies. Obtivemos sucesso na
decomposio do exemplo do banco, mas falhamos no exemplo do esquema R= (A, B, C, G, H, I).
Quando no conseguimos alcanar as trs metas, abrimos mo da 4FN aceitando FNBC ou mesmo 3FN, se
necessrio, assegurando a preservao da dependncia.
Normalizao usando dependncias na Juno

192

Vimos que a propriedade sem perda na juno uma das diversas propriedades para o projeto de um
banco de dados. De fato, essa propriedade essencial: sem ela, h perda de informao. Quando restringimos o
conjunto das relaes vlidas entre as que satisfazem um conjunto de dependncias funcionais e multivaloradas,
podemos usar essas dependncias para mostrar que certas decomposies so decomposies sem perda na
juno.
Por causa da importncia desse conceito de sem perda na juno, til conseguir restringir um
conjunto de relaes vlidas sobre uma esquema R para aquelas relaes para as quais uma dada decomposio
uma decomposio sem perda na juno. Vamos agora definir o que dependncia de juno. Apenas como
tipos de dependncias conduzidas por outras formas normais, dependncias de juno sero direcionadas a uma
forma normal chamada forma normal de projeo de juno Project-join normal form (FNPJ).
Dependncias de juno (Join Dependencies)
Seja R um esquema de relao e R1, R2, ..., Rn seja uma decomposio de R. A dependncia de juno *
(R1, R2, ..., Rn) usada para restringir o conjunto de relaes legais para aquelas para as quais R1, R2, ..., Rn uma
decomposio sem perda na juno de R. Formalmente, se R=
, dizemos que uma relao r(R)
satisfaz a dependncia de juno * (R1, R2,..., Rn) se:
Uma dependncia de juno trivial se um dos Ri for o prprio R.
Considere a dependncia de juno *(R1, R2) do esquema R. Essa dependncia exige que, para toda
r(R)vlida:
Seja r contendo duas tuplas t1 e t2, conforme segue:

Assim, t1[R1

R2]=t2[R1

R2], mas t1 e t2 tm diferentes valores em todos os outros atributos.

Computemos
. A fig. 7.15 mostra
e
. Quando computamos a juno, temos duas
tuplas, alm de t1 e t2, exigidas na fig. 7.16 por t3 e t4.
Se *(R1, R2) vale, ento, sempre que tivermos as tuplas t1 e t2, devemos tambm ter t3 e t4. Assim, a fig.
7.16 mostra uma representao tabular da dependncia de juno *(R1, R2). Compare a fig. 7.16 com a fig. 7.9, na
qual temos a representao tabular de

. Se tivermos
e =R1, podemos ver que as duas
representaes tabulares nessas figuras so as mesmas. De fato, *(R1, R2) apenas um outra forma de determinar
. Usando as regras da complementao e do incremento para dependncias multivaloradas,
podemos mostrar que


R1 implica


R2. Assim, *(R1, R2) equivalente a


R2. Essa
observao no causa surpresa tendo em vista que, conforme observamos anteriormente, R1 e R2 formam uma
decomposio de R sem perda na juno se, e somente se,

193

R2 ou

R1.

Toda dependncia de juno da forma *(R1, R2) , portanto, equivalente a uma dependncia
multivalorada. No entanto, h dependncias de juno que no so equivalentes a nenhuma dependncia
multivalorada. O exemplo mais simples desse tipo de dependncia o esquema R=(A, B, C). A dependncia de
juno: *((A, B), (B, C), (A, C))
no equivalente a nenhuma coleo de dependncias multivaloradas. A fig. 7.17 mostra uma representao
tabular dessa dependncia de juno. Para notar que nenhum conjunto de dependncias multivaloradas
implicam logicamente *((A, B), (B, C), (A, C)), consideramos a fig. 7.17 como uma relao r(A, B, C), como mostra a
fig. 7.18.

A relao r satisfaz a dependncia de juno *((A, B), (B, C), (A, C)), como podemos verificar computando:
e mostrando que o resultado exatamente r. Entretanto, r no satisfaz qualquer dependncia multivalorada notrivial. Para percebemos isso, verificamos que r no satisfaz nenhuma das A

B, A

C, B

A, B

C,
C

A, ou C

B.

194

Da mesma forma que a dependncia multivalorada um modo de estabelecer a independncia de um

par de relacionamentos, uma dependncia de juno um modo de estabelecer que os membros de um conjunto
de relacionamentos so todos independentes. Essa noo de independncia de relacionamentos consequncia
natural do modo pelo qual geralmente definimos uma relao. Considere:
esquema_info_emprstimo=(nome_agncia, nome_cliente, nmero_emprstimo, total)
de nosso exemplo bancrio. Podemos definir uma relao info_emprstimo (esquema_info_emprstimo) com o
conjunto de todas as tuplas do esquema_info_emprstimo) com o conjunto de todas as tuplas do
esquema_info_emprstimo, tal que:
O emprstimo representado por nmero_emprstimo feito pela agncia de nome nome_agncia.
O emprstimo representado por nmero_emprstimo feito pelo cliente chamado nome_cliente.
O emprstimo representado por nmero_emprstimo est no total de nome total.
A definio anterior da relao info_emprstimo uma conjugao de trs predicados: um em
nmero_agncia e nome_agncia, um em nmero_emprstimo e nome_cliente e um em nmero_emprstimo e
total.
Supreendentemente, pode ser mostrado que a definio intuitiva anterior de info_emprstimo implica
logicamente a dependncia de juno *((nmero_emprstimo, nome_agncia), (nmero_emprstimo,
nome_cliente), (nmero_emprstimo, total)).
Assim, as dependncias de juno tm um aspecto intuitivo e correspondem a um dos trs critrios
apresentados para um bom projeto de banco de dados.
Para dependncias funcionais e multivaloradas, temos de fornecer um sistema de regras de inferncias
que devem ser vlidas e completas. Infelizmente, nenhum conjunto de regras conhecido para dependncias de
junes. Esse fato nos leva a considerar classes mais genricas de dependncias que as dependncias de junes
para construir um conjunto de regras de inferncias slido e completo.

Forma Normal de Projeo de Juno

Forma normal de projeo de juno (FNPJ) definida de maneira similar a FNBC e a 4FN, exceto pelo
fato das dependncias de junes serem usadas. Um esquema de relao r est em FNPJ com respeito a um
conjunto D de dependncias funcionais, multivaloradas e de juno se, para todas as dependncias de junes
ReR=
, ao menos uma das seguintes for
em D+ na forma *(R1, R2, ..., Rn), em que cada Ri
validade:
*(R1, R2, ..., Rn) uma dependncia de juno trivial.
Todo Ri superchave para R.
Um projeto de banco de dados est na FNPJ se cada membro de um conjunto de esquemas de relaes
que constituem o projeto estiver na FNPJ. A FNPJ chamada quinta forma normal (5FN) em parte da literatura
sobre normalizao de banco de dados.
Retornaremos ao nosso exemplo bancrio. Dada a dependncia de juno *((nmero_emprstimo,
nome_agncia), (nmero_emprstimo, nome_cliente), (nmero_emprstimo, total)), esquema_info_emprstimo
no est na FNPJ. Para colocar esquema_info_emprstimo na FNPJ, precisamos decomp-la em trs esquemas
especficos por meio da dependncia de juno: (nmero_emprstimo, nome_agncia), (nmero_emprstimo,
nome_cliente) e (nmero_emprstimo, total).
Como todas as dependncias multivaloradas so tambm dependncias de juno, fcil perceber que
todo esquema na FNPJ est tambm na 4FN. Assim, em geral, no precisamos chegar decomposio com
preservao de dependncia na FNPJ para um dado esquema.
Forma Normal Domnio-chave
195

A abordagem que utilizamos para a normalizao toma por base a definio de restries (funcional,
multivalorada ou dependncia de juno) e ento usa essa restrio para definir a forma normal. A forma normal
domnio-chave (FNDC) baseia-se em trs noes:
1. Declarao de domnio. Seja A um atributo e dom um conjunto de valores. A declarao de domnio A
dom exige que o valor de A em todas as tuplas seja um valor em dom.
2. Declarao de chaves. Seja R um esquema de relao com K
R. A declarao da chave key(K)
necessita que K seja uma superchave do esquema R isto , K
R. Note que todas as declaraes de
chaves so dependncias funcionais, mas nem todas as dependncias funcionais so declaraes de
chaves.
3. Restries gerais. Uma restrio geral um predicado do conjunto de todas as relaes de um dado
esquema. As dependncias que estudamos nesse captulo so exemplos de restries gerais.
Normalmente, uma restrio geral um predicado expresso em uma forma agregada, como a lgica de
primeira ordem.
Damos agora um exemplo de uma restrio geral que no funcional, multivalorada ou dependente de
juno. Suponha que todas as contas que comecem com o dgito 9 sejam contas especiais com altas taxas de
juros, cujo saldo mnimo 2500 dlares. Ento inclumos como restrio geral: se o primeiro dgito de
t[nmero_conta] for 9, ento t[saldo]2500.
Declaraes de domnio e declaraes de chave so fceis de testar em um sistema de banco de dados
prtico. Restries gerais, entretanto, podem ser extremamente custosas (em termos de tempo de
processamento e espao) para testar. O proposito de um projeto de banco de dados na FNPJ permitir-nos o
teste de restries gerais usando somente restries de domnio e chaves.
Formalmente, seja D um conjunto de restries de domnio e K, um conjunto de restries por chaves
para o esquema de relao R. Suponha que G represente as restries gerais de R. O esquema R est na FNDC se
D K implica logicamente G.
Retornemos s restries gerais que demos para as contas. As restries implicam que nosso projeto de
banco de dados no est na FNDC. Para criar um projeto na FNDC, precisamos de dois esquemas no lugar do
esquema_conta:
esquema_conta_regular=(nome_agncia, nmero_conta, saldo)
esquema_conta_especial=(nome_agncia, nmero_conta, saldo)
Conservamos, como restries gerais, todas as dependncias que tnhamos no esquema_conta. As
restries de domnio para esquema_conta_especial exigem que, para cada conta:
O nmero da conta comece por 9.
O saldo da conta seja maior que 2500.
As restries de domnio para esquema_conta_regular exigem que o nmero da conta no comece por 9.
O projeto resultante est na FNDC.
Comparemos a FNDC com outras formas normais estudadas. Nas outras formas normais, no levamos em
considerao restries de domnio. Assumimos (de modo implcito) que o domnio de cada atributo possui
domnio infinito, como o conjunto de todos os inteiros ou conjunto de todas as cadeias de caracteres. Permitimos
restries por chaves (de fato, permitimos dependncias funcionais).
Para cada forma normal, permitimos uma forma especfica de restrio geral (um conjunto de
dependncias funcionais, multivaloradas ou de juno). Assim, podemos reescrever as definies de FNPJ, 4FN,
FNBC e 3FN de modo a mostra-las como casos especiais de FNDC.
A seguir reescreveremos nossa definio de FNPJ inspirada na FNDC. Seja o esquema da relao R = (A1,
A2, ..., An). Seja dom(Ai) o domnio do atributo Ai e sejam infinitos esses domnios. Ento, todas as restries de
domnio D so da forma Ai dom(Ai). Sejam as restries gerais um conjunto G de dependncias funcionais
196

multivaloradas ou de juno. Se F um conjunto de dependncias funcionais em G, seja o conjunto K de

restries por chave aquelas dependncias funcionais no triviais em F+ da forma
R. O esquema R est na
FNPJ se e somente se ele estiver na FNDC com respeito a D, K e G.
Uma consequncia da FNDC que toda insero e remoo anmala eliminada.
A FNDC constitui a ltima forma normal porque permite restries arbitrrias, em vez de dependncias, e
permite ainda testes eficientes para essas restries. Naturalmente, se um esquema no est na FNDC, podemos
alcan-la por meio de decomposies, mas tais decomposies, como j foi visto, no so sempre
decomposies com preservao da dependncia. Assim, embora a FNDC seja a meta de um projetista de banco
de dados, poder ser sacrificada em projetos reais.
Abordagens Alternativas para Projeto de Banco de Dados
Vamos reexaminar a normalizao de esquemas de relao com nfase nos efeitos dessa normalizao no
projeto de um banco de dados real.
Adotamos como abordagem comear com um nico esquema de relao e, ento, decomp-lo. Uma de
nossas metas escolher uma decomposio que resulte em decomposio sem perda na juno. Para considerar
essa ausncia de perda na juno, assumimos ser vlido falar em juno de todas as relaes de um banco de
dados decomposto.
Considere o banco de dados da fig. 7.19, representamos a relao info_emprstimo decomposta na FNPJ.
Na fig. 7.19, representamos uma situao na qual ainda no determinamos o total do emprstimo L-58, mas
desejamos registrar a existncia do dado no emprstimo. Se computarmos uma juno natural dessas relaes,
notaremos que todas as tuplas referentes ao emprstimo L-58 desaparecero. Em outras palavras, no h
nenhuma relao info_emprstimo correspondente s relaes da fig. 7.19. Tuplas que desaparecem quando
computamos a juno so tuplas pendentes. Formalmente, seja r1(R1), r2(R2), ..., rn(Rn) um conjunto de relaes.
Uma tupla t de uma relao ri uma tupla pendente se t no est na relao:

As tuplas pendentes podem ocorrer em aplicaes de banco de dados reais. Representam informaes
incompletas, como ocorreu em nosso exemplo quando desejamos armazenar dados sobre um emprstimo que
estava ainda em processo de negociao. A relao r1 r2 ... rn chamada relao universal, uma vez que
envolve todos os atributos do universo definido por R1 R2 ... Rn.
O nico modo por meio do qual podemos escrever uma relao universal para o exemplo da fig. 7.19
incluindo valores nulos na relao universal. Vimos que valores nulos originam srias dificuldades. Pesquisas a
respeito de valores nulos e relaes so discutidos em notas bibliogrficas. Devido dificuldade de manuseio de
valores nulos, pode ser mais adequado tratar as relaes de um projeto decomposto como a representao do
banco de dados, em vez das relaes universais cujos esquemas foram decompostos durante o processo de
normalizao.

197

Note que no devemos introduzir informaes incompletas no banco de dados da fig. 7.19 sem recorrer
ao uso de valores nulos. Por exemplo, no podemos introduzir um nmero de emprstimo se no conhecermos
ao menos uma das seguintes informaes:
O nome do cliente.
O nome da agncia.
O total do emprstimo.
Assim, uma decomposio em particular define uma forma restritiva para uma informao incompleta
que aceitvel em nosso banco de dados.
A forma normal que definimos gera bons projetos de banco de dados do ponto de vista da representao
de informaes incompletas. Retornando novamente ao exemplo da fig. 7.19, poderamos desejar no permitir o
armazenamento do seguinte fato: h emprstimos (cujo nmero desconhecido) para Jones cujo montante
cem dlares. Uma vez que
nmero_emprstimo
nome_cliente total,
o nico modo de podermos relacionar nome_cliente e total por meio de nmero_emprstimo. Se desejarmos
saber o nmero do emprstimo, no poderemos diferenciar esse emprstimo de outros cujos nmeros so
desconhecidos.
Em outras palavras, no conseguimos armazenar dados cujos atributos-chave sejam desconhecidos.
Observe que as formas normais que definimos no nos permitem armazenar esse tipo de informao sem a
utilizao de valores nulos. Assim, nossas formas normais permitem a representao de informaes incompletas
no desejveis.
Se permitimos tuplas suspensas em nosso banco de dados, podemos preferir uma viso alternativa do
processo de projeto de banco de dados. Em vez de decompor uma relao universal, podemos sintetizar uma
coleo de esquemas na forma normal de um determinado conjunto de atributos. Estamos interessados nas
mesmas formas normais, independente de usar decomposio ou sntese. A abordagem da decomposio
melhor entendida e mais largamente utilizada.
Outra consequncia da abordagem usada no projeto de um banco de dados que os nomes dos atributos
devem ser nicos nas relaes universais. No podemos usar nome para referncia tanto para nome_cliente
quanto para nome_agncia. Geralmente, prefervel usar nomes nicos, como vnhamos fazendo. Ainda assim,
se definssemos nossos esquemas de relaes diretamente, em vez de usarmos relaes universais, obteramos
relaes com esquema tais como os que se seguem para nosso exemplo bancrio:
agncia_emprstimo (nome, nmero)
cliente_emprstimo (nmero, nome)
tot (nmero, total)
Observe que, com as relaes anteriores, expresses como agncia_emprstimo

cliente_emprstimo

no tm sentido. Na verdade, a expresso, agncia_emprstimo

cliente_emprstimo aponta os emprstimos
feitos para clientes cujos nomes sejam os mesmos do nome da agncia.
Em linguagens como SQL, entretanto, h operaes de juno no-naturais, ento, em uma consulta
envolvendo agncia_emprstimo e cliente_emprstimo, precisamos de referncias no ambguas para nome
usando, para isso, o nome da relao como prefixo. Nesses ambientes, os diversos papeis de nome (como nome
da agncia e nome do cliente), so menos problemticos e provavelmente de utilizao mais simples.
Acreditamos que usar o critrio do papel nico cada nome de atributo tem um nico significado no
banco de dados geralmente prefervel que a utilizao de um mesmo nome em diversos papeis. Quando o
critrio do papel nico no adotado, o projetista do banco de dados deve ser cuidadoso durante a construo
de um projeto de banco de dados relacional normalizado.

198

SQL 2003
Durante o desenvolvimento do sistema R, a IBM desenvolveu a linguagem SEQUEL, primeira linguagem de
acesso aos SGBDs relacionais. Com o desenvolvimento de um nmero cada vez maior de SGBDs, fez-se
necessrio especificar um padro da linguagem, chamada SQL, em 1986. Esse lanamento foi um esforo
particular da ANSI em conjunto com a ISO. A padronizao de uma linguagem de consulta foi responsvel pelo
sucesso dos SGBDs relacionais.
Em linhas gerais, os comandos da linguagem SQL podem ser divididos em sublinguagens, tais como a
Linguagem de Manipulao de Dados (DML) e a Linguagem de Definio de Dados (DDL). A DML trata dos
comandos ligados manipulao de Dados, definindo comandos para a seleo, incluso, alterao e excluso
dos dados das tabelas. J a DDL, rene os comandos para a criao e manuteno de estruturas e objetos do
banco de dados, tais como tabelas, vises e ndices.
Os fornecedores de Gerenciadores de Banco de Dados no hesitaram em adotar a SQL. Entretanto,
criaram variaes prprias da linguagem, adicionando funes ou comandos que, muitas vezes, em virtude de seu
sucesso, acabaram se incorporando em verses posteriores do padro. Contudo, a maior parte do padro
implementado de forma idntica nos principais SGBDs, possibilitando a portabilidade de aplicaes e maior
facilidade para os conhecedores da linguagem.
A linguagem passou por aperfeioamento em 1989 e, em 1992, foi lanada a SQL-92, ou SQL2. Embora
muitos dos conceitos especificados na SQL-92 somente tenham sido implementados por SGBDs relacionais
cresceu rapidamente.
A SQL:2003 a mais nova verso do padro SQL. Nesta verso foi feita uma grande reviso do padro
SQL3 e adicionada uma nova parte, ligada ao tratamento de XML.
Tipos de Dados
Em banco de dados relacionais e relacionais estendidos, as informaes ficam armazenadas em tabelas.
As tabelas so as materializaes das relaes do modelo relacional. Elas tm linhas e colunas, onde cada linha
representa a instncia de um item armazenado e cada coluna uma informao relativa ao item em questo. A
cada coluna de uma tabela est associado um tipo de dados, fazendo com que somente dados do tipo adequado
sejam armazenados na coluna.
A SQL define alguns tipos de dados que so implementados em alguns SGBDs. Ele define, tambm, os
comandos para criao, alterao e excluso de tabelas.
Tipos de dados bsicos
Em banco de dados relacionais e relacionais-estendidos, as informaes so armazenadas em tabelas.
Cada tabela poder conter vrias colunas, as quais esto armazenados dados. A cada coluna existir um tipo de
dados associado.
O tipo de dados de cada coluna definido durante a criao da tabela. O padro de SQL define vrios
tipos de dados simples. Permite, tambm, que o usurio defina tipos de dados prprios, a partir da composio
de tipos definidos pela linguagem.
A tabela 2.1 apresenta os principais tipos de dados definidos no padro da linguagem SQL. A partir desta,
podemos dividir os tipos de dados em cinco grupos: (i) relativos a cadeias de caracteres; (ii) relativos a dados
numricos; (iii) para armazenamento de objetos grandes; (iv) para armazenamento de informao booleana e
(v) tipos de dados relativos a datas e horas.

199

Os vrios fornecedores de SGBDs utilizam variaes prprias de dados definidos no SQL:2003.

Criando Tabelas
Uma tabela a materializao de um local para armazenamento de dados. Tais dados so agrupados em
linhas. Cada linha contm um conjunto de uma ou mais colunas. Todas as linhas tm o mesmo nmero de
colunas. Cada coluna possui seu tipo de dados prprio, que o mesmo para todas as linhas.
Ao criarmos uma tabela, devemos especificar o seu nome, quais colunas que a compe e quais os tipos de
dados das colunas em questo. Alm disso, podem ser definidas restries de integridade e regras de domnio,
entre outros. Assim, podemos especificar, durante a criao de uma tabela, por exemplo, que uma coluna referese chave primria da tabela ou que uma dada coluna somente poder conter determinados valores.
Quando uma tabela criada, ela no contm dados, ou seja, linhas. Somente depois os dados so
inseridos. Entretanto, algumas colunas da tabela podem no ter o seu preenchimento obrigatrio. Para estas,
quando nenhum dado for fornecido durante a incluso, includo o valor NULL (nulo).
A princpio, todas as colunas, independente de seus tipos de dados, podem apresentar o valor NULL no
seu contedo, em uma ou mais linhas. Ou seja, uma coluna definida como de tipo INTEGER pode suportar
nmeros inteiros ou o valor NULL. Da mesma forma, uma coluna CHAR suporta cadeia de caracteres ou o valor
NULL. Notamos que NULL indica ausncia de valor definido. diferente de zero ou de uma cadeia de caracteres
de comprimento zero. Ao criarmos uma tabela, podemos especificar que uma ou mais colunas no podem conter
o valor NULL. Ou seja, tais colunas tm o seu preenchimento obrigatrio. Quando nada informado para uma
coluna, ela aceita NULL no seu contedo.
Utilizamos o comando CREATE TABLE para criao de tabelas. A sintaxe bsica do comando a seguinte:
CREATE TABLE NOME_TABELA(
COL1
TIPO_COL1
[NOT NULL],
COL2
TIPO_COL2 [NOT NULL],
COLN
TIPO_COLN [NOT NULL]
200

)
Exemplo de criao de tabela no Oracle 10g:
CREATE TABLE EDITORA (
CODIGO
NUMBER(2) NOT NULL,
NOME VARCHAR2(80) NOT NULL
)
Podemos, na criao de tabelas, especificar vrios tipos de restries. Para uma dada coluna, a SQL:2003
nos permite que restries sejam especificadas aps o nome do tipo de dados da coluna em questo. As
principais restries so:
Chave primria: devemos posicionar a expresso PRIMARY KEY ao lado da definio do tipo de dados da
coluna em questo.
Chave estrangeira: posicionamos a expresso FOREIGN KEY REFERENCES NOME_TABELA ao lado da
definio do tipo da coluna. FOREIGN KEY opcional. NOME_TABELA deve ser substitudo pelo nome da
tabela que referenciada pela chave estrangeira. A tabela referenciada pela chave estrangeira deve ser
criada antes da criao da chave estrangeira.
Chave alternada: a expresso UNIQUE deve ser usada ao lado da definio do tipo de dados da coluna.
UNIQUE faz com que no seja possvel inserir valores repetidos na coluna.
Restrio de domnio: para verificar que o valor de uma coluna deve estar contido em uma lista ou faixa
de valores, utilizamos a palavra CHECK, seguida de uma expresso booleana delimitada por parnteses.
CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO
Onde:
Constraint indica a definio de uma restrio de integridade.
Nome_Restricao nome dada a restrio (CONSTRAINT) que est sendo criada.
Tipo_Restricao tipo da restrio que est sendo criada: PRIMARY KEY, FOREIGN KEY OU UNIQUE, por
exemplo. No caso de uma chave estrangeira, FOREIGN KEY opcional e o comando deve ser
complementado com a clusula REFERENCES.
A designao de um nome para cada restrio bastante til para o controle de erros que porventura
ocorram. Suponha que, por exemplo, durante a execuo de um programa que acessa um banco de dados, tentese incluir um valor repetido em linhas de uma coluna marcada como chave primria de uma tabela. Neste caso, o
SGBD no permite operao e um erro ocorre. O SGBD informa, na mensagem de erro, o nome da restrio que
foi violada. Isto permite que a aplicao trate o erro corretamente ou, ainda que seja mais facilmente detectado o
ponto onde a aplicao deve ser alterada de forma a no permitir que tal situao ocorra. Por isso, interessante
que o nome da CONSTRAINT indique o tipo de restrio, a tabela a que se refere e, quando possvel, a coluna que
sofre a restrio.
Consideremos a coluna CPF da tabela AUTOR. Esta coluna no deve aceitar valores repetidos. Para isso,
utilizamos a seguinte definio para a coluna:
CPF CHAR(11) NOT NULL UNIQUE
Por exemplo, para criar a tabela EDITORA no banco de dados Oracle 10g:
CREATE TABLE EDITORA (
CODIGO
NUMBER(2) NOT NULL PRIMARY KEY,
NOME VARCHAR2 (80) NOT NULL )
Para criar a tabela ASSUNTO, definindo PK_ASSUNTO como nome para a CONSTRAINT chave primria, utilizamos,
no Oracle 10g:
CREATE TABLE ASSUNTO(
SIGLA
CHAR(1) NOT NULL
CONSTRAINT PK_ASSUNTO PRIMARY KEY,
DESCRICAO
VARCHAR2(50)
201

)
Vejamos agora, um exemplo da definio de chave estrangeira, a partir da criao da tabela LIVRO.
Atribuiremos o nome PK_LIVRO para a restrio de chave primria, FK_LIVRO_ASSUNTO para a restrio de chave
estrangeira da coluna que referencia a tabela ASSUNTO e FK_LIVRO_EDITORA para a restrio de chave
estrangeira da coluna que referencia a tabela EDITORA.
CREATE TABLE LIVRO(
CODIGO
NUMBER(3) NOT NULL
CONSTRAINT PK_LIVRO PRIMARY KEY,
TITULO
VARCHAR2(80) NOT NULL,
PRECO
NUMBER(10,2),
LANCAMENTO DATE,
ASSUNTO
CHAR(1)
CONSTRAINT FK_LIVRO_ASSUNTO
REFERENCES ASSUNTO,
EDITORA
NUMBER(2)
CONSTRAINT FK_LIVRO_EDITORA
REFERENCES EDITORA
)
Restries de domnio podem ser implementadas atravs da clusula CHECK, seguida da expresso
booleana delimitada por parnteses. Para a montagem da expresso booleana podemos utilizar operadores de
comparao (<,>,>=,<=, =, <>) e predicados como LIKE e IN.
Exemplos:
Para definirmos a coluna SIGLA, que no admite valores nulos, somente possa aceitar os valores R, B
e F:
SIGLA CHAR(1) NOT NULL CHECK (SIGLA IN(R, B, F))
Para definirmos que a coluna MATRICULA somente aceitar valores maiores que 1000:
MATRICULA INTEGER CHECK (MATRICULA > 1000)
Podemos, tambm, atribuir um valor padro para as colunas de uma tabela. O valor padro ser
automaticamente atribudo coluna durante a criao de uma linha, caso nenhum valor tenha sido fornecido.
Sua definio d-se no momento da criao da tabela atravs da clusula DEFAULT, conforme apresentado a
seguir:
COL1
TIPO_COLUNA DEFAULT VALOR_PADRAO
Por exemplo: SEXO CHAR(1) DEFAULT M
A utilizao de restries de integridade no banco de dados pode ser bastante til para a manuteno da
correo das informaes. A definio de chaves primrias e restries UNIQUE impedem que sejam includos
valores repetidos em uma dada coluna. A definio de chaves estrangeiras faz com que somente sejam
permitidos valores que existam na tabela referenciada.
A tabela 2.6 apresenta um contedo da tabela EDITORA:

202

Na tabela LIVRO que criamos anteriormente, especificamos a coluna EDITORA como chave estrangeira
para a tabela EDITORA. Dessa forma, se considerarmos o contedo da tabela EDITORA apresentado na tabela
acima, ento a coluna EDITORA da tabela LVIRO somente poder conter os valores NULL, 1, 2, 3 e 4. Se tentarmos
incluir quaisquer outros valores, o SGBD gerar um erro e no permitir a incluso das informaes.
Considere, agora, que existe uma linha na tabela LIVRO onde a coluna EDITORA possua o valor 2.
Consideremos que um usurio tente excluir, da tabela EDITORA, a linha de cdigo 2. Se isto for possvel, teremos
uma inconsistncia nos dados, pois existir um valor na chave estrangeira da tabela LIVRO que no existe na
chave primria da tabela EDITORA. De acordo com o padro SQL possvel especificar, durante a definio da
restrio, trs diferentes aes a serem tomadas pelo SGBD, quando tal situao ocorrer:
Impedir a excluso da linha da tabela pai (EDITORA) caso existam outras tabelas que referenciem o valor a
ser excludo. A linha no excluda e um erro gerado. Esta a situao padro, a qual ocorrer sempre
que uma chave estrangeira for definida, a menos que declaremos o contrrio. especificada atraves da
opo ON DELETE RESTRICT;
ASSUNTO
CHAR(1)
CONSTRAINT FK_LIVRO_ASSUNTO
REFERENCES ASSUNTO
ON DELETE RESTRICT

Alterar o valor da coluna da chave estrangeira na tabela filho (LIVRO), tornando-o NULL para as linhas que
possuam o valor que est sendo apagado na tabela pai. A linha da tabela pai tambm apagada. Esta
ao especificada atraves da clusula ON DELETE SET NULL;
ASSUNTO
CHAR(1)
CONSTRAINT FK_LIVRO_ASSUNTO
REFERENCES ASSUNTO
ON DELETE SET NULL

Apagar as linhas da tabela filho onde existir, na coluna de chave estrangeira, o valor que est sendo
apagado na tabela pai. A linha da tabela pai tambm apagada. Esta ao definida atraves da clusula
ON DELETE CASCADE.
ASSUNTO
CHAR(1)
CONSTRAINT FK_LIVRO_ASSUNTO
REFERENCES ASSUNTO
ON DELETE CASCADE
Existe, ainda, um outro formato para a especificao de restries em tabelas. Podemos especificar
restries aps a declarao de todas as colunas. Neste caso, deveremos seguir o formato:
CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO
(COLUNA1_RESTRICAO, COLUNA2_RESTRICAO,...)

203

Eis a sintaxe do Oracle 10g:

CREATE TABLE LIVRO (
CODIGO
NUMBER(3),
TITULO
VARCHAR2(80) NOT NULL,
PRECO
NUMBER(10,2),
LANCAMENTO DATE,
ASSUNTO
CHAR(1),
EDITORA
NUMBER(2)
CONSTRAINT PK_LIVRO PRIMARY KEY (CODIGO),
CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY (ASSUNTO)
REFERENCES ASSUNTO,
CONSTRAINT FK_LIVRO_EDITORA
FOREIGN KEY (EDITORA)
REFERENCES EDITORA
)
Alterando tabelas
A SQL:2003 nos d a opo de alterar tabelas j existentes no banco de dados. Para isso, utilizamos o
comando ALTER TABLE. Este comando pode ser utilizado em conjunto com as clusulas adicionais para executar,
entre outras, uma das seguintes opes:
Incluir novas colunas em uma tabela existente;
Excluir colunas existentes em uma tabela;
Adicionar a definio de uma restrio a uma tabela existente;
Excluir a definio de uma restrio existente em uma tabela.
Incluindo novas colunas em uma tabela j existente
Para incluir novas colunas em uma tabela, utilizamos o comando ALTER TABLE, conforme a seguir:
ALTER TABLE NOME_TABELA
ADD [COLUMN] NOME_COLUNA TIPO_COLUNA RESTRICOES
Por exemplo, vamos adicionar a coluna IDENTIDADE tabela AUTOR, j criada no banco de dados.
ALTER TABLE AUTOR
ADD IDENTIDADE CHAR(10)
Excluindo colunas existentes em uma tabela
Para excluir colunas existentes em uma tabela, utilizamos o comando ALTER TABLE no formato
apresentado a seguir:
ALTER TABLE NOME_TABELA
DROP [COLUMN] NOME_COLUNA
Por exemplo, vamos remover a coluna IDENTIDADE da tabela AUTOR, j criada no banco de dados:
ALTER TABLE AUTOR
DROP COLUMN IDENTIDADE
Adicionando a definio de uma restrio a uma tabela existente
ALTER TABLE NOME_TABELA
ADD CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO
(COLUNA1_RESTRICAO, COLUNA2_RESTRICAO, ...)
204

Por exemplo, suponha que tenhamos criado a tabela LIVRO sem especificar nenhuma restrio. Vamos
agora adicionar essas restries atraves de trs comandos:
Adicionando a chave primria:
ALTER TABLE LIVRO
ADD CONSTRAINT PK_LIVRO PRIMARY KEY (CODIGO)
Adicionando a chave estrangeira a tabela ASSUNTO:
ALTER TABLE LIVRO
ADD CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY (ASSUNTO)
REFERENCES ASSUNTO
Adicionando a chave estrangeira para a tabela EDITORA:
ALTER TABLE LIVRO
ADD CONSTRAINT FK_LIVRO_EDITORA
FOREIGN KEY (EDITORA)
REFERENCES EDITORA
Excluindo a definio de uma restrio existente em uma tabela
Alterando tabelas
Podemos tambm alterar tabelas j definidas no banco de dados. Para isso utilizamos o comando ALTER
TABLE. Este comando pode ser utilizado em conjunto com as clusulas adicionais para executar, entre outras,
uma das seguintes opes:
Incluir novas colunas em uma tabela existente;
Excluir colunas existentes em uma tabela;
Adicionar a definio de uma restrio em uma tabela j existente;
Excluir a definio de uma restrio existente em uma tabela.
Incluir novas colunas em uma tabela existente
Para incluir novas colunas em uma tabela existente, utilizamos o comando ALTER TABLE conforme a
seguir:
ALTER TABLE NOME_TABELA
ADD [COLUMN] NOME_COLUNA TIPO_COLUNA RESTRICOES
Por exemplo: vamos adicionar a coluna IDENTIDADE tabela AUTOR, j criada no banco de dados.
ALTER TABLE AUTOR
ADD IDENTIDADE CHAR(10)
Excluindo colunas existentes em uma tabela, utilizamos o comando ALTER TABLE no formato apresentado a
seguir:
ALTER TABLE NOME_TABELA
DROP [COLUMN] NOME_COLUNA
Exemplo, vamos remover a coluna IDENTIDADE da tabela AUTOR, j criada no banco de dados:
ALTER TABLE AUTOR
DROP COLUMN IDENTIDADE
Adicionando a definio de uma restrio a uma tabela existente
Para incluir uma nova restrio a uma tabela existente, tambm utilizamos o comando ALTER TABLE. A
sintaxe bsica utilizada :
205

ALTER TABLE NOME_TABELA

ADD CONSTRAINT NOME_RESTRICAO TIPO_RESTRICAO
(COLUNA1_RESTRICAO, COLUNA2_RESTRICAO, ...)
Por exemplo: Suponha que tenhamos criado a tabela LIVRO sem especificar nenhuma restrio. Vamos,
agora, adicionar as restries a essa tabela, atravs de trs comandos.
Adicionando a chave primria:
ALTER TABLE LIVRO
ADD CONSTRAINT PK_LIVRO KEY(CODIGO)
Adicionando a chave estrangeira para a tabela ASSUNTO:
ALTER TABLE LIVRO
ADD CONSTRAINT FK_LIVRO_ASSUNTO FOREIGN KEY(ASSUNTO)
REFERENCES ASSUNTO
Adicionando a chave estrangeira para a tabela EDITORA:
ALTER TABLE EDITORA
ADD CONSTRAINT FK_LIVRO_EDITORA
FOREIGN KEY (EDITORA)
REFERENCES EDITORA
Excluindo a definio de uma restrio existente em uma tabela
O comando ALTER TABLE tambm pode ser utilizado para excluir uma restrio j existente em uma
tabela. Para isso, utilizamos o seguinte formato:
ALTER TABLE NOME_TABELA
DROP CONSTRAINT NOME_RESTRICAO
Por exemplo, desejamos excluir a chave primria da tabela LIVRO:
ALTER TABLE LIVRO
DROP CONSTRAINT PK_LIVRO
Desejamos destruir a chave estrangeira da tabela LIVRO que aponta para a tabela EDITORA.
ALTER TABLE LIVRO
DROP CONSTRAINT FK_LIVRO_EDITORA
Destruindo tabelas
Para destruir uma tabela utilizamos o comando DROP TABLE. Sua sintaxe bsica :
DROP NOME NOME_TABELA [CASCADE]
Exemplo: Para destruir a tabela LIVRO.
DROP TABLE LIVRO

206

Comandos Bsicos
Incluso de Dados
Para incluirmos dados em uma tabela, devemos utilizar o comando INSERT. Sua sintaxe bsica, segundo a
qual inserimos uma linha em uma tabela mostrada a seguir:
INSERT INTO NOME_TABELA (COL1, COL2, ..., COLN)
VALUES (VAL1, VAL2, ..., VALN)
Considere a tabela LIVRO j apresentada anteriormente. A tabela 3.1 apresenta um exemplo de instncia
da tabela LIVRO apresentado. Notamos que existe um livro com valor nulo para o campo LANCAMENTO. Isso
significa que ele ainda no foi lanado.

A descrio completa dos assuntos est na tabela ASSUNTO. Nesta existem vrios assuntos cadastrados,
independentemente se existe um livro do assunto em questo. Tomemos a tabela 3.2 como exemplo de instncia
da tabela EDITORA.

Para concluirmos as trs primeiras linhas na tabela LIVRO, devemos realizar os seguintes comandos
INSERT:
INSERT INTO LIVRO
(CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES
(1, BANCO DE DADOS PARA WEB, 31.2, 10/01/1999, B, 1)
INSERT INTO LIVRO
(TITULO, CODIGO, LANCAMENTO, PRECO, ASSUNTO, EDITORA) VALUES
(PROGRAMANDO EM LINUGAGEM C, 2, 01/10/1997, 30, P, 1)
Notamos que a diferena dos dois primeiros comandos anteriores est na diferena da ordem. Quando
especificamos o nome no h uma limitao na ordenao das mesmas.
A especificao dos nomes das colunas permite, ainda, que no sejam inseridos dados para todas as
colunas de uma tabela. Considere o caso do livro de cdigo 4, que no possui data de lanamento. Ao inseri-lo,
podemos omitir a coluna LANCAMENTO do comando INSERT a ser utilizado:
INSERT INTO LIVRO (CODIGO, TITULO, PRECO, ASSUNTO, EDITORA) VALUES
(4, BANCO DE DADOS PARA INFORMATICA, 48, B, 2)
207

Neste caso, ser inserido o valor NULL para LANCAMENTO. Note que, se essa coluna possuir uma
restrio para no aceitar valores nulos, e no estiver definido um valor padro, o comando no poder ser
executado.
Outra forma de executar o comando anterior, especificando todas as colunas da tabela, atravs da
utilizao da palavra NULL:
INSERT INTO LIVRO
(CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES
(4, BANCO DE DADOS PARA BIOINFORMATICA, 48, NULL, B, 21)
Caso estejamos inserindo valores para todas as colunas da tabela, podemos omitir seus nomes.
Entretanto, nesse caso, devemos especificar os valores a serem inseridos na mesma ordem em que as colunas da
tabela foram criadas:
Errado:
INSERT INTO LIVRO VALUES
(R, 42, 5, 01/09/1996, REDES DE COMPUTADORES, 2)
Correto:
INSERT INTO LIVRO
(CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA) VALUES
(5, REDES DE COMPUTADORES, 42, 01/09/1996, R, 2)
Quando inclumos dados em tabelas que possuem chaves estrangeiras referenciando outras tabelas, os
valores que esto sendo inseridos nas colunas da chave estrangeira j devem constar na chave primria da tabela
referenciada.
Consulta simples
A consulta simples a dados armazenados , usualmente, a operao realizada com mais freqncia em
sistemas comerciais. medida que a quantidade de linhas em tabelas cresce e que utilizamos varias tabelas em
uma mesma consulta, no s a complexidade do comando SQL aumenta, como tambm o tempo de resposta da
consulta pode ser muito alto, exigindo, assim, mais ateno na montagem do comando.
Para a realizao de consulta ao banco de dados, utilizamos o comando SELECT. A sintaxe bsica do
comando SELECT :
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA
Considere a instncia da tabela LIVRO apresentado anteriromente. Se quisermos recuperar as colunas
TITULO e CODIGO dessa tabela, devemos executar o comando:
SELECT CODIGO, TITULO
FROM LIVRO
Se quisermos recuperar todas as colunas da tabela LIVRO podemos especific-la no comando SELECT ou
utilizar o caractere *.
As consultas:
SELECT CODIGO, TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA
FROM LIVRO
e
SELECT * FROM LIVRO

208

Quando especificamos as colunas no comando SELECT, elas sero apresentadas no resultado, na ordem
especificada. Quando o caractere * utilizado, as colunas estaro ordenadas da mesma forma que o foram na
criao da tabela.
A clusula WHERE
Os resultados de comandos como apresentado anteriormente possuem todas as linhas da tabela. No
entanto, na maioria das consultas queremos consultar apenas as informaes referentes a algumas linhas. Essas
linhas devem atender a alguma condio.
A clusula WHERE permite que sejam especificadas linhas sobre as quais ser aplicada. A instruo pode
ser um comando SELECT ou comandos de atualizao e excluso de dados.
WHERE sempre usada com expresses lgicas, a qual pode ser operadores de comparao (>,<,>=,<=, =,
<>), operadores lgicos (AND, OR e NOT) e predicados prprios de linguagem SQL, tais como IS(NOT) NULL, IS
(NOT) LIKE, IN e EXISTS. Os operadores lgicos AND e OR so usados para conectar comparaes.
A expresso lgica ter um resultado que poder assumir os valores verdadeiro ou falso. A instruo
especificada ser executada para as linhas que tornarem o resultado da expresso lgica verdadeiro.
Por exemplo:
Preo superior a R$ 50,00
WHERE PRECO > 50
Preo igual a R$ 50,00 e de assunto p
WHERE PRECO > 50 AND ASSUNTO = P
Preo inferior a R$ 50,00 ou de assunto P
WHERE PRECO < 50 OR ASSUNTO = P
Lanamento nulo
WHERE LANCAMENTO IS NULL
Quando realizamos comparaes com colunas de tipos cadeias de caracteres, frequentemente queremos
encontrar valores que possuem determinados caracteres ou sequencias de caracteres. Para tal, usamos o
predicado LIKE em conjunto com um ou mais caracteres coringa.
O caractere coringa usado para substituir um ou mais caracteres que no conhecemos. Os caracteres
coringa so % e _. O caractere % utilizado para substituir uma cadeia ilimitada de caracteres onde ele
posicionado, enquanto _ substitui zero ou apenas um caractere.
Por exemplo: WHERE TITULO IS LIKE %BANCO_ DE DADOS%
Atualizao de informaes
Os dados inseridos em tabelas do banco de dados podem ser modificados. Para tal, utiliza-se o comando
UPDATE. Sua sintaxe :
UPDATE NOME_TABELA
SET COL1 = VAL1, COL2 = VAL2, ..., COLN = VALN
WHERE EXPRESSAO_LOGICA
Considerando a tabela LIVROS, temos os seguintes exemplos:
Atualizar o preo de todos os livros fornecendo um aumento de 10%.
UPDATE LIVRO
SET PRECO = PRECO * 1.1
Atualizar o preo do livro Programando em Linguagem C para R$ 32,00.
UPDATE LIVRO
SET PRECO = 32
WHERE TITULO = PROGRAMANDO EM LINGUAGEM C
209

Alterar o titulo e o preo do livro de cdigo 2 para Programao em Linguagem C e R$ 42,00,

respectivamente.
UPDATE LIVRO
SET PRECO = 42,
TITULO = PROGRAMACAO EM LINGUAGEM C
WHERE CODIGO = 2

Quando atualizamos os dados de uma ou mais colunas marcadas como chaves estrangeiras, os novos
valores j devem constar na chave primria da tabela referenciada.
Excluso de linhas
O comando DELETE utilizado para excluir linhas de uma tabela. Sua sintaxe a seguinte:
DELETE FROM NOME_TABELA
WHERE EXPRESSAO_LOGICA
Nos exemplos a seguir, utilizaremos novamente a tabela LIVROS:
Excluir todos os livros da tabela.
DELETE FROM LIVRO
Excluir os livros que tenham preo superior a R$ 100,00 e que no tenham sido lanados.
DELETE FROM LIVRO
WHERE LANCAMENTO IS NULL AND PRECO > 100
Excluir os livros que tenham R como assunto ou que ainda no tenham sido lanados.
DELETE FROM LIVRO
WHERE ASSUNTO = R OR LANCAMENTO IS NULL
Agrupamento Dados
Na linguagem SQL so definidas vrias funes que operam sobre grupos de dados. Tais funes,
usualmente, realizam operaes ou comparaes sobre um conjunto de dados e retornam, como resultado, uma
relao de apenas uma linha ou uma coluna. So chamadas Funes Agregadas.
Contagem
Muitas vezes necessrio contar uma quantidade de linhas que satisfaz uma determinada condio. Para
isso, utilizamos a funo COUNT. Assim como as outras funes que sero apresentadas mais adiante, a funo
COUNT recebe um parmetro e retorna um numero.
Como parmetro para a funo COUNT podemos utilizar o nome de uma coluna ou o caractere *. No caso
da utilizao do caractere * o resultado obtido a contagem do numero de linhas da tabela. No caso da utilizao
de uma coluna como parmetro, o reesultado obtido o numero de ocorrncias no nulas desta coluna na tabela
pesquisada.
Por exemplo:
Contar a quantidade de linhas da tabela LIVRO:
SELECT COUNT(*)
FROM LIVRO
Contar a quantidade de linha da tabela LIVRO com a coluna de cdigo preenchida:
SELECT COUNT(CODIGO)
FROM LIVRO
A funo COUNT retornar zero quando nenhuma linha atender ao critrio utilizado.
Soma
210

Outra operao comumente utilizada a soma. Para realizar a soma de valores de uma coluna para um
grupo de dados, utilizamos a funo SUM.
Exemplo:
Somatrio dos preos da tabela de livros:
SELECT SUM(PRECO)
FROM LIVRO
A funo SUM retornar o somatrio dos valores no-nulos da coluna utilizada como parmetro.
Retornar NULL se todos os valores desta coluna forem nulos ou se nenhum valor atender ao critrio de seleo.
Mdia
Para obter a mdia aritmtica dos valores de uma coluna utilizada como parmetro, utilizamos o
comando AVG, informando, como parmetro para a mesma, o nome da coluna para a qual desejamos obter a
mdia.
A funo AVG retornar a mdia considerando apenas os valores no-nulos da coluna especificada.
Exemplo:
SELECT AVG(PRECO)
FROM LIVRO
Valor Mximo
Para obter o valor mximo de uma coluna em um conjunto de dados, utilizamos a funo MAX. Assim
como a funo AVG, MAX recebe um parmetro e retorna o valor NULL se em todas as linhas da tabela
consultada o valor da coluna em questo for nulo, ou se nenhuma linha atender ao valor do critrio de seleo.
Exemplo:
SELECT MAX(PRECO)
FROM LIVRO
WHERE ASSUNTO = P
Valor mnimo
Em oposio funo MAX, temos a funo MIN, que retorna o menor valor de uma coluna para a tabela
especificada.
Menor preo da tabela de livros, para cujos livros o assunto seja B:
SELECT MIN(PRECO)
FROM LIVRO
WHERE ASSUNTO = B
Outras funes
Podemos destacar:
STDDEV_POP: desvio padro da populao;
STDDEV_SAMP: desvio padro da amostra;
VAR_POP: varincia calculada como o quadrado de STDDEV_POP;
VAR_SAMP: varincia calcula como o quadrado de STDDEV_SAMP.
Clusula GROUP BY
Para utilizarmos uma funo de agregao em conjunto com colunas da tabela na clusula SELECT,
devemos utilizar a clusula GROUP BY. A sintaxe de utilizao da clusula GROUP BY a seguinte:
SELECT COL1, COL2, ..., COLN, FUNCAO1, , FUNCAON
FROM NOME_TABELA
WHERE CONDICAO
211

GROUP BY COL1, COL2, ..., COLN

A utilizao da clusula GROUP BY faz com que os dados sejam sumarizados pelas colunas que so
especificadas na mesma. Assim, somente valores distintos destas colunas farao parte do resultado. Neste caso,
torna-se possvel utilizar funes agregadas, as quais iro operar sobre as linhas que foram utilizadas para montar
cada grupo (sumarizao) de dados. Vejamos alguns exemplos:
Qual o preo mdio dos livros de cada assunto?
SELECT ASSUNTO, AVG(PRECO)
FROM LIVRO
GROUP BY ASSUNTO
Quantos livros existem para cada assunto?
SELECT ASSUNTO, COUNT(*)
FROM LIVRO
GROUP BY ASSUNTO
Qual o preo do livro mais caro de cada assunto, dentre aqueles que j foram lanados?
SELECT ASSUNTO, MAX(PRECO)
FROM LIVRO
WHERE LANCAMENTO IS NOT NULL
GROUP BY ASSUNTO
Quantos livros j foram lanados para cada editora?
SELECT EDITORA, COUNT(*)
FROM LIVRO
WHERE LANCAMENTO IS NOT NULL
GROUP BY EDITORA
Clusula HAVING
A clusula WHERE no nos permite realizar no nos permite realizar restries com base nos resultados
das funes agregadas. Para isso, devemos utilizar a clusula HAVING.
A clusula HAVING ser seguida de uma expresso lgica que poder ser composta ou no, de forma
idntica ao que foi apresentado na clusula WHERE. Assim como a clusula WHERE, a clusula HAVING serve de
filtro para as linhas constantes do resultado do comando SQL.
A principal diferena entre essas clusulas se d no fato de que, no caso da clusula WHERE, o filtro
aplicado quando as linhas so recuperadas do banco de dados, fazendo com que estas nem cheguem a ser
consideradas quando da realizao de agrupamentos ou na execuo da funo de agregao. J as restries
descritas na clusula HAVING sero aplicadas somente aps a recuperao das linhas no banco de dados, da
montagem dos grupos e da execuo de funes agregadas. Por isso, possvel utilizar funes agregadas em
expresses lgicas da clusula HAVING.
Sintaxe bsica:
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA
WHERE EXPRESSAO_LOGICA_WHERE
GROUP BY COL1, COL2,..., COLN
HAVING EXPRESSAO_LOGICA_HAVING
Exemplo:
Quais os assuntos cujo preo mdio dos livros ultrapassa R$50,00?
212

SELECT ASSUNTO
FROM LIVRO
GROUP BY ASSUNTO
HAVING AVG(PRECO) > 50
Quais os assuntos que possuem mais de dois livros?
SELECT ASSUNTO, COUNT(*)
FROM LIVRO
GROUP BY ASSUNTO
HAVING COUNT(*) > 1
Quais os assuntos que possuem mais de dois livros j lanados?
SELECT ASSUNTO, COUNT(*)
FROM LIVRO
GROUP BY ASSUNTO
HAVING COUNT(*) > 1
Quantos livros j foram lanados por assunto?
SELECT ASSUNTO, COUNT(*)
FROM LIVRO
WHERE LANCAMENTO IS NULL
GROUP BY ASSUNTO

213

Operando, Ordenando e Formatando Resultados

Usando apelidos
No possvel atribuir apelidos tanto a colunas quanto a tabelas, e referenci-las atravs de seus apelidos.
Apelidos para colunas  atribuir um apelido a uma coluna resultante de uma consulta extremamente fcil. Veja
a sintaxe:
SELECT COL1 AS MINHA_COLUNA
FROM NOME_TABELA
Quaisquer construes particionadas na clusula SELECT, como as funes, podem receber apelidos. Por
exemplo:
Considere a consulta que retorna o maior preo da tabela de livros para livros cujo assunto seja P:
SELECT MAX(PRECO) AS PRECO_MAXIMO
FROM LIVRO
WHERE ASSUNTO = P
Apelidos para as tabelas  em nossas consultas ao banco de dados podemos fazer referncia a uma coluna
explicitando a sua tabela de origem como uma construo no formato: NOME_TABELA.NOME_COLUNA. Na
verdade, h situaes onde somos obrigados a utilizar esse tipo de construo.
Em alguns casos, as tabelas so representadas por nomes extensos e utilizar a construo anterior pode no
ser s cansativo quanto tornar o comando extenso e confuso. Nessas situaes, possuir um apelido menor e
expressivo para a tabela interessante. Na verdade, no se trata somente de questo de clareza de comando. H
situaes onde somos obrigados a utilizar apelidos para tabelas e relaes. Vejamos, ento, como fornecer
apelidos para tabelas:
SELECT COL1
FROM NOME_TABELA_ORIGINAL AS NOVO_NOME_TABELA
Abaixo, a tabela LIVRO substituda pelo apelido L:
SELECT MAX(L.PRECO) AS PRECO_MAXIMO
FROM LIVRO L
WHERE L.ASSUNTO = P
Constantes e concatenao
A SQL permite definir constantes que sero repetidas em todas as linhas do resultado de uma consulta, o que
atende ao caso anterior. Para isso, basta especificar a constante desejada na clusula SELECT do comando. Por
exemplo:
SELECT LIVRO: AS TEXTO, TITULO
FROM LIVRO
Neste exemplo, a cadeia de caracteres LIVRO: foi tratada como uma coluna independente. A linguagem SQL
define o operador de concatenao ||, e deve ser utilizado entre as colunas ou textos que desejamos
concatenar.
Vejamos o exemplo da utilizao de concatenao do exemplo anterior:
SELECT LIVRO: || TITULO AS TEXTO
FROM LIVRO
Realizando operaes aritmticas

214

Da mesma forma que utilizamos a clusula SELECT, podemos realizar operaes aritmticas sobre os
resultados de uma consulta. Os operadores +, -, *, e / podem ser utilizados em expresses matemticas. Alm
disso, parnteses tambm podem ser utilizados, para determinar prioridades na execuo das operaes. Por
exemplo:
Listar os novos preos dos livros se os valores fossem reajustados em 10%.
SELECT TITULO, PRECO*1.1 AS NOVO_PRECO
FROM LIVRO
Podemos reescrever a consulta para demonstrar a utilizao de outros operadores mas obtendo o mesmo
resultado.
SELECT TITULO, PRECO + (PRECO/10) AS NOVO_PRECO
FROM LIVRO
Notamos que as operaes realizadas modificam somente o resultado das consultas, no alterando os dados
das tabelas.
Aplicando Funes
Formatando os resultados de uma consulta atravs de funes do SGBD pode fornecer resultados mais
compreensveis e, tambm, fazer com que a consulta retorne informaes em formato adequado para exibio
ao usurio final. Alm disso, muitas vezes, podemos utilizar funes que manipulam os resultados de consultas
SQL formatando-os ou alterando-os.
Cadeia de caracteres  o padro SQL define vrias funes que manipulam e formatam cadeias de caracteres.
Nesta seo so apresentadas as principais: UPPER, LOWER, TRIM, SUBSTRING e LENGHT.
As funes UPPER, LOWER, TRIM e LENGHT recebem uma cadeia de caracteres (ou uma coluna de dados do
tipo cadeia de caracteres) como parmetro e retornam um resultado do mesmo tipo. J a funo SUBSTRING, que
tambm retorna uma cadeia de caracteres como resultado, recebe trs parmetros como entrada, sendo dois
numricos e uma cadeia de caracteres.
A funo UPPER retornam o seu parmetro de entrada com todos os caracteres convertidos para maisculas.
Em oposio funo UPPER, a funo LOWER retorna todos os caracteres convertidos para minsculos. Vejamos
um exemplo:
SELECT UPPER(LIVRO:) || LOWER(TITULO) AS TEXTO
FROM LIVRO
A funo TRIM retira os caracteres espao contidos nas margens da cadeia de caracteres que recebe como
parmetro. Exemplo:
Consulta:
SELECT TRIM( LIVRO: ) || TITULO AS TEXTO
FROM LIVRO
WHERE ASSUNTO = P
A funo SUBSTRING retorna o trecho da cadeia de caracteres que ela recebe como parmetro. O trecho a ser
retornado definido por outros dois parmetros de entrada: a posio de incio do trecho e o seu comprimento.
Exemplo:
Listar os dez primeiros caracteres dos ttulos dos livros:
SELECT SUBSTRING(TITULO, 1, 10) AS TRECHO
FROM LIVRO

215

LENGTH retorna o comprimento da cadeia de caracteres que recebe como parmetro. Retornar nulo, caso
receba NULL como parmetro. Exemplo:
SELECT LENGTH(TITULO) AS COMPRIMENTO
FROM LIVRO
WHERE ASSUNTO = R
Datas
A formatao de campos relacionados a datas e horrios uma das que apresenta o maior nmero de
variaes entre as implementaes dos SGBDs padres para SQL. Dentre as funes mais utilizadas, temos as
funes DAY, MONTH e YEAR. Estas funes recebem uma data como parmetro e retornam o dia, o ms e o ano
da data, respectivamente. Exemplo:
Selecionar o dia da publicao do livro de cdigo 1
SELECT DAY(LANCAMENTO) AS DIAS
FROM LIVRO
WHERE CODIGO = 1
Selecionar o ms e o ano da publicao dos livros cujo assunto R:
SELECT MONTH(LANCAMENTO) AS MS,
YEAR(LANCAMENTO) AS ANO
FROM LIVRO
WHERE ASSUNTO = R
Nmeros
A linguagem SQL e os SGBDs oferecem vrias funes predefinidas para a manipulao de nmeros.
Na tabela 5.1 so apresentadas as principais funes matemticas definidas pela SQL. A maioria das funes
da tabela 5.1 recebe apenas um parmetro de entrada numrico e retorna um nmero.

Tambm so comuns implementaes de funes trigonomtricas para a SQL. Dentre as principais funes
trigonomtricas, temos as apresentadas na tabela 5.2:

216

A utilizao das funes algbricas e trigonomtricas apresentadas semelhante das funes de cadeias de
caracteres apresentadas anteriormente. Veja o exemplo para a funo CEIL:
SELECT CEIL(PRECO)
FROM LIVRO
WHERE CODIGO = 3
Eliminando repeties
Quando utilizamos consultas sobre tabelas, podemos obter linhas repetidas. Para eliminar repeties, em
relaes resultantes de consultas, foi definido o predicado DISTINCT. Este predicado poder ser utilizado
isoladamente na clusula SELECT ou em conjunto com outras funes SQL.
Para eliminar resultados distintos de uma consulta, basta posicionar o predicado DISTINCT aps a clusula
SELECT e antes da especificao das colunas a serem recuperados. Vejamos um exemplo:
recuperar os assuntos distintos da tabela de livros:
SELECT DISTINCT ASUNTO AS ASSUNTO
FROM LIVRO
O predicado DISTINCT pode ainda ser utilizado com a funo COUNT, quando posicionado junto ao seu
parmetro de entrada. Neste caso, possvel contar os valores distintos de uma coluna, por exemplo.
SELECT COUNT(DISTINCT ASSUNTO)
FROM LIVRO
Ordenando os resultados
Ao realizarmos consultas SQL no sabemos, a priori, quais e em que ordem as linhas do resultado sero
apresentadas. No entanto, muitas vezes, desejamos obter os resultados ordenados por uma ou mais colunas.
Para isso, devemos utilizar a clusula ORDER BY.
A clusula ORDER BY sempre posicionada como a ltima de um comando SELECT. Vejamos um exemplo de
sintaxe:
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA
WHERE CONDICAO
GROUP BY COL1, COL2, ..., COLN
HAVING EXPRESSAO_LOGICA
ORDER BY COL1 [DESC,ASC], COL2 [DESC, ASC]
Consulta:
Gerar a listagem dos livros contendo assunto, ttulo, e preo. A listagem dever estar ordenada em ordem
crescente de assunto e decrescente de preo.
SELECT ASSUNTO, TITULO, PRECO
217

FROM LIVRO
ORDER BY ASSUNTO, PRECO DESC
Gerar listagem dos livros contendo assunto, ttulo e preo. A listagem dever estar ordenada em ordem
crescente de ttulo e descente de preo.
SELECT ASSUNTO, TITULO, PRECO
FROM LIVRO
ORDER BY 2, PRECO DESC

A SQL:2003 nos permite, ainda, utilizar funes, como SUBSTRING, na clusula ORDER BY.

218

Junes
Nos comandos apresentados anteriormente, somente uma tabela era acessada por vez. Entretanto, muitas
vezes precisamos acessar informaes de mais de uma tabela em uma mesma consulta.
Para acessar mais de uma tabela em um mesmo comando SELECT, devemos realizar operaes chamadas
junes. Existem vrios tipos de juntos, como a interna, a externa e a natural. As diferenas entre as junes se
do na forma como as tabelas da consulta so combinadas para a montagem dos resultados.
Para coletar informaes de mais de uma tabela, realizamos junes. As junes so ligaes entre tabelas,
realizadas atravs dos valores de uma ou mais colunas. Usualmente, essas ligaes ocorrem entre a chaveprimria de uma tabela e a chave estrangeira de outra.
No caso de nosso exemplo, temos que a coluna ASSUNTO da tabela LIVRO a chave estrangeira para a
coluna SIGLA, chave-primria da tabela ASSUNTO. Assim, neste caso, a ligao entre as informaes de uma
tabela com a outra se dar atravs das colunas ASSUNTO e SIGLA.
A juno entre tabelas faz com que seja gerada uma relao resultante contendo todas as colunas das
tabelas originais. Para a juno entre as tabelas anteriores ser gerada uma relao contendo as colunas CODIGO,
TITULO, PRECO, LANCAMENTO, ASSUNTO, EDITORA, SIGLA e DESCRICAO. Essa relao ser gerada somente para
a execuo da consulta e sobre ela podero ser aplicadas as operaes apresentadas anteriormente. As linhas
que participaro da relao resultante sero escolhidos com base no tipo de juno que est sendo realizada e
com o predicado de juno.
Juno Interna
A juno interna entre tabelas a modalidade de juno que faz com que somente participarem da relao
resultante as linhas das tabelas de origem que atenderem clusula de juno. A sintaxe bsica para a realizao
da juno interna :
SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON
FROM NOME_TABELA
INNER JOIN NOME_TABELA2
ON NOME_TABELA.COL1 = NOME_TABELA2.COL1
WHERE CONDICAO
GROUP BY COL1, COL2, ..., COLN
HAVING EXPRESSAO_LOGICA
ORDER BY COL1, COL2, , COLN
Por exemplo:
Quais os ttulos dos livros j lanados e a descrio dos seus assuntos?
SELECT TITULO, DESCRICAO
FROM LIVRO
INNER JOIN ASSUNTO
ON SIGLA = ASSUNTO
WHERE LANCAMENTO IS NOT NULL
No exemplo anterior, nem todas as linhas da tabela ASSUNTO (cuja instncia est representada na tabela 3.2)
fazem parte do resultado da consulta. Isto ocorre porque estamos utilizando uma juno interna, onde somente
participam do resultado as linhas nas quais os valores das colunas de juno possuem correspondente em ambas
as tabelas. As junes externas, apresentadas a seguir, permitiro que linhas onde no existam valores
correspondentes em ambas as tabelas participam.
Os primeiros SGBDs possuram a clusula INNER JOIN. Mas as junes internas j eram utilizadas. Para tal, as
tabelas eram listadas na clusula FROM, separadas por virgulas, e as condies de juno eram descritas na

219

clusula WHERE. Nesta construo, as condies de juno so listadas juntamente com as condies de seleo.
Veja o exemplo da juno interna sem a clusula INNER JOIN:
SELECT TITULO, DESCRICAO
FROM LIVRO, ASSUNTO
WHERE ASSUNTO = SIGLA
AND LANCAMENTO IS NOT NULL
Em consultas complexas formuladas dessa forma, comum que alguma importante condio seja esquecida.
Embora bastante difundidas, aconselhvel que construes deste tipo sejam substitudas pela sintaxe contendo
a clusula INNER JOIN.
Suponha que, agora, busquemos gerar uma listagem contendo o ttulo do livro, o nome da editora que o
publicou e a descrio do assunto de que trata. Para isso, teremos que utilizar o acesso a trs tabelas. Por
exemplo:
SELECT TITULO, NOME, DESCRICAO
FROM LIVRO
INNER JOIN EDITORA E
ON EDITORA = E.CONTEUDO
INNER JOIN ASSUNTO
ON ASSUNTO = SIGLA
Em consultas onde ocorrem junes, todas as clusulas apresentadas anteriormente como (WHERE, GROUP
BY, HAVING e ORDER BY) continuam vlidas. Por exemplo:
Montar a listagem das editoras e dos ttulos dos livros que lanaram, ordenada pelo nome da editora e, em
seguida, pelo ttulo do livro. Apresentar somente os livros j lanados.
Consulta:
SELECT NOME, TITULO
FROM EDITORA E
INNER JOIN LIVRO
ON EDITORA = E.CODIGO
WHERE LANCAMENTO IS NOT NULL
ORDER BY NOME, TITULO
Junes Externas
Nas consultas onde se realizam junes internas, somente participam dos resultados as linhas cujas colunas
de juno possuem os mesmos valores em ambas as tabelas participantes da juno.
Nesta seo, sero apresentadas trs formas de executar a juno externa, modalidade de juno onde a no
inexistncia de valores correspondentes no limita a participao de linhas no resultado de uma consulta.
Juno externa esquerda
Suponha que desejamos obter uma listagem de todas as editoras cadastradas em nosso banco de dados e,
para aquelas que possuam livros publicados, o nome dos mesmos. Vamos ter que utilizar uma juno externa. Eis
a sintaxe da juno externa esquerda:
SELECT COL1, COL2, ..., COLN, FUNCAO1, FUNCAO2
FROM NOME_TABELA
LEFT OUTER JOIN NOME_TABELA2
ON NOME_TABELA.COL1 = NOME_TABELA2. COL1
WHERE CONDICAO
GROUP BY COL1, COL2, ..., COLN
HAVING EXPRESSAO_LOGICA
220

ORDER BY COL1, COL2, , COLN

A nica diferena para sintaxe da juno interna a substituio do termo INNER JOIN pelo termo LEFT
OUTER JOIN, indicador da juno externa esquerda.
Em uma juno externa esquerda, a juno ocorre de forma que todas as linhas pertencentes tabela
posicionada esquerda do termo LEFT OUTER JOIN no comando e que atendem aos critrios definidos na
clusula WHERE faro parte do resultado, independente se existem valores correspondentes na coluna de juno
da tabela posicionada direita do comando. Caso no existam valores correspondentes na tabela direita, as
colunas selecionadas desta tabela, nas linhas onde no existe correspondncia, tero valor NULL.
Montando a listagem de todas as editoras cadastradas em nossa base de dados e, para aquelas que possuam
livros publicados, relacionar, tambm, o ttulo dos mesmos. Vamos ordenar os resultados pelo nome da editora e
pelo ttulo do livro.
SELECT NOME, TITULO
FROM EDITORA E
LEFT OUTER JOIN LIVRO
ON EDITORA = E.CODIGO
ORDER BY NOME, TITULO
Outro exemplo: Mostrar a listagem completa de assuntos contendo, tambm, os ttulos dos livros e seus
respectivos assuntos. Resultados ordenados pela descrio do assunto.
Consulta:
SELECT DESCRICAO, TITULO
FROM ASSUNTO
LEFT OUTER JOIN LIVRO
ON SIGLA = ASSUNTO
ORDER BY DESCRICAO
Juno externa Direita
A juno externa direita extremamente parecida com a juno externa esquerda. A nica diferena
consta no fato de que a tabela da qual todas as linhas constaro do resultado est posicionada direita do termo
RIGHT OUTER JOIN no comando. Sua sintaxe :
SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON
FROM NOME_TABELA
RIGHT OUTER JOIN NOME_TABELA2
ON NOME_TABELA.COL1 = NOME_TABELA2.COL1
WHERE CONDICAO
GROUP BY COL1, COL2, ..., COLN
HAVING EXPRESSAO_LOGICA
ORDER BY COL1, COL2, , COLN
Onde, a nica diferena em termos de sintaxe para a juno externa esquerda a substituio do termo
LEFT OUTER JOIN pelo termo RIGHT OUTER JOIN, indicador da juno externa direita.
Se reescrevermos a consulta do exemplo anterior de forma a obtermos o mesmo resultado e com a utilizao
da juno externa direita, teremos a seguinte consulta:
SELECT DESCRICAO, TITULO
FROM LIVRO
RIGHT OUTER JOIN ASSUNTO
ON SIGLA = ASSUNTO
221

ORDER BY DESCRICAO
Note que para que as consultas sejam equivalentes, temos que inverter a ordem das tabelas na clusula
FROM.
Juno Externa Completa
Podemos ainda querer montar as listagem de todas as linhas das tabelas participantes que atendam aos
critrios de seleo especificados na clusula WHERE participem do resultado, independente da correspondncia
de valores da clusula de juno. A clusula de juno atua de forma a montar a relao quando existir
correspondncia entre valores. Quando no existir, as colunas da tabela onde inexiste o valor devem apresentar o
valor nulo. Esta a juno externa completa.
A diferena da juno externa para as junes direita e esquerda se d no fato de que, naquelas, uma das
tabelas somente apresentava os valores com correspondncia outra, a qual apresentava todos os seus valores.
Na juno externa completa, as duas tabelas podero apresentar valores sem correspondentes. A sintaxe :
SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON
FROM NOME_TABELA
FULL OUTER JOIN NOME_TABELA2
ON NOME_TABELA.COL1 = NOME_TABELA2.COL1
WHERE CONDICAO
GROUP BY COL1, COL2, ..., COLN
HAVING EXPRESSAO_LOGICA
ORDER BY COL1, COL2, , COLN
Onde a nica diferena para a sintaxe da juno externa esquerda a substituio do termo FULL OUTER
JOIN, em detrimento de LEFT OUTER JOIN e RIGHT OUTER JOIN, respectivamente.
Consideremos agora, a tabela de editoras, cujo exemplo apresentado na tabela 2.6, e a tabela de livros,
onde foram adicionados mais livros, ainda sem data prevista para o lanamento, sem editora definida e sem
preo. A nossa nova tabela de livros apresentada na tabela 6.1. Vejamos, ento um exemplo para a realizao
da juno externa completa.

Listagem com a exibio de todos os ttulos e de todas as editoras, relacionando a obra com a editora que a
publica, quando caso. A listagem dever estar ordenada pelo ttulo da obra.
Consulta:
SELECT TITULO, NOME
FROM LIVRO
FULL OUTER JOIN EDITORA
ON EDITORA.CODIGO = EDITORA
ORDER BY TITULO
Juno Cruzada
222

Algumas vezes queremos gerar todas as combinaes possveis entre elementos de duas tabelas. uma
operao idntica a um produto cartesiano dos elementos das tabelas. Para isso, podemos utilizar um tipo de
juno conhecida como CROSS JOIN. Sua sintaxe :
SELECT COL1, COL2, ..., COLN, FUNCAO1, , FUNCAON
FROM NOME_TABELA
CROSS JOIN NOME_TABELA2
WHERE CONDICAO
GROUP BY COL1, COL2, , COLN
HAVING EXPRESSAO_LOGICA
ORDER BY COL1, COL2, , COLN
Suponha um torneio onde selees so divididas em dois grupos, A e B, e onde todos os membros do grupo A
jogam contra todos os membros do grupo B. A tabela 6.2 representa as selees do Grupo A, euqunato a tabela
6.3, as do grupo B.

Consulta:
SELECT A.NOME AS TIME_A, B.NOME AS TIME_B
FROM GRUPO_A A CROSS JOIN GRUPO_B B
Resultado:

Juno Natural e Baseada em Nomes de Colunas

Anteriormente foram apresentadas as junes internas e externas. Agora vamos verificar a juno natural e a
juno baseada em nomes de colunas. Ambas so construes que podem ser aplicadas em conjunto com as
modalidades apresentadas anteriromente para substituir a utilizao da clusula ON.

223

Na verdade, como, em alguns casos, as tabelas sobre as quais queremos realizar a juno apresentam
colunas de mesmo nome e para que, nesses asos, no seja necessrio explicitar o nome das colunas, definida a
juno natural. Nesta modalidade de juno, todas as colunas de mesmo nome nas tabelas em questo
participam da condio de juno.
Para utilizar a juno natural, basta incluir a palavra reservada NATURAL antes das palavras INNER, LEFT,
OUTER ou FULL, de acordo com a situao. Ento, no ser necessrio utilizar a clusula ON.
Entretanto, realizar automaticamente a juno por todas as colunas de mesmo nome pode ser um problema.
Frequentemente encontramos tabelas com colunas de nomes intituladas nome e descrio. No entanto, no
comum realizar junes por tais colunas.
Para solucionar essa questo, foi elaborada a juno baseada em nomes de colunas. Assim, como no caso da
juno natural, neste caso, as colunas de mesmo nome nas diferentes tabelas sero utilizadas para a juno.
Entretanto, agora, as colunas no sero utilizadas automaticamente. Ser necessrio especificar quais colunas
sero utilizadas.
A sintaxe da juno baseada em nomes de coluna :
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA
[INNER, LEFT OUTER, RIGHT OUTER,
FULL OUTER] JOIN NAME_TABELA2
USING [NOME_COLUNA]
A principal diferena entre a juno natural e a baseada em nomes de colunas se d no fato de que, na
juno natural, todas as colunas de mesmo nome nas tabelas sero utilizadas para realizar a juno, enquanto a
juno baseada em nomes de colunas, somente sero utilizadas as colunas que forem listadas.
Formatando a Sada e as junes externas
Quando utilizamos as funes externas, podemos obter vrios valores nulos em uma ou mais coluna do
resultado. A funo COALESCE nos permite substituir os valores nulos por outros que desejamos. Ela recebe uma
lista de parmetros e retorna o primeiro que possuir um valor no-nulo. Frequentemente, exigido que todos os
parmetros sejam do mesmo tipo de dados.
Por exemplo:
Obter uma listagem com a descrio de todos os assuntos e os ttulos dos livros de cada um. Quando no
existir um assunto associado, deve ser escrita a frase SEM PUBLICAES.
Consulta:
SELECT DESCRICAO, COALESCE(TITULO, SEM PUBLICAES) AS TITULO
FROM ASSUNTO
LEFT OUTER JOIN LIVRO
ON SIGLA = ASSUNTO
ORDER BY DESCRICAO

224

Combinando Comandos
Todos os commandos de consulta da linguagem SQL atuam sobre uma relao, que pode ou no estar
materializada em formato de uma tabela. O resultado dos comandos de seleo tambm uma relao. Tanto as
relaes de entrada quanto as relaes de sada podem possuir diversos nmeros de colunas e linhas.
Este tipo de construo permite que utilizemos consultas embutidas na clusula FROM de uma consulta,
fazendo com que a sada de um comando SELECT seja utilizada como entrada para outro comando SELECT. Outras
formas de combinarmos os dois ou mais comandos SELECT para obter um nico resultado final so subconsultas
da clusula WHERE, correlacionadas ou no, e as operaes baseadas nas operaes de conjunto.
Subconsultas da clusula WHERE
A utilizao de subconsultas na clusula WHERE uma das formas de combinao de duas ou mais consultas
para um nico resultado final. Nestas construes, o resultado da subconsulta no apresentado ao usurio,
sendo construdo de forma temporria pelo SGBD, o qual utiliza os resultados temporrios em testes das
consultas mais externas. Existem dois tipos de subconsultas: correlacionadas e no-correlacionadas.
Subconsultas no-correlacionadas
Com a utilizao do predicado IN era possvel comparar o valor de uma coluna com uma lista de valores. Na
subconsulta no-correlacionada, substitumos a lista de valores do predicado IN por uma consulta.
A sintaxe bsica do comando para utilizao da subconsulta no-correlacionada :
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA
WHERE COLM [NOT] IN (SELECT COLX FROM NOME_TABELA2)
Note que, esquerda do predicado [NOT] IN continua posicionada uma coluna (a utilizao do operador NOT
opcional). A consulta interna ao predicado IN (aquela que substitui a lista de valores), no tem nenhuma ligao
com a consulta externa. Ambas as consultas podero possuir todas as construes apresentadas anteriormente,
sem nenhuma restrio adicional devido presena da subconsulta. A consulta interna dever, no entanto,
retornar uma coluna apenas.
Exemplos:
Considerando a base de dados de publicaes composta pelas tabelas ASSUNTO, LIVRO e EDITORA, conforme
anteriormente. Desejamos saber os nomes das editoras que possuem livros j lanados.
Consulta:
SELECT NOME
FROM EDITORA
WHERE CODIGO IN ( SELECT EDITORA
FROM LIVRO
WHERE LANCAMENTO IS NOT NULL)
Neste exemplo, a subconsulta gera uma relao temporria de uma nica coluna (no exibida ao usurio em
nenhum momento) contendo os cdigos de editoras que publicaram livros que j foram lanados. A consulta
externa procurar por nomes de editoras para as quais o cdigo consta na relao produzida para subconsulta.
Desejamos saber quais assuntos no foram lanados livros.
SELECT DESCRICAO
FROM ASSUNTO
WHERE SIGLA NOT IN (SELECT ASSUNTO FROM LIVRO WHERE LANCAMENTO IS NOT NULL)
Neste exemplo, a subconsulta gera uma listagem de assuntos dos livros que j foram lanados. A consulta
externa procurar, na tabela de assuntos, quais assuntos no constam na listagem gerada pela subconsulta.

225

Tambm podemos utilizar subconsultas combinadas com operaes de atualizao e excluso de dados. Por
exemplo:
Desejamos excluir as editoras que no publicaram os livros. O comando para tal operao :
DELETE FROM EDITORA
WHERE CODIGO NOT IN (SELECT EDITORA FROM LIVRO)
Subconsultas Correlacionadas
possivel utilizar o predicado IN em conjunto com um commando SQL em uma construo chamada de nocorrelacionada. Agora, veremos outro tipo de construo, chamado de subconsulta no-correlacionada. Agora,
veremos outro tipo de construo, chamada de subconsulta correlacionada, pois, neste caso, a subconsulta
possui dependncia direta da consulta externa.
Na subconsulta correlacionada utilizaremos o predicado EXISTS. O predicado IN permitia testar se valores de
uma coluna constavam em uma listagem de valores. O predicado EXISTS testa se uma condio verdadeira ou
falsa. Vejamos exemplo da sintaxe para sua utilizao:
SELECT COL1, COL2, ..., COLN
FROM NOME_TABELA TAB_EXTERNA
WHERE [NOT] EXISTS
(SELECT COLX
FROM NOME_TABELA2 TAB_EXTERNA
WHERE TAB_EXTERNA.COLA = TAB_INTERNA.COLA)
Na subconsulta do exemplo anterior, existe uma comparao entre uma coluna da tabela externa com uma
coluna da tabela interna (em negrito). Este tipo de teste possvel em subconsultas, onde a consulta mais interna
poder acessar uma coluna da coluna mais externa, usualmente utilizando o apelido (ou correlation name) da
tabela mencionada da coluna mais externa, usualmente utilizando o apelido da tabela mencionada da consulta
mais externa.
Esse comando comea a ser executado pela consulta mais externa. Ento, para cada linha de NOME_TABELA,
a subconsulta ser executada, substituindo-se o valor de TAB_EXTERNA.COLA por seu valor na linha em questo.
Se a subconsulta retornar algum valor a clusula EXISTS ser verdadeira e a linha recuperada na consulta mais
externa far parte do resultado final. Em caso contrrio, a consulta mais externa realiza o teste para a prxima
linha de TAB_EXTERNA.COLA.
Note que, na utilizao do predicado EXISTS, no posicionada nenhuma coluna esquerda do mesmo, pois
ele no compara valores, e, sim, testa uma condio booleana. Assim, a coluna posicionada na clusula SELECT da
subconsulta no influenciar no resultado do comando.
Devido existncia, na subconsulta, da utilizao de uma coluna da consulta mais externa em uma
comparao, esta construo chamada de consulta correlacionada.
Vejamos os exemplos anteriores reescritos para o formato de subconsultas correlacionadas:
Desejamos saber os nomes das editoras que possuem livros lanados.
SELECT NOME
FROM EDITORA ED
WHERE EXISTS (SELECT EDITORA
FROM LIVRO
WHERE LANCAMENTO IS NOT NULL
AND ED.CODIGO = EDITORA)
Desejamos saber sobre quais assuntos nao foram lanados livros.
SELECT DESCRICAO
FROM ASSUNTO ASS
WHERE NOT EXISTS (SELECT ASSUNTO
226

FROM LIVRO
WHERE LANCAMENTO IS NOT NULL
AND ASS.SIGLA = ASSUNTO)
Assim como no caso do predicado IN, poderemos utilizar EXISTS em commandos de atualizao e excluso de
dados. Vejamos a reescrita do comando para excluso das editoras que no possuem livros associados, com a
utilizao de EXISTS:
DELETE FROM EDITORA E
WHERE NOT EXISTS (
SELECT 1 FROM LIVRO WHERE EDITORA = E.CODIGO)
Subconsultas substituindo valores
Em uma consulta, para cada linha da relao resultante temos, em uma dada coluna, uma pequena relao
de uma linha e uma coluna que pode ser substituda por um comando SELECT que retorne apenas uma linha e
uma coluna. Tal comando SELECT pode ser formador tanto de uma consulta correlacionada quanto de uma
consulta no-correlacionada.
Considere que desejamos montar uma relao que contenha em uma coluna a descrio dos assuntos
existentes e, em outra, a quantidade de livros lanados de cada assunto.
Para obter a coluna ASSUNTOS basta realizar uma seleo sobre a coluna DESCRIO da tabela de assuntos e
utilizar o apelido ASSUNTOS para a coluna. Para obter a coluna LIVROS_LANCADOS devemos contar, para cada
assunto, quantos livros j lanados existem na tabela de livros do assunto em questo. O comando que monta o
resultado anterior o seguinte:
SELECT DESCRICAO AS ASSUNTOS,
(SELECT COUNT(*)
FROM LIVRO L
WHERE L.ASSUNTO = A.SIGLA
AND LANCAMENTO IS NOT NULL
) AS LIVROS_LANCADOS
FROM ASSUNTO A
Note que, no comando anterior, foi utilizada uma subconsulta correlacionada substituindo um valor em um
comando SELECT e, para a qual, foi dado um apelido (LIVROS_LANCADOS). A subconsulta utilizada possui
somente uma coluna onde foi usada a funo COUNT que retorna somente uma linha, de forma a atender ao
requisito apresentado anteriormente. Como a correlao desta com a tabela externa (L.ASSUNTO = A.SIGLA) faz
com que a contagem de livros seja feita para o assunto adequado.
Outro exemplo:
Listar o nome das editoras e o preo mdio das publicaes de cada uma.
SELECT NOME,
(SELECT AVG(PRECO)
FROM LIVRO V
WHERE V.EDITORA = E.CODIGO
AND LANCAMENTO IS NOT NULL) AS PRECO_MEDIO
FROM EDITORA E
ORDER BY NOME
Poderemos utilizar subconsultas que retornem uma relao de uma linha e uma coluna em vrios comandos
e locais como, por exemplo, substituindo o valor no comando UPDATE TABELA SET COLUNA = VALOR.

227

Tabelas aninhadas
Uma tabela a materializao de uma relao. Quando realizamos uma consulta e posicionamos uma tabela
na clusula FROM, estamos fazendo uma consulta sobre uma relao. Logo, podemos substituir uma tabela por
uma subconsulta que retorne uma relao. A esta construo chamamos de tabelas aninhadas.
Para utilizarmos o resultado de uma consulta como uma tabela, devemos posicionar a consulta delimitada
por parnteses em local destinado a uma tabela. Para que possamos acessar as colunas do resultado da
subconsulta como se acessssemos as colunas de uma tabela, pode ser necessrio atribuir um apelido para a
subconsulta. Vejamos um exemplo de sintaxe para a juno entre uma tabela aninhada e uma tabela:
SELECT COL1, COL2, COLN, COLX, COLY, COLZ
FROM
(SELECT COLX, COLY, COLZ FROM TAB_INTERNA) TAB_CONSULTA
INNER JOIN TAB_EXTERNA
ON TAB_CONSULTA.COLX = TAB_EXTERNA.COL1
Notamos que a expresso TAB_CONSULTA.COLX representa o acesso coluna COLX do resultado da
subconsulta. Qualquer coluna da tabela aninhada poder ser acessada como uma coluna de uma tabela.
Listar o nome das editoras e as publicaes das editoras que lanaram ao menos dois livros, ordenados
por nome da editora e pelo ttulo da publicao.
SELECT NOME, TITULO
FROM
(SELECT EDITORA, COUNT(*) AS QUANTIDADE
FROM LIVRO V
WHERE LANCAMENTO IS NOT NULL
GROUP BY EDITORA) EDITORA_QUANT
INNER JOIN LIVRO
ON EDITORA_QUANT.EDITORA = LIVRO.EDITORA
INNER JOIN EDITORA
ON EDITORA_QUANT.EDITORA = EDITORA.CODIGO
WHERE QUANTIDADE >= 2
ORDER BY NOME
Essa relao, que no exibida ao usurio, utilizada exatamente como uma tabela e referenciada pelo
nome EDITORA_QUANT.
Listar os ttulos dos livros dos assuntos para os quais o preo mdio das publicaes superior a R$ 40,00,
juntamente com os respectivos assuntos.
SELECT TITULO, DESCRICAO AS ASSUNTO
FROM ( SELECT ASSUNTO, AVG(PRECO) AS PRECO_MEDIO
FROM LIVRO V
GROUP BY SIGLA
HAVING AVG(PRECO) > 40) ASSUNTO_PRECO
INNER JOIN LIVRO
ON ASSUNTO_PRECO.ASSUNTO = LIVRO.ASSUNTO
INNNER JOIN ASSUNTO
ON ASSUNTO_PRECO.ASSUNTO = ASSUNTO.SIGLA
Operaes de Conjunto
Podemos realizar as operaes tradicionais sobre conjuntos: unio, interseo, e diferena.
Unio
228

Quando realizamos junes entre tabelas, formamos uma relao resultante com as colunas que contm as
colunas das tabelas originais. Por outro lado, podemos querer realizar um comando SQL que apresente, como
resultado, todas as linhas que foram recuperadas por outros dois comandos SQL realizados em separado. Para
unir as linhas resultantes de duas ou mais consultas, utilizamos o predicado UNION.
O predicado UNION utilizado posicionado entre dois comandos de consulta, da seguinte forma:
SELECT COL1, COL2
FROM TABELA1
UNION [ALL]
SELECT COL3, COL4
FROM TABELA2
Observamos que os comandos podero acessar tabelas diferentes e utilizar as mais diversas construes da
linguagem. Existem, somente, duas regras para utilizao do UNION: (i) os comandos devem retornar o mesmo
nmero de colunas e (ii) as colunas correspondentes em cada comando devem possuir os mesmo tipos de dados.
O UNION ir atuar fazendo com que o resultado das consultas participante seja combinado com o resultado
final. Quando utilizamos o UNION isoladamente, no resultado final no constaro linhas repetidas. Se desejarmos
que linhas repetidas apaream, devemos utilizar o predicado ALL logo aps UNION, conforme mostrado antes.
* Listar os ttulos dos livros que cujo assunto Banco de Dados ou que foram lanados por editoras que
contenham Mirandela no nome.
SELECT TITULO
FROM LIVRO
INNER JOIN ASSUNTO
ON ASSUNTO = SIGLA
WHERE DESCRICAO = BANCO DE DADOS
UNION [ALL]
SELECT TITULO
FROM LIVRO
INNER JOIN EDITORA E
ON EDITORA = E.CODIGO
WHERE NOME LIKE %MIRANDELA%
Interseo
Para obtermos a interseo entre os resultados do comando SELECT, utilizamos o comando INTERSECT.
O INTERSECT utilizado da mesma forma que o UNION, posicionado entre dois comandos SELECT, e atende
s mesmas regras: (i) os comandos devem retornar o mesmo nmero de colunas e (ii) as colunas correspondentes
em cada comando devem possuir os mesmos tipos de dados. Ento, o INTERSECT retornar as linhas que estejam
presente nos resultados de todas as consultas participantes.
Da mesma forma que o UNION, o INTERSECT utilizado isoladamente eliminar as linhas repetidas. Para que
as linhas repetidas constem no resultado final, o predicado ALL deve ser utilizado.
Listar os ttulos dos livros cujo assunto Programao e que foram lanados por uma editora que
contenha a palavra Mirandela no nome, sem repeties.
SELECT TITULO
FROM LIVRO
INNER JOIN ASSUNTO
ON ASSUNTO = SIGLA
WHERE DESCRICAO = PROGRAMACAO
INTERSECT
SELECT TITULO
FROM LIVRO
229

INNER JOIN EDITORA E

ON EDITORA = E.CODIGO
WHERE NOME LIKE %MIRANDELA%
Diferena
Tambm possvel realizar a diferena entre os resultados de comandos SELECT. Neste caso, o predicado
utilizado o EXCEPT.
O EXCEPT ser utilizado da mesma forma que o UNION e o INTERSECT (entre os comandos SELECT). Estar
sujeito s mesmas duas regras apresentadas nos casos anteriores sobre o nmero de colunas e os tipos de dados
das mesmas. Isoladamente, ele no permite linhas repetidas no resultado final. Da mesma forma que o UNION e
o INTERSECT, ele pode ser utilizado em conjunto com o predicado ALL.
Exemplo: Listar os ttulos dos livros cujo assunto Banco de Dados e que no foram lanados por uma editora
que contenha a palavra Mirandela no nome.
SELECT TITULO
FROM LIVRO
INNER JOIN ASSUNTO
ON ASSUNTO = SIGLA
WHERE DESCRICAO = BANCO DE DADOS
EXCEPT
SELECT TITULO
FROM LIVRO
INNER JOIN EDITORA E
ON EDITORA = E.CODIGO
WHERE NOME LIKE MIRANDELA
Como o EXCEPT realiza a diferena entre conjuntos, a ordem de declarao das consultas com relao ao
predicado EXCEPT altera o resultado final, diferentemente do que acontece com os predicados UNION e
INTERSECT.
Listar o ttulo dos livros que foram lanados por editora que contenham a palavra Mirandela em seu
nome e cujo assunto no Banco de Dados.
SELECT TITULO
FROM LIVRO
INNER JOIN EDITORA E
ON EDITORA = E.CODIGO
WHERE NOME LIKE %MIRANDELA%
EXCEPT
SELECT TITULO
FROM LIVRO
INNER JOIN ASSUNTO
ON ASSUNTO = SIGLA
WHERE DESCRICAO = BANCO DE DADOS
Comandos e Estruturas Avanadas
A seguir sero apresentadas construes da SQL:2003 que permitem a realizao de consultas bastante
poderosas, como as consultas recursivas, ou de grande utilidade, como o predicado CASE e os comandos para
criao e excluso de vises. Tambm apresentado o comando MERGE, para incluso e atualizao de
informaes em tabelas.
Vises e Vises Temporrias
230

Muitas vezes gostaramos de utilizar os dados contidos em nosso banco de dados como se estivessem em um
formato diferente daquele em que realmente esto.
Consideremos uma situao em que queremos constantemente queremos consultar o ttulo de um livro, seu
preo, o nome da editora que o publica e a descrio do assunto do livro. Estas informaes esto contidas em
nosso banco de dados, mas espalhada em trs tabelas. Para uni-las devemos realizar o comando SELECT com
junes entre as tabelas. Entretanto, como a consulta realizada constantemente, gostaramos de ter uma
diferente viso de nosso banco de dados: gostaramos de ter uma viso onde as informaes j aparecessem
unidas. A linguagem SQL nos permite isso atravs da criao de um objeto chamado viso.
Vises so tabelas artificiais cujo contedo provm de tabelas reais. Os dados que as compem so definidos
atravs de comandos SELECT realizados sobre tabelas dos bancos de dados. Na verdade, os dados continuam
armazenados na tabela original. Cada vez que realizamos uma consulta sobre a viso, o SGBD se encarrega de
coletar os dados nas tabelas de origem, a partir do comando SELECT que definem a viso como se ela fosse uma
tabela.
Para criamos vises, utilizamos o comando CREATE VIEW, cuja estrutura bsica apresentada a seguir.
CREATE VIEW NOME_VISO
AS COMANDO DE CONSULTA
Vejamos, a seguir o comando para criao da viso que contm o ttulo dos livros, seus preos, o nome da
editora que os publica e a descrio de seus assuntos.
CREATE VIEW LIVRO_EDITORA_ASSUNTO
AS
SELECT TITULO, PRECO, NOME AS EDITORA,
DESCRICAO AS ASSUNTO
FROM LIVRO
INNER JOIN EDITORA ED
ON EDITORA = ED.CODIGO
INNER JOIN ASSUNTO
ON ASSUNTO.SIGLA = LIVRO.ASSUNTO
Agora, poderemos consultar a viso como se consultssemos uma tabela de nosso banco de dados. Como
exemplo, vamos apresentar o comando para obtermos o ttulo, o nome da editora, e a descrio do assunto dos
livros que possuem preo superior a R$ 45,00. Queremos a listagem ordenada por ttulo do livro.
SELECT TITULO, EDITORA, ASSUNTO
FROM LIVRO_EDITORA_ASSUNTO
WHERE PRECO > 45
ORDER BY TITULO
A definio de uma viso permanece no banco de dados, de forma que a viso pode ser acessada a qualquer
momento. Para apagarmos uma viso, utilizamos o comando DROP VIEW, seguido do nome da viso. A seguir,
como exemplo, temos o comando para excluso da viso
LIVRO_EDITORA_ASSUNTO
DROP VIEW LIVRO_EDITORA_ASSUNTO
Na excluso da viso, somente sua definio excluda. Os dados permanecem nas tabelas originais.
Por outro lado, podemos querer criar uma viso para ser utilizada em um comando somente, sem que sua
definio fique armazenada no banco de dados. Para isto, utilizamos o comando WITH. Uma estrutura simples
para o comando WITH apresentada a seguir.
WITH NOME_VISO_TEMPORRIA [(NOME_COLUNAS_VISO)]
AS
(COMANDO_DEFINIO_VISO)
COMANDO_DE_CONSULTA
231

Vamos, agora, como exemplo, utilizar o mesmo comando que colocou a viso LIVRO_EDITORA_ASSUNTO na
definio de uma viso temporria. Usaremos, tambm, a mesma consulta sobre esta viso que utilizamos
anteriormente.
WITH CONSULTA_EDITORA_ASSUNTO AS (
SELECT TITULO, PRECO, NOME AS EDITORA, DESCRICAO AS ASSUNTO
FROM LIVRO
INNER JOIN EDITORA ED
ON EDITORA = ED.CODIGO
INNER JOIN ASSUNTO
ON ASSUNTO.SIGLA = LIVRO.ASSUNTO)
SELECT TITULO, EDITORA, ASSUNTO
FROM LIVRO_EDITORA_ASSUNTO
WHERE PRECO > 45
ORDER BY TITULO
Consultas recursivas
A incluso de consultas na linguagem SQL permitiu a realizao de comandos que antes deveriam ser
realizados somente atravs da utilizao de linguagens de programao.
Vamos considerar um frum de mensagens na Intenet. Neste frum, o usurio pode enviar uma mensagem
ou responder a outra enviada anteriormente. O usurio pode, inclusive, responder a uma resposta anterior. Um
exemplo dessa estrutura apresentado na figura 8.1. Notamos que essa estrutura pode ser visualizada em
formato de rvore.
Em termos de modelagem, consideremos que a mensagem seja representada por um auto-relacionamento,
conforme a figura 8.2. Todas as mensagens podero estar contidas em uma nica tabela do banco de dados, da
qual temos um exemplo na tabela 8.1. Nesta tabela, a coluna ID_MENSAGEM chave primria, identificando
univocamente cada mensagem da tabela. A coluna ASSUNTO representa o assunto da mensagem. No caso de
uma mensagem estar respondendo outra, na coluna ID_MENSAGEMPAI estar contido o identificador da
mensagem que est sendo respondida. Em caso contrrio, esta coluna estar vazia.

232

Se desejarmos obter quais as respostas para a mensagem de nmero 1, basta realizarmos uma consulta
procurando as linhas onde a coluna ID_MENSAGEMPAI possui o valor 1. Entretanto, podemos querer obter todas
as mensagens originadas a partir da pergunta de mensagem de nmero 1, ou seja, todas aquelas que esto
diretamente respondendo mensagem de nmero 1, aquelas que respondem a respostas da mensagem de
nmero 1 e assim por diante. Para obter todas essas mensagens, termos que utilizar uma consulta recursiva.
Consultas recursivas utilizam-se da clusula WITH combina com os comandos SELECT e UNION ALL.
A construo a ser utilizada semelhante apresentada anteriormente. A principal diferena reside na
construo da consulta que define a viso. Esta dever conter consultas, unidas via UNION ALL. A primeira, mais
bsica, define a semente do comando, acessando a linha a partir da qual iremos querer disparar a recurso. A
segunda conter uma segunda definio de tabela, ligada primeira, montando a clusula da recurso.
Assim, para o exemplo anterior, onde queremos obter todas as mensagens que foram originadas a partir da
mensagem de nmero 1, devemos utilizar o seguinte comando listado a seguir.
WITH JA_SELECIONADO
(ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI)
AS
(SELECT ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI
FROM MENSAGEM
WHERE ID_MENSAGEM = 1
UNION ALL
SELECT M.ID_MENSAGEM, M.ASSUNTO, M.ID_MENSAGEM_PAI
FROM JA_SELECIONADO J, MENSAGEM M
WHERE J.ID_MENSAGEM = M.ID_MENSAGEM_PAI)
SELECT * FROM JA_SELECIONADO
Note, no comando, que utilizamos a consulta
SELECT ID_MENSAGEM, ASSUNTO, ID_MENSAGEM_PAI
FROM MENSAGEM
WHERE ID_MENSAGEM = 1
233

Como semente da recurso, selecionando a primeira linha da tabela temporria J_SELECIONADO. O

comando SELECT, que se une a este, acessa as tabelas MENSAGEM e J_SELECIONADO, unindo-as pela chave
estrangeira e fazendo com que novas linhas sejam adicionadas viso temporria.
Embora as consultas recursivas tenham sido um grande avano, elas tambm criaram um novo problema a
ser tratado: o loop infinito. Assim, ao construirmos consultas recursivas, devemos estar atentos para mont-las de
forma a que tenham fim.
Predicado CASE
Algumas vezes queremos selecionar resultados diferentes em funo de uma ou mais condies. O predicado
CASE, que pode ser utilizado em conjunto com comandos SELECT, permite que realizemos tal tarefa.
Existem duas diferentes construes para o predicado CASE. A construo mais simples possui o seguinte
formato:
CASE COLUNA
WHEN VALOR THEN RESULTADO
WHEN VALOR2 THEN RESULTADO2
...
[ELSE RESULTADO_ELSE]
END
Para os livros cujo assunto B, retornar o ttulo concatenado com a expresso -MUITO INTERESSANTE.
Para aqueles cujo assunto P retornar o ttulo concatenado com a expresso -INTERESSANTE MDIO.
Para os outros retornar a expressao -SEM INTERESSE concatenada com seu ttulo. Consideremos a
Tabela 6.1 como a instncia para a tabela LIVRO.
SELECT CASE ASSUNTO
WHEN B THEN TITULO || -MUITO INTERESSANTE
WHEN P THEN TITULO || -INTERESSE MDIO
ELSE TITULO || -SEM INTERESSE
END AS IMPORTANCIA
FROM LIVRO

O segundo formato da expresso CASE permite que testes envolvendo diferentes colunas, variveis e
expresses sejam avaliados. Sua estrutura a seguinte:
CASE
WHEN EXPRESSAO_BOOLEANA THEN RESULTADO
WHEN EXPRESSAO_BOOLEANA2 THEN RESULTADO2
...
[ELSE RESULTADO_ELSE]
END
Consideremos, novamente, o exemplo de instncia para a tabela LIVRO apresentado na tabela 6.1. Para
os livros que possuem data de lanamento e o preo superior a R$ 45,00 retornar o ttulo concatenado
com a expresso -LIVRO CARO. Para aqueles que no possuem data de lanamento, mas possuem
editora, retornar o ttulo concatenado com a expresso - LANCAMENTO EM BREVE. Para aqueles que
no possuem editora, retornar o ttulo concatenado com a expressao -LIVRO BARATO.
SELECT CASE
WHEN LANCAMENTO IS NOT NULL AND PRECO > 40
THEN TITULO || LIVRO CARO
WHEN LANCAMENTO IS NOT NULL AND EDITORA IS NOT NULL
THEN TITULO || LANCAMENTO EM BREVE

234

WHEN EDITORA IS NULL

THEN TITULO || EM PREPARACAO
ELSE TITULO || LIVRO BARATO
END AS IMPORTANCIA
FROM LIVRO
CASE pode ser utilizado em consultas SELECT que tenham complexidade que desejemos. Pode, inclusive, ser
utilizado na clusula WHERE. Exemplo:
As vrias editoras esto estudando a aplicao de diferentes fatores a reajustes de preos. Queremos
saber quais os ttulos dos livros que custaro acima de R$50,00 caso a editora VIA-NORTE aplique um
reajuste de 10% nos preos de seus livros e a editora ILHAS TIJUCAS aplique um reajuste de 25%.
SELECT TITULO
FROM LIVRO
INNER JOIN EDITORA
ON EDITORA = EDITORA.CODIGO
WHERE 50 < (CASE WHEN NOME= EDITORA VIA-NORTE
THEN PRECO *1.1
WHEN NOME = EDITORA ILHAS TIJUCAS
THEN PRECO * 1.25
ELSE PRECO
END)
Comando MERGE
Suponhamos que tenhamos uma tabela de clientes. A descrio da tabela de clientes ser apresentada na
figura 8.3. Esta tabela possui vrias linhas, sendo que, algumas delas so referentes a pessoas que tambm atuam
como atores e que tambm esto cadastradas na tabela de autores.

Foi decidido que todos os autores sero

cadastrados como clientes. Para os autores que j se encontram cadastrados como clientes, deveremos atualizar
as informaes na tabela de clientes com base nos dados da tabela de autores.
Para realizar tais operaes utilizando os comandos INSERT e UPDATE, teramos que percorrer todas as linhas
da tabela de autores, verificando cada uma se o autor j est cadastrado como cliente. Caso no esteja, teramos
que realizar um comando INSERT para cadastr-lo. Caso o autor j estivesse cadastrado, teramos que fazer um
comando UPDATE, para atualizar essas informaes na tabela de clientes. Para simplificar situaes como essa,
foi criado o comando MERGE (algumas vezes conhecidos como UPSERT, devido s suas circunstncias).
MERGE faz, automaticamente, comparaes entre informaes de tabelas, inserindo as linhas que no existem e
atualizando as outras. Uma sintaxe simplificada para o comando MERGE apresentado a seguir:
MERGE INTO TABELA_DESTINO [AS APELIDO_DESTINO]
USING TABELA_ORIGEM [AS APELIDO_ORIGEM]
ON (EXPRESSAO_BOOLEANA)
WHEN MATCHED THEN OPERAO_VERDADEIRO
WHEN NOT MATCHED THEN OPERAO_FALSO
Vejamos, a seguir, como exemplo, a realizao da incluso e atualizao dos dados de autores como clientes,
conforme descrito anteriormente, atravs do comando MERGE.
MERGE INTO CLIENTE CLI
235

USING AUTOR AU
ON (AU.CPF = CLI.CPF)
WHEN MATCHED THEN
UPDATE SET CLI.NOME = AU.NOME
CLI.ENDERECO = AU.NOME,
CLI.DATA_NASCIMENTO = AU.DATA_NASCIMENTO
WHEN NOT MATCHED THEN
INSERT(CODIGO, NOME, CPF, ENDERECO, DATA_NASCIMENTO)
VALUES (AU.MATRICULA, AU.NOME, AU.CPF, AU.ENDERECO, AU.DATA_NASCIMENTO)
Transaes e Concorrncia
Uma transao formada por um conjunto de comandos SQL que so atmicos no que diz respeito sua
execuo e recuperao do banco de dados. Cada comando executado em um banco de dados faz parte de uma
transao, mesmo que unitria. As propriedades ACID (Atomicidade, Consistncia, Isolamento e Durabilidade) so
importantes propriedades em transaes. Para implement-las, os SGBDs utilizam mecanismos que podem
reduzir o nvel de concorrncia do sistema como um todo.
SGBDs so sistemas que, em situaes reais podem ser acessados por milhares de usurios
concorrentemente. So comuns situaes onde vrios usurios realizam consultas e atualizaes nos mesmos
dados. Na situao ideal, cada usurio de um banco de dados deveria executar os seus comandos como se ele
fosse o nico usurio. Esse o maior nvel de isolamento a ser obtido. Entretanto, muito baixo o nvel de
concorrncia correspondente a tal nvel de isolamento. Neste caso, usurios podero ficar aguardando por
informaes durante tempos relativamente longos, espera do trmino de outras transaes.
De forma a aumentar os nveis de concorrncia em detrimento do isolamento, a SQL define quatro nveis de
isolamento: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ e SERIAZABLE.
Iniciando, Alterando e Concluindo Transaes
Se uma transao for concluda com sucesso, as alteraes por ele realizadas no podero ser desfeitas.
Mesmo que ocorram falhas no sistema, o SGBD deve prover mecanismos para recuperao de informaes de
forma a manter o estado que as mesmas possuam quando da confirmao do trmino de uma transao.
De forma anloga, se uma transao concluda com fracasso, o SGBD deve desfazer todas as operaes de
atualizao dos dados contidas na transao em questo, retornando o banco de dados para o estado em que
estava ao incio da transao.
Iniciando uma Transao
O comando a seguir uma simplificao do comando de incio de uma transao no padro SQL:2003:
START TRANSACTION [NIVEL_DE_ISOLAMENTO]
Concluindo uma Transao
Uma transao pode ser concluda com sucesso ou com fracasso. Para concluirmos uma transao com
sucesso, utilizamos o comando:
COMMIT [WORK]
Para terminar uma transao com fracasso, ou seja, para desfazer todas as aes ocorridas durante a
transao, retornando ao seu estado inicial, utilizamos o comando:
ROLLBACK [WORK]
Por exemplo: Considere a instncia da tabela ASSUNTO representa na tabela 3.2. Considere que uma transao
foi iniciada e que os dois comandos a seguir foram executados:
236

INSERT INTO ASSUNTO (SIGLA, DESCRICAO)

VALUES (X, XML)
UPDATE ASSUNTO SET DESCRICAO = BIOINFORMATICA WHERE SIGLA = B
A nova instncia da tabela representada na tabela 9.1. No entanto, essa instncia est sendo vlida para a
transao em questo. Ento, consideremos que os comando a seguir foi realizado.
ROLLBACK
Neste caso, todas as alteraes foram desfeitas, ou seja, a tabela ASSUNTO voltou a ter o contedo da tabela
3.2.
Se, ao invs de desfazermos as alteraes, quisssemos mant-las, tomando a instncia representada pela
tabela 9.1 definitiva, bastaria realizar o comando COMMIT ao invs do comando ROLLBACK.
Inserindo figura da pgina 8.1
Marcando pontos de retorno
A SQL permitem que sejam definidos marcadores durante uma transao chamados de pontos de
salvamento (SAVEPOINT). A transao pode, ento, ser desfeita at um ponto de salvamento, tornando sem
efeito os comandos que foram executados aps o mesmo.
Os pontos de salvamento somente so validos dentro de transaes que foram definidos. No possvel
retornar um ponto de salvamento aps a concluso da transao, quer seja com sucesso ou com fracasso.
Um ponto de salvamento pode ser definido atravs do comando:
SAVEPOINT IDENTIFICADOR_DO_SAVEPOINT
Para retornar a um ponto de salvamento, devemos utilizar o comando ROLLBACK em conjunto com a clusula
TO SAVEPOINT, conforme mostrado a seguir:
ROLLBACK [WORK] TO SAVEPOINT IDENTIFICADOR_DO_SAVEPOINT
Consideremos a instncia da tabela ASSUNTO representada na tabela 3.2. Considere que uma transao
foi iniciada e que os trs comandos a seguir foram executados.
INSERT INTO ASSUNTO (SIGLA, DESCRICAO)
VALUES (X, XML)

SAVEPOINT PONTO1
UPDATE ASSUNTO SET DESCRICAO = BIOINFORMATICA
WHERE SIGLA = B
A nova instncia da tabela est representada na tabela 9.1. Ento, consideremos que o comando a seguir foi
realizado:
ROLLBACK TO SAVEPOINT PONTO1
Neste caso, o comando UPDATE foi desfeito. O contedo temporrio da tabela ASSUNTO est representado
na tabela 9.2, mas a transao continua ativa. Neste caso, novos comandos podem ser realizados antes da
finalizao da transao. Se, neste ponto, o comando COMMIT for executado, a tabela ASSUNTO ser confirmada
com contedo idntico ao da tabela 9.2. Se um comando ROLLBACK for executado, contedo da tabela ASSUNTO
voltar a ser da tabela 3.2.

237

Para destruir um ponto de salvamento, devemos utilizar o comando:

Concorrncia e Nveis de isolamento
Cada transao realizada em um SGBD tem um nvel de isolamento. So quatro os nveis de isolamento
definidos no padro SQL: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, e SERIAZABLE. O nvel de
isolamento mais alto, SERIAZABLE, faz com que as operaes sejam executadas como se a transao em questo
fosse a nica ocorrendo no sistema. Esse nvel de isolamento diminui o nvel de concorrncia. Por outro lado, os
nveis de isolamento mais baixos, que aumentam os nveis de concorrncia podem levar a aparentes problemas
de consistncia das informaes.
Consideremos um ambiente onde no existe isolamento entre as transaes. As alteraes realizadas por um
usurio so imediatamente vistas por todos. Neste caso, dentre os fenmenos possveis de ocorrer, temos:
Leitura Suja leitura de dados no confirmados. Suponha que ocorram os seguintes passos:
1. Duas transaes, T1 e T2 so iniciadas;
2. A transao T1 modifica a linha L1;
3. A transao T2 l a linha L1 antes que T1 termine;
4. T1 termina com fracasso e suas operaes so desfeitas;
Neste caso, T2 ter lido uma informao que nunca foi confirmada.

Leitura No-Repetida: duas leituras de dados da mesma transao no se repetem. Na segunda leitura,
dados antigos no existem ou foram modificados. Suponha que ocorram os seguintes passos:
1. Duas transaes T1 e T2 so iniciadas;
2. A transao T1 l a linha L1;
3. A transao T2 modifica a linha L1, atualizando seus dados ou apagando a linha;
4. A transao T2 concluda com sucesso e suas operaes so confirmadas;
5. A transao T1 l (ou tenta ler) a linha L1. T1 nunca modificou os dados da linha L2, mas no obteve a
mesma leitura duas vezes dentro da mesma transao.

Leitura Fantasma: na leitura de um conjunto de dados, surgem novas informaes no conjunto. Suponha
que ocorram os seguintes passos:
1. Duas transaes T1 e T2 so iniciadas;
2. A transao T1 l um conjunto de linhas que atendem a uma condio C1;
3. A transao T2 executa uma operao de atualizao que cria uma ou mais que atendem condio
C1;
4. A transao T1 l, novamente, um conjunto de linhas que atendem a uma condio C1. Embora T1
no tenha criado linhas que atendam condio C1, novas linhas participaro do resultado da
consulta;
Perda de atualizao: duas transaes que ocorrem simultaneamente atualizam o mesmo dado no banco
de dados. Isto pode ocorrer em uma sequencia segundo a qual uma das atualizaes perdida:
1. Duas transaes, T1 e T2, so iniciadas;
2. A transao T1 l o dado D1 e armazena seu valor na varivel X;
3. A transao T2 l o dado D1 e armazena seu valor na varivel Y;
4. A transao T1 atualiza D1 com o valor de 6*X;
5. A transao T2 atualiza D1 com o valor de 0.5*Y;
238

6. A transao T1 termina com sucesso;

7. A transao T2 termina com sucesso.
Para a transao T1, ao seu final, o valor de D1 deveria ter sido multiplicado por seis. J para T2, ao seu final,
o valor de D1 deveria ser a metade do seu valor original. Se as transaes T1 e T2 fossem executadas em srie,
independente da ordem, o valor final de D1 deveria ser a metade do valor original. Entretanto, na ordenao de
comandos demonstrada antes, o valor final de D1 a metade do original, como se a atualizao realizada por T1
nunca tivesse sido realizada.
Os quatros nveis de isolamento da SQL podem ser definidos de acordo com sua relao com os quatro
fenmenos listados. Essa relao mostrada na tabela 9.3.

O nvel de
isolamento a ser utilizado pode ser definido atravs de uma clusula nos comandos de incio de uma transao,
conforme foi apresentado. Pode, tambm, ser definido em um comando de alterao das propriedades da
transao, o comando:
SET TRANSACTION ISOLATION LEVEL NIVEL_DE_ISOLAMENTO
Por exemplo, alterar o nvel de isolamento de uma transao para SERIAZABLE:
SET TRANSACTION ISOLATION LEVEL SERIAZABLE
Programas e Gatilhos Armazenados
A linguagem SQL uma linguagem diferente das linguagens tradicionais, como C e Pascal. Ao contrrio de
linguagens como estas, no SQL especificamos o resultado que queremos obter, sem nos preocuparmos com a
sequencia de passos a serem para obteno do resultado. Por isso, a SQL classificada como uma linguagem
declarativa.
Por outro lado, SGBDs se tornaram pontos cruciais em ambientes coorporativos, sendo acessos por diversos
sistemas. A partir da, surgiram, em algumas situaes, duas necessidades: (i) mover a especificao e execuo
de rotinas que verificam e implementam regras de negcio para o prprio SGBD, centralizando, assim, tais
operaes e as disponibilizando para toda a empresa de uma s vez, e (ii) fornecer ao SGBD algum tipo de
comportamento ativo (ou reativo) a determinadas situaes.
De forma a permitir a migrao das regras de negcio para o gerenciador de banco de dados foram definidos,
na SQL, os conceitos de procedimento e funo armazenados. Estes so pequenos programas compilados,
armazenados e executados diretamente no servidor de banco de dados. So invocados atravs de comandos SQL.
J para adicionar ao SGBD comportamento reativo, foi introduzido, na linguagem SQL, o conceito de gatilho.
Este um mecanismo que permite a execuo automtica de comandos ou, at mesmo, programas, a partir de
eventos que ocorrem na base de dados (como a atualizao do contedo de uma clula, por exemplo).
Para permitir a definio de blocos de programas a serem armazenados no SGBD, a SQL foi estendida com
comandos tpicos de linguagens no-declarativas, como comandos de iterao e de deciso, por exemplo. Estes
blocos compem o corpo no s de procedimentos e funes armazenados nos servidores, mas, tambm, de

239

gatilhos. Os SGBDs apresentam tambm, conjuntos prprios de comandos de controle. No Oracle, a linguagem
de programao, chama-se PL/SQL. J no SQL Server, chama-se Transact SQL.
Bloco de Comandos
Para permitir a criao de programas com SQL, foi criado o conceito de blocos de comandos. Alm disso,
foram incorporados linguagem vrios comandos de controle similares aos existentes em outras linguagens de
programao.
Blocos de comandos so pequenos programas compostos de um ou mais comandos SQL. Permitem a
especificao de variveis e cursores prprios aos blocos. Sua estrutura a seguinte:
BEGIN
DECLARAO DE VARIVEIS
DECLARAO DE CURSORES
LISTA DE COMANDOS SQL
END
Existe, ainda, no padro SQL:2003, a possibilidade de declarao de handles, objetos que iro tratar excees
ocorridas durante a execuo de blocos de comandos.
Declarao de Variveis: em um bloco de comandos, podemos declarar quantas variveis locais forem
necessrias. Para isso, utilizamos a seguinte estrutura:
DECLARE NOME_VARIAVEL1, NOME_VARIAVEL2, ...,
NOME_VARIAVELN TIPO_DE_DADOS
Cursores OPEN, FETCH e CLOSE: cursores so mecanismos que permitem que as linhas de uma tabela sejam
manipuladas uma a uma. Atuam como ponteiros que apontam para as linhas que formam o resultado de uma
dada consulta. Podemos recuperar e manipular os valores de cada linha apontada por um cursor.
Desta forma, deve existir um comando SELECT associado a um cursor. Para declarar um cursor e seu
comando associado, utilizamos o comando DECLARE CURSOR, conforme mostrado a seguir:
DECLARE CURSOR
FOR COMANDO_SELECT
[FOR UPDATE]
Um cursor no deve ser, somente, declarado. Para manipularmos os dados, devemos, inicialmente, abrir um
cursor. Para isso, utilizaremos o comando OPEN seguido do nome do cursor, conforme a seguir:
OPEN NOME_CURSOR
Neste momento, o resultado do comando SQL que define o cursor estar pronto para ser manipulado. Ento,
para posicionarmos o ponteiro, devemos utilizar o comando FETCH. Esse comando ir posicionar o ponteiro em
uma dada linha e atribuir as informaes apontadas para um conjunto de variveis. Ento, aps a atribuio,
poderemos manipular as variveis que recebem o valor de um cursor como tratamos quaisquer outras. FETCH
ter a seguinte estrutura:
FETCH NOME_CURSOR
INTO VARIAVEL1, ..., VARIAVELN
O comando FETCH , usualmente, utilizado em conjunto com um comando de iterao, como os comandos
REPEAT e WHILE, que sero apresentados ainda nesta seo.
Ao final de sua utilizao, o cursor deve ser fechado. Para fechar o cursor, utilizamos o comando CLOSE
seguido do nome do cursor, conforme representado a seguir:
240

CLOSE NOME_CURSOR
Atravs do comando FOR, poderemos declarar, abrir, navegar, e fechar cursores em um nico comando. O
comando FOR ser apresentado mais adiante.
Atribuio de Valores: podemos utilizar variveis em blocos de comandos. Para atribuirmos valores a variveis,
utilizaremos o comando SET da seguinte forma:
SET NOME_VARIAVEL = VALOR;
Por exemplo: Bloco de comando contendo a declarao de uma varivel X, de tipo caractere de comprimento
cinco, e atribuio do valor OI a X.
BEGIN
DECLARE X CHAR(5);
SET X = OI;
END
Comando FOR: FOR um comando bastante til, pois permite que, atravs de um s comando, seja declarado
como cursor, que seu contedo seja percorrido e que tal cursor seja fechado. O cursor fechado
automaticamente ao final do comando. FOR deve ser utilizado quando a navegao se faz de forma seqencial e
atravs de todas as linhas do resultado da consulta de declarao do cursor. Sua estrutura mostrado a seguir.
FOR
NOME_CURSOR [CURSOR FOR]
COMANDO_SELECT
DO LISTA DE COMANDOS SQL
END FOR
Ao incio de FOR o cursor declarado e aberto. O ponteiro posicionado na primeira linha do resultado da
consulta. Ento, os comandos SQL contidos na lista de comandos so executados. Ao chegar a END FOR, a
execuo retorna para FOR que, desta vez, percebe que o cursor j est aberto e posiciona o ponteiro na prxima
linha do resultado da consulta. Novamente, o conjunto de comandos SQL executado. O lao se repete at que
todas as linhas resultantes do comando SELECT tenham sido percorridas.
Comando SELECT INTO: atribui um valor a uma varivel. O valor atribudo recuperado a partir de uma consulta.
A consulta deve retornar somente uma linha. A seguir apresentado um formato para o comando.
SELECT COL1, COL2, ..., COLN
INTO VAR1, VAR2, ..., VARN
FROM NOME_TABELA
Comando IF: para permitir decises, foi incorporado linguagem SQL o comando IF. Esta testa se uma condio
booleana verdadeira e, em funo do resultado dos testes, executa um determinado conjunto de comandos.
Sua estrutura :
IF CONDICAO_BOOLEANA THEN
LISTA DE COMANDOS SQL
[ELSE IF CONDICAO_BOOLEANA THEN
LISTA DE COMANDOS SQL]
[ELSE LISTA DE COMANDOS SQL]
END IF

241

Comando WHILE: permite que a execuo de um conjunto de comandos se repita enquanto determina se a
condio verdadeira. Sua estrutura :
WHILE CONDICAO_BOOLEANA DO
LISTA DE COMANDOS SQL
END WHILE
Comando REPEAT: permite que a execuo de um conjunto de comandos se repita enquanto determinada
condio for falsa. Os comandos sero executados ao menos uma vez, independente do valor da condio.
REPEAT
LISTA DE COMANDOS SQL
UNTIL CONDICAO_BOOLEANA
END REPEAT
Comando LOOP: assim como WHILE e REPEAT, LOOP permite a repetio na execuo de um conjunto de
comandos. Entretanto, no caso de LOOP, no existe uma condio a ser testada. Para que a repetio termine,
outro comando deve ser utilizado. Segundo a SQL, o comando LEAVE termina o lao. Na estrutura de LOOP, que
apresentado a seguir, temos LOOP e END LOOP como delimitadores do comando e conjunto de comandos a
serem executados, representados por uma lista de comandos SQL. LEAVE deve ser posicionado na lista de
comandos SQL.
LOOP
LISTA DE COMANDOS SQL
END LOOP
Procedimentos armazenados e Funes
Os blocos e comandos apresentados anteriormente permitem a construo de rotinas que sero executadas
no servidor de banco de dados. Tais rotinas podem possuir cdigo extenso e serem bastante complexas.
Armazenar tais rotinas no servidor e permitr que sejam invocadas a partir da prpria linguagem SQL aumenta em
muito a utilidade de sua construo. Para permitir essa definio e armazenamento, esto definidas, na
linguagem SQL, os conceitos de procedimentos e funes armazenados no servidor.
Procedimentos armazenados
Procedimentos armazenados (stored procedures) so procedimentos anlogos aos existentes em linguagens
de programao tradicionais, mas que tero seu cdigo-fonte armazenado no servidor de banco de dados, o que
capaz de compil-lo e execut-lo.
Assim como em outras linguagens, os procedimentos podero receber valores como parmetros. Esses
parmetros so definidos no cabealho de procedimentos. Eles tm um nome, um tipo de dados e um modo.
Existem trs modos para os parmetros na SQL:2003: (i) parmetros que permitem apenas que os valores
externos das variveis sejam passados dentro do procedimento (idntico s passagens por valor de outras
linguagens); (ii) modo onde as variveis internas ao procedimento referentes aos parmetros no recebem
valores das variveis externas correspondentes, mas alteraes de valores ocorridas nos procedimentos so
efetivadas nas variveis externas correspondentes; e (iii) os valores externos so passados para dentro do
procedimento e as modificaes ocorridas internamente so efetivadas para as variveis externas (modo
semelhante s passagens por referncia de outras linguagens). Parmetros do primeiro modo so identificados
pela palavra reservada IN. A palavra OUT identifica os parmetros do segundo modo. J os parmetros que
pertencem ao terceiro modo so identificados pela palavra reservada INOUT. O primeiro passo para a utilizao
de procedimentos armazenados a sua criao no servidor. Para criar um procedimento armazenado, utilizamos
o comando CREATE PROCEDURE. Uma estrutura bsica para este comando apresentado a seguir.
CREATE PROCEDURE NOME_PROCEDURE(
242

MODO_PARAM1 NOME_PARAM1 TIPO_PARAM1,

MODO_PARAM2 NOME_PARAM2 TIPO_PARAM2,
...
MODO_PARAMN NOME_PARAMN TIPO_PARAMN
BLOCO_DE_COMANDOS_SQL
Consideremos, por exemplo, o procedimento PRECO_MEDIO apresentado a seguir. Ele possui dois
parmetros. O primeiro, NMERO_LIVROS, um parmetro de entrada que recebe do ambiente externo o
nmero total de livros a ser considerado. O segundo parmetro, PRECO_MEDIO, um procedimento e este valor
estar visvel para a varivel externa correspondente ao parmetro. Aps a declarao da linguagem utilizada,
est sendo criado um bloco de comandos SQL. Neste bloco, declarada uma varivel (V_VALOR_TOTAL),
utilizado um cursor (MEUCURSOR), manipulado atravs do comando FOR, e o valor mdio dos preos dos livros
calculado. Tal valor atribudo varivel PRECO_MEDIO, segundo parmetro do procedimento.
CREATE PROCEDURE PRECO_MEDIO
(IN NMERO_LIVROS INTEGER, OUT PRECO_MEDIO REAL)
LANGUAGE SQL
BEGIN
DECLARE V_VALOR_TOTAL REAL;
SET PRECO_MEDIO = 0;
SET V_VALOR_TOTAL = 0;
FOR MEU_CURSOR AS
SELECT PRECO FROM LIVRO
DO
SET V_VALOR_TOTAL = V_VALOR_TOTAL + PRECO;
END FOR;
SET PRECO_MEDIO = V_VALOR_TOTAL / NMERO_LIVROS
END
Aps a criao do procedimento, este fica armazenado no servidor de banco de dados e est pronto para ser
utilizado, bastando acion-lo a partir de um bloco de comandos. Para isso, devemos utilizar seu nome e variveis
correspondentes aos parmetros entre parnteses, quando for o caso. A seguir temos um exemplo de chamada
ao procedimento PRECO_MEDIO:
BEGIN
DECLARE V_NUMERO INTEGER;
DECLARE MDIA REAL;
...
PRECO_MEDIO(V_NUMERO, MDIA);
...
END
Para destruirmos um procedimento de nosso banco de dados, devemos utilizar o comando DROP
PROCEDURE seguido do nome do procedimento a ser destrudo, conforme mostrado a seguir.
DROP PROCEDURE NOME_PROCEDIMENTO;
Como exemplo, vamos destruir o procedimento PRECO_MEDIO:
DROP PROCEDURE PRECO_MEDIO;
Funes Armazenadas

243

Alm de procedimentos, o SQL permite que armazenemos funes no servidor de banco de dados. A funo
pode receber e tratar diversos parmetros de uma mesma maneira que o procedimento. A diferena entre um
procedimento e uma funo reside no fato de que a funo sempre retorna um valor. Assim, para criar uma
funo, utilizamos o comando CREATE FUNCTION ao invs do comando CREATE PROCEDURE. Como a funo
retorna um valor, no comando CREATE FUNCTION devemos especificar o tipo de dados retornado pela funo. O
exemplo da estrutura de CREATE FUNCTION similar a CREATE PROCEDURE. A nica diferena, alm do nome do
comando, reside na introduo da clusula RETURNS, onde o TIPO_RETORNO representa o tipo de dados
retornado pela funo.
CREATE FUNCTION NOME_FUNO (
MODO_PARAM1 NOME_PARAM1 TIPO_PARAM1,
MODO_PARAM2 NOME_PARAM2 TIPO_PARAM2,
...
MODO_PARAMN NOME_PARAMN TIPO_PARAMN
) RETURN TIPO_RETORNO [LANGUAGE NOME_LINGUAGEM]
BLOCO DE COMANDOS SQL
Dentro do bloco de comandos do corpo da funo devemos ter um comando RETURN seguido do valor a ser
retornado pela mesma. Exemplo:
RETURN 3.65;
A chamada para execuo de funes um pouco diferente da chamada para execuo de procedimentos.
Como funes retornam um valor, o nome da funo aparece ao lado direito do comando de atribuio de
valores. Por exemplo:
BEGIN
DECLARE V_NUMERO INTEGER;
DECLARE MDIA REAL;
...
SET MDIA = FUNC_PRECO_MEDIO(V_NUMERO);
...
END
Funes armazenadas podem, ainda, ser utilizadas em comandos SQL da mesma forma que as funes da
prpria linguagem, j apresentadas anteriormente.
Para destruirmos funes, utilizamos o comando DROP FUNCTION seguido do nome da funo.
DROP FUNCTION FUNC_PRECO_MEDIO
Gatilhos
Gatilhos so especificaes de aes a serem realizadas sempre que um dado evento ocorrer sobre um dado
objeto. Entre os eventos possveis, temos a incluso, atualizao ou excluso de informaes de uma tabela.
Um gatilho executa um conjunto de comandos, definido num bloco de comandos similar aos apresentados
anteriormente. Este bloco pode ser executado uma vez para cada evento que disparou o gatilho ou uma vez para
cada linha afetada pelo evento em questo. No primeiro caso, dizemos que se trata de um evento ao nvel de
comando e, no segundo, ao nvel de linha.
Entretanto, podemos querer que o bloco de comandos seja acionado somente em algumas circunstncias e
no todas as vezes que o evento disparador do gatilho ocorrer. A linguagem SQL nos permite realizar tal ao
atravs da incluso de uma condio booleana na declarao do gatilho. Devido s suas caractersticas, os
gatilhos so conhecidos por atenderem regra ECA Evento, Condio e Ao.

244

Um gatilho pode ser executado antes ou aps a execuo do comando que o disparou. Entretanto, em ambos
os casos, podemos querer acessar os dados nos formatos que teriam antes ou aps a execuo de tal comando.
Ou seja, podemos, por exemplo, aps a realizao de uma atualizao, querer testar se o novo valor de uma dada
coluna diferente do valor anterior.
Para permitir o acesso duas verses das informaes de uma dada linha dentro de um gatilho, foram
definidas as tabelas de transio NEW e OLD. NEW contm a nova verso das informaes e OLD, a verso antiga.
Note que os eventos podem ser operaes de incluso, atualizao e excluso. No caso de uma operao de
incluso, OLD est vazia, pois a informao no existia antes do evento. Caso o evento seja um operao de
excluso, NEW est vazia, pois a informao no mais existe aps o comando. Quando o evento disparador uma
operao de atualizao, tanto NEW quanto OLD possuem dados. A seguir, apresentaremos a sintaxe bsica para
a declarao de um gatilho:
CREATE TRIGGER NOME_GATILHO
MOMENTO_EXECUO
EVENTO_DISPARADOR
ON TABELA_EVENTO
[REFERENCING NEW AS NOVO_NOME_N OLD AS NOVO_NOME_O]
[NIVEL_GATILHO]
[CONDICAO_EXECUCAO]
BLOCO_DE_COMANDOS_SQL
Por exemplo: Suponha que desejamos armazenar, sempre que um livro sofra um aumento de preo superior a
20%, seu cdigo, seu preo antigo e seu novo preo. Para isto, criamos uma tabela chamada AUDITORIA que tem
trs colunas: uma para armazenar o cdigo do livro que sofreu aumento (CODIGO_LIVRO), a segunda para
armazenar o preo do livro antes do aumento (VALOR_ANTIGO) e a ltima (VALOR_NOVO), para armazenar o
novo preo do livro.
Para que a rotina de armazenamento das mudanas de preo ocorra de forma automtica, criamos um
gatilho, chamado TESTA_AUMENTO, que disparado sempre que a coluna PREO, da tabela LIVRO, atualizada.
Ento, para cada linha afetada pelo comando de atualizao, se o novo valor for superior a 20% do antigo valor, o
cdigo do livro, o seu preo antigo e seu novo preo so inseridos na tabela auditoria. Nesse gatilho, utilizaremos
N1 como apelido para a tabela NEW e O1 para apelido para a tabela OLD.
O comando de criao do gatilho descrito encontra-se a seguir:
CREATE TRIGGER TESTA_AUMENTO
AFTER UPDATE OF PRECO ON LIVRO
REFERENCING NEW AS N1 OLD AS O1
FOR EACH ROW
WHEN (N1.PRECO > 1.2 * O1.PRECO)
BEGIN
INSERT INTO AUDITORIA (CODIGO_LIVRO, VALOR_ANTIGO, VALOR_NOVO) VALUES (:N1.CODIGO, :O1.PRECO,
:N1.PRECO)
END;
Note que, no exemplo, utilizamos o caractere ; para referenciar, a partir do bloco de comandos SQL, as
variveis que representam a tabela de transio. Note, ainda, que, para acessarmos os valores das colunas,
podemos utilizar o formato NOME_TABELA_TRANSICAO.NOME_COLUNA.
No podemos executar gatilhos atravs de chamadas diretas, como fazemos com procedimentos e funes
armazenadas. A nica maneira de execut-los atravs de seu evento disparador.
Para apagar um gatilho, utilizamos o comando DROP TRIGGER seguido do nome do gatilho. Exemplo:
DROP TRIGGER TESTA_AUMENTO;
245

Extenses ao Relacional
No final da dcada de 80, a programao orientada a objetos alcanou um grande nmero de adeptos. O
debate entre os que defendiam os SGBDs orientados a objetos e entre os adeptos dos SGBDs relacionais tomou
maior importncia. A partir deste, surgiram SGBDs que incorporaram caractersticas de orientao a objeto aos
modelos relacionais: os SGBDs estendidos ou relacionais a objeto.
Vrios SGBDs Relacionais comearam a se tornar relacionais estendidos, at que a SQL incorporou
comandos para criao de tipos do usurio e manipulao de dados no-convencionais, entre outros.
Tipos de Dados do Usurio
A primeira caractersticas dos SGBDs relacionais estendidos a possibilidade do usurio poder criar seus
prprios tipos de dados.
Tipos de dados definidos pelo usurio podem conter um ou mais atributos, sendo que cada atributo possui,
por sua vez, um tipo de dados prprio, podendo este ser um tipo predefinido ou um tipo de dados do usurio.
Tipos de dados do usurio em conjunto com seus atributos formam estruturas anlogas ao struct da linguagem C
ou ao RECORD da linguagem Pascal.
Podemos, tambm, atribuir mtodos a tipos de dados do usurio. Mtodos so rotinas (procedimentos ou
funes) que podem ser acionados para tratamento e manipulao de informaes.
Outro importante conceito proveniente de orientao a objetos o de herana. Na orientao a objetos,
uma classe, chamada de subclasse, pode herdar atributos e mtodos de outra classe, sua superclasse. Na
SQL:2003, um tipo de dados do usurio pode ser classificado como NOT FINAL podero ter herdeiros (ou
descendentes), ou seja, seus atributos e mtodos podero ser herdados por outros tipos de dados.
CREATE TYPE NOME_TIPO [UNDER NOME_SUPER_TIPO] AS (
ATRIBUTO1
TIPO_ATRIBUTO1,
ATRIBUTO2
TIPO_ATRIBUTO2,
...
ATRIBUTON
TIPO_ATRIBUTON
)
[TIPO_FINAL]
[METHOD NOME_MTODO1 (PARAMETROS_METODO1),
METHOD NOME_METODO2 (PARAMETROS_METODO2),
...
METHOD NOME_METODON(PARAMETROS_METODON)]
Consideremos que nossa base de dados armazena a informao de endereos em diversas tabelas. Para
tornar a definio de um endereo mais completa, gostaramos de dividi-lo em vrios campos: logradouro,
nmero, complemento, CEP, bairro, cidade e estado.
Como temos vrias tabelas com colunas que armazenam endereos, decidimos, por exemplo, criar um tipo
de dados chamado TYP_ENDERECO, que contm os campos citados anteriormente com seus atributos. A criao
do tipo de dados TYP_ENDERECO apresentado a seguir:
CREATE TYP_ENDERECO (
LOGRADOURO
VARCHAR(100),
NMERO
INTEGER,
COMPLEMENTO VARCHAR(15),
CEP
CHAR(8),
BAIRRO
VARCHAR(30),
CIDADE
VARCHAR(40),
ESTADO
VARCHAR(2) )
246

FINAL
No exemplo anterior, o tipo de dados TYP_ENDERECO foi definido como FINAL. Isso significa que ele no
pode ter suas propriedades herdadas por outros tipos de dados. TYP_ENDERECO no apresenta nenhum mtodo.
Consideremos, agora, como exemplo, que desejamos tornar a definio de nomes mais bem estruturada,
criando dois atributos para um nome e sobrenome. Chamemos nosso tipo de dados de TYP_NOME. Alm disso,
muitas vezes, desejamos obter o nome completo de uma pessoa. Para tal, criamos um mtodo que seja capaz de
concatenar nome e sobrenome. Os atributos e mtodos desse tipo de dados podem ser herdados por outros
tipos. A definio do tipo de dados, contendo atributos e mtodos, apresentado a seguir:
CREATE TYPE TIP_NOME(
PRIMEIRO_NOME VARCHAR(30),
SOBRENOME
VARCHAR(30)
) NOT FINAL
METHOD NOME_COMPLETO RETURNS VARCHAR
Utilizando tipo de dados do usurio
Os tipos de dados definidos pelo usurio podem ser utilizados na definio de colunas. Assim, podemos criar
uma tabela CLIENTE que possui, dentre as suas colunas, a coluna NOME, de tipo de dados TYP_NOME, e a coluna
ENDERECO que tem, como tipo de dados, tipo TYP_ENDERECO. O comando de criao da tabela CLIENTE
apresentado a seguir:
CREATE TABLE CLIENTES(
CODIGO INTEGER PRIMARY KEY,
NOME
TYP_NOME NOT NULL,
ENDERECO TYP_ENDERECO NOT NULL
CPF
CHAR(11) CONSTRAINT UK_CPF UNIQUE,
DATA_NASCIMENTO
DATE,
TELEFONE VARCHAR(12) )
Para utilizarmos colunas cujos tipos so definidos pelo usurios em comandos de seleo, incluso,
atualizao e excluso, devemos utilizar o construtor do tipo, que podemos o nome do prprio tipo de dados.
Alterando o tipo de dados do usurio
Em varias situaes pode ser necessrios alterar um tipo de dados definido pelo usurio. Podemos, por
exemplo, querer: (i) adicionar atributos, (ii) remover atributos, (iii) adicionar novos mtodos e (iv) remover
mtodos existentes. Para atender a essas necessidades, foi definido o comando ALTER TYPE.
Podemos utilizar ALTER TYPE em diferentes construes. A estrutura a seguir deve ser utilizada para
adicionarmos um atributo a um tipo.
ALTER TYPE NOME_TIPO
ADD ATTRIBUTE NOME_ATRIBUTO TIPO_ATRIBUTO
Exemplo:
ALTER TYPE TYP_ENDERECO
ADD ATTRIBUTE PAIS VARCHAR(35)
J para remover um atributo, utilizamos o comando ALTER TYPE com o formato abaixo.
ALTER TYPE NOME_TIPO
DROP ATTRIBUTE NOME_ATRIBUTO [RESTRICT]

247

RESTRICT refora a idia de que nenhum atributo pode ser apagado se o tipo de dados estiver sendo utilizado na
definio de qualquer objeto de b d.
Exemplo:
ALTER TYPE TYP_ENDERECO
DROP ATTRIBUTE PAIS
Para adicionar novos mtodos, utilizamos o commando com o formato abaixo:
ALTER TYPE NOM_TIPO
ADD METHOD NOME_METODO [PARAMETROS_METODO]
RETURNS TIPO_RETORNO
Aps a incluso do mtodo, seu corpo deve ser especificado. Tal especificao ocorre de forma anloga
apresentada anteriormente.
J para removermos um mtodo do tipo definido pelo usurio, utilizamos o comando ALTER TYPE conforme
mostrado a seguir.
ALTER TYPE NOME_TIPO DROP METHOD NOME_METODO
Removendo tipos de dados do usurio
Tipos de dados do usurio podem ser excludos. Para isso, utilizamos o comando DROP TYPE seguido do
nome do tipo de dados em questo. A seguir, teremos o exemplo de excluso dos tipos TYP_CLIENTE e
TYP_ENDERECO.
DROP TYPE TYP_CLIENTE
DROP TYPE TYP_ENDERECO
Para que possamos excluir um tipo de dados, ele no deve estar sendo utilizado por nenhuma tabela e nem
por outro tipo de dados.
Armazenando e referenciando objetos
Os objetos (de dados) criados a partir dos tipos definidos pelo usurio possuem um identificador nico,
chamado OID (object identifier). Podemos referenciar os objetos, atravs de seu OID, utilizando o tipo REF.
REF um ponteiro para objetos de um determinado tipo de dados do usurio. Permite implementar vnculos
entre relaes onde em um dos lados existe um objeto. Desta forma, podemos criar colunas ou atributos que
sejam do tipo REF e que armazenam um ponteiro para um objeto de um dado tipo. Ao valor da coluna, podemos
atribuir o valor NULL ou uma referncia ao objeto. Podemos utilizar o valor contido em REF para recuperar o
objeto que apontado e para atualizar seu valor.
Para criarmos um atributo ou coluna que armazene uma referncia, devemos utilizar a construo:
NOME_COLUNA REF NOME_TIPO_DE_DADOS_USUARIO
Exemplo: Considere que tenhamos montado um banco de dados para armazenar as equipes que participam de
um torneio. De cada jogador, queremos armazenar o nome e a equipe a que pertence. De cada equipe,
desejamos armazenar o nome e o nome de seu capito. Para isso, iremos criar dois tipos de dados.
Iniciamos criando o tipo que representa as informaes de equipes que, por enquanto, contm apenas o
atributo nome.
CREATE TYPE TYP_EQUIPE AS (
NOME VARCHAR(30)
)
Ento, criamos o tipo de dados para representar as informaes de cada jogador. Este tipo contm dois
atributos: o nome, e uma referncia para um objeto do tipo referenciado.
248

CREATE TYPE TIP_JOGADOR AS (

NOME VARCHAR(50),
EQUIPE REF(TYP_EQUIPE))
Por fim, alteramos TYP_EQUIPE para conter uma referncia para um objeto que contm as informaes do
capito da equipe:
ALTER TYPE TYP_EQUIPE ADD ATTRIBUTE CAPITAO REF(TYP_JOGADOR)
A SQL:2003 nos permite criar tabela que sejam repositrios de objetos. Nestas tabelas, somente temos um
objeto. Uma sintaxe simplificada para sua criao :
CREATE TABLE NOME_TABELA OF NOME_TIPO_DADOS (
REF IS NOME_COLUNA,
NOME_COLUNA_TIPO_REF WITH OPTIONS
SCOPE NOME_TABELA_REFERENCIADA,
NOME_COLUNA_TIPO_REF2 WITH OPTIONS
SCOPE NOME_TABELA_REFERENCIADA2,
NOME_COLUNA_TIPO_REFN WITH OPTIONS
SCOPE NOME_TABELA_REFERENCIADAN
)
Consideremos o tipo de dados TYP_EQUIPE e TYP_JOGADORES, mencionados anteriormente. Vamos, agora,
criar as tabelas EQUIPES e JOGADORES de forma a armazenar objeto dos dois tipos, respectivamente.
Inicialmente, criamos a tabela EQUIPES, definindo OID como nome da coluna de referncia.
Comando:
CREATE TABLE EQUIPES OF TYP_EQUIPE (REF IS OID)
Ento, criamos a tabela JOGADORES, definindo, tambm, uma coluna de nome OID como coluna de
referncia. Na criao, definimos, ainda, que o atributo EQUIPE aponta para objetos contidos na tabela EQUIPES.
Comando:
CREATE TABLE JOGADORES OF TYP_JOGADOR (REF IS OID,
EQUIPE WITH OPTIONS SCOPE EQUIPES)
Agora, utilizamos o comando ALTER TABLE para modificar a tabela EQUIPES de forma a fazer com que a
coluna CAPITAO referencie objetos contidos na tabela JOGADORES. O comando a ser utilizado, apresentado a
seguir, permite alterar a definio de uma coluna, adicionando um escopo para sua referncia.
ALTER TABLE EQUIPES ALTER CAPITAO ADD SCOPE JOGADORES
Vamos, agora, como exemplo, incluir equipes e jogadores nas tabelas. Comeamos incluindo trs equipes
chamadas Equipe Azul, Equipe Verde e Equipe Laranja. Os comandos de incluso so apresentados a seguir.
INSERT INTO EQUIPES (OID, NOME)
VALUES (TYP_EQUIPE(1), EQUIPE AZUL)
INSERT INTO EQUIPES (OID, NOME)
VALUES (TYP_EQUIPE(2), EQUIPE VERDE)
INSERT INTO EQUIPES (OID, NOME)
VALUES (TYP_EQUIPE(3), EQUIPE LARANJA)
Note, nos comandos anteriores, que no inclumos valores para o atributo CAPITAO. Alm disso, utilizamos o
nome do tipo de dados como construtor para a obteno de um OID a partir dos valores 1, 2 e 3.

249

Podemos, tambm, incluir dados na tabela de jogadores. Vamos incluir trs jogadores para a Equipe Azul:
Joo, Andr, e Pedro. Para isso, executamos os comandos a seguir:
INSERT INTO JOGADORES (OID, NOME, EQUIPE)
VALUES (
TYP_JOGADOR(1), JOAO, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL))
INSERT INTO JOGADORES (OID, NOME, EQUIPE) VALUES (
TYP_JOGADOR(2), ANDR, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL))
INSERT INTO JOGADORES (OID, NOME, EQUIPE) VALUES (
TYP_JOGADOR(3), PEDRO, (SELECT OID FROM EQUIPES WHERE NOME= EQUIPE AZUL))
Nos comandos anteriores, utilizamos uma subconsulta para recuperar o objeto referente equipe dos
jogadores e inseri-lo na tabela JOGADORES. Vamos, agora, marcar o jogador Andr como capito da equipe Azul.
UPDATE EQUIPE
SET CAPITAO = ( SELECT OID FROM JOGADORES WHERE NOME = ANDR)
WHERE NOME = EQUIPE AZUL
Podemos, tambm, realizar consultas sobre os dados contidos em JOGADORES e em EQUIPES. Vejamos
exemplos:
Desejamos selecionar o nome do capito da Equipe Azul.
SELECT CAPITAO -> NOME
FROM EQUIPES
WHERE NOME = EQUIPE AZUL
Desejamos selecionar o nome da equipe do jogador JOAO.
SELECT EQUIPE -> NOME
FROM JOGADORES
WHERE NOME = JOAO
Desejamos selecionar o nome do capito da equipe do jogador JOAO.
SELECT EQUIPE -> CAPITAO -> NOME
FROM JOGADORES
WHERE NOME = JOAO
Nestes comandos utilizamos -> para acessar os campos dos objetos referenciados pelas colunas de tipo REF.
No terceiro exemplo, a partir do objeto referente ao jogador JOAO acessamos o objeto referente Equipe Azul,
na tablea de equipes, e, ento, acessamos o objeto referente ao jogdor capito da equipe, Andr, para obter o
seu nome.
A SQL:2003 define, tambm, dois tipos de colees de objetos: arrays e multisets. Arrays so colees onde
cada elemento participante possui uma posio fixa e pode ser acessado por sua posio na coleo. Multisets
so colees onde no existe ordenao dos elementos. Assim, Multisets so colees onde no existe ordenao
dos elementos. Assim, no h um ndice atravs do qual acessemos um dado elemento.
Extenso para OLAP
A SQL:2003 apresenta diferentes estruturas para atender a necessidades de aplicaes OLAP. Dentre elas,
temos os elementos de agrupamento ROLLUP, CUBE e GROUPING SETS, que so apresentados a seguir.
Anteriormente foi apresentada a clusula GROUP BY. Ela faz com que dados sejam agrupados atravs de uma
ou mais colunas e permite que se apliquem funes sobre as linhas que participam de cada grupo. ROLLUP, CUBE,
250

e GROUPING SETS so empregados em conjunto com GROUP BY, provendo diferentes comportamentos a essa
clusula.
ROLLUP
Quando utilizamos ROLLUP, o resultado obtido contm linhas representando a realizao do agrupamento
em vrios nveis. Sua sintaxe de utilizao a seguinte:
SELECT COL1, COL2, ..., COLN, FUNCAO1, ..., FUNCAON
FROM NOME_TABELA
GROUP BY ROLLUP (COL1, ..., COLN)
Como exemplo, considere uma base de dados de vendas. Assuma que existe uma tabela onde so
armazenadas informaes das vendas realizadas por uma empresa nos diversos estados do pas. So
armazenados os produtos vendidos, a data das vendas e as quantidades vendidas em cada operao. Um
exemplo desta tabela apresentado na Tabela 11.1.
Considere, como exemplo, que desejamos saber a quantidade total vendida em cada combinao de
<produto, ms, estado> existente na tabela. Desejamos que a listagem esteja ordenada por estado, ms de
venda, e nome do produto. Para isso, devemos utilizar a consulta a seguir.
SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL
FROM VENDA
GROUP BY ESTADO, MONTH(DATA), PRODUTO
ORDER BY ESTADO, MONTH(DATA), PRODUTO
Considere que, agora, desejamos montar uma listagem que apresente os totais de vendas, no s para as
diversas combinaes de <produto, ms, estado>, mas, tambm, para cada par <ms, estado> e para cada estado
isoladamente. Vamos, ento, utilizar o operador ROLLUP:
SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO,
SUM(QUANTIDADE) AS TOTAL
FROM VENDA
GROUP BY ROLLUP (ESTADO, MONTH(DATA), PRODUTO)
ORDER BY ESTADO, MONTH(DATA), PRODUTO
Note a diferena entre os resultados da utilizao da clusula GROUP BY com e sem o operador ROLLUP.
Quando utilizamos o operador ROLLUP, alm das linhas obtidas com a realizao do agrupamento, so obtidas
novas linhas que contm os subtotais para cada nvel de agrupamento. Uma linha contendo o total geral tambm
participa do resultado.
Grouping Sets
J a utilizao do operador GROUPING SETS faz com que o agrupamento seja realizado, isoladamente, por
cada uma das expresses contidas na clusula GROUP BY. Ou seja, o resultado de uma consulta com a utilizao
de GROUPING SETS em um clusula GROUP BY com n expresses idntico unio dos resultados de n
comandos com a clusula GROUP BY utilizada isoladamente e, em cada um dos n comandos, somente uma das
colunas n originais est presente em GROUP BY.
GROUPING SETS utilizado de forma idntica a ROLLUP, bastando substituir no comando de consulta, ROLLUP
por GROUPING SETS. Vejamos, como exemplo, a utilizao de GROUP SETS na nossa tabela de vendas.
SELECT ESTADO, MONTH(DATA) AO MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL
FROM VENDA
GROUP BY GROUPING SETS (ESTADO, MONTH(DATA), PRODUTO)
251

ORDER BY ESTADO, MONTH(DATA), PRODUTO

Note, no exemplo, anterior, que o resultado final idntico ao que seria obtido se realizssemos a consulta
trs vezes, onde, em cada uma, somente o comando GROUP BY e uma das trs expresses de agrupamento
(ESTADO, MONTH(DATA), PRODUTO) fossem utilizados.
CUBE
Este operador realizar agrupamentos por cada combinao possvel das expresses contidas na clusula
GROUP BY. Ele apresenta, tambm, uma linha com informao condensada de toda a tabela. utilizado de forma
idntica a ROLLUP e a GROUP SETS. Vejamos um exemplo de consulta utilizando a tabela VENDA:
SELECT ESTADO, MONTH(DATA) AS MS, PRODUTO, SUM(QUANTIDADE) AS TOTAL
FROM VENDA
GROUP BY CUBE(ESTADO, MONTH(DATA), PRODUTO)
ORDER BY ESTADO, MONTH(DATA), PRODUTO
Notamos que esto presentes no resultado aqueles que seriam obtidos se realizssemos vrias consultas
com a clusula GROUP BY e diversas combinaes entre as colunas ESTADO e PRODUTO e a expresso
MONTH(DATA).
Nos exemplos anteriores, utilizamos a funo SUM. Comportamento anlogo pode ser obtido se utilizarmos
outras funes agregadas, como SUM. No caso da utilizao de AVG em conjunto com ROLLUP, por exemplo,
obtemos a mdia por produto, ms e estado, a mdia de vendas por ms e estado, a mdia por estado e, enfim, a
mdia final de vendas.
Privilgios e Papis
Controle de privilgios um importante mecanismo existente em SGBDs. atravs dele possvel garantir
que os usurios realizem apenas as operaes que lhe so permitidas.
Todo acesso a um SGBD realizado em conjunto com a identificao de um usurio ou tipo de usurio, seja
de forma implcita ou explcita. A cada usurio podem estar associados diversos privilgios. De acordo com os
privilgios que possui, o usurio pode, por exemplo, se conectar ao banco de dados, criar outros usurios e ler,
alterar, incluir ou apagar dados de uma ou mais tabela.
possvel ainda, por exemplo, configurar o sistema de forma que um determinado usurio conectado ao
SGBD no saiba da existncia de uma ou mais tabelas. Para isso, basta no atribuir a tal usurio os privilgios
mnimos para que tome conhecimento da existncia das tabelas em questo.
De forma a facilitar o gerenciamento e a atribuio de privilgios a usurios, o padro SQL define a
possibilidade de criao de papis (roles), os quais podem ser tratados como conjuntos de privilgios que podem
ser atribudos a usurios.
Usurios
O padro SQL define o conceito de identificadores de usurios como a representao no SGBD de usurios do
mundo real. Desta forma, identificadores de usurios representam usurios do SGBD.
De acordo com o que foi definido no padro SQL, toda sesso SQL possui um identificador de usurio a ela
associado. De acordo com os privilgios, que o identificador de usurio da sesso possuir, so definidos os
comandos que podem ou no ser executados na referida sesso.
comum que usurios do banco de dados representem aplicaes e no usurios reais. Do ponto de vista do
SGBD, no que se refere ao controle de acesso e segurana, esses tipos de usurios no so diferentes entre si,
devendo ser tratados de maneira similar, havendo tambm a necessidade de atribuio e revogao de
privilgios.

252

Privilgios
O padro SQL define um privilegio como sendo uma autorizao para que uma dada ao seja executada.
Estas aes geralmente incidem sobre um objeto de banco de dados, como tabelas, vises, gatilhos ou colunas,
por exemplo.
Dentre as possveis aes indicadas no padro SQL, temos:
INSERT [LISTA_DE_COLUNAS] LISTA DE COLUNAS opcional. Permite incluir somente valores para as
colunas especificadas na LISTA_DE_COLUNAS, caso esta lista tenha sido especificada, ou para todas as
colunas de uma tabela/viso, caso a lista no tenha sido especificada.
UPDATE [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite atualizar as colunas de uma
tabela/viso especificadas na LISTA_DE_COLUNAS, caso essa lista tenha sido especificada, ou em todas as
colunas, caso essa lista no tenha sido especificada.
DELETE Apagar dados em uma tabela.
SELECT [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite selecionar valores de uma
tabela/viso, somente para as colunas especificadas na LISTA_DE_COLUNAS, caso esta lista tenha sido
especificada, ou para todas as colunas, caso essa lista no tenha sido especificada.
REFERENCES [LISTA_DE_COLUNAS] LISTA_DE_COLUNAS opcional. Permite referenciar uma tabela na
criao de chaves estrangeiras. Somente as colunas especificadas na LISTA_DE_COLUNAS podero ser
referenciadas, caso essa lista tenha sido especificada, ou qualquer coluna, caso a lista no tenha sido
especificada.
De forma a melhorar os mecanismos de controle de acesso e segurana, os Gerenciadores de Banco de dados
apresentam diversos privilgios alm dos especificados no padro. Cada SGBD possui seu prprio modelo de
privilgios. Nesses modelos, os privilgios so classificados, geralmente, ao menos como privilgios de objeto e
privilgios de sistema.
De toda a forma, so comuns em SGBDs privilgios especficos para:
Conectar-se a uma instncia do SGBD ou a uma de suas bases de dados;
Criar e destruir objetos do banco de dados, como tabelas, ndices, vises, gatilhos, e procedimentos
armazenados, dentre outros.
Consultar, atualizar, incluir e excluir dados em tabelas (e em vises, para gerenciadores que suportam a
realizao dessas operaes nas mesmas).
Executar procedimentos e funes armazenados.
Alterar as caractersticas do sistema e de suas bases de dados, tais como parmetros de inicializao.
Realizar operaes de gerao de cpias de segurana (backup) e recuperao de tais cpias (restore).
Em geral, o usurio analista de sistema ou programador no necessitar possuir todos esses privilgios. A
maioria de tais privilgios se relaciona com aes que so realizadas especificamente pelo administrador do
banco de dados.
Usualmente, o administrador do banco de dados que concede os privilgios necessrios para que outros
usurios realizem suas aes.
Atribuindo privilgios a um usurio
Para atribuirmos um privilgio a um usurio (ou seja, para permitimos que um usurio realize uma
determinada ao), devemos utilizar o comando GRANT, cuja sintaxe exibida a seguir:
GRANT PRIVILEGIOS
TO NOME_PRIVILEGIADO
[WITH HIERARCHY OPTION][WITH GRANT OPTION]
[GRANTED BY NOME_CONCEDENTE]
importante notar que, para poder atribuir um privilgio a um dado usurio, o usurio concedente deve
possuir privilgios para tal.
Como exemplo, consideremos que deve ser permitido ao usurio MARIA realizar qualquer operao dentro
da tabela EDITORA. Para atribuir ao referido usurio tais privilgios, pode ser usada a clusula ALL PRIVILEGES.
253

GRANT ALL PRIVILEGES ON EDITORA TO MARIA

Considere-se, ainda, que este usurio deveria poder, tambm, selecionar e atualizar dados da tabela LIVRO,
mas que no lhe deve ser permitido incluir ou apagar dados desta tabela. O usurio MARIA poder, ainda,
conceder privilgios que possui na tabela LIVRO a outros usurios. Para permitir que o usurio MARIA realize tais
aes, executa-se o comando a seguir:
GRANT SELECT, UPDATE ON LIVRO TO MARIA WITH GRANT OPTION
J no que se refere tabela ASSUNTO, o usurio MARIA somente pode alterar apenas a coluna DESCRIO.
Para atribuir Maria privilgios necessrios para realizar essa operao, deve ser executado o seguinte comando:
GRANT UPDATE(DESCRIO) ON ASSUNTO TO MARIA
Conforme mencionado anteriormente, para que os comandos GRANT apresentados nos exemplos possam
ser executados com sucesso, devem ser executados por um usurio que possua os privilgios adequados.
Usualmente, esse usurio representa o administrador do banco de dados, o qual possui privilgios de sistema
que lhe permitem realizar todas, ou quase todas as operaes do banco de dados. No entanto, podem, tambm,
ser executados por um usurio que tenha recebido tais privilgios com a opo WITH GRANT OPTION, que lhe
permite atribuir privilgios recebidos a outros usurios.
Privilgios referentes manipulao de dados em objetos podem, ainda, ser executados pelo usurio dono
do objeto em questo. Usualmente, o dono de um objeto de banco de dados o usurio que o criou.
Removendo privilgios de um usurio
Aps o usurio ter recebido o privilegio para executar uma ao, ele ir manter esse privilgio at que o
mesmo seja explicitamente revogado. Para revogar um ou mais privilgios de um usurio, deve-se utilizar o
comando REVOKE. Sua estrutura simplificada mostrada a seguir:
REVOKE [GRANT OPTION FOR] PRIVILGIOS FROM NOME_PRIVILEGIADO
Como exemplo, consideremos que o usurio MARIA no deve mais possuir a habilidade de alterar dados da
tabela EDITORA. Para tal, pode-se executar comando como o apresentado a seguir.
REVOKE UPDATE ON EDITORA FROM MARIA
Consideremos, agora, que no deve mais ser permitido ao usurio MARIA atribuir a todos os outros usurios
o privilgio de atualizao da tabela LIVRO. Para tal, pode-se executar o comando apresentado a seguir, que
revoga essa habilidade do usurio em questo, mas tambm a possibilidade que o referido usurio possa
atualizar dados na tabela LIVRO.
REVOKE GRANT OPTION FOR UPDATE ON LIVRO FROM MARIA
Podemos ainda considerar a situao onde no mais deve ser permitido ao usurio realizar quaisquer aes
na tabela ASSUNTO. Para tal, pode-se executar o comando a seguir, que retira do usurio os privilgios para
executar aes na tabela ASSUNTO.
REVOKE ALL PRIVILEGES ON ASSUNTO FROM MARIA
Papis
Em um ambiente de banco de dados de produo podem existir diversos usurios e algumas centenas ou at
mesmo milhares de tabelas, entre outros objetos. Muitos dos usurios podem utilizar o mesmo conjunto de
objetos, devendo ter privilgios para executar conjuntos similares de aes.
Atribuir privilgios referentes a cada um dos objetos para cada usurio de forma individual pode ser uma
tarefa bastante trabalhosa. Alm disso, a medida que aumenta o nmero de tabelas ou outros objetos sobre as
quais cada usurio deve ter privilgios, aumenta tambm a probabilidade de que, por erro ou por esquecimento
254

pode ficar desapercebido num primeiro momento. No entanto, poder causar problemas mais graves, por
exemplo, quando a aplicao que utilize o usurio em questo para acessar o banco de dados esteja em
produo.
Para facilitar as tarefas de administrao do banco de dados relacionadas com a atribuio e revogao de
privilgios, e reduzir o nmero de erros nessas operaes, foi definido o conceito de Papel (Role).
Um Papel visa representar todas as aes que um ou mais usurios podem realizar no banco de dados.
Assim, aps criar um papel, necessrio atribuir-lhe todas as aes que representa. Em seguida, esse papel pode
ser atribudo a um ou mais usurios. Todos os usurios a quem o papel for atribudo recebero todos os
privilgios que foram atribudos ao papel em questo. A qualquer momento possvel atribuir ou revogar
privilgios de um papel, e atribuir ou revogar o papel de um ou mais usurios.
Desta forma, ao ser criado um novo usurio B que deva possuir os mesmos privilgios para execuo de
aes que outro usurio A j existente, podemos atribuir ao usurio B os mesmos papis que tiverem sido
atribudos ao usurio A.
Criando e utilizando Papis
Para criamos um papel, utilizamos o comando CREATE ROLE. Sua sintaxe simplificada a seguinte:
CREATE ROLE NOME-ROLE
Consideremos a base de dados de livros que ser utilizada por vrios usurios que podem ser agrupados
segundo dois diferentes perfis: um denominado BIBLIOTECA e outro denominado VISITANTE. Para criar esses
papis, utilizamos o comando a seguir:
CREATE ROLE BIBLIOTECA
CREATE ROLE VISITANTE
Os papis somente sero teis se a eles forem associados os privilgios aos quais correspondem. Para
aqueles que possurem o papel BIBLIOTECA, dever ser permitido realizar quaisquer operaes sobre os dados
das tabelas ASSUNTO, EDITORA, AUTOR, LIVRO e AUTOR_LIVRO. necessrio, ento, que tais privilgios sejam
atribudos ao papel BIBLIOTECA. Isto pode ser feito pelo comando GRANT, de forma similar ao que foi realizado
para a atribuio de privilgios para um usurio. Nesse caso, deve-se usar o nome do papel na posio de NOMEPRIVILEGIADO.
Os cinco comandos a seguir apresentam a atribuio dos privilgios para o papel BIBLIOTECA.
GRANT ALL PRIVILEGES ON ASSUNTO TO BIBLIOTECA
GRANT ALL PRIVILEGES ON EDITORA TO BIBLIOTECA
GRANT ALL PRIVILEGES ON AUTOR TO BIBLIOTECA
GRANT ALL PRIVILEGES ON LIVRO TO BIBLIOTECA
GRANT ALL PRIVILEGES ON AUTOR_LIVRO TO BIBLIOTECA
Alm de atribuir os privilgios ao papel, faz-se necessrio atribuir o papel a cada usurio que deva ter o perfil
em questo.
Caso deva ser permitido aos usurios MARIA, JOO e ANA o acesso completo aos dados das tabelas
ASSUNTO, EDITORA, AUTOR, LIVRO e AUTOR_LIVRO, podemos atribuir o papel BIBLIOTECA a tais usurios. Para
isso, utilizamos o comando GRANT de forma similar ao apresentado anteriormente. Porm, neste caso,
PRIVILGIOS ser substitudo pelo nome do papel. O NOME_PRIVILEGIADO ir se referir ao usurio que dever
possuir os mesmos privilgios que foram atribudos ao papel. O comando a seguir exemplifica a atribuio do
papel BIBLIOTECA aos usurios MARIA, JOO e ANA.
GRANT BIBLIOTECA TO MARIA, JOAO, ANA

255

Aps a execuo do comando anterior, os usurios MARIA, JOO e ANA podero executar todas as aes
definidas nos privilgios atribudos ao papel BIBLIOTECA.
Se considerarmos que, aps uma reavaliao dos critrios de segurana do banco de dados, seja definido, por
exemplo, que o papel BIBLIOTECA no deve ter acesso aos dados da tabela EDITORA, podemos revogar os
privilgios que possui com a utilizao do comando REVOKE.
A utilizao do comando REVOKE, nesse caso, ser similar apresentada anteriormente, sendo necessrio
que se utilize, como NOME_PRIVILEGIADO, o nome do papel em questo. O exemplo a seguir retira os privilgios
sobre a tabela EDITORA do papel BIBLIOTECA.
REVOKE ALL PRIVILEGES ON EDITORA FROM BIBLIOTECA
Ao executarmos o comando anterior, alguns privilgios para executar aes que so revogados do papel
BIBLIOTECA e, consequentemente, de todos os usurios que possuem o referido papel. Ou seja, segundo nosso
exemplo, os privilgios para executar aes sobre a tabela EDITORA foram removidos dos usurios MARIA, ANA e
JOO. De fato, se for necessrio atribuir um novo privilgio ou revogar um privilgio do papel que os usurios
possuem.
possvel, tambm, revogar de um usurio a sua participao em um papel. Para isso, tambm utilizado o
comando REVOKE. Neste caso, o nome do papel ser utilizado em PRIVILEGIOS e o nome do usurio em
NOME_PRIVILEGIADO.
Consideremos que o usurio ANA no deva mais ter os privilgios definidos para o papel BIBLIOTECA. O
exemplo a seguir revoga o referido papel do usurio ANA.
REVOKE BIBLIOTECA FROM ANA
Removendo Papis
Para removermos papis, podemos utilizar o comando DROP ROLE. Sua sintaxe bsica :
DROP ROLE NOME_ROLE
O comando a seguir exemplifica a excluso do papel BIBLIOTECA atravs do comando DROP ROLE.
DROP ROLE BIBLIOTECA
Ao removermos um papel, ele automaticamente retirado de todos os usurios a quem tenha sido atribudo.
Desta forma, no ser mais permitido aos usurios que executem as aes definidas no papel que foi removido, a
menos que os privilgios para tal sejam diretamente atribudos aos usurios ou que sejam atribudos atravs de
outros papis.
Com base nos exemplos anteriores, pode-se dizer que ao removermos o papel BIBLIOTECA, o usurio JOO
no ter mais privilgios para realizar aes sobre as tabelas LIVROS e LIVRO_AUTOR, dentre outras. Isso porque
nenhum privilegio sobre tais tabelas tinha sido explicitamente atribudo a este usurio. Todas as aes que ele
podia realizar sobre essas tabelas eram permitidas pois o usurio possua o papel BIBLIOTECA, ao qual foi, agora,
removido do sistema.

256

Transao e Concorrncia
Normalmente, considera-se que um conjunto de vrias operaes no banco de dados uma nica
unidade do ponto de vista do usurio. Por exemplo, a transferncia de fundos de uma conta corrente para uma
poupana uma operao nica sob o ponto de vista do cliente; dentro do sistema de banco de dados, porm,
ela envolve vrias operaes. Evidentemente, essencial a concluso de todo o conjunto de operaes, ou que,
no caso de uma falha, nenhuma delas ocorra. Seria inaceitvel o dbito na conta sem o crdito na poupana.
As operaes que formam uma nica unidade lgica de trabalho so chamadas de transaes. Um
sistema de banco de dados precisa garantir a execuo apropriada das transaes a despeito de falhas ou a
transao executada por completo ou nenhuma parte dela executada. Alm disso, ele deve administrar a
execuo simultnea de transaes de modo a evitar a ocorrncia de inconsistncias. Retornando a nosso
exemplo de transferncia de fundos, uma transao que calcula o total de dinheiro do cliente poderia trabalhar
com o saldo da conta corrente antes do dbito feito pela transao de transferncia e, tambm, verificar o saldo
da poupana depois do crdito. Com isso, obteria um resultado incorreto.
Conceito de Transao
Uma transao uma unidade de execuo de programa que acessa e, possivelmente, atualiza vrios
itens de dados. Uma transao, geralmente, o resultado da execuo de um programa de usurio escrito em
uma linguagem de manipulao de dados de alto nvel ou em uma linguagem de programao (p.e., SQL, COBOL,
C ou Pascal), e determinada por declaraes (ou chamadas de funo) da forma begin transaction e end
transaction. A transao consiste em todas as operaes ali executadas, entre o comeo e o fim da transao.
Para assegurar a integridade dos dados, exigimos que o sistema de banco de dados mantenha as
seguintes propriedades das transaes:
Atomicidade. Ou todas as operaes da transao so refletidas corretamente no banco de dados ou
nenhuma o ser.
Consistncia. A execuo de uma transao isolada (ou seja, sem a execuo concorrente de outra
transao) preserva a consistncia do banco de dados.
Isolamento. Embora diversas transaes possam ser executadas de forma concorrente, o sistema garante
que, para todo par de transaes Ti e Tj, Ti tem a sensao de que Tj terminou sua execuo antes de Ti
comear, ou que Tj comeou sua execuo aps Ti terminar. Assim, cada transao no toma
conhecimento de outras transaes concorrentes no sistema.
Durabilidade. Depois da transao completar-se com sucesso, as mudanas que ela faz no banco de
dados persistem, at mesmo se houver falhas no sistema.
Essas propriedades so chamadas frequentemente de propriedades ACID; o acrnimo derivado da
primeira letra de cada uma das quatro propriedades.
Para obter um melhor entendimento das propriedades ACID e da necessidade dessas propriedades,
vamos considerar um sistema bancrio simplificado que consiste em vrias contas e um conjunto de transaes
que acessam e atualizam essas contas. Por enquanto, vamos supor que o banco de dados reside
permanentemente em disco, mas que alguma parte dele reside, temporariamente, na memria principal.
O acesso ao banco de dados obtido pelas duas seguintes operaes:
read(X), que transfere o item de dados X do banco de dados para um buffer local alocado transao que
executou a operao de read.
write(X), que transfere o item de dados X do buffer local da transao que executou a write de volta ao
banco de dados.
Em um sistema de banco de dados real, a operao write (escrita) no resulta necessariamente na
atualizao imediata dos dados no disco; a operao write pode ser armazenada temporariamente na memria e
ser executada depois no disco. Mas, por enquanto, vamos supor que a operao write atualize o banco de dados
imediatamente.
257

Seja Ti uma transao que transfere 50 dlares da conta A para a conta B. Essa transao pode ser
definida como:

Vamos considerar cada uma das propriedades ACID (para facilidade de apresentao, vamos considera-las
em ordem diferente da ordem A-C-I-D).
Consistncia. A exigncia de consistncia aqui significa que a soma de A com B deve permanecer
inalterada aps a execuo da transao. Sem a exigncia de consistncia, uma soma em dinheiro poderia
ser criada ou destruda pela transao! Pode-se verificar facilmente que, se o banco de dados permanece
consistente depois da execuo da transao.
Assegurar a permanncia da consistncia aps uma transao em particular responsabilidade do
programador da aplicao que codifica a transao.

Atomicidade. Suponha que, exatamente antes da execuo da transao Ti, os valores das contas A e B
sejam 1000 e 2000 dlares, respectivamente. Agora suponha que, durante a execuo da transao Ti,
uma falha aconteceu impedindo Ti de se completar com sucesso. Exemplos desses tipos de falhas incluem
falta de energia, falhas de mquina e erros de software. Alm disso, suponha que a falha tenha ocorrido
depois da execuo da operao write(A), mas antes da operao write(B). Nesse caso, os valores das
contas A e B refletidas no banco de dados so 950 e 2000 dlares. Como resultado da falha sumiram 50
dlares. Em particular, notamos que a soma A+B j no preservada.

Assim, como resultado da falha, o estado do sistema no reflete mais de um estado real do mundo que se
supe representado no banco de dados. Chamamos esse estado de inconsistente. Devemos assegurar que essas
inconsistncias no sejam perceptveis em um sistema de banco de dados. Porm, observe que o sistema pode,
em algum momento, estar em um estado inconsistente. Mesmo que a transao Ti seja executada at o final, h
um ponto no qual o valor da conta A 950 dlares e o valor da conta B 2000 dlares, que claramente um
estado inconsistente. Porm esse estado dever ser substitudo pelo estado consistente em que o valor da conta
A 950 dlares e o valor da conta B 2050 dlares. Assim, se a transao nunca se iniciou ou se for garantida sua
execuo completa, esse estado incompatvel no seria visvel, exceto durante a execuo da transao. Essa a
razo da exigncia da atomicidade: se a propriedade de atomicidade for garantida, todas as aes da transao
sero refletidas no banco de dados ou nenhuma delas o ser.
A ideia bsica por trs da garantia da atomicidade a seguinte. O sistema de banco de dados mantm um
registro (em disco) dos antigos valores de quaisquer dados sobre os quais a transao executa uma gravao e, se
a transao no se completar, os valores antigos so restabelecidos para fazer com que parea que ela nunca foi
executada. Assegurar a atomicidade responsabilidade do prprio sistema de banco de dados, mais
especificamente ela tratada por um componente chamado de componente de gerenciamento de transaes.
Durabilidade. Se a transao se completar com sucesso, e o usurio que a disparou for notificado da
transferncia de fundos, isso significa que no houve nenhuma falha de sistema que tenha resultado em
perda de dados relativa a essa transferncia de capitais.
A propriedade de durabilidade garante que, uma vez completada a transao com sucesso, todas as atualizaes
realizadas no banco de dados persistiro, at mesmo se houver uma falha de sistema aps a transao se
completar.
Suponha agora que uma falha do sistema possa resultar em perda de dados na MP, mas que os dados
gravados em disco nunca sejam perdidos. Podemos garantir a durabilidade observando um dos seguintes itens:
258

1. As atualizaes realizadas pela transao foram gravadas em disco, antes da transao completar-se.
2. Informaes gravadas no disco, sobre as atualizaes realizadas pela transao, so suficientes para que o
banco de dados possa reconstruir essas atualizaes quando o sistema de banco de dados for reiniciado
aps uma falha.
Assegurar a durabilidade responsabilidade de um componente do sistema de banco de dados chamado
de componente de gerenciamento de recuperao. O componente de gerenciamento de transao e o
componente de gerenciamento de transao esto estreitamente relacionados.
Isolamento. Mesmo asseguradas as propriedades de consistncia e de atomicidade para cada transao,
quando diversas transaes concorrentes so executadas, suas operaes podem ser intercaladas de
modo inconveniente, resultando em um estado inconsistente.
Por exemplo, conforme vimos, o banco de dados fica temporariamente inconsistente, enquanto a
transao transfere fundos de A para B, quando o total reduzido j est escrito em A e o total a ser acrescidos
ainda est aguardando ser escrito em B. Se uma segunda transao, em execuo concorrente, ler A e B nesse
ponto intermedirio e computar A+B, observar um valor inconsistente. Alm disso, se essa segunda transao
executar em A e B atualizaes baseadas nos valores inconsistentes que leu, o banco de dados pode ficar em um
estado inconsistente mesmo aps ambas as transaes se completarem.
Uma soluo para o problema de execuo concorrente de transaes executar as transaes em srie
ou seja, uma aps a outra. Entretanto, a execuo simultnea de transaes proporcionam uma melhoria de
desempenho significativa. Por isso, foram desenvolvidas opes que permitem que diversas transaes sejam
executadas de modo concorrente.
Discutimos os problemas causados pela execuo de transaes concorrentes adiante. A propriedade de
isolamento de uma transao garante que a execuo simultnea de transaes resulte em uma situao no
sistema equivalente ao estado obtido caso as transaes tivessem sidos executadas uma de cada vez, em
qualquer ordem. Assegurar a propriedade de isolamento responsabilidade de um componente do sistema de
banco de dados chamado componente de controle de concorrncia e bem como a obedincia a seus princpios.

Estado da Transao
Na ausncia de falhas, todas as transaes completam-se com sucesso. Entretanto, como observamos
anteriormente, nem sempre uma transao pode completar-se com sucesso. Nesse caso, a transao abortada.
Se asseguramos a propriedade de atomicidade, uma transao abortada. Se assegurarmos a propriedade de
atomicidade, uma transao abortada no deve ter efeito sobre o estado do banco de dados. Assim, quaisquer
atualizaes que a transao abortada tiver feito no banco de dados devem ser desfeitas. Uma vez que as
mudanas causadas por uma transao abortada sejam desfeitas, dizemos que a transao foi desfeita (rolled
back retornada). Gerenciar transaes abortadas responsabilidade do esquema de recuperao.
Uma transao completada com sucesso chamada efetivada (committed). Uma transao que foi
efetivada e que realizou atualizaes transforma o banco de dados em um novo estado consistente que deve
persistir at mesmo se houver uma falha no sistema.
Uma vez que uma transao chegue efetivao (commit), no podemos desfazer seus efeitos
abortando-a. O nico modo de desfazer os efeitos de uma transao efetivada executar uma transao de
compensao, porm nem sempre isso possvel. Logo, a responsabilidade pela criao e execuo de uma
transao de compensao deixada a cargo do usurio, no sendo tratada pelo sistema de banco de dados.
Precisamos ser mais precisos sobre o que queremos dizer com trmino com sucesso de uma transao.
Portanto, estabeleceremos um modelo de transao simples e abstrato. Uma transao deve estar em um dos
seguintes estados:
Ativa, ou estado inicial; a transao permanece neste estado enquanto estiver executando.
Em efetivao parcial, aps a execuo da ltima declarao.
Em falha, aps a descoberta de que a execuo normal j no pode se realizar.
259

Abortada, depois que a transao foi desfeita e o banco de dados foi restabelecido ao estado anterior do
incio da execuo da transao.
Em efetivao, aps a concluso com sucesso.

O diagrama de estado correspondente a uma transao mostrado na fig. 13.1. Dizemos que uma
transao foi efetivada somente se ela entrou no estado de efetivao. Analogamente, dizemos que uma
transao abortou somente se ela entrou no estado de abortada. Uma transao dita concluda se estiver em
efetivao abortada.

Uma transao comea no estado ativo. Quando termina sua ltima declarao, ela entra no estado de
efetivao parcial.
Nesse momento, a transao completou sua execuo, mas ainda possvel ser abortada, j que seus
efeitos ainda podem estar na MP, e com isso uma falha de hardware pode impedir que seja completada com
sucesso.
Ento, o sistema de banco de dados escreve informaes suficientes no disco, de forma que, at mesmo
em uma falha eventual, as atualizaes realizadas pela transao possam ser recriadas quando o sistema for
reiniciado. Quando a ltima dessas informaes for escrita, a transao entre no estado de efetivao.
Conforme mencionamos anteriormente, por enquanto estaremos supondo que as falhas no resultam em
perda de dados no disco. Tcnicas para lidar com a perda de dados sero discutidas a seguir.
Uma transao entra no estado de falha quando o sistema determina que ela j no pode prosseguir sua
execuo normal (p.e., por causa de erros de hardware ou erros lgicos). Essa transao deve ser desfeita. Ela
entra, ento, no estado abortada. Nesse momento, o sistema tem duas opes:
Ele pode reiniciar a transao, mas somente se ela foi abortada como resultado de algum erro de
hardware ou de software no criado pela lgica interna da transao. Uma transao reiniciada
considerada uma transao nova.
Ele pode matar a transao. Normalmente, isso feito em decorrncia de algum erro lgico interno que
s pode ser corrigido refazendo o programa de aplicao, ou porque a entrada de dados no era
adequada ou porque os dados desejados no foram encontrados no banco de dados.
Devemos ser cautelosos quando tratamos de escritas externas observveis, como escrever em um
terminal ou em uma impressora. Uma escrita desse tipo no pode ser apagada, j que vista externamente ao
sistema de banco de dados. A maioria dos sistemas permite que essas escritas aconteam somente depois que
essas escritas aconteam somente depois que a transao entra no estado de efetivao. Um modo de
implementar esse esquema fazer com que o sistema de banco de dados armazene temporariamente, em um
meio de armazenamento no-voltil, qualquer valor associado a uma escrita externa, e fazer com que ele executa
a escrita real somente depois que a transao entra no estado de efetivao. Se o sistema falhar depois ter
entrado no estado de efetivao, mas antes de completar a escrita externa, quando o sistema for reiniciado, o
260

sistema de banco de dados executar a escrita externa (usando as informaes do meio de armazenamento novoltil).
Para certas aplicaes, pode ser conveniente permitir que transaes ativas exibam dados aos usurios,
particularmente em transaes de longa durao, de minutos ou horas. Infelizmente, no podemos permitir essas
sadas de dados, a menos que estejamos dispostos a comprometer a atomicidade da transao. A maioria dos
atuais sistemas de transao assegura a atomicidade e, por isso, probe essa forma de interao com usurios.
Implementao de Atomicidade e Durabilidade
O componente de gerenciamento de recuperao de um banco de dados implementa o suporte
atomicidade e durabilidade. Consideraremos primeiro um esquema simples, mas extremamente ineficiente. Esse
esquema supe que somente uma transao esteja ativa por vez, e baseia-se em cpias do banco de dados
simplesmente um arquivo no disco. Um ponteiro chamado db_pointer mantido no disco; ele aponta para a
cpia corrente do banco de dados.
No esquema de banco de dados shadow, uma transao que deseja atualizar o banco de dados primeiro
cria uma cpia completa dele. Todas as atualizaes so feitas na nova cpia, deixando a cpia original, chamada
cpia shadow, intata. Se, em qualquer momento, a transao tiver de ser abortada, simplesmente apaga-se a
novo cpia.
Se a transao se completa, sua efetivao ser feita conforme segue. Primeiro, o sistema operacional
precisa ter certeza de que todas as pginas da nova cpia do banco de dados tenham sido escritas no discos. Em
sistemas Unix, o comando flush (transportar, arrebatar) usada para esse propsito. Depois que o flush se
completa, o ponteiro db_pointer atualizado para apontar para a nova cpia do banco de dados e a esta se torna
a cpia atual. Ento, a cpia velha apagada. Esse esquema mostrado graficamente na fig. 13.2, em que o
estado do banco de dados, antes e aps a atualizao, indicado.

Diz-se que uma transao foi efetivada quando o db_pointer atualizado escrito no disco. Discutiremos,
agora, como essa tcnica trata as falhas de transao e de sistema. Primeiramente, consideremos a falha de
transao. Se a transao falhar antes da atualizao do db_pointer, o contedo antigo do banco de dados no
ser afetado. Simplesmente podemos abortar a transao apagando a cpia nova do banco de dados. Se a
transao foi efetivada, todas as atualizaes que ela executou esto no banco de dados apontado pelo
db_pointer. Assim, ou todas as atualizaes da transao so efetivadas ou nenhum de seus efeitos estaro
refletidos, a despeito da falha da transao.
Agora, considere uma falha do sistema. Suponha que a falha do sistema ocorra antes do db_pointer
atualizado ser escrito em disco. Quando o sistema reiniciar, ele ler o db_pointer, ver o contedo original do
banco de dados e nenhum dos efeitos da transao ser visvel no banco de dados. Agora, suponha que o sistema
falha depois que o db_pointer tiver sido atualizado em disco. Antes de atualizar o ponteiro, todas as pginas
atualizadas da nova cpia do banco de dados foram escritas no disco. Como mencionamos anteriormente,
estamos supondo que, uma vez escrito no disco, o contedo de um arquivo no seja danificado, nem mesmo se

261

houver uma falha de sistema. Portanto, quando o sistema reiniciar, ele ler o db_pointer e ver o contedo do
banco de dados depois de todas as atualizaes executadas pela transao.
Na verdade, a implementao depende da atomicidade da gravao em db_pointer; ou seja, todos os
seus bytes so escritos ou nenhum de seus bytes o ser. Se alguns dos bytes do ponteiro forem atualizados por
uma escrita, mas outros no, o ponteiro no ser representativo, e tanto a verso antiga do banco de dados
quanto a verso nova podem no ser encontradas quando o sistema for reiniciado. Felizmente, os sistemas de
disco fornecem atualizaes atmicas para blocos inteiros, ou pelo menos para um setor de disco. Em outras
palavras, o sistema de disco garante que atualizar o db_pointer atomicamente.
Assim, as propriedades de atomicidade e durabilidade das transaes so garantidas na tcnica de
implementao com cpia shadow, feita pelo componente de gerenciamento de recuperao.
Um exemplo simples de uma transao, fora do domnio de banco de dados, seria uma sesso de edio
de texto. Uma sesso de edio inteira pode ser modelada como uma transao. As aes executadas pela
transao so a leitura e a atualizao de um arquivo. Salvar o arquivo ao trmino da edio corresponde
efetivao da transao de edio; sair da sesso do editor sem salvar o arquivo corresponde a abortar a
transao de edio.
Muitos editores de texto usam essencialmente a implementao descrita acima, para garantir que a
sesso de edio seja transacional. Um arquivo novo usado para armazenar o arquivo atualizado. Ao trmino da
sesso de edio, se o arquivo atualizado for salvo, um comando de arquivo rename usado para rebatizar o
arquivo novo com seu nome corrente. Supe-se que o rename seja implementado como uma operao atmica
pelo sistema de arquivo subjacente, e que ele tambm apagar o arquivo antigo.
Infelizmente, essa implementao extremamente ineficiente no contexto dos grandes banco de dados,
j que a execuo de uma nica transao implica copiar o banco de dados inteiro. Alm disso, essa
implementao no permite que transaes concorram uma com as outras. H maneiras prticas de implementar
a atomicidade e a durabilidade que so muito menos onerosas e mais poderosas.
Execues Concorrentes
Os sistemas de processamento de transaes, normalmente, permitem que diversas transaes sejam
executadas de modo concorrente. Permitir que mltiplas transaes concorram na atualizao de dados traz
diversas complicaes em relao consistncia desses dados, conforme vimos anteriormente. Assegura a
consistncia, apesar da execuo concorrente de transaes, exige trabalho adicional; muito mais fcil insistir
na execuo de transaes sequencialmente, uma de cada vez, cada uma comeando somente depois que a
anterior se completou. Porm, h duas boas razoes para permitir a concorrncia.
Uma transao consiste em diversos passos. Alguns envolvem atividade de I/O; outros atividades de CPU.
A CPU e os discos em um sistema de computador podem operar em paralelo. Logo, a atividade de I/O
pode ser feita em paralelo com o processamento na CPU. Assim, o paralelismo entre CPU e o sistema de
I/O pode ser explorado para executar diversas transaes em paralelo. Enquanto uma leitura ou escrita
solicitada por uma transao est em desenvolvimento em um disco, outra transao pode estar sendo
processada na CPU, e outro disco pode estar executando uma leitura ou escrita solicitada por uma
terceira transao. Desse modo, h um aumento no throughput do sistema ou seja, no nmero de
transaes que podem ser executadas em um determinado tempo. De forma correspondente, o uso do
processador e do disco tambm aumentam; em outras palavras, o processador e o disco ficam menos
tempo inativos ou sem executar trabalho til.
Pode haver uma mistura de transaes em execuo simultnea no sistema, algumas curtas e outras
longas. Se a execuo das transaes for sequencial, uma transao curta pode ser obrigada a esperar at
que uma transao longa precedente se complete, o que pode gerar atrasos imprevisveis em sua
execuo. Se as transaes esto operando em diferentes partes do banco de dados, melhor deixa-las
concorre de modo a compartilhar os ciclos de CPU e os acessos de disco entre si. A execuo concorrente
reduz os atrasos imprevisveis na execuo. Se as transaes esto operando em diferentes partes do
262

banco de dados, melhor deixa-las concorrer de modo a compartilhar os ciclos de CPU e os acessos de
disco entre si. Alm disso, reduz tambm o tempo mdio de resposta: o tempo mdio para uma
transao ser completada aps ser submetida.
A motivao para usar a execuo concorrente em um banco de dados essencialmente a mesma para
usar a multiprogramao em um sistema operacional.
Quando vrias transaes so processadas de modo concorrente, a consistncia do banco de dados pode
ser destruda, mesmo que cada transao individual seja executada com correo. Vamos agora apresentar o
conceito de escalas de execuo (schedules), para ajudar na identificao de quais ordens de execuo podem
garantir a manuteno da consistncia.
O sistema de banco de dados deve controlar a interao entre as transaes concorrentes para impedi-las
de destruir sua consistncia. Isso feito por meio de uma variedade de mecanismos chamados de esquemas de
controle de concorrncia.
Considere, novamente, o sistema bancrio simplificado j apresentado, que possui diversas contas, alm
de um conjunto de transaes que acessa e atualiza essa contas. Sejam T1 e T2 duas transaes que transferem
fundos de uma conta para outra. A transao T1 transfere 50 dlares da conta A para a conta B e definida da
seguinte forma:

A transao T2 transfere 10 por cento do saldo da conta A para a conta B e definida da seguinte forma:

Sejam mil e dois mil dlares os valores correntes das contas A e B, respectivamente. Suponha que as duas
transaes sejam executadas em sequncia, T1 seguida de T2. Essa sequncia de execuo representada na fig.
13.3. A sequncia dos passos das instrues esto em ordem cronolgica a partir do topo da figura, com as
instrues de T1 aparecendo na coluna esquerda e as instrues de T2 aparecendo na coluna direita. Depois
que a execuo apresentada na fig. 13.3 terminar, os valores nas contas A e B so 855 e 2145 dlares,
respectivamente. Assim, o montante de dinheiro das contas A e B ou seja, a soma A+B preservado depois da
execuo de ambas as transaes.

263

Analogamente, se as transaes forem executadas em outra sequncia, desta vez T2 seguida de T1, ento
a sequncia de execuo correspondente mostrada na fig. 13.4. Novamente, conforme esperado, a soma A+B
preservada, e os valores finais das contas A e B so 850 e 2150 dlares, respectivamente.
As sequncias de execuo descritas anteriormente so chamadas de escalas de execuo ou escalas. Elas
representam a ordem cronolgica por meio da qual as instrues so executadas no sistema. Claramente, uma
determinada escala de execuo de um conjunto de transaes consiste em todas as instrues dessas transaes
e deve preservar a ordem na qual as instrues aparecem em cada transao individual. Por exemplo, na
transao T1, a instruo write(A) deve aparecer antes da instruo read(B), em qualquer escala vlida. Na
discusso a seguir, iremos nos referir primeira sequncia de execuo (T1 seguida de T2) como escala 1 e
segunda sequncia de execuo (T2 seguida de T1) como escala 2.

Essas escalas de execuo so sequenciais. Cada escala sequencial consiste em uma sequncia de
instrues de vrias transaes em que as instrues que pertencem a uma nica transao aparecem agrupadas.
Assim, para um conjunto de n transaes, h n! escalas sequenciais vlidas diferentes.
Quando vrias transaes so executadas simultaneamente, a escala correspondente pode j no ser
sequencial. Se duas transaes so executadas simultaneamente, o sistema operacional pode executar uma
transao durante algum tempo e, ento, voltar primeira transao durante algum tempo e assim por diante,
alternadamente. Com diversas transaes, o tempo de CPU compartilhado entre todas.
Vrias sequncias de execuo so possveis, j que as vrias instrues, de ambas as transaes podem
ser intercaladas. Geralmente, no possvel exatamente prever quantas instrues de uma transao sero
executadas antes que a CPU alterne para outra transao. Assim, o nmero de escalas de execuo possveis para
um conjunto de n transaes muito maior que n!
264

Retornando ao nosso exemplo anterior, suponha que as duas transaes sejam executadas de modo
concorrente. Uma escala de execuo possvel mostrada na fig. 13.5. Aps essa execuo, chegamos ao mesmo
estado obtido durante a execuo sequencial na ordem T1 seguida de T2. A soma A+B preservada.

Nem todas as execues concorrentes resultam em um estado correto. Para ilustrar, considere a escala
de execuo da fig. 13.6. Depois de sua execuo, chegamos a um estado tal que os valores para as contas A e B
so 950 e 2100 dlares, respectivamente. Esse estado final um estado inconsistente, j que apareceram 50
dlares durante a execuo concorrente. Realmente, a soma A+B no preservada na execuo das duas
transaes.

Se o controle da execuo concorrente deixado completamente sob a responsabilidade do sistema

operacional, muitas escalas de execuo possveis, inclusive aquelas que deixam o banco de dados em um estado
inconsistente como a descrita anteriormente, so factveis. uma tarefa do sistema de banco de dados garantir
que qualquer escala executada deixe o banco de dados em estado consistente. O componente do sistema de
banco de dados que executa esta tarefa chamado de componente de controle de concorrncia.
Podemos assegurar a consistncia do banco de dados, sob execuo concorrente, garantindo que
qualquer escala executada tenho o mesmo efeito de outra que tivesse sido executada sem qualquer
concorrncia. Isto , uma escala de execuo deve, de alguma forma, ser equivalente a uma escala sequencial.
Serializao
O sistema de banco de dados deve controlar a execuo concorrente de transaes para assegurar que o
estado do banco de dados permanea consistente. Antes de examinarmos como o sistema de banco de dados
pode cumprir essa tarefa, temos de entender primeiro quais escalas de execuo podem garantir a consistente e
quais no iro faz-lo.
265

Considerando que as transaes so programas, difcil, pelo carter da computao, determinar quais
so as operaes exatas que uma transao executa, e como as operaes de vrias transaes interagem. Por
essa razo, no faremos interpretaes sobre o tipo de operaes que uma transao pode executar em um item
de dados. Em vez disso, consideraremos apenas duas operaes: read (leitura) e write (escrita). Supomos assim
que, entre uma instruo read (Q) e write(Q) em um item de dado Q, uma transao pode executar uma
sequncia arbitrria de operaes na cpia de Q, que est residindo no buffer local no qual se processa a
transao. Assim, as nicas operaes significativas de uma transao, do ponto de vista da escala de execuo,
so suas instrues de leitura e escrita. Por isso, mostraremos apenas as instrues read e write nas escalas de
execuo, conforme fizemos na representao da escala 3 que mostrada na fig. 13.7.

Vamos discutir formas de equivalncia entre escalas de execuo; elas conduzem s noes de
serializao de conflito e de viso serializada.
Serializao de Conflito
Vamos considerar uma escala de execuo S com duas instrues sucessivas, Ii e Ij, das transaes Ti e Tj
(ij), respectivamente. Se Ii e Ij referem-se a itens de dados diferentes, ento podemos alternar Ii e Ij sem afetar os
resultados de qualquer instruo da escala. Porm, se Ii e Ij referem-se ao mesmo item de dados Q, ento a
ordem de dois passos pode importar. Como estamos lidando apenas com instrues read e write, h quatro casos
a considerar:

Assim, apenas no caso em que ambas, Ii e Ij, so instrues de read a ordem relativa de suas execues
no importante.
Dizemos que Ii e Ij entram em conflito caso elas sejam operaes pertencentes a diferentes transaes,
agindo no mesmo item de dado, e pelo menos uma dessas instrues uma operao de write.
Para ilustrar o conceito de operaes conflitantes consideraremos a escala 3 mostrada na fig. 13.7. A
instruo write (A) de T1 entra em conflito com a instruo read(A) de T2. Porm, a instruo write(A) de T2 no
est em conflito com a instruo read(B) de T1, porque as duas instrues trabalham itens de dados diferentes.
Sejam Ii e Ij instrues consecutivas de uma escala de execuo S. Se Ii e Ij so instrues de transaes
diferentes e no entram em conflito, ento podemos trocar a ordem de Ii e Ij para produzir uma nova escala de
266

execuo S. Esperamos que S seja equivalente a S, j que todas as instrues aparecem na mesma ordem em
ambas as escalas de execuo com exceo de Ii e Ij , cuja ordem no importa.
Como a instruo write(A) de T2 na escala 3 da fig. 13.7 no entra em conflito com a instruo read(B) de
T1, podemos trocar essas instrues para gerar uma escala de execuo equivalente, a escala 5, conforme mostra
a fig. 13.8. A despeito do estado inicial do sistema, ambas as escalas, 3 e 5, produzem o mesmo estado final no
sistema.

Continuaremos a trocar instrues no-conflitantes conforme segue:

Trocar a instruo read(B) de T1 pela instruo read(A) de T2.
Trocar a instruo write(B) de T1 pela instruo write(A) de T2.
Trocar a instruo write(B) de T1 pela instruo read(A) de T2.

O resultado final dessas trocas, conforme mostrado na escala 6 da fig. 13.9, uma escala de execuo
sequencial. Assim, mostramos que a escala 3 equivalente a uma escala de execuo sequencial. Essa
equivalncia implica que, a despeito do estado inicial do sistema, a escala 3 produzir o mesmo estado final
produzido por alguma escala sequencial.

Se uma escala de execuo S puder ser transformada em outra, S, por uma srie de trocas de instrues
no-conflitantes, dizemos que S e S so equivalentes no conflito.
Retornando a nossos exemplos anteriores, observamos que a escala 1 no equivalente no conflito
escala 2. Entretanto, a escala 1 equivalente no conflito escala 3, porque as instrues read(B) e write(B) de T1
podem ser trocadas pelas instrues read(A) e write(A) de T2.
O conceito de equivalncia no conflito leva ao conceito de serializao de conflito. Dizemos que uma
escala de execuo S conflito serializava se ela equivalente no conflito a uma escala de execuo sequencial.
Assim, a escala 3 conflito serializava, j que ela equivalente no conflito escala sequencial 1.
Finalmente, considere a escala 7 da fig. 13.10; ela consiste somente nas operaes significativas (ou seja,
read e write) das transaes T3 e T4. Essa escala de execuo no conflito serializava, j que no equivalente
escala sequencial <T3, T4> ou escala sequencial <T4, T3>.

267

 possvel ter duas escalas de execuo que produzam o mesmo resultado, mas que no sejam
equivalentes no conflito. Por exemplo, considere a transao T5, que transfere 10 dlares da conta B para a conta
A. Seja a escala 8 definida na fig. 13.11. Verificamos que a escala 8 no equivalente no conflito escala
sequencial <T1, T5>, j que, na escala 8, a instruo write(B) de T5 entra em conflito com a instruo read(B) de T1.
Assim, apenas pela troca de instrues consecutivas no conflitantes, no conseguimos mover todas as instrues
de T1 antes daquelas de T5. Porm, os valores finais das contas A e B depois da execuo da escala 8 ou da escala
sequencial <T1, T5> so os mesmos isto , 960, e 2040 dlares, respectivamente.

Podemos ver nesse exemplo que h definies menos triviais de equivalncia de escala que a
equivalncia de conflito. Para o sistema determinar se a escala 8 produz o mesmo resultado que a escala
sequencial <T1, T5>, ele tem de analisar toda computao executada por T1 e T5, em vez de analisar apenas as
operaes read e write. Em geral, tal anlise difcil de implementar e onerosa em termos computacionais.
Porm, h outras definies de equivalncia entre escalas de execuo baseadas puramente nas operaes read
e write.
Viso Serializada
Vamos considerar uma forma de equivalncia que menos restritiva que a equivalncia de conflito,
embora, assim como a equivalncia de conflito, esteja baseada apenas nas operaes read e write das
transaes.
Considere duas escalas de execuo S e S, com o mesmo conjunto de transaes participando de ambas.
As escalas S e S so ditas equivalente na viso se as trs condies seguintes forem satisfeitas:
1. Para cada item de dados Q, se a transao Ti fizer uma leitura no valor inicial de Q na escala S, ento a
transao Ti tambm deve, na escala S, ler o valor inicial de Q.
2. Para cada item de dados Q, se a transao Ti executar um read(Q) na escala S, e aquele valor foi
produzido por meio da transao Tj (se houver), ento a transao Ti tambm dever, na escala S, ler o
valor de Q que foi produzido por meio da transao Tj.
3. Para cada item de dados Q, a transao (se houver) que executa a operao final write(Q) na escala S tem
de executar a operao write(Q) final na escala S.

268

As condies 1 e 2 asseguram que cada transao l os mesmos valores em ambas as escalas e, ento,
executa a mesma computao. A condio 3, em conjunto com as condies 1 e 2, assegura que ambas as escalas
de execuo resultem no mesmo estado final de sistema.
Retornando a nossos exemplos anteriores, notamos que a escala 1 no equivalente em viso escala 2,
j que, na escala 1, o valor da conta A lido pela transao T2 foi produzido por T1, enquanto isso no ocorre na
escala 2. Porm, a escala 1 equivalente em viso escala 3, porque os valor da conta A e B lidos pela transao
T2 foram produzidos por T1 em ambas as escalas.
O conceito de equivalncia de viso leva ao conceito de serializao de viso. Dizemos que uma escala de
execuo S tem viso serializada se for equivalente, em viso, a uma escala de execuo sequencial.
Para ilustrar, suponha que aumentemos a escala 7 com a incluso da transao T6 obtendo a escala 9,
conforme pode ser visto na fig. 13.12. A escala 9 a viso serializada. De fato, ela equivalente em viso escala
sequencial <T3, T4, T6>, j que uma instruo read(Q) l o valor inicial de Q em ambas as escalas, e T6 executa a
escrita final de Q em ambas as escalas.

Toda escala conflito serializava viso serializava, mas h escala viso serializava que no so conflito
serializava. Realmente, a escala 9 no conflito serializava, uma vez que qualquer par de instrues consecutivas
conflitante e, assim, no possvel nenhuma troca de instrues.
Observe que, na escala 9, as transaes T4 e T6 executam operaes write(Q) sem terem executado uma
operao read(Q). Esse tipo de escrita chamado de escrita cega (blind write). As escritas cegas aparecem em
algumas escalas viso serializava que no so conflito serializava.
Recuperao
At o momento, estudamos quais escalas de execuo so aceitveis do ponto de vista da consistncia do
banco de dados, supondo, de modo implcito, que no ocorram falhas de transao. Veremos agora os efeitos das
falhas de transao durante a execuo concorrente.
Se uma transao Ti falhar, por qualquer razo, precisamos desfazer seus efeitos para garantir a
propriedade de atomicidade da transao. Em um sistema que permite execuo concorrente, tambm
necessrio assegurar que qualquer transao Tj que seja dependente de Ti (quer dizer, Tj leu dados escritos por Ti)
tambm seja abortada. Para alcanar essa segurana, precisamos colocar restries no tipo de escalas permitidas
no sistema.
Escala de Execuo Recuperveis
Considere a escala 11, mostrada na fig. 13.13, na qual T9 uma transao que executa apenas uma
instruo: read(A). Suponha que o sistema permita que T9 seja efetivada imediatamente aps executar a
instruo read(A). Assim, T9 efetivada antes que T8 o seja. Agora, suponha que T8 falhe antes da efetivao.
Como T9 leu o valor do item de dados A escrito por T8, temos de abortar T9 para assegurar a atomicidade da
transao. Porm, T9 j foi efetivada e no poder ser abortada. Assim, temos uma situao em que impossvel
se recuperar corretamente da falha de T8.

269

A escala 11, com a efetivao acontecendo imediatamente aps a instruo read(A), um exemplo de
escala de execuo no-recupervel que, portanto, no deveria ser permitida. A maioria dos sistemas de banco
de dados exige que todas as escalas sejam recuperveis. Uma escala recupervel aquela na qual, para cada par
de transaes Ti e Tj, tal que Tj leia itens de dados previamente escritos por Ti, a operao de efetivao de Ti
aparea antes da operao de efetivao de Tj.
Escalas sem cascata
Mesmo em uma escala recupervel, para o sistema recuperar-se corretamente da falha de transao Ti,
pode ser que seja necessrio desfazer diversas transaes. Tais situaes ocorrem se as transaes leram dados
escritos por Ti. Como ilustrao, considere a escala parcial da fig. 13.14. A transao T10 escreve um valor para A
que lido pela transao T11. A transao T11 escreve um valor para A que lido pela transao T11. Suponha que,
nesse momento, T10 falhe. T10 dever ser desfeita. Como T11 dependente de T10, T11 dever ser desfeita. Como
T12 dependente de T11, T12 dever ser desfeita. Esse fenmeno, no qual a falha de uma nica transao conduz a
uma srie de reverses de transao, chamado de retorno em cascata (cascading rollback).

O retorno em cascata indesejvel, j que leva a desfazer uma quantia significativa de trabalho.
conveniente restringir as escalas quelas nas quais os retornos em cascata no possam acontecer. Tais escalas so
chamadas de escalas sem cascata. Uma escala sem cascata aquela na qual cada par de transaes Ti e Tj, tal que
Tj leia um item de dados previamente escrito por Ti, a operao de efetivao de Ti aparea antes da operao de
leitura de Tj. fcil verificar que toda escala sem cascata tambm recupervel.
Implementao do Isolamento
At o momento, vimos quais propriedades uma escala deve ter para deixar o banco de dados em um
estado consistente e para permitir o tratamento seguro de possveis falhas de transao. Especificamente, as
escalas que so conflito ou viso serializava e sem cascata satisfazem essas exigncias.
H vrios esquemas de controle de concorrncia que podemos usar para garantir que, at mesmo quando
diversas transaes so executadas de modo concorrente, sejam geradas apenas escalas aceitveis, a despeito de
como o sistema operacional compartilha os recursos (como o tempo de CPU) entre as transaes.
Como um exemplo trivial de um esquema de controle de concorrncia, considere este: uma transao
bloqueia (lock) o banco de dados inteiro antes de comear e libera o bloqueio aps sua efetivao. Enquanto uma
transao mantm um bloqueio, nenhuma outra tem permisso para realizar um bloqueio, todas elas so
obrigadas a esperar sua liberao. Como resultado dessa poltica de bloqueio, apenas uma transao pode
executar um bloqueio de cada vez. Logo, so geradas apenas escalas sequenciais. Estas so trivialmente
serializveis e fcil verificar que so tambm sem cascata.

270

Um esquema de controle de concorrncia como esse apresenta um desempenho pobre, j que fora as
transaes a esperarem o trmino das precedentes antes que possam comear. Em outras palavras, ele
possibilita um baixo grau de concorrncia. A execuo concorrente traz vrios benefcios em relao ao
desempenho.
O objetivo dos esquemas de controle de concorrncia proporcionar um alto grau de concorrncia,
enquanto garante que todas as escalas geradas sejam conflito serializava ou viso serializava, e tambm sejam
em cascata.
Os esquemas tm diferentes caractersticas em termos do grau de concorrncia observado e da
quantidade de overhead em que incorrem. Alguns deles permite que apenas escalas conflito serializava sejam
geradas, outros permite que escalas viso serializvel, que no so conflito serializava, tambm sejam geradas.
Definio de Transao em SQL
Uma linguagem de manipulao de dados deve possuir um construtor para especificar o conjunto de
aes que constitui uma transao.
O padro SQL especifica que uma transao comea de modo subentendido. As transaes so
terminadas por uma das seguintes declaraes SQL:
Commit work executa a efetivao da transao corrente e comea uma nova.
Rollback work aborta a transao corrente.
A palavra-chave work opcional em ambas as declaraes. Se um programa termina sem um desses
comandos, as atualizaes so efetivadas ou desfeitas a escolha no especificada pelo padro, e
dependente da implementao.
O padro especifica tambm que o sistema deve assegurar a serializao e retorno sem cascata. A
definio de serializao usada pelo padro a que estabelece que uma escala deve ter o mesmo efeito de uma
escala sequencial. Assim, tanto serializao de conflito quanto serializao de viso so aceitveis.
O padro SQL-92 tambm permite que se estabelea para uma transao uma execuo de modo no
serializava em relao a outras transaes. Por exemplo, uma transao pode operar em nvel de read sem
efetivao (read uncommitted), permitindo que as transaes leiam registros mesmo sem suas efetivaes. Essa
caractersticas oferecida para transaes longas, cujos resultados no precisam ser exatos. Por exemplo, uma
informao aproximada geralmente suficiente para estatsticas usadas na otimizao de consultas. Se essas
transaes forem executadas de uma maneira serializava, elas poderiam interferir em outras transaes,
provocando atrasos.
O nvel de consistncia especificado pela SQL-92 :
Serializvel o default (padro).
Read repetitivo somente permite leitura de registros que sofreram efetivao e, alm disso, exige que
nenhuma outra transao consiga atualizar um registro entre duas leituras feitas por uma transao.
Entretanto, a transao pode no ser serializava com respeito a outras transaes. Por exemplo, quando
se est procurando registros que satisfaam algumas condies, uma transao pode achar alguns dos
registros inseridos por uma transao que sofreu efetivao, mas no encontrar os outros.
Read com efetivao permite que apenas registros que sofreram efetivao sejam lidos, mas no exige
read repetitivo. Por exemplo, entre duas leituras de um registro feitas por uma transao, os registros
podem ter sido atualizados por meio de transaes que obtiveram efetivao.
Read sem efetivao permite a leitura de registros que no sofreram efetivao. o nvel mais baixo de
consistncia permitido pela SQL-92.
Teste de Serializao
Ao projetar esquemas de controle de concorrncia, devemos mostrar que as escalas geradas por eles so
serializveis. Para faz-lo, primeiro temos de entender como determinar, para uma escala S em particular, se ela
serializava. Nesta seo, apresentaremos mtodos para determinar serializao de conflito e serializao de viso.
271

Mostraremos que h um algoritmo simples e eficiente para determinar a serializao de conflito. Entretanto, no
h nenhum algoritmo eficiente para determinar a serializao de viso.
Teste para Serializao de Conflito
Seja S uma escala. Construmos um grfico direcionado, chamado grfico de precedncia de S. Esse
grfico consiste em um par G=(V,E), em que V um conjunto de vrtices e E um conjunto de arestas. O conjunto
de vrtices consiste em todas as transaes que participam da escala. O conjunto de arestas consiste em todas as
transaes que participam da escala. O conjunto de arestas consiste em todas as arestas Ti
Tj para as quais uma
das seguintes condies se verifica:
1. Ti executa write(Q) antes de Tj executar read(Q).
2. Ti executa read(Q) antes de Tj executar write(Q).
3. Ti executa write(Q) antes de Tj executar write(Q).
Se h uma aresta Ti
Tj no grfico de precedncia, ento, em qualquer escala sequencial S equivalente a
S, Ti deve aparecer antes de Tj.
Por exemplo, o grfico de precedncia para a escala 1 mostrado na fig. 13.15a. Ele contm a nica
aresta T1
T2, j que todas as instrues de T1 so executadas antes da primeira instruo de T2 ser executada. De
forma semelhante, a fig. 13.15b mostra o grfico de precedncia para a escala 2 com a nica aresta T2
T1, j que
todas as instrues de T2 so executadas antes da primeira instruo de T1 ser executada.

O grfico de precedncia para a escala 4 mostrado na fig. 13.16. Ele contm a aresta T1
T2, porque T1
executa read(A) antes de T2 executar write(A). Ele tambm contm a aresta T2
T1, porque T2 executa read(B)
antes de T1 executar write(B).
Se o grfico de precedncia para S tem um ciclo, ento a escala S no conflito serializava. A ordem de
serializao pode ser obtida por meio da classificao topolgica, que estabelece uma ordem linear consistente
com a ordem parcial do grfico de precedncia. Em geral, vrias ordens lineares possveis podem ser obtidas por
meio da classificao topolgica. Por exemplo, o grfico da fig. 13.17a possui ordens lineares aceitveis, conforme
ilustrado pelas fig. 13.17b e 13.17c.
Assim, para testar a serializao de conflito, precisamos construir o grfico de precedncia e evocar um
algoritmo de deteco de ciclos. Algoritmos de deteco de ciclos podem ser encontrados em livros-texto sobre
algoritmos. Os algoritmos de deteco de ciclos, como aqueles baseados em depth-first search, so da ordem de
n2 operaes, em que n o nmero de vrtices no grfico (ou seja, o nmero de transaes). Assim, temos um
esquema prtico para determinar a serializao de conflito.
Retornando a nossos exemplos anteriores, observe que os grficos de precedncia para as escalas 1 e 2
(fig. 13.15) realmente no contm ciclos. O grfico de precedncia para a escala 4 (fig. 13.16), por outro lado,
contm um ciclo que indica que essa escala no conflito serializava.
Teste para Serializao de Viso
Podemos modificar o teste do grfico de precedncia para serializao de viso, conforme mostraremos a
seguir. Entretanto, o teste resultante oneroso em relao ao tempo de CPU. De fato, testar serializao de viso
um problema caro em termos computacionais, como veremos posteriormente.

272

No teste para serializao de conflito, sabemos que, se duas transaes, Ti e Tj, tm acesso a um item de
dados Q, e pelo menos uma dessas transaes escreve Q, ento a aresta Ti
Tj ou a aresta Tj
Ti ser inserida no
grfico de precedncia. Porm, isto no mais ocorre no teste para serializao de viso. Como veremos em breve,
essa diferena a razo da incapacidade em se chegar a um algoritmo eficiente para esse teste.
Considere a escala 9 da fig. 13.12. Se seguirmos a regra do teste para serializao de conflito e criamos o
grfico de precedncia, obteremos o grfico da fig. 13.18. O grfico contm um ciclo indicando que a escala 9 no
conflito serializava. Entretanto, como vimos anteriormente, a escala 9 viso serializava, j que ela
equivalente em viso escala sequencial <T3, T4, T6>. A aresta T4
T3 no deveria ter sido inserida no grfico, j
que os valores do item Q produzidos por T3 e T4 no foram usados por quaisquer outras transaes, e T6 produziu
um valor final novo de Q. As instrues write(Q) de T3 e T4 so chamadas de gravaes inteis.

Com isso, mostramos que no podemos simplesmente usar o esquema de grfico de precedncia citado
anteriormente para testar serializao de viso. Precisamos desenvolver um esquema para decidir se uma aresta
deve ou no ser inserida no grfico de precedncia.
Seja S uma escala. Suponha que a transao Tj leia o valor do item de dado Q escrito por Ti. claro que, se
S viso serializava, ento, em qualquer escalar que S seja equivalente a S, Ti deve preceder Tj. Suponha agora
que, na escala S, a transao Tk executou uma write(Q). Ento, na escala S, Tk deve preceder Ti ou deve seguir Tj.
273

Ela no poder aparecer entre Ti e Tj, porque dessa forma Tj no leria o valor de Q escrito por Ti e, assim, S no
seria equivalente em viso a S.
Tais requisitos no podem ser expressos no modelo simples de grfico de precedncia discutido
anteriormente. A dificuldade acontece porque sabemos que, no exemplo precedente, um dos pares de arestas,
Tk
Ti ou Tj
Tk, dever ser inserido no grfico, mas no temos, contudo, formulada a regra para determinar qual
a escolha apropriada.
Para formul-la, precisamos expandir o grfico de precedncia de modo a incorporar as arestas rotuladas.
Chamamos esse grfico de grfico de precedncia rotulado. Como antes, os ns do grfico so as transaes que
participam da escala. As regras para a insero de arestas rotuladas so descritas a seguir.
Seja S uma escala que consiste nas transaes {T1, T2, ..., Tn}. Sejam Tb e Tf duas transaes fictcias, tais
que Tb execute write(Q) para todo Q que sofreu acesso em S e Tf, execute uma read(Q) para todo Q que sofreu
acesso em S. Construmos uma nova escala S a partir de S por meio da insero de Tb no incio de S e do
acrscimo de Tf no final de S. Construmos o grfico de precedncia rotulado para a escala S conforme segue:
1. Adicione uma aresta
, se a transao Tj l o valor do item de dados Q escrito pela transao Ti.
2. Remova todas as arestas que incidam em transaes inteis. Uma transao Ti intil se no houver
caminho, no grfico de precedncia, de Ti para a transao Tf.
3. Para todo item de dados Q, tal que Tj l o valor de Q escrito por Ti, Tk executa um write(Q) e TkTb, faa o
seguinte:
no grfico de precedncia rotulado.
a. Se Ti=Tb e TjTf, ento insira a aresta
b. Se TiTb e Tj=Tf, ento insira a aresta
no grfico de precedncia rotulado.
c. Se Ti=Tb e TjTf, ento insira o par de arestas
e
no grfico de precedncia rotulado,
em que p um inteiro maior que 0 que no tenha sido usado anteriormente para rotular arestas.
A regra 3c determina que, se Ti escrever um item de dados lido por Tj, ento uma transao Tk que escreva o
mesmo item de dados deve vir antes de Ti ou depois de Tj. As regras 3a e 3b so casos especiais resultantes do
fato de que, necessariamente, Tb e Tf so a primeira e a ltima transao, respectivamente. Quando aplicamos a
regra 3c, no estamos exigindo que Tk esteja simultaneamente antes de Ti e depois de Tj. Em vez disso,
poderemos escolher onde Tk aparecer, em uma ordem sequencial equivalente.
Como ilustrao, considere novamente a escala 7 (fig. 13.10). O grfico construdo pelos passos 1 e 2
mostrado na fig. 13.19a. Ele contm a aresta
, j que T3 l o valor de Q escrito por Tb. ele contm a aresta
, j que T3 foi a ltima transao que escreveu Q e, assim, Tf leu aquele valor. O grfico final que
corresponde escala 7 mostrado na fig. 13.19b. Ele contm a aresta
resultante do passo 3a. Ele contm
a aresta
como resultado do passo 3b.

274

Agora, considere a escala 9 (fig. 13.12). O grfico construdo nos passos 1 e 2 mostrado na fig. 13.20a. O
grfico final mostrado na fig. 13.20b. Ele contm as arestas
e
como resultado do passo 3a. Contm
as arestas
(j no grfico) e
como resultado do passo 3b.

Finalmente, considere a escala 10 da fig. 13.21. A escala 10 viso serializava, j que equivalente em
viso escala sequencial <T3, T4, T7>. O grfico de precedncia rotulado correspondente, construdo nos passos 1
e 2 mostrado na fig. 13.22a. O grfico final mostrado na fig. 13.22b. As arestas
e
foram inseridas
como resultado da regra 3a. O par de arestas
aplicao da regra 3c.

275

foi inserido como resultado de uma nica

Os grficos mostrados nas figuras 13.19b e 13.22b contm os seguintes ciclos mnimos, respectivamente:

O grfico da fig. 13.20b, por outro lado, no contm ciclos.

Se o grfico no contm ciclos, a escala correspondente viso serializava. Realmente, o grfico da figura
13.20b no contm ciclos, e sua escala correspondente, escala 9, viso serializava. Entretanto, se o grfico
contiver um ciclo, essa condio no implica necessariamente que a escala correspondente no seja viso
serializava. Realmente, o grfico da fig. 13.19b contm um ciclo, contudo sua escala correspondente, escala 7,
no viso serializava. O grfico da fig. 13.22b, por outro lado, contm um ciclo, mas sua escala correspondente,
escala 10, viso serializava.
Como, ento, determinamos se uma escala viso serializava? A resposta est em uma intepretao
apropriada do grfico de precedncia. Suponha que haja n pares de arestas distintas. Ou seja, aplicamos n vezes a
regra 3c na construo do grfico de precedncia. Haver ento 2n grficos diferentes, sendo que cada grfico
contm apenas uma aresta de cada par. Se algum desses grficos for acclico, ento a escala correspondente ser
viso serializava. A ordem de serializao determinada pela remoo das transaes fictcias Tb e Tf e pela
classificao topolgica do grfico acclico restante.
Volte ao grfico da fig. 13.22b. como h exatamente um par distinto, h dois grficos diferentes que
devem ser considerados. Os dois grficos so mostrados na fig. 13.23. Como o grfico da fig. 13.23a acclico,
sabemos que a escala correspondente, escala 10, viso serializava.
O algoritmo descrito anteriormente obriga testar exaustivamente todos os possveis grficos distintos.
Para isso mostrou-se que o problema do teste de um grfico acclico nesse conjunto recai sobre a classe de

276

problemas NP-completos. Qualquer algoritmo para um problema NP-completo quase certamente tomar um
tempo exponencial proporcional ao tamanho do problema.

De fato, foi mostrado que o problema do teste para serializao de viso , ele prprio, NP-completo.
Assim, muito provavelmente no h um algoritmo eficiente para testar serializao de viso. Entretanto, os
esquemas de controle de concorrncia ainda podem usar as condies suficientes para serializao de viso. Ou
seja, se as condies suficientes forem satisfeitas, a escala viso serializava, mas pode haver escalas viso
serializava que no satisfaam as condies suficientes.

277

Controle de Concorrncia
J vimos que uma propriedade fundamental da transao o isolamento. Quando diversas transaes so
executadas de modo concorrente em um banco de dados, a propriedade do isolamento pode no ser preservada.
necessrio que o sistema controle a interao entre transaes concorrentes; esse controle alcanado por
meio de uma larga gama de mecanismo chamados esquemas de controle de concorrncia.
Todos os esquemas de controle de concorrncia tm por base a propriedade de serializao
(serializability). Isto , todos os esquemas apresentados aqui garantem que a ordenao de processamento
serializada.
Protocolo com Base em Bloqueios (Lock)
Um meio de garantir a serializao obrigar que o acesso aos itens de dados seja feito de maneira
mutuamente exclusiva; isto , enquanto uma transao acessa um item de dados, nenhuma outra transao pode
modifica-lo. O mtodo mais usado para sua implementao permitir o acesso a um item de dados somente se
ele estiver bloqueado.
Bloqueios
H vrios modos por meio dos quais um item de dado pode ser bloqueado. Vamos nos restringir a dois
deles:
1. Compartilhado. Se uma transao Ti obteve um bloqueio compartilhado (denotado por S) sobre o item Q,
ento Ti pode ler, mas no escrever Q.
2. Exclusivo. Se uma transao Ti obteve um bloqueio exclusivo (denotado por X) do item Q, ento Ti pode
tanto ler como escrever Q.
Precisamos que toda transao solicite o bloqueio do item Q de modo apropriado, dependendo do tipo
de operao realizada em Q. A solicitao direcionada para o gerenciador do controle de concorrncia. A
transao pode realizar suas operaes somente depois que o gerenciador de controle de concorrncia. A
transao pode realizar suas operaes somente depois que o gerenciador de controle de concorrncia conceder
(grants) o bloqueio para transao.
Dado um conjunto de bloqueios, podemos definir uma funo de compatibilidade sobre eles. Seja A e B
uma representao arbitrria dos modos de bloqueio. Suponha que uma transao Ti solicite um bloqueio do
modo A sobre o item Q, sobre o qual a transao Tj (TiTj) mantm um bloqueio do modo B.
Se uma transao Ti consegue um bloqueio sobre Q imediatamente, a despeito da presena de um
bloqueio do modo B, ento dizemos que o modo A compatvel com o modo B. Essa funo pode ser
convenientemente representada por uma matriz. A relao de compatibilidade entre os dois modos de bloqueio
usados aqui apresentada na matriz comp da fig. 14.1. Um elemento comp(A,B) da matriz possui valor
verdadeiro se, e somente se, o modo A compatvel com o modo B.

Note que o modo compartilhado compatvel com o modo compartilhado, mas no com o modo
exclusivo. A qualquer hora podem ser feitos diversos bloqueios compartilhados simultaneamente (por diferentes
transaes) sobre um item de dado em particular. Uma solicitao de bloqueio exclusivo precisa esperar at que
um bloqueio compartilhado termine para ser efetivada.
Uma transao solicita um bloqueio compartilhado do item de dado Q executando a instruo lock-S(Q).
Analogamente, um bloqueio exclusivo solicitado pela instruo lock-X(Q). um item de dado Q pode ser
desbloqueado por outra transao, o gerenciador de controle de concorrncia no conceder o bloqueio at que
todos os bloqueios incompatveis mantidos pela outra transao sejam desfeitos.

278

A transao Ti pode desbloquear um item de dado a qualquer momento. Note que uma transao precisa
manter o bloqueio do item de dado durante todo o tempo de acesso quele item. Alm disso, o desbloqueio
imediatamente aps o acesso final nem sempre interessante, j que pode comprometer a serializao.
Como ilustrao, considere novamente o sistema bancrio apresentado anteriormente.
Sejam A e B duas contas que so acessadas pelas transaes T1 e T2. A transao T1 transfere 50 dlares
da conta A para a conta B e tem a forma:

A transao T2 apresenta o saldo total das contas A e B isto , a soma A+B e definida por:

Suponha que os saldos de A e B sejam 100 e 200 dlares, respectivamente. Se essas duas transaes so
executadas serialmente, na ordem T1, T2 ou T2, T1, ento a transao T2 mostrar o valor 300 dlares. Se, no
entanto, essas transaes forem executadas concorrentemente, a escala de execuo 1, mostrada na fig. 14.2,
pode ocorrer. Nesse caso, a transao T2 mostrar o resultado 250 dlares, que no correto. A razo desse erro
provm da falta de bloqueio em tempo hbil do item de dado B, com isso T2 mostra uma situao inconsistente.
A escala de execuo mostra as aes que so executadas pelas transaes, assim como os pontos em
que os bloqueios so concedidos pelo gerenciador de controle de concorrncia. Uma transao que pede um
bloqueio no pode executar sua prxima ao at que o bloqueio seja concedido pelo gerenciador de controle de
concorrncia; da o bloqueio precisa ser concedido no intervalo de tempo entre a operao de pedido de
bloqueio e a ao seguinte da transao. Em que momento, exatamente, o bloqueio concedido imediatamente
antes da ao seguinte da transao. Assim, retiraremos a coluna que indica as aes do gerenciador de controle
de concorrncia de todas as escalas de execuo apresentadas.
Suponha, agora, que os desbloqueios sejam realizados ao final da transao. A transao T3 similar
transao T1, com desbloqueio ao final da transao, e definida como:

A transao T2 apresenta o saldo total das contas A e B isto , a soma A+B e definida por:
279

Suponha que os saldos de A e B sejam 100 e 200 dlares, respectivamente. Se essas duas transaes so
executadas serialmente, na ordem T1, T2 ou T2, T1, ento a transao T2 mostrar o valor 300 dlares. Se, no
entanto, essas transaes forem executadas concorrentemente, a escala de execuo 1, mostrada na fig. 14.2,
pode ocorrer. Nesse caso, a transao T2 mostrar o resultado 250 dlares, que no correto. A razo desse erro
provm da falta de bloqueio em tempo hbil do item de dado B, com isso T2 mostra uma situao inconsistente.
A escala de execuo mostra as aes que so executadas pelas transaes, assim como os pontos em
que os bloqueios so concedidos pelo gerenciador de controle de concorrncia. Uma transao que pede um
bloqueio no pode executar sua prxima ao at que o bloqueio seja concedido pelo gerenciador de controle de
concorrncia; da o bloqueio precisa ser concedido no intervalo de tempo entre a operao de pedido de
bloqueio e a ao seguinte da transao. Em que momento, exatamente, o bloqueio concedido dentro desse
intervalor no importante; o bloqueio considerado seguro mesmo que concedido imediatamente antes da
ao seguinte da transao. Assim, retiraremos a coluna que indica as aes do gerenciador de controle de
concorrncia de todas as escalas de execuo apresentadas aqui.
Suponha, agora, que os desbloqueios sejam realizados ao final da transao. A transao T3 similar
transao T1, com desbloqueio ao final da transao, e definida como:

A transao T4 corresponde T2, com desbloqueio ao final da transao, e definida como:

280

Voc pode notar que a sequncia de leituras e escritas da escala de execuo 1, que resulta no total
incorreto de 250 dlares, no ocorre usando T3 e T4. Outras escalas so possveis. T4 no apresentar um
resultado inconsistente, qualquer que seja a escala de execuo.
Infelizmente, o uso de bloqueio pode causar situaes indesejveis. Considere a escala parcial de T3 e T4
na fig. 14.3. J que T3 mantm um bloqueio exclusivo sobre B, e T4 solicita um bloqueio compartilhado em B, e T4
solicita um bloqueio compartilhado em B, T4 espera que T3 libere B. Analogamente, como T4 mantm um bloqueio
compartilhado de A, e T3 est solicitando um bloqueio exclusivo em A, T3 est esperando que T4 libere A. Assim,
chegamos a uma situao em que nenhuma dessas transaes pode processar em sua forma normal. Essa
situao chamada de deadlock (impasse). Quando um deadlock ocorre, o sistema precisa desfazer uma das duas
transaes. Uma vez desfeita a transao, os itens de dados so, ento, avaliados por outras transaes, que
podem continuar com suas execues. Retornaremos aos meios de tratamento do deadlock mais adiante.

Se no usarmos o bloqueio, ou desbloqueio, dos itens de dados, to logo seja possvel, aps sua leitura ou
escrita, poderemos chegar a resultados inconsistentes. Por outro lado, se no desbloquearmos um item de dados
antes de solicitarmos um bloqueio a outro item de dados, o deadlock poder ocorrer. H formas de evitar o
deadlock em algumas situaes. Entretanto, em geral, deadlocks so problemas inerentes ao bloqueio, necessrio
se desejarmos evitar estados inconsistentes. Os deadlocks podem ser preferveis a estados inconsistentes, j que
podem ser tratados por meio do rollback (reverso) da transao, enquanto os estados inconsistentes podem
originar problemas reais, no tratados pelo sistema de banco de dados.
Exigimos que cada transao do sistema siga determinado conjunto de regras, chamado de protocolo de
bloqueio, indicando quando uma transao pode ou no bloquear ou desbloquear cada um dos itens de dados. O
protocolo de bloqueio restringe o nmero de escalas de execuo possveis. O conjunto de todas as escalas desse
tipo um subconjunto de todas as escalas serializadas possveis. Apresentaremos diversos protocolos de bloqueio
que permitem somente escalas com serializao de conflitos. Antes de faz-lo, precisamos de algumas definies.
Seja {T0, T1, ..., Tn} um conjunto de transaes participantes de uma escala de execuo S. Dizemos que Ti
precede Tj em S, denotando Ti
Tj, se h um item de dado Q tal que Ti consegue bloqueio do tipo A sobre Q e
depois Tj consegue bloqueio do tipo B sobre Q e comp (A,B) = falso. Se Ti
Tj, ento essa precedncia implica que,
em qualquer escala serial equivalente, Ti precisa aparecer antes de Tj. Observe que esse grfico similar ao usado
anteriormente para testar serializao de conflito. Dizemos que um protocolo de bloqueio garante serializao de
conflito se, e somente se, para todas as escalas de execuo legais, as relaes associadas
so acclicas.
Concesso de Bloqueios
Quando uma transao solicita bloqueio sobre um determinado item de dado em particular, e nenhuma
outra transao mantm o mesmo item de dado bloqueado de modo conflitante, tal bloqueio pode ser
concedido. Entretanto, preciso ter cuidado para evitar o seguinte cenrio. Suponha que a transao T2 tenha um
bloqueio compartilhado sobre um item de dado e outra transao T1 solicite um bloqueio exclusivo do mesmo
281

item. Claro que T1 ter de esperar at que o bloqueio compartilhado feito por T2 seja liberado. Enquanto isso,
uma transao T3 pode solicitar que um bloqueio compartilhado feito por T2 seja liberado. Enquanto isso, uma
transao T3 pode solicitar um bloqueio compartilhado sobre o mesmo item de dado. O bloqueio pedido
compatvel com o bloqueio concedido a T2, de modo que o bloqueio compartilhado pode ser concedido a T3.
Nessa altura, T2 pode liberar o bloqueio, mas T1 ter de esperar agora, at que T3 termine. Novamente, aparece
uma nova transao T4 que solicita um bloqueio compartilhado sobre o mesmo item de dado e ele concedido
antes que T3 libere o dado. De fato, possvel que haja uma sequncia de transaes solicitando bloqueios
compartilhados sobre um item de dado, e que cada uma delas libere seu bloqueio um pouco antes de que novo
bloqueio seja concedido outra transao, de modo que T1 nunca consegue seu bloqueio exclusivo. A transao
T1 poder nunca ser processada, e ela chamada de inane (starved).
Podemos evitar a inanio de transaes da seguinte forma. Quando uma transao Ti solicita o bloqueio
do item de dados Q de um modo particular M, o bloqueio concedido contato que:
1. No haja nenhuma outra transao com bloqueio sobre Q cujo modo de bloqueio seja conflitante com
M.
2. No haja nenhuma outra transao que esteja esperando um bloqueio sobre Q e que tenha feito sua
solicitao de bloqueio antes de Ti.
Protocolo de Bloqueio em Duas Fases
Um dos protocolos que garante a serializao o protocolo de bloqueio em duas fases (two-phase locking
protocol). Esse protocolo exige que cada transao emita suas solicitaes de bloqueio e desbloqueio em duas
fases:
1. Fase de expanso. Uma transao pode obter bloqueios, mas no pode liberar nenhum.
2. Fase de encolhimento. Uma transao pode liberar bloqueios, mas no consegue obter nenhum bloqueio
novo.
Inicialmente, uma transao est na fase de expanso. A transao adquire os bloqueios de que precisa.
To logo a transao libera um bloqueio, ela entra na fase de encolhimento e no poder solicitar novos
bloqueios.
Por exemplo, as transaes T3 e T4 tm duas fases. Por outro lado, as transaes T1 e T2 no tm duas
fases. Note que as instrues de desbloqueio no precisam aparecer no final da transao. Por exemplo, no caso
da transao T3, podemos colocar a instruo unlock(B) logo aps a instruo lock-X(A) e ainda assim manter a
propriedade do bloqueio em duas fases.
Podemos mostrar que o protocolo do bloqueio em duas fases garante a serializao de conflitos.
Considere qualquer transao. O ponto da escala no qual a transao obteve seu bloqueio final (o fim da fase de
expanso) chamado de ponto de bloqueio da transao. Assim, as transaes podem ser ordenadas de acordo
com seus pontos de bloqueio essa ordenao , de fato, uma ordenao serializada de transaes.
O bloqueio em duas fases no garante a ausncia de deadlock. Observe que as transaes T3 e T4
possuem duas fases, mas na escala de execuo 2 (fig. 14.3) elas esto em um deadlock.
Recordamos que, alm de serem serializada, desejvel que as escalas de execuo no sejam em
cascata. O rollback em cascata pode ocorrer sob o protocolo de bloqueio em duas fases. Como ilustrao,
considere a escala da fig. 14.4. Cada transao observa o protocolo de bloqueio em duas fases, mas a falha de T5
depois do passo read(A) da transao T7 ocasiona o rollback em cascata de T6 e T7.

282

Os rollbacks em cascata podem ser evitados por uma modificao no bloqueio em duas fases chamado
protocolo de bloqueio em duas fases severo (strict two-phase locking). O protocolo de bloqueio em duas fases
severo exige, em adio ao bloqueio feito em duas fases, que todos os bloqueios de modo exclusivo tomados por
uma transao sejam mantidos at que a transao seja efetivada. Essa exigncia garante que qualquer dado
escrito por uma transao que no foi ainda efetivada seja bloqueado de modo exclusivo at que a transao seja
efetivada, evitando que qualquer outra transao leia o dado em transao.
Outra variante do bloqueio em duas fases o protocolo de bloqueio em duas fases rigoroso, que exige
que todos os bloqueios sejam mantidos at que a transao seja efetivada. Pode ser facilmente verificado que,
com o bloqueio em duas fases rigoroso, as transaes podem ser serializadas na ordem de sua efetivao. A
maioria dos sistemas de banco de dados implementa ou o bloqueio em duas fases severo ou o rigoroso.
Considere as duas transaes seguintes para as quais mostramos somente algumas das mais significativas
operaes de leitura (read) e escrita (write). A transao T8 definida como:

A transao T9 definida como:

Se empregarmos o protocolo de bloqueio em duas fases, ento T8 precisar bloquear a1 de modo

exclusivo. Portanto, qualquer execuo concorrente de ambas as transaes atinge uma execuo serial. Note,
entretanto, que T8 precisa de um bloqueio exclusivo de a1 somente ao final de sua execuo, quando ela escreve
a1. Assim, se T8 estiver bloqueando ai de modo compartilhado e depois mudar esse bloqueio para o modo
exclusivo, poderemos obter mais concorrncia, j que T8 e T9 poderiam manter acesso simultneo a a1 e a2.
Essa observao remete-nos ao refinamento do protocolo bsico do bloqueio em duas fases, no qual a
converso de bloqueios permitida. Podemos proporcionar um mecanismo para promover um bloqueio
compartilhado para exclusivo de promoo (upgrade) e de exclusivo para compartilhamento de rebaixamento
(downgrade). A converso de bloqueio no pode ser arbitrria. Pelo contrrio, a promoo s pode acontecer
durante a fase de expanso, enquanto o rebaixamento somente ocorre na fase de encolhimento.
Retornando a nosso exemplo, as transaes T8 e T9 podem ser executadas concorrentemente sob o
protocolo de bloqueio em duas fases refinado, como mostra a escala incompleta da fig. 14.5, em que somente
algumas das instrues de bloqueio so mostradas.
Note que uma transao tentando a promoo de um bloqueio do item Q pode ser forada a esperar.
Essa espera forada ocorre se Q estiver bloqueado por outra transao em modo compartilhado.

283

Tanto quanto o protocolo de bloqueio em duas fases, o bloqueio em duas fases com converso de
bloqueio no pode ser arbitrria. Pelo contrrio, a promoo s pode acontecer durante a fase de expanso,
enquanto o rebaixamento somente ocorre na fase de encolhimento.
Retornando a nosso exemplo, as transaes T8 e T9 podem ser executadas concorrentemente sob o
protocolo de bloqueio em duas fases refinado, como mostra a escala incompleta da fig. 14.5, em que somente
algumas das instrues de bloqueio so mostradas.
Note que uma transao tentando a promoo de um bloqueio do item Q pode ser forada a esperar.
Essa espera forada ocorre se Q estiver bloqueado por outra transao em modo compartilhado.
Tanto quanto o protocolo de bloqueio em duas fases, o bloqueio em duas fases com converso de
bloqueio s gera escalas com serializao de conflito, e as transaes podem ser serializadas por seus pontos de
bloqueio. Alm disso, se bloqueios exclusivos so mantidos at o final da transao, as escalas so em cascata.
Descreveremos agora um esquema simples, mas muito usado, que gera as instrues de bloqueio e
desbloqueio, automaticamente, para uma transao. Quando uma transao Ti emite uma operao read(Q), o
sistema emite uma instruo lock-S(Q) seguida de uma instruo read(Q). Quando Ti emite uma operao
write(Q), o sistema verifica se Ti ainda mantm um bloqueio compartilhado. Se ainda h, o sistema emite uma
instruo upgrade(Q), seguida de uma instruo write(Q). De outro modo, o sistema emite uma instruo lockX(Q), seguida de uma instruo write(Q). Todos os bloqueios obtidos por uma transao so desbloqueados
depois da transao ser efetivada ou abortada.

Para um conjunto de transaes, pode haver escalas de serializao de conflito que no sejam obtidas por
meio do protocolo de bloqueio em duas fases. Entretanto, para obter escalas de serializao de conflito por meio
de protocolos de bloqueio sem usar duas fases, precisamos obter informaes adicionais sobre as transaes ou
impor alguma estrutura, ou ordem, sobre o conjunto de itens de dados dos banco de dados. Na ausncia de tais
informaes, o bloqueio em duas fases necessrio para a serializao de conflito se Ti uma transao que
no est em duas fases, sempre possvel encontrar outra transao Tj que esteja em duas fases, tal que haja
uma escala vivel para Ti e Tj que no seja conflitante por serializao.
O bloqueio em duas fases severo e o bloqueio em duas fases rigoroso (com converso de bloqueios) so
usados extensivamente em sistemas de banco de dados comerciais.
Protocolos com Base em Grficos (Graph-Based Protocols)
Como dissemos, na ausncia de informaes a respeito do modo de acesso aos itens de dados, o
protocolo de bloqueio em duas fases necessrio e suficiente para garantir a serializao. Assim, se desejamos
desenvolver protocolos que no usam duas fases, precisamos de informaes adicionais sobre como cada
transao desenvolver seu acesso ao banco de dados. H diversos modelos que diferem no tocante quantidade
de informaes a proporcionar. O modelo mais simples exige que tenhamos conhecimento anterior sobre a
ordem na qual os itens de banco de dados sero acessados. Fornecidas essas informaes, possvel construir
protocolos de bloqueio que no sejam em duas fases, mas que, no entanto, garantem a serializao de conflito.
Para adquirir esse conhecimento prvio, impomos uma ordenao parcial
sobre o conjunto
D={d1,d2,...,dn} de todos os itens de dados. Se di
dj, ento qualquer transao que mantenha acesso a ambos, di
284

e dj, dever acessar primeiro di e depois dj. Essa ordenao parcial pode resultar da organizao fsica ou lgica
dos dados, ou pode ser imposta somente para fins de controle de concorrncia.
A ordenao parcial implica que o conjunto D pode ser visto agora como um grfico acclico, chamado
grfico de banco de dados. Por maior simplicidade, restringiremos nossa ateno somente queles grficos que
so rvores razes. Apresentaremos um protocolo simples, chamado de protocolo de rvore, que restrito para
emprego somente nos bloqueios exclusivos.
No protocolo de rvore permitida somente a instruo de bloqueio lock-X. Cada transao Ti pode
bloquear um item de dado no mximo uma vez e deve observar as seguintes regras:
1. O primeiro bloqueio feito por Ti pode ser sobre qualquer dado.
2. Subsequentemente, um certo item de dado Q pode ser bloqueado por Ti somente se os pais de Q
estiverem bloqueados por Ti.
3. Itens de dados podem ser desbloqueados a qualquer momento.
4. Um item de dado que foi bloqueado e desbloqueado por Ti no pode ser rebloqueado por Ti
subsequentemente.
Como colocamos anteriormente, todas as escalas de execuo que forem legais sob o protocolo de rvore
que sero conflito serializadas.
Para ilustrar esse protocolo, considere o grfico do banco de dados da fig. 14.6. As quatro transaes
seguintes respeitam o protocolo de rvore desse grfico. Mostraremos somente as instrues de bloqueio e
desbloqueios:

Uma escala possvel em que participam essas quatro transaes a mostrada na fig. 14.7. Note que,
durante a execuo, a transao T10 mantm bloqueio sobre duas subrvores separadas.

Observe que a escala da fig. 14.7 conflito serializada. No apenas pode ser mostrado que o protocolo de
rvore garante a serializao de conflito, mas tambm que esse protocolo garante a ausncia de deadlock.
285

O protocolo de bloqueio em rvore apresenta a vantagem de realizar o desbloqueio mais cedo do que
feito no protocolo de bloqueio em duas fases. O desbloqueio feito mais cedo pode reduzir os tempos de espera e
aumentar a concorrncia. Alm disso, uma vez que o protocolo resistente a deadlocks, nenhum rollback
necessrio. Entretanto, o protocolo tem a desvantagem de, em alguns casos, uma transao pode manter o
bloqueio de um item de dado que no acessa. Por exemplo, uma transao que precise do acesso aos itens de
dados A e J cujo grfico do banco de dados o da fig. 14.6, precisa no somente bloquear A e J, mas tambm os
itens de dados B, D e H. Esse bloqueio adicional resulta no aumento de overhead relativo aos bloqueios, na
possibilidade de tempo de espera adicional e decrscimo potencial da concorrncia. Alm disso, sem o
conhecimento prvio de como os itens de dados sero bloqueados, as transaes tero de bloquear a raiz da
rvore, o que reduz consideravelmente a concorrncia.
Para um conjunto de transaes, h escalas conflitos serializadas que no podem ser obtidas pelo
protocolo de rvore. Ainda, h escalas possveis sob o protocolo de bloqueio em duas fases que tambm no so
possveis sob o protocolo de rvore, e vice-versa.
Protocolos com Base em Timestamp (Registro de Tempo)
Nos protocolos de bloqueio, descritos at agora, a ordem entre cada par de transaes conflitantes
determinada durante a execuo do primeiro bloqueio que ambas solicitam e que envolve modos incompatveis.
Outro mtodo para a determinao da ordem serializada selecionar uma ordenao entre transaes em
andamento. O mtodo mais usado o esquema de ordenao por timestamp.
Timestamp
A cada transao Ti dos sistema associamos um nico timestamp fixo, denotado por TS(Ti). Esse
timestamp criado pelo sistema de banco de dados antes que a transao Ti inicie sua execuo. Se uma
transao Ti recebeu o TS(Ti) em uma nova transao Tj entre no sistema, ento TS(Ti)<TS(Tj).
H duas formas simples de implementar esse esquema:
1. Usar a hora do relgio do sistema (clock) como timestamp, isto , o timestamp de uma transao igual
hora em que a transao entra no sistema.
2. Usar um contador lgico que incrementado sempre que se usa um novo timestamp, isto , o timestamp
da transao igual ao valor do contador no momento em que a transao entre no sistema.
Os timestamps das transaes determinam a ordem de serializao. Assim, se TS(Ti)<TS(Tj), o sistema
precisa garantir que a escala produzida seja equivalente a uma escala serial em que a transao Ti aparece antes
da transao Tj.
Para implementao desse esquema, associamos a cada item Q dois valores para timestamp:
W-timestamp(Q) denota o maior timestamp de qualquer transao que execute uma write(Q) com
sucesso.
R-timestamp(Q) denota o maior timestamp de qualquer transao que execute uma read(Q) com
sucesso.
Esses timestamps so atualizados sempre que uma nova instruo read(Q) ou write(Q) for executada.
O Protocolo de Ordenao por Timestamp
O protocolo de ordenao por timestamp assegura que quaisquer operaes de leitura e escrita sejam
executadas por ordem de timestamp. Esse protocolo opera da seguinte forma:
1. Suponha que a transao Ti emita uma read(Q).
a. Se TS(Ti)<W-timestamp(Q), ento Ti precisa ler um valor de Q que j foi sobreposto. Assim, a
operao read rejeitada e Ti desfeita.
b. Se TS(Ti)W-timestamp(Q), ento a operao read executada e R-timestamp(Q) recebe o maior
valor entre R-timestamp(Q) e TS(Ti).
2. Suponha que a transao Ti emita um write(Q).
286

a. Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti est produzindo foi necessrio antes e o

sistema assumiu que aquele valor nunca seria produzido. Logo, a operao write rejeitada e Ti
desfeita.
b. Se TS(Ti)<W-timestamp(Q), ento Ti est tentando escrever um valor obsoleto em Q. Logo, essa
operao write rejeitada e Ti desfeita.
c. De outro modo, a operao write executada e W-timestamp(Q) registrado em TS(Ti).
Uma transao Ti que foi desfeita pelo esquema de controle de concorrncia, decorrente de uma
operao read ou write, recebe um novo timestamp e reiniciada.
Para ilustrar esse protocolo, considere as transaes T14 e T15. A transao T14 mostra o contedo total das
contas A e B e definida como:

A transao T15 transfere 50 dlares da conta A para a conta B e ento apresenta o resultado de ambas:

Nas escalas criadas obedecendo ao protocolo de timestamp, assumimos que uma transao recebe um
timestamp imediatamente antes de sua primeira instruo. Assim, na escala 3 da fig. 14.8, TS(T14)<TS(T15) e a
escala possvel sob o protocolo de timestamp.
Notamos que a execuo precedente pode tambm ser realizada pelo protocolo de bloqueio em duas
fases. H, entretanto, escalas que so viveis sob o protocolo de bloqueio em duas fases, mas inviveis sob o
protocolo de timestamp, e vice-versa.

O protocolo de ordenao por timestamp garante a serializao de conflito. Essa assero provm do fato
de que operaes conflitantes so processadas pela ordem do timestamp. O protocolo garante tambm
resistncia a deadlocks, j que uma transao nunca espera. O protocolo consegue gerar escalas que no podem
ser recuperadas (desfeitas), entretanto ele pode receber uma extenso para fazer escalas cascateadas.
Regra de Escrita de Thomas (Thomas Write Rule)
Apresentaremos agora uma modificao no protocolo de ordenao por timestamp que aumenta a
concorrncia em potencial em relao quele que descrevemos anteriormente. Consideremos a escala 4 da fig.
14.9 e apliquemos a ela o protocolo da ordenao por timestamp. Uma vez que T16 comea antes de T17, podemos
considerar que TS(T16)<TS(T17). A operao read(Q) de T16 executada, assim como a operao write(Q) de T17.
Quando T16 tenta executar sua operao write(Q), descobrimos que TS(T16)<W-timestamp(Q), j que Wtimestamp(Q) = TS(T17). Assim, a operao write(Q) de T16 rejeitada e a transao T16 precisa ser desfeita.

287

Embora o rollback de T16 seja requerido pelo protocolo da ordenao por timestamp, ele desnecessrio.
Uma vez que T17 j escreveu Q, o valor que T16 est tentando escrever nunca ser lido. Qualquer transao Ti com
TS(Ti)<TS(T17) dever ler o valor de Q que foi escrito por T17 em vez de o valor escrito por T16.
Essa observao sugere uma modificao no protocolo de ordenao por timestamp no qual operaes
write obsoletas podem ser ignoradas sob determinadas circunstncias. As regras de protocolo para as operaes
read permanecem inalteradas. As regras de protocolo para as operaes write, entretanto, so ligeiramente
diferentes das do protocolo de ordenao por timestamp vista anteriormente:
1. Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti est produzindo foi necessrio anteriormente, e
assumiu-se que o valor nunca seria produzido. Logo, a operao write rejeitada e Ti desfeita.
2. Se TS(Ti)<W-timestamp(Q), ento Ti est tentando escrever um valor obsoleto para Q. Logo, a operao
write pode ser ignorada.
3. De outro modo, a operao write executada e W-timestamp(Q) recebe o valor de TS(Ti).
A diferena entre essas regras e as apresentadas anteriormente est na segunda regra. O protocolo de
ordenao por timestamp exige que Ti seja desfeita se emitir uma write(Q) e TS(Ti)<W-timestamp(Q). Entretanto,
aqui, nos casos em que TS(Ti)W-timestamp(Q). Entretanto, aqui, nos casos em que TS(Ti)R-timestamp(Q),
ignoramos writes obsoletas. Essa modificao no protocolo de ordenao por timestamp chamada de regra de
escrita de Thomas.
A regra de escrita de Thomas faz uso da serializao de viso, eliminando, com efeito, as operaes de
write obsoletas das transaes que as emitem. Essa modificao torna possvel a gerao de escalas de execuo
serializadas que no poderiam ocorrer sob outros protocolos apresentados aqui. Por exemplo, a escala 4 da fig.
14.9 no-conflito serializada e, assim, no vivel sob qualquer protocolo de bloqueio em duas fases, protocolo
de rvore ou de ordenao por timestamp. Sob a regra escrita de Thomas, a operao write(Q) da T16 poderia ser
ignorada. O resultado uma escala cuja viso equivalente escala serial <T16, T17>.
Protocolos com Base em Validao
Nos casos em que a maioria das transaes somente de leitura, a taxa de conflitos entre as transaes
pode ser baixa. Assim, algumas dessas transaes, se executadas sem a superviso de um esquema de controle
de concorrncia, poderiam deixar o sistema sempre em estado consistente. Um esquema de controle de
concorrncia impe overhead relativo execuo de mais cdigo e possvel atraso nas transaes. Pode ser
interessante usar um esquema alternativo que resulte em menor overhead. Uma dificuldade enfrentada para a
reduo de overhead que no sabemos a priori quais transaes sero envolvidas em conflito. Para obter essa
informao, precisamos de um esquema para a monitorao do sistema.
Consideramos que cada transao Ti executada em duas ou trs fases diferentes, dependendo se uma
transao somente de leitura ou de atualizao. Essas fases so, em ordem, as seguintes:
1. Fase de leitura. Durante essa fase, a execuo da transao Ti tem incio. Os valores de diversos itens de
dados so lidos e armazenados em variveis locais para Ti. Todas as operaes de escrita so processadas
com variveis locais temporrias, sem alterar de fato o banco de dados.
2. Fase de validao. A transao Ti processa um teste de validao para determinar se pode copiar no
banco de dados as variveis locais temporrias que mantm os resultados das operaes de escrita sem,
com isso, causar a violao da serializao.
3. Fase de escrita. Se a transao Ti obtm sucesso na validao (passo 2), ento a atualizao aplicada de
fato ao banco de dados. Caso contrrio, Ti desfeita.
Cada transao precisa passar pelas trs fases, na ordem mostrada. Entretanto, as trs fases de
transaes em execuo concorrentes podem ser intercaladas.
288

As fases de leitura e escrita so autoexplicativas. A nica fase que exige mais explicaes a de validao.
Para realizar os testes de validao, precisamos saber quando ocorreram as diversas fases da transao Ti.
Precisamos, portanto, associar trs timestamps diferentes para a transao Ti:
1. Start(Ti), o momento em que Ti teve incio.
2. Validation(Ti), o momento em que Ti terminou sua fase de leitura e comeou sua fase de validao.
3. Finish(Ti), o momento em que Ti terminou sua fase de escrita.
Determinamos a ordem de serializao pela tcnica de ordenao por timestamp, usando o valor do
timestamp da Validation(Ti). Assim, o valor de TS(Ti)=Validation(Ti) e, se TS(Tj)<TS(Tk), ento qualquer escala criada
precisa ser equivalente escala serializada na qual a transao Tj aparece antes da transao Tk. A razo para
escolhermos Validation(Ti) em vez de Start(Ti) como timestamp da transao Ti que, com isso, podemos esperar
menor tempo de resposta, com a condio de que as taxas de conflito entre transaes sejam com certeza
pequenas.
O teste de validao para Ti exige que, para todas as transaes Ti com TS(Ti)<TS(Tj), uma das duas
condies a seguir seja realizada:
1. Finish(Ti)<Start(Ti). J que Ti completa sua execuo antes de Tj comear, a ordem de serializao com
certeza mantida.
2. No h interseo entre o conjunto de itens de dados escritos por Ti e o conjunto de dados lidos por Tj, e
Ti completa sua fase de escrita antes de Tj comear sua fase de validao
(Start(Tj)<Finish(Ti)<Validation(Tj)). Essa condio garante que as escritas de Ti e Tj no sejam sobrepostas.
Uma vez que a escrita de Ti no afeta a leitura de Tj e que Tj no pode afetar a leitura de Ti, a ordem de
serializao com certeza mantida.
Como ilustrao, considere novamente as transaes T14 e T15. Suponha que TS(T14)<TS(T15). Ento, a fase de
validao consegue produzir a escala de execuo 5, que apresentada na fig. 14.10. Note que a escrita das
variveis reais realizada somente aps a fase de validao de T15. Assim, T14 l valores desatualizados de A e B e
essa serializada.

O esquema de validao evita, automaticamente, os rollbacks em cascata, j que as escritas reais

acontecem somente depois que a transao que emitiu a solicitao de escrita tenha sido efetivada.
Granularidade Mltipla
Nos esquemas de concorrncia descritos at agora, estivemos usando cada item de dado individual como
uma unidade qual a sincronizao aplicada.
H circunstncias, no entanto, em que pode ser vantajoso o agrupamento de diversos itens de dados,
tratando-os como uma unidade de sincronizao individual. Por exemplo, se uma transao Ti precisa do acesso a
todo o banco de dados e um protocolo de bloqueio usado, Ti precisar bloquear cada um dos itens do banco de
dados. Logicamente, esse bloqueio um consumidor de tempo. Seria melhor Ti emitir uma nica solicitao de
bloqueio a todo o banco de dados. Por outro lado, se uma transao Tj precisa do acesso a somente alguns itens
de dados, no necessrio bloquear todo o banco de dados, porque, desse modo, a concorrncia perdida.
preciso um mecanismo que permita ao sistema definir diferentes mltiplos de granulao. Podemos
desenvolver um desses mecanismos permitindo diversos tamanhos aos itens de dados e definindo uma hierarquia
289

de granularidade de dados, em que as granulaes menores sejam aninhadas s maiores. Tal hierarquia pode ser
representada graficamente como uma rvore. Note que a rvore que descrevemos aqui bastante diferente da
usada no protocolo de rvore. O n sem ramificaes de uma rvore de granularidade mltipla representa o dado
associado a seus descendentes. No protocolo de rvore, cada n representa um item de dado independente.
Como ilustrao, considere a rvore da fig. 14.11, consistindo em ns em quatro nveis. O nvel mais alto
representa o banco de dados como um todo. Abaixo, h ns do tipo rea; o banco de dados constitudo
exatamente dessas reas. Cada rea, por sua vez, possui ns do tipo arquivo como filhos. Cada rea constituda
exatamente daqueles arquivos que so seus ns filhos. Nenhum arquivo est em mais de uma rea. Finalmente,
cada arquivo possui ns do tipo registro. Como antes, o arquivo constitudo exatamente daqueles registros que
so seus ns filhos, e nenhum registro pode estar em mais de um arquivo.

Cada n de uma rvore pode ter bloqueio individual. Como foi feito no protocolo de bloqueio em duas
fases, usaremos os modos de bloqueio exclusivo e compartilhado. Quando uma transao bloqueia um n, tanto
no modo compartilhado quanto no exclusivo, a transao tambm bloquear todos os descendentes daquele n
no mesmo modo de bloqueio. Por exemplo, se a transao Ti bloqueio de forma explcita o arquivo Fc da fig.
14.11, no modo exclusivo, ento ela est bloqueando de forma implcita, no modo exclusivo, todos os registros
pertencentes quele arquivo. Ela no precisar fazer, de forma explcita, o bloqueio individual dos registros de Fc.
Suponha que uma transao Tj queira bloquear o registro rb6 do arquivo Fb. Dado que Ti bloqueou Fb de
forma explcita, segue que rb6 est tambm bloqueado (de forma implcita). Mas, quando Tj emite uma solicitao
de bloqueio para rb6, este no bloqueado de modo explcito! Como o sistema determinar se Tj pode bloquear rb6?
Tj precisar percorrer a rvore da raiz at o registro rb6. Se algum modo n do caminho estiver bloqueado de
modo incompatvel, ento Tj precisar esperar.
Suponha, agora, que a transao Tk deseja bloquear todo o banco de dados. Para isso, ela precisa
simplesmente bloquear a raiz hierrquica. Note, entretanto, que Tk no deve conseguir o bloqueio no n raiz, j
que Ti j est bloqueado, como acontece com parte da rvore (especificamente, o arquivo Fb). Mas, agora, como o
sistema determinar se o n raiz poder ser bloqueado? Uma soluo seria pesquisar a rvore inteira. Essa
soluo, entretanto, se antepe ao proposito do esquema do bloqueio de granularidade mltipla. Um meio mais
eficiente seria introduzir uma nova classe de modo de bloqueio, chamado modo de bloqueio intencional. Se um
n bloqueado no modo intencional, o bloqueio explcito ser feito no nvel mais baixo da rvore (isto , na
granularidade mais fina). Bloqueios intencionais sero feitos em todos os antecessores do n antes que aquele n
seja bloqueado de forma explcita. Assim, uma transao no precisa pesquisar a rvore inteira para determinar
se poder bloquear um n. Uma transao que queira bloquear um n digamos, Q precisa percorrer o
caminho, pela rvore, do n at Q. Enquanto se percorre a rvore, os bloqueios das transaes so feitos de
modo intencional.
H um modo intencional associado ao modo compartilhado e um relacionado ao modo exclusivo. Se um
n bloqueado no modo compartilhado-intencional (intention-shared IS), o bloqueio explcito est sendo feito
no nvel mais baixo da rvore, mas com somente bloqueios de modo compartilhado.
Analogamente, se um n bloqueado no modo exclusivo-intencional (intention-exclusive IX), ento o
bloqueio explcito est sendo feito no nvel mais baixo, no modo exclusivo ou compartilhado. Finalmente, se um
n est bloqueado nos modos de bloqueio apresentada na fig. 14.12.
290

O protocolo de bloqueio de granularidade mltipla garante a serializao. Cada transao Ti pode

bloquear um n Q, usando as seguintes regras:
1. A funo de compatibilidade de bloqueio da fig. 14.12 precisa ser observada.
2. A raiz da rvore precisa ser bloqueada primeiro e pode ser bloqueada em qualquer modo.
3. Um n Q pode ser bloqueado por Ti no modo S ou IS somente se o pai de Q for bloqueado por Ti no modo
IX ou IS.
4. Um n Que pode ser bloqueado por Ti no modo X, SIX ou IX somente se o pai de Q estiver bloqueado por
Ti no modo IX ou no modo SIX.
5. Ti pode bloquear um n somente se ele no desbloqueou outro n anteriormente (isto , Ti tem duas
fases).
6. Ti pode desbloquear um n Que somente se nenhum dos filhos de Que estiver bloqueado por Ti.
Observe que o protocolo de granularidade mltipla exige que os bloqueios sejam feitos de cima para
baixo (top-down da raiz para as folhas), enquanto a liberao deve ser de baixo para cima (bottom-up das
folhas para a raiz).
Para ilustrar o protocolo, considere a rvore da fig. 14.11 e as seguintes transaes:
Suponha que a transao T18 leia o registro ra2 do arquivo Fa. Ento, T18 precisa bloquear o banco de
dados, a rea A1, o arquivo Fa no modo IS (nessa ordem) e, finalmente, bloquear ra2 no modo S.
Suponha que a transao T19 altere o registro ra9 do arquivo Fa. Ento, T19 precisa bloquear o banco de
dados, a rea A1, o arquivo Fa no modo IX e, finalmente, bloquear ra9 no modo X.
Suponha que a transao T20 leia todos os registros do arquivos Fa. Ento, T20 precisa bloquear o banco de
dados e a rea A1 (nesse ordem) no modo IS e, finalmente, bloquear Fa no modo S.
Suponha que a transao T21 leia todo o banco de dados. Ento, poder faz-lo depois de bloquear o
banco de dados no modo S.
Podemos notar que as transaes T18, T20, e T21 mantm acesso ao banco de dados concorrentemente. A
transao T19 pode concorrer com T18, mas no com T20 nem T21.
Esse protocolo aumenta a concorrncia e reduz o overhead por bloqueio. Isso particularmente til em
aplicaes que misturam:
Transaes curtas que mantm acesso em poucos itens de dados.
Transaes longas que produzem relatrios a partir de um arquivo ou de um conjunto de arquivos.
H protocolos de bloqueio similares que so aplicados a sistemas de banco de dados nos quais a
granularidade organizada na forma de grficos acclicos.
Esquemas de Multiverso
Os esquemas de controle de concorrncia discutidos at aqui garantem a serializao atrasando a
operao ou abortando a transao responsvel por tal operao. Por exemplo, uma operao de read pode ser
retratada se o valor apropriado em questo ainda estiver sendo escrito; ou pode ser rejeitada se o valor
apropriado em questo ainda estiver sendo escrito; ou pode ser rejeitada (isto , a transao que emitiu tal
solicitao deve ser abortada) porque o valor lido j foi alterado. Essas dificuldades podem ser evitadas se o
sistema providenciar cpias anteriores de cada item de dado.
Em um sistema de banco de dados multiverso, cada operao write(Q) cria uma nova verso de Q.
Quando emitida uma operao read(Q), o sistema seleciona uma das verses de Q para ser lida seja tal que
291

assegure a serializao. crucial, por razes de desempenho, que uma transao possa determinar fcil e
rapidamente qual verso do item de dados poder ser lido.
Multiverso com Ordenao por Timestamp
A tcnica mais usada nos esquemas de multiverso o timestamp. A cada transao Ti do sistema
associado um timestamp nico e esttico, denotado por TS(Ti). Esse timestamp associado antes do incio da
execuo da transao, conforme j descrito.
Para cada idem de dado Q, uma sequncia de verses < Q1, Q2, ..., Qm> associada. Cada verso Qk
contm trs campos de dados:
Content (contedo) o valor da verso Qk.
W-timestamp(Qk) o timestamp da transao que criou a verso Qk.
R-timestamp(Qk) o timestamp mais alto de alguma transao que tenha lido a verso Qk com sucesso.
Uma transao digamos, Ti cria uma nova verso Qk do item de dado Q emitindo uma operao
write(Q). O campo contedo da verso mantm o valor escrito por Ti. O W-timestamp e o R-timestamp so
inicializados por TS(Ti). O valor de R-timestamp atualizado sempre que uma transao Tj l o contedo de Qk e
R-timestamp atualizado sempre que uma transao Tj l o contedo de Qk e R-timestamp(Qk)<TS(Tj).
O esquema de multiverso com timestamp apresentado a seguir garante a serializao. O esquema opera
da forma descrita a seguir. Suponha que uma transao Ti emita uma operao read(Q) ou write(Q). Seja Qk a
verso de Q cujo timestamp de escrita o mais alto timestamp, menor ou igual a TS(Ti).
1. Se a transao Ti emitir uma read(Q), ento o valor recebido ser o contedo da verso Qk.
2. Se a transao Ti emitir um write(Q) e TS(Ti)<R-timestamp(Qk), o contedo de Qk sobreposto; caso
contrrio, outra verso de Q criada.
A justificativa para a regra 1 clara. Uma transao l a verso mais recente anterior a ela. A segunda
regra fora o aborto de uma transao se for tarde demais para que se faa uma escrita. Mais precisamente, se
Ti tentar escrever uma verso que alguma outra transao j tenha lido, ento no poderemos permitir que essa
escrita seja bem-sucedido.
As verses que no forem mais necessrias sero removidas conforme a regra seguinte. Suponha que
haja duas verses, QK e Qj, de um item de dados e que ambas as verses tenha o W-timestamp menor que o
timestamp da ltima transao do sistema. Ento, a mais antiga entre as verses QK e Qj no ser usada
novamente e pode ser eliminada.
O esquema multiverso ordenada por timestamp possui a adequada propriedade de garantir que uma
solicitao de leitura nunca falhe e nunca espere. Em um sistema de banco de dados tpico, em que as operaes
de leitura so mais frequentes que as de escrita, essa vantagem de grande importncia prtica.
O esquema, entretanto, possui duas propriedades indesejveis. Primeiro, a leitura de um item de dados
exige tambm a atualizao do campo R-timestamp, resultando em dois acessos ao disco, em vez de apenas um.
Segundo, os conflitos entre transaes so resolvidos por rollback, em vez da imposio de tempo de espera. Essa
alternativa pode ser onerosa. Um algoritmo para amenizar o problema ser descrito na prxima seo.
Multiverso com Bloqueio em Duas Fases
O protocolo de multiverso com bloqueio em duas fases tenta combinar as vantagens do controle de
concorrncia multiverso com as vantagens do bloqueio em duas fases. Esse protocolo diferencia transaes
somente de leitura das transaes de atualizao. As transaes de atualizao executam um bloqueio em duas
fases rigorosas, isto , elas mantm todos os bloqueios at o final da transao. Assim, podem ser serializadas de
acordo com sua ordem de efetivao. Cada item de dado possui um nico timestamp. O timestamp no , nesse
caso, baseado no horrio, mas em um contador, que ser chamado de ts_counter, que incrementado durante o
processo de efetivao.

292

Marcamos o timestamp das transaes somente de leitura por meio do valor corrente do contador, ou
seja, lendo o valor de ts_counter antes de comear sua execuo; para a leitura, elas seguem o protocolo de
multiverso ordenada por timestamp. Com isso, quando uma transao Ti desse tipo emite uma read(Q), o valor
recebido o contedo da verso cujo timestamp o inferior a TS(Ti) mais prximo.
Quando uma transao de atualizao l um item, ela impe um bloqueio compartilhado ao item e l a
ltima verso do item. Quando uma transao de atualizao deseja escrever um item, ela primeiro consegue o
bloqueio exclusivo desse item e, ento, cria uma nova verso do item de dados. A escrita realizada a partir da
nova verso e o timestamp da nova verso recebe como valor inicial, que maior que qualquer outro
timestamp possvel.
Quando uma transao de atualizao Ti completa suas aes, ela realiza o processo de efetivao da
seguinte forma: primeiro, Ti adiciona 1 ao valor de ts_counter e transfere esse valor aos timestamp de todas as
verses que criou; ento, Ti adiciona 1 ao ts_counter. Somente uma transao de atualizao por vez pode
realizar o processo de efetivao.
Como consequncia, as transaes somente de leitura que comearem depois de Ti incrementar o
ts_counter acessaro o valor atualizado por Ti, enquanto aquelas que comearem antes do incremento de
ts_counter, feito por Ti, vero o valor anterior atualizao de Ti. Nesse caso, as transaes somente de leitura
jamais precisaro esperar por bloqueios.
As verses so eliminadas de modo similar multiverso com ordenao por timestamp. Suponha que
haja duas verses, QK e Qj, de um item de dado e que ambas as verses tenham timestamp menor que o da
ltima transao somente de leitura processada no sistema. Logo, a mais antiga entre as duas verses QK e Qj
no ser mais usada e pode ser eliminada.
A multiverso com bloqueio em duas fases ou variaes so aplicadas a alguns sistemas de banco de
dados comerciais.
Manuseio do Deadlock
Um sistema est em estado de deadlock se h um conjunto de transaes, tal que toda a transao desse
conjunto est esperando outra transao tambm nele contida. Mais precisamente, h um conjunto de
transaes esperando {T0,T1,...,Tn}, tal que T0 est esperando um item de dado mantido por T1, T1 est esperando
um item de dado mantido por T2, ..., Tn-1 est esperando um item de dados mantido por Tn e Tn est esperando
por um item de dado mantido por T0. Nenhuma dessas transaes poder prosseguir em uma situao dessas. O
nico remdio para essa situao indesejvel uma ao drstica do sistema, como reverter uma das transaes
envolvidas no deadlock.
H dois mtodos principais para o tratamento do deadlock. Podemos usar o protocolo de preveno de
deadlock para garantir que o sistema nunca entrar em tal situao. Ou podemos permitir que o sistema entre
em estado de deadlock e, ento, remov-lo dessa situao, recuperando-o por meio dos esquemas de deteco
de deadlock e recuperao de deadlock. Como vimos, ambos os mtodos podem acabar por reverter uma
transao (rollback). A preveno mais utilizada se a probabilidade do sistema que entrar deadlock for
relativamente alta; caso contrrio, a deteco e recuperao so mais eficientes.
Note que os esquemas de deteco e recuperao implicam overhead relativo, no somente ao tempo de
processamento do sistema para manuteno das informaes necessrias e para a execuo do algoritmo de
deteco, mas tambm devido s perdas potenciais inerentes advindas da recuperao de um deadlock.
Preveno de Deadlock
H duas abordagens para a preveno de deadlock. Uma garante que nenhum ciclo de espera poder
ocorrer pela ordenao de solicitaes de bloqueios, ou obrigando que todos os bloqueios sejam obtidos juntos.
Outra aproxima-se da recuperao do deadlock, fazendo com que a transao seja refeita, em vez de esperar um
bloqueio, sempre que a espera possa potencialmente ocorrer um deadlock.

293

O esquema mais simples sob a primeira abordagem obriga cada transao a bloquear todos os itens de
dados antes de sua execuo. Alm disso, ou todos so bloqueados de uma vez ou nenhum o ser. H duas
desvantagens nesse protocolo. A premiria, normalmente, a dificuldade em prever, antes da transao comear,
quais itens de dados precisaro de bloqueio. Segundo, a utilizao do item de dados pode ser bastante reduzida,
j que muitos dos itens de dados podem ser bloqueados e no ser usados pro um longo perodo.
Outro esquema de preveno de deadlock feito pela imposio de ordenao parcial de todos os itens
de dados e pela obrigao de que a transao bloqueie um item de dado somente na ordem especificada na
ordenao parcial. Vimos um desses esquemas no protocolo de rvore.
A segunda abordagem para a preveno de deadlock a preempo e o rollback de transaes. Na
preempo, quando uma transao T2 solicita um bloqueio que est sendo mantido pela transao T1, o bloqueio
concedido a T1 pode ser revisto por meio do rollback de T1, e concedido a T2. Para controle da preempo,
consideramos um nico timestamp para cada transao. O sistema usa esses timestamps somente para decidir se
a transao pode esperar ou ser revertida. O bloqueio ainda usado para controle de concorrncia. Se uma
transao for revertida, ela manter seu timestamp antigo quando for reiniciada. So propostos dois esquemas
diferentes de preveno de deadlock usando timestamp:
1. O esquema esperar-morrer (wait-die) tem por base uma tcnica de no-preempo. Quando uma
transao Ti solicita um item de dado mantido por Tj, Ti pode esperar somente se possuir um timestamp
menor que o de Tj (isto , Ti mais antiga que Tj). Caso contrrio, Ti ser revertida (morta). Por exemplo,
suponha que as transaes T22, T23 e T24 tenham timestamps 5, 10 e 15, respectivamente. Se T24 solicita
um item de dado mantido por T23, ento T24 ser desfeita. Se T24 solicitar um item de dado mantido por
T23, ento T24 esperar.
Sempre que as transaes forem revertidas, importante garantir que no haja inanio (starvation)
isto , que nenhuma transao seja desfeita continuamente e jamais possa continuar seu processamento.
Ambos os esquemas, esperar-morrer e ferir-esperar, evitam a inanio: qualquer que seja o momento,
possvel encontrar a transao com menor timestamp. Essa transao no ser revertida em nenhum dos
esquemas. Uma vez que os timestamps sempre crescem, e dado que as transaes no recebem dois novos
timestamps se foram revertidas, a transao revertida, em determinado momento, ter o menor timestamp.
Assim, ela no ser revertida novamente.
H entretanto, diferenas significativas entre as formas dos dois esquemas operar.
No esquema esperar-morrer, a transao mais antiga precisar esperar at que a mais nova libere seus
itens dados. Assim, quanto mais antiga a transao, maior a possibilidade de esperar. Em contraste, no
esquema ferir-esperar, a transao mais antiga nunca espera a mais nova.
No esquema esperar-morrer, se uma transao Ti morre e desfeita porque solicitou um item de dado
preso por uma transao Tj, ento Ti pode reemitir a mesma sequncia de solicitaes quando for
reiniciada. Se os itens de dados ainda estiverem presos por Tj, ento Ti morrer novamente. Assim, Ti
poder morrer diversas vezes antes de conseguir o item de dados necessrio. Compare essa srie de
eventos com o que acontece no esquema ferir-esperar. A transao Ti ser ferida e revertida porque Tj
solicitou um item de dados preso por ela. Quando Ti reinicia e solicita o item de dado preso por Tj, Ti
esperar. Com isso, deve haver menos reverses do esquema ferir-esperar.
O maior problema com ambos os esquemas que podem ocorrer rollbacks desnecessrios.
Esquemas com Base em Tempo Esgotado (Timeout)
Outro enfoque simples para o tratamento de deadlocks tem por base o tempo esgotado para o bloqueio
(lock timeouts). Dessa forma, uma transao que tenha solicitado um bloqueio espera por ele determinado
perodo de tempo. Se o bloqueio no for conseguido dentro desse intervalo, dito que o tempo da transao est
esgotado, assim ela mesma se reverte e se reinicia. Se de fato estiver ocorrendo um deadlock, uma ou mais
transaes nele envolvidas tero seu tempo esgotado e se revertem, permitindo a continuao de outras. Esse
294

esquema pode ser considerado alguma coisa entre preveno de deadlock, dado que o deadlock nunca ocorre, e
deteco e recuperao, j discutidas.
O esquema de tempo esgotado particularmente fcil de ser implementado, trabalha bem se as
transaes forem curtas e longas esperas so frequentemente em funo dos deadlocks. Entretanto, em geral
difcil decidir por quanto tempo a transao deve esperar. Esperas muito longas implicam atrasos desnecessrios,
dado que esteja ocorrendo um deadlock. Esperas muito curtas resultam em transaes sendo revertidas mesmo
sem deadlock, desperdiando recursos. A inanio tambm possvel nesse esquema. Ento ocorre a aplicao
limitada do esquema com base em tempo esgotado.
Deteco de Deadlock e Recuperao
Se um sistema no usa um protocolo resistente ao deadlock, ou seja, que garanta que deadlocks no
aconteam, ento um esquema para deteco e recuperao precisa ser aplicado. Um algoritmo que examina o
estado do sistema evocado periodicamente para determinar se um deadlock est ocorrendo. Se estiver, ento o
sistema precisa tentar recuperar-se. Para isso, ele precisa:
Manter informaes sobre a alocao corrente dos itens de dados para transaes, assim como qualquer
solicitao de itens de dados pendente.
Proporcionar um algoritmo que use essas informaes para determinar se o sistema entrou em estado de
deadlock.
Recuperar-se de um deadlock quando o algoritmo de deteco determinar que ele ocorreu.
Deteco de Deadlock
Os deadlocks podem ser precisamente descritos em, termos de um grfico chamado grfico de espera.
Esse grfico consiste em um par G=(V,E), em que V um conjunto de vrtices e E, um conjunto de arestas. O
conjunto de vrtices consiste em todas as transaes do sistema. Cada elemento do conjunto E de arestas um
par ordenado Ti
Tj. Se Ti
Tj est em E, ento o sentido da aresta, da transao Ti para Tj, implica que a
transao Ti est esperando que a transao Tj libere o item de dado de que ela precisa.
Quando a transao Ti solicita um item de dado que est preso pela transao Tj, ento a aresta Ti
Tj
inserida no grfico de espera. Essa aresta removida somente quando a transao Tj no estiver mais esperando
um item de dado necessrio transao Ti.
H um deadlock no sistema se, e somente se, o grfico de espera contiver um ciclo. Cada transao
envolvida em um ciclo est em deadlock. Para detectar deadlocks, o sistema precisa manter o grfico de espera e,
periodicamente, evocar um algoritmo que verifique a existncia de ciclos.
Para ilustrar esses conceitos, considere o grfico de espera da fig. 14.13, que exibe a seguinte situao:
A transao T25 est esperando as transaes T26 e T27.
A transao T27 est esperando a transao T26.
A transao T26 est esperando a transao T28.

Uma vez que no h ciclos, o sistema no est em estado de deadlock.

Suponha agora que a transao T28 esteja solicitando um item preso por T27. A aresta T28
T27 ser
adicionada ao grfico de espera, alterando o estado do sistema, como mostrado na fig. 14.14. A essa altura, o
grfico contm o ciclo:
implicando que as transaes T26, T27 e T28 esto todas em deadlock.
295

Consequentemente, impe-se a questo: quando evocaremos o algoritmo de deteco ser evocado com
mais frequncia que o usual. Os itens de dados alocados nas transaes em deadlock no estaro disponveis para
outras transaes at que o deadlock seja resolvido. Alm disso, o nmero de ciclos no grfico pode crescer
tambm. Na pior das hipteses, evocaramos o algoritmo de deteco sempre que uma solicitao de alocao
no puder ser atendida imediatamente.
Recuperao aps um Deadlock
Quando um algoritmo de deteco determina a existncia de um deadlock, o sistema precisa recuperarse desse deadlock. A soluo mais comum reverter uma ou mais transao para quebrar o deadlock. Devem ser
tomadas trs aes:
1. Selecionar uma vtima. Dado um conjunto de transaes em deadlock, precisamos determinar quais
transaes (ou transao) sero desfeitas para quebrar o deadlock. Poderamos reverter as transaes
que representam o menor custo. Infelizmente, o termo mnimo custo no preciso. Muitos fatores
podem determinar o custo de um rollback, incluindo:
a. A quanto tempo a transao est em processamento e quanto tempo ser ainda necessrio para
que a tarefa seja completada.
b. Quantos itens de dados a transao usou.
c. Quantos itens ainda a transao usar at que se complete.
d. Quantas transaes sero envolvidas no rollback.
2. Rollback. Uma vez decidido que uma transao em particular ser revertida, precisamos determinar at
que ponto ela dever ser revertida. A soluo mais simples revert-la totalmente: abort-la para depois
reinici-la. Entretanto, mais eficaz reverter a transao somente o suficiente para a quebra do deadlock.
Mas esse mtodo exige que o sistema mantenha informaes adicionais sobre o estado de todas as
transaes em execuo.
3. Inanio. Em um sistema no qual a seleo de vtimas tem por base fatores de custo, pode acontecer de
uma mesma transao ser sempre escolhida vtima. Assim, essa transao nunca se completa. Essa
situao chamada de inanio. Precisamos garantir que uma transao seja escolhida vtima somente
um nmero finito (pequeno) de vezes. A soluo mais comum incluir o nmero de reverso no fator de
custos.
Operaes de Insero e Remoo
At agora restringimos nossa ateno a operaes read e write. Essas restries limita a ao das
transaes sobre os itens de dados existentes no banco de dados. Algumas transaes precisam no somente de
acesso a itens de dados existentes, mas tambm da capacidade de criar novos itens de dados. Outras precisam
remover itens de dados. Para examinar como tais transaes afetam o controle de concorrncia, introduzimos as
seguintes operaes adicionais:
delete(Q) remove o item de dados Q do banco de dados.
insert(Q) insere um novo item de dados Q em um banco de dados e designa um valor inicial para ele.
Uma transao Ti que queira operar uma read(Q) depois da remoo de Q resulta em erro lgico em Ti.
Analogamente, se uma transao Ti quiser realizar uma operao de read(Q) antes da insero de Q, tambm
haver erro lgico em Ti. Tambm ser um erro lgico tentar remover um item de dados inexistente.
296

Remoo
Para entender como uma instruo de remoo (delete) afeta o controle de concorrncia, precisamos
definir quando ela entra em conflito com outra instruo. Seja Ii e Ij instrues de Ti e Tj, respectivamente, que
aparecem nessa ordem na escala de execuo S. Seja Ii= delete(Q). Consideremos as seguintes instrues Ij.
Ij = read(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou
antes de Ii, Tj poder executar a operao read com sucesso.
Ij = write(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou
antes de Ii, Tj poder executar a operao write com sucesso.
Ij = delete(Q). Ii e Ij entram em conflito. Se Ii comeou antes de Ij, Tj incorrer em erro lgico. Se Ij comeou
antes de Ii, Ti incorrer em erro lgico.
Ij = insert(Q). Ii e Ij entram em conflito. Suponha que o item de dado Q no exista antes da execuo de Ii e
Ij. Ento, se Ii comeou antes de Ij, ocorrer erro lgico em Ti. Se Ij comeou antes de Ii no ocorrer
nenhum erro lgico. Da mesma forma, se Q existir antes da execuo de Ii e Ij, poder ocorrer erro lgico
se Ij comeou antes de Ii, caso contrrio no.
Podemos concluir que, se o bloqueio em duas fases for usado, preciso um bloqueio exclusivo sobre o
item de dados antes que ele possa ser removido. Sob o protocolo de ordenao por timestamp, um teste que ele
possa ser removido. Sob o protocolo de ordenao por timestamp, um teste similar ao indicado para a write
precisar ser realizado. Suponha que a transao Ti emita um delete(Q).
Se TS(Ti)<R-timestamp(Q), ento o valor de Q que Ti removeu j havia sido lido pela transao Tj com
TS(Tj)>TS(Ti). Ento, a operao delete ser rejeitada e Ti ser revertida.
Se TS(Ti)<W-timestamp(Q), ento uma transao Tj com TS(Ti)>TS(Tj) j gravou Q. Com isso, essa operao
delete ser rejeitada e Ti ser desfeita.
De outro modo a operao delete ser executada.
Insero
Vimos que uma operao insert(Q) entra em conflito com uma operao delete(Q). Analogamente,
insert(Q) entra em conflito com uma operao read(Q) ou uma operao write(Q). nenhuma read ou write pode
ser realizada sobre um item de dados antes que ele exista.
Uma vez que insert(Q) estabelea um valor para o item de dado Q, a insert tratada de modo similar
write para efeito de controle de concorrncia:
Sob o protocolo de bloqueio em duas fases, se Ti realizar uma operao insert(Q), Ti estar impondo um
bloqueio exclusivo para o novo item de dado Q criado.
Sob o protocolo de ordenao por timestamp, se Ti realizar uma operao insert(Q), os valores de Rtimestamp(Q) e W-timestamp(Q) sero registros em TS(Ti).
O Fenmeno do Fantasma
Considere a transao T29 que executa a consulta SQL a seguir:

A transao T29 obriga o acesso a todas as tuplas da relao conta pertencentes a agncia Perryridge.
Seja T30 uma transao que executa a seguinte insero SQL:

Seja S uma escala de execuo envolvendo T29 e T30. Esperamos um conflito em potencial pelas seguintes
razes:
Se T29 usar a tupla recentemente inserida por T30 para calcular sum(saldo), ento T29 ler o valor inserido
por T30. Assim, em uma escala de execuo serializada equivalente a S, T30 deve comear antes de T29.
297

Se T29 no usar a tupla recentemente inserida por T30 para calcular sum(saldo) em uma escala de
execuo serializada equivalente a S, T29 deve comear antes de T30.
O segundo caso curioso. T29 e T30 no acessam a nenhum tupla em comum, ainda assim entram em
conflito. Com efeito, T29 e T30 entram em conflito com uma tupla fantasma. Assim, o fenmeno que acabamos de
descrever chamado de fenmeno do fantasma. Se o controle de concorrncia feito com granularidade de
tupla, esse conflito pode no ser detectado.
Para prevenir esse fenmeno, fazemos com que T29 evite que outras transaes criem novas tuplas na
relao conta com nome_agncia= Perryridge.
Para encontrar todas as tuplas de conta com nome_agncia = Perryridge, T29 precisa pesquisar toda a
relao conta, ou ao menos um ndice na relao. At agora, consideramos de modo implcito que os itens de
dados aos quais a transao mantm acesso sejam somente tuplas. Entretanto, T29 um exemplo de transao
que procura a informao de quantas tuplas h na relao e T30 exemplifica uma transao que atualiza essa
informao. lgico que no suficiente bloquear as tuplas que sofrem acesso; o bloqueio tambm necessrio
para informaes sobre os quais tuplas esto na relao.
A soluo mais simples para esse problema seria associar um item de dado prpria relao. Transaes,
como a T29, que leem informaes acerca de quais tuplas esto na relao deveriam, ento, bloquear no modo
compartilhado o item de dado correspondente relao conta. Transao, com a T30, que atualizam as
informaes acerca de quais tuplas esto na relao deveriam bloquear o item de dado no modo exclusivo. Desse
modo, T29 e T30 entram em conflito devido a itens de dados reais, e no fantasmas.
No confunda o bloqueio de uma relao inteira, como no bloqueio de granularidade mltipla, com o
bloqueio de um item de dado correspondente relao. Por meio do bloqueio do item de dado, uma transao
impede somente que outras transaes alterem informaes sobre as tuplas que pertencem relao. O
bloqueio das tuplas ainda necessrio. As transaes que mantm acesso direto a uma tupla podem conseguir o
bloqueio de uma tupla mesmo que outra transao tenha bloqueio exclusivo sobre um item de dado
correspondente quela transao propriamente dita.
A maior desvantagem do bloqueio de um item de dado correspondente a uma relao o baixo grau de
concorrncia duas transaes que inserem tuplas diferentes em uma relao no podem ser concorrentes.
Uma soluo melhor a tcnica do bloqueio de ndices. Qualquer transao que inserir uma tupla em
uma relao deve inserir informaes em todos os ndices mantidos pela relao. Eliminamos o fenmeno do
fantasma por meio da imposio de um protocolo de bloqueios para os ndices.
Todo valor da chave de pesquisa est associado a um registro do ndice ou a um bucket. Uma consulta,
normalmente, usar um ou mais ndices para o acesso relao. Uma consulta, normalmente, usar um ou mais
ndices para o acesso relao. Uma insero precisar introduzir uma nova tupla em todos os ndices de uma
relao.
Em nosso exemplo, assumimos que h um ndice em conta para nome_agncia. Logo, T30 precisa
modificar o bucket de Perryridge. Se T29 l o bucket de Perryridge para localizar todas as tuplas pertencentes
agncia Perryridge, ento T29 e T30 entraro em conflito naquele bucket.
O protocolo de bloqueio de ndices possui a vantagem de criar ndices sobre uma relao por meio da
troca de instncias do fenmeno de fantasmas por conflito de bloqueios em ndices bucket. O protocolo opera da
seguinte forma:
Toda relao precisa ter ao menos um ndice.
Uma transao Ti pode bloquear em modo S uma tupla ti de uma relao somente se ela possui um
bloqueio modo S sobre o ndice bucket que contm um ponteiro para ti.
Uma transao Ti pode bloquear em modo X uma tupla ti de uma relao somente se ela possui um
bloqueio modo X sobre o ndice bucket que contm um ponteiro para ti.
Uma transao Ti no pode inserir uma tupla ti em uma relao r sem atualizar todos os ndices de r. Ti
precisa obter um bloqueio modo X sobre todos os ndices bucket que ela modifica.
preciso observar as regras do protocolo de bloqueio em duas fases.

298

H variante da tcnica de bloqueio de ndices para a eliminao do fenmeno do fantasma em outros

protocolos de controle de concorrncia j apresentados.
Concorrncia em Estruturas de ndices
possvel tratar do acesso s estruturas de ndices como qualquer outra estrutura de um banco de dados
e aplicar as tcnicas de controle de concorrncia discutidas anteriormente. Entretanto, uma vez que os ndices
tm acesso frequente, eles se tornam ponto de grande conteno de bloqueios, originando um baixo nvel de
concorrncia. Felizmente, os ndices no tem de receber o mesmo tipo de tratamento das demais estruturas do
banco de dados, j que no proporcionam um alto nvel de abstrao para o mapeamento de chaves de pesquisa
de tuplas do banco de dados. perfeitamente aceitvel que uma transao verifique um ndice duas vezes e
perceba que essa estrutura de ndice foi alterada nesse meio tempo, contanto que o ndice aponte um conjunto
correto de tuplas. Assim, aceitvel manter acesso concorrente no-seriado em um ndice, contanto que a
preciso do ndice seja mantida.
Mostramos a tcnica para o gerenciamento de acessos concorrentes em rvores-B+.
As tcnicas que apresentamos para rvores-B+ tm por base o bloqueio, mas nem o bloqueio em duas
fases nem o protocolo de rvore so empregados.

299

Sistema de Recuperao
Um sistema de computador, como qualquer outro equipamento mecnico ou eltrico, est sujeito a
falhas. H grande variedade de falhas, incluindo quebra de disco, falha de energia, erro de software, fogo na sala
de equipamento ou mesmo sabotagem. Em cada um desses casos, informaes podem ser perdidas. Portanto, o
sistema de banco de dados deve precaver-se para garantir que as propriedades de atomicidade e durabilidade
das transaes sejam preservadas, a despeito de tais falhas. Uma parte integrante de um sistema de banco de
dados o esquema de recuperao que responsvel pela restaurao do banco de dados para um estado
consistente que havia antes da ocorrncia da falha.
Classificao de Falha
Vrios tipos de falhas podem ocorrer em um sistema, cada um dos quais exigindo um tratamento
diferente. O tipo de falha mais simples de tratar aquele que no resulta na perda de informao no sistema. As
falhas mais difceis de tratar so aquelas que resulta em perda de informao. Vamos considerar somente os
seguintes tipos de falha:
Falha de transao. Dois tipos de erros podem causar uma falha de transao:
o Erro lgico. A transao no pode mais continuar com sua execuo normal devido a alguma
condio interna, como uma entrada inadequada, um dado encontrado, overflow ou limite de
recurso excedido.
o Erro de sistema. O sistema entrou em um estado inadequado (por exemplo, deadlock), com isso,
uma transao no pode continuar com sua execuo normal. A transao, entretanto, pode ser
reexecutada posteriormente.
Queda do sistema. H algum mau funcionamento de hardware ou um bug no software de banco de
dados ou no sistema operacional que causou a perda do contedo no armazenamento voltil e fez o
processamento da transao parar. O contedo de armazenamento no-voltil permanece intato e no
corrompido.
A condio originada por erros de hardware e bugs no software que fazem o sistema parar, mas no
corrompem o contedo do armazenamento no-voltil, conhecida como condio falhar-parar. Sistemas bem
projetados tm numerosas verificaes internas em nvel de hardware e software que fazem o sistema parar
quando h um erro. Consequentemente, a condio falhar-parar uma condio razovel.
Falha de disco. Um bloco de disco perde seu contedo em funo da quebra do cabeote ou da falha
durante uma operao de transferncia de dados. So usadas, para recuperao do sistema aps a falha,
as cpias dos dados em outros discos ou backups de arquivos em meios tercirios, como fitas.
Para determinar como o sistema deve recuperar-se das falhas, necessitamos identificar os modos de falha
possveis dos equipamentos usados para armazenar dados. Depois, devemos considerar como esses modos de
falha afetam o contedo do banco de dados. Ento, poderemos desenvolver algoritmos para assegurar a
consistncia do banco de dados e a atomicidade da transao, a despeito das falhas. Esses algoritmos so
conhecidos como algoritmos de recuperao, embora tenham duas partes:
1. Aes tomadas durante o processamento normal da transao a fim de garantir que haja informao
suficiente para permitir a recuperao de falhas.
2. Aes tomadas em seguida falha, recuperando o contedo do banco de dados para um estado que
assegure sua consistncia, a atomicidade da transao e durabilidade.
Estrutura de Armazenamento
Os vrios itens do banco de dados podem ser armazenados e sofre acesos em diferentes meios de
armazenamento. Para compreender como garantir propriedades de atomicidade e durabilidade de uma
transao, devemos compreender melhor como funcionam esses meios de armazenamento e seus mtodos de
acesso.

300

Tipos de Armazenamento
H vrios tipos de meios de armazenamento; eles so distinguidos por sua velocidade relativa, capacidade
e resistncia falha.
Armazenamento voltil. A informao residente em armazenamento voltil usualmente no sobrevive a
quedas no sistema. Exemplos de tal armazenamento so MP e memria cache. O acesso armazenagem
voltil extremamente rpido, tanto devido velocidade de acesso da memria em si quanto ao acesso
direto a qualquer item de dado possvel no armazenamento voltil.
Armazenamento no-voltil. A informao residente em armazenamento no-voltil sobrevive a quedas
de sistema. Exemplos de tal armazenamento so o disco e fitas magnticas. Os discos so usados para
armazenamento online, ao passo que as fitas so usadas para armazenamento de arquivo. Entretanto,
ambos esto sujeitos falha (por exemplo, quebra de cabeote), que pode resultar em perda de
informao. No atual estado da tecnologia, o armazenamento no-voltil mais lento que o
armazenamento voltil por muitas ordens de magnitude. Essa distino ocorre porque discos e fitas so
equipamentos eletromecnicos, em vez de inteiramente baseados em chips, como o armazenamento
voltil. Outros meios no-volteis so usados, normalmente apenas no backup de dados.
Armazenamento estvel. A informao residente em armazenamento estvel nunca perdida (nunca
entendida aqui como uma agulha no palheiro, j que teoricamente nunca no pode ser garantido por
exemplo, possvel, embora extremamente improvvel, que um buraco negro engula a Terra e destrua
permanentemente todos os dados!). Embora o armazenamento estvel seja teoricamente impossvel de
obter, pode-se chegar perto dele usando tcnicas que torna extremamente improvvel a perda de dados.
Frequentemente, as distines entre os vrios tipos de armazenamento so menos claras na prtica que
em nossa apresentao. Certos sistemas fornecem backup de bateria, de forma que parte da MP pode resistir a
quedas de sistema e falhas de energia. Formas alternativas de armazenamento no-voltil, como meio tico,
fornecem maior grau de confiabilidade que os discos.
Implementao do Armazenamento Estvel
Para implementar o armazenamento estvel, temos de replicar a informao em vrios meios de
armazenamento ano-volteis (usualmente discos), como modos possveis de falha independentes, e controlar a
atualizao das informaes, garantindo que uma eventual falha durante a transferncia de dados no danifique
as informaes.
Os sistemas RAID garantem que a falha de um nico disco (mesmo durante a transferncia de dados) no
resulte em perda de dados. A forma mais simples e mais rpida de RAID o disco espelhado, que mantm duas
cpias de cada bloco em discos separados. Outras formas de RAID oferecem custos menores, mas com menor
desempenho.
Os sistemas RAID, entretanto, no podem se proteger contra perda de dados devido a desastres como
incndios ou enchentes. Muitos sistemas armazenam backups em fitas e diferentes locais para proteger-se contra
tais desastres. Entretanto, j que as fitas no podem ser transportadas continuamente, as atualizaes ocorridas
entre o desastre e o ltimo backup podem ser perdidas. Sistemas mais seguros mantm uma cpia de cada bloco
de armazenamento estvel em um site remoto, enviando-a por uma rede de computadores, alm de armazenar o
bloco em um sistema de disco local. J que os blocos so enviados ao sistema remoto, como e quando so
enviados para o armazenamento local, uma vez completada a operao de sada, essa sada no perdida,
mesmo na ocorrncia de um desastre, como um incndio ou uma enchente.
Vamos discutir como o meio de armazenamento pode ser protegido de uma falha durante a transferncia
de dados. A transferncia de blocos entre a memria e o armazenamento de disco pode resultar em:
Concluso bem-sucedida. A informao transferida chegou de forma segura ao seu destino.
Falha parcial. Uma falha ocorreu no meio de transferncia e o bloco de destino contm informao
incorreta.
301

Falha total. A falha ocorreu cedo o suficiente, de modo que o bloco de destino permanece intato.
Exigimos que, se uma falha na transferncia de dados ocorrer, o sistema a detecte e chama um
procedimento de recuperao para restabelecer o bloco, levando-o a um estado consistente. Para isso, o sistema
deve manter dois blocos fsicos para cada bloco lgico do banco de dados; no caso de discos espelhados, ambos
os blocos ento no mesmo local; no caso de backup remoto, um dos blocos local, enquanto o outro est em um
site remoto. Uma operao de sada executa como segue:
1. Escreve a informao dentro do primeiro bloco fsico.
2. Quando a primeira escrita se completar com sucesso, escreve a mesma informao no segundo bloco
fsico.
3. A sada completada somente aps a segunda escrita completar-se com sucesso.
Durante a recuperao, cada par de blocos fsico examinado. Se ambos so iguais e no h erro detectvel,
ento nenhuma ao adicional necessria. Se um bloco contm um erro detectvel, ento trocamos seu
contedo pelo contedo do segundo bloco. Se ambos os blocos no contm erros detectveis, mas diferem em
contedo, ento trocamos o contedo do primeiro bloco pelo valor do segundo. Esse procedimento de
recuperao assegura que uma escrita em armazenamento estvel seja bem-sucedida (isto , atualize todas as
cpias), ou no resulte em mudana alguma.
Exigir a comparao entre cada par de blocos correspondentes durante a recuperao custoso.
Podemos reduzir consideravelmente o custo mantendo uma varredura de escritas de bloco que esto em
progresso, usando uma pequena quantidade de RAM no-voltil.
Os protocolos para escrita de um bloco em um site remoto so similares aos protocolos para escrita de
blocos em sistema de disco espelhado.
Podemos facilmente expandir esse procedimento para que permita o uso de um nmero arbitrariamente
grande de cpias de cada bloco de armazenamento estvel. Embora o uso de um nmero grande de cpias
reduza a probabilidade de uma falha para muitos menos que quando se usam duas cpias, em geral suficiente
simular o armazenamento estvel somente com duas cpias.

Acesso de dados
O sistema de banco de dados reside permanentemente em armazenamento no-voltil (usualmente
discos) e particionado em unidades de armazenamento de comprimento fixo chamadas de blocos. Os blocos
so unidades de transferncia de dados para e a partir do disco e podem conter vrios itens de dados. Assumimos
que nenhum item de dado abrange dois ou mais blocos. Essa premissa verdadeira para a maioria das aplicaes
de processamento de dados, como em nosso exemplo bancrio.
As transaes transferem informaes do disco para a MP e, ento, reenviam essas informaes de volta
para o disco. As operaes de entrada e sada (entrar e sair da memria) so feitas em unidades de bloco. Os
blocos residentes no disco so chamados de blocos fsicos; os blocos residentes temporariamente na MP so
chamados de blocos de buffer. A rea de memria na qual os blocos residem temporariamente chamada de
buffer de disco.
Movimentos de bloco entre disco e memria principal so iniciados por meio de duas operaes
seguintes:
1. input(B) transfere o bloco fsico B para a MP.
2. output(B) transfere o bloco de buffer B para o disco e troca-o, no disco, pelo fsico apropriado.
Esse esquema ilustrado na fig. 15.1.

302

Cada transao Ti tem uma rea de trabalho privada na qual cpias de todos os itens de dados acessados
e atualizados so mantidas. Essa rea de trabalho criada quando a transao iniciada; ele removida quando
a transao iniciada; ela removida quando a transao efetivada ou abortada. Cada item de dados x mantido
na rea de trabalho da transao Ti denotado por xi. A transao Ti interage com o sistema de banco de dados
pela transferncia de dados para e de sua rea de trabalho at o buffer de sistema. Transferimos os dados usando
as duas operaes a seguir:
1. read(X) designa o valor do item de dado X para a varivel local xi. Essa operao executada como segue:
a. Se o bloco Bx no qual reside X no est na memria principal, ento emitido um input(Bx).
b. Designa a xi o valor de X a partir do bloco de buffer.
2. write(X) designa o valor da varivel local xi para o item de dado X no bloco de buffer. Essa operao
executada como segue:
a. Se o bloco Bx no qual reside X no est na memria principal, ento emite um input(Bx).
b. Designa o valor de xi para X no buffer Bx.
Observe que ambas as operaes podem exigir a transferncia de um bloco do disco para a MP.
Entretanto, elas no exigem a transferncia de um bloco da MP para o disco.
O bloco de buffer ser eventualmente escrito no disco se o gerenciador de buffer necessitar de espao
em memria para outros propsitos ou porque o sistema de banco de dados deseja refletir a mudana em B
sobre o disco. Dizemos que o sistema de banco de dados fora sadas do buffer B se ele emite um output(B).
Quando uma transao necessita do acesso a um item de dado X pela primeira vez, ela deve executar
read(X). Todas as atualizaes de X so, ento, realizadas sobre xi. Aps o ltimo acesso X feito pela transao, ela
executar um write(X) para refletir a mudana em X no banco de dados propriamente dito.
A operao output(Bx) para o buffer de bloco Bx em que X reside no precisa ter efeito imediato aps a
execuo do write(X), j que o bloco Bx pode conter outros itens de dados que ainda esto sendo acessados.
Ento, a sada real aparecer mais tarde. Observe que, se o sistema cair aps a operao write(X) ter sido
executada, mas antes do output(Bx), o novo valor de X nunca ser escrito no disco e, portanto, perdido.
Recuperao e Atomicidade
Considere novamente nosso sistema bancrio simplificado e a transao Ti transfere 50 dlares da conta
A para a conta B, com valores iniciais de A e B sendo mil e dois mil dlares, respectivamente. Suponha que uma
queda de sistema tenha ocorrido durante a execuo de Ti, aps output(BA), mas antes do output(BB), em que BA
e BB denotam os blocos de buffer em que A e B residem. J que os contedos de memria foram perdidos, no
sabemos o destino da transao; ento, poderamos chamar um dos dois possveis procedimentos de
recuperao:
Reexecutar Ti. Este faz com que o valor de A torne-se 900 dlares, em vez de 950 dlares. Ento, o
sistema entra em um estado inconsistente.
No reexecutar Ti. No estado corrente do sistema, os valores A e B so de 950 e 2000 dlares,
respectivamente. Ento, o sistema entra em um estado inconsistente.
Em ambos os casos, o banco de dados deixado em estado inconsistente, logo esse esquema de recuperao
simples no funciona. Essa dificuldade ocorre porque modificamos o banco de dados sem ter certeza de que a
303

transao ser efetivada de fato. Entretanto, se Ti realizou diversas modificaes no banco de dados, podem ser
necessrias vrias operaes de sada e pode ocorrer uma falha aps algumas dessas modificaes terem sido
feitas, mas antes de todas serem realizadas.
Para atingir nosso objetivo de atomicidade, primeiro devemos mandar informaes que descrevam essas
modificaes para um armazenamento estvel, sem modificar o banco de dados em si. Como veremos, esse
procedimento nos permitir enviar todas as modificaes feitas por uma transao efetivada, apesar de possveis
falhas. H duas maneiras de realizar tais sadas. Vamos assumir que as transaes so executadas serialmente,
isto , somente uma nica transao est ativa de cada vez.
Recuperao Baseada em Log
A estrutura mais usada para gravar modificaes no banco de dados o log (dirio). O log uma
sequncia de registros de log que mantm um arquivo atualizado das atividades no banco de dados. H vrios
tipos de registros de log que mantm um arquivo atualizado das atividades no banco de dados. H vrios tipos de
registro de log. Um registro de atualizao de log descreve uma nica escrita do banco de dados e tem os
seguintes campos:
Identificador de transao um identificador nico da transao que realiza operao de escrita (write).
Identificao de item de dado um identificador nico do item de dado escrito. Normalmente, a
localizao do item de dado no disco.
Valor antigo o valor do item de dado anterior escrita.
Valor novo o valor que o item de dado ter aps a escrita.
H outros registros de log para arquivar eventos significativos durante o processamento de transao,
como o incio da transao, sua efetivao ou aborto. Indicamos os vrios tipos de registros de log como seguem:
<Ti start>. A transao Ti comeou.
<Ti, Xj, V1, V2>. A transao Ti foi efetivada.
<Ti abort>. A transao Ti foi abortada.
Sempre que uma transao realiza uma escrita, essencial que o registro de log para aquela escrita seja
criado antes do banco de dados ser modificado. Havendo o registro de log, podemos enviar a modificao ao
banco de dados quando ela for conveniente. Tambm conseguiremos inutilizar (undo) uma modificao que j
tenha sido enviada ao banco de dados. Podemos desfaz-la usando o campo de valor antigo do registro de log.
Para que os registros de log sejam teis na recuperao aps falhas de sistema e disco, o log deve residir
em armazenamento estvel. Por enquanto, assumiremos que todo registro de log ser escrito no final do arquivo
de log em armazenamento estvel, to logo seja criado. Veremos quando seguro afrouxar essa exigncia para
reduzir o overhead imposto ao registro em log. Introduziremos tambm duas tcnicas de uso de log para garantir
atomicidade de transaes apesar das falhas. Repare que o log contm um registro completo de toda atividade
do banco de dados. Com isso, o volumo de dados armazenado no log pode tornar-se absurdamente grande.
Mostraremos quando seguro apagar informaes de log.
Modificaes adiadas do banco de dados
A tcnica de adiar modificaes garante a atomicidade de transaes quando todas as modificaes do
banco de dados so escritas no log, adiando a execuo de todas as operaes write de uma transao at sua
efetivao parcial. Lembre-se de que uma transao considerada parcialmente efetivada quando a ltima ao
da transao tiver sido executada. A verso da tcnica de modificao que descrevemos aqui pressupe que as
transaes sejam executadas serialmente.
Quando uma transao parcialmente efetivada, as informaes no log associadas quela transao so
usadas para a execuo das escritas adiadas. Se o sistema cair antes de completar a transao ou se a transao
for abortada, ento as informaes do log sero simplesmente ignoradas.

304

A execuo da transao Ti funciona como segue. Um registro <Ti start> escrito no log antes de Ti ter
incio. Uma operao write(X) feita por Ti resulta na escrita de um novo registro no log. Finalmente, quando Ti
parcialmente efetivada, um registro <Ti commit> escrito no log.
Quando uma transao Ti parcialmente efetivada, os registros no log a ela associados so usados para
execuo das escritas adiadas. Como uma falha pode ocorrer enquanto essa execuo est em andamento,
devemos ter certeza, antes de comea-la, de que todos os registros de log estejam escritos em armazenamento
estvel. Uma vez escritas, as atualizaes reais podem ocorrer de fato e a transao entra no estado de
efetivao.
Observe que somente o novo valor do item de dado necessrio para a tcnica de modificao adiada.
Logo, podemos simplificar a estrutura geral do registro de atualizao do log, que vimos anteriormente, por meio
da omisso do campo de valor antigo.
Para ilustrao, reconsidere nosso exemplo de sistema bancrio simplificado. Seja T0 uma transao que
transfere 50 dlares da conta A para a conta B. Essa transao definida como segue:

Seja T1 uma transao que debita cem dlares da conta C. Essa transao definida como:

Suponha que essas transaes sejam executadas serialmente, T0 seguida por Ti e os valores das contas
A, B e C antes da execuo, eram de 1000, 2000 e 700 dlares, respectivamente. A poro do log contendo as
informaes relevantes sobre essas duas transaes apresentada 15.2.

Como resultado da execuo de T0 e T1, h vrias ordens possveis em que as sadas reais podem ocorrer,
tanto para o sistema de banco de dados como para o log. Tal ordem apresentada na fig. 15.3. Note que o valor
de A alterado somente aps o registro <T0, A, 950> ter sido colocado no log.

Usando o log, o sistema pode lidar com qualquer falha que resulte em perda de informao no
armazenamento voltil. O esquema de recuperao usa o seguinte procedimento:
redo(Ti) define o valor de todos os itens de dados atualizados pela transao Ti para os novos valores.
O conjunto de itens de dados atualizados por Ti e seus respectivos novos valores podem ser encontrados
no log.
305

A operao redo (refazer) deve ser idempotente, isto , execut-la vrias vezes deve ser equivalente a
execut-la uma vez s. Essa caracterstica exigida se formos garantir comportamento correto, mesmo que uma
falha ocorra durante o processo de recuperao.
Aps a ocorrncia de uma falha, o subsistema de recuperao consulta o log para determinar quais
transaes tm de ser refeitas. A transao Ti dever ser refeita se, e somente se, o log contiver os registros <Ti
start> e <Ti commit>. Assim, se o sistema cair depois que a transao completar sua execuo, as informaes no
log sero usadas na restaurao do sistema para o estado consistente anterior.
Como ilustrao, retornemos a nosso exemplo bancrio com as transaes T0 e T1 executadas uma aps a
outra, T0 seguida por T1. A figura 15.2 mostra o log resultante da execuo completa de T0 e T1.
Suponhamos que o sistema caia antes que as transaes terminem, de forma que possamos ver como a
tcnica de recuperao restabelece o banco de dados para um estado consistente. Assuma que a queda logo aps
o registro de log do passo write (B) da transao T0 ter sido escrito em armazenamento estvel. O log, no
momento da queda, mostrado na fig. 15.4a. Quando o sistema retorna, nenhuma ao refazer tem de ser
tomada, j que nenhum registro de efetivao aparece no log. Os valores das contas A e B permanecem mil e dois
mil dlares, respectivamente. Os registros de log da transao incompleta T0 podem ser removidos do log.

Agora, assumamos que a queda venha logo aps o registro de log para o passo write(C) da transao T1
ter sido escrito em armazenamento estvel. Nesse caso, o log, no momento da queda, est como na fig. 15.4.
Quando o sistema retorna, a operao redo (T0) realizada, j que o registro <T0 commit> aparece no log em
disco. Aps essa operao, os valores das contas A e B so 950 e 2050 dlares, respectivamente. O valor da conta
C permanece 700 dlares. Como antes, os registros de log da transao incompleta T1 podem ser removidos do
log.
Por ltimo, assumamos que uma queda ocorra logo aps o registro de log <T1 commit> ser escrito em
armazenamento estvel. O log, no momento dessa queda, est como mostra a fig. 15.4c. Quando o sistema
retorna, dois registros de efetivao esto no log: um para T0 e um para T1. Portanto, as operaes redo(T0) e
redo(T1) devem ser processadas. Aps essas operaes, os valores das contas A, B e C so, respectivamente, 950,
2050 e 600 dlares.
Finalmente, consideremos o caso em que uma segunda queda de sistema ocorre durante a recuperao
da primeira queda. Algumas mudanas devem ter sido feitas no banco de dados como resultado das operaes
redo, mas pode ser que nem todas as alteraes tenham ocorrido. Quando o sistema retornar da segunda queda,
a recuperao se dar exatamente como nos exemplos anteriores.
Para cada registro de efetivao <Ti commit> encontrado no log, a operao redo(Ti) ser processada. Em
outras palavras, as aes de recuperao so reinicializadas a partir do comeo. J que redo escreve valores no
banco de dados independente de seus valores correntes, o resultado de uma segunda tentativa de redo ser igual
ao alcanado caso o redo seja bem-sucedido j na primeiro vez.
Modificao Imediata de Banco de Dados
A tcnica de atualizao imediata permite que as modificaes no banco de dados sejam enviadas
enquanto as transaes ainda esto no estado ativo. As escritas emitidas por transaes ativas so chamadas de
modificaes no-efetivadas. Na ocorrncia de uma queda ou de uma falha de transao, o sistema dever usar o
campo relativo ao valor antigo dos registros de log para restaurao dos itens de dados modificados, levando-os
306

ao valor anterior ao incio da transao. Essa restaurao conseguida por meio da operao undo (desfazer)
descrita a seguir.
Antes que uma transao Ti inicie sua execuo, o registro <Ti start> escrito no log. Durante sua
execuo, qualquer operao write(X) feita por Ti precedida pela escrita apropriada do novo registro corrente
no log. Quando Ti parcialmente efetivada, o registro <Ti commit> escrito no log.
J que as informaes do log so usadas na reconstruo do estado do banco de dados, no podemos
permitir que a atualizao real do banco de dados ocorra antes da escrita correspondente, em armazenamento
estvel, do registro de log. Portanto, exigimos que, antes da execuo de uma operao output(B), os registros de
log correspondentes a B sejam escritos em armazenamento estvel.
Como ilustrao, reconsideremos nosso sistema bancrio simplificado, com transaes T0 e T1 executadas
uma aps a outra com T0 seguida por T1. A poro do log contendo as informaes importantes relativas a essas
duas transaes apresentada na fig. 15.5.

Uma ordem possvel de ocorrncia das sadas reais, tanto para o sistema de banco de dados quanto para
o log, resultantes da execuo de T0 e T1, descrita na fig. 15.6. Observe que essa ordem no poderia ser obtida
na tcnica de modificao adiada.

Usando o log, o sistema pode tratar de qualquer falha que no resulte na perda de informao em
armazenamento no-voltil. O esquema de recuperao usa dois procedimentos de recuperao:
undo(Ti) retorna aos valores antigos todos os itens de dados atualizados pela transao Ti.
redo(Ti) ajusta os valores de todos os itens de dados atualizados pela transao Ti para os valores novos.
O conjunto de itens de dados atualizados por Ti e seus respectivos valores antigos e novos podem ser
encontrados no log.
As operaes undo e redo devem ser idempotentes para garantir o comportamento correto mesmo se
uma falha ocorrer durante o processo de recuperao.
Aps a falha, o esquema de recuperao consulta o log para determinar quais transaes necessitam ser
refeitas e quais necessitam ser inutilizadas. Essa classificao de transaes conseguida como segue:
A transao Ti tem de ser inutilizada se o log contm o registro <Ti start>, mas no contm o registro <Ti
commit>.
A transao Ti tem de ser refeita se o log contm tanto o registro <Ti start> quanto o registro <Ti commit>.
Como ilustrao, retornaremos a nosso exemplo bancrio, com as transaes T0 seguida por T1. Suponhamos
que o sistema caia antes do trmino das transaes. Deveremos considerar trs casos. O estado dos logs para
cada um desses casos mostrado na fig. 15.7.
307

Primeiro, assumamos que a queda ocorra logo aps o registro de log para o passo write(B) da transao
T0 ter sido escrito em armazenamento estvel (fig. 15.7a). quando o sistema retorna, ele encontra o registro <T0
start> no log, mas nenhum registro <T0 commit> correspondente. Ento, a transao T0 dever ser inutilizada, de
modo que um undo(T0) ser processado. Como resultado, os valores nas contas A e B (no disco) so restaurados
em mil e dois mil dlares, respectivamente.
A seguir, assumamos que a queda venha logo aps o registro de log para o passo write(C) da transao T1
ter sido escrito em armazenamento estvel (fig. 15.7b). Quando o sistema retornar, duas aes de recuperao
necessitam ser tomadas. A operao undo (T1) deve ser realizada, j que o registro <T1 start> aparece no log, mas
no h o registro <T1 commit>, e a operao redo(T0) tambm deve ser realizada, j que o log contm tanto o
registro <T0 start> como o registro <T0 commit>. No fim do processo de recuperao completo, os valores das
contas A, B e C sero 950, 2050 e 700 dlares, respectivamente. Observe que a operao undo(T1) realizada
antes de redo(T0). Nesse exemplo, o resultado seria o mesmo se a ordem fosse revertida. Entretanto, fazer
primeiro as operaes undo e depois as operaes redo importante no algoritmo de recuperao que veremos
adiante.
Finalmente, assumamos que a queda ocorra logo aps o registro de log <T1 commit> ter sido escrito em
armazenamento estvel (fig. 15.7c). Quando o sistema retorna, tanto T0 como T1 necessitam ser refeitas, j que os
registros <T0 start> e <T0 commit> aparecem no log, assim como os registros <T1 start> e <T1 commit>. Aps os
procedimentos de recuperao redo(T0) e redo(T1), os valores nas contas A, B e C sero 950, 2050 e 600 dlares,
respectivamente.
Checkpoints
Quando uma falha de sistema ocorre, devemos consultar o log para determinar aquelas transaes que
necessitam ser refeitas e aquelas que necessitem ser inutilizadas. A princpio, para isso, deveramos pesquisar
todo o log. H duas grandes dificuldades nessa abordagem:
1. O processo de pesquisa consome tempo.
2. Muitas das transaes que, de acordo com nosso algoritmo, necessitam ser refeitas j escreveram suas
atualizaes no banco de dados. Embora refaz-las no cause dano algum, a recuperao torna-se mais
longa.
Para reduzir esses tipos de overhead, introduzimos os checkpoints (pontos de controle). Durante a
execuo, o sistema mantm o log usando uma das duas tcnicas descritas anteriormente. Alm disso, o sistema
cria checkpoints periodicamente, que exigem a execuo da seguinte sequncia de aes:
1. Sada, para armazenamento estvel, de todos os registros residentes na memria principal;
2. Sada, para disco, de todos os blocos de buffer modificados.
3. Sada, para armazenamento estvel, de um registros de log <checkpoint>.
No permitido s transaes processar quaisquer aes de atualizao, como escrever em um bloco de
buffer ou escrever um registro de log, enquanto um checkpoint est em progresso.
A presena de um registro <checkpoint> no log permite que o sistema dinamize seu procedimento de
recuperao. Considere uma transao Ti efetivada antes do checkpoint. Para tal transao, o registro <Ti
commit> aparece no log antes do registro <checkpoint>. Quaisquer modificaes feitas por Ti ou j foram escritas
no banco de dados antes do checkpoint ou o foram como parte do checkpoint propriamente dito. Ento, no
momento de recuperao, no haver necessidade de uma operao redo sobre Ti.
308

Essa observao permite-nos refinar nossos esquemas de recuperao anteriores (continuamos a assumir
que as transaes so executadas serialmente). Aps uma falha, o esquema de recuperao examina o log para
determinar a ltima transao Ti anterior ao checkpoint mais recente. Isso poder ser feito por uma pesquisa
retroativa no log, a partir de seu final at o primeiro registro <checkpoint> (j que estamos pesquisando em
ordem cronolgica inversa, o registro encontrado ser o ltimo registro <checkpoint> do log); ento o sistema
continuar a pesquisar retroativamente at encontrar o prximo registro <Ti start>. Esse registro identifica uma
transao Ti.
Uma vez identificada a transao Ti, as operaes redo e undo devem ser aplicadas transao Ti e a
todas as transaes Tj que comearam depois da dela. Indiquemos essas transaes pelo conjunto T. O restante
(parte anterior) do log pode ser ignorado e at mesmo apagado, se for conveniente. Quais operaes de
recuperao devem, exatamente, ser processadas depender da tcnica de modificao em uso, se imediata ou
adiada. As operaes de recuperao exigidas, se a tcnica de modificao imediata empregada, so as
seguintes:
Para todas as transaes Tk em T que no tm nenhum registro <Tk commit> no log ser executado
undo(Tk).
Para todas as transaes Tk em T tais que o registro <Tk commit> aparece no log ser executado redo(Tk).
Obviamente, a operao undo no ser aplicada caso a tcnica de modificao adiada esteja em uso.
Como ilustrao, considere o conjunto de transaes {T0,T1,..., T100} executado na ordem dos subescritos.
Suponha que o checkpoint mais recente tenha ocorrido durante a execuo da transao T67. Ento, somente as
transaes T67, T68, ..., T100 necessitam ser consideradas durante o esquema de recuperao. Cada uma delas ser
refeita se tiver sido efetivada; caso contrrio, ser inutilizada.
Paginao Shadow
Uma alternativa s tcnicas de recuperao de queda baseada em log a paginao shadow (sombra). A
tcnica de paginao shadow essencialmente uma melhoria de tcnica de cpia shadow. Sob certas
circunstncias, a paginao shadow pode exigir menos acessos a disco que os mtodos baseados em log que
acabamos de discutir. Entretanto, tambm h desvantagens nessa abordagem, como veremos. Por exemplo,
difcil aplicar a paginao shadow pode exigir menos acessos a disco que os mtodos baseados em log que
acabamos de discutir. Entretanto, tambm h desvantagens nessa abordagem, como veremos. Por exemplo,
difcil aplicar a paginao shadow em transaes concorrentes.
Como antes, o banco de dados particionado em um nmero de blocos de comprimento fixo, chamados
de pginas. O termo pgina emprestado dos sistemas operacionais, j que estamos usando um esquema de
paginao para gerenciamento de memria. Assumamos que haja n pginas, numeradas de 1 at n. (Na prtica, n
pode ser da ordem de centenas de milhares.) Essas pginas no necessitam ser armazenadas em alguma ordem
particular no disco (h muitas razes para que isso no acontea). Entretanto, deve haver uma forma de
encontrar, para um i qualquer, a i-sima pgina do banco de dados. Usamos, para esse proposito, uma tabela de
pgina, como mostrado na fig. 15.8. A tabela de pgina tem n entradas uma para cada pgina do banco de
dados. Cada entrada contm um ponteiro para uma pgina no disco. A primeira entrada contm um ponteiro
para a primeira pgina do banco de dados, a segunda entrada aponta para a segunda pgina e assim por diante. O
exemplo da fig. 15.8 mostra que a ordem lgica das pginas do banco de dados no necessita corresponder
ordem fsica em que as pginas esto armazenadas no disco.
A ideia bsica da tcnica de paginao shadow manter duas tabelas de pgina durante o processamento
da transao: a tabela de pginas atuais e a tabela de pginas shadow. Quando a transao comea, ambas as
tabelas so idnticas. A tabela de pgina shadow no alterada durante toda a durao da transao. A tabela de
pgina atual alterada quando a transao processa uma operao write. Todas as operaes de entrada (input)
e sada (output) usam a tabela de pginas atuais para localizar pginas do banco de dados no disco.

309

Suponha que a transao processe uma operao write(X) e que X resida na i-sima pgina. A operao
write executada como segue:
1. Se a i-sima pgina (isto , a pgina em que X reside) ainda no est na MP, ento ser emitido um
input(X).
2. Se essa a primeira escrita processada na i-sima pgina por essa transao, ento a tabela de pginas
atuais ser modificada conforme segue:
a. Encontra-se uma pgina sem uso no disco. Normalmente, o sistema de banco de dados tem
acesso a uma lista de pginas sem uso (livres).
b. Remove-se a pgina encontrada no passo 2a a partir da lista de quadros de pginas livres.
c. Modifica-se a tabela de pginas atuais, tal que a i-sima entrada aponte para a pgina encontrada
no passo 2a.
3. Designa-se o valor de xj para X na pgina de buffer.

Comparemos a ao precedente para a operao write com aquela j descrita. A nica diferena
adicionamos um novo passo. Os passos 1 e 3 anteriores correspondem aos passos 1 e 2 descritos anteriormente.
O passo adicional, passo 2, manipula a tabela de pginas atuais. A fig. 15.9 mostra as tabelas, shadow e atual,
para uma transao que realize uma escrita na quarta pgina de um banco de dados constitudo de dez pginas.
Intuitivamente, a abordagem de recuperao por meio de pginas shadow consiste em manter uma
tabela de pginas atuais. A fig. 15.9 mostra as tabelas, shadow e atual, para uma transao que realize uma
escrita na quarta pgina de um banco de dados constitudo de dez pginas.
Intuitivamente, a abordagem de recuperao por meio de pginas shadow consiste em manter uma
tabela de pginas shadow em armazenamento no-voltil, tal que se possa recuperar o estado do banco de dados
anterior execuo da transao, devido a uma queda ou aborto da transao. Quando uma transao
efetivada, a tabela de pginas atuais escrita em armazenamento no-voltil. A tabela de pginas atuais torna-se,
ento, a nova tabela de pginas shadow e, ento, uma nova transao pode comear. importante que a tabela
de pginas shadow seja armazenada em meio no-voltil, j que ela fornece o nico meio de localizao das
pginas do banco de dados. A tabela de pginas atuais pode ser mantida na MP (armazenamento voltil). No
importa se a tabela de pginas atuais perdida em uma queda, j que o sistema se recupera usando a tabela de
pgina shadow.

310

Uma recuperao bem-sucedida exige que, aps uma queda, encontremos a tabela de pginas shadow no
disco. Uma forma simples de encontra-la manter, em uma localizao fixa de armazenamento estvel, o
endereo em disco da tabela de pgina shadow. Quando o sistema retornar aps uma queda, copiamos a tabela
de pginas shadows na MP e a usamos para o processamento subsequente da transao. Devido a nossa
definio de operao write, garantimos que a tabela de pginas shadow apontar para as pginas do banco de
dados que correspondem ao estado do banco de dados anterior a qualquer transao ativa no momento da
queda. Ento, o aborto de transaes automtico. Ao contrrio dos esquemas baseados em log, nenhuma
operao undo precisa ser chamada.
Para efetivar uma transao, devemos fazer o seguinte:
1. Garantir que todas as pginas de buffer da MP que foram alteradas pela transao sejam enviadas para a
sada em disco. (Observe que essas operaes de sada no alteraro as pginas do banco de dados
apontadas pela tabela de pginas shadow.)
2. Enviar a tabela de pginas atuais para sada em disco. Observe que no devemos sobrescrever a tabela de
pginas atuais, j que poderemos precisar dela para a recuperao aps uma queda.
3. Enviar os endereos de disco da tabela de pgina atuais para a localizao fixa em armazenamento
estvel que contm o endereo da tabela de pginas shadow. Essa ao sobrescreve o endereo da tabela
de pginas shadow antiga. Portanto, a tabela de pginas atuais tornou-se a tabela de pginas shadow e a
transao foi efetivada.
Se uma queda ocorrer antes do trmino do passo 3, reverteremos ao estado anterior ao da execuo da
transao. Se a queda ocorrer aps o trmino do passo 3, os efeitos da transao ainda assim sero preservados;
nenhuma operao redo precisar ser atividade.
A paginao shadow oferece diversas vantagens sobre as tcnicas baseadas em log. O overhead relativo
ao envio dos registros de log eliminado e a recuperao de falhas significativamente mais rpida (j que
nenhum operao undo e redo necessria). Entretanto, h tambm inconvenientes nessa tcnica.
Overhead de efetivao. A efetivao de uma nica transao usando paginao shadow exige que
diversos blocos sejam enviados blocos de dados reais, tabela de pginas atuais e o endereo de disco da
tabela de pginas atuais. Os esquemas baseados em log precisam enviar somente os registros de log que,
para as pequenas e mais comuns transaes, cabem dentro de um bloco.
Fragmentao de dado. Consideramos estratgias para manter prximas no disco as pginas do banco de
dados relacionadas fisicamente. Essa proximidade permite maior rapidez na transferncia de dados. A
paginao shadow gera alteraes na localizao das pginas do banco de dados quando elas sofrem
311

atualizaes. Com isso, ou perdemos a proximidade das pginas ou precisaremos recorrer a esquemas
mais complexos, com maior overhead para gerenciamento do armazenamento fsico.
Coleta de lixo. Cada vez que uma transao efetivada, as pginas do banco de dados contendo a verso
antiga do dado, alterado pela transao, tornam-se inacessveis. Na fig. 15.9, a pgina apontada pela
quarta entrada da tabela de pginas shadow se tornar inacessvel se a transao daquele exemplo for
efetivada. Tais pginas so consideras lixo, j que elas no fazem parte do espao livre nem contm
informao til. O lixo tambm pode ser um efeito colateral das quedas. Periodicamente, necessrio
encontrar todas as pginas lixo e adicion-las lista de pginas livres. Esse processo, chamado de coleta
de lixo, impe overhead e complexidade adicionais ao sistema. H vrios algoritmos-padro para coleta
de lixo.
Alm dos inconvenientes que mencionamos, a adaptao da paginao shadow a sistemas com
transaes concorrentes mais difcil do que registro de log. Em tais sistemas, algum tipo de registro de log
normalmente necessrio, mesmo que a paginao shadow seja usada. O prottipo do Sistema R, por exemplo,
usava uma combinao de paginao shadow com um esquema de registro de log similar ao j apresentado.
relativamente simples ampliar os esquemas de recuperao baseados em log para que trabalhem com transaes
concorrentes. Por essas razes, a paginao shadow no to usada.
Recuperao com Transaes Concorrentes
At agora, consideramos a recuperao em um ambiente no qual uma nica transao executada por
vez. Agora, discutiremos como modificar o esquema de recuperao baseado em log para tratar de diversas
transaes concorrentes. Independente do nmero de transaes concorrentes, o sistema tem um nico buffer
de disco e um nico log. Os blocos de buffer so compartilhados por todas as transaes. Permitiremos, alm de
atualizaes imediatas, que um bloco de buffer tenha itens de dados atualizados por uma ou mais transaes.
Interao com Controle de Concorrncia
O esquema de recuperao depende muito do esquema de controle de concorrncia em uso. Para
reverter (rollback) uma transao com falha, devemos inutilizar as atualizaes processadas por ela. Suponha que
uma transao T0 tenha de ser desfeita e um item de dado Q que foi atualizado por T0 tenha de recuperar seu
valor antigo. Usando os esquemas baseados em log, recuperamos esses valor usando as informaes undo de um
registro de log.
Suponha agora que uma segunda transao T1 tenha tambm processado uma atualizao sobre Q antes
de T0 ser desfeita. Ento, a atualizao processada por T1 ser perdida quando T0 for revertida.
Portanto, exigimos que, se uma transao T atualizou um item de dado Q, nenhuma outra transao
consiga atualizar o mesmo item de dado at que T tenha sido efetivada ou revertida. Podemos facilmente cumprir
essa exigncia pelo bloqueio em duas fases severo isto , bloqueio em duas fases com bloqueios exclusivos
mantidos at o final da transao.
Reverso de Transao
Revertemos uma transao com falha, Ti, usando o log. O log reexaminado, do fim para o comeo; e
para cada registro da forma <Ti, Xj, V1, V2> encontrado, o item de dado Xj restaurado em seu valor antigo V1.
Esse exame termina quando o registro de log <Ti, start> encontrado.
Reexaminar o log de trs para frente importante, j que uma transao pode ter atualizado um item de
dados mais de uma vez. Como ilustrao, considere o par de registros de log:

Os registros de log representam uma modificao do item de dado A por Ti, seguido de outra modificao
de A por Ti. Reexaminar o log do final para o comeo ajusta A corretamente para 10. Se os logs fossem
examinados no sentido inverso, A seria ajustado para 20, cujo valor incorreto.
312

Se o bloqueio em duas fases severo usado para controle de concorrncia, os bloqueios mantidos pela
transao T podem ser liberados somente aps a transao ter sido revertida, como descrito. Uma vez que uma
transao T (que revertida) tenha atualizado um item de dado, nenhuma outra transao poder atualizar o
mesmo item de dado, devido s exigncias de controle de concorrncia mencionadas anteriormente. Portanto, a
recuperao do valor antigo do item de dado no apagar os efeitos de qualquer transao.
Checkpoints
Usamos checkpoints para reduzir o nmero de registros de log que devem ser examinados quando o
sistema se recupera de uma queda. J que no tnhamos levado qualquer ocorrncia em conta, foi necessrio
considerar somente as seguintes transaes durante a recuperao:
Aquelas transaes que iniciaram aps o checkpoint mais recente.
Aquela transao, se houver alguma, que estava ativa no momento da escrita do checkpoint mais
recente.
A situao mais complexa quando as transaes podem ser executadas de modo concorrente, j que
vrias transaes poderiam estar ativas no momento em que o checkpoint mais recente foi gerado.
Em um sistema com processamento de transaes concorrentes, exigimos que o registro de log relativo
ao checkpoint seja da forma <checkpoint L>, em que L a lista de transaes ativas no momento do checkpoint.
Novamente, assumimos que as transaes no processam atualizaes tanto nos blocos de buffer como no log
enquanto o checkpoint est em andamento.
A exigncia de que as transaes no devem realizar quaisquer atualizaes nos blocos de buffer, ou no
log, durante o checkpoint pode ser preocupante, j que o processamento de transao ter de parar enquanto
um checkpoint estiver em progresso. Um fuzzy checkpoint aquele que permitido s transaes processarem
atualizaes mesmo quando os blocos de buffer esto sendo escritos.
Recuperao por Reincio
Quando um sistema se recupera de uma queda, ele constri duas listas: a lista inutilizar (undo-list), que
consiste em transaes a serem inutilizadas, e a lista refazer (redo-list), que consiste em transaes a serem
refeitas.
Essas duas listas so construdas na recuperao como segue. Inicialmente, ambas esto vazias.
Examinando o log de trs para frente, cada registro, at que seja encontrado o primeiro registro <checkpoint>:
Para cada registro da forma <Ti commit> encontrado, adicionamos Ti lista refazer.
Para cada registro da forma <Ti start> encontrado, se Ti no estiver na lista refazer, ento adicionamos Ti
na lista inutilizar.
Quando todos os registros de log apropriados tiverem sido examinados, checamos a lista L no registro de
checkpoint em questo. Para cada transao Ti em L, se Ti no estiver na lista refazer, ento ser adicionada lista
inutilizar.
Uma vez construdas as listas refazer e inutilizar, os procedimentos de recuperao prosseguem como
segue:
1. Reexaminar o log a partir do registro mais recente e processar um undo para cada registro de log
pertencente transao Ti na lista inutilizar. Os registros de log de transaes na lista refazer sero
ignorados nessa fase. O exame para quando os registros <Ti start> so encontrados para cada
transao Ti na lista inutilizar.
2. Localizar o registro <checkpoint L> mais recente no log. Note que este passo pode implicar exame do
log na ordem cronolgica crescente, se o registro de checkpoint foi ultrapassado no passo 1.
3. Examinar o log a partir do registro <checkpoint L> mais recente at o final e processar redo para cada
registro de log pertencente a uma transao Ti que est na lista refazer. Ignorar os registros de log de
transaes na lista inutilizar nessa fase.

313

 importante processar o log no passo 1, na ordem cronolgica decrescente, para garantir que o estado
resultante do banco de dados estar correto.
Aps desfazer todas as transaes da lista inutilizar, as transaes da lista refazer so refeitas.
importante, nesse caso, processar o log na ordem cronolgica crescente. Completado o processo de recuperao,
o processamento da transao reassumido.
Quando se usa o algoritmo precedente, importante inutilizar uma transao da lista inutilizar antes de
refazer transaes da lista refazer. De outra forma, o seguinte problema pode ocorrer. Suponha que o item de
dado A tenha inicialmente o valor 10. Suponha que uma transao Ti tenha atualizado o item de dado A para 20 e
depois foi abortada; a reverso da transao restauraria A para o valor 10. Suponha, ento, que outra transao Tj
tenha atualizado o item de dado A para 30 e tenha sido efetivada; em seguida, o sistema cai. O estado do log no
momento da queda :

Se o passo redo processado primeiro, A ser ajustado para 30; ento, no passo undo, A ser ajustado
para 10, o que est errado. O valor final de Q deveria ser 30, que podemos alcanar processando undo antes de
redo.
Gerenciamento de Buffer
Vamos considerar diversos detalhes sutis, embora essenciais, para a implementao de um esquema de
recuperao de queda que garanta consistncia de dados e imponha uma quantidade mnima de overhead
devido a interaes com o banco de dados.
Bufferizao de Registro de Log
Anteriormente, assumimos que qualquer registro de log enviado para a sada de armazenamento
estvel no momento em que criado. Essa situao impe grande overhead execuo do sistema pelas
seguintes razes. Normalmente, a sada para armazenamento estvel ocorre em unidades de blocos. Em muitos
casos, um registro de log muito menor que um bloco. Ento, a sada de cada registro de log se traduz em uma
sada muito maior no nvel fsico. Alm do mais a sada de um bloco para armazenamento estvel pode significar
vrias operaes de sada no nvel fsico.
O custo relativo ao processamento de uma sada de bloco para armazenamento estvel suficientemente
alto; melhor que saiam diversos registros de log de uma s vez. Para isso, escrevemos os registros de log em um
buffer de log na MP, onde permanecem temporariamente, at serem enviados para armazenamento estvel.
Mltiplos registros de log podem ser reunidos no buffer de log e enviados para armazenamento estvel em uma
nica operao de sada. A ordem dos registros de log no armazenamento estvel deve ser exatamente a mesma
na qual foram escritos no buffer de log.
Em consequncia do uso da bufferizao do log, um registro de log pode residir somente em MP
(armazenamento voltil) por um tempo considervel antes de ser enviado para a sada em armazenamento
estvel. J que tais registros de log so perdidos se os sistema cair, devemos impor exigncias adicionais s
tcnicas de recuperao para garantia de atomicidade da transao:
A transao Ti entra em estado de efetivao aps o registro de log <Ti commit> ter sido enviado para
sada em armazenamento estvel.
Antes do registro de log <Ti commit> sofrer armazenamento estvel, todos os registros de log
pertencentes transao Ti devero ter sido enviados para armazenamento estvel.
Antes de um bloco de dados na MP podem ser enviado para o banco de dados (em armazenamento novoltil), todos os registros de log pertencentes a dados naquele bloco devem ter sido enviados para
armazenamento estvel.

314

Antes de um bloco de dados na MP poder ser enviado para o banco de dados (em armazenamento novoltil), todos os registros de log pertencentes a dados naquele bloco devem ter sido enviados para
armazenamento estvel.
A ltima regra chamada de regra write-ahead logging (WAL). (Precedncia de escrita do log, a regra WAL exige
somente a informao undo no log tenha sido enviada para sada em armazenamento estvel, permitindo que a
informao redo seja escrita mais tarde. A diferena relevante em sistemas nos quais a informao redo e undo
armazenada em registros de log separados.)
Escrever o log bufferizado no disco s vezes chamado de forar o log (log force). As regras precedentes
criam situaes em que certos registros de log devem ser enviados para sada em armazenamento estvel. No
h problema decorrente do envio dos registros de log mais cedo que o necessrio. Logo, quando o sistema achar
necessrio enviar um registro de log para armazenamento estvel, ele enviar um bloco inteiro de registros de
log, se houver registros de log suficientes na MP para preencher um bloco. Se os registros de log forem
insuficientes na MP para preencher um bloco. Se os registros de logo forem insuficientes para preencher o bloco,
os registros de log na MP sero combinados a um bloco parcialmente completo e sero enviados para sada em
armazenamento estvel.

Bufferizao de Banco de Dados

J descrevemos a hierarquia de armazenamento em dois nveis. O banco de dados est armazenado em
armazenamento no-voltil (disco) e os blocos de dados so levados MP quando necessrio. J que a MP
normalmente muito menor que o banco de dados inteiro, pode ser necessrio sobrescrever um bloco B1 na MP
quando outro bloco B2 necessitar ser levado memria. Se B1 tiver sido modificado, ele dever ser enviado para o
banco de dados antes da entrada de B2. Essa hierarquia de armazenamento o conceito-padro de sistema
operacional de memria virtual.
As regras para a sada de registros de log limitam a liberdade do sistema para sada de blocos de dados. Se
a entrada do bloco B2 fizer com que o bloco B1 seja selecionado para a sada, todos os registros de log
pertencentes aos dados em B1 devem ser enviados para armazenamento estvel antes de B1 ser enviado para
sada. Ento, a sequncia de aes pelo sistema, seria como segue:
Enviar registros de log para armazenamento estvel at acabarem os registros de log pertencentes ao
bloco B1.
Enviar o bloco B1 para sada no disco.
Enviar o bloco B2 do disco para a entrada em MP.
importante que nenhuma gravao no bloco B1 esteja em progresso enquanto a sequncia precedente
de aes estiver em execuo. Essa condio satisfeita quando se usa um meio especial de bloqueio, como
segue. Antes que uma transao escreva um item de dado, ela deve adquirir um bloqueio exclusivo sobre o bloco
no qual o item de dados reside. O bloqueio poder ser liberado imediatamente aps a atualizao. Antes de um
bloco ser enviado para a sada, o sistema obtm um bloqueio exclusivo sobre o bloco, para garantir que nenhuma
transao o altere. Completada a sada do bloco, o bloqueio liberado. Os bloqueios que so mantidos por pouco
tempo so frequentemente chamados de trancas (latches). As trancas so tratadas de forma distintas dos
bloqueios usados pelo sistema de controle de concorrncia. Com isso, elas podem ser liberadas sem considerar
qualquer protocolo de bloqueio, como bloqueio em duas fases, exigido pelo sistema de controle de concorrncia.
Para ilustrar a necessidade da sequncia anterior de aes, consideremos nosso exemplo bancrio com as
transaes T0 e T1. Suponha que o estado do log seja:

e que a transao T0 emita uma read(B). Assuma que o bloco em que B reside no est na MP e que a MP esteja
completa. Suponha que o bloco em que reside A seja escolhido para ser enviado ao disco. Se o sistema envia esse
bloco para sada no disco e, ento, o sistema cai, os valores no banco de dados para as contas A, B e C so 950,
2000 e 700 dlares, respectivamente. Esse estado do banco de dados inconsistente. Entretanto, devido s
exigncias precedentes, o registro de log <T0, A, 1000, 950> dever ser enviado para armazenamento estvel
315

antes da sada do bloco em que A reside. O sistema pode usar o registro de log durante a recuperao para levar
o banco de dados de volta a um estado consistente.
Regra de Sistema Operacional em Gerenciamento de Buffer
Podemos gerenciar o buffer do banco de dados usando uma das duas abordagens:
1. O sistema de banco de dados reserva parte da MP para servir como um buffer gerenciado por ele, e no
pelo sistema operacional. O sistema de banco de dados gerencia a transferncia de bloco de dados, de
acordo com as exigncias que j discutimos.
Essa abordagem tem o inconveniente de limitar a flexibilidade de uso da MP. O buffer deve ser mantido
pequeno o suficiente para que outras aplicaes tenha MP suficiente para sua necessidades. Entretanto, mesmo
quando outras aplicaes no estiverem rodando, o banco de dados no poder fazer uso de todas a memria
disponvel. Da mesma forma, aplicaes que no sejam banco de dados podem no usar aquela parte da MP
reservada para o buffer de banco de dados, mesmo se algumas pginas no buffer do banco de dados no
estiverem em uso.
2. O sistema de banco de dados implementa seu buffer dentro da memria virtual do sistema operacional.
J que o sistema operacional possui informaes sobre as exigncias de memria de todos os processos
no sistema, idealmente ele deveria estar capacitado a decidir quais blocos de buffer devem ser forados
sada para o disco e quando isso deve ser feito. Mas, para atender precedncia de escrita do log que
discutimos, o sistema operacional no poderia escrever pginas de buffer no banco de dados por si s,
mas, ao contrrio, solicitar que o sistema de banco de dados forasse a sada dos blocos do buffer. O
sistema de banco de dados, por sua vez, s foraria a sada dos blocos do buffer para o banco de dados
aps escrever os registros de log relevantes em armazenamento estvel.
Infelizmente, quase todos os sistemas operacionais da gerao atual mantm controle completo sobre a
memria virtual. O sistema operacional reserva espao em disco para armazenar pginas de memria virtual que
no esto na MP; este espao chamado de espao de swap (troca). Se o sistema operacional decidir retirar da
memria um bloco Bx, ele ser enviado para o espao de swap no disco, e no h nenhuma forma do sistema de
banco de dados conseguir controle dessa sada de blocos do buffer.
No entanto, se o buffer de banco de dados estiver na memria virtual, as transferncias entre arquivos de
banco de dados e o buffer na memria virtual so gerenciadas pelo sistema de banco de dados, que cumprir as
exigncias de precedncia de escrita do log que discutimos.
Essa abordagem pode implicar sadas extras de dados para o disco. Se um bloco Bx retirado pelo sistema
operacional, esse bloco no ser enviado para o banco de dados. Ao contrrio, ele ser enviado para o banco de
dados. Quando o sistema de banco de dados tiver de enviar Bx para o disco, pode ser que o sistema operacional
tenha de, primeiro, retirar Bx de seu espao de swap. Ento, ao contrrio de uma nica sada de Bx da memria,
exigiremos duas sadas de Bx (uma pelo sistema operacional, e outra pelo sistema de banco de dados), alm de
uma entrada extra de Bx na memria.
Embora ambas as abordagens padeam de alguns inconvenientes, uma ou outra dever ser escolhida, a
menos que o sistema operacional seja projetado para aceitar as exigncias de log do banco de dados. Somente
uns poucos sistemas operacionais atuais, como o sistema operacional Mach, aceitam tais exigncias.
Falha com Perda de Armazenamento No-voltil
At agora, consideramos somente falhas que tm como consequncia a perda de informaes residentes
em armazenamento voltil; o contedo do armazenamento no-voltil permanece intacto. Embora as falhas com
perda de armazenamento no-voltil sejam raras, precisamos estar preparados para trata-las. Vamos discutir, por
enquanto, apenas armazenamento em disco. Nossas discusses se aplicam tambm a outros tipos de
armazenamento no-voltil.
O esquema bsico descarregar (dump) todo contedo do banco de dados para armazenamento estvel
periodicamente digamos, uma vez por dia. Por exemplo, podemos descarregar o banco de dados para uma ou
316

mais fitas magnticas. Se ocorrer uma falha que resulte na perda de blocos fsicos do banco de dados, a descarga
mais recente ser usada na restaurao do banco de dados para seu ltimo estado consistente possvel. Uma vez
completada essa restaurao, o sistema usa o log para trazer o sistema de banco de dados para um estado
consistente recente.
Mais precisamente, nenhuma transao pode estar ativa durante o procedimento de descarga, e um
procedimento similar para checkpoint (pontos de controle) deve ocorrer:
1. Enviar todos os registros de log residentes em MP para sada de armazenamento estvel.
2. Enviar todos os blocos de buffer para sada em disco.
3. Copiar o contedo do banco de dados em armazenamento estvel.
4. Enviar um registro de log <dump> para sada em armazenamento estvel.
Os passos 1, 2 e 4 correspondem aos trs passos usados para checkpoints anteriormente.
Para se recuperar da perda de armazenamento no-voltil, restauramos o banco de dados em disco
usando a descarga (dump) mais recente. O log , ento, consultado e todas as transaes que foram efetivadas
desde a ltima descarga so refeitas. Observe que nenhuma operao undo precisa ser executada.
Uma descarga do contedo do banco de dados tambm chamada de archival dump (descarga histrica),
j que podemos arquivar as descargas e us-las mais tarde para examinar informaes antigas do banco de
dados. Descargas de um banco de dados e checkpoints dos buffers so similares.
O procedimento de descarga simples aqui descrito oneroso pelas seguintes razes. Primeiro, todo o
banco de dados dever ser copiado em armazenamento estvel, resultando em considervel transferncia de
dados. Segundo, j que o processamento das transaes suspenso durante a descarga, ciclos de CPU so
perdidos. Tm sido desenvolvidos esquemas de fuzzy dump (descarga indistinta) que permitem a existncia de
transaes ativas enquanto a descarga est em progresso. So similares a esquemas de checkpoints.
Tcnicas de Recuperao Avanadas
As tcnicas de recuperao j descritas requerem que, enquanto uma transao atualizao um item de
dado, nenhuma outra transao consiga atualizar o mesmo item de dado, at que a primeira seja efetivada ou
revertida. Satisfazemos essa condio por meio do bloqueio em duas fases severo. Embora o bloqueio em duas
fases severo seja aceitvel para os registros de relaes ele causa um significativo decrscimo de concorrncia
quando aplicado a certas estruturas especiais, como pginas de ndice de rvore-B+.
Para aumentar a concorrncia, podemos usar o algoritmo de controle e de concorrncia rvore-B+
permitindo que os bloqueios sejam liberados mais cedo, sem usar duas fases. Como isso, entretanto, as tcnicas
de recuperao estudadas tornam-se inaplicveis. Vrias tcnicas de recuperao alternativas tm sido propostas
tornam-se inaplicveis. Vrias tcnicas de recuperao alternativas tm sido propostas, aplicveis mesmo com
liberao prematura de bloqueio. Descrevemos uma dessas tcnicas de recuperao agora.
Log com Undo Lgico
Para aes nas quais os bloqueios so liberados mais cedo, no podemos processar as aes undo
simplesmente regravando o valor antigo dos itens de dados. Considere uma transao T que insira uma entrada
em uma rvore-B+ e, seguindo o protocolo de controle de concorrncia rvore-B+, libere alguns dos bloqueios
aps o trmino da operao de insero, mas antes da transao ser efetivada. Aps a liberao dos bloqueios,
outras transaes podem realizar inseres ou remoes adicionais, causando desse modo mudanas adicionais
nas pginas da rvore B+.
Mesmo que a operao libere alguns dos bloqueios previamente, ela dever reter bloqueios suficientes
para garantir que no seja permitido a nenhuma outra transao executar qualquer operao conflitante (como
ler ou remover o valor inserido). Por essa razo, o protocolo de controle de concorrncia rvore-B+ mantm os
bloqueios no nvel de folha da rvore-B+ at o fim da transao.
Agora vamos considerar como processar os rollbacks de transaes. Se os valores antigos dos ns
internos da rvore-B+ (antes da operao de insero ser executada) forem restaurados durante a reverso da
317

transao, algumas das atualizaes processadas pelas ltimas operaes de insero ou excluso executadas por
outras transaes poderiam ser perdidas. Em vez disso, a operao de insero tem de ser inutilizada logicamente
isto , pela execuo de uma operao de remoo.
Portanto, quando a ao de insero for completada, antes de liberar qualquer bloqueio, ela dever
gravar um registro de log <Oi, operation-end, U>, em que U indica a informao de inutilizao e Oi indica um
identificador para a operao. Por exemplo, se a operao inseriu uma entrada em uma rvore-B+, a informao
undo U indicaria o que remover da rvore-B+. Esse log de informao sobre operaes chamado de log fsico e
os correspondentes registros de log so chamados de registros de log fsicos.
As operaes de insero e remoo so exemplos de uma classe de operaes que exige operaes undo
lgicas, j que liberam os bloqueios previamente; chamamos tais operaes de operaes lgicas. Antes que uma
operao lgica tenha incio, ela escreve um registro de log <Oi, operation-begin>, em que Oi o identificador
para a operao. Enquanto a operao est sendo executada, o log feito da maneira convencional para todas as
atualizaes processadas pela operao. Ento, as informaes usuais dos valores antigos e novos so escritos
para cada atualizao. Quando a operao termina, um registro de log de final de operao (operation-end)
escrito como explicado anteriormente.
Reverso de Transao
Vamos considerar primeiro a reverso de transaes durante operao normal (isto , no durante a
recuperao do sistema aps uma falha). O log examinado de trs para a frente (ordem cronolgica
decrescente) e os registros de log pertencente transao so usado para restaurar os valores antigos dos itens
de dados. Ao contrrio de antes, escrevemos registros especiais de log somente redo da forma <Ti, Xj, V> com o
valor V sendo sobreposto ao item de dado Xj durante a reverso. Esses registros de log algumas vezes so
chamados de registros de log de compensao. Sempre que um registro de log <Oi, operation-end, U>
encontrado, aes especiais so tomadas:
1. Revertemos a operao usando a informao undo U do registro de log. As atualizaes processadas
durante a reverso da operao so registradas no log exatamente da mesma forma que as atualizaes
processadas quando a operao foi executada primeiro. Alm do mais, registros de log referentes ao
incio e ao final da operao so gerados exatamente como durante a execuo normal da operao.
2. Quando a verificao retroativa do log continua, saltamos todos os registros de log da transao at
encontrados o registro de log <Oi, operation-begin>. Aps o registro de log de incio da operao ser
encontrado, os registros de log da transao so processados novamente de maneira usual.
Quando a transao Ti for revertida, um registro <Ti abort> ser adicionado ao log.
Se ocorrerem falhas enquanto uma operao lgica est em progresso, o registro de logo de fim de
operao para aquela operao no ser encontrado quando a transao for revertida. Entretanto, para cada
atualizao processada pela operao, a informao undo na forma do valor antigo nos registros de log fsicos
est disponvel no log. Observe que saltar os registros de log fsicos, quando o registro de log de fim de operao
encontrado durante a reverso, garante que os valores antigos do registro de log fsico no sejam usados na
reverso, uma vez que a operao terminou.
Se o bloqueio usado para controle de concorrncia, os bloqueios mantidos por uma transao T podem
ser liberados somente aps a transao tiver sido revertida, conforme descrito.
Checkpoints
Os checkpoints so processados conforme j descrito. Atualizaes no banco de dados so
temporariamente suspensas e as seguintes aes so executadas:
1. Enviar para sada em armazenamento estvel todos os registros de log residentes na memria principal.
2. Enviar para sada em armazenamento estvel um registro de log <checkpoint L>, em que L uma lista de
todas as transaes ativas.
3. Enviar para sada em disco todos os blocos de buffer modificados.
318

Recuperao de Reincio
As aes de recuperao, quando o sistema de banco de dados reiniciado aps uma falha, so
executadas em duas fases:
1. Na fase redo, reexecutamos as atualizaes de todas as transaes pela varredura do log avanando a
partir do ltimo checkpoint. Os registros de log que sero reexecutados englobam os registros de log das
transaes que foram revertidas antes do sistema cair e aquelas que no foram efetivas quando ocorreu
a queda do sistema. Os registros de log reexecutados incluem os registros de log usuais da forma <Ti, Xj,
V1, V2> e os registros de log especiais da forma <Ti, Xj, V2>; o valor V2 escrito para o item de dados Xj em
qualquer caso. Essa fase tambm determina todas as transaes que esto na lista de transaes no
registro de checkpoint ou que foram iniciadas mais tarde, mas no tm nenhum registro <Ti abort> ou <Ti
commit> no log. Todas essas transaes tm de ser revertidas e seus identificadores de transao so
colocados em uma lista undo.
2. Na fase undo, refazemos todas as transaes da lista undo. Processamos a reverso reexaminando o log
do final para o comeo. Sempre que um registro de log pertencente a uma transao da lista undo
encontrado, as aes undo so processadas exatamente como se o registro de log fosse encontrado
durante a reverso de uma transao que falhou. Ento, os registros de log de uma transao anteriores a
um registro final de operao, mas aps o correspondente registro de incio de operao, so ignorados.
Quando um registro de log <Ti start> encontrado para uma transao Ti na lista undo, um registro de log
<Ti abort> escrito no log. O exame do log para quando registros de log <Ti start> so encontrados para todas as
transaes na lista undo.
A fase redo da recuperao de reincio reexecuta todos os registros de log fsico, a partir do mais recente
registro de checkpoint. Em outras palavras, essa fase de recuperao de reincio repete todas as aes de
atualizao que foram executadas aps o checkpoint e cujos registros de log alcanaram log estvel. Essas aes
incluem as transaes incompletas e as aes executadas para reverter transaes com falha. As aes so
repetidas na mesma ordem em que foram executas; consequentemente, esse processo chamado de histria
repetitiva (repeating history). A histria repetitiva simplifica enormemente os esquemas de recuperao.
Fuzzy Checkpoint
A tcnica checkpoint descrita exige que todas as atualizaes ao banco de dados sejam temporariamente
suspensas enquanto o checkpoint est em progresso. possvel modificar a tcnica para permite que as
atualizaes iniciem no momento em que o registro checkpoint escrito, mas antes dos blocos de buffer
modificados serem escritos no disco. Ento, o checkpoint gerado um fuzzy checkpoint (ponto de controle
indistinto).
A ideia a seguinte. Em vez de reexaminar o log de trs para frente a fim de encontrar um registro de
checkpoint, armazenamos a localizao em log do ltimo registro de checkpoint em uma posio fixa no disco.
Entretanto, essa informao no atualizada quando o registro checkpoint escrito. Ao contrrio, antes do
registro checkpoint ser escrito, uma lista com todos os blocos de buffer modificados criada. A informao ltimo
checkpoint atualizada somente aps todos os blocos de buffer, da lista de blocos de buffer modificados, terem
sido escritos no disco. O protocolo de precedncia de escrita do log deve ser seguido quando os blocos de buffer
so enviados para sada.
Observe que, em nosso esquema, o registro de log lgico usado somente para propsitos de undo, ao
passo que o registro de log fsico usado para propsitos redo (refazer) e undo (inutilizar). H esquemas de
recuperao que usam registro de log lgico para propsitos redo. Entretanto, tais esquemas no podem ser
usados com fuzzy checkpoint e, portanto, no so muito empregados.

319