5.2.1 Capítulo 5: Outras linguagens Query-by-Example (QBE) Datalog.

Apresentação em tema: "5.2.1 Capítulo 5: Outras linguagens Query-by-Example (QBE) Datalog."— Transcrição da apresentação:

1 5.2.1 Capítulo 5: Outras linguagens Query-by-Example (QBE) Datalog

2 5.2.2Datalog Estrutura de Base Sintaxe de regras Datalog Semântica de programas não recursivos Operações relacionais em Datalog Recursão em Datalog (programas definidos e estratificados) Expressividade de Datalog Recursão sobre negação (modelo bem-fundado) Answer-set programming

3 5.2.3 Estrutura de Base Programas em lógica sem predicados de controlo (e.g. !, var), sem “side-effects” (e.g. write, read) nem uso de símbolos funcionais. Permite recursão. Um programa Datalog é um conjunto de regras, que definem “views”. Exemplo: definir relação (view) v1 com todos os números de conta e respectivos saldos, para as contas de Perryridge com saldo superior a 700. v1(A, B) :– account(A, “Perryridge”, B), B > 700. Qual o saldo da conta “A-217” na view v1? ?- v1(“A-217”, B). Quais as contas com saldo superior a 800? ?- account(A,_,B), B > 800

4 5.2.4 Exemplos de perguntas Cada regra define um conjunto de tuplos que pertencem à view  E.g. v1(A, B) :– account(A, “Perryridge”, B), B > 700 lê-se como para todo A, B se (A, “Perryridge”, B)  account e B > 700 então (A, B)  v1 O conjunto de tuplos duma view é definido como a união dos conjuntos de tuplos de cada uma das suas regras. Exemplo: interest-rate(N, 5) :– account(N,A, B), B = 10000

5 5.2.5 Negação em Datalog Definir a view c contendo os nomes de todos os clientes que têm pelo menos um depósito mas não têm empréstimos: c(N) :– depositor(N, A), not is-borrower(N). is-borrower(N) :–borrower (N,L). NOTA: usando directamente not borrower (N, L) na 1ª regra dava resultado diferente: clientes N que têm pelo menos um depósito e existe algum empréstimo L que não é de N  Para evitar confusão (e problemas de implementação), é usual exigir-se que as variáveis em literais negados apareçam na cabeça da regra ou em algum literal positivo do corpo da regra Problema de floundering. Considere: p(X) :- not q(X). q(a). e as perguntas ?- p(X). e ?- p(b).

6 5.2.6 Regras por camadas (views sobre views) Quais os juros de cada uma das contas de Perryridge interest(A, l) :– perryridge-account(A,B), interest-rate(A,R), l is B * R/100. perryridge-account(A,B) :– account(A, “Perryridge”, B). interest-rate(N,0) :– account(N, A, B), B = 2000. Camadas das várias views:

7 5.2.7 Recursão em Datalog Considere a relação: precedencia(X, Y) contendo pares X, Y de cadeiras onde X dá precedência directa para Y. Cada cadeira pode dar precedência para outras, directa ou indirectamente  Uma cadeira X dá precedência indirectamente a Y, se dá precedência directa a uma cadeira Z, que por sua vez dá precedência para Y Encontrar todas as cadeiras que dão precedência (directa ou indirecta) a Bases de Dados 1. Podemos escrever o seguinte programa Datalog recursivo: precBD1(X) :- precedencia(X, ‘BD1’). precBD1(X) :- precedencia(X, Y), precBD1(Y).

8 5.2.8 Recursão em Datalog (Cont.) De forma mais geral: criar view precs com todos os pares (X, Y) onde X dá precedência directa ou indirecta para Y: precs(X, Y) :– precedencia(X, Y). precs(X, Z) :– precs(X,Y), precs(Y,Z). Quais as cadeiras que dão precedência a BD1 ?- precs(X, ‘BD1’). E qual o significado preciso disto?  É mesmo igual a Prolog?  Que views é que são definidas assim?  A sintaxe é parecida com a do Prolog. Mas qual é, exactamente?

