Model Data Agen Real Estat

Selain lokasi, apa yang diperlukan untuk menjalankan bisnis real estat yang sukses? Kami memeriksa model data untuk membantu agen real estat tetap teratur.

Membeli, menjual, dan menyewakan apartemen atau rumah adalah bisnis yang sangat besar saat ini. Kebanyakan orang dengan senang hati membayar biaya dan membiarkan agen real estat profesional melakukan pekerjaan untuk mereka. Di sisi lain, perusahaan dapat bertindak atas namanya sendiri, membeli properti untuk dijual kembali atau disewakan. Perusahaan real estat juga dapat menyewakan properti kemudian menyewakan atau menyewakannya kembali dan menghasilkan keuntungan dari selisihnya.

Jelas, melacak properti adalah bagian penting dalam menjalankan bisnis real estat. Pada saat yang sama, tanggal sama pentingnya. (mis. Kapan apartemen sewaan akan tersedia? Kapan sebidang properti akan dipasarkan?) Dalam artikel ini, kita akan melihat model data yang dapat membantu perusahaan real estat tetap teratur.

FAQ Real Estat

Sebelum kita mulai menjelaskan model dan data yang diharapkan, pertama-tama kita akan menjawab beberapa pertanyaan khusus untuk bisnis real estat. Real estat memiliki banyak istilah dan penjelasan lengkap tentang jargon dan prinsipnya melampaui cakupan artikel ini, jadi kami hanya akan menjawab pertanyaan paling umum dan mendasar di sini.

Apa yang dapat dianggap sebagai perkebunan atau properti?

Ketika kita memikirkan real estat, gambaran pertama yang kita dapatkan sering kali adalah sebuah rumah atau tempat tinggal lainnya. Real estat jauh lebih dari itu. Bangunan, kantor, tanah, sumber daya mineral dan korps juga termasuk dalam kategori ini. Untuk tujuan artikel ini, saya akan memperlakukan segala sesuatu yang "tidak dapat dipindahkan" sebagai real estat. Karena itu, kami akan fokus terutama pada bangunan apartemen dan rumah.
Di manakah lokasi perkebunan atau properti?

Untuk rumah, gedung, dan apartemen ini sangat sederhana. Kami akan tahu alamat persisnya di mana properti itu berada. Tanah tidak memiliki alamat, tetapi posisinya ditentukan oleh pendaftaran tanah.
Data apa yang perlu kami simpan?

Dalam model kami, kami perlu menyimpan semua perkebunan (yaitu properti nyata) dan klien yang bekerja sama dengan kami. Kami membutuhkan informasi ini untuk membuat laporan dan juga untuk meningkatkan bisnis kami.

Kami dapat berharap bahwa kami akan sering berkomunikasi dengan klien, jadi kami harus menyimpan semua detail kontak mereka. Kami juga ingin mengetahui karyawan mana yang menghubungi klien dan minat apa yang diungkapkan klien selama percakapan.

Untuk properti, kami memerlukan detail dan status terkininya di ujung jari kami sehingga kami dapat menjawab pertanyaan calon pelanggan dengan cepat.

Kami juga akan menyimpan riwayat kontak kami dan kontrak apa pun yang terkait dengan klien atau properti.
Seberapa penting tanggal?

Tanggal selalu penting, tetapi saya ingin menekankan bahwa mereka sangat penting dalam real estat. Kami perlu mengetahui jumlah waktu yang tepat dari salah satu properti sewaan kami ditempati sehingga kami dapat menyewanya lagi segera setelah tersedia. Tidak boleh ada tumpang tindih ketika dua klien menyewa properti yang sama. Jika calon klien menyatakan keinginan untuk menyewa pada tanggal tertentu di masa mendatang, kami harus menyimpan informasi tersebut dan mendapatkan pengingat saat tanggal tersebut semakin dekat.
Seperti apa tampilan aplikasi kita?

Untuk tujuan ini, aplikasi web adalah solusi terbaik. Sebagian besar pekerjaan real estat berbasis kantor, tetapi agen penjualan harus dapat memasukkan data baru di mana pun mereka berada. Fungsi terpenting dalam aplikasi kami adalah pencarian cepat yang dapat menemukan klien, properti, dan status properti.

Model Data

Model data real estat kami terdiri dari tiga bidang subjek utama:

Estates and locations
Clients and contacts
Contracts and transactions

Ada satu meja, employee , yang berada di luar area subjek apa pun.

Harap perhatikan bahwa employee dan estate tabel di Clients and contacts area subjek dan client tabel di Contracts and transactions area subjek hanyalah salinan yang digunakan untuk menyederhanakan model.

Kita akan melihat employee tabel terlebih dahulu, lanjutkan dengan Estates and locations , pindah ke Clients and contacts , lalu selesaikan dengan Contracts and transactions .

Meja Karyawan

Kita akan mulai dengan employee meja. Sederhana:hanya menyimpan first_name dan last_name dari setiap karyawan. Kita dapat menambahkan detail lain seperti NPWP karyawan, tanggal lahir, alamat, peran pekerjaan, dll. Namun, dalam model ini kita tidak akan berfokus pada karyawan, jadi yang kita butuhkan hanyalah cara untuk mengaitkan karyawan dengan tindakan (seperti ditugaskan untuk tugas atau kontrak). Tabel ini juga memungkinkan kita merekam karyawan mana yang berpartisipasi dalam setiap kontak klien.

Bagian 1:Perkebunan dan Lokasi

Estates and locations area subjek berisi enam tabel yang menjelaskan semua perkebunan (properti) yang kami tangani, lokasinya, dan statusnya saat ini.

Tabel pusat di area subjek ini adalah estate meja. Ini berisi daftar semua perkebunan yang sedang, sedang, atau akan kami tangani. Ini termasuk perkebunan yang kami mediasi antara dua klien, yang kami miliki, semua yang kami jual atau sewakan kepada klien, dan semua yang kami sewa atau beli dari klien. Itu juga menyimpan catatan perkebunan yang kami rencanakan (atau rencanakan) untuk berbisnis dengan kami.

Karena kami berfokus terutama pada apartemen dan rumah dalam artikel ini, atribut dalam tabel ini sebagian besar terkait dengannya. Jika kita ingin mendeskripsikan jenis properti nyata lainnya, kita dapat menambahkan atribut deskriptif nullable tambahan. Kami juga dapat dengan mudah memasukkan nilai tersebut di estate_description atribut. Atribut di estate tabelnya adalah:

estate_name - Nama perkebunan. Ini bisa menjadi nama internal kami untuk sebuah properti (“Stoker house”) atau nama publik yang terkenal (“Bran Castle”).
city_id – ID kota tempat perkebunan itu berada.
estate_type_id – Merujuk pada estate_type kamus.
floor_space dan balconies_space – Ukuran (dalam meter persegi) lantai apartemen dan balkon.
number_of_balconies , number_of_bedrooms , number_of_garages dan number_of_parking_spaces – Nilai integer untuk setiap kategori. Cukup jelas.
pets_allowed – Nilai Boolean yang menunjukkan jika hewan peliharaan diperbolehkan. Ini sebagian besar digunakan untuk properti sewaan.
estate_description - Penjelasan rinci tentang sebuah perkebunan. Di sinilah kami menyimpan informasi tambahan, mis. sejarah properti.
estate_status_id – Jika sebuah perkebunan saat ini tersedia atau tidak. Kami akan menggunakan bidang ini dalam fungsi pencarian kami.

Kami telah menyebutkan dua kamus yang estate tabel mengacu pada, estate_type dan estate_status . Kedua kamus ini hanya berisi ID dan atribut nama UNIK.

Di estate_type kamus, kami akan menyimpan nilai seperti “apartemen”, “rumah”, “lapangan”, dll. estate_status tabel akan memiliki nilai yang menyatakan apakah properti saat ini tersedia atau tidak, seperti “estate disewakan”, “estate dibeli”, “estate dijual”, “estate disewa”.

Kami akan menentukan lokasi setiap perkebunan, tidak hanya dengan deskripsi (estate . estate_description atribut), tetapi juga oleh negara dan kotanya. Untuk tujuan ini, kami akan menggunakan dua tabel kamus:country dan city . Setiap negara secara unik ditentukan oleh country_name , yang akan menjadi satu-satunya atribut (selain ID) yang disimpan dalam tabel. Di sisi lain, setiap kota memiliki nama dan negara. Beberapa kota mungkin memiliki nama yang sama, tetapi kami akan berasumsi bahwa setiap nama kota unik untuk negaranya – hanya satu Wina, Austria atau Jenewa, Swiss. Namun, jika kita ingin melindungi dari duplikat, kita bisa menambahkan atribut region. Namun, untuk saat ini, kami akan membiarkan semuanya apa adanya. city_name – country_id pair adalah kunci UNIK city tabel.

Tabel terakhir di bidang subjek ini adalah in_charge meja. Kita dapat mengharapkan bahwa setiap perkebunan akan memiliki setidaknya satu karyawan yang ditugaskan untuk menangani hal-hal yang berkaitan dengannya. Karyawan ini bertanggung jawab untuk hal-hal seperti berkomunikasi dengan klien, menunjukkan warisan kepada calon klien, dan tugas administratif dan hukum lainnya. Dalam in_charge tabel, kita akan memiliki:

estate_id dan employee_id – Kunci asing yang masing-masing merujuk ke properti dan klien terkait.
date_from dan date_to – Interval saat karyawan ditugaskan ke perkebunan itu. Perhatikan bahwa "date_to" dapat menjadi NULL karena seorang karyawan dapat mengurus harta warisan tanpa batas waktu. Saat kita menugaskan seorang karyawan ke perkebunan, kita harus memastikan mereka belum ditugaskan ke perkebunan lain dengan memeriksa interval tanggal yang tumpang tindih. Di sisi lain, kami dapat menugaskan banyak karyawan ke perkebunan yang sama pada waktu yang bersamaan. Ini akan diinginkan ketika karyawan memiliki peran yang berbeda, mis. satu karyawan menangani komunikasi klien, karyawan lain menunjukkan perkebunan itu, yang lain menangani penjualan dan kontrak hukum, dll.

Bagian 2:Klien dan Kontak

Clients and contacts area subjek hanya terdiri dari dua tabel, client tabel dan contact meja. Dua tabel lain ditampilkan di area ini, employee:Clients and contacts dan estate:Clients and contacts hanya salinan.

client tabel berisi catatan semua klien yang pernah kami tangani, termasuk klien saat ini dan klien potensial. Siapa klien potensial? Bisa jadi seseorang yang mengatakan mereka ingin menjual, membeli, atau menyewa properti dari kita di masa depan. Kami perlu menyimpan detail kontak dan properti klien tersebut untuk penggunaan di masa mendatang. Atribut di client tabelnya adalah:

client_name – Untuk individu, bidang ini berisi nama depan dan belakang mereka. Jika klien adalah badan hukum, ia memegang nama perusahaan atau entitas.
client_address – Deskripsi teks tentang lokasi klien.
contact_person – Nama depan dan belakang (dan mungkin jabatan jika klien adalah bisnis) penghubung kami.
phone , mobile dan mail – Detail kontak klien.
client_details – Semua detail lain yang terkait dengan klien itu. Ini disimpan dalam format teks tidak terstruktur.

Lima atribut terakhir dalam tabel ini nullable karena tidak krusial. Kami mungkin perlu menyimpan informasi untuk setidaknya satu narahubung, tetapi kami mungkin tidak tahu sebelumnya siapa kontak kami.

Tabel kedua dan terakhir di area subjek ini adalah contact meja. Di sini kami akan menyimpan data tentang setiap interaksi yang kami lakukan dengan klien. Kami akan menggunakan informasi ini untuk mengoptimalkan bisnis kami di masa depan – misalnya, jika klien meminta untuk menyewakan properti tertentu dari kami saat tersedia, kami harus menyimpan permintaan itu dan memberi tahu mereka saat properti sudah siap. Atribut dalam tabel adalah:

client_id – ID klien yang terlibat.
employee_id – ID karyawan yang terlibat dalam instance kontak tersebut. Ini bisa menjadi NULL karena klien tidak boleh menghubungi karyawan individu mana pun – mis. mungkin klien mengirim email ke akun perusahaan. Namun, dalam banyak kasus, kita dapat berharap bahwa kita akan mengetahui karyawan mana yang menangani interaksi.
estate_id - ID dari properti terkait. Ini berguna ketika klien meminta properti tertentu atau jika klien ingin menjual atau menyewakan sesuatu yang sudah kami miliki di sistem kami.
contact_time – Waktu terjadinya kontak.
contact_details – Catatan tidak terstruktur apa pun yang ingin kami simpan tentang kontak itu. Kita mungkin menulis sesuatu seperti “Klien menyatakan keinginan untuk membeli rumah di lingkungan .”

Bagian 3:Kontrak dan Transaksi

Area subjek terakhir dalam model kami adalah Contracts and transactions . Kami akan menggunakannya untuk menghubungkan perkebunan dengan klien.

Tabel pusat bagian ini adalah contract meja. Di sinilah kami akan menyimpan semua detail kontrak dan menghubungkan kontrak dengan klien dan karyawan. Atribut dalam tabel ini adalah:

client_id – ID klien yang menandatangani kontrak terkait.
employee_id – ID karyawan yang menandatangani kontrak atas nama perusahaan kami.
contract_type_id – Merujuk pada contract_type kamus dan menunjukkan jika kontrak berkaitan dengan pembelian, penjualan, penyewaan, atau penyewaan properti.
contract_details – Deskripsi detail kontak, disimpan dalam format teks.
payment_frequency_id – Merujuk pada payment_frequency kamus dan menentukan interval kapan faktur harus dikirim.
number_of_invoices – Jumlah invoice yang harus dibuat. Jika perusahaan hanya membayar sekali, nilai “1” disimpan dalam atribut ini dan seluruh payment_amount akan sama dengan invoice_amount .
payment_amount – Jumlah total yang dibayarkan.
fee_percentage – Persentase yang kami bebankan kepada klien. Misalnya, kami mungkin membebankan 5% dari harga jual rumah sebagai biaya. Nilai di kolom ini harus sama dengan contract_type .fee_percentage atribut untuk kontrak ini. fee_percentage atribut akan digunakan untuk menghitung fee_amount ketika kita memasukkan nilai di payment_amount atribut.
fee_amount – Jumlah total biaya yang akan kami bebankan kepada klien untuk kontrak ini.
date_signed – Tanggal ketika kontrak ditandatangani.
start_date – Tanggal ketika kontrak menjadi valid (misalnya untuk kontrak sewa atau sewa).
end_date – Tanggal berakhirnya kontrak. Itu bisa NULL jika kita menandatangani kontrak yang tidak memiliki tanggal akhir. Namun, dalam kebanyakan kasus kita akan mengetahui end_date sebelumnya.
transaction_id –Mereferensikan transaction tabel jika kontrak merupakan bagian dari transaksi antara dua klien. Itu dapat berisi nilai NULL karena tidak akan ada catatan transaksi terkait jika kontrak langsung antara kami dan klien.

under_contract tabel berhubungan kontrak dan perkebunan. Di samping atribut kunci utama id , hanya berisi dua kunci asing, estate_id dan contract_id . Pasangan kunci asing ini juga membentuk kunci UNIK tabel.

Kami akan menyimpan catatan setiap faktur yang kami buat di invoice meja. Jika klien melakukan pembayaran tunggal untuk seluruh kontrak, hanya akan ada satu catatan dalam tabel ini untuk kontrak tersebut. Hal yang sama berlaku jika kita melakukan pembayaran tunggal ke klien. Jika klien (atau perusahaan kami) memilih untuk membayar dengan mencicil, jumlah catatannya sama dengan nilai dalam contract .number_of_invoices bidang. Atribut dalam tabel ini adalah:

contract_id – ID kontrak terkait.
invoice_number – Pengidentifikasi internal unik untuk faktur.
issued_by – Sebuah deskripsi teks dari penerbit faktur. Saat kami mengeluarkan faktur, kami akan menyimpan detail perusahaan kami di sini. Jika klien mengeluarkannya, maka detailnya akan disimpan di sini.
issued_to – Kebalikan dari issued_by . Jika kami menagih klien, maka atribut ini akan berisi detail mereka; jika klien menagih kami, maka detail kami disimpan di sini.
invoice_details – Semua detail item faktur.
invoice_amount – Jumlah yang harus dibayar pada faktur ini.
date_created – Tanggal sebenarnya saat faktur dibuat di sistem kami.
billing_date – Tanggal saat faktur harus dibayar.
date_paid – Tanggal aktual saat faktur dibayar. Bisa NULL sampai invoice dibayar.

Kami akan menggunakan dua kamus lagi untuk menjelaskan kontrak, contract_type dan payment_frequency . contract_type_name field digunakan untuk menunjukkan tindakan yang kami lakukan dalam kontrak:“mediasi (pembelian)”, “mediasi (penjualan)”, “mediasi (penyewaan)”, “mediasi (leasing)”, “pembelian (dari pelanggan) ”, “menjual (kepada pelanggan)”, ”menyewakan (dari pelanggan)” dan “menyewakan (kepada pelanggan)”. payment_frequency_name atribut hanya menjelaskan seberapa sering faktur akan dibuat, baik oleh kami atau klien. Itu dapat menyimpan nilai seperti "sekali", "sekali per bulan", "sekali setiap 2 bulan" dan "sekali per tahun".

Jika perusahaan kami membeli atau menyewakan beberapa properti, kami akan membayar klien. Ini berarti kita akan menjadi orang yang ada di invoice .issued_to lapangan dan kami harus membayar faktur. Jika kami menjual atau menyewakan properti, klien akan membayar kami dan kami akan menjadi orang yang ada di invoice .issued_by lapangan.

Jika kami menengahi kesepakatan antara dua klien, kami akan membebankan biaya untuk layanan kami. Dalam hal ini, kami akan menandatangani dua kontrak terpisah, satu dengan klien penjual/penyewa dan lainnya dengan klien pembeli/penyewa. Kami akan menghubungkan kedua kontrak ini bersama-sama dengan menetapkan transaction_id yang sama untuk keduanya. transaction table digunakan untuk menyimpan catatan transaksi yang telah kami mediasi. Atribut dalam tabel ini adalah:

transaction_id – ID unik untuk setiap transaksi.
transaction_type_id – Merujuk pada transaction_type kamus.
client_offered – Merujuk client tabel dan menunjukkan siapa yang menjual atau menyewa tanah.
client_requested – Merujuk client tabel dan menunjukkan siapa yang membeli atau menyewa tanah.
transaction_date – Tanggal kapan transaksi akan benar-benar terjadi.
transaction_details – Semua detail yang terkait dengan transaksi itu, disimpan dalam format teks tidak terstruktur.

Tabel terakhir dalam model kami adalah transaction_type kamus. Nilai yang disimpan dalam tabel ini ditetapkan untuk setiap transaksi menurut apa adanya:“beli/jual” atau “sewa/sewa”.

Menjalankan perusahaan real estat sangat rumit, menuntut, dan bahkan berisiko. Untuk menjaga semuanya bekerja dengan lancar, banyak organisasi diperlukan. Saya harap model data ini membantu Anda menyadari kompleksitas bidang ini.

Seperti biasa, ada banyak cara untuk meningkatkan model ini. Jangan ragu untuk membagikan saran dan komentar Anda.