Створення та обробка баз даних на ПЕОМ (стр. 11 )

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

Посилальна цілісність — це забезпечення вимоги, щоб значення зовнішнього ключа екземпляра дочірньої сутності відповідали значенням первинного ключа в батьківській сутності. Посилальна цілісність може контролюватися при всіх операціях, що змінюють дані (INSERT/UPDATE/DELETE). Засобу контролю посилальної цілісності в ERwin включають автоматичну генерацію тригерів і використання механізмів декларативної посилальної цілісності (для тих СУБД, що підтримують дані механізми).

Для кожного зв'язку на логічному рівні можуть бути задані вимоги по обробці операцій INSERT/UPDATE/DELETE для батьківської і дочірньої сутності. ERwin представляє наступні варіанти обробки цих подій:

•  відсутність перевірки;

•  перевірка допустимості;

•  заборона операції;

•  каскадне  виконання  операції
(DELETE/UPDATE);

•  установка  порожнього  (NULL-значення)
або заданого значення за замовчуванням.

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

Звичайно моделі ERwin зберігаються на диску у виді файлу. Мається можливість зберігати модель у цільовий СУБД. Для цього за допомогою самого ERwin у цільовий СУБД створюється позначка-база ERwin. У цій базі даних зберігається інформація моделі. В окремому випадку базою даних можуть бути і dBase-файли, з якими ERwin працює через ODBC.

3.6. Проектування сховищ даних за допомогою CASE системи ERwin

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

Нижче розглядаються основні можливості ERwin по проектуванню сховищ даних.

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

Структура дані сховища повинна бути зрозуміла користувачам; Повинні бути виділені статичні дані, що регулярно модифікуються: щодня, щотижня, щокварталу; Повинні бути спрощені вимоги до запитів з метою виключення запитів, що могли б вимагати множинних тверджень SQL у традиційних реляційних СУБД; Повинна бути забезпечена підтримка складних запитів SQL, що вимагають послідовної обробки тисяч або мільйонів записів.

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

Для ефективного проектування сховищ даних 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).

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

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

Таблиця факту є центральною таблицею в схемі зірка. Вона може складатися з мільйонів рядків і містити підсумовуючі або фактичні дані, що можуть допомогти відповісти на необхідні питання. Вона з'єднує дані, що зберігалися б у багатьох таблицях традиційних реляційних базах даних. Таблиця факту і таблиці розмірності зв'язані ідентифікуючими зв'язками, при цьому первинні ключі таблиці розмірності мігрують у таблицю факту як зовнішні ключі. У розмірній моделі напрямку зв'язків явно не показуються – вони визначаються типом таблиць. Первинний ключ таблиці факту цілком складається з первинних ключів усіх таблиць розмірності. У прикладі (таблиця факту «SALE») первинний ключ складений з чотирьох зовнішніх ключів: CustomerID, SalespeopleID, TimeID і ProductID.

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

У прикладі на мал. 3.8 , таблиця «SALE» - таблиця факту; «CUSTOMER», «TIME», «SALESPEOPLE» і «PRODUCT» - таблиці розмірності, що дозволяють швидко витягати інформацію про тім хто і коли зробив покупку, який продавець і на яку суму продав і які саме товари були продані.

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

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

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