Discussion :

[bloups]

Bonjour tous le monde,

Je dois modéliser une base de données de billetterie en ligne mais c'est un peu confus pour moi.
Voici les maigres informations que j'ai à ma portée.

Les artistes sont décrits par un identifiant, un nom, une courte biographie et l'url de leur site web lorsqu'ils en possèdent un. Les salles de concert sont décrites à l'aide d'un code, d'une adresse et d'une liste de catégories de places (tribune, gradins, parterre...). La tournée d'un artiste consiste à définir les dates de passage de celui-ci dans une salle de concert ; la tournée est aussi décrite à l'aide d'un libellé et d'un court résumé. Si les prix d'un billet varient en fonction de l'artiste et de la catégorie de places, ceux-ci sont toutefois fixes pour toutes les dates où l'artiste se produit dans une même salle.

Pour moi, l'entité Concert n'a pas lieue d'être puisque qu'elle correspond je pense à l'association Jouer (car un code d'artiste + un code de salle + une date suffisent à déterminer un concert). Qu'en pensez-vous ?

Par contre, où mettre le prix du billet ?
Comment relier la tournée ?

Je me pose aussi une question concernant la catégorie de place. Comment le comprenez-vous? La logique voudrait qu'une salle puisse accueillir plusieurs catégories et ne soit pas limitée à une seule (d'où la création d'une entité Catégorie plutôt qu'un simple attribut dans SalleConcert)

Le sujet étant peu détaillé, je pense que des hypothèses sont indispensables.

Hypothèses :
- un artiste ne fait qu'un seul concert par jour dans une même salle
- il y a possibilité d'avoir une salle nouvellement construite (donc sans encore de concert)
- il y a possibilité d'avoir un artiste récemment découvert (et donc n'ayant jamais fait de concert)

Je présume que d'autres hypothèses sont à faire mais je ne vois pas lesquelles pour le moment.

NOTE : il s'agit d'un cas fictif, donc les hypothèses à prendre sont moins restrictives que si c'était un cas réel.

Merci d'avance pour vos éclaircissements


edit : j'ai oublié de préciser que je devais mettre en place un système de commentaires sur les concerts (pour que l'on puisse donner son avis, ce système étant sans login donc sans gestion de comptes utilisateurs).
En gros, je dois pouvoir :
- connaître les concerts ayant lieu dans une salle;
- connaître les dates décrivant la tournée d'un artiste ;
- accéder à la fiche d'un artiste ;
- réserver des billets ;
- donner son avis sur un concert et consulter ses avis

[fsmrel]

Bonjour,


J’ai vu après coup que vous parliez des réservations (votre edit en fin de message). En attendant de voir cela, voici déjà quelques propositions.

Dressons l’inventaire des entités-types autonomes, fortes (Kernels au sens de Codd, Regular entities au sens de Chen), c'est-à-dire celles dont l’existence ne dépend d’aucune autre entité-type. Elles sont les suivantes :

ARTISTE,
SALLE,
CATEGORIE (de places).

Il y a aussi les entités-types dites associatives, qui permettent de mettre en relation des entités-types (que ces dernières soient fortes ou non) :

TOURNEE, qui permet de mettre en relation un artiste et une salle, caractérisée par les propriétés suivantes : tarif journalier de l’artiste (en supposant que le tarif de l'artiste varie d'une salle à l'autre) et libellé (en supposant que le libellé de la tournée peut connaître des modifications d'une salle à l'autre).

CAT_PRIX, qui permet de mettre en relation une tournée d’un artiste et une catégorie de prix en fonction de la salle dans laquelle il se produit. Cette entité-type associative peut ne pas être mise en œuvre si on préfère établir directement une relation entre SALLE et CATEGORIE au moyen d’une entité-type associative (que l’on peut aussi appeler CAT_PRIX) qui au lieu d’être caractérisée par un prix, l’est par un coefficient tarifaire par catégorie de place permettant de calculer le prix d’une place en fonction de ce coefficient et du tarif journalier de l’artiste.

Il y a aussi les entités-types qui correspondent à des propriétés multivaluées d’autres entités-types (que ces dernières soient fortes, associatives, ou faibles) et l’on appelle entités-types faibles (Characteristics au sens de Codd, Weak entities au sens de Chen) :
CONCERT, qui est une propriété multivaluée de TOURNEE, et fournit les différentes dates auxquelles un artiste se produit dans une salle.

Exemple de représentation graphique (avec Workbench, gratuit) :


Ou bien si l’on utilise un coefficient par catégorie de place :


N.B. Les clés primaires sont symbolisées par des mickeys (clé jaunes). Les clés étrangères par des losanges rougeâtres. Si une clé étrangère est aussi primaire, le mickey est encore la clé jaune (exemple : l’attribut SalleId de l’entité-type (ou plutôt table) TOURNEE).

[bloups]

Merci beaucoup d'avoir pris le temps de me répondre.

Je dois avouer que j'ai du mal à bien comprendre votre schéma, n'ayant jamais présenté comme çà un MCD.

D'après ce que j'ai compris, vous proposez 3 classes d'entités (Artiste, Salle et Catégorie) et 2 classes d'associations (Tournee et Cat_Prix).

J'ai essayé de modéliser votre proposition de MCD sous Windesign mais je ne suis pas sûr de l'avoir fait correctement.

En effet, sur votre schéma, Cat_Prix est relié à Tournée, hors si j'ai bien compris, il s'agit tout deux d'associations, ce qui est alors impossible à relier sur un schéma entités/associations.
Un problème se porte aussi sur l'entité Concert qui semble avoir 2 clés étrangères et un attribut de date, hors on ne modélise pas les clés étrangères sur un MCD, du coup, est-ce vraiment une entité ?



Je me rend compte aussi qu'en fait, contrairement à ce que je disais au début concernant le login, une entité Client est indispensable pour réserver et pour un éventuel suivi des réservations précédentes, mais aussi pour afficher ses anciens commentaires.

Bref, pour ne rien vous cacher, je suis encore dans le flou

PS : j'ai conscience qu'il y a surement un problème avec les cardinalités. ^^

[fsmrel]

Je dois avouer que j'ai du mal à bien comprendre votre schéma, n'ayant jamais présenté comme çà un MCD.

Au vu de votre 1er MCD, je ne savais pas si vous utilisiez Win’Design (que je n’ai pas) ou Power AMC ou que sais-je. Pour ma part, je suis passé directement au niveau MLD après avoir utilisé un vocabulaire non merisien (entités-types fortes, associatives, faibles). Étant au niveau MLD, il est normal que les clés étrangères montrent le bout de leur nez...

Pour retrouver un MCD, il faudrait en passer par une rétro-conception, mais cela poserait quelques problèmes, car Merise (sauf Merise orienté objet) refuse d’associer des associations, ce qui complique singulièrement votre modélisation : en effet, si TOURNEE est une association-type, avec Merise CAT_PRIX ne peut pas être elle aussi une association-type.

Soit vous travaillez directement au niveau MLD, soit vous devez tricher et transformer TOURNEE en entité-type...

Je note que vous avez fait figurer le libellé de la tournée dans l’association-type TOURNEE. Vous confirmez donc que ce libellé peut varier selon la salle dans laquelle passe l’artiste. C’est bien cela ?

Question concernant les prix des places : le tarif d’un artiste dépend-il seulement de la tournée ou bien dépend-il aussi le la salle ?

Votre association-type CAT_PRIX est porteuse du prix de la place, mais indépendamment de la tournée : si donc l’artiste a1 passe dans la salle s1, alors le prix p1 pour la catégorie c1 sera toujours le même et ne pourra jamais varier dans le temps, quel que soit le concert.

La cardinalité 1,1 portée par la patte connectant votre entité-type CONCERT à TOURNEE ne fonctionne pas, car elle dit qu’une date de concert détermine un artiste : deux artistes ne peuvent pas être en concert le même jour... De même, à une date donnée il ne peut y avoir qu’une salle qui puisse accueillir un concert... En réalité, votre cardinalité 1,1 doit être remplacée par une cardinalité 1,N (ou plutôt 0,N) et il faut mettre en œuvre une CIF : ARTISTE X CONCERT → SALLE. Dans ces conditions, après dérivation en MLD, vous retrouverez ma table CONCERT et à condition en plus de ne pas considérer TOURNEE comme étant l’association-type connectant tout ce petit monde.

Il est temps manifestement de remettre tout à plat et de fournir la liste précise des règles de gestion des données telles que vous les entendez avant de représenter graphiquement les choses.

N’oubliez surtout pas de bien préciser noir sur blanc si le libellé d’une tournée peut varier d’une salle à l’autre, même chose pour le tarif journalier d’un artiste.

Ceci fait, je verrai à faire la rétro-conception de mon MLD en MCD pour vous faciliter la lecture.

Je me rend compte aussi qu'en fait, contrairement à ce que je disais au début concernant le login, une entité Client est indispensable pour réserver et pour un éventuel suivi des réservations précédentes, mais aussi pour afficher ses anciens commentaires.

On regardera cela une fois que reste sera stabilisé.

[bloups]

Je note que vous avez fait figurer le libellé de la tournée dans l’association-type TOURNEE. Vous confirmez donc que ce libellé peut varier selon la salle dans laquelle passe l’artiste. C’est bien cela ?

Merci d'avoir noter cette erreur de ma part. La nom de la tournée est le même pour toutes les dates d'un même artiste dans les différentes salles.
ex : « John Frankie World Tour » le 26/02 au Zenith de Toulouse, puis le 06/03 au Bataclan, ...
Il en va de même pour le résumé de la tournée.

Question concernant les prix des places : le tarif d’un artiste dépend-il seulement de la tournée ou bien dépend-il aussi de la salle ?

Concernant le tarif, celui ci varie en fonction de l'artiste et de la catégorie de places.
ex : une place pour les Rolling Stones en gradins ne coutera pas le même prix qu'une place pour le même concert en parterre ; qui ne coutera pas le même prix qu'une place pour Mickey 3D en parterre, etc...

"Le prix est cependant fixe pour toutes les dates où l'artiste se produit dans une même salle (cf. énoncé)."

Cette partie de l'énoncé est bizarre car si un artiste fait une tournée dans une salle à une date donnée, puis y revient 15ans après, le prix reste le même.
Je pense que celà doit être dans la limite des dates d'une même tournée (il faut donc un lien entre le prix et la tournée, le prix de chaque catégorie pouvant alors changer à chaque tournée de l'artiste).


Je voulais faire un MCD car la traduction en MLD est assez facile.
Mais je peux tenter de faire un MLD directement. Je tente une nouvelle approche (qui peut ma foi être fausse, j'en suis conscient ) :

SALLE(SalleID, SalleNom)
CATEGORIE(CategorieID, CategorieLibelle)
ARTISTE(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteURL)
TOURNEE(TourneeID, TourneeLibelle, TourneeResume)

CONCERT(ArtisteID#, ConcertDate, SalleID#, TourneeID#)
CAT_PRIX(ArtisteID#, SalleID#, CategorieID#, PrixPlace)

Le problème est que pour le moment, le prix n'est pas relié à la tournée et donc restera le même d'une tournée à l'autre (dans la même salle avec le même artiste).



Pensez-vous qu'il est judicieux de considérer qu'un concert puisse être joué par 1 ou plusieurs artistes ? (ex : Les enfoirés)

[JPhi33]

Bonjour,

J'interviens car j'ai "planché" moi aussi sur cet énoncé fort intéressant.

Tout d'abord, je confirme le point de vue de fsmrel : ce MCD ne peut pas être exprimé dans la forme traditionnelle Merise, ni même Merise/2. Il faudrait utiliser "Merise avancé" permettant l'association d'associations.

La nom de la tournée est le même pour toutes les dates d'un même artiste dans les différentes salles. ex : « John Frankie World Tour » le 26/02 au Zenith de Toulouse, puis le 06/03 au Bataclan, ... Il en va de même pour le résumé de la tournée.

Pour ma part, j'ai résolu ce point en décidant de faire de TOURNEE une entité faible de ARTISTE, identifiée, par conséquent, par ArtisteId et un identifiant propre a-significatif TournéeId :

Code :

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

1
2
3
4
5
6
7
ArtisteId   TournéeId   TournéeLibellé     TournéeRésumé

EDDYMITCH   1           Jambalaya          ...
EDDYMITCH   2           Grand Ecran        ...
ROLLINGST   1           Licks World Tour   ...
ROLLINGST   2           A Bigger Band      ...

"Le prix est cependant fixe pour toutes les dates où l'artiste se produit dans une même salle (cf. énoncé)."

Pour ce point, je rejoins la remarque de bloups : il faut bien faire des hypothèses car l'énoncé n'est pas parfait.

Hypothèses :
1) Le prix est cependant fixe pour toutes les dates où l'artiste se produit dans une même salle pendant la même tournée.
2) Il n'y a qu'un seul concert par jour dans une salle donnée (contrainte encore plus forte que la première hypothèse du premier message de bloups).


L'hypothèse 2 permet de définir une association CONCERT entre les entités DATE (dont on se passera aisément lors de la dérivation en MLD) et SALLE. Un CONCERT n'accueille qu'une et une seule TOURNEE :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 [ DATE ]
     |
    0,n
     |
     |
( CONCERT )--1,1----( )----0,n->[ TOURNEE ]
     |
     |
    0,n
     |
 [ SALLE ]

Pour le prix des places, j'obtiens exactement la même modélisation que fsmrel mais pas tout à fait de la même manière. J'ai considéré que, pour gérer la réservation et la vente des billets, il faut connaître le nombre de places de chaque catégorie dans chaque salle grâce à une association PLACE portant la propriété Nombre_places :

[ SALLE ]--0,n----( PLACE )----0,n--[ CATEGORIE ]


Par conséquent, le prix d'une place est une propriété d'une association entre PLACE et TOURNEE. Cette association, dérivée en table, est identique à CAT_PRIX du MLD de fsmrel (à l'identifiant TournéeId près).

( PLACE )<-0,n----( CAT_PRIX )----0,n--[ TOURNEE ]

Remarque : le lien entre deux associations est obligatoirement orienté sinon il serait impossible de distinguer laquelle de PLACE et CAT_PRIX est le résultat de l'association avec l'autre.

[fsmrel]

Bonsoir,

J'interviens car j'ai "planché" moi aussi sur cet énoncé fort intéressant.

J’étais prêt à répondre, quand j'ai vu que vous aviez fourni le résultat de votre réflexion. Je transmets ma réponse à peine modifiée, sachant que, si j’ai pris un peu de retard, nous sommes d’accord et fournissons des propositions identiques : ça fait de la redondance, mais ça n’est pas bien grave, ça ne pourra que rassurer l’ami bloups (ou le plonger dans des abîmes d’intense méditation ?)

Attendant les réponses de notre ami, je n’ai pas encore pour ma part traité du prix des places en fonction par exemple du nombre de places par catégorie. Vous l’avez fait : parfait.

Question concernant les prix des places : le tarif d’un artiste dépend-il seulement de la tournée ou bien dépend-il aussi le la salle ?

Concernant le tarif, celui ci varie en fonction de l'artiste et de la catégorie de places.
ex : une place pour les Rolling Stones en gradins ne coutera pas le même prix qu'une place pour le même concert en parterre ; qui ne coutera pas le même prix qu'une place pour Mickey 3D en parterre, etc...

"Le prix est cependant fixe pour toutes les dates où l'artiste se produit dans une même salle (cf. énoncé)."

On est bien d’accord que le prix d’une place dépend du de la catégorie de celle-ci, comme dans Les enfants du paradis, et cela quel que soit l’artiste. Mais partons maintenant de ce que vous écrivez :

« John Frankie World Tour » a lieu le 26/02 au Zénith de Toulouse, puis le 06/03 au Bataclan.

Ma question est plus précisément la suivante : Le tarif demandé par l’artiste est-il le même qu’il s’agisse du Zénith, du Bataclan, etc., ou bien ce tarif est-il négocié salle par salle ? Cette deuxième hypothèse est celle qui correspond à la règle de gestion que vous fournissez, mais j’aimerais connaître votre point de vue quant à la première hypothèse.

Par ailleurs, je suppose que le tarif journalier d’un artiste est déterminé après d’âpres négociations avec son agent, mais bien avant que la location des places ait lieu.

si un artiste fait une tournée dans une salle à une date donnée, puis y revient 15 ans après, le prix reste le même.
Je pense que cela doit être dans la limite des dates d'une même tournée

C’est bien comme cela qu’il faut aborder les choses, le tarif demandé par l’artiste ne peut que changer au fil des tournées...

Mais je peux tenter de faire un MLD directement. Je tente une nouvelle approche

Vous modélisez TOURNEE ainsi :

TOURNEE (TourneeID, TourneeLibelle, TourneeResume)

Mais il s’agit de la tournée d’un artiste, il manque donc la référence à celui-ci. Il faut donc modéliser ainsi :

TOURNEE (TourneeID, ArtisteID, TourneeLibelle, TourneeResume)

ou de préférence :

TOURNEE (ArtisteID, TourneeID, TourneeLibelle, TourneeResume)

Auquel cas TOURNEE est identifiée relativement à ARTISTE. Du point de vue du MCD :

[ TOURNEE ]-----1,1 (R)-----(EFFECTUER)----- 0,N----->[ ARTISTE ]

Ensuite, on peut brancher les salles et les tournées :

[ TOURNEE ]-----1,N-----(ACCUEILLIR)----- 0,N-----[ SALLE ]

Maintenant de deux choses l’une : si le tarif journalier de l’artiste est le même pour toutes les salles dans lesquelles il se produit, alors le tarif fait l’objet d’un attribut de TOURNEE, sinon si ce tarif est négocié salle après salle, alors il fait l’objet d’un attribut de l’association-type ACCUEILLIR (hypothèse retenue).

En tout état de cause, CONCERT est une propriété multivaluée de ACCUEILLIR. Au niveau du MLD, pas de difficulté :

[ CONCERT ] -----> [ACCUEILLIR ]

État à ce jour du MLD (avant intervention de JPhi33 à propos du nombre de places) :



Au niveau du MCD (Merise), ça coince puisqu’on ne peut pas établir des relations entre relations, et pour contourner il faut quelque chose comme ceci :


A compléter à coups de CIF pour traduire les contraintes suivantes :

ARTISTE X DATE → TOURNEE
ARTISTE X DATE → SALLE

Pour qu’au niveau MLD on obtienne ceci :

CONCERT {ArtisteID, ConcertDate, SalleID, TourneeID}

Sinon, les artistes auraient le don d’ubiquité, ils pourraient participer simultanément à 36 tournées et être présents au même moment dans des salles différentes (quoique, me direz-vous, si l’artiste est un magicien...)

N.B. La mise en œuvre des CIF doit être dans les cordes de JPhi33, après qu’il ait corrigé ce qui lui semble louche selon la grammaire de Merise...

Bon courage.

[bloups]

Tout d'abord, merci à vous deux pour vos réflexions approfondies

N'ayant pas beaucoup de temps, je vais aller à l'essentiel et répondre à vos questions.

Le tarif demandé par l’artiste est-il le même qu’il s’agisse du Zénith, du Bataclan, etc., ou bien ce tarif est-il négocié salle par salle ?

Le tarif est négocié par salle.
Ex :
Les Rolling Stones au Zénith de Paris le 17/02/10 - 55€
Les Rolling Stones à Bercy le 18/03/10 - 50€
Les Rolling Stones au Zénith de Toulouse le 22/04/10 - 53€
Les Rolling Stones au Zénith de Paris le 12/09/10 - 55€ (même tarif que la première fois car même salle, et même tournée)


Concernant votre première hypothèse (à savoir si le tarif demandé par l’artiste est le même qu’il s’agisse du Zénith, du Bataclan, etc.), je pense que cela ne serait pas judicieux. En effet, rien n'est indiqué à ce niveau là dans l'énoncé, donc autant ne pas prendre d'hypothèses trop restrictives.

Par ailleurs, je suppose que le tarif journalier d’un artiste est déterminé après d’âpres négociations avec son agent, mais bien avant que la location des places ait lieu.

Effectivement, toutes les décisions concernant les prix et le nombre de places alloués par catégorie sont prises à l'avance.



Je me pencherai sur vos schémas ce soir.

[bloups]

Pour tout vous avouer, plus je regarde vos schémas, et plus je suis perdu

Etant quasi-débutant en bases de données, ce sujet était censé être "accessible". Or là, vous faites des liens entre associations, chose que je pensais inconcevable il y a encore 3 jours

M'enfin je ne désespère pas de trouver (avec vos conseils) un MLD qui tienne la route.

État à ce jour du MLD (avant intervention de JPhi33 à propos du nombre de places) :

Si j'ai bien tout compris (je ne suis pas habitué aux MLD graphiques), cela est censé correspondre à çà :
Je me suis permis d'ajouter nb_places.

SALLE(SalleID, SalleNom)
CATEGORIE(CategorieID, CategorieLibelle)
ARTISTE(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteURL)

TOURNEE(TourneeID, ArtisteID#, TourneeLibelle, TourneeResume)
CONCERT(ArtisteID#, ConcertDate, SalleID#, TourneeID#)
CAT_PRIX(ArtisteID#, SalleID#, CategorieID#, TourneeID#, PrixPlace, nb_places)
ACCUEILLIR(ArtisteID#, TourneeID#, SalleID#, TourneeTarifJournalier)


Par contre, j'ai du mal à comprendre la différence entre votre TourneeTarifJournalier et PrixPlace. Enfin, surtout, ce que je ne comprend pas, c'est plutôt l'existence de TourneeTarifJournalier.

Sinon concernant la gestion du nombre de places, l'attribut Nb_places est-il au bon endroit ?
Je pense que pour Nb_places, l'hypothèse à faire est que pour chaque concert qui se passeront dans la même salle, toutes les places sont utilisées (donc le nombre de places par catégorie reste le même d'un concert sur l'autre). Il me semble que c'est l'hypothèse la moins contraignante même si cela ne reflète pas nécessairement la vérité.

[JPhi33]

Bonjour,

Or là, vous faites des liens entre associations, chose que je pensais inconcevable il y a encore 3 jours

Si tu es novice en modélisation conceptuelle, il ne faut pas te focaliser sur les associations d'associations. Il existe un moyen artificiel pour contourner la faiblesse des outils de modélisation vis-à-vis de ce concept : l'identification relative "dénaturée".

L'identification relative est déjà mise en oeuvre ici avec TOURNEE. Les outils de modélisation utilisent chacun leur propre technique de notation de ce concept. Par exemple, PowerAMC met la cardinalité de l'entité faible entre parenthèses. Exemple :

[ TOURNEE ]--(1,1)----( )----0,n->[ ARTISTE ]

qui se lit : TOURNEE est identifiée relativement à ARTISTE. TOURNEE dispose de son propre identifiant TourneeId. Par conséquent, l'identifiant réel de TOURNEE est {ArtisteId, TourneeId}.


Maintenant, si on retire TourneeId de l'entité TOURNEE, l'identifiant de TOURNEE devient le singleton {ArtisteId}. Si on fait abstraction du fait que ceci est conceptuellement incorrect (c'est pourquoi je parle d'identification relative "dénaturée"), nous avons un moyen bien pratique pour représenter une association comme une entité. Par exemple, j'ai modélisé l'association PLACE comme suit :

MCD 1
[ SALLE ]--0,n----( PLACE )----0,n--[ CATEGORIE ]


Avec la technique de l'identification relative, on pourrait la représenter comme ceci :

MCD 2
[ SALLE ]<-0,n----( )----(1,1)--[ PLACE ]--(1,1)----( )----0,n->[ CATEGORIE ]

PLACE est identifiée relativement à SALLE et CATEGORIE. Si PLACE n'a pas d'identifiant propre, alors son identifiant complet est {SalleId, CategorieId}.
Le MLD issu de MCD 1 est exactement le même que celui issu de MCD 2, notamment la table PLACE(SalleId, CategorieId, ...)


Maintenant que nous avons une entité PLACE (et non plus une association) la suite vient d'elle-même :

[ PLACE ]--0,n----( CAT_PRIX )----0,n--[ TOURNEE ]


Voici le MLD correspondant à cette partie du modèle :

ARTISTE (ArtisteId, ArtisteNom, ArtistePrenom, ArtisteURL)
TOURNEE (ArtisteId#, TourneeId, TourneeLibelle, TourneeResume)
SALLE (SalleId, SalleNom)
CATEGORIE (CategorieId, CategorieLibelle)
PLACE (SalleId#, CategorieId#, PlaceNombre)
CAT_PRIX (ArtisteId#, TourneeId#, SalleId#, CategorieId#, PrixPlace)


Pour terminer, il manque la notion de concert. J'ai considéré qu'il n'y a qu'un seul concert par jour dans une salle donnée (mon hypothèse 2) :

[ SALLE ]--0,n----( CONCERT )----1,n--[ DATE ]


Un concert ne peut donc porter que sur une seule tournée (donc un seul artiste) :

( CONCERT )--1,1----( )----0,n->[ TOURNEE ]

Noter au passage que la CIF entre une association et une entité est une notion déjà existante dans Merise 1.

MLD :
CONCERT (SalleId#, ConcertDate, TourneeId#)

Arrivé à ce stade, je pense que toutes les parties de l'énoncé ont été modélisées.

Par contre, j'ai du mal à comprendre la différence entre votre TourneeTarifJournalier et PrixPlace. Enfin, surtout, ce que je ne comprend pas, c'est plutôt l'existence de TourneeTarifJournalier.

Moi non plus. Peut-être s'agit-il du cachet de l'artiste ? Dans ce cas, ne s'éloigne-t-on pas de l'énoncé ?

[fsmrel]

Bonsoir,

j'ai du mal à comprendre la différence entre votre TourneeTarifJournalier et PrixPlace. Enfin, surtout, ce que je ne comprend pas, c'est plutôt l'existence de TourneeTarifJournalier.

Il s’agit de ce que vous aviez appelé « Le tarif négocié par salle ». Si vous ne l’utilisez pas, il peut bien sûr disparaître du modèle, mais le conserver vous permettrait — à titre d’exercice — de réfléchir à la cohérence du prix des places par rapport à ce tarif (bénéfices/déficits réalisés par la salle).

Pour tout vous avouer, plus je regarde vos schémas, et plus je suis perdu

Je rappelle que ces schémas ne sont pas des MCD mais des MLD. En l’occurrence, Workbench (gratuit je le rappelle) n’établit pas les relations entre des entités-types mais entre des tables (d’où la mise en évidence par exemple des clés étrangères). La notation que l’outil utilise est la notation IE (Information engineering) de James Martin.

La lecture des cardinalités est la suivante :

la cardinalité minimale 0 se traduit par un « o » (rien de changé),
la cardinalité minimale (ou maximale) 1 se traduit par une barre « | »,
la cardinalité maximale N se traduit par un trident.

Mais surtout, l’ordre de lecture est (apparemment inversé) :

Supposons qu’en Merise vous voyiez ceci :



Quand votre œil parcourt le chemin allant de A à B, en fait sa lecture est arrêtée par l'ovale de l’association R. Et vous interprétez 1,1 comme « A participe exactement une fois à R ». De même, partant de B, la lecture est à nouveau arrêtée par l’ovale et vous interprétez 1,N comme « B participe au moins une fois à R ».

Avec la notation IE :



Partant de A, le cheminement de l’œil ne rencontre pas d’obstacle, si ce n’est B lui-même et l’interprétation devient « Pour une valeur de A il y a exactement une valeur de B » et pour le parcours dans l’autre sens, « Pour une valeur de B il y a au moins une valeur de A ». Dans cet exemple, on a en fait représenté une surjection. Si vous utilisiez la notation de Chen, cette fois-ci vous pourriez être à juste titre perturbé (voyez à nouveau le renvoi à IE).


Quelque chose me fait tiquer concernant la représentation tabulaire ci-dessous :

TOURNEE (ArtisteId#, TourneeId, TourneeLibelle, TourneeResume)
...
CONCERT (SalleId#, ConcertDate, TourneeId#)

En effet, concernant CONCERT, l’attribut TourneeId est noté clé étrangère et la table référencée ne peut être que la table TOURNEE. Mais celle-ci a pour clé primaire la paire {ArtisteId, TourneeId}, donc l’attribut ArtisteId devrait figurer dans la liste des attributs de la clé étrangère portée par CONCERT, ce qui nous ramène inévitablement au problème de la bilocation d’un artiste dans une foule de salles...

Que {SalleId, ConcertDate} soit clé candidate de CONCERT, d’accord, mais {ArtisteId, ConcertDate} l’est aussi. Sinon, on peut produire l’extension suivante, dans laquelle on trouve de la bilocation :

Code :

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

1
2
3
4
5
SalleId   ConcertDate   ArtisteId   TourneeId
   s1         d1          a1           t1
   s1         d2          a2           t2
   s2         d1          a1           t3
   s3         d1          a1           t1

(Le rôle de la table ACCUEILLIR n’est peut-être pas inutile dans cette affaire pour définir les paires {SALLE, TOURNEE}.)

Pardon bloups pour ces considérations, mais il y va de l’intégrité de la base de données.

[JPhi33]

Bonjour fsmrel,

Quelque chose me fait tiquer concernant la représentation tabulaire ci-dessous :

TOURNEE (ArtisteId#, TourneeId, TourneeLibelle, TourneeResume)
...
CONCERT (SalleId#, ConcertDate, TourneeId#)

Et vous avez raison !

En effet, concernant CONCERT, l’attribut TourneeId est noté clé étrangère et la table référencée ne peut être que la table TOURNEE. Mais celle-ci a pour clé primaire la paire {ArtisteId, TourneeId}, donc l’attribut ArtisteId devrait figurer dans la liste des attributs de la clé étrangère portée par CONCERT,

Tout à fait. C'est une bourde de ma part. J'aurais du écrire :

CONCERT (SalleId#, ConcertDate, ArtisteId#, TourneeId#)

ce qui nous ramène inévitablement au problème de la bilocation d’un artiste dans une foule de salles...

Manifestement, cet aspect m'a échappé

Johnny n'ayant pas encore le don d'ubiquité, je vais devoir retravailler ce point au niveau conceptuel. Il est probable que le MLD résultant ressemble trait pour trait au vôtre.

[bloups]

Bon, j'ai demandé hier à ma prof de m'expliquer vite fait les associations d'associations.
En gros, j'ai compris que l'on contournait le problème d'associer des associations (qui n'est pas possible normalement) en considérant qu'un bloc entités/association (2 entités et leur asso) était une entité agrégée. Du coup, celà revient à joindre l'association de cette entité agrégée avec une autre association.
J'ai bon ?

C'est mal expliqué comme çà et j'ai peut être pas tout compris, mais jcrois que l'essentiel est là
Quoi qu'il en soit, je ne suis pas censé utiliser une telle méthode.


Concernant le don d'ubiquité de nos chers artistes, ne faudrait-il pas remplacer :

CONCERT (SalleId#, ConcertDate, ArtisteId#, TourneeId#)

par

CONCERT(ArtisteID#, ConcertDate, SalleID#, TourneeID#)

comme l'a fait fsmrel ?

[fsmrel]

Bonjour,

Bon, j'ai demandé hier à ma prof de m'expliquer vite fait les associations d'associations.

Ce que votre professeur vous a expliqué est dans la ligne de ce qui a été traité par la famille Smith en 1977 (John Miles Smith et Diane C.P. Smith : “Database Abstractions: Aggregation and Generalization”, ACM Transactions on Database Systems, Vol. 2, No. 2, June 1977). Dans votre cas, l’association d’associations est formalisable au moyen de l’agrégation smithienne :



Mais je n’ai pas vu que Merise dans sa version classique (pas plus que les AGL merisiens) propose cette solution. Cela dit, Arnold Rochfeld José Morejon et Pascal Negros sont passés au concept d’associations d’associations pour pallier la contrainte trop rigide des associations exclusivement entre entités-types, ce qui dans votre cas vous permet de représenter les choses ainsi (cf. la représentation graphique merisienne que je vous ai proposée à l’occasion d’un message précédent) :



Notez la contrainte d’inclusion toujours présente (patte orientée de CONCERT vers ACCUEILLIR).

Quoi qu'il en soit, je ne suis pas censé utiliser une telle méthode.

Ce qui ne vous empêche pas de noter les contraintes sous forme textuelle dans votre MCD ou d’en passer par des CIF (cf. toujours mon message en référence). Quoi qu’il en soit, vous aurez à mettre ces contraintes en œuvre au stade du MLD, à la façon de celui que je vous ai proposé, car cette fois-ci il n’y a plus que des tables et rien que des tables et les problèmes évoqués par les Smith, Rochfeld et ses compagnons ne se posent plus.

Concernant le don d'ubiquité de nos chers artistes, ne faudrait-il pas remplacer :

CONCERT (SalleId#, ConcertDate, ArtisteId#, TourneeId#)

par

CONCERT(ArtisteID#, ConcertDate, SalleID#, TourneeID#)

comme l'a fait fsmrel ?

Les deux contraintes doivent être mises en œuvre.

Exemple SQL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE  TABLE CONCERT (
  ArtisteId   INT   NOT NULL,
  ConcertDate DATE  NOT NULL,
  SalleId     INT   NOT NULL,
  TourneeId   INT   NOT NULL,
  PRIMARY KEY (ArtisteId, ConcertDate),
  UNIQUE (SalleId, ConcertDate),
  CONSTRAINT CONCERT_ACCUEILLIR_FK
    FOREIGN KEY (SalleId, ArtisteId, TourneeId)
    REFERENCES ACCUEILLIR (SalleId, ArtisteId, TourneeId)) ;

Sinon, dans la même salle, le même jour vous pourriez avoir la présence de tous les artistes :

Code :

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

1
2
3
4
5
SalleId   ConcertDate   ArtisteId   TourneeId
   s1         d1          a1           t1
   s1         d1          a2           t2 
   ...        ...         ...          ...
   s1         d1          an           tm

[JPhi33]

Bonjour,

En gros, j'ai compris que l'on contournait le problème d'associer des associations (qui n'est pas possible normalement) [...]

Ca reste à voir. Dès Merise 1 (Tome 1, Principes et outils), on trouve une CIF associant une association et une entité. Et une CIF est une association.

[...] en considérant qu'un bloc entités/association (2 entités et leur asso) était une entité agrégée.

Bien que décrite dans Merise/2, personnellement je n'adhère pas à cette notation qui introduit une entité artificielle regroupant deux entités (ou plus) et une association (premier schéma dans le dernier message de fsmrel) et surcharge le MCD. Une entité c'est... une entité, pas un regroupement d'objets conceptuels.

[bloups]

Bonjour,

Avec tout ces changements, et ces hypothèses, je commence à me perdre vraiment

Je suis perdu car je n'ai pas l'impression que vous proposez tout deux la même solution, ce qui me perturbe un peu je dois l'avouer, ne sachant pas laquelle je dois utiliser...
Ou bien est-ce peut être moi qui ne comprend pas tout.

En plus, je me rend compte que la modélisation n'est pas finie car je dois gérer les réservations de places et donc les comptes clients.

L'un d'entre vous pourrait-il éventuellement proposer un MLD (textuel si possible) qui réponde à ces contraintes de réservation tout en restant proche des bases établies jusqu'ici ?

[fsmrel]

Bonjour bloups,

On ne vous oublie pas. Dès que j'aurai un moment, je vous proposerai un MLD (sur lequel JPhi33 — vraisemblablement bien chargé de son côté — donnera son avis, s'il en a le temps).

[fsmrel]

JPhi33 et moi-même sommes apparemment d’accord sur le MLD :

Il est probable que le MLD résultant ressemble trait pour trait au vôtre.

En conséquence de quoi, je vous propose ceci :

Si le système concerne la direction de la salle, le montant du cachet de l’artiste est à prendre en compte au même titre que l’URL de l’artiste, auquel cas je maintiens l’attribut correspondant au cachet de l’artiste (CachetParConcert ou CachetParTournee, comme on veut), de telle sorte que la direction d’une salle puisse rapprocher ce montant des recettes. Si le système ne concerne pas la direction de la salle, l’attribut disparaît (de même probablement l’URL de l’artiste, car je vois mal son rôle dans cette vision des choses) et tant qu’à faire tout le système de gestion des places.

Pensez-vous qu'il est judicieux de considérer qu'un concert puisse être joué par 1 ou plusieurs artistes ? (ex : Les enfoirés)

C’est l’histoire de la portée de rat dans les laboratoires : les ratons n’ont pas besoin d’être isolés et identifiés en tant que tels. Si dans le cadre, par exemple, d’une expérience on en isole un ou plusieurs, alors seulement on crée une entité-type Raton.

j'ai oublié de préciser que je devais mettre en place un système de commentaires sur les concerts (pour que l'on puisse donner son avis, ce système étant sans login donc sans gestion de comptes utilisateurs).
En gros, je dois pouvoir :
- réserver des billets ;
- donner son avis sur un concert et consulter ses avis.

En attendant de savoir ce que vous souhaitez exactement concernant le système de réservation des places (par téléphone ? Aux guichets ?), je propose le MLD suivant, dans lequel les spectateurs donnent leur avis. J’espère que ce MLD réalisé avec Power AMC V11 vous perturbera moins que celui réalisé avec Workbench :


N.B. <pk> est l'abréviation de primary key (clé primaire) et <ak> est l'abréviation de alternate key (clé alternative).
<fk> est l'abréviation de foreign key (clé étrangère) ,mickey qui peut être numéroté : <fk1>, <fk2>, etc. (tout comme <ak> du reste).

[JPhi33]

Bonsoir,

JPhi33 et moi-même sommes apparemment d’accord sur le MLD

Oui, à quelques détails près...

Table CAT_PRIX
Dans un précédent message j'ai modélisé l'association dont cette table est issue comme ceci :

[ PLACE ]--0,n----( CAT_PRIX )----0,n--[ TOURNEE ]

Ainsi, aucune vérification n'est nécessaire quant à l'origine de SalleId. Cette (partie de) clé référence obligatoirement la table PLACE.

Dans la modélisation de fsmrel, il faut se demander si SalleId référence PLACE ou bien ACCUEILLIR.
Peut-être existe-t-il un prédicat de construction de table (désolé si les termes ne sont pas adéquats) permettant d'indiquer que cette clé référence les deux tables à la fois et que, obligatoirement, les deux valeurs doivent être identiques ? Si ce n'est pas le cas, il faut choisir laquelle des deux tables est référencée et interdire (par trigger ?), au moment de l'insertion d'une ligne de CAT_PRIX, de la lier à une ligne de l'autre ayant une valeur différente de SalleId. Bref, ça me semble bien compliqué...


Table CONCERT
Je ne comprends pas comment cette table est modélisée. {ArtisteId, ConcertDate} référence seulement une partie de la clé de ACCUEILLIR (ArtisteId), l'autre partie (TournéeId, SalleId) se retrouvant en clé étrangère dans CONCERT.


Quoi qu'il en soit, cette partie du modèle est la plus délicate. Ce que j'ai proposé en premier lieu n'est pas bon. Il s'agissait de ceci :

[ SALLE ]--0,n----( CONCERT )----1,n--[ DATE ]

( CONCERT )--1,1----( )----0,n->[ TOURNEE ]

En effet, un artiste ne peut pas se produire dans deux endroits différents en même temps (voir la démonstration de fsmrel).

Par ailleurs, j'avais émis l'hypothèse que : "Il n'y a qu'un seul concert par jour dans une salle donnée". Si l'on tient compte de cette hypothèse, la modélisation suivante n'est pas non plus correcte :

[ TOURNEE ]--0,n----( CONCERT )----1,n--[ DATE ]

( CONCERT )--1,1----( )----0,n->[ SALLE ]

car elle autorise la présence de plusieurs artistes dans la même salle le même jour. Mais est-ce vraiment un problème ? Cette contrainte n'existe pas dans l'énoncé (je l'ai rajoutée). Et elle interdit qu'il y ait, par exemple, des premières parties de concert ("Demain, au Zénith, Les Rolling Stones, avec Eddy Mitchell en première partie"). En conséquence, je retire cette hypothèse.


Le MCD façon Merise 1
En vert, les entités qui sont en réalité des associations.



Le MLD



Le MCD façon Merise avancé
- CAT_PRIX est une association entre PLACE et TOURNEE
- "est donné dans" est une CIF de CONCERT vers SALLE
- ConcertDate n'est pas une entité mais une "propriété spatio-temporelle" : pas de nom d'entité, pas de table correspondante dans le MLD

[fsmrel]

Bonsoir,

Dans la modélisation de fsmrel, il faut se demander si SalleId référence PLACE ou bien ACCUEILLIR.

Pourquoi donc ? SalleId référence nécessairement PLACE et ACCUEILLIR. En effet, du point de vue de la théorie relationnelle, la structure des tables (plus exactement je devrais dire des variables relationnelles car le concept de table est strictement SQL, mais on fera comme si) est la suivante :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
ACCUEILLIR {ArtisteId, TourneeId, SalleId, CachetParConcert}
     KEY {ArtisteId, TourneeId, SalleId}
     FOREIGN KEY {ArtisteId, TourneeId} REFERENCES TOURNEE   
     FOREIGN KEY {SalleId} REFERENCES SALLE ; 
PLACE {SalleId, CategorieId, NombrePlaces}
     KEY {SalleId, CategorieId}
     FOREIGN KEY {SalleId} REFERENCES SALLE
     FOREIGN KEY {CategorieId} REFERENCES CATEGORIE ;
CAT_PRIX {ArtisteId, TourneeId, SalleId, CategorieId, PrixPlace}
     KEY {ArtisteId, TourneeId, SalleId, CategorieId}
     FOREIGN KEY {ArtisteId, TourneeId, SalleId} REFERENCES ACCUEILLIR
     FOREIGN KEY {SalleId, CategorieId} REFERENCES PLACE ;

La clé étrangère {ArtisteId, TourneeId, SalleId} portée par la table CAT_PRIX référence la clé primaire {ArtisteId, TourneeId, SalleId} de la table ACCUEILLIR, donc relationnellement parlant, SalleId référence correctement ACCUEILLIR. Cette clé étrangère est symbolisée par le mickey <fk1> porté par la table CAT_PRIX ci-dessous (extraite du diagramme de mon message précédent, mickey fourni par Power AMC) :


La clé étrangère {SalleId, CategorieId} portée par la table CAT_PRIX référence la clé primaire {SalleId, CategorieId} de la table PLACE, donc relationnellement parlant, SalleId référence correctement PLACE (cf. le mickey <fk2> porté par la table CAT_PRIX proposée ci-dessus.

Peut-être existe-t-il un prédicat de construction de table (désolé si les termes ne sont pas adéquats) permettant d'indiquer que cette clé référence les deux tables à la fois et que, obligatoirement, les deux valeurs doivent être identiques ?

L’attribut SalleId fait référence simultanément à PLACE et ACCUEILLIR, donc pour une ligne donnée de la table CAT_PRIX cet attribut ne peut pas prendre deux valeurs distinctes. Détaillons :

a) Si cet attribut prend la valeur s1 (table CAT_PRIX), pour la tournée t1 de l’artiste a1, le triplet <a1, t1, s1> étant une valeur de la clé étrangère {ArtisteId, TourneeId, SalleId} portée par CAT_PRIX, ce triplet est nécessairement une valeur de la clé primaire le la table cible ACCUEILLIR (sinon l’intégrité référentielle serait violée). A son tour, le singleton <s1> étant une valeur de l’attribut SalleId de la table ACCUEILLIR, c’est aussi une valeur de la clé étrangère {SalleId} portée par cette table, donc une valeur de la clé primaire {SalleId} de la table cible SALLE, intégrité référentielle oblige.

b) Cet attribut prenant la valeur s1 (table CAT_PRIX), pour la catégorie c1, la paire <s1, c1> étant une valeur de la clé étrangère {SalleId, CategorieId} portée par CAT_PRIX, cette paire est nécessairement une valeur de la clé primaire le la table cible PLACE (intégrité référentielle oblige à nouveau). A son tour, le singleton <s1> étant une valeur de l’attribut SalleId de la table PLACE, c’est aussi une valeur de la clé étrangère {SalleId} portée par cette table, donc une valeur de la clé primaire {SalleId} de la table cible SALLE, intégrité référentielle oblige toujours.

=>

Quel que soit le chemin emprunté, partant de la valeur s1 de l’attribut SalleId de la table CAT_PRIX on aboutit à la valeur unique s1 de l’attribut SalleId de la table SALLE : pour une ligne donnée de la table CAT_PRIX, l’attribut SalleId prend exactement une valeur (s1 dans l’exemple).

Ainsi, il n’est nul besoin de trigger ou autre mécanisme pour assurer la cohérence, l’intégrité référentielle suffit, de façon très simple.

Par ailleurs, j'avais émis l'hypothèse que : "Il n'y a qu'un seul concert par jour dans une salle donnée". Si l'on tient compte de cette hypothèse, la modélisation suivante n'est pas non plus correcte :

[ TOURNEE ]--0,n----( CONCERT )----1,n--[ DATE ]

( CONCERT )--1,1----( )----0,n->[ SALLE ]

car elle autorise la présence de plusieurs artistes dans la même salle le même jour. Mais est-ce vraiment un problème ? Cette contrainte n'existe pas dans l'énoncé (je l'ai rajoutée). Et elle interdit qu'il y ait, par exemple, des premières parties de concert ("Demain, au Zénith, Les Rolling Stones, avec Eddy Mitchell en première partie"). En conséquence, je retire cette hypothèse.

Soit. A mon tour je supprime la clé candidate {SalleId, ConcertDate} qui avait été définie pour la table CONCERT et je ne conserve que la clé {ArtisteId, ConcertDate} (mickey <pk>) :





Concernant les cachets des artistes

Manifestement je suis seul à prendre en compte cette donnée. Je me rallie donc à la majorité, je vais la considérer comme étant hors périmètre du projet et je la supprime : tant pis si l’on ne peut désormais plus savoir si les directions des salles gagnent ou perdent de l’argent et dans quelles proportions.

La structure de la table ACCUEILLIR devient la suivante :


Mais dans ces conditions, la table ACCUEILLIR peut être interprétée comme étant la projection {ArtisteId, TourneeId, SalleId} appliquée à la table CAT_PRIX, auquel cas ACCUEILLIR peut disparaître (et faire au besoin l’objet d’une vue), quitte à renaître si l’on voulait prendre à nouveau en compte les cachets des artistes. En conséquence, le MLD devient le suivant :


Ce MLD est structurellement identique à celui de JPhi33, si ce n’est que la table CONCERT diffère quant à la composition de sa clé (primaire), voir ci-après.

Table CONCERT
Je ne comprends pas comment cette table est modélisée. {ArtisteId, ConcertDate} référence seulement une partie de la clé de ACCUEILLIR (ArtisteId), l'autre partie (TourneeId, SalleId) se retrouvant en clé étrangère dans CONCERT.

Il faut interpréter cette modélisation dans le cadre strict de la théorie relationnelle. Reprenons le MLD que j’ai proposé dans mon précédent message (présence de la table ACCUEILLIR), mais auparavant je rappelle définition de la clé candidate :

Une clé candidate est un sous-ensemble d’attributs K de l’en-tête d’une table T, respectant les deux contraintes suivantes :
— Unicité. Deux lignes distinctes de T ne peuvent avoir même valeur de K.
— Irréductibilité. Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Dans ces conditions, le triplet {ArtisteId, ConcertDate, TourneeId} vérifie la condition d’unicité mais pas celle d’irréductibilité, tandis que la paire {ArtisteId, ConcertDate} vérifie les deux conditions. Cette paire constitue une clé candidate de la table CONCERT et par ailleurs elle n’a pas à référencer la table ACCUEILLIR, sinon elle devrait aussi être clé étrangère, or les concepts de clé candidate et de clé étrangère au sein d’une table donnée (CONCERT en l’occurrence) sont totalement indépendants (orthogonaux comme dirait Chris Date) quels que soient les attributs qui les composent. Ainsi, le singleton {ArtisteId} peut très bien participer en tant que sous-ensemble strict à une clé candidate de la table CONCERT et/ou à une clé étrangère et, toutes choses égales par ailleurs, il en va évidemment de même pour la paire {TourneeId, SalleId}.

Ici, c’est bien le triplet {ArtisteId, TourneeId, SalleId} qui constitue légalement et légitimement une clé étrangère par rapport à la clé primaire de la table ACCUEILLIR, sinon l’intégrité de la table serait mise à mal.

La modélisation suivante est conforme aux canons de la théorie relationnelle :

Code D :

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

1
2
3
4
5
6
7
8
9
10
ACCUEILLIR {ArtisteId, TourneeId, SalleId, CachetParConcert}
     KEY {ArtisteId, TourneeId, SalleId}
     FOREIGN KEY {ArtisteId, TourneeId} REFERENCES TOURNEE   
     FOREIGN KEY {SalleId} REFERENCES SALLE ; 

CONCERT {ArtisteId, ConcertDate, SalleId, TourneeId}
     KEY {ArtisteId, ConcertDate}
     KEY {SalleId, ConcertDate}
     FOREIGN KEY {ArtisteId, TourneeId, SalleId} REFERENCES ACCUEILLIR ;

La table CONCERT est dotée de deux clés : {ArtisteId, ConcertDate} et {SalleId, ConcertDate}. La première joue le rôle de clé primaire pour SQL et la deuxième — bien qu’en réalité elle disparaisse en même temps que la règle de gestion que vous supprimez — celui de clé alternative (dans la théorie relationnelle, il n’y a que des clés candidates, le concept de clé primaire a été passé au fil du rasoir d’Occam).

Ces clés sont respectivement symbolisées par les mickey <pk> et <ak> portés par la table CONCERT ci-dessous (reprise du diagramme de mon message précédent) :


De la même façon, le triplet {ArtisteId, TourneeId, SalleId} représente la clé étrangère permettant de référencer la clé primaire de la table ACCUEILLIR (cf. le mickey <fk>).

Cas où la table ACCUEILLIR disparaît du MLD :

Indépendamment du fait que la clé candidate {SalleId, ConcertDate} disparaît et que les clés étrangères sont modifiées, la clé (primaire) de la table CONCERT reste bien {ArtisteId, ConcertDate}, pour les raisons de bilocation débattues dans les messages précédents.


Maintenant, concernant votre MLD, j'observe que le problème de la bilocation n'est pas résolu. En effet votre MLD est le suivant :


Considérons alors le prédicat associé à la table CONCERT (je renomme les attributs ArtisteId, TourneeId, SalleId et ConcertDate respectivement en A, T, S, D) :

L’artiste A se produira dans la salle S à la date D lors de la tournée T.

Selon votre MLD, les propositions suivantes sont valides, car la table CONCERT y a pour clé le triplet {ArtisteId, TourneeId, ConcertDate} :

L’artiste< a1> se produira dans la salle <s1> à la date <d1> lors de la tournée <t1>,
L’artiste< a1> se produira dans la salle <s2> à la date <d1> lors de la tournée <t2>.

Il y a bien bilocation. En fait, le triplet {ArtisteId, TourneeId, ConcertDate} n’est pas une clé candidate mais seulement une surclé, c'est-à-dire que si ce sous-ensemble garantit bien la règle d’unicité des lignes de la table, il n’en est pas moins réductible à la paire {ArtisteId, ConcertDate} qui est une vraie clé candidate (d'une part cette paire garantit l'unicité et d'autre part si on la réduisait à {ArtisteId} ou à {ConcertDate}, on perdrait la propriété d’unicité des clés candidates).


MLD correspondant :




@ bloups :

Le MLD sous forme déclarative (aux erreurs près de copié/collé) :

Code D :

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
21
22
ARTISTE {ArtisteId, ArtisteNom, ArtisteBio, ArtisteURL}
        KEY  (ArtisteId) ;
SALLE {SalleId, SalleNom}
        KEY  (SalleId) ;
CATEGORIE {CategorieId, CategorieLibelle}
        KEY  (CategorieId) ;
TOURNEE {ArtisteId, TourneeId, TourneeLibelle}
        KEY  (ArtisteId, TourneeId)
        FOREIGN KEY (ArtisteId) REFERENCES ARTISTE ;
PLACE {SalleId, CategorieId, NombrePlaces}
        KEY  (SalleId, CategorieId)
        FOREIGN KEY (SalleId) REFERENCES SALLE
        FOREIGN KEY (CategorieId) REFERENCES CATEGORIE ;
CAT_PRIX {ArtisteId, TourneeId, SalleId, CategorieId, PrixPlace}
        KEY  (ArtisteId, TourneeId, SalleId, CategorieId)
        FOREIGN KEY (ArtisteId, TourneeId) REFERENCES TOURNEE
        FOREIGN KEY (SalleId, CategorieId) REFERENCES PLACE ;
CONCERT {ArtisteId, ConcertDate, TourneeId, SalleId}
        KEY  (ArtisteId, ConcertDate)
        FOREIGN KEY (ArtisteId, TourneeId) REFERENCES TOURNEE
        FOREIGN KEY (SalleId) REFERENCES SALLE ;