Índice pedro ramos, dcti/iscte modelo relacional pedro nogueira ramos ([email protected]) dcti /...

60
Pedro Ramos, DCTI/ISCTE Índic e Modelo Relacional Pedro Nogueira Ramos ([email protected]) DCTI / ISCTE

Upload: internet

Post on 18-Apr-2015

121 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Modelo Relacional

Pedro Nogueira Ramos

([email protected])

DCTI / ISCTE

Page 2: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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

Arquivo

Parameterização

Transacções

Concorrência

Page 3: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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..

Page 4: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Relação

Número Nome Morada

001 João NULL

013 Ana NULL

056 Luís NULL

Relação: ClienteUm 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).

INT (inteiros)

STR (caracteres)Domínios

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

Modelo Relacional

Page 5: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Produto Cartesiano

O Produto Cartesiano é obtido através de todas as combinações entre os elementos dos conjuntos.

Produto Cartesiano (D1 X D2) =

{(0,A), (0,B), (0,C), (1,A), (1,B), (1,C)}

Modelo Relacional

01

a

bc

0 a

0 b

0 c

1 a

1 b

1 c

Domínio D1={0,1} Domínio D2 ={A,B,C}

Exemplo

Representação Relacional

DI D2

Page 6: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Definição de Relação

Número Nome Morada

001 João Lisboa

013 Ana NULL

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).

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.

Modelo Relacional

Page 7: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Chave Primária (I)

Número Nome Morada

001 João NULL

013 Ana NULL

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.

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.

Modelo Relacional

O conjunto {Número} é chave porque não podem existir dois clientes com o mesmo número.

Page 8: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Chave Primária (II)

Fila Lugar Ocupado?

A 1 sim

A 2 não

B 1 não

Modelo Relacional

Apenas o conjunto {Fila, Lugar} garante que identificamos apenas uma linha.

Sala de Cinema

Chaves Candidatas (ou Alternativas)

Cliente

Número Nome Morada BI

001 João NULL 1234567

013 Ana NULL 7654321

É obrigatório optar por uma única chave !

Page 9: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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

Page 10: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Critérios para adopção de uma Chave Primária (II)

Modelo Relacional

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

Livro

Alternativa a {Título, Editora, Edição}

Apesar de familiar, é pouco eficiente e obriga ao preenchimento de Edição

Page 11: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Chave Estrangeira (I)

As chaves estrangeiras ocorrem quando existem dependências entre domínios.

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.

Modelo Relacional

Número Data Cliente

001 12-12-1999 001

002 01-03-2000 013

0003 02-03-2000 001

Factura

Número Nome Morada

001 João NULL

013 Ana NULL

056 Luís NULL

Cliente

Page 12: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Chave Estrangeira (II)

Factura.Cliente é Chave Estrangeira na tabela Factura.

Modelo Relacional

Número Data Cliente

001 12-12-1999 001

002 01-03-2000 013

0003 02-03-2000 001

Factura

Número Nome Morada

001 João NULL

013 Ana NULL

056 Luís NULL

Cliente

1 0...*

Dependência

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.

Page 13: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Chave Estrangeira (III)

Modelo Relacional

CodPostal Localidade

1500 Lisboa

2100 Porto

3999 Évora

Localidade

Número Nome CodPostal

001 João 1500

013 Ana 2100

056 Luís NULL

Cliente

0 ... 10...*

Cliente.CodPostal é Chave Estrangeira porque aos clientes não podem ser atribuídos códigos postais que não constem na tabela de localidades.

Cliente.CodPostal {Localidade.CodPostal} NULL

Mas não é obrigatório atribuir um Código Postal a um cliente.

Page 14: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Integridade das Chaves Estrangeiras(Operação Delete)

Modelo Relacional

CodPostal Localidade

1500 Lisboa

2100 Porto

3999 Évora

Localidade

Número Nome CodPostal

001 João 1500

013 Ana 2100

056 Luís NULL

Cliente

Dado que Cliente.CodPostal {Localidade.CodPostal} NULL,

três alternativas se colocam ao gestor da base de dados:

Hipótese: um utilizador pretende apagar a linha cujo CodPostal é 2100

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)

Page 15: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Integridade das Chaves Estrangeiras(Operação Update)

Modelo Relacional

CodPostal Localidade

1500 Lisboa

2100 Porto

3999 Évora

Localidade

Número Nome CodPostal

001 João 1500

013 Ana 2100

056 Luís NULL

Cliente

Dado que Cliente.CodPostal {Localidade.CodPostal} NULL,

três alternativas se colocam ao gestor da base de dados:

Hipótese: um utilizador pretende alterar o CodPostal 2100 para o valor 2200

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)

Page 16: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Cruzamento de Informação

Modelo Relacional

CodPostal Localidade

1500 Lisboa

2100 Porto

3999 Évora

Localidade

Número Nome CodPostal

001 João 1500

013 Ana 2100

056 Luís NULL

Cliente

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)

Número Nome CodPostal Localidade

001 João 1500 Lisboa

013 Ana 2100 Porto

056 Luís NULL NULLX

Para cada Cliente.CodPostal procura-se um Localidade.CodPostal idêntico e selecciona-se a localidade respectiva.

Page 17: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Joins

Modelo Relacional

CodPostal Localidade

1500 Lisboa

2100 Porto

3999 Évora

Localidade

Número Nome CodPostal

001 João 1500

013 Ana 2100

056 Luís NULL

Cliente

A informação obtida unicamente através do produtos cartesiano entre tabelas é inconsistente, daí a necessidade de efectuar Joins.

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

X =

Únicas linhas coerentes: Chave Primária = Chave Estrangeira(Key Join)

Page 18: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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

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.

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.

Page 19: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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

NomeMoradaTelefone

Docente (Nome, Morada, Telefone, ID)

Page 20: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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 EmissãoValorNúmero de Factura

Recibo

Nº ChequeNº Recibo

0 … 11

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)

Page 21: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (“um/um” II)

Modelo Relacional

Factura

Data EmissãoValorNúmero de Factura

Recibo

Nº ChequeNº Recibo

0 … 11

Factura (Data, Valor, NFact)

Recibo (NCheque, NRecibo, NFact)

Chave Estrangeira

NFact Data Valor

001 12-12-99 12000

013 02-01-00 13000

NRecibo NCheque NFact

05 Null 001

07 Null 003

Factura Recibo

Page 22: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

Funcionário

Num. ContribuinteNomeMorada

Departamento

Designação10 … *

Page 23: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (“um/n” II)

Modelo Relacional

Chave Estrangeira

NCont Nome Morada Departamento

001 Ana NULL Produção

013 João NULL Produção

Designação

Produção

Comercial

Funcionário Departamento

Funcionário

Num. ContribuinteNomeMorada

Departamento

Designação10 … *Funcionário (NCont, Nome, Morada, Designação)

Departamento (Designação)

Page 24: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

Aluno

NúmeroNomeMorada

Disciplina

Designação0 ... *0 … *

frequenta

Page 25: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (“n/n” II)

Modelo Relacional

Chave Estrangeira

NAluno Nome Morada

001 Ana NULL

013 João NULL

Designação

Marketing

Comunicação

Aluno Disciplina

Aluno

NúmeroNomeMorada

Disciplina

Designação0 ... *0 … *

frequenta

Aluno (NAluno, Nome, Morada)

Disciplina (Designação)

Frequenta (NAluno, Designação)

NAluno Disciplina

001 Marketing

001 Comunicação

Frequenta

Chave Estrangeira

Page 26: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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 (Designação)

Disciplina (Designação)

DisCLic (DesignaçãoLic, DesignaçãoDisc, TipoAval)

Licenciatura

Designação

Disciplina

Designação1 … *0 … *

Disciplinas da Licenciatura

Tipo Avaliação

Funcionário

Num. ContribuinteNomeMorada

Departamento

Designação10 … *

Disciplinas da Licenciatura

Data Admissão

Departamento (Designação)

Funcionário (Ncont, Nome, Morada, Designação, DtAdmissão)

Page 27: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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

NomeMoradaBI

Aluno

NúmeroCurso

Docente

NúmeroCategoria

Pessoa (BI, Nome, Morada, Tipo)

Aluno (Número, Curso, BI)

Docente (Número, Categoria, BI)

Page 28: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (Generalizações II)

Modelo Relacional

Chave Estrangeira

Número Curso BI

001 História 123456

BI Nome Morada Tipo

123456 João NULL A

321456 Ana NULL D

Aluno Pessoa

Número Categoria BI

10 Assistente 321456

Docente

Pessoa

NomeMoradaBI

Aluno

NúmeroCurso

Docente

NúmeroCategoria

Pessoa (BI, Nome, Morada, Tipo)

Aluno (Número, Curso, BI)

Docente (Número, Categoria, BI)

Page 29: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

Sócio

NomeMoradaTelefoneNúmero Sócio

Individual

IdadeProfissão

Organização

CAE

Page 30: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (Generalizações IV)

Modelo Relacional

Chave Estrangeira

NSócio Idade Profissão

11 32 Docente

NSócio Nome Morada Telefone

10 João NULL 21345676

11 Ana NULL 22456543

Individual Sócio

NSócio CAE

10 A.99.8872

Organização

Sócio

NomeMoradaTelefoneNúmero Sócio

Individual

IdadeProfissão

Organização

CAE

Sócio (NSócio, Nome, Morada, Telefone, tipoSócio)

Individual (NSócio, Idade, Profissão)

Organização (NSócio, CAE)

Page 31: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

Empresa

DesignaçãoMorada

Departamento

Designação1

0 … *

Automóvel

MatrículaMarcaModelo

Roda

Tipo PneuTipo Jante

1 4

Volante

Material1

Automovel (Matrícula, Marca, Modelo)

Roda (IDRoda, TipoPneu, TipoJante, Matrícula)

Volante (IDVol, Material, Matrícula)

Page 32: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

Factura

NúmeroData

Linha da factura

ProdutoQuantidadePreço Unitário

1 … *1

Page 33: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Regras de Transposição (Composição II)

Modelo Relacional

Factura (NFact, Data)

Linha (NFact, NLinha, Produto, Quantidade, PreçoUnit)

Factura

NúmeroData

Linha da factura

ProdutoQuantidadePreço Unitário

1 … *1

Chave Estrangeira

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

Factura Linha

Page 34: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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 (<,>,<>, or, and) e.g., IN (lista de valores);

• Valor por omissão;

• Comentários.

Page 35: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Optimizações do 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:

Modelo Relacional

a) Número de tabelas (um elevado número de tabelas – joins – pode comprometer a eficiência do modelo;

b) 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.

Page 36: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Exemplos de Optimizações (I)

Modelo Relacional

Ano

Ano 1 … 12

1 Dia

Dia

Mes

Mes 1 …30

1

Dias Serviço

Hora InícioHora Fim

Farmácia

NomeMorada

0 …* 0 …*

Ano (Ano)

Mes (Ano, Mes)

Dia (Ano, Mes, Dia)

Farmácia (IDFarmacia, Nome, Morada)

Dias-Servico (IDFarmacia, Ano, Mes, Dia, Hora_Inicio, Hora_Fim)

As três classes para modelar a data podem-se justificar para realçar o facto de não haver periodicidade (semanal, mensal) nos dias de serviço.

Utilidade das tabelas Ano, Mês e Dia ?

Dias Serviço

DataHora InícioHora Fim

Farmácia

NomeMorada

0 …*

1Farmácia (IDFarmacia, Nome, Morada)

Dias-Servico (IDFarmacia, Data, Hora_Inicio, Hora_Fim)

Apenas um atributo

Page 37: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Exemplos de Optimizações (II)

Modelo Relacional

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)

Ano Licenciatura

Ano

Disciplina do Curso

0 … *

Licenciatura

SiglaDesignação

Disciplina

SiglaDesignação

0 … * 0 … *

Docente

IDDocenteNome

0 … *

0 … *

Chave ineficiente

Ano Licenciatura (Ano) Licenciatura (Sigla, Designação) Disciplina (Sigla, Designação)

Disciplina do Curso (Sigla Disciplina, Sigla Curso, Ano, IDDis) Docente (IDDocente, Nome)

Lecciona (IDDocente, IDDis)A validação da chave original terá que ser feita por programação

Page 38: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Exemplos de Optimizações (III)

Modelo Relacional

Pessoa

NomeMoradaBI

Aluno

NúmeroCurso

Docente

NúmeroCategoria

Pessoa (BI, Nome, Morada, Tipo)

Aluno (Número, Curso, BI)

Docente (Número, Categoria, BI)

Aluno (Número, Curso, BI, Nome, Morada)

Docente (Número, Categoria, BI, Nome, Morada)

Facilita listagens de alunos (ou docentes) mas penaliza mailings.

Sócio

NomeMoradaTelefoneNúmero Sócio

Individual

IdadeProfissão

Organização

CAE

Sócio (NSócio, Nome, Morada, Telefone, tipoSócio)

Individual (NSócio, Idade, Profissão)

Organização (NSócio, CAE)

Sócio (NSócio, Nome, Morada, Telefone, Idade, Profissão, CAE, TipoSócio {Individual, CAE})

Page 39: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Exemplos de Optimizações (IV)

Modelo Relacional

Factura (Número, Data)

