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. Begin transaction Read(Cta=x, saldo) Saldo = saldo - 100 (valor informado) Write(cta=x, saldo) end transaction 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). UPDATE CONTA SET saldo = saldo - 100 WHERE nro_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.
Captulo 1: Gerncia de Transaes

-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).

Captulo 1: Gerncia de Transaes

-5-

Banco de Dados II

Aes da Aplicao
Begin Transaction (BOT)

Aes do Gerente de Transaes

Inicia aes padro para UNDO. Garantia de atomicidade da TA

Seqncia de operaes DML associadas a RIs End of Transaction (EOT)

Execuo das operaes DML e teste de Ris imediatas, com mensagem de erro 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 Ps-Graduao 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.

Captulo 1: Gerncia de Transaes

-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 T3

T2
T1 T2

T3
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 T2 read(x) x=x+100 write(x) 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

Captulo 2: Controle de Concorrncia

-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
C E

Matriz de Compatibilidade de Bloqueios:

Captulo 2: Controle de Concorrncia

-9-

Banco de dados II
C E X 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) T2 lock_E(x) espera ... ... ... lock_E(x) x=x+100 write(x) unlock(x)

x=x-1 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: fase de aquisio (growing phase): nesta fase a transao apenas adquire os bloqueios;
Captulo 2: Controle de Concorrncia
- 10 -

Banco de dados II

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 read(x) x=x+100 write(x) commit write(x) read(y) y=y+10 write(y) commit write(x) lock_E(y) read(y) y=y+10 write(y) commit unlock(x,y) T1 Lock_E(x) x=x-10 T2 lock_E(x) espera ... ... ... ... ... ... ... ... ... continua ...

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 Bsico

2PL Estrito

2PL Conservativo

BOT

EOT

BOT

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 transaes tero se baseado em um dado intermedirio levando a uma inconsistncia do banco de dados.

Captulo 2: Controle de Concorrncia

- 11 -

Banco de dados II

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.

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.
Captulo 2: Controle de Concorrncia
- 12 -

Banco de dados II

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
2.4 Granularidade Mltipla

T2

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;
Captulo 2: Controle de Concorrncia
- 13 -

Banco de dados II

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

A1

A2

Arq a

Arq b

Arq c

ra1

...

ran

rb1

...

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; 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;
Captulo 2: Controle de Concorrncia
- 14 -

Banco de dados II

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 CI EI C CEI E V V V V F

EI V V F F F

C V F V F F

CEI V F F F F

E F F F F F

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) 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:
Captulo 2: Controle de Concorrncia
- 15 -

Banco de dados II

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.
Bibliografia utilizada no captulo: [BER 87] BERNSTEIN, Philip A; HADZILACOS, Vassos; GOODMAN, Nathan. Concurrency Control and Recovery in Database Systems. Reading:Addison-Wesley, 1987. [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 Ps-Graduao 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.

Captulo 2: Controle de Concorrncia

- 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. 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). Falha de transao: erro detectado pela prpria transao. Exemplo: overflow, diviso por zero, violao de proteo de memria. Qual o meio de

Os meios de armazenamento podem ser divididos em:

Com relao s falhas podemos caracterizar trs tipos bsicos:

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> <Ti, nome arquivo, id-registro, atributo, valor antigo, valor novo> <Fim Ti>
Captulo 4: Segurana em SGBDs
- 18 -

Banco de dados II

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> <fim T3> <incio T5> <T4, Conta, c9, 500, 600> <Inicio T6>
Captulo 4: Segurana em SGBDs
- 19 -

Banco de dados II

<T5, Conta, c5, 100, 260> <fim T5> <T2, Conta, c7, 700, 850> <T6, Conta, c8, 200, 550> Supondo que a tcnica de modificao imediata do banco de dados esteja sendo utilizada: a) que aes devem ser realizadas pelo subsistema de recovey caso ocorra: 1) uma falha da transao T4; 2) uma falha de sistema; b) se houvesse um registro de checkpoint imediatamente aps o registro <incio T4>, que aes deveriam ser realizadas se ocorresse uma falha de sistema? 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, pode-se 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; um registro de checkpoint gravado no arquivo de LOG: <checkpoint <t1, t2, ..., tn>>

Bibliografia utilizada no captulo:

Captulo 4: Segurana em SGBDs

- 20 -

Banco de dados II
[BER 87] BERNSTEIN, Philip A; HADZILACOS, Vassos; GOODMAN, Nathan. Concurrency Control and Recovery in Database Systems. Reading:Addison-Wesley, 1987. [SIL 99] SILBERSCHATZ, Abraham.; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. 3 edio., So Paulo: Makron Books, 1999.

Captulo 4: Segurana em SGBDs

- 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 deix-las 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.

Captulo 4: Segurana em SGBDs

- 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.
GRANT SELECT, UPDATE ON FUNCIONARIO TO PEDRO;

Captulo 4: Segurana em SGBDs

- 23 -

Banco de dados II

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

Usurio 3

Tabela A

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;

Captulo 4: Segurana em SGBDs

- 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.

Captulo 4: Segurana em SGBDs

- 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. 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

Exemplos:

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

Captulo 6: Restries de Integridade

- 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). no podem suportar operaes de insert, update e delete
CREATE VIEW ConsPac (codp,totcons) AS SELECT codp, count(*) FROM consultas GROUP BY codp

Situao 2: viso que relaciona o total de consultas de um determinado paciente

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.

Captulo 6: Restries de Integridade

- 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) >= esal(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 )

Existem ainda as restries de integridade prprias do contexto da aplicao. Essas podem ser especificadas atravs de:
Anexos
- 31 -

Banco de dados II
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 Cdigo objeto de programas

Processador de consulta Gerenciador de Banco de Dados

Compilador de DDL Gerenciador Dicion.Dados

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 Autorizao de Acesso Verificao de Integridade Processador de Comandos Gerente de Transaes Gerente de Buffers Otimizador de Consultas Scheduler Gerenciador Dicion.Dados

Gerente de Dados

Gerente de Recuperao Falhas

Gerenciador de Arquivos

Banco de Dados e Dicionrio de Dados

Anexos
- 34 -