Een gegevensmodel voor restaurantbezorging

Honger maar geen zin om te koken? Roep een restaurant op, bestel je favoriete maaltijd en lees over een datamodel dat het hele proces kan organiseren.

Ondanks een overvloed aan "tijdbesparende" technologie, lijken we minder tijd te hebben om aan basisbehoeften te voldoen, zoals eten. Als we iets willen eten, maar we hebben niet de tijd (of de vaardigheden) om het zelf te koken, kunnen we eten bestellen bij een restaurant (dat wil zeggen een afhaalmaaltijden of afhaalmaaltijden), dat onze maaltijden rechtstreeks naar onze deur brengt. Natuurlijk moeten we betalen voor dit gemak, dus we verwachten dat het eten goed en warm is!

Uiteraard is elk restaurant gemotiveerd om zijn klanten tevreden te houden. Je zult er misschien versteld van staan hoeveel werk er in het runnen van een afhaalmaaltijd zit. De meeste gebruiken een soort volgsysteem om bestellingen en leveringen te beheren. Laten we eens kijken naar het datamodel onder een dergelijk systeem. Pak een snack, leun achterover en geniet van het artikel.

Wat moeten we weten over de horeca?

Eten maken en afleveren bij klanten is niet eenvoudig. Allereerst moet je talent en kennis hebben om heerlijke maaltijden te bereiden. Je moet ook georganiseerd zijn:alles moet perfect functioneren als deze maaltijden op tijd en op de juiste plek worden bezorgd!

Voordat we maaltijden gaan bezorgen, moeten we het volgende weten:

Wie heeft de maaltijd besteld
Waar en wanneer de maaltijd bezorgd moet worden
Welke gerechten zijn inbegrepen in de bestelling
Welke ingrediënten we nodig hebben om de bestelling uit te voeren
Als de bestelling al is betaald

We moeten ook de bezorgstatussen volgen en feedback van klanten over hun maaltijd en/of ons bezorgproces vastleggen. Bovendien willen we misschien weten welke maaltijden het meest (of het minst) populair zijn. En we moeten ook wat financiële informatie bewaren voor rapportage- en analysedoeleinden.

Laten we aannemen dat we een app hebben waarmee onze klanten bestellingen kunnen plaatsen voor bezorging. Hiermee kunnen ze menu-items kiezen, ervoor betalen en een bezorgtijd en adres opgeven. Hoe zou het datamodel onder zo'n app eruit kunnen zien?

Het gegevensmodel

U kunt dit model in uw browser openen door op Edit model in your browser te klikken knop.

Het datamodel bestaat uit drie vakgebieden:

Restaurants & customers
Menus
Orders

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

Restaurants en klanten

De Restaurants & customers onderwerpgebied bevat drie tabellen met details over onze restaurants (er kunnen er meerdere zijn), de steden waar we actief zijn en onze klanten.

Zowel klanten als restaurants bevinden zich in steden (of steden, dorpen, enz.). Daarom hebben we een city woordenboek. Het bevat slechts twee attributen, city_name en zip_code . Als we in meer dan één land actief zijn, hebben we ook een landwoordenboek nodig dat gerelateerd is aan deze tabel, maar daar gaan we hier niet op in.

Vervolgens hebben we een lijst nodig van alle restaurants die we exploiteren. We gebruiken het restaurant tafel daarvoor. Om het simpel te houden, slaan we alleen het address van elk restaurant op en een verwijzing naar de city waar het zich bevindt.

De laatste tabel in dit onderwerpgebied is de customer tafel. Hier slaan we een lijst op van al onze geregistreerde bezorgklanten. We gebruiken gegevens uit deze tabel om klanten later in het model aan hun bestellingen te koppelen. Uiteraard hoeven klanten niet in ons model geregistreerd te zijn om een bestelling te plaatsen, maar deze lijst hebben we wel nodig. We zouden als loyaliteitsprogramma kortingen kunnen aanbieden aan geregistreerde klanten. Of misschien zouden we deze gegevens gebruiken om contact op te nemen met klanten met speciale aanbiedingen. Voor elke geregistreerde klant slaan we op:

customer_name – De volledige naam van de klant.
city_id – Verwijst naar de city waar de klant woont.
address – Het adres van de klant.
contact_phone – Het telefoonnummer van de klant.
email – Het e-mailadres dat de klant heeft gebruikt tijdens het registratieproces.
confirmation_code – Een bevestigingscode die wordt gebruikt tijdens het registratieproces.
password – Het door de klant gekozen wachtwoord voor deze app.
time_joined – Een tijdstempel van wanneer de klant zich bij onze applicatie heeft aangesloten.

Menu's

Dit onderwerp bevat informatie over de menukaarten van onze restaurants. Laten we er voorlopig vanuit gaan dat al onze restaurants hetzelfde menu gebruiken.

De eerste tabel is de category woordenboek. Het bevat slechts één UNIEK kenmerk, category_name . Dit veld zal waarschijnlijk de gebruikelijke menucategorieën bevatten, zoals "drankjes", "voorgerechten", "salades", "broodjes", "pizza", enz.

Vervolgens hebben we de menu_item tafel. Het geeft een overzicht van alle items die we op een van onze menu's hebben (of hadden). Voor elk item slaan we op:

item_name – Een naam voor dat item, bijv. "broodje kip".
category_id – Verwijst naar de category waartoe het item behoort, b.v. "broodjes".
description – Een beschrijving van dat item. Dit zou hetzelfde moeten zijn als op het afgedrukte menu.
ingredients – De ingrediënten die zijn gebruikt om dat artikel te produceren en hun hoeveelheden. In dit veld kan een recept worden opgeslagen.
price – De huidige prijs voor één artikel (bijvoorbeeld één broodje kip).
active – Als het item wordt aangeboden in het huidige menu.

Als we menu's in meerdere talen willen opslaan, moeten we een benadering gebruiken zoals die in dit artikel wordt gepresenteerd.

De meeste restaurants hebben speciale, tijdelijke aanbiedingen. Ze kunnen ook aanbiedingen hebben voor een onbeperkte tijd. We gebruiken de offer tafel voor deze. Voor elk hebben we:

date_active_from en date_active_to – Samen bepalen deze wanneer dit aanbod actief is. Als een aanbieding een onbeperkte duur heeft of is gebaseerd op uren in plaats van dagen, bevatten deze twee kenmerken NULL-waarden. Een voorbeeld van dit soort aanbiedingen is "Koop in de maand maart één curry en krijg er een met 50% korting".
time_active_from en time_active_to – Definieert het tijdstip van de dag waarop een aanbieding geldig is – b.v. "Krijg elke dag een gratis kopje koffie van 6-9 uur".
offer_price – De prijs voor die aanbieding.

Alle menu-items in aanbiedingen worden opgeslagen in de in_offer tafel. Deze tabel bevat het UNIEKE paar offer_id – menu_item_id .

Als onze restaurants verschillende menu's hebben, moeten we voor elk restaurant een apart menu maken. We zouden dan menu's en aanbiedingen moeten relateren aan restaurants met behulp van buitenlandse sleutels. Dit zou ons in staat stellen om menu's en aanbiedingen voor elk restaurant te wijzigen zonder de anderen te beïnvloeden. Dit zou niet alleen de database compliceren; het bedrijfsmodel zou ook complexer worden. Dit is de reden waarom de meeste restaurantketens bij slechts één menu blijven en waarom ik heb besloten deze methode in dit model niet te gebruiken.

Bestellingen

Het laatste onderwerpgebied in ons model is de Orders gebied. Hier hebben we alles wat nodig is om bestellingen en hun status op te slaan.

De centrale tabel hier is de placed_order tafel. Het is het beste om niet alleen "order" te gebruiken als de naam van deze tabel:"order" is een SQL-sleutelwoord. Probeer het gebruik van trefwoorden als namen voor tabellen en kolommen te vermijden; anders kunt u fouten krijgen bij het schrijven van query's. Voor elke bestelling registreren we:

restaurant_id – De ID van het restaurant gerelateerd aan die bestelling.
order_time – Een tijdstempel van wanneer de bestelling is geplaatst.
estimated_delivery_time – Een tijdstempel van de geplande levering van deze bestelling.
food_ready – Een tijdstempel dat aangeeft wanneer de bestelitems zijn voorbereid. Dit bevat een NULL-waarde totdat het voedsel is bereid. We zouden dit attribuut kunnen gebruiken om het tijdsverschil te berekenen tussen het moment dat de bestelling werd geplaatst en het moment waarop het eten werd bereid. We konden het ook gebruiken om te zien hoeveel tijd er was verstreken tussen het moment waarop het eten klaar was en het moment waarop het werd bezorgd. Deze informatie kan zeer nuttig zijn om de efficiëntie van het personeel te verhogen.
actual_delivery_time – Een tijdstempel van wanneer deze bestelling daadwerkelijk is afgeleverd. Het is NULL totdat het eten bij de klant is afgeleverd.
delivery_address – Het adres waar de bestelling bezorgd moet worden.
customer_id – De ID van de customer die die bestelling heeft geplaatst. Dit kenmerk kan een NULL-waarde bevatten als de bestelling is geplaatst door iemand die geen geregistreerde app-gebruiker is.
price – De prijs voor alle artikelen in die bestelling.
discount – Het eventuele kortingsbedrag (bijv. coupon of loyaliteitskorting) dat op de prijs wordt toegepast.
final_price – De bestelprijs minus de korting.
comment – Aanvullende opmerkingen die door de klant zijn ingevoegd bij het plaatsen van de bestelling. Dit kunnen aanvullende leveringsinstructies zijn of iets anders dat de klant belangrijk vindt.
ts – Een tijdstempel van wanneer dit record in de tabel is ingevoegd.

De in_order tabel bevat alle artikelen of speciale aanbiedingen die bij een bestelling zijn inbegrepen. Voor elk record in deze tabel slaan we op:

placed_order_id – De ID van de gerelateerde order .
offer_id – Verwijst naar de offer tafel, maar alleen wanneer een of meer aanbiedingen in deze bestelling zijn opgenomen. In dat geval is de menu_item_id attribuut zal NULL zijn.
menu_item_id – Verwijst naar de menu_item tabel, maar alleen als dit record betrekking heeft op een menu-item en niet op een aanbieding.
quantity – Hoeveel aanbiedingen of menu-items zijn inbegrepen in deze bestelling.
item_price – De prijs van een enkele aanbieding of menu-item.
price – De totale prijs voor deze regel, uitgedrukt als item_price * quantity .
comment – Eventuele opmerkingen van de klant die specifiek betrekking hebben op dat bestelitem, b.v. "Snijd pizza alsjeblieft in 8 plakjes".

De comment tabel laat ons de invoeging van meerdere opmerkingen met betrekking tot bestellingen ondersteunen. Voor elke opmerking slaan we de ID van de gerelateerde bestelling en de ID van de klant op. We slaan ook een tijdstempel op van wanneer deze opmerking is ingevoerd. We markeren ook of deze opmerking een klacht of een compliment was; slechts één van deze twee kan tegelijk worden ingesteld. Als er geen zijn ingesteld, behandelen we deze opmerking als neutraal.

De laatste twee tabellen in ons model hebben betrekking op statussen die we aan bestellingen toewijzen. De status_catalog tabel bevat een lijst van alle mogelijke UNIEKE status_name attributen die we aan orders konden toewijzen. De order_status tabel bevat alle statussen die zijn toegewezen aan bestellingen. Voor elk record in deze tabel slaan we externe sleutels op met betrekking tot bestelling en status en het tijdstempel waarop deze status is toegewezen.

Wat vindt u van het gegevensmodel voor bezorging van restaurants?

Vandaag hebben we een datamodel besproken dat kan worden gebruikt voor het organiseren, beheren en opslaan van bezorgbestellingen in restaurants. We kunnen de status van elke bestelling en enkele financiële details volgen. Ik heb een paar ideeën over hoe we dit model robuuster kunnen maken, maar ik zou graag uw mening horen. Deel het alsjeblieft in het opmerkingengedeelte!