Мы находимся в процессе внедрения нового хранилища данных с использованием методологии Data Vault в базе данных Snowflake. Наше намерение состоит в том, чтобы придерживаться самых последних стандартов и передовых практик, насколько мы можем, например, использовать только вставку и пытаться избегать различных анти-паттернов, таких как, когда это практически возможно, связывание ключей ( см. Комментарии здесь для обсуждения ключей управления ).
Ниже приведен упрощенный пример раздела наших данных, относящихся к рейтингам, присвоенным объектам недвижимости с течением времени (представьте себе рейтинги отелей или аналогичные).
Центральным в этом является таблица, связывающая недвижимость с рейтингом. В следующем примере показана история рейтингов для одного свойства по двум разным схемам.
PropertyRatingID PropertyID RatingSchemeID RatingID EffectiveDate
1 1 1 1 2020-01-01
2 1 1 2 2020-01-02
3 1 1 1 2020-01-03
4 1 2 3 2020-01-02
5 1 2 4 2020-01-03
Соответствующая информация, касающаяся структуры данных.
- PropertyRatingID - это ключ идентификации для обеспечения уникальности и не имеет делового значения.
- В любой момент времени свойство может иметь только одну оценку для одной схемы, но может оцениваться по нескольким схемам
- PropertyID, RatingSchemeID и EffectiveDate не обязательно должны быть уникальной комбинацией.
- EffectiveDate не представляет дату, в которую запись была введена в систему, и ее можно задним числом перенести в прошлое на значительный промежуток времени, создавая двухпалатную ситуацию между датой вступления в силу и датой применения изменения.
- PropertyID, RatingSchemeID и RatingID являются внешними ключами для других таблиц, предоставляющих описательные данные. Свойство уже существует как отдельный концентратор в нашей модели.
Временная шкала, описанная выше, может быть изображена следующим образом.
Date Scheme1Rating Scheme2Rating
2020-01-01 1 NULL
2020-01-02 2 3
2020-01-03 1 4
2020-01-04 1 4
Моя первоначальная попытка смоделировать это создать концентратор для RatingID, ссылку между свойством и рейтингом и спутник, присоединенный к ссылке, используя PropertyRatingID, содержащий всю другую информацию (в первую очередь, BrandID и EffectiveDate), чтобы сделать его мультиактивным. Это оказалось очень трудным для использования, потому что ключевой фактор изменений (PropertyID и BrandID был распределен между каналом и спутником).
С точки зрения двусторонней ситуации, основное внимание будет уделено получению последнего записанного набора дат вступления в силу (т. е. самой последней системной даты) для создания истории рейтингов с течением времени, например, EffectiveEndDate становится эквивалентом LEAD(EffectiveDate) OVER(PARTITION BY PropertyID,RatingID ORDER BY EffectiveDate ASC) в исходной таблице. Хотя мы не будем регулярно использовать записи значений из прошлых системных времен, мы будем время от времени рассматривать их на произвольной основе c, чтобы объяснить изменения в истории между отчетными периодами.
Простое решение было бы объединить несколько таблиц в исходной системе, чтобы сгладить данные, разделить их и создать спутник по схемам оценок и присоединить его непосредственно к концентратору свойств. Это дало бы нам краткосрочное решение, но было бы негибким (требующим нового концентратора для любых новых рейтинговых схем) и все же требовало бы, чтобы эти спутники были мультиактивными, чтобы поддерживать текущую дату в исходной системе с несколькими действующими датами.
Я считаю, что для идеального решения требуется, по крайней мере, еще один концентратор, связанный с ключом вождения, и, возможно, второй, связанный с присвоением рейтинга имуществу. Большая часть моего чтения (см. Предыдущую ссылку и эту статью ) подразумевает, что мой спутник должен быть подключен к концентратору, а не к ссылке.
Каким будет эффективный подход к модели это с использованием методологии Data Vault?
Мне было бы интересно обсудить преимущества предлагаемого решения, например, дополнительные «слабые» концентраторы по сравнению с решением основных проблем в более сложных запросах.