Cấu trúc cơ sở dữ liệu quan hệ tốt nhất cho dữ liệu này

Tôi đang trong quá trình tạo sơ đồ cơ sở dữ liệu cho kịch bản sau:

• Có người dùng
• Người dùng có vai trò (chẳng hạn như "Nhà phát triển" hoặc "CEO")
• Vai trò có các ứng dụng (chẳng hạn như "Topdesk")
• Các ứng dụng có quyền (chẳng hạn như "Cập nhật kiến ​​thức")
• Một vai trò có thể có quyền, nếu vai trò đã có quyền truy cập vào ứng dụng

Giả sử không có môi trường hiệu năng cao (không cần tối ưu hóa tốc độ), cách tốt nhất để thực hiện lược đồ này là gì? Môi trường cơ sở dữ liệu có thể là MySQL, MSSQL ... đó là về thiết kế cơ sở dữ liệu quan hệ.

Bản thân tôi đã đưa ra những điều sau đây:

Tất nhiên, phần tôi không chắc chắn nhất là bảng Application_Permissions_Roles. Nó là một bảng liên kết trên đầu bảng liên kết khác. Tôi chưa bao giờ sử dụng hoặc nhìn thấy điều này trước đây. Một cách khác để làm điều đó là thay thế nó bằng một bảng liên kết giữa Vai trò và Quyền, sau đó sử dụng mã hoặc các ràng buộc để đảm bảo các mối quan hệ cần thiết ... nhưng đó dường như không phải là một giải pháp tốt cho tôi. Những điều này nên được thi hành ở cấp cơ sở dữ liệu nếu có thể (và dường như có thể), chứ không phải ở cấp mã.

Thứ hai, là liên kết giữa Quyền. Ứng dụng và Ứng dụng. Tôi có cần thiết không? Tôi sử dụng nó bởi vì có thể không có bất kỳ hàng nào trong Roles_Applecting (chẳng hạn như khi bạn vừa thêm một ứng dụng mới) và sau đó không thể tìm ra quyền nào thuộc về ứng dụng nào. Nó cũng là một điểm tham chiếu duy nhất để tra cứu ứng dụng nào thuộc quyền. Tôi đoán điều này là đúng, nhưng nó cũng tạo ra một vòng tròn trong thiết kế cơ sở dữ liệu. Lỗi MSSQL trên đó khi cố gắng đặt ON_DELETE hoặc ON_UPDATE thành xếp tầng.

Bất kỳ đề xuất, hoặc đây là cách nó phải được thực hiện? Bất kỳ đề xuất nào khác liên quan đến quy ước đặt tên và như vậy cũng được hoan nghênh (có lẽ là nhận xét).

Cảm ơn,
Lục

Chỉnh sửa: Thay đổi tiêu đề, hy vọng làm cho nó rõ ràng hơn. Cái trước là toàn diện hơn, nhưng có lẽ quá phức tạp.

Cách bạn mô hình hóa nó là tốt. Mô hình của bạn đảm bảo rằng các quy tắc kinh doanh được thực thi bởi cơ sở dữ liệu.

Có một vài điều bạn có thể làm thay thế. Một là sẽ loại bỏ khóa thay thế trên Roles_Applications. Là một bảng giao nhau, bạn có thể sử dụng hai khóa ngoại với nhau làm khóa chính tổng hợp. Nếu bạn đã làm điều này, điều đó sẽ lan truyền Rolevà Applicationxuống Applications_Permissions_Rolesbàn của bạn . Điều này sẽ có lợi thế là cung cấp cho bạn nhiều hơn "một cửa" cho dữ liệu cấp phép ứng dụng của bạn (tức là ít tham gia hơn) mà không ảnh hưởng đến việc bình thường hóa của bạn dưới bất kỳ hình thức nào.

Một cách khác bạn có thể đi là đơn giản hóa một chút và xác định quyền mặc định cho mỗi ứng dụng. Bạn có thể gọi nó là bất cứ điều gì bạn thích, chẳng hạn như "truy cập mặc định" hoặc "truy cập cơ bản" hoặc "người dùng" hoặc bất cứ điều gì có ý nghĩa với bạn. Điều này sẽ cho phép bạn làm phẳng mô hình của mình và về cơ bản thả Roles_Applicationsbảng và tham gia Applications_Permissions_Rolesthẳng vào Roles. Điều này sẽ thay đổi bản chất của truy vấn mà bạn sẽ sử dụng để hỏi "vai trò nào có thể truy cập ứng dụng nào?" nhưng các quy tắc kinh doanh của bạn vẫn sẽ được thực thi bởi lược đồ.

Roles_Applicationkhông xuất hiện để đại diện cho một điều thực sự ở đây. Nó là gì, ngoài việc biểu thị rằng một vai trò cụ thể có một số cấp phép cho ứng dụng, mặc dù bạn cần kiểm tra Applications_Permissions_Rolesđể xác định mức đó là gì? Ví dụ, đây là một CEO nhận được quyền truy cập ghi vào ứng dụng Lịch trong mô hình hiện tại của bạn:

Vai trò

ID    Name
--    ----
1     CEO

Các ứng dụng

ID    Name
--    ----
C     Calendar

Quyền

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Roles_Applecting

ID    Role_ID    Application_ID
--    -------    --------------
50    1          C

Ứng dụng_Permissions_Roles

Role_Application_ID    Permission_ID
-------------------    -------------
50                     10

Tôi nghĩ rằng loạt các mối quan hệ này có thể được mô hình hóa mà không có Roles_Applications. Nếu chúng tôi xóa điều đó (như Joel Brown gợi ý, nhưng không thay đổi giả định có "quyền mặc định"):

Vai trò

ID    Name
--    ----
1     CEO

Các ứng dụng

ID    Name
--    ----
C     Calendar

Ứng dụng_Permissions (nee Permissions)

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Ứng dụng_Permissions_Roles

Role_ID    Application_Permission_ID
-------    -------------
1          10

Bảng cũ Permissionskhông có các quyền đơn giản, như "đọc" và "ghi", sau đó có thể được áp dụng cho các ứng dụng như "Topdesk" và "Lịch": Nó chứa các quyền cụ thể của ứng dụng, như "write in Topdesk" và " viết trong Lịch "và" Thay đổi đồng hồ hệ thống trong Windows ". Để làm cho rõ ràng hơn, tôi đã đặt tên cho bảng Applications_Permissionsnhưng tất nhiên đó không phải là một bước cần thiết.

Cách tiếp cận này có tác dụng làm phẳng mô hình, cũng như đề xuất thứ hai của Joel, nhưng không thêm logic ứng dụng hoặc khái niệm về quyền mặc định. Roles_Applicationskhông mang lại bất cứ điều gì cho bên ngoài một dấu hiệu cho thấy vai trò có một số mức độ truy cập vào ứng dụng. Thông tin đó được truyền tải với sự ngắn gọn hơn bởi sự tồn tại của một bản ghi Applications_Permissions_Rolesvới giá trị phù hợp của Role_ID.