¿Qué es un Data Warehouse DW?
El término Data Warehouse fue acuñado por Bill Inmon a principios de la década de los ´90 y lo definió de la siguiente manera:“Un warehouse es una colección de datos orientada a un determinado tema, integrado, variante en el tiempo y no volatil para ayudar al proceso de toma de decisiones gerenciales” [Inm92].
Analicemos cada uno de estos términos al igual que lo hace el autor
Orientado a un Tema:
Datos que brindan información sobre un “tema” o proceso del negocio en particular, en lugar de concentrarse en la dinámica de las transacciones de la organización.Integrado:
Los datos con los que se nutre el data warehouse vienen de diferentes fuentes y son integrados para dar una visión de un “todo” coherente.Variante en el Tiempo:
Todos los datos en el data warehouse son asociados con un período de tiempo específico.No Volatil:
Los datos son estables en el data warehouse. Mas datos son agregados pero los datos existentes no son removidos.Ralph Kimball define data warehouse de una forma más sencilla y práctica pero igual de importante, un data warehouse es:
“una copia de los datos transaccionales específicamente estructurados para consultas y análisis” [Kim92].
El data warehouse pretende conseguir un objetivo básico : “Proporcionar la información adecuada para la persona correcta en el tiempo preciso”
Arquitectura de un DW
Data Mart
Operational Data Store (ODS)
Extracción Transformación y Carga (ETL - Extract clean Transform Load)
Carga de datos es un proceso importante en el almacén de datos. Se compone de 50% a 75% de cualquier esfuerzo de almacenamiento de datos. Proceso ETL efectiva representa el principal éxito del proyecto de almacén de datos.
Extracción: El proceso por el cual los datos se tira o empuja desde sistemas fuente dispares.
Limpieza:Después que los datos se extrae de la fuente viene el siguiente paso es para limpiar los datos incorrectos.
Transformación:Sobre la base de las reglas de negocio se transforma datos.
Carga:Insertar / mover los datos transformados en las tablas de dimensiones y de hechos en un almacén de datos.
Decision Support System DSS
El DW es el “corazón” de la arquitectura de un Sistema de Soporte de Decisiones (DSS). Es la parte fundamental del funcionamiento de un DSS, dado que es una única fuente integrada de datos y los mismos, dentro del DW, son realmente accesibles permitiendo al analista del negocio trabajar en un ambiente inmensurablemente más fácil que en un ambiente clásico transaccional.El Sistema de Soporte de Decisiones provee los mecanismos de acceso a los datos y el análisis de los mismos. El DSS Engine es el “cerebro” de la arquitectura, es el motor que traducirá los requerimientos de los usuarios en las correspondientes sentencias de consulta para el data warehouse y el que interpretará los resultados devueltos por el warehouse para mostrarlos según lo solicitado por el usuario.
OLTP vs OLAP
Podemos dividir los sistemas de TI en transaccional (OLTP) y analítico (OLAP). En general se puede asumir que los sistemas OLTP proporcionan datos de origen a los almacenes de datos, mientras que los sistemas OLAP ayudan a analizar.
OLTP (On-line Transaction Processing) se caracteriza por un gran número de transacciones cortas en línea (INSERT, UPDATE, DELETE). El énfasis principal de los sistemas OLTP se pone en el procesamiento de consultas muy rápido, manteniendo la integridad de los datos en entornos multi-acceso y una efectividad se mide por el número de transacciones por segundo. En la base de datos OLTP hay datos detallada y actualizada, y el esquema utilizado para almacenar bases de datos transaccionales es el modelo de entidad (por lo general 3NF).
OLAP (On-Line Analytical Processing) se caracteriza por un volumen relativamente bajo de transacciones. Las consultas son a menudo muy complejos e implican agregaciones. Para los sistemas OLAP un tiempo de respuesta es una medida de eficacia. Aplicaciones OLAP son ampliamente utilizados por las técnicas de minería de datos. En la base de datos OLAP se agregan, los datos históricos, almacenados en esquemas multidimensionales (por lo general de esquema de estrella).
OLTP System
Online
Transaction Processing
(Operational
System)
|
OLAP System
Online
Analytical Processing
(Data Warehouse)
|
|
Fuente de los
datos
|
Datos operativos; OLTPs son la fuente original de los datos.
|
Consolidación de datos; Datos OLAP
proviene de las diferentes bases de datos OLTP
|
Finalidad de los
datos
|
Para controlar y ejecutar las tareas fundamentales del negocio
|
Para ayudar con la planificación, resolución de
problemas y apoyo a las decisiones
|
Data
|
Revela una instantánea de los procesos de negocio
en curso
|
Vistas multidimensionales de diversos tipos de
actividades empresariales
|
Inserciones y actualizaciones
|
Inserciones y actualizaciones cortas y rápidas iniciadas por los usuarios finales
|
Puestos de trabajo periódicas de lotes de larga duración actualizar los datos
|
Consultas
|
Consultas relativamente estandarizadas y simples que vuelven
relativamente pocos registros
|
A menudo, las consultas complejas que involucran
agregaciones
|
Velocidad de
procesamiento
|
Típicamente muy rápido
|
Depende de la cantidad de datos involucrados; actualizaciones de datos por lotes y consultas complejas pueden tardar muchas horas; velocidad de consulta se puede mejorar mediante la creación de
índices
|
Requisitos de
espacio
|
Puede ser relativamente pequeña si se archiva datos históricos
|
Más grande debido a la existencia de estructuras de
agregación y datos de la
historia; requiere más índices
que OLTP
|
Diseño de base de datos
|
Altamente normalizada con muchas mesas
|
Por lo general-normalizado de con
menos mesas; uso de estrella y / o
esquemas de copo de nieve
|
Backup y
recuperación
|
Copia de seguridad de la religión; datos operativos
es fundamental para manejar el negocio,
pérdida de datos que pueda provocar
una pérdida monetaria importante
y la responsabilidad legal
|
En lugar de copias de seguridad periódicas, algunos
entornos pueden considerar simplemente
volver a cargar los datos OLTP como un método
de recuperación
|
Modelo Dimensional
Un modelo dimensional es un diseño lógico para diseñar almacenes de datos. Formado por tablas de hechos y dimensiones. Difiere de los E/R ya que estos se orientan a transacciones. Kimball define este modelo como la única forma viable para llevar datos a usuarios en un DW. Cada proceso de negocio puede representarse en un cubo con dos o más dimensiones.Pasos para Construir un DW
1. Identificar el Proceso de Negocio:
Historial Académico. Conocer el historial académico de un estudiante para un periodo determinado.
2. Identificar la granularidad
Se refiere al nivel de sumarización o resumen de los datos en el almacén.A mayor nivel de granularidad se tienen menos detalles de los datos y viceversa.
Ejemplo:
Historial Académico por semestre para un estudiante.
3. Identificar Dimenciones
Una dimensión es un conjunto de atributos con una clave única (subrogada) que corresponde con uno de los componentes de la tabla de hechos.Los atributos definen características de una entidad, ofreciendo descripciones textuales. Los atributos de la dimensión surgen del sistema operacional y son los más relevantes para el análisis de los datos, son flexibles en el cambio, permiten realizar operaciones drill down y roll up.
Ejemplo:
Dim_Tiempo (id_dimTiempo, id_semestre, desc_semestre )
Estudiante (id_dimEstudiante, nombre, ci, sexo, estadoCivil, Nacionalidad, Fecha_Nacimiento, dirección, universidad, facultad, escuela).
Dim_Materia (id_dimMateria, codMateria, descMateria, preCondiciones,creditos)
Dim_Notas >>>dimension degenerada
4.Identificar los hechos
Una tabla de hecho es una relación multiclave que expresa relaciones muchos a muchos. Cada clave se relaciona con una dimensión.Un hecho es una medición del negocio, distinta a un atributo. Contiene además uno o más hechos numéricos que ocurren en la combinación de esas claves. Los hechos más útiles son los numéricos y aditivos.
Ejemplo:
Fact(id_DimEstudiante,Id_dimTiempo, id_dimMateria, id_dimNotas,
Cantidad de materias aprobadas, Cantidad de materias retiradas, Cantidad de creditos aprobadas, Cantidad de creditos retirados, Promedio de notas aprobadas...)
Tipos de dimensiones
Dimensiones Conformadas:
posee el mismo significado en cada relación que exista con alguna tabla de hechos.Dimensiones Degeneradas:
El término Dimensión Degenerada, hace referencia a un campo que será utilizado como criterio de análisis y que es almacenado en la tabla de hechos.
Esto sucede cuando un campo que se utilizará como criterio de análisis posee el mismo nivel de granularidad que los datos de la tabla de hechos, y que por lo tanto no se pueden realizar agrupaciones o sumarizaciones a través de este campo. Los "números de orden", "números de ticket", "números de transacción", etc, son algunos ejemplos de dimensiones degeneradas.
La inclusión de estos campos en las tablas de hechos, se lleva a cabo para reducir la duplicación y simplificar las consultas.
Se podría plantear la opción de simplemente incluir estos campos en una tabla de dimensión, pero en este caso estaríamos manteniendo una fila de esta dimensión por cada fila en la tabla de hechos, por consiguiente obtendríamos la duplicación de información y complejidad, que precisamente se pretende evitar.
Dimensión Basura:
Contiene información contextual de los hechos que pueden almacenarse en dimensiones separadas. Permiten almacenar datos como flags, comentarios, indicadores.Ejemplo:
Crear una dimensión basura con los atributos "sexo" y "estado civil" (con sus combinaciones)
Crear una dimensión basura con "comentarios" (si es conveniente tener ese atributo en el almacén)
Bibliografía
[Kim92] Ralph Kimball, 1992. The Data Warehouse Toolkit, Wiley Computer Publishing[Inm92] William H. Inmon, 1992. “Building the Data Warehouse”, Wiley-QED John Wiley & Sons, Inc..
http://datawarehouse4u.info/OLTP-vs-OLAP.html
http://www.dwmantra.com/dwconcepts.html
