Zarabiaj pieniądze na niewykorzystanych rzeczach:model danych gospodarki współdzielenia

Niewiele jest szans, że przegapiłeś całą ideę ekonomii współdzielenia – czy ci się to podoba, czy nie. Spopularyzowany przez firmy takie jak Airbnb, Uber, Lyft i wiele innych, pozwala ludziom zarobić trochę pieniędzy, wynajmując nieużywane rzeczy. Zobaczmy model danych stojący za taką aplikacją.

Masz wolny pokój? Zarejestruj się w Airbnb i zarób dodatkowe pieniądze na wynajmie. Masz samochód i trochę wolnego czasu? Zostań kierowcą Ubera. I tak to się dzieje – idea tych firm i wielu im podobnych jest prawie taka sama. Chodzi o dzielenie się zasobem (głównie) z nieznajomymi, z korzyścią dla obu stron. Właściciel dostaje pieniądze za swoją niewykorzystaną nieruchomość, podczas gdy klient zazwyczaj dostaje dobrą ofertę; powinna to być sytuacja korzystna dla obu stron.

Oczywiście potrzebujemy platformy do łączenia właścicieli z klientami i śledzenia ważnych szczegółów. Dziś przedstawimy model danych, który może zarządzać zadaniem. Usiądź wygodnie w fotelu i ciesz się jazdą po modelu danych ekonomii współdzielenia.

Czego potrzebujemy w naszym modelu danych?

Pomysł wynajmu nieruchomości, kiedy z niej nie korzystamy, wydaje się bardzo mądry. Po pierwsze, nieruchomość jest użytkowana zgodnie z jej przeznaczeniem; po drugie, wynajem przyniesie jakiś dodatkowy dochód. Może to być gotówka, ale może to być również wymiana (np. ktoś w Nowym Jorku zamienia mieszkanie z kimś w Paryżu na tydzień).

Modele bezgotówkowe są naprawdę fajne i zwykle zależą od wzajemnego zrozumienia, dobrej woli i uczciwości. W tym artykule skupimy się jednak na modelach ekonomii współdzielenia, które wymagają zapłaty. Nie jest to tak romantyczne jak modele bezgotówkowe, ale model płatności jest całkiem skuteczny.

Potrzebujemy bardzo prostego sposobu, aby duża liczba właścicieli nieruchomości dotarła do dużej liczby zainteresowanych klientów i odwrotnie. To pierwsze wymaganie dla naszego modelu danych. Będziemy mieć konta użytkowników i co najmniej dwie różne role – właściciela i klienta.

Następną rzeczą, której potrzebujemy, jest lista wszystkich dostępnych właściwości w naszej aplikacji. Dla Airbnb byłyby to mieszkania; dla Ubera byłyby to samochody. W tym artykule skupimy się bardziej na wynajmie mieszkań (model danych podobny do Airbnb), ale zachowam model na tyle ogólny, aby można go było łatwo przekształcić w dowolną inną pożądaną usługę ekonomii współdzielenia.

Dla każdego właściciela nieruchomości musimy określić lokalizację, w której prowadzi działalność. W przypadku mieszkań jest to dość oczywiste (miasto, w którym znajduje się mieszkanie). W przypadku usług transportowych będzie to zależeć od aktualnej lokalizacji samochodu i/lub jego właściciela.

W przypadku każdej usługi lub zasobu będziemy musieli śledzić okresy użytkowania i prośby/rezerwacje. Pozwoli nam to znaleźć dostępne nieruchomości po złożeniu nowego zapytania oraz obliczyć obłożenie i cenę. Będziemy również mogli korzystać z innych programów do analizowania tych danych i tworzenia innych statystyk.

Model danych

Model danych składa się z pięciu obszarów tematycznych:

Kraje i miasta
Użytkownicy i role
Usługi i dokumenty
Żądania
Świadczone usługi

Zaprezentujemy każdy obszar tematyczny w tej samej kolejności, w jakiej jest wymieniony.

Sekcja 1:Kraje i miasta

Zaczniemy od Krajów i miast Tematyka. Chociaż nie są one specyficzne dla tego modelu danych, tabele te są bardzo ważne. Usługi związane z nieruchomościami są zazwyczaj zorientowane geograficznie. Nasz model jest ściśle związany z wynajmem jakiegoś mieszkania, więc fizyczna lokalizacja jest tutaj kluczowa. Oczywiście ta lokalizacja zwykle się nie zmieni. Są bardzo szczególne przypadki, które mogą skutkować zmianą lokalizacji nieruchomości, ale to mieszkanie w nowej lokalizacji potraktowałbym jako zupełnie nową nieruchomość.

