Buenas prácticas para un datamart

1 BUENAS PRÁCTICAS PARA UN DATAMARTS
1.1 APLICAR EL MÁXIMO NIVEL DE DETALLE EN EL MODELO ENTIDAD-RELACIÓN
El máximo nivel de detalle no lo debemos dejar de lado en el modelo relacional debido a que todo el detalle debe propagarse hasta el modelo dimensional. Sólo de esta manera el sistema Business Intelligence superará el ataque de las consultas del cliente que quiera ver niveles de detallemuy bajos. Si se dispone la información detallada, cualquier consulta posterior podrá resolverse en cualquier de las agrupaciones disponibles.
Ej. En nuestro reporte podemos ver las ventas diarias de cada producto, ¿Pero y si luego quiero verlo agrupados por categorías? ¿O por hora de venta? ¿O si lo quiero segmentar por precio de venta? ¿O por tipo de subcategoria? Sólo si inicialmente se diseñóel Modelo Entidad-Relación y cargó el Datamart con la información detallada podrán contestarse estas preguntas.
1.2 NO MEZCLAR HECHOS DE DIFERENTE GRANULARIDAD EN UNA MISMA TABLA DE HECHOS.
El Datamart tiene, y debe tener, todo el detalle de información en su nivel atómico. Así, las ventas podrán ser detalladas por fecha, cliente, producto y punto de venta pero sin embargo la mayoría deconsultas no necesitan acceder a tanto detalle.
Ej. Un "product manager" puede estar interesado en los totales de venta de sus productos mes a mes, mientras que el "área manager" consulta diariamente la evolución de ventas de sus zonas.
Por lo tanto para evitar este error es bueno que se creen dimensiones para hacer cruces distintos de los hechos, por ejemplo la dimensión FECHA o PERIODO.
1.3 NOCREAR UN MODELO DIMENSIONAL PARA RESOLVER UN INFORME EN PARTICULAR
Tanto el Datamart como el modelo Entidad-Relación debes ser pensado y diseñado para abarcar más de una problemática haciendo del DM un modelo físico eficiente y que no se centra tan solo en un “indicador”.
Ej: No es correcto crear un Datamart solo para abarcar el indicador de una venta de productos, si en ese mismo modelo de puedeincluir un indicador de facturación, clientes y todos los indicadores o informes relacionados a ventas.
1.4 DEFINIR LA GRANULARIDAD DE LOS CAMPOS DE LA TABLA DE HECHOS
La tabla de hechos contiene las claves subrogadas de aquellas dimensiones que definen su nivel de detalle, y los indicadores. Nada más. Por lo tanto, antes de crear la tabla de hechos debe entenderse perfectamente lainformación que se guardará.
De hecho, la creación de una tabla de hechos es una tarea con poco margen a la imaginación. Antes que nada, debe localizarse el origen de la información que se quiere cargar, debe entenderse perfectamente el significado de estos indicadores, y debe determinarse el nivel de detalle de estos datos. Una vez hecho esto, la creación de la estructura de la tabla es inmediata.
1.5CREAR CLAVES PRIMARIAS (SUBROGADAS) INDEFERENTES AL NEGOCIO
Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son siempre de tipo numérico y preferiblemente un entero autoincremental.
¿Pero por qué necesitamos crear otra clave única para un producto si este ya tiene unaasignada por defecto del sistema? Por varios motivos:
• Fuentes heterogéneas. El DM suele alimentarse de diferentes fuentes, cada una de ellas con sus propias claves, por lo que es arriesgado asumir un código de alguna aplicación en particular. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Cambios en las aplicaciones origen. Puede ocurrir que cambie lalógica operacional de alguna clave que hubiésemos supuesto única, o que siempre debería estar informada. ¿Qué pasará cuando llegue un producto sin SKU?. Lo mejor es crear nuestras propias claves subrogadas desde el inicio del proyecto.
• Rendimiento. En la base de datos, ocupa menos espacio un entero que una cadena. Identificar una ciudad con 5 bytes, o una persona con 9 bytes es un desperdicio...