Discussion :

[blaz]

Considérons le schéma relationnel ci dessus.

Je ne veux pas générer l'entité date.
Du coup, lors de la génération du MPD, la colonne EvalDat migre dans la table "Evaluer".

Imaginons que ce ne soit pas une date, mais une période qui soit modélisée dans l'entité date.
Celle ci contiendrait deux attributs : DatDeb et DatFin.
DateDeb serait la clé primaire et datFin un attribut pouvant être null.
Je ne veux toujours pas générer l'entité date.

Du coup, DatDeb migrera bien dans "Evaluer" mais pas datFin.

Peut-on dire à powerAMC de migrer l'attribut qui ne fait pas partie de la clé de la table non générée (datFin) ?


Merci pour vos réponses.

Et excuses et merci d'avance à fsmrel , m'étant permis d'emprunter le lien vers son schéma dans un autre post
http://www.developpez.net/forums/d75...d-entite-date/

[fsmrel]

Bonsoir blaz,

DateDeb serait la clé primaire et datFin un attribut pouvant être null

Venant du Relationland où le bonhomme NULL est interdit de séjour, je suis obligé de vous proposer de modéliser autrement.

Vous abordez en fait le problème de la modélisation des données temporelles, ayant fait l’objet d’une étude approfondie par les Relationlanders, et ayant donné lieu à l’ouvrage Temporal Data And The Relational Model concocté par C. J. Date, Hugh Darwen et Nikos A. Lorentzos.

Je ne vais pas commenter 400 pages qui ne sont pas toujours d’une lecture facile, mais en tous cas, la première chose qu’on en retient est qu’il faut impérativement isoler les données en cours des données historisées, et que pour ces dernières on doit disposer du type INTERVALLE pour pouvoir mettre en œuvre la batterie des contraintes et des opérateurs permettant de contrôler efficacement et manipuler de façon simple les données intervallaires, telles que celles qui concernent le temps.
Vu de la théorie relationnelle, votre modèle doit ressembler à ceci :

Code D :

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

1
2
3
4
5
6
7
8
9
VAR PARTICIPANT BASE RELATION
      {PartId          INTEGER,
       PartNom         CHAR}
    KEY {PartId} ;

VAR EVALUATION BASE RELATION
      {ThemeId         INTEGER,
       Duree           INTEGER}
    KEY {ThemeId} ;

Pour la partie en cours :

Code D :

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

1
2
3
4
5
6
7
8
VAR EVALUER_ENCOURS BASE RELATION
      {PartId          INTEGER,
       ThemeId         INTEGER,
       Evaluer_Depuis  DATE,
       EvalNote        INTEGER}
    KEY {PartId, ThemeId, Evaluer_Depuis}
    FOREIGN KEY {PartId} REFERENCES PARTICIPANT
    FOREIGN KEY {ThemeId} REFERENCES EVALUATION ;

Pour la partie historique :

Code D :

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

1
2
3
4
5
6
7
8
VAR EVALUER_HISTORIQUE BASE RELATION
      {PartId          INTEGER,
       ThemeId         INTEGER,
       Evaluer_Durant  INTERVAL_DATE,
       EvalNote        INTEGER}
    KEY {PartId, ThemeId, Evaluer_Durant}
    FOREIGN KEY {PartId} REFERENCES PARTICIPANT
    FOREIGN KEY {ThemeId} REFERENCES EVALUATION ;

L’attribut Evaluer_Durant est du type INTERVAL_DATE auquel est associé un opérateur de sélection :

INTERVAL_DATE ([debut : fin])

debut et fin étant des expressions du type DATE. On doit évidemment disposer d’opérateurs tels que BEGIN (i), END (i), etc. pour manipuler les intervalles, par exemple BEGIN (Evaluer_Durant) pour connaître la date de début d’une EvalNote.

On contrôle l’unicité des clés de façon très rigoureuse en codant :

Code D :

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

1
2
3
4
5
6
7
8
VAR EVALUER_HISTORIQUE BASE RELATION
      {PartId          INTEGER,
       ThemeId         INTEGER,
       Evaluer_Durant  INTERVAL_DATE,
       EvalNote        INTEGER}
    USING Evaluer_Durant KEY {PartId, ThemeId, Evaluer_Durant}
    FOREIGN KEY {PartId} REFERENCES PARTICIPANT
    FOREIGN KEY {ThemeId} REFERENCES EVALUATION ;

Mais je ne puis en dire plus, sauf à écrire 20 pages d'explications préalables...

Quoi qu’il en soit, avec SQL vous avez tout à construire, à commencer par le type INTERVAL_DATE et ses opérateurs (si votre SGBD vous le permet, ce qui n'est pas acquis...)

Mais commencez au moins par interdire la présence du bonhomme NULL, en modélisant ainsi en Merise :

MCD


MLD


Bonne route.

[blaz]

merci pour votre réponse plus que complète.

J'en déduis que ce que je voulais faire n'est donc pas possible dans powerAMC.

Cependant, pour continuer le débat sur le modèle que vous proposez, j'y vois trois aspects peu pratiques pour l'humble développeur que je suis.

en effet, quand on on veut restituer l'activité d'évaluation d'un participant, il faut donc faire un select union sur evaluer_encours et evaluer_histo.

De plus, (mais j'aurais du le préciser), j'étais plutôt parti sur l'idée, qu'un participant ne peut participer à deux évaluations en même temps.
Du coup, votre modèle permet celà. A moins d'une contrainte check ou un trigger pour l'interdire.

enfin, dernière chose, en séparant l'historique d'évaluation de l'évaluation en cours, il faut donc prévoir un mécanisme qui transfère la ligne de donnée de eval_encours à eval_histo (un trigger ?)

C'est dans cette optique que j'étais parti sur la petite entorse à la modélisation que je proposais dans mon premier message.

Pourriez-vous m'éclairer sur ces trois points ?

Par avance merci pour vos réponses, qui sont complètes et qui me rendent moins bête ;-)

[fsmrel]

Bonsoir,

Pourriez-vous m'éclairer sur ces trois points ?

Vous me rappelez un bouquin de Pierre Dac intitulé La lumière qui éteint...

quand on veut restituer l'activité d'évaluation d'un participant, il faut donc faire un select union sur evaluer_encours et evaluer_histo.

Bien entendu, l'opérateur UNION peut servir à cela. Et si vous souhaitez cacher aux yeux innocents cet opérateur au demeurant on ne peut plus respectable, vous pouvez créer une vue d’« UNION », ce qui n’est quand même pas la mer à boire.

De plus, (mais j'aurais du le préciser), j'étais plutôt parti sur l'idée, qu'un participant ne peut participer à deux évaluations en même temps.
Du coup, votre modèle permet cela. A moins d'une contrainte check ou un trigger pour l'interdire.

A l’occasion de mon message précédent, je ne me suis pas focalisé sur les règles de gestion. En ce qui concerne les évaluations en cours, vous souhaitez qu’un participant ne puisse être évalué que pour un seul thème : ainsi donc, au jour d’aujourd’hui, un participant ne peut pas être en relation avec deux thèmes, soit.

Dans le cadre de la théorie relationnelle, la structure de la variable EVALUER_ENCOURS ne change pas, mais la clé est réduite au singleton {PartId} :

Code D :

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

1
2
3
4
5
6
7
8
VAR EVALUER_ENCOURS BASE RELATION
      {PartId          INTEGER,
       ThemeId         INTEGER,
       Evaluer_Depuis  DATE,
       EvalNote        INTEGER}
    KEY {PartId}
    FOREIGN KEY {PartId} REFERENCES PARTICIPANT
    FOREIGN KEY {ThemeId} REFERENCES EVALUATION ;

Dans le cadre de Merise, la partie correspondante du MCD devient la suivante (la relation établie avec la pseudo entité-type DATE n’a plus lieu d’être) :



Mais les merisiens purs et durs vont faire des bonds sur leur chaise. A les écouter, à cause de la cardinalité maximale 1 portée par la patte connectant l’entité-type Participant et l’association-type Evaluer_Encours, les attributs EvalDateDeb et EvalNote devraient migrer dans l’entité-type Participant. Mais ils oublient qu’en procédant ainsi, lors du passage au MLD, ces attributs pourront être marqués NULL dans la table Participant, ce que prohibe la théorie relationnelle (n’oublions pas que pour sa part, PowerAMC effectue consciencieusement la migration si on laisse le MCD ci-dessus en l’état). Pour interdire au bonhomme NULL de se manifester, l’association-type Evaluer_Encours devra faire l’objet d’une table.

La notation Merise ne le permettant pas stricto sensu, plutôt que de mettre en oeuvre cette table manuellement, il est préférable de laisser tomber cette notation au profit de la notation Entité/Relation :

MCD


Le mickey (D) symbolise le fait que l’entité-type Participant joue le rôle de dominant par rapport à l’entité-type Evaluer_Encours, ce qui permet d’éviter un cycle entre ces deux entités-types.

MLD


Accessoirement on peut se poser la pertinence de la présence de l’attribut EvalNote puisque l’évaluation du participant n’est pas achevée, mais peu importe.

Conséquences au niveau de l’historique

Dans le cadre de la théorie relationnelle, la structure de la variable EVALUER_HISTORIQUE ne change pas, mais, pour reprendre la règle que vous proposez, puisque pendant une période donné un participant n’a pu être en relation qu’avec un seul thème, là aussi l’attribut ThemeId est évacué de la clé :

Durant la période φ, le participant p a obtenu la note n pour le thème t.

Code D :

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

1
2
3
4
5
6
7
8
VAR EVALUER_HISTORIQUE BASE RELATION
      {PartId          INTEGER,
       ThemeId         INTEGER,
       Evaluer_Durant  INTERVAL_DATE,
       EvalNote        INTEGER}
    USING Evaluer_Durant KEY {PartId, Evaluer_Durant}
    FOREIGN KEY {PartId} REFERENCES PARTICIPANT
    FOREIGN KEY {ThemeId} REFERENCES EVALUATION ;

(Du fait de la présence de la clause USING, le système doit s’assurer que les périodes (attribut Evaluer_Durant) ne peuvent pas se chevaucher.)

Au niveau du MLD produit par l'AGL, l’attribut EvalDateFin est à expulser de la clé de la table Evaluer_Histo : on fait cela manuellement, ou bien, au niveau conceptuel, on abandonne la notation Merise au profit de la notation Entité/Relation proposée par PowerAMC, afin de ne plus être em... (sorry...) par la sempiternelle prétendue entité-type DATE.

MCD


MLD



Se pose maintenant le problème du chevauchement que l’on veut interdire pour les périodes.
Dans le style de la norme SQL, on met en œuvre une assertion :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE ASSERTION Contrainte_xx 
    CHECK (NOT EXISTS 
            (SELECT '' 
             FROM   EVALUER_HISTO AS x
                      JOIN 
                    EVALUER_HISTO AS y
                          ON x.PartId = y.PartId
             WHERE  x.EvalDateDeb > y.EvalDateDeb  
               AND  x.EvalDateDeb <= y.EvalDateFin
               AND  y.EvalDateDeb <= x.EvalDateFin)) ;

Et si le SGBD ne propose pas cette instruction, on peut utiliser un trigger. Par exemple avec SQL Server :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE TRIGGER TRIG01 ON EVALUER_HISTO INSTEAD OF INSERT, UPDATE AS
    SELECT '' 
    FROM   INSERTED AS x
             JOIN 
           EVALUER_HISTO AS y
                 ON x.PartId = y.PartId
    WHERE  x.EvalDateDeb > y.EvalDateDeb  
      AND  x.EvalDateDeb <= y.EvalDateFin
      AND  y.EvalDateDeb <= x.EvalDateFin
  IF @@Rowcount > 0
     BEGIN 
       Raiserror ('Chevauchement des périodes !',16,1) 
     RETURN
  END
  INSERT INTO   EVALUER_HISTO
         SELECT *
         FROM   INSERTED     
go

Enfin, dernière chose, en séparant l'historique d'évaluation de l'évaluation en cours, il faut donc prévoir un mécanisme qui transfère la ligne de donnée de eval_encours à eval_histo (un trigger ?)

De fait, à l’occasion de l’ajout d’une ligne dans la table Evaluer_Encours, vous pouvez prévoir un trigger pour expulser la ligne à remplacer (si elle existe) vers la table Evaluer_Histo, en y valorisant l’attribut EvalDateFin à la nouvelle date EvalDateDeb - 1, ou tout autre valorisation qui vous convient.

[blaz]

Merci bcp.