16 Capítulo 2.

Arquitectura

calcula que en la actualidad, una gran mayoría de los datos operacionales de las empresas
se almacenan en este tipo de sistemas.

Sistemas de archivo propietarios como VSAM o RSM.

Bases de datos externas públicas o privadas, que pueden aportar datos comparativos de la
empresa frente a sus competidores o datos de otros agentes económicos que participan
en el mismo entorno (como las empresas que recopilan datos y los venden, proveedores,
clientes, etc.).

Internet, que dada la cantidad ingente de datos diversos, puede suponer una fuente importante
a la hora de completar los datos extraídos desde las fuentes de datos operacionales.

Datos en formato tradicional, ya que aún existen empresas y organismos públicos que disponen
de datos que están en formato tradicional como albaranes, facturas, notas de entrega o
datos del registro civil. Incorporar estos datos suele ser un esfuerzo extra porque, en primer
lugar hay que pasarlos a formato electrónico. Sin embargo, en ocasiones es imprescindible
si se quiere disponer de un almacén de datos que registre una larga historia.

2.3. Los procesos ETL

Los procesos ETL (Extraction, Transformation, and Loading, extracción, transformación y
carga) son de crucial relevancia en la arquitectura del almacén de datos. Estos procesos son los
responsables de extraer los datos de las fuentes de datos transaccionales, realizar las transfor-
maciones necesarias, cargarlos en el almacén de datos una vez hayan sido tratados y realizar
los refrescos o cargas sucesivas de datos durante la vida del almacén de datos. Así como a las
herramientas de usuario final se les conoce como el front-end, a los procesos ETL y el trata-
miento de los datos operacionales se les suele denominar back-stage, back-room o staging area.
A continuación, vamos a concretar un poco más las tareas que se realizan en cada una de estas
fases.

2.3.1. Extracción
Son procesos que se encargan de conectar con las fuentes de datos operacionales para extraer
los datos con los que se poblará el almacén de datos. Para programar estos procesos, se tiene que
Copyright © 2013. ECU. All rights reserved.

tener conocimiento de los metadatos de las fuentes de datos y del tipo de conectividad necesaria
para su extracción.

2.3.2. Transformación o limpieza

Es fundamental que los datos del almacén de datos sean correctos, dado que se utilizarán para
adoptar decisiones estratégicas que normalmente llevan asociadas fuertes inversiones, siendo
claves para el posicionamiento de la empresa en el entorno en el que se desenvuelve. Dada la
idiosincrasia de los almacenes de datos, en el sentido que los datos proceden de diversas fuentes
de datos, normalmente heterogéneas; existe una alta probabilidad de enfrentarnos a errores en
caso de no limpiar o tratar los datos con anterioridad a su carga en el repositorio.
Por resumir, algunas anomalías típicas son:

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.
 2.3. Los procesos ETL 17

Longitud inconsistente de campos. Es muy común que los campos de datos (como los de
dirección, nombre o apellidos) tengan longitudes distintas en las diferentes bases de
datos de la organización. Estas bases de datos se han podido desarrollar en distintos pe-
riodos de tiempo, incluso por distintas empresas o personas, sin tener la precaución de que
coincidan la longitud de los campos de datos.

Descripción inconsistente de campos. Podemos encontrar que en una base de datos, por ejem-
plo, el campo dirección se refiere al nombre de la calle o avenida donde reside una perso-
na, mientras que en otra el campo dirección incluye el referido a nombre, código postal,
ciudad, provincia, etc.

Distintas codi caciones para el mismo término. Esta anomalía continúa siendo una fuente im-
portante de errores aunque sea cada vez menos habitual en las fuentes de datos operacio-
nales (gracias a la generalización de formularios que presentan listas desplegables de va-
lores prefijados para la introducción de datos mediante selección). Por ejemplo, podemos
tener en distintas bases de datos (académica, económica, estadística, etc.) que un estudian-
te proviene del I. Jorge Juan , Inst. Jorge Juan , I.B. Jorge Juan , I.B. J.
Juan , etc. Si estos datos se cargan sin limpiarlos, a la hora de extraer resúmenes, todos
estos nombres serán tratados como institutos de bachillerato distintos, cuando en realidad
son el mismo. Por ello, es fundamental limpiarlos y unificar sus descripciones y nombres
antes de cargarlos en el almacén de datos.

Valores nulos. Es muy común que una vez diseñado el esquema del almacén de datos, cuando
extraigamos datos de las fuentes, nos encontremos con campos de datos nulos, los cuales,
en muchas ocasiones, se tendrán que rellenar de forma manual.

Nuevas reglas de integridad. Si los datos de las fuentes de datos se regían según unas ciertas
reglas de integridad, ya en el almacén de datos, estas reglas no serán válidas. Éste dispone
de sus propias reglas de integridad y los nuevos datos deberán de adecuarse a tales reglas
siguiendo el nuevo esquema de datos, propio del almacén de datos.

2.3.3. Carga
Una vez que los datos se han extraído de las fuentes de datos y se han transformado y limpiado,
hay que cargarlos en el almacén de datos. Pero antes de realizar la “inserción” final de los datos,
Copyright © 2013. ECU. All rights reserved.

normalmente se requiere un preprocesamiento de los datos ya limpiados, que normalmente suele

consistir en:

Comprobar nuevamente las reglas de integridad.

Ordenar los datos.

Calcular datos agregados, resumidos, etc., ya que los almacenes de datos suelen albergar
una gran cantidad de datos de este tipo.

Construir tablas derivadas, virtuales, temporales, etc., necesarias para la carga final de
datos.

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.
 18 Capítulo 2. Arquitectura

Construir índices específicos para la carga de datos. Una buena política de definición de
índices suele ser fundamental para el rendimiento del mismo, no sólo para las propias
estructuras del almacén de datos, sino también para el proceso de carga de datos.

Definir la paginación de carga de datos.

Especificar el tiempo (la ventana de carga) en el que se desea realizar la carga de datos.
Dicha carga se deberá realizar cuando la fuente de datos tenga menos volumen de trabajo.
No resulta extraño entonces que la noche sea el momento adecuado para la carga de
datos en el almacén de datos, pues es cuando probablemente menos consultas tendrá
que satisfacer el sistema OLTP. Aun así, siempre podremos dar con casos especiales y
extremos: las empresas multinacionales establecidas en varios continentes es un ejemplo
típico de cuándo deberemos estudiar con detenimiento del período óptimo de carga.

Las técnicas de carga de datos más comunes son:

Cargas secuenciales. Son las más caras y las que más tiempo ocupan, puesto que consisten en
reemplazar la antigua tabla con la nueva después de una transacción. Además, utilizan
comprobaciones periódicas, normalmente, comenzar después de fallo.

Procesos por lotes (batch). Son aquellas en las que el administrador monitoriza el proceso de
carga. La carga se realiza mediante procesos cortos con uso secuencial de E/S. Tal técnica
es adecuada para la generación de índices y datos derivados.

Procesamiento paralelo y técnicas incrementales. Sólo carga las actualizaciones, no tablas en-
teras. Al realizar la confirmación de la transacción, se reemplaza el antiguo estado con los
nuevos datos. Con esta técnica, el almacén de datos puede ser consultado mientras carga.
Utiliza también comprobaciones periódicas de inconsistencia, esto es, mediante procesos
de auditoría sobre los datos.

Por otro lado, tras la primera carga del almacén de datos, se procede a un proceso de refresco
en que las actualizaciones realizadas sobre las fuentes de datos se propagan al almacén de datos.
De todas formas, realizar una nueva carga por cada actualización de la fuente de datos es un
proceso costoso y sólo debería justificarse dada la importancia de analizar datos muy actuales,
como es el caso del análisis de la bolsa de valores. Normalmente, los refrescos se hacen de manera
periódica, definiéndose una política de actualización en función de cada caso. Por ello, no se debe
Copyright © 2013. ECU. All rights reserved.

olvidar que los SGBD (Sistema de gestión de bases de datos) ofrecen servidores para replicar
datos con la consiguiente aceleración de los refrescos.
Existen dos técnicas fundamentales para el refresco:

Extracción entera de las bases de datos donde se leen las tablas o bases de datos completa-
mente. Pese a que esta alternativa es costosa, a veces, es la única elección para ficheros o
sistemas heredados.

Técnicas incrementales donde se detectan y propagan los cambios. Esta técnica se realiza me-
diante servidores de réplica. Por ejemplo, mediante imágenes (snapshots) y triggers como
con Oracle, mediante transporte de transacciones (transaction shipping) como con Sybase,
u otras como con IBM data replicator.

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.
 2.4. El almacén de datos 19

2.3.4. Herramientas para procesos ETL

Aunque en la práctica los procesos ETL se configuran normalmente haciendo uso de las utili-
dades para tal fin que proporciona el producto comercial que utilizamos como gestor del almacén
de datos, o programando directamente en cualquier 4GL (Fourth-Generation programming Lan-
guage), existen herramientas específicas que están enfocadas a facilitar estas tareas. Ofrecemos
aquí una clasificación de las mismas:
Herramientas de migración de datos (data migration). Permiten definir reglas para transfor-
maciones simples como, por ejemplo, reglas para reemplazar el nombre del campo género
en la fuente por sexo en el almacén de datos.
Herramientas de limpieza de datos (data scrubbing ). Con ellas se puede registrar conocimien-
to específico del dominio en forma de reglas y comprobar que los datos las cumplen. Por
ejemplo, permiten la definición de patrones para direcciones postales y así, cualquier campo
dirección deberá cumplir esta regla.
Herramientas de auditoría de datos (data auditing tools). Examinan los datos para descu-
brir reglas y relaciones entre ellos y, de esta forma, lanzar señales de violación si se en-
cuentra que hay reglas predefinidas que no se están cumpliendo.

2.4. El almacén de datos

Este es el elemento principal de la arquitectura y donde los datos a analizar se integran y
consolidan. Por ello, la definición de almacén de datos se ha visto ya en el capítulo anterior y en
el siguiente se verá su diseño mediante el modelado multidimensional de hechos y dimensiones
bajo análisis.

2.4.1. Almacenes de datos departamentales o data marts

Los data marts son repositorios de datos que se asocian a un almacén de datos como vistas
de éste para satisfacer las necesidades de un departamento o sección dentro de una empresa.
Normalmente, en la práctica suelen contener más cantidad de información agrupada que en
detalle, tal y como ocurre por otro lado en el almacén de datos.
Para su construcción se pueden seguir dos aproximaciones:
Copyright © 2013. ECU. All rights reserved.

1. Definir primero el almacén de datos y, a partir de él, definir los data marts.
2. Definir primero los data marts y posteriormente integrarlos en un almacén de datos global
para la organización.
De estas dos aproximaciones, la primera es la más adecuada desde un punto de vista teórico,
pues ayuda a que los procesos de carga integren las fuentes de datos en un único repositorio
para después distribuir los datos agregados a los data marts. Por otro lado, en la práctica, si la
envergadura de la empresa es considerable o la experiencia en la construcción de almacenes de
datos es pequeña, es aconsejable decantarse por la segunda aproximación, pues permite definir
un almacén de datos global cuando ya se ha visto la viabilidad y utilidad de proyectos de data
marts más pequeños y manejables que uno de almacenes de datos. En resumen, podemos decir
que:

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.
 20 Capítulo 2. Arquitectura

Figura 2.2.: Representación de los data marts como versiones agregadas del almacén de datos

Almacén de datos corporativo dispone de información acerca de toda la empresa, requiere un

modelado del negocio complejo y puede llevar años en su construcción e implementación.
Data mart es una versión reducida del almacén de datos orientado a un tema específico. Por
ejemplo, marketing, clientes, productos o ventas. Es más rápido de diseñar pero con el
problema de que la integración con el almacén de datos corporativo puede ser compleja al
haberse diseñado antes que él.

Aparte de los data marts, existen también los almacenes de datos virtuales. Si los primeros
se podían ver como vistas materializadas del almacén de datos, los segundos son vistas (sin
materializar) sobre las fuentes de datos operacionales. Pese a que en general tales vistas son solo
virtuales, también se incluyen materializaciones de algunas vistas agregadas para hacer más
eficientes las consultas más comunes. Estos repositorios son más fáciles de construir, ya que no
se requieren estructuras físicas para su almacenamiento, pero necesitan una capacidad operativa
extra en el servidor para ser analizado mediante las herramientas correspondientes. Por ello, no
es extraño que muchas empresas decidan construir almacenes de datos cuando el administrador
ya ha creado uno virtual.

2.5. Los metadatos

Copyright © 2013. ECU. All rights reserved.

Los metadatos “son datos acerca de otros datos”. A continuación, se presentan algunos ejemplos
de tales metadatos:

Qué dato se guarda (por ejemplo, clientes).

Dónde se guarda (tabla clientes).
Campos de la tabla.
Con qué datos de las fuentes se corresponden.
Niveles de agregación.

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.
 2.6. Servidores de bases de datos y consulta 21

Cuándo se actualizan los datos.

Cuándo fue la última actualización.

Patrón de dato válido (por ejemplo, Apellido1 Apellido2, Nombre).

Los metadatos se clasifican en los siguientes tipos:

Administrativos: estos son toda la información necesaria para el almacén de datos. Entre ellos
contamos con: fuentes de datos y contenidos, descripciones del gateway, esquema del al-
macén de datos, vistas y datos agregados, dimensiones de análisis con sus jerarquías, con-
sultas e informes predefinidos, localización y contenido de los data marts o las particiones
de datos, entre otros.

De negocio: como es la información y términos de negocio, las políticas de posesión de datos y

las políticas de permiso de datos por los usuarios (seguridad).

Operacionales: recogidos durante el proceso de carga del almacén de datos. Por ejemplo, los
datos migrados y secuencia de transformaciones aplicadas, el estado de los datos (acti-
vos, archivados, eliminados, etc.) o la información de monitorización (estadísticas de uso,
informes de error, auditoría, etc.).

2.6. Servidores de bases de datos y consulta

El servidor del almacén de datos es un SGBD que se encarga de gestionar el repositorio
del propio almacén de datos, coordinar los procesos ETL que alimentan el almacén de datos
y procesar las consultas lanzadas sobre el almacén devolviendo los datos. Generalmente son
servidores relacionales dada la amplia difusión de tal tecnología.
Por otro lado, en la mayoría de las arquitecturas se utiliza un servidor distinto al del almacén
de datos para las consultas. Esto es debido a motivos de rendimiento y mantenimiento, pues al
separar las consultas del SGBD, se pueden establecer diferentes mecanismos que optimicen las
consultas en función de su tipo. Dada su flexibilidad, la mayoría de las herramientas funcionan
con esta arquitectura (por ejemplo, MicroStrategy).
Copyright © 2013. ECU. All rights reserved.

Existen dos tipos de arquitecturas fundamentales para implementar tales servidores, en fun-
ción de la tecnología de bases de datos usada.
Por un lado, los servidores ROLAP utilizan la tecnología relacional mediante la extensión de
SQL (Structured Query Language, lenguaje de consulta estructurado) para soportar el acceso
multidimensional a los datos. Presentan métodos de implementación adecuados para representar
los datos multidimensionales en la tecnología relacional. La ventaja del uso de una tecnología
tan difundida como la relacional es que están basados en el estándar SQL. Algunos de los más
extendidos son: Oracle o IBM (DB2 y Business Solutions), por ejemplo.
Por otro lado, los servidores MOLAP utilizan la tecnología multidimensional. Los datos
están almacenados directamente en matrices y las operaciones de consulta están implementadas
directamente sobre tales estructuras de datos. Por ello, no están basados en el estándar SQL.
La ventaja es que suelen ser más rápidos que los servidores ROLAP.

Trujillo, Juan Carlos. Diseño y explotación de almacenes de datos: conceptos básicos de modelado multidimensional, ECU, 2013. ProQuest
Ebook Central, [Link]
Created from upnortesp on 2020-10-01 21:55:11.