CAITU LO

de esto, no ha; duplicacin de funciones. Mejor an, el almacn de datos maneja el componente de datos en forma ms eficiente sr; el OLAP, de modo que se pueden apreciar los beneficios detener un almacn central que sirve como la base de da::* para el soporte de decisiones de una empresa grande.

de datos normalmente proporciona. De hecho, cuando se implementa en forma apropiada, el almacn de datos ejec.;= todas las funciones de preparacin de datos en lugar de permitir que el OLAP lo hagi; como resultado

Para dar un mejor desempeo, algunos sistemas OLAP fusionan los mtodos del almacn y el mercado de datos , guardar pequeos extractos del almacn en estaciohes de trabajo del usuario final. El objetivo es aumentar la rapicz: de acceso y visualizacin de datos (las representaciones grficas de tendencias y caractersticas de los datos). La log,:: que hay detrs de ese mtodo es la suposicin de que casi todos los usuarios finales, por lo general, trabajan.on i".conjuntos de datos estables del almacn, ms bien pequeos. Por ejemplo, lo ms probable es que un analista de ver.=s trabaje con datos de ventas, mientras que un representante de clientes Io haga con datos de clientes. La figura 13 :
ilustra esta situacin.

fIGURA

13.9

Sistema OLAP

"Motor" OIAP
compartido

@m
\#PEI
@
\ffi&
,.'***.*-:'t

Mercados locales de datos

Mltiples usurios
tienen acceso al mo-

tor OLAP

Cualquiera que sea el arreglo de los componentes OLAP, una cosa es segura: deben usarse datos multidimensionales. Pero, cmo se guardan y almacenan mejor estos datos? Quienes proponen el OLAP estn muy dididos; algunos estn a favor del uso de bases relacionales para guardarlos; otros estn por Ia superioridad de las tases de datos multidimensionales especializadas para guardar datos multidimensionales. Las caractersticas bsicas de cada mtodo se examinan a continuacin.

INTELIGENCIA

DE NEGOCIOS Y ALMACENES

DE DATOS

s37

EEEtr oto" *tto"'o*ot

El procesarniento analtico en lnea relacional (ROLA'P) establece la funcionalidad OLAP al usar bases de datos relacionales y herramientas de consulta relacionales conocidas para guardar y analizar datos multidimensionales.
Ese mtodo se construye sobre tecnologas relacionales existentes y representa una extensin natural para todas las compaas que ya usan sistemas relacionales de administracin de bases de datos dentro de sus organizaciones. El ROLAP agrega las siguientes extensiones a la tecnologa RDBMS tradicional: . Soporte a esquemas de datos multidimensionales dentro del RDBMS. ' Lenguaje de acceso a datos y desempeo de consulta optimizados para datos multidimensionales. o Soporte para bases de datos muy grandes (VLDB).

Soporte a esquerna cle datos multiclimensionales dentro del RDBMS

La tecnologa relacional usa tablas normalizadas para guardar datos. La seguridad en normalizacin como metodologa de diseo para bases de datos relacionales se ve como un bloque tambaleante para su uso en sistemas O[AP. La normalizacin divide entidades de negocios en partes ms pequeas para producir las tablas normalizadas. Por ejemplo, los componentes de datos de ventas podran estar guardados en cuatro o cinco tablas. La raz6n para usar tablas normalizadas es reducir redundancias, con lo cual se eliminan anomalas de datos y se facilitan actualizaciones de datos. Desafortunadamente, para fines de soporte de decisiones, es ms fcil entender datos cuando se ven con respecto a otros datos. (Vase el ejemplo de la figura 13.5.) Dada esta vista del ambiente de los datos, este libro ha hecho nfasis en que los datos de soporte de decisiones tienden a ser no normalizados, duplicados y agregados preamente. Esas caractersticas parecen imposibilitar el uso de tcnicas estndar de diseo relacional y los RDBMS como fundamento para datos multidimensionales.

Por fortuna para quienes han hecho fuertes inversiones en tecnologa relacional, el ROIAP usa una tcnica especial de diseo para hacer posible que la tecnologa RDBMS soporte representaciones de datos multidimensionales. Esta tcnica especial de diseo se conoce como esquema en estrella, el cual se estudia en detalle en la seccin 13.7.
El esquema en estrella est diseado para optimizar operaciones de consulta ms que de actualizacin de datos. Naturalmente, cambiar el fundamento para diseo de datos significa que las herramientas empleadas para tener acceso a esos datos tendrn que cambiar. Los usuarios finales familiarizados con las herramientas tradicionales para consulta relacional descubrirn que esas herramientas no trabajan de manera eficienfe con el nuevo esquema en estrella. No obstante, el ROLAP salva el da al agregar soporte para el esquema en estreila cuando se usan herramientas de consulta conocidas. El ROLAP proporciona funciones avanzadas para anlisis de datos y mejora la optimizacin de consultas y los mtodos de visualizacin de datos.

Lenguaje de acceso a datos y desempeo de consulta optimizados para datos multidirnensionales

Otra crtica de las bases de datos relacionales es que el SQL no est adaptado para efectuar anlisis avanzado de datos. Casi todas las solicitudes de datos de soporte de decisiones requieren el uso de consultas de SQL de pasos mltiples o de enunciados SQL anidados mltiples. Para contestar esta crtica, el ROLAP extiende el SQL para que pueda disnguir entre requisitos de acceso para datos de almacn de datos (basados en el esquema en estrella) y datos operacionales (tablas normalizadas). En esa forma, el sistema ROLAP es capaz de generar el cdigo requerido de SQL para tener acceso a los datos del esquema en estrella.
El desempeo de consulta tambin se mejora porque el optimizador de consultas se modifica para identificar los objetivos de consulta buscads por el cdigo de SQL. Por ejemplo, si el objetivo de consulta es el almacn de datos, el optimizador le pasa las solicitudes. No obstante, si el usuario final ejecuta consultas de bajada contra datos operacionales, el optimizador de consulta identifica esa operacin y optimiza correctamente las solicitudes de SQL antes de'pasarlas por el DBMS operacional.

Otra fuente de desempeo mejorado de consulta es el uso de tcnicas avanzadas de indizacin, como los ndices de mapas de bits dentro de bases de datos relacionales. Como su nombre lo sugiere, un ndice de mapa de bits se basa en bits 0 y 1 para representar una condicin dada. Por ejemplo, si el atributo REGION de la figura 13.3 tiene slo cuatro resultados (Norte, Sur, Este y Oeste), pueden estar representados como se observa en la tabla 13.9. (Slo los primeros 10 renglones de la figura 13.3 estn representados en la tabla 13.9. El " 1 " representa "bit activado " y el " 0" representa "bit desactivado". Por ejemplo, para representar un rengln con un atributo REGION : "Este". slo el bit "Este" estar activado. Ntese que cada rengln debe estar representado en la tabla del ndice.)

c'ApJ,?uro rj

Ntese que el ndice de la tabla 13.9 toma una cantidad mnima de espacio. por tanto, los ndices de mapa de bits son ms eficientes en el manejo de grandes cantidades de datos de lo que son los ndices qu" po. lo general se encuentran en muchas bases de datos relacionalesl pe.o ,e.u".dn que los ndices de mapas de bits se usan principalmente en situaciones donde el nmero de posibles valres puru ,., ut.iluto (en otras palabras, el dominio del atributo) es bastante pequeo. por ejemplo, REGION tiene slo cuatro resultado. Ln este ejemplo. El estado civil, es decir casado, soltero, ,irao, iuo..iuao. sera otro buen candidato para ndice de mapa de bits, como lo sera el gnero: M o F.
Las herramientas ROLAp son principalmente productos clien_ te/servidor en las que la interfaz de usuario flnal, el procesa_ miento analtico y el procesamiento de datos

tienen lugar en diferentes computadoras. La figura 13.10 muesi.a la interaccin de los componentes ROLAp cliente,/servidor-

FIGURA

13.10

ervidor ROI_Ap

El

servidor ROLAP interpreta

y construye complejas

consultas de usuario final consultas de SeL requeridas para tener acceso al almacn de datos. Si un usuario finat pide una operacin de bajar, el_ servidor ROLAp construye

el cdigo requerido de Set para tener acceso a la base de datos operacional.

La GUI frontal se ejecuta en la computadora cliente y pasa solicitudes de anlisis d atos al sevidor ROLAP La Gui'recibe respuestas de datos del servidor ROLAP y les da formato de acuerdo con las necesidades de presentacin del usuario finat.

Soporte para bases de datos muy grandes

Recuerde que el soporte para las VLDB es un reqsito de bases de datos para soporte de decisiones. por tanto, cuando la base de datos relacional se usa en una funcin " sopo.t" de decisiones, tambin debe ser capazdeguardar cantidades

= =
INf ELIGENCA DE NEGOCIOS Y ALMACENES DE DATOS
539

.,c 'rG

actividad.

muy grandes de datos. La capacidad de almacenamiento y el proceso de carga de datos en la base de datos son de importancia decisiva. Por tanto, el RDBMS debe tener las herramientas apropiadas para importar, integrar y poblar el almacn con datos' Los datos para soporte de decisiones se cargan normalmente en modo granel (lote) a desde los datos operacionales. No obstante, las operaciones en lote requieren que las bases de datos fuente"y destino se reserven (bloqueen). La velocidad de las operaciones de carga de datos es importante, en especial cuando se ve que casi todos los sistemas operacionales funcionan 24 horas al da, 7 das a la semana, 52 semanas al ao. por tanto. la ventana de oportunidad para mantenimiento y carga de lotes se qbre slo brevemente, por lo general durante periodos de poca

Con una arquitectura cliente/servidor abierta, el ROLAP ofrece funciones avanzaclas para soporte de decisiones que son escalables a toda Ia compaa. Claramente, el ROLAP es una opcin lgica para compaas que ya usan baies de datos relacionales para sus datos operacionales. Daclo el tamao del mercaclo de bases cle datos relacionales, no es de sorprender que casi todos los vendedores actuales de RDBMS hayan extendido sus productos para soportar
almacenes de datos.

EEE

"t.,,,4uLrrDrMENsroNAEl procesamiento analtico multidimensional en lnea (MOLAP) extiende la funcionalidad del OLAp a los sistemas de administracin de bases de datos multidimensionales (MDBMS). (Un MDBMS usa tcnicas
es que las bases de datos multidimensionales estn mejor adaptadas para administrar guardar y analira, datos multidimensionales. Casi todas las tcnicas patentadas que se usan en los MDBMS se derivan de los iampos de la ingeniera por ejemplo, el diseo asistido por computadora o la manufactura asistida por computadora (CAD/bAM) y sistemas de informacin geogrfica (GIS).

especiales patentadas para guardar datos en arreglos de dimensiones n parecidos a matrices.j La premisa del MOLAp

Conceptualmente, los usuarios finales del MDBMS ven los datos guardados como un cubo tridimensional conocido como cubo de datos. El lugar de cada valor de datos del cubo es una funcin de los ejes x, y y z, en un espacio tridimensional. Esos ejes representan las dirrensiones del valor de los datos. Los cubos de datos pueden crecer a n nmero de dimensiones, convirtindose as en hipercubcts. Los cubos de datos se crean al extraer datos de las bases de datos operacionales o del almacn de datos. Una caracterstica importante de los cubos es que son estticos; esto es, no estn sujetos a cambios y deben ser creados antes de que se puedan usar. Los cubos de datos no pueden ser creados por consultas ad hoc. En cambio, se pueden consultar cubos creados previamente con ejes definids; por ejemplo, un cubo para ventas tendr dimensiones de producto, de lugar y de tiempo y se pueden consultar slo esas dimensiones. Por tanto, el proceso de creacin del cubo de datos es crtico y requiere trabajo de diseo a fondo del elemento frontal. El trabajo de diseo del elemento frontal puede estar bien justificaclo porque se sabe que las bases de datos MOLAp son mucho ms rpidas que sus similares ROLAP, en especial cuando se trata con conjuntos de datos de tamao pequeo a mediano. Para acelerar el acceso a los datos, los cubos se mantienen en memoria en lo que se denomina cach de cubo. (Un cubo de datos es slo una ventana para un subconjunto predefinido de datos d la base de datos. Un cuto de datos y una bose de datos no son lo mismo.) Como el MOLAP tambin se beneficia de una infraestructura cliente/ servidor' el cach de cubo se puede localizar en el servidor MOLAP, en el cliente MOLAP, o en ambos lugares. La figura 13.11 muestra la arqr.iitectura bsica del MOLAP. Como el cubo de datos est predefinido con un nmero establecido de dimensiones, la adicin de una n,eva dimensin requiere que todo ei cubo sea recreado. Este proceso de recreacin es lento. Por tanto, cuando cubos de datos sean creados con demasiada frecuencia. el MDBMS pierde parte cle su ventaja en velociclad sobre la base de datos relacional. Y aunque los MDBMS tengan ventajas de operacin sobre las bases de datos relacionales. estn mejor adapiadas para conjuntos de tamao mediano y pequeo. La escalabilidad es un tanto limitada porque el tamao del cubo de datos est restringido para evitar largos tiempos de acceso a datos causados por tener menos espacio de trabajo (memoria) disponible para el sistema operativo y ios programas de apiicacin. Aciems. el MDBMS hace uso de tcnicas patentadas de almacenatriento de datos que. a stlvez, requieren mtodos patentaclos de acceso a los datos que usan un lenguaje de consulta multidimensionai.
El anlisis de datos multidimensional iambin es afectado por la forma en que el sistema de base de datos maneia la dispersin. La dispersin es una medida de la densidad de los datos contenidos en el cubo de datos; se calcula al dividir el nmero total de vaiores reales en el cubo entre e|nmero toial de celdas en 1. Debido a que las dimensiones del cubo estn predefinidas, no todas las celdas estn pobladas, algunas estn vacas. Regresando al ejemplo de ventas, puede haber muchos productos que no se venden durante un lapso determinado en un lugar dado. De hlcho, con irecuencia se encontrar que menos de 50% de las celdas del cubo de daios estn pobladas. En cualquier caso, las bases de datos los gastos generales y las necesidades de recursos.

multidimensionales deben manejar con eficiencia la dispersin para reducir cle manera eficiente el procesamiento de

EEE o,r.^",o*.'
Las dimensiones son caractersticas calificadoras que dan perspectivas adicionales a un hecho determinado. Rec-ryde que las dimensiones son de inters porque los dofos para soporte de decisiones son cosi siempre uisos en relcc:.:. con otros datos. Por ejemplo, las ventas podran compararse por producto de una regin a otra y de un perioc: a siguiente. La clase de problema que por lo general se resuelve con un sistema de BI podra ser el hacer una compara:,rde las ventas de la unidad X por regin para los prirneros trimestres de 2000 al 2010. En ese ejemplo, las ventas era". dimensiones de producto, lugar y tiempo. En efecto, las dimensiones son la lente de aumento por medio de la cu- s estudian los hechos. Estas dimensiones normalmente se guardan en tablas de dimensin. La figura 13.12 de,cc:i:ts un esquema en estrella para ventas con dimensiones de producto, lugar y tiempo.

FIGURA

13.12

EEE or*,'r'o=
Cada tabla de dimensin contiene atributos. A veces los atributos se usan para busca filtrar o clasificar hechos. Lcs dimensones dan caractersticas descriptioas acerca de los hechos por medo de sus atributos. Por tanto, el diseador de un almacn de datos debe definir atributos comunes de negocios que sern usados por el analista de datos par= estrechar una bsqueda, informacin de grupo o describir dimensiones. Usando un ejemplo de ventas, algunos atribuic= posibles para cada dimensin se ilustran en la tabla 13.11. TAB-A "g 3."8 ?

Lugar

Regin, estado, ciudad, tienda, etctera.

Producto

I l I
I

L-

Cualquier cosa que d una descripcin del producto vendido. Por ejemplo, producto para el cuidado del cabello, champ, marca de e!9t9te-!3!9,a!, ,! q!2q9,

q9!9-Ig:-1gg'9g:g-

Tipo de producto, lD de producto, marca, paquete, presentacin, color, tamao, etctera.

: ]

INf ELIGENCIA

DE

NEGOCIOS Y ALI,'ACENES

D:

DATOS

5.43

'Etf-A
"c3""ff"9

Fstas dimensiones de producto, lugar y tiempo agregan una perspectiva a los hechos de ventas. El analista de datos ahora puede agrupar las cifras cle ventas para un proucto deier-inado, en una regin y en un tiempo determinados. El esquema en estrella, por medio de sus hechos y dimensiones, puede dar los datts en el formato requerido cuando se necesiten Y puede hacerlo as sin imponer la carga de datos adicionales e innecesarios (por ejemplo, nmero de pedido, nmero de orden de compra y situacin) que por lo general existen en bases de datos opecionales.

tridimensional facilita visualizar el problema. En este ejemplo tridimensional, la trminologiu " unlirl, de datos multidimensionales. el cubo ilustrado en la figura 13.13 repreienta una vista de ventas dimensionada por producto. lugar y tiempo.

das a una tabla de hechos' No hay lmite matemtico al nmero de dimensiones que se usen! pero emplear un modelo

Conceptualmente, el modelo de datos multidimensional del ejemplo de ventas est mejor representado por un cubo tridimensional Desde luego, esto no implica que haya un lmite en el nmero de dimensnes que

puedun estar asocia-

FIGURA

13.13

Cubo conceptual tridimensional de ventas por producto, lugar

y

tiempo

Los hechos de ventas se

guardan en la interseccin de cada dimensin de producto, tiempo y lugar

observe que cada uno de los valores de ventas guardados en el cubo de la figura 13.13 est asociado con las dimensiones de lugar, producto y tiempo. No obstante, recuerde que este cubo es slo una representac" r;:r;;;ri;;;:" datos multidimensionales y no muestra el modo en que ios datos se guardan fsicamente en un almacn de datos. Un motor de ROLAP guarda datos en un RDBMS y emplea su propia lo"gica de anlisis de datos v u ui de usuario final para ejecutar anlisis multidimensional. Un sistema MOLAP guarda dltos en un MDBMS, us.,do matriz patentada y tecnologa de arreglo (matriz) para simular este cubo multidirnnsional.
Cualquiera que sea la tecnologa de base de datos fundamental, una de las principales caractersticas del anlisis multidimensional es su capacidad para concentrarse en "rebanadas" especficas dll cubo. por ejemplo. el gerentede producto puede estar interesado en examinar las ventas de un producto, al tiempo que el gerente de la tienda est interesado en examinar las ventas hechas por una tienda particular. En trminos multidimensionales, la capacidad de concentrarse en rebanadas del cubo para ejecutar un anlisis ms detallado se conoce como rebanada y dado. La figura 13.14 ilustra

el concepto de rebanada y dado. Al ver la figura 13.14, ntese que cada corte horizontal del cubo da una rebanada. L-a: rebanadas que se cruzan producen pequeos cubos que constituyen la parte "dado" de la operacin "rebanada y dacio-

FIGURA

13.14

Vista de datos de ventas det gerente de ventas

Vista de datos de ventas del gerente de producto

Para tener una rebanada y un dado, debe ser posible identificar cada rebanada del cubo. Esto se hace usando los vai::.r: de cada atributo en una dimensin determinada. Por ejemplo, para usar la dimensin de lugar podra ser necesa:-r: definir un atributo STORE_iD, para concentrarse en una tienda particular. Dada la necesidad de valores de atributo en un ambiente de rebanada y dado, volvamos a examinar Ia tabla 13.11. tese que cada atributo agrega una perspectiva adicional a los hechos de ventas, poniendo as el escenario para encor.::rnuevas formas de buscar, clasificar y posiblemente agregar informacin. Por ejemplo, la dimensin de lugar agra" una perspectiva geogrfica de donde tuvo lugar la venta: en qu regin, estado, ciudad, tienda, etc. Todos los an'ib,-* tos son seleccionados con el objetivo de dar datos de soporie de decisiones a usuarios finales para que puedan e---* diar ventas por cada uno de los atributos de la dimensin. EI tiempo es una dimensin especialmente importante. La dimensin de tiempo brinda un marco del que se pueia-analizar patrones de ventas y posiblemente predecirlos. Tambin, la dimensin de tiempo desempea un importar.:; papel cuando el analista de datos est interesado en ver agregados de ventas por trimestre, mesr semana, etc. Dada importancia y universalidad de la dimensin del tiempo desde una perspectiva de anlisis de datos, numerosos vendei:res han agregado a sus productos de almacn de datos las funciones automticas para administracin de la dimensi:. del tiempo.

\:*

EEEtr
tos

Jenaneues

DE

ATRIBUT.'

Los atributos dentro de dimensiones pueden ser ordenados en una jerarqua bien definida. La ierarqua de atribuda una organizacin de datos de arriba hacia abajo que se usa para dos fines principales: anlisis parahgregar'.' bajarubir datos. Por ejemplo, la figura 13.15 muestra la forma en que los atributos de la dimensin de lugar se pueder organizar en una jerarqua por regin, estado, ciudad y tienda. La jerarqua de atributos da la capacidad de ejecutar bsquedas de bajar y subir en un almacn de datos. Suponga que un analista de datos ve las respuestas a la consulta: Cmo se compara la operacin de ventas de 2009 de un mes a la fecha con la operacin de ventas de 2010 de un mes a la fecha? El analista de datos observa una aguda baja en ventas para marzo de 2070. El analista de datos podra decidir bajar dentro del mes de marzo para ver cmo se comparan las ventas por regiones con respecto al ao previo. Al hacerlo as, el analista puede determinar si las bajas ventas en marzo se reflejaron en todas las regiones o slo en una regin particular. Este tipo de operacin de bajar puede incluso extenderse hasta que el analista identifique la tienda que est operando debajo de 1o normal.

INTELIGENCIA

DE NEGOCIOS Y ALI{ACENES

DE DATOS

FIGURA

13.15

[a jerarqua de atributos permite al usuario final realizar

bsquedas de subir y bajar

cripciones narrativas de las dimensiones. pero recuerde que los atributos de diferentes dimensiones pueden agruparse para formar una jerarqua. Por ejemplo, despus qr bu;u de ciu_ dad a tienda. podra usted bajar usando la dimensin de pro_ ducto para que el gerente pueda identificar productos lentos en la tienda. La dimensin de producto puede estar basada en el grupo de productos (lcteos, carnes, etc.) o en la marca de productos (marca A, marca B, etctera).

La situacin de ventas de marzo es posible porque la jerarqua de atributos permite al almacn de datos y ri.t"-u, OLAp te_ ner una va definida que identificar la forma en que los datos se han de descomponer y agregar para operaciones de subir y bajar. No es necesario que todos los atributos sean parte de una jerarqua de atributos; algunos existen slo para dar des-

de producto, tiempo y lugar. En este ejemplo, la dimensin de producto se establece en "Todos los productos", lo cual significa que el analista ver todos los productos en el eie y. fa dimensin de tiempo (eje x) est establecida para "Trimesire", lo cual significa que los datos son ug.nguao, por trimestres (por ejemplo, ventas totales de los productos A, B y c en eITt,TV,T3 y T4). por ltimo, lJdimensin de lugar est inicialmente fijada en "Regin", asegurando as que cada una de las celds contenga el total de ventas regionales para un producto determinado en un trimestre determinado.

datos estudia hechos de ventas, usando las dimensiones

La figura 13.16 ilustra una situacin en la que el analista de

datos dL variante en tiempo en diferentes niveles de agregacin: ao, trimestre! mes o semana. Cada valor de ventas inicialmente muestra el total de ventas, por regin, de cada producto. Cuando se usa una GUI, hacer clic en la celda de regin hace posible que el analista de datos baje para ver ventas por estados dentro de la regin. Dar un clic otra vez en node los valores de estado da las ventas por cada ciudad en el estado y as sucesivamente.

La sencilla situacin de anlisis de datos ilustrada en la figura 13.16 suministra al analista de datos tres vas de informacin' En la dimensin de productos (el eje y), el analista puede pedir ver todos los productos, productos agrupados por tipo, o slo un producto. En la dimensin de tiempo (el eje x), el analista puede pedi,

Como se ilustra en los ejemplos precedentes, las jerarquas de atributos determinan la forma en que los datos del almacn de datos son extrados y presentados. La informacin de jerarqua de atributos se guarda n el diccionario de datos del DBMS y es usado por la herramienta OLAP para tener u..nro .o.r".tamente al almacn. l)na vezasegurado este acceso, las herramientas de consulta deben integrarse de manera estrecha con los metadatos del almacn y deben dar soporte a las potentes capacidades analticas.

EEI

*."

otras numerosos renglones de hechos estn relacionados con cada uno de los renglones de dimensin. Usando el ejemplo de ventas. se puede concluir que cada producto aparece muchas veces en la tabla de hechos SALES o/ENTAS).

Los hechos y las dimensiones normalmente son representados por tablas fsicas en la base de datos del almacn. La tabla de hechos est relacionada con cada tabla de dimensiones en una relacin de muchos a uno (M:1). En palabras,

Las tablas de hechos y dimensiones estn relacionadas por llaves forneas y estn sr-rjetas a las ya conocidas reqtricciones de llave primaria/llave fornea. La llave primara en el lado "1", la tabL de dimensin, est guardada como parte de la llave primaria en el lado "muchos", la tabla de hechos. Debid,o a que la tabla de hechos est relacionada con muchas tablas de dmensin, la llaue primara de la tabla d.e datos es prmara compuesta. La figura 13.17 ilustra las relaciones entrela tabla de hechos de ventas y las tablas de dimensiones de product, lugar y tipo. para mostrar al lector cmo se puede expandir fcilmente el esquema en estrella, una dimensin cliente se ha agregado a la combinacin Agregar la dimensin cliente slo requiri incluir la CUST-ID en la tabla de hechos SALE y agregar la tabla CUSTOMER a la base de datos. La llave primaria compuesta para la tabla de hechos SALES est formada por TIME_ID, Loc-lD, cusT*lD y pRoD_lD. Cada registro de la tabla de hechos SALES est identificado de manera nica por la combinacin de valores de cada una de las llaves forneas de la tabla de hechos. Por det'ault, la llaue prmaria de la tabla d.e hechos sempre
se

el concepto de rebanada y dado. Al ver la figura 13.14, ntese que cada corte horizontal del cubo da una rebanada, r-x rebanadas que se cruzan producen pequeos cubos que constituyen la parte "dado" de la operacin "rebanada y da::-

FICURA

13.14

Vist de datos de ventas del gerente de ventas

Vista de datos de ventas del gerente de producto

Para tener una rebanada y un dado, debe ser posible identificar cada rebanada del cubo. Esto se hace usando los rz,_s de cada atributo en una dimensin determinada. Por ejemplo, para usar la dimensin de lugar podra ser nece-ia-"{: definir un atributo STORE_ID, para concentrarse en una tienda particular. Dada la necesidad de valores de atributo en un ambiente de rebanada y dado, volvamos a examinar Ia tabla 13.11 tese que cada atributo agrega una perspectiva adicional a los hechos de ventas, poniendo as el escenario para enc3:-:a

l':-

nuevas formas de buscar, clasificar y posiblemente agregar informacin. Por ejemplo, la dimensin de lugar ag:=,,.e una perspectiva geogrfica de donde tuvo lugar la venta: en qu regin, estado, ciudad, tienda, etc. Todos los a=:-tos son seleccionados con el objetivo de dar datos de soporte de decisiones a usuarios finales para que puedar: er-diar ventas por cada uno de los atributos de la dimensin.

El tiempo es una dimensin especialmente importante. La dimensin de tiempo brinda un marco del que se pua:r analizar patrones de ventas y posiblemente predecirlos. Tambin, la dimensin de tiempo desempea un impor,:--.: papel cuando el analista de datos est interesado en ver agregados de ventas por trimestre, mes, semana, etc. Dai= .e importancia y universalidad de la dimensin del tiempo desde una perspectiva de anlisis de datos, numerosos venie-::res han agregado a sus productos de almacn de datos las funciones automticas para administracin de la dimer.=:rdel tiempo.

Effi

.*o*.r1""j. "II1yr""

Los atributos dentro de dimensiones pueden ser ordenados en una jerarqua bien definida. La jerarqua de atrib+ tos da una organizacin de datos de arriba hacia abajo que se usa para dos fines principales: anlisis para'agrega:'" bajarubir datos. Por ejemplo, la figura 13.15 muestra la forma en que los atributos de la dimensin de lugar se puedr, organizar en una jerarqua por regin, estado, ciudad y tienda.

La jerarqua de atributos da la capacidad de ejecutar bsquedas de bajar y subir en un almacn de datos. Spong=
que un analista de datos ve las respuestas a la consulta: Cmo se compara la operacin de ventas de 2009 de un mes : la fecha con la operacin de ventas de 2010 de un mes a la fecha? El analista de datos observa una aguda baja en venta. para marzo de 2010. El analista de datos podra decidir bajar dentro del mes de marzo para ver cmo se comparrlas ventas por regiones con respecto al ao previo. Al hacerlo as, el analista puede determinar si las bajas ventas e:. marzo se reflejaron en todas las regiones o slo en una regin particular. Este tipo de operacin de bajar puede inclusj extenderse hasta que el analista identifique la tienda que est operando debajo de lo normal.

INfELIGENCIA

DE NGOCIOS Y ALI,4ACENES DE DATOS

545

:'-#

FICURA

13.15

[a jerarqua de atributos permite al usuario final realizar

bsquedas de subir y bajar

La situacin de ventas de marzo es posible porque la jerarqua de atributos permite al almacn de datos y sistemas OLAp tener una va definida que identificar la forma en que los datos se han de descomponer y agregar para operaciones de subir y bajar. No es necesario que todos los atributos sean parte de una jerarqua de atributos; algunos existen slo para dar descripciones narrativas de las dimensiones. pero recuerde que los atributos de diferentes dimensiones pueden agruparse para formar una jerarqua. Por ejemplo, despus que baje de ciudad a tienda, podra usted bajar usando la dimensin de producto para que el gerente pueda identificar productos lentos en la tienda. La dimensin de producto puede estar basada en el grupo de productos (lcteos, carnes, etc.) o en la marca de productos (marca A, marca B, etctera).

La figura 13.16 ilustra una situacin en la que el analista de

datos estudia hechos de ventas, usando las dimensiones

de producto, tiempo y lugar. En este ejemplo, la dimensin de producto se establece en "Todos los productos", lo cual significa que el analista ver todos los productos en el eje y. La dimensin de tiempo (eje x) est establecida para "Trimestre", lo cual significa que los datos son agregados por trimestres (por ejemplo. ventas totales de los productos A, B y C en eIT7, T2, T3 y T4). Por ltimo, h aimensin de lugar est inicialmente fijada en "Regin", asegurando as que cada una de las celdas contenga el total de ventas regionales para un producto determinado en un trimestre determinado.

La sencilla situacin de anlisis de datos ilustrada en la figura 13.16 suministra a[ analista de datos tres vas de informacin. En la dimensin de productos (el eje y), el analista puede pedir ver todos los productos, productos agrupados por tipo, o slo un producto. En la dimensin de tiempo (el eje x), el analista puede pedir datos de variante en tiempo en diferentes niveles de agregacin: ao, trimestre, mes o semana. Cada valor de ventas inicialmente muestra el total de ventas, por regin, de cada producto. Cuando se usa una GUI, hacer clic en la celda de regin hace posible que el analista de datos baje para ver ventas por estados dentro de la regin. Dar un clic otra u", nn rno de los valores de estado da las ventas por cada ciudad en el estado y as sucesivamente.

este acceso, las herramientas de consulta deben integrarse de manera estrecha con los metadatos del almacn v deben dar soporte a las potentes capacidades analticas.

Como se ilustra en los ejemplos precedentes. las jerarquas de atributos determinan Ia forma en que los datos del almacn de datos son extrados y presentados. La informacin de jerarqua de atributos se guarda n el diccionario de datos del DBMS y es usado por la herramienta OLAP para tener acceso correctamente al almacn. l)na vez asegurado

EEE

*-"n.seN*crN

DE ESo,EMA EN E.TRELLA

numerosos renglones de hechos estn relacionados con cada uno de los renglones de dimensin. Usando el ejemplo de ventas, se puede concluir que cada producto aparece muchas veces en la tabla de hechos SALES (VENTAS).

Los hechos y las dimensiones normalmente son representados por tablas fsicas en la base de datos del almacn. La tabla de hechos est relacionada con cada tabla de dimensiones en una relacin de muchos a uno (M:1). En otras palabras,

est relaconada con muchas tablas de dmensin, la llaue primara de la tabla de datos es primara compuesta. La figura 13.17 ilustra las relaciones entre la tabla de hechos de ventas y las tablas de dimensionls de producto, lugu. y tiempo. para mostrar al lector cmo se puede expandir fcilmente el esquema en estrella, una dimensin cliente se ha agregado a la combinacin. Agregar la dimensin cliente slo requiri incluir la CUST-ID en la tabla de hechos SALES y agregar la tabla CUSTOMER a la base de datos.
La llave primaria compuesta para la tabla de hechos SALES est formada por TIMF ID, LOC_ID, CUST_ID y pROD-lD. Cada registro de la tabla de hechos SALES est identificado de manera nica por la combinacin de valores de cada una de las llaves {orneas de la tabla de hechos. Por default, la liaue primaria de la tabla d.e hechos sempre se

Las tablas de hechos y dimensiones estn relacionadas por llaves forneas y estn sr-rjetas a las ya conocidas restricciones de llave primaria,/llave fornea. La llave primara en el lado "1", 1a tabia de dimensin, est guardada coml parte de la llave primaria en el lado "muchos", la tabla de hechos. Debido a que la tabla de hechos

ifiPiiliF,r,t"rlt

rc

lrt

FIGURA

13.16

Producto A

Producto B Prodtclo C

''.,..,'
':--.i:r.

Total de

trimestres

i
I

forma al combnar las llaues t'orneas que apuntan a las tablas de dmensin a las que est.n relacionodos. En r caso, cada uno de los registros de ventas representa cada producto vendido a un cliente especfico, en un tierrp: ,lugar especficos. En este esquema, la tabla de dimensin TIME (TIEMPO) representa periodos diarios, de modo que = tabla de hechos SALES representa ventas diarias agregadas por producto y cliente. Debido a que las tablas de heci,..
contienen los valores reales empleados en el proceso de soporte de decisiones, estos valores se repiten muchas ve:s en esas tablas. Por tanto, las tablas de hechos siempre son los hechos ms grandes del esquema en estrella. Comc .=s tablas de dimensin contienen slo informacin no repetitiva (todos los vendedores nicos, todos ios productos nic:= etc.), siempre son ms pequeas que las de hechos. En un esquema en estrella tpico, cada registro de dimensin est relacionado con miles de registros cle hechos. P:: ejemplo, "accesorio'' apatece slo una vez en la dimensin de producto, pero tiene miles de registros correspopdientes e:: la tabla de hechos SALES. Esta caracterstica ciei esquema en estrella facilita las funciones de recuperacin de darc. casi todo el tiempo que el analista de datos vea los hechos por medio de los atributos de la dimensin. Por tanto. ,;. DBMS de almacn de datos que est optimizado para soporte de decisiones primero busca las tablas ms pequeas c; dimensin antes de tener acceso a tablas ms grandes de hechos. Los almacenes de datos por lo general tienen mnchas tablas de hechos. Cada una de ellas est diseada para respo: der preguntas especficas para soporte de decisiones. Supongamos que usted desarroll un nuevo inters en pedidos a mismo tiempo que mantena su inters original en ventas. En esa situacin, debe mantener una tabla de hechos ORDERS y una SALES en el mismo almacn de datos. Si los pedidos son considerados como de inters clave para una organizacin, la tabla de hechos ORDERS debe ser el centro de un esquema en estrella que pueda tener dimensiones Ce vendedor, producto y tiempo. En ese caso, un inters en vendedores da una nueva dimensin de vendedor, representada

INTELIGENCIA

DE NEGOCIOS Y ALMACENES

DE DATOS

:G

FIGURA

13.17

25 registros 365 registros

PROD 3O00O0O records

Agregados de ventas
1

25 registros

diarias por tienda, cliente y producto

30OO registros

por una nueva tabla VENDOR en la base de datos. La dimensin de producto est representada por la misma tabla de productos que se emplea en el esquema en estrella inicial de ventas. No obstante, dado el inters en pedidos as corno en ventas. la dimensin de tiempo ahora requiere atencin especial. Si el departamento de pedidos usa los mismos periodos que el departamento de ventas, el tiempo puede estar representado por la misma tabla de tiempo. Si se usan diferentes periodos. debe crearse otra tabla, quiz de nombre ORDER,TIME. para representar los periodos empleados por el departamento de pedidos. En la figura 13.18, el esquema en estrella de pedidos comparte las dimensiones de producto, vendedor y tiempo.
Tarnbin pueden crearse mltiples tablas de hechos por razones de operacin y semnticas. La siguiente seccin explica varias tcnicas para mejoiar ei desempeo y que pueden usarse dentro dei esquema en estrella.

548

CAPfTULO

I3

FIGURA

13.18

85000 registros
Agregadas de ventas

365 registros

diarias por productos y vendedor VEND ID

,VEND-AREACODE

50 registros

ffi

TcNrces .ARA MEJ.RAR EL DEsErrpeo EN EL EseuEMA EN

ESTRELLA

La creacin de una base de datos que proporcione respuestas rpidas y precisas a consultas de anlisis de datos es " principal propsito del diseo de un almacn de datos. Por tanto, las acciones para el desempeo podran tener cor:: ob;etivo Iarapidez de consulta, por medio de facilitar el cdigo de SQL y mediante una mejor representacin semn--:: de las dimensiones de negocios. Estas cuatro tcnicas con frecuencia se usan para optimizar el diseo de un almacn :=
datos:

. . . .

Normalizartablasdimensionales. Mantener mltiples tablas de hechos para representar diferentes niveles de agregacin. Desnormalizar tablas de hechos. Dividir y reproducir tablas.

F.i,c l'

;r I ;.:

; ,' i:

*; i i

:'

:.i I

;:

.:

: : : !, ; ; i:.. ! :; r

Las tablas dimensionales se normalizan para obtener sencillezsemntica y facilitar la navegacin del usuario final pc: medio de dimensiones. Por ejemplo, si la tabla de dimensin de lugar contiene dependencias transitivas entre regir:. estado y ciudad, se pueden modificar estas relaciones a Ia 3NF (tercera forma normal), como se ilustra en la figura 13.19. (Si es necesario, repase las tcnicas de normalizacin en el captulo 6.) El esquema en estrella que se obserr,'a en la figura 13.19 se conoce como esquema copo de nieve, que es un tipo de esquema en estrella en el que las tablas de dimensin pueden tener sus propias tablas de dimensin. El esquema copo de nieve suele ser el resultado de normalizar tablas de dimensin.

INTELIGENCIA

DE NEGOCIOS Y ALMACENES

DE DATOS

549

i:#

FIGURA

13.19

RECION ID

TAT'EINAME

SAI.ES TOTAL

Al normalizar las tablas de dimensin, se simplifican las operaciones de filtrado de datos relacionadas con las dimensiones. En este ejemplo, la regin, estado, ciudad y lugar contienen muy pocos registros en comparacin con la tabia de
hechos SALES. Slo la tabla de lugar est directamente relacionada con la tabla de hechos de ventas.

lrf{filrifl,'ilftl
Aunque el uso de las tablas de dimensin que se ilustran en la figura 13.19 da sencillez estructural, hay un precio a pagar por esa sencillez. Por ejemplo. si se desean agregar los datos por regin, debe usarse una combinacin de cuatro tablas, con lo cual se aumenta Ia complejidad de los enunciados de SeL. El esquema en estrella de la figura 13.17 usa una tabla de dimensin LOCATION que en gran medida facilita la recuperacin de datos al eliminar mltiples operaciones de combinacin. ste es otro ejemplo de compensacin

que deben considerar los diseadores.

lantenimiento de nrltiples tablas de hechos para representar cliferentes riveles cfe agregacin Tambin se pueden acelerar operaciones de consulta al crear y mantener mltiples tablas de hechos en cada nivel de agregacin (regin, estado y ciudad) en la dimensin de lugar. Estas tablas agregadas son calculadas previamente en la fase de carga de datos y no en tiempo de ejecucin. El propsito de esta tcnica es ahorrar ciclos de procesador en el tiempo de ejecucin, con lo cual se acelera el anlisis de datos. Una herramienta de consulta para el usuario final, optimizada para anlisis de decisiones, tiene entonces acceso apropiado a las tablas de hechos resumidas en lugar de calcular los valores al acceder a un nivel ms bajo de la tabla de hechos de detalle. Esta tcnica se ilustra en la figira 13.20, que agrega tablas de hechos agregadas por regin, estado y ciudad al ejemplo inicial de ventas.
El diseador de un almacn de datos debe identificar qu niveles de agregacin calcular previamente y guardar en la
base de datos. Estas mliiples tablas de hechos agregadas se actualizan durante cada ciclo ".urgu en el modo de lote. Y como el objetivo es reducir al mnimo el tiempo de acceso y procesamiento. segn la frecuenci esperada de uso el ,-

3l

'c:;il:.:i...-lJ

FIGURA

13.20

IMEiID

Mj

ctTY*tD
.CUT-fD

PROD ID

r{rT_QuANTrw
LSCIT*PRICE

RECIO{ lD

st{tr;AMouNT

CUT ID

rroc_QUANTTTY

stsLoc:JMouNT

tiempo de procesamiento requerido para calcular un nivel determinado de agregacin en el tiempo de ejecucior. ;.
diseador de un almacn de datos debe seleccionar cules tablas de hechos de agregacin crear.

Desnormalizaci'n de tablas de hechos

Desnormalizar tablas de hechos mejora el desempeo del acceso a datos y ahorra espacio para almacenar datos. L< ltimo objeiivo, sin embargo, se est convirtiendo en un problema menor. Los costos de almacenamiento de ia::s disminuyen casi a diario y las limitaciones del DBMS que restringen los lmites de Ia base de datos y el tamao ie -e tabla, los lmites del tamao de un registro y el nmero mximo de registros en una sola tabla tienen efectos mucho ::,'.
negativos que los costos brutos de espacio de

almacenamiento.

La desnormalizacin mejora el desempeo al usar un solo registro para guardar datos que normalmente llevar:: muchos registros. Por ejemplo, para calcular el total de ventas para todos los productos en todas las regiones. tenc:-= mos que acceder a los agregados de ventas de regin y resumir todos los registros de esa tabla. Si tenemos 300 0L-: ventas de productos, se podran resumir al menos 300 000 renglones. Aunque esto podra no ser una operacin ar:--madora para un DBMS, una comparacin, por ejemplo, del valor de ventas previas de 10 aos empieza por ata=-

el sistema. En tales casos, es til tener tabias agregadas especiales que estn desnormalizadas. Por ejemplo, una ial YEAR_TOTALS podra contener los campos siguientes: YEAR_ID, MONT_#1, MONT_#2 ... MONTH_12y elrc'2, de cada ao. Estas tablas pueden usarse con toda facilidad para servir como base para comparaciones de un ao a orl a[ nivel ms alto de mes, al nivel de trimestre o al nivel de aos. Aqu, otra vez, los criterios de diseo, por ejempic ;

INTELIGENCIA

DE NEGOCIOS Y ALMACENES

DE DATOS

55f

;:il

frecuencia de uso y necesidades de desempeo, se evalan contra la posible sobrecarga impuesta en el DBMS para manejar las relaciones desnormalizadas.

Eivisiqim y repicacidn de ta:las

Como la divisin y replicacin de tablas se trataron en detalle en el captulo 12, se explican aqu slo en lo que especfi, camente se relacionan con el almacn de datos. La divisin y replicacin de una tabla son particularmente importantes cuando un sistema de BI se implementa en zonas geogrficas dispersas. Dividir descompone una tabla en subconluntos de renglones o columnas y pone los subconjuntos cerca de la computadora cliente para mejorar el tiempo de aceso Replicar hace una copia de una tabla y la pone en un lugar diferente, tambin para mejorar el tiempo de

:.,..;r::"t

Sin importar cul sea el esquema que se use para mejorar el desempeo, el iiempo es Ia dimensin ms comn que se usa en el anlisis de datos de negocios. Por tanto, es muy comn tener una tabla de hechos por cada nivel de agregacin definido dentro de la dimensin de tiempo. Por citar un caso, en el ejemplo de ventas podramos tener cinco tablas
agregadas de hechos de ventas: diarias, semanales, mensuales, trimestrales y anuales. Esas tablas de hechos deben tener una periodicidad definida implcita o explcita. La periodicidad por lo general se expresa slo como ao actual, aos previos, o todos los aos y proporciona informacin acerca del espacio en tiempo de los datos guardados en la tabla.

Ai trmino de cada ao, las ventas diarias para el ao actual se pasan a otra tabla que contiene slo ventas diarias de aos previos. Esta tabla en realidad contiene todos los registros de ventas desde el principio de las operaciones, con la excepcin del ao actual. Los datos de las tablas del ao actual y de aos previos representan entonces la historia tener que acceder remotamente a datos histricos de ventas, lo cual puede causar un tiempo de respuesta lento. El
completa de ventas de la compaa. La tabla de ventas de aos previos se puede replicar en varios lugares para evitar tamao posible de esta tabla es suficiente para intimidar a todos, menos al mejor de los optimizadores de consultas. A continuacin veamos un caso en el que la desnormalizacin seria de valor.

El desarrollo de un sistema de informacin que abarque toda una organizacin est sujeto a numerosas restricciones. Algunas de ellas se basan en el finnciamiento disponible; otras estn en funcin de cmo vea ia aclministracin el papel desempeado por un departamento de servicio de internet (lS) y de la extensin y profundidad de las necesidades de informacin. Agregue las restricciones impuestas por la cultura corporativa y entender por qu ninguna frmula puede describir un desarrollo perfecto del almacn de datos. Por tanto, ms que proponer un diseo individual de almacn de datos y metodologa de implementacin, esta seccin identifica algunos factores que parecen ser comunes al almacenamiento de datos.

El elvncN DE DATos coMo MARco Acrrvo pARA sopoRTE DE DEcrsroNEs

Quiz lo primero que hay que recordar es que un almacn de datos no es una base de datos esttica. En cambio, es un marco dinmico para soporte de decisiones que es, casi por definicin, siempre un trabajo en proceso. Debido a que es el fundamento de un ambiente moderno de inteligencia de negocios (BI), el diseo e implementacin del almacn de datos significa que estamos involucrados en el diseo e implementacin de una infraestruch-ra, para el desarrollo de un sistema completo de base de datos para soporte de decisiones a nivel de toda la compaa. Aunque es fcil concentrarse en la base de datos de un almacn como el depsito central de datos de Ia Bi. debemos recordar que la infraestructura para soporte de decisiones incluye hardware, softr",are, personal y procedimientos, as como datos. El argumento de que el almacn de datos es el nico componente crtco para el xito de la BI es tan errado como el de que un ser humano necesita slo un corazn o un cerebro para funcionar. El almacn de datos es un componente crtico de un mbito de BI moderno. pero ciertamente no es el nico. Por tanto, su diseo e implementacin deben examinarse a la luz de toda la infraestructura.