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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

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

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

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

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

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

· OLTP (Online Transaction Processing) - онлайновая обработка транзакций, использующая такой способ организации СУБД, при котором система работает с транзакциями небольшими по размерам, но идущими большим потоком, и при этом клиенту требуется от системы максимально быстрое время ответа;

· OLAP (Online Аnalytical Processing) - аналитическая обработка информации в реальном времени, включающая составление и динамическую публикацию отчётов и документов и реализующая принципы построения систем поддержки принятия решений – Decision Support System (DSS) и систем интеллектуального анализа данных – Data Mining .

При реализации технологий OLAP и OLTP используется новая форма организации внутримашинной информационной базы, представляющей совокупность взаимосвязанных компонентов: Операционной Базы Данных (ОБД), Хранилищ данных (ХД) - Data Warehouse (DW) и Витрин Данных (рис. 5.6).

Рис. 5.6 - Организация внутримашинной информационной базы ИС

Операционные БД систем OLTP (Online Transaction Processing) - онлайновая обработка транзакций, являются основным источником информации. Их дополняют внешние данные , представленные обычно в текстовом формате.

Хранилище данных(Data Warehouse) по определению предложившего его Билла Инмона - предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений.

Свойства хранилищ данных:

· предметная ориентация – данные представляют предмет, а не процессы;

· интеграция;

· строгая и однотипная хронология – обязательная привязка данных по времени;

· неизменяемость – данные не изменяются, а пополняются за счет ОБД и внешних данных.

Структура данных в хранилище данных:

· мета данные (данные об данных) – информация об источнике и произведенных над исходными данными операциях;

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

· агрегированные данные.

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

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

Данная архитектура основана на распространенной концепции посредников (mediators). Рассмотрим два типа компонентов этой ар­хитектуры. Обертка (wrapper) используется для хранения информа­ции о внешнем источнике и организации к нему доступа. При получении запроса обертка обра­щается,к источнику через предоставляемый им интерфейс. Получен­ные от источника данные конвертируются во внутренний формат данных хранилища (т.е. в модель данных хранилища). Понятно, что для каждого источника необходима своя обертка. Посредник осуществляет интеграцию данных из различных источ­ников (из различных оберток). Посредник может взаимодействовать как с обертками, так и с другими посредниками. Таким образом, предоставляется возможность построения сложной сети взаимодей­ствующих между собой посредников, что позволит обобщать данные различными способами для удовлетворения нужд различных прило­жений, взаимодействующих с виртуальным хранилищем.

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

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

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

Рис. 5.7 – Шесть уровней архитектуры хранилища данных

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

На втором уровне размещается система извлечения, преобразования и загрузки данных (ETL - Extract, Transformation and Load). Основная задача ETL – извлечь данные из разных систем, привести их к согласованному виду и загрузить в хранилище.

Роль следующего уровня – надежное, защищенное от несанкционированного доступа, хранение данных . В соответствии с предлагаемой тройной стратегией на этом уровне должны размещаться также системы ведения метаданных и нормативно-справочной информации (НСИ) . Оперативный склад данных (Operational Data Store) необходим тогда, когда требуется как можно более оперативный доступ к пусть неполным, не до конца согласованным данным, доступным с наименьшей возможной задержкой. Зоны временного хранения (Staging area) нужны для реализации специфического бизнес – процесса, например, когда перед загрузкой данных контролер данных должен просмотреть их и дать разрешение на их загрузку в хранилище.

Системы уровня распределения данных выполняют задачи, значительно отличающиеся от задач ETL, а именно, выборку реструктуризацию и доставку данных (SRD – Sample, Restructure, Deliver). ETL извлекает данные из множества внешних систем. SRD выполняет выборку из единого хранилища данных. ETL получает несогласованные данные, которые надо преобразовать к единому формату. SRD имеет дело с очищенными данными, структуры которых должны быть приведены в соответствие с требованиями различных приложений. ETL загружает данные в центральное хранилище. SRD должно доставить данные в различные витрины в соответствии с правами доступа, графиком доставки и требованиями к составу информации.

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

Уровень бизнес-приложений представлен сценарными расчетами и статистическим анализом, многомерным анализом, средствами планирования и подготовки отчетности. Естественно, что список бизнес-приложений этим не исчерпывается.

Как исходные, так и агрегированные данные могут храниться либо в реляционных, либо в многомерных БД. Поэтому в настоящее применяются три способа хранения данных :

· MOLAP (Multidimensional OLAP) или OLAP со многими измерениями – исходные и агрегированные данные хранятся в многомерной БД;

· ROLAP (Relational OLAP) или реляционный OLAP – исходные данные находятся в своей реляционной БД, агрегированные данные помещают в специально созданные служебный таблицы в той же БД;

HOLAP (Hybred OLAP) или гибридный OLAP – исходные данные находятся в своей реляционной БД, агрегированные данные хранятся в многомерной БД.

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

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

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

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

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

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

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

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

Рис. 2.20.

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

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

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

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

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

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

КОНТРОЛЬНЫЕ ВОПРОСЫ

• 1. Сформулируйте понятие информационного обеспечения. Каковы его цели и задачи?
• 2. Какова структура подсистемы «информационное обеспечение»?
• 3. Как можно определить понятие внемашинного и внутримашинного информационного обеспечения?
• 4. Что включает в себя внемашинное информационное обеспечение?
• 5. Что понимается под системой классификации и для чего необходима классификация?
• 6. Какими свойствами характеризуется любая система классификации?
• 7. Каковы основные особенности фасетной системы классификации?
• 8. Какие требования необходимо соблюдать при классификации?
• 9. Перечислите основные особенности иерархической системы классификации.
• 10. С какой целью разрабатываются и какие бывают классификаторы?
• 11. В каких случаях используются регистрационные системы кодирования? Какие системы относятся к этому классу?
• 12. Для чего используются классификационные системы кодирования? Какие системы входят в эту группу?
• 13. В чем сущность штрихового кодирования?
• 14. Дайте определения документа, унифицированной системы документации.
• 15. Что представляют собой схемы информационных потоков и каково их основное назначение?
• 16. Каковы основные способы организации внутримашинного информационного обеспечения?
• 17. Перечислите основные недостатки систем с файловой организацией.
• 18. Дайте определение базы данных. В чем ее особенности?
• 19. Каковы основные структурные единицы базы данных и их взаимосвязь?
• 20. Перечислите и охарактеризуйте основные этапы жизненного цикла базы данных.
• 21. Раскройте основные этапы проектирования базы данных.
• 22. В чем заключается сущность концептуального проектирования?
• 23. Для чего используется?7?-модель? Каковы ее сущность и достоинства?
• 24. Дайте характеристику основных типов логических моделей данных.
• 25. Опишите иерархическую и сетевую модели данных.
• 26. Поясните назначение ключевых полей в реляционной базе данных.
• 27. Какие виды связей между объектами вам известны?
• 28. Какие нормальные формы вам известны? Опишите их основные свойства, назначение.
• 29. Что такое отношение в реляционной модели? Назовите основные свойства отношения.
• 30. Дайте определения следующим понятиям: отношение, кортеж, атрибут, домен.
• 31. В чем заключается принцип нормализации отношений?
• 32. Каковы особенности постреляционных баз данных?
• 33. В чем основные особенности технологии «Хранилище данных»?
• 34. Дайте определение хранилища данных и витрины данных. В чем их отличие?
• 35. Какие основные типы витрин данных вам известны?
• 36. В чем сущность понятия «многомерный куб»?
• 37. Охарактеризуйте основные функциональные блоки системы управления «Хранилище данных».
• 38. Опишите многомерную структуру хранилища данных типа «звезда» и «снежинка».
• 39. Каковы основные источники поступления данных в информационное хранилище?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Витрины данных (Data mart)

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

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

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

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

Метаданные

Метаданные − это любые данные о данных. Метаданные играют важную роль в построении СППР. Одновременно это один из наиболее сложных и недостаточно практически проработанных объектов. В общем случае можно выделить по крайней мере три аспекта метаданных, которые должны присутствовать в системе.

1. С точки зрения пользователей:

метаданные для бизнес-аналитиков,

метаданные для администраторов,

метаданные для разработчиков.

2. С точки зрения предметных областей:

структуры данных хранилища,

модели бизнес-процессов,

описания пользователей,

технологические и пр.

3. С точки зрения функциональности системы:

метаданные о процессах трансформации,

метаданные по администрированию системы,

метаданные о приложениях,

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

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

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

База моделей

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

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

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

По цели использования модели подразделяются:

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

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

По способу оценки модели классифицируются:

детерминистские, использующие оценку переменных одним числом при конкретных значениях исходных данных,

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

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

По области возможных приложений модели разбиваются:

специа­лизированные, предназначенные для использования только одной системой,

уни­версальные − для использования несколькими системами.

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

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

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

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

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

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

Система управления базой моделей должна обладать следующими возможностями: создавать новые модели или изменять существующие, поддерживать и обновлять парамет­ры моделей, манипулировать моделями.