EL desarrolLo de uvzALmace.nde Datos (Data Warehouse) se ha convertido en unfactor Crin.code exfropara machos compan"-i"aDse. sa caLidadpaede depender La supervz-vencia de la compan.-iaen an mercado coda vez mas competz.lino.Por tanto, no es rezonabLe manejar el proceso .de construcci6n juera deL marco de trabajo de ana metodoLogia. Desgraciadamente, ext.sten pocas metodologias completes para el disen-o de almacenes de datos. En este trabajo se presenta MIDEA, ana metodoLogia basada en an modeLo conceptual muLtidimensionaL.La metodoLogz~autilz"za como marco de referencia Laversion 3 de la MetodoLogla PAbLz`cEaspahola de PLaniflcaci6ny Desarrollo de Sistemas de Informaci6n (METRICA). Porte de La metodoLogz~east& soportada por ana herramienta CASE (IDEA-DWCASE), de La que Se dispone de an primer prototipo. Ofreceremos ana vision general tanto de La metodoLogzacomo deLmodeLo conceptual, y profandz"zaremosa, modo de ejempLo, en Una de Las actividades qae La componen: el modelado conceptual.
La necesidad de poder disponer de una forma rzipiday sencilla de toda la informaci6n hist6rica presenteen los sistemas operacionalesy su uso para la toma de decisiones ha empujadoa las empresas y a la comunidadcientifica a buscarnuevas formas de estructuraci6n y acceso a estos datos de forrna eficiente para,de esta forma, conseguir una ventaja con Sus competidores.Existe un acuerdoen que los sistemas tradicionales de bases de datos no resultan adecuados para realizar consultas analiticas sobre ellos desde una perspectiva multidimensional, que es la forma en la que los analistas de negocio ven los dams de la organizaci6n. Los sistemas OLTP (On-Lz"ne transactional processing) tradicionales estdn optimizados para proporcionar un elevado rendimientoen el procesamientode un gran ndmero de transacciones concurrentes, que habitualmente afectan a un reducido numerode registros,mientras que IDS sistemas multidimensionales ban de responder a consultas complejas Ca veces impredecibles) que acceden a una enorme cantidad de re__oistr[o1s].
Una posible soluci6n consiste en la implantaci6n de un 51.sternsde almacn de datos, que proporciona un repositorio de inforrnaci6n procedente fundarnentalmente de sistemas operacionales (OLTP) que proporciona los datos para el procesamiento analftico y la toma de decisiones. Contiene datos refxnados, hist6ricos, resumidos y no voltiles, y son bases de datos fundamentalmente de s6lo lectura, es decir, las actualizaciones se Bevan a cabo espo icamente, de forma controlada y masiva, y habitualmente fuerade los horarios de trabajo.
tecnologia se refleja en el hecho de que el crecirnientode las ventas y estx~macionersealizadas entre 1998 y 2002 es superioral 20% annal [14].
OLAF (On-line Analytical Processing) como herramientasfrontales para el acceso a los datos.
variaciones sobre los bdsicos, podemos hablar fundamentalmente de dos tipos de arquitecturas [151: la arquitecturaROLAP (Relational OLAP), y la arqul"tecturMa OLAP(MaLtidimensionaLOLAP).
almacenan en tablas relacionales organizadasen un esqaema en estreLla [7] o a15curidae Sus natl.antes, ofreciendo de esta forma una interfaz multidimensional a las tablas relacionales. Un esquemaen estrella consiste en una tablacentral de hechoSde grantamafioy varias tablasde dimensi6n a su alrededor cuyas claves primarias son claves ajenasen la tabla de hechos. Las medidas de inter6s para el proceso analitico se almacenanen las tablas de hecho, mientras que por cada dimensi6n (Tiempo, Geografia, etc.) existira Una tabla de dimensi6n, que contenc[rd todos los niveles de agregaci6n (en el esquema en copo de nieve, o versi6n normalizada del esquema en estrella, cada nivel de agregaci6n formardsu propiatabla).
En Una arquitecturaMOLA?, sin embargo, los datos se almacenan directamente en estructuras multidimensionales, proporcionando por tanto directamente una visi6n multidimensional, sin ningdn artificio similar aI caso relacional. El rendimiento de este tipo de sistemas suele ser superior al caso relacional pero, probablemente debido a la poca madurez de este tipo de sistemas, todavfa no son capaces de almacenar la gram cantidadde informaci6n que soportan los sistemas relacionales y por ello en ocasiones Se utilizan como almacenes de datos departamentales(data marts) que pueden alimentarse de un almacn de datos corporativorelacional.
Los entomos OLTP y OLAF son
profundamentediferentes, y las t6cnicas utilizadas
para el diseiio de bases de datos operacionalesson
inapropiadaspara el diseho de almacenes de datos
[7], [8}~El proceso de desarrollarun almacn de
datos es, como cualquier tarea Queimplique alg6n
tipo de integraci6n de recursos preexistentes (en
este caso, datos procedentes fundamentalmentede
sistemas heredados), sumamente complejo, y
exigira "an gran eacrzo sajeto a errores,
generalmente jiastrante, y qae LLevaa que machos
proyectos se abandonen antes de sa terminaci6n "
[
A este respecto, en los dltimos ahOsha habido bastantes propuestas restringidas a algunos de los aspectosparticulatesdel disefio de los almacenesde datos, sin embargo, `.aunqae Se han desarrollado muchassolaciones para sabproblemas interesantes, como el manejo de datos maLtidimensionales, mantenimiento de vistas para datos agregados, integraci6n de datos, etc., la combinaci6n de estas solaciones parciales y a menado muy abstractas en ana metodologla completa de diseho y ana estrategia de warehoasing todavia se deja en monos de Losdesarrolladores" {4].
trabajosrelacionados. En el apartado3 ofrecemos
A pesar de la evidente importancia que tiene
disponer de un soporte metodol6gico para el
desarrollo de un sistema OLAF de calidad, el
proceso de disebo hastaahora ha recibido may poca
atenci6n por parte de la comunidad cientifica y de
los proveedores de productos~ Los modelos
habitualmenteutilizados para el discho de bases de
datos operacionales, como el modelo EiR, no
deberian utilizarse sin rods para el discfio de
entomos analiticos. Atendiendo a motivos
puramentet6cnicos, las bases de datos obtenidas
como resultado del modelado con esta teenica son
inapropiadaspara sistemas de soporte a la decisi6n
en los que es importante la eficiencia en las
consultas y en la carga de los datos (incluyendo las
cargas incrementales)[
En los tiltimos ados ban aparecido diferentes propuestas metodol6gicas para el desarrollo de almacenes de datos.For ejemplo, en [8] los autores plantean una aproximaci6n basada en dos panics: por Unaparte,la Arquitecturaen Bus del Almac6n de Datos (Data Warehouse Bus Architectare), Que mostrardc6mo construiruna sucesi6n de almacenes de datos departamentales Que, finalmente, permitirlincrearun almac6nde dates corporativoy, por otra, la aproximaci6n basada en el Ciclo de Vida Dimensional del Negocio (Busbess Dimensional Lecycle BDL approach), que tiene como objetivos la construcci6n, a partir de los requisitos del negocio, de almacenes de datos departamentales basados en modelos dimensionales en estrella. Es Una metodologia muy detallada y, segdn los propios autores, ampliamente probada. Sin embargo, esta excesivamente centrada en el rnodeJo reJacionaJ ya desde las fases iniciales deJ modelado dimensional,
En [1], los autores presentan tanto un modelo l6gico para el disefio de bases de datos multidimensionales (Ilamado MD) como una metodologia de disefio para obtener un esquema MD a partly de bases de datos operacionales. Para elfo utilizan como punto de partida un esquema E/R que describe una vista integrada de las bases de datos operacionales, que contendrd toda la informaci6n disponible para nuestro almacgn de datos, aunque en an formato no adecuado a este tipo de sistema~ La metodologia consta, por una parte, de una serie de pasos para la construcci6n del esquema en el modelo MD, y por otra de una transforrnaci6n tanto al modelo relacional como a matrices multidimensionales. La metodologia es adn incomplete y pane de Una situaci6n ideal, suponiendo que toda la informaci6n estard incluida en el esquema E/R. Sin embargo, los esquemas operacionales deberian ser simplemente un apoyo, dando una mayor importancia a los requisitos de los usuarios analiticos.
En [6) se esboza un marco metodol6gico para el disefio de almacenes de datos basado en el modelo conceptuaJ de Jos mismos auto/es, JJamado Dimensional Fact Model (DFM). La metodologia adrl Se encuentra incompleta, y de momento Se centra dnicamente en la implementaci6n relacional.
Existen muchas otras propuestas parciales, centradas en aspectos may particulates como transformaci6n entre modelos, materizalizaci6n de vistas, indices, etc. Por ejemplo, en [J2] Se propone utilizer t6cnicas de data mining en las fases de dise6o del almac6n de datos (aJgoritmos de data mining para descubrir informaci6n implfcita en los datos, para la resoluci6n de conflictos de la integraci6n de esquemas para la compleci6n de valores perdidos y la correcci6n de ruido en los datos y datos incorrectos, etc.)"
Como resumen. podemos decir que aunque existe un acuerdo en cuanto a la necesidad de metodologias y herramientas para el desarrolfo de aJmacenes de datos de calidad, todavia no existe ninguna undnimemente aceptada- En el presente articulo present&mos MIDEA, una metodologia de desarrollo de almacenes de datos. La metodologia utiliza en su fase de andlisis un modelo conceptual multidimensionalde datos, denominadoIDEA que permite modelar esquemas conceptuales multidimensionales
Segdn (17), la caJidadtotal de los sistemas de informaci6nes un concepto multidimensional, que englobaa Jassiguientes dimensiones (figura J): . Calidad de las infraestructuras, que engloba al hardwarey el software que lo soporta (por ejemplo, rodes, software de sistema, etc") . Calidad del software, es decir, la calidad de las aplicaciones construidas, mantenidas o soportadas For el departamentode Sistemas de Informaci6n. Calidad de IDS datos de entrada a los distintos sistemas de informaci6n. . Calidad de la inforrnaci6n, es decir, la calidad de las salidas resultantes de los sistemas de inforrnaci6n.En ocasiones, Ja salida de un sistema se convierte en entradade otro, por lo que la calidad de la informaci6n estd relacionada con la calidad de los datos, . Calidad administrativa,es decir, la calidad de la gesti6n en la funci6n del departamentode Sistemas de Informaci6n. * Calidad de los servicios, que incluye la calidad de los procesos de soporte aI cliente, tales como los relativos a los .help desk'.
La metodofogfa de desarrollo que presentamos en el presente articulo tendn-a como objetivo fundamentalconseguir la calidad de la informaci6n analitica suministradaa los usuarios que toman las decisiones en la empresa aunque, evidentemente, tambien influirden (y se nerd inffuida por) el resto de las dimensiones que engloban la calidad, taJ como se muestraen la figura I . Cdidad dc los Sistemas de kLforz:I:laci6o
Figura 1. Dimensiones de la cal\dad
del marco del proyecto EINSTEIN. EINSTEIN es un proyecto de Investigaci6n y desarrollo Que aplica la experiencia y el conocimiento obtenido en el desarrollo de sistemas de bases de datos TelaCiOnalesen la ultima d6cada (SQL, modelado E/R, herramientas CASE, metodologfas, ...) al disefio de bases de datos multidimensionales (BDMDs).
desarrollo de BDMD (Bases de Datos
que Se ban utilizado en el desarrollo de sistemas de bases de datos relacionales. La metodologia utiliza como rnodelo conceptual en su lase de andlisis un modelo conceptual multidimensional denominado
proyecto EINSTEIN [II). Ademds, parte de esta metodologia estd soportada por una herramienta CASE (IDEA-DWCASE) que incorpora una interfaz grdfica [IO]. Esta herramientapermite la transformaci6nde un esquema conceptualIDEA en un esquema l6gico basado en el modelo soportado por algunos productos multidimensionales o relacionales. La figura 2 muestra Una neatens del prototipo de la herrarnienta,cuya notaci6n grdflea
Figura 2. Prototipo IDEA-DWCASE principal de IDEA es el Esquerna de Hecho, y es el modelo de datos relacionaly al de tipo de entidad descripci6n de un espacio n-dimensional Que contiene informaci6n relevante para su procesamiento analitico. Todo Esquema de Hecho consta de un conjunto de dimensiones, Una estructurade celda, y puede, o no, tener definido an predicado,de tal forma Quelos datos contenidos en la extensi6n del EH Sean dnicamente aquellos Que cumplan el predicado. Cada dimensi6n esni asociada a un atributo de dimensi6n, el cual. en caso de Queaqu6Ilaest6asociada a una subjerarqufa de atributos, ser su rafz" For otra parte, la estructura de celda consta de una estructura de subcelda (Quecontiene un atributode sintesis y un conjunto de funciones de sintesis definidas sobre eSte) y puede tener an conjunto de m6todos, Que son procedimientos aplicados sobre una o ms estructurasde subceldas.
de la metodologfa y profundizaremos, a modo de ejemplo, en una de Sus actividades.
IDEA Se utiliza para comprendery representer los requisitos de los usuarios analiticos de una forma similar a como el mOdelo de datos E/E se utiliza para interactuarcon los usuarios de los microdatos.Los esquemas de datos elementales de 105 sistemas OLTf] existentes y los requisitos obtenidos de los usueriosde datos analfticos son las entradas principales en la construcci6n de los esquemas conceptuales multidimensionales en
El siguiente paso consiste en transformar, utilizando un conjunto de reglas metodol6gicas, cada esquema conceptual definido previamente en un esquema l6gico en el modelo de cada producto concreto, el cuaf puede ser un sistema de gesti6n de bases de datos multidimensional puro o un sistema relacional con caracterisdcas multidimensionales (star joins, Indices bitmap, ...). Es necesario destacar Que el procedimiento habitual en los proyectos actuales es transformer directamente los esquemas relacionales en esquemas multidimensionales soportados directamente por herramientas OLAF.
La aproximaci6n del proyecto EINSTEIN perrnite la ingenieria inners& de esquemas multidimensionales especfficos existences en esquemas conceptuales IDEA. Estos podrdn comprobarse con los requisitos de los usuarios OLAF para verificar Que el alrnac6n de datos actual IDS satisface.
De igual modo, al contrario de la mayoria de las aproxirnaciones actuales, es posible crear y/o verificar esquemas E/R conceptuales elementales utilizando un conjunto de reglas contenidas en la metodologi.a para satisfacer los requisitos de los usuarios analfticos. Creemos Que esta`aproximaci6n no ha sido tratada en suficiente profundidad en los trabajos previos, en IDS Que norrnalmente s6lo podemos ver una direcci6n en el modelado dimensional: el Que va desde las bases de datos operacionales hacia las anal(fleas, pero no el opuesto, es decir, desde \as necesidades analfticas hacia un disefio operacional.
La metodologia utiliza como marco de referencia la propuesta para la versi6n 3 de la Metodo2ogla Pdblica Esparjola M:ETRfCA (MV3) [91. Los procesos pertenecientes a MV3 Que se contemplan son S9u61105en los Quela especificidad del desarrollo de un Almac6n de Datos tiene una mayor influencia, en concreto, los procesos de Andlisis del Sistema de Informaci6n (ASI), Diseiio del Sistema de Informaci6n (DSI) y Construcci6n del Sistema de Informaci6n (CST). Los nuevos procesos, modificados a partir de 2os propuescos en MV3, ban recibido el nombre de ASI-MD (MultiDimensional), DSI-MD y CSI-MD. El considerer 6mcamente estos tres procesos no signiffca Que el resco de 2os concemp2adosen MV3 no deban tenerse en enema en el desarrollo de un almac6n de datos. Es evidence Que existir una implantaci6n del sistem& Que puede Ilevarse a cabo un estudio de viabi2idad pronto, etc., sin embargo, se ha consider&do Que no sen-an significativas las diferencias con respecto al desarrollo de cualquier otro sistema de informaci6n.
La figura 3 muestra una visi6n global de la metodologfa, mostrando el alcance de los tres procesos Que la componen, ASI-MD, DSI-MD y CSI-MD.
Cada uno de estos procesos se divide en actividades y, a su vez, 6stas se descomponen en tareas. El orden asignado a las actividades no debe interpretarse necesariamente como "una secuencia en su realizaci6n, ya Que 6stas pueden realizarse en orden diferente a su codificaci6n o bien en paralelo, intercalando tareas de actividades diferentes. Sin embargo, no se dar;i por concluido un proceso hasta no haber terminado codas Sus actividades. En los grdficos Que acompaflan &cada proceso, se destacan las actividades Que tengan una implicaci6n destacada en el desarro!lo de un almacdn de datos.
..~~ (MOIAPOrBLRU:!c|<a i`m uh NI;ion11 ~o~OSi ' Figura 3. Vision general de la metodologfa
ban de llevar a cabo en la actividad de modelado conceptual del almacen de datos. For falta de espacio, no se incluyen los productos de entraday salida de cada tarea, los participantesen la misrnay las tecnicas utilizadas.
El objetivo de esta actividad consiste en obtener, aplicando el modelo IDEA, el esquema conceptual multidimensional de datos del alrnac6n de datos. a partirdel cata1ogode requisitos y de los esquernas entidad/interrelaci6n existentes. Consta de las siguientes siete actividades:
Esta tarea consiste en la obtenci6n de estructuras de subcelda preliminares. Estas estructurasde subceldamodelerar|los "eventos que ocurrendinmicamente en el mundo de la empresa" [51, tales como las ventas en una empresa, los movimientos de una cuenta de ahorro etc. No es necesario en este punto detailer cada estructurade subcelda hasta el nine! del atributo concreto y las funciones de sfntesis que la forman. En este momento estamos interesados dnicamente en estructurasgenerales, preliminares. La inforrnaci6n necesaria para el modelado de las estructuras de subcelda preliminares puede proceder de distintas fuentes: por una parte,y mas importance,la opini6n de IDS usuarios expertos. Son ellos los que mejor conocen su problematicay por tanto los que saben qu6 datos son los que necesitan en su trabajo. Habitualmente se. corresponden con medidas num6ricas de la empresa, preferentementevalores "numcos, continuos, y aditivos" [71. Por otra parte, si contamos con el esquema entidad/interrelaci6n de la base de datos de la empresa,estas estructurasde subcelda preliminares suelen corresponderse con determinados atributos de entidades o de interrelaciones N:M. Tambi6n podremos coater con el esquerna conceptual multidimensional previo elaborado en la actividad ASI-MD I .
42. Obtenci6n
Una vez detectadas las estructurasde subcelda preliminares, Que representan las variables de inter6s en la empresa, el siguiente paso consiste en detectar las dimensiones Que formardn parte de cada uno de ellos, es decir, de qu6 forma se podn agxegarlos valores que hemos detectado. En este momento los usuarios deben pensar en las dimensiones de forma abstracta, sin intentar necesariamente identificar IDs atributos Que formar;insu jerarquia de forma individual. For ejemplo, IDsusuaxiospensardnen dimensiones tales como el tiempo, el espacio, etc., y no en t6rrninos de atributoscomo dfas-meses-ados (en el caso del tiempo) o deSegaci6n-provincia-pais(en el caso del espacio). Esta forma de trabajardescendentepuede complementarse con el estudio de Sos esquemas conceptuales de las bases de datos operacionales, observando Sos atributos Que componen las entidades e interrelaciones Que Se encuentran enlazados (bien directamente, bien a trav6s de otras) a aqueHas Que Se ban identifxcado como hechos en el esquema entidad/interrelaci6n.Estos atxibutos nos darn pistas acerca de posibles dimensionesocultas no detectadaspor los usuarios.
43.
esquemapreliminarque constarade un conjunto de estructurasde subceldaprelirninaresdefinidas sobre determinadas dimensiones. Es el momento de intentaridentificar de forma nu poco mas precisa las dimensiones y las correspondientesjerarquias. Se identificara cada dimensi6n, describiendo, en caso de Que exista, la subjerarqufaque la forma y las agregaciones de Que consta esta. No es necesario en este momento entraren detalle de los doxninios de dimension de Que consta cada agregaci6n, ni en el detalle de las funciones de agregaci6n-En este momento podran identifxcarse nuevas dimensiones. Un ejemplo upico de estas es el liempo, que en ocasiones no esta presente en las bases de datos elementales pero Que suele ser Una dimensi6n fundamental en codes los almacenes de datos.
4.4.
El siguiente paso consiste en depurar las jerarqufas obtenidas en el paso anterior. Esta depuraci6nconsistirxien la enumeraci6n detallada de 105 atributos de dimension de Que consta la subjerarquia asociada a la dimensi6n. Podrdn detectarseatributosnuevos o elirninarotrosinx:itiles, distinguir o aBadiraqu6Hosque serdn Onicamente propiedadesde los atributospropios de la jerarquia (atributos de descripci6n). For ejemplo, en Una dimension Quecontemple las distintas delegaciones de Una empresa en un pals, podemos contemplar el tel6fono o la direcci6n de cada delegaci6n. Estos atributos no son mds Que propiedades (atributos de descripci6n) del propio atributo de dimensi6n~ Para todos los atributos se definir;i su dominio, o se asignard a un dominio ya definido. Asiruismo, se elaborard la jerarquia de agregaciones de dorninios, especificando en mayor detune las funciones de agregaci6n entre Jos mismos.
Una vez obtenidas por completo las dimensiones y definidas Susjerarquias, pasaremos a estudiar en ms detalle las estructuras de subcelda. Especificaremos para cada una de ellas el atributo de Que consta y las funciones de sintesis Que se ap2icardnsobre el mismo. Se estudiald cada Una de estas funciones con respecto a cada Una de las dimensicnes, comprobando que cada funci6n de sintesis Se puede aplicar a lo largo de cada Una de las dimensiones Co atributo de dimensi6n), se6alando aquellas que no Sean aplicables (aunque algunas son evidentes, por ejemplo no tiene sentido sumar la temperatura a lo largo de los dias del 860, en general deberan indicarlas explfcitamente los usuarios). Habitualmente estas funciones de sintesis consistiran en la funci6n Suva, aunque en ocasiones el usuario puede desear otras distintas (por ejemplo, la media, el valor rmiximo, el mfnimo, etc.).
En este momento tenemos identiflcadas estructuras de subcelda, cada Una con suS dimensiones asociadas. El siguiente paso consiste en la agrupaci6nde las estructurasde subceldas en estructuras de celda, para format esquemas de hecho. Como cada estructurade ceZdapertenece a un esquemade hecho, y a su vez cada esquema de hecho consta de unas dimensiones determinadas, deberemos detectaraquellas estructurasde subcelda
consistir en:
Uni6n de dos estructuras de subcelda en una dnica, debido a Querepresentana2mismo hecho (es decir, estabanduplicadas). Sus atributosde sfntesis y Sus dimensiones coincidirdn. Las funciones de sintesis resultado de la uni6n serdn la uni6n de las funciones de sfntesis de ambas estructuras de subcelda, eliminando aquellas que estuvieran duplicadas. Se revisar la aplicabilidad de las mismas a las dimensiones o atributosde dimensi6n.
Agregaci6n de dos estructuras de subcelda en una estructura de celda, o una estructura de subcelda a una estructura de celda ya identificada previamente. En este caso Sus dimensiones deben tener cierta coincidencia" Decimos cierta coincidencia porque en ocasiones puede interesar unir estructuras en las Que no exist& una coincidencia total de dimensiones. En ese caso, habra que estudiar c6mo se comportan las agregaciones en el caso de las nuevas dimensiones (o atributos de 6stas) incorporados. Es decir, que Sean o no agregables en las misrnas. Naturalmente, siempre tendremos la posibilidad de incorporar todas las estructuras de subcelda en una misma estructura de celda (esquema de hecho), pero en este caso puede ocurrir Que existan numerosos atributos de sfntesis Que no Sean agregables en muchas dimensiones. El esquema, ademas, puede resultar poco legible.
En esta tarea se verifica y Valida el esquema conceptual multidimensional, con el objetivo de asegurar que el mismo sea completo, ajustado al catalogo de requisitos, y que siga unos criterios de calidad predeterminados,
Se realizaran otro tipo de comprobaciones, como por ejemplo, que 105 datos del almac6n de datos Que obtendremos de las REDD elementales estdn disponibles en las mismas (si no estan disponibles en dichas REDD habra que plantear, por ejemplo, la necesidad de modificarlas).
La figura 4 muestra un ejemplo de esquema resultante producto de la actividad anterior, cuya representaci6n grdflea aparece en la figura 2. Dom.n Sub~&al: "DDSnWed - (AW=lb!{n} *D:Sr(Pm=-fe(Ai!=6af!tT:rPQ . , _ .
multidimensionalen ID , ae esquema 5' Condnsxones
El desaltoSlo de un Almacen de Datos se ha convertido en un factor crftico de 6xito para muchas compafifas. Pol tanto no es razonable rnanejar el proceso de construcci6n fuera del marco de trabajo de una metodologia. Esta no es Una aproximaci6n totalmente nueva, pero existen algunas apottaciones en el trabajo Renado a cabo- en el proyecto EINSTEIN omo. `. berramienta CASE traduce esquemas IDEA a
\ Este trabajo se esui Ilevando a cabo dentro del |proyecto MIDAS, parcialmente financiado por la
[I] L. Cabibboy R. Torlone."A Logical Approach to Multidimensional Databases" En Sixth International Conference on Extending Database Technology (EDBT'98), Valencia Espaha Lecture Notes in Computer Science 1377. Springer'-Verlag.pages 183.. 197, 1998.
[21 S. Chaudfluriy U. Dayal. "An Overview of Data Warehousing and OLAP Technology". ACM SIGMOD Record26(I) Marzo 1997
[3] B.` ter, C. Sapia M. Blaschk&'G. Hofling. "OLAP Market and Research: Initiating the Cooperation". Journal of Computer Scion and InformationManagement,Vol 2, N. 3, 1999.
[
Cices3s9981lawaii Intemaional Conference On esquemas analfticos partiendo de los requisitos de 105 usuaxios de datos analfticos, utilizando los esquemas operacionales existentes como un soporte para la creaci6n del esquema conceptual multidimensional.
[6] M. Golfarelli Y S. Rizzi "Designing The Data Warehouse:Key Steps And Crucial Issues". Journal Of ComputerScience And Information Management,Vol 2, Nf 3, 1999' [7] R' Kimball. The Data Warehouse Toolkit: * Ingenia
Inversa p a, laobtenci6 de ese o9eyf
Sbo dimensional data esquema en IDEA a Partxrde las bases de datos multidxmensionales esPecfflcas existentes'
' Creaci6n o modificaci6n de esquemas operacionales existentes como result&do de las necesidades de 105usuariOs analiticos.
Se ha desarrollado una metodologia multidimensional general basada en una propuesta para la versi6n 3 de la Metodologi bhca spafiola de Planifxcaci6n y Desarrolloe Sistemas de Inforrnaci6n (CA) [91. Pe de la metoloa es poado por Una haenta CASE (mEA-DWCASE), de la cual ya disne de un pm prototi prentado en 101. Es heaenta, cuya escta del rositoo es el memodelo de EA, peite la creaci6n de enevus conctuales multidimensioles basados en 7EA, y la aducci6n de 6stos a diferent [g] R. Kimball, ' L. Reeves, M. Ross, W. y ThornWaite. The Data Warehouse Lifecicle 'Too]kit., John Wiley & Sons. Inc,, 1998
[9] A. de Miguel et al., "METftICA Version 3: Planning and Development Methodology of Information Systems. Designing a Methodology: A Practical exPerience",in CIfCC98. Aguascalientes, Mxico, Nov. 1998. Pags 264 276 mun[I ] guetsD`EDOOf)SE: oftd ck. Eons[ e
Mo de Demons6ons 20
[ll] A. Schez, J.M Caveroy A Miel. "IDEA: A cone mulmension model d me meodoloc implicao". CIICC'99, Ccan, M ico'Ps 30718.
{12}C' Sia G`HOnin M-Mmler,C Hausdo H. usey Sicer mMiaiD edus o omoento a
W WoP: Da
WnB d D