Технология хранения данных. Корпоративные базы данных.

5.6.1. Современные требования к корпоративным базам данных.

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

а) Распределенная обработка данных.

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

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

б) Технологии хранилищ данных.

Любая корпорация сегодня должна анализировать накопленные данные - без такого анализа невозможно принимать управленческие решения. Анализ должен быть всесторонним (иначе решение будет неправильным) и быстрым (иначе решение запоздает). Для этого средства анализа должны быть гибкими и понятными конечному пользователю.

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

Таким образом, современная корпоративная база данных должна располагать средствами построения хранилищ данных и OLAP-анализа.

в) Масштабируемость.

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

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

Для получения объективных оценок производительности и соотношения "цена/производительность" применяются стандартные тесты, разрабатываемые Советом по обработке транзакций (Transaction Processing Council - TPC). Результаты тестов регулярно публикуются на Web-узле TPC - http://www.tpc.org.

г) Снижение стоимости владения.

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

В сфере корпоративных систем обработки данных в последнее время большое значение придается совокупной стоимости владения (Total Cost of Ownership, TCO). Этот показатель учитывает не только начальные вложения в систему обработки данных - приобретение аппаратуры и системного ПО, но и дальнейшие затраты - разработку прикладного ПО, внедрение, обучение пользователей, текущее сопровождение, модернизацию.

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

5.6.2. Потребность в анализе данных.

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

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

5.6.3. Хранилища данных.

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

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

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

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

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

5.6.4. Хранилища и киоски данных.

Хранилища данных могут быть разбиты на два типа: корпоративные хранилища данных (enterprise data warehouses) и киоски данных (data marts).

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

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

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

а) Основные компоненты.

Основными компонентами хранилища данных являются следующие:

- оперативные источники данных;

- средства проектирования/разработки;

- средства переноса и трансформации данных;

- СУБД;

- средства доступа и анализа данных;

- средства администрирования.

5.6.5. Анализ данных в корпоративных системах.

а) OLAP - передовая технология анализа.

Двенадцать определяющих принципов OLAP были сформулированы в 1993 году Е.Ф.Коддом, "изобретателем" реляционных баз данных. OLAP - это OnLine Analytical Processing, то есть оперативный анализ данных. Позже определение Кодда было переработано в так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information - быстрый анализ разделяемой многомерной информации), который требует, чтобы OLAP-приложение предоставляло следующие возможности быстрого анализа разделяемой многомерной информации:

- высокая скорость. Анализ должен производиться одинаково быстро по всем аспектам информации. При этом допустимое время отклика составляет не более 5 секунд;

- анализ. Должна существовать возможность производить основные типы числового и статистического анализа - предопределенного разработчиком приложения или произвольно определяемого пользователем;

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

- многомерность. Основная, наиболее существенная характеристика OLAP;

- работа с информацией. Приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения.

б) Многомерное представление.

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

в) Хранение данных OLAP.

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

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

В итоге мы имеем 4 значения исходных данных и 5 значений агрегатов, то есть объем данных увеличился в 2,25 раза. Степень увеличения объема зависит от количества измерений и количества уровней суммирования. В одном из недавно опубликованных стандартных тестов полный подсчет агрегатов для 10 Мбайт исходных данных потребовал 2,4 Гбайт дисковой памяти.

Другой проблемой хранения OLAP-данных является разреженность многомерных данных. Например, если в 1999 году продаж на Юге не было, то на пересечении соответствующих измерений куба не будет никакого значения. Если OLAP-сервер будет хранить в таком случае некое соответствующее значение, то при значительной разреженности данных количество пустых ячеек (требующих, тем не менее, места для хранения) может во много раз превысить количество заполненных и в результате общий объем неоправданно возрастет. Решения, предлагаемые для этого компанией Microsoft, приводятся ниже.

г) Разновидности OLAP.

Для хранения OLAP-данных могут использоваться:

- специальные многомерные СУБД (OLAP-серверы). В этом случае говорят о MOLAP (Multidimensional OLAP). При выполнении сложных запросов, анализирующих данные в различных измерениях, многомерные СУБД обеспечивают большую производительность, чем реляционные. При этом скорость выполнения запроса не зависит от того, по какому измерению производится "срез" многомерного куба;

- традиционные реляционные СУБД - ROLAP (Relational OLAP). Применение специальных структур данных - схемы "звезды" (star) и "снежинки" (snow-flake), а также хранение вычислительных агрегатов делают возможным многомерный анализ реляционных данных. Реляционные СУБД исторически более привычны, и в них сделаны значительные инвестиции, поэтому пока ROLAP более распространен.

Комбинированный вариант - HOLAP (Hybrid OLAP), совмещающий и тот, и другой вид СУБД. Одним из вариантов совмещения двух типов СУБД является хранение агрегатов в многомерной СУБД, а детальных данных (имеющих наибольший объем) - в реляционной.

5.6.6. Размышления и предсказания.

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

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

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

Сообщество баз данных выделяют следующие задачи:

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

- масштабирование баз данных по размеру (до пентабайт), пространственному размещению (распределенные) и многообразию (неоднородные);

- автоматическое обнаружение тенденций данных, их структур и аномалий (добывание данных, анализ данных);

- интеграция (комбинирование) данных из нескольких источников;

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

- автоматизация проектирования и администрирования базами данных.

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

Годы Факультеты Преподаватели

Специальности Кафедры

Группы

Студенты

Рис.5.2. Корпоративная база данных ВУЗа (пример).

Рис.5.3. Корпоративная база данных "заказчик-потребитель" (пример).