Cách thiết kế database cho thực thể có nhiều trường hợp, nhiều loại,... với số lượng thuộc tính khác nhau

#1

Chào ạ, làm sao để thiết kế bảng cho 1 thực thể mà có nhiều loại nhiều kiểu với mỗi loại có số lượng thuộc tính khác nhau. Ví dụ:
Thực thể X có 2 loại :

  • Loại 1: có 3 thuộc tính A,B,C
  • Loại 2: có 5 thuộc tính B,C,D,E,F

Cụ thể là :

  1. Trong App quản lý phương tiện cơ giới đường bộ cần bảng Xe. Theo cách thông thường thì chỉ cần 1 bảng như này :
+------------+--------------+-------------+----------+
| Biển số xe | Ngày đăng ký | CMND chủ xe | model xe |
+------------+--------------+-------------+----------+
| 123        | 456          | 789         | 112      |
+------------+--------------+-------------+----------+
| 3123       | 21321        | 3213        | 12312    |
+------------+--------------+-------------+----------+

Nhưng đề bài là: Có 2 loại xe:

  • Xe đạp thì có số khung, CMND chủ xe, model xe. Không có biển số xe.
  • Xe máy, oto thì cần thêm thuộc tính số máy, số khung, ngày đăng kiểm, … v/v

2/ Tương tự web bán hàng có 2 loại khách hàng :

  • Khách vãng lai chỉ lưu mã khách hàng.
  • Khách hàng đã tạo tài khoản, khách thân thiết cần lưu thêm SĐT, Tên, địa chỉ,…

3/ Bảng bệnh nhân trong app bệnh viện có 2 loại bệnh nhân :

  • Người lớn cần lưu SĐT, CMND, …
  • Trẻ em không có ĐT, chưa có CMND thì lưu CMND của người thân.

==> Em giải quyết bằng cách lưu tất cả vào 1 bảng. Bảng có bao gồm tất cả các cột của nhiều loại, thuộc tính nào không có thì để trống hoặc lưu null. Trong ví dụ trên xe đạp không có số máy, ngày đăng kiểm nên để null các field này. Nhưng em nghỉ cách này hơi củ chuối. Các bác giúp em chuẩn hóa với. Cảm ơn

P/S: vấn đề em gặp phải cũng giống như topic này ạ, mà topic này chưa có tick solution.

1 Like
Thiết kế database quản lý thực thể như thế nào
#2

Think out of box. Bài toán này khá giống với bài toán lưu trữ thông tin sản phẩm trong TMĐT. Thay vì lưu toàn bộ data mỗi record trong 1 bảng thì bạn lưu trên nhiều bảng khác nhau. Mỗi loại thuộc tính sẽ được lưu vào 1 bảng khác nhau. Có thêm 1 bảng lưu mapping giữa type và các thuộc tính mà nó sở hữu. Khi query sẽ join các bảng lại với nhau.
VD bài toán quản lí phương tiện giao thông.
Bạn có các bảng sau:
Vehicles: id, reg_date, type, owner
NumberPlates: id, vehicle_id, plate_no
ChassisNumbers: id, vehicle_id, engine_no, chassis_no
VehicleAttributes: id, type, attributes
VehicleTypes: id, name

Nếu cần thêm loại thuộc tính thì bạn add thêm bảng mới và cập nhật mapping vào bảng VehicleAttributes.
Mình ví dụ vậy, bạn nghiên cứu thêm để có được phương án tối ưu nhất

6 Likes
#3

Như này đúng không anh?

Capture
Capture1260×655 9.74 KB

Đoạn này là sao em không hiểu?

#4

Thay vì mỗi bảng có mỗi ID khác nhau, khóa chính của Vehicles làm khóa ngoại cho bảng NumberPlates và ChassisNumbers thì cả 3 bảng dùng chung một vehicles_ID được không anh?

mà bảng NumberPlates: id, vehicle_id, plate_no có đến tận 3 field là unique: cột id, cột vehicle_id, plate_no

#5

Mục đích của thiết kế dạng này là decompose 1 thực thể thành nhiều phần nhỏ do đó sẽ có 1 số dữ liệu trùng lặp ở nhiều bảng
bảng VehicleAttributes và VehicleTypes sẽ chịu trách nhiệm mapping/config cho từng loại vehicle sẽ có các thuộc tính khác nhau.
Trong ER của bạn thiếu 1 bảng quan trọng là bảng VehicleAttributes để config type cụ thể có các thuộc tính gì

4 Likes
#6

Được bạn nhé :slightly_smiling_face:

3 Likes
#7


Idea được mình lấy từ Magneto framework, bạn có thể tham khảo link trên để tìm hiểu thêm

3 Likes
#8

Mình thường tách ra mỗi thực thể làm nhiều record.
Mỗi record có cấu trúc :
OBJECT_ID
PROPERTY_ID
PROPERTY_NAME
PROPERTY_VALUE.

2 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?