ЛЕКЦИИ

Лекция

Постреляционные модели данных.

Технологии интеграции распределенных данных на основе XML

 

14.1.Постреляционная модель данных

14.1.1. Ограничения реляционной модели данных. Не первая нормальная форма

Одним из наиболее важных принципов реляционной модели данных является нормализация. Однако использование первой нормальной формы (1НФ) накладывает ограничение атомарности на допустимые значения атрибутов (все используемые домены отношения должны содержать только скалярные значения). Это снижает выразительность реляционной модели данных при описании целого ряда предметных областей[1]. Наиболее часто такая проблема возникает, когда атрибут должен содержать множественные значения или требуется внутренняя структура данных атрибута.

Таким образом, в ряде случаев нормализованная реляционная модель предметной области несколько искусственна[2]. Кроме того, нормализация в таких случаях заставляет разрабатывать довольно сложные запросы для получения, казалось бы, простых данных.

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

Для преодоления такого рода недостатков реляционной модели данных была разработана постреляционная (post-relational) модель данных. Создание такой модели данных, допускающей не атомарность значений атрибутов кортежей потребовало разработки новых правил нормализации. Основой нормализации в постреляционной модели данных служит так называемая «не первая нормальная форма» – НФ2[3] (Non First Normal Form – NF2). Суть заключается в расширенной трактовке понятия «атрибут». В постреляционной модели атрибут может быть или атомарным (как в реляционной модели), или множественным. Множественный атрибут описывается вложенным отношением (множеством кортежей) со всеми вытекающими последствиями. Вообще говоря, атрибуты такого вложенного отношения также могут быть множественными. Это допущение не нарушает принципов реляционной алгебры.

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

14.1.2. Демонстрация постреляционной модели данных на примере задачи «Сессия»

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

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

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

В постреляционной модели данных также введен новый механизм, под названием «ассоциация». Смысл его сводится к созданию так называемых «множественных групп». Каждая множественная группа представляет собой совокупность из нескольких (двух и более) множественных атрибутов, значения которых в каждом кортеже связаны между собой порядком следования. То есть, первому значению первого множественного атрибута ставятся в соответствие первые значения всех остальных множественных атрибутов в такой множественной группе, второму значению атрибута группы – вторые значения остальных атрибутов группы и т.д.

Столбцы «Дисциплина» и «Семестр» в таблице «Преподаватель» связаны ассоциацией. Также связаны ассоциацией столбцы «Семестр» и «Преподаватель» в таблице «Дисциплина» и столбцы «Дисциплина», «Семестр», «Оценка» в таблице «Студент».

14.1.3. Обзор распространенных постреляционных СУБД

В настоящее время к числу распространенных постреляционных СУБД можно отнести:

–         UniVerse (Vmark Software);

–         Postgres (University of California at Berkeley – UCB);

–         Cache’ (Intersystems).

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

 

UniVerse

В данной СУБД используется расширение стандарта ANSI SQL. Для описания множественного атрибута используется ключевое слово MULTIVALUED, а для механизма ассоциации – ASSOC. Множественный атрибут трактуется как вложенная таблица с одним атрибутом.

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

CREATE TABLE Студент (

  ID INTEGER,

  Фамилия_И_О CHARACTER VARYING(50),

  Домашний_адрес CHARACTER VARYING(100),

  Телефон CHARACTER VARYING(20),

  Номер_группы CHARACTER VARYING(10),

  Дисциплина INTEGER MULTIVALUED,

  Семестр INTEGER MULTIVALUED,

  Оценка INTEGER MULTIVALUED,

  ASSOC Дисциплина (Семестр, Оценка),

  PRIMARY KEY (ID)

)

 

CREATE TABLE Преподаватель (

  ID INTEGER,

  Фамилия_И_О CHARACTER VARYING(50),

  Домашний_адрес CHARACTER VARYING(100),

  Телефон CHARACTER VARYING(20),

  Кафедра INTEGER,

  Должность CHARACTER VARYING(20),

  Дисциплина INTEGER MULTIVALUED,

  Семестр INTEGER MULTIVALUED,

  ASSOC Дисциплина (Семестр),

  PRIMARY KEY (ID)

)

 

CREATE TABLE Дисциплина (

  ID INTEGER,

  Наименование CHARACTER VARYING(50),

  Семестр INTEGER MULTIVALUED,

  Преподаватель INTEGER MULTIVALUED,

  ASSOC Семестр (Преподаватель),

  PRIMARY KEY (ID)

)

Postgres (слайд 5)

В данной СУБД используется вариант стандарта SQL-3 под названием PostgreSQL. Он реализует все основные команды языка SQL, а также позволяет использовать команды и типы данных языка программирования (например, Си). PostgreSQL позволяет создавать множественные атрибуты с внутренней структурой (например, вложенные таблицы с несколькими атрибутами). В настоящее время Postgres относят к классу объектно-реляционных СУБД. В ней реализовано наследование таблиц и некоторые другие объектно-ориентированные механизмы.

Множественные поля реализуются в виде массивов. Создание таблиц выглядит следующим образом:

CREATE TYPE TMarks AS (Дисциплина INTEGER, Семестр INTEGER, Оценка INTEGER)

 

CREATE TABLE Студент (

  ID INTEGER,

  Фамилия_И_О CHARACTER VARYING(50),

  Домашний_адрес CHARACTER VARYING(100),

  Телефон CHARACTER VARYING(20),

  Номер_группы CHARACTER VARYING(10),

  Оценки TMarks ARRAY[],

  PRIMARY KEY (ID)

)

 

CREATE TYPE TDiscip AS (Дисциплина INTEGER, Семестр INTEGER)

 

CREATE TABLE Преподаватель (

  ID INTEGER,

  Фамилия_И_О CHARACTER VARYING(50),

  Домашний_адрес CHARACTER VARYING(100),

  Телефон CHARACTER VARYING(20),

  Кафедра INTEGER,

  Должность CHARACTER VARYING(20),

  ДП TDiscip ARRAY[],

  PRIMARY KEY (ID)

)

 

CREATE TYPE TPrep AS (Преподаватель INTEGER, Семестр INTEGER)

 

CREATE TABLE Дисциплина (

  ID INTEGER,

  Наименование CHARACTER VARYING(50),

  Ведет TPrep ARRAY[],

  PRIMARY KEY (ID)

)

Множественные атрибуты хранятся в массивах переменной длины со сложным типом данных. Запрос для вывода только средствами SQL будет слишком сложным, и поэтому здесь не приводится. Для эффективного выполнения такого запроса необходимо воспользоваться расширенными возможностями PostgreSQL (написать специальную функцию на высокоуровневом языке программирования).

В Postgres реализован механизм наследования структуры таблиц. При этом  наследуются все атрибуты таблицы и добавляются новые атрибуты. Например, таблицы преподавателей и студентов можно объявить следующим образом:

CREATE TABLE Персона (

  ID INTEGER,

  Фамилия_И_О CHARACTER VARYING(50),

  Домашний_адрес CHARACTER VARYING(100),

  Телефон CHARACTER VARYING(20),

  PRIMARY KEY (ID)

)

 

CREATE TABLE Преподаватель (

  Кафедра INTEGER,

  Должность CHARACTER VARYING(20),

  ДП TDiscip ARRAY[]

) Персона

 

CREATE TABLE Студент (

  Номер_группы CHARACTER VARYING(10),

  Оценки TMarks ARRAY[]

) Персона

Это позволяет повысить выразительные способности SQL при описании структур данных, а также снизить затраты на их описание.

 

Cache’

Cache’ довольно условно можно отнести к постреляционным СУБД. В чистом виде в ней не реализована НФ2. «Постреляционность» Cache’ обусловлена возможностью связывания реляционной модели данных с объектно-ориентированной моделью штатными средствами СУБД. С одной стороны это не прямой способ реализации НФ2. Но с другой – предоставляет разработчикам более широкие возможности, присущие объектно-ориентированному подходу. Поэтому, Cache’ относят как к классу постреляционных, так и к классу объектно-ориентированных СУБД.

14.1.4. Достоинства и недостатки постреляционной модели данных (слайд 6)

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

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

Следует также отметить, что в настоящее время отсутствуют стандарты и средства автоматизации проектирования постреляционных баз данных. Создать наглядное графическое представление (диаграмму) постреляционной модели на концептуальном (инфологическом) уровне можно средствами, например, ER-диаграмм и соответствующих CASE-средств (например, ERWin Data Modeler). Так же наглядно изобразить ту же модель, но на уровне физическом (реализации) на сегодняшний день не так просто.

 

14.2. Объектно-ориентированная модель данных

14.2.1. Основы объектно-ориентированного подхода

В последнее время при разработке автоматизированных информационных систем широко применяется объектно-ориентированный (ОО) подход. В его основе лежит предположение о том, что человек видит окружающий мир как множество объектов. Поэтому такой подход должен быть наиболее близким разработчику, должен существенно упростить анализ и проектирование систем[4].

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

Базовыми механизмами ОО подхода являются (слайд 8):

1.    Инкапсуляция (encapsulation). Объединение атрибутов и методов доступа к ним в одном объекте. Пользователю (в широком смысле) предоставляется только спецификация объекта (описание класса), а его реализация скрывается. В идеале, доступ атрибутам объекта – только через его методы.

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

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

4.    Абстракция (abstraction). Спецификация методов класса на уровне вызова (без реализации). Используется для объявления отдельных методов, которые должны быть реализованы в дочерних классах, а также для создания интерфейсов (interface). Интерфейс это – спецификация взаимодействия между объектами (поименованный перечень методов, которые должны быть реализованы в объекте).

Существует три уровня ОО моделирования (слайд 9):

1)      уровень анализа;

2)      уровень проектирования;

3)      уровень реализации.

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

На первом уровне моделирования описывается предметная область (в терминах объектов). При этом допускается не описывать атрибуты и методы (или описывать только наиболее существенные). Допускаются так называемые «классы-ассоциации».

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

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

Наибольшее распространение получил язык ОО моделирования UML (Unified Modeling Language). Он позволяет описывать ОО модель с помощью диаграмм следующих видов (слайд 10):

–      вариантов использования (use-case);

–      классов (class);

–      объектов (object);

–      взаимодействия (interaction):

–      последовательности (sequence);

–      кооперативных (collaboration);

–      пакетов (package);

–      состояний (statechart);

–      деятельностей (activity);

–      размещения (deployment).

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

14.2.2. Объектно-ориентированный подход в сфере баз данных

ОО подход получил отражение и в сфере баз данных. Можно выделить три основных направления его реализации:

1)      «интерфейсный»;

2)      смешанный (объектно-реляционный);

3)      «чистый».

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

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

«Чистый» подход в корне меняет представление об ОО автоматизированной информационной системе. Ее не нужно делить на базу данных и программу. Система представляет собой некую среду, состоящую из объектов, обменивающихся сообщениями. Такой подход требует от разработчика смены концепции, что не просто. Однако уже предпринимаются попытки его реализации (например, в СУБД Cache’). В целом такой подход выходит за рамки курса «Базы данных» и поэтому здесь не рассматривается[5].

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

14.2.3. Пример структуры ОО базы данных

Ниже приведен пример ОО модели для задачи «Сессия». Для простоты модель описывается только диаграммой классов.

ОО модель для задачи «Сессия» на уровне анализа приведена на слайде 11. Основными классами являются: Преподаватель, Дисциплина, Студент. К связи Преподаватель – Дисциплина прикреплен класс-ассоциация «Читает», а к связи Дисциплина – Студент прикреплен класс-ассоциация «Оценка». Эти классы позволяют отразить семантику связей, а при необходимости описать атрибуты связей.

На уровне проектирования ОО модель для задачи «Сессия» приведена на слайде 12. Классы Преподаватель и Студент являются наследниками более общего родительского класса Персона, в котором описаны общие атрибуты (фамилия, имя, отчество и т.д.). Связь Преподаватель – Дисциплина реализована с помощью класса «Дисциплина в плане». Этот класс является наследником родительского класса «Дисциплина». Связь Студент – Дисциплина реализована с помощью класса «Запись сводной ведомости».

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

14.2.4. Обзор распространенных ОО СУБД (слайд 13)

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

Большинство производителей придерживаются первого направления. (ОО интерфейсы к реляционной базе данных). Такое направление избрала компания Microsoft, разработав для MS SQL Server компонент LINQ (Language-Integrated Query), позволяющий обращаться к записям базы данных как к объектам. Аналогично поступила компания MySQL AB (СУБД MySQL), разработав специальное средство Object-relational mapping tool.

Наиболее ярким представителем второго направления (объектно-реляционных СУБД) можно считать компанию Oracle (СУБД Oracle Database). Oracle Database позволяет объявлять классы (содержащие атрибуты и методы), которые затем могут использоваться либо как типы данных (при описании столбцов таблиц), либо в качестве описания структуры таблицы целиком (атрибуты класса трактуются как столбцы таблицы). В первом случае объектом является поле в записи, во втором случае – целая запись, причем сама таблица трактуется как класс. Эти два подхода являются взаимоисключающими.

Поддержка объектно-реляционного подхода реализована также в СУБД Progress. К этой же группе можно (условно) отнести и СУБД Postgres, реализующую принцип наследования при описании структуры базы данных. Среди не реляционных СУБД, поддерживающих ОО подход, можно выделить документальную СУБД Lotus Domino. Она реализует механизм инкапсуляции. Документ (основная структурная единица этой СУБД) можно рассматривать как объект, содержащий данные и методы. Реализован механизм сокрытия данных.

Наиболее яркой «чистой» ОО СУБД можно считать Cache’. Объектная модель данных в ней реализована на основе стандарта ODMG (Object Database Management Group – группа по объектному управлению базами данных). В СУБД реализованы все базовые механизмы ОО подхода (инкапсуляция, наследование, полиморфизм, абстракция).

14.2.5. Достоинства и недостатки объектно-ориентированной модели данных

К числу основных достоинств ОО модели данных можно отнести (слайд 14):

–      близость ОО концепции к восприятию мира, свойственному человеку (как следствие – более естественные процессы анализа и проектирования);

–      потенциально большее быстродействие (за счет использования ассоциативных связей);

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

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

Среди основных недостатков ОО модели данных можно выделить:

–      громоздкость описания ОО модели существующими языками (например, UML);

–      сложность перехода (смены парадигмы) к ОО модели от простой и распространенной реляционной модели данных;

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

 

14.3. Технологии интеграции распределенных данных на основе XML

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

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

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

 

Слабоструктурированными называются данные, обладающие определенной структурой, но эта структура может оказаться непостоянной или определенной не полностью. Коллекции таких документов иногда называют «не имеющими схемы», (schema-less) или самоопределенными (self-describing). Характерной особенностью слабоструктурированных данных является то, что описательная информация, которая обычно выделяется в отдельную схему, в той или иной форме присутствует в самих наборах данных. В некоторых формах представления слабоструктурированных данных не предусмотрено применение отдельной схемы, а в других она существует, но налагает на представленные в ней данные очень слабые ограничения.

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

Схема слабоструктурированных данных может быть как предписывающей, так и описывающей.

Примером предписывающей схемы слабоструктурированных данных является Document Type Definition (DTD) или XML-схемы, которые описывают структуру XML-документов, а XML-процессоры используют это описание при разборе. Если разбираемый документ не соответствует DTD, процессор прекращает его разбор и сигнализирует об ошибке. Таким образом, предписывающая схема накладывает ограничения на структуру данных.

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

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

 

14.3.1. Технологии XML (слайд 15)

XML изначально является средством обмена данными: XML-документ – это просто поток текста, который может принимать и передавать приложе­ние. XML практически не за­висит от платформы, операционной системы, языка программирования и т. д. Во-вторых, XML – это стандарт, утвержденный World Wide Web Consortium (W3C), и поэтому ана­лизаторы для чтения XML-документов имеются по­чти для всех основных платформ, включая MS Windows, UNIX. В-третьих, для определения и обработ­ки XML-документов можно ис­пользовать ряд связанных стандартов, в том числе Document Type Definitions (DTD) и XML-схемы, позво­ляющие определять XML-документы, спецификация Namespaces, язык указателей XML (XML Pointer Language - XPointer), язык ссылок XML (XML Linking Language – XLink), язык запросов XQuery, объектная модель (Document Object Model - DOM),  интерфейсы API, язык преобразования Extensible Stylesheet Language (XSLT).

 

 

Объектная модель документа (DOM) предполагает представление структуры и содержания документа в виде совокупности узлов, каждый из которых имеет свои свойства (имя, тип, значение, число дочерних узлов) и методы (создание, удаление, вставка). Модель DOM используется при обработке XML-документов, как различными XML-процессорами, так и при написании собственных процедур преобразования. DOM определяет некоторый стандартный набор объектов для представления HTML- и XML-документов, методы и алгоритмы комбинирования этих объектов, а также интерфейс для доступа к ним и выполнения операций над ними.

 

XML (Extensible Markup Language) - это язык разметки, описывающий класс объектов данных, называемых XML- документами. XML – это средство для описания грамматики представления и контроля правильности составления документов.

Если XML-документ не нарушает правила синтаксиса XML, то он называется формально-правильным или - хорошо оформленным документом, и разборщики XML-документов, будут работать с ним корректно.

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

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

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

 

14.3.2. Основы XML

Синтаксис XML

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

Правильные, хорошо оформленные XML-документы должны удовлетворять следующим требованиям (слайд 16):

1) В XML все элементы должны иметь закрывающий тэг, т.е. в отличие от HTML, XML не разрешается опускать конечные тэги элементов

2) В тэгах XML учитывается регистр[6]. Например,  <Book> отличается от <book>. Таким образом, начальные и конечные тэги должны писаться в одном регистре.

3) Элементы XML должны быть правильно вложены друг в друга

Перекрывание элементов возникает тогда, когда закрывающий тэг внешнего элемента располагается перед закрывающим тэгом внутреннего элемента, например:

<b><i>Этот текст пишется полужирным курсивом</i></b>

4) XML-документы должны иметь единственный корневой элемент

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

5) Значения атрибутов всегда должны быть заключены в кавычки

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

6) все пробелы являются значимыми, т.е. при отображении пробелы в XML-документе не будут устраняться (в отличие от отображения HTML-документов).

7) В XML есть несколько зарезервированных символов, которые используются только как элементы синтаксиса XML и, следовательно, при необходимости их употребления в тексте, такие символы нужно заменять сущностями - специальными последовательностями других символов. Такими зарезервированными символами являются пять следующих знаков:  <, >, &, “, ‘.

 

XML-документы имеют два раздела: пролог и тело документа (слайд 17).

Пролог, предваряющий любой XML-документ, включает объявление XML и объявление типа документа. Объявление XML заключается между парами символов <? и ?> и может включать указание программе-анализатору текущего стандарта, объявление кодировки и самостоятельности, например, на слайде представлено объявление XML-документа с внешним DTD-определением в файле sample.dtd.

К телу документа относится все кроме пролога.

Тело XML-документа состоит из элементов разметки и непосредственно содержимого документа – данных, и представляет собой набор элементов и атрибутов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных.

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

 

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

Элементы могут иметь подэлементы (дочерние элементы). Подэлементы должны быть правильно вложены внутри родительского элемента (на слайде - <root>, <child>).

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

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

Сущности и специальные символы (слайд 19). Для того, чтобы включить в документ, например, символ, используемый для определения каких-либо конструкций языка (например, символ угловой скобки), нужно использовать его специальный символьный либо числовой идентификатор. Например, &lt;, &gt; &quot; или &#036; (десятичная форма записи), &#x1a (шестнадцатеричная) и т.д.  Таким образом, если необходимо поместить внутрь XML-элемента символ "<", и не вызвать ошибку, потому что он будет интерпретирован как начало нового элемента, символ "<" нужно заменить ссылкой на сущность:

<message>if salary &lt; 1000 then</message>

 

 

14.3.3. XML и реляционная модель данных

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

Эту таблицу можно представить как XML-доку­мент с именем Customers, содержащий два элемента Customer. При этом поля можно представить тремя способами:

1)   в атрибутной форме, где им будут соответствовать атрибуты пустого элемента.

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

3)   в смешанной форме:

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

С точки зрения реляционной модели, различия между этими способам могут быть сведены к тому, что атрибуты подобны колонкам (точнее, их именам – атрибутам, которые могут иметь значение – величину в соответствующей ячейке), а элементы аналогичны строкам (в том числе, включая атрибуты). Атрибут может иметь только одно значение (атомарность ячейки), а элемент может повторяться. То есть, можно сказать, что атрибуты представляют «горизонтальную» модель, а элементы – «вертикальную».

 

14.3.4. Представление связей с помощью XML

Реляционные БД предназначены для представления связей между сущностями. Напри­мер, сущность заказ (Order) может быть связана с несколькими сущнос­тей товар (Item), как, например, на слайде 21.

С помощью XML в простейшем случае связь может быть реализована в виде вложенных атрибутов.

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