Идентифициране на структурата на спецификацията (BOM) в базите данни

Моделът за проектиране на спецификациите на материалите (BOM) е измамно прост, но невероятно мощен. В исторически план той е бил използван за моделиране на продуктови структури, но моделът може да се използва за много повече от просто дефиниране на йерархия. Тази статия ще представи три много различни примера, които да ви помогнат да разпознаете модела във вашите собствени проекти.

Какво е спецификация или спецификация?

Слитна спецификация има своите корени в производството. Това е списък на суровините, подвъзлите, междинните възли, подкомпонентите, частите и количествата от всеки, необходими за производството на краен продукт. Можете да го разглеждате като йерархична декомпозиция на продукт. Други термини за същото нещо са продуктова структура, спецификация на материала и свързан списък.

За да илюстрирате спецификация, вижте концептуалния модел по-долу. Започва с продукта от най-високо ниво, Car . Най-общо казано, Car има Engine и Body . В този пример има различни типове двигатели:V6 и V8. Има различни видове каросерии:с 3 врати, с 5 врати и комби (известни още като комби или комби). Процесът на разлагане може да се сведе до последната гайка и болт – или дори малко лепило – но получавате картината.

На най-простото ниво, вие съединявате две части заедно под формата на йерархия – родителска част към дъщерна част – от върха на йерархията надолу до дъното. Най-основният производствен модел на спецификация изглежда така:

Това е класическата структура на спецификацията , където единична [родителска] таблица има две релации с [дъще] съединителна таблица.

Ето простата йерархия на продуктите от примера с колата:

Спецификациите в производството обикновено имат същия вид основни свойства:

• Сглобки, подвъзли и отделни компоненти могат да се използват повторно . Например един и същ вид болт може да се използва в различни видове монтаж.
• Често трябва да има специфично за йерархията количество . Например, важно е да знаете, че един модул се нуждае от 10 болта, но друг модул може да се нуждае от 15 болта със същата спецификация.

След като дефинирате сбор, неговата структура автоматично се импортира във всички други сборки, които го използват. Така че, ако този сбор се промени, тогава всички други спецификации, които го използват, ще бъдат актуализирани автоматично. Спецификациите, които описват подвъзли като тази, се наричат ​​модулни спецификации .

За производителите спецификацията е важна част от информация за продукта, запис, който изброява всичко необходимо за производството на продукт. Необходими са усъвършенствани техники за моделиране за работа с конфигурируеми продукти, компонентини , или заместител компоненти. Промяната на малка част от продукт може да има множество въздействия върху спецификациите на други продукти. Без да се вземат предвид това, управлението на BOM може да стане доста неуправляемо.

Но тази специализирана област е извън обхвата на тази статия. Вместо това ще се съсредоточим върху примери за това къде могат да се появят структури на спецификациите при проектирането на база данни. След като можете да разпознаете спецификация, ще можете да използвате този мощен модел на дизайн.

Ще започнем с общ пример:връзката много към много между полети и летища.

Какво общо има моделът на спецификацията с полетите?

Ето концептуалния модел:

Представете си себе си на всяко летище по света. От там ще можете да видите излитащи самолети за други дестинации. Ще видите и самолети, които кацат от други дестинации. Така че има връзка много към много между летища за заминаване и пристигане.

Обикновено разрешаваме тази връзка много към много с помощта на таблица за свързване:

Flight класът ще има свои собствени атрибути, включително flightNumber , scheduledDepartureTime и scheduledArrivalTime .

Поглеждайки назад към нашия модел, може да забележим малък проблем. Знаем, че няма такова нещо като DepartureAirport или ArrivalAirport . И двете са просто летища, от които тръгват и до които пристигат полети.

Затова обединяваме DepartureAirport и ArrivalAirport в едно airport таблица като тази:

Отново това следва класическата структура на спецификацията , където единична [родителска] таблица има две релации с [дъще] съединителна таблица.

Концептуално обаче има голяма разлика между това и производствената спецификация. Тази спецификация няма истинска йерархична структура. Напълно плосък е. Защо казвам това?

Най-добре е описано като пример.

Първо, нека разгледаме някои примерни данни за тази спецификация:

Сега ще работим с пример. Представете си, че трябва да летите от Манчестър до Ченай. Няма директни полети. Но можете да летите от Манчестър до Дубай, първият етап от вашето пътуване. След това можете да вземете друг полет от Дубай до Ченай, вторият етап от вашето пътуване. Докато двата крака формират вашия маршрут, по никакъв начин вторият етап не е някакъв подкомпонент на първия! Следователно тази структура е плоска.

Но имайте предвид съответствието на данните 1:1 между частите и примерите за полети:Автомобил → Манчестър; Двигател → Дубай; Ченай → V6.

В примера с автомобила частите образуваттясно свързана йерархия . В примера за летището полетите могат да се преминават, за да образуват повече слабо свързани връзки между полети. За пътник, летящ от Манчестър до Ченай, трябва да се създаде маршрут. Това е резултат от заявка, която взема предвид какво представлява връзка – напр. минималното и максималното време между полетите; дали трябва да се използва една и съща авиокомпания или са разрешени различни авиокомпании.

След това нека разгледаме как спецификацията може да се използва за описване на връзки в моделирането на данни.

Взаимоотношения в структурата на спецификацията

Под това имам предвид взаимоотношенията между хората, между организациите и между организациите и хората. Това са отношения в реалния свят, като например някой да е служител на компания или член на екип, или на компания, притежаваща друга компания. Концептуалният модел изглежда така:

Ако трябва да съпоставите това директно с физически модел, ще имате таблици за свързване за всяка от връзките много към много. Това може да стане малко претрупано и не помага при изпълнение на заявки – например намиране на всички връзки като Person има.

Така че вероятно е по-добре да разпознаете този Person и Organization са различни видове Party . Това ни позволява да опростим трите отношения много към много в една:

Ако вашите изисквания са прости, това може да е достатъчно. Но в реалния свят нещата не са толкова прости. Например, служител може да напусне компания, за да пътува по света за известно време. Когато се връща от пътуванията си, той търси работа и отново е нает от компанията, която е напуснал. (Случва се!) Следователно служителят има два отделни случая на връзка с този работодател, всеки с различни дати на влизане в сила и вероятно с различен идентификационен номер на служител.

Така че самата връзка изисква атрибути. Това означава друг обект, Relationship , се изисква да ги съдържа:

Отново това следва класическата структура на спецификацията , където единична [родителска] таблица има две релации с [дъще] съединителна таблица.

По конвенция в този модел 1 interactor има тенденция да бъде превъзходната Party в Relationship като работодателя, а не служителя, или лидера на екипа, а не члена на екипа.

Този модел на спецификация на взаимоотношения между страните може да се използва за изброяване на всички служители (2 interactor ) в организация (1 interactor). ) придоговорното ниво, ако щете. Това е плоска йерархия на едно ниво. Може също да се използва едновременно за дефиниране на цялатаструктура за отчети за управление (или йерархия) в една и съща организация, която може да има произволен брой нива. Например:един служител може да работи по един договор в продължение на няколко години, но може да се окаже, че работи за различни мениджъри през този период (1 интерактор =отговорен за; 2 интерактор =докладва). Той дори може да работи едновременно за повече от един мениджър.

Ето как могат да изглеждат данните (със съответните им роли в скоби):

Запознайте се със спецификацията

Докато спецификацията на материална структурата има своите корени в производството, може да се използва за различни цели , което може да варира от нещо строго йерархично и тясно свързано до нещо доста плоско и по-слабо свързано.

Надявам се, че тези примери ще ви помогнат да разпознаете модела на спецификацията, ако той съществува във вашите проекти. След като разпознаете модела, ще разберете как трябва да бъде приложен. Не е нужно да изобретявате колелото всеки път – просто трябва да го приспособите към вашите специфични изисквания.