Системы обработки распределенных баз данных (РаБД)

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

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

Ответом на задачи реальной жизни стали две технологии: технология распределенных баз данных (Distributed Database) и технология тиражирования данных (Data Replication).

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

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

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

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

Глобальный словарь данных — это механизм отслеживания расположения объектов в распределенной БД. Данные могут храниться на локальном узле, на удаленном узле, или на обоих узлах — их расположение должно оставаться прозрачным как для конечного пользователя, так и для программ. Не нужно явным образом указывать место расположения данных — программа должна быть полностью независима от того, на каких узлах размещаются данные, с которыми она оперирует;

ü Оптимизация распределенных запросов – эта проблема требует интеллектуального решения. Распределенный запрос затрагивает несколько баз данных на различных узлах, причем объемы выборки могут быть весьма различными. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера. Поэтому оптимизатор распределенных запросов обязательно должен учитывать размеры таблиц. В противном случае запрос будет выполняться непредсказуемо долго.

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

ü Управление распределенными транзакциями. Решение всех задач распределенной обработки возложено на специальный компонент СУБД — сервер распределенных баз данных (Distributed Database Server).

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

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

Для СУБД это качество означает следующее:

· способность приложений, созданных средствами разработки данной СУБД, оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных (использованием шлюзов);

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

Вскоре после появления идея (и теория) реляционных баз данных стала популярна среди разработчиков СУБД. Однако сделать реляционную СУБД оказалось непросто. Сложилась неоднозначная ситуация, когда после некоторых усовершенствований одни фирмы стали называть свои разработки реляционными (иногда просто добавляя '/R' к имени своей СУБД), а другие - отказываться от создания реляционных СУБД в силу сложности задачи. Для того, чтобы внести ясность в оценку разработок одних фирм и более определенно сформулировать цель, к которой разработчикам нужно стремиться, для других (или тех же самых) фирм, Е. Кодд, автор реляционного подхода, в конце 70-х гг. опубликовал свои 12 правил соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики. Ниже приводятся эти правила.

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

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

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

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

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

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

· определение данных,

· определение правил целостности,

· манипулирование данными (в диалоге и из программы),

· определение выводимых таблиц (в том числе возможности их модификации),

· определение правил авторизации,

· границы транзакций.

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

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

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

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

10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

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

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

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

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

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

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

Рассмотрим пример такой системы.

Глобальная база данных распределена по трем узлам. Узел A — это компьютер

VAX 6000/560 с ОС VMS и СУБД Rdb, где расположена локальная БД Предприятия в формате Rdb. Второй узел (B) представляет собой компьютер SUN Sparc Server 1000 под управлением операционной системы Solaris. На нем функционирует СУБД Ingres и находится локальная БД Склад в формате Ingres. В качестве узла C выступает mainframe IBM с операционной системой MVS и СУБД DB2. На нем расположена локальная БД Инструмент в формате DB2.

Сервер распределенной БД — компонент СУБД Ingres — выполняется на узле B. Коммуникационные серверы Ingres работают на всех трех узлах. Узлы A и B используют для взаимодействия протокол TCP/IP, в то время как узлы B и C общаются в соответствии со стандартом SNA.

Локальные БД на всех трех узлах управляются автономно. Распределенная БД Производство содержит таблицы из всех трех локальных БД. Для доступа сервера распределенной БД к БД Предприятия необходим шлюз из Ingres в Rdb, а для доступа к БД Инструмент — шлюз из Ingres в DB2.

Шлюз из Ingres в DB2 позволяет манипулировать данными в формате DB2 так, как будто они — данные в формате Ingres. Шлюз из Ingres в Rdb позволяет оперировать с данными в формате Rdb так, как будто они — данные в формате Ingres.

Все эти детали не видны конечному пользователю. Он работает с БД Производство так, как будто это централизованная БД Ingres. Это и есть полностью прозрачный доступ к данным.

Хранилища данных

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

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

Предметная ориентированность ХД означает, что данные должны представлять предметы (объекты), а не процессы (выписка счета, продажа товара). Неизменяемость указывает на то, что данные не обновляются, а пополняются за счет баз данных. Хронологическая поддержка указывает на обязательную привязку данных ко времени, так как они накапливаются на протяжении длительного периода (10—15 лет).

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

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

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

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

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

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

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

Концепция ХД относится к одному из перспективных направлений развития систем формирования решений. Хранилище данных может создаваться в следующих целях:

· интеграция текущих и исторических значений данных;

· объединение данных из разрозненных источников;

· создание надежной платформы данных для аналитических целей;

· обеспечение однородности данных в организации;

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

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

В настоящий момент внедрение Хранилищ данных и связанных с ними технологий находится в процессе невиданного за последние несколько лет ускоренного развития и изменения. Недавние результаты, представленные аналитиками компании IDC, показывают, что рынок ХД составляет сегодня около 10 млрд. долларов, а в ближайшие годы может возрасти до 13,5 млрд. Казалось бы, идея ХД, «с нуля» выросшая во всемирный многомиллиардный рынок, уже изживает себя. Однако осуществленные за последние годы новые разработки говорят о том, что в этой области грядет возрождение. Крупные корпорации по всему миру получают существенные преимущества за счет технологии Хранилищ, которая потенциально может принести еще больше пользы.

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

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

Устройства для Хранилищ данных можно определить как:

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

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

Большинство подобных устройств поддерживают так называемые "крупные витрины данных", где витрина является частью аналитического приложения, обычно предназначенного для анализа какой-то отдельной области: деталей заказов, потребителей, корзин заказов и т.д. Это одна из наиболее распространенных на сегодня областей использования устройств для Хранилищ данных.

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

Объем данных, находящихся под управлением одной крупной витрины, обычно составляет от 1 до 10 терабайт, причем это данные, доступные для запросов. Их объем будет увеличиваться по мере того, как пользователи станут работать с большим количеством данных, а поставщики начнут создавать более емкие модели. Обычно пользователи устройств для Хранилищ данных начинают с объема 1-3 терабайта и доводят его до 10 терабайт за несколько лет.

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

Контрольные вопросы

1. Исторический аспект методов обработки данных.

2. Принципы передачи данных в сети.

3. Сущность удаленной обработки данных.

4. Для чего используются виртуальные имена узлов сети.

5. Обработка запросов в архитектуре "файл/сервер".

6. Обработка запросов в архитектуре "клиент/сервер".

7. Достоинства и недостатки архитектур файл/сервер и клиент/сервер.

8. Понятие «распределенная база данных

9. Способы распределения базы данных.

10. Достоинства и недостатки распределенной обработки данных.

11. Различия гомогенных и гетерогенных РаБД.

12. Наиболее известные распределенные СУБД

13. Двенадцать правил К. Дейта.

14. Понятие «хранилище данных».

15. Причины появления хранилищ данных.

16. Суть технологии OLAP.

Литература

1. Экономическая информатика / Под.ред. П.В.Конюховского, Д.Н.Колесова. – Мн.: Новое знание. 2001. - с. 302-306.

2. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: учеб. пособие. – 2-е изд., испр. и доп. – М.: ФОРУМ:ИНФРА-М, 2007. – С. 272-280, 337-340.

3. Кузин А.В., Демин В.М. Разработка баз данных в системе Microsoft Access: учебник. – 2-е изд. – М.: ФОРУМ-ИНФРА-М, 2007.- С. 182-186.

4. Романов А.Н., Одинцов Е.Е. Информационные системы в экономике (лекции, упражнения и задачи): Учеб. пособие. – М.: Вузовский учебник, 2007. – С. 99-100., 107-111.

5. Многопользовательская система обработки видеоинформации, конструкторской документации, допечатной подготовки на базе технологии SAN // Режим доступа: http://www.kvazar-micro.com/sub/it/ru/solutions/1/1/200512021725-3986.htm

6. Хранилища данных // Режим доступа: http://www.kvazar-micro.com/sub/it/ru/solutions/1/1/