Linha (Número, Item, Produto, Quantidade, PU)

Pode obrigar a re-cálculos de subtotais e totais (e.g., para estatísticas)

Factura

NúmeroData

Linha da factura

ProdutoQuantidadePreço Unitário

1 … *1

Factura (Número, Data, Total)

Linha (Número, Item, Produto, Quantidade, PU, SubTotal)

Para além dos perigos da redundância, penaliza o cálculo de cada factura (update na tabela de factura).

Page 40: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Índices (I)

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

Modelo Relacional

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

Assunto Índice

Direito

História

Informática

Informática

Sociologia

Ficheiro de Índice Tabela de Publicação

Ordenado por assunto

Page 41: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Índices (II)

Modelo Relacional

Assunto Índice

Direito

História

Informática

Informática

Sociologia

Ficheiro de Índice Tabela de Publicação

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).

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

Page 42: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Í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.

Assunto/Data Índice

Direito+1986

Informática+1997

Ficheiro de Índice Tabela de Publicação

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

Pode ser criado um índice para dois ou mais atributos.

Page 43: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Í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 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.

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.

Page 44: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Índices (V)

Modelo Relacional

Exemplos de acessos

Tabela: Publicacao (ISBN (Int), Assunto (Str), Ano (Int), Titulo (Str)) 100.000 registos

Índice Inserção Consulta

Nenhum 398 2

ISBN 402 2

ISBN, Assunto 547 (+37%) 0

Inserção: ISBN sequencial, restantes 3 aleatóriosConsulta: Número de publicações com um determinado assuntoValores em segundos

Page 45: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Arquivo

O arquivo (histórico / backup) de informação por vezes origina problemas de consistência.

Modelo Relacional

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:

Factura

NúmeroData

Linha da factura

IDProdutoQuantidade

1 … *1Produto

IDProdutoDesignaçãoPreço Unitário

a) Cópia integral da base de dados – é sempre coerente;

b) Cópia de algumas tabelas – pode gerar incoerência.

c) Tabelas próprias para backup (alternativa a b))

Linha (Num_Fact, Linha, IDProduto, Designação, PU, Quantidade)

1

0 … *

Page 46: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Parameterização

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.

Modelo Relacional

Page 47: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Transacções (I)

Exemplo: Transferências entre contas bancárias

Modelo Relacional

CONTA A

CONTA B

Débito 100 Crédito 100

BD Inconsistente

Falha no sistema

• 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.

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:

Page 48: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Transacções (II)

Modelo Relacional

Flat TransactionsStart 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).

Page 49: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Transacções (III)

Modelo Relacional

Chained TransactionsStart 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).

Page 50: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Concorrência (I)

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).

Modelo Relacional

 Execução em série

Tempo Operação Saldo

1 T1 Ler saldo 1000

2 T1 Escrever Saldo 900

3 T2 Ler Saldo 900

4 T2 Escrever Saldo 500

Exemplos de execuções

Transacção T1 Transacção T2

Ler saldo Ler saldo

Saldo = Saldo - 100 Saldo = Saldo - 400

Escrever Saldo Escrever Saldo

Estado da BD coerente

Tempo Operação Saldo

1 T1 Ler saldo 1000

2 T2 Ler Saldo 1000

3 T2 Escrever Saldo 600

4 T1 Escrever Saldo 900

 Execução concorrente

Lost update – perdeu-se uma actualização

Page 51: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Concorrência (II)

Modelo Relacional

Exemplo de uma situação de dirty read (ler valor inexistente)

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

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

(*) 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.

Page 52: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Concorrência (III)

Modelo Relacional

Escalonamentos SerializadosAs 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.

Page 53: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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.

Page 54: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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.

Page 55: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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.

Page 56: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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 

T2Begin 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

Page 57: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Concorrência (VIII)

Modelo Relacional

O Saldo Cont tem associado um lock de leitura, logo não pode ser facultado a T2 um lock de escrita.

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 seguinte escalonamento (não serializado) não poderia acontecer:

No entanto o 2PL não impede os dead locks.

Page 58: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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 ....

Situação de dead lock, T2 e T1 bloquedas. T2 tem que libertar ....

T2 pode prosseguir

Dead lock em 2PL

Page 59: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

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)

T1 fica bloqueada

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 pode continuar

(*) aguarda o unlock de saldo_cont

Page 60: Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) DCTI / ISCTE

Pedro Ramos, DCTI/ISCTE Índice

Concorrência (XI)

Modelo Relacional

Os SGDB’s 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.