Проектування баз даних з ERwin. Базові концепції моделювання даних. Частина 3, Інтеграція додатків і даних, Бази даних, статті

Частина 2


Фізична модель даних


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


В ERwin фізична модель є графічним представленням реально реалізованої бази даних. Фізична база даних буде складатися з таблиць, стовпців і зв’язків. Фізична модель залежить від платформи, обраної для реалізації, та вимог до використання даних. Фізична модель для IMS буде серйозно відрізнятися від такої ж моделі для Sybase. Фізична модель для OLAP-Звітів буде виглядати інакше, ніж модель для OLTP (оперативної обробки транзакцій).


Розробник моделі даних і адміністратор бази даних (DBA – database administrator) використовують логічну модель, вимоги до використання та стратегічні принципи формування архітектури корпорації для розробки фізичної моделі даних. Ви можете денормалізовать фізичну модель для поліпшення продуктивності, і створити подання для підтримки вимог до використання. У наступних розділах детально розглядається процес денормализация та створення уявлень.


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


Збір вимог до використання даних


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


Вимоги до використання включають:



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

Крім голови, секретаря і користувачів у сесії, присвяченій вимогам до використання, повинні брати участь розробник моделі, адміністратор бази даних і архітектор бази даних. Обговоренню повинні піддаватися вимоги користувача до історичних даних. Тривалість періоду часу, протягом якого зберігаються дані, значно впливає на розмір бази даних. Часто старіші дані зберігаються в узагальненому вигляді, а атомарні дані архівуються або видаляються.


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


Компоненти фізичної моделі даних


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


Деякі логічні відносини неможливо реалізувати у фізичній базі даних.


Зворотне проектування


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


Використання корпоративних функціональних кордонів


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



ПРИМІТКА
Деякі з моїх колег називають ці корпоративні функціональні межі моделюванням реального світу. Моделювання реального світу спонукає розробника моделі розглядати інформацію в термінах реально властивих їй відносин і взаємозв’язків.


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


Що таке корпоративна модель даних?


Корпоративна модель даних (EDM – enterprise data model) містить сутності, атрибути і відносини, які представляють інформаційні потреби корпорації. EDM звичайно підрозділяється у відповідність з предметними областями, які представляють групи сутностей, відносяться до підтримки конкретних потреб бізнесу. Деякі предметні області можуть покривати такі специфічні бізнес-функції, як управління контрактами, інші – об’єднувати суті, описують продукти або послуги.


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


EDM також включає специфічні сутності, які визначають область визначення значень для ключових атрибутів. Ці суті не мають батьків і визначаються як незалежні. Незалежні сутності часто використовуються для підтримки цілісності зв’язків. Ці сутності ідентифікуються кількома різними іменами, такими як кодові таблиці, таблиці посилань, таблиці типів або класифікаційні таблиці. Ми будемо використовувати термін “корпоративний бізнес-об’єкт”. Корпоративний бізнес-об’єкт це сутність, яка містить набір значень атрибутів, що не залежать ні від якої іншої сутності. Корпоративні бізнес-об’єкти в рамках корпорації слід використовувати одноманітно.


Побудова корпоративної моделі шляхом нарощування даних


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


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


Поняття методології моделювання


Існує кілька методологій візуального моделювання даних. ERwin підтримує дві:



  • IDEF1X (Integration Definition for Information Modeling – інтегроване опис інформаційних моделей).
  • IE (Information Engineering – інформаційна інженерія).

DEF1X – хороша методологія і використання її нотації широко поширене.


Інтегроване опис інформаційних моделей


IDEF1X – високо структурована методологія моделювання даних, що розширює методологію IDEF1, прийняту як стандарт FIPS (Federal Information Processing Standards – федеральний орган стандартів обробки інформації). IDEF1X використовує строго структурований набір типів конструкцій моделювання та призводить до моделі даних, яка вимагає розуміння фізичної природи даних до того, як така інформація може стати доступною.


Жорстка структура IDEF1X примушує розробника моделі призначати сутностей характеристики, які можуть не відповідати реаліям навколишнього світу. Наприклад, IDEF1X вимагає, щоб всі підтипи сутностей були ексклюзивними. Це призводить до того, що персона не може бути одночасно клієнтом і співробітником. У той час як реальна практика говорить нам інше.


Розробникам моделей рекомендується вивчити IDEF1X і сформувати власну думку про неї. Документи FIPS доступні в Web, існує кілька хороших публікацій з IDEF1X.


Інформаційний інжиніринг


К. Фінклештейна часто називають батьком інформаційного інжинірингу, хоча подібні ж концепції викладав разом з ним і Д. Мартін (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Інформаційний інжиніринг використовує для управління інформацією підхід, що направляється бізнесом, і застосовує іншу нотацію для представлення бізнес-правил. IE служить розширенням і розвитком нотації і базових концепцій методології ER, запропонованої П. Ченом.


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


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


Розробникам моделей рекомендується познайомитися з роботами Д. Мартіна і К. Фінклештейна для більш глибокого розуміння підходу IE до управління інформаційними ресурсами.


Висновок


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


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


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


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


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

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


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

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

Ваш отзыв

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

*

*