Discussion :

[quentyn]

Bonjour,

Je suis en licence informatique et nous devons réaliser un projet afin de valider nos compétences en SQL. Pour cela, nous avons le droit de créer un sujet, tant que celui-ci est suffisamment complexe et pédagogiquement intéressant.


Comme sujet, nous avons choisi un système qui, apparemment, est très compliqué, puisqu’il fait intervenir la gestion de stock dans plusieurs entrepôts, la gestion de fournisseur et de transformation de ressources.
Par conséquent, nous avons choisi de simplifier au maximum les notions, afin de se concentrer sur la recherche de ressources suite à une commande, et d’estimer les prix des ressources commandées (on ne tient pas compte du temps et des différents trajets entres entrepôts/fournisseurs.)



Le debrief du projet:
À partir de commandes reçues, l’entreprise de gestion et livraison de matière première (entre-autres), doit pouvoir se renseigner si les ressources commandées sont disponibles dans l’un de ses entrepôts, ou s’il est possible de s’approvisionner afin de répondre à la demande. Pour se réapprovisionner, l’entreprise possède plusieurs contacts avec des sous-traitants extérieurs, de nature différentes;
Fournisseur source: Une source est une sorte de grand entrepôt qui possède une certaine quantité de matière, généralement une seule, et qui vend ses ressources. Par exemple une mine de Cobalt,...
Fournisseur usine: Une usine est un fournisseur qui transforme la matière donnée entrante en matière transformée, en suivant un Processus, une recette de cuisine.




Je vous écris ce message pour vous demander de l’aide sur la partie ci-dessus, car il y a plusieurs problèmes que nous avons du mal à résoudre:
(je ne vous demande pas d’aide directement sur les règles de gestion, mais sur les entités et les associations en général)


- L’association tertiaire “Récupérer” nous a été décrit comme maladroit, et nous n’avons pas vu en cours comment adapter facilement ce genre de relation en SQL. Pourtant je l’a trouve pertinente, et ne vois donc pas commencer la développer en plusieurs entités. Dans les SQL de gestion de stocks disponible en ligne, il y a tout un système de “LignedeCommande” présent dans “l’OrdredeCommande”, mais je n’arrive pas à l’adapter correctement dans ce type de projet.

- Les différentes associations liées à l’Ordre de commande. Selon moi, l’ordre doit indiquer les processus à exécuter et le fournisseur qui réalise ce processus, mais j’ai du mal à savoir s’il suffit d’associer les entités entre elles où si une autre chose doit être employée.


Petite information, les variables “coef” désignent la quantité de ressources en prenant comme référentiel le stock des entrepôts. Par exemple, un procédé qui nécessite deux ressources, auront un coefficient négatif, et fournira un produit avec un coefficient positif.


Si vous pouviez m'éclairer sur ces deux points, je vous serais très reconnaissant !
Et si le message n'est pas clair, n'hésitez pas à le signaler afin que l'on puisse mieux se faire comprendre


Bonne fin de journée à vous !

[escartefigue]

Bonsoir quentyn et bienvenue dans ce forum.

Un MCD n'est pas bon ou mauvais en soi - aux écueils techniques près - il est bon ou mauvais en regard des règles de gestion auxquelles il se rapporte. Or, vous ne nous avez communiqué aucune des règles de gestion.

Vous trouverez dans ce fil de discussion, dans la réponse n°8, comment procéder pour communiquer les règles.

[quentyn]

Bonjour,

Effectivement, j'aurais dû commencer par là!


R001: Un entrepôt peut contenir aucune à n quantité de ressources.
R002: Une ressource peuvent être contenu dans aucun à plusieurs entrepôt.
R003: Un (ordre de) commande externe peut commander un à plusieurs ressources.
R004: Une ressource peut être commandé dans aucun à pleins d'ordre de commande externe.
~R005: Un entrepôt peut récupérer (ou envoyer) aucune à plusieurs ressources dans une même commande interne
~R006: Une ressource peut être récupéré par aucune ou plusieurs commande interne.
~R007: ?? (Récupérer - Ordre de commande interne)
R008: Un ordre de commande interne est associé à aucun ou un fournisseur
R009: Un fournisseur peut être associé à aucun ou plusieurs ordre de commande interne
R010: Un fournisseur réalise 0 à n procédé
R011: Un procédé est réalisé par aucun à pleins de fournisseurs.
R012: Un procédé est relatif à aucune ou plusieurs commandes interne.
R013: Un ordre de commande interne est associé à aucun ou un procédé
R014: Un procédé produit (et consomme) 1 à plusieurs ressources
R015: Une ressource peut être produite pas aucun ou pleins de procédés.


