Identification de la structure de la nomenclature (BOM) dans les bases de données

Le modèle de conception de la nomenclature (BOM) est d'une simplicité trompeuse, mais incroyablement puissant. Historiquement, il a été utilisé pour modéliser les structures de produits, mais le modèle peut être utilisé pour faire bien plus que simplement définir une hiérarchie. Cet article présentera trois exemples très différents pour vous aider à reconnaître le modèle dans vos propres projets.

Qu'est-ce qu'une nomenclature ?

Une nomenclature a ses racines dans la fabrication. Il s'agit d'une liste des matières premières, des sous-ensembles, des assemblages intermédiaires, des sous-composants, des pièces et des quantités de chacun nécessaires à la fabrication d'un produit final. Vous pouvez le voir comme une décomposition hiérarchique d'un produit. D'autres termes pour la même chose sont la structure du produit, la nomenclature et la liste associée.

Pour illustrer une nomenclature, regardez le modèle conceptuel ci-dessous. Cela commence par le produit de premier niveau, Car . En gros, une Car a un Engine et un Body . Dans cet exemple, il existe différents types de moteurs :V6 et V8. Il existe différents types de carrosseries :3 portes, 5 portes et break (appelé aussi break ou break). Le processus de décomposition peut descendre jusqu'au tout dernier écrou et boulon - ou même jusqu'à un peu de colle - mais vous obtenez l'image.

Au niveau le plus simple, vous joignez deux parties sous la forme d'une hiérarchie - une partie parent à une partie enfant - du haut de la hiérarchie jusqu'en bas. Le modèle de nomenclature de fabrication le plus basique ressemble à ceci :

Il s'agit de la structure de nomenclature classique , où une seule table [parent] a deux relations avec une table de jonction [enfant].

Voici la hiérarchie de produits simple de l'exemple de la voiture :

Les nomenclatures de fabrication ont généralement le même type de propriétés principales :

• Les assemblages, sous-assemblages et composants individuels peuvent être réutilisés . Par exemple, le même type de boulon peut être utilisé dans différents types d'assemblage.
• Il doit souvent y avoir une quantité spécifique à la hiérarchie . Par exemple, il est important de savoir qu'un assemblage nécessite 10 boulons, mais qu'un autre assemblage peut nécessiter 15 boulons de la même spécification.

Une fois que vous avez défini un assemblage, sa structure est automatiquement importée dans tous les autres assemblages qui l'utilisent. Donc, si cet assemblage devait changer, toutes les autres nomenclatures qui l'utilisent seront automatiquement mises à jour. Les nomenclatures qui décrivent des sous-assemblages comme celui-ci sont appelées nomenclatures modulaires .

Pour les fabricants, une nomenclature est une information essentielle sur le produit, un enregistrement qui répertorie tout ce qui est nécessaire pour fabriquer un produit. Des techniques de modélisation avancées sont nécessaires pour gérer les éléments configurables produits, composants variantes , ou substitut Composants. La modification d'une petite partie d'un produit peut avoir plusieurs impacts sur d'autres nomenclatures de produits. Sans ces considérations, la gestion des nomenclatures peut devenir assez ingérable.

Mais ce domaine spécialisé dépasse le cadre de cet article. Au lieu de cela, nous nous concentrerons sur des exemples d'endroits où les structures de nomenclature peuvent apparaître dans la conception de bases de données. Une fois que vous serez en mesure de reconnaître une nomenclature, vous pourrez utiliser ce puissant modèle de conception.

Commençons par un exemple courant :la relation plusieurs-à-plusieurs entre les vols et les aéroports.

Qu'est-ce que le modèle de nomenclature a à voir avec les vols ?

Voici le modèle conceptuel :

Imaginez-vous dans n'importe quel aéroport du monde. De là, vous pourrez voir des avions décoller vers d'autres destinations. Vous verrez également des avions atterrir d'autres destinations. Il existe donc une relation plusieurs à plusieurs entre les aéroports de départ et d'arrivée.

En règle générale, nous résolvons cette relation plusieurs-à-plusieurs à l'aide d'une table de jonction :

Le Flight la classe aura ses propres attributs, y compris flightNumber , scheduledDepartureTime , et scheduledArrivalTime .

En regardant notre modèle, nous pouvons repérer un problème mineur. Nous savons qu'il n'existe pas d'DepartureAirport ou un ArrivalAirport . Ce ne sont que des aéroports de départ et d'arrivée.

Nous fusionnons donc DepartureAirport et ArrivalAirport dans un seul airport tableau comme celui-ci :

Encore une fois, cela suit la structure de nomenclature classique , où une seule table [parent] a deux relations avec une table de jonction [enfant].

Conceptuellement cependant, il y a une grande différence entre cela et une nomenclature de fabrication. Cette nomenclature n'a pas de véritable structure hiérarchique. C'est complètement plat. Pourquoi est-ce que je dis ça ?

Il est préférable de le décrire à l'aide d'un exemple.

Considérons d'abord quelques exemples de données pour cette nomenclature :

Nous allons maintenant travailler sur un exemple. Imaginez que vous ayez besoin de voler de Manchester à Chennai. Il n'y a pas de vols directs. Mais vous pouvez voler de Manchester à Dubaï, la première étape de votre voyage. Vous pouvez ensuite prendre un autre vol de Dubaï à Chennai, la deuxième étape de votre voyage. Si les deux étapes forment votre itinéraire, la deuxième étape n'est en aucun cas une sorte de sous-composante de la première étape ! Par conséquent, cette structure est plate.

Mais notez la correspondance des données 1:1 entre les parties et les vols exemples :Voiture → Manchester; Moteur → Dubaï ; Chennai → V6.

Dans l'exemple de la voiture, les pièces forment une hiérarchie étroitement couplée . Dans l'exemple de l'aéroport, les vols peuvent être traversés pour former davantage de connexions à couplage lâche entre les vols. Pour un passager voyageant de Manchester à Chennai, un itinéraire doit être créé. Ceci est le résultat d'une requête, qui prend en compte ce qui constitue une connexion - par ex. le temps minimum et maximum entre les vols ; si la même compagnie aérienne doit être utilisée ou si différentes compagnies aériennes sont autorisées.

Voyons maintenant comment la nomenclature peut être utilisée pour décrire les relations dans la modélisation des données.

Relations dans la structure de nomenclature

J'entends par là les relations entre les personnes, entre les organisations et entre les organisations et les personnes. Ce sont des relations réelles, comme quelqu'un qui est employé d'une entreprise ou membre d'une équipe, ou d'une entreprise propriétaire d'une autre entreprise. Le modèle conceptuel ressemble à ceci :

Si vous deviez mapper cela directement sur un modèle physique, vous auriez des tables de jonction pour chacune des relations plusieurs-à-plusieurs. Cela peut être un peu encombré et cela n'aide pas à exécuter des requêtes - par exemple, trouver toutes les relations d'une Person a.

Il est donc probablement préférable de reconnaître cette Person et Organization sont différents types de Party . Cela nous permet de simplifier les trois relations plusieurs-à-plusieurs en une seule :

Si vos exigences sont simples, cela peut suffire. Mais dans le monde réel, les choses n'ont pas tendance à être aussi simples. Par exemple, un employé peut quitter une entreprise pour voyager à travers le monde pendant un certain temps. Au retour de ses voyages, il cherche du travail et est réembauché par l'entreprise qu'il a quittée. (Ça arrive !) L'employé a donc deux instances distinctes d'une relation avec cet employeur, chacune avec des dates d'effet différentes et éventuellement avec un ID d'employé différent.

Ainsi, la relation elle-même nécessite des attributs. Cela signifie une autre entité, Relationship , doit obligatoirement les contenir :

Encore une fois, cela suit la structure de nomenclature classique , où une seule table [parent] a deux relations avec une table de jonction [enfant].

Par convention, dans ce modèle le 1 l'interacteur a tendance à être le Party dans la Relationship comme l'employeur plutôt que l'employé, ou le chef d'équipe plutôt que le membre de l'équipe.

Ce modèle de nomenclature de relation de partie peut être utilisé pour répertorier tous les employés (2 interactor ) dans une organisation (1 interactor ) au contractuel niveau si vous voulez. Il s'agit d'une hiérarchie plate à un seul niveau. Il peut également être utilisé simultanément pour définir l'ensemble de la structure de reporting de gestion (ou hiérarchie) au sein d'une même organisation, qui peut avoir n'importe quel nombre de niveaux. Par exemple :un employé peut travailler sous un même contrat pendant plusieurs années, mais peut se retrouver à travailler pour différents managers au cours de cette période (1 interacteur = responsable ; 2 interacteur = rapporte à). Il peut même travailler simultanément pour plusieurs managers.

Voici à quoi pourraient ressembler les données (avec leurs rôles respectifs entre parenthèses) :

Apprenez à connaître la nomenclature

Tandis que la nomenclature structure a ses racines dans la fabrication, il peut être utilisé à différentes fins , qui peut aller de quelque chose de strictement hiérarchique et étroitement couplé à quelque chose d'assez plat et plus lâche.

J'espère que ces exemples vous aideront à reconnaître le modèle de nomenclature s'il existe dans vos projets. Une fois que vous aurez reconnu le modèle, vous comprendrez comment il doit être mis en œuvre. Vous n'avez pas à réinventer la roue à chaque fois, il vous suffit de l'adapter à vos besoins spécifiques.