лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

системи підтримки прийняття рішень

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

 

Розділ 10

Системи підтримки прийняття рішень на основі сховищ даних та OLAP-систем

10.1. Розвиток та застосування СППР на основі сховищ даних та OLAP-систем


10.1.1. Передумови та сутність СППР
на основі сховищ даних та OLAP-систем

Системи підтримки прийняття рішень на основі сховищ даних та OLAP-систем, як і самі сховища даних (Data Warehouses) та системи аналітичного онлайнового оброблення даних, належать до типу орієнтованих на дані СППР. У загальному вигляді орієнтовану на дані систему підтримки прийняття рішень (ОДСППР) можна визначити як інтерактивну комп’ю­теризовану систему, що допомагає ОПР використовувати дуже велику базу даних із внутрішніх даних компанії і деякі зовнішні дані з навколишнього середовища системи з метою прийняття обґрунтованих рішень. Наприклад, система може надавати дані щодо збуту продукції як самої компанії, так і її конкурентів. Деякі дані можуть бути деталізованими даними транзакцій, а деякі — агрегованими. У більшості реалізованих нині ОДСППР користувачі можуть виконувати незаплановані або в режимі на даний випадок (ad hoc) аналізи даних і формулювати запити. За допомогою таких систем менеджери обробляють дані для ідентифікації фактів і отримання висновків у вигляді графічних зображень (діаграм, графіків, трендів).
Орієнтовані на дані СППР, зокрема системи аналітичного онлайнового оброблення, інколи називають бізнес-інформаційними (Business intelligence).Цей популярний, широко відомий термін запропонував 1989 року аналітик Говард Дрезнер (Howard Dresner) з групи «Gartner», що консультує фірми «Fortune 1000» з питань інформаційних технологій, для описання низки понять і методів, призначених для вдосконалення бізнесових рішень за допомогою використання основаних на фактах систем підтримки прийняття рішень (власне замість терміна «програмне забезпечення» («decision support») був запропонований термін «Business intelligence»). Зокрема, 1994 року Говард Дрезнер писав: «До 1996 року використання розв’язків Business intelligence різко переміститься від спеціалізованих аналітиків до всіх менеджерів і професіоналів як найкращий шлях розуміння бізнесу… Замість вузького кола аналітиків, які витрачають 100 відсотків свого часу на аналізування даних, усі менеджери і професіонали витратять 10 відсотків свого часу для цього, використовуючи програмне забезпечення Business intelligence». Хоча ні 1996, ні навіть 2001 року повною мірою цей прогноз не справдився, проте багато менеджерів освоїли і продовжують вивчати цей тип програмних продуктів. Така обставина пояснюється тим, що програмне забезпечення орієнтованих на дані СППР надає змогу користувачам досягати як загальної для всієї корпорації мети, тобто підвищення рівня конкурентоспроможності за рахунок своєчасного отримання важливої для успіху інформації, недосяжної раніше іншими шляхами, так і поліпшувати особисту управлінську продуктивність, тобто різко скорочувати завдяки таким СППР час на отримання таких самих результатів.
Термін «Business intelligence» використовується як синонім «OLAP» в інструкціях щодо використання і в описаннях виконавчих інформаційних систем. «Business intelligence» є терміном з мар­кетингу. Він уживається також для позначення орієнтованих на
дані СППР. Цей тип СППР допомагає користувачам реалізувати практичне оброблення вниз (drill down) для детальнішого огляду інформації, оброблення вгору (drill up), щоб оглянути ширшу, інтегровану інформацію, «розрізати базу даних тонкими скибочками й нарізувати кубиками» («slice and dice»), щоб змінити вимірність, яку вони переглядають. Результати «drilling» і «slicing та dicing» подаються в таблицях і схемах. Чому саме такі та подібні їм можливості стали конче потрібними ОПР та менеджерам?
Традиційна технологія підготовки інтегрованої інформації на основі запитів і звітів у звичайних системах підтримки прийняття рішень стала неефективною через різке зростання кількості і збільшення різноманітності вихідних даних, що знаходяться в численних оперативних і виробничих системах організацій. Ця обставина стала гальмувати виконання функцій управління у разі необхідності швидко створювати й приймати рішення. Крім того, постійне накопичення даних у корпоративній базі даних для прийняття рішень і подальший їх аналіз гальмують оперативну роботу з даними.
У типовій організації доступні оперативні бази даних розроблялися для здійснення регулярних процедур (транзакцій). Такі потреби можуть включати, наприклад, підготовку нового або поновлення попереднього замовлення. Регулярні процедури рідко пов’язані з запитами, тому, зазвичай, оперативні бази даних містять тільки поточну інформацію. Вони не можуть задовольнити інформаційні потреби користувачів СППР, тому що їм не вистачає архівних даних та їх стабільності, що стає вирішальним у разі необхідного аналізування. Наприклад, ОПР може звернутися до системи із запитанням: «Як проведені компанією останні заходи щодо розповсюдження товару впливали на його продаж за останній квартал у порівнянні з таким самим просуванням товару за останній рік?» Швидкої та вичерпної відповіді на подібні запитання традиційні СППР забезпечити не могли.
Крім того, часто дані знаходяться в різних операційних системах, які мають суттєві відмінності в організації даних. Фактично поєднання даних із систем DB2, Oracle та COBOL з даними бази даних Sybase чи Informix може бути нелегким та ускладнюючим аналіз цих даних. Оперативні бази даних за структурою та розміром є недостатніми для загального аналізу. Як результат із цього випливає, що коли потреби оперативних баз даних повністю відрізняються від потреб СППР, то вони не є оптимальними для використання в СППР, що призводить до неефективного виконання запитів до СППР.
В історичному контексті це означає, що СППР не були такими корисними, як могли б бути, оскільки необхідні дані не були вчасно доступними. Для компенсації цього недоліку часто адаптовували окремі «заморожені» фрагменти виходів інформаційної системи для наступного аналізу. Ці фрагменти забезпечують лише інформацією про відібрані об’єкти в окремі моменти часу. Хоча такі фрагменти ефективніші, ніж безпосереднє використання оперативної бази даних, але їм недостає широкого спектру інформації для повного її аналізу або гнучких специфічних запитів. Інакше кажучи, ураховуючи всі переваги такого розв’язання проблеми, воно загалом не створює сприятливого середовища для використання СППР.
Альтернативним та популярнішим підходом є створення сховища даних для підтримки потреб СППР, а також застосування інструментальних засобів OLAP-систем, які забезпечують доступ і оброблення накопичених за достатній період внутрішніх даних організації, а також у деяких випадках і зовнішніх.
У загальному випадку дані ОДСППР є операційними даними
щодо фіксації щоденних бізнесових операцій компанії, тобто дані про транзакції (ведення справ, угод) і бізнесові випадки (явища). Вони формуються, щоб забезпечити тактичні й стратегічні бізнесові дії на основі операційних і доречних зовнішніх даних. Відмінність у цілях застосування операційних баз даних і баз даних СППР полягає в тому, що формати і структури цих видів даних відрізняються принаймні за шістьма основними показниками: структурою даних, діапазоном часу, підсумовуванням даних, мін­ливістю даних, вимірністю даних і метаданими. Короткий виклад цих відмінностей наведено в табл. 10.1. Зупинимося на них докладніше.

Таблиця 10.1
ЗІСТАВЛЕННЯ ОПЕРАЦІЙНИХ ДАНИХ І ДАНИХ ОДСППР

Показники

Операційні дані

Дані СППР

Структура даних

стандартизована

інтегрована

Діапазон часу

поточні

історичні (накопичувані)

Підсумовування

не здійснюється

розширюване в системах

Мінливість даних

змінюються

довготермінові

Вимірність даних

одновимірні

багатовимірні

Метадані

бажані

обов’язкові й імпортовані

 

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

За зберігання операційних даних або даних транзакційних систем програмне забезпечення і апаратні засоби оптимізовані так, щоб підтримувати транзакції стосовно щоденних операцій компанії. Наприклад, кожного разу, коли продається виріб, то все, що з цим актом пов’язане, мусить бути записане і враховане, тобто обчислене у відповідній таблиці транзакцій. Також пов’язані з цією операцією дані — дані щодо замовників і запасів матеріалів, змінюються в системах оброблення транзакцій. Для того, щоб забезпечити ефективну й ефектну актуалізацію БД, системи транзакцій зберігають дані в багатьох малих таблицях, кожна з яких
має мінімальну кількість полів. Так, наприклад, простій транзакції з оброблення запиту щодо збуту продукції потрібно мати дані, елементи яких записуються в п’яти або більше різних таблицях, оскільки потрібно добавляти або змінювати запис у таблиці накладної, в таблиці рядків накладної, таблиці дисконтів, таблиці запасів і таблиці департаменту.
Хоч такий структурований підхід до створення багатьох малих таблиць розглядається як ефективний для бази даних транзак­цій, однак він не призначений для організації даних в ОДСППР. За такого підходу запити будуть виконуватися повільно, оскільки потрібно з’єднати багато таблиць, щоб завершити опрацювання запиту, на що витрачається багато часу і використовуються обширні ресурси системи.
Операційні дані, зазвичай, зберігаються в багатьох різних таблицях і містять інформацію про специфічні транзакції, а дані ОДСППР — у значно меншій кількості таблиць, причому в них не завжди можна відшукати детальні відомості щодо кожної транзакції, бо вони є переважно підсумковими даними транзакцій. Дані з численних операційних баз даних інтегровані, агреговані й підсумовані в базі даних ОДСППР, щоб задовольняти наперед невизначені потреби щодо підтримки прийняття рішень.
Орієнтовані на дані СППР можуть містити надлишкові дані, якщо це сприяє прискоренню оброблення запитів. Компонентами даних ОДСППР на основі сховища даних є: метадані, поточні деталізовані дані, давніші докладні дані, підсумовані дані тощо. Загальна нормалізація не ефективна для даних ОДСППР і навіть деяка часткова нормалізація може реально зменшити ефективність оброблення запитів у орієнтованих на дані СППР.
Діапазон часу. Операційні дані є поточними даними, оскільки вони відображають теперішній стан бізнесових транзакцій. Дані ОДСППР — це миттєві знімки станів у задані моменти часу, тобто вони являють собою упорядковану за часом сукупність або серію операційних даних. Фактично в ОДСППР зберігаються численні «часові зрізи» операційних даних.
Підсумовування. Дані ОДСППР можуть підсумовуватися за допомогою програмного забезпечення аналітичного оброблення. Можна відправити деякі дані з бази даних ОДСППР у мультивимірний куб даних для прискореного аналізу. Деякі бази даних ОДСППР утворюються виключно з підсумків або (як їх часто називають) похідних чи вторинних даних. Наприклад, скоріше, ніж зберігати кожну із 10 000 транзакцій зі збуту в окремих елементах пам’яті на даний період, база даних ОДСППР може містити загальну кількість проданих одиниць і обсяг збуту. Дані ОДСППР можна було б подати у такий спосіб, щоб спостерігати обсяги збуту в грошовому еквіваленті для кожного магазину або збут у різних одиницях виміру для кожного типу продукту. Метою підсумовування є визначення і оцінювання трендів продажу або порівняння збутів різних типів продукції. Користувач може захотіти, наприклад, дізнатися: який тренд продукту А? чи доцільно припинити продаж деякого продукту? чи були ефективними витрати на рекламу для створення сприятливих змін у збуті? На всі ці запитання можна відповідати, використовуючи інтегровані дані. Операційні дані не підсумовуються в базах даних.
Мінливість даних. Тільки два види дій відбуваються в сховищі даних або базі даних ОДСППР: завантаження даних і організація доступу до них. Можна додавати дані в пакетах, але це вже не буде інтерактивною актуалізацією даних. Отже, дані СППР не змінюються з часом. Операційні дані мають непостійний характер, оскільки вони змінюються, як тільки відбуваються нові транзакції.
Вимірність даних. Багатовимірність даних є, можливо, найхарактернішою особливістю даних ОДСППР. З погляду менеджера чи аналітика дані ОДСППР завжди пов’язані між собою багатьма різними способами. Наприклад, коли аналізується збут продукту окремому споживачеві протягом певного проміжку часу, то можна зробити такий запит: «Скільки виробів типу X було продано споживачеві Y протягом останніх шести місяців?» Дані ОДСППР можуть досліджуватися в різних аспектах, наприклад, за видами продуктів, за регіонами і за часом. Здатність аналізувати, виділяти і подавати дані як інформацію в зручному вигляді є однією із головних позитивних характеристик ОДСППР. На противагу ним, операційні дані мають тільки одну вимірність.
Метадані. В орієнтованій на дані СППР важливо розробити і підтримувати метадані про дані СППР. Словники баз даних можуть бути і для систем оброблення транзакцій, але через те, що дані ОДСППР можуть надходити від багатьох джерел, створення словників і метаданих є особливо важливим для СППР. Метадані — це «інформація про дані» в базі даних СППР. До ресурсів метаданих належать каталоги і словники бази даних, а також імена змінних, довжини полів, допустимі значенння змінних і описи елементів даних. Семантичні дані часто зберігаються в словнику бази даних. Метадані зберігають інформацію про зміни у схемі початкових джерел сховища даних або бази даних.
Орієнтовані на дані СППР часто відносять до типу аналітичних систем (АС), тобто інформаційних систем, метою яких є лише аналіз даних. Інколи терміни «АС» і «ОДСППР» уживають як синоніми. Зауважимо, що стосовно інформаційних процесів аналітичні системи є вторинними по відношенню до операційних транзакційних систем OLTP (On-line transaction processing), оскільки всі дані, що використовуються для аналізу, необхідно спочатку нагромадити і, за можливості, частково обробити, чим і займаються різні транзакційні системи, а лише потім їх про­аналізувати. Основні відмінності систем оброблення транзакцій OLTP (онлайнових систем оброблення даних) і аналітичних систем (орієнтованих на дані СППР) наведені в табл. 10.2.

Таблиця 10.2
ОСНОВНІ ВІДМІННОСТІ СИСТЕМ ОБРОБЛЕННЯ
ТРАНЗАКЦІЙ (OLTP) І АНАЛІТИЧНИХ СИСТЕМ


Характеристика

Онлайнова система
оброблення транзакцій

Аналітична система

Мета
системи

Облік, зберігання і оперативне оброблення первинних, де­талізованих даних, що характеризують поточний стан об’є­ктів предметної галузі (ПГ)

Отримання і зберігання узагальнених даних про ПГ і подання їх у вигляді, зручному для бізнес-аналізу та підтрим­ки прийняття рішень

Джерела та но­менклатура даних

Поточні оперативні дані, що деталізовано характеризують стан об’єктів ПГ, як правило, за останній та кілька поперед­ніх місяців

Крім детальних, потрібні узагальнені дані за певні періоди, а також фактичні дані, нагромаджені за тривалий час. Крім внутрішніх потрібні ще й зовнішні дані

Вигляд
даних

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

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

Частота
оновлення

Дані є динамічними, поточними, тобто безперервно онов­люються і дуже часто зміню­ються

Дані є статичними, тобто вони практично не змінюються, а лише доповнюються новими записами

Закінчення табл. 10.2


Характеристика

Онлайнова система
оброблення транзакцій

Аналітична система

Характер
запитів
до системи

Перелік запитів до транзакційних систем відомий ще за їх проектування. Переважають регламентні запити, які детерміновані в часі, тобто створюються з певною періодичністю і мають фіксований перелік вихідних повідом­лень. За розв’язання таких
задач переважають дуже часті вибірки з БД даних невеликими порціями. Транзакційні системи, головно, містять задачі прямого розрахунку

За розв’язання аналітичних завдань переважають нерегламентні запити, які потребують оброблення великих обсягів агрегованих даних (сум, мінімальних, максимальних, середніх та інших значень показників). АС має надавати аналітику різноманітні інструменти для оброблення даних та методики аналізу (наприклад, весь спектр статистичних методів, генетичних алгоритмів, нечіткої логіки і т. п.)

Подання
результатів
роботи

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

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

Захист

Для оперативної БД, як правило, достатньо захисту на рівні таблиць

Аналітичні дані потребують більшого захисту, зокрема, на рівні окремих значень аналітичних показників

Наявність
метаданих

Метаданими в OLTP-систе­мах користуються переважно лише адміністратори систем

Репозитарій метаданих — це необхідна компонента, яка є довідником про дані сховища для користувачів системи

Необхідність перепроекту-вання

Бази даних транзакційної системи мають бути спроектовані так, щоб вони не потребували подальшого перепро­ектування

Створення сховищ даних є ітеративним за своєю суттю і потребує регулярного перепроектування протягом усьо­го їхнього життєвого циклу

Аналітичні завдання залежно від концепції аналізу можна поділити на дві групи: завдання статичного та завдання оперативного аналізу. Ці дві групи аналітичних завдань суттєво відрізняються між собою.
Перша група завдань характеризується тим, що вони реалізуються на основі традиційної технології автоматизації розв’язан­ня. За цієї технології спочатку формулюється технічне завдання, яке передається програмісту для програмування. Програміст складає програму та тестує її і лише після цього отримує результат у вигляді регламен­тованих, тобто чітко визначених форм. За такого підходу виникає велика затримка в часі між моментом виникнення потреби в аналізі та отриманням відповідного результату. Дуже часто результат аналізу, який був потрібний аналітику, отримують пізно і рішення прий­мається без його врахування. Тому для прийняття оперативних рі­шень такий вид аналізу не підходить.

Рис. 10.1. Узагальнена схема
інформаційної аналітичної системи
Саме потреба в оперативному багатоаспектному бізнес-аналізі привела до виникнення нової OLAP-технології розв’язання аналітичних завдань. Ця технологія призначена забезпечувати аналітиків динамічним багатовимірним аналізом консолідованих даних. Як уже зазначалося, розв’язання аналітичних завдань не може обмежуватись лише даними транзакційних систем. Для порівняльного аналізу та виявлення тенденцій потрібно мати великі обсяги зовнішніх даних з різних статистичних збірників, з електронних та інших джерел. Зручним способом зберігання даних для розв’язання оперативних аналітичних завдань є сховища даних, що утворюють основу аналітичних інформаційних систем. Узагальнена схема інформаційної аналітичної системи, котра ураховує описані засади, показана на рис. 10.1.
Орієнтовані на дані СППР мусять мати дані найвищої якості, інакше дані можуть призвести до невдач у розв’язанні проблем. Дані найвищої якості — це точні, своєчасні, значимі (важливі)
і повні (комплектні) дані. Оцінювання або вимірювання якості джерел даних є попереднім завданням, яке пов’язане з оцінюванням технічної здійснимості проекту орієнтованої на дані СППР.
10.1.2. Базові концепції та визначення
Зважаючи на те, що сховища даних і системи оперативного аналітичного оброблення (OLAP-системи) в принциповому плані виконують фактично такі самі функції, а саме: на основі нагромаджених за багато періодів даних про поточні ділові операції появляється можливість отримувати інформацію для створення кращих, основаних на фактах, управлінських рішень, деякі коментатори стали їх ототожнювати. Насправді, сховища даних і OLAP — різні види орієнтованих на дані СППР.
Сховище даних (Data Warehouses) є специфічною базою даних, яка проектується і наповнюється, щоб підтримувати створення рішень в організації. Це є пакет, своєрідна система керування базою даних, що існує окремо від оперативних систем, обновлюється і структурується для термінових оперативних запитів і управлінських підсумків. За змістом та часовим горизонтом вона відрізняється від оперативних систем. При цьому сховище даних є незмінним у часі, а, отже, здатним підтримувати різноманітні види аналізу. Переважно такі бази даних є архівами операційних даних, відібраних для забезпечення підтримки прийняття рішень та оптимізованих для взаємодії з СППР організації. На рис. 10.2 зображена спрощена схема формування та використання сховища даних у СППР. Дані беруться з різноманітних джерел оперативних даних. Після переміщення проводиться їх відбір для гарантування того, що вони мають достатню значимість, є безперервними і точними. Потім дані завантажуються в реляційні таблиці, які в змозі підтримувати різноманітні види аналізу та запитів, і оптимізуються для тих таблиць, які, як очікується, будуть найчастіше застосовуватися. І, нарешті, дані зберігаються для подальшого використання в СППР.

Рис. 10.2. Схема формування і використання
сховища даних у СППР
Згідно з концепцією засновника сховищ даних Б. Інмона (Bill Inmon) «сховище даних є тематично орієнтованою, інтегрованою, динамічною (time-variant), довготривалою сукупністю даних для підтримання процесів менеджерів, котрі розробляють рішення». Р. Кімбал (Ralph Kimball, 1996), інший піонер створення сховищ даних, уважає, що «сховище даних містить копії даних транзакцій, специфічно структурованих для запитів і аналізу».
Головними властивостями сховищ даних, які виділені Інмоном, є:
Тематична (суб’єктна) орієнтованість означає фокусування на темах, пов’язаних з бізнесом або організаційною активністю суб’єктів подібно діям споживачів (клієнтів), службовців і постачальників, тобто сховища даних мають орієнтуватися на предметну галузь, а не на специфіку програмних засобів, які будуть взаємодіяти з цими додатками.
Інтегрованість означає, що дані зберігаються в узгодженому форматі завдяки використанню іменованих правил (умовних позначень, домовленостей), обмежень домена (області допустимих значень, сфери дії), фізичних атрибутів і вимірів.
Динамічність (time-variant) — це відповідність даних певним моментам часу, тобто це є часові ряди (або серії), що не мають поточного статусу.
Довготривалість означає, що дані тільки читаються і не змінюються з часом, як тільки вони переміщуються в сховище,
і зберігаються для підтримки рішень.
Крім цих характеристик існують і інші важливі властивості сховищ даних, зокрема:
Підсумовуваність даних операційні дані набувають придатної для підтримки рішень форми, тобто бази даних утримують агреговані значення для управлінських рішень як окремий відбиток від баз даних, які використовуються для онлайнового оброблення транзакцій — OLTP (On Line Transaction Processing).
Масштабність мається на увазі, що в сховищах даних зберігається набагато більше даних, ніж у звичайних базах
даних.
Ненормалізованість дані в сховищах можуть бути надмірними, ненормалізованими.
Наявність метаданих метадані в СППР на основі сховищ даних обов’язкові. Ці метадані життєво важливі для підтримки сховищ даних і для кінцевих користувачів, яким потрібно знати, як розмістити дані.
Сховища даних недешеві. До цих пір потрібні багатомільйонні загальні витрати і тривалий час для їх проектування та реалізації. Велике корпоративне сховище даних може потребувати 2—3 мільйонів доларів, необхідних для створення програмного та апаратного забезпечення, оплати праці розробників, витрат на навчання та 2—3 років для його створення. Оскільки сховища даних розробляються з метою забезпечення кожного менеджера підприємства загальним рядом даних, то вони, як правило, великі за обсягом даних і збільшуються з часом. Типові розміри потрібної пам’яті — від 50 гігабайт (гігабайт = 1 073 741 844 байтам) до понад один Тб (терабайт = 1000 гігабайтам). Проте, незважаючи на значні фінансові та витрати часу, організація сховищ даних стає все популярнішою. Нині побудова сховищ даних є головним напрямом розвитку інформатики. Оцінки дещо різняться, але можна впевнено стверджувати, що більше половини корпорацій, які входять до 500 найуспішніших, мають або планують мати сховища даних.
Зі сховищем даних пов’язаний термін «вітрина даних» (Data Mart). Інколи застосовують такі його синоніми: кіоск даних, підмножина сховища даних, сховище даних рівня підприємства, ярмарка даних. Вітрина даних — це певна частина сфокусованих на окрему тему даних або виокремлені елементи сховища даних. Наприклад, деякі компанії скоріше будують вітрину даних щодо споживачів, ніж багатопредметне сховище даних. Така вітрина даних містить всю необхідну інформацію про споживачів. Багато організацій і бізнесових структур починають будувати свої повномасштабні (корпоративні) сховища даних шляхом побудови серії сфокусованих вітрин даних.
Коли сховище даних уже створене та оптимізоване, то необхідно ефективно завантажувати нові дані в систему без переривання процесу підтримки прийняття рішень. Однак у разі збільшення кількості даних розробникам необхідно визначати нові синтаксичні формати та формати запитів, які були б швидшими та легшими. Найпоширенішим засобом організації сховищ даних для задоволення різних аналітичних запитів є використання багатовимірної моделі даних, що пов’язується з поняттям OLAP, зокрема, з його реляційним різновидом.
Група продавців технології OLAP, яка є асоціацією захисників програмних продуктів OLAP, що має призначення сприяти більшому розумінню системи і її головних принципів, сформувала Раду OLAP. Рада запропонувала таке визначення OLAP:
Оперативне (онлайнове) аналітичне оброблення (On-line analytical processing — OLAP) є категорією технології програмного забезпечення, яке дало змогу аналітикам, менеджерам і виконавцям підсилити подання даних завдяки швидкому, узгодженому, інтерактивному доступу до широкого діапазону можливих зображень інформації, яка була одержана шляхом перетворення неопрацьованих (первинних) даних для відображення в реальній вимірності, зрозумілій користувачам, стану підприємства.
З практичного погляду OLAP є якраз тим, чого очікували від СППР протягом багатьох років, тобто перспективною системою, яка проста для використання, містить спеціалізовані (спеціально виділені) дані і пристосована до потреб користувачів. Ця система використовує сховища даних, а також містить велику кількість інструментальних засобів кінцевого користувача для організації доступу до даних і проведення їх аналізу.
OLAP здійснюється в багатокористувацькому клієнт/сервер­ному режимі і уможливлює узгоджену швидку відповідь на запити, незалежно від обсягу і складності бази даних. OLAP допомагає користувачеві синтезувати інформацію підприємства завдяки порівняльному, конкретизованому перегляду даних, а також завдяки аналізу фактичних і розрахункових показників у варіантах аналізу типу «що …, якщо…?». Все це досягається за допомогою використання сервера OLAP.
Сервер OLAP є високорозрядним, багатокористувацьким механізмом (або процесором бази даних) маніпулювання даними, специфічно розробленим для того, щоб підтримувати і здійснювати операції з багатовимірними структурами даних. Багатовимірна структура упорядкована так, щоб кожний елемент даних був розміщений і забезпечений доступом на основі перетину компонентів вимірностей, які визначають той елемент. Сервер і структура даних оптимізовані для швидкого пошуку інформації, для проведення аналізу типу «на даний випадок» (ad-hoc) у будь-якому аспекті, а також для швидкого та гнучкого обчислення і перетворення первинних даних, що ґрунтується на формульних взаємоза­лежностях.
Досягнутий на даний час стан технологічних засобів і вимоги кінцевих користувачів щодо узгоджених і швидких відповідей визначають, що найкращим підходом до організації оброблення даних є установлення багатовимірної бази даних у сервері OLAP. Прикладами багатовимірних серверів можуть бути Lightship Server від Pilot Software і Essbase від Arbor Software.
Функціональні можливості OLAP характеризують підтримку кінцевих користувачів-аналітиків динамічним багатовимірним аналізом консолідованих підприємницьких даних і навігаційними діями, включаючи: обчислення і моделювання, що застосовується за допомогою вимірності, єрархії і/або компонентів; аналіз трендів за послідовні періоди; квантування підмножин (підмножини даних аналізують за допомогою тонких зрізів) для візуалізації на екрані; практичне оброблення з підвищенням рівня деталізації до найглибших рівнів консолідації основних даних; прямий доступ до основних деталізованих даних; повернення до порівнянь у нових вимірах із застосуванням візуалізації.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2019 BPK Group.