Por Ricardo Eíto Brun
Ricardo Eíto Brun, diplomado en Biblioteconomía y Documentación, es técnico de sistemas en la empresa Meta4 de Madrid.
Foto: CC By Tomàs Baiget
Uno de los principales problemas que afrontan las organizaciones es que la continua inversión en tecnologías informáticas y sistemas de procesamiento de datos no se corresponde con una mejora sustancial en la calidad y disponibilidad de datos críticos para la toma de decisiones. El problema se acentúa en las organizaciones con sistemas informáticos heterogéneos y a menudo incompatibles. En estos casos, aunque la información se encuentre registrada en el sistema, no podrá ser compartida ni utilizada por ninguna otra aplicación que no sea aquella en la que se registró inicialmente.
Si bien estas limitaciones pueden no tener importancia en los sistemas encargados de gestionar el funcionamiento diario de la empresa (sistemas transaccionales u operacionales), los procesos de toma de decisiones requieren grandes volúmenes de datos procedentes de distintas áreas funcionales. Y es aquí donde surge la necesidad de poner a disposición del analista una visión global y sintética de la actividad empresarial que salve las barreras entre los múltiples sistemas heterogéneos; y con ella, el concepto de data warehouse (DW) o almacén de datos.
La percepción más inmediata que recibimos al oír hablar de DW es la de una única base de datos situada en la red informacional de la empresa, donde cualquier usuario, a través de una plataforma cliente-servidor, puede acceder a un gran volumen de datos organizados de forma eficiente.
La idea que se encuentra detrás del DW no es nueva: John D. Porter y John J. Rome señalaron cómo a mediados de los 70 IBM trabajó en un sistema similar conocido como information factory o information refinery.
Sin embargo, el concepto no fue propuesto hasta 1990 por William Inmon, quien además formuló una definición ya clásica en la teoría de los sistemas de información.
El DW pretende solventar el problema de la integración de datos procedentes de los distintos sistemas transaccionales de la organización, salvando la distancia entre secuencias de proceso e intervalos de decisión (Andreu et al. [1990, 26-28]).
Una de las preguntas que surgen inmediatamente al tratar el tema del DW es el por qué ha transcurrido tanto tiempo antes de encontrar la solución a uno de los principales problemas afrontados por la gestión de sistemas de información (SI). De hecho, hasta hace poco menos de un año ningún fabricante ofrecía una solución integral para la construcción de un DW, por lo que los responsables de SI debían configurar su propio sistema recurriendo a programas de distintos fabricantes que permitiesen resolver objetivos puntuales y que no superasen las inversiones presupuestadas.
El problema radica en que DW, como veremos en el apartado siguiente, es una tecnología muy comprehensiva en la que se deben salvar complejas dificultades técnicas tanto a nivel de estructura lógica como de soporte físico. No en vano algunos autores, entre ellos Ken Orr, definen el DW como una arquitectura global del SI de la empresa, de la que los sistemas transaccionales y la colección de datos sumarizados que Inmon identificaba como DW serán tan sólo unos componentes.
Si seguimos la propuesta de Ken Orr, un DW quedaría configurado por una arquitectura en ocho niveles. En las siguientes líneas trataremos de sintetizar cómo funciona un DW, estableciendo un paralelismo con las designaciones propuestas por Orr para cada nivel.
- Nivel operacional
Inicialmente tomamos como punto de partida un conjunto de bases de datos, probablemente incompatibles, que registran los datos asociados con procesos de negocio bien definidos dentro del conjunto de actividades desempeñadas por la organización. Orr se refiere a estos sistemas como ‘nivel operacional’, o de ‘base de datos externa’.
- La base de datos central
Con una cierta periodicidad, v. g., cada 24 horas, cada uno de estos sistemas volcará los datos que ha registrado en una base de datos central: el Data Warehouse propiamente dicho.
Orr se refiere al DW como ‘nivel físico’, o ‘de DataWarehouse‘.
¿Qué tecnología de base de datos resulta más adecuada para implementar un DW? Gran parte del éxito logrado por los sistemas relacionales en la última década se cifra en su capacidad de gestionar transacciones de forma concurrente. Sin embargo, las características de las bases de datos relacionales no parecen ser las más acordes con los requerimientos de un sistema orientado a la toma de decisiones. Se abre así una línea de debate entre la mayor o menor conveniencia de unos u otros esquemas, aunque no debemos olvidar en ningún momento que el concepto de DW es totalmente independiente de cualquier modelo de base de datos.
A pesar de que no exista una vinculación a priori entre DW y ninguna tecnología en particular, los productores de sgbd (sistemas de gestión de bases de datos) multidimensionales se han lanzado al mercado del data warehousing con la convicción de que sus sistemas son los más apropiados para satisfacer las exigencias del concepto.
Los partidarios de la tecnología relacional argumentan que el análisis multidimensional puede implementarse sin ningún riesgo en un sistema relacional, con lo que además evitamos el principal problema de las bases de datos multidimensionales: su carácter propietario –es decir, dependiente de una marca concreta– y su dificultad de interactuar de forma abierta con otro tipo de aplicaciones para las que los principales productores de sgbd relacionales ya cuentan con interfaces disponibles.
En el caso de decidirnos por un sgbd multidimensional deberemos evaluar su capacidad buscando respuesta a las siguientes preguntas:
1) profundidad con que se lleva a cabo la sumarización de los datos;
2) capacidad del sistema de operar con la totalidad de permutaciones posibles entre dimensiones. Es decir, si nuestro esquema cuenta con 100 productos, 100 clientes y los datos se sumarizan cada quince días, el sistema debe ofrecer cabida a un mínimo de 240.000 registros-sumarizados;
3) número de dimensiones con que nos permite trabajar la base de datos;
4) posibilidad de añadir nuevas dimensiones sin que se resienta el esquema.
La tecnología relacional surgió a comienzos de los 70 con los estudios de Edgar F. Codd y Christopher J. Date. Este último definió una base de datos relacional como una «base de datos percibida por el usuario como una colección de relaciones normalizadas de diversos grados que varía con el tiempo». La normalización es un proceso que permite obtener un esquema de base de datos con un mínimo nivel de redundancia (el necesario para evitar cualquier pérdida de información). Como contrapartida, al interrogar la base de datos nos veremos obligados a proceder a complejas yunciones entre tablas. Una yunción consiste en generar una única tabla a partir de varias que comparten un atributo común (definido sobre un mismo dominio). Un concepto fundamental en la tecnología relacional es el de la ‘atomicidad’ de los datos o ‘valor escalar’, según el cual los valores de los atributos en una tabla deberán estar constituidos por las menores unidades semánticas de información, sin estructura interna. |
- Softwares para el acceso del usuario final
Uno de los principales objetivos del DW es que el usuario pueda trabajar con la información registrada en él sirviéndose de aplicaciones con las que ya se encuentra familiarizado, evitando el problema de la curva de aprendizaje. Las mejores opciones son las que eliminan la necesidad de conocer lenguajes de interrogación complejos como SQL.
Debe tenerse siempre presente que la productividad y rentabilización del DW depende de la facilidad con que el analista pueda acceder a la información.
El conjunto de software que actúa de interface entre el usuario y el DW ocuparía el ‘nivel de acceso a la información’ en la propuesta de Orr.
- Transferencia y homogeneización de datos
Hasta ahora no hemos hecho mención a las transformaciones que afectan a los datos cuando pasan de las bases de datos transaccionales al DW, y de éste al software de usuario final. Para que estas transformaciones sean posibles se necesita una serie de elementos lógicos que en el modelo de Orr ocupan los niveles de ‘plataforma de datos’, ‘de acceso a los datos’, ‘gestión de procesos’ y ‘nivel de metadatos’. Comprenderemos mejor el concepto de DW si nos fijamos en cómo fluye la información entre los componentes del almacén de datos:
En primer lugar, los datos registrados en los sistemas transaccionales se graban en el DW. Esto implica una duplicación, distinguiéndose entre:
- duplicación sincrónica en tiempo real;
- duplicación sincrónica con un mínimo desfase; y
- duplicación asíncrona, dependiendo del tiempo que se tarde en transferir al DW los datos registrados en las bases de datos operacionales.
Si los sistemas informáticos de la empresa son homogéneos, es decir, si no se necesita hacer ninguna transformación en los datos, existen numerosos productos de duplicación disponibles para los principales sgbd: Symmetric Replication, de Oracle 7.x, Informix OnLine, de Informix, o DataWarehouse, de Information Builders.
Para apreciar cómo funcionan los distintos tipos de softwares de transformación de datos recogemos un ejemplo propuesto por Joe Celko:Un centro de salud quiere analizar la utilización de los servicios sanitarios dependiendo del sexo de los pacientes. Los resultados se registrarán en una base de datos en la que se representan los valores del atributo sexo mediante los siguientes códigos: 0=desconocido, 1=hombre, 2=mujer y 9=propiedad inaplicable.
El problema surge cuando, en la situación más probable, se debe cargar en el DW datos procedentes de sistemas heterogéneos. En este caso, el administrador del DW cuenta con una serie de herramientas que a partir de un ‘macrolenguaje’ le permiten definir reglas de transformación para cada fuente de datos. Entre estas aplicaciones están Warehouse Manager, de Prism Solutions, que pretende lograr una total compatibilidad con el mayor número de sgbd existentes en el mercado, Extract, de Evolutionary Technology, o EDA/Copy Manager, de Information Builders.
Un mayor nivel de complejidad lo ofrecen las denominadas ‘herramientas de fregado de datos’ (data-scrubbing tools), que además de la transferencia y transformación de datos efectúan complejos análisis que permiten identificar relaciones lógicas entre datos. Dentro de estos sistemas encontramos Integrity, de Vality, o Enterprise Integrator Tool, de Apertus, que puede utilizarse de forma independiente o como interface con algunos de los sistemas descritos en el párrafo anterior: Extract, Warehouse Manager, etc.
En cualquiera de los casos anteriores, el objetivo de la integración de datos se cifra en obtener un esquema uniforme en el que a un mismo contenido informativo le corresponda una misma codificación.
- Abstracción de datos
Una vez que los datos procedentes de los distintos sistemas transaccionales han sido grabados e integrados en el DW, procederemos a su transformación en un formato que facilite el análisis para la toma de decisiones y ofrezca una visión global de la actividad de la empresa. Aquí distinguiremos tres técnicas de abstracción:
a) Desnormalización: consiste en el proceso inverso al que nos ha llevado a la obtención de un esquema normalizado. Si la normalización de bases de datos pretende minimizar las redundancias e inconsistencias evitando la pérdida de información, la desnormalización pretende reducir el número de yunciones entre tablas necesarias para obtener respuesta a determinadas ecuaciones de búsqueda;
b) Sumarización: en este caso procedemos a la agregación de datos operacionales según distintos criterios y niveles jerárquicos. Por ejemplo, podríamos sumarizar las ventas de un determinado tipo de productos semanal, mensual y trimestralmente, o semanal y mensualmente para los almacenes situados en una determinada división geográfica.
Estas sumarizaciones son los datos que suelen precisarse en el análisis estratégico, por lo que será de gran utilidad dotarlos de persistencia para así reducir los tiempos de respuesta del sistema.
c) Fragmentación: consiste en generar, a partir de una única tabla, múltiples tablas atendiendo a algún criterio de selección ‘horizontal’, v. g., a partir de la tabla de ventas anuales obtendríamos doce tablas dependiendo del mes en el que se registró la transacción.
Este procedimiento es el menos utilizado, ya que, aunque disminuye los tiempos de respuesta para algunas preguntas, para otras obliga a proceder a complejas uniones, necesitándose un conocimiento efectivo de la distribución tabular de datos que referencian una misma entidad o proceso.
Una vez se ha procedido a la abstracción de los datos extraídos de los sistemas transaccionales, éstos podrán eliminarse del DW a menos que su consulta sea tan frecuente que haga recomendable dotarlos de persistencia en el almacén de datos.
Es importante incidir en este aspecto, ya que una de las primeras impresiones que recibimos al oír hablar de DW es que entre éste y los sistemas transaccionales existe un gran nivel de redundancia. No mantendremos esta idea si consideramos que en el DW sólo registramos datos con valor para la toma de decisiones agregados en unos formatos que nunca encontraremos en el entorno operacional. Si el patrimonio informático de la organización está compuesto por sistemas heterogéneos, la existencia de un DW es la única solución para obtener una visión global de la actividad de la empresa.
Las bases de datos multidimensionales pretenden superar las limitaciones de los sistemas gestores de bases de datos (sgbd) relacionales en los procesos de análisis. Las posibilidades de estos productos para la sumarización y agregación (cláusulas sum, avg, group by, etc., de SQL) resultan muy limitadas para la obtención de resultados globales. La normalización dificulta una visión general de los datos, viéndonos obligados a generar más y más tablas virtuales para proceder a un análisis medianamente complejo.
Una base de datos multidimensional estructura la información en torno a las principales dimensiones que determinan el entorno de trabajo de la organización.
- Función de los metadatos
Pero para que sea posible la administración y gestión de un almacén de datos es imprescindible mantener un directorio sobre los distintos tipos de datos que circulan por la estructura informacional de la empresa, de forma que el usuario o administrador pueda acceder a ellos de forma transparente.
El directorio de metadatos de un DW puede considerarse como un superconjunto de los catálogos de sistema que encontramos en cualquier sgbd.
Dada la mayor complejidad de un DW, para que un directorio de metadatos sea realmente operativo deberá registrar información sobre:
- los sistemas departamentales de donde procede la información registrada en el DW;
- periodicidad con que se procede a la transferencia de datos entre sistemas, controlando cuál ha sido la última transferencia recibida en el DW desde cada uno de los sistemas operacionales;
- restricciones de integridad que deben cumplir los datos;
- reglas de duplicación de datos;
- métodos utilizados para la sumarización y agregación;
- períodos de retención de datos en el DW antes de proceder a su sumarización o eliminación definitiva.
El principal problema que se plantea al tratar la cuestión de los metadatos, y que ya se encuentra en vías de solución, es la inexistencia de formatos uniformes. Hasta el momento, cada aplicación o fabricante presenta distintas alternativas. En un entorno configurado a partir de módulos heterogéneos, como es el del DW, esta falta de coherencia puede generar serios problemas, por lo que las principales compañías comerciales dedicadas al data warehousing han creado el MetaData Council.
El objetivo de este organismo es promover una definición normalizada, de forma que los metadatos sólo deban ser definidos una vez, y sea posible su reutilización por los distintos módulos del sistema.
Inicialmente integraron el MetaData Council: Arbor Software, Business Objects, Cognos, Evolutionary Technology, Platinum Technology y Texas Instruments, a los que ya se han unido otros fabricantes.
Sin embargo, algunas empresas de software están trabajando en la definición de metadatos propietarios, como en el caso de Oracle, que parece mostrar reticencias a integrarse en el MetaData Council.
Sigue en:
https://www.scimagoepi.com/data-warehouses-para-gestion-de-la-informacion-parte-ii
—
Esta información se publicó en la revista Information World en Español (IWE), n. 48, octubre de 1996, pp. 22-24.
- Volver al índice de este número 48:
https://www.scimagoepi.com/information-world-en-espanol-iwe-numero-48-octubre-de-1996
- Volver a la página principal de Information World en Español (IWE):
https://www.scimagoepi.com/information-world-en-espanol-iwe