ОПЕРАТИВНА АНАЛІТИЧНА ОБРОБКА

Термін оперативна аналітична обробка (On-Line Analytical Processing-OLAP) вперше був згаданий в доповіді, підготовленій для корпорації Arbor Software Corp в 1993 році [2211], хоча визначення цього терміна, як і у випадку з сховищами даних, було сформульовано набагато пізніше Поняття, позначене цим терміном, може бути визначене як інтерактивний процес створення, супроводу, аналізу даних і видачі звітів. Крім того, зазвичай додають, що розглянуті дані повинні сприйматися і оброблятися таким чином, як якщо б вони зберігалися в багатовимірному масиві Але перш ніж приступити до обговорення власне багатовимірного представлення, розглянемо відповідні ідеї в термінах традиційних таблиць SQL

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

дуже скоро стає занадто великим Проте, користувачам необхідно розглянути всі або майже всі такі способи Безумовно, тепер в стандарті SQL підтримується подібне агрегування, але будь-який конкретний запит SQL виробляє в якості свого результату тільки одну таблицю, а всі рядки в цій результуючій таблиці мають однакову форму і одну і ту ж інтерпретацію10 (принаймні, так

9 Наведемо рада з книги по сховищ даних [2224]: [Відмовтеся] від нормалізації .. По тортури нормалізувати будь-яку з таблиць в багатовимірної базі даних виключно заради економії дис кового простору [саме так] – марна трата часу .. Таблиці розмірності не повинні бути нормалізовані .. Нормалізовані таблиці розмірності виключають можливість перегляду .

10 Якщо тільки ця таблиця результатів не включає будь невизначені значення, або NULL-значення (див главу 19, розділ 193, підрозділ Додаткові відомості про предикатах) Насправді конструкції SQL: 1999, які повинні бути описані в даному розділі, можна охаракте ризовать як засновані на використанні цього вельми не рекомендованого засоби SQL () в дей ствительности, вони підкреслюють той факт, що у своїх різних проявах невизначені значе ня можуть мати різний зміст, і тому дозволяють представити в одній таблиці багато різних преди катів (Як буде показано нижче)

було до появи стандарту SQL: 1999) Тому, щоб реалізувати п різних способів групування, необхідно виконати п окремих запитів і створити в результаті л окремих таблиць Наприклад, розглянемо наведену нижче послідовність запитів, які виконуються в базі даних постачальників і деталей

1 Визначити загальну кількість поставок

2 Визначити загальну кількість поставок по постачальникам

3 Визначити загальну кількість поставок по деталям

4 Визначити загальну кількість поставок по постачальникам і деталям

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

Тепер припустимо, що є тільки дві деталі, з номерами Р1 і Р2, а таблиця поставок виглядає наступним чином

Тоді формулювання на мові SQL для чотирьох зазначених вище запитів і відповідні результати їх виконання будуть такими, як показано нижче

Примітка У стандарті SQL: 1999 дозволено (а в стандарті SQL: 1992 – ні), вправах, укладати операнди конструкції GROUP BY в круглі дужки і, по-друге, застосовувати конструкцію GROUP BY взагалі без операндів (останнє еквівалентно повному виключенню конструкції GROUP BY)

1 SELECT SUM(QTY) AS TOTQTY FROM    SP GROUP BY ()

2&nbsp&nbsp SELECT S#

SUM(QTY) AS TOTQTY FROM   SP GROUP BY (S#)

Недоліки цього підходу очевидні Складання такої великої кількості про

3&nbsp&nbsp&nbsp&nbsp SELECT P#

SUM(QTY) AS TOTQTY FROM   SP GROUP BY (P#)

4&nbsp&nbsp&nbsp SELECT S#,  P# SUM(QTY) AS

TOTQTY FROM   SP GROUP BY (S#,P#)

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

створюючи ОПЦИИ GROUPING SETS, ROLLUP І CUBE КОНСТРУКЦІЇ GROUP BY

Примітка Ці опції вже підтримуються в комерційних продуктах протягом декількох років, а в стандарт SQL введені в 1999 році

Опція GROUPING SETS дозволяє користувачеві точно вказати, який саме спосіб групування йому потрібно Наприклад, наведений нижче оператор SQL являє собою поєднання запитів 2 і 3

SELECT S#, P#, SUM(QTY) AS TOTQTY FROM  SP

G R O U P                                           BY    G R O U PIN G    SE TS                                         (                                         ( S # ) ,                                          ( P # )                                          )                                         

Тут за допомогою конструкції GROUP BY системі фактично передається вимога на виконання двох запитів, в одному з яких групування відбувається по атрибуту s #, а в іншому – по атрибуту Р #

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

Ідея обєднання декількох окремих запитів в один оператор зазначеним способом сама по собі не викликає особливих заперечень (хоча необхідно все ж сказати, що

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

Цей результат дійсно можна вважати таблицею (У всякому разі, таблицею в стилі SQL), але навряд чи його можна назвати ставленнямЗверніть увагу на те, що рядки з даними про постачальників (вони містять невизначені значення в стовпці Р #) і рядки з даними про деталі (які містять невизначені значення в стовпці S #) мають абсолютно різні інтерпретації А сенс значень TOTQTY стає різним залежно від того, чи належать вони до рядків з даними про постачальників або до рядків з даними про деталі Так яким ж може бути предикат для такого відносини? (В дійсності, результуючу таблицю в даному прикладі можна розглядати, скоріше як зовнішнє обєднання результатів запитів 2 і 3, але вельми дивне зовнішнє обєднання Як описано в главі 19, операція зовнішнього обєднання, причому навіть і не в такій дивній формі, не заслуговує назви повноцінної реляційної операції)

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

Примітка У мові SQL надається можливість відрізнити ці нові невизначені значення від інших видів, але вивчення докладних відомостей про таку процедуру досить утомливо по суті, користувач змушений окремо аналізувати кожний рядок Певне уявлення про те, що з цим повязано, можна отримати, розглянувши наступний приклад (який показує, як фактично може виглядати на практиці наведений вище приклад застосування конструкції GROUPING SETS)

SELECT CASE GROUPING (

S# ) WHEN 1 THEN ?

?’ ELSE S# AS S#, CASE GROUPING ( P#

) WHEN 1 THEN !!’ ELSE P# AS P#,

SUM(QTY) AS TOTQTY FROM   SP GROUP BY GROUPING SETS ( (S#), (P#)

)

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

отриманню наступних результатів

Повернемося до конструкції GROUP BY Дві інші опції конструкції GROUP BY, ROLLUP і CUBE, по суті, є скороченнями для певних поєднань в конструкції GROUPING SETS Спочатку розглянемо опцію ROLLUP на прикладі наступного запиту

SELECT S#, P#, SUM(QTY) AS TOTQTY FROM  SP

GROUP BY ROLLUP ( S#, P# )

У даному випадку конструкція GROUP BY буде рівносильно наступної

GROUP BY GROUPING SETS ( (S#,P#), (S#), () )

Іншими словами, цей запит обєднує формулювання запитів 4, 2 і 1 на мові

SQL Результат його виконання виглядає наступним чином

Термін ROLLUP (накопичити) прийнятий через те, що в даному прикладі кількості накопичуються для кожного постачальника (тобто накопичуються по розмірності постачальника; див наведений нижче підрозділ Багатовимірні бази даних) Загалом конструкція GROUP BY ROLLUP (А, B, .., Z), або, простіше кажучи, накопичити по розмірності А, означає згрупувати по всіх наступним сполученням .

(А, В, , Z )

{А, В, )

(А, В) (А)

Зверніть увагу на те, що в загальному випадку виконується багато окремих накопичень по розмірності А (ЦЕ залежить від того, які інші стовпці згадані в розділеному комами списку ROLLUP) Також відзначимо, що конструкції GROUP BY ROLLUP (А, B) і GROUP BY ROLLUP (B, А) мають різні значення, тобто конструкція GROUP BY ROLLUP (А, В) не симетрична відносно А і B

А тепер розглянемо опцію CUBE Як приклад візьмемо наступний запит

SELECT S#, P#, SUM(QTY) AS TOTQTY FROM  SP

GROUP BY CUBE ( S#, P# )

Конструкція GROUP BY тут буде логічно еквівалентна конструкції, показаної нижче

GROUP BY GROUPING SETS ( (S#,P#), (S#), (P#), () )

Іншими словами, цей запит обєднує формулювання всіх чотирьох запитів 4, 3, 2 і 1 на мові SQL Результат його виконання виглядає наступним чином

Маловиразну ключове слово CUBE (куб) було прийнято до використання через те, що в термінології технології OLAP, принаймні, в багатовимірної, значення даних розглядаються як зберігаються в осередках багатовимірного масиву, або гиперкуба У даному випадку значення даних є кількісними куб має лише два виміри – вимір постачальників і вимір деталей (такий куб слід було б назвати площиною) ці два виміри мають нерівні розміри (так що даний куб навіть не є квадратом скоріше, це-прямокутник) Але як би то не було, конструкція GROUP BY CUBE(А, в, .. Z) означає згрупувати по всіх можливих підмножини множини {А, в, ,   Z}&quot.

Будь-яка конструкція GROUP BY може включати довільні поєднання опцій

GROUPING SETS, ROLLUP І CUBE

Перехресні таблиці

Продукти OLAP часто відображають результати запитів не у вигляді таблиць SQL, а у вигляді перехресних таблиць (cross tabulation, або скорочено – crosstab) Знову розглянемо запит 4 (Визначити загальну кількість поставок по постачальникам і деталям ) Нижче представлені результати виконання цього запиту у вигляді перехресної таблиці Відзначимо, до речі, що кількість деталей з номером Р1 для постачальників з номерами S3 і S4 показано (правильно) як нульове У мові SQL, навпаки, для цієї кількості було б отримано невизначений значення (див главу 19) Насправді, таблиця, яка формується в мові SQL у відповідь на запит 4, не містить рядків для поєднання атрибутів (S3, Р1) або (S4, Р1), тому спроба створити з неї перехресну таблицю є не такою вже легко здійсненною

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

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

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

підрозділі

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

Багатовимірні бази даних

Досі передбачалося, що дані OLAP зберігаються у звичайній базі даних, що використовує мову SQL (не рахуючи того, що іноді ми все ж стосувалися термінології та концепції багатовимірних баз даних) Фактично ми, не вказуючи явно, описували так звану систему ROLAP (Relational OLAP—  реляційна OLAP) Однак багато хто вважає, що використання системи MOLAP (Multi-dimensional OLAP – Багатовимірна OLAP) – більше перспективний шлях У цьому підрозділі принципи побудови систем MOLAP будуть розглянуті детальніше

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

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

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

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

стовпців, значення яких визначають значення інших стовпців) Отже, незалежні змінні задають розмірність масиву, за допомогою якого організовуються дані, а також утворюють схему адресаціі11 для даного масиву Значення залежних змінних, які представляють фактичні дані, зберігаються в осередках масиву

Примітка Різниця між значеннями незалежних, або розмірних, змінних,

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

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

На жаль, наведена вище характеристика багатовимірних баз даних занадто спрощена, оскільки більшість сукупностей даних спочатку залишаються НЕ вивченими повною мірою З цієї причини ми зазвичай прагнемо, в першу чергу, проаналізувати дані, щоб краще їх зрозуміти Часто недостатнє розуміння може бути настільки істотним, що заздалегідь неможливо визначити, які змінні є незалежними, а які залежними Тоді незалежні змінні вибираються згідно поточному уявленню про них (тобто на підставі деякої гіпотези), після чого перевіряється результуючий масив для визначення того, наскільки вдало вибрані незалежні змінні (див розділ 227) Подібний підхід призводить до того, що виконується безліч ітерацій за принципом проб і помилок Тому система зазвичай допускає заміну розмірних і нерозмірних змінних, і цю операцію називаютьзміною осей координат(Pivoting) Інші підтримувані операції включають транспозицию масиву і переупорядочение розмірностей Повинен бути також передбачений спосіб додавання розмірностей

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

(Див главу 19)

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

ієрархія, що звязує секунди з хвилинами, хвилини з годинником, годинник з добою, добу з тижнями, тижня з місяцями, місяці з роками Або інший приклад: можлива ієрархія

композиції, що звязує деталі з комплектом деталей, комплекти деталей з вузлом, вузли з модулем, модулі з виробом Часто одні і ті ж дані можуть агрегуватися багатьма різними способами, тобто одна і та ж незалежна змінна може належати до багатьох різних ієрархій Система надає оператори для проходження вгору (Drill up) і проходження вниз (Drill down) з такої ієрархії Проходження вгору означає перехід від нижнього рівня агрегування до верхнього, а проходження вниз –

перехід в протилежному напрямку Для роботи з ієрархіями є й інші операції, наприклад операція для переупорядковування рівнів ієрархії

Примітка Між операціями проходження вгору (Drill up) і накопичення підсумків (roll

up) є одне тонка різниця: операція накопичення підсумків – це операція реалізації

12 Зверніть увагу на відміну від реляційних систем У справжньому реляційному аналогу цього прикладу в рядку Ic, p, t) не було б марною осередку кількості, у звязку з тим, що рядок (З, р, t) просто б була відсутня Тому при використанні реляційної моделі, на відміну від багатовимірних масивів, немає необхідності підтримувати розріджені масиви, або скоріше розріджені таблиці , а значить, не потрібні вправні методи стиснення для роботи з такими таблицями

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

У продуктах багатовимірних баз даних надається також ряд статистичних та інших математичних функцій, які допомагають формулювати і перевіряти гіпотези (тобто гіпотези, що стосуються передбачуваних звязків) Крім того, надаються інструменти візуалізації та генерації звітів, що допомагають вирішувати подібні завдання Але, на жаль, для багатовимірних баз даних поки ще немає ніякого стандартного мови запитів, хоча ведуться дослідження з метою розробки обчислення, на якому міг би базуватися такий стандарт [2231] Але нічого подібного реляційної теорії нормалізації, яка могла б служити науковою основою для проектування багатовимірних баз даних, поки, на жаль, немає

Завершуючи цей розділ, зазначимо, що в деяких продуктах поєднуються обидва підходи – ROLAP і MOLAP Таку гібридну систему OLAP називають HOLAP Проводяться широкі дискусії з метою зясувати, який з цих трьох підходів краще, тому варто і нам спробувати сказати з даного питання кілька слов13 У загальному випадку системи MOLAP забезпечують більш швидке проведення розрахунків, але підтримують менші обсяги даних у порівнянні з системами ROLAP, тобто стають менш ефективними в міру зростання обсягів даних А системи ROLAP надають більш розвинені можливості масштабованості, паралельності і управління порівняно з аналогічними можливостями систем MOLAP Крім того, недавно був доповнений стандарт SQL і в нього включено багато статистичні і аналітичні функції (див розділ 228) З цього випливає, що в даний час продукти ROLAP здатні до того ж надавати розширені функціональні можливості

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*