-
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
-
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.
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 ManyLos 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.
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 medidaFlatten-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/11626454Creamos 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ónDefinir 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/11626452Cross 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/11626448Relació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
- Debes estar registrado para responder a este debate.