Identifiera materialstycksstrukturen (BOM) i databaser

Designmönstret för stycklistor (BOM) är bedrägligt enkelt, men ändå otroligt kraftfullt. Historiskt sett har det använts för att modellera produktstrukturer, men mönstret kan användas för att göra mycket mer än att bara definiera en hierarki. Den här artikeln kommer att introducera tre mycket olika exempel för att hjälpa dig att känna igen mönstret i dina egna projekt.

Vad är en stycklista?

En materiallista har sina rötter i tillverkningen. Det är en lista över råvaror, underenheter, mellanenheter, underkomponenter, delar och de kvantiteter av varje som behövs för att tillverka en slutprodukt. Du kan se det som en hierarkisk nedbrytning av en produkt. Andra termer för samma sak är produktstruktur, stycklista och tillhörande lista.

För att illustrera en BOM, titta på den konceptuella modellen nedan. Det börjar med produkten på toppnivå, Car . I stort sett en Car har en Engine och en Body . I det här exemplet finns det olika typer av motorer:V6 och V8. Det finns olika typer av karosser:3-dörrars, 5-dörrars och kombi (även känd som vagn eller kombi). Nedbrytningsprocessen kan gå ner till den allra sista muttern och bulten – eller till och med en klick lim – men du förstår.

På den enklaste nivån sammanfogar du två delar i form av en hierarki – en överordnad del till en underordnad del – från toppen av hierarkin ända ner till botten. Den mest grundläggande tillverkningsstycklistmodellen ser ut så här:

Detta är den klassiska BOM-strukturen , där en enda [förälder]-tabell har två relationer med en [underordnad]-övergångstabell.

Här är den enkla produkthierarkin från bilexemplet:

Stycklistor i tillverkning tenderar att ha samma typ av huvudegenskaper:

• Sammanställningar, underenheter och enskilda komponenter kan återanvändas . Till exempel kan samma typ av bult användas i olika typer av montering.
• Det måste ofta finnas en hierarkispecifik kvantitet . Till exempel är det viktigt att veta att en enhet behöver 10 bultar, men en annan enhet kan behöva 15 bultar med samma specifikation.

När du väl har definierat en sammansättning importeras dess struktur automatiskt till alla andra sammansättningar som använder den. Så om den sammansättningen skulle ändras kommer alla andra stycklistor som använder den att uppdateras automatiskt. Stycklistor som beskriver underenheter som denna kallas modulära stycklistor .

För tillverkare är en stycklista en viktig del av produktinformation, en post som listar allt som behövs för att tillverka en produkt. Avancerade modelleringstekniker krävs för att hantera konfigurerbara produkter, komponentvarianter , eller ersätta komponenter. Att ändra en liten del av en produkt kan ha flera effekter på andra produktstycklar. Utan att ta hänsyn till dessa kan BOM-hanteringen bli ganska ohanterlig.

Men detta specialistområde ligger utanför ramen för denna artikel. Istället kommer vi att fokusera på exempel på var BOM-strukturer kan förekomma i databasdesign. När du kan känna igen en BOM kommer du att kunna använda detta kraftfulla designmönster.

Vi börjar med ett vanligt exempel:många-till-många-relationen mellan flyg och flygplatser.

Vad har styckmönstret med flyg att göra?

Här är den konceptuella modellen:

Föreställ dig själv på vilken flygplats som helst i världen. Därifrån kommer du att kunna se flygplan lyfta till andra destinationer. Du kommer också att se flygplan som landar från andra destinationer. Så det finns ett många-till-många-samband mellan avgångs- och ankomstflygplatser.

Vanligtvis löser vi denna många-till-många-relation med hjälp av en korsningstabell:

Flight klass kommer att ha sina egna attribut, inklusive flightNumber , scheduledDepartureTime och scheduledArrivalTime .

När vi ser tillbaka på vår modell kan vi upptäcka ett mindre problem. Vi vet att det inte finns något sådant som en DepartureAirport eller en ArrivalAirport . De är båda bara flygplatser som flygen avgår från och till vilka flygen anländer.

Så vi slår samman DepartureAirport och ArrivalAirport till en enda airport tabell så här:

Återigen följer detta den klassiska BOM-strukturen , där en enda [förälder]-tabell har två relationer med en [underordnad]-övergångstabell.

Konceptuellt är det dock en stor skillnad mellan detta och en tillverkningsstycklista. Denna BOM har ingen verklig hierarkisk struktur. Det är helt platt. Varför säger jag detta?

Det är bäst att beskriva som ett exempel.

Låt oss först överväga några exempeldata för denna BOM:

Nu ska vi gå igenom ett exempel. Föreställ dig att du behöver flyga från Manchester till Chennai. Det finns inga direktflyg. Men du kan flyga från Manchester till Dubai, den första delen av din resa. Du kan sedan ta ett nytt flyg från Dubai till Chennai, den andra delen av din resa. Även om de två etapperna utgör din resplan, är den andra etappen inte på något sätt någon form av delkomponent av den första etappen! Därför är denna struktur platt.

Men notera 1:1 dataöverensstämmelsen mellan delarna och flygexemplen:Bil → Manchester; Motor → Dubai; Chennai → V6.

I bilexemplet bildar delarna en tätt sammankopplad hierarki . I exemplet på flygplatsen kan flygningar passeras för att bilda fler löst kopplade förbindelser mellan flygen. För en passagerare som flyger från Manchester till Chennai måste en resplan skapas. Detta är resultatet av en förfrågan, som tar hänsyn till vad som utgör en anslutning – t.ex. den minsta och maximala tiden mellan flygningar; om samma flygbolag måste användas eller om olika flygbolag är tillåtna.

Låt oss sedan titta på hur BOM kan användas för att beskriva samband i datamodellering.

Relationer i BOM-strukturen

Med detta menar jag relationer mellan människor, mellan organisationer och mellan organisationer och människor. Dessa är verkliga relationer, som att någon är anställd i ett företag eller medlem i ett team, eller i ett företag som äger ett annat företag. Den konceptuella modellen ser ut så här:

Om du skulle mappa detta till direkt till en fysisk modell, skulle du ha korsningstabeller för var och en av många-till-många-relationerna. Det här kan bli lite rörigt, och det hjälper inte med att köra frågor – till exempel att hitta alla relationer en Person har.

Så det är förmodligen bättre att känna igen den Person och Organization är olika typer av Party . Detta gör att vi kan förenkla de tre många-till-många-relationerna till en enda:

Om dina krav är enkla kan detta vara tillräckligt. Men i den verkliga världen brukar saker och ting inte vara så enkla. Till exempel kan en anställd lämna ett företag för att resa runt i världen under en tid. När han kommer tillbaka från sina resor söker han arbete och blir återanställd av företaget han lämnade. (Det händer!) Den anställde har därför två separata instanser av en relation med denna arbetsgivare, var och en med olika ikraftträdandedatum och möjligen med olika anställd-ID.

Så själva relationen kräver attribut. Detta betyder en annan enhet, Relationship , krävs för att innehålla dem:

Återigen följer detta den klassiska BOM-strukturen , där en enda [förälder]-tabell har två relationer med en [underordnad]-övergångstabell.

Enligt konventionen är 1 i denna modell interaktör tenderar att vara den överlägsna Party i Relationship såsom arbetsgivaren snarare än den anställde, eller teamledaren snarare än teammedlemmen.

Detta parti-förhållande BOM-mönster kan användas för att lista alla anställda (2 interactor ) i en organisation (1 interactor ) på kontraktsstället nivå om du vill. Detta är en platt hierarki på en nivå. Den kan också användas samtidigt för att definiera hela ledningsrapporteringsstrukturen (eller hierarki) i samma organisation, som kan ha hur många nivåer som helst. Till exempel:en anställd kan arbeta under ett kontrakt under ett antal år men kan finna sig själv att arbeta för olika chefer under den perioden (1 interaktör =ansvarig för; 2 interaktör =rapporterar till). Han kan till och med arbeta samtidigt för mer än en chef.

Så här kan data se ut (med deras respektive roller inom parentes):

Lär känna BOM

Medan materialförteckningen struktur har sina rötter i tillverkningen, den kan användas för olika ändamål , som kan sträcka sig från något strikt hierarkiskt och tätt kopplat till något ganska platt och mer löst kopplat.

Min förhoppning är att dessa exempel kommer att hjälpa dig att känna igen BOM-mönstret om det finns i dina projekt. När du känner igen mönstret kommer du att förstå hur det ska implementeras. Du behöver inte uppfinna hjulet på nytt varje gång – du behöver bara skräddarsy det efter dina specifika krav.