Типичный склад данных Star-schema Kimball - варианты моделей Возможны? и как закодировать 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 должен был бы содержать уникальные имена столбцов, и я также обеспокоен производительности с оптимизатором, если я сделайте это, потому что я обеспокоен тем, что все предметы в WH пункт ERE через различные факты и размеры получить оптимизирован, так как вид будет через всю звезду, и взгляды не могут быть параметризованным (мальчик, не было бы круто!)

Так что мои вопросы -

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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