Discussion :

[Nohant]

Bonjour,

Un peu rouillé sur la méthode Merise je suis intéressé par vos conseil pour modéliser au mieux la situation suivante :

Il s'agit d'un système de classique de commande : Un client passe une commande de n articles différents pour une quantité y.

La particularité tient au fait que certains types d'articles ont deux caractéristiques particulières :

1. une date limite de validité dont le client peut modifier la valeur par défaut (dans une plage définie)
2. un n° de série unique et spécifique à chaque type d'article doit généré pour chaque article commandé.

Ex le client commande 2 articles A, 3 articles B et 1 article C.

L'article A ne comporte pas de n° de série.
Pour l'article B il est nécessaire de générer autant de n° de série qu'il y a de quantité d'article B. Pour cela on récupère le dernier numéro de série en base et on l'incrémente. Le n° de série est constitué d'un partie spécifique au type d'article et une partie séquentielle
Par ex s'il est à B10 on va générer les n° de série B11, B12 et B13. Le numéro de série permet d'identifier la commande d'origine et donc le client ainsi que le produit.
Idem pour l'article C, le dernier n° est en base est C32, on génère le n° C33.

pour les articles comportant une date de fin de validité, elle est la même pour la quantité d'article commandé (par ex si on commande 10 articles B, ils auront tous la même date de fin de validité dont la valeur par défaut peut être modifiée par le client mais il n'est pas possible d'avoir dix date de fin de validité différentes).

Pour l'instant j'ai commencé ça sur mon cahier mais je vais chercher un outil pour essayer de mettre ça au propre.

En tout cas tout aide, conseil ou suggestion sera fortement appréciée,
Merci d'avance

[freud]

Bonjour,


L'entité ARTICLE devrait comporter un attribut TYPE_ARTICLE pour identifié son type :

-Standard,
-Sérialiser,
-Lot,
-..........

(IdArticle, Nom_Article,Type_article, PU)

.....il est nécessaire de générer autant de n° de série qu'il y a d'article B.

Autant de n° de série qu'il y a de quantité d'article B vous voulez dire ?

[Nohant]

Merci de cette première réponse.

c'est effectivement une formulation incorrecte de ma part, je corrige l'énoncé

donc l'ajout d'une entité type d'article permet de distinguer les deux catégories d'article cad ceux qui disposent d'une date de fin de validité et d'un n° de série et les autres (c'est une donnée stable il y a en réalité quatre articles possibles, deux comportent une deux de fin de validité et des n° de série, et les deux autres non).

Je fais un MCD électronique pour la fin de l'après-midi qui permettra de poser des bases, en attendant je suis toujours preneur d'info

[freud]

Oui je pense qu'il faut ajouter une entité TYPE_ARTICLE qui permet non seulement de distinguer les deux catégories mais autant de categories que l'on veut. Dans la future application cela devient paramétrable. Cela signifie que la gestion de tel article est soit standard (normale), soit sérialiser, soit autre..... et quand aux numéros de series je suppose que c'est l'article qui doit-être gerer en n° de series et il doit y avoir une entité NUMERO_SERIE.

[Nohant]

Bon je viens de faire un premier essai et j'ai du mal à voir l'intérêt de l'ajout d'une entité Type_Article pour modéliser le fait que certains article peuvent avoir un n° de série et une date de fin de validité. Je bloque sur le fait que chaque exemplaire de certaine catégories d'article aura un n° de série unique généré lors de la commande.

Par ailleurs est-il correct de considérer que la date de fin de validité d'un article peut être une propriété de la relation "porter" dans la mesure où elle est identique dans une commande pour un type d'article donné et malgré le fait que pour certains articles cette notion n'existe pas ?

[freud]

Bonjour,

j'ai du mal à voir l'intérêt de l'ajout d'une entité Type_Article pour modéliser le fait que certains article peuvent avoir un n° de série et une date de fin de validité.

Parce qu'il va falloir ajouter une entité NUMERO_SERIE :
NUMERO_SERIE (#num_serie,Id_Art,date_validite).
Les numéros de serie créer seront stockés dans cette table avec eventuellement un champ de plus "STATUS" qui representera l'etat de l'article (en stock, vendu, retourné,etc...) afin de pouvoir gerer la tracabilité des numéros de serie d'articles.
L'entité Type_Article avec la migration du champ ID_TYPE_ART comme clé etrangere vers la table ARTICLE permettra de distinguer parmi les articles qui sont gerer par numero de serie ou autres. Mais si on a que deux types d'articles, je pense que l'on pourra s'en passer et ne garder que le champ TYPE_ARTICLE dans la table ARTICLE.

est-il correct de considérer que la date de fin de validité d'un article peut être une propriété de la relation "porter"

date de fin de validité du numero de serie ou de l'article commandé ?

A la place de la relation "porter" je pense qu'il faut mettre l'habituelle association "COMPOSER" parce qu'une commande sera composée de 1 ou n lignes d'articles dans l'entité LIGNE_COMMANDE relié à COMMANDE :

COMMANDE_CLIENT(ID_CDE,DATE_CDE, REFERENCE_INTERNE_CLIENT,....)
LIGNE_COMMANDE(ID_LIGNE,ID_CDE,ID_ART,QTE,PU)

Concernant les adresses de livraisons dans COMMANDE.....
Elle vont se répeter pour un même client donc il vaudrait mieux les externaliser dans une nouvelle entité ADRESSE :
ADRESSE [(ID_ADR,LIGNE_UN,LIGNE_DEUX,LIGNE_TROIX,LIGNE_QUATRE,CODE_POSTAL,VILLE, TYPE_ADR)
et de migrer l' ID_ADR dans l'entité COMMANDE.

Le TYPE_ADR c'est dans le cas oû le client possederait plusieur types d'adresses (livraison,facturation)

[Nohant]

Tout d'abord merci pour cette réponse qui me permet de m'interroger et de me stimuler et ça c'est bon

Parce qu'il va falloir ajouter une entité NUMERO_SERIE :
NUMERO_SERIE (#num_serie,Id_Art,date_validite).
Les numéros de serie créer seront stockés dans cette table avec eventuellement un champ de plus "STATUS" qui representera l'etat de l'article (en stock, vendu, retourné,etc...) afin de pouvoir gerer la tracabilité des numéros de serie d'articles.

tel que je vois cette solution on ne pourra pas à partir d'un n° de série identifier la commande correspondante ?

Par ailleurs il n'y a pas de besoin de gestion de stock ni de gestion des tarifs (la facturation est gérée à part). Pour expliciter : lorsqu'un client passe commande, un ordre de fabrication et d'expédition est adressé à un industriel indiquant les articles commandé et la quantité et avec pour les articles qui le nécessitent la date de fin à indiquer et les n° de série à utiliser. Les n° de série ne sont générés que lors du passage d'une commande.

L'entité Type_Article avec la migration du champ ID_TYPE_ART comme clé etrangere vers la table ARTICLE permettra de distinguer parmi les articles qui sont gerer par numero de serie ou autres. Mais si on a que deux types d'articles, je pense que l'on pourra s'en passer et ne garder que le champ TYPE_ARTICLE dans la table ARTICLE.

je ne vois toujours pas en quoi l'ajout de l'entité Type_Article apporte comme solution à mon problème. Donc sauf si ça peut servir à résoudre le problème des n° de série, je n'ai pas besoin de distinguer les types d'articles.

date de fin de validité du numero de serie ou de l'article commandé ?

date de fin de validité de l'article commandé. Pour une commande donnée elle est unique pour tous les exemplaires d'un article donné (si commande de 10 articles B, les dix auront la même date de fin de validité cad soit la date de fin de validité par défaut, soit la date de fin validité choisie par le client dans une plage prédéfinie.

A la place de la relation "porter" je pense qu'il faut mettre l'habituelle association "COMPOSER" parce qu'une commande sera composée de 1 ou n lignes d'articles dans l'entité LIGNE_COMMANDE relié à COMMANDE :

COMMANDE_CLIENT(ID_CDE,DATE_CDE, REFERENCE_INTERNE_CLIENT,....)
LIGNE_COMMANDE(ID_LIGNE,ID_CDE,ID_ART,QTE,PU)

"Porter" ou "composer" je ne pense pas que ça change qq chose de fondamental (j'utilise le verbe porter dans le sens de "une commande porte sur n article) ce qui importe ce sont les cardinalités mais je peux me tromper ?

par ailleurs là on parle MLD ? non ? car justement LIGNE_COMMANDE devrait être la table résultant de l'association "porter" ? je répète je suis totalement rouillé sur Merise donc je peux me gourer

enfin LIGNE_COMMANDE(ID_LIGNE,ID_CDE,ID_ART,QTE,PU) suppose que l'on peut avoir plusieurs lignes de commande d'un même article ce qui dans le cas présent n'est pas possible/voulu d'où l'intérêt d'avoir au niveau MLD un clé composée de ID_CDE + ID_ART.

Concernant les adresses de livraisons dans COMMANDE.....
Elle vont se répeter pour un même client donc il vaudrait mieux les externaliser dans une nouvelle entité ADRESSE :
ADRESSE [(ID_ADR,LIGNE_UN,LIGNE_DEUX,LIGNE_TROIX,LIGNE_QUATRE,CODE_POSTAL,VILLE, TYPE_ADR)
et de migrer l' ID_ADR dans l'entité COMMANDE.

Le TYPE_ADR c'est dans le cas oû le client possederait plusieur types d'adresses (livraison,facturation)

ce choix est totalement volontaire et assumé. Il ne s'agit pas de client particulier mais de professionnels disposant de nombreux sites possibles de livraison. Un même client peut passer plusieurs commande qui seront livrées à plusieurs adresses, une commande n'étant livrée qu'à une seule adresse.
Par ailleurs il s'agit de commande transmises par mail/fax et ressaisies ensuite par un opérateur donc avoir une table des adresses de livraison présente peu d'intérêt car il y aurait plus de temps perdu à vérifier si l'adresse sur le bordereau correspond à une adresse déjà enregistrée.

Mais ne nous déconcentrons pas, la question principale concerne la manière la plus appropriée de modéliser la question des articles disposant ou non de n° de série et de date de fin de validité.

Et je suis tout ouïe pour qu'on m'explique mes erreurs ou pour avoir des suggestions (même si je suis pas d'accord avec ça fait quand même avancer le schmilblick).

[Nohant]

Bon,

Je patauge, je patauge, j'ai refais le MCD sous PowerAMC en ajoutant l'entité Numéro de série grâce à Freud.

Je pense l'avoir lié correctement aux entités commande et article par contre le MCD actuel ne permet pas de représenter que le nombre de n° de série générés doit correspondre au nombre d'articles commandés et au type d'article. Il doit manquer une contrainte entre les relations je ne sais pas comment les modéliser dans PowerAMC (version 15 de démo).

Sinon j'ai ensuite penser créer un sous type de l'entité Article qui serait Article_Serie qui exprimerait l'idée des articles dotés de n° de série et de date de fin de validité mais ça me donne une entité sans attribut et de plus je ne vois pas comment on dessine ça dans PowerAMC (si c'est possible ...)?

Au passage ça existe sous PowerAMC la notion de propriété composée (pour l'adresse notamment) ?

[CinePhil]

1) Tu as des articles dont chaque exemplaire vendu aura un numéro de série et une date de validité et d'autres articles vendus sans ces références.

Il y donc bien, comme le suggérait Freud, deux types d'articles et potentiellement plusieurs autres :
- Ceux à numéro de série et date de validité ;
- Ceux sans numéro de série ni date de validité.

Règle de gestion :
Un article est d'un certain type et un type d'article qualifie plusieurs articles.

MCD :
Type_Article -0,n----qualifier----1,1- Article

Tables :
type_article (ta_id, ta_libelle, ta_description...)

Le fait de typer les articles permettra au programme utilisateur de la BDD de lancer le processus de génération des numéros de série et de la date de validité de certains articles vendus.

Comme l'a dit Freud, si tu es sûr de ne jamais avoir d'articles d'un autre type, tu peux te contenter d'un attribut booléen disant si l'article nécessite un numéro de série. Sinon il vaut mieux créer une entité type_article comme ci-dessus.

2) Un client peut passer commande de plusieurs articles différents et en quantités variées, certains nécessitant la génération de numéros de série de chaque exemplaire vendus et d'autres non. Autrement dit, une commande peut contenir des articles de plusieurs types.

Comme l'a suggéré Freud, il est généralement procédé ici à la transformation d'une association en entité.

MCD de départ :
Commande -1,n----Concerner----0,n- Article

On transforme l'association "Concerner" en entité "Ligne_Commande" :
Commande -1,n----Contenir----(1,1)- Ligne_Commande -1,1----Concerner----0,n- Article

Tables :
Commande (c_id, c_id_client, c_date...)
Ligne_Commande (lc_id_commande, lc_num_ligne, lc_id_article, lc_quantite...)

À noter ici l'utilisation de l'identification de la ligne de commande relativement à sa commande.

3) Il faut générer et enregistrer les dates de validité et numéros de série de chaque exemplaire d'article de ce type vendu.
Certains article engendre donc en BDD la mémorisation de chaque exemplaire vendu, associés à la ligne de commande dans laquelle ils ont été vendus.

MCD :
Ligne_Commande -0,n----Générer----1,1- Exemplaire_article

Tables :
Exemplaire_Article (ea_id, ea_id_commande, ea_num_ligne_commande, ea_num_serie, ea_date_validite)

À noter qu'on retrouvera à quel article correspond tel numéro de série via la ligne de commande.

Ça répond à ton besoin ou je n'ai rien compris au Schmilblick ?

[Nohant]

Bonsoir,

Donc si j'ai bien suivi on abouti au MCD suivant :


on garde par contre la même problématique qu'il faut ensuite passer par un programme (un trigger par exemple?) pour assurer les contraintes suivantes

• Pour certains articles uniquement on doit générer des exemplaires (n° série, date fin validité)
• le nombre d'exemplaires générés d'un article doit correspondre à la quantité commandée

On ne peut pas modéliser ça afin de bénéficier des mécanismes d'intégrité référentielle dans la base ?

Ce qui me chiffonne (mais sans doute à tort) c'est que par contre comme tu le signales il faut maintenant passer par la table Ligne commande pour identifier le type d'article correspondant à un n° de série alors dans le cas précédent l'info était directe. L'avantage étant par contre d'avoir un lien direct entre l'entité Exemplaire article et Ligne commande.

Désolé pour Freud je n'avais pas compris la phrase "A la place de la relation "porter" je pense qu'il faut mettre l'habituelle association "COMPOSER" parce qu'une commande sera composée de 1 ou n lignes d'articles dans l'entité LIGNE_COMMANDE relié à COMMANDE". J'ai ripé et j'ai cru que ça parlais MLD.

En tout cas merci de cette réponse et si toi ou d'autre ont des suggestions à apporter je les apprécierai à leur juste valeur.

[CinePhil]

Je n'avais pas mis d'identification relative entre Ligne_Commande et Article.

Commande -1,n----Contenir----(1,1)- Ligne_Commande -1,1----Concerner----0,n- Article

Tu as fait une boucle :
Ligne_commande -0,n----Générer----(1,1)- Exemplaire_article -(1,1)----Correspondre
|---------------------------(1,1)----Concerner----0,n- Article -0,n------------------------------|

Du coup, ton MCD autorise le fait qu'un exemplaire d'article corresponde à un autre article que celui qui figure dans la ligne de commande !

Je n'avais pas fait d'association entre Article et exemlaire_article :

Ligne_Commande -0,n----Générer----1,1- Exemplaire_article

C'est pour ça que je disais que pour retrouver l'article correspondant à l'exemplaire, il fallait "passer" par la ligne de commande qui, elle, est associée à l'article.
De plus, je n'avais pas identifié l'exemplaire article relativement à la ligne de commande.

Dans mon schéma, Numero_serie n'est pas l'identifiant de exemplaire_article. J'ajoute un identifiant anonyme car le numéro de série sera probablement alphanumérique et ne constitue donc pas une bonne clé.

Exemplaire_Article (ea_id, ea_id_commande, ea_num_ligne_commande, ea_num_serie, ea_date_validite)

on garde par contre la même problématique qu'il faut ensuite passer par un programme (un trigger par exemple?) pour assurer les contraintes suivantes

• Pour certains articles uniquement on doit générer des exemplaires (n° série, date fin validité)
• le nombre d'exemplaires générés d'un article doit correspondre à la quantité commandée

Un trigger ou un bout de programme qui génère les requêtes INSERT nécessaires.

On ne peut pas modéliser ça afin de bénéficier des mécanismes d'intégrité référentielle dans la base ?

Là je ne comprends pas la question !
Ton MCD engendrera un MLD contenant des clés étrangères auxquelles tu pourras, au moment de l'implémentation en BDD, ajouter des contraintes d'intégrité référentielle ON DELETE.

Ce qui me chiffonne (mais sans doute à tort) c'est que par contre comme tu le signales il faut maintenant passer par la table Ligne commande pour identifier le type d'article correspondant à un n° de série alors dans le cas précédent l'info était directe. L'avantage étant par contre d'avoir un lien direct entre l'entité Exemplaire article et Ligne commande.

Quel est l'article et la commande ayant généré le numéro de série 'abc123' ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT a.libelle AS libelle_article,
  c.id_cde, c.date_cde
FROM Ligne_commande AS l
INNER JOIN Commande AS c ON c.id_cde = l.id_cde
INNER JOIN Exemplaire_article AS e ON e.id_cde = l.id_cde AND e.num_ligne = l.num_ligne
INNER JOIN Article AS a ON a.id_art = l.id_art
WHERE e.Numero_serie = 'abc123'

[Nohant]

Bonjour,

Merci de m'avoir repris sur cette grosse bourde que je n'avais pas vu. J'avais oublié de supprimer la relation de la 1ère version.

Cette fois j'espère avoir correctement dessiné le MCD concernant les entités et les cardinalités (je dois revoir les propriétés et les types de données associées)


Pour ma question (stupide) sur les mécanismes d'intégrité référentielles c'était en rapport avec les deux problématiques de générer des exemplaires pour les articles qui le nécessite et contrôler que le nombre d'exemplaires générés correspond à la quantité de la ligne détail. Si j'ai bien compris pour assurer cette cohérence il faudra passer par du code soit directement dans la base de données soit en externe.

Pour le n° de série (qui permet de par sa structure d'identifier un article) il est entièrement numérique et comme par nature il est unique, ne peut-il pas faire un bon candidat comme clé ?

[CinePhil]

Cette fois j'espère avoir correctement dessiné le MCD concernant les entités et les cardinalités

Ça me semble bon.

Pour ma question (stupide) sur les mécanismes d'intégrité référentielles c'était en rapport avec les deux problématiques de générer des exemplaires pour les articles qui le nécessite et contrôler que le nombre d'exemplaires générés correspond à la quantité de la ligne détail. Si j'ai bien compris pour assurer cette cohérence il faudra passer par du code soit directement dans la base de données soit en externe.

Oui.

Pour le n° de série (qui permet de par sa structure d'identifier un article) il est entièrement numérique et comme par nature il est unique, ne peut-il pas faire un bon candidat comme clé ?

Non.
Une bonne clé doit être entièrement gérée par le SGBD.
Si un jour il est décidé de passer à un code alphanumérique pour les numéros de série, les mises à jour seront plus complexes à cause des clés étrangères.

Et d'ailleurs, je doute que, même si le numéro de série n'est composé que de chiffres, il soit de type numérique. Il sera plutôt de la forme '0001' que 1 non ?

D'une manière générale, il faut réserver les types numériques aux clés et aux valeurs sur lesquelles on peut procéder à des calculs (quantités, années...).
Tout ce qui s'appelle 'numéro de quelque chose' (de série, de document, de chapitre, de dossier, de téléphone, de sécurité sociale, de police d'assurance...) sont en fait des codes ou des références et doivent être de type alphanumérique.
Ils ne doivent pas être utilisés comme clé, sauf si cette clé est à jamais invariable et de taille plus courte qu'un entier. Si vous êtes sûr de ne jamais avoir plus de 26 types de quelque chose, vous pouvez les "numéroter" de A à Z dans une colonne de type CHAR(1) et utiliser cette colonne comme clé.

[Nohant]

merci pour la réponse et le lien vers l'article sur les clés, super auteur d'ailleurs je possède l'un de ses ouvrages (SQL).

Dernière question que je me pose (pour l'instant) et qui découle de la présence de l'entité Exemplaire article. En cas de modification de commande pourtant sur les articles avec n° de série.

Je vois trois cas de figure

1. suppression de l'article
2. diminution de la quantité
3. augmentation de la quantité

Cas 1 si on supprime la ligne de commande tous les exemplaires en découlant sont supprimés via l'intégrité référentielle
Cas 2 il sera nécessaire de calculer la quantité d'article retranchés et supprimer le nombre d'exemplaires correspondant (effet de bord il pourra potentiellement y avoir des trous dans les n° de série si une autre commande a déjà été enregistrée)
Cas 3 il sera nécessaire de calculer la quantité d'article ajoutés et créer le nombre d'exemplaires correspondant (effet de bord pour une commande donnée potentiellement la numérotation des exemplaires ne sera pas séquentielle si une commande a été enregistrée dans l'intervalle entre création et mise à jour)

C'est juste pour voir si j'appréhende bien les conséquences de la structure de la base donnée

[CinePhil]

Juste une toute petite remarque sémantique sur ce que tu a écrit :

1. suppression de l'article

En modifiant une commande, on ne supprime pas l'article mais la ligne de commande relative à un article.

Sinon dans l'ensemble tu as bien capté le problème.
Pour ce qui est des trous dans les numéros de série, est-ce grave docteur ? Un numéro de série n'est qu'un numéro. Quelle importance que deux articles commandés en même temps portent deux numéros de série successifs ?

Si j'achète 2 ordinateurs, ce qui compte c'est qu'ils fonctionnent. Leurs numéros de série, je m'en fout !

Par contre il peut y avoir un autre effet de bord plus délicat à gérer par le programme.
Client A passe commande de 5000 trucs.
On génère les 5000 numéros de série et on lance la fabrication.
Client B passe commande de 2000 trucs et accepte un délai plus long à cause de la commande précédente.
Client A modifie sa commande et n'en veut plus que 1000.
Il y en a déjà 1500 qui ont été fabriqués.
Je ne vais peut-être pas mettre les 500 en trop à la poubelle mais plutôt les passer sur la commande du client B à qui en plus je vais annoncer fièrement que je vais pouvoir le livrer plus vite.
Ça tient cette fois plus de la gestion de production que de la gestion de commande mais d'ailleurs à la réflexion, je pense qu'en général c'est plutôt la production qui génère des numéros de série, pas la commande.

[Nohant]

Pour la sémantique on est d'accord, implicitement je pensais supprimer l'article dans la commande

pour les trous non pas de souci particulier, c'est juste bon de le savoir.

pour l'effet de bord évoqué effectivement ça serait dans le cas s'il s'agissait d'un outil gestion de production/stock ce qui n'est pas le cas présentement où ça reste un outil simple de commande mais merci d'avoir soulevé la question.