8.3.2. Ієрархії і процеси.

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

За ходом відлагодження СУБД і реструктуризації БД ми спостерігаємо як початкові, стартові ієрархії об’єктів і процесів змінюються, більше того фактично саме це зміна і є змістовною частиною реструктуризації – породження нових відношень і процесів.

Відома ідеологія Get Up (GU) і Check Up (CHU) інтерфейсів обслуговує лише два типи процесів, а саме:

• слабозв’язані процеси (див. роботи Е. Дейкстра), тобто такі, що не руйнують локальну структуру;

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

Для обслуговування третього, такого, що власне і представляє для нас інтерес типу процесів, а саме, що руйнує глобальне середовище, адекватного формалізму немає, його просто до цих пір і не намагалися створювати. Тому тут ми беремо працю і відповідальність на себе і запроваджуємо третій тип процесів із ідеологією Crash Restore (CRR).

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

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

• блокується частина глобального середовища (або все середовище);

• проводиться переналагодження моделі даних;

• відповідно до перебудованої МД проводиться перезавантаження блокованої частини глобального середовища з переобчисленням елементів (зв’язків, імен, значень тощо., аж до глобальних дескрипторів і цілих структур);

• попередній пункт виконується до тих пір, поки не вичерпані можливості МД, чи можливості переобчислення елементів, чи, нарешті, ця процедура не стала занадто дорогою, після чого “життєвий цикл” СУБД завершується і треба проектувати нову СУБД.

Відмітимо тепер, що те ж саме ми спостерігаємо на апаратному рівні при обробці переривання від збоїв шини пам’яті (або блоку). Якщо апаратура забезпечена засобами резервування і деяким механізмом типу “міжблочного кеша”, то вона чинитиме опір збоям, обходячись частковими гарячими перезавантаженнями, до тих пір, поки не будуть вичерпані можливості резервування.

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

8.3.3. Концепція відкритої субд.

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

Отже, структура СУБД “розкривається дзеркально відносно ПЗ”. Також як із ПЗ виділяється логічна модель (або моделі), в СУБД виникає власне структура БД і структура управління у вигляді динамічно розкриваного об’єкта.

Структура, що реалізує БД, повинна задовольняти наступним вимогам:

• відображати (моделювати) потенційно нескінченну множину (різноманіття) логічних моделей даних;

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

Відповідною структурою є механізм В*-дерев. Більше того, нами доведено, що цей механізм є “глобально-мінімаксним” {105. У В*-деревах можна змоделювати будь-яку структуру – це здається вже не потребує пояснень, як і той факт, що розріджені масиви суть один із найбільш економічних способів використання пам’яті. Доказ зводиться до наступного. Система В*-моделей завжди залишається неповною, але ефективно поповнюваною. За рахунок неповноти гарантована несуперечність, тобто ця модель не може сама породити колізію, що руйнує глобальне середовище. Навпаки, будь-яка “багатша” логічна модель таку породить неминуче. Для кожного окремого випадку можливо підібрати подання, економічніше, ніж B*-дерева, але воно обов’язково самозруйнується навіть при простому поповненні даних на деякому кроці цього поповнення, тобто БД фізично руйнуватиметься навіть без зовнішньої причини (події), пов’язаної із зміною логіки моделі даних. Звідси виходить ситуація мінімакса – найбільш економічне (в середньому за сукупністю всіх відображень) подання для потенційно нескінченного числа логічних моделей.}. Розкриваність об’єкта (структури, БД, що управляє), що управляє, зводиться до наступного.

Структура повинна містити компоненти:

• опису зовнішньої логічної моделі – зовнішнього подання ПЗ;

• описи трансляції зовнішнього подання у В*-модель – це засоби розкриття “назовні-всередину”;

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

• описи інших зовнішніх логічних моделей для роботи з системами інших концепцій – засоби розкриття “вшир”;

• засоби для роботи з вище переліченими описами, тобто інтерфейс користувача – засоби “розкриття до користувача”;

• інструментальні засоби для корекції, організації взаємодії і створення описів – управління “засобами розкриття”.

Взагалі кажучи, це і не описи, а деяке подання структури, яка може бути, зокрема, і сама динамічним об’єктом зі всіма його компонентами і властивостями.

Тут ми повинні зробити один з найважливіших практичних висновків. Якщо в такій структурі виникає подія, що сигналізує про руйнування глобального середовища, це означає, що джерело події можна однозначно локалізувати або в “зовнішній”, або в “внутрішній” частині моделі даних того об’єкта, який був в даний момент активний. Далі залишається використовувати відповідні інструментальні засоби і скоректувати модель даних, чи побудувати нову.

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

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

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

Необхідно відзначити наступне. Витрати неминучі у будь-якому випадку, при будь-якому способі розширення моделі даних. Але в нашому випадку їх можна вимірювати, збирати статистику і контролювати (у Cache для цього є вбудовані засоби). Ці витрати ніколи не стануть рости обвально, що неминуче при апріорному завданні метаструктури даних, або при періодичному повторенні процесу проектування структури БД. Фактично це еквівалентно обміну обсягу апаратних затрат на затрати багаторазового відновлення проектування.