Словарь метаданных документно-ориентированной информационной системы

Роман Чернышев, 2001

Назначение

Словарь метаданных (CM или Metadata dictionary, MD) служит для связи объектов предметной области (документов) со структурой их хранения в БД. Любой тип документа, используемый в системе, должен быть описан в СМ до начала его использования приложениями. На базе словаря строятся другие базовые службы системы, такие как служба разграничения прав доступа к документам и/или их атрибутам и учетная схема.

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

Устройство

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

Рис. 1 Концептуальная модель MD.

Сущность NodeType содержит полный перечень возможных типов узлов СМ.

Атрибут

Назначение

TypeID

Primary Key

Tag

Код

Name

Название для UI

Сущность MD представляет собой собственно реестр классов документов и их атрибутов.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя.

TypeID

Тип узла

Name

Название для UI

Tag

Кодовое название

SchemaName

Название схемы владельца объекта

TabName

Название таблицы (или пакета для узлов типа NT_METHOD)

ColName

Название колонки или процедуры

RefLink

Для атрибута-ссылки ID узла в CM c описанием типа документа

Note

Комментарий

Типы узлов и их назначение

Ниже приведен перечень всех возможных типов узлов и описание их назначения. Типы узлов заносятся в таблицу при установке системы и не изменяются в процессе эксплуатации системы.

NT_DOC

Узел типа NT_DOC является корневым в описании класса документа. Узлы NT_DOC могут располагаться только на нулевом уровне иерархии (ParentID is NULL) и не могут содержать в себе другие узлы этого же типа. Все дочерние узлы интерпретируются как атрибуты данного класса документов. В колонках SchemaName, TabName должно содержаться имя главной таблицы класса. Главной считается таблица, в которой содержится атрибут или атрибуты составляющие первичный ключ (идентифицирующий атрибут).

Назначение атрибутов MD при описании узла NT_DOC.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NULL.

TypeID

1

Name

Название класса документов.

Tag

Кодовое имя класса

SchemaName

Название схемы владельца главной таблицы класса.

TabName

Название главной таблицы документа.

ColName

Не используется, всегда NULL.

RefLink

Не используется, всегда NULL.

Note

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

NT_KEY

Узел является идентифицирующим атрибутом (PRIMARY KEY) или его частью. Может быть вложен в узлы типа NT_DOC, NT_COMPOUND и NT_DETAIL. На сегодняшний день в системе принята политика формирования суррогатных ключей для всех сущностей, поэтому, скорее всего каждый класс документов будет иметь только один атрибут NT_KEY. По той же причине, атрибуты типа NT_KEY не должны выносится на уровень пользовательского интерфейса. Не может содержать дочерних узлов.

Назначение атрибутов MD при описании узла NT_KEY.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL и содержит ссылку на узел типа NT_DOC, NT_COMPOUND, NT_DETAIL

TypeID

2

Name

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

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца главной таблицы класса.

TabName

Название главной таблицы документа.

ColName

Название колонки являющейся первичным ключом.

RefLink

Не используется, всегда NULL.

Note

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

NT_PARENTKEY

Узел является вторичным ключом-ссылкой на родителя. Используется для документов, имеющих иерархическую структуру хранилища. В качестве примера может быть приведена сущность MD, в которой колонка ParentID является как раз таким ключом. Узлы этого типа могут быть вложены только в узлы типа NT_DOC. Так же как и NT_KEY, узлы этого типа служат только для описания структуры хранилища и не предназначены для использования на уровне пользовательского интерфейса. Не может содержать дочерних узлов.

Назначение атрибутов MD при описании узла NT_PARENTKEY.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL и содержит ссылку на узел типа NT_DOC

TypeID

3

Name

Не используется.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца главной таблицы класса.

TabName

Название главной таблицы класса.

ColName

Название колонки являющейся внешним ключом.

RefLink

Не используется, всегда NULL.

Note

Не используется.

NT_DATA

Атрибут, содержащий данные базового типа (NUMERIC, VARCHAR…). Не может содержать дочерних узлов.

Назначение атрибутов MD при описании узла NT_DATA.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

6

Name

Название атрибута для UI.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца таблицы.

TabName

Название таблицы.

ColName

Название колонки соответствующей атрибуту.

RefLink

Не используется, всегда NULL.

Note

Комментарий.

NT_NAME

Частный случай NT_DATA, используется для маркировки атрибута в качестве идентифицирующего документ на уровне пользовательского интерфейса, например, при построении списка документов данного класса. В качестве примера можно привести атрибут ‘Название’ существующий в большинстве классов. Не может содержать дочерних узлов.

Назначение атрибутов MD при описании узла NT_NAME.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

4

Name

Название атрибута для UI.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца таблицы.

TabName

Название таблицы.

ColName

Название колонки соответствующей атрибуту.

RefLink

Не используется, всегда NULL.

Note

Комментарий.

NT_REF

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

Назначение атрибутов MD при описании узла NT_REF.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

5

Name

Название атрибута для UI.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца таблицы.

TabName

Название таблицы.

ColName

Название колонки FK соответствующей атрибуту.

RefLink

Заполняется NodeID узла типа NT_DOC c описанием класса, на который ссылается атрибут.

Note

Комментарий.

NT_COMPOUND

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

Назначение атрибутов MD при описании узла NT_COMPOUND.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

7

Name

Название атрибута для UI.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца подчиненной таблицы.

TabName

Название подчиненной таблицы.

ColName

Не используется, всегда NULL

RefLink

Не используется, всегда NULL

Note

Комментарий.

NT_DETAIL

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

Назначение атрибутов MD при описании узла NT_DETAIL.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

8

Name

Название атрибута для UI.

Tag

Кодовое имя атрибута

SchemaName

Название схемы владельца подчиненной таблицы.

TabName

Название подчиненной таблицы.

ColName

Не используется, всегда NULL

RefLink

Не используется, всегда NULL

Note

Комментарий.

NT_METHOD

Описывает методы класса. Предусмотрены два типа методов:

  • хранимые, реализуются в виде функций и процедур в пакетах PLSQL
  • абстрактные, реализуются приложением

Для хранимых методов в колонках SchemaName, TabName и ColName указываются названия схемы содержащей пакет, название пакета и название процедуры соответственно. Описание абстрактного метода должно содержать NULL во всех трех колонках.

Назначение атрибутов MD при описании узла NT_METHOD.

Атрибут

Назначение

NodeID

Идентификатор узла, PRIMARY KEY

ParentID

Идентификатор узла-родителя, всегда NOT NULL.

TypeID

9

Name

Название метода для UI.

Tag

Кодовое имя метода

SchemaName

Название схемы владельца пакета или NULL для абстрактного метода.

TabName

Название пакета или NULL для абстрактного метода.

ColName

Название функции или NULL для абстрактного метода.

RefLink

Не используется, всегда NULL

Note

Комментарий.

Зависимые объекты

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

При назначении прав на узел MD, права на связанные объекты по умолчанию выдаются в соответствии со следующей таблицей:

Привилегия на узел MD/Тип объекта

S

U

I

D

E

Table

S

U

I

D

S

View

S

S

S

S

S

Procedure

-

E

E

E

E

Существует возможность изменения такого поведения путем установки соответствующих значений в таблице PMap(privilege map).

Комментарии

Изображение пользователя pater_leo.

Есть предложение по развитию этой темы

Сергей.
Похоже, мы оба Ораклоиды :-)
Есть предложение по дальнейшему развитию метамодели Oracle.
Для начала можно глянуть направление в моей статье "To keep abreast of the 21st Century"
http://www.ototsky.mgn.ru/it/21abreast.htm
Подготовлю несколько скрин-шотов с комментариями на русском

Изображение пользователя st.

Не совсем

На совсем "ораклоид", скорее "базоданщик" :) С ораклом я работаю только на уровне интеграции, как основное средство не пользую, оставаясь в основном на MS SQL, Postgres и даже Access в качестве локального движка. Вот автор статьи (Роман Чернышев) более плотно работал с ораклом.

Что касается метаданных, то тема меня давно интересует, как обширная часть еще более общей темы под названием "разработка от модели" (model-driven). Небольшие описания реализаций есть вот здесь:

Изображение пользователя pater_leo.

Сергей, Почитал

Сергей,
Почитал статьи . Направление правильное.
Пишу комментарии мылом.
Это сейчас очень актуальное направление в рамках нового поколения Web - SemanticWeb,
которое является "горячей точкой" OMG - Object Management Group .

Изображение пользователя st.

Да, похоже

Да, похоже. Видимо, все реализации метаданных более-менее похожи, потому что делают их с одними и теми же целями: создать метамодель, с помощью которой управлять структурой и поведением. Ко всему этому близко MDA (Model Driven Architecture), как обобщаюший метод.

P.S. Это не моя статья, бывшего коллеги. У меня тоже были опубликованные примеры, смотрите по тегу MDA: http://www.arbinada.com/taxonomy/term/70