Una base de datos puede contener muchas tablas. Cada tabla puede considerarse como una lista de algo; cada registro de la lista representa una instancia de un objeto de algún tipo.
Ejemplo:
Si dos tablas son listados de cosas distintas, por ejemplo, si una es una lista de clientes y otra una lista de facturas y ambas tablas tienen un campo en común, como puede ser el número de cliente, en general podemos decir que existe una relación entre ambas tablas. En las herramientas SQL estándar de consulta, las dos tablas siempre deberían ir unidas.
Las tablas definidas en el script de QlikView se denominan tablas lógicas. QlikView efectúa asociaciones entre las tablas, basándose en los nombres de los campos y lleva a cabo las uniones al efectuarse una selección, por ej. cuando el usuario selecciona un valor de campo en un cuadro de lista.
Esto significa que una asociación es casi lo mismo que una unión join. La única diferencia está en que la unión join se efectúa al ejecutarse el script y la tabla lógica es normalmente el resultado del join. La asociación se realiza tras crearse la tabla lógica, las asociaciones siempre se realizan entre tablas lógicas.
La asociación QlikView comparada con un natural outer join de SQL
Una asociación de QlikView se parece a un outer join de SQL. Aunque la asociación es más general: un outer join de SQL es normalmente una proyección en un solo sentido de una tabla sobre otra. Una asociación siempre da como resultado un natural outer join completo (bidireccional).
Información de frecuencia al asociar campos
Existen algunas limitaciones en cuanto al uso de la mayoría de campos de asociación, es decir, en campos que son comunes a dos o más tablas. Cuando un campo aparece en más de una tabla, QlikView se enfrenta al problema de tener que saber cuál de las tablas debe utilizar para calcular las frecuencias de datos.
QlikView analiza los datos para ver si existe alguna forma no ambigua de identificar una tabla principal en la que contar (a veces existe), pero en la mayoría de los casos el programa solo puede hacer una suposición. Dado que una suposición errónea podría ser fatal (QlikView daría la impresión de cometer errores en los cálculos), el programa ha sido diseñado de tal manera que no permite determinadas operaciones cuando la interpretación de los datos es ambigua para campos asociados.
Limitaciones en la asociación de campos
- En un cuadro de lista que muestre el campo, no se podrá visualizar la información de frecuencia.
- Los cuadros de estadísticas del campo muestran n/a para la mayoría de entidades estadísticas.
- En los gráficos, no es posible crear expresiones que contengan funciones que dependan de la información de frecuencia (como las funciones Sum, Count y Average) en el campo, a menos que se active el modificador Distinct. Después de cada recarga, QlikView analizarán todas las expresiones de los gráficos para ver si ha aparecido alguna ambigüedad como resultado de los cambios en las estructuras de los datos. Si el programa encuentra cualquier expresión ambigua, mostrará un diálogo de advertencia y desactivará esa expresión. La expresión no podrá activarse hasta que no se haya corregido el problema. Si se activa un archivo de registro, todas las expresiones ambiguas se enumeran en el registro.
Solución
Hay una manera muy simple de superar estas limitaciones. Cargue el campo una vez más, con un nuevo nombre, en la tabla donde deba contabilizarse la frecuencia. Utilice a continuación el nuevo campo para un cuadro de lista con la configuración de frecuencia, para un cuadro de estadísticas o para cálculos en sus gráficos.
