Что обычно происходило при развитии такой системы? Типичный сценарий жизни подобной ИС таков. После ввода в эксплуатацию выявляются недочеты (нередко связанные не с ошибками программистов, а с неверно сформулированным техническим заданием), у пользователей возникают новые потребности (создать тот или иной дополнительный сервис, модернизировать структуру таблиц, добавить новые таблицы, запросы или отчеты, изменить выходные формы или предусмотреть возможность их редактирования). Начинается переработка исходных текстов, структур таблиц, добавление "заплат". В конечном итоге получается программный продукт, в исходном тексте которого никто, кроме автора, разобраться не в состоянии. Примерно так же выглядит и используемая структура данных. При этом связи между таблицами могут быть не просто неочевидными, порой они оказываются невероятно причудливыми. О подчинении данных реляционной модели, как правило, не может быть и речи. Чем дальше, тем сложнее становится модернизировать подобную ИС, и в конечном итоге приходится ее перепроектировать и переписывать заново, портировать старые данные в новую структуру, что нередко приводит к немалым трудовым и материальным затратам. Автору приходилось наблюдать случай, когда из-за накопившегося количества переделок действующей ИС, неудачно спроектированной структуры данных и некорректной обработки транзакций при завершении работы приложения переписывались заново несколько десятков dBase-таблиц, что занимало несколько минут. При сбоях происходило нарушение ссылочной целостности БД, и система становилась неработоспособной. Из-за этого пришлось оснастить рабочие станции источниками бесперебойного питания (а пользователей снабдить валокордином и валерьянкой). Проблема генерации отчетов, не предусмотренных приложением, на основе полученной БД не решалась в принципе -- никто, кроме автора, не мог понять, как между собой связаны таблицы. Самое удивительное, что существуют ИС, основанные на архитектуре "клиент/сервер" (например, использующие сервер Oracle 7), созданные и развивающиеся подобным образом. Опыт работы многих программистов показывает, что, как правило, редко удается создать идеальную ИС. Следовательно, необходимо изначально предусматривать возможность ее безболезненной модернизации. Поэтому нужны иные подходы к проектированию ИС, нежели те, что применялись до недавнего времени. Одним из таких подходов и является применение специализированных средств проектирования структур данных -- так называемых CASE-средств (CASE расшифровывается как Compu-ter Aided Software Engineering или Computer Aided System Engineering, что, по существу, отражает многообразие решаемых этими средствами за-дач -- от создания структур данных до генерации приложений). CASE-средства позволяют автоматизировать процесс создания структур данных, создавать серверные части приложений, вносить в них бизнес-логику приложения, правила контроля целостности данных, а также приписывать полям в таблицах расширенные атрибуты (тип интерфейсного элемента, максимальные и минимальные значения, значения по умолчанию и т.д.). Немаловажно, что в процессе проектирования и перепроектирования структур данных можно документировать создаваемые таблицы, их поля и связи между ними и отображать графически полученную структуру.
К сожалению, CASE-технология на сегодняшний день используется недостаточно широко. В лучшем случае разработчики считают CASE-средства просто инструментом для рисования, чем-то вроде CorelFlow. В большинстве случаев об этих средствах разработчики не слышали вообще или имеют смутное представление. Как показало проведенное автором небольшое статистическое исследование, примерно треть (!) выставляющих свои программные продукты на стендах выставки SofTool'96 специалистов-разработчиков, не говоря уже о менеджерах, никогда о CASE не слышали, еще треть слышали, но не видели, и буквально единицы видели и используют. Примерно такая же картина наблюдалась среди посетителей стенда фирмы Borland на выставке WindowsExpo'96. И, видимо, придется приложить немало усилий, чтобы эти замечательные средства завоевали умы и сердца разработчиков. Одним из CASE-средств, наиболее удачных с точки зрения соотношения цены, простоты использования и возможностей, является ERwin фирмы Logic Works. Данное средство обладает всеми перечисленными возможностями и при этом имеет удобный интерфейс, интуитивно понятные инструменты, разнообразные возможности графического представления структуры данных. Это средство поддерживает много разных форматов плоских таблиц и серверных БД и умеет создавать триггеры и хранимые процедуры на соответствующих процедурных расширениях языка запросов SQL, поддерживаемых обслуживаемыми серверами (в случае Oracle это PL/SQL). При этом, проектируя стуктуру данных, не обязаны знать ни SQL, ни его расширения.
Следует отметить, что большинство CASE-средств позволяет восстанавливать схему БД по имеющейся физической структуре (такая процедура называется обратным проектированием, или реинжинирингом). Что касается ERwin, то на сегодняшний день это единственное средство, позволяющее не только восстанавливать сведения о плоских таблицах типа dBase или Paradox, но и сведения о некоторых связях, основываясь на индексах, имеющихся в такой БД.
Как осуществляется проектирование БД для сервера Oracle с использованием ERwin? Все очень просто. При разработке новой ИС вы можете использовать полностью или частично структуру ее прежней версии или иного прототипа. В этом случае сначала вы делаете реинжиниринг этого прототипа и получаете некий полуфабрикат вашей схемы, требующий, как правило, модернизации (изменения имен полей, восстановления связей и др.). Если же прототипа нет, можно создать схему с самого начала. В этом случае вы создаете на экране прямоугольники, соответствующие вашим таблицам, описываете поля этих таблиц, а затем рисуете связи между таблицами и описываете свойства этих связей. То, что получится в результате, называется ER-диаграммой (или диаграммой "сущность-связь"). Далее выбирается соответствующий сервер вашей БД (в нашем случае Oracle), и после этого можно либо соединиться с сервером и создать на нем пустую структуру из таблиц, индексов и триггеров, либо оставить это увлекательное занятие на откуп администратору БД и SQL*Plus, сохранив вашу диаграмму в виде программы на языке PL/SQL. Такая программа называется DDL-сценарием приложения (DDL расшифровывается как Data Definition Language) и делает то же самое -- создает таблицы, индексы и триггеры в соответствии с вашим описанием.
Что можно делать дальше? А дальше можно писать приложение, используя имеющуюся структуру БД. При этом, если вы правильно выбрали средство разработки (автор очень рекомендует Borland Delphi), в случае нарушения ссылочной целостности или иных установленных вами правил, ваше приложение будет цитировать сообщения созданных ERwin триггеров (что такое триггер, вы, вообще говоря, тоже знать не обязаны, хотя в условиях российской действительности их сообщения не вредно перевести на русский язык или, слегка поредактировав шаблоны в ERwin, заменить чем-нибудь более понятным для пользователя, нежели фразы типа "Foreing key not found").
Следует отметить, что для некоторых средств разработки приложений (SQL Windows, Power Builder, VB) созданы специальные версии ERwin, позволяющие создавать формы конечных приложений (например, для ввода данных). Президентом фирмы Logic Works Беном Коганом обещан ERwin для Delphi. То, что известны форматы словарей данных как самого ERwin, так и Delphi, дает повод для создания специализированных программ-экспертов для переноса данных между этими словарями, встраиваемых в среду разработки Delphi (один из таких экспертов входит в комплект поставки Delphi 2.01).
Итак, структура базы данных готова, приложение написано и отлажено...
Вы создаете документацию к ваше-му приложению. Вспомните о ER-диаграмме! Если вы не забыли внести в нее все описания, комментарии к полям, таблицам и связям -- это замечательная основа для вашей документации. Да и сама схема БД послужит не один год важным источником информации для ваших пользователей, когда они будут создавать отчеты, и для вас и ваших коллег, когда вы в очередной раз будете модернизировать созданную вами информационную систему.
И еще одна приятная деталь. Если у вас возникла необходимость сменить один сервер на другой, вы можете использовать все ту же ER-диаграмму для создания схемы новой базы данных на этом сервере. При этом вы получите триггеры уже на другом диалекте SQL, поддерживаемом новым сервером -- ERwin сделает это за вас автоматически. А если вдруг вы решите создать набор dBase-таблиц, то вместе с их заголовками получите и текст программы для создания индексов на нужном диалекте xBase.
Вы убедились, что ERwin вам жизненно необходим? Тогда ждем вас в фирме Interface Ltd. -- крупнейшем в России дистрибьюторе этого замечательного средства. Наши специалисты могут обучить вас работе с этим средством, помочь выбрать средство разработки, подходящее для вашей задачи, спроектировать вашу базу данных, написать приложения и помочь создать отчеты.