Gestion de données temporellesDate de publication : 15/01/2006 Implémentation de données temporelles, ou la gestion des historiques I. Introduction II. Définitions II-A. Données II-A-1. Données constantes II-A-2. Données Mouvantes II-A-3. Données multi-valuées II-A-4. Nomenclature multi-valuée II-B. Photographies II-B-1. Photographie multivaluée avec nomenclature II-B-2. Photographie multivaluée sans nomenclature II-C. Historiques II-C-1. Historique Nomenclature II-C-2. Historique multivalué avec nomenclature II-C-3. Historique multivalué sans nomenclature II-C-4. Journal III. Implémentation d'une gestion temporelle III-A. Exemple de Modèle Conceptuel des Données III-B. Explications III-C. Résumé des techniques I. Introduction
Avant d'envisaqer une gestion des historiques, il est nécessaire de se poser les questions suivantes :
Pour chacune des grandes catégories ci-dessus, il faut se demander :
Enfin il faut mettre en place un mécanisme permettant de connaître la valeur "en cours" de façon d'autant plus performante que cette question sera la plus naturelle, la plus courante.
Une date peut marquer :
II. DéfinitionsII-A. DonnéesII-A-1. Données constantes
Ce sont les données dont on ne désire pas conserver l'historique, que ce soit parce que la donnée est effectivement constante (date de naissance, par exemple), ou dont les différentes valeurs dans le temps ne sont pas utiles (le nom usuel, le N° de téléphone etc.). Toutes les données de ce genre, avec ou sans table de nomenclature sont réunies dans une seule table, dont la clé identifie un objet hors du temps (ici un employé), une telle table est obligatoire, même si elle ne contient que l'identifiant de l'entité. II-A-2. Données Mouvantes
Ce sont les données dont on veut pouvoir accéder à la valeur à une date donnée, mais dont les transitions ne présentent pas d'intérêt, par exemple, il est important de connaître le N° de compte bancaire d'un employé à une date donnée (pour retrouver la trace d'un virement par exemple), mais savoir à quelle date il a changé de compte bancaire ne présente pas d'intérêt (la question " combien d'employés ont changé de compte bancaire entre le 26/04/2003 et le 23/11/2004 " ne doit pas être posée très souvent). Une seule table de données mouvantes par entité est utile, elle regroupe toutes les données qui doivent être suivies de cette façon, un nouvel enregistrement est créé chaque fois que l'une des données est modifiée. Toutes les données mouvantes, avec ou sans table de nomenclature, sont réunies dans une seule table dont la clé est constituée de la clé de l'objet étudié (ici l'employé) plus une date de début. Je préconise d'ajouter une date de fin, ce qui complique un peu la mise à jour mais facilite énormément les extractions. Cette table permet de savoir, avec le maximum d'économie, quelles étaient les valeurs des différents attributs mouvants de l'employé à une date donnée, mais ne permet pas de faire (simplement) les études de transitions (compter les employés qui ont changé de compte bancaire dans les trois mois de leur mariage, par exemple ; cette question concernant les clients d'une banque pourrait être intéressante, mais pas dans le cadre des RH, sans doute) II-A-3. Données multi-valuées
Ce sont les données qui peuvent prendre plusieurs valeurs différentes (pour une même instance de l'entité) au même instant, mais qui n'ont pas besoin d'être historisées ; par exemple ici, l'ensemble des N° de téléphone, et des prénoms. La clé de ce genre de table est constituée de l'identifiant de l'objet multivalué (le N° de téléphone, par exemple) ; la clé de l'objet propriétaire de ces données doit apparaître dans cette table, éventuellement dans la clé (par exemple si le même N° de téléphone ne peut être attribué à plusieurs clients la clé du propriétaire n'a pas à être dans la clé de la table des N° de téléphone, alors que le même prénom peut être attribué à plusieurs personnes, et donc la clé du propriétaire doit être dans la clé de la table des prénoms). Une table sur ce schéma est nécessaire pour chacune des données multivaluées à suivre.
II-A-4. Nomenclature multi-valuée
Ce sont les données qui peuvent prendre plusieurs valeurs de nomenclature différentes (pour une même instance de l'entité) au même instant, et qui n'ont pas de vie dans le temps, par exemple, ici, l'ensemble des diplômes obtenus. La clé pour ce schéma de tables est constituée de l'identifiant de l'objet propriétaire (l'employé), et de la clé de l'attribut nomenclaturé (le diplôme). Une table de ce genre est nécessaire pour chacune des données de référence multivaluées à suivre. On peut remarquer que la date d'obtention du diplôme n'est pas un élément d'historisation, parce qu'un diplôme ne remplace un autre diplôme antérieur, mais vient s'ajouter à la liste, d'ailleurs cette date n'est pas dans la clé.
II-B. Photographies
Ce sont les données qui correspondent à une situation à un instant donné. La clé de ce genre de table est constituée de la clé de l'objet possédant, plus une période. Une table de ce genre est nécessaire par type de période, par exemple si on veut suivre le Total Brut mensuel et le Cumul net imposable Annuel, il faut deux tables, mais si on veut ajouter une autre information mensuelle (le nombre de jours de congés acquis ou pris dans le mois), il est possible de l'ajouter dans la table des photos mensuelles, même si l'information n'est pas du même type. Si des informations de nomenclature devaient être ajoutées, elles n'apparaîtraient pas dans la clé. II-B-1. Photographie multivaluée avec nomenclature
Ce sont les données qui correspondent à une situation à un instant donné (Quotidienne, hebdomadaire, etc.), mais qui se déclinent sur plusieurs valeurs de nomenclature (ici les retenues salariales différenciées par type de retenues salariales) . La clé de ce genre de table est constituée de la clé de l'objet propriétaire, de la clé de répartition et d'une période. Une table de ce genre est nécessaire par type de période et par clé de répartition (voire ensemble de clés de répartition).
II-B-2. Photographie multivaluée sans nomenclature
Même problématique que le cas précédent sauf que ce n'est pas une valeur de nomenclature qui confère l'aspect multivalué, la clé dans ce cas est constituée de la clé de l'objet propriétaire, d'une période, et d'un N° d'ordre (éventuellement artificiel). Ce cas n'apparaît pas sur le MCD, voir Historique multivalué sans nomenclature.
II-C. HistoriquesII-C-1. Historique Nomenclature
Ce sont les données dont l'historique est important, mais dont on veut pouvoir étudier les transitions ; par exemple pour faire des études sur les employés qui ont changé de Salaire de base moins de 3 mois après avoir changé de métier. La clé de ce genre de table est constituée de l'identifiant de l'objet propriétaire et d'une date de début ; la date de fin est ajoutée afin de simplifier les requêtes. Une table de ce genre est nécessaire pour chacune des données à suivre. Des données avec ou sans table de référence peuvent être gérées dans la même table, à condition qu'elles aient le même cycle de vie (ici le motif de changement est évidemment lié au changement de métier)
II-C-2. Historique multivalué avec nomenclature
Ce sont des données dont l'historique est important, qui peuvent prendre plusieurs valeurs au même instant, et dont on veut pouvoir étudier les transitions. La clé de ce genre de table est constituée de l'identifiant de l'objet propriétaire, de la clé de la nomenclature potentiellement multiple et d'une date de début, la date de fin est ajoutée afin de simplifier les requêtes. Une table de ce genre est nécessaire pour chacune des données à suivre.
II-C-3. Historique multivalué sans nomenclature
Même problématique que le cas précédent sauf que ce n'est pas une valeur de nomenclature qui confère l'aspect multivalué, la clé dans ce cas est constituée de la clé de l'objet propriétaire, d'une date de début, et d'un N° d'ordre (éventuellement artificiel). Ce cas ainsi que celui de la photographie multivaluée sans nomenclature, sont sans doute assez rare, je n'ai pas trouvé d'exemple qui ne soit pas complètement artificiel.
II-C-4. Journal
Ce cas est un peu particulier, car il ressemble à un historique (la date de début apparaît dans la clé, mais la gestion de la date de fin est très différente, il s'agit de gérer des évènements ayant un début et une fin, deux tels événements ne pouvant pas avoir la même date de début. L'exemple ici est " Arrêt Maladie ". La clé est constituée de la clé de l'objet propriétaire et d'une date de début.
Journal multivalué : Un journal peut aussi se décliner avec ou sans nomenclature, multivalué ou non et on va retrouver les mêmes solutions que pour les historiques ou les photographies.
III. Implémentation d'une gestion temporelleIII-A. Exemple de Modèle Conceptuel des Données
III-B. Explications Il est possible d'avoir IdNomenclature et N° Ordre conjointement dans la clé si il est possible d'avoir plusieurs fois la même valeur de Nomenclature pour le même temps. III-C. Résumé des techniques
|
Copyright © 15/01/2006 Mediat. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.
