Вернуться на главную страницу
Что не так с текстологией и как исправить ситуацию? Часть III. Ответы на вопросы товарищей
Пока что нельзя сказать, что очерки «Что не так с текстологией и как исправить ситуацию?» вызывали большой интерес и активный практический отклик. Среди тех, кто прислал какой-либо отклик наиболее частой реакцией было недоумение. «Люди практического склада» недоумевали, что очерки слишком уводят в сторону программирования, программисты недоумевали, что нет никаких сведений по работе схемы Фроша-Загорского-Радкевичюте с общепринятыми языками программирования. Текстологи недоумевали, что нет никакого разбора исторических критериев установления авторского текста для ленинских сочинений, а техники недоумевали, что полностью проигнорирована проблема настройки управляющей программы базы данных. Наконец, просто внимательные читатели недоумевали в отношении того, чем отличается схема Фроша-Загорского-Радкевичюте от схемы Фроша-Загорского. Попробуем разрушить это и другие недоумения.
Вопрос 1. Что такое схема (в терминологии «схема Фроша-Загорского-Радкевичюте»)?
Ответ: Схема есть то, что так называется (Die Scheme) в управляющих программах баз данных PostgreSQL и Oracle. Точнее, это совокупность таблиц (хранимых картотек) и правил их взаимной связи (это то, что в языке SQL помещается вокруг слова REFERENCE).
Вопрос 2. Чем отличается схема Фроша-Загорского-Радкевичюте от схемы Фроша-Загорского?
Ответ: Схема Фроша-Загорского (нем. FS-Scheme, пол. FZ-schemat) является частью схемы Фроша-Загорского-Радкевичюте (нем. FSR-Scheme, пол. FZR-schemat). Схема Фроша-Загорского не предусматривает таблицы, отвечающий за хранение графических координат абзаца на фотокопии и таблицы, отвечающей за хранение геометрического описания фотокопий страниц. Иными словами, схема Фроша-Загорского имеет своим содержанием только тексты безотносительно к фотокопиям оригинальных изданий.
Вопрос 3. Как выглядит схема Фроша-Загорского-Радкевичюте?
Ответ. Полноценной и актуальной диаграммы не существует. Однако товарищем Фрошем была реализована база данных, выходящая за пределы FZ-схемы, но не имеющая некоторых таблиц FZR-схемы. Для получения чертежа базы данных мы обратились к товарищу Фрошу. Он любезно согласился на публикацию диаграммы таблиц и связей, созданной по его просьбе товарищами при помощи специальной программы-графопостроителя.
Публикуемая диаграмма отражает попытку введения (в ответ на замечание товаришки Радкевичюте) свойств, содержащих время последнего изменения и название пользователя-редактора. Предложения товаришки Радкевичюте реализованы в данной схеме не в полной мере, также отсутствует связь работ с книгами1.
Места крепления связей не соотнесены со свойствами, то есть конкретное свойство для связи нужно выбирать из имеющихся в таблице по контексту, не полагаясь на линии. Много где названия свойств, участвующих в связи, выделены жирным шрифтом со стороны источника информации и никак не выделены со стороны приёмника (где хранится ссылка). Тем не менее, по смыслу должно быть понятно, что из одних таблиц уходит в другие. Так факт авторского участия, очевидно, содержит упоминание автора и его произведения.
Примерные переводы названий таблиц с эсперанто (по рядам слева направо, в каждом ряду сверху вниз)
(первый ряд)
Абзац-оригинал (какой абзац является основой перевода)
Абзац-примечание (к какому абзацу является примечанием этот абзац)
Абзац-последовательность (какой абзац следует за каким в тексте оригинала)
Абзац-страница (к каким страницам относится данный абзац)
(второй ряд)
Работы-названия (оригинал и переводы названий работ)
Авторство работ (какой автор принял участие в написании какой работы)
Абзацы (основная картотека текстов абзацев)
Авторы-имя (оригинальные и переводные имена авторов)
Правила оформления (содержимое специальных правил CSS, определяющих оформление всех текстов)
Авторство книг (какой автор указан на титульных листах какой книги)
Названия издательств (переводные и оригинальные)
Издание (участие издательства в публикации книги)
Книги-страницы (перечень страниц с номером и указанием на книгу)
Книги-названия (переводные и оригинальные)
(третий ряд)
Оригиналы произведений
Произведения
Авторы
Заголовки правил оформления (к каким абзацам каких классов применяются элементы правил)
(четвёртый ряд)
Языки
Издательства
Книги
(пятый ряд)
Языковые семьи
Вопрос 4: Порождает ли работа по схеме Фроша-Загорского какие-либо информационно-технические зависимости?
Ответ: Жить в обществе и быть свободным от общества нельзя. Вопрос содержательно переносится в характер этого влияния.
С юридической точки зрения правовые системы всех стабильных государств современности гарантируют свободу использования, распространения и доработки под свои нужды программ, управляющих базами данных - SQLite и PostgreSQL. Подобно ближайшим аналогам - программам Firebird MariaDB MySQL - названные находятся в той или иной форме общественной собственности: всякому гарантируется присвоение, но исключается любая попытка приватизации исключительных прав. SQLite, PostgreSQL и Firebird производятся коммунистическим способом - международным комитетом программистов-добровольцев, зарабатывающих иным способом. Не существует запретов на создание своих модификаций названных программ и не существует никаких платёжных обязательств в отношении авторов или распространителей этих программ. Конкретно SQLite и PostgreSQL созданы на языке программирования Си, который известен с 1970-х годов и может создавать программы для большого числа разных моделей процессоров. Формальный язык SQL в той части, которая нужна для схемы Фроша-Загорского-Радкевичюте, поддерживается весьма большим количеством платных и бесплатных программ управления базами данных, производимых как капиталистическим так и коммунистическим способом. Бесплатные производимые коммунистическим способом программы SQLite и PostgreSQL вследствие создания на языке Си почти не ограничены в выборе модели процессора. Таким образом, как информационная, так и техническая зависимость при работе по схеме Фроша-Загорского-Радкевичюте не больше, чем при работе с безбумажной формой текста в виде гипертекста. Например, форматы гипертекста стандартизированы в США в документах, многие из которых не имеют переводов с английского языка. В противоположность, схема Фроша-Загорского-Радкевичюте предлагается в наглядном виде на языке эсперанто для облегчения работы с ней и описания её сути на языках Европы.
Вопрос 5: Что было источником вдохновения для схемы Фроша-Загорского-Радкевичюте?
С этим вопросом мы обратились к товарищу Фрошу.
«Источником вдохновения было конкретное бумажное издание, которое показал мне один товарищ, связанный с помощью польским и украинским товарищам. Это трёхязычное издание «Іван Франко Franko Iwan Иван Франко Зів'яле листя Zwiędłe liście Увядшие листья» (Львів, Каменяр, 2003). Это было примерно в 2007 году. Через день мы с тем товарищем синхронно направили друг другу письма, что хорошо бы иметь в таком виде работы Ленина. Через несколько месяцев выяснилась невозможность сотрудничества с какими-либо носителями языка Ленина. В 2013 году заезжая литовка дала контакты польских текстологов, состоящих теперь в SMP . Лишь наши самообразовательные курсы по базам данных активизировали подготовку принципов FSR-схемы в 2015 году. Довольно легко убедиться, что названное издание отлично раскладывается в базу данных, созданную по FSR-схеме».
Вопрос 6: Что такое uuid, какую роль он играет и для чего применяется.
UUID2 (эта аббревиатура чаще пишется заглавными буквами) - это технический стандарт, предназначенный для создания особого бессодержательного представителя иного. UUID как представитель иного аналогичен номеру (документа, шкафа, заводского изделия, тепловоза, кабинета), однако не выполняет очевидное правило о том, что больший номер выдаётся позднее. В общем сравнение UUID имеет смысл только с результатом равен и не равен, но едва ли имеет какое-либо значение результат больше или меньше. От случайных чисел, нужной длины, получаемых разными способами, UUID отличается тем, что обеспечивает не столько случайность, сколько неповторимость. Вероятность создать одинаковые UUID на разных машинах должна быть крайне низкой. При создании миллиардов UUID ежесекундно повторение должно гарантированно произойти не чаще одного раза в несколько миллиардов лет. По просьбе товарища Фроша несколько немецких математиков подтвердили такую оценку повторимости UUID для алгоритма uuid_generate_v4(), заложенного в модуль uuid-ossp внутри PosgtgreSQL.
В отличие от номеров, где целое число может быть почтовым индексом, номером швейной машины, номером квартиры, телефонным кодом абонента и т. д., UUID однозначно указывает на то, что он означает. Скажем, неизвестно к чему относящийся UUID можно проверить по всем каталогам конкретной базы данных и выяснить к чему он относится, если все элементы какого-либо рода снабжены представляющими их кодами UUID. В этом случае в одном из каталогов данный UUID совпадёт и укажет на все другие свойства представляемого им объекта.
Вопрос 7: Чем вызвана странная форма записи UUID?
Ответ: Если взять образец формата «a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11», то такая форма записи вызвана программистскими особенностями формирования UUID. В одной из отделённых четвёрок зафиксирован способ получения UUID и она обычно не является случайной. Других подробностей узнать не удалось, ибо не нашлись сведения на немецком, польском или французском языке по истории программирования касательно получения UUID.
Возможно, товарищам помогут сведения, что в SQLite полноценный UUID в текстовом виде можно создать директивой
select '{' || hex( randomblob(4)) || '-' || hex( randomblob(2))
|| '-' || '4' || substr( hex( randomblob(2)), 2) || '-'
|| substr('AB89', 1 + (abs(random()) % 4) , 1) ||
substr(hex(randomblob(2)), 2) || '-' || hex(randomblob(6)) ||
'}';
Вопрос 8: Как UUID может хранить тип обозначаемого объекта, если это бессодержательный и неповторимый набор кодов?
Ответ: UUID как идеальный феномен ничем не отличается от других аналогичных феноменов по принципу функционирования. Так статуи Венеры не повторяют физическое тело, а воспроизводят его геометрию и фактуру в той мере, в какой это было значимо для античных мастеров. Так надпись «ptak» не хранит ничего связанного с признаками группы живых существ - птиц. С реальными птицами эта надпись не имеет никаких существенных общих свойств. Разве что надпись, как и птица, - это нечто протяжённое. Однако всякий, знающий польский язык, без труда проводит связь от экранных или типографских знаков «ptak» до реальных живых существ. Подобно надписи, UUID бесполезен для того, кто не умеет его применять по месту. Как знаки надписи, так и UUID ничего не содержат для того, кто не знает ни одного упоминания. Но как только появляется словарь польского языка или база данных с нужными каталогами, так для всякого человека обретают смысл надпись в случае со словарём и UUID в случае с базой данных. В каждом случае надпись и UUID, будучи по форме беесодержательными, несут в себе общественно важное содержимое некоего иного. Притом это содержание раскрывается всегда только для действующего по свои целям, связанного с обществом человека и только в процессе действия. Без осмысления надписи и без приказаний базе данных проверить наличие UUID оба феномена не имеют общественного значения и содержательных функций.
Вопрос 9: Что произошло с книжным комплектом 5-го издания ПСС Ленина в США?
Ответ: Мы обратились за разъяснениями к товарищам, организовавшим текстологическое совещание. Они сообщили, что убеждения гостя из Сан-Франциско не были известны - «он не предоставил никаких публикаций или текстов для прочтения. Латвийские товарищи предложили рассматривать гостя как политического авантюриста, а получение книжного комплекта как коммерческую операцию. Гость довольно хорошо разбирался в текстологии. Даже лучше, чем в немецком языке, но не демонстрировал желания держать контакт. В конце 2015 года попытки написать на указанный адрес электронной почты стали приводить к ошибке «неправильный или несуществующий получатель»».
Исходя из имеющихся у нас сообщений, нет смысла предполагать, что какие-либо самообразовательные сообщества в США приступили к текстологическим работам по произведениям Ленина. Критическое переиздание или комплектование книг, называемых у белорусов двухмоўнікамі, при существующем состоянии гипертекстов оригиналов исключается. Вероятнее всего, книжный комплект попал в академическую среду на началах обыкновенной товарной спекуляции. По опыту некоторых стран можно вывести, что направления текстологической работы связаны с направлениями теоретической работы через несколько опосредствующих элементов, то есть прямого соответствия не существует. Далеко не всегда уровень самообразовательной работы прямо сказывается на уровне текстологической работы. Единство этих уровней является чертой некоторой части центральной Европы и ряда провинций Индии, тогда как в большинстве остальных стран может быть найдена как текстология без связи с самообразованием, так и самообразование без связи с текстологическими работами.
Вопрос 10: Каков ожидаемый результат текстологической работы с использованием FZR-схемы?
Ответ: Результат непредсказуем, он ограничен творческими догадками тех людей, который будут работать с базой данных. Названные принципы построения базы данных потенциально пригодны и для автоматического создания прототипов одноязычных бумажных изданий, и для создания академических двойных и тройных (двухмоўнік, трохмоўнік) параллельных текстов. Автоматическое создание разных форматов электронных книг едва ли стоит упоминать как очевидное применение. Лёгкое улучшение перевода через доступность оригинала и лёгкое поабзацное создание перевода без отвлечения на проблемы оформления издания также должно быть упомянуто.
Вопрос 11: Существует ли реализация схемы Фроша-Загорского-Радкевичюте?
Ответ: Да. Авторы схемы согласились признать, что её реализует (за исключением двух языковых таблиц, описанных ранее) некоторая апробированная группа SQLкоманд для PostgreSQL (помещается в приложение №1). Предпосылкой правильного выполнения этих команд является наличие заполненного перечня языков и языковых семей, как было указано в предыдущей статье настоящего цикла.
Вопрос 12: Каковы ближайшие задачи по развитию FZR-схемы?
Ответ: Основательное комментирование приведённых выше команд на трёх мировых языках теоретического мышления. Сбор откликов.
Вопрос 13: Существуют ли образцы заполнения баз данных созданных по FZR-сехме?
Ответ: Нет, за исключением образцов из предыдущей части. Пока что отсутствуют образцы описания работы через оригинальную книгу, выпущенную издательством и имеющую авторство.
Вопрос 14: Нельзя ли понимать FZR-сехму иначе, чем группу таблиц базы данных с указанными связями?
Ответ: Нет. Только понимание группы таблиц как связанных в базе данных позволяет легко обращаться с результатами всех видов текстологической работы. Если же понимать FZR-схему как справочную основу для какой-либо одной программы или функции, то будет непонятен эффект объединения всех видов текстологического труда. FZR-сехма задумывалась не для удовлетворения текстологических потребностей, а для обеспечения самообразовательных потребностей и международного теоретического взаимодействия. В настоящий момент FZ-сехма охватывает (не ограничиваясь указанными) такие виды текстологического труда как:
1. Проверка достоверности (верификация) по оригиналу.
2. Корректура результатов полуавтоматического формирования текста по фотокопии.
3. Формирование параллельных многоязычных изданий.
4. Создание новых переводов.
5. Перепроверка переводов.
6. Поиск контекста цитат.
7. Поиск и перепроверка библиографических ссылок на оригинальное бумажное издание.
Вопрос 15: Как произвести занесение конкретного тома ленинских работ (например, http://uaio.ru/vil/33.htm) в базу данных, реализующую FZR-схему?
Ответ: Сводная рекомендация будет опубликована отдельной статьёй. Если коротко, то многое решает анализ текстологических свойств конкретного источника, после чего вырабатывается группа SQL команд, порядок которых можно считать типовым, ибо он не зависит от многих особенностей источника.
Вопрос 16: Каков принцип формирования сложной разметки текстов, например, отображения ленинского конспекта книги Фейербаха из XXIX тома?
Ответ: Руководящий текстологический принцип: в таблицу абзацев не попадет ни одного элемента, который не происходил бы прямо из авторской рукописи. Так, если автор отчеркнул тремя чертами слева строку с каким-то предложением, то это должно быть воспроизведено тут же в гипертекстовой форме. Безусловно, это относится к таким простым приёмам как курсив, жирный шрифт, подчёркивание, надчёркивание, написание индексов. Если же издатели отметили все абзацы цитат шрифтом несколько меньшего размера, но авторская рукопись не даёт примеров такого приёма, то абзацы цитат подлежат пометке «
», что даст в таблице абзацев Etikedo = p Klaso = Citato. В этом случае правила оформления цитат должны быть прописаны в двух таблицах, название которых включает «Dizajnoj». В одной таблице указывается применимость правил (элемент p и классом Citato), в другой его код связывается с отдельными правилами оформления.
Вопрос 17: Существуют ли текстологические проблемы, связанные с гипертекстовой формой представления?
Ответ: Да. В XXIX томе 5-го издания ленинских сочинений может быть найдено несколько приёмов, которые до сих пор не имеют соответствий в стандарте гипертекста HTML5. Немецкие товарищи из текстологической группы mlwerke.de указали на фигурные скобки и некоторые типы надчёрквиваний. Полноценной текстологической экспертизы оригинала XXIX тома до сих пор никем не было осуществлено. Однако несомненно, что все авторские приёмы оформления текста (за исключением выделения заглавий и, может быть, надписей на полях) не подлежат выносу в CSS и подлежат хранению в составе гипертекста.
Вопрос 18: Значительны ли текстологические проблемы, связанные с гипертекстовой формой представления?
Ответ: Нет. За исключением XXIX тома и нескольких подобных работ, всё остальное с точки зрения текстологических работ и текстологической экспертизы не требует знаний за пределами курса основной школы.
Вопрос 19: Как FZR-схема позволяет хранить иллюстрации?
Ответ: Авторские иллюстрации хранятся в гипертекстовом виде по месту как отдельный абзац или в составе абзаца, что определятся источником. Редакционные иллюстрации, титульные и технические листы не описаны в FZR-схеме. Однако возможно создать отдельную таблицу с привязкой к бумажному изданию для хранения подобных элементов. Заинтересованные текстологи приглашаются для обсуждения.
Вопрос 20: Какова правовая форма FZR-схемы и FZ-схемы?
Ответ: Авторы определили запрет на коммерческое использование подобной структуры базы данных до успешных испытаний на массовой работе. После того, как будет подтверждено, что базы данных, созданные по названным принципам, позволяют сохранять текстологическую работу без утраты авторского замысла и полноты бумажного издания-прототипа, ожидается передача всех SQL-команд на создание базы данных в общественное достояние.
Вопрос 21: Какова правовая форма текстологического результата в базах данных, созданных по FZR-схеме или по FZ-схеме?
Ответ: В главном это определяется теми, кто контролирует базу данных. Авторы FZR-схемы рекомендуют устанавливать режим ODBL лицензии или лицензии творческих коммун CC-BY-SA.
Вопрос 22: Какой этап автоматизации и работ по программированию проходит сейчас FZR-схема?
Ответ: По причине отсутствия людей с должной квалификацией в программировании в настоящий момент средства автоматизации загрузки текстов в базу данных полностью отсутствуют. В виде группы SQL-директив существует формирователь одноязычного гипертекстового прототипа любой работы. В виде программы на языке Java существует средство занесения стилей оформления текстов CSS в базу данных. Несколько функций были автоматизированы для терминала операционной системы в виде sh файлов с применением https://pl.wikipedia.org/wiki/Zenity и стандартного клиента psql. Однако эти черновые программы не выдерживают критики с точки зрения скорости, многоязычности и безопасности. В настоящий момент над созданием комплекта программ для FZR-схемы не работает ни один программист и эргономист, более того, графических интерфейсов FZR-схемы до сих пор не существует. Эта схема базы данных была создана на основании профессиональных знаний по математике (теория баз данных), кибернетике и текстологии, соображения общего программирования не рассматривались.
Вопрос 23: Какой объём хранения информации может потребовать база данных по схеме Фроша-Загорского для всего 5-го издания ленинских сочинений?
Ответ: Нормативный гипертекст в международной кодировке уникод для каждого тома занимает оценочно 4-6 мегабайт. При прямой оценке это 275 мегабайт текстовых данных. Добавляя использование кодов uuid, занимающих пятую часть от объёма текста (очень пессимистическая оценка) получаем 330 мегабайт. Книжные описания и описания работ можно оценить в 2-3 мегабайта. Итого огромный текстологический проект по созданию гипертекстов ленинских работ может уместиться по пессимистической оценке в 512 мегабайт пространства хранения. В тройной копии без архивирования это 1,5 гигабайта, что равно объёму 2 CD дисков. Фактически целесообразны 2 независимых CD копии. Затраты на накопители не превышают 5 евро для дорогих моделей. Проблема текстологического качества (упорядоченности и проверенности базы данных) и обобществления труда в данном случае намного превосходит по сложности любые технические трудности, что ясно из опыта международного текстологического проекта MEGA (издание оригиналов сочинений Маркса и Энгельса).
Вопрос 24: Существуют ли публичные базы данных, созданные по схемам FZ или FRZ?
Ответ: Нет. Существует испытательная модель в одном из городов Бранденбурга и готовится аналогичная испытательная модель в Варшаве. Для публичной работы обе модели не предназначены и публичных адресов не имеют. Все существенные команды по созданию таких моделей были опубликованы ранее и всякий внимательный читатель (даже совершенно незнакомый с базами данных до этой серии статей) может создать у себя аналогичную испытательную модель.
____
ПРИЛОЖЕНИЕ №1
Директивы SQL по созданию базы данных для текстологической работы
/* TEKSTUJO INTERNACIO ĜENERALA PROEKTO DE DATUMBAZO */
CREATE TABLE "Eldonejoj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Loko" text NOT NULL,
"Nomo internacia" text NOT NULL,
"Loko OSM" varchar NULL,
"Originala lingvo de nomo" varchar(3) NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Eldonejoj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Eldonejoj_Lingvoj_FK" FOREIGN KEY ("Nomo originalo - lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Eldonejoj - nomoj" (
"Eldonejo" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Nomo" text NOT NULL,
CONSTRAINT "Eldonejoj_nomoj_pk" PRIMARY KEY ("Eldonejo","Lingvo"),
CONSTRAINT "Eldonejoj_nomoj_Eldonejoj_FK" FOREIGN KEY ("Eldonejo") REFERENCES "Eldonejoj"("Kodo"),
CONSTRAINT "Eldonejoj_nomoj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Libroj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Nomo originalo - lingvo" varchar(3) NOT NULL,
"ISBN" varchar(32) NULL,
"Publikacio" date NOT NULL,
"Numero de eldono" int2 NOT NULL DEFAULT 1,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Libroj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Libroj_Lingvoj_FK" FOREIGN KEY ("Nomo originalo - lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Libroj - nomoj" (
"Libro" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Nomo" text NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Libroj_nomoj_pk" PRIMARY KEY ("Libro","Lingvo"),
CONSTRAINT "Libroj_nomoj_Libroj_FK" FOREIGN KEY ("Libro") REFERENCES "Libroj"("Kodo"),
CONSTRAINT "Libroj_nomoj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Libroj - paĝoj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Libro" uuid NOT NULL,
"Numero" varchar(16) NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Libroj_paĝoj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Libroj_paĝoj_Libroj_FK" FOREIGN KEY ("Libro") REFERENCES "Libroj"("Kodo")
);
CREATE TABLE "Aŭtoroj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Nomo originalo - lingvo" varchar(3) NOT NULL,
"Naskiĝo" date NOT NULL,
"Morto" date NOT NULL,
"Deskripcio" text NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
"Foto generala" bytea NULL,
CONSTRAINT "Aŭtoroj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Aŭtoroj_Lingvoj_FK" FOREIGN KEY ("Nomo originalo - lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Aŭtoroj - nomoj" (
"Aŭtoro" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Nomo" text NOT NULL,
"Familinomo" text NULL,
"Alianomoj" text NULL,
"Pseŭdonomo" bool,
"Adreso vikipedia" text,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Aŭtoroj_nomoj_pk" PRIMARY KEY ("Aŭtoro","Lingvo"),
CONSTRAINT "Aŭtoroj_nomoj_Aŭtoroj_FK" FOREIGN KEY ("Aŭtoro") REFERENCES "Aŭtoroj"("Kodo"),
CONSTRAINT "Aŭtoroj_nomoj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Eldono" (
"Eldonejo" uuid NOT NULL,
"Libro" uuid NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Eldono_Eldonejoj_FK" FOREIGN KEY ("Eldonejo") REFERENCES "Eldonejoj"("Kodo"),
CONSTRAINT "Eldono_Libroj_FK" FOREIGN KEY ("Libro") REFERENCES "Libroj"("Kodo")
);
CREATE TABLE "Aŭtoreco kun libro" (
"Aŭtoro" uuid NOT NULL,
"Libro" uuid NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Eldono_Aŭtoroj_FK" FOREIGN KEY ("Aŭtoro") REFERENCES "Aŭtoroj"("Kodo"),
CONSTRAINT "Eldono_Libroj_FK" FOREIGN KEY ("Libro") REFERENCES "Libroj"("Kodo")
);
CREATE TABLE "Laboroj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Nomo originalo - lingvo" varchar(3) NOT NULL,
"Publikacio" date NOT NULL,
"Libro" uuid,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Laboroj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Laboroj_Lingvoj_FK" FOREIGN KEY ("Nomo originalo - lingvo") REFERENCES "Lingvoj"("ISO 639-3"),
CONSTRAINT "Laboroj_Libroj_FK" FOREIGN KEY ("Libro") REFERENCES "Libroj"("Kodo")
);
CREATE TABLE "Laboroj - nomoj" (
"Laboro" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Nomo" text NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Laboroj_nomoj_pk" PRIMARY KEY ("Laboo","Lingvo"),
CONSTRAINT "Laboroj_nomoj_Laboroj_FK" FOREIGN KEY ("Laboro") REFERENCES "Laboroj"("Kodo"),
CONSTRAINT "Laboroj_nomoj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3")
);
CREATE TABLE "Laboroj - originaloj" (
"Laboro" uuid NOT NULL,
"Originalo" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Laboroj_originaloj_pk" PRIMARY KEY ("Lingvo", "Originalo"),
CONSTRAINT "Laboroj_originaloj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3"),
CONSTRAINT "Laboroj_originaloj_Laboroj_FK" FOREIGN KEY ("Laboro") REFERENCES "Laboroj"("Kodo"),
CONSTRAINT "Laboroj_originaloj_Laboroj_FK_1" FOREIGN KEY ("Originalo") REFERENCES "Laboroj"("Kodo")
);
CREATE TABLE "Aŭtoreco kun laboro" (
"Aŭtoro" uuid NOT NULL,
"Laboro" uuid NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Eldono_Aŭtoroj_FK" FOREIGN KEY ("Aŭtoro") REFERENCES "Aŭtoroj"("Kodo"),
CONSTRAINT "Eldono_Laboroj_FK" FOREIGN KEY ("Laboro") REFERENCES "Laboroj"("Kodo")
);
/* CSS */
CREATE TABLE "Dizajnoj" (
"Kodo" serial NOT NULL,
"Etikedo" varchar(32) NOT NULL,
"Klaso" varchar(64),
"Komento" text,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Dizajnoj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Dizajnoj_uq" UNIQUE ("Etikedo", "Klaso")
);
CREATE TABLE "Dizajnoj - elementoj" (
"Kodo" serial NOT NULL,
"Dizajno" int NOT NULL,
"Atributo" varchar(64),
"Valoro" varchar(64),
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Dizajnoj_elementoj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Dizajnoj_elementoj_Dizajnoj_FK" FOREIGN KEY ("Dizajno") REFERENCES "Dizajnoj"("Kodo")
);
/* PARAGRAFOJ */
CREATE TABLE "Paragrafoj" (
"Kodo" uuid NOT NULL DEFAULT uuid_generate_v4(),
"Laboro" uuid NOT NULL,
"Etikedo" varchar(32) NOT NULL,
"Klaso" varchar(64) NULL,
"Interno" text NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Paragrafoj_pk" PRIMARY KEY ("Kodo"),
CONSTRAINT "Paragrafoj_Dizajnoj_FK" FOREIGN KEY ("Etikedo", "Klaso") REFERENCES "Dizajnoj"("Etikedo", "Klaso"),
CONSTRAINT "Paragrafoj_Laboroj_FK" FOREIGN KEY ("Laboro") REFERENCES "Laboroj"("Kodo")
);
CREATE TABLE "Paragrafoj - ĉenoj" (
"Antaŭa" uuid NOT NULL,
"Sekva" uuid NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Paragrafoj_ĉenoj_Paragrafoj_FK" FOREIGN KEY ("Antaŭa") REFERENCES "Paragrafoj"("Kodo"),
CONSTRAINT "Paragrafoj_ĉenoj_Paragrafoj_FK_1" FOREIGN KEY ("Sekva") REFERENCES "Paragrafoj"("Kodo")
);
CREATE TABLE "Paragrafoj - notoj" (
"Paragrafo" uuid NOT NULL,
"Aŭtora" bool NOT NULL,
"Kodo_de_Div" text NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
"Fonto" uuid NOT NULL,
CONSTRAINT "Paragrafoj_notoj_Paragrafoj_FK" FOREIGN KEY ("Paragrafo") REFERENCES "Paragrafoj"("Kodo"),
CONSTRAINT "Paragrafoj_notoj_Paragrafoj_FK1" FOREIGN KEY ("Fonto") REFERENCES "Paragrafoj"("Kodo")
);
CREATE TABLE "Paragrafoj - originaloj" (
"Paragrafo" uuid NOT NULL,
"Originalo" uuid NOT NULL,
"Lingvo" varchar(3) NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Paragrafoj_originaloj_pk" PRIMARY KEY ("Lingvo", "Originalo"),
CONSTRAINT "Paragrafoj_originaloj_Lingvoj_FK" FOREIGN KEY ("Lingvo") REFERENCES "Lingvoj"("ISO 639-3"),
CONSTRAINT "Paragrafoj_originaloj_Paragrafoj_FK" FOREIGN KEY ("Paragrafo") REFERENCES "Paragrafoj"("Kodo"),
CONSTRAINT "Paragrafoj_originaloj_Paragrafoj_FK_1" FOREIGN KEY ("Originalo") REFERENCES "Paragrafoj"("Kodo")
);
CREATE TABLE "Paragrafoj - paĝoj" (
"Paragrafo" uuid NOT NULL,
"Paĝo" uuid NOT NULL,
"Uzanto" varchar(64) NOT NULL DEFAULT user,
"Tempo" timestamptz NOT NULL DEFAULT now(),
CONSTRAINT "Paragrafoj_paĝoj_Libroj_paĝoj_FK" FOREIGN KEY ("Paĝo") REFERENCES "Libroj - paĝoj"("Kodo"),
CONSTRAINT "Paragrafoj_paĝoj_Paragrafoj_FK" FOREIGN KEY ("Paragrafo") REFERENCES "Paragrafoj"("Kodo")
);
___
1 Это вызвано тем, что диаграмма отражает более раннюю версию схемы базы данных, чем SQL директивы. Диаграмма создавалась не товарищем Фрошем, а по его просьбе другими людьми - TC.
Фр. IDentifiant Universel Unique, анг. Universally Unique IDentifier ,
2 см. https://docs.postgresql.fr/10/datatype-uuid.html
Украинский жаргонизм "всесвітня неповторна ознака" (всемирный опознаватель без повторений) - Ред.
Часть 3 http://propaganda-journal.net/10402.html
Часть 4 http://propaganda-journal.net/10412.html
Часть 5. http://propaganda-journal.net/10421.html
Речи к представителям самообразовательных теоретических сообществ о воспитательном значении текстологической работы.
Речь 1 http://propaganda-journal.net/10313.html
