Normalmente, las selecciones se hacen explícitamente haciendo clic en los valores de un campo que son interesantes. Pero, también existe la posibilidad de hacer las selecciones de forma indirecta a través de vínculos semánticos. Estos son similares a los valores de un campo, con la diferencia que son más bien descripciones de las relaciones entre los objetos que objetos mismos. Su apariencia es en una lista de botones.
Cuando se hace clic en un vínculo semántico, se efectúa una selección en otro campo.
Reglas para las tablas semánticas
Los vínculos semánticos se crean con la importación de tablas que contienen las relaciones entre los objetos.
- La tabla debe contener exactamente tres o cuatro columnas.
- Una tabla semántica debe contener relaciones entre valores de campos diferentes o entre valores del mismo campo. No se acepta una mezcla de ambas.
- La sentencia LOAD o SELECT que carga una tabla semántica, debe ir precedida por un cualificador semantic para declarar que no se trata de una tabla lógica.
En general, se usan cuatro columnas, la primera contiene los valores de los campos que están relacionados con algún otro valor, este valor del campo relacionado esta comprendido en la tercera columna. La segunda columna debe contener los nombres de las relaciones, y finalmente la cuarta debe contener los nombres de las relaciones inversas.
Si se emplean tres columnas, no se pueden dar nombres explícitos para las relaciones inversas. Entonces, los nombres dados en la segunda columna se utilizan para ambas, la relación y la relación inversa. Los nombres llevan en este caso flechas delante o detrás.
Las primera y tercera columnas deben llevar el mismo nombre, si se trata de relaciones entre valores del mismo campo. Al igual que los nombres de la segunda y cuarta columna, es decir, el tipo de relaciones, deben ser el mismo. No obstante, si las relaciones se dan entre valores de campos diferentes, todas las columnas deben llevar nombres diferentes.
Extraer una tabla semántica de los datos
La tabla semántica no siempre tiene que existir como tabla externa fuera de QlikView. Es mejor (resulta más flexible) extraer esta tabla de una tabla de objetos existente a través de una sentencia LOAD aparte.
En el ejemplo presidents incluido en el directorio de ejemplos de QlikView, el script para generar los vínculos Predecessor y Successor podría ser:
Directory presidents;
LOAD * from presdnts.csv (ansi, txt, delimiter
is ',', embedded labels);
Semantic LOAD
No -1 as No,
'Successor' as Relation,
No,
'Predecessor' as Relation
from presdnts.csv (ansi, txt, delimiter is ',',
embedded labels) where No > 1;
El resultado de la segunda sentencia LOAD es una tabla como la de la derecha, y esta tabla ha sido cargada como tabla semántica. Se utiliza la cláusula where para omitir el primer registro, ya que si no se omitiera vincularía el primer presidente al inexistente presidente nº 0.
Observamos también que esta sentencia LOAD contiene dos campos titulados No y dos campos titulados Relation. Una sentencia LOAD de este tipo causaría un error en la ejecución de script si se usara para cargar una tabla interna, ya que el procedimiento de carga para una única tabla interna exige que ninguno de los campos tenga el mismo nombre. La sentencia SELECT correspondiente tampoco es posible, porque la mayoría de drivers ODBC exigen lo mismo. En lugar de eso, se debería usar la estructura siguiente, si la tabla de presidentes figura en una base de datos:
Connect to DataBase;
SELECT * from presdnts;
Alias No2 as No, Relation2 as Relation;
Semantic SELECT
No -1 as No,
'Successor' as Relation,
No as No2,
'Predecessor' as Relation2
from presdnts where No > 1;
El ejemplo de los presidentes es tan solo un ejemplo muy simple para el uso de vínculos semánticos. Éstos también pueden emplearse en la genealogía, donde los vínculos semánticos pueden ser p.ej. primo, hermano, abuela,etc. o para los empleados de una empresa donde los vínculos semánticos pueden ser p.ej. superior, reports to, secretary, etc.
Uso de los valores relacionados como nombres de las relaciones
A veces puede resultar más descriptivo utilizar los valores de campo relacionados como nombre de la relación. En el ejemplo de los presidentes, puede ser ventajoso tener todos los predecesores en una columna y todos los sucesores en otra:
Para crear estos enlaces se necesita el script siguiente:
LOAD
No as DuplicateOfNo,
FirstName & ' ' & LastName as Name,
*
from presdnts.csv;
Semantic LOAD
No -1 as No,
FirstName & ' ' & LastName as Successor,
No as DuplicateOfNo,
'Dummy1'
from presdnts.csv where No > 1;
Semantic LOAD
No +1 as No,
FirstName &' ' & LastName as Predecessor,
No as DuplicateOfNo,
'Dummy2'
from presdnts.csv;
Cuando se hace clic en un vínculo semántico, se efectúa una selección en el campo de la tercera columna, DuplicateOfNo, que corresponde en la tabla semántica siempre con el número del presidente mostrado en el vínculo semántico.
Aunque a lo mejor no resulta obvio al principio, las relaciones inversas en la construcción anterior son prácticamente inútiles. Mostrarían el nombre de un presidente y, al hacer clic, seleccionarían el predecesor/sucesor del presidente mostrado. Por eso se llaman Dummy1 y Dummy2 y se usa sólo la primera relación (columna dos).
Como no deseamos que las relaciones dummy aparezcan en los cuadros de lista, debemos tratar las segundas y cuartas columnas como relaciones de diferentes tipos. Esto significa que las primeras y terceras columnas deberán tener nombres de campos diferentes. Por esta razón tenemos dos columnas con el número del presidente, No y DuplicateOfNo.
Como deseamos obtener dos cuadros de lista diferentes con relaciones, necesitamos dos sentencias semantic diferentes.
También es posible realizar este ejemplo con tablas semánticas de tres columnas, pero entonces es muy probable que los cuadros de lista con las relaciones inversas confundan al usuario.
