Université de Jijel-Mohamed Seddik ben Yahia Faculté des Science Exact et de l’Informatique
Département de l’Informatique
Mémoire
Pour l’obtention du diplôme Master de Recherche en Informatique
Option : Système d’information et aide à la décision
Amélioration de la qualité de service d’une application Android
à base d’un entrepôt de données actif.
Thème
Présenter par :
Bounnah Fayza
Encadré par :
M
me.Bouainah Madiha
Membres de jury :
Président : ...
Rapporteure : M
me.Bouainah Madiha
Examinateur : ...
Après avoir remercié Dieu, notre créateur de nous avoir donné la force, le courage et la volonté pour terminer ce
travail.
Je tiens à exprimer ma grande gratitude à ma directrice de recherche Mme" Bouainah Madiha " pour avoir
diriger ce travail, je voudrais ainsi la remercier pour son encadrement exceptionnel, ses conseils judicieux, et ses remarques avisées qui m’ont guidées tout au long de ma
recherche.
Je voudrais également remercier les membres du jury pour avoir accepter d’évaluer mon travail. Merci de
Je dédie ce modeste travail :
A mes parents. Aucun hommage ne pourrait être à la hauteur de l’amour et les sacrifices que vous avez consenti pour mon instruction et mon bien être. Je vous
remercie pour tout le soutien et l’amour que vous me portez depuis mon enfance et j’espère que votre bénédiction m’accompagne toujours. Que dieu leur
procure bonne santé et longue vie. A tous ceux qui ont participé à ma réussite.
Table des matières i
List of Figures v
List of Tables vii
Liste des abbréviations viii
Introduction Générale ix
1 Généralisation sur les entrepôts de données 1
1.1 Introduction . . . 1
1.2 Notions fondamentaux . . . 1
1.2.1 Notion d’un entrepôt de données . . . 1
1.2.2 Magasin de données (Datamart) . . . 3
1.2.3 Les systèmes de traitement en ligne . . . 3
1.2.3.1 OLAP (On-Line Analytical Processing) . . . 3
1.2.3.2 OLTP (On-Line Transactional Processing) . . . 4
1.2.3.3 Les caractéristiques distinctives entre OLTP et OLAP . 4 1.2.4 PROCESSUS ETL . . . 4
1.3 Modelage multidimensionnel . . . 5
1.3.1 Outils de modelage . . . 5
1.3.1.1 Stockage de données . . . 6
1.3.1.2 Notion de cube . . . 8
1.3.1.3 Les opérateurs OLAP . . . 9
1.3.1.4 Les différentes technologies d’implémentation . . . 11
1.4 L’architecture d’un entrepôt de données . . . 12
1.5.3 Modélisation . . . 14
1.5.4 Modélisation physique . . . 14
1.5.5 Sources de données . . . 15
1.5.6 Processus ETL . . . 15
1.5.7 Remplir les entrepôts de données . . . 15
1.5.8 Applications utilisateur . . . 15
1.5.9 Roll-out les entrepôts et les applications . . . 15
1.6 L’importance des tests pour un entrepôt de données . . . 15
1.6.1 Tests unitaires . . . 16 1.6.2 Test d’intégration . . . 16 1.6.3 Test du système . . . 16 1.7 Conclusion . . . 17 2 L’Etat de l’art 18 2.1 Introduction . . . 18 2.2 SGBD actif . . . 19
2.2.1 Les bases de données actives . . . 19
2.2.1.1 Caractéristiques . . . 20
2.2.2 Survol sur une règle ECA . . . 20
2.2.2.1 Le contexte d’un évènement . . . 21
2.2.2.2 Condition . . . 23
2.2.2.3 Action . . . 23
2.2.2.4 Déclencheur . . . 23
2.2.3 Les avantages d’une base de données active . . . 24
2.3 L’entrepôt de données actif . . . 24
2.4 Les règles d’analyse . . . 26
2.4.1 Modèle de connaissance . . . 26
2.4.1.1 Modèle de règles . . . 27
2.4.2 Mode de production et Techniques de Détection . . . 28
2.4.2.1 Mode de production . . . 28
2.4.2.2 Les mécanismes de Détection d’évènements composés . 29 2.4.3 Modèle d’exécution . . . 30
2.5.2 Fonctionnalité du CEP . . . 31
2.5.3 Types de CEP . . . 32
2.6 Entreposage de données d’événements . . . 32
2.6.1 Notion de EDWH . . . 33
2.6.2 Les types d’éléments de données stockés dans un EDWH . . . . 33
2.6.3 Stockage des traces d’événements . . . 34
2.6.3.1 Insertion transactionnels . . . 34
2.6.3.2 Traitement batch transactionnel . . . 34
2.6.3.3 Transactionnels dans la mémoire de chargement en masse 34 2.6.3.4 Utilisation des logs transactionnels . . . 34
2.6.4 Exigences de CEP . . . 35
2.7 Conclusion . . . 35
3 Analyse et conception 37 3.1 Introduction . . . 37
3.2 Domaine d’application . . . 38
3.2.1 Processus de Livraison à distance . . . 38
3.2.2 Problèmes . . . 39
3.3 Architecture générale du système . . . 39
3.4 Spécification des besoins . . . 41
3.4.1 Besoins non fonctionnels . . . 41
3.4.2 Besoins fonctionnels . . . 41
3.5 Description du contexte . . . 42
3.5.1 Identification des acteurs . . . 42
3.5.2 Réalisation des diagrammes de contexte . . . 42
3.5.2.1 Diagrammes de cas d’utilisation . . . 43
3.5.3 Diagrammes de classe des bases de données source . . . 45
3.6 Conception de l’entrepôt de données(QUALITE_DE_SERVICE) . . . 48
3.6.1 Les faits et les dimensions . . . 48
3.6.1.1 La table des faits et les mesures . . . 48
3.6.1.2 Les dimensions et leurs hiérarchies . . . 49
3.7.2 Les règles d’analyse . . . 55
3.8 Conclusion . . . 60
4 L’implémentation 61 4.1 Introduction . . . 61
4.2 Outils utilisés pour réaliser l’application . . . 61
4.2.1 NetBeans . . . 61
4.2.2 Oracle SQL Developer . . . 62
4.3 Survol sur l’application . . . 62
4.3.1 Interface d’authentification . . . 62
4.3.1.1 Interface d’accueil . . . 63
4.3.1.2 Les bases de données sources . . . 64
4.3.1.3 L’entrepôt de données passif . . . 65
4.3.1.4 Qualité de service . . . 66
4.3.1.5 Gestion l’application . . . 68
4.4 Conclusion . . . 71
1.1 Processus ETL . . . 5
1.2 Exemple général du schéma en étoile . . . 7
1.3 Exemple général du schéma en flocon du neige . . . 7
1.4 Exemple général du schéma Galaxy . . . 8
1.5 Exemple des trois dimensions d’un Hypercube . . . 9
1.6 Cube sous forme d’un cuboïde . . . 9
1.7 Architecture générale d’un entrepôt de données . . . 13
1.8 Implémentation d’un entrepôt de données[7] . . . 13
2.1 SGBD actif . . . 20
2.2 Architecture d’un entrepôt de données actif[22] . . . 25
2.3 La détection de l’évènement(E =E1; E2) par un automate. . . 29
2.4 La détection de l’évènement(E =E1; E2) par un graphe d’événement. . . 30
2.5 Architecture d’un traitements complexes. . . 32
3.1 L’architecture générale du système. . . 40
3.2 Diagramme de cas d’utilisateur du système « Administrateur » . . . . 43
3.3 Diagramme de cas d’utilisateur« Produits » . . . 44
3.4 Diagramme de cas d’utilisateur« chauffeur-livreur » . . . 45
3.5 schéma conceptuel de base de données « Produits » . . . 46
3.6 schéma conceptuel de base de données « CHAUFFEURS-LIVREUR » . 47 3.7 Modèle dimensionnel décrivant les données dans l’entrepôt de données. 54 3.8 La syntaxe pour spécifier une règle d’analyse. . . 55
3.9 La règle d’analyse BloqueChauffeurLivreur. . . 55
3.10 La règle d’analyse NouveauChauffeurLivreur. . . 56
3.11 La règle d’analyse SupprimerChauffeurLivreurInactif. . . 56
3.15 La règle d’analyse NouveauClient. . . 58
3.16 La règle d’analyse SupprimerClientInactif. . . 59
3.17 La règle d’analyse SupprimerMarque. . . 59
3.18 La règle d’analyse NouveauMarque. . . 60
3.19 La règle d’analyse NotifierChauffeurLivreur. . . 60
4.1 Fenêtre d’authentification . . . 63
4.2 Fenêtre principale. . . 64
4.3 Fenêtre de bases de données sources. . . 65
4.4 Fenêtre d’entrepôt de données passif. . . 66
4.5 Fenêtre de qualité de service. . . 67
4.6 Fenêtre d’analyse avancé par chauffeur-livreur. . . 68
4.7 Fenêtre pour gérer l’application. . . 69
1.1 Les caractéristiques distinctives entre OLTP et OLAP . . . 4
1.2 Niveaux de modélisation . . . 6
2.1 Les évènements temporels . . . 27
3.1 Rôles principaux des acteurs du système. . . 42
3.2 La table des faits (F_QUALITE_SERVICE). . . 49
3.3 Dimensions & hiérarchies. . . 49
3.4 D_CHAUFFEURS_LIVREUR. . . 50 3.5 D_COMMANDES. . . 50 3.6 D_PRODUITS. . . 51 3.7 D_MARQUES. . . 51 3.8 D_CATEGORIES. . . 51 3.9 D_JOURS. . . 52 3.10 D_MOIS. . . 52 3.11 D_ANNEE. . . 52 3.12 D_CLIENTS. . . 53
ECA Event-Condition-Action
OLTP On-Line Transaction Processing XML Extensible Markup Language OLAP On-line Analytical Processing ETL Extract Transaction Load
SGBD Système de Gestion de Base De Données SQL Structured query language
ROLAP Relational On-Line Analytical Processing
MOLAP Multidimensional On-Line Analytical Processing HOLAP Hybrid On-Line Analytical Processing
ODBC Open Data Base Connectivity RDP Réseau de Pétri
DAG Direct Acyclic Graph IA Intelligence artificielle IoT Internet of Things
CEP Complex Event Processing EDWH Event Data Warehouse UP Unified Process
IDE Integrated Development Environment JDBC Java Database Connectivity
La première apparition des entrepôts de données remonte aux années 80, et dans les années 90 leur concept a été formalisé par (Inmon et al., 1994). Les entrepôts de don-nées sont fiables dans le domaine de la prise de décision, en plus qu’ils considèrent comme une technologie clef pour améliorer l’analyse de des données et les système d’aide à la décision dans les entreprises.
Les entrepôts de données conventionnels ont un rôle d’analyse et d’extrait des con-naissances à partir des données, mais ils ne sont pas capable a effectuer tous les analy-ses automatiquement, un coté manuel est nécessaire pour adapter les analyanaly-ses et prend des décisions.
Dans ce contexte, une nouvelle catégorie de systèmes d’aide à la décision a émergé appelée «les entrepôts de données actifs». Selon les travaux de (Thalhammer et al., 2001), les entrepôts de données actifs qui sont inspirées par les base de données ac-tives qui utilisent le paradigme ECA offre la possibilité d’automatiser la prise de dé-cision. Les décisions sont automatiquement exportées vers les systèmes de traitement des transactions en ligne (OLTP). Les règles ECA (Event-Condition-Action) dans un entrepôt de données actif sont imitent le travail d’un analyste lors de la prise de déci-sion donc en l’appelées les règles d’analyse.
Une question essentielle est effectivement posé sur le rôle joué (ou pas) par un décideur humain dans la prise des décisions, en tant que les algorithmes d’aide à la décision concernent quasiment tous les domaines aujourd’hui’hui. Il vaut la peine de dire que la disposition d’un système d’aide à la décision peut nous conduire à une dé-cision entièrement automatisée ou partiellement.Dans ce cas-là, si on ne remet jamais en cause le résultat de l’algorithme alors, la décision réputé fiable et dite automatisée
Le développement d’Internet, des réseaux sans fils, des technologies agents et des télécommunications a conduit à l’émergence d’un commerce électronique basé sur des applications spéciales qui sont l’intermédiaire entre le e-commerçant et ses clients. Nous mentionnerons spécifiquement les applications de livraison à distance qui se multiplient au fil de temps, grâce aux services précieux qu’elles peut fournit aux clients tel que : le gain de temps, livraison facilitée et rapidité des objets volumineux, ...
La simplicité d’utilisation et l’ergonomie sont des points de base pour le développe-ment des applications de livraison à distance. Donc, pour l’amélioration de rôle de ces application et l’amélioration de la qualité de ces services, il s’agit de faire une étude scientifique des conditions de travail et des relations entre l’être humain et la machine pour adapter l’environnement de travail (outils, matériel, organisation. . . ) aux besoins de l’utilisateur, ainsi que la garantir de la facilité des commandes et de livraison pour encourager les clients à continuer à bénéficier de ces services. On outre, il est néces-saire de continuer à évaluer ces applications pour assurer la continuité de la qualité de leurs services et les améliorer en fonction des exigences des clients, ainsi que pour compenser les lacunes qui accompagnent le processus de livraison. Dans le travail que nous allons présenter, on propose une manière pour gérer l’évaluation d’une appli-cation de livraison à travers des décisions automatiques à l’aide des règles d’analyses dans un entrepôt de données actif.
Problématique
Tout d’abord, notre travail se situe dans le domaine des application de livraison à dis-tance, où la livraison est le lien réel relie l’e-commerçant à ses clients, de plus, la qualité de processus de livraison est de puissants révélateurs de la qualité d’offre logistique de l’application. Donc, la problématique de notre travail est d’apporter une solution pour la modélisation et le développement des règles d’analyses dans un entrepôt de données actif au but d’évaluation d’une application de livraison et de gérer par l’automatisation de quelques taches de la gestion de livraison afin d’améliorer la qualité de ce service.
√
Nous avons développé un système d’aide à la décision à base d’entrepôt de don-nées passif pour la gestion de livraison à distance, et pour observer la qual-ité de service de livraison valoriser par le temps moyen de réponse / mois, le taux de retardement/ mois, le taux de commandes en attend / mois, le taux de chauffeur−livreur libre / mois et le taux de disponibilité de produits (par mar-ques et par catégories)/mois.
√
Puis, nous avons présenté un modèle conceptuel pour les règles d’analyse.
Pour mesurer la qualité de service, on utilise les formules suivants :
• Le temps moyen de réponse = La somme (Temps entre la date de création de commande et la date livrée de chaque commande dans une période) / le nombre de commandes dans la même période.
• Le taux de retardement =(Le nombre des commandes livrées en re-tard (où le temps entre date livrée et date délai de commande > 0 ) dans une période)∗100 / le nombre de commandes dans la même période.
• Taux des commandes en attend = (Le nombre des commandes en attend dans une période) ∗100 / le nombre de commandes dans la même période.
• Taux de chauffeurs−livreur non travaillés = (Nombre Chauffeur−livreur en état libre)∗100 / le nombre total des chauffeurs−livreur.
catégories (ou des marques).
Objectifs du travail
Les objectifs suivants expliques les raisons qui font que l’on s’oriente vers ce type de décision automatique :
(1) Augmenter l’automatisation avec le déclenchement automatique des actions. (2) Les applications réalisent certains types de tâches de façon plus efficace que
l’homme.
(3) Rendent des décisions pratiques et rapides, avec la possible de traitement de gros volumes de données, bien au-delà de ce que peut faire l’humain .
(4) Rendent des décisions automatique qui n’ont pas besoins de raisonnement manuelle par le décideur humain.
(5) Augmenter la flexibilité et minimiser le temps de réponse pour améliorer la qual-ité de service.
Organisation du mémoire
Pour atteindre ces objectifs, nous avons retenu pour ce mémoire une présentation or-ganisé en quatre chapitres:
Le chapitre 1 introduit les principaux concepts des entrepôts de données et des systèmes d’analyse en ligne. Nous présentons les principes de la modélisation mul-tidimensionnelle. ce chapitre présente également l’architecture, l’implémentation et l’importance des testes des entrepôts de données.
Le chapitre 2 est dédiée à l’état de l’art des systèmes décisionnels nommé d’entrepôts de données actifs. Ce chapitre décrive les notions et concepts des entrepôts de données actifs.
que nous avons proposé pour amener une solution à notre problème.
Le chapitre 4 est dernier chapitre, il contient une description d’application que nous avons adoptée pour prouver la validité des solutions proposées pour améliorer la qualité de service de processus de livraison. L’utilisateur peut se connecter à la page d’accueil de l’application après avoir confirmé le nom d’utilisateur et le mot de passe du système.
Enfin, on terminerons ce document par une conclusion générale qui résume notre travail avec des perspectives pour les futurs travaux de ce projet.
Généralisation sur les entrepôts de
données
1.1
Introduction
Les systèmes d’information flexibles et interactifs qui aident les décideurs à extraire des informations utiles pour identifier, résoudre des problèmes et prendre des déci-sions, s’appelés les systèmes d’aide à la décision (Alter, 1980). Le processus de prise de décision se base sur l’efficacité des systèmes d’informations décisionnels à fournir des données suffisantes qui aident les décideurs à prendre des décisions stratégiques dans les plus brefs délais. Donc, les systèmes d’informations doivent stocker et analyser une grande quantité de données, et pour faciliter cela, des ensembles de quantités de données sont organisées dans un entrepôt de données, pour la préparer et faciliter son utilisation pour soutenir la prise de décision.
Dans ce chapitre, nous présentons une généralisation sur les entrepôts de données et nous décrivons leurs concepts principaux.
1.2
Notions fondamentaux
1.2.1
Notion d’un entrepôt de données
Un entrepôt de données est un dépôt d’informations contenant une grande masse de données provenant de plusieurs sources, tel que les bases de données opérationnelles et les fichiers plats (XML, texte, ...), ces informations sont stockées dans un schéma
unifié, et souvent en un seul site. La différence entre les sources de données pose plusieurs problèmes qui peuvent être un obstacle à la prise de la bonne décision au bon moment. Donc, la construction d’un entrepôt de données se base sur plusieurs processus tel que, nettoyage, intégration, transformation, chargement et rafraîchissant périodique des données.
Selon W.H.Inmon, un architecte de premier plan dans la construction des systèmes des entrepôts de données, « un entrepôt de données est une collection de données orientées sujet, intégrées, historisées et non volatiles, organisées pour le support d’un processus décisionnel ».
L’objectif d’un entrepôt de données
L’objectif d’un système d’entrepôt de données est d’aide les décideurs pour faire les bons choix décisionnels par fournir les informations précises et opportunes. Donc un entrepôt de données doit adapter les points suivants [1]:
a) Rendre les informations de l’entreprise accessible : • Contenu de l’entrepôt compréhensible,
• L’utilisateur naviguer facilement et avec rapidité. b) Rendre les information d’une entreprise cohérente :
• Les informations provenant des diverses branches de l’entreprise peuvent être mise en corrélation entre eux.
c) La constitution d’une source d’information souple et adaptable:
• La perspective de changements dans l’entrepôt de données est perpétuelle, • L’arrivée de nouvelles questions ne doit pas bouleverser les données et les
technologies existantes.
d) Représenté un bastion sécurisé qui protège la capitale information : • L’entrepôt de données contrôle l’accès aux données,
• L’entrepôt de données offre à ses gestionnaires une bonne visibilité des util-isations des données (bonnes et mauvaises) aussi après que celles-ci ont quitté l’entrepôt.
e) La constitution de la base décisionnelle de l’entreprise :
• Les informations propres au sein de l’entrepôt de données facilitent la prise de décisions.
1.2.2
Magasin de données (Datamart)
L’accès à des informations dans les plus brefs délais est difficile spécialement pour des informations très spécifiques, en raison de l’énorme quantité de données stockées dans les entrepôts de données, ce qui augmente la durée des traitements. Un magasin de données permet de répondre à ces problématiques. Un magasin de données est une forme simple d’un entrepôt de données centré sur un seul sujet ou fonction. Les don-nées sont cataloguées, ce qui permet d’améliorer le temps de réponse des utilisateurs. Les tailles des magasins de données sont variées, donc il peut accueillir et stocker des millions d’enregistrements [5].
1.2.3
Les systèmes de traitement en ligne
On a deux systèmes de traitement en ligne, OLAP et OLTP. Les entrepôts de don-nées prennent en charge le traitement analytique en ligne (OLAP), dont les exigences fonctionnelles et de performances sont très différentes de celles des applications de traitement des transactions en ligne (OLTP) traditionnellement prises en charge par les bases de données opérationnelles [6]. Les deux systèmes fonctionnent à des buts différents. Les modifications des données en ligne sont effectuées à l’aide du système OLTP. Par contre à l’aide du système OLAP, les données multidimensionnelles sont récupérées en ligne pour les analyser ce qui peut aider à la prise de décision.
1.2.3.1 OLAP (On-Line Analytical Processing)
Le système OLAP est une catégorie d’outils software qui fournissent une analyse des données pour répond à des requêtes analytiques multidimensionnelles pour l’aide à la décision. Il permet aux utilisateurs d’analyser les informations de base de données de plusieurs systèmes de base de données à la fois.
1.2.3.2 OLTP (On-Line Transactional Processing)
Le système OLTP supporte les applications orientées vers les transactions sur Internet, et gère les transactions quotidiennes des organisations.
1.2.3.3 Les caractéristiques distinctives entre OLTP et OLAP
Caractéristique OLTP OLAP
But Gestion de données
opéra-tionnelles
Aide à la décision Nombre
d’utilisateurs, Utilisateurs
Milliers. Les employés, les clients et les professionnels des technologies de l’information
Certaines. Travailleurs de la connaissance (les managers, l’administratif et les analystes, . . . )
Transaction Des transactions courtes Des transactions longues Nature des
re-quêtes
Requêtes prédéfinies (plus sim-ples)
Requêtes AD-HOC (plus com-plexes)
Les données Gère les données actuelles dans un format trop détaillé.
Numériques et
al-phanumériques
Gère de grandes quantités de données historiques, fournit des fonctionnalités de récapitula-tion et d’agrégarécapitula-tion.
Plutôt numériques Accès aux
don-nées
Certaines d’enregistrements, en lecture/écriture
Millions d’enregistrements, en lecture seule
Intégrité Orientée application Orientée sujet Normalisation Les tables sont normalisées
(3NF)
Les tables ne sont pas normal-isées, multidimensionnel
Couverture temporelle
Données courantes seulement Données courantes et his-toriques
Mise à jour Continue Périodique
Optimisation Accès transactionnel à une par-tie de la base de données
Accès analytique à toute la base de données
Sources OLTP et ses transactions con-stituent la source originale de données
Différentes bases de données OLTP deviennent la source de données pour OLAP
Opérations principales
Insertion, mise à jour et sup-pression
Extraire des données multidi-mensionnelles pour les analyser Table 1.1: Les caractéristiques distinctives entre OLTP et OLAP
1.2.4
PROCESSUS ETL
Avant d’insérer des données dans un entrepôt de données, nous devons savoir com-ment obtenir des données efficaces et utilisables. Le processus ETL (Extract-Transform-Load) est un processus de chargement des données depuis des sources vers l’entrepôt
de données, donc il est capable de produire des données propres, facilement accessi-bles et qui peuvent être exploitées efficacement. La figure 1.1 présente le rôle des trois étapes du processus ETL.
Figure 1.1: Processus ETL
1.3
Modelage multidimensionnel
Le modèle de données multidimensionnel est le cœur d’un système décisionnel [2]. Les décideurs doivent analyser les données nécessaires pour prendre une décision partic-ulière. Le modèle multidimensionnel propose de visualiser les données représentant les sujets d’analyse comme des points dans un espace à plusieurs dimensions formant les différents axes d’analyse (Choong et al, 2003)[3]. La modélisation multidimen-sionnelle consiste à considérer un sujet analysé comme un point dans un espace à plusieurs dimensions. Les données sont organisées de manière à mettre en évidence le sujet analysé et les différentes perspectives de l’analyse [4]. Nous distinguons trois niveaux pour obtenir un modèle de données, niveau conceptuel, niveau logique et niveau physique, la table 1.2 fournit une description de chaque niveau.
1.3.1
Outils de modelage
Le stockage des données dans un entrepôt de données se fait sous la forme d’un schéma dimensionnel qui se base sur la dualité FAIT/DIMENSION. Un ensemble de faits qui se produisent dans la réalité est analysé par rapport à un ensemble de dimensions dans le but de comprendre les faits et mieux l’expliquer.
Niveaux Description
Conceptuel : Une vue initiale du modèle (du système) proche de la perception de l’utilisateur pour les concepts de la réalité, loin de la machine, c’est-à-dire le modèle de niveau conceptuel ne dépend pas du choix d’un progiciel, ... etc.
e.g. entité/association.
Logique : Les modèles dépendent du SGBD utilisé dans l’implémentation (pre-mière choix d’implémentation), plus proche la machine et compréhen-sibles pour les utilisateurs finaux.
Physique : préciser les structures de stockage employés et les fonctions telles qu’elles seront ensuite réalisées par le programmeur ( très proche à la machine).
Table 1.2: Niveaux de modélisation
Faits
Un fait représente un sujet d’analyse dans une application décisionnelle [3]. Il est analysable selon un ensemble d’attributs numériques et cumulable (ou des indica-teurs d’analyse) appelés les mesures d’activité qui est agrégés en fonction des axes d’analyse à l’aide d’un ensemble des opérations d’agrégation. Les fonctions classiques pour agréger les mesures sont les mêmes que les opérations SQL "COUNT", "SUM", "MIN", "MAX" et "AVG" [8].
Dimensions
Une dimension est un axe d’analyse selon lequel sont visualisées les mesures d’activité d’un sujet d’analyse [3]. Elle explique le fait par des paramètres. Les dimensions peuvent être se présentent sous la forme d’une liste d’éléments organisés de façon hiérarchique pour permettre différents groupements de données.
1.3.1.1 Stockage de données Les différents schémas de stockage :
♦ Schéma en étoile : Le schéma en étoile est une structure simple contient un ensemble des tables périphériques, (tables de dimensions) qui sont toutes reliées par des clés primaires et étrangères à une table centrale (table des faits) utilisant le modèle entité-relation.
Figure 1.2: Exemple général du schéma en étoile
♦ Schéma en flocon : Dans les entrepôts de données, la performance prime sur la structure, en effet, le schéma en flocon de neige est une évolution du schéma en étoile, et il existe pour des raisons de performances. Le schéma en flocon in-clut une décomposition des dimensions du modèle en étoile à une forme hiérar-chique des tables, c’est à dire, la table de faits est reliée par des clés primaires et étrangères avec de différentes tables de dimension et de sous-dimension, dans une structure ressemble à un flocon de neige.
♦ Schéma en constellation (Schéma Galaxy) :Un modèle en constellation de faits est une accumulation de schémas, (en étoiles et/ou en flocon) ou les tables de faits se partagent certaines tables de dimensions. Le schéma en constellation est plus complexe par rapport au schéma en étoile et en flocon de neige. Ce modèle offre un schéma flexible mais difficile à mettre en œuvre et à maintenir.
Figure 1.4: Exemple général du schéma Galaxy
1.3.1.2 Notion de cube
Un cube de données est l’outil qui donne une vision des données sur plusieurs di-mensions, pour mettre en évidence le sujet analysé et les différentes perspectives de l’analyse.
a) Hypercube
Un Hypercube est un modèle conceptuel multidimensionnel métaphorique. Un Hypercube contient dans les cellules les valeurs des mesures détaillées et les axes sont faits par les membres des niveaux les plus détaillés de différentes dimen-sions [8]. Parmi les six faces du cube, on peut schématiser trois faces (ou di-mensions), alors que les trois dimensions à l’arrière son difficile à schématiser graphiquement comme indiqué dans la figure 1.5. Après la création du Hyper-cube, on peut l’analyser directement ou le stocker. Le contenu des cellules varie selon le besoin analytique entre les données les plus détaillées (cube de base) et les données moins détaillées (les données agrégées).
Figure 1.5: Exemple des trois dimensions d’un Hypercube
b) Treillis de cuboïdes
Les données sont agrégées dans une structure cubique s’appelé cuboïde. L’ensemble des cuboïdes constitue un treillis et forme le cube de données[9]. Un treillis est une relation d’ordre dans lequel chaque paire d’éléments admet une borne supérieure et une borne inférieure [10]. Le "All" est un niveau imaginaire in-dique au niveau d’agrégation qui s’appelé le cuboïde apex. Le cuboïde de base est le niveau le plus détaillée du cube.
Figure 1.6: Cube sous forme d’un cuboïde
1.3.1.3 Les opérateurs OLAP
Les opérateurs OLAP sont des opérations de manipulation, ils permettent d’effectuer les analyses OLAP. Il existe nombreuses opérations OLAP qui classés dans trois
caté-gories principales:
a) Les opérations de Granularité
Les opérations liées au niveau de granularité des données sont des opérations agissant sur la granularité d’observation des données. En d’autres termes, ils permettent la navigation entre les différents niveaux de détails de l’information hiérarchiquement.
On distingue deux opérations dans le niveau de granularité des données, (Roll-up et Drill-down). Cette catégorie concerne un changement de niveau de détail.
• Roll-up (Forage vers le haut) : Les données du cube sont résumées (en réduisant les dimensions) par passer d’un niveau de détail à un niveau de granularité supérieur (moins détaillé) conformément à la hiérarchie définie sur la dimension.
• Drill-down (Forage vers le bas) : Les données du cube sont représentées à un niveau de granularité de niveau inférieur, (plus détaillé) conformément à la hiérarchie définie sur la dimension (par affiner et/ou ajouter une dimen-sion).
b) Les opérations de restructuration
Cette catégorie concerne la manipulation de la représentation (Switch), les change-ments de points de vue multidimensionnelle selon différentes dimensions (pivot) et la visualisation du cube (Split, Nest, Push, Pull). Les opérations de restructura-tion sont liées à la structure des données.
• Switch (Permutation) : Consiste à inter-changer la position des membres d’une dimension.
• Pivot (Rotate) : une rotation autour d’un des trois axes d’un cube de don-nées passant par le centre de deux faces opposées, pour présenter un ensem-ble de faces différent. Un genre de sélection de faces et non des membres. • Split (Division): passer d’une présentation tridimensionnelle d’un
hyper-cube vers une présentation bidimensionnelle, c’est à dire les tranches du cube se présente sous la forme d’un ensemble de tables.
dire toutes les informations d’un cube (quel que soit le nombre de ses di-mensions) peu regrouper sur une même représentation bidimensionnelle. • Push : Push ou enfoncement consiste à combiner les membres d’une
di-mension aux mesures du cube.
c) Les opérations ensembliste (Entre les cubes)
Extraction les données par l’utilisation des opérations similaires à ceux de l’algèbre relationnelle. Les opérations ensemblistes entre les cubes, (union, intersection, différence, . . . ) aussi projection (Slice), sélection (Dice) et jointure (Drill-Across). • Slice : c’est la projection selon une dimension du cube de données. Donc, l’application de l’opérateur slice permet de sélectionner une dimension spé-cifique dans le cube pour fournit une présentation sous-cube.
• Dice : une sélection du cube de données, qui se produit après l’application de l’opérateur slice à deux dimensions ou plus pour fournit une présentation sous-cube.
• Jointure : signifie à combiner les mesures des faits de différents cubes de données corrélés pour effectuer une analyse plus globale. Les différents faits se partagent une ou plusieurs dimensions concordantes.
1.3.1.4 Les différentes technologies d’implémentation
[13] Il existe plusieurs technologies liées à l’implémentation d’un système OLAP. On distingue principalement deux types différents, MOLAP et ROLAP. On mentionne aussi le type HOLAP qui mélange les deux types précédents.
a) ROLAP (Relational Online Analytical Processing)
OLAP relationnelle est la technologie la plus utilisée d’analyse OLAP, car les SGBDs relationnels sont très largement répandus. En effet, ROLAP relie à la manipulation des données stockées dans la base de données relationnelle, mais il est nécessité d’étendre les fonctionnalités d’un SGDB pour les adaptés à des analyses.
+ ROLAP peut gérer de grandes quantités de données et n’impose aucune lim-itation sur la quantité de données,
+ Permet de générer des requêtes adaptées au schéma de l’entrepôt, et de faire des calculs adaptés aux requêtes OLAP sur le SGBD relationnel.
− Les performances peuvent être lentes (si la taille de données est grande, le temps de(s) requête(s) SQL peut être long),
− Les technologies ROLAP sont traditionnellement limitées par ce que fonc-tionnalités SQL peut faire.
b) MOLAP (Multidimensional Online Analytical Processing)
OLAP multidimensionnel est la méthode d’analyse OLAP la plus traditionnelle. La technologie MOLAP consiste au stockage des données directement dans une structure de cube multidimensionnel (dans des formats propriétaires).
+ MOLAP nécessite le pré-calcul lors de la création du cube, nécessaire pour la réalisation des calculs complexes,
+ MOLAP se caractérise par ses excellentes performances, il permet des ex-tractions des informations très rapides et optimisées,
+ Optimaux pour les opérations slice et dice.
− Le stockage n’être pas dans la base relationnelle, mais dans des cubes pro-priétaire, alors il nécessite un investissement supplémentaire,
− Il peut gérer une quantité limite de données, malgré que les données du cube peuvent dérivées d’une grande quantité de données. Dans le cube lui-même, impossible d’inclure une grande quantité de données, mais, c’est possible d’inclure des données résumées.
c) HOLAP (Hybrid Online Analytical Processing)
OLAP hybride est la technologie qui tente de combiner les avantages de MOLAP et ROLAP et exploiter le meilleur des deux. Donc, pour des informations de type sommaire HOLAP utilise la technologie MOLAP pour des performances plus rapides. Lorsque des informations détaillées sont nécessaires, HOLAP utilise la technologie ROLAP pour le stockage des données détaillées.
1.4
L’architecture d’un entrepôt de données
L’architecture d’un entrepôt de données est un mécanisme pour regrouper les don-nées sources, créer le schéma de l’entrepôt de dondon-nées, remplir et maintenir l’entrepôt de données. Il existe de nombreuses études et recherches liées à l’architecture de
l’entrepôt de données. Nous avons constaté qu’il existe plusieurs architectures qui ont été abordées, avec différents sujets et méthodes d’offre. La figure 1.7 représente l’architecture générale d’un entrepôt de données.
Figure 1.7: Architecture générale d’un entrepôt de données
1.5
Les di
fférens implémentation dans les entrepôts de
données
[7]Les étapes suivantes sont implémentées jusqu’à ce que nous ayons un entrepôt de données prêt à être utilisé par les décideurs.
1.5.1
Analyse des besoins et planification des capacités
Le premier processus de l’entreposage de données contenir la consultation de la direc-tion supérieure ainsi que des différentes parties prenantes, pour :
• La définition des besoins de l’entreprise, • La définition des architectures,
• La planification de la capacité et la sélection des outils matériels et logiciels.
1.5.2
Intégration matérielle (Hardware)
Juste après la sélection de matériel et les logiciels ils nécessitent d’être mis en intégrant les serveurs, les méthodes de stockage, et les outils logiciels utilisateur.
1.5.3
Modélisation
Cette étape est importante qui implique :
• La conception du schéma de l’entrepôt de données et les points de vues,
• L’utilisation d’un outil de modélisation si les entrepôts de données sont sophis-tiqués.
1.5.4
Modélisation physique
La modélisation physique est nécessaire pour que les entrepôts de données fonction-nent efficacement, on a dans cette étape:
• La conception de l’organisation physique de l’entrepôt de données, • Le placement des données,
• Le partitionnement des données,
1.5.5
Sources de données
L’entrepôt de données contient des informations provient d’un ou de plusieurs sources de données. Cette étape contient l’identification et la connexion des sources qui se fait à l’aide de Gateway, des drivers ODBC qui utilisent l’interface (Open Data Base Connectivity) de Microsoft qui permet aux applications d’accéder aux données dans les systèmes de gestion de base de données, ou d’un autre.
1.5.6
Processus ETL
Les données de la source nécessitent de passer par la phase ETL. Le processus de con-ception et d’implémentation de la phase ETL peut contenir des outils personnalisés pour répondre aux besoins des entreprises.
1.5.7
Remplir les entrepôts de données
Quand les outils ETL convenus, il sera nécessaire de tester les outils, peut-être en util-isant une zone de transit, (staging area) pour confirme que tout fonctionne correcte-ment. Puis, les outils ETL peuvent être utilisés pour remplir les entrepôts.
1.5.8
Applications utilisateur
La présence des applications utilisateur est ce qui rend les entrepôts de données utiles, cette étape contient la conception et l’implémentation des applications requises par les utilisateurs finaux.
1.5.9
Roll-out les entrepôts et les applications
Quand l’entrepôt de données a été rempli et les applications utilisateurs finaux testées, le système d’entrepôt et les opérations peuvent être déployés pour les utiliser par la communauté des utilisateurs.
1.6
L’importance des tests pour un entrepôt de données
Les différents types de changements tel que la corruption ou la manipulation des données qui se produisent pendant le processus d’entreposage de données, peuvent
conduire à des problèmes de performances, car beaucoup de données sont transfor-mées, intégrées, structurées, nettoyées avant de regroupées dans l’entrepôt de données. Donc, les tests de l’entrepôt de données sont une étape très critique dans le processus de développement de l’entrepôt de données [11]. Un test de l’entrepôt de données est nécessaire pour le faire fonctionner correctement et efficacement.
Le succès d’un projet d’entreposage de données besoin de planifier, concevoir et exécuter un ensemble de techniques de tests spéciales et efficaces qui exposent tous les problèmes des données, (l’incohérence, la qualité, la sécurité, processus ETL, la perfor-mances, l’expérience des utilisateurs finaux, ... etc.). Donc, les tests garantissent que les données dans les sources sont les mêmes que celles qui parviennent aux utilisa-teurs, ils se travaillent également d’améliorer la qualité des données et de les protéger contre la corruption et la perte.
[12] Il existe trois niveaux de base de tests effectués sur un entrepôt de données :
1.6.1
Tests unitaires
Lors des tests unitaires qui sont effectués par les développeurs, chaque composant est testé séparément, c’est-à-dire les procédures, les programmes, script SQL, ...
1.6.2
Test d’intégration
Pendant les tests d’intégration, pour tester si les différents composants fonctionnent bien après l’intégration, différentes modules d’application sont assemblées, puis testées.
1.6.3
Test du système
Les tests du système sont effectués par l’équipe de test dans l’objective de vérifier si l’ensemble du système fonctionne correctement ensemble ou non (estimer et de mesurer les temps de chargement, les erreurs de chargement, les placements des don-nées, ... etc.). L’ensemble de l’application d’entrepôt de données est testé à la fois avec une possibilité d’effectuer des tests système minimum avant de pouvoir appliquer le plan de test, Compte tenu de la très grande taille de l’entrepôt de données.
1.7
Conclusion
Un entrepôt de données est un outil central de chaîne décisionnelle. L’importation des données inutiles à l’entrepôt de données apportera de nombreux problèmes, alors l’implémentation de l’entrepôt de données en est une phase critique et importante. Enfin, les utilisateurs finaux peuvent accéder aux données collectées, mises en forme et propres pour étudier les situations décisionnelles.
L’Etat de l’art
2.1
Introduction
Au fil du temps, le développement du Web et la diffusion de diverses technologies Internet ont également fait les bases de données avec leur terminologie et leurs appli-cations, une partie très importante de tout processus dans divers domaines (tels que l’éducation, l’économie, ... etc.). Dans lequel, les bases de données sont devenues une base pour tous les échanges d’informations et une composante majeure de tous les systèmes d’information. En conséquence, les systèmes d’information et les nouvelles applications deviennent progressivement de plus en plus complexes.
Ils existent plusieurs types des systèmes de bases de données qui sont développées dans des contextes spécifiques telles que: distribués, temporels, objets, multimédias, ... etc. Ces nouveaux systèmes de bases de données sont efficaces pour résoudre des problèmes spécifiques, grâce aux services et aux modèles de données qu’ils fournissent, mais malgré cela, ils sont considérés comme des systèmes conventionnels (ou passifs), donc, toute manipulation de données dans ces systèmes est effectuée sur la demande explicite d’un utilisateur ou d’une application alors que leur efficacité reste souvent limité en terme de gestion de la dynamique des bases de données et en particulier de réagir aux changements d’états des bases de données [14].
Les systèmes de gestion de base de données besoin d’offrir des fonctionnalités sup-plémentaires afin de faciliter l’implémentation des applications plus avancées et plus complexes. En effet, les systèmes actifs permettent de créer des systèmes d’information
plus performants, plus rapides, et à meilleur coût que dans les systèmes passifs [15]. En plus, les systèmes actifs répondent à des évènements spécifiques après la satisfac-tion de certaines condisatisfac-tions afin de réagir aux changements d’états des bases de don-nées, autrement dit que ces systèmes permettent d’effectuer des actions prédéfinies.
Ce chapitre présente un survol sur les bases de données actives, le formalisme général des règles ECA, puis les entrepôts de données actifs, ensuite nous allons parler aux règles d’analyse dans les entrepôts de données actifs, le traitement d’événements complexes et l’entreposage de données d’évènements.
2.2
SGBD actif
Tout d’abords, il s’agit de mentionner que les données d’une base ne sont pas indépen-dantes. Les systèmes de gestion de bases de données (SGBDs) doivent garantir la co-hérence des données durant des mises à jour de la base, donc les données sont obéissent à des contraintes d’intégrité, qui sont des règles sémantiques utilisent à modéliser des relations statiques entre données (Contrainte structurelle) et des relations dynamiques (Contrainte de comportement) [16].
Un système de gestion de base de données actif est un système de base de données dotée de règle active. Dans les systèmes actifs, les transactions (des groupes de mises à jour dépendantes) ont la capacité de surveiller les objets d’une base et font passer la base d’un état cohérent à un autre état cohérent.
2.2.1
Les bases de données actives
La base de données active est un type des bases de données se produit selon la nature de la donnée et le traitement associé. On parle des bases de données avec un sys-tème d’observation d’évènements, ce syssys-tème surveille les évènements et permette à détecter lorsque certains évènements ont produit l’exécution automatique de quelques actions selon certaines conditions. Selon Smith et Dayal et al., les bases de données ac-tives offrent toutes les fonctionnalités des bases de données conventionnelles et aussi elles sont capables de réagir des modifications dans l’état de la base de données ou de son environnement, avec ou sans l’intervention d’un utilisateur grâce à l’intégration
de règles de production (nommé aussi règle d’événement- condition-action) qui sont déclenchées par des transitions d’état dans la base de données [14]. Les bases de don-nées actives sont très difficiles à maintenir en raison de la complexité qui se pose pour comprendre l’effet des déclencheurs [20].
Figure 2.1: SGBD actif
La base de données active est une base de données composée d’un ensemble de déclencheurs qui contrôle des situations d’intérêts (des évènements), et déclenche un ensemble réactions (actions) appropriée à l’apparition d’une situation. À chaque fois le déclencheur est actif, le SGBD exécute la partie condition, puis la partie action si et seulement si la condition est vraie. Ce comportement est exprimé dans des règles ECA (événement- condition-action) qui sont définies et stockées dans la base de données.
2.2.1.1 Caractéristiques
♦ Une base de données active possède tous les concepts d’une base de données conventionnelle (e.g. langage de requête, ... etc.).
♦ Une base de données active support toutes les fonctions des bases de données conventionnelle (e.g. définition et manipulation de données, gestion du stockage, ... etc.), en plus que ça, il support la définition et la gestion des règles ECA. ♦ Les bases de données actives doivent implémenter l’exécution des règles ECA,
c’est à dire, il doit être capable de détecter l’occurrence d’un événement, d’évaluer les conditions et d’exécuter des actions liées à l’évènement qu’il est détecté.
2.2.2
Survol sur une règle ECA
L’importance d’utilisation des règles dans le domaine d’informatique réside à la décrire des comportements des personnes et/ou des systèmes ou bien, de contrôler ces
com-portements, et aussi de modéliser des processus métier d’une manière déclarative [21]. Dans notre étude, nous intéressons aux règles de production, plus précisément les rè-gles Evènement-Condition-Action, ce modèle est appliqué pour spécifier les rèrè-gles des bases de données actives. Les règles ECA (Evènement-Condition-Action) sont des ex-tensions des règles de production. La plupart des systèmes de base de données actifs prennent en charge les règles avec les trois composants: l’évènement, la condition et l’action; une telle règle est appelée Evènement-Condition-Action ou règle ECA [17]. Dans un système de bases de données actif, la notion de réagir à des situations est supportée par des règles actives spécifiez les actions qui sont déclenchées automa-tiquement par certains événements, quand certaines conditions sont satisfaites.
• Une règle ECA se formalise par la forme suivant: ON<event> IF<condition>
DO<action>
• Cette règle est attachée à la sémantique suivante: Lorsque l’événement <event> se produit, on doit vérifier la condition. Si la condition <condition> est satisfaite, alors exécuter l’action <action>. Où :
L’événement est que quelque chose se passe à un endroit et à un moment particulier caractérise un fait significatif pour le déclenchement de la règle. La condition est une requête sur la base de données, qui détermine si la règle
doit être exécutée après que l’événement s’est produit.
L’action est constituée d’un ou plusieurs mises à jour ou des requêtes sur la base de données. Elle spécifie le code à exécuter si la condition est satisfaite.
2.2.2.1 Le contexte d’un évènement
L’événement représente l’identification du moment pour le déclenchement d’une rè-gle, il est associé un ensemble d’information (type et moment de production) explicite leur production. On distingue deux types d’évènements : type primitif et type com-posite.
a) Type primitif : On dit événement primitif pour décrive un évènement produit par des opérations atomiques. Les événements primitifs peuvent être internes, temporels ou externes.
• Evénement interne : est un évènement lié à la manipulation des données (e.g. les modifications de la base, ...) et des transactions (e.g. la fin de transaction, ...) dans l’SGBD.
• Evénement temporel : est un événement déclenché par une application; il fait référence au temps. L’événement temporel peut être absolu (e.g. le 25/07/2020), relatif (e.g. 5 minute après login), ou périodique (e.g. tous les trimestres).
• Evénement externe : est un événement déclenché par une application; il dépend uniquement aux phénomènes externes au système (e.g. tempéra-ture, alarme, ...).
b) Type composite : On dit événement composite pour décrive une combinaison d’événements primitifs qui est composés grâce à l’application des opérateurs de disjonction, de conjonction, de séquence et de fermeture, etc. Si les opéra-teurs de composition sont absences, des événements composites sont spécifier par plusieurs règles nécessaires. Dans la suite, on décrite la sémantique des opérateurs de composition.
E: événement composite; E1,E2,E3,E0 : événement primitif ; I : intervalle fermé
formé par [E1,E3].
• Disjonction (OR) : La disjonction de deux événements E1et E2, notée (E1OE2). L’événement E se produit lorsque E1 ou E2a lieu.
• Conjonction (AND) : La conjonction de deux événements E1 et E2, notée (E14E2). L’événement E se produit lorsque les deux événements E1 et E2
ont lieu, quel que soit leur ordre d’occurrence.
• Séquence (SEQ) : Séquence de deux événements E1 et E2, notée (E1; E2). L’événement E se produit lorsque E2 a lieu à condition que E1 se soit déjà
produit.
• Négation (NOT) : l’opérateur NOT, noté (E2). L’événement E se produit si aucune occurrence de E2 ne survient pendant l’intervalle fermé I.
• Constructeur () : noté par (E = ∗E0), l’événement E se produit après la pre-mière occurrence de E0dans I.
• Choisir (Choose) : Exemple: E = Choose (N, E1). Cela implique que, si la nième occurrence de l’événement E1 est détecté alors l’événement composé
Eest détecté.
• L’opérateur ANY : désigné par ANY (m, E1, E2, ..., En) tel que : m <= n. L’événement E se produit lorsque m événements sur les n événements dis-tincts spécifiés se produisent, sans retient l’attention sur l’ordre relatif de leur occurrence.
• L’opérateur apériodique : cet opérateur permet d’exprimer les occurrences d’un événement apériodique dans un intervalle de temps fermé. Il est et exprimé par A (E1, E2, E3), où E1, E2 et E3 sont des événements arbitraires
et on distingue deux versions :
i) L’événement apériodique cumulé : l’événement E se produit une seule fois lorsque E3 se produit et accumule les occurrences de E2dans I.
ii) L’événement apériodique non cumulatif : l’événement E est signalé à chaque fois que E2se produit dans l’intervalle de temps I.
2.2.2.2 Condition
Pour les systèmes actifs, la partie condition des règles ECA est une formule qui permet de spécifier les situations dans lesquelles l’action de chaque règle doit être effectuée, bien sûr si et seulement si cette condition est remplie. Cependant que, dans certains cas la partie condition d’une règle est optionnelle car la condition est toujours vraie; aussi dans d’autre cas, la condition est intégrée dans l’un des deux partie (l’événement ou l’action).
2.2.2.3 Action
La partie action est spécifiée par le langage de requêtes et s’exécute après la vérification si la condition est satisfaite. Au cas d’absence de condition l’action est exécutée après la déclenchement d’événement.
2.2.2.4 Déclencheur
La réalisation technique d’une base de données actives se fait par les déclencheurs « triggers ». Un déclencheur est une procédure, (peut être considéré comme un dae-mon qui surveille une base de données) qui est automatiquement invoqué par l’SGBD
en réponse aux modifications spécifiées de la base de données (la base de données est modifié d’une manière qui correspond à la spécification d’évènement). Pendant l’exécution d’une partie d’une action d’un déclencheur, des déclencheurs récursifs (d’autres déclencheurs ou le même déclencheur qui a initialisé cette action) peut être activer. Donc, il est possible d’activer plusieurs déclencheurs dans une même instruc-tion.
2.2.3
Les avantages d’une base de données active
+ Augmenter l’automatisation avec le déclenchement automatique des actions. + Augmenter la flexibilité : permet de réduire le coût de développement et de
maintenance.
+ Améliore la fiabilité de données : plus d’opérations de vérification et de répara-tion et évite la redondance d’eux.
+ Améliore les fonctionnalités d’une base de données conventionnelles : les puis-santes capacités des traitements des règles ECA.
+ Permet la construire des bases de connaissances larges et efficaces. + Permet la construire des systèmes experts.
+ Simplifier les programmes d’application : on peut être programmé une partie de programme avec les règles actives.
2.3
L’entrepôt de données actif
La première apparition des entrepôts de données remonte aux années 80, cependant que, dans les années 90 leur concept a été formalisé par (Inmon et al., 1994). Les en-trepôts de données sont des bases de données décisionnelles considèrent comme une technologie clef pour améliorer l’analyse de des données et les système d’aide à la décision dans les entreprises. Les données collectées à partir des systèmes OLTP pro-duisent des systèmes de base de données à usage spécifique destinés à fournir des don-nées approfondies pour soutenir la prise de décision, ces systèmes sont connus comme des entrepôts de données jouent un rôle analytique et permettant d’extrait des con-naissances à partir des données. Cependant, les entrepôts de données conventionnels
sont passifs [18]. Les moyens classiques tel que, requêtes SQL, vues, outils graphiques d’interrogation, ...etc., qui sont utilisent par les décideurs pour l’exploitation des vol-umes importants de données électroniques sont réalisées de manière imparfaite, autr-ement dit, les modèles relationnels dans les bases opérationnelles convient bien aux applications gérant l’activité quotidienne de l’entreprise, mais s’avère inadapté au dé-cisionnel où les analystes sont obligés d’effectuer manuellement l’analyse des données et les tâches de prise de décision, alors les entreprises ont recours à des systèmes d’aide à la décision spécifiques [14].
Dans la littérature, il existe un certain nombre de travaux sur les entrepôts de don-nées actifs. Selon les travaux de (Thalhammer et al., 2001), les entrepôts de dondon-nées actifs appartient à une nouvelle catégorie de systèmes d’aide à la décision, (inspirées par les base de données actives qui utilisent le paradigme ECA) qui offre la possi-bilité d’automatiser la prise de décision, ensuite, les décisions sont automatiquement exportées vers les systèmes de traitement des transactions en ligne (OLTP). Les règles ECA (Event-Condition-Action) dans un entrepôt de données actif sont imitent le tra-vail d’un analyste lors de la prise de décision donc en l’appelées les règles d’analyse. La figure 12 représente une architecture conceptuelle des entrepôts de données actifs proposée par Thalhammer et al. [22].
2.4
Les règles d’analyse
Les règles d’analyse sont essentiellement les mêmes que les règles ECA et ont la même structure, mais elles effectuent des analyses plus complexes dans le contexte de prise de décision.
Dans [22], Thalhamer et al., ont adopté une démarche qui simulait l’approche de prise de décision mais de manière automatique, où les règles d’analyse jouent le rôle d’un analyste et effectuer des modifications de données dans un système OLTP concer-nant les décisions routinières, d’autre part, les décisions semi-routinières nécessitent d’autres analyses manuelles par l’analyste.
La structure de base pour définir une règle d’analyse est adoptée en fonction des points suivants, qui sont adoptées par Thalhammer [22]:
1) La dimension primaire : chaque règle est associée à des instances d’un niveau de dimension particulier;
2) La condition primaire : une expression booléenne qui fait référence aux attributs de description du niveau de dimension primaire. Cette condition est faculta-tive, permet d’analyser seulement les instances du niveau de dimension primaire lorsque la règle est déclenchée.
3) L’événement : la règle d’analyse est lancée dans un point temporel spécifique. 4) Le graphe d’analyse : l’utilisateur définit un ensemble des cubes reliés entre eux
qui sont utiles pour l’analyse à l’aide des opérateurs OLAP.
5) L’ensemble des étapes de décision : la décision est prise quand certaines condi-tions sont satisfaites.
6) L’action : effectuer le résultat de la prise de décision sur le système OLTP.
2.4.1
Modèle de connaissance
Le modèle de connaissances d’un entrepôt de données actif dispose le modèle de rè-gles ; c’est l’élément constitutif qui décrit la façon dont sont définies, représentées et manipulées les règles d’analyse.
2.4.1.1 Modèle de règles
Le modèle de règle représente la définition de la structure des règles d’analyse et les opérations applicables sur ces règles. La structure d’une règle d’analyse représente dans les trois parties: évènement, condition et action.
♦ Evènement
Représente une spécification des points de temps auxquels les règles d’analyse doivent être exécutées aux contexte de prise de décision. D’après Thalhammer et al. [22], dans la partie évènement d’une règle d’analyse on intéressons unique-ment aux évèneunique-ments temporel; il existe trois types d’évèneunique-ment sont : un événe-ment temporel absolu, un événeévéne-ment temporel périodique ou un événeévéne-ment tem-porel relatif.
Type Définition Méthode Exemple
Absolu Un évènement associé à une valeur absolue dans le temps.
Disponible globalement : Exécute pour tout niveau de dimension primaire
Le 10/07/2020
Périodique Un évènement associé à une valeur de temps péri-odique.
Disponible globalement : Exécute pour tout niveau de dimension primaire
La fin de
chaque mois Rlatif Un évènement qui fait
référence à une valeur de temps relative à un point de repère.
Disponible localement : Exécute sur la base OLTP pour des instances du niveau de dimension primaire
Dix jours après la modification du prix d’un produit
Table 2.1: Les évènements temporels
♦ Condition
La partie condition d’une règle d’analyse présente une approche descendante (top-down) effectuée manuellement par l’analyste. Les opérations OLAP (e.g. Slice, Dice, Drill-Down, Roll-Up, ...) aident à identifier le cube primaire néces-saire à l’analyse multidimensionnelle. Puis, d’autres analyses hiérarchiques peu-vent être effectuées à partir du cube primaire pour obtenir des cubes plus dé-taillées jusqu’à ce que nous ayons les informations nécessaires et suffisant pour prendre une décision.
♦ Action
ré-sultat d’analyse par l’exécution d’une transaction spécifique sur le système OLTP, si non, d’autres analyses supplémentaires sont effectués.
2.4.2
Mode de production et Techniques de Détection
Ce modèle désigné quels événements et quand ils sont détectés. Nous devons égale-ment souligner que les événeégale-ments (soit être primitifs ou composés) déclenchants sont produits seulement dans la mesure où les événements primitifs ont été détectés [15]. Le moteur d’exécution des règles soit signalé quand les événements sont détectés et produits.
2.4.2.1 Mode de production
Il existe quatre modes de production pour préciser la sémantique des types d’événements composés en fonction de l’application sont :
Exemple : E= E1; E2 est un événement composé avec un historique d’événements
considérons comme suite : {E11, E13, E14} pour E1 et {E22,E25, E26} pour E2 (tel que
: Eij de type Ei produit dans l’instant Tj). On peut produire différents événements
composés selon le mode de production considéré ci-dessous :
• Récent : les occurrences les plus récentes uniquement sont utilisées pour pro-duire l’événement composé (e.g. {E14, E26}).
• Chronologique : un événement composite est détecté par les occurrences du type Ei, ils sont considérés dans leur ordre d’apparition chronologique (e.g. {E11, E22},
{E13, E25}, {E14, E26}). Une fois les occurrences des événements utilisées pour
con-stituer l’événement composite, ils ne peuvent participer à aucune autre occur-rence de l’événement composite [27].
• Continu : chacune des occurrences du type Ei peut déclencheraient la détec-tion d’une ou plusieurs occurrences du l’événement composé (e.g. {E11, E22},
{E11, E25}, {E11, E26}, {E13, E25}, {E13, E26}, {E14, E25}, {E14, E26}).
• Cumulatif : toutes les occurrences de l’événement Ei sont cumulées jusqu’à ce que l’événement composite soit détecté. Une occurrence d’événement ne par-ticipe pas à deux occurrences distinctes du même événement dans le contexte
cumulatif. Donc, n’importe quand un événement composite est détecté, on sup-prime toutes les occurrences d’événements constitutives qui sont utilisées pour détecter cet événement [27].
Dans l’exemple précédent, le contexte d’une occurrence d’événement E avec E22
qui inclut (E11) et avec E25qui inclut (E13, E14).
2.4.2.2 Les mécanismes de Détection d’évènements composés
La possibilité de découvrir ou de signaler des événements (primitifs et complexes) liés aux opérations de base est une étape essentielle dans les systèmes actifs ainsi que dans les entrepôts de données actifs. Il est clair que les événements primitifs sont détectés de manière directe, mais plusieurs études ont déterminé certaines méthodes qui sont suivies pour aider à détecter les événements complexes, et comme indiqué dans [15], ils sont détectés par : un automate fini, un réseau de Pétri (RdP) ou un graphe dirigé acyclique (DAG pour Direct Acyclic Graph).
a) Automate fini
Dans le contexte de cette approche, un automate avec un nombre fini d’états se fournit pour la détection des événements composites; les règles actives sont véri-fiés par le système à chaque fois qu’un événement primitif est signalé, et donc l’automate se passe à son état suivant si un événement logique se produit.
Figure 2.3: La détection de l’évènement(E =E1; E2) par un automate.
La figure 2.3 représente la détection d’évènement composé E par un automate fini, l’évènement E est défini par la séquence suivante : E=E1; E2. L’évènement
primitif E1est détecté, puit l’automate se passe à l’état suivante quand l’évènement
primitif E2est détecté, afin que L’évènement composé E soit détecté tout de suite.
Il est possible qu’un événement déclenche plusieurs règles à la fois, dans ce cas-là, le programmeur doit être attentif car l’ordre d’exécution dépend de
l’implém-entation des règles. On outre, le temps d’occurrence et le temps de la détection de l’événement composé sont stockés comme des informations additionnelles dans une structure de données; aussi pour chaque définition de règle, on stocke la table de transition de l’automate (une fois pour toute la classe) et l’état de l’automate (avec chaque objet pour qui la règle est activée). [15]
b) RdP
Dans le contexte de cette approche un RdP est créé par le système à chaque fois un événement composé est défini. Pour qu’un RdP détecte un événement com-posé, il doit modéliser cet évènement suivant sa sémantique. On peut compter les RdP Classiques ou colorés.
c) Graphe DAG
Le contexte de cette approche est de détecter les événements composites par un graphe d’événement qu’est un graphe dirigé acyclique (DAG).
Figure 2.4: La détection de l’évènement(E =E1; E2) par un graphe d’événement.
La figure 2.4représente la détection de l’évènement composé (E= E1; E2) par un
graphe d’événements construits suivant la sémantique de l’expression d’événem-ent E. Quand l’événemd’événem-ents primitifs sont détectés par le processus du détecteur, un jeton primitif est construit, puis, injecte ce jeton dans la feuille correspon-dante dans le graphe événement. Par la suite, il transmet le jeton primitif vers le sommet en suivant les arcs du graphe en traversant les nœuds internes [15]. L’exécution d’évènement composé E est signalé quand le nœud déclenchant cor-respondant est atteint.
2.4.3
Modèle d’exécution
Le modèle d’exécution d’un entrepôt de données actif spécifie quand et comment une règle d’analyse est déclenchée, évaluée et exécutée pour gérer les décisions.