En réalité ça m'a permis de clarifier certaines parties et de corriger les liens, merci !!
J'éprouve tout de même des difficultés au niveau de l'association à 3 liens ("Récupérer"), mais je pense avoir mieux assimilé le second point présenté au départ.

Voici donc le nouveau MCD;

[escartefigue]

Bonjour Quentyn

C'est un bon début, mais il faut expliquer certains termes, n'hésitez pas à donner des exemples.

À propos des commandes :

• qui est l'émetteur d'une commande interne, un service de l'entreprise ?
• qui est l'émetteur d'une commande externe, un client ?
• qu'est ce qui distingue une commande interne d'une commande externe, y a-t-il des attributs spécifiques à l'une ou l'autre ?

Sauf explications contraires, je ne vois pas en quoi il est intéressant de spécifier, dans la commande, de quel entrepôt doit venir la marchandise.
C'est au fournisseur de livrer le produit attendu par son client en qualité, nombre et délais conforme à la commande, peu importe où ce produit a été stocké.
Ce faisant, il n'y a pas besoin de modéliser une association entre la commande et l'entrepôt.

Également, le lieux de livraison ne doit pas être un attribut de la commande : une même adresse peut être utilisée pour plusieurs commandes.
Il faut donc utiliser un type d'entité ADRESSE associé à la commande. Et comme plusieurs adresses peuvent concerner une même ville, on aura également besoin d'un type d'entité VILLE associé aux adresses.

Ce qui donne un MCD de ce type :

[COMMANDE] 1,1 --- (livrer) --- 0,n [ADRESSE] 1,1 --- (situer) --- 0,n [VILLE]


À propos du stockage :
Si l'on gère des entrepôts, alors les produits ne sont pas stockés n'importe où dans l'entrepôt, mais dans des lieux précis, sans quoi, le cariste qui va rechercher la marchandise pour préparer une commande perdra beaucoup de temps à chercher...
Dans la vraie vie, les entrepôts sont en général découpés en magasins, eux mêmes détaillés en rangées, elles-mêmes subdivisées en emplacements.
Comme il s'agit d'un exercice, on pourrait accepter ici cette simplification, mais comme dans votre introduction vous précisez qu'il faut que ce soit suffisamment complexe... il faut choisir son camp

[fsmrel]

Quentyn,

Indépendamment des remarques pertinentes formulées par escartefigue, voici une observation d’ordre technique concernant votre association Recuperer (mise à mal par escartefigue, qui la débranche de l’entité-type Entrepot) :

Supposons donc que cette association ternaire soit après tout pertinente. Vous la dotez d’un attribut nommé coef, et comme l’association est ternaire, un coefficient donné dépend donc obligatoirement d’un entrepôt, d’une ressource et aussi d’un ordre de commande interne. Qu’en est-il ?

[quentyn]

Bonjour,

Merci à vous deux pour vos réponses !


Pour ce projet, on voulait vraiment se concentrer sur la gestion des stocks, et le fait de retrouver les ressources demandées dans tout le circuit/système.
Ainsi, la partie livraison est plutôt annexe; on veut simplement qu'elle fonctionne.


Du coup, le type de commande interne serait du genre:

--- commande n°36
36 | entrepot1 | -2000 | fer brut
36 | entrepot2 | -50 | charbon brut
36 | entrepot1 | +2050 | acier 2.5%

--- ordre commande n°36
id_com|fournisseur|procede
36 | usineA | fonte


(pardonnez le formalisme maladroit)
Comme vous le constatez, on néglige le fait que les ressources reste dans l'entrepôt de l'usine, car je trouve ça plus pratique et cohérent pour le projet.



Pour répondre à vos questions, ce projet prend le point de vue d'un manipulateur extérieur, qui possède tout les entrepôts, et qui donc gère et vérifie toutes les recettes/processus et que les ressources sont bien dans les entrepôts adéquats (plus que vérifier, il sait...).
Les commandes internes sont donc ordonnées depuis l'extérieur, et les commandes externes sont des "objectifs" à atteindre, mais en effet il n'y a pas de différence concrète entre les deux. C'était surtout pour les différentier: l'une est interne au système, l'autre "supprime" les ressources du cycle.


