Discussion :

[Armagnak]

Salut,

Je modélise (enfin j'essaie) un stock et j'en bave un peu.
L'idée est de relier d'associer une nomenclature à chaque nouveau projet puis de confronter cette nomenclature avec le stock existant.
La présence du champ "Projet_id" dans la table "Articles en stock" est-elle concevable ou c'est n'importe quoi ?


Modélisation modifié après le message de Fsmrel

N'hésitez pas à critiquer...

Armagnak

[fsmrel]

Bonsoir Armagnak,


Concernant Nomenclatures : il ya quelque chose qui cloche. En effet il y a deux associations entre Références Articles et Nomenclatures (ce qui est normal pour une nomenclature) : je suppose que la première concerne le rôle Composant et la deuxième le rôle Composé, autrement dit, Article Id devrait apparaître deux fois dans Nomenclatures (avec bien sûr des noms différents, par exemple Art_Enfant_Id et Art_Parent_Id). Or, dans la liste des attributs on retrouve Nom_Article qui existe déjà dans Références Articles où, puisque Article_Id est clé primaire, il existe la dépendance fonctionnelle :

Article_Id -> Nom_Article

Nom_Article doit dégager de la clé de Nomenclatures et même dégager de Nomenclatures pour que la 2e forme normale soit respectée.

D’autre part, votre nomenclature est-elle une hiérarchie ou un graphe acyclique ? (autrement dit, un article peut-il entrer dans la composition de plus d’un article ? Ce qui serait le plus vraisemblable).
Un couple {article enfant, article parent} n’existe-t-il qu’une fois dans Nomenclatures, ou peut-il exister en plusieurs exemplaires, un par projet ? (pour le moment je retiens la 1ère hypothèse).

Par ailleurs, que fait l’attribut Projet_Id dans Articles en stock ?
Prix d’achat est-il vraiment à sa place ?

Je suppose que dans Projet, l’attribut Nom_Article est à renommer ?

Pourriez-vous utiliser un outil qui effectue des contrôles ? Ci-dessous, un petit MLD fait avec DBDesigner 4 (sans prétention mais gratuit et qui génère les Create Table) :

[Armagnak]

Salut et merci de ta réponse.

J'ai commencé par rectifier les champs de "nomenclatures" pour qu'ils correspondent à ce que j'avais fait sur papier

J'aimerais que ma table "articles_en_stock" comporte un enregistrement par article qui est (ou a été) en stock. Dans mon idée "articles_en_stock.stock_id" sert à distinguer plusieurs articles identiques en stock et "articles_en_stock.quantité" est obtenu en sommant les enregistrements ayant le même "articles_en_stock.article_id".

Par ailleurs, j'aimerais qu'il y ait autant de couple {article enfant, article parent} dans "nomenclatures" que de projet utilisant cette liaison. L'utilité étant de créer une nomenclature par projet (les nomenclatures seront souvent proches mais jamais exactement similaire dans la pratique).

Enfin, la présence de "articles_en_stock.projet_id" me permet de déterminer si l'article est disponible si ce champs est nul ou déjà utilisé/réservé par un projet. Le plus dur pour moi sera de concevoir l'interface PHP pour remplir ce champs lorsqu'on utilise des articles en stock.


En fait, mon MCD est cyclique C'est grave docteur ?

Armagnak

[fsmrel]

Bonjour Armagnak,


Remarque préliminaire, du genre point de détail, mais un peu de précision ne fait pas de mal. Vous écrivez : "...mon MCD..." : en fait nous étudions ici un MLD (modèle logique de données) avec des liens à la sauce conceptuelle (associations). De même, utilisez le terme "attribut" ou colonne" de préférence à celui de "champ" qui sert plutôt quand on parle de fichiers.

Dans mon idée "articles_en_stock.stock_id" sert à distinguer plusieurs articles identiques en stock

Excellent reflexe dans la mesure où Stock_Id est relatif à Article_Id (identification relative au sens conceptuel).

la présence de "articles_en_stock.projet_id" me permet de déterminer si l'article est disponible si ce champs est nul ou déjà utilisé/réservé par un projet

Par conformité avec votre représentation graphique, l’attribut Projet_Id ne peut pas prendre la valeur nulle, puisque les cardinalités minimales de l’association Est_utilisé_par sont à 1. Si vous prévoyez qu’à un article en stock ne soit pas nécessairement associé à un projet, alors la cardinalité 1,1 doit devenir 0,1. Mais en conséquence, la clé étrangère Projet_Id pourra prendre la valeur nulle, ce qui peut provoquer de gros problèmes avec le comportement des opérateurs relationnels, SQL pouvant en l’occurrence se révélant dangereux. Pour éviter les clés étrangères pouvant prendre la valeur nulle, le mieux est de prévoir la mise en œuvre d’une table ad-hoc, telle que Réserver (cf. la représentation graphique ci-dessous, en notant les cardinalités 0,1/1,1 entre Stock et Réserver).

En fait, mon MCD est cyclique C'est grave docteur ?

Graphiquement on a un cycle, mais ça n’est pas grave. Ça pourrait l’être si une table était "delete-connected to itself", c'est-à-dire si le serpent pouvait se mordre la queue, si la suppression d’une ligne d’une table pouvait entraîner la suppression d’autres lignes de cette table, via d’autres tables. En fait, on ne peut en juger qu’à condition d’observer le comportement métabolique de la base de données. Cela suppose que vous ayez défini les règles de comportement associées aux liens représentés par les clés étrangères : choix Cascade ou Restrict (No action pour certains SGBD), Set Null ou Set Default. Je ne préjuge pas de ce que sera votre choix final, mais j’ai retenu à titre d’exemple les options suivantes :

La suppression d’un article dans la table Article entraîne la suppression des lignes correspondantes dans la table Stock (effet Cascade). Elle entraîne la suppression de cet article en tant que composant dans la table Nomenclature. La suppression de cet article en tant que composé est refusée (Restrict) si d’autres articles sont présents en tant que composants de l’article.






La suppression d’un article dans la table Stock entraîne la suppression de la ligne correspondante dans la table Réserver.

La suppression d’un projet dans la table Projet entraîne la suppression des lignes correspondantes dans les tables Réserver et Nomenclature.

Par définition, la suppression d’une ligne dans la table Stock n’a aucun effet sur la table Article. Même principe pour la table Réserver vis-à-vis des tables Stock et Projet. Même principe pour la table Réserver vis-à-vis des tables Article et Projet.

Conclusion : manifestement le serpent ne peut pas se mordre la queue (même si le seul Restrict était remplacé par un Cascade) : la suppression d’un article ne touche même pas la table Projet et réciproquement. Les tables Réserver et Nomenclature jouent le rôle de barrières de sécurité.

J’ai dit que je ne préjugeais pas de vos choix, mais n’oubliez pas que l'utilisation systématique de Restrict pétrifie la base données, les opérations de suppression deviennent particulièrement pénibles.

En outre, pour des raisons de cohérence, les SGBDR fonctionnent selon le mode "tout ou rien" : si vous tentez de supprimer un article qui a des composants, du fait du Restrict, l’opération sera globalement annulée : le stock ne sera pas altéré.

Le plus dur pour moi sera de concevoir l'interface PHP

Je ne connais pas PHP. A titre de curiosité, quelle est la nature de la difficulté ? (Si ça n’est pas trop long à exposer...)

[Armagnak]

Salut et merci de vous intéresser à mon MLD

(...)
Par conformité avec votre représentation graphique, l’attribut Projet_Id ne peut pas prendre la valeur nulle, puisque les cardinalités minimales de l’association Est_utilisé_par sont à 1.
(...)

Au lieu d'ajouter la table de jonction "reserver", ne puis-je pas tout simplement créer un enregistrement "pas de projet" dont la table "projet" et l’attribut stock.Projet_Id ne serait jamais nul ?
ça fait un peu bricolage mais cela simplifie le tout sans nuire, non ?

Je dois vous avouer que je ne m'étais même pas poser la question des suppression mais j'ai lu attentivement votre analyse et elle me sera précieuse.
Je vais m'atteler à comprendre les règles de comportement associées aux liens représentés par les clés étrangères.

Pour le contexte, j'utilise MySQL avec des tables de type MyISAM.

Je ne connais pas PHP. A titre de curiosité, quelle est la nature de la difficulté ? (Si ça n’est pas trop long à exposer...)

Je parle de "difficulté" parce que je vais devoir m'aider de PHP pour réaliser certaines opérations sur ma base de données.
En particulier, je n'arrive pas à mettre à jour les attributs projet_id lorsqu'on fabrique un article à partir d'autres articles avec une unique requête SQL (en utilisant MySQL).

Armagnak

[fsmrel]

Bonsoir Armagnak,

Au lieu d'ajouter la table de jonction "reserver", ne puis-je pas tout simplement créer un enregistrement "pas de projet" dont la table "projet" et l’attribut stock.Projet_Id ne serait jamais nul ?
ça fait un peu bricolage mais cela simplifie le tout sans nuire, non ?

Techniquement, il est effectivement possible de créer un enregistrement "pas de projet". Cela dit, dans vos requêtes SQL, vous devrez en tenir compte, par exemple pour ne pas fausser des calculs d’agrégation (telles que SUM, Count, AVF, MIN, MAX). Ça sera une sorte de boulet. Par ailleurs il faut tenir compte d’éléments tels que la volumétrie, la concurrence d’accès, les cycles (que nous évoquions...) Par exemple, si vous avez 90% des articles en stock affectés à des projets, on peut discuter. S’il n’y en a que 10%, les requêtes portant sur la seule table Reserver seront plus efficaces et la concurrence d’accès moins polluante globalement pour le système. Personnellement, j’ai pris l’habitude dans l’univers des bases de données d’appeler un chat un chat et ne pas le déguiser : les applications n’en ont pas souffert, au contraire. Certes, les jointures peuvent entraîner un peu plus de complexité dans les requêtes, mais enfin l’opérateur de jointure est l’opérateur relationnel par excellence, il ne faut pas en avoir peur et en cas de doute on monte un petit prototype de performance pour comparer et trancher. Mais sachez que déguiser a toujours des effets secondaires, sinon pervers.

Je vais m'atteler à comprendre les règles de comportement associées aux liens représentés par les clés étrangères.

Ceci est capital, car au lieu de se limiter à l’anatomie de la base de données, on passe au niveau métabolique et il n’est pas rare que cela entraîne des modifications dans les modèles. A chaque fois la question à se poser est la suivante : « Si l’entité X reçoit un stimulus de la part de l’entité Y parce que celle-ci doit être supprimée, X est-elle obligée de s’incliner ou bien est-elle légitimement habilitée à faire jouer son droit de veto ? »
Par exemple, si une ligne de facture est en relation avec une facture d’une part et un article d’autre part, clairement cette ligne de facture n’a aucune raison de s’opposer à la mort de la facture donc à la sienne propre, puisqu’elle n’en est qu’un composant. En revanche, si c’est l’article avec lequel elle est en relation qui veut disparaître : que nenni, sinon on pourrait avoir des problèmes avec les gestionnaires des factures de l’entreprise... Il y a une dimension sémantique qui émerge très nettement et c’est bon pour la modélisation, la pertinence et la compréhension de la base de données.