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

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

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, а затем его можно настроить перед фиксацией создания представления.

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