Застосування метамоделі під час проектування баз даних з кількома абстрактними шарами

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

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

(рис. 1)

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

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

(рис. 2)

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

Перехід до більш високого ступеня абстракції дозволяє нам виділити сутність вищого порядку «структурний підрозділ» або «організаційна ієрархія», яка відобразиться в структурі бази даних в таблицю з рекурсивним посиланням (сама на себе; поле зазвичай зване ParentId або аналогічно). З такої таблиці ми можемо розгорнути ієрархію, з необмеженою вкладеністю. Те ж відбувається і з другою ієрархією, ми виділяємо сутність більш високого порядку «класифікація діяльності» (див. рис. 3). Таким чином, ми зробили згортку зв'язків, перетворивши 8 відносин «багато-ко-багатьом» в одне таке ставлення. Але в даному випадку, при узагальненні, була втрачена семантика, а саме: зв'язок між компаніями і спеціалізаціями не потрібен (в даному прикладі), а так як компанії є структурними підрозділами в «організаційної ієрархії», а спеціалізації входять в «класифікацію діяльності», то по діаграмі на малюнку 3, такий зв'язок можливий. Однак, інформаційна система, повинна забороняти користувачеві створювати зв'язок такого типу на логічному рівні, що є аспектом цілісності інформації і є обов'язковою функцією СУБД.

(рис. 3)

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

(рис. 4)

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

(рис. 5)

Але виникає питання, де зберігати атрибути сутностей? Адже в таблиці «Організаційна ієрархія» може міститися тільки група атрибутів, загальна для всіх сутностей нижчого порядку абстракції: компанія, підрозділ, відділ. А всі атрибути, що не перетинаються, повинні бути винесені в окремі таблиці, щоб не створювати ненормалізовану структуру з великою кількістю «порожніх» комірок. Таким чином, ми приходимо до необхідності мати кілька таблиць більш низького рівня абстракції в одній базі з нашою ієрархічною таблицею. А пов'язані вони будуть з нею загальним (точніше, однаковим) первинним ключем у всій групі таблиць, об'єднаних зв'язком «один-к-одному» з таблицею «організаційна ієрархія». Такий зв'язок (див. рис. 5) передбачає наявність запису з відповідним первинним ключем з «організаційної ієрархії» тільки в одній з чотирьох таблиць. Графічне зображення зв'язку «один-к-одному-з» або «supertype-and-sybtype-discriminator» взято з нотації IDEF1, що застосовується у великій кількості CASE-засобів розробки інформаційних моделей баз даних (ErWin, Logic Works, Rational Rose, ER/Studio та д. р.).

(рис. 6)

Опис елементів метамоделі (на рис. 6):

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

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

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

Relation Type - тип зв'язку профілів.

Relation - зв'язок між двома або більше профілями (на другому рівні абстракції) або двома і більше сутностями (на рівні реляційної моделі).

Link - посилання на профіль (сутність), що дозволяє включати в зв'язку кілька профілів.

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

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

Type - тип даних, призначений атрибуту профілю (сутності).

Method - метод або функція, реалізує бізнес-логіку профілю.

На другому рівні абстракції моделі ми можемо прийти до згортки реляційної структури бази до ще більшого узагальнення (див. рис. 6). На малюнку ми бачимо елементи метамоделі, де жовтий і зелений кольори, відповідають відповідно за сутності і зв'язки, а група сірих таблиць відповідає за атрибути сутностей. Така структура підходить для переважної більшості предметних областей у сфері прикладних інформаційних систем. Це структура метаданих, яка описує структуру таблиць в більш узагальнених категоріях, що дозволяє програмному забезпеченню спиратися не на структуру бази даних і не на метадані, а на структуру метамоделі, тобто на абстракцію другого порядку. Однак, метамодель не має достатньої конкретики для вирішення прикладних завдань і потребує деталізації, що і відбувається на першому абстрактному рівні (див. рис. 4). Таким чином, ми маємо дві структури бази, на різних рівнях абстракції, що зберігаються в одній БД паралельно. Зв'язок між ними відбуватися за наскрізними унікальними ідентифікаторами, так як, Profile - це є абстрактна сутність другого порядку, пов'язана з усіма сутностями першого порядку зв'язком «один-к-одному-з» (або «supertype-and-sybtype-discriminator», див. рис. 5 і пояснення вище).

Продовження буде в другій частині.

Для обговорення додаю ще одну схему, яка буде описана в другій частині:

Дякую за увагу.