POTT порождает дополнительную сложность
Очевидно, что POTT действительно приводит к дополнительной сложности -- под "сложностью" я прежде всего понимаю сложность для пользователя, хотя порождаются большие сложности и для системы. Например, реляционная модель поддерживает только один "генератор типа коллекции" -- RELATION -- совместно с набором операций -- соединение, проекция и т.д. -- которые применимы ко всем "коллекциям" этого типа (другими словами, ко всем отношениям). В отличие от этого, в соответствии с предложениями ODMG поддерживаются четыре генератора типа коллекции - SET, BAG, LIST и ARRAY, для каждого из которых имеется набор операций, применимых ко всем коллекциям данного типа. И я утверждаю, что операции ODMG одновременно сложнее реляционных и обладают меньшей можностью. Вот, например, операции ODMG для списков:
IS_EMPTY IS_ORDERED ALLOWS_DUPLICATES CONTAINS_ELEMENT INSERT_ELEMENT REMOTE_ELEMENT CREATE_ITERATOR CREATE_BIDIRECTIONAL_ITERATOR REMOTE_ELEMENT_AT RETRIEVE_ELEMENT_AT REPLACE_ELEMENT_AT INSERT_ELEMENT_AFTER INSERT_ELEMENT_BEFORE INSERT_ELEMENT_FIRST INSERT_ELEMENT_LAST REMOVE_FIRST_ELEMENT REMOTE_LAST_ELEMENT RETRIEVE_FIRST_ELEMENT RETRIEVE_LAST_ELEMENT CONCAT APPEND
Между прочим, стоит заметить мимоходом, что ODMG не поддерживает генератор типа RELATION. Авторы The Object Database Standard: ODMG 2.0 утверждают, что "модель данных ODMG включает реляционную модель данных за счет наличия типа TABLE", но тип TABLE строго недостаточен во многих отношениях; в частности, отсутствуют многие из критических реляционных операций -- например, соединение. В связи с тем утверждением, что модель ODMG "включает реляционную модель" или "является более мощной", имеется много дополнительных проблем, но ограничения размера этой заметки не позволяют рассмотреть их здесь.
Далее, ODMG поддерживает язык запросов OQL - язык только для выборки (операции обновления отсутствуют), который в свободном стиле срисован с SQL. Более конкретно, OQL:
В The Object Dtabase Standard: ODMG 2.0 содержится ряд утверждений про OQL. Вот пара из них (в обоих случаях курсив добавлен К. Дейтом):
С моей точки зрения, наоборот, OQL очень хорошо иллюстрирует то, что POTT приводит к дополнительной сложности! То есть я утверждаю, что OQL более сложен, а не более мощен (как кажется, люди из мира компьютеров часто путают эти два понятия). И дополнительная сложность порождается тем фактом, что пользователю демонстрируется так много разных структур данных. Мне кажется, что это положение дел является прямым следствием непризнания преимуществ строго разделения модели и реализации.
Исследуем этот вопрос возрастающей сложности немного более пристально. Прежде всего заметим , что когда мы говорим о списках в базе данных, о массивах в базе данных и т.д., мы на самом деле говорим о переменных списков, переменных массивов и т.д. -- равно как, когда мы говорим об отношениях в базе данных, мы на самом деле имеем в виду переменные отношений (relvar). Конечно, в реляционной модели мы находим только один вид переменных - переменные отношений (т.е. переменные, значениями которых являются отношения); реляционная модель не имеет дела с переменными списков или массивов. Поэтому введение, например, переменных списков представляет собой существенный отход от классической реляционной модели.
Почему же этот отход настолько важен? Ортогональность требует, чтобы мы определили целый новый язык запросов для списков -- т.е. набор операций ("алгебру списков?", аналогичный алгебре операций, уже определенных для отношений (реляционной алгебре). Конечно, в связи с этим языком мы также должны побеспокоиться о замкнутости. И мы должны определить набор операций обновления списков, аналогичный существующему реляционному набору. Мы должны быть в состоянии определять для списков ограничения целостности и безопасности и представления списков.
Каталог должен описывать переменные списков наряду с переменными отношений. (А что будет собой представлять сам каталог? Переменные списков? Переменные отношений? Смесь того и другого?) Нам нужна теория проектирования списков, аналогичная существующей реляционной теории проектирования. Нам также потребуются руководства относительно того, когда следует использовать переменные списков, а когда переменные отношений. И так далее, поскольку я уверен, что этот перечень не является исчерпывающим.
Предполагая, что такую "алгебру списков" можно определить, и на все вопросы предыдущего параграфа можно удовлетворительно ответить, теперь мы могли бы иметь два способа выполнения действий там, где ранее было достаточно одного. Другими словами, как уже отмечалось, добавление нового вида переменной определенно увеличивает сложность, но не повышает мощность; нет ничего такого (по крайней мере, полезного), что можно было бы сделать с использованием смеси переменных списков и отношений и что нельзя было бы сделать с использованием только переменных отношений. Таким образом, интерфейс пользователя теперь будет более сложным и будет предоставлять больше возможностей выбора, большей частью без хороших руководств относительно того, как делать этот выбор.
В качестве прямого следствия всего этого приложения баз данных -- включая приложения общего назначения и "frond ends" -- станет труднее писать и поддерживать. Эти приложения станут также более уязвимыми к изменениям в структуре базы данных; будет утрачена некоторая часть независимости данных. Подумайте, что произойдет, например, если представление некоторой части информации изменится из переменной отношения на переменную списка или на что-то еще.
Все эти проблемы прямо конфликтуют с Принципом Информации Кодда. Я уверен, что Кодд не случайно назвал его "фундаментальным принципом реляционной модели". Этот принцип можно сформулировать следующим образом: "Вся информация в базе данных должна быть явно представлена в терминах отношений и никак иначе".
В своей книге The Relational Model for Database Management Version 2 (Addison-Wesley, 1997) Кодд приводит ряд аргументов в пользу поддержки этого принципа (аргументов, с которыми я, конечно, согласен). Как мы утверждаем в Третьем Манифесте, отношения являются необходимыми и достаточными для представления любых данных (на логическом уровне). Другими словами, мы должны иметь отношения и нам не требуется ничего, кроме отношений.
Так откуда же возникла идея POTT? Мне кажется, здесь мы имеем (как это часто случается) фундаментальную путаницу в понятиях модели и реализации. Более точно, было замечено, что некоторые SQL-продукты не слишком хорошо выполняют некоторые операции (в особенности соединения); на основе этого было сделано предположение, что эффективность была бы улучшена, если бы мы могли использовать, скажем, списки или массивы вместо отношений. Но в этой идее содержится серьезна путаница; в ней смешиваются логический и физический уровни. Никто не утвержает, что, например, списки не могли бы быть полезны на физическом уровне; вопрос в том, должны ли списки и тому подобное демонстрироваться на логическом уровне. И очень строгой позицией защитников реляционного подхода и, частности, авторов Третьего Манифеста является то, что ответом на этот вопрос является "нет".
