Хранилище Метаданных (Репозиторий)

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

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

Широко известны Репозитории, входящие в состав популярных САSE-средств (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA Research)), систем разработки приложений (Developer 2000 (Oracle), Power Builder (Sybase)), администрирования и поддержки информационных систем (Platinum, MSP). Все они, однако, решают частные задачи, работая с ограниченным набором метаданных, и предназначены, и основном, для облегчения труда профессионалов — проектировщиков, разработчиков и администраторов информационных систем.

Репозиторий метаданных СППР на основе ХД предназначен не только для профессионалов, но и для пользователей, которым он служит в качестве поддержки при формировании бизнес-запросов. Более того, развитая система управления метаданными должна обеспечивать возможность управления бизнес-понятиями со стороны пользователей, которые могут изменять содержание метаданных и образовывать новые понятия по мере развития бизнеса. Тем самым Репозиторий превращается из факультативного инструмента в обязательный компонент СППР и ХД.

Разработка системы управления метаданными сходна с разработкой распределенной транзакционной системы. При ее создании необходимо решать следующие задачи:

• анализ процессов возникновения, изменения и использования метаданных;

• проектирование структуры хранения метаданных (например, в составе реляционной базы данных);

• организация прав доступа к метаданным;

• блокировка и разрешение конфликтов при совместном использовании метаданных (что очень часто возникает при изменении общих бизнес-понятий в рампах структурного подразделения);

• разделение метаданных между Витринами Данных;

• согласование метаданных ХД с Репозиториями САSE-средств, применяемых при проектировании и разработке Хранилищ;

• реализации пользовательского интерфейса с Репозиторием.

Опыт реализации управления метаданными показывает, что основная трудность состоит не в программной реализации, а в определении содержания конкретных метаданных и методики работы с ними, в практическом внедрении Репозитория. Кроме того, если подходить к проектированию итерационно, последовательно переходя от разработки соответствующих бумажных форм и методик к созданию CASE-модели метаданных, от централизованной к распределенной модели, используя в качестве системы для хранения метаданных промышленную реляционную СУБД, можно значительно упростить задачу.

Поскольку большинство СASE-средств использует различные форматы метаданных, поставщики систем управления метаданными выработали стандарт обмена MDIS, обеспечивающий возможность интеграции CASE-средств в СППР на основе ХД. К сожалению, не все предлагаемые сегодня на российском рынке продукты соответствуют этому стандарту, поэтому преобразование форматов метаданных представляют собой достаточно сложный процесс, упростить который призваны специализированные программные продукты, в том числе, например, средства фирмы Evolutionary Technologies International или Prism Solutions (Data Warehouse Directory).

По завершении разработки структуры метаданных и системы управления ими, решается задача заполнения и обновления данных в ХД.

Загрузка Хранилища

При заполнении ХД необходимо определить спектр задач, которые будут решаться с его помощью и круг пользователей.

При описании технологии заполнения Хранилища различают три взаимосвязанные задачи:

• Сбор Данных (Data Acquisition),
• Очистка Данных (Data Cleansing) и
• Агрегирование Данных (Data Consolidation).

 

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

1. поддерживаются интерфейсы всех крупных производителей серверов баз данных (Oracle, Informix, ADABAS и т. д.);

2. практически всегда имеется ODBC-интерфейс;

3. можно извлекать данные из текстовых файлов в формате CSV (comma separated values) и из некоторых структурированных файлов, например файлов dBase.

Набор имеющихся интерфейсов — важнейшая характеристика, которая часто позволяет оценить, для каких задач проектировался продукт. Так, если среди поддерживаемых интерфейсов имеются AS/400, 052/400, IMS, VSAM (как в популярном продукте PASSPORT фирмы Carleton), то он предназначен скорее для использования в системах, работающих на больших мэйнфреймах, чем в сети из ПК. Несколько иной набор интерфейсов предлагает, например, хорошо известный продукт InfoPump фирмы PLATINUM Technology, который обеспечивает поддержку LotusNotes, Microsoft Access, dBase и работу с текстовыми файлами. Крупные производители серверов либо имеют собственные средства сбора данных, либо устанавливают партнерские отношения с производителями таких средств и разрабатывают инструментарий промежуточного уровня для тиражирования «чужих» данных (таков, например, Replication Server фирмы Sybase).

 

 

 

 

 

Рис. 1.8. Склад данных с простой архитектурой клиент-сервер

 

Второй аспект процесса сбора данных, который автоматизирован в некоторых продуктах, - это организация процесса пополнения Хранилища. В том же InfoPump, например, имеется возможность строить расписание пополнения Хранилища данными либо на временной основе, либо с использованием механизма событий. Имеются и более сложные программные комбинации, например корпорация Software AG разработала собственное решение для сбора и очистки данных, называемое, SourcePoint,, которое на нижнем уровне использует PASSPORT, а функции организации расписаний реализует как надстройку над этим нижним уровнем. Помимо этого SourcePoint реализует параллельные извлечение, передачу данных и заполнение Хранилища.

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

Агрегация – отношение «часть - целое».

При заполнении Хранилища агрегированными данными мы должны обеспечить выборку данных из транзакционной базы данных и других источников в соответствии с метаданными, поскольку агрегирование происходит в терминах бизнес-понятий. Так, например, агрегированная величина «объем продаж продукта Х в регионе Y за последний квартал» содержит понятия «продукт» и «регион», которые являются бизнес-понятиями данного предприятия. Следует подчеркнуть, что задача выборки необходимых данных не может быть решена полностью автоматически: возможны коллизии (отсутствие необходимых данных, ошибки в данных и т. п.), когда вмешательство человека окажется необходимым. Далее, предполагая, что объектом анализа являются числовые показатели, связанные с бизнес-понятиями, такие как ОБЪЕМ ПРОДАЖ или ПРИБЫЛЬ, когда необходимо определить правила вычисления этих показателей для составных бизнес-понятий, исходя из их значений для более простых бизнес-понятий. Это и есть правила агрегирования.

Простейшей архитектурой системы на основе ХД является архитектура клиент-сервер. Традиционно само хранилище размещается на сервере (или на серверах), а анализ данных выполняется на клиентах. Некоторое усложнение в эту схему вносят Витрины Данных. Они также размещаются на серверах, но, учитывая взаимодействия между Витринами, приходится вводить так называемые переходники ( Hub Servers ), через которые идет обмен данными между Витринами.

Переход к базам данных клиент-сервер – относительно небольшой скачок в развитии хранилища данных. На рис. 1.8 и 1.9 показаны две альтернативные архитектуры хранилища данных, основанные на современной модели клиент-сервер.

На рис. 1.8 приложение EIS, написанное на языке Xbase осуществляет доступ к централизованному SQL-хранилищу данных посредством прикладного программного интерфейса ODBC. В такой среде довольно легко реализовать простейшую модель клиент-сервер, где один сервер обслуживает несколько клиентов.

На рис. 1.9 представлен более сложный вариант архитектуры клиент-сервер.

Доступ к логически централизованному на множестве платформ, осуществляется так же, как и в примере на рис. 1.8. Однако внутри хранилища данных для доступа к его распределенным компонентам применяется комбинация интерфейсов IDAPI и DRDA API. В таком случае приложение, выполняющееся над хранилищем данных, выступает в двоякой роли: как сервер для комплекса приложений EIS и как клиент, запрашивающий информацию у других серверов хранилища данных.

 

 

 

 

 

 

 

 

 

IDAPI

 

IDAPI

 

 

DRDA

 

 

Рис.1.9. Распределенный склад данных со сложной архитектурой клиент-сервер

 

Словарь

 

Мультиплексирование

Multiplexing

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

 

⇐ Предыдущая1234567

Поделиться: