47197 (597325), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

При построении схемы взаимодействия корпоративного Хранилища и Витрин Данных в рамках создания СППР рекомендуется определить некоторую специальную структуру для хранения исторических данных и дополнительно развернуть Витрины, заполняемые данными из этой структуры. Тем самым удается разделить два процесса: накопление исторических данных и к анализ.

Современные витрины данных должны:

• хранить сотни гигабайт данных и обеспечивать сложные разновидности аналитической обработки, например, из области добычи данных (data mining);

• обеспечивать удаленный доступ к витрине данных для сотен пользователей с использованием технологии Internet и Intranet;

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

2. 5. Представление и основные характеристики OLAP-технологии, понятие многомерного статистического анализа, характеристика систем MOLAP и ROLAP

Оперативная аналитическая обработка данных (OLAP)

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

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

В основе OLAP лежит многомерное концептуальное представление (multi-dimensional conceptual view) – наиболее естественный взгляд управляющего персонала на объект управления; множественная перспектива из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ.

Каждое измерение включает направления консолидации данных из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения «предприятие – подразделение – отдел – служащий». Измерение Время может даже включать два направления консолидации – «год – квартал – месяц – день» и «неделя – день», поскольку счет времени по месяцам и по неделям несовместим. В этом случае возможен произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция раскрытия или спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция свертки или подъема (rolling up) означает движение от низших уровней к высшим.

Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции сечения «анализа вдоль и поперек» («slice and dice»), вращения (rotate) и размещения (pivot) направлений консолидации. Пользователь не должен знать, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся. Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формальном языке. Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе. Настоятельно рекомендуется допущение в каждом серьезном OLAP‑инструменте как минимум пятнадцати, а лучше двадцати измерений в аналитической модели. Каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.

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

Если принимается второй вариант, сразу появляется следствие – система должна скрывать от конечного пользователя физическую структуру и способы хранения данных. Знать такие подробности пользователю совсем не нужно. Такая задача решается введением семантического слоя, который ставит каждому бизнес-термину в соответствие способ получения данных.

В основе организации данных OLAP лежит понятие гиперкуба или многомерного куба данных, в ячейках которого хранятся анализируемые (числовые) данные, например объемы продаж. Измерения – это совокупности значений других данных, скажем, названий товаров и названий месяцев года. В простейшем случае двумерного куба мы получаем таблицу, показывающую значения уровней продаж по товарам и месяцам. Дальнейшее усложнение модели данных возможно по нескольким направлениям:

• Увеличение числа измерений – данные о продажах не только по месяцам и товарам, но и по регионам. В этом случае куб становится трехмерным;

• усложнение содержимого ячейки – например, нас может интересовать не только уровень продаж, но и чистая прибыль или остаток на складе. В этом случае в ячейке будет несколько значений;

• введение иерархии в пределах одного измерения – общее понятие ВРЕМЯ естественным образом связано с иерархией значений: год состоит из кварталов, квартал из месяцев и т.д.

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

В рамках каждого измерения модели данных OLAP могут быть организованы в виде иерархии, представляющей различные уровни их детализации. Например, в измерении «Время» можно выделить уровни «Годы», «Месяцы» и «Дни». Точно так же в рамках измерения «География» вы могли бы ввести уровни «Страна», «Регион», «Штат/провинция» и «Город». Каждая конкретная модель OLAP будет включать определенные значения для каждого уровня иерархии. При просмотре данных OLAP пользователь будет перемещаться вверх и вниз между уровнями данных, чтобы увидеть больше деталей или получить сводную информацию.

В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная физическая структура или лишь как виртуальная модель данных, различают системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). На заре развития технологии OLAP большинство производителей считало, что единственное возможное решение при создании OLAP‑приложений связано с использованием специализированной, нереляционной модели хранения. Позднее другие производители обнаружили, что применение определенных структур базы данных (схемы «звезда» и «снежинка»), индексации и хранения агрегатов позволяет использовать для OLAP реляционные системы управления базами данных. Такие производители назвали свою технологию Relational OLAP (ROLAP). Поставщики более старых систем затем приняли термин MOLAP (multidimensional OLAP – многомерная OLAP).

Недавно разработаны гибридные решения для OLAP, которые иногда называют HOLAP (hybrid OLAP). Одновременно используя архитектуры ROLAP и MOLAP, они соединяют лучшие черты обоих решений – превосходную производительность и высокую масштабируемость. Один из подходов к созданию HOLAP включает в реляционную базу данных записи с детальной информацией (занимающие наибольший объем) и в то же время помещает агрегаты в отдельное хранилище архитектуры MOLAP.

Для большинства продуктов OLAP предварительное вычисление агрегатов – это основная стратегия, обеспечивающая выигрыш в производительности. В то же время предварительная агрегация связана со значительными затратами: число агрегатов легко может превысить число исходных точек с детальной информацией, что приводит к резкому росту объема хранимых данных, причем коэффициент взрыва данных может составить около 240, так что для управления 10 Мб входных данных потребовалась бы емкость устройства хранения 2,4 Гб.

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

2. 6. Классификация ИИС. ИИС как совокупность нескольких технологий

Интеллектуальные информационные системы (ИИС)

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

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

Важность этих систем для теории и практики и практики искусственного интеллекта определяется двумя обстоятельствами:

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

• в структуре специализированных процессоров или архитектур этих систем реализуются некоторые начальные этапы технологии обработки данных, характерных для технологии искусственного интеллекта. Это относится к организации хранения и обработки больших объемов данных в виде многомерных кубов с учетом семантических взаимосвязей

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

Экспертные системы представляли собою автономные программные комплексы не интегрированные с базами данных и системами аналитических вычислений. Понятие «экспертная система» закрепилось за такими автономными программами, ориентированными на определенную достаточно узкую сферу применения.

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

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

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

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

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

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

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

Характеристики

Список файлов книги