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

Вопрос, в каком виде оптимальнее хранить историю? Есть два варианта, как я понимаю

1) Создать одну таблицу с данными (таблица фактов) и делать в нее срезы каждый день. Будет происходить накопление данных, но это может занимать много места.

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

Каким образом предпочтительнее хранить историю добавления данных? Может быть, есть еще варианты о которых я не знаю?

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

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

PS/ время есть, спасибо - изучу-)

д0kХMr_MuscleСтоит задача, спроектировать схему таблиц для хранилища данных.
Требуется отслеживать все изменения в данных, которые будут поступать в базу раз в сутки.


Раз в сутки , это прошлый век.
Уже лет 10 как бизнес уходит в реалтайм.
А тот кто не уходит, непоспевает за трендами, и потенциальный банкрот.
Особенно критично, если это логистика продаж.

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

Раз в сутки - это достаточная периодичность для данного случая. Данные будут использоваться для составления отчетности в госорганы.

Alexus12Автор,
1) обязательно прочитай рекомендованную ссылку, особенно Facts and Dimensions
http://docs.oracle.com/database/122/DWHSG/data-warehouse-logical-design.htm#DWHSG9234
дальше дели свои входящие данные на Facts \ Dimensions, факты складируй по срезам, измерения делай медленно меняющиеся - https://en.wikipedia.org/wiki/Slowly_changing_dimension типа 2,
джойны факт-измерение будут выглядеть так:

fact.id_dimension = dim.id_dimension
and fact.ddate between dim.start_date and dim.end_date

2) некоторые редко меняющиеся или долго длящиеся факты можно хранить в виде scd type2 - это может сильно экономить место

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

andrey_anonymous,

Получается, что мне больше подходит 6 способ

Если есть таблица
----------------------------------------------------------------------------
Supplier_key | Supplier_Code | Supplier_Name | Supplier_State
----------------------------------------------------------------------------
123 | ABC | Acme Supply Co | CA
124 | ABC | A & J Supply Co | IL


То к ней таблица истории с такими колонками:

Supplier_key
Supplier_Code
Supplier_Name
Sup_Name_Start_Date
Sup_Name_End_Date
Sup_Name_Change_Cause
Sup_Name_Change_User
Supplier_State
Supplier_State_Start_Date
Supplier_State_End_Date
Supplier_State_Change_Cause
Supplier_State_Change_User


Не херня ли получается, товарищи?

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





Аналогично - другие таблицы, на которые может ссылаться Deals. Для вывода всего этого делать витрины данных по запросу. Так не очень хернёй выглядит?

andrey_anonymousMr_Muscleхернёй выглядит?
Выглядит.
Со ссылками - точно оно.

А почему?

andrey_anonymousMr_MuscleА почему?

Исторические записи id={5,6} куда ссылаются? А id={1,2}?

Ну, на SELLER_ID {1,2} и соответственно BUYER_ID {5,6}

andrey_anonymousMr_MuscleНу, на SELLER_ID {1,2} и соответственно BUYER_ID {5,6}
Пора уже что-нибудь почитать из теории реляционных БД.
Хотя бы основы.

Читаю-читаю много, пока видимо не помогает! пожалуйста, объясните что здесь не так.

Не внял что-то...andrey_anonymousпропущено...

Начнете запросы к этой... гм... структуре писать - поймете.
А почему одно на одно и то же измерение не могут сслылаться несколько разных столбцов фактов? Как это влияет на запросы?

Хороший вопрос!!!

Sintetik,

Простите, не совсем понятно.. можно чуть чуть подробнее?