Mô hình dữ liệu đại lý bất động sản

Ngoài vị trí, điều gì cần thiết để điều hành một doanh nghiệp bất động sản thành công? Chúng tôi kiểm tra mô hình dữ liệu để giúp các đại lý bất động sản luôn có tổ chức.

Mua, bán và cho thuê căn hộ hoặc nhà ở thực sự là một lĩnh vực kinh doanh lớn ngày nay. Hầu hết mọi người đều vui lòng trả một khoản phí và để một công ty bất động sản chuyên nghiệp thực hiện công việc cho họ. Mặt khác, công ty có thể nhân danh chính mình, mua tài sản để bán lại hoặc cho thuê. Một công ty bất động sản cũng có thể cho thuê bất động sản sau đó cho thuê hoặc cho thuê lại và thu lợi nhuận từ phần chênh lệch.

Rõ ràng, việc theo dõi tài sản là một phần quan trọng trong việc vận hành một doanh nghiệp bất động sản. Đồng thời, ngày tháng cũng quan trọng không kém. (ví dụ:Khi nào thì một căn hộ cho thuê sẽ có sẵn? Khi nào thì một phần bất động sản sẽ được tung ra thị trường?) Trong bài viết này, chúng ta sẽ xem xét một mô hình dữ liệu có thể giúp các công ty bất động sản luôn có tổ chức.

Câu hỏi thường gặp về bất động sản

Trước khi bắt đầu mô tả mô hình và dữ liệu dự kiến của nó, trước tiên, chúng tôi sẽ trả lời một số câu hỏi cụ thể cho một doanh nghiệp bất động sản. Bất động sản có nhiều thuật ngữ và lời giải thích đầy đủ về biệt ngữ và nguyên tắc của nó nằm ngoài phạm vi của bài viết này, vì vậy chúng tôi sẽ chỉ trả lời những câu hỏi cơ bản và phổ biến nhất ở đây.

Cái gì có thể được coi là động sản hay tài sản?

Khi chúng ta nghĩ về bất động sản, hình ảnh đầu tiên chúng ta nhận được thường là một ngôi nhà hoặc một số nơi ở khác. Bất động sản còn nhiều hơn thế nữa. Các tòa nhà, văn phòng, đất đai, tài nguyên khoáng sản và quân đoàn cũng thuộc loại này. Với mục đích của bài viết này, tôi sẽ coi mọi thứ “không thể di chuyển được” là bất động sản. Phải nói rằng, chúng tôi sẽ tập trung chủ yếu vào các tòa nhà chung cư và nhà ở.
Di sản hoặc tài sản nằm ở đâu?

Đối với nhà ở, cao ốc, căn hộ thì việc này rất đơn giản. Chúng tôi sẽ biết địa chỉ chính xác nơi có tài sản. Đất không có địa chỉ, nhưng vị trí của nó do cơ quan đăng ký đất đai xác định.
Chúng tôi cần lưu trữ dữ liệu nào?

Trong mô hình của chúng tôi, chúng tôi cần lưu trữ tất cả các bất động sản (tức là tài sản thực) và các khách hàng mà chúng tôi làm việc cùng. Chúng tôi cần thông tin này để tạo báo cáo và cũng để cải thiện hoạt động kinh doanh của mình.

Chúng tôi có thể mong đợi rằng chúng tôi sẽ liên lạc thường xuyên với khách hàng, vì vậy chúng tôi phải lưu trữ tất cả các chi tiết liên hệ của họ. Chúng tôi cũng sẽ muốn biết nhân viên nào đã liên hệ với khách hàng và sự quan tâm của khách hàng trong cuộc trò chuyện.

Đối với các bất động sản, chúng tôi cần thông tin chi tiết và tình trạng hiện tại của chúng để có thể nhanh chóng trả lời các câu hỏi của khách hàng tiềm năng.

Chúng tôi cũng sẽ lưu trữ lịch sử liên hệ của mình và mọi hợp đồng liên quan đến khách hàng hoặc tài sản.
Ngày quan trọng như thế nào?

Ngày tháng luôn là yếu tố quan trọng, nhưng tôi muốn nhấn mạnh rằng chúng đặc biệt quan trọng trong lĩnh vực bất động sản. Chúng tôi cần biết chính xác khoảng thời gian mà một trong các tài sản cho thuê của chúng tôi bị chiếm dụng để có thể cho thuê lại ngay khi có. Không thể có bất kỳ sự chồng chéo nào khi hai khách hàng thuê cùng một tài sản. Nếu một khách hàng tiềm năng bày tỏ mong muốn thuê vào một ngày cụ thể nào đó trong tương lai, chúng tôi nên lưu trữ thông tin đó và nhận lời nhắc khi ngày đó sắp đến.
Ứng dụng của chúng tôi trông như thế nào?

Với mục đích này, ứng dụng web là giải pháp tốt nhất. Phần lớn công việc bất động sản là ở văn phòng, nhưng các đại lý bán hàng có thể chèn dữ liệu mới vào bất cứ nơi đâu. Chức năng quan trọng nhất trong ứng dụng của chúng tôi là tìm kiếm nhanh có thể tìm thấy khách hàng, thuộc tính và trạng thái thuộc tính.

Mô hình dữ liệu

Mô hình dữ liệu bất động sản của chúng tôi bao gồm ba lĩnh vực chủ đề chính:

Estates and locations
Clients and contacts
Contracts and transactions

Có một bảng, employee , nằm ngoài bất kỳ lĩnh vực chủ đề nào.

Xin lưu ý rằng employee và estate trong Clients and contacts lĩnh vực chủ đề và client trong Contracts and transactions chủ đề chỉ là các bản sao được sử dụng để đơn giản hóa mô hình.

Chúng tôi sẽ xem xét employee đầu tiên, hãy tiếp tục với Estates and locations , chuyển đến Clients and contacts , và sau đó kết thúc với Contracts and transactions .

Bảng nhân viên

Chúng ta sẽ bắt đầu với employee bàn. Thật đơn giản:nó chỉ lưu trữ first_name và last_name của mỗi nhân viên. Chúng tôi có thể thêm các chi tiết khác như số ID thuế của nhân viên, ngày sinh của họ, địa chỉ, vai trò công việc, v.v. Tuy nhiên, trong mô hình này, chúng tôi sẽ không tập trung vào nhân viên, vì vậy tất cả những gì chúng tôi cần là một cách để liên kết nhân viên với hành động (như được giao cho một nhiệm vụ hoặc hợp đồng). Bảng này cũng sẽ cho phép chúng tôi ghi lại nhân viên nào đã tham gia vào từng liên hệ với khách hàng.

Phần 1:Bất động sản và Vị trí

Estates and locations vùng chủ đề chứa sáu bảng mô tả tất cả các bất động sản (thuộc tính) mà chúng tôi làm việc, vị trí của chúng và trạng thái hiện tại của chúng.

Bảng trung tâm trong chủ đề này là estate bàn. Nó chứa một danh sách tất cả các bất động sản mà chúng tôi đang, đã, hoặc sẽ làm việc cùng. Điều này bao gồm các bất động sản mà chúng tôi làm trung gian giữa hai khách hàng, những bất động sản mà chúng tôi sở hữu, bất kỳ khu đất nào chúng tôi đã bán hoặc cho khách hàng thuê và bất kỳ khu đất nào chúng tôi đã cho thuê hoặc mua từ khách hàng. Nó cũng lưu giữ hồ sơ về các bất động sản mà chúng tôi dự định (hoặc đã lên kế hoạch) kinh doanh.

Vì chúng tôi tập trung chủ yếu vào căn hộ và nhà ở trong bài viết này, nên các thuộc tính trong bảng này hầu hết đều liên quan đến chúng. Nếu chúng tôi muốn mô tả các loại thuộc tính thực khác, chúng tôi có thể thêm các thuộc tính mô tả có thể vô hiệu bổ sung. Chúng tôi cũng có thể chỉ cần nhập các giá trị đó vào estate_description thuộc tính. Các thuộc tính trong estate bảng là:

