Historisation des Données

**mathieu44800** · 15/02/2008, 11h48

Bonjour,

Je travaille actuellement sur un projet où on me demande de gérer une historique des modifications sur les tables.

Je m'explique :

J'ai (pour simplifier) 2 tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Utilisateur(ID_UTIL,...,#ID_GROUPE)
Groupe(ID_GROUPE,...)

Environ 120 Utilisateurs répartis dans 15 Groupes...

Ces utilisateurs peuvent changer d'un groupe à un autre à une date donnée,
mais pour les requêtes, je dois savoir qui a été dans tel groupe à telle intervalle de temps.

Si la date de la modification intervient avant ou après l'intervalle de la requête, je pense que ça ne devrait pas poser de problême (même si je ne sais pas modéliser une telle chose...).

Par contre, si la date de modif intervient entre l'intervalle de la requête, ça doit certainement poser des soucis...

J'espère que je suis assez clair dans l'explication de mon problème et qu'aucun topic ne relate de ce problème (j'ai pourtant cherché...).

Merci.

A+

**Antoun** · 16/02/2008, 14h05

Conceptuellement, cela veut dire que tu as une entité Utilisateur et une entité Groupe, liées par une association "appartient". Cette appartenance a des attributs, date de début et date de fin. En termes de cardinalité, stocker l'historique veut dire qu'au cours du temps, un utilisateur va appartenir à plusieurs groupes. L'association est donc "plusieurs à plusieurs".

Une association portant des attributs ou ayant une cardinalité "plusieurs à plusieurs" est traduite pas une table, cela te donne donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Utilisateurs(ID_UTIL,...)
Appartenances(#ID_UTIL, #ID_GROUPE, debut, fin)
Groupes(ID_GROUPE,...)

(au passages, les tables sont des ensembles ; la norme recommande donc de leur donner un nom au pluriel.)

**fsmrel** · 17/02/2008, 20h57

Bonsoir mathieu44800,

Concernant la gestion des historiques, vous pouvez parcourir les messages suivants :

http://www.developpez.net/forums/sho...d.php?t=334343

http://www.developpez.net/forums/sho...d.php?t=336896

http://www.developpez.net/forums/sho...d.php?t=342162

Envoyé par antoun

au passages, les tables sont des ensembles ; la norme recommande donc de leur donner un nom au pluriel

Je vous prie de m'excuser, mais je ne sais pas de quelle norme vous parlez. Quoi qu'il en soit, les théoriciens du relationnel (Codd, Date, Ullman, j'en passe et des meilleurs) utilisent tous le singulier pour nommer cet ensemble qu'est une table.

**mathieu44800** · 18/02/2008, 09h40

Bonjour,

Merci pour vos réponses !

Partons sur cet exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Utilisateurs(ID_UTIL,...)
App_Utils_Grps(#ID_UTIL, #ID_GROUPE, Date_Debut, Date_Fin)
Groupes(ID_GROUPE,...)

Il me reste un petit doute quant aux requêtes sur ces tables :

- Comment savoir quel utilisateur fait parti d'un groupe à un temps donné ?

- Et sur un intervalle de temps ?

A+

**Antoun** · 18/02/2008, 21h54

Envoyé par mathieu44800

- Comment savoir quel utilisateur fait parti d'un groupe à un temps donné ?

Dans le principe, sur la table App_Utils_Grps, tu places une condition date_de_reference entre debut et fin.

Dans la pratique, c'est un peu peu subtil, parce que, a priori, la plupart des appartenances en cours n'ont pas de date de fin. Cela te donne donc, par exemple avec une date de référence à aujourd'hui :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
CURRENT_DATE() BETWEEN debut AND fin
OR CURRENT_DATE() >= debut AND fin IS NULL

Une astuce classique (quoi que pas très catholique) consiste à utiliser, pour les dates de fin encore inconnues, une date de "fin des temps", genre 31/12/9999, plutôt que NULL. Cela permet d'éviter le OR et de ne garder que le BETWEEN.

Envoyé par mathieu44800

- Et sur un intervalle de temps ?

Soit DebR et FinR le début et la fin de la période de référence :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Debut <= FinR AND Fin >= DebR

... ceci dans le cas où la période est inclusive et où aucune date n'est NULL.

**Antoun** · 18/02/2008, 22h11

Envoyé par fsmrel

Je vous prie de m'excuser, mais je ne sais pas de quelle norme vous parlez.

Dans mon esprit, il s'agissait de la norme SQL, mais en vérifiant mes références je m'aperçois qu'il s'agit d'une norme sur les conventions de nommage relatives aux méta-données (ISO-11179 Standard naming conventions). Je n'ai pas lu la norme en question, mais la présentation qu'en fait Joe Celko*.

Envoyé par fsmrel

Quoi qu'il en soit, les théoriciens du relationnel (Codd, Date, Ullman, j'en passe et des meilleurs) utilisent tous le singulier pour nommer cet ensemble qu'est une table.

Si j'étais Codd ou Date, je pense que je ficherais pas mal des règles rédigées par les gratte-papier de l'ISO.
Si maintenant je redescends à mon modeste niveau... je constate que dans sa première version, Codd décrivaits des relations liées entre elles par des relationships. Je pense que c'était un génie, mais je suis néanmoins très content que l'on n'ait pas suivi à la lettre sa terminologie...

* CELKO, Joe. Joe Celko's SQL Programming Style. San Francisco: Elsevier, 2005. p. 14.

**fsmrel** · 19/02/2008, 01h57

Bonsoir,

Envoyé par antoun

je constate que dans sa première version, Codd décrivaits des relations liées entre elles par des relationships.

Comme l’écrit Chris Date, il est vrai que dans son article fondateur de 1970 A Relational Model of Data for
Large Shared Data Banks, Ted Codd a utilisé le terme relationship à la place de celui de relation.

Dans son article, Codd écrivait :

"we propose that users deal, not with relations which are domain-ordered, but with relationships which are their domain-unordered counterparts. "

On ne saurait quand même tenir grief à l’inventeur des bases de données relationnelles d’avoir utilisé une fois dans sa vie le terme relationship au lieu de celui de relation. En effet, dans tous ses écrits à suivre, Codd utilisa exclusivement ce dernier terme, dans son acception d’aujourd’hui (à ceci près qu’une relation est désormais seulement une valeur, alors qu’une relvar est une variable, dont les valeurs successives sont des relations*).

Il a fallu attendre six ans pour que ce terme de relationship soit utilisé par Chen, avec un sens différent (association entre entités), dans son Modèle Entité/Relation.

En passant, il a fallu aussi attendre six pour que le prototype Sytem/R d’IBM et son langage SQL voient le jour. Hélas ! Trois fois Hélas ! Bien que chercheur chez IBM, Codd n’a pas été sollicité pour superviser le projet...

Envoyé par antoun

Si j'étais Codd ou Date, je pense que je ficherais pas mal des règles rédigées par les gratte-papier de l'ISO.

Ted Codd s’en fiche, puisqu’il nous a laissés orphelins il y a bientôt cinq ans. Pour sa part, Chris Date est sur le pont relationnel depuis plus de trente-cinq ans et je pense qu’il a autre chose à faire que de s’intéresser à ce qu’écrit l’ISO. Maintenant, si cet organisme s’avisait de toucher à la théorie relationnelle je ne dis pas qu’il ne distribuerait pas des mauvais points et des petites claques, comme il l’a fait pour Celko (je vous renvoie à Date on Database: Writings 2000-2006...)

* Par opposition, le terme table en SQL désigne à la fois la variable et les valeurs, le contenant et le contenu.