Databasemodel voor het reserveringssysteem van een rijschool. Deel 1

Ik moet een datamodel ontwerpen voor een reserveringssysteem voor een rijschool. Het onderwerp ziet er vrij eenvoudig uit, maar er zijn nog steeds complexiteiten. Je moet alle verzoeken van klanten bijhouden en de middelen (voertuig, tijd en instructeur) bijhouden die tijdens lessen worden verbruikt.

Inleiding

Ik gebruik graag een domeingedreven aanpak voor het ontwerpen van een datamodel. Het zorgt ervoor dat ik de obsessie voor technologie opzij zet en me voornamelijk concentreer op het modelleren van het vakgebied dat draait om de bijbehorende entiteiten en onderlinge relaties.

Vereisten in een notendop

Laat ik eerst de vereiste eerst in gewoon Engels opschrijven.

Ik heb een datamodel nodig voor een rijschool om klanten . toe te staan om reserveringen te maken voor lessen online. De rijschool heeft mogelijk meer dan één instructeur en meer dan één voertuig . De instructeur wordt bij reservering aan de les toegewezen. Het systeem moet klanten in staat stellen reserveringen op elk moment vóór de geplande dag te annuleren. Het voertuig dat aan de les is toegewezen, moet ook worden opgenomen als de les plaatsvindt.

Betrokken entiteiten en relaties

Als ik aan het onderwerp denk, zijn de entiteiten die het eerst in me opkomen, “Klant” , “Instructeur” , "Rijles" , “Reserveringsverzoek” en 'Voertuig' . Laat ik beginnen met mijn allereerste tafel voor dit model, en dat is customer . Het is om stamgegevens voor klanten op te slaan. Ik zou waarschijnlijk een andere tabel nodig hebben om de details van de instructeur op te slaan, maar in plaats van een tabel te maken met de naam van de instructeur, zal ik een algemene tabel maken met de naam staff voor personeelsgegevens en houd "Instructeur" als functietitel. Het zal mijn datamodel uitbreidbaar maken om ook andere servicegebieden, zoals administratief en juridisch werk, van een rijschool te bedienen.

Ik beschouw “rijcursus” als een van de services, dus maak ik een andere tabel met de naam service . Een service, “rijcursus” kan in dit geval meerdere lessen hebben. Om aan deze vereiste te voldoen, heb ik zeker een andere hoofdtabel nodig, namelijk lesson , en één relatietabel, namelijk service_lesson , om veel-op-veel-relaties tussen beide hoofdentiteiten te beheren, d.w.z. één service kan zeker meerdere lessen hebben, maar aan de andere kant kan één les ook deel uitmaken van meer dan één service.

Wanneer iemand een reserveringsaanvraag indient, wordt hem/haar gevraagd om zijn/haar gegevens en voorlopige voorkeuren in te vullen, zoals welk type service hij/zij wil, keuze voor voertuig en startdatum. De klantgegevens worden opgeslagen in de klantentabel. Vervolgens wordt één verzoek aangemaakt in het request tabel, en alle voorkeuren worden tegen het verzoek opgeslagen in dezelfde tabel. Er zijn bepaalde statussen verbonden aan elk verzoek, zoals "verzenden", "in behandeling", "annuleren" en "voltooid". Ik zal er een ondersteunende tabel voor maken met de naam request_status .

Bij het indienen van de aanvraag geeft men een voorkeur voor voertuig, d.w.z. type voertuig. Het voertuig zou echter daadwerkelijk aan een les worden toegewezen wanneer deze plaatsvindt. Daarom bewaar ik vehicle_type_id als een van de kolommen in request tafel voor nu.

Wanneer een aanvraag in behandeling is genomen, worden er reserveringen gemaakt voor elke les van de serviceaanvraag. Bovendien worden instructeurs en voertuigen aan elke les toegewezen op basis van de beschikbaarheid van instructeurs en de voorkeuren van klanten voor voertuigen. Lessen zijn gepland voor toekomstige data met status "Open". Al deze details worden vastgelegd in een andere transactietabel genaamd reservation . Ik heb alle transactietabellen gemarkeerd met een andere kleur dan alle hoofdtabellen.

Eén hoofdtabel, reservation_status , is gemaakt om alle mogelijke waarden op te slaan voor reserveringsstatussen zoals "open", "in behandeling", "annuleren" en "voltooid".

Met dit model kan een klant zowel een individuele les als het serviceverzoek als geheel annuleren. Als de klant het serviceverzoek annuleert, worden alle resterende lessen, die voor de klant zijn gepland, geannuleerd in de reserveringstabel.

Raadpleeg het gegevensmodel dat door mij is gemaakt met Vertabelo voor details op kolomniveau van al deze tabellen. Een paar punten met betrekking tot het maken van kolommen:

• Een vlagkolom met de naam is_active wordt toegevoegd aan alle hoofdtabellen om zachte verwijdering van records mogelijk te maken. Dus als een instructeur bijvoorbeeld de school verlaat, zetten we de vlag op "N" om zijn record inactief te maken.
• Bepaalde kolommen zoals created_date , created_by , last_modified_date en last_modified_by worden in alle transactietabellen toegevoegd om een ​​audittrail voor wijzigingen in records mogelijk te maken. Transactietabellen zijn blauw gemarkeerd in het gegevensmodel dat is gemaakt in Vertabelo.
• Je vraagt ​​je misschien af ​​wat de address_id kolom in de staff tafel is voor. Ik heb deze kolom met opzet in de staff tabel zodat ik mijn gegevensmodel kan uitbreiden om een ​​geautomatiseerd proces te ondersteunen om een ​​instructeur toe te wijzen aan een verzoek op basis van zijn of haar locatie. Stel bijvoorbeeld dat er in New York City een verzoek van White Plains binnenkomt. Mijn systeem moet eerst zoeken naar een beschikbare instructeur in dezelfde of dichtstbijzijnde omgeving. Mijn systeem mag nooit een instructeur toewijzen die in Manhattan verblijft, dat bijna 80 kilometer verwijderd is van de plaats van de aanvrager.

Opvallende kenmerken van dit model

• Met dit model kunnen klanten reserveringsverzoeken indienen volgens hun voorkeuren voor startdatum en voertuig.
• Hiermee kunnen ze een of meer lessen van hun cursus annuleren, of de hele cursus zelf.
• Dit model legt instructeur- en voertuigdetails vast voor elke les.
• Dit model is uitbreidbaar om alle mogelijke diensten van een rijschool aan te kunnen.
• Het stelt ons in staat om trainingscursussen te ontwerpen en lessen effectief te plannen.

Databasemodel

Hier is het database-ontwerp voor ons reserveringssysteem. Het model is gemaakt in Vertabelo voor de Oracle-database, maar hetzelfde ontwerp kan zonder noemenswaardige wijzigingen worden geïmplementeerd voor andere database-engines.

Conclusie

Er zijn bepaalde onderwerpen die we in dit artikel niet hebben behandeld, zoals:

• Kunnen we een geautomatiseerde aanpak ontwikkelen om voertuigen en instructeurs aan lessen toe te wijzen?
• Hoe zit het met het factureren van klanten? Wat als een klant niet voor de hele cursus wil betalen, maar voor een paar lessen? Kunnen we deze lessen voor hem beschikbaar stellen?

Ondersteunt ons bestaande model dergelijke functies? Het antwoord is nee. Ik zal deze onderwerpen waarschijnlijk in mijn volgende artikel behandelen.