Наткнулся на проблему, которую в принципе можно обойти, но хочется сделать все аккуратно. :-)

Имется таблица фактов "Операции", в ней есть поля:
"Источник" и "Тип источника".

"Тип источника" - целое
0 - "Пусто"
1 - "Клиент"
2 - "Поставщик"
3 - "Товар"

"Источник" - строка ключ к разным таблицам соответственно:
0 - ""
1 - Ключ к первичному ключу из таблицы "Клиенты"
2 - Ключ к первичному ключу из таблицы "Поставщики"
3 - Ключ к первичному ключу из таблицы "Товары"

Причем измерения по клиентам имеют свой (расширеный) набор полей,
по поставщикам - короткий, по товарам вообще только поле "Код товара".
В случае с 0 это внутренние операции, не имеющие внешних источников.

С "Пусто" в общем понятно, добавляем в выборку/(таблицу в DWH) пустое поле
С 1 и 2 с очень большим натягом работает UNION из разных таблиц, с пустыми полями, которых нехватает в "Поставщики".

Но вот 3 совершенно неакуратно выходит. Операция очень редкая, была сделана явно с тестовыми намерениями и потом от нее отказались.
И я для быстрого решения просто добавил в UNION еще пару строчек с нехватающими записями. Но не факт, что ситуация не повторится.
А делать UNION со всеми товарами нереально. Их там уже под 300 тысяч.

Поэтому вопрос к гуру:

Как можно связать в кубе с таблицой фактов разные измерения в зависимости от значения поля в таблице фактов?
Или другие предложения по решению проблемы в общем случае.
В общем случае в том смысле, что "Тип источника" может расшириться.

Никто так и не ответил.
Вопрос глупый?
Задача нерешаема в принципе?

Заводить 3 (а в принципе даже 4) колонки в таблице фактов в DWH не очень хорошая идея. Мало того что вырастет размер, так еще и скорость обновления DWH сильно упадет.

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

Пока думаю над другим вариантом, сделать в DWH таблицу "Источник" и там делать один суррогатный ключ, а с остальными данными вязать в представлении. Но тогда эта таблица сильно разрастется в размере.
Поставщиков немного, Клиентов до 30 000, а вот товаров уже под 300 000.
И из-за 2-3 товаров городить огород?

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

Сервера MS SQL 2000 SP4 и MS AS 2000 SP4.

А какая разница в данном случае между UNION и UNION ALL?
Ключи то все равно уникальны и дубликатов все равно нет.
Ну разве скорость у UNION ALL должна быть больше.
Так обновление измерения и так занимает меньше минуты.
В общем это к вопросам оптимизации, а не решения самой проблемы.

Теперь столбец Товар будет вязаться с измерением Товары?

И если измерение Товары будет использоваться, то все операции с пустым столбцом Товары уйдут.
А останется только пару операций.

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

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

Ну почему же противоречит?

Операция 0 это внутренние перемещения без изменений в структуре товаров.
Уценки, накрутки и т.д.
Операция 1 это собственно продажи.
Операция 2 это закупки.
Операция 3 это редкая операция, когда из товаров собирается новый товар-комплект. Поскольку организация тороговая, необходимости особой нет.
Но в таблице операций такие операции есть. Ссылка всего на 2 товара, которые когда то (года 3 назад) собрали в комплект. Видимо пользы в этом не увидели, и сейчас такого не делают. Но поскольку ЕРП управленческая, закрытых периодов нет и остатки считаются с начала времен.

При процессинге в 2000 вообще не была заметна потеря нескольких фактов в 2003 году. Потом поднял для тестов 2005 и он при процессинге куба указал отсутствующие ключи. Тогда на скорую руку я банально добавил в представление 2 этих товара.

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

Если я сделаю связку по ключу с товарами, то когда в отчете будет использоваться измерение товары, возможны выпадения фактов с товарами NULL. Возможны, а не обязательны. Но потратить неделю или две на создание варехауза и собрав куб убедиться в своих подозрениях не хочеться.

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

Я уже принял решение.
Поскольку "Источник" все же отдельная сущность, хоть и составная, я в DWH буду создавать отдельную таблицу со своими суррогатными ключами.
Придеться правда делать на тригерах заполнение, но зато уверенность в последующей работе на все 100%.

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