Элементы и Атрибуты: Моделирование Реляционных Данных Средствами XML. Часть 1

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

 

Но перед тем, как перейти к обсуждению того, как же мы должны моделировать наши связанные данные на XML, нам нужно понять одну из классических проблем моделирования данных на XML: что нам следует использовать в качестве модели самих данных (в технической литературе их еще называют "точками данных" - Data Points ) - элементы или атрибуты?

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

Таблица 1.

<customer>
     <name>Fred Q. Anybody</name>
  <address>123 Somewhere Street</address>
  <city>Randomtown</city>
  <state>WV</state>
  <zip>25423</zip>
</customer>

или вот такой моделью:

Таблица 2.

<customer
     name = "Fred Q. Anybody"
  address = "123 Somewhere Street"
  city = "Randomtown"
  state = "WV"
  zip = "25423" />

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


Сравнение Элементов, Атрибутов и Реляционной Модели

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

Значение Порядка

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

Таблица 3.

<customer>
     <name>Fred Q. Anybody</name>
  <address>123 Somewhere Street</address>
  <city>Randomtown</city>
  <state>WV</state>
  <zip>25423</zip>
</customer>

 

будет обработан (распаресен) не так, как вот этот документ:

Таблица 4.

<customer>
  <address>123 Somewhere Street</address>
  <city>Randomtown</city>
  <state>WV</state>
  <zip>25423</zip>
     <name>Fred Q. Anybody</name>
</customer>

 

Это может создать некоторые трудности при разборе, в зависимости от используемой вами библиотеки парсинга. Вам придется самостоятельно проверить все элементы-потомки родительского элемента для того, чтобы найти нужную информацию (например, имя покупателя - customer's name). Генерирование XML документов с подобной структурой также немного сложнее - элементы, содержащие "точки данных" должны быть представлены в итоговом документе в точно таком же порядке, что и в исходном (в противном случае он не будет соответствовать DTD или схеме).

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

Таблица 5.

<customer
     name = "Fred Q. Anybody"
  address = "123 Somewhere Street"
  state = "WV"
  city = "Randomtown"
  zip = "25423" />

 

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

Различия в Размере Документа

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

Таблица 1 содержит 144 символа. А таблица 2 - 107. Размер, конечно, будет сильно зависеть от длины имен, выбранных вами для обозначения "точек данных", но все же документ, который использует атрибуты вместо элементов для размещения данных, всегда будет меньше. Это ведет к снижению накладных расходов (и при хранении и при передаче), а так же уменьшает время парсинга.

Различия в Сложности Кода

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

  1. Перемещение к элементу, символизирующему таблицу.
  2. Перемещение к элементу, который содержит искомое значение.
  3. Перемещение к текстовому элементу внутри этого элемента.
  4. Вернуть значение этого текстового элемента.

Для сравнения, извлечение значения атрибута потребуется только два шага:

  1. Перемещение к элементу, символизирующему таблицу.
  2. Вернуть значение атрибута, который совпадает с искомым.

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

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

Представление Смешанного Содержимого

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

Таблица 6.

<para> Это пример <b>смешанного</b> содержимого.</para>

 

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

Совместимость с Существующими Системами

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


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


С оригинальным текстом статьи вы можете ознакомиться на www.developers.net

Отдавая должное автору, считаю нужным представить некоторую информацию о нем:

Kevin Williams основатель и Исполняющий Директор фирмы Blue Oxide Technologies. Его компания предоставляет программное обеспечение в области сервис-ориентированного Интернета. За более подробной информацией вы можете обратиться к веб-странице: www.blueoxide.com

С переводчиком можно связаться по e-mail: beststory@yandex.ru

Перевод сделан эксклюзивно для realcoding.net

Автор - Kevin Williams, перевод - kate aka cronOS



Опубликовал admin
28 Сен, Среда 2005г.



Программирование для чайников.