Discussion :

[blins]

Bonjour,

en fait je suis bloqué dans ma réflexion et p-e que vous allez pouvoir m'aider.

j'aimerais me rappeler comment l'on prodèce pour créé une table de Contact mais dont les valeurs tel que (adresse, nom conjoint) peuvent changée aux fils du temps.

Je ne souhaite pas écrasser les valeurs mais conserver les valeurs pour que les ids qui pointait vers ma table Contact possède tjs les bonne valeurs.

(J'essaye en fait de me rappeler d'un example "Contact, assurance, voiture" dont certaines valeurs changeaient sur le temps).

Je vous remercie d'avance

[LeoAnderson]

Il y a 2 tables, une table courante et une table d'historique.
La table historique contient les mêmes données que la table courante + la date du changement.

Et c'est un trigger sur UPDATE qui se charge d'insérer dans la table d'historique.

[blins]

Merci pour cette solution,

mais à mon souvenir je pense qu'il ya avait plus quelque chose comme :

client_c (courant) [ idc, nom, prenom, idct_t ] ; client_d (dynamic) [idc_t, addresse, idc ] ; facture [idc_t , prix ]

Comme ceci si je doit changer l'adresse du client_c.idc = 3, je ferais un insert into client_d ( (newId), newAdresse, 3) et un update into client_c set idc_t = (newId)

Ainsi "facture" pointe tjs sur l'ancien idct_t qui lui même pointe vers le bon client_c (select * from facture, client_d, client_c where gnagnag ) -> idc, nom, prenom, adresse, idc_t, prix

Pensez-vous que ce résonnement puisse être possible (le but étant de ne pas avoir à recopier des champs fixes tel que nom/prenom (si meme le nom/prenom peuvent se mouvoir sur le temps, restons imagé en disant que ces 2 champs soit fixe à vie).

Concernant votre proposition, elle ne resout pas mon probleme des tables qui pointaient vers mes anciennes données courants (je ne vais pas mettre un id_ref vers la table_historique non ?

Merci d'avance

[Médiat]

Problème classique de gestion des historiques, pour donner une réponse complète, il est intéressant 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
  [list:aac6463c81]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.[/list:u:aac6463c81]

[blins]

Whaw, Médiat,

Non seulement tu m'as rappeler les questions que j'avais entendu au cours mais tu viens de me mettre encore plus dans l'interrogation, des termes tel que "transition fondamentale, information multivaluée, etc." me remette à ne mm plus savoir quoi

je ne voudrais pas te déranger plus mais si tu avais par un hassard quelqu'on un fichier avec un example d'analyse basic avec des tables contenant des données à conserver et dont on veux connaitre leur état d'antant et de maintenant.

Sinon, encore merci pour ces questions fondamentale, je pense avoir de quoi réfléchir

[Médiat]

Je pourrai rédiger un peu et fournir des explications plus détaillées, mais pas avant ce week-end, si tu n'es pas pressé...

[blins]

Faite à votre aise, nous avons tous du travail mais je vous remercie d'hors et déjà du document que vous m'enverrez

[LeoAnderson]

Je pense (et espère !) que le doc. ne vous sera pas envoyé mais sera publié ici même ! ;-)

[blins]

Evidement, partagons la culture et les connaissances

[Médiat]

Je pense (et espère !) que le doc. ne vous sera pas envoyé mais sera publié ici même ! ;-)

Et même que si tu connais un serveur où je pourrais stocker une image, j'ajouterais un MCD explicatif

[Médiat]

Remarque 1 :
Le MCD suivant ne se veut en aucun cas un MCD acceptable pour la gestion des RH, mais simplement comme un réservoir d’exemples.
Un MCD pour servir d'exemple

Remarque 2 :
Une date peut marquer un point dans le temps non prévisible (diplôme)
Une date peut marquer des périodes successives non prévisibles (métier)
Une date peut marquer des périodes non successives non prévisibles (arrêt maladie)
Une date (ou période) peut marquer des périodes prévisibles (températures tous les jours à 5h du matin, salaire mensuel, etc.)

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.

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é.

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)

Données multivalué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.

Nomenclature Multivalué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é.

Photographie :
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é.

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).

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.

Historique
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)

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.

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.

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.

Un petit tableau récapitulatif

Remarque : 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.

Résumé des techniques d'Alimentation :
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

Il serait possible de continuer à explorer les différentes possibilités, mais c'est déjà assez long ainsi, l'étape suivante serait de la taille d'un livre...

[blins]

Excellent document !

Y a juste les images qui ont été réduite lors du transfert, on ne voit plus trop bien le tableau MCD, dommage mais heureusement que le document est claire.

Je vais bien m'en servir et te contact si j'ai encore une question, merci bcp bcp

[Médiat]

je te contact si j'ai encore une question

n'hésite pas.

Pour le MCD, peu lisible, je peux ajouter le code couleur :

Jaune : données de nomenclature
Orange : données constantes
Bleu : Photographie
Vert : journal
Rouge : historique / mouvantes

Ce qui est important c'est la façon dont les clés sont constituées.