Семантические связи

Как правило, выборка выполняется явно, щелчком по необходимым значениям полей. Тем не менее, существует способ непрямой выборки через семантические связи. Они подобны значениям полей, за тем исключением, что описывают взаимоотношения между объектами, а не сами объекты. Они отображаются в виде списка кнопок.

При щелчке по семантической связи выполняется выборка в другом поле.

Правила семантических таблиц

Примечание: Семантические таблицы не отображаются в представлении таблицы.

Семантические связи создаются загрузкой таблиц, содержащих взаимосвязи между объектами.

  • Таблица должна содержать точно три или четыре столбца.
  • Семантическая таблица должна содержать взаимосвязи между значениями различных полей или одного поля. Сочетание и тех и других не допускается.
  • Оператор LOAD или SELECT, управляющий загрузкой семантической таблицы, должен следовать за классификатором semantic, означающим, что это не логическая таблица.

Как правило, используется четыре столбца: первый содержит значения полей, которые имеют взаимосвязи с некоторыми другими значениями полей, а третий — связанные значения полей. Второй столбец должен содержать имена связей, а четвертый — имена обратных связей.

Если используется три столбца, явные имена для обратных связей не задаются. Имена, заданные во втором столбце, используются и для связей, и для обратных связей. До или после таких имен указаны стрелки.

В случае взаимосвязей между значениями одного поля первый и третий столбец должны иметь одно имя. Это касается также имен во втором и четвертом столбцах, то есть типы связей должны быть одинаковыми. Однако в случае связей между значениями разных полей все столбцы должны иметь разные имена.

 Извлечение семантической таблицы из данных

Семантическая таблица не всегда должна существовать в виде внешней таблицы QlikView. Проще извлечь ее из существующей таблицы объектов с помощью отдельного оператора LOAD.

В примере с президентами presidents в каталоге образцов QlikView скрипт создания связей для предшественников Predecessor и преемников Successor может выглядеть следующим образом:

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;

Второй оператор LOAD создает таблицу, подобную указанной справа, которая загружается как семантическая таблица. Выражение where используется для пропуска первой записи, так как она может связать первое значение president со значением nonexistent 0:th president.

Обратите внимание на то, что этот оператор LOAD содержит два поля с метками No и два поля с метками Relation. Такой оператор LOAD может привести к возникновению ошибки при выполнении скрипта, если используется для загрузки внутренней таблицы, так как при загрузке единой внутренней таблицы все поля должны иметь разные имена. Невозможно использовать и соответствующий оператор SELECT, т. к. большинство драйверов ODBC также предъявляют подобные требования. Если таблица с президентами находится в базе данных, вместо этих операторов следует использовать следующую структуру:

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;

Пример с президентами — только один простой пример использования семантических связей. Эту структуру можно также использовать для установки генеалогических связей, в которых семантические связи могут быть следующими: двоюродный брат (сестра), брат (сестра), бабушка и т. п., или связей между сотрудниками компаний, для которых семантические связи могут быть следующими: superior, reports to, secretary и т. п.

 Использование связанных значений в качестве имен связей

Иногда в качестве имен связей следует использовать связанные значения полей. Если рассматривать пример с президентами (presidents), то всех предшественников (predecessors) можно указать в одном столбце, а всех преемников (successors) в другом:

Для создания этих связей требуется следующий скрипт:

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;

При щелчке по семантической связи выполняется выборка в поле третьего столбца DuplicateOfNo, который в семантической таблице всегда отображает номер президента, показанный в семантической связи.

Возможно, с первого взгляда это и не очевидно, но обратные связи в вышеуказанной структуре практически бесполезны. Они должны показывать имя президента и при щелчке осуществлять выбор предшественника/преемника отображаемого президента. Поэтому такие связи называются Dummy1 и Dummy2, при этом используется только первая связь (столбец номер два).

Поскольку пустые связи в списках не нужны, второй и четвертый столбец должны обрабатываться как связи разных типов. Это значит, что первый и третий столбец должны иметь разные имена полей. По этой причине существует два столбца, содержащих номер президента, No и DuplicateOfNo.

Требуется два разных оператора semantic, чтобы создать два разных списка со связями.

В этом примере также можно использовать семантические таблицы, состоящие из трех столбцов, однако при этом списки с обратными связями только запутают пользователя.