1.

1 INTRODUCCION AL CONCEPTO DATA WAREHOUSING

Data warehousing es el centro de la arquitectura para los sistemas de informacin en la dcada de los
'90. Soporta el procesamiento informtico al proveer una plataforma slida, a partir de los datos
histricos para hacer el anlisis. Facilita la integracin de sistemas de aplicacin no integrados. Organiza
y almacena los datos que se necesitan para el procesamiento analtico, informtico sobre una amplia
perspectiva de tiempo.
Un Data Warehouse o Depsito de Datos es una coleccin de datos orientado a temas, integrado, no
voltil, de tiempo variante, que se usa para el soporte del proceso de toma de decisiones gerenciales.
Se puede caracterizar un data warehouse haciendo un contraste de cmo los datos de un negocio
almacenados en un data warehouse, difieren de los datos operacionales usados por las aplicaciones de
produccin.
Base de Datos Operacional
Datos Operacionales
Orientado a la aplicacin
Actual
Detallada
Cambia continuamente

Data Warehouse
Datos del negocio para Informacin
Orientado al sujeto
Actual + histrico
Detallada + ms resumida
Estable

Diferentes tipos de informacin

El ingreso de datos en el data warehouse viene desde el ambiente operacional en casi todos los casos. El
data warehouse es siempre un almacn de datos transformados y separados fsicamente de la
aplicacin donde se encontraron los datos en el ambiente operacional.
1.2 SISTEMAS DE INFORMACION

Los sistemas de informacin se han dividido de acuerdo al siguiente esquema:

Sistemas Estratgicos, orientados a soportar la toma de decisiones, facilitan la labor de la direccin,

proporcionndole un soporte bsico, en forma de mejor informacin, para la toma de decisiones. Se
caracterizan porque son sistemas sin carga peridica de trabajo, es decir, su utilizacin no es predecible,
al contrario de los casos anteriores, cuya utilizacin es peridica.

Destacan entre estos sistemas: los Sistemas de Informacin Gerencial (MIS), Sistemas de Informacin
Ejecutivos (EIS), Sistemas de Informacin Georeferencial (GIS), Sistemas de Simulacin de Negocios (BIS
y que en la prctica son sistemas expertos o de Inteligencia Artificial-AI).
Sistemas Tcticos, diseados para soportar las actividades de coordinacin de actividades y manejo de
documentacin, definidos para facilitar consultas sobre informacin almacenada en el sistema,
proporcionar informes y, en resumen, facilitar la gestin independiente de la informacin por parte de
los niveles intermedios de la organizacin.
Destacan entre ellos: los Sistemas Ofimticos (OA), Sistemas de Transmisin de Mensajera (E-mail y Fax
Server), coordinacin y control de tareas (Work Flow) y tratamiento de documentos (Imagen, Trmite y
Bases de Datos Documentarios).
Sistemas Tcnico-Operativos, que cubren el ncleo de operaciones tradicionales de captura masiva de
datos (Data Entry) y servicios bsicos de tratamiento de datos, con tareas predefinidas (contabilidad,
facturacin, almacn, presupuesto, personal y otros sistemas administrativos). Estos sistemas estn
evolucionando con la irrupcin de censores, autmatas, sistemas multimedia, bases de datos
relacionales ms avanzadas y data warehousing.
Sistemas Interinstitucionales, este ltimo nivel de sistemas de informacin recin est surgiendo, es
consecuencia del desarrollo organizacional orientado a un mercado de carcter global, el cual obliga a
pensar e implementar estructuras de comunicacin ms estrechas entre la organizacin y el mercado
(Empresa Extendida, Organizacin Inteligente e Integracin Organizacional), todo sto a partir de la
generalizacin de las redes informticas de alcance nacional y global (INTERNET), que se convierten en
vehculo de comunicacin entre la organizacin y el mercado, no importa dnde est la organizacin
(INTRANET), el mercado de la institucin (EXTRANET) y el mercado (Red Global).
Sin embargo, la tecnologa data warehousing basa sus conceptos y diferencias entre dos tipos
fundamentales de sistemas de informacin en todas las organizaciones: los sistemas tcnicooperacionales y los sistemas de soporte de decisiones. Este ltimo es la base de un data warehouse.
1.2.1 Sistemas tcnico-operacionales
Como indica su nombre, son los sistemas que ayudan a manejar la empresa con sus operaciones
cotidianas. Estos son los sistemas que operan sobre el "backbone" (columna vertebral) de cualquier
empresa o institucin, entre las que se tiene sistemas de ingreso de rdenes, inventario, fabricacin,
planilla y contabilidad, entre otros.
Debido a su volumen e importancia en la organizacin, los sistemas operacionales siempre han sido las
primeras partes de la empresa a ser computarizados. A travs de los aos, estos sistemas operacionales
se han extendido, revisado, mejorado y mantenido al punto que hoy, ellos son completamente
integrados en la organizacin.
Desde luego, la mayora de las organizaciones grandes de todo el mundo, actualmente no podran
operar sin sus sistemas operacionales y los datos que estos sistemas mantienen.
1.2.2 Sistemas de Soporte de Decisiones
Por otra parte, hay otras funciones dentro de la empresa que tienen que ver con el planeamiento,
previsin y administracin de la organizacin. Estas funciones son tambin crticas para la supervivencia
de la organizacin, especialmente en nuestro mundo de rpidos cambios.

Las funciones como "planificacin de marketing", "planeamiento de ingeniera" y "anlisis financiero",

requieren, adems, de sistemas de informacin que los soporte. Pero estas funciones son diferentes de
las operacionales y los tipos de sistemas y la informacin requerida son tambin diferentes. Las
funciones basadas en el conocimiento son los sistemas de soporte de decisiones.
Estos sistemas estn relacionados con el anlisis de los datos y la toma de decisiones, frecuentemente,
decisiones importantes sobre cmo operar la empresa, ahora y en el futuro. Estos sistemas no slo
tienen un enfoque diferente al de los operacionales, sino que, por lo general, tienen un alcance
diferente.
Mientras las necesidades de los datos operacionales se enfocan normalmente hacia una sola rea, los
datos para el soporte de decisiones, con frecuencia, toma un nmero de reas diferentes y necesita
cantidades grandes de datos operacionales relacionadas.
Son estos sistemas sobre los se basa la tecnologa data warehousing.
1.3 CARACTERISTICAS DE UN DATA WAREHOUSE
Entre las principales se tiene:

Orientado al tema

Integrado

De tiempo variante

No voltil

1.3.1 Orientado a Temas

Una primera caracterstica del data warehouse es que la informacin se clasifica en base a los aspectos
que son de inters para la empresa. Siendo as, los datos tomados estn en contraste con los clsicos
procesos orientados a las aplicaciones. En la Figura N 1 se muestra el contraste entre los dos tipos de
orientaciones.
El ambiente operacional se disea alrededor de las aplicaciones y funciones tales como prstamos,
ahorros, tarjeta bancaria y depsitos para una institucin financiera. Por ejemplo, una aplicacin de
ingreso de rdenes puede acceder a los datos sobre clientes, productos y cuentas. La base de datos
combina estos elementos en una estructura que acomoda las necesidades de la aplicacin.
En el ambiente data warehousing se organiza alrededor de sujetos tales como cliente, vendedor,
producto y actividad. Por ejemplo, para un fabricante, stos pueden ser clientes, productos,
proveedores y vendedores. Para una universidad pueden ser estudiantes, clases y profesores. Para un
hospital pueden ser pacientes, personal mdico, medicamentos, etc.
La alineacin alrededor de las reas de los temas afecta el diseo y la implementacin de los datos
encontrados en el data warehouse. Las principales reas de los temas influyen en la parte ms
importante de la estructura clave.

Las aplicaciones estn relacionadas con el diseo de la base de datos y del proceso. En data warehousing
se enfoca el modelamiento de datos y el diseo de la base de datos. El diseo del proceso (en su forma
clsica) no es separado de este ambiente.
Las diferencias entre la orientacin de procesos y funciones de las aplicaciones y la orientacin a temas,
radican en el contenido de la data a nivel detallado. En el data warehouse se excluye la informacin que
no ser usada por el proceso de sistemas de soporte de decisiones, mientras que la informacin de las
orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos
funcionales y de proceso, que pueden ser usados o no por el analista de soporte de decisiones.
Otra diferencia importante est en la interrelacin de la informacin. Los datos operacionales
mantienen una relacin continua entre dos o ms tablas basadas en una regla comercial que est
vigente. Las del data warehouse miden un espectro de tiempo y las relaciones encontradas en el data

warehouse son muchas. Muchas de las reglas comerciales (y sus correspondientes relaciones de datos)
se representan en el data warehouse, entre dos o ms tablas.
1.3.2 Integracin
El aspecto ms importante del ambiente data warehousing es que la informacin encontrada al interior
est siempre integrada.
La integracin de datos se muestra de muchas maneras: en convenciones de nombres consistentes, en
la medida uniforme de variables, en la codificacin de estructuras consistentes, en atributos fsicos de
los datos consistentes, fuentes mltiples y otros.
El contraste de la integracin encontrada en el data warehouse con la carencia de integracin del
ambiente de aplicaciones, se muestran en la Figura N 2, con diferencias bien marcadas.
A travs de los aos, los diseadores de las diferentes aplicaciones han tomado sus propias decisiones
sobre cmo se debera construir una aplicacin. Los estilos y diseos personalizados se muestran de
muchas maneras.
Se diferencian en la codificacin, en las estructuras claves, en sus caractersticas fsicas, en las
convenciones de nombramiento y otros. La capacidad colectiva de muchos de los diseadores de
aplicaciones, para crear aplicaciones inconsistentes, es fabulosa. La Figura N 2 mencionada, muestra
algunas de las diferencias ms importantes en las formas en que se disean las aplicaciones.
Codificacin. Los diseadores de aplicaciones codifican el campo GENERO en varias formas. Un
diseador representa GENERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X"
y una "Y" e inclusive, como "masculino" y "femenino".
No importa mucho cmo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan buenas
como cualquier otra representacin. Lo importante es que sea de cualquier fuente de donde venga, el
GENERO debe llegar al data warehouse en un estado integrado uniforme.
Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicacin, donde ha sido
representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse.
Medida de atributos. Los diseadores de aplicaciones miden las unidades de medida de las tuberas en
una variedad de formas. Un diseador almacena los datos de tuberas en centmetros, otros en
pulgadas, otros en millones de pies cbicos por segundo y otros en yardas.
Al dar medidas a los atributos, la transformacin traduce las diversas unidades de medida usadas en las
diferentes bases de datos para transformarlas en una medida estndar comn.
Cualquiera que sea la fuente, cuando la informacin de la tubera llegue al data warehouse necesitar
ser medida de la misma manera.
Convenciones de Nombramiento.- El mismo elemento es frecuentemente referido por nombres
diferentes en las diversas aplicaciones. El proceso de transformacin asegura que se use
preferentemente el nombre de usuario.

Fuentes Mltiples.- El mismo elemento puede derivarse desde fuentes mltiples. En este caso, el
proceso de transformacin debe asegurar que la fuente apropiada sea usada, documentada y movida al
depsito.
Tal como se muestra en la figura, los puntos de integracin afectan casi todos los aspectos de diseo las caractersticas fsicas de los datos, la disyuntiva de tener ms de una de fuente de datos, el problema
de estndares de denominacin inconsistentes, formatos de fecha inconsistentes y otros.
Cualquiera que sea la forma del diseo, el resultado es el mismo - la informacin necesita ser
almacenada en el data warehouse en un modelo globalmente aceptable y singular, aun cuando los
sistemas operacionales subyacentes almacenen los datos de manera diferente.
Cuando el analista de sistema de soporte de decisiones observe el data warehouse, su enfoque deber
estar en el uso de los datos que se encuentre en el depsito, antes que preguntarse sobre la
confiabilidad o consistencia de los datos.

1.3.3 De Tiempo Variante

Toda la informacin del data warehouse es requerida en algn momento. Esta caracterstica bsica de
los datos en un depsito, es muy diferente de la informacin encontrada en el ambiente operacional. En
stos, la informacin se requiere al momento de acceder. En otras palabras, en el ambiente operacional,

cuando usted accesa a una unidad de informacin, usted espera que los valores requeridos se obtengan
a partir del momento de acceso.
Como la informacin en el data warehouse es solicitada en cualquier momento (es decir, no "ahora
mismo"), los datos encontrados en el depsito se llaman de "tiempo variante".
Los datos histricos son de poco uso en el procesamiento operacional. La informacin del depsito por
el contraste, debe incluir los datos histricos para usarse en la identificacin y evaluacin de tendencias.
(Ver Figura N 3).

l tiempo variante se muestra de varias maneras:

1 La ms simple es que la informacin representa los datos sobre un horizonte largo de tiempo - desde
cinco a diez aos. El horizonte de tiempo representado para el ambiente operacional es mucho ms
corto - desde valores actuales hasta sesenta a noventa das.
Las aplicaciones que tienen un buen rendimiento y estn disponibles para el procesamiento de
transacciones, deben llevar una cantidad mnima de datos si tienen cualquier grado de flexibilidad. Por
ello, las aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseo de
aplicaciones rgidas.
2 La segunda manera en la que se muestra el tiempo variante en el data warehouse est en la
estructura clave. Cada estructura clave en el data warehouse contiene, implcita o explcitamente, un
elemento de tiempo como da, semana, mes, etc.
El elemento de tiempo est casi siempre al pie de la clave concatenada, encontrada en el data
warehouse. En ocasiones, el elemento de tiempo existir implcitamente, como el caso en que un
archivo completo se duplica al final del mes, o al cuarto.
3 La tercera manera en que aparece el tiempo variante es cuando la informacin del data warehouse,
una vez registrada correctamente, no puede ser actualizada. La informacin del data warehouse es, para
todos los propsitos prcticos, una serie larga de "snapshots" (vistas instantneas).
Por supuesto, si los snapshots de los datos se han tomado incorrectamente, entonces pueden ser
cambiados. Asumiendo que los snapshots se han tomado adecuadamente, ellos no son alterados una
vez hechos. En algunos casos puede ser no tico, e incluso ilegal, alterar los snapshots en el data
warehouse. Los datos operacionales, siendo requeridos a partir del momento de acceso, pueden
actualizarse de acuerdo a la necesidad.

1.3.4 No Voltil
La informacin es til slo cuando es estable. Los datos operacionales cambian sobre una base
momento a momento. La perspectiva ms grande, esencial para el anlisis y la toma de decisiones,
requiere una base de datos estable.
En la Figura N 4 se muestra que la actualizacin (insertar, borrar y modificar), se hace regularmente en
el ambiente operacional sobre una base de registro por registro. Pero la manipulacin bsica de los
datos que ocurre en el data warehouse es mucho ms simple. Hay dos nicos tipos de operaciones: la
carga inicial de datos y el acceso a los mismos. No hay actualizacin de datos (en el sentido general de
actualizacin) en el depsito, como una parte normal de procesamiento.
Hay algunas consecuencias muy importantes de esta diferencia bsica, entre el procesamiento
operacional y del data warehouse. En el nivel de diseo, la necesidad de ser precavido para actualizar las
anomalas no es un factor en el data warehouse, ya que no se hace la actualizacin de datos. Esto
significa que en el nivel fsico de diseo, se pueden tomar libertades para optimizar el acceso a los datos,
particularmente al usar la normalizacin y denormalizacin fsica.
Otra consecuencia de la simplicidad de la operacin del data warehouse est en la tecnologa
subyacente, utilizada para correr los datos en el depsito. Teniendo que soportar la actualizacin de
registro por registro en modo on-line (como es frecuente en el caso del procesamiento operacional)
requiere que la tecnologa tenga un fundamento muy complejo debajo de una fachada de simplicidad.

La tecnologa permite realizar backup y recuperacin, transacciones e integridad de los datos y la

deteccin y solucin al estancamiento que es ms complejo. En el data warehouse no es necesario el
procesamiento.
La fuente de casi toda la informacin del data warehouse es el ambiente operacional. A simple vista, se
puede pensar que hay redundancia masiva de datos entre los dos ambientes. Desde luego, la primera
impresin de muchas personas se centra en la gran redundancia de datos, entre el ambiente
operacional y el ambiente de data warehouse. Dicho razonamiento es superficial y demuestra una
carencia de entendimiento con respecto a qu ocurre en el data warehouse. De hecho, hay una mnima
redundancia de datos entre ambos ambientes.

Se debe considerar lo siguiente:

Los datos se filtran cuando pasan desde el ambiente operacional al de depsito. Existe mucha data que
nunca sale del ambiente operacional. Slo los datos que realmente se necesitan ingresarn al ambiente
de data warehouse.
El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La informacin en el
ambiente operacional es ms reciente con respecto a la del data warehouse. Desde la perspectiva de los
horizontes de tiempo nicos, hay poca superposicin entre los ambientes operacional y de data
warehouse.
El data warehouse contiene un resumen de la informacin que no se encuentra en el ambiente
operacional.
Los datos experimentan una transformacin fundamental cuando pasa al data warehouse. La mayor
parte de los datos se alteran significativamente al ser seleccionados y movidos al data warehouse. Dicho
de otra manera, la mayora de los datos se alteran fsica y radicalmente cuando se mueven al depsito.
No es la misma data que reside en el ambiente operacional desde el punto de vista de integracin.
En vista de estos factores, la redundancia de datos entre los dos ambientes es una ocurrencia rara, que
resulta en menos de 1%.

1.4 ESTRUCTURA DEL DATA WAREHOUSE

Los data warehouses tienen una estructura distinta. Hay niveles diferentes de esquematizacin y detalle
que delimitan el data warehouse. La estructura de un data warehouse se muestra en la Figura N 5.
En la figura, se muestran los diferentes componentes del data warehouse y son:

Detalle de datos actuales

Detalle de datos antiguos

Datos ligeramente resumidos

Datos completamente resumidos

Meta data

Detalle de datos actuales.- En gran parte, el inters ms importante radica en el detalle de los datos
actuales, debido a que:
Refleja las ocurrencias ms recientes, las cuales son de gran inters
Es voluminoso, ya que se almacena al ms bajo nivel de granularidad.
Casi siempre se almacena en disco, el cual es de fcil acceso, aunque su administracin sea costosa y
compleja.

Detalle de datos antiguos.- La data antigua es aquella que se almacena sobre alguna forma de
almacenamiento masivo. No es frecuentemente accesada y se almacena a un nivel de detalle,
consistente con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un
medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no frecuente de los
mismos, es poco usual utilizar el disco como medio de almacenamiento.
Datos ligeramente resumidos.- La data ligeramente resumida es aquella que proviene desde un bajo
nivel de detalle encontrado al nivel de detalle actual. Este nivel del data warehouse casi siempre se
almacena en disco. Los puntos en los que se basa el diseador para construirlo son:
Que la unidad de tiempo se encuentre sobre la esquematizacin hecha.
Qu contenidos (atributos) tendr la data ligeramente resumida.
Datos completamente resumidos.- El siguiente nivel de datos encontrado en el data warehouse es el de
los datos completamente resumidos. Estos datos son compactos y fcilmente accesibles.

A veces se encuentra en el ambiente de data warehouse y en otros, fuera del lmite de la tecnologa que
ampara al data warehouse. (De todos modos, los datos completamente resumidos son parte del data
warehouse sin considerar donde se alojan los datos fsicamente.)
Metadata.- El componente final del data warehouse es el de la metadata. De muchas maneras la
metadata se sita en una dimensin diferente al de otros datos del data warehouse, debido a que su
contenido no es tomado directamente desde el ambiente operacional.
La metadata juega un rol especial y muy importante en el data warehouse y es usada como:

Un directorio para ayudar al analista a ubicar los contenidos del data warehouse.
Una gua para el mapping de datos de cmo se transforma, del ambiente operacional al de data
warehouse.
Una gua de los algoritmos usados para la esquematizacin entre el detalle de datos actual, con los
datos ligeramente resumidos y stos, con los datos completamente resumidos, etc.
La metadata juega un papel mucho ms importante en un ambiente data warehousing que en un
operacional clsico.
A fin de recordar los diferentes niveles de los datos encontrados en el data warehouse, considere el
ejemplo mostrado en la Figura N 6.
El detalle de ventas antiguas son las que se encuentran antes de 1992. Todos los detalles de ventas
desde 1982 (o cuando el diseador inici la coleccin de los archivos) son almacenados en el nivel de
detalle de datos ms antiguo.
El detalle actual contiene informacin desde 1992 a 1993 (suponiendo que 1993 es el ao actual). En
general, el detalle de ventas no se ubica en el nivel de detalle actual hasta que haya pasado, por lo
menos, veinticuatro horas desde que la informacin de ventas llegue a estar disponible en el ambiente
operacional.

En otras palabras, habra un retraso de tiempo de por lo menos veinticuatro horas, entre el tiempo en
que en el ambiente operacional se haya hecho un nuevo ingreso de la venta y el momento cuando la
informacin de la venta haya ingresado al data warehouse.
El detalle de las ventas son resumidas semanalmente por lnea de subproducto y por regin, para
producir un almacenamiento de datos ligeramente resumidos.

El detalle de ventas semanal es adicionalmente resumido en forma mensual, segn una gama de lneas,
para producir los datos completamente resumidos.
La metadata contiene (al menos):
La estructura de los datos
Los algoritmos usados para la esquematizacin
El mapping desde el ambiente operacional al data warehouse
La informacin adicional que no se esquematiza es almacenada en el data warehouse. En muchas
ocasiones, all se har el anlisis y se producir un tipo u otro de resumen. El nico tipo de
esquematizacin que se almacena permanentemente en el data warehouse, es el de los datos que son
usados frecuentemente. En otras palabras, si un analista produce un resumen que tiene una
probabilidad muy baja de ser usado nuevamente, entonces la esquematizacin no es almacenada en el
data warehouse.
1.5 ARQUITECTURA DE UN DATA WAREHOUSE
Una de las razones por las que el desarrollo de un data warehouse crece rpidamente, es que realmente
es una tecnologa muy entendible. De hecho, data warehousing puede representar mejor la estructura
amplia de una empresa para administrar los datos informacionales dentro de la organizacin. A fin de
comprender cmo se relacionan todos los componentes involucrados en una estrategia data
warehousing, es esencial tener una Arquitectura Data Warehouse.
ARQUITECTURA DE UN DATA WAREHOUSE

1.5.1 Elementos constituyentes de una Arquitectura Data Warehouse

Una Arquitectura Data Warehouse (Data Warehouse Architecture - DWA) es una forma de representar
la estructura total de datos, comunicacin, procesamiento y presentacin, que existe para los usuarios
finales que disponen de una computadora dentro de la empresa.
La arquitectura se constituye de un nmero de partes interconectadas:

Base de datos operacional / Nivel de base de datos externo

Nivel de acceso a la informacin

Nivel de acceso a los datos

Nivel de directorio de datos (Metadata)

Nivel de gestin de proceso

Nivel de mensaje de la aplicacin

Nivel de data warehouse

Nivel de organizacin de datos

Base de datos operacional / Nivel de base de datos externo

Los sistemas operacionales procesan datos para apoyar las necesidades operacionales crticas. Para
hacer eso, se han creado las bases de datos operacionales histricas que proveen una estructura de
procesamiento eficiente, para un nmero relativamente pequeo de transacciones comerciales bien
definidas.
Sin embargo, a causa del enfoque limitado de los sistemas operacionales, las bases de datos diseadas
para soportar estos sistemas, tienen dificultad al acceder a los datos para otra gestin o propsitos
informticos.
Esta dificultad en acceder a los datos operacionales es amplificada por el hecho que muchos de estos
sistemas tienen de 10 a 15 aos de antigedad. El tiempo de algunos de estos sistemas significa que la
tecnologa de acceso a los datos disponible para obtener los datos operacionales, es as mismo antigua.
Ciertamente, la meta del data warehousing es liberar la informacin que es almacenada en bases de
datos operacionales y combinarla con la informacin desde otra fuente de datos, generalmente externa.
Cada vez ms, las organizaciones grandes adquieren datos adicionales desde bases de datos externas.
Esta informacin incluye tendencias demogrficas, economtricas, adquisitivas y competitivas (que
pueden ser proporcionadas por Instituciones Oficiales - INEI). Internet o tambin llamada "information
superhighway" (supercarretera de la informacin) provee el acceso a ms recursos de datos todos los
das.

Nivel de acceso a la informacin

El nivel de acceso a la informacin de la arquitectura data warehouse, es el nivel del que el usuario final
se encarga directamente. En particular, representa las herramientas que el usuario final normalmente
usa da a da. Por ejemplo: Excel, Lotus 1-2-3, Focus, Access, SAS, etc.
Este nivel tambin incluye el hardware y software involucrados en mostrar informacin en pantalla y
emitir reportes de impresin, hojas de clculo, grficos y diagramas para el anlisis y presentacin. Hace

dos dcadas que el nivel de acceso a la informacin se ha expandido enormemente, especialmente a los
usuarios finales quienes se han volcado a los PCs monousuarios y los PCs en redes.
Actualmente, existen herramientas ms y ms sofisticadas para manipular, analizar y presentar los
datos, sin embargo, hay problemas significativos al tratar de convertir los datos tal como han sido
recolectados y que se encuentran contenidos en los sistemas operacionales en informacin fcil y
transparente para las herramientas de los usuarios finales. Una de las claves para esto es encontrar un
lenguaje de datos comn que puede usarse a travs de toda la empresa.
Nivel de acceso a los datos
El nivel de acceso a los datos de la arquitectura data warehouse est involucrado con el nivel de acceso
a la informacin para conversar en el nivel operacional. En la red mundial de hoy, el lenguaje de datos
comn que ha surgido es SQL. Originalmente, SQL fue desarrollado por IBM como un lenguaje de
consulta, pero en los ltimos veinte aos ha llegado a ser el estndar para el intercambio de datos.
Uno de los adelantos claves de los ltimos aos ha sido el desarrollo de una serie de "filtros" de acceso a
datos, tales como EDA/SQL para acceder a casi todo los Sistemas de Gestin de Base de Datos (Data
Base Management Systems - DBMSs) y sistemas de archivos de datos, relacionales o no. Estos filtros
permiten a las herramientas de acceso a la informacin, acceder tambin a la data almacenada en
sistemas de gestin de base de datos que tienen veinte aos de antigedad.
El nivel de acceso a los datos no solamente conecta DBMSs diferentes y sistemas de archivos sobre el
mismo hardware, sino tambin a los fabricantes y protocolos de red. Una de las claves de una estrategia
data warehousing es proveer a los usuarios finales con "acceso a datos universales".
El acceso a los datos universales significa que, tericamente por lo menos, los usuarios finales sin tener
en cuenta la herramienta de acceso a la informacin o ubicacin, deberan ser capaces de acceder a
cualquier o todos los datos en la empresa que es necesaria para ellos, para hacer su trabajo.
El nivel de acceso a los datos entonces es responsable de la interfaces entre las herramientas de acceso
a la informacin y las bases de datos operacionales. En algunos casos, esto es todo lo que un usuario
final necesita. Sin embargo, en general, las organizaciones desarrollan un plan mucho ms sofisticado
para el soporte del data warehousing.

Nivel de Directorio de Datos (Metadata)

A fin de proveer el acceso a los datos universales, es absolutamente necesario mantener alguna forma
de directorio de datos o repositorio de la informacin metadata. La metadata es la informacin
alrededor de los datos dentro de la empresa.
Las descripciones de registro en un programa COBOL son metadata. Tambin lo son las sentencias
DIMENSION en un programa FORTRAN o las sentencias a crear en SQL.
A fin de tener un depsito totalmente funcional, es necesario tener una variedad de metadata
disponibles, informacin sobre las vistas de datos de los usuarios finales e informacin sobre las bases
de datos operacionales. Idealmente, los usuarios finales deberan de acceder a los datos desde el data
warehouse (o desde las bases de datos operacionales), sin tener que conocer dnde residen los datos o
la forma en que se han almacenados.

Nivel de Gestin de Procesos

El nivel de gestin de procesos tiene que ver con la programacin de diversas tareas que deben
realizarse para construir y mantener el data warehouse y la informacin del directorio de datos. Este
nivel puede depender del alto nivel de control de trabajo para muchos procesos (procedimientos) que
deben ocurrir para mantener el data warehouse actualizado.
Nivel de Mensaje de la Aplicacin
El nivel de mensaje de la aplicacin tiene que ver con el transporte de informacin alrededor de la red
de la empresa. El mensaje de aplicacin se refiere tambin como "subproducto", pero puede involucrar
slo protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones operacionales o estratgicas a
partir del formato de datos exacto, recolectar transacciones o los mensajes y entregarlos a una
ubicacin segura en un tiempo seguro.
Nivel Data Warehouse (Fsico)
En el data warehouse (ncleo) es donde ocurre la data actual, usada principalmente para usos
estratgicos. En algunos casos, uno puede pensar del data warehouse simplemente como una vista
lgica o virtual de datos. En muchos ejemplos, el data warehouse puede no involucrar almacenamiento
de datos.
En un data warehouse fsico, copias, en algunos casos, muchas copias de datos operacionales y/o
externos, son almacenados realmente en una forma que es fcil de acceder y es altamente flexible. Cada
vez ms, los data warehouses son almacenados sobre plataformas cliente/servidor, pero por lo general
se almacenan sobre mainframes.
Nivel de Organizacin de Datos
El componente final de la arquitectura data warehouse es la organizacin de los datos. Se llama tambin
gestin de copia o rplica, pero de hecho, incluye todos los procesos necesarios como seleccionar,
editar, resumir, combinar y cargar datos en el depsito y acceder a la informacin desde bases de datos
operacionales y/o externas.
La organizacin de datos involucra con frecuencia una programacin compleja, pero cada vez ms, estn
crendose las herramientas data warehousing para ayudar en este proceso. Involucra tambin
programas de anlisis de calidad de datos y filtros que identifican modelos y estructura de datos dentro
de la data operacional existente.
1.5.2 Operaciones en un Data Warehouse
En la Figura N 8 se muestra algunos de los tipos de operaciones que se efectan dentro de un ambiente
data warehousing.

a) Sistemas Operacionales
Los datos administrados por los sistemas de aplicacin operacionales son la fuente principal de datos
para el data warehouse.
Las bases de datos operacionales se organizan como archivos indexados (UFAS, VSAM), bases de datos
de redes/jerrquicas (I-D-S/II, IMS, IDMS) o sistemas de base de datos relacionales (DB2, Oracle,
Informix, etc.). Segn las encuestas, aproximadamente del 70% a 80% de las bases de datos de las
empresas se organizan usando DBMSs no relacional.
b) Extraccin, Transformacin y Carga de los Datos
Se requieren herramientas de gestin de datos para extraer datos desde bases de datos y/o archivos
operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el
data warehouse.
Tomar los datos desde varias bases de datos operacionales y transformarlos en datos requeridos para el
depsito, se refiere a la transformacin o a la integracin de datos. Las bases de datos operacionales,
diseadas para el soporte de varias aplicaciones de produccin, frecuentemente difieren en el formato.
Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por
diferentes software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen
formatos inconsistentes y/o ser codificados de manera diferente. Todas estas inconsistencias deben
resolverse antes que los elementos de datos sean almacenados en el data warehouse.
c) Metadata
Otro paso necesario es crear la metadata. La metadata (es decir, datos acerca de datos) describe los
contenidos del data warehouse. La metadata consiste de definiciones de los elementos de datos en el
depsito, sistema(s) del (os) elemento(s) fuente. Como la data, se integra y transforma antes de ser
almacenada en informacin similar.
d) Acceso de usuario final

Los usuarios accesan al data warehouse por medio de herramientas de productividad basadas en GUI
(Graphical User Interface - Interfase grfica de usuario). Pueden proveerse a los usuarios del data
warehouse muchos de estos tipos de herramientas.
Estos pueden incluir software de consultas, generadores de reportes, procesamiento analtico en lnea,
herramientas data/visual mining, etc., dependiendo de los tipos de usuarios y sus requerimientos
particulares. Sin embargo, una sola herramienta no satisface todos los requerimientos, por lo que es
necesaria la integracin de una serie de herramientas.
e) Plataforma del data warehouse
La plataforma para el data warehouse es casi siempre un servidor de base de datos relacional. Cuando
se manipulan volmenes muy grandes de datos puede requerirse una configuracin en bloque de
servidores UNIX con multiprocesador simtrico (SMP) o un servidor con procesador paralelo masivo
(MPP) especializado.
Los extractos de la data integrada/transformada se cargan en el data warehouse. Uno de los ms
populares RDBMSs disponibles para data warehousing sobre la plataforma UNIX (SMP y MPP)
generalmente es Teradata. La eleccin de la plataforma es crtica. El depsito crecer y hay que
comprender los requerimientos despus de 3 o 5 aos.
Muchas de las organizaciones quieran o no escogen una plataforma por diversas razones: el Sistema X
es nuestro sistema elegido o el Sistema Y est ya disponible sobre un sistema UNIX que nosotros ya
tenemos. Uno de los errores ms grandes que las organizaciones cometen al seleccionar la plataforma,
es que ellos presumen que el sistema (hardware y/o DBMS) escalar con los datos.
El sistema de depsito ejecuta las consultas que se pasa a los datos por el software de acceso a los datos
del usuario. Aunque un usuario visualiza las consultas desde el punto de vista de un GUI, las consultas
tpicamente se formulan como pedidos SQL, porque SQL es un lenguaje universal y el estndar de hecho
para el acceso a datos.
f) Datos Externos
Dependiendo de la aplicacin, el alcance del data warehouse puede extenderse por la capacidad de
acceder a la data externa. Por ejemplo, los datos accesibles por medio de servicios de computadora en
lnea (tales como CompuServe y America On Line) y/o va Internet, pueden estar disponibles a los
usuarios del data warehouse.
Evolucin del Depsito
Construir un data warehouse es una tarea grande. No es recomendable emprender el desarrollo del
data warehouse de la empresa como un proyecto cualquiera. Ms bien, se recomienda que los
requerimientos de una serie de fases se desarrollen e implementen en modelos consecutivos que
permitan un proceso de implementacin ms gradual e iterativo.
No existe ninguna organizacin que haya triunfado en el desarrollo del data warehouse de la empresa,
en un slo paso. Muchas, sin embargo, lo han logrado luego de un desarrollo paso a paso. Los pasos
previos evolucionan conjuntamente con la materia que est siendo agregada.
Los datos en el data warehouse no son voltiles y es un repositorio de datos de slo lectura (en general).
Sin embargo, pueden aadirse nuevos elementos sobre una base regular para que el contenido siga la
evolucin de los datos en la base de datos fuente, tanto en los contenidos como en el tiempo.

Uno de los desafos de mantener un data warehouse, es idear mtodos para identificar datos nuevos o
modificados en las bases de datos operacionales. Algunas maneras para identificar estos datos incluyen
insertar fecha/tiempo en los registros de base de datos y entonces crear copias de registros actualizados
y copiar informacin de los registros de transaccin y/o base de datos diarias.
Estos elementos de datos nuevos y/o modificados son extrados, integrados, transformados y agregados
al data warehouse en pasos peridicos programados. Como se aaden las nuevas ocurrencias de datos,
los datos antiguos son eliminados. Por ejemplo, si los detalles de un sujeto particular se mantienen por 5
aos, como se agreg la ltima semana, la semana anterior es eliminada.

1.6 TRANSFORMACION DE DATOS Y METADATA

1.6.1 Transformacin de Datos
Uno de los desafos de cualquier implementacin de data warehouse, es el problema de transformar los
datos. La transformacin se encarga de las inconsistencias en los formatos de datos y la codificacin,
que pueden existir dentro de una base de datos nica y que casi siempre existen cuando mltiples bases
de datos contribuyen al data warehouse.
En la Figura N 9 se ilustra una forma de inconsistencia, en la cual el gnero se codifica de manera
diferente en tres bases de datos diferentes. Los procesos de transformacin de datos se desarrollan
para direccionar estas inconsistencias.

La transformacin de datos tambin se encarga de las inconsistencias en el contenido de datos. Una vez
que se toma la decisin sobre que reglas de transformacin sern establecidas, deben crearse e incluirse
las definiciones en las rutinas de transformacin.
Se requiere una planificacin cuidadosa y detallada para transformar datos inconsistentes en conjuntos
de datos conciliables y consistentes para cargarlos en el data warehouse.

1.6.2 Metadata
Otro aspecto de la arquitectura de data warehouse es crear soporte a la metadata. Metadata es la
informacin sobre los datos que se alimenta, se transforma y existe en el data warehouse. Metadata es
un concepto genrico, pero cada implementacin de la metadata usa tcnicas y mtodos especficos.
Estos mtodos y tcnicas son dependientes de los requerimientos de cada organizacin, de las
capacidades existentes y de los requerimientos de interfaces de usuario. Hasta ahora, no hay normas
para la metadata, por lo que la metadata debe definirse desde el punto de vista del software data
warehousing, seleccionado para una implementacin especfica.
Tpicamente, la metadata incluye los siguientes tems:

Las estructuras de datos que dan una visin de los datos al administrador de datos.

Las definiciones del sistema de registro desde el cual se construye el data warehouse.

Las especificaciones de transformaciones de datos que ocurren tal como la fuente de datos
se replica al data warehouse.

El modelo de datos del data warehouse (es decir, los elementos de datos y sus relaciones).
Un registro de cuando los nuevos elementos de datos se agregan al data warehouse y cuando los
elementos de datos antiguos se eliminan o se resumen.
Los niveles de sumarizacin, el mtodo de sumarizacin y las tablas de registros de su data warehouse.
Algunas implementaciones de la metadata tambin incluyen definiciones de la(s) vista(s) presentada(s) a
los usuarios del data warehouse. Tpicamente, se definen vistas mltiples para favorecer las preferencias
variadas de diversos grupos de usuarios. En otras implementaciones, estas descripciones se almacenan
en un Catlogo de Informacin.
Los esquemas y subesquemas para bases de datos operacionales, forman una fuente ptima de entrada
cuando se crea la metadata. Hacer uso de la documentacin existente, especialmente cuando est
disponible en forma electrnica, puede acelerar el proceso de definicin de la metadata del ambiente
data warehousing.
La metadata sirve, en un sentido, como el corazn del ambiente data warehousing. Crear definiciones
de metadata completa y efectiva puede ser un proceso que consuma tiempo, pero lo mejor de las
definiciones y si usted usa herramientas de gestin de software integrado, son los esfuerzos que darn
como resultado el mantenimiento del data warehouse.
1.7 FLUJO DE DATOS
Existe un flujo de datos normal y predecible dentro del data warehouse. La Figura N 10 muestra ese
flujo.
Los datos ingresan al data warehouse desde el ambiente operacional. (Hay pocas excepciones a esta
regla).

Al ingresar al data warehouse, la informacin va al nivel de detalle actual, tal como se muestra. Se
queda all y se usa hasta que ocurra uno de los tres eventos siguientes:

Sea eliminado

Sea resumido

Sea archivado

Con el proceso de desactualizacin en un data warehouse se mueve el detalle de la data actual a data
antigua, basado en el tiempo de los datos. El proceso de esquematizacin usa el detalle de los datos
para calcular los datos en forma ligera y completamente resumidos.
Hay pocas excepciones al flujo mostrado. Sin embargo, en general, para la mayora de datos
encontrados en un data warehouse, el flujo de la informacin es como se ha explicado.

1.8 MEDIOS DE ALMACENAMIENTO PARA INFORMACION ANTIGUA

El smbolo mostrado en la Figura N 11 para medios de almacenamiento de informacin antigua es la
cinta magntica, que puede usarse para almacenar este tipo de informacin. De hecho hay una amplia
variedad de medios de almacenamiento que deben considerarse para almacenar datos ms antiguos. En
la figura se muestra algunos de esos medios.
Dependiendo del volumen de informacin, la frecuencia de acceso, el costo de los medios y el tipo de
acceso, es probable que otros medios de almacenamiento sirvan a las necesidades del nivel de detalle
ms antiguo en el data warehouse.

1.9 USOS DEL DATA WAREHOUSE

Los datos operacionales y los datos del data warehouse son accesados por usuarios que usan los datos
de maneras diferentes.
Uso de
Uso de Base de Datos Operacionales
Muchos usuarios concurrentes
Consultas predefinidas y
actualizables
Cantidades pequeas de datos
detallados
Requerimientos de respuesta
inmediata

Data Warehouse
Pocos usuarios concurrentes
Consultas complejas,
frecuentemente
no anticipadas.
Cantidades grandes de datos
detallados
Requerimientos de respuesta no
crticos

Maneras diferentes de uso de datos

Los usuarios de un data warehouse necesitan acceder a los datos complejos, frecuentemente desde
fuentes mltiples y de formas no predecibles.
Los usuarios que accedan a los datos operacionales, comnmente efectan tareas predefinidas que,
generalmente requieren acceso a una sola base de datos de una aplicacin. Por el contrario, los usuarios
que accedan al data warehouse, efectan tareas que requieren acceso a un conjunto de datos desde
fuentes mltiples y frecuentemente no son predecibles. Lo nico que se conoce (si es modelada
correctamente) es el conjunto inicial de datos que se han establecido en el depsito.
Por ejemplo, un especialista en el cuidado de la salud podra necesitar acceder a los datos actuales e
histricos para analizar las tendencias de costos, usando un conjunto de consultas predefinidas. Por el
contrario, un representante de ventas podra necesitar acceder a los datos de cliente y producto para
evaluar la eficacia de una campaa de marketing, creando consultas base o ad-hoc para encontrar
nuevamente necesidades definidas.
Slo pocos usuarios acceden a los datos concurrentemente
En contraste a la produccin de sistemas que pueden manejar cientos o miles de usuarios concurrentes,
al data warehouse acceda un limitado conjunto de usuarios en cualquier tiempo determinado.

Los usuarios generan un procesamiento no predecible complejo

Los usuarios del data warehouse generan consultas complejas. A veces la respuesta a una consulta
conduce a la formulacin de otras preguntas ms detalladas, en un proceso llamado drilling down. El
data warehouse puede incluir niveles de resmenes mltiples, derivado de un conjunto principal, nico,
de datos detallados, para soportar este tipo de uso.
En efecto, los usuarios frecuentemente comienzan buscando en los datos resumidos y como identifican
reas de inters, comienzan a acceder al conjunto de datos detallado. Los conjuntos de datos resumidos
representan el "Qu" de una situacin y los conjuntos de datos detallados permiten a los usuarios
construir un cuadro sobre "Cmo" se ha derivado esa situacin.
Las consultas de los usuarios accedan a cantidades grandes de datos
Debido a la necesidad de investigar tendencias y evaluar las relaciones entre muchas clases de datos, las
consultas al data warehouse permiten acceder a volmenes muy grandes tanto de data detallada como
resumida. Debido a los requerimientos de datos histricos, los data warehouses evolucionan para llegar
a un tamao ms grande que sus orgenes operacionales (de 10 a 100 veces ms grande).
Las consultas de los usuarios no tienen tiempos de respuesta crticos
Las transacciones operacionales necesitan una respuesta inmediata porque un cliente puede estar
esperando una respuesta. En el data warehouse, por el contrario, tiene un requerimiento de respuesta
no-crtico porque el resultado frecuentemente se usa en un proceso de anlisis y toma de decisiones.
Aunque los tiempos de respuesta no son crticos, los usuarios esperan una respuesta dentro del mismo
da en que es hecha la consulta.
Por lo general, los diferentes niveles de datos dentro del data warehouse reciben diferentes usos. A ms
alto nivel de esquematizacin, se tiene mayor uso de los datos.
En la Figura N 12 se muestra que hay mayor uso de los datos completamente resumidos, a diferencia
de la informacin antigua que apenas es usada.
Hay una buena razn para mover una organizacin al paradigma sugerido en la figura, la utilizacin del
recurso. La data ms resumida, permite capturar los datos en forma ms rpida y eficiente. Si en una
tarea se encuentra que se hace mucho procesamiento a niveles de detalle del data warehouse, entonces
se consumir muchos recursos de mquina. Es mejor hacer el procesamiento a niveles ms altos de
esquematizacin como sea posible.
Para muchas tareas, el analista de sistemas de soporte de decisiones usa la informacin a nivel de
detalle en un pre data warehouse. La seguridad de la informacin de detalle se consigue de muchas
maneras, aun cuando estn disponibles otros niveles de esquematizacin. Una de las actividades del
diseador de datos es el de desconectar al usuario del sistema de soporte de decisiones del uso
constante de datos a nivel de detalle ms bajo.
El diseador de datos tiene dos predisposiciones:
Instalar un sistema chargeback, donde el usuario final pague por los recursos consumidos

Sealar el mejor tiempo de respuesta que puede obtenerse cuando se trabaja con la data a un nivel alto
de esquematizacin, a diferencia de un pobre tiempo de respuesta que resulta de trabajar con los datos
a un nivel bajo de detalle.
Para ilustrar cmo un data warehouse puede ayudar a una organizacin a mejorar sus operaciones, se
muestra un ejemplo de lo que es el desarrollo de actividades sin tener un data warehouse.

Ejemplo:
Preparacin de un reporte complejo
Considere un problema bastante tpico en una compaa de fabricacin grande en el que se pide una
informacin (un reporte) que no est disponible.

El informe incluye las finanzas actuales, el inventario y la condicin de personal, acompaado de

comparaciones del mes actual con el anterior y el mismo mes del ao anterior, con una comparacin
adicional de los 3 aos precedentes. Se debe explicar cada desviacin de la tendencia que cae fuera de
un rango predefinido.
Sin un data warehouse, el informe es preparado de la manera siguiente:
La informacin financiera actual se obtiene desde una base de datos mediante un programa de
extraccin de datos, el inventario actual de otro programa de extraccin de otra base de datos, la
condicin actual de personal de un tercer programa de extraccin y la informacin histrica desde un
backup de cinta magntica o CD-ROM.
Lo ms interesante es que se ha pedido otro informe que contine al primer informe (debido a que las
preguntas se originaron a partir del anterior). El hecho es, que ninguno de los trabajos realizados hasta
aqu (por ejemplo, diversos programas de extraccin) se pueden usar para los prximos o para cualquier
reporte subsiguiente. Imagine el tiempo y el esfuerzo que se ha desperdiciado por un enfoque
anticuado. (Ver Figura N 13).
Las inconsistencias deben identificarse en cada conjunto de datos extrados y resolverse, por lo general,
manualmente. Cuando se completa todo este procesamiento, el reporte puede ser formateado,
impreso, revisado y transmitido.
Nuevamente, el punto importante aqu es que todo el trabajo desempeado para hacer este informe no
afecta a otros reportes que pueden solicitarse es decir, todos ellos son independientes y caros, desde el
punto de vista de recursos y productividad.
Al crear un data warehouse y combinar todos los datos requeridos, se obtienen los siguientes
beneficios:
Las inconsistencias de los datos se resuelven automticamente cuando los elementos de datos se cargan
en el data warehouse, no manualmente, cada vez que se prepara un reporte.
Los errores que ocurrieron durante el proceso complejo de la preparacin del informe, se minimizan
porque el proceso es ahora mucho ms simple.
Los elementos de datos son fcilmente accesibles para otros usos, no slo para un reporte particular.
Se crea una sola fuente.

1.10 CONSIDERACIONES ADICIONALES

Hay algunas consideraciones adicionales que deben tenerse en cuenta al construir y administrar el data
warehouse.
La primera consideracin es respecto al ndice. La informacin de los niveles de esquematizacin ms
altos pueden ser libremente indexados, mientras que las de los niveles ms bajos de detalle, por ser tan
voluminosa, pueden ser indexados moderadamente.
Por lo mismo, los datos en los niveles ms altos de detalle pueden ser reestructurados fcilmente,
mientras que el volumen de datos en los niveles ms inferiores es tan grande, que los datos no pueden
ser fcilmente reestructurados.
Por consiguiente, el modelo de datos y el diseo clsico fundamentan que el data warehouse se aplique
casi exclusivamente al nivel actual de detalle. En otras palabras, las actividades de modelamiento de
datos no se aplican a los niveles de esquematizacin, en casi todos los casos.
Otra consideracin estructural es la particin de la informacin en el data warehouse. El nivel de detalle
actual es casi siempre particionado.

La particin puede hacerse de dos maneras: al nivel de DBMS y al nivel de la aplicacin. En la particin
DBMS, se conoce las particiones y se administra por consiguiente. En el caso de la particin de las
aplicaciones, slo los programadores de las mismas conocen las particiones y la responsabilidad de su
administracin es asignada a ellos.
Al interior de las particiones DBMS, mucho de los trabajos de infraestructura se hacen
automticamente. Pero existe un elevado grado de rigidez asociada con la gestin automtica de las
particiones. En el caso de las particiones de las aplicaciones del data warehouse, la mayor parte del
trabajo recae sobre el programador, pero el resultado final es que la gestin de datos es ms flexible.

1.11 EJEMPLO DE UN DATA WAREHOUSE

En la Figura N 14 se muestra un ejemplo hipottico de un data warehouse estructurado para un centro
de produccin industrial.

Se muestra slo el detalle actual, no as los niveles de esquematizacin ni los archivos de detalle ms
antiguos.
Adems, se observa que hay tablas del mismo tipo divididas a travs del tiempo. Por ejemplo, para el
histrico de la fabricacin de las piezas, hay muchas tablas separadas fsicamente, representando cada
una un trimestre diferente. La estructura de los datos es consistente con la tabla de la elaboracin de las
piezas, aunque fsicamente hay muchas tablas que lgicamente incluyen el histrico.
Para los diferentes tipos de tablas hay diferentes unidades de tiempo que fsicamente dividen las
unidades de informacin. El histrico de fabricacin est dividido por trimestres, el histrico de la orden
de piezas est dividido por aos y el histrico de cliente es un archivo nico, no dividido por el tiempo.

As tambin, las diferentes tablas son vinculadas por medio de un identificador comn, piezas u rdenes
de piezas (la representacin de la interrelacin en el ambiente de depsito toma una forma muy
diferente al de otros ambientes, tal como el ambiente operacional).

1.12 EXCEPCIONES EN EL DATA WAREHOUSE

Mientras que los componentes del data warehouse trabajan de acuerdo al modelo descrito para casi
todos los datos, hay pocas excepciones tiles que necesitan ser discutidas.
Una de ellas es la data resumida pblica, que es la data que ha sido calculada fuera del data warehouse
pero es usada a travs de la corporacin. La data resumida pblica se almacena y administra en el data
warehouse, aunque su clculo se haya hecho fuera de l.
Un ejemplo clsico de data resumida pblica es el archivamiento trimestral hecho por cada compaa
pblica. Los contadores trabajan para producir cantidades como rentas trimestrales, gastos trimestrales,
ganancias trimestrales y otros. El trabajo hecho por los contadores est fuera del data warehouse. Sin
embargo, esas cantidades referenciales producidas por ellos se usan ampliamente dentro de la
corporacin para marketing, ventas, etc. Una vez que se haya hecho el archivo, los datos se almacenan
en el data warehouse.
Otra excepcin no considerada en este documento es la data externa.
Otro excepcional tipo de datos a veces encontrados en un data warehouse es el detalle de los datos
permanentes, que resulta de la necesidad de una corporacin para almacenar la data a un nivel
detallado permanentemente por razones ticas o legales.
Si una corporacin expone a sus trabajadores a sustancias peligrosas hay una necesidad de detalle de
datos permanente. Si una corporacin produce un producto que involucra la seguridad pblica, tal como
la construccin de las partes de aviones, hay una necesidad de datos permanentes. Si una corporacin
se compromete con contratos peligrosos, hay una necesidad de detalle de datos permanentes.
La organizacin simplemente no puede dejar los detalles porque en futuros aos, en el caso de una
demanda, una notificacin, un edificio en disputa, etc., se incrementara la exposicin de la compaa.
Por lo tanto hay un nico tipo de datos en el data warehouse conocido como detalle de datos
permanentes.
El detalle de datos permanentes comparte muchas de las mismas consideraciones como otro data
warehouse, excepto que:
El medio donde se almacena la data debe ser tan seguro como sea posible.
Los datos deben permitir ser restaurados.
Los datos necesitan un tratamiento especial en su indexacin, ya que de otra manera los datos pueden
no ser accesibles aunque se haya almacenado con mucha seguridad.
2. PROYECTO DE ELABORACIN DE UN DATA WAREHOUSE
2.1 FASE: ORGANIZACION

La planificacin es el proceso ms importante que determina la clase de tipo de estrategias data

warehousing que una organizacin iniciar.
2.1.1 FACTORES EN LA PLANIFICACION DE UN DATA WAREHOUSE
No existe una frmula de garanta real para el xito de la construccin de un data warehouse, pero hay
muchos puntos que contribuyen a ese objetivo.
A continuacin, se indican algunos puntos claves que deben considerarse en la planificacin de un data
warehouse:
1. Establecer una asociacin de usuarios, gestin y grupos
Es esencial involucrar tanto a los usuarios como a la gestin para asegurar que el data warehouse
contenga informacin que satisfaga los requerimientos de la empresa.
La gestin puede ayudar a priorizar la fase de la implementacin del data warehouse, as como tambin
la seleccin de herramientas del usuario. Los usuarios y la gestin justifican los costos del data
warehouse sobre cmo ser "su ambiente" y est basado primero en lo esperado y segundo, en el valor
comercial real.
2. Seleccionar una aplicacin piloto con una alta probabilidad de xito
Una aplicacin piloto de alcance limitado, con un reembolso medible para los usuarios y la gestin,
establecer el data warehouse como una tecnologa clave para la empresa. Estos mismos criterios
(alcance limitado, reembolso medible y beneficios claros para la empresa) se aplican a cada fase de la
implementacin de un data warehouse.
<![endif]>3. Construir prototipos rpida y frecuentemente
La nica manera para asegurar que el data warehouse rena las necesidades de los usuarios, es hacer el
prototipo a lo largo del proceso de implementacin y an ms all, as como agregar los nuevos datos
y/o los modelos en forma permanente. El trabajo continuo con los usuarios y la gestin es, nuevamente,
la clave.
4. Implementacin incremental
La implementacin incremental reduce riesgos y asegura que el tamao del proyecto permanezca
manejable en cada fase.
5. Reportar activamente y publicar los casos exitosos
La retroalimentacin de los usuarios ofrece una excelente oportunidad para publicar los hechos exitosos
dentro de una organizacin. La publicidad interna sobre cmo el data warehouse ha ayudado a los
usuarios a operar ms efectivamente puede apoyar la construccin del data warehouse a lo largo de una
empresa.
La retroalimentacin del usuario tambin ayuda a comprender cmo evoluciona la implementacin del
data warehouse a travs del tiempo para reunir requerimientos de usuario nuevamente identificados.

2.1.2 ESTRATEGIAS PARA EL DESARROLLO DE UN DATA WAREHOUSE

Antes de desarrollar un data warehouse, es crtico el desarrollo de una estrategia equilibrada que sea
apropiada para sus necesidades y sus usuarios.
Las preguntas que deben tenerse en cuenta son:
-

Quin es el auditorio?

Cul es el alcance?

Qu tipo de data warehouse debera construirse?

Existe un nmero de estrategias mediante las cuales las organizaciones pueden conseguir sus data
warehouses.
1ra.: Establecer un ambiente "data warehouse virtual", el cual puede ser creado por :
Instalacin de un conjunto de facilidades para acceso a datos, directorio de datos y gestin de proceso.
Entrenamiento de usuarios finales.
Control de cmo se usan realmente las instalaciones del data warehouse.
Basados en el uso actual, crear un data warehouse fsico para soportar los pedidos de alta frecuencia.
2da.: Construir una copia de los datos operacionales desde un sistema operacional nico y posibilitar al
data warehouse de una serie de herramientas de acceso a la informacin.
Esta estrategia tiene la ventaja de ser simple y rpida. Desafortunadamente, si los datos existentes son
de mala calidad y/o el acceso a los datos no ha sido previamente evaluado, entonces se puede crear una
serie de problemas.
3ra.: Finalmente, la estrategia data warehousing ptima es seleccionar el nmero de usuarios basados
en el valor de la empresa y hacer un anlisis de sus puntos, preguntas y necesidades de acceso a datos.
De acuerdo a estas necesidades, se construyen los prototipos data warehousing y se prueban para que
los usuarios finales puedan experimentar y modificar sus requerimientos.
Una vez se tenga un consenso general sobre las necesidades, entonces se consiguen los datos
provenientes de los sistemas operacionales existentes a travs de la empresa y/o desde fuentes
externas de datos y se cargan al data warehouse.
Si se requieren herramientas de acceso a la informacin, se puede tambin permitir a los usuarios
finales tener acceso a los datos requeridos usando sus herramientas favoritas propias, o facilitar la
creacin de sistemas de acceso a la informacin multidimensional de alta performance, usando el
ncleo del data warehouse como base.
En conclusin, no se tiene un enfoque nico para construir un data warehouse que se adapte a las
necesidades de las empresas, debido a que las necesidades de cada una de ellas son diferentes, al igual
que su contexto.

Adems, como la tecnologa data warehousing va evolucionando, se aprende cada vez ms y ms sobre
el desarrollo de data warehouses, que resulta en que el nico enfoque prctico para al almacenamiento
de datos es la evolucin de uno mismo.
2.1.3 ESTRATEGIAS PARA EL DISEO DE UN DATA WAREHOUSE
El diseo de los data warehouses es muy diferente al diseo de los sistemas operacionales tradicionales.
Se pueden considerar los siguientes puntos:
1ra. : Los usuarios de los data warehouses usualmente no conocen mucho sobre sus requerimientos y
necesidades como los usuarios operacionales.
2da.: El diseo de un data warehouse, con frecuencia involucra lo que se piensa en trminos ms
amplios y con conceptos del negocio ms difciles de definir que en el diseo de un sistema operacional.
Al respecto, un data warehouse est bastante cerca a Reingeniera de los Procesos del Negocio
(Business Process Reengineering).
3ra.: Finalmente, la estrategia de diseo ideal para un data warehousing es generalmente de afuera
hacia adentro (outside-in) a diferencia de arriba hacia abajo (top-down).
A pesar que el diseo del data warehouse es diferente al usado en los diseos tradicionales, no es
menos importante. El hecho que los usuarios finales tengan dificultad en definir lo que ellos necesitan,
no lo hace menos necesario. En la prctica, los diseadores de data warehouses tienen que usar muchos
"trucos" para ayudar a sus usuarios a "visualizar" sus requerimientos. Por ello, son esenciales los
prototipos de trabajo.
2.1.4 ESTRATEGIAS PARA LA GESTION DE UN DATA WAREHOUSE
Los data warehouses requieren una comercializacin y gestin muy cuidadosa. Debe considerarse lo
siguiente:
1ra.: Un data warehouse es una inversin buena slo si los usuarios finales realmente pueden conseguir
informacin vital ms rpida y ms barata de lo que obtienen con la tecnologa actual.
Como consecuencia, la gestin tiene que pensarse seriamente sobre cmo quieren sus depsitos para
su eficaz desempeo y cmo conseguirn llegar a los usuarios finales.
2da.: La administracin debe reconocer que el mantenimiento de la estructura del data warehouse es
tan crtico como el mantenimiento de cualquier otra aplicacin de misin-crtica.
De hecho, la experiencia ha demostrado que los data warehouses llegarn a ser rpidamente uno de los
sistemas ms usados en cualquier organizacin.
3ra.: La gestin debe comprender tambin que si se embarcan sobre un programa data warehousing, se
crearn nuevas demandas sobre sus sistemas operacionales, que son:
-

Demandas para mejorar datos

Demandas para una data consistente

Demandas para diferentes tipos de datos, etc.

2.2 FASE: DESARROLLO

2.2.1 PORQUE CONSTRUIR BLOQUES DE DATA WAREHOUSE?
Para ampliar un negocio, se necesita que la informacin sea comprensible. Para muchas compaas, sto
significa un gran data warehouse que muestre, junto a los datos no filtrados y dispersos, nuevas formas
creativas de presentacin.
Las herramientas para capturar y explorar los datos al detalle evolucionan, as como nuestra capacidad
para encontrar las formas de explotar los datos recolectados.
En los ltimos 10 aos se han combinado dos factores para ayudar a la difusin de los data warehouses.
Ellos son:
1 Se ha reconocido los beneficios del procesamiento analtico en lnea (On Line Analytical Processing OLAP), ms all de las reas tradicionales de marketing y finanzas.
Las organizaciones saben que los conocimientos inmersos en las masas de datos que rutinariamente
recogen sobre sus clientes, productos, operaciones y actividades comerciales, contribuyen a reducir los
costos de operacin y aumentar las rentas, por no mencionar que es ms fcil la toma de decisiones
estratgicas.
2 El crecimiento de la computacin cliente/servidor, ha creado servidores de hardware y software ms
poderosos y sofisticados que nunca. Los servidores de hoy compiten con las mainframes de ayer y
ofrecen arquitecturas de memoria tecnolgicamente superiores, procesadores de alta velocidad y
capacidades de almacenamiento masivas.
Al mismo tiempo, los Sistemas de Gestin de Base de Datos (Data Base Management Systems - DBMS(s))
modernos, proporcionan mayor soporte para las estructuras de datos complejas.
De esta renovacin de hardware y software surgen los data warehouses multiterabyte que ahora se ve
en ambientes de cliente/servidor.
2.2.2 CONSIDERACIONES PREVIAS AL DESARROLLO DE UN DATA WAREHOUSE
Hay muchas maneras para desarrollar data warehouses como tantas organizaciones existen. Sin
embargo, hay un nmero de dimensiones diferentes que necesitan ser consideradas:
Alcance de un data warehouse
Redundancia de datos
Tipo de usuario final
La Figura N 15 muestra un esquema bidimensional para analizar las opciones bsicas. La dimensin
horizontal indica el alcance del depsito y la vertical muestra la cantidad de datos redundantes que
deben almacenarse y mantenerse.

2.2.2.1 ALCANCE DEL DATA WAREHOUSE

El alcance de un data warehouse puede ser tan amplio como toda la informacin estratgica de la
empresa desde su inicio, o puede ser tan limitado como un data warehouse personal para un solo
gerente durante un ao.
En la prctica, en la amplitud del alcance, el mayor valor del data warehouse es para la empresa y lo ms
caro y consumidor de tiempo es crear y mantenerlo. Como consecuencia de ello, la mayora de las
organizaciones comienzan con data warehouses funcionales, departamentales o divisionales y luego los
expanden como usuarios que proveen retroalimentacin.
2.2.2.2 REDUNDANCIA DE DATOS
Hay tres niveles esenciales de redundancia de datos que las empresas deberan considerar en sus
opciones de data warehouse:
-

Data warehouses "virtual" o "Point to Point"

Data warehouses "centrales"

Data warehouses "distribuidos"

No se puede pensar en un nico enfoque. Cada opcin adapta un conjunto especfico de requerimientos
y una buena estrategia de almacenamiento de datos, lo constituye la inclusin de las tres opciones.
Data Warehouses "Virtual" o "Point to Point"
Una estrategia de data warehouses virtual, significa que los usuarios finales pueden acceder a bases de
datos operacionales directamente, usando cualquier herramienta que posibilite "la red de acceso de
datos".

Este enfoque provee flexibilidad as como tambin la cantidad mnima de datos redundantes que deben
cargarse y mantenerse. Adems, se pueden colocar las cargas de consulta no planificadas ms grandes,
sobre sistemas operacionales.
Como se ver, el almacenamiento virtual es, frecuentemente, una estrategia inicial, en organizaciones
donde hay una amplia (pero en su mayor parte indefinida) necesidad de conseguir la data operacional,
desde una clase relativamente grande de usuarios finales y donde la frecuencia probable de pedidos es
baja.
Los depsitos virtuales de datos proveen un punto de partida para que las organizaciones determinen
qu usuarios finales estn buscando realmente.
2. Data Warehouses "Centrales"
El concepto de data warehouses centrales es el concepto inicial que se tiene del data warehouse. Es una
nica base de datos fsica, que contiene todos los datos para un rea funcional especfica,
departamento, divisin o empresa.
Los data warehouses centrales se seleccionan por lo general donde hay una necesidad comn de los
datos informticos y un nmero grande de usuarios finales ya conectados a una red o computadora
central. Pueden contener datos para cualquier perodo especfico de tiempo. Comnmente, contienen
datos de sistemas operacionales mltiples.
Los data warehouses centrales son reales. Los datos almacenados en el data warehouse son accesibles
desde un lugar y deben cargarse y mantenerse sobre una base regular. Normalmente se construyen
alrededor de RDBMs avanzados o, en alguna forma, de servidor de base de datos informtico
multidimensional.
3. Data Warehouses Distribuidos
Los data warehouses distribuidos son aquellos en los cuales ciertos componentes del depsito se
distribuyen a travs de un nmero de bases de datos fsicas diferentes.
Cada vez ms, las organizaciones grandes estn tomando decisiones a niveles ms inferiores de la
organizacin y a la vez, llevando los datos que se necesitan para la toma de decisiones a la red de rea
local (Local Area Network - LAN) o computadora local que sirve al que toma decisiones.
Los data warehouses distribuidos comnmente involucran la mayora de los datos redundantes y como
consecuencia de ello, se tienen procesos de actualizacin y carga ms complejos.
2.2.2.3 TIPO DE USUARIO FINAL
De la misma forma que hay una gran cantidad de maneras para organizar un data warehouse, es
importante notar que tambin hay una gama cada vez ms amplia de usuarios finales.
En general, se puede considerar tres grandes categoras:
Ejecutivos y gerentes
"Power users" o "Buzo de Informacin" (analistas financieros y de negocios, ingenieros, etc.)

Usuarios de soporte (de oficina, administrativos, etc.).

Cada una de estas categoras diferentes de usuario tienen su propio conjunto de requerimientos para
los datos, acceso, flexibilidad y facilidad de uso.
2.2.3 ELEMENTOS CLAVES PARA EL DESARROLLO DE UN DATA WAREHOUSE
Los data warehouses exitosos comienzan cuando se escogen e integran satisfactoriamente tres
elementos claves.
Un data warehouse est integrado por un servidor de hardware y los DBMS que conforman el depsito.
Del lado del hardware, se debe combinar la configuracin de plataformas de los servidores, mientras se
decide cmo aprovechar los saltos casi constantes de la potencia del procesador. Del lado del software,
la complejidad y el alto costo de los DBMSes fuerzan a tomar decisiones drsticas y balances
comparativos inevitables, con respecto a la integracin, requerimientos de soporte, desempeo,
eficiencia y confiabilidad.
Si se escoge incorrectamente, el data warehouse se convierte en una gran empresa con problemas
difciles de trabajar en su entorno, costoso para arreglar y difcil de justificar.
Para conseguir que la implementacin del depsito tenga un inicio exitoso, se necesita enfocar hacia
tres bloques claves de construccin:
-

Arquitectura total del depsito

Arquitecturas del servidor

Sistemas de Gestin de Base de Datos

A continuacin se presentan algunas recomendaciones para tomar las correctas elecciones para su
empresa.
2.2.3.1 DISEO DE LA ARQUITECTURA
a) Arquitectura del Depsito
El desarrollo del data warehouse comienza con la estructura lgica y fsica de la base de datos del
depsito ms los servicios requeridos para operar y mantenerlo. Esta eleccin conduce a la seleccin de
otros dos tems fundamentales: el servidor de hardware y el DBMS.
La plataforma fsica puede centralizarse en una sola ubicacin o distribuirse regional, nacional o
internacionalmente. A continuacin se dan las siguientes alternativas de arquitectura:
1 Un plan para almacenar los datos de su compaa, que podra obtenerse desde fuentes mltiples
internas y externas, es consolidar la base de datos en un data warehouse integrado. El enfoque
consolidado proporciona eficiencia tanto en la potencia de procesamiento como en los costos de
soporte. (Ver Figura N 16).

2 La arquitectura global distribuye informacin por funcin, con datos financieros sobre un servidor en
un sitio, los datos de comercializacin en otro y los datos de fabricacin en un tercer lugar. (Ver Figura
N 17)

3 Una arquitectura por niveles almacena datos altamente resumidos sobre una estacin de trabajo del
usuario, con resmenes ms detallados en un segundo servidor y la informacin ms detallada en un
tercero.
La estacin de trabajo del primer nivel maneja la mayora de los pedidos para los datos, con pocos
pedidos que pasan sucesivamente a los niveles 2 y 3 para la resolucin.
Las computadoras en el primer nivel pueden optimizarse para usuarios de carga pesada y volumen bajo
de datos, mientras que los servidores de los otros niveles son ms adecuados para procesar los
volmenes pesados de datos, pero cargas ms livianas de usuario. (Ver figura N 18).

b) Arquitectura del servidor

Al decidir sobre una estructura de depsito distribuida o centralizada, tambin se necesita considerar
los servidores que retendrn y entregarn los datos. El tamao de su implementacin (y las necesidades
de su empresa para escalabilidad, disponibilidad y gestin de sistemas) influir en la eleccin de la
arquitectura del servidor.
1 Servidores de un solo procesador
Los servidores de un slo procesador son los ms fciles de administrar, pero ofrecen limitada potencia
de procesamiento y escalabilidad. Adems, un servidor slo presenta un nico punto de falla, limitando
la disponibilidad garantizada del depsito.
Se puede ampliar un solo servidor de redes mediante arquitecturas distribuidas que hacen uso de
subproductos, tales como Ambientes de Computacin Distribuida (Distributed Computing Environment DCE) o Arquitectura Broker de Objeto Comn (Common Objects Request Broker Architecture - CORBA),
para distribuir el trfico a travs de servidores mltiples.
Estas arquitecturas aumentan tambin la disponibilidad, debido a que las operaciones pueden
cambiarse al servidor de backup si un servidor falla, pero la gestin de sistemas es ms compleja.
2 Multiprocesamiento simtrico

Las mquinas de multiprocesamiento simtrico (Symmetric MultiProcessing - SMP) aumentan mediante

la adicin de procesadores que comparten la memoria interna de los servidores y los dispositivos de
almacenamiento de disco.
Se puede adquirir la mayora de SMP en configuraciones mnimas (es decir, con dos procesadores) y
levantar cuando es necesario, justificando el crecimiento con las necesidades de procesamiento. La
escalabilidad de una mquina SMP alcanza su lmite en el nmero mximo de procesadores soportados
por los mecanismos de conexin (es decir, el backplane y bus compartido).
3 Procesamiento en paralelo masivo
Una mquina de procesamiento en paralelo masivo (Massively Parallel Processing - MPP), conecta un
conjunto de procesadores por medio de un enlace de banda ancha y de alta velocidad. Cada nodo es un
servidor, completo con su propio procesador (posiblemente SMP) y memoria interna. Para optimizar
una arquitectura MPP, las aplicaciones deben ser "paralelizadas" es decir, diseadas para operar por
separado, en partes paralelas.
Esta arquitectura es ideal para la bsqueda de grandes bases de datos. Sin embargo, el DBMS que se
selecciona debe ser uno que ofrezca una versin paralela. Y an entonces, se requiere un diseo y
afinamiento esenciales para obtener una ptima distribucin de los datos y prevenir "hot spots" o "data
skew" (donde una cantidad desproporcionada del procesamiento es cambiada a un nodo de
procesamiento, debido a la particin de los datos bajo su control).
4 Acceso de memoria no uniforme
La dificultad de mover aplicaciones y los DBMS a agrupaciones o ambientes realmente paralelos ha
conducido a nuevas y recientes arquitecturas, tales como el acceso de memoria no uniforme (Non
Uniform Memory Access - NUMA).
NUMA crea una sola gran mquina SMP al conectar mltiples nodos SMP en un solo (aunque
fsicamente distribuida) banco de memoria y un ejemplo nico de OS. NUMA facilita el enfoque SMP
para obtener los beneficios de performance de las grandes mquinas MPP (con 32 o ms procesadores),
mientras se mantiene las ventajas de gestin y simplicidad de un ambiente SMP estndar.
Lo ms importante de todo, es que existen DBMS y aplicaciones que pueden moverse desde un solo
procesador o plataforma SMP a NUMA, sin modificaciones.
2.2.3.2 SISTEMAS DE GESTION DE BASES DE DATOS
Los data warehouses (conjuntamente con los sistemas de soporte de decisin [Decision Support
Systems - DSS] y las aplicaciones cliente/servidor), fueron los primeros xitos para el DBMS relacional
(Relational Data Base Management Systems - RDBMS).
Mientras la gran parte de los sistemas operacionales fueron resultados de aplicaciones basadas en
antiguas estructuras de datos, los depsitos y sistemas de soporte de decisiones aprovecharon el
RDBMS por su flexibilidad y capacidad para efectuar consultas con un nico objetivo concreto.
Los RDBMS son muy flexibles cuando se usan con una estructura de datos normalizada. En una base de
datos normalizada, las estructuras de datos son no redundantes y representan las entidades bsicas y
las relaciones descritas por los datos (por ejemplo productos, comercio y transaccin de ventas). Pero

un procesamiento analtico en lnea (OLAP) tpico de consultas que involucra varias estructuras, requiere
varias operaciones de unin para colocar los datos juntos.
La performance de los RDBMS tradicionales es mejor para consultas basadas en claves ("Encuentre
cuenta de cliente #2014") que para consultas basadas en el contenido ("Encuentre a todos los clientes
con un ingreso sobre $ 10,000 que hayan comprado un automvil en los ltimos seis meses").
Para el soporte de depsitos a gran escala y para mejorar el inters hacia las aplicaciones OLAP, los
proveedores han aadido nuevas caractersticas al RDBMS tradicional. Estas, tambin llamadas
caractersticas super relacionales, incluyen el soporte para hardware de base de datos especializada,
tales como la mquina de base de datos Teradata.
Los modelos super relacionales tambin soportan extensiones para almacenar formatos y operaciones
relacionales (ofrecidas por proveedores como RedBrick) y diagramas de indexacin especializados, tales
como aquellos usados por Sybase IQ. Estas tcnicas pueden mejorar el rendimiento para las
recuperaciones basadas en el contenido, al pre juntar tablas usando ndices o mediante el uso de listas
de ndice totalmente invertidos.
Muchas de las herramientas de acceso a los data warehouses explotan la naturaleza multidimensional
del data warehouse. Por ejemplo, los analistas de marketing necesitan buscar en los volmenes de
ventas por producto, por mercado, por perodo de tiempo, por promociones y niveles anunciados y por
combinaciones de estos diferentes aspectos.
La estructura de los datos en una base de datos relacional tradicional, facilita consultas y anlisis a lo
largo de dimensiones diferentes que han llegado a ser comunes. Estos esquemas podran usar tablas
mltiples e indicadores para simular una estructura multidimensional. Algunos productos DBMS, tales
como Essbase y Gentium, implementan tcnicas de almacenamiento y operadores que soportan
estructuras de datos multidimensionales.
Mientras las bases de datos multidimensionales (MultiDimensional Databases - MDDBs) ayudan
directamente a manipular los objetos de datos multidimensionales (por ejemplo, la rotacin fcil de los
datos para verlos entre dimensiones diferentes, o las operaciones de drill down que sucesivamente
exponen los niveles de datos ms detallados), se debe identificar estas dimensiones cuando se
construya la estructura de la base de datos. As, agregar una nueva dimensin o cambiar las vistas
deseadas, puede ser engorroso y costoso. Algunos MDDBs requieren un recargue completo de la base
de datos cuando ocurre una reestructuracin.
2.2.3.3 NUEVAS DIMENSIONES
Una limitacin de un RDBMS y un MDDB, es la carencia de soporte para tipos de datos no tradicionales
como imgenes, documentos y clips de video/ audio. Si usted necesita estos tipos de objetos en su data
warehouse, busque un DBMS relacional-objeto (Ejemplo: Illustra de Informix).
Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de base de datos
pueden acomodar estos tipos de datos, slo con extensiones basadas en cierta referencias, tales como
indicadores de archivos que contienen los objetos. Muchos RDBMS almacenan los datos complejos
como objetos grandes binarios (Binary Large Objects - BLOBs). En este formato, los objetos no pueden
ser indexados, clasificados, o buscados por el servidor.
Los DBMS relacional-objeto, de otro lado, almacenan los datos complejos como objetos nativos y
pueden soportar las grandes estructuras de datos encontradas en un ambiente orientado a objetos.

Estos sistemas de base de datos naturalmente acomodan no slo tipos de datos especiales sino tambin
los mtodos de procesamiento que son nicos para cada uno de ellos.
Pero una desventaja del enfoque relacional-objeto, es que la encapsulacin de los datos dentro de los
tipos especiales de datos (una serie de precios de stock a travs del tiempo en cada registro de una tabla
de stock, por ejemplo), requiere de operadores especializados para que hagan bsquedas simples
previamente (por ejemplo, "Encontrar todas las existencias que han mostrado una disminucin en el
precio de Abril a Mayo 1996").
La seleccin del DBMS est tambin sujeta al servidor de hardware que se usa. Algunos RDBMS, como el
DB2 Paralelo, Informix XPS y el Oracle Paralelo, ofrecen versiones que soportan operaciones paralelas. El
software paralelo divide consultas, uniones a travs de procesadores mltiples y corre estas operaciones
simultneamente para mejorar la performance.
Se requiere el paralelismo para el mejor desempeo en los servidores MPP grandes y SMP agrupados.
No es an una opcin con MDDBS o DBMS relacional-objeto.
En la tabla "Cmo comparar DBMS" se resume los pro y los contra de los diferentes tipos de DBMS para
operaciones de data warehouse.
La tabla "Matriz de Decisin del Data Warehouse" contiene algunos ejemplos de cmo afectan estos
criterios de decisin en la eleccin de una arquitectura de servidor/ data warehouse.
Cmo comparar DBMSes?
Caractersticas/Funcin Relacional

SuperRelacional

Multidimensional
(Lgico)

Estructuras
Normalizadas
Tipos de datos
abstractos
Paralelismo
Estructuras
Multidimensionales
Drill-Down
Rotacin
Operaciones
dependientes de datos
=si
Matriz de Decisin para el Data Warehouse
Para estos ambientes
Requerimientos
Soporte de
Usuarios
comerciales
Sistemas
Alcance:
Pequea Local mnimo departamental
Usos: anlisis de
central
ubicacin nica
datos
promedio
Alcance:
departamental

Grandeanalistas en

Multidimensional Objeto(Fsico)
Relacional

Elija
Arquitectura Servidor

DBMS

Consolidado Procesador
nico

MDDB

paquete

Local mnimo - Seccionado -

o SMP
Grupos de
SMP

RDBMS para

Usos: anlisis ms
informtica

Alcance: empresa

una sola
ubicacin;
usuarios
informticos
dispersos
Grande;
geogrfica-

Usos: anlisis ms

mente disperso

informtica
Alcance:
departamental

Pequea pocas

Usos: investigacin

ubicaciones

central
promedio

detalle en
central para central;
centralMDDB
resumen en SP o SMP para
para local
local
local

Central fuerte Centralizado

Grupos de
SMP

Central fuerte Centralizado MPP

Objetorelacionalsoporte
Web
RDBMS con
soporte
paralelo

2.2.3.4 COMBINACION DE LA ARQUITECTURA CON EL SISTEMA DE GESTION DE BASE DE DATOS

Para seleccionar la combinacin correcta de la arquitectura del servidor y el DBMS, primero es necesario
comprender los requerimientos comerciales de su compaa, su poblacin de usuarios y las habilidades
del personal de soporte.
Las implementaciones de los data warehouses varan apreciablemente de acuerdo al rea. Algunos son
diseados para soportar las necesidades de anlisis especfico para un solo departamento o rea
funcional de una organizacin, tales como finanzas, ventas o marketing. Las otras implementaciones
renen datos a travs de toda la empresa para soportar una variedad de grupos de usuarios y funciones.
Por regla general, a mayor rea del depsito, se requiere mayor potencia y funcionalidad del servidor y
el DBMS.
Los modelos de uso de los data warehouses son tambin un factor. Las consultas y vistas de reportes
preestructuradas frecuentemente satisfacen a los usuarios informticos, mientras que hay menos
demandas sobre el DBMS y la potencia de procesamiento del servidor. El anlisis complejo, que es tpico
de los ambientes de decisin-soporte, requiere ms poder y flexibilidad de todos los componentes del
servidor. Las bsquedas masivas de grandes data warehouses favorecen el paralelismo en el DBMS y el
servidor.
Los ambientes dinmicos, con sus requerimientos siempre cambiantes, se adaptan mejor a una
arquitectura de datos simple, fcilmente cambiable (por ejemplo, una estructura relacional altamente
normalizada), antes que una estructura intrincada que requiere una reconstruccin despus de cada
cambio (por ejemplo, una estructura multidimensional).
El valor de la data fresca requerida indica cun importante es para el data warehouse renovar y cambiar
los datos. Los grandes volmenes de datos que se refrescan a intervalos frecuentes, favorecen una
arquitectura fsicamente centralizada para soportar una captura de datos eficiente y minimizar el
tiempo de transporte de los datos.
Un perfil de usuario debera identificar quines son los usuarios de su data warehouse, dnde se ubican
y cuntos necesita soportar. La informacin sobre cmo cada grupo espera usar los data warehouses,
ayudar a analizar los diversos estilos de uso.
Conocer la ubicacin fsica de sus usuarios ayudar a determinar cmo y a qu rea necesita distribuir el
data warehouse. Una arquitectura por niveles podra usar servidores en el lugar de las redes de rea

local. O puede necesitar un enfoque centralizado para soportar a los trabajadores que se movilizan y
que trabajan en el depsito desde sus laptops.
El nmero total de usuarios y sus modelos de conexin determinan el tamao de sus servidores de
depsito. Los tamaos de memoria y los canales de I/O deben soportar el nmero previsto de usuarios
concurrentes bajo condiciones normales, as como tambin en las horas punta de su organizacin.
Finalmente, se debe factorizar la sofisticacin del personal de soporte. Los recursos de los sistemas de
informacin (Information System - IS) que estn disponibles dentro de su organizacin, pueden limitar la
complejidad o sofisticacin de la arquitectura del servidor. Sin el personal especializado interno o
consultores externos, es difcil de crear y mantener satisfactoriamente una arquitectura que requiere
paralelismo en la plataforma del servidor (MPP o SMP agrupado, por ejemplo).
2.2.3.5 PLANES DE EXPANSION
Como su depsito evoluciona y los datos que contiene llegan a ser ms accesible, los empleados
externos al depsito podran descubrir tambin el valor de sus datos. Al enlazar su data warehouse a
otros sistemas (tanto internos como externos a la organizacin), se puede compartir informacin con
otras entidades comerciales con poco o sin desarrollo. Los mensajes E-mail, servidores Web y
conexiones Intranet/Internet, pueden entregar listas por niveles a sus proveedores o segn su
condicin, a sus socios de negocio.
Como los data warehouses continan creciendo en sofisticacin y uso, los datos acumulados dentro de
una empresa llegarn a ser ms organizados, ms interconectados, ms accesibles y, en general, ms
disponibles a ms empleados.
El resultado ser la obtencin de mejores decisiones en el negocio, ms oportunidades y ms claridad de
trabajo.
2.2.4 CONFIABILIDAD DE LOS DATOS
La data "sucia" es peligrosa. Las herramientas de limpieza especializadas y las formas de programar de
los clientes proporcionan redes de seguridad.
No importa cmo est diseado un programa o cun hbilmente se use. Si se alimenta mala
informacin, se obtendr resultados incorrectos o falsos. Desafortunadamente, los datos que se usan
satisfactoriamente en las aplicaciones de lnea comercial operacionales pueden ser basura en lo que
concierne a la aplicacin data warehousing.

Los datos "sucios" pueden presentarse al ingresar informacin en una entrada de datos (por ejemplo,
"Sitsemas S. A." en lugar de "Sistemas S. A." ) o de otras causas. Cualquiera que sea, la data sucia daa la
credibilidad de la implementacin del depsito completo. A continuacin, en la Figura N 23 se muestra
un ejemplo de formato de ventas en el que se pueden presentar errores.
Afortunadamente, las herramientas de limpieza de datos pueden ser de gran ayuda. En algunos casos,
puede crearse un programa de limpieza efectivo. En el caso de bases de datos grandes, imprecisas e
inconsistentes, el uso de las herramientas comerciales puede ser casi obligatorio.
Decidir qu herramienta usar es importante y no solamente para la integridad de los datos. Si se
equivoca, se podra malgastar semanas en recursos de programacin o cientos de miles de dlares en
costos de herramientas.
2.2.4.1 LIMPIEZA DE LOS DATOS

La limpieza de una data "sucia" es un proceso multifactico y complejo. Los pasos a seguir son los
siguientes:
1 Analizar sus datos corporativos para descubrir inexactitudes, anomalas y otros problemas.
2 Transformar los datos para asegurar que sean precisos y coherentes.
3 Asegurar la integridad referencial, que es la capacidad del data warehouse, para identificar
correctamente al instante cada objeto del negocio, tales como un producto, un cliente o un empleado.
4 Validar los datos que usa la aplicacin del data warehouse para realizar las consultas de prueba.
5 Producir la metadata, una descripcin del tipo de datos, formato y el significado relacionado al
negocio de cada campo.
6 Finalmente, viene el paso crucial de la documentacin del proceso completo para que se pueda
ampliar, modificar y arreglar los datos en el futuro con ms facilidad.
En la prctica, se tendra que realizar mltiples pasos como parte de una operacin nica o cuando use
una sola herramienta. En particular, limpiar la data y asegurar la integridad referencial son procesos
interdependientes.
Las herramientas comerciales pueden ayudar en cada uno de estos pasos. Sin embargo, es posible
escribir sus propios programas para hacer el mismo trabajo.
Los programas de limpieza de datos no proporcionan mucho razonamiento, por lo que las compaas
necesitan tomar sus decisiones en forma manual, basados en informacin importante y reportes de
auditora de datos.
Cada vez que se carga un nuevo conjunto de datos, la limpieza de datos comnmente constituye cerca
del 25 por ciento de lo que puede ser un proceso de cuatro semanas.
A continuacin, se darn algunos ejemplos de las experiencias de las empresas que han realizado
limpieza de datos para un ambiente data warehousing.
Ejemplo 1:
CompuCom Systems, un gran integrador de sistemas basados en Dallas, implement un registro de 12
millones, en un depsito de 10 Gb para el soporte de decisiones internas y de los clientes, segn el orden
y la condicin y producir informacin por medio del Web.
CompuCom implement algunas rutinas de mejoramiento de datos en lenguajes de cuarta generacin
(4GL), asociado con su base de datos Progress, la cual corre sobre un HP 9000. El incremento incluye
desciframiento de valores de columnas en descripciones inglesas cortas o mnemotecnia. El cdigo de
limpieza de datos, tales como las conversiones de fecha y datos, estn escritas en lenguaje C.
La ventaja de sto es que CompuCom ahora posee estas rutinas y puede usarlas en otras aplicaciones.
Los usuarios ayudaron a definir los requerimientos de limpieza de datos, ya que son ellos los que mejor
conocen los datos y pueden informar sobre qu tipo de datos sucios deben salir y cmo limpiarlos.

La compaa no usa una herramienta de limpieza comercial porque gran parte de sus datos est en la
misma forma bsica. As, la compaa puede fcilmente usar de nuevo las rutinas escritas.
La desventaja principal ha sido la cantidad de tiempo de desarrollo (alrededor de una semana) que se
necesit para crear las rutinas. Aunque tienen cierta dificultad de tiempo para mantenerse al da con la
demanda y han buscado paquetes de software [comercial], no han encontrado an, en el mercado, algo
que se ajuste mejor a sus requerimientos.
Ejemplo 2:
Ohio Casualty Insurance (Hamilton, OH) experiment por dos aos con la limpieza in-house, usando
programas COBOL, antes de usar la herramienta comercial, Integrity Data Reengineering Tool de Vality
Technology.
El data warehouse de Ohio Casualty combina registros asociados con alrededor de 1 milln de plizas de
seguro personales, incluyendo auto y plizas de casa propia. Como una prueba, la compaa comenz
con 3,500 plizas de sus empleados.
Sin embargo, es difcil tratar de programar para todas las situaciones en que se puede caer. Despus de
tomar un ao en desarrollar programas genricos de extraer/ transformar/cargar, se necesit otro ao,
para programar en Cobol y editar el manual, para conseguir los datos de las plizas correctos para el
depsito.
La herramienta Vality Integrity Data Reengineering ayuda a atacar el primer conjunto de datos de los
clientes - alrededor de 15, 000 plizas en el centro comercial Denver de la compaa. Aunque el personal
de Ohio Casualty todava necesita investigar las anomalas que ha descubierto el producto Vality, no se
ha requerido ninguna programacin o redaccin del manual de los datos. Los datos estuvieron listos
para el depsito en alrededor de seis semanas.
Ejemplo 3:
Intel (Hillsboro) es un ejemplo de compaa que ha realizado exitosamente una limpieza de datos inhouse, aunque con ciertos problemas. Inicialmente pretendi encargar su limpieza de datos a una
agencia de servicios, para un depsito de aproximadamente 1 milln de registros tomados desde cinco
sistemas operacionales.
La agencia de servicios prometi identificar las relaciones entre los diversos grupos dentro de las
compaas clientes. Adems, la agencia proveera informacin industrial para las organizaciones de
clientes, tales como el nmero de empleados, las rentas y el crecimiento, las cuales seran valiosas para
las ventas de Intel. Desafortunadamente, la agencia de servicio no hizo un buen trabajo de identificar las
relaciones entre los clientes, lo que dio como resultado el hecho de que algunas personas estuvieron
asociadas con compaas equivocadas.
Intel tom la cinta de la agencia de servicio y luego corri los datos con el paquete de anlisis estadstico
SAS, del Instituto SAS, para identificar y corregir los problemas con las relaciones con un tope de 10
agrupaciones (es decir, las primeras compaas en una relacin jerrquica nica).
La compaa luego us las herramientas de base de datos Oracle para propiciar el anlisis y la limpieza.
Ya que la nueva data llegaba todo el tiempo, algunas de las rutinas de limpieza de Oracle fueron
implementadas como procedimientos almacenados para que puedan correr automticamente contra la
nueva data.

Intel an persiste en encargar las tareas de la limpieza de los datos. Sin embargo, la compaa planea
mantener la limpieza in-house hasta que encuentre una agencia de servicio aceptable.
Ejemplo 4:
CrediCard (So Paulo, Brasil), un gran emisor de tarjetas de crdito en Sudamrica, consigui
herramientas de limpieza y mejora de datos como parte de la implementacin de un data warehouse por
Market Knowledge, una filial de Equifax.
El personal de comercializacin de CrediCard usa aproximadamente 200 rutinas para efectuar
operaciones de limpieza, tales como la eliminacin de datos malos o sin uso, correccin de valores
equivocados y estandarizacin de formatos diversos.
Adems, ellos pueden mejorar los datos al realizar operaciones como correccin de cantidades
monetarias por la inflacin y la devaluacin, creando un campo de edad virtual basado en la fecha de
nacimiento de una persona y aadiendo datos de censos a los registros entrantes. Estas rutinas (por
ejemplo, correccin de inflacin) favorecen particularmente a los requerimientos brasileos.
Ellos adems estn diseados para el uso del personal de comercializacin no-tcnico. Las rutinas de
limpieza de los datos, las cuales son programadas como comandos SQL, emple slo alrededor de tres
personas por semana para crearlas - una porcin mnima de un proyecto de 2 aos y medio.
Las herramientas para mejorar los datos, ms automatizadas y ms inteligentes, representan alrededor
de $ 120,000 del total del proyecto de $ 840,000.
2.2.4.2 Tipos de Limpieza de Datos
a) Limpieza de datos moderada
Si decide no programar funciones de limpieza de datos o contratar un consultor para hacer el trabajo,
puede inhibirse tambin de la compra de una herramienta especfica para esa tarea. El software de
gestin del data warehouse puede ser suficiente para limpiar y validar segn sus propsitos.
Muchos proyectos de data warehouse usan productos como Warehouse Manager de Prism Solutions o
Passport de Carleton, para una gama de tareas de gestin de data warehouse, que incluyen:
Extraccin de los datos desde las bases de datos operacionales
Preparacin de los datos para cargarlos en una base de datos del depsito,
Administracin de la metadata.
Estos productos cuestan desde $ 75,000 a ms de $ 200,000, dependiendo del tamao y la complejidad
del proyecto y pueden tambin limpiar, transformar y validar.
Ejemplo 5:
La Universidad Emory (Atlanta) hace la limpieza de toda la data para su depsito de 6 Gb con programas
en Cobol generados por Prism Warehouse Manager. Adems de tener problemas tpicos, tales como
formatos mltiples de fecha, la data con frecuencia contiene campos no inicializados que retienen

valores arbitrarios. Dos miembros del personal utilizan como 4 horas de un da de trabajo en las tareas
de limpieza de datos.
Emory ha considerado usar herramientas de limpieza de datos especializados, pero la escuela est
eliminando la data sucia hasta ahora, lo suficientemente bien, que no ve el valor adicional en otros
productos comerciales para justificar la compra.
Sin embargo, tienen una buena oportunidad de que las herramientas mencionadas anteriormente de
Prism y Carleton no limpien todo lo que se necesite. Ellos pueden encontrar anomalas comunes que
pueden manejarse mediante simples tablas de bsqueda de informacin (por ejemplo, reconocer que
Avenida y Av. representan la misma informacin), pero podran no salir exitosos con irregularidades ms
importantes e impredecibles, porque estas herramientas no estn diseadas para hacer tipos de limpieza
de gran intensidad.
Si los datos que requieren limpieza consisten predominantemente de nombres (incluyendo nombres de
compaa) y direcciones, las compaas tales como Harte-Hanks Communications e Innovative Systems
proveen no solamente herramientas de software, sino que actualizan peridicamente los archivos de
datos para ayudar a combinar las variantes de los nombres de las compaas, detectar cdigos postales
que no corresponden a las direcciones proporcionadas y encontrar anomalas similares.
Estas herramientas pueden ser apropiadas en otros campos (aparte de nombres y direcciones) que sean
conocidos para ser corregidos (por ejemplo, cantidades de dlar devaluados que han sido validados por
las cuentas) o contengan informacin independiente que no ser usada como una llave o ndice (por
ejemplo, las anotaciones de contacto de los vendedores).
Las soluciones orientadas al nombre y la direccin pueden costar en cualquier parte desde $ 30,000 a
ms de $ 200,000, dependiendo del tamao del data warehouse en cuestin. Adems se necesita, una
herramienta de extraer/ transformar/cargar (Extract, Transform, Load - ETL), tales como el Warehouse
Manager o Passport.
Lamentablemente, en el pas no existen empresas que se especialicen en estas actividades. Slo
corporaciones internacionales como las de Arthur Andersen han efectuado limpieza de datos en nuestro
medio en bancos privados y muy pocos organismos pblicos.
b) Limpieza de datos intensa
Para trabajos de limpieza intensos, se deben considerar herramientas que se han desarrollado para esas
tareas. Existen dos grandes competidores: Enterprise/Integrator de Apertus Technologies y la
herramienta Integrity Data Reengineering de Vality.
Enfoque Top-Down
La empresa Enterprise/Integrator toma un enfoque top-down, en la que usted propone las reglas para
limpiar los datos. Esta es una estrategia directa, donde usted impone sus conocimientos sobre su
negocio en los datos.
Por ejemplo:
Desea usted tratar una serie de concesiones de Martha's Fried Chicken como un cliente nico con
direcciones mltiples?

Para los propsitos del data warehouse, tiene sentido sustituir una direccin central nica para las
diferentes direcciones de las concesiones?
O, le gustara tratar las ubicaciones de las concesiones como clientes completamente diferentes?
Esta decisin determina cmo se agrega o consolida estos registros y si se trata las diferentes direcciones
de Martha's Fried Chicken como excepciones.
La empresa Enterprise/Integrator ofrece no solamente limpieza de datos, sino tambin extraccin,
transformacin, carga de datos, repeticin, sincronizacin y administracin de la metadata. Es bastante
caro (de $130,000 a $250,000), pero se puede ahorrar dinero si elimina la necesidad de otras
herramientas de gestin de data warehouse.
La desventaja principal del enfoque top-down de Enterprise/Integrator es que usted tiene que conocer,
o ser capaz de deducir las reglas del negocio y de la limpieza de datos.
Apertus provee ejemplos para trabajar con muchas estructuras comerciales y excepciones comunes.
An as, crear reglas es consumo de tiempo y est seguro de encontrar algunas excepciones no
esperadas. Estos pueden manejarse manualmente mediante un sistema de excepto - manipulacin,
pero es un proceso que consume tiempo.
Enfoque Bottom-Up:
La herramienta Integrity Data Reengineering de Vality tiene un enfoque bottom-up. Analiza los datos
caracter por caracter y automticamente emergen los modelos y las reglas del negocio. Integrity
proporciona un diseo de la data para ayudar a normalizar, condicionar y consolidar los datos. Este
enfoque tiende a dejar pocas excepciones para manejarse manualmente y el proceso tiende a consumir
menos tiempo.
Al igual que Enterprise/Integrator, Integrity puede tomar en cuenta las relaciones comerciales que no
son obvias a partir de los datos, tales como fusiones y adquisiciones que han tenido lugar desde que
fueron creados los datos. Pero con cualquier herramienta, estas reglas deben imponerse con un modelo
top-down.
Integrity incide exclusivamente sobre la limpieza de los datos, comenzando desde los archivos bsicos.
No extrae los datos desde bases de datos operacionales, carga los datos en la base de datos del
depsito, duplica y sincroniza los datos o administra la metadata.
Por ello, adems de costar $ 250,000, Integrity podra requerir tambin una herramienta como
Warehouse Manager o Passport. Sin embargo, pueden ser suficientes los utilitarios disponibles con la
base de datos para una simple extraccin/carga.
2.2.5 FACTORES DECISIVOS PARA DECIDIR EL DESARROLLO DE UN DATA WAREHOUSE
La data sucia es un serio peligro para el xito de un proyecto de data warehouse. Dependiendo del
alcance del problema, simplemente podra no ser posible dirigirlo rpidamente y abaratarlo.
Los principales factores son:
El tiempo que toma la programacin interna

El costo de las herramientas

Los gerentes de proyectos de Data Warehouse necesitan evaluar el problema con realismo, los recursos
internos disponibles para distribuirlos y seleccionar la solucin que se adapte a la planilla y presupuesto
del proyecto, o modificar la planilla y el presupuesto para solucionar el problema.
2.3 FASE: IMPLEMENTACION
En esta fase, el proyecto de data warehouse debe tener asignado el liderazgo adecuado, as como, los
recursos humanos, recursos tecnolgicos y el presupuesto apropiado.
Sin embargo, deben evaluarse otros aspectos, como desarrollar un proyecto en su totalidad o por fases
y adems, diferenciar el tipo de proyecto a realizar.
2.3.1 ELEMENTOS A CONSIDERAR EN LA IMPLEMENTACION
a) Proyecto Total o Proyecto en Fases
Es ms viable el desarrollo de un proyecto en fases que produzcan resultados a corto plazo que el
desarrollo de un proyecto que entregue resultados al trmino de varios aos. Por ello, el proyecto debe
estar centrado en un rea o un proceso.
b) Modelo lgico de datos
El modelo lgico de datos debe tener un alcance ms alto y cubrir todas las reas de inters, as como
los procesos ms estratgicos de cada una de ellas.
Ejemplo: Puede cubrir las reas de mercadeo, crdito y comercializacin y los procesos de
segmentacin, scoring para retencin, scoring para crdito y gestin de clientes, productos y canales de
ventas.
c) Proyecto Especializado o Proyecto Base
Decidir sobre qu tipo de proyecto, es algo complicado. Un proyecto especializado soporta
directamente un proceso especfico, por ejemplo: retencin de clientes.
Un proyecto base entrega capacidad genrica de anlisis a todos los usuarios que tengan acceso al data
warehouse, pero no tiene, entre sus funcionalidades, la solucin de un problema especfico o el soporte
especializado de un proceso especfico.
Un proyecto base es ms econmico y fcil de acabar que uno especializado, ms costoso y difcil de
terminar.
2.3.2 ESTRATEGIAS PARA EL PROCESO DE IMPLEMENTACION
Deben definirse las siguientes:
1 Identificar el problema en el cual el uso estratgico de la informacin detallada, permita conseguir
una solucin para generar una ventaja competitiva o un ahorro de costos.
Ejemplo: Un problema puede ser la ausencia de un modelo para estudios de retencin de clientes.
2 Definir el modelo lgico de datos a implementar para resolver el problema planteado.

Ejemplo: Se puede dar un modelo lgico cuando se presenta al usuario la informacin en trminos de
dimensiones (clientes, productos, canales de ventas, promociones, adquirientes, etc) bsicas del modelo
de datos y hechos que se registrarn para estas dimensiones (medidas de ventas, de costos, de
produccin, de facturacin, de cartera, de calidad, de servicio, etc.).
3 Reunir los datos para poblar ese modelo lgico de datos.
4 Tomar iniciativas de complementacin de informacin para asegurar la calidad de los datos
requeridos para poblar el modelo de datos.
Estas definiciones deben estar acompaadas de un servidor apropiado para el data warehouse, as como
elementos de comunicaciones, nodos cliente, el manejador de la base de datos del data warehouse y
otros hardware y software requeridos para la implementacin del proyecto.
2.3.3 ESTRATEGIAS EN LA IMPLEMENTACION
Deben plantearse las siguientes:
1 Definir el mejor diseo fsico para el modelo de datos. El diseo fsico debe estar orientado a generar
buen rendimiento en el procesamiento de consultas, a diferencia del modelo lgico que est orientado
al usuario y a la facilidad de consulta.
2 Definir los procesos de extraccin, filtro, transformacin de informacin y carga de datos que se
deben implementar para poblar ese modelo de datos.
3 Definir los procesos de administracin de la informacin que permanece en el data warehouse
4 Definir las formas de consultas a la informacin del data warehouse que se le proporcionar al
usuario. Para sto, debe considerarse la necesidad de resolver un problema y la potencia de consulta.
5 Completar el modelo de consulta base, relativo al rea seleccionada.
6 Implementar los procesos estratgicos del rea de trabajo, es decir, implementar herramientas
especializadas de scoring, herramientas especializadas para induccin de conocimiento (Data Mining),
etc.
7 Completar las reas de inters, en forma similar a lo descrito anteriormente.
2.4 FASE: EVALUACIN
2.4.1 EVALUACION DE RENDIMIENTO DE LA INVERSION
Cuando se evalan los costos, el usuario del data warehouse puede no tener el contenido de los costos
en mente, pero las preguntas mnimas que puede comenzar a hacerse son las siguientes:
Qu clases de costos excedieron el presupuesto en ms del 10% en cada uno de los 12 meses pasados?
Se aumentaron los presupuestos en ms de 5% para cualquier rea dentro de los ltimos 18 meses?
Cmo especificar las clases de gasto entre diferentes departamentos? Entre divisiones? A travs de
las regiones geogrficas?

Cmo tener mrgenes de operacin sobre los dos ltimos aos en cada rea de negocio? Donde han
disminuido los mrgenes, se han incrementado los costos?
Con frecuencia, los aspectos realmente importantes identificados por una gestin mayor, tienen un
valor agregado, en el que ellos saben si tuvieron la informacin que estaban buscando, lo que
significara una mejora de (por ejemplo) las ventas en 0.5% a 1% - que, si su operacin estuvo por los
billones de dlares en un ao, puede resultar en cientos de millones de dlares. En algunos casos, el
costo del depsito inicial se ha recobrado en un perodo de 6 a 8 meses.
Al hacerse preguntas de este tipo, los usuarios comienzan a identificar las reas en la que los costos han
aumentado o disminuido significativamente y pueden evaluar cada una de estas reas con ms detalle.
Caso prctico:
En un estudio encargado por 20 vendedores y consultores, se encontr un Retorno Promedio Total de la
inversin (Return On Investment-ROI) de 401%. Se encontr una compaa que genera cerca de 16,000%
en su estudio sobre 62 organizaciones. Tambin, se excluyeron los proyectos fracasados, as como los
ejecutados excepcionalmente (tantos buenos como malos).
Dicho estudio puede resumirse en el siguiente cuadro:
Cambios en el Valor
ROI promedio total
ROI promedio del proyecto ms grande
ROI promedio del modelo complementario de
datos
ROI mediano
Perodo de reembolso promedio
Costo promedio

401%
322%
533%
160%
2.3 Aos
2.2 Millones

2.4.1.1 COSTOS Y BENEFICIOS

Se han identificado diversos costos y beneficios en la elaboracin de un proyecto de construccin de un
data warehouse, tales como:
a) Costos
Costos preliminares
Planificacin
Diseo
Modelamiento/Ingeniera de Informacin
Costos iniciales
Plataforma de hardware
Software de base de datos

Herramientas de transferencia y limpieza de datos

Costos en procesamiento
Mantenimiento de datos
Desarrollo de aplicaciones
Capacitacin y soporte
b) Beneficios
Beneficios Tcticos
Impresin y emisin de reporte reducido
Demanda reducida para consultas de clientes
Entrega ms rpida de informacin a los usuarios
Beneficios Estratgicos (Potencialidad)
Aplicaciones y herramientas de acceso para los usuarios finales
Decisiones con mayor informacin
Toma de decisiones ms rpida
Capacidad de soporte a la informacin organizacional
2.4.2 BENEFICIOS A OBTENER
a) Para la Empresa
El data warehouse hace lo posible por aprovechar el valor potencial enorme de los recursos de
informacin de la empresa y volver ese valor potencial en valor verdadero.
b) Para los Usuarios
El data warehouse extiende el alcance de la informacin para que puedan acceder directamente en
lnea, lo que a la vez contribuye en su capacidad para operar con mayor efectividad las tareas rutinarias
o no.
Los usuarios del data warehouse pueden acceder a una riqueza de informacin multidimensional,
presentado coherentemente como una fuente nica confiable y disponible a ellos por medio de sus
estaciones de trabajo.
Los usuarios pueden usar sus herramientas familiares, hojas de clculo, procesadores de textos y
software de anlisis de datos y anlisis estadstico para manipular y evaluar la informacin obtenida
desde el data warehouse.
c) Para la Organizacin en Tecnologas de Informacin

El data warehouse enriquece las capacidades del usuario autosuficiente y hace lo factible para ofrecer
nuevos servicios a los usuarios, sin interferir con las aplicaciones cotidianas de produccin.
La pugna constante por resolver las necesidades de usuarios que piden acceso a los datos operacionales,
finaliza con la implementacin de un data warehouse. La mayora de los usuarios no necesita acceder
ms a los datos actuales, porque ellos tienen informacin ms til disponible desde el data warehouse.
Un data warehouse aumenta el valor de las inversiones en tecnologas de informacin, en aplicaciones y
bases de datos operacionales. Como estas bases de datos alimentan informacin, al evolucionar el data
warehouse, llegan a ser imprescindibles no solamente para las operaciones diarias, sino adems como la
fuente de informacin del negocio de amplio rango.
3. SOFTWARE EN UN DATA WAREHOUSE
La informacin estratgica sobre clientes importantes o un exitoso lanzamiento de producto, se
almacena en gigabytes de datos de marketing o ndice de transacciones de venta. Esa informacin debe
ser extrada de alguna forma para la toma de decisiones.
En este caso se necesita software especializado que permita capturar los datos relevantes en forma
rpida y pueda verse a travs de diferentes dimensiones de los datos. El software no debera limitarse
nicamente al acceso a los datos, si no tambin, al anlisis significativo de los datos. En efecto,
transformar los datos de la informacin cruda o no procesada, en informacin til para la empresa.
Los softwares o herramientas de negocios inteligentes se colocan sobre la plataforma data warehousing
y proveen este servicio. Debido a que son el punto principal de contacto entre la aplicacin del depsito
y la gente que lo usa, estas herramientas pueden constituir la diferencia entre el xito o fracaso de un
depsito.
Las herramientas de negocio inteligentes se han convertido en los sucesores de los sistemas de soporte
de decisin, pero tienen un alcance ms amplio. No solamente ayudan en las decisiones de soporte sino,
en muchos casos, estas herramientas soportan muchas funciones operacionales y de misin-crtica de la
compaa. Sin embargo, estos productos no son infalibles ya que slo se consigue el mximo provecho
del data warehouse, si elige las herramientas adecuadas a las necesidades de cada usuario final.
Los software usados en un data warehouse se clasifican en Herramientas de Consulta y Reporte,
Herramientas de Base de Datos Multidimensionales/ Olap (On Line Analytical Processing), Sistemas de
Informacin Ejecutivos, Herramientas Data Mining y los Sistemas de Gestin de Bases de Datos
propiamente.
En el Anexo N 1, se muestra una lista de los softwares existentes en la tecnologa Data warehousing.
3.1 HERRAMIENTAS DE CONSULTA Y REPORTE
Existe una gran cantidad de poderosas herramientas de consulta y reporte en el mercado (Ver Anexo 1A). Algunos proveedores ofrecen productos que permiten tener ms control sobre qu procesamiento
de consulta es hecho en el cliente y qu procesamiento en el servidor.
Las ms simples de estas herramientas son productos de reporte y consultas bsicas. Ellos proporcionan
desde pantallas grficas a generadores SQL (o ms preciso, generadores de acceso-llamada a base de
datos).

Ms que aprender SQL o escribir un programa para acceder a la informacin de una base de datos, las
herramientas de consulta al igual que la mayora de herramientas visuales, le permiten apuntar y dar un
click a los mens y botones para especificar los elementos de datos, condiciones, criterios de agrupacin
y otros atributos de una solicitud de informacin.
La herramienta de consulta genera entonces un llamado a una base de datos, extrae los datos
pertinentes, efecta clculos adicionales, manipula los datos si es necesario y presenta los resultados en
un formato claro.
Se puede almacenar las consultas y los pedidos de reporte para trabajos subsiguientes, como est o con
modificaciones. El procesamiento estadstico se limita comnmente a promedios, sumas, desviaciones
estndar y otras funciones de anlisis bsicas. Aunque las capacidades varan de un producto a otro, las
herramientas de consulta y reporte son ms apropiadas cuando se necesita responder a la pregunta
"Qu sucedi"? (Ejemplo: "Cmo comparar las ventas de los productos X,Y y Z del mes pasado con las
ventas del presente mes y las ventas del mismo mes del ao pasado?").
Para hacer consultas ms accesibles a usuarios no-tcnicos, los productos tales como Crystal Reports de
Seagate, Impromptu de Cognos, Reportsmith de Borland, Intelligent Query de IQ Software, Esperant de
Software AG y GQL de Andyne, ofrecen interfases grficas para seleccionar, arrastrar y pegar.
Lo ms avanzado de estos productos lo orientar hasta las consultas que tienen sintaxis mala o que
devuelven resultados imprevistos. El acceso a los datos han mejorado tambin con las nuevas versiones
de estos productos y los vendedores ya instalan drivers estndares tales como ODBC y 32-bit nativo,
hasta fuentes de datos comerciales.
En general, los administradores de data warehouses que usen estos tipos de productos, deben estar
dispuestos a ocupar su tiempo para resolver las tareas de estructuracin, como administrar bibliotecas y
directorios, instalar software de conectividad, establecer nombres similares en Ingls y precalcular
"campos de datos virtuales".
Una vez que se han creado las pantallas SQL, puede necesitar desarrollar un conjunto de consultas y
reportes estndares, aunque algunos productos ofrecen libreras de plantillas prediseadas y reportes
predefinidos que se pueden modificar rpidamente.
3.2 HERRAMIENTAS DE BASE DE DATOS MULTIDIMENSIONALES / OLAP
Los generadores de reporte tienen sus limitaciones cuando los usuarios finales necesitan ms que una
sola, una vista esttica de los datos, que no sean sujeto de otras manipulaciones. Para estos usuarios, las
herramientas del procesamiento analtico en lnea (OLAP - On Line Analytical Processing), proveen
capacidades "Slide y Dice" que contestara "qu sucedi?" al analizar por qu los resultados estn
como estn.
Las primeras soluciones OLAP estuvieron basadas en bases de datos multidimensionales (MDDBS). Un
cubo estructural (dos veces un hipercubo o un arreglo multidimensional) almacenaba los datos para que
se puedan manipular intuitivamente y claramente ver las asociaciones a travs de dimensiones
mltiples. Los productos pioneros tal como Essbase de Arbor Software soportan directamente las
diferentes vistas y las manipulaciones dimensionales requeridas por OLAP.
Limitaciones del enfoque de bases de datos multidimensionales:
1ra.: Las nuevas estructuras de almacenamiento de datos requieren bases de datos propietarias. No hay
realmente estndares disponibles para acceder a los datos multidimensionales.

Los proveedores como Arbor, vieron sto como una oportunidad para crear de facto normas para editar
MDDB APIs, propiciando herramientas terceristas y estableciendo asociaciones estratgicas.
Muchas de estas herramientas de consulta y de soluciones data-mining soportan directamente Essbase,
Oracle Express y otros formatos MDDB comunes. El Commander OLAP, herramienta cliente/servidor de
Comshare, se sita sobre la parte superior de un data warehouse multidimensional Essbase y soporta el
acceso dinmico y la manipulacin de los datos.
2da.: La segunda limitacin de un MDDB concierne al desarrollo de una estructura de datos. Las
compaas generalmente almacenan los datos de la empresa en bases de datos relacionales, lo que
significa que alguien tiene que extraer, transformar y cargar estos datos en el hipercubo.
Este proceso puede ser complejo y consumidor de tiempo pero, nuevamente, los proveedores estn
investigando la forma de solucionarlos. Las herramientas de extraccin de datos y otras automatizan el
proceso, trazando campos relacionales en la estructura multidimensional y desarrollando el MDDB
sobre la marcha.
Algunos proveedores ofrecen ahora la tcnica OLAP relacional (Relational On Line Analytical Processing ROLAP), que explora y opera en el data warehouse directamente usando llamadas SQL estndares. Las
herramientas de pantallas permiten retener los pedidos multidimensionales, pero el motor ROLAP
transforma las consultas en rutinas SQL. Entonces se recibe los resultados tabulados como una hoja de
clculos multidimensional o en alguna otra forma que soporte rotacin, drilling down y reduccin.
As como la extraccin de los datos, el desarrollo y evolucin de la estructura MDDB puede cambiarse.
Los administradores ROLAP deben afrontar algunas veces las tareas (agobiantes) de desarrollar las
rutinas SQL para agregar e indexar los datos ROLAP, as como, asegurar la traduccin correcta de los
pedidos multidimensionales en la ventana de comandos SQL.
Los defensores de ROLAP argumentan que se usan estndares abiertos (SQL) y que se esquematiza
(nivel de detalle) los datos para hacerlos ms fcilmente accesibles. Por otra parte, argumentan que una
estructura multidimensional nativa logra mejor performance y flexibilidad, una vez que se desarrolla el
almacn de los datos.
Lo bueno es que estas tecnologas evolucionan rpidamente y/o pueden proveer una pronta solucin
OLAP. Algunos productos ejemplos son PowerPlay de Cognos, Business Objects con el software del
mismo nombre, Brio Query de Brio Technology y una serie de DSS Agent/DSS Server de MicroStrategy.
Los retos administrativos y de desarrollo de OLAP, a diferencia de las encontradas con las herramientas
de consulta y reporte, son generalmente ms complejos. Definiendo el OLAP y el software de acceso a
los datos, se requiere un claro entendimiento de los modelos de datos de la corporacin y las funciones
analticas requeridas por ejecutivos, gerentes y otros analistas de datos.
El desarrollo de productos comerciales pueden aminorar los problemas, pero OLAP es raramente una
solucin clave. La arquitectura debe permitir el soporte a su fuente de datos y requerimientos. Pero una
vez que se ha establecido un sistema OLAP, el soporte al usuario final ser mnimo.
Los usuarios de estos productos deben decidir sobre si los datos del procesamiento analtico en lnea,
deberan almacenarse en bases de datos multidimensionales especialmente diseadas o en bases de
datos relacionales. Esto depende de las necesidades de la organizacin. En el Anexo 1-B, se indica si un
producto almacena datos en bases de datos relacionales o en una base de datos multidimensional
(MDDB).

3.3 SISTEMAS DE INFORMACION EJECUTIVOS

Las herramientas de sistemas de informacin ejecutivos (Executive Information Systems - EIS),
proporcionan medios sumamente fciles de usar para consulta y anlisis de la informacin confiable.
Generalmente se disean para el usuario que necesita conseguir los datos rpidamente, pero quiere
utilizar el menor tiempo posible para comprender el uso de la herramienta.
Tambin, permiten a los desarrolladores de sistemas colocar el contexto del negocio alrededor de
informacin diversa. Un uso tpico de un EIS es facilitar al usuario la recuperacin y anlisis de la
mtricas, de performance de la organizacin.
El precio de esta facilidad de uso es que por lo general existen algunas limitaciones sobre las
capacidades analticas disponibles con el sistema de informacin ejecutivo. Adems, muchas de las
herramientas de consulta/reporte y OLAP/multidimensional, pueden usarse para desarrollar sistemas de
informacin ejecutivos.
El concepto de sistema de informacin ejecutivo es simple: los ejecutivos no tienen mucho tiempo, ni la
habilidad en muchos casos, para efectuar el anlisis de grandes volmenes de datos. El EIS presenta
vistas de los datos simplificados, altamente consolidados y mayormente estticas.
Categoras de Ambientes EIS:
1. El libro electrnico es una versin en lnea, electrnica, contraparte del papel que muchos ejecutivos
usan en reuniones con el personal. Las diapositivas electrnicas presentan una visin concreta de una
iniciativa organizacional o quizs los datos para dar a conocer la situacin actual de un proyecto
importante.
2. El centro de comando es bsicamente una coleccin de puertos en un amplio conjunto de reportes, el
newsgroup recupera desde Internet y otros materiales que proveen conocimientos en la organizacin.
Los reportes del centro de comando pueden ser accesados diariamente o con ms frecuencia, si la
informacin cambia constantemente o slo cuando se garantiza las excepciones. Algunos productos
generan alarmas cuando ocurren las excepciones especificadas.
Cuando sea apropiado, cada diapositiva del libro electrnico o pantalla del centro de comando, debera
permitir al ejecutivo recibir informacin adicional si lo desea (y si est disponible). A diferencia del
modelo OLAP, donde el incremento de niveles de informacin se dan a conocer tal como el analista
manipula los datos, un ejecutivo espera una descripcin global. No deberan escudriar para obtener
respuestas.
Por ello, cuando los ejecutivos piden ms informacin desde las diapositivas del libro electrnico o de
las pantallas del centro de comandos, la presentacin debera ser cuidadosamente elaborada para
presentar principalmente informacin adicional amplificada. El ejecutivo debe ser capaz de pasar cada
punto para "ms informacin", sin perder alguna informacin crtica.
Los ejecutivos pueden administrar su propio libro electrnico y centro de comandos o los
administradores pueden mantener y modificar el EIS de acuerdo a las especificaciones del ejecutivo. Los
sistemas de informacin ejecutivos, generalmente tienen una programacin que variar en complejidad
de un producto a otro. Los pioneros en el mercado de EIS incluyen Comshare, creadores del Commander
EIS y Pilot Software, desarrolladores del Pilot Command Center.

En el Anexo 1-C, se incluye una relacin de productos y empresas que brindan herramientas de Sistemas
de Informacin Ejecutivos.
3.4 HERRAMIENTAS DATA MINING
Data mining es una categora de herramientas de anlisis open-end. En lugar de hacer preguntas, se
toma estas herramientas y se pregunta algo "interesante", una tendencia o una agrupacin peculiar, por
ejemplo. El proceso de data mining extrae los conocimientos guardados o informacin predictiva desde
el data warehouse sin requerir pedidos o preguntas especficas.
Las herramientas Mining usan algunas de las tcnicas de computacin ms avanzadas como:
-

redes neurales

deteccin de desviacin

modelamiento predictivo y

programacin gentica

para generar modelos y asociaciones. Mining es un dato-conducido, no una aplicacin-conducida.

El Intelligent Miner de IBM para AIX soporta sofisticadas tcnicas mining, as como las funciones de
preparacin de los datos para extraer informacin desde bases de datos Oracle o Sybase y cargarlos en
DB2 para mining. Con su opcin Data Mine para el motor Red Brick Warehouse 5.0, Red Brick integra la
funcionalidad de un data mining y la arquitectura de almacenamiento.
Otros ejemplos de herramientas data mining comerciales incluyen Darwin de Thinking Machines,
herramientas de visualizacin de datos en MDDB de SAS Institute, SGI MineSet y Focus 6 Serie de
Visualizacin y Anlisis de Information Builders.

3.5 SISTEMAS DE GESTION DE BASES DE DATOS

Estos software proporcionan procesamiento en paralelo y/o algo fuera de los aspectos ordinarios, que
puedan ser especialmente interesantes para la gente de desarrollo de data warehouse y de sistemas de
soporte de decisiones.
Se incluye el Anexo 1-D con una relacin de Bases de Datos usados para Data Warehouse.

3.6 ELECCION DE HERRAMIENTAS

Hay algunas reglas obvias a seguir cuando se eligen herramientas de anlisis. Las herramientas se
combinan segn las necesidades de los usuarios finales, capacidad tcnica empresarial y la fuente de
datos existente.
1 Si se elige un proveedor de depsito que adems ofrece herramientas integradas, probablemente se
ahorrar un tiempo de desarrollo significativo al elegir un conjunto de herramientas compatibles.

De otro modo, seleccione un conjunto de herramientas que soporte su fuente de datos original. Sin ese
soporte, se debera optar por una solucin OLAP relacional debido a que provee una arquitectura
abierta.
2 Despus que se ha seleccionado un conjunto de herramientas compatible con su fuente de datos,
determine cunto anlisis necesita realmente.
Si usted simplemente necesita saber "cunto" o "cuntos", ser suficiente una herramienta bsica de
consultas y reportes.
Si usted requiere un anlisis ms avanzado que explique la causa y los efectos de las ocurrencias y las
tendencias, busque una solucin OLAP.
Las herramientas data mining sofisticadas requieren expertos en tcnicas de anlisis de datos y se
necesitan para pronsticos avanzados, clasificacin y creacin del modelo.
3 Como con cualquier tecnologa, para el mejor desempeo de su compaa, se puede optar por una
solucin nica o un conjunto de soluciones. Su personal debe comprender los requerimientos de
tecnologa, desarrollar soluciones que renan esos requerimientos y mantener y mejorar efectivamente
los sistemas.
Los softwares de negocio inteligentes son slo herramientas. Todava se necesita gerentes y ejecutivos
que capten los conocimientos derivados y tomen decisiones intuitivamente. En otras palabras, estos
softwares requieren todava inteligencia comercial propia.
En la siguiente tabla se definen los parmetros a tener en cuenta para la eleccin de las herramientas
adecuadas.
Elija la Herramienta adecuada
Tipo de Herramienta Pregunta bsica
Consulta y Reporte

Procesamiento
analtico
en lnea (OLAP)
Sistema de
Informacin
Ejecutiva (SIE)

Qu sucedi?

Qu sucedi y
por qu?
Qu necesito
conocer ahora?

Modelo de Salida
Reportes de ventas
mensuales;

Usuario tpico
Necesita data histrica
puede tener aptitud
tcnica limitada

histrico de inventario
Ventas mensuales vs. Necesita ir de una visin
Cambios
esttica de los datos a
"slicing and dicing"
de precio de los
competidores
tcnicamente astuto
Necesita informacin
Libros electrnicos;
resumida o de alto nivel
puede no ser
Centros de comandos
tcnicamente astuto
Necesita extraer la
relacin y

Qu es interesante?
Data mining

Modelos predictivos
Qu podra pasar?

tendencias de la data
ininteligible
tcnicamente astuto.