6 respuestas en este tema

[Delphius]

Generalmente el diseño de los DERs a mi no me cuestan y los suelo sacar de un tiro. Pero en esta lo ando pensando en como encararlo.

Les explico mi caso.

Tengo una relación "muchos a muchos" que como todos saben requiere de una tabla intermedia:

 

A -1---m- B -m---1- C

 

siendo -1---m- la relación "uno a muchos".

 

Esta relación (m,m) consiste en llevar información del tipo histórica. La tabla A contiene la descripción de expedientes, C registra las áreas por las que se mueven los expedientes, y B por tanto contiene el registro de cada movimiento de todos los expedientes por distintas áreas. La tabla B contiene justamente esto:

 

ID: PK

AID: FK (TablaA.ID)

CID: FK (TablaC.ID)

Fecha: TimeStamp

Observación: varchar

 

 

Resulta ser que mi programa tiene diseñado una especie de mini-motor de reglas de validación o de chequeo que va a anlizar los registros que dan forma a esta relación. La cuestión es que hay dos tipos de reglas: generales y específicas.

Las generales aplican a todos, es decir que analizará todo el histórico de todos los expedientes. Cuando se detecta que se cumple dicha regla se asienta esto en una lista que luego se notificará al usuario de los cambios.

 

Más el problema está en las específicas, y la intención es que el usuario pueda personalizar algunas reglas para que se le notifique de ésto. Es decir:

* el expediente X ha pasado al área Y. O bien,

* el expediente X no se ha movido del área Y en Z días.

 

Entonces no sólo se trata de reglas generales y específicas sino que además éstas son de 2 naturalezas:

* Reglas de pase al momento: el caso 1.

* Reglas de pase peresozo: el caso 2.

 

Es decir que se esperan tener reglas específicas y puntuales tanto "In the moment"  (casos 1) como las "Lazzy" (casos 2).

 

Se me chamuscaron los cables al momento de dar forma en la base de datos en cómo registrar esto. ¿Alguna idea o sugerencia? ¿Cómo podría traducir en tablas de modo que pueda diferenciar específicas de las generales, y a su vez las de momento como las peresozas?

 

Saludos,

[Rolphy Reyes]

Saludos.

 

De momento no se me ocurre nada concreto, pero para la regla 2 pudieras tener un campo llamado DIAS_NOTIFICACION que te servirá para guiarte o calcular cuantos días tiene el expediente estancado en el área.

 

Para la regla 1 tal vez almacenar el ID del área por donde se requiere notificación a su llegada o no dependiendo de los movimientos del expediente.

 

Pudieras poner esto en tablas separadas para verlas y luego unirlas si requiere.

[Delphius]

Saludos.

 

De momento no se me ocurre nada concreto, pero para la regla 2 pudieras tener un campo llamado DIAS_NOTIFICACION que te servirá para guiarte o calcular cuantos días tiene el expediente estancado en el área.

 

Para la regla 1 tal vez almacenar el ID del área por donde se requiere notificación a su llegada o no dependiendo de los movimientos del expediente.

 

Pudieras poner esto en tablas separadas para verlas y luego unirlas si requiere.

 

De que necesito tener esa información de alguna forma seguro. El asunto es que quisiera evitar formar un ciclo. Inicialmente el esquema es así:

 

A -1---m- B -m---1- C

 

Pero si quisiera incorporar ahora el esquema de reglas específicas que también vinculan a A y a C. llego a esto:

 

A -1---m- D -m---1- C

 

Siendo esta D la tabla que registra las reglas. Podría tener un diseño algo como:

 

ReglasEspecificas

IDRegla: PK

ExpedienteID: FK(Expediente.ID)

AreaID: FK(Area.ID)

DiasEspera: INTEGER

TipoRegla: CHAR(1) // o INTEGER, o el que sea

 

El tema es que en lo posible hay que evitar estos ciclos.

 

Esta mañana estuve pensando mientras hacía otro trabajo que quizá pueda ser llevado como una tabla independiente y no necesariamente forzar a usar el esquema relacional con las claves foráneas. De este modo mi cabeza me decía que podría incluso disponer de una única tabla que registre todas las reglas:

 

ReglasNotificacion:

IDRegla: PK

Nombre: VARCHAR

RefExpte: INTEGER // ID del expediente asociado, cuando es regla específica. Para regla general es -1

RefArea: INTEGER // ID del área

DiaEspera: INTEGER // si es distinto de 0 se aume que es del tipo regla ociosa.

 

Entonces lo que yo pienso es directamente cargar el listado de reglas, y al momento de proceder a verificar los movimientos evaluar si es una regla específica fijándome en el RefExpte. En caso afirmativo me fijo si dicho movimiento corresponde al mismo espediente (deberían coincidir RefExpte y Movimientos.ExpteID), de ser así recién tendría lugar comprobar el área y/o los días de espera.

Cuando se trata de regla general, como aplica a todos los movimientos de todas formas debe leerse el campo del área.

 

No estoy del todo decidido... Este esquema requiere de un poco de más trabajo, pero al menos me evitar ese ciclo.

A ver que opinan ustedes.

 

Saludos,

[cram]

Delphius no leí toda la segunda respuesta. Pero lo que se me ocurre es que precisamente en la tabla de relación (la intermedia) es en la que podrías colocar la información faltante. Es decir que cada vez que se cree o modifique la relación se modifique ese valor.

Espero haber entendido bien.

 

Ahora, si esa relación no existe al momento de utilizar la regla, es que -obviamente- no te entendí bien.

 

Saludos

[Delphius]

Delphius no leí toda la segunda respuesta. Pero lo que se me ocurre es que precisamente en la tabla de relación (la intermedia) es en la que podrías colocar la información faltante. Es decir que cada vez que se cree o modifique la relación se modifique ese valor.

Espero haber entendido bien.

 

Ahora, si esa relación no existe al momento de utilizar la regla, es que -obviamente- no te entendí bien.

 

Saludos

 

Justamente ese es el punto: pueden existir las reglas pero puede que no necesariamente los movimientos. No necesariamente debe haber un vínculo entre ellos dado por una relación. La intención justamente es que periodicamente se vaya consultando este histórico de movimientos (que se va llenando diariamente, según las consultas a servicios externos de mi aplicación) y verificar si hay alguna "coincidencia" con alguna regla para dar aviso de tal hecho.

 

Saludos,

[Rolphy Reyes]

De que necesito tener esa información de alguna forma seguro. El asunto es que quisiera evitar formar un ciclo. Inicialmente el esquema es así:

 

A -1---m- B -m---1- C

 

Pero si quisiera incorporar ahora el esquema de reglas específicas que también vinculan a A y a C. llego a esto:

 

A -1---m- D -m---1- C

 

Siendo esta D la tabla que registra las reglas. Podría tener un diseño algo como:

 

ReglasEspecificas

IDRegla: PK

ExpedienteID: FK(Expediente.ID)

AreaID: FK(Area.ID)

DiasEspera: INTEGER

TipoRegla: CHAR(1) // o INTEGER, o el que sea

 

El tema es que en lo posible hay que evitar estos ciclos.

 

Esta mañana estuve pensando mientras hacía otro trabajo que quizá pueda ser llevado como una tabla independiente y no necesariamente forzar a usar el esquema relacional con las claves foráneas. De este modo mi cabeza me decía que podría incluso disponer de una única tabla que registre todas las reglas:

 

ReglasNotificacion:

IDRegla: PK

Nombre: VARCHAR

RefExpte: INTEGER // ID del expediente asociado, cuando es regla específica. Para regla general es -1

RefArea: INTEGER // ID del área

DiaEspera: INTEGER // si es distinto de 0 se aume que es del tipo regla ociosa.

 

Entonces lo que yo pienso es directamente cargar el listado de reglas, y al momento de proceder a verificar los movimientos evaluar si es una regla específica fijándome en el RefExpte. En caso afirmativo me fijo si dicho movimiento corresponde al mismo espediente (deberían coincidir RefExpte y Movimientos.ExpteID), de ser así recién tendría lugar comprobar el área y/o los días de espera.

Cuando se trata de regla general, como aplica a todos los movimientos de todas formas debe leerse el campo del área.

 

No estoy del todo decidido... Este esquema requiere de un poco de más trabajo, pero al menos me evitar ese ciclo.

A ver que opinan ustedes.

 

Saludos,

 

Hola.

 

Delphius en mi comentario anterior no especifique que fuera en la tabla intermedia, sino en tablas separadas por cada regla y que tal vez pudieras unir (fundir) ambas tablas en una.

 

Precisamente para no tener que definir una y otra vez las mismas reglas por cada relación que se haga.

[Delphius]

Hola.

 

Delphius en mi comentario anterior no especifique que fuera en la tabla intermedia, sino en tablas separadas por cada regla y que tal vez pudieras unir (fundir) ambas tablas en una.

 

Precisamente para no tener que definir una y otra vez las mismas reglas por cada relación que se haga.

 

A ver si ahora te entiendo... ¿tu sugieres que tenga una tabla ReglasDeMomento y una tabla ReglasDeOcioso y que cada una de estas tenga el campo que necesite?

Algo como:

 

Tabla: ReglasDeMomento

IDReglaM: PK

AreaID: FK(Area.ID)

 

TablaDeOcioso

IDReglaO: PK

AreaID: FK(Area.ID)

Dias: INTEGER

 

Esto sería para el caso general. Para las específicas se necesitaría de una referencia hacia el expediente. Y hasta donde percibo o bien se añade ese campo extra, o bien se añade una tabla más llamada AsignacionReglas que vincule la regla con el expediente. De todas formas se llega al mismo ciclo: desde A hacia C hay dos "caminos" posibles de llegada, que es lo que quisiera poder evitar.

 

O es que todavía no le capto a tu propuesta.

 

Por lo pronto, el sistema va por defecto con una única regla: general "al momento" con un área específica también por defecto. Luego el usuario ya es libre de añadir las que guste. De todas formas sólo existen 4 combinaciones posibles de reglas:

General "al momento" : aplica a todos los expedientes. Se notifican todos los movimientos de expedientes cuya área sea la definida.

General "ociosa": aplica a todos los expedientes. Se notifican los movimientos de expedientes que no se hayan movido en tantos días de la área definida.

Específica "al momento". Lo mismo a su versión general, sólo que puntualmente se evalúa para el expediente definido.

Especifica "ociosa". Versión análoga a la general, pero que aplica a expedientes puntuales definidos.

 

El proceso de verificación prioriza lo específico sobre lo general. Si el movimiento en cuestión cumple con alguna de las reglas se da por notificado.

 

Por lo que no veo no necesito darle más vuelta a tratar de preveer más tipos de reglas (al menos que algún cliente me rompa el molde). Lo que necesito en definitiva es lograr llevar estas combinaciones de reglas de forma persistente en la base de datos.

 

Saludos,