Oprettelse af en datamodel for samkørsel

I dag er samkørsel accepteret og fremmet af mennesker over hele kloden. Det reducerer bestemt ens personlige CO2-aftryk, og det kan være mere omkostningseffektivt end at leje eller købe en bil.

Samkørsel kræver også meget arbejde - organisatorisk arbejde, der let kan udføres af en veldesignet database. Denne artikel forklarer en detaljeret datamodel, som et samkørselswebsted kunne bruge.

Datadesign, mød samkørsel

Så vi er nødt til at designe en datamodel for et samkørsels-websted (også kendt som samkørsel).

Samkørsel er lidt anderledes end biludlejning. Ved samkørsel er bilen ejet af én person, og de tilbyder kørsel til andre. Eventuelle medrejsende betaler for turens omkostninger, inklusive brændstof, vejafgifter osv.

Projektkrav:

Webstedet bør tillade brugerne (alias ride-share medlemmer) for at registrere sig selv ved hjælp af deres navn, telefonnummer, e-mailadresse, kørekortnummer osv.
Medlemmer skal have lov til at angive deres præferencer vedrørende forlystelser og medrejsende.
Medlemmer kaldet rideejere kan oprette en tur ved at indtaste deres rejsedetaljer (dvs. start- og destinationspunkter, starttidspunkt, omkostninger pr. rytter osv.)
Andre medlemmer kan søge efter tilgængelige forlystelser til en destination by .
Medlemmer, der leder efter en tur, kan kontakte ejeren af forlystelsen og foretage en reservation for deres pladser.
Kørselsejeren bør være i stand til at godkende eller afvise reservationsanmodninger.
Baseret på handlingen foretaget af rejseejeren på reservationsanmodningen, bør antallet af tilgængelige pladser opdateres.
Kørselsejeren kan også markere undervejsbyer, som er byer på vej fra deres startpunkt til deres destination. Hvis de ønsker det, bør ejerne af forlystelser også være i stand til at rumme folk til byer undervejs.

Med disse parametre i tankerne, lad os identificere de vigtigste enheder og relationer for vores samkørselsdatamodel.

Identifikation af enheder og relationer

Når jeg ser kravene som helhed, kan jeg nemt finde ud af hovedenhederne. De er:

medlemmer (inklusive rytterejere og medrejsende )
bil
præferencer
tur
by
kørselsanmodning

Medlem – Alle, der besøger denne hjemmeside, skal registrere sig, før de bruger den. I denne proces skal de give detaljer som first_name , last_name , gender , email og contact number . For co-rejsende er disse varer tilstrækkelige. Kørselsejere, som formodentlig vil køre bil, skal udfylde nogle yderligere detaljer såsom driving_license_number og driving_license_valid_from skal også medtages. Kørekortoplysningerne fortæller medrejsende noget om køreoplevelsen for kørende ejer. Dette vil hjælpe medrejsende til at vælge den bedste tilgængelige tur. Jeg tilføjer en tabel med navnet member med alle påkrævede kolonner.

Bil – Kørselsejeren skal tilføje detaljer for mindst én bil, før han opretter en tur. Så lad os oprette en anden tabel, kaldet car , for at gemme disse oplysninger. Et medlem kan eje mere end én bil. En tur kan afhænge af et medlem-bil-par, så vi har brug for et andet bord for at etablere dette forhold. Vi kalder denne tabel member_car . Jeg vil henvise til den primære nøgle i denne tabel i min ride tabel, hvor jeg vil gemme køreoplysninger. Jeg tilføjer også en kolonne, nemlig comfort_level , der gemmer komfortniveauet for en bil på en skala fra 0 til 5. Dette niveau beregnes automatisk af systemet, baseret på de øvrige oplysninger om bilen, der er angivet af medlemmer.

Præferencer - Præferencer betyder noget for alle. Hjemmesiden giver medlemmer mulighed for at udfylde deres præferencer om bilen og deres medrejsende. Disse oplysninger forbliver valgfrie på registreringstidspunktet, men skal udfyldes, før du opretter en tur . Forlystelsesejeren vil sandsynligvis lede efter personer med lignende præferencer, så alle rejser komfortabelt. Folk, der søger efter forlystelser, gør det samme.

Nogle grundlæggende præferencer for bilrejser er:

Er rygning tilladt inde i bilen?
Er kæledyr tilladt med?
Hvor snakkesalig er rideejeren? Hvilket niveau af snak er acceptabelt under turen? (Mulige svar her inkluderer ingen, let snak, gabfest.)
Hvilken type musik kan rideejeren lide?
Hvilken musiklydstyrke tillader rideejeren?

Da disse detaljer er valgfrie under registreringen, opretter jeg en anden tabel med navnet member_preference at gemme disse detaljer. To ekstra tabeller gemmer mulige muligheder for musik (music_preference ) og samtale i bilen (chitchat_preference ).

