Identifikace struktury kusovníku (BOM) v databázích

Návrhový vzor kusovníku (BOM) je zdánlivě jednoduchý, ale neuvěřitelně výkonný. Historicky se používal k modelování produktových struktur, ale vzor lze použít k mnohem více než pouhému definování hierarchie. Tento článek představí tři velmi odlišné příklady, které vám pomohou rozpoznat vzor ve vašich vlastních projektech.

Co je kusovník nebo kusovník?

kusovník má kořeny ve výrobě. Je to seznam surovin, podsestav, mezisložek, dílčích součástí, dílů a množství každého potřebného k výrobě konečného produktu. Můžete se na to dívat jako na hierarchický rozklad produktu. Další termíny pro stejnou věc jsou struktura produktu, kusovník a související seznam.

Pro ilustraci kusovníku se podívejte na koncepční model níže. Začíná produktem nejvyšší úrovně, Car . Obecně řečeno, Car má Engine a Body . V tomto příkladu jsou různé typy motorů:V6 a V8. Existují různé typy karoserií:3dveřové, 5dveřové a kombi (také známé jako kombi nebo kombi). Proces rozkladu může jít až do poslední matice a šroubu – nebo dokonce kousku lepidla – ale pochopíte.

Na nejjednodušší úrovni spojujete dvě části dohromady ve formě hierarchie – nadřazené části k podřízené části – od vrcholu hierarchie až dolů. Nejzákladnější model výrobního kusovníku vypadá takto:

Toto je klasická struktura kusovníku , kde jedna [nadřazená] tabulka má dva vztahy s [podřízenou] spojovací tabulkou.

Zde je jednoduchá hierarchie produktů z příkladu Car:

Kusovníky ve výrobě mívají stejný druh hlavních vlastností:

• Sestavy, podsestavy a jednotlivé komponenty lze znovu použít . Například stejný druh šroubu lze použít v různých typech montáže.
• Často musí existovat množina specifická pro hierarchii . Je například důležité vědět, že jedna sestava potřebuje 10 šroubů, ale jiná sestava může potřebovat 15 šroubů stejné specifikace.

Jakmile definujete sestavu, její struktura se automaticky importuje do všech ostatních sestav, které ji využívají. Pokud by se tedy tato sestava měla změnit, všechny ostatní kusovníky, které ji používají, budou automaticky aktualizovány. Kusovníky, které popisují podsestavy, jako je tento, se označují jako modulární kusovníky .

Pro výrobce je kusovník kritickou informací o produktu, záznamem, který uvádí vše potřebné k výrobě produktu. Pro práci s konfigurovatelnými jsou vyžadovány pokročilé techniky modelování produkty, variace komponent , nebo náhrada komponenty. Změna malé části produktu může mít více dopadů na kusovníky jiných produktů. Bez zohlednění těchto skutečností se správa kusovníků může stát zcela neovladatelnou.

Tato specializovaná oblast však přesahuje rámec tohoto článku. Místo toho se zaměříme na příklady, kde se mohou vyskytovat struktury kusovníku v návrhu databáze. Jakmile rozpoznáte kusovník, budete moci využít tento výkonný návrhový vzor.

Začneme běžným příkladem:vztahem mnoho k mnoha mezi lety a letišti.

Co má vzor kusovníku společného s lety?

Zde je koncepční model:

Představte si sami sebe na jakémkoli letišti na světě. Odtud budete moci vidět letadla startující do jiných destinací. Uvidíte i letadla přistávající z jiných destinací. Mezi letišti odletu a příletu tedy existuje vztah mnoho k mnoha.

Tento vztah mnoho k mnoha obvykle řešíme pomocí spojovací tabulky:

Flight class bude mít své vlastní atributy, včetně flightNumber , scheduledDepartureTime a scheduledArrivalTime .

Když se podíváme zpět na náš model, můžeme zaznamenat menší problém. Víme, že nic takového jako DepartureAirport nebo ArrivalAirport . Obě jsou to jen letiště, ze kterých lety odlétají a na která lety přilétají.

Slučujeme tedy DepartureAirport a ArrivalAirport do jediného airport tabulka takto:

Opět platí klasická struktura kusovníku , kde jedna [nadřazená] tabulka má dva vztahy s [podřízenou] spojovací tabulkou.

Koncepčně je však mezi tímto a výrobním kusovníkem velký rozdíl. Tento kusovník nemá žádnou skutečnou hierarchickou strukturu. Je to úplně ploché. Proč to říkám?

Nejlépe je to popsáno na příkladu.

Nejprve se podívejme na některá vzorová data pro tento kusovník:

Nyní projdeme příkladem. Představte si, že potřebujete letět z Manchesteru do Chennai. Neexistují žádné přímé lety. Ale můžete letět z Manchesteru do Dubaje, což je první úsek vaší cesty. Poté můžete podniknout další let z Dubaje do Chennai, což je druhý úsek vaší cesty. Zatímco dvě části tvoří váš itinerář, druhá část v žádném případě není jakousi podsložkou první části! Proto je tato struktura plochá.

Všimněte si však shody dat 1:1 příklady mezi díly a lety:Auto → Manchester; Motor → Dubaj; Chennai → V6.

V příkladu automobilu tvoří díly pevně propojenou hierarchii . V příkladu letiště lze lety procházet a vytvářet více volně spojených spojení mezi lety. Pro cestujícího letícího z Manchesteru do Chennai je třeba vytvořit itinerář. Toto je výsledek dotazu, který bere v úvahu, co tvoří spojení – např. minimální a maximální doba mezi lety; zda musí být použita stejná letecká společnost nebo zda jsou povoleny různé letecké společnosti.

Dále se podívejme, jak lze kusovník použít k popisu vztahů v datovém modelování.

Vztahy ve struktuře kusovníku

Mám tím na mysli vztahy mezi lidmi, mezi organizacemi a mezi organizacemi a lidmi. Jedná se o vztahy v reálném světě, například když je někdo zaměstnancem společnosti nebo členem týmu nebo společnosti vlastnící jinou společnost. Koncepční model vypadá takto:

Pokud byste to namapovali přímo na fyzický model, měli byste spojovací tabulky pro každý z vztahů many-to-many. To může být trochu nepřehledné a nepomáhá to se spouštěním dotazů – například hledání všech vztahů a Person má.

Takže je pravděpodobně lepší rozpoznat tu Person a Organization jsou různé typy Party . To nám umožňuje zjednodušit tři vztahy many-to-many do jediného:

Pokud jsou vaše požadavky jednoduché, může to stačit. Ale ve skutečném světě věci nebývají tak jednoduché. Zaměstnanec může například opustit společnost a vydat se na nějaký čas na cestu po celém světě. Když se vrátí z cest, hledá si práci a je znovu přijat do firmy, ze které odešel. (Stává se!) Zaměstnanec má tedy dva samostatné případy vztahu s tímto zaměstnavatelem, každý s jiným datem účinnosti a možná s jiným ID zaměstnance.

Takže vztah sám o sobě vyžaduje atributy. To znamená další entitu, Relationship , musí je obsahovat:

Opět platí klasická struktura kusovníku , kde jedna [nadřazená] tabulka má dva vztahy s [podřízenou] spojovací tabulkou.

Podle konvence je v tomto modelu 1 interaktor má tendenci být nadřazenou Party ve Relationship jako je zaměstnavatel spíše než zaměstnanec nebo vedoucí týmu spíše než člen týmu.

Tento vzor kusovníku vztahu mezi stranou lze použít k zobrazení seznamu všech zaměstnanců (2 interactor ) v organizaci (1 interactor ) u smluvní úroveň, chcete-li. Toto je plochá hierarchie jedné úrovně. Lze jej také použít současně definovat celou strukturu manažerských výkazů (nebo hierarchie) ve stejné organizaci, která může mít libovolný počet úrovní. Například:zaměstnanec může pracovat na základě jedné smlouvy několik let, ale během tohoto období může pracovat pro různé manažery (1 interaktor =odpovědný za; 2 interaktor =podřízené). Může dokonce pracovat současně pro více než jednoho manažera.

Zde je návod, jak mohou data vypadat (s jejich příslušnými rolemi v závorkách):

Seznamte se s kusovníkem

Zatímco kusovník struktura má své kořeny ve výrobě, lze jej použít k různým účelům , která se může pohybovat od něčeho přísně hierarchického a těsně propojeného až po něco poměrně plochého a volněji propojeného.

Doufám, že tyto příklady vám pomohou rozpoznat vzor kusovníku, pokud ve vašich projektech existuje. Jakmile rozpoznáte vzor, ​​pochopíte, jak by měl být implementován. Nemusíte pokaždé znovu vynalézat kolo – stačí jej přizpůsobit svým konkrétním požadavkům.