Een gegevensmodel voor carpoolen maken

Tegenwoordig wordt carpoolen geaccepteerd en gepromoot door mensen over de hele wereld. Het verkleint zeker iemands persoonlijke ecologische voetafdruk en het kan kosteneffectiever zijn dan het huren of kopen van een auto.

Carpoolen kost ook veel werk - organisatorisch werk dat gemakkelijk kan worden gedaan door een goed ontworpen database. In dit artikel wordt een gedetailleerd datamodel uitgelegd dat een carpoolwebsite zou kunnen gebruiken.

Datadesign, maak kennis met carpoolen

We moeten dus een gegevensmodel ontwerpen voor een website voor het delen van ritten (ook wel carpoolen genoemd).

Carpoolen is iets anders dan een auto huren. Bij carpoolen is de auto eigendom van één persoon en bieden ze ritten aan aan anderen. Eventuele medereizigers betalen voor de ritkosten, inclusief brandstof, tolgelden, enz.

Projectvereisten:

De website moet de gebruikers . toestaan (ook bekend als ride-share-leden) om zichzelf te registreren met hun naam, telefoonnummer, e-mailadres, rijbewijsnummer, enz.
Leden moeten hun voorkeuren kunnen instellen met betrekking tot ritten en medereizigers.
Leden die riteigenaren worden genoemd, kunnen een rit maken door hun reisgegevens in te voeren (d.w.z. start- en bestemmingspunten, starttijd, kosten per rijder, enz.)
Andere leden kunnen zoeken naar beschikbare ritten naar een bestemming stad .
Leden die op zoek zijn naar een rit kunnen contact opnemen met de eigenaar van de rit en een reservering plaatsen voor hun stoelen.
De eigenaar van de rit moet reserveringsverzoeken kunnen goedkeuren of afwijzen.
Op basis van de actie die de eigenaar van de rit heeft ondernomen op het reserveringsverzoek, moet het aantal beschikbare stoelen worden bijgewerkt.
De eigenaar van de rit kan ook en-route steden markeren, dit zijn steden op weg van hun startpunt naar hun bestemming. Als ze dat willen, moeten de eigenaren van de rit ook mensen kunnen huisvesten voor steden onderweg.

Laten we met deze parameters in gedachten de belangrijkste entiteiten en relaties voor ons carpoolgegevensmodel identificeren.

Entiteiten en relaties identificeren

Als ik de vereisten als geheel zie, kan ik gemakkelijk de belangrijkste entiteiten achterhalen. Dit zijn:

leden (inclusief rijderseigenaren en medereizigers )
auto
voorkeuren
rijden
stad
ritverzoek

Lid – Iedereen die deze website bezoekt, moet zich registreren voordat hij deze kan gebruiken. In dit proces moeten ze details verstrekken zoals first_name , last_name , gender , email , en contact number . Voor medereizigers zijn deze items voldoende. Eigenaars van een rit, die vermoedelijk zullen rijden, moeten enkele aanvullende gegevens invullen, zoals driving_license_number en driving_license_valid_from moet ook worden opgenomen. De licentie-informatie vertelt medereizigers iets over de rijervaring van de riteigenaar. Dit zal de medereizigers helpen om de best beschikbare rit te selecteren. Ik voeg een tafel toe met de naam member met alle vereiste kolommen.

Auto – De eigenaar van de rit moet details voor ten minste één auto toevoegen voordat hij een rit maakt. Laten we dus een andere tabel maken, genaamd car , om deze informatie op te slaan. Eén lid kan meer dan één auto bezitten. Een rit kan afhankelijk zijn van een lid-autopaar, dus we hebben een andere tabel nodig om deze relatie vast te stellen. We noemen deze tabel member_car . Ik zal de primaire sleutel van deze tabel verwijzen in mijn ride tabel waar ik ritgegevens zal opslaan. Ik zal ook één kolom toevoegen, namelijk comfort_level , dat het comfortniveau van een auto opslaat op een schaal van 0 tot 5. Dit niveau wordt automatisch berekend door het systeem, op basis van de andere door leden verstrekte details over de auto.

Voorkeuren – Voorkeuren zijn voor iedereen belangrijk. Op de website kunnen leden hun voorkeuren over de auto en hun medereizigers invullen. Deze gegevens blijven optioneel op het moment van registratie, maar moeten worden ingevuld voordat een rit wordt gemaakt . De eigenaar van de rit zal waarschijnlijk op zoek gaan naar mensen met vergelijkbare voorkeuren, zodat iedereen comfortabel reist. Mensen die op zoek zijn naar ritten doen hetzelfde.

Enkele basisvoorkeuren voor autoreizen zijn:

Is roken toegestaan in de auto?
Mogen huisdieren mee?
Hoe spraakzaam is de eigenaar van de rit? Welk niveau van chatter is acceptabel tijdens de rit? (Mogelijke reacties hier zijn geen, licht geklets, gabfest.)
Van wat voor soort muziek houdt de eigenaar van de rit?
Welk muziekvolume staat de eigenaar van de rit toe?

Aangezien deze details optioneel zijn tijdens de registratie, zal ik een andere tabel maken met de naam member_preference om deze gegevens op te slaan. Twee extra tabellen bevatten mogelijke opties voor muziek (music_preference ) en gesprek in de auto (chitchat_preference ).

Laten we een nul-op-één relatie hebben tussen het member en member_preference tabellen, aangezien leden hun voorkeuren al dan niet in het systeem kunnen instellen wanneer ze zich aanmelden, en er is slechts één record voor voorkeuren per lid.

Stad – Eén hoofdtabel, city , is nodig om een lijst op te slaan van alle steden die door de website worden bediend. Het moet de relevante staats- en landinformatie voor elke stad bevatten.

Rijden – Een lid kan een rit aanmaken door te vullen met welke auto hij reist; vanuit welke stad hij vertrekt; naar welke stad hij op weg is; de datum en tijd van de reis; het aantal beschikbare stoelen; en bijdrage per hoofd. De bijdrage per hoofd is het bedrag dat elke medereiziger moet betalen voor de ritkosten. Ook kan de riteigenaar aangeven hoeveel bagage hij van medereizigers verwacht, zodat alles in de auto past. Dus voegen we één kolom toe, luggage_size_allowed , voor dit artikel. Mogelijke waarden voor deze kolom zijn licht, gemiddeld en zwaar.

Ritverzoek – Leden kunnen de lijst met beschikbare ritten van de ene stad naar de andere bekijken of een aanvraag indienen voor een specifieke reis. We hebben absoluut één tabel nodig om details over dergelijke verzoeken op te slaan. Een tabel met de naam request past bij het doel. Het verzoek wordt in eerste instantie ingevoerd als een 'ingediend' verzoek en de eigenaar van de rit is de enige persoon die het mag goedkeuren of afwijzen. Het aantal beschikbare stoelen in de rittabel wordt bij elke goedkeuring en/of afwijzing aangepast.

En-route-steden – Bij het delen van ritten gaat het niet alleen om rechtstreeks van startpunt naar bestemming gaan. Men kan ook een rit delen met anderen voor en-route steden. Als een man bijvoorbeeld van Chicago naar Miami reist, kan hij iemand accommoderen die van Chicago naar Nashville wil gaan. Nashville is een van de steden die hij op zijn route zal passeren, dus het is een stad onderweg. Ons systeem zou eigenaren van ritten in staat moeten stellen om en-route steden in te stellen op basis van de route die ze gaan volgen om hun bestemming te bereiken. Als medereizigers dat willen, kunnen ze uitstappen bij een van de en-route steden; hun reiskosten worden dienovereenkomstig pro rata berekend.

We maken een andere tabel met de naam enroute_city Voor dit doeleinde. Records worden toegevoegd wanneer de eigenaar van de rit en-route steden aan zijn rit toevoegt. Leden kunnen dan reserveringen aanvragen om naar een van de en-route steden te reizen. Daarom verwijs ik de primaire sleutel van deze tabel naar het request tafel.

De order_from_source kolom in enroute_city tabel geeft de koers aan die de eigenaar van de rit gaat volgen voor de reis.

Rapporten op de website:

Op deze website kunnen verschillende rapportages (data-extracten) getoond worden. Ik zal er een paar uitleggen:

Ritten beschikbaar van de ene specifieke stad naar de andere – Dit is een van de rapporten die vrij vaak zullen worden geëxtraheerd, omdat het de essentie van deze website weergeeft. De meeste leden zullen deze website bezoeken om te zoeken naar reisalternatieven of gedeelde ritten. Bij het uitpakken van dit rapport moeten leden hun start- en bestemmingsplaatsnaam invoeren. De SQL volgt:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, seats_offered 
from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = u.id 
and mc.car_id = c.id and m.id = mp.member_id
and source_city_id = (select city_id from city where city_name = ‘CHICAGO’)
and destination_city_id = (select city_id from city where city_name = ‘MIAMI’)
and seats_offered > (select count(id) from request req, request_status reqs where req.request_status_id = reqs.id and upper(reqs.description) = ‘APPROVE’ and req.ride_id = r.id);

Lijst met ingediende/goedgekeurde verzoeken voor een rit – Dit rapport wordt getoond aan de eigenaar van de rit. Het laat zien wie het ritverzoek heeft ingediend en de eigenaar kan alleen actie ondernemen op verzoeken vanuit dit rapport. De SQL hiervoor volgt:

select first_name || ‘ ‘ || last_name as “Submitter”,  req.created_on as “Submitted on”, rs.description as “Request Status” 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and req.ride_id = ;

Vorige en huidige ritten aangeboden – Deze rapporten worden op hun eigen dashboards aan rijders getoond. De volgende SQL kan worden gebruikt om een lijst met ritten te genereren die de eigenaar van de rit momenteel aanbiedt:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time >= sysdate
and m.id = ;

En deze SQL kan worden gebruikt om een lijst met eerder aangeboden ritten te extraheren:

Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
where r.member_car_id = mc.id and mc.member_id = m.id 
and mc.car_id = c.id and u.id = mp.member_id
and r.travel_start_time < sysdate
and m.id = ;

Lijst met medereizigers voor een rit – Dit rapport is beschikbaar voor alle medereizigers, inclusief de eigenaar van de rit. Ze kunnen allemaal een lijst met alle medereizigers genereren voor hun eerdere of toekomstige ritten.

select first_name || ‘ ‘ || last_name 
from member m, request req, request_status rs
where m.id = req.requester_id and rs.id = req.request_status_id
and rs.description = ‘APPROVED’
and req.ride_id = 
UNION
select first_name || ‘ ‘ || last_name 
from member m, member_car mc, ride r
where m.id = mc.member_id and mc.id = r.member_car_id 
and r.id = ;

Het definitieve gegevensmodel

Hoe zit het met verbeteringen?

Kunnen we dit model verder verbeteren? Ja dat kunnen we! Er zijn nog enkele gebieden die moeten worden aangepakt.

Wat als men terugkerende ritaanvragen wil aanmaken? Stel dat een chauffeur elk weekend van de ene stad naar de andere reist, en hij is altijd bereid deze rit te delen. Een terugkerend verzoek zou handiger zijn.

Hoe kan iemand vertrouwen op een onbekende man die een lift aanbiedt? Er moet een manier zijn om mensen te helpen anderen te evalueren voordat ze een rit aanvragen. Een haalbaar mechanisme is het publiceren en delen van feedback over riteigenaren en medereizigers. Deze details zullen anderen zeker helpen om met meer vertrouwen een rit met vreemden te boeken. Welke wijzigingen zijn hiervoor nodig in ons datamodel?

Voel je vrij om je input over dit model te delen.