Supertype / Subtype quyết định giữa thể loại: hoàn toàn tách rời hoặc chồng chéo không hoàn chỉnh

Tôi đang xây dựng cơ sở dữ liệu kiểm kê lưu trữ phần cứng CNTT, chẳng hạn như máy tính để bàn, máy tính xách tay, thiết bị chuyển mạch, bộ định tuyến, điện thoại di động, v.v. Tôi đang sử dụng mẫu supertype / subtype, trong đó tất cả các thiết bị được lưu trữ trong một bảng và thông tin cụ thể được đưa vào bảng phụ. Vấn đề nan giải của tôi là lựa chọn giữa hai thiết kế sau:

Trong sơ đồ hàng đầu, tất cả các thiết bị chia sẻ các kiểu con phổ biến. Ví dụ: máy tính để bàn và máy tính xách tay sẽ có các bản ghi trong các bảng sau: Thiết bị, NetworkDevice. Một chuyển đổi sẽ có hồ sơ trong: Thiết bị, NetworkDevice. Một bộ định tuyến sẽ có các bản ghi trong: Device, NetworkDevice, WANDevice. Bất kỳ thiết bị nào chúng tôi theo dõi vị trí sẽ có bản ghi trong Vị trí. Một số ưu và nhược điểm mà tôi nghĩ đến cho thiết lập này:

• Pro: CHỌN bản ghi dựa trên một trường chung, như Tên máy chủ hoặc LocationID dễ dàng hơn.
• Pro: Không có trường null.
• Con: Các bảng nên được bao gồm trong các hoạt động CRUD cho một thiết bị cụ thể là không rõ ràng và có thể gây nhầm lẫn cho các DBA trong tương lai.

Trong sơ đồ dưới cùng, tất cả các thiết bị đều có kiểu con riêng (Có nhiều lớp thiết bị không được hiển thị ở đây). Trong tình huống này, rõ ràng các bản ghi bảng được chèn vào hoặc được chọn từ đó. Máy tính để bàn và máy tính xách tay đi trong Máy tính, vv Một số ưu và nhược điểm mà tôi nghĩ đến cho thiết lập này:

• Pro: Rõ ràng ngay lập tức sử dụng bảng nào cho các hoạt động CRUD cho các kiểu con.
• Pro: Chỉ phải sử dụng một bảng cho các hoạt động CRUD.
• Con: CHỌN các bản ghi dựa trên các trường con phổ biến yêu cầu tất cả các bảng được kết hợp, ví dụ: tìm kiếm theo Tên máy chủ hoặc LocationID.

Trong cả hai trường hợp, trường ClassDiscriminator được đặt trong các bảng phụ để sử dụng với ràng buộc CHECK để kiểm soát loại nào có thể được chèn.

Có bất kỳ khuyến nghị cho thiết kế nào là tốt hơn, hoặc nó hoàn toàn là một vấn đề quan điểm và phụ thuộc vào mục đích dự định của cơ sở dữ liệu?

EDIT: Một câu hỏi cụ thể mà tôi có liên quan đến tính chất chồng chéo của bảng "NetworkDevice". Bảng này có nghĩa là chứa thông tin mạng cho bất kỳ thiết bị nào có tên máy chủ và / hoặc địa chỉ IP, cho dù đó là máy tính, bộ chuyển mạch hoặc bộ định tuyến. Là bản chất chồng chéo của bảng này một cái gì đó có thể gây ra vấn đề, hoặc có thể thực hiện nó theo cách này?

Cảm ơn bạn trước cho bất kỳ đầu vào được cung cấp. Xin hỏi nếu có thêm thông tin cần thiết.

Thực hiện vật lý của phân nhóm trong cơ sở dữ liệu là một vấn đề phức tạp. Trừ khi bạn có một tình huống mà nó mang lại những lợi thế hấp dẫn (xem bên dưới để biết một hoặc hai ví dụ), nó sẽ tăng thêm sự phức tạp khi thực hiện trong khi cung cấp giá trị tương đối ít.

Đã thực hiện điều này với phân nhóm thực sự phức tạp (applicaitons và câu trên hệ thống quản lý vụ án của tòa án, phân biệt cấu trúc hợp đồng bảo hiểm thương mại rủi ro kết hợp) Tôi đoán rằng tôi có một số quan sát về điều này. Một số trường hợp góc quan trọng là:

• Nếu tổng số trường cơ sở dữ liệu trên các kiểu con tương đối thấp (giả sử: dưới 100) hoặc có sự phổ biến đáng kể giữa các kiểu con thì việc tách các kiểu con ra thành các bảng vật lý riêng biệt có lẽ ít có giá trị. Nó sẽ thêm chi phí đáng kể để báo cáo truy vấn và tìm kiếm. Trong hầu hết các trường hợp, tốt nhất là có một bảng duy nhất và quản lý phân nhóm của bạn trong ứng dụng. (Có lẽ là gần nhất với vấn đề của bạn)

• Nếu phân nhóm của bạn rất rời rạc và các kiểu con khác nhau có cấu trúc dữ liệu phụ thuộc kiểu treo chúng (ví dụ: bảng con hoặc cấu trúc phức tạp hơn), thì bảng phụ có ý nghĩa. Trong trường hợp này, mỗi kiểu con có thể có tương đối ít trong ứng dụng (có lẽ có toàn bộ hệ thống con trong ứng dụng dành riêng cho kiểu con đó). Hầu hết báo cáo và truy vấn có thể sẽ xảy ra trong một loại phụ nhất định, với các truy vấn loại chéo chủ yếu bị hạn chế ở một số trường phổ biến. (Hệ thống quản lý vụ án)

• Nếu bạn có một số lượng lớn các kiểu con với các thuộc tính khác nhau và / hoặc yêu cầu để làm cho cấu hình này thì cấu trúc chung và siêu dữ liệu bổ sung có thể phù hợp hơn. Xem bài đăng SO này để nhận được một số cách tiếp cận có thể. (Hệ thống quản lý chính sách bảo hiểm)

• Nếu bạn có một số lượng rất lớn các trường có ít điểm chung giữa các loại phụ của bạn và ít yêu cầu truy vấn trên các bảng loại phụ (nghĩa là không có gì nhiều trong cách kết hợp bên ngoài đa chiều so với các bảng loại phụ của bạn) thì hãy phụ loại bảng có thể giúp quản lý cột ngổn ngang. (Phiên bản phức tạp về bệnh lý của vấn đề của bạn)

• Một số người lập bản đồ O / R chỉ có thể hỗ trợ một cách tiếp cận cụ thể để quản lý các lớp con.

Trong hầu hết các trường hợp, các bảng loại phụ vật lý trong lược đồ DB là một chút giải pháp để tìm kiếm một vấn đề, vì chúng có khả năng có tác dụng phụ không mong muốn.

Trong trường hợp của bạn, tôi giả sử bạn có số lượng loại phụ tương đối khiêm tốn và số lượng thuộc tính có thể quản lý được. Sơ đồ và câu hỏi của bạn không cho thấy bất kỳ ý định treo bảng con khỏi hồ sơ. Tôi sẽ đề nghị bạn xem xét việc sử dụng tùy chọn đầu tiên được đề xuất ở trên và duy trì một bảng và quản lý việc gõ phụ trong ứng dụng của bạn.

Trước tiên hãy xem xét việc phát triển một mô hình dữ liệu logic bằng cách sử dụng các quy tắc phân cấp mô hình hóa dữ liệu được tìm thấy trong Mô hình mô hình doanh nghiệp , một cuốn sách của David Hay. Khi tạo cấu trúc phân cấp, mỗi lần xuất hiện (hàng) phải là một và chỉ một kiểu con. Điều này có nghĩa là các loại phụ là loại trừ lẫn nhau. Việc phân loại phải dựa trên một đặc tính duy nhất, cơ bản, không thay đổi. Sử dụng quy tắc cơ bản này sẽ cung cấp rất nhiều sự rõ ràng cho mô hình của bạn. Trong mô hình bạn có, một đặc điểm duy nhất để phân loại là mục đích của thiết bị - điện thoại, bộ chuyển đổi mạng, máy tính, bộ định tuyến, v.v. Mỗi thiết bị phải là một, và chỉ một, trong số các loại này. Vì vậy, ví dụ vị trí sẽ không phải là một loại phụ. Các thuộc tính như địa chỉ IP thuộc loại siêu.

Tôi nghĩ bạn sẽ thấy rằng số loại thiết bị sẽ đủ lớn để đảm bảo mẫu EAV như được đề cập trong câu trả lời khác. Cuốn sách David Hay tôi tham khảo bao gồm mô hình này rất hiệu quả. Tuy nhiên, nếu số lượng loại phụ ít, bạn có thể quy tắc quyết định chỉ thực hiện một bảng siêu loại có nhiều cột không thể, chỉ các bảng loại phụ có cột trùng lặp hoặc cả hai. Nếu mỗi loại phụ khác nhau rất nhiều trong các thuộc tính của nó và không có mối quan hệ nào ở cấp siêu loại, bạn có thể chỉ đi với các bảng loại phụ. Nếu điều ngược lại là đúng, bạn có thể chỉ đi với các bảng siêu loại. Nếu có sự pha trộn, sau đó thực hiện cả hai.

Lưu ý cuối cùng, bạn luôn có thể triển khai mẫu EAV dưới dạng lược đồ bảng cơ sở và sau đó tạo lớp trừu tượng dạng xem trình bày dữ liệu cho ứng dụng dưới dạng bảng siêu và loại phụ. Điều này cho phép bạn linh hoạt ở lớp lưu trữ nhưng khả năng hiểu ở lớp xem ứng dụng.

Một sản phẩm không phải là hàng tồn kho. Hàng tồn kho và sản phẩm là khác biệt.

Một sản phẩm thực sự là một đặc điểm kỹ thuật của một sản phẩm, không phải là một vật lý.

Vật chất là một Tài sản mà công ty sở hữu (hoặc cửa hàng). Bạn có thể có tài sản mà bạn theo dõi theo số sê-ri (tài sản riêng) hoặc tài sản mà bạn chỉ theo dõi theo số lượng (tài sản tồn kho).

Tôi sẽ xem cuốn Sách tài nguyên mô hình dữ liệu của Silverston Tập 1. Anh ấy có một lược đồ tốt cho các sản phẩm tự hào, tính năng, giá cả, hàng tồn kho. Nó sẽ giúp bạn tiết kiệm rất nhiều thời gian.

Một trong những câu hỏi tôi sẽ hỏi là tại sao bạn theo dõi các thuộc tính khác nhau của các mặt hàng tồn kho của bạn? - Hay cụ thể hơn, bạn đang làm gì với thông tin thuộc tính này?

Nếu bạn có nhiều báo cáo hoặc biểu mẫu có ý nghĩa cụ thể về các thuộc tính cụ thể thì bạn cần sử dụng phương pháp được đề xuất bởi ConcernedOfTunbridgeWell. Mặt khác, các thuộc tính này được ghi lại để liệt kê chúng hoặc có thể so sánh chúng với các thuộc tính giống như của các thiết bị tương tự, thì bạn thực sự có thể có một lý do tốt (hiếm) để sử dụng EAV. Tôi biết rằng "EAV là tà ác thuần túy" vì nhiều lý do, ngoại trừ những trường hợp rất hiếm khi những lý do đó không xảy ra đối với một ứng dụng cụ thể. Bạn có thể là một ứng dụng như vậy.

Hãy xem câu trả lời này liên quan đến thiết kế hệ thống kiểm kê thiết bị và câu trả lời này liên quan đến thiết kế hệ thống danh mục sản phẩm để xem cách tiếp cận EAV có thể đơn giản hóa ứng dụng của bạn cùng với thảo luận về chính xác những rủi ro của EAV là gì và làm thế nào để đánh giá xem những rủi ro đó có thể không áp dụng cho ứng dụng cụ thể của bạn.