Мал. 2.Зріз OLAP-куба

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

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

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

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

Тут " Країна", "Товар", "Рікє атрибутами або вимірами, а " Об'єм продажу- тим самим числовим значенням або мірою. Завданням аналітика, повторимося, є виявлення стійких взаємозв'язків між атрибутами та числовими параметрами. Подивившись на таблицю, можна помітити, що її легко можна перевести в три виміри: по одній із осей відкладемо країни, по іншій – товари, по третій – роки. А значеннями у цьому тривимірному масиві ми матимемо відповідні обсяги продажів.

Тривимірне подання таблиці. Сірим сегментом показано, що для Аргентини в 1988 даних немає

Саме такий тривимірний масив у термінах OLAP і називається кубом. Насправді, з погляду суворої математики кубом такий масив буде далеко не завжди: у справжнього куба кількість елементів у всіх вимірах має бути однаковим, а у кубів OLAP такого обмеження немає. Проте, незважаючи на ці деталі, термін "куби OLAP" через свою стислість і образність став загальноприйнятим. Куб OLAP зовсім не обов'язково має бути тривимірним. Він може бути і дво-, і багатовимірним - залежно від розв'язуваного завдання. Особливо запеклим аналітикам може знадобитися близько 20 вимірів - і серйозні OLAP-продукти саме на таку кількість і розраховані. Простіші настільні програми підтримують десь 6 вимірів.

Вимірювання OLAP-кубів складаються з так званих мітокчи членів (members). Наприклад, вимір "Країна" складається з міток "Аргентина", "Бразилія", "Венесуела" і так далі.

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

Однак куб сам для аналізу не придатний. Якщо ще можна адекватно уявити або зобразити тривимірний куб, то з шести - або дев'ятнадцятимірною справа значно гірша. Тому перед вживанняміз багатовимірного куба витягують звичайні двовимірні таблиці. Ця операція називається "розрізанням" куба. Термін цей, знову ж таки, образний. Аналітик як би бере і "розрізає" вимірювання куба за мітками, що його цікавлять. Цим способом аналітик отримує двовимірний зріз куба та з ним працює. Приблизно також лісоруби вважають річні кільця на спилі.

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

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

Приклад ієрархії

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

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

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

Відповісти на питання:

Що таке куб OLAP?

Що таке мітки конкретного виміру? Навести приклади.

Чи можуть заходи у кубі OLAP, містити нечислові значення.

Що таке сховище даних?

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

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

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

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

Як будують сховище?

• Вилучення – вилучення даних із зовнішніх джерел у зрозумілому форматі;
• Перетворення – перетворення структури вихідних даних у структури, зручні побудови аналітичної системи;

Повернемося до аналізу.

Що таке аналіз і для чого він потрібний?

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

OLAP

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

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

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

Багатовимірні поняття

Куб

• Дата замовлення
• Країна
• Місто
• Назва замовника
• Компанія-доставник
• Назва товару
• Кількість товару
• Сума замовлення

• Якою є сумарна вартість замовлень, зроблених клієнтами з певної країни?
• Яка сумарна вартість замовлень, зроблених клієнтами з певної країни та доставлених певною компанією?
• Яка сумарна вартість замовлень, зроблених клієнтами з певної країни у заданому році та доставлених певною компанією?

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

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

Якщо ж захочеться отримати самі дані, але у розрізі років, тоді з'явиться ще одне зміна, тобто. набір даних стане тривимірним (умовним тензором 3-го порядку або 3-мірним «кубом»).

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

Так ми приходимо до поняття багатовимірності та її втілення – багатовимірному кубу. Така таблиця називатиметься « таблицею фактів». Вимірювання або Осі куба ( dimensions) – це атрибути, координати яких – виражаються індивідуальними значеннями цих атрибутів, що у таблиці фактів. Тобто. наприклад, якщо інформація про замовлення велася в системі з 2003 по 2010 рік, то ця вісь складатиметься з 8 відповідних точок. Якщо замовлення приходять із трьох країн, то вісь країн міститиме 3 точки тощо. Незалежно від того, скільки країн закладено у довіднику Країн. Крапки на осі називаються її «членами» ( Members).

Самі агреговані дані в даному випадку назватимуся «заходами» ( Measure). Щоб уникнути плутанини з «вимірюваннями», останні краще називати «осями». Набір заходів утворює ще одну вісь «Міри» ( Measures). У ній стільки членів (точок), скільки заходів (агрегаційних стовпців) у таблиці фактів.

Члени вимірів або осей можуть бути об'єднані однією або декількома ієрархіями ( hierarchy). Що таке ієрархія, пояснимо на прикладі: міста із замовлень можуть бути об'єднані в райони, райони в області, області країни, країни в континенти чи інші утворення. Тобто. є ієрархічна структура - континент- країна-область-район-місто- 5 рівнів ( Level). Для району дані агрегуються по всіх містах, які до нього входять. Для області по всіх районах, що містять усі міста тощо. Навіщо потрібні кілька ієрархій? Наприклад, по осі з датою замовлення ми можемо хотіти групувати точки (тобто дні) за ієрархією Рік-Місяць-Деньабо по Рік-Тиждень-День: в обох випадках по три рівні. Очевидно, що Тиждень та Місяць по-різному групують дні. Бувають також ієрархії, кількість рівнів у яких не детермінована і залежить від даних. Наприклад, папки на комп'ютерному диску.

Агрегація даних може відбуватися з використанням кількох стандартних функцій: сума, мінімум, максимум, середня кількість.

MDX

Ми розглянемо його докладно тому, що це єдина мова, яка отримала статус стандартного в рамках загального стандарту протоколу XMLA, а по-друге тому, що існує його open-source реалізація у вигляді проекту Mondrian від компанії Pentaho. Інші системи OLAP-аналізу (наприклад, Oracle OLAP Option) зазвичай використовують розширення синтаксису мови SQL, втім, декларують підтримку і MDX.

Робота з аналітичними масивами даних передбачає лише їх читання і передбачає запис. Т.о. у мові MDX немає пропозицій для зміни даних, а є лише одна пропозиція вибірки – select.

В OLAP із багатовимірних кубів можна робити зрізи- Тобто. коли дані фільтруються по одній або декільком осях, або проекції- коли по одному або декільком осях куб «схлопується», агрегуючи дані. Наприклад, наш перший приклад із сумою замовлень із країн – є проекція куба на вісь Країни. MDX запит для цього випадку буде виглядати так:

Select ...Children on rows from
Що тут що?

Select– ключове словоі до синтаксису входить виключно для краси.
- Це назва осі. Всі власні імена в MDX пишуться в квадратних дужках.
- Це назва ієрархії. У нашому випадку – це ієрархія Країна-Місто
- Це назва члена осі на першому рівні ієрархії (тобто країни) All - це мета-член, що об'єднує всі члени осі. Такий мета-член є у кожній осі. Наприклад, у осі років є «Всі роки» тощо.
Children- Це функція члена. Кожен член має кілька доступних функцій. Таких, як Parent. Level, Hierarchy, що повертають відповідно предка, рівень ієрархії і саму ієрархію, до якої належить у разі член. Children – повертає набір членів-нащадків цього члена. Тобто. у разі – країни.
on rows– Вказує, як розмістити ці дані у підсумковій таблиці. У цьому випадку – у заголовку рядків. Можливі значення тут: on columns, on pages, on paragraphs і т.п. Можливо також вказівку просто за індексами, починаючи з 0.
from- Це вказівка ​​куба, з якого проводиться вибірка.

Що якщо нам не потрібні всі країни, а потрібна лише пара конкретних? Для цього можна в запиті вказати явно ті країни, які нам потрібні, а не вибирати всі функції Children.

Select ( ..., ... ) on rows from
Фігурні дужки в даному випадку – оголошення набору ( Set). Набір – це список, перелік членів з однієї осі.

Тепер напишемо запит для другого прикладу – висновок у розрізі доставника:

