De stuklijststructuur (BOM) in databases identificeren

Het ontwerppatroon van de stuklijst (BOM) is bedrieglijk eenvoudig, maar toch ongelooflijk krachtig. Historisch gezien werd het gebruikt om productstructuren te modelleren, maar het patroon kan voor veel meer worden gebruikt dan alleen het definiëren van een hiërarchie. Dit artikel introduceert drie zeer verschillende voorbeelden om u te helpen het patroon in uw eigen projecten te herkennen.

Wat is een stuklijst of stuklijst?

Een stuklijst heeft zijn wortels in de productie. Het is een lijst van de grondstoffen, subassemblages, tussenassemblages, subcomponenten, onderdelen en de hoeveelheden die nodig zijn om een ​​eindproduct te vervaardigen. Je kunt het zien als een hiërarchische decompositie van een product. Andere termen voor hetzelfde zijn productstructuur, stuklijst en bijbehorende lijst.

Bekijk het conceptuele model hieronder om een ​​stuklijst te illustreren. Het begint met het topproduct, Car . In grote lijnen een Car heeft een Engine en een Body . In dit voorbeeld zijn er verschillende typen motoren:V6 en V8. Er zijn verschillende soorten carrosserieën:3-deurs, 5-deurs en stationwagen (ook wel wagon of stationwagen genoemd). Het ontbindingsproces kan tot de laatste moer en bout gaan - of zelfs een beetje lijm - maar je snapt het wel.

Op het eenvoudigste niveau voegt u twee delen samen in de vorm van een hiërarchie - een bovenliggend deel tot een onderliggend deel - van de top van de hiërarchie tot aan de onderkant. Het meest elementaire stuklijstmodel voor fabricage ziet er als volgt uit:

Dit is de klassieke stuklijststructuur , waarbij een enkele [bovenliggende] tabel twee relaties heeft met een [onderliggende] verbindingstabel.

Hier is de eenvoudige producthiërarchie uit het voorbeeld van de auto:

Stuklijsten in productie hebben meestal dezelfde soort belangrijke eigenschappen:

• Assembly's, sub-assemblies en individuele componenten kunnen hergebruikt worden . Hetzelfde soort bout kan bijvoorbeeld worden gebruikt in verschillende soorten montage.
• Er moet vaak een hiërarchie-specifieke hoeveelheid . zijn . Het is bijvoorbeeld belangrijk om te weten dat de ene assemblage 10 bouten nodig heeft, maar voor een andere assemblage kunnen 15 bouten met dezelfde specificatie nodig zijn.

Zodra u een merk definieert, wordt de structuur automatisch geïmporteerd in andere merken die er gebruik van maken. Dus als die assembly zou veranderen, dan worden alle andere stuklijsten die er gebruik van maken automatisch geüpdatet. Stuklijsten die subassemblages als deze beschrijven, worden modulaire stuklijsten genoemd .

Voor fabrikanten is een stuklijst een cruciaal stuk productinformatie, een record dat alles opsomt dat nodig is om een ​​product te vervaardigen. Geavanceerde modelleringstechnieken zijn vereist om configureerbare . te verwerken producten, component variaties , of vervangen componenten. Het wijzigen van een klein onderdeel van een product kan meerdere gevolgen hebben voor andere productstuklijsten. Zonder hiermee rekening te houden, kan BOM-beheer behoorlijk onhandelbaar worden.

Maar dit specialistische gebied valt buiten het bestek van dit artikel. In plaats daarvan zullen we ons concentreren op voorbeelden van waar stuklijststructuren kunnen voorkomen in databaseontwerp. Zodra u een stuklijst kunt herkennen, kunt u dit krachtige ontwerppatroon gebruiken.

We beginnen met een veelvoorkomend voorbeeld:de veel-op-veel-relatie tussen vluchten en luchthavens.

Wat heeft het stuklijstpatroon met vluchten te maken?

Hier is het conceptuele model:

Stel je voor dat je op elke luchthaven ter wereld bent. Vanaf daar kunt u vliegtuigen zien opstijgen naar andere bestemmingen. Je zult ook vliegtuigen zien landen vanaf andere bestemmingen. Er is dus een veel-op-veel-relatie tussen vertrek- en aankomstluchthavens.

Meestal lossen we deze veel-op-veel-relatie op met behulp van een verbindingstabel:

De Flight klasse heeft zijn eigen kenmerken, waaronder flightNumber , scheduledDepartureTime , en scheduledArrivalTime .

Als we terugkijken op ons model, zien we mogelijk een klein probleem. We weten dat er niet zoiets bestaat als een DepartureAirport of een ArrivalAirport . Het zijn allebei slechts luchthavens van waaruit vluchten vertrekken en waar vluchten aankomen.

Dus we voegen DepartureAirport en ArrivalAirport in een enkele airport tabel als volgt:

Wederom volgt dit de klassieke stuklijststructuur , waarbij een enkele [bovenliggende] tabel twee relaties heeft met een [onderliggende] verbindingstabel.

Conceptueel is er echter een groot verschil tussen deze en een productiestuklijst. Deze stuklijst heeft geen echte hiërarchische structuur. Het is helemaal vlak. Waarom zeg ik dit?

Het kan het beste worden beschreven aan de hand van een voorbeeld.

Laten we eerst eens kijken naar enkele voorbeeldgegevens voor deze stuklijst:

Nu zullen we een voorbeeld doornemen. Stel je voor dat je van Manchester naar Chennai moet vliegen. Er zijn geen directe vluchten. Maar u kunt wel van Manchester naar Dubai vliegen, het eerste deel van uw reis. U kunt dan nog een vlucht nemen van Dubai naar Chennai, het tweede deel van uw reis. Hoewel de twee etappes uw reisroute vormen, is de tweede etappe op geen enkele manier een subonderdeel van de eerste etappe! Daarom is deze structuur plat.

Maar let op de 1:1 correspondentie van gegevens tussen de onderdelen en vluchten voorbeelden:Auto → Manchester; Motor → Dubai; Chennai → V6.

In het autovoorbeeld vormen de onderdelen een strak gekoppelde hiërarchie . In het luchthavenvoorbeeld kunnen vluchten worden overgestoken om meer losjes gekoppelde verbindingen te vormen tussen vluchten. Voor een passagier die van Manchester naar Chennai vliegt, moet een reisschema worden gemaakt. Dit is het resultaat van een zoekopdracht, die rekening houdt met wat een verbinding is - b.v. de minimale en maximale tijd tussen vluchten; of dezelfde luchtvaartmaatschappij moet worden gebruikt of dat verschillende luchtvaartmaatschappijen zijn toegestaan.

Laten we vervolgens eens kijken hoe BOM kan worden gebruikt om relaties in gegevensmodellering te beschrijven.

Relaties in de stuklijststructuur

Hiermee bedoel ik relaties tussen mensen, tussen organisaties en tussen organisaties en mensen. Dit zijn relaties in de echte wereld, zoals iemand die een werknemer is van een bedrijf of een lid van een team, of van een bedrijf dat eigenaar is van een ander bedrijf. Het conceptuele model ziet er als volgt uit:

Als je dit rechtstreeks zou toewijzen aan een fysiek model, zou je verbindingstabellen hebben voor elk van de veel-op-veel-relaties. Dit kan een beetje onoverzichtelijk worden en het helpt niet bij het uitvoeren van zoekopdrachten, bijvoorbeeld het vinden van alle relaties van een Person heeft.

Het is dus waarschijnlijk beter om die Person en Organization zijn verschillende soorten Party . Dit stelt ons in staat om de drie veel-op-veel relaties te vereenvoudigen tot één enkele:

Als uw vereisten eenvoudig zijn, kan dit voldoende zijn. Maar in de echte wereld zijn de dingen niet zo eenvoudig. Een werknemer kan bijvoorbeeld een bedrijf verlaten om een ​​tijdje de wereld rond te reizen. Als hij terugkomt van zijn reizen, zoekt hij werk en wordt opnieuw aangenomen door het bedrijf dat hij heeft verlaten. (Het gebeurt!) De werknemer heeft daarom twee afzonderlijke gevallen van een relatie met deze werkgever, elk met verschillende ingangsdata en mogelijk met een ander werknemers-ID.

Dus de relatie zelf vereist attributen. Dit betekent een andere entiteit, Relationship , is vereist om ze te bevatten:

Wederom volgt dit de klassieke stuklijststructuur , waarbij een enkele [bovenliggende] tabel twee relaties heeft met een [onderliggende] verbindingstabel.

Volgens afspraak is in dit model de 1 interactor is meestal de superieure Party in de Relationship zoals de werkgever in plaats van de werknemer, of de teamleider in plaats van het teamlid.

Dit partij-relatie BOM-patroon kan worden gebruikt om alle werknemers weer te geven (2 interactor ) in een organisatie (1 interactor ) aan de contractuele niveau als je wilt. Dit is een platte hiërarchie op één niveau. Het kan ook gelijktijdig worden gebruikt om de volledige managementrapportagestructuur te definiëren (of hiërarchie) bij dezelfde organisatie, die een willekeurig aantal niveaus kan hebben. Bijvoorbeeld:een werknemer kan een aantal jaren onder één contract werken, maar kan in die periode voor verschillende managers werken (1 interactor =verantwoordelijk voor; 2 interactor =rapporteert aan). Hij kan zelfs gelijktijdig voor meer dan één manager werken.

Dit is hoe de gegevens eruit kunnen zien (met hun respectievelijke rollen tussen haakjes):

Maak kennis met de stuklijst

Terwijl de stuklijst structuur heeft zijn wortels in productie, het kan voor verschillende doeleinden worden gebruikt , die kan variëren van iets strikt hiërarchisch en nauw gekoppeld tot iets vrij vlak en losser gekoppeld.

Ik hoop dat deze voorbeelden je zullen helpen om het stuklijstpatroon te herkennen als het in je projecten voorkomt. Zodra u het patroon herkent, begrijpt u hoe het moet worden geïmplementeerd. U hoeft niet elke keer het wiel opnieuw uit te vinden - u hoeft het alleen maar aan uw specifieke vereisten aan te passen.