Skapa en datamodell för samåkning

Nuförtiden accepteras och främjas samåkning av människor över hela världen. Det minskar verkligen ens personliga koldioxidavtryck, och det kan vara mer kostnadseffektivt än att hyra eller köpa en bil.

Samåkning kräver också mycket arbete – organisatoriskt arbete som enkelt kan utföras av en väl utformad databas. Den här artikeln förklarar en detaljerad datamodell som en samåkningswebbplats kan använda.

Datadesign, möt samåkning

Så vi måste designa en datamodell för en samåkningswebbplats (alias samåkning).

Samåkning är lite annorlunda än en biluthyrning. Vid samåkning ägs bilen av en person och de erbjuder skjuts till andra. Alla medresenärer betalar för resan, inklusive bränsle, vägtullar, etc.

Projektkrav:

Webbplatsen bör tillåta användarna (alias ride-share-medlemmar) för att registrera sig med sitt namn, telefonnummer, e-postadress, körkortsnummer, etc.
Medlemmar bör tillåtas ställa in sina inställningar angående åkattraktioner och medresenärer.
Medlemmar som kallas åkägare kan skapa en åkning genom att ange deras reseinformation (d.v.s. start- och destinationspunkter, starttid, kostnader per åkare, etc.)
Andra medlemmar kan söka efter tillgängliga resor till en destination stad .
Medlemmar som söker skjuts kan kontakta färdägaren och göra en bokning för sina platser.
Återresans ägare bör kunna godkänna eller avvisa bokningsförfrågningar.
Baserat på den åtgärd som färdägaren vidtog på bokningsförfrågan bör antalet tillgängliga platser uppdateras.
Rittägaren kan också markera en-route-städer, som är städer på väg från startpunkten till destinationen. Om de så önskar bör färdägarna också kunna ta emot människor för en-route-städer.

Med dessa parametrar i åtanke, låt oss identifiera huvudenheterna och relationerna för vår datamodell för samåkning.

Identifiera enheter och relationer

När jag ser kraven som en helhet kan jag enkelt lista ut huvudenheterna. De är:

medlemmar (inklusive ryttareägare och medresenärer )
bil
inställningar
åka
stad
åkningsförfrågan

Medlem – Alla som besöker den här webbplatsen måste registrera sig innan de kan använda den. I den här processen måste de tillhandahålla detaljer som first_name , last_name , gender , email och contact number . För medresenärer är dessa föremål tillräckliga. Åkägare, som förmodligen kommer att köra, måste fylla i ytterligare information som driving_license_number och driving_license_valid_from bör också ingå. Licensinformationen berättar för medresenärerna något om körupplevelsen hos färdägaren. Detta kommer att hjälpa medresenärerna att välja den bästa resan som finns. Jag lägger till en tabell med namnet member med alla obligatoriska kolumner.

Bil – Åkägaren måste lägga till detaljer för minst en bil innan färden skapas. Så låt oss skapa en annan tabell, kallad car , för att lagra denna information. En medlem kan äga mer än en bil. En tur kan bero på ett medlem-bil-par, så vi behöver ett annat bord för att upprätta denna relation. Vi kallar den här tabellen member_car . Jag kommer att referera till den här tabellens primärnyckel i min ride tabell där jag kommer att lagra åkinformation. Jag lägger också till en kolumn, nämligen comfort_level , som lagrar komfortnivån för en bil på en skala från 0 till 5. Denna nivå beräknas automatiskt av systemet, baserat på de andra uppgifterna om bilen som medlemmen tillhandahåller.

Inställningar – Preferenser är viktiga för alla. Webbplatsen låter medlemmarna fylla i sina preferenser om bilen och deras medresenärer. Dessa uppgifter förblir valfria vid registreringstillfället, men måste fyllas i innan du skapar en resa . Åkägaren kommer sannolikt att leta efter personer med liknande preferenser så att alla reser bekvämt. Människor som letar efter åkattraktioner gör detsamma.

Några grundläggande preferenser för bilresor är:

Är rökning tillåten inne i bilen?
Är husdjur tillåtna?
Hur pratsam är färdägaren? Vilken nivå av prat är acceptabelt under åkturen? (Möjliga svar här inkluderar inga, lätt snack, gabfest.)
Vilken typ av musik gillar åkägaren?
Vilken musikvolym tillåter åkägaren?

Eftersom dessa uppgifter är valfria under registreringen skapar jag en annan tabell med namnet member_preference för att lagra dessa uppgifter. Två ytterligare tabeller lagrar möjliga alternativ för musik (music_preference ) och konversation i bilen (chitchat_preference ).

Låt oss ha en noll-till-ett-relation mellan member och member_preference tabeller, eftersom medlemmar kan eller inte kan ställa in sina preferenser i systemet när de registrerar sig, och det finns bara en post för preferenser per medlem.

Stad – En huvudtabell, city , behövs för att lagra en lista över alla städer som betjänas av webbplatsen. Den bör innehålla relevant information om staten och landet för varje stad.

Rik – En medlem kan skapa en resa genom att fylla i vilken bil han reser med; vilken stad han utgår ifrån; vilken stad han är på väg mot; datum och tid för resan; antalet tillgängliga platser; och bidrag per capita. Bidraget per capita är det belopp som varje medresenär måste betala för resan. Åkägaren kan också nämna hur mycket bagage han förväntar sig av medresenärer för att allt ska få plats i bilen. Så vi lägger till en kolumn, luggage_size_allowed , för denna artikel. Möjliga värden för denna kolumn skulle vara lätt, medium och tung.

Rittbegäran – Medlemmar kan titta på listan över tillgängliga resor från en stad till en annan eller lägga in en begäran om en specifik resa. Vi behöver definitivt ett bord för att lagra information om sådana förfrågningar. En tabell som heter request passar syftet. Begäran läggs initialt in som en "inskickad" begäran, och färdägaren är den enda person som får godkänna eller avslå den. Antalet tillgängliga platser i åktabellen kommer att justeras för varje godkännande och/eller avslag.

Städer på väg – Samåkning handlar inte bara om att gå direkt från startpunkt till destination. Man kan dela en resa med andra för en-route städer också. Till exempel, om en man reser från Chicago till Miami, kan han ta emot någon som vill åka från Chicago till Nashville. Nashville är en av städerna han kommer att passera på sin rutt, så det är en en-route-stad. Vårt system bör tillåta färdägare att ställa in en-route-städer baserat på rutten de ska följa för att nå sin destination. Om medresenärer vill kan de gå av vid vilken som helst av resestäderna; deras resekostnader kommer att proportioneras i enlighet med detta.

Vi skapar en annan tabell som heter enroute_city för detta ändamål. Rekord kommer att läggas till när färdägaren lägger till en-route-städer till sin resa. Medlemmar kan sedan begära bokningar för att resa till en av en-route-städerna. Därför hänvisar jag den här tabellens primärnyckel till request tabell.

order_from_source kolumnen i enroute_city tabellen anger kursen som åkägaren kommer att följa för resan.

Rapporter på webbplatsen:

Det finns olika rapporter (dataextrakt) som kan visas på denna webbplats. Låt mig förklara några av dem:

Åkturer tillgängliga från en specifik stad till en annan – Det här är en av rapporterna som kommer att extraheras ganska ofta, eftersom den skildrar kärnan i den här webbplatsen. De flesta av medlemmarna kommer att gå in på den här webbplatsen för att leta efter resealternativ eller resedelar. När den här rapporten extraheras måste medlemmar ange sina start- och destinationsnamn. SQL:en följer:

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);

Lista över inlämnade/godkända förfrågningar om åktur – Denna rapport kommer att visas för färdägaren. Den kommer att visa vem som har skickat in åkbegäran, och ägaren kan endast vidta åtgärder på förfrågningar från denna rapport. SQL för detta följer:

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 = ;

Tidigare och nuvarande turer erbjuds – Dessa rapporter kommer att visas för åkägare på deras egna instrumentpaneler. Följande SQL kan användas för att generera en lista över åkturer som åkägaren erbjuder för närvarande:

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 = ;

Och denna SQL kan användas för att extrahera en lista över tidigare erbjudna åkturer:

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 = ;

Lista över medresenärer för en tur – Den här rapporten kommer att vara tillgänglig för alla medresenärer, inklusive färdägaren. Alla kan generera en lista över alla medresenärer för någon av deras tidigare eller framtida turer.

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 = ;

Den slutliga datamodellen

Vad sägs om förbättringar?

Kan vi förbättra denna modell ytterligare? Ja det kan vi! Det finns fortfarande några områden som måste tas om hand.

Vad händer om man vill skapa återkommande åkförfrågningar? Anta att en förare reser från en stad till en annan varje helg, och att de alltid är villiga att dela denna resa. En återkommande begäran skulle vara bekvämare.

Hur kan en person lita på någon okänd kille som erbjuder skjuts? Det borde finnas något sätt att hjälpa människor att utvärdera andra innan de begär skjuts. En gångbar mekanism är att publicera och dela feedback om åkägare och medresenärer. Dessa detaljer kommer säkert att hjälpa andra att boka en resa med främlingar mer självsäkert. Vilka ändringar krävs av vår datamodell för att detta ska hända?

Dela gärna med dig av dina synpunkter på den här modellen.