35147

Информационные системы. Общие сведения

Книга

Информатика, кибернетика и программирование

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

Беларуский

2013-09-09

10.58 MB

8 чел.

83

1. Общие сведения об информационных системах

1.1. Обобщенная структура ИС

Информационная система в целом представляет собой систему, в которой выполняются информационные процессы всех основных разновидностей:

  •  извлечение информации;
  •  передача (транспортировка) информации;
  •  хранение информации;
  •  обработка информации;
  •  представление информации.

Следовательно, обобщенная структура ИС выглядит так:

Символами T обозначены модули, выполняющие передачу информации, P – модули, выполняющие обработку информации, M – модуль хранения информации.

К средствам извлечения информации относятся:

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

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

К средствам представления информации относятся:

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

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

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

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

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

1.2. Системы, ориентированные на работу с файлами

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

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

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

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

Пример

Рассматриваем задачу при двух упрощающих предположениях:

сотруднику начисляется заработная плана на основе его оклада;

никакие налоги и вычеты не учитываются.

Необходимые для решения этой задачи сведения о сотруднике представлены в следующей карточке НАЧИСЛЕНИЕ:

Фамилия Имя Отчество

FIO

Оклад

O

Количество отработанных дней в месяце

Ko

Начисленная сумма

S

Для каждого сотрудника соответствующие данные имеют конкретное значение, например:

Иванов Иван Иванович

1800

24

1800

В целях решения задачи кадрового учета обрабатываются сведения о сотруднике, представленные в карточке СОТРУДНИК:

Фамилия Имя Отчество

FIO

Должность

D

Год рождения

G

Оклад

O

Место

жительства

M

Обрабатываются сведения, представленные записями ЭКОНОМИЯ ФОТ:

Фамилия Имя Отчество

FIO

Оклад

O

Количество дней на больничном листе

Kдв

Невыплаченная сумма

SN

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

Назначение поля

Наименование поля

Длина, байт

Тип

ФИО

FIO

118

Строка

Оклад

O

4

Число с плавающей точкой

Количество отработанных дней в месяце

KO

2

Целое число

Начисленная сумма

S

4

Число с плавающей точкой

В синтаксисе языка C она будет выглядеть следующим образом:

typedef struct _PAY_ {

 char FIO [118];

 float OKLAD;

 int KO;

 float SUM;

} PAY;

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

Из приведенного примера очевидны основные недостатки ИС, ориентированных на использование файлов:

  1.  Разделение и изоляция данных.
  2.  Дублирование данных.
  3.  Зависимость от данных.
  4.  Несовместимость форматов файлов.
  5.  Ориентация на фиксированные запросы при необходимости быстрого увеличения количества приложений.

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

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

  1.  Приводит к неэкономному расходу временных ресурсов на повторный ввод информации.
  2.  Приводит к неэкономному расходу пространства носителя.
  3.  Необходимость одновременного обновления данных в нескольких файлах и опасность нарушения целостности данных. Если данные из приведенных в примере таблиц будут связываться по ФИО, то в случае изменения ФИО нужно будет вносить изменения во все файлы сразу. Если в результате ошибки программиста, некорректных действий пользователя или аппаратурного сбоя эти изменения выполнены не будут, то данные, например, кадрового учета и учета начислений «отвязываются» друг от друга.

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

  1.  Выполнить предварительный анализ ИС с целью выявления всех программных модулей, работающих с соответствующей таблицей.
  2.  Составить план тестирования выявленных программных модулей.
  3.  Переработать программные модули.
  4.  Выполнить отладку и тестирование.

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

  1.  Открывает файл со старой структурой.
  2.  Создает временный файл.
  3.  В цикле читает структуры из старого файла, копирует поля в новые структуры и сохраняет их во временном файле.
  4.  Удаляет старый файл (или сохраняет как резервную копию).
  5.  Сохраняет временный файл под именем старого.

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

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

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

1.3. Системы, работающие с базами данных

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

Это означает, что необходимо ввести некоторый промежуточный уровень. Необходимо, чтобы в программном обеспечении хранились только данные о структурах, которые изменяться не будут. Такими структурами и должны являться структуры описания данных. Из описания данных уже будет получена структура данных, с которой программное обеспечение может работать однотипно.

Так от понятия файлов данных переходят к понятию баз данных.

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

Описание данных называют словарем данных (data dictionary), а его элементы – метаданными (metadata) или данными о данных.

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

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

СУБД – программный комплекс поддержки интегрированной совокупности данных, предназначенный для создания, ведения и использования базы данных многими пользователями (прикладными программами).

Взаимодействие между прикладным ПО и СУБД реализуется с использованием специальных языковых и программных средств. К языковым средствам относят в первую очередь язык SQL (Structured Query Language). Этот язык содержит синтаксические конструкции, позволяющие:

  1.  Создавать БД и описывать ее структуру при помощи DDL SQL (Data Definition Language).
  2.  Выполнять манипуляции с данными, такие как добавление, удаление, изменение, выборка, при помощи DML SQL (Data Manipulation Language).
  3.  Выполнять управление доступом к данным при помощи DCL SQL (Data Control Language).
  4.  Выполнять усложненную программную обработку данных, в частности циклическую и условную обработку, при помощи PL SQL (Program Language).

К программным средствам СУБД относятся:

  •  оболочки, позволяющие вводить директивы SQL и просматривать результаты выполнения запроса;
  •  утилиты, позволяющие выполнять административные операции, такие как создание резервной копии БД и восстановление из нее;
  •  библиотеки, имеющие программный интерфейс для обращения к ним (API), которые позволяют программно использовать функциональные возможности СУБД.

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

Основными достоинствами БД и СУБД являются преодоления недостатков файлового подхода:

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

К недостаткам СУБД можно отнести следующие:

  1.  Снижение производительности работы для случаев локальной работы с данными.
  2.  Неуниверсальность поддерживаемых форматов данных.
  3.  Дополнительные затраты на этапе внедрения системы (аппаратура и СУБД).

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

Второй недостаток последовательно изживался в течение ряда лет и продолжает изживаться производителями СУБД. В ранних СУБД действительно можно было хранить данные ограниченного множества типов: целые, дробные, строки, даты. С течением времени набор поддерживаемых типов расширялся: BLOB, массивы и т.п.

2. Составные части информационной системы

2.1. Базы данных и их дополнительные возможности

Существует ряд определений понятия «База данных». Приведем наиболее распостраненные.

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

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

Поскольку ключевой особенностью СУБД является универсальность (независимость от данных и от предметной области), то одним из недостатков СУБД считают некоторую избыточность в работе с данными. Например, если в запросе не указать директивно набор полей таблиц, из которых производится выборка, будут выбраны все поля. Если не отфильтровать в запросе записи по условию, будут выбраны все записи.

Для минимизации последствий потенциальной избыточности разработан ряд дополнительных возможностей СУБД:

  1.  Опции DML SQL, охарактеризованные выше: возможность задавать условие выборки и набор выбираемых полей.
  2.  Представления.
  3.  Хранимые процедуры.
  4.  События.

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

Среди прочих достоинств представлений:

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

Хранимые процедуры также являются для пользователя и для разработчика прикладного ПО средством некоторого «сужения» универсальности СУБД, поскольку позволяют подачей одной команды выполнить достаточно сложную обработку данных.

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

2.2. Разновидности БД

По форме хранимой информации выделяют:

  •  фактографические БД;
  •  документальные БД;
  •  мультимедийные БД.

По типу используемой модели данных выделяют:

  •  иерархические БД;
  •  сетевые БД;
  •  реляционные БД.

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

По размещению выделяют:

  •  локальные;
  •  интегрированные;
  •  распределенные.

2.3. Формат БД

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

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

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

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

2.4. Типовые задачи СУБД. Функции СУБД

СУБД обеспечивает:

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

2.5. Состав СУБД и схема функционирования

ИС на базе СУБД подразумевает совместное использование пяти основных компонентов:

  •  аппаратное обеспечение;
  •  программное обеспечение;
  •  данные;
  •  процедуры;
  •  пользователей.

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

Используемое аппаратное обеспечение зависит, с одной стороны, от требований СУБД, с другой стороны – от требуемых характеристик ИС.

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

Одни СУБД предназначены для работы только с конкретными типами операционных систем или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными операционными системами.

Программное обеспечение ИС достаточно разнородно по составу. Оно включает в себя:

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

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

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

• Регистрация в СУБД.

• Использование отдельного инструмента СУБД или приложения.

• Запуск и останов СУБД.

• Создание резервных копий СУБД.

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

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

В структурном составе СУБД могут быть выделены ядро и среда.

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

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

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

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

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

Основные программные компоненты среды СУБД представлены на рисунке.

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

На рисунке 1 показаны следующие программные компоненты среды СУБД.

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

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

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

• Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.

Рисунок 1. Основные программные компоненты среды СУБД

• Компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация — в заголовках файлов с данными.

• Диспетчер словаря. Диспетчер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

Ниже перечислены основные программные компоненты, входящие в состав диспетчера базы данных (рисунок 2):

• Модуль контроля прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции.

Рисунок 2. Структура диспетчера БД

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

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

• Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса.

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

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

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

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

Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей нужны некоторые другие структуры данных, К ним относятся файлы данных и индексов, а также системный каталог. Группой DAFTG (Database Architecture Framework Task Group) была предпринята попытка стандартизации СУБД и в 1986 году предложена некоторая эталонная модель. Назначение эталонной модели заключается в определении концептуальных рамок для разделения предпринимаемых попыток стандартизации на более управляемые части и указания взаимосвязей между ними на очень широком уровне,

2.6. Разновидности СУБД

Как и БД, СУБД делятся по типу используемой модели данных на иерархические, сетевые и реляционные. По размещению выделяют серверные (клиент-серверные) СУБД и локальные СУБД.

Первые специализированные программы для хранения обработки данных стали появляться в конце 60-х, начале 70-х годов двадцатого века. СУБД помогала пользователям компьютеров организовывать и структурировать данные. Несмотря на то, что первые СУБД функционировали на больших ЭВМ (мэйнфреймах), с появлением персональных компьютеров активное использование БД и СУБД переместилось на них и стало доступным не только для индустриальных гигантов и исследовательских центров, но и для обычных пользователей (малый и средний бизнес, образовательные учреждения, предприятия бытовой сферы, муниципальные организации).

Настольные СУБД:

  •  FoxPro;
  •  Dbase;
  •  Paradox;
  •  MS Access.

Недостатки:

  •  низкая скорость работы с БД большого объема;
  •  плохая защищенность данных;
  •  ограниченная поддержка логики предметной области;
  •  и т.п.

Основным достоинством является экономичность.

Настольные СУБД применяются в первую очередь в случаях, когда количество пользователей ограничено 10-15 человеками, объемы данных невелики, риски невысоки. Некоторые из настольных СУБД обладают средствами реализации оконного интерфейса, средствами поддержки транзакций, средствами поддержки ограничений целостности.

Северные СУБД:

  •  Oracle;
  •  Sybase;
  •  Informix;
  •  Ingres;
  •  DB2;
  •  MS SQL Server.

2.7. Утилиты СУБД

Утилиты АБД образуют библиотеку программ обслуживания БД в привилегированном режиме (работа пользовательских средств одновременно с программами обслуживания не разрешена). Основные функции утилит АБД:

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

К средствам пользователя, поставляемым разработчиками СУБД, относятся:

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

2.8. Слои представления, обработки, доступа. Модели ИС

Рассматривая работу с данными с использованием СУБД, выделяют три основных слоя: управления данными (доступа), обработки, представления.

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

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

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

Функциональность слоев может быть различными способами распределена между аппаратными компонентами ИС (рисунок 3).

Рисунок 3. Варианты распределения функций между аппаратными компонентами ИС

Один из подходов к классификации способов распределения функциональности между слоями представлен на рисунке.

Вариант «Распределенное представление» наиболее адекватное воплощение находит в современных Web-технологиях, где функции управления данными реализуются SQL-сервером, функции обработки могут быть распределены между хранимыми процедурами SQL-сервера и Web-приложением, а представление формируется Web-сервером как динамический HTML-контент, который затем отображается тонким клиентом.

Вариант «Удаленное представление» соответствует двухзвенной клиент-серверной архитектуре, где вся предметная логика реализована в хранимых процедурах на сервере. Клиентское ПО выполняет только функции отображения информации и поддержки пользовательского ввода.

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

В варианте «Удаленный доступ к данным» на сервере выполняются только штатные общие функции работы с данными, а вся предметно-ориентированная обработка выполняется на клиенте.

Вариант «Распределенная БД» предполагает хранение БД как на клиенте, так и на сервере. Это могут быть или две реплики одной и той же БД или две различные БД, где, как правило, локальная БД представляет собой часть серверной. Этот вариант накладывает максимальные требования на аппаратуру клиента.

3. Архитектурные модели ИС

3.1. Персональная система (PSPersonal System)

Каждый пользователь имеет свою автономную персональную ЭВМ. База данных и СУБД копируется на компьютере каждого пользователя.

Каждый пользователь работает с базой данных на своей ЭВМ. Модель широко использовалась в начальный период появления персональных ЭВМ. Для модели характерна полная децентрализация данных. Основным недостатком модели является невозможность оперативного обновления данных на всех компьютерах при изменении из одним из пользователей.

3.2. Файл-серверная модель (FSFile-Server)

Рисунок 4. Файл-серверная модель

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

Работа построена следующим образом:

  •  База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
  •  Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
  •  На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
  •  Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
  •  СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
  •  При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
  •  Результат СУБД возвращает в приложение.
  •  Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов. В рамках архитектуры «файл-сервер» были выполнены первые версии популярных т.н. настольных СУБД, таких как dBase и Microsoft Access.

В литературе указываются следующие основные недостатки данной архитектуры:

  •  При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.
  •  Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Т.о. не оптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
  •  Как правило, используется навигационный подход, ориентированный на работу с отдельными записями.
  •  В БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и Dbase); подобная возможность облегчается тем обстоятельством, что, фактически, у таких СУБД база данных понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в отдельном каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.

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

3.3. Модель удаленного доступа (RDARemote Database Access)

Рисунок 5. Модель доступа к удаленным данным.

В RDA-модели коды компонента представления и прикладного компонента совмещены и выполнятся на компьютере-клиенте, который поддерживает как функции ввода и отображения данных, так и прикладные функции. Доступ к информационным ресурсам обеспечивается, как правило, операторами специального языка (например, SQL) или вызовами функций специализированной библиотеки API. С удаленным компьютером (например, сервером БД) ведется обмен запросами и блоками данных (рисунок 5).

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

Недостатки модели RDA могут рассматриваться только в сравнении с более эффективными моделями (не в сравнении с файл-серверной). К недостаткам относят большие объемы сетевого обмена, поскольку предметная обработка реализована на клиентской части, высокие требования к аппаратуре клиента и сложность модификации, поддержки и администрирования клиентского ПО.

3.4. Модель сервера БД (DBSDataBase Server)

Рисунок 6. Модель сервера базы данных.

В DBS-модели (рисунок 6) процесс, выполняемый на компьютере-клиенте, ограничивается функциями представления. Прикладные функции реализованы в хранимых процедурах (stored procedure). Они хранятся непосредственно в базе данных на сервере БД. Понятие информационного ресурса сужено до БД, поскольку механизм хранимых процедур имеется пока только в СУБД.

Достоинствами DBS-модели по сравнению с RDA являются: снижение нагрузки на сеть и на клиентское программное обеспечение, упрощение администрирования и поддержки за счет централизации.

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

3.5. Мэйнфреймовая модель (MFMainFrame)

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

3.6. Модель сервера приложений (AS – Application Server)

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

Новое понимание действительности привело к возникновению новых технологий, новых подходов к хранению и обработке данных. А в чем, собственно, проблема, чем архитектура «клиент-сервер» плоха для организации такой деятельности, как описано выше в примере?

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

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

Для разрешения описанных выше проблем появилось некоторое развитие архитектуры «клиент-сервер». На настоящий момент это развитие представляет собой так называемую трехзвенную (в некоторых случаях многозвенную) архитектуру (N-tier или multi-tier). Рассмотрев архитектуру «клиент-сервер», можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД.

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

Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей.

Итак, в результате работа построена следующим образом:

  •  База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
  •  СУБД располагается также на сервере сети.
  •  Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика).
  •  Существует множество клиентских компьютеров, на каждом из которых установлен т.н. «тонкий клиент» – клиентское приложение, реализующее интерфейс пользователя.
  •  На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.
  •  Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
  •  СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
  •  СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
  •  Сервер приложений возвращает результат в клиентское приложение (пользователю).
  •  Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

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

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

Транзакция является логической единицей работы с БД. Она может быть представлена одной командой, последовательностью команд или целой программой.

Транзакция – законченный блок обращений к ресурсу (БД) и некоторых действий над ним, описываемых последовательностью операторов ЯМД, которое рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. Пример: банковская транзакция по переводу средств со счета на счет.

Традиционные транзакции – ACID-транзакции – характеризуются четырьмя свойствами:

  1.  Атомарность (Atomicity). Операции транзакции образуют неделимый блок. Они или выполняются в совокупности или не выполняются вообще. В случае сбоя в процессе выполнения транзакции выполняется операция отката (rollback), т.е. отмены всех действий транзакции, возврата к исходному состоянию.
  2.  Согласованность (Consistency). Транзакция не нарушает согласованности данных. По завершении транзакции данные являются согласованными.
  3.  Изолированность (Isolation). Одновременный доступ транзакций к БД координируется таким образом, чтобы они не влияли друг на друга.
  4.  Долговечность (Durability). Если транзакция завершена успешно, то изменения, произведенные ей в данных, не могут быть потеряны, например, в случае последующих ошибок.

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

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

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

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

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

Рисунок 7. Структура модулей обработки транзакций

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

  1.  Проблема потерянного обновления. Возникает в случае, когда две параллельно выполняющиеся транзакции обращаются к одним и тем же данным и изменяют состояние одной и той же величины. При этом окончательное значение величины должно быть результатом суперпозиции действий этих транзакций, но вместо этого результат оказывается тождественным случаю, когда выполнялась только одна транзакция, несмотря на то, что вторая выполняется и завершается успешно. Пример: одновременное начисление и снятие денежных средств со счета. Проблемы можно избежать, если запретить каждой из этих транзакций считывать значение, изменяемое в этот момент другой транзакцией.
  2.  Проблема зависимости от незафиксированных результатов («грязного» чтения). Возникает, когда одна транзакция пользуется данными, сформированными в ходе выполнения другой транзакции, которая завершается откатом. Проблему можно устранить, если запретить первой транзакции пользоваться изменяемыми данными вплоть до фиксации второй транзакции.
  3.  Проблема анализа несогласованности. Возникает в случае, когда одна транзакция считывает данные, одновременно изменяемые другой. В сущности, является вариантом предыдущей проблемы. Решение аналогичное: запретить считывающей транзакции использовать изменяемые данные до фиксации изменяющей транзакции. Пример: перевод средств со счета на счет и подсчет суммы на счетах.
  4.  Проблема неповторяемого (нечеткого) чтения. Ситуация, близкая к двум предыдущим. Проявляется, когда одна транзакция дважды считывает одну и ту же величину, имеющую разные значения до и после изменений, выполненных другой транзакцией.
  5.  Проблема фантомного чтения. Характеризуется ситуацией, когда транзакция считывает набор строк, а при повторном считывании в нем появляются фантомные (дополнительные) строки, что также является результатом действий другой транзакции.

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

Основные методы доступа к данным:

  •  монопольный;
  •  коллективный.

Объектами доступа могут быть: БД, таблица, запись таблицы, поля записи таблицы. Если СУБД предполагает разработку, объектами доступа могут также быть спецификации отчетов, запросов и экранных форм.

Типовые ситуации использования монопольного доступа:

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

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

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

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

В распределенных БД используется технология двухфазной фиксации или двухфазной блокировки транзакций (2PC – 2-Phase Commit, 2PL – 2-Phase Lock). Она заключается в том, что сначала команды на изменения данных отправляются во все узлы, от всех узлов, где изменяются данные, запрашивается подтверждение блокировки, а затем эта блокировка подтверждается.

Первая фаза:

  1.  Управляющий сервер отправляет остальным серверам команды на изменение данных.
  2.  Серверы выполняют изменения данных и отправляют информацию о результатах изменения. Изменения на этом этапе обратимы.

Вторая фаза:

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

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

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

3.8. Децентрализованные (распределенные) системы

Системы распределенной обработки – системы, в которых выполняется многопользовательская распределенная работа с БД, размещенной на центральном компьютере.

Системы распределенных данных отличаются от систем распределенной обработки размещением БД (и других ресурсов) на различных ЭВМ сети.

Характерные свойства систем распределенных данных:

  1.  БД представляет собой логически связанные данные, разделяемые на некоторое количество фрагментов.
  2.  Фрагменты распределяются по разным узлам, которые связаны между собой сетевыми соединениями.
  3.  Может быть предусмотрена репликация фрагментов.
  4.  Доступ к данным на каждом узле происходит под управлением СУБД, которая на каждом узле должна поддерживать работу как локальных приложений, так и глобальных.

Основные условия и требования к распределенной обработке данных:

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

Ни одна из существующих СУБД не удовлетворяет этим требованиям в полной мере.

Типы распределенных СУБД:

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

Распределенная СУБД имеет функции, аналогичные функциям локальной СУБД, но расширенные по сравнению с ними.

Системы распределенных данных делятся на системы с фрагментацией (называемые также просто распределенными БД, Distributed Database) и системы с репликацией (тиражированные БД, Data Replication). Существуют также смешанные стратегии размещения данных.

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

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

Достоинство фрагментации в сравнении с репликацией состоит в экономном использовании ресурсов серверов (пространства носителей), что позволяет строить БД больших объемов.

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

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

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

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

4. Языковые и программные средства доступа к данным и реализации ИС

4.1. Языковые средства

К языковым средствам относятся языки, предназначенные специально для работы с БД и объединяемые термином «подъязык данных», поскольку не являются полноценными языками программирования. Термины ЯОД (язык определения данных), ЯМД (язык манипулирования данными) и т.п. являются достаточно общими, относящимися не только к реляционной модели, и вырабатывались еще в эпоху становления теории баз данных. Поскольку абсолютное большинство современных СУБД работают с реляционной моделью данных и пользуются языком SQL, то и языковые средства для них являются подмножествами языка SQL.

Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как COBOL, Fortran, Pascal, Ada, С, C++, Java или Visual Basic. В этом случае язык высокого уровня принято называть базовым или включающим языком (host language). Перед компиляцией файла программы на базовом языке, содержащей внедренные операторы подъязыка данных, такие операторы удаляются и заменяются вызовами функций программного интерфейса (API) клиентской части СУБД. Затем этот предварительно обработанный файл обычным образом компилируется с помещением результатов в объектный модуль, который компонуется с библиотекой, содержащей вызываемые в программе функции СУБД (клиентской библиотекой СУБД). После этого полученный программный текст готов к выполнению. Помимо механизма внедрения, для большинства подъязыков данных предоставляются также средства интерактивного выполнения операторов, вводимых пользователем непосредственно с терминала, т.е. некоторое пользовательское интерфейсное средство, предназначенное для интерактивного обмена запросами и ответами с сервером.

Язык определения данных (DDL, Data Definition Language) – язык, позволяющий описывать и именовать сущности и атрибуты БД.

Результатом компиляции набора операторов DDL, описывающих новую схему БД, является набор таблиц метаданных, хранящихся в системном каталоге.

Язык манипулирования данными (DML, Data Manipulation Language) соедржит набор операторов для выполнения следующих манипуляций:

  •  добавление (вставка) данных – INSERT;
    •  модификация данных – UPDATE;
    •  удаление данных из – DELETE;
    •  выборка данных – SELECT.

Существуют процедурные и непроцедурные языки DML. Непроцедурные (ЧТО-языки) позволяют декларировать требуемый результат операции манипуляции данными. Процедурные (КАК-языки) позволяют указать способ получения результата.

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

К непроцедурным (декларативным) DML относят языки, характерные для реляционных СУБД: DML SQL, QBE.

История языка SQL сопряжена с историей развития реляционных СУБД. Развитие концепции SQL началось с программной статьи сотрудника лаборатории фирмы IBM Е.Ф.Кодда 1970 г., в которой рассматривались и обосновывались основные положения реляционной модели. Язык SEQUEL был предложен его коллегой Д.Чемберленом в 1974 г. Его переработанная версия SEQUEL/2 была опубликована в 1976 г. Ее можно считать первой рабочей версией, поскольку с ее использованием была реализована СУБД System R, прототип которой был выпущен в том же 1976 г. Название SQL язык получил несколько позже по юридическим соображениям.

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

В то время были альтернативные реализации языка запросов для реляционных СУБД, однако именно SQL был избран ANSI и ISO в качестве основы для разработки стандарта, которая началась в 1982 г. Исходный вариант стандарта был выпущен в 1987 г. Он был подвергнут серьезной критике. Например, Дейт указывал, что в нем отсутствует ряд реляционных операторов и средства поддержки ссылочной целостности.

Дополнение к стандарту, содержащее функции поддержки ссылочной целостности, было выпущено в 1989 г. Его иногда называют SQL89. Первой окончательной версией стандарта считают SQL92 (SQL2). Следующая версия – SQL99 (SQL3).

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

