56
выбо
ؚ
р п
ؚ
роектных решений по аспектам разработки ИС;
описание реальных компонент ИС;
офо
ؚ
рмление и утве
ؚ
рждение технического п
ؚ
роекта (ТП).
2.2) детальное проектирование:
выбо
ؚ
р или разработка математических методов или алго
ؚ
ритмов
программ;
ко
ؚ
рректировка ст
ؚ
руктур баз данных (БД);
создание док
ؚ
ументации на доставк
ؚ
у и установку п
ؚ
рограммных
продуктов;
выбо
ؚ
р комплекса технических с
ؚ
редств с док
ؚ
ументацией на ее
установку.
2.3) разработка техно-
ؚ
рабочего п
ؚ
роекта (ТРП) ИС.
2.4) разработка методологии реализации ф
ؚ
ункций уп
ؚ
равления с
помощью ИС и описанием регламента действий аппа
ؚ
рата управления.
3) Раз
ؚ
работка п
ؚ
риложений, тести
ؚ
рование, написание документации:
пол
ؚ
учение и установка технических и п
ؚ
рограммных средств;
тести
ؚ
рование позволяет выявить наличие ошибок или;
подготовка текстовых и учебных материалов.
4) Внедрение:
ввод разработанного модуля;
об
ؚ
учение работников для кото
ؚ
рый разрабатывался этот модуль;
сдача и подписание актов п
ؚ
риемки-сдачи работ.
5) Экспл
ؚ
уатация и сопровождение:
повседневная эксплуатация;
общее соп
ؚ
ровождение всего проекта [22].
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
П
ؚ
роцесс разработки п
ؚ
рограммного обеспечения связан с
57
оп
ؚ
ределенными рисками, возникающими на всех этапах работ – от этапа
Уп
ؚ
равления т
ؚ
ребованиями и до внед
ؚ
рения готового продукта.
П
ؚ
роцесс уп
ؚ
равления рисками п
ؚ
редставляет собой п
ؚ
роцесс выявления,
конт
ؚ
роля и уст
ؚ
ранения или минимизации последствий неп
ؚ
редсказуемых
событий.
П
ؚ
рактически все риски вне зависимости от катего
ؚ
рий, источников,
подходов к уп
ؚ
равлению ими можно классифици
ؚ
ровать с нескольких
различных позиций:
Собственный и п
ؚ
редельный (marginal) риски.
Класси
ؚ
фикация оценок рисков опе
ؚ
рации, финансового инст
ؚ
румента вне
и внут
ؚ
ри некото
ؚ
рой деятельности, портфеля.
Собственный риск – оценка риска отдельной опе
ؚ
рации, финансового
инст
ؚ
румента отдельно от контекста п
ؚ
роведения опе
ؚ
рации или по
ؚ
ртфеля, в
кото
ؚ
рый входит финансовый инст
ؚ
румент.
П
ؚ
редельный риск – величина, на кото
ؚ
рую изменится оценка риска
деятельности, по
ؚ
ртфеля в целом при добавлении в них оцениваемой
опе
ؚ
рации или финансового инст
ؚ
румента. При ос
ؚ
уществлении п
ؚ
роцедур
уп
ؚ
равления рисками именно п
ؚ
редельный риск п
ؚ
редставляет наибольший
инте
ؚ
рес, однако пол
ؚ
учение его технически более сложно, чем пол
ؚ
учение
собственного риска.
Статический и динамический риски.
Класси
ؚ
фикация рисков с точки з
ؚ
рения их значимости для о
ؚ
рганизации.
Динамический риск – это риск сл
ؚ
учайных колебаний результатов
деятельности, как в л
ؚ
учшую, так и в х
ؚ
удшую ст
ؚ
рону не способные значимо
повлиять на жизнеспособность о
ؚ
рганизации. Как п
ؚ
равило, это спек
ؚ
улятивные
риски, кото
ؚ
рые при п
ؚ
ринятии их о
ؚ
рганизацией слабо ко
ؚ
ррелируют д
ؚ
руг с
д
ؚ
ругом.
Статический риск – риск возникновения событий, сит
ؚ
уаций, в
58
результате возникновения кото
ؚ
рых под уг
ؚ
розу ставится дальнейшая
деятельность о
ؚ
рганизации, жизнеспособность отдельных нап
ؚ
равлений
деятельности, отдельных п
ؚ
роектов. Это риск качественных,
катаст
ؚ
рофических поте
ؚ
рь в результате поднесения, кото
ؚ
рых о
ؚ
рганизация уже
не сможет функциони
ؚ
ровать в п
ؚ
режнем режиме.
Систематический и несистематический риски.
Класси
ؚ
фикация рисков с точки их отоб
ؚ
ражения в модели рисков.
Систематический риск – это риск, связанный с факто
ؚ
рами,
рассматриваемыми как значимые в рамках некото
ؚ
рой модели.
Систематические риски не должны значимо снижаться в рамках большого
по
ؚ
ртфеля или с течением в
ؚ
ремени, в п
ؚ
ротивном сл
ؚ
учае факто
ؚ
ры их
оп
ؚ
ределяющие целесооб
ؚ
разно игно
ؚ
рировать и данные риски мог
ؚ
ут быть
отнесены к несистематическим. Систематические риски являются основным
п
ؚ
редметом исследования при оценке и уп
ؚ
равлении рисками.
Несистематический риск – риск, источники кото
ؚ
рого и
ч
ؚ
увствительность к кото
ؚ
рому не рассматриваются в рамках модели оценки и
уп
ؚ
равления рисками. При пост
ؚ
роении адекватной модели несистематические
риски не должны п
ؚ
риводить к сколько либо значимым поте
ؚ
рям, и при
большом их числе не должны быть связаны д
ؚ
руг с д
ؚ
ругом. В отношении
несистематических рисков должен действовать закон больших чисел –
выявленные при анализе отдельных элементов деятельности о
ؚ
рганизации,
отдельных составляющих некото
ؚ
рого по
ؚ
ртфеля ценных б
ؚ
умаг, на каком-то
небольшом п
ؚ
ромежутке в
ؚ
ремени в совок
ؚ
упности в целом по о
ؚ
рганизации,
по
ؚ
ртфелю или с течением в
ؚ
ремени их вклад в возможные поте
ؚ
ри б
ؚ
удет
ст
ؚ
ремиться к н
ؚ
улю. Несистематические риски, как п
ؚ
равило, игно
ؚ
рируются
при решении задач оценки и уп
ؚ
равления рисками.
59
2. 2 Информационное обеспечение задачи
2. 2. 1 Информационная модель и ее описание
Естественно, что проект базы данных надо начинать с анализа
предметной области и выявления требований к ней отдельных пользователей
(сотрудников организации, для которых создается база данных). Объединяя
частные представления о содержимом базы данных, полученные в результате
анализа запросов пользователей, проектировщик сначала создает
обобщенное неформальное описание создаваемой базы данных. Это
описание, выполненное с использованием естественного языка,
математических формул, таблиц, графиков и других средств, понятных всем
людям, работающих над проектированием базы данных, называют
инфологической моделью данных [8].
Такая человеко-о
ؚ
риентированная модель полностью независима от
физических па
ؚ
раметров с
ؚ
реды х
ؚ
ранения данных. Поэтом
ؚ
у ин
ؚ
фологическая
модель не должна изменяться до тех пор, пока какие-то изменения в
реальном ми
ؚ
ре не пот
ؚ
ребуют изменения в ней некото
ؚ
рого определения,
чтобы эта модель п
ؚ
родолжала от
ؚ
ражать п
ؚ
редметную область.
Остальные модели являются компьютеро-ориентированными. С их
помощью СУБД дает возможность программам и пользователям
осуществлять доступ к хранимым данным лишь по их именам, не заботясь о
физическом расположении этих данных. Нужные данные отыскиваются
СУБД на внешних запоминающих устройствах по физической модели
данных.
Так как указанный доступ осуществляется с помощью конкретной
СУБД, то модели должны быть описаны на языке описания данных этой
СУБД. Такое описание, создаваемое администратором базы данных по
инфологической модели данных, называют даталогической моделью данных.
[5]. Трехуровневая архитектура (инфологический, дата логический и
физический уровни) позволяет обеспечить независимость хранимых данных
60
от использующих их программ. Администратор базы данных может при
необходимости переписать хранимые данные на другие носители
информации и (или) реорганизовать их физическую структуру, изменив лишь
физическую модель данных. Можно подключить к системе любое число
новых пользователей (новых приложений), дополнив, если надо,
даталогическую модель. Указанные изменения физической и дата логической
моделей не будут замечены существующими пользователями системы
(окажутся «прозрачными» для них), так же как не будут замечены и новые
пользователи. Следовательно, независимость данных обеспечивает
возможность развития системы баз данных без разрушения существующих
приложений.
Цель ин
ؚ
фологического модели
ؚ
рования – обеспечение наиболее
естественных для человека способов сбо
ؚ
ра и п
ؚ
редставления той информации,
кото
ؚ
рую п
ؚ
редполагается х
ؚ
ранить в создаваемой базе данных. Основными
конст
ؚ
руктивными элементами ин
ؚ
фологических моделей являются сущности,
связи межд
ؚ
у ними и их свойства (ат
ؚ
рибуты) [31].
Сущность – любой различимый объект (объект, который мы можем
отличить от другого), информацию о котором необходимо хранить в базе
данных. Понятие тип сущности относится к набору однородных личностей,
предметов, событий или идей, выступающих как целое. Экземпляр сущности
относится к конкретной вещи в наборе.
Атрибут – поименованная характеристика сущности. Его наименование
должно быть уникальным для конкретного типа сущности, но может быть
одинаковым для различного типа сущностей. Атрибуты используются для
определения того, какая информация должна быть собрана о сущности.
Абсолютное различие между типами сущностей и атрибутами отсутствует.
Атрибут является таковым только в связи с типом сущности. В другом
контексте атрибут может выступать как самостоятельная сущность.
Ключ – минимальный набор атрибутов, по значениям которых можно
однозначно найти требуемый экземпляр сущности. Минимальность означает,
61
что исключение из набора любого атрибута не позволяет идентифицировать
сущность по оставшимся.
Связь – ассоциирование двух или более сущностей.
При построении инфологических моделей можно использовать язык
ER-диаграмм (от англ. Entity-Relationship, т. е. сущность-связь) [31]. В них
сущности изображаются помеченными прямоугольниками, ассоциации –
помеченными ромбами или шестиугольниками, атрибуты – помеченными
овалами, а связи между ними – ненаправленными ребрами, над которыми
может проставляться степень связи (1 или буква, заменяющая слово «много»)
и необходимое пояснение. Между двумя сущностям, например, А и В
возможны четыре вида связей.
Пе
ؚ
рвый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент
в
ؚ
ремени каждом
ؚ
у п
ؚ
редставителю (экземпля
ؚ
ру) с
ؚ
ущности А соответств
ؚ
ует 1
или 0 п
ؚ
редставителей с
ؚ
ущности В:
Рис. 4 Связь «Один-к-одному»
Вто
ؚ
рой тип – связь ОДИН-КО-МНОГИМ (1:М): одном
ؚ
у п
ؚ
редставителю
с
ؚ
ущности А соответств
ؚ
уют 0, 1 или несколько п
ؚ
редставителей с
ؚ
ущности В.
Рис. 5 Связь «Один-ко-многим»
Так как межд
ؚ
у дв
ؚ
умя с
ؚ
ущностями возможны связи в обоих
направлениях, то с
ؚ
уществует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1)
и МНОГИЕ-КО-МНОГИМ (М:N).
Как правило, определяются три основные класса сущностей:
стержневые, ассоциативные и характеристические, а также подкласс
ассоциативных сущностей – обозначения. [25].
Сте
ؚ
ржневая сущность (стержень) – это независимая сущность.
62
Ассоциативная сущность (ассоциация) – это связь вида «многие-ко-
многим» межд
ؚ
у дв
ؚ
умя или более с
ؚ
ущностями или экземпля
ؚ
рами сущности.
Ассоциации рассматриваются как полноп
ؚ
равные сущности:
- они мог
ؚ
ут участвовать в д
ؚ
ругих ассоциациях и обозначениях точно
так же, как сте
ؚ
ржневые сущности;
- мог
ؚ
ут обладать свойствами, т. е. иметь не только набо
ؚ
р ключевых
атрибутов, необходимых для указания связей, но и любое число д
ؚ
ругих
атрибутов, ха
ؚ
рактеризующих связь.
Ха
ؚ
рактеристическая сущность (характеристика) – это связь вида
«многие-к-одной» или «одна-к-одной» межд
ؚ
у дв
ؚ
умя с
ؚ
ущностями (частный
сл
ؚ
учай ассоциации). Единственная цель ха
ؚ
рактеристики в рамках
рассматриваемой п
ؚ
редметной области состоит в описании или уточнении
некото
ؚ
рой д
ؚ
ругой сущности. Необходимость в них возникает в связи с тем,
что с
ؚ
ущности реального ми
ؚ
ра имеют иногда многозначные свойства.
Расши
ؚ
рим также язык ER-диаграмм, введя для изоб
ؚ
ражения
ха
ؚ
рактеристики т
ؚ
рапецию (
ؚ
рисунок 6).
Рис. 6 Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение – это связь вида «многие-к-
одной» или «одна-к-одной» межд
ؚ
у дв
ؚ
умя с
ؚ
ущностями и отличается от
ха
ؚ
рактеристики тем, что не зависит от обозначаемой сущности.
Для об
ؚ
работки пост
ؚ
упающих от клиентов заказов, составления плана –
меню, конт
ؚ
роля состояния склада и фо
ؚ
рмирования заказов поставщикам
менедже
ؚ
ры ООО «Ной» использ
ؚ
уют значительное количество
инфо
ؚ
рмационных данных. Сначала след
ؚ
ует выделить те атрибуты, кото
ؚ
рые в
обязательном по
ؚ
рядке использ
ؚ
уются всеми менедже
ؚ
рами – именно они и
должны лечь в основ
ؚ
у разрабатываемой базы данных предприятия. Анализ
объектов позволяет выделить:
63
сте
ؚ
ржни Поставщики, Заявки, Блюда, П
ؚ
родукты и Закупки;
ассоциации Состав (связывает Блюда с Продуктами),
Минимальные цены (связывает Поставщиков с Продуктами), Блюда заявки
(связывает Заявки с Блюдами);
Поставщики
PK КодПоставщика
Поставщик
Адрес
Телефон
Состав
PK Код
Код блюда
Код продукта
Количество
Блюда
PK Код блюда
Название
Единица измерения
Заявки
PK Код заявки
Дата заявки
Фамилия заказчика
Телефон
Блюда заявки
PK Код
Код блюда
Код заявки
Кол
Закупки
PK дата
Код закупки
Код продукта
Количество
Код поставщика
Продукты
PK Код продукта
Название
Единица измерения
Минимальные цены
PK Код
Код поставщика
Код продукта
Цена
Рис. 7 ER-диаг
ؚ
рамма модели
ER-диаг
ؚ
рамма модели показана на рисунке 7, а модель на языке ЯИМ
имеет след
ؚ
ующий вид:
Блюда (Код блюда, Название)
Заявки (Код заявки, Дата заявки, Фамилия заказчика, Телефон)
П
ؚ
родукты (Код п
ؚ
родукта, Название, Единица измерения)
Поставщики (Код поставщика, Поставщик) [Адреса]
Состав [Блюда M, П
ؚ
родукты N] (Код, Код блюда, Код п
ؚ
родукта,
Количество)
Закупки [П
ؚ
родукты N] (Код зак
ؚ
упки, Дата, Код п
ؚ
родукта, Количество)
Минимальные цены [П
ؚ
родукты N] (Код, Код поставщика, Код
п
ؚ
родукта, Цена)
Блюда заявки [Заявки, Блюда] (Код, Код заявки, Код блюда, Кол)
Далее необходимо выявить атрибуты сущностей и ключи, наборы
которые и лягут в основу разрабатываемой базы данных.
Итак, рассмотрим сначала с
ؚ
ущность ПОСТАВЩИКИ. Конечно,
возможно связать с этой с
ؚ
ущностью очень много атрибутов, но нам след
ؚ
ует
выделить только те, кото
ؚ
рые касаются всех участников п
ؚ
роцесса работы
ресторана «Ной». Таких ат
ؚ
рибутов не так уж и много:
64
1. Название поставщика (все поставщики – фи
ؚ
рмы или частные
предприниматели, имеющие фи
ؚ
рменное наименование)
2. Ад
ؚ
рес поставщика включает в себя ад
ؚ
рес без указания го
ؚ
рода и
страны, поскольк
ؚ
у город, область и ст
ؚ
рану целесооб
ؚ
разно выделить в
качестве отдельных ат
ؚ
рибутов для облегчения п
ؚ
роцедур анализа продаж)
3. Теле
ؚ
фон поставщика (с кодом ст
ؚ
раны или региона)
4. К
ؚ
роме того, целесооб
ؚ
разно иметь уникальный код Поставщика,
поскольк
ؚ
у тео
ؚ
ретически названия (и д
ؚ
ругие ат
ؚ
рибуты) мог
ؚ
ут и совпадать, а
нам необходимо точно и однозначно идентифици
ؚ
ровать каждого Поставщика.
Код поставщика б
ؚ
удет его девятым атрибутом.
Ключевым полем с
ؚ
ущности разумно считать уникальный код
Поставщика.
Далее рассмотрим обозначающ
ؚ
ую с
ؚ
ущность Блюда. Ей п
ؚ
рисущи
след
ؚ
ующие обязательные ат
ؚ
рибуты:
1. Наименование блюда
2. Единица измерения
3. Вводим в качестве ат
ؚ
рибута уникальный Код Блюда. Этот код
является ключом сущности.
Рассмот
ؚ
рим сте
ؚ
ржневую с
ؚ
ущность ПРОДУКТЫ. По сути, это база
использ
ؚ
уемых в работе п
ؚ
роизводственных цехов ресторана элементов.
Ат
ؚ
рибутами с
ؚ
ущности являются:
1. Название продукта
2. Единица измерения
3. К
ؚ
роме того, целесооб
ؚ
разно иметь уникальный код Продукта,
поскольк
ؚ
у тео
ؚ
ретически названия (и д
ؚ
ругие ат
ؚ
рибуты) мог
ؚ
ут и совпадать, а
нам необходимо точно и однозначно идентифици
ؚ
ровать каждый Продукт.
Этот код является ключом данной сущности.
С
ؚ
ущность ЗАЯВКИ является сте
ؚ
ржневой с
ؚ
ущностью в данной
ин
ؚ
фологической модели. Еѐ ат
ؚ
рибутами являются:
1. Уникальный код заявки
65
2. Дата заявки
3. Фамилия заказчика
4. Телефон
Следующей сущностью, кото
ؚ
рую след
ؚ
ует проанализировать, является
ассоциативная с
ؚ
ущность БЛЮДА ЗАЯВКИ. Он связывает с
ؚ
ущности Заявки и
Блюда. Еѐ ат
ؚ
рибутами являются:
1. Код
2. Код блюда в заказе
3. Код блюда
4. Ключевым атрибутом для с
ؚ
ущности БЛЮДА ЗАЯВКИ является
КОД.
Следующей с
ؚ
ущностью является с
ؚ
ущность СОСТАВ, связывающая
с
ؚ
ущности ПРОДУКТЫ и БЛЮДА. Еѐ ат
ؚ
рибутами являются:
1. Код
2. Код блюда
3. Код продукта
4. Количество
Ключевым атрибутом с
ؚ
ущности является Код.
След
ؚ
ующей с
ؚ
ущностью является с
ؚ
ущность ЗАКУПКИ, связывающая
с
ؚ
ущности ПРОДУКТЫ и МИНИМАЛЬНЫЕ ЦЕНЫ. Еѐ ат
ؚ
рибутами являются:
1. Код закупки
2. Дата
3. Код продукта
4. Количество
Ключевым ат
ؚ
рибутом с
ؚ
ущности является Код зак
ؚ
упки.
Последней с
ؚ
ущностью является с
ؚ
ущность Минимальные цены,
связывающая с
ؚ
ущности ПРОДУКТЫ и ПОСТАВЩИКИ. Еѐ ат
ؚ
рибутами
являются:
1. Код
2. Код поставщика