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

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

Серед промислових продуктів в галузі баз даних (БД) рішуче переважають табличні бази, які скорочено називають “реляційними”. Реляційна модель даних, запропонована Коддом [Codd E.F. Relational Model of Data for Large Shared Data Banks. – Communication of the Association of computer mathematics, 1970, v. 13, № 6, p. 377-383], має фундаментальне математичне обґрунтування, свого часу вона була великим кроком у теорії баз даних. Дві основні риси архітектури, які забезпечують їм високу ефективність – це фіксований набір таблиць і фіксована структура кожної таблиці. Обидва рішення – щодо набору таблиць і щодо їх структури – треба приймати на етапі проектування БД; кожна інформаційна потреба, не врахована на етапі проектування, вимагає перепроектування БД – чи то зміни структури якоїсь таблиці (додавання нових полів, зміна типу даних поля, додавання нових індексів), чи навіть створення нової таблиці. Це відповідальна операція, яка вимагає від виконавця глибокого знання тієї БД, яку треба зреформувати, методів перепроектування та можливих ускладнень на шляху реформ. Тому всі методичні посібники з проектування БД одностайно радять спочатку якомога ретельніше вивчити інформаційні потреби, які мусить задовольняти БД, і скласти проект, який би не вимагав серйозної переробки.

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

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

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

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

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

Приклади, які ми вище назвали “складними”, є твердим горішком для реляційних БД. На наш погляд, успіхів тут можна досягти за рахунок застосування об'єктного підходу : об'єктного аналізу предметної області, розробки об'єктного проекту БД та його реалізації в об'єктному вигляді. Ці ідеї близькі ідеям концептуального моделювання, наукової дисципліни, яка з'явилася на початку 80-х років на стику теорії баз даних, штучного інтелекту і мов програмування. Як приклад моделі даних концептуального рівня можна навести КОМОД [Фурсин Г.И., Кабаков Ю.Б. Модель данных КОМОД. – Управляющие системы и машины.- 1986, № 4, с. 92-99; Кабаков Ю.Б., Медведева А.И., Фурсин Г.И. КОМОД-91 – система поддержки концептуальных схем и гипертекстов. – Управляющие системы и машины.- 1991.- № 7, с. 22-28]. Ця модель даних являє собою мову для описання структури і семантики “предметної області”. Одним з її основних понять є поняття об'єкту. Об'єкти, які мають спільний набір властивостей згідно деякого рівня абстракції, об'єднуються у клас об'єктів.

Об'єкт класу характеризується певним набором атрибутів. Значення атрибуту об'єкту може бути як атомарним (текстові строки, числа), так і складним об'єктом деякого класу, який зветься класом значень цього атрибуту. Завдяки такій організації, у моделі даних КОМОД за допомогою атрибутів можуть описуватися як властивості об'єктів, так і відношення між ними. Між класами об'єктів може задаватися ієрархія узагальнення (відношення рід – вид). Вона відображає співвідношення “більш загальні поняття – менш загальне поняття” (інтенсіональний аспект), або “суперклас – підклас” (екстенсіональний аспект). Задавши класи об'єктів, ієрархію узагальнення, описавши за допомогою атрибутів властивості об'єктів та відношення між ними, ми фактично задаємо певний каркас описання предметної області. Після цього модель даних КОМОД дає змогу описувати більш тонкі властивості предметної області, які мають назву “обмеження цілісності”. Основні підходи і концепції моделі даних КОМОД були використані авторами при розробці універсальної об'єктної бази “АРХЕОМЕТРИКА”. В той же час серед археологів також зріло розуміння необхідності використання об'єктного підходу при відображенні складних малоформалізованих предметних областей. В двох препринтах Інституту археології НАН України, написаних під керівництвом В.Ф.Генінга [Бунятян Е.П., Генинг В.Ф., Пустовалов С.Ж., Рычков Н.А. ИПС : информационно-поисковая система по погребальным памятникам.- К., 1989.- 45 с.; Бунятян Е.П., Генинг В.Ф., Пустовалов С.Ж., Рычков Н.А. ИПС : подготовка данных по погребальному обряду для ввода в ЭВМ.- К., 1989.- 48 с.] викладено досить досконалий проект об'єктної БД для опису курганів. Проте жодної професійної системи управління об'єктними базами даних не створено і досі (принаймні серед промислово поширюваних продуктів).

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