diseño arquitectonico.pdf

24
13 SISTEMAS & TELEMÁTICA Propuesta de un método para el diseño y modelado de una bodega de datos José Hernando Bahamón L. Universidad Icesi [email protected] RESUMEN El desarrollo de los Sistemas de In- formación Gerencial basados en tec- nologías de Data Warehouse y Herra- mientas Olap, es relativamente re- ciente y, por lo tanto, no existe una propuesta metodológica universal- mente válida y aceptada como tal, por la comunidad académica. El presente artículo expone una pro- puesta metodológica para la realiza- ción del diseño de una bodega de da- tos, que utiliza como eje articulador la identificación de las necesidades de información por parte de la gerencia, para el soporte de los procesos de con- trol y de toma de decisiones. El método propuesto está compuesto de ocho pasos agrupados en tres fa- ses. La primera fase comprende la identificación de las necesidades de información gerencial, desde la pers- pectiva del negocio. La segunda fase comprende todas las actividades re- lacionadas con la elaboración de un modelo lógico-conceptual de la estruc- tura de la bodega de datos. La terce- ra fase incluye los pasos para reali- zar el diseño físico de la estructura de la bodega de datos. PALABRAS CLAVES Bodegas de datos, método de diseño de la estructura de una bodega de datos. ABSTRACT The development of Management In- formation Systems based on Ware- Fecha de recepción: 15-4-2003 Fecha de aceptación: 25-8-2003

Upload: sophie-triana

Post on 27-Nov-2015

46 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Diseño arquitectonico.pdf

13SISTEMAS& TELEMÁTICA

Propuesta de un método para el diseñoy modelado de una bodega de datos

José Hernando Bahamón L.Universidad Icesi

[email protected]

RESUMENEl desarrollo de los Sistemas de In-formación Gerencial basados en tec-nologías de Data Warehouse y Herra-mientas Olap, es relativamente re-ciente y, por lo tanto, no existe unapropuesta metodológica universal-mente válida y aceptada como tal, porla comunidad académica.

El presente artículo expone una pro-puesta metodológica para la realiza-ción del diseño de una bodega de da-tos, que utiliza como eje articuladorla identificación de las necesidades deinformación por parte de la gerencia,para el soporte de los procesos de con-trol y de toma de decisiones.

El método propuesto está compuestode ocho pasos agrupados en tres fa-

ses. La primera fase comprende laidentificación de las necesidades deinformación gerencial, desde la pers-pectiva del negocio. La segunda fasecomprende todas las actividades re-lacionadas con la elaboración de unmodelo lógico-conceptual de la estruc-tura de la bodega de datos. La terce-ra fase incluye los pasos para reali-zar el diseño físico de la estructurade la bodega de datos.

PALABRAS CLAVESBodegas de datos, método de diseñode la estructura de una bodega dedatos.

ABSTRACTThe development of Management In-formation Systems based on Ware-

Fecha de recepción: 15-4-2003 Fecha de aceptación: 25-8-2003

Page 2: Diseño arquitectonico.pdf

14 SISTEMAS& TELEMÁTICA

house Data technologies and Olaptools is relatively new. Therefore, the-re is no valid methodological appro-ach that is generally accepted as suchby the academic community.

This article presents a methodologi-cal approach to the design of a datawarehouse using the identification ofmanagement information require-ments as a shaft that supports thecontrol and decision-making proces-ses. The suggested approach consistsof eight steps grouped in three diffe-rent stages. The first stage encompas-ses the identification of management

information requirements from a bu-siness perspective. The second onedeals with all the activities associa-ted with the preparation of a logicalconceptual model for the data ware-house structure, and the third stageincludes the steps to make the phy-sical design of the data warehousestructure.

KEY WORDSData warehouses, approach to thedesign of a data warehouse struc-ture.

Clasificación: A

Page 3: Diseño arquitectonico.pdf

15SISTEMAS& TELEMÁTICA

INTRODUCCIÓNEl desarrollo de los Sistemas de In-formación Gerencial basados en tec-nologías de Data Warehouse y herra-mientas Olap, es relativamente re-ciente y, por lo tanto, no existe unapropuesta metodológica universal-mente válida y aceptada como tal, porla comunidad académica.

Entre las propuestas más conocidasestán: 1. Ralph Kimball,1 con un es-quema centrado en la identificaciónde los procesos de la empresa, comoelemento clave para la definición dela estructura de variables y dimen-siones; 2. W.H. Inmon,2 con un esque-ma que parte de la construcción delmodelo de datos corporativos, elabo-rado al más alto nivel de abstracción,para luego derivar la estructura delmodelo de datos, para el diseño de labodega; 3. Golfarelli Matteo, MaioDario, Rizzi Stefano3 proponen unesquema que parte de los modelos E-R descriptivos de los sistemas tran-saccionales de la organización, paraluego derivar el modelo E-R de la es-tructura, para la bodega de datos.

En este artículo se presenta una pro-puesta de sistematización del proce-so de diseño de una bodega de datos,que se aparta de los esquemas de di-seño referidos, y que utiliza como ejearticulador, la identificación de la in-formación gerencial, para el soportede los procesos de control y de tomade decisiones en los niveles directi-vos de la organización.

MÉTODO PROPUESTOEl método de diseño propuesto estácentrado en la identificación de lainformación clave y relevante para so-portar los procesos de dirección y detoma de decisiones dentro de la orga-nización. Este método utiliza, comopunto de partida, la identificación yel modelado de: qué es lo que elnegocio está tratando de alcan-zar, para luego elaborar una estruc-tura que apoye el proceso de gestiónhacia el logro de las metas definidas.

Una vez que la información clave deapoyo a los procesos de gestión y con-trol de la organización ha sido iden-tificada, se inicia la elaboración delmodelo lógico-conceptual de la estruc-tura de la bodega de datos, que so-portará las consultas y la exploraciónde los datos, a partir de los cuales seconstruirán los indicadores de gestiónrequeridos por los niveles directivosde la organización.

Para darle un orden a este procesosistémico de diseño, los pasos delmétodo propuesto, tal como se presen-tan en la Figura 1, se han agrupadoen las siguientes fases:

• Fase 1: Identificación de las ne-cesidades de información geren-cial, desde la perspectiva del ne-gocio.

• Fase 2: Elaboración del modelo ló-gico-conceptual de la estructurade la bodega de datos.

1. Kimball R. The Data Warehouse Toolkit. John Wiley & Sons, 1996.

2. Inmon W.H. Building The Data Warehouse. QED Press / John Wiley & Sons, 1992.

3. Golfarelli M., Maio D., Rizzi S. Conceptual Design of Data Warehouse From E/R Schemes.http//www.csr.unib.it/~golfare/db.html, 1998.

Page 4: Diseño arquitectonico.pdf

16 SISTEMAS& TELEMÁTICA

• Fase 3: Elaboración del modelo fí-sico de la bodega de datos.

Fase 1:Identificación de las necesidadesde información gerencial, desdela perspectiva del negocio.

La primera fase, a partir de la cualse realiza el proceso de diseño de laestructura para una bodega de datos,comprende la identificación de las ne-cesidades de información gerencial,lo que significa hacer explícitos losobjetivos y los factores claves de éxi-to de la organización, o de un áreadel negocio.

Es bastante común empezar este pro-ceso de identificación y modeladomediante entrevistas a los directivos,en las cuales la pregunta central es:

«¿Cuál es la información que deseaobtener del sistema de informacióngerencial?». Este enfoque puede resul-tar muy peligroso, si el directivo norealiza un proceso sistemático y orde-nado, para establecer sus necesidadesde información, en relación con sus ac-tividades de gestión y control.

Una forma ordenada y sistemáticapara realizar esta fase de identifica-ción de las necesidades de informa-ción, que soporte los procesos de ges-tión y control gerencial, es la aplica-ción del enfoque de sistemas, paraguiar el proceso de revisión o defini-ción de: 1. Los objetivos estratégicosdel negocio o del área; 2. Los factoresclave para el logro de los objetivos de-finidos y 3. Los indicadores de con-trol, tanto de los objetivos como de losfactores clave.4

4. Véase Bahamón José H. Construcción de indicadores de gestión bajo el enfoque de sistemas. S&T Revistade la Facultad de Ingeniería, Universidad Icesi. 2003.

Page 5: Diseño arquitectonico.pdf

17SISTEMAS& TELEMÁTICA

Método para el diseño y modelado de una bodega de datos

Fase 1: Identificación de las necesidades de infor-mación gerencial, desde la perspectiva del negocio.

Fase 2: Elaboración del modelo lógico-conceptualde la estructura de la bodega de datos.

2.1. Definir las tablas de hechos o las variables de laestructura.

2.2. Identificar, para cada tabla de hechos, las dimen-siones que la referencian.

2.3. Establecer el nivel de granulación y los niveles deagregación.

2.4. Elaborar el diagrama en estrella que representala estructura de la bodega.

Fase 3: Elaboración del modelo físico de la bodegade datos.

3.1. Verificación y ajuste del modelo lógico.

3.2. Definición del esquema físico del almacenamien-to de las dimensiones y sus jerarquías.

3.3. Definición de los atributos que conforman lastablas de hechos.

Figura 1. Método para el diseño y modelado de una bodega.

Page 6: Diseño arquitectonico.pdf

18 SISTEMAS& TELEMÁTICA

Como resultado de esta fase, se ten-drá una visión del negocio y de la in-formación requerida para la direccióny el control gerencial, representadafundamentalmente por: Los objetivosdel negocio; los factores clave de éxi-to y, en especial, un conjunto de indi-cadores clave de la gestión.

Fase 2:Elaboración del modelo lógico-conceptual de la estructura de labodega.

En esta fase se elabora el modelo ló-gico de la estructura de la bodega, quesoportará las consultas, mediante lascuales se obtendrá la información re-querida por los niveles directivoscomo apoyo a sus procesos de gestióny de toma de decisiones.

La elaboración de este modelo lógicocomienza con los indicadores de ges-

tión (necesidades de información ge-rencial), identificados en la fase an-terior, y termina con la construcciónde una representación multidimen-sional de las variables que conformancada indicador. En esta representa-ción multidimensional, cada variablees modelada mediante un arreglo di-mensional (multidimensional) de cel-das, como se presenta en la Figura 2.

Para facilitar el proceso de elabora-ción del modelo lógico, se utiliza unarepresentación gráfica denominadadiagrama tipo estrella, donde el ele-mento central del esquema es la Va-riable o Tabla de Hechos («Fact»), lacual es referenciada por un conjuntode ejes, denominados Dimensiones, através de los cuales se seleccionan losvalores contenidos en la tabla de he-chos. En la Figura 3, se esquematizael modelo de un diagrama en estrella.

Page 7: Diseño arquitectonico.pdf

19SISTEMAS& TELEMÁTICA

Figura 2. Vista multidimensional de una de las variables que conformanun indicador.

Figura 3. Diagrama en estrella de una estructura multidimensional.

Page 8: Diseño arquitectonico.pdf

20 SISTEMAS& TELEMÁTICA

Antes de presentar los pasos propues-tos por el método para la elaboracióndel modelo lógico, es pertinente pre-cisar algunos de los términos utiliza-dos en el método propuesto. En el

Cuadro 1 se presentan las definicio-nes adoptadas para los diferentesconceptos utilizados en el método pro-puesto.

Cuadro 1: Definición de conceptos básicos.

Una gráfica es una red de nodos interconectados.Una gráfica direccional es aquella en la cual la conexión entredos nodos tiene una dirección específica.Un modelo E-R puede ser considerado una gráfica direccional.

En una gráfica, una trayectoria acíclica es aquella que sólotiene una forma de recorrido (en un solo sentido).Una trayectoria cíclica es aquella que se puede recorrer en doso más secuencias diferentes.

Es la tabla central de la estructura de la bodega. Esta tablacontiene los datos de interés para el negocio, es decir, los valo-res para la construcción de los indicadores claves del negocio.

Técnicamente, la tabla de hechos es una entidad de intersec-ción cuya llave primaria está compuesta por la unión de losdominios de las diferentes dimensiones que la referencian.

Las dimensiones corresponden a los ejes con los cuales se cons-truye la vista multidimensional de la información clave del ne-gocio, almacenada en la tabla de hechos.

Las atributos almacenados en las dimensiones determinan lagranulación adoptada para el modelo.

Las dimensiones pueden ser:

– Propias: Cuando el conjunto de entidades que conformanla dimensión se encuentran unidas a la tabla de hechos, enuna trayectoria acíclica.

– Impropias: Cuando el conjunto de entidades que confor-man la dimensión se encuentran unidas a la tabla de he-chos, en una trayectoria cíclica.

– De Información: Cuando los atributos contenidos en ladimensión definen qué tipo de datos se encuentran almace-nados en la tabla de hechos.

Determinan cómo las instancias de la tabla de hechos pueden seragregadas. Las jerarquías permiten las operaciones de «drill-down»o «rollup», en los procesos de consulta.

Una jerarquía está conformada por el conjunto de entidadesque constituyen la dimensión.

Gráfica

Trayectorias cíclicasy acíclicas

Tabla de hechos

Dimensión

Jerarquías

Page 9: Diseño arquitectonico.pdf

21SISTEMAS& TELEMÁTICA

A continuación se presentan los cua-tro pasos propuestos para la sistema-tización del proceso de elaboración delmodelo lógico:

Paso No. 1:Definir las tablas de hechos o lasvariables de la estructura.

Este paso se realiza a partir del con-junto de los indicadores de gestión,definidos en la fase de identificaciónde las necesidades de informacióngerencial, desde la perspectiva delnegocio. El paso se inicia con la eva-luación de las variables (divisores ydividendos) de cada indicador, paradeterminar cuáles de éstas puedenser almacenadas en una tabla de he-chos, y cuáles no.

En el Cuadro 2 se presenta, a mane-ra de ejemplo, la información obteni-da, al aplicar los pasos de la fase 1 alárea de ventas de una organización.A partir de estos resultados se iden-tifican las variables o tablas de he-chos, como lo establece el paso 1 deesta fase.

Aplicación del paso 1: Identificaciónde las tablas de hechos

• El indicador definido para el mo-nitoreo del objetivo puede serconstruido con una sola tabla dehechos: Ventas. Se toma una solavariable, por cuanto las ventas delaño y las ventas del año anterior,que son las dos variables que con-forman el indicador, se puedenalmacenar en la misma tabla dehechos.

• El indicador 1 del F.C.E1 puedeser construido con dos tablas dehechos que son: ventas por ven-dedor y cuota de ventas de cadavendedor.

• El indicador 2 del F.C.E1 puedeser construido con dos tablas dehechos que son: número de visi-tas realizadas por cada vendedor,y número de visitas presupuesta-das por cada vendedor.

• El indicador 1 del F.C.E2 puedeser construido con una tabla dehechos: número de clientes nue-vos en la base de datos. En estecaso, el denominador del indica-dor se asume como un único valory, por lo tanto, no tiene sentidoalmacenarlo en otra tabla de he-chos.

• Los demás indicadores se anali-zan de igual manera.

En suma, al realizar el análisis detodos los indicadores, obtenemos lassiguientes tablas de hecho:

• Ventas.

• Ventas por vendedor.

• Cuota de ventas de cada vende-dor.

• Número de visitas realizadas porcada vendedor.

• Número de visitas presupuesta-das por cada vendedor.

• Número de clientes nuevos en labase de datos.

• Número de vendedores capacita-dos que aprobaron los cursos.

Page 10: Diseño arquitectonico.pdf

22 SISTEMAS& TELEMÁTICA

Cuadro 2: Información gerencial del área de ventas,obtenida al realizar la fase 1.

Área del Negocio - Descripción. Se trabaja con el área de ventas de una orga-nización dedicada a la producción de recipientes elaborados en plástico.

Objetivo del Área: para propósitos del ejemplo, se toma el siguiente objetivo:

Lograr al final del año un incremento del 15% en las ventas totales de lacompañía, con respecto a las ventas del año anterior.

Factores claves de éxito. Luego de realizado el análisis de las acciones y lascondiciones necesarias para garantizar el logro del objetivo planteado, se identi-ficaron los siguientes F.C.E:

• F.C.E.1: Planeación y control de la fuerza de ventas.

• F.C.E.2: Búsqueda de nuevos clientes rentables para la organización.

• F.C.E.3: Capacitación y entrenamiento de la fuerza de ventas.

Indicadores claves de gestión. Para el control y seguimiento de los F.C.E y losobjetivos, se proponen los siguientes indicadores:

Ventas del añoI_obj: -1

Ventas del año anterior

Ventas del vendedor

I1_FCE1:Cuota de ventas

Número de visitas de venta realizadas

I2_FCE1:Número de visitas presupuestadas

Número de clientes nuevos en la base de datos

I1_FCE2:Número de clientes nuevos presupuestados

Número de vendedores capacitados que aprobaron los cursosI1_FCE3:

Número presupuestado de vendedores capacitados

Page 11: Diseño arquitectonico.pdf

23SISTEMAS& TELEMÁTICA

Paso No. 2:Identificar, para cada tabla dehechos, las dimensiones que lareferencian.

Para cada variable o tabla de hechosse identifican, con la colaboración delusuario líder del área de negocio, losejes de visualización multidimensio-nal los cuales constituyen las dimen-siones de la variable.

En este paso, se espera que el usua-rio visualice cada variable, como unconjunto de valores almacenados enuna estructura de varias dimensio-nes, donde los valores almacenadosson referenciados por la combinaciónde los valores definidos para cada eje(dominio de la dimensión), tal comose esquematiza en la Figura 4.

Figura 4: Esquema de una vista multidimensional de una tabla de hechos.

Paso 3:Establecer el nivel de granula-ción y los niveles de agregaciónde cada dimensión.

Una vez que las dimensiones han sidoidentificadas se debe establecer, paracada una de ellas, el menor nivel degranulación, el cual corresponde alconjunto de atributos que referencianel mayor nivel de detalle deseadopara la variable o tabla de hechos.

A manera de ejemplo, se aplican losdos pasos anteriores para la Tabla de

Hechos sobre Ventas, definida en elejemplo anterior.

Aplicación del paso 2: Identificaciónde las dimensiones.

Supongamos que el gerente de ven-tas expresa su interés por visualizarla información de ventas organizadade la siguiente manera: primero, porcada producto de la compañía; en se-gundo término, por cada lugar endonde se venden los productos y, fi-nalmente, por cada semana. Podemosestablecer la necesidad de utilizar

Page 12: Diseño arquitectonico.pdf

24 SISTEMAS& TELEMÁTICA

tres ejes para elaborar la vista mul-tidimensional (dimensiones) de laTabla de Hechos - Ventas:

• Dim1: Producto

• Dim2: Lugar de venta

• Dim3: Tiempo.

Aplicación del paso 3: Definición delnivel de granulación.

De acuerdo con la solicitud del geren-te, se establece para cada dimensiónla siguiente granulación:

• Dim. Producto: El menor nivelde granulación es el Tipo de Pro-ductos. Podemos establecer otrosniveles como: Línea de Productos,que tiene un nivel de granulaciónmayor, pero un menor nivel de de-talle en la variable ventas; o Re-ferencias de Productos, que tieneun menor nivel de granulación,pero un mayor nivel de detalle.

• Dim. Lugar: El nivel de granu-lación requerido es la Ciudad. Sehabrían podido seleccionar otrosniveles, como Almacén, que tieneun menor nivel, o Región, que tie-ne uno mayor.

• Dim. Tiempo: El menor nivel degranulación requerido es la Sema-na. Se habrían podido seleccionarotros niveles, como el Día, que tie-ne un menor nivel, o el Mes, quetiene uno mayor.

Una vez se han definido los menoresniveles de granulación para cada di-mensión, se identifican los niveles deagregación requeridos para los valo-res almacenados en la tabla de he-

chos, por cada dimensión. Estos ni-veles de agregación representan lajerarquía de cada dimensión.

• Jerarquía en la Dim. Produc-to: Las ventas por productos pue-den ser agregadas por grupos deproductos, por líneas de produc-tos y, por el total de la venta. Deesta manera, los niveles de agre-gación de la dimensión productoson:

– Por grupos de productos.

– Por líneas de productos.

– Total.

• Jerarquía en la Dim. Lugar:Las ventas por lugar pueden seragregadas por regiones y por eltotal del país.

• Jerarquía en la Dim. Tiempo:Las ventas por tiempo pueden seragregadas por mes, por trimestre,por semestre, por año.

Paso 4:Elaborar el diagrama en estrellaque representa la estructura dela bodega.

Luego de identificar los elementosque conforman la estructura de lavista multidimensional, de la infor-mación gerencial requerida por laorganización, se pasa a la elaboraciónde una representación gráfica, en for-ma de estrella; para ello se puede uti-lizar la notación simplificada de losdiagramas E-R, o la notación deno-minada «Dot modeling».5

5. Todman, Chris. Designing a Data Warehouse: Supporting Customer Relationship. Prentice Hall, 2001.

Page 13: Diseño arquitectonico.pdf

25SISTEMAS& TELEMÁTICA

Notación tipo E-R:En esta notación, el diagrama en es-trella está conformado por una enti-dad central asociativa, que correspon-de a la tabla de hechos, y por un con-

junto de trayectorias de entidades yrelaciones de uno a muchos, que co-rresponde a las dimensiones y a susjerarquías. En la Figura 5 se presen-ta un diagrama en estrella con estanotación.

Figura 5. Representación de un diagrama en estrella, mediante lanotación tipo E-R.

Notación «Dot Modeling»En esta notación, el diagrama en es-trella está conformado por una enti-dad central que corresponde a la Ta-bla de Hechos, y por un conjunto de

trayectorias compuestas por puntos(«dots»), que representan las dimen-siones y sus jerarquías. En la Figura6 se presenta un diagrama en estre-lla con esta notación.

Figura 6. Representación de un diagrama en estrella, mediante lanotación «Dot Modeling».

Page 14: Diseño arquitectonico.pdf

26 SISTEMAS& TELEMÁTICA

A manera de ejemplo se presenta enla Figura 7, el diagrama en estrella,con notación «Dot Modeling», para laTabla de Hechos y para las dimen-siones identificadas en el ejemplo

anterior. En la Figura 8 se represen-tan los mismos elementos de la es-tructura de la bodega, pero con nota-ción tipo E-R.

Figura 7. Representación, mediante la notación «Dot Modeling», de laestructura para la bodega de datos del ejemplo anterior.

Figura 8. Representación, mediante la notación E-R, de la estructura parala bodega de datos del ejemplo anterior.

Page 15: Diseño arquitectonico.pdf

27SISTEMAS& TELEMÁTICA

Fase 3:Elaboración de la estructura fí-sica de la bodega

Durante esta fase, se realiza la trans-formación del modelo lógico concep-tual en la estructura física, que pos-teriormente será implementada enalguna herramienta de «Data Ware-house».

Este proceso de transformación serealiza mediante los siguientes pasos:1. Verificación y refinamiento delmodelo lógico para determinar su con-sistencia. 2. Definición del esquemafísico de almacenamiento de las es-tructuras jerárquicas de las dimen-siones. 3. Identificación de los atri-butos que conforman las tablas dehechos y las dimensiones.

Paso 1:Verificación y ajustedel modelo lógico.Durante este paso, se realiza la veri-ficación del modelo lógico, obtenido enla fase anterior, para garantizar queel modelo, además de soportar todaslas consultas requeridas por los ni-veles ejecutivos, siempre retorne in-formación confiable.

Para iniciar este proceso de verifica-ción se debe elaborar una matriz decruce, entre los requerimientos deinformación gerencial, definidos en lafase inicial, y las estructuras (estre-llas), definidas en la fase anterior. Enla matriz de cruce se confirma si elrequerimiento está completamente

soportado. Si esta verificación no escorrecta, se debe retornar a la faseanterior, para incorporar las estruc-turas que soporten los requerimien-tos faltantes de información.

Terminada la revisión anterior, elproceso continúa con la evaluación dela estructura, para asegurar la vali-dez de todas las consultas de infor-mación realizadas sobre dicha estruc-tura.

Para realizar este proceso de compro-bación de validez de la estructura,recurrimos a la teoría de grafos, se-gún la cual una estructura de consul-ta es válida cuando está conformadapor trayectorias acíclicas. Al aplicaresta teoría, se puede afirmar quecualquier diseño para una bodega dedatos permitirá siempre consultas co-rrectas, si la estructura propuestaestá conformada únicamente por di-mensiones propias, es decir, por tra-yectorias acíclicas.

Si al realizar la comprobación de laestructura se encuentran trayecto-rias acíclicas, éstas deben ser trans-formadas, para asegurar la confiabi-lidad de las consultas. Las posiblestransformaciones son:6

1. Ajuste para los casos de trayecto-rias cíclicas simplesEste caso ocurre cuando la trayecto-ria de una dimensión presenta unatrayectoria alterna que tiene dos en-tidades comunes. En la Figura 9, seesquematiza una trayectoria cíclicasimple.

6. Mcguff, F. Designing the perfect Data Warehouse. 1998.

Page 16: Diseño arquitectonico.pdf

28 SISTEMAS& TELEMÁTICA

Figura 9. Dimensión con trayectoria cíclica.

2. Ajuste para los casos de trayecto-rias alternas, mezcladas con trayec-torias cíclicas.Se presenta cuando la trayectoria deuna dimensión está conformada poruna trayectoria alterna, más una tra-yectoria cíclica, tal como se esquema-tiza en la Figura 10.

Figura 10. Dimensión con trayectoria alterna, más trayectoria cíclica.

Las opciones de transformación paraesta clase de trayectorias son:

• Tratar cada trayectoria como unanueva dimensión, lo cual signifi-ca redibujar el diagrama, elimi-nando las relaciones N1-A2 y A3-N4, para luego crear la relación:Tabla de Hechos - A2.

• Convertir la trayectoria cíclica enuna trayectoria alterna, eliminan-do la relación A3-N4.

Page 17: Diseño arquitectonico.pdf

29SISTEMAS& TELEMÁTICA

En estos casos, el problema ocurre conla trayectoria cíclica; por lo tanto, latransformación se maneja como se ex-plicó en el caso anterior.

Paso 2:Definición del esquema físico delalmacenamiento de las dimensio-nes y sus jerarquías.

El modelo en estrella que conformala estructura lógica propuesta para

la bodega de datos, debe ser conver-tido en una estructura totalmentedesnormalizada, tal como se presen-ta en la Figura 11. Este modelo físicoestá conformado por una tabla dehechos, y por las entidades en las cua-les se almacenarán los dominios delas dimensiones con sus correspon-dientes niveles jerárquicos.

Figura 11. Modelo lógico en estrella, y modelo físico de la bodega.

Para el proceso de conversión de cadauna de las trayectorias que confor-man el modelo en estrella, en entida-des desnormalizadas, se puede utili-zar uno de los siguientes esquemasde conversión.7

1. Conversión verticalo recursiva

En esta conversión, se utiliza una lla-ve primaria única, para cada dimen-sión. El dominio de esta llave prima-ria se obtiene mediante la unión de

todos los dominios de las entidadesque conforman la trayectoria de ladimensión, es decir, si los dominiosde las entidades que conforman latrayectoria son: {enero, febrero, mar-zo, abril ....}; {1er_trim, 2º_trim,3er_trim, 4º_trim}; {1er_sem,2º_sem}, el dominio de la llave prima-ria será: {enero, febrero, marzo, abril,...., 1er_trim, 2º_trim, 3er_trim,4º_trim; 1er_sem,2º_sem}. En la Fi-gura 12 se presenta, de manera grá-fica, este esquema de conversión.

7. Mcguff, F. Designing the perfect Data Warehouse. 1998.

Page 18: Diseño arquitectonico.pdf

30 SISTEMAS& TELEMÁTICA

Figura 12. Conversión vertical de la trayectoria de una dimensión.

Adicionalmente, en este esquema deconversión a cada valor del dominiose le asocia un valor padre, el cualtambién pertenece al dominio; de estamanera se implementa la jerarquíadefinida en la trayectoria, represen-tada en la dimensión, dentro del mo-delo en estrella.

Este esquema para el manejo de lasjerarquías (id_dimensión, id_padre)permite implementar fácilmente laoperación de desenrolle («drill-down»), cuando se realizan consultasa la bodega de datos. Sin embargo,esta estructura es eficiente, si lasagregaciones para cada nivel jerár-

quico son precalculadas y almacena-das en la bodega.

Este esquema de conversión es el másrecomendado para implementar laestructura física de una bodega, cuan-do las dimensiones están compuestaspor jerarquías desbalanceadas.

2. Conversión horizontalEn esta conversión, la llave primariade la dimensión se conforma comouna llave compuesta por las llaves decada una de las entidades que con-forman la trayectoria de la dimen-sión. En la Figura 13 se presenta, demanera gráfica, este esquema de con-versión.

Figura 13: Conversión horizontal de la trayectoria de una dimensión.

Page 19: Diseño arquitectonico.pdf

31SISTEMAS& TELEMÁTICA

Este esquema de conversión es el másrecomendable, si las agregaciones dedatos se realizan de manera dinámica.

Paso 3:Definición de los atributos queconforman las tablas de hechosy las dimensiones del modelo.

En este paso final, se identifican paracada tabla de hechos y cada dimen-sión las características de los atribu-

tos que conforman cada estructura.Una vez asignados todos los atribu-tos, se realiza un análisis cruzado en-tre la tabla de hechos y las dimen-siones, para establecer los tipos decálculo matemático que pueden serrealizados, sobre la tabla de hechos.

La especificación de los atributos queconforman la tabla de hechos se deberealizar siguiendo el formato que apa-rece en el Cuadro 3.

Cuadro 3: Formato para la definición de los atributosde una tabla de hechos.

Igualmente, para la especificación de los atributos que conforman las dimen-siones se debe utilizar el formato que aparece en el Cuadro 4.

Cuadro 4: Formato para la definiciónde los atributos de una dimensión.

Page 20: Diseño arquitectonico.pdf

32 SISTEMAS& TELEMÁTICA

Finalmente, se deben establecer lostipos de cálculos matemáticos comosuma, conteo, promedio, mínimo,máximo, que pueden ser aplicados alos valores almacenados en las tablas

de hechos. El resultado de esta revi-sión debe quedar consignado en unamatriz de cruce, como la presentadaen el Cuadro 5.

A manera de ejemplo, se presenta en los siguientes cuadros la definición deatributos para la tabla de hechos y para las dimensiones definidas en el ejem-plo anterior, y esquematizadas en la Figura 7.

Tabla de hechos

Atributo 1

Dimensiones Suma Conteo Prom. Mín. Máx.

1. Dimensión a2. Dimensión b3. Dimensión c.....

Atributo 2

Dimensiones Suma Conteo Prom. Mín. Máx.1. Dimensión a2. Dimensión b3. Dimensión c

Atributo 3

Dimensiones Suma Conteo Prom. Mín. Máx.1. Dimensión a2. Dimensión b3. Dimensión c ....

Cuadro 5: Operaciones matemáticaspara cada atributo de la tabla de hechos.

Page 21: Diseño arquitectonico.pdf

33SISTEMAS& TELEMÁTICA

Cuadro 6: Definición de los atributos de la tabla de hechos sobre ventas.

Nombre de la estructura de la bodega Área de ventas

Tabla de hechos Ventas

Atributos tipo Pk DescripciónId lugar C(35) Sí Identif. de la dimensión lugarId tiempo C(12) Sí Identif. de la dimensión tiempoid producto C(30) Sí Identif. de la dimensión productoUnidades vendidas N(8,0) Valor 1 de la tabla de hechosPesos-venta N(10,2) Valor 2 de la tabla de hechos

Cuadro 7: Definición de los atributos de las dimensiones,para la estructura de ventas.

Nombre de la estructura de la bodega

Nombre de la estructura de la bodega

Nombre de la estructura de la bodega

Page 22: Diseño arquitectonico.pdf

34 SISTEMAS& TELEMÁTICA

Cuadro 8: Operaciones matemáticas para cada atributode la tabla de hechos sobre ventas.

Tabla de hechos Ventas

Atributo 1 Unidades vendidas

Dimensiones Suma Conteo Prom Mín MáxLugar ✓ ✓ ✓ ✓

Tiempo ✓ ✓ ✓ ✓

Producto ✓ ✓ ✓ ✓

Atributo 2 Pesos-venta

Dimensiones Suma Conteo Prom Mín MáxLugar ✓ ✓ ✓ ✓

Tiempo ✓ ✓ ✓ ✓

Producto ✓ ✓ ✓ ✓

CONCLUSIÓNMediante la aplicación del enfoque deSistemas para la definición de los in-dicadores claves de gestión de la or-ganización, se ha logrado articularuna propuesta para modelar, de ma-nera ordenada y sistémica, las estruc-turas de las bodegas de datos que ser-virán de soporte a la implementaciónde sistemas de información gerencial,hechos a la medida de las necesida-des de información de la gerencia.Esta propuesta facilita, ordena y sis-tematiza un proceso que en algunas

organizaciones se realiza de maneraintuitiva y, en otras mediante la uti-lización de estructuras de bodegasque han sido definidas para otras or-ganizaciones. El modelo propuesto,que se aparta de muchos de los enfo-ques presentados por los investigado-res en este campo, se convierte en unaopción válida para el diseño de siste-mas de información gerencial, en par-ticular para el diseño de bodegas dedatos departamentalizadas («DataMarts»).

Page 23: Diseño arquitectonico.pdf

35SISTEMAS& TELEMÁTICA

BIBLIOGRAFÍA

• Mcguff, F. Designing the perfectData Warehouse. 1998. http://members.aol.com/fmcguff/dwmo-del/index.htm

• Kimball R. The Data WarehouseToolkit. John Wiley & Sons, 1996.

• Inmon W.H. Building The DataWarehouse. QED Press /JhonWiley, 1992.

• Golfarelli, M; Maio, D; Rizzi, S.Conceptual Design of Data Ware-house From E/R schemes. http//www.csr.unib.it/~golfare/db.html,1998.

• Bahamón, J. H. Construcción deindicadores de gestión bajo el en-foque de sistemas. S&T Revista dela Facultad de Ingeniería, Univer-sidad Icesi. 2003.

• Chuck, B; Dick, H; Don, S; Rhon-da; Eunsaeng, K.; Ann, V. Data

Modeling Techniques for DataWarehouse. IBM. 1998.

• Todman, C. Designing a DataWarehouse: Supporting CustomerRelationship. Prentice Hall. 2001

CURRÍCULO

José Hernando Bahamón L. Inge-niero Electrónico de la Universidaddel Cauca, especialista en Adminis-tración de la Universidad Icesi y ma-gíster en Dirección Universitaria dela Universidad de los Andes. Profe-sor investigador de la UniversidadIcesi. Vinculado a la Universidad Ice-si desde 1988. Ha sido jefe del Depar-tamento Académico de Sistemas(1988-1998), Director del programade Ingeniería de Sistemas (1998-2000), y en la actualidad es el Direc-tor Académico de la Universidad.

Page 24: Diseño arquitectonico.pdf

36 SISTEMAS& TELEMÁTICA