Los principales objetivos de
este artículo se orientan hacia la construcción de un Datawarehouse que
está dirigido fundamentalmente a responder de manera
rápida a las solicitudes de análisis de los directivos de las empresas. Un
lugar importante en la construcción del Datawarehouse lo
ocupa el área de transformación de los datos, la cual
varía en su complejidad en dependencia de los
requerimientos del problema.
Palabras claves: datawarehouse, back room,
área de transformación de datos, modelo
dimensional
Para aquellos que desarrollan y mantienen los sistemas de datos
haciéndolos disponibles para los directivos de las
empresas, el término DataWareHouse o también
conocido como Almacén de Datos, ofrece la
solución como ubicación central para que todos
puedan acceder a la información con los reportes necesarios,
dando respuesta a necesidades de diferentes tipos de
usuarios.
El Datawarehouse (en lo adelante nos referiremos como
DWH) surgió con el objetivo de
hacer consultable la información que se tiene de una empresa tanto
de meses como de años anteriores.
El DWH organiza y orienta los datos desde la perspectiva
del usuario final, mientras que los sistemas operacionales
organizan sus datos desde la perspectiva de la aplicación,
para lograr eficiencia en el
acceso a datos.
Los principales objetivos de un Datawarehouse
son:
- Comprender las necesidades de los usuarios por
áreas dentro del negocio. - Determinar qué decisiones se pueden tomar con
la ayuda del DWH - Seleccionar un subconjunto del sistema de
fuentes de
datos que sea el más efectivo y procesable para
presentar el DWH. - Asegurar que los datos sean precisos , correctos y
confiables y que mantengan la consistencia . - Monitorear continuamente la precisión y
exactitud de los datos y el contenido de los reportes
generados. - Publicar los datos.
¿Por qué se justifica construir un
Datawarehouse?
Generalmente, los sistemas transaccionales o OLTP usan
estructuras
normalizadas, en las cuales se optimizan las inserciones y
actualizaciones de artículos e incluso algunas
selecciones, pero es menos probable que el sistema se organice de
forma tal que produzca reportes eficientes para datos resumidos
con cierta jerarquía. Y es aquí donde
debería usarse el DWH, que usa los datos relevantes de
fuentes existentes y los combina en una estructura que
ha sido optimizada para las selecciones.
Esta es la razón por la cual se construye un
datawarehouse para solucionar la problemática de tener un
sistema fuente transaccional corriendo sobre un servidor Novell. Esta
información se necesita que esté consultable para
los clientes de
la empresa de
forma remota y sin embargo, por problemas de
seguridad no
puede estar directamente disponible desde el mismo sistema
fuente. El datawarehouse ha sido la solución propuesta
para que la información sea utilizada por una
aplicación cliente de acceso
remoto. De esta forma se aprovecha la forma en que se organizan
los datos en el almacén en
el modelo dimensional y se brinda a la Gerencia un
grupo de
informaciones organizadas en cubos multidimensionales que les
permite profundizar en el análisis de la
información y ver su variación en el tiempo.
Un DWH debe tener cuatro características que son
primarias . Es una colección de datos orientada a un
tema , integrada, variable en el tiempo y no
volátil que sea útil para la toma de
decisiones.
Es orientada a un tema porque tiene en cuenta los
procesos de
negocio de la empresa que se
deseen priorizar. Es integrado porque agrupa a todos los
sistemas operacionales en un sistema de
información con formatos y códigos
consistentes. Es variante en el tiempo porque los datos se
organizan y almacenan en jerarquías en el tiempo, lo que
permiten análisis comparativos de estados actuales y de
períodos anteriores. Es no volátil porque se
usa principalmente para operaciones de
recuperación de información y no para
actualizaciones.
Los DWH están en la categoría de los
sistemas para el soporte de decisiones (DSS) que tienen como
objetivos medir y controlar el desarrollo de
las variables
importantes del negocio, buscando identificar, proyectar y
predecir tendencias a partir de los datos acumulados.
Los datos que se manejan en el DWH son informacionales ,
esto significa que son datos resumidos y periódicos a
diferencia de los datos operacionales.
Cuáles pudieran ser consultas típicas en
este sistema para la toma de decisiones de la
empresa?.
- ¿Cuál ha sido el total de ingresos de los
clientes por meses y años? - ¿Cuáles han sido los pagos realizados
por los clientes y por qué conceptos? - ¿Cuáles han sido las principales
cadenas hoteleras que aportan a sus Casas Matrices?
Con la creación de un DWH, se persigue un sistema
de fácil comprensión y de rápida
ejecución que significa datos de alta calidad, con un
diseño
que permita los cambios y además, una salvaguarda segura
para proteger la información.
Partes del DWH
El DWH necesita de tres áreas bien diferentes
entre sí pero que se integran para lograr un buen
funcionamiento:
- Los sistemas origen o fuentes legados
. - El área de transformación de los datos
(en lo adelante nos referiremos como ATD) - El Servidor de presentación del
DWH
(Ver Anexo1)
Las fuentes legados son
los sistemas de procesamiento que capturan las transacciones del
negocio. Deben ser sistemas confiables y consistentes , aunque
entre ellos hay marcadas diferencias en los formatos y las
estructuras de los datos. Quedan fuera del DWH por lo que no
tenemos el control sobre el
contenido de sus datos.
El área de transformación de los
datos (ATD) consta tanto del área de almacenamiento
como del conjunto de procesos que se usan frecuentemente para la
extracción, transformación y carga de los datos .
Es generalmente la parte más compleja de esta arquitectura. Es
todo lo que se presenta entre la fuente externa y el área
de presentación de los datos.
El servidor de presentación es la fuente
consultable de datos de la empresa. Es donde se organizan los
datos del DWH , se almacenan y están disponibles para
hacer consultas, reportes y acceder mediante
aplicaciones.
Concretamente, el área de transformación
de datos puede estar constituida por un grupo de servicios de
transformación de datos que pueden ser implementados para
mantener actualizada la información del almacén
haciendo algunas transformaciones a los datos.
El DWH se soporta sobre el modelo dimensional a
diferencia de los sistemas de bases de datos
que están basados en el modelo
Entidad-Relación. Este modelo contiene la misma
información que el modelo E/R pero empaqueta los datos en
un formato simétrico cuyo objetivo es ganar una mayor
comprensión del usuario y garantizar la ejecución
rápida y eficiente de las consultas. A diferencia del
modelo E/R, el modelo dimensional no necesita anticipar las
consultas que se van a realizar y es muy elástico a los
cambios que se produzcan en los patrones de los
usuarios.
El modelo dimensional divide el mundo de los datos en
dos grandes tipos: las medidas y las descripciones del entorno de
estas medidas. Las medidas, que generalmente son
numéricas, se almacenan en las tablas de hechos y
las descripciones de los entornos que son textuales se almacenan
en las tablas de dimensiones. Las tablas de hechos son las
tablas primarias en el modelo dimensional y contiene los valores
del negocio. Los hechos más comunes son valores
numéricos . Cada tabla representa una interrelación
muchos – muchos y contiene dos o más llaves
extranjeras que acoplan con sus respectivas tablas de
dimensiones.
Las tablas de dimensiones son las compañeras de
las tablas de hechos. Cada dimensión se define por su
llave primaria que sirve para mantener la integridad referencial
en la tabla de hechos a la que se acopla. Los atributos de estas
tablas sirven de base a las solicitudes que se hacen al
DWH.
Las tablas de dimensiones contienen información
jerárquica que permitirán la realización de
las agregaciones o las profundizaciones.
En el Anexo # 2 se muestra un modelo
dimensional propuesto para una institución financiera
basado en un esquema de estrella.
Para conformar la tabla de hechos se tuvo en cuenta el
hecho principal del problema que es la operación
financiera de un cliente, la cual se mide por el importe de la
operación. En la operación intervienen
además del código
del cliente que hizo la operación, el desglose de la
cuenta, la moneda en que se hizo, el concepto y la
fecha y sobre estas descripciones se conformaron las dimensiones
que se actualizan de los clasificadores del sistema
fuente.
Para acceder al servidor de presentación se
implementan las herramientas de acceso de datos del usuario
final. Estas herramientas
constituyen el cliente del DWH que mantiene una interacción con el servidor enviando a
éste solicitudes SQL y devuelve
los resultados ya sea en pantalla , o en un reporte o un
gráfico o alguna otra forma superior de análisis
para el usuario. Estas herramientas pueden ser tan simples como
las consultas ad-hoc o tan complejas como la
minería de datos . Las consultas ad-hoc se
establecen cuando el usuario forma sus propias consultas
manipulando directamente las tablas relacionales y sus conexiones
. Se usa solamente por un 10% de todos los usuarios finales del
DWH ya que el resto prefiere usar las aplicaciones.
Para dar uso al almacén y acceder de forma remota
a esa información, se implementa una aplicación
cliente basada en tecnología web aprovechando
la ventaja de que esta aplicación se puede invocar desde
cualquier máquina haciendo conexión remota
independientemente del sistema operativo
que tenga implantado. Las consultas que hace la aplicación
al servidor de los datos se realizan invocando procedimientos
almacenados que están en el servidor y que agilizan
notablemente dichas consultas.
Otra de las herramientas que se utilizan en el Servidor
de Presentación es el Procesamiento Analítico en
Línea (OLAP), el cual permite crear vistas
multidimensionales de los datos sobre las bases de datos
tradicionales.
El procesamiento analítico en línea se
puede ver como la síntesis,
análisis y consolidación de grandes
volúmenes de datos empresariales en la perspectiva de
múltiples dimensiones tales como el tiempo, los clientes,
las cadenas, las operaciones
financieras, etc. Este análisis en línea de los
datos puede utilizar fórmulas matemáticas y análisis
estadísticos para consolidar y resumir los
datos.
Los requerimientos del negocio son los que dirigen la
arquitectura de diseño de un DW por lo que se debe tener
bien claro todos los asuntos del negocio, las estrategias, los
procesos, la disponibilidad y las expectativas de
ejecución del negocio.
La arquitectura del DWH se convierte en el esquema de
producción . Esta no es un plan de proyectos o una
lista de tareas. Es el "qué" se debe hacer y no
cómo y por qué. Desarrollar una arquitectura es
difícil, pero posible y decisiva para el éxito
del DWH. Está dirigida por el negocio, es decir, los
requerimientos del negocio traen implicaciones técnicas
sobre la arquitectura. Por ejemplo: las actualizaciones nocturnas
conllevan a adecuar el procesamiento en el ATD; si se quiere
tener una disponibilidad a nivel mundial se requiere de servidores
distribuidos o paralelos; etc.
Back Room o Area de transformación de
datos
El área técnica de una arquitectura de DWH
se divide en dos subconjuntos: el back room y front room . El
back room es la parte responsable de preparar los datos y el
front room de entregarlos a los usuarios.
El back room es el área donde tienen lugar
los procesos de transformación de los datos y coincide con
el área de transformación de datos.
El principal interés de
los administradores de las Base de datos
y de sistema en esta parte es resolver el problema de tomar los
datos correctos del punto A al punto B y hacer las
transformaciones apropiadas en un tiempo adecuado.
Los almacenes de
datos, en su mayoría, se encuentran en el back room
del DWH en pequeños y medianos tamaños. Lo que
usted necesita para su diseño depende en gran medida de
los requerimientos de su problema y la complejidad de los
procesos de extracción y transformación que va a
desarrollar.
A modo de resumen, podemos plantear que para crear la
arquitectura del back room es decisivo comprender la naturaleza de
las fuentes de datos y qué formas van a tomar.
El área de transformación de datos es el
banco de
trabajo del
DWH. Su propósito es dejar el dato listo para el servidor
de presentación, ya sea un DBMS relacional o un motor
OLAP.
Una característica distintiva de esta área
es que aquí se crean las tablas de dimensiones, las cuales
se replican en todos los mercados de datos
que lo requieran.
Una vez que los datos se extraen del sistema fuente, se
le aplican una serie de transformaciones para convertirlos en
algo presentable a los usuarios y de valor para el
negocio.
Los procesos en el ATD están guiados en esencia
por metadatos que incluyen las reglas del negocio. Los metadatos
se usan con herramientas administrativas para guiar las
extracciones de los datos, transformaciones, archivo y carga
en los mercados de datos y en el esquema del DWH.
Los metadatos se definen como datos acerca de los datos.
Son como el mapa de carretera hacia los datos.
Se plantea que el proceso de
creación y manejo de los datos en el DWH está
formado por varios pasos de los cuales en su mayoría
involucran metadatos y el DWH en su totalidad depende de
ellos.
El catálogo de metadatos juega un papel decisivo
en la arquitectura del DWH , ya que suministra los
parámetros y la información que permite que la
aplicación realice sus tareas; contiene un conjunto de
información de control del DWH, su contenido, sus fuentes
de origen y sus procesos.
Hasta este punto, el catálogo de datos es
sólo un concepto lógico y cualquier cambio en
él se reflejará en toda la arquitectura y
estará disponible para todos los servicios a la
vez.
En la mayoría de los casos, no es muy
práctico traer toda la información a un solo lugar.
Los metadatos existen en varias herramientas, programas y
utilitarios que hacen que el DWH funcione.
Kimball [4] presentó un grupo de transformaciones
que pudieran ser incluidas en el DWH que vamos a
crear:
- Integración: implica generar llaves
sustitutas para las dimensiones, mapear las llaves de un
sistema con otro y mapear los códigos con las
descripciones completas. - Mantenimiento lento en los cambios en las
dimensiones : identificar los valores que han cambiado y
crear las llaves sustitutas asociadas es un proceso que
encierra trucos en lugar de hechos
matemáticos. - Chequeo de integridad referencial : la
integridad referencial significa que los datos en una tabla
estén en correspondencia con sus iguales en la otra
tabla. La integridad referencial se pudiera manejar a nivel de
base de datos en vez de cómo parte del proceso de
transformaciones pero reduciría su
flexibilidad. - Denormalización : convertir una
jerarquía de tablas separadas en una dimensión es
un proceso estándar de transformación del DWH.
Este proceso consiste en abandonar las reglas de normalización y permitir los datos
repetitivos con el objetivo de dar mayor comprensión y
fácil ejecución a las consultas. - Limpieza y depuración : limpiar los
datos. Este es un proceso complejo especialmente con aquellos
DWH que tienen que ver con entidades externas como clientes,
compañías, doctores y pacientes, pero ya existen
proveedores
que ofrecen herramientas y servicios específicos para
ello. - Conversión del tipo de datos : Hacer
transformaciones a bajo nivel que conviertan un tipo de datos o
formato en otro. Por ejemplo: convertir las representaciones
numéricas, de carácter de una base de datos a
otra. - Asignaciones y cálculos : Hacer
transformaciones se aplican a las reglas del negocio que se
identifican durante el proceso. Un ejemplo pudiera ser llevar a
mayúsculas el campo nombre del usuario para hacer
más legibles los reportes. - Agregación : se maneja en el proceso de
carga, en dependencia de los recursos que
estén disponibles en cada etapa. - Auditoría del contenido de los datos :
Procesar sumas de chequeo, contadores de filas y chequearlos
contra las fuentes para alertar cuando no se correspondan. Es
imposible chequear todo, pero sí algunas pruebas
sólidas ahorrarían gasto de tiempo y
errores. - Valores nulos : Identificar cuales son los
valores sustitutos para los nulos y desarrollar reglas para
manejarlos en las bases de datos.
Integridad referencial
El DWH como sistema de base de datos, debe mantener la
integridad referencial y para implementarla, se procesan primero
las dimensiones antes que los hechos. Se crean llaves sustitutas
en el fichero de las dimensiones antes de cargarlo en el mercado de datos.
La identificación de estas llaves consiste en una
búsqueda en el fichero de forma secuencial.
Cada llave del DWH debe ser una llave sustituta pues
debe ser flexible a los cambios en las descripciones y a las
condiciones anormales que se produzcan en la fuente de datos, es
por ello que se plantea que las llaves productoras pueden ser
reusadas y reformateadas.
La correspondencia entre las llaves productoras y los
valores de las dimensiones se lleva a cabo con una simple
revisión a través de los datos fuentes y los datos
de la tabla de dimensión.
Seguridad en el back room
La seguridad no es tan importante en el back room como
en el front room. Esto se debe a que el back room es una
actividad que tiene que ver con el desarrollo de aplicaciones y
son suficientes las reglas de seguridad estándar de los
sistemas. Sin embargo, debemos prestar atención al proceso de movimiento de
los datos ya que si éstos se van a mover a través
de la red aunque sea
interna, siempre se paga caro y se corren riesgos. Es
importante asegurarse de que se está utilizando un
utilitario de transferencia de ficheros que use un protocolo
seguro.
Otro aspecto a tener en cuenta en esta área es
determinar quién va a tener accesos de administración al servidor de DWH y al
software. Con
respecto a este tema, Kimball [3] plantea que se ven situaciones
donde no hay uno en el equipo que tenga privilegios de administración y otros casos, donde todo el
mundo tiene acceso a todo. Ninguna de las dos es la correcta,
porque en el primer caso si sucede una situación anormal
en la máquina donde está el DWH, se necesitan
privilegios de administración para resetearla y reiniciar
todo de nuevo. Con respecto al segundo caso, lo general es no
darle acceso a todo el mundo pues el servidor de DWH debe estar
estrictamente controlado y solo se otorgan privilegios de
administración a algunos miembros del equipo de
DWH.
El concepto de DWH está teniendo una gran
aplicación en la actualidad para el desarrollo de las
empresas, como almacén de datos. Sus objetivos incluyen la
reducción de los costes de almacenamiento y una mayor
velocidad de
respuesta frente a las consultas de los usuarios. Estos pueden
ahora analizar y realizar preguntas sobre años, más
que sobre meses de información.
Para diseñar una buena arquitectura de DWH es
necesario como primer paso conocer bien los requerimientos del
negocio y hacer un estudio profundo de las fuentes externas que
nos van a suministrar los datos. Además, hacer un buen
diseño del área de transformación de datos,
cuáles son las transformaciones que se van a realizar y
cómo se va a implementar el modelo dimensional con sus
tablas de hechos y de dimensiones es el segundo paso a
seguir.
Resumiendo los beneficios de la arquitectura del DWH
:
- Provee un esquema de organización – cuáles son
los componentes que la forman, cómo ellos se
interrelacionan, quién es el dueño de cada parte
y cuáles son las prioridades. - Mejora la flexibilidad – permite que
rápidamente se añadan nuevas fuentes de
datos. - Desarrollo rápido y reuso – los
desarrolladores de DWH son más capaces de comprender el
proceso de DWH , los contenidos de las bases de datos y las
reglas del negocio más rápidamente. - Herramientas de comunicaciones – define y comunica la
dirección y el alcance de las
expectativas , identifica los roles y responsabilidades y
comunica los requerimientos al proveedor.
En general, podemos plantear que el Datawarehouse
representa una oportunidad para estrechar las relaciones de las
empresas con los clientes.
[1] Hadley L., "Developing a Data Warehouse
Architecture", extraido el 28 de febrero de 2003 de
http://www.users.qwest.net/~lauramh/resume
.
[2] Kimball R., " Build your DataWarehouse one piece at
a time" , Datawarehouse Designer, Octubre 2002. Extraido el 4 de
marzo del 2003 de http://www.iemagazine.com/021030
[3] Kimball R., "Is Data Staging Relational?" DBMS,
April 1998 . Extraido el 26 de febrero de 2003 de http://www.dbmsmag.com
[4] Kimball R., Laura Reeves, Margy Ross & Warren
Thornthwaite, The Data Warehouse Life Cycle Toolkit, New York :
John Wiley & Sons, 1998.
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
ANEXO # 2 ALMACEN DE DATOS – ESQUEMA DE
ESTRELLA
MODELO DIMENSIONAL
Para ver el gráfico seleccione la
opción "Descargar" del menú superior
Datos de la autora:
Dialys Nerely Pérez de Armas
Estudios realizados: Licenciada en Cibernética
Matemática