Discussion :

[qlaimand]

Bonjour,
Dans le cadre de mon stage, je dois reconcevoir un SGBD pour une entreprise.
J'en suis pour l'instant à la phase de conception, et je travaille sur mon schéma E/A.

Le cahier des charges impose un historique des prix de composants utilisés par l'entreprise dans ses projets.
Ces prix varient selon plusieurs paramètres, à savoir les projets dans lesquels sont impliqués les composants, les fournisseurs, le volume de composants utilisé.
Il faut que je garde une trace de chaque évolution du prix.
Pour l'instant je pense faire une table historique_prix, avec pour ID un numéro qui correspondrait à une MAJ d'un prix. Mais je bute sur la manière de lier ces prix avec le reste des tables.
Le but final est d'avoir un système d'analyse précis des prix (vues permettant d'avoir un maximum d'info concernant un composant, l'évolution de son prix, etc..).
Voilà, voilà
Merci à tous.

++

[al1_24]

Je le verrais bien sous cette forme :

- Composant(Id_Composant, Descriptif, ...)
- Projet(Id_Projet, Descriptif, ...)
- Prix_Composant(Id_Composant, Id_Prix, Prix, Date, ...)
Clé primaire (Id_Composant, Id_Prix)
Clé étrangère (Id_Composant) référence Composant(Id_Composant)
- Composant_Projet(Id_Projet, Id_Composant, Id_Prix, Qte, ...)
Clé primaire (Id_Projet, Id_Composant, Id_Prix)
Clé étrangère (Id_Composant, Id_Prix) référence Prix_Composant(Id_Composant, Id_Prix)
Clé étrangère (Id_Projet) référence Projet(Id_Projet)

[qlaimand]

Merci pour votre réponse al1_24.

En suivant votre schéma, et pour ajouter la composante fournisseur, il faudrait donc que j'ajoute:

-Fournisseur(Id_fournisseur, descriptif...)
Clé primaire (Id_fournisseur)

-Fournisseur_Composant(Id_fournisseur, Id_composant, Id_prix)
Clé primaire (Id_fournisseur, Id_composant, Id_prix)
Clé étrangère (Id_fournisseur) --> Fournisseur (Id_fournisseur)
Clé étrangère (Id_composant) --> Prix_composant (Id_composant)
Clé étrangère (Id_prix) --> Prix_composant (Id_prix)

Est ce que cela vous paraît correct?

Si j'ai bien compris votre manière de voir la chose, chaque fois qu'un prix est mis à jour, un enregistrement est fait dans la table prix composant. Donc pour les tables Composant_projet et Composant_fournisseur, c'est l'ID du prix qui est lié, donc un prix fixe à une date donnée vu que cet ID est unique.
Si au cours de l'avancement d'un projet le prix d'un composant change, il suffira d'écrire la requete, je suppose que l'ID du prix change aussi.

Du coup, comment garder en mémoire l'évolution du prix d'un composant au sein d'un projet, lorsque celui ci a été séléctionné ??

Merci, bonne journée


Edit : Et surtout est ce que ce sytème sera capable de gérer l'évolution du prix total d'un projet au cours du temps ??
++

[fsmrel]

Bonjour,

Ces prix varient selon plusieurs paramètres, à savoir les projets dans lesquels sont impliqués les composants, les fournisseurs, le volume de composants utilisé.

Le volume de composants a donc une incidence sur les prix, mais en relation avec les projets, les fournisseurs ? Autre ? La modélisation dépend de votre réponse.

[qlaimand]

Oui, en fait je dois vraiment mémoriser tout l'historique des prix d'un composant.
Ces prix varient d'un projet à l'autre, du volume acheté, d'un fournisseur à l'autre.

Dès qu'un prix évolue, meme si c'est juste une proposition du fournisseur (je pense mettre un tag sur un prix rentré dans la table), il faut que ça soit gardé.

[fsmrel]

Bonsoir,

Dès qu'un prix évolue, meme si c'est juste une proposition du fournisseur (je pense mettre un tag sur un prix rentré dans la table), il faut que ça soit gardé.

Soit.

Ces prix varient d'un projet à l'autre, du volume acheté, d'un fournisseur à l'autre

J’entends bien, mais cela reste trop synthétique pour produire un modèle de données, indépendamment de ce qui a déjà été proposé.

Je reformule donc mes certitudes et interrogations :

(1) Le prix d'achat d’un composant donné, C1, peut être différent selon qu’on l’a acheté à un fournisseur F1 ou à un fournisseur F2.

(2) Si C1 a fait l’objet d’une commande au fournisseur F1 à une date D1 et d’une autre commande à F1 à une date D2, les prix respectifs Px1 et Px2 peuvent différer en fonction du nombre de composants commandés (respectivement Pn1 et Pn2) alors que le prix unitaire PU1 est le même (Px1 = PU1 X Pn1, Px2 = PU1 X Pn2, abstraction faite d'éventuels paliers de remises et autres paramètres que nous ne prenons pas en compte ici).

(3) Toujours en relation avec le fournisseur F1, le prix d'achat peut changer alors que les quantités qui lui sont commandées sont les mêmes, mais parce que F1 a changé ses prix entre D1 et D2.

(Votre observation ci-dessus est évidemment une variation relative sur les deux points précédents).

(4) Je suppose que si au moins deux fournisseurs se sont associés pour fournir C1 au prix Px1 à la date D1, cela est transparent concernant Px1 (quitte à ce que ce prix soit réparti par fournisseur). Autrement dit, cette possibilité sort du périmètre de l'étude. Et cela est indépendant de ce qui est écrit au point (1).

(5) Le prix du composant C1, peut être différent pour deux projets distincts P1 et P2. Soient Pp11 et Pp12 les prix correspondants.
Qu’est-ce qui fait que Pp11 et Pp12 puissent être différents ? Seulement le nombre de composants Pj1 et Pj2 respectivement acquis pour les deux projets ? Autre chose ? Si oui, quoi donc ? Je suppose que Pp11 (cela vaut pour Pp12) n'est pas égal au prix unitaire à l'achat PU1 multiplié par Pj1, sinon cela ferait intervenir les différents fournisseurs du composant C1 (au cas où la situation se présenterait).


Dans tout cela, je cherche à voir quels éléments sont ou non dépendants les uns des autres, notamment concernant les quantités de composants en relation avec les fournisseurs d’une part et les projets d’autre part.

Merci de confirmer ou d’infirmer point par point et de compléter.

Question subsidiaire, mais ne concernant pas directement ce dont nous traitons ici et simplement à titre de curiosité, gérerez-vous les remises (et les paliers qui les accompagnent) ?

[qlaimand]

Concernant vos différents points:

(1) Le prix d'achat d’un composant donné, C1, peut être différent selon qu’on l’a acheté à un fournisseur F1 ou à un fournisseur F2.

Exact.

(2) Si C1 a fait l’objet d’une commande au fournisseur F1 à une date D1 et d’une autre commande à F1 à une date D2, les prix respectifs Px1 et Px2 peuvent différer en fonction du nombre de composants commandés (respectivement Pn1 et Pn2) alors que le prix unitaire PU1 est le même (Px1 = PU1 X Pn1, Px2 = PU1 X Pn2, abstraction faite d'éventuels paliers de remises et autres paramètres que nous ne prenons pas en compte ici).

Exact.

(3) Toujours en relation avec le fournisseur F1, le prix d'achat peut changer alors que les quantités qui lui sont commandées sont les mêmes, mais parce que F1 a changé ses prix entre D1 et D2.

Exact.

(4) Je suppose que si au moins deux fournisseurs se sont associés pour fournir C1 au prix Px1 à la date D1, cela est transparent concernant Px1 (quitte à ce que ce prix soit réparti par fournisseur). Autrement dit, cette possibilité sort du périmètre de l'étude. Et cela est indépendant de ce qui est écrit au point (1).

Je ne suis pas sûr de bien saisir le sens de votre phrase. Qu'entendez-vous par "se sont associés". Si deux fournisseurs aus moins proposent le même prix, il faut pouvoir le voir.

(5) Le prix du composant C1, peut être différent pour deux projets distincts P1 et P2. Soient Pp11 et Pp12 les prix correspondants.
Qu’est-ce qui fait que Pp11 et Pp12 puissent être différents ? Seulement le nombre de composants Pj1 et Pj2 respectivement acquis pour les deux projets ? Autre chose ? Si oui, quoi donc ? Je suppose que Pp11 (cela vaut pour Pp12) n'est pas égal au prix unitaire à l'achat PU1 multiplié par Pj1, sinon cela ferait intervenir les différents fournisseurs du composant C1 (au cas où la situation se présenterait).

C'est vraiment la nature du projet qui va faire varier les prix des composants.
Un projet peut être plus intéressant qu'un autre pour un fournisseur, et cela indépendamment du volume de composant vendu.
Je suis d'accord avec votre supposition.

Pour finir, je ne pense pas que je gererais les remises.

Merci pour votre aide, et pour l'interêt que vous semblez porter au problème.

[fsmrel]

Bonjour,

Qu'entendez-vous par "se sont associés".

Participer à une livraison commune. Mais apparemment, tel n’est pas le cas.

Un projet peut être plus intéressant qu'un autre pour un fournisseur, et cela indépendamment du volume de composant vendu.

Dans ce qui suit, je considère que les prix sont des prix unitaires.
Ce que vous dites laisse sous-entendre que le prix fixé par le fournisseur est déterminé en fonction du projet, autrement dit on devrait normalement pouvoir en déduire que le fournisseur F1 peut fournir le composant C1 au projet J1, avec une date d’applicabilité du prix D1, en quantité Q1, au prix P1, mais aussi que F1 peut fournir ce même composant C1 au projet J2, avec la même date D1, pour la même quantité Q1 mais à un prix P2 différent.

Dans cette hypothèse, le MLD proposé par al1_24 est à aménager et les tables en jeu seraient alors les suivantes (clés soulignées) :

Composant (IdComposant, Descriptif, ...)

Fournisseur (IdFournisseur, Siret, ...)

Projet (IdProjet, Descriptif, ...)

PrixComposant (IdComposant, IdFournisseur, IdProjet, DateAppli, Prix, Qte)

Toutefois, vous laissez entendre que le fournisseur peut changer le prix d’un composant : je continue à considérer qu’il s’agit d’un prix unitaire appliqué à un projet (si ce prix est indépendant des projets, cela a une incidence sur le MLD qui devra encore évoluer...)
En tout état de cause, si la quantité de composants n’est pas impliquée dans cette affaire, la table PrixComposant doit être remplacée par les deux tables suivantes :

PrixComposant1 (IdComposant, IdFournisseur, IdProjet, DateAppli, Prix)

PrixComposant2 (IdComposant, IdFournisseur, IdProjet, DateAppli, Qte)

[qlaimand]

D'accord, je vais étudier ce shéma.

Cependant, il y a 2 points ou je ne suis pas sûr de bien saisir:

- vers quoi renverrait la clé DateAppli de la table PrixComposant ? (une table d'historique où toutes les dates de modifications seraient enregistrées par exemple? Dans ce cas là, un IDdate me semblerait plus approprié au cas où 2opérations se feraient au même moment...)

- je n'arrive pas à comprendre pourquoi on aurait besoin de 2 tables PrixComposant.

Et pour votre curiosité ( ), j'ai repensé à cette histoire de remise, et elle rejoint un peu le fait que le prix change en fonction des projets:
- la personne pour qui je développe cette DB m'a expliqué que les fournisseurs pouvaient faire baisser les prix en fonction des clients auxquels ma société allait vendre ses projets, parceque certains clients ont des accords avec certains fournisseurs.

[fsmrel]

Bonsoir,

vers quoi renverrait la clé DateAppli de la table PrixComposant ?

Vers rien. DateAppli est un attribut de type Date, qui a simplement la particularité de participer à une clé, en compagnie de 3 autres attributs. Maintenant, si le même jour, pour le même projet, le même fournisseur il peut y avoir plus d’une opération, alors effectivement vous pouvez remplacer le type Date par un type Timestamp (résolution à la milliseconde) ou bien encore mettre en œuvre un identifiant relatif (de type entier) incrémenté d’une unité à chaque fois que pour une valeur donnée du triplet {IdComposant, IdFournisseur, IdProjet} on engrange une opération :

Avant

Code :

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

1
2
PrixComposant (IdComposant, IdFournisseur, IdProjet, IdRelatif, DateAppli, Prix, Qte)
                 c1             f1           j1         1          d1       p1    q1

Après

Code :

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

1
2
3
PrixComposant (IdComposant, IdFournisseur, IdProjet, IdRelatif, DateAppli, Prix, Qte)
                 c1             f1           j1         1          d1       p1    q1
                 c1             f1           j1         2          d1       p2    q2

je n'arrive pas à comprendre pourquoi on aurait besoin de 2 tables PrixComposant

Pour éviter de gérer des redondances : si un prix évolue, on insère une ligne dans la table PrixComposant1, sans qu’on ait besoin d’en faire autant dans la table PrixComposant2.
En revanche, si l’on n’a que la seule table PrixComposant, il faut prendre soin de recopier la quantité dans la ligne insérée. Mais à la limite, vous choisissez la stratégie qui vous convient le mieux.

certains clients ont des accords avec certains fournisseurs

Hum... On sort du périmètre, passons...

[qlaimand]

Bonjour,
merci de votre réponse, j'ai mis en place tout ça et ça tourne bien.

J'ai encore une petite question avant de pouvoir mettre le tag "résolu"...!

Toujours dans le même systême,
l'entreprise pour laquelle je travaille fait de la sous-traitance électronique, cela veut dire qu'il travaille a la fois avec des clients et des fournisseurs.
Pour une pièce ayant exactement les mêmes specs, il y a souvent plusieurs fournisseurs.
Le fait est que les clients et les fournisseurs travaillent avec leur propre références (à des composants), donc il arrive souvent que 2 pièces exactement identiques (au niveau specs) peuvent se retrouver jusqu'à 40 noms différents! De plus, aucun ID composant(propre à la l'entreprise) n'a été mis en place.

Voilà le modèle relationnel que j'ai mis en place concernant les nomenclatures:

COMPOSANT (id_composant, spec, desc...)
FOURNISSEUR (id_fournisseur, nom...)
CLIENT (id_client, nom...)

NOMENCLATURE_COMPOSANT_FOURNISSEUR (id_composant_cf#, id_fournisseur_cf#, nomenclature_composant_fournisseur...)

NOMENCLATURE_COMPOSANT_CLIENT(id_composant_cc#, id_client_cc#, nomenclature_composant_client...)

Est ce que ce schéma vous paraît correct? Dans quelme mesure pourrais-je l'améliorer?

Merci

[fsmrel]

Bonjour,

Est ce que ce schéma vous paraît correct ?

Ça tient la route. Juste une question : Au cas où un fournisseur (ou un client) modifie le nom d'un composant, procédez-vous par "annule et remplace", ou bien devez-vous conserver la trace des noms ?

[qlaimand]

Il faut que je conserve la trace des noms. Est-ce que cela implique un problème auquel je n'aurais pas pensé ? Pourquoi pas metter un statut sur les références clients, ou fournisseurs?

[fsmrel]

Considérez votre table (j’ai enlevé les "cf#" qui me font loucher) :

NCF (id_composant, id_fournisseur, nomenclature_composant_fournisseur...)

La clé est constituée du couple {id_composant, id_fournisseur} et pour ce couple vous ne pouvez avoir qu’une seule valeur pour les autres attributs de la table. Si vous devez conserver la trace des noms, ça ne sera pas possible, à moins de pratiquer comme pour les prix, en incorporant la date ou un identifiant relatif dans la clé :

Code :

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

1
2
3
NCF (IdComposant, IdFournisseur, IdRelatif, DateAppli, Libelle)
         c1            f1          1           d1        l1
         c1            f1          2           d2        l2

[qlaimand]

D'accord, c'est compris, merci!

J'aimerais aborder un dernier point, où il s'agirait d'approfondir un peu le sujet:
je suis allé consulter un (très bon) article de SQLPro concernant les méta données (suivant un lien que vous avez posté sur une discussion dans le forum).

Je suis étudiant, mes cours n'ont pas traité des méta données, mais j'aimerais pouvoir profiter de mon stage pour découvrir cet aspect des SGBD, et je sens que ce type d'approche pourrait être intéressante dans mon cas, pour ce que j'ai compris du concept (l'outil final doit s'avérer très souple pour l'utilisateur).
Si vous pensez que c'est le cas, dans quelle mesure cela pourrait m'être utile?
Auriez-vous des pistes, ou des conseils sur la voie à suivre pour traiter cet aspect? Comme j'ai dis plus-haut, j'ai saisi le concept, mais j'arrive pas bien à voir comment l'appliquer à mon projet, malgré la qualité et la clarté des explications de SQLPro (comme je viens de le dire aussi hehe ).

[fsmrel]

Bonjour qlaimand,

Je reprends ce que j’avais écrit dans la discussion entamée par hugo69 concernant la métamodélisation. En réponse à sa question :

Est que certains d'entre vous ont déjà tenté ce genre de conception ?

Ma réponse avait été la suivante :

Personnellement non, car les SGBD que j’utilise (DB2 for z/OS, SQL Server, ...) m’offrent déjà le service grâce à leur catalogue relationnel (tables SysTables recensant tables et vues, SysColums recensant les colonnes des précédentes, SyRrels décrivant les contraintes d’intégrité référentielle, SysForeignKeys, etc.)

Par contre, un AGL comme Cool:gen a sa propre métabase, car il gère des objets qui sortent du domaine du SGBD (partie IHM par exemple). Il a même une méta-métabase composée d’un nombre extrêmement réduit de tables (de mémoire, quelque chose comme 5 tables) mais pouvant devenir volumineuses, de l’ordre de la centaine de millions de lignes).

Au-delà, vouloir réduire le tout à une seule table, façon relation universelle (RU), n’offre guère d’intérêt quand on sort du cadre de la recherche théorique et vous vous inspirerez plutôt des écrits pragmatiques de SQLpro, évoqués par madfu.

Vous pouvez constater que je ne suis pas un adepte de la métamodélisation, car je ne suis éditeur ni de SGBD, ni d’AGL. Maintenant, si j’avais eu à développer des progiciels et autres logiciels à tout faire, il est probable que j’aurais mis en œuvre des entités-types du genre Caractéristique, à la façon de SQLpro, qui pose très bien le problème. En effet, lors de l’installation par exemple d’un ERP dans une entreprise, il y a des fatalement des adaptations à faire, des cas particuliers à traiter, toutes choses que l’outil magique ne peut prévoir, et dans ce genre d’exercice, il faut aller vite, le mot-clé est réactivité. Sinon, puisque je ne travaille pas dans l’urgence et que je réalise du sur-mesure, je fais en sorte que le MCD que je bâtis (ou valide) soit à même d’accueillir de nouvelles tables, sans métamodéliser, même si cela prendra un peu plus de temps : aller vite c’est peut-être bien, mais il ne faut pas que cela devienne une nécessité, suite à une certaine négligence initiale de ma part. Évidemment, cela ne s’apprend pas dans les livres, mais ne peut être que le constat de ce l’on observe vraiment sur le terrain, suite à des années d’expérience, chez des clients exigeants, du genre industrie, banque, assurance, grande distribution et j’en passe.

Je ne sais pas si vous avez étudié les techniques de généralisation/spécialisation. Si tel n’est pas le cas, je vous y engage vivement. Par exemple, pour remonter au niveau conceptuel, vous avez une entité-type Fournisseur et une autre Client. Pour factoriser ce qu’ils ont en commun (Nom, N° de Siren, Adresse, etc.) vous pouvez procéder par généralisation et mettre en œuvre une entité-type Personne, dont Fournisseur et Client seraient des spécialisations.

Une chose encore : si vous voulez creuser le sujet de la métamodélisation, n’oubliez pas de considérer la dimension temporelle des choses, c'est-à-dire la partie traitant de l’historique, comme dans le cas des prix des composants.

Bon courage.

[qlaimand]

fsmrel,

Merci pour vos conseils et votre point de vue.
Je vais tenter de mettre ça en place.
Je considère que mon problème est résolu, et que le discussion dérive vers d'autres aspects que la simple gestion d'un historique de prix.
J'ouvrirais éventuellement une autre discussion concernant méta-tables, généralisation/spécialisation, mais avant ça je vais me pencher un peu plus sur ces techniques.
Merci encore pour votre aide, j'espère vous recroiser sur le forum.