del proyecto de M&E
El modelo conceptual subyacente a la base de dato C- INCAMI, se basa en una aproximación relacional del marco de M&E C-INCAMI, ya presentado en la sub-sección 2.2.3 y el capítulo 4. Dado que el modelo de base de datos lógico, asociado con la base de datos C-INCAMI, ha sido desplegado sobre un contexto relacional y partiendo de que el marco C-INCAMI se sustenta en el paradigma orientado a objetos, es lógico que nuestra aproximación haya requerido algún ajuste en términos de implementación, que permitan compatibilizar ambos paradigmas, en post de mantener intactas las cuestiones conceptuales del marco.
A.1 Modelo conceptual asociado a la definición del proyecto de M&E A.2 Modelo conceptual asociado a la
definición de la métrica
A.3 Modelo Conceptual asociado a la definición de indicadores y mecanismos de alarmas
Figura 81. Vista Relacional del sub-esquema de la base de datos C-INCAMI asociado con la definición del proyecto de M&E
La Figura 81 muestra el sub-esquema de la base de datos C-INCAMI asociado con la definición del proyecto de M&E. Como un aspecto particular, note que en la mencionada figura se encuentra una tabla denominada parametrosdsips. Ésta última, en realidad contiene una serie de parámetros que rigen el comportamiento del prototipo en términos operativos, pero que no contiene relación directa con los conceptos del marco, por ello ha sido expuesta como sin relación con respecto a los restantes conceptos. Un ejemplo de esto último es el parámetro STATISTICAL_ALARM (presentado entre otros, en la sub-sección 7.11) cuya finalidad es indicar al DecisionMaker si dará curso o no a las alarmas surgidas desde el análisis estadístico.
El sub-esquema contiene la tabla Project la cual almacena la definición de los proyectos de M&E, se vincula con InformationNeed a los efectos de establecer qué necesidad de información satisface. La relación entre project y directors determina el rol del coordinador global del proyecto de M&E, mientras que la relación entre requirementproject y directors señala la presencia de un sub-director particular para un requerimiento dentro del proyecto.
El proyecto estará vinculado a varios conceptos calculables (projectxcalculableconcept). Cada concepto calculable (calculableconcept) puede asociarse con un modelo conceptual (conceptmodel). Adicionalmente, puede tener vinculado varios atributos (attribute) o bien, varias propiedades de contexto (contextproperty). Cada requerimiento del proyecto puede asociarse con muchos atributos de un concepto calculable (requirementprojectxattribute).
Una necesidad de información (informationneed), puede tener asociada varias definiciones de contexto (context) como así también, puede asociarse con varias categorías de entidad (entitycategory). A una categoría de entidad, puede definírsele un contexto en particular y dicho contexto, es caracterizado por sus propiedades de contexto (contextProperty). A su vez, cada categoría de entidad es caracterizada por una serie de atributos (entcatxattribute), y dentro de una categoría de entidad, pueden existir varias entidades a monitorear (centity)
Cada uno de estos conceptos, deben estar previamente definidos, para poder proceder a la especificación de las métricas e indicadores asociados. Esto último es lógico, por cuanto y por ejemplo, para poder asociar una métrica a un atributo determinado, debiera tenerse noción del concepto calculable y/o el requerimiento del proyecto de M&E específico al cual se vinculará.
A.2
Modelo conceptual asociado a la definición de la métrica
La Figura 82 muestra el sub-esquema de la base de datos C-INCAMI asociado con la definición de la métrica. Todas las métricas son definidas en la entidad metric, allí puede apreciarse la relación con el atributo (attribute) o propiedad de contexto (contextproperty) que implementa. Adicionalmente, puede observarse la definición del error máximo permitido para la métrica, como así también los valores de referencia para la misma (atributos mínimo, máximo y normal). Toda métrica tiene asociada una escala numérica (numericalscale), la cual a su vez se vincula con la tabla scale.
Cada métrica puede tener asociadas varias mediciones (measurement). Estas mediciones pueden o no ser deterministas, por lo que una medición puede tener asociada varias medidas con su correspondiente probabilidad (measure). Un conjunto de mediciones puede asociarse con trainingdataset, cuyo objetivo es definir un grupo representativo de mediciones para una métrica. Si bien y a priori, ello parecería contradictorio con el planteo de procesamiento de flujos de datos on-line, no lo es en absoluto, por cuanto dicho grupo representativo de mediciones, constituye el dataset para entrenar a los clasificadores on-line en el momento 0 (cero). Es por ello, que se mencionaba dentro de la tesis, que el grupo de mediciones para entrenar un clasificador (ver sub- sección 8.5), podría ser provisto por especialistas del área bajo medición. Así, tales observaciones estarían almacenadas en las entidades measurement, measure y trainingdataset para ser
utilizadas automáticamente al momento en que el clasificador sea inicializado para un proyecto de medición dado.
Figura 82. Vista Relacional del sub-esquema de la base de datos C-INCAMI asociado con la definición de la métrica
La tabla datasource almacena las fuentes de datos que han implementado la interface Datasource (ver sub-sección 5.1), y han llevado adelante el proceso de configuración descrito en el capítulo 5. De este modo, se identifica a cada una de las fuentes de datos que interactúa con el prototipo, permitiendo entre otras cuestiones un resguardo o copia de seguridad de la configuración de la misma con respecto a uno o más proyectos de medición. Es decir, que si la fuente de datos por algún motivo sufriera una desconfiguración, mediante los servicios web presentados en el capítulo 5, podría recuperar la información de configuración para evitar llevar adelante todo el proceso nuevamente.
Recapitulando el proceso de configuración de la fuente de datos explicado en la sub- sección 5.5, la fuente de datos debía indicar con qué métrica se asociaría junto con la entidad bajo estudio a la que mediría. Esto último, es lo que almacena la entidad datasourcexmetrics, es decir que su función es mantener la relación para cada una de las métricas con las que se asocia una
fuente de datos, la entidad que mide específicamente dicha métrica (para esa fuente de datos) y si el atributo en cuestión, es o no una propiedad contextual. En éste último sentido, cabe aclarar que tanto attribute como contextproperty poseen idéntica clave primaria, con lo que desde el punto de vista relacional podrían haber sido fusionados bajo una misma entidad, no obstante ello, se ha primado su separación en post de mantener claramente diferenciado los conceptos vinculados a cada uno de ellos.
A.3
Modelo Conceptual asociado a la definición de indicadores y
mecanismos de alarma
La Figura 83 muestra el sub-esquema de la base de datos C-INCAMI asociado con la definición de indicadores y mecanismos de alarma.
Figura 83. Vista Relacional del sub-esquema de la base de datos C-INCAMI asociado con la definición de indicadores y mecanismos de alarma
Al igual que las tablas analizadas en la sub-sección A.2, permiten definir un patrón de referencia para el análisis on-line de una medida y por ende, son de vital importancia en el análisis estadístico (ver capítulo 7), los conceptos aquí vertidos, representan un marco de referencia obligado para el proceso de toma de decisiones, ya que aquí, entre otras cuestiones, los expertos vierten en términos de indicadores, su conocimiento y experticia sobre el dominio del proyecto de M&E.
Como puede apreciarse en la Figura 83, una definición de métrica puede aprovisionar o nutrir a más de un indicador elemental (elementaryindicator). Cada indicador elemental tiene asociado diferentes rangos (elementaryindicatorrangecriteria), en donde cada uno establece sus umbrales, si corresponde o no emitir una alarma y el mensaje asociado a la misma. Dicha definición es de particular importancia para el proceso de toma de decisión planteado en el capítulo 8, por cuanto define un patrón de referencia para el DecisionMaker.
La base de datos mantiene relación entre cada fuente de datos y el grupo de seguimiento al que pertenecen (tracegroup_composicion) o bien del cual son propietarias (tracegroup). Cada grupo de seguimiento, en función de las etiquetas de clases definidas para el clasificador (rangos de interpretación nominales u ordinales de los indicadores), puede particularizar el tipo de acción a tomar (tracegroup_classaction) en la medida que satisfaga una probabilidad de ocurrencia mínima requerida. Esto permite potenciar los aspectos de particularización del clasificador al grupo de seguimiento, tal y como fue analizado en las sub-secciones 8.4 a 8.7.
Un aspecto de fundamental importancia en este sub-esquema de base de datos, es que permite configurar por cada grupo de seguimiento los tipos de alarmas que se prefieren no emitir, porque posiblemente las relaciones o situaciones que la provocan son conocidas a priori, y constituirían una sobrecarga innecesaria de procesamiento. En este sentido, es posible bloquear las alarmas por detección de normalidad en una métrica particular para un grupo de seguimiento (blockedalarmtgnormality), bloquear las alarmas surgidas del análisis descriptivo de una determinada métrica en un grupo de seguimiento (blockedalarmtgdescriptiveresume) y bloquear alarmas por detección de correlación entre dos métricas de un grupo de seguimiento (blockedalarmtgcorrelation).
Como forma básica de prueba de las alarmas emitidas, el modelo de datos contiene la posibilidad de desviar las alarmas hacia a un registro persistente (alarmevent). Ello es útil al momento de probar la configuración inicial del proyecto y verificar el régimen de alarmas emitidas, teniendo en cuenta que cuando el mismo esté en producción, las mismas serán emitidas a los responsables definidos en el proyecto. Por ejemplo, para el escenario planteado en el capítulo 9, serían los doctores del centro de salud.