Discussion :

[poulping]

Bonjour.
J'ai voulu modéliser les tables d'un site Web traitant de musique.
Mon intention a été de traiter les points suivants :

- un artiste peut posséder une ou plusieurs professions.
- un artiste possède un style musical.
- un artiste "travaille" sur des disques (que l'on retrouve via l'entite "label").
- un label produit des disques.
- un disque est produit par un label.

J'ai mis en place de l'héritage concernant la qualité du disque : un album ou un Riddim (ce dernier qualifiant la version instrumentale d'une chanson, réutilisable par d'autres artistes).
On doit pouvoir rattacher les chansons à un riddim ou un album.

Pour l'héritage j'ai voulu placer une contrainte XT mais je n'ai pas réussi avec ce logiciel.
Je n'aime pas trop cette solution pour l'instant car on pourrait très bien rajouter une propriété dans disque afin de de déterminer sa nature.
En même temps je me dis que je n'ai peut être pas encore pensé à toutes les différences existantes entre un single et un album...

- un disque est composé de titres.
- un titre peut être présent sur plusieurs disques.

Viennent ensuite les revendeurs...
- un revendeur distribue des disques, leur prix étant déterminé en fonction du revendeur et du disque.
J'ai mis l'adresse dans l'entité Revendeur car je pensais que beaucoup de revendeurs n'aurait qu'une enseigne.
En me relisant je pense que cette solution est incorrect du fait du 1,1 du côté de succursales.
Peut être devrais-je descendre les prorpriétés adresses / coordonnées dans succursales et ajouter un champ siège (à 1 si la succursale est le siège) ?
J'ai voulu faire une entité faible de succursales, mais je n'ai pas réussi avec cette version d'essai de PowerDesigner 9.5...
Est ce moi ou n'est ce pas possible? (j'ai pourtant parcouru l'aide qui indique comment faire mais je n'ai pas trouvé les menus correspondants...)

Bref j'ai utilisé le formalisme #nompropriété# pour indiquer (schématiquement) l'entité faible.

J'aimerais donc vos avis éclairés concernant ce schéma !
Enfin je m'excuse pour l'éventuelle illisibilité de la photo car c'est la première fois que j'utilise l'outil.

Merci !

[fsmrel]

Bonjour Poulping

Pour mettre en œuvre l’identification relative avec Power AMC :

Cliquer sur le lien entre "Succursales" et "Avoir". Apparaît la fenêtre "Propriétés du lien d’association". Cocher la case à cocher "Identifiant".

Entité-type Succursales : mettre au singulier (vous décrivez une succursale-type).
Une succursale fait-elle nécessairement l’objet d’une entité-type faible ? Que se passe-t-il quand une entreprise E1 reprend des succursales de l’entreprise E2 ?

Selon votre MCD, un artiste "travaille" non pas sur des disques, mais sur tous les disques produits par les labels avec lesquels il est en relation.

Concernant l’héritage impliquant Album et Riddim : un album et un riddim ont un nom. Les attributs R_Nom et AL_Nom peuvent donc réintégrer l’entité-type Disque. Si vous ne prévoyez pas d’attributs spécifiques pour Riddim, cette entité-type n’ayant plus d’attributs en propre (pas plus que de relations en propre), l’héritage n’offre pas ici un intérêt décisif. En fait, Disque peut absorber Album et Riddim, auquel cas vous dotez Disque d’un attribut Type_de_disque, pour savoir à quel type de disque on a à faire. Étant donné que l’attribut AL_TrackList ne concerne que les albums, vous conservez l’entité-type Album (en lui donnant un autre nom...) et en faites une entité-type faible (relation 0-1/ (1,1)).

Concernant les adresses, les entreprises et établissements on en général plusieurs adresses (adresse de facturation, de règlement, etc.) Un revendeur ne peut-il pas avoir des adresses qui ne figurent pas au niveau des succursales ?

[poulping]

Merci pour ta réponse.
Concernant l'héritage, je suis d'accord avec toi : on peut aisément remonter les propriétés dans DISQUE de RIDDIM et ALBUM. L'héritage me servais de roue ed secours si certaines propriétés spécifiques se manifaistaient, ce qui ne semble pas être le cas.
Merci pour l'idée de l'entité faible de AL_TrackList, je pensais ne lui donner une valeur que si le disque en question est un album

Un artiste ne travaille pas directement sur un album.
C'est voulu. En fait je veux être sur qu'un artiste ne chante que sur des "disques produits".

J'ai noté ton conseil concernant les adresses et devrais je donc lier les différents établissements à une table ADRESSE via une n,n ?

Merci beaucoup pour avoir pris du temps pour analyser ce MCD (le premier dans un but de projet)

Je le complète et vous donnerai la version finale plus tard (prise en charge de concerts etc...)

[fsmrel]

Je suis favorable à la mise en œuvre d’une entité-type Adresse, mais à condition qu’elle soit faible, par rapport à une entité-type parente "forte". Pour avoir crapahuté dans de nombreux référentiels, comportant des tables à bonne volumétrie (tables Adresse à plus de dix millions de lignes et d’autres tables à plus de cent millions de lignes), j’ai vérifié que les entités-types fortes Adresse étaient un facteur de gros ralentissements lors du rapprochement des personnes (entreprises, établissements, individus, etc.) avec leurs adresses (traitements de type batch ou transactionnel lourd). Je m’en suis déjà expliqué sur ce forum (phénomène de l’I/O bound correspondant à des attentes pour fin d’entrées/sorties, entraînant des ralentissements très importants).

Par contre, si l’on définit une entité-type (forte) du genre Personne et qu’on lui associe Adresse en tant qu’entité-type faible, on sait (au niveau physique) éliminer ces ralentissements (grâce à la mise en œuvre au niveau conceptuel de l’identification relative donnant lieu au niveau physique au clustering, au sens DB2/zOS du terme : regroupement dans une même page physique des adresses des personnes, par opposition à leur éparpillement).

Si l’exercice vous tente, vous pouvez utiliser cette fois-ci l’héritage :
Une entité-type Personne (ou tout autre nom générique) avec pour sous-types : Revendeur, Succursale, Label, Artiste.

Une ébauche de MCD :