Характеристика базы данных

Типичный размер таблиц Схема доступа

Количество строк, к которым обращается один запрос

С какими данными работает приложение

Интенсивность обращений к базе данных

Тип доступа

Чем определяется производительность

База данных OLTP

Тысячи строк

Предопределена для каждого типа обрабатываемых транзакций

Десятки

С отдельными строками

Больщое количество

бизнес-транзакций

в минуту или в секунду

Выборка, вставка и обновление

Время выполнения транзакции

База данных хранилища

Миллионы строк

Произвольная; зависит от того, какая именно задача стоит перед пользователем в данный момент и какие сведения нужны для ее рещения

От тысяч до миллионов

С фуппами строк (итоговые запросы)

На выполнение запросов требуется время, минуты или даже часы

Преимущественно выборка

(почти 100 процентов операций)

Время выполнения запроса

Компоненты хранилище данных

На рис. 21.1 изображена архитектура хранилища данных. Выделим три ее основных компонента:

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

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

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

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

Деловые операции

Реляционные базы данных .

Унаследованные базы данных

Файлы сданными

Бизнес-приложения

Средства извлечения, переформатирования и загрузки данных

Реляционные базы данных Л

СУБД хранилища

База данных хранилиа!а

Средства

анализа

данных и

генерации

Рис 21.1 Компоненты хранилищаданных

Эволюция хранилищ данных

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

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

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

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

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

Архитектура баз данных для хранилищ

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

Кубы фактов

в больщинстве случаев информация в базе данных хранилища может быть представлена в виде N-мерного куба фактов, отражающих деловую активность компании в течение определенного времени. Простейший трехмерный куб данных о продажах изображен на рис. 21.2. Каждая его ячейка представляет один факт - объем продаж в долларах. Вдоль одной грани куба (одного измерения) располагаются месяцы, в течение которых выполнялись отражаемые кубом продажи. Второе измерение составляют категории товаров, а третье - регионы продаж. В каждой ячейке содержится объем продаж для соответствующей комбинации значений по всем трем измерениям. Например, значение $50475 в левой верхней ячейке - это объем продаж одежды в январе в восточном регионе.

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