• Nenhum resultado encontrado

Banco de Dados II

N/A
N/A
Protected

Academic year: 2021

Share "Banco de Dados II"

Copied!
84
0
0

Texto

(1)
(2)
(3)

Revisão

Revisão Lingüístico-TLingüístico-Textualextual Silvéria Aparecida BasniaK SchierSilvéria Aparecida BasniaK Schier

Gerente de Divisão de Material Impresso

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

Revisão Digital

Revisão Digital Helena Costa e Lima PrestesHelena Costa e Lima Prestes

Projeto Gráfco

Projeto Gráfco Irenides TeixeiraIrenides Teixeira Katia Gomes da Silva Katia Gomes da Silva

Ilustração

Ilustração Geuvar S. de OliveiraGeuvar S. de Oliveira

Capas

Capas Igor Flávio SouzaIgor Flávio Souza

EQUIPE EADCON EQUIPE EADCON Coordenador Editorial

Coordenador Editorial William Marlos da CostaWilliam Marlos da Costa

 Assistentes de Edição

 Assistentes de Edição Ana Aparecida Teixeira da CruzAna Aparecida Teixeira da Cruz  Janaina Helena Nogueira Bartkiw  Janaina Helena Nogueira Bartkiw

Lisiane Marcele dos Santos Lisiane Marcele dos Santos

Programação Visual e Diagramação

Programação Visual e Diagramação Denise Pires PierinDenise Pires Pierin

Kátia Cristina Oliveira dos Santos Kátia Cristina Oliveira dos Santos Monica Ardjomand Monica Ardjomand Rodrigo Santos Rodrigo Santos Sandro Niemicz Sandro Niemicz

William Marlos da Costa William Marlos da Costa

(4)

plina anterior. As discussões agora são voltadas para aspectos de projeto de 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 bancos de dados relacionais. Os bancos de dados relacionais são os mais utilizados no mercado e, por essa

utilizados no mercado e, por essa razão, seu estudo é essencial.razão, seu estudo é essencial. Considerando que grande parte dos sistemas de i

Considerando que grande parte dos sistemas de inormação e aplicativosnormação e aplicativos em geral manipulam dados e inormações que cam armazenadas em geral manipulam dados e inormações que cam armazenadas perma-nentemente, o projeto de bancos de dados relacionais se torna uma

nentemente, o projeto de bancos de dados relacionais se torna uma área deárea de grande importância.

grande importância.

O conteúdo deste caderno permite a você

O conteúdo deste caderno permite a você ter uma visão geral a ter uma visão geral a respeitorespeito de diversos conceitos para o projeto de bancos de dados. Esses conceitos de diversos conceitos para o projeto de bancos de dados. Esses conceitos permeiam as ases de denições conceituais e revisão, também questões de permeiam as ases de denições conceituais e revisão, também questões de implantação e de manutenção da conabilidade, consistência e implantação e de manutenção da conabilidade, consistência e disponibili-dade do banco de dados. Além disso, permite auxiliar o uturo analista de dade do banco de dados. Além disso, permite auxiliar o uturo analista de sistemas na tomada de decisões a respeito de quais tecnologias utili

sistemas na tomada de decisões a respeito de quais tecnologias utilizar parazar para tirar o máximo de proveito dos

tirar o máximo de proveito dos recursos computacionais disponíveis.recursos computacionais disponíveis. Bons estudos!

Bons estudos!

Pro. Carlos Henrique Corrêa Tolentino Pro. Carlos Henrique Corrêa Tolentino

(5)

rência. Sistemas de recuperação. Banco de

rência. Sistemas de recuperação. Banco de dados distribuídos.dados distribuídos.

OBJETIVOS OBJETIVOS

Apresentar conceitos comumente encontrados na literatura e no Apresentar conceitos comumente encontrados na literatura e no

• •

mercado na área de bancos de dados. mercado na área de bancos de dados.

Oerecer uma base para a tomada de decisões em relação a Oerecer uma base para a tomada de decisões em relação a

• •

como proceder na atividade de projetar um banco de dados como proceder na atividade de projetar um banco de dados relacional.

relacional.

CONTEÚDO PROGRAMÁTICO CONTEÚDO PROGRAMÁTICO

Conceitos de projetos de bancos de dados relacionais Conceitos de projetos de bancos de dados relacionais

• • Dependências uncionais Dependências uncionais • • Normalização Normalização • • Transa

Transações e controle ções e controle de concorrênciade concorrência

• •

Classicação de alhas e si

Classicação de alhas e sistemas de recuperaçãostemas de recuperação

• •

Bancos de dados distribuídos e

Bancos de dados distribuídos e outras tecnologias emergentesoutras tecnologias emergentes

• •

(6)

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

(7)
(8)

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

compreender os conceitos de dependência uncional 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 oram vistos na disciplina de Bancos de Dados do segundo período e são importantes para a compreensão da dependência uncional e da normalização.

Atualmente, muitos sotwares que compõem os sistemas de inormação

podem ser considerados apenas uma interace entre os usuários e os dados armazenados. Esse raciocínio é ilustrado na gura 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 unções, a responsabilidade de gerenciar o acesso dos aplicativos às bases de dados por ele gerenciadas.

Dependência funcional e

normalização

(9)

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 inormações (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). A qualidade de um projeto é tão importante quanto a qualidade dos sotwares que azem a interace 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 uncional e a normalização de dados, que é o

oco de estudo desta aula.

1.1 Dependência funcional

A dependência uncional pode ser denida como uma restrição entre dois conjuntos de atributos de uma mesma entidade/relação (ALVES, 2004). Essa denição pode ser eita sob uma linguagem mais precisa. Elmasri e Navathe (2005) armam que uma dependência uncional, denotada por X→Y entre dois

conjuntos de atributos (que são subconjuntos) de uma relação R especicam uma restrição nas possíveis tuplas que ormem 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 signica 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 uncionalmente) os valores de Y. A partir do exposto, dizemos que Y é uncionalmente dependente de X. O conceito de dependência uncional é explicado e exemplicado 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 gura a seguir.

(10)

Se considerarmos X como sendo o conjunto ormado 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 ormado 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 inor-mações sobre o aluno.

As guras a seguir ilustram outras possibilidades de dependência uncional dentro da mesma relação.

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

Figura 4 Outras possibilidades de dependência uncional: 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.

(11)

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 guras anteriores, a Figura 5 ilustra uma dependência uncional total.

Figura 5 Exemplo de dependência uncional total.

Observe que, dierentemente 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 ez 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 uncional 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 é uncionalmente dependente de um atributo que não az 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 oi adicionado o atributo status, usado para indicar se o aluno

(12)

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

1.1.1 Redundância e anomalias

De acordo com as dependências uncionais 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 inormaçõ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,

liação, etc. Dessa maneira, ao inserir inormações como nome_aluno, estamos duplicando desnecessariamente uma inormação.

Uma solução aparente para esse problema seria unifcar as relações, de

maneira que as inormações adicionais da entidade Aluno sejam presentes na relação apresentada nas guras 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 inormações duplicadas.

Complementando, podemos armar 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 eitas em inormações duplicadas devem ser propagadas para cada registro que contiver aquelas inormaçõ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 uncionais 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 denição de um modelo de dados,

(13)

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

Abordagem

• bottom-up : consiste em aplicar a normalização como

erra-menta de projeto do modelo de dados, para que, inicialmente já se construa um modelo de dados normalizado.

Segundo Alves (2004), a orma normal de uma relação indica o grau de normalização no qual a relação se encontra. Academicamente alando, existem cinco ormas normais, embora apenas as três primeiras já sejam sucientes para termos uma boa denição da estrutura do banco de dados. No m 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-upou top-down), esperamos obter um banco de dados com as seguintes

características: robustez

•

eciência

•

acilidade de manutenção e alteração

•

fexibilidade

•

conabilidade

•

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

1.2.1 A primeira forma normal

Existem muitos bancos de dados que armazenam inormações multivalo-radas. Essas inormações são passíveis de decomposição. Uma inormação que

não pode, ou não precisa ser decomposta é chamada de inormação atômica.

Segundo Silberchartz, Korth e Sudarshan (2006), dizemos que uma relação R se encontra na primeira orma 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, one, endereço e data_nasc. Todos nós sabemos que o endereço é composto por outras inorma-ções, como cidade, estado, CEP, bairro, rua, número e complemento. Dessa maneira não é diícil perceber que existe nessa relação um atributo multivalo-rado. Para adequar essa relação à primeira orma normal, poderíamos rená-la para a orma sugerida na gura a seguir.

(14)

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 orma normal é baseada no conceito de dependência uncional total. Alves (2004) complementa armando

que colocar as entidades na segunda orma normal é um pouco mais diícil que na primeira. Uma entidade se encontra na segunda orma normal se, além de estar na primeira, todos os seus atributos são totalmente dependentes da chave

(15)

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

A remoção dos atributos parcialmente dependentes não signica propria-mente que essas inormaçõ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 orma 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 inormações para outra relação, como apresentado na solução a seguir, ilustrada na Figura 10.

Figura 10 Resultado da aplicação da segunda orma normal.

Analisando esse novo diagrama, percebemos que a adequação à segunda orma normal oi eetuada sem a perda da capacidade de recuperação das inormaçõ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.

(16)

1.2.3 A terceira forma normal

Elmasri e Navathe (2005) também descrevem a terceira orma normal. Uma relação se encontra na terceira orma 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 aça parte da chave primária. Um exemplo de dependência transitiva já oi 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

orma normal. Uma possível solução para o problema seria o que está exposto na gura a seguir.

Figura 11 Resultado da aplicação da terceira orma 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 oi aprovado em uma disci-plina vericando 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 identicação das dependências uncionais 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

•

eciência

•

acilidade de manutenção e alteração

•

fexibilidade

•

conabilidade

•

Portanto, a partir do que analisamos nesta aula, percebemos que ignorar dependências uncionais 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 (abordagembottom-up) ou mesmo um banco de dados já em operação

(17)

Nesta aula, estudamos conceitos muito importantes para o projeto de bancos de dados relacionais: dependência uncional e normalização. Uma dependência uncional é 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 uncionais 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 identicação dos tipos de dependências uncionais (parcial, total e transitiva), além da correta aplicação da normalização (primeira, segunda e terceira ormas normais) são importantes para que tenhamos em mãos um bom projeto de banco de dados.

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

a) Pode existir dependência uncional entre atributos de entidades dierentes.

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

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

d) A redundância de dados causada por alguns tipos de dependências uncionais, 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 armar que:

a) a segunda orma normal diz respeito às dependências uncionais parciais;

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

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

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

(18)

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

Que tal conerir 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 denição de dependência uncional, um conjunto de atributos de uma relação R é uncionalmente 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 ala de

redun-dância e anomalias, uma dependência uncional 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 abordagemtop-down é aplicada

sobre um modelo conceitual já denido. 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 denido.

Naatividade três, a alternativa incorreta é a letra(c), que compara a primeira

e a segunda orma normal, entretanto, cita-as de maneira errônea, já que a primeira orma normal trata de atributos multivalorados e não de dependência uncional, enquanto que a segunda orma normal trata somente das dependên-cias uncionais parciais.

Na atividade quatro, você apontou os problemas que podem surgir se não

observarmos as ormas normais: redundância e os dierentes tipos de anomalias, por exemplo, anomalias de inserção que nos orçam a inserir inormações dupli-cadas e, além disso, obrigam a um esorço maior nas exclusões que devem ser propagadas.

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

ELMASRI, Ramez E.; NAVATHE, Shamkant B. Sistemas de banco de dados. São

(19)

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

São Paulo: Érica, 1996.

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

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

(20)

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

compreender a maneira como os bancos de dados são armazenados

•

em arquivos;

compreender a orma 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 oram 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 ato de estarem relacionados com os conceitos de armazenamento, indexação e hashing, oco 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 az 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 orma como os dados estão estruturados infuencia diretamente no desempenho de um sistema de banco de dados. Existem diversas técnicas de armazenamento. Elas apresentam

(21)

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 az parte do projeto í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 denitivo. 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 inormações relacionadas, no qual cada uma das inormaçõ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 eita, simplesmente, ao nal do arquivo. Nesse tipo de organização, a operação de inserção é muito eciente, já que pode ser eita 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 nal do arquivo para só então descobrir que a inormaçã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 de-nido por um campo do registro, podemos implementar a busca binária.

(22)

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 regisregis-tros devem perma-necer ordenados sicamente. 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 à rente para que o novo registro seja alocado no arquivo. Assim podemos perceber que essa orma de armazenamento é eciente, mas pode resultar no aparecimento dos mesmos problemas do armazenamento não ordenado.

Uma possibilidade de minimizar esses problemas é usar um arquivo de

overow . Segundo essa técnica, os novos registros são inseridos em outro

arquivo e, nesse arquivo adicional, a leitura e a escrita são eitas de maneira linear. Em intervalos de tempo periódicos (possivelmente nos horários de menor acesso ao banco de dados), eetuam a inserção dos registros do arquivo de

overfow 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 or 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 unção de espalhamento. Essa unção irá, a partir do

campo escolhido, determinar em qual bloco esse registro deve ser armazenado. Essa mesma unção de espalhamento pode ser usada na busca por um registro. A eciência dessa técnica reside no ato de que a busca será baseada em uma unçã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 , enda ou bloco) é usada para armazenar um

registro. Nesse caso, a unçã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 transormar o campo de hash em um

valor inteiro M e aplicar a unção (M) = M mod N, onde N é a quantidade

de endas disponíveis e mod é um operador que retorna o resto da divisão do

(23)

Devemos considerar que existe a possibilidade de que dois valores dierentes de entrada para a unçã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 or determinado o bloco no qual se encontra o registro, usando a unção de espalhamento, inicia-se uma busca linear, degenerando o desempenho da estrutura de hash.

Uma unção de espalhamento considerada ótima é a que nunca retorna valores idênticos para valores de entrada dierentes. Porém essa situação é inviável, já que seria necessário ter tantas posições no vetor quantos registros para armazenamento. Uma unção de espalhamento pode ser considerada boa quando chega próximo do chamado espalhamento uniorme, no qual os

regis-tros cam distribuídos de maneira equilibrada nos diversos blocos disponíveis. Um espalhamento é dito uniorme quando a dierenç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 unçã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 unciona quase da mesma orma que o índice remissivode um livro. Se quisermos procurar

por um termo em particular, vamos ao nal do livro, procuramos esse termo, e descobriremos a página que o contém. Podemos, então, ir à página e buscar as inormações desejadas (SILBERCHARTZ; KORTH; SUDARSHAN, 2006).

A utilização de um índice remissivo somente é útil se ele estiver ordenado, dimi-nuindo o esorç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 dene 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.

(24)

O aspecto que descreve a vantagem de utilizar índices reside no ato 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 reerenciado por um índice dierente. 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 é dierente da ordem dos registros correspondentes. A associação é eita 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á armado ante-riormente, podem existir diversos campos de indexação para um mesmo registro, como ilustra a Figura 2 a seguir.

(25)

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 deniçã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_ornecedor, como chave primária de tabelas. Isso pode ser justicado pela acilidade dos sistemas computacionais em processar dados numéricos. Entretanto, em uma tabela de ornecedores, campos que constantemente são utilizados como chave para buscas pelos usuários, como o CNPJ, não devem ser duplicados. A deniçã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 inorma-ções e, ao mesmo, tempo ornece um mecanismo eciente 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 orem pequenos, alguns SGBDs ornecem a opção de utilizar a estrutura de dados árvore B como orma

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 signica Redundant Arrays o  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 dierentes 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 caram muito mais rápidos, e os discos magnéticos para 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 deasada 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.

(26)

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 azê-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 eitas em paralelo, ornecendo, assim, altas taxas de transerência globais (ELMASRI; NAVATHE, 2005).

Portanto a utilização de uma técnica de armazenamento e a recuperação de inormações adequada pode se tornar o dierencial de um determinado banco de dados em relação a outros. Aspectos como a quantidade de inormações de um banco de dados, os dispositivos ísicos de armazenamento disponíveis e os recursos de sotware 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 ormas de armazenamento eletrônico de dados, por exemplo, os arquivos de registros desordenados e os

arquivos de registros ordenados. Além disso, apresentamos algumastecnologias 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 infuenciam aspectos como a eciência e desempenho.

1. Considerando que a utilização de arquivos de registros ordenados é uma técnica que tem seu potencial undamentado na busca binária dos registros, ordenados de acordo com um dos campos dos registros, verifcamos que há uma limitação nessa técnica quando pesquisas são eitas 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 undamentado na rapidez para

determinar o local de armazenamento de um registro. Entretanto dois regis-tros dierentes podem ser mapeados para um mesmo bloco de regisregis-tros, o que chamamos de colisão. Uma das ormas de tratamento de colisões é a utilização do encadeamento. Porém, dentro de um grupo de registros que oram mapeados para o mesmo bloco, implementa-se a busca seqüencial, o que az com que se perca grande parte da perormance. O que poderia ser eito para manter o alto desempenho?

(27)

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 inormaçõ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 armar que:

a) de acordo com a tecnologia RAID, um único disco de grande capaci-dade é ragmentado logicamente em diversas unicapaci-dades.

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 unçã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 orma de acesso aos arquivos que compõem um banco de dados. Será que eles oram atingidos? Vamos conerir!

Na atividade umvocê 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 regisregis-tros, além da busca binária ser reém de um único critério, que é justamente o campo que oi 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.

(28)

Na atividade dois, você considerou que o encadeamento az 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 eetuar 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 eciente) para uma determinada entidade em um sistema de banco de dados.

Na atividade quatro, a alternativa correta é (b). A alternativa (a) é incorreta

pelo ato de que a tecnologia RAID prevê a utilização de vários discos ísicos, agindo como um disco lógico, e não o contrário, como armado. A alternativa(c)

está errada, já que uma unçã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 inormações. Finalmente, a alternativa (d) também está incorreta pelo ato de

que existem meios de lidar com as colisões em uma tabela de espalhamento.

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

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.

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 eciente às operações eetuadas 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á!

(29)
(30)

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

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 é undamental 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 oram 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-erê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 artií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 Denindo transações

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

(31)

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 é transormar 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 inormar ao sistema quando dierentes operações azem 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 orma, podemos perceber que uma transação é ormada 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;

(32)

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 transerência bancária. Em meio a um processo de transerência de valor entre contas, temos alguns comandos SQL que são executados todos de uma vez, ormando 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 transerência, utilizaremos somente o UPDATE.

Digamos que nossa agência tenha dois correntistas, A e B e, em um belo

dia, A resolve azer uma transerência de R$ 50,00 para B. Essa transação será

eita 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 conerência por parte do SGBD – tudo correu bem –, então a transação é nalizada 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 armar que as transações desempenham um papel importante em um SGBD uma vez que:

uncionam como um mecanismo que garante que toda transação iniciada

•

termina com sucesso ou é deseita;

transações de dierentes 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 alha.

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 qualicada como uma tran-sação. Vejamos agora, segundo Date (2004), o que signica cada uma delas.

3.3.1 Atomicidade

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

(33)

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 alhar 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 alhar, ela deve deixar o banco de dados em um estado consistente. Se uma transação alhar, ela precisa desazer 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 m, ou seja, modicatransa-ções eitas por transatransa-ções simultâneas devem ser isoladas das modicações eitas por qualquer outra transação simul-tânea. Uma transação que debita uma conta e credita outra deve ser totalmente transparente. Quando isso é eito, 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á sorendo uma transação, o banco de dados só deve retornar o valor do saldo depois que completar a atualização. Dessa orma, durante a transação algumas linhas são bloqueadas.

3.3.4 Durabilidade

Depois que uma transação tiver sido concluída, seus eeitos cam 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 alhas uturas. As modicações persistem até mesmo no caso de uma queda do sistema. Se todas as ações orem realizadas com sucesso, não signica que houve sucesso na transação, pois ela precisa gravar os dados de volta ao disco. Caso ocorra uma alha no disco, a transação não é válida. Então antes que uma transação seja completada deve vericar se as alterações oram 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á ez? Concluiu suas operações? Deve abortar? São algumas perguntas que o SGBD realiza para gerenciar os estados de uma transação.

(34)

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

Uma transação pode se encontrar em dierentes estados. O grao apresen-tado na Figura 3 ilustra as possibilidades de transição de esapresen-tados.

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 eetivaçã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 eetivadas com sucesso (não soram alhas);

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 eetivação. Suas ações já realizadas devem ser deseitas (ROLLBACK);

eetivada

• : entra nesse estado após o SGBD conrmar que todas as

modi-caçõ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 buers em disco, entre outros;

concluída

• : estado nal de uma transação, ele indica uma transação que

deixa o sistema. As inormações das transações mantidas em catálogo podem ser excluídas (operações eitas, dados manipulados, buers

utilizados, entre outros). Caso a transação não tenha sido concluída com sucesso, ela pode ser reiniciada automaticamente.

(35)

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 coná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 é transormar 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 deseita. As transações também controlam melhor a concorrência de operações e a reconstrução dos dados em caso de alha. Transações de dierentes usuários que envolvem dados compartilhados são executadas em seqüência.

Compreendeu também que, para ser qualicada 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 grao de transição de estados. Finalmente, viu que os estados de uma transação podem ser: ativa, em processo

de eetivação, eetivada, em processo de aborto e concluída.

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

2. Leia e analise atentamente as seguintes armativas 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 eetivadas com sucesso em um banco de dados ou nenhuma delas se eetiva. Isso é realizado para preservar a integri-dade do banco de dados.

II. A propriedade de isolamento dene que cada transação deve ser isolada dos eeitos da execução concorrente de outras transações.

III. A propriedade que dene que toda transação que or nalizada de orma bem-sucedida deve persistir seus resultados em banco mesmo na presença de alhas no sistema é a propriedade de consistência.

(36)

Assinale a alternativa correta.

a) Somente a armativa I está incorreta.

b) Somente as armativas I e II estão corretas. c) Somente as armativas II e III estão incorretas. d) Todas as armativas estão corretas.

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

4. Leia atentamente as armativas 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 conrma que todas as modica-ções da transação estão garantidas no banco de dados.

III. Eetivada é o estado nal 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.

Assinale a alternativa correta.

a) As armativas II e III estão incorretas. b) As armativas I e III estão incorretas. c) Somente a armativa IV está correta. d) As armativas I e IV estão incorretas.

Na atividade um, você armou que uma transação é a unidade lógica de

trabalho, constituída de um conjunto de operações. Seu objetivo é transormar 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 oi

essa, parabéns, você atingiu nosso objetivo de entender as propriedades de uma transação e seus estados. A armativa (III) está incorreta, pois a propriedade de

(37)

consistência dene que cada transação executada isoladamente deve preservar a consistência do banco de dados, e a propriedade de durabilidade dene que toda transação que or nalizada de orma bem-sucedida deve persistir seus resultados em banco mesmo na presença de alhas 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 deseita. 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 orma, sugiro que você volte ao conteúdo desta aula e reveja atentamente a deniçã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 armativas (II) e (III) estão incorretas, pois o estado eetivado é o estado em que o SGBD conrma que todas as modi-cações da transação estão garantidas no banco de dados, e concluída é o estado nal 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 dierente, 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.

ELMASRI, Ramez E.; NAVATHE, Shamkant B. Sistemas de banco de dados. São

Paulo: Pearson Prentice Hall, 2005.

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 eetuada no mesmo instante em um banco de dados. Até lá!

(38)

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

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

•

identicar 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 oram 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 interram uma nas outras. Assim serão consideradas, nesta aula, os prin-cipais problemas de concorrência, além das prinprin-cipais 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

(39)

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 • commit  aná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 nalizando, 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 ato 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.

(40)

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

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.

(41)

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 supercial, é semelhante ao problema apresentado na seção anterior, já que resulta na leitura inconsis-tente de valores por uma transação. A dierenç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 nalizadas usando o comando commit . Para exemplicar 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.

TRANSAçãO A TEMPO TRANSAçãO B

– | – ler conta1(40) soma = 40 T1 – ler conta2 (50) soma = 90 T2 – – T3 altera conta3 30 → 20 altera conta1 40 → 50 commit ler conta3 (20) soma = 110 T4 – – ↓ Fonte: Date (2003, p. 401).

É importante observar que o resultado nal da soma realizada na tran-sação A é 110, enquanto o resultado correto seria 120. Esse problema se deve ao ato 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 nalizada 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 oi alterado no tempo T3 pela transação B, causando o problema de inconsistência no valor nal 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 nal.

(42)

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 classicadas em técnicas pessimistas e otimistas. Elmasri e Navathe (2005) citam a seguinte classicação:

a) pessimista

bloqueio

•

• timestamp (marcas de tempo) b) otimista

validação

•

As técnicas pessimistas presumem que sempre ocorrerá intererê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 intere-rência entre as transações e somente verifcam o aspecto da serialização ao fnal.

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 tarea. Logo o que ocorre em todos os protocolos nada mais é que uma deniçã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 diundidos 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êsShare ) sobre um dado, então poderá ler, mas

Referências

Documentos relacionados

seria usada para o parafuso M6, foram utilizadas as equações 14 e 15, referentes aos parafusos de 8 mm de diâmetro e folga entre parafuso e furo de 0,5 mm, que definem,

No entanto, os resultados apresentados pelo --linalol não foram semelhantes, em parte, aos do linalol racêmico, uma vez que este apresenta um efeito vasorelaxante em anéis de

Resumo: O presente trabalho corresponde a um estudo empírico descritivo e exploratório que aborda comportamentos e falas de atores políticos que participaram do processo legislativo

O registro de dados na plataforma de trabalho do operador temperatura do ar, °C; temperatura de globo negro, °C; umidade relativa do ar, %; frequência cardíaca do operador,

xii) número de alunos matriculados classificados de acordo com a renda per capita familiar. b) encaminhem à Setec/MEC, até o dia 31 de janeiro de cada exercício, para a alimentação de

Este presente artigo é o resultado de um estudo de caso que buscou apresentar o surgimento da atividade turística dentro da favela de Paraisópolis, uma

As principais indicações para a realização foram a suspeita de tuberculose (458 pacientes) e uso de imunobiológicos (380 pacientes).. A maior prevalência de resultado positivo

17 CORTE IDH. Caso Castañeda Gutman vs.. restrição ao lançamento de uma candidatura a cargo político pode demandar o enfrentamento de temas de ordem histórica, social e política