Łącza semantyczne
Selekcji dokonuje się zazwyczaj w sposób jawny, klikając odpowiednie wartości pól. Istnieje też jednak sposób pośredniego dokonywania selekcji z wykorzystaniem łączy semantycznych. Są one podobne do wartości pól, ale nie opisują samych obiektów, a jedynie relacje między obiektami. Są one wyświetlane jako lista przycisków.
Kliknięcie łącza semantycznego powoduje dokonanie selekcji w innym polu.
Reguły dotyczące tabel semantycznych
Aby utworzyć łącza semantyczne, należy załadować tabele zawierające relacje między obiektami.
- Tabela musi zawierać dokładnie trzy lub cztery kolumny.
- Tabela semantyczna może zawierać albo relacje między wartościami różnych pól, albo relacje między wartościami tego samego pola. Nie można w jednej tabeli umieścić obu typów relacji.
- Instrukcja LOAD lub SELECT ładująca tabelę semantyczną musi być poprzedzona kwalifikatorem semantic informującym, że nie jest to tabela logiczna.
Zazwyczaj stosuje się cztery kolumny. Pierwsza zawiera wartości pól będące w relacji z pewnymi innymi wartościami pól, które są podane w trzeciej kolumnie. Druga kolumna zawiera nazwy relacji, a w czwartej znajdują się nazwy relacji odwrotnych.
W przypadku użycia trzech kolumn nie można określać jawnych nazw relacji odwrotnych. Nazwy podane w drugiej kolumnie będą używane zarówno dla relacji, jak i dla relacji odwrotnej. W takim przypadku przed nazwą lub po niej umieszczana jest strzałka.
Jeśli relacje występują między wartościami tego samego pola, kolumny pierwsza i trzecia muszą mieć taką samą nazwę. Identyczne muszą też być nazwy drugiej i czwartej kolumny (typ relacji). Jeśli jednak relacje występują między wartościami różnych pól, wszystkie kolumny muszą mieć różne nazwy.
Wyodrębnianie tabeli semantycznej z danych
Tabela semantyczna nie zawsze musi istnieć poza QlikView jako faktyczna tabela. Bardziej elastycznym podejściem jest wyodrębnienie takiej tabeli z istniejącej tabeli obiektów w ramach osobnej instrukcji LOAD.
W przykładzie presidents z katalogu przykładów QlikView skrypt generujący łącza Predecessor i Successor może wyglądać następująco:
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;
Druga instrukcja LOAD powoduje utworzenie tabeli pokazanej poniżej, która zostaje załadowana jako tabela semantyczna. Klauzula where powoduje pominięcie pierwszego rekordu, ponieważ jego uwzględnienie spowodowałoby powiązanie pierwszego prezydenta z nieistniejącym prezydentem zerowym.
Warto zwrócić uwagę, że ta instrukcja LOAD zawiera dwa pola o nazwie No i dwa pola o nazwie Relation. Użycie takiej instrukcji LOAD do załadowania tabeli wewnętrznej spowodowałoby błąd wykonania skryptu, ponieważ procedura ładowania pojedynczej tabeli wewnętrznej wymaga, aby każde pole miało inną nazwę. Również analogiczna instrukcja SELECT byłaby niemożliwa, ponieważ większość sterowników ODBC ma takie same wymagania. Jeśli tabela presidents znajduje się w bazie danych, należy użyć następującej konstrukcji:
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;
Przykład presidents to bardzo prosty przypadek użycia łączy semantycznych. Można ich również używać w genealogii, gdzie łącza semantyczne mogą określać stopień pokrewieństwa (kuzyn, rodzeństwo, babcia itp.), lub do opisywania zależności służbowych w firmach, na przykład za pomocą łączy semantycznych superior, reports to, secretary itp.
Używanie powiązanych wartości jako nazw relacji
Niekiedy bardziej czytelne jest używanie powiązanych wartości pól jako nazw relacji. W przykładzie presidents może być wskazane umieszczenie wszystkich poprzedników w jednej kolumnie, a wszystkich następców w innej:
Do utworzenia takich łączy potrzebny jest następujący skrypt:
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;
Kliknięcie łącza semantycznego powoduje dokonanie selekcji w trzeciej kolumnie DuplicateOfNo, która w tabeli semantycznej zawsze zawiera numer prezydenta wyświetlany na łączu semantycznym.
Nie jest to oczywiste na pierwszy rzut oka, ale relacje odwrotne w powyższej konstrukcji są praktycznie bezużyteczne. Wyświetlałyby one nazwisko prezydenta, a po kliknięciu dokonywały selekcji poprzednika lub następcy wyświetlanego prezydenta. Dlatego otrzymały one nazwy Dummy1 i Dummy2, a używana jest tylko pierwsza relacja (kolumna druga).
Relacje robocze nie mają być wyświetlane na listach wartości, kolumny drugą i czwartą trzeba zatem traktować jako relacje różnych typów. Oznacza to, że kolumny pierwsza i trzecia muszą mieć różne nazwy. Z tego względu istnieją dwie kolumny zawierające numer prezydenta: No i DuplicateOfNo.
Należy uzyskać dwie różne listy wartości z relacjami, potrzebne są zatem dwie różne instrukcje semantic.
Ten sam przykład można by wykonać z tabelami semantycznymi o trzech kolumnach, ale wtedy byłyby widoczne mylące dla użytkownika listy wartości z relacjami odwrotnymi.