Een gegevensmodel voor de bezorging van boodschappen

Als er een manier is om online boodschappen te bestellen, waarom zou je die dan niet gebruiken? Dit artikel onderzoekt het datamodel achter het bezorgsysteem van een supermarkt.

We krijgen nog steeds een speciaal gevoel als we iets uit de tuin plukken en het dan meteen klaarmaken - maar het is niet iets dat we vaak kunnen doen. Het hoge tempo van vandaag laat dat niet toe. Soms staan we zelfs niet eens toe om naar de winkel te gaan om onze boodschappen te "picken". Het is dus logisch om onszelf wat tijd te besparen en een app te gebruiken om te bestellen wat we nodig hebben. Onze bestelling komt gewoon bij ons thuis. Misschien krijgen we niet dat speciale versgeplukte gevoel, maar staat er wel eten op tafel.

Het datamodel achter zo'n applicatie is het onderwerp van het artikel van vandaag.

Wat hebben we nodig voor een gegevensmodel voor de bezorging van boodschappen?

Het idee van dit model is dat een applicatie (web, mobiel of beide) geregistreerde klanten in staat stelt een bestelling te plaatsen (bestaande uit producten uit onze winkel). Dan wordt deze bestelling bij de klant afgeleverd. We zullen uiteraard klantgegevens en een lijst van alle beschikbare producten opslaan om dit te ondersteunen.

Klanten kunnen meerdere bestellingen plaatsen die verschillende artikelen in verschillende hoeveelheden bevatten. Wanneer de bestelling van een klant wordt ontvangen, moeten winkelmedewerkers op de hoogte worden gesteld, zodat ze de benodigde artikelen kunnen vinden en inpakken. (Hiervoor kunnen één of meerdere containers nodig zijn.) Ten slotte worden de containers, samen of apart geleverd.

In de app zelf moeten klanten en medewerkers na de levering notities kunnen invoegen en de andere partij kunnen beoordelen.

Het gegevensmodel

Het datamodel bestaat uit drie vakgebieden:

Items & units
Customers & employees
Orders

We presenteren elk onderwerp in de volgorde waarin het wordt vermeld.

Sectie 1:Artikelen en Eenheden

We beginnen met de Items & units gebied. Hoewel het een klein onderdeel van ons model is, bevat het twee zeer belangrijke tabellen.

De unit tabel bevat informatie over de eenheden die we aan elk item in onze inventaris zullen toewijzen. Voor elke waarde in deze tabel slaan we twee UNIEKE waarden op:unit_name (bijv. "kilogram") en unit_short (bijv. "kg"). Merk op dat unit_short is de afkorting voor unit_name .

De tweede tabel in dit onderwerpgebied is item . Hierin staan alle artikelen die we in voorraad hebben. Voor elk item slaan we op:

item_name – De UNIEKE naam die we voor dat item zullen gebruiken.
price – De huidige prijs van dat artikel.
item_photo – Een link naar een foto van dit item.
description – Aanvullende tekstuele beschrijving van het item.
unit_id – Verwijst naar de unit woordenboek en geeft de eenheid aan die wordt gebruikt om dat item te meten.

Houd er rekening mee dat ik hier een aantal dingen heb weggelaten. De belangrijkste is een vlag die aangeeft of een inventarisitem momenteel te koop wordt aangeboden. Waarom hebben we dit niet? Het zou ten minste één extra veld (de vlag) en een andere tabel vereisen (om historische wijzigingen voor elk item op te slaan). Om het simpel te houden, ging ik ervan uit dat alle items die we in voorraad hebben ook te koop zijn.

Het tweede belangrijke dat ik heb weggelaten, is het volgen van de magazijnstatus. Mijn veronderstelling is dat we alles vanuit één centraal magazijn verzenden en dat we altijd artikelen beschikbaar hebben. Als we een artikel niet hebben, zullen we de klant hiervan op de hoogte stellen en hem een soortgelijk artikel ter vervanging aanbieden.

Sectie 2:Klanten en werknemers

De Customers & employees onderwerpgebied bevat alle tabellen die nodig zijn om klant- en medewerkergegevens op te slaan. We gebruiken deze informatie in het centrale deel van ons model.

De employee tabel bevat een lijst van alle relevante medewerkers (bijvoorbeeld de inpakkers en de bezorgers). Voor elke medewerker slaan we hun first_name op en last_name en een UNIEKE employee_code waarde. Hoewel de id-kolom ook UNIEK is (en de primaire sleutel van deze tabel), is het beter om een andere, echte waarde (bijvoorbeeld een btw-nummer) als werknemer-ID te gebruiken. Zo hebben we de employee_code veld.

Merk op dat ik geen inloggegevens van werknemers, werknemersrollen en een manier om de rolgeschiedenis bij te houden, heb opgenomen. Deze kunnen eenvoudig worden toegevoegd, zoals beschreven in dit artikel.

Nu gaan we klanten aan ons model toevoegen. Hiervoor zijn nog twee tafels nodig.

Klanten worden geografisch gesegmenteerd, dus we hebben een city woordenboek. Voor elke stad waar we boodschappen laten bezorgen, bewaren we de city_name en de postal_code . Samen vormen deze de alternatieve sleutel van deze tabel.

Klanten zijn absoluut het belangrijkste onderdeel van dit model; zij zijn degenen die het hele proces initiëren. We slaan een volledige lijst van onze klanten op in de customer tafel. Voor elke klant slaan we het volgende op:

first_name – De voornaam van de klant.
last_name – De achternaam van de klant.
user_name – De gebruikersnaam die de klant heeft gekozen bij het instellen van zijn account.
password – Het wachtwoord dat de klant heeft gekozen bij het instellen van zijn account.
time_inserted – Het moment waarop dit record in de database is ingevoerd.
confirmation_code – Een code die is gegenereerd tijdens de registratiecode. Deze code wordt gebruikt om hun e-mailadres te verifiëren.
time_confirmed – Toen de e-mailbevestiging plaatsvond.
contact_email – Het e-mailadres van de klant, dat ook wordt gebruikt als bevestigingsmail.
contact_phone – Het telefoonnummer van de klant.
city_id – De ID van de city waar de klant woont.
address – Het huisadres van de klant.
delivery_city_id – De ID van de city waar de bestelling van de klant moet worden afgeleverd.
delivery_address – Het gewenste afleveradres. Let op:dit kan (maar hoeft niet) hetzelfde te zijn als het thuisadres van de klant.

Sectie 3:Bestellingen

Het centrale en belangrijkste onderdeel van dit model zijn de Orders gebied. Hier vinden we alle tabellen die nodig zijn om een bestelling te plaatsen en artikelen te volgen totdat ze bij de klanten worden afgeleverd.

Het hele proces begint wanneer een klant een bestelling plaatst. Een lijst van elke bestelling die ooit is geplaatst, staat in de placed_order tafel. Ik heb met opzet deze naam gebruikt en niet "order" omdat order een gereserveerd SQL-sleutelwoord is. Voor elke bestelling slaan we op:

customer_id – De ID van de customer die deze bestelling heeft geplaatst.
time_placed – Het tijdstempel waarop deze bestelling is geplaatst.
details – Alle details met betrekking tot die bestelling, in ongestructureerd tekstueel formaat.
delivery_city_id – Een verwijzing naar de city waar deze bestelling moet worden afgeleverd.
delivery_address – Het adres waar deze bestelling moet worden afgeleverd.
grade_customer &grade_employee – Cijfers gegeven door de medewerker en klant nadat een bestelling is voltooid. Tot dat moment bevat dit attribuut een NULL-waarde. Het cijfer van een klant geeft aan hoe blij ze waren met onze service; Het cijfer van een medewerker geeft ons informatie over wat we kunnen verwachten de volgende keer dat een klant een bestelling plaatst.

Tijdens het plaatsen van een bestelling zal een klant een of meer artikelen selecteren. Voor elk item definiëren ze een gewenste hoeveelheid. Een lijst met alle items die betrekking hebben op elke bestelling wordt opgeslagen in de order_item tafel. Voor elke record in deze tabel slaan we ID's op voor de gerelateerde bestelling (placed_order_id ), item (item_id ), de gewenste hoeveelheid en de price wanneer deze bestelling is geplaatst.

Naast wat ze geleverd willen hebben, zullen klanten ook hun gewenste levering tijd bepalen . Voor elke bestelling maken we één record in de delivery tafel. Dit registreert de delivery_time_planned en voeg aanvullende tekstuele opmerkingen toe. De placed_order_id attribuut wordt ook gedefinieerd wanneer dit record wordt ingevoegd. De overige twee kenmerken worden gedefinieerd wanneer we die levering toewijzen aan een werknemer (employee_id ) en wanneer de bestelling is afgeleverd (delivery_time_actual ).

Hoewel het lijkt alsof we maar één levering per bestelling hebben, is dat niet altijd het geval. Het kan zijn dat we twee of meer leveringen per bestelling moeten doen, en dat is de belangrijkste reden waarom ik ervoor heb gekozen om de leveringsgegevens in een nieuwe tabel te plaatsen.

Wanneer wij een bestelling gaan verwerken, pakken medewerkers de artikelen in een of meerdere dozen in. Elke box wordt UNIEK gedefinieerd door zijn box_code en wordt toegewezen aan een levering (delivery_id ). We slaan ook de ID op van de medewerker die die box heeft klaargemaakt.

Elke doos zal een of meer items bevatten. Daarom, in de item_in_box tabel, moeten we verwijzingen naar het box tabel (box_id ) en het item tabel (item_id ), evenals de hoeveelheid die in die doos is geplaatst. Het laatste attribuut, is_replacement , geeft aan of een artikel een vervanging is voor een ander artikel. We kunnen verwachten dat een medewerker contact opneemt met een klant voordat hij een vervangend artikel in een doos stopt. Een uitkomst van die actie zou kunnen zijn dat een klant akkoord gaat met het vervangende artikel; een ander kan het annuleren van de hele bestelling zijn.

De overige drie tabellen in het model hangen nauw samen met statussen en opmerkingen.

Eerst slaan we alle mogelijke statussen op in de status_catalog . Elke status wordt UNIEK gedefinieerd door zijn status_name . We kunnen statussen verwachten zoals "bestelling aangemaakt", "bestelling geplaatst", "items verpakt", "in transit" en "afgeleverd".

Statussen worden automatisch aan bestellingen toegewezen (nadat sommige delen van het proces zijn voltooid) of, in sommige gevallen, handmatig (bijvoorbeeld als er een probleem is met de bestelling). Alle beschikbare bestelstatussen worden opgeslagen in de order_status tafel. Naast externe sleutels uit twee tabellen (status_catalog en placed_order ), slaan we de werkelijke tijdstempel op toen deze status werd toegewezen (status_time ) en eventuele aanvullende details in tekstvorm.

De finaletafel in dit model zijn de notes tafel. Het idee achter deze tabel is om alle aanvullende opmerkingen met betrekking tot een bepaalde bestelling in te voegen (placed_order_id ). Opmerkingen kunnen worden ingevoegd door medewerkers of klanten. Voor elke record, slechts één van de employee_id of customer_id velden zullen een waarde bevatten; de andere zal NULL zijn. We slaan het moment op waarop deze notitie in het systeem werd ingevoegd (note_time ) en de note_text .

Welke wijzigingen zou u aanbrengen in het gegevensmodel voor de bezorging van boodschappen?

Vandaag bespraken we een datamodel dat web- en mobiele bezorgapps voor boodschappen zou kunnen ondersteunen, zowel vanuit het perspectief van de klant als vanuit het perspectief van de werknemer. Zoals al vermeld in dit artikel, zijn er veel manieren om dit model te verbeteren. Voel je vrij om je suggesties toe te voegen. Vertel ons wat u aan dit model zou toevoegen of eruit zou verwijderen. Of misschien zou je deze structuur heel anders inrichten. Laat het ons weten in de comments!