Muchas veces a la hora de desarrollar un cuadro de mando con cualquier herramienta, lo primero que se nos viene a la cabeza es qué información quiero mostrar y como será visualizada, olvidando la parte de la estructura de datos, siendo ésta uno de los pilares sobre los que se apoyará nuestro proyecto Business Intelligence.
Con esto no queremos decir que haya que descuidar la parte de visualización de los datos, pensando en qué escenario nos movemos, ya que ésta forma en su totalidad la percepción que tendrá el usuario final sobre la calidad del cuadro de mandos que desarrollemos.
Puesto que lo primero que necesitamos para poder crear nuestro cuadro de mandos es tener los datos almacenados en alguna base de datos, Excel u otro origen, hay que pararse un tiempo a determinar qué forma tendrá la estructura de los datos ya que afectará directamente al desarrollo en diferentes ítems, ya sea en los tiempos de carga o la robustez de los datos, entre otros, que iremos citando a lo largo del artículo.
A nadie le gusta ver una amalgama de datos desperdigados, donde haya que pasar demasiado tiempo para averiguar cómo obtener un dato. Por ello, lo primero que hay que pensar para tener la estructura de datos adecuada es ¿qué datos necesito realmente? ¿Cuál será mi tabla de hechos donde tenga todos los datos principales de mi cuadro de mandos? ¿Qué dimensiones necesitaré? Una vez respondidas estas preguntas, podemos ir construyendo nuestras tablas de hechos y dimensiones solo con los datos que sean estrictamente necesarios. Aunque sea tentador poner datos extra por si acaso en un futuro se necesitara de ellos, hay que evitarlo y, si en el futuro necesitamos ese dato, lo incluiremos cuando sea necesario, pero no antes.
Otra parte importante del desarrollo es buscar la mejor velocidad para nuestro cuadro de mando. El tiempo de espera es tiempo perdido que podríamos estar dedicando a desarrollo y a ojos del usuario final, los altos tiempos de carga pueden llegar a ser tediosos o desesperantes. Para realizar una optimización del tiempo de carga del cuadro de mando hay que tener unas cuantas cosas en cuenta. La primera y la más sencilla es la que hemos nombrado en el punto anterior, definir correctamente qué datos necesitamos, tanto a nivel de filas como de columnas. Si vamos a mostrar únicamente los datos de este año y el anterior y no vamos a necesitar un histórico para nada, solo traeremos los datos últimos; esto es mucho mejor que realizar el filtrado en nuestra plataforma de desarrollo, ya que luego los tiempos de procesamiento de las fórmulas que utilicemos escalarán y se ralentizará a todos los niveles.
También si no necesitamos una columna no nos la traeremos ya que, si restamos, aunque sea una sola columna a la estructura de datos nos quedará una estructura de m * n-1 en vez de m * n y a valores elevados se nota mucho la diferencia.
Otra manera de optimizar los tiempos de carga es con la adecuación de los tipos de datos, ya que en ocasiones se pueden tomar como texto los datos que tenemos y a efectos de velocidad, los números enteros son más rápidos que los textos o los números decimales.
Relacionado con el primer punto, si tenemos los datos mejor estructurados y son más legibles, esto tendrá un impacto positivo sobre el desarrollo en sí. Tener localizados los datos y ser capaz de acceder a ellos de manera rápida y fácil hará que se reduzca el tiempo de desarrollo, sobre todo para proyectos grandes. Además, cuando hablamos de facilitar el desarrollo no solo nos referimos a empezar un proyecto desde cero, sino también a ampliar el proyecto en posteriores fases, añadiendo nueva información o simplemente para modificarlo y mantenerlo.
Puede que se dé por hecho que todos los datos de los que los disponemos son útiles y fiables, pero una mala estructura de datos puede afectar directamente a la fiabilidad de los datos que se encuentran en él. Si permitimos que los campos clave puedan repetirse, cuando deben ser únicos, puede generar duplicidades o incluso incoherencia en los datos. Un ejemplo claro es, si dejamos que un identificador de un elemento se pueda repetir y éste debiera ser único, podemos llegar a tener el mismo cliente dos veces o que para el mismo identificador haya dos clientes diferentes y esto posteriormente generará incoherencias en los datos o datos irreales, cuando lo que buscamos son datos precisos.
Una buena manera de cumplir los puntos anteriores es guardar todos los datos en un Data Warehouse (DWH). Con un DWH nos podemos asegurar que los puntos anteriores se cumplan, ya que en éste especificaremos lo que necesitamos, desechando lo que no se vaya a utilizar. Esto hará que se incremente la fiabilidad de los datos presentados, ya que solo traeremos lo estrictamente necesario para posteriormente manejar los datos de manera más eficiente. Además, se pueden traer de varios orígenes de datos para tenerlos todos en el mismo sistema de estructura de datos, por lo que añade versatilidad a nuestro proyecto.
Uno de los objetivos de los DWH es aumentar la velocidad de obtención de datos, sobre todo para bases de datos grandes, afectando muy positivamente a los tiempos de carga. También se puede mejorar incluso los DWH mediante cubos OLAP o tabulares, lo cual, hablaremos en otra ocasión.
Tal y como hemos ido desengranando en este artículo, una buena estructura de datos nos va a aportar un gran número de beneficios a varios niveles, tanto en el desarrollo del cuadro de mando como en el resultado final del mismo. Por lo que con buenas prácticas se puede dar un salto de calidad importante del producto y mejorar la eficiencia al realizarlo.