On—Line Transaction Processing

 

ВСТУП

 

 

Важко знайти в комп'ютерному світі людини, яка хоча б на інтуїтивному рівні не розуміла, що таке бази даних  і навіщо вони потрібні. На відміну  від традиційних реляційних СУБД, концепція OLAP не так широко відома, хоча загадковий термін «OLAP» чули, напевно, майже всі. Що ж таке OnLine Analytical Processing, де він мешкає, і з чим його їдять, ми і спробуємо розібратися.

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

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

РОЗДІЛ 1

КОНЦЕПЦІЯ СХОВИЩ ДАНИХ ТА ЇЇ ЗАСТОСУВАННЯ В АНАЛІТИЧНИХ ІНФОРМАЦІЙНИХ СИСТЕМАХ (OLAP)

 

1.1 Концепція сховища даних

 

OLAP (On—Line Transaction Processing) — системи оперативної аналітичної обробки, які призначені для підтримки прийняття рішень і орієнтовані головним чином на нерегламентовані запити. Термін OLAP дозволяє описувати технологію обробки даних, в якій застосовується багатомірне представлення агрегованих даних для забезпечення швидкого доступу до даних для поглибленого аналізу.

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

— довготривалого зберігання даних ;

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

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

Зауваження: термін OLAP дуже популярний в даний час і OLAP—системою часто називають будь—яку DSS—систему, засновану на концепції сховищ даних і забезпечують малий час виконання (On—Line) аналітичних запитів, не залежно від того, чи використовується багатовимірний аналіз даних. Що не зовсім вірно.

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

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

 

Рис. 1.1 Зразок структури інформаційно—аналітичної системи

 

Яка спонукальна причина поява концепції  сховищ даних?

Здавалося б, навіщо будувати сховища даних  — адже вони містять завідомо надлишкову інформацію, яка і так є в базах або файлах оперативних систем? Відповісти можна коротко: аналізувати дані оперативних систем безпосередньо неможливо або дуже важко. Це пояснюється рядом причинами, в тому числі

— розрізненістю даних (OLTP—системи, текстові звіти, xls—файли);

— зберіганням їх у форматах різних СУБД і в різних вузлах корпоративної мережі.

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

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

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

Для того, щоб витягувати корисну інформацію з даних, вони повинні бути організовані способом, відмінним від прийнятого в OLTP—системах Чому?

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

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

У разі аналітичних запитів частіше  використовуються не детальні, а узагальнені (агреговані дані).

В результаті дані, застосовувані для  аналізу, стали виділяти в окремі спеціальні бази даних, що згодом отримали назву сховищ даних (Data Warehouse).

Сховище даних (визначення Білла Інмона (Bill Inmon)) — предметно—орієнтований, інтегрований, прив'язаний до часу і незмінний набір даних, призначений для підтримки прийняття рішень. Базові вимоги до сховища даних:

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

— Інтегрованість і внутрішня несуперечність. Оскільки дані в сховищі надходять з різних джерел (OLTP—системи, архіви та інше), необхідно привести їх до єдиного формату (дата: 5 січня, 5.01, :). У процесі завантаження сховища повинна бути забезпечена, очищення та узгодженість даних.

— Прив'язка до часу. Облік хронології досягається введенням атрибутів «Дата» та «Час». Впорядкування по цим атрибутам дозволяє скоротити час виконання аналітичних запитів.

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

— Підтримка високої швидкості отримання даних зі сховища.

— Можливість отримання і порівняння так званих зрізів даних (slice and dice);

— Повнота і достовірність даних, що зберігаються;

— Підтримка якісного процесу поповнення даних.

1.2 OLAP — основні відомості

 

Термін OLAP був запропонований в 1993 р. Едвардом Коддом (E. Codd — автор реляційної моделі даних) За Коду OLAP—технологія — це технологія комплексного динамічного синтезу, аналізу та консолідації великих обсягів багатовимірних даних. Він же сформулював 12 принципів OLAP, які пізніше були перероблено в так званий тест FASMI:

— Fast (швидкий) — надання користувачу результатів аналізу за прийнятний час (зазвичай не більше 5 с), нехай навіть ціною менш детального аналізу;

— Analysis (аналіз) — можливість здійснення будь—якого логічного та статистичного аналізу, характерного для даного додатка, і його збереження в доступному для кінцевого користувача вигляді;

— Shared (що розділяється) — багатокористувацький доступ до даних з підтримкою відповідних механізмів блокувань і засобів авторизованого доступу;

— Multidimensional (багатовимірної) — багатовимірне концептуальне уявлення даних, включаючи повну підтримку ієрархій та множинних ієрархій (ключова вимога OLAP);

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

У найзагальнішому вигляді OLAP = багатовимірне  представлення = куб

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

При тому гіперкуб є концептуальною логічною моделлю організації даних, а не фізичною реалізацією їх зберігання, оскільки зберігатися такі дані можуть і в реляційних таблицях («реляційні БД були, є і будуть найбільш придатною технологією для зберігання корпоративних даних» — E. Codd).

По  Кодду, багатовимірне концептуальне уявлення (multi—dimensional conceptual view) являє собою множинну перспективу, що складається з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані певні сукупності даних. Одночасний аналіз по декількох вимірах визначається як багатовимірний аналіз. Осями багатовимірної системи координат служать основні атрибути аналізованого бізнес—процесу (те, по чому ведеться аналіз). Наприклад, для продажу це можуть бути тип товару, регіон, тип покупця. В якості одного з вимірів використовується час. На перетинах осей — вимірів (dimensions) — знаходяться дані, що кількісно характеризують процес — заходи (measures): суми та інші агрегатні функції (min, max, avg, дисперсія, ср відхилення і пр.). Кожен вимір включає напрямки консолідації даних, що складаються із серії послідовних рівнів узагальнення (рівнів ієрархії), де кожен вищестоящий рівень відповідає більшому ступені агрегації даних по відповідному вимірюванню (різні рівні їх деталізації). У цьому випадку стає можливим довільний вибір бажаного рівня деталізації інформації по кожному з вимірів.

 

Рис. 1.2 Багатовимірне концептуальне уявлення за Коддом

 

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

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

 

Рис. 1.3 Тривимірний куб

 

Значення, «відкладені» уздовж вимірювань, називаються членами або мітками (members). Мітки використовуються в операціях маніпулювання вимірами.

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

All (світ)         

Country (країна)                

State (штат)                    

City (місто)                          

Store (магазин)

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

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

 

Рис. 1.4 Ієрархія значень у вимірі — регіон.

 

Ієрархії  можуть бути збалансованими (balanced), як, наприклад, ієрархія, представлена ​​вище (така ж ієрархії, засновані на даних типу «дата-час»), і незбалансованими (unbalanced). Типовий приклад незбалансованої ієрархії - ієрархія типу «начальник - підлеглий».

Іноді для таких ієрархій використовується термін Parent - child hierarchy.

 

Рис. 1.5 Типовий приклад незбалансованої ієрархії

 

Існують також ієрархії, що займають проміжне положення між збалансованими і незбалансованими (вони позначаються терміном ragged - «нерівний»). Зазвичай вони містять такі члени, логічні «батьки» яких знаходяться не на безпосередньо вищестоящому рівні (наприклад, в географічній ієрархії є рівні Country, City та State, але при цьому в наборі даних є країни, які не мають штатів або регіонів між рівнями Country і City ).

 

Рис. 1.6 Проміжна ієрархія

 

Аналітичні OLAP—операції:

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

— Обертання (rolling). Операція обертання змінює порядок подання вимірювань, забезпечуючи уявлення мета куба в більш зручній для сприйняття формі.

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

— Операція спуску (drill doun). Операція, зворотна консолідації, яка включає відображення докладних відомостей для розглянутих консолідованих даних.

— Розбиття з поворотом (slicing and dicing). Дозволяє одержати уявлення даних з різних точок зору. Наприклад, один зріз даних про доходи може містити всі відомості про доходи від продажів товарів зазначеного типу по кожному місту. Інший зріз може представляти дані про доходи окремої компанії в кожному з міст.

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

1.3 Моделі сховища даних

 

Забезпечуючи  багатомірне концептуальне уявлення з боку користувача інтерфейсу до вихідної бази даних, всі продукти OLAP діляться на кілька класів за типом вихідної БД. Багатомірний гіперкуб, використовуваний в OLAP—технології, може бути реалізований в рамках реляційної моделі або існувати як окрема база даних спеціальної багатовимірної структури. В залежності від цього прийнято розрізняти багатовимірний (MOLAP) і реляційний (ROLAP) підходи до побудови сховища даних.

У MOLAP—моделі багатовимірне представлення даних реалізується фізично. У спеціалізованих СУБД, заснованих на багатовимірному поданні даних, дані організовані не у формі реляційних таблиць, а у вигляді впорядкованих багатовимірних масивів:

— Гіперкубів (всі збережені в базі даних осередки повинні мати однакову розмірність, тобто знаходитися в максимально повному базисі вимірювань) і

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

Використання  багатовимірних баз даних в системах оперативної аналітичної обробки має наступні достоїнства:

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

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

Недоліки MOLAP—моделі:

— Багатовимірні СУБД не дозволяють працювати з великими базами даних.

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

Отже, використання багатовимірних СУБД виправдано тільки при наступних умовах:

— Обсяг вихідних даних для аналізу не занадто великий (не більше декількох гігабайт), тобто рівень агрегації даних досить високий.

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

— Час відповіді системи на нерегламентовані запити є найбільш критичним параметром.

Приклади OLAP—серверів, що використовують MOLAP—архітектуру: Oracle Express Server фірми Oracle, IBM Informix MetaCube, IBM DB2 OLAP, Arbor Essbase.

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

Для більшості сховищ даних найбільш ефективним способом моделювання N—мірного куба фактів є схема «зірка» (star schema).

Основними складовими структури сховищ даних  є таблиця фактів (fact table) і таблиці  вимірів (dimension tables).

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

— факти, пов'язані з транзакціями (Transaction facts). Вони засновані на окремих подіях (типовими прикладами яких є телефонний дзвінок або зняття грошей з рахунку за допомогою банкомату);

— факти, пов'язані з «моментальними знімками» (Snapshot facts). Засновані на стані об'єкта (наприклад, банківського рахунку) в певні моменти часу, наприклад на кінець дня або місяця. Типовими прикладами таких фактів є обсяг продажів за день або денна виручка;

— факти, пов'язані з елементами документа (Line—item facts). Засновані на тому чи іншому документі (наприклад, рахунку за товар або послуги) і містять детальну інформацію про елементи цього документа (наприклад, кількості, ціні, відсотку знижки);

— факти, пов'язані з подіями або станом об'єкта (Event or state facts). Представляють виникнення події без подробиць про нього (наприклад, просто факт продажу або факт відсутності такої без інших подробиць).

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

Зауваження:

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

2. У таблиці фактів відсутні  будь—які відомості про те, як групувати записи при обчисленні агрегатних даних.

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

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

 

Рис. 1.7 Схема «зірка»

 

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

У складних завданнях з багаторівневими  вимірами використовуються різні розширення схеми «зірка» - схема «сніжинка» (snowflake schema). Це розширення може проявлятися у двох різновидах.

1. У разі великого числа складних  атрибутів в таблиці вимірювань, деякі атрибути можуть бути  деталізовані в окремих таблицях  вимірів. Іншими словами окремі  вимірювання містяться не в  одній, а в кількох пов'язаних  між собою таблицях. Додаткові таблиці вимірювань в такій схемі, зазвичай відповідні верхнім рівням ієрархії виміру і знаходяться в співвідношенні «один до багатьох» в головній таблиці вимірювань, відповідної нижньому рівню ієрархії, іноді називають консольними таблицями (outrigger table).Наприклад, з таблиці «Покупець» можна вилучити опису регіону, населеного пункту (залишивши лише їх ключі) і зберігати їх в окремих додаткових таблицях. Це зменшить ступінь дублювання інформації, але знижує швидкість виконання запитів, оскільки збільшує ступінь нормалізації. Тому навіть за наявності ієрархічних вимірів з метою підвищення швидкості виконання запитів до сховища даних нерідко перевага віддається схемі «зірка».

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

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

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

Нижче наведено фрагмент для одного виміру в схемі «сніжинка».

 

Рис. 1.8 Схема «сніжинка»

 

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

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

 

Рис. 1.9 Приклад запиту

1.4 Висновки до I розділу

 

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

Сервер OLAP є високорозрядним, багатокористувацьким механізмом (або процесором бази даних) маніпулювання даними, специфічно розробленим для того, щоб підтримувати і здійснювати операції з багатовимірними структурами даних. Багатовимірна структура упорядкована так, щоб кожний елемент даних був розміщений і забезпечений доступом на основі перетину компонентів вимірностей, які визначають той елемент. Сервер і структура даних оптимізовані для швидкого пошуку інформації, для проведення аналізу типу «на даний випадок» (ad—hoc) у будь—якому аспекті, а також для швидкого та гнучкого обчислення і перетворення первинних даних, що ґрунтується на формульних взаємозалежностях.

Досягнутий  на даний час стан технологічних  засобів і вимоги кінцевих користувачів щодо узгоджених і швидких відповідей визначають, що найкращим підходом до організації оброблення даних  є установлення багатовимірної бази даних у сервері OLAP. Прикладами багатовимірних серверів можуть бути Lightship Server від Pilot Software і Essbase від Arbor Software. 

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

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

 

 

 

 

 

 

РОЗДІЛ 2

СИСТЕМА УПРАВЛІННЯ КОНТЕНТОМ DRUPAL

 

2.1 Призначення систем управління контентом

 

В Інтернеті часто можна зустріти слоган «створи свій куточок в Інтернеті». Так от, системи управління вмістом, CMS - це і є той самий куточок. З одного боку, це інтерфейс користувача - відвідувача сайту, де господар показує, що у нього є, організує різні WEB-сервіси, а відвідувач може дивитися, купувати, спілкуватися. З іншого боку - це інтерфейс адміністраторської панелі, недоступний для відвідувачів, де і відбувається управління ресурсом - адміністрування, управління виглядом сайту, спілкування з відвідувачами і клієнтами WEB-сайту.

Ролі CMS відводиться значна частина  в загальному розвитку Інтернету. Всесвітня  мережа постійно розвивається семимильними кроками, чому сприяють і загальна комп'ютеризація, і зростаюча зв'язок offline-світу і бізнесу з online способами доставки інформації. Виникає все більшу кількість бажаючих мати своє представництво в Інтернеті. Фактично, з виникненням CMS-конструкторів сайту зняті технічні обмеження на створення свого WEB-сайту - найчастіше досить лише розібратися в інтерфейсі, запланувати структуру сайту і виходить готовий сервіс. Залишилося лише підтримувати сайт, оновлювати інформацію, залучати відвідувачів. Все це стало можливо завдяки широкому розповсюдженню систем управління контентом.

CMS - це абревіатура  від Content Management System, що в дослівному  перекладі означає «система управління контентом сайту» або просто «система управління сайтом». Іноді CMS називають «движок» сайту. CMS - це програмне забезпечення, яке дозволяє розробляти і підтримувати динамічні інформаційні web-сайти. Різні CMS дозволяють проектувати сайти різної складності, аж до Інтернет - магазинів та інформаційних порталів. Найбільше CMS підходять для формування новинних і тематичних сайтів.