В этом номере мы публикуем переводы трех статей из декабрьского выпуска журнала Computer, тематика которого (в кои-то веки!) посвящена системам управления данными, а именно, хранилищам данных и системам оперативной аналитической обработки (OLAP — online analytical processing), а также, отчасти, технологии добычи данных (data mining). Вот почему из своего ежемесячного обзора этого журнала я решил выделить более связную заметку, представляющую собой некоторый комментарий к публикуемым статьям (о других материалах декабрьского номера Computer можно прочитать, как обычно, в рубрике «Книжная полка ОС» в статье «Навстречу вызову инженерных систем»). Без сомнения, редакция журнала Computer своим декабрьским выпуском сделала всем читателям хороший новогодний подарок. Давно не получал такого удовольствия от чтения этого журнала, чего и вам желаю.

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

Две из трех предлагаемых вниманию читателей «Открытых систем» статей — «Технология многомерных баз данных» Торбена Педерсена и Кристиана Йенсена и «Технология баз данных в системах поддержки принятия решений» Сураджита Чаудхаури, Умешвара Дайала и Венкатеша Ганти — являются обзорами. Когда мы отбирали статьи для перевода, то при первом просмотре (по оглавлению журнала) первая привлекала меня названием, а вторая — составом авторов. Чаудхари, в частности, — один из наиболее часто публикуемых в настоящее время авторов, и его статьи всегда отличаются очень высоким качеством.

Начнем с первого обзора. Многомерные базы данных (multidimensional databases) — словосочетание, которое по моим наблюдениям чаще и успешнее всего используется в маркетинговых целях компаниями, которые (а) позиционируются на рынке технологии хранилищ и витрин данных и (b) действительно обладают специализированными продуктами для управления такими базами данных. Из числа реально видимых я бы назвал всего три компании — Oracle, IBM и SAS.

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

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

2. СУБД, специально организованные для работы с многомерными базами данных, могут обеспечить гораздо более эффективный доступ к ним, чем если бы многомерные структуры поддерживались средствами «обычных» реляционных СУБД.

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

Проанализируем эти высказывания в контексте статьи Педерсена и Йенсена. Более осторожные авторы, как правило, стараются избегать использования термина «модель данных» применительно к многомерным базам данных. Педерсен и Йенсен отважно идут на это, и нужно заметить, отчасти оправданно. Во-первых, им, как мне кажется, удалось очень понятно объяснить природу многомерного куба данных, используя простые и выразительные примеры (правда, быть может, стоило сделать примеры немного более сложными). Во-вторых, они ссылаются на некоторый математический базис многомерных баз данных — алгебраическую теорию матриц. В-третьих, сформулирован базовый набор операций манипулирования данными. Это, конечно, не модель данных в полной мере: не хватает абстрактности, строгости и полноты. Но все равно это очень хорошо, поскольку лучше иметь хоть какой-нибудь вариант модели, чем не иметь никакого.

Возможно, это всего лишь моя личная черта, но мне очень не нравятся программистские «черные ящики». В частности, мне не нравятся программные продукты, которые объявляются (и иногда действительно являются) существенно более эффективными, чем другие — если я не понимаю, с чем эта эффективность связана. В этом отношении реляционные СУБД являются очень открытыми в технологическом смысле. Даже не будучи посвященным в детали, можно догадаться, за счет оптимизации каких операций одна реляционная база данных превосходит другую в данном приложении. Системы управления многомерными базами данных предельно закрыты. Несмотря на многократные попытки, мне так и не удалось узнать, например, как же все-таки отображается многомерный куб на внутренние структуры. По всей видимости, Педерсен и Йенсен находятся в тех же условиях, поскольку в разделе статьи, посвященном реализации, содержится всего лишь один не слишком вразумительный абзац про «специализированные структуры», хранящиеся на дисках. При всем своем желании я не могу сказать, почему многомерные базы данных справляются с многомерными кубами лучше, чем реляционные. Кстати, то же самое относится к возможности обоснования того факта, что возможные объемы содержащихся в них данных ограничены по сравнению с реляционными базами данных, как и то, что, по утверждению авторов статьи, ограничение это постепенно снижается.

Наверное, по тем же причинам неудовлетворенности собственными возможностями подробно описать технологию систем управления многомерными базами данных, Педерсен и Йенсен часто и с видимым удовольствием переходят к описанию схем «звезда» и «снежинка», используемых в реляционных базах для представления многомерных кубов. Что представляют собой эти схемы, я повторять не буду. Лучше я поделюсь своими соображениями по поводу того, каково место этих схем в мире реляционных баз данных вообще, и почему эти схемы одинаково горячо любят и поставщики реляционных СУБД, и те, кто строят на их основе хранилища и витрины данных. (Заранее готов к восприятию замечаний и возражений.)

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

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

В-третьих, и разработчики аналитических приложений любят схемы «звезда» и «снежинка», поскольку они действительно явно представляют многомерный куб в виде набора связанных двумерных таблиц. Таким образом, любые визуальные манипуляции с кубом легко отображаются в термины SQL — языка запросов к реляционным базам данных. Более того, обе схемы дают явный и здравый ответ (в отличие от случая действительно многомерных баз данных) относительно способа представления иерархий измерений.

Перейду теперь к статье Чаудхари, Дайала и Ганти. В действительности, как мне кажется, многие сочтут название обзора — «... для систем поддержки принятия решений» — не соответствующим содержанию. Конечно, времена меняются, но еще совсем недавно технологии систем поддержки принятия решений (DSS — decision support system) и OLAP принципиально и по существу разделялись. Не вдаваясь в детали, отмечу, что с точки зрения требований к СУБД системы категории DSS ориентированы на заранее запланированный и продуманный набор запросов, в то время как системы категории OLAP ориентированы на непредвиденные, «ad hoc» запросы. Если исходить из содержания, то статью лучше было бы назвать «Обзором современных тенденций развития технологии баз данных для поддержки хранилищ и витрин данных, оперативной аналитической обработки и добычи данных».

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

Статья построена весьма логично и производит цельное впечатление. Мне хочется прокомментировать только три момента.

  • Больше трех страниц текста статьи посвящена добыче данных. С одной стороны, это хорошо, поскольку читатели могут получить представление о структуре (в смысле framework) этой технологии, понять, из каких шагов состоит этот процесс, и что наиболее существенно на каждом шаге. С другой стороны, этого катастрофически мало, чтобы понять смысл этого процесса. Например, исключительно важный подраздел «Типы моделей [добычи данных]» состоит из перечисления их названий (классификационная модель, регрессионная модель, кластерная модель и т.д.). Этого, конечно же, явно недостаточно для понимания. Для справедливости заметим: приведены ссылки на две книги и статью, где все это описано подробно.
  • Очень (слишком!) коротко затрагивается вопрос «очистки данных» (data cleaning) при построении хранилищ данных. С моей точки зрения, качественная очистка данных (включая согласование форматов, выявление противоречивых и неполных данных, установление логической согласованности и т.д.) — одно из важнейших требований к содержимому хранилищ. К сожалению, процесс очистки данных плохо формализуется, и, по-видимому, здесь трудно ожидать полных и универсальных решений. Вероятно, краткость авторов статьи объясняется тем, что существенных продвижений в этой области нет.
  • На мой взгляд, недостаточное внимание Чаудхури и его коллеги уделили Internet-технологиям в контексте тематики хранилищ данных. Статус этой заметки не оставляет мне возможности вдаваться в детали, но я все же замечу, что активная работа в области виртуальной интеграции данных в Internet дает основания надеяться на соответствующее взаимодействие с технологией хранилищ данных.

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

В тематической подборке имеется еще две статьи. Авторский коллектив из четырех человек опубликовал статью «Проектирование хранилищ данных с применением объектно-ориентированных концептуальных моделей» («Designing Data Warehouses with OO Conceptual Models»). Укажу только первого автора — Хуан Трухилло.Замечу, что особой объектной ориентированностью предлагаемый подход не отличается. На самом деле, представлена методология моделирования хранилищ данных со схемой «снежинка» с использованием языка UML. Разбирается небольшой, но достаточно жизненный пример, с приведением разных фрагментов диаграмм. Речь идет о структурных диаграммах, хотя авторы отмечают, что намерены в будущем использовать и диаграммы активности (не совсем понятно, для чего).

Четыре автора из университета Южной Флориды представили статью «Хранилища данных и контроль качества в здравоохранении» («Healthcare Data Warehousing and Quality Assurance»). Это абсолютно практическая статья, повествующая о том, как во Флориде было создано хранилище данных для нужд здравоохранения. Статья может быть полезна для всех, кто планирует провести подобную работу в России.