Apostila - BDII-5

Banco de Dados II
Profa MSc. Tanisi Carvalho

Profa MSc. Simone Vicari
Notas de Aula
Banco de dados II
Sumrio
1 GERNCIA DE TRANSAES...................................................................................................................3
1.1 PROPRIEDADES DA TRANSAO.................................................................................................................4
1.2 ESTADOS DA TRANSAO...........................................................................................................................4
2 CONTROLE DE CONCORRNCIA...........................................................................................................7
2.1 PROBLEMAS ASSOCIADOS EXECUO CONCORRENTE DE TAS................................................................8
2.2 MECANISMOS PARA CONTROLE DE CONCORRNCIA..................................................................................9
2.2.1 Bloqueio simples.................................................................................................................................9
2.2.2 Bloqueio de Duas Fases (2PL).........................................................................................................10
2.3 DEADLOCK.................................................................................................................................................12
2.3.1 Preveno de Deadlock.....................................................................................................................12
2.3.2 Deteco e Recuperao de Deadlock..............................................................................................13
2.4 GRANULARIDADE MLTIPLA....................................................................................................................13
3 RECUPERAO APS FALHAS..............................................................................................................17
3.1 PROJETO DE UM SUBSISTEMA DE RECOVERY...........................................................................................17
3.2 PROCEDIMENTOS PARA RECUPERAO DE FALHAS BASEADOS EM LOG................................................18
3.2.1 Checkpoints.......................................................................................................................................20
4 SEGURANA EM SGBDS..........................................................................................................................22
4.1 AUTORIZAO DE ACESSO........................................................................................................................23
4.1.1 Criando usurios...............................................................................................................................23
4.1.2 Concedendo/Revogando privilgios de acesso.................................................................................23
4.1.3 Roles..................................................................................................................................................24
4.1.4 Sinnimos..........................................................................................................................................25
5 VISES..........................................................................................................................................................26
5.1 USO DE VISES..........................................................................................................................................27
5.2 PROBLEMAS ASSOCIADOS S VISES........................................................................................................28
6 RESTRIES DE INTEGRIDADE...........................................................................................................29
6.1 CLASSIFICAO DAS RESTRIES DE INTEGRIDADE................................................................................29
6.1.1 Segundo seu alcance.........................................................................................................................29
6.1.2 Segundo o momento do teste.............................................................................................................29
6.1.3 RIs que regulamentam a atualizao de valores...............................................................................29
6.1.4 RIs que devem ser testadas na ocorrncia de eventos externos.......................................................30
6.2 RESTRIES DE INTEGRIDADE NO MODELO RELACIONAL.......................................................................30
6.2.1 Restrio de domnio........................................................................................................................30
6.2.2 Restrio de valor nulo (NULL).......................................................................................................31
6.2.3 Restrio de chave primria.............................................................................................................31
6.2.4 Restrio de integridade referencial.................................................................................................31
6.3 ESPECIFICAO DE RESTRIES DE INTEGRIDADE...................................................................................31
7 ANEXOS.........................................................................................................................................................33
7.1 ARQUITETURA BSICA DE UM SGBD.......................................................................................................33
7.2 ARQUITETURA DO GERENCIADOR DE BANCO DE DADOS.........................................................................34
Banco de dados II
1 Gerncia de Transaes
Um conceito bastante importante no contexto de sistemas gerenciadores de banco de
dados (SGBDs) o conceito da transao:
A transao uma unidade de trabalho do usurio (da aplicao) que atmica
do ponto de vista da aplicao [DAT 81]
A transao uma unidade de execuo de programa que acessa e,
possivelmente, atualiza vrios itens de dados. Geralmente, o resultado da execuo de
um programa escrito em uma linguagem de manipulao de dados de alto nvel ou em
uma linguagem de programao (por exemplo, SQL, COBOL, C ou Pascal) [SIL 99]
A partir dos dois conceitos acima importante definir que:
a transao sempre leva o banco de dados de um estado inicial consistente a

um outro final, tambm consistente;
a transao atmica, ou seja, a transao deve ser tratada pelo SGBD como
uma unidade nica, ou todas as alteraes devem estar no BD ou nada deve
acontecer.
Normalmente, as transaes definidas em linguagens de manipulao apresentam

comandos para marcar o incio e o fim da transao (begin transaction/end transaction).
A Figura 1. 1 -1 apresenta um exemplo de uma transao que retira R$ 100,00 de uma
Conta Bancria. A Figura 1. 1 -2 apresenta o mesmo exemplo em SQL.
Begintransaction
Read(Cta=x,saldo)
Saldo=saldo100(valorinformado)
Write(cta=x,saldo)
endtransaction
Figura 1.1-1: Exemplo de transao
Como pode ser observado na Figura 1. 1 -2, no aparece o comando de incio de
transao. O padro SQL92 define que uma transao inicia a partir do primeiro
comando SQL, todos os comandos subseqentes so considerados da mesma transao
at que seja encontrado um comando de fim de transao (COMMIT ou ROLLBACK).
UPDATECONTA
SETsaldo=saldo100
WHEREnro_conta=x;
COMMIT;
Figura 1.1-2: Exemplo de transao em SQL
Captulo 1: Gerncia de Transaes
Banco de Dados II
1.1 Propriedades da Transao

Para garantir a integridade do banco de dados necessrio que o sistema de banco
de dados mantenha as seguintes propriedades da transao:
Atomicidade: o programa que representa a transao deve, ou executar por

completo e com sucesso sobre o banco de dados, ou deve parecer nunca ter
executado (Lei do Tudo-Ou-Nada). Essa propriedade , normalmente, garantida
pelo SGBD, atravs de seu componente de recuperao aps falhas;
Consistncia: a transao s pode realizar operaes corretas, do ponto e vista da
aplicao, sobre o banco de dados. Isto , a transao no pode transgredir
qualquer restrio de integridade (RI) declarada ao SGBD (restries de
integridade de chave primria e restries de integridade de chave estrangeira.
Isolamento: em um ambiente multiusurio (multiprogramado), a execuo de
uma transao no deve ser influenciada pela execuo de outras. Essa
propriedade , normalmente, garantida pelo SGBD, atravs do mdulo de
Controle de Concorrncia (scheduler);
Durabilidade: os resultados de uma transao que termina com sucesso devem
permanecer inalterados, no banco de dados, at que outra transao os altere e
tambm termine com sucesso. Isto , os resultados de transaes que terminam
com sucesso devem sobreviver a falhas ( de transao, de sistema ou de meio de
armazenamento. A Durabilidade tambm garantida pelo componente de
recuperao aps falhas.
As transaes que seguem estas quatro propriedades so tambm conhecidas como

transaes ACID.
1.2 Estados da Transao

Uma transao pode concluir sua execuo com sucesso ou no. Quando uma
transao no conclui com sucesso, a propriedade da atomicidade deve ser garantida, isso
significa que todas as modificaes feitas sobre o banco de dados, por essa transao,
devem ser desfeitas (rollback). Se, no entanto, a transao conclui com sucesso seus
efeitos esto materializados no banco de dados e ela dita committed.
Podemos dizer que uma transao, ao longo da sua execuo, passa por vrios
estados:
ativa: o estado inicial, uma transao fica nesse estado enquanto estiver
executando;
em efetivao: aps a execuo da ltima declarao;
em falha: aps a descoberta de que a execuo normal no poder se realizar;
abort: depois que a transao foi desfeita e o banco de dados foi restabelecido ao
estado anterior ao incio da execuo da transao;
commit: aps a concluso com sucesso da transao.
A Figura 1 .3 apresenta o diagrama de estados correspondente a uma transao.
-4
-
Banco de Dados II
Em
efetivao
Commit
Ativa
Em
Falha
Abort
Figura 1.3: Diagrama de Estados da Transao

Enquanto uma transao estiver executando ela estar no estado ativa. No momento
em que a transao concluir a execuo da ltima declarao ela entra no estado de
efetivao. Uma transao no vai direto para o estado de commit, porque o SGBD
precisa concluir uma srie de operaes como, por exemplo, atualizar arquivos de log,
atualizar o banco de dados, para garantir as propriedades de atomicidade e durabilidade.
O estado de efetivao uma preparao para o commit. Pode ocorrer que durante esse
estado ocorra alguma falha e a transao no possa ser concluda normalmente. Nessa
situao, a transao passa de um estado de efetivao para um estado em falha onde
todos os efeitos da transao devero ser desfeitos. Uma transao passar para o estado
de commit quando todas as operaes necessrias estiverem concludas. A partir desse
momento a aplicao teria conhecimento de que a transao realmente concluiu. O
estado abort se dar quando uma vez detectada a falha o estado do banco de dados,
anterior falha, tenha sido estabelecido.
A Figura 1 .4 apresenta um esquema mostrando a relao existente entre o
programa de aplicao e a execuo de uma transao pelo SGBD (Gerente de
Transaes).
-5
-
Banco de Dados II
Aes da Aplicao
Aes do Gerente
de Transaes
Begin
Transaction
(BOT)
Inicia aes padro

para UNDO. Garantia de
atomicidade da TA
Seqncia de operaes
DML associadas a RIs
Execuo das operaes DML

e teste de Ris imediatas, com
mensagem de erro
End of
Transaction
(EOT)
Teste de Ris Postergadas

com mensagem de erro e
UNDO
Aes padro para REDO.
Garantia de durabilidade
Avisa aplicao/usurio
do final da TA
Figura 1.4: Aes da Aplicao x Aes do Gerente de Transaes

Uma transao comea a executar quando uma instruo Begin Transaction
encontrada. O gerente de transaes deve ento executar um conjunto de aes para
garantir a atomicidade de uma transao no caso de uma falha. A aplicao continua
executando as suas operaes. estas operaes so processadas pelo SGBD, as restries
de integridade associadas so testadas. A aplicao envia a declarao de fim de
Transao. A partir desse momento a transao est em estado de efetivao, o SGBD
testa as restries de integridade postergadas, que s podem ser testadas no fim,
executada as aes de REDO para garantir a durabilidade e, por fim, envia um aviso a
aplicao de que a transao foi concluda com sucesso. Nesse ponto, a transao passa a
ser commit e seus efeitos esto materializados no banco de dados. No caso de uma falha,
o sistema precisa executar um conjunto de operaes para garantir a atomicidade e a
transao abortada.
Bibliografia utilizada no captulo:
[BER 87] BERNSTEIN, Philip A; HADZILACOS, Vassos; GOODMAN, Nathan. Concurrency Control
and Recovery in Database Systems. Reading:Addison-Wesley, 1987.
[DAT 81] DATE, Chris. J. An Introduction to Database Systems. Reading:Addison-Wesley, 1983, p. 112123.
[IOC 95] IOCHPE, Cirano. Notas de Aula CMP97 Sistemas de Banco de Dados. Curso de PsGraduao em Cincia da Computao, 1995.
[SIL 99] SILBERSCHATZ, Abraham.; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados.
3 edio., So Paulo: Makron Books, 1999.
-6
-
Banco de dados II
2 Controle de Concorrncia
O controle de concorrncia a atividade de coordenar a ao de processos que
operam em paralelo, acessam dados compartilhados e, portanto, interferem uns com os
outros.
Quando duas ou mais transaes executam concorrentemente, suas operaes podem
ser processadas, pelo sistema de computao, de forma intercalada (interleaving). A
Figura 2 -3 apresenta um exemplo da execuo serial das transaes T1, T2 e T3 e da
execuo interleaving das mesmas transaes.
T1
T1
T2
T2
T3
T1
T3
T2
T1
tempo
Figura 2-3: Exemplos de execues das transaes T1, T2 e T3

A execuo concorrente das transaes permite um melhor aproveitamento dos
recursos do sistema. A execuo de uma transao geralmente envolve operaes de E/S
liberando o uso da CPU, tornando-a ociosa. Esse tempo de CPU pode ser destinado
execuo de outra transao. A idia central manter em paralelo o processamento da
E/S e da CPU melhorando, assim, o throughput do sistema (nmero de transaes
executadas por unidade de tempo).
Um outro aspecto que em um sistema podem existir transaes longas e transaes
curtas. Se a execuo for seqencial, ento pode ocorrer da transao curta ter que
aguardar pela transao longa acarretando em um tempo de resposta maior (tempo que
uma transao leva para comear a responder solicitao realizada). A Figura 2 -3
apresenta um exemplo dessa situao, a transao T3 tem que aguardar a execuo de T1
e T2; j na execuo interleaving, o tempo de T3 melhorado.
Na Figura 2 -4 temos a arquitetura do SGBD do ponto de vista de gerncia de
transaes:
gerente de transaes: executa as operaes do banco de dados e das

transaes, passando-as para o scheduler;
scheduler: controla a ordem da execuo das operaes read, write, commit e
abort de diferentes transaes que so executadas, garantindo o isolamento. As
aes do scheduler podem ser: executar, rejeitar ou postergar a operao que
chega para o scheduler;
Captulo 2: Controle de Concorrncia
-7-
Banco de dados II
gerente de recuperao: responsvel pela finalizao das transaes (garante a

atomicidade e a durabilidade);
gerente de buffers: armazena parte do banco de dados em memria durante a
execuo das transaes. responsvel pela tansferncia dos dados entre o
disco e memria principal.
T1
T2
T3
....
Tn
Gerente de
Transaes
Scheduler
Gerente de Dados
Gerente de
Recuperao
Falhas
Gerente de
Buffers
Banco de Dados
/LOG
Figura 2-4 Gerncia de Transaes
2.1 Problemas associados execuo concorrente de TAs

Quando se tem transaes executando concorrentemente pode-se levar o banco de
dados a um estado inconsistente.
Problemas que podem existir sem um mecanismo de controle de concorrncia:
Atualizao perdida: ocorre quando uma atualizao de uma transao
sobreescrita pela atualizao de outra transao, fazendo com que uma delas seja
perdida;
a) execuo serial
T1
read(x)
x=x-10
write(x)
read(y)
Y=y+10
write(y)
commit
b) execuo no serial
T1
T2
read(x)
x=x-10
read(x)
x=x+100
write(x)
Commit
write(x)
read(y)
y=y+n
write(y)
commit
T2
read(x)
x=x+100
write(x)
commit

-8-
Banco de dados II
TAs no recuperveis:
Uma transao no pode se basear em dados de uma transao que ainda no foi
efetivada (princpio da recuperabilidade).
T3
read(x)
x=x-10
write(x)
T4
read(x)
x=x+100
write(x)
commit
read(y)
rollback
T4 considerou T3
concluda com
sucesso o que
no
verdadeiro!!!
2.2 Mecanismos para Controle de Concorrncia

Os mecanismos de controle de concorrncia tm por objetivo permitir a
concorrncia garantido o princpio da serializabilidade. Sero estudados trs
implementaes de mecanismos de controle de concorrncia:
marcas de tempo (timestamp);

verses.
bloqueios (locking);
2.2.1 Bloqueio simples

Consiste em estabelecer bloqueios sobre o dado a ser acessado pela transao, de
modo a restringir o acesso a este dado.
A unidade de bloqueio, geralmente, a de registro. Quanto menor for a
granularidade de bloqueio, maior o grau de concorrncia.
So definidos dois tipos de bloqueios:
Exclusivo (E): se uma transao obteve um bloqueio E em um dado, ento a

transao pode ler e escrever neste dado.
Compartilhado (C): se uma transao obteve um bloqueio C em um dado, esta
transao e as demais podem somente ler este dado
Matriz de Compatibilidade de Bloqueios:

-9-
Banco de dados II
C
E
E
X
X
Quando uma transao Ti deseja acessar um dado, ela deve primeiro bloque-lo com
um dos dois tipos de bloqueio, dependendo da operao desejada. Se o dado j est
bloqueado com tipo incompatvel, Ti precisa esperar at que todos os bloqueios
incompatveis sejam liberados.
To logo o dado deixe de ser utilizado o bloqueio deve ser liberado.
T1
lock_E(x)
read(x)
x=x-1
write(x)
unlock(x)
T2
lock_E(x)
espera
...
...
...
lock_E(x)
x=x+100
write(x)
unlock(x)
Um dos problemas associados a este protocolo o fato dos bloqueios serem

liberados muito cedo. Observe o exemplo abaixo:
T3
T4
sum=0
lock_C(x)
read(x)
unlock(x)
sum=sum+x
lock_C(y)
lock_E(x)
x=x-10
write(x)
unlock(x)
commit
read(y)
unlock(y)
sum-sum+y
O protocolo de bloqueio simples no garante o isolamento por completo. No

exemplo acima, caso T4 seja abortada T3 foi efetivada com valores de x que no
existiram no banco de dados (atomicidade para T4).
2.2.2 Bloqueio de Duas Fases (2PL)
O mecanismo de bloqueio de duas fases (Two-Phase Lock), garante a
serializabilidade tratando os bloqueios em duas fases:
- 10 -
Banco de dados II
fase de aquisio (growing phase): nesta fase a transao apenas adquire os

bloqueios;
fase de liberao (shrinking phase): nesta fase a transao somente libera
bloqueios. A partir do momento que o primeiro bloqueio liberado nenhum
bloqueio pode ser adquirido pela transao.
O Strict 2PL garente execues concorrentes serializveis, recuperveis, evita o
cascating abort e liberando os bloqueios apenas no commit ou rollback.
O mecanismo funciona de forma anloga ao mecanismo de bloqueios simples,
diferenciando-se apenas pela forma como so tratadas a aquisio e a liberao de
bloqueios.
T1
read(x)
x=x-10
T2
T1
Lock_E(x)
x=x-10
T2
read(x)
x=x+100
write(x)
commit
write(x)
read(y)
y=y+10
write(y)
commit
lock_E(x)
espera
...
...
...
...
...
...
...
...
...
continua ...
write(x)
lock_E(y)
read(y)
y=y+10
write(y)
commit
unlock(x,y)
A implementao do mecanismo 2PL tem algumas variaes conforme mostra a

Figura 2 -5. As variaes caracterizam-se pela forma como so implementadas as fases
de aquisio e liberao de bloqueios.
2PL Estrito
2PL Bsico
BOT
EOT
BOT
2PL Conservativo
EOT
BOT
EOT
Figura 2-5: Variaes do mecanismo 2PL

Na verso 2PL Bsico, os bloqueios so liberados medida que a transao deixa de
utiliz-los. Isso pode acarretar num problema conhecido como aborto em cascata
(cascading abort). Uma vez que o bloqueio foi liberado, este dado pode ser utilizado por
qualquer outra transao, assim se a transao no concluir com sucesso, outras

- 11 -
Banco de dados II
transaes tero se baseado em um dado intermedirio levando a uma inconsistncia do

banco de dados.
A implementao estrita resolve esta situao liberando os bloqueios apenas no final
e em um momento nico, garantindo com isso que o problema de aborto em cascata no
ocorra. Esta implementao pode ter ainda uma otimizao, permitindo que os bloqueios
compartilhados sejam liberados deixando apenas os bloqueios exclusivos. A
implementao estrita a mais utilizada comercialmente.
Uma caracterstica dos protocolos baseados em bloqueios so as situaes de
impasse (deadlocks). Uma situao de impasse ocorre quando uma transao est a
espera de um dado que est bloqueado por uma segunda transao e esta est a espera de
um dado segurado pela primeira. As situaes de deadlock so indesejveis, pois
degradam o desempenho. Este assunto ser detalhado na prxima sesso.
A implementao conservativo evita que o deadlock ocorra, pois solicita todos os
dados de antemo. Esta abordagem, no entanto, tende a diminuir o throughput do
sistema, visto que uma transao no vai utilizar todos os dados ao mesmo. Alm disso,
difcil saber quais dados sero utilizados por uma transao. Esta implementao pode
levar a outro problema conhecido como postergao definida, situao em que uma
transao fica a espera de um evento que nunca venha a ocorrer.
Uma outra caracterstica dos protocolos de bloqueios que alguns sistemas
permitem iniciar o bloqueio como compartilhado e depois passar este bloqueio para o
modo exclusivo (lock upgrade/downgrade). A vantagem disso que pode-se retardar a
aquisio de bloqueios no modo exclusivo, permitindo assim um maior grau de
concorrncia. Tanto para o upgrade ou downgrade a matriz de compatibilidade de
bloqueios deve ser obedecida. Isso pode acarretar em situaes de deadlock.
2.3 Deadlock
Uma situao que pode ocorrer em sistemas concorrentes conhecida por impasse
ou deadlock (abrao mortal). O deadlock est associado a utilizao de recursos
compartilhados que s podem ser utilizados de forma exclusiva, no caso de banco de
dados, os dados utilizados pelas transaes.
Um sistema est em deadlock sempre que uma transao Ti est esperando por um
item de dado que est bloqueado por uma transao Tj e Tj est esperando por um item
de dado que est bloqueado por Ti.
H dois mtodos para resolver um deadlock:
utilizar alguma tcnica que evite a sua ocorrncia;

possuir mecanismos para deteco e recuperao de deadlock.

- 12 -
Banco de dados II
2.3.1 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 bloqueio, ou pela aquisio de
todos os bloqueios juntos. A outra faz com que a transao seja refeita, em vez de esperar
por um bloqueio, sempre que a espera possa potencialmente decorrer em deadlock.
Pela primeira abordagem, cada transao obrigada a bloquear todos os itens de
dados antes de sua execuo. Alm disso, ou todos os dados so bloqueados de uma s
vez ou nenhum ser. H duas desvantagens nesse protocolo: a dificuldade de prever,
antes da transao comear, quais itens de dados devero ser bloqueados. Segundo, a
utilizao do item de dado pode ser bastante reduzida j que os dados podem ser
bloqueados e no ser usados por um longo perodo de tempo.
Pela segunda, so utilizados timeouts para decidir se uma transao deve ficar em
wait ou deve ser refeita (REDO). Se o tempo de espera ultrapassar um valor x, a
transao abortada independente de ter ocorrido o deadlock ou no.
2.3.2 Deteco e Recuperao de Deadlock
As tcnicas de deteco e recuperao so utilizadas quando o subsistema de
controle de concorrncia no possui nenhum mecanismo de preveno de deadlock.
Normalmente a deteco feita pela gerao de um grafo de espera, onde a ocorrncia de
ciclos indica a presena de deadlock.
Para recuperar do deadlock necessrio que uma ou mais transaes sejam
selecionadas como vtimas para serem abortadas. Para a seleo das vtimas podem ser
utilizados critrios como, por exemplo, a transao mais recente, o quanto falta para uma
transao terminar, quantas atualizaes a transao realizou ou at mesmo nenhum
critrio (por facilidades de implementao).
Um problema decidir quando o algoritmo de deteco deve ser acionado. Se os
intervalos forem curtos, muito overhead. Se forem intervalos longos, pode-se levar muito
tempo para verificar que um deadlock ocorreu.
Grafo de espera:
criado um n para cada transao do sistema

se Ti est esperando por um dado utilizado por Tj, criada uma borda Ti Tj
quando o dado liberado, a borda removida
ocorre um dealock quando o grafo contiver um ciclo
T1
T2
- 13 -
Banco de dados II
2.4 Granularidade Mltipla

Os exemplos de bloqueios apresentados at agora se referiam a bloquear um registro
por vez. Existe, porm, situaes em que vantajoso bloquear diversos itens de dados,
tratando-os como uma unidade de acesso do que bloquear um registro. Por exemplo:
atualizao de todos os dados de um arquivo;
leitura de todos os dados do banco de dados;
Nessas situaes mais interessante bloquear todo o arquivo, pois em uma nica
solicitao todo o arquivo estar bloqueado e o tempo necessrio para realizar os bloqueios
(de cada registro) evitado. Em contrapartida, se a transao necessita de apenas um
registro, bloquear todo o arquivo desnecessrio e, tambm, elimina a concorrncia.
importante, ento, que o sistema permita definir mltiplos nveis de
granularidade de bloqueio. A granularidade de bloqueio , ento, a poro de itens de
dados que pode ser bloqueada por uma transao. As granularidades mais usuais so:
registro (tupla);
pgina;
arquivo (tabela).
Isso pode ser implementado atravs de uma rvore de granularidade, onde cada
nodo representa a poro de dados (gro) que est sendo bloqueada e existe uma hierarquia
entre os nodos. Observe a Figura 2 -6:
BD
A2
A1
Arq a
ra1
...
Arq b
ran
rb1
...
Arq c
rbn
rc1
...
rcn
Figura 2-6: rvore de Granularidades

Um banco de dados (BD) pode ser dividido em reas (A). Cada rea pode ser
dividida em um ou mais arquivos e cada arquivo possui um ou mais registros.
Princpio do bloqueio de gros:
quando uma transao bloqueia um determinado gro (ou nodo), ela bloqueia
tambm todos os nodos filhos deste gro no mesmo modo de bloqueio;
- 14 -
Banco de dados II
quando uma transao bloqueia um gro, todos os seus ancestrais devem ser
bloqueados intencionalmente no mesmo modo de bloqueio.
Modos de bloqueio:
compartilhado (C): o nodo e toda a sua subrvore esto bloqueados

explicitamente no modo compartilhado;
exclusivo (E): o nodo e toda a sua subrvore esto bloqueados explicitamente
no modo exclusivo;
compartilhado intencional (CI): um nodo com este bloqueio significa que
algum bloqueio compartilhado explcito est sendo mantido na sua subrvore;
exclusivo intencional (EI): um nodo com este bloqueio significa que algum
bloqueio exclusivo explcito est sendo mantido na sua subrvore;
compartilhado e exclusivo intencional (EI): um nodo est bloqueado
explicitamente no modo compartilhado e algum nodo na sua subrvore est
bloqueado explicitamente no modo exclusivo;
CI
EI
CEI
CI
EI
CEI
Regras:
1) respeitar a matriz de compatibilidade dos modos de bloqueio
2) a raiz da rvore precisa ser bloqueada primeira e pode ser bloqueada em
qualquer modo
3) um nodo n pode ser bloqueado por Ti no modo C ou CI apenas se os pais de n
esto correntemente bloqueados por Ti no modo EI ou CI
4) Um nodo n pode ser bloqueado por Ti no modo E, CEI, ou EI apenas se os pais
de n esto correntemente bloqueados por Ti no modo EI ou CEI
5) Ti pode bloquear um nodo apenas se ele no desbloqueou nenhum nodo antes
(segue a tcnica de bloqueio de duas fases)
- 15 -
Banco de dados II
6) Uma Ti pode desbloquear um nodo apenas se nenhum dos filhos estiver

bloqueado por Ti.
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).
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 d eum arquivo ou de um
conjunto de arquivos.
Os seguintes fenmenos podem ocorrer:

leitura suja (dirty reads): ocorre quando uma transao tem acesso aos dados
modificados por uma transao que ainda no concluiu, ou seja, a transao est
acessando dados intermedirios.
Leituras no repetidas (Nonrepeatable Read): A TA faz a mesma consulta em
vrios momentos e encontra valores diferentes que foram modificados ou deletados.
Leitura fantasma (Phantom reads): A TA faz a mesma consulta com uma
determinada condio que retorna um conjunto de valores, esta mesma consulta
executada novamente e retorna mais linhas, que foram adicionadas por TAs commited e
que satisfazem a condio.
[CON 98] CONNOLLY, Thomas; BEGG, Carolyn. Database Systems a practical approach to design,
implementation and management. Harlow:Addison-Wesley, 1998.
[IOC 95] IOCHPE, Cirano. Notas de Aula CMP97 Sistemas de Banco de Dados. Curso de PsGraduao em Cincia da Computao, 1995.

- 16 -
Banco de dados II
3 Recuperao Aps Falhas

Diversas falhas podem ocorrer em um sistema de computador como, por exemplo,
queda de energia, falha na unidade de armazenamento fsico, falha no programa de
aplicao. Tais falhas podem tornar os dados armazenados no banco de dados
inconsistentes, fazendo com que testes e procedimentos sejam incorporados ao SGBD
para tratamento dessas falhas. O mdulo do SGBD responsvel por essa tarefa
chamado de recuperao aps falhas ou recovery.
O objetivo do subsistema de recovery levar o banco de dados a um estado
consistente aps uma falha que o tenha deixado em um estado no consistente. Para que
isso ocorra, todo o sistema de recovery est baseado na redundncia de informaes.
Essa redundncia normalmente obtida a partir das seguintes hierarquias de
armazenamento:
Arquivos de log: correspondem a arquivos que mantm um histrico das

transaes executadas. Contm as informaes necessrias para reconstruir o
estado mais recente do database buffer e, normalmente, esto armazenados em
disco. Suporta falhas de sistema;
Archive log: uma cpia de um estado consistente do banco de dados. Suporta
falhas de mdia (disco). armazenado em discos ou fitas magnticas.
Arquivos de backup: correspondem s cpias de segurana. Podem estar
armazenadas em disco ou fita magntica e armazenam o contedo de um banco
de dados consistente em um dado perodo do tempo.
3.1 Projeto de um Subsistema de Recovery

O projeto de um subsistema de recovery deve levar em considerao:
Meios de armazenamento de dados;

Tipos de falhas e como estas falhas afetam a integridade dos dados
armazenados;
Procedimentos para recuperao destas falhas.
Os meios de armazenamento podem ser divididos em:
Meio de armazenamento voltil: caracteriza-se pela perda dos contedos

armazenados em caso de falta de energia. Por exemplo, a memria principal;
Meio de armazenamento no voltil (fsico): caracteriza-se por manter o
contedo armazenado, mesmo em caso de falta de energia. Exemplo: memria
secundria (discos e fitas magnticas).
Com relao s falhas podemos caracterizar trs tipos bsicos:
Falha de transao: erro detectado pela prpria transao. Exemplo: overflow,

diviso por zero, violao de proteo de memria. Qual o meio de
Captulo 4: Segurana em SGBDs
- 17 -
Banco de dados II
armazenamento comprometido? Nenhum! Qual a ao a ser executada?

Desfazer a transao.
Falha de sistema: interrupo do sistema. Exemplo: queda de luz, falha no
sistema operacional. Meio de armazenamento comprometido: voltil. Ao:
desfazer as transaes em execuo no momento da falha que no foram
concludas.
Falha no meio fsico: perda total ou parcial do meio fsico. Exemplo: falha no
cabeote de gravao do disco, erro de hardware. Meio de armazenamento
comprometido: fsico. Aes: acionar a ltima cpia de segurana e refazer
transaes executadas com sucesso aps a ltima cpia.
A partir dos tipos de falhas acima apresentados possvel identificar quatro aes a
serem implementadas pelo mecanismo de recovery:
transaction UNDO: desfaz os efeitos de uma nica transao, garantindo a

atomicidade (ou a transao concluda com sucesso e seus efeitos so
materializados no banco de dados, ou como se a transao nunca tivesse
existido); - Falha de Transao
global UNDO: desfaz os efeitos de todas as transaes atualmente sendo
executadas, garantindo a atomicidade de um conjunto de transaes; - Falha de
sistema
partial REDO: refaz os efeitos de um conjunto de transaes que terminaram
com sucesso (committed), os quais talvez no tenham sido salvos no BD;
garante durabilidade - Falha de sistema
global REDO: refaz os efeitos de um conjunto de transaes que terminaram
com sucesso (committed), independente do meio onde estes efeitos estejam
armazenados. Falha de disco
A implementao das operaes acima depende, no entanto, da forma como alguns

aspectos do SGBD so implementados. Quatro aspectos devem ser analisados:
tipo de propagao dos dados: como os dados so transferidos do buffer de

dados para o banco de dados;
gerncia dos buffers: como determinar que buffers de dados sero liberados para
outros dados;
tratamento de EOT (end-of-transaction): quando uma transao termina com
sucesso que tratamento recebem os dados que ainda esto nos buffers de dados;
checkpoints: tcnica utilizada para reduzir o esforo de recovery. Alguns
sistemas permitem sua implementao.
3.2 Procedimentos para Recuperao de Falhas Baseados em

LOG
Periodicamente realizada uma cpia do banco de dados. Cada mudana feita no
banco de dados por uma transao fica registrada no arquivo de LOG (histrico).
A estrutura do LOG composta por trs registros:
<Incio Ti>
- 18 -
Banco de dados II
<Ti, nome arquivo, id-registro, atributo, valor antigo, valor novo>

<Fim Ti>
No caso de uma falha, executado o seguinte algoritmo:

1. Aloca duas listas: lista-UNDO e lista-REDO
2. Percorre o arquivo de LOG do fim para o incio at chegar ao primeiro
registro de checkpoint, examinando cada registro:
2.1.
se achou <Fim Ti>, adiciona Ti na lista-REDO
2.2.
se achou <Inicio Ti> e Ti no est na lista-REDO, adiciona Ti na
lista-UNDO
3. Quando se chega ao registro checkpoint, para cada transao Ti na lista de
transaes desse registro:
3.1.
se Ti no estiver na lista-REDO, ento adiciona Ti na lista-UNDO
4. Percorre o arquivo de LOG do fim para o incio:
4.1.
realizando UNDO(Ti) para todas as transaes Ti existentes na
lista-UNDO
4.2.
marcando na lista-REDO as transaes Ti cujos registros <Incio
Ti> esto sendo encontrados nessa varredura
5. caso todas as transaes existentes na lista-UNDO tenham sido desfeitas e
ficou alguma transao Ti no marcada na lista-REDO;
5.1.
continua percorrendo o arquivo de LOG para trs at que todos os
registros <Inicio Ti> das transaes no marcadas na lista-REDO
tenham sido encontradas
6. Percorre o arquivo de LOG para a frente, realizando REDO(Ti) para todas as
transaes existentes na lista-REDO.
Esse algoritmo evita a varredura e a verificao de todas as transaes existentes em todo o

arquivo de LOG. A operao de REDO deve ser idempotente, ou seja, a execuo do
REDO(Ti) diversas vezes deve ser equivalente a execut-la apenas uma nica vez!
Exemplo: Suponha um ambiente bancrio multiusurio e um arquivo de LOG com as
seguintes informaes num dado instante:
<incio T1>
<T1, Conta, c1, 1000, 500>
<incio T2>
<incio T3>
<T2, Conta, c2, 3000, 3500>
<fim T1>
<incio T4>
<T3, Conta, c3, 1500, 1200>
<T2, Conta, c6, 500, 100>
<T4, Conta, c8, 200, 0>
- 19 -
Banco de dados II
<fim T3>
<incio T5>
<T4, Conta, c9, 500, 600>
<Inicio T6>
<T5, Conta, c5, 100, 260>
<fim T5>
<T2, Conta, c7, 700, 850>
<T6, Conta, c8, 200, 550>
Supondoqueatcnicademodificaoimediatadobancodedadosestejasendo
utilizada:
a)queaesdevemserrealizadaspelosubsistemaderecoveycasoocorra:
1)umafalhadatransaoT4;
2)umafalhadesistema;
b)sehouvesseumregistrodecheckpointimediatamenteapsoregistro<incioT4>,
queaesdeveriamserrealizadasseocorresseumafalhadesistema?
Antes da transao ser efetivada no banco de dados, ela deve estar gravada no LOG
fsico (WAL Write Ahead Log).
Como as modificaes realizadas pela transao esto armazenadas no LOG, podese retardar o momento em que as mesmas sero transferidas para o banco de dados como,
por exemplo, no momento da seleo de uma vtima. Em caso de falha de sistema,
necessrio fazer o partial redo para recuperar as transaes committed no momento da
falha e o global undo para desfazer o efeito das transaes que no haviam sido
concludas.
No segundo caso, as modificaes realizadas por uma transao so efetivadas no
banco de dados no momento em que a transao est sendo executada (imediato). O
procedimento WAL continua valendo, ou seja, primeiro a informao armazenada no
arquivo de log. A implementao da poltica force pode gerar problemas no
processamento de transao, pois o overhead no sistema maior.
3.2.1 Checkpoints
Checkpoints so pontos de verificao que garantem que at aquele ponto os
contedos dos buffers de LOG e do banco de dados foram descarregados nos respectivos
meios fsicos. Os checkpoints so executados periodicamente pelo sistema de recovery e
tem por objetivo reduzir o esforo de recovery.
Os seguintes passos so executados quando da ocorrncia de um checkpoint:
o buffer de LOG descarregado para o arquivo de LOG;

o buffer de dados descarregado para o banco de dados fsico;

- 20 -
Banco de dados II
um registro de checkpoint gravado no arquivo de LOG: <checkpoint <t1,

t2, ..., tn>>


- 21 -
Banco de dados II
4 Segurana em SGBDs
O termo segurana, em banco de dados, refere-se proteo do banco de dados
contra acessos intencionais ou no intencionais utilizando controles baseados em
computador ou no [CON 98]
So considerados acessos intencionais aqueles realizados propositadamente, por
exemplo, um usurio do sistema cede sua senha a pessoas no autorizadas. Acessos no
intencionais so aqueles que, ao ocorrer, causam algum tipo de perda (por exemplo, perda
da consistncia do banco de dados ou perda de informao), mas no foram propositados.
Exemplo, queda de energia que corrompe o banco de dados.
Segundo [CON 98], o contexto de segurana pode ser analisado segundo as
seguintes situaes:
roubo e fraude de informao;
perda de confiabilidade;
perda de privacidade;
perda de integridade;
perda de disponibilidade.
Os controles que podem ser implementados podem ser baseados em computador ou
no. Os controles no baseados em computador geralmente esto associados a polticas e
planos de segurana estabelecidos pela organizao. Exemplo: poltica para cesso de
contas de usurios, os usurios devem trocar suas senhas mensalmente e no devem deixlas registradas em locais de fcil acesso.
Os controles baseados em computador so agrupados nas seguintes categorias:
autorizao: refere-se a concesso de um direito ou de um privilgio a um
usurio (ou a um programa) a acessar legitimamente o sistema ou um objeto do
sistema;
vises: um mecanismo que permite estabelecer pores de dados que podem
ser visualizados por um determinado usurio (ou programa);
backup e recuperao de falhas: refere-se ao mecanismos necessrios para
garantir a disponibilidade do sistema em caso de falhas;
integridade: refere-se aos controles que contribuem para manter a segurana do
sistema evitando que dados invlidos sejam registrados no sistema (ver
Captulo 2);
criptografia: refere-se codificao dos dados a partir de um algoritmo
especial que torna os dados impossibilitados de serem lidos sem que se tenha a
chave de criptografia. Esse tpico no faz parte do escopo da disciplina;
auditorias: tem por objetivo verificar os acessos que so realizados sobre o
sistema e observar se os acessos realizados seguem as polticas de segurana
propostas. Esse tpico no faz parte do escopo da disciplina.

- 22 -
Banco de dados II
4.1 Autorizao de Acesso

Os mecanismos de autorizao envolvem duas abordagens: autenticao e
autorizao de acesso. A primeira tem por objetivo verificar se o usurio que tenta acessar o
sistema quem realmente diz ser. Em SGBDs, a autenticao realizada atravs de senhas
embora este recurso no seja totalmente garantido. O mecanismo de autorizao permite
conceder privilgios para cada um dos objetos aos usurios. Desse modo, apenas os
usurios que tm privilgio sobre o objeto podem acess-lo.
Em SQL existe um conjunto de comandos DDL que permite criar usurios e
conceder privilgios.
4.1.1 Criando usurios
Os usurios so criados pelo administrador do sistema (DBA) e, geralmente, o
administrador do sistema que concede os privilgios que esse usurio ter.
Exemplo:
CREATE USER ALUNO IDENTIFIED BY ALUNOSENHA;
A execuo do comando acima criar um usurio chamado ALUNO, cuja senha

ALUNOSENHA.
4.1.2 Concedendo/Revogando privilgios de acesso
O fato de criar um usurio no significa que ele ter acesso aos objetos do sistema.
Em SQL, para que um usurio tenha acesso aos objetos do esquema ele deve receber,
explicitamente, esse privilgio. Caso ele deixe de ter acesso aos objetos do esquema, os
direitos devero ser revogados, tambm, explicitamente.
Quem pode conceder/revogar privilgios? A resposta o proprietrio do esquema j
que, inicialmente, apenas ele tem conhecimento da existncia do objeto.
Que privilgios podem ser concedidos/revogados? Em SQL, os privilgios que
podem ser atribudos a objetos so:
SELECT: permite recuperar dados de uma tabela;

INSERT: permite inserir novas tuplas em uma tabela;
UPDATE: permite modificar tuplas de uma tabela;
DELETE: permite remover tuplas de uma tabela;
EXECUTE: permite executar uma stored procedure;
REFERENCES: permite referenciar colunas de uma tabela j existente (de outro esquema) em
restries de integridade.
O comando SQL para conceder privilgios a um usurio GRANT.

Sintaxe:
GRANT <privilgios> ON <nome tabela ou viso> TO <usurios>;
Exemplo: autorizao de leitura e atualizao dos atributos da tabela Funcionrio

para o usurio Pedro.
- 23 -
Banco de dados II
GRANT SELECT, UPDATE ON FUNCIONARIO TO PEDRO;
Para revogar privilgios:

REVOKE <privilgios> ON <nome tabela ou viso> FROM <usurios>;
Exemplo: retirar a autorizao de atualizao sobre a tabela Funcionrio do usurio

Pedro.
REVOKE UPDATE ON FUNCIONARIO FROM PEDRO;
4.1.3 Roles
Como voc pode observar, para cada objeto do esquema deve ser definido quais
usurios tero direito sobre ele e que tipo de direito tero. Alguns SGBDs oferecem alguns
recursos para facilitar a administrao do sistema, as roles. Uma role (papel) consiste de um
conjunto de privilgios que so definidos sobre uma tabela e que podem ser atribudas a um
usurio, facilitando a tarefa de concesso de privilgios.
Usurio 1
Usurio 2
Tabela A
Usurio 3
Tabela B
Figura 5-7: Usurios e privilgios sobre tabelas

A vantagem na utilizao de roles que se novas tabelas precisam ser
acrescentadas, basta atribuir isso a role criada e todos os usurios passaro a ter esse
privilgio. Alm disso, se um novo usurio acrescentado ao sistema, necessrio atribuir
a ele apenas a role apropriada.
O uso de roles muito similar ao uso dos privilgios. Primeiro de tudo necessrio
criar a role. Exemplo, definir um papel (role) que permita a recuperao de dados e a
atualizao de dados da tabela Funcionrio e atribuir ao usurio Pedro:
CREATE ROLE RL_FUNCIONARIO;
Criada a role, atribui-se a ela os privilgios sobre os objetos:

GRANT SELECT, UPDATE ON FUNCIONARIO TO RL_FUNCIONARIO;
Finalmente, atribui-se a role ao usurio;

GRANT RL_FUNCIONARIO TO PEDRO;

- 24 -
Banco de dados II
Usurio 1
Usurio 2
Usurio 3
Role
Tabela A
Tabela B
Figura 5-8: Usurios, privilgios sobre tabelas e roles

Tambm possvel atribuir uma role a outra role. Por exemplo, se agora fosse
criada uma role RL_DEPENDENTES que permite selecionar, inserir e atualizar
Dependentes de um Funcionrio e que o usurio Pedro pode executar essas operaes.
Pode-se fazer isso de duas formas:
GRANT RL_FUNCIONARIO, RL_DEPENDENTES TO PEDRO;
GRANT RL_DEPENDENTES TO RL_FUNCIONARIO;
4.1.4 Sinnimos
Um outro recurso oferecido pelo SGBD ORACLE o de sinnimo. Um sinnimo
tem por objetivo oferecer transparncia no acesso aos objetos. Quando um objeto
acessado por um usurio que no o proprietrio ele deve ser referenciado pelo
[nome_do_proprietrio.nome_do_objeto].
O sinnimo cria um apelido para um objeto:
CREATE PUBLIC SYNONYM FUNCIONARIO FOR RH.FUNCIONARIO;
Foi criado um sinnimo pblico para a tabela Funcionrio, que pertence ao esquema
RH, chamado Funcionrio. A partir da criao do sinnimo todos os usurios que tiverem
privilgio sobre a tabela Funcionrio podero referenci-la como Funcionrio, apenas.
Esse captulo apresentou alguns recursos que so oferecidos pelo SGBD Oracle,
mas que podem estar presentes em outros SGBDs, tambm. Embora alguns desses recursos
no estejam previstos na linguagem SQL, estes ainda assim foram apresentados para que
voc faa uma melhor utilizao do SGBD nos exerccios prticos.

- 25 -
Banco de dados II
5 Vises
As tabelas criadas em um banco de dados relacional tm existncia fsica dentro do
sistema de computao. Algumas vezes, porm, necessrio criar tabelas que no
ocupem espao fsico, mas que possam ser utilizadas como as tabelas normais. Essas
tabelas so chamadas de vises ou tabelas virtuais, pois no existem por si, mas parecem
ao usurio como se fossem. Vises so, ento, relaes virtuais derivadas das relaes do
banco de dados.
Uma viso definida utilizando a instruo create view. Para definir uma viso
necessrio definir um nome e estabelecer uma consulta. Em SQL a sintaxe :
create view <nome da viso> as <expresso da consulta>
Onde:
<expresso da consulta> qualquer expresso de consulta legal da lgebra

relacional;
<nome da viso> o nome da tabela virtual.
A definio de uma viso armazenada no dicionrio de dados (catlogo) do

sistema. Para o usurio, no entanto, como se tivesse sido criada uma nova tabela no
banco de dados.
A viso criada dita dinmica, pois todas as modificaes que forem executadas
sobre a tabela origem (da qual a viso foi derivada) se refletiro sobre a mesma.
Assim como as tabelas, as vises tambm podem ser removidas:
drop view <nome da viso>
A viso especificada eliminada (isto , sua definio removida do dicionrio de

dados) e todas as vises definidas em termos desta viso tambm so automaticamente
anuladas.
Exemplos:
CREATE VIEW DadosPac AS
SELECT cod_pac, nome
FROM Pacientes
DROP VIEW DadosPac
Uma vez definida a viso, o nome pode ser usado para referenciar a relao virtual
que a viso gera. Nomes de vises podem aparecer em qualquer lugar em que um nome
de relao possa aparecer.
Captulo 6: Restries de Integridade

- 26 -
Banco de dados II
5.1 Uso de vises

Podemos ressaltar as seguintes vantagens na utilizao das vises:
pode-se preparar o terreno para usurios casuais que no entendem de

processamento de dados, e aos quais no se deseja entrar nos detalhes de
comandos SQL mais complexos;
pode-se simplificar consultas criando vises com as consultas mais comuns
que envolvem muitas tabelas;
permitem que um mesmo dado seja visto por diferentes usurios de diferentes
formas (ao mesmo tempo);
na segurana de dados, isto , a limitao do acesso por parte das pessoas
indesejveis. Para isso, pode-se criar uma viso e fornec-la como relao
existente para esses usurios, porm com a ocultao de dados. Por exemplo,
pode-se criar uma viso com os dados apenas dos funcionrios que ganham
menos do que 5000, ou apenas dos funcionrios do departamento de
Informtica (usando uma juno com Departamentos e Funcionrios, por
exemplo). Essas restries de acesso podem ser divididas em geral nas
restries do acesso apenas a algumas colunas inteiras de uma ou mais relaes
ou a apenas algumas de suas linhas, ou um misto de ambas.
Exemplos:
uso na segurana de acesso (autorizao): Um funcionrio do hospital no deve

ter acesso a todos os dados pessoais de um paciente, somente ao seu cdigo e
nome:
CREATE VIEW DadosPac AS
SELECT cod_pac, nome
FROM Pacientes
para simplificar consultas: Pode ser interessante vincular os dados de um

mdico aos dados de suas consultas.
CREATE VIEW MedCons AS
SELECT nome, to_char(data_hora,dd/mm/yy hh24:mi:ss)
FROM Medico, Consultas
WHERE medico.cod_med=consultas.cod_med
Operaes realizadas sobre uma viso se refletem diretamente sobre as tabelas

fsicas das quais ela deriva.
Exemplos:
a)
o funcionrio do hospital deseja buscar o nome de todos os pacientes cadastrados que

comeam com a letra R.
SELECT nome
FROM DadosPac
Where nome LIKE R%
buscar a data das consultas do mdico Pedro
SELECT data_hora
FROM MedCons
WHERE nome = Pedro

- 27 -
Banco de dados II
5.2 Problemas associados s vises

Vises so mecanismos teis para simplificar consultas dos bancos de dados, mas
modificaes do banco de dados atravs de vises tm potencialmente conseqncias
desvantajosas.
Exemplos:
Situao 1: Insero de tuplas na viso MedCons. Problemas:
violao da regra de integridade de entidade (no tenho o cdigo do mdico e

do paciente);
perde-se os relacionamentos entre mdicos e consultas (algumas consultas no
teriam resultados satisfatrios).
Situao 2: viso que relaciona o total de consultas de um determinado paciente
no podem suportar operaes de insert, update e delete

CREATE VIEW ConsPac (codp,totcons) AS
SELECT codp, count(*)
FROM consultas
GROUP BY codp
Vises so interessantes para facilitar consultas e estabelecer nveis de segurana.

Entretanto, modificaes utilizando vises podem gerar problemas devido possibilidade
de envolver vrias tabelas e do fato de que uma viso pode apresentar apenas alguns
atributos da relao, impossibilitando a realizao de modificaes sobre a mesma.
No possvel implementar vises atualizveis que envolvam funes de agregao
como, por exemplo, GROUP BY, CONNECT BY, DISTINCT.

- 28 -
Banco de dados II
6 Restries de Integridade
As restries de integridade so regras que determinam as operaes vlidas sobre o
banco de dados, mantendo a consistncia dos dados armazenados. Por operaes vlidas
entende-se aquelas operaes que mantm a relao entre o mundo real (do usurio ou da
aplicao) e a sua representao no banco de dados. Pode-se dizer que existe um
mapeamento das regras existentes no mundo real para o banco de dados
A partir da definio, por parte do usurio, dos estados corretos e das transies de
estado corretas, o SGBD deve garantir que o banco de dados reflita somente estes estados e
que as operaes sobre o banco de dados reflitam somente estas transies.
Alguns exemplos de restries de integridade:
a) em campos do tipo numrico caracteres no so permitidos (com exceo do
ponto decimal);
b) um aluno no pode estar matriculado na mesma disciplina, mais de uma vez, no
mesmo semestre;
c) pela CLT, um funcionrio no pode ter o seu salrio rebaixado.
No primeiro exemplo, a restrio de integridade definida em mais baixo nvel,
sendo vlida para qualquer aplicao. No segundo e terceiro exemplo, as restries de
integridade so definidas em mais alto nvel e dependem da aplicao.
6.1 Classificao das Restries de Integridade

6.1.1 Segundo seu alcance
Refere-se ao volume de informao associada RI
a) atinge um nico atributo de uma relao;
b) atinge mais de um atributo da mesma tupla;
c) atinge mais de uma tupla do mesmo tipo (mesma relao);
d) atinge duas ou mais tuplas que podem ser de tipos diferentes (relaes
diferentes).
6.1.2 Segundo o momento do teste
a) instantnea: sempre que o dado associado RI for inserido ou atualizado, a RI
deve ser testada;
b) postergada: a RI s pode ser testada aps uma srie de operaes sobre o banco
de dados (tpico em RI que atingem mais de uma tupla).
6.1.3 RIs que regulamentam a atualizao de valores
Referem-se a RIs baseadas em verses de valores de dados e RIs que levam em
conta a relao (valor_antigo, valor_novo).
Anexos
- 29 -
Banco de dados II
Exemplo 1: o salrio do empregado no pode ser rebaixado e-sal(novo_valor) >=

e-sal(valor_atual)
Exemplo 2: as transies do estado civil do empregado devem respeitar o seguinte
grafo de precedncias:
VIVO
SOLTEIRO
CASADO
SEPARADO
DIVORCIADO
Figura 7-9: Exemplo de Restrio de Integridade

6.1.4 RIs que devem ser testadas na ocorrncia de eventos externos
O momento do teste da RI determinado pela aplicao.
Exemplo: a partir de trs meses de sua data de ingresso na empresa, o salrio do
empregado deve refletir o salrio bsico estipulado para sua funo (piso salarial da
categoria).
6.2 Restries de Integridade no Modelo Relacional

