double arrow

Системный анализ

Ключевым этапом при разработке любой информационной системы является проведение системного анализа:

1. формализация предметной области;

2. представление системы как совокупности компонент.

Системный анализ позволяет, с одной стороны, лучше понять «что надо делать» и «кому надо делать» (аналитику, разработчику, руководителю, пользователю), а с другой – отслеживать во времени изменения рассматриваемой модели и обновлять проект.

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

Существуют два подхода к определению состава и структуры предметной области:

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

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

Условность такого деления достаточно очевидна, поэтому на практике используются компромиссные варианты, предполагающие по мере развития системы расширение, как состава объектов, так и спектра прикладных задач.

При рассмотрении требований конечных пользователей необходимо принимать во внимание следующее:

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

2. БД должна обеспечивать получение требуемых данных за приемлемое время, т.е. обеспечивать заданную производительность.

3. БД должна быть рассчитана на возможность удовлетворения вновь возникающих требований конечных пользователей.

4. БД должна быть рассчитана на возможность расширения при реорганизации и расширении предметной области.

5. БД должна легко изменяться при изменении программной и аппаратной среды.

6. Загруженные в БД корректные данные должны оставаться корректными.

7. Данные до включения в БД должны проверяться на достоверность.

8. Доступ к данным, размещаемым в БД, должны иметь только лица с соответствующими полномочиями.

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

2. Формирование из объектов предметной области сущностей
и их характеристик

Следующий шаг включает в себя анализ объектов реального мира, которые необходимо смоделировать в БД.

Моделирование концептуального уровня БД включает в себя:

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

- идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс "ведение учета работающих" идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.

- идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.

- идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

3. Установка соответствия между сущностями и таблицами,
характеристиками сущностей и столбцами таблиц

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

Получение реляционной схемы из ER-диаграммы:

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Каждый атрибут становится столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение.


Сейчас читают про: