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
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 inormação e aplicativosnormação e aplicativos em geral manipulam dados e inormações que cam armazenadas em geral manipulam dados e inormaçõ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 denições conceituais e revisão, também questões de permeiam as ases de denições conceituais e revisão, também questões de implantação e de manutenção da conabilidade, consistência e implantação e de manutenção da conabilidade, 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
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.
Oerecer uma base para a tomada de decisões em relação a Oerecer 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
• •
Classicação de alhas e si
Classicaçã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
• •
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
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 sotwares que compõem os sistemas de inormação
podem ser considerados apenas uma interace 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
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 inormações (SILBERCHARTZ; KORTH; SUDARSHAN, 2006). A qualidade de um projeto é tão importante quanto a qualidade dos sotwares que azem a interace 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 denida como uma restrição entre dois conjuntos de atributos de uma mesma entidade/relação (ALVES, 2004). Essa denição pode ser eita sob uma linguagem mais precisa. Elmasri e Navathe (2005) armam que uma dependência uncional, denotada por X→Y entre dois
conjuntos de atributos (que são subconjuntos) de uma relação R especicam 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 signica 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 exemplicado 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.
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 inor-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.
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, dierentemente 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
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 inormaçõ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 inormações como nome_aluno, estamos duplicando desnecessariamente uma inormação.
Uma solução aparente para esse problema seria unifcar as relações, de
maneira que as inormaçõ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 inormações duplicadas.
Complementando, podemos armar 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 inormações duplicadas devem ser propagadas para cada registro que contiver aquelas inormaçõ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 denição de um modelo de dados,
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 sucientes para termos uma boa deniçã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
•
eciência
•
acilidade de manutenção e alteração
•
fexibilidade
•
conabilidade
•
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 inormações multivalo-radas. Essas inormações são passíveis de decomposição. Uma inormação que
não pode, ou não precisa ser decomposta é chamada de inormaçã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 inorma-çõ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 rená-la para a orma sugerida na gura 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 orma normal é baseada no conceito de dependência uncional total. Alves (2004) complementa armando
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
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 signica que atributos parcialmente dependentes da chave serão removidos.
A remoção dos atributos parcialmente dependentes não signica propria-mente que essas inormaçõ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 inormaçõ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 eetuada sem a perda da capacidade de recuperação das inormaçõ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 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 vericando 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 identicaçã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
•
eciência
•
acilidade de manutenção e alteração
•
fexibilidade
•
conabilidade
•
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
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 identicaçã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 dierentes.
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 armar 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 transerir 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.
4. Que tipo de problemas pode ocorrer em um banco de dados cujas relações não observam nenhuma das ormas normais?
Que tal conerir 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 deniçã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á denido. 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 denido.
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 dierentes tipos de anomalias, por exemplo, anomalias de inserção que nos orçam a inserir inormações dupli-cadas e, além disso, obrigam a um esorç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
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 inormaçõ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.
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
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 denitivo. 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 inormações relacionadas, no qual cada uma das inormaçõ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 eciente, 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 inormaçã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.
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 é eciente, mas pode resultar no aparecimento dos mesmos problemas do armazenamento não ordenado.
Uma possibilidade de minimizar esses problemas é usar um arquivo de
overow . 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), eetuam 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 eciê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 transormar 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
Devemos considerar que existe a possibilidade de que dois valores dierentes 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 dierentes. 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 uniorme, no qual os
regis-tros cam distribuídos de maneira equilibrada nos diversos blocos disponíveis. Um espalhamento é dito uniorme quando a dierenç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 inormações desejadas (SILBERCHARTZ; KORTH; SUDARSHAN, 2006).
A utilização de um índice remissivo somente é útil se ele estiver ordenado, dimi-nuindo o esorç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 dene 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 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 reerenciado por um índice dierente. 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 é dierente 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á armado ante-riormente, podem existir diversos campos de indexação para um mesmo registro, como ilustra a Figura 2 a seguir.
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 deniçã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 justicado 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 deniçã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 inorma-ções e, ao mesmo, tempo ornece um mecanismo eciente 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 signica 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 dierentes 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 deasada 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 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 transerência globais (ELMASRI; NAVATHE, 2005).
Portanto a utilização de uma técnica de armazenamento e a recuperação de inormações adequada pode se tornar o dierencial de um determinado banco de dados em relação a outros. Aspectos como a quantidade de inormações de um banco de dados, os dispositivos ísicos de armazenamento disponíveis e os recursos de sotware 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 eciê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 dierentes 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 perormance. O que poderia ser eito 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 inormaçõ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 armar 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 conerir!
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.
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 eetuar 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 eciente) 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 armado. 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 inormaçõ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 eciente às operações eetuadas 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á!
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 Denindo transações
Date (2004, p. 63) arma que transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos de dados. Podemos dizer, ainda, que
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 é transormar 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 inormar ao sistema quando dierentes 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;
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 transerência bancária. Em meio a um processo de transerê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 transerê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 transerê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 conerê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 armar 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 é deseita;
transações de dierentes 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 qualicada como uma tran-sação. Vejamos agora, segundo Date (2004), o que signica cada uma delas.
3.3.1 Atomicidade
Uma transação deve ser uma unidade atômica de trabalho: ou todas as suas modicaçõ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 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 desazer 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, modicatransa-ções eitas por transatransa-ções simultâneas devem ser isoladas das modicaçõ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á sorendo 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 eeitos 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 modicações persistem até mesmo no caso de uma queda do sistema. Se todas as ações orem realizadas com sucesso, não signica 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 vericar 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.
Os estados de uma transação podem ser: ativa, em processo de eetivação, eetivada, em processo de aborto e concluída.
Uma transação pode se encontrar em dierentes estados. O grao 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 eetivaçã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 eetivadas com sucesso (não soram 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 eetivação. Suas ações já realizadas devem ser deseitas (ROLLBACK);
eetivada
• : entra nesse estado após o SGBD conrmar 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 buers em disco, entre outros;
concluída
• : estado nal de uma transação, ele indica uma transação que
deixa o sistema. As inormações das transações mantidas em catálogo podem ser excluídas (operações eitas, dados manipulados, buers
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 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 é transormar 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 deseita. 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 dierentes usuários que envolvem dados compartilhados são executadas em seqüência.
Compreendeu também que, para ser qualicada 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 grao de transição de estados. Finalmente, viu que os estados de uma transação podem ser: ativa, em processo
de eetivação, eetivada, em processo de aborto e concluída.
1. A partir do exposto na aula, como você dene transação?
2. Leia e analise atentamente as seguintes armativas 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 eetivadas com sucesso em um banco de dados ou nenhuma delas se eetiva. Isso é realizado para preservar a integri-dade do banco de dados.
II. A propriedade de isolamento dene que cada transação deve ser isolada dos eeitos da execução concorrente de outras transações.
III. A propriedade que dene 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.
Assinale a alternativa correta.
a) Somente a armativa I está incorreta.
b) Somente as armativas I e II estão corretas. c) Somente as armativas II e III estão incorretas. d) Todas as armativas estão corretas.
3. Para você, qual é a importância das transações em um SGBD?
4. Leia atentamente as armativas 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 conrma que todas as modica-ções da transação estão garantidas no banco de dados.
III. Eetivada é 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 armativas II e III estão incorretas. b) As armativas I e III estão incorretas. c) Somente a armativa IV está correta. d) As armativas I e IV estão incorretas.
Na atividade um, você armou que uma transação é a unidade lógica de
trabalho, constituída de um conjunto de operações. Seu objetivo é transormar 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 armativa (III) está incorreta, pois a propriedade de
consistência dene que cada transação executada isoladamente deve preservar a consistência do banco de dados, e a propriedade de durabilidade dene 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 deseita. 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 deniçã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 armativas (II) e (III) estão incorretas, pois o estado eetivado é o estado em que o SGBD conrma 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 dierente, 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 eetuada no mesmo instante em um banco de dados. Até lá!
Esperamos que, ao nal desta aula, você seja capaz de:
compreender o porquê da utilização da concorrência nas transações;
•
identicar 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 interram 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
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.
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.
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 supercial, é semelhante ao problema apresentado na seção anterior, já que resulta na leitura inconsis-tente de valores por uma transação. A dierenç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 exemplicar 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.
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 classicadas em técnicas pessimistas e otimistas. Elmasri e Navathe (2005) citam a seguinte classicação:
a) pessimista
bloqueio
•
• timestamp (marcas de tempo) b) otimista
validação
•
As técnicas pessimistas presumem que sempre ocorrerá intererê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 intere-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 tarea. Logo o que ocorre em todos os protocolos nada mais é que uma deniçã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 diundidos 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