Часть 7. Метаданные - наше все

Фактически все, что нас окружает, можно отнести к метаданным. Метаданные служат для описания объектов. В одной из книг по Data Mining [1] я обнаружил точное объяснение, которое показывает различия между понятиями “информация” и “данные”. “Информация, в отличие от данных, имеет смысл”. Проведем аналогию на примере с метаданными.

В чем отличие данных от знания? Данные - это всего лишь информация об объекте, тогда как знания - это то, что позволяет использовать данные. БД - это всего лишь данные, тогда как знания получаются, когда понятна структура метаданных в БД. Очень часто при работе начинаешь восстанавливать структуру метаданных, а только потом делать основную работу.

Необходимо понимать ценность метаданных. Любой специалист, работая в любой области имеет свой набор метаданных, которые описывают схему его действий. Одной из самых больших сегодняшних проблем для российских компаний является то, что описанию метаданных не уделяют достаточного внимания. При увольнении одного из значимых специалистов происходит почти полная потеря слоя метаданных, который в некоторых случаях может оказаться просто невосстановим. Первое, с чем сталкивается новый работник - это реставрация утерянного слоя, в котором предстоит работать. Интересно, что самым значимым метаданным слоем считается слой руководителя, ведь только он обладает незаменимыми знаниями. Работая аналитиком в разных компаниях я старался создавать такой слой или пытался доказывать, что этот слой просто необходим для дальнейшего роста компании. Эта мысль кратко выражается во фразе: метаданные - наше все.

При проектировании БД строят ER диаграммы для того, чтобы извлекать необходимую информацию об объектах. По логике вещей любые диаграммы (ДРАКОН, схемы-алгоритмы, UML, SADT ….) - это всего лишь набор метаданных, которые используются людьми для получения знаний из данных или БД. Для того, чтобы описать слой метаданных (например, таблицы, проекты) используют язык xml. Язык этот очень простой (похож на HTML) и используется повсеместно от хранения информации до описания алгоритма обработки. Могу высказать только одно предположение: на этом языке сегодня можно описать практически любую сложную модель. Известный пример использования языка xml для пользователей - формат Excel 2007 и последующие.

Применительно к аналитике на языке xml описывают структуры OLAP кубов, системы разделения информации, запросы к системам аналитики, схемы функционирования систем аналитики, схемы функционирования БД, схемы представления и движения информации и т.д.

В двух системах (MS SQL сервер и Pentaho CE) информация о структуре кубов хранится в xml виде (думаю, что и в других система все хранится так же в xml). Теперь осталось разобраться со структурой информации, которая описывает модели OLAP куба (кстати, можно вспомнить, что был специально разработан протокол XML/A для аналитики).

XML Структура OLAP куба для системы аналитики Pentaho CE

<?xml version="1.0" ?>
- <Schema name="SampleData">
- <!--
 Shared dimensions
  -->
- <Dimension name="Region">
- <Hierarchy hasAll="true" allMemberName="All Regions">
  <Table name="QUADRANT_ACTUALS" />
  <Level name="Region" column="REGION" uniqueMembers="true" />
  </Hierarchy>
  </Dimension>
- <Dimension name="Department">
- <Hierarchy hasAll="true" allMemberName="All Departments">
  <Table name="QUADRANT_ACTUALS" />
  <Level name="Department" column="DEPARTMENT" uniqueMembers="true" />
  </Hierarchy>
  </Dimension>
- <Dimension name="Positions">
- <Hierarchy hasAll="true" allMemberName="All Positions">
  <Table name="QUADRANT_ACTUALS" />
  <Level name="Positions" column="POSITIONTITLE" uniqueMembers="true" />
  </Hierarchy>
  </Dimension>
- <Cube name="Quadrant Analysis">
  <Table name="QUADRANT_ACTUALS" />
  <DimensionUsage name="Region" source="Region" />
  <DimensionUsage name="Department" source="Department" />
  <DimensionUsage name="Positions" source="Positions" />
  <Measure name="Actual" column="ACTUAL" aggregator="sum" formatString="#,###.00" />
  <Measure name="Budget" column="BUDGET" aggregator="sum" formatString="#,###.00" />
  <Measure name="Variance" column="VARIANCE" aggregator="sum" formatString="#,###.00" />
  </Cube>
  </Schema>

 

В качестве примера приведем несколько тегов, которые очень просто понять:

  • <Cube> - это тег, описывающий куб в целом.
  • <Dimension> - это тег, описывающий измерения куба.
  • <Hierarchy> - это тег, описывающий правила иерархии данных в кубе.
  • <Level> - это уровень иерархии.
  • <Measure> - это меры (сами данные, по которым проводятся операции, допустимые на множестве, например, суммирование).

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

Ссылки и литература:

  1. Чубукова И. А. Data Mining. Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний - 2-е изд., испр. - М.: 2008
  2. Можно пройти курс Чубуковой И.А. в Национальном Открытом Университете «ИНТУИТ». Название курса - Data Mining. Когда-нибудь я сам хочу пройти этот курс.
  3. Pentaho metadata editor http://wiki.pentaho.com/display/ServerDoc1x/Pentaho+Metadata+Editor
  4. Метаданные и их место в Хранилище. Представление метаданных с помощью XML http://www.iso.ru/print/rus/document6148.phtml
Подробности
Опубликовано: 01 Сентябрь 2013
Просмотров: 3855
   
   
© BIWED.RU