Académique Documents
Professionnel Documents
Culture Documents
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
As transaes que seguem estas quatro propriedades so tambm conhecidas como transaes ACID.
-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
Begin Transaction (BOT)
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.
-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 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
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
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)
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)
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.
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.
Banco de dados II
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.
Banco de dados II
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>>
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.
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.
Banco de dados II
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.
Exemplo: autorizao de leitura e atualizao dos atributos da tabela Funcionrio para o usurio Pedro.
GRANT SELECT, UPDATE ON FUNCIONARIO TO PEDRO;
Banco de dados II
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;
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.
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.
Banco de dados II
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
Banco de dados II
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.
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.
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.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.
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
SGBD
Gerenciador de Arquivos
Anexos
- 33 -
Banco de dados II
Gerente de Dados
Gerenciador de Arquivos
Anexos
- 34 -