Моделювання даних (Data Modelling)

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

Моделювання даних (Data Modelling) це одна з методик BABOK v3 (розділ 10.15)

Опис Моделювання даних (Data Modelling) в BABOKv3 (10.15.2)

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

Модель даних (data model) часто використовуються для з'ясування та аналізу вимог і проектування, а також для підтримки впровадження та безперервного вдосконалення.

Існує кілька варіацій моделей даних:

  • Концептуальна модель даних (Conceptual data model): не залежить від будь-якого рішення або технології і може бути використана для представлення того, як бізнес сприймає свою інформацію. Вона може бути використана для створення узгодженого словника, що описує бізнес-інформацію та взаємозв'язки всередині цієї інформації.
  • Логічна модель даних (Logical data model): абстракція концептуальної моделі даних, яка включає правила нормалізації для формального управління цілісністю даних і зв'язків. Вона пов'язана з проектуванням рішення.
  • Фізична модель даних (Physical data model): використовується експертами предметної області для опису того, як фізично організована база даних. Вона вирішує такі проблеми, як продуктивність, паралельність і безпека.

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

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

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

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

Елементи Моделювання даних (Data Modelling) в BABOKv3 (10.15.3)

Сутність або клас (Entity or Class)

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

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

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

Атрибут (Attribute)

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

Атрибути можуть включати такі значення як:

  • Ім'я (Name): унікальне ім'я для атрибута. Інші імена, що використовуються зацікавленими сторонами, можуть бути записані як псевдоніми.
  • Значення/Смисли (Values/Meanings): список допустимих значень для атрибута. Це може бути виражено у вигляді переліку або у вигляді опису допустимих форматів даних (включаючи таку інформацію, як кількість символів). Якщо значення є скороченими, вони повинні містити пояснення їхнього значення.
  • Опис (Description): визначення атрибута в контексті рішення.

Відносини або асоціація (Relationship or Association)

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

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

За допомогою цього формату зв'язок між двома сутностями можна читати в обох напрямках:

  • Кожне значення (цього об'єкта) пов'язане з (мінімальним, максимальним) значенням (цього іншого об'єкта).

У моделі класів замість відношення використовується термін асоціація (association), а замість кардинальності - множинність (multiplicity).

Діаграми (Diagrams)

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

Діаграма в моделі даних називається діаграмою "сутність-зв'язок" (ERD - entity-relationship diagram). У моделі класів діаграма називається діаграмою класів.

Рисунок 10.15.1: Діаграма "сутність-зв'язок" (нотація "вороняча лапка" - Crow's Foot Notation)
Рисунок 10.15.2: Діаграма класів (UML®)

Метадані (Metadata)

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

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

Міркування щодо використання Моделювання даних (Data Modelling) в BABOKv3 (10.15.4)

Сильні сторони Моделювання даних (Data Modelling)

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

Обмеження Моделювання даних (Data Modelling)

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

Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.