странно - не знал что такие вещи модно называются.

делаешь обычно, чтобы юзеру конечному удобно было

а оно во как

Ну тут спасибо Линдштеду за формализацию

И это не просто костыли

Там тоже есть требования

А то что "пользователю удобно" - это уже слой витрин

А есть где обзор всех разных подходов, с плюсами-минусами?
Аналог Фаулера, но для КХД

https://4pda.ru/2020/05/21/371575/ интересный с точки зрения построения решения проект

Больше баз данных богу Баз данных

Вообще, прям в книге сказано, что надо оперировать бизнес сущностями

Не помню правда, вроде это было в 2.0

Мить, имеешь в виду в одно отношение, например ФИО?

по разным полям ?

Нене, я про другое. В DV самом основном волте должна лежать информация, которую ты собрал. Это ядро. А дальше у тебя есть эвристики, которые ты додумал.

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

Поэтому такие фишки, а также связи построенные на них, выносят в структуру business vault. Если вдруг свойства бизнеса изменятся - BV может утратить актуальность, а DV ядро - нет (если строили по всем правилам)

Хм, интересное решение, но тогда не совсем понятно, получается BV, это пристройка сбоку к DV?

Отношение = таблица. Например у тебя один источник по сущности «человек».  И ну ты знаешь, что источник у тебя всегда будет содержать по людям какую-то базовую инфу. Типа фио, должность, email. Такие вещи можно положить в один «сателит»

Ну да, так и есть

Но там очень много всего полезного туда кладут

Мить -  у меня был курс реляционной алгебры. повезло :)