Первая страница
Наша команда
Контакты
О нас

    Головна сторінка



Ярцев в. П. Створення та обробка баз даних на пеом

Ярцев в. П. Створення та обробка баз даних на пеом




Сторінка5/20
Дата конвертації10.03.2017
Розмір2.36 Mb.
ТипПротокол
1   2   3   4   5   6   7   8   9   ...   20

Код групи


Найменування

Староста


Спеціальність

………………


Табельний номер


ФІП

Кафедра


………………..






Належить Викладає



Студент



Група

Код студента


ФІП

Рік народження

Номер залікової книжки

Фотографія

……………………

Предмет


Код предмету


Найменування

Програма


…………….






Заняття

Бере участь по предметах

н
Успішність


а заняттях

Вид заняття


Дата

Оцінка


Рис. 3.5. Граф-схема моделі “сутність-зв'язок” навчальної БД


3.4. Перехід до реляційної моделі

Модель “сутність-зв'язок” перетворюється у реляційну модель відповідно до наступних правил:



  1. Кожної сутності ставиться у відповідність відношення реляційної моделі. Імена сутностей і відношень можуть відрізнятися. При цьому враховуються вимоги обраної СУБД до імен відношень (таблиць).

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

  3. Первинний ключ сутності стає первинним ключем відношення.

  4. У кожному відношенні, яке представляє відповідну підлеглу сутність (в зв'язку типу “1:М”), додається набір тих атрибутів з основної сутності, які у неї є первинним ключем. У відношенні, що відповідає підлеглої сутності, цей набір атрибутів стає зовнішнім ключем. Відповідний зв'язок “1:М” позначається умовою рівності значень цих атрибутів, які тепер стали зовнішнім ключем.

На Рис. 3.6 приведено схему відношень, яка отримана після перетворення моделі “сутність-зв'язок”, граф якої був побудований вище і зображений на Рис. 3.5. Первинні ключі на схемі відношень позначені напівжирним шрифтом.

На схемі відносин типи даних зазначені в припущенні, що в якості СУБД обрана MS Access.













Код_Груп = Код_Груп Таб_ном = Таб_ном


Студент




Код_Cтуд Числовий


Код_Груп Числовий

ПІП Текстовий

Год_Народж Числовий

Ном_Зач_Кн Текстовий

Фото Гиперпосилання












Код_Студ = Код_Студ Код_Пред = Код_Пред

Успішність

Вид_Зан Текстовий

Дата Дата/Час


Код_Студ Числовий

Код_Пред Числовий

Оцінка Числовий

Рис. 3.6. Схема відносин реляційної БД



3.5. Застосування CASE-засобу ERwin  для проектування БД


 

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

Інформаційна модель - це специфікація структури даних і бізнес правил (правил предметної області).

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


3.5.1. Інформаційне моделювання

Розглянемо деякі аспекти інформаційного моделювання і його автоматизації з використанням Кошт-CASE-засобу ERwin 3.5 фірми LogicWorks (рис.3.7).

ERwin — засіб розробки структури бази даних (БД). ERwin сполучить графічний інтерфейс Windows, інструменти для побудови ER-діаграм, редактори для створення логічного і фізичного опису моделі даних і прозору підтримку ведучих реляційних СУБД і настільних баз даних.

Рис.3.7. Інтерфейс програми ERwin


За допомогою ERwin можна створювати або проводити зворотне проектування (реінжиніринг) баз даних.

У  ERwin реалізований ряд  функцій:

•    пряме підключення до бази даних: створення структури бази даних безпосередньо з ERwin, відновлення моделі існуючої БД;

•    перехід від однієї цільової бази даних до іншої з використанням  взаємно однозначних відповідностей особливостей СУБД;

•   підтримка «настільних» (desktop) СУБД;

•    керування фізичними характеристика­ мі збереження даних

(для Oracle і Sybase  — табличним простором і сегментами відповідно);

•    розбивка діаграми на функціонально закінчені частини — логічні області;

•   збережені набори параметрів відображення для побудови звітів і діаграм;

•    процедури і тригери описуються при побудові моделі й автоматично створюються в БД при генерації;

•   технологія «drag and drop» для маніпулювання атрибутами;

•   можливість збереження діаграми в цільовій базі даних або в DBF файлах;

•   підтримка   системи   контролю   версій PVCS фірми Intersolv;

•   шрифтове і колірне виділення.

Реалізація моделювання в ERwin базується на теорії реляційних баз даних і на методології IDEF1X.

Методологія IDEF1X була розроблена для ВВС США і тепер використовується, зокрема, в урядових, аерокосмічних і фінансових установах, а також у великому числі приватних компаній.

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

Можливі дві точки зору на інформаційну модель і, відповідно, два рівні моделі.

Аспект (лат. aspectus - вигляд, погляд) - поняття філософії (онтології, теорії пізнання). У філософії аспект розглядається
Перший — логічний (точка зору користувача) — описує дані, задіяні в бізнесі підприємства. Другий — фізичний — визначає представлення інформації в БД. ERwin поєднує них у єдину діаграму, що має кілька рівнів представлення ".

Процес побудови інформаційної моделі складається з наступних кроків:

- визначення сутностей;

- визначення        залежностей        між сутностями;

- завдання   первинних   і   альтернативних ключів;

- визначення атрибутів сутностей;

- приведення      моделі      до     необхідного рівня нормальної форми;

- перехід до фізичного опису моделі: призначення відповідностей ім'я сутності - ім'я таблиці, атрибут сутності - атрибут таблиці; завдання тригерів, процедур і обмежень;

- генерація бази даних.

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

3.5.2. Відображення логічного і фізичного рівня моделі  даних у ERwin


У ERwin існують два рівні представлення і моделювання — логічний і фізичний.

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

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

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

Діагра́ма - (від грец. Διάγραμμα (diagramma) - зображення - малюнок , креслення) - графічне зображення, що наочно у вигляді певних геометричних фігур показує співвідношення між різними величинами, які порівнюються.

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

•   Режим «сутності» - усередині прямокутників відображається ім'я сутності (для логічної моделі) або ім'я таблиці (для фізичного представлення моделі); служить для зручності огляду великої діаграми  або  розміщення прямокутників сутностей на діаграмі.

•   Режим «визначення сутності» служить для презентації діаграми іншим людям.



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

•   Режим «первинні ключі» — усередині прямокутників - сутностей показуються тільки атрибути/стовпчика, що складають  первинний ключ.

•   Режим «піктограми». Для презентаційних цілей кожній таблиці може бути поставлена у відповідність піктограма (bitmap).

•   Режим «показ дієслівної фрази». На дугах зв'язків показуються дієслівні фрази, що зв'язують сутності  (для логічного рівня)  або імена зовнішніх ключів (для фізичного рівня).

Діаграма може займати більш ніж один екран і більш ніж один лист при печатці. Для огляду моделі передбачені, крім прокручувань екрана, режими зменшення зображення в два і чотири рази.

3.5.3. Інструменти для створення моделі в ERwin

Основні інструменти створення моделі доступні як з меню, так і через вікно інструментів. З їхньою допомогою створюються незалежні і залежні сутності, що ідентифікують і не ідентифікують зв'язки, повні і неповні категорії, неспецифічні зв'язки і текстові елементи.

Натисканням миші над сутністю виробляється вхід в один з численних редакторів ERwin:

•   редактори, зв'язані із сутністю в цілому   (визначення  сутності,  додаткова інформація, тригери, індекси, характеристики таблиці, збережені процедури, зв'язані з таблицею);

