63808532 banco de dados ii

EQUIPE UNITINS

Organização de Conteúdos Acadêmicos Carlos Henrique Corrêa Tolentino

Coordenação Editorial Maria Lourdes F. G. Aires

Revisão Lingüístico-Textual Silvéria Aparecida BasniaK Schier

Gerente de Divisão de Material Impresso Katia Gomes da Silva

Revisão Digital Helena Costa e Lima Prestes

Projeto Gráfico Irenides TeixeiraKatia Gomes da Silva

Ilustração Geuvar S. de Oliveira

Capas Igor Flávio Souza

EQUIPE EADCON

Coordenador Editorial William Marlos da Costa

Assistentes de Edição Ana Aparecida Teixeira da CruzJanaina Helena Nogueira BartkiwLisiane Marcele dos Santos

Programação Visual e Diagramação Denise Pires PierinKátia Cristina Oliveira dos SantosMonica ArdjomandRodrigo SantosSandro NiemiczWilliam Marlos da Costa

Apr

esen

taçã

o

Prezado estudante,

Este caderno de Bancos de Dados representa a continuidade da disci-plina anterior. As discussões agora são voltadas para aspectos de projeto de bancos de dados relacionais. Os bancos de dados relacionais são os mais utilizados no mercado e, por essa razão, seu estudo é essencial.

Considerando que grande parte dos sistemas de informação e aplicativos em geral manipulam dados e informações que ficam armazenadas perma-nentemente, o projeto de bancos de dados relacionais se torna uma área de grande importância.

O conteúdo deste caderno permite a você ter uma visão geral a respeito de diversos conceitos para o projeto de bancos de dados. Esses conceitos permeiam as fases de definições conceituais e revisão, também questões de implantação e de manutenção da confiabilidade, consistência e disponibili-dade do banco de dados. Além disso, permite auxiliar o futuro analista de sistemas na tomada de decisões a respeito de quais tecnologias utilizar para tirar o máximo de proveito dos recursos computacionais disponíveis.

Bons estudos!

Prof. Carlos Henrique Corrêa Tolentino

EMENTA

Projeto de banco de dados relacional. Transações. Controle de concor-rência. Sistemas de recuperação. Banco de dados distribuídos.

OBJETIVOS

Apresentar conceitos comumente encontrados na literatura e no •mercado na área de bancos de dados.

Oferecer uma base para a tomada de decisões em relação a •como proceder na atividade de projetar um banco de dados relacional.

CONTEÚDO PROGRAMÁTICO

Conceitos de projetos de bancos de dados relacionais•

Dependências funcionais•

Normalização•

Transações e controle de concorrência•

Classificação de falhas e sistemas de recuperação•

Bancos de dados distribuídos e outras tecnologias emergentes•

Plan

o de

Ens

ino

unitins • Análise e desenvolvimento de sistemAs • 3º PeRÍodo 121

BIBLIOGRAFIA BÁSICA

DATE, C. J. Introdução a sistemas de banco de dados. Rio de Janeiro: Elsevier, 2003.

ELMASRI, Ramez E.; NAVATHE, Shamkant B. Sistemas de banco de dados. São Paulo: Pearson Prentice Hall, 2005.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de bancos de dados. São Paulo: Campus, 2006.

BIBLIOGRAFIA COMPLEMENTAR

HEUSER, Carlos Alberto. Projeto de banco de dados. Porto Alegre: Sagra Luzzatto, 2004.

LIGTHSTONE, Sam; TEOREY, Toby; NADEAU, Tom. Projeto e modelagem de bancos de dados. Rio de Janeiro: Campus, 2006.

MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e implementação. São Paulo: Érica, 2004.

MONTEIRO, Emiliano Soares. Projeto de sistemas e banco de dados. Rio de Janeiro: Brasport, 2004.

Esperamos que, ao final desta aula, você seja capaz de:

compreender os conceitos de dependência funcional e sua importância •no contexto de bancos de dados;

entender os conceitos de normalização e sua aplicação.•

Para que os objetivos desta aula sejam atingidos, é importante que você domine os conceitos de relações, entidades, atributos, chaves, relacionamentos e cardinalidade. Além disso é importante ter uma visão geral da organização de um banco de dados relacional. Esses conteúdos foram vistos na disciplina de Bancos de Dados do segundo período e são importantes para a compreensão da dependência funcional e da normalização.

Atualmente, muitos softwares que compõem os sistemas de informação podem ser considerados apenas uma interface entre os usuários e os dados armazenados. Esse raciocínio é ilustrado na figura que segue.

Figura 1 Ilustração da relação entre aplicativos, usuários e bancos de dados.

Nesse cenário, um elemento importante não pode deixar de ser conside-rado: o sistema gerenciador de banco de dados - SGBD. O SGBD tem, entre outras funções, a responsabilidade de gerenciar o acesso dos aplicativos às bases de dados por ele gerenciadas.

AulA 1 • bAnco de dAdos



compreender os conceitos de dependência funcional e sua importância •no contexto de bancos de dados;

entender os conceitos de normalização e sua aplicação.•

Para que os objetivos desta aula sejam atingidos, é importante que você domine os conceitos de relações, entidades, atributos, chaves, relacionamentos e cardinalidade. Além disso é importante ter uma visão geral da organização de um banco de dados relacional. Esses conteúdos foram vistos na disciplina de Bancos de Dados do segundo período e são importantes para a compreensão da dependência funcional e da normalização.

Atualmente, muitos softwares que compõem os sistemas de informação podem ser considerados apenas uma interface entre os usuários e os dados armazenados. Esse raciocínio é ilustrado na figura que segue.

Figura 1 Ilustração da relação entre aplicativos, usuários e bancos de dados.

Nesse cenário, um elemento importante não pode deixar de ser conside-rado: o sistema gerenciador de banco de dados - SGBD. O SGBD tem, entre outras funções, a responsabilidade de gerenciar o acesso dos aplicativos às bases de dados por ele gerenciadas.

Dependência funcional e normalização

Aula 1


124 3º PeRÍodo • Análise e desenvolvimento de sistemAs • unitins

Em geral, o objetivo do projeto de um banco de dados relacional é um esquema de relações que nos permite armazenar um conjunto de dados sem redundância, além de possibilitar a rápida recuperação de informações (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). A qualidade de um projeto é tão importante quanto a qualidade dos softwares que fazem a interface com o usuário, embora, em muitas situações o público-alvo de um projeto não tenha acesso, ou noção, das ações e esquemas que são implementados.

Alguns conceitos são de extrema importância no projeto de bancos de dados relacionais, como a dependência funcional e a normalização de dados, que é o foco de estudo desta aula.

1.1 Dependência funcional

A dependência funcional pode ser definida como uma restrição entre dois conjuntos de atributos de uma mesma entidade/relação (ALVES, 2004). Essa definição pode ser feita sob uma linguagem mais precisa. Elmasri e Navathe (2005) afirmam que uma dependência funcional, denotada por X→Y entre dois conjuntos de atributos (que são subconjuntos) de uma relação R especificam uma restrição nas possíveis tuplas que formem um estado da relação r de R. A restrição é que, para quaisquer duas tuplas t1 e t2 em r que tenham t1[X] = t2[X], elas também têm de ter t1[Y] = t2[Y].

Isso significa dizer que os valores do componente de Y, de uma tupla em r, dependem ou são determinados por valores do componente de X. Alternativamente, os valores de X determinam exclusivamente (ou funcionalmente) os valores de Y. A partir do exposto, dizemos que Y é funcionalmente dependente de X. O conceito de dependência funcional é explicado e exemplificado a seguir.

Considere uma relação Matrícula com os seguintes atributos: mat_aluno, cod_curso, cod_disciplina, nome_aluno, data_matricula, nome_disciplina, nome_curso e nota_prova. Uma relação de dependência entre esses atributos é ilustrada na figura a seguir.

Figura 2 Ilustração de dependência funcional parcial.



Se considerarmos X como sendo o conjunto formado pelos atributos matri-cula_aluno, cod_curso e cod_disciplina, que são justamente os atributos que compõem a chave primária dessa relação, e Y como sendo o conjunto formado pelos atributos nome_aluno e data_matricula, podemos dizer que os valores dos atributos de Y dependem do atributo matricula_aluno, que pertence ao conjunto X. Esse tipo de dependência, na qual o conjunto Y é dependente apenas de parte da chave primária da relação, é chamada de dependência parcial. Note que o nome do aluno e a data de sua matrícula em uma determinada disciplina de um curso são valores, geralmente, armazenados em uma relação com infor-mações sobre o aluno.

As figuras a seguir ilustram outras possibilidades de dependência funcional dentro da mesma relação.

Figura 3 Outras possibilidades de dependência funcional: cod_curso e nome_curso.

Figura 4 Outras possibilidades de dependência funcional: nome_disciplina e cod_disciplina.

Note, na Figura 3, que o atributo nome_curso é dependente apenas do cod_curso, enquanto que, na Figura 4, o atributo nome_disciplina é dependente apenas do atributo cod_disciplina.



Outro tipo de dependência é a dependência total, ou completa, na qual um determinado conjunto de atributos é dependente de todos os atributos que compõem a chave primária da relação. Utilizando o mesmo exemplo de relação das figuras anteriores, a Figura 5 ilustra uma dependência funcional total.

Figura 5 Exemplo de dependência funcional total.

Observe que, diferentemente das outras ilustrações de dependência, o atri-buto nota_prova não pode ser associado a apenas parte da chave primária, pois a nota de uma prova deve estar, sempre, relacionada ao aluno que fez a prova, a disciplina em questão e também o curso ao qual a disciplina pertence. Esse é um exemplo clássico de dependência funcional total.

Existe ainda m tipo de dependência chamada de dependência transitiva. Esse tipo de dependência é caracterizado por uma situação na qual um determi-nado conjunto de atributos Y é funcionalmente dependente de um atributo que não faz parte da chave primária da relação. Ainda aproveitando o exemplo anterior, a Figura 6 ilustra este tipo de dependência.

Figura 6 Exemplo de dependência transitiva.

Observe que foi adicionado o atributo status, usado para indicar se o aluno está reprovado ou aprovado. Note que a aprovação ou reprovação do aluno é



dependente exclusivamente da nota obtida na prova realizada pelo aluno, que não faz parte da chave primária da relação.

1.1.1 Redundância e anomalias

De acordo com as dependências funcionais que estiverem presentes em um banco de dados, existe a possibilidade de surgirem diversos tipos de problemas. Um deles é a redundância. Ainda abordando o exemplo supracitado, observe que as únicas informações armazenadas que dizem respeito aos alunos são matricula_aluno, nome_aluno. É natural, que nesse banco de dados, exista uma tabela chamada Aluno, na qual estejam contidos atributos como endereço, filiação, etc. Dessa maneira, ao inserir informações como nome_aluno, estamos duplicando desnecessariamente uma informação.

Uma solução aparente para esse problema seria unificar as relações, de maneira que as informações adicionais da entidade Aluno sejam presentes na relação apresentada nas figuras anteriores. Essa ação geraria uma anomalia, já que somente poderíamos inserir um registro da entidade Aluno quando houvesse uma matrícula e, além disso, para cada matrícula de cada disciplina, novamente teríamos as informações duplicadas.

Complementando, podemos afirmar que tais problemas se agravam nas ações de exclusão e atualização, já que, ao se excluir a matrícula de um aluno, estaríamos excluindo também o registro do próprio aluno. Além disso, atua-lizações feitas em informações duplicadas devem ser propagadas para cada registro que contiver aquelas informações.

Nesse cenário, surgem questionamentos sobre como resolver esses problemas. A resposta reside nas técnicas de normalização, que são discutidas a seguir.

1.2 Normalização

Segundo Elmasri e Navathe (2005), a normalização de dados pode ser vista como o processo de análise de determinados esquemas de relações com base em suas dependências funcionais e chaves primárias para alcançar as propriedades desejáveis de minimização de:

redundância•

anomalias de inserção•

anomalias de exclusão•

anomalias de atualização•

Machado e Abreu (1996) sugerem duas abordagens para empregar a técnica de normalização de dados. Vejamos, a seguir, quais essas abordagens.

Abordagem • top-down: após a definição de um modelo de dados, apli-camos a normalização para obtermos uma síntese dos dados, bem como



uma decomposição das entidades e relacionamentos em elementos mais estáveis, tendo em vista uma futura implementação física em um banco de dados.

Abordagem • bottom-up: consiste em aplicar a normalização como ferra-menta de projeto do modelo de dados, para que, inicialmente já se construa um modelo de dados normalizado.

Segundo Alves (2004), a forma normal de uma relação indica o grau de normalização no qual a relação se encontra. Academicamente falando, existem cinco formas normais, embora apenas as três primeiras já sejam suficientes para termos uma boa definição da estrutura do banco de dados. No fim da normali-zação, teremos a resposta para uma das perguntas que surgem quando iniciamos um projeto: quantas tabelas serão necessárias em nosso banco de dados?

Após a aplicação da normalização, independente da abordagem (bottom-up ou top-down), esperamos obter um banco de dados com as seguintes características:

robustez•

eficiência•

facilidade de manutenção e alteração•

flexibilidade•

confiabilidade•

Vejamos, nos tópicos a seguir, as três formas normais para que haja defi-nição da estrutura do banco de dados.

1.2.1 A primeira forma normal

Existem muitos bancos de dados que armazenam informações multivalo-radas. Essas informações são passíveis de decomposição. Uma informação que não pode, ou não precisa ser decomposta é chamada de informação atômica. Segundo Silberchartz, Korth e Sudarshan (2006), dizemos que uma relação R se encontra na primeira forma normal se todos os atributos de R são atômicos.

Um exemplo clássico de atributo multivalorado é o campo endereço, presente em muitas relações em bancos de dados. Considerem uma relação Aluno contendo os atributos: matricula_aluno, nome_aluno, fone, endereço e data_nasc. Todos nós sabemos que o endereço é composto por outras informa-ções, como cidade, estado, CEP, bairro, rua, número e complemento. Dessa maneira não é difícil perceber que existe nessa relação um atributo multivalo-rado. Para adequar essa relação à primeira forma normal, poderíamos refiná-la para a forma sugerida na figura a seguir.



Figura 7 Decomposição do atributo endereço.

Outra ação de normalização que pode ser implementada é a criação de uma nova relação contendo os atributos do campo multivalorado, mantendo-se o vínculo dessa relação com a chave primária da relação original. A Figura 8 ilustra essa solução.

Figura 8 Outra opção de normalização.

Observe que agora temos duas tabelas relacionadas pela chave estrangeira mat_aluno criada na tabela ENDEREÇO.

1.2.2 A segunda forma normal

Segundo Elmasri e Navathe (2005), a segunda forma normal é baseada no conceito de dependência funcional total. Alves (2004) complementa afirmando que colocar as entidades na segunda forma normal é um pouco mais difícil que na primeira. Uma entidade se encontra na segunda forma normal se, além de estar na primeira, todos os seus atributos são totalmente dependentes da chave



primária composta. Note que essa forma normal não se aplica as relações com uma chave primária simples (composta por um único atributo). Isso significa que atributos parcialmente dependentes da chave serão removidos.

A remoção dos atributos parcialmente dependentes não significa propria-mente que essas informações serão perdidas, mas podem ser alocadas em outra relação, ou ainda, removendo-as, estaríamos apenas deixando de duplicá-las.

Para ilustrar a aplicação da segunda forma normal, vamos considerar um domínio no qual tenhamos o relacionamento apresentado na Figura 9.

Figura 9 Relacionamento em um domínio de aplicação.

Observe que, na tabela ITENS, os atributos descrição e valor unitário não são dependentes da chave primária composta pelo campo num_pedido e cod_produto. A sua remoção não indica necessariamente que eles deixem de ser armazenados no banco de dados, mas uma ação de normalização poderia agir no sentido de repassar essas informações para outra relação, como apresentado na solução a seguir, ilustrada na Figura 10.

Figura 10 Resultado da aplicação da segunda forma normal.

Analisando esse novo diagrama, percebemos que a adequação à segunda forma normal foi efetuada sem a perda da capacidade de recuperação das informações. Por exemplo, para que um aplicativo possa determinar o valor total de um pedido, basta consultar quais itens estão contidos nesse pedido, a quan-tidade de cada item e o seu valor unitário na tabela produto.



1.2.3 A terceira forma normal

Elmasri e Navathe (2005) também descrevem a terceira forma normal. Uma relação se encontra na terceira forma normal quando não há nenhuma depen-dência transitiva, ou seja, quando nenhum atribuo é dependente de um conjunto X de atributos tal que um elemento qualquer de X não faça parte da chave primária. Um exemplo de dependência transitiva já foi mostrado anteriormente, no qual o valor de um campo status era dependente do valor do campo nota. O campo status deve ser removido da relação para que ela esteja na terceira forma normal. Uma possível solução para o problema seria o que está exposto na figura a seguir.

Figura 11 Resultado da aplicação da terceira forma normal.

Nesse exemplo, além de remover a dependência transitiva, inserimos na tabela DISCIPLINA o campo nota_ap, que é a nota mínima para a aprovação. Dessa maneira, podemos determinar se um aluno foi aprovado em uma disci-plina verificando se a nota_prova desse aluno tem valor igual ou superior ao valor do campo noa_ap da disciplina em questão. Note que essas associações são possíveis por meio da utilização das chaves estrangeiras mat_aluno e cod_disc na tabela MATRÍCULA.

A partir da identificação das dependências funcionais e das aplicação das técnicas de normalização, poderemos projetar e construir bancos de dados com as características que permitem um bom desempenho. São as já citadas:

robustez•eficiência•facilidade de manutenção e alteração•flexibilidade•confiabilidade•

Portanto, a partir do que analisamos nesta aula, percebemos que ignorar dependências funcionais e normalização pode trazer diversos problemas na utili-zação de banco de dados. Assim, ao projetarmos um banco de dados desde o seu início (abordagem bottom-up) ou mesmo um banco de dados já em operação (abordagem top-down), devemos aplicar as técnicas de normalização.



Nesta aula, estudamos conceitos muito importantes para o projeto de bancos de dados relacionais: dependência funcional e normalização. Uma dependência funcional é uma restrição imposta sobre conjuntos de atributos de uma relação. Já a normalização é processo de análise de determinados esquemas de relações com base em suas dependências funcionais e chaves primárias para alcançar as propriedades desejáveis de minimização de redundância, anomalias de inserção, anomalias de exclusão, anomalias de atualização.

Estudamos que a identificação dos tipos de dependências funcionais (parcial, total e transitiva), além da correta aplicação da normalização (primeira, segunda e terceira formas normais) são importantes para que tenhamos em mãos um bom projeto de banco de dados.

1. A respeito de dependências funcionais, assinale a alternativa correta.

a) Pode existir dependência funcional entre atributos de entidades diferentes.

b) Para a eliminação de qualquer tipo de dependência funcional, devemos apenas reorganizar os atributos de uma relação, nunca criar outras rela-ções ou apagar atributos.

c) Alguns tipos de dependência funcional podem resultar em problemas, como a redundância de dados.

d) A redundância de dados causada por alguns tipos de dependências funcionais, não pode ser considerada um problema, já que dados redun-dantes somente são usados para leitura e não para atualizações.

2. Dê exemplos de situações nas quais seja indicado utilizar as abordagens para normalização de dados (top-down e bottom-up).

3. Sobre normalização, é incorreto afirmar que:

a) a segunda forma normal diz respeito às dependências funcionais parciais;

b) a terceira forma normal trata das dependências transitivas em uma relação;

c) a primeira e a segunda formas normais tratam do mesmo tipo de depen-dência funcional. A primeira apenas substitui os atributos, enquanto que a segunda cria outras relações para transferir tais atributos.

d) para que uma relação esteja de acordo com a terceira forma normal, ela deve estar também de acordo com a segunda forma normal.

4. Que tipo de problemas pode ocorrer em um banco de dados cujas relações não observam nenhuma das formas normais?

Que tal conferir se você acertou as respostas e atingiu os objetivos da aula? Iniciamos então pela atividade um. A alternativa (a) é incorreta, já que, segundo a definição de dependência funcional, um conjunto de atributos de uma relação R é funcionalmente dependente de outro conjunto de atributos da mesma relação. De acordo com as regras de normalização, em alguns casos, atributos podem ser reorganizados e em outros casos removidos, portanto, a alternativa (b) também é incorreta. De acordo com a sessão que fala de redun-dância e anomalias, uma dependência funcional mal projetada pode trazer problemas, logo, a alternativa (c) é a correta. A alternativa (d) é totalmente incorreta, já que a redundância é um problema comum em bancos de dados mal projetados e, além disso, esse problema independe das ações de leitura e ou atualização de itens de dados.

Na atividade dois, você considerou que a abordagem top-down é aplicada sobre um modelo conceitual já definido. Com isso, uma situação comum para utilização desse tipo de abordagem é a manutenção de bancos de dados, ou ainda, implementação de alterações na estrutura do banco de dados. Em relação à abordagem bottom-up, é comum encontrá-la quando se deseja construir um banco de dados partindo do início, ou seja, a normalização não será aplicada sobre um modelo conceitual definido.

Na atividade três, a alternativa incorreta é a letra (c), que compara a primeira e a segunda forma normal, entretanto, cita-as de maneira errônea, já que a primeira forma normal trata de atributos multivalorados e não de dependência funcional, enquanto que a segunda forma normal trata somente das dependên-cias funcionais parciais.

Na atividade quatro, você apontou os problemas que podem surgir se não observarmos as formas normais: redundância e os diferentes tipos de anomalias, por exemplo, anomalias de inserção que nos forçam a inserir informações dupli-cadas e, além disso, obrigam a um esforço maior nas exclusões que devem ser propagadas.

ALVES, Willian P. Sistema de bancos de dados. São Paulo: Érica, 2004.




4. Que tipo de problemas pode ocorrer em um banco de dados cujas relações não observam nenhuma das formas normais?

Que tal conferir se você acertou as respostas e atingiu os objetivos da aula? Iniciamos então pela atividade um. A alternativa (a) é incorreta, já que, segundo a definição de dependência funcional, um conjunto de atributos de uma relação R é funcionalmente dependente de outro conjunto de atributos da mesma relação. De acordo com as regras de normalização, em alguns casos, atributos podem ser reorganizados e em outros casos removidos, portanto, a alternativa (b) também é incorreta. De acordo com a sessão que fala de redun-dância e anomalias, uma dependência funcional mal projetada pode trazer problemas, logo, a alternativa (c) é a correta. A alternativa (d) é totalmente incorreta, já que a redundância é um problema comum em bancos de dados mal projetados e, além disso, esse problema independe das ações de leitura e ou atualização de itens de dados.

Na atividade dois, você considerou que a abordagem top-down é aplicada sobre um modelo conceitual já definido. Com isso, uma situação comum para utilização desse tipo de abordagem é a manutenção de bancos de dados, ou ainda, implementação de alterações na estrutura do banco de dados. Em relação à abordagem bottom-up, é comum encontrá-la quando se deseja construir um banco de dados partindo do início, ou seja, a normalização não será aplicada sobre um modelo conceitual definido.

Na atividade três, a alternativa incorreta é a letra (c), que compara a primeira e a segunda forma normal, entretanto, cita-as de maneira errônea, já que a primeira forma normal trata de atributos multivalorados e não de dependência funcional, enquanto que a segunda forma normal trata somente das dependên-cias funcionais parciais.

Na atividade quatro, você apontou os problemas que podem surgir se não observarmos as formas normais: redundância e os diferentes tipos de anomalias, por exemplo, anomalias de inserção que nos forçam a inserir informações dupli-cadas e, além disso, obrigam a um esforço maior nas exclusões que devem ser propagadas.





MACHADO, N. R.; ABREU, M. Projeto de banco de dados: uma visão prática. São Paulo: Érica, 1996.


Estudaremos os conceitos relacionados ao armazenamento e à recuperação de informações. Abordaremos mais precisamente os arquivos de registros e outras formas de armazenamento. Analisaremos também as técnicas de inde-xação e hashing usadas para acessar os itens de dados armazenados.

Esperamos que, ao final desta aula, você seja capaz de:compreender a maneira como os bancos de dados são armazenados •em arquivos;compreender a forma de acesso aos arquivos que compõem um banco •de dados.

Para que os objetivos desta aula sejam atingidos, é importante que você entenda o conceito de armazenamento de dados em arquivos, conheça os tipos de memória. É importante também que domine a noção de tabelas e registros de um banco de dados. Tais assuntos foram abordados largamente em disciplinas como Bancos de Dados (no segundo período), Programação e Computação Básica. Eles são importantes para esta aula pelo fato de estarem relacionados com os conceitos de armazenamento, indexação e hashing, foco de estudo desta aula.

Os bancos de dados geralmente armazenam grandes quantidades de dados que devem ser mantidos por longos períodos de tempo. Durante esse tempo, os dados podem ser acessados e processados repetidas vezes (ELMASRI; NAVATHE, 2005). Atualmente os computadores têm uma capacidade de armazenamento muito superior aos computadores de uma década atrás. Porém a arquitetura da maioria desses computadores, sobretudo os computadores pessoais, ainda se apóia na mesma arquitetura, que faz um uso muito grande da chamada memória principal, ou memória RAM.

Embora a velocidade de acesso a dados permitida pelos dispositivos de armazenamento atuais seja consideravelmente alta, a forma como os dados estão estruturados influencia diretamente no desempenho de um sistema de banco de dados. Existem diversas técnicas de armazenamento. Elas apresentam

Anotações



Esperamos que, ao final desta aula, você seja capaz de:compreender a maneira como os bancos de dados são armazenados •em arquivos;compreender a forma de acesso aos arquivos que compõem um banco •de dados.

Para que os objetivos desta aula sejam atingidos, é importante que você entenda o conceito de armazenamento de dados em arquivos, conheça os tipos de memória. É importante também que domine a noção de tabelas e registros de um banco de dados. Tais assuntos foram abordados largamente em disciplinas como Bancos de Dados (no segundo período), Programação e Computação Básica. Eles são importantes para esta aula pelo fato de estarem relacionados com os conceitos de armazenamento, indexação e hashing, foco de estudo desta aula.

Os bancos de dados geralmente armazenam grandes quantidades de dados que devem ser mantidos por longos períodos de tempo. Durante esse tempo, os dados podem ser acessados e processados repetidas vezes (ELMASRI; NAVATHE, 2005). Atualmente os computadores têm uma capacidade de armazenamento muito superior aos computadores de uma década atrás. Porém a arquitetura da maioria desses computadores, sobretudo os computadores pessoais, ainda se apóia na mesma arquitetura, que faz um uso muito grande da chamada memória principal, ou memória RAM.

Embora a velocidade de acesso a dados permitida pelos dispositivos de armazenamento atuais seja consideravelmente alta, a forma como os dados estão estruturados influencia diretamente no desempenho de um sistema de banco de dados. Existem diversas técnicas de armazenamento. Elas apresentam

Armazenamento, indexação e hashing

Aula 2



vantagens e desvantagens que podem se aplicar melhor a um determinado tipo de aplicação. A determinação do tipo de armazenamento a ser utilizado faz parte do projeto físico do banco de dados.

Em geral, bancos de dados relacionais são armazenados em arquivos de registros. É comum encontrarmos bancos de dados muito grandes para serem processados de uma só vez, dessa maneira, apenas os registros que estão sendo acessados em um determinado momento são carregados para a memória prin-cipal. Após a sua manipulação, eles são devolvidos para o dispositivo de arma-zenamento definitivo. Nesta aula, estudaremos algumas técnicas de armazena-mento e acesso a dados armazenados em um banco de dados relacional.

2.1 Arquivos de registros

Um registro é uma coleção de informações relacionadas, no qual cada uma das informações é chamada de campo (ELMASRI; NAVATHE, 2005). Os regis-tros, em geral, descrevem as entidades e seus atributos. Um arquivo de registros é uma seqüência de registros armazenada eletronicamente. Um arquivo de regis-tros pode se enquadrar em dois tipos principais: desordenado e ordenado.

2.1.1 Arquivos de registros desordenados

Este é o tipo de organização mais básico, no qual a inserção de registros pode ser feita, simplesmente, ao final do arquivo. Nesse tipo de organização, a operação de inserção é muito eficiente, já que pode ser feita utilizando ponteiros para as posições dos registros.

Por outro lado, uma operação de busca de um registro pode se tornar extre-mamente dispendiosa em termos de tempo computacional, já que, com os regis-tros desordenados, é necessário que se realize uma busca seqüencial, ou seja, o sistema vê-se obrigado a percorrer todos os registros do arquivo seqüencial-mente. No pior caso, chega-se ao final do arquivo para só então descobrir que a informação buscada não está armazenada.

2.1.2 Arquivos de registros ordenados

Os arquivos de registros ordenados apresentam algumas vantagens em relação aos desordenados. Uma dessas vantagens reside na busca por elementos: considerando que os registros estão ordenados de acordo com um critério defi-nido por um campo do registro, podemos implementar a busca binária.

Saiba mais



Por outro lado, as operações de inserção e remoção em arquivos de regis-tros ordenados podem ser muito dispendiosas, já que os registros devem perma-necer ordenados fisicamente. Se um registro deve ser inserido na metade do arquivo (de acordo com o campo usado como critério de ordenação), todos os registros posteriores a ele devem ser movidos uma posição à frente para que o novo registro seja alocado no arquivo. Assim podemos perceber que essa forma de armazenamento é eficiente, mas pode resultar no aparecimento dos mesmos problemas do armazenamento não ordenado.

Uma possibilidade de minimizar esses problemas é usar um arquivo de overflow. Segundo essa técnica, os novos registros são inseridos em outro arquivo e, nesse arquivo adicional, a leitura e a escrita são feitas de maneira linear. Em intervalos de tempo periódicos (possivelmente nos horários de menor acesso ao banco de dados), efetuam a inserção dos registros do arquivo de overflow no arquivo original.

A utilização de arquivos de registros ordenados traz ainda implicações sobre as operações de atualização, pois, caso o campo chave para a orde-nação seja um dos valores alterados, será necessário reposicionar o registro atualizado dentro do arquivo. Além disso, em uma busca, somente podemos utilizar a pesquisa binária quando o campo chave para ordenação for um dos campos envolvidos na busca.

Você já deve ter percebido as limitações desse modo de armazenamento. Devido a elas, a utilização de arquivos de registros ordenados é rara na imple-mentação de bancos de dados.

2.2 Técnica de hashing

Existe outro tipo de organização primária de arquivos de registros, que é baseada em hashing ou tabelas de espalhamento. Uma tabela de espalhamento é uma estrutura de dados na qual cada registro deve ter um campo que será utili-zado como chave para uma função de espalhamento. Essa função irá, a partir do campo escolhido, determinar em qual bloco esse registro deve ser armazenado. Essa mesma função de espalhamento pode ser usada na busca por um registro. A eficiência dessa técnica reside no fato de que a busca será baseada em uma função que, geralmente, utiliza cálculos matemáticos para agilizar o processamento.

É comum encontrarmos implementações de hashing usando vetores, nos quais cada posição do vetor (slot, fenda ou bloco) é usada para armazenar um registro. Nesse caso, a função de espalhamento deverá ter como entrada o valor do campo de hash e retornará um índice do vetor, indicando onde o registro deve ser armazenado. Um exemplo seria transformar o campo de hash em um valor inteiro M e aplicar a função f(M) = M mod N, onde N é a quantidade de fendas disponíveis e mod é um operador que retorna o resto da divisão do operando à esquerda pelo operando à direita.



Devemos considerar que existe a possibilidade de que dois valores diferentes de entrada para a função de espalhamento resultem em valores de retorno idên-ticos. Além disso, é comum encontrarmos situações nas quais o número de regis-tros a serem armazenados é muito maior do que a quantidade de blocos dispo-níveis. Esse cenário é propício para o aparecimento de colisões. Uma colisão acontece quando dois registros são encaminhados para o mesmo bloco.

Uma maneira de tratar colisões é utilizar a técnica de encadeamento. De acordo com essa técnica, cada posição do vetor é utilizada como o início de uma lista encadeada. Assim, quando houver uma colisão, os elementos são inseridos nessa lista.

Uma implicação da utilização do encadeamento é que, em uma busca, quando for determinado o bloco no qual se encontra o registro, usando a função de espalhamento, inicia-se uma busca linear, degenerando o desempenho da estrutura de hash.

Uma função de espalhamento considerada ótima é a que nunca retorna valores idênticos para valores de entrada diferentes. Porém essa situação é inviável, já que seria necessário ter tantas posições no vetor quantos registros para armazenamento. Uma função de espalhamento pode ser considerada boa quando chega próximo do chamado espalhamento uniforme, no qual os regis-tros ficam distribuídos de maneira equilibrada nos diversos blocos disponíveis. Um espalhamento é dito uniforme quando a diferença entre o bloco com maior número de elementos e o bloco com menor número de elementos é, no máximo, dois. Outra característica para uma boa função de espalhamento é que sejam utilizados todos os blocos do vetor.

2.3 Indexação

Um índice para um arquivo de um sistema de banco de dados funciona quase da mesma forma que o índice remissivo de um livro. Se quisermos procurar por um termo em particular, vamos ao final do livro, procuramos esse termo, e descobriremos a página que o contém. Podemos, então, ir à página e buscar as informações desejadas (SILBERCHARTZ; KORTH; SUDARSHAN, 2006).

A utilização de um índice remissivo somente é útil se ele estiver ordenado, dimi-nuindo o esforço necessário para encontrar um determinado termo. Esse mesmo cenário pode ser aplicado ao armazenamento de registros de um banco de dados.

Para obter acesso aleatório rápido aos registros em um banco de dados, podemos utilizar uma estrutura de índice. Essa estrutura define um arquivo, contendo dados (índices) associados aos campos de um registro. Cada um desses índices contém um ponteiro para o registro ao qual está associado. Dessa maneira, estando os índices ordenados, podemos utilizar a pesquisa binária e, então, acessar o registro desejado por meio do ponteiro contido no arquivo de índice.



O aspecto que descreve a vantagem de utilizar índices reside no fato de que manter apenas uma parte do registro ordenada é computacionalmente mais barato do que manter todo o arquivo de registros ordenado. Além disso, ao contrário dos arquivos de registros ordenados, podemos utilizar vários índices para uma mesma entidade, de modo que cada atributo seja referenciado por um índice diferente. A Figura 1 a seguir traz uma ilustração desse conceito.

Figura 1 Exemplo de indexação.

Observe na Figura 1 que a ordem dos elementos do índice é diferente da ordem dos registros correspondentes. A associação é feita utilizando ponteiros. Um campo que serve de índice é chamado de campo de indexação. Nesse exemplo temos apenas um campo de indexação, porém, como já afirmado ante-riormente, podem existir diversos campos de indexação para um mesmo registro, como ilustra a Figura 2 a seguir.

Figura 2 Exemplo de indexação com dois índices.



Observe que, no segundo exemplo, existem dois campos utilizados como índices: o ano e o autor. Existem diversas outras situações nas quais é útil utili-zarmos índices, por exemplo, na definição de atributos que não são chave, porém não devem ser duplicados. É importante ressaltar que, em muitos casos, a própria chave primária do registro é utilizada como campo de indexação.

Sabemos que em muitos bancos de dados, os atributos que são chave primária são de tipos numéricos. É comum encontrarmos campos como cod_aluno, cod_carro, cod_fornecedor, como chave primária de tabelas. Isso pode ser justificado pela facilidade dos sistemas computacionais em processar dados numéricos. Entretanto, em uma tabela de fornecedores, campos que constantemente são utilizados como chave para buscas pelos usuários, como o CNPJ, não devem ser duplicados. A definição de um campo como um índice não-duplicável é uma boa opção para o projeto bancos de dados, pois evita a duplicidade e a inconsistência de informa-ções e, ao mesmo, tempo fornece um mecanismo eficiente para busca.

2.4 Outras estruturas para armazenamento primário

Segundo Elmasri e Navathe (2005), outras estruturas de dados podem ser usadas como organizações primárias de arquivo. Por exemplo, se tanto o tamanho do registro quanto o número de registros em um arquivo forem pequenos, alguns SGBDs fornecem a opção de utilizar a estrutura de dados árvore B como forma de organização primária do arquivo de dados.

Em geral, qualquer estrutura de dados que possa ser adaptada às caracterís-ticas dos dispositivos de disco poderá ser usada como organização de arquivo primária para a disposição de registros no disco. Por exemplo, Alves (2004) descreve a utilização de listas lineares, enquanto Silberchartz, Korth e Sudarshan (2006) descrevem a utilização de árvores binárias.

2.5 Tecnologia RAID

Um grande avanço da tecnologia de armazenamento secundário é repre-sentado pelo desenvolvimento do RAID, que significa Redundant Arrays of Inexpensive Disks, ou vetores redundantes de discos baratos. O principal obje-tivo do RAID é proporcionar melhoria de desempenho de modo a equiparar as taxas muito diferentes entre os discos e as memórias de microprocessadores (ELMASRI; NAVATHE, 2005).

Uma das razões que motivam o desenvolvimento desse padrão é que memórias e processadores ficaram muito mais rápidos, e os discos magnéticos para armaze-namento em massa não acompanharam essa evolução. A capacidade de armaze-namento dos discos tem aumentado bastante, porém a sua velocidade de acesso continua defasada em relação a outros dispositivos, de maneira que o acesso ao disco tem se tornado o vilão de muitas aplicações que exigem alto desempenho.

A solução proposta pela tecnologia RAID é utilizar um grande vetor de pequenos discos independentes, atuando como um único disco lógico de mais alto desempenho. Um conceito que utiliza paralelismo para aumentar o desempenho de um disco, o stripping, é utilizado e consiste em distribuir os dados de maneira transparente em diversos discos e fazê-los parecer um único disco grande e rápido. O stripping de dados melhora o desempenho total de entrada e saída, permite que diversas entradas e saídas possam ser feitas em paralelo, fornecendo, assim, altas taxas de transferência globais (ELMASRI; NAVATHE, 2005).

Portanto a utilização de uma técnica de armazenamento e a recuperação de informações adequada pode se tornar o diferencial de um determinado banco de dados em relação a outros. Aspectos como a quantidade de informações de um banco de dados, os dispositivos físicos de armazenamento disponíveis e os recursos de software disponibilizados pelo SGBD nos ajudam a escolher a técnica adequada para um determinado tipo de banco de dados.

Nesta aula, comentamos algumas das principais formas de armazenamento eletrônico de dados, por exemplo, os arquivos de registros desordenados e os arquivos de registros ordenados. Além disso, apresentamos algumas tecnologias de acesso aos registros de um banco de dados, como a utilização de arquivos de registros, indexação, hashing e a tecnologia RAID.

Tais conceitos são muito importantes para o projeto de bancos de dados, já que influenciam aspectos como a eficiência e desempenho.

1. Considerando que a utilização de arquivos de registros ordenados é uma técnica que tem seu potencial fundamentado na busca binária dos registros, ordenados de acordo com um dos campos dos registros, verificamos que há uma limitação nessa técnica quando pesquisas são feitas em relação a outros campos. Que outra técnica, que também utiliza pesquisa binária, permite que vários campos de um registro possam ser utilizados como base para pesquisa binária?

2. A técnica de hashing tem seu potencial fundamentado na rapidez para determinar o local de armazenamento de um registro. Entretanto dois regis-tros diferentes podem ser mapeados para um mesmo bloco de registros, o que chamamos de colisão. Uma das formas de tratamento de colisões é a utilização do encadeamento. Porém, dentro de um grupo de registros que foram mapeados para o mesmo bloco, implementa-se a busca seqüencial, o que faz com que se perca grande parte da performance. O que poderia ser feito para manter o alto desempenho?



A solução proposta pela tecnologia RAID é utilizar um grande vetor de pequenos discos independentes, atuando como um único disco lógico de mais alto desempenho. Um conceito que utiliza paralelismo para aumentar o desempenho de um disco, o stripping, é utilizado e consiste em distribuir os dados de maneira transparente em diversos discos e fazê-los parecer um único disco grande e rápido. O stripping de dados melhora o desempenho total de entrada e saída, permite que diversas entradas e saídas possam ser feitas em paralelo, fornecendo, assim, altas taxas de transferência globais (ELMASRI; NAVATHE, 2005).

Portanto a utilização de uma técnica de armazenamento e a recuperação de informações adequada pode se tornar o diferencial de um determinado banco de dados em relação a outros. Aspectos como a quantidade de informações de um banco de dados, os dispositivos físicos de armazenamento disponíveis e os recursos de software disponibilizados pelo SGBD nos ajudam a escolher a técnica adequada para um determinado tipo de banco de dados.

Nesta aula, comentamos algumas das principais formas de armazenamento eletrônico de dados, por exemplo, os arquivos de registros desordenados e os arquivos de registros ordenados. Além disso, apresentamos algumas tecnologias de acesso aos registros de um banco de dados, como a utilização de arquivos de registros, indexação, hashing e a tecnologia RAID.

Tais conceitos são muito importantes para o projeto de bancos de dados, já que influenciam aspectos como a eficiência e desempenho.

1. Considerando que a utilização de arquivos de registros ordenados é uma técnica que tem seu potencial fundamentado na busca binária dos registros, ordenados de acordo com um dos campos dos registros, verificamos que há uma limitação nessa técnica quando pesquisas são feitas em relação a outros campos. Que outra técnica, que também utiliza pesquisa binária, permite que vários campos de um registro possam ser utilizados como base para pesquisa binária?

2. A técnica de hashing tem seu potencial fundamentado na rapidez para determinar o local de armazenamento de um registro. Entretanto dois regis-tros diferentes podem ser mapeados para um mesmo bloco de registros, o que chamamos de colisão. Uma das formas de tratamento de colisões é a utilização do encadeamento. Porém, dentro de um grupo de registros que foram mapeados para o mesmo bloco, implementa-se a busca seqüencial, o que faz com que se perca grande parte da performance. O que poderia ser feito para manter o alto desempenho?



3. Em relação à utilização de índices em um banco de dados, assinale a alter-nativa correta.

a) Um campo de indexação deve, sempre, ser um campo não duplicável.

b) A utilização de índices é extremamente prejudicial ao banco de dados, pois representa o armazenamento de uma quantidade maior de informações.

c) A indexação é muito útil, sobretudo por não necessitar da ordenação dos registros armazenados em arquivo, mas apenas do índice.

d) A utilização de mais de um campo de indexação é inútil, pois de qual-quer maneira, o arquivo de registros não é ordenado.

4. Em relação à tecnologia de RAID e às tabelas de espalhamento, é correto afirmar que:

a) de acordo com a tecnologia RAID, um único disco de grande capaci-dade é fragmentado logicamente em diversas unidades.

b) a tecnologia RAID é uma alternativa para melhorar o desempenho dos sistemas de bancos de dados que utilizam os discos magnéticos, já que não acompanharam a evolução na rapidez de acesso em relação às memórias RAM.

c) as tabelas hash, também conhecidas como tabelas de espalhamento, somente têm utilidade em um sistema de banco de dados se contiverem uma função de espalhamento que seja considerada excelente.

d) a principal limitação da técnica de hashing é a incapacidade de tratar colisões.

Os objetivos desta aula são: compreender a maneira como os bancos de dados são armazenados em arquivos e compreender a forma de acesso aos arquivos que compõem um banco de dados. Será que eles foram atingidos? Vamos conferir!

Na atividade um você considerou que, embora a técnica de armazenamento em arquivos ordenados seja uma opção melhor em relação aos arquivos de regis-tros desordenados, ela tem problemas, como a inserção e a remoção de registros, além da busca binária ser refém de um único critério, que é justamente o campo que foi utilizado como base para a ordenação dos registros no momento de sua inserção no arquivo. Você apontou que uma alternativa seria utilizar a técnica de indexação. Com essa técnica, diversos índices podem ser criados para uma mesma entidade, não há a necessidade de ordenação dos arquivos, não há custo computacional adicional nas inserções e remoções e, ainda, permite a utilização da busca binária tendo outros campos como chave para pesquisa.

Na atividade dois, você considerou que o encadeamento faz com que cada bloco usado para receber os elementos seja o início de uma lista encadeada. Uma alternativa seria deixar essas listas ordenadas e efetuar a pesquisa binária. Essa é uma opção de projeto que tem certo custo de implantação, mas permite diminuir o problema causado pelas colisões.

Na atividade três, a resposta é a alternativa (c). A alternativa (a) está incor-reta, pois não há restrições para a criação de índices. A alternativa (b) é incorreta, pois, apesar de necessitar de uma quantidade maior de dados armazenados, a rapidez no acesso compensa todo o custo adicional de armazenamento. A alternativa (d) também está incorreta, pois a utilização de mais de um campo de indexação permite que se tenha mais uma opção para busca binária (mais eficiente) para uma determinada entidade em um sistema de banco de dados.

Na atividade quatro, a alternativa correta é (b). A alternativa (a) é incorreta pelo fato de que a tecnologia RAID prevê a utilização de vários discos físicos, agindo como um disco lógico, e não o contrário, como afirmado. A alternativa (c) está errada, já que uma função de espalhamento ótima sugere um bloco para cada registro, situação que pode ser inviável em um banco de dados com grande volume de informações. Finalmente, a alternativa (d) também está incorreta pelo fato de que existem meios de lidar com as colisões em uma tabela de espalhamento.




Estudaremos as transações, que são muito importantes para os sistemas de bancos de dados. Essa importância se dá, inclusive, pela possibilidade de tratar de maneira mais eficiente às operações efetuadas sobre um banco de dados. O estudo das transações inclui as suas principais propriedades, que são a atomici-dade, consistência, isolamento e durabilidade. Até lá!



Na atividade dois, você considerou que o encadeamento faz com que cada bloco usado para receber os elementos seja o início de uma lista encadeada. Uma alternativa seria deixar essas listas ordenadas e efetuar a pesquisa binária. Essa é uma opção de projeto que tem certo custo de implantação, mas permite diminuir o problema causado pelas colisões.

Na atividade três, a resposta é a alternativa (c). A alternativa (a) está incor-reta, pois não há restrições para a criação de índices. A alternativa (b) é incorreta, pois, apesar de necessitar de uma quantidade maior de dados armazenados, a rapidez no acesso compensa todo o custo adicional de armazenamento. A alternativa (d) também está incorreta, pois a utilização de mais de um campo de indexação permite que se tenha mais uma opção para busca binária (mais eficiente) para uma determinada entidade em um sistema de banco de dados.

Na atividade quatro, a alternativa correta é (b). A alternativa (a) é incorreta pelo fato de que a tecnologia RAID prevê a utilização de vários discos físicos, agindo como um disco lógico, e não o contrário, como afirmado. A alternativa (c) está errada, já que uma função de espalhamento ótima sugere um bloco para cada registro, situação que pode ser inviável em um banco de dados com grande volume de informações. Finalmente, a alternativa (d) também está incorreta pelo fato de que existem meios de lidar com as colisões em uma tabela de espalhamento.




Estudaremos as transações, que são muito importantes para os sistemas de bancos de dados. Essa importância se dá, inclusive, pela possibilidade de tratar de maneira mais eficiente às operações efetuadas sobre um banco de dados. O estudo das transações inclui as suas principais propriedades, que são a atomici-dade, consistência, isolamento e durabilidade. Até lá!

Anotações




entender o que é uma transação e quais as suas vantagens;•

entender as propriedades de uma transação e seus estados.•

Para o entendimento desta aula, é importante que você conheça os conceitos de monoprocessamento, multiprocessamento e processamento paralelo para uma melhor compreensão do tratamento às transações em um SGBD que garanta a integridade e a consistência dos dados quanto das operações realizadas pelos sistemas dos usuários em um banco de dados. Também é fundamental o conhe-cimento básico sobre o que é um banco de dados e um Sistema Gerenciador de Banco de Dados – SGBD –, bem como ainda dos comandos básicos da linguagem SQL utilizada por diversos SGBDs. Todos esses conteúdos foram vistos nas aulas da disciplina de Bancos de Dados, no segundo período.

Grande parte dos vários processos existentes no mundo real, tais como trans-ferências de valores em instituições bancárias, compras em comércio eletrônico e outros serviços, utiliza transações que são um atributo ou um artifício comum em bancos de dados comerciais.

Vamos estudar, nesta aula, a importância das transações dentro de um SGBD, bem como suas propriedades e seus estados.

3.1 Definindo transações

Date (2004, p. 63) afirma que transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos de dados. Podemos dizer, ainda, que




entender o que é uma transação e quais as suas vantagens;•

entender as propriedades de uma transação e seus estados.•

Para o entendimento desta aula, é importante que você conheça os conceitos de monoprocessamento, multiprocessamento e processamento paralelo para uma melhor compreensão do tratamento às transações em um SGBD que garanta a integridade e a consistência dos dados quanto das operações realizadas pelos sistemas dos usuários em um banco de dados. Também é fundamental o conhe-cimento básico sobre o que é um banco de dados e um Sistema Gerenciador de Banco de Dados – SGBD –, bem como ainda dos comandos básicos da linguagem SQL utilizada por diversos SGBDs. Todos esses conteúdos foram vistos nas aulas da disciplina de Bancos de Dados, no segundo período.

Grande parte dos vários processos existentes no mundo real, tais como trans-ferências de valores em instituições bancárias, compras em comércio eletrônico e outros serviços, utiliza transações que são um atributo ou um artifício comum em bancos de dados comerciais.

Vamos estudar, nesta aula, a importância das transações dentro de um SGBD, bem como suas propriedades e seus estados.

3.1 Definindo transações

Date (2004, p. 63) afirma que transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos de dados. Podemos dizer, ainda, que

Transações

Aula 3



uma transação é “todo e qualquer comando que altera o estado do banco de

dados”, ou seja, transação é a unidade lógica de processamento de um SGBD,

constituída de um conjunto de operações (INSERT, UPDATE, DELETE, etc.), cujo

objetivo é transformar um BD de um estado consistente para outro estado consis-

tente, mesmo que nos passos intermediários (operações) o sistema permaneça

temporariamente inconsistente. A Figura 1 ilustra essa situação.

Figura 1 Exemplo de transação.

O usuário deve ser capaz de informar ao sistema quando diferentes operações

fazem parte de uma transação. Basicamente, a transação começa quando uma

operação BEGIN é executada e termina quando uma operação chamada COMMIT

ou ROLLBACK correspondente é executada. Dessa forma, podemos perceber que

uma transação é formada caracteristicamente por esses comandos (ELMASRI;

NAVATHE, 2005). A Figura 2 contém uma representação de uma transação.

Figura 2 Estrutura sql de uma transação.

...BEGIN OPERACAO 1; OPERACAO 2; ... OPERACAO N;COMMIT;...ROLLBACK;

Pensando sobre o assunto



Segundo Date (2004), podemos consistir o conceito de transação com um exemplo clássico que é utilizado quando precisamos iniciar esse assunto em sala de aula, que é uma explicação análoga a uma transferência bancária. Em meio a um processo de transferência de valor entre contas, temos alguns comandos SQL que são executados todos de uma vez, formando a tal unidade lógica que, por sua vez, envolve diversas operações de bancos de dados, tais como INSERT e UPDATE. Transações também podem conter DELETE e SELECT, mas no caso da transferência, utilizaremos somente o UPDATE.

Digamos que nossa agência tenha dois correntistas, A e B e, em um belo dia, A resolve fazer uma transferência de R$ 50,00 para B. Essa transação será feita pela Internet, por meio de um sistema de internet banking, então, A aces-sará a sua conta e completará a operação. Do lado servidor, o banco de dados recebe o valor e a conta de destino, tal valor é subtraído da conta de origem e adicionado na conta de destino. Nesse momento, há uma conferência por parte do SGBD – tudo correu bem –, então a transação é finalizada com sucesso (ELMASRI; NAVATHE, 2005).

3.2 Importância das transações

Segundo Ramakrishnan e Gehrke (2003), se tomarmos como base o conceito de que transações são unidades lógicas de trabalho em uma aplicação, e que a base de dados está em um estado consistente antes e depois de uma transação, podemos afirmar que as transações desempenham um papel importante em um SGBD uma vez que:

funcionam como um mecanismo que garante que toda transação iniciada •termina com sucesso ou é desfeita;

transações de diferentes usuários que envolvem dados compartilhados •são executadas em seqüência;

transações controlam melhor a concorrência de operações e a recons-•trução dos dados em caso de falha.

3.3 Propriedades ACID

Você compreendeu que uma transação é uma seqüência de operações execu-tadas como uma única unidade lógica de trabalho. Uma unidade lógica de trabalho deve mostrar quatro propriedades, designadas pelas iniciais ACID (atomicidade, consistência, isolamento e durabilidade), para que seja qualificada como uma tran-sação. Vejamos agora, segundo Date (2004), o que significa cada uma delas.

3.3.1 Atomicidade

Uma transação deve ser uma unidade atômica de trabalho: ou todas as suas modificações de dados são executadas ou nenhuma delas é executada,



ou seja, você utiliza transação quando determinada ação envolve atualização de mais de uma tabela do banco. E para garantir que todas as atualizações sejam realizadas, utiliza transação. Se uma ação pode ser separada em ações menores, então temos duas (ou mais) transações, ou seja, se uma ou mais ações podem falhar sem deixar o banco de dados em estado inconsistente, essas ações não devem ser parte da mesma transação.

3.3.2 Consistência

A execução de uma transação deve levar ao banco de dados de um estado consistente a outro também consistente, ou seja, quando concluída, uma transação deve deixar todos os dados em um estado consistente. Uma transação é consis-tente se não violar a integridade do banco de dados. Se a transação tiver êxito ou falhar, ela deve deixar o banco de dados em um estado consistente. Se uma transação falhar, ela precisa desfazer todas as alterações temporárias e deixar o banco de dados no estado em que ele estava antes que a transação iniciou.

3.3.3 Isolamento

Uma transação não deve tornar suas atualizações visíveis a outras transa-ções antes do seu fim, ou seja, modificações feitas por transações simultâneas devem ser isoladas das modificações feitas por qualquer outra transação simul-tânea. Uma transação que debita uma conta e credita outra deve ser totalmente transparente. Quando isso é feito, a transação precisa atualizar o banco de dados de uma só vez. Por exemplo, se um usuário solicitar o saldo de uma conta e ela está sofrendo uma transação, o banco de dados só deve retornar o valor do saldo depois que completar a atualização. Dessa forma, durante a transação algumas linhas são bloqueadas.

3.3.4 Durabilidade

Depois que uma transação tiver sido concluída, seus efeitos ficam perma-nentemente no sistema, ou seja, após o término de uma transação, suas atuali-zações não podem ser perdidas por causa de falhas futuras. As modificações persistem até mesmo no caso de uma queda do sistema. Se todas as ações forem realizadas com sucesso, não significa que houve sucesso na transação, pois ela precisa gravar os dados de volta ao disco. Caso ocorra uma falha no disco, a transação não é válida. Então antes que uma transação seja completada deve verificar se as alterações foram gravadas com sucesso antes de terminar.

3.4 Estados de uma transação

Segundo Ramakrishnan e Gehrke (2003), uma transação é sempre monito-rada pelo SGBD quanto ao seu estado. Que operações já fez? Concluiu suas operações? Deve abortar? São algumas perguntas que o SGBD realiza para gerenciar os estados de uma transação.



Os estados de uma transação podem ser: ativa, em processo de efetivação, efetivada, em processo de aborto e concluída.

Uma transação pode se encontrar em diferentes estados. O grafo apresen-tado na Figura 3 ilustra as possibilidades de transição de estados.

Figura 3 Transição de estados de uma transação.

Alves (2004) descreve os estados de uma transação da seguinte maneira:

ativa• : é o estado inicial de toda transação selecionada para execução. Ela permanece nesse estado enquanto estiver em execução;

em processo de efetivação• : entra nesse estado após executar sua última operação (solicitação de COMMIT). Neste momento, o SGBD precisa garantir que as suas atualizações sejam efetivadas com sucesso (não sofram falhas);

em processo de aborto• : entra nesse estado se não puder prosseguir sua execução. Pode ainda passar para esse estado enquanto ativa ou em processo de efetivação. Suas ações já realizadas devem ser desfeitas (ROLLBACK);

efetivada• : entra nesse estado após o SGBD confirmar que todas as modi-ficações da transação estão garantidas no banco de dados (COMMIT OK), como, por exemplo, a gravação em Log, descarga de todos os buffers em disco, entre outros;

concluída• : estado final de uma transação, ele indica uma transação que deixa o sistema. As informações das transações mantidas em catálogo podem ser excluídas (operações feitas, dados manipulados, buffers utilizados, entre outros). Caso a transação não tenha sido concluída com sucesso, ela pode ser reiniciada automaticamente.



Portanto, diante da apresentação das propriedades ACID e dos estados de uma transição, podemos perceber como a utilização do mecanismo de transa-ções pode auxiliar na construção de bancos de dados consistente e confiável.

Nesta aula, você aprendeu que uma transação é a unidade lógica de processamento de um SGBD, constituída de um conjunto de operações. O objetivo dela é transformar um BD de um estado consistente para outro estado consistente, mesmo que nos passos intermediários o sistema permaneça tempo-rariamente inconsistente.

Você entendeu também a importância das transações em um SGBD, pois elas garantem que toda transação (operações) iniciada termine com sucesso ou seja desfeita. As transações também controlam melhor a concorrência de operações e a reconstrução dos dados em caso de falha. Transações de diferentes usuários que envolvem dados compartilhados são executadas em seqüência.

Compreendeu também que, para ser qualificada como uma transação, ela deve mostrar quatro propriedades, designadas pelas iniciais ACID, que são as propriedades de atomicidade, consistência, isolamento e durabilidade.

Você pôde compreender que uma transação é sempre monitorada pelo SGBD quanto ao seu estado, respeitando sempre um grafo de transição de estados. Finalmente, viu que os estados de uma transação podem ser: ativa, em processo de efetivação, efetivada, em processo de aborto e concluída.

1. A partir do exposto na aula, como você define transação?

2. Leia e analise atentamente as seguintes afirmativas sobre as propriedades de uma transação.

I. O princípio de atomicidade é o princípio de tudo ou nada, ou seja, ou todas as operações são efetivadas com sucesso em um banco de dados ou nenhuma delas se efetiva. Isso é realizado para preservar a integri-dade do banco de dados.

II. A propriedade de isolamento define que cada transação deve ser isolada dos efeitos da execução concorrente de outras transações.

III. A propriedade que define que toda transação que for finalizada de forma bem-sucedida deve persistir seus resultados em banco mesmo na presença de falhas no sistema é a propriedade de consistência.

Assinale a alternativa correta.

a) Somente a afirmativa I está incorreta.

b) Somente as afirmativas I e II estão corretas.

c) Somente as afirmativas II e III estão incorretas.

d) Todas as afirmativas estão corretas.

3. Para você, qual é a importância das transações em um SGBD?

4. Leia atentamente as afirmativas a seguir sobre os estados de uma transação.

I. Ativo é o estado inicial da transação. Ela permanece nesse estado enquanto estiver em execução.

II. Concluída é o estado em que o SGBD confirma que todas as modifica-ções da transação estão garantidas no banco de dados.

III. Efetivada é o estado final de uma transação, ele indica uma transação que deixa o sistema. Caso a transação não tenha sido concluída com sucesso, ela pode ser reiniciada automaticamente.

IV. O estado processo de aborto é o estado em que a transação não pode prosseguir sua execução.


a) As afirmativas II e III estão incorretas.

b) As afirmativas I e III estão incorretas.

c) Somente a afirmativa IV está correta.

d) As afirmativas I e IV estão incorretas.

Na atividade um, você afirmou que uma transação é a unidade lógica de trabalho, constituída de um conjunto de operações. Seu objetivo é transformar um BD de um estado consistente para outro estado consistente, mesmo que nos passos intermediários o sistema permaneça temporariamente inconsistente. Se você conseguiu expor dessa maneira, parabéns! Você atingiu o objetivo de entender o que é uma transação e quais as suas vantagens. Caso não tenha conseguido, sugiro que volte ao início desta aula e revise cuidadosamente o conteúdo sobre transações.

Na atividade dois, a resposta correta é a alternativa (b). Se sua resposta foi essa, parabéns, você atingiu nosso objetivo de entender as propriedades de uma transação e seus estados. A afirmativa (III) está incorreta, pois a propriedade de




a) Somente a afirmativa I está incorreta.

b) Somente as afirmativas I e II estão corretas.

c) Somente as afirmativas II e III estão incorretas.

d) Todas as afirmativas estão corretas.

3. Para você, qual é a importância das transações em um SGBD?

4. Leia atentamente as afirmativas a seguir sobre os estados de uma transação.

I. Ativo é o estado inicial da transação. Ela permanece nesse estado enquanto estiver em execução.

II. Concluída é o estado em que o SGBD confirma que todas as modifica-ções da transação estão garantidas no banco de dados.

III. Efetivada é o estado final de uma transação, ele indica uma transação que deixa o sistema. Caso a transação não tenha sido concluída com sucesso, ela pode ser reiniciada automaticamente.

IV. O estado processo de aborto é o estado em que a transação não pode prosseguir sua execução.


a) As afirmativas II e III estão incorretas.

b) As afirmativas I e III estão incorretas.

c) Somente a afirmativa IV está correta.

d) As afirmativas I e IV estão incorretas.

Na atividade um, você afirmou que uma transação é a unidade lógica de trabalho, constituída de um conjunto de operações. Seu objetivo é transformar um BD de um estado consistente para outro estado consistente, mesmo que nos passos intermediários o sistema permaneça temporariamente inconsistente. Se você conseguiu expor dessa maneira, parabéns! Você atingiu o objetivo de entender o que é uma transação e quais as suas vantagens. Caso não tenha conseguido, sugiro que volte ao início desta aula e revise cuidadosamente o conteúdo sobre transações.

Na atividade dois, a resposta correta é a alternativa (b). Se sua resposta foi essa, parabéns, você atingiu nosso objetivo de entender as propriedades de uma transação e seus estados. A afirmativa (III) está incorreta, pois a propriedade de



consistência define que cada transação executada isoladamente deve preservar a consistência do banco de dados, e a propriedade de durabilidade define que toda transação que for finalizada de forma bem-sucedida deve persistir seus resultados em banco mesmo na presença de falhas no sistema. Caso você tenha optado por outra alternativa, sugiro que reveja o conteúdo sobre as proprie-dades das transações.

Na atividade três, você expôs que as transações desempenham um papel importante em um SGBD porque garantem que toda transação (operações) iniciada termine com sucesso ou então seja desfeita. Se sua resposta trouxe essas observações sobre a importância das transações, parabéns! Você atingiu nosso objetivo de entender o que é uma transação e quais as suas vantagens. Caso não tenha conseguido responder dessa forma, sugiro que você volte ao conteúdo desta aula e reveja atentamente a definição e importância das transa-ções em um SGBD.

Na atividade quatro, a resposta correta é a alternativa (a). Se você optou por essa resposta, parabéns! Você atingiu nosso objetivo de entender as proprie-dades de uma transação e seus estados. As afirmativas (II) e (III) estão incorretas, pois o estado efetivado é o estado em que o SGBD confirma que todas as modi-ficações da transação estão garantidas no banco de dados, e concluída é o estado final de uma transação, ele indica uma transação que deixa o sistema. Caso a transação não tenha sido concluída com sucesso, ela pode ser reiniciada automaticamente. Caso sua resposta tenha sido diferente, sugiro que você volte ao conteúdo sobre os estados de uma transação e observe detalhadamente as características de cada estado.

ALVES, W. P. Fundamentos de bancos de dados. São Paulo: Érica, 2004.

DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. São Paulo: Campus, 2004.


RAMAKRISHNAN, R; GEHRKE, J. Database management systems. 3. ed. São Paulo: McGrow-Hill, 2003.

Estudaremos sobre os mecanismos de controle de concorrência. Esses meca-nismos são muito importantes, sobretudo em ambientes nos quais mais de uma transação pode ser efetuada no mesmo instante em um banco de dados. Até lá!


compreender o porquê da utilização da concorrência nas transações;•

identificar os principais problemas e técnicas para o controle de •concorrência.

Para uma melhor compreensão desta aula, é importante que os conceitos rela-cionados a transações sobre um banco de dados tenham sido assimilados, bem como os comandos da linguagem procedural SQL, necessários para a execução de uma transação. Esses conteúdos foram apresentados na aula três deste caderno. Entendendo os conceitos relativos às transações, podemos compreender também os mecanismos de controle de concorrência, que é o assunto da aula.

Agora trataremos de um tema muito importante para os SGBDs em geral: a concorrência. Essa importância se dá visto que um SGBD geralmente permite que sejam realizadas diversas transações ao mesmo tempo. Assim é necessário que sejam adotados alguns mecanismos para garantir que transações concorrentes não interfiram uma nas outras. Assim serão consideradas, nesta aula, os prin-cipais problemas de concorrência, além das principais técnicas utilizadas para solucionar os problemas considerados.

4.1 Concorrência

O conceito de controle de concorrência é de extrema importância para os SGBDs, visto que algumas propriedades devem ser respeitadas e, entre elas, deve se considerar o isolamento de transações que serão executadas concorren-temente. A maioria das técnicas utilizadas para esse controle tenta assegurar a




compreender o porquê da utilização da concorrência nas transações;•

identificar os principais problemas e técnicas para o controle de •concorrência.

Para uma melhor compreensão desta aula, é importante que os conceitos rela-cionados a transações sobre um banco de dados tenham sido assimilados, bem como os comandos da linguagem procedural SQL, necessários para a execução de uma transação. Esses conteúdos foram apresentados na aula três deste caderno. Entendendo os conceitos relativos às transações, podemos compreender também os mecanismos de controle de concorrência, que é o assunto da aula.

Agora trataremos de um tema muito importante para os SGBDs em geral: a concorrência. Essa importância se dá visto que um SGBD geralmente permite que sejam realizadas diversas transações ao mesmo tempo. Assim é necessário que sejam adotados alguns mecanismos para garantir que transações concorrentes não interfiram uma nas outras. Assim serão consideradas, nesta aula, os prin-cipais problemas de concorrência, além das principais técnicas utilizadas para solucionar os problemas considerados.

4.1 Concorrência

O conceito de controle de concorrência é de extrema importância para os SGBDs, visto que algumas propriedades devem ser respeitadas e, entre elas, deve se considerar o isolamento de transações que serão executadas concorren-temente. A maioria das técnicas utilizadas para esse controle tenta assegurar a

Controle de concorrência

Aula 4



serialização da execução das transações. Para isto, utiliza um conjunto de regras, também chamadas de protocolos. Para melhor entendimento desses protocolos, temos de compreender, primeiro, os problemas que podem ocorrer em um banco de dados e, obviamente, sobre as transações sobre ele executadas.

4.2 Problemas de concorrência

Existem três problemas cruciais que os mecanismos de controle de concor-rência de um SGBD devem tratar:

atualização perdida (• lost update)dependência sem • commitanálise inconsistente•

Esses três problemas podem ocorrer mesmo que a transação esteja correta respeitando as propriedades de uma transação. A seguir, vamos entender o que ocorre em cada um dos problemas citados.

4.2.1 Atualização perdida (lost update)

A melhor maneira de entendermos os problemas citados anteriormente é aplicando exemplos. Então vamos ao primeiro exemplo, que apresentará a atua-lização perdida. A Tabela 1 apresenta duas transações A e B, que, em momentos distintos, acessam uma tupla de dados ou como também pode ser expresso um item de dados.

Tabela 1 Problema de atualização perdida.

TRANSAçãO A TEMPO TRANSAçãO B– | –

ler (t) T1 –– T2 ler(t)

alterar(t) T3 –– T4 alterar(t)– ↓ –

Fonte: Date (2003, p. 400).

Observando a Tabela 1, podemos notar que a transação A acessou uma tupla t e leu o seu valor em um tempo T1; a transação B acessou a mesma tupla e também realizou a leitura de seu valor em um tempo T2; a transação A realizou uma alteração no valor da tupla t em um tempo T3; e finalizando, a transação B atualizou o valor da mesma t no tempo T4. Porém essa atualização na tupla é realizada com base em seu acesso ao valor de t no tempo T2, perdendo, assim, a atualização realizada pela transação A no tempo T3. Resumidamente, o problema da atualização perdida consiste no fato que uma transação B em algum momento sobrescreve uma atualização realizada por uma transação A, com valores muitas vezes incorretos devido a um processo de concorrência inadequado.



4.2.2 Dependência sem commit

Assim como realizado na seção anterior, vamos a um exemplo para uma melhor compreensão sobre o problema da dependência sem commit. Observe a Tabela 2, na qual é apresentada a seqüencia de transações e suas operações para descrever o problema.

Tabela 2 Problema da dependência sem commit com leitura de valores.

TRANSAçãO A TEMPO TRANSAçãO B– | –– T1 alterar(t)

ler(t) T2 –– T3 rollback– T4 –– ↓ –

Fonte: Date (2003, p. 400).

Como pode ser observado na Tabela 2, o problema da dependência sem commit reside na inconsistência dos dados devido a uma transação não ser completada com sucesso. Note na tabela, que em um tempo T1, a transação B altera os valores do item de dados t; em seguida, a transação A, no tempo T2, lê os valores de t; porém a transação B realiza um comando de rollback, ou seja, a alteração não é completada. Assim o valor lido pela transação A, no tempo T2, é incoerente, passando valores inconsistentes devido à incompletude na tran-sação B que ainda não havia sido finalizada.

Outra vertente desse problema e que é considerada mais séria, consiste em transações que, ao invés de somente realiza a leitura, realiza operações de escrita, sem que outra transação iniciada anteriormente tenha sido completada, como é demonstrado na Tabela 3.

Tabela 3 Problema da dependência sem commit com alteração de valores.

TRANSAçãO A TEMPO TRANSAçãO B– | –– T1 alterar(t)

alterar(t) T2 –– T3 rollback– T4 –– ↓ –

Fonte: Date (2003, p. 400).

Note que o problema é o mesmo apresentado na Tabela 2. Porém, ao invés de um acesso de leitura sobre a tupla t, é realizada uma operação de escrita, o que pode tornar tudo mais complexo, já que esses dados passam a estar incoe-rentes e persistentes no banco de dados.



4.2.3 Análise inconsistente

O último problema a ser apresentado dos citados no início desta aula é a análise inconsistente. Ele, sob um ponto de vista mais superficial, é semelhante ao problema apresentado na seção anterior, já que resulta na leitura inconsis-tente de valores por uma transação. A diferença é que a leitura ocorre sem que tenham ocorrido problemas com a transação concorrente, ou seja, as operações da transação são finalizadas usando o comando commit. Para exemplificar esse problema, imaginemos um banco que tem três contas correntes, contendo respec-tivamente os valores 40, 50 e 30, sobre as quais duas transações acontecem simultaneamente. A transação A realizará a soma dos valores das contas e a transação B realizará operações de atualização no banco de maneira concor-rente. A Tabela 4 demonstra a seqüência de eventos.

Tabela 4 Problema da análise inconsistente.


ler conta1(40)soma = 40

T1 –

ler conta2 (50)soma = 90

T2 –

– T3altera conta3 30 → 20altera conta1 40 → 50

commit

ler conta3 (20)soma = 110

T4 –

– ↓ –Fonte: Date (2003, p. 401).

É importante observar que o resultado final da soma realizada na tran-sação A é 110, enquanto o resultado correto seria 120. Esse problema se deve ao fato de que, enquanto a transação A, nos tempos T1 e T2, lê e soma os valores das contas conta1 e conta2, em um tempo T3, a transação B realiza uma atualização nos valores das contas conta3 e conta1, sendo finalizada com sucesso por meio do comando commit. Porém, no tempo T4, a transação A realiza a soma do valor contido na conta3, que foi alterado no tempo T3 pela transação B, causando o problema de inconsistência no valor final da soma.

Assim podemos dizer que o problema de análise inconsistente geralmente acontece devido a diversos acessos de leitura a linhas de maneira que, a cada acesso, é lido um novo valor gerado devido à concorrência com outras transa-ções, causando a inconsistência no valor final.



Saiba mais

4.3 Técnicas de controle de concorrência

Para sanar os problemas mencionados anteriormente, são utilizadas técnicas, também denominadas protocolos, para tratar do controle de concorrência. Nesta disciplina, serão consideradas apenas escalas ditas serializáveis, que podem ser classificadas em técnicas pessimistas e otimistas. Elmasri e Navathe (2005) citam a seguinte classificação:

a) pessimista

bloqueio• • timestamp (marcas de tempo)

b) otimista

validação•

As técnicas pessimistas presumem que sempre ocorrerá interferência entre as transações e, então, buscam sempre garantir a serialização enquanto uma transação estiver ocorrendo. Já as técnicas otimistas supõem que raramente ocorrerá a interfe-rência entre as transações e somente verificam o aspecto da serialização ao final.

Vamos à análise dos protocolos de controle de concorrência.

4.3.1 Bloqueio

Um protocolo consiste em uma padronização de procedimentos utilizados para a execução de uma tarefa. Logo o que ocorre em todos os protocolos nada mais é que uma definição de regras a serem seguidas. O bloqueio é certamente o mais utilizado entre os protocolos de controle de concorrência pelos bancos de dados disponíveis no mercado (ELMASRI; NAVATHE, 2005).

Diversos modos de bloqueio podem ser utilizados para trabalhar com transa-ções concorrentes, porém iremos assumir apenas os dois modos mais difundidos e que são mencionados por Silberschatz, Korth e Sudarshan (2006). Vejamos quais são esses dois modos.

a) Compartilhado: se uma transação obtiver um bloqueio compartilhado (indicado por S, do inglês Share) sobre um dado, então poderá ler, mas não escrever sobre o item bloqueado.



b) Exclusivo: se uma transação obtiver um bloqueio do tipo exclusivo (indi-cado por X, do inglês exclusive) sobre um dado, então ela poderá ler e escrever sobre o item de dados bloqueado.

Cada transação deve, no momento de execução, solicitar o bloqueio obser-vando o modo mais apropriado sobre os dados a serem utilizados. O que ocorre é que a transação lança uma solicitação ao gerenciador de controle de concor-rência, que só autoriza o seu prosseguimento, após conceder (grants) o bloqueio sobre os dados a serem manipulados.

Entender a compatibilidade de bloqueios é de extrema importância, pois, por meio dela são baseadas as atividades permitidas ou não em um controle de concor-rência. Observe a Tabela 5, na qual é apresentada a matriz de compatibilidade.

Tabela 5 Matriz de compatibilidade de bloqueio.

TRANSAçõES Lock S Lock XLock S Verdadeiro FalsoLock X Falso Falso

Vamos entender melhor a matriz de compatibilidade apresentada. Nos eixos dos comandos de bloqueio lock, estão dispostos valores que determinam se duas transações ocorrem no modo compartilhado ou exclusivo. Note que apenas no caso em que duas ou mais transações estiverem bloqueando um mesmo item de dados Q no modo compartilhado (lock S), elas poderão ser executadas ao mesmo tempo. O modo compartilhado permite apenas ler dados, logo a leitura de ambas as transações ao mesmo tempo não afetará em momento algum nos dados que ambas estão acessando.

Nas demais situações expostas pela matriz de compatibilidade, sempre que uma transação solicitar o bloqueio, uma deve aguardar a outra ser concluída para ter acesso aos dados. A liberação de recursos ocorre com a utilização do comando unlock. Vamos a um exemplo para entender a técnica de bloqueio em transações. Relembrando o exemplo apresentado anteriormente sobre contas correntes, duas transações fazem acesso às contas, consultam e alteram valores, bloqueiam os dados quando necessário. Essas transações são apresentadas na Tabela 6.

Tabela 6 Controle de concorrência com bloqueios.

TRANSAçãO A TEMPO TRANSAçãO BGERENCIAMENTO DE CONTROLE DE CONCORRêNCIA

– | – –lock X (conta1) T1 – –

– T2 –grant

X(conta1,Transação A)lock X (conta2) T3



TRANSAçãO A TEMPO TRANSAçãO BGERENCIAMENTO DE CONTROLE DE CONCORRêNCIA

– T4 –grant

X(conta2,Transação A)altera conta1 40

→ 30altera conta2 50

→ 60commit

aux1 = ler(conta1)unlock(conta1)unlock(conta2)

T5 – –

– T6 lock S (conta2) –

– T7 –grant

S(conta2,Transação B)–

lock S (conta2)T8 aux3 = ler(conta2) –

– T9 –grant

S(conta2,Transação A)aux2 = ler(conta2)

unlock(conta2)mostrar(aux1 +

aux2)

T10unlock(conta2)

–

– ↓ – –

Ok, pessoal, vamos à explicação. Nesse exemplo, é realizada a apresen-tação da soma dos valores da conta1 e conta2, além de realizar a transfe-rência da conta1 para a conta2. Do tempo T1 ao T4, a transação A solicita o bloqueio exclusivo da conta1 e conta2 que aguarda a liberação do gerenciador do controle de concorrência que acontece nos tempos T2 e T4, é uma permissão com exclusividade. No tempo T5, a transação A efetua uma alteração no valor da conta1 e na conta2, realiza a persistência dos valores por meio da instrução commit e emite um aviso ao gerenciador de concorrência que libera a conta1 e conta2 para outras transações, por meio da instrução unlock. Note que, do tempo T6 a T10, as duas transações, A e B, realizam acesso compartilhado aos dados autorizados pelo gerenciador de controle de concorrência por meio dos grants, imprimindo a soma dos valores das contas. É importante lembrar que são realizadas apenas atividades de leitura aos valores nas contas no referido intervalo de tempo (T6 a T 10).

Com isso, podem ser controlados os acessos e, assim, garantir o isolamento das transações. Porém, com o bloqueio, surge um novo problema, denominado impasse ou deadlock. Na Tabela 7, a transação A solicita o bloqueio da conta2,



realiza a leitura e a atualização dos valores no tempo T1, porém não realiza a liberação do recurso conta2. No tempo T2, a transação B solicita o bloqueio compartilhado da conta1, lê os valores e, então, solicita o bloqueio da conta2, criando, assim, um impasse com a transação A, já que está não liberou os dados da conta2. Para tornar o processo mais problemático, a transação A ainda soli-cita o bloqueio da conta1 de maneira exclusiva e, como pode ser observado, ainda está bloqueada para a transação B.

Tabela 7 Impasse ou deadlock entre transações.


lock X(conta2)ler conta2 (50)

altera conta2 60 -> 50commit

T1 –

– T2lock S(conta1)

ler conta1lock S(conta2)

lock X(conta1) T3 –– ↓ –

Quando o banco se depara com uma situação de deadlock, o sistema deve se encarregar de reverter uma das transações para que a outra prossiga. Logo, quando uma transação é revertida, os itens de dados bloqueados para essa tran-sação são desbloqueados. Silberschatz, Korth e Sudarshan (2006) mencionam que o deadlock é um mal necessário, evitando estados inconsistentes.

Saiba mais

4.3.2 Timestamp

Timestamp é um método que determina a ordem de serialização das transações ordenando-as antes de sua execução. O método mais comum para isso consiste na ordenação por timestamp (marcas de tempo) representado como TS. Nesse modelo de ordenação, é atribuído um valor de timestamp pelo banco de dados antes que a transação se inicie. Uma transação posterior sempre terá um times-tamp maior que o da transação anterior. Segundo Silberschatz, Korth e Sudarshan (2006), dois modos são utilizados para implementar esse esquema. Vejamos.

Utilização do valor do • clock (hora do sistema) como timestamp de uma transação.



Utilização de um contador lógico para definir o• timestamp de uma transação.

É por meio desses timestamp definidos para as transações que é assegurada a ordem de serialização das transações. Logo, se TS(A) < TS(B), o sistema deve garantir que o esquema de execução montado privilegie a transação A em detri-mento de B. Conforme Elmasri e Navathe (2005), para garantir essa ordem, são associados a cada item de dados dois valores de timestamp:

Write• _TS(Q): que indica o maior timestamp de qualquer transação que executou uma escrita com sucesso;

Read• _TS(Q): que indica o maior timestamp de qualquer transação que executou uma leitura com sucesso.

Esses valores são atualizados a cada execução de instruções de leitura ou escrita em uma transação. Assim o protocolo de ordenação de timestamp deve garantir que operações conflitantes sejam executadas segundo a ordem de cada valor de timestamp definido para cada operação sobre o item de dados Q de uma transação. Esse protocolo, conforme Elmasri e Navathe (2005), trabalha da seguinte forma:

a) suponha que a transação A realize uma leitura(Q):

Se TS(A) < Read_TS(Q), então•

existe outra operação sobre Q com • timestamp maior e a tran-sação A é revertida.

Senão•

a operação de leitura é executada e Read_TS(Q) é definido •como o novo maior timestamp de leitura.

b) suponha que a transação A realize uma escrita(Q):

Se TS(A) < Read_TS(Q) ou TS(A) < Write_TS(Q) então,•

existe outra operação de leitura ou escrita com • timestamp maior e a transação é revertida

Senão•

o sistema executa a operação de escrita e define Write_TS(Q) •como o novo maior timestamp para escrita.

Quando uma transação é revertida pelo controle de concorrência, um novo valor de timestamp é definido. Um importante detalhe a ser considerado sobre a técnica de timestamp é que por não utiliza bloqueio, não ocorrem deadlocks. Porém esse protocolo abre espaço para o problema de estagnação de transa-ções longas, se uma seqüência de outras transações curtas em conflito causarem o reinício da transação longa.



4.3.3 Validação

A validação consiste no último protocolo de controle de concorrência a ser analisado nesta aula. Essa técnica consiste em um esquema de monitoramento, ou seja, uma visão otimista, pois nenhuma verificação é realizada durante a execução das transações. Com isso, tem-se um ganho considerável sobre o overhead criado por um controle de concorrência pessimista. Nessa técnica, as operações de uma transação são realizadas por cópias locais dos itens de dados. Para tanto, uma transação tem duas ou três fases dependendo se elas realizam a leitura ou escrita respectivamente. Silberschatz, Korth e Sudarshan (2006) apresentam essas fases. Vejamos.

Fase de leitura• : a transação A lê os dados e os atualiza em cópias locais.

Fase de validação• : nessa fase, ocorre a análise da serialização dos conflitos caso as alterações nas cópias sejam efetivadas.

Fase de escrita• : se a fase de validação ocorrer sem problemas, aplicam-se as atualizações no banco, caso contrário a transação é revertida.

Para a realização dos testes de validação, devem ser definidos três times-tamps diferentes para cada operação de uma transação. Conforme Silberschatz, Korth e Sudarshan (2006), são eles:

start• (transação): momento em que a transação foi iniciada;

validation• (transação): momento em que a transação terminou a fase de leitura e iniciou a fase de validação;

finish• (transação): momento em que se termina a fase de escrita.

O teste de validação para uma transação A e B exige que TS(A) seja menor que TS(B). Segundo Elmasri e Navathe (2005), uma das condições a seguir necessita ser mantida.

Finish• (A) < Start(B): a transação A termina a execução de suas opera-ções antes da transação B;

O conjunto de dados escritos por A não tem interseção com os dados •lidos por B, e A completa sua fase de escrita antes que B inicie sua fase de validação.

O esquema de validação protege contra rollbacks em cascata, pois o processo de escrita real somente ocorre depois que a transação tenha sido vali-dada (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).

A partir do que vimos nesta aula, podemos concluir que a aplicação de meca-nismos de controle de concorrência é muito importante quando existe a possibili-dade de acessos simultâneos a um banco de dados. Essa situação é muito comum nas organizações de maneira geral, e a tendência é que os bancos de dados com

acessos concorrentes sejam cada vez mais presentes, sobretudo pelo crescimento dos sistemas de informação cuja plataforma é o ambiente da Internet.

Nesta aula, apresentamos os conceitos básicos relacionados ao controle de concorrência, que é um mecanismo utilizado para garantir as propriedades das transações e a consistência do banco de dados. Vimos os três tipos de problemas que podem ocorrer em um SGBD devido à falta do controle de concorrência. Consideramos as principais técnicas, ou como também são conhecidas, protocolos para o controle de concorrência: bloqueio, timestamp e validação. Bloqueios podem ser compartilhados, quando o item de dados é utilizado por outras transações (normalmente em operações somente de leitura), ou exclusivos (geralmente usados em operações de escrita). A técnica de timestamp define a serialização das transa-ções em intervalos de tempo. Enquanto a validação define fases para as transações de maneira que as fases de escrita não se sobreponham, mantendo a consistência.

1. Três problemas que podem ocorrer devido à falta de controle de concor-rência entre transações são:

a) isolamento, durabilidade e integridade;

b) fantasmas, isolamento e atualização perdida;

c) atualização perdida, dependência sem commit e análise inconsistente;

d) deadlock, integridade e análise inconsistente.

2. As principais técnicas ou protocolos utilizados para o controle de concor-rência entre transações são:

a) bloqueio em duas fases, gerenciamento de concorrência e transação;

b) bloqueio, timestamp e validação;

c) start, validação e finish;

d) read_TS(), Write_TS e timestamp.

3. O bloqueio consiste na técnica mais utilizada pelos SGBDs para o controle de concorrência. Uma das suas desvantagens consiste no deadlock ou também conhecido como impasse. Descreva o que consiste o deadlock e como o banco deve proceder caso uma situação de impasse seja encontrada.

4. Explique o funcionamento do protocolo de timestamp, considerando duas operações concorrentes A e B sobre um mesmo item de dados Q.



acessos concorrentes sejam cada vez mais presentes, sobretudo pelo crescimento dos sistemas de informação cuja plataforma é o ambiente da Internet.

Nesta aula, apresentamos os conceitos básicos relacionados ao controle de concorrência, que é um mecanismo utilizado para garantir as propriedades das transações e a consistência do banco de dados. Vimos os três tipos de problemas que podem ocorrer em um SGBD devido à falta do controle de concorrência. Consideramos as principais técnicas, ou como também são conhecidas, protocolos para o controle de concorrência: bloqueio, timestamp e validação. Bloqueios podem ser compartilhados, quando o item de dados é utilizado por outras transações (normalmente em operações somente de leitura), ou exclusivos (geralmente usados em operações de escrita). A técnica de timestamp define a serialização das transa-ções em intervalos de tempo. Enquanto a validação define fases para as transações de maneira que as fases de escrita não se sobreponham, mantendo a consistência.

1. Três problemas que podem ocorrer devido à falta de controle de concor-rência entre transações são:

a) isolamento, durabilidade e integridade;

b) fantasmas, isolamento e atualização perdida;

c) atualização perdida, dependência sem commit e análise inconsistente;

d) deadlock, integridade e análise inconsistente.

2. As principais técnicas ou protocolos utilizados para o controle de concor-rência entre transações são:

a) bloqueio em duas fases, gerenciamento de concorrência e transação;

b) bloqueio, timestamp e validação;

c) start, validação e finish;

d) read_TS(), Write_TS e timestamp.

3. O bloqueio consiste na técnica mais utilizada pelos SGBDs para o controle de concorrência. Uma das suas desvantagens consiste no deadlock ou também conhecido como impasse. Descreva o que consiste o deadlock e como o banco deve proceder caso uma situação de impasse seja encontrada.

4. Explique o funcionamento do protocolo de timestamp, considerando duas operações concorrentes A e B sobre um mesmo item de dados Q.



Na atividade um, a alternativa correta é a letra (c), visto que conforme apre-sentado em aula, os principais problemas de concorrência consistem na atuali-zação perdida, dependência sem commit e análise inconsistente.

Já na atividade dois, a opção correta é a alternativa (b), já que as princi-pais técnicas ou protocolos utilizados para a gerência do controle de concor-rência consistem no bloqueio, timestamp e validação conforme foi considerado nesta aula.

Na atividade três, você expôs que o deadlock é um problema gerado pelo controle de concorrência que utilize o bloqueio, visto que duas ou mais transa-ções podem tentar fazer uso de um mesmo item de dados, criando, assim, um impasse. Quando um SGBD se depara com tal situação, deve reverter uma das transações, dando liberdade para que a outra prossiga.

Na atividade quatro, você colocou que o timestamp é um valor que é atri-buído a uma transação com o intuito de organizar a ordem de execução das tran-sações. Existem duas formas para se atribuir um timestamp a uma transação: por meio do clock do computador ou de contadores lógicos. Após definido o times-tamp de uma transação, são seguidas regras que definem o acesso aos dados. Isso depende se o timestamp de uma transação tem prioridade maior que os das demais transações concorrentes em suas operações sobre um item de dados.

Se você acertou as atividades, atingiu os objetivos propostos para a aula: compreender o porquê da utilização da concorrência nas transações e identi-ficar os principais problemas e técnicas para o controle de concorrência.




Estudaremos os sistemas de recuperação de bancos de dados. Ao contrário de outras situações, o termo recuperação, na próxima aula, não significa acesso às informações armazenadas, mas recuperação da consistência do banco de dados em caso de falhas.


compreender os tipos de falhas que podem ocorrer em um banco de •dados;

entender os mecanismos de recuperação de falhas.•

Para que os objetivos desta aula sejam atingidos, é importante que você compreenda o conceito de transação, a importância das proriedades ACID de uma transação e a noção de consistência de um banco de dados, consistência esta que é resultado da garantia das propriedades ACID, conteúdos estudados nas aulas três e quatro. Esses conteúdos são importantes para esta aula justa-mente porque as técnicas de recuperação são usadas para garantir que as propriedades ACID sejam mantidas.

Um sistema de computador, como qualquer outro dispositivo está sujeito a falhas por uma série de causas: falha de disco, falta de energia, erro de software, um incêndio, desabamento e até mesmo sabotagem (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).

Seja qual for o motivo de uma falha, em um sistema de banco de dados, é necessário que as propriedades de atomicidade e durabilidade sejam garan-tidas para que o banco de dados permaneça em um estado consistente.

Um dos componentes que integra um sistema de banco de dados é um sistema de recuperação. Esse sistema tem a responsabilidade de fazer com que, após a ocorrência de alguma falha, o banco de dados volte a um estado de consistência. Nesta aula, estudaremos justamente os sistemas de recuperação.




compreender os tipos de falhas que podem ocorrer em um banco de •dados;

entender os mecanismos de recuperação de falhas.•

Para que os objetivos desta aula sejam atingidos, é importante que você compreenda o conceito de transação, a importância das proriedades ACID de uma transação e a noção de consistência de um banco de dados, consistência esta que é resultado da garantia das propriedades ACID, conteúdos estudados nas aulas três e quatro. Esses conteúdos são importantes para esta aula justa-mente porque as técnicas de recuperação são usadas para garantir que as propriedades ACID sejam mantidas.

Um sistema de computador, como qualquer outro dispositivo está sujeito a falhas por uma série de causas: falha de disco, falta de energia, erro de software, um incêndio, desabamento e até mesmo sabotagem (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).

Seja qual for o motivo de uma falha, em um sistema de banco de dados, é necessário que as propriedades de atomicidade e durabilidade sejam garan-tidas para que o banco de dados permaneça em um estado consistente.

Um dos componentes que integra um sistema de banco de dados é um sistema de recuperação. Esse sistema tem a responsabilidade de fazer com que, após a ocorrência de alguma falha, o banco de dados volte a um estado de consistência. Nesta aula, estudaremos justamente os sistemas de recuperação.

Sistema de recuperação

Aula 5



5.1 Classificação de falhas

Existem vários tipos de falhas que podem ocorrer em um sistema, cada um deles precisa ser tratado de uma maneira diferente. O tipo mais simples de falha é o que não resulta na perda de informações no sistema. Falhas que causam perda de informações são mais difíceis de tratar (SILBERSCHATZ; KORTH; SUDARSHAN, 2006).

Elmasri e Navathe (2005) descrevem alguns tipos principais de falhas, subdividindo-os em categorias: falha de transações, falha de sistema e falha de discos (ou mídia). Vejamos em que consiste cada uma dessas falhas.

Falha do computador• : um erro de hardware, software ou rede ocorre e em um sistema de computador durante a execução de uma transação, por exemplo, uma falha na memória principal.

Um erro de transação ou sistema• : alguma operação da transação pode ocasionar uma falha, como um estouro de inteiro, ou uma divisão por zero. Falhas de transação também podem ocorrer por conta de valores errados de um parâmetro ou por erros na lógica de programação. Além disso, o próprio usuário pode interromper a operação antes do término da transação.

Erros locais ou condições de exceção detectadas para a transação• : durante a execução de uma transação, podem ocorrer determinadas condições que necessitem o cancelamento da transação, por exemplo, os dados para a transação não estarem disponíveis.

Imposição do controle de concorrência• : o método de controle de concor-rência pode optar por abortar uma transação para ser reiniciada poste-riormente caso ela viole a ordem de serialização ou porque diversas transações estão em estado de deadlock.

Falha de disco• : alguns blocos de disco podem perder seus dados por causa de mau funcionamento de uma leitura ou gravação.

Problemas físicos ou catástrofes• : referem-se a uma lista sem fim de problemas que incluem falha de energia, furto, sabotagem, sobre gravação de dados, etc.

Saiba mais



5.2 Recuperação

Para determinar como um sistema deve se recuperar de falhas, precisamos identificar os modos de falha dos dispositivos usados para armazenamento de dados. Em seguida, temos de considerar como esses modos de falhas afetam o conteúdo do banco de dados. Podemos, então, propor algoritmos para garantir a coerência do banco de dados e a atomicidade das transações efetuadas apesar das falhas (SILBERSCHATZ; KORTH; SUDARSHAN, 2006). Essas ações podem ser tomadas durante a execução das transações para garantir que haja informações suficientes para recuperar falhar (caso elas ocorram) ou podem ser tomadas após a ocorrência de falhas, para recuperar os dados e retornar o banco de dados a um estado consistente.

Segundo Elmasri e Navathe (2005), a recuperação de transações que falharam significa, em geral, que o banco de dados será restaurado para o estado de consistência mais recente, exatamente antes do momento da falha. Para isso, o sistema deverá manter informações sobre as alterações que foram aplicadas no banco de dados pelas várias transações executadas. Geralmente, essas informa-ções são armazenadas em arquivos chamados de log (histórico) do sistema.

Uma estratégia genérica para recuperação de falhas pode ser baseada em dois pontos principais, que são mencionados a seguir.

a) Se houver um dano extenso em uma grande porção do banco de dados, por conta de uma falha catastrófica, tal com uma falha de disco, o método de recuperação restaura uma cópia anterior do banco de dados que estava guardada em um arquivo de armazenamento (o que chamamos de backup) e o reconstrói em um estado mais atual, reapli-cando ou refazendo as operações das transações armazenadas no log até o instante da falha.

b) Quando o banco de dados não for danificado fisicamente, mas se tornar inconsistente por causa de uma falha não catastrófica, a estratégia é reverter quaisquer mudanças que causaram a inconsistência, desfa-zendo algumas operações. Além disso, será necessário refazer algumas operações para restaurar o estado consistente do banco de dados.

5.2.1 Recuperação baseada em log

A estrutura mais utilizada para registrar as modificações do banco de dados é o log. O log é uma seqüência de registros de atividades de atualização no banco de dados. Um registro de log de atualização descreve uma escrita no banco de dados, ou seja, armazena dados suficientes para que a transação seja refeita, caso necessário. Em geral, uma entrada de log, conforme Silberschatz, Korth e Sudarshan (2006) contém os seguintes campos:

identificador de transação• : é o identificador exclusivo da transação que realizou a operação de escrita;



identificador do item de dados• : identificador único do item de dados que foi escrito, normalmente, o local no disco em que o item foi armazenado;

valor antigo• : valor do item de dados antes da escrita;

novo valor• : valor que o item de dados passa a ter após a escrita.

Observe que a capacidade de desfazer uma alteração no banco de dados se apóia no armazenamento do valor antigo dos dados envolvidos em uma escrita. Assim, em caso de falhas, eles podem ser restaurados. Sempre que uma transação realiza uma escrita, é essencial que o registro de log seja feito antes que o banco de dados seja modificado. Após o registro em log da transação, a modificação do banco de dados pode ser liberada.

Um ponto importante para que a técnica de recuperação baseada em log seja realmente útil é que os registros de log devem estar armazenados em local estável. Imagine uma situação em que os arquivos de log estão armazenados no mesmo disco que o sistema de banco de dados e que ocorra uma falha no disco. Existe a possibilidade de que o arquivo de log seja danificado em conjunto do banco de dados. Dessa maneira, sugere-se que o log seja armazenado em um local externo ao sistema de banco de dados.

Outro aspecto a ser observado é que cada transação efetuada em um banco de dados resulta em uma entrada no registro de log. Dessa forma, esse arquivo pode se tornar muito grande em um pequeno intervalo de tempo. Portanto devemos pensar, também, em como manipular esses arquivos com eficiência.

5.2.2 Recuperação baseada na atualização adiada

A idéia contida nas técnicas de atualização adiada é postergar quais-quer atualizações no banco de dados real até que a transação complete sua execução com sucesso e alcance o seu ponto de efetivação. Durante a execução de uma transação, as atualizações são gravadas em log. Quando a transação alcançar o seu ponto de efetivação, há a gravação do log em um meio estável de armazenamento, então as atualizações podem ser efetuadas sobre o banco de dados.

Se uma transação falhar antes de alcançar o seu ponto de efetivação, não será necessário desfazer nenhuma alteração, pois a transação não afetou o banco de dados no disco. Assim, segundo Elmasri e Navathe (2005), podemos definir um protocolo de atualização adiada em:

a) uma transação que não pode mudar o banco de dados em disco até que atinja o seu ponto de efetivação;

b) uma transação que não alcança o seu ponto de efetivação até que todas as suas operações de atualização sejam registradas no log, e até que o log seja gravado em disco.



Outra observação interessante é que alguns tipos de transações não afetam o banco de dados. Operações como geração e impressão de relatórios são caracterizadas por ações de leitura apenas. Mesmo assim pode ser inviável que elas sejam retornadas ao usuário “meio completas”, pois um relatório baseado em dados incorretos pode ser usado como instrumento para tomada de decisão, o que acarretaria um problema não para o sistema em si, mas para o negócio (o que pode ser ainda pior!).

Um sistema de recuperação pode atuar nesse contexto informando ao usuário que um determinado relatório foi gerado com erro. Outra ação seria garantir que esse relatório somente seja gerado depois que a transação alcance o seu ponto de efetivação. Outra opção é compor comandos que gerem relatórios e os mantenham como tarefas em lote, sendo executadas apenas depois que a transação alcançar seu ponto de efetivação. Caso a transação falhe, as tarefas em lote são canceladas.

5.2.3 Recuperação baseada na atualização imediata

As técnicas de modificação imediata permitem que as modificações no banco de dados sejam enviadas ao sistema quando a transação ainda está em estado ativo. As modificações de dados escritas pelas transações ativas são chamadas de modificações não confirmadas (SILBERSCHATZ; KORTH; SUDARSHAN, 2006). Caso ocorra alguma falha durante uma transação, o sistema precisará utilizar o campo valor antigo do registro de log para restaurar os itens de dados modificados para que retornem aos valores que tinham antes da transação ser iniciada.

Para que esse método funcione corretamente, é necessário que cada operação de atualização (mesmo antes da efetivação da transação) seja execu-tada somente depois que um registro de log dessa operação seja gravado em meio de armazenamento estável. Dessa maneira, as atualizações no banco de dados podem ser feitas imediatamente, mas com a possibilidade de recupe-ração das alterações feitas.

Segundo Elmasri e Navathe (2005), teoricamente, podemos identificar dois tipos principais de algoritmos de atualização imediata, que citamos a seguir.

Algoritmo de recuperação • UNDO/NO-REDO (desfaz e não refaz): caracterizado pelo fato de que é garantido que todas as atualizações (escritas) de uma transação sejam registradas no banco de dados em disco antes da transação se efetivar. Dessa forma, em caso de falha na transação, não será necessário refazer as atualizações, apenas desfazer as que já executaram.

Algoritmo • UNDO/REDO (desfaz-refaz): se é permitido que a transação seja efetivada antes que todas as mudanças sejam escritas no banco de dados, temos uma técnica do tipo UNDO/REDO.



5.2.4 Pontos de verificação (checkponts)

Quando ocorre uma falha do sistema, é preciso consultar o arquivo de log para determinar quais transações precisam ser refeitas e quais transações precisam ser desfeitas. Em muitos casos, é preciso percorrer todo o arquivo de log para obter essa informação. Conforme Silberschatz, Korth e Sudarshan (2006), essa técnica apresenta duas dificuldades:

o processo de busca é demorado;•

a maioria das transações que precisam ser refeitas já enviaram suas •atualizações para o banco de dados. Embora refazê-las não cause dano algum, a recuperação leva mais tempo.

Para reduzir esse tipo de sobrecarga, são utilizados os pontos de verificação. Durante a execução, o sistema mantém o log, usando uma das duas técnicas apresentadas (atualizações adiadas ou imediatas). Além da utilização de logs, o sistema implementa pontos de verificação, por meio das seguintes ações:

a) enviar para armazenamento estável todos os registros atualmente resi-dentes na memória principal;

b) enviar para o disco todos os blocos modificados;

c) enviar para o armazenamento estável um registro de log <checkpoint>.

Essa técnica permite melhorar o esquema de recuperação das outras já citadas e funciona da seguinte maneira: quando houver uma falha, o esquema de recuperação examina o log no sentido do último registro para o primeiro, para identificar a transação T que foi iniciada após o último ponto de verificação. Dessa maneira, apenas precisarão ser desfeitas, ou refeitas as transações que iniciaram após o começo da transação T, além de T, é claro. Assim diminui o custo da recuperação do banco de dados.


5.2.5 Recuperação com transações concorrentes

Segundo Elmasri e Navathe (2005), independente do número de transações simultâneas, um sistema de banco de dados tem um único buffer de disco e um único arquivo de log.



O esquema de recuperação depende muito do mecanismo de controle de concorrência. Para reverter uma transação que falhou, temos de desfazer as atualizações realizadas pela transação. Supondo que uma transação T deve ser revertida e que atualizou um item de dados X, ela deve ser revertida e o valor do item de dados modificado deve ser restaurado de acordo com o seu valor antigo registrada em log. Vamos supor, ainda, que outra transação S atualizou o valor do item de dados X antes de T ser refeita. Nesse caso, a atualização feita pela transação S será perdida.

Para resolver essa situação, podemos perceber que, enquanto a transação T é revertida, atualizando um item de dados X, nenhuma outra transação poderá atualizar o mesmo item de dados até que T seja revertida ou efetivada. Esse requisito pode ser garantido utilizando uma técnica de bloqueio em duas fases com bloqueios exclusivos enquanto a transação é completada.

5.2.6 Recuperação em sistemas de bancos de dados múltiplos

Até o momento consideramos apenas a recuperação de falhas em um único sistema de banco de dados. Porém não é rara a execução de transações em bancos de dados distribuídos (conceitos que veremos com mais detalhes na próxima aula). Nesse cenário, uma única transação, chamada de transação multibanco de dados, pode acessar diversos bancos de dados, que podem estar armazenados em diferentes sítios e ainda sob a gerência de diferentes SGBDs (ELMASRI; NAVATHE, 2005).

Para manter a atomicidade de uma transação em um multibanco de dados é necessário ter um mecanismo de recuperação em dois níveis: um gerenciador de recuperação global, ou coordenador, responsável por manter as informações exigidas para recuperação; e os gerenciadores de recuperação locais, respon-sáveis pelos registros de log.

A recuperação em múltiplos bancos de dados é baseada em duas fases.

a) Fase 1: quando todos os bancos de dados participantes sinalizarem ao coordenador que a sua parte na transação multibanco de dados foi concluída, ele envia uma mensagem de preparação para efetivação a fim de informar cada participante, que deverá registrar as alterações em log e enviar ao coordenador uma resposta de OK ou não-OK (no caso de ocorrer alguma falha).

b) Fase 2: se todos os bancos de dados participantes responderem OK (inclusive o coordenador), o coordenador enviará um sinal de “efetivar” para cada participante, que gravará as alterações em log.

A idéia é que todos os bancos de dados efetivem a transação, ou nenhum deles o faça. No caso de haver alguma falha, será possível recuperar a consis-tência a partir de um estado no qual a transação possa ser efetivada ou revertida.



Uma falha ocorrida durante a fase 1 requer que a transação seja revertida (desfeita), enquanto que uma falha durante a fase 2 requer que a transação seja revertida e, em seguida, efetivada (desfeita e refeita novamente).

5.2.7 Sistema de backup

Certamente você já ouviu falar em backup e, provavelmente, a definição mais encontrada para esse termo é cópia de segurança. Muitos administradores de bancos de dados efetuam essa tarefa no dia-a-dia, sempre fazendo uma cópia do banco de dados para que, em caso de alguma falha (sobretudo as catastróficas).

Silberschatz, Korth e Sudarshan (2006) sugerem que, para obtermos alta disponibilidade, podemos realizar o processamento das transações em um local chamado de sítio primário e manter um sítio secundário, no qual todos os dados do sítio primário são replicados. O sítio secundário também é chamado de backup remoto.

O backup precisa ser sincronizado com o sítio primário enquanto as transa-ções são processadas nele. Essa sincronização pode ser obtida enviando todos os registros de log para o backup. Esse sítio de backup deve estar fisicamente distante do sítio primário para evitar que, caso ocorra algum desastre, o backup não seja danificado junto com o primário.

Quando o sítio primário falhar, o sistema de backup remoto irá utilizar a última cópia de segurança efetuada e aplicar sobre essa cópia todos os registros de log das transações efetuadas desde então. Assim teremos, ao final desse processa-mento o banco de dados no seu estado atualizado e consistente. Três desafios são fundamentais para o bom funcionamento de um sistema de backup.

Detecção de falha• : o sistema de backup deve ter um mecanismo para detectar uma falha no sistema primário. Um caso clássico é uma falha na comunicação que pode fazer com que o sistema de backup “ache” que o sistema primário falhou e inicie as rotinas de recuperação. Uma solução para esse caso é manter duas conexões distintas utilizando tecnologias dife-rentes para aumentar a confiabilidade do sistema de detecção de falhas.

Transferência de controle• : quando o sistema primário falha, o sistema de backup assume o papel e passa a processar as transações. Ao retornar à operação, o antigo sistema primário pode tanto permanecer como backup, quanto voltar a ser o primário. Essa decisão pode depender, por exemplo, da tecnologia de comunicação que dá acesso ao sistema primário original e ao sistema de backup;

Tempo de recuperação• : quando os arquivos de log se tornam muito grandes pode ser necessário um longo tempo para processá-los e deixar o banco de dados em um estado consistente e atual. Um sistema de backup que leva muito tempo para estar disponível pode não atender as necessidades da

aplicação. Uma solução para esse problema é o processamento periódico do arquivo de log, para que, quando houver a necessidade, seja gasto menos tempo para iniciar a operação do sistema de backup.

A utilização de sistemas de recuperação é muito importante, já que as infor-mações correspondem a um dos bens mais preciosos das instituições. A perda dessa informação pode trazer um prejuízo muito grande em termos de tempo, de refazer o trabalho anterior e também financeiro.

Nesta aula, estudamos algumas metodologias para recuperação de falhas em sistemas de bancos de dados, como a utilização de logs, que armazenam registros que contêm informações suficientes para que transações sejam refeitas quando necessário.

Vimos também os métodos baseados em atualização adiada e imediata. O primeiro sugere que os dados sejam efetivados no banco de dados definitivo em um momento de poucos acessos. O segundo sugere que as atualizações sejam gravadas no momento do processamento das transações.

Os pontos de verificação definem pontos de checagem a partir dos quais as transações podem ser recuperadas. Já os sistemas de recuperação em ambientes concorrentes utilizam técnicas baseadas nos mecanismos de controle de concorrência.

Os métodos apresentados são baseados na utilização de arquivos de log, que não armazenam o banco de dados, mas registros que permitem identificar as transações efetuadas de maneira que possamos reconstruir as alterações até retornar o banco de dados a um estado atualizado e consistente.

1. Entre os tipos de falhas citados, encontramos falhas de equipamento, de sistema, etc. Mas nenhuma delas inclui o usuário ou as aplicações. Em relação ao sistema de banco de dados, uma ação do usuário pode ser responsável por alguma falha? E em relação às aplicações que acessam o banco de dados? O que pode ser feito em relação à prevenção de falhas provocadas pelo usuário?

2. Em relação à utilização de arquivos de log, devemos considerar que existe um custo para implementação dessa técnica, por exemplo, espaço para armazenamento. A utilização de um backup completo do banco de dados não seria mais simples do que armazenar registros de log que ainda preci-sarão ser processados para entrarem em operação?



aplicação. Uma solução para esse problema é o processamento periódico do arquivo de log, para que, quando houver a necessidade, seja gasto menos tempo para iniciar a operação do sistema de backup.

A utilização de sistemas de recuperação é muito importante, já que as infor-mações correspondem a um dos bens mais preciosos das instituições. A perda dessa informação pode trazer um prejuízo muito grande em termos de tempo, de refazer o trabalho anterior e também financeiro.

Nesta aula, estudamos algumas metodologias para recuperação de falhas em sistemas de bancos de dados, como a utilização de logs, que armazenam registros que contêm informações suficientes para que transações sejam refeitas quando necessário.

Vimos também os métodos baseados em atualização adiada e imediata. O primeiro sugere que os dados sejam efetivados no banco de dados definitivo em um momento de poucos acessos. O segundo sugere que as atualizações sejam gravadas no momento do processamento das transações.

Os pontos de verificação definem pontos de checagem a partir dos quais as transações podem ser recuperadas. Já os sistemas de recuperação em ambientes concorrentes utilizam técnicas baseadas nos mecanismos de controle de concorrência.

Os métodos apresentados são baseados na utilização de arquivos de log, que não armazenam o banco de dados, mas registros que permitem identificar as transações efetuadas de maneira que possamos reconstruir as alterações até retornar o banco de dados a um estado atualizado e consistente.

1. Entre os tipos de falhas citados, encontramos falhas de equipamento, de sistema, etc. Mas nenhuma delas inclui o usuário ou as aplicações. Em relação ao sistema de banco de dados, uma ação do usuário pode ser responsável por alguma falha? E em relação às aplicações que acessam o banco de dados? O que pode ser feito em relação à prevenção de falhas provocadas pelo usuário?

2. Em relação à utilização de arquivos de log, devemos considerar que existe um custo para implementação dessa técnica, por exemplo, espaço para armazenamento. A utilização de um backup completo do banco de dados não seria mais simples do que armazenar registros de log que ainda preci-sarão ser processados para entrarem em operação?



3. Sobre as técnicas de recuperação apresentadas nesta aula, é incorreto afirmar que:

a) As técnicas de recuperação baseadas em atualização imediata e recu-peração baseada em atualização adiada utilizam arquivos de log para funcionarem;

b) Quando um backup entra em operação, as atualizações em arquivos de log que ainda não foram processados somente serão processadas depois que o sistema primário voltar a operar. Enquanto isso, o backup trabalha com dados desatualizados sem prejuízo, pois eles serão atua-lizados posteriormente;

c) É possível implementar a técnica de backup em sistemas multibanco de dados, da mesma forma que os gerenciadores locais de recuperação mantêm arquivos de log para as transações executadas em cada banco de dados local;

d) A técnica de backup pode, também, utilizar arquivos de log para processar as últimas atualizações em um banco de dados antes do sistema de backup entrar em operação.

4. Assinale a alternativa que não apresenta uma vantagem da utilização de técnicas de recuperação.

a) Facilidade de refazer as transações para manter o banco de dados consistente.

b) Maior necessidade de capacidade de armazenamento e processamento para gerenciar os arquivos de log.

c) Menor prejuízo quando ocorrem falhas.

d) Não há vantagens reais na utilização de técnicas de recuperação.

As atividades desta aula nos levam a refletir sobre o tema sistemas de recu-peração. Ao responder corretamente as atividades você terá atingido os obje-tivos da aula, que são: compreender os tipos de falhas que podem ocorrer em um banco de dados e entender os mecanismos de recuperação de falhas. Vamos verificar se você os atingiu?

Na atividade um, você disse que erros do usuário podem, indiretamente, resultar em falhas do sistema, e essas falhas já estão previstas nas técnicas apresentadas (rever tipos de falhas). Erros de rede ou desastres também podem ser causados pelo usuário, tendo um impacto direto nos sistemas de bancos de dados. Embora nenhuma das falhas citadas no início desta aula referencie

diretamente o usuário, todas refletem a ação dele (exceto as causas naturais). Em relação a como se prevenir contra erros causados pelo usuário, as técnicas de recuperação apresentadas estão suficientemente instrumentadas para lidar com falhas causadas pelos usuários, pois permitem desfazer e refazer altera-ções corretamente.

Na atividade dois, você mencionou que a utilização de sistemas de backup é muito útil, porém, caso não haja um log de transações e alguma falha de tran-sação ocorra, teremos duas cópias inconsistentes de um mesmo banco de dados. A cópia de segurança apenas garante que os dados não serão perdidos, porém não podem garantir que os dados armazenados estejam consistentes. Por isso os logs são tão importantes.

Na atividade três, a afirmação incorreta é a da letra (b), pois um sistema de backup somente deve entrar em operação quando as atualizações previstas no arquivo de log forem executadas. Caso contrário, o sistema pode operar certo tempo com um banco de dados inconsistente e, quando o sistema primário voltar a operar, a aplicação das atualizações pode não ser suficiente para recuperar a consistência do banco de dados.

Na atividade quatro, a única alternativa que não apresenta uma vantagem da utilização de técnicas de recuperação é a (b), que comenta a maior necessidade de armazenamento e processamento para gerenciar os arquivos de log. Obviamente é previsto um custo computacional para que as técnicas de recuperação sejam implementadas, porém é preciso pensar a sua viabilidade observando a relação custo/benefício, pois certamente o prejuízo causado pela perda dos dados é maior do que o investimento em recuperação de falhas.



Estudaremos um modelo de banco de dados que vem cada vez mais ganhando espaço no mercado, os bancos de dados distribuídos. Esse tipo de banco de dados tem características marcantes, tais como a forma de armazenamento para se obter vantagens em relação aos bancos de dados isolados. Estudaremos ainda sobre o controle de concorrência nesse tipo de banco de dados.



diretamente o usuário, todas refletem a ação dele (exceto as causas naturais). Em relação a como se prevenir contra erros causados pelo usuário, as técnicas de recuperação apresentadas estão suficientemente instrumentadas para lidar com falhas causadas pelos usuários, pois permitem desfazer e refazer altera-ções corretamente.

Na atividade dois, você mencionou que a utilização de sistemas de backup é muito útil, porém, caso não haja um log de transações e alguma falha de tran-sação ocorra, teremos duas cópias inconsistentes de um mesmo banco de dados. A cópia de segurança apenas garante que os dados não serão perdidos, porém não podem garantir que os dados armazenados estejam consistentes. Por isso os logs são tão importantes.

Na atividade três, a afirmação incorreta é a da letra (b), pois um sistema de backup somente deve entrar em operação quando as atualizações previstas no arquivo de log forem executadas. Caso contrário, o sistema pode operar certo tempo com um banco de dados inconsistente e, quando o sistema primário voltar a operar, a aplicação das atualizações pode não ser suficiente para recuperar a consistência do banco de dados.

Na atividade quatro, a única alternativa que não apresenta uma vantagem da utilização de técnicas de recuperação é a (b), que comenta a maior necessidade de armazenamento e processamento para gerenciar os arquivos de log. Obviamente é previsto um custo computacional para que as técnicas de recuperação sejam implementadas, porém é preciso pensar a sua viabilidade observando a relação custo/benefício, pois certamente o prejuízo causado pela perda dos dados é maior do que o investimento em recuperação de falhas.



Estudaremos um modelo de banco de dados que vem cada vez mais ganhando espaço no mercado, os bancos de dados distribuídos. Esse tipo de banco de dados tem características marcantes, tais como a forma de armazenamento para se obter vantagens em relação aos bancos de dados isolados. Estudaremos ainda sobre o controle de concorrência nesse tipo de banco de dados.




compreender os conceitos de bancos de dados distribuídos;•

entender as diferenças em relação aos sistemas centralizados e as impli-•cações de sua utilização.

Para que os objetivos desta aula sejam atingidos, é importante que você compreenda a visão geral do processo de projeto de bancos de dados, que conheça as tecnologias de bancos de dados e outras tecnologias que apóiam a sua utilização, como os conceitos básicos da comunicação entre computadores. Esses conceitos foram vistos nas diciplinas de Banco de Dados, no segundo período, e Redes de Computadores, no terceiro período. Eles ajudarão compre-ender os conceitos de bancos de dados distribuídos.

A arquitetura de um sistema de bancos de dados é bastante influenciada pelo sistema de computador básico em que ela trabalha, em particular, por aspectos da arquitetura de computador como redes, paralelismo e distribuição (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). Nesse sentido, podemos citar algumas arquiteturas como a centralizada, na qual os sistemas de bancos de dados executam em um único computador, não interagindo com outros (traba-lhando de forma isolada). Uma aplicação comum para esse tipo de arquitetura são os sistemas de pequeno porte e monousuários.

Também merece destaque a arquitetura cliente-servidor, na qual um servidor de banco de dados serve a vários sistemas clientes. Essa arquitetura é comumente encontrada em empresas, nas quais os softwares instalados nos diversos termi-nais interagem com o sistema de banco de dados por meio de uma rede local.

Anotações




compreender os conceitos de bancos de dados distribuídos;•

entender as diferenças em relação aos sistemas centralizados e as impli-•cações de sua utilização.

Para que os objetivos desta aula sejam atingidos, é importante que você compreenda a visão geral do processo de projeto de bancos de dados, que conheça as tecnologias de bancos de dados e outras tecnologias que apóiam a sua utilização, como os conceitos básicos da comunicação entre computadores. Esses conceitos foram vistos nas diciplinas de Banco de Dados, no segundo período, e Redes de Computadores, no terceiro período. Eles ajudarão compre-ender os conceitos de bancos de dados distribuídos.

A arquitetura de um sistema de bancos de dados é bastante influenciada pelo sistema de computador básico em que ela trabalha, em particular, por aspectos da arquitetura de computador como redes, paralelismo e distribuição (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). Nesse sentido, podemos citar algumas arquiteturas como a centralizada, na qual os sistemas de bancos de dados executam em um único computador, não interagindo com outros (traba-lhando de forma isolada). Uma aplicação comum para esse tipo de arquitetura são os sistemas de pequeno porte e monousuários.

Também merece destaque a arquitetura cliente-servidor, na qual um servidor de banco de dados serve a vários sistemas clientes. Essa arquitetura é comumente encontrada em empresas, nas quais os softwares instalados nos diversos termi-nais interagem com o sistema de banco de dados por meio de uma rede local.

Bancos de dados distribuídos

Aula 6



Com a disseminação da tecnologia da informação e o crescimento do poder computacional dos sistemas, muitas instituições passaram a se utilizar dos sistemas de bancos de dados. Com o crescimento e a necessidade de integração desses sistemas, novos desafios surgiram. Um desses desafios era fazer com que uma única aplicação pudesse operar de modo transparente sobre dados dispersos, armazenados em bases de dados diferentes e gerenciados por diferentes SGBDs. É justamente a noção de bancos de dados distribuídos, tema desta aula.

6.1 Bancos de dados distribuídos

Um sistema de banco de dados distribuídos é, na verdade, uma espécie de banco de dados virtual, cujas partes componentes estão fisicamente armaze-nadas em vários bancos de dados reais distintos, em locais distintos, podendo ser descrito como a união lógica desses bancos de dados (DATE, 2004).

Os elementos que compõem um sistema de banco de dados distribuídos traba-lham em conjunto com o objetivo principal de resolver, de uma maneira eficiente, um problema grande que fora repartido em partes menores e mais fáceis de geren-ciar. Entretanto, considerando que cada um dos elementos é um sistema de banco de dados com usuários e demandas isoladas, esses elementos podem conter opera-ções independentes da interligação com outros sistemas de bancos de dados.

Nesse contexto, surge a idéia de um software responsável pelo gerencia-mento de todo o sistema de banco de dados distribuído, o SGBDD – Sistema Gerenciador de Banco de Dados Distribuídos. Uma das suas funções principais é permitir que os diversos bancos distribuídos pela rede sejam manipulados de forma transparente, ou seja, não cabe ao usuário conhecer detalhes da distri-buição dos dados nem das suas localizações (ALVES, 2004). Aliás, esse pode ser considerado o princípio fundamental dos bancos de dados distribuídos: para o usuário, um sistema distribuído deve parecer exatamente como um sistema não distribuído (DATE, 2004).

Muitos sistemas de bancos de dados distribuídos usam, atualmente, a Internet como meio de comunicação entre os usuários e o sistema. Considerando a grande diferença de velocidade de acesso aos dados dos sistemas isolados em relação aos sistemas distribuídos, um dos objetivos essenciais no projeto de bancos de dados distribuídos é a minimização do uso da rede, ou seja, diminuir ao máximo a troca de mensagens.

Outro aspecto importante dos sistemas distribuídos é a forma como os dados são armazenados. Duas técnicas de armazenamento merecem destaque: repli-cação e fragmentação, discutidas nos tópicos a seguir.

6.1.1 Replicação

Quando é utilizada a técnica de replicação, o sistema mantém várias réplicas (cópias) idênticas de uma mesma relação em diversos sítios (cada um



dos bancos de dados reais que estão distribuídos) diferentes (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). Uma replicação dita completa é aquela na qual existe uma cópia armazenada em cada sítio que compõe o sistema.

O uso de replicação traz alguns benefícios, como a disponibilidade dos dados. Já que podem estar em dois ou mais sítios diferentes, se houver alguma falha em um deles, os usuários podem continuar trabalhando normalmente, pois outras cópias estão disponíveis. Outra vantagem é o aumento da possibilidade de paralelismo nas operações, sobretudo nas operações de leitura, de maneira que quanto mais réplicas houver, maior a chance de que os dados sejam encon-trados no próprio sítio no qual a transação está sendo processada, diminuindo a necessidade de requisições pela rede.

Por outro lado, um número elevado de cópias de uma mesma relação em um sistema de banco de dados distribuído gera uma maior sobrecarga na atua-lização dos dados, visto que, para manter a consistência entre as réplicas, são necessárias diversas trocas de mensagens.

Podemos perceber, então, que a técnica de replicação é muito eficiente para melhorar o desempenho nas operações de leitura e também para aumentar a disponibilidade, porém, em operações de atualização, podem sobrecarregar o sistema.

6.1.2 Fragmentação

Quando utilizamos a técnica de fragmentação, o sistema particiona uma mesma relação em vários fragmentos e armazena cada fragmento em um sítio diferente (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). Existem dois tipos de fragmentação, a horizontal e a vertical.

Na fragmentação horizontal, subconjuntos de uma relação são armazenados em sítios diferentes. Usando analogia com tabelas, podemos dizer que a tabela é dividida em vários subconjuntos de linhas, e cada um desses subconjuntos é armazenado em pelo menos um dos fragmentos (sítios).

Uma vantagem que se pode obter com essa técnica é a distribuição de linhas da tabela pelos sítios que são mais acessados, fazendo um balanceamento de carga e diminuindo a necessidade de transferência de dados. Um exemplo seria fragmentar horizontalmente a tabela cliente de uma concessionária de planos de saúde, de maneira que as linhas contendo as informações dos clientes de uma determinada cidade ficassem armazenadas localmente. Dessa forma, apenas seria necessário transferir dados quando se desejasse acessá-los a partir de outra localidade.

Essa técnica não prejudica a transparência do sistema, já que podemos associar cada fragmento à localidade na qual está armazenada e reconstruir a relação em sua totalidade (como se não fosse fragmentada) consultando cada uma dos sítios que contém fragmentos desta tabela.



A fragmentação vertical é um pouco diferente. Nela não são as linhas de uma tabela que formarão os subconjuntos, mas as colunas. Dessa maneira, cada conjunto de atributos pode ficar em um sítio diferente. É necessário, porém, associar cada uma das colunas fragmentadas à relação original. Isso pode ser feito adicionando um campo que identifique a relação à qual aquela coluna pertence.

Uma das vantagens de se utilizar a fragmentação vertical está ligada à segu-rança dos dados, já que dificulta acessos indevidos a uma linha completa de uma tabela. Assim os dados acessados indevidamente podem não ser completos ou significativos, não tendo muito valor quando separados.

6.1.3 Tipos de bancos de dados distribuídos

Existem diversos fatores que podem distinguir um sistema de banco de dados distribuídos de outros. Um deles é o grau de homogeneidade, que diz respeito ao tipo de software que é utilizado em todo o sistema. Se os servidores e clientes utilizam software de um mesmo fabricante ou fornecedor (softwares idênticos) dizemos que é um SGBDD homogêneo, caso contrário, é considerado um SGBDD heterogêneo (ALVES, 2004).

No ambiente heterogêneo, há a necessidade de se definir um padrão de interoperabilidade. A interoperabilidade diz respeito à capacidade de um sistema interagir com outros, de diferentes tecnologias e padrões. Uma das maneiras de garantir a interoperabilidade em sistemas de bancos de dados distribuídos é a implementação de um midleware para conversão das mensa-gens trocadas entre os sítios. Outra forma é definir um protocolo comum de comunicação. Dessa maneira, mesmo com tecnologias diferentes, pode-se utilizar uma linguagem comum.

Outro aspecto que pode ser usado para classificação é o grau de autonomia local. O grau de autonomia local é a capacidade de um SGBD que faz parte de um sistema distribuído trabalhar isoladamente (atender as demandas de clientes locais). Se um SGBD tem essa capacidade, podemos dizer que ele tem auto-nomia local, caso contrário, dizemos que ele não tem autonomia local.

Segundo Alves (2004), destacam-se três tipos principais de autonomia.

Autonomia de comunicação• : capacidade de decidir comunicar-se com outro SGBD.

Autonomia de execução• : capacidade de executar operações locais sem sofrer nenhuma interferência de outras operações externas e para decidir a ordem em que elas devem ser executadas.

Autonomia de associação• : capacidade de decidir se suas funcionalidades e recursos devem ser compartilhados e quando serão compartilhados.



6.2 Transações distribuídas

Considerando dados replicados e/ou fragmentados em um banco de dados distribuído e considerando, ainda, que algumas características dos bancos de dados isolados devem ser mantidas, algumas tarefas, como a utilização de tran-sações para implementar as operações que são feitas sobre o banco de dados, é importante encontrar meios para que tais operações sejam executadas correta-mente no ambiente de um banco de dados distribuído.

Assim como em bancos de dados isolados, o acesso a diversos itens de dados em um sistema distribuído também é realizado por meio de transações, que, assim como nos sistemas isolados, precisam manter as propriedades ACID. Para que essas propriedades sejam garantidas, são propostas dois tipos de tran-sações: locais e globais.

6.2.1 Transações locais x transações globais

Segundo Silberchartz, Korth e Sudarshan (2006), transações locais são aquelas que acessam e atualizam dados apenas em um banco de dados local, enquanto que as transações globais são aquelas que acessam e atualizam dados em diversos bancos de dados locais. Garantir as propriedades ACID em transa-ções locais é tarefa similar a de fazer o mesmo em bancos de dados isolados, mas, no caso das transações globais, essa tarefa pode se tornar muito mais complexa, já que diversos sítios podem estar envolvidos.

Uma falha em um desses sítios, ou a perda da capacidade de comunicação (por exemplo, uma falha na rede) podem ocasionar situações nas quais os dados manipulados se tornem inconsistentes. Por essa razão se propõe uma estrutura para suportar as transações globais em sistemas de bancos de dados distribu-ídos. Essa estrutura se apóia em dois elementos principais: o gerenciador de transações e o coordenador de transações.

O gerenciador de transações controla a execução das transações que são executadas em bancos de dados locais. Vale ressaltar que uma transação local pode fazer parte de um conjunto de transações locais que compõem uma tran-sação global.

A atuação do gerenciador de transações em ambiente distribuído é muito parecida com a sua atuação em um sistema isolado. Suas principais tarefas são: manter um log para fins de recuperação e participar de um esquema de controle de concorrência para as transações que são executadas em um determinado sítio.

O coordenador de transações de um sítio coordena a execução de diversas transações, locais ou globais, iniciadas no sítio. Não sendo necessário em ambiente isolado, suas principais responsabilidades são iniciar a execução da transação, dividi-la em uma série de subtransações, distribuí-la de maneira adequada pelos diversos sítios e coordenar o término da transação.



6.3 Controle de concorrência em bancos de dados distribuídos

O controle de acesso concorrente a usuários e a recuperação de dados são fatores muito importantes em um SGBD distribuído. Usando esses meca-nismos, podemos tratar de alguns problemas inerentes aos bancos de dados distribuídos que não são comuns aos implementados em ambiente centralizado (ALVES, 2004).

Elmasri e Navathe (2005) descrevem esses problemas da seguinte maneira:

manipulação de múltiplas cópias dos itens de dados• : o método de controle de concorrência é responsável por manter a consistência entre essas cópias;

falhas em sítios individuais• : quando um determinado sítio entrar em estado de falha, o SGBDD deve ser capaz de continuar em operação utilizando os outros SGBDD que continuarem em operação;

falha de • links de comunicação: o sistema deve ser capaz de lidar com falha de um ou mais links de comunicação que conectam os sítios;

commit• distribuído: problemas podem surgir quando se está realizando um commit de uma transação que está acessando bancos de dados armazenados em múltiplos sítios e um desses sítios falharem durante o processo;

deadlock• distribuído: o deadlock pode ocorrer entre vários sítios, em uma situação na qual um aguarda o desbloqueio de um item de dados que está sendo acessado por outro e ambos ficam aguardando uma liberação.


Para o controle de concorrência em bancos de dados distribuídos, apre-sentamos dois tipos: baseados em cópia distinta de item de dados e controle baseado em votação. No primeiro tipo, se encontram técnicas que são extensões das já existentes para bancos de dados centralizados (ALVES, 2004).

Segundo Elmasri e Navathe (2005), a idéia é designar cada cópia parti-cular de um item de dados como uma cópia distinta. Os bloqueios para esse item de dados são associados à cópia distinta e todas as solicitações de bloqueio e desbloqueio são enviadas para o sítio que contém a cópia.



Vários métodos diferentes estão baseados nessa idéia, mas eles diferem em seus métodos para escolher as cópias distintas. Na técnica de sítio primário, todas as cópias distintas são mantidas no mesmo sítio. Uma modificação dessa abordagem é o sítio primário com um sítio de backup. Outra abordagem é o método da cópia primária, no qual as cópias distintas dos vários itens de dados podem ser armazenadas em sítios diferentes. Um sítio que inclui uma cópia distinta de um item de dados basicamente atua como o sítio coordenador do controle de concorrência para aquele item.

No método de votação, não há cópia distinta, em vez disso, uma solici-tação de bloqueio é enviada para todos os sítios que têm uma cópia do item de dados. Cada cópia mantém seu próprio bloqueio e pode conceder ou negar a solicitação para bloqueio. Se uma transação que solicitar um bloqueio e lhe for concedido pela maioria das cópias, ela mantém o bloqueio e informa a todas as cópias. Se uma transação não receber a maioria de votos que lhe concedam um bloqueio dentro de certo período de timeout, ela cancela a solicitação e informa a todos os sítios o cancelamento.

O método de votação é considerado um método de controle de concor-rência verdadeiramente distribuído, pois a responsabilidade por uma decisão reside em todos os sítios envolvidos. Estudos de simulação têm mostrado que a votação tem um tráfego maior de mensagens entre os sítios que os métodos de cópia distinta. Se o algoritmo levar em consideração as possíveis falhas de sítios durante o processo de votação, ele se torna extremamente complexo (ELMASRI; NAVATHE, 2005).

Silberchartz, Korth e Sudarshan (2006) ainda descrevem uma técnica de controle de concorrência baseada em bloqueios. Uma delas é a técnica de gerenciador de bloqueios único, na qual o sistema mantém um único geren-ciador de bloqueio que reside em um único sítio escolhido. Todas as solicitações de bloqueios são repassadas ao gerenciador e, se uma solicitação não puder ser atendida, ela é adiada até que seja possível concedê-la, caso contrário, o gerenciador de bloqueios envia uma mensagem para o sítio em que a solici-tação foi iniciada. No caso de uma atualização (escrita), todos os sítios que contêm uma réplica do item de dados devem ser envolvidos no processo, com a finalidade de manter a consistência entre as diferentes réplicas.

Esse esquema tem as vantagens de uma implementação simples e um simples tratamento de impasses, já que as decisões são centralizadas. Por outro lado, o gerenciador de bloqueios único se torna um gargalo para o sistema, já que deverá processar todas as solicitações. Além disso, esse modelo descreve um ponto único de falha. Caso o gerenciador deixe de operar, o processamento é interrompido até que alguma técnica de recuperação seja acionada.

Uma alternativa para manter o equilíbrio entre a simplicidade da implemen-tação e o desempenho é a utilização de um gerenciador de bloqueios distri-



buído, no qual cada sítio mantém um gerenciador de bloqueios sobre os itens de dados armazenados nesse sítio.

6.4 Questões sobre mobilidade

Os sistemas de bancos de dados distribuídos podem ser, ainda, implemen-tados utilizando dispositivos móveis. Nesse caso, um dos requisitos é a comuni-cação em um ambiente de redes sem fio. Um dos grandes desafios para a área de bancos de dados móveis é justamente tratar a movimentação dos sítios.

Outro aspecto importante é a possibilidade de itens de dados serem aces-sados a partir de dispositivos móveis. Nesse cenário, um dos grandes desafios é controlar o bloqueio de itens de dados quando um dispositivo migra da região de um sítio para outro. Assim um bloqueio concedido sobre uma determinada cópia que não mais será acessada deve ser tratado por algum mecanismo de controle de concorrência.

Saiba mais

A partir do que vimos nesta aula, podemos concluir que os bancos de dados distribuídos vêm se tornando cada vez mais comuns. As ferramentas projetadas para bancos de dados isolados nem sempre são capazes de tratar todas as particu-laridades dos bancos de dados distribuídos. O estudo de técnicas para tratar dessas particularidades é importante para atender os requisitos desse tipo de tecnologia.

Nesta aula, apresentamos os conceitos básicos de sistemas de bancos de dados distribuídos. Traçamos uma comparação entre o modelo centralizado e o modelo distribuído, abordando as suas vantagens e desvantagens. Estudamos também a forma de armazenamento dos dados em ambiente distribuído e técnicas de controle de concorrência. Analisamos os métodos de replicação (que determina que uma relação deve ser replicada em mais de um sítio que compõe o banco de dados) e fragmentação (que determina que partes de uma mesma relação podem estar em diferentes sítios) para armazenamento em bancos de dados distribuídos.

Falamos a respeito do mecanismo de transações distribuídas, que determinam a existência de dois tipos de transações: globais, quando envolvem diversos sítios, ou locais, quando executadas em um único sítio. Também vimos os meca-nismos de controle de concorrência, como os gerenciadores de bloqueios, que determinam as permissões de acesso aos itens de dados por transações.

Finalmente, falamos sobre questões de mobilidade, que comentam a possibi-lidade de o banco de dados ser acessado por estações móveis, ou mesmo a possi-bilidade de estações móveis serem utilizadas como sítios de armazenamento.

1. A fragmentação de relações em sistemas de bancos de dados distribuídos é muito útil em algumas situações. Assinale a alternativa que contém uma das vantagens de se utilizar a fragmentação vertical.

a) Ter subconjuntos de uma relação em diversos sítios diferentes.

b) Uma velocidade muito maior no atendimento das requisições, já que o processamento é feito em um único sítio.

c) Aumenta a segurança dos dados, já que, para uma linha de uma tabela ser acessada na sua forma completa, é necessário buscar seus atributos em diversos sítios diferentes.

d) A vantagem é armazenar os dados em um púnico fragmento, por isso é chamada de vertical.

2. Sobre transações distribuídas, é incorreto afirmar que:

a) podem ser classificadas em locais e globais;

b) transações locais são executadas de forma praticamente idêntica aos sistemas de bancos de dados centralizados;

c) transações globais, em geral, são controladas por um elemento do sistema chamado de coordenador de transações;

d) a propriedade de isolamento não se aplica às transações distribuídas, já que o isolamento nesse contexto é totalmente contrário à idéia de distribuição.

3. Quais as principais diferenças entre o controle de concorrência em bancos de dados distribuídos e bancos de dados isolados?

4. Quais as principais diferenças entre os métodos de fragmentação e de replicação?

Na atividade um, a alternativa correta é a (c), pois a fragmentação indica que um possível acesso indevido. Para ter acesso aos dados na sua forma completa, necessita ter acesso à política de fragmentação e às associações



Finalmente, falamos sobre questões de mobilidade, que comentam a possibi-lidade de o banco de dados ser acessado por estações móveis, ou mesmo a possi-bilidade de estações móveis serem utilizadas como sítios de armazenamento.

1. A fragmentação de relações em sistemas de bancos de dados distribuídos é muito útil em algumas situações. Assinale a alternativa que contém uma das vantagens de se utilizar a fragmentação vertical.

a) Ter subconjuntos de uma relação em diversos sítios diferentes.

b) Uma velocidade muito maior no atendimento das requisições, já que o processamento é feito em um único sítio.

c) Aumenta a segurança dos dados, já que, para uma linha de uma tabela ser acessada na sua forma completa, é necessário buscar seus atributos em diversos sítios diferentes.

d) A vantagem é armazenar os dados em um púnico fragmento, por isso é chamada de vertical.

2. Sobre transações distribuídas, é incorreto afirmar que:

a) podem ser classificadas em locais e globais;

b) transações locais são executadas de forma praticamente idêntica aos sistemas de bancos de dados centralizados;

c) transações globais, em geral, são controladas por um elemento do sistema chamado de coordenador de transações;

d) a propriedade de isolamento não se aplica às transações distribuídas, já que o isolamento nesse contexto é totalmente contrário à idéia de distribuição.

3. Quais as principais diferenças entre o controle de concorrência em bancos de dados distribuídos e bancos de dados isolados?

4. Quais as principais diferenças entre os métodos de fragmentação e de replicação?

Na atividade um, a alternativa correta é a (c), pois a fragmentação indica que um possível acesso indevido. Para ter acesso aos dados na sua forma completa, necessita ter acesso à política de fragmentação e às associações



entre as colunas fragmentadas e o processo de remontagem, dificultando a ação de tais acessos indevidos. A alternativa (a) fala da fragmentação hori-zontal e não vertical. A alternativa (b) também é incorreta, pois, se por um lado a fragmentação vertical pode acelerar o processamento quando se trata de um único atributo da relação, quando existe a necessidade de remontar a relação buscando dados em diferentes sítios, o processamento pode se tornar mais lento pela necessidade de trocas de mensagens entre os sítios. A alterna-tiva (d) é completamente contrária à idéia de fragmentação. A verticalidade ou horizontalidade da fragmentação diz respeito à estrutura das relações (se conjuntos de tuplas são armazenados em locais diferentes – horizontal – ou se conjuntos de atributos são armazenados em sítios diferentes). Esta atividade está relacionada ao primeiro objetivo da aula, que é compreender os conceitos de bancos de dados distribuídos.

Na atividade dois, a alternativa incorreta é a (d), uma vez que as proprie-dades ACID são desejáveis em qualquer transação de qualquer tipo de banco de dados. O isolamento de uma transação diz respeito ao isolamento dos dados e à influência que uma transação pode sofrer de outras operações que estejam acontecendo no mesmo momento. A alternativa (a) é correta, pois as transações em ambiente distribuído são realmente classificadas como locais ou globais. A alternativa (b) é correta, já que transações locais são efetuadas sobre um único sítio, não há a necessidade de considerar aspectos de um ambiente distribuído, como as trocas de mensagens entre os sítios que o compõem. A alternativa (c) é correta, pois o coordenador de transações é um elemento importante para controlar as transações globais, executadas em mais de um sítio.

A terceira atividade e a quarta atividade estão relacionadas com o segundo objetivo da aula, que é compreender as diferenças entre os bancos de dados isolados e os bancos de dados distribuídos. Para responder corre-tamente a atividade três, você mencionou que o controle de concorrência em ambiente distribuído deve considerar aspectos que não são necessários em ambiente isolado, já que em ambiente distribuído os dados manipulados em uma transação podem estar armazenados em diferentes sítios. Além disso, os mecanismos de bloqueio devem considerar diferentes tipos de transações, como as locais e globais.

Na atividade quatro, você foi coerente com a idéia de que a replicação atua como se vários bancos de dados isolados, ou relações completas de um banco de dados fossem copiados e estivessem disponíveis. Um dos problemas dessa técnica é a necessidade constante de atualização para manter a consistência entre as diferentes réplicas. A fragmentação sugere que partes de uma relação (um conjunto de registros ou uma coluna de uma relação) sejam armazenados em diferentes sítios.





Estudaremos alguns tópicos adicionais de bancos de dados. Mais especifi-camente sobre a utilização da linguagem XML no contexto de bancos de dados. Essa linguagem se tornou um padrão mundialmente utilizado de documentos estruturados para o ambiente web. Estudaremos também conceitos de segurança em bancos de dados.







Estudaremos alguns tópicos adicionais de bancos de dados. Mais especifi-camente sobre a utilização da linguagem XML no contexto de bancos de dados. Essa linguagem se tornou um padrão mundialmente utilizado de documentos estruturados para o ambiente web. Estudaremos também conceitos de segurança em bancos de dados.

Anotações




compreender a relação entre bancos de dados e XML;•

entender os conceitos de segurança em bancos de dados.•

Para que os objetivos desta aula sejam atingidos, é importante que você tenha uma visão geral dos sistemas de bancos de dados, da forma como os componentes de um sistema de banco de dados, como usuários, aplicativos e SGBDs, interagem entre si. Esses conceitos, apresentados na primeira aula desta disciplina e também já vistos na disciplina de Bancos de Dados do segundo período, são importantes para compreendermos os tópicos adicionais que são relacionados com os conceitos já estudados.

Por serem um elemento de grande importância nos sistemas de informação, as tecnologias voltadas para bancos de dados têm estado em constante evolução. Melhorias nas formas de armazenamento, metodologias de acesso, conexão física, técnicas de recuperação e de acesso a dados são alvo de diversos estudos acadêmicos, técnicos e profissionais.

Algumas áreas, como a segurança de dados, são muito importantes, já que em bancos de dados podem ser armazenadas grandes quantidades de informa-ções confidenciais relevantes ao negócio de uma empresa, dados pessoais e/ou bancários que devem ser preservados.

Estudos têm sido realizados, também, para desenvolver padrões de arma-zenamento e personalização dos dados. Nesse sentido, em conjunto com o crescente número de aplicações que envolvem bancos de dados baseadas no




compreender a relação entre bancos de dados e XML;•

entender os conceitos de segurança em bancos de dados.•

Para que os objetivos desta aula sejam atingidos, é importante que você tenha uma visão geral dos sistemas de bancos de dados, da forma como os componentes de um sistema de banco de dados, como usuários, aplicativos e SGBDs, interagem entre si. Esses conceitos, apresentados na primeira aula desta disciplina e também já vistos na disciplina de Bancos de Dados do segundo período, são importantes para compreendermos os tópicos adicionais que são relacionados com os conceitos já estudados.

Por serem um elemento de grande importância nos sistemas de informação, as tecnologias voltadas para bancos de dados têm estado em constante evolução. Melhorias nas formas de armazenamento, metodologias de acesso, conexão física, técnicas de recuperação e de acesso a dados são alvo de diversos estudos acadêmicos, técnicos e profissionais.

Algumas áreas, como a segurança de dados, são muito importantes, já que em bancos de dados podem ser armazenadas grandes quantidades de informa-ções confidenciais relevantes ao negócio de uma empresa, dados pessoais e/ou bancários que devem ser preservados.

Estudos têm sido realizados, também, para desenvolver padrões de arma-zenamento e personalização dos dados. Nesse sentido, em conjunto com o crescente número de aplicações que envolvem bancos de dados baseadas no

Tópicos adicionais

Aula 7



ambiente da Internet, surgiu a linguagem XML, que tem tido uma forte ligação com os sistemas de bancos de dados. Os tópicos de segurança e utilização de XML serão estudados nesta aula.

7.1 XML

Extensible Markup Language, ou linguagem de marcação extensível, é uma linguagem que permite a estruturação de documentos. Linguagens muito difundidas, como HTML – Hypertext Transfer Protocol –, também se enquadram na categoria das linguagens de marcação. Porém as marcações em HTML são rígidas, permitindo que os documentos sejam estruturados somente de acordo com as regras dessa linguagem. Já a linguagem XML permite que os documentos sejam estruturados de acordo com as necessidades do usuário (da linguagem). Nesse contexto, uma marcação refere-se a qualquer elemento de um documento que não sirva como parte de sua saída impressa (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). Por exemplo, partes de um texto podem ser formatadas de maneira diferente, isso pode ser expresso por meio de marcações.

Dois conceitos principais são usados para construir um documento XML: elementos e atributos (ELMASRI; NAVATHE, 2005). É importante observar que, em XML, o termo atributo não é usado da mesma maneira que a terminologia habitual em bancos de dados, mas da maneira como é usado em linguagens de marcação para descrição de documentos estruturados. Os atributos fornecem informações que descrevem os elementos. Existem basicamente dois tipos de elementos, os simples, que contêm valores de dados, e os complexos, que são construídos hierar-quicamente a partir de outros elementos, simples ou também complexos.

Tanto a linguagem XML quanto HTML são derivadas da linguagem SGML – Standard Generalized Markup Language –, que é bastante complexa e contém elementos que permitem a estruturação de documentos em diversos aspectos. XML ganha destaque por permitir que o usuário crie suas próprias marcações, também chamada de tags, de maneira que o documento fique estruturado de acordo com as regras definidas para uma aplicação, situação ou simplesmente atenda os requisitos de estruturação definidos pelo usuário.

A definição das tags, que poderão ser utilizadas para estruturar um docu-mento XML, fica armazenada em um arquivo do tipo DTD – Document Type Definition. A partir da estrutura pré-definida em um DTD, podem-se especificar os elementos que estarão contidos no documento XML. Essa definição também pode ser feita utilizando-se uma API – Application Program Interface –, que permite que aplicações possam inserir, excluir e alterar elementos contidos no docu-mento. Essa API é chamada de DOM – Document Object Model.

A partir da definição de uma estrutura para os documentos XML e da criação de tags próprias, podemos considerar que uma nova linguagem de marcação foi criada. Por essa razão, muitos autores chamam a linguagem XML



de metalinguagem. Essa possibilidade faz com que documentos XML se tornem poderosas ferramentas de intercâmbio de dados, já que são facilmente proces-sados e transmitidos no ambiente da Internet (a transmissão é feita utilizando o protocolo HTTP, o mesmo usado para páginas HTML). Ao definir uma estru-tura de documento que seja utilizada como formato para intercâmbio, diversas aplicações com arquiteturas diferentes podem compartilhar dados de maneira eficiente sem que seja necessário refazê-las.

Outra característica marcante da linguagem XML é que a estrutura pode ser definida em um arquivo, enquanto o conteúdo, ou seja, os dados que serão estruturados de acordo com a estrutura definida podem ser armazenados em outro arquivo. Além disso, é importante ressaltar que o conteúdo de um docu-mento XML contém, basicamente, os dados estruturados (geralmente de maneira hierárquica em forma de árvore) e, ao contrário de HTML, não contém informa-ções sobre como os dados devem ser apresentados.

A forma de apresentação dos dados pode ser determinada de várias maneiras. Duas das mais comuns são a utilização de CSS – Cascade Stlyle Sheet – ou Folhas de Estilo em cascata, e XSL – Extensible Stylesheet Language. A definição da forma de apresentação independente do conteúdo e da estru-tura confere à linguagem XML uma flexibilidade muito grande, tornando os documentos facilmente personalizáveis. A Figura a seguir ilustra graficamente a relação entre conteúdo, estrutura e apresentação de um documento XML.

Figura Composição de um documento XML.

Observe que o conteúdo estruturado de acordo com regras pré-definidas dá origem ao documento XML, escrito em uma estrutura hierárquica em árvore. A partir daí já poderíamos utilizar os dados estruturados para uma quantidade muito grande de aplicações. Uma delas seria apresentar ao usuário de um sistema de informações qualquer os dados contidos no documento. Nesse momento, entram em cena as regras de apresentação, que, aplicadas ao documento XML, fazem com que formatações sejam aplicadas às tags definidas quando o documento for apresentado em um browser (navegador web).



7.1.1 XML e bancos de dados

Embora tenha sido exposto que os elementos e atributos em um documento XML não são exatamente iguais aos atributos em bancos de dados, essa asso-ciação pode ser feita sem prejuízos quando estivermos falando de bancos de dados relacionais. Se uma determinada entidade pode ser definida a partir de seus atributos, podemos associar a estrutura de uma tabela em um banco de dados relacionais à estrutura de um documento XML.

Saiba mais

Algumas abordagens têm sido propostas para a organização do conteúdo de documentos XML para facilitar sua subseqüente consulta e recuperação. Segundo Elmasri e Navathe (2005), as abordagens mais comuns são as seguintes:

uso de SGBD para armazenar documentos como texto• : documentos XML podem ser armazenados como atributos (do tipo texto) de registros em bancos de dados relacionais;

uso de um SGBD para armazenar o conteúdo do documento XML como •elemento de dados: essa abordagem funciona para o armazenamento de uma coleção de documentos que seguem um esquema (estrutura) específico XML estabelecida em um DTD. Como todos os documentos têm a mesma estrutura, é possível projetar um banco de dados relacional para armazenar os elementos de dados dentro dos documentos XML. Essa abordagem exigiria um algoritmo de mapeamento para projetar um esquema de banco de dados que seja compatível com a estrutura do documento XML e também para recriar, a partir dos dados armaze-nados, os documentos XML. Esses algoritmos podem ser implementados tanto internamente aos SGBDs quanto como um middleware separado que não faça parte do SGBD;

projeto de um sistema especializado para armazenamento de dados XML •nativos: um novo tipo de sistema de banco de dados baseado no modelo hierárquico poderia ser projetado e implementado. O sistema incluiria técnicas especializadas de indexação e de consultas e funcionaria para todos os tipos de documentos XML. Considerando que documentos XML são basicamente arquivos de texto, poderia incluir técnicas de compressão para reduzir o tamanho dos documentos para armazenamento;



criação ou publicação de documentos XML customizados a partir de •bancos de dados relacionais preexistentes: como existem enormes quan-tidades de dados já armazenados em bancos de dados relacionais, parte desses dados pode precisar ser formatada como documento para troca ou exibição pela web. Essa abordagem usaria uma camada de software middleware separada para tratar as conversões necessárias entre o banco de dados e os documentos XML.


7.2 Segurança em bancos de dados

Segundo Date (2004), geralmente, questões sobre segurança de dados estão associadas à integridade. No entanto são conceitos bem diferentes. Observe a diferença entre eles a seguir.

Segurança• : significa proteger os dados contra usuários não-autorizados;

Integridade• : significa proteger os dados de usuários autorizados.

Nesta parte da aula, o nosso interesse é puramente a segurança. A segu-rança em banco de dados é uma área bastante ampla, que, segundo Elmasri e Navathe (2005), se refere a muitas questões.

Questões legais e éticas referentes ao direito de acesso a certas •informações.

Questões políticas no nível governamental, institucional ou corporativo, •como quais tipos de informações não devem ser tornados disponíveis publicamente.

Questões relacionadas ao sistema, como os níveis de tratamento de •segurança (SGBD, sistema operacional, aplicação, etc.).

Necessidades de algumas organizações em categorizar níveis de segu-•rança e enquadrar os dados nesses níveis.

Quando o assunto é segurança, é comum que se pense também sobre quais os tipos de ameaças queremos nos prevenir. Os objetivos principais da segu-rança em bancos de dados é eliminar ameaças que afetem a integridade, a disponibilidade e a confidencialidade dos dados. Para proteger os bancos de



dados contra os diversos tipos de ameaças, algumas medidas podem ser imple-mentadas, como:

controle de acesso•controle de inferência•controle de fluxo•criptografia•

Uma das maneiras de garantir o controle de acesso é definir contas para os usuários. Geralmente o DBA – Data Base Administrator – possui uma conta de sistema, ou conta de superusuário, que habilita capacidades que não estão disponíveis para os usuários comuns de um banco de dados. Entre essas capaci-dades estão: criação de contas, concessão de privilégios, revogação de privilé-gios e atribuição de nível de segurança.

Para melhorar o esquema de segurança, somente devem ter uma conta de acesso usuários que tenham uma necessidade legítima de acessar o banco de dados. O sistema de banco de dados também deve manter informação de todas as operações que são aplicadas por um usuário durante cada sessão de conexão, que consiste em uma seqüência de interações que um usuário realiza desde o momento de conexão (login) até o momento de desconexão (logoff). Essas informações, asso-ciando também o terminal a partir do qual os comandos foram enviados, podem ser armazenadas em um log de acesso do sistema (ELMASRI; NAVATHE, 2005).

Podemos destacar dois tipos principais de controle de acesso: o discrimina-tório e o mandatário.

Segundo Date (2004), no caso do controle de acesso discriminatório, deter-minado usuário terá, em geral, direitos de acesso (também chamados de privilé-gios) diferentes sobre objetos diferentes. Além disso, há bem poucas limitações inerentes a respeito de quais usuários podem ter privilégios diferentes sobre diferentes objetos (por exemplo, um usuário A tem direitos sobre um objeto X, mas não sobre Y, enquanto um usuário B tem direitos sobre Y, mas não sobre X), tornando esse modelo bastante flexível.

No caso do controle mandatário, cada objeto de dados é assinalado com certo nível de classificação e cada usuário recebe certo nível de liberação. O acesso a um determinado objeto de dados só pode ser feito por usuários com a liberação apropriada. Os esquemas mandatários tendem, assim, a ser hierár-quicos por natureza, e, desse modo, comparativamente rígidos. Outra ferramenta que pode ser usada para segurança em bancos de dados é a criptografia.

7.2.1 Criptografia

A criptografia é um recurso de segurança muito útil quando os dados se encontram nas mãos de usuários ilegítimos, possivelmente por um erro no canal de comunicação entre computadores (rede) ou mesmo aproveitando de uma



vulnerabilidade em um aplicativo ou na própria transmissão de dados. Nesse caso, o uso de criptografia permite que os dados sejam protegidos, já que, mesmo de posse das informações presentes no banco de dados, elas não estão escritas de forma inteligível.

A criptografia consiste em aplicar um algoritmo de criptografia a um conjunto de dados escritos em texto puro (não criptografado) usando uma chave de criptografia transfor-

mando esse texto puro em um texto cifrado (criptografado).

O algoritmo de criptografia em si não necessita ser secreto, porém a chave usada para criptografar e descriptografar os dados deve ser de posse única de usuários que tenham real necessidade de acesso a esses dados. Em bancos de dados, a utilização de criptografia aumenta a segurança dos dados se eles forem armazenados e transmitidos na forma de texto cifrado, pois, ao serem acessados indevidamente, transportados fisicamente, ou interceptados em uma comunicação, estarão seguros.

Existem diversas técnicas de criptografia, algumas delas são baseadas em substi-tuição, outras em permutação de caracteres em um texto puro. Outros ainda utilizam essas duas técnicas combinadas, como o DES – Data Encryption Standard –, que foi desenvolvido pela IBM e adotado como padrão federal dos Estados Unidos em 1977 (DATE, 2004). Para usar o DES, o texto comum é dividido em blocos de 64 bits e cada bloco é criptografado com o uso de uma chave de 64 bits.

Na medida em que computadores se tornaram mais rápidos e precisos, as chaves de 64 bits usadas no DES foram se tornando relativamente pequenas, já que ataques de força bruta (testar todas as combinações possíveis) se tornaram viáveis em algumas situações. Assim outros padrões ganharam força, como o AES – Advanced Encryption Standard –, que utiliza chaves de 128, 192 e 256 bits, muito mais seguras.

Existe ainda o modelo de criptografia de chave pública. Os algoritmos de chave pública são baseados em operações matemáticas, em vez de operações sobre bits. Além disso, diferem da então criptografia tradicional por utilizarem duas chaves ao invés de uma só. As duas chaves são chamadas de pública e privada. A privada é sempre mantida em segredo (ELMASRI; NAVATHE, 2005).

Como sugerido no nome desse modelo, a chave pública é tornada pública para outros usarem, ao passo que a privada é conhecida apenas por seu proprie-tário. Um algoritmo de criptografia de chave pública genérica se baseia em uma chave para cifrar e outra chave diferente, porém relacionada, para decifrar, de acordo com os seguintes passos:

cada usuário gera seu par de chaves para cifrar e decifrar os dados;•



cada usuário coloca uma das duas chaves em um registro público ou em •outro arquivo acessível (essa é a chave pública). A outra chave que a acompanha é mantida secreta;

se um remetente deseja enviar uma mensagem privada para um desti-•natário, o remetente cifra a mensagem utilizando a chave pública do destinatário;

quando o destinatário receber a mensagem, decifra a mensagem utili-•zando a chave privada do destinatário. Nenhum outro receptor pode decifrar a mensagem, já que somente o destinatário conhece a sua própria chave privada.

Saiba mais

Portanto os conceitos de segurança em bancos de dados são muito impor-tantes, já que aspectos como a confidencialidade são requisitos para um banco de dados confiável. Considerando que existem muitos sistemas baseados na web, aspectos de segurança ficam ainda mais em evidência e devem poder ser aplicados às novas tecnologias, como XML.

Nesta aula, apresentamos os conceitos fundamentais da linguagem XML e algumas das possibilidades de utilizá-la como uma ferramenta para a área de bancos de dados. Essa tecnologia pode ser usada tanto como formato para inter-câmbio na troca de informações, quanto formato para armazenamento ou ainda como padrão para apresentação dos dados ao usuário. Outro tópico abordado foi a segurança em bancos de dados, que muitas vezes não é percebida pelo usuário. Apresentamos os métodos baseados em controle de acesso e também conceitos de criptografia.

1. Sobre XML, assinale a alternativa incorreta.

a) Pelo fato da transferência de dados em XML ser feita utilizando o mesmo protocolo que HTML, o protocolo HTTP, é muito difícil para os sistemas de bancos de dados decodificar as informações.

b) XML, assim como HTML, é uma linguagem de marcação.

c) As marcações de um documento XML podem ser definidas em um docu-mento chamado DTD e podem também refletir o domínio da aplicação em questão.

d) A formatação dos dados contidos em um arquivo XML pode ser definida em outro arquivo, por exemplo, do tipo CSS.

2. A segurança em bancos de dados é um dos aspectos mais importantes. Sobre segurança, assinale a alternativa correta.

a) A segurança em um banco de dados é implementada diretamente e somente na aplicação que interage como banco de dados.

b) A única forma de implementar segurança em um banco de dados é por meio do controle de acesso efetuado no SGBD.

c) A criptografia de chave pública é uma maneira de proteger os dados mesmo que eles caiam nas mãos de pessoas não autorizadas.

d) Segurança em bancos de dados é um sonho impossível, já que os dados sempre são armazenados na sua forma definitiva e qualquer um que os acessar pode decifrá-los sem problema algum.

3. A separação entre estrutura, conteúdo e formatação é uma caracterís-tica marcante da linguagem XML. Como isso poderia se traduzir em uma vantagem no contexto de bancos de dados?

4. Foi comentado anteriormente que existem diversas técnicas de segurança para a área de bancos de dados. Essas técnicas devem ser utilizadas sepa-radamente, ou podemos implementar um “pacote” de segurança contendo diversas técnicas?

Considerando os objetivos da aula, que estão relacionados aos temas XML e segurança em banco de dados, vamos comentar as questões propostas nas atividades para verificar se você os atingiu.

Na atividade um, a alternativa (a) está incorreta, já que o fato de dados em XML serem transmitidos utilizando o protocolo HTTP representa uma das vantagens desse padrão, pois uma série de problemas de transmissão de dados já está resolvida. Aliás, essa é uma das razões de XML estar se tornando um padrão cada vez mais em uso. A alternativa (b) é correta, pois como já foi exposto, a linguagem XML é uma linguagem de marcação, assim como HTML, e a construção dos documentos é baseada na utilização de tags. A alternativa (c) expressa corretamente uma possibilidade de separação da



b) XML, assim como HTML, é uma linguagem de marcação.

c) As marcações de um documento XML podem ser definidas em um docu-mento chamado DTD e podem também refletir o domínio da aplicação em questão.

d) A formatação dos dados contidos em um arquivo XML pode ser definida em outro arquivo, por exemplo, do tipo CSS.

2. A segurança em bancos de dados é um dos aspectos mais importantes. Sobre segurança, assinale a alternativa correta.

a) A segurança em um banco de dados é implementada diretamente e somente na aplicação que interage como banco de dados.

b) A única forma de implementar segurança em um banco de dados é por meio do controle de acesso efetuado no SGBD.

c) A criptografia de chave pública é uma maneira de proteger os dados mesmo que eles caiam nas mãos de pessoas não autorizadas.

d) Segurança em bancos de dados é um sonho impossível, já que os dados sempre são armazenados na sua forma definitiva e qualquer um que os acessar pode decifrá-los sem problema algum.

3. A separação entre estrutura, conteúdo e formatação é uma caracterís-tica marcante da linguagem XML. Como isso poderia se traduzir em uma vantagem no contexto de bancos de dados?

4. Foi comentado anteriormente que existem diversas técnicas de segurança para a área de bancos de dados. Essas técnicas devem ser utilizadas sepa-radamente, ou podemos implementar um “pacote” de segurança contendo diversas técnicas?

Considerando os objetivos da aula, que estão relacionados aos temas XML e segurança em banco de dados, vamos comentar as questões propostas nas atividades para verificar se você os atingiu.

Na atividade um, a alternativa (a) está incorreta, já que o fato de dados em XML serem transmitidos utilizando o protocolo HTTP representa uma das vantagens desse padrão, pois uma série de problemas de transmissão de dados já está resolvida. Aliás, essa é uma das razões de XML estar se tornando um padrão cada vez mais em uso. A alternativa (b) é correta, pois como já foi exposto, a linguagem XML é uma linguagem de marcação, assim como HTML, e a construção dos documentos é baseada na utilização de tags. A alternativa (c) expressa corretamente uma possibilidade de separação da



definição da estrutura do documento e do preenchimento do seu conteúdo. A alternativa (d) apresenta outra característica da linguagem XML, que é a possibilidade de definir a formatação de cada tipo de marcação em um arquivo separado.

Na atividade dois, a alternativa (a) é incorreta, pois a implementação da segurança em bancos de dados pode ser feita em diversos níveis, de aplicação, SGBD, etc., e não somente nas aplicações. A alternativa (b) é incorreta, pois o controle de acesso é uma das formas de garantir a segu-rança dos dados, porém não é a única. A alternativa (c) é a resposta correta, já que dados criptografados com a tecnologia de chaves públicas somente podem ser decifrados com a utilização de uma chave provada, que somente um proprietário possui. Dessa maneira, outras pessoas não podem acessar indevidamente os dados. A segurança da informação é um aspecto chave na sociedade atual. Muitos esforços têm sido realizados nesse sentido, porém, ainda existem muitas vulnerabilidades a serem solucionadas. Entretanto há ambientes seguros para a troca de informações, por isso não podemos consi-derar a segurança um sonho, já que em muitos sistemas a dificuldade em burlar os mecanismos de segurança seria muito grande. Diante do exposto, a alternativa (d) é falsa.

A atividade três chamou você para refletir sobre uma das principais caracte-rísticas da linguagem XML, que é a separação entre conteúdo, estrutura e apresen-tação. No contexto de bancos de dados, podemos utilizar essas características de diversas formas diferentes. Uma delas seria a possibilidade de armazenar grandes quantidades de documentos XML sem a necessidade de armazenar, em conjunto, os aspectos de formatação de cada um, já que um único esquema de formatação pode ser definido em separado e aplicado a todos os documentos armazenados. Outra possibilidade seria personalizar a apresentação dos dados para diferentes categorias de usuários, ou ainda, validar, baseando-se em uma estrutura pré-definida, os dados contidos em um documento antes de armaze-ná-los no banco de dados.

Na atividade quatro, você afirmou que a segurança de um sistema de banco de dados tem vários níveis, por exemplo, os usuários, a aplicação, o SGBD e os próprios dados. Algumas técnicas de segurança, como o controle de acesso, atuam em apenas uma dessas camadas, sozinha não é o suficiente para garantir a segurança das informações. A junção de técnicas soa como uma solução mais completa e eficaz, já que, se uma barreira for vencida, ainda restarão outros mecanismos para impedir que os dados sejam prejudicados ou acessados indevidamente. Por exemplo, efetuar o controle de acesso com senhas criptografadas ou, ainda, criptografar as definições de permissão para os diferentes usuários dificultam um possível ataque utilizando informações sobre um determinado usuário.









Anotações

63808532 banco de dados ii

Documents