Relation Database Covering Black Sea Region Prosopographical Studies of Italian Black Sea Trading Posts (13th - 15th cc.)

Karpov Sergei Pavlovich Doctor of History Academician of the Russian Academy of Sciences, History Professor, Departmentt of Medieval History, Lomonosov Moscow State University   119192, Russia, g. Moscow, g. Moscow, ul. Pr. Lomonosovskii, 27k4, of. 1 spkarp1204@yandex.ru

Ilyashenko Vladimir Aleksandrovich Senior Lecturer, Historical Information Science Department, History Faculty, Lomonosov State University   119192, Russia, g. Moskva, g. Moscow, pr. Lomonosovskii, 27k4, of. 1 vlad-ilyashenko@ya.ru

Материалы источников по истории классического Средневековья позволяют исследователю производить не только качественный, но и количественный анализ процессов и явлений экономического и политического развития регионов. Наличие комплексов нотариальных документов по истории самой дальней итальянской торговой фактории – Таны (Азова), расположенной в устье Дона, дает возможность детального изучения коммерческой активности и реалий повседневной жизни поселения, расположенного на территории Золотой Орды и являвшегося терминалом путей мировой торговли, связывавших мир Средиземноморья с Востоком, протянувшихся от Китая и Средней Азии до гаваней Азовского и Черного морей. Там они встречались с миром Древней Руси, Византии, Кавказа и оттуда корабли венецианцев и генуэзцев перевозили товары в Западную Европу ^{[6][8, с. 29-64]}. Инструментом изучения этих источников может быть просопографическая база данных, позволяющая через имена и деятельность людей анализировать феномены экономического, политического, а иногда и историко-культурного развития эпохи конца XIII – XV вв.

Анализируемые нами источники – это в основном документы из архивных фондов Венецианского и Генуэзского государственных архивов. Их сравнительно высокая степень сохранности позволяет восполнить очевидную лакуну отсутствия подобных материалов в отечественных собраниях (исключая, быть может, новгородские берестяные грамоты, при том многократно превосходящие их и численно и информативно).

Отбирая источники для включения в своего рода аналитическую «анкету», мы прежде всего обращаемся к нотариальным актам. Их особенность в том, что они заключались на месте, в конкретное время и точно, а не опосредованно, как, например, нарративные источники, фиксируют обстоятельства и условия сделок. Важным дополнением к ним являются материалы судебного делопроизводства, разбиравшего коммерческие споры и нарушения правового регулирования, записи торговых книг купцов, руководств по ведению торговли, постановления и поручения органов власти и комиссий Венеции и Генуи, любые другие свидетельства, адекватно и непосредственно отражавшие торговые операции и действия контрагентов и магистратур ^{[2, с.137-179][3][5]}. Разумеется, перед включением материалов источников в базу данных, необходим аналитический анализ их особенностей, достоверности и характера отражения ими действительности.

В качестве ключевой категории для регистрации данных в таблицах отбирались регуляризированные записи патронима и пренома участника сделки. Регуляризация необходима ввиду того, что нотарии по-разному транскрибируют имена одних и тех же лиц.

Метод идентификации имен в базе данных требует пояснения. Дело в том, что для средневекового нотария отнюдь не представлялось необходимым и существенным всегда одинаково называть одно и то же лицо, прибегая к некому стандартному и однообразному обозначению патронима и пренома. Для него гораздо существеннее такая идентификация, которая была бы понятна и достаточна для данной общины, в которой он работал, для его контрагентов и для властей (судебных или административных), куда могли обращаться его клиенты. Таким идентификатором могла служить редкая или единственная в фактории должность (к примеру, переводчик с татарского-труциман), «национальность» (например, тевтон), или характерное прозвище (например, Карабога – у итальянца Франческино Сенья). Прекрасно зная имя труцимана и даже приводя его (в том числе - без всякого упоминания должности) в каком-либо ином акте, нотарий в последующих документах может определить это же, хорошо известное ему, лицо только по должности, без имени. Составитель базы данных тем самым должен анализировать всю возможную совокупность актов в их взаимосвязи. Чем меньше в нашем распоряжении массив актов, тем больше вероятность ошибки идентификации. Сложностью идентификации является и вероятность того, что под одним именем, например, Андреа Корнаро, скрывается два лица. Проблемы с отождествлением возникают и при разном написании личных имен с употреблением так называемых экспрессивных или уменьшительных суффиксов (-ин, -ол и др.), типа: Марин и Маринино, Андреа и Андреоло, Николо и Николетто. Это может быть и один человек, и два разных лица. Исследование показало, что в большинстве случаев нотарий довольно безразличен к наличию или отсутствию таких суффиксов и употребляет имена с ними и без них на равных основаниях, применительно к одному и тому же лицу. Основанием для написания пренома для него служит самоидентификация заказчика акта или его именование контрагентами. При этом нотарий в написании всех имен допускает разные графические варианты (Chaterina – Katerina, Lodoycus – Ludovicus, Bedoloto-Bedolotto, Phelipo-Filippus и т.п.). Многочисленны просторечные варианты преномов (например, Zan вместо Iohannes) и разные написания их патронимов в латинской форме или на диалетто, отличающиеся от принятого и стандартного итальянского варианта (например, Mauroceno вместо Morosini, Superantio, вместо Soranzo, Picameio вместо Piccamiglio). Для верификации необходимо, наряду с регуляризацией, сохранить оригинальные варианты написания имени в источнике, и это сделано в особой таблице «справка имен», куда заносятся также данные об этносе и происхождении лица из какого-либо города или места, квартала или прихода, где он проживает, а также (если это указывается) возраста.

Идентификацию лиц отчасти облегчает то, что нотарий нередко упоминает отца участника сделки и квартал или приход в Венеции, откуда он был родом. Исключение составляют краткие обозначения лиц, когда они выступают свидетелями. Некоторую помощь здесь, как и в других случаях, могут оказать «титулы». Сочетание типа «nobilis vir, dominus», «nobilis vir, ser» указывают на безусловную принадлежность лица к одному из патрицианских семейств Венеции, в то время как простое упоминание лица с «благородным» патронимом, типа Морозини или Тьеполо, отнюдь не гарантирует его принадлежность к этим знаменитым фамилиям, ибо некоторые вольноотпущенники, бывшие рабы тех же Тьеполо, принимали их родовые имена. Но рядом с таким именем нотарий никогда не поставит «nobilis vir» или даже более нейтрального «ser». Титул «ser» (в редких актах на диалетто-«misser») без дополнительных дефиниций не означает патрицианского статуса носителя, хотя может употребляться и при имени нобиля. Это именование присваивается вообще всем полноправным гражданам Венеции и Генуи, включая и имеющих этот статус греков и иудеев. Титул «discretus vir» может означать и нобиля, но чаще просто вообще уважаемого человека, например, нотария или купца из другого города (к примеру, Генуи) ^{[1, NN 115-116, 160]}. Титул «egregius vir, dominus» чаще всего прилагается к высокому должностному лицу – консулу или послу, «honestus vir» - к клирику, «magister» – к ученому человеку, судье, врачу, имеющим, как правило, университетское образование. Все эти титулы являются для нас идентификатором. Отождествление производится как на основании анализа содержания группы актов (например, оформляющих одну или связанные сделки), так и по родственным связям лиц, их принадлежности к определенным приходам или кварталам, их профессии. Итак, составленная база данных была подвергнута многоуровневой верификации имен, позволившей устранить «дубликаты» и однозначно идентифицировать лиц.

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

В настоящее время составленная база таблиц имеет 10800 записей в кумулятивных таблицах «источники» и «сделки». В ней 5608 верифицированных имен. В качестве отдельных, связанных с «именами» таблиц имеются таблицы о гражданстве, местах жительства, профессиях, должностях, семейном положении, деловых и личных связях контрагентов. База непрерывно пополняется по мере ввода в нее новых материалов. Её достоинством является её открытость и легкость обращения с запросами, возможность при необходимости графически отображать искомые параметры анализа.

Рис. 1. Общая структура базы.

Рассматриваемая база состоит из шестнадцати таблиц, и принцип построения связей в базе напрямую связан с источниками, на которых она построена. База спроектирована таким образом, чтобы существовала возможность удобно анализировать внесенные данные путем создания запросов.

База является реляционной, таблицы в базе связаны по принципу «многие-ко-многим» и «один-ко-многим». Так, в базе есть три основные таблицы – «Люди», «Сделки» и «Источники», а также тринадцать подчиненных таблиц с дополнительной информацией. Так как в источниках содержится информация о нотариально зафиксированных сделках, основой базы стала информация о зарегистрированных сделках и о людях, связанных с этими сделками. Один и тот же человек мог участвовать во многих сделках, и информация об этих сделках может находится в разных источниках. В силу этого между таблицами «Люди» и «Сделки» была создана таблица «Источники», содержащая информацию об источниках, откуда почерпнуты сведения о сделках и людях, в них участвовавших. Таким образом обеспечена связь «многие-ко-многим» между таблицами «Люди» и «Сделки». У таблицы «Люди» есть 10 подчиненных таблиц, содержащих дополнительные сведения о персоналиях и соединенных с ней связью «один-ко-многим», то же самое и у таблицы «Сделки», имеющей три подчиненные таблицы.

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

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

Сведения из источников собирались на протяжении многих лет без учета возможности объединения их в реляционную базу, и представляли собой четыре несвязанные между собой отдельные таблицы в формате базы данных, имеющих разное, иногда весьма существенное – до 65 – количество полей. Состав полей в разных таблицах также различался. В силу этой особенности базы первой задачей было приведение к единой структуре имеющиеся таблицы, а также экспорт их в формат xlsx, так как в Excel работа с одиночными таблицами эффективнее, чем в Access. После приведения всех четырех таблиц к единому формату необходимо было объединить их в одну большую общую таблицу. Чтобы не допустить потерь информации, в единую таблицу было введено поле, содержащее информацию о том, из какой таблицы была перенесена запись.

Кроме того, особенностью первоначальной базы было то, что единицей информации в ней была сделка, и поэтому база содержала массу дублированных записей о людях. Некоторые персонажи могли участвовать в десятках сделок, но выявить это при старой структуре базы было невозможно, хотя для дальнейшей работы была необходимость получать эти сведения. Из базовой таблицы мы выделили в отдельные таблицы формата xlsx сведения, которые должны были в дальнейшем войти в разные таблицы реляционной базы, и добавили поля для связи – номер человека или номер сделки. Так в разрозненных таблицах полностью сохранялась возможность однозначно связать записи между собой, а в дальнейшем перенести их в реляционную базу с сохранением целостности данных.

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

Упомянутая проблема проявила себя также и в том, что возникла разница между таблицей «Люди» и подчиненными таблицами. В таблице «Люди» номера у повторяющихся персоналий были исправлены, а в подчиненных таблицах нет, и база данных в таком случае не могла пройти проверку целостности – в подчиненных таблицах появлялись номера персоналий, отсутствующие в главной таблице. Чтобы не сводить все данные обратно в одну таблицу, исправлять и потом разносить по многим таблицам обратно, было сделано следующее.

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

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

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

Для выявления рабов в качестве условия использовалось выражение «Like "*scl*"», (sclavus, sclava (лат.) – раб, рабыня, невольник) по которому из всех родов деятельности персоналий отбирались только рабы. Звезда (подстановочный знак в Access, заменяет любое количество любых символов) в начале и в конце условия позволяет найти в том числе записи, где содержится дополнительная информация (например, «famula, exsclava» или «sclava et ancilla»).

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

Один из вариантов запроса предполагал использование неявного логического оператора «ИЛИ». В таком случае для поля «Место сделки» возможно применить условие «"*TA*"», но для каждого места сделки условие необходимо указывать на новой строке, а для каждого поля «Дата сделки» использовать условие «Not Like "14*"», чтобы исключить 15 век (запись в поле «Дата сделки» всегда начинается с года), и повторить это условие на каждой строке для каждого поля «Дата сделки». Это неудобный вариант, к тому же усложняющий задачу при необходимости внесения в запрос дополнительных условий.

Рис. 2. Вариант запроса для поиска сделок, совершенных в Тане не в 15 веке.

Более удобным вариантом решения этой проблемы является возможность использования операторов амперсанд (&) и «+» в Access, которые позволяют объединять текстовые значения из разных полей в одном. В заголовок соответствующего поля запроса было подставлено выражение «("Год "+[Дата сделки1]) & (", Год "+[Дата сделки2]) & (", Год "+[Дата сделки3])», а в качестве условия использовалось выражение «Not Like "*Год 14*"». Вывод запроса по этому полю в таком случае представляет из себя запись типа «Год 1363.06.22, Год 1364.02.28». (В приведенном примере в полях «Дата сделки1» и «Дата сделки2» есть записи, в поле «Дата сделки3» записи нет, поэтому третье слово «Год» не отображается. Это особенность оператора «+», когда пустое значение в ячейке (Null) приводит к выводу значения Null для всего выражения в скобках.) Слово «Год» (можно взять любой символ или несколько символов, не встречающихся в записях данного поля и не являющихся операторами Access) в выражении было использовано для того, чтобы обеспечить точное указание на столетие, в противном случае по подобному условию можно найти и 14 число месяца, что будет ошибкой.

Рис. 3. Запрос для выявления количества проданных рабов в Тане (режим конструктора).

Для полей «Место сделки» подстановка дополнительных символов не является обязательной, так как наличие букв «TA» в любом месте объединенной записи является корректным и свидетельствует об отношении сделки к Тане, однако для более удобного чтения результатов запроса между записями о местах сделки при помощи выражения «Места: [Место сделки1] & (", "+[Место сделки2]) & (", "+[Место сделки3])» мы подставили запятые.

Рис. 4. Результат запроса (режим таблицы).

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

* * *

Представленная структура базы данных позволяет через систему запросов выявлять и систематизировать необходимую информацию, к примеру: о количественном и этническом составе населения факторий, объемах и динамике товарооборота, количестве и качестве товаров, их ценах и системах денежного обращения, методах и инструментах ведения торговли, таких, как торговые общества (societates), торговое партнёрство (комменды), поручительства, формы и виды кредита. Наконец, мы восстанавливаем историю людей в их взаимосвязях, обнаруживаем скрытую до того информацию об облике участников сделок через их идентификацию по разным запросам. В целях верификации и проверки записей возможно через поле «вложение» включать в базу непосредственно и сами используемые источники в виде их фотографий или транскрипций.

Одним словом, мы получаем возможность не обобщенно (или в качестве примеров), а вполне конкретно проследить эволюцию экономических отношений целого региона в его многосторонних связях. Таким образом нами исследовался, например, феномен работорговли, ее векторы, динамика, масштаб, этнический, половозрастной состав рабов, контрагенты сделок и т.д. ^{[4, p. 41-59][7, с. 128-142]}, в подготовленной книге по истории Таны также использованы материалы базы и проведен сущностный анализ содержащихся в ней данных.

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