Errores más
comunes al diseñar un DWH
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
Relaciones – Constraints (PK’s, Fk’s, Not Null, No duplicates)
Identificadores úncos – Uk’s o
Indexación
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 periodosHacer 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
~Mario Vargas
 |
| "Two Wrongs Doesn't Make One Right" |