9 5.2.9 Exemplo de pergunta complexa Questão 28 da 1ª ficha de problema SQL:  Quais os nomes dos alunos que não seguiram pelo menos uma das precedências (directas) aconselhadas, e em que cadeiras não as seguiram? nao_fez(NAluno,CCurso,CCadeira) :- curso_cadeira(CCurso,CCadeira,_Semestre), not(esta_inscrito(NAluno,CCurso,CCadeira) ). esta_inscrito(NA,CCr,CCd) :- inscricoes(NA,CCr,CCd,_DIn,_DAv,_Nt) query(Nome,Cadeira) :-alunos(Num,Nome,_L,_Dt,_Sx,_Cr), inscricoes(Num,CCurso,CCadeira,_DIn,_DAv,Nt), precedencias(CCurso,CCadeira,CadP), nao_fez(Num,CCurso,CadP), cadeiras(CCadeira,Cadeira,_C,_D). query(Nome,Cadeira) :-alunos(Num,Nome,_L,_Dt,_Sx,_Cr), inscricoes(Num,CCurso,CCadeira,DIn,_DAv,_Nt), precedencias(CCurso,CCadeira,CadP), inscricoes(Num,CCurso,CadP,_DIn,DAv,_Nt), DAv > Din, cadeiras(CCadeira,Cadeira,_C,_D). E se fossem precedências indirectas, bastava substituir precedencias por precs.

10 5.2.10 Sintaxe de regras Datalog Um literal positivo (ou átomo) tem a forma p(t 1, t 2..., t n )  p é o nome da relação, com n atributos  cada t i é uma constante ou uma variável Um literal negativo (ou por default) tem a forma not p(t 1, t 2..., t n ) Operadores de comparação são entendidos como predicados  E.g. X > Y é entendido como o átomo >(X,Y)  Conceptualmente “>” define uma relação (infinita) contendo todos os pares (X,Y) onde X é maior que Y. Operações aritméticas são entendidas como predicados  E.g. A is B + C é entendido como +(B, C, A), onde a relação (infinita) “+” tem todos os triplos em que o 3º valor é igual à soma dos primeiros 2.

11 5.2.11 Sintaxe de regras Datalog (Cont.) Regras são da forma: p(t 1, t 2,..., t n ) :– L 1, L 2,..., L m.  cada L i é um literal (positivo ou negativo)  cabeça – átomo p(t 1, t 2,..., t n )  corpo – literais L 1, L 2,..., L m A uma regra com corpo vazio chama-se um facto: p(v 1, v 2,..., v n ).  afirma que o tuplo (v 1, v 2,..., v n ) pertence à relação p Um programa Datalog é um conjunto (finito) de regras Um programa diz-se definido, se nenhuma das suas regras contém literais negativos (i.e. se not não aparece no programa).

12 5.2.12 Operações Relacionais em Datalog Projecção do atributo account-name de account: query(A) :– account(A, N, B). Produto cartesiano das relações r 1 e r 2. query(X 1, X 2,..., X n, Y 1, Y 2,..., Y m ) :– r 1 (X 1, X 2,..., X n ), r 2 (Y 1, Y 2,..., Y m ). União das relações r 1 e r 2. query(X 1, X 2,..., X n ) :– r 1 (X 1, X 2,..., X n ). query(X 1, X 2,..., X n ) :– r 2 (X 1, X 2,..., X n ). Selecção de tuplos de r 1 que obedecem a condição cond. query(X 1,..., X n ) :– r 1 (X 1,..., X n ), cond(X 1,..., X n ). Diferença entre r 1 e r 2. query(X 1, X 2,..., X n ) :– r 1 (X 1, X 2,..., X n ), not r 2 (X 1, X 2,..., X n ).

13 5.2.13 Semântica duma regra Uma instância duma regra é o resultado de substituir cada uma das variáveis da regra por alguma constante.  Eg. Sendo v1 v1(A,B) :– account (A,“Perryridge”, B), B > 700.  Uma instância de v1 é: v1(“A-217”, 750) :–account(“A-217”, “Perryridge”, 750), 750 > 700. O corpo duma instância duma regra R’ é satisfeito num conjunto de factos I (interpretação, ou instância da base de dados) sse 1.Para cada átomo q i (v i,1,..., v i,ni )  R’, l contem q i (v i,1,..., v j,ni ). 2.Para cada literal not q j (v j,1,..., v j,ni )  R’, l não contem q j (v i,1,..., v j,ni ).

14 5.2.14 Restrições nas variáveis É possível escrever regras com um nº infinito de soluções. maior(X, Y) :– X > Y not-in-loan(B, L) :– not loan(B, L) Em Prolog isto não era problema (tuple-at-a-time). Mas agora é, se quisermos saber o resultado duma pergunta (set-at-a-time) Para evitar este problema, em Datalog:  Toda a variável que apareça na cabeça duma regra tem que aparecer também no corpo dessa regra, e num átomo que não seja expressão aritmética.  Esta condição pode ser tornada mais fraca para permitir regras como: p(A) :- q(B), A is B + 1  Toda a variável que apareça num literal negativo no corpo duma regra tem que aparecer também num átomo do corpo dessa mesma regra.