Select ...Children on rows .Members on columns from
Тут додалося:
- Вісь;
.Members- Функція осі, яка повертає всі члени на ній. Така ж функція є і в ієрархії і рівня. Т.к. у цій осі ієрархія одна, її вказівку можна опустити, т.к. рівень та ієрархії теж один, то можна виводити всі члени одним списком.

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

Виберіть ..Children on rows .Members on columns from where (.)
А де тут фільтрація?

where- ключове слово
- Це один член ієрархії . Повне ім'я з урахуванням усіх термінів було б таким: .. , Але т.к. Ім'я цього члена в рамках осі унікальне, всі проміжні уточнення імені можна опустити.

Чому член дати у дужках? Круглі дужки – це кортеж ( tuple). Кортеж – це один або кілька координат по різнимосям. Наприклад для фільтрації відразу по двох осях у круглих дужках ми перерахуємо два члени з різнихвимірювань через кому. Т. е. кортеж визначає «зріз» куба (або «фільтрацію», якщо така термінологія ближче).

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

Це потрібно, наприклад, щоб вивести в двовимірну таблицю результат тривимірного запиту.

Вибрати crossjoin(...Children, ..Children) on rows .Members on columns from where (.)
Crossjoin- Це функція. Вона повертає набір (set) кортежів (так, набір може містити кортежі!), Отриманий в результаті декартового твору двох наборів. Тобто. результуючий набір міститиме всі можливі поєднання країн і років. Заголовки рядків, таким чином, міститимуть пару значень: Країна-Рік.

Питання, а де вказівку які числові характеристики треба виводити? У разі використовується міра за умовчанням, задана при цьому куба, тобто. Сума замовлення. Якщо ми хочемо виводити інший захід, то згадуємо, що заходи – це члени виміру Measures. І діємо так само як і з іншими осями. Тобто. фільтрації запиту за одним із заходів виводитиме саме цей захід у осередках.

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

Обчислювані члени

With member. as '.CurrentMember / ..', FORMAT_STRING='0.00%' select ...Children on rows from where .
Обчислення відбувається в контексті осередку, у якого відомі всі його атрибути-координати. Відповідні координати (члени) можуть бути отримані функцією CurrentMember у кожної з кубічних осей. Тут треба розуміти, що вираз .CurrentMember / ..' не ділить один член на інший, а ділить відповідні агреговані данізрізів куба! Тобто. зріз поточною територією розділиться на зріз всіма територіями, тобто. сумарне значення всіх замовлень. FORMAT_STRING – визначає формат виведення значень, тобто. %.

Інший приклад обчислюваного члена, але вже по осі років:

With member. as ‘. - .’
Вочевидь, що у звіті буде одиниця, а різницю відповідних зрізів, тобто. різниця суми замовлень у ці два роки.

Відображення у ROLAP

Навігація

Drill– це деталізація звіту за допомогою зменшення ступеня агрегації даних, поєднане з фільтрацією по якійсь іншій осі (або кількох осях). Свердління буває декількох видів:

• drill-down– фільтрація по одній з вихідних осей звіту з виведенням детальної інформації щодо нащадків у рамках ієрархії обраного члена, що фільтрує. Наприклад, якщо є звіт щодо розподілу замовлень у розрізі Країн та Років, то при клацанні на 2007-му році виведеться звіт у розрізі тих самих Країн та місяців 2007 року.
• drill-aside– фільтрація під однією або декількома вибраними осями та зняття агрегації по одній або декільком іншим осям. Наприклад, якщо є звіт щодо розподілу замовлень у розрізі Країн та Років, то при натисканні на 2007-му році виведеться інший звіт у розрізі, наприклад, Країн та Постачальників з фільтрацією по 2007 році.
• drill-trough– зняття агрегації по всіх осях та одночасна фільтрація по них – дозволяє побачити вихідні дані з таблиці фактів, з яких отримано значення у звіті. Тобто. при клацанні за значенням осередку виводиться звіт із усіма замовленнями, які дали цю суму. Таке собі миттєве буріння в «надра» куба.

Теги: Додати теги

Головна Терміни Статті Курси Досвід компаній Блог Поради Завантажити Партнерам Контакти Акції

Статті > Автоматизація бюджетування та управлінського обліку >

Олександр Карпов, керівник проекту bud-tech.ru, автор серії книг «100% практичного бюджетування» та книги «Постановка та автоматизація управлінського обліку»

www.bud-tech.ru

Можливо, для когось використання 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). Природно, у звіт виводиться стільки кнопок із довідниками, скільки є у рядку бюджету, що містить максимальну кількість довідників. Якщо в жодному рядку бюджету немає жодного довідника, то у звіті не буде жодної кнопки з довідниками.

Мал. 6. Вимірювання OLAP-КУБу програмного комплексу «ІНТЕГРАЛ»

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

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

Мал. 7. Приклад перебудови звіту після зміни конфігурації вимірювань програмного комплексу «ІНТЕГРАЛ»

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

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

Мал. 8. Редактор карти вимірювань програмного комплексу «ІНТЕГРАЛ»

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

Мал. 9. Приклад редагування довідника 1 Продукти та послуги у програмному комплексі «ІНТЕГРАЛ»

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

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

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

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

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

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

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

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

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

Загальні відомості

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

Отримання даних та оновити відмінності

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

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

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

Не-OLAP дані можуть бути повернуті до Microsoft Excel як діапазон зовнішніх даних або звіт зведеної таблиці або зведена діаграма. Дані OLAP можуть бути повернуті до Excel лише у вигляді звіту зведеної таблиці або зведеної діаграми.

Фоновий запит

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

Запити з параметрами

Звіти зведених таблиць, засновані на джерелі даних OLAP, не підтримують використання запитів з параметрами.

Оптимізація пам'яті

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

Параметри поля сторінки

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

Відмінності до розрахунку

Параметри поля сторінки

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

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

Обчислювані поля та обчислювані елементи

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

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

OLAP-КУБ (динамічна управлінська звітність)

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

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

Проміжні висновки

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

Макет та дизайн відмінності

Вимірювання та заходи

При роботі зі звітом зведеної таблиці, що базується на вихідних даних OLAP, аналітик може використовуватися тільки як поля рядків, стовпців або сторінку. Заходи можуть використовуватися лише як поля даних. При перетягуванні вимірювання в область даних поля або вимірювання в рядок, стовпець або область полів сторінок з'являється таке повідомлення про помилку:

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

При активному звіті зведеної таблиці на основі вихідних даних OLAP панелі інструментів Зведена таблиця відображає значок поряд з кожним рядком поля. Значок показує, де Excel дозволить розмістити поле у ​​звіті зведеної таблиці. Якщо значок у лівому верхньому куті, поле є виміром, який можна перетягнути в рядок, стовпець або поле сторінки областей. Якщо значок у нижньому правому куті, поле є заходи, які можна перетягувати в область полів даних.

Вимірювання та заходи

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

Групування та розгрупування елементів

У Excel 2000 не можна групувати елементи у звіті зведеної таблиці, що базується на вихідних даних OLAP;

Перейменування полів

Звіти зведених таблиць, що базуються на вихідних даних OLAP, дозволяють відобразити найнижчий рівень даних, доступних на сервері OLAP.

Угруповання та розгрупування елементів

Для OLAP вихідних даних елементи в новому звіті зведеної таблиці спочатку з'являються відсортовані в порядку зростання на ім'я елемента.

Детальні дані

Команда Показати сторінки не доступна у звітах зведених таблиць на основі вихідних даних OLAP.

Show Items With No Data

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

Нижче наведено список питань щодо предмету Інформаційні технології в менеджменті МФПУ/МФПА «Синергія»

… – інтерактивна автоматизована система, яка допомагає…

OLAP у вузькому значенні слова трактується як …

OLAP-системи (online analytical processing) – це …

OLTP-системи виявилися мало придатними тому що …

Автоматизована система управління (автоматизована інформаційна система)

У програмі MS Project …

У системі OLTP оновлення даних відбувається…

Діаграма, призначена для аналізу плану робіт за допомогою методів…

Інформаційна система – це безліч взаємопов'язаних елементів.

Інформаційна технологія – це …

Інформаційне забезпечення – це …

Інформаційні технології на розвиток суспільства впливають наступним чином.

Інформаційний обмін у структурі органів управління організації про…

Виконавчі інформаційні системи (Executive Information Sys…

До ознак «малих» інформаційних систем належить …

До ознак інформаційних систем «середнього» масштабу належать …

Методи обробки інформації є …

Модульний принцип побудови бухгалтерських інформаційних систем.

На малюнку наведено фрагмент діаграми типу …, виконаної в про…

На мережевому графіку в програмі MS Project завдання із зовнішнього проекту.

На мережевому графіці в програмі MS Project завдання, яке не належить …

На мережевому графіці в програмі MS Project завдання, що зав...

На мережевому графіку в програмі MS Project зведене завдання

На склад та кількість автоматизованих робочих місць, що входять до …

Наука про інформаційну діяльність, інформаційні процеси та…

Організація інформаційної системи, при якій на віддаленому серв...

Основне призначення системи OLAP полягає у …

Основним призначенням ERP-систем є …

Основним призначенням методології MPS є …

Основними характеристиками OLAP-систем є …

Підсистема технічного забезпечення включає …

Послідовність технологічних етапів з модифікації первинно…

При мережевому об'єднанні персональних комп'ютерів у вигляді внутрішнього комп'ютера.

Прикладне програмне забезпеченняЕОМ призначено для …

Прикладом предметної інформаційної технології є …

Процес підтримки прийняття рішення має на увазі …

Мережа Масштабу Підприємства або Корпоративна Мережа – це інформаційна мережа.

Система штучного інтелекту є …

Системи обробки трансакцій – це системи, призначені для …

Системи обробки трансакцій відповідають …

Системи підтримки прийняття рішень (Decision Support Systems – DS...

Сучасні методи та засоби аналізу та планування процесів пр…

Створення інтегрованої автоматизованої інформаційної системи.

Створені інформаційні системи стають не придатними для використання.

Специфіка інформаційної системи підтримки керівництва виявляє…

Засобами традиційних OLTP-систем можна …

Структура корпоративних інформаційних систем є …

Прискорити та спростити роботу менеджерів з персоналу на фірмі позв..

Прискорити та спростити роботу менеджерів з персоналу на фірмі позв…

Фіксовані факти навколишнього світу, що сприймаються, являють зі…

Ланцюжок дій, що найбільш точно відображає процес управління пр...

Економічні завдання, які вирішуються в діалоговому режимі, характеризують…

Експертні системи призначені для обробки …

Є порушенням безпеки або відноситься до сфери безпеки.

OLAP - це просто

Дивовижне поруч …

По ходу роботи мені часто потрібно робити складні звіти, я весь час намагався знайти в них щось спільне, щоб складати їх більш просто і універсально, навіть написав і опублікував з цього приводу статтю «Дерево Осипова». Однак мою статтю розкритикували і сказали, що всі проблеми, які я порушив, давно вже вирішені в OLAP (www.molap.rgtu.ru) і порекомендували подивитися зведені таблиці в EXCEL.
Це виявилося настільки простим, що приклавши до цього свої геніальні рученята, у мене вийшла дуже проста схема для вивантаження даних з 1С7 або будь-якої іншої бази даних (надалі під 1С мається на увазі будь-яка база даних) та аналізу в OLAP.
Я думаю, багато схем вивантаження в OLAP занадто ускладнені, я вибираю простоту.

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

1. Для роботи потрібно лише EXCEL 2000.
2. Користувач може конструювати звіти без програмування.
3. Вивантаження із 1С7 у простому форматі текстового файлу.
4. Для бухгалтерських проводоквже є універсальна обробка для вивантаження, що працює у будь-якій конфігурації. Для вивантаження інших даних є обробки-зразки.
5. Можна заздалегідь сформулювати форми звітів, а потім застосовувати їх до різних даних без їх повторного конструювання.
6. Досить хороша продуктивність. На першому тривалому етапі дані спочатку імпортуються в EXCEL з текстового файлу і будується куб OLAP, потім досить швидко на основі цього куба може бути побудований будь-який звіт. Наприклад, дані про продаж товару по магазину за 3 місяці з асортиментом 6000 товарів, завантажуються в EXCEL 8 хвилин на Cel600-128M, рейтинг товарів і груп (OLAP-звіт) перераховується за 1 хвилину.
7. Дані вивантажуються з 1С7 повністю за вказаний період (всі рухи, за всіма складами, фірмами, рахунками). При імпорті в EXCEL можливе використання фільтрів, що завантажують для аналізу лише потрібні дані (наприклад, з усіх рухів, лише продажу).
8. В даний час розроблені способи аналізу рухів або залишків, але не рухів та залишків разом, хоча це в принципі можливо.

Що таке OLAP : (www.molap.rgtu.ru)

Припустимо, у вас є торгова мережа. Нехай дані про торгові операції вивантажені у текстовий файл або таблицю виду:

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

У 1С, наприклад, один рядок цієї таблиці буде відповідати одному рядку накладної, деякі поля (Контрагент, Дата) при цьому беруться з накладної шапки.

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

Ця таблиця є вихідною для OLAP-аналізу.

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

Як використовувати у себе :

Дані з дистрибутива розпакувати саме до каталогу c:\fixin (для торгової системи можливо в c:\reports). Прочитайте readme.txt та виконайте всі інструкції в ньому.

Спочатку ви повинні написати обробку, яка вивантажує дані з 1С текстовий файл (таблицю). Вам потрібно визначити склад полів, які вивантажуватимуться.
Наприклад, вже готова універсальна обробка, яка працює у будь-якій конфігурації та вивантажує для OLAP-аналізу проводки за період, вивантажує для аналізу наступні поля:

Дата|ДеньТижня|Тиждень|Рік|Квартал|Місяць|Документ|Фірма|Дебет|ДтНоменклатура
|ДтГрупаНоменклатура|ДтРозділНоменклатура|Кредит|Сума|ВалСумма|Кількість
|Валюта|ДтКонтрагенти|ДтГруппаКонтрагенти|КтКонтрагенти|КтГруппаКонтрагенти|
КтРізніОб'єкти

Де під префіксами Дт(Кт) йдуть субконто Дебету (Кредиту), Група - це група цього субконто (якщо є), Розділ - група групи, Клас - група розділу.

Для торгової системи поля можуть бути такі:

Напрямок|ВідРуху|ЗаНал|Товар|Кількість|Ціна|Сума|Дата|Фірма
|Склад|Валюта|Документ|ДеньТижня|Тиждень|Рік|Квартал|Місяць|Автор
|КатегоріяТовара|КатегоріяРуху|КатегоріяКонтрагенту|ГрупаТовара
|ВалСумма|Собівартість|Контрагент

Для аналізу даних використовують таблиці "Аналіз рухів.xls" ("Аналіз бухгалтерії.xls"). Відкриваючи їх, не відключайте макроси, інакше ви не зможете оновлювати звіти (вони запускаються макросами VBA). Вихідні дані ці файли беруть із файлів C:fixinmotions.txt (C:fixinbuh.txt), в іншому вони однакові.

Основи OLAP

Тому можливо, вам доведеться скопіювати ваші дані в один із цих файлів.
Щоб у EXCEL завантажилися дані, виберіть або напишіть свій фільтр і натисніть кнопку "Сформувати" на аркуші "Умови".
Аркуші звітів розпочинаються префіксом "Отч". Перейдіть на лист звіту, натисніть "Оновити" і дані звіту зміняться відповідно до останніх завантажених даних.
Якщо вас не влаштовують стандартні звіти, є лист ОтчШаблон. Скопіюйте його в новий аркуш і налаштуйте вигляд звіту, працюючи зі зведеною таблицею на цьому аркуші (про роботу зі зведеними таблицями в будь-якій книзі EXEL 2000). Рекомендую налаштовувати звіти на невеликому наборі даних, та був запускати їх у великому масиві, т.к. немає жодної можливості відключити перемалювання таблиць при кожній зміні макета звіту.

Технічні коментарі :

При вивантаженні даних із 1С користувач вибирає папку, куди йому вивантажувати файл. Я зробив це тому, що цілком можливо в найближчому майбутньому будуть вивантажуватися кілька файлів (залишки та рухи). Потім за натисканням у Провіднику кнопки "Надіслати" -> "На OLAP-аналіз в EXCEL 2000" дані копіюються з вибраної папки в папку C:\fixin. (щоб ця команда з'явилася у списку команди "Надіслати" і потрібно скопіювати файл "На OLAP-аналіз в EXCEL 2000.bat" у каталог C:\Windows\SendTo) Тому вивантажуйте дані відразу даючи імена файлам motions.txt або buh.txt.

Формат текстового файлу:
Перший рядок текстового файлу - заголовки колонок розділені "|", інші рядки містять значення цих колонок, розділені "|".

Для імпорту текстових файлів у Excel використовується Microsoft Query (складова частина EXCEL) для його роботи потрібна наявність у каталозі імпорту (C:\fixin) файлу shema.ini, що містить таку інформацію:

ColNameHeader=True
Format=Delimited(|)
MaxScanRows=3
CharacterSet=ANSI
ColNameHeader=True
Format=Delimited(|)
MaxScanRows=3
CharacterSet=ANSI

Пояснення: motions.txt і buh.txt - це назва розділу, що відповідає імені імпортованого файлу, описує, як імпортувати текстовий файл в Ексель. Інші параметри означають, що перший рядок містить назви колонок, роздільником колонок є "|", набір символів - Windows ANSI (для ДОС - OEM).
Тип полів визначається автоматично виходячи з даних, що містяться в колонці (дата, число, рядок).
Перелік полів не потрібно ніде описувати - EXCEL та OLAP самі визначать, які поля містяться у файлі за заголовками в першому рядку.

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

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

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

Мені довелося повозитися з VBA, щоб дані бралися з файлу з будь-яким списком полів, і можна було заздалегідь готувати бланки звітів.

Опис роботи в EXCEL (для користувачів):

Інструкція з використання звітів:
1. Надішліть на аналіз вивантажені дані (уточніть у адміністратора). Для цього натисніть правою кнопкою на папці, в яку у вас вивантажилися дані з 1С і виберіть команду "Надіслати", потім "На OLAP-аналіз в EXCEL 2000".
2. Відкрийте файл "Аналіз рухів.xls"
3. Виберіть значення фільтра, потрібні вам фільтри можна дописати на закладці "Значення".
4. Натисніть кнопку "Сформувати", при цьому вивантажені дані будуть завантажені в EXCEL.
5. Після завантаження даних у EXCEL, можна дивитися різні звіти. Для цього достатньо натиснути кнопку "Оновити" у вибраному звіті. Аркуші зі звітами розпочинаються на Відч.
Увага! Після того як ви зміните значення фільтра, потрібно ще раз натиснути кнопку "Сформувати", щоб дані в EXCEL перезавантажилися з файлу вивантаження у відповідність до фільтрів.

Обробки з демо-прикладу:

Обробка motionsbuh2011.ert – остання версіявивантаження проводок із Бухгалтерії 7.7 для аналізу в Excel. У ній є галочка «Приєднати до файлу», яка дозволяє вивантажувати дані частинами за періодами, приєднуючи їх у той самий файл, а не вивантажуючи в один і той же файл заново:

Обробка motionswork.ert вивантажує дані про продаж для аналізу в Excel.

Приклади звітів :

Шахівка з проводок:

Завантаженість операторів за видами накладних:

P.S. :

Зрозуміло, що за аналогічною схемою можна організувати вивантаження даних із 1С8.
У 2011 році до мене звертався користувач, якому потрібно було доопрацювати цю обробку в 1С7, щоб вона вивантажувала великі обсяги даних, я знайшов аутсорсера та виконав цю роботу. Отже, розробка цілком актуальна.

Обробку motionsbuh2011.ert доопрацьовано, щоб справлятися з вивантаженням великого обсягу даних.

Перше чітке визначення OLAP(On-line Analytical Processing) запропоновано в 1993 Е.Ф.Коддом (E.F.Codd) у статті, опублікованій за підтримки Arbor Software (тепер - Hyperion Software). Стаття включала 12 правил, які вже стали широко відомими і описані на сайті будь-якого постачальника OLAP додатків. Пізніше, в 1995 році, до них були додані ще шість менш відомих правил, усі вони були поділені на чотири групи та названі "характеристиками" (features). Ось ці правила, що дають визначення OLAP додатки з коментарями Найджела Пендса (Nigel Pendse), одного із творців сайту OLAP Report.

Основні характеристики OLAP включають:

1. Багатомірність моделі даних. З цим твердженням мало хто сперечається і воно вважається основною характеристикою OLAP. Частиною цієї вимоги вважається можливість побудови різних проекцій та розрізів моделі.

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

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

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

5. Архітектура «клієнт-сервер». Кодд вважає, що не тільки кожен продукт повинен бути клієнт-серверним, але й кожна серверна компонента OLAP продуктів повинна бути достатньо інтелектуальною для того, щоб різні клієнти могли бути підключені з мінімальними зусиллями і програмуванням. Це набагато складніший тест, ніж проста клієнт-серверна архітектура і відносно мало продуктів проходить його. Ми могли б заперечити, що цей тест, можливо, складніше, ніж треба, і не варто диктувати розробникам архітектуру системи.

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

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

Спеціальні характеристики

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

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

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

11. Обробка відсутніх значень. Усі відсутні значення мають бути проігноровані під час аналізу, незалежно від їхнього джерела.

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

12. Гнучка побудова звітів. Різні вимірювання повинні вибудовуватися будь-яким способом відповідно до потреб користувача. Більшість продуктів відповідає цій вимогі в рамках спеціальних редакторів звітів. Хотілося б, щоб такі можливості були доступні і в інтерактивних засобах перегляду, але це зустрічається значно рідше. Це одна з причин, через яку ми вважаємо за краще, щоб функціонал аналізу та побудови звітів був об'єднаний в одному модулі.

1. Поняття куба olap

13. Стабільна продуктивність при побудові звітів. Це означає, що продуктивність системи при побудові звітів має істотно падати зі збільшенням розмірності чи величини бази даних.

14. Автоматичне регулювання фізичного рівня. OLAP система повинна автоматично регулювати фізичну структуру для адаптації її до типу та структури моделі.

Управління розмірністю

15. Загальна функціональність. Усі виміри повинні мати однакові можливості у структурі та функціональності.

16. Необмежену кількість вимірювань та рівнів агрегування. Власне, під необмеженим числом Кодд передбачає 15-20, тобто. число, що явно перевищує максимальні потреби аналітика.

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

Подробиці про продукти Hyperion - на сайті www.hyperion.ru

Версія для друку

назад

10.8 Робота зі зведеними таблицями (об'єкт PivotTable)

Об'єкт Excel.PivotTable, програмна робота зі зведеними таблицями та кубами OLAP в Excel засобами VBA, об'єкт PivotCache, створення макета зведеної таблиці

У процесі роботи більшості підприємств накопичуються звані необроблені дані (raw data) про діяльність. Наприклад, для торгового підприємства можуть накопичуватися дані про продажі товарів - з кожної купівлі окремо, для підприємств стільникового зв'язку - статистика навантаження на базові станції тощо. Найчастіше менеджменту підприємства необхідна аналітична інформація, що генерується з урахуванням необробленої - наприклад, порахувати внесок кожного виду товару у доходи підприємства чи якість обслуговування у зоні даної станції. З необробленої інформації такі відомості отримати дуже важко: потрібно виконувати дуже складні SQL-запити, які виконуються довго і часто заважають поточній роботі. Тому все частіше нині необроблені дані зводяться спочатку у сховище архівних даних - Data Warehouse, а потім - у куби OLAP, які дуже зручні для інтерактивного аналізу. Найпростіше уявити куби OLAP як багатовимірні таблиці, у яких замість стандартних двох вимірів (стовпці і рядки, як і звичайних таблицях), вимірів може бути дуже багато. Зазвичай для опису вимірювань у кубі використовується термін «у розрізі». Наприклад, відділу маркетингу може бути потрібна інформація у тимчасовому розрізі, у регіональному розрізі, у розрізі типів продукту, у розрізі каналів продажів тощо. За допомогою кубів (на відміну від стандартних SQL-запитів) дуже просто отримувати відповіді на запитання на кшталт «скільки товарів такого типу було продано в четвертому кварталі минулого року в Північно-Західному регіоні через регіональних дистриб'юторів.

Звичайно, у звичайних базах даних такі куби не створити. Для роботи з кубами OLAP потрібні спеціалізовані програмні продукти. Разом із SQL Server поставляється база даних OLAP від ​​Microsoft, яка називається Analysis Services. Є OLAP-рішення від Oracle, IBM, Sybase і т.п.

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

Російською він називається Зведена таблиця(На графічному екрані він доступний через меню Дані -> Зведена таблиця), а англійською - Pivot Table. Відповідно, об'єкт, який представляє цей клієнт, називається PivotTable. Необхідно відзначити, що він вміє працювати не тільки з кубами OLAP, але і зі звичайними даними в таблицях Excel або баз даних, але багато можливостей при цьому втрачаються.

Зведена таблиця та об'єкт PivotTable - це програмні продукти компанії Panorama Software, які були придбані Microsoft і інтегровані в Excel.

Тому робота з об'єктом PivotTable дещо відрізняється від роботи з іншими об'єктами Excel. Здогадатися, що треба зробити, часто буває непросто. Тому рекомендується для отримання підказок активно використовувати макрорекордер. У той самий час під час роботи зі зведеними таблицями користувачам часто доводиться виконувати одні й самі повторювані операції, тому автоматизація у багатьох ситуаціях необхідна.

Як виглядає програмна робота зі зведеною таблицею?

Перше, що нам потрібно зробити, - створити об'єкт PivotCache, який представлятиме набір записів, отриманих з джерела OLAP. Дуже умовно цей об'єкт PivotCache можна порівняти з QueryTable. Для кожного об'єкта PivotTable можна використовувати лише один об'єкт PivotCache. Створення об'єкта PivotCache здійснюється за допомогою методу Add() колекції PivotCaches:

Dim PC1 As PivotCache

Set PC1 = ActiveWorkbook.PivotCaches.Add(xlExternal)

PivotCaches - стандартна колекція, і з методів, які заслуговують на докладний розгляд, в ній можна назвати тільки метод Add(). Цей метод приймає два параметри:

• SourceType- обов'язковий визначає тип джерела даних для зведеної таблиці. Можна вказати створення PivotTable на основі діапазону Excel, даних з бази даних, у зовнішньому джерелі даних, інший PivotTable і т.п. На практиці зазвичай OLAP є сенс використовувати лише тоді, коли даних багато – відповідно потрібно спеціалізоване зовнішнє сховище (наприклад, Microsoft Analysis Services). У цій ситуації вибирається значення xlExternal.
• SourceData- обов'язковий у всіх випадках, крім тих, коли значення першого параметра - xlExternal. Власне, визначає той діапазон даних, на основі якого і створюватиметься PivotTable. Зазвичай приймає об'єкт Range.

Наступне завдання – налаштувати параметри об'єкта PivotCache. Як мовилося раніше, цей об'єкт дуже нагадує QueryTable, і набір властивостей і методів він дуже схожий. Деякі найважливіші властивості та методи:

• ADOConnection- можливість повернути об'єкт ADO Connection, який автоматично створюється для підключення зовнішнього джерела даних. Використовується для додаткового налаштування властивостей підключення.
• Connection- працює так само, як і однойменна властивість об'єкта QueryTable. Може приймати рядок з'єднання, готовий об'єкт Recordset, текстовий файл, Web-запит. файл Microsoft Query. Найчастіше під час роботи з OLAP прописується рядок підключення безпосередньо (оскільки отримувати об'єкт Recordset, наприклад зміни даних, великого сенсу немає - джерела даних OLAP практично завжди доступні лише читання). Наприклад, налаштування цієї властивості для підключення до бази даних Foodmart (навчальна база даних Analysis Services) на сервері LONDON може виглядати так:

PC1.Connection = "OLEDB; Provider = MSOLAP.2; Data Source = LONDON1; Initial Catalog = FoodMart 2000"

• властивості CommandTypeі CommandTextтак само описують тип команди, яка передається на сервер баз даних, і текст самої команди. Наприклад, щоб звернутися на куб Sales і отримати його повністю в кеш на клієнті, можна використовувати код виду

PC1.CommandType = xlCmdCube

PC1.CommandText = Array(«Sales»)

• властивість LocalConnectionдозволяє підключитися до локального куба (файлу *.cub), створеного засобами Excel. Звичайно, такі файли для роботи з "виробничими" обсягами даних використовувати дуже не рекомендується - тільки для створення макетів і т.п.
• властивість MemoryUsedповертає кількість оперативної пам'яті, що використовується PivotCache. Якщо PivotTable на основі цього PivotCache ще не створена і не відкрита, повертає 0. Можна використовувати для перевірок, якщо ваша програма працюватиме на слабких клієнтах.
• властивість OLAPповертає True, якщо PivotCache підключено до сервера OLAP.
• OptimizeCache- Можливість оптимізувати структуру кешу. Початкове завантаження даних проводитиметься довше, але потім швидкість роботи може зрости. Для джерел OLE DB не працює.

Інші властивості об'єкта PivotCache збігаються з аналогічними властивостями об'єкта QueryTable і тому тут розглядатися не будуть.

Головний метод об'єкта PivotCache – це метод CreatePivotTable(). За допомогою цього і проводиться наступний етап - створення зведеної таблиці (об'єкта PivotTable). Цей метод приймає чотири параметри:

• TableDestination- Єдиний обов'язковий параметр.

  Приймає об'єкт Range, у верхній лівий кут якого буде розміщена зведена таблиця.

• TableName- Ім'я зведеної таблиці. Якщо не вказано, автоматично згенерується ім'я виду «Зведена Таблиця1».
• ReadData- якщо встановити в True, весь вміст куба буде автоматично поміщено в кеш. З цим параметром потрібно бути дуже обережним, оскільки неправильне застосування може різко збільшити навантаження на клієнта.
• DefaultVersion- ця властивість зазвичай не вказується. Дозволяє визначити версію створюваної зведеної таблиці. За замовчуванням використовується найсвіжіша версія.

Створення зведеної таблиці в першому осередку першого аркуша книги може виглядати так:

PC1.CreatePivotTable Range («A1»)

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

• область стовпців- у ній містяться ті виміри («розріз», у якому аналізуватимуться дані), членів яких менше;
• область рядків- ті виміри, членів яких більше;
• область сторінки- ті виміри, за якими потрібно лише проводити фільтрацію (наприклад, показати дані тільки по такому регіону або тільки за такий рік);
• область даних- власне, центральна частина таблиці. Ті числові дані (наприклад, сума продажів), які ми аналізуємо.

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

Крім того, це може тривати певний час. Тому часто потрібно розмістити дані у зведеній таблиці програмним чином. Ця операція здійснюється за допомогою об'єкта CubeField. Головна властивість цього об'єкта - Orientation, воно визначає, де буде те чи інше поле. Наприклад, поміщаємо вимір Customers в область стовпців:

PT1.CubeFields («»).Orientation = xlColumnField

Потім - вимір Time в область рядків:

PT1.CubeFields («»).Orientation = xlRowField

Потім - вимір Product в область сторінки:

PT1.CubeFields («»).Orientation = xlPageField

І нарешті, показник (числові дані для аналізу) Unit Sales:

PT1.CubeFields(«.»).Orientation = xlDataField

Тепер зведена таблиця створена і з нею можна працювати. Однак часто необхідно виконати ще одну операцію – розкрити потрібний рівень ієрархії виміру. Наприклад, якщо нас цікавить поквартальний аналіз, потрібно розкрити рівень Quarter виміру Time (за замовчуванням показується лише найвищий рівень). Звичайно, користувач може це зробити самостійно, але не завжди можна розраховувати, що він здогадається, куди клацнути мишею. Програмним чином розкрити, наприклад, ієрархію вимірювання Time на рівень кварталів для 1997 можна за допомогою об'єктів PivotField і PivotItem:

PT1.PivotFields(«.»).PivotItems(«.»).DrilledDown = True

/ У кубістичній манері. Застосування OLAP-кубів у практиці управління великих компаній

Вконтакте

Однокласники

Костянтин Токмачов, системний архітектор

У кубістичній манері.
Застосування OLAP-кубів у практиці управління великих компаній

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

Про користь бізнес-аналітики

У контурі управління корпорацією між «сирими» даними та «важелями» на керований об'єкт розташовуються «показники роботи» – KPI. Вони утворюють хіба що «приладове табло», що відбиває стан різних підсистем керованого об'єкта. Оснастити фірму інформативними показниками роботи та контролювати їх розрахунок та отримані значення – праця бізнес-аналітика. Істотну допомогу в організації аналітичної роботи корпорації здатні надати автоматизовані служби аналізу, такі як утиліта MS SQL Server Analysis Services (SSAS) та її головний диспозитив – OLAP-куб.

Прямо тут слід зробити ще одне зауваження. Скажімо, в американській традиції спеціальність, орієнтована працювати з OLAP-кубами, називається BI (Business Intelligence). Не повинно бути жодних ілюзій, ніби американське BI відповідає російській «бізнес-аналітик». Без образ, але нерідко наш бізнес-аналітик – це «недобухгалтер» і «недопрограміст», фахівець з нечіткими знаннями та з невеликим окладом, який реально не має жодного власного інструментарію та методології.

Фахівець BI – це, по суті, прикладний математик, висококласний фахівець, який ставить на озброєння фірми сучасні математичні методи (те, що називалося Operations Researh – методи дослідження операцій). BI більше відповідає колишньому колись СРСР спеціальності «системний аналітик», що випускалася факультетом ВМК МДУ ім. М.В. Ломоносова. OLAP-куб та служби аналізу можуть стати перспективною основою робочого місця російського бізнес-аналітика, можливо після деякого підвищення його кваліфікації у бік американського BI.

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

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

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

Нарешті, програміст, який колись (завдяки освіті) провідником передових технічних ідей зі сфери науки у сфері бізнесу, перетворився на пасивного виконавця фантазій бухгалтера та менеджера, тож вже не рідкість, коли ІТ-відділами корпорацій підрулюють бухгалтери і взагалі всі, кому не ліньки. Безініціативний, малограмотний, але щодо високооплачуваний програміст 1С – справжній бич російських корпорацій. (Майже як вітчизняний футболіст.) Про так звані «економісти та юристи» я вже не кажу, про них давно все сказано.

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

Переваги OLAP-кубів

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

Деяке уявлення про OLAP-
кубі може дати "зведена таблиця" MS Excel. У цих об'єктів схожа логіка та схожі інтерфейси. Але, як видно з статті, функціональність OLAP незрівнянно багатша, а продуктивність незрівнянно вища, отже «зведена таблиця» залишається локальним настільним продуктом, тоді як OLAP – продукт корпоративного рівня.

Чому OLAP-куб добре підходить для вирішення аналітичних завдань? OLAP-куб влаштований так, що всі показники у всіх можливих розрізах заздалегідь обчислені (цілком або частково), і користувачеві залишається лише «витягнути» мишею необхідні показники (вимірювання measures) та розрізи (розмірності dimensions), а програмі – перемалювати таблички.

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

Формулювання аналітики можливе у трьох варіантах: це або поле бази даних (вірніше, поле warehouse), або розрахункове поле calculation, що визначається на рівні дизайну куба, або вираз мови MDX при інтерактивній роботі з кубом.

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

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

Наведемо приклад. Припустимо, керівник контролює дебіторську заборгованість. Поки KPI простроченої дебіторської заборгованості «горить зеленим світлом», отже, все гаразд, жодних управлінських дій не потрібно. Якщо колір змінився на жовтий або червоний - щось не так: розрізаємо KPI по відділах продажів і одразу бачимо підрозділи "у червоному". Наступний розріз менеджерів – і продавець, чиї клієнти прострочили платежі, визначено. (Далі суму прострочення можна розрізати за покупцями, за термінами тощо). Керівник корпорації може прямо звернутися до порушників на будь-якому рівні. Але взагалі той же KPI (на своїх рівнях ієрархії) бачать і начальники відділів, і менеджери з продажу. Тому, щоб виправити ситуацію, їм навіть не потрібно чекати «виклику на килим»… Зрозуміло, сам KPI за змістом не обов'язково має бути сумою прострочення – він може бути середньозваженим терміном прострочення чи взагалі швидкістю обороту дебіторської заборгованості.

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

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

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

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

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

OLTP + OLAP: контур зворотного зв'язку в ланцюзі управління фірмою

Тепер розглянемо загальну ідею OLAP-кубів та їх точку застосування в управлінському ланцюзі корпорації. Термін OLAP (OnLine Analytical Processing) був запроваджений британським математиком Едгаром Коддом на додаток до раніше введеного терміну OLTP (OnLine Transactions Processing). Про це буде сказано, але Є. Кодд, зрозуміло, запропонував як терміни, а й математичні теорії OLTP і OLAP. Не вдаючись до деталей, у сучасній інтерпретації OLTP – це реляційна база даних, розглянута як механізм реєстрації, зберігання та вибірки інформації.

Методологія вирішення

Такі ERP-системи (Enterprice Resource Planning), як 1С7, 1С8, MS Dynamics AX, мають програмні інтерфейси, орієнтовані на користувача (введення та коригування документів тощо), та реляційну базу даних (DB) для зберігання та вибірки інформації , представлена ​​сьогодні програмними продуктами типу MS SQL Server (SS).

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

Але щоб керувати процесом, недостатньо реєструвати інформацію про нього. Процес має бути представлений у вигляді системи числових показників (KPI), що характеризують його перебіг. Крім того, для показників мають бути визначені допустимі інтервали значень. І тільки якщо значення показника виходить за межі допустимого інтервалу, має бути керуючий вплив.

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

Окрім звичної системи реєстрації інформації методом OLTP, потрібна ще одна система - система аналізу зібраної інформації. Ця надбудова, яка в контурі керування відіграє роль зворотного зв'язку між керівництвом та об'єктом керування, є системою OLAP або, коротше кажучи, OLAP-куб.

Як програмну реалізацію OLAP ми розглядатимемо утиліту MS Analysis Services, що входить до складу стандартної поставки MS SQL Server, скорочено SSAS. Зазначимо, що за задумом Е. Кодда OLAP-куб в аналітиці повинен дати ту саму вичерпну свободу дій, яку система OLTP та реляційна база даних (SQL Server) дають у зберіганні та вибірці інформації.

Матеріально-технічне забезпечення OLAP

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

Вважатимемо, що корпорація використовує ERP-систему, наприклад, 1С7 або 1С8, в рамках якої в звичайному порядку йде реєстрація інформації. База даних цієї ERP-системи розміщується на якомусь сервері та підтримується програмою MS SQL Server.

Вважатимемо також, що на іншому сервері встановлено матзабезпечення, що включає MS SQL Server з утилітою MS Analysis Services (SSAS), а також програми MS SQL Server Management Studio, MS C#, MS Excel та MS Visual Studio. Ці програми разом утворюють необхідний контекст: інструментарій і необхідні інтерфейси розробника OLAP-кубів.

На сервері SSAS встановлена ​​програма blat, що вільно розповсюджується, викликана (з параметрами) з командного рядката забезпечує поштовий сервіс.

На робочих станціях співробітників, в рамках локальної мережі, серед іншого встановлені програми MS Excel (версії щонайменше 2003), і навіть, можливо, спеціальний драйвер забезпечення роботи MS Excel з MS Analysis Services (якщо лише відповідний драйвер не включено до MS Excel).

Для визначеності вважатимемо, що на робочих станціях працівників встановлено операційна система Windows XP, а серверах – Windows Server 2008. Крім того, нехай як SQL Server використовується MS SQL Server 2005, причому на сервері з OLAP-кубом встановлені Enterprise Edition (EE) або Developer Edition (DE). У цих редакціях можна використовувати т.зв. «напівадитивні заходи», тобто. додаткові агрегатні функції (статистики), відмінні від звичайних сум (наприклад, екстремум чи середнє значення).

Дизайн OLAP-куба (OLAP-кубізм)

Скажемо кілька слів про дизайн самого OLAP-куба. На мові статистики OLAP-куб - це безліч показників роботи, розрахованих у всіх необхідних розрізах, наприклад, показник відвантаження в розрізах по покупцям, товарам, дат і т.п. Через прямий переклад з англійської в російській літературі по OLAP-кубах показники називаються «заходами», а розрізи – «розмірностями». Це математично коректний, але синтаксично і семантично не дуже вдалий переклад. Російські слова «міра», «вимірювання», «розмірність» майже не відрізняються за змістом та написанням, тоді як англійські «measure» і «dimension» відмінні і за написанням і змістом. Тому ми віддаємо перевагу аналогічним за змістом традиційним російським статистичним термінам «показник» та «розріз».

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

У цій схемі OLAP і OLTP немає загальних таблиць, і аналітики OLAP розраховуються максимально детально на стадії оновлення куба (Process), попередньої стадії використання. Ця схема називається MOLAP (Multidimensional OLAP). Її мінуси – асинхронність з ERP та великі витрати пам'яті.

Хоча формально OLAP-куб можна побудувати з використанням як джерело даних всіх (тисяч) таблиць реляційної бази даних ERP-системи та всіх (сот) їх полів як показники або розрізи, реально цього робити не варто. Навпаки. Для завантаження в куб правильніше підготувати окрему базу даних, яка називається «вітрина» або «сховище» (warehouse).

Декілька причин змушують вчинити саме так.

• По перше,прив'язка OLAP-куба до таблиць реальної базиданих, напевно, створить технічні проблеми. Зміна даних у таблиці може ініціювати оновлення куба, а оновлення куба – не обов'язково швидкий процес, тому куб буде в стані перманентної перебудови; при цьому ще процедура оновлення куба може блокувати (при читанні) дані таблиць бази, гальмуючи роботу користувачів реєстрації даних в ERP-системі.
• По-друге, наявність надто великої кількості показників та розрізів різко збільшить область зберігання куба на сервері. Не забудемо, що в OLAP-кубі зберігаються не тільки вихідні дані, як в OLTP-системі, а ще й усі показники, підсумовані за всіма можливими розрізами (і навіть за всіма поєднаннями всіх розрізів). Крім того, відповідно, сповільняться швидкість оновлення куба і врешті-решт швидкість побудови та оновлення аналітик і заснованих на них звітів користувача.
• По-третє, дуже багато полів (показників і розрізів) створить проблеми в інтерфейсі розробника OLAP, т.к. списки елементів стануть неоглядними.
• По-четверте, OLAP-куб дуже чутливий до порушень цілісності даних. Куб не може бути побудований, якщо ключові дані не знаходяться за посиланням, прописаним у структурі зв'язків полів куба. Тимчасове чи постійне порушення цілісності, незаповнені поля – звичайна справа у базі даних ERP-системи, але це категорично не годиться для OLAP.

Можна ще додати, що ERP-систему та OLAP-куб слід розташовувати на різних серверах, щоб розділити навантаження. Але тоді за наявності загальних таблиць для OLAP та OLTP виникає ще й проблема мережного трафіку. Практично нерозв'язні проблеми з'являються в цьому випадку при необхідності консолідації в один OLAP-куб декількох різнорідних ERP-систем (1С7, 1С8, MS Dynamics AX).

Напевно, можна й надалі нагромаджувати технічні проблеми. Але найголовніше, згадаємо, що на відміну від OLTP, OLAP – не засіб реєстрації та зберігання даних, а засіб аналітики. Це означає, що не потрібно "про всяк випадок" вантажити і вантажити "брудні" дані з ERP в OLAP. Навпаки, потрібно спочатку виробити концепцію управління фірмою, хоча б на рівні системи KPI, і далі сконструювати прикладне сховище даних (warehouse), розташоване на тому ж сервері, що і OLAP-куб, і невелика рафінована кількість даних, що містить, з ERP, необхідних для управління .

Не пропагуючи погані звички, OLAP-куб щодо OLTP можна уподібнити відомому «перегінному кубу», за допомогою якого з «забрудненої маси» реальної реєстрації витягується «чистий продукт».

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

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

Архітектура рішення

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

На сервері OLAP ми створюємо образи (порожні копії) бази даних всіх цих ERP-систем. На ці порожні копії ми періодично виконуємо часткову реплікацію баз даних відповідних активно працюючих ERP.

Далі запускаються SP (stored procedure), які на тому ж сервері OLAP без мережного трафіку на основі часткових реплік баз даних ERP-систем створюють (або поповнюють) сховище (warehouse) – джерело даних OLAP-куба.

Потім запускається стандартна процедура оновлення/побудови куба за даними warehouse (операція Process в інтерфейсі SSAS).

Прокоментуємо окремі моменти технології. Яку роботу виконують SP?

В результаті часткової реплікації в образі деякої ERP-системи на сервері OLAP з'являються актуальні дані. До речі, часткова реплікація може виконуватись двома способами.

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

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

Звичайно, можна не копіювати рядки таблиць, але тільки додавати нові записи. Однак це створює серйозні незручності при врахуванні редакцій ERP «заднім числом», що часто зустрічається в системах, що реально працюють. Так що простіше, не мудруючи лукаво, копіювати всі записи (або оновлювати «хвіст», починаючи з деякої дати).

Далі, головне завдання SP – перетворити дані ERP-систем до формату warehouse. Якщо є лише одна ERP-система, то завдання перетворення в основному зводиться до викопування і, можливо, переформатування потрібних даних. Але якщо в тому самому OLAP-кубі необхідно консолідувати кілька ERP-систем різної структури, то перетворення ускладнюються.

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

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

Приділимо деяку увагу архітектурі сховища warehouse. Зазвичай схему OLAP-куба представляють як «зірки», тобто. як таблицю даних, оточену «променями» довідників – таблицями значень вторинних ключів. Таблиця – це блок показників, довідники – це їх розрізи. При цьому довідник може бути довільним незбалансованим деревом або збалансованою ієрархією, наприклад, багаторівневою класифікацією товарів або контрагентів. У OLAP-кубі числові поля таблиці даних із warehouse автоматично стають «показниками» (або вимірами measures), а за допомогою таблиць вторинних ключів можуть бути визначені розрізи (або розмірності dimensions).

Це наочне «педагогічне» опис. Насправді архітектура OLAP-куба може бути значно складнішою.

По-перше, warehouse може складатися з кількох «зірочок», можливо, пов'язаних через загальні довідники. У цьому випадку OLAP-куб буде об'єднання кількох кубів (кілька блоків даних).

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

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

По-четверте, на базі існуючих показників та розрізів при використанні виразу мови MDX можуть бути визначені нові показники (calculations). Важливо, нові куби, нові показники, нові розрізи автоматично повністю інтегровані з вихідними елементами. Слід зазначити, що невдало сформульовані показники calculations і ієрархічні розрізи можуть помітно загальмувати роботу OLAP-куба.

MS Excel як інтерфейс з OLAP

Окремий інтерес представляє інтерфейс користувача з OLAP-кубами. Звичайно найбільш повний інтерфейс надає сама утиліта SSAS. Це і інструментарій розробника OLAP-кубів, інтерактивний конструктор звітів, і вікно інтерактивної роботи з OLAP-кубом за допомогою запитів на мові MDX.

Крім самого SSAS, існує багато програм, що забезпечують інтерфейс з OLAP, які більшою чи меншою мірою охоплюють їх функціональність. Але серед них є одна, яка, на наш погляд, має незаперечні переваги. Це MS Excel.

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

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

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

Щонічний цикл обробки facubi

Тепер опишемо щоденний (щонощовий) обчислювальний цикл експлуатації OLAP. Розрахунок ведеться під контролем програми facubi, написаної на C# 2005 та запускається за допомогою Task Scheduler на сервері з warehouse та SSAS. На початку facubi звертається до інтернету та зчитує поточні курси валют (використовуються для представлення низки показників у валюті). Далі виконуються такі действия.

По-перше, facubi запускає SP, що виконують часткову реплікацію баз даних різних ERP-систем (елементів холдингу), доступних у локальній мережі. Реплікація виконується, як ми говорили, на заздалегідь підготовлені подвір'я – образи віддалених ERP-систем, розташовані на сервері SSAS.

По-друге, за допомогою SP виконується відображення з реплік ERP на сховище warehouse - особливу DB, яка є джерелом даних OLAP-куба і розташована на сервері SSAS. При цьому вирішуються три основні завдання:

• дані ERPпідбиваються під необхідні формати куба; мова йде і про таблиці, і про поля таблиць. (Іноді необхідну таблицю потрібно «виліпити», скажімо, з кількох аркушів MS Excel.) Аналогічні дані можуть мати різний формат у різних ERP, наприклад, ключові поля ID у довідниках 1С7 мають 36-значний символьний код довжиною 8, а поля _idrref у довідниках 1С8 - шістнадцяткові числа довжиною 32;
• по ходу обробки ведеться логічний контроль даних (зокрема прописування «умовчань» default дома пропущених даних, де це можливо) і контроль цілісності, тобто. перевірка наявності первинних та вторинних ключів у відповідних класифікаторах;
• консолідація кодів об'єктів, що мають один і той же зміст у різних ERP. Наприклад, відповідні елементи довідників різних ERP можуть мати той самий сенс, скажімо, це один і той же контрагент. Завдання консолідації кодів вирішується за допомогою побудови таблиць мепінгу, де різні коди тих самих об'єктів приводяться до єдності.

По-третє, facubi запускає стандартну процедуру поновлення даних куба Process (зі складу процедур утиліти SSAS).

Згідно з контрольними списками, програма facubi розсилає поштові повідомлення про хід виконання етапів обробки.

Виконавши facubi, Task Scheduler запускає кілька файлів excel, у яких заздалегідь створені звіти з урахуванням показників OLAP-куба. Як ми говорили, MS Excel має спеціальний програмний інтерфейс (окремо завантажуваний або вбудований драйвер) для роботи з OLAP-кубами (з SSAS). Під час запуску MS Excel включаються програми на MS VBA (типу макросів), які забезпечують оновлення даних у звітах; звіти за необхідності модифікуються та розсилаються поштою (програма blat) користувачам згідно з контрольними списками.

Користувачі локальної мережі, які мають доступ до сервера SSAS, отримають «живі» звіти, налаштовані на OLAP-куб. (В принципі вони самі, без будь-якої пошти, можуть оновлювати OLAP-звіти в MS Excel, що лежать на їх локальних комп'ютерах.) Користувачі поза локальною мережею або отримають оригінальні звіти, але з обмеженою функціональністю, або для них (після оновлення OLAP-звітів у MS Excel) будуть обчислені спеціальні «мертві» звіти, які не звертаються до сервера SSAS.

Оцінка результатів

Ми говорили вище про асинхронність OLTP та OLAP. У варіанті технології цикл оновлення OLAP-куба виконується вночі (скажімо, запускається в 1 годину ночі). Це означає, що у поточному робочому дні користувачі працюють із вчорашніми даними. Оскільки OLAP – це засіб реєстрації (подивитися останню редакцію документа), а засіб управління (зрозуміти тенденцію процесу), таке відставання зазвичай не критично. Втім, при необхідності навіть в описаному варіанті архітектури куба (MOLAP) оновлення можна проводити кілька разів на добу.

Час виконання процедур оновлення залежить від особливостей конструкції OLAP-куба (більшої чи меншої комплексності, більш менш вдалих визначень показників і розрізів) та від обсягу баз даних зовнішніх OLTP-систем. За досвідом процедури побудови warehouse займають від кількох хвилин до двох годин, процедура оновлення куба (Process) – від 1 до 20 хвилин. Йдеться про комплексні OLAP-куби, що об'єднують десятки структур типу «зірочка», про десятки загальних «променів» (довідників-розрізів) для них, про сотні показників. Оцінюючи обсяги баз даних зовнішніх ERP-систем за документами відвантаження, ми говоримо про сотні тисяч документів і, відповідно, мільйони товарних рядків на рік. Історична глибина обробки, яка цікавить користувача, становила три – п'ять років.

Описана технологія експлуатується у низці великих корпорацій: з 2008 року в «Російській рибній компанії» (РРК) та компанії «Російське море» (РМ), з 2012 року в компанії «Санта-Бремор» (СБ). Частина корпорацій є переважно торгово-закупівельними фірмами (РРК), інші – виробничими (заводи з переробки риби і морепродуктів РМ і СБ). Всі корпорації є великими холдингами, що об'єднують кілька фірм з незалежними і різними системами комп'ютерного обліку – починаючи від стандартних ERP-систем типу 1C7 і 1C8 і закінчуючи «реліктовими» обліковими системами на базі DBF і Excel. Додам, що описана технологія експлуатації OLAP-кубів (без урахування етапу розробки) або взагалі не вимагає спеціальних співробітників, або входить до кола обов'язків одного штатного бізнес-аналітика. Завдання роками крутиться в автоматичному режимі, щодня забезпечує різні категорії співробітників корпорацій актуальною звітністю.

Плюси та мінуси рішення

Як показує досвід, варіант запропонованого рішення досить надійний та простий в експлуатації. Він легко модифікується (підключення/відключення нових ERP, створення нових показників та розрізів, створення та модифікація Excel-звітів та списків їх поштового розсилання) при інваріантності керуючої програми facubi.

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

«Рафінована» БД warehouse, в якій консолідовано (у ході побудови куба) кілька різнорідних ERP-систем, навіть без будь-якого OLAP дозволяє вирішувати (на сервері SSAS, методом запитів на мові Transact SQL або методом SP та ін) безліч прикладних завдань управління. Нагадаємо, структура БД warehouse уніфікована і значно простіше (у плані кількості таблиць і числа полів таблиць), ніж структури БД вихідних ERP.

Особливо відзначимо, що у запропонованому нами рішенні є можливість консолідації в одному OLAP-кубі різних систем ERP. Це дозволяє отримати аналітику по всьому холдингу та зберегти багаторічну спадкоємність в аналітиці під час переходу корпорації на іншу облікову ERP-систему, скажімо, при переході від 1C7 до 1С8.

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

На закінчення наведемо ще один аргумент на користь OLAP, який, можливо, був би доречнішим у Середні віки. Оскільки його доказова сила лежить на авторитеті. Скромний, явно недооцінений британський математик Е. Кодд наприкінці 60-х розробив теорію реляційних БД. Сила цієї теорії була така, що зараз, через 50 років, вже важко знайти базу даних не реляційного типу і мову запиту до БД, відмінний від SQL.

Технологія OLTP, заснована на теорії реляційних БД, була першою ідеєю Е. Кодда. По суті концепція OLAP-кубів – це друга його ідея, висловлена ​​ним на початку 90-х років. Навіть не будучи математиком, можна очікувати, що друга ідея виявиться настільки ж ефективною, як перша. Тобто в плані комп'ютерної аналітики ідеї OLAP незабаром захоплять світ і витіснять усі інші. Просто тому, що тема аналітики знаходить в OLAP своє вичерпне математичне рішення, і це рішення «адекватне» (термін Б. Спінози) практичному завданню аналітики. «Адекватно» означає у Спінози, що й сам Бог не придумав би краще…

1. Ларсон Б. Розробка бізнес-аналітики в Microsoft SQL Server 2005. - СПб.: "Пітер", 2008.
2. Codd E. Relational Completeness of Base Base Sublanguages, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice – Hall.

Вконтакте