Subtypes and Supertypes Setting the Scene

POTT нарушает независимость данных


Одна из причин, по которой мы отвергаем POTT, является то, что эта идея ведет к утрате независимости данных. Как я уже отмечал, POTT означает, что любая структура данных, которая может быть создана в традиционной прикладной программе, может быть сохранена как объект в объектной базе данных, и структура таких объектов является видимой для пользователя. Конечно, это подход "все годится" по отношению к тому, что может содержаться в базе данных, является основным отличием объектной модели от реляционной, поэтому рассмотрим его более пристально. Замечание: В целях обсуждения я предполагаю, что термин объектная модель является хорошо определенным и хорошо понимаемым, хотя такое предположение -- мягко говоря -- немного льстит объектам.

При принятии этого предположения мы можем охарактеризовать различия между этими двумя подходами следующим образом:

  • Объектная модель говорит, что мы можем поместить в базу данных все, что угодно (любую структуру данных, которую можно создать с использованием механизмов обычного языка программирования).

  • Реляционная модель говорит, по существу, то же самое -- но требует, чтобы все, что бы не было помещено в базу данных, представлялось для пользователя в чисто реляционной форме.

    Более точно, реляционная модель совершенно правильно не говорит ничего о том, что может быть физически сохранено. Поэтому она не накладывает никаких ограничений на то, какие структуры данных допустимы на физическом уровне; единственное требование состоит в том, что любые физически хранимые структуры должны отображаться в отношения на логическом уровне и быть скрыты от пользователя. В реляционных системах четко различаются логика и физика (т.е. модель и реализация), а в объектных системах - нет.

    Одним из последствий этого положения дел, как уже говорилось -- в противоречии с традиционным здравым смыслом -- является то, что объектные системы могут поддерживать меньшую независимость данных, чем реляционные системы. Например, предположим, что в некоторой объектной базе данных реализация упоминавшегося ранее объекта EX (коллекции служащих данного отдела) изменяется из массива в список со ссылками.
    Что произойдет с существующим программным кодом, обращающимся к объекту EX? Он сломается.

    Возможно, мне следует задать еще один вопрос: Зачем нам нужно менять реализацию EX таким способом? Конечно, в основе ответа лежит эффективность. В идеале изменение не должно затрагивать ничего, кроме эффективности; однако на деле это не так.

    На самом деле, мне кажется, что возможность наличия всех этих разных способов представления данных на логическом уровне является примером того, что я называю ложной общностью. Я бы даже сказал, что вся эта идея проистекает из неудачи четкого разделения модели и реализации (может понадобиться множество разных представлений на физическом уровне, но они не нужны на логическом уровне). Помню, как однажды сказал Э.Ф. Кодд (E.F. Codd) (в ответ на вопрос на панельной дискуссии): "Если вы скажете, что имеете в своей системе 50 разных способов представления данных [на логическом уровне, конечно], то я скажу вам, что 49 из них - лишние".


    Содержание раздела