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

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

Мы запутались, по-моему. Поскольку эта тема мне кажется очень интересной, начну сначала

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

Стандартный подход к "структуре базы данных" - предполагает, что в таблицах каждая строчка (одна!) соответствует одному объекту (того класса, который описывается этой таблицей);
каждое поле таблицы ("колонка") соответствует некоторому свойству (одному!) объектов (того класса, который описывается этой таблицей);
а значение, хранящееся в данном поле данной записи - соответствует значению этого свойства у этого объекта.
Однако когда я вижу список из 35 полей (как тот, что привел выше RODGER), у меня возникает уверенность, что такая архитектура уже не проходит!
___________________________

Однако, есть и другой подход к построению (и ИНТЕРПРЕТАЦИИ) записей и полей таблицы, основаный на том, что каждая строка таблицы описывает не объект, а отношение объект-свойство.

Такая таблица содержит всего 3 (!) поля:
1. идентификатор объекта
2. идентификатор свойства
3. значение, принимаемое этим свойством "на" этом объекте.

Отдельно создаются две таблицы-справочника:
1. таблица объектов (формат: [идентификатор объекта],[имя (основное) объекта]) и
2. таблица свойств (формат: [идентификатор свойства],[имя (основное) свойства]).

В этом подходе имеется практически НЕОГРАНИЧЕННАЯ СВОБОДА в выборе свойств, которые мы хотим хранить в базе: 35 - так 35, 100 - так сто ...
___________________________

Таблицы "обычного" формата (одна строка = один объект) получается в этом подходе как CrossTab-запрос ...

Ориентироваться на Роджера мысль совершенно правильная - он как раз тот самый профессиональный генеалог, который будет использовать эту базу

Надеюсь, не он один

Но мне кажется, что первый вариант возможен.
Есть типовые события - рождение, смерть, крещение, прибыл, убыл... ну и еще какие-то, которые писал Роджер. Каждое это типовое событие предполагает, что у него есть несколько параметров. Ну, например, рождение предполагает связь с датой, местом, родителями. Крещение предполагает связь с датой, местом, приходом, восприемниками, священником... Можно на каждое это событие заводить отдельную таблицу.
То есть, допустим, таблица - рождение.
В первой колонке ID персоны, во второй дата, в третьей место, в четвертой папа, в пятой мама.
Таблица - крещение.
В первом столбце стоят идентификаторы окрещаемой персоны, во втором дата, в третьем место, в третьем приход, в четвертом - идентификатор священника, в пятом... кто там дальше?
Ну и все-таки, мне кажется, надо заводить отдельные таблицы на приходы и населенные пункты, чтобы в эти таблицы тоже попадали только их номера.
А как применять второй способ мне непонятно. Потому что ни одно свойство персоны не остается постоянным, ну, кроме пола

Может быть

Все остальные меняются.

В моем словоупотреблении "свойство" = "предикат", то есть - ЛЮБОЕ СКАЗУЕМОЕ.

А если свойство меняется, то его значения нужно хранить вместе с указанием ПЕРИОДА, в который данное значение свойства имело место. Только так и никак иначе.

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

. Вот завтра днем возьму все, что Роджер написал и попробую написать, к чему это сводится... Если он сам до этого этого не сделает

Ага ... только не забудьте к каждому полю свойства, которое - по Вашему мнению - "у персоны не остается постоянным", добавить еще ДВА поля даты:
[начиная 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 источника
Вводить таблицу «Возраст» не имеет смысла, возраст будет высчитываться из даты рождения (а дата рождения из возраста) при введении или выведении информации, только надо учесть, что дата может быть точной, а может быть и не точной, надо ввести обозначение для приблизительной даты или диапазона дат – около, между, до, после.
Ну, я уже много написала, теперь вы что-нибудь скажите!!!

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