КОНСТРУКТОР SQL-ЗАПРОСОВ
ДЛЯ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ ЧЕРЕЗ WEB-ИНТЕРФЕЙС
Одной из наиболее привлекательных возможностей web-технологий является использование web-интерфейса для доступа к базам данных – это позволяет неограниченному числу пользователей, независимо от их физического местонахождения, работать с базами данных, находящимися на сервере.
Очевидно, что чем сложнее структура базы данных, тем разнообразнее запросы к ней со стороны пользователей.
Рассмотрим наипростейший пример. Пусть база данных состоит из единственной таблицы с n полями, и пусть пользователю разрешено только просматривать содержимое любого из ее полей или содержимое сразу нескольких полей в различных комбинациях без каких-либо дополнительных условий. (То есть выполнять запросы вида:
SELECT * FROM таблица или SELECT (список полей) FROM таблица). (1)
В этом случае общее число возможных запросов составит 
, то есть 2n . При n=20 (а бывают таблицы с гораздо большим количеством полей) это число равно 1 048 576. Учитывая, что число таблиц в базе данных может исчисляться десятками, а то и сотнями, нетрудно подсчитать, каково будет число простейших запросов в этих случаях. А если учесть, что запросы могут быть сколь угодно сложными, причем в большинстве своем они требуют получения некоторой информации от пользователя, то их общее количество становится астрономической величиной. Поэтому предусмотреть отдельный web-документ для формирования каждого запроса совершенно невозможно.
В силу всего сказанного выше серверные сценарии, разрабатываемые для поддержки web-интерфейса к базе данных, позволяют выполнять лишь ограниченный набор SQL-запросов.
Поставим задачу создания
конструктора, то есть такого
интерфейса к базе данных, который позволил бы
в режиме диалога создавать SQL-запросы к любому указанному источнику данных.
Этот конструктор должен быть легко настраиваемым на любую удаленную БД (а иначе его создание не имеет смысла) и максимально “дружественным” к пользователю.
Пользователь не обязан знать СУБД, средствами которой создана интересующая его база данных. Более того, он может даже не знать структуры этой базы данных. Эта структура должна определяться средствами серверного сценария (например, на PERL) и показываться пользователю. Было бы удобно ввести для имен таблиц и полей “псевдонимы”, раскрывающие смысл содержащейся в них информации. (Например, к таблице disc обращаться по имени Дисциплины, к полю lan – по имени Язык и т.д.) Понятно, что и ключевые слова запросов (SELECT, DELETE, UPDATE, INSERT) нужно заменить псевдонимами: “НАЙТИ”, “УДАЛИТЬ”, “ИЗМЕНИТЬ”, “ДОБАВИТЬ”.
Обычно некоторые запросы повторяются очень часто, другие же являются единичными. Нужно предоставить пользователю возможность сохранения однажды сгенерированного им запроса (с тем, чтобы впоследствии не генерировать их заново). Сохранять SQL-запрос следует в наиболее удобоваримой форме, например, в виде фраз: “Вывести список всех иногородних студентов”, “Вывести список всех студентов, имеющих задолженности”, “Вывести список дисциплин, по которым в текущем семестре есть экзамен” и т.д. Формулировка SQL-запроса “бытовым” языком должна осуществляться пользователем. Необходимо предусмотреть возможность редактирования и удаления сохраненных SQL-запросов (для пользователей, имеющих соответствующие права доступа).
Многие запросы при формировании требуют ввода каких-либо значений, участвующих в логическом выражении. При создании web-интерфейса для ввода этих значений нужно предусмотреть динамическое создание соответствующей формы. Желательно, чтобы вид этой формы соответствовал типу поля, на которое накладывается условие.
Таким образом, конструктор SQL-запросов должен представлять собой систему, содержащую базу данных и несколько серверных сценариев. БД должна создаваться динамически в соответствии со структурой той базы данных, для просмотра или администрирования которой этой конструктор создается. Создаваемая “промежуточная” БД должна содержать псевдонимы имен таблиц и полей исходной базы данных, псевдонимы наиболее часто используемых запросов, информацию о правах доступа. Серверные сценарии должны динамически создавать web-документы, соответствующие тому или иному этапу формирования очередного SQL-запроса.
В настоящее время разработан сценарий для динамической генерации запросов типа (1). Его необходимо усовершенствовать с учетом всего сказанного выше, а также создать серверный сценарий для генерации промежуточной базы данных.