Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Аналитическая обработка данных - файл 1.docx


Аналитическая обработка данных
скачать (62.6 kb.)

Доступные файлы (1):

1.docx63kb.19.11.2011 08:55скачать

содержание

1.docx


Министерство образования и науки РФ.

_____________________

Университет


Реферат по ИОБД на тему:

Аналитическая обработка данных
Выполнила:

гр.

Проверил:

Санкт-Петербург

2011 г.

Оглавление

 3

Введение. 4

1. Хранилища (склады) данных 4

1.1Реляционные хранилища данных 7

1.2.Таблица фактов. 7

 8

1.3.Таблицы измерений 8

2. Способы аналитической обработки данных 8

3. Оперативная аналитическая обработка данных 10

3.1. Требования к средствам оперативной аналитической обработки 12

3.2. Классификация продуктов OLAP по способу представления данных 13

3.2.1. Многомерный OLAP (MOLAP) 14

3.2.2. Реляционный OLAP (ROLAP) 16

Заключение 17

 18

Список литературы. 19


^



Введение.


Да́нные (калька от англ. data) — это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе.

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

^ Обработка данных [data processing, information processing] — процесс приведения данных к виду, удобному для использования. Независимо от вида информации, которая должна быть получена, и типа оборудования любая система, О. д. выполняет три основные группы операций: подбор исходных, входных данных, собственно их обработку (в процессе которой система оперирует промежуточными данными), получение и анализ результатов, т. е. выходных данных.

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

В своём реферате я рассмотрю аналитическую обработку данных, способы такой обработки данных.
^

1. Хранилища (склады) данных


В области информационных технологий всегда сосуществовали два класса систем:

  • системы, ориентированные на операционную (транзакционную) обработку данных; в англоязычной литературе они часто называются термином OLTP (On-Line Transaction Processing, оперативная транзакционная обработка), в противовес OLAP - оперативной аналитической обработке ; А. А. Сахаров определяет их термином "системы обработки данных" (СОД);

  • системы, ориентированные на аналитическую обработку данных - системы поддержки принятия решений (СППР), или Decision Support Systems (DSS).

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

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

Целью построения корпоративного хранилища данных является интеграция, актуализация и согласование оперативных данных из разнородных источников для формирования единого непротиворечивого взгляда на объект управления в целом. При этом в основе концепции хранилищ данных лежит признание необходимости разделения наборов данных, используемых для транзакционной обработки, и наборов данных, применяемых в системах поддержки принятия решений. Такое разделение возможно путем интеграции разъединенных в СОД и внешних источниках детализированных данных в едином хранилище, их согласования и, возможно, агрегации. W. Inmon, автор концепции хранилищ данных , определяет такие хранилища как:

  • “предметно-ориентированные,

  • интегрированные,

  • 

  • неизменчивые,

  • поддерживающие хронологию

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

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

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

  2. Интегрированный взгляд на распределенное корпоративное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Таким образом, временная недоступность хотя бы одного из источников может либо сделать работу информационно-аналитической системы (ИАС) невозможной, либо привести к ошибочным результатам.

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

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

  5. Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД. Основное назначение СОД - оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе.

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

приводятся к единому формату, согласовываются и, в ряде случаев, агрегируются до минимально требуемого уровня обобщения.

Облегченным вариантом корпоративного хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. Концепция витрин данных была предложена Forrester Research в 1991 году. При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания. В 1994 году M. Demarest [32] предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру:

  • общекорпоративное централизованное хранилище данных;

  • тематические витрины данных на уровне подразделений;

  • рабочие места конечных пользователей, снабженные аналитическим инструментарием.

Рассмотренная концепция ориентирована исключительно на хранение, а не на обработку корпоративных данных. Она не предопределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным. Таким образом, она оставляет свободу выбора во всем, что касается:

  • способов представления данных в целевом хранилище (например, реляционный, многомерный);

  • режимов анализа данных хранилища.



^

1.1Реляционные хранилища данных


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

Типичная структура хранилища данных существенно отличается от структуры обычной реляционной СУБД. Как правило, эта структура денормализована (это повышает скорость выполнения запросов) и может допускать избыточность данных. Типичная структура хранилища данных приведена на рис. 1. Основные составляющие этой структуры - таблица фактов (fact table) и таблицы измерений (dimension tables).






^

1.2.Таблица фактов.


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

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



1.3.Таблицы измерений


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

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

В состав современных средств проектирования данных, таких, как CA AllFusion Modelling Suite, обычно входят шаблоны для проектирования хранилищ данных. Следует сказать, что для создания реляционных хранилищ данных иногда применяются специализированные СУБД, хранение данных в которых оптимизировано с точки зрения скорости выполнения запросов. Пример такого продукта - Sybase Adaptive Server IQ, реализующий нетрадиционный способ хранения данных в таблицах. Однако создавать хранилища можно и в обычных реляционных СУБД
^

2. Способы аналитической обработки данных


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

По критерию режима анализа данных информационно-аналитические системы подразделяются на две категории:

  • статические (включающие предопределенный набор сценариев обработки данных и составления отчетов); в эту категорию входят так называемые информационные системы руководителя (ИСР);

  • динамические (поддерживающие построение и выполнение нерегламентированных запросов и формирование отчетов произвольной формы).

Очень часто ИАС, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические СППР,или Информационные системы руководителя (ИСР) - (Executive Information Systems, EIS) - содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений (ПРИМЕЧАНИЕ. По определению В. Пржиялковского, ИСР - это "компьютерная система, позволяющая ... предоставлять информацию в распоряжение старшего управляющего персонала с ограниченным опытом обращения с ЭВМ".). Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов; однако, каждый новый, непредусмотренный при проектировании такой системы, запрос должен быть сначала формально описан, передан программисту, закодирован и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.

Динамические СППР, напротив, ориентированы на обработку нерегламентированных, неожиданных (ad hoc) запросов аналитиков к данным. Наиболее глубоко требования к таким 

системам рассмотрел E. F. Codd в статье, положившей начало концепции OLAP. OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучения их результатов, каждый из которых может породить потребность новой серии запросов.

Но динамические СППР могут действовать не только в области оперативной аналитической обработки (OLAP); поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах.

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

  2. Сфера агрегированных показателей. Комплексный взгляд на собранную в хранилище данных информацию, ее обобщение и агрегация, гиперкубическое представление и многомерный анализ являются задачами систем оперативной аналитической обработки данных (OLAP). Здесь можно или ориентироваться на специальные многомерные СУБД, или (что, как правило, предпочтительнее) оставаться в рамках реляционных технологий. Во втором случае заранее агрегированные данные могут собираться в БД звездообразного вида, либо агрегация информации может производиться на лету в процессе сканирования детализированных таблиц реляционной БД .

  3. Сфера закономерностей. Интеллектуальная обработка производится методами интеллектуального анализа данных (ИАД, Data Mining), главными задачами которых являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и/или (с определенной вероятностью) прогнозируют развитие некоторых процессов.

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

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


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

3. Оперативная аналитическая обработка данных


В основе концепции оперативной аналитической обработки (OLAP) лежит многомерное представление данных. Термин OLAP ввел E. F. Codd в 1993 году. В своей статье он рассмотрел недостатки реляционной модели, в первую очередь невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.

Следует заметить, что Кодд обозначает термином OLAP многомерный способ представления данных исключительно на концептуальном уровне. Используемые им термины - "Многомерное концептуальное представление" ("Multi-dimen-sional conceptual view"), "Множественные измерения данных" ("Multiple data dimensions"), "Сервер OLAP" ("OLAP server") - не определяют физического механизма хранения данных (термины "многомерная база данных" и "многомерная СУБД" не встречаются ни разу). Однако в большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД (это в принципе неверно, поскольку сам Кодд в отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP"). Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что, вообще говоря, некорректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Поэтому более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP.



По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).
Рис. 2. Измерения и направления консолидации данных.

^

3.1. Требования к средствам оперативной аналитической обработки


Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (табл. 1).

^ Таблица 1. Правила оценки программных продуктов класса OLAP.

1.


Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View)

Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice" - перевод С. Д. Кузнецова, выступление на 3-й ежегодной конференции "Корпоративные базы данных '98"), вращения (rotate) и размещения (pivot) направлений консолидации.

2.

Прозрачность (Transparency)

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

3.

Доступность (Accessibility)

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

для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.



4.

Устойчивая производительность (Consistent Reporting Performance)

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

5.

Клиент - серверная архитектура (Client-Server Architecture)

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

6.

Равноправие измерений (Generic Dimensionality)

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

7.

Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling)

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

8.

Поддержка многопользовательского режима (Multi-User Support)

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

9.

Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations)

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




10.

Интуитивное манипулирование данными (Intuitive Data Manipulation)

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

11.

Гибкий механизм генерации отчетов (Flexible Reporting)

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

12.

Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels)

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

^

3.2. Классификация продуктов OLAP по способу представления данных


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

  1. Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software, Oracle Express Server компании Oracle) относились к классу MOLAP (Multidimensional OLAP), то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки и либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей. Наиболее мощным (и самым дорогим) представителем данного класса является SAS System компании SAS Institute. SAS System состоит из множества подсистем-модулей, которые позволяют проектировать готовые решения - расширенные ИСР, дополненные функциями OLAP и (при использовании специальных модулей) - интеллектуального анализа .

  2. Благодаря такому подходу достигается компромисс между гибкостью настройки и простотой использования, поскольку разработкой системы поддержки принятия решений занимаются администраторы на этапе проектирования, а аналитики имеют дело с уже адаптированной для их потребностей системой.

  3. Возникшие после программной статьи Кодда системы оперативной аналитической обработки реляционных данных (Relational OLAP, ROLAP) позволили представлять данные, хранимые в классической реляционной базе, в многомерной форме . К этому классу относятся DSS/Server и DSS/Agent компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам первого класса, они требуют значительных затрат на обслуживание 

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

  5. Наконец, появившиеся около 1997 года первые гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP. Однако, этот класс систем является новым, и судить о его действительных преимуществах пока рано.

Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP и/или интегрированные с внешними средствами, выполняющими такие функции. Эти довольно развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Для работы с небольшими, просто организованными базами эти средства подходят наилучшим образом. Основными представителями этого класса являются BusinessObjects одноименной компании , BrioQuery компании Brio Technology и PowerPlay компании Cognos .
^

3.2.1. Многомерный OLAP (MOLAP)


В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:

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

  • поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).

Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.

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

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

С другой стороны, имеются существенные ограничения.

  1. Многомерные СУБД не позволяют работать с большими базами данных. На сегодняшний день их реальный предел - 10-20 гигабайт. К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, как правило, соответствуют в 2.5-100 раз меньшему объему исходных детализированных данных, то есть в лучшем случае нескольким гигабайтам.

  2. Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. Ячейки гиперкуба хранятся в них в виде логически упорядоченных массивов (блоков фиксированной длины), причем именно такой блок является минимальной индексируемой единицей. Хотя в многомерных СУБД блоки, не содержащие ни одного определенного значения, не хранятся, это решает проблему только частично. Поскольку данные хранятся в упорядоченном виде, неопределенные 

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

  4. В настоящее время для многомерных СУБД отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными.

  5. Многомерные СУБД не поддерживают репликацию данных, часто используемую в качестве механизма загрузки.

Следовательно, использование многомерных СУБД оправдано только при следующих условиях.

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

  2. Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).

  3. Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.

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

3.2.2. Реляционный OLAP (ROLAP)


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

  1. При оперативной аналитической обработке содержимого хранилищ данных инструменты ROLAP позволяют производить анализ непосредственно над хранилищем (потому что в подавляющем большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД).

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

  3. Системы ROLAP могут функционировать на гораздо менее мощных клиентских станциях, чем системы MOLAP, поскольку основная вычислительная нагрузка в них ложится на сервер, где выполняются сложные аналитические SQL-запросы, формируемые системой.

  4. Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и разграничения прав доступа.

  5. Реляционные СУБД имеют реальный опыт работы с очень большими базами данных и развитые средства администрирования.

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



В общем случае факты имеют разные множества измерений, и тогда их удобно хранить не в одной, а в нескольких таблицах; кроме того, в различных запросах пользователей может интересовать только часть возможных измерений. Но при таком подходе при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Для решения этой проблемы авторы работы предлагают специальное расширение для языка SQL (оператор "GROUP BY CUBE" и ключевое слово "ALL”. В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema).В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений. Это позволяет добиться наилучшей производительности, но часто приводит к избыточности данных.

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

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

Заключение


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

^



Список литературы.


1. Федоров А., Елманова Н. Введение в OLAP-технологии Microsoft. - М.: Диалог-МИФИ, 2002.

2.http://ru.wikipedia.org/wiki/Базы данных

3.http://ru.wikipedia.org/wiki/%C4%E0%ED%ED%FB%E5#.D0.94.D0.B0.D0.BD.D0.BD.D1.8B.D0.B5_.D0.B2_XML

4. http://infovisor.ivanovo.ru/press/paper04.html#31

5.http://slovari.yandex.ru/~книги/Лопатников/Обработка данных/

6.http://ru.wikipedia.org/wiki/OLAP


Скачать файл (62.6 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации