Skip site navigation (1) Skip section navigation (2)

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

From: Dmitry Turin <dmitry(dot)turin(at)belarusbank(dot)minsk(dot)by>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: (коррекция ссылки) Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009
Date: 2008-12-19 12:04:45
Message-ID: 169573787.20081219140445@belarusbank.minsk.by (view raw or flat)
Thread:
Lists: pgsql-ru-general
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00004.php
заменено на привильную ссылку
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php

---

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

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


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

Для решения 2-й проблемы, необходимо предоставить возможность инсталлировать 
СУБД и немедленно использовать ее так, как пользователь инсталлирует и 
использует программы "Teleport", "FlashGet", браузер и т.д. СУБД сама должна 
принимать XML и размещать данные, в нем содержащиеся, в таблицах в соответствии 
с некоторыми соглашениями. Мои предложения относительно этих соглашений:
  *) xml-элемент записывается в таблицу с тем же именем (т.е. имя тега совпадает с
  именем таблицы), xml-атрибут записывается в поле с тем же именем (т.е. имя 
  атрибута совпадает с именем поля). Первичный ключ новой записи заполняется 
  триггером 
  *) во время создания двух записей, соответствующих обрамляющему xml-элементу и
  непосредственно вложенному в него, первичный ключ одной записи копируется во 
  внешний ключ другой (предполагается, что одна таблица ссылается на другую 
  только одним внешним ключом, и что две таблицы не ссылаются друг на друга 
  одновременно [3])
  *) во время создания двух записей, соответствующих двум одноименным
  последовательно расположенным xml-элементам, также первичный ключ одной записи 
  копируется во внешний ключ другой (предполагается, что таблица ссылается на 
  саму себя только одним внешним ключом [4])

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

Что касается 3-й проблемы, то необходимо отметить, что SQL был бы более гибок и 
удобен для распределенных запросов (сбор данных из нескольких баз данных и 
рассовывание их в несколько баз данных), чем фирменные программы; в т.ч. более 
удобен для репликации, чем фирменные программы. Но нет необходимого синтаксиса:
  *) пусть каждая база данных получит 'прозвище'. Прозвище указывается в запросе
  перед именем таблицы через двоеточие 
  *) группу баз данных назовем 'обществом'. Общество также указывается перед именем
  таблицы через двоеточие, и означает прозвища всех баз данных, входящих в 
  группу [8]
  *) база данных по умолчанию - это та, в которой хранятся все прозвища и все
  общества

В целях безопасности распределенные запросы должны удовлетворять некоторым 
требованиям. Предлагаю концепцию полного недоверия одной базе данных другой:
  *) база данных не хранит логин другой базы данных (чтобы при взломе не отдать еще
  и чужой логин) 
  *) база данных не редактирует (изменяет, вставляет, удаляет) данные другой базы
  данных (чтобы временный доступ к одной базе данных, полученный при взломе, не 
  мог разрушить другую базу данных) 
  *) если это возможно, база данных не получает данных из другой базы данных (чтобы
  при взломе не стали доступны данные еще и из другой базы данных) 
И концепцию крайней простоты клиента: 
  *) клиент не знает SQL (не упрощает и не производит декомпозицию SQL)

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

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

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


[1] http://sql50.euro.ru/sql5.16.4.pdf
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php
[3] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую
несколькими внешними ключами, то эта неоднозначность разрешается в имени 
открывающего xml-тега: после собственно имени таблицы, содержащей нужный внешний 
ключ, ставится знак '#' и имя нужного ссылающегося поля (не имя constraint-а, 
т.е. внешнего ключа). Выглядит как новое имя открывающего тега с символом '#' в 
середине имени (с. 22-23). Такое указание имени ссылающегося поля будем называть 
это термином 'детерминация'
[4] Если таблица ссылается на саму себя несколькими внешними ключами, то эта
неоднозначность также разрешается в имени открывающего xml-тега: после 
собственно имени таблицы ставится знак '$' и имя нужного ссылающегося поля (не 
имя constraint-а, т.е. внешнего ключа). Это также выглядит как новое имя 
открывающего тега с символом '$' в середине имени (с. 24). Такое указание имени 
ссылающегося поля также будем называть это термином 'детерминация'. Детерминация 
должна быть указана в каждом из последовательно расположенных одноименных 
xml-элементов - в т.ч. и в первом (чтобы пользователю меньше думать). В двух 
разных видах детерминации использованы разные знаки - '#' и '$' - чтобы оба вида 
детерминации можно было использовать одновременно: 'tag#field1$field2'
[5] Кроме того, превращение всех реляционных полей не в xml-аттрибуты, а в
xml-элементы подходит для браузера, но не подходит для mash-up сервисов и 
всевозможных языков, основанных на XML
[6] Но ничего не стоит указать и реально не существующий, виртуальный внешний
ключ (vFK), как это показано на с. 118
[7] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую
несколькими внешними ключами, то эта неоднозначность разрешается в запросе 
дерева: после собственно имени таблицы, содержащей нужный внешний ключ, ставится 
знак '#' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего 
ключа). Выглядит как новое имя таблицы с символом '#' в середине имени (с. 
36-37). Такое указание имени ссылающегося поля будем называть термином 
'рафинирование'. Аналогично, если таблица содержит список и ссылается на саму 
себя несколькими внешними ключами, то эта неоднозначность также разрешается в 
запросе дерева: после собственно имени таблицы ставится знак '$' и имя нужного 
ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Это также выглядит 
как новое имя таблицы с символом '$' в середине имени (с. 38). Такое указание 
имени ссылающегося поля также будем называть это термином 'рафинирование'. В 
двух разных видах рафинирования использованы разные знаки - '#' и '$' - чтобы 
оба вида рафинирования можно было использовать одновременно: 
'table#field1$field2'
[8] Таким образом одно sql-выражение с обществом означает множество
sql-выражений с прозвищами. Кроме того, чтобы прозвища (с. 49), несколько 
обществ или несколько упоминаний одного общества (с. 50) никогда не указали на 
одну и ту же базу данных одновременно, поместим перед ними символ '%'; а чтобы 
несколько упоминаний одного общества наоборот всегда синхронно указыли на одну и 
ту же базу данных, поместим любое слово (одинаковое) и символ '%' перед этими 
упоминаниями (с. 53-54)
[9] Предлагаю оформлять эти специальные команды в xml-виде как <?command/?>,
чтобы различать их и от sql-команд, и от xml-данных (традиционно оформляемых как 
<element/>). Кроме того, предлагаю оператор 'POSTPONE' для заморозки на второй 
стадии 2- и 3-стадийных 'COMMIT' (2PC и 3PC), и оператор 'ADJOURN' заморозки на 
третей стадии 3-стадийных 'COMMIT' (3PC) (с. 60)


Тюрин Дмитрий




pgsql-ru-general by date

Next:From: Dmitry TurinDate: 2008-12-20 10:33:12
Subject: Re[2]: [pgsql-ru-general] Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009
Previous:From: Dmitry TurinDate: 2008-12-19 11:24:44
Subject: Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group