Функції аналізу та створення звітів для рішень бізнес-аналітики на базі Microsoft SQL Server. Частина 1, Інші СУБД, Бази даних, статті

Незалежно від того, чи використовуєте ви як сховище даних реляційний склад даних або розміщуєте дані безпосередньо в компоненті Analysis Services (SSAS) Microsoft SQL Server, в першу чергу ви думаєте про доставку даних бізнес-користувачам, тобто про заключному ланці в ланцюжку програм вирішення бізнес-аналітики. Якщо ви використовуєте компонент SSAS з Microsoft SQL Server, то більшу частину роботи з підготовки даних до доставки можна виконувати з його допомогою. Можна обчислити тенденції, наприклад, підсумки для даних з продажу, середні вартості для замовлень через певний період часу або дізнатися, в яких регіонах країни певні категорії товарів продаються краще, ніж в інших. Саме в цих ситуаціях ви зможете повною мірою оцінити ефективність функцій SSAS, які допоможуть вам витягти максимум корисної інформації з ваших даних.

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


КОМПОНЕНТ SQL SERVER “СЛУЖБИ ANALYSIS SERVICES”


За останні кілька років компонент SSAS зазнав значних змін і перетворився в одну з найбільш надійних платформ аналізу даних корпоративного рівня. У версіях SQL Server 2005 і SQL Server 2008 ми спостерігаємо небувалий ріст функціональності і масштабованості платформи; при цьому програмний продукт зберігає своє основна перевага – він дозволяє без зайвих складнощів створити новий проект. Завдяки цього багато розробників вибирають SSAS в якості основи для створення рішень бізнес-аналітики, адже даний програмний продукт робить можливою швидку розробку і розгортання рішень для зберігання даних. Велика частина цих функціональних можливостей закладена в семантичній бізнес-моделі SSAS, яка визначає бізнес-суті, логіку, розрахунки і показники (її фірмову назву в Microsoft – Unified Dimensional Model, UDM (універсальна просторова модель)). Роботу будь реалізації SSAS забезпечує або значну кількість ETL-процесів, що завантажують дані з різних інших джерел безпосередньо в куб SSAS, або реляційне сховище даних, яке служить серверної стороною куба. UDM-модель забезпечує централізоване зберігання даних і надає єдиний джерело для всіх даних, що мають відношення до вирішення бізнес-аналітики. Це допомагає розробникам створити певний рівень абстракції, що дозволяє приховати описані серверні процеси від клієнтської сторони і механізмів доставки даних.


ЗАГАЛЬНА СХЕМА


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


Коротко: Ральф Кімболл в своїй роботі під назвою “The Data Warehouse Lifecycle Toolkit” (Набір інструментів для всього життєвого циклу сховищ даних) ідентифікував і дав визначення проблеми “сполучення труб різного діаметру “(stovepipe). У багатьох корпораціях часто трапляється, що кожна незалежна система, або вітрина даних, ідентифікує і зберігає дані своїм унікальним чином, що нагадує набір труб різного діаметру. Отримання даних з цих різних систем і об’єднання їх в систему підтримки рішень може бути надзвичайно складною справою. Щоб пом’якшити ситуацію, Кімболл рекомендує використовувати методологію подібних вимірів. Згідно цієї методології, всі використовувані виміру, наприклад, дані по продажах, повинні мати однакові атрибути та агрегати у всіх вітринах даних в межах корпорації. Таким чином, сховище даних може створюватися з вітрин даних у всій корпорації. Головна думка тут в тому, що сховище даних містить всі розмірні бази даних для спрощення аналізу, при цьому користувачі можуть просто безпосередньо запитувати сховище при будь-яких потреб у інформації.



Рисунок 1. Приклад: куб в Microsoft Visual Studio.



Рисунок 2. Група показників “Підсумки по продажам” в Visual Studio.


Білл Інмон в своїй роботі Corporate Information Factory (Корпоративна фабрика інформації) рекомендує більш універсальний безрозмірний формат. Вітрини даних можуть містити абсолютно неоднорідну інформацію, і користувачі безпосередньо запитують ці різнорідні джерела, а не сховище даних.


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


Продумавши створення вітрини / сховища даних на високому рівні, ви повинні перейти до реального створення проекту. Для наших цілей ми скористаємося навчальним проектом, який поставляється з SQL Server 2008 – це сховище даних AdventureWorksDW. Зокрема, ми будемо розглядати навчальний проект Visual Studio, створений для сховища даних. Завдяки цьому ви зможете вивчати матеріал разом з нами, і одночасно отримати загальні навички дослідження інших проектів. Компанія Adventure Works, яка згадується в навчальних матеріалах по Microsoft SQL Server – це уявна компанія, що займається продажем велосипедів. Інформація про продажі і співробітників зберігається в реляційному сховище даних, а відповідний куб служб Analysis Services відображає ці дані для користувачів або безпосередньо з реляційної бази даних, або через сховище даних. Всі описані навчальні матеріали можна завантажити з Web-сайту www.codeplex.com.


КУБИ


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


Куб – це фундамент багатовимірної бази даних. Як правило, куб має 2 або більше вимірів і фактичні дані. Виміри використовуються для опису фактичних даних. Звичайні вимірювання – це час, географічні дані та інформація про продукт. Ми застосовуємо ці вимірювання до наших фактичним даними, наприклад, до продажу, щоб зрозуміти значення цих даних. Наприклад, ми застосовуємо часовий вимір до даних з продажу, щоб з’ясувати, скільки продажів було зроблено конкретним співробітником в кожному місяці року. Ми можемо змінити часовий вимір, щоб вивчити ті ж дані про продажі за квартал, або порівняти дані в річному численні. Ці виміри засновані на загальній концепції вимірювань в будь-якому сховище даних (не тільки для служб Analysis Services). Однак не у всіх аспектах. В SSAS вимірювання мають ієрархії. Кожен вимір має атрибути, які пов’язані з іншими вимірами відносинами предок-нащадок, іншими словами, вимірювання утворюють ієрархії. Класичним прикладом ієрархії є вимірювання Geography, що має атрибути Country-State-City-Zip Code (Країна-штат-місто-зіп-код). Ці атрибути формують ставлення ієрархії з іншими атрибутами.


На малюнку 1 показаний куб AdventureWorks в Visual Studio. У центральній панелі ми бачимо факти (вони позначені жовтим кольором) і вимірювання (вони позначені синім кольором). Справа розташована панель оглядача рішень Solution Explorer, ліворуч ми бачимо ще дві панелі: Dimensions (Вимірювання) і Measures (Заходи).



Рисунок 3. Діалогове вікно “Edit Measure” в Visual Studio.


Крім вимірювань і фактів, куби служб Analysis Services містять об’єкти, які називаються measures (заходи). По суті, заходи – це особливі вимірювання куба, які представляють собою кількісні суті, використовувані для аналізу. Зазвичай заходи є частиною груп заходів (measure group), які використовуються для того, щоб зробити більш зручними для читання деякі інструменти навігації та проектування в кубі.


Заходи можна представити як набір стовпців даних, до якого може застосовуватися (або не застосовуватися) користувальницьке вираз (обчислення). Наприклад, переглядаючи проект AdventureWorks в Visual Studio, ми бачимо в кубі Adventure Works групу заходів “Sales Summary” (малюнок 2).


У групі заходів можна побачити кожну міру. Якщо двічі клацнути мишею на першій мірі в списку “Order Quantity”, відкриється діалогове вікно “Edit Measure”, показане на малюнку 3.


В даному випадку ми бачимо, що для стовпця OrderQuantity з таблиці Sales Summary Facts підведений підсумок (у списку Usage). Це означає, що дана міра просто є сумою всіх значень зі стовпця OrderQuantity або, логічно, суму за всіма замовленнями. Ще дві структури в кубі, про які слід мати уявлення – це members (члени) і cells (комірки). Кожна ієрархія вимірювань містить одне або більше включень цього значення в базовій таблиці вимірів. Наприклад, на малюнку 4 показано вимір Geography і члени “Australia” та “Canada”, які, в свою чергу, мають члени на кожному нижчому рівні ієрархії.


Осередки (cells) – це сутності, з яких ми витягуємо дані. Як і осередки в таблиці (хоча і більш складні за будовою), вони представляють собою перетин осей даних. На відміну від таблиці, значення якої часто є перетином двох осей, X і Y, осередок в кубі є перетин трьох осей: X, Y і Z. В даному випадку X, Y і Z є перетинами вимірювань. Крім того, кожен рівень ієрархії у вимірі перетинається з іншими рівнями ієрархії в інших вимірах. Саме наявність кількох рівнів перехрещень між вимірами на рівнях в їх ієрархіях робить куб таким ефективним.


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


Читати частина 2

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*