База даних

Микола Жарких

«Достали нот, баса, альта, две скрипки…» – яку ідилічну картину роботи наукового інституту малює нам байкар! Як ми «діставали» (цілком точне визначення) наші інструменти, тобто обладнання і базове програмне забезпечення – я вже розповів. Для того щоб «пленять своим искусством свет», залишалися ще «ноти» – тобто спеціалізоване програмне забезпечення бази даних по пам’ятках. Його «дістати» було неможливо – з тієї простої причини, що його не існувало в природі, його треба було створити.

Для невтаємничених читачів коротко поясню: база даних – це поєднання масиву (набору, колекції) даних на комп’ютерних (машинних) носіях і програмного забезпечення, котре дає можливість з цим масивом працювати. В залежності від контексту «базою даних» може називатись або тільки набір даних, або тільки програмне забезпечення, під яким у свою чергу можна розуміти програми загального призначення (системи управління / керування базами даних, СУБД / СКБД / DBMS), або спеціалізовані надбудови над СУБД для вирішення конкретних задач. Чим більше ми занурюємось в цю область, тим більше смислових відтінків набуває термін «база даних». Коли ж цей вираз вживає не-спеціаліст, він може означати що завгодно з даної предметної області, а найчастіше – всю область в цілому.

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

Програмне забезпечення має створювати ілюзію простоти
(рисунок з книги: Буч Г. Объектно-ориентированное программирование. – М.: Конкорд, 1992 г., с. 12.)

Все, що має знати рядовий користувач, це – кнопку, яку треба натиснути (як на рисунку).

Але від первісно сформульованого завдання – «створити базу даних пам’яток» – до простого натискання кнопок лежав дуже довгий шлях, не пройдений і досі, до 2015 року.

Отже, перша проблема, котру нам треба було розв’язати – як розуміти поставлене завдання. Через повне невігластво тодішнього начальства всіх рівнів в інформаційних технологіях діяв принцип «технічне завдання на розробку програм пише сам програміст». І так воно буде завжди, поки у «виконавчій вертикалі» тільки найменший виконавець знає, що таке «технічне завдання» і навіщо воно потрібно.

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

Найкращий шлях написання технічного завдання – узяти завдання на розробку попередньої / подібної програми й модифікувати його для нових потреб. Я про це знав і тому приділив певний час ознайомленню з такими програмами. Михайло Панченко запропонував піди до Національного музею історії України, де на той час (1996 р.) уже використовувалась база даних обліку музейних предметів.

Підрозділ, котрий займався цією базою, містився не в головному будинку музею, а в якомусь маленькому будиночку поруч, і то в підвалі (нині, розглядаючи план Києва, я не бачу на ньому нічого подібного… Може, й помиляюсь із місцем). Там працювала Світлана Советнікова – головний конструктор цієї бази. З’ясувалось, що в музеї працює локальна мережа з немалим як на той час числом робочих станцій та виділеним сервером. На сервері містилась СУБД FoxPro (здається, версії 2.0, досить нової на той час; нам слід було знати, що розвиток цього продукту припинився в 1994 р., але ми про це дізнались значно пізніше). Важливо підкреслити, що музей придбав ліцензійний примірник цієї СУБД.

База даних мала клієнт-серверну архітектуру, і співробітники могли приєднуватись до бази зі своїх робочих місць. Ясна річ, була система облікових записів, захищених паролями, була консоль адміністратора, з якої, зокрема, здійснювалась архівація даних. Якщо я не помиляюсь, був навіть поділ масиву записів на групи зберігання, завдяки чому працівник даної групи зберігання мав змогу працювати тільки із записами своєї групи і не мав доступу до інших груп. Була також якась загальна звітність по наповненню бази. Також важливо, що база забезпечувала друкування наборів записів у вигляді звичної для музейників «книги вступу», на яку можна було поставити печатку. Музей мав окремий дозвіл Міністерства культури на ведення комп’ютерного обліку фондів. Ніякої загальної інструкції по комп’ютерному обліку тоді не було, як не було її й пізніше (йойкання на цю тему я чув ще у 2008 році, як далі – не знаю).

Відповідно до технічного рівня того часу, ця база даних використовувала текстові екрани; про зображення предметів не було ані мови. Також не могло бути ніякого обміну текстами з іншими програмами, тому що робочі станції працювали з операційною системою MS DOS в однозадачному режимі. Єдиний спосіб вводу інформації в базу вів через клавіатуру.

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

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

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

Щоб не повертатись більше до цієї бази даних, скажу, що в наступні роки на різних зустрічах і говоріннях ця база даних постійно згадувалась як успішна розробка (як воно по суті й було). Два тісно пов’язаних між собою недоліки роботи полягали в мізерній інсталяційній базі (здається, були спроби передати її до інших музеїв, але про успіхи чути не довелось) і в безнадійно застарілій програмній основі. І що то зробить з нею Тетяна Сосновська, новий директор музею? Чи знає вона, що таке «інсталяційна база»?

«О приговоре истории дать знать Топтыгину Третьему – пускай изворачивается»…

Ще один похід такого плану (здається, у тому ж 1996 році) організував для нас Сергій Іванович Кот (він якось співпрацював з ІПД, мабуть, за сумісництвом). Завдяки його знайомству ми відвідали інститут Діпромісто (бульв. Лесі Українки, 26 – тільки я не пам’ятаю точно, чи це був сам інститут, чи якась інша установа в тому будинку). Там ми побачили надзвичайно цікаві та ефектні програми, котрі показували текстову і різноманітну графічну інформацію по архітектурних об’єктах. Що мене найбільше вразило – можливість клацнути по якомусь місцю зображення і отримати фотографію даної архітектурної деталі в окремому вікні.

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

Недоліком показаної нам роботи, наскільки я устиг зрозуміти, була необхідність писати й компілювати програму для кожної пам’ятки окремо. Тобто це була скоріше колекція мультимедійних паспортів пам’яток, а не база даних як така. Але в технічні деталі керівник роботи (от, забув його прізвище!) не дуже хотів вдаватись, і не видно було його бажання якось співпрацювати з ІПД. Так на одному візиті справа і скінчилась.

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

Отже, спроби поживитись чужим умом для нашої роботи не принесли великих результатів. Я не буду детально розповідати про хід роботи над логічних проектом бази даних – про нього можна більш-менш повно довідатись із моїх статей в «Археометрії». Натомість розповім дещо, не відбите у статтях.

Перша ідея побудови бази даних пам’яток належала Миколі Корбуту. Він пропонував геоінформаційну систему – от так! Основна його ідея полягала в тому, що інформація про пам’ятки повинна мати прив’язку до цифрової карти.

Нині, через 20 років, кожен може відкрити «Карти Google» і вибрати якусь адресу. Програма запропонує вам фотографії цього об’єкта і, можливо, його опис. Оце й є геоінформаційна система «для чайників» («доросла» система повинна мати ще масу інших функцій, котрі рядовому користувачу не потрібні). І дивлячись на це ІТ-чудо, мені залишається тільки повторити за бравим вояком Швейком: «Про це ми ще до війни говорили з паном окружним начальником».

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

Наступним кроком стало «діставання» цифрової карти України. Домовлявся про це Дудкін, і про умови я нічого не знаю. Але добре пам’ятаю, як ми з Вайнером узяли мішок дискет (саме так, бо архівована карта займала щось із 20 дискет) і зайшли у сірий будинок на вул. Великій Васильківській (тоді – Червоноармійській), 69. Я не вмію сказати, як звалась та установа (нині я бачу, що в цьому будинку міститься добрий десяток різних геодезичних контор – може, це була одна з них). Поки працівник записував нам оцей стос дискет, ми устигли поговорити про оцифрування карт і подивитись, як на практиці йде ця робота. Повернувшись до ІПД, ми побачили, що одна чи дві дискети не читаються, їх треба було переписувати заново (гордим, як відомо, сам бог противиться…).

Ця цифрова карта, хоч і мала дуже значний як на той час обсяг (читач уже відчув, що навіть перенос її з комп’ютера на комп’ютер перевищував можливості тогочасної техніки), спиралась на карту мірила 1 см : 5 км. Найважливіший для нас шар карти – населені пункти – був представлений тільки зовнішніми контурами, котрі виглядали досить примітивно. Так само примітивно виглядав інший важливий для пам’яток археології шар – річкова мережа. Виявлено було й інші недоробки і помилки. Отже, продукт був ще сирий, не опрацьований остаточно, і до того ж розрахований виключно на дрібні масштаби (країна в цілому або область). Карти районного масштабу виглядали дуже грубо і далеко поступалися старим паперовим картам.

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

Щоб не повертатись до теми новаторських ідей Інституту, котрі випередили свій час, я відскочу на хвилинку від бази даних. Мультимедійна група (Відейко, Богданець, Корбут, Бабенко) займалась тривимірним моделюванням. Це частково відбито в в «Археометрії». Були зроблені моделі трипільських керамічних посудин, потім – двоповерхових будинків і нарешті – цілого трипільського поселення Майданецьке, котре займало площу десь 200 га і мало з півтори тисячі окремих будівель. На основі цих моделей було згенеровано відеофайли, котрі показували об’єкти в послідовному обході (а поселення – з висоти пташиного лету, неначе обліт не вертольоті). Генерація цих відеофайлів теж перевищувала можливості наших комп’ютерів – хоча відео було коротке, з малою частотою кадрів і малого піксельного розміру, його створення займало багато годин і можливо було хіба що вночі.

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

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

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

1, найвідповіднішою для даної предметної області була об’єктна модель даних;

2, база даних повинна підтримувати зображення пам’яток;

3, геоінформаційна складова – важлива, але її реалізацію слід відкласти до грецьких календ (або до морковкина заговенья, залежно від того, що настане раніше);

4, база даних повинна працювати під управлінням ОС Windows;

5, база даних повинна працювати автономно на комп’ютерах клієнтів (серверний варіант практично не розглядався);

6, база повинна підтримувати синхронізацію примірників, котрі редагувались незалежно на окремих клієнтських машинах (як наслідок рішення 5).

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

В розробці цих вимог найбільшу участь узяли я, Панченко та Юрій Борисович Кабаков, про якого я ще не мав нагоди згадати. Він працював в Інституті кібернетики, а в ІПД – за сумісництвом. Як програміст-практик він участі в написанні коду не брав, але як фахівець з моделей даних був для нас надзвичайно корисним. Послухавши наші розмови, він розробив математичну концепцію «історичної дати», власне, алгебру історичних дат (алгебра, хто не знає – система аксіом, яка передбачає операції «додавання» та «множення» об’єктів…). Цю новаторську концепцію він виклав у своїй в «Археометрії», і ми з ентузіазмом включили її в план бази даних.

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

Далі можна було поставити собі запитання – хто і як має будувати цю базу даних, виконувати проект «в металі», в комп’ютерних кодах? Типова відповідь була би – доручити це спеціалізованій фірмі з розробки програмного забезпечення, так, як це робиться скрізь і всюди і позначається модним нині словом outsourcing. Ми такий варіант навіть не розглядали серйозно:

1, які гроші міг віддати сторонній організації ІПД, котрий не міг оплатити один телефонний номер?

2, в світі outsourcing панує просте правило: чого нема в технічному завданні, того зроблено не буде.

А яке завдання ми могли виставити, коли нам самим не було до кінця ясно, чого ми хочемо? От, наприклад, «об’єктна модель даних» – існує кілька різних схем побудови об’єктних архітектур, і чи можемо ми віддати це на волю виконавця, чи повинні сформулювати якісь вимоги? Скажімо, чи має бути система визначень класів жорстко зашита у програмі (простіше в реалізації), чи користувачі повинні мати змогу модифікувати визначення класів і додавати нові по мірі потреби (складніше в реалізації, але гнучкіше і тому довговічніше)? А перш ніж формулювати вимоги такого роду, треба дуло визначити, чи така модель взагалі надається для реалізації. Тобто перш ніж проектувати детальну структуру класів, слід знати, чи вона взагалі буде затребувана. І це – тільки одне з десятків питань, котрі лежать на шляху від ідеї програми до реально працюючого коду.

Тому ІПД не мав іншої ради, як спробувати реалізувати поставлені вимоги самотужки. Технічне завдання пише виконавець, нікуди від цього не подінешся…

Другою проблемою, котру нам треба було розв’язувати, був вибір відповідної технічної основи для бази даних. Вимога підтримки зображень однозначно диктувала «вибір» ОС. Слово «вибір» узято в лапки, тому що це були давно нам знайомі радянські вибори з одного кандидата. Що можна було вибирати, коли 99.9 % персональних комп’ютерів використовувало Windows? Позитив тут був у тому, що ця ОС добре підтримувала роботу із зображеннями.

Від клієнт-серверної архітектури, яку ми бачили в музеї і яку я вивчав по книжках, довелось відмовитись на користь клієнтської (настільної) бази даних. Братись за розробку серверної архітектури в ІПД, котрий не міг собі дозволити сервера навіть для експериментів, було б… нераціонально, скажемо м’яко.

До того ж клієнт-серверні комплекси прирікають установи, котрі беруться їх розгортати, на створення спеціальних підрозділів з їх експлуатації. Нікого не дивує, що на установу в 200 – 300 працівників має бути електрик, який забезпечує подачу електроенергії і тим самим – роботу цілої установи. Але далеко не всім керівникам очевидна вимога створення відділів з експлуатації комп’ютерних систем, і далеко не скрізь інструкції дозволяють це робити. А без них складні комп’ютерні системи не будуть працювати. Велика жирна крапка.

Асортимент настільних (клієнтських) СУБД визначався можливістю «дістати». Пригадую розмову в комп’ютерному магазині на другому поверсі книгарні «Наукова думка» (вул. Грушевського, 4). Там я купував якусь залізяку і зайшла з продавцем мова про бази даних. От він і каже: «Купіть у нас Oracle – не пошкодуєте. Є в нас і Personal Oracle (тобто настільний)». Але ж заради експериментів – усього не купиш (а ІПД не міг купити не тільки «усе», а рішучо нічого). Про експеримент з ArcView я уже написав, далі були Microsoft Access та Delphi + Paradox.

Я люблю Microsoft Access! Я знаю досконало всі його можливості, особливості та обмеження, і навіть на божевільну плутанину в розподілі функцій між макрокомандами та Visual Basic я дивлюсь як на милий каприз. Так само мені мила плутанина між комами і крапками з комами в однакових в цілому операторах Visual Basic та запитів (queries), між можливостями форм та звітів і т. д.

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

Слід знати, що Microsoft Access – єдина у своєму класі програма, котра не має близьких аналогів. Вона поєднує функції настільної СУБД (з усіма можливостями мови SQL, Structured query language, що само по собі є величезним плюсом), середовища розробки прикладних програм і великої колекції вбудованих функцій, котрі покривають більшу частину потреб прикладної програми. Microsoft Access цілком справедливо хвалиться, що він забезпечує розробку і експлуатацію баз даних без програмування (у простих випадках, ясна річ).

Тому для першої спроби реалізації бази даних було взято Access, останної на той час версії 2.0. І дуже скоро з’ясувалось, що він абсолютно не озброєний для роботи із зображеннями. Експерименти по зберіганню графічної інформації в Access дуже скоро показали нам, що це заняття – не для слабких духом (я навіть статейку на цю тему тоді написав). На честь Access слід сказати, що й нині, через 20 років і масу нових версій, він залишається таким само стійким і глухим до графічної інформації, яким був на початку. Не царське це діло – і край.

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

Отже, цей напрямок довелось залишити.

Я люблю Delphi! Я сміливо користаюсь виключним правом програміста мати стількох коханок у світі систем програмування, скільки душа забажає.

Про Delphi я вперше почув від Миколи Корбута, який сам в цій системі не працював, але знав про її можливості. Я «дістав» – здається версію 1.0 для Windows 3.1 – і одразу в неї закохався. Використана там алгоритмічна мова Object Pascal була мені прекрасно знайома з попередньої реалізації – Turbo Pascal 6.0 для MS DOS, і взагалі вона така проста й логічна, що вивчення її з нуля зовсім не складне. А тут до цієї мови приєднано візуальний редактор екранних форм з великою бібліотекою готових компонентів – знай перетягай їх мишкою на форму і користуйся. Плюс швидкий і надійний компілятор, плюс можливість написання і встановлення саморобних компонентів (чим довелось скористатись), плюс вичерпна ясно написана документація – все це заслужено робило Delphi законодавцем мод в галузі візуального програмування і програмування для Windows взагалі.

Я люблю її строгу типізацію даних, її найкращу, зразкову об’єктну модель і пов’язану з нею можливість динамічної підміни типів даних (run-time type identification, RTTI), її геніально реалізований тип «строка» (string), її прекрасну систему управління динамічною пам’яттю (heap memory) і багато інших знахідок.

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

Другий недолік полягав у складній, неоковирній і ненадійній в роботі колекції компонентів для роботи з базами даних (власне, з Paradox, бо інших не було). Розробники Delphi написали для неї багато прекрасних, надійних і зручних компонентів, але з компонентами баз даних їх рішучо «лихий попутав». Вони були нездалі як з архітектурної (проектної) точки зору, так і з точки зору реалізації.

Тому, попогулявши по цих граблях, я був змушений відмовитись від Paradox. Слід зауважити, що цей поворот «усі разом» зробили програмісти всього світу, і я більше ніколи не чув, щоб Paradox десь використовувався. Через цю біду довелось відмовитись від проекту «Археометрика» і в 1999 році розпочати новий – «Мислене древо».

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

Далі роботи по вдосконаленню програмного забезпечення і наповненню бази даних велися паралельно, причому я займався в основному програмою, а Панченко з колегами – наповненням.

Перш за все було вирішено ввести в базу паспорти пам’яток національного значення, перелік яких було затверджено постановою Кабінету міністрів у 2001 р. При цьому згадали про стару колекцію паспортів, написаних це в 1980-і роки, коли пізньобрежнівське начальство вирішило було підготувати «Звід пам’яток історії і культури СРСР». Ідея вдарити опудалами товариша Леніна по американському імперіалізму усім сподобралась, і почалися підготовчі роботи. Організацію всього проекту було покладено на Міністерство культури СРСР (так, це не помилка! Культури не було, а Міністерство – було!).

Міністерство розписало цей наказ на музеї, і в них почали створювати відділи охорони пам’ятників Леніну (ну, офіційно вони звались якось інакше, але суть була така). В Україні головним вважався Київський історичний музей, тож копії усіх паспортів накопичувалсь там.

Після здобуття незалежності цей музей переіменували на Національний музей історії України, а стоси паспортів на опудала товариша Леніна передали «на разсмотреніє мишам». Їх поклали у якомусь будиночку в Голосіївському лісі, призначили сторожем відставного організатора Ленінських кімнат на радянських підводних кораблях Петра Михайловича Калугіна – і забули.

Згадали про них, кажу, у 2001 році, і наші співробітники їздили до Калугіна по паспорти потрібних нам пам’яток. Була розроблена форма документа Word, в який переносились текстові дані з паспортів, при цьому доводилось відкидати усе радянське пустословіє, заради якого, власне, і починалося усе радянське пам’ятко-паспорто-писаніє, і залишати тільки фактичні дані. Плани й фотографії, прикладені до паспортів, сканувалися і також приводилися до певного стандарту, розробленого тим же Панченком. Недоліком такої схеми роботи була неможливість найменшої перевірки даних, внесених 20 і більше років тому (навіть адреси багатьох пам’яток змінились через переіменування вулиць), а також відсутність необхідного оновлення (інспекції, стеження, чи як модно нині говорити – monitoring пам’яток).

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

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