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 }@fing.edu.uy 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

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

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas. El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los

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

Unidad 1. Fundamentos en Gestión de Riesgos

Unidad 1. Fundamentos en Gestión de Riesgos 1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.

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

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

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

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

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

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

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

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

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

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

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

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

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

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

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

UML, ejemplo sencillo sobre Modelado de un Proyecto

UML, ejemplo sencillo sobre Modelado de un Proyecto UML, ejemplo sencillo sobre Modelado de un Proyecto Normal &DOLILFDU 0L3DQRUDPD 626 (VFULEHSDUD1RVRWURV Por Armando Canchala Contenido Introducción Objetivo Requerimientos Casos de Uso Subcasos de Uso

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

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

Capítulo VI. Diagramas de Entidad Relación

Capítulo VI. Diagramas de Entidad Relación Diagramas de Entidad Relación Diagramas de entidad relación Tabla de contenido 1.- Concepto de entidad... 91 1.1.- Entidad del negocio... 91 1.2.- Atributos y datos... 91 2.- Asociación de entidades...

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

PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES

PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES Raúl Palma G. y Guillermo Bustos R. Escuela de Ingeniería Industrial Universidad Católica de Valparaíso Casilla

Más detalles

Soporte y mantenimiento. Generalidades

Soporte y mantenimiento. Generalidades Soporte y mantenimiento Generalidades 2014 Tabla de Contenido 1 Introducción... 3 2 Objetivos generales... 3 3 Caso de soporte... 3 4 Condiciones... 4 5 Restricciones... 5 6 Sistema de soporte... 5 Página

Más detalles

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase,

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

Introducción. Componentes de un SI. Sistema de Información:

Introducción. Componentes de un SI. Sistema de Información: Introducción. Sistema de Información: Conjunto de elementos relacionados entre sí de acuerdo a ciertas reglas, que aporta a la organización la información necesaria para el cumplimiento de sus fines, para

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...

Más detalles

Gestión de la Configuración

Gestión de la Configuración Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de

Más detalles

DE VIDA PARA EL DESARROLLO DE SISTEMAS

DE VIDA PARA EL DESARROLLO DE SISTEMAS MÉTODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS 1. METODO DEL CICLO DE VIDA PARA EL DESARROLLO DE SISTEMAS CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS. El desarrollo de Sistemas, un proceso

Más detalles

Plan de estudios Maestría en Sistemas de Información y Tecnologías de Gestión de Datos

Plan de estudios Maestría en Sistemas de Información y Tecnologías de Gestión de Datos Plan de estudios Maestría en Sistemas de Información y Tecnologías de Gestión de Datos Antecedentes y Fundamentación Un Sistema de Información es un conjunto de componentes que interactúan entre sí, orientado

Más detalles

Patrones para persistencia (I) Ingeniería del Software II

Patrones para persistencia (I) Ingeniería del Software II Patrones para persistencia (I) Ingeniería del Software II 1 Patrones para la construcción del esquema relacional En todos los ejemplos realizaremos transformaciones del siguiente diagrama de clases: Figura

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

Este documento enumera los diferentes tipos de Diagramas Matriciales y su proceso de construcción. www.fundibeq.org

Este documento enumera los diferentes tipos de Diagramas Matriciales y su proceso de construcción. www.fundibeq.org DIAGRAMA MATRICIAL 1.- INTRODUCCIÓN Este documento enumera los diferentes tipos de Diagramas Matriciales y su proceso de construcción. Muestra su potencial, como herramienta indispensable para la planificación

Más detalles

K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2

K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 Historia de revisiones Fecha VersiónDescripción Autor 08/10/2009 1.0 Creación del documento.

Más detalles

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Sergio Valero Orea, svalero@utim.edu.mx, UTIM, Izúcar de Matamoros, Puebla. Resumen El desarrollo de sistemas

Más detalles

Base de datos relacional

Base de datos relacional Base de datos relacional Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar

Más detalles

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

forma de entrenar a la nuerona en su aprendizaje.

forma de entrenar a la nuerona en su aprendizaje. Sistemas expertos e Inteligencia Artificial,Guía5 1 Facultad : Ingeniería Escuela : Computación Asignatura: Sistemas expertos e Inteligencia Artificial Tema: SISTEMAS BASADOS EN CONOCIMIENTO. Objetivo

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. PROYECTO

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

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

CASO PRÁCTICO. ANÁLISIS DE DATOS EN TABLAS DINÁMICAS

CASO PRÁCTICO. ANÁLISIS DE DATOS EN TABLAS DINÁMICAS CASO PRÁCTICO. ANÁLISIS DE DATOS EN TABLAS DINÁMICAS Nuestra empresa es una pequeña editorial que maneja habitualmente su lista de ventas en una hoja de cálculo y desea poder realizar un análisis de sus

Más detalles

TECNÓLOGO EN INFORMÁTICA PLAN DE ESTUDIOS

TECNÓLOGO EN INFORMÁTICA PLAN DE ESTUDIOS Administración Nacional de Universidad de la República Educación Pública Facultad de Ingenieria CF Res..0.07 Consejo Directivo Central Consejo Directivo Central Res..05.07 Res. 17.0.07 TECNÓLOGO EN INFORMÁTICA

Más detalles

Indicadores del Sector Público. marzo de 2011

Indicadores del Sector Público. marzo de 2011 Indicadores del Sector Público marzo de 2011 Aspectos Conceptuales Un DATO es un valor puntual que expresa la situación de una variable en un momento específico del tiempo. Un dato aislado de su contexto

Más detalles

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008 Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento

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

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

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa

Más detalles

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

Más detalles

MINISTERIO DE EDUCACIÓN DIRECCIÓN DE EDUCACIÓN TÉCNICA Y PROFESIONAL PROGRAMA DE LA ASIGNATURA BASE DE DATOS ESPECIALIDAD INFORMÁTICA.

MINISTERIO DE EDUCACIÓN DIRECCIÓN DE EDUCACIÓN TÉCNICA Y PROFESIONAL PROGRAMA DE LA ASIGNATURA BASE DE DATOS ESPECIALIDAD INFORMÁTICA. MINISTERIO DE EDUCACIÓN DIRECCIÓN DE EDUCACIÓN TÉCNICA Y PROFESIONAL PROGRAMA DE LA ASIGNATURA BASE DE DATOS ESPECIALIDAD INFORMÁTICA. AUTORES: MSC. MIREYA LÓPEZ DELGADO LIC. ESPINOSA. CUIDAD HABANA PROGRAMA

Más detalles

Enginyeria del Software III

Enginyeria del Software III Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad

Más detalles

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de diseño en ingeniería El diseño de productos tecnológicos (artefactos, procesos, sistemas e infraestructura) está en el centro de la naturaleza

Más detalles

CURSO COORDINADOR INNOVADOR

CURSO COORDINADOR INNOVADOR CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto

Más detalles

REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS

REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS La gestión del asesor comercial se basa en mantener contacto personalizado con un grupo de clientes empresariales o personales.

Más detalles

Tecnologías de Información y Comunicación II CLASE 10

Tecnologías de Información y Comunicación II CLASE 10 Tecnologías de Información y Comunicación II CLASE 10 Medidas Una medida es un tipo de dato cuya información es usada por los analistas (usuarios) en sus consultas para medir la perfomance del comportamiento

Más detalles

DCU Diagramas de casos de uso

DCU Diagramas de casos de uso DCU Diagramas de casos de uso Universidad de Oviedo Departamento de Informática Contenidos Introducción Elementos básicos Más sobre los actores Más sobre los casos de uso Más sobre las asociaciones Otros

Más detalles

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...

Más detalles

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 9. Reglas de Integridad

FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA. Tema 9. Reglas de Integridad FICHEROS Y BASES DE DATOS (E44) 3º INGENIERÍA EN INFORMÁTICA Tema 9. Reglas de Integridad 1.- Introducción. 2.- Claves Primarias. 3.- Regla de Integridad de Entidades. 4.- Claves Ajenas. 5.- Regla de Integridad

Más detalles

Funciones, x, y, gráficos

Funciones, x, y, gráficos Funciones, x, y, gráficos Vamos a ver los siguientes temas: funciones, definición, dominio, codominio, imágenes, gráficos, y algo más. Recordemos el concepto de función: Una función es una relación entre

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

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

PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN

PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN PROPUESTA METODOLOGICA PARA LA EDUCCIÓN DE REQUISITOS EN PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN Paola Britos 1,2, Enrique Fernandez 1,2, Ramón García-Martinez 1,2 Centro de Ingeniería del Software e Ingeniería

Más detalles

<Generador de exámenes> Visión preliminar

<Generador de exámenes> Visión preliminar 1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,

Más detalles

BearSoft. SitodeCloud. Rafael Rios Bascón Web: http://www.bearsoft.com.bo Móvil: +591 77787631 Email: rafael.rios@bearsoft.com.bo

BearSoft. SitodeCloud. Rafael Rios Bascón Web: http://www.bearsoft.com.bo Móvil: +591 77787631 Email: rafael.rios@bearsoft.com.bo BearSoft Rafael Rios Bascón Web: http://www.bearsoft.com.bo Móvil: +591 77787631 Email: rafael.rios@bearsoft.com.bo CONTENIDO 1. Resumen. 3 2. Business Intelligence.. 4 3. Características del software.

Más detalles

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA BASE DE DATOS TEMA 3 MODELO ENTIDAD INTERRELACION Modelización Conceptual Modelo Entidad-Interrelación Elementos M.E.IR Caso de Estudio Tipos de

Más detalles

Sistemas de Gestión de Calidad. Control documental

Sistemas de Gestión de Calidad. Control documental 4 Sistemas de Gestión de Calidad. Control documental ÍNDICE: 4.1 Requisitos Generales 4.2 Requisitos de la documentación 4.2.1 Generalidades 4.2.2 Manual de la Calidad 4.2.3 Control de los documentos 4.2.4

Más detalles

Guía Metodológica para el diseño de procesos de negocio

Guía Metodológica para el diseño de procesos de negocio Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan

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

1.1 EL ESTUDIO TÉCNICO

1.1 EL ESTUDIO TÉCNICO 1.1 EL ESTUDIO TÉCNICO 1.1.1 Definición Un estudio técnico permite proponer y analizar las diferentes opciones tecnológicas para producir los bienes o servicios que se requieren, lo que además admite verificar

Más detalles

IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS

IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS CORPORACIÓN UNIVERSITARIA IBEROAMERICANA TECNOLOGIA EN LOGISTICA INFORMATICA BOGOTA D.C. 2013 INTRODUCCIÓN

Más detalles

Guía Práctica para el Uso del Servicio de Software Zoho CRM

Guía Práctica para el Uso del Servicio de Software Zoho CRM Guía Práctica para el Uso del Servicio de Software Zoho CRM Parte 4 Modificación de las Listas Estándar del Sistema Modificación del Menú Principal del Sistema Importación de información al Sistema Adición

Más detalles

PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores

PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores PERFIL DEL PUESTO POR COMPETENCIAS Sepa cómo construirlo y evitar bajos desempeños posteriores Martha Alicia Alles Es contadora pública nacional, doctora por la Universidad de Buenos Aires en la especialidad

Más detalles

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INDICE Introducción...2 Frontera de la aplicación...3 Cuenta de Puntos Función sin ajustar...3 Funciones de Datos...4 Funciones Transaccionales...4 Mecanismo...5

Más detalles

PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO

PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO PROYECTO GESTIÓN POR PROCESOS: INFORME DE AUTOEVALUACIÓN MEDIANTE CUESTIONARIO UNIDAD: TÉCNICOS DE LABORATORIOS DE DEPARTAMENTOS, CENTROS E INSTITUTOS DE INVESTIGACIÓN (UTLA). Fecha de realización: DICIEMBRE

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

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

Más detalles

Master en Gestion de la Calidad

Master en Gestion de la Calidad Master en Gestion de la Calidad 3. La Calidad en la Actualidad La calidad en la actualidad 1 / 9 OBJETIVOS Al finalizar esta unidad didáctica será capaz: Conocer la calidad en la actualidad. La familia

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

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

Tema 2: Modelo Entidad-Relación(ER)

Tema 2: Modelo Entidad-Relación(ER) ÒÓ Ô ºÙÒ ÓÚ º Tema 2: Modelo Entidad-Relación(ER) Fernando Cano Espinosa Universidad de Oviedo. Departamento de Informática 1 Contenido 1. Introducción al modelo de datos ER 2. Conjuntos de entidades y

Más detalles

ÍNDICE MANUAL OFERTA ACADÉMICA

ÍNDICE MANUAL OFERTA ACADÉMICA ÍNDICE MANUAL OFERTA ACADÉMICA I. CREACIÓN AÑO LECTIVO... 4 II. CREACIÓN PERÍODO ACADÉMICO... 6 III. IDENTIFICACIÓN DEL PLAN DE ESTUDIOS... 8 IV. ASIGNATURAS... 11 V. CREACIÓN DE SECCIONES... 12 VI. PRESTACIÓN

Más detalles

Soporte y mantenimiento. Generalidades

Soporte y mantenimiento. Generalidades Soporte y mantenimiento Generalidades Tabla de Contenido 1. Introducción 2. Objetivos generales 3. Caso de soporte 4. Condiciones 5. Restricciones 6. Sistema de soporte Soporte y mantenimiento 1. Introducción

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

SOROLLA2 GUÍA PRÁCTICA SIMPLIFICADA. Relaciones de transferencias. Marzo del 2014

SOROLLA2 GUÍA PRÁCTICA SIMPLIFICADA. Relaciones de transferencias. Marzo del 2014 DE PRESUPUESTOS SOROLLA2 GUÍA PRÁCTICA SIMPLIFICADA Relaciones de transferencias Marzo del 2014 1. DE PRESUPUESTOS Aunque la operativa es prácticamente idéntica, vamos a distinguir dos tipos entre las

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

Manual Operativo SICEWeb

Manual Operativo SICEWeb Manual Operativo SICEWeb Gestión de Expediente Digital Expediente Único de Clientes y Otros 1 Índice Contenido Expediente Único de Clientes y Otros... 1 Índice... 2 MODELO DE GESTIÓN DOCUMENTAL (MGD)...

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

CAPÍTULO 3 Servidor de Modelo de Usuario CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes

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

Base de Datos. Profesor: José Miguel Rubio L. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING.

Base de Datos. Profesor: José Miguel Rubio L. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING. P. UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA ESCUELA DE ING. INFORMÁTICA Base de Datos Usuario A Programa de Aplicación Bodega Usuario B Usuario N Insumo Proveedor Profesor: José Miguel

Más detalles

1.1. Introducción y conceptos básicos

1.1. Introducción y conceptos básicos Tema 1 Variables estadísticas Contenido 1.1. Introducción y conceptos básicos.................. 1 1.2. Tipos de variables estadísticas................... 2 1.3. Distribuciones de frecuencias....................

Más detalles

Sistema de Facturación de Ventas WhitePaper Enero de 2007

Sistema de Facturación de Ventas WhitePaper Enero de 2007 Sistema de Facturación de Ventas WhitePaper Enero de 2007 Ronda Guglielmo Marconi, 9 Parque Tecnológico 46980 Paterna Valencia Spain T +34 96 338 99 66 ventas@preference.es Please Recycle PrefSuite Document

Más detalles

La tutoría para la dirección de proyectos de investigación. Darder Mesquida, Antònia antonia.darder@uib.es. Universitat de les Illes Balears.

La tutoría para la dirección de proyectos de investigación. Darder Mesquida, Antònia antonia.darder@uib.es. Universitat de les Illes Balears. La tutoría para la dirección de proyectos de investigación. Resumen Darder Mesquida, Antònia antonia.darder@uib.es Universitat de les Illes Balears. Se presenta un modelo de tutoría docente para la dirección

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles