Типичное хранилище данных звездообразной схемы Кимбалла — представления модели осуществимы?и как кодировать Gen

Question

У меня есть хранилище данных, содержащее типичные звездообразные схемы, и целый набор кода, который делает такие вещи (очевидно, намного больше, но это для иллюстрации):

SELECT cdim.x
    ,SUM(fact.y) AS y
    ,dim.z
FROM fact
INNER JOIN conformed_dim AS cdim
    ON cdim.cdim_dim_id = fact.cdim_dim_id
INNER JOIN nonconformed_dim AS dim
    ON dim.ncdim_dim_id = fact.ncdim_dim_id
INNER JOIN date_dim AS ddim
    ON ddim.date_id = fact.date_id
WHERE fact.date_id = @date_id
GROUP BY cdim.x
    ,dim.z

Думаю заменить его на view(MODEL_SYSTEM_1, скажем), так что это становится:

SELECT m.x
    ,SUM(m.y) AS y
    ,m.z
FROM MODEL_SYSTEM_1 AS m
WHERE m.date_id = @date_id
GROUP BY m.x
    ,m.z

Но вид MODEL_SYSTEM_1 должны будут содержать уникальные имена столбцов, и меня также беспокоит производительность оптимизатора, если я продолжу и сделаю это, потому что я обеспокоен тем, что все элементы в предложении WHERE по различным фактам и измерениям будут оптимизированы, поскольку вид будет охватывать всю звезду, и виды не могут быть параметризованы (боже, это было бы круто!)

Итак, мои вопросы -

1. Нормален ли этот подход, или это будет просто абстракция, которая снижает производительность и не дает ничего, кроме гораздо более приятного синтаксиса?

2. Каков наилучший способ создания кода для этих представлений, исключая повторяющиеся имена столбцов (даже если представление позже потребуется настроить вручную), учитывая, что все соответствующие PK и FK имеются?Должен ли я просто написать SQL, чтобы вытащить его из INFORMATION_SCHEMA или уже есть хороший пример.

Редактировать: Я протестировал это, и производительность кажется одинаковой даже в более крупных процессах - даже при объединении нескольких звезд, каждая из которых использует эти представления.

Автоматизация обусловлена ​​главным образом тем, что в хранилище данных есть несколько таких звезд, а проектировщики правильно сделали FK/PK, но я не хочу перебирать все таблицы или документацию.Я написал сценарий для создания представления (он также генерирует сокращения для таблиц), и он хорошо работает для автоматического создания скелета из INFORMATION_SCHEMA, а затем его можно настроить перед фиксацией создания представления.

Если кому-то нужен код, я, вероятно, мог бы опубликовать его здесь.

Answer 1

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

2. Я создал представления с помощью дизайнера в студии управления SQL Server и не использовал какой-либо автоматизированный подход.Я не могу себе представить, чтобы схема менялась достаточно часто, чтобы автоматизировать ее вообще имело бы смысл.На настройку результатов вы можете потратить столько же времени, сколько потребовалось бы, чтобы перетащить все таблицы в представление!

Чтобы устранить двусмысленность, хорошим подходом является добавление имени столбца в начале имени измерения, к которому он принадлежит.Это полезно для составителей отчетов и для всех, кто выполняет специальные запросы.

Answer 2

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

Вы можете использовать словарь данных или представления информационной схемы для генерации SQL для создания таблиц, если у вас есть большое количество этих сводок или вы хотите часто их менять.

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

Answer 3

Если вы используете MS SQL Server, вы можете попробовать встроенный UDF, который максимально близок к параметризованный вид как получится.