Перечень статей   Choose language


Вывод из базы данных
в формате Оконной Системы против
пространственных конструкторов и OpenGL

Сегодня для представления двумерных данных из базы данных на экране монитора пользователю приходится преодолевать дебри пространственных типов данных (объективно излишних, и как следствие вычурных), а потом ломать голову как запрограммировать OpenGL (или DirectX - кому как не повезет), чтобы отобразить полученное на экране. Очевидно подобные же затруднения пользователей ждут, когда ISO JTC1 SC32 WG3 породит следующие, вычурные типы данных для трехмерных конструкций.

Что нужно? Во всех языках программирования существует функция 'print' для вывода переменных программы на экран. В т.ч. текстовых переменных. Так пусть она сначала запросит этой текстовой строкой пространственные данные в базе данных, а полученное отобразит вместо самой текстовой строки.

Пользователю будет достаточно вызвать одну функцию, назовем ее 'printg', в которой указать какие 3D-объекты из базы данных должны возникнуть на экране. Эта функция, будучи вызванной первый раз, автоматически перенаправляет все мышиные команды перемещения объектов и движения камеры в СУБД, а все полученные от СУБД сообщения об обновлении координат объектов автоматически перенаправляет в Оконную Систему. Эту же функцию можно использовать, чтобы отправить приказ изменить координаты на языке запросов (изменение мгновенно отражается на экране). И эта функция может быть вызвана на любом языке программирования.

Это прорыв в офисных технологиях. Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны с расчетом на некие когнитивные способности, которыми, как показывают эксперименты, средний человек на самом деле не обладает. Tрудности, связанных с использованием 3D-объектов, возникает из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи. Предлагаю добавить функцию 'printg' в стандартные библиотеки ввода-вывода, дабы позволить пользователю наконец-то выполнить работу и сделать его более продуктивным, и как результат - более счастливым.

Детальное описание изложено на с.209-271 отдельного pdf-документа. 3D-конструкция представлена в нем как иерархия точек, треугольников, фигур (групп треугольников), групп фигур, групп групп, и т.д. Записи, содержащие эти объекты, должны быть связаны внешним ключем. Для того, чтобы извлечь все треугольники фигуры или группы, нужно оператором 'SELECT' выбрать не только запись, являющуюся данной фигурой или группой, но и все записи, расположенные ниже нее в иерархии - вплоть до тех, которые представляют 3D-точки. Для этого таблицы этих записей перечисляются через точку - 'select * from group3.group2.group1.triangle.point' - как это и принято в классических объектно-ориентированных языках [1]. Названия таблиц значения не имеют, т.к. всегда точки предполагаются расположенными на самом нижнем уровне иерархии каждой ветви дерева, треугольники - на один уровень выше, а записи остальных уровней не визуализируются [2]. Перед преобразованием в формат X11 (или в формат Microsoft Window System, если клиент базы данных работает в 'Microsoft Windows') невидимые треугольники будут удалены из результата запроса, а частично видимые будут обрезаны до их видимых частей. Итого любая программа отображает содержимое базы данных на экране функцией 'printg("select * from group3.group2.group1.triangle.point")'.

Аналогично в операторе 'UPDATE' также можно указать всю иерархию записей от фигуры или группы до 3D-точки - 'update group3.group2.group1.triangle.point set ...'. Итого любая программа изменяет положение объекта в базе данных и на экране функцией 'printg("update group3.group2.group1.triangle.point set ...")' [3].

Таким образом возможности OpenGL должны быть инкапсулированы внутрь СУБД.

Ведь давно известно из науковедения (science of science), что новая точка роста, скачек возникает при создании нового типа инструмента, а не следующего изделия старыми инструментами. Почитайте хотя бы классика Eugene Garfield.

[1] соответственно схема должна быть отделена от названия таблицы не точкой, а каким-то другим знаком, например '§': 'select * from user§group3.group2.group1.triangle.point'

[2] как отсекать ненужные ветви дерева, подробно рассказано на с.12-16, 21-22, 34-46, 53-55, 58-68 упомянутого pdf-документа

[3] процедуры сдвига, растяжения и вращения предлагаю поставлять не как хранимые в базе данных, а как встроенные в SQL, например сдвиг на 5 единиц по каждой координате выглядел бы как 'update group3.group2.group1.triangle.point shift (5,5,5)' - подробно о новых операторах 'update' и о триггерах для них рассказано на с.218, 232-233 pdf-документа. Эти же триггеры могут быть вызваны мышью, т.е. посылкой X11 данных (или данных Microsoft Window System), о чем рассказано на с.235

Литература:

P.Scarponcini. SQL Multimedia and Application Packages - Part 3: Spatial. Bentley Transportation, 2000-03-26. http://www.wiscorp.com/sqlspat.zip



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



Перечень статей   Choose language


Используются технологии uCoz