Beste relationale Datenbankstruktur für diese Daten

Ich bin dabei, ein Datenbankschema für das folgende Szenario zu erstellen:

Es gibt Benutzer
Benutzer haben Rollen (wie "Entwickler" oder "CEO")
Rollen haben Anwendungen (wie "Topdesk")
Anwendungen verfügen über Berechtigungen (z. B. "Update Knowledgebase").
Eine Rolle kann Berechtigungen haben, wenn die Rolle bereits Zugriff auf die Anwendung hat

Unter der Annahme, dass keine Hochleistungsumgebung vorhanden ist (keine Geschwindigkeitsoptimierung erforderlich), wie lässt sich dieses Schema am besten implementieren? Die Datenbankumgebung kann MySQL, MSSQL sein ... es geht mehr um das relationale Datenbankdesign.

Ich selbst habe mir Folgendes ausgedacht:

ERD-Diagramm

Der Teil, über den ich am unsichersten bin, ist natürlich die Tabelle Applications_Permissions_Roles. Es ist eine Verknüpfungstabelle über einer anderen Verknüpfungstabelle. Ich habe das noch nie benutzt oder gesehen. Eine andere Möglichkeit wäre, es durch eine Verknüpfungstabelle zwischen Rollen und Berechtigungen zu ersetzen und dann Code oder Einschränkungen zu verwenden, um die erforderlichen Beziehungen sicherzustellen ... aber das scheint mir keine gute Lösung zu sein. Diese Dinge sollten auf Datenbankebene erzwungen werden, wenn dies überhaupt möglich ist (und es scheint möglich zu sein), nicht auf Codeebene.

Zweitens ist die Verknüpfung zwischen Permissions.Application und Applications.Id erforderlich? Ich verwende es, weil es möglicherweise keine Zeilen in Roles_Applications gibt (z. B. wenn Sie gerade eine neue Anwendung hinzugefügt haben) und es dann nicht möglich ist, herauszufinden, welche Berechtigungen zu welcher Anwendung gehören. Es ist auch ein einziger Bezugspunkt für die Suche, zu welcher Anwendung eine Berechtigung gehört. Ich denke, das ist richtig, aber es macht auch einen Kreis im Datenbankdesign. MSSQL-Fehler beim Versuch, ON_DELETE oder ON_UPDATE auf Kaskade zu setzen.

Irgendwelche Vorschläge, oder soll es so gemacht werden? Alle anderen Vorschläge bezüglich der Namenskonvention und dergleichen sind übrigens ebenfalls willkommen (möglicherweise als Kommentar).

Danke,
Luc

Bearbeiten: Titel geändert, hoffentlich klarer. Der vorherige war umfassender, aber wahrscheinlich zu kompliziert.

database-design normalization relational-theory

— Luc
quelle

Ich bin mir nicht sicher, ob ich mich mit dem Zusammenspiel von Rollen, Anwendungen und Berechtigungen beschäftigt habe. Jede Rolle / Anwendung verfügt über eine bestimmte Berechtigung, die unabhängig von den anderen Anwendungen einer Rolle ist. Beispielsweise hat ein CEO / Topdesk möglicherweise nur Leseberechtigung, während ein CEO / Kalender möglicherweise eine Schreibberechtigung hat.

— Mdoyle

Ich verstehe nicht, was Sie unter "bestes relationales Datenbankschema für diese Daten" verstehen. Meinen Sie welche Engine? Wie Postgres oder MySQL oder MSSQL oder ... etc?

— Jcolebrand

@jcolebrand Vermutlich ist der Titel noch weniger klar als zuvor ... Vielleicht ist "Datenbankstruktur" ein besseres Wort. Das Tabellenlayout und die Beziehungen (Fremdschlüssel usw.).

— Luc

@mdoyle Berechtigungen befinden sich immer in einer Anwendung (Beispiel: Berechtigung 'Systemuhr ändern' in Anwendungsfenstern ') und somit gehört eine Berechtigung zu genau einer Anwendung. Eine Rolle kann sowohl Berechtigungen als auch Anwendungen haben. Die einzige Einschränkung besteht darin, dass Sie, wenn Sie über Berechtigungen verfügen, auch Zugriff auf die Anwendung haben müssen, zu der die Berechtigungen gehören. (Wenn Sie Topdesk nicht verwenden können, können Sie natürlich nicht die Berechtigung 'Knowledgebase aktualisieren' für die Anwendung Topdesk haben.) Macht dies dies klarer?

— Luc

Ich bin nicht davon überzeugt, dass Roles_Applicationsdas eine echte Sache ist. Angesichts der Tatsache, dass alle Berechtigungen anwendungsspezifisch sind, scheint es Applications_Permissions(was Sie gekennzeichnet haben Permissions) zu geben, die dann über einen Datensatz in bestimmten Rollen zugewiesen werden können Applications_Permissions_Roles. Roles_ApplicationsTatsächlich scheint es sich um die grundlegendste Anwendungsberechtigung zu handeln - den einfachen Zugriff. Oder es wird behauptet, dass eine Rolle über bestimmte Berechtigungen für eine Anwendung verfügt, Sie müssen jedoch anderswo nachsehen, um festzustellen, welche.

— Mdoyle

Antworten:

Die Art und Weise, wie Sie es modelliert haben, ist in Ordnung. Ihr Modell stellt sicher, dass die Geschäftsregeln von der Datenbank durchgesetzt werden.

Es gibt ein paar Dinge, die Sie als Alternative tun könnten. Eine wäre, den Ersatzschlüssel zu entfernen Roles_Applications. Als Schnittpunkttabelle können Sie die beiden Fremdschlüssel zusammen als zusammengesetzten Primärschlüssel verwenden. Wenn Sie dies getan haben, das würde ausbreiten Roleund Applicationbis zu Ihrem Applications_Permissions_RolesTisch. Dies hätte den Vorteil, dass Sie Ihre Anwendungsberechtigungsdaten (dh weniger Joins) mehr aus einer Hand erhalten, ohne Ihre Normalisierung in irgendeiner Weise zu beeinträchtigen.

Ein anderer Weg, den Sie gehen könnten, wäre, etwas zu vereinfachen und eine Standardberechtigung für jede Anwendung zu definieren. Sie können es so nennen, wie Sie möchten, z. B. "Standardzugriff" oder "Basiszugriff" oder "Benutzer" oder was auch immer für Sie sinnvoll ist. Auf diese Weise können Sie Ihr Modell reduzieren und die Roles_ApplicationsTabelle im Wesentlichen fallen lassen und Applications_Permissions_Rolesdirekt mit verbinden Roles. Dies würde die Art der Abfrage ändern, mit der Sie fragen würden, welche Rollen auf welche Anwendungen zugreifen können. Ihre Geschäftsregeln werden jedoch weiterhin vom Schema durchgesetzt.

— Joel Brown
quelle

Vielen Dank für Ihre Antwort! An diese Vorschläge hatte ich noch nicht gedacht. Der zweite Vorschlag würde jedoch viel Anwendungslogik hinzufügen: Alle Stellen, die Berechtigungen verarbeiten, sollten prüfen, ob eine Operation mit der Standardberechtigung nicht ausgeführt wird (da diese nicht veränderbar sein oder vielleicht sogar angezeigt werden sollte). und Dinge, die sich mit Anwendungen befassen, sollten sicherstellen, dass die Standardberechtigung entsprechend erstellt oder entfernt wird. Es würde die Datenbank vereinfachen, aber zu höheren Kosten scheint es. Der erste Vorschlag ist jedoch eine Option. Ich denke, ich werde dies umsetzen.

— Luc

Roles_Applicationscheint hier keine echte Sache zu sein. Was ist das, über was bedeutet , dass eine bestimmte Rolle hat eine Berechtigungsstufe für eine Anwendung, auch wenn Sie überprüfen müssen , Applications_Permissions_Rolesum festzustellen , was das Niveau ist? Als Beispiel erhält ein CEO Schreibzugriff auf den Anwendungskalender in Ihrem aktuellen Modell:

Rollen

ID    Name
--    ----
1     CEO

Anwendungen

ID    Name
--    ----
C     Calendar

Berechtigungen

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

Roles_Applications

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

Applications_Permissions_Roles

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

Ich denke, diese Reihe von Beziehungen kann ohne die modelliert werden Roles_Applications. Wenn wir das entfernen (wie Joel Brown vorschlägt, aber ohne die Änderung der Annahme, dass es "Standardberechtigungen" gibt):

Rollen

ID    Name
--    ----
1     CEO

Anwendungen

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

Die alte PermissionsTabelle verfügt nicht nur über Berechtigungen wie "Lesen" und "Schreiben", die dann auf Anwendungen wie "Topdesk" und "Kalender" angewendet werden können: Sie enthält anwendungsspezifische Berechtigungen wie "In Topdesk schreiben" und " In Kalender schreiben "und" Systemuhr in Windows ändern ". Um das klarer zu machen, habe ich die Tabelle benannt, Applications_Permissionsaber das ist natürlich kein notwendiger Schritt.

Dieser Ansatz hat den Effekt, dass das Modell abgeflacht wird, ebenso wie Joels zweiter Vorschlag, ohne jedoch Anwendungslogik oder das Konzept der Standardberechtigungen hinzuzufügen. Roles_Applicationsbrachte der Partei nichts anderes als einen Hinweis darauf, dass eine Rolle einen gewissen Grad an Zugriff auf eine Anwendung hat. Diese Informationen werden mit größerer Kürze durch das Vorhandensein eines Datensatzes Applications_Permissions_Rolesmit dem richtigen Wert von Role_ID übermittelt.

— mdoyle
quelle

Okay, ich verstehe, was du jetzt meinst. Das Problem ist, dass man nicht immer Berechtigungen für eine Anwendung hat. Wie bei Microsoft Word gibt es einfach keine. In diesen Fällen ist nicht bekannt, welche Rolle auf welche Anwendung zugreifen kann. Sie müssen immer mindestens eine Berechtigung von dieser Anwendung haben, die einer Rolle zugewiesen ist. Dafür war der Vorschlag "Standardberechtigung" von Joel Brown gedacht. Vielen Dank für den Vorschlag! Es ist keine schlechte Idee und macht Sinn, aber ich kann sie einfach nicht auf meine Situation anwenden. * Upvoted *

— Luc

Ist für etwas wie Word nicht eine Berechtigung "ausführen"? Aber ich verstehe Ihren Standpunkt, wenn das Ausführen oder Zugreifen auf eine Anwendung aus irgendeinem Grund nicht als Berechtigung angesehen wird.

— Mdoyle