Tworzenie modelu danych do wspólnych przejazdów

Obecnie carpooling jest akceptowany i promowany przez ludzi na całym świecie. Z pewnością zmniejsza to osobisty ślad węglowy i może być bardziej opłacalne niż wynajem lub zakup samochodu.

Carpooling również wymaga dużo pracy – pracy organizacyjnej, którą z łatwością wykona dobrze zaprojektowana baza danych. W tym artykule wyjaśniono szczegółowy model danych, który może być wykorzystany przez witrynę do wspólnych przejazdów.

Projektowanie danych, poznaj Carpooling

Tak więc musimy zaprojektować model danych dla witryny internetowej umożliwiającej wspólne przejazdy (tzw. carpooling).

Carpooling to coś innego niż wynajem samochodu. W przypadku wspólnych przejazdów samochód jest własnością jednej osoby i oferuje przejazdy innym. Wszyscy współpodróżujący płacą za koszty przejazdu, w tym paliwo, opłaty drogowe itp.

Wymagania projektu:

Witryna powinna umożliwiać użytkownikom (inaczej członkowie współużytkowania przejazdów), aby zarejestrować się, używając swojego imienia i nazwiska, numeru telefonu, adresu e-mail, numeru prawa jazdy itp.
Członkowie powinni mieć możliwość ustawiania swoich preferencji dotyczące przejażdżek i współpodróżników.
Członkowie nazywani właścicielami przejazdów mogą tworzyć przejazdy wprowadzając szczegóły swojej podróży (tj. Punkty początkowe i docelowe, czas rozpoczęcia, koszty na pasażera itp.)
Inni członkowie mogą wyszukiwać dostępne przejazdy do docelowego miasta .
Członkowie, którzy szukają przejazdu, mogą skontaktować się z właścicielem przejazdu i dokonać rezerwacji dla ich miejsc.
Właściciel przejazdu powinien mieć możliwość zatwierdzania lub odrzucania próśb o rezerwację.
Na podstawie działań podjętych przez właściciela przejazdu w związku z prośbą o rezerwację, liczba dostępnych miejsc powinna zostać zaktualizowana.
Właściciel przejazdu może również oznaczyć miasta na trasie, czyli miasta na trasie od punktu początkowego do miejsca docelowego. Jeśli chcą, właściciele przejażdżek powinni również być w stanie pomieścić ludzi w miastach na trasie.

Mając na uwadze te parametry, zidentyfikujmy główne jednostki i relacje dla naszego modelu danych carpooling.

Identyfikowanie podmiotów i relacji

Kiedy patrzę na wymagania jako całość, mogę łatwo rozgryźć główne byty. Są to:

członkowie (w tym właściciele motocyklistów i współpodróżnicy )
samochód
preferencje
jazda
miasto
prośba o przejazd

Członek – Każdy, kto odwiedza tę stronę, musi się zarejestrować, zanim z niej skorzysta. W tym procesie muszą podać szczegóły, takie jak first_name , last_name , gender , email i contact number . Dla współpodróżników te elementy są wystarczające. Właściciele pojazdów, którzy prawdopodobnie będą prowadzić, muszą podać dodatkowe informacje, takie jak driving_license_number i driving_license_valid_from należy również uwzględnić. Informacje o prawie jazdy informują współpodróżujących o wrażeniach z jazdy właściciela przejażdżki. Pomoże to współpodróżującym wybrać najlepszą dostępną jazdę. Dodam jedną tabelę o nazwie member ze wszystkimi wymaganymi kolumnami.

Samochód – Właściciel przejazdu musi dodać szczegóły co najmniej jednego samochodu przed utworzeniem przejazdu. Stwórzmy więc kolejną tabelę o nazwie car , aby przechowywać te informacje. Jeden członek może posiadać więcej niż jeden samochód. Przejazd może zależeć od pary członek-samochód, więc potrzebujemy innej tabeli, aby ustalić tę relację. Nazwiemy tę tabelę member_car . Odniosę klucz podstawowy tej tabeli podczas mojej ride tabela, w której będę przechowywać szczegóły jazdy. Dodam też jedną kolumnę, a mianowicie comfort_level , który przechowuje poziom komfortu samochodu w skali od 0 do 5. Ten poziom jest automatycznie obliczany przez system na podstawie innych informacji o samochodzie podanych przez innych użytkowników.

Preferencje – Preferencje mają znaczenie dla każdego. Witryna umożliwia członkom wprowadzenie swoich preferencji dotyczących samochodu i osób towarzyszących. Te dane pozostają opcjonalne w momencie rejestracji, ale należy je wypełnić przed utworzeniem przejazdu . Właściciel przejażdżki prawdopodobnie będzie szukał osób o podobnych upodobaniach, aby każdy mógł podróżować komfortowo. Ludzie, którzy szukają przejażdżek, robią to samo.

Niektóre podstawowe preferencje dotyczące podróży samochodem to:

Czy palenie jest dozwolone w samochodzie?
Czy zwierzęta są dozwolone?
Jak rozmowny jest właściciel przejażdżki? Jaki poziom gadania jest akceptowalny podczas jazdy? (Możliwe odpowiedzi tutaj obejmują brak, lekką pogawędkę, gabfest).
Jakiego rodzaju muzyki lubi właściciel przejażdżki?
Jaką głośność muzyki pozwala właściciel przejazdu?

Ponieważ te dane są opcjonalne podczas rejestracji, stworzę kolejną tabelę o nazwie member_preference przechowywać te dane. Dwie dodatkowe tabele przechowują możliwe opcje muzyki (music_preference ) i rozmowa w samochodzie (chitchat_preference ).

