Владимир Калачихин

Программное решение и схема данных

для представления библиотечно – библиографической информации в духе правил JSC Resource Description and Access (http://www.rda-jsc.org/rda.html), которые, в свою очередь, базируются на IFLA Functional Requirements for Bibliographic Records (http://www.ifla.org/VII/s13/frbr/frbr.htm)

Версия 2.1 от 9.11.2010

Цитаты из FRBR приведены по русскому переводу “Функциональные требования к библиографическим записям” под ред. Т. А. Бахтуриной и др., РГБ, Москва, 2006.

Цитаты из RDA приведены по официальной документации с сайта JSC RDA http://www.rda-jsc.org/rda.html

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



Введение

Реляционная схема данных построена по полностью инвертированной схеме и нормализована до третьей нормальной формы.

Схема включает в себя произвольный набор сущностей, поименованных как “объекты”. С каждым из “объектов” связан произвольный набор произвольных сущностей, поименованных как “атрибуты”. Атрибуты имеют возможность ссылаться на другие объекты и их атрибуты, организовывая таким образом “связи”. Смысловые ограничения, присущие предметной области, выражаются алгоритмически.

Объекты

FRBR предполагает наличие фиксированного списка типов объектов трёх ниже перечисленных групп:

Группа 1

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

Группа 2

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

Группа 3

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



В отличии от FRBR, в RDA типы собственно объектов не выделяются и не фиксируются. Вместо типов произведение, выражение, etc существуют некие domains, принадлежность объекта к которым определяется набором атрибутов. Атрибуты же, напротив, имеют тип, и RDA содержит обширный, однако не исчерпывающий перечень типов. Предполагается, что в дальнейшем список типов будет расширяться и изменяться.

Таким образом, не смотря на присутствие в RDA понятий произведение и выражение, отражения в схеме данных они не имеют, и объекты описываются только отношением

Объекты (Objects)

ObjectID INTEGER AUTO_INCREMENT PRIMARY KEY

Атрибуты

Перечень атрибутов объектов в FRBR является открытым:

“Авторы постарались сделать перечень атрибутов, включённых в модель, обширным, но не исчерпывающим.”

При этом имеется некоторый параллелизм в выразительных свойствах модели FRBR: некоторые связи между сущностями предметной области можно представить как через связи между объектами так и через атрибуты объектов:

“На первый взгляд некоторые атрибуты, определенные в модели, дублируют предметы интереса, которые были отдельно определены в модели как объекты и привязаны к объекту, о котором идет речь, через связи. “

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

В RDA эта проблема решается автоматически как следствие основополагающего принципа — все свойства объекта выражаются через его атрибуты. Значит, и связи — также выражаются соответствующими атрибутами. При этом такие тонкости FRBR, как связи между объектами “на обобщённом уровне” и на “конкретном уровне” (имеются в виду связи как-бы между классами и между экземплярами объектов) - опускаются.

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

Таким образом, отношение

Типы атрибутов (QualityTypes)

QualityTypeID INTEGER AUTO_INCREMENT PRIMARY KEY,

QualityTypeName VARCHAR(255),

QualityTypeDescription /* указания к применению */ TEXT,

QualityTypeHelper /* обработчик данных этого атрибута */ BLOB

имеет очевидные по смыслу поля.

Кроме этого, имеется поле QualityTypeHelper, в котором предлагается хранить программу — обработчик данных этого типа. Вся семантика предметной области должна выражаться совокупностью таких программ-обработчиков. Эта конструкция отражает идею RDA о том, что:

«For each element of descriptive data, RDA provides general guidelines and instructions that can be applied to any resource exhibiting the characteristic represented in that element. Where necessary, RDA specifies exceptions to the general guidelines and instructions that apply to specific types of media, content, mode of issuance, etc. »

По умолчанию обработчик отсутствует, и данные типа представляют собой (многострочный) текст.

Сами атрибуты объектов из отношения Объекты описываются отношением

Атрибуты объекта(ObjectQuality)

ObjectID INTEGER NOT NULL,

ObjectQualityID INTEGER AUTO_INCREMENT,

QualityTypeID INTEGER NOT NULL,

QualityValue BLOB,

ToObjectID INTEGER UNSIGNED default NULL,

ToObjectQualityID INTEGER UNSIGNED default NULL

Предполагается, что все атрибуты имеют один тип — "большой двоичный объект" (BLOB). Поле такого типа позволяет хранить любые объекты, а во многих СУБД этот тип трактуется как TEXT, если в поле хранятся текстовые данные.

Механизм образования связей атрбута объекта с другими сущностями представлен полями ToObjectID и ToObjectQualityID. Они позволяют выразить ссылку на другой объект и другой атрибут того же или другого объекта.

Особенности реализации и методические решения

FRBR предполагает, что связи между сущностями однонаправленные, но парные. Например: определена связь произведение выражено через выражение, и связь выражение является выражением произведения. В общем-то, если существует одна связь, то должна быть и другая, однако в FRBR и RDA нигде не сказано, что это обязательно. Вместе с тем в реляционной модели нет возможности явным образом выразить двунаправленные или парные связи. Поэтому принято решение выделить "главное" направление связей, а противоположное поддерживать по мере необходимости. Исследование показало, что поддержание связей в направлении потомокпредок в классификационных системах, и экземплярвоплощениевыражениепроизведение в "книгах" менее трудоёмко. Таким образом, поле ToObjectID в отношении Атрибуты объекта содержит, как правило, ObjectID предка.

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

Таким образом, ссылка на автора является атрибутом произведения, а связь частей многотомника с многотомным произведением — атрибутом частей.

Проблемы

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

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

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



Заключение

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

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

Такая гибкость в обращении с хранящимися данными способствует продлению срока их жизни, однако заметно усложняет организацию их повседневного использования. Однако это усложнение может быть преодолено, если считать, что первичная организация связей, типов атрибутов и их наборов (т.е., первичная организация использования данных) есть задача разработки программного комплекса. Более того, могут существовать клиентские (по отношению к базе данных) приложения, которые жёстко фиксируют взгляд на логическую структуру базы данных. Таким приложением может быть, например, Z39.50-сервер, SRU-сервер или другое приложение, отдающее библиографические записи в формате MARC.

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