Моделирование измерений: нужна помощь в создании этой звезды для университета

Я новичок в моделировании измерений и работаю над созданием модели измерений для университета. Текущий бизнес-процесс, который я изучил, — это продажа/доход. Я читал разные главы в разных книгах, и хотя я думаю, что хорошо разбираюсь в фактах и ​​измерениях, мне трудно приспособить процесс продаж к бумаге.

В идеале процесс продаж в школе аналогичен другим предприятиям, где студенты являются клиентами, а продуктом являются «курсы», которые они проходят. Однако в определенных ситуациях существуют разные типы продуктов, и я не знаю, как подобрать тип продукта. Например, студент платит сбор за подачу заявления, сбор за опоздание или сбор за запрос стенограммы, который не связан с каким-либо курсом. Как мне вписать эти различные типы потоков доходов в мою звезду?

То, что я сделал до сих пор, похоже на это

Sales_FACT
====
Date_Key_FK
Product_Key_FK
Campus_Key_FK
Student_Key_FK
ChargeCredit_SKU
Amount


Product_Key
------
Product_Key_PK
SectionID
AcademicYear
AcademicTerm
AcademicSession
CourseCode
CourseName
ProductType???

Теперь для определенного типа продуктов (например, плата за запрос стенограммы) - у меня нет названия курса, кода, срока года, сеанса - я изо всех сил пытаюсь понять, как это будет работать.

У кого-нибудь есть какие-либо данные по этому поводу? или любые полезные примеры материалов/схем, безусловно, оценят их

Спасибо,


database data-warehouse dimensional-modeling database-design
person user18620    schedule 19.08.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы найдете много таких случаев в будущем. Обычно эта проблема возникает из-за того, что в вашем случае вы смешиваете два разных типа «продукта».

Это может быть решено логически или технически.

Во время процесса ETL на этапе очистки вы можете переписать свои пустые поля с помощью sql (nvl, объединение, CASE WHEN) с чем-то, связанным с полем

nvl(CourseCode, 'No Course Code') as CourseCode

Затем, когда вы группируете по ProductType и CourseName, вы должны получить что-то вроде этого:

ProductType     CourseName     sum(Amount)
------------------------------------------
AppFee          Course1             345.13
AppFee          Course4            8901.00
TranscriptFee   No Course Name      245.99

Или вы можете поместить его в отдельные таблицы. Даже если это противоречит вашему бизнес-процессу (не может иметь разные продукты в строке фактов), иногда термины, которые вы хотите объединить (например, ApplicationFee и TranscriptFee), имеют много разных уровней группировки, которые часто слишком сложно сопоставить.

Изменить:

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

Product-Service Dimension
--------------------------------------------
SurogateKey
NaruralKey
Type(Product/Sevrice/Other)
Level1(ProductType/ServiceType)
Level2(ProductSubType/ServiceSubType)
Level3
Level4
Attribute1
Attribute2
person fenix    schedule 20.08.2014
comment
Спасибо за ответ. Вопрос в том, как вы разрешите эту ситуацию для компании, которая продает товары, а также услуги? Одинаков ли подход в этой ситуации? - Причина, по которой я спрашиваю об этом, если ответ заключается в том, чтобы хранить их в двух разных таблицах, как вы решаете бизнес-вопрос о том, каков доход за последние 6 месяцев по географическому местоположению? получить доход, если информация хранится в двух разных таблицах. Есть ли смысл идти в снежинку в такой ситуации? - person user18620; 20.08.2014