Метаданные, metadata
-
(от греч. Meta и лат. Data), буквально переводится как "данные о данных", информация о другом наборе данных.
Метаданные - это структурированные, кодированные данные, которые описывают характеристики объектов-носителей информации, способствующие идентификации, обнаружению, оценке и управлению этими объектами.
Тема эта поднимается с тех пор, как существуют данные: метаданные были необходимы для описания значения и свойств информации с целью лучшего ее понимания, управления и использования. Классическим примером являются библиотеки. Книги (данные) можно классифицировать, управлять ими и находить только с помощью соответствующих метаданных (т.е. заголовка, автора и ключевых слов содержания).
Обычно под метаданными понимается любая информация, необходимая в IT для анализа, проектирования, построения, внедрения и применения компьютерной системы. В случае информационных систем метаданные особенно упрощают управление, создание запросов, полноценное использование и понимание данных. Многие недавние проекты, как научные, так и практические, направлены на изучение метаданных. Генерирование, хранение и управление метаданными помогают в поддержке использования огромных объемов информации, доступных в наши дни в любой электронной форме. Так как все, с чем работает компьютер, по сути является данными, и своего рода метаданные сопровождают любые данные, то это понятие имеет место быть в любой сфере приложений и принимает различные формы в зависимости от применения.
Метаданные Хранилища данных
Популярность Хранилищ данных в последние годы существенно возросла. Конкурентоспособные организации находятся на пути построения ХД либо расширения, перепроектирования и усовершенствования уже имеющихся. Метаданные считаются ключевым фактором успеха в проектах по внедрению Хранилищ. Они содержат всю информацию, необходимую для извлечения, преобразования и загрузки данных из исходных систем, а также для последующего использования и интерпретации содержимого ХД.
Метаданные систем Хранилищ данных иногда подразделяют на два типа:
служебные метаданные, используемые для функций извлечения, преобразования и загрузки, для переноса OLTP-данных (информации из транзакционных систем) в Хранилище;
интерфейсные метаданные, использующиеся для описания экранов и создания отчетов.
Ральф Кимболл (Ralph Kimball) перечисляет следующие типы метаданных в Хранилище:
метаданные исходной системы
спецификации источников данных, таких как репозитории;
описательная информация (например, частота обновления, юридические ограничения и методы доступа);
информация о процессах, таких как график заданий и коды извлечения.
метаданные преобразования данных
информация о получении данных (например, планирование передачи данных и результатов, а также сведения об использовании файлов);
управление таблицами измерений, например, определения измерений и присвоения суррогатных ключей;
преобразование и агрегирование, например, расширение и отображение данных, программы (скрипты) загрузки СУБД, определения агрегатов данных;
документирование проверок, работ и журналов, например: журналов преобразования данных и записей слежения за происхождением данных.
метаданные СУБД, такие как:
содержание системных таблиц СУБД;
рекомендации по обработке.
Роль метаданных в хранилище данных
Лучше всего объяснить суть метаданных, описывая их роль и назначение в реализации процессов ХД. Метаданные можно использовать тремя способами:
пассивно
, обеспечивая четкую документацию о структуре, процессе разработки и использовании системы ХД. Доступная документация необходима всем участникам (т.е. конечным пользователям, системным администраторам, а также разработчикам приложений);
активно
, путем хранения конкретных семантических аспектов (например, правил преобразования) в виде метаданных, которые можно интерпретировать и использовать во время исполнения. В этом случае процессы Хранилища данных управляются метаданными. А следовательно, код (т.е. активные метаданные) и дополнительная документация согласованно и унифицировано управляются в одном репозитории, при этом актуальность документации возрастает;
полуактивно
, за счет хранения статической информации (например, определений структур, спецификаций конфигураций), которую будет считывать другой программный компонент во время выполнения. Например, обработчикам запросов необходимы метаданные для проверки существования атрибутов. В отличие от активного использования, здесь метаданные только читаются, но не исполняются.
Создание и управление метаданными служит двум целям:
минимизации работ по разработке и администрированию ХД;
более эффективному извлечению информации из ХД.
Первая цель в основном относится к:
поддержке интеграции систем. Схемы и интеграция данных зависят от метаданных, описывающих структуру и смысл отдельных источников данных и целевых систем. Правила преобразования можно применить к исходным данным и хранить в качестве метаданных. Более того, интеграция различных инструментов возможна только тогда, когда они разделяют “данные”, которые в данном случае представляют собой метаданные системы Хранилища данных;
поддержке анализа и проектирования новых приложений. Метаданные повышают контролируемость и надежность процесса разработки приложений, обеспечивая информацию о смысле данных, их структуре и источниках. Более того, метаданные касающиеся решений по проектированию приложений, можно использовать повторно;
повышению гибкости системы и возможности повторного использования существующих программных модулей. Это возможно только для активного и полуактивного использования метаданных. Быстро изменяющиеся семантические аспекты явным образом хранятся в виде метаданных вне прикладных программ. Поддержка поэтому существенно проще. Систему можно расширить и адаптировать без всяких трудностей. Данный подход также дает возможность повторного использования “фрагментов кода”;
автоматизации административных процессов. Метаданные управляют запуском различных процессов ХД (например, загрузки и обновления). Информация об их исполнении (журналы доступа, количество добавленных в Хранилище записей и т.п.) также содержится в репозитории, легко доступном администратору;
усилению механизмов безопасности. Метаданные должны обеспечить правила доступа и пользовательские права для всей системы ХД. Управление доступом в Хранилище иногда требует применения сложных методов. Например, оперативный источник может содержать безобидную информацию об отдельных показателях работы компании, однако суммарные значения в Хранилище иногда оказываются важнейшим секретом. С другой стороны, персональные доходы каждого сотрудника являются тайной, но при этом итоговая сумма зарплат в ХД может вовсе не быть критической информацией.
Вторая цель относится к эффективному извлечению информации, а точнее к:
повышению качества данных. Качество данных определяется следующими характеристиками:
согласованностью (является ли представление данных однородным, нет ли дубликатов, данных с пересекающимися или конфликтующими определениями);
полнотой (все ли данные присутствуют);
точностью (совпадением хранимых и фактических значений);
своевременностью (актуально ли хранимое значение).
Правила проверки качества данных необходимо задать, сохранить в виде метаданных и проверять при каждом обновлении Хранилища. Кроме того, высокое качество требует поддержки контроля данных. Метаданные обеспечивают информацию о времени создания и об авторе данных, об источнике, значении данных в момент получения (о наследовании данных), и о дальнейшем пути от источника к текущему местоположению (data lineage — о происхождении данных). Таким образом пользователи могут восстановить цепочку, по которой проходят данные за время преобразования, и проверить точность возвращенной информации;
улучшению взаимодействия внутри системы ХД. Взаимодействие происходит как посредством выполнения простых запросов и отчетных приложений, так и с использованием сложных аналитических инструментов. Метаданные обеспечивают сведения о значении данных, терминологию и бизнес-концепции предприятия, а также их связь с данными. Поэтому метаданные повышают качество выполняемых запросов за счет более точной и строгой формулировки, а также сокращают расходы на пользователей, которым необходимы доступ, оценка и применение соответствующей информации;
улучшению анализа данных. Методы анализа данных представлены широко — начиная от простых приложений отчетности и OLAP и заканчивая сложными приложениями data mining. В этом направлении метаданные необходимы для понимания предметной области и ее представления в Хранилище, с тем чтобы адекватно применить и интерпретировать результаты;
применению общей терминологии и языка взаимодействия внутри корпорации. Доступность метаданных как уникального источника документации для пользователей имеет и другие преимущества. Она гарантирует согласованные средства взаимодействия и интерпретации информации из Хранилища. А также устраняет двусмысленность и обеспечивает согласованность сведений внутри компании, позволяет разделять знания и опыт.
Метаданные системы ХД содержатся в репозитории — структурированной системе хранения и извлечения, реализованной на основе СУБД. Для интерпретации метаданных необходимо хранить структуру репозитория (то есть схему метаданных) и их семантику.
Существуют различные способы определения и хранения метаданных в хранилище данных. Один из методов — использование технологии XML.
XML и метаданные
XML в наше время охватывает практически все аспекты информационных технологий. Что касается метаданных, то переоценить использование XML тут сложно, оно распространяется на множество приложений, в том числе и на Хранилища данных.
Основная функция XML - определять другие языки разметки. XML — это метаязык, а поэтому он оказывается очень эффективным форматом представления и обмена метаданными.
XML имеет множество преимуществ, которые делают его идеальным средством описания:
Он относительно понятен людям в чтении и написании (правда, чрезвычайно критичен к ошибкам). А следовательно, доступен новичкам и не вызывает страха.
Это открытая технология. Стандарт XML предложен W3C. Никто им не имеет прав собственности на этот язык. Он — платформо-независимый.
XML может применяться повсеместно. Анализатор XML можно найти везде, и, используя соответствующие инструменты, несложно сразу же внедрить эту технологию.
Язык гибок. Пожалуй, одна из главных причин использования XML в том, что нет четких рамок применения. Каждый самостоятельно решает, как использовать его в своем приложении.
XML недорог для внедрения как в большой, так и в малой организации.
Можно привести и иные причины использования XML, а не других средств. В первую очередь, структура метаданных часто бывает сложной, в ней множество вложенных отношений, а некоторые элементы метаданных могут повторяться. Во-вторых, если для хранения метаданных используется, например, РСУБД (реляционная система управления базой данных), то таблицы в базе не отражают сложных связей между элементами метаданных (трудно сгенерировать определения таблиц для описания отношений). И наоборот, XML задает структуру документа “самоописательным” образом. Его можно использовать для задания не только содержания, но и схемы. А следовательно, не сложно найти взаимосвязь между различными участками XML-документа.
XML позволяет публиковать метаданные, используемые любой программой или базой данных, в виде языка общения. XML обеспечивает связь между структурированной базой и неструктурированным текстом, передаваемым в формате XML. Так как XML позволяет задавать свой собственный язык разметки, то можно использовать все расширенные гипертекстовые возможности для хранения самих метаданных или ссылок в любом формате.
Если имеется программное обеспечение, которое может прочесть и расшифровать XML-файлы, то метаданные в любом Хранилище можно представить в виде обычного XML-файла, созданного на основе общего DTD (document type definition — описание типа документа).
Очевидно, что XML становится все популярнее в компаниях, так как решает задачи хранения и доступа к метаданным. Многие стремятся к созданию приложений управления метаданными по принципу повторного использования и обеспечения активного применения схем и DTD. Всем известно, что необходимо создавать стандарты и определения данных, классифицируемые по бизнес-функциональности. Очевидно, что XML надо использовать не потому, что это новая и популярная технология, но потому, что это правильный бизнес-выбор.
Однако кто же будет решать эти задачи? В большинстве организаций программисты, дизайнеры, интеграторы и менеджеры проектов “переступают” через XML-технологию и даже не вспоминают о том, что ее можно использовать для управления ресурсами данных. Не стоит удивляться, если вдруг в одном из XML-файлов, описывающих метаданные, обнаружатся проблемы: один и тот же атрибут пишется в разных местах по-разному, используются всевозможные стандарты именования полей, несогласованные форматы данных.
А что будет, если таких XML файлов окажется 1000, причем все они будут написаны в соответствии с разными стандартами? Вроде бы у современных грамотных специалистов этого не должно случиться. XML — открытый стандарт, в распоряжении специалистов есть DTD и схемы, и в нужный момент появятся необходимые инструменты. Но так ли это? Где же эти инструменты, стандарты, где профессионалы, решающие такие проблемы? Не похоже, что они занимаются написанием XML-кода.
Проблемы XML
А кто готов перед лицом руководства поставить следующие задачи, возникающие в XML-среде:
согласованный стиль тэгов;
непротиворечивые соглашения об именовании;
совместимые определения тэгов;
управление XML-объектами для их последующего повторного использования;
инструменты для динамической проверки DTD и схем;
документированные наборы кодов;
четко заданные пространства имен бизнес-модели.
Создание интеллектуальных парсеров XML, устойчивых к ошибкам, опечаткам в коде
Если найдутся такие энтузиасты, то XML-сообщество будет им признательно. Но смелость потребует немалых жертв в борьбе с руководством, которое стремится к краткосрочным целям и ждет скорых результатов. Однако, со временем метаданные будут признаны критически важным компонентом в инфраструктуре компаний, так же как и XML-стратегия.
Очевидно, что метаданные еще пять лет назад были в поле зрения большинства крупных компаний. Сегодня они на передовой линии XML-технологии, и это их лучшее место.
Кто есть кто
Майкл Брэкет (Michael Brackett) — признанный лидер в области обработки данных. Основатель справочного интернет-портала проектирования и моделирования ресурсов данных (Data Resource Design and Remodeling — http://members.aol.com/mhbrackett/). Работал координатором ресурсов данных штата Вашингтон, где разрабатывал общую архитектуру данных штата. Кроме того, занимался преподаванием проектирования и моделирования данных в Университете Вашингтона и написал пять книг по этой теме, в том числе “Проблема Хранилища данных: устранение хаоса данных” (The Data Warehouse Challenge: Taming Data Chaos). Занимает должность президента ассоциации DAMA International.
Адриен Танненбаум (Adrienne Tannenbaum) — президент консалтинговой компании Database Design Solutions (www.dbdsolutions.com), специализирующейся на восстановлении корпоративных данных. Является автором двух популярных книг о метаданных: “Решения для метаданных: использование метамоделей, репозиториев, XML и корпоративных порталов для генерации информации” (Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand) (2001, изд. Addison Wesley) и “Внедрение корпоративного репозитория” (Implementing a Corporate Repository) (1994, изд. Wiley).
Ральф Кимболл (Ralph Kimball) (ralph@kimballgroup.com) известен во всем мире как новатор, писатель, преподаватель, лектор и консультант в области Хранилищ данных.
Знаете ли Вы, в чем фокус эксперимента Майкельсона?
Эксперимент А. Майкельсона, Майкельсона - Морли - действительно является цирковым фокусом, загипнотизировавшим физиков на 120 лет.
Дело в том, что в его постановке и выводах произведена подмена, аналогичная подмене в школьной шуточной задачке на сообразительность, в которой спрашивается: - Cколько яблок на березе, если на одной ветке их 5, на другой ветке - 10 и так далее При этом внимание учеников намеренно отвлекается от того основополагающего факта, что на березе яблоки не растут, в принципе.
В эксперименте Майкельсона ставится вопрос о движении эфира относительно покоящегося в лабораторной системе интерферометра. Однако, если мы ищем эфир, как базовую материю, из которой состоит всё вещество интерферометра, лаборатории, да и Земли в целом, то, естественно, эфир тоже будет неподвижен, так как земное вещество есть всего навсего определенным образом структурированный эфир, и никак не может двигаться относительно самого себя.
Удивительно, что этот цирковой трюк овладел на 120 лет умами физиков на полном серьезе, хотя его прототипы есть в сказках-небылицах всех народов всех времен, включая барона Мюнхаузена, вытащившего себя за волосы из болота, и призванных показать детям возможные жульничества и тем защитить их во взрослой жизни. Подробнее читайте в FAQ по эфирной физике.
