Amarillismo en la inteligencia artificial: Sophia el primer robot ciudadano

Este post podría ser considerado la segunda parte o continuación de http://devongt.blogspot.com/2017/08/amarillismo-en-la-inteligencia.html

En las últimas semanas varios medios(incluidos varios medios populares como tech insider) han publicado noticias de “Sophia el primer robot ciudadano” que básicamente presentan como un robot que ha obtenido ciudadanía y lo anuncian como un robot que cuenta con lo que se conoce como “inteligencia artificial general”. Lamentablemente tanto Sophia como sus capacidades anunciadas son completamente falsas y crean en las personas ideas y expectativas falsas de lo que es la inteligencia artificial, sus alcances y capacidades y su estado actual como ciencia. Personalmente llevo algún tiempo ignorando(o incluso sintiendo cierto disgusto) al solo ver el nombre Sophia o su imágen en las noticias, pero algunas noticias en particular fueron las que hicieron que decidiera escribir esto :

• Sophia es entrevistada en vivo por “Tech Insider”(https://www.youtube.com/watch?v=78-1MlkxyqI): en el video se puede ver claramente como el entrevistador lee las preguntas desde su celular, es decir que es una serie de preguntas programadas a las cuales el robot responde por que ya estaban planificadas. Esto no es bajo ninguna definición inteligencia artificial.
• Sophia dice que su inteligencia artificial esta basada en emociones humanas(https://youtu.be/S5t6K9iwcdw?t=180) como : compasión, amabilidad y empatía. La inteligencia artificial actual se basa en modelos matemáticos y estadisticos de tareas específicas basandose en la racionalidad que consiste en realizar la acción mas adecuada (que maximiza o minimiza un resultado) bajo las percepciones del agente, no existe en la actualidad manera de integrar valores humanos o sentimientos en la inteligencia artificial .

Lo que me causa disgusto de el tema, es como los creadores de Sophia estan aprovechando que actualmente la inteligencia artificial es un tema de moda para exagerar y mentir acerca de sus capacidades , y no podemos negar que la mecatrónica de Sophia es impresionante y ha logrado gestos humanos grandiosos, pero de esto a que cuente con inteligencia artificial hay una gran mentira de por medio , y aún mas grande es la mentira de que cuente con AGI(inteligencia artificial general), emociones y sentimientos.Actualmente la AGI es solo un sueño con la que muchos entusiastas e investigadores fantasiamos(probablemente lo mas cerca a esto sea “reinforcement learning” pero aún RF esta lejísimos) , y el tener emociones en la inteligencia artificial es solo algo de ciencia ficción.

Por esto es extremadamente molesto como los medios se aprovechan de el boom y moda actual de AI ya que engañan a las personas, y hasta cierto punto las estafan dandoles expectativas falsas, incluso miedos no fundamentados, y personalmente creo que esto en algún momento puede frenar la investigación o adopción en la sociedad de productos basados en AI, incluso me atrevería a pensar en futuras manifestaciones de la sociedad en contra de AI por culpa de este amarilismo de los medios.

Personalmente creo que esto ocasiona algunos problemas como:

• Crea en el público y sociedad en general miedos no fundamentados como: los robots se van a revelar y nos van a exterminar
• Crea en publico técnico interesado el deseo de incursionar en AI para luego de una curva de aprendizaje bastante grande, darse cuenta que AI en la actualidad no es mas que estadística y matemática para crear modelos y funciones a partir de grandes sets de datos, y no lo que esperaban de robots verdaderamente inteligentes.

 Sophia no es mas que una marioneta mecatrónica ,pre-programada y controlada por inteligencia humana, no inteligencia artificial,no escucha, no entiende lo que le dicen, ni etiende lo que ella dice, no tiene emociones ni sentimientos.Que diferencia hay entre su inteligencia y la de un títere de circo? NINGUNA

Autor: Luis Leal

Idea de investigación: IA clásica combinada con Machine Learning

A diferencia de la mayoría de nuestras publicaciones, esta no es una aplicación  real o buenas practicas en la aplicación de ciertas técnicas ,conocimientos y/o herramientas, es mas bien una idea que ha rondado mi cabeza desde hace algunos años, pero que lamentablemente no he podido experimentar por falta de tiempo y otros motivos. Es posible que alguien mas este investigando y experimentando con esto, o que alguien tenga los fundamentos teóricos para determinar la posibilidad de que funcione o falle, sin necesidad de experimentar.

 La idea se basa en la combinación de 2 sub-áreas de la inteligencia artificial que comúnmente son tratadas por separado e independientes: Algoritmos genéticos y Machine Learning, por lo cual se necesita un poco de conocimiento en estos temas o bien la curiosidad para explorarlos. No entraré a muchos detalles pero por favor si encuentras este articulo navegando por Internet, y ya lo has experimentado o conoces el resultado, o quieres aportar tus ideas , por favor deja un comentario.

Antecedentes

• Algoritmos genéticos: sabemos que los algoritmos genéticos se basan en (como su nombre indica)   el comportamiento a través de generaciones de los  organismos vivos, principalmente utilizando postulados de Darwin acerca de como las poblaciones evolucionan de generación en generación a través de la selección natural y la supervivencia de los individuos "mas aptos".  En ciencias de la computación (y otras ciencias como "data science") , estos algoritmos son utilizados como método de BÚSQUEDA y OPTIMIZACIÓN(en el siguiente párrafo se vera por que escribo BUSQUEDA y OPTIMIZACION en mayúsculas)  ,siendo muchas veces la búsqueda de combinaciones optimas entre un conjunto de opciones o bien la optimización de una función matemática. 
  
  
  
  
• Machine learning: tema  amplio, con muchas definiciones y con gran popularidad recientemente por lo cual no entrare a muchos detalles en su definición, la mayoría de algoritmos de ML se basan fuertemente en estadística , y otras ciencias como matemáticas(álgebra lineal  y calculo),por ejemplo los llamados "modelos parametricos"  se basan en una función de costo (mientras mas preciso el algoritmo, menor costo, y un costo alto significa algoritmo impreciso) , este costo es función de lo que estadisticamente son "parametros del modelo" , y matemáticamente definiríamos como "variables de la función", y nos apoyamos en un algoritmo de OPTIMIZACION para realizar una BUSQUEDA de los parámetros del modelo(o variables de la función) que minimizan el costo  , este algoritmo de optimización siendo comúnmente un algoritmo basado en gradientes(derivadas parciales) para encontrar la dirección en la que mas rápido decrece el costo ,comúnmente "gradient-descent" o derivados.
  
  
  
  

Ya se puede ver por que escribí "OPTIMIZACION" y "BÚSQUEDA" en mayúsculas?  Mi idea consiste en experimentar con algoritmos genéticos , como sustitutos de los algoritmos basados en gradientes , es decir, si podemos utilizar un algoritmo genético como  método de optimización de una función matemática, por que no utilizarlo para minimizar la función de costo de un algoritmo de ML? Viéndolo desde la perspectiva de algoritmo genético como método de búsqueda de combinaciones optimas entre un conjunto de opciones, por que no utilizarlo para realizar la búsqueda de combinaciones optimas de los parámetros/variables en el algoritmo de ML ?  Mi hipotesis es que un algoritmo genético podría ser una alternativa a los algoritmos basados en gradientes, y como en toda ciencia, la hipótesis esta sujeta a resultados experimentales los cuales no he podido realizar, alguien se anima a realizarlos? 

(Si, si, se que los expertos en el tema, y en algoritmos dirán "Pero un algoritmo genetico es un "greedy algorithm" y como todo  greedy algorithm es propenso a mínimos locales, por lo cual no funcionaría, pero los algoritmos basados en  gradientes también sufren este problema y son el casi estándar en la materia, ademas que los investigadores/científicos  han creado métodos para minimizar este riesgo, entonces por que no experimentar?) 

Autor: Luis Leal

Amarillismo en la inteligencia artificial

En este presente año 2017, se ha visto una explosión en los medios respecto a la inteligencia artificial y se ha vuelto una moda que muchos intentan adoptar, lamentablemente su mayor difusión se ha visto acompañada de exageraciones, creación de noticias falsas, especulaciones de robots asesinos ,o de agentes de inteligencia artificial que "cobran vida" y empiezan a comunicarse entre si en un lenguaje que ellos mismos inventaron.  

Este ultimo ejemplo se concretó y  ha sido muy popular en las ultimas semanas, al punto de convertirse viral y ser publicado en múltiples medios ,revistas, periódicos, noticieros etc. Incluso en medios no enfocados a tecnología y ciencias, estamos hablando de una noticia que en algunos medios decía algo similar a :

"Facebook apaga a 2 de sus agentes de inteligencia artificial que cobraron vida y empezaron a comunicarse en un lenguaje que ellos mismos crearon." , esta noticia es exageradamente falsa y nosotros la catalogamos de amarillismo , creada(y compartida) por medios que carecen de conocimiento en la materia ,de los alcances,avances y estado actual de la misma y que se dejan llevar sin investigar o que solo buscan subirse al tren y hablar de un tema que se ha vuelto una moda en el actual año, generar temor en las personas y de esta manera obtener mayor alcance y difusión . Las personas que escribimos este blog seguimos en redes sociales, blogs y sitios de ciencias y tecnología a algunos de los pioneros e investigadores mas importantes de IA y algunos de los comentarios de ellos luego de que este rumor se convirtiera viral fueron:

Yann LeCun,director de ingeligencia artificial en facebook:   Indicó que muchos en su equipo y de la comunidad de investigadores de IA sentían verguenza ajena(facepalming) al ver la noticia,aclaró que FB no había apagado a los agentes por que cobraran vida e inventaran un lenguaje, fue por que simplemente no funcionaban ,y catalogó a estas noticias de alarmistas, y de ser carnada de clicks e incentivó a leer,informarse y preguntar a la gente que se dedica o conoce el tema. 

Ian Goodfellow,investigador en Google,OpenAI y creador del ultimo avance en IA(GANs): Compartió un artículo titulado "No,facebook no entro en pánico y apago un programa que se estaba volviendo peligrosamente inteligente", en su publicación otros investigadores comentaban "Estoy seguro que estamos lejos de eso", "Luego de leer por 30 segundos, lo catalogue como ridículo ".

Lo mas triste de esto, es que muchos conocedores y profesionales de ciencias de la computación y gente que se auto-nombra conocedores de IA han sido engañados y han compartido la noticia, en lugar de desmentirlo e informar a gente afuera del ámbito.

Una analogía que me gusta hacer respecto a esto(utilizando como ejemplo vehículos que se manejan solos es) :

• Antes de 2017:  investigadores vuelven al laboratorio y mesa de diseño, luego de que el algoritmo del vehículo fallara y cruzara un semáforo en rojo.
• En 2017: Empresa automovilística se ve obligada a apagar su vehículo de inteligencia artificial,luego de que cobrara vida y rebeldemente ignorara un semáforo con el objetivo de dañar a su tripulante.

Personalmente llevo varios años en el tema aun antes de su actual "boom"(en mi ultimo año antes de entrar a la universidad, compre mi primer libro(fotocopias) del tema aun que no entendía nada, en 2013 publique un articulo sobre sistemas expertos en mi blog y fui multado en la biblioteca de mi universidad por no devolver el famoso libro de IA de Peter Norvig y en 2014 empece a auto-enseñarme machine learning y deep learning)y sigo de cerca las publicaciones de algunas de las personas mas importantes del tema(como Andrew NG o Yann Lecun)y he experimentado y desarrollado varios agentes de IA y puedo decir que el comportamiento que exhibieron los agentes de FB se da cuando el sistema  esta fallando, su arquitectura es incorrecta, sus hyperparametros deben ser mejorados, o su data de entrenamiento es poca o de baja calidad y NO SE DEBE a que cobran vida y están inventando su propio idioma, aun estamos muy lejos de esto, no olvidemos que la inteligencia artificial se reduce a algoritmos, modelos matemáticos, estadísticos y problemas de optimización.

Como ejemplo de uno de mis proyectos, comparto el siguiente repositorio que consiste en un bot que luego de ser entrenado con literatura de horror de 2 de mis autores favoritos "aprende" a generar nueva literatura que fusiona el estilo de ambos, se puede ver que en los primeros "commits" genera texto completamente sin  sentido(como el de los agentes de FB) y luego esto mejora conforme se experimenta con la arquitectura,hiperparametros y preprocesamiento de datos:

Bot generador de literatura de horror

Espero con este articulo poder aportar un poco a clarificar y desmentir esta noticia amarillista y alarmista.

Autor: Luis Leal

Google Adwords API Wrapper

Este post esta dirigido a software y data engineers o developers en general que deban utilizar la API de google adwords para realizar consumo de datos de google.

Muchas veces , las APIs de google brindan gran poder y flexibilidad al desarrollador pero esto acompañado de complejidad o poca claridad de implementación . Este es el caso de la API de Google adwords , para el escenario especifico de descargar datos de google desde una aplicación o un job programado automático, esta API impone cierta complejidad . Por esta razon creamos un Wrapper orientado a objetos en python que solo necesita una operación luego de instanciar un objeto:

descargar()

Esta operación recibirá de parametros la data que queremos descargar, las fechas deseadas, el formato del archivo de salida , y un flag booleano para indicar si se desea comprimir o no. Respecto al archivo de configuración googleads.yaml ,solo necesitamos indicar su ubicación como parametro al momento de instanciar el objeto(o bien usar el parametro default de Python el cual asumirá que el archivo se encuentra en el directorio home del usuario). De esta manera abstraemos la complejidad de programacion de la API de google adwords a 2 pasos(en pseudocodigo)

1. Crear instancia de wrapper enviando de parámetro la ubicación del archivo de configuración.
2. Ejecutar llamada a operación de descarga de datos enviando de parametro la data deseada, fechas requeridas, y formato de salida esperado.

Este wrapper puede ser integrado facilmente a cualquier aplicación, job automático, herramientas de integración de data(como SAP Data Services o Pentaho Data integration).

El codigo y un ejemplo de uso puede ser encontrado en el repositorio de github:

Repositorio en github

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 2

En continuación a nuestro post anterior: 

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

En este post trataremos otro patrón a evitar al modelar una relación maestro/detalle (encabezado/detalle o header/line) en un modelo ROLAP.   Como bien se mencionó en el post anterior, muchas veces los diseñadores de un modelo analítico (OLAP) están mucho más familiarizado con el diseño de un modelo transaccional (OLTP) por lo cual instintivamente buscan aplicar las mismas técnicas y patrones de diseño olvidando que ambos enfoques tienen objetivos completamente distintos.  En el post anterior mencionamos el error de manejar el encabezado como una dimensión (por ejemplo  una factura en la que el encabezado de la factura es tratado como una dimensión).  En este caso  trataremos el error de manejar tanto el encabezado, como el detalle como fact tables como podemos ver en el siguiente diagrama:

(Los nombres de tablas y campos en este ejemplo no son importantes, lo importante es notar el diseño de 2 fact tables unidas por una tabla foránea)

En este caso, el encabezado ya no es una dimensión, sino una fact table a la cual están asociadas diversas dimensiones (por ejemplo: producto,cliente, sucursal ,fecha). El detalle es a su vez otra fact table relacionada con el encabezado a través de una llave foránea (por ejemplo el número de factura) y adicionalmente otras dimensiones.
Aunque este diseño  representa de manera precisa la relación jerárquica padre/hijo entre el encabezado y el detalle, tiene fallas importantes. Si  bien hemos mencionado antes, en un modelo analítico se busca facilidad de consumo  y tiempo ágil de respuesta , buscando almacenar la información  de manera que se tenga la menor cantidad de joins y cálculos posibles en tiempo de consulta, a costo de un mayor espacio en disco(esto varía en función del motor de base de datos y la tecnología de este, ya que hay motores columnares especializados para OLAP que manejan índices y bitmaps) y procesamiento en tiempo de ETL, asi como tiempo de desarrollo a los procesos de ETL, en este modelo esto no ha sido aplicado , y el poder analizar las métricas a nivel de detalle implica realizar joins con el encabezado  la cual es una tabla casi tan voluminosa (y con ritmo de crecimiento alto)  como la tabla de detalle, y luego realizar un segundo join a las dimensiones. De esta manera el plan de ejecución de la consulta involucra: tabla voluminosa -> tabla voluminosa -> tablas pequeñas(dimensionales).

Luego de ver el problema , y lo que este conlleva,  podemos tocar la solución al mismo, nuevamente esta solución conlleva un patrón de diseño que puede causar incomodidad al diseñador(arquitectos de datos, ingenieros de datos, etc) que está acostumbrado al modelado relacional de sistemas transaccionales pero que luego de absorberlo se verán los beneficios en la agilidad y performance en un sistema de distinto enfoque(analítico) .

La solución consiste en crear una única fact table, cuya granularidad es 1 registro  en el modelo dimensional, por cada registro del detalle en el modelo transaccional, las dimensiones asociadas al encabezado(o maestro) son asociadas a cada  registro de la fact table a través de llaves foráneas a las tablas dimensionales.  De esta forma  se evita el realizar joins enter 2 tablas voluminosas , y el tener que recorrer estas tablas para encontrar los valores distintos de cada dimensión, y así también se genera un modelo más intuitivo y entendible para usuarios de negocio , lo cual cumple con 2 de los objetivos fundamentales: facilidad y agilizad de consumo de información

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

Similar al anterior artículo: Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas  , el presente artículo esta enfocado a arquitectos e ingenieros de datos, específicamente aquellos trabajando en el diseño y construccion de un data warehouse o data mart  haciendo uso de modelado multidimensional.

En el artículo citado se mencionó que existen diferencias en los objetivos y enfoque de un modelo de datos para un sistema transaccional(OLTP) y un modelo de datos análitico( OLAP) y por lo tanto también existen diferencias en los patrones de diseño y las buenas practicas para ambos casos  encontrándose ocasiones en los que una buena practica en un enfoque es un "pecado" en el otro.

El problema esta en que en las universidades y cursos de bases de datos es muy poco tocado el tema de analíticos por lo cual las personas encargadas de realizar un diseño de este tipo, muchas veces desconocen los objetivos, patrones y buenas practicas y realizan el diseño como si se tratase de un modelo transaccional(enfoque que si es tratado a profundidad academicamente)  , muchos otros han aprendido el diseño de analíticos de manera básica a través de otras personas o bien por su cuenta , pero solo conociendo los patrones de diseño básicos por lo cual mezclan ambos mundos.

En el presente articulo atacaremos un error común y la manera recomendada de resolución del mismo.

En un modelo transaccional utilizando el modelo entidad-relación es muy común encontrarse con 2 tablas en relación de uno a muchos en una estructura llamada  "maestro/detalle" en la cual cada registro del maestro o encabezado contiene información  general que es compartida por cada uno de los registros "detalle" asociados.Ejemplos de esto son facturas en los que cada factura(maestro o encabezado)  tiene asociados varios productos(detalles)  o bien ordenes de mantenimiento de equipos en los que cada orden(maestro o encabezado) tiene asociados muchos equipos(detalle),en ambos casos los datos del maestro o encabezado son datos generales y que son compartidos por cada elemento del detalle(por ejemplo numero de factura u orden, o fecha de la operación) .En el mundo transaccional es correcto modelarlo de manera normalizada pensando en los objetivos de reducción de redundancia , facilidad de actualización de datos, integridad referencial  y reducción de consumo de espacio en disco y no olvidando que en este tipo de sistemas operativos, comúnmente un usuario accede y/o actualiza una transacción a la vez, por lo cual en estos sistemas el modelado se hace a través de la estructura mencionada de 2 tablas,1 tabla maestro o encabezado, asociada con una tabla de detalle. Por ejemplo el siguiente modelo de facturación con una tabla para almacenar cada factura y otra tabla de detalle donde se registra para cada factura, que productos fueron vendidos.

Este patrón es muy usado y recomendado para el mundo transaccional , mas no así en el mundo multidimensional donde comúnmente no se accede una sola transacción a la vez si no posiblemente miles y ademas buscamos agilidad, simplicidad , menor cantidad de enlaces(joins) y tiempos de respuesta mas eficientes. Lamentablemente este patrón es muy utilizado ya que representa de manera correcta las relaciones entre los datos y es la manera en la que los diseñadores de modelos de datos se sienten mas cómodos. Esto nos al primero de los 2 patrones a evitar. 

Replicar la tabla maestro(o encabezado) como una dimensión y el detalle como una fact table en el modelo multidimensional

El primer patrón a evitar consiste en prácticamente crear una copia de la tabla de encabezado, como una dimensión en el modelo multidimensional, y el detalle como una fact table. Aun que si es muy común y recomendado  tener una tabla  de detalle como base para  una fact table, es mala practica que esta fact table sea una copia fiel de la tabla detalle y la tabla de encabezado sea una dimensión . Ejemplo:

Hacerlo de esta forma hace que se pierdan muchos beneficios de un modelo multidimensional bien diseñado, como el uso de dimensiones centralizadas,integradas, únicas y compartidas entre diversos modelos(lo cual permite hacer un analisis drill across entre múltiples procesos de negocio) ya que la información contextual o descriptiva  estaría "incrustada" dentro de la dimensión de encabezado, o bien  a través de un doble enlace entre fact table->dimension encabezado -> Dimension descriptiva , lo cual como se menciono en el anterior post también es un patrón a evitar. Ejemplo(Como podemos ver esto ya nisiquiera tiene la famosa forma de estrella):

De esta forma se tendría una tabla dimensional que crece a un ritmo bastante elevado(similar al de la fact table) y un análisis de este proceso de negocio implicaría el acceso a 2 tablas voluminosas(en lugar de una tabla voluminosa y pequeñas tablas dimensionales) .Si se desea analizar solo la información contextual o descriptiva(por ejemplo: listado de clientes o sucursales) sería necesario recorrer toda la tabla(con posiblemente millones de registros) en vez de recorrer una única tabla pequeña, esto puede degradar el rendimiento y tiempo de respuesta. 

Además de esto el campo de enlace(o llave) entre ambas tablas, sería un campo incremental y único que no se repetiría en la fact table , lo cual haría que sea imposible utilizar técnicas de compresión (como por ejemplo compresion bytedict en amazon redshift) o indices bitmap(Sybase IQ) que si podrían ser utilizadas si se manejara como pequeñas dimensiones con pocos valores repetidos muchas veces.

En este post hemos hablado del primer patron a evitar para relaciones maestro detalle, en el siguiente post se explicara el segundo patrón ademas de presentarse un esquema de datos recomendado para  modelar estas relaciones de manera eficiente. Nuevamente estas no son recomendaciones o ideas generadas únicamente por mi persona, si no por los expertos en la materia y creadores del modelado multidimensional. 

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas

El actual articulo esta orientado a ingenieros y arquitectos de datos(principalmente para personas encargadas del diseño y/o construcción de data warehouse siguiendo un modelado multi-dimensional) por lo cual se asume y recomienda familiaridad con la materia.

Existen en la industria buenas prácticas , tips y patrones de diseño comprobadas a lo largo del tiempo y con muchos casos de éxito , pero de igual forma existen malas practicas, errores y acciones a evitar cuando se aborda la tarea de diseñar un modelo de datos para apoyar a la toma de decisiones .

Dentro de estos errores , es muy común el que se presenta en este articulo y también se presentará el método recomendado para manejarlo. Ojo, las ideas propuestas acá(y por los expertos de la industria) entran en conflicto con las buenas prácticas de diseño de modelos de datos que se enseñan religiosamente en universidades y cursos de bases de datos, por lo cual se recomienda terminar de leer el post antes de dejarlo a medias pensando que lo que en el se dice es incorrecto.

El error es: modelar estructuras y jerarquías normalizadas. 

A lo largo de mi experiencia me he encontrado con este error en múltiples ocasiones ,incluso siendo realizado por arquitectos de datos experimentados , pero a que se debe? Principalmente a que como se menciono , esta práctica se evangeliza y se trata religiosamente en universidades y cursos de bases de datos y comúnmente los arquitectos de datos incursionan en el diseño de un modelo de datos de toma de decisiones sin tener en cuenta las diferencias(incluso sin un entrenamiento adecuado) en el enfoque y objetivos de un modelo de datos transaccional(comúnmente relacional) y un modelo analítico(toma de decisiones, descubrimiento de patrones y conocimiento).

En un modelo transaccional , el modelo se realiza pensando en objetivos tales como: captura de información,reducción de redundancia, integridad referencial , disminución de espacio de almacenamiento y para esto se recurre comúnmente a un modelo entidad/ relación normalizado, en el cual se modelan entidades del mundo(o negocio) y las relaciones entre las mismas.

Por otra parte en un modelo analítico , el diseño se realiza con objetivos tales como: consumo de información,toma de decisiones, análisis de indicadores del negocio, facilidad de consumo y entendimiento por parte de usuarios no técnicos, velocidad de acceso a la información ,aplicar pocos o ningún calculo y formulas durante el consumo(durante el query, y hacerlo en el ETL) y que el query sea lo mas "limpio" posible  y es acá donde entra en conflicto el enfoque analítico con el transaccional  ,ya que en el modelo analítico no se modelan entidades y sus relaciones, si no procesos de negocio, las métricas generadas por el proceso  y el contexto o puntos de vista de análisis del proceso y sus métricas(dimensiones)  .En este caso es permitido y altamente RECOMENDADO el tener estructuras de datos redundantes , no normalizadas y sacrificar  la disminución de espacio de almacenamiento .

Entonces entrando en materia(y es acá donde los arquitectos de sistemas y datos encontraran difícil de digerir y aceptar el material)  y  viendo ejemplos reales del error y su solución  , manejaremos 2 situaciones comunes :

1. Modelado de productos y categorías.
2. Modelado de información geográfica(en este ejemplo estado y ciudad)

• Enfoque transaccional: En este enfoque se modelan entidades y sus relaciones,para el primer caso identificando 2 entidades : producto y categoría y la relación entre ambas(un producto pertenece a una categoría y en una categoría se agrupan muchos productos).. Para el segundo caso se identifican 2 entidades: estado y ciudad  y la relación entre ambas(una ciudad pertenece a un estado, un estado contiene muchas ciudades).  Para ambos casos esta es una relación de jerarquía , a nivel físico este diseño implicaría 2 tablas por jerarquía y una llave foránea como relación entre las mismas.A continuación se presenta un modelo ER simplificado(se ha dejado de lado otras entidades y otros atributos de las entidades mostradas con fines de ejemplo)

• Enfoque analítico(dimensional): En este enfoque se modelan procesos de negocio, las métricas generadas por los mismos, y el contexto(descripción,puntos de vista) llamado dimensión en el que se generan las métricas. Para estos 2 ejemplos en vez de 4 entidades(2 para información de producto y 2 para información geográfica) se tienen únicamente 2 dimensiones(seleccionando siempre el nivel mas granular o mas bajo en la jerarquía) , y cada dimensión contiene toda la información de la jerarquía representada , para estos 2 ejemplos , tendríamos que la dimensión de producto, tiene como atributo la categoría del mismo, y la dimensión de ciudad tiene como atributo el estado al que pertenece,esto genera redundancia y rompe reglas de normalizacion  ya que para este ejemplo la categoría se repetiría muchas veces(1 por cada producto en la categoría),pero como se mencionó esto es permitido y recomendado con fines de generar simplicidad de consumo(query fácil de construir) y tiempos de respuesta mas ágiles(query eficiente) ya que ni la base de datos, ni el usuario final debe realizar costosas uniones innecesarias(joins) entre múltiples tablas en la jerarquía. Algo que viene a la mente al arquitecto de datos acostumbrado a modelar de manera relacional , es que esto también genera  un mayor costo en disco pero se deben tomar 2 cosas en cuenta:
1. El mayor costo de disco es permitido y es el precio a pagar por la simplicidad y tiempo de consumo de datos.
2. Comúnmente los modelos analíticos son implementados sobre bases de datos columnares(como Amazon Redshift o SAP Sybase IQ), diseñadas con este tipo de modelado en mente y utilizando internamente estructuras como bitmaps(o indices bitmap) para almacenar una única vez cada valor diferente de la columna y acceder al valor a través del bitmap,logrando así una compresión significativa. Crear un modelo normalizado(y jerarquías con múltiples tablas) en un motor columnar, es desperdiciar y desaprovechar  las capacidades(Y la alta inversión económica!)   y enfoque del mismo.

          Podemos concluir entonces, que es recomendable no tener(o tener un mínimo) jerarquías de múltiples tablas(y las relacione entre ellas) y tener únicamente una tabla con el nivel mas bajo de la jerarquía y agregar el resto de datos de la jerarquía como atributos de la tabla,Y tener un único nivel de unión(de  fact table a la dimensión) aun que esto represente generar redundancia y romper normalizacion.

Esta recomendación no es algo generado por mi persona, lo recomiendan los expertos de la industria(incluso los creadores del modelado dimensional) como podemos ver en las siguientes referencias. Espero que esto sea de utilidad para generar mejores modelos analíticos.

Ver mistake #1

http://www.dataintegration.ninja/mistakes-bottom-up-datawarehouse-development-approach/

Ver rule#6

http://www.kimballgroup.com/2009/05/the-10-essential-rules-of-dimensional-modeling/

O bien, en el libro "The data warehouse toolkit", capitulo 8 ,pagina  398 ver : Mistake #8

Autor: Luis Leal