HIPAC (HIgh Performance ACtive database) [Dayal88] était un projet mené au laboratoire de recherche Xerox (Cambridge, USA). Son modèle de règles peut être ajouté à tout SGBDOO ; le prototype a été bâti au-dessus du SGBD PROBE.
6.2.1 Le modèle de règles
Les règles y sont modélisées par des objets. Toutes les règles sont instances d'une classe unique qui décrit la structure et le comportement des règles. Cette classe peut être spécialisée pour créer des règles plus spécifiques. Les attributs d'une classe règle sont les suivants : l’événement, la condition, l’action et le mode de couplage.
L’ événement
L'événement est défini par un identificateur et une liste de paramètres. Ces paramètres permettent à l'action et à la condition d’accéder au contexte de déclenchement de l'événement. HIPAC distingue trois types d'événements primitifs: Base de données, Temporels et Abstraits.
• Les événements Base de données sont associés aux opérations exécutées sur la Base de données (BD). Ces opérations peuvent être réalisées par le système (modification de la base, transaction, ...) ou par l'utilisateur (fonctions définies par l'utilisateur).
Une opération n'étant pas instantanée, pour chacune d'elles deux événements peuvent être définis, l'un correspondant au début de l'opération, l'autre à la fin de celle-ci. L'identificateur de l'événement est alors l'identificateur de l'opération préfixé de Beginning ou End. Pour les opérations système, la liste des arguments est définie par les concepteurs d'HIPAC. Tandis que pour les fonctions utilisateur, les arguments de l'événement Beginning sont les paramètres d'entrée de la fonction et les arguments de l'événement End sont les paramètres de sortie.
Par exemple, l'événement E1 ci-dessous est déclenché lors de l'appel de la fonction Update_position. Ses arguments sont T la cible qui va changer de position, et Position qui indique les coordonnées initiales de la cible. L'événement E2 est déclenché au retour de la fonction, ses arguments sont les mêmes mais Position indique alors les nouvelles coordonnées de la cible.
E1 : Beginning_Update_Position (T : Target, Position(T) : (Lat, Long)) E2 : End_Update_Position (T : Target, Position(T) : (Lat, Long))
• Les événements Temporels sont déclenchés par l'horloge système. Ils peuvent être désignés de manière absolue (exemple : 9:00:00 a.m. April 10. 1988), relative (exemple : 30 secs after event E occurred) ou périodique (exemple : every day at midnight).
• Les événements Abstraits sont les événements qui ne peuvent pas être détectés par le système HIPAC. Leur identificateur et leur liste d'arguments sont définis dans le modèle, mais ils sont déclenchés par l'utilisateur ou un programme annexe, au moyen de l'appel de fonction
signal.
Ces trois types d'événements représentent les événements primitifs. HIPAC permet aussi l'expression d'événements composés grâce aux opérateurs de disjonction, de séquence et de fermeture.
• L'opérateur de disjonction "|" (Exemple: E1|E2) permet de spécifier la sélection d'une règle soit lors de la détection d'un événement E1, soit lors de celle d'un événement E2.
• L'opérateur de séquence ":" (Exemple : E1:E2) permet d'indiquer la sélection d'une règle lorsque, durant une même transaction, les événements E1 et E2 sont détectés suivant l'ordre spécifié.
• L'opérateur de fermeture "*" (Exemple: E1*) permet d'indiquer qu'une règle qui référence un événement E1 avec l'opérateur de fermeture, ne sera sélectionnée qu'en fin de transaction . Si, lors d'une transaction, l'événement E1 est déclenché n fois, ses arguments effectifs seront stockés séquentiellement. A la fin de cette transaction, la règle utilise la séquence des n listes d'arguments effectifs.
Les autres composants d’une règle active dans HIPAC sont :
La condition
La condition est exprimée par une conjonction de requêtes à la base de données . Elle est satisfaite si toutes les requêtes retournent une réponse non-vide. L'ensemble des réponses pourra être utilisé par l'action lors de son exécution.
L'action
L’action est soit un programme incluant des opérations sur la BD et des déclenchements d'événements abstraits, soit un message à destination d'un programme externe.
Les couplages E-C, C-A
Au niveau d'une règle, les couplages expriment respectivement le moment de l'évaluation de la condition relativement au déclenchement de l'événement et celui de l'exécution de l'action par rapport à l'évaluation de la condition. Ils peuvent prendre comme valeurs : immédiat,
différé, séparé dépendant, séparé indépendant.
• Le mode immédiat indique l'interruption de la transaction dans laquelle l'événement est déclenché, pour permettre l'évaluation de la condition (ou respectivement l'exécution de l'action).
• En mode différé, la condition est évaluée à la fin de la transaction (de même pour l'exécution de l'action).
• En mode séparé dépendant, l'évaluation de la condition et l'exécution de l'action sont réalisées dans une autre transaction, si la transaction déclenchante n'est pas interrompue.
• Le mode séparé indépendant est identique au précédent ; cependant si la transaction déclenchante est interrompue, la condition est tout de même évaluée et l'action exécutée.
6.2.2 Bilan
HIPAC est la référence des modèles à base de règles ECA par le nombre de concepts qu'il
introduit. Certains de ces concepts restent cependant flous. En particulier, la définition de l'opérateur de séquence ne spécifie pas si la séquence est stricte (E1 suivi immédiatement de
E2), ou si des événements peuvent s'intercaler : E1 E3 ... En E2. En ce qui concerne
l'opérateur de disjonction, Dayal ne précise pas comment il utilise, dans la condition et l'action, les paramètres des deux événements. En effet, un paramètre formel ne peut pas être utilisé si un paramètre effectif ne lui est pas associé. Les modes de couplages sont aussi discutables. Les modes immédiat et différé sont intéressants. Par contre, étant donné le caractère aléatoire de l’instant où sont réalisées l'évaluation de la condition et l'exécution de l'action, les deux autres modes seront-ils utilisés ? De plus, lors de l'exécution de l'action, les paramètres effectifs et les réponses des requêtes ne sont plus représentatifs de l'état de la BD.
Par contre, le système HIPAC propose un certain nombre de concepts intéressants que nous avons adoptés. En particulier, il a mis en évidence le fait que les événements peuvent avoir des origines multiples et que certains ne sont pas déclenchables par le système (Evénements abstraits). Il a aussi montré que les trois composantes d'une règle ne sont pas indépendantes. Le contexte dans lequel s'est déclenché l'événement peut être utilisé par la condition et l'action. Les calculs et les requêtes réalisés lors de l'évaluation de la condition peuvent être