Многомерная модель: Против
Для создания многомерной модели требуется разработать комбинацию составных данных, все DDL (операторы определения данных), программы извлечения данных; все сценарии нагрузки должны работать в соответствии с моделью и поддерживать ее. Многомерное моделирование уменьшает рабочую нагрузку СУБД и перекладывает работу на плечи разработчика базы данных. Очевидно, что это не идеально; база данных может работать быстрее и точнее, чем люди, у которых уже имеется трудная задача реализации сложного склада данных. Появляются дополнительные расходы, связанные с выполнением работы вручную.
Дополнительной ценой многомерного моделирования является свойственная денормализации (через внешние соединения) избыточность данных. Кроме того, для обеспечения доступа к большой денормализованной таблице фактов часто приходится создавать много индексов, чтобы избежать сканирований, и несколько уровней сводных таблиц, чтобы избежать как сканирований, так и агрегаций. СУБД должна поддерживать это при обновлениях, что иногда занимает больше времени, чем бы этого хотелось, и всегда отнимает ресурсы, которые правильнее было бы потратить на выполнение запросов. По определению (и даже по своей номенклатуре) многомерные модели ограничены построенными измерениями. Для большинства запросов и бизнес-вопросов этих измерений достаточно. Но известные вопросы, заранее подготовленные, ожидаемые вопросы сами по себе обладают относительно низкой значимостью. Они могут возвращать полезную информацию, но вы можете достичь понимания и мудрости, преобразующих деятельность компании, только размышляя "за пределами звезды".
