Многомерность является важной особенностью хранилища данных.
не «обходной путь» для ограничений реляционной модели. Это лучший способ моделирования данных, где вам нужно сделать произвольный анализ «фрагментов и кубиков» фактов в отношении множества нетривиальных измерений.
Запросы Star-schema не очень сложны. Они на самом деле очень простые, так как они почти всегда имеют форму SELECT SUM(MEASURE) FROM FACT JOIN DIM1 ON ... JOIN DIM2 ON ... WHERE....
Взаимодействие - как правило - медленное. Однако объединения могут выполняться в объектно-ориентированном коде вместо хранилища SQL.
Во многих случаях большинство измерений на самом деле довольно мало и полностью помещается в память. Аналитические запросы могут переходить к простым выборам всех фактов, за которыми следуют запросы памяти размерных атрибутов в памяти.
В остальных случаях у нас есть схема снежинок, где измерение (как правило, клиент, пациент или размер элемента) почти такое же, как и соответствующая таблица фактов. В этом случае полезно использовать реляционное соединение в базе данных.
«Базы данных объектов не имеют объединений, потому что отношения между объектами поддерживаются прямыми ссылками».
Не совсем верно. База данных объектов имеет навигацию от объекта к объекту. Если вы получите набор объектов вместе со связанными с ними объектами, будет выполнена операция соединения - по сути -.
«Вопрос в том, нужны ли нам одни и те же концепции (многомерная база данных - хранилище данных и т. Д.), Когда мы говорим о бизнес-анализе базы данных объектов?»
Да. Многомерность необходима. Абсолютно. Объектная база данных будет представлять это точно также (или, возможно, лучше), чем реляционная база данных. Любая модель, однако, должна представлять существенную истину Меры и их размеры.