Laten we verdere wijzigingen aanbrengen in het gegevensmodel, dat ik in mijn eerdere blogpost heb gemaakt, zoals een geautomatiseerde benadering voor het toewijzen van een instructeur en voertuig aan een les, facturering aan klanten en het volgen van hen.
Ten eerste moet ik logica bouwen aan de applicatiekant om een instructeur en voertuig toe te wijzen aan lessen voordat ze daadwerkelijk plaatsvinden. Het belangrijkste om hier voor te zorgen is beschikbaarheid, d.w.z. een instructeur of voertuig kan alleen aan een les worden toegewezen als beide beschikbaar zijn op de geplande tijd van de les.
Ik moet twee afzonderlijke tabellen maken om de bezetting voor respectievelijk instructeurs en voertuig bij te houden. Je vraagt je misschien af waarom ik van plan ben de bezetting bij te houden in plaats van de beschikbaarheid. Het antwoord is dat als we de bezetting in plaats van de beschikbaarheid bijhouden, we geen tabellen meer hoeven te maken om de onbeschikbaarheid van middelen op te slaan als gevolg van door instructeurs gepland verlof of een geplande service voor voertuigen. In het geval van geplande onbeschikbaarheid, worden de records dienovereenkomstig in de bezettingstabellen ingevoegd.
Ik ga er hier van uit dat instructeurs en voertuigen alleen beschikbaar zijn tijdens kantooruren, bijvoorbeeld van 8:00 tot 18:00 uur, op werkdagen die door de school worden bepaald. Daarom kan ik zeggen dat een instructeur op een bepaalde tijd op een werkdag beschikbaar is als ik de bezettingsdetails voor de opgegeven tijd en dag niet kan vinden in de staff_occupancy tafel.
De structuur voor tabel staff_occupancy is als volgt:
Sommige variaties kunnen naar behoefte worden aangebracht. Zo moet er voor een instructeur bijvoorbeeld minimaal 15 minuten tussen twee opeenvolgende lessen zitten.
De structuur voor tabel vehicle_occupancy is als volgt:
Toewijzing van instructeur en voertuig worden vastgelegd in de reservation tafel. Ik had al twee kolommen toegevoegd, staff_id en vehicle_id , in deze tabel. Deze toewijzingen zullen uiteraard gebeuren op basis van hun beschikbaarheid.
Daarnaast bewaar ik reservation_id in de staff_occupancy en vehicle_occupancy tabellen, zodat bij annulering van een les de betreffende bezetting van personeel en voertuig eenvoudig kan worden vrijgegeven. Maar ik bewaar beide kolommen als nullable aangezien de bezetting van instructeurs en voertuigen niet noodzakelijkerwijs te wijten is aan reserveringen. Wat als een instructeur met verlof gaat? Of gaat een van de voertuigen een dag naar het servicecentrum?
Om zacht verwijderen in dergelijke scenario's mogelijk te maken, zal ik een kolom toevoegen met de naam is_active in beide tabellen.
Facturering
Voor de factureringsvereiste zal ik één tabel maken, namelijk invoice , om factuurgegevens vast te houden, waaronder customer_id en reservation_id . Hier wordt gefactureerd aan klanten, maar op basis van de lessen die voor de klant zijn uitgevoerd. We hebben dus de reservation_id . nodig kolom in de factuurtabel, zodat men op elk moment een rapport over gedetailleerde facturering kan opvragen op basis van een reservering voor een klant. Ik zal ook één kolom maken, namelijk invoice_status_id , in de tabel om de status van facturen op te slaan.
Databasemodel
Hier is de bijgewerkte databasestructuur ontworpen in Vertabelo:
Conclusie
U moet inmiddels zijn gaan geloven dat datamodellering voor een reserveringssysteem van een rijschool net zo interessant en charmant is als leren autorijden?
Voel je vrij om je vragen en suggesties over het artikel te posten. Ik beantwoord ze graag en neem uw suggesties op in mijn volgende artikel.