W przypadku aplikacji samochodowych i/lub dla kierowców, takich jak Uber, bardzo ważna jest również aktualna lokalizacja samochodu i kierowcy. W przeciwieństwie do wynajmu mieszkań w stylu Airbnb, te lokalizacje nieruchomości mogą się często zmieniać.

Kraj tabela zawiera listę UNIKATOWYCH nazw krajów, w których działamy. miasto tabela zawiera listę wszystkich miast, w których działamy. UNIKALNA kombinacja dla tej tabeli to kombinacja kod_pocztowy , nazwa_miasta i id_kraju atrybuty.

Obie te tabele mogą zawierać wiele dodatkowych atrybutów, ale celowo je pominąłem, ponieważ nie wniosą żadnej wartości do tego modelu.

Sekcja 2:Użytkownicy i role

Następną rzeczą, którą musimy zrobić, to zdefiniować użytkowników i ich zachowania lub role w naszej aplikacji. Aby to zrobić, użyjemy trzech tabel w Użytkownicy i role obszar tematyczny.

Lista wszystkich użytkowników znajduje się na koncie_użytkownika stół. Dla każdego użytkownika przechowujemy następujące dane:

nazwa_użytkownika – UNIKALNA nazwa, którą użytkownik wybrał, aby uzyskać dostęp do naszej aplikacji.
hasło – Wartość skrótu hasła wybranego przez użytkownika.
imię i nazwisko – Imię i nazwisko użytkownika.
identyfikator_miasta – Odniesienie do miasta gdzie zwykle znajduje się użytkownik.
current_city_id – Odniesienie do miasta gdzie aktualnie znajduje się użytkownik.
e-mail – Adres e-mail użytkownika.
czas_wstawiony – Znacznik czasu, kiedy ten rekord został wstawiony do tabeli.
kod_potwierdzenia – Kod wygenerowany podczas procesu rejestracji w celu potwierdzenia adresu e-mail użytkownika.
czas_potwierdzony – Znacznik czasu potwierdzenia adresu e-mail. Ten atrybut zawiera wartość NULL aż do momentu potwierdzenia.

Użytkownik będzie miał różne uprawnienia w aplikacji w zależności od swojej roli. Możliwe jest również, że jeden użytkownik może jednocześnie pełnić więcej niż jedną aktywną rolę, np. mogą być właścicielem jednej nieruchomości i klientem innej nieruchomości. W takim przypadku użytkownik użyje tych samych danych logowania i będzie miał możliwość przełączania się między rolami. Każda rola będzie miała swój własny ekran w aplikacji.

Lista wszystkich możliwych ról jest przechowywana w roli słownik. Każda rola jest JEDYNIE zdefiniowana przez swoją role_name . Dla uproszczenia możemy spodziewać się tylko dwóch ról:„właściciela nieruchomości” i „klienta”.

Użytkownik może mieć przypisaną tę samą rolę wielokrotnie w różnych okresach. Jednym z takich przypadków byłoby, gdyby użytkownik wynajmował swoje nieużywane mieszkanie, a następnie zdecydował się nie wynajmować swojego mieszkania, ponieważ tego potrzebował. Jednak po kilku miesiącach ten sam użytkownik zdecydował się ponownie wynająć swoje mieszkanie. W takim przypadku dezaktywowalibyśmy ich rolę, a następnie aktywowalibyśmy ją ponownie.

Lista wszystkich ról, które kiedykolwiek zostały przypisane użytkownikom, jest przechowywana w has_role stół. Dla każdego rekordu w tej tabeli będziemy przechowywać:

user_account_id – Identyfikator powiązanego użytkownika .
role_id – Identyfikator powiązanej roli .
czas_od – Znacznik czasu umieszczenia tej roli w systemie.
czas_do – Znacznik czasu dezaktywacji tej roli. Będzie zawierać wartość NULL, o ile rola jest nadal aktywna.
is_active – Jest ustawiony na Fałsz, gdy rola jest dezaktywowana z jakiegokolwiek powodu.

Wstawiając nowy rekord do tej tabeli, powinniśmy sprawdzić, czy rekordy się pokrywają. Pozwala nam to uniknąć dwukrotnego nadawania tej samej roli ważności w tym samym okresie.

Sekcja 3:Usługi i dokumenty

Następną rzeczą, którą musimy zdefiniować, są usługi świadczone przez użytkowników. Będziemy również musieli śledzić wszelkie powiązane dokumenty. Aby to zrobić, potrzebujemy tabel w Usługi i dokumenty obszar tematyczny.