estate_name - Tên của bất động sản. Đây có thể là tên nội bộ của chúng tôi cho một tài sản (“Nhà của Stoker”) hoặc một tên công cộng nổi tiếng (“Lâu đài Bran”).
city_id - Giấy tờ tùy thân của thành phố nơi có bất động sản.
estate_type_id - Tham chiếu estate_type từ điển.
floor_space và balconies_space - Kích thước (tính bằng mét vuông) của các tầng căn hộ và ban công.
number_of_balconies , number_of_bedrooms , number_of_garages và number_of_parking_spaces - Các giá trị nguyên cho mỗi danh mục. Tự giải thích.
pets_allowed - Giá trị Boolean biểu thị nếu vật nuôi được phép. Điều này chủ yếu được sử dụng cho các tài sản cho thuê.
estate_description - Bản mô tả chi tiết về bất động sản. Đây là nơi chúng tôi lưu trữ bất kỳ thông tin bổ sung nào, ví dụ:lịch sử tài sản.
estate_status_id - Nếu hiện tại có di sản hay không. Chúng tôi sẽ sử dụng trường này trong chức năng tìm kiếm của mình.

Chúng tôi đã đề cập đến hai từ điển mà estate bảng đề cập đến, estate_type và estate_status . Cả hai từ điển này chỉ chứa một ID và một thuộc tính tên DUY NHẤT.

Trong estate_type từ điển, chúng tôi sẽ lưu trữ các giá trị như “căn hộ”, “nhà”, “trường”, v.v. estate_status bảng sẽ có các giá trị cho biết bất động sản hiện có sẵn hay không, chẳng hạn như “bất động sản cho thuê”, “bất động sản đã mua”, “bất động sản đã bán”, “bất động sản cho thuê”.

Chúng tôi sẽ xác định vị trí của từng bất động sản, không chỉ bằng mô tả (estate . estate_description thuộc tính), mà còn theo quốc gia và thành phố của nó. Vì mục đích này, chúng tôi sẽ sử dụng hai bảng từ điển:country và city . Mỗi quốc gia được xác định duy nhất bởi một country_name , sẽ là thuộc tính duy nhất (ngoài ID) được lưu trữ trong bảng. Mặt khác, mỗi thành phố có một tên và một quốc gia. Một số thành phố có thể có tên giống nhau, nhưng chúng tôi sẽ giả định rằng tên của mỗi thành phố là duy nhất cho quốc gia của nó - chỉ một Vienna, Áo hoặc Geneva, Thụy Sĩ. Tuy nhiên, nếu chúng ta muốn bảo vệ khỏi các bản sao, chúng ta có thể thêm thuộc tính vùng. Tuy nhiên, hiện tại, chúng tôi sẽ để nguyên mọi thứ. city_name - country_id cặp là khóa DUY NHẤT của city bảng.

Bảng cuối cùng trong chủ đề này là in_charge bàn. Chúng ta có thể mong đợi rằng mỗi khu đất sẽ có ít nhất một nhân viên được chỉ định để xử lý các vấn đề liên quan đến khu nhà đó. Nhân viên này chịu trách nhiệm về những việc như giao tiếp với khách hàng, hiển thị tài sản cho khách hàng tiềm năng và các nhiệm vụ hành chính và pháp lý khác. Trong in_charge bảng, chúng ta sẽ có:

estate_id và employee_id - Các khóa ngoại lần lượt đề cập đến bất động sản và khách hàng có liên quan.
date_from và date_to - Khoảng thời gian mà nhân viên được giao cho bất động sản đó. Lưu ý rằng “date_to” có thể là NULL vì một nhân viên có thể chăm sóc di sản vô thời hạn. Khi chúng tôi chỉ định một nhân viên cho một điền trang, chúng tôi nên đảm bảo rằng họ chưa được chỉ định cho một điền trang khác bằng cách kiểm tra các khoảng ngày trùng lặp. Mặt khác, chúng ta có thể phân công nhiều nhân viên vào cùng một bất động sản cùng một lúc. Điều này sẽ là mong muốn khi nhân viên có các vai trò khác nhau, ví dụ:một nhân viên chăm sóc giao tiếp với khách hàng, một nhân viên khác trưng bày bất động sản đó, một nhân viên khác xử lý các hợp đồng mua bán và pháp lý, v.v.

