De Databases, Warehouses y otras hierbas

Hola,

Hoy es un día especial porque vamos a romper con la rutina y mis absurdas manías y maneras de profundizar en los problemas y vamos a cambiar de ámbito y qué mejor manera de hacerlo que contar con un invitado de lujo para colaborar con su conocimiento y visión.

Me enorgullece presentar hoy a Eider Gorrotxategi1, que nos hablará un poco sobre esas siglas que se han puesto tan de moda en los últimos tiempos: BI. Os dejo con ella. Que lo disfrutéis.

¿En qué se diferencian una Base de Datos y un Data Warehouse? ¿Por qué necesito un Data Warehouse, si ya tengo una Database? ¿No son lo mismo?

Sí, pero no.

Una Base de Datos es una colección de datos organizados para su almacenamiento, accesibilidad y recuperación. Existen varios tipos de bases de datos, pero en este post nos centraremos en bases de datos OLTP (On Line Transactional Processing).

Éstas se caracterizan por procesar un elevado número de transacciones cortas como INSERT, UPDATE, DELETE, etc. Es importante la rapidez de las querys, mantener la integridad de los datos en un entorno de acceso múltiple donde la efectividad se mide por el número de transacciones por segundo, y se almacenan principalmente datos actuales, garantizando estar "al día" basado en un modelo relacional. Unos entornos donde pueden aplicarse una Base de Datos de estas condiciones: contabilidad, ventas en un supermercado, administración…

¿Qué es un Data Warehouse? Es una Base de Datos diseñada para facilitar el análisis, querys más complejas y optimizada para la presentación de reportes a a gran escala. Por lo que un Data Warehouse es una Base de Datos, pero una base de datos no tiene porqué ser un Data Warehouse, básicamente porque este último está ligado con un entorno más Bussiness Intelligence donde su filosofía es convertir datos en información e información en conocimiento para su posterior puesta en acción. Hacer que los analistas tengan una visión de los datos más relevantes de la compañía y anticiparse al mercado, a las necesidades del cliente…es decir, tener como una especie de visión de futuro.

Se dice que son bases de datos OLAP (On Line Analyctical Processing) cuando hay pocas transacciones, pero consultas más complejas, menos usuarios machacando la Database, un usuario común es un analista, el objetivo es el "data OUT", por lo general mantiene el histórico de los datos cuya precisión se mantiene en el tiempo, soporta grandes volúmenes de datos y normalmente el modelo de los datos es en estrella.

Es importante profundizar en cómo se construye un Data Warehouse. Esos datos que luego se convierten en información pueden venir de diferentes fuentes, que principalmente suelen ser bases de datos "tradicionales" OLTP, bases de datos no relacionales, ficheros planos de mala madre, que tienen que ser tratados para su posterior análisis. A ese proceso se le denomina ETL (Extract, Transform and Load).

  • Extraer: coger la información de diferentes fuentes, causando el mínimo daño en el sistema de origen.

  • Transformar: limpiar esos datos, separar, quedarte con lo que necesitas, depurar, corregir, aplicarles formatos, agrupación (lookup, merge), homogeneización…

  • Cargar: organizar y cargar la Base de Datos con esos nuevos datos transformados.

Existen un montón de herramientas ETL que facilitan este proceso, desde Informatica PowerCenter (muy usado en Banca y por empresas con pasta) hasta Talend Open Studio un proyecto Open Source que poco tiene que envidiar a "los grandes".

Vamos a por un ejemplo un poco tonto pero práctico para ver más o menos en qué se basa una ETL. Imaginemos que tengo una empresa totalmente innovadora de productos rurales.

Quiero añadir unas columnas (entre ellas fecha) a una tabla de mi Data Warehouse. Tengo los datos que necesito por una parte en ficheros planos CSV y quiero además cambiarle el formato al campo fecha a AAAA/MM/DD.

Lo primero, la herramienta tiene que estar en contacto tanto con el origen como con el destino, y en el medio del camino, realizara la transformación. En este caso, estará escuchando en un path el fichero CSV. Leerá el fichero localizando cada campo separado por las comas. (La separación puede estar delimitada por otro carácter como puede ser un pipe "|", una "&" o incluso ";", siempre y cuando después pueda ser interpretado correctamente).

Después cogerá la fecha que estaba en formato DD/MM/AAAA y lo cambiará a AAAA/MM/DD y por último se dispondrá a cargar este cambio junto con los otros campos de la tabla correspondientes. Para eso, tiene que estar en contacto con la Database, y la herramienta tiene que saber el nombre del host y el password, nombre del esquema y el nombre de la tabla entre otras cosas. Hay que describirle cual es el camino que tiene que seguir el dato paso a paso para que llegue a su destino.

El proceso es sencillo, una vez sepas cuales son los cambios que necesitas realizar al dato, el diseño del mapping es más fácil y después lo único que queda son las conexiones. Podemos decir que el fichero del origen no sufre ningún cambio, que el cambio se hace "en el camino" y que ahora tenemos datos mejorados en nuestra Data Warehouse. Cómo sacarle partido a esto ya, lo dejo en vuestra mano.

Espero que os haya parecido interesante la experiencia de traer a gente invitada a escribir sobre otros temas. Es posible que siga haciéndolo, convenciendo a gente técnica de mi entorno de colaborar por aquí aportando un poco más de variedad al blog.

Si tenéis alguna pregunta o comentario para eso está la sección inferior 😉

Un abrazo


  1. Eider es, a parte de otros millones de cosas maravillosas, la persona que me acompaña en mi vida y la persona para la que me gusta cocinar. Ingeniera de Telecomunicaciones. Su experiencia profesional siempre ha estado ligada a la explotación de datos a gran escala. Maniática de las fechas y los pequeños detalles desempeña su trabajo con la misma meticulosidad y precisión. Puedes encontrártela en internet escribiendo sobre lo que le gusta comer mientras me alegra la vida con su compañía (aquí).

Anuncios