Discussion :

[xxxseblxxx]

Bonjour, je suis étudiant en dernière année d'un Bachelier. Je dois élaborer une analyse et une solution logicielle pour mon mémoire. J'ai choisis de présenter une gestion de stock, pour laquelle j'ai construit le MCD qui suit, mais j'aimerais quelques avis et vos critiques sur celui-ci... Merci

(Le MCD est en pièce jointe tfe_3.png)

[fsmrel]

Bonsoir,

je suis étudiant en dernière année d'un Bachelier

Quelle discipline ?

Vous ne fournissez pas les règles de gestion des données de votre MCD, on ne peut donc pas donner d'avis pertinent sur la justesse de votre modélisation.

Votre diagramme est trop chargé, donc fouillis, à la limite de la lisibilité : il faudrait le découper en vues.

Je note que, via l'entité-type Informations_Personnelles, une personne est simultanément propriétaire, fournisseur et client, ce dont on peut carrément douter...

Vous pourriez utiliser un autre outil qu'AnalyseSI. Dans les gratuits, vous avez OPen ModelSphere, qui vous permet de représenter (sous forme de diagrammes de classes) les relations d'héritage qui manifestement concernent les entités-types Propriétaire, Client et Fournisseur.

Le nom des identifiants est invariablement suffixé par « PK » qui est l’abréviation de Primary key, concept SQL (et jadis relationnel). Comme vous vous situez au niveau conceptuel, il serait préférable de suffixer par « Id ».

Je passe le relais au relecteur suivant.

[CinePhil]

Je commence à lire le MCD...

Utilisateur -1,1----POSSEDER----1,n- Proprietaire

Traduction :
Un utilisateur est possédé par un seul propriétaire et un propriétaire possède de un à plusieurs utilisateurs.

Bizarre cette notion de possession non ?

Proprietaire -1,1----DISPOSER----1,1- Information_Personnelle

Remarque 1 : On nomme en principe les entités au singulier ; j'ai corrigé ci-dessus le pluriel de "Informations_Personnelles" figurant sur le schéma.

Remarque 2 : Des cardinalités (1,1 - 1,1) signifient le plus souvent qu'on peut fusionner les deux entités. Ici en réalité, je pense que c'est le propriétaire qui peut être fusionné avec l'utilisateur, ce qui donnerait plutôt le MCD suivant :

Utilisateur -1,n----POSSEDER----1,1- Information_Personnelle

Traduction :
Un utilisateur possède une à plusieurs informations personnelles et une information personnelle est la propriété d'un seul utilisateur.

Ce n'est pas mieux comme ça ?

Utilisateur -0,1----PRODUIRE----1,1- Produit_Fini

Traduction :
Un utilisateur peut produire un seul produit fini et un produit fini ne peut être produit que par un seul utilisateur.

Si vos "utilisateurs" sont, entre autre, les ouvriers chargés de la production, ils ne travaillent pas beaucoup !
=> Ne vaudrait-il mieux pas 0,n à la place de 0,1 ?

Utilisateur -0,n----ABIMER----0,n- Produit_Fini

Traduction :
Un utilisateur peut abîmer plusieurs produits finis et un produit fini peut être abîmé par plusieurs utilisateurs.

Déjà qu'ils ne peuvent produire qu'un seul produit, si en plus ils peuvent se mettre à plusieurs pour abîmer plusieurs produits... vous êtes sûr que vous avez besoin d'une gestion de stock ?



J'arrête là et je voterais, si je trouvais ce sondage utile, "A retravailler fortement" !

[Richard_35]

Bonjour à tous,

Juste pour expliquer mon vote : "A retravailler fortement".

@Xxxseblxxx :
Je pense que tu peux, facilement, te mettre à la place des personnes de ce forum qui ne connaissent pas ton contexte et voient arriver un MCD "tissé" par Spiderman (ce n'est pas de moi : rendons à Fabien, ce qui est à Cesar).

En bref, je te conseille de segmenter ta réflexion, comme conseillé par Fsmrel, et demander des avis/conseils par "tranches" de ton MCD (par "vues", donc). Après, en recollant tous les bouts (travail qui t'incombe) tu devrais pouvoir t'en sortir.

[xxxseblxxx]

Je commence à lire le MCD...

Utilisateur -1,1----POSSEDER----1,n- Proprietaire

Traduction :
Un utilisateur est possédé par un seul propriétaire et un propriétaire possède de un à plusieurs utilisateurs.

Bizarre cette notion de possession non ?

Proprietaire -1,1----DISPOSER----1,1- Information_Personnelle

Remarque 1 : On nomme en principe les entités au singulier ; j'ai corrigé ci-dessus le pluriel de "Informations_Personnelles" figurant sur le schéma.

Remarque 2 : Des cardinalités (1,1 - 1,1) signifient le plus souvent qu'on peut fusionner les deux entités. Ici en réalité, je pense que c'est le propriétaire qui peut être fusionné avec l'utilisateur, ce qui donnerait plutôt le MCD suivant :

Utilisateur -1,n----POSSEDER----1,1- Information_Personnelle

Traduction :
Un utilisateur possède une à plusieurs informations personnelles et une information personnelle est la propriété d'un seul utilisateur.

Ce n'est pas mieux comme ça ?

Utilisateur -0,1----PRODUIRE----1,1- Produit_Fini

Traduction :
Un utilisateur peut produire un seul produit fini et un produit fini ne peut être produit que par un seul utilisateur.

Si vos "utilisateurs" sont, entre autre, les ouvriers chargés de la production, ils ne travaillent pas beaucoup !
=> Ne vaudrait-il mieux pas 0,n à la place de 0,1 ?

Utilisateur -0,n----ABIMER----0,n- Produit_Fini

Traduction :
Un utilisateur peut abîmer plusieurs produits finis et un produit fini peut être abîmé par plusieurs utilisateurs.

Déjà qu'ils ne peuvent produire qu'un seul produit, si en plus ils peuvent se mettre à plusieurs pour abîmer plusieurs produits... vous êtes sûr que vous avez besoin d'une gestion de stock ?



J'arrête là et je voterais, si je trouvais ce sondage utile, "A retravailler fortement" !

Bonjour et merci pour votre réponse rapide et complète. J'ai tenu compte de vos conseils et recréé un MCD (mcd.rar désolé j'ai du compresser vu que je suis limité à 5 pièces jointes) sous forme de vue, l'autre semblait illisible de fait (d'où je demandais conseil).

J'ai mis à disposition le travail entier (EI.doc) afin que vous ayez le contexte et "l'analyse" préalable. En ce qui concerne "abîmer", je voulais simplement prévoir le cas si cela se présentait, l'article rentrerait donc avec une autre valeur dans le stock.

Pour répondre à votre question si j'ai besoin d'une gestion de stock, il se trouve que je suis dans l'obligation de présenter un mémoire en juin, et cette gestion en est le projet (hélas le seul que j'ai pu trouver)

Vos précieux conseils me seront toujours utiles.

Merci beaucoup

[xxxseblxxx]

Bonsoir,



Quelle discipline ?

Vous ne fournissez pas les règles de gestion des données de votre MCD, on ne peut donc pas donner d'avis pertinent sur la justesse de votre modélisation.

Votre diagramme est trop chargé, donc fouillis, à la limite de la lisibilité : il faudrait le découper en vues.

Je note que, via l'entité-type Informations_Personnelles, une personne est simultanément propriétaire, fournisseur et client, ce dont on peut carrément douter...

Vous pourriez utiliser un autre outil qu'AnalyseSI. Dans les gratuits, vous avez OPen ModelSphere, qui vous permet de représenter (sous forme de diagrammes de classes) les relations d'héritage qui manifestement concernent les entités-types Propriétaire, Client et Fournisseur.

Le nom des identifiants est invariablement suffixé par « PK » qui est l’abréviation de Primary key, concept SQL (et jadis relationnel). Comme vous vous situez au niveau conceptuel, il serait préférable de suffixer par « Id ».

Je passe le relais au relecteur suivant.

Bonjour et merci également pour votre réponse. J'ai refais le MCD sous forme de vues afin de le rendre plus lisible comme vous m'aviez conseillé et j'ai également utilisé Open ModelSphere. Je n'ai pas encore replacé les attributs, qui resteront globalement les mêmes.

Je suis étudiant dans un Bachelier en informatique de gestion (Analyste-Programmeur), mais ayant pour la première fois une analyse de cette taille en temps réel à faire, j'ai un peu de mal.

J'ai placé le travail entier pour que vous disposiez du contexte en pièce jointe.

Vos conseils et critiques sont les bienvenus.

Merci à vous

[fsmrel]

Bonsoir,


Vous pourriez fournir une vue concernant le référentiel des personnes :




Évitez de suffixer les attributs identifiants par « PK » qui est connoté. « Id » est plus conceptuel et neutre.
Dans votre MCD, l’utilisateur (qui est plutôt employé que possédé, quoique...) n’a pas de nom, de coordonnées, genre téléphone ?

PERSONNE joue le rôle de surtype, PROPRIETAIRE, CLIENT et FOURNISSEUR celui de sous-type et en conséquence n’ont pas d’identifiant en propre ; Ils héritent de l’identifiant de PERSONNE (cardinalité soulignée : 1,1).

Je vous laisse le soin de prendre en compte les attributs de ces entités-types.