(Продолжение. Начало в №25)

Отображение пространственных конструкций

Сначала где их хранить. В 3DMLW, 3DXML, COLLADA? Заведомо известно, что наши биолог, физик, библиотекарь не разберутся в этих форматах, не напишут конвертеры своих данных в них, не инициируют событие в программах-визуализаторах для обновления экрана. Может быть, в современных СУБД? Практика показывает, не подключат они драйверы. Кроме того, сложно задействовать данные, поставляемые корпорациями в вычурных типах от ISO JTC1 SC32 WG3 - сводку 2D-типов вы можете видеть в P.Scarponcini "SQL Multimedia and Application Packages - Part 3: Spatial. Bentley Transportation" по адресу wiscorp.com/sqlspat.zip, скоро подоспеют 3D-типы. Всё это настолько неподъемно, что нужно отдельное высшее образование только для staging-а, т.е. для ETL. Кто-то на этом искусственном барьере вытаскивает из нас деньги.

Затем нужно визуализировать данные. Не запрограммируют прикладные специалисты OpenGL. Это уже результат сговора других ТНК. И если кто-то соберётся отъедать у них часть рынка, то его DirectX не будет проще. Ибо если где-то образуется простота, через нее утекут все деньги.

Итого два барьера, на которых долго, дорого плюс дублирование информации на компьютере.

Не сомневаемся, что вычурные типы даже не пришли вам в голову, и вы поступили самым естественным образом: представили 3D-конструкцию как иерархию точек, треугольников, фигур (групп треугольников), групп фигур, групп групп, и т.д. И записи, содержащие эти объекты, связали внешними ключами. Что теперь нужно? Во-первых, не копировать поштучно точки и треугольники в OpenGL, вызывая её процедуры, а указать предикат, которому записи подчиняются, - например, узел дерева, дистальнее которого концы ветвей содержат точки, и маршрут к ним с помощью "SELECT * FROM GroupsTable.FiguresTable.TrianglesTable.PointsTable" Во-вторых, не обновлять собственноручно координаты в хранилище, подслушивая мышиные drag-and-drop, и уж тем более не редактировать самому координаты в OpenGL после каждого изменения в хранилище. Всё это гуманная библиотека сделает самостоятельно. Назовем ее машиной проекций. А участок экрана, порожденный её 'print', - пространственным полем. Итого любая программа отображает содержимое хранилища на экране функцией 'print("SELECT * FROM GroupsTable.* ")'.

Это прорыв в офисных технологиях. Tрудности, связанные с использованием пространственных объектов, возникали из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи. Дадим пользователю машину проекций на всех языках программирования, дабы позволить ему наконец-то выполнить работу и сделать его более продуктивным, и как результат - более счастливым.

Чтобы названия таблиц не имели значения и чтобы допустить ветви дерева ниже 3D-точек (возможно, нам понадобится прикрепить к последним что-нибудь глубокомысленное), пометим колонки, содержащие координаты, служебным словом "DOT", которое по аналогии с типом данных назовем визуальным типом. Треугольники (или четырехугольники) предполагаются расположенными на один уровень выше в каждой ветви дерева, а записи остальных уровней не визуализируются. Как отсекать ненужные ветви дерева, см. sql50.euro.ru/sql5.19.2.pdf с.12-16, 21-22, 34-46, 53-55, 58-68. В связи с использованием точки для указания маршрута по дереву, схема должна быть отделена от названий таблиц не точкой, а каким-то другим знаком, например "§": "SELECT * FROM user§GroupsTable.*"

Аналогично в операторе UPDATE также можно указать всю иерархию записей от фигуры или группы до 3D-точки с помощью "UPDATE GroupsTable.FiguresTable.TrianglesTable.PointsTable SET ...", чтобы обновить не все записи в хранилище, а только входящие именно в такие деревья. Т.е. любая программа изменяет положение объекта в хранилище и на экране функцией 'print("UPDATE GroupsTable.* SET ...")'. Сдвиг, растяжение и вращение органичнее поставлять не как хранимые процедуры, а как встроенные в SQL, например, сдвиг на 5 единиц по каждой координате выглядел бы как "UPDATE GroupsTable.* SHIFT (5,5,5)". SHIFT, SPRAIN, ROTATION действуют только на колонки, отмеченные визуальным типом DOT. На них может быть установлен триггер типа "CREATE TRIGGER ... AFTER SHIFT".

Но заранее спланированное движение должно задаваться не обновлением записей по таймеру в процедуре пользователя, писать и поддерживать которую крайне тяжело для него, а путем указания времени актуальности записей. Сегодняшний синтаксис такой актуальности переусложнен. Избавимся от лишнего слова VALID и будем вместо VALID PERIOD писать просто PERIOD. Сейчас с периодом актуальности оперируют не как с полем структуры, что неудобно для извлечения записей за произвольный отрезок времени - особенно если этот отрезок задан не константами, а под-запросом. Кроме того, использование для сравнения таких периодов не операций над массивами, а ключевых слов UNION, INTERSECT, EXCEPT, уже задействованных для обработки целых записей, вызывает когнитивный диссонанс. Поэтому будем указывать время актуальности в самом настоящем поле, для чего пометим в структуре один из двухэлементных массивов типа DATATIME визуальным типом PERIOD как на с.220-221 упомянутого pdf-документа.

Интересно, сможет ли хоть DARPA побороть американские концерны с её "mission to prevent technological surprise for the United States and to create technological surprise for its adversaries". Помочь американским ученым, самостоятельно разрабатывающим некачественное ПО, мучающимся от низкой реальной продуктивности программирования. Или даже на HPCS они будут визуализировать по старинке.

Проблематика

Подход "print-SELECT командует не только хранилищем, но и оконным сервером, плюс работа пользователя клавиатурой и мышью вместо последующих запросов", должен быть применен и к визуализации строковых и числовых данных. Пока что додумались только до того, что после редактирования записей в плоской таблице изменения автоматически фиксируются в базе данных, а при отображении двух таблиц в подчиненной демонстрируются только записи, ссылающиеся на текущую запись главной. Это реализовано во всевозможных RAD-системах (вместо печатания print-SELECT применяется drag-and-drop иконок). Но не реализованы остальные динамические связки оконного сервера и хранилища, ручное написание которых и есть суть создания интерфейса над новыми структурами данных и алгоритмами обработки. Эти связки перечислим в следующем разделе, а машину, их выполняющую, назовем машиной демонстраций (будем использовать одну и ту же функцию 'print' для всех машин, а предназначение машине проекций выделять служебным словом PROJECTING в конце запроса "SELECT ... FROM ... PROJECTING"). Машина демонстраций запрашивает данные не только у винчестера, но и у машины 'join', когда ее парсер обнаруживает join-овский SQL. Таким образом все машины должны использовать общий механизм контроля доступа/транзакций.

И уж хотя бы это должно дать понять, что права доступа к записям должны не реализовываться пользователем каждый раз заново вручную, а поставляться самим хранилищем, например, так: создавать-удалять некие департаменты командами "CREATE DEPARTMENT dp" и "DROP DEPARTMENT dp", делегировать-удалять полномочия на них командами "BESTOW select ON dp FOR username" и "VANISH update ON dp FOR rolename", а имя департамента указывать в самих записях в поле специального типа "CREATE TABLE a (..., a5 DEPARTMENT, ...)", "INSERT INTO a VALUES (..., dp, ...)". Отсутствие полномочия SELECT означает невидимость записи, полномочия UPDATE - невозможность ее редактировать, полномочия DELETE - невозможность удалить, полномочия INSERT - невозможность вставить запись, маркированную данным департаментом. Само специальное поле доступно для изменения только тем, у кого есть полномочие DIRECTOR на значение, содержащееся в поле, "BESTOW director ON dp FOR rolename". Мы преднамеренно выбрали существительное (director) для обозначения этого полномочия, а не глагол, подобный 'select, update, delete, insert', чтобы выделить его особую роль в голове пользователя.

Если механизм контроля доступа/транзакций реализован в ОС, однотипные машины разных производителей взаимозаменяемы, конкуренция между ними велика. Если он находится в линейке машин 'join', то их производители организуют второй (после операционных систем) рубеж "Vendor lock-in". Могут отказывать производителям других машин, чтобы реализовывать машины самим. И торговать ими в нагрузку (распухание СУБД). Или запретить работу лицензированного под них продукта с 'join' конкурента. А если и будет работать продукт с несколькими машинами 'join', для общения с каждой нужен перекодировщик, падает производительность из-за драйверов. Помимо контроля доступа/транзакций, в общем механизме ОС должен быть реализован вызов триггеров.

Строковые и числовые данные - как и пространственные - должны храниться не в СУБД, а на жестком диске, расформатированным под третью парадигму; ведь машина 'join' - очень частный случай, предназначенный для изучения статистики, не более чем один из сервисов ОС, такой же, как и машины проекций и демонстраций. На месте удаленной структуры может быть создана новая, но ссылка на удалённую не должна указывать на новую. Для этого в таблицах необходима системная колонка, в которую записывается следующее значение для каждой новой записи. Такое значение может браться из счетчика для всей таблицы, что экономит разрядность этой колонки, но требует для неё хэша; либо просто инкрементироваться при удалении записи, тогда внешние ключи должны содержать два числа - физический адрес записи и значение в колонке. Значение внешнего ключа в первом случае называется первичным ключом, значение во втором случае по аналогии будем называть физическим ключом. Почти все приложения не изучают статистику, поэтому хранилище резонно построить на основе физического ключа, а не первичного. Это даст выигрыш в скорости.

Для оконного сервера и для машин нужен единый формат данных, разумеется, бинарный. Подобно тому, как реализация третьей парадигмы с физическими ключами поверх FAT и СУБД с её первичными ключами и хэшами превращает хранилище в монстра, жрущего ресурсы, так и проектирование оконного сервера без учета того, в каком формате машины передают друг другу, нагружает оконный сервер еще одним перекодировщиком и превращает в медленно едущую телегу. Среди прочего формат должен кодировать специальные значения ACCEPTING и NOTGOT, необходимые для уведомления о том, что особо крупный объект все еще находится в процессе получения - по мотивам статьи "Почему BLOB-поле - недополе, и как его сделать полем" ("КВ" №7'2009, от описываемой там "времянки" типа HTML следует вообще отказаться; вместо идентификатора, уникального для всех BLOB-полей базы данных, для вставки в текст картинки лучше использовать SELECT, обрамленный с двух сторон непечатными символами - подробнее об этом в конце следующего раздела).

Кроме того, ОС запоминает за клиента отправленные им команды в своем стеке; принимая для него уведомления, делает подстановки в запомненном и спрашивает у пользователя пароли к другим хранилищам, чтобы отправить измененные команды (таким образом большую часть масштабируемого доступа осуществляет совсем не клиент). Операционные системы хранилищ откатывают и накатывают транзакции по методу временных меток, чтобы разрешить deadlock-и; и обмениваются для этого специальными декларациями - мы не изображали их на слайдах, но зарезервируем для них обозначение <<declaration/>>. И формат должен также их кодировать. Обмен происходит через ОС клиента, чтобы та могла информировать пользователя как происходит этот процесс, в т.ч. об истечении собственного таймаута и о стороннем запросе его продлить. Ну и протокол для формата уже изложен в публикации "Унификация протоколов в единый" ("КВ" №17).

А программа при последовательном проектировании ОС должна взаимодействовать не с оконным сервером, а непосредственно с нужными ей машинами. Кроме того, мы последовательно в духе Дейкстры проводим политику на избавление пользователя от выписывания в его алгоритме особенностей компьютера, поэтому программа должна не запускаться и терминироваться, а только существовать (этакий супер-триггер, в который вложены триггеры, составляющие программу) или быть уже удаленной, и передача ей данных - это внесение и изменение записей в её же схеме. Деление программ на демонов и не демонов отсутствует. Не существуют stdin и stdout - только копирование записей или обновление полей.

Ну и, наконец, хоть это и выходит за рамки настоящей работы, SELECT или его аналог в органично созданных языках программирования должен непосредственно входить в число оператов языка, а не вкладываться в другой оператор "печатать". И раз уж мы подняли вопрос на принципиальную высоту, по умолчанию операторы должны выполняться параллельно, а не последовательно, т.к. второе порождает искусственную задачу распараллеливания. Впрочем, в другой статье мы еще поговорим о морфологическом ящике для методологий моделирования и, как следствие, для языков программирования, а пока вернемся к ОС и сосредоточимся на динамических связках оконного сервера и хранилища, реализуемых машиной демонстраций для визуализации строковых и числовых данных.

(Продолжение следует)

Дмитрий ТЮРИН,
dmitryturin.narod.ru