不動産業者のデータモデル

場所以外に、不動産ビジネスを成功させるには何が必要ですか？不動産業者が整理された状態を維持できるように、データモデルを検討します。

アパートや家を売買し、借りることは、今日本当に大きなビジネスです。ほとんどの人は喜んで料金を支払い、専門の不動産業者に仕事を任せます。一方、会社は、転売または賃貸するために不動産を購入するという、独自の行動をとることができます。不動産会社はまた、不動産を賃貸し、それを賃貸または転貸して、差額から利益を得る場合があります。

明らかに、不動産を追跡することは不動産ビジネスを運営する上で重要な部分です。同時に、日付も同様に重要です。（例：賃貸アパートが利用可能になるのはいつですか？不動産の一部が市場に出るのはいつですか？）この記事では、不動産会社の整理に役立つデータモデルを見ていきます。

不動産に関するよくある質問

モデルとその予想されるデータについて説明する前に、まず不動産ビジネスに固有のいくつかの質問に答えます。不動産には多くの用語があり、その専門用語と原則の完全な説明はこの記事の範囲をはるかに超えているため、ここでは最も一般的で基本的な質問にのみ回答します。

不動産または不動産と見なすことができるものは何ですか？

不動産について考えるとき、最初に得られるイメージは、多くの場合、家やその他の住居です。不動産はそれだけではありません。建物、オフィス、土地、鉱物資源、軍団もこのカテゴリに分類されます。この記事では、「動かせない」ものはすべて不動産として扱います。そうは言っても、私たちは主にアパートの建物と家に焦点を当てます。
不動産または不動産はどこにありますか？

家、建物、アパートの場合、これは非常に簡単です。宿泊施設の正確な住所がわかります。土地には住所がありませんが、その位置は土地登記所によって定義されています。
どのデータを保存する必要がありますか？

私たちのモデルでは、すべての不動産（つまり、不動産）と一緒に働くクライアントを保存する必要があります。レポートを作成し、ビジネスを改善するためにも、この情報が必要です。

クライアントと頻繁に連絡を取ることが予想されるため、クライアントの連絡先情報をすべて保存する必要があります。また、どの従業員がクライアントに連絡したか、会話中にクライアントがどのような関心を示したかを知りたいと思います。

物件については、潜在的な顧客からの問い合わせに迅速に答えられるように、詳細と現在の状況をすぐに確認する必要があります。

また、連絡履歴と、クライアントまたはプロパティに関連する契約も保存します。
日付はどのくらい重要ですか？

日付は常に重要ですが、不動産では特に重要であることを強調したいと思います。賃貸物件の1つが占有されている正確な時間を知る必要があります。そうすれば、賃貸物件が利用可能になり次第、再度賃貸することができます。 2人のクライアントが同じ物件を借りる場合、重複することはありません。潜在的なクライアントが特定の将来の日付で賃貸したいという希望を表明した場合、その情報を保存し、その日付が近づいたときにリマインダーを受け取る必要があります。
アプリケーションはどのように表示されますか？

この目的には、Webアプリケーションが最適なソリューションです。不動産業務の多くはオフィスベースですが、販売代理店はどこにいても新しいデータを挿入できる必要があります。このアプリの最も重要な機能は、クライアント、プロパティ、プロパティのステータスを見つけることができる高速検索です。

データモデル

私たちの不動産データモデルは、3つの主要な主題分野で構成されています。

Estates and locations
Clients and contacts
Contracts and transactions

employee 、それはどのサブジェクトエリアの外でもあります。

employee およびestate Clients and contactsのテーブルサブジェクトエリアとclient Contracts and transactionsのテーブルサブジェクトエリアは、モデルを単純化するために使用される単なるコピーです。

employee 最初にテーブルを作成し、Estates and locationsに進みます、Clients and contactsに移動します、そしてContracts and transactionsで終了します。

従業員テーブル

employee テーブル。シンプルです。first_nameのみを保存しますおよびlast_name 各従業員の。従業員の納税者番号、生年月日、住所、職務などの詳細を追加することもできます。ただし、このモデルでは従業員に焦点を当てないため、必要なのは従業員を関連付ける方法だけです。アクション（タスクまたは契約への割り当てなど）。この表では、各クライアントの連絡先に参加した従業員を記録することもできます。

セクション1：不動産と場所

Estates and locations サブジェクトエリアには、私たちが扱うすべての不動産（プロパティ）、それらの場所、およびそれらの現在のステータスを説明する6つの表が含まれています。

このサブジェクトエリアの中央のテーブルは、estate テーブル。これには、私たちが現在、または現在、または今後取り組んでいるすべての不動産のリストが含まれています。これには、2つのクライアント間で仲介する不動産、所有する不動産、クライアントに販売または賃貸した不動産、クライアントから賃貸または購入した不動産が含まれます。また、私たちが取引を計画している（または計画していた）不動産の記録も保持しています。

この記事では主にアパートと家に焦点を当てているため、この表の属性は主にそれらに関連しています。他のタイプの不動産について説明したい場合は、null許容の説明属性を追加できます。これらの値をestate_descriptionに入力することもできます。属性。 estate 表は次のとおりです：

estate_name –不動産の名前。これは、プロパティの内部名（「ストーカーハウス」）または有名な公的な名前（「ブラン城」）である可能性があります。
city_id –不動産が所在する都市のID。
estate_type_id – estate_type 辞書。
floor_space およびbalconies_space –アパートの床とバルコニーのサイズ（平方メートル）。
number_of_balconies 、number_of_bedrooms 、number_of_garages およびnumber_of_parking_spaces –各カテゴリの整数値。自明。
pets_allowed –ペットが許可されているかどうかを示すブール値。これは主に賃貸物件に使用されます。
estate_description –不動産の詳細な説明。これは、追加情報を保存する場所です。財産の歴史。
estate_status_id –不動産が現在利用可能かどうか。このフィールドを検索機能で使用します。

estateの2つの辞書についてはすでに説明しました表は、estate_type およびestate_status 。これらの辞書には両方とも、IDと一意の名前属性のみが含まれています。

estate_type 辞書には、「apartment」、「house」、「field」などの値が格納されます。estate_status 表には、「賃貸物件」、「購入物件」、「売却物件」、「賃貸物件」など、物件が現在利用可能かどうかを示す値が表示されます。

説明（estate）だけでなく、各不動産の場所を定義します。 estate_description 属性）だけでなく、その国や都市によっても。この目的のために、2つのディクショナリテーブルを使用します：country およびcity 。各国はcountry_nameによって一意に定義されます、これはテーブルに格納される唯一の属性（ID以外）になります。一方、各都市には名前と国があります。同じ名前の都市もありますが、各都市の名前はその国に固有であると想定します。オーストリアのウィーンまたはスイスのジュネーブの1つだけです。ただし、重複から保護したい場合は、region属性を追加できます。ただし、今のところ、すべてをそのままにしておきます。 city_name – country_id ペアはcity テーブル。

このサブジェクトエリアの最後のテーブルはin_charge テーブル。各不動産には、それに関連する問題を処理するために少なくとも1人の従業員が割り当てられることが期待できます。この従業員は、クライアントとのコミュニケーション、潜在的なクライアントへの不動産の提示、およびその他の管理上および法律上のタスクなどの責任を負います。 in_charge テーブル、次のようになります：

estate_id およびemployee_id –関連する不動産とクライアントをそれぞれ参照する外部キー。
date_from およびdate_to –従業員がその不動産に割り当てられた間隔。従業員が不動産を無期限に管理する可能性があるため、「date_to」はNULLになる可能性があることに注意してください。従業員を不動産に割り当てるときは、重複する日付間隔をチェックして、その従業員が別の不動産に割り当てられていないことを確認する必要があります。一方、同じ不動産に同時に多くの従業員を割り当てることができます。これは、従業員がさまざまな役割を持っている場合に望ましいでしょう。 1人の従業員がクライアントとのコミュニケーションを担当し、別の従業員が不動産を示し、別の従業員が販売や法的な契約などを処理します。

セクション2：クライアントと連絡先

Clients and contacts サブジェクト領域は、client テーブルとcontact テーブル。この領域に表示される他の2つのテーブル、employee:Clients and contacts およびestate:Clients and contacts 単なるコピーです。

client 表には、現在および潜在的なクライアントを含む、これまでに取り組んだすべてのクライアントの記録が含まれています。潜在的なクライアントは誰ですか？将来、私たちから不動産を売却、購入、または賃貸したいと言った人かもしれません。このようなクライアントの連絡先の詳細とプロパティは、将来使用するために保存する必要があります。 client 表は次のとおりです：

client_name –個人の場合、このフィールドには名前と名前が保持されます。クライアントが法人の場合、会社名またはエンティティ名を保持します。
client_address –クライアントの場所の説明文。
contact_person –担当者の名前と姓（およびクライアントがビジネスの場合はおそらく役職）。
phone 、mobile およびmail –クライアントの連絡先の詳細。
client_details –そのクライアントに関連する他のすべての詳細。これらは非構造化テキスト形式で保存されます。

この表の最後の5つの属性は、重要ではないためnull許容です。おそらく少なくとも1人の連絡担当者の情報を保存する必要がありますが、連絡先が誰であるかを事前に知らない場合があります。

このサブジェクトエリアの2番目で最後のテーブルはcontact テーブル。ここでは、クライアントとのすべてのやり取りに関するデータを保存します。この情報を使用して、将来のビジネスを最適化します。たとえば、クライアントが特定の不動産が利用可能になったときに賃貸を依頼した場合は、そのリクエストを保存して、不動産の準備ができたら通知する必要があります。表の属性は次のとおりです。

client_id –関係するクライアントのID。
employee_id –その連絡先インスタンスに関与する従業員のID。クライアントは個々の従業員に連絡できないため、これはNULLになる可能性があります。クライアントが会社のアカウントにメールを送信した可能性があります。それでも、ほとんどの場合、どの従業員がやり取りを処理したかがわかると期待できます。
estate_id –関連する不動産のID。これは、クライアントが特定の物件を要求した場合、またはクライアントがシステムにすでにあるものを販売またはリースしたい場合に役立ちます。
contact_time –連絡が行われた時間。
contact_details –その連絡先について保存したい構造化されていないメモ。「クライアントが近所の家を購入したいという希望を表明した」のように書くかもしれません。

セクション3：契約と取引

モデルの最後のサブジェクト領域はContracts and transactionsです。これを使用して、不動産とクライアントを関連付けます。

このセクションの中心となる表は、contract テーブル。ここにすべての契約の詳細を保存し、クライアントや従業員との契約を関連付けます。この表の属性は次のとおりです。

client_id –関連する契約に署名したクライアントのID。
employee_id –当社を代表して契約に署名した従業員のID。
contract_type_id – contract_type 辞書であり、契約が不動産の購入、販売、賃貸、または賃貸に関連するかどうかを示します。
contract_details –連絡先の詳細な説明。テキスト形式で保存されます。
payment_frequency_id – payment_frequency 辞書を作成し、請求書を送信する間隔を定義します。
number_of_invoices –生成する必要のある請求書の数。会社が1回だけ支払う場合は、この属性に「1」の値が格納され、payment_amount全体が格納されます。 invoice_amountと等しくなります。
payment_amount –支払われた合計金額。
fee_percentage –クライアントに請求する割合。たとえば、住宅の販売価格の5％を手数料として請求する場合があります。この列の値は、contract_typeと同じである必要があります。fee_percentage この契約の属性。 fee_percentage 属性はfee_amountの計算に使用されます payment_amountに値を入力するとき属性。
fee_amount –この契約に対してクライアントに請求する合計料金。
date_signed –契約が締結された日付。
start_date –契約が有効になる日付（例：レンタルまたはリース契約の場合）。
end_date –契約の有効期限が切れる日付。終了日がない契約に署名する場合は、NULLになる可能性があります。ただし、ほとんどの場合、end_dateがわかります。事前に。
transaction_id –transaction 契約が2つのクライアント間のトランザクションの一部である場合はテーブル。契約が私たちとクライアントの間で直接行われている場合、関連するトランザクションレコードがないため、NULL値を含めることができます。

under_contract 表は契約と不動産に関連しています。主キー属性の横にあるid 、estate_idの2つの外部キーのみが含まれていますおよびcontract_id 。この外部キーのペアは、テーブルのUNIQUEキーも形成します。

生成したすべての請求書の記録をinvoice テーブル。クライアントが契約全体に対して1回の支払いを行う場合、このテーブルにはその契約のレコードが1つだけ存在します。クライアントに1回の支払いを行う場合も同様です。クライアント（または当社）が分割払いを選択した場合、contractの値と同じ数のレコードがあります。number_of_invoices 分野。この表の属性は次のとおりです。

contract_id –関連する契約のID。
invoice_number –請求書の一意の内部識別子。
issued_by –請求書発行者のテキストによる説明。請求書を発行するときに、会社の詳細をここに保存します。クライアントがそれを発行した場合、その詳細はここに保存されます。
issued_to – issued_byの反対。クライアントに請求する場合、この属性にはクライアントの詳細が含まれます。クライアントが私たちに請求した場合、私たちの詳細はここに保存されます。
invoice_details –すべての請求書アイテムの詳細。
invoice_amount –この請求書の未払い額。
date_created –請求書がシステムで作成された実際の日付。
billing_date –請求書の支払い日。
date_paid –請求書が支払われた実際の日付。請求書が支払われるまではNULLにすることができます。

契約を説明するために、さらに2つの辞書contract_type およびpayment_frequency 。 contract_type_name フィールドは、契約で実行しているアクションを示すために使用されます：「調停（購入）」、「調停（販売）」、「調停（賃貸）」、「調停（リース）」、「購入（顧客から）」」、「（顧客への）販売」、「（顧客からの）リース」、「（顧客への）賃貸」。 payment_frequency_name 属性は、私たちまたはクライアントのいずれかによって請求書が生成される頻度を簡単に説明します。「1回」、「1か月に1回」、「2か月に1回」、「1年に1回」などの値を保存できます。

私たちの会社がいくつかの不動産を購入またはリースする場合、私たちはクライアントに支払います。これは、私たちがinvoiceの1人になることを意味します。issued_to フィールドと私たちは請求書を支払う必要があります。私たちが不動産を売却または賃貸する場合、クライアントが私たちに支払いを行い、私たちがinvoiceの1人になります。issued_by フィールド。

2つのクライアント間の取引を仲介する場合、サービスの料金を請求します。この場合、2つの別個の契約に署名します。1つは販売/賃貸クライアントと、もう1つは購入者/賃貸クライアントとの契約です。同じtransaction_idを割り当てることで、これら2つのコントラクトを関連付けます。両方へ。 transaction テーブルは、仲介した取引の記録を保存するために使用されます。この表の属性は次のとおりです。

transaction_id –各トランザクションの一意のID。
transaction_type_id – transaction_type 辞書。
client_offered –client 表であり、誰が不動産を販売または賃貸しているのかを示します。
client_requested –client 表であり、誰が不動産を購入またはリースしているのかを示します。
transaction_date –トランザクションが実際に発生する日付。
transaction_details –そのトランザクションに関連するすべての詳細。構造化されていないテキスト形式で保存されます。

モデルの最後のテーブルはtransaction_type 辞書。このテーブルに格納されている値は、「購入/販売」または「レンタル/リース」の内容に従って各トランザクションに割り当てられます。

不動産会社の経営は非常に複雑で、要求が厳しく、リスクさえあります。すべてがスムーズに機能し続けるためには、多くの組織が必要です。このデータモデルが、この分野の複雑さを理解するのに役立つことを願っています。

いつものように、このモデルを改善する方法はたくさんあります。提案やコメントをお気軽に共有してください。