Tecnología del Data

Warehouse
Unidad I
¿Qué es un data warehouse?
• Un data warehouse es un repositorio central de información que se puede analizar para tomar
decisiones mejor informadas.
• Los datos fluyen hacia un data warehouse a partir de sistemas transaccionales, bases de datos
relacionales y otros orígenes, normalmente a un ritmo regular.
• Los analistas empresariales, los científicos de datos y los responsables de la toma de decisiones
obtienen acceso a los datos mediante herramientas de inteligencia empresarial (BI), clientes SQL
y otras aplicaciones analíticas.
• Para que las empresas se mantengan competitivas, los datos y el análisis se han vuelto
fundamentales.
• Las empresas utilizan informes, paneles de control y herramientas analíticas para extraer
información de los datos, monitorizar el desempeño de la empresa y respaldar la toma de
decisiones.
• Estos informes, paneles y herramientas de análisis cuentan con almacenes de datos que
almacenan los datos de manera eficaz para reducir la entrada y la salida y suministrar resultados
de consultas a gran velocidad a cientos y miles de usuarios de manera simultánea.
Arquitectura de un Datawarehouse
• Un datawarehouse está compuesto por datos provenientes de
diversos sistemas operacionales (o también llamados
transaccionales).
• Cuando se habla de poblar un datawarehouse, se hace referencia al
proceso de tomar los datos de dichos sistemas para cargarlos en el
datawarehouse.
• Ahora bien, los datos crudos por sí mimos, en la base de datos del
datawarehouse no son útiles para ser presentados.
• Para presentar los datos al usuario final existen diversas alternativas,
algunas de ellas a través de desarrollos a medida o también mediante
herramientas existentes en el mercado desarrolladas a tal fin.
Arquitectura de un Datawarehouse
Arquitectura de un Datawarehouse
• Procesos de un Data Warehouse
• Extracción: obtención de información de las distintas fuentes tanto internas
como externas.
• Elaboración: filtrado, limpieza, depuración, homogeneización y agrupación de
la información.
• Carga: organización y actualización de los datos y los metadatos en la base de
datos.
• Explotación: extracción y análisis de la información en los distintos niveles de
agrupación.
Arquitectura de un Datawarehouse
• Procesos de un Data Warehouse
• Desde el punto de vista del usuario, el único proceso visible es la explotación
del almacén de datos, aunque el éxito del Data Warehouse radica en los tres
procesos iniciales que alimentan la información del mismo y suponen el
mayor porcentaje de esfuerzo (en torno a un 80%) a la hora de desarrollar el
almacén.
Arquitectura de un Datawarehouse
• Sistema Fuente (Source System)
• Denominamos sistema fuente a todo aquel sistema que proporciona datos al
datawarehouse para su análisis y explotación.
• Como ejemplo de un sistema fuente (los sistemas operacionales o transaccionales
nombrados anteriormente son sistemas fuente) podemos mencionar a los existentes
en los puestos de caja de un supermercado, que se encuentran permanentemente
generando registros en bases de datos transaccionales.
• La prioridad fundamental de un sistema de caja de un supermercado es que se
encuentre permanentemente funcionando y los tiempos de respuesta sean válidos
para los usuarios.
• Por otro lado, las consultas que se realizan sobre los movimientos de los puestos de
caja son escasas y dado el volumen de la información a almacenar, estos sistemas
tienden a no contener información histórica.
Arquitectura de un Datawarehouse
• Sistema Fuente (Source System)
• Los sistemas fuente son generalmente sistemas operacionales o
transaccionales (aunque otros sistemas también pueden ser fuente de datos
sin ser de estas clases) cuya función es capturar las transacciones de un
negocio.
• Un sistema fuente es frecuentemente llamado “ sistema legacy” en los
ambientes de mainframe.
• Las máximas prioridades de un sistema fuente son que se encuentre
funcionando y disponible.
• Por otro lado, las consultas a los sistemas fuentes son escasas y por lo general
contienen muy poca información histórica.
Arquitectura de un Datawarehouse
• Sistema Fuente (Source System)
• En cuanto a la base de datos de los sistemas fuente, se las suele denominar
bases de datos OLTP (on-line transaction processing).
• Por lo general, se puede ver que los sistemas transaccionales cuentan con su
base de datos modeladas bajo el esquema de entidad-relación
• Estas bases de datos se encuentran en mayor o menor medida normalizadas
de forma tal de evitar duplicidades de datos, optimizando espacio de
almacenamiento.
• Algunos ejemplos de sistemas fuentes son SAP, Peoplesoft, el ERP de Oracle,
un sistema de caja de una sucursal bancaria, o cualquier otra aplicación que
una empresa tenga desarrollada a medida con el fin de capturar las
transacciones del negocio.
Arquitectura de un Datawarehouse
• Área de Staging (almacenamiento intermedio) de Datos
• Como ya se mencionó anteriormente, cuando se quiere analizar el funcionamiento
de una empresa o de un área en particular, es necesario obtener datos de distintos
sistemas fuente para analizarlos en su conjunto.
• Volviendo al caso de un supermercado, quizás algún directivo o gerente del mismo
desee obtener un reporte que indique cuál ha sido el efecto de publicitar una
determinada oferta de un producto por televisión.
• Para poder lograr esto, puede ser necesario integrar los datos de los sistemas
transaccionales de caja (que indiquen cantidad de unidades vendidas de un
producto) con los sistemas de marketing (que indiquen cuando y en qué canal
apareció la oferta).
• Por otro lado, podría darse el caso de que para un mismo producto el código que
utiliza el sistema de caja sea distinto al código que utiliza el sistema de marketing con
lo cual sea necesario integrarlos.
Arquitectura de un Datawarehouse
• Área de Staging (almacenamiento intermedio) de Datos
• O quizás marketing no cuente con un sistema transaccional, sino que los
datos se encuentren en planillas Excel.
• En definitiva, la función de un Area de Staging de Datos es recibir los datos de
los sistemas transaccionales al fin de limpiarlos, transformarlos, combinarlos,
integrarlos y eliminar datos duplicados preparando los mismos para ser
usados en un datawarehouse o data mart.
Arquitectura de un Datawarehouse
• Área de Staging (almacenamiento intermedio) de Datos

• Es un área de almacenamiento y un conjunto de procesos orientados a

realizar estas tareas.
• Este conjunto de procesos se conoce comúnmente como procesos de ETL
(Extract, Transform, Load – Extracción, Transformación y Carga).
• En el mercado existen varias empresas que ofrecen herramientas de ETL
capaces de integrar datos de diversos sistemas fuente. Como ejemplo, las
cinco herramientas con mayor market share en el mercado mundial son:
Informatica, Ascential Datastage, SAS, Oracle Warehouse Builder y Genio
Arquitectura de un Datawarehouse
• Capa del datawarehouse propiamente dicho

• El datawarehouse es una base de datos modelada bajo un esquema

denominado “dimensional”
• El modelado dimensional es una disciplina específica para modelar datos que
es una alternativa al esquema de modelado de entidad-relación
Arquitectura de un Datawarehouse
• Capa del datawarehouse propiamente dicho
• Los componentes de un modelo dimensional se analizan más en detalle
posteriormente, pero los podemos definir brevemente:
• Tabla de Hechos o tabla de métricas o de indicadores o Fact Table
• Es la tabla primaria en cada modelo dimensional, orientada a contener las medidas del
negocio. (métrica para representar una medida del negocio, este término aparece como fact
measure o measurement y también como indicador)
• Cada fact table representa una relación de muchos a muchos y contiene un conjunto de dos o
más foreign keys (claves foráneas) que hacen referencias a sus respectivas tablas de
dimensión
Arquitectura de un Datawarehouse
• Capa del datawarehouse propiamente dicho
• Los componentes de un modelo dimensional se analizan más en detalle
posteriormente, pero los podemos definir brevemente:
• Dimension Table
• La Dimension Table restringe los criterios de selección de los datos de la fact table.
• Cada dimensión está definida por su clave primaria que sirve como base para la integridad
referencial con la Fact table con la cual hace join. Muchas tablas de dimensión contienen
atributos textuales (campos) que son la base para restringir y agrupar las consultas sobre el
data warehouse.
• Integración de las Dimension Tables con las Fact Tables
• Una métrica está siempre en función de las dimensiones. Supongamos que nos interesa el
importe vendido por fecha y sucursal. “ Importe vendido” es una métrica por lo que residirá
en lafact table. Y lo hará en función de los valores de las dimensiones que son fecha y
sucursal.
Arquitectura de un Datawarehouse
• Capa del datawarehouse propiamente dicho
• Los componentes de un modelo dimensional se analizan más en detalle
posteriormente, pero los podemos definir brevemente:
• Integración de las Dimension Tables con las Fact Tables
• Una métrica está siempre en función de las dimensiones. Supongamos que nos interesa el
importe vendido por fecha y sucursal. “ Importe vendido” es una métrica por lo que residirá
en lafact table. Y lo hará en función de los valores de las dimensiones que son fecha y
sucursal.
• Algebraicamente: Importe Vendido = f (fecha, sucursal)
• Generalizando: Métrica = f(d1, d2, …, dn)
• Las dimensiones son las variables de entrada de la función. Si se representara esto
gráficamente nos quedaría una función de dos variables (o dimensiones).
Arquitectura de un Datawarehouse
• Capa del datawarehouse propiamente dicho
• Los componentes de un modelo dimensional se analizan más en detalle
posteriormente, pero los podemos definir brevemente:
• Integración de las Dimension Tables con las Fact Tables
• Si vemos la representación algebraica, en el gráfico siguiente se puede entender por qué se
emplea el término “modelado dimensional”.
• Más aún, la implementación física del modelo dimensional es comunmente denominada
“cubo” cuando se implementa sobre bases de datos multidimensionales
Arquitectura de un Datawarehouse
• Análisis multidimensional
• E.F. Codd, considerado como el padre de las bases de datos relacionales, ha venido
insistiendo desde principio de los noventa, que disponer de un sistema de bases de datos
relacionales, no significa disponer de un soporte directo para la toma de decisiones.
• Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se
intentan resolver con la tecnología no orientada para esta naturaleza.
• Este análisis multidimensional, parte de una visión de la información como dimensiones de
negocio.
Arquitectura de un Datawarehouse
• Dimensiones del negocio
• Estas dimensiones de negocio se comprenden mejor fijando un ejemplo, para
lo que vamos a mostrar, para un sistema de gestión de expedientes, las
jerarquías que se podrían manejar para el número de los mismo para las
dimensiones: zona geográfica, tipo de expediente y tiempo de resolución
Arquitectura de un Datawarehouse
• Un gerente de una zona estaría
interesado en visualizar la información
para su zona en el tiempo para todos
los productos que distribuye, lo podría
tener una representación gráfica
como la siguiente
• Un director de producto, sin embargo
querría examinar la distribución
geográfica de sus productos, para
toda la información histórica
almacenada en el Data Warehouse
• O se podría también examinar los
datos en un determinado momento o
una visión particularizada.
Arquitectura de un Datawarehouse
• Metadatos
• Otra característica del Data Warehouse es que contiene datos relativos a los
datos, concepto que se ha venido asociando al término de metadatos.
• Los metadatos permiten mantener información de la procedencia de la
información, la periodicidad de refresco, su fiabilidad, forma de cálculo, etc.,
relativa a los datos de nuestro almacén.
• Estos metadatos serán los que permitan simplificar y automatizar la
obtención de la información desde los sistemas operacionales a los sistemas
informacionales.
Arquitectura de un Datawarehouse
• Objetivos de los metadatos
• Soportar al usuario final, ayudándole a acceder al Data Warehouse con su
propio lenguaje de negocio, indicando qué información hay y qué significado
tiene. Ayudar a construir consultas, informes y análisis, mediante
herramientas de navegación
• Soportar a los responsables técnicos del Data Warehouse en aspectos de
auditoría, gestión de la información histórica, administración del Data
Warehouse, elaboración de programas de extracción de la información,
especificación de las interfaces para la realimentación a los sistemas
operacionales de los resultados obtenidos, etc.
Arquitectura de un Datawarehouse
• Base de datos operacional / Nivel
de base de datos externo
• Nivel de acceso a la información
• Nivel de acceso a los datos
• Nivel de directorio de datos
(Metadata)
• Nivel de gestión de proceso
• Nivel de mensaje de la aplicación
• Nivel de data warehouse
• Nivel de organización de datos
Arquitectura de un Datawarehouse
Arquitectura de un Datawarehouse
• Base de datos operacional / Nivel de base de datos externo
• Los sistemas operacionales procesan datos para apoyar las necesidades
operacionales críticas.
• Para hacer eso, se han creado las bases de datos operacionales históricas que
proveen una estructura de procesamiento eficiente, para un número
relativamente pequeño de transacciones comerciales bien definidas.
• A causa del enfoque limitado de los sistemas operacionales, las bases de
datos diseñadas para soportar estos sistemas, tienen dificultad al accesar a
los datos para otra gestión o propósitos informáticos
• Ciertamente, la meta del data warehousing es liberar la información que es
almacenada en bases de datos operacionales y combinarla con la información
desde otra fuente de datos, generalmente externa
Arquitectura de un Datawarehouse
• Nivel de acceso a la información
• El nivel de acceso a la información de la arquitectura data warehouse, es el
nivel del que el usuario final se encarga directamente.
• En particular, representa las herramientas que el usuario final normalmente
usa día a día.
• Actualmente, existen herramientas más y más sofisticadas para manipular,
analizar y presentar los datos, sin embargo, hay problemas significativos al
tratar de convertir los datos tal como han sido recolectados y que se
encuentran contenidos en los sistemas operacionales en información fácil y
transparente para las herramientas de los usuarios finales.
• Una de las claves para esto es encontrar un lenguaje de datos común que
puede usarse a través de toda la empresa
Arquitectura de un Datawarehouse
• Nivel de acceso a los datos
• El nivel de acceso a los datos de la arquitectura data warehouse está involucrado con el nivel
de acceso a la información para relacionarse con el nivel operacional. El lenguaje de datos
común es el SQL.
• El nivel de acceso a los datos no solamente conecta DBMSs diferentes y sistemas de archivos
sobre el mismo hardware, sino también a los fabricantes y protocolos de red.
• Una de las claves de una estrategia data warehousing es proveer a los usuarios finales con
"acceso a datos universales".
• El acceso a los datos universales significa que, teóricamente por lo menos, los usuarios
finales sin tener en cuenta la herramienta de acceso a la información o ubicación, deberían
ser capaces de accesar a cualquier o todos los datos en la empresa que es necesaria para
ellos, para hacer su trabajo
• El nivel de acceso a los datos es responsable de la interface entre las herramientas de acceso
a la información y las bases de datos operacionales. En algunos casos, esto es todo lo que un
usuario final necesita.
• Las organizaciones desarrollan un plan mucho más sofisticado para el soporte del data
warehousing.
Arquitectura de un Datawarehouse
• Nivel de Directorio de Datos (Metadata)
• A fin de proveer el acceso a los datos universales, es absolutamente necesario
mantener alguna forma de directorio de datos o repositorio de la información
metadata.
• La metadata es la información alrededor de los datos dentro de la empresa.
• A fin de tener un depósito totalmente funcional, es necesario tener una
variedad de metadata disponibles, información sobre las vistas de datos de
los usuarios finales e información sobre las bases de datos operacionales.
• Idealmente, los usuarios finales deberían de acceso a los datos desde el data
warehouse (o desde las bases de datos operacionales), sin tener que conocer
dónde residen los datos o la forma en que se han almacenados
Arquitectura de un Datawarehouse
• Nivel de Gestión de Procesos
• El nivel de gestión de procesos tiene que ver con la programación de diversas
tareas que deben realizarse para construir y mantener el data warehouse y la
información del directorio de datos.
• Este nivel puede depender del alto nivel de control de trabajo para
muchos procesos (procedimientos) que deben ocurrir para mantener el
data warehouse actualizado.
Arquitectura de un Datawarehouse
• Nivel de Mensaje de la Aplicación
• El nivel de mensaje de la aplicación tiene que ver con el transporte de
información alrededor de la red de la empresa.
• El mensaje de aplicación se refiere también como "subproducto", pero puede
involucrar sólo protocolos de red.
• Puede usarse por ejemplo, para aislar aplicaciones operacionales o
estratégicas a partir del formato de datos exacto, recolectar transacciones o
los mensajes y entregarlos a una ubicación segura en un tiempo seguro
Arquitectura de un Datawarehouse
• Nivel Data Warehouse (Físico)
• En el data warehouse (núcleo) es donde ocurre la data actual, usada
principalmente para usos estratégicos.
• Se puede pensar del data warehouse simplemente como una vista lógica o
virtual de datos. En muchos ejemplos, el data warehouse puede no involucrar
almacenamiento de datos.
• En un data warehouse físico, copias, en algunos casos, muchas copias de
datos operacionales y/o externos, son almacenados realmente en una forma
que es fácil de accesar y es altamente flexible. Cada vez más, los data
warehouses son almacenados sobre plataformas cliente/servidor, pero por lo
general se almacenan sobre mainframes
Arquitectura de un Datawarehouse
• Nivel de Organización de Datos
• El componente final de la arquitectura data warehouse es la organización de
los datos. Se llama también gestión de copia o réplica,
• Incluye todos los procesos necesarios como seleccionar, editar, resumir,
combinar y cargar datos en el depósito y accesar a la información desde bases
de datos operacionales y/o externas.
• La organización de datos involucra con frecuencia una programación
compleja,
• Están creándose las herramientas data warehousing para ayudar en este
proceso.
• Involucra también programas de análisis de calidad de datos y filtros que
identifican modelos y estructura de datos dentro de la data operacional
existente.
Data Warehouse y las bases de
datos operacionales
Data Warehouse y las bases de datos
operacionales
• En un Data Warehouse se almacena toda la información de interés para
una organización que luego queramos analizar, mientras que, en una base
de datos operacional se almacenan todas las transacciones de la
organización, tanto datos útiles como no útiles.
• Uno de los errores típicos cuando nos enfrentamos a la construcción de un
almacén de datos es intentar replicar el modelo operacional.
• Un almacén de datos es diferente a una base de datos operacionales
porque su finalidad y objetivos son distintos. Haciendo una analogía con el
transporte, si quiero entregar una carta en una oficina en el centro de la
ciudad contrato a un mensajero que vaya en moto y lo haga de forma ágil y
rápida. Si quiero entregar 2 toneladas de papel contrato a un camión.
Ambos son transportes, pero con características distintas que responden a
necesidades distintas.
Data Warehouse y las bases de datos
operacionales
• El motivo principal de por que deben ser bases de datos distintas con
modelos distintos es por que se les va a dar usos distinto y lo que es
bueno para uno es malo para el otro.
• Interactuamos con la información de forma distinta por lo que debe
estar estructurada de forma distinta.
Data Warehouse y las bases de datos
operacionales
• Diferencias entre un data warehouse y una base de datos
• Normalmente, un data warehouse está diseñado para el análisis de datos,
que incluye la lectura de grandes volúmenes de datos para comprender las
relaciones y las tendencias internas. Una base de datos se usa para registrar y
almacenar datos, como la grabación de detalles de una transacción.
Data Warehouse y las bases de datos
operacionales
Diferencias entre un data warehouse y una base de datos
Normalmente, un data warehouse está diseñado para el análisis de datos, que incluye la lectura de grandes volúmenes de datos para comprender las relaciones y
las tendencias internas. Una base de datos se usa para registrar y almacenar datos, como la grabación de detalles de una transacción.
Características Data warehouse Base de datos transaccional

Cargas de trabajo admitidas Análisis, generación de informes, big data Procesamiento de transacciones

Datos recopilados y normalizados desde muchos Datos registrados tal cual desde un único origen,
Origen de datos
orígenes como un sistema transaccional

Optimizado para operaciones de escritura continua a

Operaciones de escritura masivas normalmente en un
Registro de datos medida que datos nuevos se encuentran disponibles
cronograma en lotes predeterminado
para maximizar el procesamiento de transacciones

Esquemas no normalizados, como los esquemas Star

Normalización de datos Esquemas estáticos con alto nivel de normalización
o Snowflake

Optimizado para acceso simple y desempeño de Optimizado para operaciones de escritura de alto
Almacenamiento de datos consultas de alta velocidad con almacenamiento en procesamiento a un único bloque físico orientado a
columnas filas

Optimizado para minimizar la E/S y maximizar el Grandes volúmenes de pequeñas operaciones de

Acceso a los datos
procesamiento de datos lectura
Data Warehouse y las bases de datos
operacionales
• Diferencias entre un data warehouse y un lago de datos
• A diferencia de un data warehouse, un lago de datos es un repositorio
centralizado para todos los datos, incluidos los estructurados y los no
estructurados. Un data warehouse usa un esquema predefinido optimizado
para realizar análisis. En un lago de datos, el esquema no está definido, lo que
permite añadir tipos adicionales de análisis, como análisis de big data,
búsqueda de texto completo, análisis en tiempo real y aprendizaje
automático.
Data Warehouse y las bases de datos
operacionales
Características Data warehouse Lago de datos

Datos relacionales provenientes de sistemas Datos no relacionales y relacionales provenientes

Datos transaccionales, bases de datos operativas y de dispositivos con IoT, sitios web, aplicaciones
aplicaciones de línea de negocio móviles, redes sociales y aplicaciones corporativas

Diseñado con anterioridad a la implementación Escrito al momento del análisis (esquema de

Esquema
del data warehouse (esquema de escritura) lectura)
Precio/desemp Resultados de búsqueda más rápidos con Resultados de consultas que se tornan más
eño almacenamiento de mayor costo rápidos con almacenamiento de bajo costo
Calidad de los Datos muy mantenidos que funcionan como Cualquier dato que pueda estar mantenido o no
datos versión central de la verdad (es decir, datos no procesados)
Analistas empresariales, científicos de datos y Científicos de datos, desarrolladores de datos y
Usuarios
desarrolladores de datos analistas empresariales (con datos mantenidos)
Generación de informes en lotes, BI y Aprendizaje automático, análisis predictivo,
Análisis
visualizaciones detección de datos y creación de perfiles
Data Warehouse y las bases de datos
operacionales
• Diferencias entre un data warehouse y un data mart
• Un data mart es un data warehouse que atiende las necesidades de un
equipo o unidad de negocios específico, como finanzas, marketing o ventas.
Es de menor tamaño, más enfocado y puede incluir resúmenes de datos que
atiendan mejor a su comunidad de usuarios.
Data Warehouse y las bases de datos
operacionales
Características Data warehouse Data Mart
Centralizado, varias áreas de asuntos integradas
Ámbito Descentralizado, área de asunto específica
juntas
Usuarios Toda la organización Un único departamento o comunidad
Un único origen o unos pocos, o bien una
Origen de datos Muchos orígenes porción de datos ya recopilados en un data
warehouse
Grande, puede ser de cientos de gigabytes a Pequeño, generalmente de hasta decenas de
Tamaño
petabytes gigabytes
Diseño De arriba hacia abajo De abajo hacia arriba

Nivel de detalle
Datos completos y detallados Puede incluir datos resumidos
de los datos
Bases de datos Multidimensional
Bases de datos Multidimensional