Discussion :

[shimomura22]

Bonjour à tous ...
Voici mon problème, je dois modéliser un raquette de tennis, cette modélisation fait partie d'un plus grand ensemble car je suis dans l'analyse d'une application qui permet de gérer un magasin de qui s'occupe de vendre, de louer des raquettes de tennis et de corder les raquettes.
Voici mon problème, je coince dans la modélisation d'une raquette de tennis.

Voici un description d'une raquette

Un raquette propose plusieurs modèle et un modèle est proposé par une seule "marque de " raquette jusque la tt va bien.
Là où je coince c'est que un raquette est composée entre autres d'une poignée et d'une "tête" et que ces 2 éléments sont constitué de cordage.
Ces 2 éléments sont "costumisables" c'est-à-dire qu'une poignée peut être faite d'un cordage et que la "tête" peut faire partie d'une autre cordage.

Je vous propose mon MCD


Merci .....

[shimomura22]

Après réflexion je vous propose cette 2éme solution qui je pense me parait plus correcte
La relation entre raquette et modèle reste inchangée

[escartefigue]

Bonjour,

Il s'agit apparemment de modéliser non pas "une raquette de tennis" mais "la commande et l'assemblage d'une raquette de tennis".

La première des choses à faire et de planter un peu le décor, et préciser certains éléments par exemple, une commande ne comporte -t- elle que des raquettes de tennis, ou bien y a -t- il aussi possibilité de commander des balles, des vêtements, des accessoires etc...

Ensuite
- définissez les termes dans un glossaire, ce qui est clair pour vous, ne l'est pas pour les lecteurs non avertis. Par exemple c'est quoi une "main" ?
- décrivez toutes vos règles de gestion en leur affectant un numéro. Exemple

• R001 : une commande concerne 1 ou plusieurs articles
• R002 : un article peut faire l'objet de plusieurs commandes
• R003 : etc...

Quelques remarques sur votre MCD :

Pourquoi mêlez vous des termes anglais (player, ranking...) et français (nom, prénom...) ? Je ne recommande pas cette pratique source d'équivoques et incompréhensions.
Si votre projet est franco-français, ne choisissez que des termes français, si c'est un projet international, préférez l'anglais.
Préférez des infinitifs (ou participe passé) pour identifier les associations. Par exemple "realiser" (ou "réalisé") plutôt que "est réalisé"

Entité-type "PLAYER"
Etes vous certains que seuls des joueurs peuvent commander une/des raquette(s) ? ne pouvez vous pas recevoir des commandes de la part d'un club, d'une association, d'une collectivité, d'une entreprise... Auquel cas il faut modéliser une entité-type personne qui aura des sous-types personne-morale, personne physique... certaines de ces personnes physiques peuvent être des joueurs d'autre non etc...
Les n° de téléphone et adresses courriel ne doivent pas être dans l'entité-type mais dans une autre ET en relation avec l'ET PERSONNE (plutôt que "PLAYER") car une personne peut avoir zéro ou plusieurs téléphone et courriel. Ce qui donne le modèle PERSONNE(id, nom, prenom...) 0,n --- posseder --- (1,1) MEDIA(id, numero...) 1,1 --- typer --- 0,n TYPE_MEDIA (id, code_type, libellé...)
Avec le média identifié relativement à la personne (d'où les parenthèses autour des cardinalités)
Si vous avez prévu que l'attribut préférences soit une liste de valeur (ce que laisse supposer le pluriel) alors c'est une hérésie en terme de modélisation.
Il faut là aussi créer une nouvelle ET en relation avec la personne : PERSONNE 0,n --- préférer --- 0,n CHOIX

Entité-type "COMMANDE"
Une commande ne concerne -t- elle vraiment qu'une et une seule commande (cf. remarque précédente)

Entité-type "RAQUETTE"
Une même raquette peut être attachée à plusieurs commandes ?
Une même raquette peut avoir plusieurs cordages ?

Entité-type "CORDAGE"
Un cordage peut constituer des poignées ?
Pour le béotien que je suis, la poignée c'est la partie de la raquette qui permet de la tenir non ?
Un cordage peut constituer des mains ?

Entité-type "RESERVATION"
Cette ET est là pour réserver quoi ? il manque un lien avec une raquette ou autre

A compléter donc. Bon courage

[UndeadangerousK]

Selon moi, il conviendrait de faire une une relation "Modeliser" qui regrouperait tout les différents éléments d'une raquette et dont l'ID serait composé des ID des éléments et celui de Raquette. Ainsi, on aurait un ID vraiment unique puisque la raquette elle même serait unique.

[UndeadangerousK]

Voici ce que j'aurais fait a ta place. Attention, je ne gère pas la commande ou la location par lot ! Sinon, tu devrais avoir un numéro de lot, avec une entité lot !

[escartefigue]

Bonjour,

Votre relation 'MODELISER' à quatre pattes est une erreur de conception :
En effet, vous mettez en relation une ET RAQUETTE avec chaque composante de la raquette, or c'est bien la combinaison de POIGNEE + CORDAGE + CADRE qui constitue une raquette
En d'autre termes, votre relation 'MODELISER' est en fait l'entité-type RAQUETTE

Donc

• soit on modélise des relations binaires entre l'ET RAQUETTE d'une part, et chacune des ET composantes d'autre part (POIGNEE, CORDAGE et CADRE)
• soit on considère qu'une raquette est en fait la relation entre POIGNEE + CORDAGE + CADRE, soit une relation ternaire, mais cette approche me semble inappropriée, une raquette a une existence propre, c'est bien un individu et donc une entité-type.

Pour info, je n'ai pas souvenir d'avoir déjà rencontré une relation entre 4 entités-types qui ne soit pas une erreur, mais peut être en existe-il

Quoi qu'il en soit, c'est prématuré de proposer un MCD alternatif tant que les règles de gestion n'ont pas été communiquées par le demandeur

[UndeadangerousK]

Si je poste un MCD aussi prématurément, c'est aussi pour profiter de votre expertise dans ce domaine. J'aime beaucoup l'analyse mais j'ai des méthodes parfois... "Exotiques".

Merci pour votre avis, donc, ca me permettra d'améliorer ma technique =)

[escartefigue]

Pas de souci, échanger c'est s'enrichir

Voici à ce titre une possibilité de modélisation

Pièce jointe 339189

ENTITE-TYPE PERSONNE
L'utilisation de l'héritage permet de mutualiser ce qui est commun aux personnes de tous types en particulier l'identifiant, et le fait de posséder zéro ou plusieurs média et zéro ou plusieurs adresses (adresses que je n'ai pas modélisées ici, mais à faire sur le même principe que les médias avec une nouvelle ET et une relation de la PERSONNE vers cette ET)
La spécialisation en personnes physiques ou morales est bien sur par partition (symbole X avec barre inférieure pour Power-AMC, symbole XT dans d'autres outils)
Par contre, les personnes physiques peuvent être soit des joueurs, soit des employés, soit les 2, soit aucun des deux (une personne peut commander une raquette à offrir par exemple)
La commande est en relation avec la personne, quel que soit son sous-type
Cette modélisation évite les redondances et permet à une personne morale ou physique, y compris un employé, de passer commande


Sous-Type EMPLOYE
Il est probable qu'un employé ne fasse pas que du cordage mais plus probablement aussi l'équipement des autres accessoires. En tout cas il faut le permettre.
D'où l'intérêt d'un sous-type EMPLOYE plutôt que "CORDEUR"
S'il est besoin de restreindre certains employés à l'équipement de certains accessoires, alors il faudra enrichir le modèle avec la notion de qualification de chaque employé et en intégrant des CIF


ENTITE-TYPE COMMANDE
J'ai considéré dans mon exemple qu'une personne peut commander soit une raquette, soit des équipements (cordage, poignée, autre...) soit les deux


ENTITE-TYPE ACCESSOIRE
Un accessoire peut être un cordage, une poignée ou tout autre selon le besoin.
Je n'ai pas pris le temps de le modéliser ici, mais on peut bien sur là aussi utiliser l'héritage pour les attributs spécifiques à certains accessoires.


Relation EQUIPER
Un employé équipe une raquette d'un accessoire autant de fois que nécessaire

Voilà une base possible, à enrichir avec les notions que je n'ai pas prises en compte ici (comme la réservation par exemple), en fonction, encore une fois des règles de gestion

[escartefigue]

J'avais été un peu vite en besogne et oublié la ligne de commande, il manquait aussi l'id média
J'en ai profité pour ajouter les adresses.

Pièce jointe 339732