Cap.

4 SQL As linguagens formais proporcionam uma notao concisa para a representao de consultas, mas os bancos de dados comerciais precisam de uma linguagem de consulta mais fcil para o utilizador a SQL combinao de construtores em lgebra e clculo relacional. Ela mais que simples linguagem de consulta pois permite tambm definir estruturas de dados, modificar dados e especificao de restries de segurana. 4.1. Histrico SQL=Structured Query Language Linguagem de Consulta Estruturada. Actual SQL92. A linguagem SQL tem diversas partes: Linguagem de definio de dados DDL Linguagem interactiva de manipulao de dados DML: baseada na lgebra relacional e no clculo relacional de tuplos. Incorporao DML Definio de vises Autorizao Integridade Controle de transaces Neste captulo cobre-se a DML interactiva e os recursos DML bsicos da SQL. Usaremos como exemplo empresa com os seguintes esquemas de relaes: Esquema_agncia=(nome_agncia, cidade_agncia, fundos) Esquema_cliente=(nome_cliente, rua_cliente, cidade_cliente) Esquema_emprstimo=(nome_agncia, nmero_emprstimo, total) Esquema_devedor=(nome_cliente, nmero_emprstimo) Esquema_conta=(nome_agncia, nmero_conta, saldo) Esquema_depositante=(nome_cliente, nmero_conta) 4.2. Estruturas bsicas Um banco de dados relacional consiste numa coleco de relaes, cada uma designada por um nico nome. A SQL permite o uso de valores nulos para indicar valores desconhecidos ou inexistentes. H clusulas que permitem ao utilizador especificar quais os atributos no podero receber valores nulos. A estrutura bsica de uma expresso em SQL consiste em trs clususlas: selct, from e where select corresponde operao de projeco from corresponde ao produto cartesiano where corresponde seleco do predicado ex: select A1, A2, ..., An from r1, r2, ... , rm where P equivalente a A1,A2,...,An (P(r1xr2x...xrm) Se a clusula where for omitida, o predicado P verdadeiro. Diferentemente da lgebra relacional, o resultado de uma consulta em SQL pode conter cpias mltiplas de alguns tuplos. 4.2.1. A Clusula Select O resultado de uma consulta de SQL , naturalmente, uma relao. ex: select nome_agncia from emprstimo Na prtica a eliminao de duplicidade consome tempo. As linguagens formais de consulta baseia-se no facto de uma relao ser um conjunto. Se quisermos mesmo eliminarmos a duplicidade: select distinct ...

Select all ...= por defeito. O asterisco * pode ser usado para denotar todos os atributos ex: select emprstimo.* ex: select * A clusula select pode conter expresses aritmticas envolvendo os operadores + - * /, e os operandos constantes ou atributos das tuplas: ex: select nome_agncia, nmero_emprstimo, total*100 4.2.2. A Clusula Where ex: select nmero_emprstimo from emprstimo where nome_agncia = Perryridge and total > 1200 A SQL permite o uso de operadores de comparao para strings e expresses aritmticas, assim como tipos especiais, como tipos de datas. A SQL permite o operador between para simplificar a clusula where: ex: where total between 90000 and 100000 4.2.3. A Clusula From Por si s define um produto cartesiano das relaes na clusula. Uma vez que a juno natural definida em termos de produto cartesiano, uma seleco e uma projeco so um meio relativamente simples de escrever a expresso SQL para uma juno natural: nome_cliente, nmero_emprstimo(devedor >< emprstimo) select distinct nome_cliente, devedor.nmero_emprstimo from devedor, emprstimo where devedor.nmero_emprstimo=emprstimo.nmero_emprstimo 4.2.4. A Operao Rename Mecanismo para rebaptizar tanto relaes como atributos usando a clusula as. A clusula as pode aparecer tanto na clusula select como na from Por vezes, numa consulta derivamos nomes de atributos das antigas relaes para as novas relaes/resultados. Nem sempre convm: Primeiro porque nas relaes da clusula from podem existir atributos com o mesmo nome e que resultaria em nomes duplicados; Segundo, se usarmos uma expresso aritmtica na clusula select, o atributo resultante no teria um nome; terceiro, mesmo que o nome do atributo possa ser derivado das relaes de base, podemos desejar mudar o nome: ex: select distinct nome_cliente, devedor.nmero_emprstimo as id_emprstimo 4.2.5. Variveis Tuplos A clusula as particularmente til na definio do conceito de varivel tuplo, como feito no clculo realcional. Uma varivel tuplo precisa de estar associada a uma relao em particular. So definidas na clusula from por meio do uso da clusula as. ex: Para todos os clientes que possuem um emprstimo no banco, encontre os seus nomes e respectivos nmeros de emprstimo: select distinct nome_cliente, T.nmero_emprstimo from devedor as T.emprstimo, emprstimo as S where T.nmero_emprstimo = S.nmero_emprstimo Variveis tuplos so mais teis para comparao de dois tuplos da mesma relao. Poderamos tambm usar a operao rename. ex: Encontrar os nomes de todas as agncias que tenham fundos maiores que ao menos uma agncia daquelas localizadas em Brooklyn select T.nome_agncia from agncia as T, agncia as S where T.fundos > S.fundos and S.cidade_agncia = Brooklyn

A ordenao de tuplos feita atributo a atributo. 4.2.6. Operaes com Strings As operaes mais usadas so as checagens para verificao de coincidncias de pares, usando ooperador like. Identificaremos esses pares por meio do uso de dois caracteres especiais: % - compara qualquer substring _ - compara qualquer caracter So sensveis a minsculas e maisculas (case sensitive) ex: Perry% corresponde a qualquer string que comece por Perry ex: select nome_cliente from cliente where rua_cliente like %Main% permitido uso caracter de escape ex: like ab\%cd% escape \ A SQL permite pesquisar diferenas em vez de coincidncias, usando o not like Tambm permite concatenao (usando ||), extraco de substrings, indicao de tamanhos de strings, converso de maisculas para minculas, etc. 4.2.7. Ordenao e Apresentao de Tuplos Clusula order by ex: select distinct nome_cliente from devedor, emprstimo where devedor.nmero_emprstimo=emprstimo.nmero_emprstimo and nome_agncia=Perryridge order by nome_cliente Por defeito ordena de forma ascendente (asc). Se quisermos descendente devemos acrescentar, no fim, desc. 4.2.8. Duplicidade O uso de relaes com duplicidade (tuplos repetidos) por vezes til. A SQL d tambm o nmero de repeties. Podemos definir a semntica da duplicidade de uma consulta SQL usando verses multiconjuntos dos operadores relacionais. ... ser preciso??? 4.3. Operaes de Conjuntos Os operadores SQL-92 union, intersect e except operam relaes e correspondem s operaes U e - da lgebra relacional. Tambm aqui as relaes participantes das operaes precisam de ser compatveis, isto , ter o mesmo conjunto de atributos. 4.3.1. A Operao de Unio ex: Todos os clientes que possuam emprstimos ou conta ou ambos: (select nome_cliente from depositante) union (select nome_cliente from devedor) union, ao contrrio de select, elimina automaticamente as repeties. Se quisermos as repeties fazemos union all 4.3.2. A Operao Interseco Encontrar todos os clientes que tenham tanto emprstimos quanto contas no banco: (select distinct nome_cliente from depositante)

intersect (select distinct nome_client from devedor) A operao intersect elimina todas as repeties. Para aparecerem -> intersect all 4.3.3. A Operao Excepto Encontrar todos os clientes que tenham uma conta e nenhum emprstimo (select distinct nome_cliente from depositante) except (select nome_cliente from devedor) Tambm elimina repeties, excepto se escrevermos except all 4.4. Funes Agregadas So funes que tomam uma coleco (um conjunto ou subconjunto) de valores como entrada e retornam um valor simples. H 5: Mdia (average) : avg Mnimo (minimum) : min Mximo (maximum) : max Total (total) : sum Contagem (count) : count A entrada para sum e avg precisa ser um conjunto de nmeros. Os outros podem operar tambm como outros tipos de dados, como strings, etc. ex: Encontrar a mdia dos saldos em contas na agncia Perriridge select avg (slado) from conta where nome_agncia = Perryridge O resultado uma relao com atributo nico, contendo uma nica linha. Podemos dar-lhe um nome com a clusula as. Existem circunstncias em que queremos aplicar uma funo agregada no somente a um conjunto de tuplos, mas tambm a um grupo de conjuntos de tuplos. Teremos de usar a clusula group by. O atributo ou atributos fornecidos numa clusula group by so usados para formar grupos. ex: Encontrar a mdia dos saldos nas contas de cada uma das agncias do banco select nome_agncia, avg (saldo) from conta group by nome_agncia s vezes, mais interessante definir condies e aplic-las a grupos do que a tuplos. Deve usar-se a clusula having. ex: select nome_agncia, avg (saldo) from conta group by nome_agncia having avg (saldo) > 1200 Usamos a funo count com muita frequncia para contar o nmero de tuplos numa relao. A notao para essa funo count(*) ex: select count(*) from cliente A SQL no permite o uso de distinct em count(*), mas permite em max e min. Se uma clusula where e uma clusula having aparecem na mesma consulta, o predicado que aparece em where aplicado primeiro. Os tuplos que satisfazem a clusula where so, ento, colocadas em grupos por meio da clusula gropup by. A clusula having, se presente, ento aplicada a cada grupo. Os grupos que no satisfazem o predicado da clusula having so removidos. Os grupos remanescentes so usados pela clusula select.

ex: encontre o saldo mdio para cada cliente que mora em Harrison e tenha ao menos 3 contas select depositante.nome_cliente, avg(saldo) from depositante, conta, cliente where depositante.nmero_conta=conta.nmero_conta and depositante.nome_cliente=client.nome_cliente and cidade_cliente = Harrison group by depositante.nome_cliente having count (distinct depositante.nmero_conta) >= 3 4.5. Valores Nulos Podemos usar a palavra-chave null como predicado para testar a existncia de valores nulos. ex: select nmero_emprstimo from emprstimo where total is null O predicado is not null testa a ausncia de valores nulos. O uso de valores nulos em operaes aritmticas e comparaes causa diversas complicaes. O resultado de uma expresso aritmtica (envolvendo, por exemplo, +, -, * ou /) nula se qualquer um dos valores for nulo. O resultado de qualquer comparao envolvendo uma valor nulo pode ser imaginado como falso. Mais precisamente, a SQL trata os resultado destas comparaes como unknown, que no true nem false, embora muitas vezes seja tratado comop false. Tambm complica o clculo de funes agregadas, como sum. Em vez de dizer que a soma nula, o operador sum pode ignorar os valores nulos de entrada. Em geral, todas as funes agregadas (excepto count(*)) ignoram os valores nulos. 4.6. Subconsultas aninhadas As aplicaes mais comuns para as subconsultas so testes para membros de conjuntos, comparaes de conjuntos e cardinalidade de conjuntos. 4.6.1. Membros de Conjuntos Verificar se um tuplo membro ou no de uma relao. Usa-se o conectivo in (ou not in) que testa os mebros de um conjunto, no qual o conjunto a coleco de valores produzidos por select. ex: select distinct nome_cliente from devedor where nome_cliente in (select nome_cliente from depositante) ===> H um volume substancial de redundncia no SQL. Os operadores in e not in tambm podem ser usados em conjuntos enumerados: ex: select distinct nome_cliente from devedor where nome_cliente not in (Smith, Jones) 4.6.2. Comparao de Conjuntos Encontre os nomes de todas as agncias que tenham fundos maiores que ao menos uma agncia localizada no Brooklyn (dif de 4.2.5.) select nome_agncia from agncia where fundos > some (select fundos from agncia where cidade_agncia = Brooklyn)

=some idntico a in, mas <> no a mesma coisa que not in. any sinnimo de some, mas as ltimas verses s permitem o some devido ambiguidade lingustica de any. ex: de uso de > all select nome_agncia from agncia where fundos > all (select fundos from agncia where cidade_agncia = Brooklyn) all idntico a not in. Como exemplo final de comparaes de conjuntos, encontre a agncia que tem o maior slado mdio. Funes agregadas no podem ser agregadas em SQL, pelo que no podemos usar max(avg(...)). Ento, estrategicamente: select nome_agncia from conta group by nome_agncia having avg(saldo) >= all (select avg (saldo) from conta group by nome_agncia) 4.6.3. Verificao de Relaes Vazias A SQL possui meios para testar se o resultado de uma subconsulta possui algum tuplo. Usa-se o construtor exists que retorna o valor true de o argumento de uma subconsulta n-ao-vazio. ex: Encontre todos os clientes que tenham tanto conta como emprstimo no banco select nome_cliente from devedor where exists (select * from depositante where depositante.nome_cliente = devdor.nome_cliente) tambm se pode testar a no existncia de tuplos na subconsulta por meio do construtor not exists. Este construtor pode ser usado para simular operaes com conjuntos contidos (superconjuntoos): podemos escrver a relao A contm a relao B como not exists (B except A). Embora no seja padro do SQL-92, o operador contains existiu nalgumas verses de SQL. ex: Encontre todos os clientes que tenham uma conta em todas as agncias do Brooklyn select distinct S.nome_cliente from depositante as S where not exists (select nome_agncia from agncia where cidade_agncia = Brooklyn) except (select R.nome_agncia from depositante as T, conta as R where T.nmero_conta = R.nmero_conta and S.nome_cliente = T.nome_cliente)) 4.6.4. Teste para a Ausncia de Tuplos Repetidos (numa subconsulta) O construtor unique retorna o valor true caso o argumento da subconsulta no possua nenhum tuplo repetido. ex: Encontre todos os clientes que tenham somente uma conta na agncia Perryridge

