Сховища даних та їх проектування за допомогою CA ERwin, Інтеграція додатків і даних, Бази даних, статті

Проблеми ефективного використання цих

Корпоративні системи управління підприємством, створені на основі реляційних СУБД, як правило, ефективно вирішують завдання обліку, контролю та зберігання даних. Однак в силу своєї специфіки, реляційна структура не дозволяє вирішувати завдання аналізу наявної інформації з необхідною продуктивністю. Особливо гостро ця проблема стоїть у гетерогенних інформаційних середовищах, коли в центральному офісі організації та у філіях експлуатуються СУБД різних виробників (рис.1).

Рис.1. Гетерогенна інформаційне середовище.

Така ситуація часто виникає або в результаті злиття кoмпаній, коли компанія перетворюється на філію більшої, але при цьому нерентабельно перебудовувати історично сформовану інформаційну інфраструктуру, або внаслідок незадовільного управління, коли філії не дотримуються корпоративного стандарту і впроваджують власні інформаційні системи. Однією з основних завдань, що вирішуються в корпоративних інформаційних системах, є надання аналітичної інформації необхідної для прийняття рішень. Для підтримки прийняття рішення необхідний не один заздалегідь підготовлений звіт, а серія різноманітних звітів, причому менеджер не завжди уявляє, який саме звіт знадобиться йому в наступні півгодини. Наприклад, при аналізі продажів по компанії виявляється, що в лютому поточного року відбувся спад. Щоб з’ясувати причини спаду, необхідно переглянути звіт про продажі в регіонах. Звіт про продажі в регіонах показує, що спад відбувся, мабуть, через незадовільну роботу одного з філіалів, отже, необхідний звіт про роботу даної філії і т.д. і т.п. Організувати виконання таких звітів в гетерогенної середовищі вкрай складно. Для ефективного аналізу даних у цьому випадку необхідно об’єднувати в одному запиті дані з різнорідних джерел. В даний час існують монітори транзакцій і генератори звітів (наприклад, Crystal Reports), що володіють такою функціональністю, проте продуктивність таких систем не може бути високою. У процесі аналізу дані, необхідні для прийняття рішень повинні надходити до споживача в режимі реального часу. Якщо ж дані збираються з різних джерел, то, по-перше, звіт готується неприпустимо повільно, по-друге, інші програми, що працюють з реляційними СУБД під час виконання звіту швидше за все будуть помітно сповільнюватися.

Рішенням проблеми продуктивності є створення спеціалізованої бази даних – сховища даних (Data Warehouse), призначеної виключно для обробки та аналізу інформації (рис.2).

Рис.2. Приклад гетерогенної інформаційної системи, що включає сховище даних.

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



Очевидно, що для вирішення цього завдання необхідно використовувати спеціальні інструментальні засоби. Одним з таких інструментів є Erwin ERX-CASE-засіб фірми Computer Associates International, Inc.

Erwin ERX є незамінним інструментом для проектування сховищ даних з кількох причин:


  1. Хоча реалізувати сховище даних можна на будь-якому сервері БД, існують спеціалізовані сервера, спеціально призначені для підтримки сховищ даних. Erwin підтримує генерацію схеми БД для двох таких серверів – Teradata і Red Brick.
  2. Як було зазначено вище, при проектуванні сховища необхідно створювати докладні специфікації для всіх джерел даних, у тому числі самих різних типів. Erwin підтримує на фізичному рівні пряме і зворотне проектування об’єктів більш ніж для 21 типу БД, тому є ідеальним CASE-засобом для роботи з гетерогенними інформаційними системами.
  3. Для ефективного проектування сховищ даних ERwin використовує розмірну (Dimensional) модель. Dimensional – методологія проектування, спеціально призначена для розробки сховищ даних.

Розглянемо основні особливості техніки моделювання сховищ даних за допомогою Erwin.

Підтримка методології Dimensional

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

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

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

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

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

У розмірній моделі ERwin позначає іконкою роль таблиці у схемі зірка (рис.3)

Рис. 3. Позначення таблиць у схемі “зірка”.

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

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

Таблиця факту є центральною таблицею в схемі зірка. Вона може складатися з мільйонів рядків і містити підсумовуючі або фактичні дані, які можуть допомогти відповісти на необхідні запитання. Вона з’єднує дані, які зберігалися б у багатьох таблицях традиційних реляційних базах даних. Таблиця факту і таблиці розмірності пов’язані ідентифікуючими зв’язками, при цьому первинні ключі таблиці розмірності мігрують в таблицю факту в якості зовнішніх ключів. У розмірній моделі напрями зв’язків явно не показуються – вони визначаються типом таблиць. Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності. У прикладі (таблиця факту “REVENUE”) первинний ключ складається з чотирьох зовнішніх ключів: movie_key, market_key, customer_key і time_key.

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

У прикладі на рис. 4 Таблиця “REVENUE” – таблиця факту; “CUSTOMER”, “TIME”, “MOVIE” і “MARKET” – таблиці розмірності, які дозволяють швидко отримувати інформацію про те, хто і коли зробив покупку, який продавець і на яку суму продав і які саме товари були продані.

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

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

Рис. 5. Закладка 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 (рис.6.).

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

Джерело даних може бути описаний вручну в діалозі Data Warehouse Source Editor, або імпортовано. Як джерело при імпорті можуть бути використані інші моделі Erwin, що зберігаються у файлі, SQL – Скрипти, моделі, що зберігаються в репозиторії ModelMart, або системні каталоги СУБД, на основі яких в результаті зворотного проектування можуть бути створені моделі Erwin (рис.7).

Кожному джерела може бути задано ім’я та визначення.

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

Рис.8. Опис джерела даних для колонки сховища в діалозі Column Editor.

Підтримка спеціалізованих СУБД

Хоча сховище даних можна створити, використовуючи будь-яку СУБД, існують спеціалізовані СУБД, дозволяють значно збільшити продуктивність обробки даних при використанні схеми “зірка”. Erwin підтримує на фізичному рівні дві такі СУБД – Red Brick і Teradata. При прямому і зворотному проектуванні підтримуються специфічні властивості як Red Brick, так і Teradata.

Для Red Brick підтримуються специфічні властивості індексів:


Редактор Red Brick Physical Object Editor (меню Server / Red Brick Physical Object) дозволяє створювати сегменти (Segment) Red Brick і змінювати їх властивості:


Для кожної таблиці Red Brick можна вказати сегменти для зберігання даних та індексу первинного ключа, максимальна кількість сегментів (для версії 5) та максимальну кількість рядків у сегменті (для Red Brick версії 5).

Для Teradata Erwin також підтримує специфічні об’єкти фізичної пам’яті. У діалозі Teradata Physical Object Editor Editor (меню Server / Teradata Physical Object) можна створити бази даних Teradata і визначити їх властивості:


У закладці Physical Props діалогу Teradata Table Editor можна визначити параметри аудіювання та відновлення після збою:


Закладка Teradata MACRO діалогу Teradata Table Editor дозволяє створити шаблони для збережених процедур Teradata.


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


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

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

Ваш отзыв

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

*

*