Мысли о взаимодействии общественных отношений и моделей данных в базах данных (2024)
(размышления над некоторыми идеями Виктора Глушкова)
Миколай Загорский (Mikołaj Zagorski). Перевод с украинского. Оригинальный текст.
Это вторая версия статьи, ссылка на первую версию (2017).
Тем, кто читал хотя бы некоторые популяризации идей Глушкова, должно быть известно, что на вопрос, какие именно общественные формы предполагает ОГАС, он отвечал, что этот технологический проект никак не ограничивает общественные формы, внутри которых разворачивается автоматизированный вычислительно-учетный труд за исключением обязательного отсутствия коммерческой тайны. Контекст всех ответов Глушкова на подобные вопросы позволяет также установить, что речь идет не о любых общественных формах, но именно о формах того общества, которое преодолевает товарность всех хозяйственных отношений, которое имеет целью не прибыльность и быстрое обращение денег, а нечто более сложное, то что можно обозначить как экономическую эффективность в смысле, производном от Аристотеля. То есть, по Глушкову, в любом случае речь идет об общественных формах того, что называется в общественной науке диктатурой пролетариата. Опытный исследователь общественных явлений должен знать, что на самом деле выразительного безразличия к общественным формам не имеет ни одно утверждение об общественной жизни. Но Глушков почему-то несколько раз в разговоре с Моевым как бы создает подобную иллюзию. Трудно сомневаться, что это была своеобразная игра с профессиональной ограниченностью собеседников.
На самом деле заниматься исследованиями того, каким именно общественным формам способствует осуществление ОГАС, Глушков не стал по нескольким причинам. Прежде всего, это политическая неопределенность судьбы ОГАС. Во-вторых, это достаточно быстрое развитие технических средств учета и вычислений. В-третьих, это практичность Глушкова и его неуважение к созерцательным настроениям в обществе. Сегодня существует версия, что Глушков говорил о различных общественных формах, связанных с ОГАС, потому, что не хотел выглядеть как сторонник «чрезмерного демократизма» для фракции своих оппонентов в КПСС. На самом деле это очень современная идеологизация, идеологические основания которой едва достигают 1991 г. Во-первых, Глушков, как почти любой другой рядовой советский научный работник, никогда не скрывал приверженности к самоуправлению. Во-вторых, он имел много единомышленников среди других высокопоставленных чиновников не только в ЦК КП Украины, но и на уровне высших органов КПСС. В-третьих, отдельные необходимые технические характеристики вычислительной техники 1970-х гг склоняют скорее к тому, что «самоуправление» и «демократизм» для способа применения системы подобных вычислительных средств — это очень и очень внешние характеристики. Нечто подобное доказывает и общественно-техническая история Киберсина — проекта общегосударственной автоматизации в Чили во времена Альенде. Интересно то, что в работах Бира можно найти критику подходов, которые были положены в основу ОГАС и наоборот, Глушков делает критику некоторых оснований «Киберсина». Со стороны Бира речь идет преимущественно об иерархическом построении информационных моделей и распределении руководящих сигналов. Правда, такое построение некоторых узлов ОГАС (насколько о нем вообще можно говорить, поскольку многие документы были уничтожены) обусловливалось не только неудачными принципами советского администрирования, но и распространенностью иерархических баз данных в применении в сфере автоматизации учета. Со стороны Глушкова критика принципов, которые были положены в основу «Киберсин» касалась больше телеграфной сети, которую советский кибернетик считал принципиально недостаточной. Поэтому в Институте Кибернетики были начаты работы по разработке средств информационного обмена через различные линии связи. Но что касается Чили, вряд ли здесь была практическая альтернатива, потому что масштабы промышленности Народной Польши или Советского Союза и Чили принципиально разные по количеству изделий и связей между предприятиями.
Чтобы подтвердить или проверить выводы о влиянии господства иерархических баз данных на перспективы обобществления информации в 1970-х гг., надо разобраться с техническими качествами программных средств, упомянутых в одном из вариантов проекта ОГАС, который был подготовлен позднее 1975 г. Эти программные средства общеизвестны: язык программирования ПЛ/1, системы управления базами данных (СУБД) «ОКА» и СИОД-3-ОС. Вряд ли будет полезно обсуждать в связи с обозначенными проблемами язык программирования ПЛ/1, поскольку языки программирования вообще имеют в обществе только частичное значение, тогда как именно СУБД являются специальными программами, осуществляющими функцию совместной работы с данными, т.е. их обобществления. Сейчас очень трудно искать справки о программных инструментах Единой Серии Электронно-Вычислительных Машин (ЕС ЭВМ, pol. System Jednolity) 1970-х гг., но упоминаний в мемуарах достаточно, чтобы понять, что СИОД — это сокращение от «система интеграции и обработки данных». Некоторые выводы относительно общественных форм, которые могла породить ОГАС хотя бы вокруг себя, таким образом, можно сделать из исследования потребительских качеств СУБД ОКА, ДИСОД и СИОД-3-ОС, которые обычно упоминаются в других, чем проекты ОГАС, источниках рядом.
В этом нам поможет русскоязычный источник — статья 1988 г. «Программное обеспечение банков данных (прагматический подход)»[1]. Эта статья кажется слишком поздней, но может иметь отношение к нашему исследованию, так как изображает тенденции последних лет жизни Глушкова, которые к тому времени уже были полностью развиты.
Авторы статьи, которую мы упомянули, обнародовали очень интересную таблицу, изображающую состояние развития СУБД в СССР конца 1980-х гг.
| № | Название (рус.) | Консультации по СУБД | Есть в фонде ПО[2] | Модель данных | Архит. ЭВМ |
|---|---|---|---|---|---|
| 1 | ОКА | П | + | І | ЄС |
| 2 | ИНЕС | П | + | І | ЄС |
| 3 | БАНК-ОС | П | + | М | ЄС |
| 4 | СЕТОР-3.0 | П | + | М | ЄС |
| 5 | СИОД-3-ОС | П | + | М | ЄС |
| 6 | АИСТ-Развитие | П | + | Ф | ЄС |
| 7 | ПАРМА | Е | + | М | ЄС |
| 8 | РЕБД | Е | + | Р | ЄС |
| 9 | ВЕРА | Е | Р | ЄС | |
| 10 | БАЙКАЛ | Е | М | ЄС | |
| 11 | УНИСОН | Е | Р | ЄС | |
| 12 | ДАБУ | Е | + | Р | ЄС |
| 13 | КВАНТ | Е | + | Ф | ЄС |
| 14 | ДИСОД | П | + | Ф | ЄС |
| 15 | СЕТЬ | П | М | ЄС | |
| 16 | РИС | Е | Р | ЄС | |
| 17 | ПАЛЬМА | Е | + | Р | ЄС |
| 18 | СПЕКТР | Е | + | Ф | ЄС |
| 19 | ЕНФ | Е | + | Р | ЄС |
| 20 | СЕТОР-СМ | П | + | М | СМ |
| 21 | МИРИС | П | + | Ф | СМ |
| 22 | КВАНТ-М | Е | Ф | СМ | |
| 23 | БАРС | Е | + | Р | СМ |
| 24 | БАЗА-CM | П | + | С | СМ |
| 25 | БАЗИС | Е | + | Р | СМ |
| 26 | МИКРОСЕТОР | П | + | М | Мікр |
| 27 | КАРС | П | + | Р | ЄС |
Модели данных:
- И — иерархическая
- М — сетевая
- Р — реляционная
- Ф — файловая
- С — сущность-связь
Консультации по СУБД:
- П — промышленная группа
- Е — экспериментальная группа
14 из 27 СУБД, которые упомянуты были экспериментальными, т.е. организации, которые занимались их разработкой не имели отдельных консультационно-настроечных отделов. 6 СУБД еще не были настолько готовы, чтобы была изготовлена относительно стабильная документация, которую требовали в случае «фондирования», т.е. отправки в фонд ПО. СУБД «СЕТОР» имела реализации тремя архитектурами. Понятно, что от советских авторов нельзя требовать чтобы они вспомнили состояние дел в Народной Польше или Демократической Германии, но польская СУБД РОДАН (pol. RODAN) сетевой модели данных была более передовой, чем ОКА по своим математическим принципам и одной из первых получила модуль диалога на языке, подобном SQL и еще «понимала» язык согласно рекомендациям консорциума CODASYL так же как ОКА или СЕТОР или СИОД-3-ОС.
Относительно перспектив обобществления хозяйственной информации, мы должны вычеркнуть файловые СУБД, потому что они не позволяют эффективно делать коллективный учет чего-либо. Потому что блокировка на файловом уровне в больших коллективах увеличивает время ожидания записи и плохо влияет на чтение. Таким образом различные СУБД, более-менее пригодные для обобществления выглядят так:
| № | Название (рус.) | Консультации по СУБД | Есть в фонде ПО | Модель данных | Архит. ЭВМ |
|---|---|---|---|---|---|
| 1 | ОКА | П | + | І | ЄС |
| 2 | ИНЕС | П | + | І | ЄС |
| 3 | БАНК-ОС | П | + | М | ЄС |
| 4 | СЕТОР | П | + | М | ЄС\СМ\Мікро |
| 5 | СИОД-3-ОС | П | + | М | ЄС |
| 6 | ПАРМА | Е | + | М | ЄС |
| 7 | РЕБД | Е | + | Р | ЄС |
| 8 | ВЕРА | Е | Р | ЄС | |
| 9 | БАЙКАЛ | Е | М | ЄС | |
| 10 | УНИСОН | Е | Р | ЄС | |
| 11 | ДАБУ | Е | + | Р | ЄС |
| 12 | СЕТЬ | П | М | ЄС | |
| 13 | РИС | Е | Р | ЄС | |
| 14 | ПАЛЬМА | Е | + | Р | ЄС |
| 15 | ЕНФ | Е | + | Р | ЄС |
| 16 | БАРС | Е | + | Р | СМ |
| 17 | БАЗА-CM | П | + | С | СМ |
| 18 | БАЗИС | Е | + | Р | СМ |
| 19 | КАРС | П | + | Р | ЄС |
Промышленные СУБД в СССР, имевшие промышленные консультационно-настроечные группы, рассмотрены со стороны аналогичных языков запросов и моделей данных.
| № | Название (рус.) | Консультации по СУБД | Есть в фонде ПО | Модель данных | Архит. ЭВМ |
|---|---|---|---|---|---|
| 1 | ОКА | П | + | І | ЄС |
| 2 | ИНЕС | П | + | І | ЄС |
| 3 | БАНК-ОС | П | + | М | ЄС |
| 4 | СЕТОР | П | + | М | ЄС\СМ\Мікро |
| 5 | СИОД-3-ОС | П | + | М | ЄС |
| 6 | СЕТЬ | П | М | ЄС | |
| 7 | БАЗА-CM | П | + | С | СМ |
| 8 | КАРС | П | + | Р | ЄС |
На основе последней таблицы можно понять, что в СССР даже в середине и конце 1980-х гг. безусловно господствуют иерархически-сетевые СУБД, причем реляционной является только СУБД КАРС, которая даже в русскоязычной литературе упоминается редко, и на время смерти Глушкова еще не имела каких-то полнофункциональных развитых программных пакетов.
Когда сейчас речь идет об общественных факторах формирования иерархических БД, обычно говорят о том, что их понятие формируется как образ общественного понятия иерархии в технико-математической сфере программирования. Понятно, что способ связи данных (или «модели данных», как говорят специалисты) в иерархических базах данных является математическим выражением понятия иерархии. Но, вместе с тем, взаимодействие общественного и математического понятия иерархии этим не исчерпывается. Потому что большие иерархические базы данных как форма обобществления информации формируют вокруг себя специфические общественные отношения, которые каким-то образом соотносятся с отношениями окружающего общества. То есть мы имеем критерий, позволяющий проверять отношения вокруг формирования и функционирования базы данных на то, способствуют ли они прогрессивному или реакционному развитию общества.
Следует уже сначала абстрагироваться от способа размещения данных на машинных носителях в 1975-1985 годах. Поскольку он менялся в прогрессивном направлении и занимал ежегодно меньше труда специалистов, это не был фактор, влияние которого надо считать решающим. Поэтому нужно уделить внимание главной категории даталогии — модели данных. Эта категория имеет именно такое значение как категория «бытия» для науки о мышлении или понятие «товар» для политической арифметики, или категория «безразличие» для эстетики или категория «безбумажность» для кибернетики. То есть, в любом случае мы имеем в основе нечто, что в некотором смысле противоположно главному направлению исследований. Ибо наука о мышлении не исследует бытие как таковое, политическая арифметика[3] не исследует товар, а только способы его перехода в противоположность, эстетика исследует безразличие не иначе как только в связи с ее превращением в противоположность, то есть во всеобщее небезразличие. Именно таким образом кибернетика является критикой бумажных форм учета и соответствующих способов общественного и технического управления. Подобным образом даталогия, то есть наука о данных, начинается с того, что ее основание составляет некоторая модель данных, которая обусловливает все рекомендации по выражению предметного содержания в технических формах любых баз данных. То есть надо разобраться с тем, что такое модель данных.
Модель данных можно упрощенно объяснить как перечень содержательных действий над носителями информации. Например, бумажная карточка учета книги в каталоге библиотеки позволяет осуществлять заполнение в случае добавления книги в фонд, изредка усовершенствование надписей, переход к шкафу с книгами, проверку надписей с помощью реальной книги, о которой идет речь, обращение в авторский, тематический, общий каталог. Может показаться, что подобных операций очень много, но на самом деле существует несколько математических моделей, которые позволяют выразить формальный смысл любых операций учета и проверки. Иерархическая модель, которая положена в основу СУБД ОКА, в наше время не исчезла, а нашла прочную реализацию в принципах файловой системы. Ее условно изолированный фрагмент сейчас может имитировать поведение СУБД ОКА с не очень значительными изменениями. Типичные операции файловой системы в операционных системах Линукс полностью соответствуют главным элементарным функциям СУБД ОКА: создать и удалить каталог, создать и удалить файл, записать и прочитать его содержимое, совершить переход по каталогам (mkdir, rmdir, echo > plik.txt, cat, rm, cd). Очень похожей была и проверка прав доступа, которая, кстати, не имеет значительного влияния на способ общественного применения базы данных. Что было оригинальным, так это типизация узлов. То есть было обозначено, что некий адрес занимает целое число, другой — символьный ряд в кодировке ДКОИ[4], какой-то — десятичную запись рационального числа, какой-то — что-то еще.
Другой подход, который не имеет системы узлов, но имеет типичные ранее известные структуры, называется реляционным, но соответствующий математический объект на украинском языке называется «стосунок». Интересно, что в технике применяется полонизм «реляционный», который в польском языке является германизмом, а в немецком языке является латинизмом из математических трактатов. На русском языке соответствующий объект называется «отношение», но в технике применяется англицизм «реляционный», который в английском языке является латинизмом из математических трактатов. На белорусском языке соответствующая математическая литература отсутствует, терминология не вырабатывалась.
Математическая запись отношения:
| A1(D1(T1)) | A2(D2(T2)) | A3(D3(T3)) | ... | |
|---|---|---|---|---|
| C1 | V11∈ D1 | V21∈ D2 | V31∈ D3 | ... |
| C2 | V12∈ D1 | V22∈ D2 | V32∈ D3 | ... |
| C3 | V13∈ D1 | V23∈ D2 | V33∈ D3 | ... |
| ... | ... | ... | ... | ... |
Где ограниченный (M×N) математический объект имеет следующие составляющие:
- A1..N — атрибуты или свойства или реляционные столбцы
- C1..M — кортежи или записи или реляционные строки
- V[1..N, 1..M] — значения
- D1..N — домены или реляционные диапазоны значений
- T1..N — типы значений
Пример реализаций математического объекта в базе данных
| Kodo / Код A1 (3 символа(символ)) | Nomo / Название A2 (до 64 символов(строка)) | Centro administra / Центр администрации A3(до 64 символов (строка)) | ... | |
|---|---|---|---|---|
| C1 | bel | Беларусь | Мінск | ... |
| C2 | ukr | Україна | Київ | ... |
| C3 | pol | Polska | Warszawa | ... |
| C4 | ros | Россия | Москва | ... |
| C5 | deu | Deutschland | Berlin | ... |
| ... | ... | ... | ... | ... |
Внимательный читатель из того, что почти каждая цифровая машина имеет файловую систему, может вывести то, что критика иерархической модели данных будет очень искусственной. Но речь идет не об организации функционирования отдельной машины, а об обобществлении. Автоматизированная система плановых расчетов государственного комитета по планированию (АСПР ГП СССР) была прежде всего средством обобществления хотя бы в стенах этого учреждения. Поэтому наша оценка должна касаться именно этих функций в первую очередь. Здесь можно увидеть что БД АСПР ГП СССР была очень похожа на любой крупный современный файловый сервер, разве что «файлы» (узлы СУБД ОКА) были небольшими и типизированными. Иерархическая организация обобществления оказалась неконкурентоспособной для долгосрочного функционирования более или менее крупных организаций. До сих пор она остается либо у мелких фирм, либо на этапе формирования реляционных (отношенческих[5]) баз данных. Почему так получается? Надо представить, что какую-то файловую систему с тысячами каталогов и несколькими десятками тысяч файлов попытается использовать какая-то организация. Очевидно, что человек не может помнить что и где там хранится, в каком случае и что именно добавляется к каждому из каталогов. Таким образом начинают работать ответственные за ветку БД, которые знают свою ветку иерархической БД, но плохо разбираются в соседних. Со временем им становится нужен как бы координатор, который фактически руководит способами добавления информации. Во избежание излишнего дублирования информации впоследствии выдаются директивы о том, где искать эталонные формы некоторых первичных справок. Подобных директив становится все больше и даже деспотическое вмешательство руководителей не решает проблемы, потому что обработке подлежит все больше данных. Иерархическая большая база данных как способ обобществления данных выстраивает вокруг себя ... иерархию. Это обычная история американских коммерческих фирм, которые почти все забросили иерархические базы данных еще до кризиса 1998 года. Но, вот ирония истории, Госплан СССР, который испытывал трудности из-за того, что иерархические отношения более не позволяют увеличивать экономическую эффективность, попытался решить эти проблемы созданием иерархической базы данных, которая выстраивала вокруг себя ... иерархию. То есть, поскольку Госплан СССР имел отделы и ответственных за ветки БД, СУБД ОКА мешала даже информационному единству внутри учреждения. Потому что куча частных дел не является коллективным делом, хотя противоположный тезис верен.
Какая была альтернатива в то время? Специалисты того времени в воспоминаниях рядом с СУБД ОКА упоминают СУБД ДИСОД. Это была уже система управления сетевой базой данных. То есть надо разобраться с общественными качествами сетевых баз данных[6].
Математическое выражение иерархических баз данных называется ориентированным графом, где каждый узел должен принимать только одну связь (от высшего) и отдавать сколько угодно связей низшим. Сетевая база данных выражается подобной математической структурой, которая отличается только тем, что узел может быть закреплен сразу на нескольких ветвях. В общественном и административном смысле это означает, что можно избежать дублирования данных, если они касаются чего-то одного. То есть данные из материалов для строительства школ можно сразу добавить в узлы планирования для министерства народного образования Советской Литвы и министерства строительства этого советского государства. Поэтому редактирование через один адрес автоматически изменяет то, что доступно через другие эквивалентные, потому что все адреса ссылаются только на одну структуру данных. Трудно не заметить, что это внешнее объединение, осуществление которого возложено на сообразительных техников или господ-плановиков. «Если кто-то заметит, что есть дублирование...» — это выражение характерно для позднесоветского формализма и неуверенности. Никаких формальных способов противостояния дублированию здесь нет, работникам по планированию ничего не помогает его избегать, между ответственными за разные ветви так же существует «координатор», который имеет тенденцию превращаться в господина.
Если иерархические базы данных как способ обобществления порождают вокруг себя иерархию (а это не совсем очевидная связь), нельзя говорить, что сетевые базы данных порождают нечто принципиально иное, например, так называемые сетевые способы организации. Эта аналогия будет уже неуместной.
В современности даталогическая фракция в отношении общегосударственной автоматизации обычно связывается с реляционной моделью данных. Это может показаться естественным, но исторически такая ассоциация имеет более математические, чем технические предпосылки. Интересно, что все проекты ОГАС содержали ссылки на иерархические базы данных, в частности на СУБД ОКА. Даже тот проект 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 году[7] Глушков посвящает этой проблематике отдельную шестую главу «Основ безбумажной информатики». В начале он пишет: «Ведь начиная с 1960-х годов и в частности в 1970-е годы главная масса применений ЭВМ получила другое, так называемое системное направление». Далее Глушков раскрывает читателю базу данных как инструмент экономии труда по оцифровке, отделения выполнения вычислительных задач от актуализации информации, намекая также на тенденцию к обобществлению информации. Для каждой сферы такой информационной автоматизации Глушков постулирует существование информационной модели как системы данных об объекте. Таким образом, уже первые два абзаца позволяют читателю понять технические предпосылки проблематики обобществления информации. Впоследствии Глушков отрицает такой подход, когда под каждую задачу существуют отдельные системы информации как технически отсталый и не позволяющий экономить время и труд из-за одноразовой оцифровки. Еще в 1970 году Глушков выдвигал идею «программно-технического комплекса», суть которой заключалась в том, чтобы не делать управляющие машины и программы под отдельные задачи, а делать машины и программное обеспечение для целых классов подобных задач с последующей специализацией под конкретную задачу. Сейчас несколько трудно понять, включала ли в себя эта идея и идею БД, но это было бы вполне логично. Кстати, тогда Глушков был уверен, что в капиталистическом мире ничего подобного программно-техническим комплексам нет, потому что в США типичной была аренда вычислительного времени различными организациями под разные нужды в вычислительном центре. Именно поэтому повторное использование (совпадение) каких-то исходных или производных массивов информации было почти невозможным, поскольку аренда подчиняется рыночному хаосу и коммерческой тайне.
Уже эти три абзаца из «Основ безбумажной информатики», в которых Глушков раскрывает проблематику баз данных, оказываются очень важными для оценки научных перспектив кибернетики. Они позволяют понять, возможно ли построить кибернетику как сферу применения диалектической логики, как так называемую «прикладную логику» именно так, как случилось с политической арифметикой у Маркса, психологией у Выготского, эстетикой у Канарского. Ответ Глушкова на этот вопрос, без сомнения, положительный. Но ему уже было некогда выполнять эту программу как в физиологическом так и в политическом смысле. Подобно всем упомянутым наукам, кибернетика оказывается партийной и классовой, в центре проблематики баз данных оказывается объект-субъектное отношение человека с машиной и конфликт общественных сил, заинтересованных в принципиально разном применении баз данных. Это в точности повторяет ситуацию, которую можно увидеть в сфере политической экономии.
Таким образом, вход проблематики обобществления информации в информатику Глушков датирует началом 1970-х годов. Это совпадает с развитием СУБД ОКА в СССР, СУБД ИМС в Соединенных Штатах а также с популяризацией стандартов CODASYL.
Отличие баз данных и банков данных, которое можно увидеть в литературе где-то до 1990-х годов исходит из того, что база данных рассматривается как состояние устройств хранения, то есть как информация, которая хранится. Напротив, банк данных — это, вдобавок к хранящейся информации, ещё и программы, которые вместе с базой данных выполняют функцию по обобществлению информации. Эта разница между базой данных и банком данных вообще объясняется тем, что в иерархических базах данных содержательные запросы формируются очень трудно и требуют многочисленных консультаций программистов и труда по программированию. Например, сравнение расхода строительных материалов в школах Татарстана и Волыни в АСПР ГП СССР требовало взаимодействия, как минимум, трех специалистов. Первый знал, в каком формате ведет эти данные Госплан УССР и мог написать иерархические адреса, где можно эти данные получить. Второй знал то же самое о Татарстане, где формат этих данных был немного другим. Еще один человек, получив «эмпирическую полноту» от первых, пишет программу переработки в вид, пригодный для сравнения. Эти три человека, помогавшие реализовать содержательный запрос и их программы, составляют банк данных. Реляционная модель данных предусматривает другой механизм: без помощи программистов любой работник плановых органов или народной инспекции может найти коды нужных школ в таблице «Школы», найти все упоминания этих кодов в таблице «Строительные расходы» и объединить результат так, что подобные расходы («дерево на двери», «металл для мебели», «металл на двери») можно будет сравнить в таблице сравнения. Реляционная модель построения баз данных позволяет предотвратить значительные потери труда программистов. Более того, современные реляционные базы данных позволяют хранить внутри себя отдельные процедуры на языках программирования. Правда в каждой базе данных эти языки разные: в SQLite это SQL (в триггерах), в Firebird это свой язык, в Oracle это Java и внутренний язык, в PostgreSQL это сразу несколько языков на выбор. Таким образом, современные базы данных получают все функции банков данных и частично превращаются в среды программирования, если его целью является обобществление информации. Это означает, что в современных базах данных эта проблематика концентрируется гораздо более отчетливо, чем во времена Глушкова.
Главная общественная разница реляционной и иерархической модели данных заключается почти в том же, в чем заключается формальная разница феодальной и капиталистической общественных форм экономической общественной формации. Феодализм лишь на поздней стадии подвергается хотя бы сколько-нибудь отчетливой национальной универсализации, как формирование единой метрологической системы или литературного языка. К тому времени господствует распределение правил и законов, различающихся в тождественных сферах между соседними территориями. Если заменить «территории» на «ветви базы данных», можно будет получить рисунок структур данных в базе данных Автоматизированной системы плановых расчетов государственного комитета по планированию СССР. Как известно, подобные Бальцеровичу идеологи рыночных отношений критиковали хозяйство Народной Польши за чрезмерную централизацию, которую считали еще более присущей советской хозяйственной практике. Но действительная ситуация с информацией на уровне обобществления, то есть специальной функции коллективных баз данных, была в СССР не только очень отличной от представления идеологов, а прямо противоположной ему. На уровне моделей данных и информационной доступности обобществление хозяйственной информации в СССР удовлетворялось иерархическими базами данных, которые в долгосрочном продолжении тенденций своего развития были противоположны тенденциям демократизации, экономии труда программистов, единого информационного эталона, понятности, информационной централизации и т.п. Интересно, что эффективные способы реализации реляционной модели данных вообще не интересовали и не интересуют работников плановых органов, если искать хоть какие-то упоминания в воспоминаниях или в документах плановых органов Латвии и Литвы. Только Виктор Глушков в своей последней книге отмечает перспективность реляционной модели данных с точки зрения обобществления информации и демократизации его безбумажной формы. Но к тому времени Глушков уже не был очень влиятельным в политическом смысле.
Насколько вообще рационально рассмотрение общественного смысла категории модели данных? Существует взгляд, будто этот смысл случайный, и модель данных как главная категория даталогии может выражать только движение технических средств. Но ведь технику всегда применяет какой-то человек, который принимает то или иное участие в отношениях собственности, и который пытается реализовать свои интересы через технику. Поэтому существуют физически возможные, но общественно заблокированные способы применения технических инструментов. Кибернетика, поскольку она неразрывно связана с безбумажным учетом и проблемой единого информационного пространства, оказывается неприкрыто партийной наукой так же, как политическая экономия, психология или эстетика. Материалистическая линия заключается в том, чтобы максимально применять возможности техники для улучшения человеческой жизни широких масс, а также сделать дело научного применения кибернетики их делом, так же, как всю их жизнь - воплощением лучших достижений мировой науки. Потому что известно, что некоторые общественные силы требуют ограничения учета медленными и ограниченными способами, поскольку полный учет и информационная централизация позволяют любому легко понять паразитическую ресурсную ситуацию и облегчает направление усилий по устранению паразитов. Это называется коммерческая тайна. Ее отмена принципиально меняет научную ситуацию в даталогии и смысл категории «модель данных». В капиталистических условиях даталогия играет пассивную роль дисциплины или искусства по выражению имеющихся отношений через определенный перечень элементарных информационных операций в коллективной базе данных. Когда условия прибыльности будут преодолены, встанет вопрос: как строить модель данных таким образом, чтобы она способствовала своему пониманию всё большим количеством людей, то есть обобществлению ресурсно-хозяйственной, в первую очередь, информации. Противоположности превращаются друг в друга: вместо вопроса «как выразить имеющееся» даталогия переориентируется на вопрос, «что лучше всего можно предлагать для дела получения субъектности производственным большинством общества». В первом случае даталогия ограничивается до состояния отдельной технической дисциплины в составе информатики, во втором случае она строится как полноценная партийная наука на основе логики и теории познания современного материализма. В первом случае люди ограничивают возможности техники, во втором случае техника расширяет творческие возможности людей.
Развитие моделей данных от линейных до иерархических, сетевых и реляционных соответствует не только общественным формам, но и формам безбумажной памяти. Поэтому категорию «модель данных» можно понять только в непрерывном преобразовании общественных и технических факторов осуществления элементарных операций с информацией в безбумажном виде.
Как известно, в Советском Союзе реляционная модель данных никогда не стала фактором облегчения обобществления хозяйственной информации. Поэтому мы не можем исследовать в архивах плановых органов советских стран, какие именно отношения порождает вокруг себя реляционная коллективная база данных. Попробуем это понять.
Иерархическая модель данных и ее типичные системы управления базами данных позволяют сделать соседние ветви подобными или копировать их. Но поддерживать тождественность форматов разных ветвей в программах, о которых упоминалось, трудно. Они вообще не считают одноформатность важной чертой, вокруг которой концентрируется много автоматизированных функций. Поэтому, например, разветвление шаблонизированной ветки «РСФСР» в БД АСПР ГП СССР под другими названиями не позволяет гарантировать, что через некоторое время способы получения какой-то суммы по областям РСФСР и УССР останутся тождественными. Изменение форматов разных веток не является синхронным, разница накапливается на основе «административных указаний и важных технических исключений». Поэтому, когда надо как-то сравнивать транспортный дебет Крыма, программы для обращения к данным учета Херсонской области и Краснодарского края со временем останутся разными. Более того, в каждом случае надо знать полный адрес данных, которые надо сравнивать. Речь идет о том, что нельзя узнать какие-то коды, выписать их и проверить взаимный транспортный дебет областей или еще каких-то административных единиц. Надо знать полный адрес транспортных данных Херсонской области, которая может, по историческим факторам, иметь другой принцип формирования, чем для Краснодарского края. Потому что это, во-первых, край, а не область, а во-вторых это Россия, а не Украина. В отличие от народного восприятия, администраторы в СССР всегда это резко различали. И, разумеется, это обвинение иерархической модели данных в поддержании сепаратизма. Не то, чтобы это был очень влиятельный фактор, но это был очередной фактор из многих, которых можно было избежать.
Реляционная модель данных не оставляет ничего от «тайных знаний» отдельных программистов, которые одни только и знают, каким образом какая ветвь построена. В основу построения реляционных таблиц («отношений» на математическом языке) Эдгар Кодд положил принцип типизации, который в теоретическом смысле продолжает принцип стандартизации в промышленности. Речь идет о том, что объявляется некая «сущность», которая имеет перечень «свойств», имеющих «возможные значения» или, как пишут математики, «домены нужного типа». Так, воеводство имеет метрическую площадь, название столицы на местном языке, отдельный статус, воеводу и тому подобное. В Советском Союзе административные единицы были очень разнообразны, но они тоже имели очень похожие свойства. Метрическая площадь — это в любом случае число, название столицы это всегда строка, время основания всегда дата, отдельный статус — всегда код из какого-то перечня. Кодд предложил из названных «доменов», то есть элементарных типов, строить любые содержательные структуры, которые имеют универсальность, ограниченную только условиями проекта, а не техническим применением, как в иерархических базах данных с различными ветвями. То есть реляционная модель данных, которую предложил Кодд, позволяет осуществлять неограниченную информационную централизацию через информационную стандартизацию. В иерархических базах данных универсализация и централизация данных возлагалась, почти исключительно, на аккуратность, сообразительность и внимательность людей. В реляционных базах данных, наоборот, эти функции почти исключительно вручены машине.
Что касается универсализации и централизации, которые легко реализуются в реляционной модели данных, то они касаются не только технологического учета, но и языкового вопроса. В позднем СССР по мере возрастания роли «рыночной регуляции» (на самом деле хаотизации) хозяйственной жизни также ежегодно поднимали голову различные националистические течения. Языкоцентрические аргументы были для населения советских стран каждый год более убедительны. Интересно наблюдать по документам, что в языковом смысле автоматизированные процедуры планирования почти никак не регулировались. В некоторых иерархических базах данных в СССР система названий ветвей строилась на английском языке, потому что «все равно это не публичный документ» и считалось, что она будет иметь смысл только для программистов, которые заимствовали структуры данных из англоязычных книг. Подобного аристократизма и желания сделать еще одну «прослойку перевода смысла» не было даже в Соединенных Штатах, где английский язык в то время был преобладающим естественным языком большинства населения. Была и противоположная ситуация, когда ветки данных по разным республикам именовались кириллизацией или латинизацией какого-то языка. Были и попытки полной русификации системы именования объектов в базах данных. Но попытки сохранять переводы надписей в базе данных и междугородней машинной связи терминалов с выводом на разных языках тоже произошли уже не в СССР. Лишь через несколько лет после дезорганизации советского общества была выдвинута идея применять в структуризации реляционных баз данных промежуточный упрощенный плановый язык, не дающий преимущества ни одной нации. Программная поддержка названий объектов реляционных баз данных на языке эсперанто появилась лишь 15-20 лет назад. Поэтому в Советском Союзе реляционные базы данных не стали инструментами в пользу хозяйственной и человеческой универсализации против языкоцентризма и ассимиляции. Трудно понять, надеялся ли хоть кто-то на подобную техническую помощь для продолжения ленинской национальной политики. Наиболее вероятным кажется, что нет. Что касается Глушкова, он, как можно увидеть из записи разговора с Моевым, больше надеялся на общественную демократизацию новых способов учета в ближайшем будущем и не отделял языковой вопрос в этом контексте. В противовес надеждам Глушкова на общественную демократизацию, сейчас произошла лишь техническая демократизация новых способов учета. В отношении главного, то есть обобществления ситуация стала гораздо менее развитой, претерпела отчетливый и безоговорочный откат.
Какое разделение труда порождает вокруг себя реляционная база данных? С первого взгляда кажется, что оно очень похоже на профессиональную систему. То есть врач осваивает какую-то группу таблиц и их связи, которые касаются врачебного дела, другую группу таблиц всеобщей автоматизированной системы осваивает промышленный конструктор. Всеобщая связь в реляционных базах данных выражается через концепцию идеальных представителей или внешних ключей. В иерархических базах данных нет близкого аналога этой концепции. Так, транспортный дебет Крыма в БД АСПР вычисляется на основе знания построения ветвей соседнего края и области. Реляционная БД позволяет создать общесоветскую таблицу регионов и таблицу связей, где коды регионов можно писать двойками. К этим связям регионов можно добавлять показатели разного времени и даже ссылаться на датчики-счетчики на железных дорогах, как предлагал Глушков. Эта идея полной информационной централизации позволяет раскрыть широкие возможности местного самоуправления на основе правильного понимания своих отношений с другими. Таким образом, реляционные базы данных при усилении обобществления и демократизации работают против административной централизации, оставляя центру только общую балансировку и инициирование общезначимых крупных хозяйственных планов. Это как раз позволит внедрить повсеместно научную регуляцию распределения ресурсов и уменьшить роль рыночных отношений путем согласованного наступления на них как через местные сообщества, так и через общую центральную балансировку.
Не подобны ли группы таблиц в реляционных базах данных «комнаткам профессионального кретинизма», которые хорошо известны всем нам? К сожалению, мы не можем опровергнуть этот тезис какими-то эмпирическими примерами, потому что противоположные способы развития дидактического значения баз данных еще не очень выразительны. Можно говорить, что именно педагогически-демократическая сторона баз данных сейчас почти не имеет какого-то систематического развития, поскольку условия товарного хозяйства заставляют ориентироваться на прибыль, а не на потребительские свойства любого изделия, в том числе и баз данных. Но, если сравнивать реляционные базы данных с иерархическими, можно заметить, что их понимание становится намного проще. Сейчас понимание структур баз данных очень широко распространено между людьми, которые не имеют никаких навыков по программированию и нередко даже не представляют общие принципы программирования. В Польше изучение баз данных предусматривается многими программами на этапе между основной школой (szkołą podstawową) и высшими заведениями для тех, кому знания по вычислительной технике не предусматриваются требованиями официальных специалистов в учебных заведениях. Надежду на продолжение этой тенденции (хотя и медленное) дает также развитие средств хранения информации. Прежде всего, переход от линейных накопителей к иерархическим базам данных привел сразу к уменьшению роли программирования и появлению отдельных программ — систем управления базами данных, что было выразительным шагом в направлении обобществления и уменьшения значения ремесленнического программирования. В отношении программирования это было технологизацией производства программ для обобществления. Очень похожей революцией было развитие реляционных баз данных на твердых дисках с механическими двигателями и концепцией цилиндров/секторов/головок. Эта концепция была гораздо менее технически ограниченной и гораздо более понятной для непрограммистов, чем концепция линейных перфолент или других линейных носителей. Смена линейных носителей на твердые диски была отмечена увеличением количества относительно оперативно доступной информации. Следующая революция устройств хранения происходит на наших глазах, когда механические твердые диски заменяются быстрыми энергонезависимыми устройствами хранения на основе интегральных схем. Тут количество «внешней» для процессора доступной информации равно емкости устройств хранения, а скорость доступа к внешней информации достигает скорости устройств оперативного хранения. Это означает, что равная и очень высокая скорость доступа касается всего массива информации, который подчиняется программам управления базой данных. Это влечет за собой рост значения понимания содержания базы данных в противовес особенностям ее хранения или навыкам формального манипулирования. Это сразу дает предпосылки быстрого обобществления и широкой демократизации. Создание широких шпионских баз данных позволяет увидеть, что капиталистическое развитие этих тенденций уже меняет жизнь широких народных масс многих стран. Вместе с тем, подобные же тенденции позволяют вновь поставить вопрос о развитии даталогии как кибернетической дисциплины о создании баз данных, которые наилучшим образом способствуют обобществлению информации и демократизации знаний по безбумажному учету и контролю. Но это имеет своей политической предпосылкой сознательное движение в сторону нетоварности. Таким образом, возрождение даталогии можно неразрывно связать только с политическим режимом, который поставит для себя целью преодоление товарного давления на все сферы общественной жизни.
Международный научно-практический журнал «Программные продукты и системы» (ISSN 0236-235X (P), ISSN 2311-2735 (E); 1988, №3, Наумов А.Н., Вендров А.М., Иванов В.К., Программное обеспечение банков данных (прагматический подход). ↩︎
В СССР существовала организация для центрального хранения образцов или дистрибутивов программного обеспечения. Более подробные справки, даже название соответствующей организации, найти еще не удалось. ↩︎
«Политическая арифметика» — так можно назвать результат критики политической экономии, от которой остается теория о балансировке и учете общественных ресурсов как инструмент экономии общественного времени и расширения человеческой самодеятельности. Таким образом категория Verkehr, используемая Марксом и Энгельсом в «Немецкой идеологии» подлежит непосредственному кибернетическому рассмотрению именно так, как этого требует немецкий смысл этой категории, который отсутствует в славянских языках. После этого рассмотрения можно будет понять общественные границы кибернетики в отношении превращения общества в бесклассовое. ↩︎
Система состояла из нескольких десятков кодов, она была основана на телеграфном кодировании и сходные буквы кириллицы и латиницы оставались тождественными, то есть не очень затратная азбучная сортировка была невозможна. Также система ДКОИ, которая господствовала в машинах ЕС была очень шовинистической - отсутствовали символы литовского, польского, белорусского, чешского, украинского алфавита. ↩︎
Математический объект. ↩︎
Некоторую информацию об этом можно найти здесь, рецензия. ↩︎
Поскольку Глушков умер 30 января 1982 года после тяжелой болезни, то этот раздел он писал не в том году, и, видимо, не в 1981 году, когда текст уже был изначально собран. ↩︎