Hola a tod@s, Sin duda este capítulo de “Design a Data Model” ha sido el más denso hasta ahora, al menos para mí. La granularidad siempre me ha traído de cabeza y la forma de tratar las relaciones “many to many” también. Las posibilidades que nos permite el apartado de “model” para formatear las tablas y columnas es enorme y la opción de trabajar con los sinónimos nos facilitará enriquecer el apartado de Q&A. Una parte muy poco explorada son las medidas rápidas, la forma de construir esas medidas está optimizada y sirve para aprender a construir mejores medidas. A partir de éstas descubrí la funcionalidad de “ISONORAFTER”, es un poco confusa por la función del último parámetro (al menos para mí). Las jerarquías Padre-Hijo las aprendí a construir via Power Query copiando lo publicado por otros. Ya sabemos pues como construirlo en DAX. La creación de la “Common data table” es todo un mundo y cada uno tiene su preferencia. según el modelo podemos pasar con tres funciones DAX o complicarnos lo que queramos. Lo del “Role Playing dimensions” me ha generado muchas dudas. Si queremos filtrar por distintos campos de fecha no queda otra que duplicar el “Calendar”, lo cual es independiente de la relación que utilice una medida que podría activarse con la función “USERELATIONSHIP”(así lo he entendido). La cardinalidad hace referencia a la cantidad de elementos que se relacionan desde una tabla a otra. Por otra parte la Granularidad se refiere al detalle de los datos, que puede ser distinto dependiendo de la tabla en que se encuentre. Habrá que volver más de una vez a este capítulo, lo presiento. 

Buen día para tod@s, ¿Qué aprendiste en la sección “Design a Data Model”?

• Buenas prácticas: Ocultar columnas que no se va a utilizar. Organizar mi modelo en la parte de arriba las tablas de dimensiones y en la parte de abajo la(s) tabla de hechos.
• Las diferentes jeraquias que puede existir en una tabla y cómo dar solución con las funciones de DAX: PATH (Entidad, Entidad Padre).
• La importaciones que tiene la creación de una tabla calendario para el análisis de nuestros datos.
• La importancia de “role plating dimensions” para dar solución a la relación entre tablas que ya tienen una relación.
• La solución para resolver “Many-to-Many relationships” que se puede crear un tabla con valores unicos y luego crear una relación para cada tabla respetando la cardinalidad de uno a muchos.

¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Uno de los puntos que quiero recalcar es el tema del modelo de estrella, en ciertas ocasiones si me ha tocado trabajar con el modelo copo de nieve ya que las tablas en la base de datos tiene un relación así pero no se me paso por la cabeza tener una única tabla producto haciendo un “Merge Query” entre estas tabla de dimensiones (Subcategoría y Categoría). Seguro para nuestros proyectos lo utilizaré. Cómo te servirá esto que aprendiste al presentar el examen de certificación? La verdad me ayuda mucho a reconocer la terminología y aprender como se llama cada uno de los puntos que se ve en el curso y que seguro existirá preguntas con estos términos en el examen. También en el enfoque que Diego nos esta guiando para tener diferentes caminos a la hora de analizar y contestar cada escenario. Saludos, Santiago

• ¿Qué aprendiste en la sección “Clean, Transform, and Load the data”?

1. Diferencia entre una consulta y una Tabla.
2. Definir Quick Measures.
3. Flatten out a parent child Hierarchy (Aplanar Jerarquías).
4. Realizar el “Performance Requeriment” (Utilizar esquema Estrella).
5. Creación de “Common date Table” (Tabla Calendario).
6. Definición de la Cardinalidad de las relaciones y la dirección del flujo de datos (Relationship’s cardinality" y “Cross filter Direction”).
7. Definir “Role Playing dimensions”.
8. Cómo resolver un caso de relación “Many to Many”.
9. Definición de la granularidad de datos.

. .

• ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI?

1. Manejar la diferencia de estos conceptos ayuda a tener mayor claridad de cómo se comportan los datos, quién es el que provoca que los datos se estructuren de cierta forma (Query) y cómo estos datos se visualizan de manera ordenada (Tabla).
2. Utilizar la opción de Quick Measure será útil para tener una base de fórmula DAX y así poder trabajar una nueva medida junto con Calculate.
3. Servirá para tener organizado los datos por criterio de relevancia, utilizando la fórmula de DAX: “PATH” y “PATHITEM”
4. Será útil para las buenas prácticas en la fórma de relacionar tablas de manera ordenada. Aquí se aprendieron conceptos nuevos como:
   • Fact Table: Tablas de Hechos la cual se caracteriza por tener un registro continuo de eventos, donde se pueden visualizar datos como: transacciones de venta y movimiento de inventarios. Se caracteriza por ser la tabla larga.
   • Dimension Table: Tabla que contiene el detalle de los dato de la tabla Fact Table. En este tipo de tablas se pueden ver datos como: Nombre de los productos, Datos de clientes o empleados.
   • Una de las buenas prácticas enseñadas en este item es dejar todas las tablas catalogadas como Dimension Table en la parte superior y las tablas Fact Table en la parte inferior.
5. Saber que este tipo de tablas nos ayuda a conectar 2 Fact Tables. Además este tipo de tabla se puede crear con DAX con Calendar o en el editor de consultas con “List.Dates”
6. Es importante saber el tipo de relación que habrá entre tablas y para eso es importante saber que los tipos de relaciones existentes son:
   • Many to One
   • One to One
   • One to Many
   • Many to Many
   • Junto con esto es importante saber desde donde fluirá la información y si solo tendrá una dirección (Single) o será bidireccional (Both)
7. Este punto nos enseña a crear una nueva relación entre 2 tablas, sabiendo que previamente ya existe una, por lo tanto la forma será crear una tabla calendario para relacionarla con otra tabla.
8. Servirá para cuando ambas tablas tengan datos repetidos (Fact Tables) en los campos que se usarán para crear la relación, crear una nueva tabla con un solo campo y datos únicos y así transformar la relación Many to Many en One to Many.
9. Saber cómo varía la granularidad dependerá del nivel de detalle . .

• ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación?
  • Creo que esta unidad es muy densa e importante para el examen, ya que es el paso siguiente a lo que fue Limpieza y Transformación de datos. No basta sólo con generar una limpieza adecuada sino también a cómo relacionar estos datos para posteriormente entregarle un buen reporte con la información que el cliente nos solicitará.

• ¿Qué aprendiste en la sección “Design a Data Model”? Resp. Esta ha sido la unidad mas interesante completa e importante, todos los conceptos son fundamentales ya que tener el Modelo bien diseñado es clave para poder realizar los reportes. Si en esta etapa hay errores estos afectaran a todo el trabajo que se realice sobre él.
• ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Resp. La importancia de comenzar un Proyecto realizando el Modelo de datos y las Relaciones de Tablas antes que colocarse de cabeza a realizar reportes.
• ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? Resp. Todas las unidades del Modulo Design data son importantes los conceptos de Quick measures, Jerarquías, Esquema Estrella, Tabla Calendario, Cardinalidad y la Role Playing Dimensions son todos conceptos que seguro los van a preguntar.

Hola buen día. Les comparto mis respuestas • ¿Qué aprendiste en la sección “Design a Data Model”? Diseñar un buen modelo de datos es algo muy importante para poder optimizar desde un inicio nuestros informes que consumirán los usuarios, saber que tipo de relaciones usar, crear tablas para poder crear nuevas relaciones entre cada una de ellas. • ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI?} Aplicar lo aprendido en los informes que ya están visualizando mis usuarios del negocio y corregir si omití alguna relación importante o alguna configuración de las tablas que estoy utilizando, validar que las relaciones entre mis tablas sean las correctas. • ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? Poder entender y comprender cada uno de los términos aprendidos en esta sección, la verdad que con los ejemplos nos ayuda a comprender de mejor manera por que es tan importante cada tema y como aplicarlo en un escenario mas real. Saludos…

Buenas noches, Un capitulo denso y con bastante información que procesar, me llamó la atención la parte de jerarquía, me dio una idea para un proyecto que tengo pendiente. Las buenas prácticas, algo que se debe mantener, esto me gustó mucho. El Many-to-Many relationship no lo veo claro y entiendo porque no lo recomiendan, la posibilidad de mezclar información es muy alta y si no tienes un fuerte conocimiento de BBDD seguro tendrás problemas. Quick Measures, aunque ya había visto en un webinar con Ana María Bisbé York que es una excelente herramienta para aprender DAX. La tabla calendario es muy importante, en otro curso con Miguel Escobar en poweredsolutions.co me quedó claro y de ahí fueron mis inicios con Power Query, fue un antes y un después en mi vida laboral con Excel, se logran grandes cosas y la tabla calendario prefiero también hacerla en Power Query. Un excelente materialmente para tener en cuenta en el modelado de datos. Gracias

Me pareció una sección muy completa y con muchísimos conceptos que se pueden ampliar. Saco como aprendizaje la forma de ordenar el modelo con las Dim Tables y las Fact Tables, el uso de las Quick Measures, la forma de crear jerarquías padre-hijo, el uso de la tabla CALENDAR y las distintos tipos de relaciones. También me gustaron las fórmulas DAX que se aplicaron, como por ejemplo CALENDAR, PATH, PATHITEM, CALCULATE y USERELATIONSHIP. Todos estos son conceptos fundamentales a la hora de preparar los datos para crear buenos reportes.

Buenas tardes, Excelente lo de las jerarquías, justo acabo de resolver algo como eso pero por medio de power query haciendo relaciones sobre la misma tabla y expandiendo, pero esto me parece bastante útil también. Lo de la tabla calendario bastante útil también , siempre la creaba en DAX y con un proyecto quería tenerla en power query para poder hacer otras transformación, ya con esto lo podré hacer. También lo de la tabla intermedia o puente muy útil, ando resolviendo algo así creo que me ayudará hacerlo por medio de merge en vez de tener dos tablas sueltas y pasar ese modelo como copo de nieve que tengo a uno más parecido al estrella. Saludos,

Me alegra que ya estés incorporando estos conocimientos nuevos en tus propios desarrollos, Javier. Gracias por compartir 

• Aprendí el tipo de relaciones posibles entre tablas, cardinalidad y dirección filtrado
• Más granularidad de los datos
• Manejo de Jerarquías
• Modelo con mas de 1 fact table
• Relaciones activas e inactivas como manejarlas, con DAX o bien con creación de otras tablas

Buenos días, En definitiva de lo que voy viendo del curso, esta sección es las mas extensa y también con mucha información a rescatar, de todas maneras si no tienes un buen modelado de datos, las cosas que se quieran realizar en Power BI van a ser limitadas Haciendo un resumen de lo aprendido, se pudo observar inicialmente las diferencias entre lo que es un query (codigo) y una tabla (datos almacenados), también como esconder u ocultar una tabla o columna, cambiar formatos y crear formatos personalizados a las columnas, desde el modelado y sus propiedades. La creación de medidas rápidas (quick measures), que nos permite desde ya ir viendo como se puede generar con un código DAX y también toma su estructura como buena practica de creación de medidas. La creación de aplanación de jerarquías, utilizando las funciones PATH y PATHITEM Algo muy importante y que creo que es básico saber, son las especificaciones de lo que es una fact table (tabla hechos) y una dimensión table (tabla de dimensiones), ya que esto ayudara para la creación de los distintos modelos, como el modelo estrella, copo de nieve, etc La tabla dim de calendario muy importante para poder hacer los evolutivos en la historia La creación de relaciones , cardinalidad y tipo de filtrado, creación de roles de tablas Saludos.

En este tema he aclarado algunos conceptos y aprendido nuevos puntos como:

• Diferencias entre Query y Table
• Aplanar jerarquías. Aunque creo que en el caso de que la jerarquía pueda tener 10-15 niveles o más, la forma de hacerlo manual, creando columnas nivel por nivel no es la más eficiente.
• Ya había leído sobre los modelos de estrella y de copo de nieve, y con esta sección tengo claro que hay que buscar el modelo de estrella en PowerBI siempre que se pueda (en la vida real suele ser complejo) ya que es de esta forma que está optimizado.
• Las formas de unir una tabla que tenga varias fechas, mediante las uniones activas o no activas y las formas de trabajar con ello mediante el Role playing dimensions.
• Como resolver las many-to-many relationships, creando tablas auxiliares para buscar siempre las relaciones uno a varias. Hay que recordar que las relaciones 1 a 1 no son eficientes ya que se podrían juntar en una tabla mediante un Merge.
• Los temas de granularidad que son muy importantes cuando tenemos muchos datos.

También me han surgido un par de dudas, a ver si alguien las pudiera resolver:

• Si seleccionamos en el Cross filter direction igual a Both, ¿hay algún tipo de problema a nivel de rendimiento?
• En la parte del role playing dimension, si yo solo quiero tener un filtro de fechas, ¿es mejor que utilice la función de DAX USERELATIONSHIP, ¿no?. El hacer una tabla Calendario auxiliar, entiendo que no me ayudaría.

Muchas gracias 

Genial Jose, Con respecto al rendimiento, creo que no afecta… Sólo hay que tener cuidado con ellas, ya que hay que recordar que las relaciones transmiten el filtro en las tablas. Por lo que, si se detecta un conflicto en el flujo de los filtros, te va a crear relaciones inactivas. Esto es muy común cuando comienzas a agregar la dirección del filtro cruzado en ambas direcciones, en varias relaciones. Con respecto a la role playing dimension, va a depender del caso que quieras desarrollar con tus slicers… Si solo quieres aplicar el filtro utilizando una dimensión, USERELATIONSHIP te servirá. Si quieres aplicar varios filtros de fecha, sí requerirás la tabla adicional. Saludos!

Hola! Buenas noches! en esta sección he aprendido muchas cosas, no dejo de sorprenderme de este curso! me tiene muy motivada de seguir adquiriendo mejores prácticas!

• Usar sinónimos para Q&A -Importancia del modelo de datos estrella. Diferencias con el modelo copo de nieve. -La tabla de hechos y las tablas de dimensiones deben tener una única función (transaccional o descriptiva) -Common date table! muy buenas explicaciones! más que agradecida! -Sólo se puede tener una relación activa entre dos tablas.

Muchas gracias! un curso más que completo!

Hola a todos, este capítulo me sirvió para entender el uso de las jerarquías y sobre todo la aparición de la línea punteada que no entendía su implicancia y cómo resolverla. Antes de este capítulo he tenido que mostrar datos para 3 fechas diferentes en un mismo gráfico y no lo he podido realizar así que me sirvió para resolverlo. El uso de medidas rápidas me aclaró como se realiza la construcción ordenada de código DAX que había estado experimentando mirando otros vídeos. La creación de nuevas tablas de calendario me resultó útil ya que las venía creando desde Excel Saludos

Buenos Días Crear la Tabla calendario desde el query editor ha sido un gran descubrimiento ya que desconocía que podíamos utilizar el código M para crear dicha tabla. Esto lo aplicaré en mi trabajo ya que todo lo hacía usando la función dax Calendar. Esto permitirá optimizar mi modelo. También aprendy el manejo de jerarquias Parent-child usando la Función Path. Sigo aprendiendo en cada módulo. Muchas gracias

Hola a todos, Este modulo fue muy importante, al igual que los otros módulos aprendo sobre cosas que ni siquiera sabia que estaban o como usarlas, como las propiedades de las tablas y las columnas, saber que se pueden ocultar tanto tablas como columnas, en cuanto a la linea punteada que se observa en algunas relaciones de tabla me agrado saber que es una relacion inactiva y que hay maneras de solucionarlo al igual que como solucionar las relaciones muchos a muchos agregando una nueva tabla de dimensiones. En cuanto a los filtros cruzados, y la dirección en la que fluye la información aprendí la importancia de que sea en un solo sentido, de arriba a abajo, teniendo en cuenta que arriba es la parte del modelo en donde se encuentran las tablas de dimensiones y abajo las tablas Fact o de Hechos. Gracias, Julio C

Desconocia los concptos de cardinalidad y el cross filter en las relaciones, muy importante considero el profundizar un poco en el tema para resolver el no tener resultados inesperados que pueden no ser vistos a primera instancia

Wooowww, buenisimo el apartado de Desing a Data Model, me quedo con la experiencia de crear una funcion como, Userelationships dentro de Calculate. Como bien menciona Isidre, creo que si vamos a tener que volver a ver el apartado en otra ocasion para reforzar pero esta muy bueno. Ahora una consulta diego en el ejemplo que mencionas en "Cross Filter Direction o relationships cardinality, me gustaria tener los archivos para practicar.

• ¿Qué aprendiste en la sección “Design a Data Model”? Que la práctica hace al maestro, claramente el conectar tablas y saber que relaciones son las más adecuadas para un modelo versus otro te lo da la la práctica ya que si bien la teoría es clara la aplicación es lo complejo
• ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Reforzar lo que ya conozco de bases de datos relacionales, refrescar un poco lo aprendido hace unos años para hacer modelos más eficientes
• ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? Poder tener más conocimiento sobre power Bi para enfrentar las preguntas relacionadas a este tema

¿Qué aprendiste en la sección “Design a Data Model”? En esta sección recorrimos 10 temas: 1. Definir las tablas: Aprendí la diferencia entre consulta y tabla. En el Query Editor se realizan las consultas para definir las tablas que se usaran en el modelo. La ultima vista de cada consulta es la tabla del modelo. Las tablas se guardan en el modelo, las consultas no se guardan, solo generan códigos para definir las tablas. 2.Configurar las propiedades de las tablas y de las columnas: Desde la vista de relaciones, en el modelo de datos, están las propiedades de las tablas y columnas. Para las tablas podemos cambiarles el nombre, darles una descripción de su uso al usuario, agregarles sinónimos, definir una columna como el indicador de las filas, ocultar la tabla, y definir el modo de almacenamiento ( storage mode ). Para las columnas podemos cambiar el nombre, darle una descripción, agregar sinónimos, crear folder para agruparlas, ocultarlas, darle formatos ( cambiar el tipo de datos, formatear números y fechas ), opciones avanzadas ( podemos establecerle un orden ( sort ), categorizar los datos, opción de resumen y si admiten valores nulos ). 3. Definir “quick measures”: Aprendí que podemos usar este menú para realizar algunas medidas en forma rápida, sin tener que escribir el código DAX. 4. Flatten out a parent – chid hierarchy”: aquí aprendí hacer una tabla de jerarquía. Utilizando la función path de DAX. Nos permite crear una tabla con diferentes niveles que va sumarizando un nivel inferior a otro superior como lo hacen los catálogos de cuentas. 5. Diseñar el modelo de datos para conseguir el “performance requirement”: Es la sección mas importante del modelo de datos. Trata de la estructura que deben tener las bases de datos en el modelo para que funcione en armonía y optima con powerbi. La estructura recomendada es la “Estrella”, donde las tablas de dimensiones se relacionan directamente con las de hechos. Esto es el secreto del funcionamiento optimo de powerbi. 6. Crear una “Common date table”: Se trata de crear una tabla calendario maestra para todo el modelo. Facilita la inteligencia de tiempo y las relaciones de las tablas. Es de suma importancia. 7. Definir la “relationship’s cardinality” y las “ cross-filter direction”: Este tema trata de la manera como definir las relaciones y los flujos de informaciones entre las tablas. 8. Definir “ role playing dimensión”: En este tema aprendi a definir una tabla de dimensiones para facilitar las relaciones y la obtención de informaciones de las tablas de hecho. 9. Resolver las “many-to many relationships”: aqui aprendimos a resolver las relaciones de mucho a muchos entre tablas. Evitar este tipo de relaciones nos ayuda con la cardinalidad de las relaciones entre tablas, o sea la forma en que fluye la información de una tabla a otra, que debe ser preferiblemente de una a muchos y desde una tabla de dimensiones a una de hechos. 10. Definier el nivel apropiado para la “data granularity”: En este tema se trata el nivel de detalle adecuado de los datos. Para fines del modelo mientras mas detalles tenemos mejor, ya que nos aporta mas inteligencia en el modelo. ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Es un tema importante para mi ya que me ayuda a diseñar un modelo de datos eficiente y bien estructurado. ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? En la certificación podre hacer frente a los cuestionamientos relacionados al diseño del modelo de datos.

Me gustaría compartirles que lo que eh aprendido en estos capítulos me ha servido demasiado, me quedo mucho mas claro la cardinalidad de las relaciones entre tablas. No sabia sinceramente sobre como agregar los sinónimos para usar la función de Q&A, ahora puedo integrarlo en mis proyectos. Sobre jerarquías, desconocía como hacerlo en Power BI y en estos capítulos me abrió otro mundo. Sin duda que tendré que repasar mucho este capitulo, ya que en la marcha siento que tendré mas y mas dudas.

Este modulo me ayudo a poder tener activo cálculos que dentro de un modelo aparecen como relacion inactivas gracias a la ayuda de la formula USERELATIONSHIP() , además de obtener de distintas maneras tablas de fecha.

Soy nuevo en todos esto del Power BI, por tanto todos estos temas los considero de gran importancia, debido a que lo que enseñan son buenas practicas y sobre todo conocer la terminología correcta. También el uso de Jerarquía no lo conocía de esta manera , solo lo había visto cuando lo hacen en las tablas relacionando unas columnas con otras que seguramente lo veremos luego, al igual que QA.

Hola a todos  Este es la sección en donde mas he aprendido hasta el momento. Desde el flatten out de jerarquías, las common data tables y los role playing dimensions, todos los temas de esta sección los encuentro muy interesante y muy útiles para nuestra preparación en Power BI.

A crear, relaciones, un calendario a partir de formulas dax

Hola, aprendi muchas cosa, “Definir role-playing dimensions” la funcion USERELATIONSHIP() y “Crear una common date table”

¿Qué aprendiste en la sección “Design a Data Model”? - Ver en detalle las propiedades de las columnas y tablas, y cómo usarlas. - Cómo las QUick Measures me ayudan a comprender lenguaje DAX. - Qué es la jerarquía Padre-Hijo y cómo adaptarla a PBI. - El modelo de estrella - Por fin tengo claro los diferentes modos de creación de tabla Calendario! - Los conceptos de Cardinalidad y Granularidad.   ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Tener una buena base de los conceptos de modelado descritos es básico para desarrollar modelos eficaces. ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? Comienzo a ver ejemplos de preguntas de examen de certificación más enfocadas a la práctica.  

Saludos, de la sección Modelado de datos he concluído lo siguiente: -El uso de varias relaciones de una tabla de dimensiones a una tabla fact depende de si deseamos utilizar un inside o un filtro. Hay que tener en cuenta esto para evitar problemas, o sobrecargar el modelo al ir utilizando más tablas copiadas, en este caso, de la fecha. -Usar sinónimos mejora la experiencia al usar Q&A. Buscar las palabras correctas que entren en el léxico de los usuarios es de gran utilidad. -La creación de una tabla común de fechas sea haciendo uso de DAX o PowerQUery tiene el mismo objetivo. -La cardinalidad debe ser escogida adecuadamente para cumplir con el modelo estrella y la relación de 1 a varios.

dlom dijo

Por favor compártenos:

• ¿Qué aprendiste en la sección “Clean, Transform, and Load the data”?
• ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI?
• ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación?

Con tu participación todos podremos aprender más 

En esta sección pude fortalecer mis conocimientos y comprender mucho mejor la diferencia entre Single y both, al momento de relacionar las tablas. Comprender esto me permitirá hacer y analizar modelos de datos, en Porwer Bi con más eficiencia. Este es uno de los puntos que preguntan en el examen, así que es importante tener claro el modelado de datos.

¿Qué he aprendido en la sección "Design a Data Model"? -La diferencia entre los modelos tipo estrellas y los modelos tipo de nieve, especialmente la importancia del primero. -Interpretar y definir la granularidad de los datos. -Aplanar jerarquías independientemente de su numero de niveles (PATH y PATHITEM) -La forma de administrar relaciones entre tablas tanto con Query editor como con DAX. -La creación de tablas auxiliares para resolver las many-to-many relationships. -Las diferencias entre fact tables y dimension tables y como realizar buenas prácticas. -Conocer el tipo de relación  entre tablas: One to One One to Many Many to Many

Los distintos tipos de calendarios que existen y como crearlos en función de los requerimientos. En este modulo el conocer más sobre lenguaje M y como poder utilizar formulas avanzadas para poder generar mejores query. Y tambien como activar relaciones inactivas a traves de la función relationship; son cosas que ayudan a mejorar los gráficos y poder monitorear mejor la información.

El diseño, construcción y funcionamiento de nuestro modelo de datos es una pieza fundamental para cualquier reporte de calidad. En esta sección me llevo un gran aprendizaje en como hacer este proceso con las mejores prácticas disponibles. Adicionalmente a ello, me quedó mucho mas claro como funcionan los cross-filter en dirección BOTH y como a veces no da los resultados esperados, lo mejor es respetar las recomendaciones y armar tu modelo bajo relaciones de: Uno a muchos con dirección *Single* de la *Dim Table* hacia la *Fact table*.

¿Qué aprendiste en la sección “Design a Data Model”? Estos temas dan para mucho más porque el nivel de complejidad puede ser elevado. Aprendí a como relacionar tablas y la función que pueden tener las medidas. ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI? Me permitirá definir modelos más coherentes y robustos.   ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación? Mejor dominio de conceptos y herramientas.

dlom dijo

Por favor compártenos:

• ¿Qué aprendiste en la sección “Clean, Transform, and Load the data”?
• ¿Cómo te servirá esto que aprendiste en tus desarrollos de Power BI?
• ¿Cómo te servirá esto que aprendiste al presentar el examen de certificación?

Con tu participación todos podremos aprender más 

En la sección "Design a Data Model" aprendí a definir las relaciones entre las tablas, cuidar su cardinalidad y a solucionar problemas de relaciones utilizando Role-playing o una función DAX para manejar las relaciones inactivas. También a configurar datos de ls tablas y columnas para agregar sinónimos que ayuden a los usuarios a tener una mejor experiencia on la funcionalidad Q&A. Aprendí a crear una tabla calendario desde M y utilizando DAX. Es importante tratar de que las relaciones siempre sean de uno a muchos y que la dirección de filtro sea simple para evitar resultados no deseados en nuestros informes de Power BI. Todo esto me ayuda a adquirir los conocimientos necesarios para mejorar mis proyectos de Power BI y lograr la certificación de Power BI.  

En esta sección aprendí el uso de la medida DAX USERELATIONSHIP para utilizar una relación entre tablas inactiva.

Hola. De esta sección destaco la funcionalidad de user relationship, desconocía que existía y me parece excelente. También la forma de resolver relaciones del tipo muchos a muchos.  

Hola! Este es el resumen de lo aprendido en la sección! Un saludo! Definir tablas Definir tablas: una tabla es distinta a una query. La table almacena datos, la query es el Código que permite obtener una table Ocultar tablas y columnas no necesarias, para evitar que el usuario vea información que no le resulta relevante Configuración de Propiedades de las tablas y medidas: vista desde el modelo de datos.Sinónimos, descripción y nombres. Row label: es para indicar cuál es el identificador de la table, es útil para las tablas que tienen ID único. Advanced: import, Direct Query, dual. Hide/Unhide Configuración de Propiedades de columnas:Folder: si se quiere agrupar las columnas en un folder Hide/Unhide Type format Sort column by : se puede ordenar una columna en función de otra (i.e.cronológico) Data Category: permite indicar si una columna contiene datos de una categoría, por ejemplo, country/region Summarized by: cómo se muestra columna, sum, etc Quick Measures Running total: permite obtener el acumulado de las ventas para una fecha determinada. Se puede modificar luego Crear nuevas medidas con buenas prácticas según PBI Cambiar la medida de sitio desde la medida Flatten-out a parent-chield hierarchy (ver tema parent-child hierarchy)- Aplanado https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626454 Creamos la columna con todas las jerarquías Ruta Jerarquia = PATH(Jerarquia[Entidad], Jerarquia[EntidadPadre]) Agregamos columnas con cada nivel de jerarquía Nivel 1 = PATHITEM(Jerarquia[Ruta Jerarquia],1) Nivel 2 = PATHITEM(Jerarquia[Ruta Jerarquia],2) .... Performance requirement https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626451 Esquema de estrella: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema Fact tables: table de transacciones. Información transaccional. Dim table: características que describen lo que está registrándose en la Fact. Descripciones, ID únicos. Información descriptiva Esquema de estrella debe estar ordenado: arriba las dimensiones y abajo las Facts No es recommendable el esquema copo de nieve en PBI. Hay que crear una table de dimension con toda la información, por ejemplo, Producto, categoría de producto, subcategoría de producto todo en una tabla. Puede haber más de una tabla de hechos. Esquema de estrella con multiples tablas de hechos. Crear Common date table: https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-date-tables Crear tabla calendario: las fechas no se debe repetir y debe tener todas las fechas en un rango establecido. Si no existe la tabla calendario, desde POwer Query, Ir a "Nwe Source", luego a "Blank Query" y luego poner = List.Dates aquí se agrega una lista y luego en add column seleccionamos la columna y vamos añadiendo cada columna de la tabla calendario. Asegurarse de que la primera columna con las fechas, debe ser de tipo fecha Marcar como tabla calendario del Modelo: Seleccionar la tabla y "Mark as Date Table". Desde visualización Definir la cardinalidad de una relación y la dirección del filtro cruzado https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626452 Cross filter direction: puede ser single: Que la dirección va en un solo sentido,o both, que la dirección va en ambos sentidos. Mucho Cuidado: LAS RELACIONES BIEN CREADAS SON LA BASE DEL BUEN DESARROLLO DE POWERBI. En Manage Relations se pueden ver/crear/borrar relaciones y cambiar cualquier característica que necesitemos. Hay una opción que es "autodetect" pero se debe tener mucho cuidado con su uso, ya que puede ser problemático si las relaciones se detectan de una manera errónea. Role play dimensions https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626455 No puede haber más de una relación activa entre dos tablas. Para poder usar una relación diferente a la activa con la tabla calendario hay 2 opciones Crear medidas con una relación específica diferente a la activa Se puede usar una nueva medida que haga referencia a una relación inactiva a través de USERELATIONSHIP() , de la siguiente forma: En este caso se calculan las ventas por fecha de envío, en lugar de por fecha de venta que es la relación activa. Crear una nueva tabla calendario con la nueva relación Esta opción nos permitirá, no sólo calcular medidas con esa relación, sino incluir fechas y visualizaciones que hagan referencia a la relación. La creación de una nueva tabla se hace a partir de la tabla anterior, copiando exactamente la tabla calendario existente de la sgte forma: Nombre nueva tabla= Nombre Antigua tabla (en New Table). L uego establecemos la relación entre tablas. Con esta nueva tabla luego podemos crear las medidas según la necesidad, usando el filtro de fecha que nos interese y creando las medidas con la fecha de la tabla que queramos. Una buena práctica es cambiar el nombre de las fechas en la nueva tabla para evitar confusiones a la hora de crear medidas y visualizaciones. Resolver las many-to-many relationships https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626448 Relación uno a uno: si no se repite el ID en ninguna de las dos tablas. En este caso se podrían unir las tablas con un merge para que sea más eficiente el modelo. Relación uno a varios/Varios a uno: en una tabla el ID no se repite, pero en la otra así. Esta situación se da cuando conectamos una tabla dimensión con una Fact table. Relación varios a varios: cuidado con la consistencia de los datos en esta situación. Una solución es crear una tabla adicional que contenga información única de alguna de estas tablas para luego relacionarlo con la otra. Definir el nivel apropiado para la granularidad de datos: https://www.datdata.com/products/certificacion-oficial-por-microsoft-de-power-bi/categories/3482750/posts/11626446

• La primera fue las diferentes jerarquías que puede existir en una tabla y cómo dar solución con las funciones de DAX, PATH (Entidad, Entidad Padre).
• La segunda la importaciones que tiene la creación de una tabla calendario para el análisis de nuestros datos, sea en Leguaje M o con Dax.
• La Tercera la importancia de “role plating dimensions” para dar solución a la relación entre tablas que ya tienen una relación, las cuales son:
  1. Many to One
  2. One to One
  3. One to Many
  4. Many to Many
• La solución para resolver “Many-to-Many relationships” que se puede crear un tabla con valores unicos y luego crear una relación para cada tabla respetando la cardinalidad de uno a muchos.