Проектування структури сховища даних
МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ “ЛЬВІВСЬКА ПОЛІТЕХНІКА”
“Створення сховища даних в Deductor”
Методичні вказівки
до лабораторної роботи №2
з курсу “Інтелектуальна обробка даних”
для студентів напрямку
8.05010103, 7.05010103“Системне проектування”
Затверджено
на засіданні кафедри “Системи автоматизованого проектування” Протокол № 1
від 22.08.2011
Львів 2011
“Створення сховища даних в Deductor”. Методичні вказівки до виконання лабораторної роботи №2 з курсу: “ Інтелектуальна обробка даних” для 8.05010103, 7.05010103“Системне проектування”.
Укладачі: Керницький А.Б., др.інж, доц.
Денисюк П.Ю., канд.техн.наук, доц.
Мельник М.Р., канд.техн.наук, доц.
Відповідальний за випуск: Ткаченко С.П., канд.техн.наук, доц.
Рецензенти: Каркульовський В.І., канд.техн.наук, доц.
Яковина В.С., канд.фіз.-мат.наук, доц.
МЕТА РОБОТИ
Ознайомитись та вивчити можливості створення та роботи зі сховищем даних в аналітичній платформі Deductor.
КОРОТКІ ТЕОРЕТИЧНІ ВІДОМОСТІ
Сховище даних Deductor Warehouse – це спеціально організована база даних, що орієнтована на вирішення завдань аналізу даних і підтримки прийняття рішень, забезпечує максимально швидкий і зручний доступ до інформації.
Deductor Warehouse побудований на моделі ROLAP (схема «сніжинка») і може бути розгорнутий на одній з наступних СУБД:
|
|
|
1. Firebird 1.5 і вище;
2. MS SQL Server 2000 і вище;
3. Oracle починаючи з версії 9i;
Локально база даних Firebird (з використанням бібліотеки fbclient.dll) поставляється разом з Deductor.
Вибір тієї або іншої СУБД для СД часто залежить від багатьох критеріїв: вартість, продуктивність, складність адміністрування тощо.
Можливість роботи зі сховищами даних на СУБД MS SQL Server і Oracle доступна тільки в Deductor Enterprise. Версія програми Deductor Academic підтримує роботу сховища на базі Interbase Firebird.
Призначення сховища даних – своєчасно забезпечити аналітика всією інформацією, необхідною для проведення аналізу, побудови моделей та прийняття рішень. Мета сховища даних – не аналіз даних, а підготовка даних для аналізу та їх консолідація.
В Deductor Warehouse варто виділити наступні об’єкти:
1. Вимір – це послідовність значень одного з параметрів, що аналізується. Наприклад, для параметра «час» це послідовність календарних днів, для параметра «регіон» – список міст. Кожне значення виміру може бути представлене координатою в багатовимірному просторі процесу, наприклад, товар, клієнт, дата.
2. Атрибут – це властивість виміру (тобто точки в просторі). Атрибут допомагає користувачеві повніше описати певний вимір. Наприклад, для виміру «Товар» атрибутами можуть бути «Колір», «Вага», «Габарити».
|
|
|
3. Факт – значення, що відповідає виміру. Факти – це дані, що відображають суть події. Як правило, фактами є числові значення, наприклад, сума і кількість відвантаженого товару, знижка.
4. Посилання на вимір – це встановлений зв’язок між двома і більше вимірами. Річ у тому, що деякі бізнес-терміни (що відповідають вимірам в сховищі даних) можуть утворювати ієрархії, наприклад, «Товари» можуть включати «Продукти харчування» і «Лікарські препарати», які, у свою чергу, поділяються на групи продуктів та ліків тощо. В цьому випадку перший вимір містить посилання на другий, другий – на третій і так далі.
5. Процес – сукупність вимірів, фактів та атрибутів. По-суті, процес і є «сніжинка». Процес описує певну дію, наприклад, продаж товарів, відвантаження, надходження грошових коштів тощо.
6. Атрибут процесу – властивість процесу. Атрибут процесу на відміну від виміру не визначає координату в багатовимірному просторі. Це довідкове значення, що відноситься до процесу, наприклад № накладної, валюта документа тощо. Значення атрибуту процесу на відміну від виміру може бути визначене не завжди.
|
|
|
Часто складно визначитися, що є атрибутом процесу, а що виміром. Універсальних рецептів на всі випадки не існує. Але можна дати загальні рекомендації:
· сукупність вимірів процесу повинна однозначно визначати єдиний запис в таблиці процесу («точку» в багатовимірному просторі);
· якщо існують ієрархії, то вибір повинен бути на користь виміру;
· якщо по об’єкту сховища даних передбачається в майбутньому часто робити «зрізи», то знову краще віддати перевагу виміру.
· наявність можливих пропусків (необов’язкове поле) означає, що об’єкт краще зробити атрибутом процесу.
В Deductor Warehouse може одночасно зберігатися безліч процесів, що мають загальні виміри, наприклад, вимір «Товар», що фігурує в процесах «Прихід» і «Розхід».
Всі дані, що завантажуються в СД обов’язково повинні бути визначені як вимір, атрибут або факт (рис. 2.1).
Рис.2.1. Структура сховища даних
Проектування структури сховища даних
Розглянемо приклад проектування сховища даних для процесу продажу товарів в мережі аптек. Є історія продаж різних товарів по днях. Товари об’єднані в групи. Всі дані представлені в 4 таблицях, фрагменти яких представлені нижче:
|
|
|
Таблиця 2.1. Товарні групи
| Код групи | Назва групи |
| 33 | Імуномодулятори |
| 48 | Загальнотонізуючі засоби та адаптогени |
| 50 | Місцеве знеболююче |
| 108 | Мікро- та макроелементи |
| 198 | Вітаміни |
| 223 | Нормалізація кишково-шлункового тракту |
| 247 | Антисептики та дизинфікуючі засоби |
| 320 | Біологічно активні харчові добавки |
Таблиця 2.2. Товари (фрагмент)
| Код товару | Назва товару | Код групи |
| 774 | Альмагель | 223 |
| 810 | Іммунорм | 33 |
| 824 | Ревит | 198 |
| 898 | Настоянка пустинника | 48 |
| … | … | … |
Таблиця 2.3. Відділи
| Код відділу | Назва відділу |
| 1 | Аптека 1 |
| 2 | Аптека 2 |
| 3 | Аптека 3 |
Таблиця 2.4. Продажі (фрагмент)
| Дата | Код відділу | Код товару | Час покупки | Кількість | Сума |
| 01.01.08 | 1 | 824 | 13 | 1 | 10.50 |
| 01.01.08 | 1 | 12360 | 15 | 5 | 42.5 |
| 01.01.08 | 3 | 5230 | 15 | 9 | 151.0 |
| 01.01.08 | 2 | 7201 | 16 | 3 | 6.32 |
| … | … | … | … | … | … |
Тепер визначимося, що в кожній таблиці є фактом, виміром та атрибутом:
1. Таблиця 2.1: «Код групи» є виміром, «Назва групи» – його атрибутом.
2. Таблиця 2.2: «Код товару» є виміром, «Назва товару» – його атрибутом, «Код групи» – посиланням на однойменний вимір.
3. Таблиця 2.3: «Код відділу» є виміром, «Назва відділу» – його атрибутом.
4. Таблиця 2.4: «Дата» є виміром, «Код відділу» та «Код товару», як було відмічено раніше, – також виміри, «Кількість» та «Сума» – факти.
Дата добавления: 2020-12-12; просмотров: 57; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!