Печелете пари с неизползвани неща:модел на данни за икономика за споделяне

Няма голям шанс да сте пропуснали цялата идея за икономиката на споделянето – независимо дали ви харесва или не. Популяризиран от компании като Airbnb, Uber, Lyft и много други, той позволява на хората да печелят малко пари, като отдават под наем неизползваните си неща. Нека видим модела на данни зад такова приложение.

Имате ли свободна стая? Регистрирайте се в Airbnb и спечелете допълнителни пари, като го отдавате под наем. Имате ли кола и малко свободно време? Станете шофьор на Uber. И така става – идеята зад тези компании и много други като тях е почти същата. Всичко е за споделяне на ресурс с (предимно) непознати, с предимство и за двете страни. Собственикът получава пари за неизползвания имот, докато клиентът обикновено получава добра сделка; това трябва да бъде печеливша ситуация.

Разбира се, имаме нужда от платформа за свързване на собственици с клиенти и за проследяване на важни детайли. Днес ще представим модел на данни, който може да управлява задачата. Облегнете се на стола си и се насладете на пътуването през модела на данни за икономика на споделяне.

Какво ни трябва в нашия модел на данни?

Идеята да отдаваме имот под наем, когато не го използваме, изглежда много мъдра. Първо, имотът се използва по предназначение; второ, отдаването под наем ще генерира някакъв допълнителен доход. Това може да бъде пари в брой, но може да е и размяна (например някой в Ню Йорк разменя апартаменти с някой в Париж за една седмица).

Безкасовите модели са наистина страхотни и обикновено зависят от взаимното разбирателство, добра воля и честност. Тази статия обаче ще се фокусира върху моделите на икономика на споделяне, които изискват плащане. Не е толкова романтично, колкото безкасовите модели, но моделът на плащане е доста ефективен.

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

Следващото нещо, от което се нуждаем, е нашето приложение да изброява всички налични свойства. За Airbnb това ще бъдат апартаменти; за Uber това ще са коли. Тази статия ще се фокусира повече върху наемането на апартаменти (модел на данни, подобен на Airbnb), но ще запазя модела достатъчно общ, за да може лесно да бъде преобразуван във всяка друга желана услуга за икономия на споделяне.

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

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

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

Моделът на данни се състои от пет предметни области:

Държави и градове
Потребители и роли
Услуги и документи
Заявки
Предоставени услуги

Ще представим всяка тематична област в същия ред, в който е изброен.

Раздел 1:Държави и градове

Ще започнем с Държави и градове предметна област. Въпреки че не са специфични за този модел на данни, тези таблици са много важни. Услугите, свързани с имоти, обикновено са географски ориентирани. Нашият модел е тясно свързан с наемането на някакъв вид жилище, така че физическото местоположение е от решаващо значение тук. Разбира се, това местоположение обикновено няма да се промени. Има някои много специални случаи, които могат да доведат до промяна на местоположението на имот, но аз бих третирал това жилище на новото му местоположение като напълно нов имот.

За приложения за автомобили и/или шофьори като Uber, текущото местоположение на колата и шофьора също е много важно. За разлика от апартаментите под наем в стил Airbnb, тези места на имоти могат да се променят често.

държавата таблицата съдържа списък с УНИКАЛНИ имена на страните, в които оперираме. Градът таблицата съдържа списък на всички градове, в които оперираме. УНИКАЛНАТА комбинация за тази таблица е комбинацията от postal_code , име_на_град и country_id атрибути.

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

Раздел 2:Потребители и роли

Следващото нещо, което трябва да направим, е да дефинираме потребителите и тяхното поведение или роли в нашето приложение. За да направим това, ще използваме трите таблици в Потребители и роли предметна област.

Списък с всички потребители е в user_account маса. За всеки потребител ще съхраняваме следните данни:

потребителско_име – УНИКАЛНОТО име, което потребителят е избрал за достъп до нашето приложение.
парола – Хеш стойност на избраната от потребителя парола.
first_name и фамилно_име – Името и фамилията на потребителя.
city_id – Препратка към град където обикновено се намира потребителят.
current_city_id – Препратка към град къде се намира потребителят в момента.
имейл – Имейл адресът на потребителя.
време_вмъкнато – Времевата марка, когато този запис е бил вмъкнат в таблицата.
код_потвърждение – Код, генериран по време на процеса на регистрация за потвърждение на имейл адреса на потребителя.
време_потвърдено – Печатът за време, когато имейл адресът е бил потвърден. Този атрибут съдържа стойност NULL, докато не премине потвърждението.

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

Списък с всички възможни роли се съхранява в роля речник. Всяка роля е УНИКАЛНО дефинирана от своя role_name . За простота можем да очакваме само две роли:„собственик на имота“ и „клиент“.

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

Списък с всички роли, които някога са били присвоени на потребителите, се съхранява в has_role маса. За всеки запис в тази таблица ще съхраняваме:

user_account_id – ИД на свързания потребител .
role_id – ИД на свързаната роля .
време_от – Времевата марка, когато тази роля е била вмъкната в системата.
време_до – Времевата марка, когато тази роля е била деактивирана. Това ще съдържа стойност NULL, докато ролята е все още активна.
е_активен – Задава се на False, когато ролята е деактивирана по някаква причина.

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

Раздел 3:Услуги и документи

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

Нека започнем с свойството маса. Имотите са каквито и да са обектите на нашата услуга:жилища, автомобили, велосипеди и т.н. Можем да очакваме, че потребителите ще се грижат сами за своите имоти. За всяко свойство ще трябва да дефинираме:

име_на_свойство – Екранното име за това свойство, избрано от потребителя. Това име се използва при показване на имота на потенциални клиенти в приложението. То трябва да е кратко и описателно и да отделя това свойство от другите свойства.
описание_свойство – Допълнително текстово описание в неструктуриран формат. Тук можем да очакваме куп подробности – основно всичко от размера на апартамента до това дали клиентите ще получат питие за добре дошли, когато пристигнат. Много по-рядко се случват напитки за добре дошли в транспортните услуги.
активен_от и active_to – Периодът от време, през който тази собственост е била активна в нашата система. active_to атрибутът ще съдържа стойност NULL, докато свойството не бъде деактивирано.
е_наличен – Флаг, обозначаващ дали това свойство е налично в определен момент или не.
е_активен – Флаг, обозначаващ дали това свойство все още е активно в нашата система. Стойността на този атрибут ще бъде зададена на False в същия момент active_to е зададено.

Сега ще преминем към услугата речник. Тук ще дефинираме всички възможни видове услуги, като „дългосрочен наем“, „краткосрочен наем“, „транспорт“ и т.н. Той съдържа УНИКАЛНО име на типа услуга и допълнително описание , ако е необходимо.

 
 Ще запазим свързаните имоти, услуги и потребители в предоставянето  маса. Той ще съхранява периоди, когато даден имот е бил наличен. В случай на транспорт, това ще ни покаже кога кола и шофьор действително работят за нашата компания. В случай на апартаменти под наем, той ще ни покаже кога даден имот е наличен. За всеки запис тук ще имаме:
  user_account_id – Идентификационният номер на потребителя, предоставящ тази услуга.
 идентификатор на услугата – ИД на услугата  предоставен вид.
 property_id – Препраща свойството  използван.
 време_от и време_до – Когато тази собственост е била използвана за предоставяне на тази услуга. време_до атрибутът ще съдържа стойност NULL, докато този запис не бъде деактивиран.
 е_активен – Задава се на False, след като това свойство вече няма да се използва или когато този потребител спре да предоставя тази услуга. Това се задава в същия момент, когато time_to е зададено.
 
 
 Останалите две таблици в тази тема са свързани с документи. (Таблицата user_account е просто копие на оригинала, използвано тук, за да се избегне припокриване на отношенията.) Нашата компания ще работи с много собственици на имоти и няма да има почти никакъв шанс да проверите всичко лично. Един от начините да се гарантира качество на услугата е всичко да е добре документирано.
 
 Първата таблица, свързана с документи, е document_type  маса. Този прост речник съдържа списък с УНИКАЛНО type_name стойности. Тук можем да очакваме стойности като „снимка на имота“ и „идентификатор на собственика“.
 
 Списък с всички документи се съхранява в документа  маса. Тези документи могат да бъдат свързани с потребителски акаунти, свойства или и двете. За всеки документ ще съхраняваме:
  document_location – Пълният път до този документ.
 идентификатор на_тип_документа – Препратка към document_type  речник.
 user_account_id – Препратка към user_account  маса. Този атрибут ще съдържа стойност само когато документът е свързан с потребителя или ако документът е свързан със собствеността, но потребителят също притежава тази собственост.
 property_id – Препратка към сродния имот .
 е_активен – Означава дали този документ все още е активен (валиден) или не.
 
 Раздел 4:Заявки
   
 
 Преди да можем да предоставим каквато и да е услуга, трябва да получим някои потребителски заявки. При наемане на апартаменти, клиентът ще направи своята заявка за желания имот, след като е търсил в обявите и е намерил жилището, което иска. В случай на транспортни услуги, заявките се подават от клиентите чрез мобилно приложение (например те са на летището и се нуждаят от превоз за 20 минути). Ще говорим за това как обработваме заявките в следващия раздел; засега нека видим как ще ги управляваме.
 
 Централната таблица в тази предметна област е заявката  маса. За всяка заявка ще съхраняваме:
  has_role_id – Препратка към потребителя (и текущата му роля, чрез has_role  таблица), който е направил това искане.
 request_status_id – Препратка към текущото състояние на тази заявка.
 status_time – Времевата марка, когато е присвоен този статус.
 идентификатор на услугата – ИД на услугата  изисква се с тази заявка.
 city_id – Препратка към град  където се изисква тази услуга.
 detail_request_details – Всички допълнителни подробности за заявката, в неструктуриран текстов формат.
 е_обработено – Флаг, обозначаващ дали тази заявка е била обработена (т.е. присвоена е на доставчика на услуги).
 е_активен – Този флаг ще бъде зададен на False само ако клиент е отменил заявката си или ако заявеното е било анулирано от приложението по някаква причина.
 
 
 Списък с всички възможни състояния се съхранява в request_status  речник с име_на_състояние като УНИКАЛНА (и единствена) стойност. Можем да очакваме стойности като „подадена заявка“, „свойство запазено“, „присвоено на водача“, „движение в ход“ и „завършено“.
 
 request_status_history  таблицата ще съхранява историята на всички състояния, свързани със заявките. За всеки запис в тази таблица ще съхраняваме идентификатора на свързаната заявка (request_id ), идентификатора на състоянието (request_status_id ), идентификатора на потребителския акаунт и ролята, която потребителят е имал, когато е задал това състояние (has_role_id ). Ще записваме също кога е присвоено всяко състояние (status_time ).
 Раздел 5:Предоставени услуги
   
 
 След като заявката бъде изпратена, трябва да я обработим. Заявка или автоматично ще бъде присвоена на съответния доставчик на услуги (въз основа на искания тип услуга, местоположение и т.н.), или ще бъде приета ръчно от доставчика на услуги. Нуждаем се само от още две таблици, за да се справим с това.
 
 Първо е предоставената_услуга  маса. За всеки запис ще включим:
  request_id – ИД на свързаната заявка  .
 предоставя_идентификатор – Препратка към предоставя  таблица, която обозначава доставчика на услуги и собствеността, включени в това действие.
 подробности – Всички допълнителни подробности, в структуриран текстов формат. Тази структура може да включва тагове и стойности, които описват подробности за заявката. За каране това би означавало начална и крайна точка, изминато разстояние и т.н.
 начален_час и end_time – Периодът, през който е предоставена тази услуга. И двете стойности ще бъдат зададени, когато услугата току-що стартира и приключи.
 grade_customer и grade_provider – Оценки, дадени от клиента и доставчика на услуги за тази услуга.
 
 
 Последната таблица в нашия модел е фактурата  маса. Ще таксуваме клиентите (customer_name ) за предоставяните услуги (provided_service_id ). За всяка фактура трябва да знаем обща_сума , всички платени такси (fee_amount ), когато фактурата е била издадена (time_issued ) и кога е платено (time_paid ) Платеното поле служи като флаг, указващ дали дадена фактура е платена. 
 Какво мислите за нашия модел на данни за икономика на споделяне?
 
 Днес обсъдихме модел на данни, който може да се използва от компания като Airbnb или Uber. Гръбнакът на такъв бизнес модел са клиентите и доставчиците на услуги. Има редица подробности, които мога да добавя към този модел. Все пак реших да не правя това, защото моделът бързо ще стане твърде голям. Мислите ли, че трябваше да добавя нещо? Ако е така, моля, кажете ми в коментарите по-долу.