Salud! Gran artículo Mac!!

@churro binario: Ehhh, buena pregunta. Esta serie no intenta ser un curso de nada, pero creo que te puede dar una buena pista para comprender los orígenes de todo. Tén en cuenta que hay dos artículos anteriores a éste que hablan también de Data Warehouse, y tienes allí un montón de links a sitios interesantes donde poder ampliar conocimientos, que te pueden ayudar a empezar. Pero no creo que yo fuera capaz de contar siete años de experiencia en unas pocas palabras. ¡Animo, no es tan difícil!!

Un saludo a todos

Pronto hará un añito que empecé a trabajar en una administración explotando y manteniendo (en la medida de lo posible) un DataWarehouse y, todavia a dia de hoy me encuentro un poco perdido. Estudié Ingenieria Tècnica en Informàtica de Gestión y antes que este curro estuve de programador en una mediana empresa dedicada a la fabricación de muebles. Soy un tipo curioso y con ganans de aprender (aunque no dejarme la vida). En que deberia formarme si quiero progresar en el mundillo Datawarehouse? Has repetido bastante que todo lo aprendido anteriormente no sirve, por donde empezar entonces?

Un saludo y muchas gracias.

¡Qué gran consejo! Me atrevo a generalizarlo de la siguiente manera:

“Ficha a personas con experiencia en los productos en los que desarrollas (no a pipiolos recién salidos de un curso de PDO), págales bien, de acuerdo a la experiencia que acrediten (no lostengas a pan y agua, ni los trates como esclavos, ni intentes hacerles ver que echar 12 horas diarias es lo normal), y deja que sean ellos lo que lleven la voz cantante en el proyecto, que para eso tienen experiencia…”

El sector de la informática cambiaría mucho así, creo.

Cuando empecé a currar compartía piso con un compañero que llevaba poco tiempo trabajando en Datawarehouse. No solía venir al final del día de muy buen humor. Por entonces tenía yo poca idea sobre el asunto y lo único que vagamente pensaba era que “eso del datawarehouse no era bueno para la salud”.

Macluskey, el artículo, como siempre, genial. Creo que explicas muy bien los rudimentos del datawarehouse, pero lo más importante es que pones de manifiesto lo difícil que es cambiar de mentalidad para poder abordar nuevas cosas.

Felicidades.

Que las disfrutes.

Me he sorprendido mucho conocer el motivo por el que fracasaron tantos proyectos de desarrollo e implantacion de los Data … sencillamente porque en mi campo ocurre extamente lo mismo. El comercial vende el cojo equipo de comunicaciones, el arquitecto diseña la cojo solución tecnia, el tecnico hace lo que puede (*) y el cliente se queda a verlas vernir porque no hubo nadie que quisiera escucharle o comprender sus necesidades.

(*) perdonarme la expresion pero como digo muchas veces, el tecnico deja su cagadita en el CPD y si te he visto no me acuerdo. Al final el CPD es un gran almacen de cagaditas.

1) Las dimensiones se modelizan con “simples relaciones” claro que sí, pero son mucho más que eso… definen cómo es el negocio y cómo se relaciona cada una con las demás. A ver si con un ejemplo sencillo:

Imaginemos un Sistema de venta de un Hiper más sencillo que el que sale en el post, donde sólo tenemos TRES dimensiones: Tiempo (Minuto-Hora-Día-Mes-Año), Producto vendido (Sección-Departamento-Marca-Producto), y Tienda (Tienda-Provincia-Región-País), por ejemplo.

Píntalo ahora en tres ejes de coordenadas. En el eje x, por ejemplo, ponemos “el Producto”. Cada uno de los productos que vendemos está representado en un punto del eje x. Varios de ellos son de la misma marca, y están juntos. Varias marcas son de un Departamento, y varios Departamentos forma una Sección. Estas agrupaciones cada vez más grandes de productos ocupan áreas contiguas del eje x, pero siempre, siempre, el conjunto de todas las secciones abarca el mismo área que la suma de los Departamentos, o de los productos, etc ¿Lo ves?

En el eje y, la Tienda (con las agrupaciones pertinentes de su dimensión); y en el eje z, el Tiempo (Años que se dividen en meses, estos en días, estos en horas, etc). Y pasa lo mismo con las agrupaciones.

Creo que no debería ser muy difícil pintar este escenario.

Ahora, observemos cada uno de los puntos del espacio tridimensional definido por los tres ejes (ejes finitos, por cierto: el número de productos vendidos es finito, el de tiedas también, y el tiempo lo hacemos finito porque sólo guardamos, por ejemplo, tres años). Entonces, el producto P, la Tienda T, y el momento M, definen un punto en ese espacio tridimensional) ¿Me sigues?

Y en ese punto (x,y,z) puede que haya “algo” (lo que indica que dicho producto P se vendió en esa tienda T en esa hora-minuto M, y puede que no haya nada (no se vendió nada en P,T,M). Obviamente, la mayoría de puntos están vacíos, y de vez en cuando hay alguno lleno. Sigo…

¿Qué hay DENTRO de cada punto x,y,z? LAS MÉTRICAS: en nuestro ejemplo, número de artículos vendidos e importe en euros. SÓLO las métricas. ¿Dónde están las dimensiones? EN LOS EJES.

No sé si te das cuenta de la potencia brutal de este esquema. veamos:

Caso a): queremos saber cúanto vendimos en Murcia el mes de abril pasado en la Sección de Pescadería. Fácil: Seleccionamos en cada eje dónde está Murcia (todas la tiendas de Murcia), abril (todos sus días con todas sus horas con todos sus minutos) y Pescadería (con todos sus productos). Ahora sumamos todas las métricas comprendidas en el área tridimensional comprendida por esas tres regiones. ¿Qué tenemos? Lo que pedíamos. ¿Lo ves?

Caso b) Queremos comparar la venta de los cinco primeros minutos de cada hora en la región de Galicia con la venta de los cinco últimos en la provincia de Soria. Una vez seleccionadas las áreas (los minutos 1 a 5 de cada hora, Galicia por un lado y Soria por otro, y todos los productos, dado que no hemos puesto restricciones en la otra dimensión, se suman todas las métricas y se obtiene el dato pedido.

Etc. Si sigo me saldrá otro post de los míos…

2) Hombre… lo de no hacer nunca deletes ni updates en un sistema transaccional… como que no lo veo. ¿Cómo cambias el nombre de un cliente que te dice que le tienes mal en tu base de datos? conuna Update. Como se te ocurra dar una Delete y luego una Insert, y tienes integridad referencial, te puede organizar una de mucho cuidado. Quizá haya algñun sistema donde pueda hacerse esto pero nunca con carácter general. Esa es la diferencia entre un tipo de sistemas y otros…

3) Claro que es posible diseñar sistemas utilizando lo mejor de los dos mundos… pero hay que tener en cuenta para qué deben servir los sistemas y buscar la mejor solución para que el Sistema haga lo que tenga que hacer (que es lo único importante, no se os olvide).

4) Una última reflexión: Diseñar correctamente Data Warehouses requieren más cosas que lo que he expresado con mis pobres palabras… pero lo que no he contado es lo que se encuentra con facilidad en cursos y documentación varia: Diseñar agregadas para agilizar las consultas, partionar tabñas, instanciar vistas, crear o quitar índices, poner un producto que controle las queries que se hacen y te ayude a afinar el sistema… Pero claro, si lo cuento todo, todo, igual le quito el curro a mis compañeros, y eso tampoco es…

Un saludo y gracias por la pregunta.