Гадки щодо взаємодії суспільних стосунків та моделей даних у базах даних

(роздуми над декотрими ідеями Віктора Глушкова)

Микола Загорський (Mikołaj Zagorski)

Тим, хто читав хоча б деякі популяризації ідей Глушкова, має бути відомим, що на питання, які саме суспільні форми передбачає ЗДАС, він відповідав, що цей технологічний проект ніяк не обмежує суспільні форми, всередині яких розгортається автоматизована обчислювально-облікова праця за винятком обов’язкової відсутності комерційної таємниці. Контекст всіх відповідей Глушкова на подібні питання дає можливість також встановити, що йдеться не про будь-яки суспільні форми, але саме про форми того суспільства, котре долає товарність всіх господарчих стосунків, котре має метою не прибутковість і швидкий обіг грошей, а дещо більш складне, те що можна позначити як економічну ефективність у сенсі, похідному від Арістотеля¹. Тобто, за Глушковим, у будь-якому разі йдеться про суспільні форми того, що називається у суспільній науці диктатурою пролетаріату. Досвідчений дослідник суспільних явищ має знати, що насправді виразної байдужості до суспільних форм не має жодне твердження про суспільне життя. Але Глушков чомусь декілька разів у розмові із Моєвим наче створює подібну ілюзію. Важко сумніватись, що це була своєрідна гра із професійною обмеженістю співрозмовників.

Насправді займатись дослідженнями того, яким саме суспільним формам сприяє здійснення ЗДАС, Глушков не став із кількох причин. Перш за все, це політична невизначеність долі ЗДАС. По-друге, це досить швидкий розвиток технічних засобів обліку й обчислювань. По-третє, це практичність Глушкова й його неповага до спостерігальних настроїв у суспільстві. Сьогодні існує версія, що Глушков казав про різноманітні суспільні форми, які пов’язані із ЗДАС, тому, що не хотів виглядати як прихильник “надмірного демократизму” для фракції своїх опонентів у КПРС. Насправді це дуже сучасна ідеологізація, ідеологічні підстави якої ледь сягають 1991 р. По-перше, Глушков, як майже будь-який інший пересічний радянський науковий працівник, ніколи не вкривав прихильності до самоврядування. По-друге, він мав багато однодумців між інших високопосадовців не тільки у ЦК КП України але й на рівні вищих органів КПРС. По-третє, окремі необхідні технічні характеристики обчислювальної техніки 1970-х рр схиляють скоріше до того, що “самоврядування” та “демократизм” для способу застосовування системи подібних обчислювальних засобів - це дуже й дуже зовнішні характеристики. Дещо подібне доводить і суспільно-технічна історія Кіберсину — проекту загальнодержавної автоматизації у Чилі за часи Альєнде. Цікаве те, що у працях Біра можна знайти критику підходів, котрі були покладені у основу ЗДАС та навпаки, Глушков робить критику декотрих підстав “Кіберсину”. З боку Біра йдеться переважно про ієрархічну побудову інформаційних моделей та розподіл керівних сигналів. Щоправда, така побудова декотрих вузлів ЗДАС (наскільки про її взагалі можна казати, бо багато документів було знищено) обумовлювалася не тільки невдалими принципами радянського адміністрування, але й поширеністю ієрархічних баз даних у вживанні у сфері автоматизації обліку. З боку Глушкова критика принципів, котрих було покладено у основу “Кіберсин” стосувалась більше телеграфної мережі, котру радянський кібернетик вважав принципово недостатньою. Тому у Інституті Кібернетики було розпочато роботи із розробки засобів інформаційного обміну через різноманітні лінії зв’язку. Але що стосується Чилі, навряд чи тут була практична альтернатива, бо масштаби промисловості Народної Польщі чи Радянського Союзу та Чилі принципово різні за кількістю виробів та зв’язків між підприємствами.

Щоби підтвердити чи перевірити висновки щодо впливу панування ієрархічних баз даних на перспективи усуспільнення інформації у 1970-х рр., треба розібратись із технічними якостями програмних засобів, згаданих у одному з варіантів проекту ЗДАС, котрий був підготовлений пізніше 1975 р. Ці програмні засоби загальновідомі: мова програмування ПЛ/1, системи управління базами даних (СУБД) “ОКА” (рос. ОКА) та СІОД-3-ОС (рос. СИОД-3-ОС). Навряд чи буде корисно обговорювати у зв’язку із позначеними проблемами мову програмування ПЛ/1, оскільки мови програмування взагалі мають у суспільстві тільки часткове значення, тоді як саме СУБД є спеціальними програмами, котрі здійснюють функцію спільної праці над даними, тобто їхнього усуспільнення. Зараз дуже важко шукати довідки про програмні інструменти Єдиної Серії Електронно-Обчислювальних Машин (ЄС ЕОМ, pol. System Jednolity) 1970-х рр., але згадок у мемуарах вистачає, щоби зрозуміти, що СІОД - це скорочення від “система інтеграції і обробки даних”. Декотрі висновки щодо суспільних форм, котрі могла породити ЗДАС хоча б навколо себе, таким чином, можна зробити із дослідження споживчих якостей СУБД ОКА, ДІСОД (рос. ДИСОД) та СІОД-3-ОС котрих звичайно згадують у інших, ніж проекти ЗДАС, джерелах поруч.

У цьому нам допоможе російськомовне джерело — стаття 1988 р. “Програмне забезпечення банків даних (прагматичний підхід)”³. Ця стаття здається занадто пізньою, але може стосуватись нашого дослідження, бо зображує тенденції останніх років життя Глушкова, котрих на той час вже були вповні розвинуті.

Автори статті, котру ми загадали, оприлюднили дуже цікаву таблицю, що вона зображує стан розвитку СУБД у СРСР кінця 1980-х рр.

Моделі даних: І — ієрархічна, М — мережна, Р — реляційна, Ф — файлова, С — сутність-зв’язок.

Консультації щодо СУБД: П — промислова група, Е — експериментальна група.

14 між 27 СУБД, котрих загадано були експериментальними, тобто організації, котрі займалися їхньою розробкою не мали окремих консультаційно-налаштувальних відділів. 6 СУБД ще не були настільки готовими, щоби була виготовлена відносно стабільна документація, котру вимагали у разі “фондування”, тобто відправляння до фонду ПЗ. СУБД “СЕТОР” мала реалізації трьома архітектурами. Зрозуміло від радянських авторів не можна вимагати щоби вони згадали стан справ у Народній Польщі чи Демократичній Німеччині, але польська СУБД РОДАН (pol. RODAN) мережної моделі даних була більш передовою, ніж ОКА за своїми математичними принципами та одною із перших отримала модуль діалогу мовою, подібною на SQL та ще “розуміла” мову згідно рекомендацій консорціуму CODASYL так само як ОКА чи СЕТОР чи СІОД-3-ОС.

Щодо перспектив усуспільнення господарчої інформації, ми мусимо викреслити файлові СУБД, бо вони не дозволяють ефективно робити колективний облік будь-чого. Бо блокування на файловому рівні у великих колективах збільшує час очікування запису та погано впливає на читання. Таким чином різні СУБД, більш-менш придатні для усуспільнення виглядають так:

Промислові СУБД у СРСР, котрі мали промислові консультаційно-налаштувальні групи, розглянуті із боку аналогічних мов запитів та моделей даних.

На основі останньої таблиці можна зрозуміти, що у СРСР навіть у середині та кінці 1890-х рр. безумовно панують ієрархічно-мережні СУБД, причому реляційною є тільки СУБД КАРС, котра навіть у російськомовній літературі згадується рідко та на час смерті Глушкова ще не мала якихось повнофункціональних розвинених програмних пакетів.

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

Варто вже спочатку абстрагуватись від способу розташовування даних на машинних носіях у 1975-1985 роках. Оскільки він змінювався у прогресивному напрямку й займав щороку менше праці фахівців, це не був фактор, вплив якого треба вважати вирішальним. Тому треба приділити увагу головній категорії даталогії — моделі даних. Ця категорія має саме таке значення як категорія буття для науки про мислення чи поняття товар для політичної арифметики, чи категорія “резигнація” для естетики чи категорія “безпаперовість” для кібернетики. Тобто, у будь-якому разі ми маємо дещо у основі, що у декотрому сенсі протилежне головному напрямку досліджень. Бо наука про мислення не досліджує буття як таке, політична арифметика⁷ не досліджує товар, а тільки способи його переходу у протилежність, естетика не досліджує резигнацію інакше як тільки у зв’язку із її перетворенням на протилежність, тобто у всезагальну небайдужість. Саме так кібернетика є критикою паперових форм обліку й відповідних способів суспільного й технічного управління. Подібним чином даталогія, тобто наука про дані, починається із того, що її підставу складає декотра модель даних, яка обумовлює всі рекомендації щодо вираження предметного змісту у технічних формах будь-яких баз даних. Тобто треба розібратись із тим, що таке модель даних.

Модель даних можна спрощено пояснити як перелік змістових дій над носіями інформації. Наприклад, паперова картка обліку книги у каталозі бібліотеки дозволяє здійснювати заповнення у разі додання книги до фонду, зрідка удосконалення написів, перехід до шафи із книжками, перевірку написів зо допомогою реальної книги, про яку йдеться, звернення у авторський, тематичний, загальний каталог. Може здаватись, що подібних операцій дуже багато, але насправді існує кілька математичних моделей, котрі дозволяють виразити формальний зміст будь-яких операцій обліку й перевірки. Ієрархічна модель, котру покладено у основу СУБД ОКА, в наш час не зникла, а знайшла тривку реалізацію у принципах файлової системи. Її умовно ізольований фрагмент зараз може імітувати поведінку СУБД ОКА із не дуже значними змінами. Типові операції файлової системи у операційних системах Лінукс повністю відповідають головним елементарним функціям СУБД ОКА: створити й усунути каталог, створити й усунути файл, записати й прочитати його зміст, зробити перехід по каталогах (mkdir, rmdir, echo > plik.txt, cat, rm, cd). Дуже подібною була й перевірка прав доступу, яка, до речі, не має значного впливу на спосіб суспільного застосовування бази даних. Що було оригінальним, так це типізація вузлів. Тобто було позначено, що декотру адресу займає ціле число, декотру символьний рядок у кодуванні ДКОІ⁸, декотру - десятковий запис раціонального числа, декотру щось ще.

Інший підхід, котрій не має системи вузлів, але має типові попереднє відомі структури називається реляційним, але відповідний математичний об’єкт українською мовою називається “стосунок”. Цікаве, що у техніці застосовується полонізм “реляційний”, котрий у польській мові є германізмом а у німецькій мові є латинізмом із математичних трактатів. Російською мовою відповідний об’єкт називається «отношение», але у техніці застосовується англіцизм «реляционный», котрій у англійський мові є латинізмом із математичних трактатів. Білорускою мовою відповідна математична література відсутня, термінологія не вироблялася.

Математичний запис стосунку

Де обмежений (M×N) математичний об’єкт має наступні складові:

A_1..N — атрибуті або властивості чи реляційні стовпці

C_1..M — кортежі або записи чи реляційні рядки

V_{[1..N, 1..M]} — значення

D_1..N — домени або реляційні діапазони значень

T_1..N — типи значень

Приклад реалізацій математичного об’єкту у базі даних

Landoj / Країни

Уважний читач із того, що майже кожна цифрова машина має файлову систему, може вивести те, що критика ієрархічної моделі даних буде дуже штучною. Але йдеться не про організацію функціювання окремої машини, а про усуспільнення. Автоматизована система планових розрахунків державного комітету з планування (АСПР ДП СРСР) була передовсім засобом усуспільнення хай хоча б у мурах цього закладу. Тому наша оцінка має стосуватись саме цих функцій у першу чергу. Тут можна побачити що БД АСПР ДП СРСР була дуже подібна на будь-який великий сучасний файловий сервер, хіба що “файли” (вузли СУБД ОКА) були невеликими й типізованими. Ієрархічна організація усуспільнення виявилася неконкурентоспроможною для довготермінового функціювання більш-менш великих організацій. Досі вона лишається або у дрібних фірм, або на етапі формування реляційних (стосункових⁹) баз даних. Чому так виходить? Треба уявити, що якусь файлову систему із тисячами каталогів й кількома десятками тисяч файлів спробує використовувати якась організація. Очевидно, що людина не може памʼятати що й де там зберігається, у якому випадку й що саме додається до кожного із каталогів. Таким чином починають працювати відповідальні за гілку БД, котрі знають свою гілку ієрархічної БД, але погано розбираються у сусідніх. Згодом їм стає потрібним наче координатор, котрий фактично керує способами додання інформації. Щоби уникнути зайвого дублювання інформації згодом видаються директиви про те, де шукати еталонні форми якихось первинних довідок. Подібних директив стає щоразу більше й навіть деспотичне втручання керівників не вирішує проблеми, бо обробці підлягає щоразу більше даних. Ієрархічна велика база даних як спосіб усуспільнення даних вибудовує навколо себе ... ієрархію. Це звичайна історія американських комерційних фірм, котрі майже всі закинули ієрархічні бази даних ще до кризи 1998 року. Але, ось іронія історії, Держплан СРСР, який мав труднощі через те, що ієрархічні стосунки більш не дозволяють збільшувати економічну ефективність, спробував вирішити ці проблеми створенням ієрархічної бази даних, котра вибудовувала навколо себе ... ієрархію. Тобто, оскільки Держплан СРСР мав відділи й відповідальних за гілки БД, СУБД ОКА заважала навіть інформаційній єдності усередині закладу. Бо купа партикулярних справ не є колективною справою, хоча протилежна теза правильна.

Яка була альтернатива на той час? Фахівці того часу у спогадах поруч із СУБД ОКА згадують СУБД ДІСОД. Це була вже система управляння мережевою базою даних. Тобто треба розібратись із суспільними якостями сіткових баз даних¹⁰.

Математичне вираження ієрархічних баз даних називається орієнтованим графом, де кожен вузол має приймати лише один зв’язок (від вищого) та віддавати скільки завгодно зв’язків нижчим. Мережева база даних виражається подібною математичною структурою, яка відрізняється тільки тим, що вузол може бути закріплений одразу на кількох гілках. У суспільному й адміністративному сенсі це означає, що можна уникнути дублювання даних, якщо вони стосуються чогось одного. Тобто дані з матеріалів для будування шкіл можна одразу додати у вузли планування для міністерства народної освіти Радянської Литви й міністерства будівництва цієї радянської держави. Тому редагування через одну адресу автоматично змінює те, що доступно через інші еквівалентні, бо всі адреси посилаються лише на одну структуру даних. Важко не помітити, що це зовнішнє об’єднання, здійснення якого покладено на кмітливих техніків чи добродіїв-плановиків. “Якщо хтось помітить, що є дублювання...” - цей вислів характерний для пізньорадянського формалізму й непевності. Ніяких формальних способів протистояння дублюванню тут немає, працівникам з планування нічого не допомагає його уникати, між відповідальними за різні гілки так само існує “координатор”, котрий має тенденцію перетворюватись на пана.

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

У сучасності даталогічна фракція щодо загальнодержавної автоматизації звичайно пов’язується із реляційною моделлю даних. Це може здаватись природним, але історично така асоціація має більш математичні, ніж технічні передумови. Цікаво, що всі проекти ЗДАС містили посилання на ієрархічні бази даних, зокрема на СУБД ОКА. Навіть той проект 1980 р., який Глушков вже не підписав з причини фрагментарності й суспільної потворності, має саме ієрархічні БД як основу. Постає питання, чи згадується про реляційні бази даних у працях Глушкова?

Ідею реляційних баз даних було подано британським математиком Едґаром Коддом у другої третині 1970 року. Початкову публікацію англійською мовою зайти неважко: Edgar F. Codd, Communications of the ACM, Vol. 13, No. 6, June 1970. Тобто хронологічно між цією публікацією й кінцем життя Глушкова є як мінімум 12 повних років. Через кілька років у Сполучених Штатах відбудеться перша проба публікації проекту мови запитів у бази даних, котра ґрунтується на англійській мові й котра пізніше перетворилась на загальновідому SQL, для розуміння якої зараз знання англійської лексики майже нічого не дає й якому її незнання не заважає.

У популярному підручнику — у російськомовній книзі “Основи безпаперової інформатики”, Глушков торкається формальної мови звернення до ієрархічних баз даних, але реляційну модель даних розглядає переважно як перспективну математичну концепцію, яка ще не зазнала своєї виразної реалізації. Це не дивно, бо свої відомі 12 правил, полеміка над якими відкрила низку сучасних реалізацій колективних реляційних баз даних Едґар Кодд оприлюднив тільки 1985 року, більш за через 2 роки по смерті Глушкова. Очевидно, що за життя Глушкова відбувалося початкове накопичення знань із особливостей застосовування реляційної математичної моделі до реалізації колективних баз даних.

Що стосується ієрархічної моделі даних, то вже 1969 року у Сполучених Штатах була спроба створити стандарт мережевих баз даних. Це відомий та згодом міжнародно визнаний стандарт CODASYL, котрий отримав назву консорціуму, що його створив - DBTG CODASYL / 1969.

Значення баз даних як інструментів усуспільнення Глушков зрозумів не одразу. Безумовно, всі роки своєї діяльності, пов’язаної із кібернетикою, він був прихильником усуспільнення інформації й заміни ринкових стосунків науковою регуляцією господарчого життя. Але виходить, що це усуспільнення мислилося десь до кінця без 1970-х років без баз даних. У відомій “Енциклопедії кібернетики” 1973 року не можна знайти статті “Банк даних” чи “База даних” та навіть у короткій статті “Дані” є тільки згадка про “Автоматичну систему обробки даних”. Не важко зрозуміти, що це дещо більш широке, ніж база даних чи банк даних, та що у цьому випадку проблематика усуспільнення інформації не є центральною. Але вже 1980 року¹¹ Глушков присвячує цій проблематиці окремий шостий розділ “Основ безпаперової інформатики”. У початку він пише: “Адже починаючи із 1960-х років і зокрема у 1970-ті роки головна маса застосовувань ЕОМ отримала інший, так званий системний напрямок”. Далі Глушков розкриває читачеві базу даних як інструмент економії праці з оцифровування, відокремлення виконання обчислювальних завдань від актуалізації інформації, натякаючи також на тенденцію до усуспільнення інформації. Щодо кожної сфери такої інформаційної автоматизації Глушков постулює існування інформаційної моделі як системи даних про об’єкт. Таким чином, вже перші два абзаци дозволяють читачеві зрозуміти технічні передумови проблематики усуспільнення інформації. Згодом Глушков заперечує такий підхід, коли під кожне завдання існують окремі системи інформації як технічно відсталий та такий, що не дозволяє економити час і працю через одноразове оцифровування. Ще у 1970 році Глушков висував ідею “програмно-технічного комплексу”, суть якої полягала в тому, щоб не робити керуючі машини і програми під окремі завдання, а робити машини і програмне забезпечення для цілих класів подібних завдань з подальшою спеціалізацією під конкретне завдання. Зараз дещо важко зрозуміти, чи включала в себе ця ідея і ідею БД, але це було б цілком логічно. До речі, тоді Глушков був упевнений, що у капіталістичному світі нічого подібного на програмно-технічні комплекси немає, бо у США типовою була оренда обчислювального часу різними організаціями під різні потреби у обчислювальному центрі. Саме тому повторне використовування (збіг) якихось початкових чи похідних масивів інформації було майже неможливим бо оренда підпорядковується ринковому хаосу і комерційній таємниці.

Вже ці три абзаци з “Основ безпаперової інформатики”, в яких Глушков розкриває проблематику баз даних, виявляються дуже важливими для оцінки наукових перспектив кібернетики. Вони дозволяють зрозуміти, чи можливо побудувати кібернетику як сферу застосовування діалектичної логіки, як так звану “застосункову логіку” саме так, як трапилося із політичною арифметикою у Маркса, психологією у Виготського, естетикою у Канарського. Відповідь Глушкова на це питання, без сумніву, позитивна. Але йому вже не було коли виконувати цю програму як у фізіологічному так і у політичному сенсі. Подібно до всіх наук, яких було згадано, кібернетика виявляється партійною й класовою, у центрі проблематики баз даних постає об’єкт-суб’єктний стосунок людини із машиною та конфлікт суспільних сил, котрі зацікавлені у принципово різному застосовуванні баз даних. Це крок-у-крок повторює ситуацію, котру можна побачити у сфері політичної економії.

Таким чином, вхід проблематики усуспільнення інформації у інформатику Глушков датує початком 1970-х років. Це збігається із розвитком СУБД ОКА у СРСР, СУБД ІМС у Сполучених Штатах а також із популяризацією стандартів CODASYL.

Відмінність баз даних та банків даних, котру можна побачити у літературі десь до 1990-х років виходить із того, що база даних розглядається як стан пристроїв зберігання, тобто як інформація, яка зберігається. На противагу, банк даних - це також у додаток програми, котрі разом із базою даних виконують функцію з усуспільнення інформації. Ця різниця між базою даних й банком даних взагалі пояснюється тим, що у ієрархічних базах даних змістові запити формуються дуже важко й вимагають численних консультацій програмістів й праці із програмування. Наприклад, порівняння витрат будівельних матеріалів у школах Татарстану й Волині у АСПР ДП СРСР вимагало взаємодії, як мінімум, трьох фахівців. Перший знав, у якому форматі веде ці дані Держплан УРСР та міг написати ієрархічні адреси, де можна ці дані отримати. Другий знав те саме про Татарстан, де формат цих даних був трохи іншим. Ще одна людина, отримавши “емпіричну повноту” від перших, пише програму перероблення у вигляд, придатний для порівняння. Ці три людини, котрі допомагали реалізувати змістовий запит та їхні програми, складають банк даних. Реляційна модель даних передбачає інший механізм: без допомоги програмістів будь-який працівник планових органів або народної інспекції може знайти коди потрібних шкіл у таблиці “Школи”, знайти всі згадки цих кодів у таблиці “Будівельні витрати” й об’єднати результат так, що подібні витрати (“дерево на двері”, “метал для меблів”, “метал на двері”) можна буде порівняти у таблиці порівняння. Реляційна модель побудування баз даних дозволяє запобігти значних втрат праці програмістів. Ба, більше, сучасні реляційні бази даних дозволяють зберігати усередині себе окремі процедури мовами програмування. Щоправда у кожній базі даних ці мови різні: у SQLite це SQL (у тригерах), у Firebird це своя мова, у Oracle це Ява й внутрішня мова, у PostgreSQL це одразу кілька мов на вибір. Таким чином, сучасні бази даних отримують всі функції банків даних й частково перетворюються на середовища програмування, якщо його метою є усуспільнення інформації. Це означає, що у сучасних базах даних ця проблематика концентрується набагато виразніше, ніж у часи Глушкова.

Головна суспільна різниця реляційної й ієрархічної моделі даних полягає майже у тому, у чому полягає формальна різниця феодальної й капіталістичної суспільних форм економічної суспільної формації. Феодалізм лише на пізній стадії зазнає хоча б скількись виразної національної універсалізації, як то формування єдиної метрологічної системи чи літературної мови. До того часу панує розподіл правил та законів, котрі розрізняються у тотожних сферах між сусідніми територіями. Коли замінити території гілками бази даних, можна буде отримати малюнок структур даних у базі даних Автоматизованої системи планових розрахунків державного комітету з планування СРСР. Як відомо, подібні Бальцеровичу ідеологи ринкових стосунків критикували господарство Народної Польщі за надмірну централізацію, яку вважали ще більш властивою радянській господарській практиці. Але дійсна ситуація із інформацією на рівні усуспільнення, тобто спеціальної функції колективних баз даних, була у СРСР не тільки дуже відмінна від уявлення ідеологів, а прямо протилежна йому. На рівні моделей даних та інформаційної доступності усуспільнення господарської інформації у СРСР задовольнялося ієрархічними базами даних, котрі у довготерміновому продовженні тенденцій свого розвитку були протилежні тенденціям демократизації, економії праці програмістів, одного інформаційного еталону, зрозумілості, інформаційної централізації тощо. Цікаво, що ефективні способи реалізації реляційної моделі даних взагалі не цікавили й не цікавлять працівників планових органів, якщо шукати хоч якісь загадки у спогадах чи у у документах планових органів Латвії й Литви. Тільки Віктор Глушков у своїй останній книзі відзначає перспективність реляційної моделі даних з точки зору усуспільнення інформації й демократизації його безпаперового способу. Але на той час Глушков вже не був дуже впливовим у політичному сенсі.

Наскільки взагалі раціональним є розгляд суспільного сенсу категорії моделі даних? Існує погляд, наче цей сенс випадковий, і модель даних як головна категорія даталогії може виражати тільки рух технічних засобів. Але ж техніку завжди застосовує якась людина, яка бере таку чи іншу участь у стосунках власності, та яка пробує реалізувати свої інтереси через техніку. Тому існують фізично можливі, але суспільно заблоковані способи застосовування технічних інструментів. Кібернетика, оскільки вона нерозривно пов’язана із безпаперовим обліком й проблемою єдиного інформаційного простору, виявляється неприховано партійною наукою так само, як політична економія, психологія чи естетика. Матеріалістична лінія полягає у тому, щоби максимально застосовувати можливості техніки для покращення людського життя широких мас, а також зробити справу наукового застосовування кібернетики їхньою справою, так само, як все їхнє життя втіленням кращих досягнень світової науки. Бо відомо, що деякі суспільні сили вимагають обмеження обліку повільними й обмеженими способами, оскільки повний облік та інформаційна централізація дозволяють будь-кому легко зрозуміти паразитичну ресурсну ситуацію та полегшує спрямування зусиль щодо усунення паразитів. Це називається комерційна таємниця. Її скасування принципово змінює наукову ситуацію у даталогії та сенс категорії “модель даних”. У капіталістичних умовах даталогія грає пасивну роль дисципліни чи мистецтва щодо вираження наявних стосунків через певний перелік елементарних інформаційних операцій у колективній базі даних. Коли умови прибутковості буде подолано, постане питання як будувати модель даних таким чином, щоби вона сприяла своєму зрозумінню щоразу більшою кількістю людей, тобто усуспільненню ресурсно-господарської, в першу чергу, інформації. Протилежності перетворюються одна на одну: замість питання “як виразити наявне” даталогія переорієнтується на питання, “що найкраще можна пропонувати для справи отримання суб’єктності виробничою більшістю суспільства”. У першому разі даталогія обмежується до стану окремої технічної дисципліни у складі інформатики, у другому разі вона будується як повноцінна партійна наука на основі логіки й теорії пізнання сучасного матеріалізму. У першому разі люди обмежують можливості техніки, у другому разі техніка розширює творчі можливості людей.

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

Як відомо, у Радянському Союзі реляційна модель даних ніколи не стала фактором полегшення усуспільнення господарської інформації. Тому ми не можемо досліджувати у архівах планових органів радянських країн, які саме стосунки породжує довкола себе реляційна колективна база даних. Спробуємо це зрозуміти.

Ієрархічна модель даних та її типові системи управлення базами даних дозволяють зробити сусідні гілки подібними чи копіювати їх. Але підтримувати тотожність форматів різних гілок у програмах, про які згадувалося, важко. Вони взагалі не вважають одноформатність важливою рисою довкола якої концентрується багато автоматизованих функцій. Тому, наприклад, розгалуження шаблонізованої гілки “РРФСР” у БД АСПР ДП СРСР під іншими назвами не дозволяє гарантувати, що через декотрий час способи отримання якоїсь суми по областях РРФСР й УРСР лишаться тотожними. Зміна форматів різних гілок не є синхронною, різниця накопичується на основі “адміністративних вказівок та важливих технічних винятків”. Тому, коли треба якось порівнювати транспортний дебет Криму, програми для звернення до даних обліку Херсонської області й Краснодарського краю з часом лишаться різними. Ба, більше, у кожному разі треба знати повну адресу даних, які треба порівнювати. Йдеться про те, що не можна пізнати якісь коди, виписати їх та перевірити взаємний транспортний дебет областей чи ще якихось адміністративних одиниць. Треба знати повну адресу транспортних даних Херсонської області, котра може, по історичних чинниках, мати інший принцип формування, ніж для Краснодарського краю. Бо це, по-перше, край, а не область, а по-друге це Росія, а не Україна. На відміну від народного сприйняття, адміністратори у СРСР завжди це різко розрізнювали. Та, зрозуміло, це звинувачення ієрархічної моделі даних у підтриманні сепаратизму. Не те, щоби це був дуже впливовий фактор, але це був черговий фактор із багатьох, яких можна було уникнути.

Реляційна модель даних не лишає нічого від “таємних знань” окремих програмістів, котрі тільки й знають, як яку гілку побудовано. У основу побудування реляційних таблиць (“стосунків” математичною мовою) Едґар Кодд поклав принцип типізації, котрий у теоретичному сенсі продовжує принцип стандартизації у промисловості. Йдеться про те, що оголошується якась “сутність”, котра має перелік “властивостей”, котрі мають “можливі значення” або, як пишуть математики, “домени потрібного типу”. Так, воєводство має метричну площу, назву столиці місцевою мовою, окремий статус, воєводу тощо. У Радянському союзі адміністративні одиниці були дуже різноманітні, але вони мали теж дуже подібні властивості. Метрична площа - це у будь-якому разі число, назва столиці це завжди рядок, час заснування завжди дата, окремий статус - завжди код із якогось переліку. Кодд запропонував із названих “доменів”, тобто елементарних типів, будувати будь-які змістові структури, котрі мають універсальність, обмежену тільки умовами проекту, а не технічним застосовуванням, як у ієрархічних базах даних із різними гілками. Тобто реляційна модель даних, котру запропонував Кодд, дозволяє робити необмежену інформаційну централізацію через інформаційну стандартизацію. У ієрархічних базах даних універсалізація та централізація даних доручалася, майже винятково, акуратності, кмітливості й уважності людей. У реляційних базах даних, навпаки, ці функції майже винятково покладено на машину.

Щодо універсалізації й централізації, котрі легко реалізуються у реляційній моделі даних, то вони стосуються не тільки технологічного обліку, але й мовного питання. У пізньому СРСР по мері зростання ролі “ринкової регуляції” (насправді хаотизації) господарського життя також щороку підіймали голову різноманітні націоналістичні течії. Мовоцентричні аргументи були для населення радянських країн щороку більш переконливі. Цікаво спостерігати по документах, що у мовному сенсі автоматизовані процедури планування майже ніяк не регулювалися. У декотрих ієрархічних базах даних у СРСР система назв гілок будувалася англійською мовою, бо “все одне це не публічний документ” та вважалося, що вона буде мати сенс тільки для програмістів, котрі запозичали структури даних із англомовних книжок. Подібного аристократизму та бажання зробити ще один “прошарок перекладу сенсу” не було навіть у Сполучених Штатах, де англійська мова на той час була переважною природною мовою більшості населення. Була й протилежна ситуація, коли гілки даних щодо різних республік іменувалися кирилізацією або латинізацією якоїсь мови. Були й спроби повного зросійщення системи іменування об’єктів у базах даних. Але спроби зберігати переклади написів у базі даних та міжміського машинного зв’язку терміналів із виводом різними мовами теж відбулися вже не у СРСР. Лише через кілька років після дезорганізації радянського суспільства було висунуто ідею застосовувати у структуризації реляційних баз даних проміжну спрощену планову мову, котра не дає переваги жодній нації. Програмна підтримка назв об’єктів реляційних баз даних мовою есперанто з’явилася лише 15-20 років тому. Тому у Радянському Союзі реляційні бази даних не стали інструментами на користь господарської та людської універсалізації проти мовоцентрізму та асиміляції. Важко зрозуміти, чи надіявсь хоч хтось на подібну технічну допомогу для продовження ленінської національної політики. Найбільш ймовірним здається що ні. Що стосується Глушкова, він, як можна побачити із запису розмови із Моєвим, більш надіявсь на суспільну демократизацію нових способів обліку у найближчому майбутньому та не відокремлював мовне питання у цьому контексті. На противагу надіям Глушкова на суспільну домократизацію, зараз відбулася лише технічна демократизація нових способів обліку. Щодо головного, тобто усуспільнення ситуація стала набагато менш розвиненою, зазнала виразного й беззаперечного відкату.

Який розподіл праці породжує біля себе реляційна база даних? Із першого погляду здається, що він дуже подібний на професійну систему. Тобто лікар засвоює якусь групу таблиць та їхні зв’язки, котрі стосуються лікарської справи, іншу групу таблиць всезагальної автоматизованої системи засвоює промисловий конструктор. Всезагальний зв’язок у реляційних базах даних висловлюється через концепцію ідеальних представників або зовнішніх ключів. У ієрархічних базах даних немає близького аналогу цієї концепції. Так, транспортний дебет Криму у БД АСПР обчислюється на основі знання побудови гілок сусіднього краю та області. Реляційнв БД дозволяє створити загальнорадянську таблицю регіонів та таблицю зв’язків, де коди регіонів можна писати двійками. До цих зв’язків регіонів можна додавати показники різного часу та навіть посилатись на датчики-лічильники на залізницях, як пропонував Глушков. Оця ідея повної інформаційної централізації дозволяє розкрити широкі можливості місцевого самоврядування на основі правильного зрозуміння своїх стосунків із іншими. Таким чином, реляційні бази даних у разі посилення усуспільнення й демократизації працюють проти адміністративної централізації, лишаючи центрові тільки загальне балансування й започаткування загальнозначущих великих господарських планів. Це як раз дозволить впровадити повсюди наукову регуляцію розподілу ресурсів й зменшити роль ринкових стосунків через узгоджений наступ на них як через місцеві спільноти, так і через загальне центральне балансування.

Чи не є групи таблиць у реляційних базах даних подібними до “хаток професійного кретинізму”, котрі добре відомі всім нам? На жаль, ми не можемо заперечити цю тезу якимись емпіричними прикладами, бо протилежні способи розвитку дидактичного значення баз даних ще не дуже виразні. Можна казати, що саме педагогічно-демократична сторона баз даних зараз майже не має якогось систематичного розвитку, оскільки умови товарного господарства примушують орієнтуватись на прибуток, а не на споживчі властивості будь-якого виробу, у тому числі й баз даних. Але, якщо порівнювати реляційні бази даних із ієрархічними, можна помітити, що їхнє зрозуміння стає набагато простішім. Зараз розуміння структур баз даних дуже широко розповсюджене між людьми, котрі не мають жодних навичок із програмування та нерідко навіть не уявляють загальні принципи програмування. У Польщі вивчання баз даних передбачається багатьма програмами на етапі між основною школою (szkołą podstawową) й вищими закладами для тих, кому знання з обчислювальної техніки не передбачаються вимогами офіційних фахів у навчальних закладах. Надію на продовження цієї тенденції (хоча й повільне) дає також розвиток засобів зберігання інформації. Перш за все, перехід від лінійних накопичувачів до ієрархічних баз даних призвів одразу до зменшення ролі програмування й появи окремих програм — систем управління базами даних, що було виразним кроком у напрямку усуспільнення й зменшення значення ремісницького програмування. Щодо програмування це було технологізацією виробництва програм для усуспільнення. Дуже подібною революцією був розвиток реляційних баз даних на твердих дисках із механічними двигунами та концепцією циліндрів/секторів/головок. Ця концепція була набагато менш технічно обмеженою й набагато більш зрозумілою для непрограмістів, ніж концепція лінійних перфострічок чи інших лінійних носіїв. Зміна лінійних носіїв на тверді диски була відзначена збільшенням кількості відносно оперативно доступної інформації. Наступна революція пристроїв зберігання відбувається на наших очах, коли механічні тверді диски замінюються швидкими енергонезалежними пристроями зберігання на основі інтегральних схем. Отут кількість “зовнішньої” для процесора доступної інформації дорівнює ємності пристроїв зберігання, а швидкість доступу до зовнішньої інформації сягає швидкості пристроїв оперативного зберігання. Це означає, що рівна й дуже висока швидкість доступу стосується всього масиву інформації, який підпорядкується програмам управління базою даних. За собою це тягне зростання значення розуміння змісту бази даних на противагу особливостям її зберігання чи навичкам формального маніпулювання. Це одразу передумови швидкого усуспільнення й широкої демократизації. Створення широких шпигунських баз даних дозволяє побачити, що капіталістичний розвиток цих тенденцій вже змінює життя широких народних мас багатьох країн. Разом із тим, подібні ж тенденції дозволяють знову поставити питання про розвиток даталогії як кібернетичної дисципліни про створення баз даних, котрі щонайкраще сприяють усуспільненню інформації й демократизації знань з безпаперового обліку й контролю. Але це має своєю політичною передумовою свідомий рух у бік нетоварності. Таким чином, відродження даталогії можна невідривно пов’язати тільки із політичним режимом, котрий поставить для себе метою подолання товарного тиску на всі сфери суспільного життя.

____

кінець статті