Типичное хранилище данных звездной схемы Кимбалла - Представления модели Возможно? и как кодировать 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

Я подумываю заменить его на представление (скажем, 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

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

Answer 3

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

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

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