Tjäna pengar med oanvända saker:En datamodell för delningsekonomi

Det finns inte stor chans att du har missat hela idén med delningsekonomin – oavsett om du gillar det eller inte. Populariserad av företag som Airbnb, Uber, Lyft och många andra, låter det människor tjäna lite pengar genom att hyra ut sina oanvända saker. Låt oss se datamodellen bakom en sådan applikation.

Har du ett extra rum? Registrera dig hos Airbnb och tjäna lite extra pengar på att hyra ut det. Har du en bil och lite ledig tid? Bli en Uber-förare. Och så fortsätter det – tanken bakom dessa företag och många fler liknande dem är nästan densamma. Det handlar om att dela en resurs med (för det mesta) främlingar, med en förmån för båda parter. Ägaren får pengar för sin outnyttjade egendom, medan kunden oftast får en bra affär; detta borde vara en win-win-situation.

Naturligtvis behöver vi en plattform för att koppla samman ägare med kunder och för att hålla reda på viktiga detaljer. Idag kommer vi att presentera en datamodell som kan hantera uppgiften. Sätt dig tillbaka i stolen och njut av resan genom datamodellen för delningsekonomi.

Vad behöver vi i vår datamodell?

Tanken på att hyra ut egendom när vi inte använder den verkar väldigt klok. För det första används fastigheten för sitt avsedda ändamål; för det andra kommer hyran att generera någon form av extra inkomst. Det kan vara kontanter, men det kan också vara ett utbyte (t.ex. att någon i New York byter lägenhet med någon i Paris under en vecka).

Kontantlösa modeller är riktigt coola och de beror vanligtvis på ömsesidig förståelse, goodwill och ärlighet. Den här artikeln kommer dock att fokusera på delningsekonomimodeller som kräver betalning. Det är inte lika romantiskt som kontantlösa modeller, men betalningsmodellen är ganska effektiv.

Vi behöver ett väldigt enkelt sätt för ett stort antal fastighetsägare att nå ett stort antal intresserade kunder och vice versa. Detta är det första kravet för vår datamodell. Vi kommer att ha användarkonton och minst två distinkta roller – ägare och kund.

Nästa sak vi behöver är att vår app listar alla tillgängliga egenskaper. För Airbnb skulle detta vara lägenheter; för Uber skulle det här vara bilar. Den här artikeln kommer att fokusera mer på att hyra lägenheter (en Airbnb-liknande datamodell) men jag kommer att hålla modellen tillräckligt generell så att den lätt kan konverteras till vilken annan önskad delningsekonomitjänst som helst.

För varje fastighetsägare måste vi definiera platsen där de är verksamma. För lägenheter är detta ganska uppenbart (staden där lägenheten ligger). För transporttjänster kommer detta att bero på den aktuella platsen för bilen och/eller dess ägare.

För varje egendom eller resurs måste vi spåra användningsperioder och förfrågningar/bokningar. Detta gör att vi kan hitta lediga fastigheter när en ny förfrågan görs och att beräkna uthyrningsgrad och pris. Vi kommer också att kunna använda andra program för att analysera denna data och producera annan statistik.

Datamodellen

Datamodellen består av fem ämnesområden:

Länder och städer
Användare och roller
Tjänster och dokument
Förfrågningar
Tillhandahållna tjänster

Vi kommer att presentera varje ämnesområde i samma ordning som det är listat.

Avsnitt 1:Länder och städer

Vi börjar med Länder och städer ämnesområde. Även om de inte är specifika för denna datamodell, är dessa tabeller mycket viktiga. Fastighetsrelaterade tjänster är vanligtvis geografiskt inriktade. Vår modell är nära besläktad med att hyra någon form av bostad, så det fysiska läget är avgörande här. Naturligtvis kommer den platsen vanligtvis inte att ändras. Det finns några mycket speciella fall som kan leda till att en fastighets läge ändras, men jag skulle behandla den bostaden på sin nya plats som en helt ny fastighet.

För bil- och/eller förarappar som Uber är den aktuella platsen för bilen och föraren också mycket viktig. Till skillnad från uthyrning av lägenheter i Airbnb-stil kan dessa fastighetslägen ändras ofta.

landet Tabellen innehåller en lista med UNIKA namn på de länder där vi är verksamma. staden Tabellen innehåller en lista över alla städer där vi är verksamma. Den UNIKA kombinationen för den här tabellen är kombinationen av postal_code , stadsnamn och country_id attribut.

Båda dessa tabeller kan innehålla många ytterligare attribut, men jag har avsiktligt utelämnat dem eftersom de inte kommer att tillföra något värde till denna modell.

Avsnitt 2:Användare och roller

Nästa sak vi behöver göra är att definiera användare och deras beteenden eller roller i vår applikation. För att göra detta använder vi de tre tabellerna i Användare och roller ämnesområde.

En lista över alla användare finns i user_account tabell. För varje användare lagrar vi följande information:

användarnamn – Det UNIKA namn som användaren har valt för att komma åt vår applikation.
lösenord – Ett hashvärde för lösenordet som valts av användaren.
förnamn och efternamn – Användarens för- och efternamn.
stads-id – En referens till staden där användaren vanligtvis befinner sig.
current_city_id – En referens till staden där användaren för närvarande befinner sig.
e-post – Användarens e-postadress.
tid_insatt – Tidsstämpeln när denna post infogades i tabellen.
bekräftelsekod – En kod som genereras under registreringsprocessen för att bekräfta användarens e-postadress.
time_confirmed – Tidsstämpeln när e-postadressen bekräftades. Det här attributet innehåller ett NULL-värde tills bekräftelsen går igenom.

Användaren kommer att ha olika rättigheter i applikationen beroende på sin roll. Det är också möjligt att en användare kan ha mer än en aktiv roll samtidigt, t.ex. de kan vara ägare till en fastighet och kund till en annan fastighet. I så fall kommer användaren att använda samma inloggningsuppgifter och kommer att ha möjlighet att växla mellan roller. Varje roll kommer att ha sin egen skärm i appen.

En lista över alla möjliga roller lagras i rollen lexikon. Varje roll definieras UNIKT av dess rollnamn . För enkelhetens skull kan vi förvänta oss bara två roller:"fastighetsägare" och "kund".

En användare kan ha samma roll tilldelad flera gånger under olika perioder. Ett sådant fall skulle vara om användaren hyrde sin oanvända lägenhet och sedan beslutade sig för att inte hyra sin lägenhet för att de behövde den. Men efter några månader bestämde sig samma användare för att hyra sin lägenhet igen. I det här fallet skulle vi inaktivera deras roll och sedan aktivera den igen.

En lista över alla roller som någonsin tilldelats användare lagras i has_role tabell. För varje post i den här tabellen lagrar vi:

user_account_id – ID för den relaterade användaren .
roll-id – ID för den relaterade rollen .
tid_från – Tidsstämpeln när denna roll infogades i systemet.
tid_till – Tidsstämpeln när denna roll avaktiverades. Detta kommer att innehålla ett NULL-värde så länge rollen fortfarande är aktiv.
är_aktiv – Är inställd på False när rollen är avaktiverad av någon anledning.

När vi infogar en ny post i den här tabellen bör vi kontrollera om det finns överlappande poster. Detta gör att vi kan undvika att göra samma roll giltig två gånger under samma period.

Avsnitt 3:Tjänster och dokument

Nästa sak vi behöver definiera är de tjänster som tillhandahålls av användarna. Vi måste också hålla reda på eventuella relaterade dokument. För att göra det behöver vi tabellerna i Tjänster och dokument ämnesområde.

Låt oss börja med egenskapen tabell. Fastigheter är vad som än är föremål för vår tjänst:bostäder, bilar, cyklar etc. Vi kan förvänta oss att användarna tar hand om sina egna fastigheter. För varje egenskap måste vi definiera:

egendomsnamn – Skärmnamnet för den egenskapen, valt av användaren. Det här namnet används när fastigheten visas för potentiella kunder i appen. Det bör vara kortfattat och beskrivande och särskilja den egenskapen från andra egenskaper.
egenskapsbeskrivning – Ytterligare textbeskrivning i ostrukturerat format. Vi kan förvänta oss ett gäng detaljer här – i princip allt från storleken på lägenheten till om kunderna får en välkomstdrink när de kommer. Välkomstdrinkar i transporttjänster är mycket mindre benägna att hända.
aktiv_från och active_to – Tidsperioden då den egenskapen var aktiv i vårt system. active_to attribut kommer att innehålla NULL-värde tills egenskapen avaktiveras.
är_tillgänglig – En flagga som anger om den här egenskapen är tillgänglig vid en viss tidpunkt eller inte.
är_aktiv – En flagga som anger om den egenskapen fortfarande är aktiv i vårt system. Värdet för detta attribut kommer att ställas in på False vid samma ögonblick active_to är inställd.

Vi går nu till tjänsten lexikon. Det är här vi kommer att definiera alla möjliga tjänstetyper, som "långtidshyra", "korttidshyra", "transport" etc. Den innehåller det UNIKA namnet på tjänstetypen och en ytterligare beskrivning , om det behövs.

 
 Vi kommer att behålla relaterade egenskaper, tjänster och användare i tillhandahållen  tabell. Det kommer att lagra perioder då en fastighet var tillgänglig. När det gäller transport skulle detta berätta för oss när en bil och förare faktiskt arbetade för vårt företag. När det gäller lägenhetsuthyrning skulle den berätta för oss när en fastighet var tillgänglig. För varje post här har vi:
  user_account_id – ID för användaren som tillhandahåller tjänsten.
 service_id – ID för tjänsten  typ som tillhandahålls.
 property_id – Refererar till egenskapen  används.
 tid_från och time_to – När den här fastigheten användes för att tillhandahålla denna tjänst. time_to attribut kommer att innehålla ett NULL-värde tills denna post avaktiveras.
 är_aktiv – Är inställd på False när den här egenskapen inte kommer att användas längre eller när den här användaren kommer att sluta tillhandahålla den här tjänsten. Detta ställs in i samma ögonblick när time_to är inställd.
 
 
 De återstående två tabellerna i detta ämnesområde är relaterade till dokument. (Tabellen user_account är bara en kopia av originalet, används här för att undvika att relationer överlappar.) Vårt företag kommer att arbeta med många fastighetsägare och det kommer nästan inte att finnas någon chans att kontrollera allt personligen. Ett sätt att säkerställa servicekvalitet är att ha allt väl dokumenterat.
 
 Den första tabellen som är relaterad till dokument är document_type  tabell. Denna enkla ordbok innehåller en lista med UNIKT typnamn värden. Vi kan förvänta oss värden som "fastighetsbild" och "ägar-ID" här.
 
 En lista över alla dokument lagras i dokumentet  tabell. Dessa dokument kan vara relaterade till användarkonton, egenskaper eller båda. För varje dokument lagrar vi:
  dokumentplats – Den fullständiga sökvägen till det dokumentet.
 document_type_id – En referens till document_type  ordbok.
 user_account_id – En referens till user_account  tabell. Det här attributet kommer bara att ha ett värde när dokumentet är relaterat till användaren eller om dokumentet är relaterat till egenskapen men användaren också äger den egenskapen.
 property_id – En referens till den relaterade egendomen .
 är_aktiv – Anger om detta dokument fortfarande är aktivt (giltigt) eller inte.
 
 Avsnitt 4:Förfrågningar
   
 
 Innan vi kan tillhandahålla någon tjänst måste vi få några användarförfrågningar. I lägenhetsuthyrning kommer kunden att lägga sin förfrågan om den önskade fastigheten efter att de har sökt igenom bostäderna och hittat den bostad de vill ha. När det gäller transporttjänster görs förfrågningar av kunder via mobilapplikation (de är till exempel på flygplatsen och behöver en åktur på 20 minuter). Vi kommer att prata om hur vi behandlar förfrågningar i nästa avsnitt; nu ska vi se hur vi hanterar dem.
 
 Den centrala tabellen i detta ämnesområde är förfrågan  tabell. För varje förfrågan lagrar vi:
  has_role_id – En referens till användaren (och hans nuvarande roll, via has_role).  tabell) som gjorde den begäran.
 request_status_id – En referens till den aktuella statusen för begäran.
 status_tid – Tidsstämpeln när den statusen tilldelades.
 service_id – ID för tjänsten  krävs med den begäran.
 stads-id – En referens till staden  där denna tjänst krävs.
 request_details – Alla ytterligare begärandedetaljer, i ostrukturerat textformat.
 behandlas – En flagga som anger om denna begäran har behandlats (dvs. tilldelad tjänsteleverantören).
 är_aktiv – Den här flaggan kommer endast att ställas in på False om en kund avbröt sin begäran eller om den begärda avvisades av appen av någon anledning.
 
 
 En lista över alla möjliga statusar lagras i request_status  ordbok med status_name som det UNIKA (och enda) värdet. Vi kan förvänta oss värden som "förfrågan placerad", "egendom reserverad", "tilldelad förare", "kör pågår" och "avslutad".
 
 request_status_history  tabellen kommer att lagra historiken för alla statusar relaterade till förfrågningar. För varje post i den här tabellen lagrar vi ID:t för den relaterade begäran (request_id ), status-ID (request_status_id ), användarkonto-ID och rollen som användaren hade när de ställde in den statusen (has_role_id ). Vi kommer också att registrera när varje status tilldelades (status_time ).
 Avsnitt 5:Tjänster som tillhandahålls
   
 
 Efter att begäran har lagts måste vi behandla den. En begäran tilldelas antingen automatiskt till lämplig tjänsteleverantör (baserat på den begärda tjänstetypen, plats, etc.) eller så kommer den att accepteras manuellt av tjänsteleverantören. Vi behöver bara två fler bord för att hantera detta.
 
 Först är provided_service  tabell. För varje post inkluderar vi:
  request_id – ID för den relaterade begäran  .
 tillhandahåller_id – En hänvisning till ger  tabell som anger tjänsteleverantören och egenskapen som ingår i denna åtgärd.
 detaljer – Alla ytterligare detaljer, i strukturerat textformat. Denna struktur kan inkludera taggar och värden som beskriver förfrågningsdetaljer. För en åktur skulle detta betyda start- och slutpunkten, tillryggalagd sträcka osv.
 starttid och sluttid – Den period under vilken denna tjänst tillhandahålls. Båda dessa värden kommer att ställas in när tjänsten precis har startat och avslutats.
 grade_customer och grade_provider – Betyg som ges av kunden och tjänsteleverantören för den tjänsten.
 
 
 Den sista tabellen i vår modell är fakturan  tabell. Vi debiterar kunder (customer_name ) för de tillhandahållna tjänsterna (provided_service_id ). För varje faktura måste vi känna till total_amount , eventuella avgifter som betalats (fee_amount ), när fakturan utfärdades (time_issued ), och när den betalades (tid_betald ) Det betalda fältet fungerar som en flagga som indikerar om en faktura har betalats. 
 Vad tycker du om vår datamodell för delningsekonomi?
 
 Idag diskuterade vi en datamodell som skulle kunna användas av ett företag som Airbnb eller Uber. Ryggraden i en sådan affärsmodell är kunderna och tjänsteleverantörerna. Det finns ett antal detaljer jag skulle kunna lägga till i denna modell. Ändå bestämde jag mig för att inte göra det eftersom modellen snabbt skulle bli för stor. Tycker du att jag borde ha lagt till något? Om så är fallet, berätta för mig i kommentarerna nedan.