Discussion :

[vitwan]

Salut, je travail sous merise et durant la conception d'un modèle je me suis intéresse à l'historisation et plus particulièrement à celle d'une association.
Via google , je suis arrivé sur ce schéma qui me semble représenter simplement le concept :

J'ai cherché un peu dans poweramc, j'ai la version 11 mais il ne semble pas proposer cette option depuis le MCD. La seule solution semble l'ajout à la main depuis le MPD, meme si je doute que ceci soit reelement faisable.
Comment faire ? j'ai aussi essayé l'ajout d'une nouvelle entité "historique" associé à la relation mais sans grand succès.
merci de votre aide

[CinePhil]

J'aurais plutôt tendance à séparer la table d'historisation car il n'y a pas, conceptuellement, d'association entre les données historisées et les données de l'association actuelle.
D'ailleurs, en MCD, on ne fait pas d'association à partir d'une association : on ne relie pas deux patates entre elles !

Concrètement, il va se passer le phénomène suivant :
1) Modification du loyer par l'utilisateur dans l'interface de saisie
2) Copie du tuple concerné de la table LOUER dans la table H_LOUER avec ajout de la date du jour
3) Mise à jour du loyer dans la table LOUER conformément à ce qu'a saisi l'utilisateur.

En fait, la table H_LOUER est en association avec les tables PERSONNE et LOGEMENT puisqu'elle contient leurs identifiants en clé étrangère.

Le schéma que tu montres est selon moi tout simplement faux ! D'ailleurs il n'y a pas de correspondance entre le MCD et le MLD. Et c'est normal que PowerAMC ne t'offre pas la possibilité de le faire.

[vitwan]

merci pour votre réponse.
En gros, "historiser" une table ca consiste à en créer une identique avec une date en plus sur la PK. Et tout ca se fait uniquement au niveau physique (lors de la création de la table)
Je vais simplement indiquer sur le modèle un (H) après le nom de l'association pour indiquer la particularité.

.. à moins que je représente l'historisation de cette manière ?

[CinePhil]

Cette représentation pose encore problème à mon avis.
Il y aura bien deux clés étrangères dans Louer_histo qui seront les identifiants de Personne et de Logement. Mais ton MCD donne en clé primaire 'louer_date_histo', ce qui veut dire qu'il peut y avoir une seule historisation par jour.

La bonne représentation en MCD serait peut-être de faire une association ternaire entre les entités Personne, Logement et une entité Date. Ainsi, la table issue de cette association aurait bien pour clé primaire les identifiants de Personne et de Logement et la Date.

[fsmrel]

Bonsoir,

je travail sous merise et durant la conception d'un modèle je me suis intéresse à l'historisation et plus particulièrement à celle d'une association.
Via google , je suis arrivé sur ce schéma qui me semble représenter simplement le concept

La représentation de Bernard Espinasse appelle quelques commentaires :

1) Au niveau conceptuel, l’adjonction du symbole (H) signifie que l’association-type Louer est historisable (et non pas historisée). En effet, je cite Dominique Nanci (co-auteur avec B. Espinasse de "Ingénierie des systèmes d’information Merise 2e génération"), qui parle du caractère historisable des propriétés, mais cela vaut pour les associations-types, mutatis mutandis :

Il existe alors une notation symbolique (H), qui indique que cette propriété est historisable.

A moins d’être démenti, à mon sens l’association-type Louer prend en compte ce qui est en cours et ce qui est passé (et pourquoi pas à venir) :

Pour la partie en cours :

— Une personne peut louer plusieurs logements en même temps.
— Un logement peut être loué en même temps par plusieurs personnes (les logements seraient donc de type communautaire...)

Pour la partie historique :

— Si une personne Px loue actuellement le logement Ly, alors on conserve l’historique des locations de Ly par Px (par location j’entends le couple (Personne,Logement).
— On ne conserve pas d’historique pour les locations pour lesquelles on n’a rien en cours.

Remarque concernant le MLD :

Si au niveau de la contrainte d’intégrité référentielle H_Louer -> Louer, on a défini le trigger de suppression RESTRICT, alors on ne peut pas supprimer une location en cours si elle est référencée par des locations historisées.
Si on a défini le trigger de suppression CASCADE, alors la suppression d’une location en cours entraîne celle des locations historisées.

2) La représentation graphique d’Espinasse traite du «passage du modèle Entité/Relation enrichi au modèle relationnel enrichi» (sic).

Espinasse confond représentation graphique et théorie. Je tiens en effet à rappeler que le modèle relationnel est une théorie proposée par Ted Codd en 1969 et 1970 et ce modèle se suffit à lui-même, il n’a donc nul besoin d’être enrichi.

Pour la définition exacte de ce qu’est le Modèle relationnel, je vous renvoie par exemple à la discussion avec reimscool.

J'ai cherché un peu dans poweramc, j'ai la version 11 mais il ne semble pas proposer cette option depuis le MCD. La seule solution semble l'ajout à la main depuis le MPD, meme si je doute que ceci soit reelement faisable.

Effectivement PowerAMC ne propose rien en ce sens en ce qui concerne Merise. Mais il permet de le faire si vous modélisez en utilisant la notation Entité/Relation (Outils \ Options du modèle).

1) Vous définissez les entités-types Personne et Logement en relation par une association-type Location :



2) Vous demandez à PowerAMC de transformer l’association-type en entité-type (clic droit sur le lien, puis Transformer en entité \standard) :



3) Vous ajoutez les propriétés de Location :



4) Puis vous définissez H_Location :



5) Et vous générez le MLD :

[fsmrel]

Rebonsoir,

il n'y a pas, conceptuellement, d'association entre les données historisées et les données de l'association actuelle.

Dans le cas général, il est des situations ou il peut ne pas y avoir d’association et d’autres situations dans lesquelles c’est possible.

en MCD, on ne fait pas d'association à partir d'une association : on ne relie pas deux patates entre elles !

En Merise classique, on ne relie effectivement pas deux associations-types. Maintenant, si vous passez à OOM (Orientation Objet dans Merise), cela se pratique.
Si vous passez à RM/T la version Entité/Relation de Codd (1979), il n’y a pas non plus de contraintes.

Par exemple, Codd définit :

• Des entités-types fortes, telles que Personne et Logement,
• Des entités-types associatives, telles que Location,
• Des entités-types caractéristiques (faibles), telles que H_Location.

Et il précise bien que tout type d’entité peut être connecté à n’importe quel autre type d’entité (principe d'orthogonalité).

En fait, la table H_LOUER est en association avec les tables PERSONNE et LOGEMENT puisqu'elle contient leurs identifiants en clé étrangère.

Certes, et la contrainte définie par Espinasse établit cette association, mais elle impose une contrainte supplémentaire, à savoir que l’historique des locations fait référence aux locations en cours. Or vous lui supprimez cette contrainte, donc vous changez les règles de gestion des données.

Le schéma que tu montres est selon moi tout simplement faux !

Au vu de ce tout ce qui précède, le schéma n’est pas faux. Simplement il n’est pas conforme à l’interprétation que vous faites de l’historisation des données, vous conduisant à changer les règles de gestion des données.

D'ailleurs il n'y a pas de correspondance entre le MCD et le MLD. Et c'est normal que PowerAMC ne t'offre pas la possibilité de le faire.

Les schémas que j’ai fournis dans mon précédent message montrent qu'avec PowerAMC cette correspondance existe. Simplement, pour produire le résultat attendu, il suffit d’utiliser la notation Entité/Relation au lieu de la notation Merise, qui n'est qu'une notation parmi d'autres.

[fsmrel]

Bonsoir à nouveau,

En gros, "historiser" une table ca consiste à en créer une identique avec une date en plus sur la PK. Et tout ca se fait uniquement au niveau physique (lors de la création de la table)

En très gros, comme vous dites. En tout cas, l’historisation est à modéliser au niveau conceptuel et non pas ultérieurement, au niveau logique (niveau à ne pas confondre avec le niveau physique où l’on traite des index, de la taille des blocs physiques en mémoire et/ou sur disque, bref de tout ce qui est quincaillerie, même si PowerAMC est coupable d’amalgame ès matière).

.. à moins que je représente l'historisation de cette manière ?

C’est une possibilité. Maintenant à vous de choisir :

• Soit les locations historisées doivent faire référence à des locations en cours (version Espinasse)
• Soit elles n’y font pas nécessairement référence (version CinePhil)

Si c’est la version Espinasse qui vous convient, vous procédez comme je vous l’ai indiqué dans mon premier message.
Si c’est la version CinePhil, alos votre MCD convient.

Cette représentation pose encore problème à mon avis.
Il y aura bien deux clés étrangères dans Louer_histo qui seront les identifiants de Personne et de Logement. Mais ton MCD donne en clé primaire 'louer_date_histo', ce qui veut dire qu'il peut y avoir une seule historisation par jour.

Cette représentation ne pose pas de problème, car les cardinalités 1,1 sont entre parenthèses, ce qui pour PowerAMC symbolise l'identification relative, autrement dit la clé primaire de la table Louer_histo sera la suivante :

{adresse_Logmt, n°_personne, louer_date_histo}

La bonne représentation en MCD serait peut-être de faire une association ternaire entre les entités Personne, Logement et une entité Date. Ainsi, la table issue de cette association aurait bien pour clé primaire les identifiants de Personne et de Logement et la Date.

C’est effectivement la solution classique pour faire participer la date à l’identification de la ternaire. Mais cela suppose que les locations historisées ne référencent pas les locations en cours.

=> A vitwan de choisir.

[CinePhil]

Pfiou !
Je vois que j'ai encore des choses à apprendre Professeur fsmrel !
Mes cours CNAM ne sont pas allés aussi loin et je n'ai jamais utilisé PowerAMC.
J'en étais resté à "on ne relie pas deux patates entre elles !"

[fsmrel]

J'en étais resté à "on ne relie pas deux patates entre elles !"

- begin troll -

Ben oui, je comprends. Mais c'est pourtant un bon moyen pour réussir à faire de bonnes frites pas grasses et bien dorées, à l'huile de merisier...

- end troll -

[vitwan]

bonsoir,
merci pour vos réponses, je doit les relire en détails je vais surement en apprendre beaucoup tout comme j'ai pu récupérer l'astuce de la table liés par des cardinalités "(1,1)" sur ce même forum.
pour mon problème je suis resté sur mon dernier schéma et je ne pense pas être limité à une historisation par jour puisque l'attribut date est un datetime (DT). Au pire la limite se situe à la seconde, ce qui est suffisant pour l'usage que j'ai à en faire. il s'agit en fait d'historiser le contenu de fichiers formatés.