Processamento de Transações, Recuperação de Dados e Controlo de Concorrência

UNIVERSIDADE POLITÉCNICA

APOLITECNICA
Escola Superior de Gestão, Ciências e Tecnologias
Docente: Mestre Simão Chinama
Sistema de Gestão de Bases de Dados II

Ano Lectivo 2017
Segundo Semestre
Cap. 1
Processamento de Transacções,
Recuperação de Dados e Controlo de
Concorrência
2
Cap. 1
Processamento de Transacções, Recuperação de Dados e Controlo
de Concorrência
“I always say, keep a diary and someday it’ll keep you.”
-- Mae West
Sumário
Introdução às transacções. Propriedades ACID.
Requisitos para a consistência duma base de dados.
Transacção como unidade de recuperação de dados.
Situações que requrem recuperação de dados.
Recuperação a partir duma falha numa transacção.
Estados da transacção. Entradas no system log.
Execução duma transacção. Operações de R/W duma transacção.
Checkpoints no system log. Logging com escrita à cabeça (Write Ahead
Logging).
Transacção como unidade de concorrência.
Algoritmos de escalonamento de transacções.
Escalas de transacções. Métodos de serialização/seriabilidade.
Técnicas de trancamento (Locking) para controlo de concorrência.
Tipos de fechos/trancamentos. Fechos e seriabilidade.
3
Cap. 1
Processamento de Transacções, Recuperação de Dados e Controlo
de Concorrência
“I always say, keep a diary and someday it’ll keep you.”
-- Mae West
Sumário
“Deadlocks” e “livelocks”.
Outras estratégias de controlo da concorrência e recuperação de dados.
4
1. O que é uma transacção?
Uma transacção é uma unidade lógica básica de

execução num sistema de informação. É uma
sequência de operações que são executadas como
um todo que leva uma base de dados dum estado
consistente para outro.
Uma unidade indivisível de processamento
5
1. O que é uma transacção?
base de dados num base de dados num
estado consistente estado consistente
Transferência
Conta A João Alfredo 1000,00MT 500,00MT Conta A João Alfredo 500,00MT
Conta B Luís Sabão 500,00MT

Conta B Luís Sabão 0,0MT
Begin transaction Execução da transacção end transaction

A base de dados pode
ficar temporariamente
num estado inconsistente
durante a execução

6
2. Propriedades ACID das transacções

Para preservar a integridade dos dados, o DBMS tem de assegurar:
Atomicidade. Uma transacção é unidade atómica de

processamento que é realizada completamente ou, simplesmente,
não é realizada.

Consistência. A execução isolada duma transacção (i.e. com
nenhuma outra transacção a executar concorrentemente)
preserva a consistência da base de dados.

Isolamento/Independência. As actualizações feitas por uma
transacção são obrigatoriamente invisíveis para outras transacções
enquanto não atinje o estado COMMITTED (o que resolve o
problema da actualização temporária ou temporary update
problem).

7
2. Propriedades ACID das transacções

Para preservar a integridade dos dados, o DBMS tem de assegurar:
Durabilidade. Se uma transacção altera a base de dados e é

COMMITTED, as alterações nunca se perdem mesmo que ocorra
uma falha posterior.

Seriabilidade. Várias transacções são consideradas serializáveis
se o efeito de executá-las duma forma entrelaçada é equivalente a
executá-las em série segundo alguma ordem. Esta propriedade é
importante para garantir a consistência dos dados.
8
3. Requisitos para a consistência duma base de
dados

Controlo da Concorrência
A maioria dos DBMSs são sistemas multi-utilizador.
A execução concorrente de transacções submetidas

por vários utilizadores tem de ser organizada de tal
modo que cada transacção não interfere com as
restantes, pois só assim se pode garantir que não há
resultados incorrectos.
A execução concorrente de transacções tem de ser

tal que cada transacção pareça estar a executar
isoladamente.
9
3. Requisitos para a consistência duma base de
dados

Recuperação de Dados
Falhas do sistema, quer por hardware quer por software, não poderão
deixar a base de dados num estado inconsistente.
10
4. Transacção como Unidade de Recuperação de
Dados

Se um erro ou crash de hardware/software ocorre
entre o início e o fim duma transacção, a DB ficará
inconsistente
Falha do computador (crash do sistema)
Um erro do sistema ou da transacção
Erros locais ou condições de excepção
detectadas pela transacção
Reforço do controlo da concorrência
Falha do disco
Problemas físicos e catástrofes
A DB é restaurada de volta a algum estado anterior
correcto —perto do instante da falha— de forma a
poder refazer as operações após o instante da falha.
11
4. Transacção como Unidade de Recuperação de
Dados

O DBMS assegura que se a transacção executa
algumas actualizações e depois ocorre uma falha
antes do seu término, então aquelas actualizações são
desfeitas.
As instruções COMMIT e ROLLBACK (ou seus

equivalentes) garantem a atomicidade da transacção

12
5. Recuperação de Dados
Duplicação de Dados (Mirroring)
Manter duas cópias da DB simultaneamente
Salvaguarda Periódica de Dados (Backup)

Salvaguardar (dump) periodicamente uma
cópia da DB num suporte de memória terciária
(fita magnética, DVDs, etc)
13
Registo de Transacções c/ Actualizações (System
Logging)
O log regista todas as operações envolvidas
numa transacção que afectam os dados duma DB.
O log é guardado em disco de tal forma que ele
não é afectado por falhas, com excepção das
falhas do próprio disco e das catástrofes.
14
6. Recuperação a partir duma Falha numa
Transacção

Falha Catastrófica
Restaura uma cópia anterior da DB a partir dum
backup arquivado
Aplica o transaction log à cópia para reconstruir
a DB desde o estado corrente arquivado na cópia
até ao instante da falha. É óbvio que só as
transacções COMMITTED registadas no log serão
refeitas.
 Dump incremental + log cada transacção
15
Transacção

Falha Não-Catastrófica
Inverte as operações que causaram
inconsistência, desfazendo-as e, possivelmente,
refazendo alterações legítimas que se perderam.
As entradas ou verbetes registados no system
log são consultadas durante a recuperação de
dados.
Não há necessidade de usar uma cópia completa
de arquivo da DB.
16
Transacção

Operações de Desfazer
Operações de Refazer
17
7. Estados da Transacção

Para efeitos de recuperação de dados, o sistema
precisa de registar quando uma transacção começa, é
consignada (committed) e termina.
Begin_Transaction: marca o início de execução da
transacção;
End_Transaction: especifica que as operações de
R/W terminaram e marca o fim de execução da
transacção (mas pode ser ser abortada pelo controlo
da concorrência);
Commit_Transaction: assinala o fim bem-sucedido
duma transacção. Quaisquer actualizações executadas
pela transacção podem ser consignadas (committed)
para a DB com segurança e não serão desfeitas.
18
7. Estados da Transacção

Rollback (ou Abort): assinala que a transacção
chegou ao fim sem sucesso. Quaisquer alterações que
a transacção tenha causado na DB serão desfeitas;
Undo: semelhante ao estado ROLLBACK, mas aplica-
se a uma só operação em vez de uma transacção
como um todo;
Redo: especifica que certas operações duma

transacção têm de ser refeitas para garantir que todas
as operações duma transacção consignada
(committed) foram aplicadas com sucesso a uma DB
19
8. Entradas no System Log
20
9. Execução duma Transacção
21
10. Operações de R/W duma Transacção
22
11. Checkpoints no System Log
23
12. Logging com Escrita à Cabeça(Write Ahead Logging)
24
13. Transacção como Unidade de Concorrência
25
14. Algorítmos de Escalonamneto deTransacções
26
14.1 Problema da Actualização Perdida
N:= 2; M:=3
27
14.2 The Incorrect Summary or Unrepeatable Read Problem
28
14.3 Dirty Read or The Temporary Update Problem
meanwhile T2 has read the “temporary” incorrect value of X
29
15. Escalas de Transacções

o Uma escala S de n transacções é uma sequência das operações
destas transacções.
 as transacções podem ser entrelaçadas

Uma escala mantém a ordem das operações dentro de cada
transacção.
Para cada transacção T, se a operação a é realizada em T antes
da operação b, então a será realizada antes de b em S.
o Duas operações são conflituosas se elas pertencem a

diferentes transacções, e acedem ao mesmo item de dados e
uma delas é uma operação de escrita.
30
15. Escala Seriada e Escala Não-Seriada
o Uma escala S é em seriada se, para qualquer transacção T

que participa na escala, todas as operações de T são
executadas consecutivamente em S; caso contrário, diz-se
que a escala é não-seriada.
o Nas escalas não-seriadas, as transacções são entrelaçadas.

Existem muitas ordens possíveis or escalas.
o A teoria da seriabilidade tenta determinar a 'correcção' das

escalas.
o Uma escala S de n transacções é serializável se é equivalente

a alguma escala serial das mesmas n transacções.
31
15.1 Exemplos de Escalas Seriadas
32
15.2 Exemplos de Escalas Não-Seriada
33
16. Métodos de Seriação/Seriabilidade

o Multi-versão. As técnicas de controlo de concorrência mantêm
os antigos valores do item de dados quando o item é actualizado.
o Selos de Tempo (timestamps). São identificadores únicos para
cada transacção e são gerados pelo sistema. As transações podem
então ser ordenadas segundo os seus selos de tempo de forma a
garantir a seriabilidade.
o Protocolos. Se forem seguidos por todas as transacções, os
protocolos asseguram a seriabilidade de todas as escalas em que
as transacções participam. Podem usar técnicas de locking dos
itens de dados para impedir que as várias transacções acedam aos
dados concorrentemente.
o Controlo Pessimista da Concorrência
Verifica se os itens de dados estão fechados (locked), ou
verifica os seus selos de tempo, antes de os ler ou escrever
em consequência de alguma operação que é realizada sobre a
DB.
34
17. Técnicas de Trancamento (Locking) para Controlo de
Concorrência

O conceito de trancamento de itens de dados é usado numa
das técnicas principais de controlo da execução concorrente
de transacções.
o Um fecho (lock) é uma variável associada a um item numa
DB. Em geral, existe um fecho para cada item numa DB.
o Um fecho descreve o estado do item em relação a possíveis

operações que lhe podem ser aplicadas. É usado para
sincronizar o acesso de transações concorrentes transactions
a itens da DB.
o Uma transacção tranca um objecto antes de o usar.
o Quando um objecto é trancado por uma transacção, qualquer

outra transacção que lhe tente aceder tem obrigatoriamente de
esperar que o objecto seja libertado.
35
18. Tipos de Fechos
Fechos binários têm dois estados possíveis:

1. locked (através da operação lock_item(X)) e
2.unlocked (através da operação unlock_item(X))
 Fechos multi-modo permitem o acesso concorrente ao mesmo
item por várias transacções. Têm três estados possíveis:
1.read locked ou shared locked (outras transações podem
ler o item)
2.write locked ou exclusive locked (uma única transacção
retém o item trancado) e
3.unlocked.
Os fechos são guardados numa tabela de fechos.
36
18. Tipos de Fechos
Fechos binários têm dois estados possíveis:

1. locked (através da operação lock_item(X)) e
2.unlocked (através da operação unlock_item(X))
 Fechos multi-modo permitem o acesso concorrente ao mesmo
item por várias transacções. Têm três estados possíveis:
1.read locked ou shared locked (outras transações podem
ler o item)
2.write locked ou exclusive locked (uma única transacção
retém o item trancado) e
3.unlocked.
Os fechos são guardados numa tabela de fechos.
upgrade lock: operação que comuta de read lock para write
lock
downgrade lock: operação que comuta de write lock para
read lock
37
19. Os fechos não garantem seriabilidade: caso
da actualização perdida
38
20. Os fechos não garantem seriabilidade
Y é destrancado demasiado Y é destrancado demasiado
•Escala 1: T1 seguida por T2 ⇒ X=50, Y=80

•Escala 2: T2 seguida por T1 ⇒ X=70, Y=50
39
21. Como assegurar a seriabiliade?:Trancamento em
Duas Fases (Two-Phase Locking - 2PL)

Todas as operações de trancamento (read_lock, write_lock)
precedem a primeira operação de destrancamento nas transacções.
Duas fases:
fase de expansão: novos fechos sobre itens podem ser
activados, mas nenhum pode ser libertado;
fase de contracção: os fechos existentes podem ser
libertados, mas nenhum pode ser activado.X=20, Y=30
40
22. Trancamento em Duas Fases (Two-Phase Locking –
2PL)

2PL básico:
quando uma transacção liberta um fecho, ela pode

ou não requerer outro fecho
41
2PL conservador ou 2PL estático:
uma transacção tranca todos os itens que ela acede
antes do início da sua execução
pré-declarando os conjuntos de reads e writes
2PL estrito:
uma transacção não liberta nenhum dos seus
fechos até que ela consigne (commits) ou aborte
conduz a uma escala estrita para ecuperação de
dados
42
23. Deadlock: um problema resultante do trancamento
Cada uma das duas ou mais transacções está à espera

que outra liberte um item. Também designado pelo
abraço da morte.
43
24. Deadlocks e Livelocks
 Protocoolo de prevenção de deadlocks:
 2PL conservador
 Selos nas transacções (transacções mais recentes
abortadas)
nenhuma espera
espera cautelosa
esgotamento de tempo (time outs)
Detecção de deadlock (se a carga da transacção é
leve ou as transacções são curtas e só tranca alguns
poucos itens)
 Grafo do tipo espera-por para detecção de
deadlock
 Selecção de víctima
 Recomeça ciclicamente
Livelock: uma transacção não pode prosseguir por
um período indefinido de tempo enquanto outras
transacções continuam normalmente.
Esquemas de espera justa (i.e. first-come-first-
served)
44
25. Granularidade do Trancamento

Um item duma base de dados pode ser:
um registo
o valor dum campo dum registo
um bloco do disco
a base de dados no seu todo
 Compromissos (trafe-offs)
granularidade lata
quanto maior o tamanho do item, menor é o grau da
concorrência
granularidade fina
quanto menor o tamanho do item, maior número de
fechos são necessários gerir e armazenar e mais
operações de lock/unlock são necessárias.
45
Outras Estratégias de Controlo da Concorrência e
Recuperação de Dados
26. Recuperação de Dados: Técnica de Paginação na
Sombra
46
27. Recuperação de Dados: Técnica de Paginação na
Sombra (cont.1)
47
27. Recuperação de Dados:
Técnica de Paginação na Sombra (cont.2)
48
28. Conclusões
A gestão de transacções lida com dois
requisitos chavede qualquer sistema de
bases de dados:
Resiliência
 na capacidade dos dados
sobreviverem a crashes de hardware e
erros de software sem perdas e sem
ficar inconsistente
 Controlo de Acesso
 na capacidade de permitir acesso
simultâneo aos dados por vários
utilizadores duma forma consistente e
só com acesso autorizado
49
Cap. 2
Sistema Relacional Objecto
1. Sistema Orientado a Objecto
 Introdução e Motivações;
 Conceitos principais
 Exemplos;
 Principais SGBDOOs;
 Considerações Finais.
50
Cap. 2
1.1 Introdução e Motivações
 Novas aplicações ficaram limitadas por restrições impostas pelo modelo

relacional.
 As aplicações convencionais possuem características comuns que as

tornam passíveis de serem tratadas por bancos de dados relacionais:
 Uniformidade: as informações a serem armazenadas podem ser
estruturadas de maneira similar.
 Orientação a registos: registos de tamanho fixo são adequados
para a representação desta informação.
 Itens de dados pequenos: as informações são estruturadas em
registos pequenos.
 Campos atômicos: os campos dentro de um registo são pequenos e
de comprimento fixo. Não há estruturas dentro dos campos, ou seja,
a primeira forma normal pode ser mantida.
 O modelo de bases de dados orientado a objectos está baseado no
paradigma de programação orientada a objecto.
51
Cap. 2
1.1 Introdução e Motivações (cont.)
 As aplicações mais novas, em geral, não possuem, no mínimo,

uma das características já citadas.
 Exemplos dessas aplicações:
 Computer-aided design (CAD) – desenho assistido por computador:
 É necessário armazenar os dados pertencentes a um projeto de
engenharia, incluindo os componentes do item que está sendo
projetado, o inter-relacionamento dos componentes, as versões
antigas do projecto.
 Computer-aided software engineering (CASE) – engenharia de
software auxiliada por computador:
É necessário armazenar os dados necessários para apoiar os
desenvolvedores de software, incluindo o código-fonte, as
dependências entre os módulos de software, as definições e o uso
de variáveis e o histórico de desenvolvimento do sistema de
software.
52
Cap. 2
1.2 O Modelo de Dados Orientado a Objecto
 A estrutura objecto:
 Superficialmente, um objecto corresponde a uma entidade no modelo E-R.
 Este paradigma se baseia no encapsulamento de dados e em código
relacionado a um objecto dentro de uma única unidade.
 As interações entre um objecto e o resto do sistema deve ser via mensagens.
 Uma interface entre um objecto e o resto do sistema deve ser definida por
um conjunto de mensagens permitidas.
 Em geral, um objecto tem associado a ele:
 Um conjunto de variáveis que contém os dados para o objecto; as variáveis
correspondem aos atributos no modelo E-R;
 Um conjunto de mensagens ao qual o objecto responde; cada mensagem
pode ter zero, um ou mais parâmetros;
 Um conjunto de métodos, cada qual sendo um corpo de código para
implementar a mensagem; um método para implementar a mensagem; um
método retorna um valor como resposta à mensagem.
53
Cap. 2
1.2 . O Modelo de Dados Orientado a Objecto
 O termo mensagem num contexto orientado a objecto se refere à passagem de
pedidos entre os objectos sem considerar detalhes específicos de mplementação.
 O termo chamar um método algumas vezes é usado para representar o ato de

enviar uma mensagem a um objecto e a execução do método correspondente.
 Exemplo:
o Considerando a entidade empregado numa base de dados. Suponha que o salário
anual de um empregado seja calculado de maneiras diferentes para diferentes
empregados. Por exemplo, os gerentes podem ter um bônus dependendo do
desempenho do banco, enquanto os caixas podem obter um bônus dependendo de
quantas horas eles trabalharam. É possível encapsular o código para calcular o
salário para cada empregado como um método que é executado em resposta a uma
mensagem salário_anual.
o Todos os objectos empregado respondem à mensagem salário_anual, mas fazem
isso de diferentes maneiras. Pelo encapsulamento da informação sobre como
calcular o salário anual dentro do objecto empregado, todos os objectos
empregados apresentam a mesma interface.
o É possível modificar a definição de um objecto sem afetar o resto do sistema.
Esta é uma das habilidades considerada como uma das maiores vantagens do
paradigma de programação orientado a objectos. 54
Cap. 2
1.2 . O Modelo de Dados Orientado a Objecto
 Os métodos de um objecto podem ser:
o Somente leitura: não afecta os valores das variáveis em um objecto;
o De actualização: pode mudar os valores das variáveis.
 As mensagens às quais um objecto responde podem ser, de maneira similar,

classificadas como somente leitura ou de atualização, em função do método que implementa
a
mensagem.
 Cada atributo de uma entidade deve ser expresso como uma variável e um par de
mensagens
do objecto no modelo orientado a objecto. A variável é usada para armazenar o valor do
atributo, uma mensagem é usada para ler o valor do atributo e o outro método é usado para
atualizar o valor. Por exemplo:
o O atributo endereço da entidade empregado pode ser representado por:
 Uma variável endereço;
 Uma mensagem obter_endereço cuja resposta é o endereço;
 Uma mensagem ajustar_endereço, que possui um parâmetro novo_endereço,
para atualizar o endereço.
o Por simplicidade muitos modelos orientados a objecto permitem que as variáveis
sejam lidas ou actualizadas diretamente, sem ter de definir mensagens para isso.
55
Cap. 2
1.3 . Classes de Objectos
 objectos similares são aqueles que respondem às mesmas mensagens, usam os
mesmos métodos e têm variáveis de mesmo nome e tipo.
 objectos similares são agrupados formando uma classes.
 Cada um desses objectos é chamada de uma instância de sua classe.
 A noção de uma classe no modelo de dados orientado a objecto corresponde à noção
de um conjunto entidade do modelo E-R.
 Exemplo de definição de uma classe:
Class empregado {
/* variáveis */
string nome;
string endereço;
date data_início;
int salário;
/* mensagem */
int salário_anual();
string obter_nome();
string obter_endereço();
int ajustar_endereço (string novo_endereço);
int tempo_emprego();
} 56
Cap. 2
1.4 . Herança
 Considerando um banco de dados orientado a objectos para a aplicação bancária
(exemplo –
Korth), a classe clientes é similar à classe empregados, pois ambas definem variáveis para
nome, endereço e assim por diante. No entanto, há variáveis específicas para empregados
(salário) e variáveis específicas para clientes (classificação_crédito).
 Neste caso é desejável definir uma representação para as variáveis comuns em um único
local. Para isso, combina-se empregados e clientes dentro de uma classe.
 Para permitir a representação direta de similaridades entre classes, necessita-se colocar

as
classes em uma hierarquia de especialização.
 Empregado e cliente são especializações de pessoa.
 Este conceito é similar ao conceito de especialização no modelo E-R.
Empregados e clientes podem ser representados por classes que são especializações de uma
classe pessoa. Variáveis e métodos específicos a empregados são associados à classe
empregados. Variáveis e métodos específicos a clientes são associados à classe cliente.
Variáveis e métodos que se aplicam tanto a empregados como a clientes são associados à57
classe pessoa.
Cap. 2
1.4 . Herança
class pessoa {
string nome;
string endereço;
};
class cliente isa pessoa {
int classificação_crédito
};
class empregado isa pessoa {
date data_início;
int salário;
};
class escriturário isa empregado {
int número_escriturário;
int número_conta_despesa;
};
class caixa isa empregado {
int horas_por_semana;
int número_estação;
};
class secretária isa empregado {
int horas_por_semana;
string gerente;
};
58
Cap. 2
1.4 . Herança
 Um benefício importante da herança em sistemas orientados a objecto é a
noção de reusabilidade.
 Qualquer método de uma classe pode ser invocado por qualquer objecto
pertencente a qualquer subclasse desta classe.
 Para tratar a hierarquia de classes tem-se duas opções:

 Associar à classe empregado todos os objectos empregado, incluindo aqueles que são
instâncias de escriturário, caixa e secretária.
 Associar à classe empregado somente aqueles objectos empregado que não são
instâncias nem de escriturário, nem de caixa, nem de secretária.
 É possível determinar o conjunto de todos os objectos empregado, nesse
caso, tomando-se a união daqueles objectos associados a todas as
subclasses de empregado.
59
Cap. 2
1.4 . Herança Múltipla
 Suponha que precisemos distinguir entre escriturários, caixas e secretárias de tempo
integral
e tempo parcial. Além disso, assuma que são necessárias diferentes variáveis e métodos
para representar empregados de tempo parcial e tempo integral. Então cada um desses
empregados são classificados de duas maneiras diferentes.
pessoa
empregado cliente
escriturário caixa secretária
Escrit_TI Escrit_TP Caixa_TI Caixa_TP secretária_TI secretária_TP
60
Cap. 2
1.4. Herança Múltipla
 Existem certas variáveis e métodos específicos para empregado em tempo integral e
outros
específicos para empregado em tempo parcial. Assim, na hierarquia em análise, as variáveis
e métodos para empregados de tempo integral devem ser definidos três vezes: uma vez
para
escriturário_TI, uma vez para secretária_TI e uma vez para caixa_TI. Redundâncias deste
tipo são indesejáveis mediante alterações nas propriedades dos empregados de tempo
integral (e parcial), que deverão ser feitas em dois lugares diferentes.
 Existe falha na exploração da reutilização de código.
 Nesta hierarquia também não se consegue representar os empregados que não são
escriturários, caixas ou secretárias, mas que possuem características de serem ou de tempo
parcial ou integral.
 Se existissem várias classificações de emprego, em vez de duas limitações neste exemplo,

as
limitações do modelo se tornariam muito mais aparentes.
61
Cap. 2
Herança múltipla é a habilidade de uma classe herdar variáveis e métodos
a partir de múltiplas superclasses.
pessoa
empregado cliente
tempo integral tempo parcial escriturário caixa secretária
escrit_TI escrit_TP caixa_TI caixa_TP secretária_TI secretária_TP
 Pode haver algum problema?
62
Cap. 2
 Assuma que, em vez de definir salário para a classe empregado,
defina-se uma variável chamada pagamento para cada classe:
tempo_integral, tempo_parcial, escriturário, caixa e secretária, como a
seguir:
Tempo_integral: pagamento é um inteiro de 0 a 100.000 contendo um salário anual;
 Tempo_parcial: pagamento é um inteiro de 0 a 20, contendo uma taxa horária de
pagamento.
 Caixa e escriturário: pagamento é um inteiro de 0 a 20.000, contendo um salário anual;
 Secretária: pagamento é um inteiro de 0 a 25.000, contendo um salário anual
 Considere a classe secretária_TP. Ela pode herdar a definição de
pagamento tanto de tempo_parcial como de secretária. O resultado é
diferente, dependendo da escolha feita.
 Opções:
 Incluir ambas as variáveis, renomenado-as como tempo_parcial.pagamento e
secretária.pagamento;
 Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e
secretária
foram criadas; 63
 Forçar o usuário a fazer a escolha;
Cap. 2
1.5 Identidade de objecto
 Os objectos em um banco de dados orientado a objecto correspondem a uma
entidade na empresa que está sendo modelada. Uma entidade mantém sua
identidade mesmo se algumas de suas propriedades mudam com o tempo.
 Um objecto mantém sua identidade mesmo se alguns ou todos os seus valores

de
variáveis ou definições de métodos mudarem com o tempo.
 Diferente do modelo relacional onde as tuplas de uma relação são

diferenciadas
somente pelos valores que elas contêm..
64
Cap. 2
1.5 Identidade de objecto
 Formas de identidade:
 Valor: usado em modelos relacionais  um valor de dado é usado para
identidade da tupla;
 Nome: usado em sistemas de arquivos  um nome fornecido pelo usuário é
usado para identidade dos arquivos;
 Embutido: usado em sistemas orientados a objectos  a cada objecto é
atribuído automaticamente um identificador pelo sistema quando aquele objecto
é criado.
 Identificadores de objectos são únicos. Exemplo de uso do identificador:
 Um dos atributos de um objecto pessoa pode ser o atributo cônjuge, que é
realmente um identificador do objecto pessoa correspondendo ao cônjuge da
primeira pessoa. Assim, o objecto pessoa pode armazenar uma referência ao
objecto que representa o cônjuge de pessoa.
I
65
Cap. 2
1.6 O bjectos Compostos
 As referências entre os objectos podem ser usadas para modelar
diferentes conceitos do mundo real. Um desses conceitos é o de
objectos compostos.
bicicleta é parte de
roda freio marcha quadro
Aro raio pneu pedal bloco cabo
O conceito de composição permite que os dados sejam vistos em

diferentes granularidades por diferentes usuários.
66
Cap. 2
1.7. Modelagem de BDOOs
 Representação na BDOO:
 Uma BDOO armazena objectos integralmente;
 É possível recuperar um objecto a qualquer momento, inclusive todas
as referências.
 Linguagem de definição:
 ODL (Object Definition Language);
 Utilizada para criar definições de objectos.
 Linguagem de consulta:
 OQL (Object Query Language);
 Utilizada para recuperar objectos da Base de Dados.
67
Cap. 2
Automóvel Classes
KIA
Modelo
Côr Fabricante
Preço Nome
Fabricante Presidente
Peças [ ] Fábricas [ ]
Motor
Nome
Fabricante Fábrica
Potencia
Nome
Peças Cidade
Nome Funcionários
Motor
Produção [ ]
68
Cap. 2
Automóvel {OID12} Objectos
736194174
ka
Preto Fabricante {OID1}
100.000 Ford
OID1 João da Silva
[OID5123 ] [ OID1125, OID1127, OID1128]
Peças {OID5123}
Correia dentada Motor {OID154}
Ford Rocam 1000 16V
OID154 OID1
[OID1125, OID1127, OID1128] 120CV
Fábrica {OID1125} Fábrica {OID1127} Fábrica {OID1128}

Central Filial Saão Bernardo I Filial Saão Bernardo II
Camaçari São bernardo São bernardo
320 250 130 69
Cap. 2
Automóvel {OID12}
736194174
ka Objecto Complexo
Preto
100.000
Fabricante {OID1}
Ford
João da Silva Fábrica {OID1125} Fábrica {OID1127} Fábrica {OID1128}
Central Filial Saão Bernardo I Filial Saão Bernardo II
Camaçari São bernardo São bernardo
320 250 130
Motor {OID154}
Rocam 1000 16V
OID1
120CV
70
Cap. 2
1.8. Modelagem Padrão ODMG – ODL (Object Data Management Group
-Object Definition Language)
possui_professor
Pessoa especializa_em
Departamento
oferece
trabalha_em
possui_especializacoes
oferecido_por
disciplinas_completadas
Prefessor Aluno alunos
curso
registado_em
da_assistentencia Disciplinas possui_disciplinas
assistente
AlunoGrad oferecidas do_curso
no_comite_de comite
alunos_registados
Disciplina_Actual_ oferecida
Relacionamentos Heranca Classe

1:1 Fonte:
1:N Elmasri e Navathe, 2000
M:N 71
Cap. 2
1.9. Especificação ODL
class Professor extends Pessoa

( extent professores )
{
attribute string classificação;
attribute float salário;
attribute string escritório;
attribute string telefone;
relationship Departamento trabalha_em inverse
Departamento::possui_professor;
relationship set<aluno_grad> dá_assistência inverse
AlunoGrad::assistente;
relationship set<aluno_grad> no_comitê_de inverse AlunoGrad::comitê;
void dar_aumento(in float aumento);
void promove(in string nova_classificação);
};
72
Cap. 2
class Grau
( extent graus)
{
attribute enum GrauValores{A,B,C,D,F,I,P} grau;
relationship Disciplina disciplina inverse Disciplina::alunos;
relationship Aluno aluno inverse Alunos::disciplinas_completadas;
};
73
Cap. 2
class Aluno extends Pessoa

( extent alunos)
{
attribute string classe;
attribute Departamento cursa_eletiva_em;
relationship Departamento especializa_em inverse
Departamento::possui_especializações;
relationship set <grau> disciplinas_completadas inverse Grau::alunos;
relationship set <DisciplinaCorrente> registrado_em inverse
DisciplinaCorrente::alunos_registrados;
void alterar_especialização (in string nomed) raises disciplina_inválida);
float mg();
void registrado(in short nomseção; in ValorGrau grau)
raise (disciplina_inválida,grau_invalido);
};
74
Cap. 2
1.11. Linguagens Orientadas a objecto
 Para que estes conceitos básicos de orientação a objectos sejam

usados na prática em um sistemas de banco de dados, eles devem
ser expressos em alguma linguagem. Esta representação pode ser
feita de duas formas:
 Os conceitos são usados puramente como uma ferramenta de
projeto e são codificados, por exemplo, em um banco de dados
relacional;
 Os conceitos de orientação a objectos são incorporados em uma
linguagem que é usada para manipular o banco de dados.
• Extensão de uma linguagem de manipulação de dados, como a
SQL, pela adição de tipos complexos e orientação a objectos.
• Tomar uma linguagem de programação orientada a objecto e
estendê-la para tratar banco de dados (são as linguagens de
programação persistentes).
75
Cap. 2
1.13. Persistência de objectos
 Persistência por classe: Declarar que uma classe é persistente.
Assim,
todos os objectos da classe são, por default, persistentes. Os objectos de
classes não persistentes são transientes.
 Persistência por criação: Um objecto é persistente ou transiente,

dependendo de como ele foi criado.
 Persistência por marcação: Todos os objectos são criados como

transientes mas, se um objecto deve persistir alem da execução do
programa, ele deve ser marcado explicitamente como persistente antes
do programa terminar.
 Persistência por referência: Um ou mais objectos são explicitamente

declarados como objectos persistentes (raiz). Todos os outros objectos
são persistentes se (e somente se) forem referidos diretamente, ou
indiretamente, a partir do objecto persistente raiz.
76
Cap. 2
1.14 Sistemas Persistentes C++
 O grupo de gerenciamento de banco de dados objecto (ODMG) tem
trabalhado para padronizar extensões de linguagem ao C++ (e ao
Smalltalk) a fim de aceitar persistência e definir bibliotecas de
classe para aceitar persistência.
 Exemplos:
 o operador new deve ser estendido para alocar um novo objecto na
base de dados, em meio estável;
 tipos para criação de referências (ponteiros persistentes) precisam
se criados. Ref<objecto>: referência persistente para o objecto do
tipo objecto;
 Notações para especificar restrições de integridade referencial
também são incorporadas. Inverse deve ser usado nas definições
das classes sobre as quais as restrições de integridade referencial
serão necessárias.
 Existem duas partes:
 Linguagem de Definição de objecto (ODL);
 Linguagem de Manipulação de objecto (OML).
77
Cap. 2
1.15 Principais SGBDOOs
Critério
Objectivity/DB GemStone(*)
Objectivity, Inc.
www.poet.com
GemStone Systems
Definição de dados SIM
pelo usuário
Herança Múltipla SIM
Valida cardinalidade SIM

entre objectos
Suporta transacções SIM
longas
Linguagem de C++, JAVA,
Definição de atributos Smalltalk, SQL
Não, os métodos
são armazenados
no cliente
78
Cap. 2
2. MAPEAMENTO OBJETO - RELACIONAL
Utiliza-se uma abstração bastante intuitiva no sentido de que uma classe do
tipo persistente pode ser mapeada para uma tabela no banco de dados
relacional e atributos da classe para campos da tabela. Porém, algumas
diferenças entre os dois modelos , como OID (Object Identifiers –
Identificador de Objetos), tipos de dados, herança e associações,
demandam um estudo mais detalhado das estratégias de mapeamento.
2.1 Identificação de chave primária

As linhas das tabelas identificam univocamente o tuplo da entidade.
2.2 OIDs (Objects Identifiers)

Os OIDs são identificadores únicos que representam um objeto, em linguagens de
programação, existentes, este objeto é implícito e criado quando ocorre a criação
de um novo objeto, já em um banco de dados relacional cabe ao desenvolvedor a
responsabilidade desta criação.
Quando ocorre o mapeamento, recomenda-se armazenar no banco de dados
relacional o identificador do objeto como chave primária, ou qualquer outro
atributo do objeto que possa identificá-lo, como único, exemplo o NUIT.
79
Cap. 2
3.3 Mapeamento de Classes em Tabelas
O mapeamento de classes pode ser feito mediante a paridade entre classe e tabela, ou
seja, uma classe é mapeada para uma tabela. Este mapeamento direto de classes
para tabelas representa a forma mais simples de mapeamento, tornando mais fácil o
entendimento e a manutenção de uma aplicação. Com um modelo de classes bastante
simples isto poderia ser feito. Porém, nem sempre é simples assim. No caso de uma
estrutura hierárquica, várias classes podem ser mapeadas para uma tabela, como
também uma classe pode ser mapeada para várias tabelas. Ainda, classes com
atributos multivalorados ou compostos podem ser mapeadas para mais de uma tabela.
Mapeamento de Classes em Tabelas
80
Cap. 2
2.4 Mapeamento de Atributos em Colunas
Os atributos simples podem ser mapeados directamente para colunas

em uma tabela, já os atributos complexos e multivalorados podem
necessitar de tabelas adicionais para seu armazenamento. Estes
atributos complexos geralmente possuem características recursivas, ou
seja, são classes que possuem outros atributos e assim ucessivamente.
81
Cap. 2
2.5 Mapeamento de Herança
Existem fundamentalmente três estratégias para mapear herança em um
banco de dados relacional:
Uma tabela por hierarquia:

Mapear toda a hierarquia de classes para uma tabela, onde todos os
atributos das classes da hierarquia são armazenados nesta única tabela.
A desvantagem desta estratégia é que toda vez que um objeto da

hierarquia for persistido no banco, é necessário persistir também os
valores das demais classes vazios, causando uma grande quantidade de
campos inutilizados.
82
Cap. 2
Existem fundamentalmente três estratégias para mapear herança em um
banco de dados relacional:
Uma tabela por classe concreta:

Cada classe concreta mapeada reflete uma tabela com todos os
atributos herdados das super classes abstratas. A vantagem desta
estratégia é a facilidade de manipulação de dados, uma vez que todos os
dados de cada classe estão em apenas uma única tabela.
Como desvantagem, destaca-se que quando se modifica uma classe
abstrata, é necessário modificar todas as tabelas geradas pelas classes
filhas no modelo relacional;.
Uma tabela por classe:

Cada hierárquica mapeada reflete uma tabela, relacionadas através
do mecanismo de especialização padrão do banco de dados relacional
(utilização de chaves estrangeiras).
83
Cap. 2
Existem fundamentalmente três estratégias para mapear herança em um banco de
dados relacional:
Uma tabela por classe concreta:

Cada classe concreta mapeada reflete uma tabela com todos os atributos
herdados das super classes abstratas. A vantagem desta estratégia é a facilidade
de manipulação de dados, uma vez que todos os dados de cada classe estão em
apenas uma única tabela.
Como desvantagem, destaca-se que quando se modifica uma classe
abstrata, é necessário modificar todas as tabelas geradas pelas classes filhas no
modelo relacional;
Uma tabela por classe:

Cada hierárquica mapeada reflete uma tabela, relacionadas através
do mecanismo de especialização padrão do banco de dados relacional (utilização
de chaves estrangeiras).
84
Cap. 2
Exemplos técnicas de mapeamento:

Uma tabela por hierarquia; Uma tabela por classe concreta,
Uma tabela por classe.
85
Cap. 2
Uma tabela por Uma tabela por classe Uma tabela por cla
hierarquia de classes concreta
Adhoc Simples Médio Médio/Difícil

reporting
Facilidade de Simples Médio Difícil
implementação
Facilidade de Simples Simples Médio/Difícil
acesso
Acoplamento Muito alto Alto Baixo
Velocidade de Rápido Rápido Médio/Rápido
acesso
Suporte a Médio Baixo Alto
polimorfismo
Comparação entre as técnicas
86
Cap. 2
2.6 Mapeamento de Associações
As associações entre classes no modelo orientado a objetos é conceitualmente
bastante similar ao relacionamento entre tabelas no modelo relacional. Este fato
permite que tais associações sejam mapeadas para relacionamentos, podendo
utilizar chaves estrangeiras ou tabelas auxiliares.
2.6.1 Associações do tipo 1 para 1 (1:1)

A associação deste tipo entre classes é mapeada colocando o tributo
identificador da classe referenciada na classe que o referência,
criando então o conceito de uma chave estrangeira no modelo
relacional, conforme a fig.
87
Cap. 2
2.6.2 Associações do tipo 1 para n (1:n)

Da mesma forma que a associação do tipo 1:1, o relacionamento 1:n
também é mapeado colocando o atributo identificador da classe
referenciada na classe que o referência, criando então o conceito de uma
chave estrangeira no modelo relacional, como demonstrado na fig.
88
Cap. 2
2.6.3. Associação do tipo n para n (n:n)

Para mapear uma associação do tipo n:n, é necessário utilizar o conceito
de tabela associativa, cujo propósito é manter o relacionamento entre
duas ou mais tabelas do modelo relacional.
Cria-se então uma tabela associativa com os OID’s das classes que se
referenciam, garantindo a navegabilidade do relacionamento, como
exemplificado
89
Cap. 2
2.7 MAPEAMENTO DE ASSOCIAÇÕES TODO/PARTE
As associações todo/parte geralmente são representadas como
agregações ou composições.
As agregações são associações que representam uma relação

grupo/membro, ou seja, onde o objeto agregado pode existir
independente dos objetos que o constituem.
Já a composição representa um tipo de associação onde o todo não

existe sem sua(s) parte(s).
Neste caso, tanto agregações quanto composições são mapeadas para

tabelas de duas formas: utilizando uma única tabela com todos os
atributos da classe que representa o todo e das classes que
representam suas partes, ou mais de uma tabela, uma para cada classe
envolvida no modelo.
90
Cap. 3
Bases de dados distribuídas
1. Definição
Um Sistema de Gestão de Bases de Dados Distribuídos, é um sistema
cujos dados se encontram fisicamente dispersos por várias máquinas,
ligadas por meios de comunicação, mas integrados logicamente.
1.2 Classificação das Bases de Dados Distribuídas

Homogéneos – Todos os nodos usam o mesmo sistema gerenciador
de bases de dados (SGBD), fazendo lembrar um único sistema de
bases de dados, mas em que, em vez de todos os dados estarem
armazenados num único repositório, os dados estão armazenados por
vários repositórios ligados por meios de comunicação
91
Cap. 3
1.2 Classificação das Bases de Dados Distribuídas

Heterogéneos – caracteriza-se pela existência de SGBDs diferente
nos vários nodos. As diferenças entre os SGBDs presentes podem
colocar-se a vários níveis, desde SGBD diferentes baseados no mesmo
modelo de dados (por exemplo oracle, DB2, Informix, Sysbase, etc.,
consistindo em implementações distintas do modelo relacional) até
SGBD baseados em modelos de dados diferentes (relacionais, rede,
OO, etc.)
92
Cap. 3
2. Um Sistema Centralizado, é um sistema em tanto os dados como o

processamento se localizam numa mesma máquina.
Impressoras
Printer
Mainframe
Terminal
Sistema centralizado
93
Cap. 3
 Vantagens
Facilidade de administração
Possibilidade de partilha de recursos
 Desvantagens
