Discussion :

[R00t_infinity]

Bonjour,

Dans le cadre d'un projet je dois réaliser un dossier avec MCD, MLD et tout ce qui s'en suit. J'ai déjà fait une première modélisation mais j'aurais souhaité avoir votre avis et ait également une question. Tout d'abord voici le sujet :



Mes hypothèses :
- Un seul responsable de matériel se charge du debut et fin d'une seance et ce dans un temps fixe.
- Differents catalogue par saison d'ou le 0-n entre sport et catalogue
- La gestion des salaires n'est pas à gérer mais si vous me proposer un modèle je suis preneur.
- Pas de stock de materiel à prendre en compte.

Mon petit soucis repose sur la gestion du materiel. Dois-je rajouter un lien entre le Lieu et le Materiel pour savoir ce que contient une salle ? Car si je comprend bien le sujet le responsable materiel ne devrait pas avoir de preparation à faire si la seance precedente à deja mis en place le bon type de materiel... Je suis un peu confus sur ce point.
Bien entendu si vous avez d'autres remarques (entites manquantes ou en trop, problème de cardinalité,normalisation..) je suis preneur
Merci de votre aide par avance.

[fsmrel]

Bonsoir R00t_infinity,


Votre MCD est honnête, mais il y a quelques observations à faire :

— Comment fonctionne l’abonnement d’un nouvel adhérent, désireux de pratiquer le judo ? Le judo et le water-polo ? Pourriez-vous donner des exemples ?

— Il faudrait renommer PERSONNEL en PERSONNE, car Jean Martin est une personne mais n’est pas un personnel, c'est-à-dire que Jean Martin n’est pas un ensemble de personnes (tout en pouvant être directeur du personnel).

— Corriger l’héritage : l’entité-type ANIMATEUR est un sous-type de PERSONNE et pas l’inverse.

— Rien n’empêche qu’un animateur A n’ayant pas la formation requise F pour le sport S anime une séance affectée à ce sport.

— Rien n’empêche qu’à un instant T un animateur puisse animer deux séances distinctes (problème de bilocation...)

— Certains lieux peuvent-ils accueillir en même temps deux séances ?

En attendant, voici un 1er jet d'une possible correction :




J’anticipe sur le MLD. Les rectangles rouges indiquent qu’il faudrait mettre en œuvre des entités-types SF et ASF (que vous renommerez à votre goût). Les lettres en rouge symbolisent les noms qu’auront les attributs au niveau des tables. Le soulignement précise quelles seront les clés dans le MLD. Les flèches en rouge sont du niveau MLD : pour ne pas surcharger le graphique, je n’ai pas fait figurer les associations qui leur correspondent dans le MCD.

Par ailleurs j’ai supprimé les associations PROPOSER et ANIMER car on sait les obtenir par transitivité :

SEANCE -> ASF -> SF -> S

SEANCE -> ASF -> A

J’ai supprimé l’association PENDANT et fait figurer en contrepartie un attribut P (synonyme de Période) dans l’entité-type SEANCE. Une période est composée d’une date, d’une heure de début et d’une heure de fin.

Un MCD correspondant à la partie concernée dans le diagramme précédent :



Vous noterez que l’association AVOIR connectant ANIMATEUR et FORMATION a disparu : cela veut dire qu’elle est inférable de ASF. Toutefois, je pose la question : un animateur peut-il avoir des formations non en relation avec les sports pratiqués dans le complexe sportif ? Si c’est le cas, il faudra aménager le MCD en conséquence, car SF (donc ASF) ne permet pas de les prendre en compte.

J'espère ne pas vous avoir traumatisé avec le régime auquel j'ai soumis votre MCD, tout en sachant que j'ai peut-être raté une marche quelque part...

[R00t_infinity]

Tout d'abord merci pour votre investissement.
Bien compris votre remarque sur la problème de bilocation des Animateurs ainsi que le lien Formation/Sport.

Pour ce qui est du reste, les précisions que vous demandiez :
- Une seule Séance dans un Lieu donné à un moment t.
- Les formations ne correspondront qu'aux sports proposés.
- Pour ce qui concerne l'Abonnement je me suis d’ailleurs confronté à un problème en retravaillant dessus hier. Le but serait de proposer deux types d'abonnement à prix fixe ( 1 abonnement pour un unique sport au choix à par exemple 10euros, et 1 abonnement recouvrant tous les sports pour 80€). Avec ma modélisation actuelle on aurait une redondance de l'attribut prix car on devrait créer un abonnement a sport unique pour chaque sport...)
- Pour l'attribut Période dans l'entité Séance, si je souhaite établir un planning sera-t-il possible de manipuler l'attribut pour en extraire individuellement date et heures ? Car j'avais également penser à retirer heure_deb et heure_fin de Séance pour rajouter une entité Créneau avec ces même attributs qui serait reliée à Séance via l'association Pendant.

Cependant j'aimerais une autre petite précision : Quels attributs mettriez vous dans ASF et SF ? J'ai compris leur utilité de lien avec les autres entités mais je en vois pas ce que je devrais mettre dedans.. Elles ont pour unique but de créer un lien et ne devraient contenir qu'un id ? (en plus des éventuelles clés étrangères évidemment)

Merci encore pour votre aide.

[fsmrel]

Bonsoir R00t_infinity,


Pour traiter du sujet avec rigueur et de façon complète, il serait bon que vous fournissiez les règles de gestion des données qui ont donné lieu au MCD. Certes ces règles sont rédigées en français, donc forcément parfois ambiguës, artistiquement floues, elliptiques, incomplètes, voire contradictoires, même si on fait très attention à ce qu’on écrit... Néanmoins ce sont ces règles que valide la maîtrise d’œuvre dans les entreprises, quitte à ce que celle-ci apprenne à lire un MCD, ce qui d’expérience va vite, car les gens aiment généralement les bandes dessinées. Ces règles de gestion ont pour source les différents documents qu’on vous a remis, ainsi que les entretiens que vous aurez eus avec les utilisateurs et pas seulement la maîtrise d’œuvre ou la maîtrise d’ouvrage.

Exemple (il est sous-entendu que vous avez fourni par ailleurs un dictionnaire des données expliquant chacun des termes utilisés ci-dessous : activité sportive (sport), animateur, adhérent, lieu, séance, etc.) :

RG001 - Une activité sportive est dirigée par au moins un et au plus un animateur.
...
RG123 - La direction d’une activité sportive requiert de la part des animateurs les compétences (formations) requises.
...
RG314 - A un instant donné un lieu ne peut être affecté qu’à une seule séance.
...

Vous remarquerez que la règle RG123 est ambiguë : si on associe 3 formations f1, f2, f3 au sport s1 (entité-type SF), pour diriger s1 un animateur doit-il être formé à f1 et f2 et f 3 ? Suffit-il qu’il soit formé à f1 ou f2 ou f3 ? Selon nos MCD, c’est la 2e hypothèse qui a été retenue, mais est-ce la bonne ? Dans ce genre de situation il est nécessaire de demander à l’utilisateur de trancher afin de clarifier la règle.

Verba volant, scripta manent : tout cela fait l’objet du dossier de conception détaillé (lequel est un zoom du dossier de conception générale qui synthétise le sujet dont on traite : « Gestion d’un complexe sportif »).

- Une seule Séance dans un Lieu donné à un moment t.

D’accord. Ceci fait donc l’objet de la règle RG314.

- Les formations ne correspondront qu'aux sports proposés.

D’accord. A noter que si un animateur a des formations supplémentaires, la base de données n’en aura pas connaissance. J’en déduis que si un jour on ajoute une formation f8 à un sport donné (entité-type SF), il faudra compléter ASF pour les animateurs ayant cette formation, sachant que cela ne pourra être fait que manuellement, puisque jusque-là f8 n’existe nulle part dans la base de données.

Pour l'attribut Période dans l'entité Séance, si je souhaite établir un planning sera-t-il possible de manipuler l'attribut pour en extraire individuellement date et heures ? Car j'avais également penser à retirer heure_deb et heure_fin de Séance pour rajouter une entité Créneau avec ces même attributs qui serait reliée à Séance via l'association Pendant.

En relationnel pur, vous définiriez sans difficulté votre propre type PERIODE sur la base DATE, TIME et vous coderiez ensuite :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
VAR SEANCE BASE RELATION
    {
        L      INTEGER
      , P      PERIODE  
      , S      INTEGER
      , A      INTEGER
      , F      INTEGER
    }  
    KEY {L, P}
    KEY {A, P}
    FOREIGN KEY {L} REFERENCES LIEU
    FOREIGN KEY {A, S, F} REFERENCES ASF ;

Dans cette affaire, la 1re clé {L, P} garantit que dans un lieu donné, à un instant donné, il ne peut y avoir qu’un animateur. La 2e clé {A, P} garantit qu’à un instant donné un animateur ne peut se trouver que dans un seul lieu.

Il est évident que si l’on construit soi-même le type PERIODE on doit prévoir les opérateurs permettant d’extraire, plus généralement d’en manipuler les éléments que sont la date et l’heure. Dans le cas de la théorie relationnelle, tout est prévu, voyez par exemple chez Darwen.

Quand vous allez passer à SQL, tout dépendra de votre SGBD (au fait, quel est-il ?), mais en général les choses se compliquent et ça finit par tenir du parcours du combattant...

Selon la norme SQL 2011, on doit pouvoir coder à peu de choses près ainsi (sans garantie, de ma part, j’essaie de rester dans l’esprit de la norme) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE SEANCE (
    L                    INT                  Not null,
    DateSeance           DATE                 Not null,
    HeureDebut           TIME                 Not null,
    HeureFin             TIME                 Not null,
    PERIOD FOR P (HeureDebut, HeureFin),
    S                    INT                  Not null,
    A                    INT                  Not null,
    F                    INT                  Not null,
   CONSTRAINT SEANCE_K1 PRIMARY KEY (L, DateSeance, P WITHOUT OVERLAPS),
   CONSTRAINT SEANCE_K2 UNIQUE (A, DateSeance, P WITHOUT OVERLAPS),
   CONSTRAINT SEANCE_LIEU_FK FOREIGN KEY (L) REFERENCES LIEU, 
   CONSTRAINT SEANCE_SAF_FK FOREIGN KEY (A, S, F) REFERENCES ASF) ;

Où P est un intervalle, en l’occurrence horaire et l’on demande au système, au moyen de la clause WITHOUT OVERLAPS, de s’assurer que l’heure de début et l’heure de fin ne se chevauchent pas. Avec la clé SEANCE_K1, dans le lieu l1, à la date d1 et durant la période p1 il ne peut y avoir qu’un animateur. De même, avec la clé SEANCE_K2, à la date d1 et durant la période p1, l’animateur a1 ne peut se trouver que dans un seul lieu.

Les SGBD du commerce commencent à s’y mettre (voyez ici et là), mais pour le moment, vous aurez peut-être à vous contenter de coder :

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
CREATE TABLE SEANCE (
    L                    INT                  Not null,
    DateSeance           DATE                 Not null,
    HeureDebut           TIME                 Not null,
    HeureFin             TIME                 Not null,
    S                    INT                  Not null,
    A                    INT                  Not null,
    F                    INT                  Not null,
   CONSTRAINT SEANCE_PK PRIMARY KEY (L, DateSeance, HeureDebut),
   CONSTRAINT SEANCE_AK1 UNIQUE (L, DateSeance, HeureFin),
   CONSTRAINT SEANCE_AK2 UNIQUE (A, DateSeance, HeureDebut),
   CONSTRAINT SEANCE_AK3 UNIQUE (A, DateSeance, HeureFin),
   CONSTRAINT SEANCE_LIEU_FK FOREIGN KEY (L) REFERENCES LIEU, 
   CONSTRAINT SEANCE_SAF_FK FOREIGN KEY (A, S, F) REFERENCES ASF, 
   CONSTRAINT SEANCE_CHK1 CHECK (HeureDebut < HeureFin),
   CONSTRAINT SEANCE_CHK2 CHECK (HeureDebut >= '09 :00 :00'),
   CONSTRAINT SEANCE_CHK3 CHECK (HeureFin <= '21 :00 :00')) ;

Sachant que garantir le non chevauchement des périodes est à votre charge, ce qui pourra être automatisé (c'est-à-dire ne pas avoir à être fait au sein des programmes) au moyen des triggers. Quoi qu’il en soit, avec les contraintes SEANCE_CHK1, SEANCE_CHK2 et SEANCE_CHK3 vous pouvez garantir certaines contraintes élémentaires.

Cas de l’entité-type CRENEAU : le non chevauchement des périodes restera de toute façon à votre charge et vous devrez prévoir toutes les périodes possibles pouvant être requises par SEANCE. Cette entité-type peut être intéressante si elle vous permet de contrôler plus finement la validité des périodes.

Quels attributs mettriez-vous dans ASF et SF ?

Aucun ! Comme je l’ai mentionné à propos de l’identification relative (voyez le schéma dans mon message précédent), ces entités-types faibles (qui ne sont que des associations déguisées puisque Merise interdit les associations entre associations, cf. le bricolage que j’ai fait dans votre schéma) héritent des identifiants des entités-types plus fortes dont elles dépendent. Lors de la production du MLD, l’AGL a pour mission de générer les attributs nécessaires et suffisants dans les tables SF et ASF :



A noter que dans le MLD, les mickeys <pk> <ak> et <fk> sont synonymes respectivement de « primary key », « alternate key » et « foreign key ».
Ainsi, concernant la table SEANCE, vous retrouvez les clés définies dans le code SQL ci-dessus (CREATE TABLE SEANCE).

PowerAMC a correctement fait son boulot, je n’ai eu à ajouter aucun attribut manuellement dans le MLD. Ainsi, dans le MCD, seul l'attribut P était présent dans l'entité-type SEANCE.

Le but serait de proposer deux types d'abonnement à prix fixe (1 abonnement pour un unique sport au choix à par exemple 10euros, et 1 abonnement recouvrant tous les sports pour 80€)

Pas de possibilité de s’abonner uniquement pour deux sports ?

N'oubliez pas de voter pour les discussions qui ont pu vous être utiles.

[R00t_infinity]

Bonjour,

Merci encore pour votre réponse détaillée.
En ce qui concerne l'abonnement j'ai choisis ce mode économique de manière purement arbitraire en essayant d'en faire un simple ceci n'entrant pas en "première ligne" des objectifs,c'est juste un plus. Mais si vous avez une implémentation qui autorise 1,2 ou tous les sports comme type d'abonnement je suis preneur.

Merci encore !

[fsmrel]

Bonsoir R00t_infinity,

Mais si vous avez une implémentation qui autorise 1,2 ou tous les sports comme type d'abonnement je suis preneur.

Il y a vraisemblablement quelques scénarios pour y parvenir. Je propose celui-ci :

Spécialisons les adhérents en :

— Adhérents ayant payé la cotisation leur permettant de s’inscrire aux séances planifiées pour n’importe quel sport (sous-type ADHERENT_A_TOUT) ;
— Adhérents n’ayant cotisé que pour certains sports (sous-type ADHERENT_A_PARTIE).

L’entité-type ADHERENT_A_TOUT peut être directement mise en relation avec l’entité-type SEANCE (association CP).

Dans l’autre cas, grâce à l’entité-type CS on restreint aux sports pour lesquels un adhérent a cotisé. C’est l’association CSP qui permettra de savoir quelles sont les séances auxquelles un adhérent a eu le droit de s’inscrire.

Mais attention, selon le MCD, bien qu’il n’ait pas cotisé pour le sport s7, l’adhérent c1 peut participer à la séance prévue dans le lieu l1 durant la période p1 et dévolue au sport s7.

On doit donc prévoir une contrainte interdisant cette situation illégale :

CSP {L, P, S} ⊂ SEANCE {L, P, S}

C'est une contrainte d’inclusion exprimée en Tutorial D (le langage de référence de la théorie relationnelle), selon laquelle :

La projection sur les attributs L, P, S de la variable relationnelle CSP doit être un sous-ensemble de la projection sur les attributs L, P, S de la variable relationnelle SEANCE.

MCD :




MLD :

Il faut aussi veiller à ce qu’un adhérent ne fasse partie que d’une sous-classe :

ADHERENT_A_TOUT{C} ∩ ADHERENT_A_PARTIE{C} = ∅

Dans le contexte SQL, ces deux contraintes font l’objet d’assertions, mais en général les SGBD commerciaux ne proposant pas l’instruction qui va bien (CREATE ASSERTION), on se rabat sur des triggers.

Au fait, quel est (sera) votre SGBD ?

A suivre.

[R00t_infinity]

Bonjour,

Je n'avais effectivement pas penser à séparer les adhérents en deux directement...
Quand au SGBD nous avons à disposition MySQL (phpMyAdmin). En revanche nous n'avons pas abordé l'utilisation de trigger pour le moment (je en sais pas si nous le ferons) pourriez vous me donner un exemple correspondant au dernier post ? En SQL ou les manips interface de phpmyadmin si cela est réalisable de cette manière.

Merci encore.
Bonne journée.

[fsmrel]

Bonsoir R00t_infinity,


Je ne connais pas phpMyAdmin et je n’ai pas MySQL... Le trigger qui suit vaut seulement pour MS SQL Server qui utilise des triggers INSTEAD OF. Il faut l'adapter en remplaçant la 1re ligne de l’instruction CREATE TRIGGER que j’ai codée par quelque chose comme :

Code SQL :

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

1
2
CREATE TRIGGER CHK01 BEFORE INSERT ON CSP
    FOR EACH ROW...

Etc. Même chose avec UPDATE.

Avec SQL Server, « INSERTED » est une table temporaire contenant les nouvelles lignes candidates à l’insertion dans la table CSP. Dans le cas de MySQL qui ne traite pas au niveau de l’ensemble mais de la ligne et si j’ai bien compris, le contenu de chaque ligne de l’équivalent de cette table est présenté au niveau de chaque colonne (voir NEW_col dans la doc).

Quoi qu’il en soit... Cas de la contrainte d’inclusion avec SQL Server :

CHK01 — CSP {L, P, S} ⊂ SEANCE {L, P, S}

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
19
20
CREATE TRIGGER CHK01 ON CSP INSTEAD OF INSERT, UPDATE AS
       DECLARE @N AS INT
 
SET @N = (SELECT COUNT(*) 
          FROM      
             (SELECT L, P, S
              FROM   INSERTED
             EXCEPT 
              SELECT L, P, S
              FROM   SEANCE
             ) AS x
        )    
IF @N > 0 
    BEGIN
        RAISERROR ('Un adhérent ne peut pas participer à une séance s’il n’a pas cotisé pour le sport qui y est pratiqué...',15,1) 
    END
ELSE
    BEGIN
        INSERT INTO CSP SELECT * FROM INSERTED
    END ;

Concernant la contrainte d’exclusion :

CHK02 —ADHERENT_A_TOUT{C} ∩ ADHERENT_A_PARTIE{C} = ∅

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
19
CREATE TRIGGER CHK02 ON ADHERENT_A_PARTIE INSTEAD OF INSERT, UPDATE AS
       DECLARE @N AS INT
SET @N = (SELECT COUNT(*) 
          FROM      
             (SELECT C
              FROM   INSERTED
             INTERSECT 
              SELECT C
              FROM   ADHERENT_A_TOUT
             ) AS x
        )    
IF @N > 0 
    BEGIN
        RAISERROR ('Un adhérent ne peut pas à la fois être cotisant à tout et en partie...',15,1) 
    END
ELSE
    BEGIN
        INSERT INTO ADHERENT_A_PARTIE SELECT * FROM INSERTED
    END ;

Pour des raisons de symétrie et ne as faire de jaloux... :

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
19
CREATE TRIGGER CHK03 ON ADHERENT_A_TOUT INSTEAD OF INSERT, UPDATE AS
       DECLARE @N AS INT
SET @N = (SELECT COUNT(*) 
          FROM      
             (SELECT C
              FROM   INSERTED
             INTERSECT 
              SELECT C
              FROM   ADHERENT_A_PARTIE
             ) AS x
        )    
IF @N > 0 
    BEGIN
        RAISERROR ('Un adhérent ne peut pas à la fois être cotisant en partie et à tout....',15,1) 
    END
ELSE
    BEGIN
        INSERT INTO ADHERENT_A_TOUT SELECT * FROM INSERTED
    END ;

[R00t_infinity]

Un grand merci pour tout, je pense avoir tout ce dont j'ai besoin pour peaufiner mon MCD et l'implémenter. Je reviendrais poster une conclusion d'ici une semaine en cas de nouvelles questions ou tout simplement pour un bilan.

Merci encore. Bonne journée.