Рост спроса на ИС предъявляет требования к самому проектированию: повысить производительность труда при разработке; повысить эффективность сопровождения, т. к. последнее требует больших затрат, чем непосредственно разработка.

7.2. Жизненный цикл информационной системы

Жизненный цикл (ЖЦ) ИС включает в себя все этапы развития от возникновения потребности в информационной системе определенного целевого назначения до полного прекращения ее использования вследствие морального старения или потери необходимости решения поставленных задач.

По длительности ЖЦ АЭИС разделяется на два класса:

1) Системы с малой длительностью эксплуатации, предназначенные для получения конкретных результатов вычислений. Они относительно невелики (до 10 тысяч команд), разрабатываются, как правило, одним специалистом или небольшой группой, не предназначены для тиражирования и передачи для последующего использования, преобладают в научных организациях и ВУЗах.

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

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

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

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

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

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

При создании ИС важнейшей задачей является максимизация экономической эффективности функционирования.

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

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

Глобальная оптимизация эффективности ИС на всем жизненном цикле весьма сложна и в большинстве случаев у разработчиков превалирует стремление оптимизировать этот показатель лишь на некотором интервале времени.

7.3. Разработка технического задания

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

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

Анализ полученной информации позволяет:

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

§  построить схему информационных потоков внутри организации и определить внешние информационные связи;

§  изучить процессы формирования и маршруты движения документов;

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

§  построить логическую схему обработки данных.

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

Техническое задание на разработку информационной системы должно содержать следующие разделы:

• Описание результатов обследования предприятия.

• Предложения по совершенствованию существующей системы управления.

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

• Состав функциональных подсистем и автоматизированных рабочих мест с перечнем решаемых задач.

• Перечень предварительно выбранных программных и технических средств с обоснованием их выбора.

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

7.4. Проектирование базы данных информационной системы

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

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

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

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

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

Рис. 7.1. Уровни моделей данных

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

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

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

Основой этого процесса является, предложенный Е. Коддом в рамках реляционной теории аппарат, называемый нормализацией отношений. Было выделено пять форм нормальных отношений и предложен механизм перехода от формы к форме.

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

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

Пример нормализации данных

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

Построение приложения базы данных для автоматизации отдельных аспектов бизнеса надо начать, скорее всего, с изучения способов решения текущих задач компании. В нашем примере – с анализа данных, необходимых для составления рабочего заказа клиента и счета, который клиент должен оплатить. Если для размещения этих данных создан двухмерный файл, он может выглядеть примерно так, как табл.4.1. База данных типа «двухмерный файл» размещает всю информацию в одной большой таблице, используя отдельные столбцы для отдельных частей данных.

Таблица 7.1.

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

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

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

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

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

·  Аналогичная проблема возникает с повторяющимися полями, которые относятся к различным запасным частям заказа. В лучшем случае, впустую затрачивается пространство, а в худшем – вы, размещая данные, выходите за пределы полей.

·  Множество одинаковых по смыслу полей затрудняет исполнителям заказа поиск и введение дополнительной информации.

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

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

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

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

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

Таблица 7.2

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

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

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 11 12 13