Implementar la gestión de permisos del usuario en sistemas comerciales
Los permisos en el sistema B/S son más importantes que los de C/S. Debido a que el sistema C/S tiene un cliente especial, la detección de permisos de los usuarios de acceso se puede implementar a través del cliente o a través de la detección del cliente + servidor. En B/S, los navegadores ya están disponibles para cada computadora. Si no se establece una detección completa de permisos, es probable que un "usuario ilegal" acceda fácilmente a todas las funciones en el sistema B/S a través del navegador. Por lo tanto, los sistemas comerciales B/S deben tener uno o más sistemas de permiso para implementar la detección de permisos de acceso, para que los usuarios autorizados puedan usar funciones autorizadas normalmente y legalmente, y esos "usuarios ilegales no autorizados" las rechazarán completamente ". Echemos un vistazo a cómo diseñar un sistema de permiso que pueda cumplir con el control de los permisos de la función del usuario en la mayoría de los sistemas B/S.
Declaración de requisito
• El personal con diferentes responsabilidades debe tener diferentes permisos para las operaciones del sistema. Excelente sistema comercial, esta es la función más básica.
• Puede asignar permisos al grupo. Para un sistema comercial de una gran empresa, lleva mucho tiempo e inconveniente pedirles a los administradores que asignen permisos de operación del sistema a sus empleados uno por uno. Por lo tanto, el sistema propone el concepto de operar en "grupos", y organiza a las personas con permisos consistentes al mismo grupo, y luego asigna permisos al grupo.
• El sistema de gestión de permisos debe ser extensible. Debería poder unirse a cualquier sistema con capacidades de gestión de permisos. Al igual que los componentes, se pueden reutilizar constantemente, en lugar de reconstruir la parte de gestión de permisos para cada sistema de gestión desarrollado.
• Cumplir con permisos funcionales en el sistema comercial. En los sistemas comerciales tradicionales, hay dos tipos de gestión de permisos. Uno es la gestión de los permisos funcionales, y el otro es la gestión de los permisos de recursos. Entre los diferentes sistemas, los permisos funcionales se pueden reutilizar, mientras que los permisos de recursos no pueden.
Sobre el diseño
Con la ayuda del concepto de programación de acción de Noahweb, en la etapa de diseño, los diseñadores de sistemas no necesitan considerar el diseño de la estructura del programa, pero comienzan con el flujo del programa y la estructura de la base de datos. Para realizar los requisitos, el diseño de la base de datos es extremadamente importante. Ya sea el concepto de operación "grupal" o la reutilización de todo el conjunto de sistemas de gestión de permisos radica en el diseño de la base de datos.
Analicemos primero la estructura de la base de datos:
Primero, la tabla de acción ( en adelante, denominada "Tabla de permiso" ), la tabla Gorupmanager ( en adelante denominada "Tabla de grupo de gestión" ) y la tabla maestra ( en adelante, la "Tabla de personal" ) son tres tablas de entidades que registran la información de "Permisiones", la información del "grupo de gestión" y la información del "personal". Como se muestra en la figura a continuación:
La relación entre estas tres tablas es de muchos a muchos. Un permiso puede pertenecer a múltiples grupos de gestión al mismo tiempo, y un grupo de gestión también puede contener múltiples permisos al mismo tiempo. Del mismo modo, una persona puede pertenecer a múltiples grupos de gestión al mismo tiempo, y un grupo de gestión también puede incluir personal múltiple al mismo tiempo. Como se muestra en la figura a continuación:
Dado que hay una relación de muchos a muchos entre estas tres tablas, es mejor usar las otras dos tablas para completar la interacción. Estas dos tablas juegan un papel de mapeo, a saber, la tabla "ActionGroup" (en adelante, denominada "Tabla de mapeo de permisos") y la tabla "MasterGroup" (en adelante, denominada "Tabla de mapeo de personal") . El primero asigna la interacción entre la tabla de permisos y la tabla del grupo de gestión. Este último asigna la interacción entre la tabla de personal y la tabla del grupo de gestión. Como se muestra en la figura a continuación:
Además, también se necesita una tabla para controlar la columna de permiso en el menú izquierdo del tiempo de ejecución del sistema, es decir, la "tabla de la columna de permiso", como se muestra en la figura a continuación:
Según el análisis anterior, realizamos el diseño de la estructura de la base de datos, como se muestra en la figura a continuación:
Haga clic aquí para ver el diseño del campo de la tabla de datos del sistema de gestión de permisos
Para realizar un buen análisis, dividimos la tabla de estructura de la base de datos. El papel de las tres tablas de entidad ya es muy claro. Ahora echemos un vistazo al papel de las dos tablas de mapeo.
A continuación se muestra una tabla de mapeo de permiso :
Primero, echemos un vistazo a la asociación de campo entre la tabla de mapeo de permisos y la tabla del grupo de gestión y la tabla de permiso .
Mirando el círculo rojo en la imagen, primero mire la asociación del campo Gorupido. El rendimiento de este método de asociación en la base de datos real es el siguiente:
Como se muestra en la figura, el grupo de "Super Administrador" en la tabla de grupos de gestión es 1, por lo que el permiso con GroupId de 1 en la tabla de mapeo de permisos es ese es el permiso propiedad del "Super Administrador".
Use la asociación de campo GroupID para averiguar qué permisos puede ejecutar un grupo de gestión. Sin embargo, la información detallada de estos permisos se encuentra en la asociación de campo de acción.
El comportamiento del campo de acción en la base de datos es el siguiente:
Solo a través de esta asociación se puede encontrar la información detallada de esos permisos en la tabla de mapeo de permisos . En resumen, sabemos qué permisos puede ejecutar un grupo de gestión y qué detalles de estos permisos son.
Tal vez pregunte, ¿por qué no usar el campo ActionID para asociar? porque:
• El campo ID en la tabla de permisos puede cambiar después de múltiples operaciones de la base de datos.
• La tabla MAP de permisos solo registra los permisos que un grupo de gestión puede ejecutar.
• Una vez que cambia la ID en la tabla de permisos, los registros en la tabla MAP de permiso también cambian.
• Habrá un error en los permisos que un grupo administrativo puede ejecutar, lo cual es muy indeseable.
Teniendo en cuenta la situación anterior, el campo de acción debe estar asociado porque:
• En la tabla de permisos, la identificación puede cambiar, pero el campo de acción no puede cambiar bajo ninguna circunstancia.
• Los campos de acción registrados en la tabla MAP de permiso no cambiarán.
• No habrá errores en los permisos que un grupo administrativo puede ejecutar.
La tabla de mapeo de dos personas es la siguiente:
Aprendamos sobre la asociación de campo entre la tabla de mapeo de personal , la tabla del grupo de gestión y la tabla de personal , como se muestra en la figura a continuación:
Mirando la parte del círculo rojo en la imagen, primero mire la Asociación de Campo Groupid. Este método de asociación funciona en la base de datos como se muestra en la figura a continuación:
Como se muestra en la figura, el grupo de grupo del grupo "Super Administrador" es 1. Veamos la tabla de mapeo de personal . El administrador pertenece al Grupo Super Administrador, mientras que el Administrador pertenece al Grupo Super Administrador y también pertenece al Grupo Administrador.
Este método de asociación se utiliza para descubrir quién se encuentra en un grupo de gestión. Como se indicó anteriormente, la información detallada de una persona es consultada por asociación con el campo de identificación (el campo MasterID en la tabla de mapeo de personal ).
El campo ID (campo MasterID en la tabla de mapeo de personal ) está relacionado con la base de datos como se muestra en la figura a continuación:
Una persona puede pertenecer a múltiples "grupos de gestión" al mismo tiempo. Como se muestra en la figura, el administrador pertenece a dos "grupos de gestión" al mismo tiempo. Por lo tanto, habrá dos registros sobre administradores en la tabla de mapeo de personal .
Solo de esta manera podemos consultar la información detallada del personal en el grupo de gestión. Solo al combinarlo podemos saber quién está en un grupo de gestión y la información detallada de este personal.
Combinando la tabla de permiso y la tabla de mapeo de permiso mencionada anteriormente, se realiza la operación "grupo" en los requisitos, como se muestra en la figura a continuación:
De hecho, la tabla del grupo de gestión solo registra la información básica del grupo, como el nombre, la identificación del grupo, etc. En cuanto a los detalles de las personas en un grupo, así como los detalles de los permisos que el grupo puede ejecutar, se registran en la tabla de personal y la tabla de permisos . Solo las dos tablas de mapeo realmente registran cuáles son las personas en un grupo y qué permisos se pueden ejecutar. Solo a través de la conexión de dos tablas de mapeo se puede realizar la interacción entre las tres tablas de entidad, completando así la operación "Grupo" mencionada en los requisitos .
Echemos un vistazo a la interacción entre la tabla de la columna de permiso y la tabla de permiso . Los campos entre estas dos tablas son los siguientes:
Las dos tablas usan el campo ActionColumnid para estar asociados. El método de relación en la base de datos se muestra en la figura a continuación:
Como se muestra en la figura, a través de este método de asociación, podemos ver claramente a qué columna pertenecen los permisos en la tabla de permiso .
Ahora, la estructura de la base de datos es muy clara, y se ha implementado la función de asignar permisos y operaciones de "grupo". Analicemos los problemas de reutilización de los sistemas de gestión de permisos mencionados en los requisitos.
¿Por qué se puede reutilizar un sistema creado con este método de diseño de base de datos?
Se registran tres elementos decisivos en el sistema en las tres tablas de entidad. "Permisos", "grupos" y "personas". Estos tres elementos se pueden agregar a voluntad sin ser afectados entre sí. No importa qué tipo de sistema comercial sea, estos tres elementos decisivos no cambiarán, lo que significa que la estructura no cambiará, pero solo los datos cambiarán.
La relación entre los tres elementos se registra en las dos tablas de mapeo. Pero estas relaciones son completamente creadas por el hombre. Cuando se necesitan cambios, solo operan en los registros en la base de datos sin cambiar la estructura.
La tabla de la columna de permiso registra las columnas que se muestran cuando se usa el sistema . Ya sea que desee agregar columnas, modificar columnas o reducir las columnas, es solo un registro de operación.
En resumen, el sistema puede reutilizarse por completo diseñando una base de datos de esta manera y puede resistir la prueba de "cambio".
Resumir:
La clave de este sistema es que las tres tablas físicas comprenden firmemente los componentes centrales del sistema, y las dos tablas de mapeo asignan perfectamente la interacción entre las tres tablas físicas. La dificultad radica en comprender el trabajo de la tabla de mapeo, que registra la relación e implementa el concepto de operación de "grupo". El diseño general del sistema es cumplir con la configuración de permiso funcional de diferentes sistemas "reutilizando" en diferentes sistemas MIS.
apéndice:
Diseño de campo de la tabla de datos del sistema de gestión de permisos
Echemos un vistazo al diseño de la tabla de la base de datos del sistema de gestión de permisos, que se divide en seis tablas, como se muestra en la figura a continuación:
Tabla de acción:
La tabla de acción registra todas las acciones en el sistema y la descripción relacionada con la acción.
Tabla de ActionColumn:
La tabla ActionColumn registra la columna de acción. Cuando el sistema se está ejecutando, la barra de menú izquierda proporciona varias funciones diferentes. Cada bloque es una columna. Se agrega cada columna, se agregará un registro en la tabla. En consecuencia, se agregará una nueva columna a la barra de menú izquierda.
Tabla de ActionGroup:
La tabla ActionGroup registra el grupo donde se encuentra la acción.
Tabla GroupManager:
La tabla GroupManager registra información relevante sobre el grupo de gestión. Para cada grupo de gestión agregado, se agregará un registro aquí.
Tabla MasterGroup:
La tabla MasterGroup registra el grupo de gestión donde se encuentra el administrador. Dado que un administrador puede pertenecer a múltiples grupos al mismo tiempo, puede haber múltiples registros sobre un administrador en la tabla.
Table maestra:
La tabla maestra registra la información de todos los administradores. Para cada administrador agregado, la tabla agregará un registro.
El diseño de gestión de permisos generales anteriores (recomendado) en Java es todo el contenido que comparto con usted. Espero que pueda darle una referencia y espero que pueda apoyar más a Wulin.com.