Diseño Multidimensional guiado por Ontología

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Diseño Multidimensional guiado por Ontología"

Transcripción

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

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Sistema de análisis de información. Resumen de metodología técnica

Sistema de análisis de información. Resumen de metodología técnica Sistema de análisis de información Resumen de metodología técnica Tabla de Contenidos 1Arquitectura general de una solución de BI y DW...4 2Orígenes y extracción de datos...5 2.1Procesos de extracción...5

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Evaluación de una Metodología para la construcción de Data Warehouses

Evaluación de una Metodología para la construcción de Data Warehouses Instituto de Computación Facultad de Ingeniería Universidad de la República Evaluación de una Metodología para la construcción de Data Warehouses Data Warehouse para la plataforma EVA Agustín Mullin Proyecto

Más detalles

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1

ANEXO A - Plan de Proyecto. 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 ANEXO A - Plan de Proyecto 1. - EDT de la solución EDT GENERAL DEL PROYECTO1 2.- Diagrama de Gantt de la Solución DIAGRAMA DE GANTT- FASE INICIAL DOCUMENTACION Y ANALISIS2 DIAGRAMA DE GANTT- FASE FINAL

Más detalles

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre

Clase 10. Ingeniería de ontologías. Mg. A. G. Stankevicius. Segundo Cuatrimestre Ingeniería de Aplicaciones para la Web Semántica Clase 10 Ingeniería de ontologías Mg. A. G. Stankevicius Segundo Cuatrimestre 2005 Copyright 2 Copyright 2005 A. G. Stankevicius. Se asegura la libertad

Más detalles

M III ABSTRACCIÓN Y CLASIFICACIÓN

M III ABSTRACCIÓN Y CLASIFICACIÓN M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se

Más detalles

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS

Inteligencia de Negocios Introducción. Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Inteligencia de Negocios Introducción Por Elizabeth León Guzmán, Ph.D. Profesora Ingeniería de Sistemas Grupo de Investigación MIDAS Agenda 1.Introducción 2.Definición 3.ETL 4.Bodega de Datos 5.Data Mart

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses

Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses Implementación de herramientas CASE que asistan en el Diseño de Data Warehouses Verónika Peralta, Raúl Ruggia Universidad de la República, Uruguay. {vperalta, ruggia}@fing.edu.uy Resumen: Un Data Warehouse

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

Más detalles

Gestión de Requisitos ULPGC

Gestión de Requisitos ULPGC Gestión de Requisitos ULPGC Gestión de Requisitos Consiste en gestionar los cambios de los requisitos, las relaciones entre ellos, las dependencias entre la especificación de requisitos y otros documentos

Más detalles

rg.o cm a Diseñ e o o l óg ó ico c l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s s r e r la l c a i c o i nal a e l s

rg.o cm a Diseñ e o o l óg ó ico c l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s s r e r la l c a i c o i nal a e l s Diseño lógico Diseño de bases de datos relacionales Diseño lógico de bases de datos relacionales El modelo relacional: El concepto de relación: tuplas, atributos y dominios. Restricciones de integridad

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Búsqueda sobre catálogos basada en ontologías

Búsqueda sobre catálogos basada en ontologías Búsqueda sobre catálogos basada en ontologías Alianis Pérez Sosa, Yuniel Eliades Proenza Arias Universidad de las Ciencias Informáticas. Carretera a San Antonio Km 2 ½, Reparto Torrens, La Lisa, Ciudad

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Desarrollo de Ontologías

Desarrollo de Ontologías Desarrollo de Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Desarrollo de Ontologías Curso 2014/2015 1 / 31 Índice 1 Introducción 2 Metodologías de desarrollo ECSDI (LSI-FIB-UPC

Más detalles

Calidad de la Adaptación de Cursos a Perfiles de Estudiantes

Calidad de la Adaptación de Cursos a Perfiles de Estudiantes Calidad de la Adaptación de Cursos a Perfiles de Estudiantes Regina Motz Instituto de Computación, Facultad de Ingeniería, Universidad de la República, Uruguay rmotz@fing.edu.uy Maximiliano Canario Instituto

Más detalles

Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas

Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas Construcción de un sistema de apoyo a la toma de decisiones para el área gerencial del Hospital de Clínicas Alejandro Gutiérrez, Regina Motz, Beatriz Revello, Lydia Silva Instituto de Computación, Facultad

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process

Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Metodologías de desarrollo para Service Oriented Architectures con Rational Unified Process Andrea Delgado 1, Ignacio García-Rodríguez de Guzmán 2, Francisco Ruiz 2, Mario Piattini 2 1 Instituto de Computación,

Más detalles

Tema 1 Introducción a los Sistemas Basados en el Conocimiento

Tema 1 Introducción a los Sistemas Basados en el Conocimiento Tema 1 Introducción a los Sistemas Basados en el Conocimiento Sistemas Basados en el Conocimiento Grado en Ingeniería Informática 1 Referencias Ingeniería del Conocimiento. A. Gómez, N. Juristo, C. Montes,

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

Introducción. Francisco J. Martín Mateos. Dpto. Ciencias de la Computación e Inteligencia Artificial Universidad de Sevilla

Introducción. Francisco J. Martín Mateos. Dpto. Ciencias de la Computación e Inteligencia Artificial Universidad de Sevilla Francisco J. Martín Mateos Dpto. Ciencias de la Computación e Inteligencia Artificial Universidad de Sevilla Qué es la (KE)? Definición de Wikipedia: La es una disciplina cuyo objetivo es integrar conocimiento

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR

METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR METODOLOGÍA PARA ORGANIZAR, RECUPERAR Y COMPARTIR RECURSOS DE INFORMACIÓN Y CONOCIMIENTO EN UN CENTRO I+D+I EN LA PLATAFORMA SURICATA Marrero, S.R; Nelson, J.C; Galán, M; Ocón, A.; Rubio, E. sonia@cicei.com;

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias

El diseño de la base de datos de un Data Warehouse. Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El diseño de la base de datos de un Data Warehouse Marta Millan millan@eisc.univalle.edu.co www.eisc.univalle.edu.co/materias El modelo Multidimensional Principios básicos Marta Millan millan@eisc.univalle.edu.co

Más detalles

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) SYLLABO UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS (Universidad del Perú, DECANA DE AMÉRICA) FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA Escuela Académico Profesional de Ingeniería de Sistemas 1. ESPECIFICACIONES

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

GUIA METODOLOGÍCA PARA LA IMPLEMENTACIÓN DE BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE INTELIGENCIA DE NEGOCIOS

GUIA METODOLOGÍCA PARA LA IMPLEMENTACIÓN DE BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE INTELIGENCIA DE NEGOCIOS BODEGA DE DATOS CORPORATIVA Y SOLUCIONES DE Oficina de Informática Departamento Nacional de Planeación Bogotá, 2013 TABLA DE CONTENIDO PÁGINA: 2 de 35 VERSIÓN: 0 1 OBJETIVO... 3 2 ALCANCE... 3 3 REFERENCIAS

Más detalles

CA ERwin Data Profiler

CA ERwin Data Profiler RESUMEN DEL PRODUCTO: CA ERWIN DATA PROFILER CA ERwin Data Profiler CA ERWIN DATA PROFILER AYUDA A LAS ORGANIZACIONES A REDUCIR LOS COSTOS Y RIESGOS ASOCIADOS CON LA INTEGRACIÓN DE DATOS, AL BRINDAR CAPACIDADES

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

Más detalles

Estrategias Didácticas B-Learning: ÁLGEBRA RELACIONAL

Estrategias Didácticas B-Learning: ÁLGEBRA RELACIONAL Estrategias Didácticas B-Learning: ÁLGEBRA RELACIONAL Mg. Guillermo Bernardo Durán González Guillermo.duran.g@gmail.com Modelo de diseño instruccional, basado en la modalidad semi-presencial b-learning,

Más detalles

Construcción de cubos OLAP utilizando Business Intelligence Development Studio

Construcción de cubos OLAP utilizando Business Intelligence Development Studio Universidad Católica de Santa María Facultad de Ciencias e Ingenierías Físicas y Formales Informe de Trabajo Construcción de cubos OLAP utilizando Business Intelligence Development Studio Alumnos: Solange

Más detalles

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Sandra Casas y Cecilia Fuentes Zamorano UARG, Universidad Nacional de la Patagonia Austral Campus Universitario, Piloto Riversa s/n

Más detalles

Modelado de datos. Bibliografía. Representación de la información Modelos de datos Modelado semántico

Modelado de datos. Bibliografía. Representación de la información Modelos de datos Modelado semántico Modelado de datos Representación de la información Modelos de datos Modelado semántico El modelo entidad/relación Elementos: Entidades, atributos, claves y relaciones Representación gráfica: Diagramas

Más detalles

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

Extracción e Integración de Información en una Arquitectura de Web Warehouses

Extracción e Integración de Información en una Arquitectura de Web Warehouses Extracción e Integración de Información en una Arquitectura de Web Warehouses Verónica Giaudrone Marcelo Guerra Marcelo Vaccaro Proyecto de Grado CSI Facultad de Ingeniería Agenda λ Motivación λ Arquitectura

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Estos documentos estarán dirigidos a todas las personas que pertenezcan a equipos de implementación de Oracle BI, incluyendo a:

Estos documentos estarán dirigidos a todas las personas que pertenezcan a equipos de implementación de Oracle BI, incluyendo a: Oracle Business Intelligence Enterprise Edition 11g. A lo largo de los siguientes documentos trataré de brindar a los interesados un nivel de habilidades básicas requeridas para implementar efectivamente

Más detalles

Matriz de Riesgo, Evaluación y Gestión de Riesgos

Matriz de Riesgo, Evaluación y Gestión de Riesgos Matriz de Riesgo, Evaluación y Gestión de Riesgos Cualquier actividad que el ser humano realice está expuesta a riesgos de diversa índole los cuales influyen de distinta forma en los resultados esperados.

Más detalles

Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería

Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería Análisis del proceso de carga del Sistema de Data Warehousing de Enseñanza de la Facultad de Ingeniería Lorena Etcheverry, Pablo Gatto, Salvador Tercia CSI, Instituto de Computación, Facultad de Ingeniería

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Maestría en Bioinformática. Bases de Datos y Sistemas de Información. Del MER al MR. Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com.

Maestría en Bioinformática. Bases de Datos y Sistemas de Información. Del MER al MR. Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com. Maestría en Bioinformática Bases de Datos y Sistemas de Información Del MER al MR Ing. Alfonso Vicente, PMP alfonso.vicente@logos.com.uy Agenda Conceptos MER a MR Introducción Agenda Conceptos MER a MR

Más detalles

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto

Organizaciones Virtuales e Integración de Información. José Abásolo Prieto Organizaciones Virtuales e Integración de Información José Abásolo Prieto Universidad de los Andes Objetivo de la charla Mostrar que aunque la problemática de integración de información distribuida y heterogénea

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Programa Agenda de Conectividad Estrategia de Gobierno en línea

Programa Agenda de Conectividad Estrategia de Gobierno en línea Programa Agenda de Conectividad Estrategia de Gobierno en línea República de Colombia - Derechos Reservados Bogotá D.C, Marzo de 2010 PROGRAMA AGENDA DE CONECTIVIDAD ESTRATEGIA DE GOBIERNO EN LÍNEA GUÍA

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA

ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA ARQUITECTURA ESCALABLE PARA LA DETECCIÓN DE PATRONES SECUENCIALES DIFUSOS EN MINERÍA DE DATOS CUANTITATIVA Pablo F. Provasi 1 Lucio J. Kleisinger 1 Francisco R. Villatoro 2 1 Dpto. de Informática, Universidad

Más detalles

Concepción - Chile Marcela Varas Universidad de Concepción Chile - 2012

Concepción - Chile Marcela Varas Universidad de Concepción Chile - 2012 Presentación Concepción - Chile www.udec.cl Universidad de Concepción - Chile Estudiantes Universidad de Concepción Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción 1.1. Propósito de la Guía BABOK El propósito principal de la Guía BABOK Guide es definir la profesión del Análisis de Negocio y proveer un conjunto de prácticas comúnmente aceptadas.

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

CAPÍTULO 2 DATA WAREHOUSES

CAPÍTULO 2 DATA WAREHOUSES CAPÍTULO 2 DATA WAREHOUSES Un Data Warehouse (DW) es un gran repositorio lógico de datos que permite el acceso y la manipulación flexible de grandes volúmenes de información provenientes tanto de transacciones

Más detalles

Qué es una ontología?

Qué es una ontología? Ontologías Qué es una ontología? Una ontología define un vocabulario común para investigadores que necesitan compartir información del dominio. Contiene: Definiciones de conceptos básicos Relaciones que

Más detalles

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4

Definición. Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición Data Warehousing: almacenamiento, transformación y distribución de datos útiles para los responsables de tomar decisiones 9/29/2006 4 Definición (cont.) Un Data Warehouse es una colección de

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos.

Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos. Diseño de almacén de datos para el análisis eficiente de la información de incidentes informáticos y mantenimientos. Ing. Corso Cynthia, Ing. Luque Claudio, Ing. Ciceri Leonardo, Sr Donnet Matías Grupo

Más detalles

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Vegega, C., Pytel, P., Ramón, H., Rodríguez, D., Pollo-Cattaneo, F.,

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Unidad 5. Modelo de objetos del dominio del problema. Trimestre 10-I. Universidad Autonomía Metropolitana. Unidad 5

Unidad 5. Modelo de objetos del dominio del problema. Trimestre 10-I. Universidad Autonomía Metropolitana. Unidad 5 objetos del dominio del problema Universidad Autonomía Metropolitana Trimestre 10-I Contenido de la unidad 1 Objetivos Su objetivo es delimitar el sistema y capturar la funcionalidad que éste debe ofrecer

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Programa de Asignatura Base de datos

Programa de Asignatura Base de datos 01 Carrera: Lic. Tecnología Informática 02 Asignatura: Base de datos 03 Año lectivo: 2013 04 Año de cursada: 2 05 Cuatrimestre: 2 06 Hs. Totales 6 07 Profesor: Lic.Pablo Sanz Programa de Asignatura Base

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Cecilia Datko 1, Yanela Carllinni 2 Analista de Sistemas en el Depto. Sistemas de la Dirección de Informática

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

ARQUITECTURA DE UNA BODEGA DE DATOS

ARQUITECTURA DE UNA BODEGA DE DATOS ARQUITECTURA DE UNA BODEGA DE DATOS Estructura de contenidos INTRODUCCIÓN... 3 1. ARQUITECTURA DE UNA BODEGA DE DATOS... 3 1.1 PROPIEDADES... 3 1.2 ARQUITECTURA DE UNA CAPA... 4 1.3 ARQUITECTURA DE DOS

Más detalles

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas 1114. ASIGNATURA: BASE DE DATOS Año 2011

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas 1114. ASIGNATURA: BASE DE DATOS Año 2011 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas Código Asignatura 1114 ASIGNATURA: BASE DE DATOS Año 2011 FUNDAMENTACIÓN Base de datos contribuye a la formación del Ingeniero en Informática por

Más detalles

Modelo Entidad-Relación

Modelo Entidad-Relación Modelo Entidad-Relación El modelo de datos de entidad-relación (ER) se basa en una percepción de un mundo real que consiste en un conjunto de objetos básicos llamados entidades y de relaciones entre estos

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles