ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 03.12.2020
Просмотров: 1221
Скачиваний: 2
90
усі дані, необхідні для ухвалення рішень, заздалегідь агреговані
на усіх відповідних рівнях і організовані так, щоб забезпечити
максимально швидкий доступ до них;
мова маніпулювання даними заснована на використанні бізнес-
понять.
У основі OLAP лежить поняття гіперкуба, або багатовимірного куба
даних, в ячейках якого зберігаються аналізовані (числові) дані, наприклад
обсяги продажів. Виміри є сукупності значень інших даних, скажемо назв
товарів і назв місяців року. У простому випадку двовимірного куба
(квадрата) ми отримуємо таблицю, що показує значення рівнів продажів по
товарах і місяцях. Подальше ускладнення моделі даних може йти за
декількома напрямами:
збільшення числа вимірів - дані про продажі не лише за
місяцями та товарами, але і за регіонами. В цьому випадку куб стає
тривимірним;
ускладнення вмісту ячейки - наприклад нас може цікавити не
лише рівень продажів, але і, скажімо, чистий прибуток або залишок на
складі. В цьому випадку в ячейки буде декілька значень;
введення ієрархії в межах одного виміру - загальне поняття
"Час" природним чином пов'язане з ієрархією значень: рік складається з
кварталів, квартал з місяців і т. д.
Поки йдеться не про фізичну структуру зберігання, а лише про
логічну модель даних. Іншими словами, визначається лише призначений
для користувача інтерфейс моделі даних. У рамках цього інтерфейсу
вводяться наступні базові операції:
поворот;
проекція. При проекції значення в ячейках, що лежать на осі
проекції, підсумовуються за деяким законом;
розкриття (drill-down). Одне зі значень виміру заміняється
сукупністю значень з наступного рівня ієрархії виміру; відповідно
замінюються значення в осередках гіперкуба;
згортка (roll-up/drill-up). Операція, зворотна розкриттю;
перетин (slice-and-dice).
У залежності від відповіді на питання, чи існує гіперкуб як окрема
фізична структура або лише як віртуальна модель даних, розрізняють
системи MOLAP (Multidimensional OLAP) і ROLAP (Relational OLAP). У
перших гіперкуб реалізується як окрема база даних спеціальної
нереляційної структури, що забезпечує максимально ефективний за
швидкістю доступ до даних, але потребуюча додаткового ресурсу пам'яті.
MOLAP-системи досить чуттєві до обсягів збережених даних. Тому дані зі
сховища
спочатку
містяться
в
спеціальну
багатомірну
базу
(Multidimensional Data Base, MDB), а потім ефективно обробляються
OLAP-сервером.
Для систем ROLAP гіперкуб - це лише користувальницький
інтерфейс, що емулюється на звичайній реляційній СУБД. У цій структурі
91
можна зберігати дуже великі обсяги даних, однак її недолік полягає в
низкій і неоднаковій ефективності OLAP - операцій. Досвід експлуатації
ROLAP-продуктів показав, що вони більше підходять на роль
інтелектуальних генераторів звітів, ніж дійсно оперативних засобів
аналізу. Вони застосовуються в таких областях, як роздрібна торгівля,
телекомунікації, фінанси, де кількість даних велика, а високої
ефективності запитів не потрібно. Прикладами промислових ROLAP-
систем служать MetaCube фірми Informix і Discoverer 3.0 фірми Oracle. На
практиці іноді реалізується комбінація цих підходів.
При визначенні програмно-технологічної архітектури Сховища варто
мати на увазі, що система ухвалення рішення, на які б візуальні засоби
представлення вона ні спиралася, повинна надати користувачеві
можливість деталізації інформації. Керівник підприємства, одержавши
інтегроване представлення даних і висновки, зроблені на його основі, може
зажадати більш детальні зведення, що уточнюють джерело даних або
причини висновків. З погляду проектувальника СППР, це означає, що
необхідно забезпечити взаємодію СППР не тільки зі Сховищем Даних, але
й у деяких випадках із транзакційною системою.
Вибір структури Сховища Даних
Кілька років назад для Сховищ Даних було запропоновано
використовувати схеми даних, що одержали назви "зірка" і "сніжинка".
Суть технології проектування цих схем полягає у виділенні з загального
обсягу інформації власне аналізованих даних (або фактів) і допоміжними
даних (вимірів). Необхідно, однак, усвідомлювати те, що це приводить до
дублювання даних у Сховище, зниженню гнучкості структури і
збільшенню часу завантаження. Усе це - плата за ефективний і зручний
доступ до даних, необхідний у СППР.
Незважаючи на те що передбачити, яку саме інформацію і у якому
вигляді захоче одержати користувач, працюючи з СППР, практично
неможливо, виміри, по яких проводиться аналіз, досить стабільні. У
процесі підготовки того або іншого рішення користувач аналізує зріз
фактів по одному або декількох вимірах. Аналіз інформації, виходячи з
понять вимірів і фактів, іноді називають багатомірним моделюванням
даних (MultiDimensional Modelling, MDM). Таблиці фактів звичайно
містять великі обсяги даних, тоді як таблиці вимірів роблять меншими.
Цього підходу бажано дотримуватися тому, що запит по вибірці з
об'єднання таблиць виконується швидше, коли одна велика таблиця
поєднується з декількома дрібними. При практичній реалізації СД невеликі
таблиці вимірів іноді вдається цілком розмістити в оперативній пам'яті, що
різко підвищує ефективність виконання запитів.
Оскільки в Сховищах Даних, поряд з детальними, повинні
зберігатися й агреговані дані, у випадку "сніжинки" або "зірки"
з'являються таблиці агрегованих фактів (агрегатів). Подібно звичайним
фактам, агрегати можуть мати виміри. Крім того, вони повинні бути
92
зв'язані з детальними фактами для забезпечення можливої деталізації. На
практиці Сховища часто містять у собі кілька таблиць фактів, зв'язаних
між собою вимірами, що розподіляються між декількома таблицями
фактів. Така схема має назву "розширена сніжинка", і саме вона, як
правило, зустрічається в Сховищах Даних.
Для досягнення найвищої продуктивності іноді використовують
підхід, при якому кожна "зірка" розташовується в окремій базі даних або
на окремому сервері. Хоча такий підхід призводить до збільшення розміру
дискового простору за рахунок дублювання розділених вимірів, він може
виявитися досить корисним при організації Вітрин Даних.
При проектуванні структури сховища часто виникає бажання
використовувати якнайбільше агрегатів і за рахунок цього підвищити
продуктивність системи. Неважко підрахувати, що для моделі "зірка" з 10
вимірами можна побудувати 10!=3.63 мільйона різних агрегованих
значень, розміщення яких у пам'яті при встановленні зв'язків з
відповідними вимірами призведе до різкого збільшення займаного
дискового простору й уповільненню доступа до даних. Інша крайність
полягає у використанні занадто малого числа агрегатів, а це може
призвести до необхідності виконувати агрегування динамічно, що помітно
знижує ефективність запитів. За деякими оцінками, при визначенні
оптимальної кількості агрегатів варто дотримуватися принципу 80:20 -
80% прискорення досягається за рахунок використання 20% кандидатів на
агрегати.
Вітрини Даних
Ідея Вітрини Даних (Data Mart) виникла кілька років тому, коли
стало очевидно, що розробка корпоративного сховища - довгий і дорогий
процес. Це обумовлено як організаційними, так і технічними причинами:
інформаційна структура реальної компанії, як правило, дуже
складна, і керівництво найчастіше погане розуміє суть бізнесів-процесів,
що відбуваються в компанії;
технологія прийняття рішень орієнтована на існуючі технічні
можливості і важко піддається змінам;
може виникнути необхідність у частковій зміні організаційної
структури компанії;
потрібні значні інвестиції до того, як проект почне окупатися;
як правило, потрібна значна модифікація існуючої технічної бази;
освоєння нових технологій і програмних продуктів фахівцями
компанії може вимагати багато часу;
на етапі розробки буває важко налагодити взаємодію між
розроблювачами і майбутніми користувачами Сховища.
У сукупності це призводить до того, що розробка і впровадження
корпоративного сховища вимагають значних зусиль з аналізу діяльності
компанії і переорієнтації її на нові технології. Вітрини Даних виникли в
результаті спроб зм'якшити труднощі розробки і впровадження Сховищ.
93
Зараз під Вітриною Даних розуміється спеціалізоване Сховище, що
обслуговує один з напрямків діяльності компанії, наприклад облік запасів
або маркетинг. Важливо, що бізнес-процеси, які тут відбуваються, по-
перше, відносно вивчені і, по-друге, не настільки складні, як процеси в
масштабах усієї компанії. Кількість співробітників, які беруть участь у
певній діяльності, також невелике (рекомендується, щоб Вітрина
обслуговувала не більш 10-15 чоловік). При цих умовах вдається з
використанням сучасних технологій розгорнути Вітрину підрозділу за 3-4
місяця. Необхідно відзначити, що успіх невеликого проекту (вартість якого
невелика в порівнянні з вартістю розробки корпоративного Сховища), по-
перше, сприяє просуванню нової технології і, по-друге, призводить до
швидкої окупності витрат.
Перші спроби впровадження Вітрин Даних виявилися настільки
успішними, що навколо нової технології почався дійсний бум.
Пропонувалося взагалі відмовитися від реалізації корпоративного
Сховища і замінити його сукупністю Вітрин Даних. Однак незабаром
з'ясувалося, що з ростом числа Вітрин зростає складність їхньої взаємодії,
оскільки зробити вітрини цілком незалежними не вдається. Зараз прийнята
точка зору, відповідно до якої розробка корпоративного Сховища повинна
йти паралельно з розробкою й впровадженням Вітрин Даних.
Фактичним стандартом структури даних при розробці Вітрини є
"зірка", заснована на єдиній таблиці фактів. При побудові схеми взаємодії
корпоративного Сховища і Вітрин Даних у межах створення СППР
рекомендується визначити деяку спеціальну структуру для збереження
історичних даних і додатково розгорнути ряд Вітрин, які заповнюються
даними з цієї структури. Тим самим вдається розділити два процеси:
нагромадження історичних даних і їх аналіз.
Сховище Метаданных (Репозитарій)
Принципова відмінність Системи Підтримки Прийняття Рішень на
основі Сховищ Даних від інтегрованої системи керування підприємством
полягає в обов'язковій наявності в СППР метаданих. У загальному випадку
метадані розміщуються в централізовано керований Репозитарій, у який
включається інформація про структуру даних Сховища, структуру даних,
імпортованих з різних джерел, про самі джерела, методи завантаження і
агрегування даних, інформація про засоби доступу, а також бізнес-
правилах оцінки і уявлення інформації. Там же утримується інформація
про структуру бізнес-понять.
Широко відомі Репозитарії, що входять до складу популярних CASE-
засобів (Power Designer (Sybase), Designer 2000 (Oracle), Silverrun (CSA
Research)), систем розробки додатків (Developer 2000 (Oracle), Power
Builder (Sybase)), адміністрування і підтримки інформаційних систем
(Platinum, MSP). Усі вони, однак, вирішують приватні задачі, працюючи з
обмеженим набором метаданих, і призначені, в основному, для
полегшення праці професіоналів - проектувальників, розроблювачів і
94
адміністраторів інформаційних систем. Репозитарій метаданих СППР на
основі СД призначений не тільки для професіоналів, але і для
користувачів, яким він служить як підтримка при формуванні бізнес-
запитів. Більш того, розвинена система керування метаданими повинна
забезпечувати
можливість
керування
бізнес-поняттями
з
боку
користувачів, що можуть змінювати зміст метаданих і утворювати нові
поняття по мірі розвитку бізнесу. Тим самим репозитарій перетворюється з
факультативного інструмента в обов'язковий компонент СППР і СД.
Розробка системи керування метаданнии подібна розробці
розподіленої транзакційної системи. При її створенні необхідно
вирішувати наступні задачі:
аналіз процесів виникнення, зміни і використання
метаданих;
проектування
структури
збереження
метаданих
(наприклад, у складі реляційної бази даних);
організація прав доступу до метаданих;
блокування і розв’язок конфліктів при спільному
використанні метаданих (що дуже часто виникає при зміні загальних
бізнесів-понять у рамках структурного підрозділу);
поділ метаданих між Вітринами Даних;
узгодження метаданих СД із Репозитаріями CASE-засобів,
застосованих при проектуванні і розробці Сховищ;
реалізації інтерфейсу користувача з Репозитарієм.
Досвід реалізації систем керування метаданими показує, що основні
труднощі полягає не в програмній реалізації, а у визначенні змісту
конкретних метаданих і методики роботи з ними, у практичному
впровадженні Репозиторія.
Оскільки більшість CASE-засобів використовує різні формати
метаданих, постачальники систем керування метаданими виробили
стандарт обміну MDIS, що забезпечує можливість інтеграції CASE-засобів
у СППР на основі СД. На жаль, не всі пропоновані на російському ринку
продукти відповідають цьому стандартові, тому перетворення форматів
метаданих являє собою досить складний процес, спростити який покликані
спеціалізовані програмні продукти, у тому числі, наприклад, засоби фірми
Evolutionary Technologies International або Prism Solutions (Data Warehouse
Directory).
Коли структура метаданих розроблена і система керування ними
спроектована, вирішується задача заповнення і відновлення даних у СД.
Завантаження Сховища
Які дані повинні бути поміщені в Сховищі? Як знайти і вилучити ці
дані? Як забезпечити коректність даних у Сховищі? Подібні питання є
ключовими при проектуванні Сховищ. По суті, визначаючи, чим
заповнюється Сховище, ми неявно визначаємо спектр задач, що будуть
вирішуватися з його допомогою, і коло потенційних користувачів.