Modélisation de logiciels de gestion 140. Modélisation des données Historisation 1 Préambule Dans les chapitres précédents, nous avons appris à concevoir des modèles de données relativement élaborés en visant l objectif premier qui est de garantir que toute donnée utile soit présente et sans redondance. Dans ce chapitre, nous prendrons en compte une contrainte supplémentaire qui est l historisation des données. L historisation des données est indispensable pour assurer que nos modèles ne soient pas figés dans le temps, à l image d une photo, mais soient susceptibles de prendre en compte les changements temporels, à l image d un film. Par exemple, pour une gestion scolaire, nous pouvons associer un élève à une classe de manière figée Figure 1 ou en prenant en compte ses dates d arrivée et de départ de la classe Figure 2. Figure 1 - Modèle figé Figure 2 - Modèle avec historisation Par principe, nous nous devons de prendre en compte l historisation des données lorsque le besoin de dérouler le temps est exprimé explicitement ou implicitement. Toutefois, de plus en plus souvent, l historisation des données est aussi indispensable pour satisfaire aux exigences des processus de certification des systèmes de qualité des entreprises; par exemple, pour la certification de la famille ISO 9000, il s agit de garantir la traçabilité des processus, documents, enregistrements de données 1/8
2 Stratégie de traçabilité A notre connaissance 2 stratégies de traçabilité dans l optique des systèmes qualité sont possibles : Enregistrer dans des journaux de tables tout changement survenant dans les enregistrements de données ; pour reprendre notre métaphore, cela consisterait à faire une photo lors de chaque changement et le journal serait notre album de photos. Par contre, la structure de données issue de notre modèle, ne permet de stocker que la dernière photo. Figure 3 - Exemple de structure de journaux Doter le modèle de données d éléments structurels permettant d enregistrer toutes les données susceptibles d impacter la perception temporelle (date de début et date de fin dans notre exemple de Figure 2); toujours avec notre métaphore, ce serait de disposer d un film, nous permettant de remonter le temps et revenir aisément en arrière. Ce besoin de revenir en arrière, pourrait être, pour notre exemple de gestion scolaire, de sortir une liste de classe valable au 1 er jour du mois passé et contrairement au film, nous avons aussi la possibilité de projeter et de sortir une liste de classe valable au dernier jour du mois suivant. La première stratégie a l avantage d être très facile à mettre en œuvre, s agissant de créer et d alimenter le journal; toutefois, comme pour trouver une photo dans un album, il peut être excessivement fastidieux de retrouver un enregistrement particulier. Elle aussi l avantage de pouvoir être mis en place lorsque la structure de données est déjà existante et sans éléments d historisation. La deuxième stratégie a l inconvénient d être fastidieuse à mettre en œuvre ; essentiellement, s agissant de déterminer les éléments d historisation nécessaires. Toutefois, lorsque les éléments d historisation sont en place, il est très aisé de se déplacer dans le temps comme pour un film que l on avance ou recule. 2/8
Très souvent en entreprise, nous mettons en œuvre les deux stratégies! La deuxième pour offrir des mécanismes de gestion temporelle des éléments les plus usuels, sensibles et impactant les processus métier de l entreprise. La première pour satisfaire aux besoins de traçabilité de l ensemble des données de l entreprise. Nous réalisons un journal pour chaque entité du modèle de données ; dans ce journal, toutes les écritures sont enregistrées. [Voir notre article : Une assurance pour se prémunir du risque d erreurs des développeurs et utilisateurs /publications/isnet/isnet45.pdf ] Naturellement, pour notre cours, nous n allons nous intéresser qu à la deuxième stratégie qui a une forte incidence sur la démarche de modélisation. 3 Datation Très couramment, en informatique de gestion, l historisation est relative à la prise en compte des éléments temporels de validité d une information. Les éléments temporels peuvent être des attributs de date ou des association avec des entités qui représentent des éléments temporels comme des dates, semaines, mois, années ou encore d autres découpages utiles et nécessaires à satisfaire les besoins du SII à concevoir. La littérature étant relativement pauvre en formalisation des éléments temporels, nous renonçons à poser des règles qui pourraient s avérer erronées; en lieu et place, nous vous proposons quelques recettes à partir d exemples issus de notre pratique professionnelle. Mais, auparavant, nous commenterons le concept de date. 3/8
3.1 Concept de date Dans la littérature francophone, nous trouvons des modèles où les attributs dates sont remplacés par des associations sur une entité Date comme illustré en Figure 4. Figure 4 Entité Date de l approche francophone Nous proscrivons cette manière de faire car si une entité Date n a comme seul attribut la valeur de la date, elle n a pas de raison d être puisqu elle représente une simple valeur comme le nom de l élève ou le code de la classe. Par contre, si nous voulons enregistrer l information consistant à savoir si une date correspond à un jour férié, nous créons une entité Jour qui a comme «UID» la date du jour et comme attribut Ferié qui vaudrait Oui ou Non. Figure 5 Entité Jour préconisée Si nous préconisons une entité Jour, nous déconseillons malgré tout de l associer systématiquement comme ci-dessus pour référencer des dates ; en effet, le nombre 4/8
d associations qui en découlerait dans un projet réel d entreprise deviendrait une source de difficulté alors qu un simple attribut date permet de référencer sans aucune ambigüité l enregistrement correspondant dans l entité Jour pour savoir par exemple, si à une date donnée correspond un jour férié. 3.2 1 er exemple Figure 6 Historisation d informations scolaire L entité Jour nous permet de déterminé si une date correspond à un jour ferié. Nous n établissons pas d association entre l entité Jour et les autres entités pour référencer les dates ; d une part pour éviter de surcharger le modèle, d autre part, car le jour n a pas forcément de signification comme par exemple pour la date de naissance d une personne. L entité AnneeScolaire est un élément temporel formé d un intervalle de temps balisé par les attributs Date_Debut et Date_Fin. 5/8
L entité ProgFormation est un élément temporel formé d un intervalle de temps balisé par les 2 associations Debut et Fin avec l entité AnneeScolaire. Par cet exemple, nous confirmons qu un élément temporel n est pas forcément une date mais peut être une association avec une entité dotée d une caractéristique temporelle. L entité Absence est dotée de 2 couples de dates, le premier (Date_Debut_Planif et Date_Fin_Planif) réfère a une absence annoncée à l avance, le deuxième (Date_Debut_Effectif et Date_Fin_Effectif) réfère aux dates effectives de l absence s il devait y avoir un écart. Sans ces 2 couples, il ne serait pas possible de faire des comparaisons entre ce qui a été planifié et ce qui a été réalisé ; il est évident, qu il appartient aux «utilisateurs» ou au donneur d ordre de se prononcer sur l utilité de devoir ou pouvoir faire une telle comparaison. En mettant en place 2 attributs temporels qui doivent être fusionnés en une seule valeur à un moment donné, il y a lieu d utiliser ou de développer des mécanismes de fusion ; par exemple au niveau du langage PL/SQL de la base de données Oracle, il est possible d utiliser la fonction NVL(Date_Debut_Effectif, Date_Debut_Planif) qui rendra Date_Debut_Effectif si sa valeur n est pas nulle et Date_Debut_Planif si elle devait être nulle 1. L attribut Date_Annulation de l entité Absence correspond à une suppression logique. Nous interdisons de supprimer une absence qui est peut-être référencée dans un récapitulatif ou autre. Lors de la lecture des absences, nous nous restreindrons, pour un usage normal, à celles qui ne sont pas supprimées logiquement, c est-à-dire, celles qui n ont pas de valeur dans l attribut Date_Annulation. De prime abord, cela nous choque, mais la mort est un événement naturel que nous devons prendre en compte ; l attribut Date_Deces de l entité Personne va nous permettre d utiliser cet élément comme critère dans les éventuelles requêtes d envoi de courrier ou autre et ainsi éviter des impairs vis-à-vis de la famille et des proches tout en conservant toutes les informations relatives à cette personne pour des besoins de statistiques, de facturation ou autres. 3.3 2 ème exemple Figure 7 Historisation de prix de produit individuel Le prix de vente d un produit est un bel exemple d information historique; nous intéresse-t-on au prix actuel, au prix du 15 juin de l an passé ou au prix que nous pratiquerons dès le 1 er du mois prochain? 1 Pour l enregistrement d une absence, une des 2 dates doit être renseignée. 6/8
Il est évident, qu avec un attribut Prix au niveau de l entité Produit, nous ne pourrions répondre à ce genre de question, tout comme, il ne serait pas possible de saisir un nouveau prix en prévision d un changement à venir! S agissant du dernier point, c est ce genre d erreur qui fait que «le système informatique 2» oblige les utilisateurs à faire un certain nombre de saisie sous stress à un moment précis ; par exemple, à la fermeture du magasin, avant la prochaine réouverture pour appliquer les nouveaux prix. Naturellement, la structure d historisation des prix de vente d un produit de la Figure 7 est tout à fait arbitraire. Cette solution est intéressante pour pouvoir adapter en tout temps les prix de produits individuellement. Les entreprises peuvent avoir des besoins tout autres et engendrer autant de modèles qu il y a de stratégies commerciales. La Figure 8 vous montre une solution d historisation de prix en passant par l intermédiaire d un catalogue. Figure 8 Catalogue temporel de prix d un produit L entité Catalogue définit un intervalle temporel de validité des prix des produits regroupés dans un catalogue. Naturellement, un même produit peut apparaître dans différents catalogues et ainsi permettre un historique de ses prix de vente au sein de l entité associative PrixVenteProduit. 4 Problème de gestion des données historisées La prise en compte de l historique des données d une entreprise rend difficile le travail de conception car, d une part les critères pour déterminer les éléments à historiser sont difficiles à mettre en évidence et, d autre part les modèles permettant l historisation deviennent très vite relativement complexe de part la multitude de critères temporels. Si le travail de conception est difficile, le travail de développement lui peut être qualifié d excessivement difficile ; le volume de travail devient vite très important et les difficultés techniques conséquentes dès lors que l on multiplie les données historisées. 2 Vous avez parfaitement compris que la technologie du système informatique ne saurait être en cause, seule une conception défaillante est en cause. 7/8
Du fait de ces difficultés, le recours à des journaux partiellement ou complètement, voire le recours à la mise en place d entrepôts de données est courant. 8/8