Роман Чернышев, 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
Атрибут-ссылка на другой документ. На физическом уровне это
соответствует полю, которое является внешним ключом на главную таблицу другого
класса. При описании документа типа
Назначение атрибутов 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 .
Про Мета-Базу
Пишет Леонид (не проверено),
Сергей . Направление у вас ЯВНО в ту же сторону , что и у меня ! Можете глянуть Screen-shorts с моей Мета-Базы, которая является "надстройкой" над обычной СУБД ( Oracle) у нас на ММК --> https://picasaweb.google.com/Leonid.Otot...
Да, похоже
Пишет st,
Да, похоже. Видимо, все реализации метаданных более-менее похожи, потому что делают их с одними и теми же целями: создать метамодель, с помощью которой управлять структурой и поведением. Ко всему этому близко MDA (Model Driven Architecture), как обобщаюший метод.
P.S. Это не моя статья, бывшего коллеги. У меня тоже были опубликованные примеры, смотрите по тегу MDA: http://www.arbinada.com/taxonomy/term/70