В начало

Лекция. Развитие БД

 

ПЛАН

·        XML-СЕРВЕРЫ         

·        ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ БД

·        РАСПРЕДЕЛЕННЫЕ БД

·        КОММЕРЧЕСКИЕ БД

·        ИНФОРМАЦИОННЫЕ ХРАНИЛИЩА

 

XML-серверы

Расширяемый язык разметки (eXtensible Markup Language - XML) - это язык описания документов, во многом похожий на язык разметки гипертекста (HyperText Markup Language - HTML), повсеместно используемый для конструирования Web-страниц.

HTML - это язык, используемый для создания Web-страниц и основанный на предопределенном наборе "тегов", показывающих читающему текст программному обеспечению ("браузеру"), как представлять содержимое страницы. В наиболее простом толковании можно представлять XML как развитый вариант HTML. В действительности это не так: XML и HTML являются подмножествами стандартного обобщенного языка разметки (Standard Generalized Markup Language - SGML), который, по причине своей сложности не получил широкого распространения.

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

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

В работе HTML используется Определение Типа Документа – Document Type Definition, или DTD. DTD может определяться внутри документа, при этом оставаясь доступным (в том числе и для ссылок) извне. XML-процессор использует DTD для определения корректности документа.

С XML-документом связаны три уровня корректности:

-          Правильно построенный XML-документ - это такой, в котором элементы правильно структурированы в виде дерева с корректно расставленными открывающими и закрывающими тегами.

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

-          Синтаксически корректный XML-документ находится вне контроля XML. Разработчик такого документа отвечает за его логическую структуризацию.

Однако язык не содержит механизм для реальной выборки данных из базы данных и их отображения. При желании создать Web-страницы, содержащие данные из базы данных требуется написать или купить программное обеспечение для выборки этих данных и создания страниц (Java и SQL).

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

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

2.        Использовать обобщенное программное обеспечение, читающее DTD и соответствующим образом реагирующее на теги. В этом случае точность интерпретации будет ограничена тем, что можно получить из DTD.

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

Первые два подхода будут основываться на программном обеспечении, написанном на Java или аналогичном языке. Третий подход уже применяется. Например, химики создали на основе XML Химический язык разметки (Chemical Markup Language.)

Использование XML для описания данных

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

Имеются два подхода к описанию структуры базы данных на XML:

-          Во-первых, прикладную базу данных может описывать DTD XML-документа. В этом случае операционные данные базы данных могут быть размещены между наборами описанных тегов. Такое DTD может, например, генерироваться одним CASE-средством, а читаться другим, обеспечивая способ передачи структуры данных.

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

Реализация XML сервера

На выставке CеBIT '99 корпорация Software AG представила новый информационный сервер на основе языка расширяемой разметки XML. Сервер, получивший кодовое название Tamino.

 

Объектно-ориентированные БД

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

В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:

-          объекта и идентификатора объекта;

-          атрибутов и методов;

-          классов;

-          иерархии и наследования классов.

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

Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие между объектами производится на основе передачи сообщений и выполнении соответствующих методов.

Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.

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

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

Для разработки ООБД используются следующие ОО языки программирования: Smalltalk; Лисп (проекта ORION), TDL, Си++, CO2 и др.

В качестве ОО СУБД можно отметить следующие: O2 (французский консорциум Altair), ORION (американская компания MCC), GemStone (американская фирма Servio Logic) и Iris (Hewlett-Packard).

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

 

Распределенные БД

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

Синхронизация доступа к данным

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

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

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

Управление транзакциями

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

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

Поддержание копий данных в нескольких узлах сети

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

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

Фрагментация объектов БД

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

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

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

Алгоритмы выполнения реляционных операций

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

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

 

Коммерческие БД

Основные отличия, присущие коммерческим БД:

·      Это в основном сетевые БД;

·      Обладают высокой производительностью;

·      Обладают персонализированным доступом.

Архитектура "клиент-сервер" и параллельность обработки.

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

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

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

Системы БД с многоуровневой защитой

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

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

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

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

 

Информационные хранилища

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

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

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

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

Логическая архитектура базы данных

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

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

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

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

Физическая архитектура базы данных

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

Индексные структуры

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

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

Материализованные представления

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

-        определение представлений, которые следует материализовывать;

-        использование материализованных представлений для ответа на запросы;

-        обновление материализованных представлений при загрузке новых данных.

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

Концептуальная модель данных

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

В многомерном представлении данных запросы drill-down и roll-up – это логические операции на кубе. Еще одна популярная операция – сравнить два параметра, которые агрегированы по одним и тем же измерениям.

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

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