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