miércoles, octubre 15, 2008

Tengo una ... Pregunta 3 por David Piura

Pregunta 3 por David Piura:

Formas normales para sistema ROLAP Para los sistemas con tablas relacionales, conocidos hasta ahora, usábamos las 9 formas normales para evitar errores en el diseño de nuestro sistema. Mas información aquí http://es.wikipedia.org/wiki/Clave_ajena

Existen algun tipo de formas normales en las tablas multidimensionales ROLAP? Parece ser que al diseñar estas tablas, nos e siguen las mismas directrices, sino que se saltan algunas de ellas. Existe algune squema estandar para el diseño de estas?
Gracias


Hola David, sin entrar a discutir la existencia real de 9 formas normales, te adelanto que en DW no tienes la necesidad forzosa de aplicarlas. También estarás condicionado por el tipo de modelo de negocio diseñado.

En los modelos en estrella, por ejemplo, no se aplican dichas reglas dentro de los conceptos de dimensión, es decir, una única tabla por dimensión con tantas columnas como atributos o conceptos pueda tener la dimensión. En este caso tampoco puede usar la integridad referencial, pues no puedes referenciar a dos atributos de la misma tabla entre si (definir relación “n” a “m”). Si vas siguiendo mi explicación podrás ir detectando ciertas bondades y serias limitaciones para garantizar la consistencia de los datos y en especial la rigidez o costes ocultos ante posibles cambios.

En los modelos en copo de nieve, pueden ser (dentro de una dimensión) perfectamente en tercera forma normal. El uso u optimización de “desnormalizaciones inteligentes” vendrá condicionado por la herramienta que uses, pues muchas de ellas no son capaces de interpretarla o aprovecharla. AL igual que en el caso anterior, depende como lo montes puedes tener una maravilla de modelo y con optimas capacidades de escalabilidad, pero también más complejo, con más entidades y con sentencias de consulta SQL más complejas. Sobre la existencia de algún esquema estándar, pues diría que no. Yo te remitiría a la pregunta 1, cuando explicaba el simil de la cabeza del ciervo. Puestos a trucos, te digo alguno: uso de claves simples, evitar relaciones “n” a “m” dentro de la dimensión (evitando errores de calculo con herramientas finales)… iremos comentando más.

Se podría hablar mucho sobre ventajas e inconvenientes… lo dejo a vuestra reflexión.


Apreciado David P., espero haber contestado a tus preguntas, me quedan unas tres más por analizar y contestar.
Salu2,
Chema Arce.

martes, octubre 14, 2008

Tengo una pregunta para usted - Pregunta 2

Pregunta 2 por RojoUno:
Tengo una pregunta, dentro de la arquitectura OLAP, MOLAP, ROLAP, etc., para proyectos BI se consideran sólo las herramientas propietarias como Microstrategy, BO, MIS, Hyperion, etc? O tambien se encuentra el modelo dimensional llemese de etrella o copo de nieve que uno implementa?. No se si me explico, por ejemplo uno en los proyectos ya sean DWH o Datamart crea un modelo analítico pero siempre para ser accedido por estas herramientas, en consecuencia siempre habrá una dependecia entre el modelo y la herramienta de análisis. Tambien entiendo que los motores de estas herramientas son los denominados OLAP, MOLAP, etc. Anexo tambien que estas herramientas pueden obtener informacion directo desde modelos relacionales como por ejemplo un ODS.

Un proyecto BI puede consideran una solución de principio a fin, es decir, el acceso a las fuentes, una herramienta ETL, una o unas DDBB con modelos específicos (DW) y unas herramientas de explotación. Pero como podras imaginar en informática no hat nada 100% cierto. Muchas soluciones o proyectos no cuentan con herramientas ETL, debido a su coste o puesto que el origen de los datos es claro, en pocas fuentes y no se cree necesario. La única pieza que es vital en el propio DW, con independencia del tipo de modelo diseñado (aunque siempre OLAP). La lógica dice que si tenemos un buen modelo se debe explotar, entonces que mejor que usar soluciones o herramientas ya existentes. ¿Merece la pena volver a reinventar la rueda?. Por eso motivo siempre encontraras herramientas para explotar los DW o DMarts.

Sobre dependencia entre modelo y herramienta. Esto es más relativo. Yo personalmente informo a mi cliente sobre las ventajas al optimizar para una herramienta definida y los inconvenientes. El cliente debe de decidir pero siempre asesorado por nosotros.

Sobre motores ¿Multidimensional o Relacional?. Lo primero que haría sería aclarar algún concepto. Las soluciones de Data Warehousing se apoyan sobre modelos de negocio con características OLAP (SI y siempre SI). Dentro de este tipo de características podemos utilizar un motor multidimensional propietario y entonces se denominan MOLAP (Essbase, Oracle Express, MDDB SAS, etc.), en el caso de ser simulada la multidimensionalidad a través de gestores relacional se denominan ROLAP (Oracle, Informix, SQLServer, Ingres, etc.). Llegados a este punto todavía no hemos hablado de tipos de modelos, me refiero a las estrellas o al modelo copo de nieve y tampoco hemos hablado de “formas normales” ni de “integridad referencial”.

Por cierto, existen otras terminologías en el mercado, algo ridículas o fruto de pájaras del marketing, como por ejemplo: JOLAP o DOLAP. Están anotaciones no obedecen a gestores de datos o incluso al propio OLAP, en el caso de JOLAP nos indica que el acceso a la DDBB se realiza mediante JAVA… ¿y que me importa? O DOLAP indica que se descarga los datos al escritorio del usuario y mientras no pida nada nuevo (fuera del set de datos) solo consulta los datos ahora locales, pues bueno, vale, depende para que puede ser bueno o no.

Ojo sobre el tema del ODS, debería preguntarte que entiendes tú por ODS. En el mercado existen dos conceptos asociados al ODS y son diferentes. Sobre si las herramientas pueden obtener información de modelos relacionales, SI. Incluso cuando están mal diseñados y con severos errores conceptuales (algo demasiado habitual). Las herramientas son tan potentes, todas, que logran subsanar algunas deficiencias del supuesto “arquitecto de datos DW” o por lo menos al principio, después es posible que empiecen a degradar el sistema. Cuando esto ocurre se suelen embarcar en generar tablas agregadas por todas partes para mejorar los rendimientos, cuando existen otras muchas cosas a verificar. Bueno esto será otro debate.

Apreciado RojoUNO, espero haber contestado a tus preguntas.
Salu2,
Chema Arce.

lunes, octubre 13, 2008

Tengo una pregunta para usted - Pregunta 1



Para hacer un diseño, buen diseño, mediante el sistema OLAP, hay algún truco, algún esquema, algún sistema general para diseñar y corregir? o se hace a ojímetro y lo vas ganando con la experiencia(que en mi caso es nula).
Si a la estrella le vamos añadiendo más y más puntas......habrá demasiadas dimensiones y si no le añadimos, no podremos desgranar la información que queremos. Sera esta la regla básica?.

Con independencia de la existencia de metodologías que te pueden servir para abordar un proyecto de Data Warehouse, voy a contestarte desde el punto de vista práctico y sin meternos que charcos demasiado grandes para ti u otras personas.
¿Trucos? Pues si existen. Fruto de años de participar en este tipo de proyectos, uno poco a poco va aprendiendo cositas y las aplica en el beneficio de los clientes. Sobre tu pregunta sobre un sistema para diseñar un OLAP, solamente existe un truco: escuchar bien las necesidades de los usuarios finales (ojo, no cualquier charlatán que piense tener bien claras las ideas), intentar obtener que tipo de requerimientos desean, informes tipo y cualquier concepto de negocio necesario. Tras obtener todo esto, es cuando nuestro trabajo tiene más fuerza. Si hemos entendido bien los conceptos y las necesidades podremos diseñar un buen modelo, de lo contrario no haremos nada bueno.


Un modelo debe poder controlar correctamente el negocio y éste lógicamente tiene variaciones con los años. Magia no podemos hacer y lógicamente si estamos montando un sistema de BI para un taller, no vamos a controlar que mañana decidan vender también coches o por lo menos no a priori. Pero si es lógico pensar en las piezas son suministradas por proveedores y que estos pueden cambiar con cualquier tipo de frecuencia, que los precios de coste y los de venta también, que existirá un stock de las piezas, etc… Este tipo de cosas, y muchas más, son aquellas que obtienes con la experiencia y que en ningún sitio podrás aprenderlas, siendo por lo que muchos de nosotros tenemos un determinado “caché” o salario.

Sobre tu segunda pregunta… las puntas de la estrella. Bueno de forma muy básica, por el momento y hasta nuevas preguntas, existen dos tipos básicos de estructuras (y combinaciones) las estrellas y el copo de nieve. Si nos ponemos a dar un charlón de cátedra demostraríamos que son la misma cosa, pero tratadas o almacenadas diferente.

Uno puede añadir tantas dimensiones como quiera o como pueda, el secreto es más bien saber que es una dimensión. Pues haciendo bien las dimensiones y para un grupo de métricas a analizar no saldrán muchas, en caso contrario estoy convencido de que tienes un error de concepto en algún sitio.

Según teorías de libro, si tienes más de 10 dimensiones el usuario final del sistema empieza a tener problemas para saber intepretar la información y en función del tipo de BBDD que utilices puedes empezar a encontrar limitaciones. No es lo mismo ir contra un gestor relacional, que contra una multidimensional propietaria, que contra alguna BBDD orienta a objetos.

La grandeza de un modelo, por hacerlo entendible, está en la capacidad de cruce de sus distintas estrellas.
Un último ejemplo que creo ilustrativo, siempre lo uso en mis Master. Una estructura o estrella es como la cabeza de un ciervo.

La cabeza es la tabla de hechos a analizar, la cual contiene todas las métricas necesarias. Cada cuerno es una dimensión, en el ejemplo del ciervo 2 dimensiones. Lo cual implica que dentro de cada cuerno existen muchas ramificaciones pero no por ello son otras dimensiones. Siguiendo con el ejemplo, las dimensiones nunca se tocan entre sí. El único punto en común entre ellas son las tablas fact.


Hasta pronto.
Chema Arce.

Tengo una pregunta para usted!!!!



Hola Chema, te saluda David.
No nos conocíamos, pero tenemos algo en común. Que nos gusten las bases de datos. He llegado a tu página buscando acerca OLAP, porque he decidido que mi proyecto de fin de carrera sea acerca este sistema. Me encuentro que leo y leo, pero tengo preguntillas básicas que no se hacia donde encaminar.
Cuando estudié Sistema Gestor de Bases de Datos, al crear el diseño de un sistema con tablas relacionales, teníamos unas formas normales que te encaminaban hacia el correcto diseño.
Para hacer un diseño, buen diseño, mediante el sistema OLAP, hay algún truco, algún esquema, algún sistema general para diseñar y corregir? o se hace a ojímetro y lo vas ganando con la experiencia(que en mi caso es nula).
Si a la estrella le vamos añadiendo más y más puntas......habrá demasiadas dimensiones y si no le añadimos, no podremos desgranar la información que queremos. Sera esta la regla básica?.
GRACIAS y perdona mi ignorancia. Un día sabré mucho y enseñare a otros, pero ahora.....solo soy un futuro ingeniero(a falta de 1 asignatura y el proyecto)



Gracias David P.M. por ponerte en contacto conmigo. En el pasado era un hobbie contestar a muchas personas e incluso ayudarles con sus tesis de carrera. Este hobbie lo fui abandonando por diversos motivos: yo nunca aprendía nada, la gente ni tan siquiera era agradecida, pasado el tiempo jamás volvían a contactar, al final tampoco me dejaban ver sus tesis (que terminaban siendo como hijos míos), en definitiva, por culpa de la mayoría deje de atender a otras buenas personas.

Hoy contigo, tras leer tu correo, vuelvo a intentar ayudar. Dado que cada vez tengo menos tiempo para escribir, tanto en mi blog como en las revistas en las cuales colaboro, voy a iniciar un nuevo camino, una especie de blog de preguntas y respuestas.
Por ello, queda inaugurada esta nueva sección "TENGO UNA PREGUNTA PARA USTED", gracias a ti.
Espero poder ayudar a muchos y que sepais apreciar este esfuerzo y este gesto.
Un cordial saludo para todos.

Seguidores