Создание систем підтримки прийняття решений

Содержание Введение 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 великомасштабних проектів із створенню корпоративних Сховищ Данных.

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

СППР першого типу дістали назву Інформаційних Систем Керівництва (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, відповідно, призначених саме з ИАД.

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

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

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

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

— не потрібно підтримувати поділ даних між клиентами.

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

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

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

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

Для даної архітектури в прикладі з її пошуком відносини прибыль/расходы обчислення цього моменту стосунки було б виконувати на сервері додатків. У ROLAP-системах сервер додатків виконує сполуки таблиць згідно з користувальницьким запитом. З іншого боку, сервер додатків може здійснювати динамічний агрегирование даних. У DOLAP-системах сервер додатків може зберігати клієнтські гиперкубы.

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

3. Інтелектуальний аналіз данных.

Інтелектуальний аналіз даних (ИАД) зазвичай визначають як засіб підтримки прийняття рішень, заснований на аналізі залежностей між даними. У межах такий загальної формулювання звичайний аналіз звітів, побудованих через базу даних, він може розглядатися як різновид ИАД. Для переходу до розгляду просунутіших технологій ИАД, подивимося, як і автоматизувати пошук залежностей між данными.

Існує дві підходу. У першому випадку користувач сам висуває гіпотези щодо залежностей між даними. Фактично традиційні технології аналізу розвивали саме такий підхід. Справді, гіпотеза сприяла побудові звіту, аналіз звіту до висування нової гіпотези і т. буд. Це справедливе й у разі, коли користувач застосовує такі розвинені кошти, як OLAP, оскільки процес пошуку як і повністю контролюється людиною. Багато системах ИАД у цьому автоматизовано перевірка достовірності гіпотез, що дозволяє оцінити ймовірність тих чи інших залежностей базі даних. Типовим прикладом може бути, такий висновок: можливість, зростання продажів продукту, А обумовлений зростанням продажів продукту У, становить 0,75.

Другий підхід грунтується, що залежності між даними шукаються автоматично. Кількість продуктів, виконують автоматичний пошук залежностей, говорить про дедалі вищому інтересі у виробників і споживачів до системам саме такої типу. Повідомляється про різке зростання прибутків клієнтів за рахунок правильно знайденою, заздалегідь невідомої залежності. Згадане приклад мережі британських універсамів, де ИАД застосовувався під час аналізу збитків від розкрадань товарів у торгових залах. Було виявлено, що найбільшим збитків наводять розкрадання дрібних «супутніх «товарів: ручок, батарейок тощо. п. Просте перенесення прилавків з тими товарами ближчі один до розрахунковим вузлам дозволив знизити збитки на 1000%.

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

Процеси ИАД поділяються втричі великі групи: пошук залежностей (discovery), прогнозування (predictive modelling) і аналіз аномалій (forensic analysis). Пошук залежностей полягає у перегляді бази даних із метою автоматичного виявлення залежностей. Проблема тут залежить від відборі справді важливі залежностей з величезної кількості що у БД. Прогнозування передбачає, що користувач може пред’явити системі запису із незаповненими крисами і запросити відсутні значення. Система сама аналізує вміст бази й робить правдоподібне пророцтво стосовно цих значень. Аналіз аномалій — це процес пошуку підозрілих даних, сильно отклоняющихся від стійких зависимостей.

У системах ИАД застосовується надзвичайно широкий, спектр математичних, логічних і статистичних методів: від аналізу дерев рішень (Business Objects) до нейронних мереж (NeoVista). Наразі важко казати про перспективності чи перевагу тих чи інших методів. Технологія ИАД нині у початку шляху, і практичного матеріалу якихось рекомендацій чи узагальнень явно недостаточно.

Слід також згадати про інтеграцію ИАД до інформаційної системи. Багато методи ИАД виникли із завдань експертного аналізу, тому вхідними для них традиційно слугують «плоскі «файли даних. При використанні ИАД в СППР найчастіше доводиться спочатку видобувати дані з Сховища, перетворювати в файли потрібних форматів і потім переходити власне до інтелектуального аналізу. Потім результати аналізу потрібно сформулювати в термінах бизнес-понятий. Важливий крок уперед зробила компанія Information Discovery, розробила системи OLAP Discovery System і OLAP Affinity System, призначені спеціально для інтелектуального аналізу багатомірних агрегированных данных.

Заключение

.

Створення СППР з урахуванням сховищ даних — складний, але доступний для огляду процес, вимагає знання бізнесу, програмно-технічного інструментарію і досвіду виконання великих проектів. Разом про те впровадження таких систем може дати переваги у бізнесі, що так відчутніше, ніж раніше організація почне створення СППР. За прогнозами консалтингової фірми Gartner Group, до 2010 року приблизно 90−95% компаній використовуватимуть сховища данных.

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

— закупівля і тестування різноманітних продуктів, застосовуваних під час створення СППР і Х-Д (на жаль, більшість їх погано сполучаються друг з одним, від чого складається хибне враження «неподъемности «проблемы);

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

1. Система підтримки прийняття рішень на людино-машинних системах управління. Трудов института проблем управління РАН їм. В. А. Трапезникова. Том УШ. М.: ИПУРАН, 2000 р. з. 46−59.

2. Арлазаров В. Л., Журавльов Ю.І., Ларичев О. И., Лохин В. М., Макаров І.М., Рахманкулов В. З., Фін В.К. Теорія та художні засоби створення інтелектуальних комп’ютерних систем // Інформаційні технологій і обчислювальні системи. -1998. -№ 1.

3. Валькман Ю. Р. Інтелектуальні технології дослідницького проектування. -Київ.: Port-Royal. -1998.

4. Комарцова Л. Г. Оптимізація обчислювальної системи їхньому імітаційної моделі. // Вісник МДТУ їм. Н. Э. Баумана. — сірий. «Приладобудування ». -1999. -№ 2. -С.48−60.

5. Литвак Б. Г. Експертні технології управління. М.: Річ, 2004 г.

6. Трахтенгеру Э. А. Комп’ютерна підтримка прийняття рішень. — М.: Наука, 1998.

7. Чекинов Г. П., Куляница О. Л., Бондаренко В. В. Застосування ситуаційного управління у інформаційної підтримці прийняття рішень при проектуванні організаційно-технічних систем // Інформаційні технології в проектуванні та виробництві, № 2, 2003.