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

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.

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

Кстати, тут затронута интересная тема измерения для разрешения ситуаций, подобных указанной. Кто как готовит подобные измерения?

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

И мой личный способ:

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

The Data Warehouse ETL Toolkit R.Kimball, J. CasertaVirtually every fact table has a primary key defined by a subset of the fields in the table. In Figure 6.1, a plausible primary key for the fact table is the combination of the ticket number and line number degenerate dimensions. These two fields define the unique measurement event of a single item being run up at the cash register. It is also likely that an equivalent primary key could be defined by the combination of cash register and the date/time stamp.
It is possible, if insufficient attention is paid to the design, to violate the assumptions of the primary key on a fact table. Perhaps two identical measurement events have occurred on the same time period, but the data warehouse team did not realize that this could happen. Obviously, every fact table should have a primary key, even if just for administrative purposes. If two or more records in the fact table are allowed to be completely identical because there is no primary key enforced, there is no way to tell the records apart or to be sure that they represent valid discrete measurement events. But as long as the ETL team is sure that separate data loads represent legitimate distinct measurement events, fact table records can be made unique by providing a unique sequence number on the fact record itself at load time. Although the unique sequence number has no business relevance and should not be delivered to end users, it provides an administrative guarantee that a separate and presumably legitimate measurement event occurred. If the ETL team cannot guarantee that separate loads represent legitimate separate measurement events, a primary key on the data must be correctly defined before any data is loaded.

Figure 6.1 Sales Transaction Fact Table:
Calendar Date (FK)>
Product (FK)>
Cash Register (FK)>
Customer (FK)>
Clerk (FK)>
Store Manager (FK)>
Price Zone (FK)>
Promotional Discount (FK)>
Transaction Type (FK)>
Payment Type (FK)>
Ticket Number (DD)
Line Number (DD)
Time of Day (SQL Date-Time)
Sales Quantity (fact)
Net Sales Dollar amount (fact)
Discount Dollar amount (fact)
Cost Dollar amount (fact)
Gross Profit Dollar amount (fact)
Tax Dollar amount (fact)

Переводя Кимбалла на упрощенный русский, PK факта должен быть уникальной комбинацией его FK (обычных или вырожденных). Если реальных FK не хватает, то надо придумать дополнительный FK.

Этот подход выглядит гладко на бумаге, однако на практике с ним возникают проблемы. Например:

• Во-первых, легко сказать: "Команда ETL, роди мне красивый FK в дополнение к имеющимся", но на практике это желание бывает весьма затруднительным и ресурсоемким действием. Большинство разработчиков ETL идут легким путем и создают измерение на основе простого PK источника, после чего в кубе возникает т.н. "monster dimension". Так проблема возвращается обратно к команде BI, а та, в свою очередь, может спихнуть ее на сервера и пользователей.
  
• Во-вторых, пользователи любят спускаться из кубов к фактам. Разница между удобством запросов к СУБД "перейди к факту с идентификатором X" и "перейди к факту с полем ₁ = X ₁ (...) и полем _N = X _N " видна невооруженным глазом.
  

"combination of the ticket number and line number degenerate dimensions" - для куба это FK на вырожденные измерения номеров билетов и строк в них.
И породить тем самым немало непростых проблем, не считая уже упомянутого "monster dimension". В отличие от PK источника, у порядкового номера строки нет связи с источником (пользователь не сможет найти по нему факт в источнике), порядковый номер не поддержит расчет инкремента.

У суррогатного ключа, как правило, есть связь 1:1 с PK источника. Да, разрешение идентификаторов может создавать на больших объемах проблемы, но, как правило, польза перевешивает. Сейчас я склонен протягивать в последующую систему все варианты ключа предыдущих: РК систем-источников, СК хранилища и составной ключ для кубов.

Мы явно друг друга не понимаем.
Еще раз. У Кимбалла стоит задача загрузить данные из исходной системы в куб. Он говорит: назначим РК комбинацию номера билета и номера строки в нем.

Я делаю допущение, что в исходной системе у каждого факта есть свой РК (обычно в ОЛТП бывает именно так). Однако Кимбалл не захотел грузить его в куб, считая его избыточным, и чтобы не получить монструозное измерение. Мне просто не приходилось сталкиваться с неуникальными фактами в источниках, а сам я такого не проектировал тем более.

Вы предлагаете создать РК как номер загрузки и номер строки в загрузке. По форме он полностью аналогичен решению Кимбалла (составной ФК), однако по сути, в отличие от его решения, никак не разрешается в исходный РК факта.

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

Ivan Durak,

противников наличия РК у фактов здесь нет. Речь о том, каким он должен быть.

Кимболл считает, что его надо готовить из ФК (обычных или вырожденных), исходя из пользы для куба.
Его эпигоны пишут, что ЕТЛ нуждается в СК, поэтому данное поле тоже надо грузить (я бы охарактеризовал это как столкновение "кимболловщины" с жестокой реальностью)