Bài 15 – Từ mô hình nghiệp vụ đến mô hình quan hệ: ER, khóa và chuẩn hóa dùng ở mức nào? tiếp tục bộ xương V2 của Hệ thống thông tin BĐS. Mục tiêu không phải học thuộc tên bảng, mà hiểu cách mô hình hóa thế giới BĐS thành dữ liệu có định danh, quan hệ, thời gian, nguồn và trách nhiệm quản trị.
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: Bài viết phục vụ học tập và giảng dạy trong series Hệ thống thông tin BĐS V2. Nội dung giữ ranh giới với Tin học BĐS và Phân tích TTBĐS: tập trung vào mô hình dữ liệu, quy trình, kiến trúc, quản trị và tích hợp; không biến bài thành hướng dẫn thao tác SQL/GIS hay mô hình thống kê.
Ranh giới với các series khác: Bài này chỉ giải thích ER, khóa và chuẩn hóa ở mức thiết kế HTTT. Cú pháp SQL, tạo bảng, JOIN, index và tối ưu truy vấn thuộc series Tin học BĐS.
1. Bắt đầu từ mô hình khái niệm, không từ CREATE TABLE
Trước khi tạo bảng, cần xác định thực thể nghiệp vụ: Property, Party, Agreement, Transaction, Right, Building, Space… và quan hệ. Mô hình ER (thực thể–quan hệ) giúp thảo luận với nghiệp vụ mà chưa bị khóa vào chi tiết DBMS.
2. Entity, attribute và relationship
Thực thể là đối tượng có danh tính; thuộc tính mô tả thực thể; quan hệ nối các thực thể. “Khách hàng có hợp đồng” là quan hệ; “số điện thoại” là thuộc tính; “Hợp đồng” thường là thực thể vì có ID, ngày, trạng thái và thuộc tính riêng.
3. Khóa chính và khóa tự nhiên
Khóa tự nhiên như CCCD hoặc mã thửa có ý nghĩa nghiệp vụ nhưng có thể thay đổi/quy tắc phức tạp. Khóa thay thế (surrogate key) giúp ổn định kỹ thuật; unique constraint vẫn bảo vệ mã nghiệp vụ. Không nên đánh đồng primary key với business identifier.
| Khái niệm | Vai trò | Ví dụ BĐS |
|---|---|---|
| Entity | Đối tượng có danh tính | Property, Party |
| PK | Nhận diện bản ghi | property_id |
| FK | Ràng buộc quan hệ | contract.property_id |
| Link entity | Giải M:N | contract_party |
| Normalization | Giảm trùng/lỗi | Tách address/party đúng chỗ |
4. Khóa ngoại và toàn vẹn tham chiếu
Nếu Contract.PropertyID trỏ tới Property, hệ quản trị có thể ngăn hợp đồng tham chiếu tài sản không tồn tại. Đây là giá trị cốt lõi của mô hình quan hệ. Tuy nhiên integration/event-driven có thể cần chiến lược xử lý eventual consistency ở lớp khác.
5. Quan hệ nhiều–nhiều và bảng liên kết
Một hợp đồng có nhiều bên, một chủ thể có nhiều hợp đồng. Bảng ContractParty không chỉ nối ID mà có thể chứa role, tỷ lệ, ngày hiệu lực, quyền ký. Đây là ví dụ bảng liên kết trở thành thực thể nghiệp vụ.
6. Chuẩn hóa 1NF–3NF để chống bất thường
1NF tránh nhóm lặp/giá trị không nguyên tử; 2NF loại phụ thuộc bộ phận khóa; 3NF giảm phụ thuộc bắc cầu. Mục tiêu là giảm trùng và lỗi cập nhật. Tuy nhiên không nên biến chuẩn hóa thành bài học thuộc lòng; hãy tìm câu hỏi “nếu đổi một dữ kiện phải sửa bao nhiêu nơi?”.
7. Khi nào phi chuẩn hóa?
Lớp báo cáo/data warehouse có thể phi chuẩn hóa để truy vấn nhanh. Cache và materialized view cũng có thể sao chép có kiểm soát. Nhưng dữ liệu nguồn giao dịch nên giữ toàn vẹn mạnh. Phi chuẩn hóa phải có owner và cơ chế đồng bộ.
8. ER không thay thế domain model
ER mô tả dữ liệu quan hệ tốt nhưng hệ thống hiện đại còn có document, graph, geometry, time series. Domain model giúp nhìn nghiệp vụ trước, rồi chọn storage phù hợp. BĐS thường là polyglot data.
Khung thiết kế nâng cao: từ khái niệm đến hệ thống có thể vận hành
Ở góc dữ liệu doanh nghiệp, mô hình chỉ có giá trị khi chuyển được thành quy tắc vận hành. Mỗi đối tượng phải có định danh, owner, source, trạng thái, thời gian, quyền truy cập và quy tắc thay đổi. Nếu thiếu một trong các lớp này, mô hình ER đẹp vẫn có thể tạo dữ liệu không đáng tin.
| Lớp kiểm soát | Câu hỏi thiết kế | Bằng chứng nghiệm thu |
|---|---|---|
| Identity | Cùng một đối tượng được nhận diện thế nào? | ID/namespace/crosswalk |
| Semantics | Trường này nghĩa chính xác là gì? | Data dictionary/code list |
| Source | Ai/cái gì khẳng định dữ liệu? | Source + provenance |
| Time | Đúng ở thời điểm nào? | Effective/version fields |
| Ownership | Ai chịu trách nhiệm? | Data owner/steward |
| Access | Ai xem/sửa/duyệt? | Role/permission/audit |
| Change | Thay đổi qua quy trình nào? | Workflow/event/version |
Quy trình thiết kế tốt: domain workshop → conceptual ER → logical model → normalization → constraints → physical model → performance test. SQL DDL chỉ xuất hiện sau khi các quan hệ nghiệp vụ đã được thống nhất. Đây là ranh giới với Tin học BĐS.
Một nguyên tắc quan trọng là không để schema vật lý quyết định nghiệp vụ. Nếu hệ thống hiện tại có một cột nhưng nghiệp vụ thực tế là quan hệ nhiều–nhiều, hãy sửa mô hình thay vì ép nghiệp vụ vào cột. Ngược lại, không cần tạo hàng chục thực thể chỉ để thể hiện sự 'đúng chuẩn' nếu tổ chức không có use case và governance tương ứng.
Tình huống thiết kế và phòng thí nghiệm quyết định
Tình huống giả lập: bảng Excel có mỗi dòng là một hợp đồng, trong đó lặp tên/CCCD khách, địa chỉ tài sản, dự án và 3 số điện thoại trong một ô. Khi khách đổi số, phải sửa nhiều dòng. Hãy chuyển thành ER và chỉ ra bất thường insert/update/delete.
| Bước | Việc phải làm | Câu hỏi phản biện |
|---|---|---|
| 1. Xác định đối tượng | Liệt kê entity/domain | Có đang trộn object với document/process? |
| 2. Xác định quan hệ | Cardinality + role | M:N có thuộc tính riêng không? |
| 3. Gắn thời gian | Effective/version/event | Có tái dựng lịch sử được không? |
| 4. Gắn nguồn | Source/provenance | Ai chứng minh dữ liệu? |
| 5. Gắn governance | Owner/permission | Ai có quyền sửa? |
| 6. Test ngoại lệ | Split/merge/correction | Mô hình có vỡ khi nghiệp vụ khó? |
Sinh viên không cần viết code ở bước này. Yêu cầu là vẽ mô hình, giải thích từng quan hệ và chứng minh mô hình xử lý được ngoại lệ. Nếu một thiết kế chỉ chạy trong ví dụ 'mỗi tài sản một chủ, mỗi khách một hợp đồng' thì chưa đủ cho BĐS thực tế.
Kiểm soát chất lượng dữ liệu và khả năng truy vết
Chất lượng dữ liệu không chỉ là “đủ trường”. Với mô hình BĐS, cần kiểm tra ít nhất tính đầy đủ, hợp lệ, nhất quán, duy nhất, kịp thời và truy vết được nguồn. Một record có đầy đủ thông tin nhưng source không rõ vẫn có rủi ro cao; một record đúng nhưng đã hết hiệu lực cũng không nên dùng cho quyết định hiện tại.
| Chiều chất lượng | Ví dụ lỗi | Kiểm soát |
|---|---|---|
| Completeness | Thiếu ID/source/effective date | Required rule + exception queue |
| Validity | Loại quyền ngoài code list | Reference data validation |
| Consistency | CRM và master khác loại tài sản | Reconciliation |
| Uniqueness | Hai record cùng đối tượng | Matching/duplicate workflow |
| Timeliness | Thông tin quá hạn | Expiry/SLA |
| Traceability | Không biết dữ liệu từ đâu | Provenance/audit |
Hãy luôn thêm exception workflow. Dữ liệu thực tế không bao giờ sạch tuyệt đối; hệ thống trưởng thành không phải hệ thống “không có lỗi” mà là hệ thống phát hiện, phân công, xử lý và học từ lỗi có cấu trúc.
Khung áp dụng thực tế
- Chuyển một bảng Excel phẳng thành ER.
- Chỉ ra PK/FK và link entity.
- Phân tích 3 bất thường dữ liệu.
- Quyết định lớp nào chuẩn hóa, lớp nào phục vụ BI.
Những sai lầm cần tránh
- Bắt đầu bằng SQL thay vì domain model.
- Dùng text comma-separated cho quan hệ nhiều giá trị.
- Dùng PK có ý nghĩa nghiệp vụ dễ đổi.
- Chuẩn hóa máy móc cả lớp báo cáo.
Bài tập thực hành
Chọn một hệ thống thật hoặc giả lập. Không bắt đầu bằng giao diện. Hãy viết danh sách đối tượng nghiệp vụ, quan hệ, mã định danh, source, thời gian hiệu lực, người chịu trách nhiệm và các ngoại lệ. Sau đó vẽ mô hình khái niệm và dùng ít nhất hai tình huống khó để phá thử mô hình. Cuối cùng ghi rõ phần nào là dữ liệu chủ, phần nào là giao dịch, phần nào là tài liệu và phần nào là lịch sử.
Câu hỏi tự kiểm tra
- Đối tượng chính của mô hình là gì và có định danh độc lập không?
- Quan hệ nào là 1:N, quan hệ nào thực chất là M:N?
- Mô hình có giữ được source và lịch sử hay chỉ trạng thái hiện tại?
- Ai là Data Owner và ai được quyền sửa?
- Nếu hai hệ thống có ID khác nhau, ta nối chúng bằng cơ chế nào?
- Thiết kế có đứng vững khi xảy ra split, merge, correction hoặc nhiều chủ thể không?
Kiểm thử mô hình bằng các ngoại lệ thường gặp trong BĐS
Một mô hình tốt phải xử lý được ngoại lệ trước khi triển khai. Hãy thử năm nhóm: nhiều chủ thể, nhiều hệ định danh, thay đổi theo thời gian, hồ sơ đến muộn/sửa sai và tách–hợp đối tượng. Nếu phải sửa cấu trúc bảng mỗi khi gặp ngoại lệ, conceptual model chưa đủ tổng quát.
| Ngoại lệ | Câu hỏi test | Dấu hiệu mô hình yếu |
|---|---|---|
| Nhiều chủ thể | Một quyền có 3 bên thì sao? | Chỉ có owner_id |
| Nhiều ID | CRM/GIS/ERP dùng mã khác? | Join bằng tên/địa chỉ |
| Thời gian | Xem trạng thái 2 năm trước? | Chỉ giữ current |
| Correction | Sửa sai có xóa lịch sử? | Overwrite |
| Split/Merge | Đối tượng mới kế thừa gì? | Không có lineage |
Sau mỗi test, không chỉ sửa schema. Hãy hỏi liệu lỗi nằm ở định nghĩa nghiệp vụ, code list, workflow hay governance. Nhiều vấn đề dữ liệu không thể giải quyết chỉ bằng thêm cột.
Decision log cho thiết kế dữ liệu
Mỗi quyết định mô hình quan trọng nên có nhật ký: vấn đề, các phương án, lựa chọn, lý do, tác động, người phê duyệt và ngày xem lại. Ví dụ quyết định chọn một PropertyMasterID nội bộ thay vì dùng mã CRM cần ghi rõ vì sao: CRM ID phụ thuộc ứng dụng và có thể đổi khi thay CRM. Decision log giúp đội ngũ sau này hiểu ý định thiết kế thay vì suy đoán từ schema.
Ghi nhớ trong 30 giây
- ER là ngôn ngữ thiết kế nghiệp vụ; SQL chỉ là một cách triển khai sau đó.
- Khóa chính nhận diện bản ghi; khóa ngoại biểu diễn quan hệ và bảo vệ toàn vẹn.
- Quan hệ nhiều–nhiều thường cần một thực thể/bảng liên kết có thuộc tính riêng.
- Chuẩn hóa giúp giảm trùng lặp và bất thường cập nhật; không phải mục tiêu tuyệt đối cho mọi lớp dữ liệu.
- Lớp giao dịch và lớp phân tích có thể tối ưu cấu trúc khác nhau nhưng phải giữ định nghĩa thống nhất.
Nguồn tham khảo
- Bài giảng Hệ thống thông tin BĐS 2026–2027, Buổi 2 – Codd, Chen, ER, khóa và chuẩn hóa.
- Codd, E.F. (1970) – A Relational Model of Data for Large Shared Data Banks.
- Chen, P.P. (1976) – The Entity-Relationship Model.
- Elmasri & Navathe – Fundamentals of Database Systems.
Bài tiếp theo: “Hồ sơ dữ liệu chủ (Property Master) của một BĐS nên được thiết kế thế nào?”.