Discussion :

[Jekyll82]

Voila, j'ai un problème en différentes étapes pour la gestion d'un centre sportif.

J'ai extraits les règles suivantes :

1. Le centre sportif compte sur une équipe d’instructeurs 2. Le centre sportif regroupe un ensemble d’installation 3. Les installations intérieures sont ouvertes à l’année 4. Les installations extérieures sont fermées durant le trimestre d’hiver 5. Un age minimal est exigé pour l’utilisation de certaines installations 6. Chaque installation a une capacité max 7. Chaque installation appartient à un type d’installation 8. L e centre propose différentes activités 9. Chaque activité peut être pratiquée dans un type d’installation 10. Le centre offre à chaque trimestre des cours de groupe 11. Le cours concerne 1 activité 12. Chaque cours est offert 1 fois par semaine à durée fixe 13. Chaque cours est identifié par un code unique 14. Une restriction d’âge peut s’applique pour chaque cours 15. Pour chaque cours un nombre de place maximal est déterminé 16. Pour chaque cours un instructeur est attitré 17. Un instructeur peut donner plusieurs cours différent 18. Une personne peut s’inscrire à plusieurs cours 19. Les adultes peuvent réserver une installation 20. Chaque réservation est d’une durée de 1 heure pour une date donnée

ensuite j'ai extraits les attributs suivants :

A) numInstructeur B) nomInstructeur C) numInstallation D) nomInstallation E) capaciteMax F) ageMin G) numActivite H) nomActivite I) codeTrimestre J) codeCours K) nomCours L) dateCours M) restrAge N) nbPlaces O) numClient P) nomClient Q) prenomClient R) adresseClient S) dateNaissClient T) numTelClient U) dateReservation V) numReservation W) typeInstallation X) int/ext

J'ai les DF suivantes :

(A -> B) numInstructeur -> nomInstructeur (C -> D) numInstallation-> nomInstallation (C -> E) numInstallation-> capaciteMax (C -> F) numInstallation-> ageMin (C -> W) numInstallation-> typeInstallation (G -> H) numActivite -> nomActivite (G -> W) numActivite -> typeInstallation (J -> K) codeCours -> nomCours (J -> L) codeCours -> dateCours (J -> M) codeCours -> restrictionAge (J -> N) codeCours -> nbPlaces (J -> G) codeCours -> numActivite (J -> A) codeCours -> numInstructeur (J -> I) codeCours -> nomTrimestre (O -> P) numClient -> nomClient (O -> Q) numClient -> prenomClient (O -> R) numClient -> adresseClient (O -> S) numClient -> dateNaissClient (O -> T) numClient -> numTelClient (W -> X) typeInstallation -> int/ext (C, O, U -> V) numClient, numInstallation, dateReservation -> numReservation

Et les fermetures transitives suivantes :

G -> W -> X donc G -> X J -> G -> H donc J -> H J -> G -> W donc J -> W J -> G -> W -> X donc J -> X J -> A -> B donc J -> B C -> W -> X donc C -> X

La je rush à trouver la couverture minimale ... il me semble que partout ou je vois des exemples il y a beaucoup 2 attributs déterminent un autre mais moi j'ai presque juste des éléments simple ... est-ce que je fais fausse route ?





Et j'ai fait ça comme schéma ... est-ce que ça vous semble bon ?

[Paprick]

Bonjour,
Sans rentrer, pour l'instant, sur le fond de votre modèle, trois petites remarques :

• La classe d'entités "Trimestre", qui ne contient que le code de trimestre, ne me semble pas nécessaire compte-tenu des cardinalités 1,1---0,n : autant mettre ce code trimestre directement dans la classe d'entités "Cours".
• La classe d'entités "UneReservation" (qui pourrait s'appeler "Calendrier") ne contient que des dates (à mon avis, il s'agit même de dates-heures) qui vont se retrouver, au niveau MLD, en tant que composante de la clé primaire de la table d'association "Client_Installation" : comme la future table "UneReservation" n'a donc aucune raison d'exister dans le schéma relation de la BD, vous pouvez la déclarer "Fictive" (cf. case à cocher proposée par Looping).
• Un client peut-il réserver plusieurs installations à la même date-heure ? Si ce n'est pas le cas, il y a un problème de clé minimale et la clé étrangère issue de la table "Installation" doit être exclue de la clé primaire de "Client_Installation" par une CIF. D'ailleurs, compte-tenu de la présence de "numReservation" qui pourrait probablement faire office de clé primaire, n'est-il pas préférable de transformer "Client-Installation" en une classe d'entités "Réservation" ?

Voilà pour ces premières remarques ; mes collègues ne manqueront pas d'en rajouter .

[Jekyll82]

dans le fond si je comprend bien je peux tout simplement créer une table réservation et le faire comme suit :

[fsmrel]

Bonsoir Jekyll,


A propos des réservations

Question 1 : un client peut-il effectuer plus d’une réservation d’installations pour la même date et la même heure ? Si la réponse est négative, il faudra mettre en oeuvre une CIF traduisant la DF (au sens Merise) :

CLIENT X DATE → INSTALLATION

Dans ces conditions, au stade SQL la paire {numClient, date_heure} est clé candidate de la table RESERVATION (et l’attribut numReservation ne sert à rien).

Question 2 : une installation peut-elle faire l’objet de réservations par plus d’un client pour la même date et la même heure ? Si la réponse est négative, il faudra mettre en oeuvre une CIF traduisant la DF (au sens Merise) :

INSTALLATION X DATE → CLIENT

Dans ces conditions, au stade SQL la paire {numInstallation, date_heure} est clé candidate de la table RESERVATION (et l’attribut numReservation ne sert à rien).

Si les réponses aux deux questions sont positives, la paire {numClient, numInstallation} est clé candidate de la table RESERVATION (et là encore l’attribut numReservation ne sert à rien).

Dans tous les cas l’entité-type RESERVATION n’est jamais qu’une association entre CLIENT et INSTALLATION, et donc à identifier relativement à ces deux entités-types (l’attribut numReservation ne sert alors à rien, il faut l’éliminer).

[Paprick]

Bonjour,
Je suis totalement d'accord avec l'approche CIF de fsmrel.
Il y a toutefois un point important à traiter : est-ce que le numéro de réservation est une information issue de l'analyse du système d'information, ou a-t-il été rajouté pour les besoins du système informatique ?
Dans le premier cas, il est légitime de le conserver (et de s'en servir éventuellement d'identifiant s'il est pérenne) ; sinon, il ne faut effectivement pas le créer à seules fins d'identification technique, et donc utiliser alors les identifiants de client, installation et la date pour construire l'identifiant qui va bien (en faisant un bon usage des CIF).

[Jekyll82]

Effectivement j'avais rajouté numReservation seulement pour avoir un identifiant unique
Mais je peux l'enlever.
Et alors quand je passe en UML çca donnerait quelque chose du genre ?

[Paprick]

Bonsoir,
Comme indiqué précédemment, vous devez exclure numClient de l'identifiant de Réservation.
Si nécessaire, redonnez-nous votre modèle sous forme de schéma E/A pour qu'on vous indique comment faire.

[fsmrel]

Bonsoir,

Jekyll, je vous ai posé deux questions précises, quelles sont vos réponses ?

[Jekyll82]

Effectivement le numéro de réservation a été ajouté seulement pour avoir un identifiant unique
Donc non le client ne peut pas réserver plus d'une installation pour la même date et heure.
Et effectivement une installation ne peut pas faire l'objet d'une réservation par plus d'un client.

Bonsoir Jekyll,


A propos des réservations

Question 1 : un client peut-il effectuer plus d’une réservation d’installations pour la même date et la même heure ? Si la réponse est négative, il faudra mettre en oeuvre une CIF traduisant la DF (au sens Merise) :

CLIENT X DATE → INSTALLATION

Dans ces conditions, au stade SQL la paire {numClient, date_heure} est clé candidate de la table RESERVATION (et l’attribut numReservation ne sert à rien).

Question 2 : une installation peut-elle faire l’objet de réservations par plus d’un client pour la même date et la même heure ? Si la réponse est négative, il faudra mettre en oeuvre une CIF traduisant la DF (au sens Merise) :

INSTALLATION X DATE → CLIENT

Dans ces conditions, au stade SQL la paire {numInstallation, date_heure} est clé candidate de la table RESERVATION (et l’attribut numReservation ne sert à rien).

Si les réponses aux deux questions sont positives, la paire {numClient, numInstallation} est clé candidate de la table RESERVATION (et là encore l’attribut numReservation ne sert à rien).

Dans tous les cas l’entité-type RESERVATION n’est jamais qu’une association entre CLIENT et INSTALLATION, et donc à identifier relativement à ces deux entités-types (l’attribut numReservation ne sert alors à rien, il faut l’éliminer).

donc si j'ai bien compris vos explications, avec les CIF ca donne quelque chose comme ca ? (mais je ne suis pas sur de l'orientation des fleches pour la cible et l'entité émettrice.

[fsmrel]

Bonsoir Jekyll,

Effectivement le numéro de réservation a été ajouté seulement pour avoir un identifiant unique
Donc non le client ne peut pas réserver plus d'une installation pour la même date et heure.
Et effectivement une installation ne peut pas faire l'objet d'une réservation par plus d'un client.

Vous répondez donc négativement aux deux questions posées, d’accord. Toutefois votre diagramme ne traduit pas ce qui est attendu.

Considérons en effet la 1re DF que j’ai présentée dans le post #4 :

CLIENT X DATE → INSTALLATION

Dans le MCD, cela veut dire qu’il doit y avoir les trois entités-types citées, CLIENT, DATE et INSTALLATION, participant à la même association, appelons-la RESERVATION (dans le jargon, CLIENT, DATE et INSTALLATION constituent le pivot de la CIF à mettre en oeuvre tandis que l’association RESERVATION en constitue la portée). Dans votre MCD, il manque l’entité-type DATE, donc malgré vos efforts louables, votre CIF à laquelle participe l’association — seulement binaire — CLIENT_RESERV, ayant pour source CLIENT et pour cible RESERVATION est en l’occurrence inefficace, c’est un cautère sur une jambe de bois. En ce qui concerne la CIF attendue, la partie gauche de la DF, composée de la paire {CLIENT, DATE} en constitue la source et la partie droite, composée du singleton {INSTALLATION} doit en constituer la cible. Tout cela est à modéliser ainsi :

Dans un 1er temps, modéliser le pivot de la CIF, c’est-à-dire le triplet d’entités-types CLIENT, INSTALLATION et DATE (renommée ci-dessous CALENDRIER) ainsi que l’association impliquée par ce pivot :

A noter que l’entité-type CALENDRIER est fictive (nom mis entre parenthèses), car il est inutile dans la base de données d’avoir l’ensemble des jours de chaque année...

Noter aussi que pour rendre une entité-type fictive, dans la fenêtre Entité de Looping correspondante, il suffit de cocher la case « Classe d’entités fictive ».


Dans un 2e temps, faire figurer le cercle (l’icône) « CIF » et tracer le lien entre ce cercle et la portée (l’association RESERVATION) :

Dans un 3e temps, tirer le lien entre le cercle « CIF » et la cible (l’entité-type INSTALLATION) :

Dans un 4e temps, compléter avec les liens entre le cercle « CIF » et la source, composée des entités-types CLIENT et CALENDRIER :

Au résultat, en SQL la table RESERVATION a pour clé primaire la paire {idClient, dateHeure} :

CREATE TABLE RESERVATION
(
   idClient INT,
   dateHeure DATE,
   idInstall INT NOT NULL,
   CONSTRAINT RESERVATION_PK PRIMARY KEY(idClient, dateHeure),
   CONSTRAINT RESERVATION_CLIENT_FK FOREIGN KEY(idClient) 
       REFERENCES CLIENT(idClient),
   CONSTRAINT RESERVATION_INSTALLATION_FK FOREIGN KEY(idInstall) 
       REFERENCES INSTALLATION(idInstall)
);

Le procédé de construction est le même en ce qui concerne la 2e CIF, correspondant à la DF

INSTALLATION X DATE → CLIENT

Et la table RESERVATION comporte une clé supplémentaire (alternative), RESERVATION_AK :

CREATE TABLE RESERVATION
(
   idClient INT,
   dateHeure DATE,
   idInstall INT NOT NULL,
   CONSTRAINT RESERVATION_PK PRIMARY KEY(idClient, dateHeure),
   CONSTRAINT RESERVATION_AK UNIQUE(idInstall, dateHeure),
   CONSTRAINT RESERVATION_CLIENT_FK FOREIGN KEY(idClient) 
       REFERENCES CLIENT(idClient),
   CONSTRAINT RESERVATION_INSTALLATION_FK FOREIGN KEY(idInstall) 
       REFERENCES INSTALLATION(idInstall)
);

[Jekyll82]

Ok je comprend mieux maintenant ...
Juste pour éclaircir un point, quelle est la différence entre créer :

1) clé primaire IDCLIENT, DATEHEURE, IDINSTALL
2) clé primaire IDCLIENT, DATEHEURE et clé unique IDINSTALL, DATEHEURE

