Ver Mensaje Individual
  #1  
Antiguo 09-01-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Reputación: 25
Delphius Va camino a la fama
Question Diseño de una BD - Usuarios, Perfiles, Permisos

Buenas foristas, si bien mi dilema que detallo a continuación tiene que ver con el apartado de Base de Datos... no es hacia la conexión, sino más bien al diseño.

Veran, estoy desarrollando una aplicación compleja y grande. La misma está planteada para ser llevada a cabo en forma genérica. Pues, puede aplicarse en cualquier area o departamento, organización, gustos y necesidades. El problema surge al momento de elaborar el diseño relacional de las tablas que intervienen en el apartado de seguridad.

Hasta el momento la base de datos está en papel. Pues, recien tengo material suficiente como para empezar su armado.

Como he dicho anteriormente, debe ser diseñada la base de datos para que se amolde a cualquier ambiente organizacional. Para ser preciso tengo las siguientes tablas:

* Usuarios: que lleva un reguistro de usuarios, obviamente.
* Perfil: que mantiene los distintos perfiles que sean necesarios.
* Roles: Esta tabla es la intermedia entre los usuarios y roles. Como pueden adivinar, mantiene asociado los perfiles a los usuarios.
* Funcionalidad: es una tabla simple que cuenta con un ID y descripción. Mantiene en su interior las funcionalidades permitidas en el sistema.

¿Porque mantengo esta última tabla? Pues, para permitir administrar los permisos a cada usuario a las mismas. Por tanto, pondría una tabla intermedia entre perfil y Funcionalidad. Llamemosla por ahora Permisos.

¡Hasta allí bárbaro! Ahora se pone lindo. He dicho que el sistema debe sobrevirir en cualquier organización. ¿Ahora... que distingue a cada organización? Sus propias "Reglas de Negocio". Por tanto, es en este punto donde todo lo planteado para ser general se lleva hacia la especialidad.
¿Que tiene que ver con todo lo anterior?¿Con usuarios... y perfiles?

Pues, muy sencillo... las mismas reglas de negocio dictan sobre los permisos. La parte interviniente es la administración de dichos permisos. Por poner un ejemplo: Una organización impone como regla general que un usuario X pueda acceder a toda función excepto a la Y. Pero tanto este como otro usuario responden a un perfil P. Restringir esta funcion al perfil viola entonces el modelo relacional.
¿Se entiende?
A lo que voy es que a pesar de que existan perfiles, y funciones. Cada usuario que tenga dicho perfil puede o no estar asignado a dicha función. Por poner un ejemplo: Existen varios administradores, pero algunos con más o menos privilegios que otros. Claro... todo depende de las reglas de negocio.

Entonces... en base a esto, estaba pensando en incorporar otra tabla llamada Regla. Y... viendo las relaciones, me doy con que se conecta con Perfil y Funcionalidad... y ¡ya existe tal relación: Permisos! Se forma otro arco. Y visto desde el punto de normalización esto es algo inaceptable.

yo me estaba imaginando a la tabla Regla con campos ID que se asocien perfiles y funciones (clave foranea) y un campo condicion...

Puede o no existir permisos, pero siempre hay reglas que dictan los posibles permisos... y bueno... hasta allí llego:

DILEMA: ¿Como establezco la relacion? ¿Al final... las reglas van unidas a los permisos?... a los usuarios?... adonde...?

Por eso recurro a ustedes para escuchar opciones, recomendaciones (son vàlidas las de tipo "dejate de romper la cabeza")

Disculpen que mande semejante texto...

Saludos,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita