Acceso exclusivo a usuarios

[mRoman]

Hola amigos que tal. Buenas noches.

Necesito orientación.

Se trata del acceso a la información exclusiva para ciertos usuarios PERTENECIENTES a una institucion en particular. Me explico:

Tengo una aplicación a la cual pretendo que se conecten varias instituciones (Unidades Operativas), las cuales pueden ser: Hospitales, Casas de asistencia, Asilos de ancianos, Orfanatos, Guarderías infantiles y para adultos mayores, etc...etc....

Cada una de estas instituciones, registrara en mi aplicación, un padrón de personas que recibirían el producto que mi empresa les vende, registrando obviamente la institución que realiza el pedido mas los nombres de cada persona, entre otros datos de cada uno de ellos como la direccion y la fecha de nacimiento......

PROBLEMA: ¿Como mostrarle a cada institución en mi aplicación SOLO la información que está haya registrado y que no pueda ver la información de las demás instituciones?

LO QUE ESTOY PENSANDO (Y no he hecho): Definir una tabla de usuarios a los cuales les registraré a que institución pertenecen, de tal manera que la PK de la tabla sería (por decir algo), USUARIO+CLAVE_ INSTITUCIÓN....y que cuando se conecten validar su clave de USUARIO y verificar si este usuario pertenece a la institución que él haya seleccionado en la pantalla de conexión......

...Ahora, que opinan de esta idea?....Existe alguna mejor? y para los que tengan algo parecido....como lo tienen....es decir, como lo lograron (código por fa)

Uso DELPHI 2010 y Firebird 1.5

No saben lo agradecido que estoy por su apoyo y orientación que le dediquen a mi consulta. Saludos muchachos.....

[cancun]

Hola


Yo no uso firebird ni he hecho un sistema como el que mencionas pero yo pondría un campo en la tabla de usuarios el ID de la institución y en el registro de personas el ID de la institución, a la hora de cualquier consulta solo debe coincidir ambos campos en ambas tablas.


Saludos

[[Delphius]]

Empezado por mRoman

Hola amigos que tal. Buenas noches.

Necesito orientación.

Se trata del acceso a la información exclusiva para ciertos usuarios PERTENECIENTES a una institucion en particular. Me explico:

Tengo una aplicación a la cual pretendo que se conecten varias instituciones (Unidades Operativas), las cuales pueden ser: Hospitales, Casas de asistencia, Asilos de ancianos, Orfanatos, Guarderías infantiles y para adultos mayores, etc...etc....

Cada una de estas instituciones, registrara en mi aplicación, un padrón de personas que recibirían el producto que mi empresa les vende, registrando obviamente la institución que realiza el pedido mas los nombres de cada persona, entre otros datos de cada uno de ellos como la direccion y la fecha de nacimiento......

PROBLEMA: ¿Como mostrarle a cada institución en mi aplicación SOLO la información que está haya registrado y que no pueda ver la información de las demás instituciones?

LO QUE ESTOY PENSANDO (Y no he hecho): Definir una tabla de usuarios a los cuales les registraré a que institución pertenecen, de tal manera que la PK de la tabla sería (por decir algo), USUARIO+CLAVE_ INSTITUCIÓN....y que cuando se conecten validar su clave de USUARIO y verificar si este usuario pertenece a la institución que él haya seleccionado en la pantalla de conexión......

...Ahora, que opinan de esta idea?....Existe alguna mejor? y para los que tengan algo parecido....como lo tienen....es decir, como lo lograron (código por fa)

Uso DELPHI 2010 y Firebird 1.5

No saben lo agradecido que estoy por su apoyo y orientación que le dediquen a mi consulta. Saludos muchachos.....

Pues yo no entiendo... ¿Y que tiene que ver el motor de base de datos, en este caso Firebird, con tu duda?
Asi como estás exponiendo tu caso das a entender que tu problema se trata más de diseño del sistema que algo propio a un problema duda en concreto con Firebird.
Concretamente, tu duda es como encarar el problema desde el lado de la interfaz, o en como diseñar la estructura de la base de datos (que dará lo mismo sea el motor que sea)? ¿O ambas cosas?

De lo que estoy seguro es que el que hayas elegido a Firebird como motor, es de sobra. En términos abstractos, y prácticos, en todo caso el diseño se lleva con un buen análisis y apoyándose en el uso de DER... que es algo independiente del motor. Que luego tu vuelques ese diseño y arquitectura en el motor en cuestión es por como has encarado el problema irrelevante.

Explícate bien.

Saludos,

[Casimiro Notevi]

Empezado por Delphius

Concretamente, tu duda es como encarar el problema desde el lado de la interfaz, o en como diseñar la estructura de la base de datos (que dará lo mismo sea el motor que sea)? ¿O ambas cosas?

Pues eso, una tabla de instituciones, otra de usuarios de las instituciones y ya está solucionado el problema.
Aunque no sabemos si va a estar todo centralizado o ¿cómo?

[mRoman]

Empezado por Casimiro Notevi

Pues eso, una tabla de instituciones, otra de usuarios de las instituciones y ya está solucionado el problema.
Aunque no sabemos si va a estar todo centralizado o ¿cómo?

Gracias casimiro por tu respuesta. Efectivamente la base de datos estará centralizada y todos los usuarios de cada una de las instituciones (2 0 3 usuarios y no mas) se conectaran a la base de datos, ejecutando de manera local el EXE de la aplicación.

[Casimiro Notevi]

Pues entonces te vale lo dicho antes, en la BD debes de tener una tabla de instituciones y otra de usuarios de las instituciones, básicamente algo así:

Código SQL [-]
tabla tbInstituciones (
  id integer not null,
  nombre varchar(64),
  ...
  primary key (id)
)

tabla tbUsuarios (
  id integer not null,
  id_institucion integer not null,  /* esta es la institución al que pertenece el usuario */
  nombre varchar(64),
  password varchar(64),
  ...
  primary key (id),
  foreign key (id_institucion) references tbInstituciones (id)  /* clave foránea a la tabla tbInstituciones */
)

[mRoman]

Empezado por Casimiro Notevi

Pues entonces te vale lo dicho antes, en la BD debes de tener una tabla de instituciones y otra de usuarios de las instituciones, básicamente algo así:

Código SQL [-]
tabla tbInstituciones (
  id integer not null,
  nombre varchar(64),
  ...
  primary key (id)
)

tabla tbUsuarios (
  id integer not null,
  id_institucion integer not null,  /* esta es la institución al que pertenece el usuario */
  nombre varchar(64),
  password varchar(64),
  ...
  primary key (id),
  foreign key (id_institucion) references tbInstituciones (id)  /* clave foránea a la tabla tbInstituciones */
)

Te agradezco casimiro por tu tiempo y respuesta.

Efectivamente coincido con lo que comentas, de hecho empezaré a realizar algunas pruebas con lo que comentas y les platico.....

Se siguen recibiendo ideas !

Gracias a todos.

[mRoman]

Empezado por Delphius

Pues yo no entiendo... ¿Y que tiene que ver el motor de base de datos, en este caso Firebird, con tu duda?
Asi como estás exponiendo tu caso das a entender que tu problema se trata más de diseño del sistema que algo propio a un problema duda en concreto con Firebird.
Concretamente, tu duda es como encarar el problema desde el lado de la interfaz, o en como diseñar la estructura de la base de datos (que dará lo mismo sea el motor que sea)? ¿O ambas cosas?

De lo que estoy seguro es que el que hayas elegido a Firebird como motor, es de sobra. En términos abstractos, y prácticos, en todo caso el diseño se lleva con un buen análisis y apoyándose en el uso de DER... que es algo independiente del motor. Que luego tu vuelques ese diseño y arquitectura en el motor en cuestión es por como has encarado el problema irrelevante.

Explícate bien.

Saludos,

Antes que nada gracias Delphius por contestar.

No se trata del diseño de la interfaz, si no, de como controlar el acceso a la información de la base de datos por cada uno de los usuarios. Es decir....que la información q registren los usuarios de un hospital no la pueda ver los usuarios de un Asilo de ancianos o los usuarios de un Orfanato. Esto lo tengo bien claro que lo debo de controlar a nivel base de datos (Firebird), mi duda es....como hacerlo?....que ideas proponen?

La que yo planteo al inicio del hilo, pudiera ser viable?...

No sé sí ahora haya quedado mas claro para ti Delphius

[[Caral]]

Hola
USUARIO (nombre) + CLAVE (dato) + INSTITUCIÓN (dato) + ACTIVO (si/no) + ACCESO (numérico)
Con esto se puede hacer.
Saludos

[mRoman]

Empezado por Caral

Hola
USUARIO (nombre) + CLAVE (dato) + INSTITUCIÓN (dato) + ACTIVO (si/no) + ACCESO (numérico)
Con esto se puede hacer.
Saludos

Te agradezco caral por tu respuesta.

Duda: "CLAVE" (dato)....es la clave del usuario? y "ACCESO (numérico)" que vendria siendo?

[[Caral]]

Hola
Clave es la clave del usuario
acceso es el nivel de acceso que tendra al programa, puede ser del 1 al 5 siendo 1 total. 2 a ciertos datos etc.
Asi lo uso yo, cada usuario puede accesar a solo parte del programa asi se controla quien y que parte usa.
Saludos

[mRoman]

Ok, te agradezco por tu comentario.

De hecho me pase revisando el foro y estuve leyendo acerca de los niveles de acceso que mencionas, solo que me parece que los accesos vendrían siendo otra cosa aparte de lo que plantea mi duda, sin embargo es interesante ya que en algún momento talvez recurra a los accesos.

Te comento q tengo pensado que todos los usuarios puedan consultar todo, pero no modificar o insertar registros de ciertas tablas, solo aquellas de SI deban (obvio). Talvez por ejemplo que no puedan modificar o insertar registros a los catálogos....por decir algo.

[[Caral]]

Hola
El problema que veo con el sistema que quieres implementar es que en todas las tablas tendras que poner tanto al usuario como la institucion.
Lo mas sencillo seria una BD por institucion y un programa que las vea o cargue la que se quiera ver independientemente.
Saludos

[PepeLolo]

Aplicando el criterio que te han dado, tablas (instituciones y usuarios), en el resto de tablas de tu sistema debes incluir un campo "id institución", no es necesario que sea PK, como FK es suficiente. Este campo es el que te discrimina la información entre instituciones. Si consideras que el usuario debe ser discriminador, pues lo mismo. Ahora los trucos:

A) los usuarios también los creas en la BBDD, con ello consigues a través de trigger incluir el usuario y la institución, por la relación entre las tablas (institución y usuarios), sin necesidad de modificar la aplicación.

B) en la aplicación, en las dataset principales, incluir la variable /* {id institución} */ tal y como he escrito. Esto será sustituido al vuelo en el evento Create por la condicion de la istitucion del usuario logeado.

C) usar siempre claves únicas, las demás siempre FK. Tus tablas hijas y sobre todo tu lo agradecerás.

[mRoman]

Empezado por PepeLolo

Aplicando el criterio que te han dado, tablas (instituciones y usuarios), en el resto de tablas de tu sistema debes incluir un campo "id institución", no es necesario que sea PK, como FK es suficiente. Este campo es el que te discrimina la información entre instituciones. Si consideras que el usuario debe ser discriminador, pues lo mismo. Ahora los trucos:

A) los usuarios también los creas en la BBDD, con ello consigues a través de trigger incluir el usuario y la institución, por la relación entre las tablas (institución y usuarios), sin necesidad de modificar la aplicación.

B) en la aplicación, en las dataset principales, incluir la variable /* {id institución} */ tal y como he escrito. Esto será sustituido al vuelo en el evento Create por la condicion de la istitucion del usuario logeado.

C) usar siempre claves únicas, las demás siempre FK. Tus tablas hijas y sobre todo tu lo agradecerás.

Gracias Pepe por tus comentarios....

[Gallosuarez]

mRoman:

A mi parecer, creo que tu problema lo puedes solucionar más fácilmente utilizando usuarios, roles y creando vistas actualizables con la opción "WITH CHECK OPTION". Te recomiendo, encarecidamente, que leas el siguiente libro: "La Cara Oculta de Delphi 4". Lo puedes encontrar en forma gratuita en formato PDF si haces una búsqueda a través de google (incluso creo que está en este mismo sitio). De hecho, a mi muy particular punto de vista, este libro debe de ser un referente obligado a cualquier programador de Delphi y que además utiliza Interbase o Firebird como su motor de base de datos.

Saludos,
Gerardo Suárez Trejo

P.D. "No eches en saco roto" esta pequeña recomendación (solo porque pienses que ahora estás utilizando Delphi 2010), créeme que la mayor cantidad de conceptos, tanto en Delphi como en Interbase 1.5 y Firebird siguen aun vigentes.

[Casimiro Notevi]

Lo mejor de lo mejor para delphi + bases de datos: la cara oculta de delphi
"No se puede" ser un experto sin antes haber leido ese libro.

[lbuelvas]

Mejor leer la La Cara OCulta de Delphi 6 generosamente ofrecido a la comunidad por Ian Marteens. La mayoría de los capítulos siguen siendo muy validos al dia de hoy.