Migliore struttura di database relazionale per questi dati

Sono in procinto di creare uno schema di database per il seguente scenario:

• Ci sono utenti
• Gli utenti hanno ruoli (come "Sviluppatore" o "CEO")
• I ruoli hanno applicazioni (come "Topdesk")
• Le applicazioni hanno autorizzazioni (come "Aggiorna la knowledge base")
• Un ruolo può disporre delle autorizzazioni, se il ruolo ha già accesso all'applicazione

Supponendo che non esistano ambienti ad alte prestazioni (nessuna necessità di ottimizzazione per la velocità), quale sarebbe il modo migliore per implementare questo schema? L'ambiente del database può essere MySQL, MSSQL ... riguarda maggiormente la progettazione del database relazionale.

Io stesso ho ideato quanto segue:

La parte di cui sono più incerto è ovviamente la tabella Applications_Permissions_Roles. È una tabella di collegamento in cima a un'altra tabella di collegamento. Non l'ho mai visto o visto prima. Un altro modo per farlo sarebbe quello di sostituirlo con una tabella di collegamento tra Ruoli e Autorizzazioni, e quindi utilizzare il codice o i vincoli per garantire le relazioni richieste ... ma non mi sembra una buona soluzione. Queste cose dovrebbero essere applicate a livello di database se possibile (e sembra possibile), non a livello di codice.

In secondo luogo, è necessario il collegamento tra Permissions.Application e Applications.Id? Lo uso perché potrebbero non esserci righe in Roles_Applications (come quando hai appena aggiunto una nuova applicazione) e quindi non è possibile capire quali autorizzazioni appartengono a quale applicazione. È anche un unico punto di riferimento per cercare a quale applicazione appartiene un'autorizzazione. Immagino sia giusto, ma crea anche un cerchio nella progettazione del database. Errori MSSQL su di esso quando si tenta di impostare ON_DELETE o ON_UPDATE su cascata.

Qualche suggerimento o è come dovrebbe essere fatto? Qualsiasi altro suggerimento riguardante la convenzione di denominazione e simili sono comunque ben accetti (forse come commento).

Grazie
Luc

Modifica: titolo modificato, si spera rendendolo più chiaro. Il precedente era più completo, ma probabilmente troppo contorto.

Il modo in cui l'hai modellato va bene. Il modello garantisce che le regole aziendali siano applicate dal database.

Ci sono un paio di cose che potresti fare in alternativa. Uno sarebbe quello di eliminare la chiave surrogata Roles_Applications. Come tabella di intersezione, è possibile utilizzare le due chiavi esterne insieme come chiave primaria composita. Se avete fatto queste cose, che sarebbe propagarsi Rolee Applicationgiù al vostro Applications_Permissions_Rolestavolo. Ciò avrebbe il vantaggio di offrirti più di uno "sportello unico" per i dati di autorizzazione della tua applicazione (cioè meno join) senza compromettere la tua normalizzazione in alcun modo.

Un altro modo in cui potresti procedere sarebbe semplificare leggermente e definire un'autorizzazione predefinita per ogni applicazione. Potresti chiamarlo come preferisci, come "accesso predefinito" o "accesso di base" o "utente" o qualunque cosa abbia senso per te. Ciò ti consentirebbe di appiattire il tuo modello e essenzialmente di abbandonare il Roles_Applicationstavolo e unirti Applications_Permissions_Rolesdirettamente Roles. Ciò cambierebbe la natura della query che useresti per chiedere "a quali ruoli può accedere quali applicazioni?" ma le tue regole aziendali verrebbero comunque applicate dallo schema.

Roles_Applicationnon sembra rappresentare una cosa reale qui. Cos'è, oltre a significare che un determinato ruolo ha un certo livello di autorizzazioni per un'applicazione, anche se è necessario verificare Applications_Permissions_Rolesper determinare quale sia quel livello? Ad esempio, ecco un CEO che ottiene l'accesso in scrittura al calendario dell'applicazione nel modello corrente:

ruoli

ID    Name
--    ----
1     CEO

applicazioni

ID    Name
--    ----
C     Calendar

permessi

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

Penso che questa serie di relazioni possa essere modellata senza il Roles_Applications. Se lo rimuoviamo (come suggerisce Joel Brown, ma senza il cambiamento di presupporre che ci siano "autorizzazioni predefinite"):

ruoli

ID    Name
--    ----
1     CEO

applicazioni

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

La vecchia Permissionstabella non ha semplicemente autorizzazioni, come "lettura" e "scrittura", che possono quindi essere applicate ad applicazioni come "Topdesk" e "Calendario": contiene autorizzazioni specifiche dell'applicazione, come "scrivi in ​​Topdesk" e " scrivi in ​​Calendario "e" Cambia orologio di sistema in Windows ". Per renderlo più chiaro ho chiamato la tabella, Applications_Permissionsma ovviamente non è un passaggio necessario.

Questo approccio ha l'effetto di appiattire il modello, così come il secondo suggerimento di Joel, ma senza aggiungere la logica dell'applicazione o il concetto di autorizzazioni predefinite. Roles_Applicationsnon stava portando alla festa altro che un'indicazione che un ruolo ha un certo livello di accesso a un'applicazione. Tale informazione viene trasmessa con maggiore brevità dall'esistenza di un record Applications_Permissions_Rolescon il valore corretto di Role_ID.