Een gegevensmodel voor kinderfeestjes

Kinderfeestjes organiseren is geen sinecure:alles moet perfect gepland en opgeleverd worden. Anders ontstaat er chaos. Het is aan de volwassenen - meer specifiek de feestplanners - om voor alles te zorgen en het goed te doen.

Is er een betere manier om dit te doen dan alles in een database te organiseren? Wij denken van niet!

Kinderfeestjes variëren nogal. Sommige zijn eenvoudig, zoals verjaardagsfeestjes met alleen uitnodigingen, eten (snacks, drankjes en een cake) en misschien een clown of een goochelaar om de kinderen te vermaken. Andere partijen zijn veel complexer. Ze kunnen een reis buiten de stad, slaapplaatsen en vele andere activiteiten nodig hebben. Hoe ingewikkelder het feest, hoe minder ruimte voor fouten. Hoewel een clown die 10 minuten te laat is geen probleem is, wil niemand met een groep verveelde kinderen wachten op een bus die twee uur te laat is!

Laten we eens kijken wat een datamodel kan doen om feestplanners te helpen georganiseerd te blijven.

Wat hebben we nodig in ons gegevensmodel?

Laten we aannemen dat we een partijplanningsbedrijf runnen. We hebben een lijst met diensten die we aan klanten aanbieden. Deze diensten kunnen door ons worden geleverd, of we kunnen partners gebruiken (we huren bijvoorbeeld de clown in).

Wij combineren deze diensten en bieden deze als feestpakket aan klanten aan. Elk pakket heeft een start- en eindpunt, oftewel een planning. Dit omvat niet alleen het feest zelf, maar ook het opzetten van het feest en het opruimen daarna. We kunnen ook meerdere locaties hebben (een feest begint bijvoorbeeld met pizza in een restaurant en gaat dan naar het strand om te zwemmen).

We moeten ook activiteiten met medewerkers in verband brengen, de voortgang van partijen volgen en kosten in rekening brengen voor onze diensten. Laten we eens kijken hoe dit wordt gedaan.

Het gegevensmodel voor kinderfeestjes

Ons datamodel voor kinderfeestjes bestaat uit vier vakgebieden:

• Countries & cities
• Partners & services
• Employees & roles
• Party

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

Sectie 1:Landen en steden

Dit onderwerpgebied bevat slechts twee tabellen. Ze zijn niet specifiek voor dit model, maar we zullen ze in andere vakgebieden gebruiken.

We kunnen verwachten dat we in meerdere steden en misschien zelfs in meerdere landen actief zullen zijn. Daarom moeten we naar verschillende steden verwijzen. Dit helpt ons om te volgen waar partijen zich bevinden en ook welke diensten we op elke locatie aanbieden.

Het country woordenboek bevat alleen de UNIEKE country_name waarde. Voor elke city , slaan we de UNIEKE combinatie van postal_code op – city_name – country_id .

Sectie 2:Partners en services

Laten we vervolgens de services beschrijven die we aan onze klanten zullen leveren.

Een lijst van alle mogelijke services wordt opgeslagen in de service woordenboek. Het bevat alleen de UNIEKE service_name attribuut.

In dit datamodel worden alle diensten geleverd door partners. Zelfs als ons bedrijf de service daadwerkelijk levert, behandelen we het als een partner service (en wij zijn de partner). In het partnerwoordenboek worden alle partners opgeslagen waarmee we samenwerken, inclusief wijzelf. Voor elke partner slaan we een UNIEKE partner_name op . De details attribuut slaat alle aanvullende details met betrekking tot die partner op met behulp van een ongestructureerde of gestructureerde indeling (bijvoorbeeld met behulp van naam-waardeparen gescheiden door een vooraf gedefinieerd scheidingsteken).

De provides tabel is de laatste en belangrijkste tabel in deze sectie. Voor elk record slaan we op:

• partner_id – De partner die een dienst levert.
• service_id – De service deze partner biedt.
• city_id – Verwijst naar de city waar deze service wordt geleverd door die partner.
• date_from – De datum waarop de partner die service begon aan te bieden.
• date_to – De datum waarop de partner stopte met het aanbieden van die dienst. Deze waarde kan NULL zijn als die service-partnerrelatie nog steeds aan de gang is.
• details – Alle aanvullende details met betrekking tot die service, zoals servicebeschrijving, prijs, enz. We kunnen verwachten dat alle details in een gestructureerd tekstueel formaat zullen zijn, met behulp van sleutel-waardeparen.

De combinatie van partner_id – service_id – city_id – date_from vormt de UNIEKE sleutel in deze tabel. Wanneer we een nieuwe record invoeren, moeten we controleren of deze niet overlapt met bestaande records.

Sectie 3:Werknemers en rollen

Voordat we naar het centrale en belangrijkste deel van ons model gaan, moeten we kijken naar de tabellen met betrekking tot onze medewerkers en hun rollen.

De centrale tabel in dit onderwerpgebied is de employee tafel. Voor elke medewerker slaan we hun first_name op , last_name , user_name en password . Ze gebruiken deze laatste twee kenmerken om toegang te krijgen tot onze applicatie.

Een lijst met alle mogelijke rollen wordt opgeslagen in de role woordenboek. Elke rol wordt UNIEK gedefinieerd door zijn role_name . Rollen zijn gerelateerd aan acties die elke medewerker tijdens een feest uitvoert. Daarom kunnen we hier waarden als 'partymanager' of 'assistent' verwachten.

Rollen kunnen aan medewerkers worden toegewezen door middel van de has_role tafel. De employee_id – role_id paar geeft de actieve rollen aan die elke werknemer op dat moment heeft.

Sectie 4:Feest

De Party vakgebied staat centraal in dit model. We zullen het gebruiken om tabellen uit andere vakgebieden met elkaar in verband te brengen, en we zullen hier ook wat nieuwe informatie hebben.

De centrale tafel hier is het party tafel. Voor elk feest slaan we op:

• city_id – De city waar het feest zal plaatsvinden.
• client_id – De client dit feest wordt georganiseerd voor.
• details – Een gedetailleerde tekstuele beschrijving van het feest.
• start_time_planned en end_time_planned – De tijd die we voor dit feest hebben gepland, inclusief opbouw en opruimen.
• start_time_actual en end_time_actual – De werkelijke tijden waarop het feest (en de bijbehorende services) plaatsvond.
• price_offered – De prijs die we hebben opgegeven om dit feest voor deze klant te organiseren.
• time_offered – Toen het aanbod werd gedaan.
• price_paid – Het werkelijke bedrag dat de klant voor dit feest heeft betaald.
• time_paid – Wanneer de betaling is gedaan.

Elke partij is gerelateerd aan een klant. We hebben al verwezen naar de client tabel, maar nu zullen we zien wat daar is opgeslagen. Ik ging alleen met basisgegevens:client_name , contactgegevens (address , email , phone , mobile ), en eventuele aanvullende details in tekstformaat.

Elke partij heeft ook een lijst met bijbehorende services. Die lijst wordt opgeslagen in de service_included tafel. Voor elk record hebben we nodig:

• party_id – Verwijst naar de gerelateerde party .
• service_id – Verwijst naar de service inbegrepen in het feest.
• provides_id – Verwijst naar de provider van die dienst, evenals de dienst zelf. Dit kenmerk kan NULL zijn, omdat we het zullen bijwerken wanneer we de specifieke provider selecteren.
• details – Eventuele aanvullende tekstuele details met betrekking tot die service in die partij.
• start_time_planned en end_time_planned – De geplande tijden dat er tijdens het feest bediend moet worden.

We moeten ook de voortgang van elke partij volgen. We gebruiken hiervoor twee tabellen.

De status tabel toont alle mogelijke statussen die aan een partij kunnen worden toegewezen. Voor elk record slaan we een UNIEKE status_name op en drie vlaggen:

• successful – Is alles goed gegaan? Of waren er problemen met onze diensten?
• paid – Is het feest betaald?
• final – Is dit de definitieve status voor dit feest?

We wijzen statussen toe aan services door nieuwe records toe te voegen aan de party_status tafel. Voor elk record slaan we verwijzingen op naar de party en service tabellen en de timestamp wanneer deze status werd toegekend.

De laatste tafel in ons model is de invoice tafel. Het is niet specifiek voor dit model, maar we hebben wel een basisstructuur nodig om facturen op te slaan. Voor elke factuur registreren we:

• client_name – De naam van de klant op het moment dat de factuur werd opgemaakt.
• party_id – Het party gerelateerd aan deze factuur.
• client_id – De ID van de client wordt gefactureerd.
• invoice_amount , discount , vat_amount , total_amount – De financiële details van de factuur.
• time_issued - Wanneer deze factuur is uitgegeven of toegevoegd aan de database.
• time_paid - Wanneer deze factuur is betaald.

Wat zou u doen met dit gegevensmodel?

Dit model is vrij eenvoudig, maar ik zie verschillende manieren waarop we het kunnen verbeteren. Welke veranderingen zou u voorstellen? Kunnen we iets anders organiseren? Misschien moeten we een functie toevoegen of verwijderen. Vertel het ons in de comments.