15 5.2.15 Semântica de Programas Definidos Seja I uma interpretação (conjunto de factos). Define-se, para um programa definido P: T P (I) = {p(t 1, t 2,..., t n ) : existe uma instância R’ duma regra R de P com cabeça p(t 1, t 2,..., t n ) cujo corpo está satisfeito em I} A semântica (significado) de um programa definido P sobre uma instância duma base de dados I é o resultado do menor ponto- fixo da sequência:  I 0 = I(sendo P definido, esta sequência é não decrescente)  I n+1 = T P (I n ) O resultado duma view v com k argumentos, num programa P e base de dados I é o conjunto de todos os factos v(t 1, t 2,..., t k ) pertencentes ao ponto-fixo. Claro que não é assim que está implementado!!!

16 5.2.16 Datalog vs Prolog (em programas definidos) Datalog não é muito útil para implementar algoritmos:  não é possível controlar a execução do programa.  não se podem usar estruturas de dados (infinitas) recursivas. Em Prolog não nos podemos verdadeiramente abstrair do modelo de execução. Exemplo: p(X) :- p(X).?- p(R). p(a).(em Prolog – loop; em Datalog {p(a)}) Prolog: apropriado para implementar algoritmos (na linha de outras linguagens de programação, e.g. C) Datalog: apropriado para descrever relações e perguntas a bases de dados (na linha de outras linguagens de perguntas, e.g. SQL)

17 5.2.17Monotonicidade Uma view V é monotónica se para qualquer par de conjunto de factos I 1 e I 2 tais que l 1  I 2, se tem E v (I 1 )  E v (I 2 ), onde E v é a expressão que define V. Um programa Datalog P é monotónico sse para todo o I 1 e I 2 : l 1  I 2 implica T P (I 1 )  T P (I 2 ), Views de álgebra relacional que usem os operadores    , e  (bem como outros – e.g. joins – definidos à custa destes) são monotónicas. Views de álgebra relacional com ‘–’ podem não ser monotónicas. Da mesma forma, programas Datalog definidos são monotónicos, mas programas Datalog com negação podem não o ser.

18 5.2.18Não-monotonicidade A semântica à custa do operador T P só funciona em programas monotónicos.  Algumas conclusões numa iteração, podem deixar de o ser numa iteração posterior – possibilidade de não convergência para um ponto fixo. E.g. other_accounts(Num) :- not perryridge_account(Num). perryridge_account(N) :–account(Num, “Perryridge”, _B). Na 1ª iteração uma conta doutra sucursal aparece na view other_accounts mas desaparece na 2ª iteração. Pode-se estender a iteração do T P para lidar com negação em programas estratificados (i.e. sem recursão sobre negação)

19 5.2.19 Programas Estratificados Um programa Datalog é estratificado se cada um dos seus predicados pode ser colocado num estrato de tal forma que: 1. Para cada literal positivo q no corpo duma regra com cabeça p p(..) :- …., q(..), … o estrato de p é maior ou igual do que o estrato de q 2. Dada uma regra com um literal negativo no corpo p(..) :- …, not q(..), … o estrato de p é estritamente maior que o estrato de q Por outras palavras, recursão e negação não se misturam

20 5.2.20 Perfect Model A semântica dum programa estratificado é definida estrato a estrato, começando pelo menor deles (que não tem negação). Em cada estrato usa-se a iteração T P Calculado o resultado final da iteração de T P num estrato n, usa- se para nos “livrarmos” da negação no estrato n+1:  Seja not q um literal negativo que aparece no corpo duma instância duma regra do estrato n+1:  Se q  T P dum estrato anterior → apague-se a instância  Caso contrário → apague-se o not q do corpo dessa instância Como os estratos inferiores são calculados antes, os seus factos não mudam. Logo, os resultados de cada estrato são monotónicos, se fixados os resultados dos estratos anteriores.

21 5.2.21 Datalog vs SQL Tudo o que se consegue exprimir em SQL (sem agregação) consegue exprimir-se em Datalog (e nem é preciso recursão).  É fácil introduzir agregação em Datalog. Mas não há uma forma standard, aceite por todos.  Também é possível definir formas de actualização de relações em Datalog (mas também não há forma standard). Há muitas view úteis, que exigem recursão, que não se conseguem exprimir em SQL e se conseguem em Datalog.  Com SQL é mais vezes necessário passar parte da interrogação para uma linguagem (embedded) imperativa. O SQL é (de longe) mais conhecido e usado. Datalog exige conhecimentos de programação em lógica, que nem todos têm. É usual dizer-se que as implementações de SQL são bem mais eficientes e robustas. Mas isto é cada vez menos verdade:  Há hoje implementações eficientes e robustas de Datalog (e.g. XSB-Prolog)  Essas implementações permitem ligações via ODBC, permitindo até ter partes em SQL  Usa-se SQL nas partes em que este serve  Usa-se Datalog nas partes em que o SQL não chega (ou é pior)

22 5.2.22 O poder expressivo da recursão Views recursivas permitem especificar perguntas, tal como fechos transitivos, que não podem ser especificadas sem recursão ou iteração.  Intuição: Sem recursão só se podem fazer um número fixo de junções entre relações (e.g. de precedencias com precedencias)  Isto só nos dá as precedências com indirecção até esse número fixo.  Dado um programa é sempre possível construir uma base de dados em que o nível de indirecção é maior, e na qual o programa sem recursão não funciona. A complexidade de cálculo de programas sem recursão é constante A complexidade de cálculo do modelo perfeito é linear no número de instâncias de regras Se um problema é de complexidade linear, é impossível descrevê-lo numa linguagem com complexidade inferior a linear (i.e. constante)

23 5.2.23 Para além de programas estratificados E se a complexidade do problema for maior que linear? Aí os Programas Estratificados já não são úteis:  Problemas NP-completo: E.g.  caminhos Hamiltonianos em grafos: que passam por todos os nós, sem nunca repetir um nó;  caminhos de custo mínimo: problema de caixeiro viajante  Nestes problemas seria necessário um nº exponencial de regras para os exprimir em programas estratificados (a não ser que P = NP!!). Há perguntas que não se exprimem com programas estratificados.  Considere a relação movimento(P1,P2) que guarda movimentos possíveis dum jogo.  Um posição é ganhante se é possível fazer um movimento para uma outra posição que é perdedora.  Uma posição é perdedora se não se pode concluir que é ganhante.

24 5.2.24 Para além de estratificados (Cont.) Um posição é ganhante se é possível fazer um movimento para uma outra posição que é perdedora. Uma posição é perdedora se não se pode concluir que é ganhante. ganhante(X) :- movimento(X,Y), perdedora(Y) perdedora(X) :- not ganhante(X) a b c d e f a e c são posições ganhantes. d e b são posições perdedoras. e e f não são uma coisa nem outra (empates).

25 5.2.25 Modelo bem fundado Ideias de base:  Uma interpretação a 3–valores tem factos verdadeiros, factos falsos e factos desconhecidos.  Parte-se da instância da base de dados:  tudo o que lá está é verdadeiro  tudo o resto é desconhecido  (nada é falso à partida)  Dada um interpretação a 3 valores, calcular-se novos factos que são garantidamente falsos e, com base nestes, novos factos que são garantidamente verdadeiros.  Itera-se o processo até que não haja mais factos garantidamente falsos, nem mais factos garantidamente verdadeiros.  No final podem haver factos se mantêm desconhecidos (não são verdadeiros nem falsos).

26 5.2.26 Modelo bem-fundado (Cont.) Dado uma interpretação a 3-valores I, calculam-se os factos que garantidamente falsos com base em I da seguinte forma:  Apagam-se todas as instâncias de regras contendo not q se q é verdadeiro em I  Apagam os restantes literais negativos (i.e. literais not q, onde q é falso ou desconhecido)  Calcula-se o menor ponto fixo de T P sobre o programa (definido) resultante  São garantidamente falso os factos que não estão lá. Calculados os garantidamente falso com base em I, calculam-se os novos garantidamente verdadeiros da seguinte forma:  Apagam-se todas as instâncias de regras contendo not q se q é não é garantidamente falso em I (nem no que se acabou de calcular, já agora)  Apagam os restantes literais negativos (i.e. literais not q, onde q é garantidamente falso)  Calcula-se o menor ponto fixo de T P sobre o programa (definido) resultante  São também garantidamente verdadeiros os factos que lá estão.

27 5.2.27 Bem fundado vs Perfect O modelo bem-fundado permite exprimir perguntas que combinam negação com recursão. É mais expressivo que programas estratificados. A complexidade de cálculo do modelo bem-fundado é quadrática no número de instâncias de regras. XSB-Prolog implementa o modelo bem-fundado  Pode-se usar, ligando com programas em linguagens imperativas, e com partes em SQL, via ODBC.  É eficiente e robusto.  Ganha-se bastante em expressividade. Mantém-se o problema de expressividade para o caso de problemas NP-completo!!

28 5.2.28 Answer-Set Programming Semântica de Datalog com complexidade (e expressividade) NP-completo. Define views não-deterministicas Existem implementações, também com interface ODBC (e via XSB Prolog): smodels e dlv Estas implementações são bastante robustas. São eficientes (mas tendo em conta a complexidade, nunca podem ser muito eficientes para problemas grandes). Não faz muito sentido usar para exprimir problemas que não sejam NP-completo. Mas para problemas NP-completo, faz todo o sentido!!!

29 5.2.29Answer-sets Uma interpretação é um conjunto de factos verdadeiros  Um facto é falso numa interpretação I, sse não pertence a I I é um answer-set sse é o menor ponto fixo de T P, sobre o programa definido obtido da seguinte forma:  Apagam-se de P todas as instâncias de regras que contêm not q, para algum q  I  Apagam-se os restantes literais negativos em corpos de instâncias regras (i.e. literais not q onde q é falso em I) Um programa pode ter vários (ou nenhum) answer-sets Geração e teste: gera-se aleatoriamente um I; testa-se depois para ver se é answer-set.  Claro que não é assim que está implementado!!! Cada answer-set define uma hipótese para as várias views

30 5.2.30 Exemplo ASP Dadas as relação voo(De,Para) e cidade(Nome), definir view vooCam com os voos que fazem parte dum caminho que passa por todas as cidades, sem passar duas vezes por nenhuma delas (este é um problema NP-Completo – caminhos Hamiltonianos): vooCam(X,Y) :- voo(X,Y), not vooFora(X,Y). vooFora(X,Y) :- voo(X,Y), not vooCam(X,Y). passaPor(C) :- vooCam(C,_). passaPor(C) :- vooCam(_,C). repete(C) :- vooCam(C1,C), vooCam(C2,C), C1 \= C2. saidaErrada(C) :- vooCam(C,C1), vooCam(C,C2), C1 \= C2. problema(C) :- cidade(C), not passaPor(C), not problema(C). problema(C) :- repete(C), not problema(C). problema(C) :- saidaErrada(C), not problema(C). Podem haver vários answer-sets. Cada um deles contem na view vooCam um conjunto de voos que satisfazem a pergunta (i.e. um caminho Hamiltoniano do grafo de voos) Se não houverem caminhos Hamiltonianos, então não há answer- sets

31 5.2.31 Mais um exemplo ASP Dadas as relação aula(codA,tipoSala,codCadeira), sala(num,tipo), dia(dia) e hora(hora), definir view horario(codAula,numSala,dia,Hora) com uma atribuição de aulas a salas, em que numa sala não podem haver duas aulas em simultâneo, uma cadeira não pode ter duas aulas em simultâneo, e todas as aulas têm que ter um horário atribuído (mais um problema NP-Completo!): horario(A,S,D,H) :- aula(A,T,_),sala(S,T), dia(D), hora(H), not livre(A,S,D,H). livre(A,S,D,H) :- aula(A,T,_),sala(S,T), dia(D), hora(H), not horario(A,S,D,H). atribuida(A) :- aula(A,_,_), horario(A,S,_,_). mesmaSala(A1,A2) :- horario(A1,S,D,H), horario(A2,S,D,H), A1 \= A2. mesmoHor(A1,A2) :- horario(A1,S1,D,H), horario(A2,S2,D,H) (A1,S1) \= (A2,S2). problema :- aula(A1,_,_), aula(A2,_,_), mesmaSala(A1,A2), not problema. problema :- aula(A1,_,C), aula(A2,_,C), mesmoHor(A1,A2), not problema. problema :- aula(A,_,_), not atribuida(A), not problema. Cada answer-sets corresponde a um horário possível. Claro que o problema de fazer horários é um pouco mais complicado (cadeiras do mesmo semestre, lotação das salas e inscrições, durações diferentes, etc). Não é muito mais complicado fazer a view... Só que não cabia num acetato