Початкова сторінка

Микола Жарких (Київ)

Персональний сайт

?

Проект бази даних “Археометрика”

М.І.Жарких, Ю.Б.Кабаков

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

Інформаційний об'єкт

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

– належить до певного класу;

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

– має логічне ім'я, яке допомагає людині ідентифікувати об'єкт.

Різниця між ід-ом та логічним іменем полягає в тому, що ід є структурою для “внутрішнього споживання” в БД, а логічне ім'я призначене для користувача. Наприклад, ід пам'ятки може виглядати як 13480597 (або інше досить довге число), яке мало про що говорить; логічне ім'я об'єкту, ідентифікованого цим ід-ом, може бути “курган біля с. Глеваха” чи “городище в с. Хотів”. Звичайно, біля Глевахи може бути не один курган; тобто два різних об'єкти можуть мати однакове логічне ім'я, яке не зобов'язане бути унікальним, але допомагає користувачеві зрозуміти, про що йдеться.

Класи об'єктів

Клас складається з декларації класу та множини екземплярів об'єктів класу. Декларація класу включає :

– ім'я класу;

– коментар – пояснення призначення класу;

– вказівник на суперклас;

– список власних атрибутів.

Класи об'єднуються в ієрархічні структури – дерева завдяки тому, що кожен клас може належати тільки до одного суперкласу (множинну спадковість ми не використовуємо). Це зветься ієрархією узагальнення. Якщо вказівник на суперклас є пустим, даний клас є кореневим. Кореневий клас не має ніяких атрибутів, окрім власних (перелічених в його власному списку атрибутів). Некореневий клас має окрім власних атрибутів ще й атрибути, успадковані від усіх його суперкласів аж до кореневого включно.

Алгоритм формування повного списку атрибутів такий :

[Список атрибутів] := пусто

[Поточний клас] := [Клас, для якого будуємо список]

повторювати

[Список атрибутів] := [Список атрибутів] + [Поточний клас].[Список власних атрибутів]

[Поточний клас] := [Поточний клас].[Суперклас]

поки [Поточний клас] != пусто

Таким чином, ієрархічна підпорядкованість класів та алгоритм об'єднання списків атрибутів дозволяє створювати об'єкти-нащадки, які успадковують властивості об'єктів-предків і володіють до того ж певними спеціалізованими властивостями. Це дуже потужний інструмент формалізації знань, який відповідає вимогам об'єктного аналізу [Буч Г. Объектно-ориентированное программирование с примерами приложения. – М. : Конкорд, 1992. – С. 10-145] і до того ж є інтуїтивно зрозумілим, оскільки моделює спосіб людського пізнання : від загального уявлення про предмет до його деталізованого образу.

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

При проектуванні операцій над класами ми окремо розглядаємо “множину екземплярів об'єктів даного класу” та “множину екземплярів об'єктів даного класу разом з його підкласами”. Вказівка на сферу дії операції істотна, наприклад, для операції пошуку об'єктів.

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

Атрибути

Атрибути об'єктів призначені власне для зберігання порцій інформації. Кожен атрибут має :

– ім'я атрибута;

– коментар – пояснення призначення атрибута;

– вказівник на клас-власник даного атрибута;

– тип значень;

– обмеження кількості;

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

Типи значень атрибутів

Таблиця 1. Типи значень атрибутів.

Назва типу Пояснення
Короткий текст Текст до 100 знаків
Довгий текст Текст до 32 000 знаків
Історична дата Точні й розмиті дати, інтервали дат
Зображення Графічний образ або інший OLE об'єкт
Дійсне число Значення в інтервалі -1.7·10308..1.7·10308
Ціле число Значення в інтервалі -2 млрд..2 млрд.
Перелік Елемент зі списку
Множина Набір бінарних ознак
Вказівник Інший об'єкт

Типи даних, які “Археометрика” пропонує архітектору об'єктів предметної області, перелічено в таблиці. Різниця між короткими та довгими текстами є технічною : передбачається, що короткі тексти можна індексувати для прискорення пошуку, тоді як довгі тексти (мемо-поля) жодна СУБД не індексує. Спрямування БД на застосування в царині суспільних наук зумовило заміну стандартного для всіх СУБД типу “дата та час” на “історичну дату” – дуже специфічний і потужний тип даних, який повністю підтримує такі записи, як “друге тисячоліття до нашої ери” чи “початок 1830-х років” [Кабаков Ю.Б. . – Археометрія та охорона історико-культурної спадщини, 1997.- Вип. 1. – С. 50-58].

Тип даних “перелік” надає користувачеві можливість вибору одного і тільки одного значення зі словника (зрозуміло, що цей словник треба заздалегідь наповнити значеннями; дуже важливо, що словник можна поповнювати, не торкаючись при цьому тих даних, які вже введені до БД) [Панченко М.В. . – Археометрія та охорона історико-культурної спадщини. – 1997. – Вип. 1. – С. 63-66].

Тип даних “множина” відповідає поняттю “множина” (set) з мов програмування : це перелік двійкових ознак, з яких кожна може бути встановленою або не встановленою. Наприклад, атрибут “тип нерухомої пам'ятки” може бути множиною таких ознак :

– пам'ятка археології;

– пам'ятка історії;

– пам'ятка архітектури;

– пам'ятка містобудування;

– пам'ятка монументального мистецтва;

– пам'ятка фортифікації;

– інженерна пам'ятка.

Проблема опису комплексних пам'яток [Свод памятников истории и культуры Украинской ССР : методические рекомендации. – К., 1981. – С. 35-39; Методичні рекомендації по підготовці матеріалів Зводу пам'яток історії та культури України. – К., 1993. – С. 86-89; Типові статті для Зводу пам'яток історії та культури України. – К., 1994. – С. 150-178] розв'язується в дуже простий спосіб : описувач пам'ятки повинен встановити відповідну кількість бінарних ознак (наприклад, для Києво-Печерської лаври – пам'ятка археології; пам'ятка історії; пам'ятка архітектури). Тоді під час відбору “тільки пам'яток історії” чи “тільки пам'яток археології” описана в такий спосіб пам'ятка потрапить у число відібраних. Зрозуміло, що набір двійкових ознак, об'єднаних у множину, також можна поповнювати, не зачіпаючи попередньо введені дані. Нам здається, що множина не повинна перевищувати 32 ознак (тоді її можна зберігати як 4-байтове число).

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

Атрибути і тексти

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

Отже, в БД потрібна спеціальна функція, яка повертала б текстове значення для будь-якого атрибуту (окрім зображення).

Копіювання об'єктів

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

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

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

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

Дата модифікації/Номер версії Співпадає Не співпадає
Співпадає Примірники тотожні Обидва примірники змінені, редагувались незалежно
Не співпадає Обидва примірники змінені, редагувались незалежно Більший номер версії в поєднанні з новішою датою означає новішу (здебільшого кращу) версію об'єкту

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