Гомологические модели электронных учебно-методических материалов Текст научной статьи по специальности «Компьютерные и информационные науки»

ГОМОЛОГИЧЕСКИЕ МОДЕЛИ ЭЛЕКТРОННЫХ УЧЕБНО-МЕТОДИЧЕСКИХ МАТЕРИАЛОВ

А.В. Аржаник, С.В. Воллосович, А.В. Лямин Введение

Большинство современных информационно-управляющих систем основываются на реляционной модели данных. Эта модель является самой проработанной и позволяет эффективно хранить и получать доступ к данным. В то же время занимает все более серьезные позиции формат extensible Markup Language (XML). Происходит это по нескольким причинам:

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

2 стандартизация структур данных при помощи файлов описания DTD (Document Type Definition), XSD (XML Schema Definition) позволяет устанавливать единые форматы обмена данными как внутри одной организации, так и региональные, национальные, международные;

3 стандарт данных позволяет осуществлять проверку структуры вводимых, передаваемых или получаемых данных.

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

Для стандартизации структуры XML-документа используются DTD и XSD-описания. При помощи DTD-определений возможно задание основных объектов предметной области (ELEMENT, естественное сопоставление с таблицей), их атрибутов (ATTLIST, естественное сопоставление с полями таблицы), а также вложенных объектов (естественное сопоставление со связанной таблицей с внешним ключом). Схема XSD, приближенная к самому языку XML, дает возможность более детально указывать типы данных атрибутов. Обе концепции позволяют задавать возможные количества вложенных объектов (один; нет, один или больше; нет или один). Таким образом, с точки зрения модели, данные XML представляют из себя дерево, и, следовательно, естественно поддерживаемыми типами отношений между объектами являются отношения «один-к-одному» и «один-ко-многим». Реализация отношения «многие-ко-многим» требует явного использования ссылочных атрибутов или задания определенных правил.

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

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

Обзор стандартных средств преобразования

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

Microsoft Access, начиная с версии Access XP, поддерживает импорт и экспорт индивидуальных таблиц в формате XML. При экспорте у пользователя есть следующие возможности (или любые их комбинации): экспорт данных (XML), экспорт схемы XML (XSD), экспорт представления (XSL, HTML). В случае экспорта формируемая схема основывается на указанных принципах соответствия и поддерживает типы данных для возможности последующего импорта в Access и SQL Server, а также содержит информацию об индексах и первичных ключах. Запрет одновременного экспорта нескольких таблиц исключает возможность записи в XML-формате реляционных связей между таблицами (внешних ключей).

КОД

Имя

Отчество

фамилия

телефон

дата рождения

доход на чел Б сенье

характеристика

км

ученик_код кпасс_код

Код

номер параллель -'г г изучение

Jjxj

Связанная таблица/запрос:

Ученик_ЩЦученик_класс_

Код ученик код

и

-

h

Обеспечение целое W каскадное обновле R каскадное удалени

ие связанных полей связанных записей

Тип отношения:

один-ко-многим

Реляционные связи в XSD-файлы не отображаются

Имя

Отчество

Фамилия

телефон

дата рождения

доход на чел е семье

характеристика

Код

ученик_код класс_код

Экспорт только данных

Экспорт структуры и данных

XML

Импорт только данных

XSD

Импорт структуры и данных Рис.1. Различные варианты XML-реляционного импорта-экспорта в MS Access XP+

Импорт в индивидуальную таблицу в MS Access XP+ может осуществляться из любого правильно построенного, но не обязательно основанного на схеме XML-документа. В случае наличия схемы, основанной на стандартных обозначениях, принятых при экспорте, происходит создание новой таблицы (при наличии одноименной к названию прибавляется

номер) с учетом индексов и типов данных. В случае отсутствия - новая таблица будет иметь

все поля с текстовым типом данных. Допускается также импорт только схемы данных с

созданием новой таблицы (рис. 1). Ниже приведен текст экспортируемого XML-документа:

<?xml version="1.0" encoding="UTF-8"?>

<dataroot xmlns:od="urn:schemas-microsoft-com :officedata"

xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="Ученик.xsd">

<Ученик>

<Код>1</Код>

<Имя>Иван</Имя>

<Отчество>Иванович</Отчество>

<Фамилия>Иванов</Фамилия>

<телефон>1234567</телефон>

<дата_рождения>31.01.1990</дата_рождения>

<доход_на_чел_в_семье>2500</доход_на_чел_в_семье>

<характеристика>Старательный ученик, получает 5-рки, поведение

отлично</характеристика>

</Ученик>

<Ученик>

<Код>2</Код>

<Имя>Екатерина</Имя>

<Отчество>Ивановна</Отчество>

<Фамилия>Сидорова</Фамилия>

<телефон>4236812</телефон>

<дата_рождения>27.03.1990</дата_рождения>

<доход_на_чел_в_семье>7500</доход_на_чел_в_семье>

<характеристика>Хулиганка страшная, перечит педагогам, хамит и

мешает</характеристика></Ученик>

</dataroot>

Текст XSD-схемы будет иметь вид: <?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" xmlns:od="urn:schemas-

microsoft-com:officedata">

<xsd:element name="dataroot">

<xsd:complexType>

<xsd:choice maxOccurs="unbounded">

<xsd:element ref="Ученик"/>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name="Ученик">

<xsd:annotation>

<xsd:appinfo>

<od:index index-name="PrimaryKey" index-key="Код " primary="yes" unique="yes"

clustered="no"/>

</xsd:appinfo>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name-'Код" od:jetType="autonumber" od:sqlSType="int" od:autoUnique="yes" od:nonNullable="yes">

<xsd:simpleType><xsd:restriction base="xsd:integer"/></xsd:simpleType> </xsd:element>

<xsd:element name="Имя" min0ccurs="0" od:jetType="text" od:sqlSType="nvarchar"> <xsd:simpleType>

<xsd:restriction base="xsd:string"><xsd:maxLength value="50"/></xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name=" Отчество" min0ccurs="0" od:jetType="text" od:sqlSType="nvarchar"> <xsd:simpleType>

<xsd:restriction base="xsd:string"><xsd:maxLength value="50"/></xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name=" Фамилия" min0ccurs="0" od:jetType="text" od:sqlSType="nvarchar">

<xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="50"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="телефон" min0ccurs="0" od:jetType="longinteger" od:sqlSType="int"> <xsd:simpleType><xsd:restriction base="xsd:integer"/></xsd:simpleType> </xsd:element>

<xsd:element name="дата_x0020_рождения" min0ccurs="0" od:jetType="text"

od:sqlSType="nvarchar">

<xsd:simpleType>

<xsd:restriction base="xsd:string"><xsd:maxLength value="50"/></xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="доход_x0020_на_x0020_чел_x0020_в_x0020_семье" min0ccurs="0" od:jetType="currency" od:sqlSType="money" type="xsd:double"/>

<xsd:element name="характеристика" min0ccurs="0" od:jetType="memo" od:sqlSType="ntext">

<xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength

value="536870910"/></xsd:restriction></xsd:simpleType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Клиент-серверная СУБД 0racle имеет несколько возможностей для работы c XML-содержимым. Эти возможности делятся на два типа: поддержка непосредственного хранения XML в базе данных (в той или иной форме) и программное манипулирование данными -запросы на выборку, генерирующие XML, обновление и вставку XML-содержимого, разбор XML-документов.

Как и любые другие данные, XML в 0racle можно хранить в полях CL0B. Этот способ предполагает основной вид доступа к XML-документу как к единому целому (выборка целиком и вставка целиком). В 9-й версии 0racle появился новый тип данных поля -XMLType, специально ориентированный на XML. Есть возможность создания XMLType-

таблиц и отдельных полей. При создании поля есть две возможности: хранение в структурированном виде (для каждого элемента и атрибута по определенному алгоритму создаются скрытые поля, обязательно задавать XSD-схему XML) и хранение в неструктурированном виде (создается скрытое поле CLOB, для которого поле XMLType является ярлыком, здесь использование схемы XSD необязательно). Структурированный вид предполагает более быстрый, похожий на реляционный (но нетождественный), физический доступ к содержимому, облегченное обновление и поиск данных. При структурированном хранении используются те же типы индексирования, что и при доступе к реляционным данным. Логически возможности доступа расширяются - использование в SQL операторов existNode, extract и т.д. Однако этому способу свойственен ряд ограничений, связанных с преобразованием XSD-сложных типов (complexTypes) и простейших типов данных. При неструктурированном хранении возможно использование индексирования Oracle Text. Однако производительность обоих способов меньше, чем производительность при непосредственном реляционном доступе. Кроме того, технология не является до конца проработанной: версия 9.2.0.1 XML Repository подвергалась значительной переработке с точки зрения ошибок до версии 9.2.0.2.

XML-ориентированные программные возможности включают XDK (XML Developer's Kit) для языков PL/SQL, Java, C++. В состав инструментария входят процессоры XML-схемы, языка XSLT (eXtensible Stylesheet Language Transformation), XML-парсер, а также утилита XSU (XML SQL Utility), позволяющая генерировать XML на основе реляционных запросов с возможностью одновременного формирования DTD-определе-ния или XSD-схемы. Появившаяся в 8-й версии XDK развивается по ходу выпуска новых. Использование XSU позволяет получать результаты запросов, а также производить вставку XML в виде, подобном приведенному на рис. 2.

Рис. 2. XML-реляционный импорт в Oracle 9i

Встроенные в известные СУБД возможности делятся на два типа: программные возможности SQL-выборки в виде XML, а также вставки XML в реляционные (объектно-реляционные) структуры и возможности непосредственного хранения XML-содержимого в БД. Первые, как правило, устанавливают непосредственные соответствия тегов и полей одной таблицы. Вторые обладают пониженной производительностью и пока не оптимизированы и недостаточно отлажены. Кроме того, в случае неструктурированного хранения данных XML-содержимое будет значительно увеличивать объемы БД, использование же технологий сжатия XML (например, Oracle XML Compression) еще более замедлит работу системы.

Оригинальная система правил отображения ХМЬ-документов на структуру базы данных

Альтернативой использованию встроенных средств ХМЬ-преобразований является написание специализированных программных утилит преобразования. Такие утилиты являются более гибкими и могут реализовывать практически любые алгоритмы (правила)

№ Описание правила

1 Обход дерева XML-документа ведется сверху вниз, текущей таблицей становится первый встреченный элемент, совпавший по названию с именем таблицы.

2 Элемент, название которого совпадает с таблицей, содержащий данные в формате PCDATA, интерпретируется как поле DATA в таблице, название которой совпадает с названием элемента.

3 Элемент, название которого не совпадает с таблицей, содержащий данные в формате PCDATA, интерпретируется как поле в текущей таблице (имя поля есть имя элемента).

4 Элемент, имя которого совпадает с названием таблицы, имеющий атрибут IsKey, равный "Yes", заносится только в том случае, если в этой таблице не существует такой записи. Если такая запись имеется, транслятор генерирует сообщение об ошибке. Сообщение об ошибке генерируется и в том случае, когда атрибут IsKey установлен в "No" и записи, соответствующей данному элементу, в таблице нет.

5 Элемент, имя которого совпадает с названием таблицы и для которого не задан атрибут IsKey, заносится в таблицу. Если запись уже существует, происходит обновление связей. Иначе в таблицу заносится новая запись.

6 Все атрибуты - это поля в текущей таблице.

7 Если атрибут какого-либо элемента совпадает с названием таблицы, то из таблицы TABLE_INDEX с полями TABLE_NAME, RETURN_COLUMN, INDEX_COLUMN выбирается запись, поле TABLE NAME которой совпадает со значением атрибута. Затем из таблицы с названием атрибута выбирается значение поля, название которого хранится в поле RETURN_COLUMN записи, которая удовлетворяет условию INDEX COLUMN=значенuе атрибута.

8 Атрибут с названием SRC заносится в поле SRC текущей таблицы, а файл, на который указывает атрибут, погружается в виде бинарных данных в поле CNT текущей таблицы.

9 Элементу с названием ATTACH автоматически добавляется атрибут CRC32 со значением подсчитанной контрольной суммы по алгоритму CRC32. Этот атрибут заносится в таблицу ATTACH. Подсчет контрольной суммы внедрен для соблюдения уникальности и устранения дублирования данных.

10 Если поле с названием атрибута отсутствует в текущей таблице, то необходимо перейти вверх по иерархии XML-документа и осуществить поиск таблицы с нужным полем. Поиск начинается с таблицы, название которой образовано из имен дочернего и родительского элементов, разделенных символом " ".

11 Если существует таблица с названием, образованным из имен дочернего и родительского элементов, разделенных символом " ", то осуществляется связь "многие-ко-многим".

12 Если таблицы связи нет, происходит попытка использовать связь "многие-к-одному", т.е. заносится значение поля ID из таблицы с названием родительского элемента в таблицу с названием дочернего элемента. В таблице с названием дочернего элемента должно быть поле с названием родительского элемента.

13 Если не удалось установить связь "многие-к-одному", заносится значение поля ID из таблицы с названием дочернего элемента в таблицу с названием родительского

элемента. В таблице с названием родительского элемента должно быть поле с названием дочернего элемента.

14 Для элемента, у которого не указано никаких атрибутов, но название совпадает с названием таблицы, в БД будет занесено только значение поля ID. Для таких элементов всегда должны существовать вложенные элемент DATA или текстовые данные PCDATA, вложенные в текущий элемент.

Таблица 1. Правила XML-relational преобразования

При разработке новой системы дистанционного обучения СПбГУ ИТМО в качестве хранилища материалов учебно-методического комплекса использовалась СУБД Oracle 8i, а в качестве инструмента обмена информацией с авторами УМК по различным дисциплинам был использован XML. В качестве стандарта содержимого УМК, предназначенного для погрузки в БД, было принято несколько типов XML-файлов, предназначенных для различных составляющих (электронные конспекты, практикумы, тестовые задания, виртуальные лаборатории). Для каждого типа было написано DTD-определение. Каждый файл является логически законченным объектом, удобным для заполнения. С другой стороны, структура БД отражает технические особенности системы (нормализация, оптимизация при помощи индексов и т.д.) и ориентирована на динамичную обработку и гибкую выдачу содержимого клиентским процессам. Для поддержки преобразования в БД разработана служебная таблица, содержащая информацию о подстановке внешних ключей из таблиц-справочников. Для погрузки материалов разработана система правил, представленная в табл. 1. Следование данным правилам приводит к отображению тегов в сущности базы данных, а вложенностей тегов - в реляционные связи.

Пример описания элемента УМК

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

create table TEXTBOOKPAGE create table TEXTBOOKUNIT

( ID NUMBER(8) not null, ( ID NUMBER(8) not null,

PAGEINDEX NUMBER(8) not null, TEXTBOOK NUMBER(8) not null,

NAME VARCHAR2(255) not null, PART NUMBER (3) not null,

TEXTBOOKUNIT NUMBER(8) not null, NAME VARCHAR2 (255) not null,

LEVEL NUMBER (8) not null, TEXTBOOKUNIT NUMBER(8)

SRC VARCHAR2 (255) not null, );

CNT CLOB not null, create table PAGEINDEX

COMMENT VARCHAR2(4000), (

ENCODING NUMBER(8) not null, ID NUMBER(8) not null,

LANGUAGE NUMBER (8) not null PAGEID NUMBER(10) not null,

); PAGETYPE NUMBER(2) not null,

SCHEME NUMBER(8) not null );

Рис. 3. DDL SQL-составляющая XML-модели

В процессе практической работы возникают две ситуации.

1 Автор предоставил полный конспект по одному курсу. Логичным представляется ввод данных, когда тегом верхнего уровня является TextBookUnit, т.е. сначала составляется содержание конспекта, а затем его реализация. В процессе погрузки связывание сущностей происходит на этапе обработки элемента TextBookPage (двукратное применение правила 13).

2 В распоряжении имеется некоторое количество страниц из различных курсов. Здесь ввод данных естественно начать со схемы, продолжить описанием страницы, а затем уже отнести ее к определенному конспекту. В процессе погрузки связывание сущностей происходит на этапе обработки элементов TextBookPage и TextBookUnit (применение соответственно правил 14 и 13).

В табл. 2 приведена DTD-составляющая реляционной модели для первого и второго случаев соответственно. На рис. 3 приведена неизменная DDL (Data Definition Language) SQL

(Structured Query Language)-составляющая XML-модели.

Первый случай Второй случай

<!ELEMENT Pagelndex (TextBookPage)> <!ATTLIST Pagelndex Scheme CD ATA #REQUIRED PageType CDATA #FIXED "TextBook" PagelD CDATA #REQUIRED IsKey CDATA #FIXED "Yes" > <!ELEMENT TextBookUnit (PageIndex+)> <!ATTLIST TextBookUnit Name CDATA #REQUIRED Part CDATA #REQUIRED > <!ELEMENT TextBookPage (KeyWord*, Attach*, Comment?)> <!ATTLIST TextBookPage Name CDATA #REQUIRED Level CDATA #REQUIRED Src CDATA #REQUIRED Language CDATA "ru" Encoding CDATA "Cp1251" > <!ELEMENT PageIndex (TextBookPage)> <!ATTLIST PageIndex Scheme CDATA #REQUIRED PageType CDATA #FIXED "TextBook" PageID CDATA #REQUIRED IsKey CDATA #FIXED "Yes" > <!ELEMENT TextBookPage (TextBookUnit, KeyWord*, Attach*, Comment?)> <!ATTLIST TextBookPage Name CDATA #REQUIRED Level CDATA #REQUIRED Src CDATA #REQUIRED Language CDATA "ru" Encoding CDATA "Cp1251" > <!ELEMENT TextBookUnit (EMPTY)> <!ATTLIST TextBookUnit Name CDATA #REQUIRED Part CDATA #REQUIRED >

Таблица 2. DTD-составляющая реляционной модели

Заключение

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