Business Intelligence
jueves, 21 de mayo de 2015

El segundo primer artículo de Business Intelligence fácil

¡Vuelvo que me gusta!

Buff, ¡y qué digo ahora después de dos años sin pasarme por aquí! ¿Aún quedará alguien que se acuerde de este blog abandonado de Business Intelligence?

He estado muy ocupado en los personal y en lo profesional. En lo personal, el Enano Número 1 ha aprendido a escribir, ha dado un beso a una niña y ya ha tenido que ir al dentista. El Enano Número 2 dejó la cuna, ya habla, y come con tenedor o cuchara sin ensuciar más allá de su espacio vital. A mi me han salido más canas, he adelgazado y engordado varias veces, y he aprendido a hacer memes (nivel básico).

En lo profesional he participado en un gran proyecto DWH y en varios pequeños. Mi proyecto empresarial sigue en marcha. Más vivo y más prometedor que nunca. Seguimos comprometidos en construir la plataforma de BI más potente y más fácil de utilizar del mercado. Tengo muchas cosas que contar, pero permitidme que no utilice este segundo primer post para hablar de mi libro. Ya tendremos tiempo de ello. Me comprometo a Os amenazo con escribir al menos un artículo semanal hasta final de año. Avisados estáis. :-)

Sirva esto como señal de que sigo vivo.

¿Y vosotros, queridos lectores, seguís ahí?

Categoría: Sobre el blog

Comentarios: Ver comentarios

miércoles, 24 de abril de 2013

Mejoras continuas en Crono Analytics

El pasado mes de marzo anunciamos la disponibilidad de una nueva versión Crono Analytics. En realidad, gracias al modelo de integración continua, sacamos actualizaciones y mejoras cada 2 semanas aproximadamente. Aunque solo cuando introducimos funcionalidades importantes aumentamos la versión y lo anunciamos en el blog de la empresa.

En “Business Intelligence fácil” intento manteneros informados aunque, como veis, no siempre lo consigo. Por este motivo, os animo a que os suscribáis también al blog de Crono Analytics (o, mejor, a su lista de distribución).

Hoy os quiero hablar de una funcionalidad nueva que denominamos “Reescritura avanzada de consulta”. O reescritura dimensional. Aquí intentamos explicar –con poco éxito, me temo- en que consiste: “Reescritura de consulta con Crono Analytics”.

Trataré ahora de explicarlo de otro modo. Imaginaos que tenéis un Datawarehouse con millones de registros en una sencilla “estrella”:

Modelo en estrella con una tabla de detalle

Con este modelo, evidentemente, si consultamos las ventas diarias de las tiendas de Barcelona la consulta generada será así:

SELECT
  LB_TIENDAS.POBLACION AS Poblacion,
  LB_TIENDAS.NOMBRE AS Tienda,
  LB_TIEMPO.FECHA AS Fecha,
  sum(LB_VENTAS.UNIDADES) AS Unidades
FROM LB_VENTAS
INNER JOIN LB_TIENDAS ON (LB_VENTAS.ID_TIENDA=LB_TIENDAS.ID_TIENDA)
INNER JOIN LB_TIEMPO ON (LB_VENTAS.FECHA=LB_TIEMPO.FECHA)
WHERE
  LB_TIEMPO.ANYO='2013'
  AND LB_TIENDAS.POBLACION='BARCELONA'
GROUP BY
  LB_TIENDAS.POBLACION,
  LB_TIENDAS.NOMBRE,
  LB_TIEMPO.FECHA

La consulta anterior es óptima ya que se realiza de acuerdo a su modelo en estrella. Este modelo funcionará sin problemas con millones de registros.

Sin embargo, con el paso del tiempo, se abrirán más tiendas, y se tendrá un catálogo de productos más extenso, y el datawarehouse contendrá más y más historia de datos. Los “millones de registros” iniciales se convertirán en decenas o cientos de millones de registros.

¿Seguirá funcionando igual de bien esa estrellita inicial? Seguramente no. Por lo menos, será necesario crear alguna tabla agregada.

La solución habitual –y recomendada- es crear una nueva tabla de ventas resumida (con sus respectivas dimensiones). Tal que así:

Modelo en estrella con una tabla agregada

Ahora, si consultamos las ventas mensuales de España, Crono Analytics generará esta consulta:

SELECT
  LB_POBLACIONES.POBLACION AS Poblacion,
  LB_POBLACIONES.PAIS AS Pais,
  LB_MESES.NOMBRE_MES AS Mes,
  sum(LB_VENTAS_AGREGADO1.UNIDADES) AS Unidades
FROM LB_VENTAS_AGREGADO1
INNER JOIN LB_POBLACIONES ON (LB_VENTAS_AGREGADO1.ID_POBLACION=LB_POBLACIONES.ID_POBLACION)
INNER JOIN LB_MESES ON (LB_VENTAS_AGREGADO1.ANYO=LB_MESES.ANYO AND LB_VENTAS_AGREGADO1.MES=LB_MESES.MES)
WHERE
  LB_POBLACIONES.PAIS='ESPAÑA'
  AND LB_MESES.ANYO='2013'
GROUP BY
  LB_POBLACIONES.POBLACION,
  LB_POBLACIONES.PAIS,
  LB_MESES.NOMBRE_MES

Con este nuevo modelo, las consultas agregadas utilizarán esta estrella, y tendrán buenos tiempos de respuesta, sea cual sea la consulta que realice el usuario…

Si conoces otras soluciones de BI, nada de esto te sorprenderá en exceso. ¿Qué es, entonces, lo novedoso en Crono Analytics? Varias cosas:

  • Configurar una nueva tabla agregada en el modelo semántico de Crono es trivial. En otras soluciones, es taaan costoso que es directamente inviable (recuerdo un universo de Business Objects con cientos de indicadores en la que nadie quería crear nuevos agregados por el costo de mantenimiento…). Desde IT preferíamos que alguna consulta fuesen un poco lenta, antes que arriesgarnos a tocar ese galimatías de @Aggrgate_Aware() con resultado incierto…
  • Crear una tabla agregada no impacta nada en las consultas existentes. Es decir, la primera consulta de este artículo seguirá funcionando exactamente igual, seguirá utilizando el modelo en estrella (sin agregar “joins” adicionales contra las tablas de poblaciones y meses).
  • Crono Analytics, por lo tanto, reescribe tanto las tablas de dimensiones como las tablas de hecho.

La gran virtud de esta funcionalidad es que encaja perfectamente con las mejores prácticas en entornos Business Intelligence y también con el paradigma de desarrollo ágil. Es decir:

  • Empezamos los proyectos creando las tablas detalladas. Nada más.
  • Si ya va rápido, ¡perfecto!. En cambio, si es necesario crear tablas agregadas, se crean sin problemas y se incorporan al metamodelo. (¡sin impactar negativamente a las consultas detalladas que ya iban bien inicialmente).
  • Si hacen falta crear dos o más tablas agregadas, se crean. Y todas las consultas, siempre, se hacen en estrella (si el modelo de datos lo permite).

Gracias a funcionalidades como ésta (entre muchas otras), la capa semántica de Crono Analytics es la más potente y flexible del mercado y permite que los usuarios tengan una verdadera visión de negocio de sus datos y un entorno ágil y fácil de utilizar.

Si quieres una demostración, o deseas más información, no dudes en contactar a info@crono.net.

También puedes “jugar” con la versión de evaluación.

Categoría: Productos

Comentarios: Ver comentarios

martes, 23 de abril de 2013

¿Qué aporta una solución de Business Intelligence?

AVISO: Este es un post invitado. No está escrito por mí,  de modo que no tiene por qué coincidir con mis puntos de vista o mis opiniones, pero me ha parecido interesante compartirlo con vosotros y de paso desempolvar el blog, que tengo algo desatendido últimamente.

El artículo lo escribe la compañera Rosa Becerril, Account Manager en Saima Solutions. Si os gusta el artículo, no dejéis de visitar su blog de Business Intelligence.

¿Qué aporta una solución de Business Intelligence?

Comparación enttre antes y después de implantar un sistema de BI.

Cualquier persona con cierto grado de responsabilidad en su empresa es conocedora de la ingente cantidad de datos con los que cuenta su compañía. Estos datos,  relevantes para el buen funcionamiento de la misma, son manejados, manipulados y traspasados de un compañero a otro, de unos departamentos a otros, a través de cientos de Excels, PDF o Words que cada uno de nosotros apilamos en nuestros PCs de forma local y que compartimos mediante email que se pierden en el olvido.

Gran parte de nuestro tiempo lo perdemos enfrentándonos a un maremágnum de datos que hemos de localizar, unir y verificar.

Hoy en día, tanto las multinacionales como las PYMES, cuentan en el mercado con soluciones de Business Intelligence que ayudan a resolver este problema, y facilitan el acceso a la información y por tanto a la toma de decisiones. Veamos algunos de los beneficios que aportan estas soluciones de Business Intelligence:

  • Facilita la recogida y validación diaria de la información: Todos los días el sistema carga los datos que cada departamento haya generado.
  • Posibilita el control y comunicación interdepartamental: La información agregada diariamente es traducida a lenguaje de negocio y se hace visible y  accesible a todos los miembros de la organización. Obviamente cada usuario tendrá acceso y visibilidad únicamente a la  información que necesita.
  • Ofrece información en tiempo real sobre el estado de la empresa: lo que nos permite tomar decisiones acertadas y en base a la realidad presente de la compañía.
  • Permite realizar simulaciones “What if”, pudiendo dar respuesta a preguntas como: ¿Qué necesitaré si consigo más clientes? ¿Qué ocurrirá si pierdo a mi mejor cliente? Esto nos permitirá adelantarnos a las posibles necesidades o problemáticas que el mercado nos plantee y nos facilitará la adopción de respuestas más agiles, rápidas y acertadas. Así, nos ahorramos sorpresas de última hora.
  • Facilita la toma de decisiones: dispondrás en todo momento de información actualizada.
  • Mejora de la calidad del dato al eliminar o reducir el tratamiento manualm de la información. No dependemos del factor humano para la recogida de la información, que se realiza de manera automática.
  • Permite valorar si la estrategia empresarial es la adecuada e introducir los cambios necesarios en función de los resultados: al disponer de información fiable, los cambios o necesidades del mercado serán afrontados y gestionados diariamente, lo que permite dar una respuesta rápida y altamente competitiva. Ahorro de costes.
  • Unión interdepartamental: toda la empresa irá en la misma dirección, hablará el  mismo lenguaje y dispondrá de la misma información.

Rosa Becerril

Saima Solutions

Categoría: Definiciones

Comentarios: Ver comentarios

miércoles, 13 de marzo de 2013

Una crítica al lenguaje SQL (parte 2)

En un artículo anterior comentaba que el lenguaje SQL era un excesivamente reiterativo, y ponía algunos ejemplos muy concretos:

  • Las mismas fórmulas y expresiones se repiten una y otra vez en las sentencias (en las columnas del SELECT, en los GROUP BY,…). Si la fórmula es compleja rápidamente se obtiene código difícil de mantener.
  • Los mismos JOINS se repiten en todas las sentencias. A pesar de que la relación entre las tablas es un conocimiento estático -propio del modelo de datos- debemos repetir las mismas relaciones PK-FK una y otra vez, una y otra vez, una y otra vez…
  • Operaciones entre filas. Utilizando SQL es muy sencillo hacer operaciones entre columnas (calcular el precio medio a partir del importe y las unidades, por ejemplo), pero es farragoso hacer operaciones entre filas (como comparar las ventas de este año respecto las del año anterior).

En aquella ocasión utilicé la estrella de FactResellerSales (de “Adventure Works DW”) para mostrar los ejemplos. Hoy, además, utilizaré las tablas de la estrella de “ventas de internet”:

Para el ejemplo de hoy, utilizaremos la estrella de FactIntenertSales

Operaciones entre distintas tablas de hecho

Una necesidad tan común como comparar las ventas respecto el presupuesto no es trivial resolverla con SQL. El lenguaje SQL es bueno agrupando, ordenando, y filtrando valores de un conjunto de datos (una tabla de hechos con sus tablas de dimensión, en concreto), pero si queremos comparar los valores 2 tablas de hecho, tendremos que hacer 2 consultas.

Por ejemplo, si queremos comparar o sumar las ventas de internet con las ventas en tiendas tendremos que escribir cosas así:

-- Ejemplo 5

WITH
isales1 AS (
  SELECT
    DimDate.CalendarYear AS CalendarYear,
    sum(isales.SalesAmount) AS ventasInternet
  FROM FactInternetSales isales
  INNER JOIN DimDate ON (isales.OrderDateKey=DimDate.DateKey)
  INNER JOIN DimCustomer ON (isales.CustomerKey=DimCustomer.CustomerKey)
  INNER JOIN DimGeography ON (DimCustomer.GeographyKey=DimGeography.GeographyKey)
  WHERE DimGeography.SpanishCountryRegionName='Francia'
  GROUP BY DimDate.CalendarYear
),
sales1 AS (
  SELECT
    DimDate.CalendarYear AS CalendarYear,
    sum(sales.SalesAmount) AS ventasReseller
  FROM FactResellerSales sales
  INNER JOIN DimReseller ON (sales.ResellerKey=DimReseller.ResellerKey)
  INNER JOIN DimGeography ON (DimReseller.GeographyKey=DimGeography.GeographyKey)
  INNER JOIN DimDate ON (sales.OrderDateKey=DimDate.DateKey)
  WHERE DimGeography.SpanishCountryRegionName='Francia'
  GROUP BY DimDate.CalendarYear
),
COMUN AS (
  SELECT DISTINCT CalendarYear FROM isales1
  UNION SELECT DISTINCT CalendarYear FROM sales1
)
SELECT
  COMUN.CalendarYear,
  isales1.ventasInternet AS ventasInternet,
  sales1.ventasReseller AS ventasReseller,
  coalesce(sales1.ventasReseller,0)+coalesce(isales1.ventasInternet,0) AS ventas
FROM COMUN
LEFT JOIN isales1 ON COMUN.CalendarYear=isales1.CalendarYear
LEFT JOIN sales1 ON COMUN.CalendarYear=sales1.CalendarYear

Por supuesto, en entornos Business Intelligence, estas necesidades no son excepcionales. Tanto los usuarios (desde sus herramientas de Query&Reporting) como los técnicos que crean y mantienen los procesos ETL de carga del Data Warehouse, hacen este tipo de consultas habitualmente (o no las saben hacer, y hacen cosas peores…).

La punta del iceberg

Tal vez las cosas que he comentado en este artículo te han parecido minucias o cosas inevitables. En mi opinión, son solo la punta del iceberg de un problema muy gordo.

He analizado solo las sentencias SELECT pero los mismos problemas, y de manera mucho más pronunciada, se repiten en las instrucciones de manipulación de la información (UPDATES, INSERTS y DELETES). Necesitaría un blog entero solo para hablar de ello… Piensa en el código necesario para hacer una carga de una dimensión SCD, por ejemplo…

En mi opinión, estas características del SQL son las que explican buena parte de los costes de desarrollo. Si el SQL fuera más imperativo, más legible, más fácil de escribir, el uso de herramientas ETL no estaría justificado, ya que los desarrollos serían mucho más fáciles.

Porque el SQL es como es, nacieron las herramientas de Query & Reporting, y nacieron posteriormente las herramientas ETL. Sin embargo, las herramientas ETL solo han cumplido parcialmente sus promesas. A pesar de su sofisticación, los procesos ETL siguen representando el 70% de los costes de implantación de un sistema Business Intelligence.

En otros ámbitos de la informática la evolución ha sido muy diferente. Los lenguajes han evolucionado muchísimo y han aparecido nuevos dialectos y sabores. Gracias a ello, un estudiante hoy en día puede hacer una aplicación en 2 tardes que hace 3 décadas hubiese necesitado un ejército de programadores de IBM… ¿Por qué la evolución del SQL ha sido tan limitada? No lo sé, pero sé que pagamos las consecuencias de ello…

Crono SQL

Como supongo que habrás notado, las sentencias SQL que aparecen en este artículo no las he escrito directamente. He utilizado el generador de consultas de Crono Analytics.

Si lees este blog, seguramente sepas que Crono Analytics es una solución de Business Intelligence fácil de usar. Al igual que todas las herramientas de BI, lo que hacemos es convertir las consultas de los usuarios al lenguaje SQL, pero nosotros tenemos un “truco”…. Internamente, Crono Analytics utiliza el lenguaje Crono SQL que resuelve las problemáticas que describo en este artículo. Hablaré de ello en la tercera y última parte de esta serie.

PD: Si te ha gustado este artículo, y no quieres perderte la finalización de esta serie, suscríbete al newsletter de Business Intelligence fácil.

Categoría: Definiciones

Comentarios: Ver comentarios