Предположим, есть БД на MSSQL2k.
4 таблицы: Время, Продукты, Клиенты, Факты, на основании которых строится OLAP куб на MSAS2k. Насколько важно для MSAS иметь в таблицах ключи и индексы? В данный момент между таблицами существуют только логические связи типа Клиент.id = Факт.Клиент, не выраженные никак ни в ключах, ни в индексах.

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

Ссылочная целостность обеспечивается в рабочей базе, а рассматриваемая база была создана только для того, чтобы обеспечить более "прозрачный" перенос данных в OLAP.
Время выборки и обновления кубов не критично - 5 минут в этом случае роли не играют.
А вот использует ли MSAS эту информацию (индексы и ключи) для более эффективного связывания измерений....
Копнем глубже... Скажем так: из таблицы Продукт создается 5 измерений:
Категория, Марка, Производитель, Упаковка, Вес (желание заказчика и об эффективности такого подхода здесь не говорим). В таблице продукт есть все и их идентификаторы и наименования. (Таблица Продукт не что иное как денормализованная версий этих таблиц из рабочей базы).
При создании куба, что все эти измерения не зависят друг от друга никак. Пример: Марка по строкам Вес по колонкам даст нам у каждой марки все возможные веса, даже в том случае если таковых нет. Или еще хуже: Производитель и Марка по строкам даст нам пересечение каждого производителя с каждой маркой (если не опускать пустоты). Так вот наличие ключей в исходных таблицах окажет какую-нибудь помощь MSAS при создании куба? В дальнейшем будет ли MSAS оптимизировать подобного рода пересечения при запросах - т.к. 90% информации отсутствует?

Не думал, что тема многим окажется так интересна. Спасибо за поддержку.
В общем можно подвести черту.
Ключи и индексы нужны для себя любимого, чтоб где-то не лопухнутся.
MSASу наши ключи глубоко, мягко скажем, безразличны и влияют они только на скорость выборки при обновлении куба. При построении кубов MSAS использует собственные средства и правила (Schema Optimizing) основанные только на внутренней логике, заложенной его разработчиками.
Следовательно к вопросу выборки информации из куба ни ключи, ни индексы в источнике отношения не имеют и никак на этот процесс не влияют.

2 Dmitry Biryukov
Про "виртуальные измерения": я так и сделал с самого начала, начитавшись, что именно в этой ситуации они мне помогут, но как оказалось совсем не помогают (или этого не видно) т.к. несуществующие связи все-равно остались (каждый производитель имеет все марки продуктов). К тому же в BOL ясно написано, что в виртуалных измерениях свойство Depends On Dimension имеет совсем другое значение, а именно указывает только на то, на основании какого измерения построено виртуальное. Потом, для виртуальных не создается никакая агрегация и все считается во время выполнения запроса - значит будет все медленнее. Я переделал измерения с виртуальных на реальные, установил свойство Depends on... Однако ничего не получилось - все осталось на своих местах (все производители и у каждого все продукты). Если Вы внимательно перечитаете информацию из BOL, то поймете, что это свойство влияет только на расчет предварительного размера базы в процессе создания агрегатов. Да, конечно агрегат для несуществующих пересечений не создается, но при запросе информации пересечение все же имеет место, хотя и возвращает в этом случае NULL. Вот эти изыскания и натолкнули меня на мысль о возможной необходимости ключей в источнике, но как видимо, я ошибался. Неужели придется делать столько иерархий для измерения продукт сколько возможных (необходимых) комбинаций подобного рода измерений существует, т.е. вместо 5 измерений у меня будет в худшем случае 320 иерархий?