Le modèle que vous décrivez est souvent appelé une « explosion de pièces » ou « nomenclature ». Il fait partie de la partie graphiques et arbres de l'étude des structures de données. L'essence de la solution est de réaliser que tout «produit» donné peut être composé d'autres «produits». La conception est alors une structure de réseau où il y a une Product
table qui a une ligne pour chaque produit - qu'elle soit composée d'autres produits ou non, puis une Product Component
table qui a une ligne pour chaque produit qui est composée d'autres produits et chaque produit correspondant qui est un composant de ce produit. Dans votre cas, chaque produit a un prix. Vous auriez donc quelque chose comme ça
Product
-----------------------------------
|Name |Price |
-----------------------------------
|Orange |1 |
|Apple |1.20 |
|Fruit Package |3.80 |
-----------------------------------
Product Component
----------------------------------------------------------
|Product |Contains |Quantity|
----------------------------------------------------------
|Fruit Package |Orange |2 |
|Fruit Package |Apple |2 |
----------------------------------------------------------
Cette conception est préférable à une table unique avec une association récursive car elle sépare proprement ce qui sont en réalité deux types d'entités - nœuds et liens. Dans notre cas, les produits sont les nœuds et les composants du produit sont les liens.
Bien que la conception du réseau soit une structure commune, l'interrogation est problématique car lorsqu'elle est complètement remplie, il s'agit d'une structure récursive de profondeur variable. Les SGBD de puissance industrielle tels qu'Oracle et SQL Server ont des éléments de langage spéciaux (CONNECT BY d'Oracle et CTE récursif de SQL Server) pour aider à rendre la requête déclarative. Étant donné que vous utilisez File Maker Pro, que je connais peu, vous n'aurez peut-être pas de telles constructions de langage pour vous aider et devrez peut-être écrire du code de procédure pour traverser le réseau. Ce problème peut cependant être résolu si le réseau s'avère d'une profondeur fixe - par exemple, chaque produit ne possède aucun composant ou un seul niveau de composants. Voici quelques références concernant les structures de réseau dans la conception de bases de données:
- Problèmes pratiques de gestion de base de données - Fabian Pascal . Le chapitre 7 fournit l'explication la meilleure et la plus compréhensible que j'ai trouvée.
- Arbres et hiérarchies de Joe Celko dans SQL pour Smarties, deuxième édition . Il s'agit d'un livre entier sur le sujet spécifique à la norme SQL.
- Modèles de modèle d'entreprise - David Hay . Un livre sur les modèles communs à toutes les organisations (malheureusement, les diagrammes ER sont présentés en UML mais qui peuvent être surmontés), il existe plusieurs exemples de structures de réseau.