Предложения, касающиеся управления объектами и правилами
Создатели СУБД не в состоянии предвидеть все виды элементов данных, которые могут потребоваться приложениям. СУБД третьего поколения должны управлять разнообразными объектами, и авторы манифеста выдвигают четыре предложения, относящиеся к управлению объектами, конструкторам типов, наследованию, функциям и уникальным идентификаторам.
Предложение 1.1: Система типов СУБД третьего поколения должна быть богатой и разнообразной.
Все перечисленные механизмы являются желательными:
1) система абстрактных типов данных для создания новых базовых типов;
2) конструктор типа массив;
3) конструктор типа последовательность;
4) конструктор типа запись;
5) конструктор типа множество;58
6) функции как тип;
7) конструктор типа объединение;
8) рекурсивная композиция всех перечисленных выше конструкторов.
Первый механизм позволяет конструировать новые базовые типы в дополнение к стандартному набору типов, имеющемуся в большей части систем. Должно быть возможно определять типы битовых строк, точек, линий, комплексных чисел и т.д. Второй механизм позволяет использовать массивы элементов данных. Обычным свойством массивов является отсутствие возможности вставить новый элемент в середину, сдвинув все последующие элементы. В некоторых приложениях такая вставка бывает необходимой, и конструктор третьего вида поддерживает подобные последовательности. Четвертый механизм позволяет группировать элементы данных в записи. Пятый механизм требуется для создания неупорядоченных наборов элементов данных или записей. Шестой механизм – функции (методы) – обсуждается в предложении 1.3; желательно, чтобы СУБД поддерживала такие конструкции. Следующий механизм позволяет создавать элементы данных, которые могут принимать значения одного из нескольких типов.59
Последний механизм позволяет рекурсивно комбинировать конструкторы типов для поддержки сложных объектов, обладающих внутренней структурой.
Более того, в отличие от систем второго поколения, последний примененный конструктор типов не обязан быть конструктором множеств.60
Возможно, со временем станут желательными и дополнительные конструкторы типов. Например, системы обработки транзакций управляют очередями сообщений. Поэтому может возникнуть необходимость в конструкторе, создающем очереди.
Системы второго поколения обладают лишь частью перечисленных конструкторов типов, и сторонники объектно-ориентированных баз данных утверждали, что для поддержки всех этих возможностей должны появиться качественно новые СУБД. Авторы манифеста придерживались другой точки зрения. В манифесте утверждается, что все обсуждаемые конструкторы типов можно добавить к реляционным системам как естественное расширение, и что технология этого расширения достаточно хорошо продумана. Более того, уже в то время начали появляться коммерческие реляционные системы с некоторыми из перечисленных возможностей.
Предложение 1.2: Наследование – хорошая идея.
Возможность организации типов в иерархию наследования является хорошей идеей. Более того, авторы манифеста считали, что существенно множественное наследование, так что иерархия наследования должна представляться ориентированным графом. Поддержка только единичного наследования оказывается недостаточной для адекватного моделирования подавляющего большинства ситуаций. Отмечается, что, хотя в Первом манифесте и защищается идея наследования, множественное наследование там приводится как необязательная возможность.
Желательно также иметь наборы, для которых не задаются дополнительные поля. Например, набор TEENAGER (подросток) можно было бы определить как набор, состоящий из таких же элементов данных, что и PERSON , но обладающий ограничениями на возраст. Опять-таки, уже создавались прототипы, демонстрирующие, как добавлять эти возможности к реляционным системам, и авторы манифеста ожидали, что коммерческие реляционные системы будут развиваться в этом направлении.61
Предложение 1.3: Функции, в том числе процедуры и методы баз данных, и инкапсуляция – хорошие идеи.
В системах второго поколения имеется лишь ограниченная поддержка функций и инкапсуляции. Например, в SQL над таблицами возможны только операции, осуществляемые функциями create , alter и drop .62 Абстракция таблицы доступна только путем выполнения одной из перечисленных функций.
Очевидно, что выгоды, предоставляемые инкапсуляцией, должны стать доступными для разработчиков приложений, чтобы те могли ассоциировать функции с пользовательскими наборами данных. Например, должна иметься возможность ассоциировать функции HIRE ( EMPLOYEE ) , FIRE ( EMPLOYEE ) и RAISE - SAL ( EMPLOYEE ) (нанять, уволить служащего и повысить ему зарплату) с уже знакомым набором данных EMPLOYEE . Если пользователям не разрешен прямой доступ к набору EMPLOYEE , а вместо этого предоставлены упомянутые функции, то вся информация о внутренней структуре объектов класса EMPLOYEE инкапсулируется внутри этих функций.63
Использование инкапсуляции дает административные преимущества путем поощрения модульности и регистрации функций вместе с инкапсулируемыми данными. Если набор EMPLOYEE изменяется так, что его предыдущее содержимое нельзя определить как представление, весь код, который необходимо изменить, локализован в одном месте, следовательно, его проще модифицировать.
В защищенных или распределенных системах применение инкапсуляции часто дает выигрыш в производительности. Например, функции HIRE ( EMPLOYEE ) в процессе выполнения несколько раз может потребоваться доступ к базе данных. Если HIRE ( EMPLOYEE ) задана как функция, которая должна быть выполнена сервером базы данных внутренним образом, то между приложением и СУБД состоится только один цикл обмена сообщениями. С другой стороны, если функция запускается из программы пользователя, один цикл обмена сообщениями потребуется для каждого доступа. 64
Наконец, такие функции могут быть унаследованы и, возможно, переопределены в иерархии наследования. Другими словами, функция HIRE ( EMPLOYEE ) может быть автоматически применена к набору STUDENT - EMPLOYEE .
Если воспользоваться возможностью переопределения, функцию HIRE для набора STUDENT - EMPLOYEE можно переписать. Словом, использование инкапсулированных функций крайне желательно. Однако авторы манифеста приводят три замечания.
Во-первых, пользователям следует писать функции на языке программирования высокого уровня и получать доступ к базам данных при помощи непроцедурного языка доступа высокого уровня. Язык доступа может быть встроен в язык программирования средствами препроцессора или реализован как прямое расширение языка программирования. Прямой доступ к внутренностям системы должен стать допустимым, но крайне нежелательным способом написания функций.65
Второе замечание касается понятия непрозрачных типов. Некоторые энтузиасты идеи объектно-ориентированных баз данных утверждают, что должен быть только один способ, с помощью которого пользователь может получить доступ к набору – выполнение одной из функций, применимых к набору. Такое ограничение игнорирует потребности языка запросов, среде выполнения которого требуется непосредственный доступ к каждому элементу данных. Необходим механизм, делающий типы прозрачными, чтобы к элементам данных этих типов можно было получить доступ через язык запросов.
Последнее замечание касается коммерческого рынка. Все крупнейшие поставщики СУБД второго поколения уже поддерживают функции, написанные на языке программирования высокого уровня (обычно на поддерживаемом поставщиком 4GL ), которые могут производить обращения к СУБД в терминах SQL . Более того, эти функции могут быть использованы для инкапсуляции доступа к данным, которыми они управляют. Поставщикам коммерческих реляционных систем осталось поработать над поддержкой наследования функций.
Предложение 1.4: Уникальные идентификаторы (UID ) записей должны задаваться СУБД только в том случае, когда недоступен определенный пользователем первичный ключ.
В системах второго поколения поддерживается понятие первичного ключа – заданного пользователем уникального идентификатора.
Неизменный первичный ключ лучше присвоенного системой UID , потому что обозначает нечто естественное, понятное человеку. При обмене данными или отладке это может быть значительным преимуществом. Если для набора первичный ключ недоступен, появляется необходимость в присвоенном системой уникальном идентификаторе. Некоторые наборы данных не обязательно обладают системно заданными UID , так что построение систем с принудительной уникальной идентификацией, вероятнее всего, окажется нежелательным.
Предложение 1.5: Правила (триггеры, ограничения) станут одной из ключевых характеристик будущих систем.
Правила не следует ассоциировать с определенными функциями или наборами. Исследователи объектно-ориентированных баз данных обычно игнорировали необходимость правил. На вопрос о правилах энтузиасты ООБД отвечали либо молчанием, либо предложением внедрять их путем включения кода для их поддержки в одну или несколько функций, работающих с набором.
С точки зрения авторов манифеста, имеется только одно разумное решение: правила должны поддерживаться СУБД, но не быть привязаны ни к какой функции и ни к какому набору. Из этого положения следуют два факта. Во-первых, парадигма ООБД “все выражается методами” просто не применима к правилам. Во-вторых, нельзя предоставлять непосредственный доступ к внутренним интерфейсам СУБД ниже уровня активации правил (иначе пользователи смогут обходить систему, включающую правила в нужное время).
Ко времени написания Второго манифеста уже существовали продукты поставщиков систем второго поколения, отвечающие приведенному предложению. Тем самым, в вопросах, касающихся этого предложения, коммерческий реляционный рынок опередил уровень исследований ООБД.
