Verdien geld met ongebruikte spullen:een gegevensmodel in de deeleconomie

Er is niet veel kans dat je het hele idee van de deeleconomie hebt gemist - of je het nu leuk vindt of niet. Gepopulariseerd door bedrijven zoals Airbnb, Uber, Lyft en vele anderen, kunnen mensen wat geld verdienen door hun ongebruikte spullen te verhuren. Laten we eens kijken naar het datamodel achter zo'n applicatie.

Heb je een logeerkamer? Meld je aan bij Airbnb en verdien wat extra geld door het te verhuren. Heb je een auto en wat vrije tijd? Word een Uber-chauffeur. En zo gaat het - het idee achter deze bedrijven en nog veel meer zoals zij is bijna hetzelfde. Het draait allemaal om het delen van een bron met (meestal) vreemden, met een voordeel voor beide partijen. De eigenaar krijgt geld voor zijn ongebruikte eigendom, terwijl de klant meestal een goede deal krijgt; dit zou een win-winsituatie moeten zijn.

Natuurlijk hebben we een platform nodig om eigenaren met klanten in contact te brengen en belangrijke details bij te houden. Vandaag presenteren we een gegevensmodel dat de taak zou kunnen beheren. Neem plaats in uw stoel en geniet van de rit door het datamodel van de deeleconomie.

Wat hebben we nodig in ons gegevensmodel?

Het idee om onroerend goed te verhuren wanneer we het niet gebruiken, lijkt erg verstandig. Ten eerste wordt het onroerend goed gebruikt voor het beoogde doel; ten tweede zal de huur een soort van extra inkomsten genereren. Dat kan contant geld zijn, maar kan ook een ruil zijn (bijvoorbeeld iemand in New York die een week van appartement ruilt met iemand in Parijs).

Cashless-modellen zijn echt cool en ze zijn meestal afhankelijk van wederzijds begrip, goodwill en eerlijkheid. Dit artikel zal zich echter richten op deeleconomiemodellen waarvoor betaling vereist is. Het is niet zo romantisch als modellen zonder contant geld, maar het betalingsmodel is behoorlijk effectief.

We hebben een heel eenvoudige manier nodig voor een groot aantal eigenaren van onroerend goed om een groot aantal geïnteresseerde klanten te bereiken en vice versa. Dit is de eerste vereiste voor ons datamodel. We hebben gebruikersaccounts en ten minste twee verschillende rollen:eigenaar en klant.

Het volgende dat we nodig hebben, is dat onze app alle beschikbare eigenschappen weergeeft. Voor Airbnb zouden dit appartementen zijn; voor Uber zouden dit auto's zijn. Dit artikel zal meer focussen op het huren van appartementen (een Airbnb-achtig datamodel), maar ik zal het model algemeen genoeg houden zodat het gemakkelijk kan worden omgezet naar een andere gewenste deeleconomiedienst.

Voor elke eigenaar van een onroerend goed moeten we de locatie definiëren waar ze actief zijn. Voor appartementen is dit vrij duidelijk (de stad waar het appartement zich bevindt). Voor vervoersdiensten is dit afhankelijk van de huidige locatie van de auto en/of de eigenaar.

Voor elke eigenschap of bron moeten we gebruiksperioden en verzoeken/reserveringen bijhouden. Dit stelt ons in staat om beschikbare woningen te vinden wanneer een nieuwe aanvraag wordt geplaatst en om de bezettingsgraad en prijs te berekenen. We kunnen ook andere programma's gebruiken om deze gegevens te analyseren en andere statistieken te produceren.

Het gegevensmodel

Het datamodel bestaat uit vijf vakgebieden:

Countries & cities
Users & roles
Services & documents
Requests
Provided services

We presenteren elk onderwerp in dezelfde volgorde waarin het wordt vermeld.

Sectie 1:Landen en steden

We beginnen met de Countries & cities gebied. Hoewel niet specifiek voor dit datamodel, zijn deze tabellen erg belangrijk. Vastgoedgerelateerde dienstverlening is doorgaans geografisch georiënteerd. Ons model is nauw verwant aan het huren van een woning, dus de fysieke locatie is hier cruciaal. Natuurlijk verandert die locatie meestal niet. Er zijn enkele zeer speciale gevallen die ertoe kunnen leiden dat de locatie van een onroerend goed verandert, maar ik zou die woning op de nieuwe locatie als een volledig nieuw onroerend goed behandelen.

