Обследование, системный анализ и постановка задачи

Необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами (содержание данного пункта скопировано из работы [19]). Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области. В общем случае существуют два подхода к выбору состава и структуры предметной области:

Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

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

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

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

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

Организуется обследование предметной области: оценка объема и цели проекта, определение требований, объектов и функций на высоком уровне.

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

Исходная информация для анализа берется из индивидуальных бесед с заказ­чи­­ками, на семинарах, при изучении документации, инструкций, анкети­ро­ва­нии и др.

Примерное содержание исходной информации (анкет):

1) имя и описание объекта данных. Назначение и использование объекта в подразделениях;

2) элементы данных. Для каждого элементарного данного объекта указывается: его имя и описание, источник, формат (тип, диапазоны до­пустимых значений), использование, ограничения доступа, степень важно­сти, взаимосвязи;

3) продолжительность хранения и условия перевода в архив.

Результаты фиксируются в документе типа технического задания (ТЗ), который содержит: назначение, требования, ограничения, возмож­нос­ти, бизнес‑процессы (функции), объ­ем, смету затрат, сроки, показатели эконо­ми­ческой эффективности, испол­нители.

Производится исследование информационных потоков, до­кументооборота (схемы движения данных от источника к пользовате­лю), функций и информации для их вы­пол­не­ния (объектов, атрибутов и таблиц) без учета конкретных прог­рам­мных средств. Формулируются биз­нес‑правила (факты, которым дол­жна подчи­нять­ся система).

Проектирование – поиск способа удовлетворения фун­­к­циональных по­треб­ностей пользователей средствами имеющихся тех­­нологий с учетом заданных ограничений.

Проектирование охватывает три области: таб­ли­цы, запросы, пред­став­ления, хранимые процедуры и функции; формы, от­че­ты и программы; топологию сети, модели использования таблицы.

Формализация объектов и связей между ними, построение концептуальной модели, формирование набора таблиц с указанием пер­вичных клю­чей для каждой таблицы, добавление неключевых атри­бутов в таб­ли­цы, нормализация таблиц.

Изучаются существующие СУБД и выбирается нужная (п. 1.5.6).

Далее разрабатывается логическая и физическая модели БД в тер­ми­нах выбранной СУБД.

Проектируются программы, хранимые процедуры, триггеры.

В целом можно выделить отдельные этапы инфологического (концептуального), даталогического (логического) и физического проектирования, которые буду рассмотрены ниже.

Дата добавления: 2014-12-10