El Cedazo

En la entrada anterior os hablé de los antecedentes que nos llevaron algún tiempo después a los Data Warehouses; esa entrada acabó con la llegada al mercado de esas nuevas máquinas de proceso masivo en paralelo, casi todas con un cierto sabor de UNIX, que, herederas de los superordenadores de las décadas anteriores, comenzaron a ser ofrecidas al mercado a mediados de los noventa.

Como no había tanto mercado para tantísimo superordenador entre Agencias Sí Gubernamentales, Universidades y Fábricas de Armamento Vario (sus clientes habituales), los fabricantes buscaron un nuevo nicho de mercado donde colocar tanta máquina con decenas de procesadores… Y este hecho coincidió en el tiempo con la creciente necesidad, entre tantas empresas comerciales, de contemplar su información de negocio de forma distinta a la que siempre habían usado: la transaccional.

La evolución de los Sistemas, y la creciente competencia en el mercado, hacía que cada vez más fuera necesario eliminar trabas a los usuarios en sus consultas de la información procedente del negocio, capturada por los Sistemas Operacionales normales de la Compañía, pero que antes sólo se podía ver de forma agregada, por ejemplo: Ventas totales en el mes (sí, pero ¿cómo se distribuyen por negocios, o por tipo de sucursal…?), Impagados totales en el trimestre (vale, pero ¿qué tipología de cliente impaga más, solteros o casados; jóvenes o mayores…?), etc.

De acuerdo, se vislumbraba que la solución vendría de la mano de esas nuevas máquinas con múltiples procesadores y coste más asequible que un mainframe, pero… ¿cómo conseguimos organizar un Sistema de estos para poder dar el servicio que necesitan las empresas? Porque con tener un hardware potencialmente poderoso no basta, hay que tener además un software que permita este acceso de forma cómoda y eficiente… y de eso aún no había a principios de los noventa, aunque pronto iba a cambiar la cosa… Llegaba el Data Warehouse para solucionarnos la vida… y aligerar la cartera de los clientes.

Como la serie tiene ya un cierto número de capítulos, cerca de la veintena, aquí os dejo el enlace donde hallaréis una cómoda forma de llegar a cada uno ellos.

Efectivamente, los fabricantes de máquinas con varios procesadores y habilidad para realizar los procesos en paralelo (cuyo número, además, había crecido bastante en los últimos años 80 y primeros noventa; me refiero aquí al número de modelos y también al número de procesadores) se volvieron hacia el mercado de las empresas, para intentar colocar sus productos, en vista de que su mercado tradicional ya no daba más abasto.

Había que crear un nicho que no existía antes. Así que lo primero que hubo que realizar fue una definición formal de qué era y para qué servía esa cosa nueva; las empresas tenían una necesidad de acceder a su información de negocio sin cortapisas, pero no estaba claro cómo se podría aprovechar la gran potencia teórica de estos sistemas para obtener resultados tangibles.

En una palabra, había que estructurar el mensaje comercial para convencer a las empresas de que les sería muy útil gastarse una fortuna en un nuevo gran sistema, probablemente incompatible con todos los que tenía ya instalados. Era un trabajo para los especialistas de marketing de los grandes fabricantes… Y estos hicieron su trabajo, ya lo creo que lo hicieron…

Un Data Warehouse, como un cubo de Rubik

El resultado fue el concepto de Data Warehouse, allá por los años 93-94 del siglo pasado.

Se habían hecho ya ciertos pinitos en los años 80, sobre todo los de una pequeña compañía californiana llamada Teradata, pionera absoluta en el concepto de máquina paralela dedicada exclusivamente a la resolución de consultas.

Teradata diseñó un Sistema dedicado, donde la clave era su método de interconexión entre procesadores, de nombre YNET, que comunica los diferentes servidores (de nombre AMP, de Access Module Proccessor, equipado cada uno de ellos con un procesador Intel x86), cada uno de ellos con su propia memoria RAM y su propio disco. Es decir, toda comunicación entre nodos se hacía utilizando el bus (el YNET) así llamado por tener forma de Y, que conectaba dos nodos con uno de jerarquía superior, dando lugar a un interconexionado de nodos en forma de árbol binario.

Vale, ya tenían el hardware; pero ¿cómo se gestionaba todo esto para hacerlo realmente eficaz en consultas? El Sistema Operativo de Teradata estaba basado en UNIX System V, modificado para gestionar el paralelismo, pero la clave estaba en su Base de Datos. Ya en 1984, la Base de Datos que llevaba incluida Teradata era Relacional… cuando ¡hasta el año siguiente no estuvo DB2 en el mercado! (aunque sí que estuviera ya en el mercado su antecesor, SQL/DS, para el Sistema Operativo DOS/VSE).

Ya sabéis que al principio de la vida relacional, hubo muchas reticencias acerca de su rendimiento… y sin embargo los ingenieros de Teradata se dieron cuenta de algo que luego resultó evidente: Las Bases de Datos Relacionales son perfectas para paralelizar accesos, mucho más que las jerárquicas, desde luego.

Diagrama de YNET de Teradata

A la derecha tenemos un esquema de la arquitectura usada por Teradata: su famoso bus YNET (por cierto, una arquitectura del tipo “shared nothing”). Explicaré su funcionamiento con un sencillo ejemplo:

Tenemos un cierto Sistema de Información que tiene, digamos, diez Tablas relacionales, donde la clave primaria de acceso es la misma para cada una de ellas (por ejemplo, el número de cuenta), y tenemos un sistema como el del diagrama, con cuatro nodos, de nombres A, B, C y D. Definimos una clave de particionamiento al Gestor de la Base de Datos, informándole, por ejemplo, de que los números de cuenta que empiezan ente 00 y 24 están en el nodo A; los que empiezan entre 25 y 49, en el nodo B; si empiezan entre 50 y 74, en el C; y si empiezan entre 75 y 99, en el D. Esto es sólo un ejemplo, en realidad lo que hay que procurar es que el volumen de la información asignada a cada nodo sea similar entre ellos, para mantener compensado el Sistema. Si en nuestro caso tenemos muchas cuentas que empiezan por 0 ó 1, y pocas por 8 ó 9, cosa que es lo que suele pasar en los sistemas reales, la clave de particionamiento definida de esta manera sería mala, malísima de la muerte…

También podemos informar al Gestor que utilice un algoritmo de hashing para que distribuya él solo, según sus sofisticados criterios, la información entre los nodos (sólo para que me entendáis, esta función hash podría ser algo tan simple como dividir el número de cuenta entre 4, que es el número de nodos que tenemos, y usar el resto de la división, de 0 a 3, para designar el nodo que le correspondería a esa cuenta).

Las peticiones (las queries) vienen del “Host Proccessor”, en aquel tiempo, casi exclusivamente un mainframe, en forma de un mandato SQL, que es recibido por el IFP (el nodo director). Aquí se compila la query, obteniendo el camino lógico para resolverla… que se envía a cada nodo de manera descendente, usando la YNET.

Teradata 5400H

En tiempo de carga masiva de la información, o ante una actualización, la lógica del programa director sabe de antemano a qué nodo enviar cada fila, de todas las tablas, dependiendo de su número de cuenta.

Sin embargo, éste es un Sistema diseñado para ser cargado una única vez, y luego consultado muchas, así que lo realmente importante es que ante una consulta (que, típicamente, llevará un where, quizá un par de joins o una subselect, algún count y un group by, etc, es decir, la típica consulta ad hoc que puede realizar un usuario final buscando información de negocio), cada nodo puede realizar su parte de la consulta, usando su propia memoria RAM, sobre estrictamente los datos que tiene almacenados en su propio disco. Resuelve joins, cuenta filas, agrupa los resultados… y cuando tiene la información preparada, se la remite de vuelta al nodo director, utilizando en este caso la red YNET de forma ascendente.

Obviamente, todos los nodos pueden funcionar simultáneamente, en paralelo, puesto que no necesitan información de ningún otro nodo para resolver su propia parte de query.

Cuando el nodo director ha recibido la información completa de todos los nodos, la consolida (sumando, agregando la información, etc, según el tipo de query de que se trate) y se la devuelve, por fin, al peticionario: al mainframe.

Aún asumiendo que cada nodo es sensiblemente más lento de lo que sería un buen mainframe para resolver cada parte de query, si disponemos de algunas decenas o algunos centenares de nodos, cada cuál resolviendo su pequeña parte en paralelo… el rendimiento es incomparablemente mejor, y todo ello con un coste comparativamente reducido, puesto que los procesadores, la memoria RAM, el disco, todos los componentes son corrientes en el mercado y por tanto, baratos, menos el propio bus de conexión, el YNET, en el caso de Teradata, y el software, desde luego.

Teradata vendió bastantes sistemas en los años 80 y principio de los noventa, siendo su venta estrella el gigantesco (para la época) sistema que vendió a WalMart a fines de los ochenta, y que catapultó sus ventas. Otros fabricantes siguieron su estela, por ejemplo Red Brick (hoy parte de Informix, o sea, de IBM).

IBM SP2, de 1994

Todos los fabricantes de sistemas UNIX (Digital, Hewlett-Packard, IBM, Sun, etc), pusieron en el mercado a lo largo de la primera mitad de los noventa diversos sistemas multiprocesador. Con arquitecturas distintas, capacidades diferentes, pero todos ellos de buena calidad y precio razonable. En aquella época se gastó muchísima tinta en defender las incontestables ventajas y los espantosos inconvenientes de cada tipo de arquitectura, de cada solución, de cada marca… que si el MPP resolvía mejor las queries individuales, que si los clusters eran más adecuados para sistemas distribuidos, que si los SMP eran definitivamente mejores en todo tiempo y circunstancia…

Ahora sería el momento de escribir unos miles de palabras en explicaros todo este lío, las máquinas y arquitecturas que ofertaba cada fabricante, sus pros, sus contras, los argumentos de unos y de otros… pues se trataba de una discusión que, en realidad, era mediática y comercial, aunque disfrazada de puramente tecnológica. Que si IBM vendía el SP2, que si Sun el E10000, Hewlett-Packard el suyo y los demás también…

Pero es que, veréis, entonces ya me aburría soberanamente toda esta interminable discusión sobre si la arquitectura MPP solucionaría las cargas mixtas mejor que un cluster de SMP’s conectados vía satélite… Y si me aburría entonces, imaginaos cómo será ahora, quince años después…

Así que os voy a ahorrar el rollo (albricias, ¡por una vez! pensaréis…). Así que, esta vez, ésa es otra historia, y que la cuente otro…Y es que, como tantas veces he dicho ya, lo realmente importante de un Sistema Informático es su software… Pero eso sí, del software es complicado poner fotos, mientras que el hardware es taaan fotogénico…

Sun E10000 de 1997

Con la aparición de tanta máquina UNIX multiprocesador, todos los fabricantes de Bases de Datos Relacionales (Oracle, Sybase, Informix, DB2…) añadieron capacidades de proceso paralelo dentro de su motor, para aprovechar al máximo el paralelismo que permite la existencia de varios procesadores y diferentes arquitecturas de interconexión. La excepción era el DB2 del mainframe, que tenía capacidad de proceso paralelo desde siempre (de hecho, los mainframes de IBM son de arquitectura SMP, del tipo “shared all”, desde hacía muchos años, y DB2 aprovechaba desde el principio esta capacidad del hardware y del Sistema Operativo: el MVS.

Todas ellas sabían ya lo que estaba haciendo Teradata, que efectivamente tenía un hardware específico, pero donde la clave de su alto rendimiento radicaba en realidad en su software de acceso a la Base de Datos, así que todas buscaron sus propias soluciones para ser capaces de paralelizar todo lo posible el proceso (y, sobre todo, el acceso a los discos) para incrementar el rendimiento de cada query.

Atención: si recordáis los gráficos del rinconcito de la entrada anterior, utilizar paralelismos para resolver una query (que se supone que debe acceder a muchísimos datos, pues en otro caso cuesta más el collar que el perro…), penaliza, por el otro lado, el número máximo de usuarios a los que se puede dar servicio simultáneamente. Es evidente: si tenemos seis procesadores, y cuando hay que resolver una query la partimos en trocitos y la entregamos a cada procesador para que resuelva su parte, obtendremos el resultado de esa query particular mucho más rápido que si se encargara un solo procesador de ella… pero si cada query se resuelve en un solo procesador, podríamos resolver seis queries simultáneas sin que se molesten unas a otras… Naturalmente, esto no es exactamente así, como seguro que sabéis u os figuráis ya, pero creo que es suficiente para comprender el asunto.

Recapitulemos, pues: Mediados de los noventa. Tenemos Sistemas UNIX con capacidad multiprocesador y diversas arquitecturas para proceso paralelo. Existen Bases de Datos Relacionales con capacidad de procesar queries en paralelo. Las redes y los PC’s ya tienen capacidad suficiente como para mover una cierta cantidad de información por las redes. Sabemos dónde están los datos en nuestros Sistema Operacionales, sabemos diseñar y programar el software, tenemos experiencia en el uso de las Bases de Datos Relacionales…

O sea… Ya lo tenemos todo para montar un Sistema de Queries ad hoc (es decir, según al usuario de turno le de la real gana en cada momento), ¿no es cierto?

.

Pues eso exactamente es lo que aseguraban y vendían muchos fabricantes y consultores (que al fin y al cabo, viven de vender productos y proyectos, respectivamente, no de que lo que hayan vendido sirva en realidad para algo…). Había muchísimo ruido mediático, congresos, presentaciones, llamadas telefónicas de los comerciales de toda la vida… Mucha presión para los clientes, en definitiva.

Y hubo algunas empresas, no demasiadas todavía (los early adopters, como los llaman los consultores; nosotros los llamábamos los pringaos) que comenzaron sus proyectos de Data Warehouse alegremente. Hicieron costosos benchmarks entre Sistemas, pruebas exhaustivas, estudios comparativos rigurosísimos… por fin, compraron un gran servidor de varios procesadores y una base de datos (los que mejor salieron en las interminables pruebas… o los que decidieron a dedo los directores, que de todo hubo), y comenzaron el proyecto para crear, por fin, el Data Warehouse.

Técnicas de toda la vida...

¿Cómo se haría para construirlo? Yo lo vi; no me tocó a mí liderar uno de aquellos proto-data-warehouses de mediados de los noventa (a algunos pobres compañeros míos, sí), pero sí que sé cómo se atacaron: con las mismas armas y los mismos bagajes que se escribían las aplicaciones transaccionales de toda la vida (en definitiva, eso es lo que sabíamos hacer entonces, ¿no?, y no nos había ido tan mal). Es decir: Programación en Cobol para extraer los datos; Diseño de la Base de Datos en perfecta Tercera Forma Normal; Programación en C o C++ o Visual Basic o lo que fuera, generalmente con ODBC, para acceder al Data Warehouse desde el PC; un Análisis Funcional de los de siempre, y unas especificaciones cerradas y firmadas con sangre por los usuarios.

No era por ser gafe, pero ya entonces a mí me parecía que aquello no iba a funcionar bien (me acordaba de mi experiencia personal con el usuario de marketing en mi primer Banco, como os conté en la entrada anterior…). Incluso tuve el atrevimiento de llevar la contraria a mi jefe en Reuniones de Alto Copete, con lo que conseguí que no sólo no me hicieran caso, sino que me tildaran de aguafiestas… o peor. Pues, desgraciadamente para casi todo el mundo… tenía yo razón.

La gran mayoría, fracasaron. Estrepitosamente. Y los que al final consiguieron poner algo en marcha, fue con grandes retrasos, menor funcionalidad de la esperada y mucho mayor coste. Y es que no bastaba con tener un servidor, una base de datos, conocimientos en el desarrollo de proyectos tradicionales y buena voluntad. No. Hacía falta algo más.

Para poder montar un Data Warehouse con garantías de que funcione hay que atender a más cosas, y además utilizar métodos de diseño y programación muy distintos de los normalmente utilizados para los Sistemas de Información que habíamos desarrollado hasta entonces.

Bill Inmon

Pero, aunque algunos listillos como yo lo intuíamos (je, je), pocos sabían cómo atacar correctamente el problema, así que tampoco hay que cargar mucho las tintas en los pobres Jefes de Proyecto que se estrellaron (y perdieron sus jugosos bonos) aquellos años intentando montar un Data Warehouse como buenamente pudieron; sin embargo, había ya algún avanzado que estaba poniendo remedio…

Uno de los primeros que ayudó a formalizar el procedimiento de diseño y construcción de un Data Warehouse fue Bill Inmon, que de hecho fue quien acuñó y popularizó el término Data Warehouse.

Hacia 1992, Bill Inmon publicó su libro “Building the Data Warehouse”, en el que explicó por primera vez las características que debería tener un Sistema de este estilo, y que voy (¡cómo no!; si no lo hago, reviento) a resumiros a continuación:

1- Un Data Warehouse debe estar orientado al negocio (Business Oriented, en inglés, que queda mucho más bonito). Es decir, a diferencia de los Sistemas Transaccionales (los de toda la vida), que son Transaction Oriented, dado que, para ellos, lo importante es poder realizar transacciones de forma ágil y eficiente, aquí la información debe almacenarse según la ve y percibe el usuario final, es decir, tal y como está organizada en el negocio. Esto puede parecer una tontería, pero implica cambiar completamente no sólo el método de concepción y diseño, que es mucho, sino la propia forma de pensar de los Analistas, como iremos viendo si tenéis la paciencia de seguir leyendo.

Código de Hammurabi: Grabado en Piedra

2- Un Data Warehouse debe contener datos no volátiles, es decir, datos históricos, en el sentido de que no deben ser modificados nunca. Esto quiere decir que, por ejemplo, si hoy una Oficina realiza un pago de recibo contra una cuenta, pero mañana se dan cuenta de que en realidad el recibo estaba domiciliado en otra cuenta, sería factible, en el Sistema transaccional, anular la operación errónea como si nunca hubiera existido, borrándola literalmente de la Base de Datos (precisamente en el ejemplo que he puesto esto no es verdad, pero se entiende, ¿no?). Sin embargo, si esa operación errónea ha sido ya almacenada en el Data Warehouse, lo que habría que hacer sería insertar un nuevo registro con la misma operación con el importe negativo, dado que no debe jamás acceder al registro erróneo para eliminarle. O sea, el Data Warehouse es el reino de la INSERT, nunca de la UPDATE…

3- Un Data Warehouse debe estar diseñado para proporcionar información a sus usuarios, en forma de consultas, informes, etc, nunca para capturarla (ésta es precisamente la misión de los Sistemas Transaccionales, obviamente). Además, estas consultas que debe ser capaz de contestar, no son, en general, consultas planificadas: son queries ad hoc, es decir, no es posible predecir cuál es el tipo de pregunta que van a solicitar nuestros usuarios pasado mañana, de hecho ni ellos mismos lo saben, y, por consiguiente, no es posible ajustar a priori el diseño de la tabla, su particionamiento, sus índices, etc para ciertos accesos predeterminados, que es lo que ocurre en los Sistemas Transaccionales.

Mucho tiempo para unos, poco para otros...

4- Además, los tiempos de respuesta de un Data Warehouse deben ser “razonables”. Eso de razonables siempre es objeto de controversia, como se puede imaginar cualquiera. Los usuarios quieren que sean parecidos a los del Sistema Transaccional, o sea, poco menos que instantáneos, y los informáticos intentamos convencerles de que tres horas, o diez, para obtener ciertos datos que, de otro modo, nunca jamás podría conocer, es una bicoca. Ambos tenemos razón, naturalmente. Y esa es la misión del Jefe de Proyecto, cuando le dejan: unificar criterios, convencer a unos y otros y determinar qué tipo de query es importante que tarde poco y cuál otra no importa que esté para mañana…

5- Un Data Warehouse debe estar preparado para gestionar grandes volúmenes de información, algunos órdenes de magnitud superiores a los tamaños normales en los Sistemas Operacionales. Un ejemplo: una Compañía de Telecomunicaciones cualquiera de hoy en día puede registrar quizá ciento cincuenta o doscientos millones de llamadas al día… por no hablar de mensajes SMS, multimedia, tráfico de datos, etc, etc. A poco que esta compañía quiera guardar las llamadas del último año (en la actualidad se guarda bastante más que eso, incluso debido a imposiciones legales: la lucha contra el terrorismo y tal y tal), debe mantener en línea y accesibles por el usuario entre cincuenta y cien mil millones de llamadas (o sea: 100.000.000.000 filas en la tabla de llamadas). Vale que no es nada comparado por el número de átomos del Universo, pero son una barbaridad de filas para cualquier humilde tabla relacional… como ya no nos asusta casi ningún numerajo con muchos ceros, igual no os parecen tantas filas… pero yo os aseguro que es una tabla gigantesca, complicadísima de usar, gestionar y actualizar… por no decir recuperar, en caso de error. Y lo digo por experiencia, además. A mediados de los noventa (con volúmenes medios en las tablas muchísimo más pequeños que ahora, las cifras barajadas eran de quizá de sólo veinte mil millones de filas, unas cien o doscientas veces más que la tabla más grande de todas las que existían en la instalación en la época: realmente son muchos registros, palabrita).

6- Un Data Warehouse debe tener costes razonables (y aquí también hay desavenencias entre usuarios, a los que siempre les parece caro, e informáticos, que siempre opinan que es barato…). Pero no sólo debe ser razonable el coste del Sistema inicial (hardware y software básico, sobre todo la Base de Datos), sino el propio proceso de Diseño y Construcción, el Mantenimiento posterior, la formación a desarrolladores y, sobre todo, a usuarios, etc. En concreto, es vital asegurar que las modificaciones posteriores al modelo, para incluir nuevos datos, cambiar relaciones, añadir nuevas tablas, etc, sean baratitas de realizar, porque…

7- Un Data Warehouse evoluciona junto con los usuarios. ¡Tela marinera! Éste es justamente el tipo de Sistema de Información del que los informáticos de pro hemos estado huyendo durante muchos años: uno cuyo estado vital sea el de las modificaciones permanentes. Porque, conforme los usuarios van haciendo preguntas y obteniendo respuestas (aunque tarden horas), según van explotando la información contenida en el Sistema, también van aprendiendo y haciéndose nuevas preguntas, que muchas veces requieren incorporar cierta información nueva en la que no se había pensado en el Diseño inicial… y esto requiere un enorme agilidad para realizar modificaciones en el Diseño de las Tablas, sus índices, etc. Aplicar las técnicas usuales de modificación de tablas en Producción que se aplican en los entornos transaccionales (un procedimiento lento y burocrático que a todo buen informático nos gusta muchísimo) es una manera segura de certificar el fracaso del proyecto.

El boca-a-oreja fue el mejor método para aprender esos años

Todos nos leímos las teorías de Bill Inmon, las comentábamos entre nosotros, las criticábamos, las medio-usábamos… sólo unos años más tarde llegamos a aprender y comprender de verdad lo que significaban (aunque mi opinión es que ni siquiera el propio Bill Inmon sabía por entonces las implicaciones y consecuencias finales de sus mandamientos…).

Una de esas consecuencias es que el Sistema físico (el hardware y la base de datos) deben ser independientes y dedicados. Como vosotros, lectores, ya sabéis cómo son los rinconcitos de Macluskey que os expliqué en la entrada anterior, esto no es ninguna novedad para vosotros, pero en los noventa era muy normal que los responsables del Centro de Cálculo te dijeran: “tengo aquí un Sistema para hacer las facturas que está poco cargado, así que en este mismo Sistema ponemos el Data Warehouse…”. Error. Craso error… No sólo el Data Warehouse no iba: también la facturación dejaba de ir: la competencia por los recursos de la máquina era tal que ningún proceso acababa bien.

Yo viví un caso como ése, donde nuestro Cliente tenía su Sistema de Facturación en un Servidor UNIX de mediana potencia, que estaba muy descargado durante casi todo el mes, menos cuando se procesaba la facturación; entonces estaba a pleno rendimiento hasta que terminaba. El Cliente quería un Data Warehouse para consultar cositas de las facturas y tal, y se empeñó (contra nuestra opinión) en montarlo en esa máquina que, total, estaba tan tranquilita. Dos semanas después de montarla, hubo de adquirir urgentemente otro Servidor dedicado para el Data Warehouse: no sólo tardaban eones las queries, que, en el servidor de pruebas, con casi la misma carga que el real, iban bastante bien, sino que actualizar una factura se convirtió en un dolor de cabeza, y el proceso de facturación en sí ni os cuento: pasó de durar diez o doce horas, a durar tres o cuatro días… ¡Menos mal que lo habíamos avisado por activa, por pasiva y, sobre todo, por escrito, porque si no, nos empitona bien… Pero otros compañeros no tuvieron tanta suerte.

Y otra conclusión aún más inquietante de todo esto es que el equipo humano que debe desarrollar el Data Warehouse debe ser diferente del equipo que hace las aplicaciones transaccionales. ¡Tela marinera, de nuevo! El Sistema de trabajo, el método de Diseño, la forma de atacar los problemas es radicalmente diferente: por ejemplo, la mayoría de modificaciones al Data Warehouse implican modificaciones en el Diseño de las Tablas, sin tocar para nada la funcionalidad; esto es justamente lo contrario que en los Sistemas Operacionales, como seguro que sabéis. Y claro, es complicado pedir a una persona que se olvide olímpicamente de los conocimientos adquiridos durante años de trabajo para aprender un nuevo sistema, además bastante contraintuitivo, pues va en contra de muchas de las premisas atesoradas a lo largo de tantos años de profesión. Desde luego, a mí, que soy un genio (je, je) me costó asimilarlo…

Ralph Kimball

Y hablando de método de Diseño, fue Ralph Kimball quien, en 1997, fijó las bases de diseño del Modelo Dimensional que se debería usar al diseñar un Data Warehouse, en su artículo “A Dimensional Modeling Manifesto”.

El Modelo Dimensional usa la misma técnica de representación que el Modelo Entidad Relación original de Peter Chen, es decir, entidades, relaciones y atributos, lo normal, vaya. Lo que cambia radicalmente es la forma de entender los datos que deben ser modelados, la forma de organizarlos en tablas relacionales para construir un Data Warehouse efectivo.

En efecto, para construir un Data Warehouse, hay que grabarse a fuego en la mente que la información es multidimensional.

Ya. Y ¿esto qué quiere decir? Pues que de cara a su inclusión en un Data Warehouse, todos los datos, por raros que sean, son de dos, y sólo dos tipos: Métricas y Dimensiones.

Métricas (también llamadas indicadores) son aquellos datos que implican un valor relacionado con un Hecho de Negocio. Son siempre valores numéricos, susceptibles de ser sumados para obtener cualquier valor agregado, y responden a la pregunta: ¿Cuánto…? Ejemplos son: Importe del Adeudo en Cuenta, Importe de Venta, Unidades Vendidas, Minutos de una llamada telefónica, Importe del Siniestro, Número de Hijos…

Dimensiones son aquellos datos (generalmente códigos) que califican o hacen referencia a ese Hecho de Negocio, cómo se produjo y bajo qué circunstancias, y responden a las preguntas ¿Quién…?, ¿Cuándo…?, ¿Dónde…?, ¿Cómo…?, ¿Qué?, etc. Número de Cliente, Fecha, Código de Oficina, Clave de No-Sé-Qué, etc, son dimensiones.

Preguntaréis… ¿y qué es eso de un Hecho de Negocio? Pues cualquier Operación que tenga interés para el Negocio: Una llamada telefónica que hay que facturar, una venta de un artículo, un pago de recibo, un abono en cuenta… cualquier cosa que tenga reflejo contable en una compañía, y que sea relevante para el negocio. Y casi siempre un Hecho de Negocio tiene pocas métricas, y muchas dimensiones. Para que os deis cuenta de ello, usaré como ejemplo una factura muy sencillita de un conocido hipermercado.

Factura de un Hipermercado

En esta factura, los hechos de negocio son las líneas individuales de venta, es decir, cada uno de los artículos que han sido adquiridos en esa operación, en ese carro de la compra. La factura está toda llenita de números, pero muy pocos de ellos son métricas (o indicadores); veamos cuáles:

Para cada artículo, existen dos indicadores, y sólo dos: el Número de Artículos Adquiridos (en el epígrafe “Cantidad”) y el Precio de Venta al Público de dichos artículos (bajo el epígrafe “Importe”). Cuando el número de artículos adquirido es más de uno, especifica, para mayor claridad, el PVP unitario, que, en puridad, no es un indicador en sí mismo, sino que sirve para calcular el PVP final. Y ya no hay más indicadores en esta factura. Ni uno sólo. No los busquéis, que no hay más.

Todo lo demás, son dimensiones. Veamos: El tipo de IVA de cada artículo es el código (A, B, C) que va tras la cantidad (por cierto: ¿os dais cuenta que el Papel Higiénico y el Detergente pagan el tipo máximo de IVA en España, igual las cervezas? Muy curioso, parece que la limpieza sea considerada como un artículo de lujo…); El código del vendedor (bajo el epígrafe “Vendedor”) que es normalmente la Señorita que nos atiende en Caja; El tipo de terminal (supongo que es eso, bajo el epígrafe “T.T”), que indicará si la operación se hizo en un terminal de autoservicio, en una línea de cajas, o vete a saber qué cosa que seguro que para los responsables del hipermercado tiene interés; El Centro Comercial en que se produjo la Operación (y supongo que también el código de Empresa para algún tipo de control interno que desconozco, bajo el epígrafe EmpCent), deduzco que el “002” será el “código de empresa” y el “0988” apuntará a una determinada tienda; El código de Operación (bajo el epígrafe “Operac.”), en el que seguramente viene el número de terminal más un identificador secuencial de la operación (en banca se hace exactamente igual); La Fecha y Hora en que se produjo la Operación, bajo los epígrafes “Fecha” y “Hora”; y dos códigos más que no se me ocurre (¡a pesar de mi enorme experiencia, je, je!) qué pueden indicar, pero que seguro que algún valor tienen. Por fin; tras el Total Compra (que no es más que la suma de los importes de los artículos), aparece una nueva dimensión: La Forma de Pago (en este caso “En Efectivo”; si hubiera sido con tarjeta de crédito, aparecería su número, y la indicación “con tarjeta de crédito” de débito, etc.

Por cierto, el Total de la Operación, el TOTAL COMPRA, no es una métrica básica, sino una métrica derivada, obtenido por suma de los diferentes artículos adquiridos en la misma operación. Métricas derivadas hay muchas: IVA de cada artículo (el tipo de IVA aplicado al PVP), porcentajes de participación (cuánto representa la venta de la región de Asturias respecto del total nacional), de variación (incremento de ventas entre un trimestre respecto el mismo trimestre del año anterior), de consolidación (ventas agregadas de las Secciones de Limpieza y Perfumería, por ejemplo), y muchos más tipos que seguro que se os ocurren.

En esa factura hay más dimensiones que no aparecen físicamente en la misma, pero que estar, están: por ejemplo, cada artículo lleva su código (el código de barras) que, aunque no es mostrado en la factura (en su lugar prefieren mostrar sólo el nombre del artículo), evidentemente sí es conocido por la tienda, y almacenado; este código asociará el producto a una determinada sección (Limpieza, Ultramarinos, Congelados, etc), tendrá un determinado Proveedor, que a su vez será de una cierta región o país, y que repondrá la mercancía vendida de una determinada manera (por pedido, automáticamente, por venta, etc). El vendedor estará asignado a un determinado Centro Comercial y Departamento, tendrá una cierta categoría laboral, un determinado tipo de contrato… Los terminales de tal tipo serán de una cierta marca y modelo, y tendrán una cierta historia de averías, de uso, etc. Y así con todo.

Bien, lo importante es que todos estos Hechos de Negocio representan una imagen del negocio completo de la Compañía. Es decir, si agrupamos todos los Hechos de Negocio individuales (las operaciones de venta, las devoluciones, los descuentos… todos), en una sola tabla, que llamaremos la Tabla de Hechos (Fact Table, en inglés) y mantenemos un periodo temporal importante (dependiendo del negocio, un año, dos, tres… o toda la vida), por mera acumulación de sus indicadores podremos conocer cualquier información relacionada con el Negocio de la Compañía sobre cualquier ámbito dimensional.

Parece una obviedad, sí, pero es importantísimo, esta característica es la que da valor a los Data Warehouses: en las aplicaciones transaccionales de toda la vida se definían algunos valores acumulados representativos del negocio, se precalculaban (casi siempre, en batch) y se permitía consultarles a voluntad: por ejemplo: venta mensual por región, venta acumulada por sección y centro, venta en efectivo y con tarjeta de crédito, etc… Pero, ¿qué pasa si en un momento dado necesitábamos conocer el importe de venta en efectivo de un determinado centro entre ciertas horas de los fines de semana…? Pues que no teníamos la menor idea, ni siquiera la posibilidad de obtener la información como no fuera haciendo costosos programas específicos que se usarían para calcular el dato en el futuro, cuando por fin se pongan en marcha, porque el pasado muerto… muerto está, y el dato perdido no hay quien lo recupere.

.

¿Cómo se representa gráficamente esta realidad según el modelo dimensional definido por Kimball?

Pues mediante una representación en Estrella (Star Schema, en inglés) o, mejor aún, con una representación en Copo de Nieve (Snowflake Schema). En realidad es lo mismo, sólo que en el modelo en estrella las dimensiones son de únicamente un nivel, mientras que en el modelo en Copo de Nieve, las dimensiones pueden tener jerarquías, que es lo que ocurre en virtualmente todos los casos: una jerarquía dimensional representa subagrupaciones dentro de la dimensión; por ejemplo, un año tiene la buena costumbre de dividirse en doce meses, que a su vez se dividen en días, estos en horas, éstas en minutos, etc. Si se mantiene esa jerarquía, es posible comparar las ventas de los cinco primeros días de febrero de los últimos tres años, o las de los últimos sábados de junio, por franjas horarias, o las de ciertas secciones de Alimentación, por medio de pago… y muchas más que se les ocurrirán a los responsables del negocio.

En el centro del diagrama se encuentra siempre la Tabla de Hechos, que suele ser de gran tamaño. Y cuando digo gran tamaño, aquí sí que me refiero a GRAN TAMAÑO. Miles de millones de registros (o billones de registros, como dirían los americanos), en la gran mayoría de los casos. Y alrededor, los rayos de la estrella, o las hermosas formaciones fractales de los copos de nieve, las tablas dimensionales, muchísimo más pequeñas en tamaño, que explican cada uno de los Hechos de Negocio contenidos en la tabla gorda.

Aquí arriba tenemos un modelo en Copo de Nieve (reducidísimo) de una Compañía telefónica: los hechos de negocio son las llamadas, con unos pocos indicadores cada una (minutos y segundos de duración, precio, coste, y poco más…), mientras que alrededor habrá muchas dimensiones (en el caso de una Telco, fácilmente doce o quince), entre los que se han representado unas pocas: La Dimensión Temporal, con la Hora y el Día en que se produce la llamada; La Dimensión Cliente (lo que antes llamaban “El Abonado”), con la representación de su localización geográfica: aunque sería mucho más complejo de lo que aparece representado en la figura, algo así como Central Telefónica, Distrito Censal, Distrito Postal, Ciudad, Provincia, Comunidad Autónoma, País, Región, etc, pero es que además tras el Cliente aparecen muchísimas dimensiones más: sexo, estado civil, antigüedad como cliente, servicios contratados, actividad del cliente, etc; y La Dimensión Operador de Destino, donde se marca el Operador del teléfono que recibe la llamada (puede ser la misma compañía, u otra de la competencia). Hay muchas más dimensiones: Cliente de Destino (sólo si la llamada es a un Cliente de la misma Operadora), tipo de llamada, tipo de tarifa, tipo de central telefónica…

Sólo cuando por fin aprendimos esta forma novedosa de Comprender El Mundo Multidimensional fuimos capaces de construir Data Warehouses efectivos (o sea, que de verdad funcionaran), y esto ocurrió a partir de 1998 o así… aunque todavía hubo coletazos de espectaculares fracasos hasta bien entrados los dosmiles…

Y a ello ayudaron una serie de herramientas software que fueron, y siguen siendo, cruciales en la gestión y explotación de los Sistemas de Data Warehouse. No obstante, de ellas hablaré en la próxima entrada, si no tenéis inconveniente, porque ésta es ya lo suficientemente larga como para seguir dando el tostón…

Disfrutad de la vida, mientras podáis.

The Historia de un Viejo Informático. El Data Warehouse entró en nuestras vidas… para quedarse. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.