Informática

Diseño de un “data warehouse”: explicación de los errores de Kimball mediante ejemplos. (Parte II)

19 junio, 2012

En el anterior artículo de esta serie vimos los 2 primeros errores de Kimball así como una breve definición de los términos básicos que conforman la raíz de esta serie.

En esta parte veremos 4 errores más relacionados con el diseño de un data Warehouse y seguiremos perfilando el corazón de nuestro sistema BI.

“Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones.”

Si se crean dimensiones extras en para niveles de jerarquías, se complican las sentencias que se deberán realizar para el consumo de los datos del data warehouse. Además, al ser una dimensión innecesaria, se aumenta considerablemente el espacio ocupado (ya que se generarían millones de registros con el campo de la dimensión.

Dada la siguiente jerarquía para la dimensión “punto de venta”:

País > Región > Ciudad > Tienda

En el modelado normalizado obtendríamos:

Tabla

Está claro que la estructura es más visual, pero a la hora de consultar la tabla de hechos de ventas por país, deberíamos generar una consulta que uniese todas esas tablas y se podría caer en la tentación de mover la localización a la tabla de hechos de la siguiente forma:

Tabla

Lo cual generaría un gran volumen de datos innecesarios en la tabla de hechos.
Por lo tanto, lo recomendable sería añadir las claves primarias de cada una de las jerarquías de la dimensión punto de venta a la tabla de tiendas, quedando:

Tabla

Así se mantendría un diseño en estrella que definiría la dimensión en una sola tabla.

“Error 9: No afrontar el tratamiento de las dimensiones lentamente cambiantes.”

Como ya he comentado, el hecho de no contemplar esta posibilidad supondría una gran pérdida en la explotación de los datos del data warehouse.

Dada la siguiente tabla de dimensión:

Tabla

Supongamos que, con el tiempo, la empresa modifica su modelo de negocio a uno más especializado, y modifica el maestro de productos. Si no se contempló este hecho a la hora del diseño, en el momento que cambien esos datos, todo el histórico perderá su valor ya que los productos que fueron registrados en la tabla de hechos de ventas no se corresponderán con los actuales.

“Error 8: Crear «smart keys» para relacionar una tabla de dimensión con una tabla de hechos.”

Es posible que en el operacional, el uso de claves definidas por el usuario sea mucho más útil de cara a los procesos de negocio (reglas mnemotécnicas).
Pero su uso en un data warehouse es incorrecto ya que, en el momento en que se produzca un cambio en esa clave o una repetición de la misma cuando habíamos supuesto que era única se producirán incongruencias en los datos. Además, un valor numérico ocupa menos espacio en disco que una cadena.

Por ejemplo, imaginemos que la clave del maestro de categorías son las 3 primeras letras de la descripción de la categoría y que se añade la categoría musical. Ya existe la categoría Music con su clave Mus, por lo que no se nos permitiría el volcado de los datos o obtendríamos resultados incorrectos.

“Error 7: Añadir dimensiones en una tabla de hechos antes de definir su granularidad.”

Las tablas de hechos deben tener los datos fundamentales para su aprovechamiento, ni más ni menos. Si, a la hora de realizar el diseño, no hemos especificado granularidades de las dimensiones, podríamos encontrarnos con datos inconexos y tener que modificar el diseño para añadir otra medida a la tabla de hechos lo que impactaría directamente en el tamaño de la base de datos.

Por ejemplo, supongamos que tenemos la siguiente tabla de hechos para analizar las ventas de productos:

Tabla

A la hora de explotar esos datos nos daríamos cuenta de que deberíamos haber escogido una mayor granularidad para el pedido y realizar la tabla de hechos sobre línea de pedido.
Este error, podría suponer el tener que añadir una nueva clave a la tabla que hiciese referencia al producto para identificar cuantas unidades de cada producto se vendieron o bien, modificar el diseño para sustituir el identificador del pedido por el identificador de línea.

Post publicado por:  Juan josé Hernández

Puedes compartir este artículo en:

    Deja un comentario

    Información básica acerca de cómo protegemos tus datos conforme al Reglamento General de Protección de Datos (Reglamento UE 2016/679) y en la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales

    De conformidad con lo establecido en el Reglamento General de Protección de Datos, te informamos de:

    - Quien es el responsable del tratamiento: SEAS, Estudios Superiores Abiertos S.A.U con NIF A-50973098, dirección en C/ Violeta Parra nº 9 – 50015 Zaragoza y teléfono 976.700.660.

    - Cuál es el fin del tratamiento: Gestión y control de los comentarios del blog de SEAS. 

    - En que basamos la legitimación: En tu consentimiento.

    - La comunicación de los datos: No se comunicarán tus datos a terceros.

    - Los criterios de conservación de los datos: Se conservarán mientras exista interés mutuo para mantener el fin del tratamiento o por obligación legal. Cuando dejen de ser necesarios, procederemos a su destrucción.

    - Los derechos que te asisten: (i) Derecho de acceso, rectificación, portabilidad y supresión de sus datos y a la limitación u oposición al tratamiento, (ii) derecho a retirar el consentimiento en cualquier momento y (iii) derecho a presentar una reclamación ante la autoridad de control (AEPD).

    - Los datos de contacto para ejercer tus derechos: SEAS, Estudios Superiores Abiertos S.A.U. C/ Violeta Parra nº 9 –
    50015 Zaragoza (España) o través de correo electrónico a lopd@estudiosabiertos.com

    - También puedes ponerte en contacto con nuestro Delegado de Protección de Datos en dpd@estudiosabiertos.com

    Información adicional: Puedes consultar la información adicional y detallada sobre nuestra política de privacidad