SCC0141 - Bancos de Dados
e Suas Aplicações
Transações
Prof. Jose Fernando Rodrigues Junior
Material original: Profa. Elaine Parros Machado de Sousa
1
Transações

Transação: Unidade lógica de trabalho

abrange um conjunto de operações de manipulação de
dados que executam uma única tarefa
Conecta ao Banco de Dados
Começa transação
Operações de consulta/atualização
...
Finaliza transação
Começa transação
Operações de consulta/atualização
...
Finaliza transação
Desconecta
Transações

Transição de Estados de Execução
begin (start) transaction
ativa
read,
write
end
transaction
parcialmente
efetivada
commit
efetivada
abort
(rollback)
abort
(rollback)
falha
encerrada
Transações


O que acontece se a energia acabar no meio
de uma transação, ou se houver um
problema com o disco?
O que acontece quando duas transações
executam simultaneamente manipulando o
mesmo dado?
 O banco de dados pode ser levado a um
estado inconsistente...
Falhas
Tipo de falha
Local
Local
Global
De sistema
(soft crash)
Global
De meio físico
(hard crash)
Abrangência
Apenas a
transação
corrente
Todas as
transações em
andamento
Todas as
transações em
andamento
Como
evitar/recuperar
Registro de
log/controle de
concorrência
Registro de log
Backup
Transações –
Propriedades ACID




Atomicidade
Consistência
Isolamento
Durabilidade
Transações –
Propriedades ACID

Atomicidade: todas as operações de uma transação
devem ser efetivadas; ou, na ocorrência de uma falha,
nada deve ser efetivado


Consistência: transações preservam a consistência da
base



“tudo ou nada” – não se admite parte de uma operação
Estado inicial consistente  Estado final consistente
Isolamento: a maneira como várias transações em
paralelo interagem (o que pode ser lido e o que pode
ser escrito por cada uma) deve ser bem definido
Durabilidade: uma vez consolidada (committed) a
transação, suas alterações permanecem no banco até
que outras transações aconteçam
Transações –
Propriedades ACID

Atomicidade: todas
as operações
Recuperação
de falhasde uma transação
devem ser efetivadas; ou,viana
logocorrência de uma falha,
nada deve ser efetivado


Consistência: transações preservam a consistência da
base



“tudo ou nada” – não se admite parte de uma operação
Estado inicial consistente  Estado final consistente
Isolamento: a maneira como várias transações em
paralelo interagem (o que pode ser lido e o que pode
ser escrito por cada uma) deve ser bem definida
Durabilidade: umaRecuperação
vez consolidada
(committed) a
de falhas
transação, suas as alterações
via log permanecem no banco
até que outras transações aconteçam
Transações –
Propriedades ACID

Atomicidade: todas
as operações
Recuperação
de falhasde uma transação
devem ser efetivadas; ou,viana
logocorrência de uma falha,
nada deve ser efetivado


Consistência: transações
Controle depreservam
Concorrênciaa consistência da
base
via Locks



“tudo ou nada” – não se admite parte de uma operação
Estado inicial consistente  Estado final consistente
Isolamento: a maneira
como
várias transações em
Controle de
Concorrência
paralelo interagem (o que
via pode
Locks ser lido e o que pode
ser escrito por cada uma) deve ser bem definida
Durabilidade: umaRecuperação
vez consolidada
(committed) a
de falhas
transação, suas as alterações
via log permanecem no banco
até que outras transações aconteçam
Controle de Concorrência

Execução Serial (sequencial):
B
A
t1

t2
Execução Intercalada:
B
B
A
t1
A
t2
t3
t4
t5 tempo
t3
tempo
Controle de Concorrência

Execução
Serial
(sequencial):
transações executadas em sequência


diversas
deixa a base de dados em estado correto e consistente
Execução Intercalada: comandos de diversas
transações são intercalados

pode levar a inconsistências
Isolamento
Serial
Intercalada
Concorrência
Chance de
inconsistências
Execução Serial X Intercalada

Execução serial

estado inicial correto e consistente  estado final
correto e consistente
Execução Serial X Intercalada

Execução Intercalada

Toda execução serial é consistente

Mas uma execução intercalada só é consistente
se for igual ao resultado de uma execução em
sequência (em ordem conhecida)

esta execução é dita serializável
Problemas de Execução
Intercalada

