Modelo Relacional

1
Modelo Relacional
Pedro Nogueira Ramos (Pedro.Ramos_at_iscte.pt) DCTI
/ ISCTE
2
Relacional - Índice
Relação Produto Cartesiano Definição de
Relação Chave Primária Critérios para adopção
de Chave Primária Chave Estrangeira Integridade
da Chave Estrangeira Joins Transposição a
partir do UML
Especificação de Atributos Optimizações Índices A
rquivo Parameterização Transacções Concorrência
3
Modelo Relacional(Codd, 1970)
No Modelo relacional a informação é representada
através de relações (ou tabelas). As relações
correspondem a conjuntos, ou seja, são
manipuladas através dos habituais operadores que
operam sobre conjuntos Intersecção, Produto
Cartesiano, União, etc..
4
Relação
Modelo Relacional
Uma Base de Dados relacional é um conjunto de
relações com um número específico de atributos
(colunas) e um número variável de tuplos (linhas
ou instâncias). A cada atributo é atribuído um
domínio (conjunto de valores válidos) e um nome
único na relação
Relação Cliente
Um valor é armazenado na intersecção entre uma
linha e um atributo e diz respeito ao domínio do
atributo ou tem o valor NULL (ausência de valor).
Número Nome Morada
001 João NULL
013 Ana NULL
056 Luís NULL
INT (inteiros) STR (caracteres)
Domínios
5
Produto Cartesiano
Modelo Relacional
O Produto Cartesiano é obtido através de todas as
combinações entre os elementos dos conjuntos.
Exemplo
Domínio D10,1 Domínio D2 A,B,C
Representação Relacional
DI D2
0 a
0 b
0 c
1 a
1 b
1 c
Produto Cartesiano (D1 X D2) (0,A), (0,B),
(0,C), (1,A), (1,B), (1,C)
6
Definição de Relação
Modelo Relacional
Uma relação é o subconjunto do Produto
Cartesiano de uma lista de domínios. A tabela de
clientes é um subconjunto do produto cartesiano
entre os domínios INT e STR, nomeadamente INT X
STR X STR.
Qualquer subconjunto de INT X STR X STR é uma
tabela (inclusive INT X STR X STR ou INT X STR).
Número Nome Morada
001 João Lisboa
013 Ana NULL
Um conjunto não é ordenado. Isto é, caso
seleccione elementos de um conjunto (e.g., linhas
de uma tabela) sem indicar uma forma de
ordenação, os elementos são seleccionados através
de uma ordem aleatória.
7
Chave Primária (I)
Modelo Relacional
Todas as tabelas têm de possuir uma chave
primária. Chave Primária (ou chave) conjunto
minimal de atributos que permitem identificar
univocamente uma tuplo de uma relação.
Número Nome Morada
001 João NULL
013 Ana NULL
O conjunto Número é chave porque não podem
existir dois clientes com o mesmo número.
O conjunto Nome não é chave porque podem
existir dois clientes com o mesmo nome. O
conjunto Número, Nome não é chave porque não é
minimal (contém uma chave), e designa-se por
Super-Chave.
8
Chave Primária (II)
Modelo Relacional
Sala de Cinema
Apenas o conjunto Fila, Lugar garante que
identificamos apenas uma linha.
Fila Lugar Ocupado?
A 1 sim
A 2 não
B 1 não
Cliente
Número Nome Morada BI
001 João NULL 1234567
013 Ana NULL 7654321
É obrigatório optar por uma única chave !
Chaves Candidatas (ou Alternativas)
9
Critérios para adopção de uma Chave Primária (I)
Modelo Relacional

• Atributos familiares ao utilizador
• Domínio Numérico (por razões de eficiência)
• Apenas um atributo (por razões de eficiência)
• Preenchimento Obrigatório

10
Critérios para adopção de uma Chave Primária (II)
Modelo Relacional
Livro
Título Editora Edição ID
Database Systems Addison Wesley 5 OO1
Database Systems Addison Wesley 6 002
UML, User Guide Addison Wesley NULL 003
Alternativa a Título, Editora, Edição
Apesar de familiar, é pouco eficiente e obriga ao
preenchimento de Edição
11
Chave Estrangeira (I)
Modelo Relacional
As chaves estrangeiras ocorrem quando existem
dependências entre domínios.
Factura
Cliente
Número Data Cliente
001 12-12-1999 001
002 01-03-2000 013
0003 02-03-2000 001
Número Nome Morada
001 João NULL
013 Ana NULL
056 Luís NULL
O domínio de Factura.Cliente não é INT, mas sim
o conjunto de valores da coluna Cliente.Número.
Ou seja, uma factura não pode estar associada a
um cliente (Número) que não conste na tabela
Cliente.
12
Chave Estrangeira (II)
Modelo Relacional
Factura.Cliente é Chave Estrangeira na tabela
Factura.
Factura
Cliente
Número Data Cliente
001 12-12-1999 001
002 01-03-2000 013
0003 02-03-2000 001
Número Nome Morada
001 João NULL
013 Ana NULL
056 Luís NULL
Dependência
0...
1
Cliente.Número não é Chave Estrangeira porque
podem existir clientes sem facturas. A existência
de um cliente não é condicionada à existência de
facturas.
13
Chave Estrangeira (III)
Modelo Relacional
Localidade
Cliente
Cliente.CodPostal é Chave Estrangeira porque aos
clientes não podem ser atribuídos códigos postais
que não constem na tabela de localidades.
CodPostal Localidade
1500 Lisboa
2100 Porto
3999 Évora
Número Nome CodPostal
001 João 1500
013 Ana 2100
056 Luís NULL
0 ... 1
0...
Mas não é obrigatório atribuir um Código Postal a
um cliente.
Cliente.CodPostal ? Localidade.CodPostal ? NULL
14
Integridade das Chaves Estrangeiras(Operação
Delete)
Modelo Relacional
Localidade
Cliente
CodPostal Localidade
1500 Lisboa
2100 Porto
3999 Évora
Número Nome CodPostal
001 João 1500
013 Ana 2100
056 Luís NULL
Hipótese um utilizador pretende apagar a linha
cujo CodPostal é 2100
Dado que Cliente.CodPostal ? Localidade.CodPostal
? NULL, três alternativas se colocam ao gestor
da base de dados

1. Não permite apagar (Restricted)
2. Permite apagar, mas apaga o cliente 013
   (Cascade)
3. Permite apagar, mas substitui o CodPostal do
   cliente 013 por NULL. (Set Null)

15
Integridade das Chaves Estrangeiras(Operação
Update)
Modelo Relacional
Localidade
Cliente
CodPostal Localidade
1500 Lisboa
2100 Porto
3999 Évora
Número Nome CodPostal
001 João 1500
013 Ana 2100
056 Luís NULL
Hipótese um utilizador pretende alterar o
CodPostal 2100 para o valor 2200
Dado que Cliente.CodPostal ? Localidade.CodPostal
? NULL, três alternativas se colocam ao gestor
da base de dados

1. Não permite alterar (Restricted)
2. Permite alterar, mas altera igualmente o código
   postal do cliente 013 (de 2100 passa também para
   2200) (Cascade)
3. Permite alterar, mas substitui o CodPostal do
   cliente 013 por NULL. (Set Null)

16
Cruzamento de Informação
Modelo Relacional
No Modelo Relacional a informação é obtida
através do cruzamento entre tabelas (produtos
cartesianos) através das chaves estrangeiras.
Trata-se de uma forma fácil e intuitiva de obter
informação, mas pouco eficiente.
Exemplo Listar informação de clientes (incluindo
localidades)
Cliente
Número Nome CodPostal Localidade
001 João 1500 Lisboa
013 Ana 2100 Porto
056 Luís NULL NULL
Número Nome CodPostal
001 João 1500
013 Ana 2100
056 Luís NULL
X
Localidade
Para cada Cliente.CodPostal procura-se um
Localidade.CodPostal idêntico e selecciona-se a
localidade respectiva.
CodPostal Localidade
1500 Lisboa
2100 Porto
3999 Évora
17
Joins
Modelo Relacional
A informação obtida unicamente através do
produtos cartesiano entre tabelas é
inconsistente, daí a necessidade de efectuar
Joins.
Cliente
Número Nome Cliente. CodPostal Localidade.CodPostal Localidade
001 João 1500 1500 Lisboa
001 João 1500 2100 Porto
001 João 1500 3999 Évora
013 Ana 2100 1500 Lisboa
013 Ana 2100 2100 Porto
013 Ana 2100 3999 Évora
056 Luís NULL 1500 Lisboa
056 Luís NULL 2100 Porto
056 Luís NULL 3999 Évora
Número Nome CodPostal
001 João 1500
013 Ana 2100
056 Luís NULL
X
Localidade
CodPostal Localidade
1500 Lisboa
2100 Porto
3999 Évora
Únicas linhas coerentes Chave Primária Chave
Estrangeira (Key Join)
18
Transposição Modelo de Classes / Relacional
Modelo Relacional
A transposição do modelo de classes para o modelo
relacional tem como objectivo final a criação de
uma base de dados coerente com a modelação da
fase de análise.
As regras asseguram que
1) não ocorre perca de informação, i.e., é
possível aceder a toda a informação 2) não
existe informação redundante.
As regras apresentadas não devem ser
interpretadas como leis rígidas de
transposição, mas uma indicação susceptível de
adaptação em função da análise do problema em
questão. As regras usualmente geram modelos
relacionais ineficientes. Na transposição existe
perca de informação semântica relativa às
relações entre as classes a partir de um modelo
relacional pode não ser possível obter o Diagrama
de Classes a partir do qual ele foi gerado.
19
Regras de Transposição
Modelo Relacional
Regra 1 Todas as tabelas deverão ter uma chave
primária. No caso de não existirem na tabela
atributos que satisfaçam esta condição dever-se-á
criar um identificador único usualmente designado
por id.
Regra 2 As tabelas resultam exclusivamente das
classes do modelo, e das associações de muitos
para muitos.
Regra 3 Todos os atributos de uma classe (ou de
uma associação) são atributos da tabela que
implementa a classe (ou que implementa a
associação).
Docente
Nome Morada Telefone
Docente (Nome, Morada, Telefone, ID)
20
Regras de Transposição (um/um I)
Modelo Relacional
Regra 4 Transposição de Relações de Um para
Um Neste tipo de relação uma das tabelas da
relação deverá herdar a chave principal da outra
tabela como um atributo não chave (chave
estrangeira). A determinação da tabela que
herdará a chave estrangeira fica ao critério do
analista e da interpretação que faz da realidade,
devendo optar pelo que fizer mais sentido.
Factura (Data, Valor, NFact) Recibo (NCheque,
NRecibo, NFact)
Factura (Data, Valor, Nfact, NRecibo) Recibo
(NCheque, NRecibo)
Alternativa (desvantagem o registo de um novo
recibo obriga a uma alteração na tabela de
facturas)
21
Regras de Transposição (um/um II)
Modelo Relacional
Factura (Data, Valor, NFact) Recibo (NCheque,
NRecibo, NFact)
Factura
Recibo
NFact Data Valor
001 12-12-99 12000
013 02-01-00 13000
NRecibo NCheque NFact
05 Null 001
07 Null 003
Chave Estrangeira
22
Regras de Transposição (um/n I)
Modelo Relacional
Regra 5 Transposição de Relações de Um para
Muitos Numa relação de um para muitos a tabela
cujos registos são susceptíveis de serem
endereçados diversas vezes (lado muitos) herda a
chave da tabela cuja correspondência é unitária
(lado um).
Funcionário (NCont, Nome, Morada,
Designação) Departamento (Designação)
23
Regras de Transposição (um/n II)
Modelo Relacional
Funcionário (NCont, Nome, Morada,
Designação) Departamento (Designação)
Funcionário
Departamento
NCont Nome Morada Departamento
001 Ana NULL Produção
013 João NULL Produção
Designação
Produção
Comercial
Chave Estrangeira
24
Regras de Transposição (n/n I)
Modelo Relacional
Regra 6 Transposição de Relações de Muitos para
Muitos  A relação dá origem a uma tabela
representativa da associação onde a chave
primária é composta pelos atributos chave das
tabelas que implementam as classes associadas.
Aluno (NAluno, Nome, Morada) Disciplina
(Designação) Frequenta (NAluno, Designação)
25
Regras de Transposição (n/n II)
Modelo Relacional
Aluno (NAluno, Nome, Morada) Disciplina
(Designação) Frequenta (NAluno, Designação)
Aluno
Disciplina
Frequenta
NAluno Nome Morada
001 Ana NULL
013 João NULL
Designação
Marketing
Comunicação
NAluno Disciplina
001 Marketing
001 Comunicação
Chave Estrangeira
Chave Estrangeira
26
Regras de Transposição (Classes Associativas)
Modelo Relacional
Regra 7 Transposição de Classes Associativas
(desnecessária ...) Para as Classes Associativas
aplicam-se as regras correspondentes à
associação. Os atributos da classe associativa
são herdados pela(s) tabela(s) que herda(m) a(s)
chave(s) estrangeira(s).
Licenciatura
Licenciatura (Designação) Disciplina
(Designação) DisCLic (DesignaçãoLic,
DesignaçãoDisc, TipoAval)
Designação
0
1
Disciplinas da Licenciatura
Tipo Avaliação
Funcionário
Departamento
Num. Contribuinte Nome Morada
Designação
1
0
Departamento (Designação) Funcionário (Ncont,
Nome, Morada, Designação, DtAdmissão)
Disciplinas da Licenciatura
Data Admissão
27
Regras de Transposição (Generalizações I)
Modelo Relacional
Regra 8 Transposição de Generalizações Duas
situações distintas podem ocorrer  a) As classes
filhas têm entidade própria independentemente da
classe pai  A chave das tabelas que implementam
as classes filhas é obtida através dos atributos
da própria tabela. Terá que ser criado um
atributo chave para a tabela que implementa a
classe pai, sendo que essa tabela deverá ter uma
propriedade discriminante (um atributo) que
indica a qual das filhas o registo diz respeito.
Todos os atributos chave da tabela pai terão que
constar nas tabelas filhas como atributos não
chave.
Pessoa
Aluno
Pessoa (BI, Nome, Morada, Tipo) Aluno (Número,
Curso, BI) Docente (Número, Categoria, BI)
Nome Morada BI
Número Curso
Docente
Número Categoria
28
Regras de Transposição (Generalizações II)
Modelo Relacional
Pessoa
Aluno
Pessoa (BI, Nome, Morada, Tipo) Aluno (Número,
Curso, BI) Docente (Número, Categoria, BI)
Nome Morada BI
Número Curso
Docente
Número Categoria
Aluno
Pessoa
Docente
Número Curso BI
001 História 123456
BI Nome Morada Tipo
123456 João NULL A
321456 Ana NULL D
Número Categoria BI
10 Assistente 321456
Chave Estrangeira
29
Regras de Transposição (Generalizações III)
Modelo Relacional
 b) As classes filhas só têm identidade enquanto
associadas à classe pai Neste caso, a chave da
tabela que implementa a classe pai é obtida
através dos atributos da própria tabela. As
tabelas correspondentes às classes filhas
herdarão a mesma chave da tabela pai.
Sócio (NSócio, Nome, Morada, Telefone,
tipoSócio) Individual (NSócio, Idade,
Profissão) Organização (NSócio, CAE)
30
Regras de Transposição (Generalizações IV)
Modelo Relacional
Sócio (NSócio, Nome, Morada, Telefone,
tipoSócio) Individual (NSócio, Idade,
Profissão) Organização (NSócio, CAE)
Individual
Sócio
Organização
NSócio Idade Profissão
11 32 Docente
NSócio Nome Morada Telefone
10 João NULL 21345676
11 Ana NULL 22456543
NSócio CAE
10 A.99.8872
Chave Estrangeira
31
Regras de Transposição (Agregação)
Modelo Relacional
A transposição para o relacional obedece as
regras de transposição das associações com a
mesma multiplicidade.
Empresa (IDEmp, Designação, Morada) Departamento
(IDDep, Designação, IDEmp)
Automovel (Matrícula, Marca, Modelo) Roda
(IDRoda, TipoPneu, TipoJante, Matrícula) Volante
(IDVol, Material, Matrícula)
32
Regras de Transposição (Composição I)
Modelo Relacional
Regra 9 Transposição de Composições. A tabela
que implementa a classe composição tem como
atributos chave a chave da tabela correspondente
à classe que representa a composição e um
atributo (ou mais) pertencente à classe
componente (caso não exista é necessário
criá-lo).
Factura (NFact, Data) Linha (NFact, NLinha,
Produto, Quantidade, PreçoUnit)
33
Regras de Transposição (Composição II)
Modelo Relacional
Factura (NFact, Data) Linha (NFact, NLinha,
Produto, Quantidade, PreçoUnit)
Factura
Linha
NFact Data
11 03-03-00
12 03-03-00
NFact Nlinha Produto Quantidade PreçoUnit
11 1 ProdA 3 2000
11 2 ProdB 4 4000
12 1 ProdB 3 2000
Chave Estrangeira
34
Especificação de Atributos
Modelo Relacional
Na especificação dos atributos, para além da sua
designação e tipo de dados, é possível indicar
outras propriedades

• Chave primária
• Chave Estrangeira
• Allow NULLS admite o valor null
• Unique não admite valores duplicados
• Validações (CHECK) regras simples com
  operadores lógicos (lt,gt,ltgt, or, and) e.g., IN
  (lista de valores)
• Valor por omissão
• Comentários.

35
Optimizações do Modelo Relacional
Modelo Relacional
As regras de transposição, apesar de assegurarem
um modelo completo (sem perca de informação) e
coerente, geram usualmente modelos ineficientes.
Sempre que possível (desde que não haja perca de
informação relevante) dever-se-à optimizar o
modelo relacional obtido, nomeadamente, no que
diz respeito a

1. Número de tabelas (um elevado número de tabelas
   joins pode comprometer a eficiência do modelo
2. Número de atributos que compõem a chave das
   tabelas (deve ser reduzido).

Ao contrário de um diagrama de classes, o modelo
relacional não pretende ser descritivo, mas sim
eficaz e eficiente.
36
Exemplos de Optimizações (I)
Modelo Relacional
Utilidade das tabelas Ano, Mês e Dia ?
37
Exemplos de Optimizações (II)
Modelo Relacional
Docente
IDDocente Nome
0
0
0
0
Disciplina do Curso
0

Ano Licenciatura (Ano) Licenciatura (Sigla,
Designação) Disciplina (Sigla,
Designação) Disciplina do Curso (Sigla
Disciplina, Sigla Curso, Ano) Docente
(IDDocente, Nome) Lecciona (IDDocente, Sigla
Disciplina, Sigla Curso, Ano)
Chave ineficiente
A validação da chave original terá que ser feita
por programação
38
Exemplos de Optimizações (III)
Modelo Relacional
Pessoa
Aluno
Pessoa (BI, Nome, Morada, Tipo) Aluno (Número,
Curso, BI) Docente (Número, Categoria, BI)
Nome Morada BI
Número Curso
Docente
Número Categoria
39
Exemplos de Optimizações (IV)
Modelo Relacional
Linha da factura
Factura (Número, Data) Linha (Número, Item,
Produto, Quantidade, PU)
1
Produto Quantidade Preço Unitário
1
Pode obrigar a re-cálculos de subtotais e totais
(e.g., para estatísticas)
40
Índices (I)
Modelo Relacional
Uma técnica habitual de optimização de
interrogações (querys) a bases de dados consiste
na utilização de índices. O objectivo é acelerar
o acesso a uma tabela através de um (ou vários)
campo(s). Hipótese é frequente as publicações
serem consultadas pelo assunto
Ficheiro de Índice
Tabela de Publicação
Assunto Índice
Direito
História
Informática
Informática
Sociologia
ISBM Título Data Assunto
1 A 1998 História
2 D 1997 Informática
3 C 1994 Sociologia
4 Z 2000 Informática
5 F 1986 Direito
Ordenado por assunto
41
Índices (II)
Modelo Relacional
Ficheiro de Índice
Tabela de Publicação
Assunto Índice
Direito
História
Informática
Informática
Sociologia
ISBM Título Data Assunto
1 A 1998 História
2 D 1997 Informática
3 C 1994 Sociologia
4 Z 2000 Informática
5 F 1986 Direito
Exemplos de interrogações que beneficiam do índice

1. Quais os títulos das publicações de História ?
   (mesmo que a maioria das publicações sejam de
   história, é mais rápido percorrer sequencialmente
   um ficheiro mais pequeno)
2. Quantas publicações de informática existem
   (apenas necessita de abrir o ficheiro de
   índices)
3. (campo data indexado) Quais os títulos entre 1990
   e 1998 ? (a ordenação do índice acelera muito a
   procura por intervalos).

42
Índices (III)
Modelo Relacional
É usual criar-se um índice para a chave primária
dado que a forma privilegiada de acesso às
tabelas é através da chave, e.g., joins). Pela
mesma razão também se opta por vezes por criar
índices para as chaves estrangeiras.
Pode ser criado um índice para dois ou mais
atributos.
Ficheiro de Índice
Tabela de Publicação
Assunto/Data Índice
Direito1986
Informática1997
ISBM Título Data Assunto
1 A 1998 História
2 D 1997 Informática
3 C 1994 Sociologia
4 Z 2000 Informática
5 F 1986 Direito
43
Índices (IV)
Modelo Relacional
Apesar de acelerarem a consulta de informação, os
índices penalizam a introdução e alteração de
informação.
A inserção de um registo obriga à introdução de
um registo (ordenado) na tabela de índices. A
alteração de um valor num atributo indexado
obriga ao reordenamento do ficheiro de índices.
A gestão de índices é fundamental mas perigosa
(uma má gestão excesso pode degradar muito o
desempenho da base de dados) e nunca é
definitiva. Depende do número de registos
existentes e no tipo de acessos (consultas) mais
frequentes.
44
Índices (V)
Modelo Relacional
Exemplos de acessos
Tabela Publicacao (ISBN (Int), Assunto (Str),
Ano (Int), Titulo (Str)) 100.000 registos
Inserção ISBN sequencial, restantes 3
aleatórios Consulta Número de publicações com um
determinado assunto Valores em segundos
Índice Inserção Consulta
Nenhum 398 2
ISBN 402 2
ISBN, Assunto 547 (37) 0
45
Arquivo
Modelo Relacional
O arquivo (histórico / backup) de informação por
vezes origina problemas de consistência.
Linha da factura
Produto
1
1
IDProduto Quantidade
1
IDProduto Designação Preço Unitário
0
Hipótese o preço de um produto foi alterado e é
necessário imprimir segunda via de uma factura
antiga. Três alternativas de backup

1. Cópia integral da base de dados é sempre
   coerente
2. Cópia de algumas tabelas pode gerar
   incoerência.
3. Tabelas próprias para backup (alternativa a b))

Linha (Num_Fact, Linha, IDProduto, Designação,
PU, Quantidade)
46
Parameterização
Modelo Relacional
Todas as constantes de uma aplicação devem estar
em uma(s) tabela, e nunca no código. Normalmente
essa tabela apenas contém uma linha e uma coluna
para cada parâmetro da aplicação. Exemplos de
atributos Taxa IVA Designação e Morada da
Empresa (para impressões) Dia do mês em que
são automaticamente processados os salários
Prazo de devolução de uma publicação
(biblioteca) etc.
47
Transacções (I)
Modelo Relacional
Exemplo Transferências entre contas bancárias
Necessidade de executar as duas operações como um
todo. Transacção conjunto delimitado e
pré-definido de operações que exibe as seguintes
características

• Atomicidade - grupo indivisível (todas ou
  nenhuma)
• Integridade - passar de um estado de integridade
  da BD para outro estado de integridade
• Isolamento - uma transacção deve ser executada
  como se fosse única. Ou seja, num ambiente
  concorrente não pode haver interferências entre
  as transacções, o resultado final é equivalente a
  uma execução em série (não concorrente).
• Persistência após uma transacção terminar com
  sucesso (commit), as suas actualizações sobre a
  BD passam a ser efectivas.

48
Transacções (II)
Modelo Relacional
Flat Transactions
Start Transaction . Operações de escrita na
BD COMMIT, ROLLBACK End Transaction   COMMIT
actualização permanente na BD das alterações
efectuadas desde o ultimo commit ou início de
transacção. ROLLBACK desfaz todas as alterações
desde o último commit ou início de transacção. O
End Transaction faz automaticamente o COMMIT.
Caso a transacção termine abruptamente antes do
End Transaction é feito automaticamente o
ROLLBACK.   Nem sempre é adequado. Por exemplo,
situações do tipo Update a milhares de registos
(caso a transacção falhe a meio, o ROLLBACK
desfaz tudo desde o início).
49
Transacções (III)
Modelo Relacional
Chained Transactions
Start Transaction . commit point (ou check
point) .... commit point End
Transaction   Caso haja uma falha a meio, apenas
é feito o ROLLBACK até ao Commit Point anterior.
Enquanto não for executado o End Transaction,
nenhuma alteração é efectiva. Em relação às Flat
Transactions, o ROLLBACK desfaz menos, mas a
transacção exige mais recursos (memória e
processamento). Quem decide os commit point é o
programador (manual) ou o SGBD (automático).
50
Concorrência (I)
Modelo Relacional
O problema da concorrência coloca-se em ambientes
multi utilizador várias transacções a acederem
em simultâneo aos mesmos dados (por oposição a
acederem em série).
Exemplos de execuções
Lost update perdeu-se uma actualização
Transacção T1 Transacção T2
Ler saldo Ler saldo
Saldo Saldo - 100 Saldo Saldo - 400
Escrever Saldo Escrever Saldo
 Execução em série
 Execução concorrente
Tempo Operação Saldo
1 T1 Ler saldo 1000
2 T1 Escrever Saldo 900
3 T2 Ler Saldo 900
4 T2 Escrever Saldo 500
Tempo Operação Saldo
1 T1 Ler saldo 1000
2 T2 Ler Saldo 1000
3 T2 Escrever Saldo 600
4 T1 Escrever Saldo 900
Estado da BD coerente
51
Concorrência (II)
Modelo Relacional
Exemplo de uma situação de dirty read (ler valor
inexistente)
Transacção T1 Transacção T2
Ler movimento Ler crédito em TAB1
Escrever crédito em TAB1 Escrever crédito em TAB2
Escrever débito
Saldo débito - crédito
Escrever Saldo
O Valor de Crédito em Tab1 e Tab2 tem que ser
idêntico no fim de T2
Tempo Operação TAB 1 TAB2
1 T1 Ler movimento 0 0
2 T1 Escrever crédito TAB1 1000 0
3 T2 Ler crédito 1000 0
4 T1 escrever débito 1000() 0
5 T2 escrever crédito TAB 2 1000 1000
6 T1 Escrever Saldo 1000 1000
() Hipótese erro na transacção T1, é feito o
Rollback de T1(Tab1.Credito 0). O Crédito fica
diferente nas duas tabelas no fim de T2.
52
Concorrência (III)
Modelo Relacional
Escalonamentos Serializados As restrições de
integridade apenas garantem que cada transacção
isoladamente termina de forma a deixar a base de
dados coerente, nada garantem em relação às
interferências entre as transacções.
Dado que os escalonamentos em série não tiram
partido das potencialidades multi utilizador, a
solução é encontrar um escalonamento serializado,
isto é, um escalonamento concorrente que, após o
seu término, a base de dados fique num estado
idêntico ao que teria ficado caso o escalonamento
fosse em série. Em vez de tentar-mos identificar
as sequências de operações que asseguram um
escalonamento serializado (não é fácil), opta-se
por adoptar um método de controlo de concorrência
que automaticamente assegure escalonamentos
serializados. Três Métodos possíveis
Mecanismos de locking (preventivo) Mecanismos de
etiquetagem (preventivo) Optimistas.
53
Concorrência (IV)
Modelo Relacional
Optimistas parte do pressuposto que as
interferências são raras. Deixa ocorrer as
transacções até ao fim, e depois verifica se o
commit não traz problemas de serialização
(utiliza conjuntos write set e read set com todas
as actualizações efectuadas), caso existam
problemas, faz o rollback de tudo. Mecanismos de
Etiquetagem utilizam-se etiquetas que indicam a
ordem de chegada das transacções. Os dados
acedidos (para leitura ou escrita) ficam com ID
da etiqueta que lhe acede. Existe um conflito
quando uma transacção tenta aceder a um elemento
de dados cujo valor de etiqueta é superior ao
seu. Nesse caso é necessário desfazer e reiniciar
a transacção. Existem abordagens mais elaboradas
com etiquetas de leitura e escrita. Mecanismos
de Locking os mais utilizados.
54
Concorrência (V)
Modelo Relacional
Mecanismos de Locking
Um lock é uma variável associada a um elemento da
base de dados que, de acordo com o seu valor em
cada momento, vai permitir ou impedir ser
acedido. Antes de aceder a um elemento da base de
dados, tanto para leitura como para actualização,
é necessário obter o lock desse elemento.    Um
elemento da base de dados pode ter um de três
estados  lock para leitura lock para
escrita unlocked.   A cada lock de leitura é
necessário associar um valor que traduza o número
de transacções que, em cada momento, mantêm esse
tipo de lock. O valor vai sendo decrementado à
medida que as transacções vão libertando o
elemento de dados.
55
Concorrência (VI)
Modelo Relacional
Two Phase Loccking (2PL)
Método de controlo de concorrência que utiliza
mecanismos de locking que garantem a serialização
das transacções. Uma transacção satisfaz o 2PL
se todos os seus locks antecederem os seus
unlocks. Exemplo Duas transacções T1 credita
uma conta com valores em numerário (aumenta o
saldo disponível e contabilístico) T2 credita
uma conta com valores em cheque (apenas aumenta o
saldo contabilístico). Ambas as transacções
satisfazem o 2PL.
56
Concorrência (VII)
Modelo Relacional
T1 Begin transaction Rlock(saldo_disp)
Ler saldo_disp saldo_disp saldo_disp
credito Wlock(saldo_disp) Escrever
saldo_disp Rlock(saldo_cont) Ler
saldo_cont saldo_cont saldo_cont credito
Wlock (saldo_cont) Escrever saldo_cont
Unlock(saldo_disp) Unlock (saldo_cont) End
Transaction  
T2 Begin Transaction Rlock(saldo_cont)
Ler saldo_cont saldo_cont saldo_cont
crédito Wlock (saldo_cont) Escrever
saldo_cont Unlock (saldo_cont) End Transaction
Só liberta no fim
57
Concorrência (VIII)
Modelo Relacional
O seguinte escalonamento (não serializado) não
poderia acontecer
Tempo T1 T2
1 Ler saldo_disp Calcular saldo_disp
2 Ler saldo_cont Calcular saldo_cont
3 Escrever saldo_disp
4 Ler saldo_cont Calcular saldo_cont
5 Escrever saldo_cont
6 Escrever saldo_cont
O Saldo Cont tem associado um lock de leitura,
logo não pode ser facultado a T2 um lock de
escrita.
No entanto o 2PL não impede os dead locks.
58
Concorrência (IX)
Modelo Relacional
Tempo T1 T2
1 Rlock (saldo_disp)
2 Ler saldo_disp
3 Rlock(saldo_cont)
4 Ler saldo_cont
5 Wlock(saldo_disp)
6 Escrever saldo_disp
7 Rlock(saldo_cont)
8 Ler saldo_cont
9 Wlock(saldo_cont)
10 Wlock(saldo_cont)
11 Unlock(saldo_cont)
12 Wlock(saldo_cont)
13 Escrever saldo_cont
14 Unlock(saldo_disp)
15 Unlock(saldo_cont)
16 Rlock(saldo_cont)
17 ....
Dead lock em 2PL
Situação de dead lock, T2 e T1 bloquedas. T2 tem
que libertar ....
T2 pode prosseguir
59
Concorrência (X)
Modelo Relacional
Tempo T1 T2
1 Rlock (saldo_disp)
2 Ler saldo_disp
3 Rlock(saldo_cont)
4 Ler saldo_cont
5 Wlock(saldo_disp)
6 Escrever saldo_disp
7 Wlock(saldo_cont) ()
8 Wlock(saldo_cont)
9 Escrever saldo_cont
10 Unlock saldo_cont
11 Wlock(saldo_cont)
12 ler saldo_cont
13 Escreve saldo_cont
14 Unlock(saldo_disp)
15 Unlock(saldo_cont)
Evitar o Dead lock em vez de deixar acontecer o
deadlock, T1, antes de se iniciar, ficava na
posse de todos os locks que necessita.
T1 fica bloqueada
T1 pode continuar
() aguarda o unlock de saldo_cont
60
Concorrência (XI)
Modelo Relacional
Os SGDBs normalmente implementam automaticamente
o 2PL ao nível do registo (record lock). Essa
opção (configurável) no entanto degrada a
eficiência das transacções. A atribuição de um
Read ou Write Lock é feita automaticamente pelo
SGBD em função do tipo de operação que o
programador (utilizador) manda executar (as
operações de leitura originam apenas um read
lock). Ao utilizador cabe

• Decidir o início e fim da transacção
• Configurar o nível de segurança do SGBD ou
  transacção (optar por 2PL ou níveis mais
  tolerantes / optimistas)
• Ordenar a sequência de operações da melhor forma.

Mais adiante estas opções são exemplificadas
recorrendo a exemplos em JAVA e Stored Procedures.