Проектування сховищ даних за допомогою ERwin, CASE-засоби (моделювання), Програмування, статті

Сховища даних (Data Warehouse) представляють собою спеціалізовані бази даних, призначені для зберігання даних, які рідко змінюються, але на основі яких часто потрібне виконання складних запитів. Зазвичай вони орієнтовані на виконання аналітичних запитів, які забезпечують підтримку прийняття рішень для керівників і менеджерів. Сховища даних дозволяють розвантажити промислові бази даних, і тим самим дозволяють користувачам більш ефективно і швидко витягати необхідну інформацію. Як правило, сховища даних оперують з величезними обсягами інформації, що пред’являє до їх проектування та реалізації підвищені вимоги. Вибір в якості платформи сховища даних такої високопродуктивної РСУБД дозволяє істотно підвищити загальну ефективність створюваної інформаційної системи. В цьому випадку ERwin (CASE-засіб фірми PLATINUM Technology inc.) Стає незамінним інструментом, оскільки з одного боку ефективно підтримує на фізичному рівні проектування об’єктів РСУБД, з іншого боку має спеціалізовані засоби моделювання сховищ даних. Нижче розглядаються основні можливості ERwin з проектування сховищ даних.

До проектування сховищ даних звичайно ставляться такі вимоги:


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

Для ефективного проектування сховищ даних ERwin використовує розмірну (Dimensional) модель. Dimensional – методологія проектування, спеціально призначена для розробки сховищ даних. ERwin підтримує методологію розмірного моделювання завдяки використанню спеціальної нотації для фізичної моделі – Dimensional. Найбільш простий спосіб перейти до нотації Dimensional – при створенні нової моделі (меню File / New) в діалозі ERwin Teamplate Selection вибрати зі списку пропонованих шаблонів DIMENSION. В шаблоні DIMENSION зроблені всі необхідні для підтримки нотації розмірного моделювання настройки, які, втім, можна встановити вручну.

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

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

Схема зірка зазвичай містить одну велику таблицю, яка називається таблицею факту (fact table), поміщену в центр, і навколишні її менші таблиці, звані таблицями розмірності (dimensional table), з’єднаними c таблицею факту у вигляді зірки радіальними зв’язками. У цих зв’язках таблиці розмірності є батьківськими, таблиця факту-дочірньої. Схема зірка може мати також консольні таблиці (outrigger table), приєднані до таблиці розмірності. Консольні таблиці є батьківськими, таблиці розмірності – дочірніми.

В розмірної моделі, ERwin позначає іконкою роль таблиці в схемі зірка:















 
Таблиця факту (fact table)




 
Таблиця розмірності (dimensional table)




 
Консольна таблиця (outrigger table)

Перш ніж створити базу даних зі схемою типу зірка, необхідно проаналізувати бізнес-правила предметної області, з метою з’ясування центрального питання, відповідь на який найбільш важливий. Всі інші питання повинні бути об’єднані навколо цього основного питання і моделювання повинно починатися з цього основного питання. Дані, необхідні для відповіді на це питання, повинні бути поміщені в центральну таблицю моделі – таблицю факту. Наприклад, якщо необхідно створювати звіти про загальну суму доходу від продажів за період, або по типу товару, або за продавцям, слід розробляти модель так, щоб кожен запис у таблиці факту представляла загальну суму продажу, для кожного клієнта за певний період часу для кожного продавця (рис.1). У прикладі таблиця факту містить сумарні дані про продажі (“SALE”), а таблиці розмірності містять дані про замовника і замовленнях (“CUSTOMER”), продуктах (“PRODUCT”), продавців (“SALESPEOPLE”) та періоди часу (“TIME”).

Рис. 1. Схема зірка.

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

Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності. У прикладі (таблиця факту “SALE”) первинний ключ складається з чотирьох зовнішніх ключів: CustomerID, SalespeopleID, TimeID і ProductID.

Таблиці розмірності мають меншу кількість рядків, ніж таблиці факту і містять описову інформацію. Ці таблиці дозволяють користувачеві швидко переходити від таблиці факту до додаткової інформації.

У прикладі на рис.1 таблиця “SALE” – таблиця факту; “CUSTOMER”, “TIME”, “SALESPEOPLE” і “PRODUCT” – таблиці розмірності, які дозволяють швидко отримувати інформацію про те, хто і коли зробив покупку, який продавець і на яку суму продав, і які саме товари були продані.

ERwin підтримує використання вторинних таблиць розмірності, званих консольними (outrigger) таблицями, хоча вони не потрібні для схеми зірка. Консольні таблиці можуть бути пов’язані тільки таблицями розмірності, причому консольна таблиця в цьому зв’язку батьківська, а таблиця розмірності – дочірня. Зв’язок може бути ідентифікуючої або неідентіфіцірующей. Консольна таблиця не може бути пов’язана таблицею факту. Вона використовується для нормалізації даних в таблицях розмірності. Нормалізація даних корисна при моделюванні реляційної структури, але вона зменшує ефективність виконання запитів до сховища даних.

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

Рис. 2. Схема сніжинка.

У діалозі опису властивостей таблиці Table Editor є закладка Dimensional, в якій задаються специфічні властивості таблиці в розмірної моделі (рис. 3):

Рис. 3. Закладка Dimensional діалогу Table Editor.

Роль таблиці в схемі (Dimensional Modeling Role). За замовчуванням Erwin автоматично визначає роль таблиці на підставі створених зв’язків (таблиця факту, розмірності або консольна). Таблиця без зв’язків визначається як таблиця розмірності, таблиця факту не може бути батьківського в зв’язку, таблиця розмірності може бути батьківського по відношенню до таблиці факту, консольна таблиця може бути батьківського по відношенню до таблиці розмірності. При ручному призначенні ролі таблиці ERwin автоматично перевіряє коректність розмірної моделі і видає діалог з попереджуючим повідомленням в разі наступних порушень синтаксису:

Тип таблиці розмірності (Dimension Type). Кожна таблиця розмірності може містити незмінні, або рідко змінювані дані (slowly changing dimensions).

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


  1. Перезапису старих даних новими. При цьому старі дані губляться.
  2. Створення нового запису в таблиці розмірності з новими даними і часом зміни. В цьому випадку зберігаються старі дані і можна прослідкувати історію зміни редагованих даних, але необхідно генерувати ключ для посилання на старі дані.
  3. Запис нових даних у додатковому полі тієї ж самої запису. В цьому випадку зберігається початкове і останнє нове значення. Всі проміжні дані губляться.
Правила зберігання даних (Data Warehouse Rules). Для кожної таблиці можна задати шість типів правил маніпулювання даними: оновлення (Refresh), додаток (Append), резервне копіювання (Backup), відновлення (Recovery), архівування (Archiving) і очищення (Purge). Для завдання правила слід вибрати ім’я правила з відповідного списку вибору. Кожне правило має бути попередньо описано в діалозі Data Warehouse Rule Editor (Меню Edit / Data Warehouse Rule). Для кожного правила повинно бути задано ім’я, тип, визначення. Наприклад, визначення правила доповнення даних може включати частоту і час доповнення (щоденно, в Наприкінці робочого дня), тривалість операції і т.д. Зв’язати правила з певною таблицею можна за допомогою діалогу Table Editor.

При проектуванні сховища даних важливо визначити джерело даних (для кожної колонки), метод, яким вихідні дані витягуються, перетворюються, і фільтруються перш, ніж вони імпортуються в сховище даних. Сховище даних може об’єднувати інформацію з текстових файлів і багатьох баз даних, як реляційних (у тому числі інших БД на платформі Informix), так і нереляційних, в єдину систему підтримки прийняття рішень. Щоб підтримувати регулярні оновлення та перевірки якості даних, необхідно знати джерело для кожної колонки в сховище даних. Для документування інформації про джерела даних використовується редактор Data Warehouse Source Editor (Рис. 4.).

Рис. 4. Діалог Data Warehouse Source Editor.

Імена таблиць і колонок джерел даних можуть бути імпортовані як з баз даних (зворотне проектування), так і з інших моделей ERwin. Кожному джерела може бути задано ім’я та визначення.

В редакторі Column Editor необхідно внести інформацію про використання джерел даних для кожної колонки таблиць сховища даних, а так само додаткову інформацію про способи, режимах і періодичності перенесення даних з джерела в сховище даних.


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


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

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

Ваш отзыв

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

*

*