Datawarehouse
Base de datos corporativa que integra y depura información de una
o más fuentes distintas, para luego procesarla y analizarla desde varias
perspectivas y con gran velocidad de respuesta.
La creación de un
datawarehouse representa técnicamente en la mayoría de las ocasiones, el primer
paso para implantar una solución completa y fiable de Business Intelligence.
Datamart
Base de datos departamental, especializada en el almacenamiento de
los datos de un área de negocio específica.
Existen procesos ETL
(extracción, transformación y carga) que nutren los sistemas BI, tienen que
traducir de uno o varios sistemas operacionales normalizados e independientes a
un único sistema desnormalizado, cuyos datos estén completamente integrados.
Procesos ETL
El concepto ETL proviene de los
términos ingleses Extract, Transform y Load. Las herramientas ETL juegan un
papel principal en la creación de los data warehouses, de los que hemos hablado
anteriormente. Es además uno de los cuatro principales componentes por los que
está formada una solución completa de Business Intelligence; ETL, data
Warehouse, reporting y herramientas analíticas.
Arquitectura del Data Warehouse: áreas de datos del Almacén
de datos Corporativo
Cuando
diseñamos la arquitectura de un sistema de Data Warehouse nos hemos de plantear
los diferentes entornos por los que han de pasar los datos en su camino hacia
su Data mart o cubo de destino.
Dada la cantidad de
transformaciones que se han de realizar, y que normalmente el DWH, además de
cumplir su función de soporte a los requerimientos analíticos,
realiza una función de integración de datos que van a
conformar el Almacén Corporativo y que van a
tener que ser consultados también de la manera tradicional por los sistemas
operacionales, es muy recomendable crear diferentes áreas de datos en el camino
entre los sistemas origen y las herramientas OLAP.
Cada una de estas áreas se
distinguirá por las funciones que realiza, de qué manera se organizan los datos
en la misma, y a qué tipo de necesidad puede dar servicio. El área que se
encuentra ‘al final del camino’ es importante, pero no va a ser la única que
almacene los datos que van a explotar las herramientas de reporting.
Tampoco hay una convención
estándar sobre lo que abarca exactamente cada área, y la obligatoriedad de
utilizar cada una de ellas. Cada proyecto es un mundo, e influyen muchos
factores como la complejidad, el volumen de información del mismo, si realmente
se quiere utilizar el Data Warehouse como almacén corporativo o Sistema Maestro
de Datos, o si existen necesidades reales de soporte al reporting operacional.
Propuesta de
arquitectura que cada uno ha de adaptar a sus necesidades o simplemente a su
gusto en función de su experiencia.
Staging Area
Es un área temporal donde
se recogen los datos que se necesitan de los sistemas origen. Se recogen los
datos estrictamente necesarios para las cargas, y se aplica el mínimo de
transformaciones a los mismos. No se aplican restricciones de integridad ni se
utilizan claves, los datos se tratan como si las tablas fueran ficheros planos.
De esta manera se minimiza la afectación a los sistemas origen, la carga es lo
más rápida posible para minimizar la ventana horaria necesaria, y se reduce
también al mínimo la posibilidad de error. Una vez que los datos están
traspasados, el DWH se independiza de los sistemas origen hasta la siguiente
carga. Lo único que se suele añadir es algún campo que almacene la fecha de la
carga.
Obviamente estos datos no
van a dar servicio a ninguna aplicación de reporting, son datos temporales que
una vez hayan cumplido su función serán eliminados, de hecho en el esquema
lógico de la arquitectura muchas veces no aparece, ya que su función es
meramente operativa.
Hay quien considera que la
Staging Area abarca más de lo que he comentado, o incluso que engloba todo el
entorno donde se realizan los procesos de ETL.
ODS (Operational Data Store)
Es la que va a dar soporte
a los sistemas operacionales. Su modelo de datos sigue una estructura
relacional y normalizada, para que cualquier herramienta de reporting o sistema
operacional pueda consultar sus datos. Está dentro del Data Warehouse porque se
aprovecha el esfuerzo de integración que supone la creación del Almacén de
Datos Corporativo para poder atender también a necesidades operacionales, pero
no es obligatorio, y ni siquiera es algo específico del Business
Intelligence, los ODS ya existían
antes de que empezáramos a hablar de BI y de DWH.
No almacena datos
históricos, muestra la imagen del momento actual, aunque eso no significa que
no se puedan registrar los cambios.
Los datos del ODS se
recogen de la Stage Area, y aquí sí que se realizan transformaciones, limpieza
de datos y controles de integridad referencial para que los datos estén
perfectamente integrados en el modelo relacional normalizado.
Hay que tener en cuenta que
la actualización de los datos del ODS no va a ser instantánea, los cambios en los
datos de los sistemas origen no se verán reflejados hasta que finalice la carga
correspondiente. Es decir, que se irán actualizando los datos cada cierto
tiempo, cosa que hay que explicar a los usuarios, porque los informes que se
lancen contra el ODS casi nunca podrán estar tan ‘al minuto’ como los que
existan en el sistema origen. Lo que sí se puede hacer es definir una mayor
frecuencia de carga para el ODS que para el Almacén Corporativo. Si es
necesario, se puede refrescar el ODS cada 15 minutos, y el resto cada día, por
ejemplo.
Almacén de Datos Corporativo
El Almacén de Datos
Corporativo sí que contiene datos históricos, y está orientado a la explotación
analítica de la información que recoge. Las herramientas DSS o de reporting
analítico atacarán principalmente a los Data marts, pero también se pueden
realizar consultas directamente contra el Almacén de Datos Corporativo,
sobretodo cuando sea necesario mostrar a la vez información que se encuentre en
diferentes Datamarts.
En él se almacenan datos que
pueden provenir tanto de la Staging Area como del ODS. Si ya hemos realizado
procesos de transformación e integración en el ODS no los vamos a repetir para
pasar los mismos datos al Almacén Corporativo. Lo que no se pueda recoger desde
el ODS sí que habrá que ir a buscarlo a la Staging Area.
El esquema se parece al de
un modelo relacional normalizado, pero en él ya se aplican técnicas de
desnormalización. No debería contener un número excesivo de tablas ni de
relaciones ya que, por ejemplo, muchas relaciones jerárquicas que en un modelo
normalizado se implementarían con tablas separadas aquí ya deberían crearse en
una misma tabla, que después representará una dimensión. Otra particularidad es
que la mayoría de las tablas han de incorporar campos de fecha para controlar
la fecha de carga, la fecha en que se produce un hecho, o el periodo de validez
del registro.
Si el Data Warehouse no es
demasiado grande, o el nivel de exigencia no es muy elevado en cuanto a los
requerimientos ‘operacionales’, para simplificar la estructura se puede optar
por prescindir del ODS, y si es necesario adecuar el Almacén de Datos
Corporativo para servir a los dos tipos de reporting. En este caso, el área
resultante sería el DWH Corporativo, pero a veces también se le llama ODS.
Data marts
Y por fin llegamos a la
última área de datos, que es el lugar donde se crean los Data marts. Éstos se
obtienen a partir de la información recopilada en el área del Almacén
Corporativo. Cada Data Mart es como un subconjunto de este almacén, pero orientado
a un tema de análisis, normalmente asociado a un departamento de la empresa.
Los Data marts se diseñan
con estructura multidimensional, cada objeto de análisis es una tabla de hechos
enlazada con diversas tablas de dimensiones. Si se diseñan siguiendo el Modelo
en Estrella habrá prácticamente una tabla para cada dimensión, es la versión
más desnormalizada. Si se sigue un modelo de Copo de Nieve las tablas de
dimensiones estarán menos desnormalizadas y para cada dimensión se podrán
utilizar varias tablas enlazadas jerárquicamente.
Este área puede residir en
la misma base de datos que las demás si la herramienta de explotación es de
tipo ROLAP, o también puede crearse ya fuera de la BD, en la estructura de
datos propia que generan las aplicaciones de tipo MOLAP, más conocida como los
cubos multidimensionales.
El paso del área anterior
de datos a esta ha de ser bastante simple, cosa que además proporciona una
cierta independencia sobre el software que se utiliza para el reporting
analítico. Si por cualquier razón es necesario cambiar la herramienta de OLAP
tendría que hacer poco más que redefinir los metadatos y regenerar los cubos, y
si el cambio es entre dos de tipo ROLAP ni siquiera esto último sería
necesario.
Qué
es Data Mining?
En los últimos años se han acumulado enormes cantidades de datos en
todas las organizaciones, y esta tendencia continúa a un ritmo acelerado.
Esto es posible por el amplio uso de los sistemas computarizados,
nuevas técnicas de captura de datos, el empleo de códigos de barra, los
lectores de caracteres ópticos, las tarjetas magnéticas, entre otros, y por
el avance en la tecnología de almacenamiento y su consiguiente reducción de
costos. La disponibilidad de esos datos es un importante activo para
cualquier organización, en la medida en que puedan ser transformados en
información de interés, utilizando técnicas y métodos de Data Mining.
Data Mining, también referenciado como Descubrimiento del
Conocimiento en Bases de Datos (Knowledge Discovery in Databases o KDD), ha
sido definida como el proceso de extracción no trivial de información
implícita, previamente desconocida y potencialmente útil.
El crecimiento explosivo de las bases de datos, de Internet y el
empleo de técnicas y herramientas (que en forma automática y eficiente,
generan información a partir de los datos almacenados), permiten descubrir
patrones, relaciones y formular modelos. En particular, estas técnicas
han adquirido enorme importancia en áreas tales como estrategias de
marketing, soporte de decisiones, planeamiento financiero, análisis de datos
científicos, bioinformática, análisis de textos y de datos de la web.
Data Mining incluye áreas del conocimiento tales como Estadística,
Inteligencia Artificial (Machine Learning) y Bases de Datos. Se estima
que del análisis de esos datos pueden surgir ventajas competitivas o
novedosas soluciones a antiguos problemas. Data Mining y Knowledge
Discovery es un área de gran actividad a nivel académico, como lo demuestran
el gran número de eventos científicos relacionados, como así también laborales.
Existen al momento un sinnúmero de productos desarrollados por las
grandes compañías dedicadas al software y por nuevas compañías creadas al
efecto. La causa de esta actividad radica en la necesidad por parte de
diversas organizaciones de analizar sus datos por medios automáticos o
semiautomáticos, para la resolución de diversos problemas, tanto en el ámbito
empresarial como científico.
|
ODS (Operational Data Store)
Es la que va a dar soporte
a los sistemas operacionales. Su modelo de datos sigue una estructura
relacional y normalizada, para que cualquier herramienta de reporting o sistema
operacional pueda consultar sus datos. Está dentro del Data Warehouse porque se
aprovecha el esfuerzo de integración que supone la creación del Almacén de
Datos Corporativo para poder atender también a necesidades operacionales, pero
no es obligatorio, y ni siquiera es algo específico del Business
Intelligence, los ODS ya existían
antes de que empezáramos a hablar de BI y de DWH.
No almacena datos históricos,
muestra la imagen del momento actual, aunque eso no significa que no se puedan
registrar los cambios.
Los datos del ODS se
recogen de la Stage Area, y aquí sí que se realizan transformaciones, limpieza
de datos y controles de integridad referencial para que los datos estén
perfectamente integrados en el modelo relacional normalizado.
Hay que tener en cuenta que
la actualización de los datos del ODS no va a ser instantánea, los cambios en
los datos de los sistemas origen no se verán reflejados hasta que finalice la
carga correspondiente. Es decir, que se irán actualizando los datos cada cierto
tiempo, cosa que hay que explicar a los usuarios, porque los informes que se
lancen contra el ODS casi nunca podrán estar tan ‘al minuto’ como los que
existan en el sistema origen. Lo que sí se puede hacer es definir una mayor
frecuencia de carga para el ODS que para el Almacén Corporativo.
definiendo el dashboard, es cuando las personas que
tienen que tomar las decisiones se empiezan a hacer preguntas, a pensar en sus
posibles aplicaciones,… en definitiva, es cuando realmente empiezan a ‘tocar’
el resultado de nuestro trabajo como consultora y es cuando surgen los “¿Y si?”
y los “¿cómo podríamos…?”.
definiendo el dashboard, es cuando las personas que tienen
que tomar las decisiones se empiezan a hacer preguntas, a pensar en sus
posibles aplicaciones,… en definitiva, es cuando realmente empiezan a ‘tocar’
el resultado de nuestro trabajo como consultora y es cuando surgen los “¿Y si?”
y los “¿cómo podríamos…?”.
Toma de decisiones en base al dashboard:
1. Hecho: “La tasa de rebote de una landing page ha subido hasta el 40%”.
2. Origen: viendo las fuentes de tráfico de esta landing, vemos que ppc parece ser el origen de este
aumento. Dando un paso más vemos que una de las campañas de categoría de ppc en
Google ha aumentado su % CTR, el volumen de tráfico y su tasa de rebote de una
forma notable.
3. Consecuencias para el negocio: esto ha provocado que la tasa
de conversión de la landing
haya bajado hasta el 4,2%, lo que ha provocado una disminución de las ventas
del x%.
4. Recomendación: revisión de las campañas de categoría de ppc para corregir el error.
CMI Cuadro de Mando Integral
Herramienta de control empresarial que permite establecer y
monitorizar los objetivos de una empresa y de sus diferentes áreas. Es una
aplicación que ayuda a la compañía a expresar los objetivos e iniciativas
necesarias para cumplir con su estrategia, mostrando de forma continuada cuándo
la empresa y los empleados alcanzan los resultados definidos en su plan
estratégico.
Editor
Lechiguero
No hay comentarios:
Publicar un comentario