1ère partie Nadine Cullot. Bases de données déductives. Bases de données déductives Introduction et Motivation

Transcription

1 Master STIC «Image Informatique et Ingénierie» Module Informatique Modèles de représentation - 10h CM Nadine Cullot Kokou Yétongnon nadine.cullot@u-bourgogne.fr kokou.yetongnon@u-bourgogne.fr 1ère partie Nadine Cullot Modèles logiques: Modèles déductifs à base de règles de type Datalog Modèles logiques orientés objets Frame Logique Modèles basés sur les logiques de description OWL 1 2 Introduction et motivation des concepts de BD déductives Les concepts de bases : Datalog Syntaxe et sémantique d une programme Datalog Méthodes d évaluation d un programme Datalog Apparues dans les années 1970, Les BD déductives sont encore un domaine de recherche reconnu et actif dans la communauté des Bases de Données. Au sens large, le terme déductif peut être attribué lorsqu une partie des données de la base est représentée par des règles (règles de déductions). 3 4 Description des données de façon intentionnelle : par les règles données dérivées Moteur d inférence mécanisme qui permet l activation de ces règles méthodes d évaluation règle : "tête" "corps" Domaine concernés par les BD déductives BASES DE DONNEES vues requêtes contraintes d'intégrité... INTELLIGENGE ARTIFICIELLE représentation des connaissances démonstration automatique systèmes experts... PROGRAMMATION LOGIQUE langage de programmation règles

2 Les BDD ne sont pas une nouvelle technologie de Gestion de Bases de Données, mais doivent être vues comme des fonctionnalités supplémentaires pour des SGBD qui permettent de définir et gérer des données dérivées (ou déduites) : non décrites explicitement. Les BD déductives : pour quoi faire? L utilisation de règles permet d améliorer la modélisation des connaissances définir des règles récursives (cartes, graphes, hiérarchies) introduire des niveaux de hiérarchie dans les données, accroître ou restructurer une BD sans modification physique des données, ajouter (de définir) des termes sans redondance, ni modification. 7 8 Les règles permettent aussi de proposer une alternative au concept de vue pour décrire des données en évitant des duplications redondantes proposer différents niveaux d autorisation d accès, représenter le «sens» des données stockées dans la base, définir des contraintes d intégrité, définir des règles de mise à jour de la base. Peut-on parler de domaine spécifique pour les BD déductives? La réponse peut être non, mais les BD déductives peuvent s appliquer dans tout type de contexte : grâce au niveau d abstraction qu elles permettent de définir grâce à la possibilité d introduire des nouveaux termes sans modification des données existantes 9 10 Certaines applications, typiquement de type recherche dans des graphes dont la complexité est très grande sont à l origine du développement des BDD: recherche de techniques efficaces issues de l IA mais les apports des BDD ne se limitent pas à ce type d applications Les différents types de couplage Couplage faible consiste à prendre un SGBD (relationnel) un langage de programmation logique et à bâtir une interface d appel du SGBD depuis le langage Langage Logique + Prédicats du SGBD Requêtes Système déductif SGBD

