Discussion :

[win_ubuntu]

Bonsoir tout le monde;
soit le MCD suivant, qui représente des rencontres dans un tournoi de tennis.
j'aimerais ajouter la contrainte suivante:
un joueur ne peut pas gagner un match sans y avoir participé. j'hésite entre simultanéité(égalité) et inclusion. la contrainte d'inclusion me semble plus appropriée. à votre avis quelle est la contrainte la plus appropriée.

[fsmrel]

Bonsoir win_ubuntu,



Si vous établissez une contrainte d'inclusion, vous signifiez qu'un joueur qui a gagné un match a dû y participer : c'est la moindre des choses.

Si vous établissez une contrainte de simultanéité, vous signifiez non seulement qu'un joueur qui a gagné un match a dû y participer, mais en plus que s'il a participé à un match, alors il l'a forcément gagné : même Djokovic, Borg, Lenglen, Lendl, McEnroe, Borotra et autres gloires vous diront que ça n'est pas très réaliste et vous colleront aussi sec un 6/0, 6/0...

[win_ubuntu]

merci; maintenant je comprend bien la différence.
j'ai une autre question sur le même MCD.
si on veut ajouter la contrainte suivante: il ne devrait pas y avoir deux matchs sur le même terrain à la même heure. selon mes connaissance, il n'y pas de contrainte prédéfinie (Inclusion, partition,.. etc) permettant de faire çà. si au niveau SQL qu'on doit déclarer: le couple (Horaire, N° terrain) de la table Match avec la contrainte unique. votre avis?

[fsmrel]

Bonsoir win_ubuntu,

il ne devrait pas y avoir deux matchs sur le même terrain à la même heure

Si on modélise directement au niveau relationnel (au sens de la théorie relationnelle), la modélisation est la suivante (on n’y dessine pas, puisqu’on est calé sur la théorie des ensembles, le calcul des prédicats du 1er ordre et l’algèbre relationnelle...) :

VAR TERRAIN BASE RELATION
    { 
        NoTerrain        INTEGER
      , Surface          INTEGER
    }
KEY { NoTerrain } ;

VAR MATCH BASE RELATION
    { 
        NoMatch          INTEGER
      , NoTerrain        INTEGER
      , Heure            TIMESTAMP
    }
KEY { NoMatch }
KEY { NoTerrain, Heure }
FOREIGN KEY { NoTerrain } REFERENCES TERRAIN ; 

La clé { NoTerrain, Heure } signifie que sur un terrain et à une heure donnée, il ne peut y avoir qu’un seul match.


Maintenant, s’il faut modéliser ça à la Merise, ça devient sportif...

Pour exprimer la contrainte selon laquelle « sur un terrain et à une heure donnée, il ne peut y avoir qu’un seul match », il faudrait graphiquement représenter la chose à peu de choses près comme ceci :



La cardinalité 1,1 portée par la patte connectant MATCH et OCCUPATION signifie qu’un match a lieu sur un seul terrain et à une heure donnée.

La flèche rouge représente une CIF (contrainte d’intégrité fonctionnelle) symbolisant la contrainte selon laquelle sur un terrain et à une heure donnés, il ne peut y avoir qu’un seul match.

Maintenant, votre AGL de modélisation produira un script SQL ne ressemblant en rien à ce que l’on attend :

CREATE TABLE TERRAIN 
    ( 
        NoTerrain        INTEGER
      , Surface          INTEGER
    )
CONSTRAINT TERRAIN_PK PRIMARY KEY (NoTerrain) ;

CREATE TABLE MATCH 
    ( 
        NoMatch          INTEGER
      , NoTerrain        INTEGER
      , Heure            TIMESTAMP
    )
CONSTRAINT MATCH_PK PRIMARY KEY {NoMatch}
CONSTRAINT MATCH_AK UNIQUE (NoTerrain, Heure)
CONSTRAINT MATCH_FK FOREIGN KEY (NoTerrain) REFERENCES TERRAIN ; 

[fsmrel]

Maintenant, s’il faut modéliser ça à la Merise, ça devient sportif...

Le plus simple est de considérer l’heure comme un attribut tout à fait banal, de type TIME et faisant partie de l’en-tête de l’entité-type MATCH. Pour respecter les contraintes, selon le MCD ci-dessous, cette entité-type a deux identifiants : {OCCUPATION, Heure}, identifiant primaire du fait de l’identification relative (cardinalité 1,1 mise entre parenthèses) et {NoMatch}, identifiant devenant alternatif :

Le prix à payer est l’échange des rôles, identifiant primaire / identifiant alternatif : d’identifiant primaire (et donc clé primaire au stade du MLD), {noMatch}devenant identifiant alternatif (et donc clé alternative au stade du MLD) ; si en se tordant la cervelle, on estime que c’est nécessaire, on pourra permuter manuellement les rôles dans le MLD, sinon, tout va très bien Madame la Marquise, le MLD et le code SQL généré par PowerAMC sont les suivants :

 
CREATE TABLE TERRAIN 
(
   NoTerrain            INT         NOT NULL,
   Surface              INT         NOT NULL,
   CONSTRAINT TERRAIN_PK PRIMARY KEY (NoTerrain)
) ;

CREATE TABLE MATCH 
(
   NoTerrain            INT        NOT NULL,
   Heure                TIME       NOT NULL,
   NoMatch              INT        NOT NULL,
   CONSTRAINT MATCH_PK PRIMARY KEY (NoTerrain, Heure),
   CONSTRAINT MATCH_AK UNIQUE (NoMatch),
   CONSTRAINT MATCH_TERRAIN_FK FOREIGN KEY (NoTerrain)
      REFERENCES TERRAIN
) ;