Non ci sono molte possibilità che tu abbia perso l'intera idea dell'economia della condivisione, che ti piaccia o no. Reso popolare da aziende come Airbnb, Uber, Lyft e molte altre, consente alle persone di guadagnare denaro affittando le loro cose inutilizzate. Vediamo il modello di dati alla base di tale applicazione.
Hai una stanza libera? Iscriviti ad Airbnb e guadagna qualche soldo extra noleggiandolo. Hai una macchina e del tempo libero? Diventa un autista Uber. E così è:l'idea alla base di queste aziende e di molte altre simili è quasi la stessa. Si tratta di condividere una risorsa con (per lo più) estranei, con un vantaggio per entrambe le parti. Il proprietario riceve i soldi per la sua proprietà inutilizzata, mentre il cliente di solito ottiene un buon affare; questa dovrebbe essere una situazione vantaggiosa per tutti.
Ovviamente, abbiamo bisogno di una piattaforma per connettere i proprietari con i clienti e per tenere traccia dei dettagli importanti. Oggi presenteremo un modello di dati in grado di gestire l'attività. Mettiti comodo sulla sedia e goditi il viaggio attraverso il modello di dati sull'economia della condivisione.
Di cosa abbiamo bisogno nel nostro modello di dati?
L'idea di affittare una proprietà quando non la stiamo usando sembra molto saggia. In primo luogo, la proprietà viene utilizzata per lo scopo previsto; in secondo luogo, l'affitto genererà una sorta di reddito aggiuntivo. Potrebbe trattarsi di contanti, ma potrebbe anche essere uno scambio (ad esempio qualcuno a New York che scambia appartamenti con qualcuno a Parigi per una settimana).
I modelli senza contanti sono davvero fantastici e di solito dipendono dalla comprensione reciproca, dalla buona volontà e dall'onestà. Tuttavia, questo articolo si concentrerà sui modelli di sharing economy che richiedono un pagamento. Non è romantico come i modelli senza contanti, ma il modello di pagamento è piuttosto efficace.
Abbiamo bisogno di un modo molto semplice per consentire a un gran numero di proprietari di immobili di raggiungere un gran numero di clienti interessati e viceversa. Questo è il primo requisito per il nostro modello di dati. Avremo account utente e almeno due ruoli distinti:proprietario e cliente.
La prossima cosa di cui abbiamo bisogno è che la nostra app elenchi tutte le proprietà disponibili. Per Airbnb, questi sarebbero appartamenti; per Uber, queste sarebbero le auto. Questo articolo si concentrerà maggiormente sull'affitto di appartamenti (un modello di dati simile a Airbnb), ma manterrò il modello sufficientemente generale in modo che possa essere facilmente convertito in qualsiasi altro servizio di sharing economy desiderato.
Per ogni proprietario di proprietà, dovremo definire la posizione in cui operano. Per gli appartamenti, questo è abbastanza ovvio (la città in cui si trova l'appartamento). Per i servizi di trasporto, ciò dipenderà dalla posizione attuale dell'auto e/o dal suo proprietario.
Per ogni proprietà o risorsa, dovremo tenere traccia dei periodi di utilizzo e delle richieste/prenotazioni. Questo ci consentirà di trovare le proprietà disponibili quando viene inoltrata una nuova richiesta e di calcolare il tasso di occupazione e il prezzo. Potremo anche utilizzare altri programmi per analizzare questi dati e produrre altre statistiche.
Il modello dei dati
Il modello di dati è composto da cinque aree tematiche:
Paesi e cittàUtenti e ruoliServizi e documentiRichiesteServizi forniti
Presenteremo ogni area tematica nello stesso ordine in cui è elencata.
Sezione 1:Paesi e città
Inizieremo con i Paesi e città argomento. Sebbene non siano specifiche di questo modello di dati, queste tabelle sono molto importanti. I servizi relativi alla proprietà sono generalmente orientati geograficamente. Il nostro modello è strettamente correlato all'affitto di un qualche tipo di abitazione, quindi la posizione fisica è cruciale qui. Naturalmente, quella posizione di solito non cambia. Ci sono alcuni casi molto speciali che potrebbero comportare la modifica dell'ubicazione di una proprietà, ma tratterei quell'abitazione nella sua nuova posizione come una proprietà completamente nuova.
Per le app per auto e/o conducente come Uber, anche la posizione attuale dell'auto e del conducente è molto importante. A differenza degli appartamenti in affitto in stile Airbnb, la posizione di queste proprietà potrebbe cambiare frequentemente.
Il paese la tabella contiene un elenco di nomi UNICI dei paesi in cui operiamo. La città la tabella contiene un elenco di tutte le città in cui operiamo. La combinazione UNICA per questa tabella è la combinazione di codice_postale , nome_città e country_id attributi.
Entrambe queste tabelle potrebbero contenere molti attributi aggiuntivi, ma li ho omessi intenzionalmente perché non aggiungeranno alcun valore a questo modello.
Sezione 2:Utenti e ruoli
La prossima cosa che dobbiamo fare è definire gli utenti e i loro comportamenti o ruoli nella nostra applicazione. A tale scopo, utilizzeremo le tre tabelle in Utenti e ruoli area tematica.
Un elenco di tutti gli utenti si trova nel account_utente tavolo. Per ogni utente, memorizzeremo i seguenti dettagli:
nome_utente– Il nome UNICO che l'utente ha scelto per accedere alla nostra applicazione.password– Un valore hash della password scelta dall'utente.nomeecognome– Il nome e il cognome dell'utente.ID_città– Un riferimento allacittàdove si trova solitamente l'utente.current_city_id– Un riferimento allacittàdove si trova attualmente l'utente.e-mail– L'indirizzo email dell'utente.ora_inserita– Il timestamp in cui questo record è stato inserito nella tabella.codice_di_conferma– Un codice generato durante il processo di registrazione per confermare l'indirizzo email dell'utente.ora_confermata– Il timestamp di conferma dell'indirizzo e-mail. Questo attributo contiene un valore NULL fino al completamento della conferma.
L'utente avrà diritti diversi nell'applicazione in base al proprio ruolo. È anche possibile che un utente possa avere più di un ruolo attivo contemporaneamente, ad es. potrebbero essere il proprietario di una proprietà e il cliente di un'altra proprietà. In tal caso, l'utente utilizzerà gli stessi dettagli di accesso e avrà la possibilità di passare da un ruolo all'altro. Ogni ruolo avrà la propria schermata nell'app.
Un elenco di tutti i ruoli possibili è memorizzato nel ruolo dizionario. Ogni ruolo è UNICAMENTE definito dal suo role_name . Per semplicità, possiamo aspettarci solo due ruoli:"proprietario" e "cliente".
A un utente potrebbe essere assegnato lo stesso ruolo più volte in periodi diversi. Uno di questi casi sarebbe se l'utente stava affittando il proprio appartamento inutilizzato e poi decidesse di non affittare il proprio appartamento perché ne aveva bisogno. Tuttavia, dopo alcuni mesi, lo stesso utente ha deciso di affittare nuovamente il proprio appartamento. In questo caso, disattiveremo il loro ruolo e poi lo riattiveremo.
Un elenco di tutti i ruoli che sono stati assegnati agli utenti è archiviato in has_role tavolo. Per ogni record in questa tabella memorizzeremo:
user_account_id– L'ID del relativoutente.role_id– L'ID del relativoruolo.ora_da– Il timestamp in cui questo ruolo è stato inserito nel sistema.time_to– Il timestamp in cui questo ruolo è stato disattivato. Questo conterrà un valore NULL finché il ruolo è ancora attivo.è_attivo– Viene impostato su False quando il ruolo viene disattivato per qualsiasi motivo.
Quando si inserisce un nuovo record in questa tabella, è necessario verificare la presenza di record sovrapposti. Questo ci permette di evitare di rendere valido lo stesso ruolo due volte nello stesso periodo.
Sezione 3:Servizi e documenti
La prossima cosa che dobbiamo definire sono i servizi forniti dagli utenti. Dovremo anche tenere traccia di tutti i documenti correlati. Per farlo, avremo bisogno delle tabelle in Servizi e documenti area tematica.
Iniziamo con la proprietà tavolo. Le proprietà sono qualunque siano gli oggetti del nostro servizio:abitazioni, automobili, biciclette, ecc. Possiamo aspettarci che gli utenti si prendano cura delle proprie proprietà. Per ogni proprietà, dovremo definire:
nome_proprietà– Il nome della schermata per quella proprietà, scelto dall'utente. Questo nome viene utilizzato durante la visualizzazione della proprietà ai potenziali clienti nell'app. Dovrebbe essere breve e descrittivo e distinguere tale proprietà dalle altre proprietà.descrizione_proprietà– Descrizione testuale aggiuntiva in formato non strutturato. Possiamo aspettarci un sacco di dettagli qui, praticamente tutto, dalle dimensioni dell'appartamento al fatto che i clienti riceveranno un drink di benvenuto al loro arrivo. È molto meno probabile che si verifichino drink di benvenuto nei servizi di trasporto.attivo_daeactive_to– Il periodo di tempo in cui tale proprietà era attiva nel nostro sistema. Ilactive_tol'attributo conterrà il valore NULL finché la proprietà non sarà disattivata.è_disponibile– Un flag che indica se questa proprietà è disponibile in un momento specifico o meno.è_attivo– Un flag che indica se quella proprietà è ancora attiva nel nostro sistema. Il valore di questo attributo sarà impostato su False nello stesso momentoactive_toè impostato.
Passiamo ora al servizio dizionario. Qui è dove definiremo tutti i possibili tipi di servizi, come "affitto a lungo termine", "affitto a breve termine", "trasporto" ecc. Contiene il nome UNICO del tipo di servizio e una descrizione , se necessario.
Manterremo proprietà, servizi e utenti correlati nei forniture tavolo. Memorizzerà i periodi in cui una proprietà era disponibile. Nel caso del trasporto, questo ci direbbe quando un'auto e un autista stavano effettivamente lavorando per la nostra azienda. Nel caso di affitti di appartamenti, ci direbbe quando una proprietà era disponibile. Per ogni record qui, avremo:
user_account_id– L'ID dell'utente che fornisce quel servizio.id_servizio– L'ID delserviziotipo fornito.id_proprietà– Fa riferimento allaproprietàusato.ora_daetime_to– Quando questa proprietà è stata utilizzata per fornire questo servizio. Iltime_tol'attributo conterrà un valore NULL fino alla disattivazione di questo record.è_attivo– Viene impostato su False quando questa proprietà non verrà più utilizzata o quando l'utente smetterà di fornire questo servizio. Viene impostato nello stesso momento in cuitime_toè impostato.
Le restanti due tabelle in questa area tematica sono relative ai documenti. (La tabella user_account è solo una copia dell'originale, usata qui per evitare che le relazioni si sovrappongano.) La nostra azienda lavorerà con molti proprietari di immobili e non ci sarà quasi nessuna possibilità di controllare tutto di persona. Un modo per garantire la qualità del servizio è avere tutto ben documentato.
La prima tabella relativa ai documenti è il document_type tavolo. Questo semplice dizionario contiene un elenco di UNIQUE type_name valori. Possiamo aspettarci valori come "immagine della proprietà" e "ID proprietario" qui.
Un elenco di tutti i documenti è archiviato nel documento tavolo. Questi documenti potrebbero essere correlati ad account utente, proprietà o entrambi. Per ogni documento memorizzeremo:
posizione_documento– Il percorso completo di quel documento.ID_tipo_documento– Un riferimento aldocument_typedizionario.user_account_id– Un riferimento alaccount_utentetavolo. Questo attributo conterrà un valore solo quando il documento è correlato all'utente o se il documento è correlato alla proprietà ma l'utente possiede anche quella proprietà.id_proprietà– Un riferimento alla relativa proprietà .è_attivo– Indica se questo documento è ancora attivo (valido) o meno.
Sezione 4:Richieste
Prima di poter fornire qualsiasi servizio, dobbiamo ricevere alcune richieste degli utenti. Negli appartamenti in affitto, il cliente farà la sua richiesta per l'immobile desiderato dopo aver cercato negli annunci e aver trovato l'abitazione che desidera. Nel caso dei servizi di trasporto, le richieste vengono inoltrate dai clienti tramite applicazione mobile (es. sono in aeroporto e necessitano di un passaggio in 20 minuti). Parleremo di come elaboriamo le richieste nella prossima sezione; per ora vediamo come li gestiamo.
La tabella centrale in questa area tematica è la richiesta tavolo. Per ogni richiesta memorizzeremo:
ha_id_ruolo– Un riferimento all'utente (e al suo ruolo attuale, tramite ilhas_roletabella) che ha presentato tale richiesta.request_status_id– Un riferimento allo stato attuale di tale richiesta.stato_ora– Il timestamp in cui è stato assegnato lo stato.id_servizio– L'ID delserviziorichiesto con tale richiesta.ID_città– Un riferimento allacittàdove questo servizio è richiesto.richiesta_dettagli– Tutti i dettagli aggiuntivi della richiesta, in formato testuale non strutturato.è_elaborato– Un flag che indica se questa richiesta è stata elaborata (ovvero assegnata al fornitore di servizi).è_attivo– Questo flag verrà impostato su False solo se un cliente ha annullato la sua richiesta o se la richiesta è stata annullata dall'app per qualche motivo.
Un elenco di tutti i possibili stati è memorizzato in request_status dizionario con status_name come valore UNICO (e unico). Possiamo aspettarci valori come "richiesta inoltrata", "proprietà riservata", "assegnato al conducente", "guida in corso" e "completato".
Il request_status_history la tabella memorizzerà la cronologia di tutti gli stati relativi alle richieste. Per ogni record in questa tabella, memorizzeremo l'ID della relativa richiesta (request_id ), l'ID di stato (request_status_id ), l'ID account utente e il ruolo che l'utente aveva quando ha impostato tale stato (has_role_id ). Registreremo anche quando ogni stato è stato assegnato (status_time ).
Sezione 5:Servizi forniti
Dopo che la richiesta è stata inoltrata, dobbiamo elaborarla. Una richiesta verrà assegnata automaticamente al fornitore di servizi appropriato (in base al tipo di servizio richiesto, all'ubicazione, ecc.) oppure verrà accettata manualmente dal fornitore di servizi. Abbiamo bisogno solo di altre due tabelle per gestire questo.
Il primo è il servizio_fornito tavolo. Per ogni record, includeremo:
request_id– L'ID della relativarichiesta.fornisce_id– Un riferimento alforniscetabella che indica il fornitore del servizio e la proprietà inclusa in questa azione.dettagli– Tutti i dettagli aggiuntivi, in formato testuale strutturato. Questa struttura può includere tag e valori che descrivono i dettagli della richiesta. Per una corsa, questo significherebbe il punto di partenza e di arrivo, la distanza percorsa, ecc.ora_inizioeend_time– Il periodo durante il quale è stato fornito questo servizio. Entrambi questi valori verranno impostati quando il servizio è appena iniziato e terminato.grado_clienteegrade_provider– Gradi assegnati dal cliente e dal fornitore di servizi per quel servizio.
L'ultima tabella nel nostro modello è la fattura tavolo. Addebiteremo i clienti (customer_name ) per i servizi forniti (provided_service_id ). Per ogni fattura, dobbiamo conoscere il total_amount , eventuali commissioni pagate (fee_amount ), al momento dell'emissione della fattura (time_issued ) e quando è stato pagato (time_paid ) Il campo pagato funge da flag che indica se una fattura è stata pagata.
Cosa ne pensi del nostro modello di dati sull'economia della condivisione?
Oggi abbiamo discusso di un modello di dati che potrebbe essere utilizzato da un'azienda come Airbnb o Uber. La spina dorsale di un tale modello di business sono i clienti ei fornitori di servizi. Ci sono una serie di dettagli che potrei aggiungere a questo modello. Tuttavia, ho deciso di non farlo perché il modello sarebbe diventato rapidamente troppo grande. secondo voi avrei dovuto aggiungere qualcosa? Se è così, per favore dimmelo nei commenti qui sotto.
