Problema de tipo de datos al aplicar una relación

[Anonymous]

Mis tipos de datos se han establecido en Power Query para los campos Base 93 Price, Count y Each Price en la tabla "codes" y muestran el signo Sigma.

Una vez que aplico la relación a la tabla "Ventas" (Material a artículo como uno (material) a muchos (artículo), esto sucede:

Extrae los datos correctamente, pero los campos de la tabla "códigos" no muestran el "sigma" - incluso pensó que están codificados como números enteros o moneda y no puedo usarlos en una columna calculada u obtener un total del campo Count (count is the "eaches" in a pack of the product - así que ya sea una docena, 2 docenas o 3 docenas).

¿Puede alguien decirme lo que estoy haciendo mal porque me duele la cabeza tratando de resolver esto.

¡Muchas gracias!

[edhans]

Si el sigma no aparece, entonces están llegando como "ANY" de Power Query, que es cuando el campo tiene ABC/123 como el tipo de datos (siempre una mala idea), o se formatan como texto.

Dar formato a los datos en DAX haciendo clic en él es solo formato y no cambiará el tipo de datos. Power Query puede cambiar el tipo, que es lo que debe hacer.

[Ramesh-iTalent]

Tengo el tipo de datos establecido en Power Query:

Lo que está pasando es que una vez que aplico la relación, el Sigma desaparece. Si elimino la relación, vuelve.

[edhans]

Es sólo una cosa visual, y no estoy seguro de por qué. Me puse a tablas con enteros y el sigma estaba allí. Luego me uní como una relación 1:Muchos y el sigma desapareció, pero todavía pude resumir, agregar columnas calculadas y crear medidas en esas columnas.

[PaulDBrown]

---

@edhans escribió:

"sus campos clave en las relaciones no deben utilizarse en los cálculos. Cree una columna duplicada en Power Query y utile para calcs."

---

No era consciente de un problema potencial con el uso de campos clave en los cálculos. ¿Cuáles son los riesgos? (Estoy tratando de pensar en ejemplos de cuándo usaría un campo clave en un calc, pero sólo estoy viniendo con usarlos en expresiones FILTER....). Pero por si acaso...

¡Gracias!

[edhans]

Hola @PaulDBrown ,

Como todo lo demás en Power BI, no hay absolutos, sino algunas cosas acerca de los campos clave frente a los campos de valor:

1. Los campos clave deben ser únicos en el lado 1. Estoy ignorando las complejidades de muchas a muchas relaciones.
2. Los campos clave generalmente deben estar ocultos en muchos lados. He visto muchos problemas en los informes en los que el campo clave se usó en un objeto visual en una tabla FACT frente a la tabla DIM. Hacer esto con fechas evitará que las funciones de inteligencia de tiempo funcionen.
3. Como señaló el OP, el signo sigma está desapareciendo, y aunque eso aparece en la cara de él como un problema visual, no sé lo que SSAS está haciendo debajo cuando ese campo se utiliza como una relación de filtro.
4. Si bien estoy seguro de que alguien se le ocurrirá un escenario, ¿qué posible uso matemático tendría un valor único en una tabla además de contar? Si solo está contando, puede contar las filas. Pero no debería colocar ese campo en un objeto visual para crear una medida implícita, no desde la tabla FACT o DIM. Puede colocarlo en una tabla como una columna o matriz como columna/fila como lo haría con un número de pieza, pero no en valores.
5. A menos que sea un identificador único generado por SQL u otra base de datos, casi siempre conviero identificadores numéricos en texto antes de usarlos con relaciones de filtro. Se asegura de que no se rompen si se introducen caracteres alfa. Números de pieza, números de empleados, etc.

Solo recomendaría crear una columna duplicada en Power Query y, a continuación, usarla. Su campo clave "muchos" debería estar oculto de todos modos, por lo que no causaría confusión.

[PaulDBrown]

@edhans

Gracias por esa explicación tan completa. Todo tiene sentido, por supuesto.
Me gusta especialmente su "mejor práctica" de convertir ID numéricos en texto.

Una vez más, gracias por tomarse el tiempo para ofrecer la explicación. ¡Muy apreciado!

Mejor

Paul.

[Anonymous]

Volveré a profundizar en él, pero no me dejando hacer una columna calculada usando el campo "contar". Gracias por los comentarios!

[edhans]

De acuerdo. Háganos saber cómo va. Marque mi respuesta como resuelta si esta es la solución para que otros puedan encontrar esto, o publicar de nuevo con otra información.

[Anonymous · Accepted solution]

I changed the name from Count to ItemCt and it let me do the calculation even though the Sigma wasn't there.  So you were right with respect to that just being a visual thing - WHICH THEY SHOULD FIX - but on top of that I needed to change the name of the field.  I really should have not named it that - no need for that kind of confusion!