Hasilkan Uang dengan Barang yang Tidak Digunakan:Model Data Ekonomi Berbagi

Tidak banyak kemungkinan Anda melewatkan seluruh gagasan tentang ekonomi berbagi – suka atau tidak suka. Dipopulerkan oleh perusahaan seperti Airbnb, Uber, Lyft, dan banyak lainnya, ini memungkinkan orang mendapatkan uang dengan menyewakan barang-barang mereka yang tidak terpakai. Mari kita lihat model data di balik aplikasi semacam itu.

Punya kamar cadangan? Daftar dengan Airbnb dan dapatkan uang tambahan dengan menyewakannya. Punya mobil dan waktu luang? Menjadi pengemudi Uber. Dan begitulah – ide di balik perusahaan-perusahaan ini dan banyak lagi seperti mereka hampir sama. Ini semua tentang berbagi sumber daya dengan (kebanyakan) orang asing, dengan keuntungan bagi kedua belah pihak. Pemilik mendapatkan uang untuk properti yang tidak terpakai, sementara pelanggan biasanya mendapat banyak; ini harus menjadi situasi win-win.

Tentu saja, kami membutuhkan platform untuk menghubungkan pemilik dengan pelanggan dan untuk melacak detail penting. Hari ini, kami akan menyajikan model data yang dapat mengelola tugas. Bersantailah di kursi Anda dan nikmati perjalanan melalui model data ekonomi berbagi.

Apa yang Kita Butuhkan dalam Model Data Kita?

Gagasan untuk menyewakan properti saat kita tidak menggunakannya tampaknya sangat bijaksana. Pertama, properti digunakan untuk tujuan yang dimaksudkan; kedua, sewa akan menghasilkan semacam pendapatan tambahan. Itu bisa berupa uang tunai, tetapi juga bisa berupa pertukaran (misalnya, seseorang di New York bertukar apartemen dengan seseorang di Paris selama seminggu).

Model cashless sangat keren dan biasanya bergantung pada saling pengertian, niat baik, dan kejujuran. Namun, artikel ini akan fokus pada model ekonomi berbagi yang membutuhkan pembayaran. Memang tidak seromantis model cashless, tapi model pembayarannya cukup efektif.

Kami membutuhkan cara yang sangat sederhana bagi sejumlah besar pemilik properti untuk menjangkau sejumlah besar pelanggan yang tertarik dan sebaliknya. Ini adalah persyaratan pertama untuk model data kami. Kami akan memiliki akun pengguna dan setidaknya dua peran berbeda – pemilik dan pelanggan.

Hal berikutnya yang kita butuhkan adalah aplikasi kita membuat daftar semua properti yang tersedia. Untuk Airbnb, ini akan menjadi apartemen; untuk Uber, ini adalah mobil. Artikel ini akan lebih fokus pada menyewa apartemen (model data seperti Airbnb) tetapi saya akan membuat modelnya cukup umum sehingga dapat dengan mudah dikonversi ke layanan ekonomi-berbagi lainnya yang diinginkan.

Untuk setiap pemilik properti, kita perlu menentukan lokasi tempat mereka beroperasi. Untuk apartemen, ini cukup jelas (kota tempat apartemen berada). Untuk layanan transportasi, ini akan tergantung pada lokasi mobil dan/atau pemiliknya saat ini.

Untuk setiap properti atau sumber daya, kami perlu melacak periode penggunaan dan permintaan/reservasi. Ini akan memungkinkan kami untuk menemukan properti yang tersedia saat permintaan baru diajukan dan untuk menghitung tingkat hunian dan harga. Kami juga dapat menggunakan program lain untuk menganalisis data ini dan menghasilkan statistik lainnya.

Model Data

Model data terdiri dari lima bidang subjek:

Negara &kota
Pengguna &peran
Layanan &dokumen
Permintaan
Layanan yang disediakan

Kami akan menyajikan setiap bidang subjek dalam urutan yang sama seperti yang tercantum.

Bagian 1:Negara dan kota

Kita akan mulai dengan Negara &kota bidang studi. Meskipun tidak spesifik untuk model data ini, tabel ini sangat penting. Layanan terkait properti biasanya berorientasi geografis. Model kami terkait erat dengan menyewakan beberapa jenis tempat tinggal, jadi lokasi fisik sangat penting di sini. Tentu saja, lokasi itu biasanya tidak akan berubah. Ada beberapa kasus khusus yang dapat mengakibatkan perubahan lokasi properti, tetapi saya akan memperlakukan hunian di lokasi barunya sebagai properti yang sama sekali baru.