select T.nome_cliente from depositante as T where unique (select R.nome_cliente from conta, depositante as R where T.nome_cliente = R.nome_cliente and R.nmero_conta = conta.nmero_conta and conta.nome_agncia = Perryridge) O not unique pode ser utilizado para encontrar todos os clientes que tenham pelo menos duas contas... O teste de unique falha se um dos campos for null 4.7. Relaes Derivadas O SQL permite o uso de uma expresso de subconsulta na clusula from. Nesse caso, a relao resultante deve receber um nome e os atributos precisam de ser rebaptizados, com as. ex: (select nome_agncia, avg(saldo) from depositante group by nome_agncia as resultado (nome_agncia, saldo_mdio) Depois podemos usar o resultado desta subconsulta numa consulta. 4.8. Vises ser preciso??? 4.9. Modificao no Banco de Dados Adicionar, Remover e Alterar 4.9.1. Remoo Um pedido de remoo de dados expresso muitas vezes do mesmo modo que uma consulta. Podemos remover apenas tuplos inteiros. delete from r where P ex: delete from depositante where nome_cliente = Smith ex: delete from conta where nome_agncia in (select nome_agncia from agncia where cidade_agncia = Perryridge) Assim, podemos ver que podemos atingir mais que uma relao numa operao de delete, por meio de comandos select-from-where aninhados numa clususla where de um delete. Os tuplos a remover tambm podem ser da relao da clusula delete: ex: delete from conta where saldo < (select avg (saldo) from conta) importante que todos ostestes sejam efectuados antes de remover. 4.9.2. Insero Para inserir dados numa relao podemos especificar um tuplo a ser inserido ou escrever uma consulta cujo resultado um conjunto de tuplos a inserir. ex: + simples: insert into conta values (Perryridge, A-9732, 1200) Para quem no se lembrar da ordem: insert into conta (nome_agncia, nmero_conta, saldo)

values (Perryridge, A-9732, 1200) ou qualquer outra ordem. + genericamente: insert into conta select nome_agncia, nmero_emprstimo, 200 from emprstimo where nome_agncia = Perryridge mal: insert into conta select * from conta Pode inserir-se tuplos com atributos a null, mas, com DDL pode impedir-se isso se assim o pretendermos. 4.9.3. Actualizaes ex: update conta set saldo = saldo * 1.05 ex: update conta set saldo = saldo * 1.06 where saldo > 10000 update conta set saldo = saldo*1.05 where saldp <= 10000 ateno ordem, portanto. 4.9.4. Actualizaes de uma Viso preciso?... 4.10. Composio de Relaes Alm de fornecer o mecanismo bsico do produto cartesiano para a composio dos tuplos de uma relao disponvel nas primeiras verses de SQL, a SQL-92 tambm oferece diversos outros mecanismos para composio de relaes como as junes condicionais e as junes naturais, assim como vrias formas de junes externas. Essas operaes adicionais so usadas tipicamente como expresses de subconsultas na clusula from. 4.10.1. Exemplos emprstimo inner join devedor on emprstimo.nmero_emprstimo = devedor.nmero_emprstimo Os atributos do resultado consistem nos atributos da relao da esquerda seguidos dos atributos da relao da direita (com repetio). podemos rebaptizar a relao resultado, bem assim como os atributos resultado, com a clusula as. O left outer join processado como se segue: Primeiro, o resultado da juno interna (inner join) processado como anteriormente. Ento, para todo o tuplo t da relao emprstimo do lado esquerdo que no apresente correspondncia com nenhum tuplo da relao devedor do lado direito da juno interna, um tuplo r adicionado ao resultado da juno da maneira como ser descrita. Os atributos do tuplo r que so derivados da relao do lado esquerdo so preenchidos pelos valores do tuplo t e os restantes so preenchidos com o valor nulo. O right outer join semelhante, mas ao contrrio. Finalmente consideremos o natural join ex: emprstimo natural inner join devedor semelhante ao inner join inicial, excepto que os atributos no aparecem repetidos.

4.10.2. Tipos de Junes e Condies Embora as expresses para juno externa sejam normalmente usadas na clusula from, elas podem ser usadas em qualquer lugar onde se usa uma relao. Cada uma das variantes das operaes de juno em SQL-92 consiste num tipo de juno e numa condio de juno. As condies de juno definem quais os tuplos das duas relaes apresentam correspondncia e quais atributos so apresentados no resultado de uma juno. O tipo de juno define como os tuplos em cada relao que no possuam nenhuma correspondncia (baseado na condio de juno) com os tuplos da outra relao devem ser tratados. Tipos de Juno inner join Condies de juno left outer join natural right outer join on <predicate> full outer join using (A1,A2,...,An) O uso de uma condio de juno obrigatrio para junes externas, mas opcional para junes internas (se for omitido, o resultado o produto cartesiano). Sintacticamente, a palavra-chave natural aparece antes do tipo de juno, embora as condies on e using apaream no final de uma expresso de juno. As palavraschave inner e outer so opcionais, uma vez que os nomes dos demais tipos de junes nos permitem deduzir do que se trata. Na natural, os atributos da juno (isto , os atributos comuns a ambas as relaes) aparecem primeiro, conforme a ordem que aparecem na relao do lado esquerdo. Depois vm todos os atributos para os quais no h correspondncia aos da relao do lado esquerdo e, finalmente, todos os atributos sem correspondncia aos da relao do,lado direito. A condio de juno using(A1,A2,...,An) similar condio de juno natural, excepto pelo facto de que seus atributos de juno so os atributos A,A2,...,An em vez de todos os atributos comuns a ambas as relaes. Os atributos A1,A2,...,An devem ser somente os atributos comuns a ambas as relaes e eles aparecem apenas uma vez no resultado da juno. ex: Encontre todos os clientes que tenham uma conta, mas nenhum emprstimo no banco select d-CN from (depositante left outer join devedor on depositante.nome_cliente = devedor.nome_cliente) as db1 (d-CN, nmero_conta, b-CN, nmero_emprstimo) where b-CN is null cross join = juno interna sem uma condio de juno union join = juno externa total na condio de falso, em que a juno interna vazia. 4.11. Linguagem de Definio de Dados A SQL DDL permite no s a especificao de um conjunto de relaes, como tambm infromaes acerca de cada uma das relaes, incluindo: O esquema de cada relao O domnio dos valores associados a cada atributo As regras de integridade O conjunto de ndices para manuteno de cada relao Informaes sobre segurana e autoridade sobre cada relao A estrutura de armazenamento fsico de cada relao no disco. vamos, agora, s discutir os dois primeiros:

4.11.1. Tipos de Domnios em SQL

Cap 4. EXERCCIOS 4.1. Considere o banco de dados da empresa de seguros mostrada abaixo, em que as chaves primrias esto sublinhadas. Construa as seguintas consultas em SQL para este banco de dados relacional. pessoa(ss#, nome, endereo) automvel(licena, ano, modelo) acidente(data, motorista, total_danos) proprietrios(ss#, licena) sinistro(licena, data, motorista) (a) Encontre o nmero total de pessoas cujos automveis estiveram envolvidos em acidentes em 1989. select count distinct motorista from acidente where data=1989 (b) Encontre o nmero de acidentes em que os automveis de John Smith estiveram envolvidos

CAP. 6 REGRAS DE INTEGRIDADE As regras de integridade fornecem a garantia de que mudanas feitas na base de dados por utilizadores autorizados no resultem em perda de consistncia dos dados. Como vimos no cap.2 para o modelo E-R, essas regras possuem a seguinte forma: Declarao de chaves: no duplos de chaves candidatas. Forma de um relacionamento: um para um, ... Embora arbitrrias, na prtica so limitadas s que podem ser verificadas com o mnimo tempo de processamento. 6.1. Restries de Domnios So as mais elementares formas de restries de integridade. A clusula check permite modos poderosos de restries de domnios. Permite ao projecto do esquema determinar um predicado que deva ser satisfeito por qualquer valor designado a uma varivel cujo tipo seja o domnio. ex: create domain turno_trabalho numeric(5,2) constraint valor_teste_turno check(value >= 4,00) ex: create domain nmero_conta char(10) constraint teste_nulo_nmero_conta check(value not null) ex: create domain tipo_conta char(10) constraint teste_tipo_conta check (value in (Corrente, Poupana)) 6.2. Integridade Referencial Frequentemente desejamos garantir que um valor que aparece numa relao para um dado conjunto de atributos tambm aparea para um certo conjunto de atributos de outra relao. Essa condio chamada integridade referencial 6.2.1. Conceitos Bsicos tuplos pendentes quando h tuplos de uma relao r que no pode ser combinado com um tuplo da relao s, aquando da sua juno natural. Tuplos pendentes podem ser aceitveis ou no. ex: indesejvel em conta, existir t1[nome agncia] = Lunartown e na relao agncia no haver nenhuma Lunartown. aceitvel: o contrrio. A diferena tem origem em: - O atributo nome_agncia do Esquema_conta uma chave estrangeira (foreign key) cuja referncia a chave primria do Esquema_agncia - O atributo nome_agncia do Esquema_agncia no uma chave estrangeira. ==> Regras de integridade referencial ou subconjunto dependente: (r2) K1(r1) 6.2.2. Integridade Referencial no Modelo E-R Cada Ki do esquema de R uma chave estrangeira que leva a uma regra de integridade referencial. Outra fonte de regras de integridade referencial so os conjuntos de entidades fracas. 6.2.3. Modificaes no Banco de Dados As modificaes no banco de dados podem originar violao das regras de integridade referencial. H que fazer pois verificaes para preservar (r2) K1(r1): - Insero: Se t2 inserida em r2 ---> t2[] k(r1) - Remoo: Se t1 removida de r1, o siatema deve tratar tambm o conjunto de tuplos em r2 que so referidos por t1. Pode haver cascata. - Actualizao: Mistura das duas anteriores... 6.2.4. Integridade Referencial em SQL

 possvel definir chaves primrias, secundrias (candidatas ?) e estrangeiras como parte do comando create table da SQL: Forma simplificada para declarar que uma nica coluna uma chave estrangeira: Nome_agncia char(15) references agncia ex: create table cliente (nome_cliente char(20) not null, rua_cliente char(30), cidade_cliente char(30), primary key (nome_cliente)) create table agncia (nome_agncia char(15) not null, cidade_agncia char(30), fundos integer, primary key (nome_agncia), check (fundos >= 0)) create table conta (nmero_conta char(10) not null, nome_agncia char(15), saldo integer primary key (nmero_conta), foreign key (nome_agncia) references agncia, check (saldo >=0)) create table depositante (nome_cliente char(20) not null, nmero_conta char(10) not null, primary key (nome_cliente, nmero_conta) foreign key (nome_cliente) references cliente, foreign key (nmero_conta) references conta) Quando uma regra de integridade referencial violada, o procedimento normal rejeitar a aco que ocasionou essa violao. Mas, na clusula relativa a foreign key pode especificar-se os passos para modificao do tuplo que contm a referncia, de modo a garantir a regra de integridade. ex: create table conta ... foreign key (nome_agncia) references agncia on delete cascade on update cascade, ...) A SQL-92 tambm permite que a clusula foreign key especifique outros tipos de aces alm de cascata, como alterar o campo em questo (no caso nome_agncia) com nulos, ou um valor padro... A semntica de chaves em SQL torna-se mais complexa pelo facto de a SQL permitir valores nulos. As seguintes regras, algumas das quais arbitrrias, so usadas para tratar esses valores nulos. Todos os atributos de uma chave primria so declarados implicitamente not null. Atributos de uma declarao unique (isto , atributos de uma chave candidata) podem ser nulos, contanto que no sejam declarados no-nulos de outro modo. S sa iguais se no houver nulos numa das colunas, pelo menos. Atributos nulos em chaves estrangeiras so permitidos, o que implica a sua aprovao na regra da integridade.

Dada esta complexidade e arbitrariedade natural das formas e comportamento de restries (ou regras) de integridade em relao a valores nulos, o melhor assegurar que todas as colunas especificadas em unique e foreign key sejam declaradas no permitindo nulos. 6.3. Asseres Uma assero um predicado que expressa uma condio que desejamos que seja sempre satisfeita no banco de dados. Restries de domnio e regras de integridade so formas especiais de asseres. Outros ex: A soma de todos os totais em conta emprstimo de cada uma das agncias deve ser menor que a soma de todos os saldos das contas dessa agncia. Todo o emprstimo deve ter ao menos um cliente que mantenha uma conta com saldo mnimo de 1000 dlares. create assertion <nome_assero> check <predicado> ex:1: create assertion restrio_soma check (not exists (select * from agncia where (select sum(total) from emprstimo where emprstimo.nome_agncia = agncia.nome_agncia) >= (select sum(total) from conta where conta.nome_agncia = agncia.nome_agncia))) preciso usar as asseres com muito cuidado pois a sua verificao pode ser pesada para o sistema, que precisa de as verificar em cada actualizao, para alm do incio. 6.4. Gatilhos (Triggers) Um gatilho um comando que executado pelo siatema automaticamente, em consequncia de uma modificao no banco de dados. Duas exigncias devem ser satisfeitas para o projecto de um mecanismo de gatilho: 1. Especificar as condies sob as quais o gatilho deve ser executado 2. Especificar as aces que sero executadas quando um gatilho for disparado. So teis para avisos, por ex. ex: define trigger saldo_negativo on update of conta T (if new T.saldo<0 then (insert into emprstimo values (T.nome_agncia, T.nmero_conta, - new T.saldo) insert into devedor (select nome_cliente, nmero_conta from depositante where T.nmero_conta = depositante.nmero_conta) update conta S setS.saldo=0 where S.nmero_conta=T.nmero.conta)) Os gatilhos so chamdaos s vezes de regras(rules) ou regras activas (active rules), mas no devem ser confundidas com as regras da datalog. 6.5. Dependncia Funcional um tipo particular de restries. uma generalizao da noo de (super)chave. 6.5.1. Conceitos Bsicos --> se para qualquer t1[] = t2[], t1[] =t2[] A dependncia funcional permite-nos expressar restries que as superchaves no expressam.

Podemos usar dependncia funcional de dois modos: 1. Usando-as para estabelecimento de restries sobre um conjunto de relaes vlidas... F realiza-se em R 2. Usando-as para verificao de relaes... r satisfaz F. --> trivial se Para distinguir os conceitos de uma relao que satisfaz uma dependncia e de uma dependncia realizando-se num esquema, voltemos ao ex. do banco. Se considerarmos a relao cliente (com o Esquema_cliente), como mostrado, notamos que rua_cliente -> cidade_cliente satisfeita. Mas, no mundo real, possvel que duas cidades distintas tenham o mesmo nome de rua. Logo, no incluiremos a dependncia no conjunto de dependncias funcionais que so realizadas no Esquema_cliente. Na relao emprstimo (do Esquema_emprstimo) vemos que nmero_emprstimo>total satisfeita. Aqui diferente, pois na vida real normal que cada conta tenha apenas um total. Portanto queremos que a condio nmero_emprstimo -> toatla seja sempre satisfeita para a relao emprstimo. Por outras palavras, precisamos da restrio nmero_emprstimo -> total para o Esquem_emprstimo. J na relao agncia, nome_agncia -> fundos realaizada no Esquema_agncia, j o mesmo no se passando com o inverso, embora na relao, essa dependncia possa ser satisfeita. Embora o SQL no fornea um modo simples para especificao de dependncias funcionais, podemos escrever consultas para verificao de dependncias funcionais, assim como criar asseres para garantia de dependncias funcionais. Quando projectamos um banco de dados relacional, primeiro relacionamos as dependncias funcionais que sempre precisam ser realizadas. Ex: No Esquema_agncia: nome_agncia --> cidade_agncia nome_agncia --> fundos No Esquema_cliente: nome_cliente --> cidade_cliente nome_cliente --> rua_cliente 6.5.2. CLAUSURA (FECHO) DE UM CONJUNTO DE DEPENDNCIAS FUNCIONAIS No basta considerar um dado conjunto de dependncias funcionais. preciso considerar todos os conjuntos de dependncias funcionais que so realizadas. Podemos mostrar que dado um conjunto F de dependncias funcionais, prova-se que outras dependncias funcionais realizam-se (conjunto logicamente implcito em F). ex:ex: esquema R(A,B,C,G,H,I) e A --> B A --> C CG --> H CG --> I B --> H A --> H logicamente implcita O fecho de F o conjunto de todas as dependncias funcionais logicamente implcitas em F. Denotamos por F+ Dado F podemos computar F+ pela definio de DF, mas existem tcnicas mais simples. 1 Trs axiomas ou regras para inferncia Regra da Reflexividade: Se conjunto de atributos e , ento --> realiza-se Regra de Incremento:

Se --> se realiza e um conjunto de atributos, ento --> tambm se realiza Regra da Transitividade: Se --> e --> se realizam, ento --> tambm se realiza. Estas regras so slidas e completas. So os Axiomas de Armstrong. Embora sejam completos, enfadonho utiliz-los directamente para computao de F+. Ento, para simplificar, adicionamos regras adicionais: Regra da Unio: Se --> e --> se realizam, ento --> tambm se realiza. Regra de Decomposio: Se --> se realiza, ento --> e --> tambm se realizam. Regra da Pseudotransitividade: Se --> e --> se realizam, ento --> tambm se realiza 6.5.3. CLAUSURA DE CONJUNTOS DE ATRIBUTOS Para verificar se um conjunto de atributos uma superchave, precisamos conceber um algoritmo para computar o conjunto de atributos determinados funcionalmente por . Esse algoritmo tambm ser til na determinao do fecho de um conjunto F. Chamamos o conjunto dos atributos funcionalmente determinados por , sob um conjunto de dependncias funcionais F, de fecho de . Denotamos por + Em pseudo pascal: resultado := ; while (mudanas em resultado) do for each funcional dependncia --> in F do begin if resultado then resultado := resultado U ; end exerccio: provar que AG superchave. 6.5.4. COBERTURA CANNICA Sempre que uma actualizao realizada na relao, o sistema de banco de dados deve garantir que todas as dependncias funcionais em F sejam satisfeitas no novo estado do banco de dados. Para reduzir os esforos de teste: Qualquer banco de dados que satisfaa um conjunto simplificado de dependncias funcionais deve tambm satisfazer o conjunto original, e vice-versa, uma vez que os dois conjuntos tm o mesmo fecho. Um atributo de uma dependncia funcional extrnseco se podemos remov-lo sem alterar o fecho do conjunto de dependncias funcionais. Formalmente: A extrnseco a se A, e F implica logicamente (F-{-->}) U {(-A) --> } A extrnseco a se A, e o conjunto de dependncias funcionais (F-{-->}) U {(-> (-A)} implica logicamente F. Uma cobertura cannica Fc para F o conjunto de dependncias tal que F implique logicamente todas as dependncias de Fc e Fc implique logicamente todas as dependncias de F. Alm disso Fc deve apresentar as seguintes propriedades: Nenhuma dependncia funcional em Fc contm um atributo extrnseco Cada lado esquerdo da dependncia funcional em Fc nico. Isto , no h duas dependncias 1 --> 1 e 2 -.-> 2 em Fc tal que 1 = 2 Uma cobertura cannica pode ser computada como:

repeat Use a regra de unio para substituir todas as dependncias funcionais em F da forma 1 --1 e 1 --> 2 por 1 --> 12 Encontre as dependncias funcionais --> com um atributo extrnseco em ou em Se um atributo extrnseco encontrado, remova-o de --> until F no mude exerccio: Computar a cobertura cannica para F, sendo F, no esquema (A,B,C) A --> BC B --> C A --> B AB --> C Soluo: A --> B B --> C EXERCCIOS: 6.7. Por que h certas dependncias funcionais chamadas de triviais? Porque so dependncias funcionais satisfeitas por todas as relaes. Em geral, uma dependncia funcional --> trivial se 6.8. Relacione todas as dependncias atendidas (satisfeitas na) pela relao da figura: A a1 a1 a2 a2 A --> B AC --> B + as triviais : A --> A B b1 b1 b1 b1 C c1 c2 c1 c3

B --> B

C --> C

AB --> A, etc.

6.9. Use a definio de dependncia funcional para discutir como funciona cada um dos axiomas da Armstrong (reflexividade, aumento e transitividade) Reflexividade: se t1[] = t2[] e ento forosamente = . Logo t1[] = t2 [] Incremento: se t1[] = t2[] , de --> temos que t1[] = t2[]. Como, por reflexividade --> , se t1[ ] = t2[ ] ento t1[] = t2[ ] Transitividade: Est feito na pgina 204 do livro. 6.10. Explique como a dependncia funcional pode ser usada par explicar o seguinte: Um conjunto de relacionamentos um para um entre o conjunto de entidades estudantes e orientador. Um conjunto de relacionamentos muitos para um entre o conjunto de entidades estudantes e orientador. estudantes --> orientador orientador --> estudantes estudantes --> orientador

6.15. Compute a clausura do seguinte conjunto F de dependncias funcionais do esquema de relao R= (A,B,C,D,E) A --> BC CD --> E B --> D E --> A Relacione as chaves candidatas de R BC --> E pela pseudotransitividade E --> BC pela transitividade A --> B e A --> C pela decomposio E --> B e E --> C pela decomposio E --> D pela transitividade E --> ABCD pela unio E --> ABCDE pela reflexividade e unio A --> E pela transitividade A --> BCE pela unio A --> ABCD pela reflexividade, transitividade e unio A --> ABCDE pela unio BC --> ABCDE pela transitividade CD --> ABCDE pela transitividade ===> chaves candidatas: A , E , BC e CD 6.16. Usando as dependncias funcionais do exerccio anterior, compute B+ pelo algoritmo da pgina 206 do livro: 0. resultado = B 1. resultado = B U D pois B --> D resultado final = BD Se fosse pedido para o A: 6.17. Usando as dependncias funcionais dos exerccios anteriores, compute a cobertura cannica Fc Usando o algoritmo da pgina 207 do livro: ver se C extrnseco em A --> BC (F-{A-->BC}) U {A --> (BC-C)} CD-->E A-->B B-->D E-->A BC-->E pela pseudotransitividade E -->A pela transitividade E --> B pela transitividade A-->D pela transitividade AC-->E A-->BD AC-->E pela pseudotransitividade AC-->AB pela transitividade e unio no me parece e o B? tambm no.

ver se C ou D so extrnsecos em CD-->E (F {CD->E}) U {(CD D) -->E} A-->BC U C-->E B-->D E-->A CD-->E A-->B A-->C A-->D A-->E CD-->A BC-->E BC-->A Ento a cobertura cannica ser mesmo o conjunto das dependncias dadas. No possvel reduzir.

CAP. 13 TRANSACES Normalmente considera-se que um conjunto de vrias operaes no banco de dados uma nica unidade do ponto de vista do utilizador. O essencial ser a concluso de todo o conjunto de operaes, ou que, no caso de uma falha, nenhuma delas ocorra. Seria inaceitvel o dbito sem o crdito numa transferncia. As operaes que formam uma nica unidade lgica de trabalho so chamadas transaces. Alm disso o banco deve administrar a execuo de vrias transaces de modo a evitar a ocorrncia de inconsistncias. 13.1. Conceito de transaco Uma transaco uma unidade de execuo de programa que acessa e, possivelmente, actualiza vrios itens de dados. geralmente o resultado de um programa em SQL e delimitada por begin transaction e end transaction. Para assegurar a integridade dos dados, exigimos que o sistema de banco de dados mantenha as seguintes propriedades (ACID) das transaces: Atomicidade: todas as operaes ou nenhumas Consistncia: Uma transaco isolada preserva a consistncia do banco de dados. Isolamento: Embora possa ocorrer transaces concorrentes cada uma delas tem a sensao de que a outra acabou antes de se iniciar Durabilidade: Mudanas persistem at mesmo se houver falhas no sistema. Ex: Transaco em contas de um banco. Vamos supor que o banco de dados reside permanentemente em disco, mas que alguma parte dele reside, temporariamente, na memria principal. O acesso ao banco de dados obtido pelas duas seguintes operaes: read(X), que transfere o item de dados para um buffer alocado transaco write(X) que transfere do buffer localpara o banco de dados. Num banco de dados real, o write no resulta necessariamente na actualizao dos dados em disco, pode ser armazenado na memria temporariamente. ex: Ti: read(A); A:= A 50; write(A); read(B); B:=B+50; write(B) Consistncia: A exigncia de consistncia significa que que a soma de A com B deve permanecer inalterada aps a execuo da transaco. responsabilidade do programador da aplicao que codifica a transaco. Esta tarefa pode ser facilitada por meio do teste automtico dos requisitos de integridade, conforme visto no cap. 6. Atomicidade: Suponhamos que h uma falha a meio, depois de write(A) mas antes de write(B) da transaco (falta de energia, falha da mquina ou de software). Ento a soma de A+B no preservada --> estado inconsistente. A ideia bsica por detrs da atomicidade a seguinte: O sistema de banco de dados mantm um registo (em disco) dos antigos valores de quaisquer dados sobre os quais a transaco executa uma gravao e, se a transaco no for completada, os valores antigos so restabelecidos para parecer que nada dela foi executado. da responsabilidade do prprio sistema de banco de dados. Durabilidade:

Garante que uma vez completada a transaco com sucesso, todas as actualizaes realizadas permanecero mesmo que depois haja uma falha no sistema. Suponhamos agora que uma falha se d e h perda de dados na memria, mas no no disco. Podemos garantir a durabilidade se se garantir uma de: 1. As actualizaes realizadas pela transaco foram gravadas em disco, antes da transaco se completar 2. Informaes gravadas no disco, sobre as actualizaes realizadas pela transaco, so suficientes para que o banco de dados possa reconstruir essas actualizaes quando o sitema for reiniciado aps uma falha. da responsabilidade do componente de gerenciamento de recuperao. Isolamento: Quando h mais que uma transaco em simultneo (concorrentes) com operaes que podem ser intercaladas. Uma soluo realizar transaces em srie mas isso muito ineficiente. H pois outras tcnicas que veremos frente. da responsabilidade do componente de controlo de concorrncia. 13.2. ESTADO DA TRANSACO Se houver falha a transaco deve ser abortada e, nesse caso, quaisquer actualizaes j feitas devem ser desfeitas --> transaco desfeita (rolled back retornada). da responsabilidade do sistema de recuperao. Uma transaco efectuada com sucesso diz-se efectivada (committed). Para desfazer os seus efeitos s atravs de uma transaco de compensao. Uma transaco deve estar num dos seguintes estados: Activa, ou estado inicial: quando est a executar-se Em efectivao parcial: aps a execuo da ltima declarao (ainda na memria principal, pelo que ainda pode ser abortada) Em falha: Quando se descobre que a execuo normal j no se pode continuar Abortada: depois de desfeita Em efectivao: Aps concluso com sucesso. Diz-se concluda se estiver em efectivao ou abortada. Depois de entrar no estado abortada, o sistema tem duas opes: Reiniciar a transaco (excepto se for falha por erro lgico da transaco) --> nova transaco Matar a transaco (erro lgico da transaco) 13.3. IMPLEMENTAO DE ATOMICIDADE E DURABILIDADE O componente de recuperao de um banco de dados implementa o suporte atomicidade e durabilidade. Ex de esquema simples mas muito ineficiente: cpias shadow (sombra) com db_pointer. Diz-se que uma transaco foi efectivada quando o db_pointer actualizado escrito no disco. O sistema de disco garante que actualizar o db_pointer atomicamente. 13.4. EXECUES CONCORRENTES Traz diversas complicaes em relao consistncia dos dados. muito fcil insistir na execuo sequencial das transaces, porm h dois fortes motivos para que os sistemas reais permitam a concorrncia: 1. A CPU e os discos num sistema informtico podem operar em paralelo, o que aumenta a eficincia. 2. Na sequencial, uma transaco curta poderia ter de esperar muito tempo por uma longa. Logo, se as transaces esto operando em diferentes partes do banco de dados, melhor deix-las concorrer, o que reduz os tempos de atraso e o tempo mdio de resposta.

Vamos introduzir o conceito de escalas de execuo (schedules) para ajudar na identificao de quais ordens de execuo podem garantir a manuteno da consistncia. Aqui a consistncia garantida pelos mecanismos de controlo de concorrncia. EX: Escala1: T1 T2 read(A) A:=A-50 write(A) read(B) B:=B+50 write(B) read(A) temp:=A*0,1 A:=A-temp write(A) read(B) B:=B+temp write(B) Incio: A=1000 e B=2000 Se T1 e depois T2 --> A=855 e B=2145 (escala 1) Se T2 e depois T1 --> A=850 e B=2150 (escala 2) As sequncias apresentadas so chamadas de escalas de execuo ou s de escalas: representam a ordem cronolgica por meio da qual as instrues so executadas. As escalas 1 e 2 so sequenciais. H sempre n! escalas sequenciais. Se o controlo da execuo concorrente deixado completamente sob responsabilidade do sistema operativo, muitas escalas de execuo possveis, so factveis, mesmo aquelas que deixam o sistema num estado inconsistente (criao ou desaparecimento de dinheiro) tarefa do banco de dados, atravs do componente de controlo de concorrncia garantir quer isso no possa suceder. Temos pois que garantir que a escala usada seja equivalente a uma escala sequencial. 13.5. SERIALIZAO Vamos s considerar as operaes significativas do ponto de vista da escala de execuo: read e write. 13.5.1. SERIALIZAO DE CONFLITO vamos considerar uma escala de execuo S com duas instrues sucessivas, Ii e Ij , das transaces Ti e Tj (i j), respectivamente. Se Ii e Ij se referem a itens de dados diferentes, ento podemos alternar Ii e Ij sem afectar os resultados de qualquer instruo da escala. Porm, se Ii e Ij se referem ao mesmo item de dados Q, ento a ordem dos dois passos pode importar. Como s considermos read e write, h 4 casos a analisar: 1. Ii=read(Q) , Ij=read(Q) : a sequncia de execuo de Ii eIj no importa j que o mesmo valor de Q lido a despeito da ordem. 2. Ii=read(Q) , Ij=write(Q) : A ordem importa 3. Ii=write(Q) , Ij=read(Q) : A ordem importa 4. Ii=write(Q) , Ij=write(Q) : Importa, do ponto de vista do prximo read Dizemos que Ii e Ij entram em conflito caso elas pertenam a difeentes transaces, agindo no mesmo item de dado, e pelo menos uma dessas operaes de write.

Se Ii e Ij no entram em conflito podemos trocar a sua ordem que a escala S assim obtida equivalente a S. Se formos trocando a ordem e chegarmos a uma escala sequencial, quer dizer que os efeitos da escala inicial so os mesmos de uma escala sequencial. Dizemos que S e S so equivalentes no conflito. Dizemos que uma escala de execuo conflito serializvel se ela equivalente no conflito a uma escala de execuo sequencial. possvel ter duas escalas de execuo que produzam o mesmo resultado, mas que no seja, equivalentes no conflito. H definies menos restritivas de equivalncia de escala que a equivalncia de conflito, mas em geral tal anlise onerosa em termos computacionais. Mas h outras puramente baseadas em read e write: 13.5.2. VISO SERIALIZADA S e S so ditas equivalentes na viso se as trs condies seguintes forem satisfeitas: 1. Para cada item de dados Q, se a transaco Ti fizer uma leitura no valor inicial de Q na escala S, ento a transaco Ti tambm deve, na escala S , ler o valor inicial de Q. 2. Para cada item de dados Q, se a transaco Ti executar um read(Q) na escala S, e aquele valor foi produzido por meio da transaco Tj (se houver), ento a transaco Ti tambm dever, na escala S, ler o valor de Q que foi produzido por meio da transaco Tj 3. Para cada item de dados Q, a transaco (se houver) que executa a operao final writ(Q) na escala S tem de executar a operao write(Q) final em S. A escalas 1 e 2 no so equivalentes na viso mas a 1 e 3 j so. escala 3: T1 T2 read(A) write(A) read(A) write(A) read(B) write(B) read(B) write(B) Dizemos que S tem viso serializada se for equivalente em viso a uma escala de execuo sequencial. Ex: de escala viso serializvel mas no conflito serializvel: T3 T4 T6 read(Q) write(Q) write(Q) write(Q) 13.6. RECUPERAO Se uma Ti falha, precisamos de desfazer os seus efeitos, mas tambm necessario assegurar que qualquer transaco Tj que dependa de Ti seja abortada. Para assegurar isso temos de colocar restries aos tipos de escalas que se podem usar. 13.6.1. ESCALAS DE EXECUO RECUPERVEIS S devero ser permitidas escalas recuperveis.

Uma escala recupervel aquela na qual, para cada par de transaces Ti e Tj, tal que Tj leia itens de dados previamente escritos por Ti, a operao de efectivao de Ti aparea antes de operao de efectivao de Tj. 13.6.2. ESCALAS EM CASCATA O retorno em cascata indesejvel, mesmo em escalas recuperveis, j que leva a destruir uma quantidade de trabalho. Logo, conveniente restringir s sem cascata. Uma escala sem cascata aquela na qual para cada par de transaces Ti e Tj, tal que Tj leia um item de dados previamente escrito por Ti, a operao de efectivao de Ti aparea antes da operao de leitura de Tj. Toda a escala sem cascata recupervel. 13.7. IMPLEMENTAO DO ISOLAMENTO As escalas que so conflito ou viso serializvel e sem cascata assegura que o banco de dados fica sempre num estado consistente e trata seguramente as possveis falhas de transaco. H vrios esquemas para assegurar isso (controle de concorrncia) a despeito do S.Operativo usado. O mais trivial o lock usado por uma transaco que entra em execuo. mas isso ineficiente, sendo geradas apenas escalas sequenciais. 13.8. DEFINIO DE TRANSACO EM SQL Uma linguagem de manipulao de dados deve possuir um construtor para especificar o conjunto de aces que constitui uma transaco. No padro SQL ela comea de modo subentendido e termina por Commit work (executa a efectivao da transaco corrente e comea uma nova) ou Rollback work (aborta a transaco corrente) O nvel de consistncia especificado pelo SQL-92 : Serializvel Read repetitivo Read com efectivao Read sem efectivao 13.9. TESTE DE SERIALIZAO Nesta seco apresentaremos mtodos para determinar serializao de conflito (h algoritmo simples) e serializao de viso. 13.9.1. TESTE PARA SERIALIZAO DE CONFLITO Seja S uma escala. Construmos um grfico direccionado, chamado grfico de precedncia de S. Esse grfico consiste num par G=(V,E), em que V um conjunto de vrtices e E um conjunto de arestas. O conjunto de vrtices consiste em todas as transaces que partiocipam na escala. O conjunto de arestas consiste em todas as arestas Ti --> Tj para as quais uma das seguintes condies se verifica: 1.Ti executa write(Q) antes de Tj executar read(Q) 2.Ti executa read(Q) antes de Tj executar write(Q) 3.Ti executa write(Q) antes de Tj executar write(Q) Se h uma aresta Ti --> Tj no grfico de precedncia, ento, em qualquer escala sequencial S equivalente a S, Ti deve aparecer antes de Tj. Se o grfico de precedncia tem um ciclo, ento a escala S no conflito serializvel. Se o grfico no contm ciclos, ento a escala S conflito serializvel. A ordem de serializao pode ser obtida por meio da classificao topolgica. EXERCCIOS

13.1.Liste as propriedades ACID. Explique a utilidade de cada uma. Atomicidade: Para garantir que uma transaco (com vrias operaes) ou totalmente feita ou nada feito. Se assim no fosse corramos facilmente o risco de inconsistncia de dados. Da responsabilidade do programador. Consistncia: Para garantir que nada desaparece ou aparece sempre que feita qualquer transaco. da responsabilidade do sistema de base de dados. Isolamento: Apesar de duas transaces poderem ser executadas em simultneo, para rendibilizar os recursos de sistema, para cada uma delas como se a outra no existisse. da responsabilidade do sistema de controlo de concorrncia Durabilidade: Depois de efectivada a transaco h que garantir que os dados se mantm, mesmo que haja qualquer falha de sistema. Da responsabilidade do sistema de recuperao. 13.2. Suponha que haja um sistema de banco de dados que nuca falhe. Um gerenciador de recuperao necessrio para esse sistema? No, uma vez que este responsvel pela recuperao de dados consistentes quando h uma falha a meio de uma transaco que tem de ser pois abortada, ou de uma falha mesmo aps a efectivao de uma transaco para garantir a durabilidade. Se no h falhas, no se justifica este componente. 13.3. Considere o sistema de arquivo de seu sistema operativo favorito. Os aspectos de atomicidade e durabilidade so relevantes em relao aos seguintes itens? Justifique a sua resposta. (a) Utilizador do sistema operativo (b) Implementador do sistema de ficheiros. (b) Sim. Por exemplo se o utilizador manda gravar um ficheiro para actualizao, espera-se que o sistema grave/actualize a verso antiga totalmente, ou, se impossvel por falha, que no faa nada, de modo a ter acessvel a verso antiga. Por outro lado, quanto durabilidade tambm pois se se termina a operao (efectivao) que, eventualmente, apaga verses anteriores, espera-se que essa verso se mantenha para sempre. (a) No. O utilizador no tem que se preocupar com isso. 13.4. Os implementadores de sistemas de banco de dados prestaram muito mais ateno s propriedades ACID que os implementadores de sistemas de arquivo. Por qu? Porque uma base de dados, se no atender aquelas propriedades, rapidamente deixa de ser fivel e os dados tornam-se completamente inconsistentes. Alm disso as bases de dados jogam com grandes quantidades de informao interrelacionada e por vezes sensvel e, onde, inconsistncias no so fceis de descobrir. No caso dos sistemas de ficheiros embora possa ser produzida informao inconsistente, muito mais fcil descobrir esse facto. 13.5. Durante a sua execuo, uma transaco atravessa vrios estados, at ser finalmente efectivada ou abortada. Liste todas as possveis sucesses de estados pelos quais uma transaco pode passar. Explique por que cada transio de estado pode acontecer. Activa estado inicial em execuo parcialmente efectivada depois de a ltima operao j ter sido feita mas ainda em memria. Daqui pode ir para abortada ou efectivada efectivada Concluda, sem possibilidade de ser abortada Em falha... abortada Chegou-se concluso que a transaco no pode ser terminada. H que recuperar os dados antigos e desfazer as operaes da transaco j realizadas. 13.6. Explique a distino entre os termos escala sequencial e escala serializvel Escala sequencial quando as transaces se realizam uma a seguir outra. No h concorrncia. Escala serializvel uma escala em que embora isso no se verifique, os resultados so equivalentes a uma escala sequencial. 13.7. Considere as duas transaces seguintes:

read(A); read(B); if A = 0 then B:= B+1; write(B) T2: read(B); read(A); if B = 0 then A:=A+1; write(A) Seja um requisito de consistncia A=0 V B=0, com valores iniciais A=B=0. (a) Mostre que toda a execuo sequencial que envolve essas duas transaces preserva a consistncia do banco de dados. Se T1, T2, o resultado final B=1 e A=0 pois o if de T2 falso. Similarmente se T2,T1 o resultado final A=1 e B=0, pelo que a consistncia se preserva. (b) Mostre uma execuo concorrente de T1 e T2 que produza uma escala no serializvel T1 T2 read(A) read(B) read(B) read(A) if B ... write(A) if A... write(B) Aqui a consistncia j no seria preservada pois ambas as transaces fazem as leituras dos valores antes de qualquer outra operao, o que leva a que A e B sejam zero nessas leituras e que vo depois ser alterados para 1. A razo da no serializao que a escala no equivalente a nenhuma sequencial. Pela disposio pode ver-se que nunca vou poder obter (por trocas sucessivas de posio) uma escala sequencial visto que no posso trocar a ordem de write(A) de T2 por write(B) de T1 nem de read(A) de T1 por write(A) de T2 (c) H uma execuo concorrente de T1 e T2 que produza uma escala serializvel? Sim porque o grfico de precedncia no contm ciclos T1 --------> T2 ex: read(B) read(A) read(A) if A ... write(B) read(B) if B... write(A) 13.8. Dado que toda a escala conflito serializvel viso serializvel, por que enfatizamos serializao de conflito em vez de serializao de viso? Porque o algoritmo para testar a serializao de conflito muito mais simples. 13.9. Considere o grfico de precedncia da figura. A escala correspondente conflito serializvel? Justifique. . O grfico de precedncia no tem ciclos. 13.10.

T1: