Difererencia entre OLTP y Datawarehouse

Los
sistemas tradicionales de transacciones y las aplicaciones de Data
Warehousing son polos opuestos en cuanto a sus requerimientos de
diseño y sus características de operación. Es de
suma importancia comprender perfectamente estas diferencias para
evitar caer en el diseño de un Data Warehouse como si fuera
una aplicación de transacciones en línea (OLTP).

Las
aplicaciones de OLTP están organizadas para ejecutar las
transacciones para los cuales fueron hechos, como por ejemplo: mover
dinero entre cuentas, un cargo o abono, una devolución de
inventario, etc. Por otro lado, un Data Warehouse está
organizado en base a conceptos, como por ejemplo: clientes, facturas,
productos, etc.

Otra
diferencia radica en el número de usuarios. Normalmente, el
número de usuarios de un Data Warehouse es menor al de un
OLTP. Es común encontrar que los sistemas transaccionales son
accesados por cientos de usuarios simultáneamente, mientras
que los Data Warehouse sólo por decenas. Los sistemas de OLTP
realizan cientos de transacciones por segundo mientras que una sola
consulta de un Data Warehouse puede tomar minutos. Otro factor es que
frecuentemente los sistemas transaccionales son menores en tamaño
a los Data Warehouses, esto es debido a que un Data Warehouse puede
estar formado por información de varios OLTP´s.

Existen
también diferencia en el diseño, mientras que el de un
OLPT es extremadamente normalizado, el de un Data Warehouse tiende a
ser desnormalizado. El OLTP normalmente está formado por un
número mayor de tablas, cada una con pocas columnas, mientras
que en un Data Warehouse el número de tablas es menor, pero
cada una de éstas tiende a ser mayor en número de
columnas.

Los
OLTP son continuamente actualizados por los sistemas operacionales
del día con día, mientras que los Data Warehouse son
actualizados en batch de manera periódica.

Las
estructuras de los OLTP son muy estables, rara vez cambian, mientras
las de los Data Warehouses sufren cambios constantes derivados de su
evolución. Esto se debe a que los tipos de consultas a los
cuales están sujetos son muy variados y es imposible preverlos
todos de antemano

OLPT

Data Warehouse

– Orientada a transacciones – Detallada – Actualizada en línea – Usuarios de nivel operativo – Corre en base a repeticiones – Muy sensitivo al desempeño – Accesa unidades a la vez – Orientado a operación – Estructura estática – Sin redundancia – Alta probabilidad de acceso – Administrada como un todo – Información bruta (Datos) – Actualizada en línea – Muchas tablas con pocas columnas

– Orientada a Conceptos – Sumarizada – Representa valores a un tiempo (snapshot) – Usuarios de nivel gerencial – Corre heurísticamente – Poco sensitivo al desempeño – Accesa conjuntos de unidades a la vez – Orientado a análisis – Estructura flexible – Con mucha redundancia – Modesta probabilidad de acceso – Administrada por partes – Información procesada (Información) – Actualizada en Batch – Pocas tablas con muchas columnas

La
siguiente es una comparación entre un Datawarehouse y los
Sistemas Transaccionales tradicionales.

Sistema Transaccional No datos sumarizados No drill down No datos históricos Aplicaciones no integradas

Datawarehouse Muchos datos sumarizados Estructurado para análisis con drill down Datos históricos para análisis de tendencias Información integrada para análisis corporativos

A
continuación un modelo expresado en su forma transaccional y
también modelado como Data Mart.

Ciclo de Desarrollo

El
Data Warehouse sigue el mismo ciclo de perfeccionamiento que todos
los desarrollos de software.

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:

• 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 comercialización comprende la capacidad
  de hacer énfasis en la disponibilidad, los beneficios y el
  empaque para hacerla atractiva al usuario final.

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.

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.

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.

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.

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.

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.

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.

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

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

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 datawarehouse.

• 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 datawarehouse y de las aplicaciones con la misión de la
organización.

Decisiones

• Un
  enfoque útil para las necesidades de los usuarios es empezar
  definiendo las decisiones que ellos deben realizar

• Un
  datawarehouse debe ser diseñado para soportar tres tipos de
  decisiones

• Operacional
  

• Táctica

• Estratégica

Decisiones Operativas

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.

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.

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 contenido

Estas
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.

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.

Comúnmente
hay 4 clases de usuarios finales del datawarehouse:

• Administradores
  (Power Users)

• Autores
  (Analistas Financieros y de Negocios)

• Usuarios
  activos (Usuarios de Soporte, de oficina, personal administrativo)

• Usuarios
  casuales (Ejecutivos y Gerentes)

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.

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

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

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

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

Requerimientos de Información

Hacen
referencia a los requerimientos de Tecnología de Información
que son necesarios en los emprendimientos de Datawarehouse.

Planificación Tecnológica

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.

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
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.

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.

• Seguridad:
  Cómo será garantizada la seguridad de la información
  y de la base de datos.

Arquitectura del Datawarehouse

El
siguiente gráfico muestra la arquitectura clásica de un
Datawarehouse, compuesto por:

• Fuentes
  de Datos

• Motor
  del Datawarehouse

• Gestor
  de Carga

• Metadatos

• Agregaciones

• Gestor
  del Datawarehouse

• Gestor
  de Respaldos

• DW
  Repositorio

• DataMart

• BDD
  Dimensional

• Gestor
  del DataMart

• Herramientas
  de Acceso

En forma resumida la arquitectura puede verse expresada en la
siguiente figura²:

Fuentes de Datos

Cualquier origen de información que pueda ser considerado para
el datawarehouse, aquí se incluyen 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.

El motor del datawarehouse

Está
integrado por los siguientes componentes

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,
  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 datawarehouse. La figura resume el proceso de
  carga, los archivos temporales finalmente son colocados en la base
  de datawarehouse de destino.

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 DataWarehouse.

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 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.

Afortunadamente,
las herramientas de limpieza de datos pueden ser de gran ayuda. En
algunos casos, puede crearse un programa de limpieza efectivo. En el
caso de bases de datos grandes, imprecisas e inconsistentes, el uso
de las herramientas comerciales puede ser casi obligatorio.

Decidir
qué herramienta usar es importante y no solamente para la
integridad de los datos. Si se equivoca, se 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

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:

• 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)

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.

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.

Gestor de Respaldos

Es
el componente que se encarga de respaldar constantemente la
información del repositorio del datawarehouse.

Repositorio del Datawarehouse

Es
el repositorio en si o la base de datos física donde se
almacena la información del datawarehouse.

Un
DBMS para trabajar con un sistema de Datawarehouse debe cumplir con
los siguientes requerimientos

Rendimiento de carga

• Datawarehouse
  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

Procesamiento de carga

• Muchos
  pasos deben ser dados para cargar un dato nuevo o actualizado hacia
  el datawarehouse 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.

Gestión de calidad de los datos

• El
  datawarehouse debe asegurar consistencia local, consistencia global
  e integridad referencial a pesar de las fuentes «sucias» y
  tamaños masivos de bases de datos

• 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 datawarehouse.

• Mientras
  más preguntas son respondidas, los analistas tienden a
  solicitar preguntas más complejas y creativas

Rendimiento de consultas

• Gestión
  basada en hechos y análisis ad hoc no deben ser retardadas o
  inhibidas por el rendimiento del RDBMS datawarehouse.

• Consultas
  complejas y grandes para operaciones claves del negocio deben ser
  completadas en un período de tiempo razonable.

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 (10¹⁵).
  

• 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.

1
Referencia [11] de la Bibliografía.

2
Imagen perteneciente al sitio de Rueda Tecnológica.
Referencia [8] de la Bibligrafía

3
Referencia 7 de Bibliografía, Datawarehousing Fácil.

4
Información e imágenes tomadas del sitio de TODO BI.

5
Sección basada en su mayor parte de la referencia [4] de la
bibliografía: Modelamiento Dimensional, Carmen Wolf

Continuación del tutorial (3ª parte)

Ing
Cristhian Herrera
64