Bài 32 – 5 lỗi thiết kế cơ sở dữ liệu khiến hệ thống BĐS khó mở rộng thuộc series Tin học BĐS. Bài ưu tiên giải thích bằng tiếng Việt và chỉ giữ các tên kỹ thuật cần thiết để người học có thể thao tác đúng trong công cụ.
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 01/10/2026: Bài thuộc phần Cơ sở dữ liệu và SQL cho BĐS của series Tin học BĐS. Nội dung ưu tiên tiếng Việt thuần; chỉ giữ nguyên tên giao thức, định dạng và cú pháp kỹ thuật khi cần thao tác thực tế. Các ví dụ và số liệu đều là tình huống giả lập phục vụ giảng dạy.
Ranh giới chuyên đề: Bài thuộc phần Cơ sở dữ liệu và SQL cho BĐS. Tên NULL và SQL giữ nguyên vì là khái niệm/cú pháp kỹ thuật; phần diễn giải ưu tiên tiếng Việt.
1. Lỗi 1 là tạo một bảng quá rộng chứa tài sản, chủ thể, nguồn hàng, khảo sát, giao dịch và lịch sử; khi một đối tượng có nhiều sự kiện, cấu trúc nhanh chóng vỡ
Lỗi 1 là tạo một bảng quá rộng chứa tài sản, chủ thể, nguồn hàng, khảo sát, giao dịch và lịch sử; khi một đối tượng có nhiều sự kiện, cấu trúc nhanh chóng vỡ.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
2. Lỗi 2 là không có khóa chính ổn định hoặc dùng tên, địa chỉ, số điện thoại làm khóa khiến thay đổi nhỏ làm đứt liên kết
Lỗi 2 là không có khóa chính ổn định hoặc dùng tên, địa chỉ, số điện thoại làm khóa khiến thay đổi nhỏ làm đứt liên kết.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
3. Lỗi 3 là lặp dữ liệu danh mục như tên phường, tên loại tài sản, tên người dùng ở mọi dòng thay vì dùng mã và bảng danh mục
Lỗi 3 là lặp dữ liệu danh mục như tên phường, tên loại tài sản, tên người dùng ở mọi dòng thay vì dùng mã và bảng danh mục.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
| Câu hỏi kiểm | Mục đích |
|---|---|
| Nguồn nào? | Truy vết |
| Khóa nào? | Không trùng/không nhầm |
| Rỗng có nghĩa gì? | Không gán sai |
| Có giới hạn/phân trang? | Không thiếu dữ liệu |
| Sau xử lý kiểm gì? | Có bằng chứng |
4. Lỗi 4 là ghi đè lịch sử: giá mới ghi đè giá cũ, trạng thái mới ghi đè trạng thái cũ dù nghiệp vụ cần biết quá trình thay đổi
Lỗi 4 là ghi đè lịch sử: giá mới ghi đè giá cũ, trạng thái mới ghi đè trạng thái cũ dù nghiệp vụ cần biết quá trình thay đổi.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
5. Lỗi 5 là không dùng kiểu dữ liệu và ràng buộc phù hợp: giá lưu dạng chữ, ngày lưu tùy ý, khóa ngoại không kiểm, trường bắt buộc lại cho phép rỗng
Lỗi 5 là không dùng kiểu dữ liệu và ràng buộc phù hợp: giá lưu dạng chữ, ngày lưu tùy ý, khóa ngoại không kiểm, trường bắt buộc lại cho phép rỗng.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
6. Một lỗi thiết kế có thể không gây vấn đề khi có 500 dòng nhưng trở thành rất tốn kém khi hệ thống đạt hàng trăm nghìn dòng và nhiều người dùng
Một lỗi thiết kế có thể không gây vấn đề khi có 500 dòng nhưng trở thành rất tốn kém khi hệ thống đạt hàng trăm nghìn dòng và nhiều người dùng.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
| Câu hỏi kiểm | Mục đích |
|---|---|
| Nguồn nào? | Truy vết |
| Khóa nào? | Không trùng/không nhầm |
| Rỗng có nghĩa gì? | Không gán sai |
| Có giới hạn/phân trang? | Không thiếu dữ liệu |
| Sau xử lý kiểm gì? | Có bằng chứng |
7. Không phải lúc nào cũng cần chuẩn hóa cực đoan; thiết kế phải cân bằng giữa tính đúng, hiệu suất, độ đơn giản và cách sử dụng thực tế
Không phải lúc nào cũng cần chuẩn hóa cực đoan; thiết kế phải cân bằng giữa tính đúng, hiệu suất, độ đơn giản và cách sử dụng thực tế.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
8. Trước khi sửa cơ sở dữ liệu đang chạy, cần lập kế hoạch chuyển đổi dữ liệu, kiểm thử và khả năng quay lại; không nên sửa cấu trúc trực tiếp mà không chuẩn bị
Trước khi sửa cơ sở dữ liệu đang chạy, cần lập kế hoạch chuyển đổi dữ liệu, kiểm thử và khả năng quay lại; không nên sửa cấu trúc trực tiếp mà không chuẩn bị.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
Bảng trọng tâm
| Lỗi | Hậu quả | Hướng sửa |
|---|---|---|
| Bảng quá rộng | Khó mở rộng | Tách đối tượng |
| Khóa yếu | Đứt liên kết | Khóa ổn định |
| Lặp danh mục | Không nhất quán | Bảng danh mục |
| Ghi đè lịch sử | Mất truy vết | Bảng lịch sử |
| Sai kiểu/ràng buộc | Dữ liệu bẩn | Kiểu + ràng buộc |
Thiết kế dữ liệu để hệ thống hiểu đúng nghĩa
Cơ sở dữ liệu tốt không chỉ lưu được dữ liệu mà còn phải phân biệt được các trạng thái có ý nghĩa khác nhau. NULL, số 0, chuỗi rỗng và một giá trị mặc định là bốn khái niệm khác nhau. Thiết kế không rõ sẽ khiến báo cáo, kiểm tra và nghiệp vụ hiểu sai.
| Câu hỏi | Thiết kế tốt | Thiết kế yếu |
|---|---|---|
| Chưa có giá | NULL | 0 |
| Không có tầng hầm | 0 nếu thật sự không có | NULL |
| Chưa xác minh ngày | NULL | 01/01/1900 |
| Mã bắt buộc | NOT NULL + duy nhất | Cho rỗng |
Khả năng mở rộng đến từ cấu trúc chứ không chỉ máy mạnh
Một hệ thống có máy chủ mạnh vẫn khó mở rộng nếu bảng quá rộng, khóa không ổn định và lịch sử bị ghi đè. Ngược lại, cấu trúc rõ giúp chia công việc, tối ưu truy vấn và bổ sung chức năng dễ hơn.
Sửa thiết kế theo thứ tự ưu tiên
Không nên sửa tất cả cùng lúc. Thường nên bắt đầu từ định danh và ranh giới bảng, sau đó mới xử lý danh mục, lịch sử, kiểu dữ liệu và ràng buộc. Mỗi bước phải có kế hoạch chuyển dữ liệu cũ.
Tình huống giả lập phục vụ giảng dạy
Một hệ thống BĐS có một bảng 95 cột, dùng địa chỉ làm khóa, lặp tên quận/phường và ghi đè giá cũ. Hãy chỉ ra 5 lỗi và thiết kế hướng cải tổ theo từng bước.
Sinh viên phải trình bày cả cấu trúc, thao tác, lỗi có thể gặp và cách kiểm tra. Không chỉ nộp một ảnh chụp bảng dữ liệu hoặc đoạn lệnh chạy được mà phải giải thích đường đi của dữ liệu.
Quy trình thực hành gợi ý
- Xác định nguồn dữ liệu và quyền sử dụng.
- Ghi rõ câu hỏi nghiệp vụ hoặc dữ liệu cần lấy.
- Xác định khóa, trường bắt buộc và giá trị rỗng.
- Thử trên tập nhỏ trước khi lấy toàn bộ.
- Ghi số bản ghi, thời gian và lỗi phản hồi.
- Chuẩn hóa kiểu dữ liệu trước khi phân tích.
- Lưu các bước biến đổi hoặc truy vấn.
- Tạo bảng kiểm để người khác có thể chạy lại.
Tiêu chí chấm bài thực hành
| Tiêu chí | Tỷ trọng gợi ý | Đạt khi |
|---|---|---|
| Hiểu cấu trúc | 25% | Phân biệt đúng đối tượng/trường |
| Kỹ thuật | 25% | Truy vấn/kết nối đúng |
| Kiểm soát lỗi | 20% | Xử lý rỗng, phân trang, mã lỗi |
| Truy vết | 20% | Nguồn và biến đổi rõ |
| Bàn giao | 10% | Người khác chạy lại được |
Bài tập mở rộng
- Tạo bộ dữ liệu giả lập ít nhất 500 BĐS.
- Thiết kế trường có NULL hợp lý và trường bắt buộc.
- Tạo một phản hồi JSON giả lập có đối tượng và mảng.
- Thiết kế quy trình lấy dữ liệu nhiều trang.
- Ghi nhật ký thời gian, tham số và số bản ghi.
- Biến dữ liệu thành bảng và kiểm khóa duy nhất.
- Vẽ dòng truy vết từ nguồn đến một chỉ tiêu báo cáo.
- So sánh phương án API, CSV và sao chép/dán cho cùng bài toán.
Những lỗi thường gặp
- Dùng 0 để thay cho dữ liệu chưa có.
- Dùng địa chỉ làm khóa chính.
- Lặp danh mục ở mọi bảng.
- Không đọc tài liệu API.
- Để lộ khóa API.
- Chỉ lấy trang đầu rồi tưởng đã đủ dữ liệu.
- Mở rộng mảng JSON làm nhân bản dòng mà không biết.
- Làm mới nhưng không kiểm số dòng.
- Không ghi nguồn và thời gian lấy dữ liệu.
- Dùng API dù quy trình đơn giản hơn đã đủ.
Liên hệ công việc BĐS
Trong hệ thống BĐS hiện đại, dữ liệu hiếm khi nằm ở một nơi. Excel, cơ sở dữ liệu, bản đồ, website và phần mềm nội bộ thường phải trao đổi với nhau. Người làm BĐS không nhất thiết trở thành lập trình viên, nhưng cần hiểu dữ liệu được lấy thế nào, vì sao có thể thiếu, cách kiểm nguồn và cách phát hiện khi một chỉ tiêu bị thay đổi do lỗi tích hợp.
Tiêu chí tự đánh giá
| Tiêu chí | Đạt khi |
|---|---|
| Hiểu nghĩa dữ liệu | Không nhầm NULL/0/rỗng |
| Hiểu cấu trúc | Đọc được JSON/API cơ bản |
| An toàn | Không lộ khóa truy cập |
| Đủ dữ liệu | Xử lý phân trang |
| Truy vết | Biết số liệu đến từ đâu |
Câu hỏi tự kiểm tra
- NULL này có nghĩa nghiệp vụ gì?
- API có được phép sử dụng theo mục đích này không?
- Tôi đã lấy đủ mọi trang chưa?
- Khóa API có xuất hiện trong tệp chia sẻ không?
- Sau khi mở rộng JSON, số dòng có tăng ngoài dự kiến không?
- Tôi có thể giải thích con số trên báo cáo đến từ đâu không?
Ghi nhớ trong 30 giây
- Lỗi 1 là tạo một bảng quá rộng chứa tài sản, chủ thể, nguồn hàng, khảo sát, giao dịch và lịch sử; khi một đối tượng có nhiều sự kiện, cấu trúc nhanh chóng vỡ.
- Lỗi 3 là lặp dữ liệu danh mục như tên phường, tên loại tài sản, tên người dùng ở mọi dòng thay vì dùng mã và bảng danh mục.
- Lỗi 5 là không dùng kiểu dữ liệu và ràng buộc phù hợp: giá lưu dạng chữ, ngày lưu tùy ý, khóa ngoại không kiểm, trường bắt buộc lại cho phép rỗng.
- Không phải lúc nào cũng cần chuẩn hóa cực đoan; thiết kế phải cân bằng giữa tính đúng, hiệu suất, độ đơn giản và cách sử dụng thực tế.
- Trước khi sửa cơ sở dữ liệu đang chạy, cần lập kế hoạch chuyển đổi dữ liệu, kiểm thử và khả năng quay lại; không nên sửa cấu trúc trực tiếp mà không chuẩn bị.
Nguồn tham khảo
- Đề cương học phần 612421 – Tin học ứng dụng trong bất động sản, Trường Đại học Nông Lâm TP.HCM.
- Kế hoạch 96 chủ đề website – series Tin học BĐS trong hệ thống BDSNL.
- PostgreSQL Documentation – tài liệu chính thức về NULL, mô hình quan hệ và truy vấn SQL.
- Microsoft Support – tài liệu chính thức về Power Query và kết nối dữ liệu web.
- MDN Web Docs và tài liệu kỹ thuật JSON/HTTP – tham khảo về yêu cầu, phản hồi, mã trạng thái và dữ liệu JSON.
- Nguyên tắc quản trị dữ liệu: nguồn gốc, tính mới, khóa truy cập, nhật ký biến đổi và khả năng truy vết.
Bài tiếp theo: “API là gì? Giải thích bằng việc Excel lấy dữ liệu từ một website BĐS”.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.