Bases de données déductives

Transcription

1 Bases de données déductives par Mohand-Saïd HACID Maître de conférences en informatique à l université Lyon-I et Jacques KOULOUMDJIAN Docteur ès sciences Professeur d informatique à l INSA de Lyon 1. Bases de données déductives s appuyant sur des SGBD relationnels... H Bases de données déductives et langages du 1 er ordre Langages du 1 er ordre Interprétation d un ensemble de clauses Base de données relationnelle comme modèle d un ensemble de clauses Calcul du 1 er ordre Bases de données déductives utilisant le calcul du 1 er ordre Bases de données déductives et règles de production Stratégies de construction Stratégie par couplage Stratégie par intégration de systèmes Bases de données actives et bases de données déductives orientées objet Bases de données actives Bases de données déductives orientées objet Définition d objets Définition de structures complexes Définition de types Interrogation et manipulation d objets Données virtuelles Conception Exemples de SGBD déductifs SGBD déductifs relationnels SGBD déductifs orientés objet Conclusion Références bibliographiques L es technologies prédominantes pour la majorité des applications actuelles mettant en œuvre des bases de données reposent sur les trois modèles de données suivants : le modèle hiérarchique, le modèle réseaux et le modèle relationnel. Nous les appelons modèles de données traditionnels pour les distinguer de la nouvelle génération des technologies bases de données, comme les modèles sémantiques et les modèles orientés objet. Les modèles traditionnels sont très efficaces et fonctionnent convenablement dans de nombreux domaines d application. Ces applications partagent toutes une caractéristique commune : la structure de données requise pour la représentation des informations est assez simple. Cependant, l efficacité des modèles de données traditionnels ne suffit pas pour des réalisations d applications avancées où la structure des informations ne partage pas cette simplicité, et où les besoins en maintien de la cohérence, de la dérivation de données et du contrôle d accès sont importants. Un exemple où le support de structures de données complexes est nécessaire est l utilisation de bases de données pour la conception et la fabrication assistée par ordinateur. Techniques de l Ingénieur, traité Informatique H

2 BASES DE DONNÉES DÉDUCTIVES Un SGBD déductif est un système qui comporte des possibilités pour définir des règles qui peuvent déduire ou inférer des informations à partir de faits stockés dans une base de données. Dans un système de gestion de bases de données déductif, un langage déclaratif est utilisé pour spécifier des règles. Un mécanisme d inférence (ou mécanisme de déduction) peut alors déduire de nouveaux faits à partir de la base de données en interprétant les règles. Le modèle utilisé pour les bases de données déductives s apparente au modèle de données relationnel et plus particulièrement au formalisme du calcul relationnel. Un sous-ensemble de Prolog appelé Datalog est utilisé pour définir de façon déclarative des règles. Un exemple d application intéressante pour les bases de données déductives est celui où les données peuvent être interprétées sous des visions différentes. Les relations de parenté entre individus (frère, sœur, grand-parent, cousin, ancêtre, etc.) en sont une bonne illustration ; elles sont décrites à partir de la seule définition des liens parents-enfants. Les domaines dans lesquels plusieurs solutions sont possibles pour une requête et où l on souhaite décrire des algorithmes ou des heuristiques de choix de solutions optimales sont également un champ d application important (tous les problèmes de graphes dans lesquels on veut décrire des chemins optimaux par exemple). Comme toute technologie, les bases de données déductives trouvent un intérêt particulier dans certains domaines d application. Ces domaines sont ceux qui nécessitent l emploi de données factuelles et de règles de comportement et de déduction. Nous pouvons citer, par exemple, la découverte de connaissances (data mining), la régulation de transport, l ingénierie concurrente, la biologie, etc. Pour de telles applications, les SGBD déductifs proposent des langages spécifiques permettant de décrire et de manipuler des vues sur les données à côté des langages de description usuels des données de base. Plusieurs domaines d application privilégient l utilisation des bases de données déductives. Nous citerons ici trois domaines d application. Découverte de connaissances La découverte de connaissances consiste à expliciter une partie de la connaissance qui n est présente que de façon implicite dans une base de données. Ce domaine est d autant plus important que les sources d information sont diverses. L exemple d application relevant de ce domaine est celui de l école publique aux États-Unis d Amérique. L idée de réaliser une gestion de plus en plus locale de ces écoles a fait ressortir le besoin de nouvelles considérations. Les officiels de ces écoles sont amenés à accéder à divers types de données socio-économiques des écoles voisines. D un point de vue bases de données, le problème (posé) est de savoir comment intégrer une collection de bases de données et les utiliser de façon radicalement différente de leur utilisation initiale. Applications de régulation L application citée est celle du transport et du stockage de matières dangereuses. Cette activité est en général régie par des règles standard qui peuvent être internationales, nationales ou locales. Ces matières étant sujettes à des déplacements répétés, les règles à respecter sont diverses. De plus, ces règles sont régulièrement mises à jour et donc difficiles à comprendre pour un individu. L utilisation d une base de données équipée d un composant contraintes d intégrité constitue une solution à ce problème. Les contraintes d intégrité sont alors utilisées pour valider ou interdire une situation donnée. Ingénierie concurrente En ingénierie concurrente, la conception est une activité partagée par plusieurs participants. Chaque participant réalise des décisions de conception indépendamment des autres. Les conceptions issues des différentes disciplines sont ensuite intégrées de façon à produire une conception globale d un projet. Dans une telle situation, les différents participants utilisant des données partagées, il peut arriver que les interactions entre les concepteurs de différentes disciplines génèrent des inconsistances. L objectif est de détecter de telles inconsistances le plus tôt possible de façon à ne pas fausser les décisions futures. La solution consiste à fournir une base de données partagée relative à plusieurs disciplines. H Techniques de l Ingénieur, traité Informatique

3 BASES DE DONNÉES DÉDUCTIVES La présentation des concepts des bases de données déductives faite ici comprend une première partie consacrée aux bases de données déductives relationnelles. La deuxième partie donne un aperçu sur les bases de données actives puis développe un cadre pour les bases de données orientées objet déductives. 1. Bases de données déductives s appuyant sur des SGBD relationnels Les SGBD relationnels [1] ont servi de support aux premières bases de données déductives [3]. Deux familles de systèmes ont été développées : les BD déductives s appuyant sur le cadre formel des langages du 1 er ordre et celles qui utilisent le formalisme général des règles de production. 1.1 Bases de données déductives et langages du 1 er ordre Langages du 1 er ordre Comme tous les langages formels, les langages du 1 er ordre reposent sur des règles de construction syntaxique de formules bien formées du langage auxquelles on associe une interprétation. Les règles de construction syntaxiques s appuient sur : un alphabet composé de : constantes : a, b, c... ; variables : X, Y, Z... ; symboles de prédicat : P, Q, R... ; fonctions : f, g, h... ; les parenthèses ; les connecteurs logiques usuels : négation ( ), conjonction ( ), disjonction ( ), proposition conditionnelle ( ), équivalence ( ) ; les quantificateurs universel ( ) et existentiel ( ) ; des règles de construction de formules du langage composé de : termes : une constante ou une variable constitue un terme. Si t 1, t 2,..., t n sont des termes f (t 1, t 2,..., t n ) est un terme, formules atomiques : si t 1, t 2,... t n sont des termes et P est un symbole de prédicat n-aire, alors P (t 1, t 2,... t n ) est une formule atomique ; des formules bien formées (fbf) : toute formule atomique est une fbf, si w 1 et w 2 sont des fbf, alors : w 1 w 1 w 2 w 1 w 2 w 1 w 2 w 1 w 2 x w 1 (x) x w 1 (x) sont des fbf. X (Facture (X)) Z (Commande (Z, X)) est une fbf construite sur les symboles de prédicat Facture et Commande. Il s agit d une construction syntaxique qui peut s interpréter : «À toute facture X correspond une commande Z». Les fbf peuvent subir une suite de transformations pour aboutir à des représentations équivalentes dont la manipulation est plus facile (en particulier la forme clausale qui est celle utilisée dans les langages de type Prolog) : la forme normale Prenex correspond à un regroupement de tous les quantificateurs en tête de la formule : X Z (Facture (X) Commande (Z, X)) la skolémisation permet de remplacer toutes les variables quantifiées existentiellement par une fonction f des variables quantifiées universellement qui les précèdent ; f est un symbole de Skolem d arité k qui n apparaît pas dans la formule initiale : X (Facture (X) Commande (f(x), X)) Il n est donc plus nécessaire de faire figurer le quantificateur existentiel. Implicitement toutes les variables sont quantifiées universellement. Remarque : la formule précédente peut aussi s écrire : X( Facture (X) Commande (f (X), X)) la forme clausale consiste à exprimer toute fbf sous forme d une disjonction de formules atomiques positives ou négatives skolé misées : A 1 A 2... A m B 1 B 2... B n qui peut aussi s écrire : A 1 A 2... A m B 1 B 2... B n Une telle expression constitue une clause. Parent (X, Y) Mère (X, Y) Père (X, Y) On se limite la plupart du temps à l expression de clauses ne contenant qu un littéral positif en partie de droite (n = 1) : ce sont les clauses de Horn pour lesquelles il existe des mécanismes de preuves formelles. Le langage Prolog repose sur les clauses de Horn. On peut considérer qu un programme Prolog est analogue à un ensemble de clauses de Horn définies. Dans la suite, nous nous intéresserons donc à des ensembles de clauses de Horn. Père (X, Y) Parent (X, Y) Mère (X, Y) Parent (X, Y) Mère (X, Y) Parent (X, Z) Gmère (X,Z) Père (X, Y) Parent (Y, Z) Gpère (X, Z) Gmère (X, Y) Gparent (X, Y) Gpère (X, Y) Gparent (X, Y) Techniques de l Ingénieur, traité Informatique H

4 BASES DE DONNÉES DÉDUCTIVES Interprétation d un ensemble de clauses Les clauses n étant qu une construction syntaxique, nous donnons une signification à un ensemble de clauses en mettant en correspondance les éléments de ces clauses avec des éléments du monde réel appelé domaine d interprétation : cette mise en correspondance s appelle une interprétation. On choisit parmi toutes les interprétations celles qui rendent vraies toutes les clauses ; les éléments du monde réel satisfaisant ces clauses constituent un modèle pour ces clauses. Interprétation Soit un ensemble de clauses. On se donne un domaine d interprétation E non vide à partir duquel on va instancier les constantes et les variables des clauses. À chaque symbole Q de prédicat n-aire, on fait correspondre un nom de relation R de E n. soit l ensemble des clauses : 1. P(X) Q(Y) R (X, Y) 2. P (a) 3. Q (c) 4. R (a, b) 5. R (b, c) Remarquons que les clauses 2 à 5 n ont pas de partie gauche, elles constituent ce qu on appelle des faits. Soit le domaine d interprétation constitué : des individus {jean, pierre, loto, tiercé} ; des relations : a-gagné (jean), a-gagné (pierre), jeu (loto), jeu (tiercé), a-joué (jean, loto), a-joué (jean, tiercé), a-joué (pierre, loto). La mise en correspondance suivante constitue une interprétation de l ensemble des clauses : jean a a-gagné P pierre b jeu Q loto c a-joué R Valeur de vérité d une interprétation : S (e 1, e 2..., e p ) sera vrai si (e 1, e 2...e p ) R où R est l image de S. S (x) est vrai si, pour tous les éléments de E, R (x) est vrai où R est l image de S. S T est faux si T est faux et S est vrai, sinon il est évalué à vrai. ( désigne le symbole d implication). Un modèle d un ensemble de clauses est tout ensemble de formules atomiques constituant une interprétation qui rend vraies toutes les clauses. dans l exemple précédent, l instanciation proposée conduit aux formules atomiques : a-gagné (jean) ; jeu (loto) ; a-joué (jean, loto) ; a-joué (pierre, loto). Ces formules constituent un modèle car elles rendent vraies à l évidence les clauses 2 à 5. Quant à la clause 1, elle est également vraie quelles que soient les instanciations de X et Y par les constantes jean, pierre et loto. On peut vérifier que l interprétation suivante : pierre a a-gagné P jean b jeu Q tiercé c a-joué R ne conduit pas à un modèle Base de données relationnelle comme modèle d un ensemble de clauses considérons la base de données suivante : père grand-père nomp nomf nomgp nompf a b a d a c a c b d c c et l ensemble de clauses : père (X, Y) père (Y, Z) grandpère (X, Z) père (a, b) père (a, c) père (b, d) père (c, e) grandpère (a, d) grandpère (a, e) Les faits de la base de données constituent un modèle pour l ensemble des clauses. Celles-ci sont toutes vérifiées dans l interprétation qui consiste à mettre en correspondance les éléments qui ont le même nom. Cette démarche n est cependant pas très productive car la première clause n est pas utilisée comme règle de déduction et la base de données correspond à tout ce qu on peut déduire de l ensemble des clauses. Pour avoir une approche déductive, il faut définir des règles d inférence permettant d affirmer qu une clause w est une conséquence logique d un ensemble d autres clauses W. C est-à-dire que tout modèle de W satisfait w. On n a pas alors à exprimer les faits associés à w Calcul du 1 er ordre On peut définir un calcul du 1 er ordre sur un ensemble de fbf en utilisant des règles d inférences, par exemple le Modus ponens : Si P est vrai et si P Q est vrai ALORS Q est vrai et la particularisation : Si X P(X) est vrai ALORS P (a) est vrai Une formule w est dérivable d un ensemble W de fbf si elle peut être déduite de W par application finie des règles d inférences. Le calcul du 1 er ordre repose sur le principe de résolution de Robinson qui permet de dériver une nouvelle clause à partir de deux clauses données. Ainsi, de P Q et Q R, on peut dériver P R. Un ensemble de fbf muni de règles d inférences constitue une théorie du 1 er ordre Bases de données déductives utilisant le calcul du 1 er ordre C est une base de données dans laquelle une partie des faits est dérivée de faits physiquement (stockés) dans la base. Elle est donc constituée de deux parties : des données gérées par un SGBD relationnel représentant les faits de base d une BD logique ; une théorie du 1 er ordre (des clauses de Horn sans fonction) permettant de déduire de nouveaux faits. H Techniques de l Ingénieur, traité Informatique

5 BASES DE DONNÉES DÉDUCTIVES Les clauses dans la théorie peuvent être partiellement instanciées. Des clauses sans conclusion sont interprétées comme des contraintes d intégrité (exprimées sous forme négative puisque P Q peut s écrire P Q). soient les relations Père (nomp, nome) et Mère (nomm, nome) et l ensemble de clauses : 1. Père (X, Y) Parent (X, Y) 2. Mère (X, Y) Parent (X, Y) 3. Mère (X, Y) Parent (Y, Z) Gmère (X, Z) 4. Père (X, Y) Parent (Y, Z) Gpère (X, Z) 5. Parent (X, Y) Ancêtre (X, Y) 6. Parent (X, Y) Ancêtre (Y, Z) Ancêtre (X, Z) Ancêtre est un prédicat récursif alors que les autres prédicats sont (des prédicats) hiérarchiques. Ces prédicats permettent de calculer les extensions correspondantes à partir des relations Père (nomp, nome) et Mère (nomm, nome) Ces extensions sont calculées par un moteur d inférences utilisant le formalisme clausal, les règles de déduction et la base de données. D une façon pratique, il s agit le plus souvent d un démonstrateur PROLOG connecté à un SGBD dont il exploite les données. si on demande les grand-mères de jean (?Gmère (X, jean)), le système utilise la clause 3 contenant la définition du prédicat Gmère. En propageant la constante jean dans la clause, il remplace le but à résoudre par le nouveau sous-but Mère (X, Y) Parent (Y, jean). L utilisation des clauses 1 et 2 l amène à résoudre deux nouveaux sous-buts : Mère (X, Y) Père (X, jean) Mère (X, Y) Mère (Y, jean) dont la résolution va faire appel à la base de données. Le système construit donc un arbre de résolution qui a comme racine le but initial à démontrer et comme branches les sous-buts successifs obtenus par remplacement d un but par des sous-buts associés dans une clause. Les feuilles sont les faits (prédicats) de base. On dit que la résolution se fait par chaînage arrière. 1.2 Bases de données déductives et règles de production Une règle de production est de la forme : Si conditions ALORS actions où les actions représentent un ensemble d opérations à effectuer (opérations arithmétiques, entrées-sorties, génération d un nouveau fait...). Ces opérations seront effectuées si l ensemble des conditions est satisfait. les règles précédentes pourraient s exprimer sous la forme : Si X = Père (Y) et Y = Père (Z) ALORS créer X = Gpère (Z) Si X = Père (Y) ALORS créer X = Ancêtre (Y) Si X = Père (Y) et Y = Ancêtre (Z) ALORS créer X = Ancêtre (Z) 1.3 Stratégies de construction Les bases de données déductives relationnelles (BDDR) sont les bases de données construites sur l idée que le modèle de données sous-jacent est le modèle relationnel. La transition d une base de données relationnelle classique vers une BDDR est relativement simple et naturelle car le modèle relationnel repose sur des expressions simples, bien formalisées en logique des prédicats du premier ordre. La stratégie adoptée dans le développement d une BDDR est caractérisée par la conception d une base de données relationnelle comme un outil de stockage de faits dans un environnement de démonstrateur de théorèmes. Deux principales stratégies ont été utilisées pour construire des BDDR : la stratégie par couplage et la stratégie par intégration de systèmes Stratégie par couplage Elle consiste à équiper un langage logique, généralement PROLOG, de fonctionnalités de gestion de faits en mémoire secondaire de façon la plus transparente possible. Ainsi, à chaque fois que le système déductif a besoin de faits en mémoire centrale pour poursuivre ses déductions, le SGBD est activé pour l alimenter. La stratégie par couplage peut être affinée pour distinguer deux types de couplage : le couplage lâche (faible) et le couplage serré (fort). Dans une approche couplage lâche, le système déductif accède à la base de données en générant des appels via le langage de requêtes du SGBD. Cette tâche est celle du programmeur. À la suite d un appel du système déductif au SGBD, celui-ci retrouve tous les n-uplets satisfaisant la requête SELECT et les dépose dans la mémoire de travail du système déductif, et ce dernier peut alors continuer ses inférences. Dans une approche couplage fort, le système déductif accède à la base de données en générant des appels directement aux méthodes d accès du SGBD. Dès que le SGBD a retrouvé un n-uplet satisfaisant les conditions de sélection, il le charge dans la mémoire de travail du système déductif. Le système déductif continue ses inférences et le SGBD continue de façon asynchrone à générer des n-uplets satisfaisant la requête SQL, préparant ainsi des réponses à d éventuels appels à la même requête SELECT Stratégie par intégration de systèmes Cette approche consiste à intégrer en un seul système les fonctions de gestion de données permanentes (fonctions propres à un SGBD) et les fonctions de déduction (fonctions du moteur d inférences). L attention est souvent portée sur trois langages : un langage de programmation logique utilisé dans le système déductif, un langage de définition de données et un langage de manipulation de données. L intérêt d une telle approche est de disposer d un seul langage déclaratif pour les requêtes, les règles de déduction et les contraintes d intégrité. Cette stratégie a été rarement utilisée dans la pratique car elle nécessite la réécriture de systèmes complets. Le moteur d inférences va alors exploiter les règles en cherchant celles dont les prémisses sont satisfaites à une étape donnée. Celles-ci peuvent générer de nouveaux faits qui peuvent entraîner le déclenchement de nouvelles règles. Le mécanisme de déduction se fait donc par chaînage avant principalement. Ce type de fonctionnement est bien adapté à des problèmes dans lesquels on veut connaître les conséquences d un ensemble d hypothèses, comme par exemple les problèmes de diagnostic. La base de données contient l ensemble des données décrivant les hypothèses. Techniques de l Ingénieur, traité Informatique H

