Как избежать создания острова свиданий в QlikView?

Сетевой анализ действительно имеет большое влияние на производительность. Лучше использовать обычные функции «выбора» в QlikView.

Для ответа ниже я предполагаю, что вы знакомы с концепцией разработки звездообразной схемы. Короче говоря, это означает отделение Измерений (полей выбора) от полей фактов (поля счетчиков, полей суммирования и т. Д.) И их соединение через таблицу ссылок.

Возможны два сценария:

1. С одним и тем же фактом связано несколько свиданий.

Например, у вас есть таблица «транзакций продаж», в которой фактически указана сумма денег, участвующих в продаже, и есть не только «дата продажи», но и «дата платежа», и вы хотите выбрать обе. В этом случае вы хотите иметь несколько независимых вариантов выбора даты, поскольку вы не можете быть уверены, хочет ли пользователь выбрать дату преобразования, дату создания ... и т. Д. Вам необходимо продублировать свой «остров дат» с разными именами ключей и подключить его к таблица транзакций дважды. Оба пула дат больше не будут островами и будут более правильно называться «измерениями календаря».

2. Разные даты связаны с разными фактами.

В этом случае вы можете использовать одно «измерение календаря» для размещения всех полей даты. Просто создайте один ключ AutoNumber в своем календаре и назовите его %DateKey. Сделайте это поле связью между таблицей календаря и таблицей ссылок. Теперь для всех таблиц фактов, у которых есть дата, которую вы хотите выбрать с помощью календаря, убедитесь, что вы подключили ее к таблице ссылок с помощью ключа, который включает дату в хэш Autonumber.

Если бы он испытал то же самое, что я бы рекомендовал создать то, что я называю ключевой таблицей, как в примере ниже ; сохраняет отношения, и вам не нужно так часто использовать анализ множеств; просто убедитесь, что вы поместили таблицу со всеми возможными датами в качестве одной из дочерних таблиц и% DateKey, как предложил Littlegreen