•   редактори атрибутів (визначення атрибутів, стовпчика таблиці у фізичному представленні моделі, репозитарій засобу 4GL, наприклад, розширені атрибути в PowerBuilder.

На діаграмі сутність зображується прямокутником. У залежності від режиму представлення діаграми прямокутник може містити ім'я сутності, її опис, список її атрибутів і інші зведення.

Горизонтальна лінія прямокутника розділяє атрибути сутності на два набори — атрибути, що складають первинний ключ у верхній частині, та інші (не вхідні в первинних ключ) — у нижній частині.

Сутність являє собою безліч реальних або абстрактних об'єктів, наприклад: люди, місця, події, факти, що мають загальні характеристики. Сутність — це логічне поняття. Сутності відповідає таблиця в реальної СУБД. У ERwin сутність візуально представляє три основних види інформації:

•  атрибути, що складають первинний ключ;

•  не ключові атрибути;

•  тип сутності (незалежна/залежна).

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

Для кожного первинного ключа ERwin створює при генерації структури БД унікальний індекс.

Екземпляри незалежної сутності можуть бути унікально ідентифіковані без визначення її зв'язків з іншими сутностями; залежна сутність, навпаки, не може бути унікально ідентифікована без визначення її зв'язків з іншими сутностями. Залежна сутність відображається в ERwin прямокутником із закругленими кутами.

Зв'язок - це функціональна залежність між двома сутностями (зокрема, можливий зв'язок сутності із самої собою).

Функціональна залежність (далі часто ФЗ) - концепція, що лежить в основі багатьох питань, пов'язаних з реляційними базами даних, включаючи, зокрема, їхнє проектування. Математично являє собою бінарне відношення між множинами атрибутів даного відношення і є, по суті, зв'язком типу «один-до-багатьох».
Наприклад, важливо знати прізвище співробітника, і не менш важливо знати, у якому відділі він працює. Таким чином, між сутностями «відділ» і «співробітник» існує зв’язок який «складається з» (відділ складається зі співробітників). Зв'язок — це поняття логічного рівня, якому відповідає зовнішній ключ на фізичному рівні. У ERwin зв'язки представлені п'ятьма основними елементами інформації:

•  тип зв'язку (ідентифікуюча, не ідентифікуюча,   повна/неповна   категорія, неспецифічний зв'язок);

•  батьківська сутність;

•  дочірня (залежна) сутність;

•  потужність зв'язку (cardinality);

•  допустимість порожніх (null) значень.


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

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

Для визначення зв'язків ERwin вибирається тип зв'язку, потім мишею вказується батьківська і дочірня сутність. Ідентифікуючий зв'язок зображується суцільною лінією; не ідентифікуюча — пунктирною лінією. Лінії закінчуються крапкою з боку дочірньої сутності.

При визначенні зв'язку відбувається міграція атрибутів первинного ключа батьківської сутності у відповідну область атрибутів дочірньої сутності. Тому такі атрибути не уводяться вручну.

Атрибути первинного ключа батьківської сутності за замовчуванням мігрують зі своїми іменами. ERwin дозволяє ввести для них ролі, тобто нові імена, під якими мігруючі атрибути будуть представлені в дочірній сутності. У випадку кількаразової міграції атрибута таке перейменування необхідне. Наприклад, сутність «посередницька угода» має атрибут «код підприємства-продавця» і «код підприємства-покупця». У даному випадку первинний ключ сутності «підприємство» («код підприємства») має двох ролей у дочірній сутності.

На фізичному рівні ім'я ролі — це ім'я стовпчика зовнішнього ключа в дочірній таблиці.

Потужність зв'язку являє собою відношення кількості екземплярів батьківської сутності до відповідної кількості екземплярів дочірньої сутності. Для будь-якого зв'язку, крім неспецифічної, цей зв'язок записується як l:n.

ERwin, відповідно до методології IDEF1X, надає 4 варіанти для n, що зображуються додатковим символом у дочірньої сутності:

•  нуль, один або більше (за замовчуванням);

•  один або більше (зображується буквою «Р»);

•  нуль або один (зображується буквою «Z»);

•  рівно   N,   де   N   —   конкретне   число (зображується числом N).

Допустимість порожніх (NULL) значень у не ідентифікуючих зв'язках ERwin зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.

Ім'я зв'язку на логічному рівні являє собою «дієслово», що зв'язує сутності. Фізичне ім'я зв'язку (яке може відрізнятися від логічного) для ERwin означає ім'я обмеження (constraint) або індексу.

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

Альтернативний ключ - це атрибут (або група атрибутів), незбіжний з первинним ключем і унікально ідентифікуючий екземпляр сутності. Наприклад, для сутності службовець (ідентифікатор що служить, прізвище, ім'я, по батькові) група атрибутів «прізвище», «ім'я», «по батькові» можуть бути альтернативним ключем (у припущенні, що на підприємстві не працюють повні тезки).

Для альтернативного ключа, як і для первинного, ERwin автоматично створює індекси при генерації БД.

Атрибути, що складають альтернативний ключ, однозначно (унікально) ідентифікують екземпляри сутності. У ERwin можна також складати групи атрибутів, що не ідентифікують унікально екземпляри сутності, але часто використовуються для доступу до даних. Для кожної такої групи атрибутів ERwin створює не унікальні індекси.

Ті самі атрибути сутності можуть входити в кілька різних груп ключів.

•  тип зв'язку (ідентифікуюча, не ідентифікуюча,  повна/неповна категорія,


неспецифічний зв'язок);

•  батьківська сутність;

•  дочірня (залежна) сутність;

•  потужність зв'язку (cardinality);

•  допустимість порожніх (null) значень.
Зв'язок називається ідентифікуючої, якщо екземпляр дочірньої сутності ідентифікується через її зв'язок з батьківською сутністю. Атрибути, що складають первинний ключ батьківської сутності, при цьому входять у первинний ключ дочірньої сутності. Дочірня сутність при ідентифікуючому зв'язку завжди є залежною.

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

Для визначення зв'язків ERwin вибирається тип зв'язку, потім мишею вказується батьківська і дочірня сутність. Ідентифікуючий зв'язок зображується суцільною лінією; не ідентифікуюча — пунктирною лінією. Лінії закінчуються крапкою з боку дочірньої сутності.

При визначенні зв'язку відбувається міграція атрибутів первинного ключа батьківської сутності у відповідну область атрибутів дочірньої сутності. Тому такі атрибути не уводяться вручну.

Атрибути первинного ключа батьківської сутності за замовчуванням мігрують зі своїми іменами. ERwin дозволяє ввести для них ролі, тобто нові імена, під якими мігруючі атрибути будуть представлені в дочірній сутності. У випадку кількаразової міграції атрибута таке перейменування необхідне. Наприклад, сутність «посередницька угода» має атрибут «код підприємства-продавця» і «код підприємства-покупця». У даному випадку первинний ключ сутності «підприємство» («код підприємства») має двох ролей у дочірній сутності.

На фізичному рівні ім'я ролі — це ім'я стовпчика зовнішнього ключа в дочірній таблиці.

Допустимість порожніх (NULL) значень у не ідентифікуючих зв'язках ERwin зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.

Ім'я зв'язку на логічному рівні являє собою «дієслово», що зв'язує сутності. Фізичне ім'я зв'язку (яке може відрізнятися від логічного) для ERwin означає ім'я обмеження (constraint) або індексу.

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

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

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

Різна частина (наприклад, дані погодинної оплати для тимчасових працівників і дані про зарплату і відпустку для штатних працівників) міститься в сутності-підтипи.

У сутності супертипе вводиться атрибут-дискримінатор, що дозволяє розрізняти конкретні екземпляри сутності — підтипу.

У залежності від того, чи всі можливі сутності-підтипи включені в модель, категорійний зв'язок є повною або неповною. Продовжуючи приклад, якщо супертип може містити дані про звільнених співробітників, те цей зв'язок - неповної катетеризації, тому що для нього не існує запису в сутностях - підтипах. У 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) являють собою спеціалізовані бази даних, призначені для збереження даних, що рідко міняються, але на основі яких часто потрібне виконання складних запитів. Звичайно вони орієнтовані на виконання аналітичних запитів, що забезпечують підтримку прийняття рішень для керівників і менеджерів. Сховища даних дозволяють розвантажити промислові бази даних, і тим самим, дозволяють користувачам більш ефективно і швидко витягати необхідну інформацію.

Сховище даних (англ. 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):

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



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

  • Таблиця факту не є в зв'язку дочірньої;

  • Консольна таблиця не є в зв'язку батьківської;

  • Встановлено ідентифікуючий зв'язок між консольною таблицею і таблицею факту.

Тип таблиці розмірності (Dimension Type). Кожна таблиця розмірності може містити незмінні, або рідко змінювані дані (slowly changing dimensions). Оскільки сховище даних має ненормалізовану структуру, редагування таблиць розмірності може привести до колізій. Для того, щоб уникнути протиріч при збереженні даних, ERwin дозволяє задати тип рідко змінюваних даних, що відрізняється способом редагування даних:

- Модифікація старих даних новими, при цьому старі дані губляться.

- Створення нового запису в таблиці розмірності з новими даними і часом зміни. У цьому випадку зберігаються старі дані і можна простежити історію зміни редагування даних, але необхідно генерувати ключ для посилання на старі дані.

- Запис нових даних у додатковому полі того ж самого запису. У цьому випадку зберігається первісне й останнє нове значення. Усі проміжні дані губляться.



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

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

Те́кстовий файл - форма подання послідовності символів у комп'ютері, де кожен символ із задіяного набору символів кодується одним байтом чи послідовністю двох, трьох і т. д. байтів. На відміну від терміна «текстовий формат», що характеризує вміст даних, термін «текстовий файл» стосується файлу та характеризує його як контейнер, який зберігає такі дані.
Щоб підтримувати регулярні відновлення і перевірки якості даних, необхідно знати джерело для кожного стовпчика в сховище даних. Для документування інформації про джерела даних використовується редактор Data Warehouse Source Editor (рис.3.11.).



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

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

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



1   2   3   4   5   6   7   8   9   ...   20



  • Вид заняття Дата
  • Код_ C туд
  • Вид_Зан
  • 3.5. Застосування CASE-засобу ERwin для проектування БД
  • 3.5.1. Інформаційне моделювання
  • 3.5.2. Відображення логічного і фізичного рівня моделі даних у ERwin
  • 3.5.3. Інструменти для створення моделі в ERwin
  • 3.6. Проектування сховищ даних за допомогою CASE системи ERwin