Lad os have et nul-til-en-forhold mellem member og member_preference tabeller, da medlemmer måske eller måske ikke indstiller deres præferencer i systemet, når de tilmelder sig, og der er kun én post for præferencer pr. medlem.

By – Én hovedtabel, city , er nødvendig for at gemme en liste over alle de byer, der betjenes af webstedet. Den bør indeholde de relevante stats- og landeoplysninger for hver by.

Kør – Et medlem kan oprette en tur ved at udfylde, hvilken bil han rejser med; hvilken by han starter fra; hvilken by han er på vej mod; dato og tidspunkt for rejsen; antallet af ledige pladser; og bidrag pr. indbygger. Bidraget pr. indbygger er det beløb, som hver medrejsende skal betale til rejseudgifter. Kørselsejeren kan også nævne, hvor meget bagage han forventer af medrejsende, så alt får plads i bilen. Så vi tilføjer én kolonne, luggage_size_allowed , for denne vare. Mulige værdier for denne kolonne vil være let, medium og tung.

Køreanmodning – Medlemmer kan se på listen over tilgængelige forlystelser fra en by til en anden eller indsende en anmodning om en bestemt tur. Vi har bestemt brug for et bord til at gemme detaljer om sådanne anmodninger. En tabel kaldet request passer til formålet. Anmodningen indtastes i første omgang som en 'indsendt' anmodning, og kørende ejer er den eneste person, der har tilladelse til at godkende eller afvise den. Antallet af ledige pladser i køretabellen vil blive justeret for hver godkendelse og/eller afvisning.

En-route Byer – Ride sharing handler ikke kun om at gå direkte fra udgangspunkt til destination. Man kan også dele en tur med andre for en-route byer. For eksempel, hvis en mand rejser fra Chicago til Miami, kan han rumme en, der ønsker at tage fra Chicago til Nashville. Nashville er en af de byer, han vil passere på sin rute, så det er en en-route by. Vores system skulle gøre det muligt for rideejere at indstille en-route byer baseret på den rute, de vil følge for at nå deres destination. Hvis medrejsende ønsker det, kan de stå af i enhver af undervejsbyerne; deres rejseomkostninger vil blive proportionalt tilsvarende.

Vi opretter en anden tabel kaldet enroute_city til dette formål. Optegnelser vil blive tilføjet, når ejeren af turen tilføjer en-route-byer til deres tur. Medlemmer kan derefter anmode om reservationer for at rejse til en af undervejsbyerne. Derfor henviser jeg den primære nøgle til denne tabel til request bord.

order_from_source kolonne i enroute_city tabel angiver den kurs, rideejeren vil følge på rejsen.

Rapporter på webstedet:

Der er forskellige rapporter (dataudtræk), der kan vises på denne hjemmeside. Lad mig forklare et par af dem:

Forlystelser tilgængelige fra en bestemt by til en anden – Dette er en af de rapporter, der vil blive udtrukket ret hyppigt, da den skildrer essensen af denne hjemmeside. De fleste af medlemmerne vil få adgang til denne hjemmeside for at søge efter rejsealternativer eller deleture. Når du uddrager denne rapport, skal medlemmer indtaste deres start- og destinationsbynavne. SQL'en følger:

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

Liste over indsendte/godkendte anmodninger om en tur – Denne rapport vil blive vist til ejeren af turen. Det vil vise, hvem der har indsendt køreanmodningen, og ejeren kan kun handle på anmodninger fra denne rapport. SQL'en til dette følger:

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

Tidligere og nuværende forlystelser tilbydes – Disse rapporter vil blive vist for ejere af kørende på deres egne dashboards. Følgende SQL kan bruges til at generere en liste over forlystelser, som rideejeren tilbyder i øjeblikket:

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

Og denne SQL kan bruges til at udtrække en liste over tidligere tilbudte forlystelser:

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

Liste over medrejsende til en tur – Denne rapport vil være tilgængelig for alle medrejsende, inklusive forlystelsesejeren. Alle kan generere en liste over alle medrejsende til enhver af deres tidligere eller fremtidige forlystelser.

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 endelige datamodel

Hvad med forbedringer?

Kan vi forbedre denne model yderligere? Ja vi kan! Der er stadig nogle områder, der skal tages hånd om.

Hvad hvis man vil oprette tilbagevendende rideanmodninger? Antag, at en chauffør rejser fra en by til en anden hver weekend, og at de altid er villige til at dele denne tur. En tilbagevendende anmodning ville være mere praktisk.

Hvordan kan en person stole på en ukendt fyr, der tilbyder en tur? Der burde være en måde at hjælpe folk med at vurdere andre, før de anmoder om en tur. En levedygtig mekanisme er at offentliggøre og dele feedback om rideejere og medrejsende. Disse detaljer vil helt sikkert hjælpe andre til at booke en tur med fremmede mere selvsikkert. Hvilke ændringer er nødvendige i vores datamodel for at dette kan ske?

Du er velkommen til at dele dine input om denne model.