Мысли о взаимодействии общественных отношений и моделей данных в базах данных (2017)

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

Миколай Загорский (Mikołaj Zagorski). 2017. Двуязычная версия.

Это первая версия статьи, ссылка на вторую версию (2024).

Тем, кто читал хотя бы некоторые популяризации идей Глушкова, должно быть известно, что на вопрос, какие именно общественные формы предполагает ОГАС, он отвечал, что этот технологический проект никак не ограничивает общественные формы, внутри которых разворачивается автоматизированный вычислительно-учетный труд. Контекст всех ответов Глушкова на подобные вопросы позволяет также установить, что речь идет не о любых общественных формах, но именно о формах того общества, которое преодолевает товарность всех хозяйственных отношений, которое имеет целью не прибыльность и быстрое обращение денег, а экономическую эффективность. То есть в любом случае речь идет об общественных формах того, что называется в общественной науке диктатурой пролетариата. Опытный исследователь общественных явлений должен знать, что на самом деле выразительного безразличия к общественным формам не имеет ни одно утверждение об общественной жизни. Но Глушков почему-то несколько раз как бы создает подобную иллюзию. Трудно сомневаться, что это была своеобразная игра с профессиональной ограниченностью собеседников.

На самом деле заниматься исследованиями того, каким именно общественным формам способствует осуществление ОГАС Глушков не стал по нескольким факторам. Прежде всего, это политическая неопределенность судьбы ОГАС. Во-вторых, это достаточно быстрое развитие технических средств учета и вычислений. В-третьих, это практичность Глушкова и его неуважение к наблюдательным настроениям в обществе. Сегодня существует версия, что Глушков говорил о различных общественных формах, связанных с ОГАС, потому, что не хотел выглядеть как сторонник «чрезмерного демократизма» для фракции своих оппонентов в КПСС. На самом деле это очень современная идеологизация, идеологические основания которой едва достигают 1991 г. Во-первых, Глушков, как почти любой другой рядовой советский научный работник, никогда не скрывал приверженности к самоуправлению. Во-вторых, он имел много единомышленников среди других высокопоставленных чиновников не только в ЦК КП Украины, но и на уровне высших органов КПСС. В-третьих, отдельные необходимые технические характеристики вычислительной техники 1970-х гг склоняют скорее к тому, что «самоуправление» и «демократизм» для способа применения системы подобных вычислительных средств это очень и очень внешние характеристики.

Чтобы подтвердить или проверить эти выводы надо разобраться с техническими качествами тех программных средств, которые были упомянуты в одном из вариантов проекта ОГАС, который был подготовлен позже 1975 г. Эти программные средства общеизвестны: язык программирования ПЛ/1, система управления базами данных «ОКА» и программа СИОД. Вряд ли будет полезно обсуждать в связи с обозначенными проблемами язык программирования ПЛ/1, поскольку языки программирования вообще имеют в обществе только партикулярное значение, тогда как именно системы управлении базами данных являются специальными программами, осуществляющими функцию совместной работы над данными, т.е. их обобществления. Сейчас очень трудно искать справки о программных инструментах Единой Серии Электронно-Вычислительных Машин (ЕС ЭВМ) 1970-х гг., но упоминаний в мемуарах достаточно, чтобы понять, что СИОД это сокращение от «система интеграции и обработки данных». Упоминается версия СИОД-3-ОС, что указывает на связь этого программного продукта с операционной системой. То есть это тоже чисто техническая вещь, тогда как функция обобществления данных преимущественно передается СУБД ОКА.

Некоторые выводы относительно общественных форм, которые могла породить ОГАС хотя бы вокруг себя, таким образом, можно сделать из исследования потребительских качеств СУБД ОКА а также другой СУБД ДИСОД, которая обычно упоминается в других, чем проекты ОГАС, источниках рядом.

Когда сейчас речь идет об общественных факторах формирования иерархических БД, обычно говорят о том, что их понятие формируется как изображение общественного понятия иерархии в технико-математической сфере программирования. Понятно, что способ связи данных (или «модели данных», как говорят специалисты) в иерархических базах данных является математическим выражением понятия иерархии. Но, вместе с тем, взаимодействие общественного и математического понятия иерархии этим не исчерпывается. Потому что большие иерархические базы данных как форма обобществления информации формируют вокруг себя специфические общественные отношения, которые каким-то образом соотносятся с отношениями окружающего общества. То есть мы имеем критерий, позволяющий проверять отношения вокруг формирования и функционирования баз данных на прогрессивное или реакционное направление.

Следует уже сначала абстрагироваться от способа размещения данных на машинных носителях в 1975-1985 годах. Поскольку он менялся в прогрессивном направлении и занимал ежегодно менее труда специалистов, это не был фактор, влияние которого надо считать решающим. Поэтому нужно уделить внимание главной категории даталогии — модель данных. Эта категория имеет именно такое значение как бытие для науки о мышлении или товар для политической арифметики, резигнация для эстетики или безбумажность для кибернетики. То есть, в любом случае мы имеем нечто в основе, что в некотором смысле противоположно главному направлению исследований. Ибо наука о мышлении не исследует бытие как таковое, политическая арифметика (то есть критика политической экономии) не исследует товар, а только способы его перехода в противоположность, эстетика не исследует резигнацию иначе как только в связи с ее превращением в противоположность, то есть во всеобщее безразличие. Именно так кибернетика является критикой бумажных форм учета и соответствующих способов общественного и технического управления. Подобным образом датология, то есть наука о данных начинается с того, что ее основание составляет некоторая модель данных, которая обуславливает все рекомендации по выражению предметного содержания в технических формах любых баз данных. То есть нужно разобраться с тем что такое модель данных.

Модель данных можно упрощенно объяснить как перечень содержательных действий над носителями информации. Например, бумажная карточка учета книги в каталоге библиотеки позволяет заполнение в случае добавления книги в фонд, изредка усовершенствование надписей, переход в шкаф с книгами, проверку книгой, о которой идет речь, обращение в авторский, тематический, общий каталог. Может казаться, что подобных операций очень много, но на самом деле существует несколько математических моделей, которые позволяют выразить формальный смысл любых операций учета и проверки. Иерархическая модель которая положена в основу СУБД ОКА в наше время не исчезла, а нашла прочное выражение в принципах файловой системы. Ее условно изолированный фрагмент сейчас может имитировать поведение СУБД ОКА с не очень значительными изменениями. Типичные операции файловой системы в операционных системах Линукс полностью соответствуют главным элементарным функциям СУБД ОКА: создать и удалить каталог, создать и удалить файл, совершить переход по каталогам (mkdir, rmdir, echo > plik.txt, rm, cd). Очень похожей была и проверка прав доступа, которая, кстати, не имеет значительного влияния на способ общественного применения базы данных. Что было оригинальным, так это типизация узлов. То есть было обозначено, что некоторый адрес занимает целое число, некоторый символьный ряд в кодировке ДКОИ, некоторый десятичная запись рационального числа, некоторый что-то еще.

Внимательный читатель из того, что почти каждая цифровая машина имеет файловую систему может вывести то, что ее критика будет очень искусственной. Но речь идет не о функциях организации функционирования отдельной машины, а об обобществлении. Автоматизированная система плановых расчетов государственного комитета по планированию была прежде всего средством обобществления пусть хотя бы в границах учреждения. Поэтому наша оценка должна касаться именно этих функций в первую очередь. Здесь можно увидеть что БД АСПР ГП СССР была близко аналогична любому крупному современному файловому серверу, разве что «файлы» (узлы СУБД ОКА) были небольшими и типизированными. Иерархическая организация обобществления оказалась неконкурентоспособной для долгосрочного функционирования более или менее крупных организаций. До сих пор она остается либо у мелких фирм, либо на этапе формирования реляционных (реляционных) баз данных. Почему так получается? Надо представить, что некую файловую систему с тысячами каталогов и несколькими десятками тысяч файлов попытается использовать какая-то организация. Очевидно, что человеческая память не может хранить что и где там хранится, в каком случае и что именно добавляется к каждому из каталогов. Таким образом начинают работать «секторальные соответчики», которые знают свою ветку иерархической БД, но плохо разбираются в соседних. Со временем им становится нужен как бы координатор, который фактически руководит способами добавления информации. Во избежание излишнего дублирования информации впоследствии выдаются директивы о том, где искать эталоны формы каких-то первичных справок. Подобных директив становится все больше и даже деспотическое вмешательство руководителей не решает проблемы, потому что обработке подлежит все больше данных. Иерархическая большая база данных как способ обобществления данных отстраивает вокруг себя ... иерархию. Это обычная история американских коммерческих фирм, которые почти все забросили иерархические базы данных еще до кризиса 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 года нельзя найти статьи «Банк данных» или «База данных» и даже в короткой статье «Данные» есть только упоминание об «Автоматической системе обработки данных». Не трудно понять, что это нечто более широкое, чем база данных или банк данных и что в этом случае проблематика обобществления информации не является центральной. Но уже в 1982 году Глушков посвящает этой проблематике отдельный шестой раздел «Основ безбумажной информатики». В начале он пишет: «Ведь начиная с 1960-х годов и в частности в 1970-е годы главная масса применений ЭВМ получила другое, так называемое системное направление». Далее Глушков раскрывает читателю базу данных как инструмент экономии труда по оцифровке, отделения выполнения вычислительных задач от актуализации информации, намекая также на тенденцию к обобществлению информации. Для каждой сферы такой информационной автоматизации Глушков постулирует существование информационной модели как системы данных об объекте. Таким образом, уже первые два абзаца позволяют читателю понять технические предпосылки проблематики обобществления информации. Впоследствии Глушков отрицает ежезадачный подход (когда под каждую задачу существуют отдельные системы информации) как технически отсталый и не позволяющий экономить время из-за одноразовой оцифровки.

Уже эти три абзаца, через которые Глушков раскрывает проблематику баз данных оказываются очень важными для оценки научных перспектив кибернетики. Они позволяют понять, возможно ли построить кибернетику как сферу применения диалектической логики, как так называемую «прикладную логику» именно так, как случилось с политической арифметикой у Маркса, психологией у Выготского, эстетикой у Канарского. Ответ Глушкова на этот вопрос без сомнения положительный. Но ему уже было некогда выполнять эту программу как в физиологическом так и в политическом смысле. Подобно всем упомянутым наукам кибернетика оказывается партийной и классовой, в центре проблематики баз данных оказывается объект-субъектное отношение человека с машиной и конфликт общественных сил, заинтересованных в принципиально разном применении баз данных. Это в точности повторяет ситуацию, которую можно увидеть в сфере политической экономии.

Таким образом вход проблематики обобществления информации в информатике Глушков датирует началом 1970-х годов. Это совпадает с развитием СУБД ОКА в СССР, СУБД ИМС в Соединенных Штатах а также с популяризацией стандартов CODASYL.

Отличие баз данных и банков данных, которое можно увидеть в литературе где-то до 1990-х годов исходит из того, что база данных рассматривается как состояние устройств хранения, то есть как информация, которую хранят. В противоположность банк данных это также в дополнение программы, которые вместе с базой данных выполняют функцию по обобщению информации. Эта разница между базой данных и банком данных вообще объясняется тем, что в иерархических базах данных содержательные запросы формируют очень трудно и требуют многочисленных консультаций программистов и труда по программированию. Например, сравнение норм строительных материалов в школах Татарстана и Волыни в АСПР ГП СССР требовало взаимодействия как минимум трех специалистов. Первый знал в каком формате ведет эти данные Госплан УССР и мог написать иерархические адреса, где можно эти данные получить. Второй знал это о Татарстане, где формат этих данных был немного другим. Еще один человек, получивший «эмпирическую полноту» от первых пишет программу переработки в вид, пригодный для сравнения. Эти три человека, которые помогали реализовать содержательный запрос и их программы составляют банк данных. Соотносительная или реляционная модель данных предусматривает другой механизм: без помощи программистов любой работник плановых органов или народной инспекции может найти коды нужных школ в таблице «Школы», найти все ссылки на эти коды в таблице «Строительные потери» и объединить результат так, что подобные потери («дерево на двери», «металл для мебели», «металл на двери») можно будет сравнить в таблице сравнения. Реляционные базы данных позволяют предотвратить значительные потери труда программистов. Более того, современные реляционные базы данных позволяют хранить внутри себя отдельные процедуры на языках программирования. Правда в каждой базе данных эти языки разные: у SQLite это SQL (в триггерах), у Firebird это свой язык, у Oracle это Ява и внутренний язык, у PostgreSQL это несколько языков. Таким образом современные базы данных получают все функции банков данных и частично превращаются в среды программирования, если его целью является обобщение информации. Это означает, что в современных базах данных эта проблематика концентрируется гораздо отчетливее, чем во времена Глушкова.

Главная общественная разница реляционных отношений и иерархической модели данных заключается почти в том, в чем заключается формальная разница феодальной и капиталистической общественных форм экономической общественной формации. Феодализм лишь на поздней стадии претерпевает хотя бы сколько-нибудь отчетливую национальную универсализацию, как то формирование единой метрологической системы или литературного языка. К тому времени господствует распределение правил и законов, которые различаются в тождественных сферах между соседними территориями. Если заменить области ветвями базы данных, можно будет получить рисунок структур данных в базе данных Автоматизированной системы плановых расчетов государственного комитета по планированию СССР. Как известно, подобные Бальцеровичу идеологи рыночных отношений критиковали хозяйство Народной Польши за чрезмерную централизацию, которую считали еще более присущей советской хозяйственной практике. Но действительная ситуация с информацией на уровне обобществления, то есть специальной функции коллективных баз данных, была в СССР не только очень отлична от представления идеологов, а прямо противоположна ему. На уровне моделей данных и информационной доступности обобществление хозяйственной информации в СССР удовлетворялось иерархическими базами данных, которые на длительном объеме применения противоположны тенденциям демократизации, экономии труда программистов, одного информационного эталона, понятности, информационной централизации и т.п. Интересно, что эффективные способы реализации реляционной модели данных вообще не интересовали и не интересуют работников плановых органов, если искать хоть какие-то ссылки в воспоминаниях или в документах плановых органов Латвии и Литвы. Только Виктор Глушков в своей последней книге отмечает перспективность реляционной модели данных с точки зрения обобществления информации и демократизации его безбумажного способа. Но к тому времени Глушков уже не был очень влиятельным в политическом смысле.

Насколько вообще правомерно рассмотрение общественного смысла категории модели данных? Существует взгляд, будто этот смысл случайный, и модель данных как главная категория даталогии может выражать только движение технических средств. Но ведь технику всегда применяет какой-то человек, который как-то относится к собственности, и который попытается реализовать свои интересы через технику. Поэтому существуют физически возможные, но общественно заблокированные способы применения технических инструментов. Кибернетика, поскольку она неотрывно связана с безбумажным учетом и проблемой единого информационного пространства оказывается неприкрыто партийной наукой именно так, как политическая арифметика, психология или эстетика. Материалистическая линия заключается в том, чтобы максимально применять возможности техники для улучшения человеческой жизни широких масс, а также сделать дело научного применения кибернетики их собственным делом именно так, как всю их жизнь сделать воплощением лучших достижений мировой науки. Потому что известно, что некоторые общественные силы требуют ограничения учета медленными и ограниченными способами, поскольку полный учет и информационная централизация позволяют любому легко понять паразитическую ресурсную ситуацию и облегчает направление усилий по устранению паразитов. Отказ от информационной гласности и информационной централизации называется коммерческая тайна. Ее снос принципиально меняет научную ситуацию в даталогии и смысл категории «модель данных». В капиталистических условиях даталогия играет пассивную роль дисциплины или искусства по выражению существующих отношений через определенный перечень элементарных информационных операций в коллективной базе данных. Когда условия прибыльности будут снесены, встанет вопрос как строить модель данных таким образом, чтобы она способствовала своему пониманию все большим количеством людей, то есть обобществлению ресурсно-хозяйственной, в первую очередь, информации. То есть вместо вопроса «как выразить имеющееся», даталогия переориентируется на вопрос «что лучше всего можно предлагать для дела получения субъектности производственного большинства общества». В первом случае даталогия ограничивается состоянием отдельной технической дисциплины в составе информатики, во втором случае она строится как полноценная партийная наука на основе логики и теории познания современного материализма. В первом случае люди ограничивают возможности техники, во втором случае техника ограничивает творческие возможности людей.

Развитие моделей данных от линейных до иерархических, сеточных и реляционных соответствует не только общественным формам, но и формам безбумажной памяти. Поэтому категорию «модель данных» можно понять только в непрерывном преобразовании общественных и технических факторов осуществления элементарных операций над информацией в безбумажном виде.

Как известно в Советском Союзе реляционная модель данных никогда не стала фактором облегчения обобществления хозяйственной информации. Поэтому мы не можем исследовать в архивах плановых органов советских стран какие именно отношения порождает вокруг себя реляционная коллективная база данных. Попробуем это понять.

Иерархическая модель данных и ее типичные системы управления базами данных позволяют сделать соседние ветви подобными или копировать их. Но поддерживать тождественность форматов разных ветвей в программах, которые упомянуты, трудно. Они вообще не считают одноформатность свойством. Поэтому, например, ветвление шаблонизируемой ветви «РРФСР» в БД АСПР ГП СССР под другими названиями не позволяет гарантировать, что через некоторое время способы получения какой-то суммы по областям РРФСР и УССР останутся тождественными. Изменение форматов разных ветвей не является синхронным, разница накапливается на основе «административных указаний и важных технических исключений». Поэтому, когда надо как-то сравнивать транспортный дебет Крыма, программы для обращения за данными учета Херсонской области и Краснодарского края со временем останутся разными. Более того, в каждом случае надо знать полный адрес данных, которые надо сравнивать. Речь идет о том, что нельзя узнать какие-то коды, выписать их и проверить взаимный транспортный дебет воеводств или еще каких-то административных единиц. Надо знать полный адрес транспортных данных Херсонской области, которая может, по историческим факторам, иметь другой принцип формирования, чем для Краснодарского края. Потому что это во-первых край, а не область, а во-вторых это Россия, а не Украина. В отличие от народного восприятия, администраторы в СССР всегда это резко различали. И, разумеется, это обвинение иерархической модели данных в поддержании сепаратизма. Не то, чтобы это был очень влиятельный фактор, но это был очередной фактор из многих, которых можно было избежать.

Реляционная модель данных не оставляет ничего от «тайных знаний» отдельных программистов, которые только и знают как какая ветвь построена. В основу построения реляционных или отношений таблиц Эдгар Кодд положил принцип типизации, который в теоретическом смысле продолжает принцип стандартизации в промышленности. Речь идет о том, что объявляется некая «сущность», которая имеет перечень «свойств», имеющих «возможные значения» или, как пишут математики, «домены нужного типа». Так, воеводство имеет метрическую площадь, название столицы на местном языке, отдельный статус, воеводу и тому подобное. В Советском Союзе административные единицы были очень разнообразны, но они имели тоже очень похожие свойства. Метрическая площадь это в любом случае число, название столицы это всегда строка, время основания всегда дата, отдельный статус всегда код из какого-то перечня. Кодд предложил из названных «доменов», то есть элементарных типов любые содержательные структуры, которые имеют универсальность, ограниченную только условиями проекта, а не техническим применением, как в иерархических базах данных с различными ветвями. То есть, относительная модель данных, которую предложил Кодд позволяет делать неограниченную информационную централизацию через информационную стандартизацию. В иерархических базах данных это все отдавалось на откуп аккуратности, сообразительности и внимательности людей. В реляционных базах данных эти функции возложены на машину.

Что касается универсализации и централизации, которые легко реализуются в реляционной модели данных, то они касаются не только технологического учета, но и языков. В позднем СССР по мере возрастания роли «рыночной регуляции» (на самом деле хаотизации) хозяйственной жизни также ежегодно поднимали голову различные националистические течения. Языкоцентрические аргументы были для населения советских стран каждый год более убедительны. Интересно наблюдать по документам, что в языковом смысле автоматизированные процедуры планирования почти никак не регулировались. В некоторых иерархических базах данных в СССР система названий ветвей строилась на английском языке, потому что «все равно это не публичный документ» и считалось, что она будет иметь смысл только для программистов, которые заимствовали структуры данных из англоязычных книг. Подобного аристократизма и желания сделать еще одну «прослойку перевода смысла» не было даже в Соединенных Штатах, где английский язык в то время был преобладающим естественным языком большинства населения. Была и противоположная ситуация, когда ветки данных по разным республикам назывались кирилизацией или латинизацией какого-то языка. Были и попытки полного обрусения системы именования объектов в базах данных. Но попытки сохранять переводы надписей в базе данных и междугородней машинной связи терминалов с выводом на разных языках тоже произошли уже не в СССР. Лишь через несколько лет после дезорганизации советского общества была выдвинута идея применять в структурировании реляционных баз данных промежуточный упрощенный плановый язык, не дающий преимущества ни одной нации. Программная поддержка названий объектов реляционных баз данных на языке эсперанто появилась лишь 10-15 лет назад.

Какое разделение труда порождает возле себя реляционная база данных? С первого взгляда кажется, что оно очень похоже на профессиональную систему. То есть врач усваивает какую-то группу таблиц и их связи, которые касаются врачебного дела, другую группу таблиц всеобщей автоматизированной системы усваивает промышленный конструктор. Всеобщая связь в реляционных базах данных выражается через концепцию идеальных представителей или внешних ключей. В иерархических базах данных нет близкого аналога этой концепции. Так, транспортный дебет Крыма в БД АСПР вычисляется на основе знания построения ветвей соседнего края и области. Реляционная БД позволяет создать общесоветскую таблицу регионов и таблицу связей, где коды регионов можно писать двойками. К этим связям регионов можно добавлять показатели разного времени и даже ссылаться на давальцы-счетчики на железных дорогах, как предлагал Глушков. Эта идея полной информационной централизации позволяет раскрыть широкие возможности местного самоуправления на основе правильного понимания своих отношений с другими. Таким образом реляционные базы данных при усилении обобществления и демократизации работают против административной централизации, оставляя центру только общую балансировку и инициирование общезначимых крупных хозяйственных планов. Это как раз позволит внедрить повсеместно научную регуляцию распределения ресурсов и уменьшить роль рыночных отношений путем согласованного наступления на них как через местные сообщества, так и через общую центральную балансировку.

Не являются ли группы таблиц в реляционных базах данных подобными «домикам профессионального кретинизма», которые хорошо известны всем нам? К сожалению, мы не можем опровергнуть этот тезис какими-то эмпирическими примерами, потому что противоположные способы развития дидактического значения баз данных еще не очень выразительны. Можно говорить, что именно педагогически-демократическая сторона баз данных сейчас почти не имеет какого-то систематического развития, поскольку условия товарного хозяйства заставляют ориентироваться на прибыль, а не потребительские свойства любого изделия, в том числе и баз данных. Но, если сравнивать реляционные базы данных с иерархическими, можно заметить, что их понимание становится намного проще. Сейчас понимание структур баз данных очень широко распространено между людьми, которые не имеют никаких навыков по программированию и нередко даже не представляют общие принципы программирования. В Польше изучение баз данных предусматривается многими программами на этапе между основной школой (szkołą podstawową) и высшими заведениями для тех, кому знания по вычислительной технике не оговариваются требованиями официальных специалистов в учебных заведениях. Надежду на продолжение этой тенденции (хотя и медленное) дает также развитие средств хранения информации. Прежде всего, переход от линейных накопителей к иерархическим базам данных привел сразу к уменьшению роли программирования и появлению отдельных программ — систем управления базами данных, что было выразительным шагом в направлении обобществления и уменьшения значения ремесленнического программирования. В отношении программирования это было опромысливанием производства программ для обобществления. Очень похожей революцией было развитие реляционных или реляционных баз данных на твердых дисках с механическими двигателями и концепцией цилиндров/секторов/головок. Эта концепция была гораздо менее технически ограниченной и гораздо более понятной для не программистов, чем концепция линейных перфолент или других линейных носителей. Их смена на твердые диски была отмечена увеличением количества относительно оперативно доступной информации. Следующая революция устройств хранения происходит на наших глазах, когда механические твердые диски заменяются быстрыми энергонезависимыми устройствами хранения на основе интегральных схем. Тут количество «внешней» для процессора доступной информации равняется емкости устройств хранения, а скорость доступа к внешней информации достигает скорости устройств оперативного хранения. Это означает, что равная и очень высокая скорость доступа касается всего массива информации, который подчиняется программам управления базой данных. За собой это влечет рост значения понимания содержания базы данных в противовес особенностям ее хранения или навыков формального манипулирования. Это предпосылки быстрого обобществления и широкой демократизации. Создание широких шпионских баз данных позволяет увидеть, что капиталистическое развитие этих тенденций уже меняет жизнь широких народных масс многих стран. Вместе с тем, подобные же тенденции позволяют вновь поставить вопрос о развитии даталогии как кибернетической дисциплины о создании баз данных, которые наилучшим образом способствуют обобществлению информации и демократизации знаний по безбумажному учету и контролю. Но это имеет своей политической предпосылкой сознательное движение в сторону нетоварности. Таким образом, возрождение даталогии можно неразрывно связать только с политическим режимом, который поставит себе целью снос товарного давления на все сферы общественной жизни.