Aula 9_SBDD_2019

Prévia do material em texto

4/23/2020
1
SBDD – Sistemas de Base de Dados 
Distribuída
▪ Introdução
▪ Conceitos Relacionados
▪ Características de uma BDD
▪ Vantagens e desvantagens de uma BDD
▪ Funções e Arquitectura de um SGBDD
▪ Desenho de uma BDD
▪ Fragmentação e Replicação
▪ Processamento Distribuído de Consultas
▪ Transparência
▪ Concorrência e Recuperação em BDD
1Dra. Otília F. da Graça
SBDD – Introdução
▪ Estrutura das Organizações - há necessidade de 
integrar dados operacionais de uma organização 
▪ Acesso Dificultado - há necessidade de 
providenciar acesso controlado aos dados
▪ Desenvolvimento de Redes - promove a 
descentralização no trabalho
▪ Grande Volume de Dados - sistemas distribuídos 
ajudam a resolver o problema de ilhas de informação
2Dra. Otília F. da Graça
1
2
4/23/2020
2
SBDD – Introdução
Aplicações
• Companhias Aéreas
• Redes de Lojas
• Cadeias de Hotéis
• ..........
Qualquer organização 
com estrutura descentralizada
3Dra. Otília F. da Graça
Conceitos
Base de dados distribuída – uma colecção de dados 
partilhados, logicamente relacionados, fisicamente 
distribuídos através de uma rede de computadores.
Sistema de gestão de base de dados distribuída –
um sistema de software que permite a gestão de base de 
dados distribuída e faz a distribuição transparente aos 
utilizadores.
Sistema de Base de dados distribuída – SGBDD + 
BDD
4Dra. Otília F. da Graça
3
4
4/23/2020
3
Conceitos
Sistema de Base de Dados Distribuída
5Dra. Otília F. da Graça
Conceitos
O que está distribuído?
o Lógica de Processamento
o Funções
o Dados
o Controle
6Dra. Otília F. da Graça
5
6
4/23/2020
4
Conceitos
Processamento distribuído – uma base de dados 
centralizada que pode ser acedida através de uma rede de 
computadores.
7Dra. Otília F. da Graça
Conceitos
▪ Sistema Centralizado
– Performance comprometida
– Baixa disponibilidade
– Facilidade de manutenção
▪ Sistema de Base de Dados Distribuída
– Facilidade de acesso
– Tolerância a falhas
– Processamento optimizado de consultas 
8Dra. Otília F. da Graça
7
8
4/23/2020
5
SBDD - Características
▪ Dados armazenados em diversos locais (ou nós)
▪ cada nó é logicamente um processador
▪ diferente distância geográfica
▪ Processadores interconectados através de rede
▪ A base de dados distribuída não é uma colecção de arquivos
▪ O SGBDD possui toda a funcionalidade de um SGBD
▪ Tecnologia actual
▪ multiprocessadores
▪ memória compartilhada (shared-memory ou shared-everything)
▪ disco compartilhado (shared-disk)
▪ nada compartilhado ou memória distribuída (shared-nothing)
▪ cliente-servidor
▪ clusters, GRIDs
9Dra. Otília F. da Graça
Vantagens de um SBDD
▪ Partilha de dados e autonomia local: Existe um 
administrador global, responsável pelo sistema como um 
todo, mas parte das responsabilidades são delegadas a 
administradores locais que gozam de certa autonomia;
▪ Melhor desempenho no processamento de consultas: 
Sub-consultas podem ser executadas em paralelo;
▪ Fiabilidade/disponibilidade melhoradas: o sistema 
funciona conforme o projecto e está disponível por mais 
tempo;
▪ Maior escalabilidade: É mais fácil acrescentar um nó, 
desde que os mesmos sejam autónomos, do que substituir 
um sistema centralizado existente por um maior.
10Dra. Otília F. da Graça
9
10
4/23/2020
6
Desvantagens de um SBDD
▪ Custos de desenvolvimento do Software: A alta 
complexidade torna mais difícil implementar um SGBDD, 
tornando-o mais caro;
▪ Maior possiblidade de erros : Ocorrência de erros 
muito subtis na colaboração entre os nós do SGBDD;
▪ Aumento da carga de processamento: Devido à troca 
de mensagens e à computação adicional para obter a 
coordenação entre os nós;
▪ Aumento da complexidade para assegurar a 
coordenação adequada dos nós: Por exemplo, controle de 
concorrência entre transações distribuídas e detecção de 
deadlock.
11Dra. Otília F. da Graça
Tipos de SBDD
▪ Homogénea: composta por várias bases de dados idênticas e 
distribuídas através de uma rede e com equipamentos de igual 
arquitectura. Todos os nós têm o mesmo SGBD.
▪ Heterogénea: 
▪ Cada nó pode conter um ou mais SGBDs locais; 
▪ Partilham BDs pré existentes com esquemas conceptuais 
diferentes;
▪ Vantagens:
▪ Preserva-se o investimento existente em hardware, software de 
sistema e aplicações;
▪ Autonomia local e controlo administrativo;
▪ Permite o uso de SGBDs dedicados;
▪ É uma passo no sentido de uma unificação homogénea de 
SGBDs.
12Dra. Otília F. da Graça
11
12
4/23/2020
7
SGBDD – Funções
▪ Funcionalidade de um SGBD mais 
▪ Extensos serviços de comunicação para providenciar 
acesso a sites remotos e permitir transferência de 
consultas e dados entre os sites usando uma rede;
▪ Extenso sistema de catálogo para armazenar detalhes de 
distribuição de dados;
▪ Processamento de consultas distribuídas, incluindo 
optimização de consultas e acesso remoto a dados;
▪ Extenso controlo de concorrência para manter 
consistência de dados replicados;
▪ Extenso serviço de recuperação por causa de falhas de 
sites individuais e de falhas em links de comunicação.
13Dra. Otília F. da Graça
SGBDD
Em 1987, C. J. Date, um dos primeiros projectistas de 
bases de dados relacionais, junto com o Dr. E. F. Codd, 
autor da teoria relacional, propôs 12 regras que um 
SGBDD completo deveria seguir.
14Dra. Otília F. da Graça
13
14
4/23/2020
8
As 12 Regras para SGBDD
1. Autonomia local: Cada nó participante de um sistema distribuído 
deve ser independente dos outros nós. Cada nó deve prover 
mecanismos de segurança, bloqueio, acesso, integridade e 
recuperação após falha.
2. Não dependência de um nó central: Um sistema de base de 
dados distribuída não deve depender de um nó central, pois isso 
acarretaria um único ponto de falha, afectando todos os outros nós. 
Um nó central também poderia ficar sobrecarregado resultando em 
perda de desempenho do sistema.
3. Operação contínua: Um sistema de base de dados distribuída 
nunca deve precisar de ser desactivado. As operações de backup e 
recuperação devem ser suportadas on-line. Essas operações devem 
ainda ser bastante rápidas para não afectarem o funcionamento do 
sistema (backup incremental, por exemplo).
15Dra. Otília F. da Graça
As 12 Regras para SGBDD (cont.)
4. Transparência/independência de localização: Os usuários do 
sistema não devem precisar de saber o local onde estão localizados 
os dados; devem -se comportar como se os dados estivessem 
armazenados localmente.
• A transparência de localização pode ser alcançada pela utilização de 
sinónimos estendidos e pelo extenso uso do dicionário de dados.
• A transparência de localização permite que aplicações sejam transportadas 
de um nó da rede para outro sem a necessidade de modificações.
5. Independência de fragmentação: As tabelas que fazem parte de 
um sistema de base de dados distribuída podem estar divididas em 
fragmentos, localizados fisicamente em diferentes nós, de forma 
transparente para o usuário.
6. Independência de replicação: Dados podem estar replicados em 
vários nós da rede, de forma transparente. As réplicas de dados 
devem ser mantidas sincronizadas automaticamente pelo SGBDD
16Dra. Otília F. da Graça
15
16
4/23/2020
9
As 12 Regras para SGBDD (cont.)
7. Processamento distribuído de consultas : O desempenho de uma 
consulta deve ser independente do local onde a mesma é submetida. 
Um SGBDD deve possuir um otimizador capaz de seleccionar não 
apenas o melhor caminho para o acesso a um determinado nó da 
rede, mas também optimizar o desempenho de uma consulta 
distribuída, levando em conta a localização dos dados, utilização de 
CPU, I/O e o tráfego na rede.
8. Gestão de transações distribuídas: Um SGBDD deve suportar 
transações atómicas. As propriedades ACID (Atomicidade, 
Consistência, Independência e Durabilidade) das transações e a 
serialização devem ser suportadas não apenas para transaçõeslocais, 
mas também para transações distribuídas.
9. Independência de hardware: Um SGBDD deve poder operar e 
acessar dados numa variedade de plataformas de hardware. Um 
SGBDD verdadeiro não deve depender de uma determinada.
17Dra. Otília F. da Graça
As 12 Regras para SGBDD (cont.)
10.Independência de sistema operacional: Um SGBDD deve poder 
correr em sistemas operacionais diferentes. Assim como na regra 
anterior, um SGBDD não deve depender de um sistema operacional 
em especial.
11.Independência de rede: Um SGBDD deve ser projetado para 
correr independentemente do protocolo de comunicação e da 
topologia de rede usada para interligar os vários nós que fazem parte 
da rede.
12.Independência de SGBD: Um SGBDD ideal deve possuir 
capacidade para se comunicar com outros sistemas de gestãode base 
de dados correndo em nós diferentes, mesmo se estes sistemas de 
bases de dados são diferentes (heterogéneos). Todos estes sistemas 
devem usar APIs.
As 4 últimas são as mais importantes
18Dra. Otília F. da Graça
17
18
4/23/2020
10
Arquitectura de um SBDD
• Um conjunto de esquemas externos global;
• Um esquema conceptual global – descrição lógica 
de toda a bd como se não fosse distribuída;
• Um esquema de fragmentação – descrição de 
como os dados hão-de ser logicamente partilhados e 
esquema de alocação – descrição de onde os dados 
hão-de estar localizados;
• Um conjunto de esquemas para cada SGBD local, 
conforme a arquitectura de 3 níveis da Ansi-Sparc –
cada SGBD local tem o seu próprio esquema
19Dra. Otília F. da Graça
Arquitectura de um SBDD
20Dra. Otília F. da Graça
19
20
4/23/2020
11
Componentes da arquitectura de um SBDD
• SGBD local – responsável por controlar os dados 
locais em cada site que tem uma BD;
• Comunicação de dados – software que permite 
todos os sites se comunicarem; contém informação 
sobre os sites e links
• Sistema de catálogo global – armazena 
informação, tal como esquemas de fragmentação;
• SGBDD – unidade de controlo para todo o 
sistema
21Dra. Otília F. da Graça
Componentes da arquitectura de um SBDD
22Dra. Otília F. da Graça
21
22
4/23/2020
12
Desenho de uma BD relacional distribuída
▪ O projecto do esquema conceptual global e o dos esquemas 
externos globais é inteiramente semelhante ao projecto de BD 
centralizada, já que a base de dados distribuída deverá se 
comportar como centralizada perante os utilizadores globais. 
▪ O projecto dos esquemas internos locais é também idêntico 
ao de bases de dados centralizadas, excepto que a carga 
imposta por acessos remotos aos dados locais também deve ser 
levada em consideração. 
▪ O problema básico de projecto de bases de dados 
distribuídas reside no projecto dos esquemas conceptuais 
locais, pois estes refletem a estratégia de distribuição da base 
de dados.
23Dra. Otília F. da Graça
Desenho de uma BD relacional distribuída
Factores adicionais a considerar numa base de 
dados relacional distribuída:
– Fragmentação - uma relação pode ser dividida num 
número de sub-relações chamadas fragmentos, que são 
depois distribuídos
– Alocação – cada fragmento é armazenado num site 
com distribuição óptima
– Replicação – uma cópia de um fragmento pode ser 
mantida em vários sites
24Dra. Otília F. da Graça
23
24
4/23/2020
13
Desenho de uma BD relacional distribuída
25Dra. Otília F. da Graça
Fragmentação
Porque fragmentar?
• Usabilidade – é melhor trabalhar com subconjuntos de 
relações como unidade de distribuição;
• Eficiência – dados são armazenados onde são mais 
frequentemente usados;
• Paralelismo – uma consulta pode ser dividida em várias 
subconsultas que operam sobre fragmentos
• Segurança – dados não necessários por aplicação local 
não estão armazenados e por isso não disponíveis a 
utilizadores não autorizados
26Dra. Otília F. da Graça
25
26
4/23/2020
14
Fragmentação
Duas desvantagens:
– Desempenho – o desempenho de aplicações que 
necessitam de dados de vários fragmentos pode ser 
baixo;
– Integridade – controlo de integridade pode ser mais 
difícil se dados e dependências funcionais estão 
fragmentados e em diferentes sites.
27Dra. Otília F. da Graça
Fragmentação
3 regras devem ser seguidas durante a fragmentação:
– Completeness (completude) – se uma relação R é 
decomposta em fragmentos R1, R2, ... Rn, cada dado de 
R deve aparecer em pelo menos um fragmento;
– Reconstrução – deve ser possível definir uma operação 
relacional que reconstrua a relação R a partir dos 
fragmentos;
28Dra. Otília F. da Graça
27
28
4/23/2020
15
Fragmentação
- Disjointness – Se um dado aparece num 
fragmento, então ele não deve aparecer em mais 
nenhum fragmento.
Excepção:
• Fragmentação vertical, atributos chave primária deve
ser repetida para permitir reconstrução.
• Fragmentação horizontal, dado é uma tupla.
• Fragmentação vertical, dado é um atributo.
29Dra. Otília F. da Graça
Fragmentação
Tipos de fragmentação:
– Horizontal – consiste num subconjunto de tuplas de 
uma relação, usa o operador ???? da AR
– Vertical – consiste num subconjunto de atributos de 
uma relação, usa operador ??? da AR
– Mista – consiste de um fragmento horizontal que é 
subsequentemente verticalmente fragmentado, ou um 
fragmento vertical que é horizontalmente fragmentado, 
usa os operadores ???? da AR
– Derivada – é um fragmento horizontal baseado numa 
fragmentação horizontal de uma relação pai, usa 
operador ???? da AR
30Dra. Otília F. da Graça
29
30
4/23/2020
16
Fragmentação Horizontal e Vertical
31Dra. Otília F. da Graça
Fragmentação Mista
32Dra. Otília F. da Graça
31
32
4/23/2020
17
Fragmentação
Como decidir que fragmentação?
Analisar a relação, de forma a decidir quais devem ser 
fragmentadas ou mantidas e que tipo de fragmentação
– se uma relação contém poucas tuplas e não é muito 
actualizada, é melhor replicar a relação em cada site;
– se uma relação é um por um, pensar qual o melhor 
esquema de fragmentação;
– se uma relação é um por muitos, é melhor 
fragmentação derivada
33Dra. Otília F. da Graça
Alocação
▪ Centralizada – uma única BD e SGBD armazenados num 
site com utilizadores distribuídos pela rede
– localidade de referência é muito baixo
– custo de armazenamento são muito baixos
– custos de comunicação são muito altos
– confiabilidade e disponibilidade são muito baixos
– desempenho não satisfatório
▪ Fragmentada – parte a base de dados em fragmentos 
disjuntos, cada fragmento é assignado a um site
– localidade de referência é alto, os dados são muito usados
– custos de armazenamento são muito baixos
– confiabilidade e disponibilidade são baixos para dado e alto para o 
sistema
– custo de comunicação baixo
34Dra. Otília F. da Graça
33
34
4/23/2020
18
Alocação
▪ Replicação completa – manter uma cópia completa da BD 
em cada site
– localidade de referência muito alta 
– custos de comunicação são muito alto
– custo de armazenamento são muito alto
– confiabilidade e disponibilidade são altos
▪ Replicação selectiva – combinação de fragmentação, 
replicação e centralização
– localidade de referência é alto
– custos de armazenamento são médio 
– custo de comunicação é baixo
– confiabilidade e disponibilidade são baixos para dados, alto para 
o sistema
35Dra. Otília F. da Graça
Alocação
36Dra. Otília F. da Graça
35
36
4/23/2020
19
Técnicas de Alocação
37Dra. Otília F. da Graça
▪ A estrutura da organização define o caminho 
para a distribuição
▪ Integração de múltiplas BDs
▪ Diccionário de dados global
▪ Particionamento de uma BD centralizada
▪ Alocação de fragmentos a serem movidos
Actualização dos dados replicados
38Dra. Otília F. da Graça
▪ Replicação síncrona: Todas as cópias de uma relação
modificada (fragmentos) devem ser actualizadas antes da
transacção modificante fazer commit
– A distribuição de dados fica transparente para o 
usuário
▪ Replicação Assíncrona: As cópias da relação 
modificada só sãoactualizadas periodicamente; réplicas
podem ficar inconsistentes por algum tempo
– Os usuários devem estar cientes da distribuição e 
replicação
37
38
4/23/2020
20
Processamento de consultas em SGBDD
39Dra. Otília F. da Graça
Deve ter em conta:
• Réplicas dos dados
• Reconstrução de relações a partir de fragmentos
• Tempo de recuperação
• Tempo de processamento
• Transmissão de dados via rede
Transparência em SGBDD
40Dra. Otília F. da Graça
▪ A transparência “oculta” dos utilizadores os detalhes 
de implementação, é a separação entre a semântica de alto 
nível de um sistema e seus detalhes de implementação.
▪ A questão fundamental é prover Independência de 
dados no ambiente distribuído.
▪ Desta forma, os utilizadores da base de dados 
enxergariam uma única imagem da base de dados 
logicamente integrada, embora ela estivesse fisicamente 
distribuída.
39
40
4/23/2020
21
Transparência em SGBDD
41Dra. Otília F. da Graça
▪ Um sistema pode ser fragmentado e replicado, ou seja, 
uma relação pode ser particionada e cada uma dessas 
partições ser armazenada em locais distintos, isto é 
fragmentação. 
▪ Alguns desses dados podem ser duplicados em outros 
lugares por razões de confiabilidade e desempenho, isto é 
replicação de dados
▪ Resultado: uma base de dados distribuída que é 
fragmentada e replicada.
▪ Por isso, o sistema deve ser capaz de lidar com 
vários tipos de transparências
Transparência em SGBDD
42Dra. Otília F. da Graça
▪ Transparência na Distribuição
• Transparência na Fragmentação
• Transparência na Alocação
• Transparência na Replicação
• Transparência no Mapeamento Local
• Transparência na Nomeação
▪ Transparência da transacção
• Transparência na Concorrência
• Transparência na Falha
▪ Transparência no desempenho
41
42
4/23/2020
22
Transparência na distribuição
43Dra. Otília F. da Graça
▪ Transparência na Distribuição permite o utilizador
perceber a base de dados como uma única entidade lógica.
▪ Se SGBDD exibe transparência na distribuição,
utilizadores não necessitam de saber:
▪ se os dados estão fragmentados - Transparência na
Fragmentação,
▪ a localização dos dados - Transparência da
Localização,
▪ Caso contrário chamamos Transparência do
Mapeamento Local.
▪ Transparência na Replicação - o utilizador não
percebe a replicação dos fragmentos .
Transparência na distribuição
44Dra. Otília F. da Graça
▪ Transparência na Nomeação
▪ Cada item numa BDD deve ter um único nome.
▪ SGBDD deve assegurar que não existem dois sites
a criarem um objecto de base de dados com o mesmo
nome.
▪ Uma solução é criar um servidor de nomes central.
Contudo, isso resulta em:
▪ Perda de alguma autonomia local;
▪ No site central pode haver engarrafamento;
▪ Baixa disponibilidade; se o site central falha,
sites remanescentes não podem criar novos
objectos.
43
44
4/23/2020
23
Transparência na Nomeação
45Dra. Otília F. da Graça
▪ Solução alternativa – colocar um prefixo nos
objectos – um identificador do site que o criou.
▪ Por exemplo, Branch criado no site S1 pode ser
nomeado S1.BRANCH.
▪ Também necessita-se de identificar cada fragmento
e suas cópias.
▪ Assim, cópia 2 do fragmento 3 do Branch criado na
site S1 pode ser referido como S1.BRANCH.F3.C2.
▪ Contudo, isto resulta na perda da transparência na
distribuição.
Transparência na Nomeação
46Dra. Otília F. da Graça
▪ Uma forma de resolver estes problemas é usar álias
para cada objecto da base de dados.
▪ Assim, S1.BRANCH.F3.C2 pode ser conhecido
como LocalBranch pelo utilizador do site S1.
▪ SGBDD tem a tarefa de mapear alias para
apropriados objectos de base de dados
45
46
4/23/2020
24
Transparência na Transacção
47Dra. Otília F. da Graça
▪ Assegura que todas as transacções distribuídas
mantenham integridade e consistência de base de dados
distribuída.
▪ Transacção distribuída acessa dados armazenados
em mais do que um local.
▪ Cada transacção está dividida num número de
subtransacções, uma para cada site que tem de ser
acessado.
▪ SGBDD deve assegurar a indivisibilidade de ambos
transacção global e cada uma das subtransacções.
Transparência na Concorrência
48Dra. Otília F. da Graça
▪ Todas as transacções devem executar-se
independentemente e estarem logicamente consistentes
com resultados obtidos
▪ Os mesmos princípios fundamentais como para
SGBD centralizada.
▪ SGBDD deve assegurar que ambas as transacções
global e local não interferem umas com as outras.
▪ SGBDD deve assegurar consistência de todas
subtransacções da transacção global.
47
48
4/23/2020
25
Transparência na Concorrência
49Dra. Otília F. da Graça
▪ Replicação torna concorrência mais complexa.
▪ Se uma cópia de um dado replicado é actualizada,
actualização deve ser propagada a todas as cópias.
▪ Pode-se propagar mudanças como parte da
transacção original, tornando-a uma operação atómica.
▪ Contudo, se um site armazenando uma cópia não
está disponível, então a transacção é atrasada até que o
site esteja disponível.
Transparência na Concorrência
50Dra. Otília F. da Graça
▪ Pode limitar-se a propagação de actualização a
apenas aqueles sites disponíveis no momento. Restantes
sites serão actualizados quando se tornarem disponíveis.
▪ Pode permitir-se actualização de cópias
acontecerem assíncronamente, algumas vezes depois da
actualização original. Demora no ganho de consistência
pode variar de poucos segundos a várias horas.
49
50
4/23/2020
26
Transparência na Falha
51Dra. Otília F. da Graça
▪ SGBDD deve assegurar atomicidade e durabilidade
de transacção global.
▪ Significa assegurar que subtransacções de
transacção global ou são todas gravadas ou todas
abortadas.
▪ SGBDD deve sincronizar transacção global para
assegurar que todas subtransacções tenham-se
completado com sucesso antes de acontecer o COMMIT
final para transacção global.
▪ Deve fazer-se quando acontecem falhas no site e
rede.
Transparência no Desempenho
52Dra. Otília F. da Graça
▪ SGBDD deve trabalhar como se fosse um SGBD
centralizado.
▪ SGBDD não deve sofrer qualquer degradação no
desempenho devido à arquitectura distribuída.
▪ SGBDDS deve determinar uma estratégia mais
custo-efectivo para executar um pedido.
▪ Processador de Consultas Distribuído (DQP)
mapeia pedido de dados na sequência ordenada de
operacões na base de dados local.
▪ Deve considerar-se esquemas de fragmentação,
replicação, e alocação.
51
52
4/23/2020
27
Transparência no Desempenho
53Dra. Otília F. da Graça
▪ O processador de consultas distribuído tem de decidir:
▪ que fragmento acessar;
▪ que cópia de um fragmento usar;
▪ que locação usar.
▪ DQP produz estratégia de execução optimizada
relativente a alguns custos.
▪ Normalmente, custos associados com um pedido
distribuído incluem:
▪ Custo de I/O;
▪ Custo do CPU;
▪ Custo de comunicação.
Processamento Distribuído de Consultas
• Num sistema de base de dados distribuída, podem 
ocorrer consultas distribuídas, ou seja, consultas que 
acessem mais de uma base de dados remota ou local, assim 
os SGBDDs possuem mecanismos para processar estas 
consultas distribuídas
• Uma consulta distribuída é decomposta pelo Oracle local 
num número correspondente ao número de consultas 
remotas, as quais são enviadas para o site remoto para serem 
executadas; o site remoto executa estas consultas e retorna o 
resultado para o site em que foram feitas as consultas.
54Dra. Otília F. da Graça
53
54
4/23/2020
28
Processamento Distribuído de Consultas
Decomposição de Consulta SQL - Quando uma consulta faz 
referência a várias tabelas, o optimizador precisa determinar 
quais colunas pertencem a qual tabela antes de decompor a 
consulta. 
Por exemplo:
SELECT DNAME, ENAME
FROM DEPT, EMP@REMOTE
WHERE DEPT.DEPTNO = EMP.DEPTNO
• Primeiro o optimizador verifica que a coluna DNAME pertence à tabela local 
DEPT e que a coluna ENAME pertence à tabela remota EMP; uma vez que ele 
possui informações atravésdo DD de todas as tabelas remotas, a consulta pode ser 
decomposta.
• O optimizador decompõe a consulta em outras consultas separadas que serão 
enviadas para serem executadas em diferentes bases de dados; depois os dados 
resultantes são juntos localmente. Tudo isto é feito de forma automática e 
transparente para o utilizador. 
55Dra. Otília F. da Graça
Processamento Distribuído de Transacções
• O Oracle automaticamente controla e monitora commits e 
rollbacks de uma transação distribuída e mantém a 
consistência e integridade das bases de dados utilizando 
um mecanismo de gestão de transação como o protocolo 
Two-Phase Commit(2PC). Este mecanismo é totalmente 
transparente ao usuário.
• Exemplo de uma transação distribuída, sendo executada no site 
FILIALA.ISCTEM.AC.MZ:
BEGIN
UPDATE scott.estoque
SET preco_venda = preço_venda*1,1
UPDATE scott.estoque@ filiala.isctem.ac.mz
SET preco_venda = preço_venda*1,2
UPDATE scott.estoque@ filiala.isctem.ac.mz
SET preco_venda = preço_venda*1,3
END;
COMMIT;
56Dra. Otília F. da Graça
55
56
4/23/2020
29
Processamento Distribuído de Transacções
• Para garantir a consistência e integridade de uma transação 
distribuída, o Oracle utiliza o 2PC da seguinte forma: 
• Na primeira fase, a fase de preparação, o coordenador global (site 
que iniciou a transação) envia uma mensagem a todos os sites 
participantes da transação para que eles fiquem preparados para 
realizar commit da transação e fica aguardando que cada um 
responda a esta solicitação; os sites podem enviar três tipos de 
respostas:
– Preparado: Todos os dados referenciados no site pela transação já foram 
modificados e o site está pronto para finalizar a transação;
– Somente para leitura: Os dados não podem ser modificados, pois é somente 
para leitura, neste caso ele não participa mais da transação;
– Abortar: Ocorreu um erro e o site não está preparado para terminar a 
transação com êxito.
57Dra. Otília F. da Graça
Processamento Distribuído de Transacções
• Na segunda fase, a fase do commit, quando todos sites 
responderem que estão preparados, o coordenador geral 
envia uma mensagem para que todos possam efectuar o 
commit da transação, ou seja, em cada site o SGBD faz o 
commit da parte local da transação
• Assim, no final do Two-Phase commit os dados em todos 
os sites serão consistentes.
58Dra. Otília F. da Graça
57
58
4/23/2020
30
Controle de Concorrência
• O Oracle mantém a concorrência, integridade e 
consistência dos dados utilizando um modelo de controle 
de concorrência multiversão, além de vários tipos de 
bloqueios e transacções. O controle de concorrência 
multiversão armazena diferentes versões do mesmo 
registo, assim há uma melhoria no acesso concorrente aos 
dados contidos na base de dados.
• A consistência numa transacção é garantida pelo Oracle 
através de informações que são armazenadas em 
segmentos de Rollback. 
• O segmento de Rollback é uma porção da base de dados que regista 
as imagens dos dados antes de serem modificados por uma 
transação, permitindo que as alterações sejam desmanchadas (ou 
desfeitas) sob certas circunstâncias.
59Dra. Otília F. da Graça
59