sql >> Databasteknik >  >> RDS >> Database

Leverera julklappar:Tomtens datamodell

När semestern närmar sig med stormsteg behöver tomten lite extra hjälp för att leverera presenter till barn runt om i världen. Idag kommer vi att utveckla en datamodell som kan hjälpa tomten och hans tomtar att arbeta mer effektivt.

Bakgrund

Tomtens jobb är oerhört viktigt, så han måste göra allt han kan för att säkerställa framgång i tid. Kom bara ihåg alla problem som Howard stötte på i "Jingle All the Way" när han försökte hitta en enda Turbo Man-figur – vi kan inte låta tomten falla igen, annars kommer hans rykte att förstöras. Så, för att hjälpa tomten att hålla ordning, delar vi upp hans aktiviteter i tre huvudfaser.

  1. Planering

    Först måste tomten planera allt. När allt kommer omkring kan han inte låta sina tomtar springa runt i fabriken och få panik när de försöker förstå miljarder leveranser! Förutom att läsa årets brev och bestämma vilka presenter barn vill ha, bör vi också analysera eventuella trender från tidigare år för att samla in lite vanligt material eller till och med producera presenter i förväg. Detta kommer att bidra till att minska en del av eftersläpningen när vi börjar arbeta med produktionen.

  2. Produktion

    Efter planeringsfasen är vi redo att börja producera presenter. Med hjälp av tomtens tomtar kan vi snabbt tillverka och paketera presenter efter de önskelistor vi fått. För att göra processen mer effektiv måste vi dock organisera allt material och information vi har till hands så att tomtarna kan ta tag i sakerna de behöver så snabbt som möjligt.

  3. Leverans

    Ögonblicket närmar sig med stormsteg! Tomtens renar är klara, och mannen själv kollar oroligt på klockan. Presenter lastas snabbt i släden av tomtens medhjälpare. Vid det här laget tar jultomten en sista titt på sitt schema för att se till att han har alla rätt adresser, såväl som eventuella anteckningar han behöver tänka på.

Nu när vi har lite bakgrund om vilken typ av information vi behöver arbeta med kan vi äntligen börja designa tomtens datamodell.

Datamodellen




Denna datamodell består av tre sektioner:

  1. Artiklar
  2. Personer och önskelistor
  3. Leveranser

Låt oss ta en närmare titt på var och en av dessa.

Avsnitt 1:Artiklar

Vår datamodell börjar med avsnittet Objekt, som innehåller många tabeller som är centrala för de återstående två avsnitten.

item_type Tabellen är utan tvekan den viktigaste här. Den här tabellen innehåller en lista över alla föremål som vi behöver producera på tomtens fabrik. För varje vara lagrar vi följande information:

  • item_name — objektets namn.
  • properties — textuella nyckel-värdepar som anger storleken, formen, färgen och andra egenskaper hos det producerade föremålet, lagrat i ett strukturerat format.
  • description — en ostrukturerad textbeskrivning av föremålet.

Om vi ​​någonsin har två liknande föremål som bara skiljer sig åt i vissa av deras egenskaper, till exempel färg, kommer vi att lagra dem som individuella poster i tabellen.

När det gäller vår datamodell antar vi att tomten inte kommer att köpa presenter utan istället beordrar sina tomtar att producera allt hemma. För varje annan artikeltyp har vi en lista med förutsättningar som vi måste uppfylla. Dessa kan vara arbete eller material som trä, plast, metall och färger. Vi måste lagra en lista över alla möjliga förutsättningar och relatera dem till varje artikel vi behöver producera. Vi använder fyra tabeller för att uppnå detta.

Den första av dessa fyra tabeller är prerequisite , som, som namnet antyder, lagrar en lista över alla möjliga förutsättningar. För varje post i den här tabellen lagrar vi ett unikt förutsättningsnamn, alla ytterligare properties (denna gång i ett ostrukturerat format) och referenser till prerequisite_type och enhetsordböcker. prerequisite_type ordbok kommer att användas för att lagra en lista över alla förutsättningskategorier, såsom "arbete" och "material". unit ordbok kommer att användas för att lagra en lista över alla enheter som vi kommer att använda för att kvantifiera våra förutsättningar. Till exempel kan vi förvänta oss att arbete mäts i timmar eller minuter och att material mäts i termer av produktionskostnad (dollar), vikt (kilogram) eller volym (liter).

Den sista tabellen i det här avsnittet är warehouse , som vi kommer att använda för att spåra den aktuella statusen för vårt lager för både varor och material (därav item_type_id och prerequisite_id främmande nycklar). Endast en av dessa två nycklar kommer att innehålla ett värde vid en given tidpunkt. Utöver dessa nycklar lagrar vi den slutliga quantity som var tillgänglig på en viss warehouse_date .

Avsnitt 2:Personer och önskelistor

En kritisk del av vår datamodell, det här avsnittet handlar om de saker barn vill hitta under sina julgranar! Vi arbetar från höger till vänster.

De två tabellerna längst till höger är country och city . Vi kommer att använda dessa två tabeller när vi hänvisar till platsen för ett barn som skickade en önskelista till tomten. country Tabellen innehåller endast det unika country_name attribut och en lista över alla befintliga countries . För att vara mer exakt med våra platser använder vi city bord för att lagra alla städer som tomten behöver besöka. För varje stad i den här tabellen lagrar vi:

  • city_name — namnet på staden, vilket inte nödvändigtvis är unikt.
  • postal_code — stadens postnummer.
  • country_id — id för det land staden ligger i. Tillsammans med de två föregående attributen utgör detta den unika nyckeln för denna tabell.
  • latitude och longitude — används för att hjälpa tomten att hitta staden på sin karta eller för att ange dess koordinater i navigationssystemet han använder.

Självklart kan du inte ha önskningar utan människor! Vi lagrar en lista över alla personer i person tabell. För varje individ lagrar vi ett first_name , last_name , birth_date och city . Vi lagrar även personens adress samt eventuella ytterligare delivery_details Tomten kan behöva tänka på (som en lapp som anger att en person inte har en skorsten).

Den sista tabellen i det här avsnittet innehåller hela wish_list som lagrar alla julönskningar som någonsin gjorts. För varje önskan behöver vi veta:

  • person_id — en hänvisning till den person som gjorde önskemålet.
  • item_type_id — en hänvisning till den artikel (typ) som personen begärde.
  • quantity — den önskade kvantiteten av artikeln som anges i önskemålet.
  • details — alla detaljer som kan hjälpa tomten att uppfylla önskan.
  • ts — anger det ögonblick då önskan lagrades i vårt system, vilket är viktigt för att avgöra vilket år önskemålet gjordes.
  • gift_id — en hänvisning till presentbordet som anger gåvan som levererades för att uppfylla denna önskan.

Avsnitt 3:Leveranser

Nu har vi äntligen kommit fram till den mest intressanta delen av vår datamodell – gåvor och leveranser!

När en enskild artikel har producerats infogar vi dess relaterade post i item tabell. Observera att när en vara produceras är den fortfarande inte tilldelad någon gåva, så gift_id attribut kommer att innehålla värdet null tills föremålet är associerat med en viss gåva. Vi måste också lagra den typ av vara som producerades (item_type_id ), såväl som dess quantity . Även om en artikels kvantitet för det mesta kommer att vara 1, kan vi förvänta oss olika kvantiteter i vissa speciella fall (t.ex. mer än 1 artikel kombinerat till en uppsättning – detta är mycket ovanligt men ändå möjligt).

När vi går vidare kommer vi att kombinera en eller flera föremål för att producera en gift . Vi uppdaterar item.gift_id när vi har packat in våra utvalda föremål i den presenten. Varje gåva kommer att levereras till den relaterade personen (person_id ) och kommer att ha en spårningsstatus (current_status_id ), samt en tidsstämpel för när tomten planerar att leverera presenten (delivery_time_planned ). Vi kommer också att uppdatera värdet på wish_list.gift_id attribut för alla varor som har levererats.

De två sista tabellerna i denna datamodell gäller spårning av leveransstatus. Först, status Tabellen innehåller ett unikt status_name värde som vi kommer att använda när vi hänvisar till aktuell status för gft (gift.current_status_id ). Dessutom status_history tabellen kommer att lagra en lista över alla statusar för alla gåvor i vår databas, såväl som tidsstämplarna för alla statusuppdateringar (ts).

Förhoppningsvis kommer vår datamodell att hjälpa tomten att slutföra ännu ett framgångsrikt år med leveranser så att vi alla kan få våra presenter i tid. Om du är på humör för mer jul-tema SQL, har Vertabelo Academy förberett en speciell semesterutmaning med 24 frågor. Varsågod och kolla in det! Å familjen Vertabelos vägnar hoppas vi att ni får en underbar jul!


  1. Hur kan jag få kolumnnamn från en tabell i Oracle?

  2. PostgreSQL 11:Vad är nytt

  3. ogiltigt namnmönster när man försöker skicka anpassad objektmappning av orakeltyp

  4. Java lagrad procedur vs PL/SQL lagrad procedur