![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Модели данных, используемые для построения хранилищ
Задачи, решаемые аналитическими системами, существенн различаются, поэтому их БД тоже построены на разных приич пах. Критерием эффективности для таких систем обычно я ется скорость выполнения сложных запросов и прозрачно структуры хранения информации для пользователей. Многомерный OLAP (MOLAP). В специализированных СУБД, иных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов: • гиперкубов (все хранимые в БД ячейки должны иметь одинаковую мерность, т. е. находиться в максимально полном базисе измерений); • поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы). Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства. В случае использования многомерных СУБД поиск и выборка данных осуществляются значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам. Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным. С другой стороны, имеются существенные ограничения: • многомерные СУБД не позволяют работать с большими объемами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует в 2, 5—100 раз меньшему объему исходных детализированных данных; • многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память, о подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удается удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в аксимально большие непрерывные группы. Но даже в том случае проблема решается только частично. Следовательно, использование многомерных СУБД оправдано только при следующих условиях: • объем исходных данных для анализа не слишком велик более нескольких гигабайт), т. е. уровень агрегации данн достаточно высок; • набор информационных измерений стабилен (посколь любое изменение в их структуре почти всегда требует полной перестройки гиперкуба); • время ответа системы на нерегламентированные запроск является наиболее критичным параметром; • требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций. Реляционный OLAP (ROLAP). Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства. В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP. В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP-системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа. Главный недостаток ROLAP по сравнению с многомерными СУБД — меньшая производительность. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настроик индексов, т. е. больших усилий со стороны администраторов БД. Только при использовании звездообразных схем производитель ность хорошо настроенных реляционных систем может приближена к производительности систем на основе много ных баз данных. Идея схемы звезды (star schema) заключается в том, имеются таблицы для каждого измерения, а все факты помеодну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 5.19). Каждый луч схемы звезды задает (в терминологии Кодда) направление консолидации данных по соответствующему измерению. В сложных задачах с многоуровневыми измерениями имеет мысл обратиться к расширениям схемы звезды — схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema). В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (рис. 5.20). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов. В любом случае, если многомерная модель реализуете виде реляционной базы данных, следует создавать длинные В «узкие» таблицы фактов и сравнительно небольшие и «широки И таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных распределенных по незвездообразным нормализованным структурам, хотя при этом следует помнить, что включающие агрегацию запросы при высоконормализованной структуре БД могут выполняться довольно медленно. Ориентация на представление многомерной информации с помощью звездообразных реляционных моделей позволяет избавиться от проблемы оптимизации хранения разреженных матриц, остро стоящей перед многомерными СУБД (где проблема разреженности решается специальным выбором схемы). Хотя для хранения каждой ячейки используется целая запись, которая помимо самих значений включает вторичные ключи, — ссылки на таблицы измерений, несуществующие значения просто не включаются в таблицу фактов. Возможны гибридные системы (Hybrid OLAP — HOLAP), цель которых — совмещение достоинств и минимизация недостатков, присущих предыдущим классам.
|