La mejor estructura de base de datos relacional para estos datos.

Estoy en el proceso de crear un esquema de base de datos para el siguiente escenario:

• Hay usuarios
• Los usuarios tienen roles (como "Desarrollador" o "CEO")
• Los roles tienen aplicaciones (como "Topdesk")
• Las aplicaciones tienen permisos (como "Actualizar la base de conocimiento")
• Un rol puede tener permisos, si el rol ya tiene acceso a la aplicación

Suponiendo que no exista un entorno de alto rendimiento (sin necesidad de optimizar la velocidad), ¿cuál sería la mejor manera de implementar este esquema? El entorno de la base de datos puede ser MySQL, MSSQL ... se trata más del diseño de la base de datos relacional.

Yo mismo se me ocurrió lo siguiente:

La parte de la que no estoy más seguro es, por supuesto, la tabla Aplicaciones_Permisos_Roles. Es una tabla de enlace encima de otra tabla de enlace. Nunca he usado o visto esto antes. Otra forma de hacerlo sería reemplazarlo con una tabla de vinculación entre Roles y Permisos, y luego usar código o restricciones para garantizar las relaciones requeridas ... pero eso no me parece una buena solución. Estas cosas deben aplicarse en el nivel de la base de datos si es posible (y parece posible), no en el nivel del código.

En segundo lugar, ¿se requiere el enlace entre Permissions.Application y Applications.Id? Lo uso porque puede que no haya filas en Roles_Applications (como cuando acaba de agregar una nueva aplicación) y luego no es posible determinar qué permisos pertenecen a cada aplicación. También es un punto de referencia único para buscar a qué aplicación pertenece un permiso. Supongo que esto es correcto, pero también hace un círculo en el diseño de la base de datos. Errores de MSSQL en él al intentar establecer ON_DELETE u ON_UPDATE en cascada.

¿Alguna sugerencia, o es así como se supone que debe hacerse? Por cierto, cualquier otra sugerencia con respecto a la convención de nomenclatura y similares también es bienvenida (tal vez como comentario)

Gracias
Luc

Editar: título cambiado, con suerte haciéndolo más claro. El anterior fue más completo, pero probablemente demasiado complicado.

La forma en que lo has modelado está bien. Su modelo garantiza que la base de datos aplique las reglas de negocio.

Hay un par de cosas que podrías hacer como alternativa. Una sería eliminar la clave sustituta Roles_Applications. Como tabla de intersección, puede usar las dos claves foráneas juntas como una clave primaria compuesta. Si hicieras esto, eso se propagaría Roley Applicationbajaría a tu Applications_Permissions_Rolesmesa. Esto tendría la ventaja de brindarle una "ventanilla única" para los datos de permisos de su aplicación (es decir, menos uniones) sin comprometer su normalización de ninguna manera.

Otra forma de hacerlo sería simplificar ligeramente y definir un permiso predeterminado para cada aplicación. Puede llamarlo como quiera, como "acceso predeterminado" o "acceso básico" o "usuario" o lo que tenga sentido para usted. Esto le permitiría aplanar su modelo y esencialmente soltar la Roles_Applicationstabla y unirse Applications_Permissions_Rolesdirectamente a ella Roles. Esto cambiaría la naturaleza de la consulta que usaría para preguntar "¿qué roles pueden acceder a qué aplicaciones?" pero las reglas de su negocio seguirían siendo aplicadas por el esquema.

Roles_ApplicationNo parece representar una cosa real aquí. ¿Qué es, más allá de indicar que un rol en particular tiene cierto nivel de permisos para una aplicación, a pesar de que necesita verificar Applications_Permissions_Rolespara determinar cuál es ese nivel? Como ejemplo, aquí hay un CEO que obtiene acceso de escritura a la aplicación Calendario en su modelo actual:

Roles

ID    Name
--    ----
1     CEO

Aplicaciones

ID    Name
--    ----
C     Calendar

Permisos

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

Roles_Aplicaciones

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

Aplicaciones_Permisos_Roles

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

Creo que esta serie de relaciones se puede modelar sin el Roles_Applications. Si eliminamos eso (como sugiere Joel Brown, pero sin el cambio de suponer que hay "permisos predeterminados"):

Roles

ID    Name
--    ----
1     CEO

Aplicaciones

ID    Name
--    ----
C     Calendar

Aplicaciones_Permisos (nee Permissions)

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

Aplicaciones_Permisos_Roles

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

La Permissionstabla anterior no tiene simplemente permisos, como "leer" y "escribir", que luego se pueden aplicar a aplicaciones como "Topdesk" y "Calendario": contiene permisos específicos de la aplicación, como "escribir en Topdesk" y " escriba en Calendario "y" Cambiar reloj del sistema en Windows ". Para aclararlo, he nombrado la tabla, Applications_Permissionspero, por supuesto, ese no es un paso necesario.

Este enfoque tiene el efecto de aplanar el modelo, como lo hace la segunda sugerencia de Joel, pero sin agregar la lógica de la aplicación o el concepto de permisos predeterminados. Roles_Applicationsno aportaba nada a la fiesta que no fuera una indicación de que un rol tiene cierto nivel de acceso a una aplicación. Esa información se transmite con más brevedad por la existencia de un registro Applications_Permissions_Rolescon el valor adecuado de Role_ID.