Source: http://docplayer.es/885396-Diseno-multidimensional-guiado-por-ontologia.html
Timestamp: 2018-02-21 06:15:37+00:00

Document:
Diseño Multidimensional guiado por Ontología - PDF
Download "Diseño Multidimensional guiado por Ontología"
José Luis Alvarado Castillo
1 Diseño Multidimensional guiado por Ontología Sebastián Giménez, Regina Motz, Fernando Carpani, Diego Gayoso, Cecilia Colombatto Instituto de Computación, Universidad de la República, Julio Herrera y Reissig 565, Montevideo, Uruguay {carpani, rmotz Resumen. Este trabajo presenta guías de diseño conceptual multidimensional para data warehouses basadas en el análisis de requerimientos y en la ontología del dominio. Se ejemplifica con un caso de estudio real y se compara la propuesta con otras existentes. Keywords: Modelo Conceptual Multidimensional, Data Warehouse, Ontología. 1 Introducción El diseño multidimensional es ampliamente utilizado como representación conceptual de un Data Warehouse. Un Data Warehouse (DW) es una base de datos que almacena información para la toma de decisiones, que no es un sistema transaccional sino fuertemente caracterizado por ser un sistema OLAP, acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). El modelo multidimensional, o la metáfora del cubo, sirven para organizar los datos en torno a un eje de datos a ser analizados (hechos), un eje de las descripciones más importantes de esos datos (medidas) y otro eje que describe las dimensiones en que los datos pueden ser analizados. Si bien no existe un consenso de estándar en el modelo multidimensional a usar, sí existe acuerdo en la importancia de distinguir entre un diseño conceptual, un diseño lógico y un diseño físico [1, 2, 3]. El diseño conceptual apunta a la construcción de un esquema conceptual en concordancia con el modelo conceptual elegido que sea independiente de la implementación y que sea expresivo en la representación de los requerimientos del usuario. El diseño lógico toma el esquema conceptual y crea el correspondiente esquema lógico en la plataforma elegida considerando restricciones operacionales. El diseño físico se enfoca en el desarrollo específico referente a una implementación. Como señalado en [4], existen varias propuestas de metodologías para diseños en estos tres niveles, pero no existen aún metodologías sencillas, prácticas, para que desde el punto de vista industrial sirvan para mejorar el diseño conceptual de un DW. En este trabajo presentamos una propuesta para realizar el diseño conceptual multidimensional con el desafío de obtener un diseño fácil de reutilizar, de extender y de administrar. Nuestra propuesta es trabajar desde una fase de captura de requerimientos del usuario con correspondencias tanto desde una ontología de
2 dominio como desde el modelo conceptual utilizado. Mostramos como estas correspondencias permiten el diseño conceptual del DW de manera ordenada y documentada y permiten además desarrollar una clara trazabilidad de los conceptos presentes en la realidad hasta su representación en el modelo multidimensional, favoreciendo de esta forma, la administración de los cambios en los requerimientos. Generalmente ocurre que una vez que se implanta un DW, los requerimientos que originaron al mismo van cambiando, además de adicionarse nuevos. Por esto es importante que el Data Warehouse sea flexible a nuevos cambios, y que su mantenimiento sea lo menos costoso posible. Una ontología se puede definir como la especificación explícita de una conceptualización [5]. Cuando el conocimiento de un dominio es representado en un formalismo declarativo, el conjunto de objetos que pueden ser representados es llamado el universo de discurso. Este conjunto de objetos, y las relaciones descriptibles entre ellos, es reflejado en el vocabulario con el cual se representa conocimiento. En una ontología se asocian mediante definiciones los nombres de las entidades en el universo de discurso (por ejemplo clases, relaciones, funciones u otros objetos) con cierto texto expresado en lenguaje natural que las describe y con axiomas que restringen la interpretación y otorgan la característica de bien formados a dichos términos. Uno de los principales objetivos que tiene la utilización de ontologías es la de realizar inferencias sobre los conceptos. Mediante el uso de herramientas tales como razonadores es posible detectar inconsistencias, con el beneficio de obtener puntos de retrocesos menores y por lo tanto con menor costo asociado al mantenimiento del diseño guiado por ontología. El resto del artículo está organizado de la siguiente forma. La Sección 2 presenta las características particulares del modelo multidimensional utilizado, CMDM. La Sección 3 presenta las fases de nuestro enfoque mientras que la Sección 4 presenta la derivación del modelo conceptual desde la ontología de dominio. Para una mejor comprensión, la Sección 5 presenta una aplicación práctica de nuestra propuesta, experimentada en un ambiente real de diseño de DW. Finalmente la Sección 6 presenta algunas conclusiones y líneas de trabajo futuro. 2 El Modelo Multidimensional CMDM El objetivo fundamental de CMDM [6, 7] es permitir la especificación de una determinada realidad en términos multidimensionales. En una base de datos multidimensional, la información se representa como matrices multidimensionales, cuadros de múltiples entradas o funciones de varias variables sobre conjuntos finitos. Cada una de estas matrices se denomina Cubo. El esquema de un cubo queda determinado dando a conocer sus ejes con sus respectivas estructuras y la estructura de los datos que se presentan en cada celda de la matriz. Se asume que los datos en todas las celdas son uniformes, es decir, todas las posiciones de la matriz tienen datos con igual estructura. A los ejes se les llama Dimensiones y al dato que se presenta en la matriz, se le llama Medida. Generalmente, las dimensiones se estructuran en jerarquías de agregación. A cada nivel de una jerarquía se le llama Nivel de Agregación o simplemente Nivel. De esta forma, se puede considerar que
3 toda dimensión siempre tiene por lo menos una jerarquía con un único nivel. Pero una dimensión puede tener más de una jerarquía. Un ejemplo típico, es una dimensión que representa tiempo. En este caso, los niveles bimestre y trimestre no están relacionados entre sí, a pesar de que ambos están relacionados con mes y año. Para lograr representar esta realidad, CMDM presenta tres estructuras básicas: Niveles, Dimensiones y Relaciones Dimensionales. Niveles: Un nivel representa un conjunto de objetos que son de un mismo tipo. Cada nivel debe tener un nombre y un tipo. Conceptualmente, no tiene diferencia con cualquier elemento del Modelo Entidad Relación que pueda ser considerado un conjunto de Entidades. Dimensiones: Una dimensión está determinada por una jerarquía de niveles. Las dimensiones deben poder estructurarse en niveles, donde cada nivel debe tener una declaración en el conjunto de declaraciones del esquema. De esta forma, una dimensión es una tupla formada por un conjunto de niveles previamente declarados y un orden parcial con mínimo definido sobre los niveles. Toda dimensión, además, tendrá un identificador. Relaciones Dimensionales: Una relación dimensional representa el conjunto de todos los cubos que se pueden construir a partir de los niveles de un conjunto dado de dimensiones. Se asume que en cada uno de los cubos que pertenecen a la instancia de la relación dimensional, debe aparecer al menos un nivel de cada una de las dimensiones que participan en la relación. En CMDM, un cubo es una función que va del producto cartesiano de las instancias de los niveles en los booleanos. De esta forma, cualquier nivel puede cumplir el rol de medida. Por lo tanto, el esquema de una relación dimensional está dado por un grafo en forma de estrella. En las siguientes secciones mostramos el proceso a seguir para poder derivar qué conceptos de la realidad deben modelarse como dimensiones, cuáles como niveles, y cuál es la jerarquía que modela varios niveles. Más detalles sobre el modelo CMDM pueden consultarse en [6,7]. 3 Fases en el Diseño Multidimensional En el presente trabajo se propone una metodología que abarca desde la etapa inicial de Business modeling [8] hasta el diseño conceptual del DW. La metodología propuesta está soportada por una serie de fases apoyadas por el uso de una ontología de dominio. Esto permite lograr una visión global de los conceptos, realizar inferencias, verificar la consistencia del modelo y obtener la trazabilidad de los conceptos a lo largo del proceso. El ciclo de vida de la metodología propuesta consiste en tres fases secuenciales, diagramadas en la Figura 1, donde cada uno de los óvalos identifica una fase y las flechas marcadas en negro indican las dependencias más importantes y frecuentes entre las mismas.
4 Realidad Modelado de Conceptos Matriz de Requerimientos Modelo Conceptual Multidimensional (CMDM) Fase 1 Comprensión de la Realidad Fase 2 Modelado de Dominio Fase 3 Modelado Conceptual Multidimensional Requerimientos Ontología Fig. 1: Fases del Diseño Multidimensional guiado por Ontología. Fase I Análisis de la Realidad. El objetivo de esta fase es identificar todos los conceptos que componen el dominio del problema, junto con las relaciones existentes entre los mismos y las restricciones identificada para cada uno. Esta fase pretende transformar el conocimiento tácito que se encuentra en los expertos conocedores de la realidad en conocimiento explícito, de forma que el mismo se encuentre documentado y almacenado para que cualquier otro interesado en comprender la realidad pueda hacer uso de dicho conocimiento cuando lo considere necesario. Como entrada de esta fase se requiere el conjunto de requerimientos iniciales y la realidad planteada. Como resultado de la fase se cuenta con el documento Metadata de Conceptos, el cual contiene la información de contexto y datos importantes identificados para cada concepto. En este documento se incluye una descripción del dominio relevado, sobre el cual se deberá resolver los requerimientos, siendo la base para la realización del modelo de la realidad que se realizará en la Fase II (Modelado del Dominio). Los participantes de esta fase son los expertos conocedores de la realidad y analistas del equipo de desarrollo. Como condiciones para la finalización de la fase es necesario considerar que todo concepto que forme parte de la resolución de un requerimiento esté definido en el documento Metadata de Conceptos. Fase II Modelado del Dominio. El objetivo de esta fase es construir un modelo que represente, utilizando un modelo formal, los conceptos de la Fase I, detallados en el documento Metadata de Conceptos. El modelo incluirá la información y características más importantes, relaciones definidas y las restricciones consideradas en el análisis de la realidad, abstrayendo la realidad presentada y eliminando posibles inconsistencias y/o conflictos que no se hubieran identificado en la Fase I. Como entrada de la fase se requiere el documento Metadata de Conceptos obtenido en la fase I y el conjunto de requerimientos. Como resultado de la fase se obtiene la ontología que es el modelo semántico de dominio que representa la realidad relevada, modelando la información de contexto y datos importantes identificados para cada concepto, las relaciones entre estos y las restricciones identificadas. Adicionalmente, al finalizar la fase se cuenta con la Matriz de Requerimientos que refleja la interacción entre los conceptos y relaciones del modelo de dominio, y los requerimientos
5 analizados. Los participantes de esta fase son los analistas del equipo de desarrollo, diseñadores que formen parte del equipo de desarrollo y expertos conocedores de la realidad para consultas puntuales. Como condiciones para la finalización de la fase es necesario considerar que todo concepto que forme parte de la resolución de un requerimiento esté definido en la ontología de dominio. En los casos que se realicen cambios en la realidad será necesario validar que estas modificaciones se encuentren reflejadas en el documento Metadata de Conceptos y el modelo de dominio. Fase III Construcción del Modelo Multidimensional. El objetivo de esta fase es construir el modelo multidimensional CMDM a partir de la ontología de dominio guiado por los requerimientos. Como entrada de la fase se requiere el documento Metadata de Conceptos resultante de la Fase I del proceso, la Ontología del Dominio y la Matriz de Requerimientos obtenidos en la Fase II y el conjunto de Requerimientos iniciales. Para realizar el proceso de transformación de los conceptos y relaciones definidos en la ontología del dominio al modelo conceptual multidimensional es necesario contar con reglas que dirijan dicha transformación (estas reglas se muestran en la siguiente sección). Como resultado de la fase se cuenta con el modelo conceptual multidimensional. Como condición para finalizar la fase es necesario considerar que todos los requerimientos estén resueltos mediante el modelo conceptual. 4 Propuesta de Derivación del Modelo Multidimensional Para realizar la transformación del modelo de dominio, representado mediante una ontología, al modelo multidimensional CMDM, se propone un conjunto de once reglas, a partir de los cuales se podrán inducir pautas o condiciones que permitan tomar decisiones de diseño al momento de construir el modelo multidimensional CMDM. Regla 1 Definición de clases candidatas a niveles del modelo multidimensional. Para aplicar esta regla es necesario contar con la matriz de requerimientos y la Ontología de dominio. Para cada clase del conjunto C se identifican sus restricciones propias (no heredadas). Se agrega al conjunto C las clases correspondientes al rango de cada una de las propiedades participantes en las restricciones antes identificadas. Para cada una de las clases del conjunto C se identifica si la misma pertenece a una categorización en la ontología. En caso que se cumpla esta condición todas sus superclases se agregan al conjunto C. Las clases del conjunto C que en la ontología tengan al menos una propiedad que no sea heredada, son consideradas como correspondientes a niveles en CMDM. Regla 2 Definición de niveles del modelo multidimensional. Para aplicar esta regla es necesario contar con el conjunto de clases candidatas a niveles (Regla 1) y la ontología de dominio. Para cada una de las clases del conjunto de clases consideradas como correspondientes a niveles del modelo multidimensional, se identifica en la ontología su nombre y las propiedades definidas como datos simples (Data Properties). Cada uno de los niveles se nombrará según el nombre que la clase tenga
6 definido en la ontología. Los atributos de los niveles quedarán determinados por las propiedades definidas como propias, considerando solo los datos simples. Regla 3 Definición de Cardinalidades. Esta regla sirve para identificar las relaciones existentes entre las clases del conjunto de clases a mapearse como niveles. Para aplicar esta regla es necesario contar con el conjunto de clases a corresponderse como niveles y la Ontología de dominio. A continuación se detallan las consideraciones realizadas para obtener la cardinalidad. 1. En las relaciones para las cuales no se haya definido una restricción de cardinalidad se considera que la cardinalidad asociada desde la clase dominio a la clase rango es N. Esto se define así porque al no existir restricción de cardinalidad definida se establece que un individuo del dominio puede relacionarse con N entidades de la clase rango. 2. Si una relación tiene definida una relación inversa, la cardinalidad definida en la dirección rango-dominio está dada por las restricciones de cardinalidad para la relación inversa definida. 3. Si una relación no tiene definida una relación inversa, la cardinalidad definida para esta relación inversa se asume como cardinalidad N, en dirección rangodominio. Con esto se denota que un individuo de la clase rango puede relacionarse con N individuos de la clase dominio. En las relaciones para las cuales no se haya definido una restricción de cardinalidad se considera que la cardinalidad asociada desde la clase dominio a la clase rango es N. Si una relación no tiene definida una relación inversa, la cardinalidad definida para esta relación inversa se asume como cardinalidad N, en dirección rango-dominio. La cardinalidad entre dos clases queda definida por la cardinalidad de la relación entre estas dos clases y la cardinalidad de su relación inversa. Regla 4 Identificación de orden entre niveles a partir de cardinalidad N:1. Esta cardinalidad establece que las entidades pertenecientes a la clase dominio pueden relacionarse con una única entidad del rango y que a la vez una entidad del rango puede asociarse a muchos (denotando esto como N) individuos del dominio. Esto puede interpretarse como una posible relación de agrupación de datos desde la clase dominio hacia la clase rango. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad N:1 y el conjunto de niveles. Para cada relación del conjunto de relaciones identificadas con cardinalidad N:1 se define un orden entre dos niveles donde la clase que participa con cardinalidad N se corresponde como nivel inferior y la clase que participa con cardinalidad 1 se corresponde como nivel superior. De esta manera se obtiene un orden entre los niveles en CMDM. Regla 5 Identificación de orden entre niveles a partir de cardinalidad 1:N. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad 1:N y el conjunto de niveles. Para cada relación del conjunto de relaciones identificadas con cardinalidad 1:N, se define un orden entre dos niveles donde la clase con cardinalidad 1 se corresponde como nivel superior y la clase que participa con cardinalidad N se corresponde como nivel inferior. De esta manera se obtiene un orden entre los niveles en CMDM. Regla 6 Identificación de orden entre niveles a partir de cardinalidad N:N. Esta cardinalidad establece que cualquier elemento de una de las clases que interviene en la cardinalidad, puede asociarse con una cantidad no definida de elementos de la otra
7 clase participante. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de relaciones identificadas con cardinalidad N:N, y el conjunto de niveles. Esta regla define cuando dos niveles no pueden ser parte de una misma jerarquía. Las clases que definen estas relaciones son independientes entre sí, no existiendo características por la cual sea posible agruparlas. Es posible considerar dos posibles casos.(figura 2): (i) las clases se corresponden como niveles de jerarquías diferentes en una misma dimensión, y (ii) las clases se corresponden como niveles de diferentes dimensiones. La decisión entre (i) y (ii) depende del caso en particular que se esté resolviendo pero las clases nunca podrán corresponderse como niveles de una misma jerarquía. Ontología CMDM Cardinalidad N:N C1 C2 N C1 N Posible Equivalencia C2 Posible Equivalencia C1 C2 Fig. 2 : Correspondencias de cardinalidad N:N Regla 7 Identificación de orden entre niveles a partir de relaciones 1:1 con totalidad. Dada la relación que cumple con cardinalidad 1:1 y cuenta con la propiedad de totalidad, ya sea para la clase dominio o para la clase rango, se construye la jerarquía haciendo corresponder la clase para la cual se cumple la totalidad como nivel superior y la clase restante conforma el nivel inferior. De este modo, al realizar las operaciones entre niveles, es posible obtener elementos que cumplan las características dadas, descartando aquellos que no lo hagan. Para aplicar esta regla es necesario contar con la ontología de dominio, el conjunto de niveles identificados que participan en una relación con cardinalidad 1:1 con totalidad. Regla 8 Identificación de orden entre niveles a partir de cardinalidad 1:1. Cualquiera de las clases participantes en la cardinalidad puede ser considerada como nivel superior o inferior, quedando a criterio del diseñador definir el orden entre los niveles. Esta decisión depende del caso en particular que se esté resolviendo Regla 9 Categorización de las subclases. Cuando una clase tiene un conjunto de subclases y a su vez estas clases tienen la propiedad de ser disjuntas entre sí, se cumple que cada subclase es una categorización o clasificación de los elementos de la superclase, según alguna característica. (Por ejemplo las clases Auto, Camioneta y Camión son disjuntas entre sí y son subclases de la clase Vehículo). Dado que las subclases son una especialización de la superclase, es posible considerar un nuevo nivel que permita representar la característica común de las subclases (en el ejemplo todas son un tipo de vehículo). Según lo definido es posible conformar un nuevo orden entre niveles, donde la superclase sé corresponde como el nivel inferior y el
8 nuevo nivel como superior. El nuevo nivel tiene miembros que representan las distintas categorizaciones, para esto se define un atributo que permite identificar cada uno de los elementos que conforman el nivel. Por lo tanto, en este regla, para cada clase del conjunto de clases a corresponderse como niveles, se debe identificar aquellas que son superclases y cuyas subclases sean disjuntas. Dada una superclase del conjunto, pueden obtenerse un nuevo orden entre niveles donde la superclase se corresponda como nivel inferior y como nivel superior se crea un nivel que agrupe todas las subclases. Al nivel superior se le asigna un nombre que identifique la agrupación, por ejemplo TipoCategoría. (Figura 3). Para este nivel se define un atributo que permita identificar cada uno de los elementos que lo conforman. Para aplicar esta regla es necesario contar con la ontología de dominio y el conjunto de clases a corresponderse como niveles. Herencia: Ontología Niveles: CMDM C1 C11 Tipo Cat 1 (C11, C12, ) C12 N C2 (C11 y C12 Disjuntas) Fig. 3: Correspondencia de herencia Regla 10 Identificación de dimensiones en CMDM. En esta regla se busca identificar las tuplas de niveles ordenados las cuales tengan algún nivel en común. Una dimensión queda formada por el subconjunto de tuplas de niveles previamente ordenados que tengan algún nivel en común, manteniendo el orden parcial definido entre ellos. Las dimensiones deben tener un nivel mínimo donde exista un identificador para cada elemento de la misma. Gráficamente la dimensión se forma uniendo las tuplas ordenadas según el nivel en común, manteniendo el orden definido. Todos los niveles deben formar parte de alguna dimensión. Puede ocurrir que exista una dimensión con un único nivel. Para aplicar esta regla es necesario contar con el conjunto de niveles y el conjunto de niveles parcialmente ordenados. Regla 11 Identificación de relaciones dimensionales en CMDM. En el caso de contar con una dimensión donde a partir de su nivel inferior I se desprendan varias jerarquías, y a su vez la cardinalidad entre I con los niveles superiores sea N:1 en todos los casos, es posible definir una relación dimensional donde I sea el eje central de la relación. Las dimensiones que definen dicha relación dimensional quedan formadas por el conjunto de niveles superiores a partir del eje central. En el caso de contar con un conjunto de dimensiones donde su nivel inferior I es común a todas, y a su vez la cardinalidad entre I y los niveles superiores sea N:1 en todos los casos, es posible definir una relación dimensional donde I sea el eje central de la relación. Las
9 dimensiones que definen dicha relación dimensional quedan formadas por el conjunto de niveles superiores a partir del eje central. Esta consideración queda en manos del diseñador, ya que debe ser él quien defina el eje central de la discusión. 5 Ejemplo Práctico Como caso practico, para poder aplicar la metodología desarrollada en el proyecto y poder comparar los resultados, se realizó el re-diseño de un conjunto de indicadores existentes. El DW que alberga dichos indicadores se encuentra desarrollado sobre el sistema OPEN SIC (Sistema de Información Clínica) de la empresa Soluziona. OPENSIC es un Sistema de Información Clínico Integrado orientado a organizaciones prestadoras de servicios de salud. Fase I. En primera instancia se presentaron los siguientes 4 requerimientos que forman el conjunto de requerimientos iniciales: (R1) Porcentaje de egresos quirúrgicos, (R2) Promedio de estancia, (R3) Tasa de mortalidad infantil y (R4) Tasa de mortalidad infantil post neo-natal. Lo primero es realizar un análisis conceptual de cada uno de los requerimientos. Para esto, en el caso presentado se desglosó cada uno en los conceptos que lo conforman, como por ejemplo egreso quirúrgico, estancia, mortalidad infantil y mortalidad infantil post neo-natal. Se define entonces, junto a personal de la empresa, una descripción para cada requerimiento de manera de dejar explícito el objetivo de cada uno. Las descripciones definidas para cada requerimiento son las siguientes: 1. Porcentaje de egresos quirúrgicos: porcentaje de egresos quirúrgicos sobre la cantidad de egresos totales en un período determinado 2. Promedio de estancia: promedio de tiempo de internación (días) de los pacientes en un período determinado 3. Tasa de mortalidad infantil: cantidad de defunciones de pacientes menores de 1 año en relación con el número de nacidos vivos durante el mismo período 4. Tasa de mortalidad infantil post neo-natal: cantidad de defunciones de pacientes entre 28 y 364 días de edad en relación con el número de nacidos vivos durante el mismo período. Analizando el requerimiento 1.se deriva que para este requerimiento existen tres conceptos identificados egreso quirúrgico, egreso hospitalario y tiempo. Como resultado de esta fase se tiene el documento Metadata de Conceptos en el cual se establece el sentido y la semántica de cada uno de los conceptos identificados en la realidad guiada por los requerimientos. La propuesta que planteamos presenta una plantilla diseñada con el fin de brindar ayuda al momento de definir la información de contexto y datos importantes identificados para cada concepto, sin embargo, por motivos de espacio omitimos el desarrollo de esta fase pero la misma se puede encontrar en [9].
10 Fase II. En esta fase se trabaja sobre la Ontología del Dominio definiendo el conjunto de conceptos, las relaciones existentes entre estos y las restricciones de cada uno. Esta ontología permitió, mediante el uso del razonador Racer [10], realizar el chequeo de consistencia del modelo. Como observación particular del caso propuesto, ocurre que al momento de crear la ontología además de modelar las relaciones definidas en el documento Metadata de Conceptos surgieron nuevas relaciones, inferidas del modelo que no se habían identificado hasta el momento pero que efectivamente se cumplen entre los elementos del modelo. La Figura 4 ilustra gráficamente las relaciones encontradas para el requerimiento 1. Fig. 4 : Gráfica de la ontología de dominio correspondiente al requerimiento 1. Una vez identificados los conceptos y relaciones participantes en la resolución del requerimiento analizado, éstos se agregan a la Matriz de Requerimientos. De esta manera resulta sencillo verificar si un cambio afecta o no la resolución de un requerimiento simplemente identificando si el concepto o relación modificada participa o no en la resolución del requerimiento en cuestión. En [9] se utiliza una tabla que define, para cada requerimiento, el conjunto de dimensiones y medidas necesarias para su resolución. La matriz propuesta en esta etapa, a diferencia de la matriz utilizada en [9], vincula cada requerimiento con los conceptos y relaciones que participan en su resolución, es decir vincula cada requerimiento con un concepto semántico y no con una estructura del modelo conceptual.. En la Figura 5 se presenta la matriz de requerimientos con los conceptos identificados para el requerimiento R1. Fase III. Aplicando la Regla 1 se obtiene que las clases candidatas a corresponderse como niveles en el modelo multidimensional son: Egreso_Hospitalario y Actividad_Quirurgica. Aplicando la Regla 2 de forma iterativa se identifican las clases Prestación, Internado, Admitido, Persona y Registro que son agregadas al conjunto de candidatas a niveles del modelo. La Regla 3, a partir de las nuevas clases participantes de la resolución del requerimiento, actualiza la matriz de
11 requerimientos de manera de incluir las clases y las is-a. De esta manera, ante cambios en el requerimiento se puede seguir la traza de las clases y relaciones que se ven afectadas (Figura 6). Concepto R1 R2 R3 R4 Clases Egreso_Quirurgico Egreso_Hospitalario Actividad_Quirurgica Fecha Relaciones internado_tiene_actividadquirurgica egresohospitalario_tiene_fechaegreso Herencia Egreso_Quirurgico is a Egreso_Hospitalario Fig. 5 - Matriz de Requerimientos luego de la Fase II. Concepto R1 R2 R3 R4 Clases Egreso_Quirurgico Egreso_Hospitalario Actividad_Quirurgica Prestación Internado Admitido Persona Registro Relaciones internado_tiene_actividadquirurgica actividadquirurgica de_internado Herencia Egreso_Quirurgico is a Egreso_Hospitalario Egreso_Hospitalario is a Internado Internado is a Admitido Admitido is a Persona ActividadQuirurgica is a Prestacion Prestacion is a Registro l Fig. 6 - Matriz de Requerimientos Fase III, luego de la Regla 3. Las jerarquías del modelo multidimensional se obtendrán mediante la ejecución de las Reglas 4 a la 9, donde las Reglas 4 a la 7 se basan totalmente en la cardinalidad de las relaciones identificadas. Las Reglas 8 y 9 consideran, además, la condición de totalidad de las relaciones. La cardinalidad definida para las relaciones de interés son lasque muestra la Figura 7. Es importante aclarar que la relación internado_tiene_actividadquirurgica no es de interés dado que depende de la clase Egreso_Quirurgico que no es candidata a nivel en el modelo CMDM. Aplicando la Regla 4 a la relación actividadquirurgica de_internado se obtiene Internado como
12 nivel superior a Actividad_quirurgica, y aplicando la Regla 5 al resto de las relaciones se obtiene que Egreso_Hospitalario, Internado y Admitido corresponde a niveles superiores respectivamente de Internado, Admitido y Persona. Aplicando luego la Regla 10 se obtienen las dimensiones ilustradas en la Figura 8. Relación Clase Origen (Co) Clase Destino (Cd) Cardinalidad desde Co a Cd actividadquirurgica Actividad_quirurgica Internado N:1 de_internado Egreso_Quirurgico is a Egreso_Quirurgico Egreso_Hos N:1 Egreso_Hospitalario pitalario Egreso_Hospitalario is Egreso_Hospitalario Internado 1:N a Internado Internado is a Internado Admitido 1:N Admitido Admitido is a Persona Admitido Persona 1:N ActividadQuirurgica is Actividad_quirurgica Prestacion 1:N a Prestacion Prestacion is a Prestacion Registro 1:N Registro Fig. 7: Cardinalidad de la Relaciones de interés. VVVVV Egreso_Hospitalario Internado Admitido Persona Nombre:String Cedula:String Telefono:String BBBBB Egreso_Hospitalario Internado Actividad_quirurgica Descripción:String Prestacion Registro Descripcion:String Fig. 8: Dimensiones resultado de la aplicación de la Regla 10. Para la identificación de las relaciones dimensionales no se puede aplicar la Regla 11 ya que no se está en el caso de tener un conjunto de dimensiones donde su nivel mínimo forme parte de más de una dimensión o a partir de su nivel mínimo se desprendan varias jerarquías, resultando entonces las relaciones dimensionales de la Figura 9.
13 Fecha Personas Egresos Registro Fig. 9: Relaciones Dimensionales. 6 Conclusiones y Trabajos Futuros En este trabajo presentamos una propuesta metodológica para el diseño conceptual multidimensional guiado por ontología del dominio. Existen diversos trabajos sobre como realizar el diseño multidimensional. En [11] se presenta una metodología guiada por los requerimientos para el diseño conceptual, sin embargo no cuenta con un relevamiento del significado de los conceptos del dominio como lo proponemos a través de la ontología, ni prevé mecanismos para ayudar a la evolución de los requerimientos como la Matriz de Requerimientos que presentamos. En [12] se propone una adaptación de una arquitectura estándar para el desarrollo de software, llamada MDA (Model Driven Architecture) que guía el ciclo de vida completo del diseño, desarrollo, integración y administración de aplicaciones utilizando modelos en desarrollo de software. Se describe como crear los distintos artefactos (modelos) MDA por medio de extensiones de UML, también se describen las transformaciones necesarias entre modelos utilizando la aproximación Query/View/Transformatcin (QVT). Aunque se explicita la transformación de los distintos modelos, no es claro como se construye el modelo multidimensional, del cual parte la arquitectura. Creemos que las pautas presentadas para las tres Fases del diseño Multidimensional acompañadas con las Reglas de derivación desde la Ontología son un mecanismo práctico, viable para ser ensayado en casos reales. La Tabla 1 compara nuestra propuesta, que llamamos MD4DW [13], con otras. Los parámetros considerados son: si se genera un modelo conceptual multidimensional, si hay ejemplos complejos de aplicación de la propuesta, si se justifican los pasos seguidos en la obtención de la propuesta, si se consideran los requerimientos en la etapa de Análisis y Diseño, si existe trazabilidad desde los conceptos de la realidad hasta el modelo conceptual multidimensional, si la propuesta brinda soporte para la realización del análisis de impacto frente a cambios en los requerimientos, la última columna indica si la propuesta propone la elaboración de un modelo semántico que contenga el significado de los conceptos del dominio. En estos momentos estamos a la búsqueda de diseñadores de DW que quieran experimentar nuestra propuesta, creemos que es necesario que sea aplicada por terceras partes externas al proyecto para poder evaluar objetivamente sus impactos.
14 Como trabajo futuro es importante estudiar la viabilidad de automatizar el proceso generando un software integral que permita asistir la construcción de un DW, basándose en MD4DW, desde el análisis de la realidad hasta el diseño físico. Tabla 1. Comparación de Metodologías para diseño de DW. PROPUESTA M.Concep. Ej Justif. Req. Traza Imp. M. Semántico Golf98 [1] X X Gio05 [11] X X -- X Maz05 [12] X X X Kim98 [14] -- X MD4DW [13] X X X X X X X Referencias [1] Golfarelli, M.; Rizzi S.: A methodological framework for data warehouse design. In Proc. DOLAP, pages 3-9 (1998). [2] Huesemann B., Lechtenboerger J., Vossen G.: Conceptual data warehouse design. In Proc. DMDW, pages 3-9 (2000). [3] Luján-Mora S., Trujillo J.: A comprehensive method for data warehouse design. In Proc. DMDW (2003). [4] Rizzi, S., Abelló A., Lechtenboerger J., Trujillo J.: Research in DataWarehouse Modeling and Design: Dead or Alive? DOLAP, USA (2006). [5] Gruber T. R: A Translation Approach to Portable Ontology Specifications. Knowledge Acquisition, 5(2), 1993, pp (1993). [6] Carpani.F.: CMDM: Un Modelo Conceptual para la Especificación de Bases Multidimensionales,Tesis de Maestría, Facultad de Ingeniería, UdelaR, (2000). [7] Carpani, F., Ruggia R.: An Integrity Constraints Language for a Conceptual Multidimensional Data Model XIII International Conference on Software Engineering & Knowledge Engineering (SEKE'01), Buenos Aires, Argentina, (2001). [8] IBM Rup: Rational Unified Process, [9] Ballard, C., Herreman D., Schau D. Bell D. Kim R., Valncic E.: Data Modeling Techniques for Data Warehousing SG IBM Red Book.ISBN (1998). [10] Racer - [11] Giorgini P., Rizzi S., Garzetti M.: Goal-Orientes Requierement Analysis for Data Warehouse Design. Engineering Applications of Artificial Intelligence, Elsvier (2005). [12] Mazon J., Trujillo J.,.Serrano M., Piattini M., Applying MDA to the Development of Data Warehouse, DOLAP 05 (2005). [13] Gimenez S., Godoy D. Colombatto C. Carpani F, Motz R.: Proyecto MD4DW: Metadata for Data Warehouse. Universidad de la República (Uruguay) [14] Kimball, R. Reeves, L. Ross, M. Thornthwaite, W.: The Datawarehouse Lifecycle Toolkit. John Wiley & Son, Inc.(1998).
Dirección de Informatización, Universidad Camagüey, Cuba. lindsay.gomez@reduc.edu.cu b
The conceptual modeling in the process of computer-assisted generation of data warehouse models Lindsay Alonso Gómez-Beltrán a, Rosendo Moreno-Rodríguez b & Ramiro Pérez-Vázquez c a Dirección de Informatización,
MODELO DIMENSIONAL DE BODEGAS DE DATOS ADAPTABLE A EMPRESAS MIPYMES DE VENTAS AL DETAL
MODELO DIMENSIONAL DE BODEGAS DE DATOS ADAPTABLE A EMPRESAS MIPYMES DE VENTAS AL DETAL 1 Ing. Ingrid Paola Solano Benítez¹ Mg. Martha Eliana Mendoza Becerra² ¹ Docente Tiempo Completo, Facultad de Ingeniería,

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución