Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
хорошо я согласен
Member

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

Что если у меня на ту же самую дату тот же самый товар пробивался несколько раз?
Или, например, это не товар, а оказанная услуга, для которой ценник всегда оговаривается отдельно?

И вот я получаю таблицу сделок (денормализую, в качестве ID сразу value засуну в таблицу фактов для простоты описания)
Дата_ID услуга_ID цена
11.09.2020 скрипт на VBA 10000
11.09.2020 скрипт на VBA 12000
11.09.2020 удаление вирусов 10000
11.09.2020 скрипт на VBA 40000

Понятно, что составной ключ здесь не уникальный. Чтобы получить каноническую таблицу фактов с заданной гранулярностью, я должен сделать таблицу с уникальными ключами. Ок, пробую:
Дата_ID услуга_ID цена
11.09.2020 скрипт на VBA 62000
11.09.2020 удаление вирусов 10000

Но что если пользователь захочет в итоге потом взять не сумму по значениям, а среднее по всем сделкам? Просто по колонке "цена"
Среднее между 62000 и 10000 не то же самое, что среднее в первой таблице.
Скажете, что нужно добавить новую колонку "количество", ок.
Но что если пользователь захочет найти медианную сделку по каждой строке?

Короче, в итоге, у меня не выходит избавиться от "таблицы фактов" такого вида
ID Дата_ID услуга_ID цена
1. 11.09.2020 скрипт на VBA 10000
2. 11.09.2020 скрипт на VBA 12000
3. 11.09.2020 удаление вирусов 10000
4. 11.09.2020 скрипт на VBA 40000

Но это, вроде как, неправильно, потому что Кимбалл пишет:
The fact table has its own primary key composed of a subset of the foreign keys. This key is often called a composite key.


К сообщению приложен файл. Размер - 108Kb
16 ноя 20, 01:19    [22232561]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
НеофитSQL
Member

Откуда: Маями
Сообщений: 760
В графике который вы приложили, включен номер транзакции.

Дата-товар-цена это композитный ключ не на сделки, а на меню услуг, меняющееся изо дня в день.
Добавьте номер сделки, который не повторяется на протяжении одного дня - тогда будет уникальность.
16 ноя 20, 02:21    [22232565]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
.Евгений
Member

Откуда:
Сообщений: 574
Как обычно, Евангелие нуждается в трактователях и интерпретаторах, изменяющих значение первоначальных слов вплоть до противоположного:

https://www.kimballgroup.com/2006/07/design-tip-81-fact-table-surrogate-key/
However, there are a few circumstances when assigning a surrogate key to the rows in a fact table is beneficial:

  • Sometimes the business rules of the organization legitimately allow multiple identical rows to exist for a fact table. Normally as a designer, you try to avoid this at all costs by searching the source system for some kind of transaction time stamp to make the rows unique. But occasionally you are forced to accept this undesirable input. In these situations it will be necessary to create a surrogate key for the fact table to allow the identical rows to be loaded.
  • Certain ETL techniques for updating fact rows are only feasible if a surrogate key is assigned to the fact rows. Specifically, one technique for loading updates to fact rows is to insert the rows to be updated as new rows, then to delete the original rows as a second step as a single transaction. The advantages of this technique from an ETL perspective are improved load performance, improved recovery capability and improved audit capabilities. The surrogate key for the fact table rows is required as multiple identical primary keys will often exist for the old and new versions of the updated fact rows between the time of the insert of the updated row and the delete of the old row.
  • A similar ETL requirement is to determine exactly where a load job was suspended, either to resume loading or back put the job entirely. A sequentially assigned surrogate key makes this task straightforward.
Remember, surrogate keys for dimension tables are a great idea. Surrogate keys for fact tables are not logically required but can be very helpful in the back room ETL processing.
16 ноя 20, 10:35    [22232662]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
Полковник.
Member

Откуда:
Сообщений: 1901
.Евгений,

Евангелие нуждается прежде в его в правильном переводе.
16 ноя 20, 13:02    [22232820]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
bideveloper
Member

Откуда:
Сообщений: 511
НеофитSQL
В графике который вы приложили, включен номер транзакции.

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

Согласен. Обычно по продажам есть номер чека или номер интернет-заказа.
16 ноя 20, 13:17    [22232847]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
Полковник.
Member

Откуда:
Сообщений: 1901
bideveloper,

Если нет цели анализировать данные до номера чека, то лучше свернуть данные в таблице по измерениям.
16 ноя 20, 13:43    [22232885]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
.Евгений
Member

Откуда:
Сообщений: 574
Полковник.
Евангелие нуждается прежде в его в правильном переводе.

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

Кстати, тут затронута интересная тема измерения для разрешения ситуаций, подобных указанной. Кто как готовит подобные измерения?
  • Если использовать поле идентификатора факта, то получим огромное измерение со всеми вытекающими негативными последствиями.
  • поле номера факта за день, как правило, в готовом виде отсутствует и его надо считать - что мне кажется делом ресурсоемким. Да и номеров за день может возникнуть не так мало.
И мой личный способ:
  • При перегрузке фактов из ХД в витрины из полей-ссылок на измерения создается контрольная сумма и в витрину попадает порядковый номер факта с его значением контрольной суммы. Делается это абсолютно параллельно основному потоку, но требует определенного объема памяти под коллекцию счетчиков. Длина полученного измерения оказывается гораздо меньше предыдущих вариантов, а характер распределения его ссылок среди фактов гораздо удобнее для сжатия.
16 ноя 20, 13:43    [22232886]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
Ferdipux
Member

Откуда: Москва
Сообщений: 565
хорошо я согласен
Но что если пользователь захочет в итоге потом взять не сумму по значениям, а среднее по всем сделкам? Просто по колонке "цена"
Среднее между 62000 и 10000 не то же самое, что среднее в первой таблице.
Скажете, что нужно добавить новую колонку "количество", ок.
Но что если пользователь захочет найти медианную сделку по каждой строке?

ЭТО значит, что из моделирования у вас есть бизнес-сущность "сделка" или "заказ". И ID этой сущности вы опустили в данных. Если такие вопросы к сущности "сделка" есть - можно ввести его как скрытое измерение. Обычно код заказа - это так называемое degenerate dimension - которое вроде как dimension (то есть связано с сущностью), но само не имеет атрибутов и не используется для анализа.
16 ноя 20, 14:39    [22232949]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
хорошо я согласен
Member

Откуда:
Сообщений: 389
.Евгений
Как обычно, Евангелие нуждается в трактователях и интерпретаторах, изменяющих значение первоначальных слов вплоть до противоположного:

смеялся с этой формулировки
16 ноя 20, 15:02    [22232987]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
хорошо я согласен
Member

Откуда:
Сообщений: 389
НеофитSQL
В графике который вы приложили, включен номер транзакции.

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

Именно поэтому я перешёл от примера Кимбалла к своему, где номеров уникальных нет.
И вопрос был в его добавлении.
.Евгений, в целом, ответил на этот вопрос
16 ноя 20, 15:05    [22232991]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
Evolex_
Member

Откуда: Екатеринбург->Москва
Сообщений: 318
Вроде бы эта та тема самого распространенного ошибочного толкования кимбала, когда и для суммарных данных и детальных почему-то рассматривают одну и ту же гранулярность (не разделяют эти типы данных) и это еще и приписывают недостаткам dimensional modelling. Часто вижу эти грабли, потом они выливаются в длительные и проблемные процессы возвращения к исходной гранулярности + чаще всего эти проблемы не проявляются одни а сопровождаются целым рядом других ill-designed решений.

Правильно так: детальные данные это не суммарные данные и гранулярнгости для них разные и храним их отдельно.

Сам кимбал называет требование хранить только суммарные данные мифом номер 1:
https://www.silicon.co.uk/workspace/five-myths-dimensional-modelling-137164
Dimensional Models are only for summary data
This first myth is frequently the root cause of ill-designed dimensional models. Because you can’t possibly predict all the questions asked by business users, you need to provide them with queryable access to the most detailed data so they can roll it up based on the business question. Data at the lowest level of detail is practically impervious to surprises or changes. Summary data should complement the granular detail solely to provide improved performance for common queries, but not replace the details.
28 ноя 20, 02:09    [22239624]     Ответить | Цитировать Сообщить модератору
 Re: Читаю книгу Кимбалла. "Факты должны быть представлены составными ключами", но как?  [new]
Полковник.
Member

Откуда:
Сообщений: 1901
Evolex_,

Еще раньше Кимбао говорит, что при построении модели данных один из обязательных шагов - поиск и определение атомарного уровня.
вчера, 20:23    [22241593]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить