Tjen penge med ubrugte ting:En delingsøkonomi-datamodel

Der er ikke stor chance for, at du er gået glip af hele ideen om deleøkonomi - uanset om du kan lide det eller ej. Populariseret af virksomheder som Airbnb, Uber, Lyft og mange andre, lader det folk tjene nogle penge ved at leje deres ubrugte ting ud. Lad os se datamodellen bag sådan en applikation.

Har du et ekstra værelse? Tilmeld dig Airbnb og tjen nogle ekstra penge på at leje det ud. Har du en bil og lidt fritid? Bliv Uber-chauffør. Og sådan fortsætter det – ideen bag disse virksomheder og mange flere som dem er næsten den samme. Det handler om at dele en ressource med (for det meste) fremmede, med et frynsegode for begge parter. Ejeren får penge for deres ubrugte ejendom, mens kunden normalt får en god handel; dette burde være en win-win situation.

Selvfølgelig har vi brug for en platform til at forbinde ejere med kunder og til at holde styr på vigtige detaljer. I dag vil vi præsentere en datamodel, der kunne klare opgaven. Læn dig tilbage i din stol, og nyd turen gennem deleøkonomiske datamodel.

Hvad har vi brug for i vores datamodel?

Ideen med at leje bolig ud, når vi ikke bruger den, virker meget klog. For det første bliver ejendommen brugt til dets tilsigtede formål; for det andet vil lejen generere en form for ekstra indtægt. Det kan være kontanter, men det kan også være en udveksling (f.eks. en person i New York, der bytter lejlighed med en i Paris i en uge).

Kontantløse modeller er virkelig seje, og de afhænger normalt af gensidig forståelse, goodwill og ærlighed. Denne artikel vil dog fokusere på deleøkonomiske modeller, der kræver betaling. Det er ikke så romantisk som kontantløse modeller, men betalingsmodellen er ret effektiv.

Vi har brug for en meget enkel måde for et stort antal ejendomsejere at nå et stort antal interesserede kunder og omvendt. Dette er det første krav til vores datamodel. Vi vil have brugerkonti og mindst to adskilte roller – ejer og kunde.

Den næste ting, vi har brug for, er, at vores app viser alle de tilgængelige egenskaber. For Airbnb ville dette være lejligheder; for Uber ville dette være biler. Denne artikel vil fokusere mere på leje af lejligheder (en Airbnb-lignende datamodel), men jeg vil holde modellen generel nok, så den nemt kan konverteres til enhver anden ønsket deleøkonomisk tjeneste.

For hver ejendomsejer skal vi definere det sted, hvor de opererer. For lejligheder er dette ret indlysende (den by, hvor lejligheden ligger). For transporttjenester vil dette afhænge af den aktuelle placering af bilen og/eller dens ejer.

For hver ejendom eller ressource skal vi spore brugsperioder og anmodninger/reservationer. Dette vil give os mulighed for at finde ledige ejendomme, når en ny forespørgsel indgives, og beregne bebyggelsesgrad og pris. Vi vil også være i stand til at bruge andre programmer til at analysere disse data og producere andre statistikker.

Datamodellen

Datamodellen består af fem emneområder:

Lande og byer
Brugere og roller
Tjenester og dokumenter
Anmodninger
Tilbudte tjenester

Vi præsenterer hvert emneområde i samme rækkefølge, som det er angivet.

Afsnit 1:Lande og byer

Vi starter med Lande og byer emneområde. Selvom de ikke er specifikke for denne datamodel, er disse tabeller meget vigtige. Ejendomsrelaterede tjenester er normalt geografisk orienteret. Vores model er tæt forbundet med at leje en form for bolig, så den fysiske placering er afgørende her. Selvfølgelig vil den placering normalt ikke ændre sig. Der er nogle helt særlige tilfælde, der kan resultere i, at en ejendoms placering ændres, men jeg vil behandle den bolig på dens nye placering som en helt ny ejendom.

For bil- og/eller chaufførapps som Uber er den aktuelle placering af bilen og chaufføren også meget vigtig. I modsætning til leje af lejligheder i Airbnb-stil, kan disse ejendomsplaceringer ændre sig ofte.

landet tabellen indeholder en liste over UNIKKE navne på de lande, hvor vi opererer. byen tabel indeholder en liste over alle de byer, hvor vi opererer. Den UNIKKE kombination for denne tabel er kombinationen af postal_code , bynavn og country_id egenskaber.

Begge disse tabeller kunne indeholde mange yderligere attributter, men jeg har med vilje udeladt dem, fordi de ikke vil tilføje nogen værdi til denne model.

Afsnit 2:Brugere og roller

Den næste ting, vi skal gøre, er at definere brugere og deres adfærd eller roller i vores applikation. For at gøre dette bruger vi de tre tabeller i Brugere og roller emneområde.

En liste over alle brugere er i user_account bord. For hver bruger gemmer vi følgende detaljer:

brugernavn – Det UNIKKE navn, som brugeren har valgt for at få adgang til vores applikation.
adgangskode – En hashværdi af adgangskoden valgt af brugeren.
fornavn og efternavn – Brugerens for- og efternavne.
by_id – En reference til byen hvor brugeren normalt befinder sig.
current_city_id – En reference til byen hvor brugeren i øjeblikket befinder sig.
e-mail – Brugerens e-mailadresse.
tid_indsat – Tidsstemplet, da denne post blev indsat i tabellen.
bekræftelseskode – En kode, der genereres under registreringsprocessen for at bekræfte brugerens e-mailadresse.
tidsbekræftet – Tidsstemplet, når e-mailadressen blev bekræftet. Denne attribut indeholder en NULL-værdi, indtil bekræftelsen går igennem.

Brugeren vil have forskellige rettigheder i applikationen i henhold til deres rolle. Det er også muligt, at én bruger kan have mere end én aktiv rolle på samme tid, f.eks. de kunne være ejer af en ejendom og kunde af en anden ejendom. I så fald vil brugeren bruge de samme login detaljer og vil have mulighed for at skifte mellem roller. Hver rolle vil have sin egen skærm i appen.

En liste over alle mulige roller er gemt i rollen ordbog. Hver rolle er UNIKT defineret af dens rolle_name . For enkelthedens skyld kan vi kun forvente to roller:"ejendomsejer" og "kunde".

En bruger kan have den samme rolle tildelt flere gange i forskellige perioder. Et sådant tilfælde ville være, hvis brugeren lejede deres ubrugte lejlighed og derefter besluttede ikke at leje deres lejlighed, fordi de havde brug for det. Men efter et par måneder besluttede den samme bruger at leje deres lejlighed igen. I dette tilfælde vil vi deaktivere deres rolle og derefter aktivere den igen.

En liste over alle roller, der nogensinde er blevet tildelt til brugere, er gemt i has_role bord. For hver post i denne tabel gemmer vi:

user_account_id – ID'et for den relaterede bruger .
rolle_id – ID'et for den relaterede rolle .
tid_fra – Tidsstemplet, da denne rolle blev indsat i systemet.
tid_til – Tidsstemplet, da denne rolle blev deaktiveret. Dette vil indeholde en NULL-værdi, så længe rollen stadig er aktiv.
er_aktiv – Er indstillet til Falsk, når rollen er deaktiveret af en eller anden grund.

Når vi indsætter en ny post i denne tabel, bør vi kontrollere for overlappende poster. Dette giver os mulighed for at undgå at gøre den samme rolle gyldig to gange i samme periode.

Afsnit 3:Tjenester og dokumenter

Den næste ting, vi skal definere, er de tjenester, der leveres af brugerne. Vi skal også holde styr på eventuelle relaterede dokumenter. For at gøre det skal vi bruge tabellerne i Tjenester og dokumenter emneområde.

Lad os starte med egenskaben bord. Ejendomme er, hvad end formålet med vores service er:boliger, biler, cykler osv. Vi kan forvente, at brugerne passer på deres egne ejendomme. For hver ejendom skal vi definere:

ejendomsnavn – Skærmnavnet for den pågældende ejendom, valgt af brugeren. Dette navn bruges, når ejendommen vises til potentielle kunder i appen. Den skal være kort og beskrivende og adskille denne egenskab fra andre egenskaber.
egenskabsbeskrivelse – Yderligere tekstbeskrivelse i ustruktureret format. Vi kan forvente en masse detaljer her – stort set alt fra lejlighedens størrelse til, om kunderne får en velkomstdrink, når de ankommer. Velkomstdrinks i transporttjenester er meget mindre tilbøjelige til at ske.
aktiv_fra og active_to – Det tidsrum, hvor denne ejendom var aktiv i vores system. active_to attribut vil indeholde NULL-værdi, indtil egenskaben er deaktiveret.
er_tilgængelig – Et flag, der angiver, om denne egenskab er tilgængelig på et bestemt tidspunkt eller ej.
er_aktiv – Et flag, der angiver, om denne ejendom stadig er aktiv i vores system. Værdien af denne attribut vil blive sat til False på samme tidspunkt active_to er indstillet.

Vi går nu til tjenesten ordbog. Det er her, vi definerer alle mulige servicetyper, såsom "langtidsleje", "korttidsleje", "transport" osv. Den indeholder det UNIKKE navn på tjenestetypen og en yderligere beskrivelse , hvis det er nødvendigt.

 
 Vi beholder relaterede egenskaber, tjenester og brugere i tilbyder  bord. Det vil gemme perioder, hvor en ejendom var tilgængelig. I tilfælde af transport ville dette fortælle os, hvornår en bil og chauffør faktisk arbejdede for vores virksomhed. I tilfælde af leje af lejligheder ville den fortælle os, hvornår en ejendom var ledig. For hver post her har vi:
  user_account_id – ID'et på den bruger, der leverer den pågældende tjeneste.
 service_id – ID'et for tjenesten  angivet type.
 ejendoms-id – Refererer til egenskaben  brugt.
 tid_fra og tid_til – Når denne ejendom blev brugt til at levere denne service. time_to attribut vil indeholde en NULL-værdi, indtil denne post er deaktiveret.
 er_aktiv – Er indstillet til Falsk, når denne ejendom ikke længere vil blive brugt, eller når denne bruger stopper med at levere denne tjeneste. Dette indstilles på samme tidspunkt, når time_to er indstillet.
 
 
 De resterende to tabeller i dette emneområde er relateret til dokumenter. (Tabellen user_account er kun en kopi af originalen, brugt her for at undgå, at relationer overlapper.) Vores virksomhed vil arbejde med mange ejendomsejere, og der vil næsten ikke være mulighed for at tjekke alt personligt. En måde at sikre servicekvalitet på er at have alt veldokumenteret.
 
 Den første tabel relateret til dokumenter er document_type  bord. Denne enkle ordbog indeholder en liste med UNIK typenavn værdier. Vi kan forvente værdier som "ejendomsbillede" og "ejer-id" her.
 
 En liste over alle dokumenter er gemt i dokumentet  bord. Disse dokumenter kan være relateret til brugerkonti, egenskaber eller begge dele. For hvert dokument gemmer vi:
  dokumentplacering – Den fulde sti til det pågældende dokument.
 document_type_id – En reference til document_type  ordbog.
 user_account_id – En reference til user_account  bord. Denne attribut vil kun indeholde en værdi, når dokumentet er relateret til brugeren eller hvis dokumentet er relateret til ejendommen, men brugeren også ejer ejendommen.
 ejendoms-id – En reference til den relaterede ejendom .
 er_aktiv – Angiver, om dette dokument stadig er aktivt (gyldigt) eller ej.
 
 Afsnit 4:Anmodninger
   
 
 Før vi kan levere nogen service, skal vi have nogle brugeranmodninger. Ved udlejning af lejligheder vil kunden indgive sin anmodning om den ønskede bolig, efter at de har søgt i boligerne og fundet den bolig, de ønsker. I tilfælde af transporttjenester placeres anmodninger af kunder via mobilapplikation (de er f.eks. i lufthavnen og har brug for en tur på 20 minutter). Vi vil tale om, hvordan vi behandler anmodninger i næste afsnit; lad os nu se, hvordan vi administrerer dem.
 
 Den centrale tabel i dette emneområde er anmodningen  bord. For hver anmodning gemmer vi:
  har_rolle_id – En reference til brugeren (og hans nuværende rolle via has_role).  tabel), som har fremsat denne anmodning.
 request_status_id – En reference til den aktuelle status for denne anmodning.
 status_tid – Tidsstemplet, hvor denne status blev tildelt.
 service_id – ID'et for tjenesten  påkrævet med den anmodning.
 by_id – En reference til byen  hvor denne service er påkrævet.
 request_details – Alle yderligere anmodningsdetaljer i ustruktureret tekstformat.
 er_behandlet – Et flag, der angiver, om denne anmodning er blevet behandlet (dvs. tildelt til tjenesteudbyderen).
 er_aktiv – Dette flag vil kun blive indstillet til Falsk, hvis en kunde har annulleret sin anmodning, eller hvis den anmodede blev annulleret af appen af en eller anden grund.
 
 
 En liste over alle mulige statusser er gemt i request_status  ordbog med status_name som den UNIKKE (og eneste) værdi. Vi kan forvente værdier som "anmodning placeret", "ejendommen reserveret", "tildelt chauffør", "kørsel i gang" og "afsluttet".
 
 request_status_history  tabellen gemmer historikken for alle statusser relateret til anmodninger. For hver post i denne tabel gemmer vi ID'et for den relaterede anmodning (request_id ), status-id'et (request_status_id ), brugerkonto-id'et og den rolle, brugeren havde, da de indstillede denne status (has_role_id ). Vi registrerer også, hvornår hver status blev tildelt (status_time ).
 Afsnit 5:Leverede tjenester
   
 
 Efter anmodningen er indgivet, skal vi behandle den. En anmodning vil enten automatisk blive tildelt den relevante tjenesteudbyder (baseret på den ønskede tjenestetype, lokation osv.), eller den vil blive accepteret manuelt af tjenesteudbyderen. Vi mangler kun to borde mere til at håndtere dette.
 
 Først er provided_service  bord. For hver post inkluderer vi:
  request_id – ID'et for den relaterede anmodning  .
 leverer_id – En henvisning til leverer  tabel, der angiver tjenesteudbyderen og den egenskab, der er inkluderet i denne handling.
 detaljer – Alle yderligere detaljer i struktureret tekstformat. Denne struktur kan omfatte tags og værdier, der beskriver anmodningsdetaljer. For en tur vil det betyde start- og slutpunktet, den tilbagelagte distance osv.
 starttid og sluttidspunkt – Den periode, hvor denne service blev leveret. Begge disse værdier indstilles, når tjenesten lige er startet og afsluttet.
 grade_customer og grade_provider – Karakterer givet af kunden og tjenesteudbyderen for den pågældende tjeneste.
 
 
 Den sidste tabel i vores model er fakturaen  bord. Vi opkræver kunder (customer_name). ) for de leverede tjenester (provided_service_id ). For hver faktura skal vi kende total_amount , eventuelle betalte gebyrer (fee_amount ), da fakturaen blev udstedt (tidspunkt_udstedt ), og hvornår det blev betalt (time_paid ) Det betalte felt fungerer som et flag, der angiver, om en faktura er blevet betalt. 
 Hvad synes du om vores delingsøkonomi-datamodel?
 
 I dag diskuterede vi en datamodel, der kunne bruges af en virksomhed som Airbnb eller Uber. Rygraden i en sådan forretningsmodel er kunderne og serviceudbyderne. Der er en række detaljer, jeg kunne tilføje til denne model. Alligevel besluttede jeg mig for ikke at gøre det, fordi modellen hurtigt ville blive for stor. Synes du, jeg skulle have tilføjet noget? Hvis ja, så fortæl mig venligst i kommentarerne nedenfor.