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

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

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

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

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

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

Смешанная концепция витрин данных и хранилищ данных

Идея соединить две концепции - хранилищ данных и витрин данных, по-видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных.

И сегодня именно такое многоуровневое решение:

• первый уровень - общекорпоративная БД на основе реляционной СУБД с нормализованной или слабо денормализованной схемой (детализированные данные);
• второй уровень - БД уровня подразделения (или конечного пользователя), реализуемые на основе многомерной СУБД (агрегированные данные);
• третий уровень - рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;

постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:

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

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

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

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

См. также

Создание хранилища данных Понятия Варианты Элементы Факты Измерение Заполнение Использование хранилища данных Понятия Языки Инструменты Связанные темы Люди Продукты

Напишите отзыв о статье "Витрина данных"

Отрывок, характеризующий Витрина данных

– Списки у Макара Алексеича, – сказал фельдшер. – А пожалуйте в офицерские палаты, там сами увидите, – прибавил он, обращаясь к Ростову.
– Эх, лучше не ходить, батюшка, – сказал доктор: – а то как бы сами тут не остались. – Но Ростов откланялся доктору и попросил фельдшера проводить его.
– Не пенять же чур на меня, – прокричал доктор из под лестницы.
Ростов с фельдшером вошли в коридор. Больничный запах был так силен в этом темном коридоре, что Ростов схватился зa нос и должен был остановиться, чтобы собраться с силами и итти дальше. Направо отворилась дверь, и оттуда высунулся на костылях худой, желтый человек, босой и в одном белье.
Он, опершись о притолку, блестящими, завистливыми глазами поглядел на проходящих. Заглянув в дверь, Ростов увидал, что больные и раненые лежали там на полу, на соломе и шинелях.
– А можно войти посмотреть? – спросил Ростов.
– Что же смотреть? – сказал фельдшер. Но именно потому что фельдшер очевидно не желал впустить туда, Ростов вошел в солдатские палаты. Запах, к которому он уже успел придышаться в коридоре, здесь был еще сильнее. Запах этот здесь несколько изменился; он был резче, и чувствительно было, что отсюда то именно он и происходил.
В длинной комнате, ярко освещенной солнцем в большие окна, в два ряда, головами к стенам и оставляя проход по середине, лежали больные и раненые. Большая часть из них были в забытьи и не обратили вниманья на вошедших. Те, которые были в памяти, все приподнялись или подняли свои худые, желтые лица, и все с одним и тем же выражением надежды на помощь, упрека и зависти к чужому здоровью, не спуская глаз, смотрели на Ростова. Ростов вышел на середину комнаты, заглянул в соседние двери комнат с растворенными дверями, и с обеих сторон увидал то же самое. Он остановился, молча оглядываясь вокруг себя. Он никак не ожидал видеть это. Перед самым им лежал почти поперек середняго прохода, на голом полу, больной, вероятно казак, потому что волосы его были обстрижены в скобку. Казак этот лежал навзничь, раскинув огромные руки и ноги. Лицо его было багрово красно, глаза совершенно закачены, так что видны были одни белки, и на босых ногах его и на руках, еще красных, жилы напружились как веревки. Он стукнулся затылком о пол и что то хрипло проговорил и стал повторять это слово. Ростов прислушался к тому, что он говорил, и разобрал повторяемое им слово. Слово это было: испить – пить – испить! Ростов оглянулся, отыскивая того, кто бы мог уложить на место этого больного и дать ему воды.
– Кто тут ходит за больными? – спросил он фельдшера. В это время из соседней комнаты вышел фурштадский солдат, больничный служитель, и отбивая шаг вытянулся перед Ростовым.
– Здравия желаю, ваше высокоблагородие! – прокричал этот солдат, выкатывая глаза на Ростова и, очевидно, принимая его за больничное начальство.
– Убери же его, дай ему воды, – сказал Ростов, указывая на казака.
– Слушаю, ваше высокоблагородие, – с удовольствием проговорил солдат, еще старательнее выкатывая глаза и вытягиваясь, но не трогаясь с места.
– Нет, тут ничего не сделаешь, – подумал Ростов, опустив глаза, и хотел уже выходить, но с правой стороны он чувствовал устремленный на себя значительный взгляд и оглянулся на него. Почти в самом углу на шинели сидел с желтым, как скелет, худым, строгим лицом и небритой седой бородой, старый солдат и упорно смотрел на Ростова. С одной стороны, сосед старого солдата что то шептал ему, указывая на Ростова. Ростов понял, что старик намерен о чем то просить его. Он подошел ближе и увидал, что у старика была согнута только одна нога, а другой совсем не было выше колена. Другой сосед старика, неподвижно лежавший с закинутой головой, довольно далеко от него, был молодой солдат с восковой бледностью на курносом, покрытом еще веснушками, лице и с закаченными под веки глазами. Ростов поглядел на курносого солдата, и мороз пробежал по его спине.

