Tôi nghĩ rằng mô hình nháp ( theo dõi 6NF
và 3NF) sẽ giúp bạn.
Tôi đã đơn giản hóa quy ước đặt tên bằng cách loại bỏ từ khóa 'cửa hàng'.
(Ngoài ra, thực thể cửa hàng có thể dẫn đầu một khái niệm riêng là AKA SaaS)
SqlFiddle Demo
Về các câu hỏi trong nhận xét:
Có, đây là một mẫu phổ biến để sử dụng số nhận dạng thay thế
trên bàn của bạn. Như bạn có thể thấy trong bài viết, điều đó sẽ đi kèm với ưu và nhược điểm của nó.
Ví dụ:trong câu hỏi, bạn sẽ thấy khóa chính của ProductSpecification bảng là một thành phần của ProductTypeOptions , OptionValue và Product khóa ngoại.
Trong thời gian trung bình, khóa chính của các bảng khác như OptionValue là một khóa tổng hợp (OptionId + ValueName )
Có vẻ như cuộc sống sẽ dễ dàng hơn khi có ID trường trong mỗi bảng làm khóa chính, đúng vậy nhưng với tư cách là nhà thiết kế cơ sở dữ liệu, bạn sẽ thiếu một thứ gì đó có giá trị, logic nghiệp vụ .
Trong thiết kế hiện tại, bạn có thể có những ràng buộc này trong bảng Đặc tả sản phẩm, chúng sẽ hiển thị một phần logic kinh doanh của bạn:
- Kiểm tra ràng buộc về
ProductSpecification{OptionValue.optionId = productTypeOption.optionId}điều đó sẽ ngăn một giá trị như "Trắng" được gán cho "Kích thước". - Kiểm tra ràng buộc về
ProductSpecification{product.productTypeId = productTypeOption.productTypeId}điều đó sẽ ngăn một sản phẩm như "Nike" được gán cho sản phẩm Thông số kỹ thuật của "Ô tô".
Nếu bạn sử dụng mã định danh thay thế, bạn không thể có các loại ràng buộc này bên trong cơ sở dữ liệu của mình (hãy thử cách này).
Sẽ cần thêm nhiều công việc được thực hiện trong quá trình triển khai ứng dụng của bạn để đạt được chúng.
BTW sử dụng số nhận dạng thay thế, kiểm tra tính nhất quán của dữ liệu
, nếu quan tâm hơn, hãy xem chọn Khóa chính:Tự nhiên hoặc Thay thế
.
Có vẻ như "Giày nam" của "Nike" cần phải có giá, còn hàng và phụ phí, vì vậy chúng là tài sản tự nhiên của Product bảng.
