Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009

В эпоху, когда компьютер стоит на каждом рабочем месте, любой средний человек находится на передовой - он должен самостоятельно принять, отправить, обработать данные. Удобно накопить их в базе данных, но ни один обычный человек не может:

• выводить 3-мерные конструкции из базы данных на экран (конвертировать в формат и протокол X11)
• предоставлять ввод из браузера (настроить проприетарный веб-сервер конкретной СУБД)
• копировать информацию из удаленной базы данных (использовать другие источники информации для создания собственного mash-up сервиса)
• несколько раз включить и выключить ноутбук в течение одной длинной транзакции, длящейся дни или даже недели

Автор предлагает решения этих проблем, и заинтересован в мнении, комментариях и возможной реализации этих предложений. Детали изложены в pdf-документе (далее будем ссылаться на страницы этого документа). Все проблемы, кроме 2-й, могут быть решены с использованием проприетарных форматов передачи данных, и сформулированы как передача XML только для унификации с 2-й проблемой.

Решение 1-й проблемы - интерфейс 'модель - оконная система' - описан в предыдущей публикации. Чтобы приказать СУБД сменить формат данных с XML на Х11 и убрать невидимые поверхности, в операторе 'SELECT' используется постфикс 'PROJECTING'. В частном случае 2-мерных данных, объекты должны быть записаны с помощью схемы данных (что понятно пользователям), а не в вычурных (и излишних) типах данных, которые пользователь не осваивает. Единственное отличие от предыдущей публикации состоит в том, что в целях унификации с XML автор предлагает отправить Х11 данные до клиента в XML-обертке.

Для решения 2-й проблемы, необходимо предоставить возможность инсталлировать СУБД и немедленно использовать ее так, как пользователь инсталлирует и использует программы "Teleport", "FlashGet", браузер и т.д. СУБД сама должна принимать XML и размещать данные, в нем содержащиеся, в таблицах в соответствии с некоторыми соглашениями. Мои предложения относительно этих соглашений:

• xml-элемент записывается в таблицу с тем же именем (т.е. имя тега совпадает с именем таблицы), xml-атрибут записывается в поле с тем же именем (т.е. имя атрибута совпадает с именем поля). Первичный ключ новой записи заполняется триггером
• во время создания двух записей, соответствующих обрамляющему xml-элементу и непосредственно вложенному в него, первичный ключ одной записи копируется во внешний ключ другой (предполагается, что одна таблица ссылается на другую только одним внешним ключом, и что две таблицы не ссылаются друг на друга одновременно [1])
• во время создания двух записей, соответствующих двум одноименным последовательно расположенным xml-элементам, также первичный ключ одной записи копируется во внешний ключ другой (предполагается, что таблица ссылается на саму себя только одним внешним ключом [2])

Нельзя обойти вниманием и обратную проблему - проблему вывода записей в виде xml-элементов. Использование как SQL/XML-функций, так и синтаксиса проприетарного веб-сервера [3] дают очень громоздкий код, в котором пользователь запутывается. В то же время обычно извлекаются записи, уже связанные внешним ключом. Таким образом мы имеем дерево, уже сформированное в схеме базы данных. Предлагаю лаконичное 'select a.b.c' для выбора данных из таблиц 'a', 'b', 'c', уже связанных внешними ключами [4]. Будем называть это термином 'XTree' - по аналогии с 'XPath' (предполагается, что таблицы ссылаются друг на друга только одним внешним ключом, и что две таблицы не ссылаются друг на друга одновременно [5]).

Что касается 3-й проблемы, то необходимо отметить, что SQL был бы более гибок и удобен для распределенных запросов (сбор данных из нескольких баз данных и рассовывание их в несколько баз данных), чем фирменные программы; в т.ч. более удобен для репликации, чем фирменные программы. Но нет необходимого синтаксиса:

• пусть каждая база данных получит 'прозвище'. Прозвище указывается в запросе перед именем таблицы через двоеточие
• группу баз данных назовем 'обществом'. Общество также указывается перед именем таблицы через двоеточие, и означает прозвища всех баз данных, входящих в группу [6]
• база данных по умолчанию - это та, в которой хранятся все прозвища и все общества

В целях безопасности распределенные запросы должны удовлетворять некоторым требованиям. Предлагаю концепцию полного недоверия одной базы данных другой:

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

• клиент не знает SQL (не упрощает и не производит декомпозицию SQL)

Таким образом одна база данных не может породить и ввести sql-команду в другую базу данных ни прямо, ни косвенно (прося клиента перенаправить команду). А клиент не может сконструировать новую sql-команду на основе разбора (parse) введенной.

Первая база данных отправляет клиенту специальную команду, которая заставляют клиента сделать подстановку в последней отправленной первой базе данных sql-команде, запомненной в стеке клиента, и выслать результат преобразования второй базе данных. Специальные команды должны быть настолько ограниченными, чтобы не допускать порождения sql-команды, вредной для второй базы данных [7].

Для решения 4-й проблемы, достаточно ввести оператор 'FREEZE' (подобный 'DISCONNECT'), который сохраняет транзакцию в текущем состоянии; и оператор 'UNFREEZE' (подобный 'CONNECT'), который продолжает транзакцию с замороженного состояния (а не начинает новую, как 'CONNECT'). 'FREEZE' возвращает идентификатор замороженной транзакции, который должен быть указан в 'UNFREEZE'.

[1] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую несколькими внешними ключами, то эта неоднозначность разрешается в имени открывающего xml-тега: после собственно имени таблицы, содержащей нужный внешний ключ, ставится знак '#' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Выглядит как новое имя открывающего тега с символом '#' в середине имени (с.83-85). Такое указание имени ссылающегося поля будем называть это термином 'детерминация'

[2] Если таблица ссылается на саму себя несколькими внешними ключами, то эта неоднозначность также разрешается в имени открывающего xml-тега: после собственно имени таблицы ставится знак '$' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Это также выглядит как новое имя открывающего тега с символом '$' в середине имени (с.86-87). Такое указание имени ссылающегося поля также будем называть это термином 'детерминация'. Детерминация должна быть указана в каждом из последовательно расположенных одноименных xml-элементов - в т.ч. и в первом (чтобы пользователю меньше думать). В двух разных видах детерминации использованы разные знаки - '#' и '$' - чтобы оба вида детерминации можно было использовать одновременно: 'tag#field1$field2'

[3] Кроме того, превращение всех реляционных полей не в xml-аттрибуты, а в xml-элементы подходит для браузера, но не подходит для mash-up сервисов и всевозможных языков, основанных на XML

[4] Но ничего не стоит соединить два дерева (BTT), как это показано на с.25

[5] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую несколькими внешними ключами, то эта неоднозначность разрешается в запросе дерева: после собственно имени таблицы, содержащей нужный внешний ключ, ставится знак '#' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Выглядит как новое имя таблицы с символом '#' в середине имени (с.12-14). Такое указание имени ссылающегося поля будем называть термином 'рафинирование'. Аналогично, если таблица содержит список и ссылается на саму себя несколькими внешними ключами, то эта неоднозначность также разрешается в запросе дерева: после собственно имени таблицы ставится знак '$' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Это также выглядит как новое имя таблицы с символом '$' в середине имени (с.15-16). Такое указание имени ссылающегося поля также будем называть это термином 'рафинирование'. В двух разных видах рафинирования использованы разные знаки - '#' и '$' - чтобы оба вида рафинирования можно было использовать одновременно: 'table#field1$field2'

[6] Таким образом одно sql-выражение с обществом означает множество sql-выражений с прозвищами. Кроме того, чтобы прозвища (с.123), несколько обществ или несколько упоминаний одного общества (с.125) никогда не указали на одну и ту же базу данных одновременно, поместим перед ними символ '%'; а чтобы несколько упоминаний одного общества наоборот всегда синхронно указыли на одну и ту же базу данных, поместим любое слово (одинаковое) и символ '%' перед этими упоминаниями (с.128-130)

[7] Предлагаю оформлять эти специальные команды в xml-виде как <?command/?> (с.135, 151, 173), чтобы различать их и от sql-команд, и от xml-данных (традиционно оформляемых как <element/>). Кроме того, предлагаю оператор 'POSTPONE' для заморозки на второй стадии 2- и 3-стадийных 'COMMIT' (2PC и 3PC), и оператор 'ADJOURN' заморозки на третей стадии 3-стадийных 'COMMIT' (3PC) (с.180-181)

1. P.Scarponcini. SQL Multimedia and Application Packages - Part 3: Spatial. Bentley Transportation, 2000-03-26. http://www.wiscorp.com/sqlspat.zip
2. SQL Standard - SQL/XML Functionality. ISO/IEC JTC1/SC32 #1293, 2005-04-22. http://jtc1sc32.org/doc/N1251-1300/32N1293-WG3-Presentation-for-SC32-20050418.pdf
3. K.Kulkarni. Overview of SQL:2003. p.65, part 14 "SQL/XML", Silicon Valley Laboratory, IBM Corporation, San Jose, 2003-11-06. http://www.wiscorp.com/SQL2003Features.pdf
4. Folksonomy. //Wikipedia. http://en.wikipedia.org/wiki/Folksonomy
5. Mash-up, syndication. //Wikipedia. http://en.wikipedia.org/wiki/Web_2.0
6. N.Mattos, H.Darwen, P.Cotton, P.Pistor, K.Kulkarni, S.Dessloch, K.Zeidenstein. SQL99, SQL/MM, and SQLJ: An Overview of the SQL standards. http://www.wiscorp.com/sql1999_c3.zip
7. How to add style to XML. //W3C papers. http://www.w3.org/Style/styling-XML
8. CSS vs. XSL. //W3C papers. http://www.w3.org/Style/CSS-vs-XSL
9. XML Path Language (XPath). Version 1.0. //W3C Recommendation, 16 November 1999. http://www.w3.org/TR/xpath
10. XML submission. //Web Forms 2.0, Working Draft, 12 October 2006. http://www.whatwg.org/specs/web-forms/current-work/#x-www-form-xml

Тюрин Дмитрий, dmitryturin@yandex.ru