Файл: Систем управления.pdf

Проверка неравенств начинается с последнего (четвертого). Третье и четвертое неравенства выполняются, второе – нет; значит, необходимо скорректировать значения коэффициента С
2
. Примем значение С
2
= 2. Однако одновременно необходимо изменить значение C
1
таким образом, чтобы, во- первых, сохранился первоначальный порядок критериев, определенный экспертом, т. е. C
1
> C
2
, и, во- вторых, выполнялось первое неравенство. Принимаем, например, значение C
1
= 2,5. В результате применения метода последовательных предпочтений получили непротиворечивый ряд оценок (табл. 2.5
), которые в дальнейшем необходимо масштабировать.
Таблица 2.5
2.4.1.4. Оценка результатов экспертного анализа
При использовании всех рассмотренных выше методов возникает естественный вопрос: насколько можно доверять результатам оценки коэффициентов С
ij
, полученным из субъективных мнений экспертов? Достоверность результатов экспертного анализа чаще всего характеризуется степенью согласованности данных ими оценок. Для количественной оценки степени согласованности часто используется коэффициент конкордации [3]:
где
r
ij
– место, которое заняло i-e свойство в ранжировке j-м экспертом.
Коэффициент W позволяет оценить, насколько согласованы между собой ряды предпочтительности, построенные каждым экспертом. Его значение находится в пределах 0 ≤ W ≤ 1,причем W = 0означает полную противоположность, a W = 1 – полное совпадение ранжировок. Практически достоверность считается хорошей, если W = 0,7÷0,8.
На основе рассмотренных методов могут быть определены значения коэффициентов C
ij
(i = 1, 2, ...,
т; t = 1, 2, ..., n), по которым будут вычислены коэффициенты b
i
, линейной формы интегрального критерия. При использовании такого подхода к формированию интегрального критерия в дальнейшем считается, что единица измерения каждого свойства системы, отраженного в соответствующем частном критерии, выбрана по принципу «чем больше, тем лучше». Отсюда следует, что качество решения по выбору альтернативы тем лучше, чем больше значение показателя эффективности.
Так как критерии q
i
могут иметь различную размерность, то при использовании их в качестве аргументов функции Е необходимо провести нормирование, т. е. привести их к общей размерности, и в частности к безразмерному виду.
Для придания равномерности влияния каждого из критериев на значение интегрального критерия необходимо выровнять диапазоны изменения значений критериев путем масштабирования и сведения их к диапазону [0; 1].
Проведение преобразований типов нормирования и масштабирования требует, чтобы для каждого из критериев были определены понятия «негодного» и «идеального» объектов, а это означает, что должны быть заданы допустимые области изменений значений критериев q
i
, q
iн
< q
i
≤ q
iв
. В этом случае самым простым масштабирующим и нормирующим преобразованием является линейное преобразование следующего вида:
45

где q
i
отн
, q
iн
, q
iв
- относительное, нижнее и верхнее значения критерия q
i
соответственно.
В случае такого преобразования чувствительность шкалы изменения q
i
во всем диапазоне изменений
q
i
постоянна. Если же разработчика особенно интересуют альтернативы в окрестности некоторой точки
q
i
*, то можно повысить разрешающую способность частного критерия в окрестности этой точки за счет использования соответствующих нелинейных преобразований [3].
После проведения операций нормирования и масштабирования область годных альтернатив окажется заданной в виде n-мерного единичного куба, причем
В результате проведенных преобразований для каждой рассматриваемой альтернативы будет определен вектор q
отн
(a), причем а
∈
А, где А – множество возможных альтернатив. Оценка интегрального показателя решения по выбору альтернативы производится в соответствии со следующим соотношением:
Заканчивая рассмотрение вопросов, связанных с построением обобщенного критерия эффективности сложных систем на основе метода экспертных оценок, следует еще раз обратить внимание на то, что на многих этапах его построения приходится опираться на субъективные мнения специалистов при выборе:

наиболее существенных частных критериев;

процедуры и единицы измерения для критериев;

«идеального» значения критерия;

значения, дающего наибольшую разрешающую способность критерия;

нормирующего и масштабирующего преобразований;

структуры функции обобщенного критерия;

значений весовых коэффициентов.
Поэтому решения на каждом из перечисленных этапов должны приниматься на основе усредненного мнения многих специалистов, что повышает объективное содержание критерия. Однако это не исключает таких ситуаций, когда оценки некоторых реальных объектов, полученные с помощью обобщенного критерия, противоречат мнению специалистов. В подобных случаях следует не отказываться от дальнейшего использования данного подхода, а тщательно проанализировать и выявить конкретные причины расхождения, после чего внести соответствующие изменения в критерий.
Как указывалось выше, для оценки СУБД могут использоваться самые разнообразные параметры, которые могут быть сгруппированы следующим образом:

параметры определения данных;

физические параметры;

параметры доступности;

параметры обработки транзакций;

утилиты;

средства разработки... и т.д.
Рекомендуемые параметры (показатели) для оценки СУБД приведены в табл. 2.6 [7].
Таблица 2.6
Наименование группы
Наименование параметра
46

Определение данных
Расширенная поддержка первичных ключей
Определение внешних ключей
Предусмотренные типы данных
Расширяемость типов данных
Определение доменов
Простота реструктуризации
Средства поддержки целостности данных
Реализация механизма представлений
Поддержка словаря данных
Независимость данных
Тип базовой модели организации данных
Поддержка эволюции схемы
Физические параметры
Предусмотренные файловые структуры
Поддержка определения файловых структур
Простота реорганизации
Средства индексирования
Поля/записи с переменной длиной
Сжатие данных
Возможности шифрования
Требования к памяти
Требования к устройствам хранения данных
Доступность
Язык запросов: совместимость со стандартами SQL
Интерфейс для других систем
Интерфейс для языков третьего поколения
Многопользовательский доступ
Защита базы данных: управление доступом к данным, поддержка механизма авторизации
Обработка транзакций
Процедуры резервного копирования и восстановления
Поддержка контрольных точек
Средства ведения системного журнала
Поддерживаемый уровень детализации параллельности
Возможные стратегии разрешения тупиковых ситуаций
Поддержка усовершенствованных моделей управления транзакциями
Параллельная обработка запросов
Утилиты
Измерение производительности
Настройка производительности базы данных
Инструменты загрузки/выгрузки данных
Контроль активности пользователей
Поддержка процедур администрирования базы данных
Средства разработки
Инструменты, использующие языки четвертого и пятого поколений
Case-инструменты
Инструменты для работы с оконным инструментом
Поддержка хранимых процедур, триггеров и правил
Другие параметры
Способность к модернизации
47

Стабильность производителя СУБД
База пользователей
Обучение и поддержка пользователей
Взаимодействие с другими СУБД и прочими системами
Поддержка работы в Internet
Утилиты репликации
Возможности распределенной работы
Качество и полнота документации
Требуемая операционная система
Стоимость
Оперативная справочная система
Используемые стандарты
Управление версиями
Расширенная оптимизация запросов
Масштабируемость
Переносимость
Требуемое аппаратное обеспечение
Поддержка работы в сети
Объектно-ориентированные свойства
Поддержка двух- или трехуровневой архитектуры «клиент/сервер»
Производительность
Пропускная способность при обработке транзакций
Максимальное количество одновременно работающих пользователей
2.4.2. Даталогические модели данных
Модель данных – фиксированная система понятий и правил для представления структуры данных, состояния и динамики проблемной области в базах данных [12]. Как правило, задается языком определения данных и языком манипулирования данными. Примерами модели данных, получившими широкое распространение, являются модели данных сетевая, иерархическая, реляционная и др.
Модель данных состоит из трех компонент [11].
1. Структура данных для представления точки зрения пользователя на базу данных.
2. Допустимые операции, выполняемые на структуре данных. Они составляют основу языка данных рассматриваемой модели данных. Одной лишь хорошей структуры данных недостаточно. Необходимо иметь возможность работать с этой структурой при помощи различных операций языка определения данных и языка манипулирования данными. Богатая структура данных ничего не стоит, если нет возможности оперировать ее содержимым.
3. Ограничения для контроля целостности. Модель .данных должна быть обеспечена средствами, позволя ющими сохранять ее целостность и защищать ее.
Схема – это средство, с помощью которого определяется модель данных приложения. В действительности схема содержит не только модель данных: в ней присутствует также некоторая семантическая информация, относящаяся к конкретному приложению. В модели данных можно определить, например, что база данных будет хранить информацию об организациях и служащих.
Однако, тот факт, что данный служащий не может работать более чем в одной организации, отражает семантику приложения. Это семантическое ограничение должно выполняться для каждого отдельного экземпляра записи базы данных об этом служащем. Поддержка ограничений заданной модели данных в базе данных также является частью функций СУБД по обеспечению защиты и целостности.
Прежде, чем перейти к детальному и последовательному изучению реляционных систем БД, целесообразно ознакомиться с ранними СУБД [8]. В этом есть смысл по трем причинам: во-первых, эти системы исторически предшествовали реляционным, и для правильного понимания причин повсеместного перехода к реляционным системам нужно знать хотя бы что-нибудь про их предшественников; во-вторых, внутренняя организация реляционных систем во многом основана на использовании методов ранних систем; в-третьих, некоторое знание в области ранних систем будет полезно для понимания путей развития постреляционных СУБД. Подробный сравнительный анализ даталогических моделей приведен в прил. 3.
48

2.4.2.1. Иерархическая модель
Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи [8].
Пример типа дерева (схемы иерархической БД) представлен на рис. 2.19.
Рис. 2.19. Пример схемы иерархической БД
На рис. 2.19 ОТДЕЛ является предком для НАЧАЛЬНИК и СОТРУДНИКИ, а НАЧАЛЬНИК и
СОТРУДНИКИ - потомки ОТДЕЛ. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (рис. 2.20, показан один экземпляр дерева) [8].
Рис. 2.20. Реализация иерархической БД
Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами.
Для БД определен полный порядок обхода - сверху-вниз, слева-направо.
Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие [8].

Найти указанное дерево БД (например, отдел 42).

Перейти от одного дерева к другому.

Перейти от одной записи к другой внутри дерева (например, от отдела – к первому сотруднику).

Перейти от одной записи к другой в порядке обхода иерархии.

Вставить новую запись в указанную позицию.

Удалить текущую запись.
Автоматически поддерживается целостность ссылок между предками и потомками. Основное
правило: никакой потомок не может существовать без своего родителя. Заметим, что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается.
В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии. Примером представления приведенной выше БД может быть следующая иерархия (рис. 2.21) [8].
49

Рис. 2.21. Пример схемы иерархической БД
Экземпляр дерева базы данных не обязательно должен содержать все свои сегменты. При необходимости можно добавлять или удалять экземпляры типов записей в соответствии с требованиями приложения.
Иерархическая структура реализует отношение ОДИН-КО-МНОГИМ между исходным и порожденным типами записей. Это отображение полностью функционально, т.к. дерево не может содержать порожденный узел без исходного узла (за исключением «корня»). Следовательно, отображения ОДИН-К-ОДНОМУ и ОДИН-КО-МНОГИМ могут непосредственно представляться иерархическими структурами. Однако для представления отображения МНОГИЕ-КО-МНОГИМ необходимо дублирование деревьев, а значит, реализация сложных связей требует больших затрат памяти.
Другой проблемой иерархий является невозможность хранения в БД порожденного узла без соответствующего исходного, т.е. в этом случае необходимо ввести пустой исходный узел.
Соответственно удаление данного исходного узла влечет удаление всех порожденных узлов
(поддеревьев), связанных в ним. Эти ограничения создают проблемы применения иерархической модели для некоторых приложений.
2.4.2.2. Сетевая модель
Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков. С точки зрения теории графов сетевой модели соответствует произвольный граф (возможно имеющий циклы и петли). В узлах графа помещаются типы записей, а ребра интерпретируются как связи между типами записей.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи [8].
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка Р и типом записи потомка С должны выполняться следующие два условия:

каждый экземпляр типа Р является предком только в одном экземпляре L;

каждый экземпляр С является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации [8].

Простой пример сетевой схемы БД приведен на рис. 2.22.
Рис. 2.22. Пример схемы сетевой БД
Примерный набор операций при использовании сетевой модели может быть следующим [8].

Найти конкретную запись в наборе однотипных записей (инженера Петрова).

Перейти от предка к первому потомку по некою рой связи (к первому сотруднику отдела 42).

Перейти к следующему потомку в некоторой связи (от Петрова к Иванову).

Перейти от потомка к предку по некоторой связи (найти отдел Петрова).

Создать новую запись.

Уничтожить запись.

Модифицировать запись.

Включить в связь.

Исключить из связи.

Переставить в другую связь и т.д.
2.4.2.3. Реляционная модель
В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13:
6, June 1970), где, вероятно, впервые был применен термин «реляционная модель данных».
Будучи математиком по образованию Э. Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [2, 5, 7, 10].
Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 2.23 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос «Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву»). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?
Отношение на доменах D
1
, D
2
, ..., D
n
(не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 2.23 приведен пример отношения для расписания движения самолетов.
Заголовок состоит из такого фиксированного множества атрибутов A
1
, A
2
, ..., A
n
, что существует взаимно однозначное соответствие между этими атрибутами А
i
и определяющими их доменами Di (i = l,
2, ..., n).
Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою
51