Discussion :

[bloups]

@ bloups :

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

Code :

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
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 ;

Un grand merci, je ne pouvais rêver de mieux

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.

Cette base de données va être implantée sous MySQL dans le cadre d'un projet PHP/MYSQL.
Il s'agit d'un site internet, aucune réservation ne se faisant alors par téléphone ou guichet, tout passe par le site.

Du coup, il est utile (et même indispensable) d'enregistrer les clients (qui s'inscriront par un formulaire) => Nom, Prénom, Rue, CP, Ville, ... si vous voyez d'autres informations que vous jugez utile, n'hésitez pas à rajouter ^^ (Genre, ...)

De plus, il est demandé de conserver les commentaires/avis qu'un client poste sur les différents concerts.
Peut-être est-il utile de conserver la date/heure de post du message pour la chronologie, même si les messages vont surement avoir une clé primaire en auto increment pour les différencier.

[fsmrel]

Un grand merci, je ne pouvais rêver de mieux

Apparemment Workbench ça n’est pas votre truc...
Je vous laisse le soin de convertir en SQL le script écrit en D.

Du coup, il est utile (et même indispensable) d'enregistrer les clients (qui s'inscriront par un formulaire) => Nom, Prénom, Rue, CP, Ville, ... si vous voyez d'autres informations que vous jugez utile, n'hésitez pas à rajouter ^^ (Genre, ...)

Je vous laisse là aussi le soin de fournir la liste des données (je ne suis pas un spécialiste de la réservation par Internet...)

De plus, il est demandé de conserver les commentaires/avis qu'un client poste sur les différents concerts.
Peut-être est-il utile de conserver la date/heure de post du message pour la chronologie, même si les messages vont surement avoir une clé primaire en auto increment pour les différencier.

Je rappelle que la table COMMENTAIRE dans le MLD proposé dans mon message du 26/03/2010 à 17h25, est effectivement porteuse de ce genre de propriétés :



Selon la notation D :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CONCERT {ArtisteId, ConcertDate, TourneeId, SalleId}
        KEY  (ArtisteId, ConcertDate)
        FOREIGN KEY (ArtisteId, TourneeId) REFERENCES TOURNEE
        FOREIGN KEY (SalleId) REFERENCES SALLE ;
SPECTATEUR {SpectateurId, Pseudonyme, ...}
        KEY  (SpectateurId)
        KEY  (Pseudonyme) ;
COMMENTAIRE {ArtisteId, ConcertDate, SpectateurId, 
             CommentaireDate, CommentaireHeure, CommentaireTexte}
        KEY  (ArtisteId, ConcertDate, SpectateurId, CommentaireDate, CommentaireHeure)
        FOREIGN KEY (ArtisteId, ConcertDate) REFERENCES CONCERT
        FOREIGN KEY (SalleId) REFERENCES SPECTATEUR ;

Notez que Le quintuplet {ArtisteId, ConcertDate, SpectateurId, CommentaireDate, CommentaireHeure} est clé candidate de la table Commentaire. Quel intérêt y a-t-il à définir une clé supplémentaire comme vous y songez ? Quelle valeur ajoutée ? Fonctionnellement je n’en vois pas. Du point de vue de la manipulation des données (requêtes) non plus. Au niveau physique, vous aurez un index supplémentaire, d’où une dégradation des performances en mise à jour. Réfléchissez du bien fondé de l’ajout systématique de clés supplémentaires dans vos tables. La parcimonie, le strict nécessaire sont de mise.

[JPhi33]

Bonsoir à tous (les deux),

Pourquoi donc ? SalleId référence nécessairement PLACE et ACCUEILLIR.

Bien évidemment.

Ce n'est pas du tout ce que je voulais dire et, une fois de plus, je me suis mal exprimé.

