domingo, octubre 14, 2007

Pregunta al aire: ¿Qué debe "almacenar" un DataWarehouse?

Yo cada vez tengo mas claro que debe almacenar todo menos datos, de hecho empiezo a sospechar que el concepto de DataWarehouse está llegando a su fin.

(SILENCIO)
(SILENCIO)
(SILENCIO)

Este silencio es para causar estupor :-D.



No me he vuelto loco, simplemente cae por su propio peso .
Si recordamos la metodología User-Driven , en ella el punto de partida es que los requisitos no son suficientes con lo que se busca mostrar al usuario un prototipo funcional para intentar captarlos lo mejor posible. Esta metodología buscan tener muy bien definido la interfaz de usuario y que la calidad del dato mostrado sea muy buena, el objetivo es conocer al usuario y las cuestiones que se tienen que responder de cara al negocio, sobre todo las de caracter estratégico.


Afolabi y Thiery, es su articulo "Using Users’ Expectations to Adapt Business Intelligence Systems", nos hablan de la importancia de usuario en este tipo de sistemas, no solo a la hora de definirlo, sino basado en sus propias fases cognitivas: observación; abstracción elemental; razonamiento y simbolización; y creatividad. A través de estos estudios podremos adaptar nuestro sistema de BI al tipo de consultas que nos hará el usuario final (Query Adaptation) y al tipo de respuestas que le tenemos que devolver (Response Adaptation).

Conocer como los usuarios "entienden" la información nos permitirá que los sistemas de BI se entronquen directamente con la gestión del conocimiento creando nuevos sistemas que algunos autores ya estan denominado Knowledge Datawarehouse.

Así pues la pregunta esta clara:

¿Que debe almacenar un Datawarehouse?
a) Datos
b) Información
c) Conocimiento.
d) Todas las anteriores
e) Ninguna de las anteriores


Os pongo una encuesta para que interactueis, pero el debate esta abierto.

33 comentarios:

Antonio Valle dijo...

Pues ya he puesto mi voto, pero como por ahora soy el unico que ha votado "Datos", tratare de razonar la respuesta.

Según tu teoría, deberiamos (quizas) almacenar la información que necesita el usuario... pero el sistema debe trascender al usuario, porque las personas van y vienen, pero los sistemas permanecen (más o menos). Asi que creo que debemos *almacenar* datos y *presentar* información, construida "al vuelo" a partir de los datos y presentada segun las necesidades cognitivas del usuario que tenemos delante de la pantalla....

La dimension tiempo es la mas importante... eso me lo enseñaste tu, maestro.

Fdo: pequeño saltamontes.

Fang Song

Jorge Fernández González dijo...

Muy buen apunte. Estamos diseñando los sistemas decisionales para las personas que van y vienen de las organizaciones, pero si hablamos de almacenar información, la información que se almacene va a depender de la que demanden los usuarios, que va a depender a su vez de la manera en que se controlan los procesos, y de que procesos necesitan mas o menos control en la coyuntura en la que se diseñó el Data.... eso nos delimita QUE informacion almacenar, vendran otras personas que nos pediran MAS información pero la que ya existe se seguirá usando o se desestimará porque el control del proceso a cambiado.

Pero ¿que pasa si almacenamos conocimiento? En teoria no depende ni de las personas ni de los procesos.

Ojo que yo ne he descartado nado, solo estoy lanzando preguntillas ;-D

Unknown dijo...

Hola Colega,

Como ya es habitual en tí, nos sales con preguntas trampa, además de provocar el debate.

Tu apreciado alumno, el pequeño saltamontes, tiene toda la razón. Y bajo mi punto de vista es la única posible, lo demas entra dentro de la ambiguedad del mundo del marketing... conocimiento, sabiduria, información...bla, bla, bla.

Lo único que puede almecenar y almacena son DATOS. Lo diferencia es en la forma de procesarlos y estructurarlos, de forma tal que aparentemente ofrece información y aplicando diversas tecnicas, tendencias y un motón de algoritmos matemáticos puede ofrecer mas o menos valor.

Pero recuerda, apreciado colega, que todas las demas cualidades son exclusivamente humanas, como mucho simuladas por un modelo, el cual también es fruto humano.

El conocimiento es relativo, para lo que uno opina que ofrece valor, para el siguiente puede que se trate de un simple informe sin valor, dejando se ser calificado con un gran analisis.

or otra parte y partiendo de la idea del almacenamiento de datos, pues es lo que recogemos de los operacionales (que no hay nada mas), los encargados de diseñar el DW se basan en las informaciones de los usuarios para detectar variables, metricas y conceptos de negocio... siendo estos correctamente colocados en un correcto DW. Intencionadamente no hablo de informes, pues eso sería hacer una estrellita por cada tipo de consulta o necesidad, eso NO es Business Intelligence NI DW, eso es una colección de parches con poco o ningun valor.

Bueno los dicho, solo DATOSSSSSS

Anónimo dijo...

Hola, Jorge.

Tu blog siempre me hace pensar y normalmente soy un consumidor pasivo. Pero creo que esta vez vale la pena que salte también a la conversación.

Sin dudarlo un momento. Los datos como ya han comentado. Son el principio de la cadena de valor y la parte invariable. Desde mi punto de vista la información y el conocimiento derivan del primero pero estan condicionados a un snapshop del canviante modelo de negocio de una organización y a aquellos que necesitan de información.

Aunque debo confesar que me encantan las posturas radicales.

Un saludo a todos.

Jorge Fernández González dijo...

Así me gusta, que se mojen Chema y Josep.
Veo que la opción Datos esta muy presente y con mucha fuerza... pero la de Todas las anteriores tambien tiene peso.

Voy a añadir un poco de leña al fuego.... ¿los datos puros dan significado?
Y esta es para Josep que es matemático :-D

Anónimo dijo...

Hola,

Buena pregunta, pero tal y como comentan creo es una pregunta trampa. ¿Qué entendemos como dato, información o conocimiento?

Los datos de ventas de mi empresa pueden entenderse como un dato (al fin y al cabo es una cifra), también como información (para el director financiero es información vital para el negocio) o perfectamente como conocimiento. Tal y como se plantea la pregunta es casi un problema lingüístico, no obstante existe un trasfondo bastante interesante, ¿debe una sistema Datawarehouse almacenar simplemente "números" o también conocimiento de negocio?

Ciertamente si pensamos en nuestros sistemas multidimensionales, con sus elementos, atributos, cubos, etc… aunque sólo almacenemos números/texto/datos, estos ya incorporan una estructura que es realmente información de negocio. Desde mi humilde punto de vista actualmente ya almacenamos datos, información y conocimiento, además según pase el tiempo se almacenará cada vez más conocimiento de negocio asociado a los datos, ya sea por una mayor complejidad en la estructura o por incorporar información adicional al dato.

Un saludo

Jorge Fernández González dijo...

Me gusta lo que dices lcflores
"¿debe una sistema Datawarehouse almacenar simplemente números o también conocimiento de negocio?".

Sigamos añadiendo leña al fuego (la verdad es que me lo estoy pasando pipa).....

Por ejemplo si yo almaceno en una tabla de mi DWH llamada F_AGG_XRT datos númericos en el campo XR_17 y GT_18 y una fecha en el campo FR_D_34.

¿Estoy almacenando datos o información?,¿que pinta la semántica en todo esta codificación?.

Y no es marketing Chema que te veo ;-D

Unknown dijo...

Hola a todos,

Por mayoría te estamos aplastando. Todos coincidimos en datos y como muy acertadamente dice lcflores, de una u otra manera los demas esta muy asociado.

La verdad que intentar demostrar esto en una líneas es casí imposible. Lo intentare con un ejemplo:

Supongamos un fichero plano(de los de toda la vida), es cierto que todo se puede encontratar en su interior, pero requiere un trabajo super pesado el obtener "información o conocimiento". Cuales son mis mejores 5 cliente, por delagación, siempre y cuando han comprado más de dos productos en menos de un mes y bla, bla, bla...

Si intentamos esto en dicha estructura estamos muertos.

La unión de las estructuras especiales para el DW, tema que hemos discutido tu y yo (OLAP), junto con las potencias de las herramientas actuales... hacen que de cara al usuario aparencan, como por arte de magía, información, conocimiento y cuanta palabrota quieras decir.

Te propongo una curiosodad más. Piensa en un sofisticado modelo Snow-Flake, ahora aplica técnicas agresivas de desnormalización... llegamos a un modelo estrella. Ahora crucemos el límite de lo razonable, desnormalicemos hasta sus últimas consecuencias. ¿Donde estamos?... ¡¡¡ Curioso !!! ya tenemos el fichero plano de toda la vida. Y habiamos comentado que solamente contenía datos...

Tu mismo respondete a la pregunta. ¿Gallina o Huevo?

Saludos figura.

Anónimo dijo...

Hola a todos, deciros que he decidido estrenarme en esto, sobre todo porque J.Arce me incita a ello con su entusiasmo, y porque después de contestar impulsivamente a la pregunta diciendo por supuesto: "Datos", he añadido "Datos estructurados" y entonces me he preguntado, si a la hora de diseñar un DW definimos un modelo lógico, en el que se seleccionamos, transformamos y depuramos aquellos datos objeto de nuestro estudio.¿no estamos ya aportando información?, eso sin contar con la nomenclatura unificada y homogénea que junto con los comentarios que añadimos definen correctamente un DW, ¿acaso estos ya no aportan información?,¿y no es menos cierto que para realizar un buen diseño de un DW no es necesario un conocimiento del negocio que sustenta todos esos datos?, luego de alguno forma ese conocimiento también queda reflejado en un DW.

Ciertamente, retomando las dos últimas pregunta lanzadas por Jorge respecto a si un dato puro ofrece significado entiendo que esto solo dependerá del receptor de dicho dato y del contexto en el que lo estudie y de la capacidad de este para obtener un conocimiento del análisis de dichos datos bien por la combinación de este con otros datos o por el estudio del dato en si mismo.

Unknown dijo...

Respecto a tu otra "trampa":
Por ejemplo si yo almaceno en una tabla de mi DWH llamada F_AGG_XRT datos númericos en el campo XR_17 y GT_18 y una fecha en el campo FR_D_34.

¿Estoy almacenando datos o información?,¿que pinta la semántica en todo esta codificación?.

***** MI RESPUESTA *********
POr su puesto estas almacenando el valor de una metricas en un momento determinado en el tiempo, es un dato.

El analisis de esa metrica a lo largo del tiempo ofrece información e incluso conocimiento para alguien del sector o con conocimientos en el mismo.

Pero a tu pregunta inicial, solamente hay datos estructurados de forma más "inteligente".

La semantica es esa codificación en concreto no aportada nada. Ademas la nomenclatura interna de las tablas, campos y demas... las cuales pueden ofrecer bastante información, no deja de ser una información normalmente usada por los informaticos. los usuarios finales manejan su "capa semántica" totalmente asociada a su necesidad, teniendo ventas, costes y fecha de factura... por ejemplo.

Salu2,

Unknown dijo...

Je, je, je...

FELICIDADES EVA, has dado otro matiz muy interesante a nuestros argumentos, el cual también hago mio, pues de alguna forma se podía leer entre líneas.

Para mi es un orgulo ver como mi equipo, pues Eva trabaja conmigo, dispone de tan elevado conocimiento y capacidad de replica.

Ahora quedamos Eva y yo impacientes a la siguiente respuesta de Jorge al estilo gallego, es decir, con otra pregunta... venga mojate ya!!!!

Jorge Fernández González dijo...

Hola

Acabo de volver de viaje y he visto que os habeis apoderado de mi blog JUA JUA JUA :-D

Os doy las gracias, de verdad que da gusto con gente como vosotros, y me descubro ante Eva que esta cazando muy bien por donde quiero ir.

Cuando Eva dice
"...la nomenclatura unificada y homogénea que junto con los comentarios que añadimos definen correctamente un DW, ¿acaso estos ya no aportan información?,"

o cuando Chema replica
"Ademas la nomenclatura interna de las tablas, campos y demas... las cuales pueden ofrecer bastante información..."

Dejan patente que queramos o no estamos dando un baño de semantica al diseño del DWH.
Estamos semiestructurando los datos con un modelo informacional, que contiene información de significado y de relaciones entre los datos. Vale, de acuerdo, quizas solo lo vean los informaticos como dice Chema, pero ahí estan.

Y claro, yo me pregunto.... :-D

¿Qué pasa con la metadata del DWH?

P.S: Despues de esta solo me queda una pregunta en la recamara :-D.

Anónimo dijo...

Esta es sencilla. Es pura información de negocio, ¿Cómo podemos montar un Datawarehouse sin contar con los conocimientos de negocio?

Al fin y al cabo, todos somos traductores. Traducimos el conocimiento de negocio expresado por personas a un lenguaje procesable por una máquina :-)

Unknown dijo...
Este comentario ha sido eliminado por el autor.
Unknown dijo...

Hola nuevamente Jorge,

Como no podia ser de otra manera, no te mojas y nos sales con respuestas a la Gallega.

Los informaticos tenemos la santa manía de intentar poner nombre a los campos, tablas, etc... que nos resulten facilmente recordables y que nos faciliten la vida. Lo cual no implica, que es mucho suponer, que aporte conocimiento (en el fondo no es el fín), tambien podiamos haber llamado a los campos c1, c2, c3 y c4... lo cual no aportaría nada. Si a esto lo quereis denominar conocimiento, pues vale conocimiento. También lo haciamos cuando diseñabamos bases de datos operacionales y nadie decia que eso era conocimiento.

Os recuerdo que ese supuesto "conocimiento", ademas de discutible, es interno y nadie lo conoce, pues solamente entran a nivel de sentencias SQL los informaticos. También podeis recordar la cantidad de veces que os habeis encontrado y modelo con nombre de tablas y campos es otros idiomas o no entendibles... ¿Entonces?

Despues de todo lo dicho, me reitero, un DW solamente tiene DATOS, admito la visión de Eva (muy acertada y sustil) DATOS ESTRUCTURADOS según una logica del negocio entendida.

Tambien recordar que un DW debe permitir la variación a lo largo del tiempo de las reglas del negocio y por ello, solamente mirando tablas y sus relaciones... puede que no veas tan claramente algunas cosas.

El metadata del DW (no DWH), de todos es sabido sus posibles contenidos, lo importante de su existencia y las ventajas que aporta. Pero puedo no existir, por ello estas introduciendo una nueva variable. Desde luego los metadata (de cualquiera de sus tipos) aporta un claro conocimiento de los datos, su origen, sus calculos y un sin fin de cosas... pero pueden no existir.

Te invitamos nuevamente a mojarte.

Salu2 colega.

Anónimo dijo...

Hola JM,

Siento no estar del todo de acuerdo, aunque si en parte :-). Tienes razón sobre que los nombres no tienen porque indicar nada, de hecho si miramos a nivel de tablas, poco entenderemos. Voy más allá, a nivel de fichero poco más que 0s y 1s, ciertamente esto sin lugar a dudas no es conocimiento de negocio.

Puestos en plan filosófico, incluso podemos reducirlo al nivel físico más bajo. En los bits almacenamos en un ordenador/disco/cinta sólo tenemos cargas positivas o nulas, podríamos decir incluso que ¡no existe ni el dato!, sólo cargas eléctricas/magnéticas.

Hay muchas capas intermedias desde ese nivel hasta el nivel lógico, pero ciertamente donde trabajamos nosotros normalmente es en este ultimo nivel, sobre todo cuando creamos un modelo de base de datos (multidimensional o no), normalmente dibujamos esquemas E/R (u otros esquemas) que no hacen otra cosa que definir como está estructurado nuestro negocio, creo que estarás conmigo en decir que en este punto son imprescindibles los conocimientos de negocio.

Pongamos como ejemplo un esquema E/R sencillo, las relaciones, entidades te marcan conocimiento sobre la información almacenada independientemente de los nombres que des a los campos o tablas. De hay que en mi humilde opinión el diseño que creas no es otra cosa que el resultado de interpretar e implementar este conocimiento en un “soporte informático”.

Por ultimo, aunque pocos usuarios entran a nivel SQL (créeme que los hay que entran, pero podríamos entrar en temas de ShadowIT y no tiene nada que ver con esto) muchos cuentan con herramientas de explotación de datos. Dentro de estás herramientas las hay de todos los tipos, desde las que incluyen complejas reglas y abstraen completamente el diseño interno hasta las que son un fiel reflejo de este, sobre todo en herramientas que explotan BBDD MOLAP.

Saludos

Jorge Fernández González dijo...

Hola a todos/as

Empezaré por Chema, desarrollando por fin mi gran esperado
....
....
....
....

"Discurso sobre la importancia de las tres siglas en los acrónimos de prestigio."

Todo gran concepto tiene que tener un gran acrónimo, y minimo ha de ser de tres siglas. Fijate sino en ERP, todo el mundo lo entiende a la perfección, es un concepto importante y tiene tres siglas.
CRM, SCM, BPM, BPR, todos tres
y entonces llegamos al Business Intelligence y al Datawarehousing y la cagamos poniendoles solo dos acrónimos (BI y DW) y claro nadie nos toma en serio.
Asi que el paso lógico es el que esta siguiendo el BI pasando a llamarse EPM o CPM (tres siglas) por lo que el Datawarehousing, si quiere sobrevivir tiene que evalucionar hacia DWH.
Es decir tres siglas para un gran concepto.
Yo seguiré utilizando DWH en lugar de DW, pero porque yo soy un irreverente.
Tu como has estudiado con Kimabll e Inmon pues no puedes hacerlo je je je y tendras que seguir con tu DW de solo dos siglas.

Ahora lcflores de Xperimentos.

"¡no existe ni el dato!, sólo cargas eléctricas/magnéticas."

Me ha caido de culo :-D, pues es verdad, pero yo estoy de acuerdo contigo en que el diseño de DWH (con tres siglas) esta empapado de información y conocimiento.

Y lanzo mi ultima pregunta y luego prometo hacer un post entero dedicado a mi respuesta (que podeis machacar a saco y ponerme verde).

¿que papel desarrolla la gestión de procesos de negocio en todo esto?

Unknown dijo...

Hola a todos,

Casi que hoy voy a empezar con una pregunta:
¿Nos entenderemos alguna vez?
Creo que lo mejor es quedar a tomar unas cervezas y charlar, pues merece la pena.

Ahora lcflores de Xperimentos:

Yo por el contrario, si estoy de acuerdo contigo, puesto o no en plan filosófico. Que por cierto me ha gustado como has llegado al origen más real del, ahora, "supuesto dato".

Respecto a: "De hay que en mi humilde opinión el diseño que creas no es otra cosa que el resultado de interpretar e implementar este conocimiento en un “soporte informático”. "

Hombre pues si, pero la simple visualización de un modelo no tiene la obligación de aportarte un conocimiento exacto.

Si yo te paso el modelo del DW que hice para Continente (Carrefour), ¿sabrias interpretar la casuistica que encierra? ¿Sabrias determoninar si el modelo es bueno o malo? Creo que en líneas generales sería dificil, aunque logicamente vas a ver relaciones entre entidades, claves y demas. Es normal estamos intentando, como bien dices, modelizar un negocio.

Si retomo la pregunta inicial de Jorge, en cuanto a que almacena, NO COMO, se esta refiriendo al dato.

Ya veremos con que nos sorprende en breve...

Puesto a jugar, yo también os propongo un juego para evaluar que tal hacemos los modelos y las diversas variaciones dentro de las estrellas, los copos de nieve, etc... Lo teneis disponible en mi blog.

Salu2, buen fin de semana.
ALONSO CAMPEON!!!!!!!!!!!

Jorge Fernández González dijo...

Pues claro que nos entenderemos, si esto es solo para provocar :-D.
Pero te tomo la palabra con lo de las cervezas. Podriamos hacer un evento "Beers and BI" y que quedasemos todos. :-D

Volviendo a tu ejemplo del carrefour, a eso mismo me refiero, si yo lo veo seguramente habrá mucha información que SOLO TU pueds descifrar y que se ha perdido por el camino, Esa casuistica que ha originado la forma del data no esta presente en él.

Pero si te fijas mi pregunta original es

¿que debe almacenar un Data Warehouse?.

Unknown dijo...

Lo que me faltaba... todo un juego de palabras!!!!

¿que DEBE almacenar un Data Warehouse?.

Pues apreciados compañeros, que almacene lo que os venga en gana, total ya estamos casi en Navidad.

Besotes para Eva, un simple abrazo para el resto.

Jorge Fernández González dijo...

je je je.
¡¡¡Y lo bien que nos lo estamos pasando que???

Anónimo dijo...

NO entro en el tema, porque sabies mucho mas que yo, y aqui estoy para aprender...

pero toda esta información en los comentarios, se pierde, porque los piques no los haceis en los respectivos blogs con links de uno a otro...

Esta preciosa discusion se perdera en el olvido... y seria toda una pena.

Saludos

MidnightRambler dijo...

Buenas, aunque tarde, me incorporo, yo soy del equipo de Josep (del equipo empresarial), ademas de su amigo, y me dedico con mas o menos fortuna, a esto del BI.

Al grano.

