Проектирование информационных систем. Учебное пособие

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

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

в качестве критерия выступает степень

ее динамичности. Для более

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

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

На уровне общего описания системы функциональные методики

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

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

применении функцио­нального и объектного подхода с учетом возможности реинжиниринга существующей ситуации [10].

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

Логическая модель предъявляет определенные требования со сторо-

пользователей к данным в терминах логических структур определен-

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

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

модель преобразу-

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

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

Логическое моделирование является логическим продолжением

процесса концептуального

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

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

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

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

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