traitement de produits chimiques contenu dans des cuves

**etiennegaloup** · 20/07/2006, 15h22

Bonjour,

je dois modèliser le traitement de produits chimiques contenu dans des cuves.
J'aimerais avoir votre avis et vos conseils car je peine surtout avec les produits référencés et les produits en stocks.
Voici mon MCD:
http://etienne.galoup.ifrance.com/MCDTrtProdChimi.JPG

Le client commande le traitement de produits. Il envoie les produits. Une fois traité, ils sont retournés chez le client.
Les produits dont le client demande la traitement peuvent-être référencés ou non dans l'entité produit.

Premier problème:
Le client peut demander le traitement de produit pas encore référencé. Ces produits n'apparaissent pas dans l'entité produit référencé. Malgrès tout, pour chaque commande, il faut attacher tous les produits attachés à cette commande y compris ceux qui ne sont pas référencés. Ainsi, selon moi, il ne peut y avoir de liaison directe entre l'entité "produit" et l'entité "commande". Si je crée une nouvelle entité "produit commandé", je devrais reprendre certaints des attributs existant déjà dans l'entité produit référencé, ce qui aurait pour effet d'introduire de la redondance.

Deuxième problème:
La gestion de stock.
Je me demande si je dois créer une entité stock ou une association entre la commande et les produits référencés.
Dans une commande, les produits non référencés sont introduits dans l'entité produit référencé lors de la réception des produits.
Les produits qui sont en stock proviennent d'une commande et sont référencés dans l'entité produit référencé.

Je suis ouvert à tous vos conseils
Merci d'avance.
++

**shinrei** · 20/07/2006, 18h04

Salut,

Moi j'ai une question sur la creation de ta table concerner, comment fais-tu pour créer ta clé primaire qui relie cde_id et prd_id ??

**etiennegaloup** · 20/07/2006, 19h44

Le code SQL est le suivant:

Code :

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

1
2
3
4
ALTER TABLE concerner ADD CONSTRAINT PK_concerner PRIMARY KEY (cde_id, prd_id, pst_id);
ALTER TABLE concerner ADD CONSTRAINT FK_concerner_cde_id FOREIGN KEY (cde_id) REFERENCES commandes_de_traitement (cde_id);
ALTER TABLE concerner ADD CONSTRAINT FK_concerner_prd_id FOREIGN KEY (prd_id) REFERENCES produits_references (prd_id);
ALTER TABLE concerner ADD CONSTRAINT FK_concerner_pst_id FOREIGN KEY (pst_id) REFERENCES produits_stockes (pst_id);

++

**SQLpro** · 21/07/2006, 12h21

Vous ne devriez avoir qu'une seule table produit avec un héritage. Lisez ceci :
http://sqlpro.developpez.com/cours/m...tion/heritage/
De même la cardinalité de la relation PASSER ne me parait pas bonne.
N'y a t-il qu'un seul traitement possible pour un produit ?

A +

**etiennegaloup** · 21/07/2006, 13h22

Vous ne devriez avoir qu'une seule table produit avec un héritage.

J'y avais pensé, mais je me suis dit qu'après tout, le produit commandé, le produit référencé ou le produit en stock n'était pas en soi des espèces de produits. C'est plus des états du produits, non ?

Après je me demande, si je fais bien d'organiser ma base de cette manière, je me demande si j'ai bien fait de créer une table "produit en stock". J'aurais peut-être dû simplement créer une table "produit commandé" et mettre un attribut "réceptionné", pour savoir s'il le produit a été réceptionné.
Qu'en pensez-vous ?

Et d'un aspect général, que pensez-vous de l'organisation ?
Est-ce ainsi qu'il faut s'y prendre pour gérer ce type d'architecture ? (Gestion de stock) Stagiaire, j'ai pas eu l'occasion de modèliser beaucoup d'appli ;-)

Merci encore.
++

**etiennegaloup** · 21/07/2006, 13h56

J'ai refait mon MCD en prenant en compte l'héritage.

http://etienne.galoup.ifrance.com/MC...AvHeritage.JPG

J'ai lié l'association provient entre les entités clients et produits. Je me suis dit que l'attribut PRD_REF_CLI était aussi un attribut de produit commandé et de produit référencé.
Sauf que pour produit commandé, ça introduit de la redondance[/b]. Car on peut déterminer le client propriétaire du produit soit en passant par l'association provient et en passant par la commande. Du coup, je ne sais pas si je fais bien....
D'après vous ?

Merci d'avance.
++

**fab** · 21/07/2006, 14h58

Salut,

Pour ta relation provient:

Si des produits doivent etre référencés alors qu'ils n'ont pas encore été commandés , cela peut être intéressant : C'est en fait un lien article/client qui contient des informations du type : designation du client, conditionnement, extension du modèle sur des tarifs, etc...

Sinon, ca a peut d'intéret car quand tu vas coder ton application tu auras des données a mettre à jour qui ne servent à rien.

Pour la table stock, a l'evidence cela doit exister dans ton modele (il te faut gérer des quantités). Ce que je ne comprend pas trop c'est quoi PST_ID , un n° d'enregistrement de stock ? comment tu veux gérer ton stock , 1 fiche par produit ? par commande ?

Et puis dans quel contexte travaille tu ? Si il y a déjà une gestion de stock, regarde comment elle est faite et interface toi avec, mais la c'est plus du sql.

Voilà. Ton problème est intéressant en tous les cas.

Bon courage. Salut.

**etiennegaloup** · 21/07/2006, 15h10

Pour ta relation provient:

Si des produits doivent etre référencés alors qu'ils n'ont pas encore été commandés , cela peut être intéressant : C'est en fait un lien article/client qui contient des informations du type : designation du client, conditionnement, extension du modèle sur des tarifs, etc...

Dans la logique, les articles ne peuvent être référencé s'ils n'ont jamais été commandés.

Pour la relation provient, j'avais plutôt tenu le raisonnement suivant:
Les produits référencés sont liés aux clients avec une relation de type 1:n, Lors de la création du mpd, la clé primaire client devient clé étrangère de la table produit. Ainsi, il est possible de savoir de quels clients provient les produits référencés. Evidemment, pour les produits commandés, on peut connaître différemment le client attaché aux produits commandés, en passant par la commande de traitement.

Selon toi, le lien provient n'a pas d'interêt ? Mais dans ce cas, comment je fais pour connaître de quel client provient le produit ? En retrouvant une commande qu'il a déjà passé sur ce produit ? Ca ne fait pas un peu compliqué ?

Qu'en pensez-vous ?

PST_ID est l'identifiant de mon produit dans le stock.
Pour la création de cette entité, j'avais tenu le raisonnement suivant:
chaque produit stocké est attaché à une commande et une seul. (Je suis en train de penser que le client pourrait traiter deux même références sur deux commandes différentes, va falloir que je change ma cardinalité)

