Читать статью 'Опыт построения реляционной базы просопографии итальянских факторий Причерноморья (XIII-XV вв.)' в журнале Историческая информатика на сайте nbpublish.com
Рус Eng За 365 дней одобрено статей: 1697,   статей на доработке: 299 отклонено статей: 358 
Библиотека
ваш профиль

Вернуться к содержанию

Историческая информатика
Правильная ссылка на статью:

Опыт построения реляционной базы просопографии итальянских факторий Причерноморья (XIII-XV вв.)

Карпов Сергей Павлович

доктор исторических наук

академик РАН, профессор кафедры истории Средних веков Московского государственного университета имени М.В.Ломоносова

119192, Россия, г. Москва, г. Москва, ул. Пр. Ломоносовский, 27к4, оф. 1

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
Ильяшенко Владимир Александрович

старший преподаватель кафедры исторической информатики исторического факультета Московского государственного университета имени М.В.Ломоносова.

119192, Россия, г. Москва, г. Москва, пр. Ломоносовский, 27к4, оф. 1

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

DOI:

10.7256/2585-7797.2021.3.36565

Дата направления статьи в редакцию:

30-09-2021


Дата публикации:

07-10-2021


Аннотация: В данной статье рассматривается опыт построения базы данных, материал для которой собирался на протяжении многих лет в рамках работы над комплексом документов по истории средневековой Италии – нотариальными документами по истории итальянской торговой фактории – Таны (Азова). В результате этой работы был собран значительный объем материала, анализ которого представлял сложную задачу в силу особенности организации имеющихся сведений. Для решения этой задачи при помощи СУБД Access была создана реляционная база данных, состоящая из шестнадцати таблиц, содержащих несколько десятков полей. Так, особыми задачами являлись идентификация имен, содержащихся в источниках, а также выявление и удаление многократных упоминаний одних и тех же персоналий.   Кроме того, рассмотрены основные задачи и сложности, возникавшие при создании базы данных, а также при анализе путем создания запросов. Так, особыми задачами являлись идентификация имен, содержащихся в источниках, а также выявление и удаление многократных упоминаний одних и тех же персоналий. Данная база содержит многостороннюю информацию о коммерческих сделках, совершенных в Тане в XIII-XV вв. Так, в базу внесены сведения о сделках, местах, датах и особенностях этих сделок, подробные сведения о персоналиях, связанных со сделками, и ссылки на источники этой информации. В статье подробно рассмотрены особенности источниковой базы исследования.


Ключевые слова: материалы судебного делопроизводства, нотариальные акты, Генуэзский государственный архив, Венецианский государственный архив, Тана - Азов, итальянская торговая фактория, История Средних веков, идентификация имен, реляционная база данных, СУБД Access

Abstract: The article discusses the process of database creation that covers notarial documents telling us about the history of an Italian trading post Tana (Azov). The material for the database has been collected over several years as part of a research addressing a set of documents about the history of medieval Italy. In the course of the research a considerable body of material has been collected. Its analysis was a hard task since data were arranged in a peculiar way. To achieve the goal a relational database consisting of sixteen tables which in turn contained several dozen fields has been created on the basis of DBMS Access. The article also describes the main goals and difficulties the database creation is accompanied by as well as those emerging when analysis by means of inquires is made. These are identification of names mentioned in the sources as well as identification and removal of multiple references to the same personalities. This database covers multilateral information about commercial transactions made in Tana in the 13th-15th centuries including places, dates and details of these transactions, detailed information about people involved as well as links to sources of this information.



Keywords:

name identification, court records, notarial deeds, Genoese State Archives, Venetian State Archives, Tana - Azov, Italian trading post, History of the Middle Ages, relational database, Access DBMS

Материалы источников по истории классического Средневековья позволяют исследователю производить не только качественный, но и количественный анализ процессов и явлений экономического и политического развития регионов. Наличие комплексов нотариальных документов по истории самой дальней итальянской торговой фактории – Таны (Азова), расположенной в устье Дона, дает возможность детального изучения коммерческой активности и реалий повседневной жизни поселения, расположенного на территории Золотой Орды и являвшегося терминалом путей мировой торговли, связывавших мир Средиземноморья с Востоком, протянувшихся от Китая и Средней Азии до гаваней Азовского и Черного морей. Там они встречались с миром Древней Руси, Византии, Кавказа и оттуда корабли венецианцев и генуэзцев перевозили товары в Западную Европу [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], в подготовленной книге по истории Таны также использованы материалы базы и проведен сущностный анализ содержащихся в ней данных.

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

Библиография
1.
Archivio di Stato di Venezia, Cancelleria Inferior, Notai, 19, Benedetto Bianco, 1 cart., NN 115-116, 160.
2.
Bautier R.-H. Sources pour l’histoire du commerce maritime en Méditerranée du XIIe au XVe siècle // Mollat M., Adam P. (ed.). Les sources de l’histoire maritime en Europe du Moyen Age au XVIIIe siècle. Paris, 1962, P. 137-179.
3.
Fossier R. L’histoire économique et sociale du moyen âge occidental. Questions, sources, documents commentés. Brepols, 1999. 408 p.
4.
idem [7]. Slavery in the Black Sea Region, 14th – 15th Centuries (Mainly according to the data of the Venetian notary sources) // Slavery in the Black Sea Region, c.900–1900. Forms of Unfreedom at the Intersection between Christianity and Islam / Edited by Felicia Roșu. Leiden, 2021. P. 41-59.
5.
Melis F. Documenti per la storia economica dei secoli XIII-XVI. Firenze, 1972. 752 p.
6.
Карпов С.П. История Таны (Азова) в XIII–XV вв.: в 2 т. – Т. 1. Тана в XIII–XIV вв. – СПб., Алетейя. 378 с.
7.
Карпов С.П. Работорговля в Тане в XIV-XV вв. (преимущественно по данным венецианских нотариальных источников) // Византийский временник. 2017. Т. 101. С. 128-142.
8.
Скржинская Е.Ч. История Таны // Скржинская Е.Ч. Барбаро и Контарини о России. К истории итало-русских связей в XV в. Л., 1971. С. 29-64.
References (transliterated)
1.
Archivio di Stato di Venezia, Cancelleria Inferior, Notai, 19, Benedetto Bianco, 1 cart., NN 115-116, 160.
2.
Bautier R.-H. Sources pour l’histoire du commerce maritime en Méditerranée du XIIe au XVe siècle // Mollat M., Adam P. (ed.). Les sources de l’histoire maritime en Europe du Moyen Age au XVIIIe siècle. Paris, 1962, P. 137-179.
3.
Fossier R. L’histoire économique et sociale du moyen âge occidental. Questions, sources, documents commentés. Brepols, 1999. 408 p.
4.
idem [7]. Slavery in the Black Sea Region, 14th – 15th Centuries (Mainly according to the data of the Venetian notary sources) // Slavery in the Black Sea Region, c.900–1900. Forms of Unfreedom at the Intersection between Christianity and Islam / Edited by Felicia Roșu. Leiden, 2021. P. 41-59.
5.
Melis F. Documenti per la storia economica dei secoli XIII-XVI. Firenze, 1972. 752 p.
6.
Karpov S.P. Istoriya Tany (Azova) v XIII–XV vv.: v 2 t. – T. 1. Tana v XIII–XIV vv. – SPb., Aleteiya. 378 s.
7.
Karpov S.P. Rabotorgovlya v Tane v XIV-XV vv. (preimushchestvenno po dannym venetsianskikh notarial'nykh istochnikov) // Vizantiiskii vremennik. 2017. T. 101. S. 128-142.
8.
Skrzhinskaya E.Ch. Istoriya Tany // Skrzhinskaya E.Ch. Barbaro i Kontarini o Rossii. K istorii italo-russkikh svyazei v XV v. L., 1971. S. 29-64.

Результаты процедуры рецензирования статьи

В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.

Рецензия на статью «Опыт построения реляционной базы просопографии итальянских факторий Причерноморья (XIII-XV вв.)»
Рецензируемая статья посвящена вопросам изучения экономической, политической, а также культурной и повседневной жизни конца XIII – XV вв. итальянской торговой фактории – Таны (Азова), расположенного на путях мировой торговли Средиземноморья с Востоком.
В центре внимания исследователя находится количественный анализ большого комплекса источников – нотариальных документов из архивных фондов Венецианского и Генуэзского государственных архивов. Источниковедческий анализ показывает, что эти документы отличаются достоверностью и точностью зафиксированной в них информации об обстоятельства и условиях сделок.
Инструментом анализа в работе является просопографическая база данных по участникам сделок. Существенным этапом стала унификация (регуляризация) имен, поскольку в документах имеются разночтения в написании имен одних и тех же лиц, которые по-разному транскрибируются нотариями. Автор приводит объяснение того, что нотарии не считали обязательным всегда одинаково называть одно и то же лицо – для них гораздо важнее бала идентификация персоналий в рамках конкретной общины, понятная для его контрагентов и для властей. Основанием для написания имен обычно служит самоидентификация заказчика акта или его именование контрагентами. Дополнительной проблемой может быть и совпадение имен у разных лиц.
Для верификации имен персоналий автор использует особую «справочную» таблицу, куда заносятся данные об этносе и происхождении лица из какого-либо места, иногда –профессии, принадлежности определенному приходу, возраста, титула и др. Многоуровневая верификация проводится автором на основании анализа содержания группы актов или по родственным связям лиц-участников сделки. Итак, составленная база данных была подвергнута многоуровневой верификации имен, позволившей устранить «дубликаты» и однозначно идентифицировать лиц.
Дополнительная информация извлекается из материалов судебного делопроизводства по коммерческим спорам, торговых книг, постановлений органов власти и других источников, отражавших торговые операции и действия контрагентов.
Связывая таблицы реляционной базы, автор в качестве главных таблиц выбирает таблицы «имена» и «сделки», между которыми существуют связи типа «многие-ко-многим». Связь между этими таблицами, как это обычно принято в MS Access, реализована через подчиненную таблицу. Это таблица «источники», куда заносятся входят идентификаторы как персоналий, так и сделок. Следует заметить, что таблица «источники» должна быть охарактеризована как подчиненная, а не основная (как это видно на рис. 1).
Масштаб созданной базы, включающей 16 таблиц, – это более 10 тыс записей в таблицах «источники» и «сделки» и более 5600 персоналий. Подчиненными для таблицы «имена» являются таблицы со сведениями таблиц имеются таблицы о гражданстве, месте жительства, профессии, должности, семейном положении, деловых и личных связях контрагентов, у таблицы «Сделки» имеются три подчиненные таблицы.

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

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