СППР с помощью хранилищ данных

Содержание

Техническое задание

Введение

1 Реферат……………………………………………………………………………………...5

1. Зарождение концепции хранилища данных…………………………...…...5 

2. Логическая архитектура хранилища  данных……………….………………6
3. Физическая архитектура хранилища данных…………………………...….8
2. Технология разработки и внедрения Хранилища Данных………………………….....9
1. Этапы проекта………………………………………………………………..9
2. Выбор модели данных Хранилища………………………..………………11
3. Выбор Структуры Хранилища Данных………………………………...…14
4. Витрины Данных………………………………………………………...…15
5. Хранилище Метаданных (Репозиторий)……………………………….....18
6. Загрузка хранилища……………………………………………………..…20
7. Анализ данных: OLAP……………………………………………………..22

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

4  Разработка хранилища данных для врача травматолога ………………………….…26

4.1          Постановка задачи…………………………………………………………...26

4.2          Математическая модель………………………………………………….….27

4.3          Логическая модель…………………………………………………….….....27

4.4         Практическая реализация СППР для врача травматолога…………..….29

4.5          Результаты работы…………………………………………………....…….30

Заключение

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

1. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ.

Технические требования разрабатываются  студентом и приводятся ниже в  тексте задания.

2. ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ.

Пояснительная записка оформляется  как единый текстовый документ, содержащий разделы, подразделы и, при необходимости, пункты и подпункты. Она должна начинаться с титульного листа и технического задания, утвержденного руководителем  курсового проекта. Пояснительная  записка оформляется в соответствии с требованиями стандартов «Правила оформления текстовых документов» ГОСТ 7.32 - 2001, ГОСТ 2.105-95 (http://guap.ru/guap/standart/prav_main.shtml). Там же приведены примеры оформления библиографических ссылок.

3. КАЛЕНДАРНЫЙ ГРАФИК РАБОТЫ

Введение

В той или иной степени Системы  Поддержки Принятия Решений (СППР) присутствуют в любой информационной системе (ИС). Поэтому, осознанно или нет, к задаче создания системы поддержки принятия решений организации приступают сразу после приобретения вычислительной техники и установки программного обеспечения. По мере развития бизнеса, упорядочения структуры организации и налаживания межкорпоративных связей, проблема разработки и внедрения СППР становится особенно актуальной. Одним из подходов к созданию таких систем стало использование хранилищ данных. В настоящей статье рассматриваются этапы и методики проведения подобных работ на опыте и с применением методологии компании Price Waterhouse, которая на сегодня выполнила 40 крупномасштабных проектов по созданию корпоративных Хранилищ Данных.

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

СППР первого типа получили название Информационных Систем Руководства (Executive Information Systems, ИСР). По сути, они представляют собой конечные наборы отчетов, построенные на основании данных из транзакционной информационной системы предприятия или OLTP-системы, в идеале адекватно отражающей в режиме реального времени все аспекты производственного цикла предприятия. Для ИСР характерны следующие основные черты:

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

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

1. Реферат

1.1 Зарождение концепции хранилища данных

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

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

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

Решение было найдено и сформулировано в виде концепции Хранилища Данных (Data Warehouse, ХД), которое выполняло бы функции предварительной подготовки и хранения данных для СППР на основе информации из системы управления предприятием (или хранилища данных предприятия), а также информации из сторонних источников, которые в достаточном количестве стали доступны на рынке информации.

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

Ограниченный объем статьи не позволил рассмотреть все аспекты Технологии Хранилищ Данных, поэтому некоторые  вопросы затронуты здесь только вскользь, а отдельные проблемы (например, взаимодействие СППР с Internet) не обсуждаются вовсе. Мы постарались сосредоточиться на ключевых этапах разработки ХД, чтобы охарактеризовать процесс разработки ХД в целом.

1.2. Логическая архитектура хранилища данных

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

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

Некоторые сущности, однако, связаны  в иерархии, которые схема «звезда» корректно не поддерживает. Иерархия — это многоуровневая группировка, каждый уровень которой состоит из непересекающихся групп значений уровня, находящегося непосредственно ниже данного. Так, все продукты могут группироваться в непересекающееся множество категорий, которые, в свою очередь, сгруппированы в непересекающееся множество семейств.

Схема «снежинка» — усовершенствованная схема «звезда», в которой иерархия измерений представляется точным образом благодаря нормализации таблиц измерений. В «звезде», приведенной на рис. 1, набор атрибутов описывает каждое измерение и может быть связан иерархией отношений. Например, измерение продукта FSC состоит из пяти атрибутов: имя продукта (Running Shoe 2000), категория (спортивная), семейство продуктов (обувь), цена (80 долл.) и маржа (80%).

1.3. Физическая архитектура хранилища данных

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

2. Технология разработки  и внедрения Хранилища Данных

2.1. Этапы проекта

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

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

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

Иными словами, бизнес-событие является более устойчивым и более тесно  связанным с информационными  и управляющими потоками понятием, чем бизнес-процесс.

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

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

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

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

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

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

2.2. Выбор модели  данных Хранилища

В самом простом варианте для  Хранилищ Данных используется та модель данных, которая лежит в основе транзакционной системы. Если, как это  часто бывает, транзакционная система  функционирует на реляционной СУБД (Oracle, Informix, Sybase и т. п.), самой сложной задачей становится выполнение запросов ad-hoc, поскольку невозможно заранее оптимизировать структуру БД так, чтобы все запросы работали эффективно.

Однако практика принятия решений  показала, что существует зависимость  между частотой запросов и степенью агрегированности данных, с которыми запросы оперируют, а именно чем более агрегированными являются данные, тем чаще запрос выполняется. Другими словами, круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это наблюдение легло в основу подхода к поиску и выборке данных, называемого Оперативной Аналитической Обработкой (On-line Analytical Processing, OLAP).

OLAP-системы построены на двух  базовых принципах:

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

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

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

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

• поворот;
• проекция. При проекции значения в ячейках, лежащих на оси проекции, суммируются по некоторому предопределенному закону;
• раскрытие (drill-down). Одно из значений измерения заменяется совокупностью значений из следующего уровня иерархии измерения; соответственно заменяются значения в ячейках гиперкуба;
• свертка (roll-up/drill-up). Операция, обратная раскрытию;
• сечение (slice-and-dice).

В зависимости от ответа на вопрос, существует ли гиперкуб как отдельная  физическая структура или лишь как  виртуальная модель данных, различают  системы MOLAP (Multidimensional OLAP) и ROLAP (Relational OLAP). В первых гиперкуб реализуется как отдельная база данных специальной нереляционной структуры, обеспечивающая максимально эффективный по скорости доступ к данным, но требующая дополнительного ресурса памяти. MOLAP-системы весьма чувствительны к объемам хранимых данных. Поэтому данные из хранилища сначала помещаются в специальную многомерную базу (Multidimensional Data Base, MDB), а затем эффективно обрабатываются OLAP-сервером.

Одним из первых производителей таких  систем стала компания Arbor Software, выпустившая продукт Essbase. Компания Oracle предлагает систему Oracle Express, интегрированную с универсальным Oracle Server. Известны и другие производители MOLAP-систем, например SAS Institute. Однако, в отличие от Essbase, их продукты часто интегрированы в приложения, созданные для конкретных вертикальных или горизонтальных рынков, и поставляются лишь в составе этих приложений.

Для систем ROLAP гиперкуб - это лишь пользовательский интерфейс, который  эмулируется на обычной реляционной  СУБД. В этой структуре можно хранить  очень большие объемы данных, однако ее недостаток заключается в низкой и неодинаковой эффективности OLAP - операций. Опыт эксплуатации ROLAP-продуктов показал, что они больше подходят на роль интеллектуальных генераторов отчетов, чем действительно оперативных  средств анализа. Они применяются  в таких областях, как розничная  торговля, телекоммуникации, финансы, где количество данных велико, а  высокой эффективности запросов не требуется. Примерами промышленных ROLAP-систем служат MetaCube фирмы Informix и Discoverer 3.0 фирмы Oracle. На практике иногда реализуется комбинация этих подходов.

Некоторые поставщики программных  продуктов (Sybase - Sybase IQ, Teradata) поставляют более сложные решения, основанные на специальных методах хранения и индексации данных и связей между данными.

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

2.3. Выбор структуры  Хранилища Данных

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

Несмотря на то что предсказать, какую именно информацию и в каком виде захочет получить пользователь, работая с СППР, практически невозможно, измерения, по которым проводится анализ, достаточно стабильны. В процессе подготовки того или иного решения пользователь анализирует срез фактов по одному или нескольким измерениям. Анализ информации, исходя из понятий измерений и фактов, иногда называют многомерным моделированием данных (MultiDimensional Modelling, MDM). Таблицы фактов обычно содержат большие объемы данных, тогда как таблицы измерений стараются сделать поменьше. Этого подхода желательно придерживаться потому, что запрос по выборке из объединения таблиц выполняется быстрее, когда одна большая таблица объединяется с несколькими малыми. При практической реализации ХД небольшие таблицы измерений иногда удается целиком разместить в оперативной памяти, что резко повышает эффективность выполнения запросов.

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

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

При проектировании структуры хранилища  часто возникает желание использовать как можно больше агрегатов и  за счет этого повысить производительность системы. Нетрудно подсчитать, что для  модели "звезда" с 10 измерениями  можно построить 10!=3.63 миллиона различных  агрегированных значений, размещение которых в памяти при установлении связей с соответствующими измерениями  приведет к резкому увеличению занимаемого  дискового пространства и замедлению доступа к данным. Другая крайность  состоит в использовании слишком  малого числа агрегатов, а это  может привести к необходимости  выполнять агрегирование динамически, что заметно снижает эффективность  запросов. По некоторым оценкам, при  определении оптимального количества агрегатов следует придерживаться принципа 80:20 - 80% ускорения достигается  за счет использования 20% кандидатов на агрегаты.