Витрины данных data mart сппр. Преимущества Трёхуровневого хранилища данных. Недостатки Трёхуровневого хранилища данных

Хранилище данных Хранилище данных - это предметно-ориентированная, интегрированная, содержащая исторические данные, неразрушимая совокупность данных, предназначенная для поддержки принятия управленческих решений. (Уильям Инмон) Термин "хранилище данных" можно представить в виде объединения двух основных идей: интеграция разобщенных данных в едином хранилище и разделение наборов данных и приложений для обработки и анализа.

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

Подходы и имеющиеся решения реализации Компания IBM A Data Warehouse Plus. Целью является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественна тесная интеграция программных продуктов. Предлагаются три решения для хранилищ данных: Изолированная витрина данных. Предназначена для решения отдельных задач вне связи с общим хранилищем корпорации. Зависимая витрина данных. Аналогична изолированной витрине данных, но источники данных находятся под централизованным контролем. Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.

Подходы и имеющиеся решения реализации (продолжение) Oracle Решение компании Oracle основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих: наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных; существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных; высокий технологический потенциал компании в области анализа данных; доступность ряда продуктов, производимых другими компаниями.

Подходы и имеющиеся решения реализации (продолжение) Hewlett Packard OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонент. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, предназначенный для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д. NCR Решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования СУБД Teradata и связанных с ней методах параллельной обработки.

Подходы и имеющиеся решения реализации (продолжение) Informix Software Стратегия компании направлена на расширение рынка для продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура базируется на четырех технологиях: реляционные базы данных, программное обеспечение для управления хранилищем данных, средства доступа к данным и платформе открытых систем. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных. SAS Institute Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем: обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и не реляционных); преобразование данных и манипулирование ими с использованием 4GL; наличие сервера многомерных баз данных; большой набор методов и средств для аналитической обработки и статистического анализа.

Подходы и имеющиеся решения реализации (окончание) Sybase Стратегия компании основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация). Software AG Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.

Правила для хранилищ данных (Уиллиам и Келли) 1. Хранилища данных и операционная среда должны быть разделены. 2. Данные в хранилище должны интегрироваться. 3. В хранилище содержатся данные, накопленные за долгое время. 4. Данные в хранилище- это мгновенный снимок данных, полученный в данный момент времени. 5. Данные в хранилище предметно ориентированы. 6. Данные в хранилище предназначены для чтения с периодическим обновлением на основе операционных данных. Данные в хранилище обновлять оперативно нельзя.

Правила для хранилищ данных (продолжение) 7. Жизненный цикл в хранилище данных отличается от классической информационной системы. В хранилище данных во главе - данные, а в операционной базе данных - процесс. 8. В хранилище данных хранятся данные с несколькими уровнями детализации (текущие, старые, слабо обобщенные, данные высокой степени обобщения). 9. Среда хранилища данных характеризуется транзакциями, выполняющих чтение только большого числа данных. (Среда операционной базы данных – большое число транзакций обновлений). 10. Хранилище данных в составе имеет систему, которая отслеживает источники данных, преобразование и хранение.

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

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

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

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

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

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

В 1994 году было предложено объединить концепции витрин данных и хранилища данных и использовать хранилища для витрин данных. Целью объединения было то, чтобы сами витрины данных основывались на данных, которые хранятся в хранилищах. Была предложена так называемая многоуровневая архитектура из трех уровней: 1-й уровень общекорпоративной базы данных на основе распределенной СУБД; 2-й уровень базы данных подразделений. Здесь хранятся агрегированные данные, то есть реляционные базы данных хранят операционные данные, а агрегированные данные отбрасываются на 2 уровень. 3-й уровень - это конкретные места пользователей-аналитиков. Те пользователи, которые на основе витрин данных делают какие-то выводы.

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

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

Архитектура хранилища данных На сегодняшний день предложено множество архитектур, рассмотрим пять наиболее распространенных: 1. независимые витрины данных (independent data marts) 2. шина взаимосвязанных витрин данных(data-mart bus architecture with linked dimensional data marts) 3. архитектура «звезда» (hub-and-spoke) 4. централизованное хранилище данных (centralized data warehouse) 5. федеративная архитектура (federated architecture).

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

Шина взаимосвязанных витрин данных (Ralph Kimball) Создание такой архитектуры начинается с анализа требований для конкретных бизнес-процессов, таких как заказы, клиенты, счета и проч. Первая витрина данных строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах. Последующие витрины данных разрабатываются с использованием этих измерений, что в результате приводит к созданию логически интегрированных витрин.

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

Централизованное хранилище данных (без зависимых витрин) Эта архитектура похожа на архитектуру «звезда» за исключением отсутствия зависимых витрин данных. Хранилище данных содержит детальные данные, некоторое количество агрегированных данных и логические представления. Запросы и приложения выполняются как на реляционных данных, так и на многомерных представлениях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Создание хранилища данных

Понятия

Варианты

Элементы

Факты

Измерение

Заполнение

Использование хранилища данных

Понятия

Языки

Инструменты

Связанные темы

Люди

Продукты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что это?

Что такое витрины данных? Английский вариант - Data Mart. Существует несколько синонимов понятия:

Специализированное хранилище
Киоск данных.
Рынок данных и проч.

Определимся с трактовкой термина "витрина данных":

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

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

Концепция хранилища

Идея создания витрин данных была предложена в 1991 году Forrester Research. Авторы представляли данное хранилище информации как определенное множество специфических баз данных, которые содержат в себе сведения, относящиеся к конкретным векторам деятельности корпорации.

Forrester Research выделяли следующие сильные стороны своего проекта - витрин данных:

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

Но те же Forrester Research говорили и о слабых сторонах своего изобретения:

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

Перейдем теперь к новой теме.

Конструирование витрин

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

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

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

Независимые витрины: примеры

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

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

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

Достоинства независимых витрин

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

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

Недостатки независимых витрин

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

Смешанная концепция

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

Данное решение объединяет в себе три уровня:

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

Данная многомерная структура со временем станет стандартной во многих компаниях. Главная причина того - объединение в ней достоинств двух подходов:

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

Достоинства трехмерных витрин

Плюсы данного типа ВД следующие:

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

Недостатки трехмерных витрин

Здесь также выделяется ряд минусов:

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