Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Правила переходу між рівнями представлення моделей даних

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

image283

Мал. 4.73. Процес трансформації моделей


Перехід до логічної моделі бази даних

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

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

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

Наприклад, інструментальне засіб СА BPWin Process Modeler надає можливість розробнику сформувати повні структури даних, включаючи їх атрибутивний складу, безпосередньо в інструментальному засобі, при побудові моделей потоків даних (ДПД, DFD). Безпосередня інтеграція з інструментом СЛ ERWin Data Modeler дозволяє, не виконуючи процедур формування сутностей, сформувати їх у моделі бази даних. Розробнику залишається тільки забезпечити встановлення зв'язків між сутностями і їх нормалізацію. Проблемою цього підходу є необхідність працювати з уже сформованими повними структурами даних, що часто викликає складнощі в коректності застосування правил нормалізації, оскільки протягом моделювання бізнес-процесів і потоків даних розробники описують документи або структури об'єктів, відомості про яких потрібно зберігати в базі даних, що не маючи можливості побудувати модель бази даних зі зв'язками і визначити правильність і повноту виділених структур.

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

Раніше, за допомогою інструментального засобу IBM WebSphere Business Modeler був описаний бізнес-процес реалізації товару в електронному магазині, де на потоках між бізнес-функціями і допоміжними функціями визначили деякі бізнес-елементи у вигляді певних структур даних, припускаючи їх подальше перетворення по суті логічної моделі бази даних. З огляду на цю особливість, розробник при описі бізнес-процесів вибудовує структури бізнес-елементів таким чином, щоб мати можливість застосувати правила нормалізації. У разі застосування документарного підходу до моделювання бази даних розробник на рівні опису бізнес-процесів буде максимально детально описувати атрибутивний складу кожного бізнес-елемента

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

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

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

Починається трансформація бізнес-елементів в структури моделі бази даних з вибору методу вивантаження (рис. 4.74). Для цього розробник, на базі IBM WebSphere Business Modeler, вибирає в контекстному меню проекту бізнес-процесів пункт "Експорт ..." і споживача вивантажених даних "InfoSphere Data Architect ..." Якщо вивантаження структур даних спрямована на подальше використання в засобі IBM InfoSphere Data Architect, то вибирається відповідний пункт вибору формату вивантаження. У разі використання сторонніх інструментальних засобів можна використовувати формат вивантаження "Текст з роздільниками (.csv, .txt)", що формує універсальне уявлення для використання в різних програмних засобах, включаючи Microsoft Excel.

image284

Мал. 4.74. Вибір споживача вивантажених структур даних


Наступним етапом є вказівка ​​панки на магнітному носії (жорсткий диск), куди необхідно зберегти вивантажені даних (рис. 4.75). При виборі варіанту InfoSphere Data Architect процедура експорту створить схеми ХМ L-документа з розширенням .xsd.

image285

Мал. 4.75. Вибір місця збереження вивантаження


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

image286

Мал. 4.76. Результат експорту бізнес-елементів


Перейшовши в інструментальне засіб IBM InfoSphere Data Architect в створеному проекті моделювання даних і використовуючи пункт "Import ..." контекстного меню проекту, запускають процедуру відновлення з розвантаженого файлу моделі бази даних. Оскільки відомості вивантажувалися із засобу, не призначеного для моделювання даних, то уявлення сутностей буде реалізовуватися на підставі атрибутів, зазначених в бізнес-елементах. У першому діалоговому вікні імпорту структур даних розробнику необхідно вибрати вид майстра формування моделі - Data Model Import Wizard (рис. 4.77).

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

  • • Model format (формат моделі) - вказується тип джерела даних для імпорту моделі, де, при використанні експортованої моделі з іншого спеціалізованого засобу моделювання структур даних, вказується его засіб, або, якщо шуканого кошти немає і формат вигру- женного файлу відповідає одному з варіантів , пропонованих для вибору;
  • • Model (модель) - указується файл, де збережені вивантажені відомості про структури даних;
  • • Target project (проект призначення) - вказує проект в робочому просторі інструментального кошти, в якому необхідно створити модель даних, використовуючи зазначений раніше файл;
  • • Model type (тип моделі) - вказує варіант створюваної моделі бази даних (логічна або фізична), але, за замовчуванням, інструментальне кошти пропонує використовувати автовизначення (Auto detect) створюваної моделі;
  • • File name (ім'я файлу) - вказується ім'я файлу моделі, яка придбає відповідне типу моделі розширення.

image287

Мал. 4.77. Вибір майстра формування моделі


Врахувавши вказані властивості, інструментальне засіб створить необхідний файл моделі бази даних, куди із зазначеного експортованого (вивантаженого) файлу будуть взяті відомості про структури даних.

Наступний набір властивостей вказує додаткові характеристики імпорту моделі бази даних (рис. 4.78), визначаючи кожен атрибут самостійним сутнісним елементом (сутністю) в моделі бази даних, з якими необхідно проводити нормалізацію.

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

image288

Мал. 4.78. Установка основних параметрів імпорту


image289

Мал. 4.79. Встановлення додаткових параметрів імпорту



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

Принцип "навантаження" файлу ідентичний варіанту імпорту моделі, що припускає вибір пункту "Import ..." контекстного меню проекту, але в якості типу майстра вибирають варіант "File System" (Файлова система), після чого, взявши файл експорту з середовища бізнес-моделювання і проект отримання файлу, формують схему XML-даних із зазначенням всіх атрибутивних і сутнісних елементів, як вони були представлені при моделюванні бізнес-процесів (рис. 4.80).

image290

Мал. 4.80. Приклад XML-схеми, імпортованої в середу моделювання


Подальший перехід до моделі бази даних грунтується на визначенні правил трансформації XML-схеми в модель бази даних (рис. 4.81), для чого необхідно створити правило трансформації через пункт "New / Transformation Configuration" (Новий / Конфігурація трансформації) контекстного меню розділу проекту "Data Models "(Моделі даних).

Для забезпечення трансформації розробнику необхідно вказати тип трансформації "XML Schema to Logical Data Model" і проект призначення для реалізації моделі. Щоб інструментальне засіб знало про джерело відомостей по інформаційній структурі об'єктів і документів, необхідно вказати саме завантажений в проект файл XSD, а не сам проект (рис. 4.82).

В рамках останнього вказівки параметрів трансформації від розробника потрібно визначити дії по відношенню до ключових атрибутів (рис. 4.83):

• Generate surrogate key (Створювати сурогатний ключ) - властивість визначає необхідність генерування первинного ключа для структурних елементів, з метою подальшого формування зчеплених первинних ключів по зв'язаних сутностей.


  • • Merge entities as attributes, where appropriate (Об'єднати суті як атрибути, коли необхідно) - властивість визначає можливість подання створюваних сутностей у вигляді атрибутів інших сутностей в разі, коли бізнес-елемент визначено атрибутом іншого бізнес-елемента.
  • • Overwrite files without warning (Замінити файли без попередження) - властивість забезпечує необхідність запитати у розробника необхідність перезапису файлу моделі бази даних, якщо вона вже існує.
  • • Prefix foreign key attribute name with inverse verb phrase (Використовувати префікс зовнішнього ключа із зазначенням смисловий фрази) - властивість вказує на необхідність відображення в моделі па зв'язку смислового наповнення по створюваному зовнішньому ключу.

image291

Мал. 4.81. Вибір основних параметрів трансформації


image292

Мал. 4.82. Вказівка джерела схеми і одержувача моделі


В результаті виконання зазначених дій буде створена конфігурація трансформації файлу експорту структур даних у вигляді схеми XML (рис. 4.84), яку можна запустити на виконання і отримати модель бази даних, відповідну вказаним у файлі характеристикам.

image293

Мал. 4.83. Визначення параметрів для створюваних атрибутів


image294

Мал. 4.84. Створена конфігурація трансформації


Для того, щоб трансформація була запущена, необхідно використовувати кнопку "Run" (Запустити) у відкритому вікні конфігурації (рис. 4.85). Виконання налаштованого алгоритму трансформації призведе до появи моделі бази даних з набором сутностей і зв'язків між ними.

image295

Мал. 4.85. Результат трансформації ХМЬ-схеми в логічну модель бази даних


В результаті трансформації ХМЬ-схеми, експортованої з моделі бізнес-процесів, виходять суті відповідно до назв бізнес-елементів (рис. 4.86). Важливо відзначити, що застосування національних алфавітів при іменуванні атрибутів і бізнес-елементів призводить до того, що в моделі бази даних наявні прогалини між словами видаляються і найменування стають злитими (без пробілів). При використанні

image296

Мал. 4.86. Модель бази даних після трансформації


латиниці проблеми з пробілами не виникає. Однак навіть при використанні національних алфавітів можна уникнути цієї проблеми, визначивши правила трансформації, створивши спеціальну модель імен (Glossary Model) [1] , яка містить макро правила, що застосовуються при трансформації моделей і нормалізації зв'язків.

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

- Зв'язки між сутностями визначаються типом один - до - одному (1: 1) і потужністю по обидва боки зв'язків "0,1", що вимагає подальшого перегляду всіх існуючих зв'язків;

смислові фрази, що описують суть зв'язків між сутностями, визначаються іменниками, що характеризують відношення дочірньої сутності до батьківської, що некоректно по суті формулювання, яка повинна бути представлена ​​дієслівної формою;

  • - Якщо в процесі моделювання бізнес-процесів залишилися бізнес- елементи, не пов'язані з іншими бізнес-елементами, то вони в моделі також будуть представлені окремими сутностями;
  • - Розмірності атрибутів за типами даних, де виникне потреба у вказівках кількості символів (зазвичай символьні і атрибути тексту), вказується в максимальній розмірності.

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

  • [1] В рамках даного підручника питання використання макромови при трансформації моделей не розглядається.
 
<<   ЗМІСТ   >>