РАЗРАБОТКА И ВЕДЕНИЕ ХРАНИЛИЩА ДАННЫХ ДЛЯ СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ

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

2015-07-16

79.68 KB

52 чел.


Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск


УЗБЕКСКОЕ АГЕНТСТВО СВЯЗИ И ИНФОРМАТИЗАЦИИ

ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ

 

На правах рукописи

 

Хамидов Умиджон Хамзаевич

 

РАЗРАБОТКА И ВЕДЕНИЕ ХРАНИЛИЩА ДАННЫХ ДЛЯ СИСТЕМ

ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ

 

Специальность: 5А521902 - «Управление и обработка информации»

 

ДИССЕРТАЦИЯ

на соискание степени магистра информационных технологий

 

 

        Работа рассмотрена

        и допускается к защите.

        Зав. кафедрой ИТ

        ___________________

 

 

«       »                         2012 г

 

Научный руководитель:

 

д.т.н. Гаипназаров Т.С. _______            

 

 

«       »                           2012 г

 

 

 

Ташкент 2012
2

 

СОДЕРЖАНИЕ

ВВЕДЕНИЕ  4

ГЛАВА 1. АНАЛИЗ ОБЪЕКТА ИССЛЕДОВАНИЯ  9

1.1.  Базовые понятия информационно-аналитических систем  9

1.2.  Data Warehouse – хранилище данных – ХД - систем

обработки данных

13

1.3.  Подходы к архитектуре хранилищ данных – ХД  26

1.4.  Анализ процесса принятий решений в системе высшего

образования

34

1.5.  Постановка задачи  36

1.6.  Выводы по первой главе  37

ГЛАВА  2.  ПРОЕКТИРОВАНИЕ  И  РАЗРАБОТКА

ХРАНИЛИЩЕ ДАННЫХ

39

2.1. Определение требований  39

2.2. Анализ вопросов  39

2.3. Определение структуры ХД  40

2.4. OLAP куб  49

2.5. Выводы ко второй главе  56

ГЛАВА 3. РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ МНОГОМЕРНОГО

АНАЛИЗА ДАННЫХ В СППР ДЛЯ УПРАВЛЕНИЯ ВНЕДРЕНИЯ

ИНФОРМАЦИОННО-КОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ В

УЧЕБНЫЙ ПРОЦЕСС МВССО

57

3.1. Разработка хранилище данных для многомерного анализа  57

3.2. BI-решения Microsoft Analysis Services  72

3.3. Выводы по третьей главе  84

ЗАКЛЮЧЕНИЕ  85

ЛИТЕРАТУРА  86

ПРИЛОЖЕНИЕ  87


Аннотация

 

Диссертационная  работа  посвящена  разработка  и  ведение  хранилища

данных  для  систем  поддержке  принятий  решений  на  примере  образование.  

Проведено  исследование  технологий  хранилище  данных.  Рассмотрен  анализ

процесса  принятий  решений  в  системе  высшего  образования.  Объектом

исследования в диссертационной работ является процесс принятия решения в

Министерстве  высшего  и  среднего  специального  образования  на  основе

анализа  данных полученных от подведомственных организации, а предметом

исследования  -  модели  систем  поддержки  принятия  решений  на  основе

многомерных моделей баз и хранилищ данных. В работе для решения задачи  

использованы  методы  основанные  на  методологии  структурного  анализа  и

проектирования  (SADT  -  Structured  Analysis  &  Design  Technique),  теории 

реляционных  баз  данных,  технологии  хранилищ  данных  и  объектно-

ориентированных методах построения программных систем.

Проведен обзор и анализ информационно-аналитических систем. Изучена

технология хранилище данных. Приведены подходы к архитектуре хранилищ

данных.  Рассмотрено  процесса  принятий  решений  в  системе  высшего

образования.  Разработана  постановка  задачи  создание  и  ведение  хранилище

данных  для  министерства  высшего  и  среднего  специального  образования.

Определено  требования  к  разрабатываемому  хранилищу  данных.  Проведен

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

для ответа на запрос пользователей. Предложено структура хранилища данных

для  анализа  материально  техническую  базу  высшего  образовательного

учреждений.  Разработано  хранилище  данных  для  многомерного  анализа.

Проведен  сравнительный  анализ  OLAP  серверов.  Для  разработки  хранилища

данных  было  создан  многомерный  куб  «Анализ  показателей  материально

технической базы ВОУ» в Microsoft Analysis Services.  

Abstract

 

Dissertational  work  is  devoted  development  and  maintaining  data  warehouse

given for systems to support of decision-making on an example education. Research

of technologies data warehouse is carried out. The analysis of process of decision-

making  in  system  of  the  higher  education  is  considered.  Object  of  research  in

dissertational  works  is  decision-making  process  in  the  Ministry  of  the  higher  and

secondary  vocational  education  on  the  basis  of  the  analysis  of  data  received  from

subordinated  the  organization,  and  an  object  of  research  -  models  of  systems  of

support of decision-making on  the basis  of  multidimensional  models of  data  bases

and  data  warehouse.  In  work  for  the  solution  of  a  task  methods  based  on

methodology of the structural analysis and design (by SADT - Structured Analysis &

Design Technique), theories of relational databases, technologies of storages of data

and object-oriented methods of creation of program systems are used.

The review and the analysis of information and analytical systems is carried out.

The technology data warehouse is studied. Approaches are brought to architecture of

data warehouse. It is considered process of decision-making in system of the higher

education. Task statement creation and maintaining data warehouse is developed for

the Ministry of Higher and Secondary Special Education. It is defined requirements

to developed data warehouse. The analysis of questions is carried out and is defined

the list of data which can be demanded for the answer to inquiry of users. It is offered

structure  of  data  warehouse  for  the  analysis  financially  technical  base  of  high

educational universities. The data warehouse is developed for the multidimensional

analysis.  The  comparative  analysis  of  OLAP  of  servers  is  carried  out.  For

development  of  data  warehouse  was  the  multidimensional  cube  «Analysis  of  the

material and technical base of HEU » in Microsoft Analysis Services is created.

Mazmunnoma

 

Dissertatsiya  ishi  qaror    qabul  qilish  qo„llab  quvvatlovchi  tizimlar  uchun

ma„lumotlar  omborini  ishlab  chiqish  va  joriy  etish  masalasiga  bag„ishlangan.

Ma„lumotlar ombori texnologiyasi tadqiq qilingan. Oliy ta„lim tizimida  qaror qabul

qilish jarayoni tahlili kurib chiqilgan. Dissertatsiya ishining tadqiqot ob„ekti Oliy va

o„rta  maxsus  ta„lim  vazirligida  qaror  qabul  qilish  jarayoni,  tadqiqot  predmeti

ma„lumotlar ombori va bazasining ko„p ulchovli modellari asosida qaror qabul qilish

tizimi  modeli.  Masalani  yechishda  strukturaviy  tahlil  va  loyihalashtirish

metodologiyasi  (SADT  -  Structured  Analysis  &  Design  Technique),  relyatsion

ma„lumotlar  bazasi  nazariyasi,  ma„lumotlar  ombori  texnoloniyasi  hamda  ob„ektga

yo„naltirilgan usullar dasturiy tizimlarni yaratish metodlaridan foydalanilgan.

Tahliliy  axborot  tizimlari  tahlil  amalga  oshirilgan.  Ma„lumotlar  ombori

texnologiyasi  o„rganib  chiqilgan.  Ma„lumotlar  ombori  arxitekturasi  turlari  ko„rib

chiqilgan. Oliy ta„lim vazirligida tahlil  olib borish hamda qaror qabul qilish jarayoni

o„rganilgan va mavjud holatda kamchiliklarni bartaraf etish hamda tahlil jarayonini

yanada  takomillashtirish  bo„yicha  takliflar  ishlab  chiqilgan.  Ma„lumotlar  omborini

loyihalashtirishda  foydalanuvchilar  tomonidan  qo„yiladigan  talablar  aniqlangan  va

belgilab  olingan.  Shuningdek  ma„lumotlar  omborida  foydalanuvchilar  so„roviga

javob berish uchun kerak bo„ladigan malumotlar ro„yhati ishlab chiqilgan, va tahlili

amalga oshirilgan. Oliy ta„lim muassasalarining moddiy texnik bazasini tahlil qilish

mo„ljallangan  ma„lumotlar  ombori    strukturasi  loyihalashtirilgan.  Ushbu  loyiha

asosida    ko„p  ulchovli  tahlil  uchun  ma„lumotlar  ombori  yaratilgan.  OLAP

serverlarning  tahlili  o„tkazilgan  va  tahlil  natijalari  asosida  Microsoft  Analysis

Services dasturi tanlab olingan. Ushbu dasturiy muhitda “Oliy ta„lim muassasasining

moddiy texnik bazasining tahliliy ko„rsatkichlari” ko„p ulchovli kub ishlab chiqilgan.
3

 

ВВЕДЕНИЕ

 

Актуальность  темы.  Важнейшие  задачи  развития  и  внедрения

современных  систем  компьютеризации  и  информационно-коммуникационных

технологий  четко  определены  государством,  изложены  в  Указе  Президента

Республики  Узбекистан  от  30  мая  2002  года  «О  дальнейшем  развитии

компьютеризации  и  внедрении  информационно-коммуникационных

технологий». Использование ИКТ в обществе является главным составляющим

Концепции  информатизации,  разработанной  в  соответствии  с  Указом

Президента  Республики  Узбекистан  от  30.05.02  года.  «Сегодня  нет

необходимости  доказывать,  что  ХХI  век,  по  общему  признанию,  становится

веком  глобализации  и  стирания  границ,  информационно-коммуникационных

технологий и Интернета, веком все более растущей конкуренции на мировом

пространстве и мировом рынке.» отметил при вступительном речи на открытие

международный  конференции  «Подготовка  образованного  и  интеллектуально

развитого  поколения  –  как  важнейшее  условие  устойчивого  развития  и

модернизации страны» Президент Узбекистана.

В  настоящее  время  базы  данных  широко  используются  в  нашей

повседневной  жизни.  Любая,  успешно  работающая  организация,  хранит  свои

данные и обрабатывает их с использованием современных систем управления

базами  данных.  Они  повсеместно  используются  для  получения  сведений  о

сотрудниках, о товарах, о продажах, бухгалтерских данных, данных бизнеса и

т.д.  Но  информация  сама  по  себе  без  обработки  не  представляет  интерес,

поэтому работа с базами данных всегда требует совершенствования способов

хранения данных, а также сокращения времени выборки данных, необходимых

для получения своевременной и необходимой информации.

Важным  фактором  в  современных  рыночных  условиях  является

оперативное  принятие  деловых  решений.  Однако  многие  предприятия

сталкивается с таким препятствием, как большой объѐм и высокая сложность
4

 

данных. Решением данного вопроса может стать создание системы поддержки

принятия  решений  (СППР)  на  основе  хранилищ  данных  (ХД).  Хранилище

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

данных, файлов,  электронных  таблиц  и  др.),  на  основе  которых  строятся

процессы принятия решений и анализа данных.  

Системы  поддержки  принятия  решений  (СППР)  -  это  системы,

обладающие  средствами  ввода,  хранения  и  анализа  данных,  относящихся  к

определѐнной предметной области, с целью поиска решений.

Основная  задача  СППР  -  предоставление  аналитикам  инструмента  для

выполнения  анализа  данных.  СППР  не  гарантирует  правильных  решений,  а

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

для изучения и анализа.

2011  году  10  мая  принят  Постановление  Президента  Республики

Узбекистан  «О  мерах  по  укреплению материально-технической  базы  высших

образовательных  учреждений  и  кардинальному  улучшению  качества

подготовки высококвалифицированных специалистов». Постановлением главы

государства одобрена Программа модернизации материально-технической базы

вузов  и  улучшения  качества  подготовки  специалистов  на  2011-2016  годы.

Министерстве  высшего  и  среднего  специального  образования  возложена

утверждения  адресные  списки  оснащения  зданий  и  сооружений  высших

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

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

образовательного учреждения. Поэтому на сегодняшний день   является особо

актуальным  реализация  подсистемы  многомерного  анализа  данных  в  СППР

дающий  возможность    анализировать  показателей  материально-технической

обеспеченности высших образовательных учреждений.

Подсистема многомерного анализа данных разработана на основе проекта

кафедры  «Теоретико-методологическое  основы  построения  интеллектуальных

программно-технических  систем  представления  и  обработки  данных  для
5

 

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

структурах».

Степень  изученности  проблемы.  Исследованию  СППР  на  основе  ХД

посвящены работы Э.Спирли, Р.Кимбала, А.А.Барсегяна, И.А.Чубуковой, М.С.

11.АЈга\уа1,  Р.УаззШасПя,  С.Хайкина,  И.С.Ризаева,  А.Н.Кузьмина,

Л.Ю.Емалетдиновой, Н.М.Вдовичева и др.

Цель  работы.  Целью  работы  является  повышение  эффективности

обработки  и  хранения  больших  объемов  информации  за  счет  использования

технологии хранилищ данных.

Задачами исследования являются:

1.  Проанализировать  и  исследовать  существующие  способы  хранения  и

обработки информации.

2.  Создать  методику  разработки  концептуальной  модели  многомерного

представления  данных  для  эффективного  хранения  и  быстрого  выполнения

запросов при хранении объектной информации.

3.  Провести  экспериментальные  исследования  моделей  и  алгоритмов  с

помощью  разработанных  программ  интеллектуального  анализа  данных  и

системы поддержки принятия решений в среде СУБД SQL SERVER 2008 R2 на

основе концепции хранилищ данных

Объект  исследования.  Объектом  исследования  является  процесс

принятия  решения  в  Министерстве  высшего  и  среднего  специального

образования  на  основе  анализа    данных  полученных  от  подведомственных

организации.

Методы  исследования.  Методы  исследования,  применяемые  в  работе,

основаны  на  методологии  структурного  анализа  и  проектирования  (SADT  -

Structured  Analysis  &  Design  Technique),  теории  реляционных  баз  данных,

технологии  хранилищ  данных  и  объектно-ориентированных  методах

построения программных систем.
6

 

Научная новизна работы. Разработана многомерной модели хранилища

данных  в  сфере  высшего  образования,  а  также  дано  формализованное

описание гиперкуба и возможных операций над кубом данных.

Предмет исследования. Модели систем поддержки принятия решений на

основе многомерных моделей баз и хранилищ данных.

Научная задача. Разработка новых аналитических моделей и алгоритмов

интеллектуального  анализа  данных  и  программного  комплекса  системы

поддержки  принятия  решений  на  основе  многомерных  моделей  хранилищ

данных.

Научная и практическая значимость работы заключается в реализации

предложенного  подхода  в  СППР  для  управления  Внедрения  информационно

коммуникационных  технологий  в  учебный  процесс  Министерства  высшего  и

среднего специального образования РУз.

Практическая ценность диссертации состоит в следующем:

-разработан хранилище данных на языке SQL в среде СУБД MSSQL 2008

R2;

-  разработаны  алгоритмы  и  комплексы  программ  в  среде  SQL  Server

Business Development Studio для решения задач загрузке, очищение данных из

внешних источников данных.

Апробация  работы.  Основные  результаты  работы  докладывались  и

обсуждались на:

•  научных  семинарах  кафедры  «Информационные  технологии»

Ташкентского университета информационных технологий

•  международная  конференция  ITPA  2011  ТУИТ  (сентябрь,  2011  г.)  на

тему «Развитие информационных технологий в Азии»;

• Научно-практической  конференции  аспирантов,  магистрантов  и

одаренных  студентов  Каршинский  Инженерно-Экономический  Институт

(КИЭИ,  Карши,  май,  2012  г.)  на  тему  «Иқтисодиѐтни  модернизация  қилиш
7

 

шароитида  ишлаб  чиқариш  соҳаларини  инновацион  ривожлантириш

муаммолари».

Опубликованность  результатов.  По  теме  диссертации  опубликовано  2

статьи.

Структура и объем работы. Выпускная диссертационная работа состоит

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

Интернет ресурсов и приложения.

Во введении обоснована актуальность работы, поставлены цели и задачи,

научная новизна диссертационной работы.

В  первой  главе  –  «Анализ  объекта  исследования»  приведено  описание  

концепция хранилище данных и  OLAP, анализ процесса принятий решения в

МВССО.  

Во  второй  главе  –  «Проектирование  и  разработка  хранилище  данных»

рассматриваются  вопросы  проектирования:  разработка  хранилище  данных  на

основы поставленной задаче.  

В третьей главе – «Реализация подсистемы многомерного анализа данных

в  СППР  для  департамента  ИКТ  МВССО»  описывается  процесс  сравнение

OLAP серверов, и на основы выбранного OLAP сервер создается многомерный

куб для анализа.  

В  заключении  приведены  основные  полученные  результаты

исследования.

Содержание работы изложено в 105 страницах текста, а также включает в

себя 39 рисунков и 5 таблицу.

Автор  выражает  свою  искреннюю  благодарность  профессору

Зайниддинову Х. Н., доценту кафедры «ИТ» Гаипназарову Т. С. за поддержку,

консультации, адекватное оценивание и за оказанное внимание в течение всего

времени работы над диссертацией.


8

 

ГЛАВА 1. АНАЛИЗ ОБЪЕКТА ИССЛЕДОВАНИЯ

1.1.  Базовые понятия информационно-аналитических систем

 

Современный этап развития рыночных отношений в узбекской экономике

(первое  десятилетие  ХХI  века)  характеризуется  началом  экономического

подъема.  Период  времени  быстрых,  в  значительной  мере  интуитивных,

импровизационных,  а  зачастую  и  силовых  решений  меняется  на  зону

продуманных,  просчитанных  выводов  и  решений  —  оперативных,

инвестиционных.

Необходимо  также  принимать  во  внимание  открытость  экономики

Узбекистана  и  связанной  с  ней  конкуренции  с  высокоразвитыми

экономическими  субъектами.  В  регионах  мира  со  сложившейся  развитой

рыночной  экономикой  достижение  заметного  повышения  прибыли  (от  долей

процента)  связано  со  сложной  аналитической  работой  с  использованием

новейших достижений науки: математики всех направлений, информационных

технологий  (IT),  которые  питают  и  подкрепляют  экономические  науки,

менеджмент,  маркетинг,  образование,  социологию,  юриспруденцию  и  т.д.

Начинают  приобретать  определяющее  значение  знания  о  протекающих

хозяйственных процессах.

На  успех  ведения  дела  влияют  как  объективные,  так  и  субъективные

факторы.

К объективным факторам можно отнести:

• закономерности протекания хозяйственных процессов,

• правовую среду,

• неписаные правила и традиции ведения дел,

• экономическую конъюнктуру и т.д.

Большое  значение  имеет  субъективный  фактор,  под  которым  будем

понимать  влияние  на  ход  бизнес-процессов  работников  предприятия  и  в

особенности лиц, принимающих решения (ЛПР).
9

 

Для выработки и принятия соответствующих складывающейся обстановке

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

требованиям  полноты,  достоверности,  своевременности  (актуальности),

полезности.

Основополагающую  роль  в  подготовке  принятия  решений  играет  его

обоснование поимеющейся у ЛПР информации. Ее, как правило, получают из

различных  внутренних  и  внешних  источников.  В  интересах  выработки

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

которые  складываются  из  отражения  деятельности  (функционирования)

объекта  в  документах,  других  видах  и  способах  сбора,  обработки,  хранения

информации,  а  также  внешние  по  отношению  к  объекту  информационные

ресурсы, например (если это предприятие) — корпорации, отрасли, региона, а

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

литературы, всемирной информационной сети Internet и т.д.

Таким образом, границы информационного пространства как отображения

деятельности  предприятия  и  его  взаимодействия  с  внешней  средой,  в  рамках

которого  принимаются  решения,  выходят  далеко  за  пределы  предприятия.

Одной из первостепенных задач при подготовке и принятии решений является

анализ  имеющейся  в  распоряжении  ЛПР  информации,  который  является

фундаментом обоснования решения.

Объемы  информации,  необходимой  и  используемой  при  принятии

решений, достигают десятков и сотен мегабайт, а в крупных корпоративных и

общегосударственных  системах  и  терабайт  (1012  Гигабайт).  Информация

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

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

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

Эти  обстоятельства  вынуждают  использовать  имеющиеся  в  настоящее

время  весьма  развитые  программно-технические  средства.  Широкое  и

эффективное применение этих средств стало одним из факторов выживаемости
10

 

и  успеха  предприятия  в  условиях  острой  конкурентной  борьбы.  Получили

широкое  распространение  автоматизированные  информационные  системы,

которые  в  последние  годы  чаще  называют  информационные  системы,

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

Проблема анализа исходной информации для принятия решений оказалась

настолько  серьезной,  что  появилось  отдельное  направление  или  вид

информационных  систем  —  информационно-аналитические  системы  (ИАС),

под  которыми  понимают  комплекс  аппаратных,  программных  средств,

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

автоматизации  аналитических  работ  в  целях  обоснования  принятия

управленческих решений и других возможных применений.

Вся  проблема  аналитической  подготовки  принятия  решений  имеет

следующие аспекты:

− извлечение из многих источников разнородных данных, представленных

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

− организация хранения и предоставления пользователям необходимой для

принятия решений информации;

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

подготовка плановой или регулярной оценки состояния управляемого объекта в

виде бумажных документов или экранных форм;

− подготовка результатов оперативного и интеллектуального анализа для

эффективного их восприятия потребителями и принятия на основе адекватных

решений.

Аспект,  касающийся  сбора  и  хранения  информации  с  сопутствующей

доработкой,  оформился  в  концепцию  информационных  хранилищ  (Data

Warehouse).  Эта  концепция  состоит  в  том,  что  сведения  о  деятельности

предприятия  или  иного  объекта  хозяйственной  или  иной  деятельности

накапливаются  в  течение  длительного  периода  времени  (годы)  в

информационном хранилище по определенным правилам. Накопленные данные
11

 

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

данных  для  разного  рода  отчетности  и  работы  с  партнерами  (Reporting)  и

обоснования управленческих решений.

В связи с большим объемом и сложностью аспект проблемы собственно

анализа имеет два направления — оперативный анализ данных (информации),

широко  распространена  аббревиатура  англоязычного  названия  —  On-Line

Analytical  Processing  —  OLAP.  Основной  задачей  оперативного  или  OLAP-

анализа  является  быстрое  (в  пределах  секунд)  извлечение  необходимой

аналитику или ЛПР для обоснования или принятия решения информации.

Интеллектуальный  анализ  информации  —  имеет  также  широко

распространенное  в  русской  специальной  литературе  англоязычное  название

Data mining. Предназначен для фундаментального исследования проблем в той

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

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

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

режиме  Data  mining  приходится  использовать  весьма  мощные  специальные

программные средства или, как говорят, инструменты.

Аспекты  проблемы  анализа  и  необходимые  для  их  разрешения  функции

нашли  выражение  в  соответствующих  программных  продуктах.

Соответственно  средства  автоматизации  анализа  представлены  в  различных

видах.  Имеются  комплексные  информационно-аналитические  системы,

выполняющие  в  той  или  иной  степени  функции  в  соответствии  с

рассмотренными аспектами. Представлены на рынке программных продуктов и

целевые  программные  системы,  выполняющие  в  увеличенном  объеме,

расширенном составе и повышенной сложности какие либо функции, например

оперативного  или  интеллектуального  анализа.  ИАС  информационно

подпитывают  системы  поддержки  принятия  решений  (СППР),  в  литературе

также применяют аббревиатуру DSS (Decisin Support Sistem).
12

 

В  целом  сложился  рынок  инструментальных  средств  создания  и

поддержки  OLAP-систем,  информационных  хранилищ  (DWH),  СППР  (DSS),

интеллектуального анализа Data mining (DMg), который получил обобщенное

название  —  Business  intelligence  (BI),  которому  пока  не  подобран

соответствующий русскоязычный термин.

Как  правило,  все  инструментальные  средства,  предназначенные  для

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

многомерных  массивов  информации;  имеют  также  возможность

импорта/экспорта  данных  в  другие  операционные  среды,  развитые  средства

визуального двумерного (2D) и трехмерного (3D) представления информации.

 

1.2.  Data Warehouse – хранилище данных – ХД - систем обработки

данных

 

Автоматизация  или  компьютеризация  предприятий,  как  правило,

происходит  исторически  и  «снизу  вверх»  (исключая  случаи  полной

реорганизации).  Определенные  подразделения,  которые  заняты  массовыми

операциями  по  обработке  данных  (выписка  счетов,  учет  производства,

складской учет, работа с поставщиками и пр.), подвергаются процессу целевой

автоматизации.  Это  означает,  что  массовые  задачи  будут  производиться  с

помощью  компьютеров,  которые  заменят  работу  с  бумажными  носителями

информации (документы, бланки) на режим, в котором действия отражаются в

БД, или (что чаще всего и происходит) информация будет дублироваться как на

бумажных носителях, так и в БД.  

В  силу  того,  что  компьютеризации  (или  отражению  в  БД)  подвергается

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

всегда согласованно, большинство БД плохо согласованы друг с другом, т.е. в

различных БД одинаковые объекты реального мира могут быть отражены по–

разному (например, Иванов И. И. при начислении заработной платы и Иванов
13

 

Иван  Иванович  при  получении  материальных  ценностей  в  подотчет).  Эта

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

словарей  уровня  предприятия,  что  само  по  себе  является  нетривиальным

техническим процессом.

Хранилище  Данных  (Data  Warehouse  ,  DW  ,  ХД,  информационное

хранилище, склад данных):

 это  централизованный  фонд  структурированного  хранения  и  быстрого

поиска информации при Off-Line анализе информации;

 это  предметно-ориентированный,  интегрированный,  неизменчивый,

поддерживающий  хронологию  и  неизменяемый  набор  данных,

предназначенный для поддержки принятия решений, и его пользователи — это

высший  и  средний  менеджмент,  аналитики,  представители  подразделений

бизнес-анализа и маркетинга;

 это  среда,  состоящая  из  одной  или  более  БД,  спроектированная  для

доставки  соответствующего  и  согласованного  бизнес-анализа  (Business

Intelligence, BI) во все бизнес-подразделения организации;

 это  инструмент  управления,  благодаря  которому  руководство  получает

доступ к информации, необходимой для принятия обоснованных решений;

 это  средство,  которое  помогает  руководству  принимать  стратегические

решения,  производить  анализ  огромных  объемов  данных,  открывать  скрытые

возможности и улучшать конкурентоспособность своего предприятия.

ХД  собирает  информацию  из  различных  источников  и  рисует

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

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

их среди тех, кому они необходимы.

Необходимость  создания  ХД  на  крупных  предприятиях  чаще  всего

определяется несовершенством существующих систем обработки транзакций.  

Назначение ХД:
14

 

• выполнения серверных/дисковых задач, связанных с созданием запросов

и  отчетов  на  серверах/дисках,  не  используемых  в  системах  обработки

транзакций OLTP. Большинство фирм стремятся настроить системы обработки

транзакций так, чтобы все операции выполнялись за приемлемое время. В связи

с  этим  рекомендуется  реализовывать  архитектуру  ХД,  использующую

отдельные  серверы/диски  для  создания  запросов/отчетов,  что  позволит

добиться  приемлемого  времени  обработки  транзакций  и  будет  разумно  и  с

финансовой и с организационной точки зрения;

• использования  моделей  данных  и/или  серверных  технологий,

ускоряющих  создание  запросов  и  отчетов,  но  не  предназначенных  для

обработки транзакций;

• создания комфортной среды, в которой написание и поддержка запросов

и отчетов не требует больших знаний в области технологий БД. А также для

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

процесс написания и поддержки запросов и отчетов, что сокращает количество

бюрократических процедур;

• создания  репозитория  "очищенных"  данных  системы  обработки

транзакций и последующего получения отчетов из этих данных без изменения

самой  OLTP-системы.  ХД  дает  возможность  очистки  данных  без  изменения

систем обработки транзакций;

• упрощения формирования запросов и отчетов по данным из нескольких

систем обработки транзакций, а также из внешних источников данных и/или по

данным,  которые  хранятся  только  для  отчетности.  Долгое  время  для

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

вынуждены  писать  специальные  процедуры  извлечения  данных  и  выполнять

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

отсортированным (и/или объединенным) выборкам данных;

• создания  репозитория  данных  для  OLTP-системы,  содержащего

долговременную  информацию,  хранение  которой  в  системе  обработки
15

 

транзакций не эффективно. Чтобы не замедлять выполнение операций, старые

данные  часто  удаляются  из  систем  обработки  транзакций.  Однако  для

отчетности и составления запросов есть смысл держать эту информацию в ХД,

где время отклика не так критично;

• ограничения доступа к БД системы и программной логике ее управления

лицам,  использующим  данные  OLTP-систем  исключительно  для  составления

отчетов и запросов. В этом случае основная цель - защита информации;

• развития  систем  управления  взаимоотношениями  с  клиентами  (CRM).

Процесс выстраивания взаимоотношений с клиентами нацелен на сохранение

старых  и  привлечение  новых  клиентов,  что  трудно  осуществить  без

автоматизации продаж, маркетинга и совершенствования обслуживания;

• ликвидации  разрозненности  данных.  Несмотря  на  то,  что  предприятия

склонны к централизации всех систем автоматизации в рамках КИС, достичь

этого  удается  далеко  не  всегда,  поскольку  неизбежно  присутствуют

разнородные источники информации.

Кроме  определенной  выше  глобальной  цели  –  создание  единой  модели

данных,  можно  выделить  т.н.  «краткосрочные  цели»,  которые  дают

немедленный  выигрыш  пользователям  на  каждом  этапе  реализации  ХД.  Вот

несколько примеров краткосрочных целей:

1.  Улучшение качества данных. Поскольку обычным недостатком СППР

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

своих данных на каждом этапе реализации ХД. Очистка данных представляет

собой  проблему  в  организации  Хранилищ:  с  одной  стороны,  предполагается,

что  ХД  обеспечит  чистые,  интегрированные,  соответствующие  и

согласованные  данные,  извлеченные  из  множества  источников;  с  другой

стороны, есть расписание разработки, составленное в расчете на 6-12 месяцев.

Практически невозможно достичь обеих целей одновременно, не идя на какие-

либо  компромиссы.  Трудность  в  том,  чтобы  определиться  с  существом  этих

компромиссов.  
16

 

2.  Подготовка  данных  для  СППР.  Создание  ХД  позволяет  произвести

следующий  этап  автоматизации  деятельности  предприятия  —  подготовить

данные  для  систем  поддержки  принятия  решений.  Основным  отличием

деятельности по принятию решений от исполнительской деятельности, с точки

зрения используемых данных, является потребность во всестороннем видении

процессов  во  всем  многообразии  параметров,  от  которых  они  зависят,  за

различные временные промежутки. Для создания систем поддержки принятия

решений  необходима  полная,  непротиворечивая,  информация  за  различные

временные  промежутки,  которая  может  быть  как  обобщена  (просуммирована

или агрегирована другим способом), так и детализирована.  

3.  Минимизация  количества  несовместимых  отчетов.  Другой

распространенной  проблемой  сегодняшних  сред  СППР  является

несовместимость  отчетов.  Несовместимые  отчеты  в  основном  происходят  от

неправильного  использования  данных,  и  первопричиной  этого  является

разногласия или непонимание значения или содержимого данных.  

4.  Захват  и  доступ  к  метаданным.  Метаданные  необходимы  для

совместного  доступа  к  данным  и  навигации  по  ним.  Сегодня  к  большинству

данных  нет  совместного  доступа  по  многим  причинам,  одной  из  которых

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

Как  только  исходные  данные  очищены,  преобразованы,  агрегированы,

просуммированы  и  рассечены  несколькими  различными  способами,

пользователи никогда снова не найдут их в ХД без помощи метаданных. Захват

метаданных  (то  есть,  определений  данных,  доменов,  алгоритмов

преобразования  исходных  данных,  столбцы  и  таблицы,  в  которых  находятся

результирующие данные, и все другие технические компоненты) представляет

собой возможное решение  

5.  Обеспечение  возможности  совместного  доступа  к  данным.  Если

совместный  доступ  к  данным  является  одной  из  задач  ХД,  то  необходимо

включить  туда  некоторую  очистку  данных,  урегулирование  разногласий  по
17

 

данным и компоненты средств доступа, основанные на метаданных в качестве

инструментов  достижения  этой  цели.  Эти  компоненты  представляют  собой

предварительные  условия  совместного  доступа  к  данным.  Двумя  другими

существенными  компонентами  являются  проектирование  БД  и  организация

доступа к ней.  

6.  Проектирование БД - Базы Данных. После того, как проанализированы

требования, необходимые данные логически смоделированы и относящиеся к

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

БД.  Проектирование  самостоятельной  БД  для  одного  бизнес-подразделения

отличается от проектирования БД совместного доступа для множества бизнес-

подразделений.  

7.  Интеграция  данных  из  множества  источников.  Это  существенная

задача  для  всех  ХД,  поскольку  это  первостепенная  проблема  в  различных

СППР.  Самостоятельные  системы,  имеющие  одни  и  те  же  данные,

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

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

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

одном файле находится на отличном от другого файла уровне детализации или

в том, что одни и те же данные модернизируются с разной периодичностью в

различных файлах.  

8.  Соединение  исторических  данных  с  текущими  данными.  Типичной

задачей ХД является сохранение истории. Эта задача сопровождается своими

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

даже  если  они  там  хранятся,  трудно  найти  трехлетнюю  или  пятилетнюю

историю в рамках одного файла.

Концепция  ХД  определяет  процесс  сбора,  отсеивания,  предварительной

обработки и накопления данных с целью долговременного хранения данных и

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

для  статистического  анализа  и  создания  аналитических  отчетов.  В  основе
18

 

концепции  ХД  для  интеграции  неоднородных  источников  данных

принципиально отличается от подхода динамической интеграции разнородных

БД, лежат две основополагающие идеи:  

Интеграция  ранее  разъединенных  детализированных  (описывающих

некоторые конкретные факты, свойства, события и т.д.) данных в едином ХД :

исторические  архивы,  данные  из  традиционных  СОД,  данные  из  внешних

источников  в  едином  ХД,  их  согласование  и  возможно  агрегация.

Интегрированность означает, что, например, данные, полученные из различных

источников, хранятся согласованно и централизованно.  

Разделение наборов данных используемых для операционной обработки и

наборов  данных  используемых  для  решения  задач  анализа,  применяемых  в

системах  поддержки  принятия  решений.  Такое  разделение  возможно  путем

интеграции  источников  ранее  разъединенных  детализированных  данных  в

едином  ХД,  их  согласования  и,  возможно,  агрегации.  Организация

информационного процесса при построении ХД представлена на рисунке 1.1..

 

Рис. 1.1. Организация информационного процесс

Цель  концепции  ХД  -  прояснить  отличия  в  характеристиках  данных  в

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

помещаемым  в  целевую  БД  ХД,  определить  общие  принципы  и  этапы  еѐ

построения,  основные  источники  данных,  дать  рекомендации  по  решению

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

транспортировке и загрузке в целевую БД.  
19

 

Для  правильного  понимания  данной  концепции  необходимо  понимание

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

ХД:  

• это  не  концепция  анализа  данных,  скорее  это  концепция  подготовки

данных для анализа.  

• не  предопределяет  архитектуру  целевой  аналитической  системы.  Она

говорит о том, какие процессы должны выполняться в системе, но не о том, где

конкретно и как эти процессы должны выполняться.  

• предполагает  не  просто  единый  логический  взгляд  на  данные

организации  (как  иногда  это  трактуется).  Она  предполагает  реализацию

единого интегрированного источника данных.

Вопрос  реализации  единого  интегрированного  источника  данных

достаточно  принципиален.  Концепция  ХД  предполагает  не  просто  единый

логический  взгляд  на  данные  организации,  а  действительную  реализацию

единого  интегрированного  источника  данных  для  систем  обработки  данных

(СОД).  

Сегодня,  достаточно  популярны  решения,  предполагающие  интеграцию

различных  СОД  на  основе  единого  справочника  метаданных  (

поддерживающего  единый  логический  взгляд  данные  организации  ),  но  не

единого  интегрированного  источника  данных.  При  этом  предполагается

динамическая  выгрузка,  по  каждому  новому  запросу,  данных  из  различных

операционных источников (СОД) их динамическое согласование, агрегация и

транспортировка  к  пользователю.  Очевидно,  что  для  определѐнных  классов

приложений, это решение вполне корректно. Но следует заранее понимать все

ограничения им накладываемые.  

Кроме  единого  справочника  метаданных,  средств  выгрузки,  агрегации  и

согласования  данных,  концепция  ХД,  как  отмечалось  ранее,  подразумевает:

интегрированность, не изменчивость, поддержку хронологии и согласованность

данных. И если, два первых свойства ( интегрированность и не изменчивость )
20

 

влияют  на  режимы  анализа  данных  (как  будет  показано  ниже,  без

интегрированной  БД,  в  которой  используются  специализированные  методы

хранения и доступа, по крайней мере, сегодня, трудно говорить о реализации

интерактивного  динамического  анализа),  то  последние  два  (  поддержка

хронологии  и  согласованность  ),  существенно  сужают  список  решаемых

аналитических задач.

Компоненты  типичного  ХД.  Компоненты,  входящие  в  типичное  ХД,

представлены на рисунке 1.2..  

 

Рис. 1.2. Структура хранилище данных

Оперативные  данные  собираются  из  различных  источников,  очищаются,

интегрируются и складываются в реляционное ХД. При этом они уже доступны

для анализа при помощи различных средств построения отчетов. Затем данные

(полностью  или  частично)  подготавливаются  для  OLAP-анализа.  Они  могут

быть загружены в специальную БД OLAP или оставлены в реляционном ХД.

Важнейшим  его  элементом  являются  метаданные,  т.  е.  информация  о

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

эффективное взаимодействие различных компонентов хранилища.  

Без  поддержки  хронологии  (наличия  исторических  данных)  нельзя

говорить о решении задач прогнозирования и анализа тенденций. Но наиболее

критичными  и  болезненными,  оказываются  вопросы,  связанные  с

согласованием данных.  

Основным  требованием  аналитика,  является  даже  не  столько

оперативность,  сколько  достоверность  ответа.  Но  достоверность,  в  конечном
21

 

счете,  и  определяется  согласованностью.  Пока  не  проведена  работа  по

взаимному согласованию значений данных из различных источников, сложно

говорить об их достоверности.  

Практически  в  любой  организации,  вопрос  о  согласованности  данных  в

различных  информационных  системах  стоит  чрезвычайно  остро.  И,  нередко,

менеджер сталкивается с ситуацией, когда на один и тот же вопрос, различные

системы могут дать и обычно дают различный ответ. Это может быть связано

как  с  не  синхронностью  моментов  модификации  данных,  отличиями  в

трактовке одних и тех же событий, понятий и данных, изменением семантики

данных  в  процессе  развития  предметной  области,  элементарными  ошибками

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

Очевидно,  что  учесть  и  заранее  определить  алгоритмы  разрешения  всех

возможных  коллизий  мало  реально.  Тем  более,  это  нереально  сделать  в

оперативном режиме, динамически, непосредственно в процессе формирования

ответа на запрос.

Примерная  структура  ИАС,  построенной  на  основе  ХД,  показана  на

рисунке 1.3..

 

Рис. 1.3. Примерная структура информационно-аналитической системы,

построенной на основе Хранилища данных
22

 

В  конкретных  реализациях  отдельные  компоненты  этой  схемы  могут

отсутствовать.  При  такой  организации  ИАС  ХД  функционирует  по

следующему сценарию: по заданному регламенту в него собираются данные из

различных  источников  –  БД  систем  оперативной  обработки.  В  ХД

поддерживается  хронология:  наравне  с  текущими  хранятся  исторические

данные  с  указанием  времени,  к  которому  они  относятся.  В  результате

необходимые  доступные  данные  об  объекте  управления  собираются  в  одном

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

агрегируются до минимально требуемого уровня обобщения.  

Несмотря  на  то,  что  ХД  содержат  заведомо  избыточную  информацию,

которая  и  так  имеется  в  базах  или  файлах  оперативных  систем,  появление

концепции  ХД  вызвано  тем,  анализировать  данные  оперативных  систем

напрямую невозможно или очень затруднительно. Это объясняется:  

• разрозненностью данных (OLTP-системы, текстовые отчеты, xls-файлы);  

• хранением  их  в  форматах  различных  СУБД  и  в  разных  узлах

корпоративной  сети.  Но  даже  если  на  предприятии  все  данные  хранятся  на

центральном сервере БД (что бывает крайне редко), аналитик почти наверняка

не разберется в их сложных, подчас запутанных структурах  

• сложные  аналитические  запросы  к  оперативной  информации  тормозят

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

сервера.  

Можно констатировать, что практически в любой организации сложилась

парадоксальная  ситуация:  -  информация  вроде  бы,  где-то  и  есть,  еѐ  даже

слишком  много,  но  она  неструктурированна,  несогласованна,  разрознена,  не

всегда достоверна, еѐ практически невозможно найти и получить. В результате

можно  говорить  об  отсутствие  информации  при  ее  наличии  и  даже

избыточности.  
23

 

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

быть организованы способом, отличным от принятого в OLTP-системах потому

что:  

• в  OLTP-системах  используются  нормализованные  таблицы  БД.

Нормализация  эффективна,  если  отношения  часто  перестраиваются  (вставка),

но дает отрицательный эффект в случае операции выборки (особенно в случае

сложных  запросов).  А  в  DSS-системах  только  операции  выборки,  и  данные

редко  меняются,  поэтому  данные  целесообразно  хранить  в  виде  слабо

нормализованных  отношений,  содержащих  заранее  вычисленные  основные

итоговые данные. Большая избыточность и связанные с ней проблемы тут не

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

данных.  При  этом происходит  как  добавление новых  данных,  так  и  пересчет

итогов.  

• выполнение некоторых аналитических запросов требует хронологической

упорядоченности данных. Реляционная модель не предполагает существования

порядка записей в таблицах.  

• в  случае  аналитических  запросов  чаще  используются  не  детальные,  а

обобщенные (агрегированные данные).  

Организация потоков данных в ХД показана на рисунке  

  

Рис. 1.4. Организация потоков данных в Хранилище Данных
24

 

Так как ХД носит предметно-ориентированный характер, его организация

нацелена  на  содержательный  анализ  информации,  а  не  на  автоматизацию

бизнес-процессов.  Это  свойство  определяет  архитектуру  построения

хранилища и принципы проектирования модели данных, отличные от тех, что

применяются  в  оперативных  системах.  Методика  построения  ХД  из  простой

теоретической дисциплины превратилась в сложную науку, полную вариаций и

направлений.  

Data Mart - Витрины данных. Облегченным вариантом корпоративного ХД

является  Витрина  Данных  (киоск,  секция,  лавка,  рынок,  ВД)  -  это  набор

тематически  связанных  БД,  содержащие  информацию,  относящуюся  к

отдельным  аспектам  деятельности  организации.  По  сути  дела,  ВД  -  это

облегченный вариант ХД, существенно меньше по объему, чем корпоративный

ХД, и для его реализации не требуется особо мощная вычислительная техника.  

Концепция ВД была предложена Forrester Research в 1991 году. При этом

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

пользователю  и  содержат  только  тематические  подмножества  заранее

агрегированных  данных,  по  размерам  гораздо  меньшие,  чем

общекорпоративное ХД, и, следовательно, требующие менее производительной

техники  для  поддержания.  Концепция  ВД  ориентирована  исключительно  на

хранение,  а  не  на  обработку  корпоративных  данных.  Она  не  предопределяет

архитектуру  целевых  аналитических  систем,  а  только  создает  поле

деятельности  для  их  функционирования,  концентрируясь  на  требованиях  к

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

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

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

В  большинстве  случае  ВД  (витрина  данных)  -  это  аналитическая

структура, которая обычно поддерживает область работы одного приложения,

бизнес-процесса  или  отдела.  Сотрудники  отдела  обобщают  требования  к

информации и приспосабливают каждую витрину к своим нуждам. Затем они
25

 

обеспечивают  персонал,  работающий  с  информацией,  средствами

интерактивной  отчетности  (например,  инструментами  OLAP,  средствами

формирования незапланированных запросов или параметризованных отчетов).

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

пространственную  структуру  "вдоль  и  поперек",  чтобы  выявить  тренды  и

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

тех процессов или задач, которыми эти сотрудники управляют.

 

1.3.  Подходы к архитектуре хранилищ данных – ХД

 

На сегодняшний день существует следующие подходы к архитектуре ХД.

• корпоративная  информационная  фабрика  (  CIF  ,  Corporate  Information

Factory ) Билла Инмона;  

• ХД с архитектурой шины ( Data Warehouse Bus , BUS) Ральфа Кимболла

(Ralph Kimball);

объединенное  ХД  (Federated  Data  Warehouse/Federated  Data  Mart,

FDW\FDM).

Выбрать оптимальную систему из этого набора архитектурных решений не

такая простая задача.  

Corporate  Information  Factory,  Корпоративное  хранилище  данных.

Когда-то  этот  подход  был  известен  под  названием  классического  ХД  (

Enterprise  Data  Warehouse  ,  EDW).  Корпоративное  ХД  является  широко

распространѐнным  и  уникальным  репозиторием  информации  предприятия.

Среда Хранилища предназначена только для чтения и состоит из детальных и

агрегированных данных, которые полностью очищены и интегрированы; кроме

того,  в  нем  хранится  обширная  и  детальная  история  данных  на  уровне

транзакций. С точки зрения этого архитектурного решения ХД реализует свои

функции, прежде всего, через подмножество зависимых Витрин данных.  

Корпоративное ХД - хранилище данных - это:  
26

 

• проект  корпоративного  масштаба,  охватывающий  все  отделы  и

обслуживающий нужды всех пользователей корпорации  

• не  механическая  коллекция  Витрин  Данных,  а  физически  целостный

объект.  

Работа такого Хранилища начинается со скоординированного извлечения

данных  из  источников.  После  этого  загружается  реляционная  база  данных  с

третьей  нормальной  формой,  содержащая  атомарные  данные.  Получившееся

нормализованное  ХД  используется  для  того,  чтобы  наполнить  информацией

дополнительные  репозитории  презентационных  данных,  т.е.  данных,

подготовленных  для  анализа.  Эти  репозитории,  в  частности,  включают

специализированные  Хранилища  для  изучения  и  "добычи"  данных  (  Data

Mining ), а также Витрины Данных.

Реляционная  база  данных.  Реляционная  база  данных  -  это  совокупность

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

Физически это выражается в том, что информация хранится в виде двумерных

таблиц, связанных по ключевым полям. В основе этих БД лежит реляционная

модель, разработанная англо-американским ученым Эдгаром Коддом в 1960-70

гг.  

При  таком  сценарии  конечные  Витрины  данных  создаются  для

обслуживания  бизнес-отделов  или  для  реализации  бизнес-функций  и

используют  пространственную  модель  для  структурирования  суммарных

данных. Атомарные данные остаются доступными через нормализованное ХД.

Очевидно, что структура атомарных и суммарных данных при таком подходе

существенно различается.

Пространственная модель - dimensional model. Пространственная модель -

это  одна  из  моделей  ХД,  в  которой  данные  организованы  не  по  третьей

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

характеристику  отдельных  категорий  информации  (  dimensions  ).  Основная

цель  пространственной  модели  -  минимизировать  время  выполнения  запроса,
27

 

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

группируются  вокруг  центральной  задачи  (или  вопроса),  которую  придется

выполнять  наиболее  часто.  Центральная  таблица  связана  со  всеми

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

(так называемая архитектура "звезда").

Отличительные  характеристики  подхода  Билла  Инмона  к  архитектуре

корпоративного ХД - хранилища данных :

• использование  реляционной  модели  организации  атомарных  данных  и

пространственной - для организации суммарных данных  

• использование  итеративного  или  "спирального"  подхода  при  создании

больших  ХД,  т.е.  "строительство"  не  сразу,  а  по  частям.  Это  позволяет  при

необходимости  вносить  изменения  в  небольшие  блоки  данных  или

программных  кодов  и  избавляет  от  необходимости  перепрограммировать

значительные  объемы  данных  в  ХД.  То  же  самое  можно  сказать  и  о

потенциальных  ошибках:  они  также  будут  локализованы  в  пределах

сравнительно небольшого массива без риска испортить все ХД  

• использование  третьей  нормальной  формы  для  организации  атомарных

данных,  что  обеспечивает  высокую  степень  детальности  интегрированных

данных и, соответственно, предоставляет корпорациям широкие возможности

для  манипулирования  ими  и  изменения  формата  и  способа  представления

данных по мере необходимости  

Достоинства архитектуры корпоративного хранилища данных:

• непротиворечивость информации.  

• один набор процессов извлечения и бизнес-правил.  

• общая семантика.  

• централизованная, управляемая среда.  

• легко создаваемые и наполняемые витрины данных.  

• единый репозиторий метаданных.  

Недостатки такого архитектурного решения ХД:
28

 

• реализация требует больших затрат.  

• высокая ресурсоемкость.  

• потребность в системах и ресурсах в масштабе всего предприятия.  

• рискованный сценарий ("все поставлено на карту").

Data  Warehouse  Bus  -  ХД  с  архитектурой  шины.  Альтернативный

подход к архитектуре ХД, известен как ХД с архитектурой шины или подход

Ральфа Кимболла.  

В  этой  модели  первичные  данные  преобразуются  в  информацию,

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

обязательно  принимаются  во  внимание  требования  к  скорости  обработки

информации  и  качеству  данных.  Как  и  в  модели  Билла  Инмона,  подготовка

данных начинается со скоординированного извлечения данных из источников.

Ряд  операций  совершается  централизованно,  например,  поддержание  и

хранение  общих  справочных  данных,  другие  действия  могут  быть

распределенными.  

Область  представления  пространственно  структурирована,  при  этом  она

может быть централизованной или распределенной. Пространственная модель

ХД содержит ту же атомарную информацию, что и нормализованная модель, но

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

выполнение  запросов.  Эта  модель  включает  как  атомарные  данные,  так  и

обобщающую информацию (агрегаты в связанных таблицах или многомерных

кубах)  в  соответствии  с  требованиями  производительности  или

пространственного  распределения  данных.  Запросы  в  процессе  выполнения

обращаются  к  все  более  низкому  уровню  детализации  без  дополнительного

перепрограммирования  со  стороны  пользователей  или  разработчиков

приложения.  

В отличие от подхода Билла Инмона, пространственные модели строятся

для  обслуживания  бизнес-процессов  (которые,  в  свою  очередь,  связаны  с

бизнес-показателями  или  бизнес-событиями),  а  не  бизнес-отделов.  Например,
29

 

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

использования, вносятся в пространственное ХД только один раз, в отличие от

CIF-подхода, в котором их пришлось бы трижды копировать в витрины данных

отделов  маркетинга,  продаж  и  финансов.  После  того,  как  в  ХД  появляется

информация  об  основных  бизнес-процессах,  консолидированные

пространственные  модели  могут  выдавать  их  перекрестные  характеристики.

Матрица корпоративного ХД с архитектурой шины выявляет и усиливает связи

между показателями бизнес-процессов (фактами) и описательными атрибутами

(измерениями).  

Типичные черты подхода Ральфа Кимболла:

• использование  пространственной  модели  организации  данных  с

архитектурой "звезда" ( star scheme ).  

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

подготовки  данных,  недоступную  для  конечных  пользователей,  и  ХД  с

архитектурой шины как таковое. В состав последнего входят несколько витрин

атомарных данных, несколько витрин агрегированных данных и персональная

витрина  данных,  но  оно  не  содержит  одного  физически  целостного  или

централизованного ХД.  

ХД с архитектурой шины обладает следующими характеристиками:  

 оно пространственное;  

 оно включает как данные о транзакциях, так и суммарные данные;  

 оно  включает  витрины данных,  посвященные  только одной  предметной

области или имеющие только одну таблицу фактов ( fact    table );

 оно может содержать множество витрин данных в пределах одной БД.  

ХД не является единым физическим репозиторием (в отличие от подхода

Билла Инмона). Это "виртуальное" ХД. Это коллекция витрин данных, каждая

из которых имеет архитектуру типа "звезда".

Объединенное (федеративное) ХД. В наше время уже нет необходимости

доказывать,  как  важно  для  многофилиальных  корпораций  наличие
30

 

согласованной  управленческой  информации,  необходимой  для  четкого

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

немногим  компаниям  удалось  достичь  высокого  уровня  информационного

обеспечения.  

Во многих организациях сложилась практика реализации многочисленных

ХД.  Хотя,  по  определению,  существует  только  одно  ХД,  а  все  остальные

объекты  являются  его  подмножеством  или  постепенно  развиваемыми

витринами данных, не все организации придерживаются этого правила. Таким

образом,  во  многих  компаниях  существует  два,  три,  десяток  и  даже  более

систем ХД.  

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

проведение  стандартизации  "сверху  вниз"  как  структуры  отчетности,  так  и

модели данных. Однако с практической точки зрения стандартизация бизнес-

структур  оказывается  для  большинства  организаций  исключительно

нецелесообразной  -  требуется  слишком  много  средств,  времени.  Кроме  того,

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

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

потребовали  бы  учета  местной  специфики.  Если,  например,  можно

стандартизировать  коды  валют  по  всей  корпорации,  введение  полностью

стандартизированной  линейки  продуктов  редко  оправданно,  а  в  некоторых

случаях - даже нежелательно.  

Поэтому даже если стандартизацию и удалось бы полностью реализовать

на практике, необходимость обеспечения согласованности лишала бы филиалы

компании  возможности  приспосабливаться  к  условиям  местного  бизнеса  и

происходящим на нем  изменениям.  Такая  ситуация  чревата  возникновениями

противоречий  между  центральным  офисом  и  местными  отделениями  -

центральная  система  неспособна  отвечать  потребностям  пользователей,  а

сотрудники  филиалов  не  стремятся  тщательно  проверять  качество  данных,  и
31

 

поэтому  возникает  опасность,  что  данные,  отправляемые  в  головной  офис,

могут оказаться ошибочными.  

Выше  описанные  проблемы  могут  быть  решены  на  основе  подхода,  в

основе которого лежит создание Федеративного ХД. В соответствии с данным

подходом, с помощью иерархии связанных ХД можно обмениваться данными,

бизнес  моделями  и  структурами  отчетности,  благодаря  чему  можно,  с  одной

стороны,  осуществлять  общий  контроль  и  предусмотреть  определенную

степень  стандартизации,  а,  с  другой  -  позволить  региональным  отделениям

сохранить автономность и учесть местную специфику.  

Система объединенных ХД характеризуется  совместным использованием

общих  информационных  точек,  устраняя,  таким  образом,  избыточность  и

гарантируя достоверность информации по всей организации (см. рисунок).  

 

Рис. 1.5. Системы объединенных Хранилищ данных

Федеративное  ХД  состоит  из  ряда  экземпляров  ХД,  которые

функционируют на полуавтономной основе и, как правило, организационно или

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

одно  большое  ХД.  Поскольку  построение  федеративного  ХД  можно

осуществлять  постепенно  -  "шаг  за  шагом",  при  его  создании  разумно

воспользоваться методом "начинай с малого, планируй в глобальном аспекте".

Такой  подход  существенно  снижает  риск  неудачи  при  глобальном

развертывании системы, поскольку каждое локальное ХД меньше по масштабу,
32

 

незамедлительно  отвечает  местным  требованиям  и  может  управляться

сотрудниками регионального бизнес-подразделения.  

Каждый  из  экземпляров  ФХД  хранит  копию  базовой  бизнес-модели  и

общие  основные  данные  (  common  master  data  ),  причем  каждое  ХД  более

высокого  уровня  содержит  итоговые  транзакционные  данные  более  низкого

уровня.  Общие  основные  данные  -  например,  схема  организационной

структуры  компании  -  отправляется  «вниз»,  т.е.  из  корпоративного

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

из  локального  ХД.  Таким  образом  "федерация"  ХД  может  предоставить

местным  отделениям  необходимую  гибкость,  а  также  обеспечить  общий

контроль и согласованность; при этом каждое ХД функционирует независимо

от всех других остальных.  

Данный подход выгоден не только с точки зрения ежедневных операций,

но  и  при  процессе  внедрения  -  при  построении  "федерации"  ХД,  которые

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

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

новые  ХД  в  соответствии  с  приоритетами  бизнеса.  Таким  образом,

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

необходимость  заранее  устанавливать  окончательную  архитектуру,  другими

словами  рискованный  монолитный  проект  может  быть  разбит  на

многочисленные, менее крупные и рискованные, но более доходные проекты.  

Достоинства системы объединенных ХД

• общая семантика и бизнес-правила.  

• один набор процессов извлечения и бизнес-правил.  

• децентрализованные ресурсы и управление.  

• параллельная разработка.  

Недостатки такого архитектурного решения

• необходимость в координировании работ.  
33

 

• сложности в преодолении "политических" моментов и решении вопросов

авторских прав.  

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

архитектуры, бизнес правил и семантики.  

• сложнейшая техническая среда.  

• очень часто наличие многочисленных репозиториев метаданных.

 

1.4.  Анализ процесса принятий решений в системе высшего

образования

 

Указом Президента от 7 января 1990 года также Постановлением Кабинета

Министров  Республики  Узбекистан  "  О  совершенствовании  деятельности

Министерства  высшего  и  среднего  специального  образования  Республики

Узбекистан  "  от  «20»  июля  2004  года  №  341  утверждено  Положение  о

Министерстве  высшего  и  среднего  специального  образования  Республики

Узбекистан.  В  положение  сказано:  «Министерство  высшего  и  среднего

специального  образования  Республики  Узбекистан  является  органом

государственного  управления,  осуществляющим  руководство  высшим  и

средним  специальным,  профессиональным  образованием  в  республике.

Министерство  в  своей  деятельности  подотчетно  Кабинету  Министров

Республики Узбекистан.». Первым и основным функциональным обязанности

министерства  является  анализ  экономического,  социального  и  т.д.  состояний

высших  образовательных  учреждений  и  на  основе  анализе  принимать

стратегический решения для улучшения и развития образований в республике.

Количественные характеристики Министерства:

1. Количество высших образовательных учреждений (ВОУ) 70;

2. Количество студентов республики 66723;

3. Общая количество педагогического персонала 44234;

4. В 2011 году расходная часть госбюджета направленную на образование

составила 2,2 триллиона сумов;
34

 

5. Управленческий  персонал  в  самом  министерства  около  60  штатных

единиц.

Как видно из показателей министерства имеет очень большой потенциал.

Процесс сбора данных для анализа на основе нижеследующего алгоритма:

1. Создаѐтся  поручения  для  ректоров  ВОУ  и  шаблон  документа  для

заполнения данными (например Excel).

2. После  утверждения  поручения  начальником  управления  а  также

соответствующим  (координирующим)  заместителем  министра  электронный

вариант документ отправляется ВОУ через программу Performance.

3. Обратно  данные  принимаются  через  электронную  почту  и  на  основе

этих данных создаѐтся сводная таблыца.

4. После сбора данных со всех ВУО специалистами ведется анализ данных.

Сбор  данных  может  продлиться  с  3  до  7дней.  Это  конечно  приводит  к

временному опозданию принятие важных решений.  

В 2006 году вместе с чиновниками Кабинета Министров и Центральным

аппаратом  Министерства  был  проведен  совещание  на  тему  «Повышение

эффективности  информационно  коммуникационных  технологий  в  сфере

образование».  В  конце  совещание  было  принято  решение  создать

автоматизированную систему управления ВОУ.  В этом же году был утвержден

проект  «Единое  информационное  пространство  ВОУ»  при  Национальном

университете. В конце 2010 года на основе этого проекта было разработана 6

автоматизированных  информационных  систем  (АИС),  работающих  на  основе

единой базе данных ВОУ:

1. АИС Студент

2. АИС Отдел Кадры

3. АИС Наука

4. АИС Информационно коммуникационных технологий (ИКТ)

5. Документооборот

6. Новый веб-портал Министерства
35

 

Достоинства этих систем:

1. Логика программного комплекса был разработан на основе единой базы

данных;

2. Программный  продукт  работает  на  основе    веб-технологий,  это  дает

пользователям системы доступа в любом месте и в любое время;

3. Пользователи  АИС  распределены  на  несколько  ролов  которое  дает

возможность  пользователям  работать  со  своими  виртуальными  рабочими

столами.  А  также  дано  доступ  создание  ролей  на  основи  выбора  функции

систему.

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

объекта и процесса;

5. На  основе  предложений  руководителей  ВОУ  подготавливается  новый

проект,  в  которым    будет  совершенствовать  комплекс  АИ  система  и

специализироваться для некоторых ВОУ;

6. Установка и поддержка системе для ВОУ бесплатно.

Недостатки:

1. Система  работает  с  транзакциями  ежеминутно,  которое  не  дают

руководителям  ВОУ,  специалистам  министерства  вести  анализ  данных  по

времени;

2. Для анализа данных не предусмотрено таблице агрегации данных.

С 2011 года ведется внедрения АИС по приказу  министерства. Такие же

системы  были  разработаны  в  ташкентским  университете  информационных

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

специализированы для самых вузов.  

 

1.5.  Постановка задачи

 

Каждый  год  для  высших  образовательных  распределяться  определѐнная

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

ремонта  и  т.д..  В  начале  года  все  управления  ведут  анализ  состояний  ВОУ.
36

 

Например  управления  Внедрения  информационно-коммуникационных

технологий  в  учебный  процесс  ведут  сбор  данных  о  состояний

информационных  коммуникационных  технологий  например  компьютеры,

сканеры,  принтеры  или  программное  обеспечения.  На  основе  данных

принимается  решения  каким  ВОУ  нужна  покупать  новые  компьютеры,

принтеры, электронные доски. Предлагается разработка хранилище данных для

анализа  состояния  материально-технической  базы  высших  образовательных

учреждений.

Задачи:

1.  Создание хранилище данных;

2.  Разработка  гиперкуба  на  основе  созданного  хранилища  данных  для

многомерного анализа информации

 

1.6.  Выводы по первой главе

 

1. Проблема  анализа  исходной  информации  для  принятия  решений

является  отдельном  направлением  результаты  которого  используются  для

обеспечения  автоматизации  аналитических  работ  в  целях  обоснования

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

2. Концепция  ХД  обеспечивает  процесс  сбора,  отсеивания,

предварительной  обработки  и  накопления  данных  с  целью  долговременного

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

пользователям  в  удобной  форме  для  статистического  анализа  и  создания

аналитических отчетов что является достаточно актуальной.

3. В  настоящее  время  проблема  использования  большого  объема

накопленной  информации  является  ключевой  для  руководства  Министерства

высшего  и  среднего  специального  образования  (далее  МВССО).  Данные

ведутся в Управлениях МВССО в различных информационных приложениях с

использованием разных программных комплексов и фактически используются

только сотрудниками конкретного Управления для контроля и формирования
37

 

текущей  бухгалтерской,  экономической,  аналитической  и  статистической

отчетности.  Руководители  из-за  масштабов  и  отсутствия  механизма

агрегирования и оперативного доступа к банку данных Управлений вынуждены

интуитивно принимать решения по управлению ресурсами отрасли. На основе

анализа  было  принято  решения  разработать  хранилище  данных  для  анализа

состояния  материально-технической  базы  высших  образовательных

учреждений.
38

 

ГЛАВА 2. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ХРАНИЛИЩЕ

ДАННЫХ

 

Методика проектирования будет рассмотрена на примере проектирования

ХД  для  анализа  состояния  материально-технической  базы  высших

образовательных учреждений.

 

2.1. Определение требований

 

Первым  шагом  проектирования  хранилище  данных  является  анализ

запросов  и  требований,  предъявляемых  пользователями  к  ХД.  Необходимо

проконсультироваться  со  специалистами,  занимающимися  анализом  в  данной

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

обратиться  к  ХД.  На  этом  этапе  интерес  представляют  не  столько  тексты

вопросов, сколько понимание того, о каких фактах, событиях и объектах в них

спрашивается.

Пример:

1. На сколько процентов изменилось материально техническая база ВУЗов

последние 2 года?

2. В каких ВОУ наибольшая соотношения компьютеров к студентом?

3.  В  каких  регионах  наибольшая  потребность  к  новым  информационно

коммуникационным технологиям?

4.  Насколько  процентов  увеличилось  среднее  число  соотношения

компьютеров к студентам в республике?

 

2.2. Анализ вопросов

 

После  этого  необходимо  провести  первичный  анализ  вопросов  и

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

запрос пользователей.
39

 

Пример:

1. Количество продуктов по типам входящих в материально техническую

базу ВОУ;

2. Количество студентов в ВОУ.

 

2.3. Определение структуры ХД

 

Теперь необходимо определить структуру ХД, т.е. определить конкретные

Измерения и Факты, их взаимосвязи и уровни агрегации хранимых данных.

Таблица фактов. Таблица фактов является основной таблицей хранилища

данных.  Как  правило,  она  содержит  сведения  об  объектах  или  событиях,

совокупность которых будет в дальнейшем анализироваться. Обычно говорят о

четырех наиболее часто встречающихся типах фактов. К ним относятся:  

• факты,  связанные  с  транзакциями  (Transaction  facts).  Они  основаны  на

отдельных  событиях  (типичными  примерами  которых  являются  телефонный

звонок или снятие денег со счета с помощью банкомата);  

• факты,  связанные  с  «моментальными  снимками»  (Snapshot  facts).

Основаны на состоянии объекта (например, банковского счета) в определенные

моменты времени, например на конец дня, или месяца. Типичными примерами

таких фактов являются объем продаж за день или дневная выручка;  

• факты, связанные с элементами документа (Line-item facts). Основаны на

том  или  ином  документе  (например,  счете  за  товар  или  услуги)  и  содержат

подробную информацию об элементах этого документа (например, количестве,

цене, проценте скидки);  

• факты,  связанные  с  событиями  или  состоянием  объекта  (Event  or  state

facts).  Представляют  возникновение  события  без  подробностей  о  нем

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

подробностей).
40

 

Для  примера  рассмотрим  факты,  связанные  с  элементами  документа  (в

данном случае счета, выставленного за товар).  

Таблица  фактов,  как  правило,  содержит  уникальный  составной  ключ,

объединяющий  первичные  ключи  таблиц  измерений.  Чаще  всего  это

целочисленные  значения  либо  значения  типа  «дата/время»  —  ведь  таблица

фактов может содержать сотни тысяч или даже миллионы записей, и хранить в

ней  повторяющиеся  текстовые  описания,  как  правило,  невыгодно  —  лучше

поместить  их  в  меньшие  по  объему  таблицы  измерений.  При  этом  как

ключевые,  так  и  некоторые  неключевые  поля  должны  соответствовать

будущим  измерениям  OLAP-куба.  Помимо  этого  таблица  фактов  содержит

одно  или  несколько  числовых  полей,  на  основании  которых  в  дальнейшем

будут получены агрегатные данные.  

Пример  таблицы  фактов,  которая  может  быть  построена  на  основе  базы

данных VSource, приведен на рис. 2.1 и рис 2.2..

 

Рис. 2.1. Таблица фактов с данными


41

 

 

Рис. 2.2. Структура таблица фактов

В  данном  примере  измерениям  будущего  куба  соответствуют  первые

шесть полей, а агрегатным данным — последние четыре.  

Отметим,  что  для  многомерного  анализа  пригодны  таблицы  фактов,

содержащие  как  можно  более  подробные  данные  (то  есть  соответствующие

членам  нижних  уровней  иерархии  соответствующих  измерений).  В  данном

случае  предпочтительнее  взять  за  основу  факты  продажи  товаров  отдельным

заказчикам, а не суммы продаж для разных стран — последние все равно будут

вычислены OLAP-средством. Исключение можно сделать, пожалуй, только для

клиентских OLAP-средств (о них мы поговорим чуть позже), поскольку в силу

ряда ограничений они не могут манипулировать большими объемами данных.  

Отметим,  что  в  таблице  фактов  нет  никаких  сведений  о  том,  как

группировать записи при вычислении агрегатных данных. Например, в ней есть

идентификаторы продуктов или клиентов, но отсутствует информация о том, к

какой  категории  относится  данный  продукт  или  в  каком  городе  находится

данный  клиент.  Эти  сведения,  в  дальнейшем  используемые  для  построения

иерархий в измерениях куба, содержатся в таблицах измерений.

Пример:

Факты  (меры)  ХД  для  анализа  состояния  материально-технической  базы

высших образовательных учреждений:

•Количество  продуктов  по  типам  входящих  в  материално  техническую

базу ВОУ;

FactEdu

FactEduID

TimeID

ProductID

UniversityID

ProductsCount

ProductsCountInEdu

ProductsCountWorkPro

StudentsCount
42

 

•Средная число соотношения продуктов к числу  студентов ВОУ.

Таблицы  измерений.  Таблицы  измерений  содержат  неизменяемые  либо

редко изменяемые данные. В подавляющем большинстве случаев  эти  данные

представляют  собой  по  одной  записи  для  каждого  члена  нижнего  уровня

иерархии в измерении. Таблицы измерений также содержат как минимум одно

описательное  поле  (обычно  с  именем  члена  измерения)  и,  как  правило,

целочисленное ключевое поле (обычно это суррогатный ключ) для однозначной

идентификации  члена  измерения.  Если  будущее  измерение,  основанное  на

данной таблице измерений, содержит иерархию, то таблица измерений также

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

иерархии. Нередко (но не всегда) таблица измерений может содержать и поля,

указывающие  на  «прародителей»,  и  иных  «предков»  в  данной  иерархии  (это

обычно характерно для сбалансированных иерархий), а также дополнительные

атрибуты  членов  измерений,  содержавшиеся  в  исходной  оперативной  базе

данных (например, адреса и телефоны клиентов).  

Каждая  таблица  измерений  должна  находиться  в  отношении  «один  ко

многим» с таблицей фактов.  

Отметим,  что  скорость  роста  таблиц  измерений  должна  быть

незначительной по сравнению со скоростью роста таблицы фактов; например,

добавление  новой  записи  в  таблицу  измерений,  характеризующую  товары,

производится только при появлении нового товара, не продававшегося ранее.

Пример:

Измерения  ХД  для  анализа  состояния  материально-технической  базы

высших образовательных учреждений:

•Время

•ВОУ

•Продукты (относящийся к материально технической базе ВОУ)

Пример таблицы измерений приведен на рис. 2.3. и 2.4.
43

 

 

Рис. 2.3. Примерная структура таблицы измерений

 

Рис. 2.4. Таблица измерений с данными

Следующий шаг - определение структурной единицы (зерна). Зерно (grain)

- нижний уровень детализации данных, хранящихся в ХД.

Информация может суммироваться на различных уровнях в соответствии с

иерархической  структурой.  Ежедневные  покупки  техники  или  канцелярий

могут  суммироваться  по  неделям,  месяцам  или  годам;  подкупленные  товары

DimProducts

ProductKey

ProductType

ProductBrend

ProductName
44

 

можно  суммировать  по  продуктам,  категориям  продуктов  или  линейкам

продуктов.

Пользователи  ХД  могут  работать  с  различными  уровнями  суммируемых

данных.  Вопрос  заключается  в  следующем:  в  какой  степени  детализации

нуждается пользователь?

Всегда  существует  вероятность  того,  что  какой-то  пользователь  в  своем

поиске  пожелает  дойти  до  базовой  транзакции,  и  на  основании  этого  можно

прийти к выводу, что разработчик ХД всегда должен обеспечить самый низкий

уровень  детализации,  но  обычно  в  этом  нет  необходимости,  а  на  практике

зачастую  неудобно.  Это  требует  хранения  в  хранилище  данных  огромных

объемов  информации.  Необходимо  внимательно  обдумать  те  вопросы

относительно  деятельности  вашей  фирмы,  на  которые  вы  хотите  получать

ответы, и соответственно выберите степень детализации данных. Сотрудникам

управления  министерства,  желающим  отследить  изменения  материально-

технический базе ВОУ, нет нужды сохранять в ХД данные о каждой покупке

технике  и  т.д.;  покупки  можно  суммировать  на  уровне  продуктов.  Но  если

необходимо  проанализировать  поведение  потребителей,  то  потребуется

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

определяется интенсивностью изменений: для отслеживания заработной платы

служащих  в  течение  длительного  периода  времени  не  имеет  смысла

использовать  в  качестве  "зерна"  день  или  неделю,  поскольку  оплата  труда

сотрудников пересматривается один раз в год.  

Определив  степень  детализации,  можно  установить  остальные  атрибуты

таблицы  измерений.  В  ХД  исторических  данных  в  качестве  одного  из

измерений обязательно присутствует время, и в таблицу измерений необходимо

поместить  информацию  о  единицах  времени,  подходящих  для  данного  ХД.

Дни, недели, месяцы и годы, очевидно, необходимы, если степень детализации

соответствует  уровню  ежедневных  транзакций.  Если  требуются  итоговые
45

 

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

лишь такие единицы времени, как годы и месяцы.

Пример:

Таблица 2.1. Степень детализации ХД для анализа состояния

материальной технической базе ВУЗов:

Время  Продукты   ВОУ

Год  Тип  Название

Полугодие  Бренд   Регион

Квартал  Название    

Иерархия  строится  по  принципу  убывания  сверху  вниз:  вверху  более

общие  определения,  внизу  более  подробные.  В  измерении  Время  я  выбрал  3

уровня  иерархии:  Год,  Полгодие,  Квартал.  Это  обусловлено  тем,  что  ВОУ

приобретают  продукты  не  очень  часто,  нет  необходимости  отслеживать

еженедельные или ежемесячные изменение. В измерении Продукты я выбрал 3

уровня  иерархии  чтобы  можно  было  отбирать  данные  по  Типу  продуктов

(принтеры,  сканеры,  компьютеры),  По  бренду  (Acer,  HP,  Dell,  Toshiba),  по

Названию.  В  измерении  высшего  образовательного  учреждения я  выбрал два

уровня иерархии: название (ТГТУ, НУУ и тд), Регион (Ташкент, Самарканд).

Таким образом, общая структура измерений выглядит следующим образом

(Таблица 2.2.).

Таблица 2.2. Общая структура измерений  

Время  Продукты   ВОУ

Год  Тип  Название

Полгодие  Бренд   Регион

Квартал  Название  Адрес

 Общая Количество  Телефон  

  Общая количество

технике в учебным

Факс
46

 

процессе

  Количество

Технике в

пригодном

состояний

 

 

Одно измерение куба может содержаться как в одной таблице (в том числе

и при наличии нескольких уровней иерархии), так и в нескольких связанных

таблицах,  соответствующих  различным  уровням  иерархии  в  измерении.  Если

каждое измерение содержится в одной таблице, такая схема хранилища данных

носит  название  «звезда»  (star  schema).  Пример  такой  схемы  приведен  на        

рис. 2.5.

 

Рисунок 2.5. Пример схемы "звезда"

Если  же  хотя  бы  одно  измерение  содержится  в  нескольких  связанных

таблицах,  такая  схема  хранилища  данных  носит  название  «снежинка»

(snowflake schema). Дополнительные таблицы измерений в такой схеме, обычно

соответствующие  верхним  уровням  иерархии  измерения  и  находящиеся  в

соотношении  «один  ко  многим»  в  главной  таблице  измерений,

DimProducts *

ProductKey

ProductType

ProductBrend

ProductName

DimTime *

TimeKey

CalendarYear

CalendarSemester

CalendarQuarter

DimUniversity *

UniversityKey

Name

Region

Phone

Fax

FactEdu *

FactEduID

TimeID

ProductID

UniversityID

ProductsCount

ProductsCountInEdu

ProductsCountWorkPro

StudentsCount
47

 

соответствующей  нижнему  уровню  иерархии,  иногда  называют  консольными

таблицами (outrigger table). Пример схемы «снежинка» приведен на рис. 2.6.

 

Рисунок 2.6. Пример схемы "снежинка"

Отметим,  что  даже  при  наличии  иерархических  измерений  с  целью

повышения  скорости  выполнения  запросов  к  хранилищу  данных  нередко

предпочтение отдается схеме «звезда».  

Однако  не  все  хранилища  данных  проектируются  по  двум  приведенным

выше  схемам.  Так,  довольно  часто  вместо  ключевого  поля  для  измерения,

содержащего данные типа «дата», и соответствующей таблицы измерений сама

таблица  фактов  может  содержать  ключевое  поле  типа  «дата».  В  этом  случае

соответствующая таблица измерений просто отсутствует.  

Пример  отступления  от  правил  —  наличие  нескольких  разных  иерархий

для  одного  и  того  же  измерения.  Типичные  примеры  таких  иерархий  —

иерархии для календарного и финансового года (при условии, что финансовый

год  начинается  не  с  1  января),  или  с  различными  способами  группировки

членов  измерения  (например,  группировать  товары  можно  по  категориям,  а

можно  и  по  компаниям-поставщикам).  В  этом  случае  таблица  измерений
48

 

содержит  поля  для  всех  возможных  иерархий  с  одними  и  теми  же  членами

нижнего уровня, но с разными членами верхних уровней.  

Как мы уже отмечали выше, таблица измерений может содержать поля, не

имеющие  отношения  к  иерархиям  и  представляющие  собой  просто

дополнительные атрибуты членов измерений (member properties). Иногда такие

атрибуты могут быть использованы при анализе данных.  

Следует сказать, что для создания реляционных хранилищ данных нередко

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

оптимизировано  с  точки  зрения  скорости  выполнения  запросов.  Примером

такого  продукта  является  Sybase  Adaptive  Server  IQ,  реализующий

нетрадиционный  способ  хранения  данных  в  таблицах  (не  по  строкам,  а  по

столбцам).  Однако  создавать  хранилища  можно  и  в  обычных  реляционных

СУБД.

 

2.4. OLAP куб

 

Технология  комплексного  многомерного  анализа  данных  получила

название  OLAP  (On-Line  Analytical  Processing).  OLAP  —  это  ключевой

компонент организации хранилищ данных. Концепция  OLAP была описана в

1993 году Эдгаром Коддом, известным исследователем баз данных и автором

реляционной модели данных (см. E.F. Codd, S.B. Codd, and C.T.Salley, Providing

OLAP  (on-line  analytical  processing)  to  user-analysts:  An  IT  mandate.  Technical

report,  1993).  В  1995  году  на  основе  требований,  изложенных  Коддом,  был

сформулирован  так  называемый  тест  FASMI  (Fast  Analysis  of  Shared

Multidimensional  Information  —  быстрый  анализ  разделяемой  многомерной

информации),  включающий  следующие  требования  к  приложениям  для

многомерного анализа:

• Fast  (Быстрый)  -  предоставление  пользователю  результатов  анализа  за

приемлемое время (обычно не более 5 с), пусть даже ценой менее детального

анализа;
49

 

• Analysis  (Анализ)  -  возможность  осуществления  любого  логического  и

статистического  анализа,  характерного  для  данного  приложения,  и  его

сохранения в доступном для конечного пользователя виде;

• Shared  (Разделяемой)  -  многопользовательский  доступ  к  данным  с

поддержкой  соответствующих  механизмов  блокировок  и  средств

авторизованного доступа;

• Multidimensional  (Многомерной)  -  многомерное  концептуальное

представление  данных,  включая  полную  поддержку  для  иерархий  и

множественных иерархий (это — ключевое требование OLAP);

• Information  (Информации)  -  приложение  должно  иметь  возможность

обращаться  к  любой  нужной  информации,  независимо  от  ее  объема  и  места

хранения.

Следует отметить, что OLAP-функциональность может быть реализована

различными  способами,  начиная  с  простейших  средств  анализа  данных  в

офисных  приложениях  и  заканчивая  распределенными  аналитическими

системами, основанными на серверных продуктах.

Многомерное представление информации. Кубы. OLAP предоставляет

удобные быстродействующие средства доступа, просмотра и анализа деловой

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

модель  данных,  организуя  их  в  виде  многомерных  кубов  (Cubes).  Осями

многомерной  системы  координат  служат  основные  атрибуты  анализируемого

бизнес-процесса.  Например,  для  продаж  это  могут  быть  товар,  регион,  тип

покупателя.  В  качестве  одного  из  измерений  используется  время.  На

пересечениях осей - измерений (Dimensions) - находятся данные, количественно

характеризующие процесс - меры (Measures). Это могут быть объемы продаж в

штуках  или  в  денежном  выражении,  остатки  на  складе,  издержки  и  т.  п.

Пользователь, анализирующий информацию, может “разрезать” куб по разным

направлениям,  получать  сводные  (например,  по  годам)  или,  наоборот,
50

 

детальные  (по  неделям)  сведения  и  осуществлять  прочие  манипуляции,

которые ему придут в голову в процессе анализа.

В  качестве  мер  в  трехмерном  кубе,  изображенном  на  рис.  2.7.,

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

Измерения  представлены  на  определенных  уровнях  группировки:  товары

группируются  по  категориям,  магазины  -  по  странам,  а  данные  о  времени

совершения операций - по месяцам.  

 

Рис. 2.7. Пример куба

“Разрезание”  куба.  Даже  трехмерный  куб  сложно  отобразить  на  экране

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

говорить о кубах с количеством измерений, большим трех? Для визуализации

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

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

строк и столбцов.

Двумерное  представление  куба  можно  получить,  “разрезав”  его  поперек

одной  или  нескольких  осей  (измерений):  мы  фиксируем  значения  всех

измерений,  кроме  двух,  -  и  получаем  обычную  двумерную  таблицу.  В

горизонтальной  оси  таблицы  (заголовки  столбцов)  представлено  одно

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

значения  мер.  При  этом  набор  мер  фактически  рассматривается  как  одно  из

измерений  -  мы  либо  выбираем  для  показа  одну  меру  (и  тогда  можем

разместить  в  заголовках  строк  и  столбцов  два  измерения),  либо  показываем
51

 

несколько мер (и тогда одну из осей таблицы займут названия мер, а другую -

значения единственного “неразрезанного” измерения).

Взгляните на рис. 2.8. - здесь изображен двумерный срез куба для одной

меры  -  Unit  Sales  (продано  штук)  и  двух  “неразрезанных”  измерений  -  Store

(Магазин) и Время (Time).

 

Рис. 2.8. Двумерный срез куба для одной меры

На рис. 2.9. представлено лишь одно “неразрезанное” измерение - Store, но

зато здесь отображаются значения нескольких мер - Unit Sales (продано штук),

Store Sales (сумма продажи) и Store Cost (расходы магазина).

 

Рис. 2.9. Двумерный срез куба для нескольких мер

Двумерное представление куба возможно и тогда, когда “неразрезанными”

остаются и более двух измерений. При этом на осях среза (строках и столбцах)

будут размещены два или более измерений “разрезаемого” куба - см. рис. 2.10.

 

Рис 2.10. Двумерный срез куба с несколькими измерениями на одной оси

Значения,  “откладываемые”  вдоль  измерений,  называются  членами  или

метками (members). Метки используются как для “разрезания” куба, так и для
52

 

ограничения  (фильтрации)  выбираемых  данных  -  когда  в  измерении,

остающемся  “неразрезанным”,  нас  интересуют  не  все  значения,  а  их

подмножество, например три города из нескольких десятков. Значения меток

отображаются  в  двумерном  представлении  куба  как  заголовки  строк  и

столбцов.

Метки  могут  объединяться  в  иерархии,  состоящие  из  одного  или

нескольких  уровней  (levels).  Например,  метки  измерения  “Магазин”  (Store)

естественно объединяются в иерархию с уровнями:

All (Мир)

 Country (Страна)

   State (Штат)

     City (Город)

        Store (Магазин).

В  соответствии  с  уровнями  иерархии  вычисляются  агрегатные  значения,

например объем продаж для USA (уровень “Country”) или для штата California

(уровень “State”). В одном измерении можно реализовать более одной иерархии

- скажем, для времени: {Год, Квартал, Месяц, День} и {Год, Неделя, День}.

Отметим,  что  иерархии  могут  быть  сбалансированными  (balanced),  как,

например,  иерархия,  представленная  на  рис.  2.11.,  а  также  иерархии,

основанные  на  данных  типа  "дата—время",  и  несбалансированными

(unbalanced).  Типичный  пример  несбалансированной  иерархии  —  иерархия

типа  "начальник—подчиненный"  (ее  можно  построить,  например,  используя

значения поля Salesperson исходного набора данных из рассмотренного выше

примера),  представлен  на  рис.  2.12.  Иногда для  таких иерархий используется

термин Parent-child hierarchy.

Существуют  также  иерархии,  занимающие  промежуточное  положение

между  сбалансированными  и  несбалансированными  (они  обозначаются

термином ragged — "неровный").


53

 

 

Рисунок 2.11. Иерархия в измерении, связанном с географическим

положением клиентов

 

Рис 2.12. Несбалансированная иерархия

Обычно  они  содержат  такие  члены,  логические  "родители"  которых

находятся  не  на  непосредственно  вышестоящем  уровне  (например,  в

географической  иерархии  есть  уровни  Country,  City  и  State,  но  при  этом  в

наборе  данных  имеются  страны,  не  имеющие  штатов  или  регионов  между

уровнями Country и City; рис. 2.13.).

 

Рисунок 2.13. "Неровная" иерархия

Отметим,  что  несбалансированные  и  "неровные"  иерархии

поддерживаются  далеко  не  всеми  OLAP-средствами.  Например,  в  Microsoft

Analysis Services 2000 поддерживаются оба типа иерархии, а в Microsoft OLAP

Services 7.0 — только сбалансированные. Различным в разных OLAP-средствах

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

членов одного уровня, и максимально возможное число самих измерений.

Архитектура OLAP приложений. Все, что говорилось выше про OLAP,

по сути, относилось к многомерному  представлению данных. То, как данные
54

 

хранятся,  грубо  говоря,  не  волнует  ни  конечного  пользователя,  ни

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

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

уровня:

 Многомерное представление данных - средства конечного пользователя,

обеспечивающие  многомерную  визуализацию  и  манипулирование  данными;

слой  многомерного  представления  абстрагирован  от  физической  структуры

данных и воспринимает данные как многомерные.

 Многомерная обработка - средство (язык) формулирования многомерных

запросов  (традиционный  реляционный  язык  SQL  здесь  оказывается

непригодным) и процессор, умеющий обработать и выполнить такой запрос.

 Многомерное  хранение  -  средства  физической  организации  данных,

обеспечивающие эффективное выполнение многомерных запросов.

Первые два уровня в обязательном порядке присутствуют во всех OLAP-

средствах.  Третий  уровень,  хотя  и  является  широко  распространенным,  не

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

и из обычных реляционных структур; процессор многомерных запросов в этом

случае  транслирует  многомерные  запросы  в  SQL-запросы,  которые

выполняются реляционной СУБД.

Конкретные  OLAP-продукты,  как  правило,  представляют  собой  либо

средство многомерного представления данных, OLAP-клиент (например, Pivot

Tables  в  Excel  2000  фирмы  Microsoft  или  ProClarity  фирмы  Knosys),  либо

многомерную серверную СУБД, OLAP-сервер (например, Oracle Express Server

или Microsoft OLAP Services).

Слой  многомерной  обработки  обычно  бывает  встроен  в  OLAP-клиент

и/или  в  OLAP-сервер, но может быть выделен  в чистом виде, как, например,

компонент Pivot Table Service фирмы Microsoft.

 


55

 

2.5. Выводы ко второй главе

 

1.  Проведен  первичный  анализ  вопросов  и  определен  перечень  данных,

которые могут потребоваться для ответа на запрос пользователей.

2.  Разработана структура ХД, содержащая три таблице измерений и одну

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

3.  OLAP (On-Line Analytical Processing) является основным компонентом

построения  и  применения  хранилищ  данных.  Эта  технология  основана  на

построении  многомерных  наборов  данных  —  OLAP-кубов,  оси  которого

содержат параметры, а ячейки — зависящие от них агрегатные данные.  


56

 

ГЛАВА 3. РЕАЛИЗАЦИЯ ПОДСИСТЕМЫ МНОГОМЕРНОГО

АНАЛИЗА ДАННЫХ В СППР ДЛЯ УПРАВЛЕНИЯ ВНЕДРЕНИЯ

ИНФОРМАЦИОННО-КОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ В

УЧЕБНЫЙ ПРОЦЕСС МВССО

3.1. Разработка хранилище данных для многомерного анализа

 

Для  разработки  хранилища  данных  было  принято  решение  создать

многомерный куб «Анализ показателей материально технической базы ВОУ».

Куб  «Анализ  показателей  материально  технической  базы  ВОУ»,  показывает

параметры  материально  техническую  обеспеченность  ВОУ.  Данный  куб

использует  небольшое  число  измерений  и  использует  пользовательских

агрегирующих функций.

Можно выделить следующий алгоритм создания куба:

1.  Спроектировать многомерный куб – выделить необходимые измерения,

иерархии и меры;

2.  На  основании  предыдущего  пункта  создать  в  хранилище  данных

соответствующие таблицы измерений и фактов;

4.  Добавить созданный куб в OLAP-сервер.

Нам  требуется  создать  куб,  хранящий  информацию  о  материально-

технической  базе  ВОУ.  У  нашего  куба  должно  быть    меры:  Количество

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

продуктов    используемых  в  учебным  процессе,  Количество  продуктов  в

состоянии исправности, Количество студентов (таблица «FactEdu»). В качестве

измерений  выбираем  Время  (таблица  «DimTime»),  Продукты  (таблицы

«DimProduct»), ВОУ(таблица «DimUniversity»).

Для  создание  хранилище  данных  с  среде  MSSQL  создаем  базу  данных

EducationDW.  Хранилище  данных  будет  служить  для  физического  хранения

очищенных  и  согласованных  данных    из  разных  источников.  Для  анализа
57

 

состоянии  материально  технической  базе  ВОУ  создаем  нижеследующие

таблицы:

1. DimUniversity  –  таблица  измерений.  В  этой  таблице  будут  храниться

обобщенные данные о высших образовательных учреждений. Также создается

столбец Регион для фильтрации данных

 

Рис 3.1. Таблица измерений DimUniversity

2. DimProducts-таблица  измерении.  В  этой  таблице  будет  храниться

данные  об  объектах  входящих  в  состав  материально  технической  базе  ВОУ.

Например:  компьютеры,  принтеры,  парты,  маршрутизаторы,  Телевизоры,

стулья и т.д. . Объекты будут группироваться по типу (ProductType).

 

Рис 3.2. Таблица измерений DimProducts

3. DimTime  –таблица  измерения  времени.  Нижний  границе  детализации

выбран квартал года.

 

Рис 3.3. Таблица измерений DimTime

 

DimProducts

ProductKey

ProductType

ProductBrend

ProductName

DimTime

TimeKey

CalendarYear

CalendarQuarter

CalendarSemester
58

 

4. FactEdu  –таблица  фактов.  В  таблице  хранятся  факты  об  объектах

входящих в состав материальную техническую база ВОУ.  

 

Рис 3.4. Таблица фактов FactEdu

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

 

Рис 3.5. Диаграмма таблиц

Для создании куба был проведен сравнительный анализ OLAP-серверов.

 

 

 

FactEdu

FactEduID

TimeID

ProductID

UniversityID

ProductsCount

ProductsCountInEdu

ProductsCountWorkPro

StudentsCount
59

 

3.1.1. Выбор OLAP-сервера

 

Основные требования, предъявляемые к OLAP-серверу:

• возможность  создания  пользовательских  функций  для  вычисления

значений  мер  (в  частности,  создание  пользовательских  агрегирующих

функций);

• доступ OLAP-клиентов по унифицированному протоколу;

• возможность добавления новых кубов;

• широкий спектр поддерживаемых СУБД.

На  сегодняшний  день  существует  множество  поставщиков  OLAP-

серверов.  Все  крупные  поставщики  СУБД,  такие  как  Oracle,  Microsoft,  IBM,

Sybase, выпускают также и OLAP-сервера к своим СУБД. Помимо крупнейших

производителей  СУБД  на  рынке  OLAP-продуктов  фигурируют  и  другие

компании, работающие в области Business Intelligence, такие как MicroStrategy,

Pentaho, SAS Institute, Jedox.   

Все  современные  OLAP-серверы  удовлетворяют  принципам

аналитической  обработки  в  реальном  времени,  изложенным  Коддом  в  1993

году, а позднее дополненными в 1995 году.

Основными  проблемами  использования  OLAP-серверов  являются

проблемы производительности, разреженности данных и «взрыва» данных.  

 Проблема производительности связана к требованию к OLAP-продукту –

времени  отклика  сервера  (которое  должно  быть  не  более  5  секунд  по  тесту

FASMI).  Объѐм  анализируемых  данных  часто  превышает  миллионы  записей,

поэтому  такое  время  сложно  достичь.  Данная  проблема  производителями

решается по-разному, но в основном, решения основываются на кешировании

сосчитанных агрегатных (суммарных) значениях, либо на предварительном их

вычислении и хранении в базе данных.

 Предварительное  вычисление  и  хранения  в  БД  агрегатных  значений

порождает  новую  проблему  –  проблему  эффекта  «взрыва  данных»,  т.е.  к
60

 

резкому  увеличению  объѐма  хранимых  данных.  Это  вызвано  тем,  что  

количество  хранимых  агрегатов  растѐт  в  экспоненциальной  зависимости  от

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

проблемам  при  разреженном  распределении  исходных  данных  по

многомерному  кубу.  Отсутствующие  или  недопустимые  значения  данных

создают разрежение в модели данных OLAP. Наиболее удачные OLAP-серверы

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

плохо заполненные кубы «не раздуваются» в объеме.

Все  современные  OLAP-серверы  могут  работать  одновременно  с

несколькими кубами, поддерживать работу с большим числом измерений, мер

и  иерархий.  Некоторые  продукты  поддерживают  несколько  иерархий  для

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

другие  функции,  такие  как  «write-back»,  позволяющую  аналитику  изменить

любое  значение  в  таблице-отчѐте,  посмотреть  к  каким  последствиям  оно

приведѐт и при необходимости сохранить новое значение в хранилище данных.  

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

запросов  к  многомерным  данным  –  в  области  OLAP    на  данный  момент  не

существует  каких-либо  стандартизованных  протоколов  обмена  информацией.

Но при этом почти каждый сервер поддерживает стандарты «де факто» обмена

информацией  –  XMLA  (XML  for  Analysis)  и  языка  запросов  к  многомерным

данным фирмы Microsoft – MDX (Multidimensional Expressions).

Для  выбора  OLAP-сервера,  удовлетворяющего  заявленным  требованиям,

было  принято  решение  провести  сравнительный  анализ  наиболее  известных

серверов.

 

3.1.2. Сравнительный анализ существующих OLAP-серверов

 

В виду достаточно большого количества производителей OLAP-серверов

было  принято  решение  рассмотреть  только  наиболее  известные  и  долго
61

 

работающие  на  рынке  фирмы,  а  также  ряд  бесплатных  продуктов.  Таким

образом, были выбраны следующие продукты (табл. 3.1):

Таблица 3.1.  Исследуемые OLAP-сервера

№  Фирма-производитель  Название OLAP-сервера

1  Microsoft  Analysis Services

2  Oracle  Essbase

3  IBM  Cognos TM1

4  Pentaho  Mondrian

5  Jedox  Palo

Для исследования возможностей и сравнения OLAP-серверов необходимо

определить критерии, по которым данные продукты можно сравнивать. Выбор

критериев  сравнения  серверов  происходил  на  основании  требований,

предъявляемых к OLAP-серверу, а также некоторых характеристик, влияющих

на  быстродействие  сервера,  гетерогенность  и  безопасность  среды,  в  которой

работает сервер.

Таким образом, были выбраны следующие критерии:

1.  Список поддерживаемых СУБД.

2.  Список  поддерживаемых  форм  хранения  данных

(MOLAP/ROLAP/HOLAP).

3.  Возможность создания вычисляемых меток. С помощью вычисляемых

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

данных, но которые можно вычислить по формуле.

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

Агрегирующие  функции  –  функции,  вычисляющие  суммарный  результат,

например  сумма  значений,  среднее  значение,  количество  элементов  и  др.

Помимо  стандартных  агрегирующих  функций,  необходимо  предусмотреть

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

агрегирующее значение по определѐнной формуле.
62

 

5.  Оптимизация  схемы  агрегирования,  т.е.  возможность  изменения

количества  вычисленных  заранее  агрегирующих  значений  (агрегатов).  Чем

больше  агрегатов  хранится  в  готовом  виде,  тем  выше  производительность

системы  и  тем  меньше  среднее  время  ответа  на  запрос.  В  то  же  время,

увеличение  количества  хранимых  агрегатов  приводит  к  увеличению  объема

хранимых  данных.  Возможность  сохранять  только  те  агрегаты,  которые

наиболее  часто  используются  в  запросах  пользователей,  позволяет  получить

наименьший объем хранилища данных при максимальной производительности

для  наиболее  популярных  запросов  к  БД.    Поэтому  данный  критерий

достаточно важен при выборе OLAP-сервера.

6.  Масштабируемость  и  расширяемость.  Масштабируемость  –  

возможность  работы  с  различными  объемами  данных:  от  очень  маленьких

(менее 10 тыс. записей) до очень больших (более 1 млн. записей) без изменения

состава  программного  продукта.  Расширяемость  –  возможность  добавления

новых  многомерных  кубов  данных  без  изменения  состава  программного

продукта.

7.  Удобные средства создания кубов и администрирования.

8.  Решение проблемы «взрыва данных».

9.   Решение проблемы разреженности данных.

10.  Список поддерживаемых API и языков запросов. Необходимо, чтобы

API  и  язык  запросов,  используемые  OLAP-сервером,  поддерживались  OLAP-

клиентом.

11.  Поддержка Unix-подобных операционных систем.

12.  Документирование.  OLAP-сервер  должен  иметь  хорошую

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

13.  Цена продукта на минимальную конфигурацию.

Проанализируем каждый продукт по предложенным критериям:

1)  OLAP-сервер Microsoft Analysis Services
63

 

Microsoft  Analysis  Services  (MSAS)  -  часть  Microsoft  SQL  Server,

включающий  в  себя  набор  средств  для  работы  с  OLAP  и  интеллектуальным

анализом данных. Последняя версия - Microsoft Analysis Services 2008.

1.  MSAS поддерживает только одну СУБД - Microsoft SQL Server.

2.  MSAS поддерживает все три вида хранения данных: MOLAP, ROLAP и

HOLAP.

3.  MSAS поддерживает создание вычисляемых меток. Следует отметить,

что  для  этого  предусмотрен  удобный  мастер,  облегчающий  создание

вычисляемой метки и редактирования еѐ формулы.

4.  MSAS  поддерживает  создание  пользовательских  агрегирующих

функций.

5.  MSAS предусматривает оптимизацию схемы агрегирования. Используя

Storage  Design  Wizard  можно  найти  компромисс    между  быстродействием

системы и размером хранимых на диске агрегатов.  

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

оптимизацию  хранения,  компрессию  данных  и  распределѐнные  вычисления

(т.е. часть вычислений можно перенести на клиент).

7.  MSAS содержит множество различных «мастеров» и «дизайнеров» по

созданию кубов, измерений, иерархий и администрированию.  

8.  Проблема «взрыва данных» в MSAS решена.

9.  Проблема разреженности данных в MSAS также решена (посредством

компрессии данных).

10.  MSAS поддерживает спецификации OLE DB, ADO DB, XMLA. Язык

запросов к многомерным данным – MDX.

11.  MSAS  может  быть  установлен  только  на  ОС  Windows  совместно  с

Microsoft SQL Server.

12. MSAS  очень  подробно  документирован.  Документация  на  русском

языке.

13.  Стоимость SQL Server 2008 Workgroup Edition - 4000$.
64

 

Следует отметить, что данный продукт поддерживает все типы иерархий и

мер, а также функцию «write-back».

2)  OLAP-сервер Oracle Essbase

Oracle  Essbase  (в  дальнейшем  Essbase)  –  первый  в  мире  OLAP-сервер.

Данный  сервер  изначально  создавался  фирмой  Hyperion  как  расширение

электронных таблиц Lotus 1-2-3 и Microsoft Excel, но впоследствии  в 2007 году

Oracle  купил  Hyperion    и  переименовал  продукт  в  Oracle  Essbase.  Последняя

версия - Oracle Essbase V.11.1.2

1.  Essbase поддерживает только свою СУБД – Oracle.

2.  Essbase поддерживает 2 вида хранения данных: MOLAP и HOLAP.

3.  Essbase поддерживает создание вычисляемых меток. Стоить отметить,

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

процедурный язык программирования  - PL/SQL.

4.  Essbase  поддерживает  создание  пользовательских  агрегирующих

функций, используя язык PL/SQL.

5.  Essbase,  так  же  как  и  MSAS,  предусматривает  гибкую  оптимизацию

схемы агрегирования.  

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

кластеризацию,  функции  отказоустойчивости,  оптимизацию  хранения  и

компрессию данных.

7.  Essbase  содержит  удобный  графический  интерфейс,  напоминающий

интерфейс  Microsoft  Office,  поэтому  освоить  такой  интерфейс  не  будет

проблемой даже для новичка.

8.  Проблема «взрыва данных» в Essbase решена.

9.  Проблема разреженности данных в Essbase также решена.

10.  Essbase  поддерживает  API  для  языков  Java,  C,  Visual  Basic  и

спецификацию XMLA. Язык запросов к многомерным данным – MDX.

11.  Essbase  может  быть  установлен  как  на  ОС  Windows,  так  и  на  Unix-

подобную ОС.
65

 

12.  Essbase,  так  же  как  и  MSAS,  очень  подробно  документирован.

Документация на русском языке.

13.  Стоимость Oracle Essbase V.11.1.2– 40 000 $

Стоит отметить, что данный продукт поддерживает все типы иерархий и

мер, а также функцию «write-back».

3) OLAP-сервер IBM Cognos TM1

Изначально  продукт  разрабатывался  фирмой  Cognos,  но  в  2009  году

Cognos была поглощена компанией IBM и продукт был переименован в IBM

Cognos  TM1.  Основное  отличие  TM1  от  предыдущих  двух  серверов

заключается  в  том,  что  это  запатентованный  64-разрядный  OLAP-сервер,

использующий  подход  In-memory  OLAP.  Данный  подход  состоит  в  

кешировании исходных данных и агрегатов в оперативной памяти, тем самым

увеличивается  производительность  сервера.  Последняя  версия  -  Cognos  TM1

9.5

1.  Сервер хранит данные в своих собственных многомерных структурах

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

инструмент  Turbo  Integrator,  поддерживающий  большинство  существующих

СУБД. Подключение в данном случае происходит через ODBC-драйвер.

2.  TM1 поддерживает один вид хранения данных – MOLAP.

3.  TM1 поддерживает создание вычисляемых меток.

4.  TM1  поддерживает  создание  пользовательских  агрегирующих

функций.  

5.  Помимо  кеширования  TM1  позволяет  сохранять  подсчитанные

агрегаты  в  БД,  тем  самым  предусматривается  гибкая  оптимизация  схемы

агрегирования.  

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

кластеризацию,  функции  отказоустойчивости,  оптимизацию  хранения  и

компрессию данных.
66

 

7.  TM1  содержит  удобный  графический  интерфейс,  встраиваемый  в

Microsoft Excel, а также собственный Web-интерфейс.

8.  Проблема «взрыва данных» в TM1 решена.

9.  Проблема разреженности данных в TM1 также решена.

10.  TM1 поддерживает спецификации OLE DB, XMLA. Язык запросов к

многомерным данным – MDX.

11.  TM1  может  быть  установлен  как  на  ОС  Windows,  так  и  на  Unix-

подобную ОС.

12.  TM1,  так  же  как  Essbase  и  MSAS,  очень  подробно  документирован.

Документация на русском языке.

13.  Стоимость IBM TM1 – 50 000 $

Стоит отметить, что данный продукт поддерживает все типы иерархий и

мер, а также функцию «write-back».

4)  OLAP-сервер Pentaho Mondrian

 В  отличие  от  вышеперечисленных  OLAP-серверов  данный  продукт

является открытым и распространяется под лицензией EPL. Mondrian написан

на Java, что с одной стороны уменьшает быстродействие (ввиду java-машины),

но  с  другой  –  добавляет  свойство  гетерогенности  среды,  в  которой  будет

использоваться  сервер.  Так  же,  как  и  IBM  TM1,  данный  сервер  использует

принцип  In-Memory  (кеширование  агрегатов).  Данный  сервер  используется  в

коммерческом продукте Pentaho Analysis. Последняя версия сервера - Mondrian

3.0.4

1.  Для подключения к хранилищам данных Mondrian используется JDBC-

драйвер.  Таким  образом,  сервер  поддерживает  СУБД,  к  которым  можно

подключаться через JDBC.

2.  Mondrian поддерживает только один вид хранения данных – ROLAP.

3.  Mondrian поддерживает создание вычисляемых меток. Выражения для

меток строятся на основе математических формул и языков SQL/MDX.
67

 

4.  Mondrian  не  поддерживает  создание  пользовательских  агрегирующих

функций.

5.  Mondrian  изначально  хранит  все  агрегаты  в  оперативной  памяти,  но

существует  возможность  создавать  для  агрегатов  свои  таблицы  в  хранилище

данных.  

6.  Mondrian  масштабируем  только с  точки  зрения  увеличения  исходных

данных. Функций кластеризации и отказоустойчивости у сервера нет.

7.  Mondrian содержит достаточно простой, но с другой стороны, удобный

графический  интерфейс  для  создания  кубов.  Графического  интерфейса  для

администрирования  сервера  нет  –  всѐ  администрирование  сводится  к

изменениям параметров в XML-файлах.

8.  Проблема «взрыва данных» в Mondrian решена.

9.  Проблема разреженности данных в Mondrian также решена.

10.  Mondrian  поддерживает  API  для  языков  Java  (OPAL4J)  и

спецификации  XMLA  и  OLE  DB.  Язык  запросов  к  многомерным  данным  –

MDX.

11.  Mondrian  может  быть  установлен  любую  машину,  для  которой

существует Java-машина. В частности, на Windows и Unix-подобную ОС.

12.  Сервер  документирован  достаточно  хорошо.  Документация  на

английском языке.

13.  Продукт  предоставляется  бесплатно. Кроме  того  доступны  исходные

коды продукта.

Следует отметить, что данный продукт поддерживает все типы иерархий,

но не поддерживает полуаддитивные меры и функцию «write-back».

5)   Jedox Palo

Данный  продукт,  так  же  как  Mondrian  является  открытым  и

распространяется  под  лицензией  GPL.  Так  же,  как  IBM  TM1  и  Mondrian,

данный  сервер  использует  принцип  In-Memory  (кеширование  агрегатов).
68

 

Данный  сервер  используется  в  коммерческом  продукте  Palo  Suite.  Последняя

версия сервера - Palo 3.1

1.  Сервер хранит данные в своих собственных многомерных структурах

данных. Для импорта данных в свою БД используется продукт Palo ETL Server,

поддерживающий большинство существующих СУБД.

2.  Palo поддерживает только один вид хранения данных – MOLAP.

3.  Palo поддерживает создание вычисляемых меток. Выражения для меток

строятся на основе математических формул и языков SQL/MDX.

4.  Palo  не  поддерживает  создание  пользовательских  агрегирующих

функций.

5.  Palo  хранит  все  агрегаты  в  оперативной  памяти.  Не  существует

возможности  сохранять  агрегаты  на  жѐстком  диске.  Стоить  отметить,  что

сервер  использует  процессор  видеоадаптера  (GPU),  что  способствует

уменьшению времени вычисления агрегатов.

6.  Palo масштабируем с точки зрения увеличения исходных данных. Palo

очень  эффективно  использует  ресурсы  процессоров  (CPU  и  GPU),  поэтому

сервер  хорошо  масштабируем  в  сторону  увеличения  количества  процессов

(ядер  процессоров).  Функций  кластеризации  и  отказоустойчивости  у  сервера

нет.

7.  Palo  содержит  достаточно  удобный  графический  интерфейс  для

создания  кубов  и  администрирования  сервера.  Palo  может  быть  встроен  в

Microsoft  Excel  и  в  Open  Office,  поэтому  освоить  такой  интерфейс  не  будет

проблемой даже для новичка.

8.  Проблема «взрыва данных» в Palo решена.

9.  Проблема разреженности данных в Palo также решена.

10.  Palo  поддерживает  API  для  языков  Java,  C/C++,  PHP,  .NET  и

спецификации  OLE  DB  и  XMLA.  Язык  запросов  к  многомерным  данным  –

MDX.
69

 

11.  Palo  может  быть  установлен  как  на  ОС  Windows,  так  и  на  Unix-

подобную ОС.

12.  Сервер документирован достаточно хорошо, но только на английском

языке.

13.  Продукт  предоставляется  бесплатно. Кроме  того  доступны  исходные

коды продукта.

Стоит отметить, что данный продукт поддерживает все типы иерархий и

мер, а также функцию «write-back».

 

3.1.3. Результаты сравнительного анализа

 

Объединим  результаты  сравнения  OLAP-серверов  в  одну  сводную

таблицу:

Таблица 3.2. Сравнительный анализ OLAP-серверов

Критерий/OLAP-сервер  MSAS  Essbase  TM1  Mondrian  Palo

Поддержка PostgreSQL  -  -  +  +  +

Поддерживаемые формы

хранения данных

(MOLAP/ROLAP/HOLAP)

(+/+/+)  (+/-/-)  (+/-/-)  (-/+/-)  (+/-/-)

Создание вычисляемых

меток

+  +  +  +  +

Создание

пользовательских

агрегирующих функций

+  +  +  -  -

Оптимизация схемы

агрегирования

+  +  +  +  -

Масштабируемость  +  +  +  +  +
70

 

Удобные средства

создания кубов и

администрирования

+  +  +  +  +

Решение проблемы

«взрыва данных»

+  +  +  +  +

Решение проблемы

разреженности данных

+  +  +  +  +

Поддержка XMLA и

MDX

+  +  +  +  +

Поддержка Unix-

подобных операционных

систем

-  +  +  +  +

Подробное

документирование на

русском языке

+  +  +  -  -

Цена продукта на

минимальную

конфигурацию

4000$  40000$  50000$  беспл.  беспл.

В ходе проведѐнного анализа можно сделать следующие выводы:

• все  рассматриваемые  продукты  полностью  соответствуют  принципам

аналитической  обработки  в  реальном  времени,  изложенным  Коддом,  и  тесту

FASMI ;

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

кластеризацию, функции отказоустойчивости;

• платные  продукты  поддерживают  все  типы  иерархий  и  мер,  а  также

функцию «write-back»;

• платные продукты очень подробно документированы (на русском языке);

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

меток;
71

 

• бесплатные  продукты  не  поддерживают  создание  пользовательских

агрегирующих функций;

• во  всех  продуктах решена  проблема  «взрыва  данных»  и  разреженности

данных;

• все  рассматриваемые  продукты  поддерживают  спецификацию  XMLA  и

язык запросов к многомерным данным  - MDX;

• TM1,  Mondrian,  Palo  используют  принцип  In-Memory  OLAP,  что

увеличивает быстродействие OLAP-сервера;

• Mondrian и Palo имеют открытый исходный код.

Для  предлагаемого  подхода  было  принято  решение  использовать  OLAP-

сервер Microsoft Analysis Services, исходя из следующих соображений:

• Министерством уже куплено Microsoft Sql Server R8 2008;

• Microsoft  Analysis  Services  беспечивают  высокую  производительность

работы приложений и масштабируемость на уровне миллионов записей и тысяч

пользователей;

• Графический интерфейс создания и администрирования кубов у Microsoft

Analysis Services очень удобный.

 

3.2. BI-решения Microsoft Analysis Services

 

BI-решение  компании  Microsoft  основывается  на  масштабируемой

платформе,  предназначенной  для  интеграции  данных,  построения  хранилищ

данных, анализа накопленных данных и построения отчетов. Ядром BI-решения

Microsoft  является  платформа  SQL  Server.  Входящие  в  нее  компоненты,

специфические для BI-решения, приведены в таблица 3.3.

Таблица 3.3. Компоненты BI-решения Microsoft

Компонент  Описание

SQL  Server  Database  Масштабируемая,
72

 

Engine  высокопроизводительная  СУБД,

способная  хранить  большие  объемы

данных,  образующиеся  в  результате

консолидации  данных  в  единое

хранилище  для  анализа  и  построения

отчетов.

SQL  Server  Integration

Services

Платформа  для  выполнения

операций  извлечения,  преобразования  и

загрузки,  которая  обеспечивает

заполнение  ХД  и  его  синхронизацию  с

данными  из  различных  источников,

которые  используются  бизнес-

приложениями организации.

SQL  Server  Analysis

Services

Обеспечивает  возможность

построения  OLAP-решений,  включая

возможность  расчета  ключевых

индикаторов  производительности  (KPI).

Применяется  также  для  построения  data-

mining-решений,  которые  используют

специализированные  алгоритмы  для

выявления  трендов  и  зависимостей  в

бизнес-данных.

SQL  Server  Reporting

Services

Инструментарий построения отчетов,

предназначенный  для  создания,

публикации  и  распространения

детализированных  бизнес-отчетов,  как

для внутренних, так и для внешних целей.

Этапы создания многомерного куба. Для создания куба нужно:

1.  Создать источник данных;
73

 

2.  Создать представления источника данных;

3.  Создать измерений для куба и отредактировать;

4.   Ввыбрать в источнике данных таблицу фактов, а в ней указать, какие

меры будут использованы в кубе;  

5.   Выбрать уже созданные измерения куба;  

6.   Сохранить куб;

7.   Отредактировать схему куба;

8.  Создать пользовательские меры;

9.   Загрузить данные в куб.

OLAP  manager  предлагает  для  администрирования  OLAP  Services  набор

мастеров и специальных инструментов. Мастера позволяют выполнить типовые

действия  самым  простым  способом  и  в  нужной  последовательности.

Специальные  инструменты  имеют  большую  гибкость,  но  в  свою  очередь

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

выполнить  минимум  двумя  путями:  при  помощи  мастера  или  специального

инструмента.  Зачастую  одно  средство  вызывается  из  другого  —  например,

добавить измерение в куб можно непосредственно в Cube Editor либо вызвать

Dimension Manager, который в свою очередь может вызвать Dimension Wizard.

Все  административные  средства  оборудованы  интуитивно  понятным

графическим  интерфейсом,  позволяющим  легко  добиться  желаемого

результата.

В  меню  «Пуск»  последовательно  выбираются  пункты  «Все  программы»,

«Microsoft SQL Server 2008», а затем выбирается «Среда SQL Server Business

Intelligence Development Studio». Открывается среда разработки Microsoft Visual

Studio (рис. 3.6.).
74

 

 

Рис. 3.6. Среда разработки Visual Studio

В  меню  «Файл»  Visual  Studio  указывается  команду  «Создать»,  затем

выбирается пункт «Проект».

В  диалоговом  окне  «Новый  проект»  на  панели  «Типы  проектов»

выбирается  значение  «Проекты  бизнес-аналитики»,  а  на  панели  «Шаблоны»

указывается «Проект служб SSAS»(рис 3.7).

 

Рис. 3.7. Выбор типа создаваемого проекта
75

 

Обратите  внимание,  что  в  нижней  части  этого  диалогового  окна

отображаются установленные по умолчанию имя проекта, имя решения и путь

к проекту. По умолчанию для решения создается новый каталог.

Изменяем имя проекта на EduСube (при этом изменится и имя решения) и

нажмите кнопку ОК(рис 3.8.).

 

Рис. 3.8. Указание имени проекта

Проект EduСube, основанный на шаблоне проекта Analysis Services, будет

создан в рамках нового решения, которое также называется EduСube.

После создания проекта служб Analysis Services работа с проектом обычно

начинается с определения одного или нескольких источников данных, которые

будут  использоваться  в  этом  проекте.  Для  определения  источника  данных

нужно задать строку соединения, которая будет использована для подключения

к этому источнику данных.

Далее  в  рамках  выполнения  работы  необходимо  указать  образец  базы

данных EducationDW в качестве источника данных для проекта служб Analysis

Services  Tutorial.  Хотя  эта  база  данных  в  данном  случае  расположена  на

локальном  компьютере,  часто  исходные  базы  данных  размещаются  на  одном

или нескольких удаленных компьютерах.
76

 

Чтобы  запустить  мастер  создание  источника  данных  нужно  щелкнуть

правой  кнопкой  мыши  в  окно  обозревателе  решений    элемент  «Источники

данных» и выбрать команду «Создать источник данных» (рис 3.9.).

 

Рис. 3.9. Контекстное меню элемента "Источники данных" в

обозревателе решений

На  странице  «Мастер  источников  данных»  нажимается  кнопка  «Далее»,

потом открывается страница «Выбор метода определения соединения»(3.10.).

 

Рис. 3.10. Выбор метода определения соединения
77

 

На странице «Выбор метода определения соединения» можно определить

источник  данных  на  основе  нового  соединения,  существующего  соединения

или  предварительно  определенного  объекта  источника  данных.  В  данной

работе  будет  определен  источник  данных  на  основе  нового  соединения,  для

этого нажимается кнопка «Создать».

В  диалоговом  окне  Диспетчер  соединений  определяются  свойства

соединения  для  источника  данных.  В  текстовое  поле  Имя  сервера  вводится

localhost (рис. 3.11.).

 

Рис. 3.11. Соединение с хранилищем данных EducationDW

В  раскрывающемся  списке  «Выберите  или  введите  имя  базы  данных»

выбирается  «EducationDW».  На  странице  мастера  «Сведения  об

олицетворении»  определяются  учетные  данные  безопасности,  которые  будут

использованы  в  службах  Analysis  Services  для  подключения  к  источнику

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

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

Windows.  Службы  Analysis  Services  не  поддерживают  олицетворения  при

работе с объектами OLAP. Выберется параметр «Использовать учетную запись

службы» и нажимается кнопка «Далее» (рис 3.12.).  
78

 

 

Рис. 3.12. Сведения об олицетворении

На  странице  «Завершение  работы  мастера»  вводится  имя  EducationDW,

затем  нажимается  кнопка  «Готово»  (Рисунок  3.13.),  чтобы  создать  новый

источник данных (Рисунок 3.14.).

 

Рис. 3.13. Имя источника данных

 

Рис. 3.14. Созданный источник

данных

После  этого  подключается  представления  источника  данных.  Для  этого

запускается мастер «Определения представления источника данных»(рис 3.14.)
79

 

 

Рис. 3.14. Мастер «Определения представления источника данных»

С помощь мастера подключается Хранилище данных, выбирается таблицы

измерений  и  фактов,  которые  нужны  для  создания  гиперкуба  (рис  3.15.).  В

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

 

Рис. 3.15. Окно для подключения таблиц измерений и фактов

Если  нажать  на  созданную  представления  источника  данных  (рис.  3.16.)

увидим  наши  таблицы  и  автоматически  сгенерированную  диаграмму,
80

 

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

создать недостающие связи между таблицами.

 

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

 Теперь создается измерения для многомерного куба, для этого запускаем

мастер  измерений.  Первым  создается  измерения  время  на  основы  таблиц

«DimTime».  Выбирается  нужные  столбцы  из  таблицы  (рис.  3.17.),  которые

будут использованы в кубе. Задается имя для измерения и завершается процесс.

 

Рис. 3.17. Выбор столбцов из таблицы
81

 

После  этого  точно  также  создается  другие  измерения,  в  нашем  случае

измерение  продукты,  высшие  образовательные  учреждения.  Если  нажать  на

измерения  откроется  окна  структуре  измерения,  показывающее  исходную

таблицу,  а также элементы измерения (рис. 3.18.).

Рис. 3.18. Окно измерений

После  нужных  настроек  измерений  создается  многомерный  куб.

Запускается  мастер  создания  куба,  выбирается  таблица  фактов  (рис  3.19.)  ,  и

измерений,  созданные  ранние.  Задается  имя  кубу  и  завершается  процесс

определение куба.

 

Рис. 3.19. Выбирается таблица фактов для куба
82

 

После этого развертывается куб, и начинается процесс получение данных с

ХД. Если системой не будет найдено ошибки, служба Analysis Services откроет

окно куба (рис. 3.20.). Также выбрав нужные измерений и нужные меры можно

увидеть срез куба (рис. 3.21.).

 

Рис. 3.20. Вкладка «Структура» в конструкторе кубов

 

Рис. 3.21. Вкладка «Обозреватель» в конструкторе кубов

Теперь  нужно  создать  пользовательскую    меру,  определяющую

соотношения  количество  студентов  к  количеству  компьютеров.  Для  этого  во
83

 

вкладке «Калькуляция» конструктора кубов создаѐтся вычисляемый элемент, и

для этого элемента задается выражения:

[Measures].[Element miqdori]/[Measures].[Talabalar soni]

 

3.3. Выводы по третьей главе

1.  На основе спроектированной ХД реализована реляционная база данных

в  Microsoft  SQL  Server  2008  R2.  Разработан  многомерный  куб  «Анализ

показателей материально технической базы ВОУ». Произведен сравнительный

анализ  OLAP    серверов,  и  на  основы  результатов  анализа  выбран  Microsoft

Analysis Services.

2.  На основе выбранного OLAP сервера поэтапно создается многомерный

куб.  В  начальном  этапе  создан  источник  данных,  представления  источника

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

отредактирована  измерение  куба.  Из  созданного  источника  данных  выбран

таблица фактов, и на основе его указаны меры, которые будут использованы в

кубе.  Из  созданных  измерений  разработан  многомерный  куб.  Для  анализа  и

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

пользовательский  мера  «Соотношение  объектов  входящий  материальную

техническую базу данных ВОУ на контингент студентов».  
84

 

ЗАКЛЮЧЕНИЕ

 

В ходе проведенных работ и исследований автором получены следующие

научно-практические результаты:

1.  В  результате  анализа  предметной  области  показана  актуальность

задачи  построения  отраслевого  центра  накопления  информации  на  основе

технологии  хранилищ  данных.  Выявлены  недостатки  существующего

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

2.  Обоснована необходимость разработки программного обеспечения для

управления централизованным хранилищем информации.

3. Предложена функционально-информационная модель централизованного

хранилища  данных.  Хранилище  данных  спроектирован  для  анализа

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

4.  В  среде  SQL  Server  2008  R2  на  основе  созданной  Хранилищ  данных

разработан многомерной куб для анализа данных. В измерениях многомерного

куба представлена высшие образовательный учреждения, время, также объекты

входящие материальную техническую базу ВОУ.  


85

 

ЛИТЕРАТУРА

 

 

1.  Указ  Президента  Республики  Узбекистан  от  30  мая  2002  года  «О

дальнейшем  развитии  компьютеризации  и  внедрении  информационно-

коммуникационных технологий».

2.  Вступительный  речь  Президента  Республики  Узбекистан  Ислама

Каримова  на  открытии  международной  конференции  «Подготовка

образованного  и  интеллектуально  развитого  поколения  –  как  важнейшее

условие  устойчивого  развития  и  модернизации  страны»  16.02.2012.

http://uza.uz/ru/politics/18080/.

3.  Постановление  Президента  Республики  Узбекистан  10  мая  2011  года

«О  мерах  по  укреплению  материально-технической  базы  высших

образовательных  учреждений  и  кардинальному  улучшению  качества

подготовки высококвалифицированных специалистов».

4.  Архипенков С. Хранилища данных. /  Д. Голубев, О. Максименко – М.:

Диалог-МИФИ, 2002.

5.  Барсегян  А.  Методы  и  модели  анализа  данных:  OLAP  и  Data  Mining

СПб.: БХВ-Петербург, 2004.

6.  Бергер  А.  Microsoft  SQL  Server  2005  Analysis  Services.  OLAP  и

многомерный анализ данных. – СПб.: БХВ-Петербург, 2007.

7.  Спирли  Э.  Корпоративные  хранилища  данных.  Планирование,

разработка и реализация. – М.: Вильямс, 2001.

8.  Харинатх  С.  SQL  Server  2005  Analysis  Services  и  MDX  для

профессионалов. / С. Куинн – М.: Диалектика, 2008.

9.  Козлов В.А. Открытые информационные системы. — М., 1999.

10.  Бойченко А.В., Кондратьев В.К., Филинов Е.Н. Основы открытых

информационных систем. Учебное пособие. — М., 2001.

11.  Дубров А.М., Мхитарян В.С. Многомерные статистические методы и

основы эконометрики. — М., 1998.
86

 

12. Андрейчиков А.В., Андрейчикова О.Н. Анализ, синтез, планирование

решений в экономике. — М., 2000.

13.  Бритов П.А., Липчинский Е.А. Практика построения хранилищ

данных: Система SAS. Ж. Системы управления базами данных. 04-05/1998/

14.  Business Objects Руководство пользователя. Материалы фирмы Терн,

1996.

15.  Калянов Г.Н. Консалтинг при автоматизации предприятий: научно-

методическое издание. — М.: СИНТЕГ, 1997.

16.  Кузьмичева Т.С. Контур Стандарт. Технология работы с системой.

Руководство пользователя. ISL. — M., 1999.

17.  Ивантер А. Деловой барометр показывает «Ясно» ж. «Эксперт» № 29,

авг. 2001.

18.  Корнев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. Базы данных.

Интеллектуальная обработка информации. — М., 2000.

19.  Маклаков С.В. Bpwin Erwin. CASE-средства разработки

информационных систем. — М.,2000.

20. Харрингтон Д. Проектирование объектно-ориентированных баз данных

/ Пер. с англ. —М.: ДМК Пресс, 2001.

21.  Кирстен В., Ирингер М., Рериг Б., Шульте П. СУБД Cache: объектно-

ориентированная разработка приложений. Учебный курс. — СПб.: Питер, 2001.

22.  Пендс Н. Перевод Абушаева Ш. Что относится к OLAP?

OLAPReport.com Last updated on Jan 1999.

23.  Щавелев Л.В. Способы аналитической обработки данных для

поддержки принятия решений. — Ж. СУБД 04-05/1998/

24.  Белов В.С. Информационно-аналитические системы. Учебное пособие

МЭСИ. — М., 2001.

25.  Шрек М. Перeвод Intersoft Lab Технология Хранилищ данных:

последние 10 лет, несомненно были впечатляющими http//www/iso/ru 08/01.
87

 

26.  Косов Д.В. Хранилища данных и семантические разрывы. Olap.ru.

2000.

27.  Коломиец С.В. Проектирование процессов перегрузки данных. Olap.ru.

2000.

28.  Федечкин С. Хранилище данных: вопросы и ответы. PCWeek, 31,

26.08.2003.

29.  Строддер Д., Бурьесси Ж., Янг М. Лучшие ИТ-поставщики на 2004

год. Intelligent enterprise. Деловой ИТ-журнал. 26.01.2004.

30.  Федоров А.Г., Елманова Н.З. Введение в OLAP-технологии Microsoft.

Учебно-справочное издание. — М.: Диалог-МИФИ, 2002.  

31.  Белов В.С. Информационно-аналитические системы. Основы

проектирования и применения. Учебное пособие. — М: МЭСИ, 2004.

32. Хамидов  У.Х.,  Маткаримов  С.  Разработка  и  внедрение

информационно-аналитическую  интегрированную  систему  в  сфере  высшего

образования  для  повышения  эффективность  электронного  документооборота.

Научный  журнал.  «Иқтисодиѐтни  модернизация  қилиш  шароитида  ишлаб

чиқариш соҳаларини инновацион ривожлантириш муаммолари» Тош. ,2012 г.

33. Хамидов  У.Х.,  Гоипназаров  Т.С.  «Ўқув  жараѐнини  бошқариш

масалаларини  ечиш  учун  маълумотлар  омборини  ишлаб  чиқиш»  Научный

журнал. Тош. ,2012 г.

 

 

Интернет-ресурсы:

34. http://ru.wikipedia.org/wiki - свободная Интернет-энциклопедия.

35. http://www.fpm.com/refer/codd.html  -  статья  Е.Ф.  Кодда,  С.Б.  Кодда  и

С.Т.  Солли  "OLAP  для  пользователей-аналитиков:  информационно-

технологический мандат".

36.  http://www.olap.ru – сайт о бизнес-аналитике.

37.  http://www.microsoft.com/msdn - Microsoft Developer Network
88

 

ПРИЛОЖЕНИЕ

 

Приложение 1. Исходный код в виде XMLа многомерного куба.

 

<Cube  xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2"

xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2"

xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/

100"

xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200"

xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/

200"  xmlns:dwd="http://schemas.microsoft.com/DataWarehouse/Designer/1.0"

dwd:design-time-name="e6c974d7-f915-4829-8f82-b177f58813cb"

xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">

 <ID>Education DW</ID>

 <Name>Education DW</Name>

 <CreatedTimestamp>0001-01-01T00:00:00Z</CreatedTimestamp>

 <LastSchemaUpdate>0001-01-01T00:00:00Z</LastSchemaUpdate>

 <Annotations>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramLayout

</Name>

     <Value>

       <dds xmlns="">

         <diagram  fontclsid="{0BE35203-8F91-11CE-9DE3-00AA004BB851}"

mouseiconclsid="{0BE35204-8F91-11CE-9DE3-00AA004BB851}"

defaultlayout="MSDDS.Rectilinear"  defaultlineroute="MSDDS.Rectilinear"
89

 

version="7"  nextobject="16"  scale="100"  pagebreakanchorx="0"

pagebreakanchory="0"  pagebreaksizex="0"  pagebreaksizey="0"  scrollleft="-2581"

scrolltop="4282"  gridx="150"  gridy="150"  marginx="5000"  marginy="5000"

zoom="84"  x="22913"  y="8493"  backcolor="15334399"  defaultpersistence="2"

PrintPageNumbersMode="3"  PrintMarginTop="0"  PrintMarginBottom="635"

PrintMarginLeft="0"  PrintMarginRight="0"  marqueeselectionmode="0"

mousepointer="0"  snaptogrid="0"  autotypeannotation="1"  showscrollbars="1"

viewpagebreaks="0"  donotforceconnectorsbehindshapes="1"

backpictureclsid="{00000000-0000-0000-0000-000000000000}">

           <font>

             <ddsxmlobjectstreamwrapper

binary="01cc0000900144420100065461686f6d61" />

           </font>

           <mouseicon>

             <ddsxmlobjectstreamwrapper binary="6c74000000000000" />

           </mouseicon>

         </diagram>

         <layoutmanager>

           <ddsxmlobj />

         </layoutmanager>

         <ddscontrol  controlprogid="DdsShapes.DdsObjectManagedBridge.2"

tooltip="FactEdu"  left="20"  top="5549"  logicalid="8"  controlid="1"  masterid="0"

hint1="0"  hint2="0"  width="4180"  height="4419"  noresize="0"  nomove="0"

nodefaultattachpoints="0"  autodrag="1"  usedefaultiddshape="1"  selectable="1"

showselectionhandles="1"  allownudging="1"  isannotation="0"  dontautolayout="0"

groupcollapsed="0" tabstop="1" visible="1" snaptogrid="0">

           <control>

             <ddsxmlobjectstreaminitwrapper binary="000800005410000043110000" />

           </control>
90

 

           <layoutobject>

             <ddsxmlobj>

               <property name="LogicalObject" value="dbo_FactEdu" vartype="8" />

             </ddsxmlobj>

           </layoutobject>

           <shape groupshapeid="0" groupnode="0" />

         </ddscontrol>

         <ddscontrol  controlprogid="DdsShapes.DdsObjectManagedBridge.2"

tooltip="DimTime"  left="363"  top="12368"  logicalid="9"  controlid="2"

masterid="0"  hint1="0"  hint2="0"  width="3493"  height="2725"  noresize="0"

nomove="0"  nodefaultattachpoints="0"  autodrag="1"  usedefaultiddshape="1"

selectable="1"  showselectionhandles="1"  allownudging="1"  isannotation="0"

dontautolayout="0" groupcollapsed="0" tabstop="1" visible="1" snaptogrid="0">

           <control>

             <ddsxmlobjectstreaminitwrapper binary="00080000a50d0000a50a0000" />

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property name="LogicalObject" value="dbo_DimTime" vartype="8" />

             </ddsxmlobj>

           </layoutobject>

           <shape groupshapeid="0" groupnode="0" />

         </ddscontrol>

         <ddscontrol  controlprogid="DdsShapes.DdsObjectManagedBridge.2"

tooltip="DimProducts"  left="6600"  top="6396"  logicalid="10"  controlid="3"

masterid="0"  hint1="0"  hint2="0"  width="3000"  height="2725"  noresize="0"

nomove="0"  nodefaultattachpoints="0"  autodrag="1"  usedefaultiddshape="1"

selectable="1"  showselectionhandles="1"  allownudging="1"  isannotation="0"

dontautolayout="0" groupcollapsed="0" tabstop="1" visible="1" snaptogrid="0">
91

 

           <control>

             <ddsxmlobjectstreaminitwrapper binary="00080000b80b0000a50a0000" />

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property  name="LogicalObject"  value="dbo_DimProducts"  vartype="8"

/>

             </ddsxmlobj>

           </layoutobject>

           <shape groupshapeid="0" groupnode="0" />

         </ddscontrol>

         <ddscontrol  controlprogid="DdsShapes.DdsObjectManagedBridge.2"

tooltip="DimUniversity"  left="610"  top="0"  logicalid="11"  controlid="4"

masterid="0"  hint1="0"  hint2="0"  width="3000"  height="3149"  noresize="0"

nomove="0"  nodefaultattachpoints="0"  autodrag="1"  usedefaultiddshape="1"

selectable="1"  showselectionhandles="1"  allownudging="1"  isannotation="0"

dontautolayout="0" groupcollapsed="0" tabstop="1" visible="1" snaptogrid="0">

           <control>

             <ddsxmlobjectstreaminitwrapper binary="00080000b80b00004d0c0000" />

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property name="LogicalObject" value="dbo_DimUniversity" vartype="8"

/>

             </ddsxmlobj>

           </layoutobject>

           <shape groupshapeid="0" groupnode="0" />

         </ddscontrol>
92

 

         <ddscontrol  controlprogid="MSDDS.Polyline"  left="3900"  top="7359"

logicalid="12"  controlid="5"  masterid="0"  hint1="0"  hint2="0"  width="3000"

height="799"  noresize="0"  nomove="0"  nodefaultattachpoints="1"  autodrag="0"

usedefaultiddshape="0" selectable="1" showselectionhandles="0" allownudging="1"

isannotation="0"  dontautolayout="0"  groupcollapsed="0"  tabstop="1"  visible="1"

snaptogrid="0">

           <control>

             <ddsxmlobj>

               <polyline  endtypedst="6"  endtypesrc="files/2/3"  usercolor="0"  linestyle="0"

linerender="1"  customendtypedstid="0"  customendtypesrcid="0"  adornsvisible="1"

/>

             </ddsxmlobj>

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property  name="LogicalObject"

value="dataSet.Relations[FK_FactEdu_DimProducts]" vartype="8" />

               <property name="Virtual" value="0" vartype="11" />

               <property name="VisibleAP" value="0" vartype="3" />

             </ddsxmlobj>

           </layoutobject>

           <connector  lineroutestyle="MSDDS.Rectilinear"  sourceid="3"  destid="1"

sourceattachpoint="14"  destattachpoint="21"  segmenteditmode="0"

bendpointeditmode="0" bendpointvisibility="0" relatedid="0" virtual="0">

             <point x="6600" y="7758" />

             <point x="4200" y="7758" />

           </connector>

         </ddscontrol>
93

 

         <ddscontrol  controlprogid="MSDDS.Polyline"  left="1711"  top="2650"

logicalid="13"  controlid="6"  masterid="0"  hint1="0"  hint2="0"  width="799"

height="3199"  noresize="0"  nomove="0"  nodefaultattachpoints="1"  autodrag="0"

usedefaultiddshape="0" selectable="1" showselectionhandles="0" allownudging="1"

isannotation="0"  dontautolayout="0"  groupcollapsed="0"  tabstop="1"  visible="1"

snaptogrid="0">

           <control>

             <ddsxmlobj>

               <polyline  endtypedst="6"  endtypesrc="files/2/3"  usercolor="0"  linestyle="0"

linerender="1"  customendtypedstid="0"  customendtypesrcid="0"  adornsvisible="1"

/>

             </ddsxmlobj>

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property  name="LogicalObject"

value="dataSet.Relations[FK_FactEdu_DimUniversity]" vartype="8" />

               <property name="Virtual" value="0" vartype="11" />

               <property name="VisibleAP" value="0" vartype="3" />

             </ddsxmlobj>

           </layoutobject>

           <connector  lineroutestyle="MSDDS.Rectilinear"  sourceid="4"  destid="1"

sourceattachpoint="5"  destattachpoint="6"  segmenteditmode="0"

bendpointeditmode="0" bendpointvisibility="0" relatedid="0" virtual="0">

             <point x="2110" y="3149" />

             <point x="2110" y="5549" />

           </connector>

         </ddscontrol>
94

 

         <ddscontrol  controlprogid="MSDDS.Polyline"  left="1710"  top="9668"

logicalid="14"  controlid="7"  masterid="0"  hint1="0"  hint2="0"  width="799"

height="3200"  noresize="0"  nomove="0"  nodefaultattachpoints="1"  autodrag="0"

usedefaultiddshape="0" selectable="1" showselectionhandles="0" allownudging="1"

isannotation="0"  dontautolayout="0"  groupcollapsed="0"  tabstop="1"  visible="1"

snaptogrid="0">

           <control>

             <ddsxmlobj>

               <polyline  endtypedst="6"  endtypesrc="files/2/3"  usercolor="0"  linestyle="0"

linerender="1"  customendtypedstid="0"  customendtypesrcid="0"  adornsvisible="1"

/>

             </ddsxmlobj>

           </control>

           <layoutobject>

             <ddsxmlobj>

               <property  name="LogicalObject"

value="dataSet.Relations[FK_FactEdu_DimTime]" vartype="8" />

               <property name="Virtual" value="0" vartype="11" />

               <property name="VisibleAP" value="0" vartype="3" />

             </ddsxmlobj>

           </layoutobject>

           <connector  lineroutestyle="MSDDS.Rectilinear"  sourceid="2"  destid="1"

sourceattachpoint="4"  destattachpoint="7"  segmenteditmode="0"

bendpointeditmode="0" bendpointvisibility="0" relatedid="0" virtual="0">

             <point x="2109" y="12368" />

             <point x="2109" y="11168" />

             <point x="2110" y="11168" />

             <point x="2110" y="9968" />

           </connector>
95

 

         </ddscontrol>

       </dds>

     </Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:ShowFriendlyN

ames</Name>

     <Value>true</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:ShowRelationsh

ipNames</Name>

     <Value>false</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:UseDiagramDef

aultLayout</Name>

     <Value>true</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramViewP

ortLeft</Name>

     <Value>-2581</Value>

   </Annotation>

   <Annotation>
96

 

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramViewP

ortTop</Name>

     <Value>4282</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramBoundi

ngLeft</Name>

     <Value>20</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramBoundi

ngTop</Name>

     <Value>0</Value>

   </Annotation>

   <Annotation>

     

<Name>http://schemas.microsoft.com/DataWarehouse/Designer/1.0:DiagramZoom<

/Name>

     <Value>84</Value>

   </Annotation>

 </Annotations>

 <LastProcessed>0001-01-01T00:00:00Z</LastProcessed>

 <State>Unprocessed</State>

 <Dimensions>

   <Dimension dwd:design-time-name="8b810038-5a61-40df-8a65-069f70bd651b">

     <ID>Dim Products</ID>
97

 

     <Name>Dim Products</Name>

     <DimensionID>Dim Products</DimensionID>

     <Attributes>

       <Attribute dwd:design-time-name="71bd2850-b461-41cb-a481-f3ab51ffbfe7">

         <AttributeID>Product Key</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="822798c7-1374-43dd-9eb1-a4fe810a408c">

         <AttributeID>Product Type</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="b0a169e0-210c-48b3-bf87-1f217995b7c9">

         <AttributeID>Product Brend</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="d2f3a6d6-9577-4d5e-95b5-896ecee916a3">

         <AttributeID>Product Name</AttributeID>

       </Attribute>

     </Attributes>

   </Dimension>

   <Dimension dwd:design-time-name="aa0c9cc2-f0cf-4468-a02b-edafaa0d33b0">

     <ID>Dim University</ID>

     <Name>Dim University</Name>

     <DimensionID>Dim University</DimensionID>

     <Attributes>

       <Attribute dwd:design-time-name="fd3aaf75-8b83-4540-a462-176622fbe77c">

         <AttributeID>University Key</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="c3273971-2c93-4a42-b21f-2c34112cc0b8">

         <AttributeID>Name</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="58378a8a-0df0-4030-b0f9-05d8f40c67a2">
98

 

         <AttributeID>Region</AttributeID>

       </Attribute>

     </Attributes>

     <Hierarchies>

       <Hierarchy  dwd:design-time-name="54ebe3a3-6957-42be-aac5-

a21ed0ebb07f">

         <HierarchyID>Hierarchy</HierarchyID>

       </Hierarchy>

     </Hierarchies>

   </Dimension>

   <Dimension dwd:design-time-name="0e1532b7-eb8f-4adc-8fe5-ace5e0a752d9">

     <ID>Dim Time</ID>

     <Name>Dim Time</Name>

     <DimensionID>Dim Time</DimensionID>

     <Attributes>

       <Attribute  dwd:design-time-name="73b8e7d9-5f40-418c-870d-

9c49bc23db1b">

         <AttributeID>Time Key</AttributeID>

       </Attribute>

       <Attribute  dwd:design-time-name="bdce1e21-9dd6-450c-ba04-

490d4092d78a">

         <AttributeID>Calendar Year</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="ac2aaa36-f4a6-45ef-8e33-c5da14cfb9f3">

         <AttributeID>Calendar Semester</AttributeID>

       </Attribute>

       <Attribute dwd:design-time-name="4af75cf4-227d-457f-818b-0fb2cbd8ffb1">

         <AttributeID>Calendar Quarter</AttributeID>

       </Attribute>
99

 

       <Attribute dwd:design-time-name="a68be3ba-df27-4735-a2b7-c04c2fd591bb">

         <AttributeID>Kvatral Nomi</AttributeID>

       </Attribute>

     </Attributes>

   </Dimension>

 </Dimensions>

 <MeasureGroups>

   <MeasureGroup  dwd:design-time-name="95884d89-ccc3-4998-9488-

bba333ec0f15">

     <ID>Fact Edu</ID>

     <Name>Fact Edu</Name>

     <CreatedTimestamp>0001-01-01T00:00:00Z</CreatedTimestamp>

     <LastSchemaUpdate>0001-01-01T00:00:00Z</LastSchemaUpdate>

     <LastProcessed>0001-01-01T00:00:00Z</LastProcessed>

     <State>Unprocessed</State>

     <Measures>

       <Measure dwd:design-time-name="f853c3dc-5906-4e60-8493-887c10629e58">

         <ID>Products Count</ID>

         <Name>Element miqdori</Name>

         <Source dwd:design-time-name="77860164-6495-4a0b-a544-0041a1a2f52b">

           <DataType>Integer</DataType>

           <Source  xsi:type="ColumnBinding"  dwd:design-time-name="484de6c7-

dbac-4bb6-979c-306dd976e1f7">

             <TableID>dbo_FactEdu</TableID>

             <ColumnID>ProductsCount</ColumnID>

           </Source>

         </Source>

         <FormatString>#,#</FormatString>

       </Measure>
100

 

       <Measure dwd:design-time-name="c6d6126c-a914-49ee-a54f-b740b5b521e1">

         <ID>Products Count In Edu</ID>

         <Name>Faqat uquv jarayonida foydalaniladigan elementlar soni</Name>

         <Source dwd:design-time-name="d60babab-58ca-49e3-8c54-1664b499ee35">

           <DataType>Integer</DataType>

           <Source  xsi:type="ColumnBinding"  dwd:design-time-name="407746e7-

86b4-4cd7-8b98-5558a211d437">

             <TableID>dbo_FactEdu</TableID>

             <ColumnID>ProductsCountInEdu</ColumnID>

           </Source>

         </Source>

       </Measure>

       <Measure dwd:design-time-name="b5fd6c7d-e193-4fff-b8b5-f33de8d10fff">

         <ID>Products Count Work Pro</ID>

         <Name>Yaroqli elementlar soni</Name>

         <Source dwd:design-time-name="19b7571c-3543-46af-b25c-b2c9a6c06916">

           <DataType>Integer</DataType>

           <Source  xsi:type="ColumnBinding"  dwd:design-time-name="3d236088-

39e5-4cdf-9ea7-a37af17fabb0">

             <TableID>dbo_FactEdu</TableID>

             <ColumnID>ProductsCountWorkPro</ColumnID>

           </Source>

         </Source>

       </Measure>

       <Measure dwd:design-time-name="b47383d2-56f5-4331-b3f7-6819c2966801">

         <ID>Students Count</ID>

         <Name>Talabalar soni</Name>

         <Source dwd:design-time-name="416c3641-789b-43ea-a928-97bb822babc0">

           <DataType>Integer</DataType>
101

 

           <Source  xsi:type="ColumnBinding"  dwd:design-time-name="09e3a583-

ad56-4ff0-b20d-1b9d28f5fb07">

             <TableID>dbo_FactEdu</TableID>

             <ColumnID>StudentsCount</ColumnID>

           </Source>

         </Source>

       </Measure>

     </Measures>

     <StorageMode>Molap</StorageMode>

     <ProcessingMode>Regular</ProcessingMode>

     <Dimensions>

       <Dimension  xsi:type="RegularMeasureGroupDimension"  dwd:design-time-

name="b1da72de-787f-4cb8-b243-feebd25c9b1c">

         <CubeDimensionID>Dim University</CubeDimensionID>

         <Attributes>

           <Attribute  dwd:design-time-name="817a26ff-ecfd-49ee-80c3-

f0c24819b1d5">

             <AttributeID>University Key</AttributeID>

             <KeyColumns>

               <KeyColumn  dwd:design-time-name="17d10c47-aea9-4929-b57f-

456761e07977">

                 <DataType>Integer</DataType>

                 <Source  xsi:type="ColumnBinding"  dwd:design-time-name="ee4aa3f4-

bd2e-465f-8710-2737faa69240">

                   <TableID>dbo_FactEdu</TableID>

                   <ColumnID>UniversityID</ColumnID>

                 </Source>

               </KeyColumn>

             </KeyColumns>
102

 

             <Type>Granularity</Type>

           </Attribute>

         </Attributes>

       </Dimension>

       <Dimension  xsi:type="RegularMeasureGroupDimension"  dwd:design-time-

name="8ac79551-5301-4c34-8801-c6a98af359bf">

         <CubeDimensionID>Dim Time</CubeDimensionID>

         <Attributes>

           <Attribute  dwd:design-time-name="1ca42325-ab94-471f-a213-

62af8dfc132d">

             <AttributeID>Time Key</AttributeID>

             <KeyColumns>

               <KeyColumn  dwd:design-time-name="335f0535-7bf9-41b2-a767-

7feaa981b71a">

                 <DataType>Integer</DataType>

                 <Source  xsi:type="ColumnBinding"  dwd:design-time-name="1772e366-

a9f3-4fbf-8768-9079fb52933f">

                   <TableID>dbo_FactEdu</TableID>

                   <ColumnID>TimeID</ColumnID>

                 </Source>

               </KeyColumn>

             </KeyColumns>

             <Type>Granularity</Type>

           </Attribute>

         </Attributes>

       </Dimension>

       <Dimension  xsi:type="RegularMeasureGroupDimension"  dwd:design-time-

name="1971dc95-ea78-4280-b2c6-6f56463fa71b">

         <CubeDimensionID>Dim Products</CubeDimensionID>
103

 

         <Attributes>

           <Attribute  dwd:design-time-name="71d720b1-558e-4bb4-aa6c-

f4ab30df2eb9">

             <AttributeID>Product Key</AttributeID>

             <KeyColumns>

               <KeyColumn  dwd:design-time-name="11267c78-9d98-4262-bc7b-

65b3457eb98f">

                 <DataType>Integer</DataType>

                 <Source  xsi:type="ColumnBinding"  dwd:design-time-name="926c55ac-

4ddd-4c63-a6b6-cf04fad1597d">

                   <TableID>dbo_FactEdu</TableID>

                   <ColumnID>ProductID</ColumnID>

                 </Source>

               </KeyColumn>

             </KeyColumns>

             <Type>Granularity</Type>

           </Attribute>

         </Attributes>

       </Dimension>

     </Dimensions>

     <Partitions />

   </MeasureGroup>

 </MeasureGroups>

 <Source dwd:design-time-name="dc17e364-4520-49c5-938e-c6bb4b4d9594">

   <DataSourceViewID>Education DW</DataSourceViewID>

 </Source>

 <MdxScripts>

   <MdxScript dwd:design-time-name="c59515de-2e00-422e-b92e-2d269905216c">

     <ID>MdxScript</ID>
104

 

     <Name>MdxScript</Name>

     <CreatedTimestamp>0001-01-01T00:00:00Z</CreatedTimestamp>

     <LastSchemaUpdate>0001-01-01T00:00:00Z</LastSchemaUpdate>

     <Commands>

       <Command>

         <Text>/*

The CALCULATE command controls the aggregation of leaf cells in the cube.

If  the  CALCULATE  command  is  deleted  or  modified, the data  within  the  cube  is

affected.

You  should  edit  this  command  only  if  you  manually  specify  how  the  cube  is

aggregated.

*/

CALCULATE;  

CREATE  MEMBER  CURRENTCUBE.[Measures].[Moddiy  texnik  bazaning

talabalar soniga nisbati (protsent kursatkichida)]

AS [Measures].[Element miqdori]/[Measures].[Talabalar soni],  

FORMAT_STRING = "Percent",  

NON_EMPTY_BEHAVIOR = { [Element miqdori], [Talabalar soni] },  

VISIBLE = 1 ,  ASSOCIATED_MEASURE_GROUP = 'Fact Edu'  ; </Text>

       </Command>

     </Commands>

   </MdxScript>

 </MdxScripts>

 <Kpis>

   <Kpi dwd:design-time-name="78b00242-6c2d-4394-89e4-fda61dc21a36">

     <ID>KPI</ID>

     <Name>Kompyuter bilan taminlanganlik darajasi</Name>

     <AssociatedMeasureGroupID>Fact Edu</AssociatedMeasureGroupID>

     <Value>[Measures].[Element miqdori]</Value>
105

 

     <Goal>[Measures].[Talabalar soni]/8</Goal>

     <Status>Case

When  

 KpiValue("Kompyuter  bilan  taminlanganlik  darajasi")/KpiGoal("Kompyuter  bilan

taminlanganlik darajasi")&gt;=.95

  Then 1

When

 KpiValue("Kompyuter  bilan  taminlanganlik  darajasi")/KpiGoal("Kompyuter  bilan

taminlanganlik darajasi")&lt;.95

  And  

 KpiValue("Kompyuter  bilan  taminlanganlik  darajasi")/KpiGoal("Kompyuter  bilan

taminlanganlik darajasi")&gt;=.85

  Then 0

 Else-1

End

</Status>

     <TrendGraphic>Standard Arrow</TrendGraphic>

     <StatusGraphic>Gauge - Ascending</StatusGraphic>

   </Kpi>

 </Kpis>

</Cube>



 

Другие похожие работы, которые могут вас заинтересовать.
5149. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ В СИТУАЦИОННЫХ ЦЕНТРАХ 198.93 KB
  Метод группового принятия решения с помощью кластеризации экспертных оценок альтернатив. Метод группового принятия решения на основе метода предпочтения. Метод группового принятия решения на основе балльного метода.
16374. тематические модели для поддержки принятия оптимальных управленческих решений в социально- экономических с 42.8 KB
  Чебоксары Математические модели для поддержки принятия оптимальных управленческих решений в социально- экономических системах Введение В социально- экономической сфере большое значение имеет построение математических моделей с помощью которых можно адекватно описать многообразие процессов протекающих в них. Модель отражает гипотезу об основных факторах развития социальной системы выраженных в частности в показателях удовлетворенности социальными потребностями. Важность таких моделей заключается в возможности прогнозирования на их основе...
11970. Информационная технология поддержки принятия решений по предупреждению и ликвидации последствий техногенных аварий на объектах нефтепереработки 17.38 KB
  Краткое описание разработки. Преимущества разработки и сравнение с аналогами. Основным преимуществом разработки в сравнении с аналогами является реализация специализированных процедур оперативного синтеза сценариев аварий для типовых объектов с возможностью последующей детальной настройки на конкретный объект. Области коммерческого использования разработки.
11683. ТАБЛИЦЫ ПРИНЯТИЯ РЕШЕНИЙ В СУБД С ТАБЛИЧНОЙ МОДЕЛЬЮ ДАННЫХ 1.22 MB
  Создать базу данных для инструментального средства, предназначенного для работы с таблицами принятия решений, встроенными в СУБД Oracle, создать пакет процедур и функций, реализующий процессы, обеспечивающие создание, редактирование и работу с таблицами принятия решений, доработать интерфейсы, разработанные в курсовой работе Дербеневой Е. «Адаптивный интерфейс для работы с таблицами принятия решений», выполнить экспериментальную проверку инструментального средства.
12205. Разработка методики принятия педагогических решений на основе агрегирования нечетких суждений экспертов 48.73 KB
  Весьма важном направлением приложения принципов ТНМ в смысле проектирования и принятия эффективных педагогических решений представляется образовательный процесс в учебных заведениях, что характеризуется доминированием информации субъективного, лингвистического характера, что в целом объясняется отношением педагогических систем к категории гуманистических.
1828. Критерий принятия решений 116.95 KB
  Критерий принятия решений – это функция, выражающая предпочтения лица, принимающего решения (ЛПР), и определяющая правило, по которому выбирается приемлемый или оптимальный вариант решения.
10997. Психологические аспекты принятия решений 93.55 KB
  МЕТОДИЧЕСКАЯ РАЗРАБОТКА для проведения лекции № 9 по дисциплине УПРАВЛЕНЧЕСКИЕ РЕШЕНИЯ Тема 9: Психологические аспекты принятия решений Для студентов специальности: 080507 Менеджмент организации Одобрена на заседании Методического совета института...
10964. Анализ задач и методов принятия решений (ПР) 46.89 KB
  Для других людей мотивы принятия решения могут быть и вовсе неясными. Поэтому с целью придания ясности следует найти численную меру для определения того насколько каждое из решений является подходящим. Руководителю фирмы требуется решить какую программу для управления предприятием следует приобрести. Главная цель – выбор наилучшей программы для управления предприятием.
7980. Процесс принятия и реализации управленческих решений 24.35 KB
  При возникновении и определении проблемы необходимо ответить на следующие вопросы: В чем суть проблемы Где возникла проблема объект проблемы бригада оборудование коллектив С кем связана проблема субъект проблемы социальный или интеллектуальный ее элемент С чем связана проблема связи проблемы Для чего необходимо решать проблему цель решения проблемы Понятие решение в научной литературе трактуется поразному. Основные компоненты управленческого решения: множество возможных вариантов; нормативный документ...
10567. Технология разработки и принятия управленческих решений 124.08 KB
  Методы моделирования и оптимизации решений Методы моделирования называемые также методами исследования операций базируются на использовании математических моделей для решения наиболее часто встречающихся управленческих задач. Количество конкретных всевозможных моделей почти также велико как и число проблем для решения которых они разработаны. Очевидно что возможность прогнозировать действия конкурентов существенное преимущество для любой коммерческой организации. Первоначально разработанные для военностратегических целей модели...
© "REFLEADER" http://refleader.ru/
Все права на сайт и размещенные работы
защищены законом об авторском праве.