3.3. Моделювання даних: створення моделі даних для інформаційної системи; концептуальна, логічна, фізична моделі даних; er-модель; нотації er-моделей

Моделювання даних (англ. data modeling) у програмній інженерії — процес створення моделі даних для інформаційної системи шляхом застосування певних формальних підходів.

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

Існують три різних типи моделей даних, що виробляються протягом переходу від вимог до дійсної бази даних для використання в інформаційній системі[2]. Вимоги до даних спочатку записуються як концептуальна модель даних, яка по суті є набором технологічно залежних специфікацій про дані та використовується для обговорення початкових вимог із зацікавленими сторонами бізнесу. Концептуальна модель потім перетворюється на логічну модель даних, яка документує структури даних, що можуть реалізовуватися в базах даних. Реалізація однієї концептуальної моделі даних може вимагати багатьох логічних моделей даних. Останнім кроком у моделюванні даних є перетворення логічної моделі даних на фізичну модель даних, яка організує дані в таблиці та пояснює деталі доступу, продуктивності та зберігання. Моделювання даних визначає не тільки елементи даних, а й також їх структури та відношення між ними[3].

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

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

• керування даними як ресурсом;

• інтеграції інформаційної системи;

• проектування баз і сховищ даних (також відомі як репозитарії даних).

Моделювання даних може здійснюватися під час різних типів проектів і на багатьох фазах проектів. Моделі даних прогресивні: немає такого поняття, як кінцева модель даних для бізнесу чи застосунку. Натомість модель даних повинна розглядатися як живий документ, який змінюватиметься у відповідь на зміну бізнесу. Моделі даних в ідеалі слід зберігати в репозитарії так, щоб їх можна було отримати, розширити та редагувати за деякий час. Віттен[en] та інші (2004) визначили два типи моделювання даних[4]:

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

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

Моделювання даних також використовується як техніка деталізації бізнес-вимог[en] для конкретних баз даних. Воно іноді називається «моделюванням даних», оскільки модель даних із часом реалізується в базу даних.

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

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

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

Моделі даних для різних систем довільно різні. Наслідком цього є необхідність складних інтерфейсів між системами, що спільно використовують дані. Ці інтерфейси можуть становити 25—70 % вартості поточних систем. Необхідні інтерфейси повинні розглядатися по суті під час проектування моделі даних, сама по собі модель даних не використовуватиметься без інтерфейсів у різних системах.

Даними не можна ділитися в електронному вигляді між клієнтами та постачальниками, оскільки структура та значення даних не були стандартизовані. Для отримання оптимального значення від реалізованої моделі даних дуже важливо визначити стандарти, які забезпечать, що моделі даних і відповідатимуть потребам бізнесу, і будуть послідовними[1].

Концептуальні, логічні та фізичні схеми. 1975 року ANSI описав три види «екземплярів» моделей даних:

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

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

• Фізична схема: описує фізичні засоби, що використовуються для зберігання даних. Вона стосується розділів, ЦП, табличних просторів тощо.

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

Модель «сутність-зв'язок» (ER-модель) (англ. Entity-relationship model або entity-relationship diagram) — модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. ER-модель — це мета-модель даних, тобто засіб опису моделей даних. Існує ряд моделей для представлення знань, але одним з найзручніших інструментів уніфікованого представлення даних, незалежного від програмного забезпечення, що його реалізує, є модель «сутність-зв'язок». Важливим є той факт, що з моделі «сутність-зв'язок» можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найзагальнішою.

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

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

Коли ми говоримо про сутність, ми зазвичай говоримо про деякий аспект реального світу, який можна виділити поміж інших аспектів. Сутність — це збірне поняття, деяка абстракція реального об'єкта, процесу, явища чи деякого уявлення про об'єкт. Хоча термін сутність найвживаніший, потрібно розрізняти поняття типу сутності та екземпляру сутності. Поняття тип сутності стосується набору однорідних особистостей, предметів, подій або ідей, що виступають як ціле. Екземпляр сутності стосується конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром — Київ, Львів і т. д.

Виділяють три види сутностей: стрижнева, асоціативна (асоціація) і характеристична (характеристика):

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

• Асоціативна сутність (або асоціація) виражає собою зв'язок «багато до багатьох» між двома сутностями. Є цілком самостійною сутністю. Наприклад, між сутностями ЧОЛОВІК і ЖІНКА існує асоціативний зв'язок, висловлюваний асоціативної сутністю ШЛЮБ.

• Характеристичну сутність ще називають слабкою сутністю. Вона пов'язана з більш сильною сутністю зв'язками «один до багатьох» і «один до одного». Характеристична сутність описує або уточнює іншу сутність. Вона повністю залежить від неї і зникає зі зникненням останньої. Наприклад, сутність Зарплата є характеристикою конкретних працівників підприємства і не може в такому контексті існувати самостійно — при видаленні екземпляра сутності Працівника повинні бути видалені і екземпляри сутності Зарплата, пов'язані з видаленим працівником.

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

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

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

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

Нотації (Графічні діаграми) Нотація Пітера Чена

Сутності відображуються у вигляді прямокутників, зв'язки у вигляді ромбів. Якщо сутність бере участь у відносинах, вони пов'язані лінією. Якщо відносини не є обов'язковими, то лінія пунктирна. Атрибути позначаються в вигляді овалів і пов'язані з однією сутністю або зв'язком. Овал похідних атрибутів зображується пунктирним контуром.

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

Нотація «вороняча лапка» (англ. crow's foot) була запропонована Гордоном Еверестом (англ. Gordon Everest) у статті 1976 року[1] під назвою «обернена стрілка» (англ. inverted arrow), однак частіше за все цю нотацію називають «вороняча лапка» або ж «виделка» (англ. fork).

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

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

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

Інші нотації

• Bachman notation

• EXPRESS[en]

• IDEF1X[en]

• Martin notation

• (min, max)-Notation

• Діаграма класів

Діаграма класів (англ. Class diagram) — статичне представлення структури моделі в UML. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення. Діаграма класів може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм.

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

На діаграмі класи представлені у вигляді прямокутників, які містять три відділення:

Відображення класу з трьома відділеннями.

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

• Середнє відділення містить атрибути класу. Вони вирівняні по лівому краю і перша літера мала.

• Нижній відсік містить операції, які може виконувати клас. Вони також вирівняні по лівому краю і перша літера мала.

Можливо додання четветого відділення, яке містить коментарі.

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

Для подальшого опису поведінки систем діаграми класів можуть бути доповнені діаграмою станів автомата або машиною станів UML.