14611

Проектування логічної структури сховища даних з архітектурою шини

Лабораторная работа

Информатика, кибернетика и программирование

8 Лабораторна робота № 2 з дисципліни: Технології сховищ даних на тему: Проектування логічної структури сховища даних з архітектурою шини Мета роботи: Вивчення порядку методів та засобів проектування і побудови сховища даних з архітекту...

Украинкский

2013-06-08

242.47 KB

11 чел.

8

Лабораторна робота № 2

з дисципліни:

«Технології сховищ даних»

на тему:

«Проектування логічної структури сховища даних з архітектурою шини»


Мета роботи: Вивчення порядку, методів та засобів проектування і побудови сховища даних з архітектурою шини та оцінка часу виконання запитів.

Теоретичні відомості

Рис. 1 подає альтернативний підхід до архітектури сховищ даних, відомий як Сховище даних з архітектурою шини, або підхід Ральфа Кімбола, або Просторове Сховище [61].

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

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

Рис 1. Просторове сховище даних.

На відміну від підходу Білла Інмона, просторові моделі будуються для обслуговування бізнес-процесів (які, у свою чергу, пов'язані з бізнес-показниками або бізнес-подіями), а не бізнес-відділів. Наприклад, дані про замовлення, які повинні бути доступні для загалькорпоративного використання, вносяться в просторове сховище даних тільки один раз, на відміну від КІФ-підходу, у якому їх довелося б тричі копіювати у вітрини даних відділів маркетинґу, продажів і фінансів. Після того, як у сховищі появляється інформація про основні бізнес-процеси, консолідовані просторові моделі можуть видавати їхні перехресні характеристики. Матриця корпоративного сховища даних з архітектурою шини виявляє й підсилює зв'язок між показниками бізнес-процесів (фактами) і описовими атрибутами (вимірами).

Підсумовуючи все вищевикладене, можна відзначити типові риси підходу Ральфа Кімбола.

1. Використання просторової моделі організації даних з архітектурою «зірка» (star scheme) – детальніше розглянуто далі.

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

3. Сховище даних з архітектурою шини має наступні характеристики:

  1.  воно просторове;
  2.  воно містить як дані про транзакції, так і сумарні дані;
  3.  воно містить вітрини даних, що описують тільки одну предметну область або мають тільки одну таблицю фактів (fact table);
  4.  вітрини даних додаються у міру необхідності;
  5.  воно може містити безліч вітрин даних у межах однієї бази даних.
  6.  Сховище даних не є єдиним фізичним репозиторієм (на відміну від підходу Білла Інмона). Це «віртуальне» сховище.

Є різні варіанти фізичної реалізації архітектури шини. Простіший варіант моделі – «зірка» (star schema) подає собою радіальну схему, у центрі розміщена головна таблиця фактів, що аналізуються, та пов’язаних з нею таблиць вимірів, що вміщують довідкову інформацію. Така схема оптимізується під найбільш поширені запити, тому реляційні таблиці вимірів можуть бути ненормалізованими. Якщо таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema).

Модель даних складається з двох типів таблиць: однієї таблиці фактів (fact table) – центр «зірки», і декількох таблиць вимірів (dimension table) за кількістю вимірів в моделі даних – проміння «зірки» (рис. 2).

Рис. 2. Фраґмент схеми сховища даних, виконаного в моделі «зірка», для відображення господарських операцій.

На відміну від корпоративного сховища, в якому для подання господарських операція, а саме продажу, використано 2 таблиці (Продаж_головна та Продаж_детальна), в архітектурі шина використано одну таблицю, яка є таблицею фактів і по якій у подальшому приймаються рішення.

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

В архітектурі «сніжинка» (рис. 3) таблиці вимірів також нормалізовані. Так, у порівнянні зі схемою сховища даних, поданою на рис. 2, таблиці вимірів Менеджер та Товар є нормалізованими.

Є різні варіанти фізичної реалізації архітектури шини. Простіший варіант моделі – «зірка» (star schema) подає собою радіальну схему, у центрі розміщена головна таблиця фактів, що аналізуються, та пов’язаних з нею таблиць вимірів, що вміщують довідкову інформацію. Така схема оптимізується під найбільш поширені запити, тому реляційні таблиці вимірів можуть бути ненормалізованими. Якщо таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema).

Модель даних складається з двох типів таблиць: однієї таблиці фактів (fact table) – центр «зірки», і декількох таблиць вимірів (dimension table) за кількістю вимірів в моделі даних – проміння «зірки» (рис. 2.)

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

Рис. 3. Фраґмент схеми сховища даних, виконаного в моделі «сніжинка», для відображення господарських операцій.

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

Зазначимо, що відношення вимірів залишаються сильно нормалізованими, а слабо нормалізоване відношення фактів використовується для збереження аґреґованих даних.

SQL-запит до схеми «зірка» зазвичай містить в собі:

  1.  одне або декілька з'єднань таблиці фактів з таблицями вимірів;
  2.  декілька фільтрів (SQL-оператор WHERE), вжитих до таблиці фактів або таблиць вимірів;
  3.  групування і аґреґацію за необхідними елементам ієрархії вимірів (dimension elements).

Запит до схеми «сніжинка» міститиме ще з’єднання для таблиць-підвимірів.

Приклад 1. Наведемо SQL-запит для визначення сум продажів по товарних групах для сховища даних, схема даних якого подана на рис. 3.

SELECT [Товарна група].[Назва], [Підстава].[Назва], SUM([Документ].[Первинна сума])

FROM [Підстава] INNER JOIN ([Товарна група] INNER JOIN ([Товар] INNER JOIN [Документ]

ON [Товар].[Код] = [Документ].[код товару])

ON [Товарна гурпа].[код] = [Товар].[код товарної групи])

ON [Підстава].[код] = [Документ].[код підстави]

GROUP BY [Товарна група].[Назва], [Підстава].[Назва];

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

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

Детальніше опишемо вимоги до таблиць фактів та вимірів.

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

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

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

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

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

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

Кожен факт має деяку ґранулярність, визначеною рівнями, з яких створюється їх комбінація значень вимірів. Наприклад, ґранулярність факту в кубі, поданому на рис. 2  — це (Місяць x Продукт x Угода). (Рік x Продукт x Угода) і (День x Продукт x Угода) — відповідно грубша і тонша ґранулярності.

Сховища даних, як правило, містять наступні типи фактів.

1. Події (event), принаймні, на рівні найбільшої ґранулярності, як правило, моделюють події реального світу, при цьому кожен факт описує певний екземпляр явища, що вивчається. Прикладами може служити продаж, клацання мишею на Web-сторінці або рух товарів на складі.

2. Миттєві знімки (snapshot) моделюють стан об'єкту в певний момент часу, такі як рівні наявності товарів в магазині або на складі та кількість користувачів Web-сайту. Один і той же екземпляр явища реального миру, наприклад, конкретна банка бобів, може виникати в декількох фактах.

3. Сукупні миттєві знімки (cumulative snapshot) містять інформацію про діяльність організації за певний відрізок часу. Наприклад, сукупний обсяг продажу за попередній період, включаючи поточний місяць, можна легко порівняти з показниками за відповідні місяці минулого року.

Сховище даних часто містить всі три типи фактів. Одні і ті ж початкові дані, наприклад, рух товарів на складі, можуть міститися в трьох різних типах кубів: потік товарів на складі, список товарів і потік за рік до поточної дати.

Хід роботи

Виконаємо команди:

use BetBattles

go

select * from sys.tables

go

Результатом отримаємо наявні у базі даних таблиці та інформацію про них рисунок 1.

Рис.1. Інформація про наявні в БД таблиці

  1.  Видалимо з таблиці Users поле Rate – для збереження загального рейтингу користувача буде використовуватися група All – у якій зберігатиметься його рейтинг:

use BetBattles

alter table Users

drop column  Rate

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

use BetBattles

alter table Users

add IsAdmin bit not null

 Результати змін таблиці відображено на рисунку 2.

Рис.2. Змінена таблиця Users

  1.  У таблиці Matches змінимо тип полів Command1 та Command2, а саме збільшимо його максимальний розмір до 35 символів:

use BetBattles

alter table Matches

alter column Command1 nvarchar(35) not null

alter table Matches

alter column Command2 nvarchar(35) not null

go

Рис. 3. Результат зміни розміру полів Command 1 та Command 2

  1.  До таблиці Groups додамо нове поле Description яке буде розповідати про те, для чого ж призначена ця група, а також перейменуємо її на Battles – адже ця назва більше відповідає контексту груп. Результат представлений на рисунку 4. Скрипт:

alter database Groups

SP_RENAME 'Groups', 'Battles'

go

alter table Battles

add [Description] nvarchar(500) null

Рис. 4. Перейменована таблиця Battles з доданим полем Description

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


 

А также другие работы, которые могут Вас заинтересовать

68129. Інтелектуальна гра «Літературна веселка» Ти завжди в серцях людей, Тарасе! 43.5 KB
  Шевченка розвивати логічне мислення виразне читання виховувати повагу до Шевченкового слова та цікавість до вивчення його творчості. Тарас Шевченко Тарас Це бунтівне пророче ім’я знайоме не тільки українцям а й усьому світові. Шевченко це криниця з джерельною водою яка втамовує духовну спрагу народу.
68130. Знайомство з країною Логікою 28.5 KB
  Сьогодні діти ми відправляємось у незвичайну подорож. Діти ходять до школи найкоротшим шляхом але можуть годинами блукати різноманітними лабіринтами. Діти імітують посадку на автобус і їзду. Ось компанія яка У якій послідовності сидять діти Боря Петрик Юрко Віра Стас Іра.
68131. Аналогія. Добір малюнків за аналогією 263.5 KB
  Тип уроку: урок засвоєння умінь і навичок Обладнання: геометричні фігури і предметні малюнки до гри Фотограф; індивідуальні набори геометричних фігур гралото малюнки з послідовністю. Міняю місцями фігури деякі взагалі прибираю. Всі фігури різного кольору А тепер відкрийте очі подивіться...
68132. Подорож по океану логічних завдань 27.5 KB
  Мета: Познайомити дітей з різними поняттями; розвивати мислення, мову, пам’ять, спостережливість; виховувати сміливість, рішучість. Хід уроку Повідомлення теми і мети уроку. Сьогодні ми вирушаємо у кругосвітню подорож на кораблі. Нас чекає багато різних пригод. Людина – мисляча істота. Думки словами виражає.
68133. Сумісні та несумісні поняття. Завдання для повторення 84.5 KB
  Мета: узагальнити й систематизувати знання учнів про поняття про сумісні та несумісні поняття вдосконалювати вміння учнів розв’язувати логічні завдання розвивати логічне мислення кмітливість увагу пам’ять уяву; виховувати любов до тварин пробуджувати пізнавальний інтерес до всього живого формувати самоосвітні...
68136. МОДЕРНІЗАЦІЯ ВИЩОЇ ОСВІТИ УКРАЇНИ: МЕХАНІЗМИ ІНСТИТУЦІЙНОГО РЕГУЛЮВАННЯ 188 KB
  Результативність та ефективність функціонування системи вищої освіти України на початку ХХІ століття забезпечуватиметься тільки у випадку, коли її не зв’язуватимуть вирішенням тимчасових завдань, породжених економіко-політичною нестабільністю, демографічною кризою, соціокультурним вакуумом.
68137. ДОСЛІДЖЕННЯ СПОЖИВНИХ ВЛАСТИВОСТЕЙ, ЯКОСТІ І ЗБЕРЕЖЕНОСТІ ПРЯНИКІВ ПОЛІПШЕНОГО СКЛАДУ 5.06 MB
  Основна сировина для пряників не забезпечує високої харчової і біологічної цінності готової продукції. Для оптимізації складу і поліпшення споживних властивостей пряників важливим завданням постає раціональне поєднання різних видів сировини натурального походження.