Всем привет!
На самом деле вопросов несколько, буду крайне признателен за помощь.
1) Есть DimCustimer, обычная такая Dim, НО бизнес хочет хранить историю ЛЮБЫХ изменений, за последнии N месяцев, т.е. если у него изменился хотя бы один из атрибутов, то мы перезаписываем данные как в scd 1, а старую строку делаем historical, при этом у новой SurogateKey должен быть как у старой записи. Т.е. был surkey = 1, cust_id = 1, phone = 44444, у него поменялся телефон, новая строка surkey = 1, cust_id=1, phone = 55555, а старая surkey = (вот здесь что, и куда это строку деть?), cust_id = 1, phone = 44444. Для анализа эти данные не нужны, они понадобятся лишь точечно, когда по клиенту возникнут проблемы (к примеру были случаи мошеничества, и изменения данных клиента пригодились бы), определятся будет во время ETL загрузки, у него есть поле update_at.
Тут было несколько идей: в etl перед обновлением читать строку, сохранять в переменную, обновлять строку, а старую вставлять заново с флагом history, surkey соответственно у нее будет новый.
Или делать тоже самое но вставлять строку в minidim, которая будет хранить только исторические данные и не связана с фактом, с основной dim связь один ко многим.
Также предлагали сделать parent_id в dim, типа у каждой новой строки родитель самая первая, но как-то это не то.....
Кто нибудь делал что нибудь подобное и как это будет выглядеть?
2) Есть большой факт, заявка, у факта много левой инфы которая также нужна но привязана именно к факту, вроде источник откуда пришел клиент (разные сайты, в справочник не вынести), ссылка по которой он клацнул для перехода на наш сайт, столбцы типа в каких он сайтах был залогинен, ip, и прочее прочее. Думал сделать отдельную dim для всего этого, но тогда она будет расти также как fact... В общем здесь тоже вопрос.

Критик,

Спасибо за ответ!
Вопрос если хранить историю отдельно, как это будет выглядеть. Т.е. если взять пример выше, новая строка 1,1,55555, а старая пойдет в другую таблицу вида, id = 1, parent_id = 1, cust_id = 1, phone = 44444. Не идеально, но свою цель выполнит, при необходимости сделать точечный запрос и посмотреть изменения по конкретному клиенту, или вывести клиентов где к примеру было изменение bank_number, т.е. к факту мы даже не обращаемся.
По сайтам возможно засунуть в Dim, а как быть в ip к примеру, или в каждой заявке идет score, что-то вроде рейтинга клиента, но относится именно к заявке, и подобных полей много. По поводу залогинен или нет, там просто одна строка с перечислением сайтов, как это в факт засунуть?

Полковник.aleksrov,

Копай в сторону темпоральной и битемпоральной модели данных, там суррогатный ключ не меняется а данные хранятся с даты начала до даты окончания действия.

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

"темпоральной и битемпоральной модели данных" изучу.
По поводу хеша, смысла нет так заморачиваться, у клиента есть поле update_at, когда будет инкриментальная загрузка мы будем брать всех клиентов у которых created_at или updated_at больше определенной даты, у которых created просто вставляем, у которых updated, обновляем с сохранением сурключа, а старую наверно выносим отдельно. В cтрок с updated будет не сильно много, процентов 5-10%.

Критикaleksrov,

по ip и прочим тестовым полям можно подумать над разделением таблицы фактов на две, которые будут связаны 1-к-1, в одной наиболее часто анализируемые данные, во второй + всякий "проблемный текст"

Наверно так и сделаю. Просто разобью факт на две таблицы, в основной будут все ключи измерений, во второй нет, она будет связана только с фактом. Запросы по ip, score, сайтам и прочему хламу тоже запускаются, это используют уже другие люди, типа data science, которые выявляют зависимости и прочие вещи. Они запускают эти запросы редко, и если запускают они все ровно связаны с основными данными, которые уже интересны бизнесу каждый день, типа даты, суммы и прочее, именно это и будет в "главном" факте. Т.е. для каждодневной или недельной отчетности нам интересны лишь часть данных факта, а для глубокого анализа уже все, из этой логики и буду разбивать.
Спасибо за помощь!