Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hola a todos:
Estoy creando un modelo de datos a partir de una serie de tablas que me proporciona el cliente; si hago una carga de datos "a pelo", el modelo que a Qlik Sense buenamente se le ocurre es el siguiente:
Completado con errores y/o advertencias
0 error(es) forzado(s)
8 clave(s) sintética(s)
$Syn 1 = ID_MES+FCH_ACTO_COMERCIAL
$Syn 2 = ID_SFID+ID_MES
$Syn 3 = ID_SFID+ID_MES+LINEA_NEGOCIO_NMR
$Syn 4 = ID_SFID+ID_MES+FCH_ACTO_COMERCIAL
$Syn 5 = $Syn 2+$Syn 3
$Syn 6 = $Syn 1+$Syn 2+$Syn 4
$Syn 7 = $Syn 1+$Syn 2+$Syn 3+$Syn 4
$Syn 8 = $Syn 5+$Syn 6+$Syn 7
Bien, la pregunta es ¿cómo de malo sería dejar así el modelo? Según la ayuda oficial:
La presencia de varias claves sintéticas suelen ser un síntoma de un modelo de datos incorrecto, pero no siempre. Sin embargo, un signo inequívoco de que el modelo de datos es incorrecto es la presencia de claves sintéticas basadas en otras claves sintéticas.
Por lo que estoy leyendo, aquí y aquí, que Qlik cree claves sintéticas no es malo per se en términos de rendimiento e incluso asegura que el tratamiento de los valores nulos sea correcto; sin embargo, en este caso llega a crear claves sintéticas a partir de claves sintéticas, que según la ayuda es signo inequívoco de que el modelo de datos es incorrecto.
Por otro lado, hay algunos problemas de redundancia en las tablas, en especial con las fechas, puesto que ID_MES está incluido en FCH_ACTO_COMERCIAL (una tabla incluso incluye un campo ID_ANIO, aunque por suerte no aparece en ninguna otra y no afecta a las conexiones), tal que así:
| ID_MES | FCH_ACTO_COMERCIAL |
| 201912 | 20191201 |
¿Sería estrictamente necesario omitir la carga de ID_MES en aquellas tablas que también incluyen FCH_ACTO_COMERCIAL (algunas tablas sólo incluyen ID_MES como referencia temporal, eso sí)? ¿Mejoraría el rendimiento o la solidez del modelo de datos? Porque se me ocurre que complicaría las presentaciones por mes de esos datos, ¿no? ¿Habría que procesar FCH_ACTO_COMERCIAL a posterior para extraer el mes?
Bien, como solución al problema de las claves sintéticas se me ha ocurrido crear las dos siguientes:
Hash256(ID_SFID, FCH_ACTO_COMERCIAL) as $key1
Hash256(ID_MES, ID_SFID, LINEA_NEGOCIO_NMR) as $key2
La primera podría incluir ID_MES o no.
De manera que el modelo queda:
Completado con éxito
0 error(es) forzado(s)
0 clave(s) sintética(s)
¿Hay algún problema en incluir FCH_ACTO_COMERCIAL en una de mis claves y a la vez usarla como clave en sí para conectar con TABLA_FCH_DIA? ¿El incluir un campo en una de las claves -haciéndolo desaparecer como tal al tener que comentarlo- impide a posteriori utilizarlo en las presentaciones? ¿Se os ocurre una alternativa mejor?
Un saludo y gracias por vuestras aportaciones.
Hola, Rubén:
Muchas gracias por tu respuesta. Al final lo he dejado en un modelo de estrella como sugerías, porque el del primer mensaje daba problemas con algunas métricas (no era capaz de relacionar bien elementos de la TABLA_TRAFICO con otros de la TABLA_SFID, que son categorías fundamentales para hacer agrupaciones):
Un saludo a todos.
Por cierto, creo que este modelo me está dando precisamente uno de los problemas que se mencionan en el segundo de los artículos que enlacé al abrir el hilo:
And they [nota mía: se refiere a las claves sintéticas] treat NULLs correctly, as opposed to an explicit concatenated key.
Por ejemplo, al intentar definir la siguiente tabla aparecen 85 valores "perdidos":
Si hacemos lo mismo con un modelo muy sencillo que sólo incluya TABLA_NPS, que es donde se encuentra esa información:
Esto supongo que es debido a algún problema con %key2 (ID_SFID, FCH_ACTO_COMERCIAL), que de alguna manera no se asocia a esos 85 valores; entonces, ¿la única alternativa es prescindir de mis claves y dejar que Qlik enlace las tablas automáticamente?
Un saludo y gracias por adelantado.
Hola, Rubén, gracias por tu respuesta.
TABLA_NPS por sí sola parece funcionar, con lo cual el problema supongo que se da al conectarla a través de %key2 -que, a diferencia de lo que dice el 1er mensaje, finalmente es Hash256(ID_SFID, FCH_ACTO_COMERCIAL)- con el resto del modelo; no sé si el que la clave no incluya ID_MES es el problema, porque al intentar hacer la tabla con FCH_ACTO_COMERCIAL también aparecen esos 85 valores "perdidos":
Bien, he modificado los campos que permiten crear mis claves %key1 y %key2 en TABLA_NPS:
ID_SFID as ID_SFID_NPS,
ID_MES as ID_MES_NPS,
FCH_ACTO_COMERCIAL as FCH_ACTO_COMERCIAL_NPS,
Y he creado un par de tablas para hacer comprobaciones:
La segunda más detallada:
Este caso es el más destacable de los "perdidos", con 16 valores.
Pero hay más, como se puede ver aquí.
Hola, Rubén, muchas gracias por tu pronta respuesta.
@rubenmarin wrote:En la tabla central Key2 debería tener informado ID_SFID en la misma línea, cada ID_SFID_NPS debe tener su ID_SFID para que se propaguen las relaciones. Lo mismo con FCH_ACTO_COMERCIAL.
No entiendo muy bien este punto, ¿te refieres a eliminar ID_SFID y FCH_ACTO_COMERCIAL como claves independientes?
@rubenmarin wrote:Por otra parte FCH_ACTO_COMERCIAL y FCH_ACTO_COMERCIAL_NPS tienen formatos distintos, si FCH_ACTO_COMERCIAL_NPS lo está cargando como número (no es una fecha con formato YYYYMMDD) no va a relacionar una fecha con otra.
Si, FCH_ACTO_COMERCIAL lo transformé en el script para que tuviera un formato más legible y para que Qlik supiera que, efectivamente, es una fecha.
En cualquier caso, en el resto de valores sí es capaz de relacionar ambas fechas aunque tengan distinto formato:
Un cordial saludo.