SELECT [DISTINCT; [ ALL] .{ * | [columnExpression [AS newName]] [ ,  . . .  ] }

FROM TableName [alias] [ , . .  ]

. [WHERE condition].,

[GROUP BY columnList] [HAVING condition]

[QRDER BY columnList]

Здесь параметр columnExpression представляет собой имя столбца или выражение из нескольких имен. Параметр TableName является именем существующей в базе данных таблицы (или представления), к которой необходимо получить доступ. Необязательный параметр alias — это сокращение, устанавливаемое для имени таблицы TableName. Обработка элементов оператора SELECT выполняется в следующей последовательности:

  1.  FROM. Определяются имена используемой таблицы или нескольких таблиц.
  2.  WHERE. Выполняется фильтрация строк объекта в соответствии с заданными условиями.
  3.  GROUP BY. Образуются группы строк, имеющих одно и то же значение в указанном столбце.
  4.  HAVING. Фильтруются группы строк объекта в соответствии с указанным условием.
  5.  SELECT. Устанавливается, какие столбцы должны присутствовать в выходных данных.
  6.  ORDER BY. Определяется упорядоченность результатов выполнения оператора.

Порядок конструкций в операторе SELECT не может быть изменен. Только две конструкции оператора — SELECT и FROM — являются обязательными, все остальные конструкции могут быть опущены. Операция выборки с помощью оператора SELECT является замкнутой, в том смысле, что результат запроса к таблице также представляет собой таблицу (см. раздел 4.1). Существует множество вариантов использования данного оператора, что иллюстрируется приведенными ниже примерами.

Пример 1. Выборка всех столбцов и всех строк таблицы

SELECT *

FROM stuff

Пример 2. Выборка конкретных столбцов и всех строк таблицы

SELECT staffNo, lName, fName, salary

FROM stuff;

Пример 3. Использование ключевого слова DISTINCT

SELECT DISTINCT propertyNo

FROM viewing;

Пример 4. Использование вычисляемых полей

SELECT staffNo, lName, fName, salary/12 AS monthlySalary

FROM stuff;

Пример 5. Фильтрация

SELECT staffNo, lName, fName, salary

FROM stuff

WHERE salary > 10000;

SELECT *

FROM branch

WHERE city=’London’ OR city=’Glasgow’;

SELECT staffNo, lName, fName, salary

FROM stuff

WHERE salary BETWEEN 20000 AND 30000;

SELECT staffNo, lName, fName, salary, position

FROM stuff

WHERE position IN (‘Manager’, ‘Supervisor’);

SELECT clientNo, viewDate

FROM viewing

WHERE comment IS NULL;

Пример 6. Сортировка

SELECT staffNo, lName, fName, salary

FROM stuff

ORDER BY salary DESC;

Пример 7. Использование агрегирующих функций

SELECT COUNT(*) AS count

FROM propertyForRent

WHERE rent > 350;

Пример 8. Группировка

SELECT branchNo, COUNT(staffNo) AS count, SUM(salary) AS sum

FROM Staff

GROUP BY branchNo

ORDER BY branchNo;

Пример 9. Группировка с фильтрацией по результатам агрегирования

SELECT branchNo, COUNT(staffNo) AS count, SUM(salary) AS sum

FROM Staff

GROUP BY branchNo

HAVING COUNT(staffNo) > 1

ORDER BY branchNo;

Пример 10. Объединение результатов выборок

(SELECT city

FROM branch

WHERE city IS NOT NULL)

UNION

(SELECT city

FROM propertyForRent

WHERE city IS NOT NULL);

Пример 11 Пересечение результатов выборок

(SELECT city

FROM branch

WHERE city IS NOT NULL)

INTERSECT

(SELECT city

FROM propertyForRent

WHERE city IS NOT NULL);

Пример 12. Разность результатов выборок

(SELECT city

FROM branch

WHERE city IS NOT NULL)

EXCEPT

(SELECT city

FROM propertyForRent

WHERE city IS NOT NULL);

Оператор INSERT предназначен для вставки записей в таблицу. Синтаксис:

INSERT INTO TableName [(columnList)]

VALUES (valueList);

Здесь параметр TableName (Имя таблицы) может представлять либо имя таблицы базы данных, либо имя обновляемого представления (раздел 6.4). Параметр colunmList (Список столбцов) представляет собой список, состоящий из имен одного или более столбцов, разделенных запятыми. Параметр coIumnList является необязательным. Если он опущен, то предполагается использование списка из имен всех столбцов таблицы, указанных в том порядке, в котором они были описаны в операторе CREATE TABLE. Если в операторе INSERT указывается конкретный список имен столбцов, то любые опущенные в нем столбцы должны быть объявлены при создании таблицы как допускающие значение NULL — за исключением случаев, когда при описании столбца использовался параметр DEFAULT (раздел 6.3.2). Параметр dataValueList (Список значений данных) должен следующим образом соответствовать параметру columnList:

  1.  Количество элементов в обоих списках должно быть одинаковым;
  2.  Должно существовать прямое соответствие между позицией одного и того же элемента в обоих списках, поэтому первый элемент списка dataValueList считается относящимся к первому элементу списка columnList, второй элемент списка dataValueList — ко второму элементу списка columnList и т.д.;
  3.  Типы данных элементов списка dataValueList должны быть совместимы с типом данных соответствующих столбцов таблицы.

Пример.

INSERT INTO Staff (staffNo, fName, IName, position, salary, branchNo)

VALUES {'SG441' , 'Anne1' , 'Jones', 'Assistant', 8100, 'B003' } ;

Вторая форма оператора INSERT позволяет скопировать множество строк одной таблицы в другую. Этот оператор имеет следующий формат:

INSERT INTO  TableName [(columnList)]

SELECT

Здесь параметры TableName и columnList имеют тот же формат и смысл, что и при вставке в таблицу одной строки. Конструкция SELECT может представлять собой любой допустимый оператор SELECT. Строки, вставляемые в указанную таблицу, в точности соответствуют строкам результирующей таблицы, созданной при выполнении вложенного запроса. Все ограничения, указанные выше для первой формы оператора INSERT, применимы и в этом случае.

Пример.

Предположим, что существует таблица Staff PropCount, содержащая имена работников компании и учетные номера сдаваемых в аренду объектов, за которые они отвечают:

StaffPropCount (staff No, fNarie, IName, propCount)

Заполните таблицу staffPropCount данными, используя информацию из таблиц staff и PropertyForRent.

INSERT INTO StaffPropCount

(SELECT s.staffNo, fName, IName, COUNT(*)

FROM Staff s, PropertуForRent p

WHERE s.staffNo = p. staff No

GROUP BY s.staffNo, fName, IName)

UNION

(SELECT staffNo, fName, IName, 0

FROM Staff

WHERE staffNo NOT IN (SELECT DISTINCT staffNo

FROM PropertyForRent) ) ;

Этот пример достаточно сложен, поскольку нам требуется подсчитать количество сдаваемых в аренду объектов собственности, за которые отвечают работники компании. Если опустить вторую часть операции UNION, то будет создан список только тех работников компании, которые в настоящее время отвечают хотя бы за один объект. Иначе говоря, из результатов будут исключены все работники, которые в данный момент не отвечают ни на один сдаваемый в аренду объект. По этой причине для составления полного списка работников компании необходимо использовать оператор UNION, в котором второй оператор SELECT предназначен для выборки сведений именно о таких работниках, причем в столбец count соответствующих строк помещается значение 0. В табл. 5.41 представлено содержимое таблицы StaffPropCount после выполнения приведенного выше оператора.

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

UPDATE. TableName

SET columnNamel = dataValuel [,columnName2 = dataValue2 …]

[WHERE searchCondition]

Здесь параметр TableName представляет либо имя таблицы базы данных, либо имя обновляемого представления (см. раздел 6.4). В конструкции SET указываются имена одного или более столбцов, данные в которых необходимо изменить. Конструкция WHERE является необязательной. Если она опущена, значения указанных столбцов будут изменены во всех строках таблицы. Если конструкция WHERE присутствует, то обновлены будут только те строки, которые удовлетворяют условию поиска, заданному в параметре searchCondition. Параметры dataValuel, dataValue2... представляют новые значения соответствующих столбцов и должны быть совместимы с ними по типу данных.

Пример.

UPDATE Staff

SET position = 'Manager', salary = 18000

WHERE staffNo = 'SG14';

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

DELETE FROM TableName

[WHERE searchCondition]

Как и в случае операторов INSERT и UPDATE, параметр TableName может представлять собой либо имя таблицы базы данных, либо имя обновляемого представления (см. раздел 6.4). Параметр searchCondition является необязательным — если он опущен, из таблицы будут удалены все существующие в ней строки. Однако сама по себе таблица удалена не будет. Если необходимо удалить не только содержимое таблицы, но и ее определение, следует использовать оператор DROP TABLE (см. раздел 6.3.3). Если конструкция WHSRE присутствует, из таблицы будут удалены только те строки, которые удовлетворяют условию отбора, заданному параметром searchCondition.

Пример.

DELETE FROM Viewing

WHERE propertyNo = 'PG4';

Ниже перечислены основные операторы языка определения данных SQL.

CREATE SCHEMA

CREATE DOMAIN

CREATE TABLE

CREATE VIEW

ALTER DOMAIN

ALTER TABLE

DROP SCHEMA

DROP DOMAIN

DROP TABLE

DROP VIEW

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

CREATE INDEX

DROP INDEX

Каждая СУБД должна предоставлять механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи, которые имеют соответствующее разрешение. Язык SQL включает операторы GRANT и REVOKE, предназначенные для организации защиты таблиц в базе данных. Применяемый механизм защиты построен на использовании идентификаторов пользователей, предоставляемых им прав владения и привилегий.

Идентификаторы пользователей и права владения

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

Каждый созданный в среде SQL объект имеет своего владельца. Владелец задается идентификатором пользователя, определенным в конструкции AUTHORIZATION той схемы, которой этот объект принадлежит (см. раздел 6.3.1). Первоначально только владелец объекта знает о существовании данного объекта и имеет право выполнять с этим объектом любые операции.

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

В стандарте ISO определяется следующий набор привилегий:

• SELECT — право выбирать данные из таблицы;

• INSERT — право вставлять в таблицу новые строки;

• UPDATE — право изменять данные в таблице;

• DELETE — право удалять строки из таблицы;

• REFERENCES — право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;

• USAGE — право использовать домены, проверки, наборы символов и трансляции. Понятия проверок, наборов символов и трансляций не рассматриваются в этой книге. Заинтересованный читатель может обратиться к источникам, приведенным в [45].

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

Аналогичным образом, привилегия REFERENCES может распространяться только на отдельные столбцы таблицы, что позволит использовать их имена в формулировках требований защиты целостности данных (например, в конструкциях CHECK и FOREIGN KEY), входящих в определения других таблиц, тогда как применение для подобных целей остальных столбцов будет запрещено.

Когда пользователь с помощью оператора CREATE TABLE создает новую таблицу, он автоматически становится ее владельцем и получает по отношению к ней полный набор привилегий. Остальные пользователи первоначально не имеют каких-либо привилегий в отношении вновь созданной таблицы. Чтобы обеспечить доступ к ней, владелец должен явным образом предоставить им необходимые права, для чего используется оператор GRANT.

Когда пользователь создает представление с помощью оператора CREATE VIEW, он автоматически становится владельцем этого представления, однако совсем не обязательно получает по отношению к нему полный набор прав. Для создания представления пользователю достаточно иметь привилегию SELECT для всех входящих в данное представление таблиц и привилегию REFERENCES для всех столбцов, упоминаемых в определении этого представления. Но привилегии INSERT, UPDATE и DELETE в отношении созданного представления пользователь получит только в том случае, если он имеет соответствующие привилегии в отношении всех используемых в представлении таблиц.

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

GRANT {PrivilegeList | ALL PRIVILEGES}

ON ObjectName

TO {AuthorizationldList | PUBLIC}

[WITH GRANT OPTION]

Параметр PrivilegeList представляет собой список, состоящий из одной или более привилегий, разделенных запятыми:

SELECT

DELETE

INSERT [(columntfame [, ... ] ) ]

UPDATE [(columnWame [, ... ] ) ]

REFERENCES [(columntfame [, ... ])]

USAGE

Кроме того, для упрощения в операторе GRANT можно указать ключевое слово ALL PRIVILEGES, что позволит предоставить указанному пользователю все шесть существующих привилегий без необходимости их перечисления. В этом операторе можно также указать ключевое слово PUBLIC, означающее предоставление доступа указанного типа не только всем существующим пользователям, но и всем тем пользователям, которые будут определены в базе данных впоследствии. Параметр ObjectName может представлять собой имя таблицы базы данных, представления, домена, набора символов, проверки или трансляции.

Конструкция WITH GRANT OPTION позволяет всем указанным в списке параметра AuthorizationldList пользователям передавать другим пользователям все предоставленные им в отношении указанного объекта привилегии. Если эти пользователи также передадут собственные полномочия другим пользователям с указанием конструкции WITH GRANT OPTION, то последние, в свою очередь, также получат право передавать свои полномочия другим пользователям. Если эта конструкция не будет указана, получатель привилегии не сможет передать свои права другим пользователям. Таким образом, владелец объекта может четко контролировать, кто получил право доступа к объекту и какие полномочия ему предоставлены.

Примеры.

GRANT ALL PRIVILEGES

ON Staff

TO Manager WITH GRANT OPTION;

GRANT SELECT, UPDATE (salary)

ON Staff

TO Personnel, Director;

GRANT SELECT

ON Branch

TO PUBLIC;

В языке SQL для отмены предоставленных пользователям посредством оператора GRANT привилегий используется оператор REVOKE. С помощью этого оператора могут быть отменены все или некоторые из привилегий, предоставленных указанному пользователю раньше. Оператор REVOKE имеет следующий формат:

REVOKE [GRANT OPTION FOR] {PrivilegeList | ALL PRIVILEGES}

ON ObjectName

FROM {AuthorizationldList | PUBLIC} [RESTRICT | CASCADE]

Ключевое слово ALL PRIVILEGES означает, что для указанного пользователя отменяются все привилегии, предоставленные ему ранее тем пользователем, который ввел данный оператор. Необязательная конструкция GRANT OPTION FOR позволяет для всех привилегий, переданных в исходном операторе GRANT конструкции WITH GRANT OPTION, отменять возможность их передачи независимо от самих этих привилегий.

Назначение ключевых слов RESTRICT и CASCADE аналогично тому, которое они имеют в операторе DROP TABLE, рассмотренном в разделе 6.3.3. Поскольку для создания некоторых объектов необходимо наличие привилегий, в результате удаления привилегии пользователь может лишиться права, на основании которого им был создан тот или иной объект (подобные объекты, лишенные владельца, принято называть заброшенными). Выполнение оператора REVOKE будет отменено, если в результате могут появиться заброшенные объекты (например, представления), если только в нем не указано ключевое слово CASCADE. Если в операторе присутствует ключевое слово CASCADE, то для любых заброшенных объектов (представлений, доменов, ограничений или проверок), возникающих при выполнении исходного оператора REVOKE, будут автоматически выданы операторы DROP.

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

Пример.

REVOKE SELECT

ON Branch

FROM PUBLIC;

К языковым средствам относят также язык QBE (Query By Example – язык запросов по образцу), который фактически не является стандартизированным языком с определенным синтаксисом, а служит неким обобщенным обозначением для средств интерактивного формирования запросов.

В качестве примера QBE можно рассмотреть реализацию его в MS Access.

Для создания запросов в MS Access используется ряд конструкторов (визардов), позволяющих выбрать тип формируемого запроса и выполнить начальные настройки. Детальная настройка запроса выполняется в сетке QBE. Каждый столбец сетки соответствует полю результата запроса. Поля отбираются из числа доступных полей таблиц, отобранных предварительно.

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

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

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

4.2. Программные средства ИС

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

  1.  SQL-сервер (например, для СУБД Firebird это исполняемый файл fbserver.exe и комплект библиотек к нему).
  2.  Универсальная клиентская часть СУБД (например, для СУБД Firebird это клиентская библиотека fbclient.dll).
  3.  Утилиты СУБД административного и сервисного назначения (например, для СУБД Interbase/Firebird это средства интерактивного формирования запросов isql и wisql, утилита IBAdmin).
  4.  Системные библиотеки, обеспечивающие сетевой обмен по протоколам вплоть до транспортного уровня.
  5.  Системные библиотеки, обеспечивающие межпрограммный обмен на верхних уровнях модели OSI.
  6.  Программные средства обслуживания аппаратуры (например, аппаратуры связи, аппаратуры сбора данных).

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

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

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

Для разработки различных компонентов ИС могут применяться инструментальные средства различного назначения. Например, для формирования структуры БД могут применяться только встроенные средства СУБД. В этом случае сценарий (скрипт) создания БД создается вручную в виде текстового файла, содержащего набор инструкций DDL SQL, и затем запускается при помощи встроенного средства СУБД, такого, например, как isql/wisql. Для разработки прикладного программного обеспечения применяются универсальные средства разработки и языки программирования общего назначения.

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

Например, для проектирования БД уже в течение некоторого времени используются средства типа ERWin (а также, например, упомянутый IBAdmin). Они позволяют выполнить моделирование и проектирование БД в виде диаграмм «сущность-связь» (Entity-Relationship), а затем сгенерировать скрипт и отправить его на выполнение СУБД для формирования БД. Проект БД при этом сохраняется, может дорабатываться, и руинные операции по формированию новой структуры БД практически не зависят по временным затратам от сложности БД, поскольку выполняются автоматически.

Для проектирования прикладного программного обеспечения используются средства разработки проектной документации в стандартизированных нотациях, таких, например, как UML, позволяющих выполнить визуальное описание структуры классов и принципов взаимодействия объектов программного обеспечения. На основе полученных описаний могут быть автоматически получены заготовки исходных кодов программного обеспечения. Например, использование пакета Rational Rose позволяет получить набор диаграмм классов, диаграмм последовательности, взаимодействия, активности, состояний, затем сформировать набор файлов с исходными кодами на требуемом языке программирования. При ориентации на язык C++, например, получается набор пар файлов с расширениями CPP и H, содержащих заготовки программного кода, который далее дорабатывается разработчиками с использованием средств разработки общего назначения, таких, например, как Borland C++ Builder. Значение средств автоматизации проектированяи, хранения и сопровождения проектной документации тем больше, чем больше масштаб разработки.

Во многих случаях от использования отдельных средств, предназначенных для выполнения отдельных этапов проектирования и разработки, переходят к использованию интегрированных сред, позволяющих объединить в рамках одной платформы и средства коллективной работы, и средства проектирования БД, и средства проектирования ПО, и средства разработки. Например, такие среды, как Eclipse, позволяют внедрять в себя пакеты для разработки на различных языках программирования, проектирования компонентов ИС с использованием различных нотаций.

Отдельно можно отметить использование программных средств, ориентированных на работу с персональными СУБД. Это такие средства, как MS FoxPro, MS Access. Эти средства содержат в себе возможности SQL, QBE и встроенный язык программирования. Недостатком их является функциональная ограниченность, т.е. они ориентированы только на построение компактных ИС, использующих БД.

5. Технологии обмена между составными частями ИС и внешней средой

5.1. API

Использование программного интерфейса приложения (API — Application Programming Interface). Альтернативный вариант состоит в предоставлении программисту стандартного набора функций, к которым можно обращаться из создаваемых им программ. API-интерфейс предоставляет тот же набор функциональных возможностей, что и при использовании встроенных операторов, но при этом устраняется необходимость предкомпиляции исходного текста. Кроме того, некоторые разработчики указывают, что в этом случае используется более понятный интерфейс и созданный программный текст более удобен с точки зрения его сопровождения.

Технология использования API следующая. Разработчик СУБД предоставляет библиотеки (статической компиляции LIB или динамического связывания DLL). Такая библиотека располагается на клиентском месте. Ее же использует разработчик. Прикладные программные модули используют функции библиотеки. Т.е. статическая библиотека подключается к проекту прикладного ПО в процессе разработки, и ее функции можно использовать непосредственно, как функции библиотек средства разработки. Использование динамических библиотек несколько сложнее, поскольку программа должна содержать вызовы функций подключения библиотеки, получения адресов функций в ней по их именам, и наконец, вызовы самих функций.

Например, библиотеки сервера Interbase содержат следующие функции для работы с БД:

isc_attach_database – подключение БД;

isc_detach_database – отключение от БД;

isc_dsql_execute_immediate – выполнение SQL-инструкции;

isc_start_transaction – начало транзакции;

isc_commit_transaction – фиксация транзакции;

isc_dsql_fetch – получение очередной записи результата выполнения запроса.

5.2. ODBC

Одним из наиболее широко известных API-интерфейсов является ODBC (Open Database Connectivity — открытый интерфейс доступа к базам данных). Он является универсальным интерфейсом

Чтобы практически реализовать унифицированный доступ к разным СУБД посредством разных сетевых протоколов, в ОDВС каждой паре СУБД/протокол соответствует свой DLL-драйвер.

ODBC-архитектура включает в себя:

Приложение. Обрабатывает данные, вызывает ODBC-функции для выполнения SQL-инструкций, получает результаты.

Менеджер драйверов. Загружает драйверы по запросу приложений.

Драйверы. Обрабатывают вызовы ODBC-функций, передают SQL-инструкции конкретным СУБД и возвращают результаты приложениям. При необходимости модифицируют SQL-инструкции и результаты, если того требует специфика СУБД.

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

Рисунок 8. Архитектура ODBC

ODBC опирается на спецификацию SQL CLI (Call Level Interface), входящую в стандарт SQL. Интерфейс ODBC API реализован как набор DLL-библиотек под Windows. Библиотека ODBC.dll содержит функции вызовов специализированных драйверов для различных БД.

5.3. BDE

История

В 1990-м году Borland приобрел компанию Ashton-Tate, а вместе с ней и dBase (и Interbase). Таким образом у Borland появилось две настольные СУБД, с совершенно разными форматами - dBase и Paradox. Понятно, что для дальнейшего развития этих продуктов усилия по развитию форматов данных и работы с ними фактически удваивались. И в частности поэтому было принято решение создать некое универсальное ядро доступа к данным, которое могло бы работать с несколькими форматами данных единым образом. Созданию такого ядра также способствовало появление Windows, а следовательно и разделяемых библиотек - DLL. Можно было выпускать несколько продуктов, используя одни и те же dll доступа к данным. Это вполне соответствовало объектно-ориентированной концепции разработки ПО, которая не только использовалась в Turbo Pascal и в Turbo C++, но и при разработке собственных приложений Borland, таких как dBase, Paradox и Quattro (все для Windows).

Технология была названа Open Database Application Programming Interface - ODAPI, и впервые была использована в Quattro Pro 1.0 for Windows в сентябре 1992 года. В январе 1993-го эта же версия ODAPI 1.0 была использована в Paradox 1.0 for Windows, а затем и в dBase 1.0 for Windows. ODAPI пока поддерживал только форматы dBase и Paradox, и мог выполнять запросы к обоим форматам при помощи механизма Query By Example (QBE), пришедшего из Paradox for DOS.

справка: драйверы ODBC 1.0 от Microsoft впервые появились в августе 1993 года. Информация из MSDN.

Всего через полгода, в сентябре 1993, ODAPI 1.1 уже поддерживала работу с SQL-серверами Interbase, Oracle, Sybase и Microsoft.

Версия 2.0 была переименована в IDAPI (слово Open было заменено на Integrated), и работами по расширению и стандартизации этого интерфейса уже занимался не только Borland, а целый комитет с IBM, Novell и Wordperfect включительно. В этой версии появился Local SQL - ядро для выполнения запросов SQL к локальным форматам данных, и IDAPtor - механизм для подключения ODBC-драйверов к IDAPI.

Последняя 16-ти разрядная версия IDAPI 2.5 использовалась в Delphi 1. Далее, начиная с 3.0 (12 января 1996 года в составе Paradox 5.0 for Windows), пошли 32-разрядные версии. Собственно, на этом развитие функциональности BDE закончилось. Добавлялись новые драйверы для доступа к SQL-серверам DB2, Informix, в BDE 3.5 появились кэшированные обновления (CachedUpdates), появился драйвер FoxPro и сопряжение с DAO, но все это происходило на протяжении достаточно длительного срока - с 1996 по 2000.

С одной стороны, функциональность BDE можно назвать даже избыточной. С другой стороны повлияла конкуренция со стороны Microsoft, стандарта ODBC. Собственно, по функциональности ODBC является подмножеством BDE, но Microsoft в те годы предпринимала очень активные действия по продвижению ODBC, и главным в этом был выпуск ODBC SDK, с помощью которого любая фирма могла разработать собственный ODBC-драйвер (надо сказать, что в те годы их было огромное количество, причем большинство было весьма низкого качества и невысокой производительности). А BDE был более "закрытым". Например, BDE SDK так и не увидел свет, однако, эксперты, принимавшие участие в его тестовом использовании, оценивали его высоко. С третьей стороны, к этому времени WordPerfect был куплен Novell, Paradox также был продан Novell, а затем Corel, а IBM, по-видимому, исключила IDAPI из перечня первых приоритетов. В результате комитет IDAPI распался, и развивающийся продукт Microsoft ODBC остался без конкуренции со стороны IDAPI.

Несмотря на перечисленные негативные моменты, BDE активно использовался не только самим Borland, но и многими другими фирмами. Это Novell (продукт InForms), ReportSmith (впоследствии купленный и проданный Borland), CrystalReports (вплоть до версии 5.0 использовал BDE) и так далее.

Архитектура

Назначение библиотек BDE – предоставить универсальное ядро доступа к локальным форматам данных и обеспечить прозрачную работу приложений как с локальными форматами, так и с SQL-серверами. Именно удобство при работе с SQL-серверами посредством BDE вызывала наибольшее количество нареканий. Архитектура BDE изображена на рисунке 9.

Рисунок 9. Архитектура BDE

Основная работа с BDE производится посредством внешнего интерфейса IDAPI (IDAPI32.DLL). Формат данных выбирается в псевдониме (alias) соединения, и в принципе дальше работа с разными форматами ничем не отличается. В том числе и неважно, как работает приложение с BDE – через компоненты VCL DB, которые используют функции BDE, или напрямую (все равно компоненты используют те же функции BDE).

Дальше функции IDAPI транслируют вызовы в функции соответствующего драйвера. Если это драйвер локального формата (dBase, Paradox, FoxPro), то драйвер формата сам работает с соответствующими файлами (таблицами и индексами). Если это SQL Link, то вызовы транслируются в вызовы функций API клиентской части конкретного SQL-сервера. Для каждого сервера SQL Link свой.

IDAPTOR (соединитель с ODBC) и интерфейс к DAO работает точно также как и SQL Link, т.е. просто транслирует вызовы BDE в вызовы ODBC или DAO, непосредственно к формату не имея никакого отношения.

Если посмотреть на файлы BDE, то можно подробно рассмотреть его составные части.

IDAPI32.DLL - основной интерфейс

BLW32.DLL, BANTAM.DLL- языковые функции

*.BTL - файлы с языковыми кодировками.

IDBAT32.DLL - операции пакетного копирования данных

IDDR32.DLL - модуль работы с Data Repository

IDASCI32.DLL - драйвер для работы с текстовым форматом

IDDAO32.DLL - драйвер трансляции вызовов к DAO

IDODBC32.DLL - драйвер трансляции вызовов к ODBC

IDPDX32.DLL - драйвер для работы с форматом Paradox

IDDBAS32.DLL - драйвер для работы с форматом dBase и FoxPro

IDQBE32.DLL - ядро обработки запросов QBE

IDSQL32.DLL - ядро обработки запросов SQL

SQLINT32.DLL - SQLLink-драйвер трансляции вызовов к Interbase API

SQLORA32.DLL - SQLLink-драйвер трансляции вызовов к Oracle Call Level Interface

SQL*32.DLL - другие SQLLink-драйверы

Таким образом, при установке BDE можно оставить только те файлы, которые необходимы для взаимодействия с конкретным сервером.

Очевидно, что BDE не является эквивалентной заменой клиентской части СУБД, а работает только с библиотеками клиентской части. Аналогично, без установленных библиотек DAO BDE не будет работать с MS Access. Вообще клиентские части SQL-серверов несовместимы между собой абсолютно. Поэтому невозможно написать универсальный SQL Link.

На использование библиотеки BDE рассчитан набор компонентов, входящих в средства разработки Borland. В частности:

TDatabase – компонент для подключения к БД;

TTransaction – компонент для управления транзакциями;

TSQLMonitor – компонент для мониторинга запросов, формируемых к BDE;

TTable – компонент для обращения к таблице;

TQuery – компонент для выполнения запроса.

5.4. Специализированные компоненты для доступа к SQL-серверам

Существует ряд библиотек компонентов, предназначенных для использования со штатными средствами разработки (Borland Delphi, Borland C++Builder и т.п.), функционально аналогичных BDE, но не обладающих такой универсальностью. Т.е. каждая из таких библиотек представляет собой «обертку» вокруг функций API соответствующей клиентской библиотеки SQL-сервера, позволяющую выполнять работу с БД на уровне объектов. Преимуществом таких библиотек является максимальная ориентация на конкретный SQL-сервер, что позволяет:

  1.  Экономить ресурсы (оптимизировать запросы, не использовать дополнительные прослойки).
  2.  Использовать технологические преимущества SQL-сервера.

Недостаток подхода очевиден – неуниверсальность библиотек приводит к возможности их использования только с одним SQL-сервером (семейством).

Примеры: IBX, FIBPlus – библиотеки для работы с Interbase, Firebird, Yaffil; DOA – библиотека для работы с Oracle.

5.5. OLE, COM, DCOM, ActiveX, ADO, MTS, COM+

Названное семейство протоколов и стандартов разработки Microsoft представляет собой единую технологическую линейку, развиваемую в течение ряда лет с постепенным наращиванием функциональности (поддержка удаленного взаимодействия, поддержка транзакционного взаимодействия, поддержка объектно-ориентированного доступа к базам данных, поддержка интернет-технологий, поддержка распределенных транзакций и т.п.). Основой этих технологий является технология RPC (Remote Procedure Call – вызов удаленных процедур).

Основные идеи, реализованные в RPC:

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

Впервые пакет RPC был реализован компанией Sun Microsystems в 1984 г. в рамках ее продукта NFS (Network File System - сетевая файловая система). Независимость от конкретного машинного представления данных обеспечивается отдельно специфицированным протоколом XDR (External Data Representation - внешнее представление данных). Этот протокол определяет стандартный способ представления данных, скрывающий такие машинно-зависимые свойства как порядок байтов в слове, требования к выравниванию начального адреса структуры, представление стандартных типов данных и т.д. По существу, XDR реализуется как независимый пакет, который используется не только в RPC, но и в других продуктах (например, в NFS).

Несколько позже другая версия RPC была разработана консорциумом Open Software Foundation в рамках спецификации Distributed Computing Environment (OSF DCE). RPC, совместимый с OSF RPC, был независимо реализован Microsoft в средах Windows.

Интерфейс взаимодействия между клиентской и серверной частями описывается на языке IDL (Interface Definition Language). Компилятор транслирует описание интерфейса в заглушку (суррогат) клиента (client stub). Формируемый при этом заголовок интерфейса включается в приложение клиента. Заглушка клиента, к которой обращается приложение клиента, оформляет вызов удаленной процедуры. Функции библиотеки RPC формирует из параметров вызова пакет, который доставляется через протоколы RPC функции приема аналогичной библиотеки на стороне сервера. Библиотека RPC на серверной стороне распаковывает параметры и передает их заглушке сервера (server stub). Заглушка сервера формирует локальный вызов сервера (см. рис. 10). Заглушка сервера и заголовок интерфейса, используемый серверным приложением, компилируются для платформы сервера.

RPC основывается на сетевых протоколах, таких, как TCP/IP, и соответствует 5-му уровню модели OSI – сессионному. XDR соответствует 6-му уровню –уровню представлений.

Рисунок 10. Архитектура RPC

Классическим подходом к реализации процедурного взаимодействия является синхронный. Это означает, что клиент ожидает завершения взаимодействия, инициализированного им. В пакете ONC+ (Sun Microsystems) реализовано асинхронное взаимодействие. Аналогичный принцип реализован в CORBA-2. Асинхронное взаимодействие усложняет реализацию программного обеспечения.

Связь программы-клиента с программой-сервером осуществляется путем обращения к порту («конечной точке»). В DCE на каждой серверной машине функционирует приложение DCE-демон, поддерживающее таблицу пар порт-сервер. Сервер при создании должен запросить у ОС порт, а затем зарегистрировать этот порт у DCE-демона.

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

Объектно-ориентированная реализация RPC имеет свои особенности. Основной из них является использование т.наз. интерфейсов вместо заглушек общего назначения, предназначенных для вызова процедур. В ООП обращение к объекту любого грамотно реализованного класса осуществляется через интерфейс, представляющий собой набор методов, изменяющих или возвращающих свойства объекта. Заглушка при ОО реализации RPC имеет вид такого интерфейса. Причем одному интерфейсу могут соответствовать различные объекты, в том числе различных классов, а одному классу – насколько интерфейсов. Это создает дополнительный уровень абстрагирования.

В объектной реализации DCE (технологии распределенных объектов) поддерживаются два типа распределенных объектов: динамические распределенные объекты (distributed dynamic objects) и именованные распределенные объекты (distributed named objects). Экземпляр динамического объекта создается сервером при каждом обращении к нему клиента. Именованные объекты создаются сервером однократно и используются несколькими клиентами совместно в результате получения каждым клиентом ссылки на объект при обращении к нему.

Для передачи сообщений в среде Windows фирмой Microsoft была первоначально разработана технология DDE (Dynamic Data Exchange – динамический обмен данными), основанная на передаче системных сообщений и обратных вызовах. Первая версия технологии OLE (Object Linking and Embedding – связывание и внедрение объектов) была основана на DDE. OLE2 использует механизм LRPC (Lightweight RPC – облегченный вызов удаленных процедур). Технология использования LRPC в OLE2 была названа COM (Component Object Model – компонентная модель объектов). Первоначально основное использование OLE было сосредоточено в области связывания и внедрения объектов, созданных в одних приложениях, в документы, созданные в других. Сейчас наибольший интерес представляет обмен между приложениями, в частности удаленными, основанный на COM. В DCOM (Distributed COM) вместо LRPC используется RPC. LRPC, несмотря на название, предназначен только для локального вызова процедур.

COM-интерфейс удовлетворяет следующим требованиям:

  •  имеет уникальный идентификатор;
  •  является производным от интерфейса IUnknown;
  •  не изменяется после публикации.

Каждый OLE-объект имеет некоторое количество интерфейсов, через которые производится обращение к его методам. Обычно интерфейсы объекта объединяют функционально близкие методы, например, интерфейс печати, вычислительный интерфейс и т.д. Любой интерфейс имеет обязательные методы QueryInterface, AddRef и Release, предназначенные соответственно для получения указателя на интерфейс, инкремента и декремента счетчика ссылок на объект. Каждый объект имеет интерфейс IUnknown, через функцию QueryInterface которого можно получить указатели на прочие интерфейсы.

Обращение к объектам и их интерфейсам в COM производится при помощи GUID (Globally Unique Identifier –глобальных уникальных идентификаторов – 16-байтовых чисел). GUID объекта (класса) называется CLSID, GUID интерфейса – IID. При обращении к объекту Windows ищет в реестре запись, нумерованную его CLSID, и запускает сервер, указанный в поле LocalServer этой записи.

Для использования DCOM на стороне клиента должен быть установлен (зарегистрирован в реестре) агент сервера. Удаленное взаимодействие реализуется следующим образом:

  1.  Приложение-клиент вызывает через OLE приложение-сервер.
  2.  OLE получает из реестра при помощи CLSID имя приложения агента сервера и вызывает его. Клиент после этого взаимодействует с агентом как с сервером.
  3.  Агент использует механизм RPC, т.е. передает ему в унифицированном формате CLSID сервера и параметры вызова.
  4.  RPC передает все это на сторону сервера.
  5.  RPC на стороне сервера распаковывает CLSID и параметры и запускает через OLE сервер.
  6.  OLE получает из реестра при помощи CLSID имя приложения сервера и вызывает его.

Рисунок 11. DCOM

В COM+ были реализована возможность отмены вызова и модель асинхронных вызовов. При выполнении синхронного обращения создается объект отмены, имеющий метод Cancel. Этот метод может быть вызван из другого потока на клиентской стороне с передачей в качестве параметра идентификатора заблокированного клиентского потока. Асинхронные вызовы реализуются путем использования методов Begin_m и Finish_m, генерируемых компилятором MIDL (Microsoft IDL), где m – имя метода интерфейса. Эти методы позволяют клиенту соответственно передать входные параметры серверу и получить выходные параметры. После выполнения метода Begin_m клиентский поток продолжает свою работу. Результаты выполнения его запроса буферизируются и получить их он может в любой момент путем обращения к методу Finish_m.

Пакеты MTS – это наборы COM-классов, выполняющих связанные функции. Типы пакетов MTS: пакеты библиотек и серверные пакеты. Пакеты библиотек запускаются в рамках процесса клиента, использующего их COM-классы. Серверные пакеты выполняются как отдельные процессы под управлением MTS.

Физически пакет – это набор библиотек и элементов каталога MTS, в котором хранится информация о пакетах, компонентах, интерфейсах, ролях и т.д.

Перенос пакетов осуществляется в текстовом файле с расширением .pak. Такой файл содержит все элементы каталога, относящиеся к пакету, его ролям, компонентам и интерфейсам, а также ссылки на библиотеки, по которым утилита администрирования MTS находит библиотеки и регистрирует их. Пакетные компоненты реализуются в виде DLL. В них должна присутствовать функция DllRegisterServer, регистрирующая CLSID, ProgID, интерфейсы и библиотеки типов компонента.

В MTS и COM+ поддерживаются автоматические транзакции (automatic transactions). Автоматические транзакции позволяют разработчику определить набор из одного или более обращений к методам, в том числе различных объектов, которые нужно объединить в транзакцию. Каждый объект класса имеет атрибут транзакции, который определяет поведение этого объекта в транзакции:

Значение

Описание

REQUIRED_NEW

При каждом обращении всегда начинается новая транзакция, даже если вызывающий клиент начал транзакцию раньше

REQUIRED

Новая транзакция начинается, если она еще не начата

SUPPORTED

Включается в транзакцию, если она начата клиентом, в противном случае не начинает ее

NOT_SUPPORTED

Никогда не включается в транзакции

DISABLED

Никогда не включается в транзакции, даже если клиент пытается это сделать

5.6. CORBA

CORBA была разработана консорциумом OMG (Object Management Group). Основные принципы функционирования CORBA аналогичны технологии RPC (рисунок 12). В частности, основой CORBA является язык IDL.

Рисунок 12. Структура интерфейсов брокера объектных заявок

Интерфейс сервера приложений реализуется на IDL и компилируется, в результате чего получаются модули заглушки клиента (Stub) и скелета сервера (Skeleton) на соответствующих языках программирования. Клиент обращается к брокеру объектных заявок (ORB - Object Request Broker) через модуль Stab или через интерфейс динамического вызова, что менее эффективно по критерию производительности. ORB упаковывает параметры вызова в сетевой пакет и передает его Smart Agent – приложению, которое может быть размещено на любой машине ЛВС. Smart Agent предназначен для управления работой однотипных серверов, находящихся в ЛВС. В ЛВС может быть несколько Smart Agent. Smart Agent отыскивает нужный сервер и передает ORB пакет заявки. ORB обращается к адаптеру объектов (Broker Object Adapter - BOA), который передает управление серверу. Сервер работает через свой модуль Skeleton. BOA предназначен для управления информацией о сервере на Smart Agent (в первую очередь для регистрации сервера).

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

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

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

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

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

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

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

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

Сетевое взаимодействие в CORBA реализуется Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP), который может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP – называется Межброкерным Протоколом Internet (Internet Inter-ORB Protocol, сокращенно IIOP).