Chaque commande est attaché à 0 (cas où le produit commandé n'a pas encore été receptionné) ou à n produits dans le stocks.

Chaque produit stockés est référencé une seul fois dans la table produit.

Qu'en pensez-vous ?

Merci d'avance.
++

**fab** · 21/07/2006, 15h31

Je crois qu'en creation de modele il ne faut pas se poser de question sur l'optimisation, il faut rester conceptuel.

Il est vrai que cela va simplifier un select dont tu auras besoin de temps en temps, mais comme je te l'ai deja dit, tu auras les écritures a gérer ce qui risque d'etre plus lourd que des select un peu compliqué.

Pour l'optimisation, il faut etre pragmatique, fait ta base, fait fonctionner ton programme et tu créeras des redondances pour l'optimisation si cela est nécessaire (par rapport au temps de réponse ou à la difficulté d'établir les requetes), mais après avoir démarré ton application, quand tu connaitras mieux les besoins de tes utilisateurs.

C'est mon avis.

**etiennegaloup** · 24/07/2006, 09h25

Pour la table stock, a l'evidence cela doit exister dans ton modele (il te faut gérer des quantités).

Oui mais ça pourrait être une association plutôt qu'une table, non ?
Qu'en penses-tu ?

Ce que je ne comprend pas trop c'est quoi PST_ID , un n° d'enregistrement de stock ? comment tu veux gérer ton stock , 1 fiche par produit ? par commande ?

J'imagine pour chaque commande, qu'à chaque référence produit stocké, il y aurait un ID. En fait, l'identifiant stock dépendrait du numéro de commande et du numéro de produit.
Deux commandes différentes, pourrait traiter la même référence produit, ce serait deux ID différents.
Sur conseils d'SQL Pro, j'ai mis une clé numérique qui est préférable pour indexer les tables. (Il est vrai que là on est dans le MCD et ce conseil relève plus du MPD)

++

**fab** · 24/07/2006, 09h43

Pour la table ou relation stock, tu réponds un peu toi même a la question.

Tu te demandes si STOCK ne doit pas être une relation. Le modèle a l'air plus lisible avec une table. Une relation avec de nombreuses propriétés on peut se demander si ce n'est pas en fait un objet réel du modèle.

Tu dis aussi mon identifiant c'est le couple Produit/commande. Cela ressemble fort à l'identifiant d'une relation 1,n/1,n transformé en table au mld.

Et table ou relation, au passage mld, de toute façon cela deviendra une table, et pour des raisons de simplification et d'optimisation, tu rajouteras une clé unique numérique plutot qu'une clé composé des autres tables.

Donc pour moi, il est plus simple de faire apparaitre la table.

Il peut manquer aussi les lignes de commandes dans ton modèle, au cas ou un produit apparait 2 fois dans une commande avec des délais différents. Et puis il faut aussi peut-être avoir la notion de quantité commandé et quantité réceptionné, si ton client te livre en plusieurs fois.

Ton modèle ressemble de plus en plus à un ERP, ca peut aller loin...

Xo · 24/07/2006, 14h30

Le forum Conception est là pour traiter ce type de sujets, on ne modélise pas en SQL

**etiennegaloup** · 28/07/2006, 19h47

OK désolé ...

J'ai modifié mon MCD, il ressemble désormais à ça.

http://etienne.galoup.ifrance.com/TrtDechetV2.0.JPG

voici les explications qui vont avec

Le produit vient du client, d'où la relation "provient" entre les entités "clients" et "produit".

Les clients (Entité: client) lui passe commande (entité: commande) pour le traitement des produits.

Chaque client possède une ou plusieurs commandes (classique).
Chaque commande correspond à 1 ou plusieurs produits. Et le traitement d'un produit peut-être commandé 1 ou plusieurs fois (toujours classique) Cette association se nomme "correspondre". En fait, elle représente un produit d'une commande.
Mon client veut savoir dans le cas où le produit est réceptionné en plusieurs fois les différentes dates de réceptions, les quantités reçue et quel opérateur a fait la réception du produit.
Chaque article d'une commande peut-être réceptionné en plusieurs fois par un utilisateur. Du coup, l'association "correspondre" est une agrégation.
Les articles réceptionnés sont stockés.
En plus, chaque article d'une commande peut avoir un statut et un statut peut-être attribué à plusieurs articles.
Ensuite je dois aussi prévoir pour le stock, la notion de quantité de produit reçue et la quantité de produit à traiter prévu sur la commande.

Pouvez-vous me dire s'il vous plait ce que vous pensez de ce MCD ?
Quel conseils pourriez-vous m'apporter ?

Merci d'avance.
++

**Médiat** · 29/07/2006, 12h08

Si j'ai bien compris ton problème :
L'entreprise traite des Articles appartenant à des clients
L'entreprise sait faire un ensemble de traitements sur un ensemble d'article
Un article doit être référencé au niveau de l'entreprise, mais aussi au niveau du client
Un traitement peut être appliqué à plusieurs articles (on peut thermolaquer plusieurs métaux)
Un article peut subir plusieurs traitements (on thermolaquer l'aluminium, mais on peut aussi l'anodiser)
Une commande concerne un ensemble de traitements portant sur un ensemble d'articles.
Est-ce bien cela ?

**etiennegaloup** · 29/07/2006, 22h29

Oui c'est exactement cela ...

Initialement, il avait été question que le client pouvait demander le traitement d'articles pas encore référencé, mais pour simplifier le schéma, lors de la saisie de la commande, le produit sera ajouté dans la table des produits référencés.

Merci
++

**Médiat** · 29/07/2006, 22h46

Alors voila ce que je ferais pour la partie commande, à toi de voir si les liens avec DetailCommande doivent être identifiants ou non, et de rajouter les attributs

**etiennegaloup** · 29/07/2006, 23h51

Bonjour et merci pour votre réponse,

qu'entendez-vous par:

si les liens avec DetailCommande doivent être identifiants ou non

La table Transformation représente-t-elle le type de traitement ? (thermolaquer,anodiser,etc.)

Comment intégreriez-vous la gestion de la réception des produits ?

Merci d'avance.

**Médiat** · 30/07/2006, 07h00

Envoyé par etiennegaloup

La table Transformation représente-t-elle le type de traitement ? (thermolaquer, anodiser,etc.)

Oui, c'est ce que sait faire l'entreprise.

Envoyé par etiennegaloup

qu'entendez-vous par:
Citation:

Envoyé par etiennegaloup

si les liens avec DetailCommande doivent être identifiants ou non

Est-ce que pour une Commande donnée il ne peut y avoir qu'un seul "lot" d'un produit à traiter d'une certaine façon, par exemple dans une commande, s'il y a de l'aluminium à anodiser, est-ce que

Tout l'aluminium à anodiser sera traiter (informatiquement) d'une seule et unique façon (le prix par exemple) et dans ce cas COM_TRA_ID est inutile, mais il faut que les liens soient identifiant afin de créer une clé pour la table DétailCommande
L'aluminium à anodiser peut être séparer en différents lots pour des raisons de détails (tarifaires, etc.), dans ce cas le schéma précédent est mieux adapté

Attention : pour répondre à la question précédente, il ne faut prendre en compte que ce qui est lié à une commande et (sans doute) à la facture qui va avec, et non la logistique.
J'en profite pour signaler un détail : le TRA_TARIF devrait se nommer TRA_ART_TARIF, mais surtout, il représente un code tarif "standard" pour une transformation d'un article, ce n'est pas forcément le tarif appliqué à une commande en particulier (remise, promotion, etc.), et bien sur il devrait y avoir une association avec une Table TARIF à la place de cet attribut.

Envoyé par etiennegaloup

Comment intégreriez-vous la gestion de la réception des produits ?

Cela dépend de la réponse à la question précédente, je donne un exemple avec des liens identifiants.

**etiennegaloup** · 02/08/2006, 16h09

C'est vachement bien ce que vous me proposez.
J'aurais dû y penser de relier le détail commande au traitement et au produit.

En fait, j'ai une entité de traitement qui comprend une référence, une date de début, une date de fin.

Et que pensez-vous du MCD que j'avais fait ?

J'avais réalisé un "graphe de couverture minimale" et étudier les dépendances fonctionnelles. Ainsi, j'avais trouvé:
Numéro de commande + Numéro de produit -> Référence Traitement

Ainsi comme expliqué dans le document de Cyril Gruau (Conception d'une base de donnée trouvé sur developpez.com), il y a une agrégation entre les entités commandes, produits et traitement.

Qu'en pensez-vous ?

Merci d'avance.
++