Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 2

En continuación a nuestro post anterior: 

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

En este post trataremos otro patrón a evitar al modelar una relación maestro/detalle (encabezado/detalle o header/line) en un modelo ROLAP.   Como bien se mencionó en el post anterior, muchas veces los diseñadores de un modelo analítico (OLAP) están mucho más familiarizado con el diseño de un modelo transaccional (OLTP) por lo cual instintivamente buscan aplicar las mismas técnicas y patrones de diseño olvidando que ambos enfoques tienen objetivos completamente distintos.  En el post anterior mencionamos el error de manejar el encabezado como una dimensión (por ejemplo  una factura en la que el encabezado de la factura es tratado como una dimensión).  En este caso  trataremos el error de manejar tanto el encabezado, como el detalle como fact tables como podemos ver en el siguiente diagrama:

(Los nombres de tablas y campos en este ejemplo no son importantes, lo importante es notar el diseño de 2 fact tables unidas por una tabla foránea)

En este caso, el encabezado ya no es una dimensión, sino una fact table a la cual están asociadas diversas dimensiones (por ejemplo: producto,cliente, sucursal ,fecha). El detalle es a su vez otra fact table relacionada con el encabezado a través de una llave foránea (por ejemplo el número de factura) y adicionalmente otras dimensiones.
Aunque este diseño  representa de manera precisa la relación jerárquica padre/hijo entre el encabezado y el detalle, tiene fallas importantes. Si  bien hemos mencionado antes, en un modelo analítico se busca facilidad de consumo  y tiempo ágil de respuesta , buscando almacenar la información  de manera que se tenga la menor cantidad de joins y cálculos posibles en tiempo de consulta, a costo de un mayor espacio en disco(esto varía en función del motor de base de datos y la tecnología de este, ya que hay motores columnares especializados para OLAP que manejan índices y bitmaps) y procesamiento en tiempo de ETL, asi como tiempo de desarrollo a los procesos de ETL, en este modelo esto no ha sido aplicado , y el poder analizar las métricas a nivel de detalle implica realizar joins con el encabezado  la cual es una tabla casi tan voluminosa (y con ritmo de crecimiento alto)  como la tabla de detalle, y luego realizar un segundo join a las dimensiones. De esta manera el plan de ejecución de la consulta involucra: tabla voluminosa -> tabla voluminosa -> tablas pequeñas(dimensionales).

Luego de ver el problema , y lo que este conlleva,  podemos tocar la solución al mismo, nuevamente esta solución conlleva un patrón de diseño que puede causar incomodidad al diseñador(arquitectos de datos, ingenieros de datos, etc) que está acostumbrado al modelado relacional de sistemas transaccionales pero que luego de absorberlo se verán los beneficios en la agilidad y performance en un sistema de distinto enfoque(analítico) .

La solución consiste en crear una única fact table, cuya granularidad es 1 registro  en el modelo dimensional, por cada registro del detalle en el modelo transaccional, las dimensiones asociadas al encabezado(o maestro) son asociadas a cada  registro de la fact table a través de llaves foráneas a las tablas dimensionales.  De esta forma  se evita el realizar joins enter 2 tablas voluminosas , y el tener que recorrer estas tablas para encontrar los valores distintos de cada dimensión, y así también se genera un modelo más intuitivo y entendible para usuarios de negocio , lo cual cumple con 2 de los objetivos fundamentales: facilidad y agilizad de consumo de información

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

Similar al anterior artículo: Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas  , el presente artículo esta enfocado a arquitectos e ingenieros de datos, específicamente aquellos trabajando en el diseño y construccion de un data warehouse o data mart  haciendo uso de modelado multidimensional.

En el artículo citado se mencionó que existen diferencias en los objetivos y enfoque de un modelo de datos para un sistema transaccional(OLTP) y un modelo de datos análitico( OLAP) y por lo tanto también existen diferencias en los patrones de diseño y las buenas practicas para ambos casos  encontrándose ocasiones en los que una buena practica en un enfoque es un "pecado" en el otro.

El problema esta en que en las universidades y cursos de bases de datos es muy poco tocado el tema de analíticos por lo cual las personas encargadas de realizar un diseño de este tipo, muchas veces desconocen los objetivos, patrones y buenas practicas y realizan el diseño como si se tratase de un modelo transaccional(enfoque que si es tratado a profundidad academicamente)  , muchos otros han aprendido el diseño de analíticos de manera básica a través de otras personas o bien por su cuenta , pero solo conociendo los patrones de diseño básicos por lo cual mezclan ambos mundos.

En el presente articulo atacaremos un error común y la manera recomendada de resolución del mismo.

En un modelo transaccional utilizando el modelo entidad-relación es muy común encontrarse con 2 tablas en relación de uno a muchos en una estructura llamada  "maestro/detalle" en la cual cada registro del maestro o encabezado contiene información  general que es compartida por cada uno de los registros "detalle" asociados.Ejemplos de esto son facturas en los que cada factura(maestro o encabezado)  tiene asociados varios productos(detalles)  o bien ordenes de mantenimiento de equipos en los que cada orden(maestro o encabezado) tiene asociados muchos equipos(detalle),en ambos casos los datos del maestro o encabezado son datos generales y que son compartidos por cada elemento del detalle(por ejemplo numero de factura u orden, o fecha de la operación) .En el mundo transaccional es correcto modelarlo de manera normalizada pensando en los objetivos de reducción de redundancia , facilidad de actualización de datos, integridad referencial  y reducción de consumo de espacio en disco y no olvidando que en este tipo de sistemas operativos, comúnmente un usuario accede y/o actualiza una transacción a la vez, por lo cual en estos sistemas el modelado se hace a través de la estructura mencionada de 2 tablas,1 tabla maestro o encabezado, asociada con una tabla de detalle. Por ejemplo el siguiente modelo de facturación con una tabla para almacenar cada factura y otra tabla de detalle donde se registra para cada factura, que productos fueron vendidos.

Este patrón es muy usado y recomendado para el mundo transaccional , mas no así en el mundo multidimensional donde comúnmente no se accede una sola transacción a la vez si no posiblemente miles y ademas buscamos agilidad, simplicidad , menor cantidad de enlaces(joins) y tiempos de respuesta mas eficientes. Lamentablemente este patrón es muy utilizado ya que representa de manera correcta las relaciones entre los datos y es la manera en la que los diseñadores de modelos de datos se sienten mas cómodos. Esto nos al primero de los 2 patrones a evitar. 

Replicar la tabla maestro(o encabezado) como una dimensión y el detalle como una fact table en el modelo multidimensional

El primer patrón a evitar consiste en prácticamente crear una copia de la tabla de encabezado, como una dimensión en el modelo multidimensional, y el detalle como una fact table. Aun que si es muy común y recomendado  tener una tabla  de detalle como base para  una fact table, es mala practica que esta fact table sea una copia fiel de la tabla detalle y la tabla de encabezado sea una dimensión . Ejemplo:

Hacerlo de esta forma hace que se pierdan muchos beneficios de un modelo multidimensional bien diseñado, como el uso de dimensiones centralizadas,integradas, únicas y compartidas entre diversos modelos(lo cual permite hacer un analisis drill across entre múltiples procesos de negocio) ya que la información contextual o descriptiva  estaría "incrustada" dentro de la dimensión de encabezado, o bien  a través de un doble enlace entre fact table->dimension encabezado -> Dimension descriptiva , lo cual como se menciono en el anterior post también es un patrón a evitar. Ejemplo(Como podemos ver esto ya nisiquiera tiene la famosa forma de estrella):

De esta forma se tendría una tabla dimensional que crece a un ritmo bastante elevado(similar al de la fact table) y un análisis de este proceso de negocio implicaría el acceso a 2 tablas voluminosas(en lugar de una tabla voluminosa y pequeñas tablas dimensionales) .Si se desea analizar solo la información contextual o descriptiva(por ejemplo: listado de clientes o sucursales) sería necesario recorrer toda la tabla(con posiblemente millones de registros) en vez de recorrer una única tabla pequeña, esto puede degradar el rendimiento y tiempo de respuesta. 

Además de esto el campo de enlace(o llave) entre ambas tablas, sería un campo incremental y único que no se repetiría en la fact table , lo cual haría que sea imposible utilizar técnicas de compresión (como por ejemplo compresion bytedict en amazon redshift) o indices bitmap(Sybase IQ) que si podrían ser utilizadas si se manejara como pequeñas dimensiones con pocos valores repetidos muchas veces.

En este post hemos hablado del primer patron a evitar para relaciones maestro detalle, en el siguiente post se explicara el segundo patrón ademas de presentarse un esquema de datos recomendado para  modelar estas relaciones de manera eficiente. Nuevamente estas no son recomendaciones o ideas generadas únicamente por mi persona, si no por los expertos en la materia y creadores del modelado multidimensional. 

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas

El actual articulo esta orientado a ingenieros y arquitectos de datos(principalmente para personas encargadas del diseño y/o construcción de data warehouse siguiendo un modelado multi-dimensional) por lo cual se asume y recomienda familiaridad con la materia.

Existen en la industria buenas prácticas , tips y patrones de diseño comprobadas a lo largo del tiempo y con muchos casos de éxito , pero de igual forma existen malas practicas, errores y acciones a evitar cuando se aborda la tarea de diseñar un modelo de datos para apoyar a la toma de decisiones .

Dentro de estos errores , es muy común el que se presenta en este articulo y también se presentará el método recomendado para manejarlo. Ojo, las ideas propuestas acá(y por los expertos de la industria) entran en conflicto con las buenas prácticas de diseño de modelos de datos que se enseñan religiosamente en universidades y cursos de bases de datos, por lo cual se recomienda terminar de leer el post antes de dejarlo a medias pensando que lo que en el se dice es incorrecto.

El error es: modelar estructuras y jerarquías normalizadas. 

A lo largo de mi experiencia me he encontrado con este error en múltiples ocasiones ,incluso siendo realizado por arquitectos de datos experimentados , pero a que se debe? Principalmente a que como se menciono , esta práctica se evangeliza y se trata religiosamente en universidades y cursos de bases de datos y comúnmente los arquitectos de datos incursionan en el diseño de un modelo de datos de toma de decisiones sin tener en cuenta las diferencias(incluso sin un entrenamiento adecuado) en el enfoque y objetivos de un modelo de datos transaccional(comúnmente relacional) y un modelo analítico(toma de decisiones, descubrimiento de patrones y conocimiento).

En un modelo transaccional , el modelo se realiza pensando en objetivos tales como: captura de información,reducción de redundancia, integridad referencial , disminución de espacio de almacenamiento y para esto se recurre comúnmente a un modelo entidad/ relación normalizado, en el cual se modelan entidades del mundo(o negocio) y las relaciones entre las mismas.

Por otra parte en un modelo analítico , el diseño se realiza con objetivos tales como: consumo de información,toma de decisiones, análisis de indicadores del negocio, facilidad de consumo y entendimiento por parte de usuarios no técnicos, velocidad de acceso a la información ,aplicar pocos o ningún calculo y formulas durante el consumo(durante el query, y hacerlo en el ETL) y que el query sea lo mas "limpio" posible  y es acá donde entra en conflicto el enfoque analítico con el transaccional  ,ya que en el modelo analítico no se modelan entidades y sus relaciones, si no procesos de negocio, las métricas generadas por el proceso  y el contexto o puntos de vista de análisis del proceso y sus métricas(dimensiones)  .En este caso es permitido y altamente RECOMENDADO el tener estructuras de datos redundantes , no normalizadas y sacrificar  la disminución de espacio de almacenamiento .

Entonces entrando en materia(y es acá donde los arquitectos de sistemas y datos encontraran difícil de digerir y aceptar el material)  y  viendo ejemplos reales del error y su solución  , manejaremos 2 situaciones comunes :

1. Modelado de productos y categorías.
2. Modelado de información geográfica(en este ejemplo estado y ciudad)

• Enfoque transaccional: En este enfoque se modelan entidades y sus relaciones,para el primer caso identificando 2 entidades : producto y categoría y la relación entre ambas(un producto pertenece a una categoría y en una categoría se agrupan muchos productos).. Para el segundo caso se identifican 2 entidades: estado y ciudad  y la relación entre ambas(una ciudad pertenece a un estado, un estado contiene muchas ciudades).  Para ambos casos esta es una relación de jerarquía , a nivel físico este diseño implicaría 2 tablas por jerarquía y una llave foránea como relación entre las mismas.A continuación se presenta un modelo ER simplificado(se ha dejado de lado otras entidades y otros atributos de las entidades mostradas con fines de ejemplo)

• Enfoque analítico(dimensional): En este enfoque se modelan procesos de negocio, las métricas generadas por los mismos, y el contexto(descripción,puntos de vista) llamado dimensión en el que se generan las métricas. Para estos 2 ejemplos en vez de 4 entidades(2 para información de producto y 2 para información geográfica) se tienen únicamente 2 dimensiones(seleccionando siempre el nivel mas granular o mas bajo en la jerarquía) , y cada dimensión contiene toda la información de la jerarquía representada , para estos 2 ejemplos , tendríamos que la dimensión de producto, tiene como atributo la categoría del mismo, y la dimensión de ciudad tiene como atributo el estado al que pertenece,esto genera redundancia y rompe reglas de normalizacion  ya que para este ejemplo la categoría se repetiría muchas veces(1 por cada producto en la categoría),pero como se mencionó esto es permitido y recomendado con fines de generar simplicidad de consumo(query fácil de construir) y tiempos de respuesta mas ágiles(query eficiente) ya que ni la base de datos, ni el usuario final debe realizar costosas uniones innecesarias(joins) entre múltiples tablas en la jerarquía. Algo que viene a la mente al arquitecto de datos acostumbrado a modelar de manera relacional , es que esto también genera  un mayor costo en disco pero se deben tomar 2 cosas en cuenta:
1. El mayor costo de disco es permitido y es el precio a pagar por la simplicidad y tiempo de consumo de datos.
2. Comúnmente los modelos analíticos son implementados sobre bases de datos columnares(como Amazon Redshift o SAP Sybase IQ), diseñadas con este tipo de modelado en mente y utilizando internamente estructuras como bitmaps(o indices bitmap) para almacenar una única vez cada valor diferente de la columna y acceder al valor a través del bitmap,logrando así una compresión significativa. Crear un modelo normalizado(y jerarquías con múltiples tablas) en un motor columnar, es desperdiciar y desaprovechar  las capacidades(Y la alta inversión económica!)   y enfoque del mismo.

          Podemos concluir entonces, que es recomendable no tener(o tener un mínimo) jerarquías de múltiples tablas(y las relacione entre ellas) y tener únicamente una tabla con el nivel mas bajo de la jerarquía y agregar el resto de datos de la jerarquía como atributos de la tabla,Y tener un único nivel de unión(de  fact table a la dimensión) aun que esto represente generar redundancia y romper normalizacion.

Esta recomendación no es algo generado por mi persona, lo recomiendan los expertos de la industria(incluso los creadores del modelado dimensional) como podemos ver en las siguientes referencias. Espero que esto sea de utilidad para generar mejores modelos analíticos.

Ver mistake #1

http://www.dataintegration.ninja/mistakes-bottom-up-datawarehouse-development-approach/

Ver rule#6

http://www.kimballgroup.com/2009/05/the-10-essential-rules-of-dimensional-modeling/

O bien, en el libro "The data warehouse toolkit", capitulo 8 ,pagina  398 ver : Mistake #8

Autor: Luis Leal

Predicción de ganancias en R

En este post se quiere dar una pequeña introducción a la predicción de las ganancias en ventas utilizando modelos de regresión lineal en R.

R es un lenguaje y ambiente  de programación para el análisis estadístico, es uno de los lenguajes mas utilizados para la investigación, con R podemos utilizar la data desde cualquier fuente de datos ya sea Excel, CSV, incluso conectarse con una base de datos y utilizarla para realizar este tipo de análisis, esta es una de las grandes ventajas con R ya que podemos utilizar la data cualquier forma que venga, manipularla y obtener resultados.

Los modelos de regresión lineal se basan en la relación entre una variable dependiente y una o mas variables independientes, los modelos de regresión lineal son utilizados para la predicción de los valores de la variable dependiente, se debe llegar a utilizar las variables dependientes correctas para tener un modelo mas preciso y llegar a tener una diferencia entre los valores predichos y la variable dependiente sea mínimo.