[fsmrel]

Bonsoir Jekyll,

Juste pour éclaircir un point, quelle est la différence entre créer :

1) clé primaire IDCLIENT, DATEHEURE, IDINSTALL
2) clé primaire IDCLIENT, DATEHEURE et clé unique IDINSTALL, DATEHEURE

La table RESERVATION contient 3 attributs (colonnes), idclient, dateheure, idinstall.

Quand je dis que la paire K1 = {idclient, dateheure} est clé primaire de RESERVATION, cela veut dire que K1 ne peut prendre que des valeurs uniques, par exemple :

<cli1, date1>
<cli1, date2>
<cli1, date3>
<cli2, date1>
<cli2, date2>
<cli2, date4>

Mais il est interdit d’avoir deux fois <cli1, date1> et autres paires dans RESERVATION.

Dans la théorie relationnelle, on dit que K1 est clé candidate de la relvar (variable relationnelle) RESERVATION, ou tout simplement que K1 est clé (KEY) de la relvar, voyez la figure A.1 de l’article.
De la même façon, la paire K2 = {idinstall, dateheure} est clé elle aussi de la relvar RESERVATION.

Par contre, le triplet K3 = {idclient, dateheure, idinstall} n’est pas clé de cette relvar, car K3 ne respecte pas la définition des clés candidates :

Une clé candidate est un sous-ensemble d’attributs K de l’en-tête d’une relvar R, respectant les deux règles suivantes :

Unicité. Deux tuples distincts de R ne peuvent avoir simultanément même valeur de K ;

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Les paires K1 et K2 respectent les deux règles, unicité et irréductibilité et sont donc des clés candidates de la relvar RESERVATION.

Le triplet K3 respecte la règle d’unicité, mais comme K1 et K2 en sont des sous-ensembles stricts, K3 viole la règle d’irréductibilité. Tout au plus K3 peut être qualifiée de surclé.

Côté SQL, K1 peut être élue Miss clé primaire, auquel cas K2 devient sa dauphine en tant que clé alternative (clause UNIQUE). Mais, toutes choses égales, c’est K2 qui peut très bien être élue Miss clé primaire, K1 devenant alors sa dauphine. En tout cas, K3 n’a aucun rôle à jouer dans cette affaire et doit passer à la trappe.

Cela dit, le langage SQL, avatar IBM du modèle relationnel de données n’est pas très regardant, et rien ne nous empêche de déclarer K3 comme dauphine supplémentaire (clause UNIQUE), ou encore de déclarer K3 comme étant Miss clé primaire, K1 et K2 étant alors à déclarer comme ses dauphines !

Pour la petite histoire : à l’origine (voir l’article fondateur de 1970 A Relational Model of Data for Large Shared Data Banks), le terme « clé primaire » faisait partie du vocabulaire du modèle relationnel de données, mais depuis une vingtaine d’années, seul reste le concept de clé (c’est-à-dire de clé candidate) et c’est effectivement largement suffisant.

En passant, Jekyll, vous ne levez plus le pouce ?

[Jekyll82]

Good, merci pour toutes ces explications surtout pour la règle d'irréductibilité.

Vous ne levez plus le pouces ... je comprend pas cette phrase par contre ! :p

[escartefigue]

@jekyll82 : n'oubliez pas d'approuver les réponses qui vous ont aidé en utilisant le bouton prévu à cet effet.

Les signes de reconnaissance font toujours plaisir

[fsmrel]

Bonsoir,

Heureusement qu’Escartefigue veille !