1.1. Разработка клиентских приложений.

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

Процесс же создания клиентских приложений, работающих с базами данных, достаточно сложно описать в виде подобной универсальной последовательности действий, поскольку логика конкретного приложения практически полностью зависит от логики моделируемого бизнес-процесса. Средства разработки приложений как категория программных продуктов существуют гораздо дольше, чем средства проектирования данных, и они более разнообразны — от компилятора, запускаемого из командной строки, до инструментов, где готовое приложение собирается «мышью» из готовых компонентов, а код генерируется автоматически. При таком разнообразии средств разработки их следует каким-то образом классифицировать, и какие-то из них удобно применять в том или ином случае.

Классификация средств разработки приложений.

2.1.Классификация приложений.

Практически любое средство разработки, мало-мальски претендующее на универсальность, можно заставить работать с любой базой данных — достаточно поддержки применения в этом средстве разработки сторонних библиотек и наличия у этой базы данных набора клиентских интерфейсов (API) для платформы, на которой должны функционировать созданные приложения.

Однако далеко не любая пара продуктов «средство разработки плюс СУБД» привлекательна с точки зрения трудозатрат, связанных с созданием подобных приложений. Можно написать полноценное приложение, вызывающее функции клиентского API и реализующего удобный пользовательский интерфейс с помощью компилятора языка С и простейшей графической библиотеки (например, позволяющей изменять цвет пикселей на экране) для той операционной системы, в которой будет работать данное приложение. Но затраты, связанные с реализацией подобного проекта, могут оказаться совершенно неоправданными — ведь в этом случае разработчикам придется реализовывать функции, которые уже содержатся в библиотеках классов и компонентов средств разработки, более глубоко ориентированных на создание приложений с базами данных или включающих поддержку создания таких приложений.

2.2.Средства разработки, ориентированные на конкретные субд.

Лет десять-двадцать назад во многих приложениях, использующих базы данных, функции клиентского API вызывались из кода, написанного на одном из языков программирования, чаще всего на C. Достаточно взглянуть на описание API клиентской части почти любой серверной СУБД — и вы найдете немало примеров наиболее типичных фрагментов кода, например, для регистрации пользователя, выполнения запросов и т.п.

Однако достаточно быстро разработчикам СУБД стало ясно, что трудозатраты, связанные с написанием подобного кода, можно существенно сократить, собрав в библиотеки наиболее типичные фрагменты кода и наиболее часто встречающиеся элементы пользовательского интерфейса (пусть даже и для алфавитно-цифровых терминалов), оформив эти библиотеки в виде отдельного продукта и добавив к нему среду разработки и утилиты проектирования пользовательских форм для просмотра и редактирования данных, а также отчетов. Именно так и появились первые средства разработки, ориентированные на конкретные СУБД, такие, например, как Oracle*Forms (предшественник нынешнего Oracle Forms Developer).

Продукты этого класса на рынке средств разработки имеются и сегодня. Почти все производители серверных СУБД производят и средства разработки приложений. В подавляющем большинстве случаев современные версии этих средств разработки поддерживают доступ к СУБД других производителей как минимум с помощью одного из универсальных механизмов доступа к данным (ODBC, OLE DB, BDE).

Однако доступ к «своей» СУБД обычно осуществляется максимально эффективным способом, то есть с помощью клиентских API, объектов, содержащихся в библиотеках клиентской части серверных СУБД, специальных классов для доступа к данным этой СУБД либо за счет реализации драйверов для универсальных механизмов доступа к данным, способной учитывать специфические особенности данной СУБД.

В отдельную категорию можно выделить среды разработки настольных СУБД. В статье данного цикла, посвященной настольным СУБД, мы уже отмечали, что подавляющее большинство настольных СУБД, доживших до сегодняшнего дня, таких как Microsoft Visual FoxPro, Microsoft Access, Corel Paradox, Visual dBase, поддерживают доступ к серверным СУБД, как минимум, с помощью универсальных механизмов доступа к данным, что позволяет условно отнести их и к категории средств разработки.

Отметим, однако, что в настоящее время создание приложений в архитектуре «клиент-сервер» с их помощью — явление нечастое. Исключение, пожалуй, составляют пары Microsoft Access — MSDE, Microsoft Access — Microsoft SQL Server и Microsoft Visual FoxPro — Microsoft SQL Server. Здесь налицо результат грамотной политики Microsoft, стремящейся к максимальной совместимости своих продуктов и обеспечивающей наиболее безболезненную для пользователей замену своих настольных СУБД собственными же серверами баз данных (Access->MSDE->Microsoft SQL Server, FoxPro->Visual FoxPro->Microsoft SQL Server).