ibnteo писал(а):
Уже существует представление SELECT запросов SQL на ДРАКОН-схемах?
...
Получается вот так:
...
ключевых слов будет довольно таки мало, сейчас это лишь те, что задают структуру программы, где вставляем отступы, оборачиваем в блоки, где хотим визуально выделить структуру, плюс возможность скрывать исходный код под комментарии
Скорее всего, для SQL на схемах не убрать текстовые ключевые слова вовсе, даже для where c having (см. ниже). Иначе придётся изобретать неимоверное количество иероглифов (в т.ч. и комплексных -- ака значок "создать" плюс "свисающий" от него "database" и т.п.), что, прежде всего, чуждо для репертуара моделирующих. И с помощью графа для SQL вряд ли получится выразить "реляционные" операторы в каком-либо удобоваримом виде (для чего, собственно то, исходный язык предназначен).
Когда-то, во времена моды на "объектные СУБД", был такой проект SBQL (мало кому известный) -- Stack Based Query Language -- язык запросов к структурам данных, альтернатива SQL, LINQ, OQL, Prolog/Datalog и прочим всяким XQuery и т.д. Краткое введение (родного спецсайта уже нет):
Stack-Based Architecture and Stack-Based Query LanguageИнтуитивно понятный, с проработанной упрощённой семантикой (были даже какие-то академические поделки в виде "наколенного LINQ" для Python, Java). Но в основе модель данных -- "объектная иерархическая" (в т.ч. с возможностью "наследования" или "множества ролей" для объекта). Если необходимо, для перевода в плоскую табличную форму требуется соответствующая адаптация. Я пользуюсь лишь "мотивами" этого языка (иногда как псевдокод для некоторых постановок задачек над виртуальными моделями данных), и в схемы его не "затаскивал". Но, вроде бы, тамошние ключевые "реляционные" операторы (так называемые "не алгебраические") над наборами данных, очень таки неплохо "ложатся" на те же Р-схемы. Последние, как упорядоченный граф переходов, по сути были трансформированы в универсальные "графические структуры" с последовательным (разной направленности), параллельным, вложенным соединением (с возможной дополнительной разметкой вершин), требующие предметной интерпретации.
Например, ниже выборка на SBQL в виде текст/схема и аналог на SQL (где знак "#" является обычным символом, применимым для идентификаторов -- "номер", "ID"):
Вложение:
sbql1.png [ 40.05 КБ | Просмотров: 4556 ]
Вложение:
r_sbql1.png [ 4.11 КБ | Просмотров: 4556 ]
На схеме над дугой указывается "проекция", под дугой -- "предикат". Смежные по вертикали дуги одной направленности -- оператор "соединение" ("join", в языке только один вид соединения). Присоединение структуры справа -- "навигация" ("точка"). В языке нет потребности в декларациях вида "group by", "having". Операции ака классическое "объединение" ("union") в чистом виде нет, предполагается при потребности следование запросов комплементарной структуры (последовательность схем). В принципе то, можно и явный оператор ввести, на схеме -- параллельное соединение структур (по вертикали, где каждая структура со своими вершинами). В языке имеются специализированные "объединения" для рекурсивных запросов: операторы "close by" и "leaves by" для "полного" замыкания и выборка только структур-"листьев" (не имеющих "дочерних" связей). На схеме: присоединение справа циклической структуры как "петля" (двойная дуга) для "полного" замыкания, циклическая структура с обратной дугой -- для "листьев". Для всех "замыканий" имеются вариации как "unique", но эта декларация может быть указана как "distinct" в "проекции" (над дугой). Запросы могут быть представлены в виде системы уравнений в стиле Prolog/Datalog (с иной семантикой, в исходном языке в рамках уравнений есть непосредственно оператор "union" как аналог "leaves unique by") вместо громоздких вложенных конструктов, на схемах -- возникает их совокупность (связи -- по именам переменных, схемы частично можно упорядочить, как и составляющие уравнений).
Пример рекурсивного запроса -- текст и схема (в двух вариантах) на SBQL, и два варианта аналога на SQL -- в диалекте Oracle и как common table expression:
Вложение:
sbql2.png [ 75.65 КБ | Просмотров: 4556 ]
Вложение:
r_sbql2.png [ 6.58 КБ | Просмотров: 4556 ]
В общем, выше всего лишь примеры, как "реляционные" операторы (фактически, все в текстовом языке) представимы в виде графа, хоть с какой-то помощью для "симультанного восприятия".
Но не в случае SQL. В примере выше такие выражения как "start with" и пр. требуют отличения от "where" и т.д. Некая обвертка в виде геометрических фигур, в нагрузке которых, фактически, не изъять текстовые ключевые слова, представимая лишь как некая "mindmap" (вся суть графа в данном случае) -- "визуальный шум". Скорее, нечто вроде
"Code Bubbles" может оказаться полезнее -- продвинутый текстовый редактор с пониманием семантических связей, если таковой сможет делать более удобное расположение отформатированных "кусков" текста, к примеру, расположить список столбцов по колонкам в соответствие с источниками, вспомогательными линии указать какие-то связи и т.п.