Haciendo Cubos

Cuando hagas tu tabla de hechos sigue estas recomendaciones.

• No usar llaves compuestas. Trata de no usar llaves compuestas, esto es, utiliza un solo campo para hacer join con las otras tablas. Esto hará que la base de datos trabaje menos. Es un poco complejo de programar pero ayudará bastante en el performance de la base de datos. ¿ Y no funciona si uso llaves compuestas? Si, si funciona pero se nota una diferencia en los tiempos de respuesta. Esto se nota más si la tabla de hechos será gigantesca.
• Define la Primary Key en la tabla de hechos. Si en el CREATE TABLE establecemos quién es la primary key, la base de datos creará un índice con la combinación de estos campos lo que hará más rápidas las búsquedas….Si, si me he topado con DWH que no tienen índices y que al procesar los cubos se tardaban 2 días. Si su tabla de hechos no tiene índices, pongale uno, el más apropiado de entrada es aquel que incluye a todos los campos que forman la llave de la tabla….Lo mismo aplica para las tablas de dimensiones o catálogos.
• Utilice los tipos de datos apropiados. En el diagrama puede ver como el campo unit sales usa un tipo de dato DOUBLE PRECISION; esto estaría bien si nos dedicaramos a la venta de garbanzos  y quisiéramos llevar la cuenta del # de garbanzos vendidos (no sé, pero un kilo de garbanzos ha de traer cientos de ellos ) ¡Es para almacenar números gigantescos!. Si lo que vendemos es maquinaria a lo mejor con un Decimal(10,2) estaría bien. Tenemos que acoplarnos al número que almacenará la columna. Espacio de más hará que la base de datos crezca más y se requiera más espacio, y a más espacio más trabajo y más servidor y más memoria y más…
• Tenga cuidado con el tipo de dato entero. Una vez haciendo un cubo de recursos humanos teníamos 2 indicadores: # de Personas y #Personal Requerido. Como no se puede tener 1/2 persona ni requerir 1/2 persona los dos los definí de tipo entero. La bronca vino al hacer las consultas. Resulta que en las bases de datos, al dividir un entero entre otro entero el resultado es un entero, o sea ( 768/1000 ) = 1. Luego teníamos a cada rato que anteponerle CONVERT u otra instrucción por que el resultado o era 1 o 0. Recuerdo que esto aplica para SQLServer y Redbrick, no recuerdo en este momento si pasa lo mismo en Oracle.
• Las tablas de hechos pueden tener campos de apoyo. Si, no siempre se tienen únicamente los hechos y dimensiones. Se pueden tener campos como Fecha de entrega, de compra, etc.
• No guarde campos que se pueden calcular. Si por ejemplo tiene un indicador que es el precio promedio = ventas $/ Ventas Unidades; no haga el calculo y lo guarde en la tabla de hechos por que al consultar los datos deberá usar una formula de agregación como SUM, AVG, MAX, MIN y si lo analiza, la distorsión del indicador será bastante grande al promediar un precio promedio en millones de registros o pocos de ellos.
• Use nombres amigables. No hay razón para no utilizar el nombre VENTAS UNIDADES para una columna en la tabla de hechos. Luego no tiene uno NPI de lo que hay en cada columna.

Recuerde, los datawarehouses se diseñan pensando en ser de fácil consulta. Son para analizar información.