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 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

[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.

[[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

[Casimiro Notevi]

Empezado por mRoman

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

No, no... ¡¡¡error!!!, así no se diseña un sistema, supongo que lo habrás estudiado.

1. Primero tienes que saber exactamente qué se quiere hacer y controlar. Cosa que veo que no tienes claro.
2. Luego tienes que pensar en cómo hacerlo. Cosa que veo que lo tienes menos claro que lo anterior.
3. Después tienes que escribir (papel y lápiz) cómo será todo lo anterior (pasarlo de la cabeza al papel). Imposible hacerlo si no has pasado por los pasos anteriores.
4. Finalmente, con lo anterior ya hecho, y todo totalmente claro, es cuando hay que implementarlo en código.

Saltarse uno de los pasos no es viable.

Tu forma de hacerlo, tal y como has dicho antes es: ¡¡¡empezar a poner ladrillos sin saber ni dónde, ni por qué, ni cómo!!!, primero necesitas los planos hechos por el arquitecto, y en este caso tú eres el arquitecto, salvo que tengas un analista en tu empresa, después son los albañiles/programadores (con el seguimiento del arquitecto) los que ponen los ladrillos y echan el cemento, ¡¡¡pero siguiendo los planos que hizo el arquitecto/analista!!!

[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

[mRoman]

Empezado por Casimiro Notevi

No, no... ¡¡¡error!!!, así no se diseña un sistema, supongo que lo habrás estudiado.

1. Primero tienes que saber exactamente qué se quiere hacer y controlar. Cosa que veo que no tienes claro.
2. Luego tienes que pensar en cómo hacerlo. Cosa que veo que lo tienes menos claro que lo anterior.
3. Después tienes que escribir (papel y lápiz) cómo será todo lo anterior (pasarlo de la cabeza al papel). Imposible hacerlo si no has pasado por los pasos anteriores.
4. Finalmente, con lo anterior ya hecho, y todo totalmente claro, es cuando hay que implementarlo en código.

Saltarse uno de los pasos no es viable.

Tu forma de hacerlo, tal y como has dicho antes es: ¡¡¡empezar a poner ladrillos sin saber ni dónde, ni por qué, ni cómo!!!, primero necesitas los planos hechos por el arquitecto, y en este caso tú eres el arquitecto, salvo que tengas un analista en tu empresa, después son los albañiles/programadores (con el seguimiento del arquitecto) los que ponen los ladrillos y echan el cemento, ¡¡¡pero siguiendo los planos que hizo el arquitecto/analista!!!

Agradezco tu comentario Casimiro. Cuando comento que pondré en práctica lo que me dices....me estaba refiriendo a "pensar" para luego pasar al "papel" y de ahi todo los demas....asi como dices en tu pasos enumarados.

En estos momentos estoy en la etapa del análisis....."imaginandome" como debo hacerle para que los usuarios solo vean su información....todavia no estoy con las tablas....de hecho tengo poco con el inicio de este aplicación si acaso 15 o 20 dias....

[Casimiro Notevi]

..........

[[Delphius]]

Empezado por mRoman

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.

Si en tu diseño de la base de datos haz hecho una formal y explícita relación entre las instituciones y los productos que éstas tienen entonces todo se resume a hacer una consulta filtrada (es decir con WHERE algo) para obtener exactamente los productos que pertenecen a una institución.

Ahora por otro lado, tienes una falla conceptual que posiblemente será de problemas más adelante: tu error en confundir y mezclar usuarios e instituciones. Una cosa son los usuarios (mejor dicho, personal) de cada institución... y otra distinta es que cada institución sea y actúe como "usuario" de tu aplicación.
Si te lees bien te enterarás de que haz mezclado ambas cosas. Cuando un "usuario" accede a su cuenta, no debiera determinar a que institución pertenece... Se supone que existe una relación formada entre las hipotéticas tablas usuarios e instituciones (relación muchos a uno, para ser precisos). De modo con el simple hecho de haber accedido debiera ser posible determinar a que institución representa. Cosa que se puede hacer y saber simplemente leyendo la clave foránea que apunta a la tabla instuciones. Ya con este valor una consulta del tipo select * from instituciones where ID = ClaveForaneaLeida basta para saber los datos de la misma.

Como representante de su institución, ahora debe ser capaz de trabajar como si fuera una institución por tanto todo movimiento y operatoria que haga este usuario en realidad se debe hacer como si la institución hiciera estas operaciones. Por tanto aquellas tablas o entidades sensibles a tener relación o interés de registrar alguna información relevante sobre la institución deberá contar con un campo que formalice esta relación. Léase: clave foránea hacia ésta.

Si no entiendes esto, me temo que estás muy en pañales y tienes una gran deficiencia y falta de conocimientos como para levar a cabo a buen puerto el sistema. Eso o simplemente te piensas que un sistema se hace por arte de magia y sin un debido análisis... tal como lo ha dejado en claro Casimiro.
"Pierde el tiempo" en estudiar las cosas, analiza la situación.

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 Delphius

Si en tu diseño de la base de datos haz hecho una formal y explícita relación entre las instituciones y los productos que éstas tienen entonces todo se resume a hacer una consulta filtrada (es decir con WHERE algo) para obtener exactamente los productos que pertenecen a una institución.

Ahora por otro lado, tienes una falla conceptual que posiblemente será de problemas más adelante: tu error en confundir y mezclar usuarios e instituciones. Una cosa son los usuarios (mejor dicho, personal) de cada institución... y otra distinta es que cada institución sea y actúe como "usuario" de tu aplicación.
Si te lees bien te enterarás de que haz mezclado ambas cosas. Cuando un "usuario" accede a su cuenta, no debiera determinar a que institución pertenece... Se supone que existe una relación formada entre las hipotéticas tablas usuarios e instituciones (relación muchos a uno, para ser precisos). De modo con el simple hecho de haber accedido debiera ser posible determinar a que institución representa. Cosa que se puede hacer y saber simplemente leyendo la clave foránea que apunta a la tabla instuciones. Ya con este valor una consulta del tipo select * from instituciones where ID = ClaveForaneaLeida basta para saber los datos de la misma.

Como representante de su institución, ahora debe ser capaz de trabajar como si fuera una institución por tanto todo movimiento y operatoria que haga este usuario en realidad se debe hacer como si la institución hiciera estas operaciones. Por tanto aquellas tablas o entidades sensibles a tener relación o interés de registrar alguna información relevante sobre la institución deberá contar con un campo que formalice esta relación. Léase: clave foránea hacia ésta.

Si no entiendes esto, me temo que estás muy en pañales y tienes una gran deficiencia y falta de conocimientos como para levar a cabo a buen puerto el sistema. Eso o simplemente te piensas que un sistema se hace por arte de magia y sin un debido análisis... tal como lo ha dejado en claro Casimiro.
"Pierde el tiempo" en estudiar las cosas, analiza la situación.

Saludos,

Gracias Delphius por tus comentarios....en realidad creo que varios de nosotros que posteamos en este foro, en algún momento experimentamos o sentimos q estamos en "pañales"....claro dependiendo del nivel del sistema que querramos desarrollar y que dependiendo de ello escasamente posteamos....y sí es el caso (de no postear para preguntar) nos convertimos entonces en personas con mayor conocimiento que orientamos a personas como yo....sinceramente te agradezco.

En cuanto a lo que me comentas, estoy iniciando con el análisis y estoy viendo que opciones existen de algo que (claro esta) no se del todo. En cuanto a la confusión que dice q tengo, pues te diré que yo lo conceptualizo asi....a cada institución la tomaré como un usuario los cuales podrán ser 1 o 2 0 3.....esto sí se quiere controlar qué usuario realiza movimientos (el cual no le interesa a mi empresa saber) por lo tanto, la institución podrá decirle a la persona encargada de alimentar al sistema, cual es el usuario y el obviamente el pass para accesar al sistema, como podrá ser cualquier otra persona a quien se lo diga...es decir no importa si JUAN, PEDRO o CHEPE entra al sistema con la misma clave de usuario.

También sé que los sistemas no se hacen por "arte de magia" (aunque a veces Delphi me hace dudar sobre esto)...es largo el camino para llegar al final, que es la implementación del sistema.

Gracias por tu tiempo y tus comentarios.....creeme q no los "hechare en saco roto" (como se dice en México).

Saludos

[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....