Principios de un Datawarehouse

La inclusion de todos los principios de un Datawarehouse, no es algo de caracter obligatorio, pero seguirlos puede llevarnos al exito y valor del mismo.

Un Datawarehouse debera incluir datos que sean aplicables a la empresa, este es el valor y relevancia enraizada de un Datawarehouse.

Asi que despues de leer a varios autores…. He sintetizado los principios de un buen Datawarehouse.

* Orientacion por Temas: Los datos seran agrupados por Temas, esto con la finalidad de absorver cambios, sin necesidad de hacer grandes cambios en la arquitectura del mismo. Un Datawarehouse jamas presentara datos que reflejen la manipulacion de los datos operacionales. En su lugar reflejara datos que representan las mas importantes areas dentro de la empresa.

* Integracion de los Datos: Aun cuando el dato provenga de distintas aplicaciones, departamentos,etc. Las diferencias deberian ser suavizadas para que los datos contengan el mismo look and feel.
a) Por Forma: Si se tiene el formato 123-(34) y 12334, uno de estos dos formatos debera ser impuesto sobre el otro.
b) Por Funcion: Cuando dos o mas datos representan la misma cosa pero con nombres diferentes, estos dos nombres deberan ser remplazados por uno solo.
c) Por Granulacion: Cuando dos o mas elementos aplican diferentes grados gerarquicos (distrito,region) para definir la misma cosa, estos 2 o mas elementos seran resueltos al mismo nivel de Jerarquia o Detalle.

* Jamas Volatil: A diferencia de los datos en operacion de las aplicaciones, los cuales tienen el futuro de ser descartados una vez que la compañia haya terminado de usar estos. En el Datawarehouse siempre deberan permanecer con la intension de poder expresar lo que es la empresa a lo largo del tiempo.

* Variante al Tiempo: Todos los datos tienen un contexto sobre un momento en el tiempo. Un Datawarehouse debera mantener ese concepto para expresar los eventos de la empresa a lo largo del tiempo sobre 3 conceptos:
a) Que era
b) Que es actualmente
c) Como sera si nada llega a cambiar
Este es un principio es una significante diferencia de aplicaciones operacionales, las cuales funcionan en el ahora, mas que en los eventos pasados.

* Ofrecer una unica version de la verdad: Un Datawarehouse debera definir cada elemento de los datos de una manera que… todos los miembros de la empresa asocien una y solo una pregunta con los datos de ese elemento.
Aqui un ejemplo de lo que se debera evitar:
— Cuantos carros fueron ensamblados ?
1.- Total de ensamblados nuevos 32,000
2.- Total de ensamblados reconstruidos 1,000
3.- Total de ensamblados para empresas filiales 19,000

Aqui un ejemplo de lo que debe ser:
— Cuantos carros nuevos fueron ensamblados ?
1.- Total de ensamblados nuevos 32,000

Esto permite que cuando todos los miembros de una empresa miren hacia el dato elemento, lo hagan todos con un solo entendimiento de su significado.

* Inversion a largo plazo: El Datawarehouse debera ser suficientemente flexible, escalable para absorver los cambios ademas de agregar un valor a la compañia a largo plazo. Ofreciendo a su vez un retorno de inversion atraves de su longevidad y estabilidad

Nota Importante: El analista ETL es el responsable de que los principios del Datawarehouse se cumplan.

Asumiendo cambios significativos en las fuentes de datos

La predictible simetria de los modelos dimensionales permiten a estos absorver algunos cambios significativos en la fuente de datos o en el modelado, esto sin invalidar las aplicaciones datawarehouse existentes.
Aqui les describo algunas de las modificaciones no esperadas. Iniciando con la mas simple:

Nuevos atributos en la dimension. Si descubrimos nuevos atributos a un producto, agregariamos esos atributos a la dimension como nuevas columnas. Si nuevos atributos estan disponibles solo despues de un punto especifico en el tiempo, entonces “No Disponible” o su equivalente sera insertado en los registros anteriores a este punto en el tiempo.

Nuevas dimensiones. Podemos agregar dimensiones a una tabla de hechos existente, bastara con agregar una nueva llave foranea y llenar esta correctamente con valores de las llave primarias proveniente de la nueva dimension.

Nuevas medidas en la Tabla de hechos (Caso Sencillo). El Caso sencillo de esto es,

cuando las nuevas medidas estan disponibles para el mismo grado de granularidad en el que se encuentra la tabla de hechos

. En este caso, la tabla de hechos es alterada para agregar las nuevas columnas, y los valores son puestos en su lugar. Si las nuevas medidas para la tabla de hechos, estan solo disponibles desde un punto del tiempo en adelante, entonces los valores nulos necesitaran ser remplazados en las viejas filas de la tabla de hechos.

Nuevas medidas en la Tabla de hechos (Caso Complejo)Cuando nuevas medidas que se desean agregar a la tabla de hechos

ocurren sobre un nivel diferente de granularidad

. Si las nuevas medidas no pueden ser albergadas o asignadas a el original nivel de granularidad de la tabla de hechos, se puede decir entonces que las nuevas medidas pertenecen a su propia tabla de hechos.”Ya que es un error mezclar diferentes medidas con diferente nivel de granularidad sobre una tabla de hechos”.

Dimensiones que se vuelven mas granulares. En algunas ocasiones es deseable aumentar la granularidad de una dimension. En la mayoria de los casos, los atributos originales de la dimension pueden ser incluidos en una nueva, mucho mas granular a causa de que estos pueden acomodarce en una relacion muchos a uno. Las dimensiones mas granulares a menudo implicaran una tabla de hechos mas granular. Pudiece no existir mas alternativa que tirar la tabla de hechos y reconstruir la misma. Ademas, todas las aplicaciones existentes podrian no ser afectadas.

Agregando una completamente nueva fuente de datos envolviendo tambien inesperadas nuevas dimensiones. Casi siempre, una nueva fuente de datos tiene su propia granularidad y dimensionalidad, entonces nosotros creamos unas nueva tabla de hechos . Deberiamos evitar el ajuste a la fuerza de nuevas medidas dentro de una existente tabla de hechos con medidas ya consistentes. Las aplicaciones existentes trabajaran aun a razon de que las tablas de hechos y dimensiones ya hechas no sean modificadas.

Explicacion de lo que es una Slowly Changing Dimension (SCD)

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.

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).

Explicacion de lo que es una Clave de Negocio (Business Key) y una clave Subrogada (Surrogate Key)

La mayoría de las tablas de base de datos con que trabajamos, utilizan un campo como clave de acceso, el cual identificará de forma inequívoca a un elemento de negocio, y que en muchos casos tiene significado por sí mismo. Pongamos algunos ejemplos:

* Si estuviéramos hablando de una tabla que almacena Pólizas, la Clave de Negocio podría ser el Número de Póliza (un valor único para cada Póliza, que tiene significado por sí mismo).

* Si estuviéramos hablando de una tabla que almacena vehículos, la Clave de Negocio podría ser la matrícula (o quizás el número de bastidor).

* Si estuviéramos hablando de una tabla que almacena productos comerciales, la Clave de Negocio podría ser el código EAN-13.

* Si estuviéramos hablando de una tabla de facturas, la Clave de Negocio podría ser la composición del Año de Factura y el Número de Factura.

Mientras que una Clave Subrogada es un campo numérico de una tabla cuyo único requisito es almacenar un valor numérico único para cada fila de la tabla, actuando como una clave sustituta, de forma totalmente independiente a los datos de negocio, que habitualmente no tiene significado por sí misma.