Куби даних. Введення в OLAP і багатовимірні бази даних

анотація: У цій лекції розглядаються основи проектування кубів даних для OLAP-сховищ даних. На прикладі показана методика побудови куба даних за допомогою CASE-інструменту.

мета лекції

Вивчивши матеріал цій лекції, ви будете знати:

що таке куб даних в OLAP-сховище даних ;
як проектувати куб даних для OLAP-сховищ даних ;
що таке вимір куба даних;
як факт пов'язаний з кубом даних;
що таке атрибути вимірювання;
що таке ієрархія;
що таке метрика куба даних;

і навчитеся:

будувати багатовимірні діаграми ;
проектувати прості багатовимірні діаграми.

Вступ

Технологія OLAP - це не окремо взятий програмний продукт, що не мова програмування. Якщо постаратися охопити OLAP в усіх його проявах, то це сукупність концепцій, принципів і вимог, що лежать в основі програмних продуктів, що полегшують аналітикам доступ до даних.

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

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

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

Оперативні дані збираються з різних джерел, очищаються, інтегруються і складаються в ХД. При цьому вони вже доступні для аналізу за допомогою різних засобів побудови звітів. Потім дані (повністю або частково) готуються для OLAP-аналізу. Вони можуть бути завантажені в спеціальну БД OLAP або залишені в реляционном ХД. Найважливішим елементом використання OLAP є метадані, т. Е. Інформація про структуру, розміщенні і трансформації даних. Завдяки їм забезпечується ефективна взаємодія різних компонентів сховища.

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

OLAP на клієнті і на сервері

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

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

Якщо вихідні дані містяться в настільній СУБД, обчислення агрегатних даних виробляється самим OLAP-засоби. Якщо ж джерело вихідних даних - серверна СУБД, багато з клієнтських OLAP -Засобів посилають на сервер SQL-запит, що містять оператор GROUP BY, і в результаті отримують агрегатні дані, обчислені на сервері.

Як правило, OLAP -функціональність реалізована в засобах статистичної обробки даних (з продуктів цього класу на російському ринку широко поширені продукти компаній Stat Soft і SPSS) і в деяких електронних таблицях. Зокрема, непоганими засобами багатовимірного аналізу володіє Microsoft Excel 2000. За допомогою цього продукту можна створити і зберегти як файл невеликий локальний багатомірний OLAP -куб і відобразити його дво- або тривимірні перетину.

багато засоби розробки містять бібліотеки класів або компонентів, що дозволяють створювати додатки, які реалізують найпростішу OLAP -функціональність (такі, наприклад, як компоненти Decision Cube в Borland Delphi і Borland C ++ Builder). Крім цього багато компаній пропонують елементи управління ActiveX і інші бібліотеки, реалізують подібну функціональність.

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

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

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

Переваги застосування серверних OLAP -Засобів в порівнянні з клієнтськими OLAP-засобами подібні з перевагами застосування серверних СУБД в порівнянні з настільними: в разі застосування серверних засобів обчислення і зберігання агрегатних даних відбувається на сервері, а клієнтське додаток отримує лише результати запитів до них, що дозволяє в загальному випадку знизити мережевий трафік, час виконання запитів і вимоги до ресурсів, що споживаються клієнтським додатком. Відзначимо, що кошти аналізу та обробка даних масштабу підприємства, як правило, базуються саме на серверних OLAP-засоби, наприклад, таких як Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, продуктах компаній Crystal Decisions, Business Objects, Cognos, SAS Institute. Оскільки всі провідні виробники серверних СУБД виробляють (або ліцензували у інших компаній) ті чи інші серверні OLAP-засоби, вибір їх досить широкий, і майже у всіх випадках можна придбати OLAP - сервер того ж виробника, що і у самого сервера баз даних.

Відзначимо, що багато клієнтські OLAP-засоби (зокрема, Microsoft Excel 2003 Seagate Analysis і ін.) Дозволяють звертатися до серверних OLAP-сховищ, виступаючи в цьому випадку в ролі клієнтських додатків, що виконують подібні запити. Крім цього є чимало продуктів, що представляють собою клієнтські програми до OLAP-засоби різних виробників.

Технічні аспекти багатовимірного зберігання даних

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

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

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

MOLAP (Multidimensional OLAP) - вихідні і агрегатні дані зберігаються в багатовимірної базі даних. Зберігання даних в багатовимірних структурах дозволяє маніпулювати даними як багатовимірним масивом, завдяки чому швидкість обчислення агрегатних значень однакова для будь-якого з вимірів. Однак в цьому випадку багатовимірна база даних виявляється надлишкової, так як багатовимірні дані повністю містять вихідні реляційні дані.
ROLAP (Relational OLAP) - вихідні дані залишаються в тій же реляційної базі даних, де вони спочатку і знаходилися. Агрегатні ж дані поміщають в спеціально створені для їх зберігання службові таблиці в тій же базі даних.
HOLAP (Hybrid OLAP) - вихідні дані залишаються в тій же реляційної базі даних, де вони спочатку знаходилися, а агрегатні дані зберігаються в багатовимірної базі даних.

Деякі OLAP-засоби підтримують зберігання даних тільки в реляційних структурах, деякі - тільки в багатовимірних. Однак більшість сучасних серверних OLAP -Засобів підтримують всі три способи зберігання даних. Вибір способу зберігання залежить від обсягу і структури вихідних даних, вимог до швидкості виконання запитів і частоти оновлення OLAP -куб.

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

Основні поняття OLAP

тест FAMSI

Технологія комплексного багатовимірного аналізу даних отримала назву OLAP (On-Line Analytical Processing). OLAP - це ключовий компонент організації ХД. Концепція OLAP була описана в 1993 році Едгаром Коддом, відомим дослідником баз даних і автором реляційної моделі даних. У 1995 році на основі вимог, викладених Коддом, було сформульовано так званий тест FASMI (Fast Analysis of Shared Multidimensional Information) - швидкий аналіз розділяється багатовимірної інформації, до складу якого такі вимоги до додатків для багатовимірного аналізу:

Fast (Швидкий) - надання користувачеві результатів аналізу за прийнятний час (зазвичай не більше 5 с), нехай навіть ціною менш детального аналізу;
Analysis (Аналіз) - можливість здійснення будь-якого логічного і статистичного аналізу, Характерного для цього додатка, І його збереження в доступному для кінцевого користувача вигляді;
Shared (Що розділяється) - розрахований на багато користувачів доступ до даних з підтримкою відповідних механізмів блокувань і засобів авторизованого доступу;
Multidimensional (Багатомірний) - багатовимірне концептуальне представлення даних, включаючи повну підтримку для ієрархій і множинних ієрархій (це ключова вимога OLAP);
Information (Інформація) - додаток повинен мати можливість звертатися до будь-якої потрібної інформації, Незалежно від її обсягу і місця зберігання.

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

Багатовимірне представлення інформації

Куби

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

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

Мал. 26.1.

"Розрізування" куба

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

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

(Levels). Наприклад, мітки, представлена \u200b\u200bна підтримуються далеко не всіма OLAP-засобами. Наприклад, в Microsoft Analysis Services 2000 підтримує обидва типи ієрархії, а в Microsoft OLAP Services 7.0 - тільки збалансовані. Різними в різних OLAP-засобах можуть бути і число рівнів ієрархії, і максимально допустиму кількість членів одного рівня, і максимально можливе число самих вимірювань.

Архітектура OLAP-додатків

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

Багатовимірність в OLAP-додатках може бути розділена на три рівні.

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

Перші два рівня в обов'язковому порядку присутні у всіх OLAP-засобах. Третій рівень, хоча і є широко поширеним, не обов'язковий, так як дані для багатовимірного уявлення можуть бути розкладені і зі звичайних реляційних структур; процесор багатовимірних запитів в цьому випадку транслює багатовимірні запити в SQL-запити, які виконуються реляційної СУБД.

Конкретні OLAP-продукти, як правило, являють собою або засіб багатовимірного представлення даних (OLAP-клієнт - наприклад, Pivot Tables в Excel 2000 фірми Microsoft або ProClarity фірми Knosys), або багатовимірну серверну СУБД (OLAP-сервер - наприклад, Oracle Express Server або Microsoft OLAP Services).

Шар багатовимірної обробки зазвичай буває вбудований в OLAP-клієнт і / або в OLAP-сервер, але може бути виділений в чистому вигляді, як, наприклад, компонент Pivot Table Service фірми Microsoft.

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

Якщо вам все-таки необхідно аналізувати OLAP-дані після відключення від мережі, створіть автономний куб даних. Автономний куб даних - це окремий файл, який представляє собою кеш зведеної таблиці і зберігає OLAP-дані, які він переглядав після відключення від локальної мережі. OLAP-дані, скопійовані в зведену таблицю, можна роздрукувати, на сайті http://everest.ua докладно про це розказано.

Щоб створити автономний куб даних, спочатку створіть зведену таблицю OLAP. Помістіть курсор в межах зведеної таблиці і клацніть на кнопці Засоби OLAP (OLAP Tools) контекстної вкладки Параметри (Tools), що входить в групу контекстних вкладок Робота зі зведеними таблицями (PivotTable Tools). Виберіть команду Автономний режим OLAP (Offline OLAP) (рис. 9.8).

На екрані з'явиться діалогове вікно налаштувань автономного куба даних OLAP. Клацніть в ньому на кнопці Створити автономний файл даних (Create Offline Data File). Ви запустили майстер створення файлу куба даних. Клацніть на кнопці Далі (Next), щоб продовжити процедуру.

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

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

На останньому етапі вкажіть розташування та ім'я куба даних. У нашому випадку файл куба буде названий MyOfflineCube.cub і буде розташовуватися в папці Work.

Файли кубів даних мають розширення .cub

Через деякий час Excel збереже автономний куб даних у зазначеній папці. Щоб протестувати його, двічі клацніть на файлі, що призведе до автоматичної генерації робочої книги Excel, Яка містить зведену таблицю, пов'язану з обраним кубом даних. Після створення ви можете поширити автономний куб даних серед всіх зацікавлених користувачів, які працюють в режимі відключеною локальної мережі.

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

Що таке OLAP сьогодні, в общем-то знає кожен фахівець. По крайней мере, поняття "OLAP" і "багатовимірні дані" стійко пов'язані в нашій свідомості. Проте той факт, що ця тема знову піднімається, сподіваюся, буде схвалений більшістю читачів, т. К. Для того, щоб уявлення про що-небудь з часом не застарівало, потрібно періодично спілкуватися з розумними людьми або читати статті в хорошому виданні ...

Сховища даних (місце OLAP в інформаційній структурі підприємства)

Термін "OLAP" нерозривно пов'язаний з терміном "сховище даних" (Data Warehouse).

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

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

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

Таким чином, завдання сховища - надати "сировину" для аналізу в одному місці і в простій, зрозумілій структурі. Ральф Кімбол в передмові до своєї книги "The Data Warehouse Toolkit" пише, що якщо після прочитання всієї книги читач зрозуміє тільки одну річ, а саме: структура сховища повинна бути простою, - автор буде вважати своє завдання виконаним.

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

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

OLAP - зручний інструмент аналізу

Централізація і зручне структурування - це далеко не все, що потрібно аналітику. Адже йому ще потрібно інструмент для перегляду, візуалізації інформації. Традиційні звіти, навіть побудовані на основі єдиного сховища, позбавлені одного - гнучкості. Їх не можна "покриття", "розгорнути" або "згорнути", щоб отримати бажане уявлення даних. Звичайно, можна викликати програміста (якщо він захоче прийти), і він (якщо не зайнятий) зробить новий звіт досить швидко - скажімо, протягом години (пишу і сам не вірю - так швидко в житті не буває; давайте дамо йому години три) . Виходить, що аналітик може перевірити за день не більше двох ідей. А йому (якщо він хороший аналітик) таких ідей може приходити в голову по кілька на годину. І чим більше "зрізів" і "розрізів" даних аналітик бачить, тим більше у нього ідей, які, в свою чергу, для перевірки вимагають все нових і нових "зрізів". От би йому такий інструмент, який дозволив би розгортати і згортати дані просто і зручно! В якості такого інструменту і виступає OLAP.

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

Компоненти, що входять до типове сховище, представлені на рис. 1.

Мал. 1. Структура сховища даних

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

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

Визначення та основні поняття OLAP

Для початку розшифруємо: OLAP - це Online Analytical Processing, т. Е. Оперативний аналіз даних. 12 визначальних принципів OLAP сформулював в 1993 р Е. Ф. Кодд - "винахідник" реляційних БД. Пізніше його визначення було перероблено в так званий тест FASMI, що вимагає, щоб OLAP-додаток надавало можливості швидкого аналізу розділяється багатовимірної інформації ().

тест FASMI

Fast (Швидкий) - аналіз повинен проводитися однаково швидко з усіх аспектів інформації. Прийнятний час відгуку - 5 з менш.

Analysis (Аналіз) - повинна бути можливість здійснювати основні типи числового і статистичного аналізу, зумовленого розробником програми або довільно визначається користувачем.

Shared (Розділяти) - безліч користувачів має мати доступ до даних, при цьому необхідно контролювати доступ до конфіденційної інформації.

Multidimensional (Багатовимірні) - це основна, найбільш істотна характеристика OLAP.

Information (Інформації) - додаток повинен мати можливість звертатися до будь-якої потрібної інформації, незалежно від її обсягу і місця зберігання.

OLAP \u003d багатовимірне представлення \u003d Куб

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

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

Мал. 2. Приклад куба

"Розрізування" куба

Навіть тривимірний куб складно відобразити на екрані комп'ютера так, щоб було видно значення цікавлять заходів. Що вже говорити про кубах з кількістю вимірів, великим трьох? Для візуалізації даних, що зберігаються в кубі, застосовуються, як правило, звичні двовимірні, т. Е. Табличні, уявлення, які мають складні ієрархічні заголовки рядків і стовпців.

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

Погляньте на рис. 3 - тут зображений двовимірний зріз куба для однієї заходи - Unit Sales (продано штук) і двох "нерозрізаних" вимірів - Store (Магазин) і Час (Time).

Мал. 3. Двовимірний зріз куба для однієї заходи

На рис. 4 представлено лише одне "нерозрізаного" вимір - Store, але зате тут відображаються значення декількох заходів - Unit Sales (продано штук), Store Sales (сума продажу) і Store Cost (витрати магазину).

Мал. 4. Двовимірний зріз куба для декількох заходів

Двовимірне подання куба можливо і тоді, коли "нерозрізаними" залишаються і більше двох вимірів. При цьому на осях зрізу (рядках і шпальтах) будуть розміщені два або більше вимірювань "розрізається" куба - см. Рис. 5.

Мал. 5. Двовимірний зріз куба з декількома вимірами на одній осі

Мітки

Значення, "відкладаються" уздовж вимірювань, називаються членами або мітками (members). Мітки використовуються як для "розрізання" куба, так і для обмеження (фільтрації) обираних даних - коли в вимірі, що залишається "нерозрізаним", нас цікавлять не всі значення, а їх підмножина, наприклад три міста з декількох десятків. Значення міток відображаються в двовимірному поданні куба як заголовки рядків і стовпців.

Ієрархії і рівні

Мітки можуть об'єднуватися в ієрархії, що складаються з одного або декількох рівнів (levels). Наприклад, мітки вимірювання "Магазин" (Store) природно об'єднуються в ієрархію з рівнями:

Country (Країна)

State (Штат)

City (Місто)

Store (Магазин).

Відповідно до рівнів ієрархії обчислюються агрегатні значення, наприклад обсяг продажів для USA (рівень "Country") або для штату California (рівень "State"). В одному вимірі можна реалізувати більше однієї ієрархії - скажімо, для часу: (Рік, Квартал, Місяць, День) і (Рік, Тиждень, День).

Архітектура OLAP-додатків

Багатовимірність в OLAP-додатках може бути розділена на три рівні:

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

Конкретні OLAP-продукти, як правило, являють собою або засіб багатовимірного представлення даних, OLAP-клієнт (наприклад, Pivot Tables в Excel 2000 фірми Microsoft або ProClarity фірми Knosys), або багатовимірну серверну СУБД, OLAP-сервер (наприклад, Oracle Express Server або Microsoft OLAP Services).

Технічні аспекти багатовимірного зберігання даних

Як вже говорилося вище, кошти OLAP-аналізу можуть отримувати дані і безпосередньо з реляційних систем. Такий підхід був більш привабливим в ті часи, коли OLAP-сервери були відсутні в прайс-листах провідних виробників СУБД. Але сьогодні і Oracle, і Informix, і Microsoft пропонують повноцінні OLAP-сервери, і навіть ті IT-менеджери, які не люблять розводити в своїх мережах "зоопарк" з ПО різних виробників, можуть купити (точніше, звернутися з відповідним проханням до керівництва компанії ) OLAP-сервер тієї ж марки, що і основний сервер баз даних.

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

Але, як відомо, за все треба платити. І за швидкість обробки запитів до сумарних даними доводиться платити збільшенням обсягів даних і часу на їх завантаження. Причому збільшення обсягу може стати буквально катастрофічним - в одному з опублікованих стандартних тестів повний підрахунок агрегатів для 10 Мб вихідних даних зажадав 2,4 Гб, т. Е. Дані виросли в 240 разів! Ступінь "розбухання" даних при обчисленні агрегатів залежить від кількості вимірювань куба і структури цих вимірів, т. Е. Співвідношення кількості "батьків" і "дітей" на різних рівнях виміру. Для вирішення проблеми зберігання агрегатів застосовуються часом складні схеми, Що дозволяють при обчисленні далеко не всіх можливих агрегатів досягати значного підвищення продуктивності виконання запитів.

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

MOLAP (Multidimensional OLAP) - і детальні дані, і агрегати зберігаються в багатовимірної БД. В цьому випадку виходить найбільша надмірність, так як багатовимірні дані повністю містять реляційні.
ROLAP (Relational OLAP) - детальні дані залишаються там, де вони "жили" спочатку - в реляційної БД; агрегати зберігаються в тій же БД в спеціально створених службових таблицях.
HOLAP (Hybrid OLAP) - детальні дані залишаються на місці (в реляційної БД), а агрегати зберігаються в багатовимірної БД.

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

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

Далі буде. Надалі ми поговоримо про конкретні OLAP-продуктах, що випускаються провідними виробниками.

Можливо, для когось використання OLAP-технології (On-line Analytic Processing) при побудові звітності здасться якоюсь екзотикою, тому застосування OLAP-КУБу для них зовсім не є одним з найважливіших вимог при автоматизації бюджетування і управлінського обліку.

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

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

Природно, це призводить до того, що керівники хочуть отримувати звітність у всіх цікавих для них аналітичних зрізах. А це означає, що звіти потрібно якось змусити «дихати». Іншими словами можна сказати, що в даному випадку мова йде про те, що за змістом один і той же звіт повинен надавати інформацію в різних аналітичних розрізах. Тому статичні звіти вже не влаштовують багатьох сучасних керівників. Їм потрібна динаміка, яку може дати багатовимірний КУБ.

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

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

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

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

Наприклад, бюджет продажів можна складати з використанням тільки однієї аналітики (довідника). Приклад бюджету продажів, побудованого на основі однієї аналітики "Продукти" представлений на малюнку 1.

Мал. 1. Приклад бюджету продажів, побудованого на основі однієї аналітики "Продукти" в OLAP-кубі

Цей же бюджет продажів можна складати з використанням двох аналітик (довідників). Приклад бюджету продажів, побудованого на основі двох аналітик "Продукти" і "Філії" представлений на малюнку 2.

Мал. 2. Приклад бюджету продажів, побудованого на основі двох аналітик "Продукти" і "Філії" в OLAP-кубі програмного комплексу "Інтеграл"

Якщо є необхідність будувати більш детальні звіти, то можна той же бюджет продажів складати з використанням трьох аналітик (довідників). Приклад бюджету продажів, побудованого на основі трьох аналітик "Продукти", "Філії" і "Канали збуту" представлений на малюнку 3.

Мал. 3. Приклад бюджету продажів, побудованого на основі трьох аналітик "Продукти", "Філії" і "Канали збуту" в OLAP-кубі програмного комплексу "Інтеграл"

Потрібно нагадати про те, що КУБ, який використовується для формування звітів, дозволяє виводити дані в різній послідовності. на малюнку 3 бюджет продажів спочатку "розгортається" по продуктам, потім по філіям, а потім по каналах збуту.

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

Мал. 4. Приклад бюджету продажів, побудованого на основі трьох аналітик "Продукти", "Канали збуту" і "Філії" в OLAP-кубі програмного комплексу "Інтеграл"

на малюнку 5 той же самий бюджет продажів "розгортається" спочатку по філіям, потім по продуктам, а потім по каналах збуту.

Мал. 5. Приклад бюджету продажів, побудованого на основі трьох аналітик "Філії", "Продукти" і "Канали збуту" в OLAP-КУБепрограммного комплексу "Інтеграл"

Насправді це не всі можливі варіанти виведення бюджету продажів.

Крім того, потрібно звернути увагу на те, що КУБ дозволяє працювати з ієрархічною структурою довідників. У представлених прикладах ієрархічними довідниками є "Продукти" і "Канали збуту".

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

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

Необхідно згадати ще про декілька можливості OLAP-КУБу.

У багатовимірному ієрархічному OLAP-кубі є кілька вимірів: тип рядка, дата, рядки, довідник 1, довідник 2 і довідник 3 (див. Мал. 6). Природно, в звіт виводиться стільки кнопок зі довідниками, скільки є в рядку бюджету, що містить максимальна кількість довідників. Якщо ні в одному рядку бюджету немає жодного довідника, то в звіті не буде жодної кнопки з довідниками.

Спочатку OLAP-КУБ будується по всіх вимірах. За замовчуванням при первісному побудові звіту вимірювання розташовані саме в тих областях, як показано на малюнку 6. Тобто такий вимір, як «Дата», розташовується в області вертикальних вимірів (вимірювання в області стовпців), вимірювання «Рядки», «Довідник 1», «Довідник 2» і «Довідник 3» - в області горизонтальних вимірів (вимірювання в області рядків), а вимір «Тип рядка» - в області «не розкривається» вимірювань (вимірювання в сторінкової області). Якщо вимір знаходиться в останній області, то дані в звіті не будуть «розкриватися» за цим виміром.

Кожне з цих вимірів можна помістити в будь-яку з трьох областей. Після перенесення вимірювань звіт миттєво перебудовується відповідно до нової конфігурацією вимірювань. Наприклад, можна поміняти місцями дату і рядки з довідниками. Або можна в вертикальну область вимірювань перенести один з довідників (див. Мал. 7). Іншими словами, звіт в OLAP-кубі можна «крутити» і вибирати той варіант виведення звіту, який є найбільш зручним для користувача.

Мал. 7. Приклад перебудови звіту після зміни конфігурації вимірювань програмного комплексу "Інтеграл"

Конфігурацію вимірів можна міняти або в основній формі КУБу, або в редакторі карти змін (див. Мал. 8). У цьому редакторі також можна мишкою перетягувати вимірювання з однієї області в іншу. Крім цього, можна міняти місцями вимірювання в одній області.

Крім того, в цій же формі можна налаштовувати деякі параметри вимірювань. По кожному вимірюванню можна налаштовувати розташування підсумків, порядок сортування елементів і назви елементів (див. Мал. 8). Також можна задавати, яку назву елементів виводити в звіт: скорочене (Name) або повне (FullName).

Мал. 8. Редактор карти вимірів програмного комплексу "Інтеграл"

Редагувати параметри вимірювань можна безпосередньо в кожному з них (див. Мал. 9). Для цього потрібно натиснути на піктограму, розташовану на кнопці поруч з назвою вимірювання.

Мал. 9. Приклад редагування довідника 1 Продукти і послуги в

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

Також в цьому редакторі можна сортувати елементи. Крім того, елементи можна перегруповують різними способами. Після такої перегрупування звіт миттєво перебудовується.

Мал. 10. Приклад виведення в звіті тільки однієї продуктової групи (папки) в програмному комплексі "ІНТЕГРАЛ"

У редакторі вимірювання можна оперативно створювати свої групи, перетягувати туди елементи з довідників і т.д. За замовчуванням автоматично створюється тільки група «Інші», але можна створювати і інші групи. Таким чином, за допомогою редактора вимірювань можна налаштовувати, які елементи довідників і в якому порядку потрібно виводити в звіт.

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

Насправді все такі зміни можна було зробити з самого початку при налаштуванні рядків.

Наприклад, за допомогою обмежень також можна задавати, які елементи або групи довідників потрібно виводити в звіт, а які - ні.

Примітка: Більш детально тема даної статті розглядається на семінарах-практикумах "Бюджетне управління підприємством" і "Постановка і автоматизація управлінського обліку" , Які проводить автор даної статті - Олександр Карпов.

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

У попередній статті даного циклу (див. № 2'2005) ми розповіли про основні нововведення аналітичних служб SQL Server 2005. Сьогодні ми докладніше розглянемо засоби створення OLAP-рішень, що входять в цей продукт.

Коротко про основи OLAP

режде ніж почати розмову про засоби створення OLAP-рішень, нагадаємо, що OLAP (On-Line Analytical Processing) це технологія комплексного багатовимірного аналізу даних, концепція якої була описана в 1993 році Е.Ф.Коддом, знаменитим автором реляційної моделі даних. В даний час підтримка OLAP реалізована в багатьох СУБД і інших інструментах.

OLAP-куби

Що являють собою OLAP-дані? Як відповідь на це питання розглянемо найпростіший приклад. Припустимо, в корпоративній базі даних якогось підприємства є набір таблиць, що містять відомості про продажі товарів або послуг, і на їх основі створено уявлення Invoices з полями Country (країна), City (місто), CustomerName (назва компанії-клієнта), Salesperson (менеджер з продажу), OrderDate (дата розміщення замовлення), CategoryName (категорія товару), ProductName (найменування товару), ShipperName (компанія-перевізник), ExtendedPrice (оплата за товар), при цьому останній із зазначених полів, власне, і є об'єктом аналізу .

Вибір даних з такого уявлення можна здійснити за допомогою наступного запиту:

SELECT Country, City, CustomerName, Salesperson,

OrderDate, CategoryName, ProductName, ShipperName, ExtendedPrice

FROM Invoices

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

SELECT Country, SUM (ExtendedPrice) FROM Invoices

GROUP BY Country

Результатом цього запиту буде одновимірний набір агрегатних даних (в даному випадку сум):

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
France	69185.48
	209373.6
	...

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

SELECT Country, ShipperName, SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName

Виходячи з результатів цього запиту можна створити таблицю наступного виду:

Такий набір даних називається зведеною таблицею (Pivot table).

SELECT Country, ShipperName, SalesPerson SUM (ExtendedPrice) FROM Invoices

GROUP BY COUNTRY, ShipperName, Year

На підставі результатів цього запиту можна побудувати тривимірний куб (рис. 1).

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

Ієрархії в вимірах

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

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

Створення OLAP-кубів в SQL Server 2005

SQL Server 2005 куби створюються з допомогою SQL Server Business Intelligence Development Studio. Цей інструмент являє собою спеціальну версію Visual Studio 2005, призначену для вирішення даного класу задач (а при наявності вже встановленої середовища розробки список шаблонів проектів поповнюється проектами, призначеними для створення рішень на основі SQL Sever і його аналітичних служб). Зокрема, для створення рішень на основі аналітичних служб призначений шаблон Analysis Services Project (рис. 3).

Для створення OLAP-куба в першу чергу слід вирішити, на основі яких даних його формувати. Найбільш часто OLAP-куби будуються на основі реляційних сховищ даних зі схемами «зірка» або «сніжинка» (про них ми розповідали в попередній частині статті). У комплекті поставки SQL є приклад такого сховища база даних AdventureWorksDW, для використання якої в якості джерела слід знайти в Solution Explorer папку Data Sources, вибрати пункт контекстного меню New Data Source і послідовно відповісти на питання відповідного майстра (рис. 4).

Потім рекомендується створити Data Source View уявлення, на основі якого буде створюватися куб. Для цього необхідно вибрати відповідний пункт контекстного меню папки Data Source Views і послідовно відповісти на питання майстра. Результатом зазначених дій стане схема даних, за допомогою яких буде побудовано уявлення джерел даних, при цьому в отриманій схемі замість вихідних можна вказати «дружні» імена таблиць (рис. 5).

Описаний таким чином куб можна перенести на сервер аналітичних служб, вибравши з контекстного меню проекту опцію Deploy, і здійснити перегляд його даних (рис. 7).

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

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

Мал. 8. Додавання обчислюється атрибута

Крім того, в кубах SQL Server 2005 можна здійснювати автоматичну угруповання або сортування членів вимірювання за значенням атрибута, визначати зв'язки між атрибутами, реалізовувати зв'язку «багато до багатьох», визначати ключові показники бізнесу, а також вирішувати багато інших завдань (подробиці про те, як виконуються всі ці дії, можна знайти в розділі SQL Server Analysis Services Tutorial довідкової системи даного продукту).

У наступних частинах цієї публікації ми продовжимо знайомство з аналітичними службами SQL Server 2005 і з'ясуємо, що нового з'явилося в області підтримки Data Mining.