Моделювання даних: навіщо потрібно і як реалізувати

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

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

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

Що таке моделювання даних

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

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

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

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

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

Переваги моделювання даних

Моделювання спрощує перегляд та розуміння взаємозв'язків між даними для розробників, архітекторів даних, бізнес-аналітиків та інших зацікавлених осіб. Крім того, моделювання даних допомагає:

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

Типи моделей даних

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

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

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

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

Процес моделювання даних

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

1. Визначте сутність. На цьому етапі ідентифікуємо об'єкти, події або концепції, представлені в наборі даних, який необхідно змоделювати.
2. Визначте ключові властивості кожної сутності. Кожен тип сутності можна відрізнити від решти, оскільки він має одну або кілька унікальних властивостей, званих атрибутами. Наприклад, сутність «клієнт» може мати такі атрибути, як ім'я, прізвище, номер телефону і т.д. Сутність «адреса» може включати назву та номер вулиці, місто, країну та поштовий індекс.
3. Визначте зв'язок між сутностями. Найраніша чернетка моделі даних визначатиме характер відносин, які кожна сутність має з іншими. У наведеному вище прикладі кожен клієнт живе за адресою. Якби ця модель була розширена за рахунок включення сутності «замовлення», кожне замовлення також було б надіслано на адресу. Ці відносини зазвичай документуються за допомогою уніфікованої мови моделювання (UML).
4. Повністю зіставте атрибути із сутностями. Це гарантує, що модель відображає те, як бізнес використовувати дані. Широко використовуються кілька формальних шаблонів (патернів) моделювання даних. Об'єктно-орієнтовані розробники часто застосовують шаблони для аналізу чи шаблони проектування, тоді як зацікавлені сторони з інших областей бізнесу можуть звернутися до інших патернів.
5. Призначте ключі в міру потреби та визначте ступінь нормалізації. Нормалізація — це спосіб організації моделей даних, у яких числові ідентифікатори (ключі) призначаються групам даних встановлення зв'язків з-поміж них без повторення даних. Наприклад, якщо кожному клієнту призначено ключ, цей ключ можна пов'язати з його адресою, і з історією замовлень, без необхідності повторювати цю інформацію у таблиці з іменами клієнтів.Нормалізація допомагає зменшити обсяг дискового простору, необхідного для бази даних, але може впливати на продуктивність запитів.
6. Завершіть та перевірте модель даних. Моделювання даних – це ітеративний процес, який слід повторювати та вдосконалювати під потреби бізнесу.

Типи моделювання даних

Моделювання даних розвивалося разом із системами управління базами даних (СУБД), у своїй типи моделей ускладнювалися зі зростанням потреб підприємств у зберіганні даних.

Ієрархічні моделі даних представляють відносини «один до багатьох» у деревоподібному форматі. У моделі цього типу кожен запис має єдиний корінь чи батьківський елемент, який зіставляється з однією чи кількома дочірніми таблицями. Ця модель була реалізована в IBM Information Management System (IMS) у 1966 році і швидко знайшла широке застосування, особливо в банківській сфері. Хоча цей підхід менш ефективний, ніж нещодавно розроблені моделі баз даних, він все ще використовується в системах розширюваної мови розмітки (XML) та географічних інформаційних системах (ГІС).

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

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

У ER-моделях даних використовують діаграми уявлення взаємозв'язків між сутностями у базі даних. ER-модель є формальною конструкцією, яка не наказує ніяких графічних засобів її візуалізації. Як стандартну графічну нотацію, за допомогою якої можна візуалізувати ER-модель, була запропонована діаграма «сутність-зв'язок» (Entity-Relationship diagram). Однак для візуалізації ER-моделей можуть використовуватися інші графічні нотації, або візуалізація може взагалі не застосовуватися (наприклад, тільки текстовий опис).

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

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

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

Інструменти для моделювання даних

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

• erwin Data Modeler — інструмент моделювання даних, заснований на мові IDEF1X, який тепер підтримує й інші нотації, включаючи нотацію для розмірного моделювання.
• Enterprise Architect — це інструмент візуального моделювання та проектування, який підтримує моделювання корпоративних інформаційних систем та архітектур, програмних програм та баз даних. Він заснований на об'єктно-орієнтованих мовах та стандартах.
• ER/Studio — це програма для проектування баз даних, сумісна з деякими найпопулярнішими СУБД. Вона підтримує як реляційне, і розмірне моделювання даних.
• Безкоштовні інструменти моделювання даних включають рішення з відкритим вихідним кодом, наприклад Open ModelSphere.

Для того, щоб перетворити дані на структуру, яка відповідає вимогам моделі, можна використовувати вбудований механізм регулярних запитів, які виконуються в Google BigQuery, Scheduled Queries та AppScript. Їх легко можна освоїти, тому що це звичний SQL, але проводити налагодження в Scheduled Queries практично нереально. Особливо якщо це якийсь складний запит або каскад запитів.

Існують спеціалізовані інструменти для управління SQL-запитами, наприклад, dbt і Dataform.

dbt (data build tool) - це фреймворк з відкритим вихідним кодом для виконання, тестування та документування SQL-запитів, який дозволяє внести елемент програмної інженерії у процес аналізу даних.Він допомагає оптимізувати роботу з SQL-запитами: використовувати макроси та шаблони JINJA, щоб не повторювати в сотий раз одні й ті ж фрагменти коду.

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