6 BASES DE DONNÉES DÉDUCTIVES 2. Bases de données actives et bases de données déductives orientées objet 2.1 Bases de données actives Les systèmes de gestion de bases de données permettent le stockage de gros volumes de données et fournissent des langages puissants d interrogation et de manipulation des données qu ils stockent. Toutefois, ces systèmes restent passifs car tout traitement sur la base de données se fait sur demande explicite (requête ou commande) d un utilisateur ou d un programme d application. Une autre approche consiste à réaliser des SGBD capables de réagir face à certains événements. Par exemple, lorsque la quantité en stock d un produit devient inférieure à un certain seuil, une demande d approvisionnement est déclenchée automatiquement. Les approches classiques utilisées consistent soit à scruter périodiquement la BD, soit à surcharger les applications par un code de contrôle. La première approche est difficile à implanter car elle nécessite le choix d une périodicité de contrôle qui risque d altérer les performances du système. La deuxième approche pose un problème de redondance de code dans les différents programmes d application, ce qui induit une difficulté supplémentaire pour la maintenance des applications. Une solution adéquate consiste à rendre un SGBD actif : il exécute de manière automatique certaines actions lorsque certains événements se produisent et que certaines conditions sont satisfaites. Les travaux dans le domaine des BD actives consistent à définir les composantes suivantes : un langage de description de règles actives, un modèle de représentation et d exécution de ces règles et une architecture définissant les techniques d implantation. Les langages de description de règles actives utilisent, en général, le format suivant : «On Event If Condition Do Action». Cette règle, exprimée en POSTGRES [7], est déclenchée par une insertion dans la table Employé. La partie action initialise les salaires des nouveaux employés à un salaire moyen diminué de 50. Supposons qu un n-uplet (nouvel employé) soit inséré. Dans les systèmes orientés instance tels que POSTGRES, cette règle est déclenchée lors de chaque insertion d employé et donc le salaire de chaque nouvel employé est différent de ceux des autres employés. Dans les systèmes orientés ensemble tels que STARBURST [9], la règle est déclenchée une seule fois pour tous les employés insérés dans la base au cours de la transaction. Les employés auront tous le même salaire. Le modèle de représentation étudie la façon d intégrer les règles actives dans une BD en tenant compte de son modèle de données. Le modèle d exécution détermine la politique d exécution des règles en tenant compte des transactions. Deux types d architecture sont envisageables pour implanter un mécanisme de règles actives : une architecture en couches, utilisée lorsque le SGBD cible est fermé (aucun changement n est introduit dans le noyau du système) et une architecture par intégration, utilisée lorsque le SGBD cible est ouvert. 2.2 Bases de données déductives orientées objet Dans une base de données déductive, un utilisateur peut spécifier ses connaissances sur les faits de la base de données en termes de contraintes d intégrité et de règles de déduction. Dans une base de données objet, un utilisateur peut décrire les données d une application en termes d objets (organisés en classes). De nouveaux faits peuvent être dérivés à partir de faits existants, grâce aux opérations pouvant s appliquer à ces faits et aux préconditions nécessaires à l application de ces opérations. En général, une base objet déductive (BDDO) peut être vue comme un système à deux niveaux. Le premier niveau (niveau base de données) contient un ensemble d objets et le deuxième niveau (le niveau base de connaissances) contient un ensemble de règles qui décrivent les connaissances de l utilisateur sur les objets. Formellement, une base objet déductive peut être définie comme un triplet (BO, R, CI) avec BO une base objet extensionnelle, R des règles de déduction et CI des contraintes d intégrité. Nous supposons la base consistante. Dans cette partie, nous identifions les techniques de structuration de données adaptées pour modéliser des éléments complexes. L objectif est d illustrer par des exemples la combinaison des caractéristiques issues du paradigme de la programmation orientée objet et des langages de programmation logique dans des modèles de données. Étant donné l existence de plusieurs langages de description et de manipulation d objets complexes, nous utiliserons un langage simple avec lequel il est possible de modéliser la majorité des propriétés inhérentes à l objet. Nous ne considérons que la partie structurelle des objets Définition d objets considérons la règle suivante : Il existe deux classes génériques d objets, les objets simples et define rule salaire-par-défaut les objets complexes. Les objets simples sont atomiques, c est-à-dire qu ils ne peuvent pas être décomposés. Ils n ont pas de structure on insert to Employe interne et ne peuvent pas subir de changement d état. Cependant, then begin lorsqu ils apparaissent comme des parties d objets complexes, ils salaire_défaut = (select avg(salaire) from Employé) 50 ; peuvent être remplacés par d autres objets simples de type similaire. update Employé.salaire = salaire_défaut Ce remplacement est vu comme le résultat d une opération de mise à jour sur des objets complexes. where Employé.num_emp = new.num_emp ; end. String, Integer, Real sont des exemples de types d objets simples. Malene, 1994, 12.5 sont des exemples d objets simples. Les objets complexes ont, quant à eux, une identité unique. Ils possèdent une structure et sont classés en différents types. Un objet complexe est une entité composite caractérisée par un ou plusieurs champs. Les valeurs des champs de l objet sont elles-mêmes des objets, simples ou complexes. un objet point possède des coordonnées x et y, qui sont des objets de type Integer : Point:P1(x 2, y 2) Point:P2(x 4, y 4) P1 et P2 représentent les identificateurs uniques qui sont assignés aux deux objets de type Point. Les valeurs des identificateurs sont générées par le système et ne sont pas visibles de l utilisateur ; un objet SegmentOrienté admet un point origine et un point extrémité, qui sont des objets de type Point : SegmentOrienté:S(PointOrigine Point:P1, PointExtrémité Point:P2) H Techniques de l Ingénieur, traité Informatique

7 BASES DE DONNÉES DÉDUCTIVES Les objets complexes ne sont pas forcément des arbres structurés, comme dans ce dernier exemple. Puisque les objets ont des identificateurs uniques, le partage de structures est facilement supporté. Quand deux segments orientés ont le même point origine, un angle est formé : Angle:A(ArcInitial SegmentOrienté:S, ArcFinal SegmentOrienté:S2(PointOrigine Point:P1, PointExtrémité Point:P3(x 2, y 4))). Les deux segments S et S2 qui forment l angle A ont le même point origine P1(x 2, y 2) Définition de structures complexes Des notations existent en mathématiques pour décrire des structures complexes. Comme exemples, nous trouvons : la notation ensembliste SET, qui est un support de base pour l étude abstraite de graphes. Par exemple, la paire S = ({a, b, c, d}, {(a,b), (a,c), (b,c), (b,d), (d,a)}) décrit le graphe de la figure 1 ; les termes clos TERM : la notation TERM est équivalente aux arbres orientés avec racine. Par exemple, le terme clos a(b,c(d,e)) représente l arbre de la figure 2 ; les termes avec variables TERM/VAR : c est une extension immédiate de TERM. Bien que les variables n aient pas de sens quand elles sont considérées seules, elles donnent lieu à une classe de formules, qui sont des formules quantifiées ayant une interprétation. Pour déterminer la valeur de vérité d une formule, les variables sont substituées par des constantes. le terme a(x, c(d, X)) décrit le graphe de la figure 3. Figure 1 Graphe d une notation SET Le langage TERM/VAR peut être étendu pour autoriser la notion de partage de structure plus générale. L idée de base pour un partage plus généralisé est une substitution plus consistante des variables objets. Les variables objets sont associées aux identificateurs d objets. Si une variable objet admet plusieurs occurrences, celles-ci vont désigner un unique identificateur d objet, référençant ainsi une même structure complexe. Traditionnellement, les variables sont des emplacements dans les systèmes logiques. Elles sont utilisées pour former des abstractions avec une quantification. Généralement, un terme avec des variables non liées est difficile à interpréter et la plupart des systèmes logiques n assignent pas de sens à de tels termes. Le langage étendu avec des variables co-références arbitraires conduit toujours à des termes clos. Donc, en plus des variables co-références, on ajoute une autre classe de variables dont les occurrences libres permettent une interprétation sensée. Cette classe de variables désigne des objets «étiquettes» qui sont interprétés par des objets abstraits. Dans un terme, ces objets étiquettes ne sont pas manipulés lors de l interprétation comme des substitutions de variables. Une fonction d interprétation associe des objets abstraits à des objets étiquettes. dans la description : Employé:E(nom NomPersonne:N(nom_famille F, Prénom P)) les variables F et P sont libres, E et N sont liées ; le terme : NomPersonne:(nom_famille wadich, prénom marie ) dénote un objet complexe représentant un nom d individu ; et le terme : Personne:V(nom NomPersonne:(nom_famille wadich,prénom marie ), adr Adresse:(N o Rue 1,Nom_Rue prem. rue )) dénote un objet complexe correspondant à une personne. Cet objet comprend un sous-objet NomPersonne et un sous-objet Adresse ; le terme : Personne:P?(nom NomPersonne:N?(prénom marie )) dénote un objet abstrait, qui contient un objet abstrait NomPersonne. L objet abstrait NomPersonne coïncide avec des objets concrets NomPersonne dont le champ prénom admet un objet simple «marie» comme valeur. L objet abstrait Personne correspond à des objets concrets Personne dont le prénom est «marie». Sémantique Les termes objets sont des spécifications (et aussi des constructeurs) pour les bases de données objet. Techniquement, ce sont des formules interprétées par des objets. Les objets fournissent un sens aux termes. Établir une correspondance (interprétation) entre formules et objets revient à définir la sémantique d un langage. Dans notre cas, chaque terme simple est interprété par une et une seule valeur atomique, alors qu un terme complexe peut être associé à n importe quel objet parmi un nombre infini d objets complexes. Figure 2 Graphe d une notation TERM Figure 3 Graphe d une notation TERM/VAR Techniques de l Ingénieur, traité Informatique H

8 BASES DE DONNÉES DÉDUCTIVES Définition de types Les types définissent et renforcent la structure des objets ; les champs et les valeurs de ces champs sont conditionnés en grande partie par le type de l objet. Un objet peut être de plusieurs types. Dans ce cas, l objet est contraint de satisfaire les conditions de structures issues de ses types. Les types jouent également un rôle important en modélisation conceptuelle ; ils correspondent à des concepts prototypes et peuvent être utilisés pour un besoin de classification. Les types ont des noms uniques. Le nom est introduit en utilisant l une des trois formes suivantes : T1 = T2, où T1 et T2 sont des noms de types ; T1 < T2 (T1 est un sous-type de T2) ; T = t, où T un nom de type et t une spécification de type. Rectangle = (Longueur Integer, Largeur Integer). La spécification : Étudiant < Personne introduit un nouveau type de nom Étudiant et le relie au type Personne en utilisant la relation d ordre <. Sémantique La sémantique du langage de définition de types peut être donnée selon deux perspectives : comment une définition de type relie-t-elle le type à ses instances, et comment une définition de type relie-t-elle le type à d autres types? Ensembles de valeurs admissibles : chaque spécification de valeur définit un intervalle de valeurs pour un champ d un objet complexe. Ces valeurs forment l ensemble des valeurs admissibles pour le champ. Conformité d un objet : la notion de conformité des objets à un type est définie de façon ascendante. Tout champ f dans un type T définit une condition nécessaire pour qu un objet soit conforme à T. Spécialisation de types : supposons que S contienne un champ f v1 et que T contienne un champ f v2. Nous dirons que S spécialise T sur f, si v [v1] v [v2]. L ensemble des valeurs admissibles pour v1 est inclus dans l ensemble des valeurs admissibles pour v2. la spécification : TroisPoints = (x Integer, y Integer, z Integer) spécialise la spécification : DeuxPoints = (x Integer, y Integer) Notons que tout S défini en utilisant l une des deux formes de sous-typage suivantes est toujours une spécialisation de T. S < T S = T:spectype TroisPoints = DeuxPoints:(z Integer) Interrogation et manipulation d objets L interrogation et la manipulation des objets d une base de données sont réalisées dans un langage de commandes. La syntaxe abstraite d une commande est : Action[x1,...,xn] Expression[y1,...,ym] Les xi et yi sont des variables distinctes. View[C] rects Rectangle:R(origine Point:P(x 2,y 3), extrémité Point:C) Cette commande visualise les angles des rectangles dont l origine est située au point (2,3). Dans cet exemple, rects est une collection d objets rectangles : C, P et R sont des commandes ou des variables. View est une opération prédéfinie qui visualise des objets complexes dans une syntaxe composite. Pour exécuter la commande, le processeur cherche des objets Rectangle ayant la description donnée (à savoir, ceux situés au point (2,3)) dans la collection rects. Pour tout objet satisfaisant la description, le processeur relie son identificateur à la variable R, son point origine à P et son point extrémité à C. L opération View visualise les objets points extrémités. Supposons qu il existe les deux objets rectangles suivants dans la collection : Rectangle:r1(origine Point:p1(x 2,y 3), extrémité Point:q1(x 5,y 10)) Rectangle:r2(origine Point:p2(x 2,y 3), extrémité Point:q2(x 6,y 15)) Le résultat de l opération View est : Point:q1(x 5,y 10) Point:q2(x 6,y 15) Les expressions et les variables dans les expressions jouent des rôles importants dans les commandes. Les termes objets et les expressions sont similaires dans leur syntaxe. Dans une approche conventionnelle, ils doivent différer dans leur sémantique : les premiers dénotent les objets d une base de données, les seconds dénotent des opérations sur les objets d une base de données. Les actions : les en-têtes de commandes dénotent des opérations impératives sur les objets de la base de données obtenus à travers l opération de pattern-matching. L opération de pattern-matching peut être vue comme une généralisation de l opération case des langages impératifs, comme Pascal. Elle permet de filtrer, parmi un ensemble d objets, un sous-ensemble satisfaisant certaines conditions. La partie action d une commande peut être composée de plusieurs en-têtes. Dans ce cas, les opérations dénotées par les en-têtes sont appliquées aux objets dans un ordre séquentiel. Les opérations de base telles que l ajout d un type et l ajout d un champ sont toutes décrites en utilisant des termes objets Données virtuelles Une base de données contient à la fois des informations explicites et des informations implicites (déduites), non directement représentées par des données physiques mais déductibles à partir des informations connues en utilisant des règles d inférence. Les données virtuelles sont importantes car elles offrent une autre alternative de considération d un même ensemble de données physiques. Comme les commandes, les règles d inférence pour les données virtuelles ont un en-tête et un corps. Leur syntaxe générale est : <Type Virtuel> <Champ Virtuel> <Objet Virtuel> <Expression> Une règle est une commande différée, exécutée à la demande et déclenchée par l exécution d autres commandes. L effet des règles n est visible que durant l exécution de commandes ; il n est pas matérialisé. H Techniques de l Ingénieur, traité Informatique

9 BASES DE DONNÉES DÉDUCTIVES Règles types Pour définir un type virtuel d un objet, la règle suivante est utilisée : T:V <Expression> avec T nom de type, V variable qui sera liée à un objet de la base de données durant l opération de pattern-matching. EmployéResponsable:E Employé:E(fonction Responsable ). Cette règle définit un type virtuel EmployéResponsable pour les objets de type Employé dont l attribut fonction est valorisé à Responsable. Règles champs Une règle champ est décrite par : V(f1 w1,...,fn wn) <Expression> où wi (i = 1,..., n) est une variable ou une constante. Les variables sont supposées être liées par pattern-matching. Pour chaque objet lié à V, la règle définit n champs virtuels, de noms f1,...,fn, et de valeurs w1,...,wn respectivement. P(GrandPère G) Personne:P(Père Personne:F (Père Personne:G)). Cette règle définit un champ virtuel GrandPère pour tout objet de type personne. Règles objets Les objets virtuels sont définis en utilisant des règles de la forme : T:*(f1 w1,...,fn wn) <Expression> l astérisque (*) assigne un identificateur d objet temporaire à chaque objet virtuel. la règle suivante définit des objets virtuels représentant des couples : Couple:*(mari:M, femme:f) Personne:M(femme Personne:F) 2.3 Conception Contrairement aux BDDR, la seule approche permettant la conception d une base de données déductive orientée objet est l approche par intégration. Le problème est dû au fait qu il n existe pas de modèle de données orienté objet formel simple et intuitif comme c est le cas pour le relationnel. Trois approches ont été utilisées pour définir un langage pour les bases de données déductives orientées objet : Datalog-OO, Prolog-OO et Logique-OO. Nous discuterons dans ce qui suit de la première approche. L approche Datalog-OO concerne les extensions de Datalog à la prise en compte de certaines caractéristiques du modèle objet. La famille de ces langages comporte COL (Complex Object Language), IQL (Identity Query Language), etc. Cette famille de langages est caractérisée par une adaptation de Datalog comme une plate-forme à partir de laquelle on peut construire un langage de bases de données déductives orientées objet. Les notions d identité d objet, de classes et de types sont représentées. Les classes sont des noms utilisés pour des ensembles d identificateurs d objets dont la structure est définie par un type donné. Deux constructeurs sont utilisés pour les ensembles et les tuples. Contrairement à l approche logique-oo, ce type de langage fait une distinction entre les niveaux schéma et instances. Un schéma est déclaré en utilisant un langage de types. Les méthodes sont utilisées comme fonctions obéissant à des contraintes de typage. Le langage à base de règles utilise des constantes, des tuples et des ensembles comme termes. Les noms de classes, les noms de relations et les méthodes avec arguments proprement typés sont également des termes. Des opérateurs de projection, d accès à la valeur d attribut et de construction de listes sont définis. Les littéraux sont des expressions construites à partir de termes proprement typés en utilisant les prédicats d égalité et d appartenance ensembliste. 3. Exemples de SGBD déductifs Parmi les SGBD déductifs opérationnels, nous pouvons citer : SGBD déductifs relationnels (par couplage) : BIM- Prolog/Oracle, BIM-Prolog/Ingres, BIM-Prolog/UNIFY, Delphia-Prolog/Oracle ; SGBD objet déductifs : Validity (Bull, France), ConceptBase (Université d Aachen, Allemagne), ROLL (Université Heriot-Watt, Écosse), XSB (Université de Stony Brook, États-Unis), CORAL (Université du Wisconsin, États-Unis). 3.1 SGBD déductifs relationnels De très nombreux logiciels permettant d avoir des fonctionnalités de systèmes déductifs existent. La plupart du temps, il s agit de systèmes proposant un langage de règles dont la manipulation est assurée par un moteur d inférence. Une passerelle entre ces logiciels et des SGBD permet d obtenir des fonctionnalités de SGBD déductifs. La facilité d accès aux données et de leur manipulation dépend beaucoup de la qualité de cette passerelle. Elle peut nécessiter une écriture explicite des requêtes SQL par l utilisateur pour l accès aux données par le moteur d inférence ou, au contraire, être totalement transparente à l utilisateur. Les requêtes au SGBD sont dans ce cas générées dynamiquement par le système déductif au fur et à mesure de ses besoins. L exemple présenté ici est la passerelle STORIA [8] associée au langage PROLOG proposé par la société DELPHIA. Son intérêt réside dans la possibilité de la mettre en œuvre suivant trois modes différents : un premier mode dans lequel des requêtes SQL statiques, sous forme de chaînes de caractères, sont écrites dans le programme PROLOG comme paramètres de prédicats prédéfinis. Deux prédicats sont disponibles : «query/2» qui est à utiliser pour les SELECT (il s agit d un prédicat binaire dont le premier paramètre est le SELECT SQL et le second le résultat de la requête exécutée par le SGBD) et «statement/1», prédicat unaire pour toutes les requêtes SQL de mise à jour qui ne retournent pas de résultat. Le second mode de communication PROLOG-SGBD est un paraphrasage de SQL qui permet l utilisation de variables. Ces variables sont dynamiquement instanciées au moment de l exécution du prédicat, ce qui permet une bonne intégration de SQL à PROLOG. Le troisième mode de communication réalise un accès totalement transparent à la base de données. Les n-uplets stockés dans la base sont vus par PROLOG comme des faits de sa propre base. Pour ce faire, la passerelle se construit une image des schémas de relations par consultation du dictionnaire de données du SGBD. Techniques de l Ingénieur, traité Informatique H

10 BASES DE DONNÉES DÉDUCTIVES Ces trois modes peuvent être utilisés de manière indépendante ou simultanée. Exemple d application de STORIA : il s agit d une application de contrôle et de maintenance en temps réel de centrales hydrauliques développée à l aide de DELPHIA-PROLOG et STORIA. Les données de fonctionnement des centrales sont captées, transmises au site de contrôle et rangées dans une base ORACLE. Un système expert analyse en permanence l évolution des paramètres et décide des modifications à effectuer sur les réglages des différentes centrales. Les ordres correspondants sont formulés puis envoyés aux centrales par télématique. Ce système permet donc l exploitation optimale des centrales difficiles d accès. 3.2 SGBD déductifs orientés objet ConceptBase [5] est un système de gestion de bases de données orientées objet déductif, parmi d autres. Il utilise un langage de description limité. Les classes, qui forment le schéma d une base de données, sont organisées en hiérarchie. Il est possible de définir, au niveau d une classe, des contraintes d intégrité et des règles de déduction. la déclaration suivante définit la classe Employé avec quatre attributs Dépt de type Département, Directeur de type Responsable, salaire de type Integer et nom de type String. Département et Responsable sont des classes : Employe in class with Attributes Dépt : Département ; Directeur : Responsable ; Salaire : Integer ; Nom : String ; end La classe Responsable est une sous-classe de la classe Employé. Elle ne spécifie pas d attributs supplémentaires. Responsable in Class isa Employé end La déclaration suivante permet de créer l objet Marie comme instance de la classe Responsable. Seuls trois attributs sont valorisés : Marie in Responsable with Dépt : R&D ; Salaire : ; Nom : «Marie Smith» ; end Règles de déduction, contraintes et requêtes Les ensembles R et CI d une base objet déductive (BO, R, CI) peuvent contenir des règles de déduction et des contraintes d intégrité spécifiques à une application. reprenons la définition de la classe Employé et étendons-la par une règle et une contrainte : Employé in Class with Attributes Dépt : Département ; Directeur : Responsable ; Salaire : Integer ; Nom : String ; rule RègleResponsable : t/responsable (d/département (this Dépt d) and (d Directeur t) or exist m/responsable (this Directeur m) and (m Directeur t) => (this Directeur t) Constraint CISalaire : m/responsable x,y/integer (this Directeur m) and (this Salaire x) and (m salaire y) x = < y. end La règle permet de déduire, pour un employé donné, tous ses responsables. La contrainte d intégrité exprime le fait qu un employé ne peut avoir un salaire supérieur à celui de son responsable. Dans ConceptBase, les requêtes sont traitées de la même façon que les règles et les contraintes. Les requêtes sont représentées comme des classes dont les instances constituent la réponse à la requête. Dans la requête ci-dessous, l attribut SalaireÉlevé est défini comme sous-classe de la classe Integer (par une règle de déduction qui spécifie son domaine de valeurs). QueryClass TopFemmeResponsable isa Responsable, Femme with attributes salaire:salaireélevé end Applications Plusieurs utilisations expérimentales ont été faites de Concept- Base. Dans ces applications, le mécanisme d abstraction offert par O-Telos, qui est une extension du langage Telos [6] pour la structuration d information complexe semble être aussi important que les possibilités des bases de données déductives. Souvent, Concept- Base s utilise comme un outil permettant d analyser le système selon des besoins et à des niveaux méta. Par exemple, dans le domaine des systèmes d information, ConceptBase a été utilisé dans le cadre du projet Esprit DAIDA. Il a servi de base de données globale dans le processus de développement depuis l analyse jusqu à l écriture des programmes d application bases de données. Dans une telle application, des objets et des outils hétérogènes sont à intégrer. Plus précisément, un système pour une telle application doit gérer l évolution des objets où des dépendances entre objets (gestion de versions) sont à maintenir. Un langage pour de tels systèmes doit combiner des possibilités d abstraction, d assertion et de classification dynamique. L abstraction est due au fait que les objets logiciels (spécification, documentation, conception, implantation) ne sont pas similaires et donc le langage doit permettre une description facile des propriétés communes. La caractéristique assertionnelle est nécessaire pour les contraintes d intégrité. Exemple de requête typique utilisée pour la classification dynamique d objets : QueryClass ProgrammeRéalisé isa Programme with paramètre producteur : Agent constraint est_réalisé : (this dans_l état Réalisé) and (this propriétaire producteur) end H Techniques de l Ingénieur, traité Informatique

11 BASES DE DONNÉES DÉDUCTIVES ConceptBase permet de stocker de telles requêtes comme toute autre classe. Les instances d une telle classe sont dérivées ; les mises à jour des composants logiciels peuvent donc changer les liens d instanciation de certains objets. ConceptBase a été utilisé dans beaucoup d autres applications comme la gestion de la qualité logiciel, la rétro-conception des schémas de bases de données relationnelles, etc. 4. Conclusion Les SGBD déductifs permettent d associer de façon souple les fonctionnalités de gestion de données des SGBD et celles d aide à la décision des systèmes experts. De nombreuses applications utilisant de tels systèmes sont opérationnelles. Les deux problèmes majeurs qui se posent encore actuellement sont, d une part, les problèmes d efficacité lorsque le système doit manipuler de nombreuses règles de déduction et accéder à de vastes bases de données et d autre part, l absence de norme, qu il s agisse du langage de description de règles ou des modèles de données objet pour les SGBD déductifs reposant sur de tels modèles. La technologie bases de données déductives jouera un rôle particulièrement important dans les domaines d application où les décisions sont complexes et évolutives, et nécessitant de nombreuses règles et des volumes de données importants. C est le cas par exemple de la gestion de documents évolutifs, de la découverte de connaissances, etc. De plus, avec l avènement de «l Internet grand public», de nouvelles applications, comme le commerce électronique, sont demandeurs de cette technologie. Références bibliographiques [1] ABITEBOUL (S.), HULL(R.) et VIANU (V.). Foundations of Databases. Addison-Wesley Publishing Company, ISBN (1995). [2] FRIESEN (O.), GAUTHIER-VILLARS (G.), LEFEBVRE (A.) et VIEILLE (L.). Applications of deductive object-oriented databases using DEL, in Applications of Logic Databases, Edited by Raghu Ramakrishnan, Academic Press (1995). [3] GALLAIRE (H.), MINKER (J.) et NICOLAS (J.-M.). Logic and Databases : A Deductive Approach. Computing Survey, Vol. 16, n o 2, Juin [4] GARDARIN (G.) et VALDURIEZ (P.). SGBD avances : bases de données objets, déductives, réparties. Eyrolles (1990). [5] JARKE (M.), EHERER (S.), GALLERSDOERFER (R.), JEUSFELD (M.) et STAUDT (M.). ConceptBase a deductive object base manager. Research Report RR93-14, University of Technology, Aachen, Germany (1993). [6] MYLOPOULOS (J.), BORGIDA (A.), JARKE (M.) et KOUBARAKIS (M.). Telos a language for representing knowledge about information systems. ACM Trans. Information Systems. Vol. 8, n o 4, p (1990). [7] STONEBRAKER (M.) et KEMNITZ (G.). The POSTGRES Next Generation Database Management Systems. Communication of ACM, Vol. 34, n o 10, p (1991). [8] STORIA Version 1.0r, Manuel de référence de l interface avec RDB, SLIGOS Agence DELPHIA, déc [9] WIDOM (J.), COCHRANE (R.J.) et LINDSAY (B.G.). Implementation Set-Oriented Production Rules as an Extension to Starburst. In proceedings of VLDB 91, Barcelona, Spain, p , sept Techniques de l Ingénieur, traité Informatique H