Meilleure structure de base de données relationnelle pour ces données

Je suis en train de créer un schéma de base de données pour le scénario suivant:

• Il y a des utilisateurs
• Les utilisateurs ont des rôles (tels que "développeur" ou "PDG")
• Les rôles ont des applications (telles que "Topdesk")
• Les applications ont des autorisations (telles que "Mettre à jour la base de connaissances")
• Un rôle peut avoir des autorisations, si le rôle a déjà accès à l'application

En supposant qu'aucun environnement haute performance (pas besoin d'optimiser pour la vitesse), quelle serait la meilleure façon de mettre en œuvre ce schéma? L'environnement de base de données peut être MySQL, MSSQL ... il s'agit plus de la conception de base de données relationnelle.

J'ai moi-même trouvé ce qui suit:

La partie dont je suis le plus incertain est bien sûr la table Applications_Permissions_Roles. Il s'agit d'une table de liaison au- dessus d' une autre table de liaison. Je n'ai jamais utilisé ou vu cela auparavant. Une autre façon de le faire serait de le remplacer par une table de liaison entre les rôles et les autorisations, puis d'utiliser du code ou des contraintes pour assurer les relations requises ... mais cela ne me semble pas être une bonne solution. Ces choses devraient être appliquées au niveau de la base de données si possible (et cela semble possible), pas au niveau du code.

Deuxièmement, le lien entre Permissions.Application et Applications.Id est-il requis? Je l'utilise car il peut ne pas y avoir de lignes dans Roles_Applications (comme lorsque vous venez d'ajouter une nouvelle application) et qu'il n'est alors pas possible de déterminer quelles autorisations appartiennent à quelle application. Il s'agit également d'un point de référence unique pour rechercher à quelle application appartient une autorisation. Je suppose que c'est vrai, mais cela fait également un cercle dans la conception de la base de données. Erreurs MSSQL dessus lors de la tentative de mise en cascade de ON_DELETE ou ON_UPDATE.

Avez-vous des suggestions ou est-ce ainsi que c'est censé être fait? D'ailleurs, toute autre suggestion concernant la convention de dénomination et autres est également la bienvenue (peut-être comme commentaire).

Merci,
Luc

Edit: Changement du titre, espérons-le rendre plus clair. La précédente était plus complète, mais probablement trop compliquée.

La façon dont vous l'avez modélisée est très bien. Votre modèle garantit que les règles métier sont appliquées par la base de données.

Il y a deux ou trois choses que vous pourriez faire comme alternative. L'une serait d'éliminer la clé de substitution Roles_Applications. En tant que table d'intersection, vous pouvez utiliser les deux clés étrangères ensemble comme clé primaire composite. Si vous avez fait cela, qui se propagerait Roleet Applicationvers le bas à votre Applications_Permissions_Rolestable. Cela aurait l'avantage de vous offrir davantage de "guichet unique" pour vos données d'autorisation d'application (c'est-à-dire moins de jointures) sans compromettre votre normalisation de quelque manière que ce soit.

Vous pouvez également simplifier légèrement et définir une autorisation par défaut pour chaque application. Vous pouvez l'appeler comme vous le souhaitez, comme «accès par défaut» ou «accès de base» ou «utilisateur» ou tout ce qui vous semble logique. Cela vous permettrait d'aplatir votre modèle et de laisser tomber la Roles_Applicationstable et de la rejoindre Applications_Permissions_Rolesdirectement Roles. Cela changerait la nature de la requête que vous utiliseriez pour demander "quels rôles peuvent accéder à quelles applications?" mais vos règles métier seraient toujours appliquées par le schéma.

Roles_Applicationne semble pas représenter une vraie chose ici. Qu'est-ce que c'est, au-delà de signifier qu'un rôle particulier a un certain niveau d'autorisations sur une application, même si vous devez vérifier Applications_Permissions_Rolespour déterminer ce niveau? À titre d'exemple, voici un PDG qui obtient un accès en écriture au calendrier de l'application dans votre modèle actuel:

Les rôles

ID    Name
--    ----
1     CEO

Applications

ID    Name
--    ----
C     Calendar

Autorisations

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

Rôles_Applications

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

Applications_Permissions_Roles

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

Je pense que cette série de relations peut être modélisée sans Roles_Applications. Si nous supprimons cela (comme le suggère Joel Brown, mais sans le changement de supposer qu'il existe des "autorisations par défaut"):

Les rôles

ID    Name
--    ----
1     CEO

Applications

ID    Name
--    ----
C     Calendar

Applications_Permissions (nee Permissions)

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

Applications_Permissions_Roles

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

L'ancienne Permissionstable n'a pas simplement des autorisations, comme "lire" et "écrire", qui peuvent ensuite être appliquées à des applications comme "Topdesk" et "Calendrier": elle contient des autorisations spécifiques à l'application, comme "écrire dans Topdesk" et " écrire dans le calendrier "et" Modifier l'horloge système sous Windows ". Pour clarifier les choses, j'ai nommé le tableau, Applications_Permissionsmais bien sûr, ce n'est pas une étape nécessaire.

Cette approche a pour effet d'aplatir le modèle, comme le fait la deuxième suggestion de Joel, mais sans ajouter de logique d'application ni de concept d'autorisations par défaut. Roles_Applicationsn'apportait rien à la partie autre qu'une indication qu'un rôle a un certain niveau d'accès à une application. Cette information est transmise avec plus de brièveté par l'existence d'un enregistrement Applications_Permissions_Rolesavec la valeur appropriée de Role_ID.