Этапы и стадии построения ИС

Самой первой проблемой построения ИС является проблема проектирования. Нельзя начинать техническую разработку, не имея тщательно проработанного проекта. Хотя строгая терминология в проектировании ИС до конца не разработана, можно выделить три этапа проектирования: логический, физический, и проектирование интерфейсов. Логический этап проектирования, свою очередь, делится на несколько стадий.

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

Вторая стадия проектирования - выработка концептуальной схемы БД, которая будет лежать в основе ИС. Должна быть выбрана система нотаций, в которой будет представляться концептуальная схема. Концептуальное представление базы данных должно сохраняться как часть документации информационной системы на все время ее существования и будет использоваться при ее сопровождении и развитии.

Поскольку большинство БД является реляционными, то третья стадия проектирования состоит в выборе определений схемы реляционной базы данных в терминах языка SQL - универсального компьютерного языка, применяемого для создания, модификации и управления данными в реляционных БД.

На четвертой стадии должен быть осуществлен выбор архитектуры системы. В частности, очень важно решить, какой будет база данных - централизованной или распределенной. Если принимается решение о распределенном характере базы данных, то необходимо произвести соответствующую декомпозицию набора определений схемы базы данных. Решение об архитектуре системы возможно и до выработки общей реляционной схемы базы данных. Тогда декомпозиция производится на уровне концептуальной схемы, а затем для каждой отдельной части концептуальной схемы создается реляционная схема в терминах языка SQL.

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

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

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

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

Работы, связанные с физическим проектированием, целесообразно выполнять совместно со специалистом, который в дальнейшем будет выполнять функции администратора БД. Если на стадии физического проектирования такой специалист еще не назначен, необходимо тщательно документировать детали физического проекта.

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

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

Что же касается обрабатывающих частей ИС, то все зависит от того, что они должны делать. Имеется масса примеров ИС, в которых вся обработка данных состоит в преобразовании их форматов при вводе и выводе, формировании отчетов и т.д. Такие функции можно фактически не программировать, поскольку существуют стандартные процедуры их автоматического генерирования по соответствующим описаниям. Но если требуется более сложная обработка данных, то в любом случае потребуется явное программирование, и в этом случае уже не столь важно, на каком языке программирование будет вестись.