В общем есть два факта, один это Permission которые дал пользователь, второй это заявки.
Факты имеют разный grain, первый это то что пользователь когда делал заявку дал разрешения на просмотр каких либо данных приложению, для одной заявки там будет множество строк, также он может бросить делать заявку, отозвать permission, потом продолжить и опять дать, второй факт это сами заявки. В чем суть, у заявок есть атрибуты, в источнике хранилось в одной таблице все, здесь вынес в Dimension, там статус, флаги, шаг заполнения и прочее, так вот, мне необходимо вытащить ключи нескольких подобных справочников из заявок в permission, сейчас делаю join во вью и забираю эти ключи, в принципе быстро, но вопрос, может я что-то упустил и вообще насколько это правильно?
Как понятно из описания факты обновляются, по другому никак, есть куча разных временных меток которые меняются, меняется статус, флаги и прочее, делаю MERGE, данные сначала лью в stage за один день, работает быстро.
Есть еще несколько подобных случаев когда во вью тащу ключи атрибутов из другого факта, так как сразу брать нельзя, потом может меняться ключ атрибутов. Т.е. к примеру был звонок, в это время заявка была в определенном статусе с опреденным набором флагов, звонок закончился, больше строка не меняется и новая вставляться не будет, но! через месяц может поменяться атрибуты заявки и они должны быть в этом звонке, т.е. ключ этих атрибутов, с permission примерно также.

Дополню что примерно тоже самое делаю когда грузятся к примеру контракты, т.е. к заявке идет контракт и когда заявка до него дошла она уже не меняется и я во время загрузку join к факту делаю и забираю ключи, есть все нужные индексы чтобы поддержать такие запросы, поэтому работает быстро, т.е. здесь на этапе ETL это делается.
Во время проектирования можно было вынести заявки как справочник, точнее их атрибуты, т.е. по сути факт заявок (тут были бы только даты и сумму) был 1 к 1 со справочником, встречал подобные реализации в сети и у тут спрашивал, советовали так сделать, но их сейчас 20 млн и прибавляется по пару сотен тысяч в день, не вариант.

sharkoff_new,

Спасибо за ответ!
MS SQL 2017, SSAS Tabular + Power BI Live Connection.
Я знаю что факты вяжутся через Dim и напрямую они не связаны. Схема огромная, проще так написать.
Первый факт - Заявки, в нем даты (создания, подтверждения телефона, прохождения определнного шага), суммы (сколько хотел получить, сколько получил и т.д.) и ключи справочников.
Второй факт, звонки - дата и время и ключи своих справочников, а также общих с заявками, вроде клиента и сотрудника, здесь все просто.
Есть Dim, это атрибуты заявки, вроде статуса, кол-во попыток, определенные флаги и т.д., ключ этого справочника должен быть сквозной по всем фактам так или иначе связанным с заявками, в данном случае звонки.
Теперь в чем вопрос, к примеру был звонок, 20190320 по заявке, в это время заявка была в статусе Pending, кол-во попыток было 5 и какой либо флаг стоял 0 к примеру, 20 числа эта строка по звонку попала в хранилище, все, больше она не обновляется и никак не меняется, но заявка живет дальше, 21 числа кол-во попыток стало 7 и статус Accepted, флаг = 1, у заявки поменялся ключ справочника на новый (как я писал факты обновляются, но это быстро, история не нужна), но у звонка который был 20го тоже должен взяться новый ключ атрибутов заявки, т.е. в звонках должен быть ключ атрибутов заявки актуальный на сейчас, а не на момент звонка.
Вот и вопрос как это лучше сделать.
Сейчас во вью для загрузки в модель я делаю join факта заявок и факта звонков, чтобы вытащить этот ключ, работает быстро, там колоночный индекс и прочитать пару хорошо сжатых столбцов не долго, но хотелось бы знать как правильно такое решается. Т.е. факты не связаны в модели никак, они связаны через справочник атрибуты заявки, проблема в том чтобы получить ключ этого справочника, т.к. в одном факте данные не меняются никогда, а во втором часто.

aleksrov,

MS SQL 2017, SSAS Tabular + Power BI Live Connection + SSIS для загрузки

aleksrov,

Т.е. еще раз резюмирую: как в одном факте получить ключи другого факта, если во втором они часто меняются.
Как пример, не очень удачный но может более понятный, к примеру есть заявка на кредит, в ней указан поручитель, оператор позвонил ему и в таблице со звонками записалось что кредит был выдан под поручительство человека с id = 100 (при этом в источнике нет данных по поручителю, они есть ТОЛЬКО в кредите, в звонке только ID кредита, но они нужны и в звонке, поэтому в ETL мы забираем эти данные из кредита), потом через полгода по этому кредиту поручитель поменялся и запись в звонке что кредит был выдан под поручительство человека с id = 100, должна поменяться на id = 9000. А потом через год он еще раз поменялся и т.д., сама строка со звонком в источнике не меняется, т.к. там не данных о поручителе, эти данные есть только в кредите, но звонок должен меняться также как и кредит.
Надеюсь так более понятнее.
Тут 2 варианта как по мне, 1й правильнее и наверное буду его делать.
1) Когда поменялись данные по кредиту в ETL помимо строки в таблице с кредитами обновлять все строки звонков связанных с этим кредитом.
2) Сделать как у меня, при загрузке данных в модель через join получать ID (Key) последнего поручителя для всех звонков.