Identifikation af styklistestrukturen i databaser

Styklisten (BOM) designmønsteret er vildledende enkelt, men alligevel utroligt kraftfuldt. Historisk set er det blevet brugt til at modellere produktstrukturer, men mønsteret kan bruges til at gøre meget mere end blot at definere et hierarki. Denne artikel vil introducere tre meget forskellige eksempler for at hjælpe dig med at genkende mønsteret i dine egne projekter.

Hvad er en stykliste eller stykliste?

En materialeliste har sine rødder i fremstillingen. Det er en liste over råmaterialer, underenheder, mellemkonstruktioner, underkomponenter, dele og mængden af ​​hver, der er nødvendig for at fremstille et slutprodukt. Du kan se på det som en hierarkisk nedbrydning af et produkt. Andre udtryk for det samme er produktstruktur, stykliste og tilhørende liste.

For at illustrere en stykliste, se på den konceptuelle model nedenfor. Det starter med produktet på øverste niveau, Car . I store træk en Car har en Engine og en Body . I dette eksempel er der forskellige typer motorer:V6 og V8. Der er forskellige typer karosserier:3-dørs, 5-dørs og stationcar (også kendt som en vogn eller stationcar). Nedbrydningsprocessen kan gå ned til den allersidste møtrik og bolt – eller endda en klat lim – men du forstår billedet.

På det enkleste niveau forbinder du to dele i form af et hierarki - en overordnet del til en underordnet del - fra toppen af ​​hierarkiet helt ned til bunden. Den mest basale produktionsstykliste-model ser sådan ud:

Dette er den klassiske styklistestruktur , hvor en enkelt [forælder]-tabel har to relationer med en [under]-forbindelsestabel.

Her er det enkle produkthierarki fra bileksemplet:

Styklister i fremstilling har tendens til at have samme slags hovedegenskaber:

• Samlinger, underenheder og individuelle komponenter kan genbruges . For eksempel kan den samme slags bolt bruges i forskellige typer montering.
• Der skal ofte være en hierarki-specifik mængde . Det er f.eks. vigtigt at vide, at én samling har brug for 10 bolte, men en anden samling kan have brug for 15 bolte med samme specifikation.

Når du har defineret en samling, importeres dens struktur automatisk til alle andre forsamlinger, der gør brug af den. Så hvis den samling skulle ændre sig, så vil alle andre styklister, der bruger den, automatisk blive opdateret. Styklister, der beskriver undersamlinger som denne, omtales som modulære styklister .

For producenter er en stykliste et kritisk stykke produktinformation, en post, der viser alt, hvad der er nødvendigt for at fremstille et produkt. Avancerede modelleringsteknikker er nødvendige for at håndtere konfigurerbare produkter, komponent variationer , eller erstatning komponenter. Ændring af en lille del af et produkt kan have flere indvirkninger på andre produktstyklister. Uden at tage disse i betragtning, kan styklistestyring blive ret uoverskuelig.

Men dette specialistområde er uden for rammerne af denne artikel. I stedet vil vi fokusere på eksempler på, hvor styklistestrukturer kan forekomme i databasedesign. Når du kan genkende en stykliste, vil du være i stand til at gøre brug af dette kraftfulde designmønster.

Vi starter med et almindeligt eksempel:mange-til-mange-forholdet mellem fly og lufthavne.

Hvad har styklistemønstret med flyrejser at gøre?

Her er den konceptuelle model:

Forestil dig dig selv i enhver lufthavn i verden. Derfra vil du kunne se fly lette til andre destinationer. Du vil også se fly lande fra andre destinationer. Så der er et mange-til-mange forhold mellem afgangs- og ankomstlufthavne.

Typisk løser vi denne mange-til-mange-relation ved hjælp af en forbindelsestabel:

Flight klasse vil have sine egne attributter, inklusive flightNumber , scheduledDepartureTime , og scheduledArrivalTime .

Når vi ser tilbage på vores model, opdager vi muligvis et mindre problem. Vi ved, at der ikke findes en DepartureAirport eller en ArrivalAirport . De er begge blot lufthavne, hvorfra fly afgår, og hvortil fly ankommer.

Så vi slår DepartureAirport og ArrivalAirport til en enkelt airport tabel som denne:

Igen følger dette den klassiske styklistestruktur , hvor en enkelt [forælder]-tabel har to relationer med en [under]-forbindelsestabel.

Konceptuelt er der dog en stor forskel mellem dette og en fremstillingsstykliste. Denne stykliste har ingen ægte hierarkisk struktur. Det er helt fladt. Hvorfor siger jeg dette?

Det er bedst beskrevet som et eksempel.

Lad os først overveje nogle eksempeldata for denne stykliste:

Nu skal vi gennemgå et eksempel. Forestil dig, at du skal flyve fra Manchester til Chennai. Der er ingen direkte fly. Men du kan flyve fra Manchester til Dubai, den første del af din rejse. Du kan derefter tage et andet fly fra Dubai til Chennai, den anden del af din rejse. Mens de to ben udgør din rejseplan, er det andet etape på ingen måde en slags underkomponent af det første etape! Derfor er denne struktur flad.

Men bemærk 1:1 dataenes korrespondance mellem dele og flyvninger eksempler:Bil → Manchester; Motor → Dubai; Chennai → V6.

I bileksemplet danner delene et tæt koblet hierarki . I lufthavnseksemplet kan flyvninger krydses for at danne flere løst koblede forbindelser mellem flyvninger. For en passager, der flyver fra Manchester til Chennai, skal der oprettes en rejseplan. Dette er resultatet af en forespørgsel, som tager højde for, hvad der udgør en forbindelse – f.eks. minimums- og maksimumstiden mellem flyvninger; om det samme flyselskab skal benyttes, eller om forskellige flyselskaber er tilladt.

Lad os derefter se på, hvordan stykliste kan bruges til at beskrive sammenhænge i datamodellering.

Relationer i styklistestrukturen

Med dette mener jeg relationer mellem mennesker, mellem organisationer og mellem organisationer og mennesker. Disse er relationer i den virkelige verden, såsom en person, der er ansat i en virksomhed eller et medlem af et team, eller af en virksomhed, der ejer en anden virksomhed. Den konceptuelle model ser således ud:

Hvis du skulle kortlægge dette direkte til en fysisk model, ville du have forbindelsestabeller for hver af mange-til-mange relationerne. Dette kan blive lidt rodet, og det hjælper ikke med at køre forespørgsler – for eksempel at finde alle relationerne en Person har.

Så det er nok bedre at genkende den Person og Organization er forskellige typer Party . Dette giver os mulighed for at forenkle de tre mange-til-mange-forhold til et enkelt:

Hvis dine krav er enkle, kan dette være tilstrækkeligt. Men i den virkelige verden plejer tingene ikke at være så enkle. For eksempel kan en medarbejder forlade en virksomhed for at rejse rundt i verden for en tid. Da han vender tilbage fra sine rejser, søger han arbejde og bliver genansat af det firma, han forlod. (Det sker!) Medarbejderen har derfor to separate tilfælde af et forhold til denne arbejdsgiver, hver med forskellige ikrafttrædelsesdatoer og muligvis med et andet medarbejder-id.

Så selve forholdet kræver attributter. Dette betyder en anden enhed, Relationship , er påkrævet for at indeholde dem:

Igen følger dette den klassiske styklistestruktur , hvor en enkelt [forælder]-tabel har to relationer med en [under]-forbindelsestabel.

Efter konvention er 1 i denne model interaktør plejer at være den overlegne Party i Relationship såsom arbejdsgiveren frem for medarbejderen, eller teamlederen frem for teammedlemmet.

Dette styklistemønster for partiforhold kan bruges til at liste alle medarbejdere (2 interactor ) i en organisation (1 interactor ) på kontrakten niveau om du vil. Dette er et fladt hierarki på ét niveau. Den kan også bruges samtidigt at definere hele ledelsesrapporteringsstrukturen (eller hierarki) i den samme organisation, som kan have et hvilket som helst antal niveauer. For eksempel:en medarbejder kan arbejde under én kontrakt i en årrække, men kan finde sig i at arbejde for forskellige ledere i den periode (1 interaktør =ansvarlig for; 2 interaktør =rapporterer til). Han kan endda arbejde samtidig for mere end én leder.

Sådan kan dataene se ud (med deres respektive roller i parentes):

Lær styklisten at kende

Mens styklisten struktur har sine rødder i fremstillingen, den kan bruges til forskellige formål , som kan spænde fra noget strengt hierarkisk og tæt koblet til noget ret fladt og mere løst koblet.

Mit håb er, at disse eksempler vil hjælpe dig til at genkende styklistemønstret, hvis det findes i dine projekter. Når du genkender mønsteret, vil du forstå, hvordan det skal implementeres. Du behøver ikke at genopfinde hjulet hver gang – du skal bare skræddersy det til dine specifikke krav.