Ocorrência de anomalias
1. leitura inválida
2. leitura não repetível
3. leitura fantasma
Problemas de Execução
Intercalada

1) Leitura inválida (Dirty Read):
 transação T’ lê
um dado modificado por uma
transação T que ainda não terminou;

permite que outras transações possam ver os
dados que ainda não foram consolidados
(committed), isto é, mudanças que podem ser
descartadas em seguida, por causa de uma
instrução ROLLBACK por exemplo.
Problemas de Execução
Intercalada

Ex: Leitura inválida (Dirty Read):
T1
tempo
Read(A)
Write(A+100)
T2
Exemplo 1:
Read(A)
Write(A  0)
rollback
• Transação T1: deposita R$100,00
na conta A.
• Transação T2: saca tudo de A.
commit
• T1 é cancelada
Problemas de Execução
Intercalada

Resultado:
foi possível
sacar R$
Ex: Leitura
inválida
(Dirty
Read):
100,00 a mais.
T1
tempo
Read(A)
Write(A+100)
T2
Exemplo 1:
Read(A)
Write(A  0)
rollback
• Transação T1: deposita R$100,00
na conta A.
• Transação T2: saca tudo de A.
commit
• T1 é cancelada
Problemas de Execução
Intercalada

Ex: Leitura inválida (Dirty Read):
T1
tempo
Read(A)
Write(A-100)
T2
• Transação T1: transfere
R$100,00 da conta A para a
Read(A-100)
conta B.
Write((A-100)+1%)
Read(B)
Write(B+100)
• Transação T2: incrementa A e B
em 1% (juros).
Read(B)
Write(B+1%)
rollback
Exemplo 2:
commit
Problemas de Execução
Intercalada

Exemplo 2:
Suponde que inicialmente A = 500 e B =
Read(A)
600
Write(A-100)
• resultado esperado: T1 (rollbacked)
Read(A-100)
Write((A-100)+1%) seguido de T2 é A = 505 (A+1%) e B =
606 (B+1%)
Read(B)
Write(B+100)
• no entanto, com T1 e T2 em paralelo,
o que se tem é: A = 404 (A - 100 + 1%)
Read(B)
e B = 707 (B+100 + 1%)
Write(B+1%)
T1
tempo
Ex: Leitura inválida (Dirty Read):
rollback
T2
commit
Problemas de Execução
Intercalada

Exemplo 2:
Suponde que inicialmente A = 500 e B =
Dirty read
Read(A)
600
Write(A-100)
• resultado esperado: T1 (rollbacked)
Read(A-100)
Write((A-100)+1%) seguido de T2 é A = 505 (A+1%) e B =
606 (B+1%)
Read(B)
Write(B+100) Dirty read
• no entanto, com T1 e T2 em paralelo,
o que se tem é: A = 404 (A - 100 + 1%)
Read(B)
e B = 707 (B+100 + 1%)
Write(B+1%)
T1
tempo
Ex: Leitura inválida (Dirty Read):
rollback
T2
commit
Problemas de Execução
Intercalada

Ex: Leitura
inválida
(Dirty
Read):
Resultado: a transferência de R$
100 de T1 foi
sobrescrita
e T2
Exemplo
2:
considerou valores
errados
como A = 500 e B =
Suponde
que inicialmente
Dirty
read
Read(A)
600de 1%. Ambos, A
base se cálculo
Write(A-100)
• resultado
esperado: T1 (rollbacked)
errados.
Read(A-100) e B estão
tempo
T1
T2
Write((A-100)+1%) seguido de T2 é A = 505 (A+1%) e B =
606 (B+1%)
Read(B)
Write(B+100) Dirty read
Read(B)
Write(B+1%)
rollback
commit
• no entanto, com T1 e T2 em paralelo,
o que se tem é: A = 404 (A - 100 + 1%)
e B = 707 (B+100 + 1%)
Problemas de Execução
Intercalada

2) Leitura não repetível (Nonrepeatable Read):




transação T lê um dado
esse dado é modificado por uma transação T’ que
começou depois de T
T é efetivada
se T’ tentar reler o mesmo dado, obterá valores
diferentes (nonrepeatable read)
tempo
Problemas de Execução
Intercalada