Zacznijmy od właściwości stół. Nieruchomościami są dowolne obiekty naszej usługi:mieszkania, samochody, rowery itp. Możemy oczekiwać, że użytkownicy zadbają o własne nieruchomości. Dla każdej właściwości musimy zdefiniować:

property_name – Nazwa ekranowa dla tej właściwości, wybrana przez użytkownika. Ta nazwa jest używana podczas wyświetlania nieruchomości potencjalnym klientom w aplikacji. Powinien być zwięzły i opisowy oraz odróżniać tę właściwość od innych właściwości.
property_description – Dodatkowy opis tekstowy w formacie nieustrukturyzowanym. Możemy spodziewać się tu mnóstwa szczegółów – w zasadzie wszystkiego, od wielkości mieszkania po to, czy klienci dostaną powitalnego drinka po przyjeździe. Powitalne drinki w usługach transportowych są znacznie mniej prawdopodobne.
active_from i aktywne_do – Okres, w którym ta właściwość była aktywna w naszym systemie. aktywne_do atrybut będzie zawierał wartość NULL, dopóki właściwość nie zostanie dezaktywowana.
jest_dostępny – Flaga wskazująca, czy ta właściwość jest dostępna w określonym czasie, czy nie.
is_active – Flaga informująca, czy ta właściwość jest nadal aktywna w naszym systemie. Wartość tego atrybutu zostanie ustawiona na False w tym samym momencie active_to jest ustawiony.

Przejdziemy teraz do usługi słownik. Tutaj zdefiniujemy wszystkie możliwe typy usług, takie jak „najem długoterminowy”, „najem krótkoterminowy”, „transport” itp. Zawiera UNIKALNĄ nazwę typu usługi oraz dodatkowy opis , w razie potrzeby.

 
 Będziemy przechowywać powiązane właściwości, usługi i użytkowników w przewidywaniu  stół. Będzie przechowywać okresy, w których nieruchomość była dostępna. W przypadku transportu, to powiedziałoby nam, kiedy samochód i kierowca faktycznie pracowali dla naszej firmy. W przypadku wynajmu mieszkań, informuje nas, kiedy nieruchomość jest dostępna. Dla każdego rekordu tutaj mamy:
  user_account_id – Identyfikator użytkownika świadczącego tę usługę.
 service_id – Identyfikator usługi  podany typ.
 property_id – Odwołuje się do właściwości  używany.
 czas_od i czas_do – Kiedy ta nieruchomość była wykorzystywana do świadczenia tej usługi. czas_do atrybut będzie zawierał wartość NULL, dopóki ten rekord nie zostanie dezaktywowany.
 is_active – Jest ustawiona na False, gdy ta właściwość nie będzie już używana lub gdy ten użytkownik przestanie świadczyć tę usługę. Jest to ustawiane w tym samym momencie, gdy time_to jest ustawiony.
 
 
 Pozostałe dwie tabele w tym obszarze tematycznym dotyczą dokumentów. (Tabela user_account to tylko kopia oryginału, użytego tutaj, aby uniknąć nakładania się relacji.) Nasza firma będzie współpracować z wieloma właścicielami nieruchomości i prawie nie będzie możliwości sprawdzenia wszystkiego osobiście. Jednym ze sposobów zapewnienia jakości usług jest dobrze udokumentowane wszystko.
 
 Pierwsza tabela związana z dokumentami to document_type  stół. Ten prosty słownik zawiera listę UNIKALNYCH type_name wartości. Możemy spodziewać się tutaj wartości takich jak „zdjęcie nieruchomości” i „identyfikator właściciela”.
 
 Lista wszystkich dokumentów jest przechowywana w dokumencie  stół. Dokumenty te mogą być powiązane z kontami użytkowników, właściwościami lub obydwoma. Dla każdego dokumentu przechowujemy:
  lokalizacja_dokumentu – Pełna ścieżka do tego dokumentu.
 document_type_id – Odniesienie do document_type  słownik.
 user_account_id – Odniesienie do konta_użytkownika  stół. Ten atrybut będzie przechowywał wartość tylko wtedy, gdy dokument jest powiązany z użytkownikiem lub jeśli dokument jest powiązany z własnością, ale użytkownik jest również jej właścicielem.
 property_id – Odniesienie do powiązanej właściwości .
 is_active – Wskazuje, czy ten dokument jest nadal aktywny (ważny), czy nie.
 
 Sekcja 4:Prośby
   
 
 Zanim będziemy mogli świadczyć jakąkolwiek usługę, musimy otrzymać kilka próśb od użytkowników. W wynajmie mieszkań klient złoży zapytanie o pożądaną nieruchomość po przeszukaniu ofert i znalezieniu mieszkania, które chce. W przypadku usług transportowych, zgłoszenia są składane przez klientów za pośrednictwem aplikacji mobilnej (np. są na lotnisku i potrzebują przejazdu w 20 minut). Porozmawiamy o tym, jak przetwarzamy żądania w następnej sekcji; na razie zobaczmy, jak nimi zarządzamy.
 
 Centralną tabelą w tym obszarze tematycznym jest prośba  stół. Dla każdego żądania przechowujemy:
  has_role_id – Odniesienie do użytkownika (i jego obecnej roli, poprzez has_role  tabeli), kto złożył tę prośbę.
 request_status_id – Odniesienie do aktualnego statusu tego wniosku.
 status_time – Sygnatura czasowa, kiedy ten status został przydzielony.
 service_id – Identyfikator usługi  wymagane z tym żądaniem.
 identyfikator_miasta – Odniesienie do miasta  gdzie ta usługa jest wymagana.
 request_details – Wszystkie dodatkowe szczegóły żądania w nieustrukturyzowanym formacie tekstowym.
 jest_przetworzony – Flaga wskazująca, czy żądanie zostało przetworzone (tj. przypisane do usługodawcy).
 is_active – Ta flaga zostanie ustawiona na Fałsz tylko wtedy, gdy klient anulował swoją prośbę lub jeśli z jakiegoś powodu żądanie zostało anulowane przez aplikację.
 
 
 Lista wszystkich możliwych statusów jest przechowywana w request_status  słownik z status_name jako WYJĄTKOWA (i jedyną) wartość. Możemy spodziewać się wartości takich jak „zamówienie złożone”, „właściwość zarezerwowana”, „przypisane do kierowcy”, „jazda w toku” i „ukończone”.
 
 request_status_history  tabela będzie przechowywać historię wszystkich statusów związanych z żądaniami. Dla każdego rekordu w tej tabeli będziemy przechowywać identyfikator powiązanego żądania (request_id ), identyfikator stanu (request_status_id ), identyfikator konta użytkownika i rolę, jaką pełnił użytkownik, gdy ustawiał ten status (has_role_id ). Będziemy również rejestrować, kiedy każdy status został przypisany (status_time ).
 Sekcja 5:Świadczone usługi
   
 
 Po złożeniu wniosku musimy je przetworzyć. Żądanie zostanie automatycznie przypisane do odpowiedniego usługodawcy (na podstawie typu żądanej usługi, lokalizacji itp.) lub zostanie zaakceptowane ręcznie przez usługodawcę. Potrzebujemy jeszcze tylko dwóch tabel, aby sobie z tym poradzić.
 
 Pierwszym z nich jest usługa_provided_  stół. Do każdego rekordu dołączymy:
  request_id – Identyfikator powiązanego żądania  .
 provides_id – Odniesienie do przepisów  tabela określająca dostawcę usług i właściwość objętą tym działaniem.
 szczegóły – Wszystkie dodatkowe szczegóły w ustrukturyzowanym formacie tekstowym. Ta struktura może zawierać tagi i wartości opisujące szczegóły żądania. W przypadku jazdy będzie to oznaczać punkt początkowy i końcowy, przebytą odległość itp.
 czas_rozpoczęcia i end_time – Okres świadczenia tej usługi. Obie te wartości zostaną ustawione po uruchomieniu i zakończeniu usługi.
 grade_customer i grade_provider – Oceny wystawione przez klienta i usługodawcę za tę usługę.
 
 
 Ostatnia tabela w naszym modelu to faktura  stół. Będziemy pobierać opłaty od klientów (customer_name ) za świadczone usługi (provided_service_id ). Dla każdej faktury musimy znać total_amount , wszelkie zapłacone opłaty (fee_amount ), kiedy faktura została wystawiona (time_issued ) i kiedy została zapłacona (time_paid ) Opłacone pole służy jako flaga wskazująca, czy faktura została zapłacona. 
 Co sądzisz o naszym modelu danych dotyczących gospodarki współdzielenia?
 
 Dziś omówiliśmy model danych, z którego mogłaby skorzystać firma taka jak Airbnb czy Uber. Podstawą takiego modelu biznesowego są klienci i usługodawcy. Jest kilka szczegółów, które mógłbym dodać do tego modelu. Mimo to postanowiłem tego nie robić, ponieważ model szybko stałby się zbyt duży. Myślisz, że powinienem coś dodać? Jeśli tak, powiedz mi w komentarzach poniżej.