Согласно GIOP, внутренняя архитектура брокеров предполагается неизвестной. Для согласованного включения брокера в компьютерную сеть требуется существование связанных с ним компонентов, способных посылать и принимать сообщения IIOP.

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

ODMGObject Database Management Group – международный консорциум, в который входят производители объектно-ориентированных СУБД: Object Design, Objectivity, Ontos, O2 Technology и т.д. Документ ODMG-93 стал первой версией стандарта ООСУБД и ООБД.

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

5.7. Пример реализации обмена данными с приложениями (MS Office)

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

Пример обращения к OLE-серверу MS Excel из программного модуля на VBA:

If Tasks.Exists("Microsoft Excel") = True Then

           Set xlObj = GetObject(, "Excel.Application")

       Else

           Set xlObj = CreateObject("Excel.Application")

       End If

       xlObj.Visible = True

       File = xlObj.GetOpenFilename("Файлы Excel,*.xls")

       If File <> False Then

           xlObj.Workbooks.Open File

           xlObj.Activesheet.UsedRange.Copy

           xlObj.ActiveWorkBook.Close (False)

           MyDoc.Range.Paste

       End If

Подобным образом реализуется обращение к OLE-серверу с использованием универсальных средств разработки. Пример для Borland C++Builder:

#include <utilcls.h>

...

Variant MSExcel, MyBook, MySheet;

...

try

{ // Получить указатель на активный объект. MSExcel - загружен

 MSExcel = Variant::GetActiveObject("Excel.Application");

}

catch (...)

{

 MSExcel = Variant::CreateObject("Excel.Application");

}

MSExcel.OlePropertySet ( "Visible", true );

...

// Создание новой книги

Variant MSBooks;

 MSBooks = MSExcel.OlePropertyGet ("Workbooks");

MyBook = MSBooks.OleFunction ( "Add" );

...

// Создание страницы

Variant Sheets;

   Sheets = MyBook.OlePropertyGet ("Worksheets");

   MySheet = Sheets.OleFunction ("Add");

...

// Заполнение таблицы

Variant Range;

Range = MySheet.OlePropertyGet ( "Range", "B2" );

Range.OlePropertySet ( "FormulaR1C1", "1" );

...

// Создание диаграммы

Variant Charts, Chart, Ch, Range;

Charts = MySheet.OlePropertyGet ("ChartObjects");

Chart = Charts.OleFunction ( "Add", 300, 20, 300, 400 );

Ch = Chart.OlePropertyGet ( "Chart" );

Range = MySheet.OlePropertyGet ( "Range", "A2:B17" );

Ch.OleProcedure ( "SetSourceData", Range, "xlColumns" );

Таким образом, все обращение к OLE-серверу сводится к использованию функций объекта класса Variant OlePropertyGet, OlePropertySet, OleFunctoin, OleProcedure.

Приведенный пример относится к методике позднего связывания. Это означает, что сначала из реестра Windows путем использования имени OLE-сервера добывается ссылка на него, описываемая его глобально уникальным идентификатором (GUIDGlobally Unique IDentifier), а затем используется эта ссылка. Такой способ снижает производительность работы приложения, но является более универсальным. Добиться некоторого повышения производительности при этом можно, перенеся часть функциональности в макросы OLE-сервера.

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

Существует два пути реализации этого способа:

  1.  Использование поставляемых с MS Office библиотек типов *.OLB. При этом соответствующая библиотека присоединяется к проекту. Например, в Borland C++Builder для этого используется пункт главного меню: ProjectImport Type Library, после чего созданные файлы *.CPP и *.H автоматически присоединяются к проекту.
  2.  Использование специализированных компонент. Например, в последних версиях Borland C++Builder используются компоненты закладки Servers. Эти компоненты выполняют работу с OLE-серверами. Генерируются эти компоненты автоматически во время установки C++Builder с настройкой на версию MS Office.

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

6. Общие вопросы построения систем с распределенными данными

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

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

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

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

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

К системам с распределенными БД не относятся:

  1.  Системы с распределенной обработкой. Это системы, в которых БД централизована, а обработка распределена. В частности, несколько аппаратно-программных комплексов могут исполнять серверные функции.
  2.  Параллельные СУБД, к которым, в свою очередь, относятся:
    1.  системы с разделением памяти (архитектура с симметричной многопроцессорной обработкой – SMP) – системы с общей памятью и несколькими процессорами, в которых обработка БД, размещенной на носителе (массиве носителей), выполняется процессорами параллельно;
    2.  системы с разделением дисков – системы, в которых каждый процессор имеет отдельную оперативную память, подключенную к нему локально, а дисковые массивы (иногда называемые дисковыми кластерами) используются в режиме разделения;
    3.  системы без разделения ресурсов (системы с массированной параллельной обработкой – MPP) – по сути наиболее близкая к распределенным БД разновидность, в которой к каждому процессору локально подключены оперативная и дисковая память, и БД распределена между носителями; отличия заключаются в том, что взаимодействие между процессорами осуществляется локально.

Преимущества распределенных СУБД:

  1.  Отражение структуры организации. Подразделения географически распределенной организации могут использовать свои локальные фрагменты БД, а руководство получать отчетность путем выполнения распределенных запросов.
    1.  Высокая степень разделяемости и локальной автономности. Как правило, пользователи локального фрагмента БД не нуждаются в использовании остальной части БД, хотя при необходимости могут использовать и ее. Как правило, администрирование и управление правами также осуществляется на локальном уровне.
      1.  Повышение надежности и доступности данных. Распределенные системы строятся таким образом, чтобы отказ одного из узлов не влиял (влиял минимальным образом) на функционирование всей остальной системы.
      2.  Повышение производительности. Если представить себе распределенную БД, которая строится на основе централизованной, сервер которой становится в результате самым производительным и мощным узлом распределенной системы, то нагрузка на него сокращается в результате перераспределения объемов хранимых данных и вычислительной нагрузки.
      3.  Сокращение расходов на аппаратное обеспечение. Распределенность системы и построение ее на основе совокупности относительно «легковесных» компонентов (по сравнению с построением на основе мэйнфрейма) позволяет минимальными затратами расширять и модернизировать систему. Локальная обработка данных также дешевле удаленной.
      4.  Модульность системы.

Недостатки распределенных СУБД:

  1.  Повышение сложности. Необходимость организации прозрачного доступа к данным независимо от их фрагментации, обеспечения репликации и т.п. возможны только путем повышения сложности системы. Снижение сложности возможно только путем сокращения названных преимуществ.
    1.  Повышение расходов на поддержание жизненного цикла программного обеспечения. Распределенная СУБД, будучи более сложной системой, требует более высоких затрат как на стадии приобретения, так и на стадиях сопровождения и поддержки.
    2.  Повышение сложности защиты. Если в централизованной системе необходимо защищать в первую очередь саму БД и сервер, то в распределенной в той же степени должны быть защищены каналы связи между серверами.
    3.  Усложнение контроля целостности данных.
    4.  Значительно меньшая апробированность технологии по сравнению с централизованными СУБД.
    5.  Отсутствие единых стандартов и усложнение процедуры разработки БД.

6.1. Архитектура распределенных СУБД

Базы данных строят в соответствии с трехуровневой архитектурой ANSI-SPARC, включающей внешний, концептуальный и внутренний уровни (схемы) данных. Такое деление отражает логические уровни представления данных: внешний – для пользователя; концептуальный – обобщенный уровень, наиболее общая модель предметной области, которая может подразумевать различные представления для конечных пользователей и различные физические способы хранения данных; физический (внутренний) – представление данных в соответствии с их хранением в БД. Более подробно данная модель рассматривается в рамках дисциплины «Управление данными».

Рекомендуемая архитектура распределенной СУБД

Распределенные СУБД рекомендуется строить в некотором соответствии с трехуровневой моделью. При этом распределенная СУБД должна включать в себя следующие основные компоненты:

  •  набор глобальных внешних схем;
  •  глобальная концептуальная схема;
  •  схема фрагментации и распределения;
  •  набор схем для каждой локальной СУБД, отвечающей требованиям трехуровневой архитектуры ANSI-SPARC.

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

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

Каждая локальная СУБД имеет свой собственный набор схем. Локальные концептуальная и внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSI-SPARC, Локальная схема отображения используется для отображения фрагментов в схеме размещения во внешние объекты локальной базы данных. Эти элементы зависят от типа используемой СУБД и служат основой для создания разнородных распределенных СУБД.

Объединенные мультибазовые системы

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

Рисунок 13. Архитектура распределенной СУБД

Компонентная архитектура распределенной СУБД

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

Эта архитектурная модель включает в себя следующие компоненты:

  •  локальная СУБД;
  •  компонент передачи данных;
  •  глобальный системный каталог;
  •  распределенная СУБД.

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

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

Рисунок 14. Архитектура тесно связанных объединенных мультибазовых СУБД

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

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

Рисунок 15. Компонентная архитектура распределенной СУБД

6.2. Разработка распределенных реляционных БД

6.2.1. Правила Дейта

Правило 1. Локальная автономность

Узлы в распределенной системе должны быть автономными. В данном контексте автономность означает следующее:

• локальные данные принадлежат локальным владельцам и сопровождаются локально;

• все локальные операции остаются сугубо локальными;

• все операции на заданном узле контролируются только этим узлом.

Правило 2. Отсутствие зависимости от центрального узла

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

Правило 3. Непрерывное функционирование

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

• добавление или удаление узла из системы;

• динамическое создание или удаление фрагментов из одного или нескольких узлов.

Правило 4. Независимость от местонахождения

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

Правило 5. Независимость от фрагментации

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

Правило 6. Независимость от репликации

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

Правило 7. Обработка распределенных запросов

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

Правило 8. Обработка распределенных транзакций

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

Правило 9. Независимость от типа оборудования

Распределенная СУБД должна функционировать на оборудовании с различными вычислительными платформами.

Правило 10. Независимость от операционной системы

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

Правило 11. Независимость от сетевой архитектуры

Распределенная СУБД должна функционировать в среде самых различных сетей связи.

Правило 12. Независимость от базы данных

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

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

6.2.2. Основные принципы проектирования распределенных БД

Основные аспекты проектирования распределенных БД:

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

Одним из наиболее общих принципов, используемых при проектировании размещения данных в распределенной СУБД называют принцип «20/80», который заключается в том, что порядка 20% процентов запросов используются пользователями в 80% случаев. Это означает, что для каждого пользователя можно выделить то относительно небольшое множество отношений, к которому он будет обращаться наиболее часто.

К количественным показателям, используемым при проектировании распределенной БД, относятся:

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

Количественные показатели используются при решении вопросов размещения.

Качественные показатели:

  •  используемые отношения, атрибуты и строки;
  •  тип доступа (чтение или запись);
  •  предикаты (настройки) операции чтения.

Качественные показатели используются при решении вопросов фрагментации.

Стратегические цели, которые преследуются при проектировании распределения данных по узлам, следующие:

  1.  Локализация ссылок. Везде, где только это возможно, данные должны храниться как можно ближе к местам их использования. Если фрагмент применяется на нескольких узлах, может оказаться целесообразным разместить на этих узлах его копии.
  2.  Повышение надежности и доступности. Надежность и доступность данных повышаются за счет использования механизма репликации. В случае отказа одного из узлов всегда будет существовать копия фрагмента, сохраняемая на другом узле.
  3.  Приемлемый уровень производительности. Неверное размещение фрагментов может привести к возникновению в системе узких мест. В этом случае некоторый узел будет перегружен запросами от других узлов, что может существенно снизить производительность всей системы. В то же время неправильное размещение может привести к неэффективному использованию ресурсов системы.
  4.  Компромисс между емкостью и стоимостью внешней памяти. Обязательно следует учитывать доступность и стоимость устройств хранения данных, имеющихся на каждом из узлов системы. Везде, где только это возможно, рекомендуется использовать более дешевые устройства массовой памяти. Это требование должно быть согласовано с требованием обеспечения локализации ссылок.
  5.  Минимизация расходов на передачу данных. Следует тщательно учитывать стоимость выполнения в системе удаленных запросов. Затраты на выборку будут минимальны при обеспечении максимальной локализации ссылок, т.е. тогда, когда каждый узел будет иметь собственную копию необходимых ему данных. Однако при обновлении копируемых данных внесенные изменения потребуется распространить на все узлы, имеющие копию обновленного отношения, что увеличит затраты на передачу данных.

Стратегии размещения данных в системе:

  1.  Централизованное размещение. Стратегия предусматривает создание на одном из узлов единственной БД, доступ к которой будут иметь все пользователи сети. Затраты на передачу данных высоки по причине низкого уровня локализации ссылок, а надежность невысока.
    1.  Фрагментированное размещение. БД разбивается на непересекающиеся фрагменты, каждый из которых размещается на одном узле системы. По сравнению с предыдущим вариантом производительность выше, а затраты ниже, выше также надежность.
    2.  Размещение с полной репликацией. Стратегия предусматривает размещение полной копии всей БД на каждом из узлов системы. Для сокращения затрат на передачу информации в некоторых случаях используется технология снимков. Снимок представляет собой копию БД в определенный момент времени. Эти копии обновляются через некоторый установленный интервал времени, например, раз в час или раз в сутки.
    3.  Размещение с избирательной репликацией. Стратегия представляет собой комбинацию методов фрагментации, репликации и централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для них высокой локализации ссылок, тогда как другие, используемые на многих узлах, но не подверженные частым обновлениям, подвергаются репликации.

7. Операции с распределенными данными в распределенных ИС

7.1. Оптимизация распределенных запросов

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

При горизонтальной фрагментации упрощение запросов выполняется по следующим правилам:

  1.  Если фильтрующее выражение не пересекается с выражением, описывающим фрагмент, то результатом будет пустая выборка, а значит, этот отбор на этом фрагменте делать не нужно.
  2.  Если соединению подвергаются фрагменты, описываемые взаимонепересекающимися выражениями, то результатом будет пустая выборка, а значит, это соединение выполнять не нужно.

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

7.2. Выполнение глобальных транзакций

7.2.1. Общий алгоритм выполнения глобальной транзакции:

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

7.2.2. Централизованный протокол двухфазной блокировки

Этот протокол характеризует наличие одного глобального диспетчера блокировок.

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

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

Преимущество централизованного протокола двухфазной блокировки состоит в том, что его можно относительно просто реализовать. Обнаружение взаимоблокировок может выполняться теми же методами, что и в централизованных СУБД, поскольку вся информация о блокировках элементов находится в распоряжении единственного диспетчера блокировок. Основной недостаток этой схемы связан с тем, что любая централизация в распределенной СУБД автоматически приводит к появлению узких мест в системе и резко снижает уровень ее надежности и устойчивости. Поскольку все запросы на блокировки элементов данных направляются на единственный центральный узел, его быстродействие ограничивает возможности всей системы. Кроме того, отказ этого узла вызывает нарушение работы всей распределенной системы, поэтому она становится менее надежной. Однако этой схеме свойствен относительно невысокий уровень затрат на передачу данных. Например, глобальная операция обновления с участием агентов (субтранзакций) на n узлах при наличии центрального диспетчера блокировок может потребовать отправки ему не менее 2n + 3 сообщений, в том числе:

• один запрос на блокировку;

• одно сообщение о предоставлении блокировки;

n сообщений с требованием обновления;

n подтверждений о выполненном обновлении;

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

7.2.3. Двухфазная блокировка с первичными копиями

В этом варианте протокола попытка преодолеть недостатки централизованного протокола двухфазной блокировки предпринимается за счет распределения функций диспетчера блокировок по нескольким узлам. В данном случае каждый локальный диспетчер отвечает за управление блокировкой некоторого набора элементов данных. В процессе репликации для каждого копируемого элемента данных одна из копий выбирается в качестве первичной копии (primary copy), a все остальные рассматриваются как вторичные (slave copy). Выбор первичного узла может осуществляться по разным правилам, причем узел, который выбран для управления блокировкой первичной копии данных, не обязательно должен содержать саму эту копию.

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

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

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

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

7.2.4. Распределенный протокол двухфазной блокировки

В этом протоколе также предпринимается попытка преодолеть недостатки, свойственные централизованному протоколу двухфазной блокировки, но уже за счет размещения диспетчеров блокировок на каждом узле системы. В данном случае каждый диспетчер блокировок отвечает за управление блокировкой данных, находящихся на его узле. Если данные не подвергаются репликации, этот протокол функционирует аналогично протоколу двухфазной блокировки с первичными копиями. В противном случае распределенный протокол двухфазной блокировки использует особый протокол управления репликацией, получивший название "чтение одной копии и обновление всех копий" (Read-One-Write-All — ROWA). В этом случае для операций чтения может использоваться любая копия копируемого элемента, но прежде чем можно будет обновить значение элемента, должны быть установлены исключительные блокировки на всех копиях. В такой схеме управление блокировками осуществляется децентрализованным способом, что позволят избавиться от недостатков, свойственных централизованному управлению. Однако данному подходу присущи свои недостатки, связанные с существенным усложнением методов выявления взаимоблокировок (из-за наличия многих диспетчеров блокировок) и возрастанием издержек на передачу данных (по сравнению с протоколом двухфазной блокировки с первичными копиями), которые вызваны необходимостью блокировать все копии каждого обновляемого элемента. В данном протоколе выполнение глобальной операции обновления, имеющей агентов на n узлах, потребует передачи не менее 5n сообщений, в том числе:

n сообщений с запросами на блокировку;

n сообщений с предоставлением блокировки;

n сообщений с требованием обновления элемента;

n сообщений с подтверждением выполненного обновления;

n сообщений с запросами на снятие блокировки.

Это количество сообщений может быть сокращено до 4n, если не передавать запросы на снятие блокировки, которое в этом случае будет выполняться при обработке операции окончательной фиксации распределенной транзакции.

7.2.5. Блокировка большинства копий

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

В этом случае также устраняются недостатки, свойственные централизованному подходу. Но данному протоколу свойственны собственные недостатки, заключающиеся в повышенной сложности алгоритма, усложнении процедур выявления взаимоблокировки, а также необходимости отправки не менее [ (n + 1) /2] сообщений с запросами на установление блокировки и [ (n + 1)/2] сообщений с запросами на отмену блокировки. Метод успешно работает, но показывает себя излишне жестким в отношении разделяемых блокировок. Для чтения достаточно заблокировать только одну копию элемента данных, а этот метод требует установки блокировок на большинстве копий.

7.3. Способы устранения взаимоблокировок в распределенной среде

7.3.1. Централизованный метод выявления взаимоблокировок

При централизованном выявлении взаимоблокировок один из узлов системы назначается координатором выявления взаимоблокировок (Deadlock Detection Coordinator — DDC). Узел DDC отвечает за построение и обработку глобального графа ожидания. С определенным интервалом каждый диспетчер блокировок в системе направляет в адрес DDC свой локальный граф ожидания. Узел DDC выполняет построение глобального графа ожидания и проверяет его на наличие циклов. Если граф ожидания содержит один или несколько циклов, DDC должен разорвать каждый цикл, выбрав те транзакции, которые подлежат отмене с выполнением отката, а затем перезапуску. В обязанности DDC входит информирование всех узлов, принимающих участие в обработке отменяемых транзакций, о том, что для последних необходимо выполнить откат и перезапуск.

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

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

7.3.2. Иерархический метод выявления взаимоблокировок

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

Второй уровень образуют узлы DDij, обеспечивающие обнаружение взаимоблокировок для соседней пары узлов Si и Sj. Третий уровень образуют узлы, выполняющие контроль взаимоблокировок на четырех соседних узлах. Корнем дерева является глобальный детектор взаимоблокировок, способный обнаружить взаимоблокировку между любыми узлами системы, например между узлами S1 и S8.

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

7.4. Восстановление после отказов в распределенной среде

Для распределенных СУБД характерны следующие причины отказов:

• потеря сообщения;

• отказ линии связи;

• аварийный останов одного из узлов;

• разделение сети на отдельные подсети.

Действия в случае отказа узла:

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

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

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

7.4.1. Двухфазная фиксация транзакций (2РС)

Как следует из названия данного протокола, фиксация результатов транзакций выполняется в два этапа: голосования (voting phase) и принятия решения (decision phase). Основная идея состоит в том, что координатор должен опросить всех участников, готовы ли они к фиксации транзакции. Если хотя бы один из участников потребует отката или не ответит на запрос в течение установленного тайм-аута, координатор укажет всем участникам на необходимость выполнить откат данной транзакции. Глобальное решение должно быть принято всеми участниками. Если некоторый участник требует отката транзакции, то он имеет право выполнить его немедленно. Фактически любой узел имеет право выполнить откат своей субтранзакции в любое время, вплоть до того момента, пока он не отправит согласие на ее фиксацию. Подобный тип отката называют односторонним откатом. Если участник проголосовал за фиксацию транзакции, то он должен ожидать до тех пор, пока координатор не разошлет широковещательное сообщение либо о глобальной фиксации, либо о глобальном откате этой транзакции. Данный протокол предполагает, что каждый узел имеет свой собственный локальный журнал и с его помощью может надежно выполнить откат или фиксацию транзакции. Двухфазный протокол фиксации транзакций включает этап ожидания сообщения от других узлов. Во избежание нежелательных блокировок процессов система использует механизм контроля тайм-аута. Для фиксации глобальной транзакции координатор выполняет следующую процедуру.

Этап1

1. Занести запись begin_commit в системный журнал и обеспечить ее принудительную запись из буфера во вторичную память. Отправить всем участникам команду PREPARE. Ожидать поступления ответов от всех участников в течение установленного тайм-аута.

Этап 2

2. Если участник возвращает сообщение ABORT, поместить в системный журнал запись abort и обеспечить ее принудительную запись из буфера во вторичную память. Отправить всем участникам команду GLOBAL_ABORT. Ожидать ответов всех участников в течение установленного тайм-аута.

3. Если один из участников возвращает сообщение READY_COMMIT, обновить список участников, приславших свои ответы. Если сообщения о готовности фиксации прислали все участники, поместить в системный журнал запись commit и обеспечить ее принудительную запись из буфера во вторичную память. Отправить всем участникам команду GLOBAL_COMMIT. Ожидать ответов всех участников в течение установленного тайм-аута.

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

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

1. При получении участником команды PREPARE он выполняет одно из следующих действий:

а) помещает запись ready_commit в файл журнала и переносит из буфера во вторичную память все записи, относящиеся к данной транзакции. Отправляет координатору сообщение READY_COMMIT;

б) помещает запись abort в файл журнала и переносит ее из буфера во вторичную память. Отправляет координатору сообщение ABORT. Выполняет односторонний откат транзакции.

2. Ожидание ответа координатора продолжается в течение установленного тайм-аута.

3. Если участник получает команду GLOBAL_ABORT, то он помещает запись abort в файл журнала и переносит ее из буфера во вторичную память. Затем выполняется откат транзакции и по его завершении координатору посылается соответствующее подтверждение. Если участник получает команду GLOBAL_COMMIT, то он помещает запись commit в файл журнала и переносит ее из буфера во вторичную память. Затем выполняется фиксация транзакции, освобождение всех установленных блокировок, после чего координатору посылается соответствующее подтверждение.

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

Участник должен ожидать поступления от координатора команды GLOBAL_COMMIT или GLOBAL_ABORT. Если в течение установленного тайм-аута он не получит никакой команды или координатор не получит ответа от участника, го предполагается, что на соответствующем узле произошел отказ и в работу запускается протокол аварийного завершения (termination protocol). Протокол аварийного завершения выполняют только функционирующие узлы, а отказавшие узлы после перезапуска выполняют протокол восстановления.

Рисунок 16. Взаимодействие координатора и участника транзакции в рамках двухфазного протокола

7.4.1.1. Протоколы аварийного завершения

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

Координатор

В процессе выполнения фиксации транзакции координатор может находиться в одном из четырех состояний: INITIAL, WAITING, DECIDED и COMPLETED, как показано на диаграмме переходов, представленной на рисунке 17. Но завершение по тайм-ауту может произойти только в двух промежуточных состояниях.

В подобных случаях предпринимаются следующие действия.

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

• Тайм-аут в состоянии DECIDED. Координатор ожидает поступления от всех участников уведомлений об успешном откате или фиксации данной транзакции. В подобной ситуации координатор просто повторно рассылает сведения о принятом глобальном решении на все узлы, не приславшие ожидаемого подтверждения.

Рисунок 17. Диаграммы переходов для координатора (верхняя) и участника (нижняя) транзакции

Участник

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

В процессе выполнения фиксации транзакции участник может находиться в одном из четырех состояний: INITIAL, PREPARED, ABORTED и COMMITTED, как показано на диаграмме переходов, представленной на рис. Но участник может завершить работу по тайм-ауту только в первых двух состояниях, как описано ниже.

• Тайм-аут в состоянии INITIAL. Участник ожидает от координатора поступления команды PREPARE. Ее отсутствие может свидетельствовать о том, что узел координатора отказал, когда процесс фиксации транзакции находился в состоянии INITIAL. В этом случае участник может выполнить откат транзакции в одностороннем порядке. При поступлении впоследствии команды PREPARE он сможет либо ее игнорировать (в результате чего координатор организует откат глобальной транзакции по тайм-ауту), либо отправить координатору сообщение ABORT.

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

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

7.4.1.2. Протоколы восстановления

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

Отказ координатора

Рассмотрим три различных варианта отказа узла-координатора.

1. Отказ в состоянии INITIAL. Координатор еще не начал процедуру фиксации транзакции. В данном случае восстановление заключается в запуске этой процедуры фиксации.

2. Отказ в состоянии WAITING. Координатор уже направил команды PREPARE узлам-участникам, и, хотя получил еще не все ответы, ни одного предложения об откате получено не было. В этом случае восстановление заключается в повторном запуске процедуры фиксации транзакции.

3. Отказ в состоянии DECIDED. Координатор уже направил участникам транзакции указания о ее глобальной фиксации или глобальном откате. Если после перезапуска координатор получит все необходимые подтверждения, завершение транзакции можно считать успешным. В противном случае потребуется прибегнуть к использованию протокола аварийного завершения, описанного выше.

Отказ участника

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

1. Отказ в состоянии INITIAL. Участник еще не успел проголосовать по поводу способа завершения транзакции. Поэтому в процессе восстановления он может выполнить откат транзакции в одностороннем порядке, поскольку без получения сведений от данного узла-участника координатор не может принять решение о глобальной фиксации этой транзакции.

2. Отказ в состоянии PREPARED. Участник уже направил сведения о своем решении в адрес координатора. В этом случае восстановление заключается в применении протокола аварийного завершения, описанного выше.

3. Отказ в состоянии ABORTED/COMMITTED. Участник уже завершил обработку транзакции. Поэтому после перезапуска дальнейшие действия не требуются.

7.4.1.3. Протоколы проведения выборов

Если участники обнаруживают отказ координатора (посредством тайм-аута), они могут выбрать другой узел, который должен взять на себя роль координатора. Один из протоколов проведения выборов требует, чтобы узлы системы были последовательно упорядочены. Предположим, что узел Si занимает позицию i в общей последовательности (первым в которой является координатор), а все остальные узлы знают идентификаторы и порядковые номера других узлов системы (причем некоторые из этих узлов также могут находиться в состоянии отказа). Данный протокол проведения выборов требует, чтобы каждый функционирующий участник посылал сообщения на узлы с большим идентификационным номером. Поэтому узел Si должен отправить сообщения на узлы Si+1, Si+2, ... , Sn, причем именно в этом порядке. Если узел Sk получит сообщение от узла-участника с меньшим номером, то узел Sk приходит к заключению, что он не может быть новым координатором, и прекращает отправку сообщений.

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

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

7.4.2. Трехфазная фиксация транзакций (ЗРС)

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

Для использования этого протокола необходимо соблюдение следующих условий.

• Разделение сети является недопустимым.

• По крайней мере один узел всегда должен быть доступен.

• Могут отказать одновременно самое большее К узлов сети (поэтому такие системы называют К-устойчивыми).

Основным преимуществом протокола трехфазной фиксации является устранение периода ожидания в состоянии неопределенности, в которое переходят участники с момента подтверждения своего согласия на фиксацию транзакции и до момента получения от координатора извещения о глобальной фиксации или глобальном откате. В трехфазном протоколе фиксации между этапами голосования и принятия глобального решения вводится третий этап, называемый предфиксацией. После получении результатов голосования ото всех участников координатор рассылает глобальное сообщение PRE-COMMIT. Участник, который получил глобальное извещение о предфиксации, знает, что все остальные участники проголосовали за фиксацию результатов транзакции и что со временем сам этот участник определенно выполнит фиксацию транзакции, если не произойдет отказ. Каждый участник подтверждает получение сообщения о предфиксации. После того как координатор получит все эти подтверждения, он рассылает команду глобальной фиксации транзакции. Если некоторый участник потребовал отката транзакции, то обработка этой ситуации выполняется точно так же, как в протоколе двухфазной фиксации.

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

8. Java-технологии

В простейшем случае Web-сервер является HTTP-сервером, т.е. способен только обрабатывать запросы http. В более сложном случае он выполняет функции сервера приложений. Это означает, что он должен включать в себя функции поддержки бизнес-логики. Эта поддержка должна быть универсальной. Бизнес-процедуры реализуются на интерпретируемых скриптовых языках, а Web-сервер обеспечивает их выполнение.

ПО, созданное с использованием Java-технологий распространяется в виде архивов, выполняемых по технологии ZIP: JARJava ARchive, EAREnterprise ARchive, WARWindows ARchive.

Основные концепции наиболее современной платформы J2EEJava 2 Enterprise Edition:

  1.  Контейнер.
  2.  JSP.
  3.  EJB.
  4.  Servlet.

Под контейнером понимают среду, обеспечивающую выполнение Java-кода, т.е. платформу, выполняющую трансляцию Java-кода, создание Java-объектов, их взаимодействие с JVM. Контейнер входит в состав браузера и обеспечивает выполнение Java-кода апплета или фрагмента кода JavaScript. Контейнер размещается на серверной стороне и входит в состав Web-сервера.

JavaScript – это разновидность языка Java, применяемая для написания фрагментов кода, как правило, оформленных в виде некоторых функций, включенных в текст html-страницы и вызываемых из нее же. Типичное применение фрагментов кода JavaScript – выполнение первичной проверки правильности значений, введенных пользователем на html-странице. Код JavaScript выполняется на клиентской стороне, т.е. поддержка JavaScript должна быть реализована в браузере. Естественно, на JavaScript обычно реализуют функции, не требующие обращений к серверу.

Рисунок 18. Диаграммы переходов для координатора (верхняя) и участника (нижняя) транзакции в случае трехфазной фиксации транзакций

Java Server Pages (JSP) – html-страницы, содержащие фрагменты Java-кода (т.наз. скриптлеты). JSP обрабатываются сервером. В ходе обработки формируется html-страница из результатов выполнения фрагментов Java-кода и находящихся между ними фрагментов html. Типичное применение JSP – динамическое формирование html-контента. В JSP возможно управление выполнением программы: циклы, условные ветвления и т.д.

В JSP используются библиотеки тэгов (taglib). Использование библиотек тэгов, подключаемых при помощи специальной директивы, позволяет наравне с html-тэгами вставлять в код JSP тэги, реализованные в этих библиотеках. Использование Java-тэга означает фактически вызов некоторой описанной в библиотеке процедуры с указанными в тэге параметрами, результатом выполнения которой является фрагмент html-кода, вставляемый в получаемую страницу вместо тэга.

Серверный компонент обработки JSP, получив запрос, выделяет из JSP составные части (html, используемые данные, фрагменты Java-кода), транслирует все полученное в объектный код сервлета и запускает его, передавая ему в качестве параметра запрос. Полученный сервлет должен генерировать ответ в виде требуемой html-страницы.

Популярной моделью реализации серверных приложений стала MVCModel-View-Controller. Согласно этой модели компонентами серверного приложения являются: Model – компоненты, предназначенные для формирования программной модели предметной области на основе данных из источников; View – компоненты, предназначенные для формирования пользовательского представления и поддержки пользовательского ввода; Controller – компоненты, предназначенные для управления всей остальной структурой.

Компоненты View реализуются в виде JSP. Все остальное реализуется как совокупность JavaBean. JavaBean называют класс на языке Java. Java-сервлетом называется Java-класс, инициализация и запуск которого при приходе определенного URL настраиваются в специальном конфигурационном файле Web-сервера формата XML. Сервлет выполняет функции контроллера. Распространена модель разбиения контроллера на собственно контроллер и совокупность классов, каждый из которых обрабатывает одно из действий (событий) пользователя с сайтом. В этом случае контроллер выполняет только функции диспетчеризации, т.е. запуска того или иного Java-bean’а в зависимости от пришедшего http-запроса. Bean’ы обрабатывают запросы и принимают решение о выводе той или иной JSP.

После приема http-запроса от клиента сервер перенаправляет запрос на сервлет. При этом сервер создает на основе запроса объект request и направляет его в сервлет. Сервлет существует один, но используется множеством потоков, каждый из которых обрабатывает один запрос. Сервлет обрабатывает запрос, формирует объект response и возвращает его серверу.

Способы доступа к сервлету:

  1.  Имя сервлета указывается в URL. При этом в URL учитывается специфика хранения сервлетов на Web-сервере, и в путь включается имя директории servlet.
  2.  Используются тэги доступа к ресурсам JSP (<a href>, <form>, <jsp:include>).
  3.  Сервлет вызывается из другого сервлета при помощи специальных методов Java.
  4.  Программно создается экземпляр класса сервлета путем использования стандартной функции получения класса по имени.
  5.  Используется специальный тэг <servlet>, поддерживаемый некоторыми Web-серверами и обрабатываемый существенно быстрее, чем конструкции из п. 2.

JavaBean в традиционном понимании это класс, описывающий визуальный компонент и поддерживающий связанную с этим компонентом бизнес-логику. Enterprise JavaBeans отличаются своей ориентацией на платформу J2EE, т.е. в первую очередь на функционирование в контейнере, соответствующем этой платформе.

Для выполнения удаленных процедур традиционно использовались протоколы RPC. Для управления транзакциями традиционно использовались мониторы обработки транзакций TPMTransaction Process Monitor. Мониторы обработки транзакций предоставляли интерфейсы, организованные в виде удаленных процедур, которые можно было выполнять. Недостатком традиционных TPM считается отсутствие поддержки объектных структур. Это означает слабое представление бизнес-логики для клиента. На ликвидацию этого недостатка направлено использование протоколов RMI (Remote Method Invocation) и компонентных мониторов транзакций (CTM).

RMI отличается от RPC поддержкой объектной ориентации, т.е. удаленный клиент обращается к объекту и его методам. Объект может создаваться единовременно для обработки только одного запроса или жить определенное время и изменять каким-то образом свое состояние. CTM отличается от TPM обработкой распределенных транзакций, независимостью от специфики источника данных, объектно-ориентированной поддержкой бизнес-логики.

Рисунок 19. Компоненты архитектуры EJB

Идея CTM некоторое время прорабатывалась с точки зрения технологий, которые должны были стать основой. Исторически первая реализация CTM имела место в семействе стандартов Microsoft DCOM, MTS, COM+, .NET. Позже группой производителей, объединившихся вокруг компании Sun, были предложены стандарты CTM, основанные на модели CORBA и использующие Java-технологии.

Эти две реализации аналогичны. Клиент общается с сервером через заглушку (stub), сервер с клиентом – через каркас (skeleton).

Таким образом, EJB – это не один класс, а их совокупность: сам серверный класс, его заглушка и каркас.

EJB-сервер – это сервер, хранящий и загружающий EJB, в которых реализована бизнес-логика и данные, используемые клиентами.

Типы EJB:

  1.  Session bean.
  2.  Entity bean.

Сравнительная характеристика Session bean и Entity bean

Свойства

Session bean

Entity bean

Зависимость от сессий клиентов

Создается в начале сессии клиента и существует в течение ее.

Используется совместно несколькими клиентами и не зависит от их сессий.

Взаимодействие с другими компонентами

Может осуществлять связь с другими компонентами.

Предназначен для взаимодействия с другими компонентами.

Работа с БД

Может обновлять данные в основной БД, но не хранит в ней свои переменные.

Хранит все свои переменные в БД.

Зависимость от работы EJB-сервера

Автоматически уничтожается при остановке EJB-сервера.

После перезагрузки сервера восстанавливает состояние из БД и продолжает работу.

Entity bean взаимодействуют с БД в соответствии с методикой Bean Managed Persistence (BMP) с использованием API JDBC или в соответствии с методикой Container Managed Persistence (CMP) с обращением к функциям EJB-контейнера.

Две основных разновидности клиентов – Java-приложение, взаимодействующее с EJB-сервером посредством RMI, и HTTP-клиент, взаимодействующий с EJB через HTTP, JSP и сервлет, функционирующий на Web-сервере.

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

Основным элементом EJB-сервера является контейнер.

Каждый EJB загружается в специальном системном окружении – контейнере. Контейнер – специализированный сервис, непосредственно обслуживающий EJB и организующий для него доступ к базе данных, монитору транзакций и прочим системным ресурсам. Многие из задач контейнера решаются путем его взаимодействия с EJB-сервером.

Вне границ контейнера EJB представляют собой обычные JAR-архивы.

Основные функции контейнера:

  1.  Обеспечение безопасности. Описываются правила доступа к EJB, которые выполняются контейнером.
  2.  Организация удаленного соединения. Обеспечивается прозрачное «квази-локальное» взаимодействие клиента с EJB.
  3.  Управление жизненным циклом EJB. Клиент только создает и удаляет EJB, все его функционирование и работу с ресурсами обеспечивает контейнер.
  4.  Управление транзакциями.

При создании EJB средство разработки генерирует стабы и скелетоны для выполнения методов RMI. Для Entity bean создаются обработчики взаимодействий между бином и источником данных.

Для использования EJB клиент должен выполнить следующие действия:

  1.  Получить доступ к home-интерфейсу EJB. Для этого используется JNDI API.
  2.  Получить ссылку на remote-интерфейс EJB при помощи методов home-интерфейса. При помощи remote-интерфейса можно создать EJB.
  3.  Вызывать методы EJB через методы его remote-интерфейса.

Home-интерфейс Session bean’а без состояния (stateless) содержит только один метод create () без аргументов. У Entity bean подразумеваются методы create(), remove, findByPrimaryKey(). В home-интерфейсе Session bean’а с состоянием может быть несколько методов create() с различными наборами аргументов. Каждому методу remote-интерфейса соответствует какой-то из методов bean’а, набор параметров должен быть идентичен. Например, методу create() remote-интерфейса соответствует метод ejbCreate() EJB.

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

Все компоненты Web-приложения имеют одну из трех областей видимости: application, session, request. Application – область видимости, соответствующая времени жизни самого приложения. Session – область видимости соответствующая сессии определенного пользователя. Request – область видимости, соответствующая контексту обработки одного запроса пользователя.

Транспортные протоколы:

  1.  Java Database Connectivity (JDBC).
  2.  Java Naming and Directory Interface (JNDI) – поддержка именованного обращения к ресурсам.
  3.  Java Message Service (JMS) – спецификация и средства посылки и приема асинхронных сообщений, поддержания очередей сообщений.
  4.  Java Mail.
  5.  Java IDL – набор классов для создания связи с CORBA-объектами с использованием IDL.
  6.  Java Transaction (JTA) – управление транзакционным доступом к совместно используемым ресурсам.
  7.  Remote Method Invocation (RMI) – протокол вызова удаленных процедур.
  8.  RMI IIOP – протокол интеграции Java и CORBA.

Web-приложения строятся в соответствии с одним из бизнес-сценариев.

Бизнес-сценарий Business-to-Consumer (B2C)

Клиент обращается к ресурсам предприятия при помощи Web-браузера.

Рисунок 20. B2C

Бизнес-сценарий Business-to-Business (B2B)

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

Бизнес-сценарий Business-to-Employee (B2E)

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

JDBC и SQLJ

Для обращения к БД из кода JavaBean используют спецификации и библиотеки JDBC и SQLJ.

JDBC – это набор API, позволяющих устанавливать соединение с БД, запускать SQL-запросы, получать их результаты. SQLJ основан на включении SQL-инструкций, обозначенных специальной директивой, непосредственно в текст Java-кода. Таким образом, в SQLJ используются только статические запросы. В запросах могут использоваться параметры. Значения параметров могут инициализироваться переменными из программы, или, напротив, передавать им свои значения. Достоинством SQLJ по сравнению с JDBC является, таким образом, встроенный контроль, который проходят все операторы SQL в процессе трансляции, а достоинством JDBC по сравнению с SQLJ – гибкость формирования запросов.

Рисунок 21. B2B

Рисунок 22. B2E

JDBC API делят на два уровня. Первый уровень (Low Level) – описывает драйверы для доступа к БД. Второй уровень (High Level) содержит классы для управления соединением, транзакциями и выполнения запросов.

Исходный файл SQLJ обрабатывается транслятором, выделяющим директивы SQL и проверяющим их корректность. При этом все SQL-данные (параметры доступа к БД, тексты запросов и т.п.) выделяются и записываются в отдельный файл, а директивы исходного файла заменяются строками Java-кода, в которых производится определение классов, дочерних по отношению к классам библиотеки SQLJ, создание объектов классов SQLJ и унаследованных от них, использование этих объектов. В результате получается полноценный Java-код, обрабатываемый уже транслятором Java. Файл кода Java и файл SQL-данных компилируются в единый байт-код.

В SQLJ используются объекты классов Контекст соединения, соответствующий сессии работы клиента с БД, и Контекст выполнения, соответствующий выполнению одного SQL-оператора. Используется также объект Итератор, позволяющий построчно обрабатывать результаты селектирующего запроса.

9. Процесс проектирования ИС и место формирования архитектуры в нем

Есть ряд примеров стандартизации жизненного цикла ИС, и в частности, создания ИС.

Для отечественного разработчика основным руководящим документом должен являться ГОСТ 34.601-90. «Автоматизированные системы. Стадии создания». Более приближенным к практике, но при этом более узко ориентированным на создание сугубо программных систем является подход RUPRational Unified Process (унифицированный процесс разработки программных систем), подразумевающий использование нотации проектирования UML.

9.1. ГОСТ 34.601-90

Стадии создания АС согласно ГОСТ 34.601-90:

1. Формирование требований к АС

2. Разработка концепции АС.

3. Техническое задание.

4. Эскизный проект.

5. Технический проект.

6. Рабочая документация.

7. Ввод в действие.

8. Сопровождение АС

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

Стадия 1 включает в себя следующие этапы:

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания).

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

Стадия 2 включает в себя следующие этапы:

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющих требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

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

Относительно стадии формирования технического задания ГОСТ дает совсем краткий комментарий, позволяющий сделать вывод о том, что формируется задание, описывающее технические характеристики разрабатываемой АС, а не конкретику технических решений.

Стадия 4 включает в себя следующие этапы:

4.1. Разработка предварительных проектных решений по системе и её частям.

4.2. Разработка документации на АС и её части.

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

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

5.1. Разработка проектных решений по системе и её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

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

9.2. Унифицированный процесс разработки ОО ПС (RUP)

9.2.1. Эволюционно-инкрементная организация жизненного цикла (ЖЦ) разработки

Данный подход является развитием спирального подхода Боэма. Эволюционная составляющая ЖЦ основывается на доопределении требований в ходе работы, инкрементная – на планомерном приращении реализации требований.

Элементами процесса являются:

  •  итерации;
  •  этапы;
  •  рабочие потоки.

Разработка представляет собой серию итераций, в ходе каждой из которых выполняется сбор требований, анализ, проектирование, реализация и тестирование.

Рисунок 23. Унифицированный процесс разработки

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

В целом методика работы с рисками ориентирована на минимизацию затрат на сокращении риска.

Итерации объединяются в этапы, характеризующие основные стадии ЖЦ, через которые проходит разрабатываемая ПС.

Рабочие потоки характеризуют те действия, которые выполняются на всех этапах ЖЦ.

9.2.1.1. Этапы и итерации

Выделяют 4 этапа:

  •  Начало (Inception) – спецификация представления продукта;
  •  Развитие (Elaboration) – планирование необходимых действий и требуемых ресурсов;
  •  Конструирование (Construction) – построение ПС в виде серии инкрементных итераций;
  •  Переход (Transition) – внедрение программного продукта в среду пользователя.

Каждый этап делится на итерации.

Итерация – полный цикл разработки, вырабатывающий промежуточный продукт. От итерации к итерации сложность продукта повышается, он приближается к завершенной ПС.

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

9.2.1.2. Рабочие потоки процесса

Выделяют 5 рабочих потоков:

  •  Сбор требований – описание того, что система должна делать;
  •  Анализ – преобразование требований к системе в классы и объекты;
  •  Проектирование – создание статического и динамического представления системы;
  •  Реализация – производство программного кода.
  •  Тестирование – проверка всей системы в целом.

Каждый рабочий поток определяет набор связанных артефактов и действий.

Артефакт – неодушевленный предмет, с которым работают участники процесса: документ, отчет или выполняемый элемент. Артефакт может вырабатываться, обрабатываться, потребляться.

Действие описывает задачи – шаги обдумывания, исполнения, проверки. Шаги выполняются участниками процесса, в ходе чего создаются или модифицируются артефакты.

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

9.2.1.3. Модели

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

Модели создаются проектировщиками. Модель – наиболее важная разновидность артефакта. Существует 9 разновидностей моделей:

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

Модель области определения (предметной области) является частным случаем более полной бизнес-модели, уточняет ее, описывает не бизнес-процессы вообще, а конкретное окружение, в котором будет работать система. Цель моделирования области определения – разобраться в контексте системы и более качественно определить требования к ней. Для моделирования предметной области могут использоваться не только Use Case диаграммы, но и диаграммы статического и динамического моделирования. Для небольших предметных областей может отсутствовать необходимость в объектном моделировании предметной области, и в качестве модели достаточен глоссарий понятий.

Модель анализа является промежуточной между моделью Use Case, описывающей функционирование системы с точки зрения пользователя, и проектной моделью, описывающей реализацию системы с точки зрения разработчика. Модель анализа описывает внутреннюю организацию системы, но не затрагивает вопросов реализации, поэтому является независимой от средств разработки и прочих особенностей реализации. Основное назначение модели анализа – описать взаимодействия между компонентами системы и пользователями. Для этого используются статические и динамические диаграммы. Модель анализа может использоваться для разных реализаций одной и той же системы.

Проектная модель описывает физическую реализацию вариантов использования, т.е. представляет кооперации в виде диаграмм классов. Физическая модель зависит не только от предметной области, но и от среды разработки, поэтому является специфичной. Проектная модель достаточно детализирована и превышает модель анализа по объему приблизительно в 5 раз. Проектная модель включает в себя статические и динамические диаграммы.

Модель реализации представляется в виде компонентов – контейнеров средства разработки, в которых размещаются подпрограммы и классы разработанные в проектной модели. Модель реализации еще более зависима от среды разработки, чем проектная модель, поскольку ориентируется не просто на языковые средства реализации абстракций, а на поддерживаемые средством разработки механизмы пакетирования и связывания контейнеров (пакетов). Это могут быть файлы *.bas, *.pas, *.dfm, *.cpp, *.h.

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

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

9.2.1.4. Технические артефакты

Основные наборы артефактов:

  1.  Набор требований.
  2.  Набор проектирования. Описывает конструкцию системы.
  3.  Набор реализации. Описывает сборку разработанных программных компонентов.
  4.  Набор размещения. Обеспечивает всю информацию о поставляемой конфигурации.

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

  •  нефункциональных требований;
    •  Use Case;
    •  области определения;
    •  анализа;
    •  неформальные описания требований.

Набор проектирования может включать модели:

  •  проектную;
    •  тестовую;
    •  неформальные описания конструкции системы.

9.2.2. Этапы унифицированного проекта разработки

9.2.2.1. Этап Начало (Inception)

Основная цель этапа – запуск проекта.

Основные рабочие потоки этапа – сбор требований и анализ.

Подцели

Действия

Артефакты

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

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

Спецификация представления основных проектных требований, ключевых характеристик и главных ограничений.

Определить элементы Use Case, критичные для системы (основные сценарии поведения, задающие ее функциональность и покрывающие главные проектные решения).

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

Начальная модель Use Case (порядка 20% от ее общего представления).

Начальный словарь проекта.

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

Проектный план, в котором показаны этапы и итерации.

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

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

Начальный бизнес-вариант (содержание бизнеса, критерий успеха).

Идентифицировать основные элементы риска.

Начальное оценивание риска.

9.2.2.2. Этап Развитие (Elaboration)

Основная цель – создание архитектурного базиса системы

Основные рабочие потоки этапа – развитие, анализ, проектирование. При этом на этапе начинаются работы по реализации и тестированию.

Подцели

Действия

Артефакты

Определить оставшиеся требования, описать функциональные требования как элементы Use Case

Развитие спецификации представления, полное формирование критических элементов Use Case, задающих дальнейшие решения

Модель Use Case (80% от ее общего представления)

Дополнительные требования (нефункциональные требования, и др. требования, не связываемые с конкретным элементом Use Case)

Определить архитектурную платформу системы

Развитие архитектуры, выделение ее компонентов

Описание программной архитектуры

Выполняемый архитектурный макет

Отслеживать риск, устранять источники наибольшего риска

Пересмотренный список элементов риска и пересмотренный бизнес-вариант

Разработать план итераций этапа Конструирование

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

Под архитектурой ОО ПС обычно понимают т.наз. представление «4+1», в которое входят:

  •  представление Use Case;
    •  логическое представление (проектная модель);
    •  представление процессов (модель процессов);
    •  представление реализации (модель реализации);
    •  представление размещения (модель размещения).

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

  1.  Определяются и ранжируются элементы риска.
  2.  Сценарии (диаграммы Use Case и последовательности) исследуются и ранжируются в порядке убывания риска, потребностей заказчика, своей роли в ПС.
  3.  Формируются классы и отношения, предназначенные для реализации сценариев.
  4.  Программируются классы и отношения.
  5.  Разрабатываются тестовые варианты.
  6.  Тестируются классы и отношения. Проверяется выполнение функционального назначения сценария.
  7.  Результаты интегрируются в результаты предыдущих итераций. Реализация тестируется.
  8.  Итерация оценивается. Выявляется необходимая повторная работа. Она планируется на следующую итерацию.

Качество логического представления архитектуры оценивают при помощи метрик:

  •  WMC – взвешенные методы на класс;
    •  NOC – количество детей;
    •  DIT – высота дерева наследования;
    •  NOM – суммарное количество методов, определенных во всех классах системы;
    •  NC – общее количество классов в системе.


 

А также другие работы, которые могут Вас заинтересовать

74332. Характерные значения удельных (погонных) параметров схем замещения и электрических режимов воздушных и кабельных линий электропередачи и соотношения между ними 496 KB
  Волновые параметры реальной линии волновое сопротивление ZB и коэффициент распространения волны γо определяются через ее удельные погонные отнесенные к 1 км параметры: где β0 коэффициент затухания α0 коэффициент изменения фазы фазовый угол. Удобно определять параметры Побразной схемы замещения линии через удельные погонные сопротивления Zo=RojX0 Ом км и проводимости Yo=g0jb0 См км. При этом равномерную распределенность параметров линии по длине учитывают приближенно с помощью поправочных коэффициентов по формулам Z...
74333. Двухобмоточные силовые тр-ры. Виды, условные обозначения, принципиальные сх., сх. замещения. Моделирование трансформаторов и определение параметров сх. замещения 224 KB
  замещения. замещения. Установим связь схемы замещения трансформатора с его реальными схемнорежимными параметрами. Эта схема в которой магнитная связь между обмотками заменена электрической называется схемой замещения трансформатора.
74334. Понятие пропускной способности электропередачи, факторы её определяющие 32 KB
  Второе ограничение связано с риском нарушения синхронной работы генератора при повышении нагрузки на которых возникает условие для выхода из синхронизма. Это ограничение чаще практикуется по статической устойчивости. При некоторой меньшей длине активным ограничение будет являться ограничение по нагреванию. Заметим что ограничение по нагреванию не зависит от длины ЛЭП.
74335. Компактные, компенсированные электропередачи переменного тока 66 KB
  Компактные компенсированные электропередачи переменного тока. В основу конструкций перспективных компактных воздушных линий электропередач разработанных в нашей стране положена простая идея. Образцы таких распорок уже созданы и составлены проекты будущих компактных воздушных линий электропередач рис. В скобках показаны для сравнения расстояния между фазами для обычных воздушных линий электропередач Расчеты показали что при меньших по сравнению с обычными воздушными линиями электропередач размерами компактные воздушные линии электропередач...
74336. Моделирование (представление) эл нагрузок при расчете рабочих режимов эл.передач и эл.сетей 114.5 KB
  Активные элементы схем замещения электрических сетей и систем нагрузки и генераторы представляются в виде линейных или нелинейных источников. Способы задания нагрузок при расчетах режимов: а постоянный по модулю и фазе ток; б постоянная по модулю мощность; вгпостоянные проводимость или сопротивление; дстатические характеристики нагрузки по напряжению; еслучайный ток Нагрузка задается постоянным по модулю и фазе током рис.Такая форма представления нагрузки принимается при всех расчетах распределительных сетей низкого напряжения...
74337. Статические характеристики электрических нагрузок 75 KB
  Зависимости показывающие изменение активной и реактивной мощности и от частоты f и подведенного напряжения U при медленных изменениях менее 1 сек этих параметров называют статическими характеристиками нагрузки СХН. Полученные при этом СХН называются естественными. Примерный состав нагрузки соответствующий типовым СХН Асинхронные двигатели...
74338. Представление генераторов при расчете установившихся режимов эл.передач ЭЭС. 105 KB
  В расчетах установившихся режимов электрических сетей и систем как правило не учитываются и а генератор представляется источником подключенным к шинам генераторного напряжения. Обычно для генерирующих узлов при фиксированных и не известны модуль и фаза напряжения узла и либо активные и реактивные составляющие напряжения и . Постоянные активная мощность и модуль напряжения В этом случае переменными являются как правило реактивная мощность и фаза напряжения. Задание постоянного модуля напряжения при соответствует реальным...
74339. Моделирование (представление) линии эл.передачи 0,38-220 кВ. характерные данные и основные соотношения между параметрами схем замещения ЛЭП 210.5 KB
  Характерные данные и основные соотношения между параметрами схем замещения ЛЭП. Выше приведена характеристика отдельных элементов схем замещения линий. При расчете симметричных установившихся режимов ЭС схему замещения составляют для одной фазы
74340. Особенности моделирования воздушных линий электропередачи со стальными проводами 116.5 KB
  Особенности моделирования воздушных линий электропередачи со стальными проводами. Поэтому стальные провода применяют при выполнении больших переходов через естественные препятствия широкие реки горные ущелья и т.