Los datos para realizar el ejemplo se obtuvieron de un csv que Pentaho brinda para hacer pruebas, este set de datos es un ejemplo de ventas de vehículos del año 2003 a inicios del 2005. En la data tenemos las columnas ORDERNUMBER, QUANTITYORDERED, PRICEEACH, ORDERLINENUMBER, SALES, STATUS, QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINE, MSRP, PRODUCTCODE, CUSTOMERNAME, CITY,  STATE, COUNTRY, PRODUCTLINEID, STATE_ID.

Para este post se realizo un script en R y se pretende demostrar como aplicar el modelo linear y predecir las ventas en este caso de vehículos, se agrego el link para descargar el ejemplo.

Si se quiere ver mas a fondo como se realizo este ejemplo, se puede descargar el código fuente, para ejecutarlo cargamos el script R  y ejecutamos la función :

   > predictSales()

 La funcionalidad de este script es con un modelo lineal describir la relación entre la ganancia y la información con la que se cuenta de los pedidos como por ejemplo la ciudad, fecha y el producto, y al final de la ejecución mostrar un gráfico que muestra las ganancias reales y las que genera el modelo. 

Al ejecutar el script se genera un gráfico con las ventas del año 2003 a inicios del 2005.

En este ejemplo se tomaron como variables independientes QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINEID, STATE_ID y como variable dependiente la ganancia. En R se puede generar un resumen del modelo con lo que podemos obtener valores como el error residual estándar, los grados de libertad, valos que nos indican que tan funcional es nuestro modelo e ir mejorando el modelo cambiando las variables dependientes para obtener un modelo mas eficiente. 

El error residual estándar es la diferencia entre los valores reales y los valores estimados de la regresión, en este caso se obtuvo un error residual estándar de 1,4077.55, este es un valor muy elevado por lo que se debe mejorar el modelo, a continuación se muestra la gráfica generada en R, en negro se muestra la ganancia obtenida de forma mensual y en rojo los valores estimados de la regresión linear. 

En la segunda parte de este post se explicara como mejorar el modelo para estar mas cerca de los valores reales y se estará prediciendo el numero de ordenes de un vehículo para ciertos estados, con esto se podrían tomar mejores decisiones para lograr mayores ganancias.

El código de este ejemplo se encuentra en Github. 

Watch Download

Muchas Gracias.

La importancia menospreciada de la aplicación de índices en un proyecto de BI/DWH

A diferencia de nuestros anteriores posts , este post no esta enfocado al analista de negocio o el tomador de desiciones que utiliza el data warehouse y el sistema o aplicaciones analiticas de inteligencia de negocios, si no que esta mas enfocado al equipo técnico detrás de un proyecto de este tipo(project managers,arquitectos de sistemas, desarrolladores de sistemas,administradores de sistemas y de bases de datos,ingenieros de datos,etc).

Todo aquel que haya tomado un curso de bases de datos, conoce la importancia de la apliacion de índices para mejorar el desempeño de una base de datos,pero la pregunta es , cuantas personas o equipos detrás de la construcción y mantenimiento de un sistema aplican lo aprendido en la teoría para mejorar el funcionamiento de un sistema real en su día a día? . Lamentablemente la respuesta es que muy pocas personas(o casi ninguna) lo hacen a pesar de que de manera académica se ve su importancia y los beneficios obtenidos, esto por muchas posibles razones,según mi experiencia y charlas con colegas ingenieros de sistemas, algunas de estas razones son:

• La constante presión y tiempos apretados para proyectos de este tipo obligan a que el equipo “funcione” y cumpla su objetivo, sin importar si lo hace de manera óptima y eficiente.
• Aun que la importancia de los indices es recalcada en los cursos, la teoría nunca se pone en práctica ya que los cursos universitarios se enfocan en un buen diseño de la base de datos pretendiendo cumplir con los requerimientos funcionales,sin dar importancia a el rendimiento del sistema.
• Muchas personas, no conocen la importancia(o incluso que es) de la aplicación de indices nisiquiera de manera teorica ya que el curso se enfoca en crear un buen diseño y sentencias y herramientas de implementacion y manipulación de ese diseño.
• Muchas veces el adminsitrador de bases de datos piensa que es tarea del desarrollador y el desarrollador piensa que es tarea del administrador de base de datos. En realidad es una tarea conjunta en donde ambos deberían de aportar , el desarrollador comunmente tiene un mayor conocimiento y detalle de la manera y frecuencia en que las aplicaciones acceden a la información y el administrador de base de datos conoce como esta realiza internamente estos accesos.
• Simplemente al equipo no le importa o es algo para lo que no se desea invertir esfuerzo.

En el ámbito de proyectos y sistemas de inteligencia de negocios y data warehouse, este problema se presenta aún con mas frecuencia a pesar de que debería de ser mas importante ya que uno de los objetivos de un sistema de Dwh es agilizar y minimizar el tiempo de acceso a la información, en este caso el problema se presenta debido a las razones ya mencionadas(agendas apretadas,desconocimiento del tema, mala planificación,indiferencia) y otras razones tales como:

• Se utiliza un motor de base de datos optimizado para sistemas analiticos(por ejemplo motorores de bases de datos columnares) y se tiene la falsa creencia o se escucha el falso mito, de que estos motores de base de datos, no necesitan(o incluso no poseen) indices. (Ver al final del post : Ejemplo Aplicado)
• Se tiene la falsa creencia ,de que al tener la información en un diseño optimizado para analisis(como un modelo estrella) se hace innecesario contar con indices ya que no hay manera de agilizar el acceso a la información.
• Nuevamente , mala planificación y no contar con tiempo en la agenda para realizar esto.

En mi experiencia trabajando para una consultora con expertise en BI/DWH , la aplicación de indices nunca estuvo en el plan del proyecto , y se contemplaba como una alternativa, hasta que el performance del sistema se veía degradado.

Según los expertos(y creadores originales) de las técnicas y patrones del modelado dimensional para sistemas de BI/DWH , el diseño de un plan de índices es tan importante, como el diseño del modelo dimensional ,el tiempo para esta actividad debe estar contemplado en el plan del proyecto y debe ser realizado posteriormente(al menos en una versión inicial) justo después de tener el diseño del modelo dimensional realizado y un perfilamiento inicial de la data realizado(para conocer cantidad de registros,tipos de datos , valores unicos en cada tabla). Para mayor información de esto , se puede consultar la metodología o ciclo de vida Kimball y el libro “The Data Warehouse Lifecycle Toolkit”

Ejemplo 

Como se mencionó, una de las razones por las cuales erróneamente no se aplican índices en un sistema de BI/DWH ,es que muchas veces se utiliza un motor de base de datos optimizado para analíticos, por ejemplo una base de datos columnar(como amazon Redshift o Sybase IQ) y se tiene la idea equivocada de que esto hace innecesaria la aplicación de índices, o incluso que el motor de base de datos no brinda esta característica.

En mi experiencia en multiples proyectos con motores de base de datos columnares ,esta fue una tarea menospreciada y olvidada en muchas ocasiones ,pero cuando se presento la necesidad de realizara, se obtuvieron beneficios destacables,por ejemplo para el motor de base de datos columnar Sybase IQ(al igual que la mayoría en el mercado) ofrece multiples tipos de indices y cada tipo se encuentra destinado a cierta tarea, según factores como:

• Tipo de dato
• Cardinalidad de valores en una tabla
• Es una columna utilizada para un join?
• Es una dimension o un indicador?

Para el caso de amazon redshift, el concepto de indice no aplica en el sentido convencional, pero este maneja diferentes conceptos tales como sortkeys,distribution keys y encoding. Que tipo de cada uno de estos aplicar depende mucho de la estructura , cardinalidad , uso(por ejemplo si es ROLAP o OLTP,para ROLAP si es dimension o fact table)  , como ejemplos tenemos:

• Para surrogate keys conviene usar encoding o compresion tipo delta.
• Para llaves foraneas(en una fact table) a dimensiones con cardinalidad menor a 255 valores, usar bytedict(equivalente a indices bitmap en Sybase IQ).

pero los beneficios pueden ser enormes, tanto en performance como en storage(lo cual se traduce en ahorro de dinero).

Referencias utiles

•   Para aprender mas sobre índices en general(para los motores de base de datos mas comunes) consultar:
  • el libro: “SQL Performance Explained” de Markus Winand
  • El sitio: http://use-the-index-luke.com/
    
• Para aprender mas sobre la metodología Kimball , y sus recomendaciones sobre el plan y aplicación de indices, consultar:
  • “The Data Warehouse Lyfecycle Toolkit”
  • “The Data Warehouse Toolkit”
• Para aprender mas sobre los diferentes tipos de indices y su aplicación en el motor SAP Sybase IQ, consultar mi siguiente post :)   

Un poco más allá de reportes

Cuando se escucha hablar sobre el BI (Business Intelligence) dentro de las empresas, es muy común a que se refieran a este como la sección que realiza los reportes de la empresa. Un departamento en el cual se le pide un reporte de forma periódica, lo vemos en una hoja de cálculo, se le pide a lo sumo una cuantas operaciones aritméticas, estadísticas y una gráfica de barras.

Es cierto que el departamento de BI puede realizar este tipo de requerimientos pero es solo una mínima parte del potencial que se puede llegar a tener un departamento de BI. Las empresas generan data de formas muy diferentes y de distinto índole, tanto como lo es en en el aspecto comercial sino también del funcionamiento en sí de la empresa. Pero la data en sí no representa mucho, el potencial se encuentra escondido en este mar de data y por eso es fundamental poder procesarla y poder obtener información, pero muchisimo mas importante es la interpretación que se le pueda dar.

Uno de los aspectos a tomar en cuenta y que se puede pensar que es algo lógico pero muchas veces no se le da la importancia necesaria es: la data. Es el corazón de todo, ya que de nada sirve tener definido los tipos de análisis que se realizarán, las herramientas más complejas y modernas que se encuentren disponibles en el mercado para la presentación, el último motor de base de datos en nuestro datawarehouse,  sino tenemos una data que valga la pena analizar. Se debe contar con una data limpia, confiable y certificada. Tenemos que tener reglas claras para el manejo de la data, datos nulos, el manejo de apropiado de texto. Cuando se maneja tablas dimensionales como por ejemplo en un modelo estrella tener las llaves subrogadas de forma apropiada, si se maneja una tabla de comportamiento en el tiempo (Slow change dimension) tener claro cuánto cambio en el registro vamos a tener, definiendo el detalle de cambio que queremos guardar. Se debe de contar con una data en la cual podamos realizar las operaciones y análisis con toda la certeza de que los valores que representa la data son los correctos, sin necesidad de preocuparnos por algún registro cuyo valor esté fuera de lo normal, la fuente de datos sea la correcta y no alguna temporal o emergente.

Es importante contar con suficiente data para analizar, ya que se si realizara análisis de comportamiento o análisis de series de tiempo no es posible realizar un análisis confiable con un set de datos pequeño en cuestión de historia guardada. Se debe contar data que cubran diferentes series de tiempo,  años, lustros, etc. para realmente encontrar patrones de comportamiento y poder realizar comparaciones respecto de alguna posicion del tiempo.

Ya con nuestras herramientas y la materia prima lista, nos podemos preguntar ¿qué esperamos de estos análisis? Dependiendo del negocio que se está analizando existen diferentes tipos de análisis, una empresa comercial tendria interes en conocer si sus promociones han tenido impacto en los consumidores de forma esporádica e instantánea o realmente han elevado las transacciones en cada consumidor, fue correcto el segmento de clientes que eligieron para dicha promoción dado las características de estos. Si la empresa está teniendo una disminución de clientes, qué características tienen estos, es posible plantear un plan de retención que sea lo suficientemente atractivo para los clientes. Para esto se cuentan con diferentes modelos análisis como análisis de regresión, árboles de decisión, redes neuronales, SVM, Deep Learning, entre otras; las cuales pueden llegar a tener diferentes objetivos como ser un análisis predictivo o un analisis de clasificacion.

Con estas herramientas podemos descubrir nueva formas de estrategias para  alimentar la toma de decisiones dentro del negocio de una forma más analitica con un respaldo matemático bastante sólido.

Con esto podemos tener un departamento de BI involucrado en el negocio y no solamente un departamento de reportería.