Voor auto- en/of chauffeurs-apps zoals Uber is ook de huidige locatie van de auto en chauffeur erg belangrijk. In tegenstelling tot verhuur van appartementen in Airbnb-stijl, kunnen deze locaties vaak veranderen.

Het country tabel bevat een lijst met UNIEKE namen van de landen waar we actief zijn. De city tabel bevat een lijst van alle steden waar we actief zijn. De UNIEKE combinatie voor deze tabel is de combinatie van postal_code , city_name , en country_id attributen.

Beide tabellen kunnen veel extra attributen bevatten, maar ik heb ze opzettelijk weggelaten omdat ze geen waarde toevoegen aan dit model.

Sectie 2:Gebruikers en rollen

Het volgende dat we moeten doen, is gebruikers en hun gedrag of rollen in onze applicatie definiëren. Om dit te doen, gebruiken we de drie tabellen in de Users & roles onderwerpgebied.

Een lijst van alle gebruikers staat in het user_account tafel. Voor elke gebruiker slaan we de volgende gegevens op:

user_name - De UNIEKE naam die de gebruiker heeft gekozen om toegang te krijgen tot onze applicatie.
password – Een hash-waarde van het wachtwoord gekozen door de gebruiker.
first_name en last_name – De voor- en achternaam van de gebruiker.
city_id – Een verwijzing naar de city waar de gebruiker zich gewoonlijk bevindt.
current_city_id – Een verwijzing naar de city waar de gebruiker zich momenteel bevindt.
email – Het e-mailadres van de gebruiker.
time_inserted – Het tijdstempel waarop dit record in de tabel is ingevoegd.
confirmation_code – Een code gegenereerd tijdens het registratieproces om het e-mailadres van de gebruiker te bevestigen.
time_confirmed – Het tijdstempel waarop het e-mailadres is bevestigd. Dit attribuut bevat een NULL-waarde totdat de bevestiging doorgaat.

De gebruiker heeft verschillende rechten in de toepassing, afhankelijk van zijn rol. Het is ook mogelijk dat één gebruiker meer dan één actieve rol tegelijk kan hebben, b.v. ze kunnen de eigenaar zijn van het ene onroerend goed en de klant van een ander onroerend goed. In dat geval gebruikt de gebruiker dezelfde inloggegevens en heeft hij de mogelijkheid om tussen rollen te wisselen. Elke rol heeft zijn eigen scherm in de app.

Een lijst met alle mogelijke rollen wordt opgeslagen in de role woordenboek. Elke rol wordt UNIEK gedefinieerd door zijn role_name . Omwille van de eenvoud kunnen we slechts twee rollen verwachten:"eigendomseigenaar" en "klant".

Aan een gebruiker kan dezelfde rol meerdere keren worden toegewezen tijdens verschillende perioden. Een dergelijk geval zou zijn als de gebruiker zijn ongebruikte appartement huurde en vervolgens besloot zijn appartement niet te huren omdat hij het nodig had. Echter, na een paar maanden besloot dezelfde gebruiker zijn appartement opnieuw te verhuren. In dit geval zouden we hun rol deactiveren en vervolgens opnieuw activeren.

Een lijst met alle rollen die ooit aan gebruikers zijn toegewezen, wordt opgeslagen in de has_role tafel. Voor elk record in deze tabel slaan we op:

user_account_id – De ID van de gerelateerde user .
role_id – De ID van de gerelateerde role .
time_from – Het tijdstempel wanneer deze rol in het systeem is ingevoegd.
time_to – Het tijdstempel waarop deze rol is gedeactiveerd. Dit zal een NULL-waarde bevatten zolang de rol nog actief is.
is_active – Is ingesteld op False wanneer de rol om welke reden dan ook is gedeactiveerd.

Bij het invoegen van een nieuw record in deze tabel moeten we controleren op overlappende records. Hierdoor kunnen we voorkomen dat dezelfde rol twee keer geldig is in dezelfde periode.

Sectie 3:Diensten en documenten

Het volgende dat we moeten definiëren, zijn de services die door gebruikers worden geleverd. We moeten ook alle gerelateerde documenten bijhouden. Om dat te doen, hebben we de tabellen nodig in de Services & documents onderwerpgebied.

Laten we beginnen met de property tafel. Vastgoed is wat het object van onze dienstverlening ook is:woningen, auto's, fietsen, etc. We kunnen verwachten dat gebruikers zelf voor hun eigendommen zorgen. Voor elke eigenschap moeten we het volgende definiëren:

property_name – De schermnaam voor die eigenschap, gekozen door de gebruiker. Deze naam wordt gebruikt bij het weergeven van de woning aan potentiële klanten in de app. Het moet kort en beschrijvend zijn en die eigenschap onderscheiden van andere eigenschappen.
property_description – Aanvullende tekstuele beschrijving in ongestructureerd formaat. We kunnen hier een heleboel details verwachten - eigenlijk alles, van de grootte van het appartement tot of klanten een welkomstdrankje krijgen als ze aankomen. Welkomstdrankjes in vervoersdiensten zijn veel minder waarschijnlijk.
active_from en active_to – De periode waarin die eigenschap actief was in ons systeem. De active_to attribuut zal NULL-waarde bevatten totdat de eigenschap wordt gedeactiveerd.
is_available – Een vlag die aangeeft of deze eigenschap op een bepaald tijdstip beschikbaar is of niet.
is_active – Een vlag die aangeeft of die eigenschap nog steeds actief is in ons systeem. De waarde van dit kenmerk wordt op hetzelfde moment ingesteld op False active_to is ingesteld.

We gaan nu over op de service woordenboek. Hier definiëren we alle mogelijke soorten diensten, zoals “lange termijn huur”, “korte termijn huur”, “transport” enz. Het bevat de UNIEKE naam van het type dienst en een aanvullende description , indien nodig.

We houden gerelateerde eigendommen, services en gebruikers in de provides tafel. Het slaat perioden op waarin een woning beschikbaar was. In het geval van transport zou dit ons vertellen wanneer een auto en chauffeur daadwerkelijk voor ons bedrijf werkten. In het geval van appartementverhuur, zou het ons vertellen wanneer een woning beschikbaar was. Voor elk record hier hebben we:

user_account_id – De ID van de gebruiker die die dienst levert.
service_id – De ID van de service type opgegeven.
property_id – Verwijst naar de property gebruikt.
time_from en time_to – Wanneer deze woning werd gebruikt om deze dienst te verlenen. De time_to attribuut zal een NULL-waarde bevatten totdat dit record wordt gedeactiveerd.
is_active – Is ingesteld op False zodra deze eigenschap niet meer wordt gebruikt of wanneer deze gebruiker stopt met het leveren van deze service. Dit wordt ingesteld op hetzelfde moment dat time_to is ingesteld.

De overige twee tabellen in dit onderwerp hebben betrekking op documenten. (De user_account tabel is slechts een kopie van het origineel en wordt hier gebruikt om te voorkomen dat relaties elkaar overlappen.) Ons bedrijf zal met veel eigenaren van onroerend goed werken en er zal bijna geen kans zijn om alles persoonlijk te controleren. Een manier om de kwaliteit van de service te garanderen, is door alles goed te documenteren.

De eerste tabel met betrekking tot documenten is de document_type tafel. Dit eenvoudige woordenboek bevat een lijst met UNIEKE type_name waarden. We kunnen hier waarden als 'eigendomsfoto' en 'eigenaar-ID' verwachten.

Een lijst van alle documenten wordt opgeslagen in het document tafel. Deze documenten kunnen verband houden met gebruikersaccounts, eigendommen of beide. Voor elk document slaan we op:

document_location – Het volledige pad naar dat document.
document_type_id – Een verwijzing naar het document_type woordenboek.
user_account_id – Een verwijzing naar het user_account tafel. Dit kenmerk heeft alleen een waarde als het document gerelateerd is aan de gebruiker of als het document gerelateerd is aan de eigenschap, maar de gebruiker ook eigenaar is van die eigenschap.
property_id – Een verwijzing naar de gerelateerde eigenschap .
is_active – Geeft aan of dit document nog steeds actief (geldig) is of niet.

Sectie 4:Verzoeken

Voordat we een service kunnen bieden, moeten we enkele gebruikersverzoeken ontvangen. Bij appartementverhuur zal de klant zijn aanvraag voor de gewenste woning plaatsen nadat ze de aanbiedingen hebben doorzocht en de woning hebben gevonden die ze willen. In het geval van vervoersdiensten worden verzoeken door klanten geplaatst via een mobiele applicatie (ze zijn bijvoorbeeld op de luchthaven en hebben binnen 20 minuten een rit nodig). We zullen het hebben over hoe we verzoeken verwerken in de volgende sectie; laten we voor nu eens kijken hoe we ze beheren.

De centrale tabel in dit onderwerpgebied is het request tafel. Voor elk verzoek slaan we op:

has_role_id – Een verwijzing naar de gebruiker (en zijn huidige rol, via de has_role tafel) die dat verzoek heeft gedaan.
request_status_id – Een verwijzing naar de huidige status van dat verzoek.
status_time – Het tijdstempel waarop die status werd toegekend.
service_id – De ID van de service vereist bij dat verzoek.
city_id – Een verwijzing naar de city waar deze service vereist is.
request_details – Alle aanvullende verzoekdetails, in ongestructureerd tekstueel formaat.
is_processed – Een vlag die aangeeft of dit verzoek is verwerkt (d.w.z. toegewezen aan de serviceprovider).
is_active – Deze vlag wordt alleen op False gezet als een klant zijn verzoek heeft geannuleerd of als het verzoek om de een of andere reden door de app is geannuleerd.

Een lijst met alle mogelijke statussen wordt opgeslagen in de request_status woordenboek met status_name als de UNIEKE (en enige) waarde. We kunnen waarden verwachten als "verzoek geplaatst", "eigendom gereserveerd", "toegewezen aan bestuurder", "rijden in uitvoering" en "voltooid".

De request_status_history tabel zal de geschiedenis van alle statussen met betrekking tot verzoeken opslaan. Voor elk record in deze tabel slaan we de ID van het gerelateerde verzoek op (request_id ), de status-ID (request_status_id ), de gebruikersaccount-ID en de rol die de gebruiker had toen ze die status instelden (has_role_id ). We registreren ook wanneer elke status is toegewezen (status_time ).

Sectie 5:Geleverde diensten

Nadat het verzoek is geplaatst, moeten we het verwerken. Een verzoek wordt ofwel automatisch toegewezen aan de juiste serviceprovider (op basis van het gevraagde servicetype, locatie, enz.) of het wordt handmatig geaccepteerd door de serviceprovider. We hebben nog maar twee tafels nodig om dit te verwerken.

De eerste is de provided_service tafel. Voor elk record nemen we het volgende op:

request_id – De ID van het gerelateerde request .
provides_id – Een verwijzing naar de provides tabel die de serviceprovider en de eigenschap aangeeft die in deze actie zijn opgenomen.
details – Alle aanvullende details, in gestructureerd tekstueel formaat. Deze structuur kan tags en waarden bevatten die verzoekdetails beschrijven. Voor een rit zou dit het begin- en eindpunt, de afgelegde afstand, enz. betekenen.
start_time en end_time – De periode waarin deze dienst is verleend. Beide waarden worden ingesteld wanneer de service net is gestart en beëindigd.
grade_customer en grade_provider – Cijfers gegeven door de klant en de dienstverlener voor die dienst.

De laatste tabel in ons model is de invoice tafel. We brengen kosten in rekening bij klanten (customer_name ) voor de geleverde diensten (provided_service_id ). Voor elke factuur moeten we het total_amount . weten , eventuele betaalde vergoedingen (fee_amount ), wanneer de factuur is uitgegeven (time_issued ), en wanneer het werd betaald (time_paid ) Het veld betaald dient als vlag die aangeeft of een factuur is betaald.

Wat vindt u van ons gegevensmodel voor de deeleconomie?

Vandaag bespraken we een datamodel dat zou kunnen worden gebruikt door een bedrijf als Airbnb of Uber. De ruggengraat van een dergelijk businessmodel zijn de klanten en de dienstverleners. Er zijn een aantal details die ik aan dit model zou kunnen toevoegen. Toch besloot ik dat niet te doen omdat het model al snel te groot zou worden. Vind je dat ik iets had moeten toevoegen? Zo ja, vertel het me dan in de reacties hieronder.