2 Jurii:

1) Правильно проектировать хранилище данных (например включить в таблицу фактов избыточность)

Не совсем понятно, что Вы имеете в виду. Какую избыточность Вы предлагаете включать?

2) Правильно выбирать OLAP-инструментарий (который умеет решать такие простенькие задачи визуальными средствами, без написания вьюшек или скриптов).

А какое в данном случае отношение имеет выбор OLAP-средств к вопросу проектирования базы данных?


2 Andronov:

При загрузке таблиц измерений в таблицу вставляется строка (0, НЕИЗВЕСТНО). При загрузке таблиц фактов (если, конечено, Ваше хранилище строится на основе моделей "звезда" или "снежинка") значения NULL соответствующих внешних ключей заменяем на 0.
Это, собственно, то, что рекомендовал GoodLeo. Однако NULL может обозначать разные вещи (неизвестно, повреждено, будет заполнено в будущем или ещё какие-нибудь варианты). Возможно, Вам захочется создать несколько служебных записей с фиксированными ID чтобы обозначать разные ситуации отсутствия данных.
Другой пример - если о данных известно ещё что-то, кроме атрибута, имеющего в нашем случае значение NULL. Тогда, чтобы выжать максимум из доступной информации, можно пойти на усложнение решения. Поясню на примере. Допустим, мы не знаем названия клиента, но знаем из какого он города (город, в данном случае может быть родительским уровнем уровня клиент). Желая сохранить информацию о городе, мы заводим ровно столько фиктивных записей о клиентах, сколько существует городов. Это позволит получить возможность группировки по городам, в которых располагается клиент, однако усложнит процедуры загрузки хранилища. Тут не обойтись просто несколькими служебными записями с заранее известными ключами. Дело сразу же доходитдо генерации суррогатных ключей. Хотя, если Вы строите что-то серьёзное, то суррогатные ключи вылазят сразу.
Придётся выбирать - либо простота загрузки, либо полнота анализа.


2 Jurii:
Юрий, странно, что такие задачи Вы называете простенькими . По моему опыту попадаются очень даже нетривиальные.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

2 Andronov:

На мой взгляд, если Вы проектируете Ваше хранилище данных как "звезду" или "снежинку", то лучше иметь выделенную таблицу фактов в классическом варианте, а не строить её на основе вьюшек.
Вьшки тоже имеют своё место в таком подходе. Например, когда один объект выступает в нескольких ролях, то вместо отдельной таблицы измерения можно построить вьюшки над этой таблицей, которые будут затем использоваться в качестве измерений при выборках. Можно и без них, это всё-таки удобно.
Этот вопрос в свое короткой статье обсуждает Ральф Кимбал. Это здесь: http://www.dbmsmag.com/9708d05.html.

Теперь, что касается вставки строки (0, НЕИЗВЕСТНО). Опять-таки, полагаю классический дизайн - таблица фактов с внешними ключами на таблицы измерений. Очевидно, в таблицы измерений простым INSERT'ом можно вставить эти строки. Соответственно, каждый раз при загрузке таблицы фактов можно будет вместо NULL вставить в соответствующий столбец значение 0.
Если, конечно, Вы захотите продолжить использовать вьюшку в качестве таблицы фактов, то Вам придётся слегка модифицировать её SQL.
Для замены NULL, возникающего в результате внешнего соединения, на 0 можно воспользоваться функцией COALESCE.
Вместо

Пишем


Ну, я думаю, вы это сами прекрасно знаете.
Всё делается средствами SQL. Не думаю, что надо такие задачи нужно перекладывать на OLAP, иначе нужно будет (по Юрию) вибирать тот OLAP, который будет уметь это делать. Зачем сажать себя на иглу?
Продолжаю настаивать на том, что подготовка данных для анализа должна проводиться в максимальном объёме до использования средств OLAP. Это - совершенно отдельная и часто очень сложная задача, в особенности, если источников данных несколько. Данные в 100 процентах случаев (я не ошибся) - грязные и их надо чистить до того, как они попадут в OLAP.

Удачи!

С уважением,
Константин Лисянский
http://lissianski.narod.ru