Discussion :

[Jekyll82]

J'ai un peu de misère a placer mon entité trimestre, la contrainte est que les installations extérieures sont fermées pour le trimestre d'hiver et les cours changent à chaque trimestre, donc comment relier le tout ?

[escartefigue]

Bonjour,

Présenté comme ça, je n'ai pas l'impression que le trimestre soit un acteur de votre modèle conceptuel, ce n'est pas un objet de gestion, mais plutôt un critère qui interviendra dans les traitements.

[Paprick]

Bonjour,

Au-delà de votre question, je m'inquiète de voir l'association "Concerne" contenant des rubriques (journée, heure) alors qu'elle possède des cardinalités 1,1/O,N...
Pas d'identifiant pour la classe "Activité"...
Il faudrait finaliser un peu plus ce MCD et définir les règles de gestion avant d'aller plus loin.

[Jekyll82]

Effectivement j'étais plus à me casser la tête avec le trimestre que finaliser les attributs et identifiants.

Donc si je comprend bien, je n'ai pas à faire quoique ce soit avec trimestre pour le moment ?

[Paprick]

Finalisez le MCD de base : nous regarderons cette histoire de trimestre ensuite.

[Jekyll82]

Donc comme ça et je ne me soucie pas du trimestre malgré le fait que ça implique que les cours changent et que les installations peuvent être fermées pour le trimestre d'hiver ?

[escartefigue]

Bonsoir Jekyll82

Difficile de critiquer un MCD sans avoir la liste des règles de gestion.
On ne peut faire que des remarques d'ordre général, et poser des questions, parmi lesquelles :

C'est quoi une "installation" ?

Votre modèle permet à un même instructeur de donner deux cours simultanément, est-ce volontaire ?

Votre modèle interdit de connaître un instructeur qui n'a encore jamais donné de cours, est-ce normal ?

Votre modèle interdit qu'un cours (notez que cours prend un "s" ) soit donné par plusieurs instructeurs, n'y a-t-il aucun cours pluridisciplinaire ou animé par plusieurs instructeurs ?

etc.

Autant d'interrogations qui seraient levées si les règles de gestion étaient fournies

[Jekyll82]

Je vous remercie d'avoir posé des questions, effectivement ca remet les choses en perspective, donc j'ai finalisé un peu plus et j'ai ca :

Le client C s'inscrit dans le cours C donné par l'instructeur I qui concerne l'activité A et se déroule pour une date donnée dans l'installation sportive S
Le client C participe à l'activité A qui se déroule dans l'installation sportive S pour une date donnée
Le client C réserve l'installation S pour une date donnée

Chaque cours ne concerne qu'une seule activité
Le cours C est donné par l'instructeur I mais en cas d'absence il peut être donné par l'instructeur J

L'instructeur I donne le cours C mais peut aussi donner le cours D

L'activité A est enseignée dans le cours C mais aussi dans le cours D
L'activité A se déroule dans l'installation gymnase S et peut aussi se dérouler dans l'installation gymnase T

Il y a des installations intérieures ouvertes à l'année mais les installations extérieures sont fermées durant le trimestre d'hiver



J'ai toujours de la misère avec le concept de temps ... est-ce que l'entité Date est au on endroit si j'en ai besoin pour que les activités ne rentre pas en conflit d'horaire avec les réservations des clients ?

[fsmrel]

Bonsoir Jekyll,


Vous avez écrit :

« Le client C réserve l'installation S pour une date donnée »

Mais selon votre MCD, deux clients peuvent réserver la même installation au même moment.

Pour qu’à une date donnée une installation ne puisse être réservée que pour un et un seul client, il faut mettre en oeuvre une CIF (contrainte d’intégrité fonctionnelle), comme ci-dessous :

Pour parvenir à cela il faut que vous utilisiez l’excellent Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci mille fois Paprick !)

Notez que dans le diagramme le nom de l’entité-type DATE_X est mis entre parenthèses ⁽¹⁾, ce qui a pour conséquence qu’au stade SQL il n’y aura pas de table DATE_X, laquelle serait un boulet, surtout si 1000 tables y faisaient référence (combien de bases de données ai-je nettoyées chez mes clients pour y supprimer la table DATE !) En revanche, Looping n’oublie évidemment pas de définir un attribut uneDate pour la table RESERVER.


Avec Looping, vous obtenez le code SQL qui va bien (pas de table DATE !) :

CREATE TABLE INSTALLATION
(
   idInstall INT,
   nomInstall VARCHAR(50) NOT NULL,
   CONSTRAINT INSTALLATION_PK PRIMARY KEY(idInstall),
   CONSTRAINT INSTALLATION_AK UNIQUE(nomInstall)
);

CREATE TABLE CLIENT
(
   idClient INT,
   nomClient VARCHAR(50) NOT NULL,
   CONSTRAINT CLIENT_PK PRIMARY KEY(idClient)
);

CREATE TABLE RESERVER
(
   idInstall INT,
   uneDate DATE,  
   idClient INT NOT NULL,
   CONSTRAINT RESERVER_PK PRIMARY KEY(idInstall, uneDate),
   CONSTRAINT RESERVER_INSTALLATION_FK FOREIGN KEY(idInstall) REFERENCES INSTALLATION(idInstall),
   CONSTRAINT RESERVER_CLIENT_FK FOREIGN KEY(idClient) REFERENCES CLIENT(idClient)
);

A propos des CIF, je vous engage aussi à lire ce qu’écrivent D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au chapitre 7 (« Modélisation conceptuelle des données », paragraphe « Contraintes intra-relation », pages 114 et suivantes.

____________________

⁽¹⁾ Dans la fenêtre Entité, cocher la case « Classe d’entité fictive ».

[fsmrel]

Bonjour Jekyll,

En attendant...

Il y a deux façons d’associer CLIENT vers ACTIVITE :

a) via l’association Participe,

(b) transitivement via les associations s’inscrit et Concerne.

Il y a là ce qu’on appelle une boucle (c’est parfois cause d’erreurs) et cela conduit à poser certaines questions :

(Q1) Un client peut-il participer à une activité sans être inscrit à des cours concernant cette activité ?

(Q2) Si un client est inscrit à des cours, peut-on en conclure qu’il participe forcément aux activités concernées par ces cours ?

[Jekyll82]

Activité est plus comme "le sport", ne pas voir comme activité bricolage par exemple. Donc l'activité volleyball, soccer, natation ....

Le client peut s'inscrire à l'activité seule, exemple le client s'inscrit à l'activité volleyball le mercredi soir et peut aussi s'inscrire à un cours sur le volleyball

Et les cours concernent tous une activité, donc quand il s'inscrit à un cours ça concerne nécessairement une activité



Je viens de télécharger le logiciel looping, par contre du moment que je met une CIF je suis incapable de faire des liens vers quoique ce soit ...

[Paprick]

Bonsoir,

Je viens de télécharger le logiciel looping, par contre du moment que je met une CIF je suis incapable de faire des liens vers quoique ce soit ...

Après avoir créé la CIF, vous devez tout d'abord la lier à l'association pivot.
Puis, vous pouvez effectuer le lien vers la classe d'entités cible, puis les classes d'entités émettrices.

[Jekyll82]

Bonsoir,

Après avoir créé la CIF, vous devez tout d'abord la lier à l'association pivot.
Puis, vous pouvez effectuer le lien vers la classe d'entités cible, puis les classes d'entités émettrices.

Merci infiniment !

[Jekyll82]

C'est toujours la que je bloque, si j'ai besoin d'un calendrier. Pour l'inscription d'un client a un cours, pour la participation d'un client à une activité ou encore pour la réservation d'une installation. Est-ce que j'ai besoin d'un calendrier pour chaque ou un seul peut faire tout ca.

Parce que si un cours se donne, l'installation ne doit pas être accessible pour une réservation, même chose si une activité a lieu, l'installation n'est pas disponible pour un cours ou pour une réservation ....

[escartefigue]

Attention, il ne faut pas confondre un simple attribut de type date comme dans le cas de la date d'inscription d'un client à un cours, avec une date qui participe comme type d'entité à une d'association.

Dans le premier cas, l'attribut date est simplement placé dans l'association (puisque c'est une association naire de chaque côté) dans l'autre, on utilise une entité-type pour que la date contribue à l'identification de chaque occurrence de l'association.

Au niveau tabulaire, on a dans le premier cas :
table INSCRIRE (association client cours) : identifiant du client et identifiant du cours constituent la PK, date d'inscription est un simple attribut

Et dans le deuxième cas :
table RESERVER (association client, installation, date) : identifiant de l'installation + date constituent la PK, identification du client est un simple attribut pour garantir l'unicité du client pour la PK