Mô hình dữ liệu cốt lõi BĐS là gì và vì sao phải thiết kế trước phần mềm? là Bài 9 trong series Hệ thống thông tin BĐS. Bài này bám bộ xương V2 đã chốt: ưu tiên tư duy hệ thống, dữ liệu và kiến trúc; chỉ sử dụng phần bài giảng hiện có khi phù hợp và không ép nội dung SQL/GIS/phân tích vào sai series.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Nội dung được phát triển từ bài giảng Hệ thống thông tin BĐS 2026–2027 của tác giả, sau đó mở rộng theo hướng kiến trúc hệ thống, quản trị dữ liệu và thực tiễn doanh nghiệp. Thuật ngữ tiếng Anh được giải nghĩa ở lần xuất hiện chính; phần thao tác SQL, QGIS, BI và mô hình phân tích sâu được để đúng series Tin học BĐS/Phân tích TTBĐS.
1. Mô hình dữ liệu cốt lõi không phải danh sách bảng
Trước khi tạo bảng PostgreSQL hay chọn phần mềm, cần xác định thế giới nghiệp vụ gồm những đối tượng nào, chúng có quan hệ gì và quy tắc nào bất biến. Đó là mô hình dữ liệu khái niệm (conceptual data model). Sau đó mới chuyển thành mô hình logic và vật lý. Nếu đi thẳng vào bảng theo màn hình phần mềm, cấu trúc dễ bị lệ thuộc vendor và khó tích hợp.
2. Ba cấp: khái niệm – logic – vật lý
Cấp khái niệm nói “có Thửa đất, Công trình, Đơn vị không gian, Chủ thể, Quyền, Hợp đồng”. Cấp logic xác định thuộc tính, khóa, quan hệ và chuẩn hóa. Cấp vật lý quyết định bảng, kiểu dữ liệu, index, partition, PostGIS… HTTT BĐS cần hiểu ít nhất hai cấp đầu; kỹ thuật SQL triển khai sâu thuộc Tin học BĐS.
3. Entity nên xuất phát từ nghiệp vụ, không từ màn hình
Một form “Thông tin căn hộ” có thể chứa dữ liệu của nhiều entity: Unit, Building, Project, Address, Owner, Contract. Nếu lưu nguyên form thành một bảng lớn, dữ liệu lặp và khó theo lịch sử. Mô hình hóa tách các khái niệm để chúng được tái sử dụng ở nhiều quy trình.
Ba mức mô hình dữ liệu
| Mức | Nội dung | Không nên nhầm |
|---|---|---|
| Khái niệm | Entity và quan hệ nghiệp vụ | Không phải bảng SQL |
| Logic | Thuộc tính, khóa, chuẩn hóa | Chưa phụ thuộc DBMS |
| Vật lý | Table, datatype, index | Phụ thuộc công nghệ |
4. Dữ liệu chủ, giao dịch và tham chiếu
Master data định danh đối tượng như property, customer, supplier. Transaction data ghi sự kiện như booking, lease, payment. Reference data là danh mục như loại tài sản, trạng thái, đơn vị hành chính. Ba loại có vòng đời và governance khác nhau; trộn chúng làm khó đồng bộ.
5. Mã định danh quan trọng hơn tên hiển thị
Tên dự án, địa chỉ hoặc tên khách có thể thay/viết khác. Mã định danh ổn định giúp liên kết. Một Property ID nội bộ có thể ánh xạ với mã thửa đất, mã BIM, mã hệ thống vận hành, mã kế toán. Không nên dùng địa chỉ làm khóa duy nhất vì địa chỉ có thể chuẩn hóa khác nhau.
6. Quan hệ pháp lý và không gian cần mô hình riêng
BĐS có đặc thù: một quyền thuộc chủ thể; quyền áp dụng lên đơn vị không gian; một thửa có thể liên quan nhiều công trình; một dự án có thể trải trên nhiều thửa. LADM của ISO mô hình hóa parties, rights/responsibilities/restrictions và spatial units, cung cấp một cách tư duy rất hữu ích cho domain đất đai.
7. Thời gian phải là một chiều của mô hình
Chủ sở hữu, trạng thái hợp đồng, diện tích khai thác và phân loại có thể thay đổi. Nếu mô hình chỉ lưu “giá trị hiện tại”, hệ thống không trả lời được lịch sử. Cần xác định effective_from/effective_to hoặc version cho dữ liệu cần truy hồi.
Loại dữ liệu
| Loại | Ví dụ | Governance |
|---|---|---|
| Master | Property, Customer | MDM/ID |
| Transaction | Lease, Booking | Audit/time |
| Reference | Status, loại tài sản | Danh mục chuẩn |
| Document | Hợp đồng, bản vẽ | Version/access |
| Geospatial | Parcel, route | CRS/topology |
8. Business glossary và data model phải đi cùng nhau
Sơ đồ ER cho biết quan hệ nhưng không giải thích đầy đủ “diện tích cho thuê được” hay “giao dịch hoàn tất”. Từ điển nghiệp vụ bổ sung định nghĩa, quy tắc và owner. Khi model và glossary tách rời, người dùng có thể hiểu đúng cấu trúc nhưng sai nghĩa.
9. Thiết kế trước phần mềm giảm vendor lock-in
Nếu tổ chức biết canonical data model của mình, khi thay CRM/PMS vẫn có thể ánh xạ dữ liệu. Nếu ngược lại toàn bộ định nghĩa phụ thuộc vào field của vendor, migration trở nên khó và tổ chức mất khả năng quyết định data ownership. Mô hình dữ liệu cốt lõi là tài sản kiến trúc.
10. Case giả lập: hai phần mềm, cùng khách nhưng không ghép được
CRM dùng CustomerID nội bộ; ERP dùng tên + số điện thoại; hệ thống booking dùng email. Sau sáp nhập dữ liệu, một khách thành ba bản ghi. Vấn đề không phải thiếu công cụ ETL mà thiếu master identity rule. Thiết kế data model và MDM sớm giúp tránh chi phí làm sạch về sau.
Khung áp dụng thực tế
- Vẽ conceptual model 10 entity trước khi nghĩ đến table.
- Phân loại master/transaction/reference/document/geospatial.
- Đặt ID nội bộ cho các master entity.
- Viết 10 thuật ngữ trong business glossary.
- Chỉ sau đó mới chuyển sang ER logic.
Góc nhìn quản trị sâu hơn
Một canonical model tốt không cần quá chi tiết ngay từ đầu. Nên bắt đầu từ entity cốt lõi và các quan hệ ổn định, sau đó mở rộng theo use case. Over-modeling cũng nguy hiểm: nếu cố mô hình mọi trường hợp trước khi có nghiệp vụ thật, hệ thống phức tạp và khó dùng. Thiết kế dữ liệu là cân bằng giữa chuẩn hóa, khả năng mở rộng và tính thực dụng.
Ma trận kiểm toán nhanh
| Thiết kế model | Câu hỏi |
|---|---|
| Entity | Đối tượng có danh tính riêng? |
| Attribute | Thuộc tính hay entity khác? |
| Relationship | Cardinality và thời gian? |
| Identity | ID ổn định là gì? |
| Governance | Owner/definition? |
Những sai lầm cần tránh
- Thiết kế bảng theo màn hình.
- Dùng tên/địa chỉ làm khóa.
- Trộn master với transaction.
- Bỏ qua thời gian và lineage.
Phòng thí nghiệm quyết định
Tình huống giả lập phục vụ giảng dạy: một tổ chức BĐS đang có nhiều hệ thống và file rời. Ban lãnh đạo yêu cầu “làm dashboard/AI” trong 60 ngày. Nhóm sinh viên không được bắt đầu bằng chọn công cụ. Hãy chọn một quyết định kinh doanh cụ thể liên quan chủ đề của bài, truy ngược về dữ liệu nguồn, xác định owner, trạng thái, luồng tích hợp và rủi ro. Sau đó xây hai phương án: cải tiến tối thiểu trong hệ thống hiện tại và kiến trúc mục tiêu dài hạn.
| Phương án | Mục tiêu | Dữ liệu cần chuẩn hóa | Rủi ro | Điều kiện thành công |
|---|---|---|---|---|
| A – cải tiến tối thiểu | Giảm lỗi/nhập lặp nhanh | Master ID + definition + owner | Giải pháp tạm kéo dài | Có SLA và review date |
| B – kiến trúc mục tiêu | Tạo nền tích hợp bền vững | Canonical model + interface + governance | Chi phí/thay đổi lớn | Có roadmap theo giai đoạn |
Nhóm phải giải thích vì sao một khoản đầu tư công nghệ cụ thể giải quyết được nguyên nhân gốc. Nếu nguyên nhân là định nghĩa dữ liệu hoặc quyền trách nhiệm, mua thêm phần mềm không được tính là giải pháp cho đến khi hai vấn đề đó được xử lý.
Bài tập phản biện
- Điều gì trong bài này thuộc nghiệp vụ HTTT và điều gì nên chuyển sang Tin học BĐS/Phân tích TTBĐS?
- Nếu một vendor đề xuất giải pháp trái với mô hình dữ liệu/quy trình hiện tại, nên thay nghiệp vụ hay cấu hình phần mềm? Dựa trên bằng chứng nào?
- Nếu dữ liệu không hoàn hảo nhưng quyết định cần ngay, HTTT nên thể hiện mức độ không chắc chắn ra sao?
- Chỉ số nào có thể rất đẹp nhưng che giấu chất lượng hệ thống kém?
- Sau 6 tháng, bằng chứng nào cho thấy cải tiến thực sự tạo giá trị?
Câu hỏi tự kiểm tra
- Tôi có phân biệt rõ đối tượng nghiệp vụ, dữ liệu và phần mềm chưa?
- Tôi có biết nguồn sự thật và người chịu trách nhiệm cho dữ liệu cốt lõi không?
- Tôi có thể truy một KPI ngược về dữ liệu nguồn và rule tính không?
- Thiết kế có giữ được lịch sử và khả năng kiểm toán không?
- Nếu thay phần mềm, kiến trúc dữ liệu/nghiệp vụ cốt lõi có còn sử dụng được không?
Nhật ký quyết định và khả năng truy vết
Một HTTT trưởng thành không chỉ lưu dữ liệu đầu vào mà còn giúp giải thích vì sao tổ chức đã hành động. Với các quyết định quan trọng, có thể lưu tối thiểu: câu hỏi, dữ liệu/phiên bản được dùng, giả định, người phê duyệt, quyết định, thời điểm xem lại và kết quả. Đây không phải để biến mọi công việc thành thủ tục nặng nề; nó giúp phân biệt “quyết định tốt nhưng kết quả xấu do bất định” với “quyết định kém vì dùng dữ liệu sai”.
| Trường | Ví dụ |
|---|---|
| decision_id | DEC-2026-001 |
| question | Có tăng diện tích cho thuê linh hoạt? |
| evidence_version | Occupancy snapshot 2026-09-30 |
| assumption | Nhu cầu hybrid tiếp tục 12 tháng |
| decision | Pilot 1 tầng |
| review_date | Sau 90 ngày |
| outcome | Đánh giá conversion/occupancy/net revenue |
Khi kết nối decision log với data lineage, tổ chức có thể học từ quá khứ và kiểm tra liệu thay đổi dữ liệu/định nghĩa có làm thay đổi kết luận. Đây là nền tảng rất hữu ích trước khi dùng AI để đề xuất quyết định tự động.
Data model như hợp đồng giữa nghiệp vụ và công nghệ
Mô hình dữ liệu cốt lõi nên được review bởi cả nghiệp vụ và kỹ thuật. Nghiệp vụ xác nhận entity, quan hệ và ý nghĩa; kỹ thuật xác nhận khả năng triển khai, khóa, lịch sử và hiệu năng. Một ERD đúng kỹ thuật nhưng không phản ánh quy tắc kinh doanh sẽ gây workaround. Ngược lại, một sơ đồ nghiệp vụ thiếu cardinality và identity sẽ không thể triển khai ổn định. Data model là tài liệu trung gian giúp hai bên cùng nói một ngôn ngữ.
| Thiết kế hiện trạng | Kiến trúc đích | Bước chuyển ưu tiên |
|---|---|---|
| Xác định dữ liệu/quy trình đang dùng và nơi phát sinh sai lệch | Xác định owner, source of truth, interface và control mong muốn | Chọn một use case có giá trị cao nhưng phạm vi đủ nhỏ |
| Đo baseline: thời gian, lỗi, nhập lặp, mức tin cậy | Đặt KPI nghiệp vụ + KPI dữ liệu | Pilot, đo lại và cập nhật kiến trúc |
| Ghi dependency với hệ thống khác | Thiết kế khả năng thay đổi/version | Mở rộng sau khi rule và dữ liệu đã ổn định |
Bài tập: chọn một quy trình đang dùng Excel hoặc trao đổi file. Hãy mô tả hiện trạng bằng 5 bước, chỉ ra điểm tạo dữ liệu, điểm sao chép và điểm ra quyết định. Sau đó đề xuất kiến trúc đích nhưng chỉ được phép thêm công nghệ nếu giải thích rõ vấn đề nghiệp vụ nào được giải quyết. Cuối cùng viết tiêu chí sau 90 ngày để chứng minh cải tiến có giá trị.
Kiểm thử hệ thống theo ba lớp: dữ liệu – quy trình – quyết định
Một thiết kế HTTT không nên chỉ được kiểm thử ở mức “màn hình chạy được”. Lớp dữ liệu kiểm tra định danh, bắt buộc, tính hợp lệ, trùng lặp, lịch sử và nguồn. Lớp quy trình kiểm tra trạng thái, quyền chuyển bước, SLA, ngoại lệ và khả năng phục hồi khi tích hợp lỗi. Lớp quyết định kiểm tra người dùng có nhận được đúng thông tin để hành động hay không. Nếu dữ liệu đúng nhưng dashboard đến quá chậm, hệ thống vẫn chưa đáp ứng use case.
| Lớp test | Ví dụ test | Tiêu chí đạt |
|---|---|---|
| Dữ liệu | Tạo hai bản ghi cùng PropertyID hoặc thiếu source | Hệ thống chặn/cảnh báo đúng rule |
| Quy trình | Chuyển trạng thái bỏ qua bước phê duyệt | Không cho phép hoặc ghi ngoại lệ có thẩm quyền |
| Tích hợp | API đích tạm ngừng | Retry/log không tạo dữ liệu trùng |
| Quyết định | KPI thay đổi khi definition version đổi | Dashboard chỉ rõ version/thời điểm |
| Người dùng | Người dùng hoàn thành tác vụ thực tế | Không cần xuất file riêng để xử lý chính |
Trong bài tập nhóm, sinh viên nên viết ít nhất 10 test case trước khi đề xuất giao diện. Cách làm này buộc người học biến khái niệm kiến trúc thành yêu cầu có thể nghiệm thu. Nó cũng cho thấy một HTTT tốt không chỉ là “đúng thiết kế” mà phải đúng dữ liệu, đúng quy trình và đúng quyết định.
Đánh đổi kiến trúc: không có hệ thống hoàn hảo cho mọi tổ chức
Mọi thiết kế đều có trade-off: chuẩn hóa cao giúp nhất quán nhưng có thể làm nhập liệu chậm; realtime giảm độ trễ nhưng tăng chi phí và độ phức tạp; một nền tảng all-in-one giảm số interface nhưng tăng phụ thuộc vendor; best-of-breed tăng chuyên sâu nhưng đòi hỏi integration mạnh. Vì vậy bài toán đúng không phải “công nghệ nào tốt nhất” mà là “trade-off nào phù hợp với quy mô, năng lực quản trị và rủi ro của tổ chức”.
| Lựa chọn | Lợi ích | Đánh đổi |
|---|---|---|
| All-in-one | Ít interface, trải nghiệm thống nhất | Vendor lock-in, khó chuyên sâu |
| Best-of-breed | Chức năng chuyên sâu | Tích hợp/governance phức tạp |
| Realtime | Thông tin nhanh | Chi phí, monitoring, consistency |
| Batch | Đơn giản, ổn định | Độ trễ |
| Chuẩn hóa mạnh | Dữ liệu sạch/dùng chung | Cần kỷ luật và change management |
Ghi nhớ trong 30 giây
- Mô hình dữ liệu cốt lõi ở cấp khái niệm không phải danh sách bảng.
- Nên tách conceptual, logical và physical model.
- Master, transaction và reference data có vòng đời khác nhau.
- ID ổn định quan trọng hơn tên/địa chỉ hiển thị.
- Thiết kế trước phần mềm giảm vendor lock-in và chi phí migration.
Nguồn tham khảo
- Bài giảng Hệ thống thông tin BĐS 2026–2027, Buổi 2 – DBMS, mô hình quan hệ, ER và chuẩn hóa.
- Codd (1970) – relational model; Chen (1976) – Entity-Relationship model.
- ISO 19152-1:2024 – Land Administration Domain Model (LADM), mô hình khái niệm parties, RRRs và spatial units.
- Nghị định 101/2024/NĐ-CP – dữ liệu chủ và dữ liệu dùng chung trong CSDL đất đai.
Bài tiếp theo: “Thửa đất – công trình – tòa nhà – tầng – căn – dự án liên hệ với nhau thế nào?”.