Capitulo4 2

MANUAL PARA LA CONSTRUCCIN DE UN
DATA WAREHOUSE
Conceptos y Estrategias de Desarrollo
Publicado por el Instituto Nacional de Estadsticas e Informtica INEI/1997 (Lima)
Revisado y Editado por Prof. J. Elliott
Contenido
Presentacin
Prefacio
1. ASPECTOS TEORICOS
1.1 Introduccin al Concepto Data Warehousing
1.2 Sistemas de Informacin
1.2.1 Sistemas Tcnico-operacionales
1.2.2 Sistemas de Soporte de Decisiones
1.3 Caractersticas de un Data Warehouse
1.3.1 Orientacin a Temas
1.3.2 Integracin
1.3.3 De Tiempo Variante
1.3.4 No Variante
1.4 Estructura de un Data Warehouse
1.5 Arquitectura de un Data Warehouse
1.5.1 Elementos constituyentes de una Arquiteectura Data Warehouse
1.5.2 Operaciones en un Data Warehouse
1.6 Tranformacin de Datos y Metadata
1.6.1 Transformacin de Datos
1.6.2 Metadata
1.7 Flujo de Datos
1.8 Medios de Almacenamiento para la Informacin Antigua
1.9 Usos de Data Warehouse
1.10 Consideraciones Adicionales
1.11 Ejemplo de un Data Warehouse
1.12 Anomalas en un Data Warehouse
2. PROYECTO DE ELABORACION DE UN DATA WAREHOUSE
2.1 Fase: Organizacin
2.1.1 Factores en la Planificacin de un Data Warehouse
2.1.2 Estrategias para el Desarrollo de un Data Warehouse
2.1.3 Estrategias para el Diseo de un Data Warehouse
2.1.4 Estrategias para la Gestin de un Data Warehouse
MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE
Pag. 1 de 93
2.2. Fase: Desarrollo

2.2.1 Porqu construir bloque de Data Warehouse?
2.2.2 Consideraciones previas al Desarrollo de un Data Warehouse
2.2.2.1 Alcance del Data Warehouse
2.2.2.2 Redundancia de Datos
2.2.2.3 Tipo de Usuario final
2.2.3 Elementos claves para el desarrollo de un Data Warehouse
2.2.3.1 Diseo de la Arquitectura
2.2.3.2 Sistemas de Gestin de Bases de Datos
2.2.3.3 Nuevas Dimensiones
2.2.3.4 Combinaciones de la Arquitectura con el Sistema de Gestin de
Bases de Datos
2.2.3.5 Planes de Expansin
2.2.4 Confiabilidad de los Datos
2.2.4.1 Limpieza de los Datos
2.2.4.2 Tipos de Limpieza de Datos
2.2.5 Factores decisivos para deducir el desarrollo de un Data Warehouse
2.3 Fase: Implementacin
2.3.1 Elementos a considerar en la implementacin
2.3.2 Estrategias para el proceso de Implementacin
2.3.3 Estrategias en la Implementacin
2.4 Fase: Evaluacin
2.4.1 Evaluacin de Rendimiento de la Inversin
2.4.1.1 Costos y Beneficios
2.4.2 Beneficios a obtener
3. SOFTWARE EN UN DATA WAREHOUSE
3.1 Herramientas de Consulta y Reporte
3.2 Herramientas de Base de Datos Multidimensionales/OLAP
3.3 Sistemas de Informacin Ejecutivos
3.4 Herramientas Data Mining
3.5 Sistemas de Gestin de Bases de Datos
3.6 Eleccin de Herramientas
ANEXOS
N 1 Software en una Data EWarehouse
1-A Herramientas de Consulta y Reporte
1-B Herramientas de Base de Datos
1-C Sistemas de Informacin Ejecutivos
1-D Bases de Datos usados para Data Warehouse
N 2 Glosario de Terminos
Glosario
Pag. 2 de 93
PRESENTACION
El Instituto Nacional de Estadstica e Informtica (INEI), ente rector de los Sistemas Nacionales de Estadstica
e Informtica, se complace en presentar el "Manual para la Construccin de un Data Warehouse".
Esta tecnologa permite que la organizacin disponga, en forma integrada y estandarizada, de la informacin
correspondiente a la operacin de la empresa, as como, proporciona a los usuarios, que tienen a su cargo la
toma de decisiones, las herramientas adecuadas, para que a travs de consultas rpidas, ellos mismos
accedan la informacin requerida.
El documento consta de tres captulos. En el primero, "Aspectos Tericos", se dan los conceptos y el
fundamento de la tecnologa data warehousing. En el segundo, "Proyecto de Elaboracin de un Data
Warehouse", se definen las estrategias para su planificacin, desarrollo, diseo y gestin, adems de los
puntos que deben considerarse en la evaluacin de la inversin.
El tercer captulo, "Software en un Data Warehouse", permite comparar las herramientas de anlisis
adecuadas para los usuarios del data warehouse. Asimismo, en los Anexos, se proporciona una relacin de
los diversos Softwares que se usan en el manejo de un Data Warehouse, seguido de un Glosario de Trminos
utilizados en la publicacin.
El INEI, en su propsito de contribuir con la modernizacin de la gestin de los Servicios Informticos, pone a
disposicin de las Instituciones Pblicas, Privadas, estudiantes y pblico en general, este documento,
agradeciendo a las personas que han contribuido a la realizacin de la presente publicacin.
Lima, Setiembre de 1997
Econ. Flix Murillo Alfaro

Jefe
INSTITUTO NACIONAL DE ESTADISTICA
E INFORMATICA
Pag. 3 de 93
PREFACIO
Desde que se inici la era de la computadora, las organizaciones han usado los datos desde sus sistemas
operacionales para atender sus necesidades de informacin. Algunas proporcionan acceso directo a la
informacin contenida dentro de las aplicaciones operacionales. Otras, han extrado los datos desde sus bases
de datos operacionales para combinarlos de varias formas no estructuradas, en su intento por atender a los
usuarios en sus necesidades de informacin.
Ambos mtodos han evolucionado a travs del tiempo y ahora las organizaciones manejan una data no limpia e
inconsistente, sobre las cuales, en la mayora de las veces, se toman decisiones importantes.
La gestin administrativa reconoce que una manera de elevar su eficiencia est en hacer el mejor uso de los
recursos de informacin que ya existen dentro de la organizacin. Sin embargo, a pesar de que sto se viene
intentando desde hace muchos aos, no se tiene todava un uso efectivo de los mismos.
La razn principal es la manera en que han evolucionado las computadoras, basadas en las tecnologas de
informacin y sistemas. La mayora de las organizaciones hacen lo posible por conseguir buena informacin,
pero el logro de ese objetivo depende fundamentalmente de su arquitectura actual, tanto de hardware como de
software
El data warehouse, es actualmente, el centro de atencin de las grandes instituciones, porque provee un
ambiente para que las organizaciones hagan un mejor uso de la informacin que est siendo administrada por
diversas aplicaciones operacionales.
Un data warehouse es una coleccin de datos en la cual se encuentra integrada la informacin de la Institucin y
que se usa como soporte para el proceso de toma de decisiones gerenciales. Aunque diversas organizaciones y
personas individuales logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que
existen muchas dificultades potenciales.
Reunir los elementos de datos apropiados desde diversas fuentes de aplicacin en un ambiente integral
centralizado, simplifica el problema de acceso a la informacin y en consecuencia, acelera el proceso de
anlisis, consultas y el menor tiempo de uso de la informacin.
Las aplicaciones para soporte de decisiones basadas en un data warehousing, pueden hacer ms prctica y
fcil la explotacin de datos para una mayor eficacia del negocio, que no se logra cuando se usan slo los datos
que provienen de las aplicaciones operacionales (que ayudan en la operacin de la empresa en sus operaciones
cotidianas), en los que la informacin se obtiene realizando procesos independientes y muchas veces
complejos.
Un data warehouse se crea al extraer datos desde una o ms bases de datos de aplicaciones operacionales. La
data extrada es transformada para eliminar inconsistencias y resumir si es necesario y luego, cargadas en el
data warehouse. El proceso de transformar, crear el detalle de tiempo variante, resumir y combinar los extractos
de datos, ayudan a crear el ambiente para el acceso a la informacin Institucional. Este nuevo enfoque ayuda a
las personas individuales, en todos los niveles de la empresa, a efectuar su toma de decisiones con ms
responsabilidad.
La innovacin de la Tecnologa de Informacin dentro de un ambiente data warehousing, puede permitir a
cualquier organizacin hacer un uso ms ptimo de los datos, como un ingrediente clave para un proceso de
toma de decisiones ms efectivo. Las organizaciones tienen que aprovechar sus recursos de informacin para
crear la informacin de la operacin del negocio, pero deben considerarse las estrategias tecnolgicas
necesarias para la implementacin de una arquitectura completa de data warehouse.
Pag. 4 de 93
1. ASPECTOS TERICOS
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
Data Warehouse
Datos Operacionales
Datos del negocio para Informacin
Orientado a la aplicacin
Orientado al sujeto
Actual
Actual + histrico
Detallada
Detallada + ms resumida
Cambia continuamente
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.
Pag. 5 de 93
1.2 SISTEMAS DE INFORMACION

En las metodologas anteriores, publicadas por el Instituto Nacional de Estadstica e
Informtica - INEI y con el fin de proporcionar una visin ms clara, 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).
o
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).
o
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
Pag. 6 de 93
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
tcnico-operacionales 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.
Pag. 7 de 93
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:
o
o
o
o
Orientado al tema
Integrado
De tiempo variante
No voltil
Pag. 8 de 93
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,
Pag. 9 de 93
una aplicacin de ingreso de rdenes puede accesar 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.
Pag. 10 de 93
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.
o
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.
o
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.
Pag. 11 de 93
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.
Pag. 12 de 93
Cualquiera que sea la fuente, cuando la informacin de la tubera llegue al data warehouse
necesitar ser medida de la misma manera.
o
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.
Pag. 13 de 93
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 accesar. 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).
El 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.
Pag. 14 de 93
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.
Pag. 15 de 93
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
Pag. 16 de 93
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:
o
o
o
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%.
Pag. 17 de 93
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:
o
o
o
o
o
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.
Pag. 18 de 93
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.)
Pag. 19 de 93
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:
o
o
o
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.
Pag. 20 de 93
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.
Pag. 21 de 93
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):
o
o
o
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.
Pag. 22 de 93
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
Pag. 23 de 93
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:
o
o
o
o
o
o
o
o
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 accesar a los datos para
otra gestin o propsitos informticos.
Esta dificultad en accesar 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.
o
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
Pag. 24 de 93
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 las
PCs monousuarias y las 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.
o
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 accesar 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, accesar 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 accesar 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 interfase 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.
o
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.
Pag. 25 de 93
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 accesar 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.
o
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.
o
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.
o
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
accesar y es altamente flexible. Cada vez ms, los data warehouses son almacenados sobre
plataformas cliente/servidor, pero por lo general se almacenan sobre mainframes.
o
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
accesar 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.
Pag. 26 de 93
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
Pag. 27 de 93
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 accesar 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.
1. Evolucin del Depsito
Pag. 28 de 93
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.
Pag. 29 de 93
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.
Pag. 30 de 93
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 interfase 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:
o
o
o
o
o
o
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.
Pag. 31 de 93
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:
o
o
o
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.
Pag. 32 de 93
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.
Pag. 33 de 93
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
Base de Datos Operacionales
Muchos usuarios concurrentes
Uso de
Data Warehouse
Pocos usuarios concurrentes
Consultas complejas, frecuentemente
Consultas predefinidas y actualizables

no anticipadas.
Cantidades pequeas de datos
detallados
Cantidades grandes de datos detallados
Requerimientos de respuesta inmediata Requerimientos de respuesta no crticos

Maneras diferentes de uso de datos
Los usuarios de un data warehouse necesitan accesar a los datos complejos,
frecuentemente desde fuentes mltiples y de formas no predecibles.
Los usuarios que accesan 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 accesan 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 accesar 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 accesar
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.
o
Slo pocos usuarios accesan a los datos concurrentemente
En contraste a la produccin de sistemas que pueden manejar cientos o miles de usuarios

concurrentes, al data warehouse accesa un limitado conjunto de usuarios en cualquier
tiempo determinado.
o
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 accesar 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.
Pag. 34 de 93
Las consultas de los usuarios accesan 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 accesar 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).
o
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.
Pag. 35 de 93
El diseador de datos tiene dos predisposiciones:

o
o
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.
Pag. 36 de 93
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.
Pag. 37 de 93
Al crear un data warehouse y combinar todos los datos requeridos, se obtienen los
siguientes beneficios:
o
o
o
o
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.
Pag. 38 de 93
1.10 CONSIDERACIONES ADICIONALES

Hay algunas consideraciones adicionales que deben tenerse en cuenta al
construir y administrar el data warehouse.
o
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.
o
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.
Pag. 39 de 93
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.
Pag. 40 de 93
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).
Pag. 41 de 93
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.
o
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.
o
o
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:
o
o
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.
Pag. 42 de 93
2.- PROYECTO DE ELABORACION 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.
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
Pag. 43 de 93
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 :
1. Instalacin de un conjunto de facilidades para acceso a datos, directorio de datos y

gestin de proceso.
2. Entrenamiento de usuarios finales.

3. Control de cmo se usan realmente las instalaciones del data warehouse.
4. 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.
Pag. 44 de 93
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
Pag. 45 de 93
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 misincrtica.
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:
o
o
o
Demandas para mejorar datos

Demandas para una data consistente
Demandas para diferentes tipos de datos, etc.
Pag. 46 de 93
2.2.
FASE DE 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:
Pag. 47 de 93
o
o
o
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:
Pag. 48 de 93
o
o
o
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.
4.
Data Warehouses "Virtual" o "Point to Point"

Una estrategia de data warehouses virtual, significa que los usuarios finales pueden accesar
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.
Pag. 49 de 93
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:
o
o
o
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

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:
o
o
o
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.
Pag. 50 de 93
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).
Pag. 51 de 93
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.
Pag. 52 de 93
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.
Pag. 53 de 93
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.
Pag. 54 de 93
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.
Pag. 55 de 93
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.
Pag. 56 de 93
Cmo comparar DBMSes?

Caractersticas/Funcin
Relacional
SuperRelacional
Multidimensional
(Lgico)
Multidimensional
(Fsico)
ObjetoRelacional
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
Elija
Requerimientos
comerciales
Usuarios
Soporte de
Sistemas
Arquitectura
Servidor
Alcance: departamental
Pequea -
Local mnimo -
Consolidado -
Procesador nico MDDB
Usos: anlisis de datos
ubicacin nica
central promedio
paquete
o SMP
Grande-analistas
en
Local mnimo -
Seccionado -
Grupos de SMP
RDBMS para
Usos: anlisis ms
una sola ubicacin; central promedio
detalle en
central-
para central;
central - MDDB
informtica
usuarios
informticos
resumen en
local
SP o SMP para
local
para local
Centralizado
Grupos de SMP
Objetorelacional-
DBMS
dispersos
Alcance: empresa
Grande;
geogrfica-
Usos: anlisis ms
mente disperso
Central fuerte
soporte Web
informtica
Pequea - pocas
Usos: investigacin
ubicaciones
Central fuerte
Centralizado
MPP
RDBMS con
soporte
paralelo
Pag. 57 de 93
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).
Pag. 58 de 93
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.
Pag. 59 de 93
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.
Pag. 60 de 93
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.
Pag. 61 de 93
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 in-house, 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,
Pag. 62 de 93
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
Pag. 63 de 93
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:
o
o
o
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.
Pag. 64 de 93
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.
o
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.
o
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.
Pag. 65 de 93
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

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:
o
o
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.
Pag. 66 de 93
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.
Pag. 67 de 93
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
Pag. 68 de 93
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 EVALUACION

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:
1. Qu clases de costos excedieron el presupuesto en ms del 10% en cada uno de

los 12 meses pasados?
2. Se aumentaron los presupuestos en ms de 5% para cualquier rea dentro de los

ltimos 18 meses?
3. Cmo especificar las clases de gasto entre diferentes departamentos? Entre

divisiones? A travs de las regiones geogrficas?
4. 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
Pag. 69 de 93
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
401%
ROI promedio del proyecto ms grande
322%
ROI promedio del modelo complementario de

datos
533%
ROI mediano
160%
Perodo de reembolso promedio

Costo promedio
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
o
o
o
o
o
o
o
o
o
o
o
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
o
o
o
o
o
o
o
o
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
Pag. 70 de 93
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 accesar
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 accesar 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 accesar 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.
Pag. 71 de 93
3. SOFTWARE EN UN DATA WAREHOUSE

3.1 HERRAMIENTAS DE CONSULTA Y REPORTE
Existe una gran cantidad de poderosas herramientas de consulta y reporte en el mercado
(Ver Anexo 1-A). 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 accesar 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.
Pag. 72 de 93
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 accesar 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.
Pag. 73 de 93
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,
Pag. 74 de 93
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.
Pag. 75 de 93
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:
o
o
o
o
redes neurales
deteccin de desviacin
modelamiento predictivo y
programacin gentica
para generar modelos y asociaciones. Mining es un dato-conducido, no una aplicacinconducida.

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.
Pag. 76 de 93
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.
o
o
o
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
Modelo de Salida
Reportes de ventas mensuales;
Consulta y Reporte
Qu sucedi?
Usuario tpico
Necesita data histrica puede
tener aptitud tcnica limitada
histrico de inventario
Procesamiento analtico
Qu sucedi y
Ventas mensuales vs. Cambios
en lnea (OLAP)
por qu?
de precio de los competidores
Sistema de Informacin
Qu necesito
Libros electrnicos;
Ejecutiva (SIE)
conocer ahora?
Centros de comandos
Necesita ir de una visin esttica

de los datos a "slicing and dicing"
tcnicamente astuto
Necesita informacin resumida o
de alto nivel puede no ser
tcnicamente astuto
Necesita extraer la relacin y
Qu es interesante?
Data mining
Modelos predictivos
tendencias de la data ininteligible
Qu podra pasar?
tcnicamente astuto.
Pag. 77 de 93
ANEXOS
ANEXO 1.- SOFTWARE EN UNA DATA WAREHOUSE
Anexo 1-A
HERRAMIENTAS DE CONSULTA Y REPORTE
PRODUCTO
EMPRESA DISTRIBUIDORA
Access
Microsoft
Access+
Sonetics
Actuate Reporting System
Actuate Software Corporation
AMIS Information Server
Hoskyns Group plc
Application System
IBM
Approach
Lotus Corporation
ARPEGGIO
Wall Data Inc.
APTuser
International Software Group
AS/Access for Microsoft Access
Martin Spencer & Associates
ASK Joe
Information Management Services
aXcess/400
Glenbrook Software
BrioQuery
Brio Technology
Business Objects
Business Objects, Inc.
Clear: Access
Sterling Software
Crystal Reports, Crystal Info
Seagate Software
d.b. Express
Computer Concepts Corp.
Databoard, Dataread
SLP Infoware
DataDirect Explorer
Intersolv
DataSite
NetScheme Solutions, Inc.
DB Publisher
Xense Technology Inc.
DbPower
Db-Tech Inc.
Decision Analyzer
Decisin Technology
DECquery, DECdecision
Touch Technologies, Inc.
Discoverer, Discoverer/2000
Oracle Corporation
DS Server, DS Modeler
Interweave
EasyReporter
Speedware Corporation
Eclipse Query/Report
Cornut Informatique
Pag. 78 de 93
ELF
ELF Software
English Wizard
English Wizard
EnQuiry
Progress Software
Esperant
Speedware
FOCUS Six
Information Builders, Inc.
4S-Report
Four Seasons Software, Inc
Freequery
Dimension Software Systems
Front & Center for Reporting, Nomad
Thomson Software Products
GQL
Andyne
HarborLight
Harbor Software
HP Information Access
Hewlett-Packard
if
Leep Technology, Inc.
Impress, SqlBuddy
Objective Technologies, Inc.
Impromptu
Cognos Corporation
InfoAssistant
Asymetrix
PRODUCTO
InfoMaker
Powersoft Corporation
InfoQuery
Platinum Technology, Inc.
InfoReports
Platinum Technology, Inc.
InformEnt Warehouse Desktop
Fiserv
Internet DataSpot
DTL Data Technologies Ltd.
inSight
Williams & Partner
Interactive Query
New Generation software
IQ/Objects, IQ/SmartServer
IQ Software Corporation
Iridon Panorama
The Great Elk Company Limited
Kinetix
Hilco Technologies
LANSA/Client
LANSA USA
MARKIS/400
AS Software
Nirvana
Synergy Technologies
OR-REPORTER II
Output Reporting, Inc.
Oracle Reports, Browser
Oracle Corporation
Paradox
Borland
Platinum Report Facility
Platinum Technology, Inc
ProBit
System Builder
Productivity Series Reports
michaels, ross & cole
QBE Vision
Sysdeco
QMF
IBM
QueryObject
Cross/Z International, Inc.
Quest
Centura Software Corporation
R&R Report Writer
Concentric Data Systems
Pag. 79 de 93
Report Writer
Raima
Reportoire
Synergistic Systems, Inc.
Reports
Nine to Five software Co.
ReporTool
Zen Software
ReportSmith
Borland
Rocket Shuttle
Rocket Software, Inc.
Safari ReportWriter
Interactive Software Systems
Sagent Data Mart Solution
Sagent Technology, Inc.
SAS System
SAS Institute
Second Wind
Anju Technologies
Select!
Attachmate
SEQUEL
Advanced Systems Concepts
Snow Report Writer
Snow International Corporation
Spectrum Writer
Pacific Systems Group
SQLPRO Agent
Beacon Ware, Inc.
SQR Workbench
MITI
Star Tracker
Leep Technology, Inc.
Strategy
ShowCase Corporation
The Reporter
Sea Change Systems, Inc
Unique XTRA
Unique AS
URSA InfoSuite
Decision Support Inc.
ViewPoint
Informix
PRODUCTO
ViewPoint
Soliton Associates
Viper
Brann Software
VisPro/Reports
Hock Ware
Visual Cyberquery
Cyberscience Corporation
Visual Dbase
Borland
Visual Express
Computer Associates International
Visual FoxPro
Microsoft Corporation
Visual Net
CNet Svenska AB
Visualizer Query, Charts
IBM
Voyant
Brossco Systems
WebBiz
Cybercom Partners
WebSeQueL
InfoSpace Inc.
WinQL
Data Access Corporation
Xentis
GrayMatter Software Corporation
Pag. 80 de 93
Anexo 1-B
HERRAMIENTAS DE BASE DE DATOS

MULTIDIMENSIONAL/OLAP
PRODUCTO
TIPO
Acuity ES
Acuity Management Systems Ltd.
MDDB
Acumate ES
Kenan Systems Corporation
MDDB
Advance For Windows
Lighten, Inc.
MDDB
AMIS OLAP Server
Hoskyns Group plc
MDDB
BrioQuery
Brio Technology
MDDB
Business Objects
Business Objects, Inc.
Relacional
Commander OLAP, Decision, Prism
Comshare Inc.
MDDB
Control
KCI Computing
Relacional
CrossTarget
Dimensional Insight
MDDB
Cube-It
FICS Group
MDDB
Dataman
SLP Infoware
MDDB
DataTracker
Silvon Software, Inc.
Relacional
DecisionSuite
Information Advantage, Inc.
Relacional
Delta Solutions
MIS AG
MDDB
Demon for Windows
Data Command Limited
MDDB
DSS Agent
MicroStrategy
Relacional
DynamicCube.OCX
Data Dynamics, Ltd.
Relacional
EKS/Empower
Metapraxis, Inc.
MDDB
Essbase Analysis Server
Arbor Software Corporation
MDDB
Essbase/400
ShowCase Corporation
MDDB
Express Server, Objects
Oracle
MDDB
Fiscal
Lingo Computer Design, Inc.
Relacional
Fusion
MDDB
FYI Planner
Think Systems
MDDB
Gentia
Planning Sciences
MDDB
Helm
Codeworks
MDDB
Holos
Holistic Systems
MDDB
Hyperion OLAP
Hyperion Software
MDDB
InfoBeacon
Platinum technology, Inc.
Relacional
Informer
Reportech
MDDB/Relacional
Pag. 81 de 93
Intelligent Decision Server
IBM
Relacional
IQ/Vision
IQ Software Corporation
Relacional
Khalix
Longview Solutions, Inc.
Relacional
Lightship
Pilot Software, Inc.
MDDB
Matryx
Stone, Timber, River
MDDB
MDDB Server
SAS
Relacional
Media
Speedware Corporation
MDDB
Metacube
Informix
Relacional
MIKSolution
MIK
MDDB
MIT/400
SAMAC, Inc
MDDB
PRODUCTO
TIPO
MSM
Micronetics Design Corporation
MDDB
Muse
OCCAM Research Corp.
MDDB
OLAP Office
Graphitti Software GmbH
MDDB
OpenOLAP
Inphase Software Limited
Relacional
Pablo
Andyne
MDDB/Relacional
ParaScope
DataVista
Relacional
PowerPlay
Cognos Corporation
MDDB/Relacional
StarTrieve
SelectStar
Relacional
The Ant Colony
Geppetto's Workshop LLC
Relacional
TM/1
Applix
MDDB
Toto
Ambit Research Ltd.
MDDB
Track for OLAP
Track Business Solutions
MDDB
Visualizer Plans for OS/2

IBM
MDDB: Multidimensional Data Base.
MDDB
Pag. 82 de 93
Anexo 1-C
SISTEMAS DE INFORMACION EJECUTIVOS

PRODUCTO
TIPO
Acuity/ES
Acuity Management Systems Limited
Applixware
Applix
BusinessMetrics
Valstar Systems Ltd.
BOARD
Pragma Inform
COINS
Russell Consulting Limited
ColumbusEIS
Jitcons YO
Commander EIS
Comshare Inc.
Corporate Management/ Financial

Executive Information System
Strategic Information Associates, Inc.
CorVu
CorVu Pty Ltd.
Decision Suite
Softkit
Discovery EIS
Atlantic Information Systems Ltd.
EIS
Inphase Software Limited
Electronic Balanced Scorecard
ASI Financial Services
Enterprise Periscope
Everyware Development Corp.
Eureka
European Management Systems
ExecuSense
TLG Corporation
FOCUS EIS
Forest & Trees
Platinum Technologies, Inc.
Pag. 83 de 93
iMonitor
BayStone Software
InfoManager
Ferguson Information Systems
Iridon Almanac
The Great Elk Company Limited
inSight
Arcplan Information Services
LEADER
Sterling Strategic Solutions
PRODUCTO
TIPO
MagnaFORUM
Forum Systems, Inc.
Merit
GIST, s.r.o.
Open EIS Pak
Microsoft
Panorama Business Views
Panorama Business Views Inc.
Perspectives
Syntell
Qbit
Zenia Software, Inc.
Reveal
CSD Software Inc.
SAS System
SAS Institute
Show Business EIS
Show Business Software
Tiler EIS++
Avoca Systems Limited
Track
Track Business Solutions
Traffic Control EIS
Research & Planning, Inc.
VentoMap, VentoSales
Vento Software Inc.
Virtual Headquarters Management System
vHQ LLC
Visual EIS
Synergistic Software
Pag. 84 de 93
Visual Publisher
KMA Associates International, Inc
VITAL
Braintec Corporation
Wingz
Investment Intelligence Systems Group
Wired for OLAP
AppSource Corporation
Xecutive Pulse EIS
Megatrend Systems, Ltd.
1. Proporciona un sistema de informacin ejecutivo con capacidades analticas.

2. Proporciona un sistema de informacin ejecutivo con capacidades analticas para usuarios
SAP R/3.
3. Proporciona un sistema de informacin ejecutivo con capacidades analticas para usuarios

SAP R/2 y R/3.
Pag. 85 de 93
Anexo 1-D
BASES DE DATOS USADAS PARA DATA

WAREHOUSE
PRODUCTO
Adabas D
Software AG
Advanced Pick
Pick Systems
DB2
IBM
Fast-Count DBMS
MegaPlex Software
HOPS
HOPS International
Microsoft SQL Server
Microsoft
Model 204
Computer Corporation of America
NonStop SQL
Tandem
Nucleus Server
Sand Technology Systems
OnLine Dynamic Server,

Informix
Extended Parallel Server
OpenIngres
Computer Associates
Oracle Server
Oracle
Rdb
Oracle
Red Brick Warehouse
Red Brick Systems
SAS System
SAS
Sybase IQ
Sybase
Sybase SQL Server, SQL Server MPP
Sybase
SymfoWARE
Fujitsu
Teradata DBS
NCR
THOR
Hitachi
Time Machine
Data Management Technologies, Inc.
Titanium
Micro Data Base Systems, Inc.
Unidata
Unidata, Inc.
UniVerse
VMARK
Vision
Innovative Systems Techniques, Inc.
WX9000
White Cross Systems Inc.
XDB Server
XDB Systems, Inc.
Pag. 86 de 93
ANEXO 2. GLOSARIO
GLOSARIO DE TERMINOS
BACKBONE
Red principal de una red de comunicaciones.
BASE DE DATOS (DATA BASE)
Conjunto de datos no redundantes, almacenados en un soporte informtico, organizados de
forma independiente de su utilizacin y accesibles simultneamente por distintos usuarios y
aplicaciones. La diferencia de una BD respecto a otro sistema de almacenamiento de datos
es que stos se almacenan en la BD de forma que cumplen tres requisitos bsicos: no
redundancia, independencia y concurrencia.
BLOB (Binary Large Object)
Objeto binario grande. Entre los tipos de datos que contienen los campos BLOB estn:
binarios, memo, memo con formato, de imagen, de sonido y OLE.
CLIENTE/SERVIDOR
Arquitectura de sistemas de informacin en la que los procesos de una aplicacin se dividen
en componentes que se pueden ejecutar en mquinas diferentes. Modo de funcionamiento
de una aplicacin en la que se diferencian dos tipos de procesos y su soporte se asigna a
plataformas diferentes.
CODIFICACION
a) Transformacin de un mensaje en forma codificada, es decir, especificacin para la
asignacin unvoca de los caracteres de un repertorio (alfabeto, juego de caracteres) a los
de otro repertorio.
b) Conversin de un valor analgico en una seal digital segn un cdigo prefijado.
DETECCION DE DESVIACION
Normalmente, para la deteccin de desviacin en bases de datos grandes se usa la
informacin explcita externa a los datos, as como las limitaciones de integridad o modelos
predefinidos. En un mtodo lineal por contraste, se enfoca el problema desde el interior de
los datos, usando la redundancia implcita de los datos. Aqu se simula un mecanismo
familiar a los seres humanos: despus de ver una serie de datos similares, un elemento que
perturba la serie se considera una excepcin.
Pag. 87 de 93
DICCIONARIO DE DATOS
Descripcin lgica de los datos para el usuario. Rene la informacin sobre los datos
almacenados en la BD (descripciones, significado, estructuras, consideraciones de
seguridad, edicin y uso de las aplicaciones, etc.).
DIRECTORIO DE DATOS
Es un subsistema del sistema de gestin de base de datos que describe dnde y cmo se
almacenan los datos en la BD (modo de acceso y caractersticas fsicas de los mismos).
DRILL-DOWN
Obtencin de informacin ms detallada sobre un conjunto de informacin en el cual se est
trabajando. Ejemplo: Si se est mirando el Activo, obtener todas las cuentas del activo.
EXTRANET
Constituye un servicio de comunicacin orientado a un pblico focalizado sobre el formato
de los sistemas Web, operando sobre la red Internet. Ejemplo: Una casa de ventas de
productos varios, implementa un sistema de Ofertas, Consulta a Catlogos, Bancos de
Datos y Compras a sus clientes preferenciales.
IN-HOUSE
Aplicable a la realizacin de un servicio de outsourcing en las instalaciones de la
organizacin que contrata el servicio.
INCONSISTENCIA
El contenido de una base de datos es inconsistente si dos datos que deberan ser iguales no
lo son. Por ejemplo, un empleado aparece en una tabla como activo y en otra como jubilado.
INTEGRIDAD
Condicin de seguridad que garantiza que la informacin es modificada, incluyendo su
creacin y borrado, slo por el personal autorizado.
INTERNET
Trmino usado para referirse a la red ms grande del mundo, que conecta miles de redes
con alcance mundial. Est creando una cultura que basndose en la simplicidad,
investigacin y estandarizacin fundamentado en usos de la vida real, est cambiando la
forma de ver y hacer muchas de las tareas actuales. Mucha de la tecnologa de punta en
redes est proviniendo de la comunidad Internet.
INTRANET
Constituye un servicio de comunicacin de los sistemas de informacin corporativos
orientados a su personal, sobre el formato de los sistemas Web, operando sobre la red
Internet. Ejemplo: El sistema contable de una empresa de ventas de productos de ferretera,
tipo Home Center.
Pag. 88 de 93
LIBRO ELECTRONICO
Gua electrnica. Documento realizado en un sistema informtico, normalmente con
caractersticas hipertexto y multimedia.
MAP
a) Conjunto de datos
b) Lista de datos u objetos, tal como actualmente estn almacenados en memoria o en
disco.
c) Transferir un conjunto de objetos de un lugar a otro. Por ejemplo, los mdulos de
programas en el disco son proyectados ("mapeados") en la memoria. Una imagen grfica en
memoria es proyectada en la pantalla.
d) Relacionar un conjunto de objetos con otro. Por ejemplo, una estructura de base de datos
lgica se proyecta sobre la base de datos fsica.
Mapping.- Proyeccin, correspondencia, transformacin.
MODELAMIENTO PREDICTIVO (Inteligencia Artificial)

Las herramientas de modelamiento predictivo permiten realizar relaciones complejas o
modelos desde un archivo de datos.
Una de las principales diferencias entre los modelos estadsticos y los modelos de
inteligencia artificial, es cmo miden su error. Los primeros miden el error relativo tal como el
modelo "adapta" los datos, mientras que los segundos, miden el error relativo a los datos
an invisibles (Error predictivo).
Segundo, los modelos estadsticos tienen dificultades al dar datos contradictorios o
desordenados, es decir, los datos deben estar limpios y deben existir las correlaciones
consistentes. Viceversa, las herramientas de inteligencia artificial buscan "generalizar"
relaciones para proporcionar el resultado ms probable.
El modelamiento abductivo (argumento en que la premisa mayor es evidente y la menor
probable, pero mas creible que la conclusin) usa funciones polinmicas para describir las
relaciones al interior de los datos. Esta metodologa facilita una variable de entrada para ser
ponderado ms de una vez. Adicional, slo se incluyen los trminos que significativamente
contribuyen al rendimiento.
Los modelos predictivos pueden usarse para el soporte de decisin o presentando subrutinas para desarrollar aplicaciones predictivas a clientes. Las capacidades de los modelos
predictivos pueden mejorarse si los archivos de datos se mejoran con tantas variables de
entrada como sea posible.
PROGRAMACION GENETICA (PG)
El paradigma de Programacin Gentica, propuesto por John Koza, es una extensin de los
algoritmos genticos que difiere de stos en la forma en que representa a los individuos de
la poblacin, pues utiliza programas de computadora en lugar de cadenas de longitud fija.
Pag. 89 de 93
La meta de la PG es lograr que las computadoras aprendan a resolver problemas sin ser
explcitamente programadas, generando soluciones a problemas a partir de la induccin de
programas. El programador no especifica el tamao, forma y complejidad estructural de los
programas-solucin, sino que los programas evolucionan hasta generar soluciones
satisfactorias.
Dentro del espacio de posibles programas de computadora, la induccin de programas
involucra el descubrimiento inductivo de un programa que produzca alguna salida deseada,
cuando se le presenta alguna entrada en particular. Y sto es precisamente lo que la
metodologa de PG realiza de una manera sistematizada.
Con base en este planteamiento, un programa puede ser llamado una frmula, un plan, una
estrategia de control, un procedimiento computacional, etc. Similarmente, las entradas del
programa pueden ser llamadas variables independientes, variables de estado, valores de
sensores, argumentos de una funcin, etc. A su vez las salidas del programa pueden
denominarse variables dependientes, un movimiento, un actuador, el valor regresado por
una funcin, etc.
En programacin gentica, poblaciones de cientos, miles y decenas de miles de programas
o ms, se desarrollan genticamente. Este desarrollo se hace usando el principio darwiniano
de supervivencia del ms apto y las operaciones genticas primarias de Reproduccin y
Cruce (o recombinacin sexual) .
Caractersticas.
a) La forma de rbol de los programas de computadora. Para evitar el crecimiento
descontrolado de un programa, en muchos casos pueden encapsularse subrboles en hojas
individuales.
b) En cada etapa de este proceso altamente paralelo, descentralizado y localmente
controlado, el estado consiste nicamente de la poblacin actual de individuos.
c) La variabilidad dinmica de los programas en la bsqueda de la solucin. A menudo, es
difcil y no natural tratar de especificar o restringir el tamao y forma de una solucin
eventual de antemano. Ms an, el hacerlo reduce el tamao de la ventana por la cual el
sistema ve al mundo, pudiendo evitar encontrar la solucin final o, peor an, encontrar una
solucin predeterminada.
d) Ausencia o un menor pre-procesamiento de entradas y post-procesamiento de salidas.
Tpicamente, las entradas, los resultados intermedios y las salidas son expresados de
manera directa en la terminologa natural del dominio del problema. Los programas
producidos por la PG consisten de funciones que son naturales al dominio del problema.
e) En la PG las estructuras que sobreviven a la adaptacin son activas. Estas no son
cdigos pasivos (cromosomas) de la solucin de un problema. Las estructuras de PG son
estructuras activas capaces de ser ejecutadas en su forma actual.
En conclusin, la programacin gentica sistematiza el problema de induccin de
programas, es decir, la generacin automtica de un programa que solucione un problema
dado. La importancia de la induccin de programas se hace evidente al observar que todos
los problemas se pueden reformular como un programa de computadora.
Pag. 90 de 93
La metodologa de PG proporciona caractersticas muy importantes para el diseo, de

manera robusta, de sistemas que acten sobre condiciones inestables en ambientes
cambiantes.
RED NEURONAL ARTIFICIAL
Son abstracciones ms o menos complejas que tratan de emular el funcionamiento de las
redes neuronales del cerebro humano. La mayora de las veces son modelos tericos que
se plasman en programas de ordenador y unas pocas modelos sobre silicio para aprovechar
la velocidad de proceso paralelo de estas arquitecturas.
Las neuronas individuales se conectan con otros para formar una "Red" de conexiones. La
conexin individual entre dos neuronas se pondera para proveer su contribucin al
pronstico del rendimiento deseado.
REDUNDANCIA
Repeticin de los mismos datos en varios lugares.
REPOSITORIO
Base de datos central en herramientas de ayuda al desarrollo. El repositorio ampla el
concepto de diccionario de datos para incluir toda la informacin que se va generando a lo
largo del ciclo de vida del sistema, como por ejemplo:
componentes de anlisis y diseo (diagramas de flujo de datos, diagramas entidad-relacin,
esquemas de bases de datos, diseos de pantallas, etc.), estructuras de programas,
algoritmos, etc. En algunas referencias se le denomina Diccionario de recursos de
informacin.
SCORING
Calificacin que se le da a un grupo de clientes/productos que mide la propensin a
compras, ventas, retiro, llegadas, etc.
Pag. 91 de 93
SISTEMA DE GESTION DE BASE DE DATOS

Software que controla la organizacin, almacenamiento, recuperacin, seguridad e
integridad de los datos en una base de datos. Acepta pedidos de datos desde un programa
de aplicacin y le ordena al sistema operativo transferir los datos apropiados.
Cuando se usa un sistema de gestin de base de datos, SGDB, (en ingls DBMS), los
sistemas de informacin pueden ser cambiados ms fcilmente a medida que cambien los
requerimientos de la organizacin. Nuevas categoras de datos pueden agregarse a la base
de datos sin daar el sistema existente.
SISTEMA DE INFORMACION (SI)
Conjunto de elementos fsicos, lgicos, de comunicacin, datos y personal que,
interrelacionados, permiten el almacenamiento, transmisin y proceso de la informacin.
SQL (Structured Query Language)
Lenguaje de interrogacin normalizado para bases de datos relacionales. El SQL es un
lenguaje de alto nivel, no procedural, normalizado, que permite la consulta y actualizacin de
los datos de BD relacionales. Se ha convertido en el estndar para acceder a BD
relacionales. La primera versin se aprob como norma ISO en 1987 y la segunda, conocida
como SQL2 y vigente actualmente, en 1992.
Actualmente se trabaja en la norma SQL3 que soportar bases de datos orientadas a objeto
y bases de datos activas. El SQL facilita un lenguaje de definicin de datos y un lenguaje de
manipulacin de datos. Adems, incluye una interfase que permite el acceso y manipulacin
de la BD a usuarios finales.
TERABYTE (TB)
Unidad de medida que equivale a 1024 GB.
TERADATA
El Sistema de Gestin de Base de Datos Relacional (RDBMS) Teradata de NCR, es una
base de datos relacional paralela de soporte de decisiones muy poderosa para data
warehousing. Con el servidor basado en el soporte para UNIX SVR4 y Microsoft Windows
NT, Teradata ofrece soporte a las empresas para la escalabilidad desde gigabytes a
terabytes, petabytes y ms.
Teradata tambin proporciona conectividad open client a virtualmente todos los sistemas
operativos, incluyendo Microsoft DOS, Windows, Windows 95, Windows NT, IBM OS/2 y
Apple Macintosh. Adems, soporta conectividad a cliente desde las aplicaciones basadas en
el host que corre sobre sistemas UNIX y en mainframes. De hecho, ofrece una conectividad
de mainframes muy resistente con canal paralelo bidireccional de alta velocidad para
mainframes de IBM, Unisys, Hitachi, Amdahl, Bull y otros.
Historia. El producto inicial de la Corporacin Teradata NCR se dise especficamente
para descargar el procesamiento reiterativo a gran escala de las mainframes IBM,
permitindoles enfocar hacia sus tareas operacionales principalmente.
Pag. 92 de 93
En 1984, sac el primer sistema de procesamiento paralelo masivo (MPP) del mundo para
computacin comercial, el Data Base Computer Modelo 1, ms conocido como el DBC 1012.
El nombre (especficamente "1012") personific la filosofa de la corporacin al soportar la
accesibilidad de Terabytes (10^12 Bytes) de datos por miles de usuarios concurrentes
corriendo consultas de negocios complejas.
En 1991, la Corporacin NCR compr la Corporacin Teradata NCR adquiriendo su
avanzada y nica tecnologa de procesamiento en paralelo comercial. La arquitectura de
hardware del DBC 1012 original evolucion en la actual familia WorldMark Server y el
software de base de datos se ha convertido en NCR Teradata RDBMS.
Hoy, el NCR Teradata RDBMS corre sobre plataformas Intel basado en UNIX y Windows
NT. Es an el nico producto de base de datos capaz de soportar data warehouses por
sobre los 500 Gigabytes de datos de usuario real.
UNIX
Sistema operativo multiproceso, multiprograma y multiusuario. Software diseado por AT&T
para ingeniera de telecomunicacin. Ha sido el primer sistema operativo concebido con
independencia de los fabricantes. Posee una gran facilidad para adaptarse a ordenadores
con diferentes arquitecturas, siendo ampliamente autnomo respecto del hardware. Est
escrito en lenguaje de alto nivel C.
--- O ---
Pag. 93 de 93

Capitulo4 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capitulo4 2

Cargado por

Copyright:

Formatos disponibles

MANUAL PARA LA CONSTRUCCIN DE UN

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

2.2. Fase: Desarrollo

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

Econ. Flix Murillo Alfaro

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

Base de Datos Operacional

Datos del negocio para Informacin

Diferentes tipos de informacin

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.2 SISTEMAS DE INFORMACION

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

Sistemas Tcticos, diseados para soportar las actividades de coordinacin de

Sistemas Tcnico-Operativos, que cubren el ncleo de operaciones tradicionales

Sistemas Interinstitucionales, este ltimo nivel de sistemas de informacin recin

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

comunicacin ms estrechas entre la organizacin y el mercado (Empresa

1.2.1 Sistemas tcnico-operacionales

1.2.2 Sistemas de Soporte de Decisiones

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.3 CARACTERISTICAS DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.3.1 Orientado a Temas

El ambiente operacional se disea alrededor de las aplicaciones y funciones tales como

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

Codificacin. Los diseadores de aplicaciones codifican el campo GENERO en

Medida de atributos. Los diseadores de aplicaciones miden las unidades de

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

Convenciones de Nombramiento.- El mismo elemento es frecuentemente referido

Fuentes Mltiples.- El mismo elemento puede derivarse desde fuentes mltiples.

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.3.3 De Tiempo Variante

El tiempo variante se muestra de varias maneras:

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

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

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

ambientes. Desde luego, la primera impresin de muchas personas se centra en la gran

Los datos se filtran cuando pasan desde el ambiente operacional al de depsito.

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.4 ESTRUCTURA DEL DATA WAREHOUSE

Detalle de datos actuales

Detalle de datos actuales.- En gran parte, el inters ms importante radica en el

Datos ligeramente resumidos.- La data ligeramente resumida es aquella que

Datos completamente resumidos.- El siguiente nivel de datos encontrado en el

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

A veces se encuentra en el ambiente de data warehouse y en otros, fuera del lmite de la

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

Metadata.- El componente final del data warehouse es el de la metadata. De

La metadata juega un papel mucho ms importante en un ambiente data warehousing que

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

La estructura de los datos

La informacin adicional que no se esquematiza es almacenada en el data warehouse. En

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.5 ARQUITECTURA DE UN DATA WAREHOUSE

ARQUITECTURA DE UN DATA WAREHOUSE

MANUAL PARA LA CONSTRUCCIN DE UN DATA WAREHOUSE

1.5.1 Elementos constituyentes de una Arquitectura

Base de datos operacional / Nivel de base de datos externo