Семантика

Технологии Big Data создавались в качестве ответа на вопрос «как обработать много данных». А что делать, если объем информации не является единственной проблемой? В промышленности и прочих серьезных применениях часто приходится иметь дело с большими данными сложной и переменной структуры, разрозненными массивами информации. Встречаются задачи, способ решения которых наперед не известен, и аналитику необходимы средства исследования исходных данных или результатов вычислений на их основе без привлечения программиста. Нужны инструменты, сочетающие функциональную мощь систем BI (а лучше – превосходящие ее) со способностью к обработке огромных объемов информации.

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

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

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

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

Пусть мы хотим предоставить аналитику возможность делать запросы такого типа:

• Какие единицы маслонаполненного оборудования работали при температуре выше 300 градусов за последнюю неделю?
• Какое оборудование находится в состоянии, выходящем за пределы рабочего диапазона?

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

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

При взгляде на этот граф становится понятной схема выполнения запроса. Сначала нужно отфильтровать измерения температуры за заданный период со значением больше 400 0 C, и измерения давления со значением больше 5 мПа; затем нужно найти среди них те, которые выполнены сенсорами, установленные на одной и той же единице оборудования, и при этом выполнены одновременно. Именно так и будет действовать витрина данных.
Схема нашей системы будет такой:

Порядок работы системы таков:

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

Вся «магия», конечно, происходит внутри витрины. Перечислим принципиальные моменты.

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

2. В нашем примере данные одного и того же типа (измерения температуры) хранятся одновременно в двух разных источниках – HBase и текстовом файле HDFS. Однако для выполнения приведенного запроса обращаться к файлу не нужно, т.к. в нем заведомо нет полезной информации: ведь в файле хранятся измерения температуры резервуара, а давление в резервуарах не измеряется. Этот момент дает представление о том, как должен работать оптимизатор выполнения запросов.

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

4. В качестве источников данных могут выступать не только хранилища, но и сервисы. В нашем примере мы спрятали за сервисом расчет предпосылок к возникновению аварийного состояния при помощи одного из алгоритмов Spark MLlib. Этот сервис получает на вход информацию о состоянии устройства, и оценивает его с точки зрения наличия предпосылок к аварии (для обучения использованы ретроспективные данные о том, какие условия предшествовали реально случившимся авариям; в качестве исходных данных нужно рассматривать не только мгновенные значения физических характеристик устройства, но и элементы основных данных – например, степень его износа).
Эта возможность очень важна, так как позволяет аналитику самому выполнять запуск расчетных модулей, подготовленных программистами, передавая им на вход различные массивы данных. В этом случае аналитик будет работать уже не с исходными данными, а с результатами вычислений на их основе.

5. Аналитик строит запросы при помощи интерфейсов нашей Системы управления знаниями, среди которых – как несколько вариантов формального конструктора запросов, так и интерфейс поиска на контролируемом естественном языке. На следующем рисунке слева показана форма построения запроса на контролируемом языке, а справа – пример результатов другого запроса.

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

За рамками нашего рассказа осталось немало интересных моментов:

• как организован сбор данных сенсоров в HBase с помощью Flume;
• запросы к источникам данных могут выполняться не просто асинхронно, но даже при отсутствии онлайн-связи с ними – на этот случай предусмотрен специальный механизм передачи запроса и получения ответа;
• результаты выполнения запроса могут не просто выдаваться пользователю в виде таблицы или выгружаться в Excel, но и попадать напрямую в BI-систему в виде набора данных для дальнейшего анализа;
• способы конвертации идентификаторов и ссылок на объекты в разных источниках, вопросы транспорта сообщений между компонентами системы, и многое другое.

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

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

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

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

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

Достоинства Витрин данных:

· Витрина данных максимально приближена к пользователю - аналитики работают только с теми данными, которые им необходимы для принятия решения.

· Витрины Данных значительно меньше по размеру, чем Хранилища данных.

· Создавать Витрины данных просто, наполнять их и работать с ними также просто.

· Витрины Данных содержат агрегированные данные по определенным темам, что упрощает их проектирование.

· Витрины данных внедряются достаточно быстро.

· Витрины проектируются для ответов на конкретный ряд вопросов.

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

Недостатки Витрин данных:

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

· сложно работать с витриной, если для наполнения витрины используется очень большое количество источников данных - Потенциально это очень сложный процесс. Наполнения витрин данных при большом количестве источников данных – процесс очень сложный (требуется команда профессионалов в области их построения и работы с ними).

· информация накапливается в различных витринах, но дальнейшее объединение информации (т.е. ее консолидация) не предусматривается. Данные не консолидируются на уровне предприятия, поэтому получить полную единую картину бизнеса нельзя.

· каждая витрина содержит информацию о конкретном аспекте деятельности компании, что не дает возможность руководству компании увидеть как работает его бизнес в целом.

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

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

Рис.24 Независимые Витрины данных

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

Но уже в 1994 году концепцию Хранилищ данных и концепцию витрин данных было предложено объединить и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных (см. Рис.25)

Рис. 25 Трёхуровневое хранилище данных

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

Преимущества Трёхуровневого хранилища данных:

· Создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных нормализованных данных.

· Витрины данных синхронизированы и совместимы с корпоративным представлением. Существует возможность сравнительно лёгкого расширения хранилища и добавления новых витрин данных.

· Гарантированная производительность.

Недостатки Трёхуровневого хранилища данных:

· Существует избыточность данных, ведущая к росту требований на хранение данных.

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

Сокращение затрат на проектирование и разработку ХД может быть достигнуто путем создания витрин данных (ВД). ВД – это упрощенный вариант ХД, содержащий только тематически объединенные данные (Рисунок 3).

Рисунок 3. Структура СППР с самостоятельными ВД

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

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

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

Рисунок 4. Структура СППР с ХД и ВД

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

Недостатки заключаются в избыточности, так как данные хранятся и в ХД, и в ВД, а также дополнительные затраты на разработку СППР с ХД и ВД.

1. Понятие и модель данных olap

   1. Понятие olap

OLAP(OnlineAnalyticalProcessing) – технология оперативной аналитической обработки данных, использующая методы и средства для сбора, хранения и анализа многомерных данных в целях поддержки процессов принятия решений.

Основное назначение OLAP-систем – поддержка аналитической деятельности, произвольных запросов пользователей – аналитиков. ЦельOLAP-анализа – проверка возникающих гипотез.

1. Категории данных в хд

Все данные в ХД делятся на три категории (Рисунок 5):

Рисунок 5. Архитектура ХД

детальные данные – данные, переносимые непосредственно из OLTP-подсистем. Соответствуют элементарным событиям, фиксируемым вOLTP-системах. Подразделяются на:

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

факты – данные, отражающие сущность события (количество проданного товара, сумма продаж, …);

агрегированные (обобщенные) данные – данные, получаемые на основании детальных путем суммирования по определенным измерениям;

метаданные – данные о данных, содержащихся в ХД. Могут описывать:

• объекты предметной области, информация о которых содержится в ХД;

  места и способы хранения данных;

  действия, выполняемые над данными;

  время выполнения различных действий над данными;

  причины выполнения различных действий над данными.

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

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

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

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

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

Создание витрины данных

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

1. Извлечение данных требует точного знания структуры исходных систем. Структуры и взаимосвязи таблиц, структуры информации в исходной системе. Необходимо четко знать из каких таблиц и полей необходимо извлекать данные и какова структура этих данных.

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

• Создание агрегатных данных
• Изменение форматов данных.
• Проверку достоверности и целостности данных.
• Удаление избыточных данных
• И т.д.

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

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

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