A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos DCTI / ISCTE.

Apresentações semelhantes


Apresentação em tema: "Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos DCTI / ISCTE."— Transcrição da apresentação:

1 Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos DCTI / ISCTE

2 Índice Pedro Ramos, DCTI/ISCTE 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

3 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE Relação NúmeroNomeMorada 001JoãoNULL 013AnaNULL 056LuísNULL 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). 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

5 Índice Pedro Ramos, DCTI/ISCTE 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 0 1 a b c 0a 0b 0c 1a 1b 1c Domínio D1={0,1} Domínio D2 ={A,B,C} Exemplo Representação Relacional DI D2

6 Índice Pedro Ramos, DCTI/ISCTE Definição de Relação NúmeroNomeMorada 001JoãoLisboa 013AnaNULL 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

7 Índice Pedro Ramos, DCTI/ISCTE Chave Primária (I) NúmeroNomeMorada 001JoãoNULL 013AnaNULL 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.

8 Índice Pedro Ramos, DCTI/ISCTE Chave Primária (II) FilaLugarOcupado? A1sim A2não B1 Modelo Relacional Apenas o conjunto {Fila, Lugar} garante que identificamos apenas uma linha. Sala de Cinema Chaves Candidatas (ou Alternativas) Cliente NúmeroNomeMoradaBI 001JoãoNULL AnaNULL É obrigatório optar por uma única chave !

9 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE Critérios para adopção de uma Chave Primária (II) Modelo Relacional TítuloEditoraEdiçãoID Database SystemsAddison Wesley5OO1 Database SystemsAddison Wesley6002 UML, User GuideAddison WesleyNULL003 Livro Alternativa a {Título, Editora, Edição} Apesar de familiar, é pouco eficiente e obriga ao preenchimento de Edição

11 Índice Pedro Ramos, DCTI/ISCTE 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úmeroDataCliente Factura NúmeroNomeMorada 001JoãoNULL 013AnaNULL 056LuísNULL Cliente

12 Índice Pedro Ramos, DCTI/ISCTE Chave Estrangeira (II) Factura.Cliente é Chave Estrangeira na tabela Factura. Modelo Relacional NúmeroDataCliente Factura NúmeroNomeMorada 001JoãoNULL 013AnaNULL 056LuísNULL Cliente * 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.

13 Índice Pedro Ramos, DCTI/ISCTE Chave Estrangeira (III) Modelo Relacional CodPostalLocalidade 1500Lisboa 2100Porto 3999Évora Localidade NúmeroNomeCodPostal 001João Ana LuísNULL 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. Cliente.CodPostal {Localidade.CodPostal} NULL Mas não é obrigatório atribuir um Código Postal a um cliente.

14 Índice Pedro Ramos, DCTI/ISCTE Integridade das Chaves Estrangeiras (Operação Delete) Modelo Relacional CodPostalLocalidade 1500Lisboa 2100Porto 3999Évora Localidade NúmeroNomeCodPostal 001João Ana LuísNULL 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 é 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 Índice Pedro Ramos, DCTI/ISCTE Integridade das Chaves Estrangeiras (Operação Update) Modelo Relacional CodPostalLocalidade 1500Lisboa 2100Porto 3999Évora Localidade NúmeroNomeCodPostal 001João Ana LuísNULL 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 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 Índice Pedro Ramos, DCTI/ISCTE Cruzamento de Informação Modelo Relacional CodPostalLocalidade 1500Lisboa 2100Porto 3999Évora Localidade NúmeroNomeCodPostal 001João Ana LuísNULL 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úmeroNomeCodPostalLocalidade 001João1500Lisboa 013Ana2100Porto 056LuísNULL X Para cada Cliente.CodPostal procura-se um Localidade.CodPostal idêntico e selecciona- se a localidade respectiva.

17 Índice Pedro Ramos, DCTI/ISCTE Joins Modelo Relacional CodPostalLocalidade 1500Lisboa 2100Porto 3999Évora Localidade NúmeroNomeCodPostal 001João Ana LuísNULL Cliente A informação obtida unicamente através do produtos cartesiano entre tabelas é inconsistente, daí a necessidade de efectuar Joins. NúmeroNomeCliente. CodPostal Localidade. CodPostal Localidade 001João1500 Lisboa 001João Porto 001João Évora 013Ana Lisboa 013Ana2100 Porto 013Ana Évora 056LuísNULL1500Lisboa 056LuísNULL2100Porto 056LuísNULL3999Évora X = Únicas linhas coerentes: Chave Primária = Chave Estrangeira (Key Join)

18 Índice Pedro Ramos, DCTI/ISCTE 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.

19 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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ão Valor Número de Factura Recibo Nº Cheque Nº 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)

21 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (um/um II) Modelo Relacional Factura Data Emissão Valor Número de Factura Recibo Nº Cheque Nº Recibo 0 … 11 Factura (Data, Valor, NFact) Recibo (NCheque, NRecibo, NFact) Chave Estrangeira NFactDataValor NReciboNChequeNFact 05Null001 07Null003 FacturaRecibo

22 Índice Pedro Ramos, DCTI/ISCTE 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. Contribuinte Nome Morada Departamento Designação 1 0 … *

23 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (um/n II) Modelo Relacional Chave Estrangeira NContNomeMoradaDepartamento 001AnaNULLProdução 013JoãoNULLProdução Designação Produção Comercial FuncionárioDepartamento Funcionário Num. Contribuinte Nome Morada Departamento Designação 1 0 … * Funcionário (NCont, Nome, Morada, Designação) Departamento (Designação)

24 Índice Pedro Ramos, DCTI/ISCTE 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úmero Nome Morada Disciplina Designação 0... * 0 … * frequenta

25 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (n/n II) Modelo Relacional Chave Estrangeira NAlunoNomeMorada 001AnaNULL 013JoãoNULL Designação Marketing Comunicação AlunoDisciplina Aluno Número Nome Morada Disciplina Designação 0... * 0 … * frequenta Aluno (NAluno, Nome, Morada) Disciplina (Designação) Frequenta (NAluno, Designação) NAlunoDisciplina 001Marketing 001Comunicação Frequenta Chave Estrangeira

26 Índice Pedro Ramos, DCTI/ISCTE 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ção 1 … * 0 … * Disciplinas da Licenciatura Tipo Avaliação Funcionário Num. Contribuinte Nome Morada Departamento Designação 1 0 … * Disciplinas da Licenciatura Data Admissão Departamento (Designação) Funcionário (Ncont, Nome, Morada, Designação, DtAdmissão)

27 Índice Pedro Ramos, DCTI/ISCTE 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 Nome Morada BI Aluno Número Curso Docente Número Categoria Pessoa (BI, Nome, Morada, Tipo) Aluno (Número, Curso, BI) Docente (Número, Categoria, BI)

28 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (Generalizações II) Modelo Relacional Chave Estrangeira NúmeroCursoBI 001História BINomeMoradaTipo JoãoNULLA AnaNULLD AlunoPessoa NúmeroCategoriaBI 10Assistente Docente Pessoa Nome Morada BI Aluno Número Curso Docente Número Categoria Pessoa (BI, Nome, Morada, Tipo) Aluno (Número, Curso, BI) Docente (Número, Categoria, BI)

29 Índice Pedro Ramos, DCTI/ISCTE 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 Nome Morada Telefone Número Sócio Individual Idade Profissão Organização CAE

30 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (Generalizações IV) Modelo Relacional Chave Estrangeira NSócioIdadeProfissão 1132Docente NSócioNomeMoradaTelefone 10JoãoNULL AnaNULL IndividualSócio NSócioCAE 10A Organização Sócio Nome Morada Telefone Número Sócio Individual Idade Profissão Organização CAE Sócio (NSócio, Nome, Morada, Telefone, tipoSócio) Individual (NSócio, Idade, Profissão) Organização (NSócio, CAE )

31 Índice Pedro Ramos, DCTI/ISCTE 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ção Morada Departamento Designação 1 0 … * Automóvel Matrícula Marca Modelo Roda Tipo Pneu Tipo Jante 1 4 Volante Material 1 Automovel (Matrícula, Marca, Modelo) Roda (IDRoda, TipoPneu, TipoJante, Matrícula) Volante (IDVol, Material, Matrícula)

32 Índice Pedro Ramos, DCTI/ISCTE 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úmero Data Linha da factura Produto Quantidade Preço Unitário 1 … * 1

33 Índice Pedro Ramos, DCTI/ISCTE Regras de Transposição (Composição II) Modelo Relacional Factura (NFact, Data) Linha (NFact, NLinha, Produto, Quantidade, PreçoUnit) Factura Número Data Linha da factura Produto Quantidade Preço Unitário 1 … * 1 Chave Estrangeira NFactData NFactNlinhaProdutoQuantidadePreçoUnit 111ProdA ProdB ProdB32000 FacturaLinha

34 Índice Pedro Ramos, DCTI/ISCTE 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.

35 Índice Pedro Ramos, DCTI/ISCTE 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.

36 Índice Pedro Ramos, DCTI/ISCTE Exemplos de Optimizações (I) Modelo Relacional Ano 1 … 12 1 Dia Mes 1 …30 1 Dias Serviço Hora Início Hora Fim Farmácia Nome Morada 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 Data Hora Início Hora Fim Farmácia Nome Morada 0 …* 1 Farmácia (IDFarmacia, Nome, Morada) Dias-Servico (IDFarmacia, Data, Hora_Inicio, Hora_Fim) Apenas um atributo

37 Índice Pedro Ramos, DCTI/ISCTE 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 Sigla Designação Disciplina Sigla Designação 0 … * Docente IDDocente Nome 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

38 Índice Pedro Ramos, DCTI/ISCTE Exemplos de Optimizações (III) Modelo Relacional Pessoa Nome Morada BI Aluno Número Curso Docente Número Categoria 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 Nome Morada Telefone Número Sócio Individual Idade Profissã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})

39 Índice Pedro Ramos, DCTI/ISCTE 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úmero Data Linha da factura Produto Quantidade Preç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).

40 Índice Pedro Ramos, DCTI/ISCTE Í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 ISBMTítuloDataAssunto 1A1998História 2D1997Informática 3C1994Sociologia 4Z2000Informática 5F1986Direito AssuntoÍndice Direito História Informática Sociologia Ficheiro de ÍndiceTabela de Publicação Ordenado por assunto

41 Índice Pedro Ramos, DCTI/ISCTE Índices (II) Modelo Relacional AssuntoÍndice Direito História Informática Sociologia Ficheiro de ÍndiceTabela 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). ISBMTítuloDataAssunto 1A1998História 2D1997Informática 3C1994Sociologia 4Z2000Informática 5F1986Direito Exemplos de interrogações que beneficiam do índice

42 Índice Pedro Ramos, DCTI/ISCTE Í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 ÍndiceTabela de Publicação ISBMTítuloDataAssunto 1A1998História 2D1997Informática 3C1994Sociologia 4Z2000Informática 5F1986Direito Pode ser criado um índice para dois ou mais atributos.

43 Índice Pedro Ramos, DCTI/ISCTE Í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.

44 Índice Pedro Ramos, DCTI/ISCTE Índices (V) Modelo Relacional Exemplos de acessos Tabela: Publicacao (ISBN (Int), Assunto (Str), Ano (Int), Titulo (Str)) registos ÍndiceInserçãoConsulta Nenhum3982 ISBN4022 ISBN, Assunto547 (+37%)0 Inserção: ISBN sequencial, restantes 3 aleatórios Consulta: Número de publicações com um determinado assunto Valores em segundos

45 Índice Pedro Ramos, DCTI/ISCTE 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úmero Data Linha da factura IDProduto Quantidade 1 … * 1 Produto IDProduto Designação Preç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 … *

46 Índice Pedro Ramos, DCTI/ISCTE 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

47 Índice Pedro Ramos, DCTI/ISCTE 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:

48 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 TempoOperaçãoSaldo 1T1 Ler saldo1000 2T1 Escrever Saldo900 3T2 Ler Saldo900 4T2 Escrever Saldo500 Exemplos de execuções Transacção T1Transacção T2 Ler saldo Saldo = Saldo - 100Saldo = Saldo Escrever Saldo Estado da BD coerente TempoOperaçãoSaldo 1T1 Ler saldo1000 2T2 Ler Saldo1000 3T2 Escrever Saldo600 4T1 Escrever Saldo900 Execução concorrente Lost update – perdeu-se uma actualização

51 Índice Pedro Ramos, DCTI/ISCTE Concorrência (II) Modelo Relacional Exemplo de uma situação de dirty read (ler valor inexistente) TempoOperaçãoTAB 1TAB 2 1T1 Ler movimento00 2T1 Escrever crédito TAB T2 Ler crédito T1 escrever débito1000(*)0 5T2 escrever crédito TAB T1 Escrever Saldo1000 Transacção T1Transacção T2 Ler movimentoLer crédito em TAB1 Escrever crédito em TAB1Escrever 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.

52 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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 Índice Pedro Ramos, DCTI/ISCTE 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. TempoT1T2 1Ler saldo_disp Calcular saldo_disp 2Ler saldo_cont Calcular saldo_cont 3Escrever saldo_disp 4Ler saldo_cont Calcular saldo_cont 5Escrever saldo_cont 6 O seguinte escalonamento (não serializado) não poderia acontecer: No entanto o 2PL não impede os dead locks.

58 Índice Pedro Ramos, DCTI/ISCTE Concorrência (IX) Modelo Relacional TempoT1T2 1Rlock (saldo_disp) 2Ler saldo_disp 3Rlock(saldo_cont) 4Ler saldo_cont 5Wlock(saldo_disp) 6Escrever saldo_disp 7Rlock(saldo_cont) 8Ler saldo_cont 9Wlock(saldo_cont) 10Wlock(saldo_cont) 11Unlock(saldo_cont) 12Wlock(saldo_cont) 13Escrever saldo_cont 14Unlock(saldo_disp) 15Unlock(saldo_cont) 16Rlock(saldo_cont) Situação de dead lock, T2 e T1 bloquedas. T2 tem que libertar.... T2 pode prosseguir Dead lock em 2PL

59 Índice Pedro Ramos, DCTI/ISCTE Concorrência (X) Modelo Relacional TempoT1T2 1Rlock (saldo_disp) 2Ler saldo_disp 3Rlock(saldo_cont) 4Ler saldo_cont 5Wlock(saldo_disp) 6Escrever saldo_disp 7Wlock(saldo_cont) (*) 8Wlock(saldo_cont) 9Escrever saldo_cont 10Unlock saldo_cont 11Wlock(saldo_cont) 12ler saldo_cont 13Escreve saldo_cont 14Unlock(saldo_disp) 15Unlock(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

60 Índice Pedro Ramos, DCTI/ISCTE 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.


Carregar ppt "Índice Pedro Ramos, DCTI/ISCTE Modelo Relacional Pedro Nogueira Ramos DCTI / ISCTE."

Apresentações semelhantes


Anúncios Google