SSAS табличные-несколько моделей?
Мы начинаем строить табличную модель SSAS и задаемся вопросом, есть ли у большинства людей одна модель или несколько. Если их несколько, дублируются ли таблицы, необходимые для каждой из них, или существует способ совместного использования таблиц между моделями? Я думаю, что знаю ответ, но я надеюсь, что те, у кого больше опыта, смогут подтвердить то, что мы нашли...
Из того, что я исследовал, я думаю... - вы не можете совместно использовать таблицы между моделями - любые "общие" таблицы должны быть дублированы и развернуты с каждой моделью. и будет занимать память - мы должны создать одну модель, использовать перспективы для организации таблиц и упростить работу с ними. - множественные модели могут быть приемлемы, если существует мало или нет общих данных между моделями
Спасибо
2 ответа:
Вы правы, нет никакого способа разделить таблицы между моделями.
Перспективы могут помочь.
Вопрос о том, иметь ли одну модель или несколько, зависит от аудитории пользователей. Кто такие пользователи? Насколько они аналитически подкованы? Будет ли у них разумное понимание структуры модели?
Одна проблема, которая затрагивает моих довольно неискушенных пользователей, заключается в том, что измерение не относится ко всем таблицам фактов. В этом сценарии, как и ожидалось, меры по таблице фактов вычислите одинаковые значения для каждого элемента несвязанного измерения. Для менее осведомленных пользователей эта ситуация сбивает с толку.
Я согласен с ответом Ари и публикую этот ответ, чтобы объяснить свой собственный опыт.
Мы используем несколько больших моделей для более продвинутых пользователей, которые находятся в памяти и обрабатываются раз в неделю. Мы договорились с бизнесом, что эти модели не будут доступны во время обработки, поэтому мы можем обрабатывать, не удерживая транзакцию открытой, что позволяет нам держать гораздо больше меньших моделей, потому что нам не нужно держать 2x размер нашей самой большой модели, доступной для экземпляра. Мы используем перспективы, чтобы упростить представление и уменьшить путаницу для нескольких таблиц фактов. Даже с точки зрения перспективы, модели довольно сложны, и требуется некоторое обучение, чтобы пользователи привыкли работать с различными фактами.
Мы также используем меньшие модели, обычно более ориентированные на конкретную аудиторию/потребности. Многие из них обрабатываются ежедневно и используют транзакционную обработку, чтобы обеспечить максимально возможную доступность для пользователей. Есть несколько измерений, которые используются в некоторые из наших небольших моделей, но мы можем фильтровать их так, чтобы пользователи не видели полный список членов, который уменьшает размер, и был огромным преимуществом для моих пользователей, потому что они видят только те члены, которые имеют факт, который они анализируют, а не список каждого члена, связанного с каким-либо фактом.
Мы используем представления для обеспечения соответствия между моделями, когда измерение используется в нескольких моделях. На мой взгляд, это очень важно, так как это очень запутанно, когда у меня есть то же самое измерение с немного другими именами атрибутов.
Чтобы подвести итог (каламбур)...
Мне нравится разрабатывать и работать с большими моделями. Я думаю, что они отвечают на большее количество вопросов с меньшим количеством работы. Большинство пользователей, с которыми я работал, предпочитают небольшие, более лаконичные модели. Ваши требования к оборудованию сервера / обработке могут также направить вас на меньшие модели, даже если некоторые из измерений будут дублироваться.