Untuk aplikasi mobil dan/atau pengemudi seperti Uber, lokasi mobil dan pengemudi saat ini juga sangat penting. Tidak seperti persewaan apartemen bergaya Airbnb, lokasi properti ini dapat sering berubah.

Negara tabel berisi daftar nama UNIK negara tempat kami beroperasi. Kota tabel berisi daftar semua kota tempat kami beroperasi. Kombinasi UNIK untuk tabel ini adalah kombinasi dari postal_code , nama_kota , dan count_id atribut.

Kedua tabel ini dapat berisi banyak atribut tambahan, tetapi saya sengaja menghilangkannya karena tidak akan menambah nilai apa pun pada model ini.

Bagian 2:Pengguna dan Peran

Hal berikutnya yang perlu kita lakukan adalah mendefinisikan pengguna dan perilaku atau peran mereka dalam aplikasi kita. Untuk melakukannya, kita akan menggunakan tiga tabel di Pengguna &peran bidang subjek.

Daftar semua pengguna ada di user_account meja. Untuk setiap pengguna, kami akan menyimpan detail berikut:

nama_pengguna – Nama UNIK yang dipilih pengguna untuk mengakses aplikasi kita.
sandi – Nilai hash dari kata sandi yang dipilih oleh pengguna.
nama_depan dan nama_belakang – Nama depan dan belakang pengguna.
id_kota – Referensi ke kota tempat pengguna biasanya berada.
id_kota_saat ini – Referensi ke kota di mana pengguna saat ini berada.
email – Alamat email pengguna.
waktu_dimasukkan – Stempel waktu saat catatan ini dimasukkan ke dalam tabel.
confirmation_code – Kode yang dibuat selama proses pendaftaran untuk mengonfirmasi alamat email pengguna.
waktu_konfirmasi – Stempel waktu ketika alamat email dikonfirmasi. Atribut ini berisi nilai NULL hingga konfirmasi berhasil.

Pengguna akan memiliki hak yang berbeda dalam aplikasi sesuai dengan perannya. Mungkin juga satu pengguna dapat memiliki lebih dari satu peran aktif secara bersamaan, mis. mereka bisa menjadi pemilik satu properti dan pelanggan properti lain. Dalam hal ini, pengguna akan menggunakan detail login yang sama dan akan memiliki opsi untuk beralih di antara peran. Setiap peran akan memiliki layarnya sendiri di aplikasi.

Daftar semua kemungkinan peran disimpan di role kamus. Setiap peran secara UNIK ditentukan oleh role_name its . Demi kesederhanaan, kita hanya dapat mengharapkan dua peran:“pemilik properti” dan “pelanggan”.

Seorang pengguna dapat memiliki peran yang sama yang ditetapkan beberapa kali selama periode yang berbeda. Salah satu kasus tersebut adalah jika pengguna menyewa apartemen yang tidak terpakai dan kemudian memutuskan untuk tidak menyewa apartemen mereka karena mereka membutuhkannya. Namun, setelah beberapa bulan, pengguna yang sama memutuskan untuk menyewa apartemen mereka lagi. Dalam hal ini, kami akan menonaktifkan peran mereka dan kemudian mengaktifkannya kembali.

Daftar semua peran yang pernah ditetapkan ke pengguna disimpan di has_role meja. Untuk setiap record dalam tabel ini kami akan menyimpan:

user_account_id – ID dari pengguna terkait .
role_id – ID dari peran terkait .
waktu_dari – Stempel waktu saat peran ini dimasukkan ke dalam sistem.
time_to – Stempel waktu saat peran ini dinonaktifkan. Ini akan berisi nilai NULL selama peran masih aktif.
is_aktif – Disetel ke False saat peran dinonaktifkan karena alasan apa pun.

Saat menyisipkan catatan baru dalam tabel ini, kita harus memeriksa catatan yang tumpang tindih. Ini memungkinkan kita untuk menghindari membuat peran yang sama berlaku dua kali selama periode yang sama.

Bagian 3:Layanan dan Dokumen

Hal berikutnya yang perlu kita definisikan adalah layanan yang disediakan oleh pengguna. Kami juga perlu melacak dokumen terkait. Untuk melakukannya, kita memerlukan tabel di Layanan &dokumen bidang subjek.

Mari kita mulai dengan properti meja. Properti adalah apa pun objek dari layanan kami:tempat tinggal, mobil, sepeda, dll. Kami dapat berharap bahwa pengguna akan mengurus properti mereka sendiri. Untuk setiap properti, kita perlu mendefinisikan:

nama_properti – Nama layar untuk properti itu, dipilih oleh pengguna. Nama ini digunakan saat menampilkan properti kepada calon pelanggan di aplikasi. Itu harus singkat dan deskriptif dan membedakan properti itu dari properti lain.
deskripsi_properti – Deskripsi tekstual tambahan dalam format tidak terstruktur. Kami dapat mengharapkan banyak detail di sini – pada dasarnya semuanya mulai dari ukuran apartemen hingga apakah pelanggan akan mendapatkan minuman selamat datang saat mereka tiba. Minuman selamat datang di layanan transportasi jauh lebih kecil kemungkinannya untuk terjadi.
active_from dan active_to – Jangka waktu ketika properti itu aktif di sistem kami. active_to atribut akan berisi nilai NULL sampai properti dinonaktifkan.
is_available – Bendera yang menunjukkan apakah properti ini tersedia pada waktu tertentu atau tidak.
is_aktif – Bendera yang menunjukkan jika properti itu masih aktif di sistem kami. Nilai atribut ini akan disetel ke False pada saat yang sama active_to telah disetel.

Sekarang kita akan pindah ke layanan kamus. Di sinilah kami akan menentukan semua jenis layanan yang mungkin, seperti "sewa jangka panjang", "sewa jangka pendek", "transportasi", dll. Ini berisi nama UNIK dari jenis layanan dan deskripsi tambahan. kode> , jika diperlukan.

 
 Kami akan menyimpan properti, layanan, dan pengguna terkait di penyediaan  meja. Ini akan menyimpan periode ketika properti tersedia. Dalam hal transportasi, ini akan memberi tahu kami kapan mobil dan pengemudi benar-benar bekerja untuk perusahaan kami. Dalam kasus persewaan apartemen, ini akan memberi tahu kami kapan properti tersedia. Untuk setiap record di sini, kita akan memiliki:
  user_account_id – ID pengguna yang menyediakan layanan tersebut.
 service_id – ID layanan  jenis yang disediakan.
 id_properti – Merujuk pada properti  digunakan.
 waktu_dari dan time_to – Ketika properti ini digunakan untuk menyediakan layanan ini. time_to atribut akan berisi nilai NULL sampai catatan ini dinonaktifkan.
 is_aktif – Disetel ke False setelah properti ini tidak akan digunakan lagi atau saat pengguna ini akan berhenti menyediakan layanan ini. Ini disetel pada saat yang sama ketika time_to telah disetel.
 
 
 Dua tabel yang tersisa di area subjek ini terkait dengan dokumen. (Tabel user_account hanyalah salinan dari aslinya, digunakan di sini untuk menghindari hubungan yang tumpang tindih.) Perusahaan kami akan bekerja dengan banyak pemilik properti dan hampir tidak ada kesempatan untuk memeriksa semuanya secara langsung. Salah satu cara untuk memastikan kualitas layanan adalah dengan mendokumentasikan semuanya dengan baik.
 
 Tabel pertama yang terkait dengan dokumen adalah document_type  meja. Kamus sederhana ini berisi daftar type_name UNIK nilai-nilai. Kami dapat mengharapkan nilai seperti "gambar properti" dan "ID pemilik" di sini.
 
 Daftar semua dokumen disimpan di document  meja. Dokumen ini dapat terkait dengan akun pengguna, properti, atau keduanya. Untuk setiap dokumen, kami akan menyimpan:
  lokasi_dokumen – Jalur lengkap ke dokumen itu.
 document_type_id – Referensi ke document_type  kamus.
 user_account_id – Referensi ke user_account  meja. Atribut ini hanya akan menyimpan nilai bila dokumen terkait dengan pengguna atau jika dokumen terkait dengan properti tetapi pengguna juga memiliki properti tersebut.
 id_properti – Referensi ke properti terkait .
 is_aktif – Menandakan apakah dokumen ini masih aktif (valid) atau tidak.
 
 Bagian 4:Permintaan
   
 
 Sebelum kami dapat menyediakan layanan apa pun, kami perlu mendapatkan beberapa permintaan pengguna. Dalam persewaan apartemen, pelanggan akan mengajukan permintaan untuk properti yang diinginkan setelah mereka mencari di daftar dan menemukan tempat tinggal yang mereka inginkan. Dalam hal layanan transportasi, permintaan diajukan oleh pelanggan melalui aplikasi seluler (misalnya mereka berada di bandara dan membutuhkan tumpangan dalam 20 menit). Kami akan berbicara tentang bagaimana kami memproses permintaan di bagian berikutnya; untuk saat ini, mari kita lihat bagaimana kita mengelolanya.
 
 Tabel pusat di area subjek ini adalah permintaan  meja. Untuk setiap permintaan, kami akan menyimpan:
  has_role_id – Referensi ke pengguna (dan perannya saat ini, melalui has_role  table) yang membuat permintaan itu.
 request_status_id – Referensi ke status permintaan saat ini.
 status_time – Stempel waktu saat status itu ditetapkan.
 service_id – ID layanan  diperlukan dengan permintaan itu.
 id_kota – Referensi ke kota  di mana layanan ini diperlukan.
 request_details – Semua detail permintaan tambahan, dalam format tekstual tidak terstruktur.
 sudah_diproses – Bendera yang menunjukkan jika permintaan ini telah diproses (yaitu ditetapkan ke penyedia layanan).
 is_aktif – Tanda ini akan disetel ke Salah hanya jika pelanggan membatalkan permintaannya atau jika permintaan dibatalkan oleh aplikasi karena alasan tertentu.
 
 
 Daftar semua kemungkinan status disimpan di request_status  kamus dengan status_name sebagai nilai UNIK (dan satu-satunya). Kita dapat mengharapkan nilai seperti “permintaan ditempatkan”, “properti dicadangkan”, “ditugaskan ke pengemudi”, “perjalanan sedang berlangsung”, dan “selesai”.
 
 request_status_history  tabel akan menyimpan riwayat semua status yang terkait dengan permintaan. Untuk setiap record dalam tabel ini, kami akan menyimpan ID permintaan terkait (request_id ), ID status (request_status_id ), ID akun pengguna dan peran yang dimiliki pengguna saat mereka menetapkan status tersebut (has_role_id ). Kami juga akan mencatat kapan setiap status ditetapkan (status_time ).
 Bagian 5:Layanan yang Diberikan
   
 
 Setelah permintaan ditempatkan, kita perlu memprosesnya. Permintaan akan secara otomatis diberikan ke penyedia layanan yang sesuai (berdasarkan jenis layanan yang diminta, lokasi, dll.) atau akan diterima secara manual oleh penyedia layanan. Kami hanya membutuhkan dua tabel lagi untuk menangani ini.
 
 Pertama adalah provided_service  meja. Untuk setiap catatan, kami akan menyertakan:
  request_id – ID dari permintaan terkait  .
 provides_id – Referensi ke menyediakan  tabel yang menunjukkan penyedia layanan dan properti yang disertakan dalam tindakan ini.
 detail – Semua detail tambahan, dalam format tekstual terstruktur. Struktur ini dapat menyertakan tag dan nilai yang menjelaskan detail permintaan. Untuk perjalanan, ini berarti titik awal dan akhir, jarak yang ditempuh, dll.
 waktu_mulai dan end_time – Periode selama layanan ini diberikan. Kedua nilai ini akan disetel saat layanan baru saja dimulai dan berakhir.
 kelas_pelanggan dan grade_provider – Nilai yang diberikan oleh pelanggan dan penyedia layanan untuk layanan tersebut.
 
 
 Tabel terakhir dalam model kami adalah faktur  meja. Kami akan menagih pelanggan (customer_name ) untuk layanan yang disediakan (provided_service_id ). Untuk setiap faktur, kita perlu mengetahui total_amount , semua biaya yang dibayarkan (fee_amount ), saat faktur diterbitkan (time_issued ), dan saat dibayar (time_paid ) Bidang dibayar berfungsi sebagai bendera yang menunjukkan jika faktur telah dibayar. 
 Apa Pendapat Anda Tentang Model Data Ekonomi Berbagi Kami?
 
 Hari ini kita membahas model data yang dapat digunakan oleh perusahaan seperti Airbnb atau Uber. Tulang punggung model bisnis seperti itu adalah pelanggan dan penyedia layanan. Ada beberapa detail yang bisa saya tambahkan ke model ini. Namun, saya memutuskan untuk tidak melakukannya karena modelnya akan cepat menjadi terlalu besar. Apakah Anda pikir saya harus menambahkan sesuatu? Jika demikian, beri tahu saya di komentar di bawah.