Ce que je voulais dire, c'est que dans un tel schéma, pour insérer une ligne dans CAT_PRIX, il faut qu'il existe (au moins) une ligne de PLACE et (au moins) une ligne de ACCUEILLIR pour lesquelles la valeur de SalleId est identique (rien de surprenant).
Mais si l'on procède à une rétro-conception, on se rend compte que le MCD doit comporter une contrainte sémantique de simultanéité visant à exprimer le fait qu'une occurrence de l'association CAT_PRIX doit associer une occurrence de PLACE et une de ACCUEILLIR (au passage, on notera que CAT_PRIX associe deux associations) ayant même valeur de SalleId. Sinon, on s'expose à indiquer le prix d'une place en tribune au Zénith pour une tournée des Stones passant au Stade de France à cause de la dérivation brute qui serait :

CAT_PRIX(ArtisteId#, TourneeId#, SalleId_A#, CategorieId#, SalleId_P#, PrixPlace)

avec SalleId_A dérivé de ACCUEILLIR et SalleId_P dérivé de PLACE.

Ce n'est que parce que cette contrainte est posée que l'on peut, lors de la dérivation du MCD en MLD, unifier les deux colonnes SalleId_A et SalleId_P en une seule colonne SalleId. Autant éviter de modéliser cette contrainte en associant directement SALLE et TOURNEE puisque l'énoncé l'autorise.

Maintenant, concernant votre MLD, j'observe que le problème de la bilocation n'est pas résolu. [...] 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.

Effectivement. Ce cas ne pouvant pas se produire dans la réalité (la date <d1> ne peut pas concerner à la fois les tournées <t1> et <t2>), le modèle doit l'interdire.

Cependant, pour pouvoir produire ce MLD à partir d'un MCD, il y a nécessité de modéliser une contrainte d'inclusion exprimant le fait que ArtisteId provenant de ARTISTE et ArtisteId provenant de TOURNEE ont même valeur pour une occurrence donnée de CONCERT.

(MCD à suivre...)

[fsmrel]

Bonsoir,

Mais si l'on procède à une rétro-conception, on se rend compte que le MCD doit comporter une contrainte sémantique de simultanéité visant à exprimer le fait qu'une occurrence de l'association CAT_PRIX doit associer une occurrence de PLACE et une de ACCUEILLIR (au passage, on notera que CAT_PRIX associe deux associations) ayant même valeur de SalleId. Sinon, on s'expose à indiquer le prix d'une place en tribune au Zénith pour une tournée des Stones passant au Stade de France à cause de la dérivation brute qui serait :

CAT_PRIX(ArtisteId#, TourneeId#, SalleId_A#, CategorieId#, SalleId_P#, PrixPlace)

avec SalleId_A dérivé de ACCUEILLIR et SalleId_P dérivé de PLACE.

Ce n'est que parce que cette contrainte est posée que l'on peut, lors de la dérivation du MCD en MLD, unifier les deux colonnes SalleId_A et SalleId_P en une seule colonne SalleId. Autant éviter de modéliser cette contrainte en associant directement SALLE et TOURNEE puisque l'énoncé l'autorise.

Il est évident que dans le cas particulier qui nous intéresse, l’association-type ACCUEILLIR n’a pas lieu d’être puisqu’au sens de la théorie relationnelle — comme je l’ai précisé dans un message précédent, elle n’est que la projection de CAT_PRIX sur les attributs ArtisteId, TourneeId et SalleId.

Mais, pour laisser le cas particulier et passer à un niveau plus général, supposons maintenant que le dossier de conception comporte effectivement la règle de gestion selon laquelle le cachet de l’artiste est à prendre en compte afin que l’on puisse mesurer les bénéfices des salles.

Par exemple (sous forme prédicative) :

Pour sa tournée T et ses passages dans la salle S, l’acteur A touchera un cachet global C.

Cette fois-ci la table ACCUEILLIR n’étant plus la projection de CAT_PRIX sur les attributs ArtisteId, TourneeId et SalleId, elle doit être matérialisée :

Code D :

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

1
2
3
4
5
VAR ACCUEILLIR BASE RELATION
    {ArtisteId, TourneeId, SalleId, Cachet}
    KEY {ArtisteId, TourneeId, SalleId}
    FOREIGN KEY {ArtisteId, TourneeId} REFERENCES TOURNEE 
    FOREIGN KEY {SalleId} REFERENCES SALLE ;

Maintenant, appelons C1 la contrainte de simultanéité dont vous avez fait état, selon laquelle, pour chaque occurrence, l’attribut SalleId_A qui sera dérivé de ACCUEILLIR et l’attribut SalleId_P dérivé de PLACE doivent prendre la même valeur.

De deux choses l’une :

• Ou bien le formalisme individuel nous permet d’exprimer la contrainte C1, auquel cas un AGL capable de l'interpréter produira une table CAT_PRIX ayant la structure suivante :

Version 1 de la table CAT_PRIX

Code D :

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

1
2
3
4
5
VAR CAT_PRIX BASE RELATION
    {ArtisteId, TourneeId, SalleId, CategorieID, PrixPlace}
    KEY {ArtisteId, TourneeId, SalleId, CategorieID}
    FOREIGN KEY {ArtisteId, TourneeId, SalleId} REFERENCES ACCUEILLIR
    FOREIGN KEY {CategorieID, SalleId} REFERENCES PLACE ;

Ou encore (mais ça serait bien ballot) :

Version 2 de la table CAT_PRIX

Code D :

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

1
2
3
4
5
6
7
8
9
VAR CAT_PRIX BASE RELATION
    {ArtisteId, TourneeId, SalleId_A, SalleId_P, CategorieID, PrixPlace}
    KEY {ArtisteId, TourneeId, SalleId_A, CategorieID}
    KEY {ArtisteId, TourneeId, SalleId_P, CategorieID}
    FOREIGN KEY {ArtisteId, TourneeId, SalleId_A} REFERENCES ACCUEILLIR
    FOREIGN KEY {CategorieID, SalleId_P} REFERENCES PLACE ;

CONSTRAINT C1
    FORALL x (x.SalleId_A = x.SalleId_P) ;

(En notant qu’il y a 36 façons d’exprimer la contrainte C1.)

Version SQL :

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 CAT_PRIX
(
  ArtisteId, TourneeId, SalleId_A, SalleId_P, CategorieId,  PrixPlace,
  CONSTRAINT CAT_PRIX_PK PRIMARY KEY (ArtisteId, TourneeId, SalleId_A, CategorieId),
  CONSTRAINT CAT_PRIX_AK UNIQUE      (ArtisteId, TourneeId, SalleId_P, CategorieId),
  CONSTRAINT CAT_PRIX_ACCUEILLIR_FK
    FOREIGN KEY (ArtisteId, TourneeId, SalleId_A) 
       REFERENCES ACCUEILLIR (ArtisteId, TourneeId, SalleId),
  CONSTRAINT CAT_PRIX_PLACE_FK
    FOREIGN KEY (SalleId_P, CategorieId) 
       REFERENCES PLACE (SalleId, CategorieId),
  CONSTRAINT CAT_PRIX_C1 CHECK (SalleId_A = SalleId_P)
) ;

• Ou bien le formalisme individuel ne nous le permet pas (à moins que ce ne soit l’AGL), auquel cas on aura à modifier manuellement la structure de la table CAT_PRIX pour retrouver la version 1 de celle-ci.

Quoi qu’il en soit, si l’on modélise directement selon la théorie relationnelle, donc sans passer par le formalisme individuel, on produit directement la version 1 de la table CAT_PRIX, « The fingers in the nose » comme disent certains pragmatiques.

Quant au processus de rétro-conception, en théorie un AGL ne devrait pas avoir de problèmes avec la version 1 de la table, si ce n'est pour fournir une représentation graphique de la contrainte de simultanéité au cas où son métamodèle ne permet pas de la prendre en compte. Même combat concernant la rétro-conception de la table CONCERT (avec l'intéressante contrainte d’inclusion...) Tout cela serait-il du ressort d’une hypothétique version ++ de Merise 2 ? Yves Tabourier, JPhi33, à l'aide...

Ne m'en veuillez pas, mais pour ma part, je modélise plutôt dans le cadre de la théorie relationnelle — c'est très égoïste, mais j'y suis plus à l'aise —, là où les contraintes sont généralement faciles à exprimer et les représentations graphiques sans emploi (même si elles ne me sont pas inutiles). Néanmoins, je me dois de fournir des MCD (voire des diagrammes de classes), car les développeurs aiment bien les avoir sous les yeux quand ils développent dans le cadre de leurs projets. En tout cas j’ai pris note que l’ami bloups n’éprouve pas une attirance folle pour Workbench...

(A suivre donc...)

[JPhi33]

Ou bien le formalisme individuel ne nous le permet pas (à moins que ce ne soit l’AGL), auquel cas on aura à modifier manuellement la structure de la table CAT_PRIX pour retrouver la version 1 de celle-ci.

Le formalisme individuel le permet mais ne prévoit pas (du moins pas à ma connaissance) la prise en compte de ces contraintes lors de la transformation du MCD en MLD. Par conséquent, les AGL de modélisation basés sur Merise ne savent pas non plus dériver les contraintes sémantiques de ce type ; ils permettent de les modéliser mais cela reste du niveau graphique.

Quant au processus de rétro-conception, en théorie un AGL ne devrait pas avoir de problèmes avec la version 1 de la table, si ce n'est pour fournir une représentation graphique de la contrainte de simultanéité au cas où son métamodèle ne permet pas de la prendre en compte. Même combat concernant la rétro-conception de la table CONCERT (avec l'intéressante contrainte d’inclusion...) Tout cela serait-il du ressort d’une hypothétique version ++ de Merise 2 ? Yves Tabourier, JPhi33, à l'aide...

Il faudrait surtout que les éditeurs d'AGL de modélisation se mettent sérieusement au travail. Tous ces concepts existent depuis plus de 15 ans !

[bloups]

Rebonjour fsmrel et JPhi33, désolé pour ce grand laps de temps depuis ma dernière réponse, j'étais en déplacement ces deux dernières semaines.

Cela a été dur de se remettre dans ces MCD et MLD, surtout avec la mine d'informations que vous fournissez à chaque post

Cependant, afin de se remémorer rapidement les détails, j'ai essayé de réunir sans en oublier les objectifs du modèle, les hypothèses faites, mais surtout la dernière version du MLD dans sa version actuelle, en rajoutant certaines informations que je détaille plus bas.

Objectifs obligatoires de l'exercice :
- 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

Il est cependant autorisé de rajouter des fonctions.

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 (sans encore de concert)
- il y a possibilité d'avoir un artiste récemment découvert (n'ayant jamais fait de concert)
- un concert ne peut être joué que par un seul artiste
- un seul concert par jour dans une salle donnée
- un concert n'accueille qu'une et une seule tournée (c'est logique!)
- le prix reste le même si l'artiste revient dans une même salle dans la limite d'une même tournée
- l'écriture d'un commentaire n'est possible que si le client est loggué (je viens de rajouter cette hypothèse au vue du MLD actuel. Je pense que c'est plus simple dans le cas où on autorise les commentaires anonymes).

Artiste(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteBio, ArtisteURL, ArtisteStyleMusique)
Salle(SalleID, SalleNom, SalleAdresse, SalleCP, SalleVille)
Categorie(CategorieID, CategorieLibelle)
Tournee(#ArtisteID, #TourneeID, TourneeLibelle)
Place(#SalleID, #CategorieID, NbPlaces)
Cat_prix(#ArtisteID, #TourneeID, #SalleID, #CategorieID, PrixPlace)
Concert(#ArtisteID, ConcertDate, ConcertHeure, #TourneeID, #SalleID)
Client(ClientID, ClientNom, ClientPrenom, ClientAdresse, ClientCP, ClientVille, ClientPays, ClientEmail, ClientPassword)
Commentaire(#ArtisteID, #ConcertDate, #ClientID, CommentaireDate, CommentaireHeure, CommentaireTexte)

Je me suis permis de rajouter des informations n'ayant aucune incidence sur le modèle.
Par exemple, l'artiste a désormais un style de musique (pour classer les concert par style), le client a une adresse postale complète et un login/password, et le concert a une heure. Pour ce dernier ajout de l'heure, je pense qu'il est facultatif et dépend juste du format de ConcertDate ; si on le met en DD/MM/AAAA ou en DD/MM/AAAA HH:MM (et donc il serait possible d'en extraire l'heure du concert). Je pense qu'il est possible de choisir le format sous MySQL (puis d'extraire plus tard en php).
Il en irait alors de même pour la date du commentaire (=> suppression de CommentaireHeure).


A ce stade du MLD, il ne manque je crois que la modélisation de la réservation.

Je vous laisse là aussi le soin de fournir la liste des données (je ne suis pas un spécialiste de la réservation par Internet...)

Je suis allé chercher dans un de mes tiroirs un billet de concert pour voir les informations qui y figuraient dessus. Apparemment, elles sont toutes déjà modélisées sauf la Date et heure d'achat du billet, et le numéro unique du billet.

De fait, s'il y a un numéro de billet, je présume qu'il existe une entité Billet qui pourrait plus ou moins ressembler à quelque chose comme çà :

Billet(BilletID, BilletDateAchat, BilletHeureAchat, #ClientID, #ArtisteID, #TourneeID, #SalleID, #CategorieID)

Ici encore, la date d'achat peut englober l'heure d'achat (selon le format de date).

[fsmrel]

Salut l’artiste,

j'étais en déplacement ces deux dernières semaines.

La tournée s’est bien passée ? Pas de surbooking ? Quelle était l’ambiance durant les concerts ?

l'artiste a désormais un style de musique

Du point de vue de la modélisation vous avez le choix :

• Au niveau du MCD, définir une entité-type StyleMusique
• Au niveau du MLD, définir une contrainte pour la table Artiste, donnant la liste des styles de musique.

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE ARTISTE 
(
      ArtisteId      CHAR(8)      NOT NULL
    , ArtisteNom     VARCHAR(45)  NOT NULL
    , ArtisteURL     VARCHAR(255) NOT NULL
    , ArtisteBio     VARCHAR(255) NOT NULL
    , Style          VARCHAR(32)  NOT NULL
  , CONSTRAINT ARTISTE_PK PRIMARY KEY (ArtisteId) 
  , CONSTRAINT ARTISTE_STYLE CHECK (Style IN ('Flamenco', 'Country', 'Opérette'))
) ;

Le jour où il faut ajouter un style, pas de problème (ALTER TABLE).


Concernant les billets, si on vous suit, le MLD devient le suivant :


Mais on ne sait pas à quel concert le client va assister. Je verrais donc les choses plutôt ainsi :


On sait quelle tournée et quelle salle sont concernées, par jointure des tables BILLET et CONCERT.

Affaire à suivre...

[bloups]

La tournée s’est bien passée ? Pas de surbooking ? Quelle était l’ambiance durant les concerts ?

Il ne s'agissait malheureusement pas de déplacements pour une tournée, je ne suis en effet pas musicien... mais c'est pas l'envie qui m'en manque ! Le problème est que je suis une vrai quiche en musique

Du point de vue de la modélisation vous avez le choix :
Au niveau du MCD, définir une entité-type StyleMusique
Au niveau du MLD, définir une contrainte pour la table Artiste, donnant la liste des styles de musique.

Je pense que c'est plus simple de créer une entité StyleMusique dès le niveau conceptuel.

Par contre, soit je fais des styles de musique suffisamment gros (exemple : Pop-rock, Rap, RNB, Classique, ...), englobant alors plusieurs sous-type (Pop-rock englobe la pop, le rock, l'indie-pop, ...), soit je dis qu'un artiste peut jouer plusieurs styles de musique mais cela change alors la cardinalité en 1,n. Du coup, il n'est plus possible de mettre StyleMusiqueID en clé étrangère dans Artiste.
Je pense faire au plus simple en utilisant une cardinalité 1,1.
De fait, celà donnerait :

StyleMusique(StyleMusiqueID, StyleMusiqueLibelle)
Artiste(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteBio, ArtisteURL, #StyleMusiqueID)

Je verrais donc les choses plutôt ainsi :


On sait quelle tournée et quelle salle sont concernées, par jointure des tables BILLET et CONCERT.

En effet, je n'ai pas réfléchi suffisamment...

MLD Actualisé :

Artiste(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteBio, ArtisteURL, ArtisteNationalite, #StyleMusiqueID)
StyleMusique(StyleMusiqueID, StyleMusiqueLibelle)
Salle(SalleID, SalleNom, SalleAdresse, SalleCP, SalleVille)
Categorie(CategorieID, CategorieLibelle)
Client(ClientID, ClientNom, ClientPrenom, ClientAdresse, ClientCP, ClientVille, ClientPays, ClientEmail, ClientPassword)
Billet(BilletID, DateAchat, #ClientID, #ArtisteID, #ConcertDate, #CategorieID)

Tournee(#ArtisteID, #TourneeID, TourneeLibelle)
Place(#SalleID, #CategorieID, NbPlaces)
Cat_prix(#ArtisteID, #TourneeID, #SalleID, #CategorieID, PrixPlace)
Concert(#ArtisteID, ConcertDate, #TourneeID, #SalleID)
Commentaire(#ArtisteID, #ConcertDate, #ClientID, CommentaireDate, CommentaireTexte)

J'ai modifié les clés étrangères dans Billet et enlevé les attributs d'heures qui seront normalement gérés dans le format de date de MySQL. J'ai aussi ajouté la nationalité de l'artiste (j'avoue, c'est un gadget :p).

Pensez-vous que le MLD est finalisé dans cette version au vue de l'ensemble des données à faire apparaitre ?

J'ai installé Power AMC v11 (la même que vous normalement) mais je n'arrive pas à faire de MLD (l'option semble inexistante dans le menu...).
Le seul modèle qui ressemble au vôtre est le MPD. Vos schémas seraient-ils des MPD ? Dans tout les cas, j'arrive à mieux les comprendre maintenant

MPD correspondant :




Par contre, je dois fournir le MCD associé à mon MLD, or j'ai cru comprendre qu'aucun logiciel ne pouvait le modéliser suite à l'utilisation de techniques non modélisables... comment faire ?

[fsmrel]

Bonsoir,

Je pense que c'est plus simple de créer une entité StyleMusique dès le niveau conceptuel.

Par contre, soit je fais des styles de musique suffisamment gros (exemple : Pop-rock, Rap, RNB, Classique, ...), englobant alors plusieurs sous-type (Pop-rock englobe la pop, le rock, l'indie-pop, ...), soit je dis qu'un artiste peut jouer plusieurs styles de musique mais cela change alors la cardinalité en 1,n. Du coup, il n'est plus possible de mettre StyleMusiqueID en clé étrangère dans Artiste.
Je pense faire au plus simple en utilisant une cardinalité 1,1.
De fait, celà donnerait :

StyleMusique(StyleMusiqueID, StyleMusiqueLibelle)
Artiste(ArtisteID, ArtisteNom, ArtistePrenom, ArtisteBio, ArtisteURL, #StyleMusiqueID)

Il n’y a bien sûr aucun inconvénient à mettre en œuvre une entité-type StyleMusique. Si un artiste peut jouer plusieurs styles de musique, pourquoi ne pas le modéliser ? Cela donnerait (avec une association-type éventuellement porteuse de propriétés) :

MCD



MLD

Pensez-vous que le MLD est finalisé dans cette version au vue de l'ensemble des données à faire apparaitre ?

Ça l’air de tenir la route.

J'ai installé Power AMC v11 (la même que vous normalement) mais je n'arrive pas à faire de MLD (l'option semble inexistante dans le menu...).
Le seul modèle qui ressemble au vôtre est le MPD.

Il est un fait qu’il a fallu attendre la V15 de l’AGL pour que le concept de MLD soit officiellement pris en compte. Avec la V11, les frites et la confiture sont empilés dans le même morceau de pain. Avec la V11 on passe directement du MCD au MPD, mais il suffit que nous fassions abstraction des index et autres outils de plomberie pour que nous restions dans les hauteurs dont sont absentes les contraintes bassement matérielles des éditeurs de SGBD et que nous produisions des MLD. Disons que le MPD sera pris en compte lors de la production des scripts SQL.

Vos schémas seraient-ils des MPD ?

En vertu de ce que je viens d’écrire, je réponds donc négativement. De la même façon, votre MPD est un MLD.

Dans tout les cas, j'arrive à mieux les comprendre maintenant

Ouf !

Par contre, je dois fournir le MCD associé à mon MLD, or j'ai cru comprendre qu'aucun logiciel ne pouvait le modéliser suite à l'utilisation de techniques non modélisables... comment faire ?

Je vous remercie d’avoir posé la question...

Considérons à nouveau le dernier MLD que je vous ai proposé :



Je ne sais pas ce qu’en pense JPhi33, mais pour le récupérer à moindre frais, à mon avis le plus simple est de partir du MCD suivant :



A partir duquel PowerAMC produit le MLD :



Il suffira d’y faire un minimum de ménage, à savoir virer l’attribut TourneeId de la clé de la table CONCERT. Pour mémoire, PowerAMC se charge ensuite de supprimer l’attribut TourneeId de la table BILLET.

Il faudra quand même prévenir le lecteur que l’on ne peut pas interdire le phénomène de bilocation au stade du MCD.

Maintenant, si vous voulez présenter le MLD (apuré) selon la notation conceptuelle (dixit PowerAMC) pas de problème... :

[JPhi33]

Bonjour,

Je ne sais pas ce qu’en pense JPhi33, mais pour le récupérer à moindre frais, à mon avis le plus simple est de partir du MCD suivant :

Il n'y a pas d'autre solution, avec les AGL actuels, que de contourner la question des associations entre associations au moyen des pseudo-entités n'ayant que des identifiants relatifs (cas de PLACE dans le MCD ci-dessus).

La manière dont sera accueillie cette astuce par le lecteur dépend de sa fonction. S'il s'agit d'un responsable Etudes et Développement, ça passera.
S'il s'agit d'un prof, ça risque de coincer. Il faudra alors expliquer ce qu'est cette pseudo-entité et peut-être recourir aux arguments exposés au fil de cette discussion (attention, certains profs acceptent mal que des élèves utilisent des concepts qu'eux-mêmes ne maîtrisent pas...)

[bloups]

Ça l’air de tenir la route.

Tout d'abord je tiens à vous dire un grand merci à vous deux pour votre aide !

Il n’y a bien sûr aucun inconvénient à mettre en œuvre une entité-type StyleMusique.

Au final j'ai laissé en clé étrangère. J'ai fait des univers musicaux suffisamment larges pour que personne n'ait à être dans 2 différents.
Mais si le besoin s'en fait sentir, il suffira que je crée la table JouerStyle.

S'il s'agit d'un prof, ça risque de coincer.

Il s'agit effectivement d'un prof. Je vais tenter et voir ce que ça donne



Concernant le MCD, je vais attendre d'avoir un MLD finalisé et je vais utiliser comme vous l'avez dit le logiciel qui va me construire le MCD.

Là, je me suis lancé dans la population de la base de données et la mise en place des scripts php pour aller lire tout çà
Un long travail m'attend...

[fsmrel]

Bonjour bloups,

Si vous avez des problèmes avec SQL, n'hésitez pas à venir pleurer dans notre giron, on essaiera de vous aider. S'il s'agit de PHP, il faudra trouver d'autres soutiens...