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 2 048 - 3
1.1 Bases de données déductives et langages du 1er ordre .......................... — 3
1.1.1 Langages du 1er ordre ........................................................................ — 3
1.1.2 Interprétation d’un ensemble de clauses ......................................... — 4
1.1.3 Base de données relationnelle comme modèle
d’un ensemble de clauses.................................................................. — 4
1.1.4 Calcul du 1er ordre .............................................................................. — 4
1.1.5 Bases de données déductives utilisant le calcul du 1er ordre......... — 4
1.2 Bases de données déductives et règles de production ............................ — 5
1.3 Stratégies de construction .......................................................................... — 5
1.3.1 Stratégie par couplage ....................................................................... — 5
1.3.2 Stratégie par intégration de systèmes.............................................. — 5
2. Bases de données actives et bases de données
déductives orientées objet.................................................................... — 6
2.1 Bases de données actives ........................................................................... — 6
2.2 Bases de données déductives orientées objet .......................................... — 6
2.2.1 Définition d’objets .............................................................................. — 6
2.2.2 Définition de structures complexes .................................................. — 7
2.2.3 Définition de types.............................................................................. — 8
2.2.4 Interrogation et manipulation d’objets ............................................. — 8
2.2.5 Données virtuelles .............................................................................. — 8
2.3 Conception ................................................................................................... — 9
3. Exemples de SGBD déductifs ............................................................... — 9
3.1 SGBD déductifs relationnels....................................................................... — 9
3.2 SGBD déductifs orientés objet ................................................................... — 10
4. Conclusion ................................................................................................. — 11
Références bibliographiques ......................................................................... — 11

es technologies prédominantes pour la majorité des applications actuelles

L 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 rela-
tionnel. 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
2 - 1997

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 informa-
H 2 048

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

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 2 048 − 1
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 algo-
rithmes 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éci-
fiques 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 connais-
sance 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 dange-
reuses. 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épen-
damment 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.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 2 048 − 2 © Techniques de l’Ingénieur, traité Informatique
________________________________________________________________________________________________________ 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 rela-
tionnelles. 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 Exemple :

∀ X (Facture (X)) → ∃ Z (Commande (Z, X)) est une fbf construite sur
déductives s’appuyant les symboles de prédicat Facture et Commande. Il s’agit d’une
construction syntaxique qui peut s’interpréter : « À toute facture X
sur des SGBD relationnels correspond une commande Z ».
Les fbf peuvent subir une suite de transformations pour aboutir
Les SGBD relationnels [1] ont servi de support aux premières à des représentations équivalentes dont la manipulation est plus
bases de données déductives [3]. Deux familles de systèmes ont été facile (en particulier la forme clausale qui est celle utilisée dans les
développées : les BD déductives s’appuyant sur le cadre formel des langages de type Prolog) :
langages du 1er ordre et celles qui utilisent le formalisme général — la forme normale Prenex correspond à un regroupement de
des règles de production. tous les quantificateurs en tête de la formule :
∀ X ∃ Z (Facture (X) → Commande (Z, X))
1.1 Bases de données déductives — la skolémisation permet de remplacer toutes les variables quan-
et langages du 1er ordre tifié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 :
1.1.1 Langages du 1er ordre
∀ X (Facture (X) → Commande (f(X), X))
Comme tous les langages formels, les langages du 1er ordre
Il n’est donc plus nécessaire de faire figurer le quantificateur exis-
reposent sur des règles de construction syntaxique de formules bien
tentiel. Implicitement toutes les variables sont quantifiées univer-
formées du langage auxquelles on associe une interprétation.
sellement.
Les règles de construction syntaxiques s’appuient sur : Remarque : la formule précédente peut aussi s’écrire :
● un alphabet composé de :
∀ X (¬ Facture (X) ∨ Commande (f (X), X))
— constantes : a, b, c... ;
— variables : X, Y, Z... ; — la forme clausale consiste à exprimer toute fbf sous forme
— symboles de prédicat : P, Q, R... ; d’une disjonction de formules atomiques positives ou négatives
— fonctions : f, g, h... ; skolé misées :
— les parenthèses ; ¬ A1 ∨ ¬ A2 ... ∨¬ Am ∨ B1 ∨ B2 ... ∨ Bn
— les connecteurs logiques usuels : négation (¬), conjonction (∧),
disjonction (∨), proposition conditionnelle (→), équivalence qui peut aussi s’écrire :
(↔) ; A1 ∧ A2 ... ∧ Am → B1 ∨ B2 ... ∨ Bn
— les quantificateurs universel (∀) et existentiel (∃) ;
— des règles de construction de formules du langage composé Une telle expression constitue une clause.
de :
Exemple :
• termes : une constante ou une variable constitue un terme. Si
t1 , t2 , ..., tn sont des termes f (t1 , t2 , ..., tn) est un terme, Parent (X, Y) → Mère (X, Y) ∨ Père (X, Y)
• formules atomiques : si t1 , t2 , ... tn sont des termes et P est un
symbole de prédicat n-aire, alors P (t1 , t2 , ... tn) est une formule On se limite la plupart du temps à l’expression de clauses ne
atomique ; contenant qu’un littéral positif en partie de droite (n = 1) : ce sont
— des formules bien formées (fbf) : les clauses de Horn pour lesquelles il existe des mécanismes de
preuves formelles. Le langage Prolog repose sur les clauses de Horn.
• toute formule atomique est une fbf, On peut considérer qu’un programme Prolog est analogue à un
• si w1 et w2 sont des fbf, alors : ensemble de clauses de Horn définies.
¬ w1 Dans la suite, nous nous intéresserons donc à des ensembles de
w1 ∨ w2 clauses de Horn.
w1 ∧ w2 Exemple :
w1 → w2 Père (X, Y) → Parent (X, Y)
w1 ↔ w2 Mère (X, Y) → Parent (X, Y)
∃ x w1 (x) Mère (X, Y) ∧ Parent (X, Z) → Gmère (X,Z)
∀ x w1 (x) Père (X, Y) ∧ Parent (Y, Z) → Gpère (X, Z)
sont des fbf. Gmère (X, Y) → Gparent (X, Y)
Gpère (X, Y) → Gparent (X, Y)

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 2 048 − 3
BASES DE DONNÉES DÉDUCTIVES _________________________________________________________________________________________________________

1.1.2 Interprétation d’un ensemble de clauses 1.1.3 Base de données relationnelle

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

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 2 048 − 4 © Techniques de l’Ingénieur, traité Informatique
________________________________________________________________________________________________________ BASES DE DONNÉES DÉDUCTIVES
Les clauses dans la théorie peuvent être partiellement instan-
cié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).
Exemple : 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.
Exemple : 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.
Exemple : 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)
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 fonc-
tionnement 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.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
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 expres-
sions 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 carac-
térisée par la conception d’une base de données relationnelle comme
un outil de stockage de faits dans un environnement de démonstra-
teur 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.
1.3.1 Stratégie par couplage
Elle consiste à équiper un langage logique, généralement
PROLOG, de fonctionnalités de gestion de faits en mémoire secon-
daire 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 pour-
suivre 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.
1.3.2 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 pro-
grammation 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écla-
ratif 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.
H 2 048 − 5
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 stoc-
kage de gros volumes de données et fournissent des langages puis-
sants 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 à cer-
tains événements. Par exemple, lorsque la quantité en stock d’un
produit devient inférieure à un certain seuil, une demande d’appro-
visionnement est déclenchée automatiquement. Les approches clas-
siques 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 sys-
tè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éne-
ments 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 ».
Exemple : considérons la règle suivante :
define rule salaire-par-défaut
on insert to Employe
then begin
salaire_défaut = (select avg(salaire) from Employé) – 50 ;
update Employé.salaire = salaire_défaut
where Employé.num_emp = new.num_emp ;
end.
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.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 2 048 − 6 © Techniques de l’Ingénieur, traité Informatique
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 appli-
cation 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 carac-
té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 descrip-
tion 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.
2.2.1 Définition d’objets
Il existe deux classes génériques d’objets, les objets simples et
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
interne et ne peuvent pas subir de changement d’état. Cependant,
lorsqu’ils apparaissent comme des parties d’objets complexes, ils
peuvent être remplacés par d’autres objets simples de type similaire.
Ce remplacement est vu comme le résultat d’une opération de mise
à jour sur des objets complexes.
Exemple :
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.
Exemple :
— 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)
________________________________________________________________________________________________________ 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 identi-
ficateurs uniques, le partage de structures est facilement supporté.
Exemple :
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).
2.2.2 Définition de structures complexes
Des notations existent en mathématiques pour décrire des struc-
tures 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 inter-
prétation. Pour déterminer la valeur de vérité d’une formule, les
variables sont substituées par des constantes. Exemple : le terme
a(X, c(d, X)) décrit le graphe de la figure 3.
Figure 1 – Graphe d’une notation SET
Figure 2 – Graphe d’une notation TERM
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
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 par-
tage 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 abstrac-
tions 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 lan-
gage é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 inter-
pré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 asso-
cie des objets abstraits à des objets étiquettes.
Exemple :
— 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:(NoRue→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 construc-
teurs) 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 3 – Graphe d’une notation TERM/VAR
H 2 048 − 7
BASES DE DONNÉES DÉDUCTIVES _________________________________________________________________________________________________________
2.2.3 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 struc-
tures issues de ses types. Les types jouent également un rôle impor-
tant 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.
Exemple :
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écia-
lise 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.
Exemple : 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
Exemple :
TroisPoints = DeuxPoints:(z→Integer)
2.2.4 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]
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 2 048 − 8 © Techniques de l’Ingénieur, traité Informatique
Les xi et yi sont des variables distinctes.
Exemple :
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 des-
cription, 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.
Exemple :
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 condi-
tions. La partie action d’une commande peut être composée de plu-
sieurs 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.
2.2.5 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 alter-
native de considération d’un même ensemble de données phy-
siques.
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é.
________________________________________________________________________________________________________ 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.
Exemple :
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é à Res-
ponsable.
■ 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.
Exemple :
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.
Exemple : 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éduc-
tives 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 Lan-
guage), 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.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
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 beau-
coup 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 para-
phrasage 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.
H 2 048 − 9
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.
Exemple : la déclaration suivante définit la classe Employé avec
quatre attributs Dépt de type Département, Directeur de type Res-
ponsable, 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 ins-
tance de la classe Responsable. Seuls trois attributs sont valorisés :
Marie in Responsable with
Dépt : R&D ;
Salaire : 50 000 ;
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.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 2 048 − 10 © Techniques de l’Ingénieur, traité Informatique
Exemple : 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 res-
ponsables. 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 struc-
turation 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 classifica-
tion 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 dyna-
mique 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
________________________________________________________________________________________________________ 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’ins-
tanciation 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 nom-
breuses 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 des-
cription 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 par-
ticulièrement important dans les domaines d’application où les
décisions sont complexes et évolutives, et nécessitant de nom-
breuses règles et des volumes de données importants. C’est le cas
par exemple de la gestion de documents évolutifs, de la décou-
verte 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 0-201-53771-0
(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, no 2,
Juin 1984.
[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 mana-
ger. 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, no 4, p. 325-362 (1990).
[7] STONEBRAKER (M.) et KEMNITZ (G.). – The
POSTGRES Next Generation Database Mana-
gement Systems. Communication of ACM,
Vol. 34, no 10, p. 78-92 (1991).
[8] STORIA Version 1.0r, Manuel de référence de
l’interface avec RDB, SLIGOS Agence
DELPHIA, déc. 1989.
[9] WIDOM (J.), COCHRANE (R.J.) et LINDSAY
(B.G.). – Implementation Set-Oriented Pro-
duction Rules as an Extension to Starburst. In
proceedings of VLDB’91, Barcelona, Spain,
p. 275-285, sept. 1991.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 2 048 − 11