Errores Comunes y Recomendaciones para DWH

Errores más comunes al diseñar un DWH

 

10) Campos de Texto como identificadores

9) Limitar los campos de texto descriptivos en las dimensiones

8) No dividir en Jerarquías las Jerarquías en las dimensiones, evitar usar el Copo de Nieve cuando sea posible

7) Cambios en los atributos del DataWareHouse (no necesariamente es algo malo), se puede dejar la tabla original y crear una nueva y ligarla, así no se pierde la conectividad

6) Los problemas de performance no siempre se arreglan al agregar mas potencia de hardware

5) Analizar si es necesario meter llaves en las tablas de hechos y dimensiones, índices si, pero llaves es de analizarlo, por otro lado si se decide utilizar llaves, que sean llaves muy simples y no  compuestas

4) Quitar la granularidad innecesaria, por ejemplo: tener un campo de nombre completo y dividirlo por nombre, apellido paterno, apellido materno, o el RFC dividirlo por mes-día-año

3) No limitar el diseño del DWH a un solo reporte en específico, tratar de hacerlo lo mas general posible para que pueda ser explotado

2) Evitar que los Datamarts sean en base a datos agregados (cálculos por ejemplo la edad) evitar que el usuario tenga que hacer un Drill-Down para obtener toda la información

1) Si utilizamos varias tablas de echos que utilizan tablas dimensiones en común (iguales) evitar crear tablas dimensión por separado, utilizar la misma tabla dimensión

 

Negatividades al crear o diseñar un DWH

 

10) Marcar la importancia del DataWareHouse

9) Establecer un plan para que los usuarios lo conozcan, que sepan explotarlo, exponerle los beneficios y los alcances que puede tener (Publicación del DataWareHouse)

8) Los usuarios que le den soporte al DataWareHouse estén en oficinas cómodas y cerca de los usuarios, no darles un trato especial y hacerlos como vedet’s

7) hacerle ver a los directivos que terminando la prueba de un DWH, pueden pasar meses hasta que ese DWH pueda ser llenado con datos reales, se debe de tener capacitación y entrenamiento simple (no retacarlos de información)

6) El usuario de negocio no es un usuario de sistemas, solo van a aprovechar el DataWareHouse si existen herramientas o programas que los ayuden (asumir las capaciades del usuario)

5) No crear expectativas falsas, siempre tratar de hacer un datawarehouse ligero y sobre la marcha irle metiendo mas cosas,

4) Interactuar con el DWH desde el inicio con los directivos, no sólo cuando ya está terminado

3) No pretender satisfacer todas las necesidades

2) Mantener desarrollos simples

1) apender a escuchar a los usuarios, estar seguros de que el DWH que se está construyendo, es el correcto para sus necesidades, debido a que al final de cuentas siempre va a tener razón

 

Recomendaciones para escoger la plataforma del DataWareHouse

 

Lógicos – Físicos

 

Entidades – Tablas

Relaciones – Constraints (PK’s, Fk’s, Not Null, No duplicates)

Identificadores úncos – Uk’s o Indexación

 

 

Definir los table spaces (uno o mas archivos, va muy de la mano con el sistema operativo) no darle mas de un uso al servidor del DataWareHouse, que no sea el disco del sistema operativo

Separar los tables spaces de tablas de echos y dimensiones (éstas últimas casi no se mueven), las tablas de echos siempre están creciendo constantemente, un table space para los índices

Organizar las tablas y particiones, separar por ejemplo la tabla de echos por periodos
Hacer vistas, analizar si se necesita que tenga o no índices, se necesitan vistas materializadas? Y en caso de que así sea, analizar si se necesita una table space para las puras vistas

Mientas menos constraints tenemos mas rápido va a responder el DWH

NO meter Indices en campos derivados!

Saber cuales son las capacidades de indexación del DMBS,

- - - - - - - - - - - - - - - - - - - - - - - -
~Mario Vargas

"Two Wrongs Doesn't Make One Right"