Другие метаданные

Андрианов В.Ю., компания Esri CIS, e-mail: vandrianov@esri-cis.ru, web: www.esri-cis.ru

Othermetadata

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

Ни одна информационная инфраструктура не может существовать без метаданных. Автономная (пусть даже и многопользовательская) информационная система – может, а инфраструктура – нет. Различие между ними в том, что система, какой бы сложной она ни была, всегда предопределена. Инфраструктура же изменчива: со временем одни компоненты добавляются, другие удаляются, некоторые изменяются и т.д. Чтобы инфраструктура была обозрима и связна, ее компоненты должны документироваться и каталогизироваться.

Документирование данных с помощью метаданных – дело само по себе полезное и рекомендуемое даже для небольших систем. В больших распределенных информационных системах роль метаданных значительно возрастает, поскольку множество пользователей должны как-то сообщать друг другу о свойствах создаваемых одними и используемых другими наборов данных. Инфраструктура же вообще не может существовать без метаданных, поскольку она является совокупностью слабо связанных (loosely coupled) информационных систем, и при ее создании никто не знает, какие наборы данных будут создаваться и использоваться в инфраструктуре, кто их будет создавать, и кто будет использовать. Точно так же, как при создании библиотеки никто не знает, какие книги в ней будут храниться (ведь многие из них еще и не изданы), и кто их будет читать. А система описания и поиска ресурсов (т.е. каталог и средства работы с ним) – то, без чего ни библиотека, ни инфраструктура обойтись не могут. Каталог же содержит метаданные.

Если вы хоть немного интересовались геопорталами или инфраструктурой пространственных данных, то наверняка уже сталкивались с понятием метаданных. При упоминании этого слова практически всегда речь идет о метаданных наборов пространственных данных. В ArcGIS им соответствуют метаданные классов пространственных объектов. Состав этих метаданных определен международным стандартом ISO 19115 «Географическая информация. Метаданные» и соответствующим национальным профилем ГОСТ Р 52573 с таким же названием. О них мы уже писали и упоминали во многих статьях ArcReview, поэтому не будем здесь останавливаться на них подробно.

Однако это не единственный вид метаданных, который мы можем с пользой применять в работе с пространственной информацией. Существуют еще метаданные пространственных объектов (под пространственными объектами имеются в виду информационные сущности, а не физические объекты, описываемые этими сущностями). В терминологии баз данных им соответствуют метаданные уровня записи (feature level metadata). Как следует из названия, эти метаданные описывают отдельную запись, а не весь массив записей, каковым является набор данных. Состав метаданных уровня записи стандартами не регламентируется, отчасти потому, что процесс стандартизации еще не достиг этого уровня информационных систем, отчасти потому, что этот вид метаданных пока не представляет большого интереса для их (т.е. ИС) взаимодействия. Однако уже сейчас можно выделить несколько универсальных элементов, применимых в большинстве случаев. А поняв идею, вы сможете самостоятельно развивать это направление в вашей предметной области или в вашей конкретной системе.

Метаданные набора данных сообщают, кто и когда его создал, как его получить, какой он тематики, какую территорию охватывает, как часто обновляется и т.д. Аналогично, метаданные записи описывают, кто ее создал, когда, кто, когда и почему ее редактировал, каков ее текущий статус и др. Понятно, что в большинстве случаев нет смысла для каждой записи указывать, например, в какой системе координат приведено положение описываемого ей пространственного объекта, поскольку в «нормальных» ГИС все записи одного класса объектов должны быть в одной системе координат. То есть, если все записи обладают общим свойством, то оно должно представляться в метаданных этого набора данных. А в метаданных записей приводится информация, которая у разных записей набора может различаться.

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

Отсюда становится понятен смысл создания метаданных уровня записи. Они позволяют не только статично документировать элементы данных, что полезно для организации бизнес-процессов работы с данными. Более ценно то, что они позволяют добавить к данным исторический и динамический (временнóй) аспекты. Конкретные примеры используемых для этого полей метаданных сделают эту мысль очевидной.

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

Данный набор элементов позволяет описать, кто и когда создал конкретную запись в таблице, откуда он взял информацию, а также добавить любой не формализованный комментарий. Следует отметить, что первое поле идентифицирует пространственный объект (а не запись о нем) и, как таковой, не является элементом метаданных. Он только связывает пространственный объект со всеми записями о нем. Это ключевой (и в прямом, и в переносном смысле) элемент данных, без которого невозможно построить ни одну серьезную информационную систему. Некоторые СУБД поддерживают специальный тип полей «идентификатор», чтобы упростить процесс разработки и более эффективно контролировать целостность базы данных. Вообще, идентификатором может быть и целое число, и текстовая строка, и специальный код типа UUID или GUID. Но в любом случае он должен решать задачу однозначного определения объекта, который он идентифицирует. Для наших целей этого достаточно, а более подробное рассмотрение вопроса можно найти в книге А. Бакланова «Корпоративные ГИС», выпущенной компанией ДАТА+.

Остальные поля являются «настоящими» метаданными, т.е. характеризуют запись в базе данных, а не описываемый этой записью физический объект. Очевидно, что дата создания записи говорит только о том, когда информация об объекте реального мира была добавлена в базу данных. Сам же объект мог быть создан гораздо ранее, или даже и не создан еще, а только проектируется. Аналогично, создавший запись человек – не обязательно тот, кто создал описываемый ею объект (обычно это делают разные люди). Иными словами, метаданные нужны для обслуживания данных, в то время как данные нужны для обслуживания объектов реального мира. Вот пример того, как могут заполняться эти метаданные:

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

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

Функция документирования данных – не единственная, которую могут выполнять метаданные уровня записи. Другая возможная функция – поддержка временнóго аспекта данных. Вот пример соответствующего набора элементов:

Поля FromDate и ToDate указывают интервал, в течение которого информация записи соответствовала реальному состоянию физического объекта. В это время запись считается активной, что отражается в поле RecordStatus, имеющем значение Активно из домена кодированных значений RecordStatusCode. Когда состояние объекта меняется (например, эксплуатируемое устройство переводится в ремонт или обслуживание), вместо редактирования существующей записи создается новая. Старая запись при этом меняет статус на Устарело, и в поле ToDate проставляется дата изменения состояния. Когда устройство будет вновь введено в эксплуатацию, опять создается новая запись, а предыдущая становится неактивной. То есть, при каждом изменении реального объекта создается новая активная запись, а все неактивные записи об этом объекте позволяют восстановить его историю.

Можно заметить, что состояние активности записи нетрудно определить, сравнивая значение в полях FromDate и ToDate с текущей датой, однако поле RecordStatus может предоставить более широкую функциональность. Вот пример списка возможных значений для него (домен RecordStatusCode): В работе, Принято, Изъято, Заменено, Активно, Устарело. Эти значения позволяют смоделировать широкий спектр ситуаций работы с данными. Во время массового ввода данных, еще до их проверки, статус создаваемых записей будет В работе. После того, как данных проверены, их статус меняется на Принято. Если какие-то записи оказались некорректны, их можно не просто удалить или изменить, а присвоить им статус Изъято или Заменено. После создания новой, корректной записи эти старые данные сохранятся и, если их предоставляла подрядная организация, в вашей системе сохранятся и они, и новые корректные данные. В случае возникновения каких-то вопросов у вас всегда будет под рукой полная информация о том, как всё было изначально и в любой момент времени потом. Такая возможность весьма ценна для поддержки юридически значимых данных.

После завершения проверки данных и перевода учетной системы в режим эксплуатации, записи получают статус Активно. Теперь изменение состояния объектов учета сопровождается созданием новых записей и переводом старых в неактивное состояние (Устарело). Причина, по которой запись перестает быть активной, указывается в поле EditReason. Возможный перечень причин (домен EditReasonCode): Ошибка в данных, Объект изменился, Новая информация и др.

Нетрудно заметить, что такой подход позволяет вообще отказаться от удаления записей и даже от их изменения в части бизнес-данных, т.е. тех атрибутов, которые содержат характеристики объектов учета. Всякий раз, когда такое изменение нужно, создается новая запись, а момент изменения сохраняется в поле ToDate старой записи и поле FromDate новой записи. Вместо удаления записи мы действуем более гибко, меняя ее статус на Изъято или Устарело. Во всех случаях поле Comment позволяет сообщить дополнительные детали о том, почему мы тем или иным образом меняем статус существующей записи или создаем новую. Причем, если данные где-то когда-то расходятся с реальностью, это также может быть отражено в метаданных проблемных записей, и эта информация после исправления не будет потеряна.

Как и в первом примере, в словаре данных второго примера показаны элементы данных, не являющиеся метаданными, на этот раз среди них появилось поле EntityStatus. Оно приведено для иллюстрации того, что состояние записи – это вовсе не то же самое, что состояние описываемого ей объекта реального мира. Реальный объект может проектироваться, строиться, устанавливаться, эксплуатироваться, ломаться, ремонтироваться, обслуживаться, разрушаться и т.д. – все эти состояния перечисляются в домене EntityStatusCode. Данные же могут вводиться, проверяться, редактироваться, устаревать и т.д., что отражается в поле RecordStatus. Таким образом, EntityStatus позволяет отразить эволюцию реального объекта, а RecordStatus – эволюции информации о нем.

Внедрение предложенных элементов метаданных уровня записи имеет два интересных следствия. Во-первых, одному и тому же физическому объекту может соответствовать множество записей в таблице, различающихся статусом и датами. Это вовсе не означает нарушение правил нормальных форм, которые определяют отношения между записями в базе данных. Связь же между записями базы данных и реальными объектами может быть любой, и в данном случае отношение «один к одному» заменяется на отношение «один ко многим». Естественным первичным ключом в таблице будет уже не идентификатор объекта, а составной ключ, образованный идентификатором объекта и датами начала и конца действия записи. В результате мы получаем как бы еще одно измерение таблицы – временнóе. То есть, мы не просто фиксируем какие-то изменения в данных, но и сохраняем всю историю изменений как данных, так и описываемых ими объектов. Благодаря этому мы можем получить актуальную версию базы данных на любой момент времени в прошлом. И это второе следствие: вместо дискретных версий базы данных, которые создаются стандартными инструментами, мы получаем непрерывную версионность. Вместо номера версии у нас теперь момент времени. И если в обычном подходе после согласования версий различия между ними теряются, то в нашем случае все эти различия сохраняются и документируются. В итоге мы получаем мощный механизм развития модели данных, позволяющий реализовать целый ряд новых функций учетной системы.

Дальнейшее развитие методологии метаданных уровня записи можно найти в книге Дж. Батлера «Проектирование баз геоданных для транспорта», которая недавно была издана нашей компанией на русском языке. Хотя в названии фигурирует транспортная отрасль, многие рассматриваемые в книге вопросы имеют универсальное применение, как нетрудно заметить по приведенным примерам. Главным достоинством книги является детальное рассмотрение и обсуждение фундаментальных принципов в моделировании данных и предложение конкретных рецептов их реализации, а не просто инструкция «как построить ГИС для транспорта».

Представленный выше способ внедрения временнóго аспекта в данные – упрощенный вариант подхода, изложенного в книге Дж. Батлера. Обратившись к ее шестой главе «Редактирование данных», вы увидите, что показанный здесь набор элементов метаданных там существенно шире и позволяет реализовать еще одну важную функцию учетных систем корпоративного уровня – разделение редактируемой (рабочей) и публикуемой (используемой) версий базы геоданных. Потребность в этом вполне очевидна: в то время как специалисты по ведению базы данных постоянно вносят правки, потребителям нужна хоть какая-то стабильность, чтобы установленные ими связи с другими наборами данных не терялись из-за постоянных изменений. Выход простой – создать стабильную версию базы данных, в которой нет нарушений целостности, и которая не меняется в ходе текущей работы операторов базы данных. Тот же принцип применяется в разработке программного обеспечения: пользователи работают на одной и той же версии приложения, в то время как разработчики готовят новую версию. После завершения цикла разработки и тестирования, новая версия публикуется, и пользователи могут перейти на нее. То же самое и в случае с наборами данных. В течение переходного периода пользователи могут отслеживать и сообщать обо всех возникающих проблемах, и по его итогам разработчиками может быть выпущен пакет обновлений, устраняющих недостатки, замеченные пользователями в новой версии. То есть, вместо анархии постоянных изменений получается контролируемый цикл разработки и использования. Организовать такой цикл в процессах ведения и использования баз данных можно как раз на основе метаданных уровня записи, и в книге Дж. Батлера рассказано, как это сделать.

Кстати, вы можете заметить, что в предложенных здесь идеях нет ничего «пространственного»: все рассмотренные элементы метаданных – суть материя обычных баз данных, и «где же тут ГИС?» Такой вопрос был бы уместен в прошлом тысячелетии, когда ГИС были самостоятельным видом информационных систем, практически не интегрированным с другими их видами. С созданием технологии базы геоданных компания Esri изменила этот взгляд на ГИС, доказав, что пространственные данные – это только один из видов данных вообще, и общие принципы моделирования данных и построения информационных систем в равной степени применимы и должны применяться в геоинформатике.