Таким образом, файловые информационные системы (ФИС) обладали следующими основными  недостатками:

• программист работал с данными на уровне физического доступа к данным. Следовательно, должен был хорошо разбираться в механизмах работы операционной системы. Это требовало достаточно высокой квалификации и снижало производительность труда при разработке ИС;
• изменения в структурах данных из-за появления новых задач приводило к необходимости изменения кода ранее написанных приложений. Таким образом, чем более крупной была ФИС, тем более медленней она эволюционировала.

Именно эти  причины сдерживали повсеместное внедрение  систем.

Идея  СУБД. Отличие от ФИС

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

   Переход от ФИС к ИС, созданных на базе СУБД привел к повсеместному распространению  информационных систем. 

Определение банка данных. Требования к БНД

 

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

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

   БнД выступает в роли специальной  обеспечивающей подсистемы (п/с) в составе ИС различного профиля.

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

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

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

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

БнД должен:

1. Удовлетворять актуальным информационным потребностям внешних пользователей, обеспечивать возможность хранения и модификации больших объемов многоаспектной информации.
2. Обеспечивать заданный уровень достоверности хранимой информации.
3. Обеспечивать доступ к данным только пользователям с соответствующими полномочиями.
4. Обеспечивать возможность поиска информации по произвольной группе признаков.
5. Удовлетворять заданным требованиям по производительности при обработке запросов.
6. Иметь возможность реорганизации и расширения при изменении границ ПО.
7. Обеспечивать выдачу информации пользователю в различной форме.
8. Обеспечивать простоту и удобство обращения внешних пользователей за информацией.
9. Обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

ПРЕИМУЩЕСТВА  ЦЕНТРАЛИЗАЦИИ УПРАВЛЕНИЯ ДАННЫМИ:

1. Сокращение избыточности хранимых данных (минимально необходимых - дублирование данных).
2. Устранение противоречивости хранимых д. (хранимых в различных файлах).
3. Многоаспектное использование д. (принцип однократного ввода д).
4. Комплексная оптимизация. (Напр., выбор структуры хранения д., которая обеспечивает наилучшее обслуживание в целом). В максимальной степени удовлетворяются противоречивые требования.
5. Обеспечение возможности стандартизации (упрощение обмена д., контроля и восстановления д.).
6. Обеспечение возможности санкционированного доступа к данным.

 

 

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

   Рассматривая  д. как один из ресурсов АС, можно  сказать, что БнД централизованно  управляет этим ресурсом в интересах всей системы. Наличие централизованного управления данными - главная отличительная черта БнД.

   БнД - информационная подсистема, реализующая  централизованное управление д. в интересах  всех пользователей АС. (Средство интеграции д.).

Понятие о корпоративных  и распределенных системах

 

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

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

В корпоративных  информационных системах по естественным причинам часто возникает потребность  в распределенном хранении общей базы данных.

Рис. 2.

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

Общая технология создания ИС. Структурный подход к созданию ИС

Системная и задачная технология создания ИС

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

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

• Срочность;
• Эксперимент и адаптация заказчика.

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);
• DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

 

 Модели  жизненного цикла  ПО

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени  наибольшее распространение получили следующие две основные модели ЖЦ:

• каскадная модель (70-85 г.г.);
• спиральная модель (86-90 г.г.).

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

Положительные стороны применения каскадного подхода  заключаются в следующем [2]:

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

Рис. 1.1. Каскадная схема  разработки ПО

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