Sistemas caros de manter em operação
Dependência em relação a fornecedores de software e hardware
Custo expansão (o aumento da capacidade de processamento é
muito caro)
Dificuldade de partilha dos dados em concorrência.
Exige mais recursos de rede (a unidade de transferência de
informação é o ficheiro)
94
Cap. 3
3. Arquitectura cliente\servidor
Segundo esta arquitectura uma ou mais máquinas dotadas em termos
de capacidade de disco poderiam ser utilizadas para armazenar uma
grande quantidade de dados (servidores), permitindo que a sua partilha
pelas restantes máquinas ligadas à rede (clientes).
95
Cap. 3
3.1 Arquitectura cliente servidor de ficheiros
Unidades de
Disco
Servidor de Ficheiros
Ficheiro B
Ficheiro A
Ficheiro C
Clientes
Arquitectura cliente/servidor de ficheiros
96
Cap. 3
3.1 Arquitectura cliente servidor de ficheiros
Desvantagens
Exige mais recursos de rede (a unidade de transferência de
informação é o ficheiro)
Dificuldade de partilha dos dados em concorrência.
3.2 Arquitectura cliente servidor de bases de dados
O servidor corre um SGBDs, o que permite responder as solicitações

dos clientes apenas com dados solicitados por estes. Desta forma
aumenta-se o nível de concorrência e diminui-se o tráfego na rede. O
processamento sobre os dados é feito pelas maquinas clientes.
97
Cap. 3
3.2 Arquitectura cliente servidor de bases de dados
Base de
dados
Servidor de base de dados
Instruções
SQL Dados
Dados
Clientes
Arquitectura cliente/servidor de base de dados
98
Cap. 3
4. Sistemas Distribuídos
São sistemas em que os dados se encontram distribuídos por
vários centros de processamento independentes e existe uma
partilha transparente desses dados entre os vários centros
(nodos), fazendo uso de meios de comunicação.
Base de dados Distribuida
Nodo 1 Nodo 2
BD1 BD 2
Rede de
Data
Nodo N Comunicação Nodo 3
BD N Bd 3
Sistema de Base de dados Distribuida

99
Cap. 3
4. Sistemas Distribuídos (SD)
Razões ou porquês de SD
Reflectir o estado distribuído de uma organização . é hoje
muito comum casos de organizações espalhadas por zonas
geograficamente distantes, com necessidade de uma
coordenação comum;
Por necessidade de crescimento.
100
Cap. 3
Razões ou porquês de SD
Reflectir o estado distribuído de uma organização . é hoje
muito comum casos de organizações espalhadas por zonas
geograficamente distantes, com necessidade de uma
coordenação comum;
Por necessidade de crescimento.
101
Cap. 3
4.1 Formas de distribuição dos dados:
4.1.1 Replicação de dados

Se os dados estão distribuídos por pontos geograficamente
distintos, sempre que houver necessidade de lhes aceder, estes
terão de ser transferidos desde os seus locais de origem, até ao
local que os solicitou. Estas viagens significam custos em
comunicação e tempo.
Uma alternativa, que pode reduzir significativamente estes

custos, consiste em replicar os dados mais frequentemente
solicitados pelos nodos que mais os solicitam.
102
Cap. 3
4.1.1 Replicação de dados

 Problemas com a replicação
a necessidade de determinar quais réplicas precisam ser
acessadas por um determinado usuário;
a redundância dos dados pode ser grande, porém é um caso
específico onde isto é desejado. Cabe ao SGBDD controlar esta
redundância, se responsabilizando pela propagação das
transações às réplicas;
as actualizações em tabelas que replicam devem ser feitas em
todas as cópias, esta é uma desvantagem da replicação e causa
o problema da propagação de actualização. Isto pode
acontecer, se algum nó que possua um réplica não esteja
disponível no momento da actualização.
103
Cap. 3
4.1.1 Replicação de dados:

Neste caso, é necessário encontrar uma estratégia para propagar as
actualizações, que pode ser: uma cópia de cada réplica é designada
como cópia master e todas as outras são cópias secundárias.
Por isso, os SGBDD devem ter suporte ao commit em duas fases

(two-phase commit) o que é custoso a nível de desempenho.
104
Cap. 3
4.1.1 Replicação de dados:

O commit em duas fases é um protocolo que divide a execução do
commit em duas etapas.
1) Um elemento escolhido como coordenador manda um aviso de

PREPARAR COMMIT a todos os servidores envolvidos na
transacção.
2) Após ter recebido a resposta de todos, pode: se todas as respostas

foram positivas, enviar aos participantes a ordem de REALIZAR
COMMIT; ou ordenar que cancelem a transacção.

Assim, ou todos farão o commit ou nenhum fará, garantindo
integridade.
105
Cap. 3
4.1 Formas de distribuição dos dados:
4.1.2 Fragmentação de dados

Da mesma forma que alguns dados, em virtude de serem muito
solicitados por alguns nodos ou por serem vitais para o seu
processamento local, são duplicados nesses nodos, existem
outros dados cuja utilização, muito frequentemente, se reduz a
algum ou alguns nodos específicos, surge assim o conceito de
fragmentação.
106
Cap. 3

Da mesma forma que alguns dados, em virtude de serem muito
solicitados por alguns nodos ou por serem vitais para o seu
processamento local, são duplicados nesses nodos, existem
outros dados cuja utilização, muito frequentemente, se reduz a
algum ou alguns nodos específicos, surge assim o conceito de
fragmentação.
Tipos de fragmentação
Fragmentação vertical
Fragmentação Horizontal
Fragmentação mista
107
Cap. 3
Fragmentação vertical
A tabela lógica é dividida em tabelas cujos esquemas são
subconjuntos do esquema da tabela original (na sua versão mais
simples, a chave da tabela lógica propaga-se a todos a todos
fragmentos verticais). Por analogia com a álgebra relacional, a
fragmentação vertical pode ser como a execução de projecções
sobre a tabela lógica, armazenando as tabelas resultantes
(tabelas físicas) em nodos diferentes.
Tabela lógica global Nodo 1 Nodo 2 Nodo 3
Tabelas
Física
Locais
Fragmentação Vertical
108
Cap. 3
Fragmentação vertical
• Divide uma relação verticalmente em colunas
– Cada fragmento mantém apenas certos atributos da
relação gerando subrelações
• Chave primária ou alguma chave candidata - atributo
comum
– Algébra relacional - através do operador de projecção
– Conjunto de fragmentos gerados pelas listas de
projecções (L1, L2, … Ln) incluem todos os atributos de R
• Compartilhando um atributo comum
– Reconstruir a relação R: operação de junção
109
Cap. 3
Exemplo: Dados Pessoais
Nome Sobren. CPF Sexo CPF_SUP Salário Depto
José Silva 0192022 M 020201212 2300,00 05
Carlos Torres 2121222 M 020201212 3000,00 05
Márcia Fernandes 1212222 F 098789999 2900,00 05
Márcia Camargo 2233223 F 898989899 2500,00 06
Antonio Rodrigues 2134786 M 898989899 4000,00 06
Rui Madsen 0857489 M 898989899 3880,00 06
Cap. 3
Exemplo: Dados Profissionais

José Silva 0192022 M 020201212 2300,00 05
Carlos Torres 2121222 M 020201212 3000,00 05
Márcia Camargo 2233223 F 898989899 2500,00 06
Rui Madsen 0857489 M 898989899 3880,00 06
Cap. 3
Fragmentação horizontal
A tabela lógica é dividida em várias partes, cada
uma delas com o mesmo esquema da tabela
original. Continuando a analogia com as
operações da álgebra relacional, o exemplo da
figura a seguir pode ser obtido executando três
operações de selecção sobre a tabela lógica e
armazenando as tabelas resultantes (tabelas
físicas) em nodos diferentes.
112
Cap. 3
• Subconjunto de tuplas em uma dada relação
– Agrupar linhas criando subconjuntos segundo um
determinado critério
– Cada critério é uma condição geralmente relacionada a
um único atributo
– Algébra relacional - através do operador de seleção
– Conjunto de fragmentos gerados pelas condições (C1,
C2, … Cn) incluem todas as tuplas de R
• Podem ou não ser disjuntos
– Reconstruir a relação R: operação de união
113
Cap. 3
Exemplo:
Empregado
José Silva 0192022 M 020201212 2300,00 05
Carlos Torres 2121222 M 020201212 3000,00 05
Márcia Camargo 2233223 F 898989899 2500,00 06
Rui Madsen 0857489 M 898989899 3880,00 06
Cap. 3
Sobre uma mesma tabela lógica são definidos fragmentos
verticais e horizontais. Em analogia com as operações da
álgebra relacional ou seja é a combinação entre fragmentação
horizontal e vertical Algébra relacional - através do operador de
projeção e seleção Reconstruir a relação R: operação de junção
e união - ordem apropriada
115
Cap. 3
Sobre uma mesma tabela lógica são definidos fragmentos
verticais e horizontais. Em analogia com as operações da
álgebra relacional ou seja é a combinação entre fragmentação
horizontal e vertical Algébra relacional - através do operador de
projeção e seleção Reconstruir a relação R: operação de junção
e união - ordem apropriada
116
Cap. 3
4.2 Características Desejáveis em Bancos de Dados

Distribuídos
Trata-se de um único BD lógico, armazenado em múltiplas
localizações físicas. Isto é diferente de diversos BD diferentes em
diferentes locais. Permite que os dados sejam acessados localmente
e gerenciados globalmente, podendo fornecer informações confiáveis
em qualquer lugar. Sistema Gerenciador de Banco de Dados
Distribuído (SGBDD) é que administra a distribuição dos dados.

Autonomia Local - o SGBD de cada local deve ser autónomo, isto
é, ele deve ser gerenciado em cada local independentemente dos
outros locais de uma rede de computador. O processamento de uma
questão pode necessitar de cooperação de vários nodos. Todo esse
processo é coordenado pelo sistema sem intervenção dos
utilizadores.
117
Cap. 3

Distribuídos
Importância Equivalente entre BD Locais - todos os locais do
BDD são igualmente importantes e nenhum local é crítico para a
execução completa de uma transacção.

Operação Contínua - devido à possibilidade de termos réplicas de
dados em múltiplos locais, o SGBDD deve estar sempre operacional.
As alterações na rede, por adição de novos nodos ou remoção dos
existentes, assim como falha dos nodos, não devem impedir os
restantes nodos de continuarem a sua operação, se não total pelo
menos parcial.

Independência da Localização e Segmentação dos Dados - não
é necessário que o usuário e/ou programador de aplicação saibam
onde estão localizados fisicamente os dados, nem especifiquem
como uma tabela deva ser segmentada.
118
Cap. 3

Distribuídos
Independência de Replicação dos Dados - é transparente para o

usuário e/ou programador de aplicação, se a propagação das
actualizações é síncrona ou assíncrona, e onde as replicações estão
armazenadas.

Independência de Hardware, SO, Rede e SGBD - capacidade de
rodar em múltiplas plataformas de hardware, ilimitados SO’s e
sistemas de rede ou protocolos; e um sistema de BDD heterogéneo
deve funcionar como se fosse homogéneo.

A transparência é o que torna possível sua utilização, nem os
usuários, nem os programadores precisam saber onde ou como os
dados estão armazenados. Para ambos, as operações parecem ser
efectuadas sobre um único BD contíguo.
119
Cap. 3
4.3 Concepção de bases de dados distribuídas

A concepção de bases de dados distribuídas relaciona-se com a
forma como a base de dados global (esquema lógico) vai ser
distribuída pelos vários nodos (esquema físico).
Existem duas abordagens:

Top_down – corresponde à divisão de uma base de dados pré-
existente ou, mais genericamente, de um esquema de bases de
dados pré-definido em várias partes a armazenar em diferentes
nodos. Normalmente, o resultado deste processo será um
ambiente distribuído homogéneo de bases de dados.

Boton-up – corresponde a integração de várias bases de dados
pré-existentes numa base de dados global, distribuída por várias
máquinas. Dada a mais que provável heterogeneidade das várias
bases de dados em presença, esta será a abordagem que mais
dificuldades oferece.
120
Cap. 3

O projecto de uma base de dados distribuída consiste, basicamente,
em decidir como distribuir as tabelas que suportam o modelo
conceptual de dados global pelos vários nodos da rede, sendo certo
que diferentes distribuições resultarão, certamente, em diferentes
desempenhos e custos de exploração do sistema global.

Nesta fase decide-se, então, quais as tabelas locais (isto é, que vão
residir por inteiro num único nodo) e a que nodos correspondem;
Quais as tabelas a fragmentar, como as fragmentar, como as
fragmentar e onde serão armazenados os fragmentos; quais as
tabelas ou fragmentos a duplicar e em que nodos se duplicarão.
121
Cap. 3
Análise e modelação de dados
Modelo de dados global
Cocepcão da base de dados global
Esquema conceptual global

Análise dos requisitos de distribuição
Esquema local 1 Esquema local N
122
Cap. 3
4.4 Processamento e optimização de questões
Basicamente, aquilo que distingue o processo de optimização de

questões nos sistemas centralizados dos sistemas distribuído são
dois aspectos:
A utilização de meios de comunicação;
O aproveitamento do paralelismo inerente aos sistemas
distribuídos.

Em sistemas distribuídos o processamento de questões envolvendo
dados de nodos distintos coloca-se a dois níveis. Por outro lado,
tentar minimizar, em termos de recursos (tráfego na rede), o custo
total do processamento da questão; por outro lado, tentar minimizar o
se tempo de resposta.
123
Cap. 3
4.5 Bases de dados distribuídas heterogéneas

Abordagens para integração de bases de dados distintas numa base
de dados heterogénea:
Utilização de database gateways/middleware – Trata-se da
abordagem normalmente utilizada quando se encontram presentes
SGBDs diferentes, mas baseados no mesmo modelo de dados.

Integração num modelo global – é a abordagem adequada quando
os SGBDs presentes se baseiam em modelos de dados diferentes.
Neste caso, é necessário utilizar um modelo global onde os modelos
locais são mapeados.

Objectos distribuídos – dadas as características intrínsecas ao
próprio modelo OO (objectos comunicando-se entre si através de
mensagens), este ajusta-se de forma natural aos ambientes
distribuídos, em que os objectos se encontram geograficamente
dispersos, comunicando entre si através de mensagens que
percorrem a rede. 124
Cap. 3

Utilização de database gateways/middleware
A função dos gateways é fazer traduções entre formatos de dados e
comandos das várias implementações, permitindo que cada SGBD
“veja” todos os outros como seus iguais.
Oracle SGBD SGBD INGRES
Gateways Oracle
DB2 SGBDSGBD Gateways DB2
Gateways INGRES
Integração por gateways de bases de dados
125
Cap. 3

Integração num modelo global
A ideia é criar uma camada sobre os vários sistemas de bases de
dados componentes, dando a ilusão de um sistema homogéneo.
Dentro desta linha de desenvolvimento, definem-se dois grupos de
sistemas:

Esquema unificado - utilizando um modelo suficientemente
rico, capaz de integrar os restantes modelos, faz-se a integração
dos esquemas das bases de dados participantes num único
esquema unificado e global.

Multibase de dados - neste tipo de solução não se procura um
esquema global as bases de dados participantes. Cada base de
dados local opera de forma autónoma e independente, existindo,
no entanto, capacidade de cooperação entre si.
126
Cap. 3

Integração num modelo global
Utilizadores globais
Multibase de dados
Base de Base de Base de

dados 1 dados 2 dados N
Utilizadores locais
Integração em multibase de dados
127
Cap. 3
4.6 Gestão de bases de dados distribuídas

Agravamento de problemas com a gestão das transacções
globais
Uma transacção distribuída continue a satisfazer as
características de atomicidade, integridade, isolamento e
durabilidade, é necessário que haja coordenação das varias
subtransacção locais que constituem a transacção global
distribuída.
As características de integridade e isolamento da transacção
global são asseguradas por cada uma das subtransacções
locais. As subtransacções da transacção global não só
necessitam ser sincronizadas com as transacções locais a cada
nodo, como também com as outras transacções globais activas
no sistema. O controlo da concorrência assume, desta forma,
uma maior complexidade.
128
Cap. 3

Agravamento de problemas com a gestão das transacções
globais (integridade e isolamento)
Cada subtransacção local deve ser atómica, no sentido em que
ou todas as suas operações sucedem ou nenhuma é executada.

A transacção global deve ser atómica, no sentido em que ou
todas as operações sucedem ou nenhuma é executada.
 Resolução uso do protocolo two-phase commit (2PC).
129
Cap. 3

Resolução uso do protocolo two-phase commit (2PC)
1ª fase – o nodo coordenador envia a cada nodo participante na
transacção uma mensagem de preparação para o commit. A esta
mensagem, cada nodo deve responder de forma afirmativa (se esta
pronto para fazer o commit da sua subtransacção local) ou de forma
negativa (se a respectiva transacção local abortou e já esta desfeita).
Esta fase termina todos es nodos envolvidos respondem ao nodo
coordenador.

2ª fase – caso todas as respostas à 1ª fase sejam afirmativas, então
o nodo coordenador envia uma instrução de commit a cada nodo
participante, aguardando uma confirmação da sua parte. Basta que
um dos nodos tenha respondido negativamente à 1ª fase (ou não
tenha sequer respondido timeout) para que o nodo coordenador
envie uma mensagem de abort a todos os nodos participantes, para
que estes façam o rollback das respectivas subtransacções locais.
130
Cap. 3

Transação distribuida terminada Transação distribuida
com sucesso abortada
1ª
1 Sim 1 Sim
2 2
F
A 1 1
S
e 2 2
2ª
3 terminado 4 3 terminado 4
F
A 3
S
e 4
131
Cap. 3

 Problemas
 Demasiado restritivo (basta que um dos nodos participantes
falhe, ou não esteja acessível pela rede (rollback);
Se o nodo coordenador falhar após a 1ª fase, antes de enviar a
instrução de commit ou de abort;
Uso do protocolo three-phase commit (3PC), em que existe um
passo intermédio, designado pre-commit, que confirma que todos os
nodos estão em condições de finalizar.
 Problemas
 Aumenta ainda mais o trafego de mensagens de coordenação
entre os nodos (não comercializável).
 Agravamento de deadlocks
132
Cap. 3
4.7 Vantagens, limitação e perspectivas futuras

A existência duma organização que se encontre distribuída
geograficamente;
A distribuição dos dados por varias maquinas, possibilita um
crescimento virtualmente ilimitado das capacidades de
processamento;
Transporta, implicitamente, uma maior resistência a falhas;
Apesar de não ser completamente evidente, o desempenho
global de um sistema de bases de dados distribuídas pode ser
superior ao da mesma versão centralizada.
Uma vez que os dados estão repartidos por vários sistemas
(nodos), é natural que, numa base de dados distribuída, o
processamento local a um nodo resulte mais rápido.
133
Capítulo 4
Data Warehouse
• Introdução ao Data Warehouse
– Sistemas de Apoio à Decisão
– Conceitos de Data Warehouse
– Principais Características
• Arquitectura do Data Warehouse
– Estrutura Interna
– Granularidade
– Data Marts
–Metadados
– Acesso aos Dados
– Tipos de DW 134
Sistemas de Apoio à Decisão
• Informação
– Melhor recurso do qual uma empresa pode dispor
para tomar decisões estratégicas
– Obtida analisando dados históricos sobre vendas,
produção, clientes, etc.
• Análise dos dados
– Fornece informações vitais para a empresa
– Pode aumentar a competitividade da empresa
– Era feita intuitivamente pelos gerentes
135
• Dificuldades para obter informação
– Quantidade de dados a serem analisados cresce
com a expansão do negócio e com o passar dos
anos
– Dados conflitantes vindos de fontes diferentes
podem gerar informações desencontradas
– Impossível para um ser humano manter e analisar
todos os dados
– Informação não é mais mantida por gerentes
devido à mobilidade no mercado de trabalho
136
• Sistemas de Apoio à Decisão (SAD)
– Usam dados históricos mantidos em um banco de
dados convencional
– Dados históricos são analisados usando técnicas
de mineração de dados para obter informações
usadas na tomada de decisões
– Estatísticas de venda, produção, clientes, etc.
podem ser levantadas e consideradas para tomar
decisões estratégicas de negócio
137
• Benefícios dos Sistemas de Apoio à Decisão
– Determinar o mercado-alvo de um produto
– Definir o preço de um produto, criar promoções e
condições especiais de compra
– Verificar a eficácia de campanhas de marketing
– Optimizar a quantidade de produtos no estoque
– Responder rapidamente a mudanças no mercado e
determinar novas tendências
... ou seja, ganhar eficiência e lucratividade
138
• Problema: dados históricos não são mantidos nos
BDs da empresa
– Volume de dados seria muito grande
– Desempenho seria insatisfatório
• Solução: criar um BD exclusivamente para manter os

dados históricos
– Especializado para realizar poucas consultas sobre um
grande volume de dados
– Surge o Data Warehouse (DW)
139
Data Warehouse
• Histórico
– Criado pela IBM na década de 60 com o nome
Information Warehouse
– Relançado diversas vezes sem grande sucesso
– O nome Data Warehouse foi dado por William H.
Inmon, considerado o pai desta tecnologia
– Tornou-se viável com o surgimento de novas
tecnologias para armazenar e processar uma
grande quantidade de dados
140
Data Warehouse
• O que é?
– Sistema que armazena dados históricos usados no
processo de tomada de decisão
– Integra os dados corporativos de uma empresa em um
único repositório
• Para que serve?
– Para criar uma visão única e centralizada dos dados que
estavam dispersos em diversos BDs
– Permite que usuários finais executem consultas, gerem
relatórios e façam análises
141
Data Warehouse
• BDs usados nas aplicações de negócio são
chamados BDs operacionais
• DW é um BD informacional alimentado com
dados dos BDs operacionais da empresa
– Disponibiliza dados actuais e dados históricos
– Dados podem ser sumarizados (condensados) para
que sejam analisados
– Contém também metadados, que são dados sobre os
dados armazenados no DW
142
Data Warehouse
• Então o Data Warehouse é apenas um BD que
contém também dados históricos?
• Para que seja considerado um Data
Warehouse, um banco de dados deve:
– Colectar dados de várias fontes
– Dados colectados devem ser transformados para
que haja uma visão única dos dados
– Dados devem ser usados por aplicativos para
obter informações que dêem apoio à decisão
143
Data Warehouse
BD Operacional Data Warehouse
Usuários Funcionários Alta administração
Utilização Tarefas cotidianas Decisões
estratégicas
Padrão de uso Previsível Difícil de prever
Princípio de Com base em Com base em
funcionamento transacções análise de dados
Valores Valores actuais Valores históricos e
dos dados e voláteis imutáveis
Detalhamento Alto Sumarizado
Organização dos Orientado a Orientado a assunto
dados aplicações
144
Principais Características
• De acordo com a definição dada por Inmon,
um Data Warehouse deve ser:
– Orientado a assunto
– Integrado
– Não-volátil
– Variável com o tempo
145
• Orientação a assunto
– Os dados em um DW são organizados de modo a facilitar a
análise dos dados
– Dados são organizados por assunto e não por aplicação,
como em BDs operacionais
Produtos
Histórico
Clientes
de Vendas
Aplicação Análise
de Venda Estoque de Vendas
146
• Integração
– Dados de um DW provém de diversas fontes
– Dados podem ser sumarizados ou eliminados
– Formato dos dados deve ser padronizado para
uniformizar nomes, unidades de medida, etc.
UK Data
C
Produtos
Peso (lb) o Warehouse
Brasil n
v
Peso (kg) e Peso (gr) Produtos
Produtos
r
USA s
Peso (oz)
ã
Produtos o
147
• Não-Volátil
– Dados não são mais alterados depois de incluídos
no DW
– Operações no DW
• Em um BD operacional é possível incluir, alterar e
eliminar dados
• Já no DW é possível apenas incluir dados
– Garante que consultas subsequentes a um dado
produzirão o mesmo resultado
148
• Variável com o Tempo
– Os dados no DW são relativos
a um determinado instante de tempo
Produto Preço
BD Caneta Azul 0,50
Preços Lápis Preto 0,30
... ...
Produto Jan/03 Fev/03 Mar/03

Caneta Azul 0,40 0,45 0,50
DW
Lápis Preto 0,25 0,28 0,30
Preços
... ... ... ...
149
Arquitectura do Data Warehouse
• Sistemas de Extração Tradicionais
Dados
Operacionais
Sistemas de
Extração
Dados
Informacionais
150
• Sistemas baseados em Data Warehouse
Dados
Operacionais
Data
Warehouse
Dados
Informacionais
151
• Principais tarefas efectuadas pelo DW
– Obter dados dos BDs operacionais e externos
– Armazenar os dados
– Fornecer informações para tomada de decisão
– Administrar o sistema e os dados
• Principais componentes do DW
– Mecanismos para acessar e transformar dados
– Mecanismo para armazenamento de dados
– Ferramentas para análise de dados
– Ferramentas de gerência
152
Estrutura Interna
• Requisitos do DW
– Eficiente
• Grande volume de dados imutáveis
• Processamento paralelo e/ou distribuído
– Confiável
• Funcionamento do sistema
• Resultado das análises
– Expansível
• Crescente volume de dados
• Maior número de fontes de dados
153
Estrutura Interna
• Em geral são usados BDs relacionais para
armazenar os dados do DW
– Capazes de manter e processar grandes volumes
de dados
– Optimizados para lidar com dados imutáveis
• As ferramentas de análise empregam:
– Técnicas de mineração de dados
– Inteligência artificial: redes neurais, fuzzy, etc.
– A Internet: Web mining, agentes móveis, etc.
154
Estrutura Interna
Clientes Operacionais BDs Operacionais BDs Externos
Obtenção
de Dados
Gerenciamento
Data Warehouse
Clientes Informacionais
Busca de
Informações
155
Estrutura Interna
• Obtenção de Dados
Oracle
SQL Server Extrair Transformar Carregar

• Dados operacionais • Limpar • Organizar
• Dados externos • Reconciliar • Combinar
DB2 Data
• Aprimorar várias fontes
Warehouse
• Sumarizar • Popular sob
• Agregar demanda
InterBase
Arquivos
156
Estrutura Interna
• Busca de Informações
Localizar Analisar
• Catálogo de • Análise multi-
Data informações dimensional
Warehouse • Visualização • Data mining
de negócios • Consultas
• Modelos e relatórios
Armazenar
• Dados
relacionais
• Cache
• Várias
plataformas
157
Estrutura Interna
• Modelo de Camadas
Dados Operacionais Dados Externos
Acesso aos Dados
Gerenc. de Processos
Troca de Mensagens
Data Staging
Data Warehouse Físico
Acesso aos Dados
Acesso à Informação 158

Estrutura Interna
• Funções das Camadas do DW
– Dados Operacionais/Externos: fontes de dados
– Acesso aos Dados: extrair dados dos BDs
– Data Staging: transformar e carregar dados
– Data Warehouse Físico: armazenar dados
– Acesso aos Dados: localizar dados para análise
– Acesso à Informação: analisar dados
– Troca de Mensagens: transportar dados
– Gerenc. de Processos: controlar actividades
159
Granularidade
• Granularidade
– Nível de detalhe dos dados
– De extrema importância no projeto do DW
Dados Nível médio Dados pouco
detalhados de detalhe detalhados
Granularidade
160
Granularidade
• Definir a granularidade adequada é vital para
que o DW atenda seus objectivos
– Mais detalhes  Mais dados  Análise mais
longa  Informação mais detalhada
– Menos detalhes  Menos dados  Análise mais
curta  Informação menos detalhada
• Para evitar que se perca informação são
criados vários níveis de granularidade
161
Granularidade
• Dados x Granularidade
– Dados Actuais
• Reflectem acontecimentos recentes
• Alto nível de detalhe (baixa granularidade)
– Dados Sumarizados (1 ou + níveis)
• Dados históricos condensados
• Menor nível de detalhe (maior granularidade)
– Dados Antigos
• Dados históricos mantidos em fita, CD, etc
• Alto nível de detalhe (baixa granularidade)
162
Granularidade
• Processo de sumarização
– Aplica um novo esquema de modo a condensar os
dados
– Ex.: armazenar totais, médias, etc.
• Processo de envelhecimento
– Transfere os dados antigos do HD para fita, CD,
etc.
– Mantém o nível de detalhe para que nenhuma
informação seja perdida
163
Granularidade
Dados
Altamente
Sumarizados
Dados
Ligeiramente
Sumarizados
Sumarização
Dados Atuais
Envelhecimento
Dados
Antigos
164
Granularidade
• Exemplo: Companhia Telefónica [Inmon]
Dados Sumarizados
Dados Detalhados
Resumo das
Sumarização ligações feitas
pelos clientes
Ligações feitas
pelos clientes Dados Antigos
nos últimos
12 meses Envelhecimento
Ligações
feitas pelos
clientes
165
Granularidade
• Exemplo: Companhia Telefónica (cont.)
Dados Detalhados Dados Sumarizados Dados Antigos
Ligações Ligações Ligações

Origem Cliente Origem
Destino Mês Destino
Início Pulsos Início
Fim LongaDist Fim
Tarifa ValConta Tarifa
Status Status
No de registros: No de registros: No de registros:

ligações nos contas emitidas ligações efetuadas
últimos 12 meses pela empresa pela empresa
166
Granularidade
• Quanto menor a granularidade, mais detalhada é a
informação disponível
– No exemplo anterior, poderíamos determinar se o cliente
A ligou para B na semana passada
– Também poderíamos verificar se A faz muitas chamadas
de longa distância
• Durante o processo de sumarização, algumas
informações podem ser perdidas
– Não seria possível saber se A ligou para B
– É possível verificar o padrão de consumo de A
167
Data Marts
• Dados mantidos no DW são separados por
assunto em subconjuntos de acordo com:
– A estrutura interna da empresa
– O processo de tomada de decisão
• Estes subconjuntos dos dados são chamados
de Data Marts
Data Mart Data Mart Data Mart Data Mart

Financeiro Vendas Marketing Produção
168
Data Marts
• Um Data Mart desempenha o papel de um
DW departamental, regional ou funcional
• Uma empresa pode construir seus Data Marts
gradativamente a partir do DW
Data
Warehouse
Data Mart Data Mart Data Mart Data Mart

Am. Latina EUA Europa Ásia
169
Data Marts
• Dados podem ser repetidos em dois ou mais
Data Marts
• Os mesmos dados podem estar representados
com granularidade diferente
• Ex:
Data Mart  Vendas detalhadas
Vendas
 Vendas totais mensais

Data Mart
Financeiro
170
Metadados
• Os Metadados são dados sobre os dados
– Para cada atributo mantido no DW há uma
entrada no dicionário de dados
– Os dados são processados, actualizados e
consultados partindo dos metadados
– Usuários ficam conhecendo a estrutura e o
significado dos dados
– No BD operacional, a estrutura e o significado dos
dados estão embutidos nas aplicações
171
Metadados
• Camadas de Metadados
– Metadados Operacionais
• Definem a estrutura dos dados operacionais
– Metadados do DW
• Orientados por assunto
• Informam como os dados do DW foram calculados e
como devem ser interpretados
– Metadados do Usuário
• Organizam os metadados do DW com base em
conceitos familiares ao usuário final
172
Metadados
• Classificação em função dos dados descritos
– Metadados de Mapeamento
• Como BDs operacionais são mapeados no DW
– Metadados de Sumarização
• Como os dados foram sumarizados no DW
– Metadados Históricos
• Como a estrutura dos dados vem mudando
– Metadados de Padrões de Acesso
• Como os dados do DW vem sendo acessados
– Metadados de Miscelânea
173
Metadados
• Fontes de Metadados
– Código fonte dos SBDs operacionais
– Diagramas CASE de BDs operacionais e do DW
– Documentação dos BDs operacionais e do DW
– Entrevistas com usuários, administradores e
programadores dos BDs e do DW
– O ambiente de DW
• Frequência de acesso aos dados, tempo de resposta, controle de
usuários, etc.
174
Acesso aos Dados
• Acesso em Duas Camadas
Fontes de Servidor
Dados de DW Data Warehouse
• Acesso em Três Camadas
Fontes de Servidor
Dados de DW Data Warehouse
Servidor Aplicação do Usuário

de Aplic. Aplicação do Usuário
175
Tipos de Data Warehouse
• DW baseado em Servidor
– Mainframe ou servidor de rede local (LAN)
• DW Virtual
– Reúne dados operacionais e dados históricos
mantidos em BDs – não há um DW central
• DW Distribuído
– DW global reúne dados de vários DWs locais
• DW baseado na Web
– Dados provenientes da World Wide Web
176
Capítulo 5
Data Warehouse – Modelo Multidimensional
Modelo Multidimensional
•Definição
•Elementos básicos (factos, dimensões, medidas)
•Modelo estrela
•Modelo estrela - representação relacional
•Modelo Floco de neve
•Exercícios.
177
Modelagem Multi dimensional
Definição
– É uma técnica aplicada para criar modelos conceptuais de
negócios, que facilita a investigação, o resumo e a
organização de dados para a análise.
• mais simples para usuários comuns

• facilidade na elaboração de consultas
178
Elementos Básicos
• Factos
– Medidas de desempenho
• Dimensões
– contexto de um fato
• Medidas (variáveis)
– representação numérica de um fato
• Os fatos são organizados em uma única grande tabela,

indexada por uma chave composta por chaves individuais de
cada dimensão
179
Elementos Básicos - exemplo
• Assunto: vendas
– Fato: venda
– Dimensões: cliente, local, produto, Vendedor,
Tempo
– Medidas: quantidade, valor, lucro
produto
tempo vendedor
venda
cliente local
180
Modelo Estrela (representação relacional)
Produto
Vendedor
CodProduto Cliente
CodVendedor Nome
Nome Tipo CodCliente
CPF Nome
Endereço
Vendas
CodProduto
CodLocal
Tempo CodTempo
CodTempo CodCliente
Dia CodVendedor Local
Mês Quantidade
Ano Valor CodLocal
Lucro Província
Distrito
181
Modelo Snowflake (Floco de Neve)
• Obtido através da aplicação da 3a. Forma Normal sobre as

entidades dimensão
• Economia no armazenamento
• Menor redundância em valores textuais
• Necessidade de utilizar mais tabelas nas consultas (joins)
• Mais hierarquizado
182
Modelo Snowflake (representação relacional)
Produto Cliente
CodProduto CodCliente
Nome Nome
Tipo Endereço Distrito
CodLocal
Vendedor Distrito
CodVendedor Vendas CodProv
Nome CodProduto
CPF CodLocal
CodTempo
Provincia
Tempo CodCliente
CodProv
CodTempo CodVendedor
Província
Dia Quantidade
Mês Valor
Ano Lucro 183
Create Table Produto Create Table Vendedor
(CodProduto int, CodVendedor
Nome varchar(30), Nome varchar(30),
Tipo Varchar(10), CPF varchar(10),
Constraint Ch_pri_Produto Constraint Ch_pri_Vendedor
Primary key (CodProduto)); Primary key (CodVendedor));
Create Table Local Create Table Cliente
(CodLocal int, (CodCliente int,
Província varchar(30), Nome varchar(30),
Distrito varchar(30) Endereço varchar(30),
Constraint Ch_pri_Local Constraint Ch_pri_Cliente
Primary key (CodLocal)) Primary key (CodCliente))
184
Create Table Tempo
(CodTempo int, Dia Varchar(2),
Mês Varchar(12), Ano Varchar(8),
Constraint Ch_pri_Tempo Primary key (CodTempo));
Create Table Vendas

(CodProduto int, CodLocal int, CodTempo int, CodCliente int,
CodVendedor int, Quantidade float, Valor float,
CONSTRAINT Ch_pri_Vendas Primary KEY (CodProduto, CodLocal, CodTempo,
CodCliente, CodVendedor),
CONSTRAINT Ch_estr_Vendas_Produto FOREIGN KEY (CodProduto)
REFERENCES Produto (CodProduto),
CONSTRAINT Ch_estr_Vendas_Local FOREIGN KEY (CodLocal)
REFERENCES Local (CodLocal),
CONSTRAINT Ch_estr_Vendas_Tempo FOREIGN KEY (CodTempo)
REFERENCES Tempo (CodTempo),
CONSTRAINT Ch_estr_Vendas_Cliente FOREIGN KEY (CodCliente)
REFERENCES Cliente (CodCliente),
CONSTRAINT Ch_estr_Vendas_Vendedor FOREIGN KEY (CodVendedor)
REFERENCES Vendedor (CodVendedor));
185
Exemplo 1
–Pretende-se conhecer a Venda líquida, em Meticais e em
unidades por produto, por loja, por semana, por companhia, nos
últimos 5 anos.
Facto: Dimensões:
•Vendas •Cliente
•Produto
Medidas •Tempo
•Unidades vendidas •Etc...
•Valor
•Etc...
186
Produto
Vendedor CodProduto
CodVendedor Nome Cliente
Nome Tipo CodCliente
CPF Nome
Endereço
Vendas
CodProduto
Tempo
CodLocal
CodTempo
CodTempo
Dia Local
CodCliente
Mês CodLocal
CodVendedor
Ano Província
Quantidade
Valor Distrito
187
Exemplo2:
A companhia aérea de Maputo fornece serviços de voos charter
“on demand”, usando um mix de aviões e tipos de aviões. O
gestor de operações pretende analisar dados dos voos charter,
como por exemplo custo, horas de voo, combustível gasto e
receita. Também pretende realizar drill-downs por piloto,
cliente, avião, tipo de avião e período de tempo (semana, mês,
trimestre, ano). Os requisitos para a datawarehouse são:
• Mostrar o número total de horas de voo por diferentes aviões,
clientes, pilotos, períodos de tempo (semana, mês e ano).
• Mostrar o custo total por aviões, clientes, pilotos e períodos de
tempo (semana, mês e ano).
• Mostrar a receita dos charters por pilotos, aviões, e por
diferentes períodos de tempo, etc.
Desenhe o esquema em estrela da datawarehouse
188
Tempo
Aviao Facto_Voo Cod_tempo
Cod_tempo Ano
Cod_aviao Cod_piloto Mes
marca Cod_aviao Semana
Tipo Cod_clientes
Custo_voo
Horas
Clientes Combustivel Pilotos
Cod_Clintes Receitas
Custo_clientes Cod_piloto
Nome
Nome
189
Exemplo 3:
Suponha que uma datawarehouse é composta por quatro
dimensões: data, espectador, localização e jogo, sendo os factos
mensuráveis quantidade e tarifa, onde tarifa é o preço que um
espectador paga para assistir a um jogo numa determinada data
numa certa localização. Os espectadores podem ser estudantes,
adultos ou seniores, tendo cada uma destas categorias a sua
respectiva tarifa.
• Desenhe um diagrama em estrela para o datawarehouse. Para

cada dimensão, defina pelo menos três atributos
190
Tempo
Espectador Cod_tempo
Ano
Cod_espectador Facto_jogo Trimestre
Categoria
Cod_tempo Mes
Sexo
Cod_espectador Semana
Cod_jogo Dia
Cod_localização
Localização Quantidade Jogo
Cod_localização Tarifa
Cod_jogo
Provincia
Tipo_jogo
Distrito
Nome_jogo
191

Processamento de Transações, Recuperação de Dados e Controlo de Concorrência

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Processamento de Transações, Recuperação de Dados e Controlo de Concorrência

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE POLITÉCNICA

Sistema de Gestão de Bases de Dados II

Uma transacção é uma unidade lógica básica de

Uma unidade indivisível de processamento

Conta A João Alfredo 1000,00MT 500,00MT Conta A João Alfredo 500,00MT

Conta B Luís Sabão 500,00MT

Begin transaction Execução da transacção end transaction

Atomicidade. Uma transacção é unidade atómica de

Durabilidade. Se uma transacção altera a base de dados e é

A execução concorrente de transacções submetidas

A execução concorrente de transacções tem de ser

As instruções COMMIT e ROLLBACK (ou seus

Salvaguarda Periódica de Dados (Backup)

Redo: especifica que certas operações duma

meanwhile T2 has read the “temporary” incorrect value of X

 as transacções podem ser entrelaçadas

o Duas operações são conflituosas se elas pertencem a

o Uma escala S é em seriada se, para qualquer transacção T

o Nas escalas não-seriadas, as transacções são entrelaçadas.

o A teoria da seriabilidade tenta determinar a 'correcção' das

o Uma escala S de n transacções é serializável se é equivalente

o Um fecho descreve o estado do item em relação a possíveis

o Uma transacção tranca um objecto antes de o usar.

o Quando um objecto é trancado por uma transacção, qualquer

Fechos binários têm dois estados possíveis:

Fechos binários têm dois estados possíveis:

Y é destrancado demasiado Y é destrancado demasiado

•Escala 1: T1 seguida por T2 ⇒ X=50, Y=80

quando uma transacção liberta um fecho, ela pode

Cada uma das duas ou mais transacções está à espera

 Novas aplicações ficaram limitadas por restrições impostas pelo modelo

 As aplicações convencionais possuem características comuns que as

 As aplicações mais novas, em geral, não possuem, no mínimo,

 O termo chamar um método algumas vezes é usado para representar o ato de

 As mensagens às quais um objecto responde podem ser, de maneira similar,

 Para permitir a representação direta de similaridades entre classes, necessita-se colocar

 Este conceito é similar ao conceito de especialização no modelo E-R.

 Para tratar a hierarquia de classes tem-se duas opções:

escriturário caixa secretária

Escrit_TI Escrit_TP Caixa_TI Caixa_TP secretária_TI secretária_TP

 Existe falha na exploração da reutilização de código.

 Se existissem várias classificações de emprego, em vez de duas limitações neste exemplo,

tempo integral tempo parcial escriturário caixa secretária

escrit_TI escrit_TP caixa_TI caixa_TP secretária_TI secretária_TP

 Pode haver algum problema?

 Um objecto mantém sua identidade mesmo se alguns ou todos os seus valores

 Diferente do modelo relacional onde as tuplas de uma relação são

roda freio marcha quadro

Aro raio pneu pedal bloco cabo

O conceito de composição permite que os dados sejam vistos em

Fábrica {OID1125} Fábrica {OID1127} Fábrica {OID1128}

da_assistentencia Disciplinas possui_disciplinas

Relacionamentos Heranca Classe

class Professor extends Pessoa

class Aluno extends Pessoa

 Para que estes conceitos básicos de orientação a objectos sejam

 Persistência por criação: Um objecto é persistente ou transiente,

 Persistência por marcação: Todos os objectos são criados como

 Persistência por referência: Um ou mais objectos são explicitamente

Valida cardinalidade SIM

2.1 Identificação de chave primária

2.2 OIDs (Objects Identifiers)