Попытаюсь сформулировать вопрос.
Извиняюсь за пространность.
Есть подход, сформулированный аналитиками на картинке в виде кропа логической модели erwin (см.)

То есть, статические атрибуты Персоны принадлежат непосредственно сущности Персона, динамические вынесены в отдельные исторические таблицы с датами начала и конца периода актуальности. (Вопрос о том, что статические атрибуты Персоны, представленные на картинке, на самом деле не статические, пока не обсуждается, хотя и закономерен).
Причем для атрибута Гражданство (вернее там 2 атрибута - Вид Гражданства и Страна) заведена отдельная историческая сущность, для ФИО+ИНН - отдельная.
И так далее.
А вот у сущности Связь с документами (1:M) история ведется прямо внутри.

Соответственно на исторические записи по их UID-у могут ссылаться другие неисторические сущности. Например, Медкарта ссылается на историческую запись Персоны, дабы всегда можно было достать ФИО Персоны на тот момент времени на который она была заведена.

У меня вопрос о разумности такого подхода в физической модели (да и в логической в общем, тоже), то есть когда "историчность" жестко вшита в модель, существуют ссылки между сущностями историческая-неисторическая, историческая-историческая; при этом для сущности, скажем, Персона, заводятся несколько исторических сущностей (по одному атрибуту или по группе) с интервалами актуальности.

Схема, конечно, выглядит достаточно гладкой, но мне кажется - слишком много от решения "в лоб", настораживает количество операций соединения для получения информации о персоне, предполагаемая скорость каких-нибудь отчетов и т.п.

Второй вариант известен - хранить в Персоне ВСЕ атрибуты, а в ОДНОЙ исторической сущности снимать слепки записей из Персоны. Мне он кажется более разумным. Но меня больше интересует именно подход с хранением ссылок на исторические сущности - насколько он разумен.

Есть и третий вариант: одна сущность, для нее - одна историческая таблица-копия, в модели не указываемая вообще (но будет сгенерирована так как у сущности указан параметр UDP: IsHistorical). А ссылки хранятся "стандартным образом" - не на исторические, а на обычные сущности (Медкарта указывает на Персону) и только при построении запроса от клиента определяется что пользователь хочет вывести историческую запись, после чего делается соединение с Историей Персоны с учетом попадания в интервал дат.

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

Спасибо за внимание.

guest_20040621> У меня вопрос о разумности такого подхода в физической модели

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

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

ModelRИМХО оба два имеют право быть в одной модели, ибо обслуживают разные ситуации. Разумеется можно попытаться их (ситуации) максмально унифицировать ко второму (ссылки только на сущность) случаю как более простому. Однако первый вариант жестко ограничивает удаление исторических записей и имеет поэтому самостоятельную ценность.
Запросы же наверняка потребуются разные, даже при явной ссылке на историческую запись может потребоваться джойн по некоторой дате медкарты с данными истории персоны.


Действительно, здесь заложено некое "упрощение". Ориентация на разовый запрос с выводом данных Персоны на момент создания медкарты. Но если нужно вывести, скажем, всю цепочку изменений данных персоны с момента создания - уже сложнее.


Разумеется можно попытаться их (ситуации) максмально унифицировать ко второму (ссылки только на сущность) случаю как более простому.


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


По гражданству . Это само по себе М:М, так что историю имеет вид гражданства: Страна+Персона+Дата -> Вид. При этом пара Страна+Персона сама по себе не обладает значимыми атрибутами.
Я бы изобразил на модели это понятие, но не стал бы генерировать таблицу, пометив сущность Страна+Персона как только логическую. Для корретного переноса ссылок использовал идентифицирующие связи к Страна и Персона.


Правильно заметили, но с гражданством кстати здесь принята упрощенная модель, то есть Вид гражданства (росс., иностр., двойн...) плюс Страна в случае наличие граджанства иностранного государства.


Связь с документами (1:M) . Не ясно, что значит "история ведется прямо внутри"? не видно нам истории. Например, у документа будет продлен срок действия. Если имеется ввиду, что будет создана там же запись с новым UID Документа, то как понять, что это две записи про один документ?


Хм, верно, похоже, надо было другую сущность в пример...


Последнее. В логической модели с суррогатными ключами крайне важно указать альтернативные бизнес-ключи.


Оно понятно. Или Вы имеете в виду цветом в ErWin ?

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

WesttrdА фамилия - то в модели может с течением времени изменяться :)

И не только фамилия

Последнее. В логической модели с суррогатными ключами крайне важно указать альтернативные бизнес-ключи.


Оно понятно. Или Вы имеете в виду цветом в ErWin ?[/quot]Нет, ErWin может показывать альтернативные ключи как и первичные у атрибута в скобках.[/quot]

Действительно, они пока не заданы.

guest_20040621> история изменения метаданных "заложена но потом отложена"

Есть два основных подхода к реализации истории изменений: 1. основанный на данных и 2. основанный на метаданных. Они вообще ничем не похожи, кроме созвучного названия. Если Вы говорите, что сейчас планируется реализовать 1., то переход к 2. потребует полного переписывания кода.

Принципиальная разница между этими подходами в том, что в 1. структура данных предполагается неизменной (точнее не так: однажды описанные сущности неизменны; никто не мешает добавлять описания новых сущностей), в 2. таких требований нет. Если аналитик Вашего проекта полагает, что описываемые сущности неизменны, - это его решение. ;) Я бы воздержался от таких допущений.

> С "видеть ТЗ" сейчас проблематично

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

Аналитик действительно считает структуру данных (тех, для которых хочет обеспечить историчность) неизменной ввиду ее неизменности в течение скольких-то там десятков лет. Другое дело, что наше ядро метаданных заточено под обработку как раз изменяющихся сущностей. Мы хотели бы его использовать, но для хранения полноценной истории действительно надо бы расширить его механизм с учетом вышесказанного. Это не очень просто.

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

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

ModelR"Нельзя дважды войти в одну и ту же реку"
"Чем больше все меняется, тем больше остается неизменным"
выберите правильный вариант :)

Все зависит от Вашего приложения. Смена пола влечет утрату имущественных прав? повышение в должности? расторжение брака?
Что для вас важно?

ИМХО можно считать тем же человеком. Если считать другим, все равно нужно старого и нового связать и в некоторых случаях по этой связи углубляться в историю.

Мне сложно представить реальную ситуацию, когда бы смена пола требовала создания новой персоны. Повышение в должности этого ИМХО не требует (приведено как быстрый пример, понимаю). А вот какое-нибудь членство в мужских клубах о котором персона со сменой пола хотела бы забыть - может быть. Впрочем и здесь соответствующие связи в таблицах при смене пола можно просто удалить ...

Я бы подошел более прагматично - если после смены пола мы можем свести в одной комнате и поставить рядом две персоны - которые "до" и "после" - то да, нам таки удалось создать вторую персону (и запись в БД).

guest_20040621>
Я не знаю, что Вы проектируете, но предположу: под полом Вы подразумеваете просто запись в документе, удостоверяющем личность (паспорте). Что есть пол в его естественном смысле? Совокупность признаков, характеризующих определенного представителя определенного биологического вида. Смена пола предполагает изменение очень незначительной части этих признаков. Собственно, откуда взяться новой персоне? ;)

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