Download 1. Data Warehouses

CAMPUS SANTIAGO
INGENIERÍA (E) EN INFORMÁTICA PARA TÉCNICOS
Avenida República N° 517, Santiago, RM
Teléfono: (2) 6753000
DATAWAREHOUSE
Profesor
Héctor Schulz Pérez
Integrantes
Luis Prieto Quezada
Claudio Biewer Mansilla
Rodrigo Arenas Aguirre
Santiago, 31 de Agosto 2011
2
Índice
D A T A W A R E H O U S E ...........................................................................................1
I. Introducción ......................................................................................................................3
II.
Definición .......................................................................................................................3
III.
Objetivos del Data Warehouse .................................................................................4
IV. Características del Data Warehouse ......................................................................5
A.
B.
C.
D.
V.
VI.
Orientado a temas ................................................................................................................ 5
Integrado................................................................................................................................. 7
De tiempo variante (Variable en el tiempo)..................................................................10
No volátil ...............................................................................................................................13
Por qué construir un DataWarehouse? ............................................................... 15
Ciclo de Desarrollo ....................................................................................................16
A.
B.
C.
Consideraciones previas al desarrollo de un DataWarehouse ..............................18
Alcance de un Data Warehouse .....................................................................................19
Redundancia de Datos ......................................................................................................19
VII.
Modelo de Planificación para un DataWarehouse ............................................21
A.
B.
C.
D.
E.
Requerimientos del Negocio ...........................................................................................22
Misión ....................................................................................................................................23
Decisiones ............................................................................................................................23
Decisiones clasificadas por clase de usuario, tipo y función de negocio ..........27
Planificación Tecnológica ....................................................................................................28
VIII.
Arquitectura del DataWarehouse .......................................................................30
A.
B.
C.
El motor del dataWarehouse ...........................................................................................32
Requisitos para que un DBMS trabaje con un Data Warehouse ..........................39
Herramientas de Acceso ó Herramientas de Usuario Final ....................................42
IX.
A.
B.
C.
D.
E.
X.
XI.
Explotación del Data Warehouse ..........................................................................47
Potencial del Data Warehouse ........................................................................................47
Extracción y manipulación de datos del Data Warehouse......................................47
Procesamiento Informático .............................................................................................48
Procesamiento Analítico ..................................................................................................49
Data Mining ..............................................................................................................................51
Glosario de Términos asociados con Data Warehouse ..................................52
Bibliografía ..................................................................................................................56
3
I. Introducción
El hombre, desde los orígenes de la civilización se ha interesado en la utilización
de la información, en el campo de batalla, en el proceso de edificación de las
grandes estructuras y para anticiparse a los eventos de la naturaleza; siempre ha
requerido cada vez más contar con mejores fuentes de información.
La Revolución de la información, ha provocado cambios fundamentales en la
elaboración y el uso de la información producidos a finales del siglo XX.
La
información dispuesta en el periódico y hasta la información almacenada en las
bases de datos han permitido que la información esté al alcance de todos y la
tecnología asociada a todos estos logros de nuestra sociedad han conducido a que
esta información empiece a adquirir importancia estratégica. gracias a que esa
información se interrelaciona como se ha estudiado en el tema de Data
Warehouse.
II. Definición
Como definición inicial para la compresión del término, Data Warehouse se traduce
al idioma español, como un almacén, depósito o bodega de datos, pero aplicando
el término a la vida cotidiana, tal como lo señala William Harvey Inmon, quien es
considerado como el padre de este concepto, “un Data Warehouse es un conjunto
de datos integrados orientados a una materia que varían con el tiempo y que no
son transitorios, los cuales soportan el proceso de toma de decisiones de una
administración."
De acuerdo con algunas organizaciones, el Data Warehouse es una arquitectura.
Para otras, es un depósito consistente en datos (separados y que no interfieren con
los sistemas operativos y de producción existentes) que Ilena por completo los
diferentes requerimientos de acceso y reporte de datos. Para algunos otros, el Data
Warehouse es un proceso continuo que mezcla los datos de varias fuentes
4
heterogéneas, incluyendo datos históricos y adquiridos para soportar la constante
necesidad de consultas estructuradas y/o ad hoc, reportes analíticos y soporte de
decisiones.
Así como hay gran divergencia para establecer una definición precisa de un Data
Warehouse, hay un claro consenso de que la tecnología del Data Warehouse es un
ingrediente esencial en el conjunto de soluciones para el soporte de decisiones en
una empresa.
III. Objetivos del Data Warehouse
Hacer que la información de la organización sea accesible: los contenidos del Data
Warehouse son entendibles y navegables, y el acceso a ellos son caracterizado por
el rápido desempeño. Estos requerimientos no tienen fronteras y tampoco limites
fijos. Cuando hablamos de entendible significa, que los niveles de la información
sean correctos y obvios. Mientras que cuando hablamos de navegables, significa el
reconocer el destino en la pantalla y llegar a donde queramos con solo un clic.
Rápido desempeño significa, cero tiempos de espera.
Hacer que la información de la organización sea consistente: la información de una
parte de la organización puede hacerse coincidir con la información de la otra parte
de la organización. Si dos medidas de la organización tienen el mismo nombre,
entonces deben significar la misma cosa. Y a la inversa, si dos medidas no
significan la misma cosa, entonces son etiquetados diferentes. Información
consistente significa, información de alta calidad. Significa que toda la información
es contabilizada y completada.
Ser información adaptable y elástica: el Data Warehouse está diseñado para
cambios continuos. Cuando se le hacen nuevas preguntas al Data Warehouse, los
datos existentes y las tecnologías no cambian ni se corrompen. Cuando se agregan
datos nuevos al Data Warehouse, los datos existentes y las tecnologías tampoco
cambian ni se corrompen.
5
Ser un seguro baluarte que protege los valores de la información: el Data
Warehouse no solamente controla el acceso efectivo a los datos, si no que da a los
dueños de la información gran visibilidad en el uso y abusos de los datos, aún
después de haber dejado el Data Warehouse.
Ser la fundación de la toma de decisiones: el Data Warehouse tiene los datos
correctos para soportar la toma de decisiones. Solo hay una salida verdadera del
Data Warehouse: las decisiones que son hechas después de que el Data
Warehouse haya presentado las evidencias. La original etiqueta que preside el
Data Warehouse sigue siendo la mejor descripción de lo que queremos construir,
un sistema de soporte a las decisiones.
IV. Características del Data Warehouse
A. Orientado a temas
Una primera característica del Data Warehouse es que la información se
clasifica en base a los aspectos que son de interés para la empresa. Siendo así,
los datos tomados están en contraste con los clásicos procesos orientados a las
aplicaciones.
En la Figura se muestra el contraste entre los dos tipos de orientaciones.
FIG.1
6
El ambiente operacional se diseña alrededor de las aplicaciones y funciones
tales como préstamos, ahorros, tarjeta bancaria y depósitos para una institución
financiera. Por ejemplo, una aplicación de ingreso de órdenes puede acceder a
los datos sobre clientes, productos y cuentas. La base de datos combina estos
elementos en una estructura que acomoda las necesidades de la aplicación.
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 médico, medicamentos, etc.
La alineación alrededor de las áreas de los temas afecta el diseño y la
implementación de los datos encontrados en el Data Warehouse. Las principales
áreas de los temas influyen en la parte más importante de la estructura clave.
Las aplicaciones están relacionadas con el diseño de la base de datos y del
proceso. En Data Warehousing se enfoca el modelamiento de datos y el diseño
de la base de datos. El diseño del proceso (en su forma clásica) no es separado
de este ambiente.
Las diferencias entre la orientación de procesos y funciones de las aplicaciones
y la orientación a temas, radican en el contenido de la data a escala detallada.
En el Data Warehouse se excluye la información que no será usada por el
proceso de sistemas de soporte de decisiones, mientras que la información 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.
7
Otra diferencia importante está en la interrelación de la información. Los datos
operacionales mantienen una relación continua entre dos o más 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 más tablas.
B. Integrado
Integra datos recolectados de diferentes sistemas operacionales de la
organización y o fuentes externas.
FIG.2
El aspecto más importante del ambiente Data Warehousing es que la
información encontrada al interior está siempre integrada.
8
La integración de datos se muestra de muchas maneras: en convenciones de
nombres consistentes, en la medida uniforme de variables, en la codificación de
estructuras consistentes, en atributos físicos de los datos consistentes, fuentes
múltiples y otros.
El contraste de la integración encontrada en el Data Warehouse con la carencia
de integración del ambiente de aplicaciones, se muestran en la figura, con
diferencias bien marcadas.
A través de los años, los diseñadores de las diferentes aplicaciones han tomado
sus propias decisiones sobre cómo se debería construir una aplicación. Los
estilos y diseños personalizados se muestran de muchas maneras.
Se diferencian en la codificación, en las estructuras claves, en sus
características físicas, en las convenciones de nombramiento y otros. La
capacidad colectiva de muchos de los diseñadores de aplicaciones, para crear
aplicaciones inconsistentes, es fabulosa. La figura mencionada, muestra algunas
de las diferencias más importantes en las formas en que se diseñan las
aplicaciones.
Codificación. Los diseñadores de aplicaciones codifican el campo GENERO en
varias formas. Un diseñador 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 cómo el GENERO llega al Data Warehouse. Probablemente
"M" y "F" sean tan buenas como cualquier otra representación. 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
aplicación, donde ha sido representado en formato "M" y "F", los datos deben
convertirse al formato del Data Warehouse.
9
Medida de atributos. Los diseñadores de aplicaciones miden las unidades de
medida de las tuberías en una variedad de formas. Un diseñador almacena los
datos de tuberías en centímetros, otros en pulgadas, otros en millones de pies
cúbicos por segundo y otros en yardas.
Al dar medidas a los atributos, la transformación traduce las diversas unidades
de medida usadas en las diferentes bases de datos para transformarlas en una
medida estándar común.
Cualquiera que sea la fuente, cuando la información de la tubería llegue al Data
Warehouse necesitará ser medida de la misma manera.
Convenciones de Nombramiento. El mismo elemento es frecuentemente
referido por nombres diferentes en las diversas aplicaciones. El proceso de
transformación asegura que se use preferentemente el nombre de usuario.
Fuentes Múltiples. El mismo elemento puede derivarse desde fuentes múltiples.
En este caso, el proceso de transformación debe asegurar que la fuente
apropiada sea usada, documentada y movida al depósito.
Tal como se muestra en la figura, los puntos de integración afectan casi todos
los aspectos de diseño - las características físicas de los datos, la disyuntiva de
tener más de una de fuente de datos, el problema de estándares de
denominación inconsistentes, formatos de fecha inconsistentes y otros.
Cualquiera que sea la forma del diseño, el resultado es el mismo - la información
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.
10
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 depósito, antes que preguntarse sobre la confiabilidad o consistencia de los
datos.
FIG.3
C. De tiempo variante (Variable en el tiempo)
Los datos son relativos a un periodo de tiempo y estos deben ser integrados
periódicamente, los mismos son almacenados como fotos que se corresponden
a un periodo de tiempo.
11
FIG.4
Toda la información del data Warehouse es requerida en algún momento. Esta
característica básica de los datos en un depósito, es muy diferente de la
información encontrada en el ambiente operacional. En éstos, la información se
requiere al momento de acceder. En otras palabras, en el ambiente operacional,
cuando usted accede a una unidad de información, usted espera que los valores
requeridos se obtengan a partir del momento de acceso.
Como la información en el data Warehouse es solicitada en cualquier momento
(es decir, no "ahora mismo"), los datos encontrados en el depósito se llaman de
"tiempo variante".
Los datos históricos son de poco uso en el procesamiento operacional. La
información del depósito por el contraste, debe incluir los datos históricos para
usarse en la identificación y evaluación de tendencias. (Ver Figura).
12
FIG.5
El tiempo variante se muestra de varias maneras:
La más simple es que la información representa los datos sobre un horizonte
largo de tiempo - desde cinco a diez años. El horizonte de tiempo representado
para el ambiente operacional es mucho más corto - desde valores actuales hasta
sesenta a noventa días. Las aplicaciones que tienen un buen rendimiento y
están disponibles para el procesamiento de transacciones, deben llevar una
cantidad mínima de datos si tienen cualquier grado de flexibilidad. Por ello, las
aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseño
de aplicaciones rígidas.
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, implícita o explícitamente, un elemento de tiempo como
día, 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á
13
implícitamente, como el caso en que un archivo completo se duplica al final del
mes, o al cuarto.
La tercera manera en que aparece el tiempo variante es cuando la información
del data Warehouse, una vez registrada correctamente, no puede ser
actualizada. La información del data Warehouse es, para todos los propósitos
prácticos, una serie larga de "snapshots" (vistas instantáneas). 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.
D. No volátil
Los datos que son almacenados no sufren ninguna actualización solo son
incrementados. El período cubierto para un DW va de 2 a 10 años.
FIG.6
14
La información es útil sólo cuando es estable. Los datos operacionales cambian
sobre una base momento a momento. La perspectiva más grande, esencial para
el análisis y la toma de decisiones, requiere una base de datos estable.
En la Figura se muestra que la actualización (insertar, borrar y modificar), se
hace regularmente en el ambiente operacional sobre una base de registro por
registro. Pero la manipulación básica de los datos que ocurre en el data
Warehouse es mucho más simple. Hay dos únicos tipos de operaciones: la
carga inicial de datos y el acceso a los mismos. No hay actualización de datos
(en el sentido general de actualización) en el depósito, como una parte normal
de procesamiento.
Hay algunas consecuencias muy importantes de esta diferencia básica, entre el
procesamiento operacional y del data Warehouse. En el nivel de diseño, la
necesidad de ser precavido para actualizar las anomalías no es un factor en el
data Warehouse, ya que no se hace la actualización de datos. Esto significa que
en el nivel físico de diseño, se pueden tomar libertades para optimizar el acceso
a los datos, particularmente al usar la normalización y desnormalización física.
Otra consecuencia de la simplicidad de la operación del data Warehouse está en
la tecnología subyacente, utilizada para correr los datos en el depósito. Teniendo
que soportar la actualización de registro por registro en modo on-line (como es
frecuente en el caso del procesamiento operacional) requiere que la tecnología
tenga un fundamento muy complejo debajo de una fachada de simplicidad.
15
FIG.7
V. Por qué construir un DataWarehouse?
Pueden darse algunas justificaciones para un emprendimiento de DataWarehouse:






Sistemas no integrados
Múltiples e incompatibles estructuras de datos
Muchos puntos de entrada a los datos
Manejo de información histórica
Para facilitar las actividades de reporteo y análisis de usuarios
Proveer una vista única del negocio
FIG.8
16
VI. Ciclo de Desarrollo
El Data Warehouse sigue el mismo ciclo de perfeccionamiento que todos los
desarrollos de software.
2°
3°
Modelizar
datos
Proceso
Iterativo de
construcción
1°
Análisis de
especificaciones
7°
Cargar y
replicar
Localizar
datos
4°
Localizar
datos
Construir
procedimientos
Replicación
Definir
data marts
5°
6°
FIG.9
Las fases del ciclo son las mismas, lo mismo que su secuencia, sólo existen
variantes únicas que se relacionan específicamente con el Data Warehouse para
tareas dentro de estas fases. La siguiente figura muestra el ciclo clásico de
desarrollo de software:
Prueba
Planeación
Desarrollo Requerimientos
Diseño
Análisis
Construcción
FIG.10
17
Planeación: La planeación es una fase importante de la implementación del Data
Warehouse. Las decisiones tomadas durante la fase de planeación tienen un
impacto significativo en el ámbito de implementación y en la magnitud del esfuerzo.
Las decisiones clave de planeación incluyen la selección de un enfoque de arriba
hacia abajo (de Io general a Io particular), de abajo hacia arriba (en sentido
opuesto) o combinado; la selección de la arquitectura apropiada de Data
Warehouse; la selección adecuada del ámbito de información, fuentes de datos y
tamaño del metamodelo; y la estimación de planes de programa y proyecto y
justificaciones de presupuesto.
Requerimientos: Durante la fase de requerimientos se debe considerar una
diversidad de ellos. Los requerimientos son conducidos por el negocio y por la
tecnología. La cuidadosa selección y especificación de requerimientos en esta
etapa proporciona un proyecto cimentado que arroja resultados con rapidez.
Análisis: La fase de análisis es importante ya que determina la forma en que se
cubrirán los requerimientos. Esta fase se enfoca principalmente en la conversión de
especificaciones de requerimientos a especificaciones de metamodelo para el Data
Warehouse. Después, estas especificaciones se usan para generar extractores del
Data Warehouse y software de transformación, integración, resumen y adición.
Construcción: La fase de construcción resalta los diversos intercambios "construir
en comparación con comprar". Mediante la selección adecuada de componentes
suministrados por fabricantes, es posible construir una primera implementación del
Data Warehouse rápida y eficaz.
Despliegue: La fase de despliegue en el ciclo de desarrollo del Data Warehouse
tiene un componente único denominado comercialización de información. Esto
reconoce que la mercancía que suministra el Data Warehouse a sus usuarios
finales (clientes) es la propia información. Como un producto de mercancía, la
información también debe comercializarse como los bienes de consumo. La
18
comercialización comprende la capacidad de hacer énfasis en la disponibilidad, los
beneficios y el empaque para hacerla atractiva al usuario final.
A. Consideraciones previas al desarrollo de un DataWarehouse
Hay muchas maneras para desarrollar data Warehouses como tantas
organizaciones existen. Sin embargo, hay un número de dimensiones diferentes
que necesitan ser consideradas:


Alcance de un data Warehouse
Redundancia de datos
La Figura muestra un esquema bidimensional para analizar las opciones
básicas. La dimensión horizontal indica el alcance del depósito y la vertical
muestra la cantidad de datos redundantes que deben almacenarse y
mantenerse.
Data
Warehouse
distribuido
Redundancia
de datos
Data
Warehouse
Centralizado
Data
Warehouse
Virtual
Warehouse
Virtual
Warehouse
proyecto
Warehouse
Departamento o
divisional
Alcance del
datawarehouse
Warehouse
funcional de la
empresa
FIG.11
19
B. Alcance de un Data Warehouse
El alcance de un data Warehouse puede ser tan amplio como toda la
información estratégica de la empresa desde su inicio, o puede ser tan limitado
como un data Warehouse personal para un solo gerente durante un año.
En la práctica, en la amplitud del alcance, el mayor valor del data Warehouse es
para la empresa y lo más caro y consumidor de tiempo es crear y mantenerlo.
Como consecuencia de ello, la mayoría de las organizaciones comienzan con
data Warehouses funcionales, departamentales o divisionales y luego los
expanden como usuarios que proveen retroalimentación.
C. Redundancia de Datos
Hay tres niveles esenciales de redundancia de datos que las empresas deberían
considerar en sus opciones de data Warehouse:



Data Warehouses "virtual" o "Point to Point"
Data Warehouses "centrales"
Data Warehouses "distribuidos"
No se puede pensar en un único enfoque. Cada opción adapta un conjunto
específico de requerimientos y una buena estrategia de almacenamiento de
datos, lo constituye la inclusión de las tres opciones.
1. Data Warehouses "Virtual" o "Point to Point"
Una estrategia de data Warehouses virtual, significa que los usuarios finales
pueden acceder a bases de datos operacionales directamente, usando
cualquier herramienta que posibilite "la red de acceso de datos".
Este enfoque provee flexibilidad así como también la cantidad mínima de
datos redundantes que deben cargarse y mantenerse. Además, se pueden
colocar las cargas de consulta no planificadas más grandes, sobre sistemas
operacionales.
20
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 depósitos virtuales de datos proveen un punto de partida para que las
organizaciones determinen qué usuarios finales están 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 física, que contiene todos
los datos para un área funcional específica, departamento, división o
empresa.
Los data Warehouses centrales se seleccionan por lo general donde hay una
necesidad común de los datos informáticos y un número grande de usuarios
finales ya conectados a una red o computadora central. Pueden contener
datos para cualquier período específico de tiempo. Comúnmente, contienen
datos de sistemas operacionales múltiples.
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 informático
multidimensional.
21
3. Data Warehouses Distribuidos
Los data Warehouses distribuidos son aquellos en los cuales ciertos
componentes del depósito se distribuyen a través de un número de bases de
datos físicas diferentes.
Cada vez más, las organizaciones grandes están tomando decisiones a
niveles más inferiores de la organización y a la vez, llevando los datos que se
necesitan para la toma de decisiones a la red de área local (Local Area
Network - LAN) o computadora local que sirve al que toma decisiones.
Los data Warehouses distribuidos comúnmente involucran la mayoría de los
datos redundantes y como consecuencia de ello, se tienen procesos de
actualización y carga más complejos.
VII. Modelo de Planificación para un DataWarehouse
El proceso de planificación de un DW/DM debe considerar:

La diversidad de roles y responsabilidades de los usuarios

El rápido crecimiento de la población de usuarios, especialmente usuarios no
técnicos

El mejoramiento constante de las habilidades técnicas de los usuarios

La evolución de procesos de toma de decisión que son basados en
comunicaciones y colaboración extensiva
22
Modelo de planificación para un datawarehouse
Misión
Requerimientos
del negocio
Decisiones
Usuarios
Requerimientos de Información
Estrategia de
la base de
datos
Estrategia de
la base de
aplicación
Estrategia de
la base de
explotación
Planificación
Tecnológica
FIG.12
A. Requerimientos del Negocio
El diseño de un DW/DM debe ser consistente con la dirección estratégica de la
organización; por lo tanto el proceso de planificación debería empezar en el nivel
de alta gerencia con una definición completa de los requerimientos del negocio.
Contempla 3 capas:

Revisión de la misión corporativa, sus metas y objetivos

Identificando puntos de decisión y preguntas necesarias

Identificando a los usuarios
23
B. Misión

La especificación de la misión corporativa debe definir las metas de la
empresa en términos de negocios y haciéndolo así, también define un claro
propósito para invertir en Data Warehouse.

La especificación de la misión del negocio debe establecer metas
específicas para ayudar a alcanzar el crecimiento del negocio. Ejemplos de
metas

Llegar a ser un productor de bajo costo

Expandir geográficamente el mercado

Expandir el tamaño del mercado

Entrar en nuevos mercados

Construir mercados compartidos
Por ejemplo, la meta para expandir geográficamente debe traducirse hacia un
objetivo específico de incremento del beneficio desde las operaciones
internacionales en un 25 %. Mientras más claro y resumido sean establecidos la
misión, las metas y los objetivos del negocio, será mas fácil alinear el diseño del
Data Warehouse y de las aplicaciones con la misión de la organización.
C. Decisiones

Un enfoque útil para las necesidades de los usuarios es empezar definiendo
las decisiones que ellos deben realizar

Un Data Warehouse debe ser diseñado para soportar tres tipos de
decisiones

Operacional

Táctica

Estratégica
1. Decisiones Operativas
24
Son realizadas cada día, generalmente por los ejecutivos de primera línea.
Estas decisiones tienden a confiar en análisis repetitivo de nuevos datos y
generalmente requieren sistemas de reportes y análisis de datos que son
altamente orientados para un aspecto específico del negocio. Los tomadores
de decisiones operacionales desean información como contenido, ya
procesado, para la ayuda en la toma de decisión apropiada, mas que una
herramienta analítica que puede ser usada para generar contenido.
Un ejemplo de decisión operativa es la facultad que tiene el encargado o
gerente de un almacén de hacer nuevos pedidos de productos cuyo inventario
está a punto de agotarse ó a la inversa devolver aquellos productos que no
tienen el nivel de ventas esperado en lugar de esperar a que estos lleguen a
su fecha de caducidad.
2. Decisiones Tácticas
Requieren mayor flexibilidad que las decisiones operacionales en términos de
acceso a datos y las capacidades analíticas provistas a los usuarios.
Aunque aún muy centradas en entregar eficientemente contenido a los
usuarios, aplicaciones de soporte a la decisión táctica también proveen a los
usuarios con capacidades analíticas asociadas con el contenido.
Por ejemplo, una aplicación de soporte a la decisión táctica debe proveer al
usuario con un reporte que le permita desglosar en las dimensiones claves del
reporte o añadir elementos a la dimensión.
Una decisión táctica típica puede recaer en el hecho de poner productos en
oferta cuando su fecha de expiración se acerca ó cuando son productos
nuevos y se requiere de llamar la atención de los posibles clientes.
25
3. Decisiones Estratégicas
Requieren decisiones ad hoc de los datos contenidos en el Warehouse, así
como también recursos de datos que no son manejados como parte del
dataWarehouse. Soporte de decisiones estratégicas se centran en proveer a
los usuarios con herramientas potentes que pueden ser usadas para crear
contenidoEstas decisiones están orientadas a la gerencia alta de un negocio y
tienen que ver con la orientación o destino que se requiere dar al negocio,
algunos ejemplos de este tipo de decisión incluyen la apertura de nuevas
sucursales de un negocio, la aplicación de estudios de mercado para el
lanzamiento de nuevos productos, etc.
4. Usuarios
El siguiente paso en la planificación del dataWarehouse es identificar los
varios grupos de usuarios responsables de las decisiones operacionales,
tácticas y estratégicas.De la misma forma que hay una gran cantidad de
maneras para organizar un data Warehouse, es importante notar que también
hay una gama cada vez más amplia de usuarios finales.
Servicio a clientes
Ejecutivos
Producción
Ventas
Comercialización
Funciones
Analistas
Personal de
Apoyo
Usuarios
expertos
Usuarios
regulares
Usuarios
Ocasionales
Contabilidad y finanzas
Gerentes
Nivel de competencia de
usuarios
Jerarquía
26
Comúnmente hay 4 clases de usuarios finales del dataWarehouse:
FIG.13

Administradores (Power Users)

Autores (Analistas Financieros y de Negocios)

Usuarios activos (Usuarios de Soporte, de oficina, personal administrativo)

Usuarios casuales (Ejecutivos y Gerentes)
5. Administradores
Son los miembros del personal de soporte en Tecnología de Información
quienes ejecutan tanto tareas relacionadas con el negocio así como técnicas
tales como asegurar la calidad del contenido del dataWarehouse y de las
aplicaciones que lo accedan, manteniendo el meta dato para informar a los
otros usuarios acerca de los cambios en el dataWarehouse ó en las
aplicaciones.
6. Autores

Son quienes desarrollan las aplicaciones del negocio.

Los autores típicamente buscan las herramientas de análisis de datos
más potentes y de riqueza funcional ad hoc disponibles y a menudo tienen
las habilidades técnicas para usar estas herramientas óptimamente
7. Activos

Son menos hábiles técnicamente que los autores, generalmente gastan
mucho tiempo buscando información desde el dataWarehouse y
analizando las respuestas

Estos usuarios requieren rápidas y exactas respuestas a los aspectos del
negocio. Este grupo tiende a ser la clase de usuarios más impaciente
27
8. Casuales

El grupo menos técnico, son también los usuarios menos frecuentes del
dataWarehouse, pero el mas numeroso.

Este grupo generalmente incluye ejecutivos de nivel senior y ejecutivos de
primera línea, pero a menudo se extiende a todos los niveles de la
estructura administrativa de una organización, desde ejecutivos hasta el
campo de representantes de ventas

Debido a que los usuarios casuales, por definición, ingresan
infrecuentemente al sistema de dataWarehouse, simplicidad es un
requerimiento principal de diseño para este grupo. Ello necesitan
comandos y controles que son tanto fáciles a usar y fáciles a recordar
D. Decisiones clasificadas por clase de usuario, tipo y función de
negocio
El siguiente gráfico muestra la importancia de los usuarios y los tipos de
decisiones que ellos deben tomar
Estratégica
Técnica
Operacional
Administrador
Autor
Activo
Casual
Ventas
Marketing
Finanzas
Tipos de
Registro
Fabricación
Producción
Clases de
Usuarios
Funciones del
negocio
FIG.14
28
Requerimientos de Información
Hacen referencia a los requerimientos de Tecnología de Información que son
necesarios en los emprendimientos de DataWarehouse.
E. Planificación Tecnológica
1. Estrategia de la Base de Datos
Se trata de la creación de la base de datos. Entre otras cosas incluye

Contenido: Qué datos e información se requieren para solucionar las
preguntas y necesidades de los usuarios

Fuentes: Cuáles son los fuentes de la información y donde se encuentran
las fuentes.

Extracción: Cómo se extraen los datos y con que periodicidad se cargan
en el dataWarehouse.

Preparación: Qué se requiere para depurar y validar los datos fuentes

Diseño: Cuál es el diseño apropiado para la base de datos

Afinamiento: Qué aspectos de afinamiento y rendimiento se van a
considerar

Plataforma: Como será la plataforma en la que residirá el dataWarehouse,
como se compone la red, cuales son los componentes de hardware y
software.

Administración: Qué se requiere para administrar el dataWarehouse en
términos de seguridad, procesos de actualización, gestión de metadatos,
aseguramiento de la calidad, etc.
2. Estrategia de la Aplicación
La estrategia de aplicación trata con la tecnología en dos puntos: la capa de
lógica analítica y la capa de presentación. Identificando acceso a los datos y
análisis de requerimientos define el conjunto de requerimientos básicos del
usuario. Algunas preguntas de los usuarios pueden ser respondidas
simplemente recuperando los datos desde el Warehouse, pero muchas mas
29
preguntas requieren algún tipo de rutinas analíticas a ser ejecutadas sobre los
datos. Estas rutinas analíticas pueden ser clasificadas desde algo tal simple
como cálculo del porcentaje de cambio del volumen de ventas hasta la
creación de un modelo matemático complejo.
Se identifican las funciones de análisis de datos que se necesitan para
satisfacer las necesidades de los usuarios.

Acceso; Identificar que usuarios van a tener acceso a la información y
también que nivel de información podrá ver cada uno de ellos.

Análisis: Qué funciones de análisis de información serán necesarias para
satisfacer los requerimientos.

Modelamiento; Requerimientos para análisis estadísticos de datos,
minería de datos, u otro soporte de modelamiento matemático

Aplicaciones; Necesidades para aplicaciones específicas del negocio

Procesos: Cómo ayuda el dataWarehouse a los procesos de negocio,
Qué
mejoras
en
los
procesos
de
negocio
se
logran
con
el
dataWarehouse.

Soporte: Cómo los usuarios recibirán soporte y capacitación en el
dataWarehouse.
3. Estrategia de la Explotación
En la estrategia de explotación se consideran los siguientes aspectos

Interfaz: Cuales usuarios usarán aplicaciones cliente servidor y cuales
accederán a través de clientes web (browser)

Colaboración; Como se promoverá la colaboración entre los usuarios.

Agentes: Cómo se automatizarán los procesos de análisis y reportes.

Motor de búsqueda; Cómo los recursos del dataWarehouse serán
registrados en motores de búsqueda.
30

Seguridad: Cómo será garantizada la seguridad de la información y de la
base de datos.
VIII. Arquitectura del DataWarehouse
El siguiente gráfico muestra la arquitectura clásica de un DataWarehouse,
compuesto por:


Fuentes de Datos
Motor del DataWarehouse
o
o
o
o
o
o

Gestor de Carga
Metadatos
Agregaciones
Gestor del DataWarehouse
Gestor de Respaldos
DW Repositorio
Herramientas de Acceso
31
FIG.15
32
En forma resumida la arquitectura puede verse expresada en la siguiente figura:
DATA WAREHOUSE
ERP
DATAMART
COMERCIAL
OLTP
DATAMART
FINANZAS
DATAMART
RRHH
LEGACY
DATAMART
SERVICIO CLIENTE
USUARIOS
METADATA
INFORMACIÓN
EXTERNA
FIG.16
Fuentes de Datos
Cualquier origen de información que pueda ser considerado para el
dataWarehouse, aquí se incluye los siguientes elementos:

Los sistemas OLTP`s que son los sistemas de Legacy que actualmente
operan en la empresa.

Datos antiguos provenientes de migraciones.

Fuentes externas como otros sistemas de la compañía, sistemas de otras
empresas, sistemas de gobierno, internet, etc.

Datos de oficina, archivos en formato de Word, Excel, archivos planos,
PDF’s, mails, etc.
A. El motor del dataWarehouse
Está integrado por los siguientes componentes
33
1. Gestor de Carga
Quizá sea uno de los elementos más importantes para el dataWarehouse,
generalmente incluye las operaciones de

Extracción: Es el proceso que accesa a los datos OLTP existentes, en
cualquier forma que exista, desde cualquier DBMS en que exista.
Típicamente,
extracción
y
el
siguiente
paso,
propagación,
son
administrados por el mismo producto. No todas las herramientas de
extracción y propagación soportan todas las plataformas, de tal manera
que una faceta importante de la selección de herramientas es si la
herramienta soporta los sistemas operativos y las bases de datos que se
esté usando para el dataWarehouse.

Propagación: Es el proceso de mover datos desde los sistemas fuente
hacia el sistema objetivo que contendrá el data Warehouse. El proceso de
propagación toma lugar en tiempo real, o en un calendario predeterminado
(batch), o sobre demanda, y puede efectuar un refresco total del
Warehouse o justo un cambio neto. Cuando se selecciona una herramienta
de propagación, se aspira que ésta ofrezca la gestión de cambios netos
como también refresco total y permitirá tanto actualizaciones en tiempo real
y calendarizadas (batch).

Depuración (Limpieza): El nivel lógico cubre problemas de valores de
datos que son inconsistentes dentro de la información importada (ejemplo,
clientes con estado casado, pero con una edad de 3 años). El nivel técnico
evalúa problemas de información tales como campos no inicializados o
valores inválidos en los datos importados (ejemplo, valor de la fecha
Febrero 31).

Transformación: Convierte datos desde su formato OLTP al apropiado
formato
del
dataWarehouse
ejecutando
funciones
tales
como
desnormalización de datos, traduciendo códigos hacia texto significativo,
34
convirtiendo una variedad de formatos de fechas hacia un formato
estándar, convirtiendo texto tal como nombres de ciudades hacia texto
estándar y renombrando campos desde nombres técnicos no significativos
hacia nombres significativos que un usuario final entenderá.

Carga: Los datos fuentes normalmente son extraídos y almacenados en
archivos temporales tipo texto, los mismos que deben ser cargados a la
base de datos del data Warehouse. La figura resume el proceso de carga,
los archivos temporales finalmente son colocados en la base de data
Warehouse de destino.
DATOS
.TXT
TEMPORALES
DATA
WAREHOUSE
FIG.17
El módulo de Gestor de Carga también es conocido como Integrador, y es muy
importante tanto en la Fase de Construcción como en la Fase de Explotación de
un Data Warehouse.
35
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.
FIG.18
No importa cómo esté diseñado un programa o cuán hábilmente se use. Si se
alimenta mala información, se obtendrá resultados incorrectos o falsos.
Desafortunadamente, los datos que se usan satisfactoriamente en las
aplicaciones de línea comercial operacionales pueden ser basura en lo que
concierne a la aplicación data warehousing.
Los datos "sucios" pueden presentarse al ingresar información en una entrada
de datos (por ejemplo, "Sistemas S. A." en lugar de "Sistemas S. A.") o de otras
causas. Cualquiera que sea, la data sucia daña la credibilidad de la
implementación del depósito completo. A continuación, en la Figura se muestra
un ejemplo de formato de ventas en el que se pueden presentar errores.
36
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, imprecisos e inconsistentes, el uso de las
herramientas comerciales puede ser casi obligatorio.
Decidir qué herramienta usar es importante y no solamente para la integridad de
los datos. Si se equivoca, se podría malgastar semanas en recursos de
programación o cientos de miles de dólares en costos de herramientas.
La limpieza de una data "sucia" es un proceso multifacético y complejo. Los
pasos a seguir son los siguientes:
1. Analizar sus datos corporativos para descubrir inexactitudes, anomalías 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 aplicación del Data Warehouse
37
FIG.19
2. Meta Datos
Esta área del Warehouse almacena todas las definiciones de los meta datos
(datos acerca de los datos) usados por todos los procesos en el Warehouse.
Los meta datos son usados para una variedad de propósitos incluyendo:
38

Los procesos de extracción, transformación y carga (meta datos es
usado para mapear las fuentes de datos a una vista común de la
información dentro del Warehouse).

Los procesos de gestión del Warehouse (cada tabla es descrita
incluyendo su estructura, índices, vistas; meta datos es usado también
para automatizar la producción de tablas resumen).

Como parte de los procesos de gestión de consulta (meta datos es
usado para dirigir una consulta a la fuente de datos más apropiada)
3. Agregaciones
Este componente del Warehouse almacena todos los datos agregados,
predefinidos y generados por el gestor del Warehouse.
El propósito de información resumida es para mejorar el rendimiento de las
consultas. Aunque hay costos operacionales incrementados asociados con la
agregación inicial de los datos, esto debería ser compensado eliminando el
requerimiento para ejecutar continuamente operaciones de agregación (tales
como clasificación o agrupación) en las respuestas a las consultas de los
usuarios. El dato agregado es actualizado continuamente en la medida que
nuevos datos son cargados en al Warehouse.
4. Gestor del DataWarehouse
En algunos casos el gestor del Warehouse también genera perfiles de
consultas para determinar qué índices y agregaciones son apropiadas. Un
perfil de consulta puede ser generado para cada usuario, grupo de usuario, o
el Data Warehouse y está basada en la información que describe las
características de las consultas tales como la frecuencia, tablas objetivo, y
tamaño de los results set.
39
5. Gestor de Respaldos
Es el componente que se encarga de respaldar constantemente la
información del repositorio del Data Warehouse.
6. Repositorio del Data Warehouse
Es el repositorio en si o la base de datos física donde se almacena la
información del Data Warehouse.
B. Requisitos para que un DBMS trabaje con un Data Warehouse
1. Rendimiento de carga
Data Warehouse requiere de carga incremental de nuevos datos en una base
periódica dentro de ventanas de tiempo pequeñas
El rendimiento de procesos de carga debería ser medido en cientos de
millones de filas o gigabytes de datos por hora y no debería haber un límite
máximo que restringa al negocio
2. Procesamiento de carga
Muchos pasos deben ser dados para cargar un dato nuevo o actualizado
hacia el Data Warehouse incluyendo conversión de datos, filtrado,
reformateado, chequeos de integridad, almacenamiento físico, indexación y
actualización de los meta datos
Aunque cada paso en la práctica puede ser atómico, el proceso de carga
debería parecer que se ejecuta como una unidad de trabajo única.
3. Gestión de calidad de los datos
El Data Warehouse debe asegurar consistencia local, consistencia global e
integridad referencial a pesar de las fuentes "sucias" y tamaños masivos de
bases de datos
40
la preparación y carga son pasos necesarios, ellos no son suficientes. La
habilidad para responder a las consultas de los usuarios finales es la medida
del éxito para una aplicación de Data Warehouse.
Mientras más preguntas son respondidas, los analistas tienden a solicitar
preguntas más complejas y creativas
4. Rendimiento de consultas
Gestión basada en hechos y análisis ad hoc no deben ser retardadas o
inhibidas por el rendimiento del RDBMS Data Warehouse.
Consultas complejas y grandes para operaciones claves del negocio deben
ser completadas en un período de tiempo razonable.
5. Escalabilidad de terabytes
El tamaño de Data Warehouse está creciendo a enormes tasas con tamaños
en el rango de cientos de gigabytes hasta los terabytes y petabytes (1015).
Los RDBMS no deben tener ninguna limitación arquitectural para el tamaño
de la base de datos y deberían soportar gestión modular y paralela. En el
evento de fallas, el RDBMS debería soportar disponibilidad continua, y
proveer
mecanismos
para
recuperación.
El
RDBMS
debe
soportar
dispositivos de almacenamiento en masa tales como discos ópticos y
dispositivos de gestión de almacenamiento jerárquico.
Finalmente, rendimiento de consultas no debería ser dependiente del tamaño
de la base de datos, sino más bien de la complejidad de la consulta.
6. Escalabilidad de usuarios en masa
El pensamiento actual es que el acceso a un Data Warehouse es limitado a
un número de usuarios gerenciales relativamente bajo.
41
Se predice que en el futuro, el Data Warehouse RDBMS debería ser capaz de
soportar cientos, o aún miles de usuarios concurrentes mientras se mantiene
un aceptable rendimiento en las consultas
7. Trabajo en red
Sistemas de Data Warehouse deberían ser capaces de cooperación en un
gran red de Data Warehouse
El Data Warehouse debe incluir herramientas que coordinen el movimiento de
subsets de datos entre Data Warehouse
Los usuarios deberían ser capaces de mirar en y trabajar con múltiples Data
Warehouses desde una estación de cliente única
8. Facilidad de administración
La muy grande escala y naturaleza cíclica en el tiempo del Data Warehouse
demanda facilidad y flexibilidad administrativa
El RDBMS
debe proveer control
para
límites
de
recursos
en la
implementación
9. Análisis dimensional integrado
La potencia de vistas multidimensionales es ampliamente aceptada y soporte
dimensional debe ser inherente en el RDBMS Warehouse para proveer el
más alto rendimiento para herramientas OLAP relacional.
El RDBMS debe soportar creación rápida y fácil de resúmenes comunes
precalculados en grandes Data Warehouses, y proveer herramientas de
mantenimiento
para
automatizar
la
creación
de
estos
agregados
precalculados
10. Funcionalidad de consulta avanzada
Usuarios finales requieren cálculos analíticos avanzados, análisis secuencial y
comparativo, y accesos consistentes a datos detallados y resumidos.
42
Usando SQL en un ambiente cliente servidor y herramientas apunte y dispare
puede algunas veces ser no práctico o aún imposible debido a la complejidad
de las consultas de los usuarios.
El RDBMS debe proveer un completo y avanzado set de operaciones
analíticas.
C. Herramientas de Acceso ó Herramientas de Usuario Final
Estas herramientas pueden reunirse en 4 grupos




Herramientas de Reportes y Consultas
Herramientas de Desarrollo de Aplicaciones
Herramientas de Procesamiento Analítico en Línea (OLAP)
Herramientas de Minería de Datos
FIG.20
43
1. Herramientas de Reportes y Consultas
Simplifican la generación de código SQL. Los usuarios formulan consultas a la
base de datos sin tener que interactuar con el lenguaje de programación de
bases de datos SQL).
2. Herramientas de desarrollo de aplicaciones
Los requerimientos de usuarios finales pueden ser tales que las capacidades
pre-construidas de las herramientas de reportes y consultas son inadecuadas
ya sea debido a que el análisis requerido no puede ser ejecutado o debido a
que la interacción del usuario requiere un no razonable alto nivel de expertise
por parte del usuario
En esta situación el acceso de usuarios puede requerir el desarrollo de
aplicaciones usando ambientes gráficos de accedo de datos desarrollados
principalmente para ambientes cliente/ servidor.
Algunas de estas plataformas de desarrollo de aplicaciones se integran con
herramientas OLAP populares, y pueden accesar todos los sistemas de bases
de datos principales, incluyendo Oracle, SQL Server, Sybase, e Informix.
Ejemplos de estos ambientes de desarrollo de aplicaciones incluyen
PowerBuilder de PowerSoft, VisualBasic de Microsoft, y Bussines Objects.
3. Herramientas de Procesamiento Analítico en Línea (OLAP)
Típicas aplicaciones de negocios para estas herramientas incluyen evaluación
de la efectividad de una campaña de marketing, previsión de ventas de
productos, y planificación de la capacidad. Estas herramientas asumen que
los datos están organizados en un modelo multidimensional, el cual es
soportado por una base de datos multidimensional especial (MDDBMS) o por
44
una
base
de
datos
relacional
diseñada
para
permitir
consultas
multidimensionales.
Este tipo de herramientas permiten a los usuarios ingresar a un Data
Warehouse desde cualquier dimensión simple para empezar el análisis, luego
navegar a otra dimensión para un mayor análisis de la información.

OLAP es online analytical processing. Se trata de una forma de
almacenar la información en una Base de Datos que permita realizar de
forma más efectiva las queries. Es una definición abreviada, claro está, la
realidad es más compleja.

MOLAP, Multidimensional OLAP. Tanto los datos fuente como los datos
agregados o precalculados residen en el mismo formato multidimensional.
Optimiza las queries, pero requiere más espacio de disco y diferente
software. El primer punto está dejando ser un problema: el espacio de
disco cada vez es más barato.

ROLAP, Relational OLAP. Tanto los datos precalculados y agregados
como los datos fuente residen en la misma base de datos relacional. Si el
Data Warehouse es muy grande o se necesita rapidez por parte de los
usuarios puede ser un problema.

HOLAP, Hybrid OLAP: Es una combinación de los dos anteriores. Los
datos agregados y precalculados se almacenan en estructuras
multidimensionales y los de menor nivel de detalle en el relacional.
Requiere un buen trabajo de análisis para identificar cada tipo de dato.
Los datos se almacenan en una estructura de cubo (es como si estuviera
totalmente indexado) y la velocidad de acceso se hace mucho más eficiente.
45
En este caso, la primera consulta nos muestra los puntos que han acumulado los
titulares de la tarjeta clásica, en todos los tipos de cabinas y en todos los meses.
Mientras, que en la segunda filtramos el cubo para los que volaron en turista.
Este tipo de consultas devuelve los datos de forma instantánea.
4. Herramientas de Mineo de Datos
Mineo de datos es el proceso de descubrir nuevas correlaciones significativas,
patrones y tendencias por medio del mineo de grandes cantidades de datos
almacenados en un Data Warehouse o en un data Mart, usando técnicas
estadísticas, reconocimiento de patrones y algoritmos de aprendizaje para
identificar relaciones entre los elementos de datos.
Ejemplo de un Data Warehouse
En la Figura se muestra un ejemplo hipotético de un data Warehouse
estructurado para un centro de producción industrial.
Se muestra sólo el detalle actual, no así los niveles de esquematización ni los
archivos de detalle más antiguos.
Además, se observa que hay tablas del mismo tipo divididas a través del
tiempo. Por ejemplo, para el histórico de la fabricación de las piezas, hay
muchas tablas separadas físicamente, representando cada una un trimestre
diferente. La estructura de los datos es consistente con la tabla de la
elaboración de las piezas, aunque físicamente hay muchas tablas que
lógicamente incluyen el histórico.
Para los diferentes tipos de tablas hay diferentes unidades de tiempo que
físicamente dividen las unidades de información. El histórico de fabricación
está dividido por trimestres, el histórico de la orden de piezas está dividido por
años y el histórico de cliente es un archivo único, no dividido por el tiempo.
46
Así también, las diferentes tablas son vinculadas por medio de un identificador
común, piezas u órdenes de piezas (la representación de la interrelación en el
ambiente de depósito toma una forma muy diferente al de otros ambientes, tal
como el ambiente operacional).
FIG.21
47
IX. Explotación del Data Warehouse
A. Potencial del Data Warehouse
El
Data
Warehouse
no
produce
resultados
en
forma
mágica.
Los
administradores de empresas y los analistas deben acceder y recuperar los
datos del Data Warehouse y convertirlos en información y en hechos. Estos
hechos conforman los cimientos de una base de conocimientos que sirve para
determinar la salud de la empresa y la dirección futura del negocio. Como en las
granjas, los usuarios sólo cosecharán la información que se pueda derivar de los
datos que sembraron en el Data Warehouse, y sólo mediante el uso de las
herramientas de cosecha adecuadas. Algunas de las herramientas de cosecha
necesarias son: las de acceso y recuperación, las de reportes de base de datos,
las de análisis y las de data mining.
Uno de los retos al cosechar un Data Warehouse consiste en no convertir
montículos de información en montañas de datos. Es fácil caer en la trampa de
"entre más, mejor". No es esencial conocer todos los hechos, sólo los cruciales.
Como ejemplo, una campaña de ropa para niños necesita cosechar exacta y
rentablemente sólo aquellas familias que tienen niños.
B. Extracción y manipulación de datos del Data Warehouse
Herramientas de soporte de decisiones es el término genérico para referirse a
las aplicaciones y herramientas del Data Warehouse que se emplean para
recuperar, manipular y analizar los datos, y para presentar después los
resultados. Estas herramientas se usan en dos modalidades: verificación y
descubrimiento. En la modalidad de verificación, el usuario empresarial crea una
hipótesis -una cuestión empresarial- e intenta confirmarla accediendo a los datos
en el Data Warehouse. Las herramientas que implementan la modalidad de
verificación
son de consulta,
de
sistemas de
reporte
y de
análisis
multidimensional. En la modalidad de descubrimiento, las herramientas intentan
48
descubrir características en los datos como patrones de compra o la asociación
entre la adquisición de artículos diferentes. En la modalidad de descubrimiento, o
eureka, el usuario empresarial no conoce ni sospecha los patrones y
asociaciones descubiertos. La herramienta de Data Mining es un ejemplo de la
modalidad de descubrimiento.
FIG.22
Desde la perspectiva de disponibilidad de herramientas, las dos modalidades de
verificación y descubrimiento se clasifican en tres enfoques: Procesamiento
Informático, Procesamiento Analítico y Data Mining.
C. Procesamiento Informático
La recuperación de la inversión en un Data Warehouse se basa en la capacidad
de los usuarios empresariales para extraer los datos correctos del Data
Warehouse, convertirlos en información y luego utilizar esa información para
tomar mejores decisiones. Los usuarios empresariales pretenden extraer los
datos correctos con una mínima inversión en tiempo y sin complicaciones.
49
A los ejecutivos y gerentes de alto nivel les interesa ver los resultados de una
actividad de procesamiento informático en forma de reportes, cuadros y gráficas.
Los gerentes desean acceder a consultas estándar de rutina. Un ambiente de
'consulta administrativa' cubre la mayoría de sus necesidades. El procesamiento
informático apoya a la modalidad de verificación del soporte de decisiones.
Comprende técnicas como análisis estadísticos básicos y de datos, consultas y
reportes. Los datos que se acceden y procesan pudieran ser históricos o
bastante recientes, y pudieran estar un poco o muy resumidos. Los resultados se
presentan en forma de reportes o gráficas.
El procesamiento informático asiste a los usuarios empresariales en la búsqueda
de respuestas a cuestiones empresariales, como las siguientes:

¿Cuáles fueron los ingresos por ventas en el fin de semana del Día de
Acción de Gracias (nuestro mejor fin de semana de ventas) para todas las
tiendas del medio oeste, con corte por departamento?

¿Cuáles fueron los diez artículos más rentables durante la venta posterior
a la Navidad? ¿Cuáles fueron los diez menos rentables?

¿Cómo se comparan las ventas del Día de Acción de Gracias con las del
mismo fin de semana, en los últimos cinco años, por departamento y
tienda?
D. Procesamiento Analítico
También el procesamiento analítico apoya a la modalidad de verificación del
soporte de decisiones. Su meta consiste en hacer que los datos estén
disponibles para el usuario de la empresa en su perspectiva de las dimensiones
empresariales. Se pueden responder e interpretar preguntas complejas como
"¿Cuántos automóviles vendimos en Estados Unidos en el primer trimestre de
1995 que tuvieran un sistema de audio CD, con un precio de 25,000 dólares o
menos?'. Este procesamiento maneja capacidades de análisis de subconjuntos
(slice and dice), profundización (drill-down) y condensación y adición (roll-up).
Los datos que se emplean en el procesamiento analítico son, por Io general,
históricos tanto a nivel de resumen como al de detalle.
50
Los gerentes y analistas empresariales requieren la funcionalidad del
procesamiento analítico cuando deben responder preguntas complejas corno las
siguientes:

¿Cuántos esquíes de nieve, fabricados por SpeedSkiDown, Inc., se
vendieron a hombres en el mes de noviembre, en nuestras tiendas de las
regiones del medio oeste, del noroeste y de la Montaña?

¿Cómo se compara Io programando con Io real del mismo mes en los dos
últimos años?

¿Cuántas minivans azules teníamos en inventario (al fin del trimestre) con
un reproductor de discos compactos y un tercer asiento, cuando la lista de
precios era menor de $19,995? Se requieren totales por condado para
cada trimestre de los últimos cinco años, comparar Io real contra Io
planeado, y comparar el inventario de cada trimestre con el del anterior y
el del siguiente?
Los gerentes ejecutivos saben que "el futuro pertenece a quienes pueden verlo y
llegar ahí primero". Por tal razón, los ejecutivos y gerentes empresariales no sólo
comprenden "lo que pasa en el negocio", sino también "que va a suceder". El
procesamiento analítico se utiliza tanto para análisis históricos complejos, con
una extensa manipulación, como para la planeación a futuro y pronóstico -el
pasado como prólogo del futuro.
Los datos empresariales son, de hecho, multidimensionales. Se encuentran
relacionados y regularmente son jerárquicos; por ejemplo, los datos de ventas,
los
datos
del
inventario
y
los
pronósticos
de
presupuestos
están
interrelacionados y dependen entre si. En la práctica, para predecir las ventas de
un nuevo producto específico, se requiere analizar los patrones de compras
anteriores, la adopción de nuevos productos, las preferencias regionales y otros
factores empresariales similares. La proyección de ventas para nuestra cuestión
de los "esquíes de SpeedSkiDown, Inc.", requiere comprender los patrones de
ventas de los últimos años.
51
E. Data Mining
El Data Mining apoya la modalidad de descubrimiento del soporte de decisiones.
Las herramientas de Data Mining recorren los datos detallados de transacciones
para desenterrar patrones y asociaciones ocultos. Por lo regular los resultados
generan extensos reportes o se les analiza con herramientas de visualización de
datos descubiertos.
El procesamiento informático es excelente y rentable para el despliegue masivo
de consultas, análisis y reportes de datos de dos o tres dimensiones. Las
herramientas de procesamiento analítico permiten diversas visualizaciones de
los datos, como ventas por marca, tienda, temporada y periodos de tiempo, las
cuales se pueden definir, consultar y analizar. Las herramientas de Data Mining
son esenciales para comprender el comportamiento de los clientes.
Usuarios
del Data
Mining
Los usuarios clave en perspectiva del Data Mining son los analistas
empresariales, los peritos en estadística y los profesionales en
tecnología
de
la
información
que
auxilian
a
los
usuarios
empresariales. Quienes obtienen beneficios de los resultados del
Data Mining son los gerentes empresariales y los ejecutivos, que
desean entender los factores de éxito del negocio con base en
datos completos del cliente y, utilizar luego, este conocimiento para
afinar las estrategias de producción, precios y comercialización;
mejorar el nivel de éxito de las estrategias; e impulsar el balance.
Hasta la fecha, las empresas han dependido del procesamiento
informático y analítico para medir y comprender la estabilidad de un
negocio. El procesamiento informático -consultas y reportes- es más
sencillo de usar, pero requiere de una estrecha dirección del
analista (ver figura). Los analistas preguntan cuestiones específicas
y verifican las cuestiones o hipótesis con los datos. Para este fin, los
datos deben estar bien organizados. El procesamiento analítico
(OLAP) requiere de menos dirección del analista, aunque los datos
deben estar organizados en una forma especial (base de datos
52
multidimensional), o accederse bien de manera especial (visión
multidimensional). En ocasiones se utiliza una combinación de
técnicas de consulta y OLAP para comprender el comportamiento
del cliente o para construir perfiles de segmentos de mercado; pero
el proceso de aplicar estas técnicas es conducido esencialmente
por el analista empresarial. En estos casos, este proceso también
se conoce como Data Mining y se define como la modalidad de
descubrimiento del soporte de decisiones, la cual es conducida por
los datos y no por el analista empresarial.
FIG.23
X. Glosario de Términos asociados con Data Warehouse
Agregación
Actividad de combinar datos desde múltiples tablas para formar una unidad de
información más compleja, necesitada frecuentemente para responder consultas
del Data Warehouse en forma más rápida y fácil.
Data Mart (DM).
Es un conjunto de datos que son estructurados de una forma que facilite su
posterior análisis. Un Data Mart contiene información referente a un área en
particular, con datos relevantes que provienen de las diferentes aplicaciones
operacionales. Los Data Mart pueden ser de diversas bases de datos relacionales
o de diversas bases de datos OLAP dependiendo del tipo de análisis que se quiera
desarrollar.
53
Data mining de pronóstico.
Es un data mining que produce un modelo para ser usado con nuevos datos para
pronosticar un valor o predecir un probable resultado basado en patrones en la
data histórica.
Data mining descriptivo.
Es un tipo de data mining (minería de datos) que produce un modelo para describir
patrones de los datos históricos y requiere interacción humana para determinar la
significación y el significado de estos patrones.
Datos no depurados.
Datos que son ambiguos o que carecen de validez por ser inexistentes, ausentes,
incorrectos o duplicados.
Data Warehouse (DW)
Es un almacén o repositorio para los datos. Muchos expertos definen el Data
Warehouse como un almacén de datos centralizados que introduce datos en un
almacén de datos específico llamado data mart. Otros aceptan una amplia
definición de Data Warehouse, como un conjunto integrado de marts.
Descendiente.
Algún miembro de algún nivel inferior en relación a otro miembro específico.
Desktop online analytical processing (DOLAP).
Es un tipo de almacenamiento OLAP que mantiene los datos en una máquina
cliente y suministra análisis multidimensional de forma local.
Dimensión.
Es una vista de datos categóricamente consistente. Todos los miembros de una
dimensión pertenecen a un mismo grupo. Entidad independiente dentro del modelo
multidimensional de una organización, que sirve como llave de búsqueda (actuando
como índice), o como mecanismo de selección de datos.
54
Drill Down :
Exponer progresivamente más detalle (dentro de un reporte o consulta), mediante
selecciones de ítems sucesivamente.
Drill-Up : Es el efecto contrario a drill -down. Significa ver menos nivel de detalle,
sobre la jerarquía significa generalizar o sumarizar, es decir, subir en el árbol
jerárquico.
DSS :
Sistema de Soporte de Decisiones. Sistema de aplicaciones automatizadas que
asiste a la organización en la toma de decisiones mediante un análisis estratégico
de la información histórica.
ETT (Extracción, Transformación y Transporte de datos) :
Pasos por los que atraviesan los datos para ir desde el sistema OLTP ( o la fuente
de datos utilizada) a la bodega dimensional.

Extracción, se refiere al mecanismo por medio del cual los datos son leídos
desde su fuente original.

Transformación (también conocida como limpieza) es la etapa por la que puede
atravesar una base de datos para estandarizar los datos de las distintas fuentes,
normalizando y fijando una estructura para los datos.

Transporte,
que
consiste
básicamente
en
llevar
los
datos
leídos
y
estandarizados a la bodega dimensional (puede ser remota o localmente).
Generalmente, para un Data Mart no es necesario atravesar por todos estos pasos,
pues al ser información localizada, sus datos suelen estar naturalmente
estandarizados (hay una sola fuente).
Granularidad:

Indica el grado de detalle asociado a un hecho particular.
55

El primer gran factor decisivo de la granularidad es el tiempo, ya que mientras
menor sea el intervalo de tiempo, mayor será el grado de detalle obtenido.

La granularidad depende directamente del número de dimensiones que se
asocian a la tabla de hechos.

Se deben considerar otros factores como la carga del procesador, espacio de
almacenamiento y satisfacer a cabalidad los requerimientos del cliente.
Hechos (Medidas):
Son medidas numéricas, las cuales describen los resultados (rendimiento) del
negocio.
Un hecho debe ser un valor cuantificable ó medible. Por ejemplo el número de
unidades vendidas, ingreso por ventas, etc.
Jerarquía:
Es un conjunto de atributos descriptivos que permite que a medida que se tenga
una relación de muchos a uno se ascienda en la jerarquía. Por ejemplo : los
Centros de Responsabilidad están asociados a un Tipo de Unidad, el cual pueden
corresponder a una gerencia, subgerencia, superintendencia, etc.; por otro parte,
cada CR está asociado a otro CR a nivel administrativo y, también existe una
clasificación a nivel funcional.
Olap (On-line Analytical Processing):
Conjunto de principios que proveen una ambiente de trabajo dimensional para
soporte decisional.
Oltp (On-line Transaction Processing) :
Sistema transaccional diario (o en detalle) que mantiene los datos operacionales
del negocio.
Rollup:
56
Comando propio del lenguaje Oracle Express, que simboliza las sumas agregadas
de una variable a través de los niveles jerárquicos de las dimensiones que la
sustentan.
Snapshot:
Imagen instantánea de los datos en un tiempo dado.
Sumarización:
Actividad de incremento de la granularidad de la información en una base de datos.
La
sumarización reduce el nivel de detalle, y es muy útil para presentar los datos para
apoyar al proceso de Toma de Decisiones.
Tabla Dimensional:
Dentro del esquema estrella, corresponde a las tablas que están unidas a la tabla
central a través de sus respectivas llaves. La cantidad de estas tablas le otorgan la
característica de multidimensionalidad a esta estrategia.
XI. Bibliografía
BF System Definición de Data Warehouse
Modelamiento Dimensional, Carmen Gloria Wolf
IBM DB2 OLAP Server, Maria Ibarra, Documentación Técnica.
Data Warehousing Fácil, Programación en Castellano, Claudio Casares.
Todo BI, Características de Pentaho OPEN SOURCE
Manual para la Construcción de un Data Warehouse, Business Intelligence,
Transformando la Información en Decisiones, Octavio Licea
7. Data Warehouse, Monografías.com, Damián Gutíerrez
8. Apuntes de Data Warehouse, Presentaciones Ing, Victor Aguilar, Escuela
Politécnica Nacional Ecuador
9. Diseño y Optimización de Bases de Datos y Data Warehouse, Universidad
Politécnica de Madrid, Dr. Eusebio Santos
1.
2.
3.
4.
5.
6.