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

Question

У меня есть база данных 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 и работаю сам. Как обычно обрабатываются множественные факты разных зерен с общими измерениями?

EDIT:

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

Answer 1

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

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

Проблема: У вас есть несколько таблиц фактов в вашей базе данных; появление почти в каждой базе данных. Некоторые (или все) эти таблицы фактов имеют одни и те же ключевые поля; не проблема, не так ли? Неправильно. К сожалению, из-за ассоциативной природы 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 и добавьте новые ключи в таблицу ссылок, а также добавьте новый конкатенированный ключ в таблицу ссылок. Он масштабируется без особых усилий.

Удачи!

Answer 2

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

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

B) Вы можете переименовать общие поля, которые могут быть сделаны по

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

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

Я бы пошел с 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 хорош с нулями).

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

Answer 3

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

Один из входов в ваше декартово измерение будет «N/A» против субъекта и Code Test (так как это не входит в таблице Учащихся)

Итак, когда вы измерить «Пол» Тест Оценки совпадают с записями измерений с действительными объектами и тестовыми кодами, а учетные записи соответствуют записям с темами и тестовыми кодами «N/A».

Затем, когда вы свертываете Пол, каждый человек «просто работает» красиво.

Answer 4

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

1. Append ваши таблицы фактов в одну таблицу фактов, - как правило, называют каскадным FACT как синтаксис QlikView для добавление данных в таблицы с использованием префикса конкатенации ( эквивалента операции SQL UNION)

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

Положительных:

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

Отрицательные:

1. Различные факты НЕ напрямую связаны друг с другом. Значение важно понимать. Это означает, что перекрестный анализ фактов, как правило, возможен только в общих измерениях. Любые фактические измерения никак не связаны с записями фактов, которые не ссылаются на эти измерения. Синтаксис сложного «набора анализа» может в какой-то мере смягчить этот недостаток, но если ваше основное требование - косвенный анализ факта A по фактическим параметрам факта B, тогда вам может потребоваться вернуться к модели таблицы ссылок.

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

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

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