Създаване на модел на данни за споделено пътуване

В днешно време споделеното пътуване е прието и популяризирано от хора по целия свят. Това със сигурност намалява личния въглероден отпечатък и може да бъде по-изгодно от наемането или закупуването на автомобил.

Споделянето на кола също изисква много работа – организационна работа, която може лесно да бъде извършена от добре проектирана база данни. Тази статия обяснява подробен модел на данни, който може да използва уебсайт за споделено пътуване.

Дизайн на данни, запознайте се с споделеното пътуване

Така че трябва да проектираме модел на данни за уебсайт за споделяне на пътувания (известен още като споделено пътуване).

Споделянето на кола е малко по-различно от кола под наем. При споделеното пътуване колата е собственост на един човек и те предлагат возене на други. Всички пътуващи плащат към разходите за пътуване, включително гориво, пътни такси и др.

Изисквания за проекта:

• Уебсайтът трябва да позволява на потребителите (известни още като членове на ride-share), за да се регистрират, като използват своето име, телефонен номер, имейл адрес, номер на шофьорска книжка и др.
• На членовете трябва да бъде позволено да задават своите предпочитания относно пътуванията и съпътстващите.
• Членове, наречени собственици на превозни средства, могат да създадат воз като въведат подробности за пътуването си (т.е. начални и крайни точки, начален час, разходи за всеки ездач и т.н.)
• Други членове могат да търсят налични превози до град дестинация .
• Членовете, които търсят превоз, могат да се свържат със собственика на превозното средство и да направят резервация за местата им.
• Собственикът на превозното средство трябва да може да одобрява или отхвърля заявки за резервация.
• Въз основа на действията, предприети от собственика на превозното средство при заявката за резервация, броят на наличните места трябва да бъде актуализиран.
• Собственикът на превозното средство може също да маркира градове по маршрута, които са градове по пътя от началната им точка до дестинацията. Ако желаят, собствениците на превозни средства трябва също да могат да настанят хора за градовете по маршрута.

Имайки предвид тези параметри, нека идентифицираме основните обекти и връзки за нашия модел на данни за споделеното пътуване.

Идентифициране на субекти и връзки

Когато видя изискванията като цяло, мога лесно да разбера основните обекти. Те са:

• членове (включително собствениците на ездачи исъпътстващии )
• кола
• предпочитания
• вози
• град
• заявка за возене

Член – Всеки, който посещава този уебсайт, трябва да се регистрира, преди да го използва. В този процес те трябва да предоставят подробности като first_name , last_name , gender , email и contact number . За съпътстващите тези елементи са достатъчни. Собствениците на превозни средства, които вероятно ще шофират, трябва да попълнят някои допълнителни подробности като driving_license_number и driving_license_valid_from също трябва да бъдат включени. Информацията за лиценза казва на съпътстващите нещо за шофирането на собственика на автомобила. Това ще помогне на съпътстващите да изберат най-доброто налично пътуване. Ще добавя една таблица с име member с всички необходими колони.

Автомобил – Собственикът на превозното средство трябва да добави подробности за поне една кола, преди да създаде пътуване. Така че нека създадем друга таблица, наречена car , за да съхранявате тази информация. Един член може да притежава повече от една кола. Едно пътуване може да зависи от двойка член-автомобил, така че се нуждаем от друга маса, за да установим тази връзка. Ще наречем тази таблица member_car . Ще се позова на първичния ключ на тази таблица в моята ride таблица, в която ще съхранявам подробности за пътуването. Ще добавя и една колона, а именно comfort_level , който съхранява нивото на комфорт на автомобил по скала от 0 до 5. Това ниво се изчислява автоматично от системата въз основа на предоставените от други членове подробности за автомобила.

Предпочитания – Предпочитанията са важни за всеки. Уебсайтът позволява на членовете да попълнят своите предпочитания за колата и техните съпътстващи. Тези подробности остават незадължителни към момента на регистрация, но трябва да бъдат попълнени, преди да създадете пътуване . Собственикът на автомобила вероятно ще търси хора с подобни предпочитания, така че всички да пътуват удобно. Хората, които търсят превози, правят същото.

Някои основни предпочитания за пътуване с кола са:

• Разрешено ли е пушенето в колата?
• Допускат ли се домашни любимци?
• Колко приказлив е собственикът на автомобила? Какво ниво на бърборене е приемливо по време на карането? (Възможните отговори тук включват никакъв, лек чат, веселба.)
• Какъв тип музика харесва собственикът на автомобила?
• Каква сила на звука на музиката позволява собственикът на превозното средство?

Тъй като тези подробности не са задължителни по време на регистрацията, ще създам друга таблица с име member_preference за съхраняване на тези данни. Две допълнителни таблици съхраняват възможни опции за музика (music_preference ) и разговор в колата (chitchat_preference ).

Нека имаме връзка нула към едно между member и member_preference таблици, тъй като членовете могат или не могат да задават своите предпочитания в системата, когато се регистрират, и има само един запис за предпочитания на член.

Град – Една главна маса, city , е необходим за съхраняване на списък с всички градове, обслужвани от уебсайта. Той трябва да включва съответната информация за щат и държава за всеки град.

Пътувайте – Член може да създаде пътуване, като попълни с коя кола пътува; от кой град тръгва; към кой град се насочва; датата и часа на пътуването; броят на наличните места; и принос на глава. Вноската на глава е сумата, която всеки съпътстващ трябва да заплати за разходите за пътуване. Собственикът на атракциона може също да спомене колко багаж очаква от други пътуващи, така че всичко да се побере в колата. Така че добавяме една колона, luggage_size_allowed , за този артикул. Възможните стойности за тази колона биха били леки, средни и тежки.

Заявка за превоз – Членовете могат да разгледат списъка с налични пътувания от един град до друг или да подадат заявка за конкретно пътуване. Определено имаме нужда от една таблица, за да съхраняваме подробности за подобни заявки. Таблица, наречена request отговаря на целта. Заявката първоначално се въвежда като „подадена“ заявка и собственикът на превозното средство е единственото лице, на което е разрешено да я одобри или отхвърли. Броят на наличните места в масата за каране ще се коригира за всяко одобрение и/или отхвърляне.

Градове по маршрута – Споделянето на пътувания не е всичко за преминаване направо от начална точка до дестинация. Човек може да сподели пътуване с други и за градовете по маршрута. Например, ако човек пътува от Чикаго до Маями, той може да настани някой, който иска да отиде от Чикаго до Нашвил. Нашвил е един от градовете, които ще премине по маршрута си, така че това е град по маршрута. Нашата система трябва да позволява на собствениците на превозни средства да задават градове по маршрута въз основа на маршрута, който ще следват, за да стигнат до местоназначението си. Ако съпътстващите искат, те могат да слязат във всеки от градовете по маршрута; техните пътни разходи ще бъдат съответно пропорционални.

Ще създадем друга таблица, наречена enroute_city за тази цел. Записите ще бъдат добавени, когато собственикът на превозното средство добави градове по маршрута към своето пътуване. След това членовете могат да поискат резервации за пътуване до един от градовете по маршрута. Затова препращам първичния ключ на тази таблица в request маса.

order_from_source колона в enroute_city таблицата означава курса, който собственикът на автомобила ще следва за пътуването.

Отчети на уебсайта:

Има различни отчети (извлечения от данни), които могат да бъдат показани на този уебсайт. Нека обясня някои от тях:

1. Предлагат се пътувания от един конкретен град до друг – Това е един от докладите, които ще се извличат доста често, тъй като изобразява същността на този уебсайт. Повечето от членовете ще имат достъп до този уебсайт, за да търсят алтернативи за пътуване или акции. Когато извличат този отчет, членовете трябва да въведат началното и крайното си име на града. 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, 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);
   

2. Списък с изпратени/одобрени заявки за превоз – Този отчет ще бъде показан на собственика на превозното средство. Той ще покаже кой е подал заявката за превоз и собственикът може да предприеме действия само по заявки от този отчет. SQL за това следва:

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

3. Предлагат се предишни и текущи пътувания – Тези отчети ще се показват на собствениците на превозни средства на техните собствени табла. Следният 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 = ;
   

   И този 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 = ;
   

4. Списък на съпътстващите за возене – Този отчет ще бъде достъпен за всички пътуващи, включително собственика на превозното средство. Всички те могат да генерират списък на всички съпътстващи за всяко от техните минали или бъдещи пътувания.

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

Моделът на окончателните данни

Какво ще кажете за подобренията?

Можем ли да подобрим допълнително този модел? Да, можем! Все още има някои области, за които трябва да се погрижим.

Ами ако някой иска да създава повтарящи се заявки за возене? Да предположим, че шофьор пътува от един град до друг всеки уикенд и той винаги е готов да споделя това пътуване. Повтарящата се заявка би била по-удобна.

Как може човек да разчита на някакъв непознат човек, който предлага превоз? Трябва да има някакъв начин да се помогне на хората да оценят другите, преди да поискат превоз. Един жизнеспособен механизъм е да публикувате и споделяте обратна връзка за собствениците на превозни средства и съпътстващите. Тези подробности със сигурност ще помогнат на другите да резервират по-уверено пътуване с непознати. За да се случи това, какви промени са необходими в нашия модел на данни?

Чувствайте се свободни да споделите вашите приноси за този модел.