Моделювання даних

Як моделі даних приносять користь[1]

Моделі даних надають фреймворк для даних, які використовуватимуться в інформаційних системах шляхом надання конкретного визначення та формату. Якщо модель даних використовується послідовно в усіх системах, то сумісність даних є досяжною. Якщо ті самі структури даних використовуються для зберігання та доступу до даних, тоді різні застосунки можуть безшовно ділитися даними. Результати цього показано на діаграмі. Проте, системи й інтерфейси часто дорого будувати, оперувати та підтримувати. Вони також можуть радше обмежувати бізнес, аніж підтримувати його. Це може статися, коли якість моделей даних, реалізованих у системах та інтерфейсах, є низькою[1]

• Бізнес-правила, специфічні до того, як усе робиться в певному місці, часто фіксуються у структурі моделі даних. Це означає, що малі зміни у способі ведення бізнесу призводять до великих змін у комп'ютерних системах та інтерфейсах. Тому бізнес-правила повинні реалізовуватися у гнучкий спосіб, що не спричинює складні залежності, а модель даних повинна бути достатньо гнучкою, щоби такі зміни в бізнесі могли реалізовуватися в межах моделі даних у відносно швидкий та ефективний спосіб.
• Типи сутностей часто невизначені чи визначені некоректно. Це може призвести до реплікації даних, їх структур і функційності, разом із супутньою вартістю такого дублювання в розробці та підтримці. Таким чином, визначення даних повинні бути зроблені настільки чіткими та легкими для розуміння, наскільки можливо для мінімізації хибного тлумачення та дублювання.
• Моделі даних для різних систем довільно різні. Наслідком цього є необхідність складних інтерфейсів між системами, що спільно використовують дані. Ці інтерфейси можуть становити 25—70 % вартості поточних систем. Необхідні інтерфейси повинні розглядатися по суті під час проектування моделі даних, сама по собі модель даних не використовуватиметься без інтерфейсів у різних системах.
• Даними не можна ділитися в електронному вигляді між клієнтами та постачальниками, оскільки структура та значення даних не були стандартизовані. Для отримання оптимального значення від реалізованої моделі даних дуже важливо визначити стандарти, які забезпечать, що моделі даних і відповідатимуть потребам бізнесу, і будуть послідовними[1].

Трирівнева архітектура ANSI/SPARC. Це показує, що модель даних може бути зовнішньою (чи розрізом), концептуальною чи фізичною моделлю. Це не єдиний спосіб поглянути на моделі даних, а він є корисним, особливо при порівнянні моделей[1]

1975 року ANSI описав три види «екземплярів» моделей даних[5]:

• Концептуальна схема: описує семантику предметної області (межі^{[уточнити]} моделі). Наприклад, це може бути модель площі інтересів організації чи індустрії. Вона складається з класів сутностей, які подають види важливих речей у предметній області, та відношень тверджень про асоціації між парами класів сутностей. Концептуальна схема визначає види фактів або пропозицій, які можна виразити за допомогою моделі. У цьому сенсі вона визначає дозволені вирази штучною «мовою» в межах, обмежених межами моделі. Простіше кажучи, концептуальна схема є першим кроком в організації вимог до даних.
• Логічна схема: описує структуру певної предметної області інформації. Вона складається з описів (наприклад) таблиць, колонок, об'єктно-орієнтованих класів і тегів XML. Логічна та концептуальна схеми іноді реалізуються як одне й те саме[2].
• Фізична схема: описує фізичні засоби, що використовуються для зберігання даних. Вона стосується розділів, ЦП, табличних просторів тощо.

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

Моделювання даних у контексті інтеграції бізнес-процесів[6]

У контексті інтеграції бізнес-процесів (див. малюнок) моделювання даних доповнює моделювання бізнес-процесів і зрештою має наслідком генерацію бази даних[6].

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

У процесі системні інтерфейси становлять від 25 % до 70 % вартості розробки та підтримки поточних систем. Основною причиною цієї вартості є те, що ці системи не поділяють спільну модель даних. Якщо моделі даних розроблені на засадах система за системою, тоді не лише той самий аналіз повторюється в пересічних областях, а й подальший аналіз повинен здійснюватися дл ястворення інтерфейсів між ними. Більшість систем в організації містять ті самі базові дані, перероблені для конкретної мети. Таким чином, ефективно спроектована базова модель даних може мінімізувати переробку з мінімальними модифікаціями для цілей різних систем в організації[1].

Моделі даних подають інформаційні сфери інтересів. Тоді як існує багато способів створення моделі даних, за словами Лена Сілверстона (1997)[7], виділяються лише дві методології моделювання, згори донизу та знизу догори:

• Моделі знизу догори, чи моделі інтеграції розрізів англ. View Integration, часто є наслідком зусиль реінжинірингу. Вони зазвичай починаються з існування форм структур даних, полів на екранах застосунків або звітів. Ці моделі зазвичай фізичні, специфічні до застосунку та незавершені з погляду підприємства. Вони можуть не сприяти обміну даними, особливо якщо вони побудовані без посилань на інші частини організації[7].
• Логічні моделі даних згори донизу, з іншого боку, створені в абстрактний спосіб отриманням інформації від людей, які знають предметну область. Система може не реалізувати всі сутності в логічній моделі, але модель слугує орієнтиром або шаблоном[7].

Іноді моделі створено в суміші двох методів: розглядаючи необхідні дані та структури застосунку, та послідовно посилаючись на модель предметної області. На жаль, у багатьох середовищах відмінності між логічною та фізичною моделями даних розмиті. На додачу, деякі CASE-засоби не розрізняють логічні та фізичні моделі даних[7].

Приклад IDEF1X-діаграми «сутність — зв'язок», використаної для моделювання самої IDEF1X. Назва розрізу — mm. Ієрархію доменів та обмежень також дано. Обмеження виражено як речення у формальній теорії метамоделі[8]

Існують декілька нотацій моделювання даних. Дійсна модель часто називається «модель „сутність — зв'язок“», оскільки вона зображає дані в термінах сутностей і відношень, описаних у даних[4]. Модель «сутність — зв'язок» (англ. entity-relationship model, ERM) є абстрактним концептуальним поданням структурованих даних. Моделювання «сутність — зв'язок» є реляційною схемою методу моделювання баз даних, що використовується у програмній інженерії для створення типу концептуальної моделі даних (або семантичної моделі даних) системи, часто реляційної бази даних, та її вимог згори донизу.

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

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

• Діаграма Бакмана
• Нотація Баркера
• Нотація Чена
• Моделювання сховищ даних
• Розширена нотація Бекуса — Наура
• IDEF1X
• Об'єктно-реляційне відображення
• Об'єктно-рольове моделювання
• Реляційна модель даних
• Реляційна модель/Тасманія

Приклад загальної моделі даних[9]

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

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

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

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

Семантичні моделі даних[8]

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

Семантична модель даних може використовуватися для багатьох цілей, як-от[8]:

• планування ресурсів даних;
• побудова поділюваних^{[уточнити]} баз даних;
• оцінювання постачальників програмного забезпечення;
• інтеграція наявних баз даних.

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