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:

Diagrama ERD

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.

database-design normalization relational-theory

— Luc
fuente

No estoy seguro de haber pensado en la interacción de roles, aplicaciones y permisos. ¿Cada rol / aplicación tiene un permiso específico que es independiente de las otras aplicaciones de un rol? Por ejemplo, un CEO / Topdesk podría tener solo permiso de lectura, mientras que un CEO / Calendario podría haber escrito?

— mdoyle

No entiendo lo que quiere decir "mejor esquema de base de datos relacional para estos datos", ¿qué motor quiere decir? ¿Como Postgres o MySQL o MSSQL o ... etc.?

— jcolebrand

@jcolebrand Supongo que el título es aún menos claro que antes ... Quizás "estructura de base de datos" es una palabra mejor. El diseño de la tabla y las relaciones (claves foráneas, etc.).

— Luc

@mdoyle Los permisos siempre están dentro de una aplicación (ejemplo: permiso 'cambiar el reloj del sistema' en la aplicación 'ventanas') y, por lo tanto, un permiso pertenece exactamente a una aplicación. Un rol puede tener permisos y aplicaciones, la única restricción es que si tiene algún permiso, también debe tener acceso a la aplicación a la que pertenecen los permisos. (Obviamente, si no puede usar Topdesk, no puede tener permiso para 'Actualizar la base de conocimiento' para la aplicación Topdesk). ¿Esto lo aclara?

— Luc

No estoy convencido de que Roles_Applicationssea algo real. Dado que todos los permisos son específicos de la aplicación, parece que hay Applications_Permissions(lo que ha etiquetado Permissions), que luego pueden asignarse a roles específicos a través de un registro Applications_Permissions_Roles. Roles_Applications, de hecho, parece estar describiendo el permiso de aplicación más básico: acceso simple. O bien, está afirmando que un rol tiene cierto nivel de permisos para una aplicación, pero debe buscar en otro lugar para determinar cuáles.

— mdoyle

Respuestas:

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.

— Joel Brown
fuente

¡Gracias por su respuesta! Todavía no había pensado en estas sugerencias. Sin embargo, la segunda sugerencia agregaría mucha lógica de aplicación: todos los lugares que manejan permisos deberían verificar si una operación no se realiza con el permiso predeterminado (ya que eso no debería ser mutable o tal vez ni siquiera mostrado); y todo lo relacionado con las aplicaciones debe asegurarse de que el permiso predeterminado se cree o elimine adecuadamente. Simplificaría la base de datos, pero a un costo más alto parece. Sin embargo, la primera sugerencia es una opción, creo que implementaré esto. Gracias de nuevo por la revisión :)

— Luc

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.

— mdoyle
fuente

Bien, entiendo a qué te refieres ahora. El problema es que uno no siempre tiene permisos en una aplicación. Al igual que con Microsoft Word, simplemente no hay ninguno. En esos casos, se desconoce qué rol puede acceder a qué aplicación; siempre debe tener al menos un permiso de esa aplicación asignado a un rol. Para eso fue la sugerencia de "permiso predeterminado" de Joel Brown. Gracias por la sugerencia sin embargo! No es una mala idea y tiene sentido, pero simplemente no puedo aplicarlo a mi situación. * Votado *

— Luc

Para algo como Word, ¿no es "ejecutar" un permiso? Pero veo su punto si, por alguna razón, ejecutar o acceder a una aplicación no se considera un permiso.

— mdoyle