Логічна модель даних

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

Огляд

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

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

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

Історія

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

Коли ANSI вперше виклав ідею логічної схеми 1975 року^[2], вибір був між ієрархічною та мережевою. Реляційна модель — де дані описані в термінах таблиць і колонок — була визнана лише як теорія організації даних, але не програмне забезпечення, що існує для підтримки цього підходу. З цього часу об'єктно-орієнтований підхід до моделювання даних — де дані описані в термінах класів, атрибутів і асоціацій — також було введено.

Теми логічної моделі даних

Причини побудови логічної структури даних

• Допомагає загальному розумінню елементів бізнес-даних і вимог
• Забезпечує основу для проектування бази даних
• Сприяє уникненню надмірності даних, і таким чином запобігає неузгодженості даних і бізнес-транзакцій
• Сприяє повторному використанню й обміну даними
• Знижує час і вартість розробки та підтримки
• Підтверджує логічну модель процесів і допомагає аналізувати вплив^[en].

Концептуальна, логічна та фізична модель даних

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

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

Концептуальна модель даних (англ. CDM)	Логічна модель даних (англ. LDM)	Фізична модель даних (англ. PDM)
Включає високорівневі конструкції даних	Включає сутності (таблиці), атрибути (колонки / поля) та відношення (ключі)	Включає таблиці, колонки, ключі, типи даних, правила перевірки, тригери баз даних, збережені процедури, домени й обмеження доступу
Не-технічні назви, так що керівники та менеджери на всіх рівнях можуть розуміти основу даних Архітектурного опису	Використовує бізнес-назви для сутностей і атрибутів	Використовує більш визначені та менш загальні конкретні назви для таблиць і колонок, як-от скорочені назви колонок, обмежені системою керування базами даних (СКБД) і будь-якими стандартами, визначеними компанією
Використовує загальні високорівневі конструкції даних, із яких створено Архітектурні описи в не-технічних термінах	Не залежить від технології (платформи, СКБД)	Включає первинні ключі й індекси для швидкого доступу до даних
Може не бути нормалізованою	Нормалізована до четвертої нормальної форми (4НФ)	Може бути де-нормалізована, щоб відповідати вимогам продуктивності, заснованим на характері бази даних. Якщо характер бази даних є онлайновою обробкою транзакцій (OLTP) або операційним сховищем даних, вона зазвичай не де-нормалізується. Де-нормалізація є звичною у сховищах даних.
Представлена з точки зору DIV-1 (DoDAF V2.0)	Представлена з точки зору DIV-2 (DoDAF V2.0) та погляду OV-7 (DoDAF V1.5)	Представлена з точки зору DIV-3 (DoDAF V2.0) та погляду SV-11 (DoDAF V1.5)

Див. також

• DoDAF^[en]
• FCO-IM^[en]
• Модель даних архітектури ядра^[en]
• Модель «сутність — зв'язок»
• Об'єктно-рольове моделювання^[en]
• Проектування баз даних
• Схема бази даних