Concuerdo contigo, ya que mantener la mayor granularidad en el modelo dimensional nos permite extender fácilmente este mismo ante nuevos requerimientos.

En los proyectos en los que he participado, eso sí, el modelo relacional normalizado que colocas como área principal del DWH no lo implementamos, pasamos directo desde el staging al dimensional requiere un poco más de trabajo con ETL pero sumando y restando el tiempo de desarrollo tiende a ser menor que si se hiciera un modelo relacional normalizado (a la Inmon).

Es un debate muy interesante. ¿Realmente es necesario un "modelo relacional" independiente del "modelo dimensional" que atacan las herramientas de BI?

Como dices, esta estructura es voluminosa, y sólo por ello es posible que el primer proyecto sea más largo que si omitésemos este repositorio.

Sin embargo, el "modelo relacional" aporta alguna ventajas que nos pueden facilitar el mantenimiento del proyecto. Particularmente, me transmite "seguridad" el hecho de tener localizado y perfectamente identificado todo el detalle de información. En el "modelo relacional" está toda la información sin duplicidades, y seré capaz de responder cualquier pregunta que me hagan ahora o en el futuro. En el modelo relacional SOLO debo preocuparme de guardar e integrar la información.

En cambio, en el "modelo dimensional" me preocupan otros aspectos. Me preocupa el rendimiento de las consultas, y la facilidad que tendrá el usuario para acceder y consultar la información. Por lo tanto, crearé agregados, y precalcularé KPI, y...

Si unificásemos estos dos repositorios en uno único, tarde o temprano me encontraré con el problema de escoger una solución de compromiso. ¿normalizo u optimizo? ¿Guardo este dato que tal vez algún día lo necesiten o lo omito para que vaya más rápido?

Existen otros pros y otros contras, pero para mi eso sólo ya justifica la existencia del "modelo relacional". En cualquier caso deben valorarse también otros aspectos, como si el operacional es fácilmente accesible y guarda suficiente historia (por si en el futuro la necesitamos).

Yo soy novatillo, por eso tengo problemas en imaginarme un ejemplo de modelo relacional dentro del DW. Este modelo relacional dentro de el DW, sería igual que en el transaccional pero integrado??Y si el datawarehouse tiene como fuente 3 BBDD transaccionales, que modelo se realizaría??Podrías poner un ejemplo?

Tambien he oído hablar DW puramente en 3fn, este es el caso de Teradata (el producto más caro en su campo) y según leí en el fundamentals de su producto Teradata 13 (la última versión de su BBDD), dice que la arquitectura que ellos propugnan es DW en 3FN, con lo que aqui tengo otra dua; ¿Que diferencia habría entre el transacional y el dimensional, en cuanto a diseño??

Esto último me recuerda a los dos gurús del DW, Bill Immon (arquitectura Bus comun- modelo en estrella o copo de nieve) y kimball (aquitectura DW 2.0- modelo en 3fn), sigo sin entender en este caso cúal es el modelo de un DW en 3fn e incluso en el libro DW Toolkit de Kimball no encuentro ni un ejemplo gráfico de un modelo..alguien podría facilitarme algún ejemplillo de un DW puro 3fn??

Saludos,

Isaac BG

Olvidar el último parrafo de mi último post, que el que tiene boca de equivoca, vaya trola he soltado, lo siento, me lié con otro tema.

Bueno aún así me duda sigue estando, Teradata si dice que sus modelos de DW estan en 3fn.(o he sido engañado vilmente)

Saludos,

Isaac BG

En la mayoría de casos, el modelo en 3FN existe (o deberia existir), aunque pasa desapercibido por los usuarios... y tal vez hasta para medio equipo de informática o incluso para el director de Sistemas...

Si, como dices, el origen son 3 transaccionales, la necesidad de unificarlo en un solo modelo normalizado es más importante aún.

A partir de este modelo en 3fn, crear el "modelo dimensional" es más rápido, más sencillo, más seguro y más mantenible.

Preguntas cual es la diferencia de diseño entre el modelo relacional y el dimensional... El relacional está normalizado (3fn, idealmente), y en el dimensional se hace lo que sea necesario para que vaya rápido (típicamente, modelos en estrella, y en copo de nieve).

Lo que oíste de Teradata es verdad. Lo oíste. Ellos venden que funciona perfectamente en un modelo normalizado. Eso dicen. La realidad es que generalmente NO ES VERDAD, y que siempre acaban haciendo un modelo dimensional adaptado para explotarse desde Business Objects, Microstrategy, o lo que sea...típicamente en copo de nieve.

Buenas otra vez,

Quizás no me haya espresado muy bien, voy a intentar hacerlo mejor..jeje...Yo sé lo que es un modelo relacional en 3fn para cualquier base de datos OLTP, pero lo que yo te he entendido es que además de este modelo relacional tienes otro modelo relacional en la base de datos del DW (que comprendo son distintas) como intermediario entre el primer modelo transaccional y el modelo multidimensional.

Que guarda este modelo?, que diferencia hay entre este y el modelo relacional de origen (si son los dos modelos relacionales que diferencia hay en cuanto a relaciones?) y que diferencia habría entre el modelo relacional dentro del DW y el módelo multidimensional también dentro del DW?quizás lo vería mejor si me puedes facilitar un ejemplo, no me refiero a cual es la diferencia entre un modelo relacional y un multidimensional, sino a la diferencia entre el modelo relacional OLTP de origen y el modelo relacional que tu haces como intermediario, antes de cargar datos en el módelo multidimensional del DW, jeje, no se si me entiendes ahora...

Ok, como te comenté si tienes 3 BBDD relacionales, según me comentas es muy importante unificarlas en una, el problema que encuentro es que cuando yo (o así me han enseñado) diseño un modelo relacional orientado a OLTP, valoras los requisitos, las entidades, las relaciones y cada modelo relacional tiene sus pecualiaridades....entonces como integrarías tres modelos que un objetivo totalmente diferente y con entidades muchas diferentes en otro módelo relacional?????Es decir, si por definición un modelo relacional representa de forma explicita las consultas que sobre él se van a realizar y esta orienta a aplicativos determinados...como vas a hacer uno que unifique los tres...no se si me entendes mejor ahora...no sé como explicarlo mejor....jejeje.

Gracias y un cordial saludo,

Isaac BG

OK, creo que te he entendido. Preguntas por la diferencia entre el modelo relacional del ERP (o sistema operacional o transaccional)... y el modelo relacional del DWH...

En cuanto al modelizado de las tablas, no hay ninguna diferencia... salvo que el operacional sea una "chapuza" fruto de una evolución dificultosa... o salvo que el operacional sean en realidad diferentes bases de datos de su padre y de su madre...

Es decir, el objetivo es "normalizar" todas aquellas cosas que no estén "correctas" en el ERP...

La otra diferencia es la ventana histórica de información... En el ERP debe haber lo estrictamente necesario, y en el DWH todo lo posible...

También preguntas por la diferencia entre el modelo relacional del DWH y el modelo dimensional del DWH... en este caso, creo que sí que lo explicaba en el artículo... El modelo dimensinoal debe ofrecer un rendimiento óptico, y tienes licencia para hacer todo lo que necesites (modelos en estrella, desnormalización, tablas agregadas...)

Buenas,

Primero que nada te felicito por tu blog, me he leído toda la información que publicaste acerca de los 12 Errores mencionados por Ralph Kimball en la construcción de un data Warehouse.

En la compañía donde trabajo, me han dado la tarea de extraer toda la información que es generada en cada sistema operativo constituyentes a una institución financiera, la cual está enfocada en Bancarizar a la gente de bajos recursos, por lo que se espera que exista gran cantidad de transacciones al día. Una de las dudas que necesito aclarar para la extracción de estos datos, se trata acerca de la información que se repite en cada interfaz del proceso, para aclarar mi pregunta voy a plantear un ejemplo.

Si un usuario realiza una transacción a través de la página web, la información es captada por tres interfaces:

Servidor WEB -> API de Comunicación -> CORE transaccional -> API -> WEB

En el esquema presentado, están los datos registrados por el servidor WEB, los cuales son transmitidos por un API de comunicación cuya finalidad es la de estandarizar la comunicación entre el CORE y los distintos canales disponibles, y finalmente los datos que registra el CORE en su log de operaciones.

Mi duda es la siguiente, la información de la misma transacción puede ser extraída de los “logs” de cada interfaz, ¿Es necesario que se extraiga la información en cada etapa del proceso?, o para efectos del Data Warehouse es suficiente contar con los datos suministrados por el CORE ie., como no dispongo de la experiencia en realidad no se cuales son las practicas a seguir.

Muchas Gracias

Daniel Z.

Hola Daniel,

Uno de los objetivos del DWH es obtener una sola versión de la verdad... Es decir, no se trata de cargarlo todo. Si en los operacionales hay información repetida (como parece), debes seleccionar una sola vez cada dato...

Por lo que cuentas, parece que lo razonable es sacarlo del "CORE". Si ahí está la información completa, detallada y validada, es el lugar perfecto. Además, parece que es el lugar por donde pasan todas las transacciones (de la web o no).

Evidentemente... me faltan datos y planteas un problema complejo, que merecerá un análisis más profundo por vuestra parte... Y no añado aquello de que no me hago responsable de las consecuencias de lo que aquí leas para no resultar pedante... :-)

Mucha suerte con el proyecto :-)

Un saludo,

Pau