Phần 2:Khách hàng và Địa chỉ liên hệ

Client and contacts chủ đề chỉ bao gồm hai bảng, client bảng và contact bàn. Hai bảng khác được hiển thị trong khu vực này, employee:Clients and contacts và estate:Clients and contacts chỉ là những bản sao.

client bảng chứa hồ sơ của tất cả khách hàng mà chúng tôi đã từng làm việc, bao gồm cả khách hàng hiện tại và khách hàng tiềm năng. Khách hàng tiềm năng là ai? Đó có thể là ai đó đã nói rằng họ muốn bán, mua hoặc thuê một số tài sản từ chúng tôi trong tương lai. Chúng tôi cần lưu trữ chi tiết liên hệ và thuộc tính của những khách hàng đó để sử dụng trong tương lai. Các thuộc tính trong client bảng là:

client_name - Đối với một cá nhân, trường này chứa họ và tên của họ. Nếu khách hàng là pháp nhân, khách hàng có tên công ty hoặc tổ chức.
client_address - Mô tả bằng văn bản về vị trí của khách hàng.
contact_person - Họ và tên (và có thể là chức danh nếu khách hàng là doanh nghiệp) của người liên hệ của chúng tôi.
phone , mobile và mail - Chi tiết liên hệ của khách hàng.
client_details - Mọi thông tin chi tiết khác liên quan đến khách hàng đó. Chúng được lưu trữ ở định dạng văn bản phi cấu trúc.

Năm thuộc tính cuối cùng trong bảng này là vô hiệu vì chúng không quan trọng. Chúng tôi có thể sẽ cần lưu trữ thông tin của ít nhất một người liên hệ, nhưng chúng tôi có thể không biết trước người liên hệ của chúng tôi sẽ là ai.

Bảng thứ hai và cuối cùng trong chủ đề này là contact bàn. Tại đây, chúng tôi sẽ lưu trữ dữ liệu về mọi tương tác mà chúng tôi đã có với khách hàng. Chúng tôi sẽ sử dụng thông tin này để tối ưu hóa hoạt động kinh doanh trong tương lai của mình - ví dụ:nếu một khách hàng yêu cầu thuê một bất động sản nhất định từ chúng tôi khi có sẵn, chúng tôi nên lưu trữ yêu cầu đó và thông báo cho họ khi khu bất động đó sẵn sàng. Các thuộc tính trong bảng là:

client_id - ID của khách hàng có liên quan.
employee_id - ID của nhân viên liên quan đến trường hợp liên hệ đó. Điều này có thể là KHÔNG ĐỦ vì khách hàng có thể không liên hệ với bất kỳ nhân viên cá nhân nào - ví dụ:có thể khách hàng đã gửi email đến tài khoản công ty. Tuy nhiên, trong hầu hết các trường hợp, chúng tôi có thể mong đợi rằng chúng tôi sẽ biết nhân viên nào đã xử lý một tương tác.
estate_id - Giấy tờ tùy thân của bất động sản có liên quan. Điều này hữu ích khi khách hàng yêu cầu một tài sản nhất định hoặc nếu khách hàng muốn bán hoặc cho thuê thứ gì đó mà chúng tôi đã có trong hệ thống của mình.
contact_time - Thời điểm liên hệ diễn ra.
contact_details - Mọi ghi chú không có cấu trúc mà chúng tôi muốn lưu về liên hệ đó. Chúng ta có thể viết đại loại như “Khách hàng bày tỏ mong muốn mua nhà ở khu phố .”

Phần 3:Hợp đồng và Giao dịch

Chủ đề cuối cùng trong mô hình của chúng tôi là Contracts and transactions . Chúng tôi sẽ sử dụng nó để liên kết các bất động sản với khách hàng.

Bảng trung tâm của phần này là contract bàn. Đây là nơi chúng tôi sẽ lưu trữ tất cả các chi tiết hợp đồng và các hợp đồng liên quan với khách hàng và nhân viên. Các thuộc tính trong bảng này là:

client_id - ID của khách hàng đã ký hợp đồng liên quan.
employee_id - ID của nhân viên đã ký hợp đồng thay mặt cho công ty chúng tôi.
contract_type_id - Tham chiếu contract_type từ điển và biểu thị nếu hợp đồng liên quan đến mua, bán, cho thuê hoặc cho thuê tài sản.
contract_details - Mô tả chi tiết về địa chỉ liên hệ, được lưu trữ ở định dạng văn bản.
payment_frequency_id - Tham chiếu payment_frequency từ điển và xác định khoảng thời gian khi hóa đơn sẽ được gửi.
number_of_invoices - Số lượng hóa đơn sẽ được tạo. Nếu công ty chỉ thanh toán một lần, giá trị “1” được lưu trữ trong thuộc tính này và toàn bộ payment_amount sẽ bằng với invoice_amount .
payment_amount - Tổng số tiền đã thanh toán.
fee_percentage - Phần trăm chúng tôi tính phí cho khách hàng. Ví dụ:chúng tôi có thể tính phí 5% giá bán của một ngôi nhà. Giá trị trong cột này phải giống với contract_type . fee_percentage thuộc tính cho hợp đồng này. fee_percentage thuộc tính sẽ được sử dụng để tính toán fee_amount khi chúng tôi nhập giá trị vào payment_amount thuộc tính.
fee_amount - Tổng số tiền phí mà chúng tôi sẽ tính cho khách hàng cho hợp đồng này.
date_signed - Ngày ký hợp đồng.
start_date - Ngày hợp đồng có hiệu lực (ví dụ:đối với hợp đồng thuê hoặc cho thuê).
end_date - Ngày hết hạn hợp đồng. Nó có thể là NULL trong trường hợp chúng tôi ký hợp đồng không có ngày kết thúc. Tuy nhiên, trong hầu hết các trường hợp, chúng tôi sẽ biết end_date trước.
transaction_id –Tham khảo transaction bảng nếu hợp đồng là một phần của giao dịch giữa hai khách hàng. Nó có thể chứa giá trị NULL vì sẽ không có hồ sơ giao dịch liên quan nếu hợp đồng trực tiếp giữa chúng tôi và khách hàng.

under_contract bảng liên quan đến hợp đồng và bất động sản. Bên cạnh thuộc tính khóa chính id , nó chỉ chứa hai khóa ngoại, estate_id và contract_id . Cặp khóa ngoại này cũng tạo thành khóa DUY NHẤT của bảng.

Chúng tôi sẽ lưu trữ hồ sơ của mọi hóa đơn mà chúng tôi đã tạo trong invoice bàn. Nếu khách hàng thanh toán một lần cho toàn bộ hợp đồng, sẽ chỉ có một bản ghi trong bảng này cho hợp đồng đó. Điều tương tự cũng áp dụng nếu chúng tôi thực hiện một khoản thanh toán cho khách hàng. Nếu khách hàng (hoặc công ty của chúng tôi) chọn trả góp thì sẽ có cùng số lượng hồ sơ với giá trị trong contract . number_of_invoices đồng ruộng. Các thuộc tính trong bảng này là:

contract_id - ID của hợp đồng liên quan.
invoice_number - Giá trị nhận dạng nội bộ duy nhất cho hóa đơn.
issued_by - Bản mô tả văn bản của đơn vị phát hành hóa đơn. Khi chúng tôi xuất hóa đơn, chúng tôi sẽ lưu trữ thông tin chi tiết về công ty của chúng tôi tại đây. Nếu khách hàng phát hành thì thông tin chi tiết của họ sẽ được lưu trữ tại đây.
issued_to - Đối lập với issued_by . Nếu chúng tôi tính phí khách hàng, thì thuộc tính này sẽ chứa thông tin chi tiết của họ; nếu khách hàng tính phí chúng tôi, thì thông tin chi tiết của chúng tôi sẽ được lưu trữ tại đây.
invoice_details - Tất cả chi tiết mặt hàng trong hóa đơn.
invoice_amount - Số tiền đến hạn trên hóa đơn này.
date_created - Ngày thực tế khi hóa đơn được tạo trong hệ thống của chúng tôi.
billing_date - Ngày thanh toán hóa đơn.
date_paid - Ngày thực tế khi hóa đơn được thanh toán. Nó có thể là NULL cho đến khi hóa đơn được thanh toán.

Chúng tôi sẽ sử dụng thêm hai từ điển để mô tả hợp đồng, contract_type và payment_frequency . contract_type_name trường được sử dụng để biểu thị hành động mà chúng tôi đang thực hiện trong hợp đồng:“dàn xếp (mua)”, “dàn xếp (bán)”, “dàn xếp (thuê)”, “dàn xếp (cho thuê)”, “mua (từ khách hàng) ”,“ Bán (cho khách hàng) ”,“ cho thuê (từ khách hàng) ”và“ cho thuê (cho khách hàng) ”. payment_frequency_name thuộc tính chỉ đơn giản mô tả tần suất hóa đơn sẽ được tạo bởi chúng tôi hoặc khách hàng. Nó có thể lưu trữ các giá trị như "một lần", "một lần mỗi tháng", "hai tháng một lần" và "một lần mỗi năm".

Nếu công ty của chúng tôi mua hoặc thuê một số tài sản, chúng tôi sẽ trả tiền cho khách hàng. Điều này có nghĩa là chúng tôi sẽ là người đứng tên trong invoice . issued_to và chúng tôi sẽ phải thanh toán hóa đơn. Nếu chúng tôi bán hoặc cho thuê bất động sản, khách hàng sẽ thanh toán cho chúng tôi và chúng tôi sẽ là người đứng tên trong invoice . issued_by trường.

Nếu chúng tôi dàn xếp một thỏa thuận giữa hai khách hàng, chúng tôi sẽ tính phí cho các dịch vụ của mình. Trong trường hợp này, chúng tôi sẽ ký hai hợp đồng riêng biệt, một với khách hàng bán / cho thuê và một hợp đồng khác với khách hàng là người mua / thuê. Chúng tôi sẽ liên kết hai hợp đồng này với nhau bằng cách chỉ định cùng một transaction_id cho cả hai. transaction bảng được sử dụng để lưu trữ hồ sơ về các giao dịch mà chúng tôi đã dàn xếp. Các thuộc tính trong bảng này là:

transaction_id - Một ID duy nhất cho mỗi giao dịch.
transaction_type_id - Tham chiếu transaction_type từ điển.
client_offered - Tham chiếu đến client bảng và biểu thị ai đang bán hoặc cho thuê bất động sản.
client_requested - Tham chiếu đến client bảng và biểu thị ai đang mua hoặc thuê bất động sản.
transaction_date - Ngày mà giao dịch thực sự sẽ diễn ra.
transaction_details - Tất cả các chi tiết liên quan đến giao dịch đó, được lưu trữ ở định dạng văn bản phi cấu trúc.

Bảng cuối cùng trong mô hình của chúng tôi là transaction_type từ điển. Các giá trị được lưu trữ trong bảng này được chỉ định cho mỗi giao dịch theo ý nghĩa của nó:“mua / bán” hoặc “thuê / cho thuê”.

Điều hành một công ty bất động sản là rất phức tạp, đòi hỏi khắt khe và thậm chí là rủi ro. Để giữ cho mọi thứ hoạt động trơn tru, cần có sự tổ chức tuyệt vời. Tôi hy vọng rằng mô hình dữ liệu này đã giúp bạn nhận ra sự phức tạp của lĩnh vực này.

Như mọi khi, có nhiều cách để cải thiện mô hình này. Vui lòng chia sẻ đề xuất và nhận xét của bạn.