En un Data Warehouse, el término dimensión se refiere a un grupo lógico de datos tal como una localidad geográfica u organizacional sobre los datos de la empresa.

Una Dimensión que cambia con el tiempo es una Slowly Changing Dimensions (SCD) es decir una dimensión que contiene datos que cambian lentamente. Por ejemplo, puede ser una dimensión que permite analizar las ventas de una empresa agrupada por vendedores. Todos los reportes regionales funcionan bien, hasta que un vendedor se mueve de una región o país hacia otra. Como mantienes ese cambio en la Dimensión de ventas?

Podrías obtener un promedio de las ventas anuales por vendedor, pero si se utiliza esto como un indicador de desempeño de los vendedores, esto podría dar información incorrecta. Si el vendedor se movió de una región muy productiva a una región con menos clientes, su promedio será superior al resto de los vendedores aún si su desempeño no es realmente mejor. O podrías crear un nuevo registro de vededor y tratarlo como una entidad distinta, pero eso también trae problemas ya que no se tendrían los totales.

Existen algunas metodologías para tratar este problema del tipo 0,1,2,3,4 y  6 que se explican brevemente a continuación.

Tipo 0. Este es un enfoque pasivo, es decir no se hace nada al respecto. Los valores permanecen como estaba la dimensión cuando los registros fueron creados. No es el tipo más usado.

Tipo 1. En este enfoque se sobreescriben los datos viejos con el dato actualizado sin mantener el historial de  donde perteneció. Este enfoque es sencillo, pero tiene la desventaja de que no contiene historia.

Tipo 2.  En este enfoque se inserta un nuevo registro cada vez que existe un cambio en la dimensión. Se agrega un campo de versión u opcionalmente se agregan dos columnas para capturar la fecha de inicio y final de ese valor. Con este método se puede relacionar fácilmente el período de tiempo para el cual es válido cierto dato en la dimensión pero no es muy sencillo de mantener sobretodo si el modelo dimensional cambia a menudo.

Tipo 3. Este método da seguimiento al cambio agregando nuevas columnas. Una columna  mantendría el dato de la región original de un vendedor por ejemplo, y otra la nueva región o actual, así como una columna de fecha efectiva del cambio. Este enfoque solo puede mantener un cambio histórico, a diferencia del Tipo 2 que puede mantener cambios ilimitados en la historia.

Tipo 4. Este método mantiene una tabla histórica para todos los cambios y una tabla con el valor actual de la dimensión.

Tipo 6 / Híbrido. Este método es una combinación de los Tipos 1,2 y 3 (1 + 2 + 3 = 6. El enfoque es usar una Dimensión TIpo 1 (escribiendo el dato actual), pero agregar un par adicional de columnas con las fechas de validez (TIpo 2).

Otras alternativas son usar un número de versión para cada nuevo renglón tal como el método de Tipo 2.

Los registros deben tener la llave de la tabla de Dimensión como una llave foránea (aunque no es un join a una única columna) en combinación con un filtro de fecha.  Para permitir historial de Tipo 2, las transacciones también podrían tener columnas para referenciar al número de versión aunque tomando las consideraciones de desempeño del Tipo 2.

No es necesario tener una bandera del dato actual en la dimensión o una llave para cada registro pero puede simplificar las consultas y la administración respectivamente.

Note que los Hechos debería tener solamente una fecha para representar la fecha en que ocurrió. Si se tienen múltiples fechas considerar dividir las transacciones de manera más granular.

No pretendo dejar resueltas todas las dudas sobre el manejo de estas dimensiones; sino solamente despertar el interés por aplicarlas y entenderlas.

Por ejemplo, para enviar signos < (menor que) como parámetro al Web Service marca un error ya que es un caracter reservado y lo confunde con el inicio de un tag. Esto se resuelve usando entidades, de acuerdo a la definicion de ISO-8859-1 que es el estándar más utilizado en los browsers y aplicaciones.

A continuación los caracteres más utilizados y sus número de Entidad soportado (note que el caracter de comilla simple no funciona en Explorer y en otras interfaces, en mi caso nos afectaba los pasos de parámetros cadena a un Stored Procedure a través de un Web Service, por lo que en lugar de su Entity Name usamos su Entity Number):

Puede consultar la tabla completa en W3Schools

Otra tip muy útil para probar webservices desde algún cliente de SOAP es usar los campos CDATA, sobretodo para evitar hacer encoding o escribir el código de las entidades repetidamente. Estos campos CDATA (Character Data) permite poner cualquier cadena de texto incluyendo caracteres especiales:

<ejemplo>
<![CDATA[
<HTML>
<HEAD><TITLE>Rock & Roll's brothers</TITLE></HEAD>
]]>
</ejemplo>

Ejemplo 2:

<![CDATA[if (c<10)]]>

El contenido dentro de las secciones CDATA debe estar dentro del rango de caracteres permitidos para el contenido XML, los caracteres de control y los caracteres de compatibilidad no pueden escaparse de esta forma. Además, la secuencia ]]> no puede aparecer dentro de una sección CDATA porque esta secuencia señala el final de la sección. Esto significa que las secciones CDATA no pueden anidarse. La secuencia también aparece en algunas secuencias de comandos. Dentro de las secuencias de comandos, es normalmente posible sustituir] ]> por ]]>.

Para lograr una mayor explotación de los beneficios del uso de BI en las empresas, se requiere de varios cambios en cuanto a la oferta de parte de proveedores, interfaces de usuario adecuadas para cada perfil asi como entendimiento de las necesidades de los usuarios finales.

Muchas personas relacionan BI con solamente el concepto de OLAP, con interfaces complejas y reportes difíciles de generar. Hoy día, muchas aplicaciones habilitan características de BI inserto en aplicaciones y explotando interfaces y mecanismos nuevos de interacción con el usuario.

Una nueva opción para las empresas que no cuentan con presupuesto para licencias de software de BI, es el uso de software libew (opensource) tal como Jaspersoft o Pentaho. Otra opción para reducir costos es el uso de proveedores de Software as a Service (SaaS). Empresas especializadas en este segmento son LucidEra, PivotLink y Oco.

Los usuarios principales de BI son analistas financieros y de negocio en un 52%, seguidos por los Ejecutivos y gerentes con 44% respectivamente; el resto de los usuarios son personal interno, de campo, clients y proveedores según datos de BIScorecard.

Algunas recomendaciones para las empresas que buscan incursionar en implementaciones de BI son: Pensar más allá de herramientas de consulta, ver como mejorar todo el negocio. Empezar en fases; Enfocarse en el Negocio y su relación con IT. Limpiar o unificar los datos. Por último se debe buscar proporcionar un portafolio de herramientas con interfaces adecuadas para cada perfil de usuario.