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

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

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

Кто нибудь описывал требования к ХД при возможных изменениях содержимого классификатора? То есть изменение граней куба, и его постройки? Что включает в себя сей процесс. И еще как проектируется к примеру нахождение маржи от определенного производителя.

Работал только с oltp. Сейчас вешаюсь от олапа.

Кот Матроскин,

Спасибо. Просто вся загвоздка и есть в том, что не получается построить куб из двух данных этих систем, т.к. они не связаны.

Dimitry Sibiryakov,

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

Dimitry Sibiryakov,

Речь идет о физической реализации таблиц для ХД, в которой есть одна таблица фактов и ее окружают измерения, при этом схема полностью денормализована.

Потом на основе звезды строится куб. Как слить две базы от двух систем в одну. Вот в чем вопрос. На этом конкретном примере.

Бредятина,

Полностью согласен, однако мне пока неясно как данные перенести, не то что говорить про сделать еще лучше. В общем тяжело и непонятно. Делить системы на уровне OLTP нет смысла, так как первая это CRM, вторая это отчетность.

Dimitry Sibiryakov,

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

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

Dimitry Sibiryakov,

Жаль что сложилось такое впечатление. Я не работал с хранилищами потому и такие проблемы в понятиях. обычные бд гораздо проще в освоении и терминах. а по хд ни кимбалла ни инмона ничего на русском нет.

Dimitry Sibiryakov,

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

londinium,

Ну я имел ввиду что то типо flow fields в навижн. Походу был не прав. А вкратце тогда что понимается под агрегатами? Это же термин OLAP?

londinium,

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

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

Dimitry Sibiryakov,

То есть из двух систем достаточно сделать сводную таблицу агрегатов, на исходные таблицы навесить триггеры на обновление полей. Я прав?