close

Вход

Забыли?

вход по аккаунту

?

5.Распределенные базы данных.

код для вставкиСкачать
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«СЕВЕРО-КАВКАЗСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
РАСПРЕДЕЛЕННЫЕ
БАЗЫ ДАННЫХ
УЧЕБНОЕ ПОСОБИЕ
Направление подготовки
210700.62 – Инфокоммуникационные технологии и системы связи
Профиль подготовки «Сети связи и системы коммутации»
Ставрополь
2015
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
УДК 004.6 (075.8)
ББК 32.97.018.2 я73
Б 87
Б 87
Печатается по решению
редакционно­-издательского совета
Северо-Кавказского федерального
университета
Распределенные базы данных: учебное пособие / авт.-сост. Н. Ю. Братченко. – Ставрополь: СКФУ, 2015. – 130 с.
Пособие составлено с учетом требований Федерального государственного образовательного стандарта высшего профессионального образования. В нем представлены необходимые сведения для освоения соответствующих компетенций, подробное рассмотрение принципов, моделей и
перспектив управления распределенной информацией.
Предназначено для студентов, аспирантов, преподавателей и специалистов, интересующихся распределенными базами данных.
УДК 004.6 (075.8)
ББК 32.97.018.2 я73
Автор-составитель
канд. физ.-мат. наук Н. Ю. Братченко
Рецензенты:
д-р техн. наук, профессор В. П. Мочалов,
д-р техн наук, профессор Н. В. Кандаурова
(Северо-Кавказский гуманитарно-технический институт)
© ФГАОУ ВПО «Северо-Кавказский
федеральный университет», 2015
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ВВЕДЕНИЕ
Распределенные базы данных невозможно рассматривать вне контекста более общей и более значимой темы распределенных информационных систем. Процессы децентрализации и информационной
интеграции, происходящие во всем мире, неизбежно должны рано или
поздно затронуть нашу страну. Россия в силу своего географического
положения и размеров «обречена» на преимущественное использование распределенных систем. На мой взгляд, это направление может
успешно развиваться лишь при выполнении двух главных условий:
- адекватное развитие глобальной сетевой инфраструктуры и применение реальных технологий создания распределенных информационных систем;
- второе условие, рассматриваемое как ключевой фактор развития
информационных технологий в нашей стране, составляет предмет
предлагаемого в данной статье обсуждения.
Важность этой темы осознают все. Действительно, страна прошла
начальный этап локальной компьютеризации. Многие задачи «автоматизации в малом» или «автоматизации в среднем» уже решаются
адекватными средствами на достаточно высоком технологическом
уровне. Но вот задачи совершенно иного качества – задачи создания
корпоративных информационных систем – нуждаются в осмыслении
и анализе. Сложность нынешнего этапа во многом предопределена
традиционализмом и инерционностью мышления, выражающейся
в попытке переноса средств и решений локальной автоматизации в
мир распределенных систем. Этот мир живет по своим законам, которые требуют иных технологий.
Распределенные базы данных в настоящее время занимают особое положение в области информационных технологий и систем, все
более становятся неотъемлемой частью жизни современного человека. Распределенные базы данных стали основой современных информационных систем и существенно повлияли на методы работы
корпораций.
Данное учебное пособие позволит приобрести теоретические
знания и практические навыки работы с распределенными базами
данных и управления распределенной информацией. Пособие посвя3
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
щено освоению важной и перспективной современной информационной технологии (базы данных) и предназначено для студентов направления подготовки 210700 – Инфокоммуникационные технологии
и системы связи, а также для инженеров, чья деятельность непосредственно связана с проектированием и эксплуатацией информационных систем и баз данных. Оно позволит закрепить знания и навыки в
области разработки и реализации распределенных баз данных.
Таким образом, пособие объединяет теорию управления и организации баз данных, а также теоретические основы создания и управления данными распределенной системы баз данных.
Данное пособие позволит студентам без особых сложностей разобраться в исследовании особенностей разработки и управления распределенной базой данных.
В предлагаемом учебном пособии достаточно полно изложено содержание разделов дисциплины «Распределенные базы данных».
4
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1. ПРИНЦИПЫ УПРАВЛЕНИЯ РАСПРЕДЕЛЕННОЙ
ИНФОРМАЦИЕЙ
Рассмотрены основные определения и характеристики распределенных систем баз данных, описаны основные правила для распределенных баз данных, а также управление распределенной информацией (желаемый сценарий).
1.1. Определение и характеристики
распределенных систем баз данных
Ядром системы управления распределенными информационными
ресурсами являются распределенная база данных (РаБД) и система
управления распределенной базой данных (РаСУБД).
Распределенная база данных – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети.
Система управления распределенной базой данных – это программная система, которая обеспечивает управление распределенной базой
данных и прозрачность ее распределенности для пользователей.
Эти определения можно дополнить, если рассмотреть также различные характеристики РаБД и РаСУБД. В 1987 г. К. Дейт опубликовал правила для распределенных баз данных (12 правил), которые
приведены ниже [7]:
1.Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции
безопасности, целостности, представления данных в памяти. Исключением может быть ситуация, когда ограничения целостности охватывают данные нескольких узлов, или когда управление распределенной транзакцией осуществляется некоторым внешним узлом.
2.Никакой конкретный сервис не должен возлагаться на какойлибо специально выделенный центральный узел. Соблюдение этого
правила, т. е. принципа децентрализованности функций РаСУБД, позволяет избежать узких мест.
3.Непрерывность функционирования. Система не должна останавливаться в случае необходимости добавления нового узла или
5
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
удаления в распределенной среде некоторых данных, изменения определения метаданных и даже (что довольно сложно) осуществления
перехода к новой версии СУБД на отдельном узле.
Характеристики распределенной базы данных определяются рядом основополагающих принципов, однако в коммерческих СУБД
большинство этих принципов до сих пор не реализовано. Необходимо, по меньшей мере, найти компромисс между этими принципами,
поскольку в рамках существующих технологий многие из них находятся в противоречии друг с другом.
Некоторые среды РаБД/РаСУБД однородны: локальные менеджеры данных в них представлены одним и тем же продуктом СУБД.
Другие по своей природе разнородны – в них используются разные
продукты СУБД (иногда даже основанные на разных моделях данных, вплоть до плоских файлов).
Некоторые среды создаются «сверху вниз» («с чистого листа»).
Однако более типична ситуация, когда для включения унаследованных систем приходится прибегать к конструированию «снизу вверх».
Конструирование «снизу вверх» оказывается более сложным, поскольку при объединении поддерживающих сред обычно возникают
характерные проблемы избыточности данных, обеспечения непротиворечивости, структурного несоответствия. В некоторых системах
используются различные модели разбиения (фрагментация), которые позволяют распределять данные между различными системами,
обеспечивая возможность трактовать их глобальным образом, как
если бы они были централизованы. Другие модели распределения
предусматривают тиражирование части или всех данных по множеству систем с целью увеличения общей пропускной способности среды и повышения доступности данных.
4.Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.
5.Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться
средствами РаСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом. Более того, РаСУБД
должна уметь обходить при обработке запросов фрагменты, не имеющие к ним отношения (например, РаСУБД должна быть достаточно интеллектуальной, чтобы определять, можно ли исключить при
6
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
обработке запроса тот или иной фрагмент в силу того, что запрос не
содержит ссылок на хранящиеся в этом фрагменте столбцы).
6.Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования, который обсуждается далее.
7.Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом. В [2] рассмотрены некоторые архитектурные принципы реализации РаСУБД и различные
модели, в рамках которых возможна распределенная обработка запросов.
8.Управление распределенными транзакциями. На распределенные базы данных необходимо распространить механизмы управления транзакциями и управления одновременным доступом. Эта
проблема включает выявление и разрешение тупиковых ситуаций,
прерывания по истечении временных интервалов, фиксацию и откат
распределенных транзакций, а также ряд других вопросов.
9.Независимость от оборудования. Одно и то же программное
обеспечение РаСУБД должно выполняться на различных аппаратных
платформах и функционировать в системе в качестве равноправного
партнера. Как уже отмечалось выше, на практике достичь этого исключительно сложно, поскольку многие поставщики поддерживают
множество платформ. Это ограничение преодолевается с помощью
модели многопродуктовых сред.
10. Независимость от операционных систем. Эта проблема тесно
связана с предыдущей, и она также решается аналогичным образом.
Учитывая, что распределенность и неоднородность быстро становятся реальностью для информационных систем (ИС) практически
любой организации, для предотвращения всеобщего хаоса настоятельно необходимо внедрение методов кооперативного управления
рассеянной информацией.
11.Независимость от сети. Узлы могут быть связаны между собой
с помощью множества разнообразных сетевых и коммуникационных
средств. Многоуровневая модель, присущая многим современным
информационным системам (например, семиуровневая модель OSI,
модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой
проблемы не только в среде РаБД, но и для информационных систем
вообще.
7
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
12.Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД.
Очевидно, что хотя крайне желательно было бы иметь системы,
удовлетворяющие всем 12 правилам, но нереально ожидать реализации этих требований в рамках хотя бы одного продукта даже в ближайшие годы. И действительно, за время, прошедшее с момента опубликования правил Дейта, эта цель так и не была достигнута.
Отчасти по этой причине поставщики, ориентирующиеся на рынок распределенных баз данных, придерживаются многоэтапного
подхода к внедрению средств распределения в свои продукты. Одним
из наиболее известных предложений в этой области является выдвинутая в 1989 г. компанией IBM программа, где определены четыре
шага, необходимые для перехода к управлению распределенными
базами данных и призванные обеспечить следующие возможности:
1.Удаленный запрос. Эта парадигма эквивалентна базовой модели удаленного доступа. Выполняется подключение к удаленному
узлу и производится чтение или изменение данных на этом узле. Результат поступает на исходный узел, после чего транзакция завершается. Практически любая коммерческая СУБД в настоящее время
поддерживает удаленные запросы, и такая возможность предоставляется уже в течение некоторого времени.
2.Удаленная единица работы. Это означает, что на удаленном узле
можно выполнить группу запросов как атомарную единицу (транзакцию). Приложение может получать и модифицировать данные многих
узлов, но каждая транзакция затрагивает данные только одного узла.
3.Распределенная единица работы. При этом каждый запрос относится только к одному узлу, но запросы, составляющие распределенную единицу работы (транзакцию), могут выполняться совместно на нескольких узлах. Вся группа запросов при этом фиксируется
или откатывается как одно целое.
4.Распределенный запрос. Этот шаг предусматривает возможность выполнения запросов, охватывающих множество баз данных
на разных узлах. Несколько таких распределенных запросов может
быть далее сгруппировано в качестве транзакции.
Как будет показано в следующем разделе, возможности последнего из четырех шагов – распределенных запросов – могут быть существенно расширены в отношении распределенности и неоднородности.
8
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.2. Управление распределенной информацией:
желаемый сценарий
В результате серии бесконечных объединений и последующих
реструктуризации за последние десятилетия организация, которая
когда-то имела дюжину мэйнфреймов (от одного поставщика), сконцентрированных в трех отделениях в разных географических точках,
откуда осуществлялось управление всей деятельностью фирмы в
мировом масштабе, теперь располагает десятками тысяч компьютеров – от ПК и рабочих станций практически на каждом рабочем
месте до машин среднего класса (от восьми разных поставщиков) в
подразделениях и все тех же мэйнфреймов. Вычислительные машины установлены в сотнях офисов, рассредоточенных по всему миру и
связанных локальными сетями (LAN), объединенными посредством
территориальной сети (WAN) [12].
Система глобальной электронной почты считается одной из самых
развитых в мире: любой сотрудник может взаимодействовать практически с любым подразделением компании. К сожалению, средства доступа к информационным ресурсам не всегда универсальны для соответствующих коммуникационных средств. Рабочие станции, системы
среднего класса и мини-компьютеры, мэйнфреймы – все имеют собственные базы данных и файловые системы, содержащие миллиарды
или даже триллионы битов информации. На ПК могут быть установлены самые разные (реляционные) СУБД. Может использоваться несколько систем семейства Xbase (dBase IV, FoxPro и др.), но на многих
машинах применяются также ParadoxforWindows и MicrosoftAccess.
Предположим, что на компьютерах среднего класса и мэйнфреймах эксплуатируется до десятка разных продуктов СУБД, в основном
реляционных, но также и некоторые системы, поддерживающие другие модели данных. В ряде приложений по-прежнему используются
системы плоских файлов как главный механизм хранения информации. К тому же в двух подразделениях на удаленных узлах ведутся
эксперименты с объектно-ориентированными СУБД для мультимедийных приложений, работающих с голосовой и видеоинформацией,
причем руководство компании выразило пожелание, чтобы любые
виды данных, обрабатываемых этими приложениями, были доступны также и для традиционных информационных запросов.
9
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В дополнение к решаемым в центре обработки данных прикладным задачам предположим, что в стадии разработки находится
крупная новая программа управления товарооборотом. Аппаратное
обеспечение и операционная система для нее еще не определены, но
почти наверняка это будет существенно неоднородная среда, что еще
более усугубляет проблемы управления информацией.
Имеющимся приложениям часто необходимы данные из дополнительных источников, и в тех немногих случаях, когда предоставляется оперативный доступ к ним, он обычно реализуется в виде
последовательности операций выборки данных только для чтения
с использованием средств обеспечения интероперабельности. Целостность данных, некогда тиражированных в таких средах, весьма
сомнительна; также проблематична своевременность доступа к этим
данным и последующей их загрузки в исходное хранилище.
Даже вновь разрабатываемым приложениям требуется распределение данных с глобальной схемой, в рамках которой функционируют
поддерживающие менеджеры данных, оперирующие с порциями информации, размещенными в независимых вычислительных системах.
Вся эта информация представляет собой комбинацию реляционных
табличных данных, мультимедийных объектов (хранимых в среде
либо объектно-ориентированных, либо гибридных объектно-реляционных СУБД) и, возможно, какой-либо гипертекстовой информации.
При этом среда управления информацией должна быть безопасной.
Принимая все это во внимание, можно сформулировать желаемые
потребности следующим образом:
−наличие надстроенной над существующей средой некоторой
«оболочки управления информацией», которая бы исключала избыточность данных, повышая уровень их непротиворечивости и целостности. Приложения должны иметь доступ к удаленным (remote)
данным, а также обладать возможностью их модификации и удаления в соответствии с установленными привилегиями;
−упомянутые выше действия хотелось бы выполнять в контексте
«правильных» принципов распределенной обработки (транзакции и
управление параллельными процессами, контролируемость доступа
и безопасности, скоординированные методы восстановления и т. д.);
−наличие возможности разрабатывать новые приложения относительно некоторого глобального представления данных с последу10
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ющим распределением создаваемых объектов и пользовательских
данных в соответствии с бизнес-правилами, техническими соображениями и прочими факторами, т. е. на ранних стадиях разработки
приложений не должны рассматриваться проблемы физического удаленного доступа;
−новым приложениям необходимо обеспечить доступ и к уже существующим данным, и к вновь создаваемым объектам данных;
−необходимы средства, позволяющие применять наиболее подходящие модели управления информацией для разных компонентов
прикладной среды. Это значит, что в одних случаях вы хотели бы
иметь возможность использовать объектно-ориентированные базы
данных, в других – гипертекстовые среды или иные представления,
при этом данные каждой модели будут доступны любому приложению, даже если оно построено на основе другой модели управления
информацией [10].
К описанной выше среде распределенной информации должны
предъявляться следующие технические требования:
1. Операции доступа к распределенным данным и их модификации должны оптимизироваться с целью максимально эффективного
выполнения. Оптимизация может достигаться за счет удаленного извлечения данных и их последующей пересылки на некоторый промежуточный пункт, где они будут скомбинированы с другими данными
и переданы по назначению; либо все требуемые блоки данных будут
пересылаться непосредственно на запрашивающий узел, где будет
произведена их обработка; либо это будет еще какая-либо возможная альтернатива. Соответствующие решения должны приниматься
в каждом конкретном случае с применением некоторого алгоритма
предварительной оценки затрат.
2. Все традиционные функции СУБД (управление параллельным
доступом, блокирование, безопасность) должны быть расширены с
учетом распределенного характера данных.
3. СУБД должны быть оптимальным образом распределены по
всей этой среде.
4. Распределенными, вероятно, должны стать и метаданные; и все
принципы распределенной обработки, применяемые к пользовательским данным, следует распространить также и на метаданные.
5. Необходимо разработать алгоритмы оценки затрат, соответствующие возможностям и стоимости сетевых средств транспортировки,
11
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
а также другим факторам, связанным с распределенностью данных.
Учитывая динамический, как правило, характер сетевой и коммуникационной среды, алгоритмы оценки затрат должны быть постоянно
обновляемыми.
Перспективой является создание уровня глобального управления
информацией над совокупностью ресурсов данных компании, обеспечивая прозрачный доступ к любым из них и ко всем их компонентам, где бы они ни находились, для операционных целей и для поддержки принятия решений.
Тем не менее, не существует пока единого мнения относительно
реальной ценности этого подхода как оптимального решения для
управления ресурсами данных в масштабах компании. Рассматривая
всевозможные предлагаемые решения в области управления распределенной информацией, можно сравнить относительные достоинства каждого из них с учетом технических вопросов и потребностей
бизнеса.
Для этого необходимо изучить различные модели и методы, позволяющие характеризовать распределенные базы данных, поскольку дальнейшее рассмотрение тенденций и основных направлений
развития потребует четких представлений о том, какие существуют
классы распределенных баз данных [10].
Контрольные вопросы
1. Что является ядром системы управления распределенными информационными ресурсами?
2. Что представляет собой распределенная информация?
3. Какие технические требования предъявляются к среде распределенной информации?
4. Что представляет собой РБД?
5. Каковы правила для распределенных баз данных (12 правил по
Дейту)?
12
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2. МОДЕЛИ РАСПРЕДЕЛЕННЫХ БАЗ ДАННЫХ
Описаны однородные и неоднородные системы и методы построения распределенных баз данных «сверху вниз» и «снизу вверх».
2.1. Однородные и неоднородные системы
Однородные распределенные системы баз данных относительно просты для понимания. Они имеют в своей основе один продукт
СУБД, обычно с единственным языком баз данных (например, SQL
с расширениями для управления распределенными данными). СУБД
с поддержкой однородного распределения являются сильносвязанными системами, их встроенные средства поиска данных и средства
обработки запросов оптимизированы и настроены для достижения
максимальной производительности и пропускной способности. На
рис. 2.1 изображена структура типичной однородной среды распределенной базы данных.
Одинаковые СУБД
Глобальная схема
Фрагмент 1
Фрагмент 2
Фрагмент 3
2
Узел 1
Узел 1
Узел 1
Рис. 2.1. Архитектура однородной распределенной базы данных
Существует множество определений однородной системы РаБД.
Так, на некотором узле может существовать одна глобально доступная «главная машина СУБД», с которой связаны компоненты для
доступа к данным локальных баз данных, размещенные совместно
с самими этими базами данных в пределах всей компании (или от13
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
дельного ее подразделения в зависимости от масштаба распределения). Более сложные модели могут допускать распределенность самой СУБД, когда каждый ее компонент «на равных правах» имеет
доступ к данным любого другого узла. Однако относительно собственно управления данными имеются идентичные модели хранения,
структуры индексирования и форматы данных в рамках всей распределенной среды. Однородные распределенные базы данных обычно
проектируются методом «сверху вниз» [5].
Противоположностью однородных систем РаБД являются неоднородные распределенные системы баз данных. Неоднородные системы включают два или более существенно различающихся продукта управления данными, например, реляционные СУБД от разных
поставщиков (Oracle и Digital Equipment Corp.) или СУБД одного
поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных (DB2 и SQL/DS компании
IBM). На рис. 2.2 показана типичная конфигурация неоднородной
распределенной базы данных. Неоднородные системы баз данных
можно подразделить на классы в широком диапазоне – от федеративных систем до различных типов систем мультибаз данных; существует и формальная таксономия неоднородных моделей.
Различные СУБД
Глобальная схема
Фрагмен
т1
Фрагмен
т2
Фрагмен
т3
Узел 1
Узел 1
Узел 1
Рис. 2.2. Простая конфигурация неоднородной
распределенной базы данных
Как уже отмечалось, однородные распределенные системы баз
данных обычно проектируются методом «сверху вниз», неоднородные чаще всего строятся «снизу вверх» с целью создания общей среды управления над существовавшими ранее разрозненными информационными ресурсами.
14
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2.2. Методы построения распределенных баз
данных «сверху вниз» и «снизу вверх»
Рассмотрим сначала процесс построения распределенных баз данных методом «сверху вниз», поскольку он концептуально наиболее
прост для понимания. Проектирование РаБД «сверху вниз» осуществляется в целом аналогично проектированию централизованных баз
данных. В идеале оно проводится с помощью одной из формальных
методологий, которые включают создание концептуальной модели
базы данных, отображение ее в логическую модель данных и, наконец,
создание (и настройку) специфических для конкретной СУБД структур (например, таблиц базы данных системы Rdb/VMS).
Однако при проектировании РаБД методом «сверху вниз» предполагается, что ее объекты не будут сосредоточены в одном месте, а распределятся по нескольким вычислительным системам (рис. 2.3). Распределение проводится путем фрагментации или тиражирования.
Фрагментация означает декомпозицию объектов базы данных (реляционных таблиц, на две или более частей, которые размещаются
на разных компьютерных системах). Классический пример, который
обычно используют для иллюстрации этого понятия: таблица с данными о сотрудниках или о заказах на продажу, разделенная на фрагменты
по географическому или другому характеристическому признаку.
На рис. 2.4 показана горизонтальная фрагментация: в таблице
делаются горизонтальные «срезы» в соответствии со значением, например, какого-либо столбца таблицы. Строки данных о сотрудниках
могут разбиваться на подмножества, соответствующие филиалам.
Данные о продажах фрагментируются по магазинам, где эти продажи производились. Фрагментация может осуществляться также по
принципу «карусели» (round-robin), а не на основе значений данных.
Альтернативная модель фрагментации – вертикальная – означает
разбиение таблицы не по строкам, а по столбцам (рис. 2.5). В этом
случае некоторая часть информации о каждом сотруднике хранится в
одном месте, а другая часть, относящаяся к той же таблице, в другом.
Независимо от того, применяется горизонтальная или вертикальная фрагментация, поддерживается глобальная схема, позволяющая
воссоздать из имеющихся фрагментов логически централизованную
таблицу или другую структуру базы данных.
15
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Концептуальная модель
Логическая модель
Реализационная модель
Фрагментрированная реализационная модель
Рис. 2.3. Построение распределенной базы данных методом «сверху вниз»
Служащие
Служащие в
Нью-Йорке
Информация о продажах
Служащие в
Филадельфии
Продажи в
Восточном
регионе
Служащие в
Чикаго
Рис. 2.4. Горизонтальная фрагментация
Служащие
Информация
о рейтингах
Персональная
информация
Послужной
список
Рис. 2.5. Вертикальная фрагментация
16
Продажи в
Западном
регионе
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прежде чем перейти к обсуждению тиражирования, обратимся к
практическим аспектам применения фрагментации в реальных базах
данных. На первый взгляд приведенные выше классические примеры
интегрированных, сконструированных «сверху вниз» с последующей
фрагментацией РаБД могут показаться вполне осмысленными, но на
самом деле они весьма далеки от жизни, по крайней мере, в том виде,
в каком они были представлены. Для среды приложения, структура которого показана на рис. 2.4, разумными были бы операции типа:
−обработка платежной ведомости для сотрудников отделения города с помощью приложений, выполняемых в городе;
−запрос статистики о прокате и продажах видеопродукции по
всем отделениям компании, выполняемый менеджерами отделения
какого-либо города, обладающими необходимыми полномочиями.
Идея создания глобальной схемы, поддерживаемой над фрагментированными таблицами, кажется вполне разумной для реализации
подобных задач.
Представителю центрального руководства вряд ли понадобятся
полные данные о продажах или прокате каждой видеокассеты в каждом из магазинов. Его, скорее всего, будет интересовать некоторая
обобщенная информация (например, объем продаж по городу за отчетный месяц в сравнении с предыдущим месяцем или с тем же месяцем предыдущего года).
Очевидно, что в развитой коммерческой организации получение
подобных отчетов предусматривается. Тем не менее, можно не без
оснований утверждать, что модель данных с фрагментацией и средствами воссоздания глобальных данных – не лучший способ достижения таких целей. В сфере управления информацией сейчас активно
формируется школа, сторонники которой считают, что необходимо
проводить различие между операционными базами данных и базами
данных, предназначенными для поддержки принятия решений и других подобных целей.
Учитывая это, можно сделать вывод: идея глобальной схемы над
распределенными фрагментированными данными в действительности не настолько привлекательна, как принято считать. Операции
модификации данных на самом деле кластеризуются относительно локально управляемых данных. Динамические выборки в среде сильно распределенных данных могут поглотить львиную долю
17
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
производительности операционной системы из-за необходимости
многочисленных пересылок больших объемов данных с одного узла
на другой (или другие) только для того, чтобы получить итоговую
информацию. Хотя в однородных РаБД, спроектированных «сверху вниз» с распределением данных путем фрагментации, возможна
«интеллектуализация» формирования планов обработки запросов
(предусматривающая, например, выполнение группирования на удаленном узле и пересылку только обобщенных результатов), однако
полезность этого подхода к задачам реального управления распределенной информацией остается под вопросом.
Параллельные системы баз данных – это одна из наиболее многообещающих моделей фрагментации в аспекте достижения высокой
производительности и пропускной способности.
Рассмотрим второй способ распределения данных – тиражирование. Тиражирование (репликация) означает создание дубликатов
данных. Репликаты – это множество различных физических копий
некоторого объекта базы данных (обычно таблицы), для которых в
соответствии с определенными в базе данных правилами поддерживается синхронизация (идентичность) с некоторой «главной» копией. Теоретически значения всех данных в тиражированных объектах
должны автоматически и незамедлительно синхронизироваться друг
с другом. В некоторых системах копии используются исключительно
в режиме чтения и обновляются в соответствии с заданным расписанием. В других средах допускается модификация отдельных значений в копиях, и эти изменения распространяются в соответствии
с процедурами планирования и координации. На рис. 2.6 показаны
различные модели тиражирования.
Мы рассматрели построение распределенных баз данных «сверху
вниз» с применением фрагментации или тиражирования. Данная идеология применима только к однородным РаБД, для которых вначале
определяется глобальная схема, а затем производится распределение
объектов базы данных. Такой подход оправдан при создании новых
приложений, но гораздо вероятнее, что вашей организации придется
решать задачу создания интегрированной среды путем объединения
существующих баз данных и соответствующих информационных
менеджеров, возможно, в дополнение к некоторым вновь проектируемым компонентам баз данных. В этом случае разработчики не могут
позволить проектирование «сверху вниз».
18
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Транзакция обновления
Дубликат 1
Дубликат 2
Дубликат 3
Одновременное обновление (с управлением параллелизмом)
Транзакция обновления
Дубликат 1
Распространение обновлений
Распространение
обновлений
Дубликат 3
Дубликат 2
Распространенные обновления
Транзакция обновления
Дубликат 1
Запланированные обновления
Запланированные
обновления
Дубликат 2
Дубликат 3
Транзакция чтения
Транзакция чтения
Рис. 2.6. Модели тиражирования данных
Поэтому приходится применять проектирование «снизу вверх»,
где основной проблемой становится объединение схем уже существующих баз данных, чтобы предоставить как новым, так и прежним приложениям доступ и к новым, и к старым ресурсам данных
(рис. 2.7). Таким образом, возникает дисциплина систем мультибаз
данных, где будет показано, что процесс создания любой формы
мультибазы данных всегда нетривиален.
19
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приложение
Глобальная схема
Фрагменты
или
дубликаты
Интегрируется
Вновь разработанные
менеджеры данных
Унаследованные системы
Рис. 2.7. Интеграция распределенных баз данных «снизу вверх»
Контрольные вопросы
1. Что представляют собой однородные распределенные системы?
2.В чем особенности СУБД с поддержкой однородного распределения?
3.В чем отличие архитектуры однородной и неоднородной распределенной базы данных?
4.Каким методом обычно проектируются однородные распределенные базы данных?
5.Что представляют собой неоднородные распределенные системы баз данных?
6.В чем чуть процесса построения распределенных баз данных
методом «сверху вниз»?
7.При проектировании РаБД методом «сверху вниз» распределение проводится путем фрагментации или тиражирования?
8.Что означает фрагментация?
9.Приведите пример фрагментации?
10.В чем отличие горизонтальной и вертикальной фрагментации?
11.Что представляют собой параллельные системы баз данных?
12.В чем суть способа распределения данных – тиражирования?
13.Что такое репликаты?
14.Какие вам известны модели тиражирования?
20
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3. ТЕХНОЛОГИЯ КЛИЕНТ-СЕРВЕР
В БАЗАХ ДАННЫХ И ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ ПРОМЕЖУТОЧНОГО СЛОЯ
Рассмотрены основные принципы и критерии оценки систем клиент-сервер, стандарты архитектуры клиент-сервер в управлении информацией, программное обеспечение промежуточного слоя и интероперабельность баз данных.
3.1. Основные принципы и критерии
оценки систем клиент-сервер
Основы технологии клиент-сервер
Системы терминал – хост. Первые системы совместной эксплуатации информационных и вычислительных ресурсов (системы коллективного пользования) появились в 60‑70-е гг. XX в. Первоначально
операционные системы ЭВМ (ОС) были рассчитаны на пакетную обработку информации, затем с созданием интерактивных терминальных
устройств появилась возможность совместной работы пользователей в
реальном масштабе времени. Основные этапы развития систем доступа к информационным ресурсам включают следующие схемы.
1. Взаимодействие терминала (конечный пользователь, источник
запросов и заданий) и хоста (центральная ЭВМ, держатель всех информационных и вычислительных ресурсов) может осуществляться
как в локальном, так и в удаленном режимах. Во втором случае, как
правило, некоторая совокупность пользователей (дисплейный класс)
размещается в так называемом абонентском пункте – комплексе,
снабженном контроллером (устройством управления), принтером,
концентратором, обеспечивающим параллельную работу пользователей с удаленным хостом. Связь между хостом и абонентским пунктом в этом случае осуществлялась с помощью модемов по телефонным каналам.
2. На следующем этапе формируются сети передачи данных (из
существующих общих и специальных цифровых каналов), позволяющие не только осуществлять более тесное взаимодействие терми21
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
нал – хост, но и обмен хост – хост для реализации распределенных
баз данных и децентрализации процессов обработки информации.
3. Появление и массовое распространение персональных компьютеров выводит на первый план (для массового пользователя) проблему связи ПК – ПК для быстрого резервирования и копирования
информации (в том числе с использованием модемов) и локальные
сети – для совместной эксплуатации баз данных (файл-сервер) и дорогостоящего оборудования. В дальнейшем локальные сети потеряют самостоятельное значение вследствие интеграции с глобальными
сетями в двухуровневые сети, строящиеся по единому принципу в
рамках Internet.
Системы клиент-сервер. Таким образом, по мере развития представлений о распределенных вычислительных процессах и процессах обработки данных складывается концепция архитектуры клиент-сервер – обобщенное представление о взаимодействии двух
компонент информационной технологии (технического и/или программного обеспечения) в вычислительных системах и сетях, среди
которых логически или физически могут быть выделены:
−активная сторона (источник запросов, клиент);
−пассивная сторона (сервер, обслуживание запросов, источник
ответов).
Взаимодействие клиент-сервер в сети осуществляется в соответствии с определенным стандартом или протоколом – совокупностью
соглашений об установлении / прекращении связи и обмене информацией.
Обычно клиент и сервер работают в рамках единого протокола –
Telnet, FTP, Gopher, http и пр., однако в связи с недостаточностью такого подхода появляются мультипротоколъные клиенты и серверы,
например, браузер Netscape Navigator. Наконец, появляются серверные приложения (брокеры, роботы), которые устанавливаются между разнопротокольными компонентамии и осуществляют трансформацию протоколов.
Процесс-сервер, процесс-клиент. Компьютер (процесс), управляющий тем или иным ресурсом, является сервером этого ресурса, а
компьютер, пользующийся им, является клиентом.
Каждый конкретный сервер определяется видом того ресурса, которым он владеет. Например, назначением сервера баз данных яв22
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ляется обслуживание запросов клиентов, связанных с обработкой
данных; файловый сервер или файл-сервер распоряжается файловой
системой и т. д.
Этот принцип распространяется и на взаимодействие программ.
Программа, выполняющая предоставление соответствующего набора услуг, рассматривается в качестве сервера, а программы, пользующиеся этими услугами, принято называть клиентами. Программы
имеют распределенный характер, т. е. одна часть функций прикладной программы реализуется в программе-клиенте, а другая – в программе-сервере, а для их взаимодействия определяется некоторый
протокол.
Схема взаимодействия клиента и сервера
Один из основных принципов технологии клиент-сервер заключается в разделении функций стандартного интерактивного (диалогового) приложения на четыре группы, имеющие различную природу.
Первая группа – функции ввода и отображения данных.
Вторая группа – объединяет чисто прикладные функции, характерные для данной предметной области (например, для банковской системы – открытие счета, перевод денег с одного счета на другой и т. д.).
Третья группа – фундаментальные функции хранения и управления информационно-вычислительными ресурсами (базами данных,
файловыми системами и т. д.).
Четвертая группа – служебные функции, осуществляющие связь
между функциями первых трех групп.
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
−компонент представления (presentation), реализующий функции
первой группы;
−прикладной компонент (business application), поддерживающий
функции второй группы;
−компонент доступа к информационным ресурсам (resource
manager), поддерживающий функции третьей группы, а также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).
Различия в реализации технологии клиент-сервер определяются
следующими факторами:
23
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
−виды программного обеспечения, в которые интегрирован каждый из этих компонентов;
−механизмы программного обеспечения, используемые для реализации функций всех трех групп;
−способы распределения логических компонентов между компьютерами в сети;
−механизмы, используемые для связи компонентов между собой.
Выделяются четыре подхода, реализованные в следующих технологиях:
−файловый сервер (File Server – FS);
−доступ к удаленным данным (Remote Data Access – RDA);
−сервер баз данных (Data Base Server – DBS).
Использование технологии клиент-сервер может появиться в следующем случае. Допустим, существует приложение, которое обращается к данным, постоянно находящимся в локальной сети или на
файловом сервере. Внутри одного подразделения к этому приложению
могут обратиться одновременно несколько пользователей, а со временем появляются и другие приложения для работы с этими данными.
Предположим, что эти данные представляют интерес и для других подразделений внутри организации. Теперь в этих подразделениях должны быть созданы дополнительные приложения. При этом
необходимо переместить данные на сервер для того, чтобы сделать
их доступнее для всех пользователей. Поскольку это происходит на
уровне организации, поэтому важно, чтобы используемое решение
позволяло осуществить доступ к данным не только быстро, но и в
необходимом для приложения виде.
Рис. 3.1, хотя и весьма упрощен, но иллюстрирует ситуацию, при
которой можно рассматривать необходимость использования технологии клиент-сервер.
Клиентское
приложение
Сервер базы
данных
Клиентское
приложение
Клиентское
приложение
Рис. 3.1. Классическая архитектура клиент-сервер
24
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
С конца 80-х годов прошлого века происходит внедрение стандартов в среду клиент-сервер. Усилия по выработке стандартов, таких,
как RDA (Remote Database Access), DRDA (Distributed Relational Database Architecture), IDAPI (Integrated Database Application Programming Interface), DAL (Data Access Language) и ODBC (Open Data Base
Connectivity) были направлены на улучшение работы архитектуры
клиент-сервер. В идеале она должна способствовать использованию
средств различных поставщиков в корпоративных системах, обеспечивая в частности переход на новые компьютерные платформы,
операционные системы и/или прикладные программы, исходя из
потребностей бизнеса. Причем такой переход должен проходить без
нарушения функционирования полной информационной системы.
В наше время в области управления базами данных появляются стандарты, способствующие расширению возможностей использования
средств различных поставщиков. Усиливается тенденция применения
программного обеспечения промежуточного слоя (middleware), т. е.
стандартизованных программных средств, которые берут на себя специфические системные функции, позволяя компонентам и клиента, и
сервера абстрагироваться от них. Хотя использование программного
обеспечения промежуточного слоя предполагает более сложную архитектуру, чем простое непосредственное соединение клиента с сервером, можно ожидать, что оно будет способствовать долговременной
эволюции информационных систем, а также создаст необходимую
основу для решения проблемы унаследованных систем.
Идея, на которой основана технология клиент-сервер, в применении ее к вычислительным системам вообще или к управлению информацией в частности исключительно проста. Архитектура клиентсервер предполагает разделение труда в масштабах вычислительной
системы компании или подразделения (либо малого предприятия).
Клиентские системы, с которыми имеют дело пользователи, взаимодействуют с серверами, предоставляющими некоторый формальный
набор сервисов (коммуникации, управление базами данных, поддержка репозитория, глобальное именование и др.). Разделение труда
происходит в основном за счет вынесения функций, ориентированных на пользователя, в клиентские системы (обычно функционирующие на ПК или рабочих станциях). Такое решение обладает целым
рядом преимуществ.
25
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Клиентское
приложение
Интерфейс
Интерфейс
Серверные компоненты
приложения (старая
серверная платформа)
Рис. 3.2. Простейшая среда клиент-сервер
Ниже приведено несколько примеров функций, ориентированных
на пользователя:
− создание и проверка допустимости запросов к базе данных и
операций модификации данных;
− получение информации с сервера и представление результатов
пользователю в соответствии с заранее определенными экранными
формами или шаблонами;
− накопление статистической информации, предоставляемой системой в целом (например, статистика произведенных операций), и
представление этой информации для пользователя в соответствии с
некоторыми шаблонами или иными правилами представления.
На рис. 3.1, 3.2 приведено концептуальное представление типичной среды клиент-сервер.
Конфигурации и архитектуры клиент-сервер могут существовать
как в локальных сетях (Local Area Network, LAN), в сетях крупных
городов (Metropolitan Area Network, MAN) или в больших территориальных сетях (Wide Area Network, WAN), так и на одном процессоре (например, один процесс выполняет функции клиента, а другой
– функции сервера). В этой главе мы рассмотрим распределенные
архитектуры клиент-сервер.
Архитектура клиент-сервер дает множество преимуществ в организации информационных систем.
Во-первых, как показала революционная экспансия персональных
компьютеров, оснащение каждого рабочего места собственными вычислительными мощностями дает колоссальный скачок производительности труда персонала.
Во-вторых, связывание корпоративных данных за счет применения технологий клиент-сервер может обеспечить целостное представление данных для пользователей.
Отказ от устаревших программ, основанных на собственных интерфейсах, разработанных традиционным образом, позволят переве26
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
сти корпоративную вычислительную среду клиент-сервер на рельсы
стандартизованных, способных развиваться технологий.
Ниже приведены основные принципы и критерии оценки систем
клиент-сервер:
1. Переносимость означает возможность переноса как клиентской, так и серверной базы либо их обеих на новую платформу без
нарушения работоспособности среды приложений (рис. 3.3).
Клиентское
приложение (старая
клиентская
платформа)
интерфейс
Клиентское
приложение (новая
клиентская
платформа)
интерфейс
Серверные
компоненты
приложения
интерфейс
Рис. 3.3. Переносимость в среде клиент-сервер
2. Взаимозаменяемость – это возможность подменить клиента или
сервер другим программным продуктом с сохранением интерфейса.
Например, при подключении в качестве сервера баз данных продукта вместо продукта в клиентские приложения, взаимодействующие с
этим сервером (рис. 3.4), не придется вносить какие-либо изменения.
Клиентское
приложение
интерфейс
интерфейс
Серверные
компонентыприложения
(старая серверная
платформа)
Серверные компоненты
приложения (новая
серверная платформа)
Рис. 3.4. Взаимозаменяемость в среде клиент-сервер
3. Сохранение автономности сервера. Клиенты должны следовать
правилам, установленным серверами; они не должны ограничивать
доступность серверов и не должны нарушать целостность каких-либо данных сервера.
4. Сохранение автономности клиента. Способ функционирования
клиента не должен зависеть от того, подключается ли он к удаленно27
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
му или локальному серверу БД; пользователи должны быть изолированы от аспектов, связанных с местоположением данных.
5. Поддержка независимости приложений от сервера. Клиент
должен вести себя независимо от того, к какому из серверов он осуществляет доступ, каков тип удаленной аппаратной платформы, операционной системы и какие используются сервисы.
6. Доступность специфических средств сервера. Клиент может запросить некоторые специфические функции конкретного сервера для
более качественного выполнения работы.
7. Поддержка доступа к реальным данным. Операции доступа и
модификации данных должны основываться на самих данных в сервере, а не на процедурах загрузки и выгрузки файлов данных.
8. Минимум дополнительных требований к рабочей станции для
доступа к серверу. Программное обеспечение клиента не должно
быть ресурсоемким.
9. Полнота вариантов соединения. Клиентское программное обеспечение не должно требовать дополнительного программирования
для выполнения соединения с сервером, хотя соединения с сервером
могут осуществляться при посредстве коммуникационных серверов
или средств других архитектурных уровней. Должна быть также доступна возможность прямых соединений.
10. Возможность локального прототипирования. Удаленность информации не должна препятствовать возможности прототипирования пользовательских приложений.
11. Полнота пользовательского инструментария. В состав среды
должны входить инструментальные средства для создания экранных
форм, генерации запросов и т. п.
12. Полнота среды разработки пользовательских приложений.
Среда разработки должна включать средства для установления сетевых соединений и управления ими, доступ к сервисам глобального
именования и местонахождения данных и др.
13. Открытая среда включающих языков. Должны быть доступны
средства программирования, позволяющие расширять возможности
инструментальных средств для конечного пользователя и предопределенных сервисов доступа.
14. Следование стандартам. Чем в большей мере будут поддерживаться стандарты, тем меньше будет возникать проблем с интероперабельностью компонентов.
28
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Клиентские приложения
Серверные части приложений или хранимые
процедуры
Менеджеры распределенных ресурсов данных
Рис. 3.5. Доступ, основанный на архитектуре клиент-сервер
3.2. Стандарты архитектуры клиент-сервер
в управлении информации
В области интерфейсов систем баз данных для соединений клиент-сервер происходит интенсивный процесс стандартизации – положительный момент; отрицательный момент – наличие множества
стандартов. Конкретный стандарт API или множество протоколов
поддерживается на сегодншний день не тремя – четырьмя поставщиками, как прежде, а двадцатью или тридцатью, но не всеми поставщиками, предлагающими подобные продукты.
Поэтому наличие нескольких стандартов не является отрицательной чертой. Любой процесс стандартизации сопровождается, как
правило, критикой по поводу того, что в попытках достижения полного множества решений для возможно большего числа различных
сред приходится оставлять за рамками стандарта некоторые характеристики, полезные в ряде случаев, предоставляя поставщикам реализовать их в качестве собственных расширений. Имея несколько
альтернативных вариантов стандартов, организации, внедряющие в
свои среды управления данными технологию клиент-сервер, могут
выбрать решения, наиболее полно соответствующие их конкретным
потребностям.
29
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
SQL Access Group истандарт DRDA
Процесс стандартизации доступа к базам данных клиент-сервер
приобрел наибольшую активность в конце 80-х – начале 90-х гг.
В 1989 г. образовалась группа SQL Access Group (SAG). Она представляет собой консорциум из 42 компаний, в число которых входят
крупнейшие поставщики СУБД и различных инструментальных
средств систем баз данных.
Одной из задач SAG было определение спецификаций форматов и
протоколов (Formats And Protocols, FAP) для коммуникаций в системах баз данных клиент-сервер на основе спецификаций удаленного
доступа к базам данных (Remote Database Access, RDA), разработанных Международной организацией по стандартизации (International
Standards Organization, ISO). Стандарт RDA описан в документе ISO/
IEC 9579: информационные технологии – языки баз данных – удаленный доступ к базам данных (ISO/IEC 9579, Information Technology
Database Languages – Remote Database Access), который состоит из
двух частей: общая модель, сервис и протокол (Generic Model, Service
and Protocol) и специализация SQL (SQL Specialization). Вторая часть
этого документа и стала основой спецификаций FAP, предложенных
группой SAG.
Спецификации FAP включают описание структуры сообщений и
протокола управления информацией, используемых для связи между компонентами, обменивающимися информацией, например, для
управляющих структур, которые сообщают данному узлу о том, что
передается единица данных с указанным номером блока, или подтверждают прием сообщения с определенным номером [10].
Примерно в то же время компания IBM, единственный крупный
поставщик средств для баз данных, не вошедший в группу SAG,
ввела стандарт «Архитектура распределенных реляционных баз данных» (Distributed Relational Database Architecture, DRDA), никак не
согласующийся с ISO RDA (хотя обе эти аббревиатуры содержат три
общие буквы, тем не менее, буквы «R» и «А» в названиях этих стандартов означают разные слова).
SQL Access Group (SAG):
− спецификации на основе стандарта ISO RDA;
− цель – стандарт де-юре;
− «открытые» компоненты.
30
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
DRDA:
− исходная цель – доступ к базам данных IBM в рамках SAA;
− возможность стать стандартом де-факто;
− использует компоненты IBM.
Исходной целью DRDA являлась интеграция баз данных в рамках
системной архитектуры приложений (System Application Architecture,
SAA), предложенной IBM. Изначально SAA рассматривалась как
главное средство интеграции для четырех платформ IBM (MVS, VM,
OS/400 и OS/2). Используя DRDA и SAA, можно объединить менеджеры баз данных для этих платформ (DB2, SQL/DS, OS/400 Data
Manager и OS/2 Extended Edition Database Manager соответственно) в
единую модель клиент-сервер.
В 1991 г. IBM предложила архитектуру хранилища информации
(Information Warehouse), в которой DRDA была отведена ключевая
роль в интеграции баз данных клиент-сервер, управляемых различными программными продуктами, и ряд поставщиков средств баз
данных объявили о своей поддержке DRDA. Таким образом, в начале
1992 г. в области стандартизации доступа к базам данных клиентсервер образовалось два «лагеря»: SAG, опирающаяся на стандарт
RDA, и сторонники DRDA, ориентированного на платформы IBM.
Поскольку SAG представляла и представляет инициативу множества поставщиков, направленную на процесс формальной стандартизации, то результат ее усилий станет стандартом де-юре, учрежденным организациями по стандартизации посредством формальных
процедур. Напротив, DRDA, несмотря на поддержку ряда поставщиков, может иметь лишь статус корпоративного стандарта компании
IBM подобно другим спецификациям, предложенным IBM (SNA или
коммуникации с помощью терминала 3270).
Между спецификациями SAG и DRDA существует ряд технических различий. Поскольку спецификации FAP, предложенные SAG,
основаны на ISO RDA, то компоненты ISO, в том числе абстрактный
синтаксис ASN.l (Abstract Syntax Notation, ASN) и базовые правила
кодирования (Basic Encoding Rules, BER) для ASN.l, используются в
качестве синтаксиса передачи сообщений (Transfer Syntax), хотя синтаксис фактических сообщений устанавливается индивидуально для
каждого соединения путем согласования. В отличие от этого DRDA
опирается на архитектуру управления распределенными данными
IBM (Distributed Data Management, DDM), а именно на ее третий уро31
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
вень, который определяет абстрактный синтаксис и правила кодирования команд и ответных сообщений. Для представления данных и
метаданных в DRDA используется архитектура IBM FD:OCA, применяемая также для представления сложных документов.
Стандарты, основанные на интерфейсе
уровня вызовов SAG
В 1992 г. возникли сразу два конкурирующих стандарта – ODBC
и IDAPI, и оба они основаны на интерфейсе уровня вызовов (CallLevel Interface, CLI), предложенном SAG. Первый из них – открытый интерфейс доступа к базам данных (Open DataBase Connectivity,
ODBC) был введен и активно продвигался компанией Microsoft. Целью Microsoft было предоставление приложениям Microsoft Windows
доступа к базам данных, основанным на SQL, посредством стандартизованного интерфейса клиент-сервер (рис. 3.6). Главное назначение ODBC – превратить SAG CLI из абстрактного обобщенного
стандарта в живую среду, в которой он может непосредственно использоваться в приложениях для ПК [9].
Приложение
Microsoft
Widows
ODBC
ODBC
Сервер
Рис. 3.6. Архитектура ODBC
Несколькими месяцами позже, в ноябре 1992 г., группа компаний под руководством Borland (включающая также IBM, Novell и
WordPerfect) объявила аналогичный стандарт интерфейса для систем
баз данных клиент-сервер, также основанный на SAG CLI и получивший название интерфейса прикладного программирования для
интегрированных систем баз данных (Integrated Database Application
Programming Interface, IDAPI). Архитектура IDAPI показана на рис.
3.7. Стандарт IDAPI концептуально аналогичен ODBC. Оба стандарта
специфицируют интерфейсы клиент-сервер, основанные на SAG CLI,
но IDAPI изначально был ориентирован, помимо Microsoft Windows,
также и на другие платформы и предоставлял в дополнение к SQLдоступу также и навигационный доступ к серверам баз данных.
Стандарт IDAPI пришел на смену другому корпоративному стандарту компании Borland – интерфейсу прикладного программирова32
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ния объектных баз данных (Object Database API, ODAPI), который
был частью компонентной объектной архитектуры Borland (Borland
Object Component Architecture, BOCA).
Стандарт IDAPI обеспечивает поддержку серверов dBase (см.
рис. 3.7). Большинство программ dBase использует навигационный
доступ к базам данных (например, модель обновления мастер-таблицы с применением транзакционной таблицы, двунаправленный
просмотр информации в таблицах и т. п.), а не SQL-подобные операции уровня множеств. Поэтому IDAPI в своем интерфейсе содержит
навигационный компонент NAV/CLI, который позволяет иметь на
серверной стороне вновь создаваемых сред приложений существующие базы данных dBase (системы баз данных, унаследованные из
мира ПК). То же можно сказать и о других драйверах серверной части IDAPI, например, о СУБД Paradox компании Borland.
Пользовательское
приложение
Пользовательское
приложение
IDAPI API (SQL\CLI и NAV\CLI)
Технология IDAPI
Драйвер
dBase
Драйвер
Oracle
Драйвер
DB2
Драйвер Sybase
Рис. 3.7. Техническая архитектура IDAPI
На рис. 3.8 показано соотношение между стандартами ODBC и
IDAPI сегодня и, возможно, в будущем. Когда был объявлен стандарт
IDAPI, председатель труппы SAG заявил, что SAG изучит содержащиеся в IDAPI расширения базового стандарта SAG CLI, и это означает, что навигационные средства, возможно, будут введены также и
в SAG CLI.
Материалы проекта спецификаций IDAPI содержали 149 страниц
описаний операторов уровня вызовов как части интерфейса прикладного программирования (Application Programming Interface, API).
Эти операторы были разделены на следующие категории:
1.Среда и соединения. Открытие и закрытие соединений с серверами, управление дескрипторами (handles), управление курсорами.
33
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2.Ресурсы и возможности. Управление конфигурационными файлами.
3.Каталоги и схемы. Управление путями доступа к схемной информации.
4.Подготовка и выполнение операторов. Функции для прямого
выполнения SQL-операторов, подготовки и последующего выполнения операторов, получения количества строк, затрагиваемых тем или
иным оператором SQL, и т. п.
5.Определение данных. Создание и модификация таблиц, создание индексов, уничтожение таблиц и индексов.
6.Манипулирование данными. Обновление и удаление строк,
управление блокировками строк и таблиц, управление большими бинарными объектами (Binary Large OBject, BLOB), открытие курсоров.
7.Управление транзакциями. Фиксация и откат транзакций, а также функции отмены выполнения отдельных SQL-операторов.
8.Диагностика. Возврат информации об ошибках.
9.Расширения, специфические для конкретных СУБД/операционных систем. Управление паролями, управление файлами, другие
системозависимые функции.
10.Разное. В настоящее время эта категория содержит один оператор, находящий первую строку, ключ которой сопоставляется с некоторым заданным значением (аналог операторов FIND или SEEK в
языке Хbаsе).
IDAPI
SQL/CLI
NAW/CLI
Другие
возможности
Стандарт
SQL/CLI
Развивается
в направлении
ODBC
Развивается
в направлении
Рис. 3.8. Стандарты ODBC и IDAPI сегодня и завтра
Читатели, которым интересно ознакомиться с типами операторов,
включенными в спецификации рассматриваемых стандартов, могут
обратиться непосредственно к Проекту IDAPI (Working Draft IDAPI),
доступному от Borland, или к аналогичным документам ODBC, доступным от Microsoft.
34
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.3. Программное обеспечение
промежуточного слоя
Стандартизованные интерфейсы клиент-сервер в последние годы
принято относить к категории программного обеспечения промежуточного слоя, которое определяется как некоторый набор процедур
или функций, обеспечивающих взаимодействие двух разнородных
программ; это своего рода клей. Программные средства этой категории применимы к компьютерным сервисам практически любого вида,
включая управление базами данных и информацией. Коммерческие
или самостоятельно разработанные программные продукты, основанные на IDAPI, ODBC, DRDA или других стандартах и предоставляющие интерфейсные возможности для клиента и сервера, относятся к
категории программного обеспечения промежуточного слоя.
Стандартизация программного обеспечения промежуточного слоя
представляет особый интерес, поскольку оказывает воздействие на
перспективные направления развития в области управления информацией в архитектуре клиент-сервер. Аналогичным образом процесс
стандартизации охватывает такие области, как коммуникации, управление объектами, электронная почта и др. Системы управления информацией завтрашнего дня неизбежно будут обеспечивать не только
доступ к базам данных клиент-сервер (посредством сетевых и коммуникационных сервисов), но также управление электронной почтой
и другие функции. Следовательно, необходим общий анализ требований к программному обеспечению промежуточного слоя.
Сервисы программного обеспечения промежуточного слоя
Сервис ПО промежуточного слоя определяется интерфейсами
прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций.
Как и многие системные категории, ПО промежуточного слоя трудно точно определить в техническом смысле. Тем не менее, его компоненты обладают рядом свойств, которые обычно ясно свидетельствуют о том, что данный компонент не является сервисом, специфичным
для приложения или платформы. Компоненты ПО промежуточного
слоя являются общими для различных приложений и прикладных об35
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ластей; они функционируют на разных платформах, распределены и
поддерживают стандартные интерфейсы и протоколы. Эти свойства:
1. Сервис ПО промежуточного слоя отвечает потребностям широкого спектра приложений многих прикладных областей. Сервис ПО
промежуточного слоя должен иметь реализации для разных платформ. В противном случае – это специфический сервис платформы.
Например, системы управления реляционными базами (СУБД) – это
ПО промежуточного слоя. Чтобы охватить как можно больше платформ, сервисы ПО промежуточного слоя разрабатывается как переносимые (portable). Это означает, что их можно перенести (портировать) на другую платформу, предприняв для этого небольшие и заранее предсказуемые усилия.
2. Сервис ПО промежуточного слоя является распределенным.
Это означает, что к нему возможен удаленный доступ (например, сервис СУБД), либо он обеспечивает удаленный доступ к другим сервисам и приложениям (например, коммуникационный сервис).
3. В идеале сервис ПО промежуточного слоя поддерживает
стандартный протокол или, по крайней мере, опубликованный
протокол. Таким образом, можно разработать множество реализаций сервиса, и все они будут взаимодействовать между собой. Однако если сервис ПО промежуточного слоя действительно работает на всех популярных платформах, его можно рассматривать как
стандартный, даже если его протоколы не опубликованы. Таким
свойством обладает, например, большинство СУБД. Если охват
платформ достаточно широк, потребители, как правило, не требуют от производителей соответствия стандарту протокола. Например, протокол клиент/сервер SQL Access Group не снискал широкого признания, хотя принятый этим консорциумом интерфейс
прикладного программирования ODBC имеет большой успех, поскольку Microsoft обеспечила его поддержку в своем семействе
операционных систем Windows.
4. Сервис ПО промежуточного слоя должен поддерживать стандартный API. Он (сервис) является прозрачным (transparent) по отношению к API, если к нему обеспечен доступ посредством API,
но при этом не требуется модификация последнего. Непрозрачное
(nontransparent) ПО промежуточного слоя требует нового API.
36
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приложение
Приложение
ПО промежуточного слоя (сервисы
распределенных систем)
Платформа:
- операционная система,
- компьютер
Платформа:
- операционная система,
- компьютер
Рис. 3.9. Программное обеспечение промежуточного слоя
5. Если производитель ПО обеспечивает широкий охват платформ
и обладает значительной долей рынка, то поддерживаемый им интерфейс прикладного программирования и протокол можно рассматривать как фактический стандарт, даже если ни интерфейс, ни протокол
не имеют в виду другие производители. Например, в реляционных
СУБД ORACLE и SYBASE поддерживаются собственные диалекты
языка SQL, и при этом они рассматриваются большинством потребителей как фактический стандарт.
Основное назначение сервисов ПО промежуточного слоя: они
(сервисы) обеспечивают интерфейс прикладного программирования,
не зависящий от платформы, так что приложения будут работать на
многих платформах. Они скрывают детали сетевых протоколов и
распределенных систем. Сервисы ПО промежуточного слоя разрабатываются таким образом, чтобы встроить общеупотребительные
функции в независимые компоненты, которые затем можно распределить по различным платформам и программным средам.
Но сервисы ПО промежуточного слоя имеют недостатки:
1. Многие популярные сервисы ПО промежуточного слоя используют собственные интерфейсы прикладного программирования. Изза этого приложения обычно оказываются зависимыми от программного продукта одного производителя.
2. Препятствием к использованию сервисов ПО промежуточного
слоя является их огромное количество. Чтобы сохранить среду программирования простой, управляемой и обозримой, разработчики
выбирают небольшое число сервисов, которые отвечают их требованиям к функциональности и спектру платформ.
37
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Интегрирующая среда (framework) – это среда программирования,
которая спроектирована с целью упрощения разработки и администрирования специализированных приложений. Интегрирующая среда – это один из видов ПО промежуточного слоя. Примеры ИС – это
офисные системы (Lotus Notes, Microsoft Office), мониторы транзакций (IBM CICS, DEC ACMSxp), языки четвертого поколения (Uniface,
Cognos, Focus), системы автоматизированного проектирования (Mentor
Graphics Falcon, DEC Powerframe), CASE-системы (HP SoftBench,
Texas Instruments Composer by IEF, Andersen Consulting Foundation,
DEC COHESIONworX), и системы управления распределенными ресурсами (HP OpenView, Tivoli Management Environment, IBM NetView).
Интерфейс с
пользователем
Приложение
приложение
Преобразование
вызовов
сервисов ПО
промежуточного
слоя
инструменты
Частные сервисы
ИС
ПО промежуточного слоя (сервисы распределенной системы)
Платформа
- Операционная система
- Компьютер
Платформа
-Операционная система
- Компьютер
Рис. 3.10. Архитектура интегрирующей среды
Иногда сервисы ПО промежуточного слоя вырастают до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Из элементарных интерактивных средств формирования и выполнения SQL-запросов они превратились в сложные
системы с комплексным набором инструментов. Интегрирующая
среда опирается на сервисы ПО промежуточного слоя. Все больше
и больше вновь разрабатываемых приложений уходят от непосредственного вызова сервисов ПО промежуточного слоя и опираются
в основном на сервисы интегрирующей среды. Причина состоит в
слишком большом разнообразии и разнородности сервисов ПО промежуточного слоя.
38
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.4. Интероперабельность баз данных
Наше обсуждение в этой главе было бы неполным, если бы мы
не рассмотрели перспективы развития других механизмов интеграции баз данных, в частности шлюзов баз данных. Мы уже отмечали,
что парадигма клиент-сервер подразумевает не только распределение
вычислительных ресурсов, но и формальное разделение функций
между этими ресурсами.
СУБД
Приложение
Утилита
доступа
СУБД
6
2
1
Шлюз базы
данных
5
Локальная база
данных
1
2
3
4
5
6
3
4
Локальная база
данных
– запрос удаленного доступа к данным;
– вызов удаленной СУБД;
– извлечение данных;
– возвращение данных на шлюз;
– возвращение данных утилите;
– сохранение данных в локальной базе данных.
Рис. 3.11. Простая архитектура с шлюзом баз данных
Серверные
компоненты
приложения
Брокер
объектных
запросов
(ORB)
Брокер
объектных
запросов
(ORB)
Клиентское
приложение (новая
клиентская
платформа)
Серверные
компоненты
приложения
Рис.3.12. Подход с использованием брокера объектных запросов
к управлению информацией в архитектуре клиент-сервер
39
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приступая к реализации среды клиент-сервер, нельзя не принимать в расчет существование во многих организациях унаследованных систем и огромных объемов данных, находящихся под их управлением.
Традиционным механизмом интеграции баз данных были шлюзы
(рис. 3.11), обеспечивающие разные уровни интероперабельности –
от простых выборок данных до управляемых приложением средств
чтения-записи. Применение программного обеспечения промежуточного слоя было спорадическим, цели его варьировались от попыток
предоставить некоторый уровень абстракции до прямого управления
доступом к шлюзу со стороны приложений [11].
В ближайшие годы число вариаций парадигмы клиент-сервер будет расти, но шлюзы не утратят своего значения. Информационные
системы многих организаций не так легко будет перенести в среду
клиент-сервер по многим причинам, в том числе в связи с закрытым
характером архитектуры существующих приложений и недостаточностью аппаратных средств. Однако стремление к повышению уровня интеграции баз данных остается. Поэтому в таких организациях
по-прежнему будут применяться шлюзы, пусть даже как переходное
решение на период, пока не будут созданы условия для реализации
среды клиент-сервер.
Существует еще один подход к унаследованным системам в период перехода к архитектуре клиент-сервер. Он заключается в использовании брокеров объектных запросов (Object Request Broker, ORB),
основанных на архитектуре клиент-сервер. При этом существующие
или вновь разрабатываемые необъектные клиентские или серверные
компоненты приложения помещаются в объектно-ориентированные
оболочки (Wrapper). Это позволяет клиентам и серверам взаимодействовать посредством объектно-ориентированных методов. На
рис. 3.12. показано, как функционирует среда с ORB [11].
Контрольныевопросы
1.Как осуществляется взаимодействие в системе клиент-сервер?
2.Каково назначение серверных приложений?
3.Какова схема взаимодействия клиента и сервера?
4.Какими факторами определяются различия в реализации технологии клиент-сервер?
40
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5.Что представляет собой простейшая среда клиент-сервер?
6.Каковы основные принципы и критерии оценки систем клиентсервер?
7.Каковы стандарты архитектуры клиент-сервер?
8.Относятся ли стандартизованные интерфейсы клиент-сервер к
категории программного обеспечения промежуточного слоя?
9.Что представляет собой программное обеспечение промежуточного слоя?
10. Что представляет собой стандартизация программного обеспечения промежуточного слоя?
41
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4. ХРАНИЛИЩА ДАННЫХ
Представлены принципы построения хранилищ данных, множественность носителей информации, агрегирование данных, распределенные хранилища данных, а также рассмотрены хранилища
данных и другие технологии управления информацией, цифровые
библиотеки и информационные магистрали.
4.1. Принципы построения хранилищ данных
Хранилища данных – это процесс сбора, отсеивания и предварительной обработки данных с целью представления результирующей
информации пользователям для статистического анализа и аналитических отчетов. Ральф Кинболл (автор концепции хранилищ данных)
описывал хранилища данных как место, где люди могут получить доступ к своим данным. Он же сформулировал основные требования к
хранилищам данных:
– поддержка высокой скорости данных из хранилища;
– поддержка внутренней непротиворечивости данных;
– возможность получения и сравнения данных;
– наличие удобных утилит просмотра данных хранилища;
– полнота и достоверность хранимых данных;
– поддержка качественного процесса пополнения данных.
Всем перечисленным требованиям удовлетворять зачастую не
удается, поэтому для реализации хранилищ данных используют несколько продуктов; одни – средства хранения данных, другие – средства их извлечения и просмотра, третьи – средства пополнения хранилищ данных [6]. Типичное хранилище данных, как правило, отличается от реляционной базы данных:
1) обычная база данных предназначена для того, чтобы помочь
пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений;
2) обычная база данных подвержена постоянным изменениям в
процессе работы пользователей, а хранилище данных относительно
стабильно; данные в нем обновляются согласно расписанию (например, ежечасно, ежедневно, ежемесячно), в идеале, процесс пополнения данными за определенный период времени без изменения прежней информации находящейся уже в хранилище;
42
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3) обычная база данных чаще всего является источником данных,
попадающих в хранилище; кроме того, хранилище может пополняться за счет внешних источников (например, сжатия данных) [10].
Хранилище данных – это логически интегрированный источник
данных для приложений систем поддержки принятия решений (DSS)
и информационных систем руководителя (EIS). Мы говорим о логической интегрированности, потому что некоторые простые среды
хранилищ данных, которые мы обсудим далее, могут быть централизованными (независимо от того, распределенными или централизованными являются сами источники данных для них). Однако наиболее подходящими по мере роста популярности хранилищ данных
станут, вероятно, распределенные архитектуры.
Приложение 1
Операции
чтения/записи
над базой
данных
Информационная
система руководителя
Приложение 2
Информационные
запросы
Операции чтения/записи над
базой данных
Операционная база данных
Периодическое пополнение содержимого хранилища данных
Хранилище
данных
Рис. 4.1. Базовая архитектура хранилища данных
На рис. 4.1 показана простейшая архитектура хранилища данных.
Информация извлекается из операционной среды управления информацией (как правило, из одной или более баз данных) в соответствии
с определенными принципами и загружается в хранилище данных.
Более сложная архитектура – это информационная поддержка принятия решений, а не собственно каждодневной деятельности организации; многие принципы технологий баз данных утрачивают для них
свое значение.
Хранилище данных обычно ориентируется на определенную предметную область и организуется на основе некоторого подмножества
43
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
данных операционной базы данных. Источниками данных для них являются различные приложения, которые могут выполняться на разных
платформах, следовательно, необходимы средства интеграции. Эти
данные агрегируются в различной степени, а не представляются в виде
отдельных экземпляров, как в операционной базе данных. Данные,
поступившие в среду хранилища данных, приобретают статус неизменчивых, т. е. вносимые изменения могут иметь характер только пополнения (например, путем регулярных плановых выборок из операционных баз данных), а не произвольных поэлементных обновлений,
как в операционных базах данных. Процесс пополнения обычно включает сложные процедуры устранения несоответствия типов, размеров,
кодировок и других свойств данных. Для этих целей пригодны алгоритмы, аналогичные тем, которые применяются в среде разнородных
распределенных баз данных, построенных по методу «снизу вверх».
На основе хранилища данных, наполненного исходными данными,
может функционировать множество разнообразных приложений для
поддержки принятия решений и информационных систем руководителя. В таких приложениях применимы процедуры последовательного
уточнения, т. е. пошаговая архитектура, где в качестве источников для
хранилища данных выступает несколько баз данных (рис. 4.2).
Возможности хранилищ данных полезны в областях, связанных с
управлением долговременно хранимой информацией (цифровые библиотеки и хранилища данных), построенных на основе информационных супермагистралей будущего.
Информация, которая загружается в хранилище, должна интегрироваться в целостную структуру, отвечающую целям анализа данных. При этом минимизируются несоответствия между данными из
различных оперативных систем, в хранилище именуются и выражаются единым образом.
Данные интегрированы на множестве уровней: на уровне ключа,
атрибута, на описательном, структурном уровне и т. д. Общие данные и общая обработка данных консолидированы и являются единообразным для всех данных, которые подобны или схожи в хранилище
данных. При этом информация структурируется по разным уровням
детализации:
– высокая степень суммаризации;
– низкая степень суммаризации;
– текущая детальная информация.
44
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приложение 1
Информационная
система руководителя
Приложение 2
Информационные
запросы
Операции чтения/записи над
базой данных
Операционная база данных
Периодическое пополнение содержимого хранилища данных
Периодическое пополнение содержимого хранилища
данных
Периодическое пополнение содержимого хранилища данных
Операционная база данных
Хранилище
данных
Операционная база данных
Операции чтения/записи над
базой данных
Операции чтения/записи над
базой данных
Приложение 3
Приложение 4
Рис. 4.2. Множество баз данных как источник для хранилища данных
Хранилища можно рассматривать как набор моментальных снимков состояния данных: можно восстановить картинку на любой момент времени. Атрибут времени всегда явно присутствует в структурах данных хранилища.
Попав однажды в хранилище, данные уже никогда не изменяются, а только пополняются новыми данными из оперативных систем,
где данные постоянно меняются. Новые данные по мере поступления
обобщаются с уже накопленной информацией в хранилище данных.
Использование технологии хранилищ данных предполагает наличие в системе следующих компонентов:
45
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
– оперативных источников данных;
– средств переноса и трансформации данных;
– метаданных – включают каталог хранилища и правила преобразования данных при их загрузке из оперативных баз данных;
– реляционного хранилища;
– OLAP хранилища;
– средств доступа и анализа данных.
Назначение перечисленных компонентов таково. Оперативные
данные собираются из различных источников. Поступившие оперативные данные очищаются, интегрируются и складываются в реляционное хранилище. Они уже доступны для анализа при помощи
средств построения отчетов. Затем данные (полностью или частично) подготавливаются с использованием средств переноса и трансформации данных для OLAP-анализа, который реализуется применением средств доступа и анализа данных. При этом они могут быть
загружены в специальную базу данных OLAP или оставаться в реляционном хранилище.
Важнейшим элементом хранилища являются метаданные, т. е.
данные о структуре, размещении, трансформации данных, которые
используются любыми процессами хранилища. Метаданные могут
быть востребованы для различных целей, например: извлечения и загрузки данных; обслуживании хранилища и запросов. Метаданные
для различных процессов могут иметь различную структуру, т. е. для
одного и того же элемента данных может существовать несколько вариантов метаданных.
Итак, хранилища данных являются структурированными. Они
содержат базовые данные, которые образуют единый источник для
обработки данных во всех системах поддержки принятия решений.
Элементарные данные, присутствующие в хранилище, могут быть
представлены в различной форме. Хранилища данных исключительно велики, поскольку в них содержатся интегрированные и детализированные данные.
Эти характеристики являются общими для всех хранилищ данных. Несмотря на то, что хранилища обладают общими свойствами,
разные типы хранилищ имеют свои индивидуальные особенности.
Хранилище данных – это предметно-ориентированная, интегрированная, содержащая исторические данные, неразрушаемая сово46
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
купность данных, предназначенная для поддержки принятия управленченских решений. Одним из первых это определение дал Уильям
Инмон в своей монографии.
Схему хранилища данных можно представить следующим образом:
Оперативная
информация
Оперативная
информация
Оперативная
информация
Оперативная
информация
Оперативная
информация
Оперативная
информация
Рис. 4.3. Схема хранилища данных
Данные из различных источников помещаются в хранилище, а их
описания – в репозиторий метаданных. Конечный пользователь с помощью различных инструментов может анализировать данные в хранилище. Результатом является информация в виде готовых отчетов,
найденных скрытых закономерностей, каких-либо прогнозов. Так
как средства работы конечного пользователя с хранилищем данных
могут быть самыми разнообразными, то теоретически их выбор не
должен влиять на структуру хранилища и функции его поддержания
в актуальном состоянии. Физическая реализация данной схемы может быть самой разнообразной.
Рассмотрим первый вариант – виртуальное хранилище данных –
это система, предоставляющая доступ к обычной регистрирующей
системе, которая эмулирует работу с хранилищем данных. Виртуальное хранилище можно организовать двумя способами. Можно
создать ряд представлений (view) в базе данных или использовать
специальные средства доступа к базе данных (например, продукты
класса desktop OLAP).
Регистрирующая
система
Виртуальное хранилище
Рис. 4.4. Виртуальное хранилище
47
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Теперь рассмотрим основные преимущества и недостатки виртуальных хранилищ. Преимущества: простота и малая стоимость реализации, единая платформа с источником информации, отсутствие
сетевых соединений между источником информации и хранилищем
данных. Недостатков больше: работаем всего лишь с иллюзией хранилища данных, остаются проблемы с производительностью, трансформацией данных, интеграцией данных с другими источниками, отсутствием истории, чистотой данных, зависимость от доступности и
структуры основной базы данных.
Поскольку конструирование хранилища данных – сложный процесс, который может занять несколько лет, поэтому некоторые организации вместо этого строят витрины данных (data mart), содержащие
информацию для конкретных подразделений. Например, маркетинговая витрина данных может содержать только информацию о клиентах, продуктах и продажах и не включать в себя планы поставок.
Несколько витрин данных для подразделений могут сосуществовать
с основным хранилищем данных, давая частичное представление о
содержании хранилища. Витрины данных строятся значительно быстрее, чем хранилище, но впоследствии могут возникнуть серьезные
проблемы с интеграцией, если первоначальное планирование проводилось без учета полной бизнес-модели. Это второй способ.
Двухуровневая архитектура хранилища данных подразумевает построение витрин данных (data mart) без создания центрального хранилища, при этом информация поступает из регистрирующих систем
и ограничена конкретной предметной областью. При построении витрин используются основные принципы построения хранилищ данных, поэтому их можно считать хранилищами данных в миниатюре.
Нетрудно провести аналогию между предметными областями хранилища данных и классами объектов в объектно-ориентированных
базах данных. Действительно, методы проектирования и моделирования, применяемые в объектно-ориентированных базах данных, могут оказаться полезными и при формировании предметных областей
хранилищ данных.
Итак, хранилища данных являются структурированными. Они
содержат базовые данные, которые образуют единый источник для
обработки данных во всех системах поддержки принятия решений.
Элементарные данные, присутствующие в хранилище, могут быть
48
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
представлены в различной форме. Хранилища данных исключительно велики, поскольку в них содержатся интегрированные и детализированные данные.
Регистрирующие системы
Витрины данных
Рис. 4.5. Двухуровневая структура хранилища
Плюсы: простота и малая стоимость реализации; высокая производительность за счет физического разделения регистрирующих и
аналитических систем, выделения загрузки и трансформации данных в отдельный процесс, оптимизированной под анализ структурой
хранения данных; поддержка истории; возможность добавления метаданных.
Построение полноценного корпоративного хранилища данных
обычно выполняется в трехуровневой архитектуре. На первом уровне расположены разнообразные источники данных – внутренние регистрирующие системы, справочные системы, внешние источники
(данные информационных агентств, макроэкономические показатели). Второй уровень содержит центральное хранилище, куда стекается информация от всех источников с первого уровня, возможно, оперативный склад данных, который не содержит исторических данных
и выполняет две основные функции.
Во-первых, он является источником аналитической информации
для оперативного управления и, во-вторых, здесь подготавливаются
данные для последующей загрузки в центральное хранилище. Под
подготовкой данных понимают их преобразование и проведение
определенных проверок. Наличие оперативного склада данных просто необходимо при различном регламенте поступления информации
из источников. Третий уровень представляет собой набор предметноориентированных витрин данных, источником информации для которых является центральное хранилище данных. Именно с витринами
данных и работает большинство конечных пользователей [5].
49
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 4.6. Корпоративное хранилище
4.2. Множественность носителей информации
Среди носителей информации выделяется группа современных
носителей документированной информации, которые используются
в настоящее время, приходя на смену старым носителям всё большей популярностью. Например, кажется не так давно очень распространённый носитель информации – гибкий магнитный диск или
дискета практически не используется, на смену ему пришли оптические диски и носители на базе флэш-памяти, тоже явление происходит и в аудио- и видеотехнике на смену аудио- и видеокассет пришли
оптические диски.
Сейчас в мире присутствует множество различных типов магнитных носителей: дискеты для компьютеров, аудио- и видеокассеты,
бабинные ленты, жёсткие диски внутри компьютеров, карты памяти,
съемные жесткие диски, и т. д. Но постепенно открываются новые законы физики и вместе с ними новые возможности записи информации.
Появление современных носителей связано и с тем, что за полвека
своего существования сменилось уже пять поколений компьютеров,
причём от поколения к поколению на порядок и более возрастали их
производительность и ёмкость запоминающих устройств. А также появлялись новые, более совершенные периферийные устройства – при50
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
нтеры, сканеры, копиры, а в настоящее время всё чаще используются
многофункциональные устройства (МФУ), которые облегчают работу
офисных служащих, позволяют получать твёрдую копию документа
не только из памяти компьютера, но и с современного носителя.
Документ представляет собой двуединство информации и материального носителя. Поэтому важными признаками, которые могут
быть положены в основу классификации, являются особенности
строения, формы материала, на котором фиксируется информация.
В частности по этому критерию всё многообразие документов, содержащихся на современных материальных носителях, можно представить в виде класса документов на искусственной материальной
основе (на полимерных материалах).В свою очередь, документы на
искусственной материальной основе можно отнести к многослойным, в которых имеется как минимум два слоя – специальный рабочий слой и подложка (магнитные носители, оптические диски и др.).
При этом основа подложки может быть разной – бумажной, металлической, стеклянной, керамической, деревянной, тканью, плёночной
или пластиночной, пластмассовой. На основу наносится от одного до
нескольких (иногда до 6‑8) слоёв. В результате материальный носитель предстаёт иногда в виде сложной полимерной системы.
Существуют также энергетические носители.
По форме материального носителя информации документы могут
быть:
−карточными (пластиковые карты);
−дисковыми (диск, компакт-диск, CD-ROM, видеодиск).
В зависимости от возможности транспортировки материальных
носителей документы можно разделить на:
−стационарные (жёсткий магнитный диск в компьютере);
−портативные (оптические диски, носители на базе флэш-памяти).
В зависимости от способа документирования документы на современных носителях информации можно разделить на:
−магнитные (магнитные жёсткие диски, магнитные карты);
−оптические (лазерные) – документы, содержащие информацию,
записанную с помощью лазерно-оптической головки (оптические,
лазерные диски);
−голографические – документы, созданные с использованием лазерного луча и фоторегистрирующего слоя материального носителя
(голограммы);
51
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
−документы на машинных носителях – электронные документы,
созданные с использованием носителей и способов записи, обеспечивающих обработку его информации электронно-вычислительной
машиной [10].
Документы на современных материальных носителях информации, как правило, не поддаются непосредственному восприятию,
считыванию. Информация хранится на машинных носителях, а часть
документов создаётся и используется непосредственно в машиночитаемой форме.
Документы на современных носителях информации относятся к
классу технически-кодированных, содержащих запись, доступную
для воспроизведения только с помощью технических средств, в том
числе звуковоспроизводящей, видеовоспроизводящей аппаратуры
или компьютера.
По характеру связи документов с технологическими процессами в
автоматизированных системах различают:
−машинно-ориентированный документ, предназначенный для
записи, считывания части содержащейся в нём информации средствами вычислительной техники (заполненные специальные формы
бланков, анкет и т. п.);
−машиночитаемый документ, пригодный для автоматического
считывания содержащейся в нем информации с помощью сканера
(текстовые, графические);
−документ на машиночитаемом носителе, созданный средствами
вычислительной техники, записанный на машиночитаемый носитель
(жёсткий магнитный диск, оптический диск, носитель на базе флэшпамяти – и оформленный в установленном порядке);
−документ-машинограмма (распечатка), созданный на бумажном
носителе с помощью средств вычислительной техники и оформленный в установленном порядке;
−документ на экране дисплея, созданный средствами вычислительной техники, отражённый на экране дисплея (монитора) и оформленный в установленном порядке;
−электронный документ, содержащий совокупность информации
в памяти вычислительной машины, предназначенный для восприятия человеком с помощью соответствующих программных и аппаратных средств.
52
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Магнитные носители
Жёсткие магнитные диски, называемые винчестерами, предназначены для постоянного хранения информации, используются при работе с персональным компьютером и устанавливаются внутри него.
Винчестеры значительно превосходят гибкие диски. Они имеют
лучшие характеристики ёмкости, надёжности и скорости доступа к
информации. Поэтому их применение обеспечивает скоростные характеристики диалога пользователя и реализуемых программ, расширяет системные возможности по использованию баз данных, организации многозадачного режима работы, обеспечивает эффективную поддержку механизма виртуальной памяти. Однако стоимость
винчестеров намного выше стоимости гибких дисков.
Винчестер смонтирован на оси-шпинделе, приводимой в движение специальным двигателем. Он содержит от одного до десяти дисков (platters). Скорость вращения двигателя для обычных моделей
может составлять 3600, 4500, 5400, 7200, 10000 или даже 12000 об/
мин. Сами диски представляют собой обработанные с высокой точностью керамические или алюминиевые пластины, на которые нанесен магнитный слой.
Важнейшей частью винчестера являются головки чтения и записи
(read-write head). Как правило, они находятся на специальном позиционере (head actuator). Для перемещения позиционера используются преимущественно линейные двигатели (типа voice coil – звуковая
катушка). В винчестерах применяются несколько типов головок:
монолитные, композитные, тонкопленочные, магниторезистивные
(MR, Magneto-Resistive), а также головки с усиленным магниторезистивным эффектом (GMR, Giant Magneto-Resistive). Внутри любого
винчестера обязательно находится электронная плата, которая расшифровывает команды контроллера жесткого диска, стабилизирует
скорость вращения двигателя, генерирует сигналы для головок записи и усиливает их от головок чтения.
Различают два вида жёстких магнитных дисков.
Жёсткий диск (hard disk) – встроенный накопитель (дисковод) на
жёстком магнитном диске, пакет закреплённых один над другим магнитных дисков, извлечение которых в процессе эксплуатации электронных вычислительных машинах является невозможным.
Съёмный жёсткий диск (removable hard disk) – пакет магнитных
53
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
дисков, заключённых в защитную оболочку, которые в процессе эксплуатации в электронных вычислительных машинах могут выниматься из дисковода на сменном жёстком диске и заменяться другим.
Использование этих дисков обеспечивает практически неограниченный объём внешней памяти ЭВМ [6].
В ходе выполнения процедуры так называемого низкоуровневого
форматирования (low-level formatting) на жесткий диск записывается
информация, которая определяет разметку винчестера на цилиндры и
секторы. Структура формата включает в себя различную служебную
информацию: байты синхронизации, идентификационные заголовки,
байты контроля четности. В современных винчестерах такая информация записывается однократно при изготовлении винчестера. Повреждение этой информации при самостоятельном низкоуровневом
форматировании чревато полной неработоспособностью диска и необходимостью восстановления этой информации в заводских условиях.
Одной из основных характеристик жесткого диска является среднее время, в течение которого винчестер находит нужную информацию. Это время обычно представляет собой сумму времени, необходимого для позиционирования головок на нужную дорожку и ожидания
требуемого сектора. Современные винчестеры обеспечивают доступ к
информации за 8‑10 мс. Другой характеристикой винчестера является
скорость чтения и записи, но она зависит не только от самого диска, но
и его контроллера, шины, быстродействия процессора. У стандартных
современных жестких дисков эта скорость составляет 15‑17 Мбайт/с.
Пластиковые карты
Пластиковые карты представляют собой устройство для магнитного способа хранения информации и управления данными.
Пластиковые карты состоят из трёх слоёв полиэфирной основы,
на которую наносится тонкий рабочий слой, и защитного слоя. В
качестве основы обычно используется поливинилхлорид, который
легко обрабатывается, устойчив к температурным, химическим и механическим воздействиям. Однако в целом ряде случаев основой для
магнитных карт служит псевдопластик – плотная бумага или картон
с двусторонним ламинированием.
Рабочий слой (ферромагнитный порошок) наносится на пластик
методом горячего тиснения в виде отдельных узких полосок. Маг54
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
нитные полоски по своим физическим свойствам и сфере применения делятся на два типа – высокоэрцетивные и низкоэрцетивные [15].
Высокоэрцетивные полоски имеют чёрный цвет. Они устойчивы к
воздействию магнитных полей. Для их записи нужна более высокая
энергия. Используются в качестве кредитных карт, водительских
удостоверений, т. е. в тех случаях, когда требуется повышенная износостойкость и защищённость. Низкоэрцетивные магнитные полосы
имеют коричневый цвет. Они менее защищены, но зато проще и быстрее записываются. Используются на картах ограниченного срока
действия, в частности для проезда в метрополитене.
Следует заметить, что, кроме магнитного, существуют и другие
способы записи информации на пластиковую карту: графическая
запись, эмбоссирование (механическое выдавливание), штрих-кодирование, лазерная запись. В частности в последнее время в пластиковых картах вместо магнитных полосок всё более широко стали
применяться электронные чипы. Такие карты, в отличие от простых
магнитных, стали называть интеллектуальными или смарт-картами
(от англ. smart – умный). Встроенный в них микропроцессор позволяет хранить значительный объём информации, даёт возможность
производить необходимые расчёты в системе банковских и торговых
платежей, превращая, пластиковые карты в многофункциональные
носители информации.
По способу доступа к микропроцессору смарт-карты могут быть:
− с контактным интерфейсом (при совершении операции карта
вставляется в электронный терминал);
− с дуальным интерфейсом (могут действовать как контактно,
так и бесконтактно, т. е. обмен данными между картой и внешними
устройствами может осуществляться через радиоканал).
Защитный слой магнитных пластиковых карт состоит из прозрачной полиэфирной плёнки. Он призван предохранять рабочий слой
от износа. Иногда используются покрытия, предохраняющие от подделки и копирования. Защитный слой обеспечивает до двух десятков
тысяч циклов записи и чтения.
Размеры пластиковых карт стандартизированы. В соответствии
с международным стандартом ISO-7810 их длина равна 85,595 мм,
ширина 53,975 мм, толщина 3,18 мм. Сфера применения пластиковых и псевдопластиковых магнитных карт достаточно обширна. По55
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мимо банковских систем, они используются в качестве компактного
носителя информации, идентификатора автоматизированных систем
учёта и контроля, удостоверения, пропуска, телефонной и интернеткарты, билета для проезда в транспорте и т. д.
Оптические носители
Непрерывный научно-технический поиск материальных носителей документированной информации с высокой долговечностью,
большой информационной ёмкостью при минимальных физических
размерах носителя обусловил появление оптических дисков, получивших в последнее время широкое распространение. Они представляют собой пластиковые или алюминиевые диски, предназначенные
для записи или воспроизведения звука, изображения, буквенно-цифровой и другой информации при помощи лазерного луча.
Стандартные компакт-диски выпускаются диаметром 120 мм
(4,75 дюйма), толщиной 1,2 мм (0,05 дюйма), с диаметром центрального отверстия 15 мм (0,6 дюйма). Они имеют жёсткую, очень прочную, прозрачную, обычно пластиковую (поликарбонатную) основу
толщиной 1 мм.
Информация на CD фиксируется на рабочем слое в виде спиральной дорожки с помощью лазерного луча, выполняющего роль преобразователя сигналов. Дорожка идёт от центра диска к его периферии.
При вращении диска лазерный луч следует вдоль дорожки, ширина которой близка к 1 мкм, а расстояние между двумя соседними дорожками – до 1,6 мкм. Формируемые на диске лазерным лучом метки (питы)
имеют глубину около пяти миллиардных долей дюйма, а площадь
1‑3 мкм2, внутренний диаметр записи составляет 50 мм, наружный 116 мм. Общая длина всей спиральной дорожки на диске составляет
около 5 км. На каждый мм радиуса диска приходится 625 дорожек. Всего
на диске располагается 20 тысяч витков спиральной дорожки.
Для хорошего отражения лазерного луча используется так называемое зеркальное покрытие дисков алюминием (в обычных дисках)
или серебром (в записываемых и перезаписываемых). На металлическое покрытие наносится тонкий защитный слой из поликарбоната
или специального лака, обладающий высокой механической прочностью, поверх которого размещаются рисунки и надписи. Нужно
иметь в виду, что именно эта окрашенная сторона диска является бо56
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
лее уязвимой, нежели противоположная, с которой осуществляется
считывание информации через всю толщину диска.
Технология изготовления оптических дисков является достаточно сложной. Вначале создаётся стеклянная матрица – основа диска.
С этой целью пластик (поликарбонат) разогревается до 350 градусов,
затем следует его впрыскивание в форму, мгновенное охлаждение и
автоматическая подача на следующую технологическую операцию.
На стеклянный диск-оригинал наносится фоторегистрирующий
слой. В этом слое лазерной системой записи формируется система
Питов, т. е. создаётся первичный мастер-диск. Затем по мастер-диску
путём литья под давлением осуществляется массовое тиражирование, создание дисков-копий.
Информационная ёмкость дисков обычно составляет менее
650 Мбайт. На одном диске можно записать несколько сот тысяч
страниц машинописного текста. Между тем уже разработаны оптические диски и с гораздо большей ёмкостью – свыше 1 Гбайт.
Поскольку запись и воспроизведение информации на оптических
дисках являются бесконтактными, постольку практически исключается возможность механического повреждения таких дисков.
На оптический диск информация записывается и считывается с
помощью сфокусированного лазерного луча.
В зависимости от возможности использования для записи и считывания оптические диски делят на два вида:
1.WORM (Write Once Read Many) – накопители, предназначенные для записи информации и её хранения.
2.CD-ROM (Compact Disk Read Only Memory) – накопители,
предназначенные для чтения информации.
Оптические диски можно разделить на типы:
− аудио-компакт-диск – это диск с постоянной (нестираемой) звуковой информацией, записанной в двоичном коде;
− CD-ROM – диск с постоянной памятью, предназначенный для
хранения и чтения значительных объёмов информации. Он содержит
компьютерную информацию, которая считывается дисководом, подключённым к ПЭВМ;
− видео-компакт-диск – диск, на котором в цифровой форме записывается текстовая, изобразительная и звуковая информация, а также
программы ЭВМ;
57
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
− DVD-диск – разновидность нового поколения оптических дисков, на котором в цифровой форме записывается текстовая, видео и
звуковая информация, а также компьютерные данные;
− магнитооптический диск – диск, состоящий из разных комбинаций гибкого магнитного диска, винчестера и оптического диска.
Носители на базе флэш-памяти
Один из самых современных и перспективных носителей документированной информации – твёрдотельная флэш-память, представляющая собой микросхему на кремниевом кристалле. Этот особый вид энергонезависимой перезаписываемой полупроводниковой
памяти. Название связано с огромной скоростью стирания микросхемы флэш-памяти.
Для хранения информации флэш-носители не требуют дополнительной энергии, которая необходима только для записи. Причём по
сравнению с жёсткими дисками и носителями CD-ROM для записи
информации на флэш-носителях требуется в десятки раз меньше
энергии, поскольку не нужно приводить в действие механические
устройства, потребляющие большую часть энергии. Сохранение
электрического заряда в ячейках флэш-памяти при отсутствии электрического питания обеспечивается с помощью так называемого
плавающего затвора транзистора.
Носители на базе флэш-памяти могут хранить записанную информацию очень длительное время (от 20 до 100 лет). Будучи упакованы
в прочный жёсткий пластиковый корпус, микросхемы флэш-памяти
способны выдерживать значительные механические нагрузки (в 5‑10
раз превышающие предельно допустимые для обычных жёстких дисков). Надёжность такого рода носителей обусловлена и тем, что они
не содержат механически движущихся частей. В отличие от магнитных, оптических и магнитооптических носителей, здесь не требуется
применение дисководов с использованием сложной прецизионной
механики. Их отличает также бесшумная работа. Кроме того, эти носители очень компактны.
Информацию на флэш-носителях можно изменять, т. е. перезаписывать. Помимо носителей с единственным циклом записи, существует флэш-память с количеством допустимых циклов записи/
стирания до 10000, а также от 10000 до 100000 циклов. Все эти типы
принципиально не отличаются друг от друга.
58
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Несмотря на миниатюрные размеры, флэш-карты обладают большой ёмкостью памяти, составляющей многие сотни Мбайт. Они универсальны по своему применению, позволяя записывать и хранить
любую цифровую информацию, в том числе музыкальную, видео- и
фотографическую.
Флэш-память вошла в разряд основных носителей информации,
широко используемых в разных цифровых мультимедийных устройствах: в портативных компьютерах, принтерах, цифровых диктофонах,
сотовых телефонах, электронных часах, записных книжках, телевизорах, кондиционерах, МРЗ-плеерах, цифровых фото- и видеокамерах.
Флэш-карты являются одним из наиболее перспективных видов
материальных носителей документированной информации. Уже
разработаны карты нового поколения – Secure Digital, обладающие
криптографическими возможностями защиты информации и высокопрочным корпусом, существенно снижающим риск повреждения
носителя статистическим электричеством.
Выпущены карты ёмкостью 4 Гбайт. На них можно поместить
около 4000 снимков высокого разрешения или 1000 песен в формате
МРЗ, или же полный DVD-фильм. Тем временем набирает свои обороты использования флэш-карта ёмкостью 8 Гбайт.
Налажено производство так называемых неподвижных флэш-дисков ёмкостью в сотни Мбайт, тоже представляющих собой устройство для хранения и транспортировки информации.
Таким образом, совершенствование технологии флэш-памяти
идёт в направлении увеличения ёмкости, надёжности, компактности,
многофункциональности носителей, а также снижения их стоимости.
4.3. Агрегирование данных
Агрегирование данных – предобработка для представления в хранилище данных более высокого уровня гранулярности.
Операционные данные извлекаются по принципу мгновенных
снимков из одной или более баз данных или других источников информации, и на основе их интеграции строится хранилище данных.
Однако хранилище данных не поддерживает того же высокого уровня гранулярности информации, который характерен для операционных баз данных.
59
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рассмотрим разницу между операционными приложениями, с
одной стороны, и приложениями поддержки принятия решений или
управления информацией для руководителя, с другой. Операционным приложениям для выполнения своих функций нужен максимально высокий уровень гранулярности. В базе данных должна быть
представлена информация о каждом клиенте, как и о каждом сотруднике, поставщике, компакт-диске, каждой видеокассете и т. п.
Пользователей DSS или EIS, напротив, вряд ли будет интересовать список всех клиентов или детальный отчет для каждого из них о
каждом взятом на прокат или приобретенном компакт-диске. Менеджеру-аналитику высокого ранга не понадобится месячный или даже
годовой отчет с подобной информацией. Будет необходим отчет о
среднемесячном объеме проката и продаж в расчете на одного клиента с разбивкой по почтовым индексам в пределах конкретного округа
или региона, охваченного деятельностью компании. Подобным же
образом будет полезным также сравнение такого рода агрегированной информации со сведениями за прошлый месяц либо за тот же
месяц одного или двух прошлых лет.
Ключ к эффективности приложений хранилища данных – это агрегирование данных. Возможно, приложения DSS или EIS могли бы самостоятельно оперировать данными с высоким уровнем гранулярности
независимо от того, хранятся ли они в операционной базе данных или с
тем же уровнем гранулярности в хранилище данных. Но такой подход
абсолютно непрактичен, по крайней мере, по одной из двух причин:
1) дополнительная нагрузка на операционную базу данных, создаваемая в результате выполнения многочисленных операций выборки и агрегирования данных, которая приведет к снижению производительности на текущих операциях;
2) неоправданное увеличение объема необходимой памяти в хранилище данных для хранения данных, которые никогда не будут использовать индивидуально.
В хранилище данных можно поддерживать несколько уровней
гранулярности, например данные, агрегированные в малой и высокой степени, что очень желательно для проведения анализа с последовательной детализацией. Анализ такого рода полезен в тех случаях, когда пользователь обнаруживает интересное для него явление и
стремится более глубоко исследовать его существо и причины.
60
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Приложение EIS
Сводные исторические данные по покупкам:
в месячном размере, по региону
Сводные исторические
данные по покупкам:
в недельном размере, по
региону
Сводные исторические
данные по покупкам:
в дневном размере, по
магазину
Сводные исторические
данные по покупкам:
в дневном размере, по
магазину
Сводные исторические
данные по покупкам:
в недельном размере, по
региону
Сводные исторические
данные по покупкам:
в дневном размере, по
магазину
Рис. 4.7. Структуры, ориентированные на поддержку типичного
анализа с последовательной детализацией
На рис. 4.7 показаны структуры, ориентированные на поддержку
типичного анализа с последовательной детализацией. Если в хранилище данных поддерживаются соответствующие связи от каждого
уровня агрегирования к «питающим» его уровням, то программные
средства приложения могут производить обход таких связей.
4.4. Распределенные хранилища данных
Распределенная база данных – это набор логически связанных
между собой разделяемых данных (и их описаний), которые физически
распределены в некоторой компьютерной сети. Тогда распределенная
СУБД – это программный комплекс, предназначенный для управления
распределенными базами данных и позволяющий сделать распределенность информации прозрачной для конечного пользователя.
Система управления распределенными базами данных (СУРБД)
состоит из единой логической базы данных, разделенной на некоторое количество фрагментов. Каждый фрагмент базы данных сохра61
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
няется на одном или нескольких компьютерах, которые соединены
между собой линиями связи, и каждый из которых работает под
управлением отдельной СУБД. Любой из сайтов способен независимо обрабатывать запросы пользователей, требующие доступа к
локально сохраняемым данным (что создает определенную степень
локальной автономии), а также способен обрабатывать данные, сохраняемые на других компьютерах сети.
Пользователи взаимодействуют с распределенной базой данных через приложения. Приложения могут быть классифицированы следующим образом: приложения, которые не требуют доступа к данным на
других сайтах (локальные приложения), и приложения, которые требуют подобного доступа (глобальные приложения). В распределенной
СУБД должно существовать хотя бы одно глобальное приложение, поэтому любая СУРБД должна отвечать следующим требованиям:
−иметь набор логически связанных разделяемых данных;
−сохраняемые данные разбиты на некоторое количество фрагментов;
−между фрагментами может быть организована репликация
данных;
−фрагменты и их реплики распределены по различным сайтам;
−сайты связаны между собой сетевыми соединениями;
−работа с данными на каждом сайте управляется СУБД;
−СУБД на каждом сайте способна поддерживать автономную работу локальных приложений;
−СУБД каждого сайта поддерживает хотя бы одно глобальное
приложение.
Преимущества и недостатки РСУБД
Системы с распределенными базами данных имеют преимущества перед традиционными централизованными системами баз данных:
1. Отражение структуры организации. Крупные организации, как
правило, имеют множество отделений, которые могут находиться в
разных концах страны и даже за ее пределами. Вполне логично будет
предположить, что используемая компанией база данных должна быть
распределена между ее отдельными офисами. В подобной базе данных
персонал отделения сможет выполнять необходимые ему локальные
запросы. Руководству компании может потребоваться выполнять гло62
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
бальные запросы, предусматривающие получение доступа к данным,
сохраняемым во всех существующих отделениях компании.
2. Разделимость и локальная автономность. Географическая распределенность организации может быть отражена в распределении ее
данных, причем пользователи одного сайта смогут получать доступ к
данным, сохраняемым на других сайтах. Данные могут быть помещены на тот сайт, на котором зарегистрированы пользователи, которые их
чаще всего используют. В результате заинтересованные пользователи
получают локальный контроль над требуемыми ими данными и могут
устанавливать или регулировать локальные ограничения на их использование. Администратор глобальной базы данных (АБД) отвечает за
систему в целом. Как правило, часть этой ответственности делегируется на локальный уровень, благодаря чему АБД локального уровня
получает возможность управлять локальной СУБД.
3. Повышение доступности данных. В централизованных СУБД
отказ центрального компьютера вызывает прекращение функционирования всей СУБД. Однако отказ одного из сайтов СУРБД или линии
связи между сайтами сделает недоступными лишь некоторые сайты,
тогда как вся система в целом сохранит свою работоспособность. Распределенные СУБД проектируются таким образом, чтобы обеспечивать продолжение функционирования системы, несмотря на подобные
отказы. Если выходит из строя один из узлов, система сможет перенаправить запросы к отказавшему узлу в адрес другого сайта.
4. Если организована репликация данных, в результате чего данные и их копии будут размещены более чем на одном сайте, отказ отдельного узла или соединительной связи между узлами не приведет
к недоступности данных в системе.
5. Повышение производительности. Если данные размещены на
самом нагруженном сайте, который унаследовал от систем-предшественников высокий уровень параллельности обработки, то развертывание распределенной СУБД может способствовать повышению
скорости доступа к базе данных (по сравнению с доступом к удаленной централизованной СУБД). Более того, поскольку каждый сайт
работает только с частью базы данных, уровень использования центрального процессора и служб ввода/вывода может оказаться ниже,
чем в случае централизованной СУБД.
Большой интерес к хранилищам данных появился в 1991 г., когда
IBM объявила свою архитектуру хранилища информации (Informa63
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
tion Warehouse Architecture), которая по замыслу должна была стать
оболочкой для множества распределенных неоднородных баз данных.
Хранилище информации должно предоставлять инструментарий и
средства для доставки полной, точной, своевременной и понятной
деловой информации лицам, обладающим необходимыми полномочиями, а также для управления этой информацией с целью эффективной поддержки принятия решений.
В соответствии с представлениями IBM хранилище информации –
это среда, в которой для удовлетворения все усложняющихся требований распределенных приложений применяются разнообразные
виды программного обеспечения промежуточного слоя, в том числе
DRDA. Если хранилища информации предназначены для управления
распределенными данными крупных компаний, то последние, несомненно, должны использовать хранилища данных для обеспечения
распределенности.
Рассмотрим архитектуры хранилищ данных, изображенные на
рис. 4.8. Централизованное хранилище данных может применяться для таких сред, где средоточием данных компании по-прежнему является мэйнфрейм. В то же время нецелесообразно было
бы сохранять централизованную архитектуру информационных
приложений в ситуациях, когда операционные приложения (и соответствующие данные) базируются на распределенных вычислительных системах.
Приложения, использующие распределенное хранилище данных,
не сталкиваются со многими проблемами распределенных баз данных, например, управление параллельным обновлением данных. Однако многие принципы СРБД применимы и к появляющимся распределенным хранилищам данных. На рис. 4.9 представлена архитектура хранилища данных с тиражированием.
В хранилище данных доступ к его содержимому и управление им
(как и в базе данных – распределенной или централизованной) требует соответствующих метаданных. Для централизованного хранилища данных структура метаданных относительно проста. Действительно, если хранилище данных реализовано на основе реляционной
СУБД, то ее метаданных обычно будет достаточно для поддержания
необходимых таблиц и других объектов хранилища данных. Эти метаданные могут быть синхронизированы с приложениями DSS/EIS,
64
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
использующими хранилище данных, и такая синхронизация в идеале
должна производиться средствами мощных высокоразвитых репозиториев будущего.
Централизованное хранилище данных
Операционная база
данных
Операционная база
данных
Операционная база
данных
Хранилище
данных
Хранилище
данных
Хранилище
данных
Рис. 4.8. Архитектура централизованного
и распределенного хранилища данных
65
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Нью-Йорк
Чикаго
Тиражировать
Тиражировать
Хранилище
данных
Хранилище
данных
Хранилище
данных
Токио
Чикаго
Тиражировать
Лос-Анжелес
Хайфа
Хранилище
данных
Берлин
Рис. 4.9. Распределенное хранилище данных с тиражированием
В распределенном хранилище данных управление метаданными может усложниться, хотя это и необязательно. Распределенное
хранилище данных, построенное на основе распределенной СУБД
(РСУБД), разумеется, будет использовать метаданные РСУБД для
компонентов хранилища данных. В других случаях, например в «доморощенных» распределенных хранилищах данных, ответственность за определение метаданных и управление ими возлагается на
проектировщиков и специалистов по реализации. Как и в средах централизованных хранилищ данных, это может также осуществляться
средствами репозиториев.
Организации, уже использующие хранилища данных или планирующие делать это в будущем, неизбежно столкнутся с необходимостью иметь в той или иной степени распределенные возможности,
как и для своих операционных баз данных. Поэтому архитекторы,
проектировщики и специалисты по реализации хранилищ данных
должны иметь представление о принципах построения распределенных хранилищ данных, а также о существующих коммерческих и
других разработках такого рода.
66
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4.5. Хранилища данных и другие технологии
управления информацией
Базы данных и приложения клиент-сервер
Переход к базам данных клиент-сервер – это относительно небольшой скачок в развитии среди хранилищ данных. На рис. 4.10 и
4.11 показаны две альтернативные архитектуры хранилищ данных,
основанные на современных моделях клиент-сервер.
Из рис. 4.10 видно, что приложения EIS, написанные на языке
Xbase, осуществляют доступ к централизованному хранилищу данных, основанному на языке SQL, посредством интерфейса прикладного программирования ODBC. В такой среде довольно легко реализовать простейшую модель клиент-сервер, где один сервер обслуживает несколько клиентов.
Xbase-приложение
EIS
Xbase-приложение
EIS
Xbase-приложение
EIS
ODBC
Хранилище данных,
основанное на SQL
Рис. 4.10. Хранилище данных с простой архитектурой клиент-сервер
На рис. 4.10 представлен более сложный вариант архитектуры
клиент-сервер. Доступ к логически централизованному хранилищу
данных, распределенному на множестве платформ, осуществляется
так же, как и в примере на рис. 4.10. Однако внутри хранилища данных для доступа к его распределенным компонентам (фрагментам)
применяется комбинация интерфейсов прикладного программирования IDAPI и DRDA. В таком случае приложение, выполняющееся
над хранилищем данных, выступает в двоякой роли: как сервер для
комплекса приложений EIS и как клиент, запрашивающий информацию хранилища данных у других серверов.
67
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Xbase-приложение
EIS
Xbase-приложение
EIS
Xbase-приложение
EIS
ODBC
Хранилище
данных
IDAPI
Хранилище
данных
IDAPI
DRDA
Хранилище
данных
Рис. 4.11. Распределенное хранилище данных
со сложной архитектурой клиент-сервер
Активные базы данных
В активных базах данных механизмы, подобные событиям, триггерам и др., используются для автоматического приоритетного выполнения действий, активизируемых такими факторами, как срабатывание таймера, определенные изменения значений в базе данных
или другие изменения состояний.
68
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Поскольку активные базы данных получили массовое распространение, они найдут, вероятно, применение в средах хранилищ данных.
Как показано на рис. 4.12 а, в базах данных, используемых в качестве
источников информации для хранилища, активные механизмы могут обеспечивать автоматическую передачу очередных «мгновенных
снимков» в хранилище данных. В такой модели загрузка данных в хранилище может быть реализована как предопределенное и хранимое
действие в самой системе базы данных – источнике, не требующее
инициативы со стороны какого-либо пользователя или приложения.
В другой модели, когда само хранилище данных реализовано на
основе активной базы данных, процедура загрузки данных в хранилище является действием, определенным в этой (активной) базе данных, которое в некоторые моменты времени инициирует запросы к
серверам операционных баз данных (рис. 4.12 б).
Может оказаться целесообразной комбинация двух типов сред,
изображенных на рис. 4.12 а, б (активные базы данных как на стороне источника, так и на стороне получателя данных). Кроме того,
выполнение хранимых процедур в самом хранилище данных может
быть инициировано и приложениями EIS/DSS (рис. 4.12 в).
Гипертекст
Одно из применений гипертекстовых средств в хранилищах данных – это поддержка анализа с последовательной детализацией в
приложениях EIS.
В частности гипертекстовый интерфейс мог бы быть составной
частью платформы, предназначенной для выполнения приложений
EIS.
Гипертекстовая среда позволяет пользователю следовать по одному пути (или более) от активного в данный момент экрана, продвигаться по одному из нескольких дальнейших альтернативных путей,
сохраняя каждый раз, однако, возможность возвращения в предыдущие точки. Представляется, что гипертекстовый способ обхода данных удобен для реализации анализа содержимого хранилища данных
с последовательной детализацией. В процессе проведения такого
анализа может потребоваться исследование другой порции информации на некотором ином уровне. Гипертекстовый интерфейс позволяет сделать это, обеспечивая вместе с тем путь возврата.
69
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Активная
база данных
Пополнение
хранилища данных,
основанное на
триггерах
Активная
база данных
Пополнение
хранилища данных,
основанное на
триггерах
Хранилище
данных
Пополнение
хранилища
данных,
основанное на
триггерах
Активная
база данных
IDAPI
Активная
база данных
а
Хранилище
данных
Триггер
Платформа
запрашивает
активной
пополнение из
базы данных
операционных
баз данных
IDAPI
б
Приложение
EIS
Хранилище данных
Вызов
Вызов
Хранимые процедуры
в
Платформа активной базы данных
Рис. 4.12. Запуск хранимых процедур приложениями EIS
70
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Временные базы данных
Временную базу данных можно коротко охарактеризовать как базу
данных, к основной структуре которой добавлено временное измерение.
Историческая информация, представленная в виде последовательности мгновенных снимков – важное свойство хранилища данных
(поскольку приложения, выполняющиеся над хранилищем данных,
постоянно осуществляют сравнительный анализ агрегированной информации за различные промежутки времени). Поэтому временная
база данных – это естественный фундамент для построения хранилища данных. Значения данных в хранилище данных должны обязательно ассоциироваться со временем (с моментами или интервалами времени). При этом желательно, чтобы структуры времени были
встроены непосредственно в модель данных. Это избавило бы от необходимости заниматься реализацией временных аспектов информации в приложениях и структурах данных.
4.6. Цифровые библиотеки
и информационные магистрали
Принципы организации хранилищ данных являются важными в
развитии таких перспективных направлений управления информацией, как цифровые библиотеки и доступ к ним посредством информационных магистралей. Концентрируя большие объемы информации
из множества источников в хранилищах данных, к которым организован доступ по общенациональной оптоволоконной сети, можно
было бы предоставлять огромные массивы информации пользователям непосредственно по месту их жительства или работы.
Цифровые библиотеки (Digital Libraries), называемые в нашей
стране также электронными библиотеками – одна из интенсивно
развивающихся новых технологий. Речь идет о создании крупных
распределенных мультимедийных и гипермедийных информационных систем, позволяющих эффективно использовать разнообразные
коллекции электронных документов, обладающих весьма развитыми
пользовательскими интерфейсами, реализующих элементы систем
баз знаний, обеспечивающих доступ пользователей через глобальные коммуникационные сети.
71
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Электронная библиотека (ЭБ) – это информационная система,
позволяющая надёжно сохранять и эффективно использовать разнообразные коллекции электронных документов (текстовых, изобразительных, звуковых, видео и др.), локализованных в самой
системе, а также доступных ей через телекоммуникационные сети.
Основные задачи ЭБ – интеграция информационных ресурсов и
эффективная навигация в них. Под интеграцией информационных
ресурсов понимается их объединение с целью использования (с помощью удобных и унифицированных пользовательских интерфейсов, желательно одного) различной информации с сохранением её
свойств, особенностей представления и пользовательских возможностей манипулирования с ней. При этом объединение ресурсов не
обязательно должно осуществляться физически, оно может быть
виртуальным, главное – оно должно обеспечивать пользователю
восприятие доступной информации как единого информационного
пространства. В частности предполагается, что ЭБ должны обеспечивать работу с гетерогенными БД, обеспечивая пользователю
эффективность информационных поисков независимо от особенностей конкретных информационных систем, к которым осуществляется доступ. Эффективная навигация в ЭБ понимается как возможность пользователя находить интересующую его информацию с наибольшей полнотой и точностью при наименьших затратах усилий
во всём доступном информационном пространстве. При таком подходе хорошо известные информационные поиски, используемые
в информационных системах и базах данных, являются частными
случаями навигационных средств.
Особенности представления информации определяются их назначением – обеспечением эффективного (быстрого и исчерпывающего,
прежде всего, по полноте) поиска нужных данных или, если таковые
не обнаружены, сведений о документах, предположительно их содержащих. Именно поэтому для достижения общности представления,
не зависящей от точек зрения и особенностей изложения, создаются
каталоги и базы данных вторичной информации, когда содержание
документа редуцируется до формы перечисления основных понятий,
в той или иной степени однозначно характеризующих его в контексте
той предметной области, для которой создаётся база данных.
72
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Контрольные вопросы
1. Что представляет собой агрегирование данных – предобработка
для представления в хранилище данных более высокого уровня гранулярности?
2. Какова архитектура централизованного и распределенного хранилища данных?
3. Каковы особенности активных баз данных?
4. Какова роль гипертекстовых средств в хранилищах данных?
5. В чем отличие временной базы данных?
6. Что представляет собой электронная библиотека?
7. Каковы основные задачи ЭБ?
8. Чем определяются особенности представления информации?
73
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5. ФРАГМЕНТАЦИЯ И ТИРАЖИРОВАНИЕ
Рассмотрены концепции МРР и параллельных систем баз данных,
дано описание моделей фрагментации при параллельных систем баз
данных, параллельное выполнение реляционных операторов и индексов структуры и перспективы развития параллельных систем баз
данных.
5.1. Концепции МРР и параллельных систем
баз данных
Согласно ранее приведенному определению, фрагментация означает разбиение объекта данных, например реляционной таблицы, на
подмножества строк или столбцов и распределение их между различными ресурсами вычислительной системы. Классические модели фрагментации в приложении к реляционным базам данных: горизонтальная – множество строк таблицы разбивается по значению
какого-либо столбца (например, таблица с данными о сотрудниках
разбивается по значению столбца JOBLOCATION – место службы,
которое определяет, на каком физическом узле должны храниться соответствующие строки), а также вертикальная – таблица разбивается
на подмножества столбцов.
Тиражирование – это создание дублирующих копий (репликатов)
объектов данных на разных узлах с целью повышения доступности
и/или сокращения времени доступа к критически важным данным
числительных систем с массовым параллелизмом (Massively Parallel
Processing, МРР). Если в организации ведутся эксперименты по применению систем МРР, то параллельные системы баз данных должны
представлять соответствующий интерес. Если в настоящее время в
организации эксплуатируется централизованная база данных, а ресурсы мэйнфрейма близки к исчерпанию, то понимание технологий
параллельных систем баз данных – важного перспективного направления для всех крупнейших поставщиков СУБД – является крайне
важным. Поэтому следует провести сравнение данного подхода с
более традиционными моделями распределения (в организации на
74
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
уровне подразделений могут успешно сосуществовать оба варианта,
выбираемые с учетом специфики конкретного набора приложений).
Классическая модель фрагментации, когда данные распределяются между узлами сети, может оказаться не самым эффективным
подходом, если учесть конкретные бизнес-правила, а также нормы
доступа к объектам и их обновления со стороны определенных пользователей и приложений. Но, как отмечалось там же, фрагментацию
вряд ли можно списывать со счетов как устаревший метод распределения данных.
На элементарном уровне идеи систем обработки данных с массовым параллелизмом исключительно просты: декомпозиция вычислительных задач на большое количество параллельно выполняемым
операциям. Архитектура МРР (рис. 5.1) масштабируется вплоть до
тысяч процессоров, поскольку в ней исключены узкие места, присущие симметричным многопроцессорным системам (Symmetrical
Multiple Processing, SMP), за счет более совершенных межпроцессорных коммуникаций и схем доступа к памяти.
Процессор
Процессор
Процессор
Память
Память
Память
Межпроцессорная сеть
Процессор
Процессор
Память
Память
Процессор
Память
Рис. 5.1. Архитектура MPP
75
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В средах управления информацией МРР являются строительными
блоками, из которых создаются системы баз данных с высоким уровнем параллелизма, представляющие привлекательные альтернативы
централизованным базам данных на мэйнфреймах.
Специализированная машина баз данных, которая в начале 80-х гг.
ХХ в. стала утрачивать позиции, на самом деле послужила стимулом
для огромного числа исследований в области параллельных систем
баз данных. Возрождение интереса к таким системам объясняется отчасти становлением и развитием реляционных СУБД как доминирующего инструмента управления информацией, поскольку реляционные
запросы являются идеальным объектом для распараллеливания.
Тиражирование получило распространение как альтернатива традиционной распределенной обработке, основанной на модели двухфазной фиксации (2-Phase Commit, 2PC).
Поставщики средств баз данных настойчиво продвигают как параллельные системы баз данных, так и серверы тиражирования, способствуя развитию обоих этих направлений.
Понимание достигнутого поставщиками СУБД уровня технологий в рассматриваемых областях, а также основных принципов различных моделей размещения и согласования данных может быть полезным в организации эффективного распределения данных в средах
уровня корпорации или подразделения. Не нужно быть специалистом
в области архитектур МРР, чтобы осознать: параллельные системы
баз данных представляют собой более плодотворную альтернативу
в управлении очень большими базами данных по сравнению с доминировавшими ранее централизованными решениями на основе мэйнфреймов. Модель двухфазной фиксации – технически оправданное
для некоторых сред решение – не поддается, однако, масштабированию в сильно распределенной среде, когда транзакции охватывают
множество систем на разных узлах. Понимание механизмов тиражирования и обсуждаемых принципов обработки сложных транзакций
может помочь тем, кто занимается планированием и принимает решения относительно распределенной среды, в выборе привлекательных и легко реализуемых альтернатив управления информацией [10].
Рассмотрим основное свойство реляционной модели, заключающееся в том, что каждый оператор порождает новое отношение.
Это означает, что множество операторов (возможно, очень большое)
76
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
может быть представлено в виде сильно распараллеленного графа потоков данных. Применяя
конвейерный параллелизм, мы можем направить
REPORT
результат выполнения оператора А на вход оператору В, где В выполняется вслед за А. Если, например, операторы SCAN (просмотр) и REPORT
(отчет) выполняются в режиме конвейерного паSCAN
раллелизма, то результаты SCAN будут поступать
на вход REPORT, но при этом оба оператора будут
выполняться параллельно (рис. 5.2).
Альтернативная модель параллелизма – параллелизм с фрагментацией – позволяет разбивать
один оператор на несколько независимых, каждый из которых работает с отдельным независимым набором данных, и все они выполняются паРис. 5.2.
раллельно. Как показано на рис. 5.3, каждый поКонвейерный
ток модели параллелизма с фрагментацией может
параллелизм
также использовать конвейерный параллелизм,
выдавая результат оператору рекомбинирования данных, например
оператору MERGE (слияние).
MERGE
MERGE
SORT
SORT
SORT
SORT
SORT
SORT
SCAN
SCAN
SCAN
SCAN
SCAN
Рис. 5.3. Параллелизм с фрагментацией (здесь SCAN –
просмотр, SORT – сортировка, MERGE – слияние)
77
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Здесь есть, однако, одно тонкое место. Для того чтобы реализовать
параллелизм с фрагментацией, должны быть фрагментированы исходные данные. Модели фрагментации для параллельных систем баз данных мы обсудим в п. 5.3. Сейчас отметим лишь, что фрагментация данных является необходимой предпосылкой для применения параллельных систем баз данных, основанных на параллелизме с фрагментацией.
В мире параллельных систем имеется множество аппаратных подходов для реализации параллелизма. В простой таксономии Майкла
Стоунбрекера параллельные системы подразделяются на следующие
категории:
− системы с разделяемой памятью (широко используемый в
отечественной литературе по информатике термин «разделяемый»
(эквивалент английского shared), обозначающий свойство ресурсов
различного рода, имеет в русском языке неоднозначное толкование.
В нашем случае следует понимать его как «совместно используемый»
ресурс – все процессоры могут иметь непосредственный доступ к общей глобальной памяти и ко всем дискам;
− системы с разделяемыми дисками – каждый процессор имеет
собственную память, но может непосредственно обращаться ко всем
системным дискам;
− системы без разделения ресурсов – ни диски, ни память не разделяются; процессоры (см. рис. 5.1) взаимодействуют друг с другом
только посредством межпроцессорных сетей.
Общепринятое в компьютерном сообществе мнение сводится к
тому, что для параллельных систем баз данных наиболее подходящей
является архитектура без разделения ресурсов. Большинство таких
систем, как исследовательских, так и коммерческих, реализовано на
архитектурах без разделения ресурсов, хотя типы сетей, применяемых для межпроцессорных соединений, значительно различаются.
Параллельные системы баз данных на архитектурах без разделения ресурсов – это хорошая идея, но истинное значение подобных
реализаций становится понятным лишь при рассмотрении перспективы перехода к большим, а точнее к очень большим базам данных.
В качестве примера заметим, что NASA (Национальное управление
по аэронавтике и исследованию космического пространства США) в
конце 80-х гг. оценила объем памяти, необходимой для хранения данных всего одного набора приложений по обработке изображений, получаемых с помощью спутников, в 1016 байтов. Не так давно обраба78
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
тываемые в оперативном режиме базы данных объемом в несколько
гигабайтов считались большими. В 90-х гг. ХХ в. во многих больших
организациях появились базы данных объемом в терабайты. Помимо
очевидной потребности в больших объемах памяти критичным относительно достижения приемлемой для таких баз данных производительности является также параллелизм.
5.2. Модели фрагментации для параллельных
систем баз данных
Как упоминалось в предыдущих темах, необходимой предпосылкой для достижения параллелизма с фрагментацией является фрагментация данных. На рис. 5.4 показана основная модель фрагментации, применяемая в параллельных системах баз данных.
На рис. 5.5, 5.6 и 5.7 соответственно приведены примеры для трех
конкретных схем фрагментации – фрагментации по диапазонам, карусельной фрагментации и фрагментации хешированием.
Каждая из этих схем имеет свои относительные достоинства и
недостатки. Фрагментация по диапазонам приводит к созданию кластеров кортежей, близких по какой-либо характеристике, что удобно
для последовательного доступа к отношению. Результаты выборки
из каждого кластера можно собрать вместе и слить, а если требуемое упорядочение результата совпадает с базой фрагментации (например, сортировка по возрастанию некоторого кода, обозначающего
место работы), то промежуточная сортировка в каждом потоке выполнения может вообще не потребоваться. В то же время в зависимости от распределения значений по диапазонам вы можете получить
неравномерное заполнение фрагментов, что приводит к «перекосам»
при выполнении запросов (рис. 5.8). Перекосы можно свести к минимуму, используя критерии распределения, близкого к равномерному.
При карусельной фрагментации значения данных не играют какой-либо роли. Фрагменты распределяются между разными дисками
и процессорами, и каждый очередной кортеж направляется в следующий по порядку фрагмент. Карусельная фрагментация в меньшей
мере подвержена «перекосам», как и фрагментация хешированием,
когда номер фрагмента для каждого кортежа определяется применением хеш-функции к какому-либо его атрибуту.
79
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Межпроцессорная сеть
Процессор
1
Процессор
2
Процессор
3
Процессор
4
Процессор
5
Процессор
6
Фрагменты
Рис. 5.4. Обобщенная модель фрагментации
для параллельной системы баз данных
Межпроцессорная сеть
Процессор
1
Процессор
2
1-1000
10012000
Процессор
3
Процессор
4
20013000
30014000
Процессор
5
Процессор
6
40015000
50016000
Фрагментация по диапазонам
Рис. 5.5. Фрагментация по диапазонам
в параллельных системах баз данных
80
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Межпроцессорная связь
Процессор
1
Процессор
2
Процессор
3
Процессор
4
Процессор
5
Процессор
6
Карусельная фрагментация
Рис. 5.6. Карусельная фрагментация
параллельных системах баз данных
Межпроцессорная связь
Процессор
1
Процессор
2
Процессор
3
Процессор
4
Процессор
5
Фрагментация хешированием
Рис. 5.7. Фрагментация хешированием
в параллельных системах баз данных
81
Процессор
6
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Подразделение=продавцы
Общая численность = 5500
Подразделение= менеджеры
Общая численность = 200
Рис. 5.8. Фрагментация по диапазонам и проблема «перекосов»
5.3. Параллельное выполнение реляционных
операторов и индексные структуры
После того как данные фрагментированы, параллельная система
баз данных выполняет реляционные операторы над фрагментами.
Если ранее при этом традиционно применялся подход, основанный на
использовании параллельных потоков данных, то в настоящее время
в параллельных системах баз данных все шире применяется параллельное выполнение реляционных операторов. Это стало возможным
благодаря разработанным для большинства реляционных операторов
более совершенным алгоритмам. Например, для выполнения соединения вместо сортировки со слиянием применяется алгоритм соединения методом хеширования (Hash-join). Этот алгоритм обеспечивает
разбиение оператора соединения больших таблиц на несколько независимых операторов соединения меньших таблиц, которые выполняются параллельно, что позволяет добиться линейного роста скорости
и линейного масштабирования для данного оператора [10].
Проводятся также исследования методов индексирования с целью
поиска оптимальных для параллельных систем баз данных индексных структур. Так как во многих реляционных базах данных индексы имеют древовидную структуру (В-деревья, В*-деревья, В+-деревья), то параллелизм системы базы данных не позволяет увеличить
производительность, поскольку такие индексные структуры будут
приводить к конфликтам по доступу, создавая узкие места. Одно из
82
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
возможных решений – гибридные индексные структуры (Hy Bridinde
Xstructure, HBX), в которых дерево индекса разбивается на несколько поддеревьев, а доступ управляется некоторой хеш-функцией. Гибридная индексная структура показана на рис. 5.9.
Справочник хеширования
Поддеревья
Базы данных
Рис. 5.9. Гибридная индексная структура
для параллельных систем баз данных
5.4. Перспективы развития
параллельных систем баз данных
В области параллельных систем баз данных было достигнуто немало важных результатов – стандартизация принципов реализации
(или даже самих фактических реализаций) на архитектурах без разделения ресурсов, разработка хорошо распараллеливаемых алгоритмов для выполнения реляционных операторов и др. Тем не менее, в
этой области остается еще целый ряд нерешенных проблем:
− сочетание пакетной обработки и оперативной обработки транзакций (Online Transaction Processing, OLTP) на одном сервере. В средах, предназначенных для выполнения пакетных заданий, и в средах
для OLTP-обработки существенно различаются принципы управления блокированием ресурсов и приоритетного планирования. Для
максимально эффективной обработки параллельных реляционных
операторов при сосуществовании указанных типов сред (например,
83
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
выполнение пакетных заданий, инициируемых из центра обработки
данных, и обработка случайных запросов, поступающих от отдельных пользователей) необходимо разработать модели и алгоритмы,
пригодные для этих обоих типов сред;
− оптимизация параллельных запросов. Оптимизаторы запросов
должны быть снабжены средствами для рассмотрения всех возможных параллельных алгоритмов реализации каждого оператора, чтобы
выбрать в каждом случае оптимальное сочетание конвейерного параллелизма и параллелизма с фрагментацией;
− распараллеливание прикладных программ. Имеется несколько
языков, в какой-то мере предусматривающих средства параллельного
выполнения (например, модель многозадачности в языке Ада, которая часто требует дополнительной настройки даже в современных
многопотоковых средах). Однако во многих языках, например в Коболе, вообще отсутствуют средства распараллеливания. Механизмом
для реализации параллелизма в прикладных программах должны
стать библиотечные процедуры;
− физическое проектирование баз данных. Поскольку имеются
три альтернативы фрагментации для поддержки параллельных систем баз данных, необходимы инструментальные средства проектирования, способные помочь в анализе организации базы данных
и предоставить рекомендации по выбору оптимальных стратегий
фрагментации;
− утилиты и процедуры реорганизации баз данных, выполняемые в
оперативном режиме. Если учесть, что параллельные системы баз данных будут, вероятно, оперировать терабайтовыми объемами данных,
очевидно, что традиционные процедуры загрузки, реорганизации, выдачи дампов, создания индексов и выполнения других служебных функций окажутся абсолютно непригодными в связи со значительным увеличением необходимых затрат времени. Фрагментация должна также
учитываться при реализации таких служебных функций, как создание
выборочных контрольных копий и восстановление данных.
Некоторые эксперты в области баз данных, в особенности те из них,
кто стремится умалить роль мэйнфреймов в пользу стратегий разукрупнения оборудования, утверждают, что параллельные системы баз данных – это ключ к управлению сверхбольшими базами данных, которые
становятся обычным явлением в больших корпорациях. Реализация
подобной среды требует сочетания архитектур с массовым параллелиз84
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мом обработки (МРР) и фрагментации, истоки которой лежат в теории
и практике традиционных распределенных баз данных. Классические
методы фрагментации данных нашли применение в областях, не предусматривавшихся при создании исходных алгоритмов и теорий. Подобно тому, как системы МРР дали новую жизнь концепции машины баз
данных (хотя и на основе несколько иных технологий, чем это виделось
прежде), реализации параллельных систем баз данных на основе МРР
вызвали новый интерес к технологиям фрагментации.
Тиражирование – это распределение данных не на основе модели
их разбиения (например, горизонтальной или вертикальной фрагментации), а посредством их дублирования. Для управления существующими в данной среде возможностями обновления копий со стороны приложений, а также стратегиями синхронизации копий применяются разнообразные модели (впрочем, иногда эти возможности
отсутствуют).
Можно выделить:
1.Полные или частичные копии.
2.Стратегии обновления копий:
- Синхронное,
- асинхронное/с распространением,
- активизированное/отложенное.
3.Стратегии доступа к копиям:
- все копии доступны для обновлений,
- некоторые копии доступны только для чтения.
Если обратиться к долгосрочным перспективам, связанным с оптимальными распределенными средами баз данных будущего, то
тиражирование данных представлялось вначале как некоторое промежуточное решение на пути к созданию окончательной модели множества баз данных, содержащих легкодоступные в рамках глобальной сети (Global Area Network, GAN) фрагменты данных. Разве лишь
для ускорения доступа предполагалось размещать в стратегически
важных пунктах в глобальной организации копии редко обновляемых данных, к которым можно обращаться только на чтение.
Однако меняется отношение к перспективам применения моделей
тиражирования подобно тому, как изменились взгляды на роль фрагментации. Тиражирование перестает рассматриваться как решение,
временно заменяющее «настоящие» СУБД, и приобретает новую
роль в сфере управления распределенным параллельным доступом.
85
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Управление параллельным доступом в распределенных базах данных основано на применении механизмов управления транзакциями,
например протокол двухфазной фиксации (2РС), где глобальный менеджер транзакций координирует процесс принятия решений о фиксации/откате транзакций для множества локальных менеджеров баз
данных (или в более общем случае – локальных менеджеров ресурсов). Несмотря на то, что и в продуктах СУБД, и в мониторах транзакций имеются средства 2РС, двухфазная фиксация транзакций не
получила широкого применения.
Нежелание многих организаций применять 2PC или другие подобные механизмы управления параллельным доступом связано в основном с решениями о фактическом отказе от использования средств фрагментации данных в сетевых средах. Хотя соответствующие технологии
имеются, причем достаточно зрелые, многие бизнес-модели, которые
играют определяющую роль в формировании архитектур информационных систем, просто не требуют таких возможностей. Поставщики
СУБД, хотя и продолжают по-прежнему обеспечивать свои продукты
средствами 2РС и другими механизмами управления параллельным доступом, однако уже не выдают эти возможности за достоинства, уделяя
все большее внимание технологии тиражирования.
Традиционно средства тиражирования предоставлялись в среде баз данных в виде дополнительных утилит, таких, как VAX Data
Distributor (Digital Equipment Corp.). Начиная с 1993 г., поставщики
коммерческих СУБД стали встраивать модели тиражирования (как
мы увидим, несколько моделей) непосредственно в сами механизмы
управления базами данных.
Тиражирование может быть реализовано разными способами.
Простейшая модель подразумевает наличие программного интерфейса, посредством которого прикладные программы сами осуществляют создание копий, а также реализуют стратегии их координации и
синхронизации (рис. 5.10). В более развитых декларативных моделях
(рис. 5.11) правила тиражирования и управления копиями встраиваются непосредственно в саму базу данных.
Как показано на рис. 5.11, декларативное управление обновлением копий может осуществляться средствами активных баз данных,
которые будут обсуждаться в гл. 16. Кратко отметим, активная база
данных обладает средствами, например механизмами триггеров и
хранимых процедур, которые позволяют автоматизировать выполне86
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ние некоторых действий в базе данных на основе заданных правил,
а не средствами программной логики управления базой данных со
стороны приложения или системы. В такой среде обновление какойлибо из копий объекта может, например, активизировать триггер,
который обеспечит автоматическое распространение изменений по
всем остальным копиям.
Программный
интерфейс
Распределенная база данных
Рис. 5.10. Программное управление копиями
Распознание изменений
на копии при
активациитриггеров
Программа
Активная база
данных
Рис. 5.11. Декларативное управление копиями
с помощью активных баз данных
Модели тиражирования с отложенным распространением изменений на удаленные копии (где прямые обновления разрешены только
по отношению к одной копии) могут применять схемы распространения в определенные моменты времени или по мере внесения изменений в основную копию.
Попытки реализовать синхронизацию всех копий в реальном времени с разрешением обновления любой копии приводят к большим трудностям с поддержкой целостности данных. Было предложено немало
87
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
экспериментальных моделей, включая использование временных меток
и блокировок для определения истинного состояния копий на данный
момент. Некоторые из них, вероятно, найдут применение в коммерческих продуктах, которые поддерживают тиражирование, и обеспечат
более высокий уровень непротиворечивости тиражируемых данных.
Классическая теория распределенных баз данных продолжает
интенсивно развиваться и сегодня вместе с развитием вычислительной науки и техники. Модели фрагментации, которые долгое время
считались достоянием баз данных, распределенных в сетевой среде,
приобрели новое значение с появлением СУБД для параллельных систем баз данных, используемых в качестве менеджеров больших баз
данных. Всеобщее убеждение в том, что управление параллельным
доступом в реальном времени в средах распределенных баз данных
должно осуществляться не иначе, как посредством протокола двухфазной фиксации, для многих организаций оказалось несостоятельным. Все большее число компаний начинает применять тиражирование как предпочтительное решение для управления параллельными
процессами, которое прежде считалось всего лишь временной мерой
до появления развитых средств в распределенных базах данных. Разработанные много лет назад основные концепции фрагментации и
тиражирования как механизмов распределения данных не утратили
своей ценности, но приобрели новые формы, отличные от тех, которые виделись десять или даже пять лет назад. Глобальный подход
к синтезированию распределенной среды баз данных из ранее автономных компонентов включает создание глобальных фрагментов и/
или копий на основе содержимого существующих баз данных.
Контрольные вопросы
1.Что такое тираживание?
2.Что представляет собой процесс фрагмиентации?
3.Какова классическая модель фрагментации?
4.Какова архитектура MPP?
5.Что представляют собой модели фрагментации для параллельных систем баз данных?
6. Каковы перспективы развития параллельных систем баз данных?
88
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
6. НЕОДНОРОДНЫЕ ФЕДЕРАТИВНЫЕ БАЗЫ
ДАННЫХ И МУЛЬТИБАЗЫ ДАННЫХ
Приведено описание таксономии систем мультибаз данных,
концептуальной архитектуры мультибаз данных, сервисов баз данных,
а также рассмотрено разрешение конфликтов, особенности медиаторов
и интегральная целостность данных в системах мультибаз данных.
6.1. Распределенные системы
баз данных: таксономия
− Весьма вероятно, что одним из основных свойств информационных ресурсов вашей организации наряду с распределенностью
является также их неоднородность -количеством моделей данных,
поддерживаемых в рассматриваемой среде: единственная модель
(например, реляционная) или несколько моделей (например, реляционная, плоских файлов, объектно-ориентированная);
− используемыми стратегиями распределения хранимых данных;
− наличием (отсутствием) глобальной схемы, используемой для
обеспечения прозрачного доступа к распределенным данным;
− однородностью или неоднородностью применяемых продуктов
СУБД;
− степенью поддержки в рассматриваемой распределенной среде
таких возможностей систем баз данных, как безопасность, целостность по ссылкам и др. [12].
Мы рассмотрим далее все перечисленные свойства, а также проблемы, присущие этому классу сред. Важно отметить, что цель нашего обсуждения - дать обзор существующих технологических подходов, а также достижений и нерешенных проблем в области федеративных баз данных и мультибаз данных.
На рис. 6.1 показана таксономия типов систем мультибаз данных.
Система мультибаз данных – это распределенная система, которая
служит внешним интерфейсом для доступа ко множеству локальных
СУБД или структурируется как глобальный уровень над локальными
СУБД. Сравнивая это определение с таксономией на рис. 6.1, можно отметить, что общий термин «распределенная база данных» на
89
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
самом деле имеет несколько более ограниченное значение, чем мы
иногда в него вкладываем (употребляя его, например, вместо термина «мультибаза данных»).
Сильно
связанные
системы
Распределение базы данных
Однородных
Глобальная схема
Внутренние функции СУБД для обеспечения интерфейса между глобальными
и локальными уровнями
Мультибазы данных с глобальной схемой
Неоднородные
Глобальная схема
Пользовательские интерфейсы СУБД для отображения между глобальными и
локальными уровнями
Федеративные базы данных
Неоднородные
Частичная глобальная схема
Пользовательские интерфейсы СУБД для отображения между глобальными и
локальными уровнями
Неоднородные системы мультибаз данных с общим языком доступа
Неоднородные
Функции языка доступа
Пользовательские интерфейсы СУБД для отображения между глобальными и
локальными уровнями
Однородные системы мультибаз данных с общим языком доступа
Однородные
Функции языка доступа
Пользовательские интерфейсы СУБД и некоторые внутренние функции
СУБД для отображения между глобальными и локальными уровнями
Интероперабельные системы
Множество типов источников данных
Отсутствие глобальной интеграции
Реализаци интерфейса между глобальным и локальным уровнями средствами
приложения
Слабо
связанные
системы
Рис. 6.1. Таксономия систем мультибаз данных [12]
Следует учесть также, что классификация и номенклатура систем,
представленные на рис. 6.1, не являются общепринятыми. Существует
альтернативная таксономия, которая выделяет два подхода: системы с
объединенной схемой (архитектура глобальной схемы) и мультибазы
данных (безглобальной схемы). В этой таксономии термин «мультибаза
90
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
данных» употребляется в специальном смысле, а не как родовой термин
для обозначения всех типов множественных баз данных.
Учитывая это, рассмотрим теперь различные классы системы
мультибаз данных (см. рис. 6.1). В верхней части изображенной на
рисунке оси, соответствующей максимальной нитрации и взаимосвязи компонентов, располагаются однородные распределенные базы
данных, функционирующие под управлением общей глобальной схемы (которая, в свою очередь, отображается в схемы поддерживающих
баз данных). Для обеспечения отображения и интерфейсов используются внутренние функции самой СУБД. Эта модель распределения
получила признание в последние годы, и далее будет пользоваться
популярностью в области параллельных систем баз данных. Хотя она
пока по-прежнему применяется и в средах LAN/WAN, такие архитектуры вряд ли найдут широкое распространение в корпоративных
средах в основном из-за их неспособности справляться с проблемой
неоднородности (когда необходимо иметь дело с несколькими разнородными продуктами СУБД или моделями данных).
На следующем уровне систем мультибаз данных добавляется неоднородность, но используется глобальная схема. Отсюда название
систем этого класса – мультибазы данных с глобальной схемой. Как
и в случае с однородными распределенными базами данных, клиентские приложения оперируют с глобальной схемой, как если бы она
представляла одну большую централизованную базу данных. Все
отображения в поддерживающие базы данных и их содержимое обрабатываются средствами глобального уровня.
Однако в отличие от однородных распределенных баз данных
мультибазы данных с глобальной схемой не обладают внутренними функциями СУБД, позволяющими поддерживать отображение и
интерфейс между глобальным и локальным уровнями в связи с тем,
что неоднородность исключает возможность реализации такого внутреннего отображения (таким образом, интерфейсы СУБД являются
внешними по отношению к ней и должны создаваться и управляться
по мере необходимости). Это происходит отчасти из-за того, что уже
существующие локальные СУБД и базы данных включаются в среду,
управляемую глобальной схемой, без определенных изменений на
локальном уровне.
В частности создание всеобъемлющей глобальной схемы само по
себе –весьма нетривиальная задача. Сложность ее объясняется тем,
91
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
что, во-первых, глобальная схема определяет полный универсум элементов данных среды, и, во-вторых, все изменения в составляющих базах данных (перемещения данных, последовательное тиражирование)
должны распространяться и на глобальную схему, чтобы обеспечить
правильное отображение между глобальным и локальным уровнями.
На самом деле этот подход при ближайшем рассмотрении оказывается значительно сложнее, чем представляется на первый взгляд.
Концептуально классическая архитектура систем мультибаз данных
выглядит относительно просто, причем за отображение глобального
уровня в локальный отвечают сервисы справочников. Рассмотрим,
однако, вариант, когда клиентские приложения сами распределены на
множестве узлов. Это означает, что каждое приложение для осуществления какой-либо операции над локальной базой данных должно
иметь доступ к глобальной схеме, и это должно быть предусмотрено
в архитектуре глобальной схемы. Один из возможных подходов заключается в том, что глобальная схема является централизованной
и поддерживается на одном узле (и, возможно, тиражируется на небольшое число узлов в пределах компании). При этом все запросы
со стороны клиентских приложений с любого узла должны сначала
поступать на один из узлов справочника, для того чтобы получить
доступ к глобальной схеме. Недостатки такого подхода очевидны:
основная причина для создания сред управления распределенной
информацией – это исключение узких мест, а направление запросов
от всех приложений распределенной среды на небольшое число расчетных центров приведет к «заторам» в сетевом трафике, особенно в
организациях с интенсивной обработкой транзакций [11].
Во-первых, значительная доля обработки, запрашиваемой приложением, скорее всего, будет относиться к локальным данным. Вовторых, следуя этой логике, нужно признать, что использование глобальной схемы для обработки локальных запросов – не самый рациональный подход. Для обработки таких запросов разумнее обращаться
к локальной схеме «своей» базы данных. Учитывая эту парадигму доступа к данным, можно сделать вывод о том, что обязательное использование глобальной схемы для доступа к локальным данным создает
не только дополнительные накладные расходы на отображение данных, но и избыточный сетевой трафик, если клиентское приложение
выполняется на узле, где отсутствует экземпляр глобальной схемы.
92
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Существует также альтернативный подход, при котором глобальная схема распределена по всем узлам корпоративной сети, где могут выполняться клиентские приложения для того, чтобы исключить
необходимость удаленного доступа приложений к сервисам отображения и справочника, предоставляемым схемой. Негативная сторона
этого подхода заключается в том, что теперь все изменения в глобальной схеме придется распространять по многим узлам сети, что также нельзя считать тривиальной задачей. В зависимости от степени
изменчивости распределения информационных ресурсов в данной
среде (которая может варьироваться от сравнительно низкой с относительно редкими изменениями в глобальной схеме до крайне высокой,
когда схема изменяется очень часто) рассматриваемый подход может
порождать серьезные проблемы, связанные со снижением пропускной
способности сети, а также с поддержанием целостности данных (последняя группа проблем возникает в ситуациях, когда изменения, вызванные перераспределением данных или корректировкой схемы, не
успевают своевременно распространиться на один или более узлов).
Можно представить себе такую среду, где клиентские приложения
сами располагают средствами, позволяющими определять, нужен
ли им в той или иной ситуации доступ к глобальной схеме. Иными
словами, подход, основанный на глобальной схеме, можно было бы
использовать для доступа клиентских приложений к удаленным данным. Но этот подход приводит к излишним накладным расходам и к
потенциальному снижению производительности в случае доступа к
локальным данным. Среда, поддерживающая разные типы доступа
различными способами, позволяет исключить указанные недостатки.
Таким образом, мы подходим к еще одному классу систем мультибаз
данных – к федеративным базам данных.
Федеративная база данных в отличие от мультибазы данных с
глобальной схемой не располагает полной глобальной схемой, к которой обязательно обращаются все приложения. Вместо этого поддерживается локальная схема импорта/экспорта (например, справочник
информации, доступной где-либо в пределах компании). В федеративных базах данных используются частичные глобальные схемы. На
каждом узле поддерживается частичная глобальная схема, описывающая только информацию из удаленных источников, которая необходима для выполнения бизнес-функций на этом узле.
93
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Отметим, что некоторые сложности, свойственные мультибазам
данных с глобальной схемой, при этом все равно сохраняются. Так,
по-прежнему необходимо распространять изменения, производимые
в глобальной схеме, на соответствующие узлы (необязательно всегда
в масштабе всей корпорации, а только в пределах некоторой ее части).
К тому же возникает дополнительная проблема, так как приходится
решать, какие именно данные, имеющиеся в компании, нужны для
приложений на каждом конкретном узле, и эта информация должна определенным образом моделироваться и соответственно представляться в схеме импорта/экспорта узла. Таким образом, в федеративной базе данных мы отказываемся от подхода, при котором все
представлено в глобальной схеме (обратись туда и возьми это, когда
тебе нужно). Здесь мы имеем определенную промежуточную модель
между управлением распределенной информацией с архитектурой
клиент-сервер и мультибазами данных с глобальной схемой. Разумеется, в этой ситуации, если на каком-то узле возникает потребность
в доступе еще к каким-то удаленным данным, или если метаданные
некоторого используемого удаленного узла изменились, то приходится вносить изменения и в локальную схему импорта/экспорта.
Преимущества этого подхода состоят в том, что мы точно указываем, что нам фактически нужно, а не сваливаем все в одну кучу.
В очень крупных распределенных средах поддержка общей схемы
вполне может оказаться неуправляемым процессом. В таком случае
федеративный подход, возможно, будет более легким и для моделирования, и для реализации.
Следующий уровень предлагаемой таксономии, соответствующий
еще более слабосвязанной организации среды, чем для федеративных
баз данных, – это мультибазы данных с общим языком доступа. Фактически они представляют собой распределенные среды управления информацией с технологией клиент-сервер. В среде мультибазы данных
с общим языком доступа – неоднородной или однородной – глобальная схема вообще отсутствует, а для запросов данных из удаленных
источников используются функции языка доступа (некоторый интерфейс прикладного программирования). Как и в федеративных базах
данных с частичной схемой, здесь также необходимо заранее определить, какие объекты данных из удаленных источников нужны клиентским приложениям каждого узла, и обеспечить эти возможности.
Наконец, наиболее слабо связанными являются интероперабельные системы, в которых сами приложения, выполняемые в среде той
94
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
или иной СУБД, ответственны за интерфейсы между различными
средами управления данными, независимо от того, являются ли они
однородными или неоднородными. Интероперабельные системы
ориентированы главным образом на обмен данными, а не на обработку, типичную для баз данных. Они представляют организацию
управления информацией прошлого дня.
6.2. Концептуализация архитектуры
мультибаз данных
Мультибазы данных с глобальной схемой являются концептуально классической архитектурой, на которую примерно с начала 1980-х
гг. ориентируются и поставщики СУБД, и авторы исследовательских
проектов. На рис. 6.2 представлена эта классическая архитектура, где
уровень глобальной схемы отображается в среду СУБД и в локальные схемы отдельных поддерживающих узлов.
Помимо сложности и потенциальных недостатков, которые отмечались в предыдущем разделе, следует обратить внимание еще на
некоторые моменты, связанные с таким подходом и архитектурой. Глобальная схема теоретически может быть представлена в рамках любой
информационной модели, подходящей для данной среды. В большинстве (в 11 из 16) прототипов и исследовательских систем, перечисленных в работе М. Брайта и др., для представления глобальной схемы
использовалась реляционная модель. В остальных случаях для этой
цели использовались концептуальные модели типа сущность – связь
или некоторый абстрактный концептуальный подход.
До недавнего времени применение реляционной модели для представления глобальной схемы было оправданно, поскольку и поддерживающие базы данных были в основном реляционными. Даже если
в такую среду были интегрированы нереляционные системы (например, IMS или система типа CODASYL), то все равно можно было
использовать точно определенные отображения между глобальным
реляционным уровнем и поддерживающими иерархической или сетевой моделью таким образом, чтобы приложения могли программироваться, как если бы они должны были взаимодействовать исключительно с реляционными базами данных.
95
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Появление объектно-ориентированных баз данных, обладающих
более богатыми средствами представления семантической информации, поставило под вопрос применение реляционной модели для представления глобальных схем (безотносительно к преимуществам или
недостаткам самой этой архитектуры по сравнению с другими типами
мультибаз данных, приведенными в классификации на рис. 6.1).
Клиентские
Клиентские
Клиентские
приложения
приложения
приложения
Интегрирующий слой: глобальная схема или другой механизм интеграции
Механизм обработки
распределенных
процессов
Oracle
Другие
реляционные
системы
Менеджер
транзакций
Сервисы баз
данных
предприятия
DB2
Rdb/VMS
Объектные
СУБД
Сервисы словарей и
справочников
Xbase
Система плоских
файлов
Другие
менеджеры
данных
Рис. 6.2. Классическая архитектура мультибазы
данных с глобальной схемой
Поскольку в последние годы объектно-ориентированные СУБД и
базы данных все чаще используются в качестве компонентов мультибаз данных с глобальной схемой, хотелось бы на концептуальном
уровне удерживать больше семантической информации, чем это возможно в рамках базовой реляционной модели. Будет ли использована
в качестве такой семантически богатой глобальной модели некоторая
расширенная реляционная модель, основанная на хорошо проработанных методах концептуального моделирования (сущность – связь
или иная современная объектно-ориентированная модель данных, например, модель ODMG) -независимость данных. Этот сервис отделяет данные от приложений, с которыми они тесно связаны (например,
файлы были созданы определенным набором прикладных программ);
96
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
− свойства транзакций – свойства атомарности, непротиворечивости, изолированности, долговременного сохранения (ACID -интероперабельность между неструктурированными и полуструктурированными данными. Базы данных предоставляют средства, с
помощью которых объекты данных могут связываться друг с другом
для определенных видов обработки независимо от используемой модели данных (например, указатели в иерархических и сетевых системах или реляционные операторы в реляционных системах). Данные,
представленные вне СУБД, не обладают такими возможностями, но
для интеграции их в среду мультибаз данных эти свойства необходимо обеспечить. Инструментальные средства и утилиты для поддержки взаимосвязей в сочетании с имеющими высокий уровень гранулярности мощными репозиториями, хранящими метаданные для
данных, представленных вне СУБД, вероятно, смогут предоставлять
информацию о взаимных связях между объектами данных;
− фильтрацию информации. Средства выполнения запросов (такие, как SELECT ... WHERE <предикат>), обычные для среды баз
данных, могут быть с относительно небольшими изменениями реализованы и для среды плоских файлов (например, для файлов VSAM
или RMS), но расширение подобных средств фильтрации на системы
обработки документов, электронных таблиц, графических образов
или других совершенно неструктурированных объектов − исключительно сложная задача. Важно предоставить средства обработки случайных запросов, связанных с графической информацией (например,
ПОКАЗАТЬ ФОТОГРАФИИ ВСЕХ СОТРУДНИКОВ С УСАМИ) и
с документами, причем это должно быть возможно через посредство глобальной схемы и для удаленно выполняемых приложений.
Отметим, что появляющиеся в последнее время пространственные
базы данных, базы данных графических образов или текстовые базы
данных предоставляют подобные средства, но только по отношению
к объектам, хранимым в среде базы данных, а не к неструктурированным объектам, хранимым в файловых системах. До тех пор, пока
такие данные не будут полностью перенесены из файловых систем
в базы данных графических образов и текстовой информации (что,
вероятно, никогда не произойдет), будет сохраняться необходимость
в средствах для их фильтрации;
− управление активностью. Тенденция к обеспечению баз данных
средствами управления активностью (триггеры и хранимые процеду97
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ры в реляционных системах, методы в объектно-ориентированных
средах) привела к тому, что программная логика приложений все в
большей степени переносится непосредственно в менеджеры данных.
Для того чтобы это можно было осуществить и в файловых системах,
необходим ряд дополнительных сервисов. Пожалуй, наиболее общий
подход к обеспечению традиционных систем такими средствами −
это инкапсуляция, подобная используемой в средах с брокером объектных запросов (Object Request Broker, ORB). Благодаря оболочке,
при помощи которой информация, определяющая поведение системы, объединяется с самими обрабатываемыми данными, «небазоданновая» система может получить средства управления активностью, в
значительной мере подобные имеющимся в современных СУБД [12].
Реализация сервисов баз данных для сред, не использующих
СУБД, − это насущная необходимость для всего последующего развития управления информацией. Какой бы механизм интеграции
мы ни выбрали для создания и управления распределенной средой
(традиционная архитектура клиент-сервер, клиент-сервер на основе
ORB, мультибазы данных с глобальной схемой или какой-либо иной
вариант), в любом случае придется встраивать в эту среду данные,
хранимые и управляемые иными средствами, отличными от СУБД.
Существующие сегодня механизмы интеграции таких «небазоданновых» сред обычно сводятся к пакетному импорту/экспорту или
(если применяется какого-либо рода уровень глобальной схемы) к
средствам доступа только на чтение. Чтобы распространить на такие интерфейсы парадигму доступа в реальном времени, необходимо
обеспечить для таких данных доступ на чтение-запись наравне с информацией, содержащейся в базах данных, а также описанные выше
дополнительные сервисы.
6.4. Разрешение конфликтов
Известна одна из проблем, которую приходится решать при объединении данных в среде логически централизованных хранилищ
данных, а именно несоответствие типов, размеров и других свойств
представления информации. Эта же проблема возникает и при создании мультибаз данных, когда при построении мультибаз данных по
методу «снизу вверх» используется глобальная схема.
98
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Отметим, что для сред мультибаз данных проблема несоответствия свойств данных стоит значительно серьезнее, чем для хранилищ
данных, поскольку здесь необходим доступ в реальном времени или
почти в реальном времени и общее время обработки запросов включает затраты на отображение в поддерживающее «реальные источники» данных. Что же касается хранилищ данных, то приложения
информационной системы руководителя (EIS) обращаются уже к
самому хранилищу данных, а не к исходным операционным базам
данных, из которых извлекаются данные, причем разрешение конфликтов может осуществляться не обязательно в реальном времени
(в зависимости от спецификации конкретной среды).
В системах мультибаз данных, способных адекватно справляться
с такими конфликтами, необходимо заранее формализовать все типы
ситуаций, при которых, вероятно, могут возникать конфликты. Это
позволит разрешать их с помощью подхода, основанного на правилах.
Полезно различать два типа конфликтов схем и конфликты данных. К конфликтам схем относятся следующие:
1. Конфликты между таблицами, которые можно подразделить
на конфликты вида «1:1» и вида «M:N». Конфликты между таблицами вида «1:1» могут выражаться в использовании разных имен для
эквивалентных таблиц; если используются одинаковые имена, то все
равно может возникнуть конфликт, выражающийся в отсутствии какого-либо атрибута в одной или нескольких локальных таблицах, что
приведет к особым затруднениям при выполнении операции UNION
(объединение). Чтобы клиентские приложения могли оперировать в
терминах глобальных схем, и запросы правильно отображались на
множество поддерживающих локальных баз данных, в системе мультибаз данных необходимо предусмотреть процедуры разрешения таких конфликтов.
Конфликты между таблицами «M:N» характерны для реляционных сред, которые возникают в результате процессов нормализации
и денормализации. Например, в одной локальной базе данных для
представления некоторой совокупности информации (инвентарного
списка видеокассет) может использоваться n таблиц, а в другой локальной базе та же информация представлена в х таблицах. Чтобы
правильно оперировать с этими двумя базами данных с пониманием
того, что в этих таблицах представлена одна и та же информация,
необходимо разрешать подобные конфликты.
99
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2. Конфликты между атрибутами, которые возникают в ситуациях, отчасти аналогичных конфликтным ситуациям между таблицами (например, используются различные имена для эквивалентных
атрибутов или одно и то же имя представляет разные атрибуты в
эквивалентных таблицах разных локальных баз данных), но могут
возникать также и в иных случаях. Возможны, например, конфликты принимаемых по умолчанию значений и конфликты ограничений.
Для атрибутов также возможны конфликты вида «M:N»: если в одной
локальной базе данных для представления некоторой информации
используется один атрибут, а в другой базе данных та же информация
представлена двумя или более атрибутами.
3. Конфликты между таблицами и атрибутами, которые возникают, когда в одной локальной базе данных представления некоторой
сущности используется отдельная таблица, а в другой – набор атрибутов какой-либо иной таблицы. Этот конфликт обычно проявляется
вследствие неполного соответствия третьей нормальной форме таблиц в какой-либо локальной базе данных (не ключевые зависимости).
В такой базе данных может быть определена, например, таблица вида:
СОТРУДНИК
(ид_сотр,
фио_сотр,
адрес_сотр,
ид_отдела,
назв_отдела, доход_отдела,)
Если бы эта таблица была подвергнута нормализации, то была бы
создана отдельная таблица с информацией об отделе с первичным
ключом «ИД_ОТДЕЛА» и остальными атрибутами отдела. Если нормализация этой таблицы была проведена не во всех локальных базах данных, то при семантическом согласовании придется разрешать
аналогичного рода конфликты.
Конфликты другого типа – конфликты данных – включают несколько дополнительных классов, соответствующих случаям использования различных представлений для одних и тех же данных (например, типы, размеры и др.) в разных локальных базах данных, а
также ситуациям, когда имеются:
− устаревшие данные, например, различные цены на прокат одной и той же видеокассеты, хранимые в локальных базах данных разных магазинов;
− неверно введенные данные; эта ситуация аналогична предыдущей в том отношении, что в базах данных будут храниться разные
значения элемента данных, которые на самом деле должны быть оди100
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
наковыми, но здесь одно или несколько значений просто оказались
по каким-то невыясненным причинам ошибочными.
Отметим, что эти типы конфликтов данных особенно актуальны
для сред мультибаз данных с тиражированием: операции над распределенной базой данных, выполненные с участием разных копий
одних и тех же данных, дадут разные результаты, которые на самом
деле должны быть одинаковыми.
Как отмечается, проблема разрешения некоторых из перечисленных типов конфликтов требует весьма значительных дополнительных исследований. От реализации полнофункционального и надежного разрешения конфликта для систем мультибаз данных с глобальной схемой нас реально отделяет еще несколько лет. Следовательно,
организации, заинтересованные в указанных аспектах управления
распределенной информацией, должны пристально следить за прогрессом в этой области.
6.5. Медиаторы
Еще один подход к разрешению конфликтов – использование медиаторов. Медиатор – это программный модуль, предназначенный
для упрощения, абстрагрования, сокращения, слияния и объяснения данных, которыми обмениваются приложения и базы данных
в некоторой среде. Идея медиаторов опирается на такие понятия,
как искусственный интеллект и базы знаний, а также базы данных
и управление информацией. К числу функций медиаторов, помимо
разрешения конфликтов, относятся следующие:
- сбор необходимого объема данных. В зависимости от типа запрашиваемой операции в системе баз данных может потребоваться выбор различного количества информации из одного или более
источников. Медиатор благодаря его «интеллекту» может помочь в
принятии подобных решений;
- поддержка абстракции и обобщения. Медиаторы могут оказать
помощь в процессе агрегирования данных в связи со средами хранилищ данных и информационных баз данных;
- интеграция текста с данными. Большая доля корпоративных ресурсов данных поддерживается в виде графических образов и в осо101
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
бенности в виде текстов. Медиатор, выступая в роли внешнего интерфейса для доступа к этим классам информации, может содействовать
«регуляризации» текстов и графических образов для упрощения их
последующей обработки и интеграции с другими формами данных;
- поддержка промежуточных результатов. Хотя для некоторых
операций в базах данных наиболее подходящими исходными данными могут быть агрегированные или производные данные, то для
исследований, связанных с анализом причин (например, специалист
применяет EIS-приложение, чтобы выяснить, почему произошло событие XYZ), необходима также некоторая промежуточная информация. Медиаторы могут оказаться полезными и в этой области.
В системах мультибаз данных медиаторы могут функционировать
в рамках многоуровневой архитектуры, другие классы мультибаз данных, представленные в таксономии на рис. 6.2, могут, однако, включать медиаторы также и в интерфейсы частичных глобальных схем
или интерфейсы клиент-сервер. Фактически медиаторы способны
использовать встроенное знание об определенных множествах или
подмножествах данных для того, чтобы поставлять информацию для
приложений более высокого уровня. Они должны при этом входить
в состав промежуточного звена трехзвенной архитектуры между
пользователем (клиентские приложения) и базой (множеством баз)
данных. Специфические применения медиаторов в средах мультибаз
данных с глобальной схемой: выяснение местоположения (где находятся данные, необходимые для выполнения нужной операции), отображение (как отображаются локальные базы данных в глобальную
схему) и разрешение конфликтов (каков результат отображения и согласования данных, какие противоречия должны быть разрешены).
Если перенести идею медиаторов из сферы глобальной схемы в
модель клиент-сервер, мы получим трехзвенную архитектуру по существу, не отличающуюся от архитектуры брокеров объектных запросов (ORB). Фактически медиаторы могут быть распределены с учетом сетевых накладных расходов и других параметров так, чтобы они
были доступны клиентским приложениям и обеспечивали бы поддерживающие локальные базы данных различными видами сервисов.
На первый взгляд может показаться, что медиаторы – это лишь
несколько модифицированная реализация средств управления распределенной информацией. Однако уникальность этого подхода за102
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ключается в том, что в области информационных систем медиаторы
используют достижения как искусственного интеллекта, так и управления базами данных. В силу этого можно ожидать, что когда-либо
они привнесут в сферу информационных система такие «продукты»
искусственного интеллекта, как поддержка знаний и обучаемость.
Если когда-нибудь произойдет взаимопроникновение искусственного интеллекта и управления информацией, то его результаты, несомненно, будут способствовать разрешению многих сложных проблем
в области распределнных мультибаз данных.
6.6. Интегральная целостность данных
в системахмультибаз данных
В 90-х гг. ХХ в. вместе с развитием языков баз данных, особенно
SQL, получили значительное развитие и методы поддержки целостности данных. Такие возможности, как ограничения целостности
по ссылкам, помогли в решении многих проблем целостности данных в прикладном программировании благодаря созданию более
декларативной модели, хранимой и обеспечиваемой средствами самой базы данных.
Эти достижения в области целостности фактически неприменимы
в средах мультибаз данных, особенно неоднородных, создаваемых
по методу «снизу вверх». Даже если бы имелась глобальная схема,
по отношению к которой можно было бы определить ограничения
целостности, связывающие несколько локальных баз данных, ни
одна из локальных СУБД не была бы способна поддерживать их во
взаимодействии с другими, по крайней мере, в своем естественном
режиме функционирования. Чтобы обеспечить такую степень декларативного управления целостностью, которая свойственна современным базам данных, в среде мультибаз данных должен существовать
некоторый глобальный механизм управления целостностью.
Один из подходов состоит в том, чтобы определить на глобальном
уровне синтаксис и семантику с использованием политранзакций –
транзакций глобального уровня, способных генерировать последовательности взаимосвязанных транзакций, которые бы обеспечивали взаимную непротиворечивость на множестве взаимосвязанных
103
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
баз данных. Так, если компоненты двух различных локальных баз
данных описаны в специальной схеме межбазовых зависимостей
как связанные некоторой зависимостью, то транзакции глобального
уровня могли бы автоматически отображаться в поддерживающие
локальные транзакции для того, чтобы конролировать интегральную
целостность баз данных.
С этим подходом связаны некоторые трудности, которые необходимо преодолеть:
1. Транзакции в локальных базах данных, которые обычно не связаны с обращением к глобальной схеме, могут затрагивать субъекты
межбазовых зависимостей. Как решить эту проблему? Значит ли это,
что нам придется вернуться к подходу, когда все контролируется глобальной схемой? Или на каждом узле поддерживать схему, определяющую межбазовые зависимости так, чтобы при выполнении каждой
локальной транзакции можно было бы предварительно установить,
затрагиваются ли ею какие-либо межбазовые зависимости, и в случае положительного ответа выполнять требуемые операции через посредством глобальной схемы?
2. Если же глобальной схемы вообще нет (например, при распределенной среде с архитектурой клиент-сервер), как тогда поддерживать межбазовые зависимости? Может быть, жестко встраивать их в
логику сервера?
Интегральная целостность данных – в системах мультибаз данных – исключительно важная область, требующая значительных исследовательских усилий. Свойства мультибаз данных, даже когда они
будут достаточно развиты, не смогут использоваться в полной мере
без решения проблем интегральной целостности для неоднородной
распределенной среды.
Контрольные вопросы
1.Что представляет собой мультибаза данных?
2.Какова таксономия систем мультибаз данных?
3.Что представляет собой федеративная база данных?
4.Что такое конфликты схем и конфликты данных?
5.Что такое медиаторы?
6.Каковы функции медиаторов?
104
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
7. ПЕРСПЕКТИВЫ УПРАВЛЕНИЯ
РАСПРЕДЕЛЕННОЙ ИНФОРМАЦИЕЙ
Описаны модели распределения информации, параллельных машин
баз данных, проблемы управления распределенной нформацией и перспективные направления в управлении распределенной информацией.
7.1. Модели распределения информации
В качестве моделей распределения информации можно рассматривать следующие виды архитектур.
Архитектура файл-сервер
В данной архитектуре (рис. 7.1) предполагается выделение одного компьютера в качестве центрального – сервера файлов. На нем
хранится совместно используемая централизованная БД. Все другие компьютеры выполняют функции рабочих станций, с помощью
которых поддерживается доступ к БД. Файлы БД в соответствии с
пользовательскими запросами передаются на рабочие станции, где
в основном и производится обработка данных. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает (рис. 7.1).
Файл – сервер
(хранение данных)
Передача файлов БД
для обработки
Рабочая станция
(обработка данных и
анализ результатов)
Рабочая станция
(обработка данных и
анализ результатов)
Рис. 7.1. Архитектура файл-сервер
Обработка предполагает следующие операции с данными базы:
− поиск (найти сведения по ФИО);
− сортировка (расположить все по ФИО, датам, по убыванию или
возрастанию);
105
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
− фильтрация (отбор данных по условию);
− добавление;
− обновление;
− удаление.
Анализ данных предполагает вычисления по программе.
Архитектура клиент-сервер
В данной архитектуре предполагается, что центральный компьютер помимо хранения централизованной БД выполняет и обработку
данных базы по запросам компьютера – клиента.
Сервер БД
(хранение и обработка данных)
Запрос
Рабочая станция
(анализ результатов)
Передача результатов
обработки данных из
базы
Рабочая станция
(анализ результатов)
Рис. 7.2. Архитектура клиент-сервер
Результаты обработки (поиска, сортировки, фильтрации) сервер отправляет по сети рабочей станции, инициировавшей клиентский запрос
(проверка паспортных данных сотрудниками МВД с помощью КПК).
Преимуществом данной архитектуры является небольшая нагрузка на сеть и невысокие требования к техническим характеристикам
рабочих станций. Ими могут быть различные мобильные электронные устройства.
Многоуровневая архитектура
В данной архитектуре предполагается использование сложных
программ, по которым анализируются данные, полученные из базы
[2]. Эти программы не всегда можно установить и использовать на
рабочих станциях, в качестве которых могут выступать мобильные
устройства. Поэтому для упрощения администрирования сети и облегчения процессов модернизации ПО однотипная для всех рабочих
станций программа устанавливается на сервере приложений. Этот
сервер используется для:
− формирования SQL-запросов к серверу БД,
− анализа данных, полученных из базы,
106
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
− передачи результатов анализа данных рабочей станции, инициировавшей запрос.
Рабочая станция
Программа интерфейс
пользователя
Ввод сведений для
получения кредита
Сервер приложений
Программа формирования
запросов и анализа данных,
полученных из БД
Сервер БД
СУБД и БД
Формирование запроса к базе, анализ
полученных сведений и данных из
базы, формирование результата
Поиск
необходимых
данных в базе
Рис. 7.3. Многоуровневая архитектура
Интернет/интранет архитектура
В данной архитектуре предполагается использование сложных
программ, по которым анализируются данные, полученные из базы.
Эти программы не всегда можно установить и использовать на рабочих станциях, в качестве которых могут выступать мобильные
устройства. Поэтому для упрощения администрирования сети и облегчения процессов модернизации ПО однотипная для всех рабочих
станций программа устанавливается на Web-сервере. Web-сервер используется для:
- получения параметров, передаваемых с рабочей станции,
- формирования SQL-запросов к серверу БД,
- анализа данных, полученных из базы,
- формирования содержимого HTML-страницы, содержащей результаты анализа данных,
- передачи результатов анализа данных рабочей станции, инициировавшей запрос.
Рабочая
станция
Программа –
Web-броузер
Ввод сведений для
получения кредита
Web-cервер
Программа – серверный сценарий (PHP, ASP)
для формирования запросов к БД, анализа
данных, полученных из базы и формирования
содержания HTML –страницы, передаваемой на
рабочую станцию
Формирование запроса к базе, анализ полученных
сведений и данных из базы, формирование результата
Рис. 7.4. Интернет/интранет архитектура
107
Сервер БД
СУБД и БД
Поиск необходимых
данных в базе
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
7.2. Параллельные машины баз данных
В конце второго тысячелетия человечество шагнуло из индустриальной эры в эру информационную. Если раньше главными были материальные ресурсы и рабочая сила, то теперь решающими факторами развития общества становятся интеллект и доступ к информации.
В информационном обществе люди в основном будут заняты в сфере
создания, распределения и обмена информацией, а каждый человек
сможет получить необходимый продукт или услугу в любом месте и
в любое время.
Как известно, основной инструмент хранения и переработки информации – электронные вычислительные машины (ЭВМ). Переход
к информационному обществу сопровождается лавинообразным
ростом объемов информации, хранимой в них. Это порождает проблему эффективной организации и поиска информации. Для представления в машинах больших объемов данных используются технологии баз данных. База данных представляет собой совокупность
структурированных и взаимосвязанных данных, хранимых более или
менее постоянно в ЭВМ на магнитных (пока) носителях и используемых одновременно многими пользователями в рамках некоторого
предприятия, организации или сообщества. Для работы с базами данных используется специальное системное программное обеспечение,
называемое СУБД (Система управления базами данных). Вычислительный комплекс, включающий в себя соответствующую аппаратуру (ЭВМ с устройствами хранения) и работающий под управлением
СУБД, называется машиной баз данных.
Первые такие машины появились во второй половине 60-х годов
ушедшего века. В настоящее время на рынок программного обеспечения поставляются сотни различных коммерческих СУБД практически для всех моделей ЭВМ. До недавнего времени большинство
машин баз данных включали в себя только один процессор. Однако
в последнее десятилетие возник целый ряд задач, требующих хранения и обработки сверхбольших объемов данных. Один из наиболее
впечатляющих примеров решения задач такого типа – создание базы
данных системы наблюдения Земли. Эта система (Earth Observing
System, EOS) включает в себя множество спутников, которые собирают информацию, необходимую для изучения долгосрочных тен108
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
денций состояния атмосферы, океанов, земной поверхности [12].
Спутники поставляют на Землю 1/3 петабайт информации в год
(petabyte – 1015 байт), что сопоставимо с объемом информации (в кодах ASCII), хранящейся в Российской государственной библиотеке.
Полученная со спутников, она накапливается в базе данных EOSDIS
(EOS Data and Information System) невиданных прежде размеров.
Другая грандиозная задача, тоже требующая использования
сверхбольших баз данных, ставится в проекте создания виртуальной
астрономической обсерватории. Такая обсерватория должна объединить данные, получаемые всеми обсерваториями мира в результате
наблюдения звездного неба; объем этой базы составит десятки петабайт. Очевидно, даже самые мощные однопроцессорные ЭВМ не
справятся с обработкой этого потока.
Естественное решение проблемы обработки сверхбольших баз
данных – использовать в качестве машин баз данных многопроцессорные ЭВМ, позволяющие организовать параллельную обработку
информации. Интенсивные исследования в области параллельных машин были начаты в 80-х годах. В течение последних двух десятилетий
такие машины проделали путь от экзотических экспериментальных
прототипов, разрабатываемых в научно-исследовательских лабораториях, к полнофункциональным коммерческим продуктам, поставляемым на рынок высокопроизводительных информационных систем.
В качестве примеров успешных коммерческих проектов создания
параллельных систем баз данных можно назвать DB2 Parallel Edition
[1], NonStop SQL [2] и NCR Teradata [3]. Подобные системы объединяют тысячи процессоров и магнитных дисков и способны обрабатывать базы данных в десятки терабайт. Тем не менее, и в настоящее
время здесь остается ряд проблем, требующих дополнительных научных изысканий. Одно из них – дальнейшее развитие аппаратной
архитектуры параллельных машин. Как указывается в Асиломарском отчете о направлениях исследований в области баз данных [4],
в ближайшее время крупные организации будут располагать базами
данных объемом в несколько петабайт. Для обработки подобных объемов информации потребуются параллельные машины с десятками
тысяч процессоров, что в сотни раз превышает их число в современных системах. Однако традиционные архитектуры параллельных машин баз данных вряд ли допускают простое масштабирование на два
порядка величины.
109
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Сила и слабость параллельных систем
В основе современной технологии систем баз данных лежит реляционная модель, предложенная Е. Ф. Коддом еще в 1969 г. [5]. Первые реляционные системы появились на рынке в 1983 г., а сейчас они
прочно заняли доминирующее положение. Реляционная база данных
состоит из отношений, которые легче всего представить себе в виде
двумерных (плоских) таблиц, содержащих информацию о некоторых классах объектов из предметной области. В случае базы данных,
хранящей список телефонных номеров, таким классом объектов будут абоненты городской телефонной сети. Каждая таблица состоит
из набора однородных записей, называемых кортежами. Все кортежи в отношении содержат один и тот же набор атрибутов, которые
можно рассматривать как столбцы таблицы. Атрибуты представляют
свойства конкретных экземпляров объектов определенного класса.
Примерами атрибутов отношения Телефонная_книга могут служить
Фамилия, Номер, Адрес. Совокупность отношений и образует базу
данных, которая в виде файлов специального формата хранится на
магнитных дисках или других устройствах внешней памяти.
Над реляционными отношениями определен набор операций,
образующих реляционную алгебру. Аргументами и результатами реляционных операций являются отношения. Запросы к реляционным
базам данных формулируются на специальном языке запросов SQL
(ранее называемом SEQUEL) [6]. На рис. 7.5 показан пример запроса на языке SQL, выполняющего операции селекции и проекции. В
нашем случае из отношения «телефонный справочник» осуществляется выборка (селекция) всех записей, у которых атрибут Фамилия
принимает значение «Иванов». В результирующее отношение проецируются только столбцы Номер и Адрес.
Если исходное отношение достаточно велико, выполнение операции селекции потребует значительных затрат машинного времени.
Для ускорения мы можем попытаться организовать параллельное выполнение запроса на нескольких процессорных узлах многопроцессорной системы. Однако реляционная модель наилучшим образом
подходит для «распараллеливания» запросов. В самой общей форме
этот процесс можно описать следующим образом (рис. 7.5).
Каждое отношение делится на фрагменты, которые располагаются на различных дисковых устройствах. Запрос применяется не
110
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
к отношению в целом, а к данным фрагментам. Каждый фрагмент
обрабатывается на отдельном процессоре. Результаты, полученные
на различных процессорах, затем объединяются (сливаются) в общее
результирующее отношение, как это схематично показано на рис. 7.6.
Таким образом, разбивая отношение на n фрагментов в параллельной
машине баз данных с n процессорными узлами, мы уменьшаем время
выполнения запроса в n раз.
SELECT Номер, Адрес /*Атрибуты выборки*/
FROM Телефонная_книга /*Исходное отношение*/
WHERE Фамилия="Иванов"; /*Условие выборки*/
Результат _ выборки
Телефонная_книга
Фамилия Номер Адрес
Иванов
345678 Цветной бульвар,23-45
Иванов
415678 Радонежская,24
Петров
452345 Большой проспект,2-23
...
...
...
Номер Адрес
345678 Цветной бульвар,23-45
415678 Радонежская,24
Рис. 7.5. Пример запроса на языке SQL, выбирающего
из отношения Телефонная_книга номера телефонов
и адреса всех абонентов с фамилией Иванов
Рис. 7.6. Параллельное выполнение запроса
111
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Исходное отношение разбивается на фрагменты по первым двум
цифрам телефонного номера. Каждый фрагмент имеет свой собственный диск для хранения и процессор для обработки. Результирующее отношение объединяет данные, поставляемые отдельными узлами системы.
Однако не все так просто, как может показаться сначала. Первая
проблема, с которой мы столкнемся, – по какому критерию производить деление отношения на фрагменты? В нашем примере (рис. 7.6)
мы применили так называемое упорядоченное разделение, использующее первые две цифры телефонного номера в качестве критерия
распределения кортежей по дискам. Но подобный способ разбиения
отнюдь не идеален, так как в результате мы, вероятно, получим фрагменты, существенно различающиеся между собой по размерам, а
это может привести к сильным перекосам в загрузке процессоров.
При неудачной разбивке отношения на фрагменты на один из процессоров может выпасть более 50 % от общего объема нагрузки, что
снизит производительность нашей многопроцессорной системы до
уровня системы с одним процессором.
Известно несколько методов разбиения отношения на фрагменты
в параллельной машине баз данных [7], однако ни один из них не
может обеспечить сбалансированной загрузки процессоров во всех
случаях. Следовательно, чтобы «распараллеливание» запросов в параллельной машине стало эффективным, мы должны иметь некоторый механизм, позволяющий выполнять перераспределение (балансировку) нагрузки между процессорами динамически, т. е. непосредственно во время выполнения запроса.
Другая серьезная проблема, связанная с использованием параллельных машин баз данных, возникает из-за ограниченной масштабируемости. В многопроцессорной системе процессоры делят между
собой некоторые аппаратные ресурсы: память, диски и соединительную сеть, связывающую отдельные процессоры между собой. Добавление каждого нового процессора приводит к замедлению работы
других, использующих те же ресурсы. При большом числе участников может возникнуть ситуация, когда они будут дольше ждать того
или иного общего ресурса, чем работать. В этом случае говорят об
ограниченной масштабируемости системы.
Само число процессоров и дисков влечет за собой и третью серьезную проблему, с которой мы столкнемся при создании параллель112
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ных машин, – проблему обеспечения отказоустойчивости системы.
Действительно, вероятность выхода из строя магнитного диска в однопроцессорной системе не очень велика. Когда наша параллельная
система включает в себя несколько тысяч процессоров и дисков, вероятность отказа возрастает в тысячи раз. Это рассуждение применимо к любой массовой аппаратной компоненте, входящей в состав
многопроцессорной системы. Поэтому для параллельных машин баз
данных проблема отказоустойчивости становится особенно важной.
Четвертая проблема связана с обеспечением высокой готовности
данных: система должна восстанавливать потерянные данные таким
образом, чтобы это было «не очень» заметно для пользователя, выполняющего запросы к базе данных. Если в процессе восстановления 80–
90 % ресурсов системы тратится исключительно на цели восстановления базы данных, то такая система может оказаться неприемлемой для
случаев, когда ответ на запрос должен быть получен немедленно.
Как мы увидим в дальнейшем, подходы к решению указанных
проблем в определяющей степени зависят от аппаратной архитектуры параллельной машины баз данных.
В 1986 г. М. Стоунбрейкер [8] предложил разбить архитектуры
параллельных машин баз данных на три класса: архитектуры с разделяемой памятью и дисками, архитектуры с разделяемыми дисками
и архитектуры без совместного использования ресурсов (рис. 7.7).
Рис. 7.7. Три классические архитектуры: SE-архитектура
с разделяемой памятью и дисками, SD-архитектура с разделяемыми
дисками, SN-архитектура без совместного использования ресурсов
В SE-системах все процессоры P с помощью общей шины подключаются к разделяемой памяти M и дискам D. Процессоры передают
друг другу данные через общую память. В SD-системах каждый про113
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
цессор имеет свою собственную память, однако диски по-прежнему
разделяются всеми процессорами. Для связи процессоров друг с другом используется высокоскоростная соединительная сеть N. В SN-системах каждый процессор имеет собственную память и собственный
диск. Обмен данными между процессорами, как и в предыдущем случае, происходит через высокоскоростную соединительную сеть.
В системах с разделяемой памятью и дисками все процессоры
при помощи общей шины соединяются с разделяемой памятью и
дисками. Обозначим такую архитектуру как SE (Shared-Everything).
В SE-системах межпроцессорные коммуникации могут быть реализованы очень эффективно через разделяемую память. Поскольку здесь
каждому процессору доступны вся память и любой диск, проблема
балансировки загрузки процессоров не вызывает принципиальных
трудностей (простаивающий процессор можно легко переключить с
одного диска на другой). В силу этого SE-системы демонстрируют
для небольших конфигураций (не превышающих 20 процессоров)
более высокую производительность по сравнению с остальными архитектурами.
Однако SE-архитектура имеет ряд недостатков, самые неприятные из которых – ограниченная масштабируемость и низкая аппаратная отказоустойчивость. При большом количестве процессоров
здесь начинаются конфликты доступа к разделяемой памяти, что
может привести к серьезной деградации общей производительности
системы (поэтому масштабируемость реальных SE-систем ограничивается 20–30 процессорами). Не могут обеспечить такие системы и высокую готовность данных при отказах аппаратуры. Выход
из строя практически любой аппаратной компоненты фатален для
всей системы. Действительно, отказ модуля памяти, шины доступа
к памяти или шины ввода-вывода выводит из строя систему в целом. Что касается дисков, то обеспечение высокой готовности данных требует дублирования одних и тех же данных на разных дисках.
Однако поддержание идентичности всех копий может существенным
образом снизить общую производительность SE-системы в силу ограниченной пропускной способности шины ввода-вывода. Все это
исключает использование SE-архитектуры в чистом виде для систем
с высокими требованиями к готовности данных.
В системах с разделяемыми дисками каждый процессор имеет
свою собственную память. Процессоры соединяются друг с другом
114
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
и с дисковыми подсистемами высокоскоростной соединительной сетью. При этом любой процессор имеет доступ к любому диску. Обозначим такую архитектуру как SD (Shared-Disk). SD-архитектура по
сравнению с SE-архитектурой демонстрирует лучшую масштабируемость и более высокую степень отказоустойчивости. Однако при реализации SD-систем возникает ряд серьезных технических проблем,
которые не имеют эффективного решения. По мнению большинства
специалистов, сегодня нет весомых причин для поддержки SD-архитектуры в чистом виде.
В системах без совместного использования ресурсов каждый процессор имеет собственную память и собственный диск. Процессоры
соединяются друг с другом при помощи высокоскоростной соединительной сети. Обозначим такую архитектуру SN (Shared-Nothing).
SN-архитектура имеет наилучшие показатели по масштабируемости
и отказоустойчивости. Но ничто не дается даром: основным ее недостатком становится сложность с обеспечением сбалансированной
загрузки процессоров. Действительно, в SN-системе невозможно непосредственно переключить простаивающий процессор на обработку данных, хранящихся на «чужом» диске. Чтобы разгрузить некоторый процессорный узел, нам необходимо часть «необработанных»
данных переместить по соединительной сети на другой, свободный
узел. На практике это приводит к существенному падению общей эффективности системы из-за высокой стоимости пересылки больших
объемов данных. Поэтому перекосы в распределении данных по процессорным узлам могут вызвать полную деградацию общей производительности SN-системы.
Иерархические архитектуры
Для преодоления недостатков, присущих SE- и SN-архитектурам,
А. Бхайд в 1988 г. предложил рассматривать иерархические (гибридные) архитектуры [9], в которых SE-кластеры объединяются в единую SN-систему, как это показано на рис. 7.8. SE-кластер представляет собой фактически самостоятельный мультипроцессор с разделяемой памятью и дисками. Между собой SE-кластеры соединяются
с помощью высокоскоростной соединительной сети N. Обозначим
такую архитектуру как CE (Clustered-Everything). Она обладает хорошей масштабируемостью, подобно SN-архитектуре, и позволяет
достигать приемлемого баланса загрузки, подобно SE-архитектуре.
115
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 7.8. CE-архитектура
Эта система объединяет несколько SE-кластеров с помощью высокоскоростной соединительной сети. Каждый отдельный кластер
фактически представляет собой самостоятельный мультипроцессор
с SE-архитектурой.
Основные недостатки CE-архитектуры кроются в потенциальных
трудностях с обеспечением готовности данных при отказах аппаратуры на уровне SE-кластера. Для предотвращения потери данных из-за
отказов необходимо дублировать одни и те же данные на разных SEкластерах. Однако поддержка идентичности различных копий одних
и тех же данных требует пересылки по соединительной сети значительных объемов информации. А это может существенным образом
снизить общую производительность системы в режиме нормального
функционирования и привести к тому, что SE-кластеры станут работать с производительностью, как у однопроцессорных конфигураций.
Чтобы избавиться от указанных недостатков, мы предложили [10]
альтернативную трехуровневую иерархическую архитектуру (рис. 7.8),
в основе которой лежит понятие SD2-кластера. Такой кластер состоит
из несимметричных двухпроцессорных модулей PM с разделяемой памятью и набора дисков, объединенных по схеме SD. Обозначим данную
архитектуру как CD2 (Clustered-Disk with 2-processor modules).
Система строится как набор SD2-кластеров, объединенных высокоскоростной соединительной сетью в стиле «без совместного использования ресурсов». Каждый кластер – это система с разделяемыми дисками и двухпроцессорными модулями.
116
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 7.8. CD2-архитектура
Структура процессорного модуля изображена на рис. 7.9. Процессорный модуль имеет архитектуру с разделяемой памятью и включает в себя вычислительный и коммуникационный процессоры.
Рис. 7.9. Несимметричный двухпроцессорный модуль
с разделяемой памятью
Такую CD2-архитектуру мы использовали при реализации прототипа параллельной системы управления данными «Омега» для отечественных многопроцессорных комплексов МВС-100/1000. Как показа117
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ли эксперименты, CD2-система способна достичь общей производительности, сравнимой с производительностью CE-системы, даже при
наличии сильных перекосов в распределении данных по дискам. В то
же время CD2-архитектура позволяет обеспечить более высокую готовность данных, чем CE-архитектура. А добиться этого помогли новые алгоритмы размещения данных и балансировки загрузки.
Иерархическая архитектура системы «Омега» предполагает два
уровня фрагментации. Каждое отношение разделяется на фрагменты, размещаемые в различных SD2-кластерах (межкластерная
фрагментация). В свою очередь, каждый такой фрагмент дробится
на еще более мелкие части, распределяемые по различным узлам
SD2-кластера (внутрикластерная фрагментация). Данный подход
делает процесс балансировки загрузки более гибким, поскольку он
может выполняться на двух уровнях: локальном, среди процессорных модулей внутри SD2-кластера, и глобальном, среди самих SD2кластеров.
В системе «Омега» диски, принадлежащие одному кластеру, на
логическом уровне делятся на непересекающиеся подмножества
физических дисков, каждое из которых образует так называемый
виртуальный диск. Количество виртуальных дисков в SD2-кластере постоянно и совпадает с количеством процессорных модулей. В
простейшем случае одному виртуальному диску соответствует один
физический диск. Таким образом, на логическом уровне SD2-кластер
может рассматриваться как система с SN-архитектурой, в то время
как физически это система с SD-архитектурой.
В основе алгоритма балансировки загрузки лежит механизм репликации данных, названный внутрикластерным дублированием.
Его суть в том, что каждый фрагмент отношения дублируется на всех
виртуальных дисках кластера (далее для простоты мы будем опускать термин «виртуальный»).
Схема работы предлагаемого алгоритма балансировки загрузки иллюстрируется на примере кластера с двумя процессорами
(рис. 7.10). Здесь процессору P1 сопоставлен диск D1, а процессору P2
– диск D2. Предположим, что нам необходимо выполнить некоторую
операцию, аргументом которой является отношение R. Мы делим
фрагменты, на которые разбито отношение R внутри SD2-кластера,
на две примерно равные части. Первая часть назначается для обра118
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ботки процессору P1, вторая – процессору P2 (на рис. 7.10) данной
стадии соответствует момент времени t0).
На дисках D1 и D2 расположены две копии отношения R. Процессору P1 разрешен доступ к копии, хранящейся на диске D1, а процессору P2 – к копии на D2. В начальный момент времени t0 фрагменты
отношения R делятся между процессорами P1 и P2 примерно в равной
пропорции.
Рис.7.10. Алгоритм балансировки загрузки
для кластера с двумя процессорными узлами
В момент времени t1 процессор P1 закончил обработку своей части
отношения R, в то время как процессор P2 успел выполнить только
половину назначенной ему работы. В момент времени t2 происходит
перераспределение необработанной части отношения R между двумя процессорами. Перераспределение продолжается до тех пор, пока
отношение R не будет обработано полностью (момент времени t3).
В момент времени t1 процессор P1 закончил обработку своей части
отношения R, в то время как процессор P2 успел выполнить только
часть назначенной ему работы. В этом случае происходит повторное
перераспределение необработанной части отношения R между двумя
119
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
процессорами (момент времени t2 на рис. 7.10). Процесс продолжается до тех пор, пока отношение R не будет полностью обработано
(к моменту времени t3). Алгоритм очевидным образом обобщается на
произвольное число процессоров.
Предложенный алгоритм балансировки загрузки процессоров
позволяет избежать перемещения по соединительной сети больших
объемов данных. Это, в конечном счете, и обеспечивает такой системе производительность, сравнимую с производительностью SE-кластеров даже при наличии сильных перекосов данных.
Очевидно, что параллельные машины баз данных с одноуровневой архитектурой на сегодняшний день практически уже исчерпали
ресурс дальнейшего эффективного масштабирования. На смену им
приходят новые системы с иерархической архитектурой, которые могут включать в себя на два порядка больше процессоров и дисков.
Однако при построении иерархических систем по двухуровневому принципу, когда кластеры процессоров с разделяемой памятью и
дисками объединяются в единую систему без совместного использования ресурсов, возникает проблема обеспечения высокой готовности данных в случае отказов аппаратуры. Действительно, при большом количестве кластеров в системе вероятность отказа одного из
кластеров становится достаточно большой, и нам необходимо дублировать одни и те же данные на нескольких различных кластерах, что
сводит на нет все преимущества иерархической организации.
Поэтому следует ожидать, что дальнейшее развитие иерархических архитектур параллельных машин баз данных пойдет по пути
создания многоуровневых гибридных схем, способных обеспечить
высокую готовность данных на конфигурациях с несколькими сотнями тысяч процессорных узлов. В качестве прототипа таких систем предлагается параллельная система баз данных «Омега», разрабатываемая в Челябинском государственном университете, которая
имеет трехуровневую иерархическую архитектуру типа CD2 и может
включать в себя сотни SD2-кластеров. Но оптимальную архитектуру
SD2-кластера еще предстоит найти. Мы планируем испытать различные конфигурации SD2-кластеров, варьируя топологию межпроцессорных соединений, количество процессорных модулей, количество
дисковых подсистем и количество дисков у отдельной дисковой подсистемы.
120
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
7.3. Проблемы управления
распределенной информацией
Проблемы управления распределенной нформацией:
1.Нарушение семантической целостности. Несоответствие между представлениями и форматами данных, поступающих из разных
источников.
2.Произвольные выборки данных. Должны быть средства для запроса сведений о структуре БД и процессах консолидации.
3.Безопасность. В условиях распределенности и неоднородности
резко осложняется поддержка безопасности.
4.Масштабируемость по числу узлов. Алгоритмы, работающие
для небольшого числа узлов, не масштабируются на среду из тысячи
узлов.
5.Обработка транзакций. Локальные СУБД распределенной среды могут иметь различные модели транзакций.
6.Проектирование распределенных сред. Пока не формализованы методы разработки распределенных сред, а старые методы уже не
применимы.
7.Распределенная обработка запросов. Глобальная оптимизация
должна учитывать индивидуальные характеристики СУБД. При динамических изменениях необходимо заново производить оптимизацию.
7.4. Перспективные направления в управлении
распределенной информацией
Таким образом, архитектура клиент-сервер обладает рядом существенных преимуществ по сравнению с традиционной архитектурой
информационных систем, основанной на сетевых версиях настольных СУБД: более высокой производительностью, более низким сетевым трафиком, улучшенными средствами обеспечения безопасности
и целостности данных.
Мы рассмотрели последние достижения в области управления базами данных и информацией в архитектуре клиент-сервер, в частности стандартизованное программное обеспечение промежуточного
121
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
слоя. Если в будущем в типичной компании будет поддерживаться
среда, соответствующая принципу «любой клиент может соединиться с любым сервером», то ключом к такой взаимозаменяемости станут стандарты.
Существование нескольких стандартов не должно вызывать беспокойства по ряду причин. Прежде всего, вспомним, что корни обоих
стандартов – IDAPI и ODBC – лежат в стандарте SAG CLT. Следовательно, интероперабельность этих двух стандартов не составит проблемы. Соединения IDAPI – ODBC могут осуществляться посредством мини-шлюзов или путем использования клиентов и серверов с
двойной поддержкой возможностей промежуточного слоя на основе
обоих стандартов. Даже соединение между несовместимыми системами промежуточного слоя, например ODBC и DRDA, будет тривиальной задачей, решаемой, например, с помощью метапрограммного
обеспечения промежуточного слоя или благодаря клиентам и серверам, поддерживающим несколько стандартов.
Перспективы
краткосрочные
долгосрочные
- Широкое распространение
архитектур клиент-сервер в
приложениях БД
- Применение формирующихся
стандартов (DRDA, IDAPI, ODBC)
во вновь создаваемых и
существующих приложениях
клиент-сервер
- Развитие стандартов
- Появление новых стандартов
- Интеграция ПО
промежуточного слоя систем БД
клиент-сервер с ПО
промежуточного слоя,
предназначенным для других
видов сервисов.
Рис. 7.11. Перспективные направления
в управлении распределенной информацией
Независимо от того, в каких направлениях пойдет развитие архитектур клиент-сервер (см. рис. 7.11), эта технология окажет существенное влияние на все сферы, которые будут обсуждаться в последующих главах, – от хранилищ данных до систем мультибаз данных.
DRDA, ODBC, IDAPI и другие стандарты, которые могут появиться,
будут иметь огромное значение для управления распределенной информацией.
122
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Контрольные вопросы
1.Какие виды архитектур можно рассматривать в качестве моделей распределения информации?
2.Какие существуют проблемы управления распределенной
нформацией?
3.Какова альтернативная трехуровневая иерархическая архитектура на основе SD2-кластера?
4.Каковы особенности СЕ и CD2 архитектуры?
5.Какими преимуществами обладает архитектура клиент-сервер?
6.В чем состоит решение проблемы обработки сверхбольших баз
данных?
123
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ЗАКЛЮЧЕНИЕ
Учебное пособие содержит необходимые теоретические сведения
для изучения принципов разработки современных распределенных
баз данных и их реализации. Оно направлено на формирование профессиональных компетенций у студентов направления подготовки
«Инфокоммуникационные технологии и системы связи».
В пособии приведено подробное описание принципов управления
распределенной информацией, подробно описаны модели распределенных баз данных, принципы построения хранилищ данных, исследованы неоднородные федеративные базы данных и мультибазы,
а также определены перспективы управления распределенной информацией.
Таким образом, особое внимание в пособии уделено теоретическим основам разработки и управления распределенными базами
данных.
Пособие может использоваться для подготовки лекций по распределенным базам данных, проведения лабораторных занятий и выполнения курсовой работы.
124
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ЛИТЕРАТУРА И ИСТОЧНИКИ
Основная
1. Братченко Н. Ю. Базы данных. Основы работы с СУБД ORACLE:
учебное пособие (лабораторный практикум). – Ставрополь: Издательство
СевКавГТУ, 2011. 129 с.
2. Братченко Н. Ю. Базы данных: учебное пособие. – Ставрополь: СевКавГТУ, 2011. 195 с.
3. Методические указания по выполнению контрольной работы / авт.
сост. Н. Ю. Братченко. – Ставрополь: СКФУ, 2014. 24 с.
4. Ржеуцкая С. Ю. Язык SQL: учебное пособие. – Вологда: ВоГТУ, 2010.
Дополнительная
5. Архипенков С. Я., Голубев Д. В., Максименко О. Б. Хранилища данных: от концепции до внедрения. – М.: Диалог-МИФИ, 2012. 528 с.
6. Дейт К. Дж. Введение в системы баз данных; пер. с англ. – М.: Издательский дом «Вильямс», 2005. 1328 с.
7. Кузьмин А. В. Flash-память и другие современные носители информации. – М.: Горячая линия-Телеком, 2005.
8. Кузнецов С. Д. Основы баз данных: курс лекций: учебное пособие. –
М.: Интернет-ун-т информ. технологий, 2005. 488 с.
9. Саймон А. Р. Стратегические технологии баз данных: менеджмент на
2000 год. – М.: Финансы и статистика, 1999. 479 с.
10.Таненбаум Э. Компьютерные сети. 4-е изд. – СПб.: Питер, 2005. 992 с.
11. Чекалов А. П. Базы данных: от проектирования до разработки приложений. – СПб.: БХВ-Петербург, 2003. 380 с.
12.Фуфаев Э. В., Фуфаев Д. Э. Базы данных. – М.: Академия, 2007.
13.ГОСТ Р51141-98 «Делопроизводство и архивное дело. Термины и
определения». – М.: Госстандарт России, 1998.
14.Большая энциклопедия Кирилла и Мефодия на DVD. – Уральский
электронный завод, 2007. Лиц. ВАФ № 77-15.
125
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ГЛОССАРИЙ
Агрегирование данных – предобработка для представления в хранилище данных более высокого уровня гранулярности.
Виртуальное хранилище данных – это система, предоставляющая доступ к обычной регистрирующей системе, которая эмулирует работу с хранилищем данных.
Ключ к эффективности приложений хранилища данных – это агрегирование данных.
Медиатор – это программный модуль, предназначенный для упрощения,
абстрагрования, сокращения, слияния и объяснения данных, которыми обмениваются приложения и базы данных в некоторой среде.
Параллельные системы баз данных – это одна из наиболее многообещающих моделей фрагментации в аспекте достижения высокой производительности и пропускной способности.
Распределенная база данных – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети.
Распределенная СУБД – это программный комплекс, предназначенный
для управления распределенными базами данных и позволяющий сделать
распределенность информации прозрачной для конечного пользователя.
Репликаты – это множество различных физических копий некоторого
объекта базы данных (обычно таблицы), для которых в соответствии с определенными в базе данных правилами поддерживается синхронизация (идентичность) с некоторой «главной» копией.
Система управления распределенной базой данных – это программная система, которая обеспечивает управление распределенной базой данных и прозрачность ее распределенности для пользователей.
Тиражирование – это создание дублирующих копий (репликатов) объектов данных на разных узлах с целью повышения доступности и/или сокращения времени доступа к критически важным данным числительных
систем с массовым параллелизмом (Massively Parallel Processing, МРР).
Тиражирование (или репликация) – создание дубликатов данных.
Хранилища данных – это процесс сбора, отсеивания и предварительной обработки данных с целью представления результирующей информации пользователям для статистического анализа и аналитических отчетов.
Хранилище данных – это логически интегрированный источник данных для приложений систем поддержки принятия решений (DSS) и информационных систем руководителя (EIS).
Ядро системы управления распределенными информационными
ресурсами – это распределенная база данных (РаБД) и система управления
распределенной базой данных (РаСУБД).
126
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СПИСОК СОКРАЩЕНИЙ И АББРЕВИАТУР
РаБД – распределенные базы данных.
БД – базы данных.
БнД – банки данных.
РаСУБД – распределенные СУБД.
МФУ – многофункциональные устройства.
WORM (Write Once Read Many) – накопители, предназначенные для записи информации и её хранения.
CD-ROM (Compact Disk Read Only Memory) – накопители, предназначенные для чтения информации.
NASA – Национальное управление по аэронавтике и исследованию космического пространства США.
OLTP (Online Transaction Processing) – оперативная обработка транзакций.
ACID (Atomicity, Consistency, Isolation, Durability) – свойства атомарности, непротиворечивости, изолированности, долговременного сохранения.
LAN – локальные сети.
WAN – территориальные сети.
ИС – информационные системы.
127
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СОДЕРЖАНИЕ
Введение.................................................................................... 3
1. Принципы управления распределенной информацией...... 5
1.1. Определение и характеристики распределенных систем
баз данных ............................................................................. 5
1.2. Управление распределенной информацией: желаемый
сценарий ................................................................................ 9
2. Модели распределенных баз данных.................................... 13
2.1. Однородные и неоднородные системы 13
2.2. Методы построения распределенных баз данных «сверху
вниз» и «снизу вверх» ........................................................ 15
3. Технология клиент-сервер в базах данных и программное
обеспечение промежуточного слоя........................................ 21
3.1. Основные принципы и критерии оценки систем клиентсервер ................................................................................... 21
3.2. Стандарты архитектуры клиент-сервер в управлении
информации . ....................................................................... 29
3.3. Программное обеспечение промежуточного слоя . ........ 35
3.4. Интероперабельность баз данных . ................................... 39
4. Хранилища данных.................................................................. 42
4.1. Принципы построения хранилищ данных ....................... 42
4.2. Множественность носителей информации ...................... 50
4.3. Агрегирование данных . ..................................................... 59
4.4. Распределенные хранилища данных ................................ 61
4.5. Хранилища данных и другие технологии управления
информацией . ..................................................................... 67
4.6. Цифровые библиотеки и информационные магистрали .... 71
128
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5. Фрагментация и тиражирование........................................... 74
5.1. Концепции МРР и параллельных систем баз данных ..... 74
5.2. Модели фрагментации для параллельных систем
баз данных ........................................................................... 79
5.3. Параллельное выполнение реляционных операторов и индексные структуры 82
5.4. Перспективы развития параллельных систем баз данных 83
6. Неоднородные федеративные базы данных и мультибазы
данных......................................................................................... 89
6.1. Распределенные системы баз данных: таксономия ........ 89
6.2. Концептуализация архитектуры мультибаз данных ...... 95
6.4. Разрешение конфликтов ..................................................... 98
6.5. Медиаторы ......................................................................... 101
6.6. Интегральная целостность данных в системахмультибаз
данных ............................................................................... 103
7. Перспективы управления распределенной
информацией.......................................................................... 105
7.1. Модели распределения информации .............................. 105
7.3. Проблемы управления распределенной информацией ... 121
7.4. Перспективные направления в управлении
распределенной информацией ........................................ 121
Заключение................................................................................... 124
Литература и источники............................................................ 125
Глоссарий...................................................................................... 126
Список сокращений и аббревиатур......................................... 127
129
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Учебное издание
РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ
Учебное пособие
Автор-составитель
Братченко Наталья Юрьевна
Редактор, технический редактор К. В. Лавренюк
Компьютерная верстка Ю. Г. Ибрагимова
Формат 60х84 1/16
Бумага офсетная
Подписано в печать 12.03.15
Усл.печ.л. 7,55
Уч.-изд.л. 7,01
Тираж 30 экз.
Заказ 459
Отпечатано в Издательско-полиграфическом комплексе
Северо-Кавказского федерального университета
г. Ставрополь, пр-т Кулакова, 2
Документ
Категория
Без категории
Просмотров
440
Размер файла
2 460 Кб
Теги
данных, распределенный, базы
1/--страниц
Пожаловаться на содержимое документа