3 Les différents types de couplage Couplage fort consiste à modifier l interpréteur du langage logique de manière à rendre transparent les appels au SGBD (pas de visibilité externe du SGBD par l utilisateur, mais visibilité des connaissances comme des prédicats du langage Langage Logique Système déductif SGBD Les différents types de couplage Intégration complète des mécanismes de déduction au SGBD nécessité de retoucher au code d un SGBD (relationnel) ajout d un évaluateur de règles, d opérateurs spécialisés, etc... meilleures performances langage d interrogation du système peut être une extension d un langage de requêtes Langage de règles Déduction SGBD Datalog notion de règle Une règle de déduction peut s'exprimer sous différentes formes : en utilisant un formalisme de langage déclaratif de requêtes de BD, ou tout autre modèle de données Datalog ( = prolog "pur") subordonné(x,y) <= travaille_pour(x,z) & chef(y,z) Datalog notion de règle Calcul relationnel subordonné = { X1,Y1 X appartient à "travaille_pour", & Y appartient à "chef & X2 = Y2 } SQL Create view "subordonné" as select "travaille_pour".1, "chef".1 from "travaille_pour", "chef" where "travaille_pour".2 = "chef".2 Algèbre relationnelle subordonné <- 1,3 [σ 2=4 (travaille_pour x chef)] Datalog motivation et cadre Datalog est accepté comme un "quasi standard" dans le domaine des BDDs. notation syntaxique des règles de déduction proche des notations prolog (clauses de Horn) C'est un langage de règles et de requêtes pour le modèle de données relationnel des extensions proposées pour les modèles objets (pas de standard) 17 Datalog motivation et cadre Une Base de Données relationnelle vérifie les principes suivants : les relations ne contiennent pas d'instances dupliquées, l'ordre des tuples n'a pas d'importance l'ordre des attributs de la relation est fixe Il y a un ensemble fini de relations. Les tuples ne contiennent ni variables, ni termes fonctionnels, ni structures. Ces différents points se retrouvent au niveau de Datalog "pur" ( non étendu). 18 3

4 Datalog syntaxe Les littéraux positifs (les faits) Les tuples d'une relation sont représentés par des littéraux positifs instanciés. description par table : forme datalog p : 1 a 13 p(1,a,13) 3 b 3 p(3,b,3) 6 a 5 p(6,a,5) conventions : constantes lettres minuscules ou chiffres variables : lettres majuscules des littéraux qui contiennent des variables peuvent être vus comme des requêtes (simples) p(x,a,y) --> donne les deux réponses (par unification) X = 1 et Y = 13 X=6 et Y=5 Datalog syntaxe Les conjonctions de littéraux possibilité d'exprimer des liens par l'occurrence multiple d'une variable dans ces littéraux p(x,y) & q(y,z) p :1 a q : a 4 2 a b 5 3 b c 6 recherche des unifications possibles X Y Z 1 a 4 2 a 4 3 b Datalog syntaxe Les règles :forme générale L0 <- L1 &... & Ln n 1, Li littéraux positifs L0 tête et Li corps de la règle Intuitivement, chaque unification possible de la tête est un tuple de la relation dérivée qui est composée de l'ensemble des tuples. p(x,z) <- q(x,y) & r(y,z) p:1 a q : 1 b r: b a 1 c b c c a Datalog syntaxe Récursivité La définition d'une relation peut être faite à l'aide de règles récursives. fermeture transitive d'une relation supérieur(x,y) <- chef(x,y) supérieur(x,y) <- chef(x,z) & supérieur(z,y) Datalog sémantique On appelle notation logique d'un programme Datalog, l'ensemble des formules de la logique du 1er ordre qui lui est associé. La sémantique d'un programme Datalog est liée à la sémantique de sa notation logique. en Datalog pas de termes fonctionnels ==> le domaine de Herbrand est fini (constantes du programme) règles exprimées par des clauses de Horn définies (exactement 1 littéral positif par clause) existence d'un modèle minimal unique associé au programme On appelle modèle canonique (Mp), le modèle minimal de la notation logique de p. 23 Datalog sémantique On considère les trois énoncés suivants : /* 1 er énoncé */ chemin(x,y) <- arc(x,y) chemin(x,y) <- arc(x,z) & chemin(z,y) /* 2 ème énoncé */ chemin(x,y) <- arc(x,y) chemin(x,y) <- chemin(x,z) & arc(z,y) /* 3 ème énoncé */ chemin(x,y) <- arc(x,y) chemin(x,y) <- chemin(x,z) & chemin(z,y) D'un point de vue sémantique, ces trois énoncés sont équivalents ==> même modèle canonique aspect déclaratif important en Datalog, on souhaite conserver cette équivalence d'un point de vue opérationnel. 24 4

5 Datalog sémantique L implication en datalog Correspondance entre l'implication d'un fait positif par un programme datalog et le programme logique associé : un fait positif (A) est impliqué par un programme datalog ssi c'est une conséquence logique du programme associé un fait négatif (~A) est impliqué par un programme Datalog ssi sa négation (i.e. A) n'est pas impliqué par le programme logique ( le programme logique impliqe ~A) en terme de modèle, Datalog applique l Hypothèse du Monde Clos Datalog sémantique Sémantique de Datalog par point fixe L'approche par point fixe est une approche plus constructive: il s'agit de construire le plus petit point fixe associé à un programme datalog définissant sa sémantique. intuitivement : Le "plus petit point fixe" est une partie de la base de Herbrand ( ==> va correspondre au modèle minimal) La construction de cet ensemble suppose l'existence d'un opérateur de "conséquence immédiate" pour produire ces faits L'opérateur de conséquence immédiate calcule tous les faits déductibles en une "étape" à partir d'un ensemble de faits (I) le "pppf" est construit par applications successives de cet opérateur Datalog sémantique Datalog méthodes d évaluation Soit le graphe suivant : et les définitions classiques de arc et chemin chemin(x,y) <- arc(x,y) chemin(x,y) <- arc(x,z) & chemin(z,y) I0 = T(p) (vide) = { faits } = { arc(a,b), arc(b,c), arc(b,d) } I1 = T(p) (I0) = I0 {chemin(a,b), chemin(b,c), chemin(b,d) } I2 = T(p) (I1) = I1 {chemin(a,c), chemin(a,d) } I3 = T(p) (I2) = I2, pas de nouveaux ajouts I2 = Plus Petit Point Fixe du programme a d b c La description de la sémantique d'un programme suggère des méthodes d'évaluation de ce programme Approche constructive du point fixe implémentation correcte de l'opérateur de conséquence immédiate méthode d'évaluation Approche modèle minimal et correspondance avec l'implication logique sur les faits positifs implémentation correcte de la résolution linéaire méthode d'évaluation Datalog méthodes d évaluation Deux classes de méthodes d'évaluation issues de ces deux approches sont considérées : Les méthodes dites en chaînage avant inspirées du plus petit point fixe méthode naïve (calculs inutiles, redondants) méthode semi-naïve (incrémentale) Les méthodes dites en chaînage arrière inspirées par l'approche modèle minimal et les techniques de résolution SLD résolution Datalog méthodes d évaluation méthodes mixtes (chaînage avant et arrière) SLD-AL résolution requêtes-sous-requêtes (QSQ) (implémentation algébrique interprétée de la SLD_AL résolution) les ensembles magiques (implémentation compilée de la SLD_AL résolution)

6 Idée intuitive : Implémentation de l'opérateur de conséquence immédiate et itération de celui-ci à l'aide des opérations sur les algèbres (projection (Π), sélection (σ) et produit cartésien (x)) Technique : on associe à chaque règle du programme p(x1,..., Xn) <- Q1(t1.1,...,t1.l) &... & Qp(tp.1,...,tp.m) un expression algébrique qui consiste à : Faire le produit cartésien sur les prédicats du corps (Qi), Faire une sélection tenant compte des occurrences des constantes dans le Qi des occurrences multiples de variables dans les Qi Faire une projection sur les attributs du prédicat "tête" de règle Exemple : R1 : s(x,y) <- p(x,z) & s(z,w) & t(w,y) Expr(s) (R1) = Π 1,6 [σ 2=3, 4=5 (p x s x t)] Le produit cartésien de p,s et t produit des 6 - uplets sur lesquels on impose que les attributs 2 et 3, 4 et 5 soient égaux et on projette sur les attributs 1 et 6. L'expression algébrique associée à un prédicat intensionnel est l'union des expressions algébriques pour chaque règle qui définit le prédicat. R2 : s(x,y) <- p(x,y) Expr (s) (R2) = p ( ou bien Π 1,2 p) La traduction algébrique d'une règle peut être faite ssi : Le prédicat tête de règle ne contient ni constante, ni occurrence multiple de variables sinon transformation préalable de la règle Expr (s) = { p Π1,6 [σ 2=3, 4=5 (p x s x t)]} Cas de l'occurrence d'une constante dans la tête de règle: p(x,a,y) <-... On réécrit la règle sous la forme : p(x,z,y) <-... & Z = a La relation associée au prédicat Z=a est une relation unaire, composée de l'unique 1-uplet <a> Cas d'occurrence multiple d'une même variable dans la tête de règle p(x,y,x) <-... & q(...,x,...) &... Ici, occurrence multiple de la variable X On remplace la 2ème variable X par une nouvelle variable, on impose en partie droite l'égalité de ces deux variables p(x,y,z) <-... & q(...,x,...) &... & X=Z La relation associée au prédicat Z=X est une relation unaire, calculée à partir du premier prédicat q du corps de la règle qui contient X

7 Exemple : R1 : p(x,x,y) <- q(x,y) & r(x) p(x,z,y) <- q(x,y) & r(x) & X = Z Expr (p) (R1) : Π 1,2,4 [σ 1=3=4 q x r x rel ] où rel = Π 1q Exemple : arc(a,b) arc(b,c) arc(b,d) chemin(x,y) <- arc(x,y) chemin(x,y) <- arc(x,z) & chemin(z,y) Expressions algébriques : Expr(chemin) = arc Π1,4 [σ 2=3 arc x chemin ] Chemin.0 = vide Chemin.1 =? on évalue l'expression algébrique associée à chemin, Chemin.1 = arc U Π 1,4 [σ 2=3 arc x chemin.0 ] = arc = { <a,b>, <b,c>, <b,d> } Chemin.2 = arc U Π 1,4 [σ 2=3 arc x chemin.1 ] arc U Π 1,4 [σ 2=3 arc x arc] = { <a,b>, <b,c>, <b,d>, <a,c>, <a,d>} Chemin.3 = arc U Π 1,4[σ 2=3 arc X chemin.2 ] = arc U Π 1,4[σ 2=3 arc x arc ] U Π 1,6[σ 2=3, 4=5 arc x arc x arc] pas de nouveaux N-uplets, fin des traitements Sélection de la réponse à la requête : chemin (a,y)? Π 2 [σ 1=a Chemin.2] Datalog Conclusion Datalog est un langage basé sur l utilisation de règles Plusieurs méthodes d évaluation ont été étudiées/proposées : évaluation naïve résolution SLD-AL méthode des requêtes sous requêtes les ensembles magiques Datalog et Le langage Datalog «pur» ne permet pas : D utiliser la négation dans le corps des règles D utiliser des termes fonctionnels dans les littéraux Exemple : chemin (f(x), Y ) <=. f(x) est un terme fonctionnel Des extensions ont été proposées Pour traiter la négation (mécanisme de stratification des programmes Datalog) Pour les termes fonctionnels et les objets complexes Introduction Datalog et La F-logique est une réponse aux restrictions de Datalog, Avec une approche orientée objet Des termes fonctionnels Et des règles Prise en charge de la négation dans le corps des règles (stratification)

8 Introduction Les modèles orientés objet Les modèles orientés objets sont basés sur : Les classes Attributs, méthodes, droits d accès Encapsulation Les hiérarchies de généralisation/spécialisation Mécanisme d héritage Surcharge des méthodes Polymorphisme Possibilité de définir des objets complexes et de spécifier leur utilisation et leurs comportements Ré-utilisation Introduction Les modèles OO et la La propose une approche orientée objet Attributs et méthodes sont décrits de façon similaire des approches OO «classiques» Mécanisme d héritage La F-logique offre en plus des modèles OO, la description de connaissances avec des règles Introduction La La est donc un formalisme entre les modèles déductifs comme Datalog et les modèles orientés objet. La permet de définir Des classes Les objets ont des propriétés (attributs/méthodes) Des hiérarchies d héritage Des objets complexes à l aide de règles 45 Introduction La La a été introduite en 1995, par M. Kifer, G. Lausen, J Wu Logical foundations of object-oriented and framebased languages. Journal of the ACM Des implémentations de la ont été développées Système Florid (1998) Système OntoBroker (1999) Le système Flora (2000) 46 Classes et méthodes Les classes et les propriétés des objets (attributs et méthodes) sont définies à l aide de signatures. L ensemble des signatures des classes et la hiérarchie d héritage peut être vu comme le schéma de la base de données Les signatures des classes sont vues en F- Logique comme des contraintes de type sur les propriétés des objets Classes et méthodes Signatures person[father => man] person[daugther =>> woman] person[friend =>> (man, woman)] man[son@(woman) =>> man] father, daugther et friend sont des méthodes de la classe person Le symbole => désigne une méthode mono-valuée Le symbole =>> désigne une méthode multi-valuée La méthode son est une méthode avec paramètre de type woman Attention : le terme méthode est à prendre au sens large (attributs + méthodes)

9 Classes et méthodes Les méthodes avec paramètres peuvent être surchargées man => man] man integer) => man] Deux propriétés «homonymes» sont décrites pour les objets de type man la 1ère propriété décrit le fils (son) d un homme (man) paramétré par le nom de sa mère (woman) La 2ème propriété décrit le fils (son) d un homme (man) paramétré par le nom de la mère (woman) et le rang de l enfant (integer). Hiérarchies d héritage Les classes peuvent être organisées en hiérarchies de spécialisation/généralisation man :: person woman :: person Les classes man et woman sont des sousclasses de la classe person Hiérarchies d héritage Deux types d héritage sont considérés en F-logique L héritage structurel i.e. la propagation des restrictions de classes (signatures) de la super-classe vers la sous-classe. L héritage comportemental qui indique le «comportement d une méthode» qui est héritée par ses sous-classes mais qui peut être «surchargée» person[believes_in *->god] Toutes les instances de la classe person vont hériter du comportement de la méthode believes_in -> god, Cependant un «individu» peut avoir un comportement différent individu :: person[believes_in -> nothing] Ici «god» et «nothing» sont des objets particuliers 51 Objets et propriétés Des objets (instances des classes) et leurs propriétés (valeurs des méthodes des classes) peuvent être explicitement décrits. abraham : man sarah : woman isaac : man [father ->abraham, mother -> sarah] Jacob : man [son ->> {reuben, simeon} ] Jacob : man [son@(leah,1)->>reuben, son@(leah,2)->> simeon] Jacob est un objet de type man, Avec un fils «reuben», 1er enfant de la femme «leah» Avec un fils «simeon», 2ème enfant de la femme «leah» 52 Règles Les règles permettent de définir de la connaissance de façon intensionnelle Une règle de la forme : X[son ->>Y] <- Y:man[father -> X] se lit Si Y est un homme (Y:man) dont le père est X (father -> X) alors X a comme fils Y (son ->> Y) La méthode father est mono-valuée mais la méthode son est multivaluée Règles X[ancestors ->>Y] <- X[father ->Y] X[ancestors ->>Y] <- X[mother ->Y] X[ancestors ->>Y] <- X[father ->Z], Z[ancestors ->> Y] X[ancestors ->>Y] <- X[mother ->Z], Z[ancestors ->> Y] Ces règles permettent de calculer l ensemble des ancêtres (Y) d une personne (X). La méthode ancestors est multi-valuée. Les ancêtres sont définis soit comme les ancêtres directs (mother, father) soit de façon récursive;

10 Règles Le corps d un règle peut contenir des négations. X[notrelated ->>Y] <- X:person, Y:person, not X[ancestors ->>Y], not Y[ancestors ->> X]. Le traitement de la négation dans le corps des règles est un problème important. la stratification des règles est une approche possible 55 Expression de chemin Les expressions de chemins permettent d exprimer les informations dans les règles ou dans les requêtes de façon plus concise. Pour désigner, le père du père d isaac, on peut écrire : <- isaac[father ->Y],Y[father ->X] avec Y qui est une valeur «intermédiaire» <- isaac.father[father ->X] avec isaac.father est une expression de chemin qui désigne le père d isaac sans variable intermédiaire 56 Requêtes Les requêtes sont des règles particulières avec une tête de règle «vide» La requête : <- jacob[ancestors->>y:woman] Permet de rechercher tous les ancêtres femme de jacob. 57 Négation et stratification L idée intuitive de la stratification comme mécanisme pour évaluer un «littéral» nié dans le corps d une règle, est de décomposer un programme en «couches» appelées «strates» et d avoir complètement évaluer le littéral (positivement et négativement) avant d évaluer la règle. Par exemple : B(b) C(a) A(X) <= B(X) & not(c(x)) Ce programme peut être stratifié en 2 strates : 1ère strate : {B, C} 2ème strate : {A} L évaluation de la règle nécessite l évaluation préalable de B et C. Ici B(b) et ~B(a), C(a) et ~C(b) La règle est appliquée en utilisant ces connaissances. L ajout d une 3ème règle : E(X) <= not(a(x)) nécessiterait une nouvelle strate de calcule préalable de A ici A(b) et ~A(a), avant de calculer E(X) avec les strates précédentes. 58 Bilan La propose une modélisation qui s appuie sur les modèles orientés objets Signatures des objets, hiérarchies des objets Et sur la logique Spécification de règles Des mécanismes d inférences pour l évaluation des règles Principe de résolution de la logique du 1er ordre La négation dans le corps de règles peut être évaluée en utilisant la stratification des Le système Florid/FloXML FLORID (F-LOgic Reasoning In Databases) Est un système de bases de données orienté objet déductif Qui utilise la comme langage de définition des données et de requêtes Version1.0 en 1996, Version 2.0 en 1998, Version 2.1 et 2.2 en 1999 L intérêt croissant pour les données semi-structurées (XML) a conduit à l extension de Florid pour gérer ces données dans un contexte d intégration Version 3.0 en 2000 FloXML Version programmes