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