La notion d'activité est apparue pour accroître la capacité de réaction des Systèmes de Gestion de Bases de Données SGBD ; elle a donné naissance au concept d'objet actif. Dans les systèmes à objets, en particulier dans les SGBD Orientés Objets (SGBDOO), chaque objet attend de recevoir un message, indiquant l’opération demandée. Dans ce cas, l'objet est dit passif. L'activité permet de spécifier pour un objet (dit actif) les moments de déclenchement de ses méthodes. Ces moments sont identifiés par des événements. L'objet actif n'a plus besoin d'attendre un message, il réagit de lui-même à son environnement en fonction des événements qu’il détecte.
L'activité est apparue essentiellement à travers les concepts de déclencheurs (triggers en anglais) ou de règles “actives”. Une règle active est définie en général par trois composants :
U
U
un événement, une condition et une action. Elle est aussi appelée règle ECA (Evénement, Condition, Action) [Dayal88].
L'activité d'un objet modélise un comportement interne ou externe. Lorsqu'un objet actif détecte un événement, il doit réagir. Cette réaction le concerne souvent lui-même, il réagit par l’exécution de ses propres méthodes ; c’est le comportement interne. Mais l'objet peut aussi stimuler le comportement d'autres objets, par l'intermédiaire du mécanisme d'envoi de messages ou en déclenchant explicitement d'autres événements ; c’est le comportement externe. Ce qui permet de modéliser un comportement inter-objets.
Deux aspects fondamentaux composent un système actif : (1) le modèle de règles qui permet d'exprimer l'activité d’un objet et (2) le modèle d'exécution qui permet l'exécution de cette activité.
(1) L'activité d’un objet est exprimée par des règles actives, dont la composition varie selon les systèmes. En général, elle est définie par trois composantes : l'événement, la condition et l'action. Certaines de ces composantes sont soit implicites, soit absentes. L'événement, qui indique le moment du déclenchement des règles, peut être du type primitif : Bases de
Données (modification de la base, fin de transaction, etc.), temporels ou externes (déclenchés
par l’application). De même, il peut être de type composite défini en appliquant des opérateurs de disjonction, composition, séquence, fermeture etc.(cf. § 6.2) [Chakravarthy94]. La condition permet de raffiner le moment de l'exécution de la règle. Celle-ci est exécutée si la condition est satisfaite. Dans certains systèmes, cette composante est soit absente, soit intégrée dans la composante événement [Tchounikine93] [Gehani91]. Quant à l'action, elle correspond à un bloc d'instructions dans lequel on peut déclencher d'autres règles.
(2) L’exécution d’une règle est généralement prise en charge par un moteur d’exécution, qui a pour but d’évaluer les conditions et d’exécuter les actions des règles sélectionnées lors de la détection d’un événement. Dans les SGBD, l’évaluation de la condition et l’exécution de l’action s’effectuent à l’intérieur d’une transaction [Atkinson89] ; Le modèle d’exécution est lié au support transactionnel du système.
La détection d’un événement peut se faire soit au niveau des programmes (événements utilisateurs) soit au niveau du gestionnaire des opérations sur la base (appels de méthodes, fin de transaction). Si on construit l’ensemble des règles référençant l’événement détecté, on obtient ainsi l’ensemble des règles candidates à l’exécution. L’ensemble des règles sélectionnées est construit en éliminant les règles désactivées, et en adoptant une stratégie d’ordonnancement de ces règles (selon la priorité, séquentiel, aléatoire etc.).
Le modèle d'exécution détermine la politique des traitements des règles sélectionnées. Plusieurs stratégies d'exécution existent en fonction des traitements des événements et des différents modes d’exécution ou mode couplages de la condition par rapport à l’événement et celui de l’action par rapport à la condition. La condition d’une règle est évaluée après la détection de l’événement (mode immédiat) ou bien à la fin de la transaction où l’événement est détecté (mode différé). L’évaluation de la condition peut aussi être effectuée dans une autre transaction séparée de celle où l’événement est déclenché (mode séparé) [Dayal90]. Nous retrouvons ces mêmes modes pour l’évaluation de l’action. Ces différents modes de couplages sont résumés dans le tableau suivant.
Couplage C-A
Immédiat Différé Séparé
Couplage
Immédiat C et A sont
évaluées après E.
C est vérifiée après E. A est exécutée à la fin de la transaction.
C est vérifiée après E, A est exécutée dans une transaction séparée. E-C Différé Non autorisé C est vérifiée et A exécutée à la fin de la transaction.
C est vérifiée à la fin de la transaction et A est exécutée dans une transaction séparée.
Séparé C est vérifiée et
A exécutée dans une transaction séparée.
Non autorisé
C est testée et A est exécutée dans une transaction séparée.
Tableau 6-1 : Les modes de couplage possibles
Les systèmes à objets actifs que nous avons étudiés sont tous des SGBDOO Actifs. Certains modélisent leur activité par des déclencheurs (triggers) [Beeri91] [Gehani91], d'autres par des règles ECA [Medeiros90] [Diaz91] [Dayal88] [Tchounikine93] [Gatzui92] [Chakravarthy94] [Collet94] etc. Les premiers ne sont pas présentés dans cet état de l'art, leurs principes étant similaires à ceux des règles ECA. Ils seront cités dans le bilan pour les comparer aux autres modèles. Les triggers de [Beeri91] sont des mécanismes qui permettent d'associer des actions à des événements ; la composante Condition n'existe pas. Les triggers (et contraintes) de ODE
[Gehani91] permettent de spécifier des règles de la forme Condition-Action, où la composante Evénement est implicite (c'est la modification d'un objet).
Dans la présentation des modèles, on s'intéressera plus au modèle de règles qu'au modèle d'exécution vu que notre objectif est de proposer un modèle actif pour un système de représentation de connaissances où la notion de transaction [Delobel91], contrairement aux
SGBD, est moins importante. Nous présentons en premier HIPAC, qui est le modèle actif ayant servi de référence aux autres modèles, et qui est l'un des plus complets et des plus anciens. Ensuite, nous présentons URDOS qui, à l'opposé d'HIPAC, est récent. Puis, nous achevons cet état de l'art par la présentation des particularités d'autres travaux [Diaz94] [Medeiros90] sur
les modèles actifs à base de règles ECA, et par la présentation d'un système à base de règles de production NEOPUS [Pachet92] dont nous nous sommes inspiré pour introduire la notion de "Bases de règles" dans notre modèle.