No modelo relacional as restries de integridade podem ser agrupadas da seguinte
forma:
restrio de domnio;
restrio de valor nulo (NULL);
restrio de chave primria;
restrio de integridade referencial..
6.2.1 Restrio de domnio

So a forma mais elementar de restries de integridade. Especificam valores que
podem ser definidos para um atributo, tambm esto associadas aos tipos de dados.
Exemplos de domnios:
Telefones: conjunto de nmeros vlidos dentro de um determinado cdigo de rea;

Notas: valores entre 0 e 10,0;
CEP: conjunto de CEPs do Brasil vlidos;
Sexo: valores Me F;
Tipos de dados: caractere, numrico, data.
Anexos
- 30 -
Banco de dados II
6.2.2 Restrio de valor nulo (NULL)

A restrio de valor nulo probe a insero do valor nulo para um atributo. til
para evitar que valores nulos sejam especificados para atributos onde se deseja obrigar que
o dado seja informado. Em SQL, esta restrio implementada a partir da clusula NOT
NULL.
6.2.3 Restrio de chave primria
A restrio de chave primria refere-se ao fato da chave ser identificador nico em
uma tupla do banco de dados. A chave primria fundamental para o modelo relacional
uma vez que os valores da chave primria so utilizados como referncias s tuplas
identificadas por eles.
Quando uma relao apresenta mais de uma chave, cada uma delas uma chave
candidata. A chave primria aquela escolhida dentre as candidatas. Alm disso, a chave
primria no pode ter valor nulo.
6.2.4 Restrio de integridade referencial
Representa referncias de uma relao para outra, isto , o relacionamento existente
entre tuplas. Com isso, assegura-se que um valor que aparece em uma relao A, para um
dado conjunto de atributos, aparece tambm para um certo conjunto de atributos, na outra
relao relao B.
Se uma relao inclui uma chave estrangeira, ento o valor desta chave s pode ser:
nulo ou
igual a algum valor na relao onde ela chave primria.
6.3 Especificao de Restries de Integridade

Em SQL, as restries de integridade de chave primria e referencial podem ser
especificadas na prpria clusula CREATE TABLE.
CREATE TABLE Empregados
(cod_func NUMBER
restrio de domnio
CONSTRAINT pk_cod_func PRIMARY KEY restrio de chave primria
CONSTRAINT ck_cod_func CHECK (cod_func BETWEEN 1 AND 999),
restrio de domnio
nome VARCHAR220) NOT NULL, restrio de campo nulo
salario NUMBER(7,2),
idade NUMBER(2),
estado_civil NUMBER CONSTRAINT ck_estado_civil
CHECK (estado_civil IN (1, 2, 3, 4,5)), restrio de domnio
cod_depto CONSTRAINT fk_cod_depto REFERENCES Departamento(cod_depto)
restrio de chave estrangeira
)
Anexos
- 31 -
Banco de dados II
Existem ainda as restries de integridade prprias do contexto da aplicao. Essas

podem ser especificadas atravs de:
clusula ASSERT;
TRIGGERS.
Anexos
- 32 -
Banco de dados II
7 ANEXOS
7.1 Arquitetura Bsica de um SGBD
Programadores
Usurios
DBA
Programas de
Aplicao
Consultas
Esquema do
Banco de Dados
Pr-processador
de DML
Processador
de consulta
Compilador
de DDL
Gerenciador de
Banco de Dados
Gerenciador
Dicion.Dados
Cdigo objeto
de programas
SGBD
Gerenciador
de Arquivos
Anexos
- 33 -
Banco de dados II
7.2 Arquitetura do Gerenciador de Banco de Dados

Cdigo objeto
de programas
Processador
de consulta
Gerenciador
Dicion.Dados
Autorizao
de Acesso
Verificao
de Integridade
Gerente de Dados
Processador de
Comandos
Otimizador de
Consultas
Gerente de
Transaes
Scheduler
Gerente de
Buffers
Gerente de
Recuperao
Falhas
Gerenciador
de Arquivos
Banco de Dados e
Dicionrio de Dados
Anexos
- 34 -

Apostila - BDII-5

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - BDII-5

Enviado por

Direitos autorais:

Formatos disponíveis

Banco de Dados II

Profa MSc. Tanisi Carvalho

a transao sempre leva o banco de dados de um estado inicial consistente a

Normalmente, as transaes definidas em linguagens de manipulao apresentam

1.1 Propriedades da Transao

Atomicidade: o programa que representa a transao deve, ou executar por

As transaes que seguem estas quatro propriedades so tambm conhecidas como

1.2 Estados da Transao

Figura 1.3: Diagrama de Estados da Transao

Captulo 1: Gerncia de Transaes

Inicia aes padro

Execuo das operaes DML

Teste de Ris Postergadas

Figura 1.4: Aes da Aplicao x Aes do Gerente de Transaes

Captulo 1: Gerncia de Transaes

Figura 2-3: Exemplos de execues das transaes T1, T2 e T3

gerente de transaes: executa as operaes do banco de dados e das

gerente de recuperao: responsvel pela finalizao das transaes (garante a

Figura 2-4 Gerncia de Transaes

2.1 Problemas associados execuo concorrente de TAs

Captulo 2: Controle de Concorrncia

2.2 Mecanismos para Controle de Concorrncia

marcas de tempo (timestamp);

2.2.1 Bloqueio simples

Exclusivo (E): se uma transao obteve um bloqueio E em um dado, ento a

Matriz de Compatibilidade de Bloqueios:

Captulo 2: Controle de Concorrncia

Um dos problemas associados a este protocolo o fato dos bloqueios serem

O protocolo de bloqueio simples no garante o isolamento por completo. No

fase de aquisio (growing phase): nesta fase a transao apenas adquire os

A implementao do mecanismo 2PL tem algumas variaes conforme mostra a

Figura 2-5: Variaes do mecanismo 2PL

Captulo 2: Controle de Concorrncia

transaes tero se baseado em um dado intermedirio levando a uma inconsistncia do

utilizar alguma tcnica que evite a sua ocorrncia;

Captulo 2: Controle de Concorrncia

2.3.1 Preveno de Deadlock

criado um n para cada transao do sistema

2.4 Granularidade Mltipla

atualizao de todos os dados de um arquivo;

leitura de todos os dados do banco de dados;

Figura 2-6: rvore de Granularidades

compartilhado (C): o nodo e toda a sua subrvore esto bloqueados

6) Uma Ti pode desbloquear um nodo apenas se nenhum dos filhos estiver

Transaes curtas que mantm acesso em poucos itens de dados;

Os seguintes fenmenos podem ocorrer:

Captulo 2: Controle de Concorrncia

3 Recuperao Aps Falhas

Arquivos de log: correspondem a arquivos que mantm um histrico das

3.1 Projeto de um Subsistema de Recovery

Meios de armazenamento de dados;

Os meios de armazenamento podem ser divididos em:

Meio de armazenamento voltil: caracteriza-se pela perda dos contedos

Com relao s falhas podemos caracterizar trs tipos bsicos:

Falha de transao: erro detectado pela prpria transao. Exemplo: overflow,

armazenamento comprometido? Nenhum! Qual a ao a ser executada?

transaction UNDO: desfaz os efeitos de uma nica transao, garantindo a

A implementao das operaes acima depende, no entanto, da forma como alguns

tipo de propagao dos dados: como os dados so transferidos do buffer de

3.2 Procedimentos para Recuperao de Falhas Baseados em

<Ti, nome arquivo, id-registro, atributo, valor antigo, valor novo>

No caso de uma falha, executado o seguinte algoritmo:

Esse algoritmo evita a varredura e a verificao de todas as transaes existentes em todo o

o buffer de LOG descarregado para o arquivo de LOG;