Читайте также: |
|
Для проектування сховищ і вітрин даних потрібно визначити таблицю фактів і перелік вимірів, установити, факти якого типу найефективніші і чим їх відрізнити від вимірів. Факти — це елементи, які можуть бути виміряні й проаналізовані. Кращими фактами вважаються числові, адитивні дані, що можуть бути подані послідовною низкою значень.
Числові факти — це реквізити основи, які відображають кількісні величини. Над числовими фактами допускається виконання різних математичних операцій; їх легко вимірювати. Характерною ознакою таких фактів є те, що вони часто змінюються. Змінність конкретних значень фактів є дуже важливою їх ознакою з погляду аналізу, оскільки досліджувати величини, що не змінюються в часі, немає сенсу.
Адитивний факт може підсумовуватися за всіма вимірами. Наприклад, кількість проданих виробів є адитивним фактом, оскільки шляхом підсумовування можна визначити, скільки виробів продано на минулому тижні (за часом); скільки виробів продано у регіонах; скільки продано кожному споживачу. В сховищах даних надається перевага адитивним фактам, тому Що, підсумовуючи їх, можна отримати компактні ряди результатів.
Деякі факти є напівадитивними (semiadditive). їх можна коректно підсумовувати за певними вимірами, але не за всіма. Наприклад, доцільно підсумовувати складські запаси за видами продукту або за регіонами, але не за часом. Напівадитивні факти не має сенсу підсумовувати за окремими вимірами, але їх можна оціню-вати інакше. Наприклад, має значення середня величина складських запасів у часі, а також максимальний і мінімальний рівні запасів та деякі інші статистичні показники.
І нарешті, мають місце неадитивні (nonadditive) факти. Ці факти неможливо підсумовувати за жодним виміром. Прикла-
дом числових неадитивних фактів є табельні номери співробітників. Неадитивні факти не можна підсумовувати, але їх можна полічити, тому вони вимірні. Неадитивні факти частіше групуються з вимірами. Виміри — це описові, якісні атрибути, що служать умовами вибирання даних у запитах, або є заголовками рядів у звітах. До таблиць вимірів належать таблиці, що містять умовно-постійну інформацію. Тобто дані, що характеризують виміри, як правило, текстові, відносно статичні і неадитивні.
Не завжди легко можна відрізнити факти від вимірів. Іноді в таблиці вимірів можуть міститися числові, адитивні атрибути, такі як ціна одиниці товару. А іноді статичний і неадитивний атрибут доцільно розмістити в таблиці фактів. Все залежить від призначення конкретної вітрини. Наприклад, стать співробітника — це текстовий, статичний і неадитивний елемент. Але якидо проектується вітрина, присвячена аналізу трудових ресурсів, і аналітики часто задають запитання типу: «яке співвідношення між кількістю співробітників чоловічої і жіночої статі, що займають керівні посади?», то ознаку статі краще розташувати в таблиці фактів.
Визначення ступеня деталізації даних є наступним кроком проектування. Найдрібніші неподільні елементи — нижчій рівень деталізації даних, що зберігаються у вітрині. Дані можуть підсумовуватися на різних рівнях відповідно до вибращої єрархії вимірів. Щоденні обсяги продажу можна підсумовувати за тиждень, місяць або рік; продані товари можна підсумю-вувати за кожним товаром, зокрема, за їх видами чи товарними групами. Іноді застосовують кілька єрархічних систем. Магазини можна групувати за поштовими регіонами з однаковими тарифами на пересилання або за територіями з аналогічною структурою продажу для проведення маркетингових досліджень.
Користувачі вітрин можуть працювати з різними рівнями даних, що підсумовуються. Питання полягає в тому, яка ступінь деталізації потрібна користувачу? Завжди є вірогідність того, іщо якийсь користувач у своєму пошуку побажає дійти до базової транзакції, і на основі цього можна дійти висновку, що за проектування вітрини необхідно прагнути до забезпечення найнижчої го рівня деталізування. Але, зазвичай, у цьому немає необхідності, враховуючи те, що вітрини призначені для проведення бізнеїс-аналізу, метою якого є виявлення тенденцій, а не вивчення конкретних детальних фактів. Проте ступінь деталізації фактів, іщо
зберігаються у вітрині, передусім, визначається метою її створення. Так, наприклад, керівництву роздрібного магазину, бажаючому відстежити зміни складських запасів, немає потреби зберігати у вітрині дані про кожну торговельну операцію; обсяги продажу можна підсумовувати на рівні товарів. Але якщо необхідно проаналізувати поведінку споживачів, то буде потрібна інформація про окремі торговельні операції для їх аналізу і вивчення уподобань споживачів.
Визначення ступеня деталізації та агрегації даних — це дуже важливий момент проектування, тому що він впливає на розмір фізичної моделі. Іноді вибір ступеня деталізаціїї визначається інтенсивністю змін: для відстеження заробітної плати службовців протягом тривалого періоду не потрібно мати її величини за день або тиждень, якщо, наприклад, перегляд оплат праці співробітників виконується раз на рік.
Установивши ступінь деталізації, можна визначити атрибути таблиці вимірювань. У вітрині фактичних даних одним із вимірів є час, і в таблицю вимірів необхідно помістити інформацію про одиниці вимірювання часу, відповідні для таблиць фактів даної вітрини. Якщо для аналізу потрібні підсумкові значення за місяць або рік, то тоді для організації таблиці вимірювань будуть потрібні лише такі одиниці часу, як рік і місяць. Фінансові вітрини бажано доповнити таким виміром як квартал.
10.3. Система аналітичного інтерактивного оброблення (OLAP)
10.3.1. Зародження і розвиток OLAP-систем
OLAP (абревіатура від On-line Analytical Processing —
інтерактивне аналітичне оброблення) фактично означає не окремі конкретні програмні продукти, а технологію багатовимірного аналізу даних, основу якої започаткувала опублікована 1993 року праця Е. Ф. Кода (Е. F. Codd) «OLAP для користува-чів-аналітиків: яким воно має бути», у котрій він запропонував 12 правил, які виражали концепцію оперативного аналітичного оброблення даних і фактично послужили стандартом інструментальних засобів оперативного аналітичного оброблення (табл. 10.5.)
Таблиця 10.5
Дата добавления: 2015-08-13; просмотров: 88 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Основні завдання та способи проектування СД | | | ПРАВИЛА КОДА ДЛЯ OLAP |