Курс лекцій з дисципліни «Системи підтримки прийняття рішень» (стр. 3 )

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

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

- можливість звернення до будь-якої потрібної інформації незалежно від її об’єму та місця збереження.

OLAP-системи оперують з великими масивами даних, які вже накопичені в ОБД OLTP-систем, взятими з електроних таблиць з інтелектуальними зв’язками або з інших можливих джерел. Такі системи характеризуються наступними ознаками:

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

- дані, які додані в систему, зазвичай ніколи не знищуються і не змінюються;

- перед завантаженням дані проходять різні процедури «очищення», які пов’язані з тим, що в одну систему можуть поступати дані з багатьох джерел, які мають різноманітні формати представлення, дані можуть бути некоректно представленні або помилкові;

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

- швидкість виконання запитів важлива, але не критична.

Виходячи з цих ознак, можна зробити висновок, що БД такої системи може бути в значній степені ненормованою.

Початкові дані для аналізу представлені у вигляді багатовимірного кубу, по якому можна отримувати потрібні розрізи - звіти. Виконання операцій над даними виконується OLAP-машиною. За засобом збереження даних розрізняють MOLAP, ROLAP и HOLAP. За місцем розміщення - OLAP-клієнти та OLAP-сервери. OLAP-клієнт виконує побудову клієнтському ПК, а OLAP-сервер отримує запит, обчислює та зберігає агрегатні дані на сервері, видаючі тільки результати. 

Причина використання OLAP для обробки даних – це швидкість. Реляційні БД зберігають сутності в певних таблицях, які зазвичай добре нормалізовані. Ця структура зручна для операційних БД (системи OLTP), але складні багато табличні запити в ній виконуються відносно повільно.

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

В центрі СЗ (star schema) знаходиться таблиця фактів, яка містить ключові факти, по яким робляться запити. Багато таблиць з вимірами приєднанні до таблиці фактів. Ці таблиці показують, як можуть аналізуватися агреговані реляційні дані. Кількість можливих агрегувань визначається кількістю способів, за допомогою яких початкові дані можуть бути ієрархічно відображені.

СЗ лежить в основі реляційного OLAP. Термін «реляційний» означає, що в основі організації даних лежить математична теорія відношення (relation). Синонім – таблиця.

n-мірним відношенням R або відношенням зі степеню n називають підмножину декартового добутку множин , не обов’язково різних. Ці множини в моделі РД називають доменами (тип даних). Дані можуть бути в різних нормальних формах. Наприклад, перша нормальна форма означає, що кожен кортеж містить тільки одне зі значень для кожного атрибуту. В реляційній моделі відношення завжди перебуває в першій нормальній формі по визначенню поняття «відношення».

Корте́ж або n-ка — в математиці впорядкована та скінченна сукупність елементів (нескінченний кортеж має назву сімейства). Атрибут (реляційна модель), поле — в реляційних базах даних, елемент даних у кортежі

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

Конкретніше, таблиця має задовольняти наступним умовам:

1.  Немає впорядкованості рядків згори до низу (порядок рядків не несе ніякої інформації)

2.  Немає впорядкованості стовпчиків зліва направо (порядок стовпчиків не несе ніякої інформації)

3.  Немає рядків, що повторюються

4.  Кожний перетин рядку та стовпчика містить рівно одне значення з відповідного домену

5.  Всі стовпчики є звичайними.

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

Приклад

Вихідка ненормалізована таблиця:

Співробітник	Номер телефону
Іванов А. В.	283-56-82 390-57-34
	708-62-34

Приведення до 1 НФ:

Співробітник	Номер телефону
Іванов А. В.	283-56-82
Іванов А. В.	390-57-34
	708-62-34

Модель даних СЗ складається з двох типів таблиць таблиці фактів (fact table) — центр «зірки» — та декількох таблиць вимірів (dimension table) по числу вимірів в моделі даних – промені зірки.

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

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

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

SQL-запит до СЗ зазвичай містить в собі:

-  Одне або декілька зєднань з ТФ до ТВ;

-  Декілька фільтрів (SQL-операторів WHERE), які використовуються до ТФ або ТВ;

·  Групування або агрегування по потрібним елементам ієрархії вимірів (dimension elements).

Наприклад:

SELECT

d_product. brand,

d_store. country_iso_id,

SUM (f_sales. units_sold) AS summa

FROM

f_sales, d_customer, d_time, d_store, d_product

WHERE

f_sales. customer_id = d_customer. customer_id AND

f_sales. date_id = d_time. date_id AND

f_sales. store_id = d_store. store_id AND

f_sales. product_id = d_product. product_id AND

d_time. year_id = 1997 AND

d_product. category_id = "tv"

GROUP BY

d_product. brand, d_store. country_iso_id

Схема сніжинки (СС) отримала свою назву за свою форму, у вигляді якої відображається логічна схема таблиць в багатовимірній БД. Як і в СЗ, СС мітить ТФ, яка зєднена з декількома ТВ. Відмінністю є нормалізація ТВ з рядом інших зв’язних таблиць, в отй час як в СЗ ТВ повністю денормалізовані, з кожним виміром, який представлений у вигляді єдиної таблиці, без зєднань на зв’язані таблиці в СС. Чим більше степінь нормалізації таблиць вимірів, тим складніше виглядає структура СС. «Ефект сніжинки» стосується тільки ТВ.

Наприклад, всі клієнти можуть бути згруповані по містам або по регіонам країни. Якщо, 2 країни містять 50 міст і 8 регіонів, тоді схема містить 3 рівня ієрархії з 60 членами. Також, клієнти можуть бути згруповані по відношенню до продукції. Якщо існує 250 продуктів, 20 категорій, 3 групи та 3 виробничих підрозділів, то кількість агрегатів складає 16560. При додаванні вимірів в схему кількість можливих варіантів швидко досягає десятків мільйонів та більше.