Лекция 2. Хранение и представление данных

Лекция 2. Хранение и представление данных
Структурированные данные обычно хранятся в файловых системах и управляются
при помощи специализированного программного обеспечения - СУБД (система
управления базами данных).
По назначению, функциональным возможностям, моделям хранения и т.п.
различные СУБД могут различаться очень сильно.
Модели данных
Самое главное свойство, по которому различаются СУБД - модель организации
данных.
Реляционная модель - модель, в которой данные представляются в виде таблицы,
каждая строка которой является идентифиуируемым объектом хранения. Записи разных
таблиц могут быть связаны различными соотношениями.
Реляционная модель данных реализована в различных реляционных СУБД
(РСУБД), типичные представители которых - MS SQL Server, PostgreSQL, MySQL, Oracle,
SYBase Server и др.
Иерархическая модель - модель, в которой данные представляются в виде дерева,
при этом идентифиуируемыми объектами хранения могут выступать как различные
экземпляры всего дерева, так и экземпляры веток единого единого дерева.
В качестве примера иерархической СУБД можно привести файловую систему
современных ОС. Идентификация объектов (файлов) в такой СУБД осуществляется по
полному имени файла, включающего перечисление всех вышестоящих узлов дерева
каталогов.
Другой пример - пример записи иерархической СУБД - текстовый XML файл.
Сетевая модель - модель, в которой данные представляются в виде дерева, при
этом идентифиуируемыми объектами хранения могут выступать как различные
экземпляры всего дерева, так и экземпляры веток единого единого дерева. В отличие от
иерархической модели в этом случае элементы дерева могут ссылаться на элементы
других деревьев. В сетевой модели каждый элемент дерева может присутствовать в
разных ветках.
В качестве примера сетевой СУБД можно опять привести файловую систему
современных ОС с задействованным механизмом связей. Например, команда (UNIX,
Linux, QNX, ...):
ln -s /a/file1.еxt
file2.txt
создает связь - объект file2.txt в текущем каталоге является ссылкой на файл /a/file1.txt.
Другой пример сетевой СУБД - каталоги серверов LDAP.
Внешнее и внутреннее представление данных
При использовании как в реляционной, так и в иерархической моделей данных для
организации конкретной базы данных необходимо определение структуры хранимых
записей, состава элементов, типов данных для каждого элемента и пр.
Для реляционной модели мы должны определить:

количество требуемых таблиц

состав полей (столбцов) для каждой таблицы

тип данных для каждого поля

обязательность заполнения каждого поля

значение поля по умолчанию

связи между таблицами

первичные и вторичные ключи

дополнительные индексы

и др.
Для иерархической модели мы должны определить:

структуру дерева данных

список допустимых элементов, причем для каждого элемента:
-
его место структуре дерева
-
тип данных (для простого элемента)
-
структуру (для составного)
-
обязательность или необязательность наличия в дереве
-
возможность повторения
Совокупность перечисленных (и других) определений составляет определение
схемы данных.
Нетрудно заметить, что каждая из создаваемых баз данных скорее всего будет
иметь свою уникальную схему данных. Эта уникальность будет отражена как в структуре
2
деревьев, таблиц и связей, так и в названиях полей или элементов данных, при этом даже
в случае, когда в разных базах данных хранится однотипная (однородная) информация.
Возникает вопрос, что делать, если нужно осуществлять поиск и извлекать
информацию одновременно из различных СУБД с однотипной информацией, т.е. как
можно интегрировать данные, которые изначально соответствуют различным локальным
схемам данных?
Для решения этой проблемы для внешнего представления данных существует
несколько подходов.
1. Каждая выгружаемая из базы данных запись содержит, кроме собственно
данных, полное определение схемы данных этой записи.
2. Локальной схеме данных приписывается некий уникальный идентификатор
(идентификатор схемы данных). Значение этого идентификатора всегда
присутствует в структуре выгружаемой из базы данных записи. Нетрудно
догадаться, что при таком подходе одна проблема заменяется другой, т.к.
требуется дополнительная база данных, в которой бы хранились определения
схем данных, соответствующих каждому использованному идентификатору.
3. Каждая
выгружаемая
из
базы
данных
запись
содержит
не
только
идентификатор схемы, но и ссылку, например, URL, на файл определения
схемы данных.
4. Создается ограниченное число схем данных с наиболее общим набором
элементов. Каждой из этих схем приписывается постоянный глобальный
идентификатор. Список этих глобальных идентификаторов включается в код
каждого клиента серверов СУБД.
Для примера, технологиях, основанных на XML, используются в разных вариациях
три первых способа, в технологиях, основанных на Z39.50, используется способ 4.
Таким образом, при работе с распределенными данными возникает необходимость
представления данных не в локальной схеме, а в некоторой более общей, которая
"известна" всем участникам сетевого взаимодействия.
Задача
преобразования
данных
из
локальных
схем
в
схемы
внешнего
представления является задачей, которую постоянно приходится решать решать при
извлечении информации из распределенных информационных источников.
Формальное описание схем данных
Существует различные способы формального описания схем данных. При этом в
разных технологиях используются разные способы.
3
DTD - Document Type Definition
Язык схем DTD (DTD schema language) — искусственный язык, который
используется для записи фактических синтаксических правил метаязыков разметки текста
SGML и XML. С момента его внедрения другие языки схем для спецификаций, такие как
XML Schema и RELAX NG, выпускаются с дополнительной функциональностью.
Из-за определённых отличий между XML и SGML, применение DTD также имеет
некоторые особенности в зависимости от целевого документа.
DTD описывает схему документа для конкретного языка разметки посредством
набора объявлений (объектов-параметров, элементов и атрибутов), которые описывают
его класс (или тип) с точки зрения синтаксических ограничений этого документа. Также
DTD может объявлять конструкции, которые всегда необходимы для определения
структуры документа, но, зато, могут влиять на интерпретацию определённых
документов.
С точки зрения DTD, XML (и HTML) - документ состоит из следующих простых
строительных блоков:
Элементы (Elements) - главные строительные блоки XML и HTML-документов.
Примерами HTML-элементов являются "body" and "table". Примерами XML-элементов
могут быть "note" and "message". Элементы могут содержать текст, другие элементы или
быть пустыми. Пример пустых HTML- элементов: "hr", "br" и "img".
Тэги (Tags) - применяются для разметки элементов. Начальный тэг, например,
<element_name> отмечает начало элемента, а конечный тэг, </element_name> отмечает его
конец.
Атрибуты (Attributes) - дают дополнительную информацию об элементах.
Атрибуты
всегда
распологаются
внутри
начального
тэга
элемента.
Атрибуты
применяются в виде пары имя атрибута/его значение. В этом примере элемент "img"
содержит дополнительную информацию о файле-источнике:
<img src="computer.gif" />
Имя элемента - "img". Имя атрибута - "src". Значение атрибута равно "computer.gif".
Поскольку сам элемент пустой, он сразу закрывается: " /".
Сущности (Entities) - это переменные, которые применяются для определения
кусков текста, который используется в нескольких местах. Ссылки на сущности вызывают
эти куски текста. Большинство из вас знают ссылку на сущность, которая используется в
HTML: " ". Это сущность "no-breaking-space". В HTML она используется для
введения в документ дополнительных пробелов. Когда документ анализируется парсером,
ссылкм на сущности заменяются кусками соответствующего текста. Список сущностей,
4
изначально заданных в XML приведен в таблице:
Ссылка на сущность
Символ
<
< (знак меньше)
>
> (знак больше)
&
& (амперсанд)
"
" (двойная кавычка)
'
' (апостроф)
PCDATA - расшифровывается как парсируемые символьные данные (parsed
character data). Символьные данные - это текст, расположенный между начальным и
конечным тэгом XML-элемента. PCDATA - это текст, который будет анализироваться
парсером. Тэги в тексте будут трактоваться как разметка, а сущности будут заменяться
соответствующими кусками текста.
CDATA - также расшифровывается как символьные данные. CDATA - это текст,
который НЕ будет анализироваться парсером. Тэги в тексте НЕ будут трактоваться как
разметка, а сущности не будут заменяться соответствующими кусками текста.
Объявления элементов образовывают перечень разрешенных названий элементов в
документе, а также определяют информацию относительно тегов (являются ли они
обязательными) и модели содержимого для каждого элемента. Различные ключевые слова
и символы определяют содержимое элемента:

EMPTY — пустое содержимое

ANY — любое содержимое

, — указывает порядок

| — разделение альтернатив

() — группировка

— любое количество элементов (ноль и более)

+ — по крайней мере один элемент (один и более)

? — необязательное наличие элемента (ноль или один)

Если нет *, + или ? — элемент должен быть только один
Пример простого XML DTD, описывающего список людей:
<!ELEMENT people_list (person*)>
<!ELEMENT person (name, birthdate?, gender?, socialsecuritynumber?)>
<!ELEMENT name (#PCDATA) >
<!ELEMENT birthdate (#PCDATA) >
5
<!ELEMENT gender (#PCDATA) >
<!ELEMENT socialsecuritynumber (#PCDATA) >
С каждым элементом DTD-документа может быть сопоставлен список атрибутов.
Для этого используется директива !ATTLIST, в которой указываются имя элемента, с
которым может быть сопоставлен список атрибутов и параметры каждого атрибута: его
имя, тип и свойства по умолчанию.
Например:
<!ATTLIST MAP name CDATA #REQUIRED>
Здесь определен атрибут name для элемента MAP. Он является обязательным.
Существуют такие типы атрибутов:












CDATA (Character set of data) — значением атрибута могут быть любые
символьные данные
ID — значением атрибута должен быть уникальный идентификатор элемента
IDREF — значением элемента является ссылка на элемент по его ID
IDREFS — тоже что и IDREF, но с возможностью ссылок не по одному
идентификатору, а по нескольким
NMTOKEN — значением атрибута может быть последовательность символов, в
чём-то схожая с именем (отсюда и названием — name token). Это строка,
которая содержит любую комбинацию тех символов, которые разрешено
использовать для имен XML.
NMTOKENS — значением атрибута является список значений
ENTITY — значение используется для ссылки на внешнюю сущность.
ENTITIES — позволяет задать список внешних сущностей, разделённых
пробелами.
NOTATION — значением атрибута может быть одна из ранее определённых
нотаций
NOTATIONS — позволяет задать список нотаций.
Listings и NOTATION-listings
ENUMERATION — задаёт список возможных альтернатив значений.
Существуют такие свойства по умолчанию:

IMPLIED — значение атрибута указывать не обязательно;

REQUIRED — значение атрибута обязательно должно быть указано;

FIXED — значение этого атрибута задано как константа в DTD и в документе
не может быть изменено;

некоторое конкретное значение, которое используется по умолчанию.
В настоящее время существует тенденция отказа от использования DTD в XMLтехнологии по ряду причин:
6

Используется отличный от XML синтаксис.

Отсутствует типизация узлов.

Отсутствует поддержка пространств имён.
Консорциума W3C рекомендует не использовать DTD для определения схем
данных, а использовать XSD (XML Schema - рекомендация W3C).
XSD - XML Schema Definition
Версия 1.0 была одобрена в качестве рекомендации консорциума W3C 2 мая 2001
года. Таким образом XSD стала первой спецификацией описания схемы XML-документа,
получившей статус рекомендации W3С, среди множества предложенных на рассмотрение.
28 октября 2004 года была опубликована вторая редакция версии 1.0, исправляющая ряд
ошибок. 5 апреля 2012 года была одобрена в качестве рекомендации консорциума Версия
1.1.
Рассмотрим xml набор данных:
<?xml version="1.0" encoding="utf-8"?>
<person_list>
<person id="16789">
<fName lang="ru">Иван</fName>
<lName lang="ru">Иванов</lName>
<mName lang="ru">Иванович</mName>
<mPhone>+7 999 888 0101</mPhone>
</person>
<person id="13451">
<fName lang="ru">Петр</fName>
<lName lang="ru">Сидоров</lName>
<mName lang="ru">Кузьмич</mName>
<mPhone>+7 812 845 3478</mPhone>
</person>
</person_list>
Описание схемы XSD можно представить как
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="person_list">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="person">
<xs:complexType>
<xs:sequence>
<xs:element name="fName">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
7
</xs:element>
<xs:element name="lName">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="mName">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="mPhone" type="xs:string" />
</xs:sequence>
<xs:attribute name="id" type="xs:unsignedShort" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Описание XSD включает в себя описание структуры записи, описание кажого
элемента с указанием его параметров и атрибутов, типа данных и т.д.
LDAP
Технология LDAP оперирует со структурами данных в соответствии с
иерархической моделью.
Информационное дерево LDAP строится из узлов - объектов данных, каждый из
которых определяется наборами свойств, сгруппированных в классы.
Классы в LDAP используются для группировки информации. Классы обеспечивают
следующие возможности:

определяют необходимые атрибуты;

определяют допустимые атрибуты;

обеспечивают легкий способ группирования информации.
Каждый реальный информационный объект дерева LDAP может определяться на
основании нескольких классов. Необходимые и допустимые атрибуты при этом являются
объединением атрибутов каждого класса.
Каждый класс (подкласс) может быть получен из другого класса (суперкласса),
8
который в свою очередь может быть получен из более общего класса. Для
структурных классов данный процесс завершается на самом общем классе, называемом
top.
Упорядоченное
множество
суперклассов
от
наиболее
общего класса до
данного класса называется цепочкой суперклассов.
Каждый класс определяет множество атрибутов, которые должны присутствовать
в записях, принадлежащихклассу, и множество атрибутов, которые могут присутствовать
в этих записях. Класс, как и запись, должен удовлетворять требованиям каждого
суперкласса, которому он принадлежит. Это говорит о том, что класс наследует
множества допустимых и необходимых атрибутов от своих суперклассов.
Каждый класс определяется
как
один
из
трех
видов
классов:
Abstract
(абстрактный), Structural (структурный) или Auxiliary (вспомогательный).
Абстрактные классы
Абстрактный (Abstract) класс, как следует из его названия, предоставляет основу
для характеристик, с помощью которой другие классы объектов могут быть определены
как наследуемые. Запись не может принадлежать абстрактному классу, если она не
принадлежит структурному или вспомогательному классу, который наследуется от
данного абстрактного класса.
Абстрактные классы не
могут
происходить
от
структурных
или
вспомогательных классов.
Все
структурные классы
объектов получены
(прямо
или
косвенно)
от
абстрактного класса top . Вспомогательные классы необязательно получены от top.
Структурные классы объектов
Каждый
структурный класс (Structural)
является
(прямым
или
косвенным)
подклассом top абстрактного класса.
Структурные классы не могут быть подклассом вспомогательных классов.
Каждая информационный
объект
в
каталоге
LDAP принадлежит
своему
структурному классу, а также всем классам в цепочке структурных классов, которая
всегда включает top.
Вспомогательные классы объектов
Вспомогательные классы (Auxiliary)
характеристик записей.
Обычно
они
используются
применяются
9
для
как
дополнение
расширения
множества
необходимых и допустимых атрибутов записи, а также могут использоваться для
описания записей или классов записей.
Вспомогательные классы не могут быть подклассом структурных классов.
Запись может
принадлежать
любому
подмножеству
множества
вспомогательных классов.
Множество вспомогательных классов, которым принадлежит запись, может со
временем изменяться.
Пример:
#
#
# This attribute handles MS/Outlook and Netscape Communicator
#
dn: cn=schema
attributeTypes: ( 1.3.6.1.4.1.4203.666.100.121 NAME ( 'rdn' )
SUP name X-ORIGIN 'For MS Office')
attributetypes: ( 1.3.6.1.4.1.4203.666.100.122 NAME ( 'otherFacsimiletelephoneNumber' )
SUP telephoneNumber X-ORIGIN 'For MS Office' )
attributetypes: ( 1.3.6.1.4.1.4203.666.100.123 NAME ( 'ipPhone' )
SUP telephoneNumber X-ORIGIN 'For MS Office' )
attributetypes: ( 1.3.6.1.4.1.4203.666.100.125 NAME ( 'comment' )
##
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
DESC 'Это комментарий'
SUP name X-ORIGIN 'For MS Office' )
attributetypes: ( 1.3.6.1.4.1.4203.666.100.126 NAME ( 'conferenceInformation' )
SUP name X-ORIGIN 'For MS Office' )
attributetypes: ( 1.3.6.1.4.1.4203.666.100.127 NAME ( 'reports' )
SUP manager X-ORIGIN 'For MS Office' )
objectclasses: ( 1.3.6.1.4.1.4203.666.100.1 NAME 'officePerson'
DESC 'Office employee or computer user'
SUP inetOrgPerson STRUCTURAL
###
MUST () - список обязательных атрибутов
MAY ( c $ rdn $ otherFacsimiletelephoneNumber $
ipPhone $ URL $ comment $ reports $ conferenceInformation )
X-ORIGIN 'For MS Office' )
#######################################################################
Z39.50
Схемы данных в Z39.50 определяются через наборы меток. Дело в том, что каждый
информационный объект в абстрактной иерархической структуре записи Z39.50 имеет
свой идентификатор - указание на набор меток (tagSet) на номер или имя метки в этом
наборе.
В качестве примера в таблице приведен список меток стандартного набора G
(tagSet-G), имеющего системный номер 2.
10
№
1
Название тэга
title
Тип данных
InternationalString or
structured into following sub-elements:
 'wellKnown',
 tagSet-M element 19, dataType InternationalString,
 'type' tagSet-M element 23
'scheme' tagSet-M element 24
2
author
Same datatype definition as title
3
publicationPlace
InternationalString
4
publicationDate
InternationalString
5
documentId
InternationalString
6
abstract
internationalString
7
name
Same datatype definition as title
8
dateTime
EXTERNAL (Z3950DateTime) or
GeneralizedTime, or InternationalString, or
structured into following sub-elements:
 'wellKnown',
 tagSet-M element 19, dataType 1, 2, or 3 above.
 'type' tagSet-M element 23
 'scheme' tagSet-M element 24
9
displayObject
OCTET STRING
10
organization
InternationalString
11
postalAddress
InternationalString
12
networkAddress
InternationalString
13
eMailAddress
InternationalString
14
phoneNumber
InternationalString
15
faxNumber
InternationalString
16
country
InternationalString, or
structured into following sub-elements:
 'wellKnown', tagSet-M element 19, dataType InternationalString
 'scheme' tagSet-M element 24
17
description
InternationalString, or
structured into following sub-elements:
 'wellKnown', tagSet-M element 19, dataType InternationalString
 'type' tagSet-M element 23
18
time
19
DocumentContent
OCTET STRING
20
language
InternationalString, or
structured into following sub-elements:
 'wellKnown', tagSet-M element 19, dataType InternationalString
 'scheme' tagSet-M element 24
21
subject
Same dataType definition as title
22
resourceType
InternationalString, or
structured into following sub-elements:
 'wellKnown', tagSet-M element 19, dataType InternationalString
 'scheme' tagSet-M element 24
23
city
InternationalString
11
24
stateOrProvince
InternationalString
25
zipOrPostalCode
InternationalString
26
cost
InternationalString, or IntUnit, or structured
27
format
InternationalString or structured
28
identifier
Same dataType definition as title
29
rights
Same dataType definition as title
30
relation
Same dataType definition as title
31
publisher
Same dataType definition as title
32
contributor
Same dataType definition as title
33
source
Same dataType definition as title
34
coverage
Same dataType definition as title
35
private
dataType definition defined by schema
36
databaseName
InternationalString
37
recordId
InternationalString
Элементы данных в абстрактной структуре записи могут идентифицироваться
следующим образом:
(2,1) – title;
(2,2) – author;
(2,7) – name;
(2,11) - postalAdress; (2,3) - publicationPlace; (2,14) - phoneNumber;
Каждый набор меток (tagSet) в Z39.50 должен иметь свой идентификатор - OID.
При этом допускаются как глобальные, так и локальные OIDы.
Так идентификатором tagSet-G является следующий OID:
1.2.840.10003.14.2
1 - ISO
2 - member_body
840 - US
10003 - Z39.50
14 - Tag Set Definitions
2 - tagSet-G
Система идентификации объектов через OID присуща не только Z39.50, но и
многим другим технологиям, в том числе и LDAP. Что касается Z39.50, то в этой
технологии через OID идентифицируются все структуры и определения.
После определения списка наборов и
списка меток
можно определить
иерархическую структуру - абстрактную структуру записи. При этом собственно
абстрактная структура записи может быть представлена, например, так:
(2,2)
(2,2)/(2,7)
(2,2)/(2,11)
(2,2)/(2,14)
(2,3)
Author
Name
Adress
Phone
Place
12
Теперь для окончательного определения схемы данных требуется полученное
дерево формально описать.
Определение схем данных в Z39.50 соответствует следующему формальному
определению ASN.1:
SchemaInfo ::= SEQUENCE {
commonInfo
[0] IMPLICIT CommonInfo OPTIONAL,
schema
[1] IMPLICIT OBJECT IDENTIFIER,
name
[2] IMPLICIT InternationalString,
description
[3] IMPLICIT HumanString OPTIONAL,
tagTypeMapping
[4] IMPLICIT SEQUENCE OF SEQUENCE {
tagType
[0] IMPLICIT INTEGER,
tagSet
[1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
-- If tagSet is omitted, then this tagType is for a tagSet
-- locally defined within the schema that cannot be
-- referenced by another schema.
defaultTagType [2] IMPLICIT NULL OPTIONAL
} OPTIONAL,
recordStructure [5] IMPLICIT SEQUENCE OF ElementInfo OPTIONAL
}
ElementInfo ::= SEQUENCE {
elementName
[1] IMPLICIT InternationalString,
elementTagPath
[2] IMPLICIT Path,
dataType
[3] ElementDataType OPTIONAL,
-- If omitted, not specified.
required
[4] IMPLICIT BOOLEAN,
repeatable
[5] IMPLICIT BOOLEAN,
description
[6] IMPLICIT HumanString OPTIONAL}
Path ::= SEQUENCE OF SEQUENCE{
tagType
[1] IMPLICIT INTEGER,
tagValue
[2] StringOrNumeric }
ElementDataType ::= CHOICE{
primitive
[0] IMPLICIT PrimitiveDataType,
structured
[1] IMPLICIT SEQUENCE OF ElementInfo}
PrimitiveDataType ::= INTEGER{
octetString
numeric
date
external
string
trueOrFalse
oid
intUnit
empty
noneOfTheAbove
}
(0),
(1),
(2),
(3),
(4),
(5),
(6),
(7),
(8),
(100) -- see 'description'
HumanString ::= SEQUENCE OF SEQUENCE {
language
[0] IMPLICIT LanguageCode OPTIONAL,
text
[1] IMPLICIT InternationalString}
TagSetInfo ::= SEQUENCE {
commonInfo
[0]
IMPLICIT CommonInfo OPTIONAL,
tagSet
[1]
IMPLICIT OBJECT IDENTIFIER,
name
[2]
IMPLICIT InternationalString,
13
description
[3]
elements
[4]
elementname
nicknames
IMPLICIT HumanString OPTIONAL,
IMPLICIT SEQUENCE OF SEQUENCE {
[1] IMPLICIT InternationalString,
[2] IMPLICIT SEQUENCE OF
InternationalString OPTIONAL,
elementTag
[3] StringOrNumeric,
description [4] IMPLICIT HumanString OPTIONAL,
dataType
[5] PrimitiveDataType OPTIONAL,
-- If the data type is expected to be structured, that is
-- described in the schema info, and datatypeis omitted here.
otherTagInfo [6] OtherInformation OPTIONAL
} OPTIONAL
}
Заметим, что каждая схема данных в Z39.50 имеет свой идентификатор OID в
классе
1.2.840.10003.13 - data base schema definition
В
качестве
примера
можно
привести
схематично
описание
представленной выше структуры записи.
{
schema: 1.2.840.10003.13.100.155.999,
name: test1,
description: { { language: 'RUS', text: 'Это схема для проверки' },
{ language: 'ENG', text: 'For test' } }
tagTypeMapping: { { tagType: 2, tagSet: 1.2.840.10003.14.2 } }
recordStructure: {
{ elementName: Author,
path: {{tagType: 2, tagValue: 2}},
required: true,
repeatable: true },
{ elementName: Name,
path: {{tagType: 2, tagValue: 2}, {tagType: 2, tagValue: 7}},
required: true,
repeatable: false },
{ elementName: Adress,
path: {{tagType: 2, tagValue: 2}, {tagType: 2, tagValue: 11}},
required: true,
repeatable: false },
{ elementName: Phone,
path: {{tagType: 2, tagValue: 2}, {tagType: 2, tagValue: 14}},
required: true,
repeatable: true },
{ elementName: Place,
path: {{tagType: 2, tagValue: 3}},
required: true,
repeatable: false
} }
}
14
схемы
для