Miejmy relację zero do jednego między member i member_preference tabele, ponieważ członkowie mogą, ale nie muszą, ustawić swoje preferencje w systemie podczas rejestracji, a istnieje tylko jeden rekord preferencji na członka.

Miasto – Jedna tabela główna, city , jest potrzebne do przechowywania listy wszystkich miast obsługiwanych przez serwis. Powinien zawierać odpowiednie informacje o stanie i kraju dla każdego miasta.

Jedź – Członek może utworzyć przejażdżkę, wypełniając samochód, którym podróżuje; z którego miasta wyjeżdża; do którego miasta zmierza; data i godzina podróży; liczba dostępnych miejsc; i wkład na głowę. Składka na głowę to kwota, którą każdy współpodróżnik musi zapłacić na pokrycie kosztów przejazdu. Właściciel przejażdżki może również wspomnieć, ile bagażu oczekuje od współpodróżników, aby wszystko zmieściło się w aucie. Dodajemy więc jedną kolumnę, luggage_size_allowed , dla tej pozycji. Możliwe wartości dla tej kolumny to lekka, średnia i ciężka.

Prośba o przejazd – Członkowie mogą przejrzeć listę dostępnych przejazdów z jednego miasta do drugiego lub złożyć wniosek o konkretną podróż. Zdecydowanie potrzebujemy jednej tabeli do przechowywania szczegółów dotyczących takich próśb. Tabela o nazwie request pasuje do celu. Żądanie jest początkowo wprowadzane jako „przesłane”, a właściciel przejazdu jest jedyną osobą, która może je zatwierdzić lub odrzucić. Liczba dostępnych miejsc w stoliku do jazdy zostanie dostosowana do każdego zatwierdzenia i/lub odrzucenia.

Miasta na trasie – Wspólne przejazdy nie polegają wyłącznie na jeździe prosto od punktu startowego do celu. Można również dzielić przejażdżkę z innymi w miastach na trasie. Na przykład, jeśli mężczyzna podróżuje z Chicago do Miami, może przyjąć kogoś, kto chce jechać z Chicago do Nashville. Nashville to jedno z miast, które będzie mijał na swojej trasie, więc jest to miasto na trasie. Nasz system powinien umożliwiać właścicielom przejazdów ustawianie miast na trasie w oparciu o trasę, którą będą podążać, aby dotrzeć do celu. Jeśli współpodróżnicy chcą, mogą wysiąść w dowolnym z miast na trasie; ich koszty podróży zostaną odpowiednio naliczone.

Utworzymy kolejną tabelę o nazwie enroute_city w tym celu. Rekordy zostaną dodane, gdy właściciel przejazdu doda do przejazdu miasta na trasie. Członkowie mogą następnie poprosić o rezerwację na podróż do jednego z miast na trasie. Dlatego odsyłam klucz podstawowy tej tabeli do request stół.

order_from_source kolumna w enroute_city tabela oznacza trasę, którą będzie podążał właściciel przejażdżki.

Raporty w witrynie:

Na tej stronie można wyświetlać różne raporty (wyciągi danych). Pozwólcie, że wyjaśnię kilka z nich:

Przejazdy dostępne z jednego miasta do drugiego – To jeden z raportów, który będzie dość często pobierany, ponieważ obrazuje istotę tej strony. Większość członków uzyska dostęp do tej witryny w celu znalezienia alternatywnych podróży lub wspólnych przejazdów. Pobierając ten raport, członkowie muszą podać nazwę miasta początkowego i docelowego. SQL jest następujący:

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 przesłanych / zatwierdzonych próśb o przejazd – Ten raport zostanie wyświetlony właścicielowi przejazdu. Pokaże, kto przesłał prośbę o jazdę, a właściciel może podjąć działania tylko w przypadku żądań z tego raportu. Kod SQL dla tego jest następujący:
```
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 = ;
```

Poprzednie i aktualne oferowane przejazdy – Te raporty będą wyświetlane właścicielom jeżdżących na ich własnych pulpitach nawigacyjnych. Do wygenerowania listy przejazdów aktualnie oferowanych przez właściciela przejazdu można użyć następującego kodu SQL:

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

Za pomocą tego kodu SQL można wyodrębnić listę wcześniej oferowanych przejazdów:

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 współpodróżujących na przejażdżkę – Ten raport będzie dostępny dla wszystkich współpodróżników, w tym dla właściciela przejażdżki. Każdy z nich może wygenerować listę wszystkich współpodróżników dla dowolnej z ich przeszłych lub przyszłych przejazdów.

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

Ostateczny model danych

A co z ulepszeniami?

Czy możemy jeszcze bardziej ulepszyć ten model? Tak możemy! Wciąż są pewne obszary, którymi trzeba się zająć.

Co zrobić, jeśli chcesz tworzyć cykliczne prośby o przejazdy? Załóżmy, że kierowca podróżuje z jednego miasta do drugiego w każdy weekend i zawsze chętnie dzieli się tą jazdą. Wygodniejsze byłoby cykliczne żądanie.

Jak można polegać na jakimś nieznanym facecie, który oferuje przejażdżkę? Powinien istnieć jakiś sposób, aby pomóc ludziom ocenić innych przed zamówieniem przejazdu. Jednym z realnych mechanizmów jest publikowanie i udostępnianie opinii na temat właścicieli przejażdżek i współpodróżników. Te szczegóły z pewnością pomogą innym z większą pewnością zarezerwować przejazd z nieznajomymi. Aby tak się stało, jakie zmiany są wymagane w naszym modelu danych?

Podziel się swoimi danymi wejściowymi na temat tego modelu.