Модели данных информационного хранилища

Многомерная модель данных представляет исследуемый объект в виде многомерной или объектно-ориентированной схемы данных, которая в геометрическом представлении выгля- дит как система поликубов.

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

Многомерные данные могут быть отображены в моделях по- средством инструментов в виде СУБД на основе реляционных мо- делей данных, а также и специальными многомерными инструмен- тальными средствами, называемыми объектными надстройками, многомерными и/или объектно-ориентированными СУБД.

Рассмотрим содержание и назначение таблицы фактов. В многомерном пуле информации создается большая централь- ная таблица, называемая таблицей факта (fact table). В ней по- мещают все данные, т. е. объект или событие, интересующие пользователя обобщающего показателя. Таблицы фактов содер- жат числовые или качественные (содержательные) значения.

Различают четыре вида фактов:

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

¾ «моментальные снимки», фиксирующие состояния объ- екта в заданные моменты времени (наличие товаров на складах, состояния счетов в банке и т. д.);

¾ элементы документов, содержащие сведения о реквизи- тах документов (например, сведения о количестве отправлен- ных, полученных товаров, ценах, дате и времени отправки);

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

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

Рассмотрим таблицы, наполняющие факт-таблицы содержа- нием (таблицы размерности, или измерений — dimensional table).

Они содержат постоянные или редко и мало изменяемые данные и должны находиться в отношении «один ко многим» к таблице фактов. Таблицы размерности являются родительски- ми по отношению к таблице факта. Таблица факта является до- черней. В случае наличия в таблице измерений иерархии в ней должны быть поля, указывающие на «предков». Их называют еще консольными таблицами (outrigger table). Они присоединя- ются к таблицам размерности и детализируют отдельные атри- буты. Консольные таблицы являются родительскими по отно- шению к таблицам размерности.

При разработке базы данных по схеме «звезда» или по дру- гой многомерной схеме необходимо глубоко и тщательно про- анализировать предметную область; поместить в центральную таблицу факта все характеризующие исследуемый объект дан- ные, предварительно разработав систему признаков.

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

Многомерные данные, в том числе и на основе реляцион- ных моделей, можно представить в виде схем «звезда», «сне- жинка», «созвездие»2.

Схема «звезда» (схема звездного соединения, звездоподоб- ная схема, звездная схема; от англ. — star schema) — специаль-

 

1 См.: Белов В. С. Указ. соч.— С. 43.

2 Там же.— С. 44.

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

цы фактов (fact table) — центр «звезды» — и нескольких таблиц измерений (dimension table) по числу измерений в модели дан- ных — лучи «звезды» (рис. 4.4).

 

Рис. 4.4. Модель данных по схеме «звезда»

Развитием схемы «звезда» является схема «снежинка» (snowflake schema). Она получила название за форму, в виде которой отображается логическая схема таблиц в многомер- ной базе данных. Как и схема «звезда», схема «снежинка» представлена централизованной таблицей фактов, соединен- ной с таблицами измерений. Однако в схеме «снежинка» таб- лицы измерений нормализованы с рядом других связанных измерительных таблиц. В схеме «звезда» таблицы измерений полностью денормализованы с каждым измерением, пред- ставленным в виде единой таблицы, — без соединений на связанные таблицы в схеме «снежинка». Чем больше степень нормализации таблиц измерений, тем сложнее выглядит структура схемы «снежинка». Создаваемый «эффект снежин- ки» затрагивает только таблицы измерений и не применяется к таблицам фактов (рис. 4.5).

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

Выбор схем обусловливается относительной мощностью платформы БД и инструментария для реализации запросов.

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

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

 

 

Рис. 4.5. Модель данных по схеме «снежинка»

 

 

Контрольные вопросы и задания

1. Для чего используется хранилище данных?

2. В чем заключается концепция централизованного храни- лища данных?

3. В чем заключается смысл витрин данных?

4. Что представляют собой рабочие метаданные?

5. Что представляет собой репозиторий?

6. Какие существуют схемы представления многомерных данных?

7. Какие преимущества и недостатки имеет схема «снежинка»?

 

Библиографический список

Основная литература

1. Информационные системы в экономике: учеб. для студентов вузов / под ред. Г. А. Титоренко.— 2-е изд., перераб. и доп.— М.: ЮНИТИ-ДАНА, 2009.— C. 146–164.

2. Марков, А. С. Базы данных: введение в теорию и методоло- гию: учеб. / А. С. Марков, К. Ю. Лисовский.— М.: Финансы и ста- тистика, 2006.— C. 51–88.

3. Белов, В. С. Информационно-аналитические системы. Основы проектирования и применения: учеб. пособие / В. С. Белов.— М.: МЭСИ, 2004.— С. 28; 32–44.

Дополнительная литература

1. Григорьев, Ю. А. Банки данных: учеб. / Ю. А. Григорьев, Г. И. Ре- вунков.— М.: МГТУ им. Н. Э. Баумана, 2002.— 320 с.

2. Дунаев, С. С. Доступ к базам данных и техника работы в сети. Практические приемы современного программирования / С. С. Ду- наев.— М.: Диалог-МИФИ, 1999.— 416 с.

3. Емельяновао, Нвы. З. Осн построения автоматизированных ин-

формационных систем: учеб. пособие / Н. З. Емельянова, Т. Л. Пар- тыка, И. И. Попов.— М.: ФОРУМ: ИНФРА-М, 2007.— 416 с.

4. Смирнова, Г. Н. Проектирование экономических информаци- онных систем: учеб. / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов.— М., 2001.— 512 с.

5. Тельнов, Ю. Ф. Интеллектуальные информационные системы в экономике: учеб. / Ю. Ф. Тельнов.— М., 2001.— 306 с.

 

 

Технологии анализа данных

План

5.1. Признаки OLAP-систем.

5.2. Интеллектуальный анализ данных.

 

Признаки OLAP-систем

Для реализации процессов, происходящих в бизнесе, ком- пания должна провести проектирование и построение единого хранилища данных (Data warehouse) и системы многомерного аналитического хранения и доступа к информации (OLAP).

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

Различают два вида информационно-аналитических систем по режиму и темпу анализа:

¾ статические — имеют заранее разработанный сценарий обработки данных при весьма ограниченных возможностях ва- риаций запросов: это так называемые информационные системы руководителя;

¾ динамические — обеспечивают обработку нерегламен- тированных запросов и гибкую систему подготовки отчетов.

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

1 См.: Белов В. С. Указ. соч.— С. 55.

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

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

¾ в сфере детализированных данных;

¾ агрегированных показателей;

¾ закономерностей1.

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

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

Анализ детализированных данных и агрегированных пока- зателей относится к оперативному, или OLAP-анализу.

Сфера закономерностей основана на интеллектуальной об- работке данных. Главной задачей здесь выступает выявление за- кономерностей в исследуемых процессах, взаимосвязей и взаи- мовлияния различных факторов, поиск крупных «непривычных» отклонений, прогноз хода различных существенных процессов. Эта сфера относится к интеллектуальному анализу (Data mining).

1 Белов В. С. Указ. соч.— С. 56.

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

Эти требования состоят в следующем:

¾ Многомерное представление данных. Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.

¾ Прозрачность. Это требование заключается в том, что пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как они орга- низованы и откуда они берутся.

¾ Доступность. Средства должны сами выбирать источник данных и связываться с ним для формирования ответа на дан- ный запрос.

¾ Согласованная производительность. Производительность не должна зависеть от количества измерений в запросе.

¾ Поддержка архитектуры «клиент-сервер». Средства долж- ны работать в архитектуре «клиент-сервер».

¾ Равноправность всех измерений. Ни одно из измерений не должно быть базовым, все они должны быть равноправными.

¾ Динамическая обработка разреженных матриц. Неопре- деленные значения должны храниться и обрабатываться наибо- лее эффективными способами.

¾ Поддержка многопользовательского режима работы с дан- ными. Все многомерные операции должны поддерживаться многими пользователями.

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

¾ Простота манипулирования данными. Средства должны иметь максимально удобный и естественный пользовательский интерфейс.

¾ Развитые средства представления данных. Средства долж- ны поддерживать различные способы представления данных.

¾ Неограниченное число измерений и уровней агрегации данных. Не должно быть ограничений на число поддерживае- мых измерений1.

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

В конце 1990-х гг. получил распространение свод требова- ний к OLAP-системам в виде «теста FASMI». Fast Analysis Shared Multidimensional Information в переводе с английского означает следующие свойства OLAP-системы: Быстрый Анализ Разделяемой Многомерной Информации.

Раскроем содержание перечисленных свойств OLAP-

системы.

Fast (быстрый) — это свойство выражается во временных требованиях к ответам системы на запросы пользователей. От- вет должен быть получен в пределах 1 секунды.

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

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

 

1 См.: Белов В. С. Указ. соч.— С. 57.

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

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

Information (информация) — возможность получения ин- формации должна обеспечиваться из любых необходимых ис- точников. Инструментальные средства оперируют с объемами и структурами данных.

Более подробно рассмотрим свойство многомерности, так как оно является наиболее отличительным от других систем свойством, в частности от OLTP (On-line Transaction Processing), которые поддерживают текущую функциональ- ность предприятия.

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

Оперативный анализ — это функция ИАС, обеспечивающая быстрый, в соответствии с правилами FASMI, доступ к любой необходимой информации, содержащейся в ИХ или, точнее в факт-таблице, представляемой также в виде многомерного ку- ба (на практике — трехмерных комбинаций кубов). Извлечение информации сопровождается ее обработкой по несложным ал- горитмам: проводится суммаризация, определение процентов от заданных величин, получение относительных показателей, вы- числение величин с заданными коэффициентами и другие дей- ствия над данными на разных уровнях детализации. В первую очередь анализируются данные, представленные в виде элек-

тронных таблиц, над которыми можно оперативно проводить различные сложные вычисления1.

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

Извлечение необходимой информации для построения отче- тов проводится с помощью следующих процедур:

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

¾ поворота. Под этой процедурой понимают изменение координат, их порядка или добавление измерений. Она обеспе- чивает замену в готовом отчете «Издержки», например, аргу- мента «время на регионы или центры затрат». Если рассматри- валась взаимозависимость «возраст — семейное положение», то можно в качестве аргумента брать любое из этих измерений и менять их местами;

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

¾ развертки, или раскрытия. Это процедура, обратная свертке. Данные детализируются: например, группы товаров

 

1 См.: Белов В. С. Указ. соч.— С. 58.

представляют по разделам, более крупные временные периоды разбивают на мелкие и т. д.;

¾ кросс-таблиц. Процедура создания этих таблиц включа- ет совмещение данных из разных таблиц по заданным призна- кам: например, создают отчет, в котором данные об издержках и выручке сводятся по одним и тем же изделиям и временным периодам;

¾ проекции. Процедура включает конструирование отче- тов, являющихся подмножествами из множества единичных ре- квизитов или атрибутов, содержащихся в операционных базах или в ИХ;

¾ построения трендов. В этой процедуре определяют за- висимость числовых или качественных значений показателя от тех или иных параметров: например, времени, технологии и т. д.1

Инструменты OLAP-систем обеспечивают возможность сортировки и выборки данных по заданным условиям. Могут задаваться различные качественные и количественные условия.

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

Рассмотрим типы многомерных OLAP-cистем.

В рамках OLAP-технологий на основе того, что многомер- ное представление данных может быть организовано как реля- ционными СУБД, так и многомерными специализированными средствами, различают три типа многомерных OLAP-систем: многомерные OLAP — MOLAP; реляционные OLAP — ROLAP; смешанные (или гибридные) OLAP — HOLAP.

1 См.: Белов В. С. Указ. соч.— С. 59.

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

Достоинства MOLAP: более быстрое, чем при ROLAP, по- лучение ответов на запросы — затрачиваемое время на 1–2 по- рядка меньше.

Недостатки MOLAP: сравнительно небольшие размеры баз данных (предел — десятки гигабайт); за счет денормализации и предварительной агрегации многомерные массивы используют в 2, 5–100 раз больше памяти, чем исходные данные (расход памяти при увеличении числа измерений растет по экспоненциальному закону); отсутствуют стандарты на интерфейс и средства манипу- лирования данными, имеются ограничения при загрузке данных.

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

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

ROLAP-системы могут использовать менее мощные клиентские станции и серверы; уровень защиты информации и разграниче- ния прав доступа в реляционных СУБД несравненно выше, чем в многомерных.

Недостатки ROLAP-систем: невысокая производительность. К значительным дополнительным трудозатратам приводят не- обходимость тщательной проработки схем базы данных; специ- альная настройка индексов; анализ статистики запросов и учет выводов анализа при доработках схем баз данных.

Выполнение же этих условий позволяет при использовании ROLAP-систем добиться схожих с MOLAP-системами показате- лей в отношении времени доступа, а также превзойти в эконо- мии памяти.

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

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

В заключение параграфа следует добавить, что применение ROLAP- и OLAP-cистем становится невозможным из-за чрез- вычайно жестких требований со стороны объектов управления или, соответственно, контролируемых процессов. К таким объ- ектам относятся крупные промышленные, транспортные, энер- гетические комплексы, финансовые рынки, а к процессам — управление объектами в критических ситуациях или их модели- рование. Именно при таких обстоятельствах применение ИАС становится безальтернативным1.

 

1 См.: Белов В. С. Указ. соч.— С. 59–61.

⇐ Предыдущая6789101112131415Следующая ⇒

Поделиться: