|
||||||||||||||||
| <Добавить в Избранное> <Сделать стартовой> <Реклама на сайте> <Контакты> | ||||||||||||||||
|
||||||||||||||||
| ||||||||||||||||
|
| ||||||||||||||||
Интернет технологии -> XML -> XML и технологии БАЗ ДАННЫХ | ||||||||||||||||
|
Веселов В.В. Долженков
А.Н. В статье рассматривается язык XML как способ логического представления информации в XML-ориентированных базах данных. Рассматривается их связь с реляционными БД, объектными БД и концепцией корпоративных хранилищ. -------------------------------------------------------------------------------- О возникновении XML как языка Перевод с реляционного языка на язык XML и наоборот. XML как модель данных XML-ориентированные БД Данные и метаданные в XML-ориентированных БД XML-ориентированные и объектно-ориентированные БД XML-ориентированные БД как КХД -------------------------------------------------------------------------------- XML - это самостоятельная технология, хотя и возникшая исторически как Internet-технология. Представляется важным рассмотреть технологию XML в отрыве от Internet и в связи с технологиями баз данных: реляционной, объектной и концепцией корпоративных хранилищ. Как связан язык XML с реляционным, почему на его основе может и должна быть построена модель данных, что собой представляет XML-ориентированная база данных, существуют ли таковые на сегодняшний день - этим вопросам посвящена настоящая статья. О возникновении XML как языка На исторические причины возникновения XML можно посмотреть с двух различных, но связанных между собой точек зрения (рис.1): Две точки зрения на XML:   Рис.1 Первая состоит в том, что семантическая ограниченность языка разметки гипертекста HTML не позволяла разработчику Web-приложений описывать специфичную информацию, например, химические или математические формулы. Возникла практическая потребность в других языках разметки, структурно аналогичных HTML, но с другой семантикой. В результате стараний Интернет-консорциума W3C был создан метаязык XML, на основе которого заинтересованные разработчики создали и создают специфичные дочерние языки разметки - CML, MathML и уже десятки других. С учетом небольшой синтаксической доработки, HTML также является дочерним языком XML. Вторая точка зрения состоит в следующем. Информация, заключенная в любом документе, в том числе и в Web-странице, является в большей или меньшей степени регулярной. Ранние варианты HTML слабо учитывали эту регулярность, что приводило к громоздкости сообщений на этом языке и не вполне удовлетворяло разработчиков Web-приложений. Первым делом, стараниями W3C-консорциума, разработчикам была предоставлена возможность вычленить из HTML-документа описание внешнего вида отдельных, регулярно повторяющихся его фрагментов в самостоятельный объект таблицу стилей CSS. Далее была вычленена в самостоятельный объект собственно разметка таблица стилей XSL, которую, возможно, следовало бы более точно назвать таблицей шаблонов разметки. В итоге остался XML-документ, описывающий в чистом виде структуру данных документа. Таким образом, структурированные данные документа были отделены от способа их логико-графического представления (разметки) в виде списков, параграфов, таблиц, диаграмм и т.п., а логико-графическое представление от конкретного внешнего вида (стиля) размеров, цветов, начертаний и т.п. В общем виде XML-документ имеет структуру произвольного дерева, которая описывается набором вложенных друг в друга тегов, каждый из которых имеет следующий синтаксический вид: <ИмяУзла ИмяАтр1=значение ИмяАтр2=значение ... > вложенные теги и тексты </ИмяУзла> Разница этих двух точек зрения на XML состоит в том, что ставить во главу угла разметку или данные. В первом случае имена тегов и их атрибутов являются указателями на конкретный шаблон разметки и стандартизуются в словарях-спецификациях XML для каждого конкретного языка разметки. Во втором случае имена тегов XML - это указатели регулярных данных самого XML- документа. Нас интересует второй вариант, и под XML-документом мы будем понимать структуру данных документа, выраженную языком XML. Перевод с реляционного языка на язык XML и наоборот Реляционный язык это язык кортежей (неупорядоченных множеств пар ИмяРеквизита-ЗначениеРеквизита) и отношений (неупорядоченных множеств кортежей, имеющих одинаковый набор имен реквизитов). Внешним представлением сообщений на реляционном языке является набор двухмерных таблиц. Конкретное приложение, работающее с РБД, делает разметку отношений, кортежей и значений в таблицы, строки (записи) и клетки (поля) и придает им некоторый внешний вид, обычно по опциональному выбору пользователя. Внешним представлением сообщений на языке XML является набор реальных документов (и электронных, и бумажных), визуализация которых происходит при помощи универсального броузера (например, IE5) на основании XSL и CSS. Перевод сообщений с реляционного языка на XML синтаксически не однозначен. Для иллюстрации рассмотрим простой пример, состоящий из 3 отношений, 5 реквизитов и 5 кортежей (рис.2). 
Рис.2 В простейшем и наиболее компактном варианте получается следующая конструкция (вариант1): <DataBase> <Tab1 A=a1 C=c1/> <Tab2 B=b1 D=d1/> <Tab2 B=b2 D=d2/> <Tab3 A=a1 B=b1 E=e1/> <Tab3 A=a1 B=b2 E=e2/></DataBase> Ее недостатком является неоднородность представления кортежей и значений, что, например, осложняет отображение расширенных реляционных моделей. Если значения оформлять также в виде тегов, то получим следующее (вариант2): <DataBase> <Tab1><A>a1</A><C>c1</C></Tab1> <Tab2><B>b1</B><D>d1</D></Tab2> <Tab2><B>b2</B><D>d2</D></Tab2> <Tab3><A>a1</A><B>b1</B><E>e1</E></Tab3> <Tab3><A>a1</A><B>b2</B><E>e2</E></Tab3></DataBase> Оба варианта используют двухуровневую вложенность XML-узлов, с помощью которой устанавливаются направленные связи кортеж-значение. Направленные связи от записей Tab1 к записям Tab3 и от записей Tab2 к записям Tab3 (Tab3 обычно называют таблицей-связкой для реализации связей типа "многие-ко-многим") указываются одинаковыми значениями ключевых реквизитов A и B. В языке XML связи обычно указываются явно путем вложения тегов друг в друга и путем применения ссылок. Это позволяет в нашем примере убрать ссылочные ключи в Tab3 и установить ссылки на одного родителя путем вложения тега Tab3 в Tab2 и на второго родителя (Tab1) с помощью атрибутов Id и Ref (вариант3): <DataBase> <Tab1 Id=#1> <A>a1</A> <C>c1</C></Tab1> <Tab2> <B>b1</B> <D>d1</D> <Tab3 Ref1=#1> <E>e1</E></Tab3></Tab2> <Tab2> <B>b2</B> <D>d2</D> <Tab3 Ref1=#1> <E>e2</E></Tab3></Tab2></DataBase> Для того чтобы выполнить обратную операцию привести произвольные XML-данные к реляционным в первую очередь их необходимо преобразовать к одному из описанных выше вариантов. Для примера возьмем вариант3. 1. Для каждого тега (в общем виде) вынесем все атрибуты, кроме Id и Ref, и все фрагменты текста в отдельные вложенные теги. Получится следующая структура: <ИмяУзла Id=Указатель Ref1=Указатель Ref2=Указатель...> <ИмяАтр1> Значение </ИмяАтр1> <ИмяАтр2> Значение </ИмяАтр2>... <ИмяТекста1> Только текст </ИмяТекста1> <ИмяТекста2> Только текст </ИмяТекста2>... Только вложенные теги </ИмяУзла> 2. Реляционные данные хранятся в неупорядоченном виде, а данные XML в упорядоченном. Если в порядке следования атрибутов, фрагментов текста и вложенных тегов заложен смысл, то его, возможно, следует сохранить путем добавления к этой структуре специального вложенного тега, содержащего эту информацию. 3. Узлы предпоследнего уровня иерархии, которым соответствуют кортежи, не могут содержать одноименные вложенные теги - эта ситуация должна быть преобразована. Грубо говоря, в реляционной таблице клетка не может быть разделена на части. Кроме того, если она и может быть пустой, то уж никак не может отсутствовать. Поэтому, необходимо учесть разницу между отсутствующим и пустым тегом последнего уровня. 4. Узлы последнего уровня иерархии, которым соответствуют значения реквизитов, не могут содержать ссылочных атрибутов Id и Ref, так как в реляционных данных связи по ключам существуют только на уровне кортежей. Преобразование варианта3 в вариант2 происходит путем включения ключевых тегов, в качестве которых, в общем случае, удобно использовать суррогатные ключи. Как видно из рассмотренного примера, если данные размещать как текст и "размечать" их именами тегов, а атрибуты использовать только для ссылок, то получается весьма однородная структура, синтаксически несколько более широкая, чем реляционная. XML как модель данных На основе языка XML может быть построена модель данных. В настоящий момент строгой модели данных нет, но она, вероятно, может быть построена на основе реляционной. Зачем она нужна? По очень простой и веской причине - естественности. Причем естественности во всех аспектах - логическом представлении данных, манипулирования ими и поддержки их целостности. Представление данных как XML-документов является естественным, поскольку они получаются из реальных документов. Представлять данные как документы привычнее и понятнее, чем представлять их как реляционные таблицы. Реляционная таблица, в лучшем случае, отдельный фрагмент документа. Неестественность табличного представления легко прочувствовать вначале при проектировании РБД, когда из набора имеющихся документов происходит вычленение сущностей, и затем при подготовке отчета, когда из этих же сущностей вновь создаются документы. Манипулировать данными с использованием такой естественной для человека (но логически избыточной!) сущности как "связь" также привычнее и понятнее, чем со ссылочными ключами, которые в реальных документах встречаются редко. В настоящий момент существует набор стандартных операций низкого уровня для работы с XML-документами - удалить или перенести узел с поддеревом, создать документ или узел, выделить коллекцию узлов по такому-то признаку и т. п. Строгая модель данных предполагает создания на основе низкоуровневых логических операций ограниченного набора логически корректных операций верхнего уровня, позволяющих пользователю манипулировать данными без использования программирования, то есть "от кнопки", на уровне пользовательского интерфейса. В любом случае, создавая набор операций манипулирования верхнего уровня в рамках XML'ной модели данных, следует отталкиваться от необходимости отразить в этом наборе именно те операции, которые совершаются в реальной жизни, причем, прежде всего, не с электронными, а с бумажными документами. Естественность первична, а математическая логика хоть и обязательна, но вторична. С исторической точки зрения, реляционная модель данных - это очередная провалившаяся попытка навязать людям нечто очень "правильное", но искусственное, типа эсперанто. Этот набор операций будет совсем другим, чем в реляционной модели. Проиллюстрируем это на нижеследующих примерах. Манипулирование документами в реальной жизни называется документооборотом. Если мы хотим сделать БД полноправным участником документооборота (иначе говоря, общаться с ней на естественном языке), то она должна манипулировать документами как участник документооборота. А действует он, образно говоря, так: "Когда поступит документ 1, возьми документ 2, просуммируй значения в таких-то полях и запиши результат в такое-то поле документа 3 и т.д.". Манипулирование документами это всегда порождение нового документа, виртуального (аналог временных отношений в РБД) или записываемого в БД. Отдельный документ или его фрагмент может возникать как результат отработки события документооборота и сам являться событием, порождающим новые документы или их фрагменты. Модель данных XML любит "вредную избыточность" данных, неприемлемую для РБД. "Иванов" в документе 1 и "Иванов" в документе 2, хотя речь и идет об одном и том же человеке, не одно и тоже документы 1 и 2 возникли в разные моменты времени и, соответственно, в разных контекстах. В процессе документооборота часто данные многократно переносятся по цепочке от одного документа к другому, что вполне естественно и должно адекватно отражаться в модели данных. Вопрос о минимизации количества хранимой информации и оптимизации скорости доступа к ней - это вопрос физического хранения, а не логической модели. Поддержка целостности данных при удалении узла XML-дерева сводится к удалению поддерева этого узла и всех поддеревьев в других документах, на узлы которых этот узел ссылается. Естественно, совокупность иерархических и горизонтальных направленных связей не должна образовывать циклических графов. Операция довольно дорогая, но редко применяемая - только в случае внесения заведомо ошибочных данных. Если документ был составлен правильно, то он прекращает свое действие вовсе не с помощью операции "удаление", а на основании некоторого другого документа, его отменяющего. "Удаленный" документ не исчезает бесследно историческая целостность документов поддерживается в архивах в течение определенного срока. XML-ориентированные БД XML-ориентированной называется база данных, которая в качестве модели данных использует XMLную модель данных. Следует отличать XML-ориентированные БД (Рис.3) от реляционных БД, поддерживающих обмен данными на языке XML (Рис.4) в основе вторых лежит реляционная модель. XML-ориентированные БД: Tamino,Cache.  Рис.3РБД, поддерживающие обмен данными на XML: Oracle, MS SQL-Server и др. 
Рис.4Авторам этой статьи на текущий момент времени известно две XML-ориентированные БД Tamino (Software AG) и Cache (InterSystems), причем со второй из них авторы непосредственно работают. Столь быстрое появление этих баз как XML-ориентированных обусловлено тем, что еще задолго до появления XML они использовали в качестве физического представления данных верхнего уровня структуры, аналогичные структурам XML-документов ненормализованные деревья (с горизонтальными связями). Несколько упрощая, можно сказать, что для этих баз XML-доступ к данным это прямой доступ к данным. Естественно, что и методы манипулирования ненормализованными деревьями в основном совпадают с низкоуровневыми логическими операциями над XML-документами. Что касается высокоуровневых методов, то их скорее следует считать не строгими, а прагматическими. Разумеется, и Тамино, и Каше поддерживают реляционный и объектный доступ к данным, работу на различных платформах и т. п. и т. д. Из рекламных заявлений разработчиков хочется обратить внимание на два момента, имеющих отношение к нашей теме. XML-БД обеспечивают существенно более высокую скорость выполнения транзакций, в том числе через интернет, что обусловлено, с одной стороны, меньшими затратами на преобразования данных и, с другой стороны, известным своей эффективностью способом управления памятью как B-деревом. XML-БД характеризуются высокой скоростью разработки приложений, что обусловлено унификацией данных, методов их обработки и, конечно же, естественностью их представления. Данные и метаданные в XML-ориентированных БД XML-документы, имеющие одинаковые уникальные имена тегов и порядок их вложенности друг в друга, и не зависимо от количества вложенных одноименных тегов, относятся к одному классу документов и являются его экземплярами. Внутри класса экземпляры документов и их узлы различаются по уникальному идентификатору ID. Говоря языком документооборота, класс это описание бланка документа (где и какие поля, как называются, какими чернилами заполнять, на основании чего именно, кому и когда передать документ после заполнения и т.п.), а экземпляр один заполненный бланк. Класс описывается одним или несколькими XML-метадокументами, которые являются экземплярами соответствующих метаклассов. Сам метакласс имеет описание в виде таких же XML-метадокументов, являющихся тоже экземплярами этих же метаклассов. Таким образом, XML БД является описанной на самой себе, что удобно по ряду причин, в частности, позволяет использовать одно и то же ПО как для работы с данными, так и для работы с метаданными. Классы разделяются на две большие группы: Исходные XML-документы, элементы которых "прошиты" взаимными связями (Id и Ref). Связи могут указывать как на узлы этого же документа, так и на узлы другого документа, находящегося как в этой же БД, так и какой-либо другой, расположенной на удаленном сервере. Если ставится задача полной поддержки исторической целостности, то кроме указателей связей в атрибуты тегов элементов записывается системная дата последнего изменения этого элемента. Аналитические XML-документы, полученные из исходных XML-документов путем заполнения содержимого тегов (текста) значениями, получаемыми либо путем прямого перенесения, либо путем аналитической обработки значений из других XML-документов. Возникает ли подобный документ в момент его запроса (виртуальный документ) или рассчитывается заранее (хранимый документ), определяется практической целесообразностью. Для описания классов используются экземпляры следующих метаклассов (не обязательно по одному): Schema - описывает структурные свойства XML-элементов для исходных XML-документов перечень имен дочерних элементов, обязательность и возможность множественности данного элемента и т. п., а также тип данных содержимого элемента и принадлежность домену. Осуществляет проверку поступившего на сервер или, чаще, заполняемого на клиенте документа. XSLT-документы описывают преобразования исходных XML-документов в аналитические XML-документы. XSL-документы с таблицами CSS и набором скриптов Behaviors - определяют, соответственно, разметку и стиль оформления документов, а также поведение элементов для электронных документов. Кроме описанных выше классов и метаклассов XML-ориентированные БД включают в себя: Набор сценариев для работы различных групп пользователей. У сервера, как у полноправного участника документооборота, также есть свой сценарий. Сценарий связывает события, порождаемые пользователем или порождаемые "внутри" XML БД (триггеры), с соответствующими метадокументами (Schema, XSLT, XSL) и операциями манипулирования, совершаемыми на клиенте или на сервере. По сути, сценарий - это данные, описывающие логику работы приложения, препарированного на составные части с целью унификации. Библиотеку готовых XSL-шаблонов, CSS-стилей, скриптов Behaviors для упрощения проектирования документов, возможности изменения на пользователе логико-геометрического представления и внешнего вида документа, а также для подготовки XSL-документов по умолчанию. Например, вид и поведение полей для ввода во входной форме могут быть определены по умолчанию на основании типа данных, записанного в "Schema". XML-ориентированные и объектно-ориентированные БД XML-документ является информационным объектом и экземпляром одного из классов, содержащихся в XML-ориентированной БД. XML-документы являются информационными объектами, и их классы собственных методов не имеют. Работа с XML-документом происходит с помощью методов объекта анализатора (например, ActiveX Microsoft.XMLDOM), в который его загружают вместе с информационными объектами-описателями (Schema, XSL, CSS, набор скриптов). Структура XML-документов унифицирована, и персональные методы для отдельного класса создавать смысла не имеет, поскольку сразу возникает естественное желание иметь возможность применить этот метод и к другим классам. Вместо инкапсуляции метод размещают либо в библиотеке, либо в анализаторе и параметризуют его данными, находящимися в информационных объектах-описателях. Заметим, что система управления XML-ориентированная БД такой же анализатор, только более мощный. Если основным признаком О-ориентированной БД считать инкапсуляцию методов обработки информационных объектов в сами же эти объекты, то XML-ориентированные БД развиваются в прямо противоположном направлении: объекты разъединяются на свои логические составляющие части, эти части представляются в открытом формате, классифицируются, унифицируются и размещаются по библиотекам с возможностью доступа к ним через Internet. Судя по темпам развития, XML-технологии О-ориентированные БД так и не успеют достигнуть того расцвета, который в свое время прошли РБД. XML-ориентированные БД как КХД XML-технология как нельзя лучше отвечает концепции КХД (корпоративных хранилищ данных), которую мы и рассмотрим с точки зрения XML-ориентированных БД. 1. Прежде всего, КХД это совокупность нескольких, связанных между собой БД. XML это Internet-технология, имеющая в этом аспекте следующие позитивные моменты. Во-первых, XML открытый формат описания данных, непосредственно понятный пользователю без броузера или анализатора. Во-вторых, XML мировой стандарт для структуризации сложной информации, ее передачи как между сервером и клиентом, так и между сервером и сервером, как в локальной, так и глобальной сетях. В-третьих, XML предоставляет возможность создания глобальных децентрализованных БД с индивидуальным набором исходных и аналитических документов, хранимых на соединенных в общую сеть серверах. В-четвертых, конвертируемость XML-документов в реляционное представление и обратно позволяет подсоединить к XML-ориентированным КХД реляционные БД. 2.КХД поддерживает историческую целостность данных. В КХД попадает исчерпывающий набор исходных данных из различных источников, который хранится в своем первоначальном состоянии и не удаляется. Для исходных данных допускается некоторое нарушение целостности и непротиворечивости. В XML-ориентированных БД разборка класса XML-документов и установление связей с другими классами может быть отложена на неопределенное время. Документы записываются в своем первоначальном состоянии, фиксируются системные даты - поступления документа, установление связей между элементами различных документов, прекращения действия документа. 3.Помимо исходных данных, КХД содержит интегрированную аналитическую информацию, необходимую для принятия решений. Интеграция предусматривает объединение данных с приведением их к единому синтаксическому и семантическому виду и устранению нарушений целостности и противоречивости. В XML-ориентированных БД разобранный документ это такой же аналитический XML-документ, как и ответ на запрос, собственно аналитический расчет, выходная или входная формы. 4.Логическая структура аналитических данных в КХД отражает точку зрения корпоративного пользователя, которая различна для разных групп пользователей, и изменяется во времени. Аналитические документы в XML-ориентированной БД как раз и отражают конкретную точку зрения как на конкретный документ, так и на их динамическое взаимодействие друг с другом на определенном временном интервале. 5.КХД должно обладать высокой скоростью обработки запросов пользователей, вследствие чего допускается высокая избыточность аналитических данных, отражающая промежуточные результаты статистически часто встречающихся запросов пользователей. Скорость обработки запросов это, в первую очередь, вопрос физического хранения и физического манипулирования данными, не имеющий отношения к XML как способу логического представления. На уровне логического XML-представления данных скорость обработки запроса зависит от того, являются ли результирующий или промежуточные XML-документы виртуальными или реально хранимыми. В XML-ориентированных КХД предполагается высокая доля реально хранимых аналитических документов. Источники: 1.Александр Печерский. Язык XML - практичкское введение. Часть 1 и 2. 2.Геннадий Верников. Технологическая эволюция корпоративных информационных систем. 3.Software AG представляет "Tamino" 4.Питте Н. XML за рекордное время. Пер. с англ. -М.:Мир,2000.- 444с. 5.Павел Храмцов. XML через призму программирования. - журнал "Открытые Системы", #09-10/1999 6.Стив Штайнк. Управление сетями и системами с помощью XML. - Lan/Журнал сетевых решений. |
| ||||||||||||||||
| ||||||||||||||||
| Copyright © CompDoc.Ru | ||||||||||||||||
| При цитировании и перепечатке ссылка на www.compdoc.ru обязательна. Карта сайта. |