Обработка нескольких таблиц фактов в Qlikview

У меня есть база данных PostgreSQL, содержащая различные данные об образовании, такие как школьные оценки тестов и цифры регистрации. Мне нужно отделить зачисление от результатов теста, потому что данные находятся на разных зернах. Несмотря на то, что регистрация отличается от данных теста детализацией, многие измерения одинаковы. Например, у меня есть:

~ ---------------------------------------------------------------------------------~
| Test Scores Fact                                                                 |
|-------------|-----------|----------|-----------|--------------|------------|-----|
| school_code | test_code | grade_id | gender_id | ethnicity_id | subject_id | ... |
|-------------|-----------|----------|-----------|--------------|------------|-----|

~ --------------------------------------------------------~
| Enrollment Fact                                         |
|-------------|----------|-----------|--------------|-----|
| school_code | grade_id | gender_id | ethnicity_id | ... |
|-------------|----------|-----------|--------------|-----|

эта структура отлично подходит для бэкэнда, но в Qlikview это создает синтетический ключ. Раствор для синтетики ключи, как правило, заменяют его таблицей ссылок с помощью сценариев Qlikview, что также было моим подходом. Но это, похоже, не масштабируется, так как, когда я добавляю третью таблицу фактов (на еще одно зерно), которая содержит больше тех же измерений, если я создаю другую таблицу ссылок, Теперь мои две таблицы ссылок начинают ассоциироваться, поскольку они содержат несколько обычно именованных полей, и ответ Qlikview-создать больше синтетических ключей?

Я относительно новичок в Qlikview и работаю себя. Как обычно обрабатываются множественные факты разных зерен с общими размерами?

изменить:

Я предоставил свое решение этой проблемы, который работает в производственной среде чуть менее года! См. мой ответ ниже...

4 ответов


видя популярность этого вопроса, я собираюсь добавить свое фактическое решение в микс, чтобы у людей был пример для работы, который по какой-то причине очень трудно найти для такой общей проблемы...

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

в проблема: у вас есть несколько таблиц фактов в базе данных; появление почти в каждой базе данных когда-либо. Некоторые (или все) из этих таблиц фактов имеют одни и те же ключевые поля; нет проблем, верно? Неправильный. К сожалению, из-за ассоциативной природы Qlik, вместо того, чтобы каждая из ваших таблиц фактов связывалась с их таблицами поиска, ваши таблицы фактов теперь связываются друг с другом и наносят ущерб вашей модели данных; создавая циклические ссылки и неисчислимое количество синтетических ключей.

Решение: создайте таблицу ссылок. Звучит просто, правда? Ну, это так, но это также очень плохо документировано и трудно понять без первоначального объяснения. Вам может быть интересно... что такое таблица? Это декартово произведение всех ключей из всех ваших таблиц фактов. Как это исправляет проблему? Он удаляет все нежелательные ассоциации между таблицами фактов, так как теперь каждая из них будет содержать только один уникальный объединенный ключ. Те уникальные ключи будут связаны только с таблицей ссылок, которая содержит все ваши уникальные объединенные ключи, а также все отдельные ключи. Таблица ссылок впоследствии будет ассоциироваться с вашими таблицами поиска, и все будет хорошо.

реализация:

эта реализация будет использовать две таблицы, содержащиеся в моем вопросе выше;test_scores_fact и enrollment_fact.

test_scores_fact     |    enrollment_fact      |    school            |    gender         |   ...
----------------     |    ---------------      |    ------            |    ------         |   ---
school_code (FK)     |    school_code (FK)     |    school_code (PK)  |    gender_id (PK) |
test_code (FK)       |    grade_id (FK)        |    school_name (FK)  |    gender_desc    |
grade_id (FK)        |    ethnicity_id (FK)    |    address           |    ...            |
gender_id (FK)       |    gender_id (FK)       |    ...               |
ethnicity_id (FK)    |    number_enrolled (F)  | 
subject_id (FK)      |
test_score (F)       |

FK = Foreign Key
PK = Primary Key
F = Fact

как вы можете видеть, две таблицы имеют перекрывающиеся ключи, school_code, grade_id, gender_id и ethnicity_id. В реляционной модели каждое ключевое поле имеет соответствующую таблицу с дополнительной информацией о ключе. Эта модель не совпадает с ассоциативной природой Qlikview, поскольку Qlikview связывает таблицы на основе имени Поля; даже если вы этого не хотите. Вы хотите, чтобы именованные поля связывались с их таблицами подстановки, однако вы не хотите, чтобы именованные поля в таблицах фактов связывались. К сожалению, вы не можете остановить это поведение. Необходимо реализовать ссылку Таблица...

  1. в скрипте Qlikview создайте временную таблицу фактов, которая загружается во все поля из таблицы базы данных:

    [temp_test_scores]:
    LOAD school_code,
         test_code,
         grade_id,
         gender_id,
         ethnicity_id,
         subject_id,
         test_score;
    SQL SELECT * FROM <database connection>
    
  2. объедините ключи и удалите все отдельные ключи:

    [test_scores]:
    LOAD school_code & '_' test_code & '_' grade_id & '_' gender_id & '_' ethnicity_id & '_' subject_id as test_key,
         test_score
    RESIDENT [temp_test_scores];
    
  3. повторите шаги 1 и 2 для каждой таблицы фактов:

    [temp_enrollment]:
    LOAD school_code,
         grade_id,
         ethnicity_id,
         gender_id,
         number_enrolled;
    SQL SELECT * FROM <database connection>
    
    [enrollment]:
    LOAD school_code & '_' & grade_id & '_' & ethnicity_id & '_' & gender_id as enrollment_key,
         number_enrolled
    RESIDENT [temp_enrollment];
    
  4. создайте таблицу ссылок, объединив отдельные ключи в один таблица:

    [temp_link_table]:
    LOAD DISTINCT
        school_code,
        test_code,
        grade_id,
        gender_id,
        ethnicity_id,
        subject_id
    RESIDENT [temp_test_scores];
    
    CONCATENATE ([temp_link_table])
    LOAD DISTINCT
        school_code,
        grade_id,
        ethnicity_id,
        gender_id,
        number_enrolled
    RESIDENT [temp_enrollment];
    
    /**
     * The final Link Table will contain all of the individual keys one time as well as your concatenated keys
     */
    [link_table]:
    LOAD DISTINCT
        school_code,
        test_code,
        grade_id,
        gender_id,
        ethnicity_id,
        subject_id,
        school_code & '_' test_code & '_' grade_id & '_' gender_id & '_' ethnicity_id & '_' subject_id as test_key,
        school_code & '_' & grade_id & '_' & ethnicity_id & '_' & gender_id as enrollment_key
    RESIDENT  [temp_link_table]
    
  5. отбросьте временные таблицы, чтобы они не отображались в вашей модели данных:

    DROP TABLE [temp_test_scores];
    DROP TABLE [temp_enrollment];
    DROP TABLE [temp_link_table];
    

это удалит все ассоциации между вашими таблицами фактов, поскольку теперь между ними нет общих имен полей. Каждая таблица фактов будет ссылаться на таблицу ссылок с помощью созданного объединенного ключа. Затем таблица ссылок будет связываться с каждой отдельной таблицей подстановки. Модель данных Qlikview не будет содержать синтетических ключей или циклическая ссылка.

если вы создадите другую таблицу фактов в будущем, просто выполните шаги 1 и 2 еще раз и добавьте любые новые отдельные ключи в таблицу ссылок, а также добавьте новый объединенный ключ в таблицу ссылок. Он масштабируется без особых усилий.

Удачи!


существует две основные стратегии моделирования данных в QlikView для обработки нескольких таблиц фактов:

  1. добавьте таблицы фактов в одну таблицу фактов-обычно упоминается как объединенный факт как синтаксис QlikView для добавление данных в таблицы осуществляется с помощью префикса CONCATENATE (префикс эквивалент операции объединения SQL)

  2. создайте таблицу ссылок (что вы сделали до сих пор) для большинства реализации, опция 1 соответствующий метод. Атрибуты Обобщенный факт можно резюмировать следующим образом:

плюсы:

  1. хорошо работает из-за уменьшения количества больших таблиц в модели данных
  2. простой в реализации, просто добавьте все данные в одну общую таблицу фактов, обеспечивая при этом общие измерения ссылаются на общие имена полей

негативы:

  1. различные факты непосредственно не связаны друг с другой. Намек на это важно понять. Это означает, что перекрестный анализ фактов, как правило, достижим только с помощью общих измерений. Любые конкретные измерения фактов никоим образом не связаны с записями фактов, которые не ссылаются на эти измерения. Сложный синтаксис "set analysis" может в некоторой степени смягчить этот недостаток, но если ваше основное требование состоит в том, чтобы сделать косвенный анализ фактов a по фактам B, то вам может потребоваться вернуться к модели таблицы ссылок вместо.

Как построить таблицы ссылок-сложная тема, но опирается на традиционные методы проектирования таблиц ссылок базы данных. Легко ошибиться и создать связывающие таблицы, которые могут показаться правильными результатами в интерфейсе, но чрезмерно велики, потребляя ресурсы памяти и процессора.

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

Я надеюсь, что это краткое, далеко из исчерпывающего, введение в моделирование нескольких фактов в QlikView доказывает некоторую помощь и устанавливает вас на правильный курс.


два самых быстрых способа, которые я могу придумать:

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

B) вы можете переименовать общие поля, что можно сделать с помощью

  1. С помощью QUALIFY (перед загрузкой таблиц фактов) и UNQUALIFY (после загрузки таблиц фактов)
  2. переименование поля с помощью " [старое поле Name] как [новое имя поля]"

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

Я бы пошел с B-1, так как это кажется немного менее хлопот.

QUALIFY
A,
B,
C,
ID;

FactTable1:
Load ID,
A,
B,
C,
From [FactTable1];

FactTable2:
Load ID,
A,
B,
C,
From [FactTable2];

UNQUALIFY
A,
B,
C,
ID;

EDIT: если вы хотите создать таблицу ссылок из них, вы можете объединить таблицы фактов в одну таблицу, где вы поместите в нее все столбцы (для многих столбцы, но QlikView хорош с нулями).

обычно я загружаю таблицы фактов и создаю поле id (RowNo () или autonumberhash128 ([список уникальных имен полей id]), затем, когда я загружаю их в таблицу ссылок, я включаю это поле id в таблицу ссылок. Наконец, я удаляю все общие поля из таблиц фактов, поэтому они существуют только в таблице ссылок.


однако каждая таблица фактов имеет другое подмножество "общих" полей, поэтому я не смог бы правильно ввести свои таблицы фактов.

одним из входов в ваше декартово измерение будет "N / A" против испытуемого и тестового кода (так как этого нет в таблице зачислений)

поэтому, когда вы измеряете по "полу", тестовые баллы совпадают с записями измерений с допустимыми предметами и тестовыми кодами, а Регистрация соответствует записям с "N / A" Предметы и коды тестов

затем, когда вы сворачиваете по полу, все "просто работает" красиво.