conception de base de données pour les enfants récursives

Question

Ce problème de conception se avère être un peu plus « intéressant » que je pensais ....

Pour le contexte, je vais implantera quelle que soit la solution que je tire dans Access 2007 (pas beaucoup de choix - l'exigence du client I pourrait être capable de les parler dans un autre backend, mais le frontal doit être Access (et donc VBA & Access SQL)). Les deux principales activités que je prévois autour de ces tables sont l'importation par lots de nouvelles structures à partir de fichiers plats et la génération de rapports sur les structures (avec une récurrence complète de la structure entière). Pratiquement pas de suppressions ou de mises à jour (à part des arbres entiers marqués comme inactifs lorsqu'une nouvelle version est créée).

J'ai deux tables principales et je me demande si je peux vraiment les relier: les produits et les pièces (il y en a d'autres, mais ils sont assez simples en comparaison).

Les produits sont composés de pièces. Une pièce peut être utilisée dans plus d'un produit, et la plupart des produits emploient plus d'une pièce. Je pense qu'une table de résolution de many-to-many peut satisfaire à cette exigence (la plupart du temps - je reviendrai dans une minute). J'appellerai cette partie de produit.

La partie «amusante» est que de nombreuses pièces sont également constituées de pièces. Encore une fois, une partie donnée peut être utilisée dans plus d'une partie parente (même dans un seul produit). Non seulement cela, je pense que je dois traiter le nombre de niveaux de récursion comme effectivement arbitraire.

Je peux capturer les relations avec une résolution m-à-m de Pièces à Pièces, reliant chaque partie non-racine à sa partie parente immédiate, mais j'ai la suspicion que je pourrais me mettre en deuil si je m'arrête là. Je vais appeler cette partie-partie. Plusieurs questions me viennent à l'esprit:

1. Est-ce que je m'embarrasse en m'interrogeant à ce sujet? En d'autres termes, est-ce que je devrais juste mettre en application les deux tables de résolution comme indiqué ci-dessus, et cesser de m'inquiéter? Dois-je également créer des rangées de parties de parties pour tous les ancêtres de chaque partie non racine, avec une colonne supplémentaire dans la table pour stocker le nombre de générations?

2. La partie produit doit-elle contenir des lignes pour chaque partie du produit ou uniquement les parties racine? Si ce sont toutes les parties, un indicateur de génération serait-il utile?

3. J'ai (juste aujourd'hui, à partir des questions connexes), jeté un coup d'oeil à l'approche de conception de jeu imbriqué. Il semble que cela pourrait simplifier certaines exigences (en particulier en ce qui concerne les rapports), mais penser à générer l'arbre lors de l'importation de centaines (parfois des milliers) de pièces dans une importation de produit me donne des cauchemars avant même que je m'endorme. Vais-je mieux mordre cette balle et aller de l'avant de cette façon?

En plus des questions spécifiques ci-dessus, je vous en serais reconnaissant toute autre comentary sur la conception structurelle, ainsi que des conseils sur la façon de traiter ce soit entrant ou sortant (si je crains que je peux 't divertir suggestions de changement de l'environnement langage/SGBD).

Answer 1

Les listes de matériaux et les listes de pièces éclatées sont toujours très amusantes. Je voudrais implémenter des parties comme table principale, avec un champ booléen pour dire qu'une partie est "vendable". Cela supprime la différence de récursivité de premier niveau et la redondance des parties qui sont elles-mêmes des produits. Ensuite, implémentez les produits en vue des pièces vendables.

Vous êtes sur la bonne voie avec la table de références croisées PartPart. Implémentez une contrainte sur cette table qui indique que la partie parente et la partie enfant ne peuvent pas avoir le même ID de partie, pour vous épargner des maux de tête avec une récursion infinie.

Les différences de génération entre les nomenclatures peuvent être gérées en créant une nouvelle pièce au niveau du changement réel et à tous les niveaux supérieurs dans lesquels le changement doit être effectué (si vous voulez dire que cette nouvelle pièce fait partie de sa hiérarchie parent, aboutit à un nouveau produit). Ensuite, mettez à jour l'arbre de référence de tous les niveaux de parties qui n'ont pas été révisés dans cette modification générationnelle (pour maintenir les parties et les produits qui ne devraient pas changer de génération si un enfant le fait). Pour éviter les orphelins (enregistrements de pièces non référencés inaccessibles depuis le niveau supérieur), Parts peut référencer directement son prédécesseur en créant une liste chaînée d'ancêtres.

C'est un web très complexe, c'est sûr; les structures arborescentes persistantes d'objets représentés de la même manière le sont habituellement. Mais, si vous êtes intelligent dans l'implémentation de contraintes pour renforcer l'intégrité référentielle et éviter une récursion infinie, je pense que cela sera gérable.

Answer 2

Je voudrais avoir une table partie pour les parties atomiques, puis une table superpart avec un superpartID et ses sous-parties connexes. Ensuite, vous pouvez avoir une table produit/superpart. Si une pièce est également une superpart, alors vous avez juste une ligne pour le superpartID avec le même partID.

Peut-être que 'composant' est un meilleur terme que superpart. Les composants pourraient être réutilisés dans des composants plus gros, par exemple.

Answer 3

Vous pouvez trouver des échantillons Bill schémas de base de données Matériaux à

http://www.databaseanswers.org/data_models/

Le site offre des applications d'accès pour certains des modèles. Vérifiez auprès de l'auteur du site.