Developpez.com - SGBD & SQL
X

Choisissez d'abord la catégorieensuite la rubrique :


Gestion de données temporelles

Date 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 :

  • Quelles sont les données non historisées (même si elles changent, on ne conserve pas les états antérieurs) ?
  • Quelles sont les données dont on veut connaître l'état à chaque instant, mais dont les transitions ne sont pas pertinentes ?
  • Quelles sont les données dont l'étude des transitions est fondamentale ?
  • Quelles sont les données qui représentent des situations à des intervalles de temps prévisibles (CA mensuel par exemple) ?
Pour chacune des grandes catégories ci-dessus, il faut se demander :

  • Est-ce que l'information est liée à une table de référence ou non ?
  • Est-ce que l'information est multivaluée ou non ?
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.

warning Le MCD présenté ici ne se veut en aucun cas un MCD acceptable pour la gestion des RH, mais simplement comme un réservoir d'exemples.
info Dans les descriptions suivantes, la notion de " multivaluation avec nomenclature " correspond à une multivaluation engendré par la possibilité d'avoir plusieurs liens avec différentes données de la nomenclature, mais un seul (à un instant donné) avec chacune des valeurs de la nomenclature.
Par exemple sur chaque feuille de paie il y a plusieurs retenues salariales, mais un seul montant par type de retenue.
Une date peut marquer :

  1. un point dans le temps non prévisible (diplôme)
  2. des périodes successives non prévisibles (métier)
  3. des périodes non successives non prévisibles (arrêt maladie)
  4. des périodes prévisibles (températures tous les jours à 5h du matin, salaire mensuel, etc.)

II. Définitions


II-A. Données


II-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. Historiques


II-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 temporelle


III-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

Nature de la donnée Méthode à utiliser
Constant Annule et Remplace
Mouvant Ajout avec mise à jour de la date de fin de la valeur précédente
Historique Ajout avec mise à jour de la date de fin de la valeur précédente.
Photographie Ajout
Journal Ajout


Valid XHTML 1.1!Valid CSS!

Copyright © 15/01/2006 Mediat. Aucune reproduction, même partielle, ne peut être faite de ce site et 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.

Contacter le responsable de la rubrique SGBD & SQL