Зміст

Вступ 3
1 Зародження концепції сховища даних 5
2 Технологія розробки та впровадження Сховища Даних 6
2.1 Етапи проекту 6
2.2 Вибір моделі даних Сховища 9
2.3 Вибір структури Сховища Даних 12
2.4 Вітрини Даних 14
2.5 Сховище метаданих (Сховище) 16
2.6 Завантаження Сховища 18
2.7 Аналіз даних: OLAP 20
3 Інтелектуальний аналіз даних 23
Висновок 26
Список літератури 27

ВСТУП

В тій чи іншій мірі Системи Підтримки Прийняття Рішень (СППР)присутні в будь-якій інформаційній системі (ІС). Тому, свідомо чині, до завдання створення системи підтримки прийняття рішень організаціїприступають відразу після придбання обчислювальної техніки й установкипрограмного забезпечення. У міру розвитку бізнесу, упорядкування структуриорганізації та налагодження міжкорпоративних зв'язків, проблема розробки івпровадження СППР стає особливо актуальною. Одним з підходів до створеннятаких систем стало використання сховищ даних. У цій статтірозглядаються етапи та методики проведення подібних робіт на досвіді і ззастосуванням методології компанії Price Waterhouse, яка на сьогоднівиконала 40 великомасштабних проектів зі створення корпоративних сховищ
Даних.

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

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

- звіти, як правило, базуються на стандартних для організації запитах; число останніх відносно невелике;

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

- як правило, ІСР орієнтовані на конкретний вертикальний ринок, наприклад фінанси, маркетинг, управління ресурсами.

СППР другого типу припускають досить глибоке пророблення даних,спеціально перетворених так, щоб їх було зручно використовувати в ходіпроцесу прийняття рішень. Невід'ємним компонентом СППР цього рівняє правила прийняття рішень, які на основі агрегованих данихпідказують менеджерського складу висновки і надають системі рисиштучного інтелекту. Такого роду системи створюються тільки в томувипадку, якщо структура бізнесу вже достатньо визначена і єпідстави для узагальнення і аналізу не тільки даних, але і процесів їхобробки. Якщо ІСР є не що інше як розвиток системи оперативногоуправління виробничими процесами, то СППР в сучасному розумінні --це механізм розвитку бізнесу, який включає в себе деяку частинукеруючої інформаційної системи, широку систему зовнішніх зв'язківпідприємства, а також технологічні та маркетингові процеси розвиткувиробництва.

1. Зародження концепції сховища даних

Ясно, що чим більше інформації залучено в процес прийняття рішень,тим більш обгрунтоване рішення може бути прийняте. Інформація, на основіякої приймається рішення, повинна бути достовірною, повною,несуперечливою і адекватною. Тому при проектуванні СППР виникаєпитання про те, на основі яких даних ці системи будуть працювати. У ІСРякість оперативних рішень забезпечується тим, що дані вибираютьсябезпосередньо з інформаційної системи керування підприємством (або з
БД підприємства), яка адекватно відображає стан бізнесу на даниймомент часу. Ранні версії СППР другого типу в якості вихіднихвикористовували відносно невеликий обсяг агрегованих даних,піддаються перевірці на достовірність, повноту, несуперечність іадекватність.

У міру росту і розвитку ІСР, а також вдосконалення алгоритмівприйняття рішень на основі агрегованих даних, системи прийняття рішеньзіткнулися з проблемами, викликаними необхідністю забезпечити зростаючіпотреби бізнесу. У ІСР накопичився обсяг даних, що уповільнює процеспобудови звітів настільки, що менеджерський склад не встигав готуватина їх основі відповідні рішення. Крім того, з розвиткомміжкорпоративних зв'язків потрібно залучати до процесу аналізу дані ззовнішніх джерел, не пов'язаних безпосередньо з виробничими процесами ітому що не входять в систему управління підприємством.

У СППР другого типу традиційна технологія підготовки інтегрованоїінформації на основі запитів і звітів стала неефективною через різкезбільшення кількості та різноманітності вихідних даних. Це стало сильнозатримувати менеджмент, для якого потрібно було швидко приймати рішення.
Крім того, поступове накопичення в БД підприємства даних для прийняттярішень та подальший їх аналіз стали негативно позначатися наоперативній роботі з даними.

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

Цей підхід вимагає нових технологічних рішень, до створенняяких кілька років тому приступили основні виробники промислових
СУБД і розробники систем аналізу даних. Сьогодні накопичено великий досвідрозробки та впровадження спеціалізованих структур даних і створення СППРна основі СУБД різних типів. Відома і технологія створення великих
Сховищ, як правило, на основі реляційних СУБД.

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

2. Технологія розробки та впровадження Сховища Даних

2.1. Етапи проекту

Першою фазою проекту розробки ХД є бізнес-аналіз процесів іданих підприємства. У Росії, незважаючи на широке розповсюдження CASE -технології, до бізнес-аналізу і проектування даних на концептуальномурівні не завжди ставляться досить серйозно. Тим часом щодо СППРна основі ХД можна з упевненістю стверджувати, що її розробка безподібного аналізу заздалегідь приречена на невдачу. Без ясного розуміннярозробниками цілей бізнесу, способів їх досягнення, що виникають при цьомупроблем і методів їх вирішення, ресурси, необхідні для розробки ХД, будутьвитрачені дарма. Найбільш критичним з ресурсів зараз є час, і той,хто почав розробку СППР, не визначивши заздалегідь, хто, коли, навіщо і якбуде приймати рішення, який вплив те чи інше рішення надає набізнес, які рішення віднести до оперативних, а які до стратегічних і т.д., прирікає себе на неминуче відставання в конкурентній боротьбі.

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

- дозволяє гнучко модифікувати бізнес-процеси, ставлячи їх в залежність від бізнес-подій;

- інтегрує дані, які при аналізі бізнес-процесів залишаються прихованими в алгоритмах обробки даних;

- об'єднує керуючі та інформаційні потоки;

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

Іншими словами, бізнес-подія є більш стійким і більш тіснопов'язаних з інформаційними і керуючими потоками поняттям, ніж бізнес -процес.

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

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

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

Отже, за результатами аналізу бізнес-процесів і структур данихпідприємства відбирається справді значима для бізнесу інформація зурахуванням невизначеності майбутніх запитів. Наступний крок пов'язаний з розуміннямтого, в якому вигляді і на яких апаратних і програмних платформах розміщуватиструктуру даних СППР на основі ХД.

2.2. Вибір моделі даних Сховища

У найпростішому варіанті для сховищ даних використовується та модельданих, яка лежить в основі транзакційний системи. Якщо, як це частобуває, транзакційних система функціонує на реляційної СУБД (Oracle,
Informix, Sybase і т. п.), найскладнішим завданням стає виконаннязапитів ad-hoc, оскільки неможливо заздалегідь оптимізувати структуру БДтак, щоб всі запити працювали ефективно.

Однак практика прийняття рішень показала, що існує залежністьміж частотою запитів і ступенем агрегування даних, з якимизапити оперують, а саме чим більш агрегованими є дані, тимчастіше запит виконується. Іншими словами, коло користувачів, що працюють зузагальненими даними, ширше, ніж той, для якого потрібні детальні дані.
Це спостереження лягло в основу підходу до пошуку та вибірці даних,званого оперативної аналітичної обробки (On-line Analytical
Processing, OLAP).

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

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

- мова маніпулювання даними заснований на використанні бізнес-понять.

В основі OLAP лежить поняття гіперкуба, або багатомірного куба даних, уосередках якого зберігаються аналізовані (числові) дані, наприклад обсягипродажів. Вимірювання представляють собою сукупності значень інших даних,скажімо назв товарів і назв місяців року. У простому випадкудвовимірного куба (квадрата) ми отримуємо таблицю, що показує значеннярівнів продажу по товарах і місяцях. Подальше ускладнення моделі данихможе відбуватися за кількома напрямками:

- збільшення числа вимірювань - дані про продажі не тільки по місяцях і товарами, але і по регіонах. У цьому випадку куб стає тривимірним;

- ускладнення вмісту комірки - наприклад нас може цікавити не тільки рівень продажів, але й, скажімо, чистий прибуток або залишок на складі. У цьому випадку в комірці буде кілька значень;

- введення ієрархії в межах одного виміру - загальне поняття «Час» природно пов'язаний з ієрархією значень: рік складається з кварталів, квартал з місяців і т. д.

Мова поки що йде не про фізичну структурі зберігання, а лише про логічноїмоделі даних. Іншими словами, визначається лише для користувачаінтерфейс моделі даних. У рамках цього інтерфейсу вводяться наступнібазові операції:

- поворот;

- проекція. При проекції значення в осередках, що лежать на осі проекції, підсумовуються по деякому визначеної законом;

- розкриття (drill-down). Одне з значень виміру замінюється сукупністю значень із наступного рівня ієрархії виміру; відповідно замінюються значення в осередках гіперкуба;

- згортка (roll-up/drill-up). Операція, зворотній оприлюдненню;

- перетин (slice-and-dice).

Залежно від відповіді на запитання, чи існує Гіперкуб як окремафізична структура або лише як віртуальна модель даних, розрізняютьсистеми MOLAP (Multidimensional OLAP) і ROLAP (Relational OLAP). У першуГіперкуб реалізується як окрема база даних спеціальної нереляціоннойструктури, що забезпечує максимально ефективний за швидкістю доступ доданими, але потребує додаткового ресурсу пам'яті. MOLAP-системи вельмичутливі до обсягів збережених даних. Тому дані зі сховищаспочатку поміщаються в спеціальну багатовимірну базу (Multidimensional Data
Base, MDB), а потім ефективно обробляються OLAP-сервером.

Одним з перших виробників таких систем стала компанія Arbor
Software, що випустила продукт Essbase. Компанія Oracle пропонує систему
Oracle Express, інтегровану з універсальним Oracle Server. Відомі йінші виробники MOLAP-систем, наприклад SAS Institute. Однак, ввідміну від Essbase, їх продукти часто інтегровані в додатки, створенідля конкретних вертикальних або горизонтальних ринків, і поставляються лишеу складі цих додатків.

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

Деякі постачальники програмних продуктів (Sybase - Sybase IQ,
Teradata) постачають більш складні рішення, засновані на спеціальнихметодах зберігання та індексації даних і зв'язків між даними.

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

2.3. Вибір структури Сховища Даних

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

Незважаючи на те що передбачити, яку саме інформацію і в якому виглядізахоче отримати користувач, працюючи з СППР, практично неможливо,вимірювання, за якими проводиться аналіз, досить стабільні. У процесіпідготовки того чи іншого рішення користувач аналізує зріз фактів поодного або кількох вимірах. Аналіз інформації, виходячи з понятьвимірів і фактів, іноді називають багатовимірним моделюванням даних
(MultiDimensional Modelling, MDM). Таблиці фактів зазвичай містять великіобсяги даних, тоді як таблиці вимірів намагаються зробити поменше.
Цього підходу бажано дотримуватися тому, що запит по вибірці зоб'єднання таблиць виконується швидше, коли одна велика таблицяоб'єднується з кількома малими. При практичній реалізації ХД невеликітаблиці вимірів іноді вдається цілком розмістити в оперативній пам'яті,що різко підвищує ефективність виконання запитів.

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

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

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

2.4. Вітрини Даних

Ідея Вітрини Даних (Data Mart) виникла кілька років тому, колистало очевидно, що розробка корпоративного сховища - довгий ідорогий процес. Це обумовлено як організаційними, так ітехнічними причинами:

- інформаційна структура реальної компанії, як правило, дуже складна, і керівництво часто погано розуміє суть що відбуваються в компанії бізнес-процесів;

- технологія прийняття рішень орієнтована на існуючі технічні можливості і не піддається змінам;

- може виникнути необхідність у частковому зміну організаційної структури компанії;

- потрібні значні інвестиції до того, як проект почне окупатися;

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

- освоєння нових технологій і програмних продуктів фахівцями компанії може вимагати багато часу;

- на етапі розробки буває важко налагодити взаємодію між розробниками і майбутніми користувачами Сховища.

У сукупності це приводить до того, що розробка і впровадженнякорпоративного сховища вимагають значних зусиль з аналізудіяльності компанії та переорієнтації її на нові технології. Вітрини
Даних виникли в результаті спроб пом'якшити труднощі розробки тавпровадження сховищ.

Зараз під вітрин даних розуміється спеціалізоване Сховище,обслуговує один з напрямків діяльності компанії, наприклад облікзапасів або маркетинг. Важливо, що відбуваються тут бізнес-процеси, по -перше, щодо вивчені і, по-друге, не настільки складні, як процеси вмасштабах всієї компанії. Кількість працівників, залучених в конкретнудіяльність, також невелика (рекомендується, щоб Вітрина обслуговував небільше 10-15 чоловік). При цих умовах вдається з використаннямсучасних технологій розгорнути Вітрину підрозділу за 3-4 місяці.
Необхідно відзначити, що успіх невеликого проекту (вартість якогоневелика в порівнянні з вартістю розробки корпоративного Сховища),по-перше, сприяє просуванню нової технології і, по-друге, призводитьдо швидкої окупності витрат.

Перші ж спроби впровадження вітрин даних виявилися настількиуспішними, що навколо нової технології розпочався справжній бум. Пропонувалосявзагалі відмовитися від реалізації корпоративного Сховища і замінити йогосукупністю вітрин даних. Однак незабаром з'ясувалося, що зі зростанням числа
Вітрин зростає складність їх взаємодії, оскільки зробити вітриниповністю незалежними не вдається. Зараз прийнята точка зору, ввідповідно до якої розробка корпоративного Сховища повинна йтипаралельно з розробкою і впровадженням вітрин даних.

Фактичним стандартом структури даних при розробці Вітрини є
"зірка", заснована на єдиній таблиці фактів. При побудові схемивзаємодії корпоративного Сховища і вітрин даних в межах створення
СППР рекомендується визначити деяку спеціальну структуру для зберіганняісторичних даних і додатково розгорнути ряд вітрин, які заповнюютьсяданими з цієї структури. Тим самим вдається розділити два процеси:накопичення історичних даних та їх аналіз.

2.5. Сховище метаданих (Сховище)

Принципова відмінність Системи підтримки прийняття рішень на основі
Сховищ даних від інтегрованої системи управління підприємством складаєтьсяв обов'язкову наявність у СППР метаданих. У загальному випадку метаданіпоміщаються в централізовано керований Сховище, в який включаєтьсяінформація про структуру даних Сховища, структурах даних, що імпортуютьсяз різних джерел, про самих джерелах, методи завантаження іагрегування даних, відомості про засоби доступу, а також бізнес-правилахоцінки та представлення інформації. Там же міститься інформація про структурубізнес-понять. Так, наприклад, клієнти можуть підрозділятися накредитоспроможних і некредитоспроможних, на що мають або не мають пільги,вони можуть бути згруповані за віковою ознакою, за місцями проживанняі т. п. Як наслідок, з'являються нові бізнес-поняття: Постійний клієнт,
Перспективний клієнт і т. п. Деякі бізнес-поняття (відповіднівимірюваннями в Сховище Даних) утворюють ієрархії, наприклад Товар можевключати продукти харчування і лікарські препарати, які, у своючергу, поділяються на групи продуктів і ліків і т. д.

Широко відомі Репозитарії, що входять до складу популярних CASE-засобів
(Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA
Research)), систем розробки додатків (Developer 2000 (Oracle), Power
Builder (Sybase)), адміністрування та підтримки інформаційних систем
(Platinum, MSP). Усі вони, однак, вирішують приватні задачі, працюючи зобмеженим набором метаданих, і призначені, в основному, дляполегшення праці професіоналів - проектувальників, розробників іадміністраторів інформаційних систем. Сховище метаданих СППР наоснові ХД призначений не тільки для професіоналів, а й длякористувачів, яким він служить як підтримка при формуваннібізнес-запитів. Більш того, розвинена система управління метаданими повинназабезпечувати можливість управління бізнес-поняттями з бокукористувачів, які можуть змінювати зміст метаданих і утворюватинові поняття у міру розвитку бізнесу. Тим самим репозитарій перетворюєтьсяз факультативного інструменту в обов'язковий компонент СППР і ХД.

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

- аналіз процесів виникнення, зміни та використання метаданих;

- проектування структури зберігання метаданих (наприклад, у складі реляційної бази даних);

-- організація прав доступу до метаданих;

- блокування і вирішення конфліктів при спільному використанні метаданих (що дуже часто виникає при зміні спільних бізнес-понять в рамках структурного підрозділу);

- поділ між метаданих вітрин даних;

- узгодження метаданих ХД з Репозиторія CASE-засобів, що застосовуються при проектуванні та розробці сховищ;

- реалізації призначеного для користувача інтерфейсу з Сховище.

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

Оскільки більшість CASE-засобів використовує різні форматиметаданих, постачальники систем управління метаданими виробили стандартобміну MDIS, що забезпечує можливість інтеграції CASE-засобів у СППР наоснові ХД. На жаль, не всі пропоновані сьогодні на російському ринкупродукти відповідають цьому стандарту, тому перетворення форматівметаданих являє собою досить складний процес, який спроститипокликані спеціалізовані програмні продукти, в тому числі, наприклад,кошти фірми Evolutionary Technologies International або Prism Solutions
(Data Warehouse Directory).

Коли структура метаданих розроблена і система управління нимиспроектована, вирішується завдання заповнення та оновлення даних в ХД.

2.6. Завантаження Сховища

Які дані повинні бути поміщені в Сховище? Як знайти і отримати цідані? Як забезпечити коректність даних у Сховище? Подібні питанняє ключовими при проектуванні сховищ. По суті, визначаючи, ніжзаповнюється Сховище, ми неявно визначаємо спектр завдань, які будутьвирішуватися з його допомогою, і коло потенційних користувачів.

При описі технології заповнення Сховища будемо розрізняти тривзаємопов'язані завдання: Збір Даних (Data Acquisition), Очищення Даних
(Data Cleansing) і Агрегація Даних (Data Consolidation).

Під Збором Даних будемо розуміти процес, який полягає в організаціїпередачі даних із зовнішніх джерел у Сховище. Лише деякі аспектицього процесу повністю або частково автоматизовані у наявнихпродуктах. Перш за все, це відноситься до інтерфейсів з існуючими БД.
Як правило, тут є кілька можливостей. По-перше,підтримуються інтерфейси всіх великих виробників серверів баз даних
(Oracle, Informix, ADABAS і т. д.). По-друге, практично завжди є
ODBC-інтерфейс, і, по-третє, можна витягати дані з текстових файлів вформаті CSV (comma separated values) і з деяких структурованихфайлів, наприклад файлів dBase. Набір наявних інтерфейсів - найважливішахарактеристика, яка часто дозволяє оцінити, для яких завданьпроектувався продукт. Так, якщо серед підтримуваних інтерфейсів є
AS/400, DB2/400, IMS, VSAM (як у популярному продукті PASSPORT фірми
Carleton), то він призначений швидше для використання в системах,що працюють на великих мейнфреймах, ніж у мережі з ПК. Дещо інший набірінтерфейсів пропонує, наприклад, добре відомий продукт InfoPump фірми
PLATINUM Technology, що забезпечує підтримку Lotus Notes, Microsoft
Access, dBase і роботу з текстовими файлами. Великі виробники серверівабо мають власні кошти збору даних або встановлюють партнерськівідносини з виробниками таких засобів та розробляють інструментарійпроміжного рівня для тиражування "чужих" даних (такий, наприклад,
Replication Server фірми Sybase).

Другий аспект процесу збору даних, що автоматизований вдеяких продуктах, - це організація процесу поповнення Сховища. У томуж InfoPump, наприклад, є можливість будувати розклад поповнення
Сховища даними або на тимчасовій основі, або з використанням механізмуподій. Є й більш складні програмні комбінації, наприкладкорпорація Software AG розробила власне рішення для збору та очищенняданих, що називається, SourcePoint, що на нижньому рівні використовує
PASSPORT, а функції організації розкладів реалізує як надбудову надцим нижнім рівнем. Крім цього SourcePoint реалізує паралельнівилучення, передачу даних і заповнення Сховища.

Під очищенням даних звичайно розуміється процес модифікації данихходу заповнення Сховища: виключення небажаних дублікатів,відновлення пропущених даних, приведення даних до єдиного формату,видалення небажаних символів (наприклад, керуючих) і уніфікація типівданих, перевірка на цілісність. Практично всі продукти мають у своєму розпорядженні тимабо іншим набором засобів очищення даних і відповідними засобамидіагностики.

При заповненні Сховища агрегованими даними ми повинні забезпечитивибірку даних з транзакційний бази даних та інших джерел уВідповідно до метаданими, оскільки агрегування відбувається в термінахбізнес-понять. Так, наприклад, Агрегована величина "обсяг продажівпродукту Х в регіоні Y за останній квартал "містить поняття" продукт "і
"регіон", які є бізнес-поняттями даного підприємства. Слідпідкреслити, що завдання вибірки необхідних даних не може бути вирішенаповністю автоматично: можливі колізії (відсутність необхідних даних,помилки в даних і т. п.), коли втручання людини виявитьсянеобхідним. Далі, припускаючи, що об'єктом аналізу є числовіпоказники, пов'язані з бізнес-поняттями, такі як ОБСЯГ ПРОДАЖУ або
ПРИБУТОК, необхідно визначити правила обчислення цих показників дляскладових бізнес-понять, виходячи з їх значень для більш простих бізнес -понять. Це і є правила агрегування.

Найпростішим архітектурою системи на основі ХД є архітектураклієнт-сервер. Традиційно саме сховище розміщується на сервері (або насерверах), а аналіз даних виконується на клієнтах. Деяке ускладнення вцю схему вносять Вітрини Даних. Вони також розміщуються на серверах, але,з огляду на взаємодії між вітринами, доводиться вводити так званіперехідники (Hub Servers), через які йде обмін даними між
Вітринами.

2.7. Аналіз даних: OLAP

Припустимо тепер, що в загальному випадку є корпоративне ХД і ряд
Вітрин даних. Яким чином слід організувати доступ до інформації дляаналізу? Зараз прийнята точка зору, відповідно до якої потрібно забезпечитиможливість аналізу даних як з вітрин, так і безпосередньо з
Сховища. Різниця тут визначається не стільки розміром бази (Вітринаможе лише ненабагато поступатися сховища), скільки тим, що Вітрини, якправило, не містять детальних - неагрегірованних даних. Це означає, щоаналіз даних Вітрини не вимагає глибокої деталізації і часто може бутивиконано більш простимі засобами.

Поряд з потужними серверами багатовимірних баз даних і ROLAP-серверами наринку пропонуються клієнтські OLAP-сервери, предназаначенние, головнимчином, для роботи з невеликими обсягами даних і орієнтовані наіндивідуального користувача. Подібні системи були названі настільними,або DOLAP-серверами (Desktop OLAP). У цьому напрямку працюють фірми
Business Objects (Business Objects 5.0), Andyne (CubeCreator, PaBLO),
Cognos, Brio Technology.

Лідером поки вважається компанія Cognos, яка постачає продукти
PowerPlay, Impromptu і Scenario. PowerPlay - це настільний OLAP-сервер,для отримання даних з реляційних баз даних (Paradox, dBase, Clipper),
"плоских" файлів і електронних таблиць (Microsoft Excel) використовуєтьсягенератор запитів і звітів Impromptu. Потім спеціальний компонент,званий Transformer, поміщає витягнуті дані в клієнтськубагатовимірну базу, яка називається PowerCube. Споживачамнадаються широкі можливості з управління PowerCube: передавати їївід користувача до користувача за запитом і примусово, поміщати насервер для розділення доступу до неї або пересилати електронною поштою.
Cognos постаралася зробити свій продукт максимально відкритим: по-перше,
PowerCube може бути поміщений в реляційні бази Oracle, Informix, Sybase,
MS SQL Server на платформах UNIX, HP/UX, Sun Solaris, IBM AIX, по-друге,сам PowerPlay здатний аналізувати вміст не тільки PowerCube, а йінших багатовимірних баз даних.

Варто відзначити, що всі ці фірми об'єднує прагнення включити до своїхпродукти компоненти, призначені для Інтелектуального Аналізу Даних
(Data Mining, ІАД). Наприклад, зусилля Business Objects і Cognos спрямованіна підготовку остаточних версій компонентів Business Miner і Scenario,відповідно, призначених саме для ІАД.

Необхідно також згадати про новий напрямок розвитку архітектурсистем клієнт-сервер, званому трирівневої архітектурою клієнт-агент -сервер. Стосовно до СППР традиційна дворівнева архітектурамає на увазі, що Сховище Даних або Вітрина Даних розміщуються насервер, а аналітична обробка і призначені для користувача інтерфейсипідтримуються клієнтом. Можна навести деякі умови, за якихдворівнева архітектура працює ефективно:

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

- більша частина обчислень може бути виконана заздалегідь;

-- коло користувачів-клієнтів чітко визначений, так що сервер обслуговує помірне число запитів в одиницю часу;

- немає необхідності підтримувати розподіл даних між клієнтами

(клієнти ізольовані один від одного);

- програми не вимагають постійних модифікацій і вдосконалень.

Практика показує, що аналітична обробка, не дивлячись напідготовленість агрегованих даних у Сховище або вітрині, можевиявитися не таким простим завданням. Наприклад, якщо потрібнопроаналізувати відношення прибутку до витрат, можливо, це завданнядоведеться вирішувати динамічно, оскільки саме такого ставлення у Сховищеможе і не бути (при тому, що прибуток і витрати, швидше за все, тамприсутні). Виконання по