Пример 1. Метатаблица TABLES

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

Следует отметить, что в последние годы в публикациях и разработках, особенно на тему геоинформационных систем (ГИС), под метаданными понимаются только вспомогательные, справочные сведения, данные о происхождении данных. Такое сужение термина вряд ли имеет смысл, так как приставка «мета-» во всех областях знаний имеет устоявшийся смысл «сверх-». Термином «сверх-данные» можно с полным правом именовать любые данные более высокого уровня, любые «данные о данных», а не только справочно-реферативные. В данной статье термин «метаданные» применяется именно в таком широком смысле. В первую очередь, однако, речь пойдет о системных данных.

Ключевые поля

Общим для метаданных разных разработчиков, как правило, является отказ от описания связей в виде отдельной таблицы (REFERENCES/CONSTRAINTS «больших» СУБД). Действительно, для описания простой структуры она не является необходимой. Например, в схеме С. А. Виноградова хорошо показано, как можно обойтись без REFERENCES, описывая связь как свойство атрибута в таблице COLUMNS [1]. Для атрибута исходной таблицы (источника), являющегося внешним ключом (foreign key) указывается ссылка на целевую таблицу. Со стороны целевой таблицы, само собой разумеется, связь опирается всегда только первичный ключ (Primary Key). При необходимости нетрудно создать запросом представление REFERENCES, включающее обычные для таких представлений колонки Source.Table, Source.Column, Target.Table, Target.Column и тип связи — «один-к-одному» или «один-ко-многим». В таком варианте схема, разумеется, ограничивает связи одинарными.

Вряд ли возможно описать составные связи, не выделяя сущность «связь» в отдельную таблицу. Но так ли уж связи необходимы именно составные? Практика свидетельствует, что не сложно обойтись и без них. В последнее время все шире применяется принцип построения системы на одинарных связях, использующих искусственные первичные ключи (ИК) [2]. Как правило, ИК имеют целочисленный тип, и популярны благодаря механизму уникальной автонумерации. С помощью ИК действительно удается построить систему практически любой сложности.

Однако естественный ключ, тем не менее, сохраняет свое значение и жизненно важен для любой таблицы, как средство контроля соответствия данных предметной области. Набор естественных ключей должен быть взаимоувязан, тогда он образует каркас системы, обеспечивая естественный порядок и поддерживая «предметную» целостность в дополнение к чисто «логической». Если система не замкнута, то есть активно общается с предметной областью, постоянно получает новые данные, то только естественный ключ поможет правильно их идентифицировать. Поскольку роль первичного ключа, как правило, занимает ИК, то естественный ключ таблицы должен быть реализован как уникальный индекс. В связи с этим далее для него применяется сокращение «ЕИ». По идее К. Дейта [3] и ИК и ЕИ — потенциальные ключи, равноправные с точки зрения таблицы. С точки зрения системы ИК «назначен» первичным для простоты организации связей.

Описание ЕИ должно присутствовать именно в метаданных, если система претендует на соответствие реляционной модели. Это практически не усложняет схему. В простом варианте ЕИ может быть одинарным, но обычно строки в таблице идентифицируются однозначно только по набору атрибутов. Такой набор обычно называется составным (или композитным) ключом (уникальным индексом). Описать составной ЕИ несложно, если условиться, что в таблице он будет один. Можно предназначить для этого логическую колонку СUnique в таблице атрибутов ATTRIBUTES, и определить, что все помеченные атрибуты в пределах одной таблицы составляют ЕИ этой таблицы (далее колонки таблицы ATTRIBUTES называются просто «колонками», во избежание путаницы между атрибутами метаданных и атрибутами основной БД).