Выполнение
| Динамическая схема | На стороне клиента | Компиляция и выполнение на стороне сервера |
| Статическая схема | На стороне клиента, компиляция на стороне сервера | Выполнение на стороне сервера |
Идея же процедур SQL, определяемых на языке модулей, повлекла внедрение во многие реализации механизма хранимых процедур. Хранимая процедура - это именованная, параметризованная конструкция, определяемая на языке SQL или некотором его расширении, встраиваемая в прикладную программу, компилируемая на стороне сервера во время обработки текста процедуры прекомпилятором. Выполняемый или интерпретируемый код хранимой процедуры сохраняется в базе данных, а сама она может быть вызвана из любой прикладной программы авторизованного пользователя (того, кто получил привилегию на выполнение этой процедуры) с указанием фактических параметров (рисунок 1.5). Пожалуй, механизмы хранимых процедур возникли прежде всего для того, чтобы обеспечить некоторое подобие статической компиляции встроенных операторов SQL в СУБД, которые поддерживают динамическую схему. Компания Oracle пошла дальше, разработав процедурное расширение SQL - язык PL/SQL. С использованием этого языка можно отсылать на сервер компоненты логики приложения. (Похоже, что в следующем стандарте языка SQL - SQL-3 - появится нечто похожее на PL/SQL.) Как мы отмечали выше, фактически это можно трактовать как первое приближение к трехзвенной организации информационной системы. Как правило, развитые СУБД поддерживают язык модулей SQL, но язык хранимых процедур обычно шире и не стандартизован. Поэтому с хранимыми процедурами нужно обращаться осторожно, если вы не хотите попасть в полную зависимость от конкретного производителя. Кроме того, в случае использования распределенной базы данных следует внимательно отслеживать возможности ссылок на таблицы, размещающиеся в разных разделах.
Рис. 1.5. Подготовка и использование хранимой процедуры
Наконец-то мы закончили с логическим проектированием базы данных информационной системы и можем приступать к следующим стадиям.
По крупному, их осталось две: физическое проектирование базы данных; проектирование и разработка интерфейсов и обрабатывающей части прикладной системы. Эти две стадии могут выполняться параллельно.
Физическое проектирование включает два основных шага, первый из которых, как правило, не зависит от особенностей выбранного серверного SQL-ориентированного продукта, а второй зависит, причем критически. На первом шаге этой стадии определяется набор требуемых индексов. Для того, чтобы правильно выбрать этот набор, необходимо еще раз тщательно проанализировать требования корпорации и оценить, какие запросы будут выполняться наиболее часто. Это непростая задача, но нужно учитывать, что создание индекса на большой заполненной таблице (когда информационная система уже функционирует) требует значительного времени. Нужно также иметь в виду, что операторы определения (создания) и уничтожения индексов не определены в стандарте SQL. Хотя имеется негласное соглашение между производителями SQL относительно вида этих операторов, они все же могут различаться в разных системах. Кроме того, следует иметь в виду, что в большинстве систем индексы автоматически создаются для полей таблицы, которые объявлены первичным, возможными или внешними ключами.
Второй шаг состоит в определении областей внешней памяти, в которых будут храниться фрагменты базы данных. По этому поводу вообще невозможно дать какие-либо общие рекомендации, поскольку вопрос непосредственного размещения данных во внешней памяти является специфическим для каждой конкретной СУБД. Если нет человека, имеющего опыт администратора данной системы, единственный выход состоит во внимательном изучении руководства администратора. Обычно эти руководства содержат по меньшей мере описание того, как СУБД работает с внешней памятью. Конечно, окончательное решение остается на совести проектировщика.
Кстати, заметим, что, видимо, целесообразно выполнять работы, связанные с физическим проектированием, совместно со специалистом, который в дальнейшем будет выполнять функции администратора базы данных.
Если на стадии физического проектирования такой специалист еще не назначен, необходимо тщательно документировать детали физического проекта.
Параллельно с физическим проектированием базы данных информационной системы может проводиться проектирование и разработка интерфейса системы и ее обрабатывающей части. В принципе, к этому моменту уже должно быть ясно, что вы хотите от интерфейса и какие функции должна выполнять система. Так что основной проблемой этой стадии является выбор инструментальных средств, которые позволят достаточно быстро произвести достаточно эффективную реализацию. Мы недаром два раза употребили слово "достаточно". Нужно понять, что важнее для корпорации - как можно быстрее ввести информационную систему в действие или добиться требуемого уровня эффективности.
Понятно, что в любом случае в наше время неразумно программировать интерфейсные функции вручную. Нужно использовать имеющиеся полуфабрикаты. Но здесь имеется большая возможность выбора: базовые библиотеки используемой оконной системы (например, X Toolkit Intrinsics в оконной системе X), универсальные инструментальные средства построения графического пользовательского интерфейса более высокого уровня (например, Motif или Tcl/Tk), языки и системы программирования 4-го поколения (например, PowerBuilder, Jam и т.д.). На наш взгляд, выбор определяется вкусом и привычками разработчика, а также общей ориентацией проекта. Например, если с самого начала проект был ориентирован на использование продуктов компании Oracle и ведется в интегрированной среде Designer/Developer 2000, то было бы странно покидать эту среду при разработке интерфейсов.
Что же касается обрабатывающих частей информационной системы, то все зависит от того, что они должны делать. Имеется масса примеров информационных систем, в которых вся обработка данных состоит в преобразовании их форматов при вводе и выводе, формировании отчетов и т.д. Такие функции можно фактически не программировать, поскольку любой 4GL может сгенерировать их автоматически по соответствующему описанию.
Но если требуется более сложная обработка данных, то в любом случае потребуется явное программирование, и тогда уже неважно, на каком языке это программирование будет вестись. В частности, если вы используете Delphi для разработки интерфейсов, то для программирования разумно использовать Object Pascal (прекрасный язык, но пока жестко привязанный к Intel-платформам). В других случаях можно применять процедурную часть 4GL (обычно все они похожи на Basic) или Си/Си++ (как правило, стыковка 4GL с этими языками поддерживается).
Последнее замечание этого раздела. Мы описали одну из возможных схем проектирования и разработки информационной системы, представив весь процесс в виде последовательно выполняемых стадий. Если проект основывается на некотором интегрированном CASE-средстве с единым репозитарием, то эти стадии, вообще говоря, могут перемешиваться. Возможности использования интегрированных инструментальных средств при проектировании, сопровождении и реинжиниринге информационных систем будут рассмотрены в следующих частях курса.
