Inteligencia de Negocios

Este es un esquema un poco más complejo que el anterior ( Esquema Estrella ), su modelado es similar al de un copo de nieve:   Vemos que un copo de nieve tiene un centro que a su vez tiene relaciones con niveles superiores y estos niveles pueden tener más relaciones con niveles aún mayores. Lo que se tiene es una  tendencia a normalizar aun más los datos que en la topología en estrella porque las dimensiones tienen más de un nivel hacia arriba:   Podemos observar como la tabla de hechos tiene productos y los productos tienen unas características como la marca y la sub categoría, lo que hace que la dimensión producto de la tabla de hechos se tenga en más de una tabla.   Respecto a la topología en estrella, este esquema lo que nos permite es no tener tanta redundancia de datos en los registros y esto se traduce en menos datos para guardar, sin embargo son modelos más difíciles para el usuario si quieren realizar una consulta porque en el query deben poner mas j

Vamos a hablar acerca de uno de los modelamientos que se pueden utilizar actualmente. Es el mas utilizado de los modelos para realizar análisis en todo el tema de BI tradicional (Ya tenemos que pensar en BI no tradicional - BigData y BI en Memoria). Pensemos primero en una estrella: Se tiene algo central y conectamos los otros puntos o nodos, al igual que la imagen, para Data Warehouse en la Topología en Estrella no se cambia mucho este concepto.Lo que tenemos es una tabla de hechos que va en la mitad y a su alrededor se construyen todas sus dimensiones, algo como lo que se muestra en la imagen. Imagen Tomada desde Google, a su autor pido disculpas porque no encuentro nuevamente la imagen desde su sitio para referenciarlo.    Una de las características de este tipo de topología para estructurar nuestro Data Warehouse es que las dimensiones siempre tendrán una clave primaria y simple o por así decirlo de un único campo (Por lo general) y la tabla de hechos que es la ta

He leido un artículo bien interesante acerca de OBIEE en el blog de Manjunath RG ( obiapplications.blogspot.com ) en el que leí que OBIEE automáticamente elimina los espacios en blanco o extras que existe en un campo que son mostrados en los tableros de control de Answers. Lo interesante es que no solo aplica esto para los espacios al momento de presentarlos, sino que también lo hace en el momento de hacer filtros del estilo between. Veamos un ejemplo que nos pone el mismo Manjunath RG en su blog: A b    A b  A  b Las tres cadenas se convierten en: A b Las tres las pone iguales. Yo la verdad estoy de acuerdo con Manjunath en una parte en la que dice que se deben cotrolar este tipo de cosas desde el ETL, sin embargo esta funcionalidad de OBIEE es interesante porque puede permitir ver información que aparentemente debería ser igual y que por uno de estos espacios no lo este, sin embargo es importante que los desarrolladores de ETL's comprendan que si no se arregla en el E

Este es un tema clave para poder tener éxito en una buena plataforma de Inteligencia de Negocios. Revisemos inicialmente la definición de ETL. Buscando rápidamente en google vemos la primera definición de ETL que nos proporcionan es la de wikipedia y dice: " Extract, Transform and Load (Extraer, transformar y cargar en inglés, frecuentemente abreviado a ETL) es el proceso que permite a las organizaciones mover datos desde múltiples fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos, data mart, o data warehouse para analizar, o en otro sistema operacional para apoyar un proceso de negocio. " (wikipedia: ETL). En la anterior imagen se ve el esquema general de una solución BI, la parte que esta dentro del círculo es la que llamamos proceso ETL. Ahora veamos un zoom dentro de lo que se hace en este proceso: Podemos decir que está definición es una definición a muy groso modo de todo lo que comprende el proceso ETL, sin embargo este es un t

Existe un viejo programa de televisión llamado los caquitos que fue hecho por el gran actor mexicano Roberto Gomez Bolaños y su compañero de aventura Ruben Aguirre y allí ellos salían con ideas locas y se cuestionaban algo, "¿estamos locos lucas?".   De la misma forma me cuestiono yo muchas veces en el tema del diseño de ETL's que a veces he leido y me cuestiono siempre lo mismo, "¿estaré loco lucas?". Lo digo porque he leido diseños de OBIAPPS, de IBM para su herramienta Datastage y sus modelos de industria e incluso el de muchos de mis compañeros.   Problematica: Sencillo, cuando se tiene un desarrollador de ETL tratando de decifrar diseños que están mal construidos (principalmente el mapeo), hace que toque recurrir al "código" para tener certeza de la veracidad del diseño y peor aún, entender lo que se está haciendo, debido a la falta de claridad que existe dentro de los documentos de diseños.   Esta es una problemática a nivel mundial