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:

Diagramme ERD

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.

database-design normalization relational-theory

— Luc
source

Je ne suis pas sûr d'avoir pensé à l'interaction des rôles, des applications et des autorisations. Chaque rôle / application dispose d'une autorisation spécifique indépendante des autres applications d'un rôle? Par exemple, un PDG / Topdesk peut n'avoir qu'une autorisation de lecture, alors qu'un PDG / Calendrier peut avoir une écriture?

— mdoyle

Je ne comprends pas ce que vous entendez par "meilleur schéma de base de données relationnelle pour ces données", par quel moteur? Comme Postgres ou MySQL ou MSSQL ou ... etc?

— jcolebrand

@jcolebrand Je suppose que le titre est encore moins clair qu'auparavant ... Peut-être que "structure de base de données" est un meilleur mot. La disposition et les relations de la table (clés étrangères, etc.).

— Luc

@mdoyle Les autorisations sont toujours dans une application (exemple: autorisation «changer l'horloge système» dans les «fenêtres» d'application) et donc une autorisation appartient à exactement une application. Un rôle peut avoir à la fois des autorisations et des applications, la seule contrainte étant que si vous avez des autorisations, vous devez également avoir accès à l'application à laquelle les autorisations appartiennent. (Évidemment, si vous ne pouvez pas utiliser Topdesk, vous ne pouvez pas avoir l'autorisation 'Mettre à jour la base de connaissances' pour l'application Topdesk.) Est-ce que c'est plus clair?

— Luc

Je ne suis pas convaincu que ce Roles_Applicationssoit une chose réelle. Étant donné que toutes les autorisations sont spécifiques à l'application, il semble qu'il y en ait Applications_Permissions(ce que vous avez étiqueté Permissions), qui peuvent ensuite être attribués à des rôles spécifiques via un enregistrement dans Applications_Permissions_Roles. Roles_Applications, en fait, semble décrire l'autorisation d'application la plus élémentaire - un accès simple. Ou bien, il affirme qu'un rôle a un certain niveau d'autorisations pour une application, mais vous devez chercher ailleurs pour déterminer lesquelles.

— mdoyle

Réponses:

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.

— Joel Brown
source

Merci pour votre réponse! Je n'avais pas encore pensé à ces suggestions. La deuxième suggestion ajouterait cependant beaucoup de logique d'application: tous les endroits qui gèrent les autorisations devraient vérifier si une opération n'est pas effectuée sur l'autorisation par défaut (car cela ne devrait pas être modifiable ou peut-être même affiché); et tout ce qui concerne les applications doit s'assurer que l'autorisation par défaut est créée ou supprimée de manière appropriée. Cela simplifierait la base de données, mais à un coût plus élevé, semble-t-il. La première suggestion est cependant une option, je pense que je vais implémenter cela. Merci encore pour l'avis :)

— Luc

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.

— mdoyle
source

D'accord, je vois ce que tu veux dire maintenant. Le problème est que l'on n'a pas toujours les autorisations sur une application. Comme avec Microsoft Word, il n'y en a tout simplement pas. Dans ces cas, on ne sait pas quel rôle peut accéder à quelle application; vous devez toujours avoir au moins une autorisation de cette application attribuée à un rôle. C'est à cela que servait la suggestion de «permission par défaut» de Joel Brown. Merci pour la suggestion! Ce n'est pas une mauvaise idée et c'est logique, mais je ne peux tout simplement pas l'appliquer à ma situation. * Surévalué *

— Luc

Pour quelque chose comme Word, "exécuter" n'est-il pas une autorisation? Mais je vois votre point de vue si, pour une raison quelconque, l'exécution ou l'accès à une application n'est pas considéré comme une autorisation.

— mdoyle