Un DW almacena INFORMACION. (Estoy con Eva).

Un dato por si mismo no aporta nada.

17,343, azul, por encima, gerente.....

Eso son datos.


Un dw me almacena dicho dato, analizado desde muchos puntos de vista (no me pegueis los puristas).

Los errores que cometió la cadena de montaje 36,con el equipo 12, en 2004, en turno de noche fueron 17.

Eso es información.

El conocimiento es un atributo humano, que se basa en: aplicando unos inputs, la experiencia, y las condiciones de entorno, saber extraer unas conclusiones operativas, emocionales, practicas, etc...

Es decir, una vez que se que se cometieron 17 fallos en dichas condiciones, RAZONO que lo mas probable es que sea debido al turno de noche, y hago DRILL para ver, ese turno, para otros días, como se comporta. Esa intención de hacer drill en el turno de noche, ya que me da el olfato que puede ser falta de iluminación la causa del fallo, es el conocimiento. Es humano. Un novato podría imputar esos 17 fallos a quien sabe que. Yo director de cadena desde hace 30 años, se que que sea de noche tiene algo que ver.

En resumen....

Con el dato 17 fallos (operacional), y la información de que es turno de noche (DW), genero y uso conocimiento, atributo humano.

Ya me direis.

Un saludo.

Anónimo dijo...

No existen las verdades absolutas (al menos para mi), y aqui va mi opinion...

La respuesta es la D y aún se podría ampliar con más cosas.

Datos: Evidente
Información: También evidente ya que lo que no aporta información no se almacena. Información es tambien la falta de información (e.g. el valor null en bbdd)
Conocimiento: Parte del conocimiento (No todo claro!) se almacena en las propias estructuras de datos (e.g Una relacion 1 a n entre 2 tablas no aporta conocimiento del negocio?)

El modelo E/R, estrella, estrella snowflecado y cualquiera que inventen.... almacenará datos que no serán triviales luego contendrán información, obviamente los modelos son semanticos por el propio hecho de ser modelos.

Seguid bien,

TOAD

Unknown dijo...

Hola a todos los colegas, amigos y curiosos.

Quiero aprovechar a matizar algunos temas:

Falty, respecto a tu comentarios "..., se pierde, porque los piques no los haceis en los respectivos blogs con links de uno a otro... ". Indicarte que todas la lineas son expresadas desde al mayor de los respetos a todos, además decirte que algunos de los participantes somo "amigos" he incluso compartimos iniciativas en común, lo cual nos une más todavía.
No te preocupes, pues como puedes ver no hemos perdido nada en el olvido, además para seso tenemos a Jorge, un maestro de la provocación y yo (que también soy un purista radical)... pero en fondo todos hablamos de lo mismo.

Sabeis, creo que al final todos hablamos de cosas similares e incluso estamos deacuerdo, solamente depende de lo "puristas" y/o técnicos que nos pongamos. Me quedo con algunas afirmaciones de Toad, pues no existen verdades absolutas. Es más, cada uno diseñaría una solución diferente (un modelo) a un mismo problema de un cliente, eso es lo maravilloso del BI, solamente el tiempo y las necesidades cubiertas determinaran cual es la mejor solución.

¿Qué contiene un DW?
* Si nos centramos en el contenido de sus tablas... Data Only.
* Si analizamos sus estructuras y relaciones, pues también tenemos cierta información.
* Si hablamos de su explotación , lo cual ya no es contenido del DW, por personas y que entiendan los resultados, entonces podemos hablar de conocimiento e información.
* Sobre la capa semantica, entendiendola como la nomenclatura que usa, por ejemplo un Business Objects, Microstrategy, etc..., para independizar la terminologia técnica y verla en plan negocio (que poco me he explicado... pero me entendeis), con sus relaciones y todo lo demas, pues logicamente aporta facilidad de uso, entendimiento y supongo que información, pero esto tampoco es contenido del alacemaniento del DW.
* Si hablamos de metadatas Técnicos, podriamos decir de forma general y breve (lo cual no es muy acertado) que es información interna, pura y casi exclusiva de los informaticos y digo casi, pues puede ayudar para indicar al usuario final como se calculo una determionada metrica, etc... por lo tanto tambien aporta su valor. Pero esto tampoco es almacenamiento del DW, además, lamentablemente la mayoria de los DW no suelen tener Metadatas o Metadatas buenos... se intentan hacer parches para evitar el comprar herramientas especificas.

Creo que no me dejo nada, a simple vista...

Saludos a todos,

Jorge Fernández González dijo...

Creo que la he liado... ;-D

Falty; no hay pique ninguno, Chema y yo somos amigos y esto es un divertimento para ambos. Tu mismo me conoces de cuando estabas en mi clase de la UPC y sabes lo que me gusta provocar la reflexión.

Alvaro; Excelente ejemplo, me ha gustado mucho, estoy totalmente de acuerdo contigo cuando dices

"Con el dato 17 fallos (operacional), y la información de que es turno de noche (DW), genero y uso conocimiento, atributo humano."

TOAD; Gran reflexión sobre la que yo no habia caido, "la falta de información tambien es información", me parece algo sobre lo que profundizar y que a mi se me habia pasado totalmente.

Chema; Como siempre genial, estoy de acuerdo contigo en que la metadata técnica no es información de negocio y que el uso del metadata en el DWH (uy perdón DW ;-D) esta muy poco explotado. Y estas dando en la clave de uno de los puntos que quiero abordar cuando dices
" La capa semántica (...) pero esto tampoco es contenido del almacenamiento del DW.".

Y la pregunta es
¿Por qué la capa semántica no es contenido del DWH?

Juro hacer un post o varios comentado todo lo que esta saliendo aquí.

Aprovecho para que los que tengais tiempo os paseis por el Blog de Chema que ha puesto un ejercicio de diseño de DW que promete mucho, aquellos que teneis el gusanillo del diseño de DWH os animo a que aprendais de uno de los mayores profesionalesque hay en España... y gratis!!!!

Unknown dijo...

Que bonitas palabras Jorge, voy a evr si entro en esa Web y aprendo algo de ese machado mental llamado Chema. Bromas aparte gracias.

Vamos a lo nuestro... ya estamos...
"¿Por qué la capa semántica no es contenido del DWH?"

Jorge, pues por que no. Eso es un invento de los fabricantes para dejar de hacer lineas de codigo como locos y para que lo informaticos no hagamos, como años atras, ventanas para fabricar "chorizos" SQL.

Lo cual no quita, para que las estructuras de bbdd que usan estas herramientas las puedas meter en la misma base de datos, pero yo no lo considero DWH ---> perdon DW.

Puesto a ser gallego:
¿Puede existir un DW sin capa semántica?
je,je, je...

Buen fin de semana para tod@s.

Anónimo dijo...

Quizas no me he expresado bien.

Con lo de pique no quiero decir que os peleis, sino que hay un "pique" de puntos de vista, esto no quiere decir que no haya respeto ni sentido del humor, mas faltaria!

Solo queria decir que todas las opiniones en estos comentarios aportan algo al post, no como la mayoria de comentarios en les X millones de blogs.
Por esto suggeria otro modo de seguir la "discusion". Solo una suggerencia.


Pues eso, continuo aprendiendo.

Jorge Fernández González dijo...

Gracias Falty por tu sugerencia, yo intentaré hacer un post de resumen de todo esto.

Estimado señor Arce.
Yo he generado muchos automatismos en mi carrera profesional que creaban chorizo SQL y estoy muy contento :-D

Pero lo de la capa semántica me trae por la calle de la amargura, sinceramente no lo veo claro, no se porqué no se diseña el mapeo de lenguaje de negocio, lo que da sentido a los datos, dentro del propio Datawarehouse. ¿Obtendrimaos algún beneficio?. Hay muchas herramientas (como Cognos y BO) que permiten exportar/importar tu metadata semantica en un modelo standard (la verdad ahora no me acuerdo de que nombre tiene el formato, pero juro buscarlo). y yo me pregunto ¿porque no almacenamos este modelo tambien en el DW/DWH y luego lo importamos con la herramienta que nos de la gana?.


A tu pregunta de si puede o no existir un DW/DWH sin capa semántica mi respuesta es clara y rotundamente si (ahora es cuando me equivoco). Pero ¿tiene sentido?.

Tu puedes crear un DW/DWH y obligar al usuario de negocio a que entienda la codificación informática y funcionará perfectamente, pero el usaurio de negocio sufrirá para conseguir la información.

Es decir, para mi una cosa va tan ligada a la otra que casi no tiene sentido separarla.


Y si vamos un paso mas allá, ¿no me interesaría tambien indicar en que punto del control de los procesos se esta consumiendo la información que almaceno?.

Anónimo dijo...

Buenas noches, después de una cena copiosa en la que me he trincado una botella de vino ... y aprovechando este estado de gracia y lucidez queria comentar varios aspectos sobre la "capa semántica" ... aunque solo sea para generar más polémica.

La capa semantica, es básicamente un metamodelo del modelo lógico de bbdd, luego es SOLO una transformación del modelo original en un modelo más entendible para el usuario.

Y aquí es donde me la juego...

Para mi la capa semantica debería construirse de forma automática vía un compilador de metadata... y me explico, imaginemos que generamos un modelo de datos M y lo enriquecemos con un GRAN conjunto de reglas lógicas RL (Por ejemplo en OCL Object Constraint Language) no creeis que:

M + RL = Modelo de Negocio

Evidentemente cuanto mejor y mayor sea el conjunto de reglas lógicas mejor será el modelo de negocio.

Lo que quiero decir es que si somos capaces de expresar toda la casuistica del negocio vía OCL, la generación del modelo la puede realizar un programa...

Otro tema es que el problema sea computable y tenga una complejidad aceptable...

Pero la idea es que el modelo de negocio lo podemos hacer a mano, o bien, definir bien las restricciones de integridad y hacerlo a maquina de forma automática.

La ventaja de utilizar un lenguaje tipo OCL adjunto al modelo, es que el modelo sera comprensible y unívoco y no dejará espacio a la libre interpretación.

Por favor, si he escrito muchas tonterias borrarme el post.

TOAD y PROTOS

Jorge Fernández González dijo...

¡¡¡¡¡Viva el PROTOS!!!!!!

Jamas habria pensado en OCL y automatizar la generacion del modelo decisional de negocio.Yo estaba mas por ir hacia las ontologías y aplicarles reglas de negocio con motores de BPM.(ups se me ha escapado la sorpresa ;-D)

Pero tu idea me parece fantástica. OCL por debajo,en la capa mas cercana a los datos, junto con reglas de negocio es justo el pegamento que me faltaba para dar el salto entre el dato y la ontología de negocio.

TOAS, Gracias me has dado una gran idea para seguir investigando, porque estaba bastante atascado precisamente con este punto.

Así que el esquema quedaria:

DW + OCL + Business Process Management + RL + Ontologia +Automatismos de creación de código.

Puede funcionar.

¿alguien piensa que estamos chavetas?¿se nos ha ido la olla definitivamente?

o estamos volviendo a generar chorizos SQL como dice JOse Mª Arce.

La verdad es que estoy ilusionado por el cariz que esta tomando este post.

Antonio Valle dijo...

Bueno señores... vengo a cerrar el ciclo... Protos y OCL? Ontologias y DW(H)?

Vamos a poner un poco de orden en todo esto:

He leido afirmaciones impresionantes en este paquete de comentarios, por ejemplo:

"Por ejemplo si yo almaceno en una tabla de mi DWH llamada F_AGG_XRT datos númericos en el campo XR_17 y GT_18 y una fecha en el campo FR_D_34."

Aha!... ningun dato sin metadato!!
y, por favor, que el metadato no sea almacenado en el nombre de la tabla!!! :-)

""Datos", he añadido "Datos estructurados""

Bien, que viva el metadato (again)

"Discurso sobre la importancia de las tres siglas en los acrónimos de prestigio."

Simplemente genial. Lo curioso es que yo me muevo en el universo de las siglas de 4 letras... ITIL, COBIT (ya se que tiene 5, pero la C no cuenta... )

Y volvemos al protos...

¡¡impresionante!!

Lo que mas me llama la atencion es que visto desde fuera... un ERP es lo mismo que un DWH... tambien debe almacenar datos, convertirlos en informacion, tener su metadata y su modelo semantico, y no se que más cosas raras de estas, no?

qué es lo que hace al mundo del BI tan diferente? (la exclusividad de sus usuarios, quizás?)

:-) Solo por echar unas bromas, sin beers&BI

Antonio

Anónimo dijo...

Hola Antonio,

Lo que si que está claro es que cuantas más letras tenga un acrónimo infomático mejor y más importante es (el tamaño importa)... y si no dime, hay algo más largo y más standard que CORBA?

Algo más musical y pedante que la Common Object Request Broker Architecture?

jejejeje
TOAD