Введение

По сравнению с бумом 70 — 90-х гг. сегодня, в начале XXI в., меняется парадигма исследований по проблемам интеллектуализации компьютеров и информационных систем на их основе, а именно: Не считаются фундаментальными проблемы поиска антропоморфных методов и алгоритмов вывода знаний, поскольку их место занимают исследования методов представления существующих знаний об объекте (предметную область использования компьютеров) и результатов интеллектуального анализа данных его фактической деятельности и интерактивного вывода новых знаний.

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

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

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

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

1. Концепция и понятие витрин данных

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

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

Витрины данных призваны улучшить время отклика для конечного пользователя, позволяя пользователям иметь доступ к определенному типу данных, таким образом, что поддерживает коллективные запросы группы пользователей.

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

 

Витрина данных существенно меньше по объему, чем корпоративное хранилище данных, и для ее реализации не требуется слишком мощная вычислительная техника.

Концепция витрин данных была предложена Forrester Research еще в 1991 году. По мнению авторов, она, как огромное количество тематических БД, где содержится информация, касающаяся отдельных аспектов деятельности организации, должен стать реальной альтернативой хранилищам данных [2].

Концепция витрин данных имеет ряд несомненных преимуществ:

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

И именно витрины данных (или что-то очень близкое к ним) имел в виду Э. Кодд, когда использовал термин «OLAP Server» [3].

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

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

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

Возникновение термина ИАД, а также его синонимов «Data Mining (Раскопки данных)», «Knowledge Discovery (Открытие новых знаний)», связано с решением проблемы интуитивного проявления непроявленной информации деятельности, определение и обоснование на основе ее анализа необходимости и содержания реорганизации действующей системы. Звонок прозвенел, когда стало ясно, что для нахождения стратегии разумного поведения необходимо иметь возможность вдумчивого просмотра как единого целого больших объемов показателей исторической деятельности с целью выявления новых зависимостей между значениями параметров-показателей, тенденций и закономерностей развития и упадка связей между ними . На этой основе происходит обработка (проектирование и тестирование) мероприятий реинжиниринга.

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

Традиционная прикладная статистика — «Какие средние показатели травматизма для курящих и некурящих?».

Интеллектуальный анализ данных — «Встречаются точные шаблоны описаний людей, характеризующих их способность к повышенному травматизму?».

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

2. Особенности использования витрин данных при многоуровневых решений в хранилищах данных

В большинстве случае ВД (витрина данных) — это аналитическая структура, которая обычно поддерживает область работы одного приложения, бизнес-процесса или отдела.

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

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

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

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

Глобальное хранилище данных. В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать хранилище данных как единственный источник интегрированных данных для всех витрин данных. Тогда естественной становится такая трехуровневая архитектура системы:

• на первом уровне реализуется корпоративное хранилище данных на основе одной из развитых современных реляционных СУБД. Это хранилище интегрированных в основном детализированных данных. Реляционные СУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не полностью отвечают потребностям OLAP-систем, в частности в связи с требованием многомерного представления данных;
• на втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В таком случае это и не нужно, поскольку речь идет о витрины данных. Заметим, что витрину данных не обязательно необходимо полностью сформировать. Она может содержать ссылки на хранилище данных и подбирать оттуда информацию по мере поступления запросов.
• на третьем уровне находятся клиентские рабочие место конечных пользователей, на которых устанавливаются средства оперативного анализа данных.

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

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

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

Часто в процессе создания СД предусматривается разработка прототипа — небольшой системы для демонстрации пользователю новые возможности, чтобы он, испытав систему в действии, оценил: стоит ли продолжать разработку, или отложить его на будущее.

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

В 2005-2010 годах, как считают эксперты известной консалтинговой фирмы Meta Group, примерно 90-95% американских фирм, входящих в список Fortune 1000 и используют в своей деятельности информационные технологии, развернут электронные архивы. Масштабные СД, существующих на сегодня, развернутые в телекоммуникационных компаниях и достигают объема 5 Tb. Объем инвестиций в технологии СД на Западе составляет несколько миллиардов долларов в год и продолжает расти.

Итак, формально корпоративное СД можно определить как комплекс аппаратно-программных средств и технологий создания архива (масштаба отрасли или корпорации или предприятия) документов в электронном виде. Цель создания СД заключается в обеспечении оперативного и полноценного доступа ко всем документам, хранящимся и поступают. Для этого нужно решить две главные задачи: ввести массив имеющихся в архиве документов и обеспечить возможность оперативного полнотекстового доступа к электронным документам.

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

Заключение

Как мы выяснили, витрина данных – это понятие, которое возникло несколько позже термина «хранилища данных», поэтому в некоторых источниках оно соединяется с понятием СД. В нашей работе под витриной (или киоском) данных (Data Mart) мы понимали сравнительно небольшой СД, сконструированый для использования каким-то подразделением с одним существенным отличием от СД — в витрине данных конечный пользователь может создавать свои собственные структуры данных. Существует еще одна особенность у витрин даных (ВД) — источником для большинства данных, сохраняются в них, есть СД. Это приводит к тому, что при создании ВД редко используют инструменты по очистке, денормации и унификации данных.

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

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

Список использованной литературы

1. Асеев Г. Г. Архитектура корпоративного хранилища данных / Георгий Асеев // Вестник Книжной палаты. — 2010. — № 10. — С. 20-25.
2. Сахаров А. А. Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server) / А. А. Сахаров // СУБД. — 2006. — № 3. — С. 44-59.
3. Codd EF Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate / SB Codd., CT Salley. — E. F. Codd & Associates, 1993. — 24 г..
4. Demarest M. Building the Data Mart / M. Demarest // DBMS. — 1994. — № 7. — P. 44-50.
5. Кузнецов С. Обзор возможностей применения ведущих СУБД для построения хранилищ данных / С. Кузнецов (DataWarehouse). — Режим доступа: http://www.olap.ru/basic/dbms.asp. — Загл. с экрана.