Лекция 3.

Лекция 3. Форматы и синтаксис
Как было показано выше схема данных определяет абстрактную структуру записи структуру, которая описывает последовательность и иерархию элементов в записи.
Однако при извлечении записей из баз данных эти записи должны быть представлены в
определенной форме с определенным синтаксисом, который должен обеспечивать
адекватное отображение структур этих записей.
Форму представления записи обычно называют форматом. Одна и та же запись в
одной и той же схеме может быть представлена в различных форматах.
С точки зрения физичекого представления данных форматы могут быть простыми
и структурированными. Под физичеким представлением мы будем понимать форму
передачи записи.
Простые
форматы
изначально
не
содержат
правил
для
передачи
структурированных данных (данные передаются в форме последовательности байт
определенной длины). Передача структурированных данных при этом возможна только
при определении дополнительных правил разметки для этого формата. В качестве
примера можно привести формат html, который физически представляет собой обычный
текст, содержащий внутреннюю разметка в
соответствии с правилами html. Другой
пример - xml.
Структурированные
форматы
допускают
передачу
структурированной
информации без определения дополнительных правил разметки.
Формат xml
Запись в формате xml представляет собой простой текст с внутренней разметкой в
соответствии с правилами xml и схемой данных:
<?xml version="1.0" encoding="utf-8"?>
<person_list ns="info:ict/person"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://db3.sbras.ru/ict/person
http://db3.sbras.ru/ict/person.xsd" >
<person id="16789">
<fName lang="ru">Иван</fName>
<lName lang="ru">Иванов</lName>
<mName lang="ru">Иванович</mName>
<phones>
<mPhone>+7 999 888 0101</mPhone>
<mPhone>+7 333 444 0507</mPhone>
</phones>
</person>
</person_list>
Формат xml широко используется для передачи структурированных данных в при
использовании технологий WEB.
Формат json
Запись в формате json представляет собой простой текст с внутренней разметкой в
соответствии с правилами json:
{
person_list: {
person: {
"fName": "Иван",
"lName": "Иванов",
"mName": "Иванович",
"phones": {
"mPhone": [ "+7 999 888 0101", "+7 333 444 0507"]
}
}
}
}
Формат json широко используется для передачи структурированных данных в WEB
приложениях, чаще всего при использовании javascript.
Форматы ISO-2709
Форматы семейства ISO-2709 (MARC21, USMARC, RUSMARC, UNIMARC,
МЕКОФ) широко используются для представления библиографичесой информации.
Пример записи (RUSMARC):
Читать запись ISO-2709 не очень удобно. Обычно для удобства чтения запись ISO2709 показывают в виде
001
005
035
100
101
102
105
200
RU\NSU\worksnsu\66
20120821143005.0
$a RU\NSU\books\91
$a 20051024d1985
u y0rusy01020304ca
0 $a rus
$a RU
$a
zy
1 $a О структурном моделировании знака $e Тезисы $f В.И. Ожогин, В.И.
2
463
1
610
700
701
1
1
801
801
899
998
0
2
Гуваков
$1 2001 $a Моделирование и оптимизация информационных процессов в
развитом социалистическом обществе $v С. 57-58 $1 210
$a
Новосибирск $d 1985
$a труды учёных НГУ
$a Ожогин $b В.И. $g Владимир Ильич $2 63013096 $3 RU\NSU\person\13917
$a Гуваков $b В.И. $g Владимир Иванович $2 63013096 $3
RU\NSU\person\48408
$a RU
$a RU $b 63013096 $c 20120821 $g RCR
$a 63013096
$a О0стмо000000Ожог
Запись в формате ISO-2709 представляет собой байтовую последовательность (не
текст!) с внутренней разметкой в соответствии с правилами:
Каждая запись ISO2709 должна содержать:



Маркер записи, состоящий из 24-х символов.
Справочник.
Поля данных переменной длины, отделенные друг от друга разделителем
поля.
 Разделитель записи.
Ниже коротко описан каждый из этих блоков.
Маркер записи
ISO-2709 предписывает, что каждая запись начинается с 24-х символьного маркера
записи. Он содержит данные, относящиеся к структуре записи, определения которых
даются в стандарте ISO-2709, а также некоторые элементы данных, выделенные ISO-2709
для особого применения.
Смещение (байт)
Длина (байт)
Поле
0
5
Длина записи
5
1
Статус записи
6
4
Коды применения
10
1
Длина индикатора
11
1
Длина идентификатора подполя
12
5
Начало данных
17
3
Резерв
План справочника
20
1
Длина записи о длине поля данных
21
1
Длина записи о начальной позиции
22
1
Длина части, определяемой при
применении
23
1
Резерв
3
Справочник
За маркером записи следует справочник. Каждая статья справочника состоит из
четырех частей:
Длина
Метка
3
Байт 20 маркера
Длина поля данных
Байт 21 маркера
Позиция начального символа
Байт 22 маркера
Часть, определяемая при применении
Метки, длина которой определяется значением байта 11 в маркере.
Числа, указывающего длину поля данных. Это число занимает количество байт,
соответствующее байту 20 маркера.
Числа, указывающего начальную позицию данных. Это число занимает количество
байт, соответствующее байту 21 маркера.
Для форматов семейства MARC часть, определяемая при применении отсутствует,
соответственно значение байта 22 в маркере равно 0.
Другие символы в статье справочника не допускаются. Первая часть каждой статьи
справочника - метка поля. Вторая часть статьи справочника определяет число символов в
поле, на которое указывает метка, приведенная в первой части статьи. В это число
включаются все символы - индикаторы, идентификаторы подполей, текстовые или
кодированные данные и разделитель полей. Третья часть статьи справочника содержит
позицию первого символа поля относительно позиции первого символа той части записи,
которая содержит переменные поля. Первый символ первого переменного поля имеет
символьную позицию 0. Положение символьной позиции 0 внутри целой записи задается
позициями символов 12-16 маркера записи. Справочник заканчивается разделителем поля
(1E).
Поля данных
Поля данных переменной длины следуют за справочником и содержат данные.
Метки не содержаться в полях данных, а приводятся только в справочнике. Поля данных
состоят из индикаторов, части для применения и следующим за ними любым количеством
подполей. Каждое подполе начинается с идентификатора подполя, который состоит из
разделителя
подполя
(1F)
и
кода
подполя,
идентифицирующего
подполе.
За
идентификаторами подполя следуют кодированные или текстовые данные произвольной
длины, не превышающей указанной в начале описания поля. Поле данных заканчивается
символом разделителя поля (1E) Последним символом данных в записи является символ
конца записи (1D), следующий за символом конца поля (1E).
4
Для WEB технологий представление записей в ISO-2709 является не очень
удобным. Существует стандартное отображение форматов ISO-2709 на формат xml.
Пример приведен ниже:
<?xml version="1.0" encoding="utf-8"?>
<record xmlns="http://www.loc.gov/MARC21/slim">
<leader>00785naa0a2200217 i 450 </leader>
<controlfield tag="001">RU\NSU\worksnsu\66</controlfield>
<controlfield tag="005">20120821143005.0</controlfield>
<datafield tag="035" ind1=" " ind2=" ">
<subfield code="a">RU\NSU\books\91</subfield>
</datafield>
<datafield tag="100" ind1=" " ind2=" ">
<subfield code="a">20051024d1985
u y0rusy01020304ca</subfield>
</datafield>
<datafield tag="101" ind1="0" ind2=" ">
<subfield code="a">rus</subfield>
</datafield>
<datafield tag="102" ind1=" " ind2=" ">
<subfield code="a">RU</subfield>
</datafield>
<datafield tag="105" ind1=" " ind2=" ">
<subfield code="a">
zy</subfield>
</datafield>
<datafield tag="200" ind1="1" ind2=" ">
<subfield code="a">О структурном моделировании знака</subfield>
<subfield code="e">Тезисы</subfield>
<subfield code="f">В.И. Ожогин, В.И. Гуваков</subfield>
</datafield>
<datafield tag="463" ind1=" " ind2="1">
<subfield code="1">2001 </subfield>
<subfield code="a">Моделирование и оптимизация информационных
социалистическом обществе</subfield>
<subfield code="v">С. 57-58</subfield>
<subfield code="1">210 </subfield>
<subfield code="a">Новосибирск</subfield>
<subfield code="d">1985</subfield>
</datafield>
<datafield tag="610" ind1=" " ind2=" ">
<subfield code="a">труды учёных НГУ</subfield>
</datafield>
<datafield tag="700" ind1=" " ind2="1">
<subfield code="a">Ожогин</subfield>
<subfield code="b">В.И.</subfield>
<subfield code="g">Владимир Ильич</subfield>
<subfield code="2">63013096</subfield>
<subfield code="3">RU\NSU\person\13917</subfield>
</datafield>
<datafield tag="701" ind1=" " ind2="1">
<subfield code="a">Гуваков</subfield>
<subfield code="b">В.И.</subfield>
<subfield code="g">Владимир Иванович</subfield>
<subfield code="2">63013096</subfield>
<subfield code="3">RU\NSU\person\48408</subfield>
</datafield>
<datafield tag="801" ind1=" " ind2="0">
<subfield code="a">RU</subfield>
</datafield>
<datafield tag="801" ind1=" " ind2="2">
<subfield code="a">RU</subfield>
<subfield code="b">63013096</subfield>
<subfield code="c">20120821</subfield>
5
процессов
в
развитом
<subfield code="g">RCR</subfield>
</datafield>
<datafield tag="899" ind1=" " ind2=" ">
<subfield code="a">63013096</subfield>
</datafield>
<datafield tag="998" ind1=" " ind2=" ">
<subfield code="a">О0стмо000000Ожог</subfield>
</datafield>
</record>
Это представление записи RUSMARC, где как и в любом MARC-формате
существуют два индикатора и отсутствуют "части для применения".
Форматы в Z39.50
Модель извлечения данных
Идеология максимального абстрагирования от структур реальных баз данных
приводит к весьма изощренной схеме извлечения данных, описанной в стандарте Z39.50.
Запись физической
базы данных
Отображение на
абстрактную структуру
записи, определенной
схемой данных
Абстрактная запись БД
Применение
спецификаций
элементов
Извлекаемая запись
базы данных
Преобразование в
затребованный формат в
соответствии с
синтаксисом
Преобразованная абстрактная
запись БД
Рис. 1. Модель извлечения записей из базы данных
Рис. 1 схематично иллюстрирует эту процедуру: записи из результирующих
наборов отображаются в записи абстрактной базы данных через схему, определяющую
абстрактную структуру записи в виде дерева элементов, специфицируемых метками (tag)
из стандартных наборов (tagSet); затребованные элементы выбираются в нужной
альтернативной форме (variant) из абстрактной записи и отображаются в экспортируемую
структуру, определяемую форматом внешнего представления (recordSyntax). Все объекты
описанной процедуры (schema, tagSet, elementSpec, variantSet, recordSyntax) определены в
соответствующих классах с присвоением OID.
6
Формат GRS-1
Схема данных и абстрактная структура записи, рассмотренные в предыдущей
секции, определяют лишь логическую структуру записи. Физическая реализация этой
структуры остается неопределенной. Стандарт Z39.50 требует, чтобы записи из
внутреннего
представления
отображались
во
внешние
структуры,
которые
и
пересылаются по сети. Для внешних представлений, которые стандартизуются в классе
(recordSyntax) {1.2.840.10003.5}, физическая реализация становится определяющей.
Существует
всего
один
универсальный
формат
внешнего
представления
(recordSyntax), который однозначно отображает абстрактную структуру записи в
экспортируемую внешнюю физическую структуру. Он называется GRS-1 (Generic Record
Syntax) OID {1.2.840.10003.5.105}.
ASN.1 определение записи в формате GRS-1 можно найти в описание протокола.
Если в этом определении оставить основное, исключив варианты и метаинформацию,
останется:
GenericRecord ::= SEQUENCE OF TaggedElement
TaggedElement ::= SEQUENCE {
tagType
[1] IMPLICIT INTEGER OPTIONAL,
tagValue
[2] StringOrNumeric,
content
[4] ElementData }
ElementData ::= CHOICE{
octets
numeric
date
ext
string
trueOrFalse
oid
intUnit
[1]
elementNotThere
[2]
elementEmpty
[3]
noDataRequested
[4]
diagnostic
[5]
subtree
[6]
END
OCTET STRING,
INTEGER,
GeneralizedTime,
EXTERNAL,
InternationalString,
BOOLEAN,
OBJECT IDENTIFIER,
IMPLICIT IntUnit,
IMPLICIT NULL, -- element
IMPLICIT NULL, -- element
IMPLICIT NULL, -- variant
IMPLICIT EXTERNAL,
SEQUENCE OF TaggedElement
requested but not there
there, but empty
request said 'no data'
}
т.е. последовательность элементов (taggedElement), каждый их которых содержит тип тэга
(tagType, т.е. номер tagSet), значение тэга (tagValue) и данные (content). Значение тэга
может быть числовым или текстовым. Данные – это или значение или вложенный элемент
(taggedElement) с описанной структурой (определение subtree ничем не отличается от
7
определения
GenericRecord).
Таким
образом,
GRS-1
представляет
собой
последовательность элементов со структурой, определенной в терминах, аналогичных
определению абстрактной структуры записи и схемы данных, с бесконечным количеством
вложений.
Следует заметить, что в Z39.50 в классе (recordSyntax) {1.2.840.10003.5}
определены и другие форматы.
1.2.840.10003.5.1
Unimarc
1.2.840.10003.5.2
Intermarc
1.2.840.10003.5.3
CCF
1.2.840.10003.5.10
USmarc
1.2.840.10003.5.11
UKmarc
1.2.840.10003.5.12
Normarc
1.2.840.10003.5.13
Librismarc
1.2.840.10003.5.14
Danmarc
1.2.840.10003.5.15
Finmarc
1.2.840.10003.5.16
MAB
1.2.840.10003.5.17
Canmarc
1.2.840.10003.5.18
SBN
1.2.840.10003.5.19
Picamarc
1.2.840.10003.5.20
Ausmarc
1.2.840.10003.5.21
Ibermarc
1.2.840.10003.5.22
Carmarc
1.2.840.10003.5.23
Malmarc
1.2.840.10003.5.26
SIGLEmarc
1.2.840.10003.5.27
ISSNmarc
1.2.840.10003.5.28
RUSmarc
1.2.840.10003.5.100
Explain
1.2.840.10003.5.101
SUTRS
1.2.840.10003.5.102
OPAC
1.2.840.10003.5.103
Summary
1.2.840.10003.5.104
GRS-0
1.2.840.10003.5.105
GRS-1
1.2.840.10003.5.106
Extended
1.2.840.10003.5.107
Fragment
1.2.840.10003.5.109.1
pdf
1.2.840.10003.5.109.2
postscript
1.2.840.10003.5.109.3
html
1.2.840.10003.5.109.4
tiff
1.2.840.10003.5.109.5
gif
1.2.840.10003.5.109.6
jpeg
1.2.840.10003.5.109.7
png
1.2.840.10003.5.109.8
mpeg
8
1.2.840.10003.5.109.9
sgml
1.2.840.10003.5.110.1
tiff-b
1.2.840.10003.5.110.2
wav
1.2.840.10003.5.111
SQL-RS
1.2.840.10003.5.1000.81.2
SOIF
1.2.840.10003.5.109.10
text-XML
1.2.840.10003.5.109.10
XML
1.2.840.10003.5.109.11
application-XML
1.2.840.10003.5.1000.155.1
rtf
Форматы в LDAP
Формат LDIF
Файлы LDIF используются в пяти основных случаях:
1. Для первоначального создания структуры DIT.
2. Для добавления (импорта) больших записей в каталог.
3. Для восстановления (импорта) каталога.
4. Для архивирования (экспорта) каталога.
5. Для выполнения крупных изменений каталога.
Пример представления данных в формате LDIF приведен ниже
#
# Фрагмент каталога в формате LDIF
#
dn: ou=Отдел 1,ou=DSpace,dc=ru
description: Подразделение для проверки
postalAddress: Новосибирск, ул. Иванова 145
postalCode: 630090
objectClass: organizationalUnit
objectClass: top
ou: Отдел 1
dn: cn=Иванов Александр Сергеевич,ou=Отдел 1,ou=DSpace,dc=ru
homePostalAddress: Новосибирск
initials: А.С.
mail: ivanov@mail.ru
mobile: +7 913-888-8799
cn: Иванов Александр Сергеевич
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
sn: Иванов А.С.
9
Формат DSML
DSML -
это формат xml с применением специальной схемы данных. Пример
записи фрагмента каталого приведен ниже
<?xml version="1.0" encoding="utf-8"?>
<dsml:dsml xmlns:dsml="http://www.dsml.org/DSML">
<dsml:directory-entries>
<dsml:entry dn="ou=Отдел 1,ou=DSpace,dc=ru">
<dsml:attr name="description">
<dsml:value>Подразделение для проверки</dsml:value>
</dsml:attr>
<dsml:attr name="postalAddress">
<dsml:value>Новосибирск, ул. Иванова 145</dsml:value>
</dsml:attr>
<dsml:attr name="postalCode">
<dsml:value>630090</dsml:value>
</dsml:attr>
<dsml:objectclass>
<dsml:oc-value>organizationalUnit</dsml:oc-value>
<dsml:oc-value>top</dsml:oc-value>
</dsml:objectclass>
<dsml:attr name="ou">
<dsml:value>Отдел 1</dsml:value>
</dsml:attr>
</dsml:entry>
<dsml:entry dn="cn=Иванов Александр Сергеевич,ou=Отдел 1,ou=DSpace,dc=ru">
<dsml:attr name="homePostalAddress">
<dsml:value>Новосибирск</dsml:value>
</dsml:attr>
<dsml:attr name="initials">
<dsml:value>А.С.</dsml:value>
</dsml:attr>
<dsml:attr name="mail">
<dsml:value>ivanov@mail.ru</dsml:value>
</dsml:attr>
<dsml:attr name="mobile">
<dsml:value>+7 913-888-8799</dsml:value>
</dsml:attr>
<dsml:attr name="cn">
<dsml:value>Иванов Александр Сергеевич</dsml:value>
</dsml:attr>
<dsml:objectclass>
<dsml:oc-value>inetOrgPerson</dsml:oc-value>
<dsml:oc-value>organizationalPerson</dsml:oc-value>
<dsml:oc-value>person</dsml:oc-value>
<dsml:oc-value>top</dsml:oc-value>
</dsml:objectclass>
<dsml:attr name="sn">
<dsml:value>Иванов А.С.</dsml:value>
</dsml:attr>
</dsml:entry>
</dsml:directory-entries>
</dsml:dsml>
Из представленных примеров можно получить представление о структуре формата
DSML. Следует заметить, что формат LDIF более компактен, нежели DSML, но
последний может быть обработан стандартным инструментарием xml.
10