Системы Управления Базами Данных T # 4/96 T стр. 71-83
Данные? Складировать? ...Не понимаю, погромче пожалуйста!
...о бесконечном невозможно вообще никакое знание,
ибо ни один разум не может охватить бесконечность...
Боэций, "Комментарий к Порфирию"
Единица! Кому она нужна?!
В. Маяковский, "Владимир Ильич Ленин"
Лет восемь тому назад автору этой статьи довелось быть на одной защите кандидатской диссертации. Темой была компьютерная система для использования во время операций на открытом сердце. Такие операции проводятся у больных с нестабильной стенокардией и состоят в том, чтобы "вскрыть" сердце, найти больной (дестабилизирующий работу сердца) участок сердечной мышцы - миокарда - и умертвить этот участок. Компьютерная система позволяла в условиях сверхжесткого лимита времени быстро и точно определять больной участок. Выступивший в обсуждении профессор высказал удовлетворение тем, что, по его мнению, после десятилетий разговоров о внедрении компьютеров в здравоохранение, ему довелось наконец-то познакомиться с работой, являющей реальное внедрение компьютерных технологий в реальную медицинскую практику.
Профессор уже несколько лет помогает поднимать немецкую науку, а сотрудники, трудившиеся по теме диссертации, помогают излечиваться больным в клиниках США. Однако так или иначе, но работы по этому, относительно небольшому, направлению проникновения информатики в медицину продолжаются. Суть приведенного примера в том, что хотя информатизация в здравоохранении использовалась и используется в целом достаточно широко, но по большей части - на уровне учета, т. е. регистрации больных, лекарственных средств, тех же операций и т. д. Проникнуть же в содержательную деятельность практикующего врача и сделать для него возможным то, что еще вчера казалось нереальным, удалось лишь сравнительно недавно, и удача эта развивается отнюдь не ударными темпами, даже несмотря на то, что трудности таких успехов компенсируются вполне осязаемым, если можно так выразиться, "живым" эффектом.
В свою очередь медицина в приведенном примере всего лишь иллюстрирует общую ситуацию, характерную и для других областей применения вычислительной техники в повседневной жизни. За очень небольшими исключениями, и в банках, и в финансовых институтах, и на заводах, в торговых организациях, государственных учреждениях и в других сферах подавляющая доля автоматизированных систем реализует расчетные, учетные функции, передачу сообщений или функции простейшей обработки. Исторически оправдание компьютерам можно видеть в резком повышении скорости и масштабов такой простейшей обработки, что позволило организациям эффективно держать в поле зрения намного большее, чем в прежние времена, число партнеров, клиентов, товаров, "единиц хранения" и т. п., и увеличить производительность работы именно за счет этого. Понимая, о какой сложной технологии идет речь, можно все-таки утверждать, что такое применение ЭВМ было самым простым из эффективных, с точки зрения реализации. Оно же до настоящего момента остается, вероятно, для подавляющего числа приложений вполне достаточным. Однако у всякого развития есть свои пределы; со временем они начинают все чаще обнаруживаться и у традиционного способа использования. Отчетливые очертания этих пределов появились (увы - пример тому и медицина) не потому, что люди - пользователи, разработчики поняли, что можно делать системы другого уровня, а потому, что "заставила жизнь", а именно новые технологические реалии, связанные с работой с необычно большими массивами данных.
Часть трудностей связана с тем, что, хотя обычные организации и получили возможность воспринимать на несколько порядков больше информации, чем могли себе позволить раньше, доступная реакция на нее при простейшей переработке тоже может быть лишь простейшей. Можно принять данные, переслать сообщение, сгенерировать ответ, но за рамками остаются, во-первых, нетипичные случаи, а во-вторых, такие категории, как целесообразность, результативность или адекватность предпринимаемых в ответ действий.
Другая часть обязана тому, что традиционные способы переработки совершенно несостоятельны в вопросе анализа больших объемов данных. Современные аппаратные средства позволяют обычной организации накапливать колоссальные количества относящейся к ее деятельности данных, однако реально это делает ничтожно малая часть из них, и не только по той причине, что это дорого стоит, но главным образом из-за того, что просто не понятно, для чего это делать. Даже если перевести каким-нибудь образом накопленные так данные в графики, то результат, по элементарной причине его объема, будет не более доступен для восприятия человеком, чем подзабытые уже стопки распечаток с таблицами и сводками АСУ. Широко распространенные средства "деловой графики", электронных таблиц и пр. дают человеку возможность "видеть" гораздо больше информации, чем практиковавшиеся до них таблицы названий и цифр, но для объемов данных, разрешаемых уже сейчас аппаратной технологией, и они не годятся.
Проблемы так или иначе упираются в анализ и обобщение (синтез) технологически достижимых объемов "операционных" данных, которые и позволили бы перевести применение ЭВМ в содержательную область. Между тем на стыке математики и информатики (исследование операций, математические методы оптимизации, математическая статистика, распознавание образов, искусственный интеллект) уже давно существует много разных течений и направлений, ориентированных как раз на анализ данных. К ним относятся все виды визуализации данных, методы предварительной обработки данных (слияние, редактирование, преобразование, фильтрация, получение выборок), проектирование данных, средства и методы исследования данных, машинное обучение, нейронные сети, нечеткая логика, статистические и другие методы распознавания образов, методы оптимизации, фильтрация знаний и многое другое. В совокупности эти методы и алгоритмы можно назвать средствами сложного анализа, или обработки, данных. Общий принцип такого анализа иногда формулируют как "получение знаний (информации) из данных". В отличие от видов анализа, уже получивших распространение в информатике, главным образом в области систем поддержки принятия решений, сложный анализ базируется на отнюдь не всегда тривиальных в смысле математики алгоритмах, решениях и теориях. Но с другой стороны, до самого последнего времени применение сложному анализу данных находилось лишь в пределах научных и научно-исследовательских организаций. Сейчас он только начинает привлекать внимание потребителей и разработчиков информационных систем в традиционных для информатики областях коммерции, производства, управления и т. д.
Очевидно, что переход от, по преимуществу, "инфологического" использования компьютеров к "синтетическому" мог бы стать на сегодняшний день самым многообещающим и захватывающим в компьютерной истории. Он не есть дело настоящего, и его обсуждение только изредка попадает на страницы компьютерной прессы. Тем не менее уже сейчас идет накопление своего рода критической массы предпосылок того, что уже примерно через год вполне в состоянии привести к коммерческому открытию нового направления в информатике.
Можно выделить несколько тематических направлений, развиваемых в информатике, системотехнике и прикладной математике независимо, или почти независимо, друг от друга и находящихся в разных стадиях проработки. Это следующие темы: информационные системы руководителя, склады данных, огромные базы данных и математический анализ массивов данных. Нужно подчеркнуть, что речь идет именно о направлениях развития, а не о каких-то законченных концепциях или разработках. Нельзя, например, не относиться критически к любым заявлениям о создании склада данных или информационной системы руководителя, поскольку четкие критерии этих понятий отсутствуют, а неформальное понимание может меняться от разработчика к разработчику и меняется со временем. Тем не менее характеристические признаки каждого направления вполне отчетливы. Объединение этих направлений может показаться эклетичным, но результат как раз и получается вследствие интеграции. Ниже будет сделана попытка их охарактеризовать, а пока осталось отметить их взаимоотношение друг с другом.
Ядром нового синтезированного направления в области построения информационных систем могло бы стать применение сложного математического анализа к огромным базам данных. Именно оно позволит содержательно перейти на новый уровень работы в прикладной области. Склад данных мог бы стать формой существования огромной базы данных, а информационная система руководителя - одним из наиболее многообещающих "потребителей" (заказчиком, а так же движущей силой) получающейся таким образом комбинации.
Информационная система руководителя (ИСР) - это компьютерная система, позволяющая получать информацию, создавать ее и предоставлять в распоряжение старшего управляющего персонала ("высшего управляющего звена") с ограниченным опытом обращения с ЭВМ. Должна предоставляться имеющаяся информация по конкретным возникающим запросам с любой допустимой степенью детализации.
Согласно исследованиям, мотивацией использования ИСР служат следующие ожидания (в порядке важности).
Классификация может быть разной, но иногда в ИСР выделяют восемь основных необходимых компонентов.
Некоторые руководители не любят пользоваться компьютером, потому что им трудно понять логику работы. Руководителю бывает сложно найти в компьютерной системе путь к необходимой для него информации, пользуясь традиционной клавиатурой. ИСР в состоянии помочь здесь, предлагая такую организацию форм на экране, которая обеспечивает простой и понятный ("логичный") переход от формы к форме в поисках нужной информации. С другой стороны, помимо логичного изображения экранных форм иногда имеет смысл обратиться к нестандартным устройствам ввода: вместо обычной клавиатуры можно использовать сенсорный экран, мышь или инфракрасную клавиатуру, что упрощает физические средства поиска.
Одно из главных преимуществ, которые дает ИСР руководителю, состоит в том, что появляется возможность получать надежную информацию о работе организации в целом гораздо оперативнее, чем раньше. Ранее руководитель часто не обращался к компьютеру вовсе, поскольку терминал, которым он мог пользоваться, не имел возможности поддерживать его собственную отдельную базу данных. Такая база данных увеличивает скорость появления на экране информации из числа той, что часто запрашивается руководителем. База данных руководителя может дополнять и в определенной степени дублировать склад данных, к которому ИСР также будет обращаться.
Кроме того, эта база данных включает в себя аналитическую и интегрированную информацию, являясь совокупным продуктом работы всего персонала компании. Это позволяет руководителю осуществлять функции информационного управления, например определять для каждого работника уровень доступа к различным видам информации (учитывая, что совокупная информация сама по себе зачастую имеет ценность, сравнимую с капиталом компании в целом).
Данные в БД руководителя поступают из разных мест хранения. Сбор может быть достаточно непростой процедурой, включающей сортировку, устранение противоречивости, в том числе с помощью статистических методов, и другие виды обработки числовых (и не только числовых) массивов. Поддержка работающих "каналов поступления данных" и организация функций обработки ложится на ИСР. В определенной мере эти процедуры аналогичны имеющимся в складах данных, однако сбор и сопутствующая обработка данных в ИСР сложнее.
Технология представления информации должна давать дополнительные возможности для понимания данных. ИСР использует для этого разнообразные средства, в частности графики, диаграммы или карты. Подобные и другие методы должны применяться для представления руководителю таких обычных вещей, как бюджеты, сводки продаж и т. д., которые помогают увидеть динамику развития различных процессов во времени.
ИСР не ограничивается только лишь сбором большого объема данных. Она должна предоставлять способы последовательного уточнения сведений, относящихся к конкретным проблемам и автоматически получать отчеты разных видов, так что сам вид отчета определяется реальными данными. Механизм исследования данных должен обеспечивать ответ на такие вопросы, которые не входят в число регулярно освещаемых сводками на рабочем столе руководителя, т. е. возникающие в процессе работы постоянно, но не всегда предсказуемо. Формы исследования данных, используемые в ИСР, приведены в соответствующем разделе ниже. Возможно, что руководитель должен иметь возможность получать данные непосредственно из операционной БД, и определенно - из склада данных. Определенную специфику алгоритмам исследования данных может давать ориентация на сверхбольшие ("огромные") склады данных.
ИСР должна позволять руководителю предусматривать и проверять различные виды решений. Для этого используется механизм моделирования, который должен быть столь же естественнен и прозрачен для руководителя, как и остальные части ИСР. Руководителю необходима возможность проигрывать различные сценарии развития событий.
Такого рода оценки обеспечиваются системой моделей (включающей как традиционные математические решения, так и статистико-вероятностные), а также необходимыми алгоритмами для поиска оптимальных вариантов. Одним из важнейших показателей качества систем планирования и принятия решений является наличие механизма протоколирования процесса поиска и явной аргументации (объяснений) всех этапов поиска решений.
Имеющийся в ИСР механизм связи должен обеспечивать взаимодействие с другими управляющими в организации посредством электронной почты, причем сообщения, которые руководитель рассылает управляющему персоналу, могут быть преформатированы. Известно, что чем выше руководитель, тем более он склонен к работе "с людьми", а не в пределах рабочего стола. В то же время для почтовых программ необходим выход на другие виды связи, типа пейджинговой, факсовой и пр.
В любой организации успешно работающая система - это такая, которая может постоянно развиваться в соответствии с изменяющимися требованиями. ИСР должна предоставлять средства доступа ко всевозможным инструментам разработки, позволяющим быстро и удобно строить новые приложения и проектировать новые экранные формы.
Информационные системы руководителя - относительно специфичная область информатики, гораздо менее популярная, чем ближайшая родственная область систем поддержки принятия решений, хотя ее потенциал трудно переоценить. Из фирм, продвинувшихся в создании таких систем далее других (что отнюдь не означает реализацию всех перечисленных возможностей), следует отметить SAS Institute (США).
В этом разделе перечисляются некоторые методы сложного анализа данных. Все они рождены в академических учреждениях или в НИИ. И, хотя большинством методов занимаются уже не одно десятилетие, их коммерческое использование до самого последнего времени либо отсутствовало, либо было крайне ограничено. Это отражается на их теперешних особенностях с точки зрения рынка информационных систем.
Во-первых, что самое тривиальное, академически, казалось бы, хорошо сделанные разработки оказываются неудовлетворительны как коммерческие продукты, работающие в реальных условиях. Во-вторых, академические постановки задачи часто отличаются от коммерческих, и многие системы, совпадая в постановках задач с требованиями рынка "в принципе", расходятся "в деталях", а значит, с точки зрения рынка, опять-таки неудовлетворительны. В-третьих, новая сфера применения часто заставляет просто менять подходы. Например, многие давно исследованные аналитические методы дают хорошие результаты при естественном для математика предположении, что имеется модель прикладной области. Однако в повседневной жизни разработка такой модели может создавать непреодолимые трудности, и, к недоумению ученого, ценность "хороших" методов девальвируется, а в результате возникает необходимость в новых, далеко не так тщательно изученных.
Тем не менее в математических методах обработки заложен для информатики огромный потенциал, и это объясняет быстрорастущий интерес к ним как в зарубежной, так и в отечественной практике. Можно сказать, что внедрение таких методов в неакадемические приложения (на практике оказывается, что по большей части в коммерческие, хотя и не исключительно) только начинается. Вот наиболее популярные из них.
Ассоциации возникают как привязка значений к какому-нибудь одному событию. Например, при исследовании покупок может выясниться, что при отсутствии дополнительной рекламы всякая покупка жареного картофеля сопровождается приобретением кока-колы в 65% случаев, в то время как при наличии рекламы кока-кола приобретается в 85% случаев. Основываясь на этом, управляющий может делать заключения о целесообразности дополнительной рекламы.
Нахождение последовательных во времени событий. Может быть, например, обнаружено, что за приобретением дома в 45% случаев в течение месяца следует покупка печи, и в 60% случаев в течение двух недель - приобретение нового холодильника.
Определяются причинно-следственные связи между значениями определенных косвенных параметров исследуемого объекта (ситуации, процесса) и распознаваемым свойством, ситуацией или процессом. Например, по набору данных определяется, что для отложения неорганических солей в нефтяной скважине характерны определенные интервалы значений ионов кальция и HCO3, а также высокий перепад давлений. Остальные химико-физические параметры мало влияют на данный процесс (техническая диагностика нефтяных скважин).
По набору показателей отчетов различных банков можно определять истинные причины (небольшой набор интервалов значений некоторых показателей), влияющих на успех (неуспех) их деятельности.
Известно, что на наступление некоторого события или ситуации влияет некоторый набор параметров. Необходимо оценить, какие из параметров наиболее значимы. Так, можно оценить, какие качества некоторого товара являются "подсознательно" определяющими для принятия решения о его покупке различными категориями потребителей.
Это один из наиболее популярных методов исследования данных. Рассматривается конечное число типов (классов) объектов, которыми могут быть в том числе события, ситуации или процессы. Объекты при этом должны быть описаны значениями числовых признаков (симптомов, показателей, параметров). Информация о каждом классе задана с помощью набора объектов (наблюдений, прецедентов), про которые их принадлежность этому классу известна заранее. Нужно найти критерии, по которым можно было бы относить объект к той или иной классификационной категории. Поиск критериев делается на основе изучения характеристик уже расклассифицированных объектов и вывода правил классификации.
Алгоритмы распознавания могут применяться в медицине, когда по наборам симптомов и данных амбулаторных обследований осуществляется диагностика заболевания; в технике, когда по наборам показателей контрольных приборов и экспертным данным происходит диагностика неисправностей; при прогнозировании месторождений полезных ископаемых по данным геологической разведки; при прогнозировании урожайности сельскохозяйственных культур по существующему состоянию растений; при прогнозе свойств сплавов металлов и химических веществ на основе их компонентного состава и предполагаемых условий синтеза; в распознавании скрытых социальных ситуаций по данным осуществляемых опросов и во многих других ситуациях.
Во многих видах деятельности возникает проблема потери постоянных заказчиков. С помощью инструментов классификации можно выделять набор характеристик для заказчиков, вероятно, готовых прекратить пользование услугами, и получить модель, позволяющую находить таких конкретных кандидатов. Можно находить те виды воздействия на заказчиков (реклама и т. д.), которые позволяют удержать разные категории заказчиков, затрачивая на это минимально требуемые средства.
Кластеризация напоминает классификацию, с тем отличием, что критерии классификации не заданы. Кластеризация при исследовании данных позволяет обнаруживать данные, сгруппированные по каким-нибудь признакам, так что объекты одной группы "похожи" друг на друга, а объекты различных групп - "не похожи". Это могут быть, например, родственные по какому-нибудь признаку номера счетов.
Алгоритмы кластеризации как инструмент первичного анализа незаменимы при обработке наборов многомерных данных, возникающих в новых областях, постановках и исследованиях.
Все вышеописанные методы имеют дело с предсказаниями событий типа "будет ли конкретный подписчик возобновлять подписку?". Здесь, однако, речь идет о прогнозировании развития каких-либо показателей, типа объемов продаж, на основе обнаруженных закономерностей.
Из истории развития банка или предприятия, заданной векторными описаниями их положения в различные моменты времени, можно определить их обобщенные показатели на некоторое время вперед. Для решения задачи необходимы аналогичные наборы данных о деятельности других банков (предприятий), для которых заранее уже имеются эти обобщенные показатели.
К средствам сложного анализа данных следует также отнести системы визуализации, преобразующие сложные данные в изображения различных типов, начиная от простых диаграмм и до трехмерных сред. Первоначально такие системы были разработаны в НАСА для слежения за погодными условиями, однако сейчас происходит их активное проникновение в коммерческие области. Например, они могут использоваться для наглядного представления состояния финансового рынка, помогая "на глаз" (т. е. с помощью "одного из самых совершенных приборов") оценивать риск, выявлять аномалии, рыночные возможности и пр. Подобными системами (многие из них запатентованы) занимаются фирмы NeoVision, IBM (обе - США) и другие.
Математические инструменты, которые служат для решения указанных и других задач, весьма разнообразны. Это алгебраические, комбинаторные методы, нейронные сети, деревья решений, алгоритмы оптимизации в разных постановках, нелинейный регрессионный анализ, генетические алгоритмы, теория нечетких множеств, динамического хаоса, вывод правил и многое другое. Подобная тематика у нас в стране традиционно большей частью разрабатывалась в институтах Академии наук. Хотя в целом их продуктивность в последние годы ощутимо уменьшилась, в дополнение появился ряд коммерческих организаций, уходящих своими корнями в те же институты. Так, например, Центр оптимизационных технологий "Оптекс" предлагает наработки по методам оптимизации, нахождению логических закономерностей, распознаванию образов и анализа данных при частичной противоречивости и неполноте данных. Нужно отметить, что системы, предлагаемые такими новыми организациями, часто оказываются более приспособленными к коммерческому использованию, нежели традиционные академические разработки.
Большое число подобных фирм, создаваемых выходцами из крупных научных центров и лабораторий, также появляется зарубежом, главным образом в США. Характерным для них является не по-академически жесткое соблюдение пределов распространения know-how, когда все подробности доступны только внутри фирмы, а открытые публикации отсутствуют. О буквально-таки кипящей деятельности в этом направлении можно судить лишь по обрывочным сведениям, косвенным данным и конечным результатам, тоже, впрочем, часто скрываемым.
Понятие склада данных1) (СД) получило активное хождение недавно - четыре года назад - и расценивается в течение последовавшего периода как перспективное и динамичное направление в проектировании информационных систем.2) Как отмечалось, поначалу проектирование информационных систем развивалось по "инфологическому" пути, и появление нового направления развития ("содержательно информационные" системы) широко проявило себя именно в виде понятия склада данных. Как и у многих других в информатике, у этого понятия отсутствует точное определение, что на практике неудобно в силу разных пониманий разными людьми, или же вообще непониманий (а так же утверждений, что такое понятие вовсе не имеет референта). Имеются разные попытки уточнить понятие СД, но в определении существа сходятся многие: это специальная база данных какой-нибудь организации, где, в отличие от операционной базы с данными для текущей оперативной работы, накапливаются хронологические данные, поступающие в организацию или генерируемые ей, и назначение которых - служить основой для получения справочной, аналитической и обобщающей информации.
Подобная база данных реализуема, если обеспечено выполнение следующих функций.
"Попадание данных на склад" - это целый процесс, который должен быть обустроен. Во-первых, они должны поступать туда в требуемом виде, а, во-вторых, это должно происходить с требуемой регулярностью. "Требуемый вид" подразумевает, как минимум, приведение к нужному формату. Данные одного и того же типа (например даты) могут поступать из разных компьютеров или программных компонентов, и если так, то было бы крайне неудобно (часто - невозможно) хранить их в первоначально разных форматах. Унифицироваться должны названия (районов, фирм; в разных источниках могут быть приняты разные обозначения: "г. Москва", "Москва", "гор. Москва", "М.") и многое другое. Еще одним видом обработки данных при поступлении является первичная переработка, глубина которой в разных приложениях может быть разной и которая может включать устранение шума или заведомо ошибочных значений, другие способы статистической обработки, устранение избыточных (повторяющихся или выводимых) данных или даже восстановление пропущенных значений в плохо обусловленных данных.
Поскольку поступление данных из систем оперативной обработки, как правило, не является разовым, то для нормального функционирования должны существовать программы, выполняющие процедуры передачи данных на склад и их первичной обработки по задаваемому графику или в связи с возникающими внешними событиями.
Как всякая база данных, СД может быть распределен по узлам компьютерной сети, и в той же сети или вне ее пределов могут находиться разнородные источники информации. Для того чтобы обеспечить согласованность работы с разными источниками и получателями данных, подсистемам, обеспечивающим функционирование СД, необходимо пользоваться описанием структур данных с обеих сторон. Обычно такое описание содержится в словаре-справочнике (репозитарии, базе мета-данных), где собираются сведения о форматах, структурах, каналах и источниках поступления данных и другая информация.
В силу проводимого различия между складами данных и операционными базами данных, обычно различаются и средства доступа к ним. Популярный способ доступа к СД состоит в использовании систем нерегламентированных запросов (ad hoc query). Эти системы обладают значительно большей гибкостью при формулировании запросов к БД, чем традиционные генераторы отчетов и 4GL-формы. Например, они открывают возможности для применения таких форм анализа, как произвольное обобщение (агрегирование показателей) или, наоборот, детализация (английские термины - drill up/drill down). Другой вид анализа, который может быть доступен в таких системах, - просчет возможных ситуаций (what-if-analysis): в реальной сводке (диаграмме) заменяются некоторые показатели и анализируется, как при этом изменится общая ситуация. Обобщенным названием для систем нерегламентированных запросов может служить ставшее традиционным "системы оперативной аналитической обработки данных" (OLAP3)), хотя чаще всего это название связывают еще и со специальной, "многомерной" организацией данных в БД. Нужно заметить, что хотя коммерческих OLAP-систем существует много, все они ориентированы на достаточно простой анализ (который тем не менее часто оказывается вполне достаточен).
Своей жизнеспособностью понятие склада данных обязано, казалось бы, такой далекой теме, как организация хранения данных. Для систем, подпадающих под определение СД, их придумано две: на базе реляционной и многомерная. Данные первого типа хранятся в обычных "реляционных" БД (точнее, "реляционно-ориентированных"), но организованы специфичной схемой. В простейшем случае это "радиальная" схема (star schema), где имеется одна большая главная таблица и много частных, связанных с ней. Главная аккумулирует данные о наиболее часто запрашиваемом объекте (например об объекте "поставка") или служит отправной точкой для запросов к таблицам со специальной частной информацией ("поставщик"). Радиальная схема оптимизирована под наиболее часто встречающиеся запросы4) и обычно оказывается реляционно не нормализованной (требование нормализованности в складах данных может оказаться попросту ненужным, если там преобладает статическая историческая информация и за целостностью данных нужно следить только раз: при помещении их в базу). Это же и создает трудности ее проектирования, ввиду отсутствия хорошо разработанной методологии. Усложнением радиальной схемы является схема типа "снежных хлопьев" (snowflake) с несколькими основными таблицами.
Многие поставщики СУБД вносят специальные усовершенствования в свои системы для того, чтобы они эффективнее поддерживали радиальную схему. Дальше других в этом направлении продвинулась фирма Prism Solutions, которая использует "множественные индексы" к главной таблице, резко уменьшая компьютерные время и память при выполнении соединений одновременно по нескольким таблицам. Для других систем такие соединения составляют большую проблему. Ряд поставщиков добавили в свои системы возможность использования поразрядных индексов, нарушив (пользуясь тем же, что и при принятии ранее противоположного решения, обоснованием "повышения эффективности"!) воздержание от этой технологии, давно применяемой в информационно-поисковых системах.
Другой подход к организации данных в СД реализован в многомерных системах, в которых данные хранятся не в таблицах, а в виде многомерных кубов. Модель гиперкуба часто оказывается нагляднее для пользователя и удобнее для OLAP-анализа. Однако и в реализации многомерного представления данных имеются свои трудности, в том числе методологические.
Работы в области СД не вызваны появлением каких-либо принципиально новых идей, а, скорее, формируются специфичной группировкой ряда уже существующих. Мотивировкой для такого группирования служит, вероятно, во-первых, определенное насыщение предпринимательской среды инфологическими системами, которые оказываются недостаточным фактором выживания для все большего числа фирм. Кроме того, многие начинают замечать, что появляющиеся технические возможности по организации сверхбольших баз данных создают условия, в которых подход "склада данных" может действительно обеспечить новое качество информационной системы. Значительный стимул оказывают системы поддержки принятия решений и информационные системы руководителя, для которых СД - естественный источник получения информации. Нельзя к тому же сбрасывать со счетов и временами искусственно подогреваемый поставщиками интерес.
Свои программы по поддержке направления складов данных имеют все крупные поставщики СУБД (Oracle, Informix и др.) и компьютерных систем (Hewlett-Packard, Digital и др.). Фирмы Oracle (Personal Express), Arbor Software (Essbase) и некоторые другие предоставляют возможности многомерной организации данных. Для формулирования нерегламентированных запросов СД с реляционной структурой эффективна система Esperant фирмы Software AG. Фирма Platinum Technology имеет много наработок в областях организации репозитария СД и сбора данных в гетерогенной сетевой среде.
Некоторые фирмы идут дальше отдельных разработок. Так, фирма Oracle объявила Warehouse Technology Initiative, специальную программу координации усилий разработчиков средств СД, цель которой - улучшить совместимость разных систем путем выработки общеупотребимых стандартов и с помощью взаимного информирования. Сейчас в этой программе участвует более 30 крупных фирм США.
Представление о том, что считать большой базой данных меняется год от года, и даже в течение года. На момент написания статьи (середина 1996 г.) примерный размер большой базы данных оценивался между 20 и 300 Гбайт. Свыше 300 Гбайт - это сверхбольшие базы данных. Понятие "огромная база данных" в английском языке отсутствует, однако все понимают, что база объемом 1 Тбайт и выше - это своя, особенная ниша. (Приведенные цифры - условные, так как понятно, что размер дискового пространства, которое занимает база, зависит от СУБД и схемы базы данных. Тем не менее другой метрики не придумано, и приходится пользоваться этой.5)
Отличие огромных базы данных (размером в 1 Тбайт и выше) от остальных в том, что, хотя они принципиально и реализуемы, но все же на пределе сегодняшних технологических возможностей. Поэтому установка огромной базы данных подразумевает самостоятельный проект, суть которого в том, чтобы найти такое системотехническое решение, которое попросту позволило бы хоть как-то работать с такими большими объемами. Такое решение возможно при наличии трех условий: специального решения для дисковой подсистемы, специальных версий операционной среды и специальных механизмов обращения СУБД к данным.
Для дисковой подсистемы, обеспечивающей поддержку огромной базы данных, используется либо "свое" решение, т. е. собственное решение фирмы-разработчика компьютерной системы в целом, либо решение третьей фирмы, специализирующейся в области изготовления дисковых систем сверхбольшой емкости. Примерами фирм, выбравшими первый путь, являются Sun Microsystems и Digital Equipment. Фирма Sun в своем SPARCcenter 2000E для демонстрации работы огромной базы данных применяет SPARCstorage Array, подсистему, в конечном счете объединяющую 612 контроллеров дисковых накопителей на 9 Гбайт каждый, причем часть дискового пространства зеркалирована по схеме RAID 1. Фирма Digital в аналогичных целях использует на установке AlphaServer 8400 свою подсистему Storage-Works, объединяющую 7 модулей по 300 Гбайт каждый по схеме RAID 5.
Примером другого подхода может служить фирма Hewlett-Packard, предлагающая в качестве своего решения применение дисковой системы Symmetrix 3500 Integrated Cached Disk Array фирмы EMC (1024 двухгигабайтных блоков). Как правило, фирмы, специализирующиеся на изготовлении дисковых систем сверхбольшой емкости (MegaDrive, Mylex и др.), предлагают RAID-устройства, компонуемые из большого числа относительно мелких модулей и соединяемых с вычислительной системой SCSI каналом (иногда не одним) со скоростью передачи 20 Мбайт в секунду.
Следует заметить, что взамен чисто дисковой системы для огромных баз данных могут использоваться комбинированные решения, включающие (магнито-) оптические запоминающие устройства и устройства на магнитных лентах. Такие решения более дешевы, хотя и менее универсальны, что, впрочем, вполне удовлетворительно для целого класса приложений, например, с архивной спецификой.
Специальные версии операционной среды при работе с огромными базами данных нужны по двум причинам: во-первых, для того чтобы полностью использовать возможности нестандартно большой дисковой системы, и, во-вторых, для дополнительного увеличения производительности, которой без того может оказаться явно недостаточно. И то и другое относится к операционной системе и к СУБД.
Применяемые версии ОС и СУБД должны сами по себе обладать повышенной производительностью (обычно это 64-разрядные системы) и уметь "обходить" некоторые ограничения, не проявлявшиеся для более ранних "обычных" версий. Так, например, Oracle версий 7.3 и предшествующих может работать с не более чем 1022 файлами Unix, и это, учитывая, что многие 32-разрядные версии этой ОС допускают максимальный размер файла прямого доступа в 2 Гбайт, может приводить к ограничению на размер БД.
Кроме того, специальная версия СУБД может использовать дополнительные возможности буферизации в попытке выиграть на том, что обращение к оперативной памяти на два порядка быстрее обращения к диску, каким бы он не был. Специальная версия Oracle позволяет увеличить область SGA системных буферов СУБД на машинах AlfaServer серии 8400 до 14 Гбайт, что на некоторых примерах дало выигрыш по времени в 250 раз. Справедливости ради, нужно заметить, что в огромных базах данных могут встречаться таблицы и больших размеров, все равно не способные поместиться в оперативную память целиком.
Характеристики огромных БД настолько необычно экстремальны, что даже при условии перечисленных выше усилий терпимого времени обработки запросов к базе можно достичь лишь для запросов с параллельной обработкой, когда разные процессоры системы одновременно обрабатывают разные части одной и той же таблицы и/или связанных с ней индексов. Возможность параллельной обработки запросов должна иметься в СУБД. В Oracle, начиная с версии 7.1, для этого используются расширение системы средством Parallel Query Option и механизм распределения файлов с данными по разным дискам (striping).
На практике выигрыш от параллельной обработки запросов получается только там, где выполняется полное сканирование больших таблиц, например при операции полного соединения, выполняемой с одной из таблиц в качестве ведущей. Это приводит к тому, что алгоритмы обработки данных должны быть в свою очередь модифицированы, для того чтобы они могли работать на сверхбольших массивах. Трудности здесь аналогичны существовавшим 20 лет назад, когда данные для алгоритмов хранились на магнитных лентах, допускавшим лишь просмотр в одну сторону и перемотку в начало.
Уже из рассмотренных вкратце технических особенностей следует, что организация работы с огромной базой данных действительно представляет собой тему отдельного проекта. Нужно добавить еще, что подобный проект дорогостоящий: оценка только аппаратной стоимости работы с 1 Тбайт колеблется около одного миллиона долларов (без учета компьютерной системы, СУБД и ОС). Все вместе это объясняет уникальность подобных разработок. Тем не менее, возможно, без излишнего афиширования, интерес к ним постоянно растет. Это вызвано, во-первых, причинами чисто технологического развития - разработчики дисковых систем уже "привыкли", что одним из основных векторов их существования из года в год служит увеличение доступного дискового пространства.
Во-вторых, тема огромных баз данных становится все более актуальной в связи с растущим интересом к складам данных и к архивам данных. Перспектива использовать сверхбольшие массивы при работе со складом или с архивом данных нередко представляется настолько многообещающей, что материальные и интеллектуальные ресурсы, потраченные на такой проект, совсем не кажутся неумеренными, а даже, наоборот, видятся вполне оправданными.
Наконец, давний и постоянный интерес к сверхбольшим базам данных имеется у научных организаций, заинтересованных в накоплении больших архивов (снимки, телеметрия и т. д.) и в возможности их дальнейшего анализа. Именно в научных приложениях происходит в настоящее время первая "обкатка" сложных методов обработки сверхбольших массивов.
Важность нового направления развития не остается без внимания наиболее дальновидных производителей СУБД. В 1995 г. фирма Oracle объявила программу Test-to-Scale сертификации поставщиков компьютерных систем, предоставивших реально работающее решение типа "склад данных" на базе более 1 Тбайт. Условиями получения сертификата служит реализация контрольного примера базы, состоящей из восьми таблиц, из которых самая большая ("позиция в заказе") содержит 6 миллиардов строк, а самая маленькая ("регион") - всего пять, и демонстрация выполнения над этими данными целого ряда операций, включающих соединение, агрегирование, загрузку и создание индекса. Компьютерные фирмы отнеслись к программе Test-to-Scale Oracle очень серьезно, о чем говорит список уже принявших в ней участие: Hewlett-Packard/ EMC, Sun, Digital, Cray, Data General/NEC, Amdahl, Sequent.
Автор благодарен сотруднику ВЦ РАН М. А. Потапову за многочисленные живые и продуктивные дискуссии по теме использования математических методов при работе с данными и за целый ряд высказанных нетривиальных соображений; АО "Апекс К. С." за предоставленную информацию о дисковых массивах сверхбольшой емкости вообще, и фирмы MegaDrive (США) в частности; А. Резниченко, главному редактору журнала "Мир Oracle", за проявленный настойчивый и конструктивный интерес к работе над этой статьей. Статья написана при частичной поддержке грантов РФФИ # 95-01-01379 и 96-07-89177.
Из чего появилась идея "складировать данные" и в чем смысл этой идеи? Хорошим пояснением может служить пример из далекого, по меркам компьютерной индустрии, прошлого. (Последнее обстоятельство, как кажется, только улучшает пример, подчеркивая универсальность проблемы.)
Более 10 лет тому назад автору, находясь в командировке во Владивостоке, довелось, пользуясь, так сказать, географической близостью к Советскому дальневосточному центру научного исследования океана, познакомиться поближе и с некоторыми проблемами этого центра. У тогдашнего правительства хватало средств на организацию достаточно большого числа морских экспедиций. Выглядели они примерно так: корабль несколько месяцев плавал по океанам и "проводил эксперименты", "собирал научные данные". Снималась масса показателей на разных широтах, разных глубинах, в разные моменты времени и т. д. Показания записывались - в те времена уже на магнитные носители, - и весь объем собранной информации привозился из рейса и сдавался в научно-исследовательские институты "на обработку". Однако дальше начиналось самое интересное.
В НИИ накапливалось (и не исключено, что до сих пор лежит в шкафах в приличного размера комнатах) необъятное море разнообразной информации, которое, казалось бы, должны быть явным воплощением предела мечтаний любого специализирующегося по данной тематике ученого. Возможно, это и были первые терабайтные по совокупности хранилища в СССР. Но на практике их "коэффициент полезного использования" оказывался до обидного низок. В чем причина? Главным образом, их две.
Во-первых, добраться до нужной информации, разбросанной по необъятному нагромождению магнитных лент, часто едва ли оказывалось возможным. Электронного справочника (а только такой и мог бы справиться с задачей) не велось, сведения о местонахождении конкретной информации часто оказывались утерянными, и доступ к информации из других институтов (а магнитные ленты часто распределялись в разные институты, "по профилю") был нередко затруднен. Чисто технической проблемой было и обработать написанной программой содержательно единый объем информации, распределенной по десяткам магнитных лент.
Во-вторых, с точки зрения обработки, имелась совершенно "неподъемная" проблема разнобоя в форматах. Она, в свою очередь, разбивалась на две: разноформатность технических измерений и неунифицированность (или же неполнота) выборок. С одной стороны, имел место технический прогресс, в соответствии с которым регулярно появлялись новые измерительные приборы и записывающие устройства. Информацию, записанную в одном рейсе на шестидорожечное записывающее устройство, уже нельзя было сравнить с аналогичной информацией из предыдущего рейса, где запись велась на пять дорожек. Данные с некоторых лент нельзя было прочитать вообще, так как записаны они были на уникальном приборе, в единичном экземпляре находящемся на каком-нибудь одном корабле (или же на приборе, снятом с производства). С другой стороны, отчасти по понятным, а отчасти по непонятным причинам, по всему многолетнему циклу измерений не имелось единого плана, и тогда сравнивать выборки по материалам разных экспедиций оказывалось невозможным: улучшая "качество эксперимента", или просто с приходом нового ученого, в новой экспедиции производились, например, 13-канальные измерения, в то время как в предыдущей - 5-канальные, да еще с разной точностью, да еще что-нибудь.
Последнее явление типично и для другого "утерянного для общества" бывшего кандидата на ценный источник научных данных: безмерного количества биомедицинской информации о космических полетах. Многим еще памятны заверения радио и газет о том, что во время полета космонавта происходят медицинские эксперименты и "сбор ценной научной информации" и что последняя по завершению полета "передана на обработку" в научно-исследовательские институты. Действительно, Россия, как преемница СССР, получила уникально большой объем медицинских данных о человеческом организме в космосе, однако беда в том, что толку от этих данных мало. Они разноформатны: уникальны по выборкам и по характеристикам для каждого полета, и потому плохо поддаются сравнительному анализу. Сравнить данные полета Юрия Гагарина и наших последних космонавтов, увы, нельзя, а уникальная информация не подлежит ни анализу, ни обобщению.
Приведенные два примера, казалось бы, стары, но совершенно четко очерчивают проблемы, решаемые в сегодняшних складах данных совсем в других областях накопления информации (точнее, данных). В новых областях, по крайней мере, предоставляется шанс избежать прошлых ошибок (а некоторые в свое время действительно было трудно предвидеть) и не превратить хранилище данных в информационное кладбище. Не надо забывать, что ценой старых ошибок было снаряжение новой экспедиции или запуск нового космического корабля для сбора уже имеющихся данных. А с информационными кладбищами, по-видимому, придется смириться для многих "старых" систем типа упомянутых выше или, например, Ленинской библиотеки в Москве, работа с книжным фондом которой, вероятно, уже навсегда останется сродни археологической, с навечно одинаковыми стартовыми условиями для каждого нового "археолога" (широко разрекламированная год назад многими отечественными компьютерными изданиями и пятизвездочными гостиницами "концепция" "электронного архива" для 99% существующих систем остается не более чем клише, хорошо укладывающееся в голову руководства).
Склад данных (СД, data warehouse, DWH): база данных, содержащая предварительно обработанные исходные ("сырые", "операционные" и т. д.) данные. Цель обработки состоит в том, чтобы сделать данные пригодными и удобными для аналитического использования разными классами пользователей, сохранив при этом информативность исходных данных. На практике склад данных обычно имеет структуру специфичного вида (типа "звезда" или "хлопьев"), в которой в целом не выполняется требование реляционной нормализации.
Секция данных (data mart): относительно небольшой склад данных или же часть более общего склада данных, специфицированная для использования конкретным подразделением в организации и/или определенной группой пользователей. Если в корпоративной системе имеется две "секции данных", то общие данные, имеющиеся в обеих секциях одновременно, должны быть представлены в секциях идентично. Термин, неустоявшийся в русском языке.
Исследование данных (data mining): метод поиска информации в данных, подразумевающий использование статистических, оптимизационных и других математических алгоритмов, позволяющих находить взаимозависимости данных (корреляция, классификация и т. д.) и синтезировать дедуктивную информацию.
Первичная обработка данных (data cleansing and scrubbing): процедура "очистки" исходных данных, заключающаяся в устранении избыточности и противоречивости и в очищении от шума перед помещением в склад данных. Более сложная обработка может включать восстановление пропущенных в исходных данных значений.
Администратор данных (data steward): новый вид специалиста, отвечающего за полноту и качество данных, помещаемых в склад данных.
Информационная система руководителя (ИСР, executive information system, EIS): компьютерная система, позволяющая получать информацию, создавать ее и предоставлять в распоряжение старшего управляющего персонала с ограниченным опытом обращения с ЭВМ. Должна предоставляться имеющаяся информация по конкретным возникающим запросам с любой допустимой степенью детализации. Также играет важную роль в стратегическом управлении организацией.
Огромная база данных (точнее всего - сверхбольшая; огромный, или сверхбольшой, склад данных, very large database, VLDB): термин для обозначения БД объемов, близких к технологически возможным максимальным границам. В настоящее время таким объемом условно может считаться объем порядка 1 Тбайт. Сверхбольшие базы и склады данных требуют особых подходов к логическому и системно-техническому проектированию, обычно выполняемому в рамках самостоятельного проекта. В сочетании с математическими средствами обработки данных они дают новое качество работы с данными, являясь в то же время весьма дорогостоящими проектами.
Система поддержки принятия решений (СППР, decision support system, DSS): система, обеспечивающая на базе имеющихся данных получение средним управляющим звеном информации, необходимой для тактического планирования и деятельности. Опирается в значительной степени на анализ данных в БД (по современным представлениям - в складе данных) визуальными средствами (графики) и средней сложности статистическими или иными математическими методами. Системы поддержки принятия решений появились давно, однако получили новый импульс к развитию с возникновением складов данных.
Сложный анализ данных (intelligent data analysis): общий термин для обозначения анализа данных с активным использованием математических методов и алгоритмов, таких как методы оптимизации, генетические алгоритмы, распознавание образов, статистические методы и т. д., а также использующих результаты их применения методов визуального представления данных. Образно смысл использования сложного анализа данных может быть сведен к формулировке "получения информации из [исходных] данных".
1) В отечественной литературе термин data warehouse переводится по-разному: то "хранилище данных", то "информационное хранилище". Оба перевода могут показаться не совсем удачными, а второй - просто не соответствующим определению. Не совсем понятно, почему многие переводчики не пользуются лозунгом "Не знаешь, как перевести - переводи буквально!" и избегают слова "склад". Наличие двух переводов оправдывает использование третьего, хотя четвертый перевод, "датахран", кажется автору не менее удачным.
2) Книга Using the Data Warehouse авторов W. Inmon и R. Hackthorn, принимая по распространенному мнению за изначальное изложение идей склада данных, появилась в 1994 г. (большинство ссылок, если смотреть назад во времени, упираются именно в нее). Представляется однако, что ценность этой книги есть скорее дань сложившейся за короткое время традиции, и что позже нее появилось много существенно более содержательных работ различных авторов.
3) Термин OLAP - это также, наверное, более дань традиции, чем существу. Во всяком случае он не раз аргументированно критиковался, так же как и 12 признаков OLAP-систем, сформулированные Коддом. Однако, новое название и новый список признаков в широкой аудитории не прижился.
4) В этом смысле радиальная схема - совсем не новость, так как иерархический характер запросов к БД, удобный для человека, известен еще по компьютерной литературе 15-летней давности.
5) Некоторые фирмы-производители пытаются извлечь выгоду из такой неопределенности, и даже идут дальше, указывая в рекламе в качестве размера базы данных общий размер испоьзуемого дискового пространства. Между тем, с учетом зеркалирования и других деталей организации дискового пространства логический суммарный объем файлов БД может оказаться значительно меньше. Если принять во внимание еще и индексы, то обем содержательной информации в базе оказывается меньше занимаемого дискового пространства в разы.