SUMÁRIO... 6 ÍNDICE DE FIGURAS... 11 ÍNDICE DE TABELAS... 13 INTRODUÇÃO... 15 OBJETIVO... 16 RELEVÂNCIA... 17 LIMITES... 18 METODOLOGIA... 18 ESTRUTURA DA DISSERTAÇÃO... 19 CAPÍTULO 1... 20 1 BANCO DE DADOS... 20
1.1 OBJETIVOS DO BANCO DE DADOS... 20
1.2 CARACTERÍSTICAS DOS SISTEMAS DE BANCO DE DADOS... 21
1.2.1 Abstração de Dados... 22
1.2.2 Esquema... 22
1.2.3 Linguagens de definição de dados... 23
1.3 SISTEMA DE GERÊNCIA DE BANCO DE DADOS - SGBD... 23
1.3.1 Principais funções dos SGDBs... 25
1.3.2 Sistemas de arquivos versus sistema de banco de dados... 26
1.4 GERENCIAMENTO DE TRANSAÇÕES... 28
1.4.1 Propriedades das transações... 29
1.4.2 Processamento de consultas... 30
1.5 SERIALIZABILIDADE... 32
1.5.1 Escalas de execução... 33
1.5.4 Serialização de conflitos... 39
CAPÍTULO 2... 42
2 ARQUITETURAS DE BANCO DE DADOS... 42
2.1 SISTEMAS CENTRALIZADOS... 43
2.1.1 Arquitetura de banco de dados para sistemas centralizados... 44
2.1.2 Sistema cliente-servidor... 44
2.1.3 Características do ambiente centralizado... 45
2.1.4 Arquitetura de banco de dados para sistemas cliente-servidor... 45
2.2 SISTEMAS DISTRIBUÍDOS... 46
2.2.1 Transações distribuídas... 47
2.2.2 Características do ambiente distribuído... 48
2.2.2.1 Transparência... 49
2.2.2.2 Replicação de dados... 49
2.2.2.3 Fragmentação de dados... 50
2.2.2.4 Replicação e fragmentação de dados... 52
2.2.3 Arquitetura de banco de dados distribuído... 52
2.2.4 Internet... 57
2.2.4.1 Gateways de banco de dados... 59
2.2.4.2 Problemas de acesso ao banco de dados... 60
2.2.4.3 Características stateless e stateful... 61
2.3 SISTEMA DE COMPUTAÇÃO MÓVEL... 63
2.3.1 Arquitetura... 64
2.3.2 Componentes do ambiente móvel... 66
2.3.3 Acesso a dados em ambiente móvel... 67
2.3.3.1 Comunicação assimétrica... 68
2.3.4 Transações móveis... 69
2.3.4.1 Modelos de Transações Móveis... 70
2.3.6 Arquitetura de banco de dados móveis... 76
2.3.7 Extensão da arquitetura cliente-servidor... 79
2.4 SISTEMA ORIENTADO A OBJETO... 80
2.4.1 Estrutura objeto... 81
2.4.2 Banco de dados orientado a objetos – BDOO... 86
2.4.3 Transações aninhadas... 87
2.4.4 Arquitetura de banco de dados orientado a objetos... 88
CAPÍTULO 3... 91
3 CONTROLE DE CONCORRÊNCIA... 91
3.1 BENEFÍCIOS E PROBLEMAS GERADOS PELA CONCORRÊNCIA... 92
3.1.1 Atualização perdida de dados... 93
3.1.2 Dependência de dados não-gravados... 94
3.1.3 A leitura que não pode ser repetida... 95
3.2 MECANISMOS PARA O CONTROLE DE CONCORRÊNCIA... 96
3.2.1 Mecanismos de controle de concorrência baseados em bloqueio... 96
3.2.1.1 Protocolo de bloqueio em duas fases – 2PL... 98
3.2.1.2 Protocolo estrito de bloqueio em duas fases – 2PL Estrito... 100
3.2.2 Deadlock... 102
3.2.2.1 Prevenção de deadlock... 102
3.2.2.2 Detecção de deadlock... 104
3.2.2.3 Detecção versus Resolução... 106
3.2.2.4 Mecanismos de controle de concorrência baseados em grafos... 106
3.2.3 Mecanismos de controle de concorrencia baseados em TO... 110
3.2.3.1 Protocolo de ordenação por timestamp... 111
3.2.3.2 Timestamp estrito... 114
3.2.3.3 Ordenação por multiversões de timestamp... 115
3.2.4 Mecanismos de validação... 116
3.2.5 Mecanismos de controle de concorrência aplicações avançadas... 118
CAPÍTULO 4... 128
4 MÉTODOS DE CONTROLE DE CONCORRÊNCIA EM DIFERENTES TECNOLOGIAS DE BANCO DE DADOS... 128
4.1 CONTROLE DE CONCORRÊNCIA PARA BANCO DE DADOS DISTRIBUÍDO... 129
4.1.1 Parâmetros para o c.c. em ambientes distribuídos... 130
4.1.2 Controle de concorrência baseado em bloqueio... 133
4.1.2.1 Bloqueio centralizado... 134
4.1.2.2 Bloqueio de cópia primária... 135
4.1.2.3 Bloqueio descentralizado... 136
4.1.3 Controle de concorrência baseado em TO... 138
4.1.3.1 Timestamp básico... 139
4.1.3.2 Timestamp conservador... 140
4.1.4 Controle de concorrência ECHO... 141
4.1.5 Controle de concorrência network-aided... 145
4.1.5.1 Controle de concorrência network-aided ordenação total... 145
4.1.5.2 Controle de concorrência network-aided previsibilidade... 146
4.1.6 Controle de concorrência DAGSO... 149
4.2 CONTROLE DE CONCORRÊNCIA EM DOIS NÍVEIS... 153
4.3 INTERNET... 155
4.4 CONTROLE DE CONCORRÊNCIA PARA BANCO DE DADOS MÓVEIS... 155
4.4.1 Novos conceitos... 156
4.4.2 Bloqueio otimista 2PL para transações móveis – O2PL-MT... 159
4.4.3 Protocolo de gravação unilateral - UMC... 162
4.4.4 Técnica da Pré-serialização – Técnica PS... 165
4.4.5 Grafo de Seriabilização Temporal - TSGT... 169
4.4.5.1 Protocolo TSGT Básico... 170
4.4.5.2 Protocolo TSGT estendido... 172
4.5.2.1 Modos de bloqueio... 181
4.5.2.2 Tabela de comutatividade... 183
4.5.3 Controle de concorrência semântico [Jun e Gruenwald, 1996]... 184
4.5.4 Controle de concorrência semântico [Muth et al, 1993]... 186
4.6 ANÁLISE DO CC NAS DIFERENTES ARQUITETURAS... 188
4.6.1 Banco de dados distribuídos... 189
4.6.2 Banco de dados móveis... 190
4.6.3 Banco de dados orientado a objeto... 192
RESUMO DO TRABALHO... 194
FIGURA 1-1 COMPONENTES DE UM SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS 24
FIGURA 1-2 EXEMPLO DE EXECUÇÃO DE UMA TRANSAÇÃO... 29
FIGURA 1-3 ETAPAS PREPARATÓRIAS PARA O PROCESSAMENTO DE CONSULTAS... 31
FIGURA 1-4 ESCALONADOR... 35
FIGURA 2-1ARQUITETURA BÁSICA DE UM SISTEMA CENTRALIZADO... 43
FIGURA 2-2 ARQUITETURA BÁSICA DE UM SISTEMA CLIENTE-SERVIDOR... 44
FIGURA 2-3 RECURSOS DE FRONT-END E BACK-END... 46
FIGURA 2-4 ARQUITETURA DE REFERÊNCIA CLIENTE/SERVIDOR... 53
FIGURA 2-5 ARQUITETURAS CLIENTE-SERVIDOR... 54
FIGURA 2-6 ARQUITETURA DE REFERÊNCIA BANCO DE DADOS DISTRIBUÍDO... 55
FIGURA 2-7 ARQUITETURA MDBS COM GCS... 56
FIGURA 2-8 ARQUITETURA MDBS SEM GCS... 57
FIGURA 2-9 ARQUITETURA CLIENTE-SERVIDOR INTERNET... 58
FIGURA 2-10 ACESSO A BD POR SERVIDOR INTERNET... 59
FIGURA 2-11 ARQUITETURA STATELESS... 61
FIGURA 2-12 ARQUITETURA STATEFUL... 62
FIGURA 2-13 ARQUITETURA PARA SISTEMAS DE COMPUTAÇÃO MÓVEL... 65
FIGURA 2-14 TRANSAÇÃO CANGURU... 71
FIGURA 2-15 ARQUITETURA DE BANCO DE DADOS MÓVEIS... 79
FIGURA 2-16 FUNÇÕES DE CLIENTE-SERVIDOR "IGNORADAS"... 80
FIGURA -2-17 ESCALA DE EXECUÇÃO DE UMA TRANSAÇÃO ANINHADA... 88
FIGURA 2-18 ARQUITETURA SERVIDORA DE OBJETOS... 89
FIGURA 2-19 ARQUITETURA SERVIDORA DE PÁGINAS... 90
FIGURA 3-1 FASE DE CRESCIMENTO E ENCOLHIMENTO DA TRANSAÇÃO... 98
FIGURA 3-2 GRAFO DE BANCO DE DADOS ESTRUTURADO EM ÁRVORE... 108
FIGURA 3-3 PADRÃO DE ACESSO DE TRÊS TRANSAÇÕES... 121
FIGURA 3-4 VALIDAÇÃO DE CONFLITOS... 123
FIGURA 4-3 GERAÇÃO DE REGISTRO DE HORA ÚNICO... 138 FIGURA 4-4 ARQUITETURA BÁSICA DO MÉTODO ECHO... 143 FIGURA 4-5 TROCA DE MENSAGENS ENTRE SITES BROADCASTER E REPRESENTATIVOS.... 144 FIGURA 4-6 DIAGRAMA DE ESTADO DO DAGSO... 151 FIGURA 4-7 CONFIGURAÇÃO TÍPICA PARA UMC... 164 FIGURA 4-8 GERENTE DE TRANSAÇÃO GLOBAL... 166 FIGURA 4-9 COMPARAÇÃO DE EXECUÇÃO ENTRE IMPLEMENTAÇÕES DO BLOQUEIO
IMPLÍCITO... 178 FIGURA 4-10 EXECUÇÃO DE TRANSAÇÃO NO ESQUEMA DE CONTROLE DE CONCORRÊNCIA
TABELA 1-1 ESCALONAMENTO ENVOLVENDO DUAS TRANSAÇÕES... 33
TABELA 1-2 EXECUÇÃO DE DUAS TRANSAÇÕES... 36
TABELA 1-3 ESCALONAMENTO SERIAL, T1 PRECEDE T2... 36
TABELA 1-4 ESCALONAMENTO SERIALIZÁVEL E NÃO SERIAL... 38
TABELA 1-5 ESCALONAMENTO NÃO SERIALIZÁVEL... 39
TABELA 1-6 ESCALONAMENTO COM OPERAÇÕES DE LEITURA E ESCRITA E TABELA EQUIVALENTE COM OS PARES DE INSTRUÇÕES ALTERADOS... 40
TABELA 1-7 ESCALONAMENTO SERIALIZÁVEL EQUIVALENTE AO DA TABELA 1-7... 41
TABELA 3-1 TRANSAÇÃO T1 É PERDIDA NO MOMENTO T3... 93
TABELA 3-2 TRANSAÇÃO T1 DEPENDE DA ALTERAÇÃO NÃO GRAVADA POR T2... 94
TABELA 3-3 TRANSAÇÃO T2 ALTERA DADOS LIDOS POR T1... 95
TABELA 3-4 MATRIZ DE COMPATIBILIDADE DE BLOQUEIOS... 97
TABELA 3-5 PROTOCOLO ESTRITO 2PL... 100
TABELA 3-6 PROTOCOLO 2PL COM EXECUÇÃO SERIAL... 101
TABELA 3-7 PROTOCOLO ESTRITO 2PL COM EXECUÇÃO INTERCALADA... 101
TABELA 3-8 ESCALA SERIABILIZADA PELO PROTOCOLO BASEADO EM GRAFO... 109
TABELA 3-9 TRANTAÇÃO T1... 112
TABELA 3-10 TRANSAÇÃO T2... 112
TABELA 3-11 ESCALA DE EXECUÇÃO 3... 113
TABELA 3-12 ESCALA DE EXECUÇÃO 4... 113
TABELA 4-1 ORDEM DE EXECUÇÃO... 152
TABELA 4-2 DIFERENÇAS NO GERENCIAMENTO DE DADOS... 158
TABELA 4-3 ESTRUTURA GLOBAL DE DADOS... 168
TABELA 4-4 ESTRUTURA DO SITE... 169
TABELA 4-5 COMPARATIVO DA EXECUÇÃO ENTRE BLOQUEIO EXPLÍCITO E BLOQUEIO IMPLÍCITO... 176
TABELA 4-6 COMPARATIVO DA EXECUÇÃO DOS MÉTODOS DE CONTROLE DE CONCORRÊNCIA EM BDOO... 180
Os bancos de Dados evoluíram através de três gerações na história da informática. Durante a primeira geração, o processamento de dados era "centrado na tecnologia" e eles eram suficientes somente para armazenar quantidades relativamente pequenas de dados. O único meio de se chegar aos dados era lê-los, para processá-los e imprimi-los. Já nos anos 80, com o surgimento do computador pessoal, a computação "centrada no usuário" tornou-se a tendência. Isso levou aos modelos lógicos de dados independentes do armazenamento físico para permitir que os usuários tivessem acesso aos dados que desejassem. Atualmente nos encontramos rumando à terceira geração dessa evolução: o processamento de dados "centrado em rede". Embora tenhamos dado apenas alguns passos em direção a esse mundo, muitas operações já se encontram entrelaçadas com aquelas dos clientes e fornecedores. Portanto, esforços são necessários para que se atinja máxima disponibilidade tanto dos bancos de dados como da gerencia das aplicações. Os requisitos de desempenho da terceira geração demandam banco de dados que transcenda os limites do modelo de dados relacional. Os modelos de dados tradicionais, especialmente os relacionais, são relativamente fáceis de implementar. O problema surge quando tentamos enquadrar o mundo real dentro de padrões que as simplistas tecnologias relacionais não podem entender. Como resultado, temos observado uma tendência na direção das diferentes tecnologias de bancos de dados pós – relacionais que forçam o desenvolvimento de novas técnicas de gerenciamento de dados. O crescimento dos ambientes multiusuários e a difusão rápida da internet são exemplos práticos disso. Os novos tipos de dados são mais exigentes quanto à manipulação do acesso concorrente às informações. As técnicas tradicionais da maneira que foram concebidas, não se aplicam a eles devido a vários fatores, ou do ambiente onde são manipulados ou do próprio dado.
Esta pesquisa tem como objeto de estudo o controle de concorrência com ênfase nas suas características em diferentes arquiteturas de banco de dados. O controle de concorrência é um importante aspecto do gerenciamento dos dados em um banco de dados. Um Sistema de Gerência de Banco de Dados (SGBD) deve permitir que
diferentes usuários leiam e escrevam simultaneamente sobre o banco de dados. É tarefa do controle de concorrência assegurar que as transações, executando concorrentemente, mantenham a consistência do banco de dados.
Levando–se em consideração os elementos apresentados anteriormente, o trabalho proposto tem como finalidade à realização de um estudo dos principais aspectos dos métodos de controle de concorrência, como gerenciamento de transações, processamento de consultas e arquiteturas de banco de dados.
Além dos aspectos relacionados ao controle de concorrência, o presente trabalho aborda um estudo sobre a atuação e evolução dos mecanismos de controle de concorrência para adequar-se aos requerimentos dos novos tipos de dados impostos pelas arquiteturas de banco de dados centralizado, distribuído, móvel e orientado ao objeto.
Objetivo
A principal preocupação de um especialista ao desenvolver o projeto de um algoritmo de controle de concorrência é garantir o correto processamento das transações que estão envolvidas em conflito. Independente da plataforma em que será aplicado, o mecanismo de controle de concorrência deve garantir de forma eficaz a consistência do banco de dados.
Com o objetivo de organizar em um documento único e de fácil acesso, esta pesquisa apresenta uma síntese do ponto de vista de vários autores sobre os mecanismos utilizados para o controle de concorrência nas tecnologias de banco de dados mais relevantes no momento: banco de dados distribuídos, banco de dados móveis e banco de dados orientados a objetos. Dá ênfase às mudanças efetuadas nos mecanismos tradicionais identificando quais são as características dos mecanismos de controle de concorrência que necessitam de tratamento especial quando são submetidos a ambientes
Relevância
O controle de concorrência é um problema que surge quando vários processos estão envolvidos em alguma parte do sistema. A maioria dos sistemas comerciais utiliza o mais popular dos mecanismos de controle de concorrência o 2PL (Mecanismo de Bloqueio em Duas Fases). O crescimento contínuo da demanda para transações mais complexas e de alto nível compromete o grau de concorrência em um banco de dados o que motivou o desenvolvimento de várias técnicas para o controle de concorrência. A utilização de uma ou mais técnicas no controle de concorrência deve ser considerada caso a caso. Cada problema como: prioridade de acesso, recursos, arquitetura ou tráfego na rede, deve ser analisado avaliando as necessidades de cada aplicação em seu ambiente. A técnica (ou técnicas) a ser utilizada depende da situação considerada.
Esse trabalho contribui com um estudo realizado sobre os problemas e soluções existentes sob a visão de diferentes autores para diferentes ambientes. As alternativas propostas para lidar com os mecanismos de controle de concorrência são de importância vital para o mundo corporativo. A partir dos problemas e soluções relacionados pode-se determinar a utilização de um método para implantação em um novo banco de dados, ou ainda contribui para pesquisas buscando avaliar as características de um banco de dados já existente e definir alterações para adequá-lo a um melhor padrão de funcionamento.
Limites
O trabalho apresentado limita-se a um estudo dissertativo apresentando algumas técnicas de controle de concorrência. Não aborda demonstração de protótipos ou algoritmos de implementação. Seu principal objetivo foi agrupar as metodologias de desenvolvimento de diferentes autores dos mecanismos de controle de concorrência. Reúne os principais mecanismos para os banco de dados centralizados, banco de dados distribuído, banco de dados móvel e banco de dados orientado a objeto.
Metodologia
Os dados para realização desse trabalho foram obtidos através de pesquisa bibliográfica, análise do conteúdo de artigos relatórios e publicações técnicas.
Esse documento utiliza como fontes primárias de pesquisa [Ramakrishnam, 2000], [Bhargava, 1999], [Barghout and Kaiser, 1991], [Silberschatz et al, 1999], [Garcia-Molina et al, 2001] e documentos oficiais de congressos, workshops, artigos, relatórios técnicos, projetos e sites da internet.
Estrutura da dissertação
Os dados levantados através das pesquisas e estudos efetuados possibilitaram organizar esse trabalho em cinco capítulos.
No capítulo 1 descreve-se uma noção básica sobre banco de dados (BD) e sobre o gerenciamento de transações, devido a sua importância para compreensão do controle de concorrência. São estudados conceitos de banco de dados, características dos sistemas de gerencia de banco de dados (SGBD), gerência de transações, processamento de consultas e serializabilidade.
No capítulo 2 como influenciam diretamente o desenvolvimento dos mecanismos de controle de concorrência analisam-se resumidamente as tecnologias de banco de dados: banco de dados centralizado, banco de dados distribuído, banco de dados móvel, e banco de dados orientado a objeto.
No capítulo 3 apresenta-se o controle de concorrência e os mecanismos tradicionais utilizado para o gerenciamento do acesso concorrente. Todos processos que buscam a sincronização do acesso concorrente estão basicamente divididos em três categorias: bloqueio, timestamp e validação. O capítulo aborda também alguns mecanismos desenvolvidos para aplicações avançadas de banco de dados.
O capítulo 4 apresenta os métodos evoluídos e adaptados sobre os mecanismos tradicionais de controle de concorrência para as tecnologias de banco de dados estudadas.
O capítulo 5 apresenta um resumo do trabalho, traz uma análise de todo material apresentado e mostra as principais características e exigências das arquiteturas junto com as extensões e adaptações propostas sobre os mecanismos básicos.
1 Banco de Dados
Um banco de dados (BD) é uma coleção de informações. Essa coleção geralmente é organizada e apresentada para servir a uma finalidade específica. Geralmente as informações de um banco de dados são integradas e compartilhadas.
Estes dois aspectos representam a maior vantagem dos sistemas de banco de dados. Por ser integrado, o banco de dados pode ser imaginado como uma unificação de diversos arquivos de dados que, de outra forma, seriam distintos, eliminando-se total ou parcialmente quaisquer redundâncias entre os mesmos. Por ser compartilhado parcelas isoladas de dados podem ser utilizadas por diversos usuários num banco de dados, no sentido de que todos possam ter acesso à mesma fonte e usá-las com finalidades diferentes [Date, 1990].
1.1 Objetivos do banco de dados
• Gerenciar grande quantidade de informação. Um sistema de banco de dados pode armazenar simplesmente dados referentes a uma agenda de amigos, como também pode armazenar as informações relativas a uma usina nuclear.
• Evitar redundância de dados e inconsistência. Redundância é manter a mesma informação em lugares diferentes. Um dos problemas da redundância é que podemos atualizar um determinado dado de um
é chamado de inconsistência.
• Segurança aos dados. Nem todos os usuários de banco de dados estão autorizados ao acesso a todos os dados. Imagine, se numa empresa todos funcionários tivessem acesso à folha de pagamento.
• Garantir a integridade . É fazer com que os valores dos dados atribuídos e armazenados em um banco de dados satisfaça certas restrições para manutenção da consistência e coerência.
1.2 Características dos sistemas de banco de dados
• Dado. É o valor do campo quando é armazenado no banco de dados. Por exemplo o valor do campo "nome do cliente" para quem está fazendo a entrada de dados.
• Conteúdo do campo. É o valor do campo armazenado no banco de dados. Por exemplo o valor do campo "nome do cliente" sem ser, momentaneamente, utilizado, armazenado na base de dados.
• Informação. É o valor que o campo representa para as atividades da empresa. Por exemplo uma resposta a uma consulta: qual os nomes dos clientes localizados no Paraná?
• Modelos de banco de dados. Representa a estrutura física interna de recuperação e armazenamento dos dados no qual o SGBD foi projetado.
1.2.1 Abstração de Dados
O sistema de banco de dados esconde alguns detalhes de como os dados são armazenados ou mantidos, esse processo é conhecido como abstração de dados. Esse conceito é importante devido à preocupação com a eficiência de um banco de dados que leva a concepção de estruturas de dados complexas para a representação dos dados. [Garcia-Molina, 2001] Existem basicamente trás níveis de abstração: Nível Físico, Nível Conceitual e Nível Visão:
• Nível Físico. É o nível mais baixo de abstração, no qual se descreve como os dados são realmente armazenados. Neste Nível estruturas complexas, de baixo nível, são descritas em detalhes.
• Nível Conceitual. Também chamado de Nível Lógico, é considerado o nível secundário de abstração, onde se descreve quais dados são realmente armazenados no banco de dados e quais os relacionamentos entre eles.
• Nível Visão. o mais alto nível de abstração, onde é somente exposta a parte do banco de dados que um determinado usuário necessita. O sistema pode proporcionar diversas visões para um mesmo banco de dados.
1.2.2 Esquema
Esquema é a estrutura de um banco de dados. Existem diversos esquemas referentes aos níveis de abstração. No nível mais baixo há o esquema físico; no nível intermediário, o esquema lógico; e no nível mais alto, os subesquemas.
Um esquema de dados é especificado por um conjunto de definições expressas por uma linguagem especial chamada linguagem de definição de dados (data-definition
language - DDL). O resultado da compilação dos parâmetros DDLs é armazenado em
um conjunto de tabelas que constituem um arquivo especial chamado dicionário de dados ou diretório de dados.
A estrutura de memória e o método de acesso usado pelo banco de dados são especificados por um conjunto de definições em um tipo especial de DDL chamado linguagem de definição e armazenamento de dados (data storage and definition
language). O resultado da compilação dessas definições é um conjunto de instruções
para especificar os detalhes de implementação dos esquemas do banco de dados.
1.3 Sistema de gerência de banco de dados - SGBD
É um software de gerência cujo objetivo é prover o acesso às informações de forma uniformizada.
Segundo [Date, 1990], o sistema de gerência de banco de dados (SGBD) é o software que manipula todos os acessos ao banco de dados.
Na figura 1.1, vemos um esboço de um SGBD completo. Retângulos simples representam componentes do sistema, retângulos tracejados representam estruturas de dados na memória. As linhas contínuas indicam fluxo de controle e de dados, enquanto as linhas tracejadas indicam somente fluxo de dados [Garcia-Molina et al, 2001].
Gerenciador de transações Compilador de consultas Mecanismo de execução Registro log e recuperação controle de concorrência Gerenc índices/ arquivos/registros Gerenciador buffer Gerenciador de armazenamento Armazenamento Usuário/Aplicativo Administrador de Banco de Dados Buffers Consultas, atualizações Plano de consulta Solicitações de índices, arquivos e registros Comandos de páginas Páginas de leitura/ gravação Comandos de transações metadados, estatísticas páginas de log Tabela de Bloqueio dados,metadados,í ndices metadados Comandos de DDL compilador
Fonte: MOLINA-GARCIA, Hector; ULLMAN, Jeffrey D.; WINDOM, Jennifer. Implementação de Sisstemas de Banco de Dados. Tradução de Vandenberg D. de Souza, Rio
de Janeiro: Campus, 2001.
1.3.1 Principais funções dos SGDBs
Os SGBDs se caracterizam principalmente pelo modelo de banco de dados [Melo et al, 1997]. Um SGBD disponibiliza funções voltadas para assegurar:
• Definição e manipulação de dados. Estas funções são fornecidas pelas linguagens do SGBD. A Linguagem de definição de dados (LDD) é usada para definir o esquema do banco de dados. O SGBD possui um compilador de LDD que processa os comandos de descrição das estruturas do esquema e os armazena em um dicionário de dados. A linguagem de manipulação de dados (LMD) é usada para realizar consultas e atualizações no banco de dados. Manipulação de dados. Um SGBD deve prover facilidades para carregar o banco de dados ou parte dele, a partir de arquivos de dados ou comandos armazenados e, inversamente, descarregá-los em arquivos. Similarmente, a cópia de segurança do conteúdo do banco de dados deve ser possível. Deve ainda garantir que as falhas durante o processamento de transações não sejam propagadas aos objetos persistentes. Um mecanismo de recuperação é provido pelo SGBD para isso.
• Persistência. É a capacidade dos objetos do banco de dados persistirem ao longo de diferentes execuções de programas de aplicação. Objetos persistentes são armazenados em arquivos do sistema operacional, fora dos programas que os utilizam e sobrevivem às falhas das transações e mesmo a algumas falhas de sistemas.
• Segurança. Um SGBD deve prover mecanismos de segurança de acesso para consulta ou atualização dos objetos persistentes. Em geral, estes mecanismos são implementados por meio de concessão/revogação de privilégios de acesso a usuários individuais ou grupos de usuários.
• Integridade . Um banco de dados deve estar sempre num estado consistente, satisfazendo permanentemente algumas condições de consistência, chamadas
de restrições de integridade. O SGBD tem a incumbência de garantir a integridade do banco de dados na passagem de um estado para outro, que ocorre ao final de cada transação.
• Controle de Concorrência. Deve ser transparente ao usuário a execução de transações concorrentes, deve-se passar a impressão de que estão sendo executadas isoladamente quando, na maioria dos sistemas, haverá na verdade muitas transações sendo executadas ao mesmo tempo. Portanto o escalonador (gerenciador do controle de concorrência) deve assegurar que as ações individuais de várias transações serão executadas em total ordem e que o efeito final será igual ao que haveria se as transações fossem executadas de fato uma de cada vez.
• Desempenho. Cabe ao SGBD garantir aos usuários índices satisfatórios de desempenho, como tempo de resposta em consultas e volume de transações processadas.
1.3.2 Sistemas de arquivos versus sistema de banco de dados
[Ramakrishman e Gehrke, 2000] Algumas características dos sistemas de banco de dados os diferenciam dos sistemas de arquivos tradicionais:
• A separação entre programas e dados;
• O suporte para múltiplas visões de usuário;
• O compartilhamento de dados e processamento multi-usuário de transações;
analise o exemplo a seguir: uma empresa com uma grande coleção de dados interligados (empregados, departamentos, produtos, vendas). Esses dados são acessados concorrentemente por diferentes funcionários. Também é necessário, por questões de segurança do banco de dados, restringir o acesso a determinadas informações para determinados usuários. Tentar gerenciar esses problemas a partir de um sistema de arquivos independentes, em máquinas independentes é praticamente impossível. Primeiramente, provavelmente não teríamos espaço suficiente de memória principal para manter todos os dados. Seríamos obrigados a armazenar dados em uma unidade de armazenamento, como um disco ou uma fita e carregar partes relevantes na memória principal para o processamento quando necessário. Teríamos que programar alguns métodos de identificação para todos os itens de dados. Teríamos ainda que escrever programas especiais para responder a cada consulta de usuários. Precisaríamos proteger os dados de alterações inconsistentes enviadas por diferentes usuários que acessam os dados concorrentemente. Esses programas deveriam considerar o acesso concorrente à memória, o que aumentaria sua complexidade. Precisaríamos garantir que os dados sejam restaurados quando ocorrer falha do sistema. Sistema operacional provê somente mecanismos de segurança, isto não é suficientemente flexível para aplicar políticas de segurança para o acesso concorrente. Assim, o uso de um SGBD para gerenciar dados traz vantagens como:
• Independência de dados;
• Eficiente acesso aos dados;
• Segurança e integridade dos dados;
• Administração de dados;
• Recuperação e acesso concorrente; e
1.4 Gerenciamento de transações
As operações executadas por um programa acessando um banco de dados são agrupadas em seqüências chamadas transações. A interação dos usuários com o banco de dados é feita através das transações [Barghout and Kaiser, 1991].
Uma transação possui propriedades bem definidas que são garantidas pelos gerenciadores de banco de dados. O gerenciador de transações aceita comando de transações de um aplicativo que irá informar ao gerenciador de transações quando as transações começam e quando terminam. O processador de transações executa as seguintes tarefas.
1. Registro de log: Para assegurar durabilidade, toda mudança no banco de dados é registrada separadamente em disco. O gerenciador de log segue uma dentre várias normas projetadas para assegurar que, independentemente de quando ocorre uma falha, um gerenciador de recuperação pode examinar o
log de mudanças e restabelecer o banco de dados a algum estado consistente.
2. Controle de concorrência: Os principais problemas relacionados com o gerenciamento de transações são gerados pela execução concorrente de transações que possuem acessos conflitantes a um mesmo item de dado e pelo acesso a dados dispersos por diferentes e independentes locais. As transações são gerenciadas pelos SGBD para evitar que ocorram anomalias (inconsistência de dados) durante ou após o seu processamento. No caso de transações executadas concorrentemente há a necessidade da utilização de mecanismos de controle para evitar a violação da integridade dos dados manipulados. Serão vistos com maiores detalhes no decorrer desse trabalho.
A figura 1.2 descreve um exemplo simples da seqüência de execução de uma transação.
Programa 1. Transação 2. Transação
Início
da transação Grava Aborta Início
da transação
Figura 1-1 Exemplo de execução de uma transação
1.4.1 Propriedades das transações
A integridade das transações exige que satisfaça certas características tradicionalmente agrupadas em quatro propriedades conhecidas como ACID: Atomicidade, Consistência, Isolamento e Durabilidade [Ferreira e Finger, 2000].
Atomicidade. Essa propriedade não permite efeitos parciais na execução de uma
transação. Ou todas suas operações são realizadas ou então nenhuma é. Transações podem não se completar basicamente por três razões: 1) a transação pode ser abortada ou finalizada sem sucesso pelo SGBD porque alguma anomalia apareceu durante sua execução. Se uma transação é abortada pelo SGBD por razões internas, ela automaticamente é reiniciada. 2) o sistema pode falhar, por exemplo, queda de energia durante a sua execução. 3) a transação pode encontrar uma situação inesperada, por exemplo, não conseguir acesso a disco e decida abordar. Se considerarmos que o usuário pensa que as transações existentes são atômicas, uma transação interrompida durante sua execução pode deixar o banco de dados em um estado inconsciente, assim um SGBD procura um modo de remover os efeitos das transações parciais, assegurando a atomicidade da transação. [Ramakrishnan e Gehrke, 2000].
Consistência. Essa propriedade garante que um banco de dados permaneça
definida uma operação de usuário onde sua execução deve partir de um estado consistente e finalizar em novo estado consistente [Melo et al, 1997].
Isolamento. A execução de uma transação não pode ser afetada pela execução
concorrente de outras. [Ferreira e Finger, 2000]. Transações são isoladas ou protegidas dos efeitos das ações concorrentes de outras transações. A propriedade isolamento garante que ações de diferentes transações podem ser intercaladas, mas o efeito externo será a execução de uma depois da outra em alguma ordem serial.
Durabilidade . Significa que os resultados de uma transação, caso ela seja
concluída com sucesso, devem ser persistentes, mesmo que ocorram falhas nos meios de armazenamento utilizados. [Melo et al, 1997]. Os efeitos de uma transação confirmada não podem ser desfeitos, só podem ser alterados por outra transação subseqüente confirmada e gravada.
1.4.2 Processamento de consultas
Consulta é a ação de extrair dados de um banco de dados. Elas podem ser formuladas diretamente pelos usuários finais, através de uma linguagem de alto nível suportada pelo banco de dados, ou podem estar contidas em aplicações desenvolvidas por programadores [Silberschatz et al, 1999].
Independentemente da origem da consulta, sua composição é feita parcial ou integralmente por comandos de manipulação de dados expressos na linguagem de um SGBD. O processamento de um comando de consulta acontece em várias etapas que podem ser agrupadas em dois passos:
1. Primeiro uma validação sintática é executada. Um componente do SGBD verifica se o comando foi escrito corretamente, formando uma frase válida na linguagem de manipulação de dados definida. Assim a primeira ação do sistema no processamento de uma consulta é traduzi-la
estruturalmente correta é preciso que os nomes utilizados sejam de objetos descritos no esquema do banco de dados referenciado e que possuam os tipos compatíveis com as regras para a construção do comando recebido.
2. Depois, o comando validado é traduzido para uma linguagem baseada em Álgebra, a partir das informações existentes no esquema do banco de dados. Essa linguagem é então otimizada. O processo de otimização consiste na definição de uma estratégia de execução que resulte no melhor desempenho possível [Melo et al 1997].
Validação S i n t á t i c a Trad para c o m a n d o s m a i s simples Otimização Catálogo do s i s t e m a Consulta Plano otimizado de execução da consulta Consulta em comandos simples Consulta Válida
Fonte: MELO, Rubens N..; SILVA, Sidney Dias da, TANAKA, Asteiro K.Banco de Dados em Aplicações Cliente-Servidor. Rio de Janeiro: Infobook, 1997
Figura 1-1 Etapas preparatórias para o processamento de consultas
Nos modelos de rede e hierárquico a otimização da consulta é geralmente responsabilidade do programador.
Na figura 1.3 é possível identificar as etapas utilizadas pelo processador de consultas durante a conversão de uma consulta simples para sua forma interna chamada
plano de consulta ou consulta válida. O compilador de consultas possui três subcomponentes:
• Analisador de consultas. Que constrói a estrutura árvore partindo da forma textual da consulta.
• Pré-processador de consultas. Responsável pelas verificações semânticas sobre a consulta e por algumas transformações de árvores que converte a árvore de análise em árvore de operadores algébricos que representa o plano de consulta inicial.
• Otimizador de consultas. Que transforma o plano de consulta inicial na melhor seqüência disponível de operações sobre o banco de dados. Em seguida, o mecanismo de execução executa cada etapa do plano de consulta escolhido. O processador de consultas interage com a maioria dos outros componentes do SGBD [Garcia-Molina et al, 2001].
1.5 Serializabilidade
A ordem em que as etapas individuais de transações diferentes ocorrem precisa ser controlada. A função de gerenciar essas etapas é dada ao componente do SGBD chamado escalonador. O fundamento da serializabilidade é tratar de maneira mais rigorosa os elementos necessários para a eficiente construção e detecção de escalonamentos. [Ferreira e Finger, 2000].
Estendendo o conceito de escalonamentos consistentes temos que a serializabilidade consiste da possibilidade de se estabelecer uma execução serilializável que equivalha à execução serial das transações encapsuladas por ela. Ela é o requisito abstrato para assegurar que transações executadas concorrentemente preservem a correção do estado do banco de dados.
Uma transação é composta por várias operações que podem ser de escrita ou de leitura. Para denota-las considera-se que um objeto O está sempre lendo dentro de um objeto também chamado O, assim uma transação T lendo um objeto O corresponde ao símbolo RT(O). Similarmente, podemos denotar operações de escritas como WT(O) [Silbersthatz et al 1999].
Em uma operação de leitura ou de escrita, a operação final de uma transação ou é gravada (commit) se completada com sucesso ou é abortada (abort). AT denota a operação de aborto de uma transação T e CT denota que uma transação T foi gravada.
Uma escala de execução (schedule) é uma lista de operações (leituras, escritas, abortos ou gravações) de um grupo de transações. A ordem de duas operações de uma transação T mostrada na escala pode ser a mesma ordem em que aparecem na transação T. A escala de execução da tabela 1.1 mostra uma ordem de execução para as operações das transações T1 e T2.
Uma escala de execução descreve as ações das transações como são vistas pelo SGBD. T1 T2 RT(A) WT(A) RT(B) WT(B) RT(C) WT(C)
Fonte: RAMAKRISHNAN, Raghu; GENRKE, Johannes. Database Management Systems. MacGraw-Hill, 2000. Second Edition.
A propriedade de atomicidade é aplicada sobre as escalas serializáveis garantindo que as operações abortadas existentes sejam desfeitas mantendo consistência idêntica a da execução da mesma escala de forma completa e serial. Estendendo essa definição para uma escala de execução serializável se obtém a definição: um escalonamento serializável definido sobre um grupo de transações G é uma escala de execução de consistência idêntica à uma escala de execução serial completa sobre o grupo de transações gravadas em G [Ramakrishnan e Gehrke, 2000].
• Escalonamento completo. Uma escala de execução completa é aquela que para cada transação possui abortos e gravações.
• Escalonamento serial. Uma escala de execução serial é aquela que tem suas transações executadas uma a uma do início ao fim.
• Escalonamento consistente. A definição mais formal para uma escala de execução consistente diz que: ela é consistente se todas as transações compreendidas nela são executadas serialmente (Ti, Ti+1,..., Tn). Isto é
para todo i = 1 até n -1 a transação Ti seja executada completamente
antes da transação Ti+1 começar [Barghout e Kaiser, 1991].
Uma escala de execução representa uma seqüência de execução atual ou potencial, pois a ordem de execução de duas ações de uma transação deve ser a mesma apresentada na transação.
1.5.2 Escalonador
O escalonador é o responsável pelo gerenciamento da concorrência. É o elemento do SGBD que tem como função receber e organizar as operações das transações. Para isso ele utiliza os critérios e fundamento da teoria da serializabilidade.
transações e as executar em buffers ou as manter em estado de espera até que possa ser executada (utilizando técnicas de controle de concorrência) [Garcia-Molina et. al, 2001]. Gerenciador de Transações Escalonador Solicitações de leitura e gravação Leituras e gravações Buffers
Fonte: GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.; WINDOM, Jennifer. Implementação de Sestemas de Banco de Dados. Tradução de Vanderberg D. de Souza.
Rio de Janeiro: Campus, 2001.
Figura 1-1 Escalonador
1.5.3 Escalonamentos seriais e serializáveis
Um escalonamento é uma seqüência ordenada das operações importantes executadas por uma ou mais transações. Ele deve conter todas as operações ordenadas de um conjunto de transações e não deve possuir operações conflitantes entre transações concorrentes.
Por exemplo, considere as duas transações e o efeito sobre o banco de dados quando suas ações são executadas em certa ordem. As ações das transações T1 e T2 são
T1 T2 RT(A, t) RT(A,s) t:=t+100 S :=s*2 WT(A, t) WT(A, s) RT(B, t) RT(B, s) t:=t+100 S :=s*2 WT(B, t) WT(B, s)
Fonte: GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.; WINDON, Jeniffer. Implementação de Sistemas de Banco de Dados. Tradução de Vandenberg D. de Souza. Rio de Janeiro: Campus, 2001.
Tabela 1-1 Execução de duas transações
Suponha que o único critério de consistência sobre o banco de dados é que A = B. Como T1 acrescenta 100 a A e a B e T2 multiplica A e B por 2. Cada transação se
executada isoladamente preservará a consistência como mostra a tabela 1.4
T1 T2 A B RT(A, t) 25 25 t:=t+100 WT(A, t) 125 RT(B, t) t:=t+100 WT(B, t) 125 RT(A,s) S :=s*2 WT(A, s) 250 RT(B, s) S :=s*2 WT(B, s) 250
Fonte: GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.; WINDON, Jeniffer. Implementação de Sistemas de Banco de Dados. Tradução de Vandenberg D. de Souza. Rio de Janeiro: Campus, 2001.
Um escalonamento é dito serial se para cada par de transações, Ti e Tj, todas as
operações de T precedem todas as operações de Tj ou vice-versa [Ferreira e Finger,
2000].
Para as transações da tabela 1.3 existem dois escalonamentos seriais possíveis, um em que T1 precede T2 e outro onde T2 executa antes de T1 .
Escalonamentos seriais não permitem nenhuma concorrência entre as operações de transações distintas. A execução de uma transação bloqueia a execução de todas as outras. Entretanto são utilizados como parâmetro para determinação da correção dos escalonamentos.
Estendendo o conceito de escalonamento serial é correto afirmar que um escalonamento é consistente somente se for equivalente a um escalonamento serial.
1.5.3.2 Escalonamentos serializáveis
Existem ainda escalonamentos não seriais mas que preservam a consistência:
T1 T2 A B RT(A, t) 25 25 t:=t+100 WT(A, t) 125 RT(A,s) S :=s*2 WT(A, s) 250
RT(B, t) t:=t+100 WT(B, t) 125 RT(B, s) S :=s*2 WT(B, s) 250
Fonte: GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.; WINDON, Jeniffer. Implementação de Sistemas de Banco de Dados. Tradução de Vandenberg D. de Souza. Rio de Janeiro: Campus, 2001.
Tabela 1-1 Escalonamento serializável e não serial
No escalonamento da tabela 1.4, T2 atua sobre A depois de T1, mas antes de T1
atuar sobre B. Entretanto o efeito das duas transações escalonadas é idêntico ao do escalonamento serial T1 à T2. Esse escalonamento garante que tanto A quanto B
ficarão com o valor 2 (c+100) e desse modo a consistência não só das transações, mas do banco de dados é preservada a partir de qualquer estado consistente.
O escalonamento da tabela 1.5 não é serial e também não é serializável. Ele toma o estado consistente A = B = 25 e deixa o banco de dados em um estado inconsistente, onde A = 250 e B = 150. T1 T2 A B RT(A, t) 25 25 t:=t+100 WT(A, t) 125 RT(A,s) S :=s*2 WT(A, s) 250 RT(B, s) S :=s*2 WT(B, s) 50 RT(B, t)
WT(B, t) 150
Fonte: GARCIA-MOLINA, Hector; ULLMAN, Jeffrey D.; WINDON, Jeniffer. Implementação de Sistemas de Banco de Dados. Tradução de Vandenberg D. de Souza. Rio de Janeiro: Campus, 2001.
Tabela 1-2 Escalonamento não serializável
1.5.4 Serialização de conflitos
O escalonamento é imposto através dos mecanismos de controle de concorrência e a consistência do banco de dados depende da sua efetiva participação. Os conflitos surgem quando duas transações solicitam uma operação sobre o mesmo item de dados a técnica de serialização desse conflito garante a concorrência e a consistência do banco de dados [Silberschatz et al, 1999].
Por exemplo, em um escalonamento com duas operações sucessivas A e B pertencentes às transações T1 e T2, respectivamente, quando as operações referem-se a
objetos diferentes suas execuções em qualquer ordem não afetam os resultados. Mas quando A e B se referem ao mesmo objeto então a ordem de execução é importante.
Denotando instruções de leitura (RT) e de escrita (WT) sobre um objeto O, é possível listar as principais compatibilidades entre elas durante uma execução:
1) A = RT(O) B = RT(O). Não conflitam mesmo que A e B desejem operar sobre o mesmo objeto. A ordem de execução não é importante
2) A = RT(O), B = WT(O). Não conflitam desde que A e B referenciem –se a objetos diferentes. Quando solicitam operações sobre o mesmo objeto elas conflitam porque sua ordem não pode ser alterada pelo SGBD.
3) A = WT(O), B = RT(O). A ordem A e B importa por razões semelhantes às do caso anterior.
4) A = WT(O), B = WT(O). Como ambas as instruções são de operações de escrita, a ordem não afeta as transações. O resultado obtido será relevante somente para a próxima operação de leitura, pois o valor armazenado é o resultado da última operação de escrita e a ordem de execução afeta diretamente esse valor.
A alteração da ordem de execução de um par de transações pode interferir no resultado de pelo menos uma delas, essa ordem só poderá ser trocada se pelo menos uma dessas operações for uma operação de escrita [Garcia-Molina et al, 2001].
T1 T2 T1 T2 RT(A) RT(A) WT(A) WT(A) RT(A) RT(A) WT(A) RT(B) RT(B) WT(A) WT(B) WT(B) RT(B) RT(B) WT(B) WT(B)
Fonte: SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistemas de Banco de Dados. São Paulo: Makron Books do Brasil Editora Ltda, 1999. Terceira Edição
Tabela 1-1 Escalonamento com operações de leitura e escrita e tabela equivalente com os pares de instruções alterados
A instrução WT(A) de T1 entra em conflito com a operação RT(A) de T2. A
operação WT(A) de T2 não está em conflito com a operação RT(B) de T1 porque elas
trabalham com objetos diferentes.
Sejam A e B operações consecutivas de um escalonamento S. Se A e B são operações de transações diferentes e não entram em conflito, então é possível trocar a ordem de execução de A e B para produzir uma nova escala de execução S’. Espera-se que S seja equivalente a S’, já que todas as operações aparecem na mesma ordem em
Continuando as trocas de operações não-conflitantes o resultado final é uma escala de execução serial:
• Trocar a operação RT(B) de T1 por RT(A) de T2.
• Trocar a operação WT(B) de T1 por WT(A) de T2.
• Trocar a operação WT(B) de T1 por RT(A) de T2.
T1 T2 RT(A) WT(A) RT(B) WT(B) RT(A) WT(A) RT(B) WT(B)
2 Arquiteturas de banco de dados
A arquitetura de um sistema de banco de dados segundo [Silberschatz et al, 1999] é fortemente influenciada pelo sistema básico computacional sobre o qual o sistema de banco de dados é executado. Assim no desenvolvimento ou na escolha de um mecanismo de controle de concorrência ambos, a arquitetura física e a arquitetura do banco de dados, devem ser considerados a fim de buscar o equilíbrio entre a confiabilidade do sistema e a performance de execução.
Como exemplo dessa influência, em um ambiente de rede de computadores permite que algumas tarefas sejam executadas no servidor e outras no cliente o que caracteriza os sistemas de banco de dados cliente-servidor. A distribuição de dados permite que eles residam onde são gerados ou mais utilizados e, ainda assim, estejam acessíveis para outros sites. Esses departamentos distribuídos podem ser representados por unidades móveis ou um cliente na Internet. Para tratar esse tipo de dados o sistema de banco de dados distribuídos tem evoluído.
Novas aplicações proporcionadas por vários aspectos da evolução do hardware, forçam uma nova abordagem até então não suficientemente trabalhada nos modelos tradicionais motivando o desenvolvimento de novas tecnologias para tratamento de informações como CAD, CASE, hipertexto, multimídia, trazendo o desenvolvimento de bancos de dados orientados ao objeto.
Sistemas centralizados são aqueles executados sobre um único sistema computacional que não interagem com outros sistemas.
Um sistema computacional genérico consiste em uma ou algumas unidades de processamento (CPU) que são conectadas por meio de um barramento (bus) comum que proporciona acesso à memória compartilhada (figura 2.1). As CPUs têm memórias
cache locais que armazenam cópias de partes da memória principal para acesso rápido
aos dados [Silberschatz et al, 1999].
Sistema de barramento CPU Impressora Controlador de impressora Controlador de unidade de fita Controlador de memória Memória Controlador de disco Disco Disco Unidade de fta
Fonte: SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistemas de Banco de Dados. São Paulo: Makron Books do Brasil Editora Ltda,
1999. Terceira edição
2.1.1 Arquitetura de banco de dados para sistemas centralizados
Sistema de banco de dados em ambientes centralizados pode ser projetado para ser monousuário, como os utilizados em computadores pessoais e normalmente não oferecem os recursos comuns aos bancos de dados multiusuário. Por exemplo, não é necessário o controle de concorrência, quando somente um usuário pode produzir atualizações.
2.1.2 Sistema cliente-servidor
Como resultado do avanço tecnológico terminais de sistemas centralizados foram substituídos por estações de trabalho possibilitando assim a arquitetura de sistemas Cliente-Servidor. Nessa arquitetura os servidores agem como provedores de recursos para as entidades clientes.
Rede Servidor
Estação Cliente Estação Cliente Estação Cliente Estação Cliente
Por se tratar de uma arquitetura resultante da evolução dos antigos sistemas de arquivos os sistemas cliente-servidor partem do princípio do armazenamento e gerenciamento único. Suas principais características podem ser relacionadas como:
• Servidor é responsável por todo processamento, distribuição e armazenamento dos dados
• Conexão persistente com largura de banda suficiente para processar todas as interações entre cliente e servidor.
• Topologia persistente.
2.1.4 Arquitetura de banco de dados para sistemas cliente-servidor
No banco de dados em ambiente cliente-servidor, o processamento, manipulação e acesso aos dados são executados pelo servidor, ficando a estação cliente apenas com o processamento das aplicações.
As funcionalidades de um banco de dados nesse ambiente podem ser superficialmente divididas em duas categorias front-end e back-end (figura 2.3) [Silberschatz et al, 1999].
Interface com o usuário Interface gráfica Gerador de relatórios Interface para formulários
Interface entre front-end e back-end
Suporte a linguagem de banco de dados
Back-end Front-end
Figura 2-1 Recursos de front-end e back-end
• Back-end. Gerencia as estruturas de acesso, desenvolvimento e
otimização de consultas e cuida do controle de concorrência e de recuperação.
• Front-end. É constituído pelas ferramentas como formulários,
gerador de relatórios e recursos de interface gráfica. A interface entre o front-end e o back-end é feita por meio de uma linguagem de banco de dados, por exemplo, o SQL ou de um programa de aplicação [Silbercshatz et al, 1999].
2.2 Sistemas distribuídos
Um sistema distribuído caracteriza-se por um conjunto de múltiplos computadores, interligados em rede que utilizam tempo compartilhado para a execução cooperativa de programas de aplicação, com controle geral de recursos descentralizados.
Os dados podem ser armazenados de forma distribuída, próximos ao seu ponto normal de uso reduzindo o tempo de resposta e os custos de comunicação. O
dados aperfeiçoada e possivelmente melhor os tempos de resposta em certas situações.
Em um sistema distribuído os processadores podem variar de tamanho e função. Os computadores de um sistema distribuídos recebem vários nomes diferentes. Aqui serão denominados sites. Cada site constitui um sistema de banco de dados com suas próprias regras: banco de dados, terminais e processador central próprio, seu próprio SGBD.
A principal característica que distingue os sistemas de processamento distribuído dos sistemas tradicionais centralizados é a descentralização do controle. Eles são heterogêneos e possui maior confiabilidade perante falhas sucessivas de componentes.
Uma das principais vantagens de compartilhar os dados pela distribuição é o fato de que cada site pode reter um grau de controle sobre os dados armazenados localmente.
O banco de dados distribuído pode ser considerado como a união de um conjunto de bancos de dados individuais centralizados [Özsu e Valduriez, 1999].
2.2.1 Transações distribuídas
Em um ambiente de banco de dados distribuído uma transação pode acessar dados armazenados em mais de um site. No momento de sua execução ela é dividida em subtransações, uma para cada site que contem as informações que ela precisa acessar. Cada subtransação da transação global deve ser tratada como uma transação indivisível pelo site local em que ela esta sendo executada. Existem dois tipos de transações:
• Transações locais. São aquelas que mantêm acesso e atualizam somente a base de dados local.
• Transações globais. Que mantêm acesso e atualizam diversas bases de dados locais.
Cada site possui seu próprio gerenciador local de transação cuja função é garantir as propriedades ACID das transações executadas localmente. Os diversos gerenciadores de transações cooperam para executar as transações globais. [Silberschatz et al, 2000]
A garantia das propriedades ACID nas transações locais pode ser executada de modo similar as executadas em transações de ambientes centralizados. Entretanto, no caso das transações globais, essa tarefa é bem mais complicada, já que diversos sites podem participar de sua execução. Uma falha em um desses sites ou uma falha de comunicação entre sites pode resultar em erros de processamento.
2.2.2 Características do ambiente distribuído
O ponto fundamental do sistema distribuído é a sua heterogenia e autonomia para garantir essas características o ambiente sofreu alterações segundo o modelo tradicional:
• Descentralização do controle.
• Replicação total ou parcial dos dados ou particionamento.
• Autonomia para transações locais.
• Independência de site central.
• Independência de localização.
• Transparência de fragmentação.
• Transparência de replicação.
• Independência de sistema operacional (heterogenia).
• Independência da rede.
Um sistema transparente é aquele que esconde do usuário os detalhes de sua implementação e estrutura. Um SGBD trabalha com diferentes tipos de transparência:
O sistema deve prover transparência para o usuário tanto dos serviços prestados pela rede quanto da forma a disponibilizar os dados. A característica de transparência garante que os usuários não tenham que especificar a localização dos dados que querem acessar. Essa característica é subdividida em duas: transparência da localização, diz que um comando usado para executar uma tarefa independe da localização dos dados e do sistema e a transparência de nomes, diz que um objeto possui um nome único em todo banco de dados.
Existem vários níveis para imposição da transparência. Ela pode ser desenvolvida no nível de usuário, através de uma linguagem de programação, o compilador fica responsável em interpretar e de garantir a transparência ao usuário. Também pode ser implementada no nível do sistema operacional. O nível mais utilizado atualmente é implementado no SGBD. Ele depende de diferentes componentes dentro do ambiente de gerenciamento de dados, a transparência de rede é englobada automaticamente pelo SGBD para ser possível garantir transparência para a replicação e partição de dados.
2.2.2.2 Replicação de dados
O sistema mantém várias réplicas idênticas de um item de dado. Cada réplica é armazenada em um site diferente, resultando em replicação de dados.
Se o item de dados r é replicado, uma cópia sua é armazenada em dois ou mais
sites. Em casos mais extremos, existe a replicação total (full replication), em que uma
Há vantagens e desvantagens na replicação, que são:
Disponibilidade . Se um dos sites contém o item de dado r falhar, r pode ser
encontrado em outro site. Assim, o sistema pode continuar a processar consultas envolvendo o item r, apesar da falha de um site.
Aumento do paralelismo. No caso onde a maioria dos acessos ao item de dado
r resulta em uma operação de leitura, vários sites podem processar consultas
envolvendo o item de dado r paralelamente. Quanto mais réplicas de r houver, maior é a chance de que os dados necessários sejam achados no site onde a transação está executando. Portanto, a replicação de dados minimiza o movimento de dados entre os
sites.
Aumento do overhead de atualização. O sistema deve assegurar que todas as
réplicas de um item r estejam consistentes; por outro lado, computações erradas podem acontecer. Assim, toda vez que r é atualizado, a atualização deve ser propagada a todos os sites que contém réplicas. O resultado é um overhead aumentado.
Em geral, a replicação eleva o desempenho de operações de leitura e aumenta a disponibilidade de dados para transações de leitura. No entanto, transações de atualização incorrem em grande overhead. O problema de controlar atualizações concorrentes de várias transações para fazer a replicação de dados é mais complexo que no controle de concorrência em um banco de dados centralizado. Pode-se simplificar o gerenciamento das réplicas do item de dado r, escolhendo uma delas como a principal cópia de r.
2.2.2.3 Fragmentação de dados
O banco de dados é particionado em diversos fragmentos que são armazenados em diferentes sites.
original. Esta reconstrução pode ser feita através da aplicação de uma operação de união ou um tipo especial de junção dos vários fragmentos.
Existem dois esquemas diferentes para fragmentação:
Horizontal. Que consiste em dividir a relação pela associação de cada tupla de r a
um ou mais fragmentos. A relação r é particionada em um número de subconjuntos, r1,
r2, ..., rn. Cada tupla da relação r deve pertencer a um dos fragmentos, para que a
relação original possa ser reconstruída se necessário. Um fragmento pode ser definido como uma seleção sobre a relação global r. Isto é, um predicado Pi é usado para construir o fragmento ri da seguinte forma:
A reconstrução de uma relação r pode ser obtida tomando a união de todos os fragmentos, isto é:
Vertical. Que consiste em dividir a relação pela decomposição de determinadas
colunas em diferentes fragmentos. Cada fragmento ri de r é definido por:
A relação r pode ser reconstruída a partir da junção natural dos fragmentos:
Geralmente, a fragmentação vertical é completada pela adição de um atributo especial, chamado tuple-id. Um tuple-id é um endereço físico ou lógico de uma tupla, que será utilizado para fazer a junção natural que possibilita a reconstrução da relação original.
fragmentação horizontal e vertical na relação r, ou em um fragmento de r que foi previamente obtido.
2.2.2.4 Replicação e fragmentação de dados
Esta é a combinação das duas técnicas descritas acima para replicação de dados e fragmentação de dados, que podem ser aplicadas sucessivamente no mesmo item de dado. Ele é particionado em vários fragmentos. O sistema mantém várias cópias idênticas de cada fragmento. Isto é, um fragmento pode ser replicado; as réplicas do fragmento podem ser fragmentadas; e assim por diante.
2.2.3 Arquitetura de banco de dados distribuído
Três tipos de arquiteturas podem implementar um sistema de banco de dados distribuído (SBDD):
Sistema cliente/servidor. A idéia principal desse esquema é dividir as funções
necessárias para a gerência em duas classes: funções de servidor e funções de cliente isso gera uma arquitetura de dois níveis fácil de ser gerenciada. Todo o processamento de consultas, gerenciamento de transações e gerenciamento de armazenamento é executado no Servidor. O cliente para gerenciar a aplicação e a interface com o usuário possui um módulo responsável pelo gerenciamento dos dados que são mantidos para o cliente figura 2.4.
SGBD Cliente -Software de comunicação -Otimizador de consultas - Gerentes de transação e de recuperação Banco de dados Consult as SQL Resulta dos
Fonte: OZSU,M. Tamer; VALDURIEZ, Patrik. Principles of Distribuited Database Systems New Jersey: Prentice-Hall, 1999. Second Edition.
Figura 2-1 Arquitetura de referência cliente/servidor
Existem vários tipos de arquiteturas cliente/servidor. A mais simples possui somente um servidor e vários clientes (múltiplos clientes - único servidor). Diferencia-se dos tradicionais sistemas de banco de dados centralizados somente pela forma de execução e gerenciamento das transações. Ela pode acarretar alguns problemas como:
• Congestionamento no servidor.
• Se o servidor falhar todo o banco de dados para.
A arquitetura mais sofisticada possui vários clientes e vários servidores (múltiplos clientes - múltiplos servidores). Neste caso duas estratégias de gerenciamento são possíveis: cada cliente gerencia sua conexão com o servidor que deseja acessar ou cada cliente conhece somente o “seu” servidor e esse é responsável pela comunicação com outros servidores quando for necessário.
Aplicações Serviços de Cliente Comunicação Comunicação Serviços SGBD Comunicação Serviços SGBD BD BD REDE Múltiplos Clientes/Múltiplos Servidores Aplicações Serviços de Cliente Comunicação Comunicação Serviços SGBD Comunicação Serviços SGBD BD BD REDE Servidor-para-Servidor
Fonte:Mestrado Ciência da Computação UFSC. Disciplina Banco de dados Distribuídos, Professor Murilo S. Camargo. Novembro, 1999.
Figura 2-2 Arquiteturas cliente-servidor
Sistema distribuído ponto – a – ponto. A organização física dos dados em cada
máquina pode ser, e provavelmente é diferente; então existe a necessidade da definição de um Esquema Interno Individual (LIS) para cada site. A visão organizacional dos dados é descrita pelo Esquema Conceitual Global (GCS) que é global porque descreve a estrutura lógica dos dados de todos os sites. Existe ainda a necessidade de uma terceira camada na arquitetura, a do Esquema Conceitual Local (LCS) e as aplicações e os acessos do usuário ao banco de dados estão organizados e gerenciados pelos Esquemas Externos (ESs). Nessa arquitetura o GCS é a união dos LCSs.
Fonte: OZSU, M. Tamer; VALDURIEZ, Patrick. Principles of Distribuited Database Systems. New Jersey: Prentice-Hall, 1999. Second Edition.
ES1 ES2 ESn
GCS LISn LIS2 LIS1 LCSn LCS2 LCS1 Legenda ES - EsquemasEsterno GCS - Esquema Conceitual Global LCS - Esquema Conceitual Local
LIS - Esquema Interno Individual
Figura 2-3 Arquitetura de referência banco de dados distribuído
Arquitetura de sistemas multibanco de dados - MDBS. As diferenças nos
níveis de autonomia entre os multibanco de dados distribuídos (MBDD) e os banco de dados distribuídos (BDD) são refletidas no seu modelo de arquitetura. A diferença fundamental esta na definição do GCS. Nos BDD o GCS define uma visão organizacional dos dados do banco de dados, enquanto no MBDD ele representa somente a coleção de alguns BD locais que cada SGBD deseja compartilhar.
• Modelo de arquitetura MDBS usando GCS. Nesse esquema o GCS é definido como integrante tanto dos esquemas locais de banco de dados quanto parte de seus esquemas conceituais locais. O projeto do GCS em um multibanco de dados envolve a integração dos seus LCS e LES. Não é necessário para o GES e para o GCS serem definidos com o mesmo modelo e linguagem de dados. Se existirem sistemas heterogêneos, existirão duas implementações alternativas: Unilingual e Multilingual. Na unilingual é exigida a utilização de diferentes modelos e linguagens de dados quando os diferentes banco de dados, local e global forem
acessados. A figura 2.7 mostra um modelo datalógico de um sistema unilingual que integra os esquemas LCS (ou parte dele) em um GCS. Na alternativa multilingual a filosofia é permitir o acesso a cada usuário ao banco de dados global (de qualquer outro banco de dados) através de um esquema externo definido por uma linguagem do usuário local.
GES1
LES11 LES12 LES13 GCS
GES3 GES2
LESn1 LESn2 LESnm
LCS1
LIS1
LCSn
LISn
Fonte: OZSU, M. Tamer; VALDURIEZ, Patrick. Principles of Distribuited Database Systems. New Jersey: Prentice-Hall, 1999. Second Edition. GES - Esquema Global Esterno LES - Esquema Local Externo LCS - Esquema Conceitual Local LIS - Esquema Interno Individual
Figura 2-4 Arquitetura MDBS com GCS
• Modelo de arquitetura MDBS não usando GCS. A arquitetura mostrada na figura 2.8 identifica duas camadas: a camada do sistema local e a camada do multibanco de dados. A camada do sistema local consiste de vários SGBD que está presente na camada MBD parte do seu banco de dados locais que desejam compartilhar com os usuários de outros bancos de dados. Se existir heterogeneidade cada esquema LCS pode usar um diferente modelo de dados [Litwin, 1998].
ES1 ES2 ES3 LCS2 LCS3 LCS1 LIS3 LIS2 LIS1 Camada sistema Local Camada Multibanco de dados
Fonte: OZSU, M. Tamer; VALDURIEZ, Patrick. Principles of Distribuited Database Systems. New Jersey: Prentice-Hall, 1999. Second Edition.
ES - Esquema Externo LCS - Esquema Conceitual Local LIS - Esquema Interno Individual
Figura 2-5 Arquitetura MDBS sem GCS
2.2.4 Internet
Como modelo de computação distribuída podemos incluir a Internet que também pode ser vista como um ambiente cliente-servidor. O cliente, normalmente conhecido como browser, comunica-se com o servidor, que é nesse ambiente chamado de servidor de páginas. A integração é garantida por gateways, ele é um software especial que fornece às aplicações cliente uma interface que garante que várias fontes distintas de dados pareçam equivalentes.
O acesso a esses servidores é feito através de um protocolo especial chamado http (Hyper text transfer protocl). Os dados requisitados pelos clientes são armazenados sob forma de arquivos (páginas), desenvolvidos em linguagem própria html (Hyper test
Cliente
Aplicação
servidora ServidorBD
Rede Rede
Figura 2-1 Arquitetura cliente-servidor Internet
Na Internet o cliente é sempre considerado universal. Isso conduz a uma nova arquitetura cliente-servidor (Fig 2.9). Na arquitetura tradicional o servidor executa os programas de banco de dados, e o cliente executa as aplicações e a interface gráfica , o aumento do numero de aplicações e de programas deixariam os clientes pesados, exigindo mais armazenamento e mais processamento.
Na arquitetura proposta para Internet (equivalente à arquitetura múltiplos-servidores/múltiplos clientes), uma aplicação servidora é introduzida para executar as aplicações. O cliente é um browser dedicado para interfaces gráficas. As aplicações lógicas que podem ser necessitadas pelo cliente são suportadas por applets (pequeno programa escrito em JAVA inserido em uma página da Internet). Assim, o cliente não precisa de muito poder computacional. Essa arquitetura pode ser generalizada para possuir n-camadas com várias aplicações servidoras.
A figura 2.10 ilustra esta generalização permitindo o acesso ao banco de dados de um servidor Internet exatamente como faz um sistema de gerencia de banco de dados [Özsu e Valduriez, 1999].
Servidor BD Servidor gateway Web browser Entradas + url Formulario html Consulta Chama consulta Tuplas Formulário html Servidor WEB
Figura 2-2 Acesso a BD por servidor Internet
2.2.4.1 Gateways de banco de dados
Os gateways permitem interoperabilidade entre banco de dados e a Internet, possibilitando que as aplicações clientes conectem-se a múltiplas fontes distintas de dados. O gateway de banco de dados é um software especial que fornece às aplicações cliente uma interface que permite que várias fontes distintas de dados pareçam equivalentes.
Um gateway de banco de dados consiste nos seguintes componentes:
• Biblioteca de API do Cliente: A API do cliente que determina o formato e o significado dos pedidos que as aplicações de cliente possam emitir.
• Biblioteca de API do Servidor: A API do servidor de banco de dados que determina qual os serviços disponíveis aos clientes do banco de dados. Estes serviços de banco de dados estão disponíveis em condições especificadas pelo fabricante do DBMS.
