Что же такое "модель данных"?
В [4] Эдгар Кодд пишет: "Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Соответственно, эта модель обеспечивает основу языка данных высокого уровня, который поддерживает максимальную независимость программ, с одной стороны, и машинного представления и организации данных с другой." Более общее определения понятия модели данных приводится в [5]: "Модель – это абстрактное, замкнутое, логическое определение объектов, операций и т.д., совместно представляющих абстрактную машину, с которой взаимодействуют пользователи". Оба эти определения являются существенными.
В первом из них говорится конкретно про реляционную модель, и, основываясь на этом определении, Кодд далее говорит, что единственной "родовой" структурой, с которой должны иметь дело пользователи реляционных систем, является n-арное отношение. И языки, на основе которых пользователи должны иметь возможность взаимодействовать с реляционными базами данных, должны строиться на уровне отношений, а не отдельных кортежей (т.е. записей данных). И в качестве эталона для создания таких языков Кодд предлагается механизм реляционной алгебры (а в последующих статьях еще и механизм реляционного исчисления).
Собственно, о том же говорят и Дейт с Дарвеном в [5], только уже по отношению к любой модели данных. В определении из [5] ключевые слова – абстрактное, замкнутое, логическое определение. Т.е. в этом определении не должно содержаться ничего лишнего, что в принципе может изменяться от одной реализации к другой. Этому определению соответствует реляционная модель в смысле Кодда, "истинно" реляционная модель в смысле "Третьего манифеста" [5], модель данных SQL и объектно-ориентированная модель данных ODMG 3.0 (см. например, [6]).
Например, в случае модели данных SQL родовой структурой данных является таблица (мультимножество строк), а языком – сам язык SQL с его операциями SELECT, INSERT, DELETE, UPDATE.
В случае модели данных ODMG 3.0 структуры хранимых данных задаются средствами определения атомарных объектных типов и объектных типов коллекций, а для доступа к данным определяется язык OQL. В языковых средствах некоторых моделей данных присутствуют явные операции обновления данных (например, в модели SQL), в некоторых моделях они полностью отсутствуют (т.е. отдаются на откуп реализациям; например, в модели ODMG), в третьих моделях в качестве единственной операции обновления базы данных вводится операция присваивания).
Для реляционной модели данных (и "истинно" реляционной модели), а также для модели данных SQL некорректно говорить об "эффективности" выполнения операций выборки и обновления данных, поскольку это полностью зависит от реализации. Можно (хотя и очень сложно) говорить об эффективности представления данных на уровне модели и о возможности выполнения над этими данными операций, требуемых конкретным приложениям, путем использования языка баз данных, определенного в модели.
Отмеченная сложность проистекает из того, что во всех современных моделях данных (в "истинно" реляционной модели, модели данных SQL и объектно-ориентированной модели) предусматриваются возможности определения произвольно сложных типов данных, позволяющих, например, определять вложенные иерархические структуры данных в реляционной модели и модели данных SQL и хранимые мультимножества строк в объектно-ориентированной модели. Так что очень трудно сказать, какую из моделей стоило бы выбрать, если вообще на касаться вопросов их реализации.
Наконец, необходимо заметить, что, несмотря на наличие большого числа реализаций СУБД, создатели которых утверждают о поддержке многомерной модели данных (например, многомерная аналитическая СУБД Essbase, "послепиковские" СУБД Universe и Unidata, основанная на M-технологии СУБД Cache, основанная на "многомерных массивах" SciDB и т.д.), мне никогда не встречалось ни одной попытки общего определения многомерной модели данных.
Поэтому, чтобы иметь возможность сравнивать многомерную модель данных с какой-либо другой моделью, неоходимо ее сначала определить, хотя бы на таком не слишком строгом уровне, как это сделал Эдгар Кодд в своей первой статье о реляционной модели данных (вернее, во второй статье, первой была [7]). Наверное, сообществу "многомерных СУБД" следовало бы поискать в своих рядах нового "Кодда", который решился бы на эту (скорее всего, неблагодарную) работу. По крайней мере, в ее результате можно было бы понять, насколько правомерно использование одного и того же термина multidimensional применительно к настолько разным системам. А пока такой модели нет, можно позволить себе только сравнивать "многомерные" реализации с другими "многомерными" или "немногомерными" реализациями.