Je ne comprends pas ce que vous trouvez étrange au fait que les entrepôts sont spécifiés. La commande n°36 ci-dessus est plutôt simple, mais il est possible qu'il y ait plus de 2 entrepôts dans une même commande. Et comment savoir que les ressources sont bien retirées de tel entrepôt, si la commande n'est pas liée à ceux-ci.


Enfaite, on part du principe qu'il n'y a jamais de perte ni de problème, puisqu'il s'agit un projet d'étudiant... C'est vrai qu'il est demandé que le projet soit suffisamment complexe, mais là normalement on est dans les clous de ce qui est attendu!
D'où le fait qu'il n'y ait pas de gestion de distance et d'adresse. Mais je suis complètement d'accord avec vous, il en faudrait.


Je ne suis pas sûr d'avoir comprit votre question fsmrel, mais de la manière dont je vous l'ai présenté, j'ai l'impression que les 3 sont nécessaires.

[fsmrel]

Bonsoir,

Je ne suis pas sûr d'avoir comprit votre question fsmrel, mais de la manière dont je vous l'ai présenté, j'ai l'impression que les 3 sont nécessaires.

Votre manière de présenter ne permet pas de faire le lien précis avec ma demande. On y reviendra plus tard.

Au préalable, vous fournissez les règles de gestion suivantes :

~R005: Un entrepôt peut récupérer (ou envoyer) aucune à plusieurs ressources dans une même commande interne
~R006: Une ressource peut être récupéré par aucune ou plusieurs commande interne.
~R007: ?? (Récupérer - Ordre de commande interne)

La règle de gestion R005 associe les 3 éléments suivants ; entrepôt, ressource, commande interne.
D’accord.
La règle de gestion R006 est inférable de la précédente, on peut l’évacuer.
La règle de gestion R007 vous trouble, on la glissera sous le tapis.

Etant donné que vous n’avez pas modélisé d’entité-type "Commande Interne", dans R005 on remplacera donc "comande interne" par "ordre de commande inrene".

Maintenant vous proposez la commande 36 :

36 | entrepot1 | -2000 | fer brut
36 | entrepot2 | -50 | charbon brut
36 | entrepot1 | +2050 | acier 2.5%

Merci d’aménager ce tableau en y nommant (explicitant) chaque attribut. En effet à quoi correspond par exemple la valeur '2000' ? même remarque concernant la valeur '2.5%'.

[escartefigue]

Bonjour quentyn

Je ne comprends pas ce que vous trouvez étrange au fait que les entrepôts sont spécifiés. La commande n°36 ci-dessus est plutôt simple, mais il est possible qu'il y ait plus de 2 entrepôts dans une même commande.
Et comment savoir que les ressources sont bien retirées de tel entrepôt, si la commande n'est pas liée à ceux-ci.

L'objet du Modèle Conceptuel des Données n'est pas de se préoccuper du "comment", mais de décrire le "quoi".

Or voici le "quoi" habituellement rencontré (ceci est bien sûr un exemple simplifié) :
R001 : la COMMANDE est passée par un et un seul CLIENT et un CLIENT passe au moins une COMMANDE
R002 : la COMMANDE contient au moins une LIGNE DE COMMANDE et une LIGNE DE COMMANDE n'est contenue que par une seule COMMANDE
R003 : chaque LIGNE DE COMMANDE concerne un et un seul ARTICLE et un ARTICLE peut concerner plusieurs LIGNES DE COMMANDE
R004 : chaque ARTICLE est stocké dans un à plusieurs EMPLACEMENTS de MAGASIN
R005 : dans un EMPLACEMENT, à un instant "t", il ne peut y avoir au plus qu'un seul ARTICLE
R006 : chaque EMPLACEMENT appartient à un et un seul MAGASIN et un MAGASIN a plusieurs EMPLACEMENTS
R007 : chaque MAGASIN est localisé dans un et un seul ENTREPOT et dans un ENTREPROT est localisé au moins un MAGASIN

ce "quoi" se symbolise selon le formalisme du modèle entité-association de la façon suivante :



Quelques remarques à propos de ce MCD :

• notez la bijection entre les noms utilisés dans les règles de gestion (COMMANDE, ARTICLE...) et les noms des types d'entité (COM_commande, ART_article) ;
• voyez qu'il en va de même entre les verbes (passer, contenir, stocker...) et les noms des associations, le but est de faciliter la vérification de conformité entre la forme littérale et la forme MCD ;
• j'ai fait intervenir un type d'entité nommé [CAL_calendrier] qui est requis pour l'association ternaire (stocker), à cause de la règle de gestion R005.

Ce MCD n'indique en rien comment les ressources sont retirées de tel ou tel entrepôt, puisque ce n'est pas sa vocation. Cela étant dit, on le devine aisément : au stade SQL on consultera la table associative issue de (STO_stocker) et qui comporte comme composante de sa clef primaire l'identifiant de l'entrepôt (ceci grâce à l'identification relative de l'emplacement vers son magasin et du magasin vers son entrepôt, identifications relatives symbolisées par le (R) près des cardinalités, nous y reviendrons plus tard).

Quoi qu'il en soit, il est prématuré de décrire le comment tant que le quoi n'est pas clairement établi.

[quentyn]

Bonjour,
j'ai oublié la première ligne..


--- commande n°36
id_com|id_entrepot|id_ressource..|coefficient
36.......| entrepot1 | fer brut........| -2000
36.......| entrepot2 | charbon brut| -50
36.......| entrepot1 | acier 2.5%...| +2050

--- ordre commande n°36
id_com|fournisseur|procede
36......|...usineA...|fonte_acier_0025

J'ai écris ici le nom de la ressource pour une meilleur compréhension, mais pour éviter le cas de "doublons" il sera inscrit l'identifiant dans le tableau (par exemple MAT0321 pour cet acier)
Le 2.5% représente donc le nom de l'acier produit..



Pour le coup, vous m'avez aidé à y voir plus clair sur l'intérêt d'un MCD escartefigue.


(je vais expliquer l'intérêt du projet, donc ce qui va suivre va paraître bateau, mais permet de poser une meilleure base sur le projet)
L'intérêt du projet, c'est quoi ?
À partir d'une commande externe, on doit pouvoir estimer le coût de la livraison et les étapes à réaliser pour obtenir les ressources commandées.

On pourra faire quoi, avec ce SQL ?
On doit pouvoir avoir un aperçu sur où trouver une ressource (est-elle disponible dans un entrepôt du groupe ? peut-elle être produite ? où ?)
On doit également pouvoir voir quels sont les fournisseurs, ressources et entrepôts qui sont les plus demandés.

L'intérêt des commandes c'est quoi ?
Dans l'objectif de produire* des ressources, on doit pouvoir déplacer les ressources vers les entrepôts.

*(les échanges de ressources internes sont possibles mais n'ont pas vraiment d'intérêt pour ce projet)

Du coup, on aurait comme règle (en remplacement aux 3 règles en ~:
un ordre de commande possède une à plusieurs ligne de commande, qui est possédée par un unique ordre de commande.
chaque ligne de commande concerne une seule ressource à un seul entrepôt, mais ceux-ci peuvent être concerné.e à plusieurs ligne de commande.

Par contre je ne suis pas sûr de bien comprendre l'intérêt de mettre en majuscule les 3 premières lettres du nom des entités (hormis pour des MCD avec beaucoup d'entités)...



J'ai donc mis la ligne de commande dans le MCD (peut-être maladroitement), en indiquant certaines identités relatif, que nous n'avons pas directement vu pendant les cours...

[escartefigue]

Désolé d'insister, mais ces questions sont essentielles à ma compréhension, aussi, je répète :

À propos des commandes :

• qui est l'émetteur d'une commande interne, un service de l'entreprise ?
• qui est l'émetteur d'une commande externe, un client ?
• qu'est ce qui distingue une commande interne d'une commande externe, y a-t-il des attributs spécifiques à l'une ou l'autre ?

Il faut répondre à ces 3 questions.
N'hésitez pas à communiquer des exemples, car ce qui est sans doute clair pour vous ne l'est pas pour moi.

[quentyn]

Pour répondre à vos questions, ce projet prend le point de vue d'un manipulateur extérieur, qui possède tout les entrepôts, et qui donc gère et vérifie toutes les recettes/processus et que les ressources sont bien dans les entrepôts adéquats (plus que vérifier, il sait...).
Les commandes internes sont donc ordonnées depuis l'extérieur, et les commandes externes sont des "objectifs" à atteindre, mais en effet il n'y a pas de différence concrète entre les deux. C'était surtout pour les différentier: l'une est interne au système, l'autre "supprime" les ressources du cycle.

Je pensais vous avoir répondu ici... excusez-moi c'était effectivement flou.

• L'émetteur d'une commande interne est un service de l'entreprise qui se situe à l'extérieur des différentes boucles, qui a la connaissance de tout les stocks et de tous les fournisseurs, et qui se charge du système de livraison.

• L'émetteur d'une commande externe est ce même service (qui reçoit une commande d'un client).

• La seule distinction entre une commande interne et une commande externe c'est que les ressources sortes complètement du système. C'est le seul moment où il peut y avoir une ressource qui est supprimé de tout entrepôt et fournisseur.
  (On peut envisager qu'une ressource rentre également depuis une commande externe, par exemple si elle n'est pas proposée par les différents fournisseurs à disposition. Cela peut être le cas pour des fournisseurs temporaires ou des cargaisons exclusives, mais rares)

[escartefigue]

• L'émetteur d'une commande interne est un service de l'entreprise qui se situe à l'extérieur des différentes boucles, qui a la connaissance de tout les stocks et de tous les fournisseurs, et qui se charge du système de livraison.
• L'émetteur d'une commande externe est ce même service (qui reçoit une commande d'un client).

Pour les commandes externes : est-ce une simple copie de la commande client ? Y a-t-il une commande externe par commande client ou est-ce qu'on peut ne passer qu'une seule commande externe pour une commande client ou à l'inverse transformer une commande client en plusieurs commandes externes ?
Pour les commandes internes : qu'est-ce qui en provoque la création ?
Et enfin que signifie "des différentes boucles" ? Que sont ces "boucles"

• La seule distinction entre une commande interne et une commande externe c'est que les ressources sortes complètement du système. C'est le seul moment où il peut y avoir une ressource qui est supprimé de tout entrepôt et fournisseur.
  (On peut envisager qu'une ressource rentre également depuis une commande externe, par exemple si elle n'est pas proposée par les différents fournisseurs à disposition. Cela peut être le cas pour des fournisseurs temporaires ou des cargaisons exclusives, mais rares)

Tout ceci reste très confus pour moi

[fsmrel]

@Quentyn

Avec la mise en oeuvre de l’entité-type LigneCommandeInterne, votre MCD a évolué dans le bon sens.
Cela dit, une ligne de commande peut y faire référence à une paire entrepôt/ressource inexistante, c’est-à-dire inconnue dans l’association Contenir : je vous propose la modélisation suivante qui pallie cela :

 

Les noms des attributs ne sont pas toujours les vôtres, voire sont omis, mais ici ça n’est pas un problème.

Notez que les identifiants sont du type INT (ou SMALLINT) plutôt que VARCHAR(50) : ainsi dans la table SQL ligneCdeInterne, le quadruplet {ordreCdeInterneId, ligneCdeInterneId, entrepotId, ressourceId} n’occupera que 10 octets au lieu de 200...

Les identifiants sont donc numériques, mais les noms des dépôts et des ressources ne sont pas oubliés, ils font l’objet d’identifiants alternatifs (doublons inter dits), entrepotNom et ressourceNom.

Code SQL généré par Looping :
 

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
CREATE TABLE Entrepot(
   entrepotId SMALLINT,
   entrepotNom VARCHAR(50) NOT NULL,
   etc. VARCHAR(50) NOT NULL,
   PRIMARY KEY(entrepotId),
   UNIQUE(entrepotNom)
);
 
CREATE TABLE Ressource(
   ressourceId SMALLINT,
   ressourceNom VARCHAR(50) NOT NULL,
   etc. VARCHAR(50) NOT NULL,
   PRIMARY KEY(ressourceId),
   UNIQUE(ressourceNom)
);
 
CREATE TABLE Contenir(
   ressourceId SMALLINT,
   entrepotId SMALLINT,
   quantite INT,
   PRIMARY KEY(ressourceId, entrepotId),
   FOREIGN KEY(ressourceId) REFERENCES Ressource(ressourceId),
   FOREIGN KEY(entrepotId) REFERENCES Entrepot(entrepotId)
);
 
CREATE TABLE OrdreCdeInterne(
   ordreCdeInterneId INT,
   PRIMARY KEY(ordreCdeInterneId)
);
 
CREATE TABLE ligneCdeInterne(
   ordreCdeInterneId INT,
   ligneCdeInterneId SMALLINT,
   coefficient DECIMAL(8,2),
   ressourceId SMALLINT NOT NULL,
   entrepotId SMALLINT NOT NULL,
   PRIMARY KEY(ordreCdeInterneId, ligneCdeInterneId),
   FOREIGN KEY(ordreCdeInterneId) REFERENCES OrdreeCdeInterne(ordreCdeInterneId),
   FOREIGN KEY(ressourceId, entrepotId) REFERENCES Contenir(ressourceId, entrepotId)
);

 
Notez encore que l’entité-type OrdreCdeInterne doit être débarrassée des attributs usine et procede : ils seront en effet présents (sous forme de clés étrangères) lors de la génération du code SQL par Looping.
 

[quentyn]

Bonjour,

Quand je parle de boucle, je parle de ce système, de cette base de donnée (désolé ça porte en effet à confusion)


Pour améliorer la lisibilité du projet, j'ai négligé la partie "Entreprises" qui possède les divers entrepôts, usines et qui commande.
Je ne pensais pas que ça pourrait causer autant de trouble, mais j'aimerais quand même ne pas en parler car ça alourdirait le MCD,
et on m'a conseillé de ne pas y consacré mon temps dessus.

On aurait quelque chose comme ceci

(un entrepôt/fournisseur pourrait bien être possédé par plusieurs entreprises..)

Je ne saurais pas répondre à toutes vos questions sur les différentes commandes. Elles sont juste un prétexte pour avoir un objectif à réaliser..
Les commandes internes sont réalisés afin de répondre aux commandes externes, ou tout simplement pour suivre les ressources quand elles sont déplacés au sein des différents entrepôts ou fournisseur. Les commandes internes sont donc déclenchés par les "entreprises" qui possèdent les entrepôts.

---

fsmrel, j'ai mis comme type pour les clés des CHAR(50) (j'ai oublié certaines clés en VARCHAR(50) effectivement), car à côté j'ai commencé à définir ces clés avec des caractères pour différentier en un clin d'œil à qui appartienne l'identifiant. (etpXX pour les entrepôts, MAT-XXXX & RES-XXXX pour les ressources, ...)

Mais il est vrai que je pourrais mieux adapter les types, merci!



J'ai trouvé votre arrangement très pratique et beaucoup plus lisible, donc j'ai commencé à modifier le MCD en conséquent; mais je ne suis pas sûr que ça soit le mieux adapté

Le problème étant que, dans les ordre de commande interne, il y a aussi une partie réception de ressource dans un entrepôt.
Ainsi, une ressource qui n'existe pas dans un entrepôt, peut désormais apparaître dans celui-ci.
De même, pour un entrepôt vide.. Je me trompe peut-être, mais votre proposition ne semble pas permettre de rajouter une ressource dans un entrepôt vide.


Voici le MCD avec cette modification, mais je ne suis plus sûr de garder cette partie..



J'ai renommé par ailleurs les Commandes interne par Mouvement interne pour améliorer la compréhension...

[quentyn]

Bonjour,

Excusez moi, finalement ça fonctionne bien de cette manière !

J'avais un peu du mal à me projeter avec ces identifiants relatifs et clés étrangères.



Pourtant j'ai lu plusieurs fois de code SQL généré par Looping.


Du coup j'ai l'impression que tout fonctionne correctement, non ?

[fsmrel]

Le problème étant que, dans les ordre de commande interne, il y a aussi une partie réception de ressource dans un entrepôt.
Ainsi, une ressource qui n'existe pas dans un entrepôt, peut désormais apparaître dans celui-ci.
De même, pour un entrepôt vide.. Je me trompe peut-être, mais votre proposition ne semble pas permettre de rajouter une ressource dans un entrepôt vide.

Je ne saisis pas. En tout cas, dans le contexte de la base de données, une ressource d’identifiant r ne peut exister dans un entrepôt d’identifiant e que si la paire <r,e> est présente dans la table Contenir.
Cela dit, rien ne s’oppose à l’ajout dune ressource sans l’associer d’office à un entrepôt.


A propos de NULL

NULL aime bien ficher la patouille dans les bases de données, il est à fuir.
Par exemple si l’attribut Quantite (table Contenir) est marqué NULL pour une paire <r,e> cela signifie en l’occurrence que la quantité correspondante est inconnue, ce qui n’est pas sain : coder NOT NULL, ce que j’avais du reste oublié de faire dans le code SQL que j’ai proposé dans le post #13 (idem pour l’attribut Coefficient).


A propos du métabolisme des données :

Supposons que vous vouliez supprimer un ordre de mouvement interne o. Il faudra d’abord supprimer les lignes de mouvement correspondantes, sinon, en l’état, le système rejettera l’opération. Pour que la suppression de l’ordre de mouvement déclenche automatiquement celle des mouvements qui le composent, vous pouvez utiliser la clause SQL « ON DELETE CASCADE » :
 

Code SQL :

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

1
2
3
4
5
6
 
CREATE TABLE ligneMvtInterne
( ...
FOREIGN KEY(ordreMvtInterneId)
      REFERENCES OrdreMvtInterne(ordreMvtInterneId) ON DELETE CASCADE
...)

Dans votre post précédent, vous fournissez une image dans laquelle figure le terme « Index » :

En fait, ce terme ne fait pas partie de la norme SQL et à remplacer par « KEY ». Quel AGL utilise-vous ?

[escartefigue]

Bonjour,

Je reste dans la confusion la plus totale concernant les commandes internes et externes, du coup je resterai sur des commentaires de surface, car le fonds du besoin m'échappe.

En l'occurrence :

• les identifiants de type varchar sont à éviter : le plus souvent leur contenu est instable et leur type est contre performant. A remplacer par un identifiant technique stable et concis (par exemple un compteur attribué par le SGBD) ;
• le type d'entrepôt gagnerait peut être à être modélisé dans un type d'entité associé à l'entrepôt. Utile si l'on souhaite associer un libellé au type, voire des dates de début et fin de validité ou autres attributs ;
• les poids et mesures nécessitent parfois des unités de mesure, à vérifier dans votre contexte  ;
• la localisation du fournisseur, s'il s'agit d'une adresse, est mal modélisée.

[fsmrel]

Je reste dans la confusion la plus totale

Tu n’es pas le seul...

R008: Un ordre de commande interne est associé à aucun ou un fournisseur

Si un ordre de commande interne n’est associé à aucun fournisseur, qui en est l’émetteur ? La génération spontanée est suspecte et en fait n’a pas sa place.

L’entité-type Fournisseur a pour identifiant id_usine alors que, cohérence oblige, ça devrait être id_fournisseur.

Fournisseur source: Une source est une sorte de grand entrepôt qui possède une certaine quantité de matière

Du point de vue de la base de données, si une source est un entrepôt, grand ou autre, alors elle ne fait pas partie des fournisseurs, mais des entrepôts.

Si une source n’est pas un entrepôt, mais un fournisseur qui n’est pas une usine et qui possède une certaine quantité de matière, alors comment a-t-on connaissance de cette matière et de sa quantité ?

Si une source n’est pas un entrepôt, mais un fournisseur qui n’est pas une usine, alors la modélisation devient la suivante :

Source et Usine sont des sous-types de l’entité-type Fournisseur et chaque sous-type peut avoir ses attributs propres, idem pour les associations. On est dans le contexte de la spécialisation.

Code SQL correspondant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
CREATE TABLE Fournisseur(
   fournisseurId INT,
   fournisseurNom VARCHAR(50) NOT NULL,
   localisation VARCHAR(50) NOT NULL,
   PRIMARY KEY(fournisseurId),
   UNIQUE(fournisseurNom)
);
CREATE TABLE Source(
   fournisseurId INT,
   PRIMARY KEY(fournisseurId),
   FOREIGN KEY(fournisseurId) REFERENCES Fournisseur(fournisseurId)
);
CREATE TABLE Usine(
   fournisseurId INT,
   PRIMARY KEY(fournisseurId),
   FOREIGN KEY(fournisseurId) REFERENCES Fournisseur(fournisseurId)
);

 

Comme vous le constatez, on néglige le fait que les ressources restent dans l'entrepôt de l'usine, car je trouve ça plus pratique et cohérent pour le projet.

L’association Contenir permet de savoir dans quels entrepôts sont les ressources. Mais quand vous écrivez : « dans l'entrepôt de l'usine  »r, comment sait-on que tel dépôt appartient à telle usine ?