Discussion :

[remax007]

Bonjour,

J'aimerai pour mon service creer une BDD concernant la gestion des stocks de notre matériel.
Après avoir longtemps parcouru le forum j'ai établi des règles de gestion ainsi que le MCD correspondant que vous trouverez ci dessous.

Poblèmatique: Dans un premier temps j'aimerai savoir si mon MCD ne comporte pas d'erreur et dans un second temps comment passer du MCD au MLD. Mon SGBD sera ACCESS 2010. Merci d'avance





Règle de gestion de l’entreprise

RG01 Un ARTICLE peut hériter d’un ARTICLE PROJET

RG02 Un ARTICLE PROJET est associé à un ou plusieurs PROJETS
RG03 Un PROJET peut être associé à un ou plusieurs ARTICLE PROJET

RG04 Un ARTICLE est associé à une CATEGORIE
RG05 Une CATEGORIE peut associer un ou plusieurs ARTICLES
RG06 Les CATEGORIES sont hiérarchisées

RG07 Un ARTICLE est stocké dans un RAYON
RG08 Un RAYON stocke un ou plusieurs ARTICLES

RG09 Un ARTICLE peut être désigné par une ou plusieurs LIGNES DE COMMANDE
RG10 Une LIGNE DE COMMANDE désigne un ARTICLE

RG11 Une LIGNE DE COMMANDE est RECEPTIONNEE
RG12 On RECEPTIONNE une ou plusieurs LIGNES DE COMMANDE

RG13 On COMMANDE une ou plusieurs LIGNES DE COMMANDE
RG14 Une LIGNE DE COMMANDE correspond à une COMMANDE

RG15 Une COMMANDE est effectuée par un USER
RG16 Un USER peut effectuer plusieurs COMMANDES

RG17 Une COMMANDE est livrée par un ou plusieurs FOURNISSEUR
RG18 Un FOURNISSEUR peut livrer plusieurs COMMANDES

RG19 Un ARTICLE peut être catalogué chez un ou plusieurs FOURNISSEURS
RG20 le FOURNISSEUR catalogue un ou plusieurs ARTICLES

RG21 Un ARTICLE peut être associé à un PACKAGE
RG22 Un PACKAGE est associé un ou plusieurs ARTICLES

[fsmrel]

Bonjour remax007,

J'ai établi des règles de gestion ainsi que le MCD correspondant que vous trouverez ci dessous.

Règles et MCD se correspondent.

En prévision du MLD, il faudrait doter chaque entité-type de son identifiant au sens Tabourier, c'est-à-dire artificiel, invariant et non significatif.

Pourquoi avoir représenté une grosse flèche noire dont la signification précise reste à fournir ? (Vous évoquez l’héritage, mais ça reste ambigu et à justifier). Sauf démenti argumenté de votre part, on pourrait avoir la représentation :

[ARTICLE_PROJET]----?,?----( )---- ?,?----[ARTICLE]

Où les cardinalités restent à préciser.

Je vais regarder le reste.

[remax007]

Merci pour vos réponses,

Oui en effet cette flèche correspond à l'héritage. J'ai ajouté cette notion d’héritage pour plusieurs raisons.

Par exemple : l'article projet correspond à une Résistance de 10K.

En stock nous avons par exemple une une Résistance de 10K 5% et une Résistance de 10K 1% qui peuvent convenir d'où la notion d’héritage.

Ensuite une autre raison est que cette même résistance 10K a un panel de fabricant. Notre résistance de 10K qui est en stock ne fait pas partie du panel de fabricants mais comme elle est similaire dans ces attributs je veux qu'elles soient quand même lier.

[fsmrel]

Oui en effet cette flèche correspond à l'héritage

L’héritage est utilisé à l’occasion de la spécialisation (ou dans l’autre sens, la généralisation) des entités-types :

Par exemple, par spécialisation, une personne peut être une personne physique, même principe pour une personne morale. Néanmoins, une personne est soit une personne physique (vous), soit une personne morale (votre entreprise), mais pas les deux, et une personne physique ne peut pas être à la fois plus d’une personne physique (vous et moi)...

Si j’interprète votre flèche au sens habituel, ARTICLE serait une spécialisation de ARTICLE_PROJET : tout article (entité-type ARTICLE) est un article (entité-type ARTICLE_PROJET) en relation avec au moins un projet. La représentation correspondante est celle-ci :

[ARTICLE_PROJET]----0,1----(Hériter)---- 1,1----[ARTICLE]

Par ailleurs, si je conçois qu’une résistance de 10K 5% ne peut être qu’une résistance, tout comme ne peut que l’être une résistance de 10K 1%, il se trouve que l’héritage correspond mathématiquement à l’injection, c'est-à-dire qu’une résistance ARTICLE_PROJET a au plus une image ARTICLE, soit une résistance de 10K 5%, soit une résistance de 10K 1% mais pas les deux à la fois...

Maintenant, si un article projet (entité-type ARTICLE_PROJET) a nécessairement une image article (entité-type ARTICLE), l’injection est à remplacer par une bijection, ce qui manifestement n’est pas ce qui vous concerne, auquel cas il ne reste guère que la possibilité de la surjection :

[ARTICLE_PROJET]----1,N----( )---- 1,1----[ARTICLE]

Ou de l’application dans :

[ARTICLE_PROJET]----0,N----( )----1,1----[ARTICLE]

Etc.

Mais il n'y a plus d'héritage au sens de la modélisation des données. Concernant les relations ARTICLE_PROJET - ARTICLE, il faudrait donc que vous reprécisiez les règles de gestion telles que les conçoit l’utilisateur, sans utiliser le langage technique du concepteur de modèle, à savoir le mot « hériter », trop connoté, donc piégeant et ne pourra être utilisé qu'après justification formelle.

Par ailleurs, il y a le problème des articles, par exemple des résistances 10K figurant au catalogue des fournisseurs. On peut bien sûr établir des relations entre ces résistances et celles dont nous venons de parler, mais là aussi cela mérite d’être détaillé pour qu’on parvienne à la représentation graphique qui convient.

[fsmrel]

Autre sujet


L’entité-type RECEPTION pose un problème : elle est dotée d’un attribut ReceptionQté tel qu’en en toute logique une quantité d’une réception donnée peut être associée, comparée à différentes (quantités de) lignes de commande, appartenant à des commandes différentes...

Il serait préférable d’attacher à l’entité-type LIGNE_DE_COMMANDE l’entité-type RECEPTION de la façon suivante :

Notation PowerAMC :

[LIGNE_DE_COMMANDE]----0,N----( )----(1,1)----[RECEPTION]

Notation WinDesign :

[LIGNE_DE_COMMANDE]----0,N----( )----1,1 (R)----[RECEPTION]

Notation UML :

[LIGNE_DE_COMMANDE]◄►-1------0..N---[RECEPTION]

AU stade MLD ; cela donne :



Pour savoir où l’on en est des réceptions pour une ligne de commande ou une commande données, en SQL ça sera très simple.