PEDECIBA Informtica

Instituto de Computacin Facultad de Ingeniera Universidad de la Repblica Montevideo, Uruguay

Reporte Tcnico RT 05-16

Procesos de desarrollo y metodologas para el diseo de Data Warehouses

Andrea Delgado

2005

Procesos de desarrollo y metodologas para el diseo de Data Warehouses Andrea Delgado ISSN 0797-6410 Reporte Tcnico RT 05-16 PEDECIBA Instituto de Computacin Facultad de Ingeniera Universidad de la Repblica Montevideo, Uruguay, 2005

Procesos de desarrollo y metodologas para el diseo de Data Warehouses

Andrea Delgado Universidad de la Repblica, Instituto de Computacin, Grupo de Ingeniera de Software, Montevideo, Uruguay adelgado@fing.edu.uy Octubre 2005 Resumen
La complejidad en el desarrollo de software de los sistemas actuales involucra diversos aspectos que van desde el rea de la aplicacin a desarrollar, las distintas tecnologas existentes a utilizar, as como el proceso de desarrollo y las metodologas a seguir. Desde el rea de la Ingeniera de Software se han propuesto varios modelos de procesos de desarrollo, desde el ms clsico enfoque de desarrollo en cascada, el desarrollo iterativo incremental como el definido en el Rational Unified Process (RUP) [1], y los nuevos enfoques de desarrollo gil representados principalmente por eXtreme Programming (XP) [2]. Un proceso de desarrollo define roles, actividades, productos de entrada y salida de las actividades, y etapas en las cuales se realizan las distintas actividades establecidas, para que las Organizaciones puedan obtener resultados de mayor calidad, medibles y repetibles, manteniendo los proyectos dentro de los costos y plazos previstos. Desde comienzos de los 90 el desarrollo de Data Warehouses ha cobrado importancia como una solucin al problema de satisfacer las necesidades de informacin gerenciales de las Organizaciones. A pesar de que su utilizacin se ha vuelto cada vez ms comn, y de los esfuerzos realizados en el estudio de tcnicas para el diseo de los mismos a partir de las bases de datos operacionales, no se han definido de la misma forma, procesos de desarrollo y metodologas a seguir por los proyectos que encaren el diseo de Data Warehouses en las Organizaciones. En este trabajo se presentan cuatro artculos seleccionados que proveen una visin del estado del arte en el rea de procesos de desarrollo y metodologas para el diseo de Data Warehouses. Dos artculos presentan enfoques de procesos de desarrollo, uno basado en el anlisis de requerimientos con Casos de Uso y el otro para el desarrollo de Data Warehouses evolutivos orientados al usuario. Los siguientes dos artculos presentan metodologas para el diseo de Data Warehouses, uno presenta un framework metodolgico considerado de los primeros enfoques que cubre completamente el proceso de diseo de Data Warehouses, y el otro muestra un enfoque para el diseo conceptual alineado con el proceso tradicional de diseo de bases de datos, teniendo en cuenta las necesidades especficas para los Data Warehouses.

Palabras clave: Ingeniera de Software, Bases de Datos, Data Warehouse, procesos de desarrollo, metodologas
de diseo, anlisis de requerimientos.

Introduccin

Este trabajo se realiza en el marco de la Maestra en Informtica del Programa de Ciencias Bsicas (PEDECIBA) de la Universidad de la Repblica Oriental del Uruguay (UDELAR). Corresponde al trabajo adicional del curso de Sistemas de Informacin Cooperativos y OLAP dictado por el Profesor Alberto Abell de la Universidad Politcnica de Catalua, en agosto de 2005, el cual se toma como curso de posgrado otorgando crditos para dicha maestra. El objetivo de este trabajo consiste en realizar un estudio del estado del arte en el rea de procesos de desarrollo y metodologas para el diseo de Data Warehouses, a travs de la presentacin de cuatro artculos seleccionados que muestran distintos enfoques del tema en este documento, que se encuentra organizado como sigue: En la seccin 2 se presentan dos artculos que tratan enfoques de procesos de desarrollo, uno basado en el anlisis de requerimientos con Casos de Uso y el otro para el desarrollo de Data Warehouses evolutivos orientados al usuario. En la seccin 3 se presentan dos artculos que tratan metodologas para el diseo de Data Warehouses, uno presenta un framework metodolgico considerado de los primeros enfoques que cubre completamente el proceso de diseo de Data Warehouses, y el otro muestra un enfoque para el diseo conceptual que puede embeberse en el proceso tradicional de diseo de bases de datos, teniendo en cuenta las necesidades especficas para los Data Warehouses. En la seccin 4 se presentan algunas conclusiones que se han obtenido en base al estudio realizado de los artculos presentados previamente. En la seccin 5 se listan las referencias a la bibliografa utilizada para la realizacin de este trabajo, y a la bibliografa ms importante referenciada en los artculos presentados.

Procesos para el diseo de Data Warehouses

En esta seccin se presentan dos artculos que tratan enfoques de procesos de desarrollo para el diseo de Data Warehouses, el primero basado en el anlisis de requerimientos con Casos de Uso [3] y el segundo para el desarrollo de Data Warehouses evolutivos orientados al usuario [4].

2.1 Anlisis de Requerimientos orientado a los procesos para el diseo de Data Warehouses, enfoque con Casos de Uso
En este artculo [3] se plantea la utilizacin de Casos de Uso como forma de mejorar la comunicacin entre los expertos del dominio, los especialistas en Data Warehouses, los diseadores de Data Warehouses y otros involucrados que tienen en general distintos enfoques. En un proyecto de desarrollo de este tipo, donde se cruzan varias unidades de la Organizacin, el relevamiento de requerimientos cobra mayor importancia, ya que definirlos en forma no ambigua, completa, verificable, consistente y usable puede convertirse en una tarea de gran dificultad. Se define un Data Warehouse como una fuente de datos consultable para propsitos de anlisis que soportan principalmente los procesos de decisin de la Organizacin. El modelado de los mismos es multidimensional almacenando datos histricos, limpios, validados, sintetizados, operativos, internos y externos. Los destinatarios de estos sistemas tienen un gran conocimiento de su negocio, el cual quieren explorar y analizar en base a los datos que presenta el Data Warehouse y su vista del negocio. Esta vista de anlisis del negocio puede ser bastante distinta de la vista global aunque el proceso bajo anlisis sea el mismo, por lo que se deben relevar los requerimientos especficos para los usuarios del Data Warehouse que corresponden a su vista de anlisis. El diseo del Data Warehouse es altamente dependiente de estos requerimientos y muchas veces cuando se construyen sin un correcto entendimiento de estas necesidades, fallan en sus objetivos. Un escenario comn es aquel en el cual los requerimientos son tomados de los usuarios por los analistas, quienes describen estos requerimientos y se los pasan al equipo de desarrollo que tiene poco o ningn conocimiento del negocio. Los desarrolladores encuentran esta descripcin demasiado vaga para realizar el diseo del Data Warehouse por lo que realizan su propia especificacin desde un punto de vista tcnico la cual luego se presenta a los usuarios para su aprobacin. Los usuarios detectan varios aspectos tcnicos que no entienden pero deben aprobarla para obtener el desarrollo del sistema que desean, sin embargo, posiblemente el sistema obtenido no sea luego lo que los usuarios esperaban, y por lo tanto no provean el efecto esperado en la Organizacin. Muchas veces en estos casos los distintos departamentos terminan haciendo sus propios Data Marts para realizar sus anlisis, lo cual no permite que se pueda realizar un anlisis global a nivel de la Organizacin.

En este contexto es que se busca modelar un sistema de Data Warehouse de forma que sea a la vez preciso y amigable al usuario. Para esto es importante que cada smbolo utilizado en el proceso de anlisis sea intuitivo para el usuario y tenga semntica definida claramente, para que los desarrolladores puedan utilizar esa descripcin como especificacin general pero precisa del Data Warehouse. Se plantea entonces que desde el punto de vista del modelado de Data Warehouse la utilizacin de Casos de Uso presenta dos ventajas principales, en primer lugar que al ser parte de UML son generalmente aceptados como notacin estndar en la comunidad del software, y en segundo lugar que pueden ser utilizados en un nivel general en el cual se omiten detalles de implementacin y sean adecuados para la comunicacin con el usuario. Por otro lado, el enfoque de procesos para el diseo de Data Warehouses permite que las Organizaciones se centren en la perfomance de los procesos del negocio como un todo y no nicamente en la medida de performance por tarea o departamento. Estos procesos del negocio en general cruzan los lmites organizacionales y tienden a ser ineficientes por el cambio de responsabilidades, grandes tiempos de demora, entre otros. Por lo que un diseo de Data Warehouses orientado a los procesos se enfoca en el proceso entero incluyendo todos los departamentos involucrados, soportando el desarrollo hacia una Organizacin centrada en procesos. El modelado que se presenta est basado en [5] en el entendido de que los modelos de Casos de Uso y de objetos que all se proponen, pueden ser utilizados para describir tanto procesos de software como procesos del negocio, que usan la misma notacin para representar distinta funcionalidad. Los Casos de Uso pueden utilizarse para describir el negocio desde un punto de vista externo proveyendo una visin del rea de inters, mientras que el modelo de objetos es un modelo interno que describe acertadamente cada proceso del negocio con sus tareas y recursos de forma de clarificar el modelo. La propuesta es una adaptacin de los modelos de Casos de Uso y de objetos para soportar el anlisis de requerimientos para un Data Warehouse, con el objetivo de proveer un mtodo de ingeniera de requerimientos formal que sea fcil de utilizar, rpido de entender, cubriendo la mayora de las caractersticas de modelado de un Data Warehouse y que sirva como vehculo de comunicacin entre todas las partes involucradas en el proceso de requerimientos. 2.1.1 Requerimientos y usuarios de un Data Warehouse

Los requerimientos para un Data Warehouse determinan que datos deben estar disponibles, como se organizan y que tan seguido deben ser actualizados. El proceso de relevamiento de requerimientos comienza con un descubrimiento del negocio a nivel macro en el cual se identifican los procesos clave del negocio, las mtricas claves del negocio, medidas y requerimientos. Con los requerimientos de los usuarios se realiza un documento de visin que describe las propiedades en alto nivel del sistema de Data Warehouse a desarrollar, las cuales expresan servicios que deben ser provistos para alcanzar los requerimientos de los usuarios. La relacin entre las propiedades de alto nivel y sus servicios para el usuario llevan a la derivacin de los requerimientos del Data Warehouse. Luego se realiza un descubrimiento del negocio a nivel micro en el cual se lleva a cabo un anlisis en profundidad de los requerimientos de la Organizacin segn lo definido en el paso anterior. En este se describen los requerimientos en mayor detalle considerndolos en el contexto de los modelos para los procesos del negocio y las estructuras de la Organizacin. A partir de los dos pasos realizados se obtiene una especificacin tcnica comprensible para el diseo del Data Warehouse, derivando estos requerimientos a partir de los requerimientos del negocio y traducindolos en forma tcnica para el equipo de desarrollo. El enfoque de Casos de Uso se utiliza principalmente para describir el comportamiento del sistema y los actores involucrados, pero para sistemas de Data Warehouse hay otros aspectos importantes a modelar como los datos y la informacin que sern almacenados, lo que se integra a la propuesta para obtener los requerimientos del negocio a partir de los usuarios correspondientes a los procesos del negocio. En este aspecto es importante considerar el contexto Organizacional de los usuarios, clasificndolos para proveer una visin comprensible de los futuros usuarios del Data Warehouse. Los distintos niveles en los cuales se encuentran estos usuarios en la jerarqua de la Organizacin determinan que se necesite informacin en distinto nivel de granularidad dependiendo de las necesidades especficas de stos. En una jerarqua tradicional con niveles administrativo, profesional, de gestin y ejecutivo, a medida que se va subiendo en los niveles de esta jerarqua, decrece el nivel de granularidad requerido para la informacin, ya que los ejecutivos utilizan informacin sumarizada de alto nivel, mientras a nivel de gestin se trabaja con nivel de informacin ms detallada. En el paso de descubrimiento del negocio a nivel micro se deben identificar los usuarios en todos los niveles de jerarqua que permita una combinacin de todos los requerimientos para modelar un sistema de soporte de decisiones a nivel de toda la Organizacin.

2.1.2

Modelo de Casos de Uso y Modelo de Objetos

El modelo de Casos de Uso propuesto describe los procesos del negocio en la Organizacin y provee informacin para los usuarios del Data Warehouse y para los integrantes de la misma, mostrando como los analistas del Data Warehouse lo utilizan, incluyendo los roles de los usuarios y los procesos del negocio que estn analizando, utilizando la siguiente notacin: Sistema y subsistemas de anlisis: es el concepto de modelado que simboliza el negocio o rea de responsabilidad que se est analizando. Analista: es el rol que alguien o algo en el ambiente realiza en relacin con el sistema de anlisis. Caso de Uso: representa el proceso del negocio que es analizado. Asociacin de uso: es una asociacin de debe y describe la agregacin de Casos de Uso en otro Caso de Uso. Este concepto se aplica cuando partes de un Caso de Uso son analizadas por otro analista. El modelo de objetos, por otro lado, muestra como est estructurado el Caso de Uso internamente para realizar las capacidades de anlisis del proceso planteado y describe los requerimientos de anlisis de varios actores sobre ste. Esta estructura interna se compone de hechos y objetos de dimensin. Los procesos del negocio tienen varias caractersticas comunes que son sus atributos los cuales reflejan la estructura de los procesos de negocio clsicos, al aplicar un enfoque orientado a objetos para el anlisis de estos procesos, es necesario identificar objetos en vez de atributos para los mismos. Los objetos en la definicin de los procesos remarcan las caractersticas claves de estos procesos, y a la vez representan las clsicas dimensiones de los Data Warehouses como ser Organizacin, cliente, producto, servicio, tiempo, entre otras, y por otro lado los hechos del Data Warehouse, esto es las medidas. Se propone un conjunto de objetos de dimensin representando las dimensiones del Data Warehouse como sigue: Objeto de Dimensin cliente: la perspectiva de un proceso en un negocio es la perspectiva del cliente, con el enfoque en procesos del negocio con cliente satisfecho como objetivo principal del proceso, se representa al mismo en este objeto. Objeto de Dimensin entregable: el cliente no tiene inters en la estructura organizacional de la Organizacin o su filosofa de gestin, el cliente solo ve los productos y servicios que ofrece la Organizacin los cuales son producidos a partir de sus procesos, y representados en este objeto. Objeto de Dimensin organizacin: los procesos del negocio tpicamente fluyen a travs de varias unidades de la Organizacin y cruzan diversas responsabilidades, por lo que el anlisis de la estructura de la Organizacin detecta ocurrencias en los procesos causadas por distintas unidades, las que se representan en este objeto. Objeto de Dimensin tiempo: un proceso del negocio es un orden de actividades a travs del tiempo con un principio y un fin, ste ltimo representando un punto en el tiempo donde los resultados del proceso son entregados y no pueden ser cambiados, lo que se representa en este objeto. Tambin se define el objeto Hecho que corresponde con los hechos en la terminologa de Data Warehouses y que representan las medidas como ganancia, porcentajes, entre otras. En general los procesos del negocio consisten de varios hechos que son creados a partir de diferentes dimensiones, por lo que se introduce una asociacin comunicacin que muestra la comunicacin entre el hecho y las dimensiones que lo crean. 2.1.3 Comentarios al artculo

De la propuesta presentada se pueden destacar principalmente dos aspectos: el enfoque de anlisis de procesos de la Organizacin y la utilizacin de Casos de Uso para el modelado de estos procesos y especificacin de los requerimientos de los usuarios y vehculo de comunicacin con ellos. El anlisis de los procesos de la Organizacin est cobrando importancia nuevamente en los enfoques de desarrollo propuestos en el rea de la Ingeniera de Software, como forma de describir lo que es importante para el negocio desde el punto de vista del negocio, con el resurgimiento del enfoque de Business Process Management (BPM) [6], herramientas que soportan la automatizacin de los mismos como por ejemplo sistemas de workflow, y enfoques de desarrollo orientado a servicios como Service Oriented Architecture (SOA) [7] que plantea entre otros, la identificacin de los servicios que brinda una Organizacin partiendo del estudio de los procesos del negocio que se realizan en sta.

En la metodologa de Casos de Uso propuesta por Jacobson inicialmente y que desde fines de los 90 integra el Rational Unified Model (RUP) los Casos de Uso modelan la utilizacin de un sistema de software por parte de los usuarios del mismo y la interaccin del mundo exterior con este, habiendose agregado posteriormente el rea de modelado del negocio que se realiza en forma previa a la especificacin de requerimientos, en la cual se utilizan Casos de Uso del Negocio para describir estos procesos donde se especifican los pasos que componen estos procesos, sin incluir en principio los aspectos de informatizacin de los mismos. En el contexto de este artculo la adaptacin realizada de los Casos de Uso para describir estos procesos es contempornea con la inclusin de este enfoque en el proceso unificado, por lo que a mi entender se podran ver como Casos de Uso del Negocio los que se plantean en el enfoque. Estos dos aspectos mejoran sensiblemente el proceso de relevamiento de requerimientos en la mayora de los proyectos, brindando una visin acertada del negocio en el que se inscribe el desarrollo propuesto, as como de las necesidades de los usuarios, y la obtencin de acuerdos con estos mediante la validacin de los Casos de Uso que expresan en forma clara una realidad que ellos conocen y que es la de su negocio y la forma en que ste funciona, teniendo en cuenta tambin el lugar que los usuarios ocupan en la Organizacin y por lo tanto el nivel de informacin que necesitan para realizar el anlisis de los procesos planteados. Sin embargo la propuesta no entra en detalles del diseo del Data Warehouse que clarifique el uso del modelo de objetos planteado, que puede parecer en principio insuficiente para guiar este diseo en forma acertada, lo que sera la parte ms dbil del artculo. Los autores reconocen este hecho cuando establecen como trabajo a futuro la mejora de los modelos planteados para que soporten en forma ms adecuada el proceso de diseo de Data Warehouses, lo que debera incluir mayor detalle y gua en la utilizacin de los objetos de hecho y dimensin definidos y su utilizacin concreta en el diseo del esquema de Data Warehouse y pasos posteriores como diseo lgico y fsico del mismo.

2.2 Modelo procedural para el desarrollo de Data Warehouses evolutivos y orientados al usuario
El artculo [4] presenta su propuesta partiendo de la base que los sistemas de software estn sujetos a una evolucin en todas las fases de su ciclo de desarrollo ya que se encuentran embebidos en ambientes sociales que cambian. En la fase de desarrollo se debe considerar como los modelos procedurales reaccionan ante los cambios, dinmica y flexibilidad del campo de accin de que trata el desarrollo. Los modelos lineales y de fases como el modelo en cascada se han probado como no adecuados para soportar estas circunstancias, y se han propuesto modelos alternativos que intentan superar la debilidad de los anteriores como los orientados a prototipos, incrementales, iterativos y evolutivos, que van cobrando cada vez mayor importancia. En el rea del desarrollo de Data Warehouses el uso de procesos iterativos incrementales es poco comn, incluso el soporte explcito para un proceso basado en prototipos tambin es limitado. En reportes prcticos se describe frecuentemente el xito del uso de mtodos con prototipos e incrementales, sin embargo la transferencia de los resultados de casos individuales parece posible solo en forma limitada. Los requerimientos para un Data Warehouse se encuentran en el rea de conflicto entre los requisitos econmico-tcnicos por un lado y los de integracin tcnica por el otro, siendo un desafo central que datos ofrecer entre la vista de orientacin a datos del Data Warehouse y la vista de orientacin a la informacin de los OLAP. En principio las posibilidades que existen son comenzar por los datos disponibles como punto de partida, lo que sera un enfoque bottom-up, o proceder en forma top-down partiendo de las necesidades de informacin existentes. Al proceder con enfoque top-down el anlisis de las necesidades de informacin es el problema central, existiendo varios obstculos que se describen en [8] como obstculos que se pueden categorizar como de los usuarios individuales, entre los usuarios, y de los usuarios individuales a los responsables del desarrollo del sistema. Muchas veces los usuarios recin podrn tener claros sus requerimientos en el transcurso del desarrollo, debido tambin a los cambios en el ambiente operacional y sus datos. Para proyectos donde los requerimientos sean inestables, inciertos e incompletos es recomendable la utilizacin de un procedimiento orientado a la prototipacin, donde los prototipos ejecutables ilustran ciertos aspectos del sistema que sern realizados mientras otros no se tienen en cuenta en ese momento. Los prototipos se presentan a los usuarios y sirven para verificar las propiedades deseadas del sistema mejorando la comunicacin con stos y hacindola ms eficiente, con lo cual los problemas en el anlisis de las necesidades de informacin pueden ser sorteados o por lo menos debilitados. Para realizar un prototipo se deben tomar decisiones sobre que aspectos incluir en el mismo y que aspectos no incluir, esas decisiones pueden ser tomadas luego de definir los objetivos para el prototipo. Si el prototipo sirve para ilustrar la adecuacin de un sistema de Data Warehouse y para la recoleccin y anlisis de las necesidades de informacin que involucra, entonces las preguntas sobre el frontend para los usuarios y los reportes y estructuras de

navegacin sern el centro de atencin. Si por el contrario se quiere investigar la factibilidad tcnica del sistema de Data Warehouse entonces el nfasis estar dado en los procesos de ETL. El desarrollo de un sistema de Data Warehouse para una Organizacin representa una tarea compleja, de larga duracin y costo de implementacin, por lo que muchas veces se comienza con el desarrollo de distintos Data Marts para las reas funcionales, que luego son integrados en forma incremental. La utilizacin de procesos incrementales no significa cuan frecuentemente se cree que no se terminar con el desarrollo, sino que se trabaja siguiendo una orientacin hacia un objetivo firme, que es alcanzado mediante la extensin gradual de primeras soluciones parciales, lo que permite manejar en forma flexible la dinmica de cambios del ambiente en el que se inserta el desarrollo, eliminando en forma temprana malentendidos y verificando donde la informacin provista corresponde a la necesidad de informacin planteada por los usuarios. Ambos mtodos, el prototipado y el incremental, se ven como facetas del principio de evolucin total. 2.2.1 Desmantelamiento del sistema total como condicin

En el proceso que se presenta se realiza un desmantelamiento del sistema de Data Warehouse para obtener por un lado los objetos de informacin y decisin necesarios, y los niveles de arquitectura por el otro. Los objetos de informacin y decisin representan los artculos relevantes desde la vista econmica que pueden ser derivados del sistema objetivo, definiendo en un nivel abstracto los tpicos para las tablas del Data Warehouse, que combinado con los niveles de arquitectura del Data Warehouse dan lugar a los objetos de desarrollo, que representan los mdulos del sistema global. En el contexto de la planificacin de los prototipos as como de las etapas de desarrollo del proceso incremental, estos objetos de desarrollo representan los artefactos de decisin, esto es, especificar que objetos y en que orden sern realizados para obtener el sistema de Data Warehouse. Los prototipos sirven para la discusin as como para la determinacin y concretizacin de las necesidades de informacin, comenzando con aquellos que se encuentran en el nivel de presentacin de la capa de OLAP y simulando los niveles por debajo, en particular sin modelar ni implementar ningn proceso de ETL ya que stos llevan cerca del 80% del tiempo de desarrollo segn las experiencias medidas. Este procedimiento incremental sigue el principio de Think globally, act locally que se recomienda en [9] para la introduccin de una arquitectura de Data Warehouse comprensible. La conexin entre la informacin individual y los objetos de decisin es de dimensin, similar a la propuesta en [10] para la integracin de Data Marts. 2.2.2 Modelo procedural iterativo para el desarrollo de Data Warehouses

El proceso plantea el desarrollo incremental en distintas liberaciones (builds), definiendo fases e iteraciones, que se planifican en base a estas liberaciones, como sigue: Fase 1: inicializacin La fase de inicializacin es el preludio para la realizacin de los objetos de desarrollo en el contexto del desarrollo incremental del Data Warehouse, en la cual se definen cuales son los objetos a realizar en el contexto del anlisis del desmantelamiento total del sistema, y la definicin de la secuencia de liberaciones que ser realizada. Fase 2: adquisicin de conocimiento, recoleccin de demandas de usuarios La segunda fase del modelo procedural representa la entrada al ciclo de determinacin y formulacin de las necesidades de informacin existentes, la cual se realiza tanto con usuarios individuales como con grupos de usuarios. Se debe determinar por un lado que hechos y nmeros caractersticos y que objetos de informacin y decisin pueden ser cuantificados, y por el otro lado la determinacin de las dimensiones y la jerarqua de dimensiones definidas por los usuarios, creando vistas cualitativas en las medidas. En esta fase se pueden utilizar distintas tcnicas como las w-questions en las que las preguntas estn orientadas a which, when, who, where, with ... tambin es posible utilizar notaciones grficas utilizando un modelo conceptual simplificado que utiliza solo un subconjunto de elementos de modelado utilizados en modelos conceptuales multidimensionales, lo que lleva a un mejor entendimiento y permite concentrarse en aspectos generales. El resultado de la fase de adquisicin de conocimiento representa la informacin de los usuarios individuales y de los grupos de usuarios, en documentos de modelos conceptuales as como de interrogatorios a los usuarios, los que son la entrada de la fase siguiente. La separacin de vistas de personas y multi-personas permite la ubicacin de las especificaciones que conciernen a los distintos usuarios siguiendo el principio de separacin de intereses, y el de trazabilidad de los requerimientos hacia su fuente, es decir a que usuario corresponden. Tambin se puede realizar

un glosario conceptual donde se indique en lenguaje natural la descripcin de la terminologa utilizada en el mundo de discurso y el modelo. Fase 3: Concepcin En esta fase se unifican los artefactos obtenidos en la fase anterior, y se realiza la transicin a la vista de multipersona. Desde el punto de vista de esta fase, los resultados de la adquisicin de conocimiento representan descripciones parciales e incompletas del sistema de Data Warehouse. Para esta fase se utilizan lenguajes de modelado correctos como DFM, ME/R, entre otros, ya que no sern utilizados para comunicacin con los usuarios sino que sta se har a travs de la validacin de prototipos. Durante la unificacin de las descripciones parciales e incompletas de la fase anterior es posible que se tengan que dar pasos hacia atrs a esa fase si las definiciones o dimensiones y sus jerarquas tienen desviaciones. El prototipo de validacin se provee mediante la transformacin del modelo conceptual en un patrn lgico para el nivel de OLAP como el patrn estrella, el copo de nieve, etc., pero preguntas que cobran importancia a nivel de modelado lgico como la normalizacin, particin y materializacin de vistas de los cubos no se tienen en cuenta a esta altura ya que no interesan para la validacin del prototipo, que representa un primer ejecutable del sistema que incluye caractersticas importantes del sistema final que pueden ser realizadas. Fase 4: validacin La validacin tanto del modelo de la fase de concepcin como del prototipo se realiza en un nico paso. Los usuarios del sistema pueden validar a travs del prototipo si los requerimientos relevados se convierten de acuerdo al mundo de discurso en nmeros caractersticos y dimensiones adecuadas. Si el prototipo es validado en forma parcial o no es validado en absoluto, se debe dar un paso hacia atrs a las fases anteriores. Para determinar a que fase se debe volver es necesario verificar con los usuarios los artefactos obtenidos en dichas fases para ir determinando los acuerdos sobre los mismos. Si el prototipo es aceptado entonces se sigue en el modelo hacia la siguiente fase de especificacin. Fase 5: especificacin En esta fase la especificacin final de los requerimientos del usuario tiene lugar en la forma de los modelos conceptual y lgico, asumiendo que la validacin del prototipo por parte de los usuarios significa que los modelos muestran los requerimientos de los usuarios en forma apropiada. Se definen las estructuras finales de las tablas incluyendo normalizacin, particiny fragmentacin. Adems de los modelos conceptual y lgico se modelan los procesos de ETL para definir que administradores del sistema y bases de datos realizarn la transferencia de datos de las fuentes operacionales de datos. 2.2.3 Comentarios al artculo

Del enfoque presentado en este artculo se puede destacar la utilizacin de un proceso de desarrollo iterativo incremental con prototipacin, y la orientacin al usuario del relevamiento de requerimientos y validacin de los mismos. Un proceso de desarrollo iterativo incremental es en general adecuado cuando los requerimientos que se tienen son cambiantes o no estn definidos completamente desde el inicio del desarrollo, por lo que cada vez que se obtiene una liberacin correspondiente a una iteracin en las fases definidas, es posible incluir requerimientos en las siguientes iteraciones que an no estuvieran del todo claros o que el usuario plantee cambiar, permitiendo evaluar el impacto de su inclusin o modificacin en el desarrollo en base a lo obtenido y definido y lo que es posible acomodar y de que forma, para definir y planificar el resto del desarrollo. En general es de esperar que los requerimientos ms importantes para el usuario estarn bien definidos desde el inicio del desarrollo y durante el mismo los cambios en los requerimientos no sern de tal magnitud que afecten negativamente lo realizado hasta ese momento. Asimismo la prototipacin como forma de realizar los acuerdos con el usuario sobre los aspectos ms importantes del sistema en desarrollo permite por un lado, mejorar la comunicacin con los usuarios que pueden ver en funcionamiento parte de lo que esperan del sistema, y por otro la deteccin temprana de malentendidos sobre los requerimientos, lo que permite la correccin de los mismos y la definicin del desarrollo sobre una base ms firme que el usuario va acordando con el equipo de desarrollo. En conjunto con el nfasis que pone el enfoque en el relevamiento de requerimientos y la identificacin de usuarios y grupos de usuarios para los mismos clarificando el uso del sistema, se permite que el proyecto vaya avanzando en la direccin correcta hacia la obtencin del sistema que el usuario desea, segn las definiciones y las validaciones de los avances que se van haciendo con stos.

La aplicacin al desarrollo de Data Warehouse de estos principios parece apropiada en el sentido planteado de que muchas veces en este tipo de desarrollo ocurre que los usuarios van redescubriendo los requerimientos a medida que van comprendiendo las posibilidades de anlisis que les brinda el sistema, facilitando la inclusin de los mismos en etapas posteriores del desarrollo. Asimismo se destaca la inclusin en las fases definidas de las actividades a realizar, sus participantes, entradas y salidas. Sin embargo en el enfoque no se plantea de que forma se realiza el diseo del Data Warehouse por parte del equipo de desarrollo, sino que se deja abierto a la utilizacin de las metodologas y enfoques que se desee utilizar, basandose si en determinacin de varios de estos aspectos en conjunto con los usuarios, teniendo en cuenta que el resultado de este modelado ser validado por los usuarios a partir de los prototipos presentados donde se podrn ver y discutir la definicin de hechos, dimensiones y jerarquas para las dimensiones, segn los requerimientos y definiciones realizadas.

Metodologas para el diseo de Data Warehouses

En esta seccin se presentan dos artculos que presentan metodologas para el diseo de Data Warehouses, el primero plantea un framework metodolgico considerado de los primeros enfoques en cubrir el proceso completo de diseo de Data Warehouses [11] y el segundo un enfoque para el diseo conceptual que puede ser embebido en el proceso de diseo de bases de datos tradicional [12].

3.1 Framework metodolgico para el diseo de Data Warehouses

Este artculo [11] presenta un framework metodolgico para el diseo de Data Warehouses basado en el modelo conceptual de Data Warehouses desarrollado por los autores, Dimensional Fact Model (DFM). La metodologa propuesta consta de seis fases para las cuales se presentan sus actividades, entradas, salidas y roles participantes, comenzando con el anlisis de los sistemas de informacin existentes y relevando los requerimientos de los usuarios, se realiza luego el diseo conceptual en forma semi-automtica a partir del esquema de bases de datos operacional, continuando con una evaluacin de los volmenes de datos y las consultas a realizar, que ser la entrada para realizar finalmente el diseo lgico y fsico que dar lugar al esquema final para el Data Warehouse. 3.1.1 Modelo Dimensional de Hechos (DFM)

El Modelo Dimensional de Hechos (DFM) es un esquema dimensional que consiste en un conjunto de esquemas de hechos cuyos elementos bsicos son hechos, dimensiones y jerarquas. A continuacin se presentan informalmente las principales definiciones del DFM en las que se apoya la metodologa que se presenta, por un mayor detalle y formalizacin de las mismas consultar [11]. Un esquema de hechos es una sxtupla f=(M,A,N,R,O,S) donde: - M es un conjunto de medidas, cada medida est definida como una expresin numrica o booleana que involucra valores adquiridos del sistema de informacin. - A es un conjunto de atributos de dimensin, cada atributo de dimensin est caracterizado por un dominio discreto de valores. - N es un conjunto de atributos no dimensionales - R es un conjunto de duplas ordenadas, con la forma (a,b) donde a pertenece a A unin a0 siendo a0 un atributo dummy que juega el papel del hecho en el cual el esquema est centrado, y b pertenece a A U N para los a distintos de b. Cada dupla modela una relacin de uno a uno entre los atributos dimensionales y no dimensionales. Un patrn de dimensin es el conjunto de los elementos de A tal que estn en una dupla en R, y cada elemento del patrn de dimensin es una dimensin. Una jerarqua en una dimensin del conjunto es el quasi-rbol bajo esa dimensin. - O C R es un conjunto de relaciones opcionales - S es un conjunto de sentencias de agregacin, cada una consistiendo en una tripla (m,d,op) donde m pertenece a M, d pertenece al patrn de dimensiones, y op. es un operador de agregacin que indica que la medida m puede ser agregada en la dimensin d segn ese operador. Si no existe ninguna sentencia de agregacin para un par (m,d) significa que m no puede ser agregada en d. Se define tambin una notacin grfica para los esquemas de hechos que permiten la comprensin de los esquemas realizados segn las definiciones provistas en forma amigable e intuitiva, que no se reproduce en este documento en el entendido de que es conocida en general ya que est presente en gran parte de la literatura de Data Warehouse existente, remitiendo al lector interesado a [11].

Cada n-upla de valores en un esquema de un hecho tomados de los dominios de sus n dimensiones define una celda elemental donde una unidad de informacin del DW puede ser representada, las unidades de informacin presentes en el DW son llamadas instancias de hechos primarios y se caracterizan por exactamente un valor para cada medida. Muchas veces el anlisis a ese nivel de detalle es abrumador por lo que puede resultar til agregar instancias de hechos primarios segn niveles de abstraccin que se corresponden con patrones de agregacin definidos. Estos patrones de agregacin declaran como las instancias de hechos primarios deben ser agregadas, si una dimensin no es interesante para el anlisis que se est realizando, la agregacin se realiza sobre todos los posibles valores que puede tomar dicha dimensin. Las instancias de hechos secundarios se obtienen al agregar hechos primarios segn el patrn de agregacin definido y se caracterizan por tener exactamente un valor para cada medida legal segn el patrn de agregacin, el cual se calcula aplicando el operador de agregacin a los valores que la medida asume en las instancias de hechos primarios que se agregan. Como distintos hechos se representan en distintos esquemas de hechos, y parte de las consultas que los usuarios formulan en el Data Warehouse requieren comparar medidas tomadas de esquemas de hechos distintos pero relacionados, se define tambin la combinacin de esquemas de hechos que permite realizar drill-across entre estos. Para eso se definen esquemas de hechos compatibles que son aquellos que comparten por lo menos un atributo de dimensin, que se define como comn a ambos esquemas si tiene la misma semntica en ambos y la interseccin de sus dominios de valores no es vaca. Para que dos esquemas de hechos sean estrictamente compatibles la contraccin de sus quasi-rboles debe ser igual, siendo esta contraccin el quasi-rbol que se obtiene a partir de un subconjunto de vrtices del quasi-rbol original que incluye los vrtices definidos y los caminos directos del rbol original que conectan los vrtices definidos sin incluir otros vrtices de ese conjunto. De esta forma se pueden solapar dos esquemas de hechos que son estrictamente compatibles para crear un nuevo esquema de hechos, ya que las dependencias entre los atributos no conflictan y es posible entonces comparar medidas de los dos esquemas. 3.1.2 Fases en la metodologa de diseo propuesta

El enfoque propuesto se compone de seis fases que se realizan secuencialmente, en forma semejante a las utilizadas en el diseo tradicional de Bases de Datos, y que se describen a continuacin: Anlisis del sistema de informacin En esta fase el objetivo primario es recolectar la documentacin que concierne al sistema de informacin operacional pre-existente, lo que involucra al diseador en colaboracin con los responsables de la gestin del sistema y si es posible con los diseadores del mismo. La salida de esta fase es el esquema conceptual o lgico del sistema o parte del mismo. Especificacin de requerimientos Esta fase consiste en recolectar y filtrar los requerimientos de los usuarios, involucrando al diseador y a los usuarios finales del Data Warehouse, y produciendo como salida la especificacin que indica la eleccin de hechos por un lado e indicaciones preliminares sobre la carga de trabajo del Data Warehouse por el otro. La eleccin de hechos para el Data Warehouse se basa en la documentacin del sistema de informacin producido en el paso anterior. Estos hechos son conceptos de principal inters para el proceso de toma de decisiones, y tpicamente corresponden a eventos que ocurren dinmicamente en el mundo de la Organizacin, en un esquema E/R puede estar representado por una entidad o una relacin n-aria, y en un esquema relacional corresponden a esquemas de relacin. En general las entidades o esquemas de relacin que representan archivos actualizados frecuentemente son buenos candidatos para la definicin de hechos, mientras aquellos que representan propiedades estructurales del dominio y corresponden a archivos ms estticos no lo son. La especificacin preliminar sobre la carga de trabajo del Data Warehouse expresar en lenguaje natural para cada hecho las medidas y agregaciones ms interesantes, de forma de permitir identificar las dimensiones y medidas en la fase de diseo conceptual. Diseo Conceptual Esta fase se realiza a partir de los esquemas del sistema de informacin obtenidos y considerando los hechos y especificacin de trabajo de carga preliminar definidas en las fases anteriores, y tiene como resultado un esquema dimensional que se estructura de acuerdo al DFM y que consiste en un conjunto de esquemas de hechos, uno por cada hecho identificado. La tcnica para producir el modelado conceptual se puede realizar en forma semiautomtica siguiendo los pasos que se indican para producir cada esquema de hechos: construir el rbol de atributos, depurar el rbol de atributos, definir las dimensiones, definir las medidas, definir las jerarquas, estos ltimos tres pasos son soportados por la especificacin preliminar de carga declarada por los usuarios finales. En esta etapa se utiliza el DFM que fue descrito previamente, para obtener el conjunto de esquemas de hechos con sus dimensiones,

atributos de dimensiones y jerarquas, as como esquemas solapados que permitan el dril-across entre los distintos esquemas de hechos definidos. Refinamiento de la carga de trabajo y validacin del esquema El objetivo principal de esta fase es refinar la carga de trabajo preliminar reformulndolo con mayor detalle en el esquema dimensional, definiendo un lenguaje de consultas para el DFM, y considerando la computacin de los volmenes de datos a manejar. En esta fase tambin se realiza una validacin del esquema conceptual producido en la fase anterior, ya que la carga de trabajo de las consultas puede ser expresada exhaustiva y correctamente solo si las dimensiones y medidas fueron identificadas apropiadamente, y las jerarquas estn bien estructuradas. En el framework propuesto una consulta tpica puede ser representada por el conjunto de instancias de hechos, a cualquier nivel de agregacin, cuyos valores de medida deben ser recuperados. Se definen para el lenguaje propuesto las expresiones de instancia de hecho, donde la clusula de seleccin contiene un conjunto de predicados booleanos que pueden o bien seleccionar un subconjunto de instancias de hecho agregadas o afectar la forma en que son agregadas las instancias de hecho, involucrando las dimensiones y atributos de dimensiones en la jerarqua de la dimensin. Tambin se definen consultas de drill-across en esquemas que se solapan. La carga de trabajo en un esquema dimensional se define como el conjunto de pares (q,v) donde q denota una consulta y v denota la frecuencia esperada para la consulta. El volumen de datos se computa para cada esquema de hechos considerando la dispersin de los hechos y la cardinalidad de los atributos de las dimensiones, en base a la definicin de varias frmulas que permiten estimar el nmero tanto de instancias de hechos primarios como secundarios. Diseo lgico Como entrada para esta fase se cuenta con el esquema dimensional, la carga de trabajo y un conjunto de informacin adicional como la frecuencia de actualizacin, el espacio de disco total disponible, etc, para producir un esquema del Data Warehouse que minimice los tiempos de respuesta a las consultas respetando las restricciones de espacio en disco. Las consultas de actualizacin deben considerarse aparte de la carga de trabajo, ya que la actualizacin del Data Warehouse se realiza peridicamente de forma off-line por lo que durante el proceso el Data Warehouse no est disponible para su uso, con lo que el proceso de actualizacin no afecta directamente la performance del Data Warehouse y es suficiente asegurar que est acotado en el tiempo. Se debe seleccionar el modelo lgico a utilizar ya sea relacional o multidimensional, donde este ltimo puede ser mapeado al primero adoptando el conocido esquema de estrella, y dependiendo de la cardinalidad de los dominios utilizar copo de nieve para una o ms dimensiones. La adopcin de un modelo simplistico puede causar graves errores mientras que la adopcin del ms exacto puede hacer que el diseo se vuelva demasiado complejo. En esta fase se realizan en forma secuencial los pasos de materializacin de vistas, traduccin a tablas, particin vertical de tablas de hechos y particin horizontal de tablas de hechos. Para reducir el tiempo de respuesta global comnmente se utiliza la tcnica de pre-computar o consolidar la informacin que puede ser til para responder consultas frecuentes. Las tablas de hechos que tienen datos consolidados de otras tablas de hechos se llaman generalmente vistas, y si bien reducen el tiempo de respuesta de un conjunto de consultas, tambin traen costos adicionales de actualizacin y ocupan ms espacio en disco. Por ejemplo consolidar algunas vistas sobre las cuales se realice frecuentemente drill-across en una nica tabla de hechos puede reducir el costo de acceso considerablemente. El modelo de costos adoptado en este paso se basa en el nmero de accesos lgicos que se realizan sobre las tablas de hechos y dimensiones para resolver las consultas, sin tener en cuenta la tcnica de acceso adoptada para su resolucin, por ej. ndices vs. escaneo secuencial. En la fase de traduccin a tablas se crean tablas para los hechos y las dimensiones a partir del esquema dimensional y de acuerdo al esquema lgico adoptado. En el caso ms simple del esquema clsico en estrella, cada hecho se traduce en una tabla de hecho con clave primaria compuesta por claves forneas a todas las dimensiones del hecho y campos las medidas correspondientes, y n tablas de dimensiones con clave primaria para cada dimensin y campos los atributos de dimensin y los atributos no dimensionales que correspondan. Luego la particin de tablas vertical y horizontal se utiliza para optimizar las consultas que requieren subconjuntos de las tablas definidas. En el caso de la particin vertical se particionan las tablas de hechos en n tablas de hechos que tienen todas la misma definicin de clave primaria y cada una tiene solo un campo de medida para ese hecho, la funcin de costos que se utiliza tiene en cuenta la reduccin de costos en el acceso a tuplas ms cortas as como el overhead en el acceso a mltiples tablas. En la particin horizontal se considera la selectividad de cada consulta, dado que no todas las tuplas en la tabla de hechos se acceden cada vez sino que solo un subconjunto determinado por un predicado que involucra uno o ms atributos de seleccin. Cada tabla de hecho se particiona en un conjunto de tablas que tienen el mismo esquema de relacin que la original en las que se distribuyen las tuplas segn un

conjunto ptimo de atributos de dimensin, la funcin de costos que se utiliza tiene en cuenta la reduccin de costos al acceder a tablas ms pequeas.

Diseo fsico El principal tema en el diseo fsico implica la seleccin ptima de ndices a definir, la cual se basa en el esquema lgico y en la carga de trabajo, y requiere tener en cuenta las estructuras de acceso especficas utilizadas por el DBMS. La seleccin de ndices tiene un rol fundamental en la determinacin de la performance del Data Warehouse, adems de los ndices tradicionales de lista de valores como rboles B, tambin se utilizan ndices de bitmap, de join y de proyeccin. Se debe determinar el mejor subconjunto de ndices para la carga de trabajo considerada, y para cada tipo de ndice la funcin de costos apropiada. El mejor subconjunto es aquel que minimiza los costos de acceso para las consultas en la carga de trabajo bajo las restricciones de espacio que varan de aplicacin en aplicacin. Tambin se deben considerar los algoritmos de join dado que las consultas en Data Warehouse generalmente involucran uno o ms joins. 3.1.3 Comentarios al artculo

Este artculo presenta una propuesta completa para el proceso de desarrollo de un Data Warehouse, incluyendo una metodologa para el diseo y especificacin del esquema del Data Warehouse en base a un modelo formal desarrollado por los autores que es el Modelo Dimensional de Hechos (DFM - Dimensional Fact Model), lo que provee un marco definido, claro y formal para la obtencin de Data Warehouses que cumplan con propiedades de calidad importantes desde el punto de vista del modelado del mismo. En el DFM se definen los esquemas de hechos que incluyen para cada hecho sus dimensiones asociadas, jerarquas de dimensiones y restricciones de sumarizabilidad, lo cual se define a partir de la especificacin de requerimientos realizada. Se presenta tambin la forma de realizar drill-across entre los distintos esquemas de hechos definidos, definiendo esquemas solapados que se obtienen a partir de esquemas con dimensiones en comn que es posible integrar en un nuevo esquema. Se provee un lenguaje de consultas para especificar las mismas sobre el DFM y realizar un refinamiento de la carga de trabajo definida y validacin del esquema obtenido para el Data Warehouse, indicando pasos para realizar el modelado lgico inlcuyendo como realizar el pasaje a tablas, materializacin de vistas, particin vertical y horizontal de tablas, y el fsico para la definicin de ndices, entre otros. Si bien se plantea el involucramiento de los usuarios en la etapa de obtencin de los requerimientos para el Data Warehouse, as como en la definicin de hechos y carga de trabajo para las distintas consultas a realizar sobre el sistema, no se hace nfasis en la comunicacin con los usuarios finales, basando el desarrollo principalmente en los esquemas de las bases de datos operacionales utilizando elementos de modelado ms tcnicos como estos esquemas, que muchas veces pueden dificultar el entendimiento con los mismos. Se destaca tambin la inclusin en las fases definidas de las actividades a realizar, sus participantes, entradas y salidas. Sin embargo el enfoque de desarrollo es basicamente secuencial como el enfoque tradicional de diseo de bases de datos, lo que muchas veces puede traer tambin dificultades si las definiciones realizadas se apartan de los requerimientos de los usuarios si hay malentendidos o agregados a los requerimientos planteados durante el desarrollo del sistema. En la literatura de Data Warehouse a la que se tuvo acceso durante el estudio realizado se pudo observar que este artculo y el trabajo de sus autores se encuentra referenciado en varios otros artculos del tema, siendo destacado en algunos casos como el primer enfoque metodolgico completo para el diseo de Data Warehouses y por lo tanto es valorado como de gran importancia en el rea. 3.2 Diseo conceptual de Data Warehouses En este artculo [12] se presenta un mtodo para el diseo conceptual de Data Warehouses que est alineado con el diseo tradicional de bases de datos, y encaja en un modelo de proceso que sigue enfoques clsicos. Los mtodos tradicionales de diseo de bases de datos estructuran el proceso de diseo en una secuencia de fases o pasos, comenzando por el anlisis y especificacin de requerimientos, se realiza luego el diseo conceptual, luego el diseo lgico y finalmente el diseo fsico, los cuales pueden ser refinados de distintas formas. Como parte central del proceso de diseo se establece un esquema conceptual para la base de datos que luego es transformado en el lenguaje del modelo lgico como la base para la correspondiente implementacin fsica. En la teora de bases de datos hay aspectos claves que se tienen en cuenta como ser la teora de dependencias funcionales que formaliza las

formas normales y la normalizacin como forma de prevenir redundancias, con la existencia de algoritmos para la construccin de esquemas normalizados. En la teora de Data Warehouses por el contrario, en el modelado comnmente aceptado en forma de estrella se tiene una tabla central de hechos que tiene los hechos de inters para una aplicacin OLAP y que est conectada a un nmero de tablas de dimensiones a travs de restricciones de integridad referencial basadas en las claves de las tablas de dimensiones, y como stas pueden estar compuestas de jerarquas de atributos, en general estn desnormalizadas, y cuya normalizacin da lugar al esquema de copo de nieve. Sin embargo no se cuenta en general con guas para el diseo de buenos esquemas o restricciones de integridad en el contexto de modelos multidimensionales. En el proceso de diseo que se presenta se plantea un proceso orientado a fases que es modelado siguiendo el proceso tradicional de diseo de bases de datos, y que muestra como obtener el esquema de Data Warehouse a partir del esquema de la base de datos operacional, especificando en la fase de diseo conceptual que dimensiones, jerarquas de dimensiones y medidas existirn y que atributos de la base de datos operacional pertenece a donde. Se recalca tambin la nocin de forma normal multidimensional (MNF) especificada en [13] como forma de describir buenos esquemas de Data Warehouses y como derivarlo a partir del esquema operacional. 3.2.1 Enfoque para el diseo de Data Warehouses

El modelo de proceso propuesto se compone de cuatro fases secuenciales siguiendo el proceso de diseo clsico de bases de datos, que se realizan como se describe a continuacin: Anlisis y especificacin de requerimientos En el esquema E/R operacional se tiene informacin bsica para determinar el potencial del anlisis multidimensional, asumiendo que se cuenta con dicho esquema y sino, es posible obtenerlo aplicando ingeniera reversa. En esta fase los expertos del dominio del negocio seleccionan los atributos de la base de datos operacional que son relevantes estratgicamente y especifican el propsito de usarlos como dimensiones y/o medidas. Para cada atributo se decide si pueden contener datos opcionales o no, y tambin se agregan requerimientos complementarios en la forma de medidas complejas derivadas. La especificacin de requerimientos resultante contiene una lista tabular de los atributos junto con su propsito multidimensional, pudindose anexar un apndice que contenga informacin suplementaria informal como restricciones de integridad del negocio relevantes, y consultas estratgicas. Diseo conceptual La fase de diseo conceptual realiza una transformacin de la especificacin de requerimientos del negocio semiformal en un esquema conceptual multidimensional formal. La formalizacin resulta en un diagrama multidimensional grfico que contiene el esquema de hechos con sus medidas relacionadas y jerarquas de dimensiones. Para cada medida del esquema de hechos se formalizan las restricciones de sumarizabilidad en un apndice tabular. Diseo lgico En esta fase se convierte el esquema conceptual en un esquema lgico con respecto al modelo lgico objetivo mayormente relacional o multidimensional. El esquema lgico se genera de acuerdo a reglas de transformacin que refieren solamente a los diagramas conceptuales y las restricciones de sumarizabilidad. Diseo fsico El proceso termina el la implementacin fsica del esquema lgico con respecto a las propiedades del sistema de base de datos objetivo, incluyendo tcnicas de optimizacin fsica como estrategias de indizacin, particiones, etc. as como ajustes especficos de OLAP como desnormalizacin relacional de las tablas de dimensiones, preagregaciones o uso especial de ndices bitmap. 3.2.2 Forma normal multidimensional (MNF)

A continuacin se presenta la terminologa y conceptos definidos en [LAW98] para la forma normal multidimensional (MNF). En [13] se distingue entre DFs dbiles que definen funciones parciales y no dbiles que definen funciones totales, mientras que en la propuesta se utiliza en forma equivalente la distincin entre atributos opcionales y mandatorios. Se define un esquema dimensional como un conjunto de atributos dimensionales D donde para cada di perteneciente a D hay un dj perteneciente a D tal que se tiene una Dependencia Funcional (DF) di dj o dj di. Un esquema multidimensional es un par M = ({D1, ..., Dk},S) donde {D1, ..., Dk} es conjunto de esquemas dimensionales y S es una medida determinada funcionalmente por los atributos que ocurren en {D1, ..., Dk}. Un atributo dimensional dt

perteneciente a D es terminal si no existe d en D tal que d dt. Un atributo dimensional d perteneciente a D es un atributo de categora si d es mandatorio y hay un d perteneciente a D tal que d d o d es mandatorio y d d, todos los dems atributos son de propiedad o atributos. Sea dt un atributo terminal, dp un atributo de propiedad y dc un atributo de categora de una dimensin comn, un elemento c de dc es un contexto de validez de dp si se cumplen: para cada elemento de dt que pertenece a c hay un valor para dp y para cada elemento de dt que no pertenece a c no hay valor para dp. Un esquema dimensional D est en forma normal dimensional si se cumplen: hay exactamente un atributo terminal dt perteneciente a D; los elementos de dt son completos, esto es todos los conceptos del mundo real estn capturados; y todos los atributos dimensionales son mandatorios. Un esquema multidimensional M est en forma normal multidimensional generalizada (GMNF) si se cumplen: para cada atributo de propiedad dp perteneciente a Di hay un elemento de un atributo de categora dc perteneciente a Di que denota el contexto de validez de dp; cada esquema dimensional restringido a los atributos de categora est en forma normal dimensional; las dimensiones son ortogonales entre si, esto es no existen DFs entre atributos de esquemas de dimensiones distintas; la medida S est determinada funcionalmente por el conjunto de atributos terminales de las dimensiones. El enfoque presentado se relaciona con los conceptos definidos en [13] mediante los lemas y teoremas que se muestran a continuacin: Lema: 1 cada jerarqua de dimensin determinada durante el diseo conceptual es un esquema dimensional que tiene como raz exactamente un atributo terminal. 2 las dimensiones son ortogonales entre si 3 en dimensiones sin jerarquas opcionales todos los niveles de dimensin son mandatorios 4 si una dimensin contiene una jerarqua opcional entonces los elementos del nivel de join representan el contexto de validez para los atributos de propiedad. 5 todas las medidas estn determinadas funcionalmente por completo por el conjunto de niveles terminales de las dimensiones. Teorema 1: El diseo conceptual que se presenta en el enfoque produce un esquema de hechos que est en forma normal multidimensional generalizada. Teorema 2: Un esquema de hechos se encuentra en forma normal multidimensional generalizada si se cumplen: 1 para cada nivel de dimensin opcional dl en la dimensin d hay un elemento de mayor nivel que es mandatorio dc que denota el contexto de validez de dl. 2 cada esquema dimensional restringido a atributos mandatorios est en forma normal dimensional. 3 las dimensiones son ortogonales entre si 4 todas las medidas estn determinadas funcionalmente por completo por el conjunto de niveles terminales de las dimensiones. La forma normal multidimensional generalizada puede verse como un factor de calidad que previene las anomalas de agregacin en forma similar a la prevencin de anomalas de actualizacin de las formas normales tradicionales de bases de datos operacionales, y por lo tanto es de gran importancia para garantizar los resultados correctos de las consultas. 3.2.3 Modelado conceptual de Data Warehouses

El modelado conceptual de Data Warehouses que se propone se realiza en la fase de diseo conceptual y toma como entrada el esquema E/R de la base operacional, la tabla con la informacin sobre los atributos identificados y su uso como dimensin o medida y opcionalidad o no del mismo, y las consultas multidimensionales estndar definidas en lenguaje natural como cuantas cuentas corrientes se manejan on-line. Esta fase se divide a su vez en tres pasos que se realizan en forma secuencial: definicin contextual de medidas, diseo de jerarquas dimensionales y definicin de restricciones de sumarizabilidad, como se describe a continuacin, para la obtencin de esquemas de hechos en forma normal multidimensional generalizada segn lo visto en la seccin anterior. Definicin contextual de medidas Dado el conjunto de medidas M definidas en el anlisis de requerimientos y el conjunto D de atributos dimensionales, cada hecho se puede percibir como un elemento del grafo de alguno funcin desde los niveles de las dimensiones a las medidas. Por lo tanto, el diseo conceptual comienza determinando las Dependencias Funcionales

(DF) desde las dimensiones a las medidas. Primero se determina una clave mnima d incluida en D para cada medida m perteneciente a M, definiendo a continuacin el conjunto F de claves que consiste en todas las DFs de la forma dm obtenidas. Dada una DF del conjunto F, los niveles de dimensin en D determinan funcionalmente la medida m, y no son funcionalmente determinados por ningn otro nivel, por lo que califican como races para la jerarqua de la dimensin. Para cada nivel terminal de dimensin se define la correspondiente dimensin. Todas las medidas con conjuntos de dimensiones iguales se agrupan en el mismo esquema de hecho ya que comparten el mismo contexto dimensional. Se obtiene entonces el diseo conceptual grfico modelando el esquema de hechos hasta el nivel terminal de dimensin. Diseo de jerarquas dimensionales En este paso se desarrollan en forma gradual las jerarquas para cada dimensin, determinando todas las DFs entre los distintos niveles de dimensin de cada dimensin, con nivel terminal de dimensin d. A partir de cada nivel terminal se determinan las DFs para la dimensin, lo que lleva a la definicin de la jerarqua para la misma. En un primer paso se deben distinguir los atributos de los niveles de dimensin segn lo definido en el anlisis de requerimientos, recordando que los atributos solo pueden ser utilizados para seleccin y no para agregacin. En un segundo paso se obtiene una aproximacin a la jerarqua de la dimensin construyendo el grafo dirigido cuyos nodos son los niveles de la dimensin, y cuyos arcos estn definidos entre nodos si di es distinto de dj y existe una DF no transitiva de di a dj. El grafo obtenido se aumenta con los atributos que se adjuntan a un nivel de dimensin si la DF del nivel de dimensin al atributo es no transitiva, y se indica si puede ser o no opcional. Finalmente las jerarquas mltiples de dimensin se chequean para ver si contienen grupos opcionales de caminos de agregacin o no. Si todos los niveles de dimensin son mandatorios segn la especificacin de requerimientos entonces todos los grupos de caminos de agregacin son alternativos. Si algn nivel de dimensin es opcional entonces esos niveles introducen grupos de caminos opcionales de agregacin. Se tendr un nivel de split a partir del cual se llega a los niveles opcionales que deben ser agrupados, y luego se tendr un nivel de join para los niveles opcionales cuyos elementos indiquen para cada elemento del nivel de split a cual nivel opcional del grupo corresponde. Definicin de restricciones de sumarizabilidad No todas las agregaciones de medidas en determinado escenario de aplicacin tienen sentido, por ejemplo determinar el promedio de edades de los clientes puede tener sentido, pero sumar las edades de los clientes no lo tenga en absoluto. Por lo tanto, un modelo conceptual debe determinar como distinguir las agregaciones de medidas que tienen sentido de aquellas que no, para que esta informacin ayude a los analistas en la realizacin de sus consultas. En particular, el esquema de Data Warehouse debe expresar explcitamente que medida puede ser agregada en que jerarqua de dimensin de acuerdo a determinada funcin de agregacin. Como la inclusin de dichas restricciones en el esquema grfico reducen la claridad del mismo, se propone el agregado de apndices de sumarizabilidad donde se indica para cada par (m,d) de medida m y nivel de dimensin d en que nivel de restriccin de sumarizabilidad se encuentra, segn la siguiente clasificacin: nivel 1 indica que todas las funciones de agregacin pueden aplicarse al roll-up m del nivel de dimensin d a todos los niveles funcionalmente dependientes sobre l, nivel 2 indica que se pueden aplicar todas las funciones de agregacin menos la suma, el nivel 3 representa la mayor limitacin donde todava se puede realizar agregacin pero solo en trminos de la funcin de conteo, y el nivel 4 establece que no es posible realizar ningn tipo de agregacin. 3.2.4 Comentarios al artculo

Este artculo presenta una metodologa para el diseo de Data Warehouses que se inscribe en un proceso de desarrollo que sigue el enfoque tradicional de diseo de bases de datos, y que especifica los pasos necesarios para la obtencin de un esquema de Data Warehouse que se encuentra en forma normal multidimensional (MNF Multidimensional Normal Form) que mejoran la calidad del esquema as como lo hacen las formas normales definidas para las Bases de Datos tradicionales. Se plantea el involucramiento de los usuarios conjuntamente con expertos en el dominio para la generacin de una lista de atributos del Data Warehouse especificando su calidad de dimensin o medida y su opcionalidad, la cual luego se utiliza para derivar los hechos, dimensiones, jerarquas de dimensiones y restricciones de sumarizabilidad, conjuntamente con el estudio de las Dependencias Funcionales entre estos atributos, y la metodologa para asegurar la obtencin del esquema de Data Warehouse en MNF. Se destaca tambin la inclusin en las fases definidas de las actividades a realizar, sus participantes, entradas y salidas. Sin embargo, igual que en el artculo presentado en [18] el cual se referencia en ste, el enfoque de desarrollo es basicamente secuencial como el enfoque tradicional de diseo de bases de datos, lo que puede traer dificultades segn el entendimiento con los usuarios, aunque en este enfoque se tiene en cuenta la participacin de los mismos en las definiciones, lo que se entiende que tiene el objetivo de minimizar este riesgo.

No se incluye detalle para las fases de modelado lgico y fsico, por ejemplo no se indica como realizar la traduccin del esquema definido a tablas, sino que se nombran las actividades que se deben realizar en forma genrica como ser la definicin de ndices, por lo que en estas etapas el enfoque queda abierto a la eleccin de tcnicas que se quiera realizar.

Conclusiones

En este trabajo se presentaron y comentaron cuatro artculos que proveen una visin del estado del arte en el rea de procesos de desarrollo y metodologas para el diseo de Data Warehouses. En los artculos que se enfocan ms hacia la definicin de procesos de desarrollo, se hacen planteos interesantes que conjuntan enfoques ampliamente utilizados en la Ingeniera de Software para las distintas etapas del desarrollo de aplicaciones, con el desarrollo especfico de sistemas de Data Warehouses y sus requerimientos asociados. En estos enfoques, aspectos como el anlisis de requerimientos con Casos de Uso y orientado a procesos, el desarrollo iterativo incremental con prototipacin, se plantean como enfoques vlidos tambin para el desarrollo de Data Warehouse presentando las ventajas que puede tener su inclusin en proyectos de este tipo. En los artculos cuyo principal enfoque est en las metodologas de diseo de Data Warehouse en cuanto a la obtencin y especificacin de esquemas de Data Warehouse que cumplan con propiedades de calidad importantes para los mismos, se enmarcan estas metodologas en el proceso tradicional de diseo de Bases de Datos y se proveen modelos formales y marcos de trabajo apropiados para el diseo de los mismos. En lo que respecta a los objetivos de investigacin de este trabajo, se encuentra que todos los artculos realizan aportes importantes en las distintas reas que involucra un proyecto de Data Warehouse, notandose como aspecto a recalcar adems de la diversidad de enfoques y propuestas que existen, lo que indica la preocupacin en la comunidad acadmica por del estudio del tema, la importante retroalimentacin existente entre el rea de Ingeniera de Software y el rea de Bases de Datos. Resulta interesante la posibilidad de definir un proceso de desarrollo para el diseo de Data Warehouses que incluya los aspectos ms destacados de los cuatro artculos presentados, que podran ser la definicin de un proceso iterativo incremental con prototipacin, utilizando Casos de Uso y orientacin a procesos para el relevamiento de requerimientos, para el diseo conceptual se podra ver la compatibilidad de las metodologas planteadas de forma de obtener un esquema de Data Warehouse en MNF especificado en DFM y poder utilizar el potencial del DFM para las fases de diseo lgico y fsico, as como el lenguaje de consultas sobre el DFM para validar la carga de trabajo especificada y el modelo definido.

Referencias

[1] IBM Rational Unified Process (RUP), <http://www-130.ibm.com/developerworks/rational/products/rup> [Consulta: 10 de junio de 2005] [2] Beck, Kent. Extreme Programming Explained: Embrace Change, Addison Wesley, 1999. ISBN 201-61641-6 [3] List B., Schiefer J., Tjoa A.M., "Process-Oriented Requirement Analysis Supporting the Data Warehouse Design Process, a Use Case Driven Approach", en 11th International Conference on Database and Expert Systems Applications (DEXA00), 2000, London, England, ISBN 3-540-67978-2 [4] Goeken M., Burmester L., "Procedural model for evolutionary and user-oriented Data Warehouse development", en 4th International Conference on Electronic Business (ICEB04) - Shaping Business Strategy in a Networked World, 2004, Beijing, China, ISBN 7-5062-7342-X [5] Jacobson I., Ericson M., Jacobson A., "The Object Advantage - Business Process Reengineering with Object Technology", ACM Press, Addison-Wesley Publishing, 1994, ISBN 0-20-142289-1 [6] Business Process Management Initiative, <http://www.bpmi.org/> [Consulta: diciembre de 2005] [7] Krafzig, D. Banke, K. Slama, D. Enterprise SOA, Service Oriented Architecture Best Practices Prentice Hall, 2005, ISBN 0-13-146575-9 [8] Valusek J.R., Fryback D.G., "Information requirement determination: obstacles within, among and between participants", en 21st annual conference on Computer personnel research, 1985, Minneapolis, Minnesota, United States, ISBN 0-89791-156-3 [9] Hackney D., "Architectures and Approaches for Succesful Data Warehouses", <http://datawarehouse.ittoolbox.com/documents/document.asp?i=815> [Consulta: diciembre de 2005] 1998,

[10] Kimball R., Ross M., The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Wiley, 2002, ISBN 0-47-120024-7

[11] Golfarelli M., Rizzi S., "A Methodological Framework for Data Warehouse Design", en 1st International Workshop on Data Warehousing and OLAP (DOLAP98), 1998, Bethesda, Maryland, USA. [12] Husemann B., Lechtenborger J., Vossen G., "Conceptual Data Warehouse Design", en 2nd International Workshop on Design and Management of Data Warehouses (DMDW'00), 2000, Stockholm, Sweden. [13] Lehner W., Albrecht J., Wedekind H., Normal forms for multidimensional Databases, en 9th International Conference on Scientific and Statistical Database Management (SSDBM97), 1997, Washington, U.S.A.