Структура базы

На сайте ВГД собираются люди, увлеченные генеалогией, историей, геральдикой и т.д. Здесь вы найдете собеседников, экспертов, умелых помощников в поисках предков и родственников. Вам подскажут где искать документы о павших в боях и пропавших без вести, в какой архив обратиться при исследовании родословной своей семьи, помогут определить по старой фотографии принадлежность к воинским частям, ведомствам и чину. ВГД - поиск людей в прошлом, настоящем и будущем!

Ага ... только не забудьте к каждому полю свойства, которое - по Вашему мнению - "у персоны не остается постоянным", добавить еще ДВА поля даты:
[начиная c даты] и [оканчивая датой]! ;-)
___________________

На самом деле, две этих НОТАЦИИ:
1. один объект со всеми своими свойствами (будь их хоть сто, хоть тысяча!) - в одной строке таблицы, и
2. строка таблицы - описывает ОДНО значение ОДНОГО свойства у ОДНОГО объекта,
- между ними существует ВЗАИМНООДНОЗНАЧНОЕ соответствие, то есть - можно переходить (например, - трансформировать базу данных) от одной нотации к другой и обратно ...

С другой стороны, каждая нотация имеет и свои преимущества, и свои недостатки ...

(Сообщение отредактировал silv ivan 19 янв. 2004 19:54)

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

Еще скажу, что я всегда был сторонником больших и смелых проектов. Так, что идея Людмилы мне понятна и очень даже по душе.

[q]
Цитата: silv ivan написал 19 янв. 2004 19:48
к каждому полю свойства, которое ... "у персоны не остается постоянным", добавить еще ДВА поля даты:
[начиная c даты] и [оканчивая датой]! ;-)
[/q]

Вот!
Мне кажется, что не надо разносить ФИО по разным клеткам, тем более, что когда-то ни отчества, ни фамилии не было. То есть, мне кажется именование персоны надо вносить в одну клетку, целиком. И совершенно все равно, что там писать – Иван Петров Яковлев, именуемый также Карачун, или Петр Ильич Чайковский – и то, и другое – именованеи персоны. Но по этому поводу надо сделать классификатор фамилий. То есть первая таблица – классификатор фамилий, две клетки: ID фамилии, Фамилия
Вторая таблица – классификатор персон. Три клетки: ID персоны, ID фамилии, именование персоны.
Поскольку в базе будут встречаться населенные пункты, обязательно нужен классификатор населенных пунктов, то есть ID населенного пункта тоже будет, но я еще не придумала состава таблиц, потому что они меняли наименование и административно-территориальное деление. Пока упростим задачу, не принимаем это в расчет (не при определении структуры базы, а просто на данном этапе рассуждений) и делаем простую таблицу из двух клеток: ID населенного пункта, наименование населенного пункта.
Напоминаю, что одна из задач, которую хочет решать Роджер такая: «К примеру, поставлена задача найти всех персон, происходящих из Нижегородской губернии, которые в 1763 г. (3-я ревизия) числились при Невьянском заводе крепостными, были заняты в молотовом производстве, а именно имели должность мастера, у которых отцы также были мастерами и принадлежали к первому поколению переселенцев, а жены происходили из того же завода. При этом желательно видеть в отчете все прочие поля - возраст, напрмер и т.п.» Ну то есть в конечном итоге без губерний не обойтись, но пока игнорируем.
Ну и, поскольку он хочет вносить источники, по ходу дела создается классификатор источников, две клетки: ID источника, наименование источника.
Ну и поскольку нужны церковные приходы, еще создается классификатор церковных приходов, дву клетки : ID прихода, наименование. Тут бы тоже надо разобраться со всякими епархиями, но об этом потом.
То есть, пока занимаемся набором таблиц для персон. Таблицы на основе событий. Поля буду звездочкой разделять. А то запятой плохо видно.
Таблица «Рождение»
ID персоны * дата * ID места рождения * ID отца * ID матери * ID источника.
Таблица «Крещение»
ID персоны * дата * ID церковного прихода * ID священника (который является такой же персоной, как и все другие) * имя крестимого (крестить могут по одному, а звать по другому) * ID одного воспреемника * ID второго воспреемника * ID источника.
Таблица «Сословие»
ID персоны * социальный статус * год * ID источника
Таблица «Место жительства»
ID персоны * ID места жительства * год * ID источника
Таблица «Место работы и должность»
ID персоны * Место работы и должность * год * ID источника
Таблица «Вероисповедание»
ID персоны * Вероисповедание * год * ID источника.
Таблица «Браки»
ID жениха * ID невесты * Дата * ID прихода * ID священника * ID поручителей (несколько клеток) * ID источника.
Таблицу про рождение детей делать не надо, потому что при вводе информации о рождении ребенка его связь с родителями задается.
Таблица «Смерти»
ID персоны * дата * ID места смерти * причина смерти * исповедь и причастие (да или нет) * ID священнослужителя * ID источника
Таблица «Похороны»
ID персоны * дата * ID места погребения * ID источника.
Таблица «Размер капитала» (для купцов)
ID персона * дата * размер капитала * ID источника
Таблица «Выбыл»
ID персоны * дата * ID населенного пункта * причина * ID источника
Таблица «Прибыл»
ID персоны * дата * ID населенного пункта * причина * ID источника
Вводить таблицу «Возраст» не имеет смысла, возраст будет высчитываться из даты рождения (а дата рождения из возраста) при введении или выведении информации, только надо учесть, что дата может быть точной, а может быть и не точной, надо ввести обозначение для приблизительной даты или диапазона дат – около, между, до, после.
Ну, я уже много написала, теперь вы что-нибудь скажите!!!

Ну для места и епархий тоже не должно быть сложности.
У всего есть своя история.
Начало, ход событий, конец.
По этому принцыпу можно и вести справочники селений и епархий, которые были приписаны к более высокому рангу (волости, уездам, губерниям также и для приходов). Для каждого уровня структуры нужен свой справочник. И каждую историю единицы привязать ко времени. Во завернул...

Людмила,
насколько я понял из вашей дискуссии, тот проект, который вы задумали, тремя настольными компьютерами с СУБД типа MS Access (слишком уж ограниченные ресурсы) не осуществить. Без более серьёзных СУБД типа DB2 или Oracle, без систем сообщений и развитой коммуникационной структурой глобальной задачи (хотя бы по России) не решить.
Конечно же, похвально, что вы занимаетесь первичным сбором информации для будущих генеалогических банков данных. А в этом, думаю, Access'а и должен помочь. Т. е. , фактически вы пытаетесь создать программное обеспечение для клиентской части глобальной системы.
Здесь мне мыслится, что должна быть реализована модель пополнение базы данных из двух этапов.
Поясню свою мысль. Определяем объекты генеалогического исследования. Первый - персона, второй - географический объект, 3-ий - время (даты, исторические события), 4-й - исторические источники (письменные, устные). По этим объектам строим соответствующие им базы данных. Далее должен быть создан софт, однозначно идентифицирующий персону, связывающий его с базами данных источников, событий, населенных пунктов. На основе информации из этих баз строится абсолютная база персоны, отражающая его основные характеристики.
Связь с историческими событиями уже устанавливает генеалог с помощью соответствующего софта, и эта связь также отражается в базе персоны.
Не совсем понятна мне идея с событиями. Ведь трактовка событий может быть неодназначной. Казалось бы, что рождение человека - определенное событие. Но сколько за этим событием кроется тайн (искаженные даты рождения, место, родители неизвестно откуда...)
Вот такие мысли вслух. Вероятно, каждый мыслит что-то о своём, но высказанные прилюдно соображения на этот счет могут привести и к интересным разработкам ...
С уважением ко всем.
Игорь Якунин.

Необязательно делать три-четыре базы данных.
Достаточно одну. База данных, не есть одна таблица, они из таблиц состоит, как я понимаю.
Я опять о своем, в футбольной базе данных все заполняется, как "соты", не зависимо от отсутствия какой либо сопричастной информации.
Можно оставить футболиста без года рождения, а затем, при обнаружении можно поставить и год и дату. Так же там без труда можно проследить переименования городов, переходы игроков из команды в команду во времени. Т.е. я к чему, все это возможно применить и к персоне во времени. И не обязательно применять инструменты как DB2 и Оракл.

Ну, про программирование баз данных я ничего не знаю. Если бы знала, сама бы все сделала

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

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

Ну а теперь о грустном.
Я никак не могу сообразить, как сделать кусок базы про административно-территориальное деление. Как раз Роджеру-то это, думаю, не нужно, он свои исследования наверняка проводит по ограниченному числу населенных пунктов, может их просто в базу внести, а мне нужно для сайта...
Вот смотрите, во-первых, менялась сама страна. Даже если не углубляться уж совсем вглубь веков (а хочется), это Российская империя, то, что было после революции (не помню так сразу как это называлось, вы помните?), СССР, и много независимых государств. Менялась территория этой страны, часть времени в ее состав входили Финляндия и Польша со своими населенными пунктами. Уже возникает вопрос, нужно ли вносить в базу населенные пункты Финляндии и Польши, вроде, нужно. Значит, сюда добавляется еще административно-территориальное деление и этих стран, точно так же как и современное деление стран ближнего зарубежья. Но это я вперед забежала.
Если считать название страны частью базы первого уровня (то есть первое ID - страны), то второй уровень тоже меняется. Ну, допустим, в СССР вторым уровнем можно считать республики, которые потом преображаются в независимые государства. До этого что? Ну, губернии, но они тоже группировались...
Ну не буду же я сейчас всю историю пересказывать!
Границы всего менялись, часть территории отходила другим странам, часть возвращалась обратно. Населенные пункты переименовывались, сливались, затоплялись...
То есть история административно-территориального деления крайне динамична. Даже более динамична, чем история персоны, человек однозначно определеяем, а населенный пункт даже местом однозначно не определишь. Вот Оренбург, например, переносили несколько раз, первый раз его построили там, где сейчас город Орск, потом перенесли и построили там, где сейчас село Красногор, а уж только потом его построили там, где он находится сейчас, при этом на всех предыдущих местах он тоже назывался Оренбургом!
Поэтому всему я думаю. Пока не придумала. Может, подумаете тоже? Если не хотите, я все равно придумаю все, а вам не скажу

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

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

Первое, что приходит в голову