Ex: Leitura não repetível (Nonrepeatable Read):
T1
T2
Read(A=lotado-1)
Write(A)
commit
Read(A=lotado-1)
Write(A  A+1)
commit
Exemplo:
• Transação T1: lê reservas de um
vôo e verifica que há apenas
um lugar disponível.
• Transação T2: lê a mesma coisa
• T2 reserva o último lugar e é
efetivada.
• T2 tenta reservar o lugar e
ocorre um erro.
Problemas de Execução
Intercalada

Ex: Leitura não repetível (Nonrepeatable Read):
T1
T2
tempo
Read(A=lotado-1)
Write(A)
commit
Read(A=lotado-1)
Write(A  A+1)
commit
Nonrepeatable
Read
Exemplo:
• Transação T1: lê reservas de um
vôo e verifica que há apenas
um lugar disponível.
• Transação T2: lê a mesma coisa
• T2 reserva o último lugar e é
efetivada.
• T1 tenta reservar o lugar e
ocorre um erro.
tempo
Problemas de Execução
Intercalada
Resultado: um usuário foi
de que(Nonrepeatable
ainda havia
 Ex: Leitura informado
não repetível
Read):
lugares. Após preencher o
clicou confirma e
Exemplo:
T1
T2 cadastro,
recebeu um erro de que o vôo
Read(A=lotado-1)
• Transação T1: lê reservas de um
Read(A=lotado-1)
estava lotado.
vôo e verifica que há apenas
Write(A  A+1)
commit
um lugar disponível.
Write(A)
commit
Nonrepeatable
Read
• Transação T2: lê a mesma coisa
• T2 reserva o último lugar e é
efetivada.
• T1 tenta reservar o lugar e
ocorre um erro.
Problemas de Execução
Intercalada
Repeatable read? Mas não está
tempo

uma nova
leitura, mas
Ex: Leituraocorrendo
não repetível
(Nonrepeatable
Read):
sim uma escrita.
Exemplo:
T1
T2
Na verdade, há uma nova leitura
Read(A=lotado-1)
• Transação T1: lê reservas de um
Read(A=lotado-1)
pelo SGBD que validará a entrada
vôo e verifica que há apenas
Write(A  A+1)
de inserí-los.
commit dos dados antes
um
lugar
disponível.
Write(A)
commit
Nonrepeatable
Read
• Transação T2: lê a mesma coisa
• T2 reserva o último lugar e é
efetivada.
• T1 tenta reservar o lugar e
ocorre um erro.
Problemas de Execução
Intercalada

3) Leitura fantasma (Phantom Read):



transação T lê um conjunto de tuplas que
atendam a uma condição de consulta
transação T’ insere/remove/atualiza uma tupla
que atenderia a essa condição e é efetivada
se T refizer a mesma consulta, obterá um
conjunto diferente de tuplas (phantom read)
Problemas de Execução
Intercalada

Ex: Leitura fantasma (Phantom Read):
T1
T2
tempo
Query( )
Report()
Update( )
commit
Query( )
Report( )
commit
Exemplo:
• Transação T1: faz uma consulta que
retorna a média geral dos alunos que
têm média ponderada acima de 5.0, e
gera um relatório
• Transação T2: atualiza as notas de
alguns alunos e é efetivada
• T1 refaz a consulta para gerar
relatório com nro de alunos por faixa
de média
 relatórios inconsistentes.
Problemas de Execução
Intercalada

Ex: Leitura fantasma (Phantom Read):
Repeatable read vs Phantom read
Exemplo:
 Repeatable read:
lê valores
de umque
• Transação
T1:diferentes
faz uma consulta
Query( )
retornaestá
a média
geral
alunos que
mesmo dado que ainda
lá, mas
foidos
alterado
Report()
têm média ponderada acima de 5.0, e
Update( )
gera um relatório
 Phanton
de dados diferentes,
commitread: lê conjuntos
Transação T
as que
notasnão
de
2: atualiza
sendo que um dos• conjuntos
possui
dados
Query( )
alguns alunos e é efetivada
existem
no(s)
outro(s)
conjunto(s) – fantasmas.
Report( )
• T1 refaz a consulta para gerar
commit
relatório com nro de alunos por faixa
de média
 relatórios inconsistentes.
tempo
T1
T2
Problemas de Execução
Intercalada  Isolamento

Ocorrência de anomalias
1.
leitura inválida: leu um dado errado, o que causou
uma operação inconsistente;
2.
leitura não repetível: tentou ler um dado que foi
alterado, impedindo que uma operação consistente
fosse concluída;
3.
leitura fantasma: teve alterado o conjunto de tuplas
envolvidas em uma seleção – fazendo com que uma
operação tenha resultados diferentes em momentos
diferentes da transação
Problemas de Execução
Intercalada  Isolamento

Ocorrência de anomalias
Um mesmo dado é escrito e lido em paralelo.
1.
leitura inválida: leu um dado errado, o que causou
Solução: bloquear o dado que foi escrito, mas que ainda não foi consolidado, até que
uma
operação
a transação
de escrita
termine.inconsistente;
Uma transação só vê apenas os dados commited antes de seu início.
Um
dado lido
e escrito
em paralelo.
2.mesmo
leitura
não
repetível:
tentou ler um dado que foi
Solução: bloquear o dado que tenha sido lido até que a transação de leitura termine.
alterado,
impedindo
que bloqueia
uma operação
Evita leitura
inválida
e, além disso,
os dados consistente
depois de sua
primeirafosse
operação
de leitura ou escrita.
concluída;
Não há concorrência por um mesmo dado específico – o que ocorre é que os dados
envolvidos
variam
de maneirateve
imprevisível.
3.
leitura
fantasma:
alterado o conjunto de tuplas
Solução: bloquear conjuntos de tuplas inteiros até que a transação termine.
envolvidas
em uma
seleção
– fazendo
comsãoque
uma
Evita leitura
não repetível
e, além
disso, outras
transações
impedidas
caso elas
suas operações
comdiferentes
os dados da
transação
sendo
operação
tenhaintercalem
resultados
em
momentos
feita. diferentes da transação.
Transações –
Propriedades ACID

Atomicidade: todas as operações de uma transação
devem ser efetivadas; ou, na ocorrência de uma falha,
nada deve ser efetivado


Consistência: transações preservam a consistência da
base



“tudo ou nada” – não se admite parte de uma operação
Estado inicial consistente  Estado final consistente
Isolamento: a maneira como várias transações em
paralelo interagem (o que pode ser lido e o que pode
ser escrito por cada uma) deve ser bem definido
Durabilidade: uma vez consolidada (committed) a
transação, suas as alterações permanecem no banco
até que outras transações aconteçam
Problemas de Execução
Intercalada  Isolamento

Ocorrência de anomalias
1.
leitura inválida
2.
leitura não repetível
3.
leitura fantasma





Solução via isolamento em diferentes graus
Read uncommitted
Read committed
Repeatable read
Serializable
Interpretação
Nível de
isolamento
Anomalias que PODEM ocorrer
1) Leitura
inválida
2) Leitura não
repetível
3) Leitura
fantasma
Leitura mesmo do que
NÃO FOI committed
Sim
Sim
Sim
Leitura apenas do que
FOI committed
Não
Sim
Sim
Leitura apenas se a
leitura
repetida
for
garantida
Não
Não
Sim
Torna
a
execução
equivalente à execução
em série
Não
Não
Não
Níveis de Isolamento em
SQL99
Nível de
isolamento
Anomalias que PODEM ocorrer
1) Leitura
inválida
2) Leitura não
repetível
3) Leitura
fantasma
Read uncommitted
Sim
Sim
Sim
Read committed
Não
Sim
Sim
Repeatable read
Não
Não
Sim
Serializable
Não
Não
Não
Exercício

Considere as transações T1 e T2, executadas sobre
os itens de dado X e Y
T1
1.1)Read(X)
1.2)Read(Y)
1.3)Write(X)
1.4)commit
T2
2.1)Read(X)
2.2)Read(Y)
2.3)Write(X)
2.4)Write(y)
2.5)commit
1) Dê um exemplo de execução intercalada que resulte em
uma anomalia de leitura inválida e explique o porquê.
2) Dê um exemplo de execução intercalada que resulte em
uma anomalia de leitura não repetível e explique o
porquê.
Exercício

Considere as transações T1 e T2, executadas sobre
os itens de dado X e Y
T2
T1
2.1)Read(X)
1.1)Read(X)
2.2)Read(Y)
1.2)Read(Y)
2.3)Write(X)
1.3)Write(X)
2.4)Write(y)
1.4)commit
2.5)commit
1) Dê um exemplo de execução intercalada que resulte em uma
anomalia de leitura inválida e explique o porquê.
R.: 2.1,2.2,2.3,1.1,1.2,1.3,2.4,1.4,2.5
Aqui, T2 leu o valor de X e escreveu o valor de X (2.3), e antes de
consolidar este valor, T1 leu o valor de X (dirty read em 1.1), e
o reescreveu em 1.3. Em seguida T1 consolida os dados (1.4),
seguido da consolidação dos dados por T2 (2.5). Qual é o valor
de X, o que foi calculado por T2, ou o que foi calculado por T1?
Exercício

Considere as transações T1 e T2, executadas sobre
os itens de dado X e Y
T2
T1
2.1)Read(X)
1.1)Read(X)
2.2)Read(Y)
1.2)Read(Y)
2.3)Write(X)
1.3)Write(X)
2.4)Write(y)
1.4)commit
2.5)commit
1) Dê um exemplo de execução intercalada que resulte em uma
anomalia de leitura inválida e explique o porquê.
R.: exemplo, em T2 alguém transfere 100 de X para Y, situação em
que X deve ser X-100. antes que T2 termine no entanto, alguém
lê o saldo de X-100 e deposita mais 100. quando T1 terminar, T1
irá consolidar (X-100)+100, ao passo que T2 irá consolidar X100, anulando o que foi feito por T1.
Exercício

Considere as transações T1 e T2, executadas sobre
os itens de dado X e Y
T1
1.1)Read(X)
1.2)Read(Y)
1.3)Write(X)
1.4)commit
T2
2.1)Read(X)
2.2)Read(Y)
2.3)Write(X)
2.4)Write(y)
2.5)commit
2) Dê um exemplo de execução intercalada que resulte em
uma anomalia de leitura não repetível e explique o porquê.
R.: 1.1, 2.1, 2.2, 2.3, 1.2, 1.3, 1.4, 2.4, 2.5
Aqui T1 lê o valor de X, o que em seguida é alterado por T2
(2.3). T1 então tenta atualizar o valor de X (1.3), o qual
agora não aceita a atualização inicialmente pretendida por
T1.
Transações em Oracle
Transação em PostgreSQL

Comando SET TRANSACTION
SET TRANSACTION ISOLATION LEVEL {
SERIALIZABLE | REPEATABLE READ | READ
COMMITTED | READ UNCOMMITTED }
READ WRITE | READ ONLY
Transação em ORACLE

Comando SET TRANSACTION
SET TRANSACTION
READ ONLY | READ WRITE | ISOLATION LEVEL
{SERIALIZABLE | READ COMMITTED}|
USE ROLLBACK SEGMENT rollback_segment
NAME ‘nome_da_transacao’;
Níveis de Isolamento de
SQL99 no ORACLE
Nível de
isolamento
Anomalias que podem ocorrer
Leitura
inválida
Leitura não
repetível
Leitura
fantasma
Read uncommitted
Sim
Sim
Nunca permitido
em Oracle. Sim
Read committed
(padrão)
Não
Repeatable read
Não
Não
Não suportado especificamente
(abrangidoSim
por serializable).
Serializable
Não
Sim
Não
Sim
Não
Transações em ORACLE



Transações explícitas iniciam com a cláusula SET TRANSACTION
Em PostgreSQL, as transações se iniciam com START TRANSACTION
E terminam:
 explicitamente com commit ou rollback

execução de comando DDL
Possuem quatro possibilidades:
 Modo de leitura: para transações apenas leitura
 READ-ONLY, e READ-WRITE
 Modo de isolamento: para transações com atualizações
 READ committed, e SERIALIZABLE


implicitamente quando um processo de usuário é finalizado
 com sucesso – ex: disconnect (commit)
 sem sucesso – ex: falha de sistema (rollback)
Transação em ORACLE

Comando COMMIT



termina a transação
torna permanente as ações da transação
libera os recursos bloqueados
Transaçoes em ORACLE

Modo de isolamento:
atualizações

transações
com
READ committed (padrão):



para
antes de uma operação, a transação aguarda até que quaisquer tuplas
sendo atualizadas sejam liberadas e prossegue
a transação “vê” apenas dados consolidados (committed) antes do
início de uma dada operação
SERIALIZABLE:



caso uma tupla seja alterada após o início da transação serializable, se
houver uma tentativa de alteração desta tupla, será jogada a exceção:
ORA-08177: Can't serialize access for this transaction.
ou seja, o Oracle informa que não é capaz de tornar a concorrência
semelhante a um processamento em série
a transação “vê” apenas dados modificados pela própria transação e
dados efetivados antes do início da transação
Transaçoes em ORACLE

Modo de isolamento:
atualizações

para
transações
com
READ committed (padrão):
Idéia
deumaSnapshot
dos dados
umatuplas
antes de
operação, a transação
aguardaantes
até que de
quaisquer
sendo atualizadas
sejam
liberadas do banco.
operação
– vários
snapshots



a transação “vê” apenas dados consolidados (committed) antes do
início de uma dada operação
SERIALIZABLE:
caso uma tupla seja alterada após o início da transação serializable, se
houverde
uma tentativa
de alteração
tupla,antes
será jogada
Idéia
Snapshot
dos desta
dados
de a exceção:
uma
ORA-08177:
for this transaction.
transação
inteira Can't
– umserialize
únicoaccess
snapshot.
 ou seja, o Oracle informa que não é capaz de tornar a concorrência
semelhante a um processamento em série
 a transação “vê” apenas dados modificados pela própria transação e
dados efetivados antes do início da transação

Transações Distribuídas

Propriedades ACID devem ser
garantidas
 Atomicidade
Concorrência
distribuída
 Consistência
 Isolamento
Recuperação
de falhas
distribuída
 Durabilidade
48
Concorrência Distribuída

Problema: o mesmo dado replicado em diferentes sites A e B. No
site A, o dado é alterado, quase que imediatamente o site B usará
este dado, cuja cópia será diferente do valor no site A.

Solução: uso de locks. Quando o site A alterar o dado, deve-se
bloqueá-lo (lock) para uso e escrita até que A finalize sua operação e
o dado seja sincronizado com o site B.

Como gerenciar bloqueios (locks) de objetos (tabelas e fragmentos)
distribuídos?
 abordagem centralizada
 abordagem cópia primária
49
 abordagem completamente distribuída
Concorrência Distribuída

Baseada no conceito de Cópia Distinguida (ou Distinta): dentre
as várias cópias dos dados, uma delas dita como o controle de
concorrência é feito – isto é, uma única cópia recebe e libera
locks

A escolha da cópia que irá ditar o controle de concorrência pode
ser estático ou dinâmico

O site que possui a cópia distinguida é denominado site
Coordenador, o qual deverá responder ao sistema de locks
50
Concorrência Distribuída



Abordagem cópia primária
 bloqueios são gerenciados pelo site onde está a cópia primária
(original) do objeto requisitado
 problema? Maior complexidade
Abordagem completamente distribuída
 bloqueios
gerenciados nos sites onde ocorrem as operações –
coordenação dinâmica
 problema? Maior complexidade, necessidade de broadcast dinâmico
para informar sobre a coordenação
Abordagem centralizada
 um único site responsável por gerenciar todas as requisições de
bloqueio
 problema? Vulnerável a falhas, requer um backup – sobrecarga de um
único site
51
Recuperação de Falhas
Distribuída

Novos tipos de falha que não ocorrem em
SGBDs não distribuídos



falhas de comunicação
falha em um site onde uma sub-transação é
executada
Atomicidade:

ou todas as sub-transações são efetivadas
(committed) ou nenhuma deve ser efetivada
COMMIT protocol
Ex: Two-Phase Commit (2PC)
52
Recuperação de Falhas
Distribuída


Uso do two-phase commit protocol (2PC)
 Algoritmo
distribuído que visa gerenciar situações
transacionais – protocolo do tipo consensual
Duas fases
1ª. Contacta todos os participantes preparando-os para o
sistema de consenso, segundo o qual, após a execução
distribuída, cada um terá que “votar” sim (commit) ou não
(abort)
2ª. Efetivação da decisão consensual, todos são informados
de que devem consolidar a transação (todos votaram
commit) ou retornar ao estado anterior (pelo menos um
votou abort ou alcançou time-out)
53
Transações e Controle de
Concorrência

Referências



Oracle Database Concepts
OracleSQL Reference
Elmasri e Navathe. Fundamentals of Database
Systems