Discussion: Raquette de tennis

  1. #1
    Membre du Club
    Homme Profil pro
    informatique de gestion
    Inscrit en
    janvier 2011
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : informatique de gestion

    Informations forums :
    Inscription : janvier 2011
    Messages : 92
    Points : 67
    Points
    67

    Par défaut Raquette de tennis

    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 .....
    Nom : EA tennis.jpg
Affichages : 110
Taille : 117,1 Ko

  2. #2
    Membre du Club
    Homme Profil pro
    informatique de gestion
    Inscrit en
    janvier 2011
    Messages
    92
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : informatique de gestion

    Informations forums :
    Inscription : janvier 2011
    Messages : 92
    Points : 67
    Points
    67

    Par défaut

    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
    Nom : EA tennis.jpg
Affichages : 96
Taille : 112,0 Ko

  3. #3
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 640
    Points : 8 213
    Points
    8 213
    Billets dans le blog
    1

    Par défaut

    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

  4. #4
    Membre habitué
    Homme Profil pro
    Voyages à dos de Pangolins (Parce que j'aime les pagolins)
    Inscrit en
    juin 2017
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Autre

    Informations professionnelles :
    Activité : Voyages à dos de Pangolins (Parce que j'aime les pagolins)

    Informations forums :
    Inscription : juin 2017
    Messages : 60
    Points : 154
    Points
    154

    Par défaut

    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.

  5. #5
    Membre habitué
    Homme Profil pro
    Voyages à dos de Pangolins (Parce que j'aime les pagolins)
    Inscrit en
    juin 2017
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Autre

    Informations professionnelles :
    Activité : Voyages à dos de Pangolins (Parce que j'aime les pagolins)

    Informations forums :
    Inscription : juin 2017
    Messages : 60
    Points : 154
    Points
    154

    Par défaut Par exemple

    Nom : idee.PNG
Affichages : 73
Taille : 90,8 Ko

    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 !

  6. #6
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 640
    Points : 8 213
    Points
    8 213
    Billets dans le blog
    1

    Par défaut

    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

  7. #7
    Membre habitué
    Homme Profil pro
    Voyages à dos de Pangolins (Parce que j'aime les pagolins)
    Inscrit en
    juin 2017
    Messages
    60
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Autre

    Informations professionnelles :
    Activité : Voyages à dos de Pangolins (Parce que j'aime les pagolins)

    Informations forums :
    Inscription : juin 2017
    Messages : 60
    Points : 154
    Points
    154

    Par défaut

    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 =)

  8. #8
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 640
    Points : 8 213
    Points
    8 213
    Billets dans le blog
    1

    Par défaut

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

    Voici à ce titre une possibilité de modélisation

    Nom : MCD_Raquette_V00.png
Affichages : 62
Taille : 77,6 Ko

    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

  9. #9
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 640
    Points : 8 213
    Points
    8 213
    Billets dans le blog
    1

    Par défaut

    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.

    Nom : MCD_Raquette_V01.png
Affichages : 71
Taille : 101,2 Ko

Discussions similaires

  1. [Debutant] Modélisation d'une appli gérant les commandes d'un client
    Par etiennegaloup dans le forum Diagrammes de Classes
    Réponses: 10
    Dernier message: 08/08/2006, 10h02
  2. [UML] modelisation d'une navigation
    Par ypicot dans le forum UML
    Réponses: 6
    Dernier message: 12/02/2006, 15h58
  3. Réponses: 9
    Dernier message: 07/07/2005, 08h34
  4. Modelisation d'une médiatheque
    Par Sylk dans le forum Décisions SGBD
    Réponses: 6
    Dernier message: 05/11/2004, 09h28
  5. modelisation d'une piste de ski
    Par djbed dans le forum Algorithmes et structures de données
    Réponses: 6
    Dernier message: 28/06/2004, 16h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo