Моделирование архитектуры хранилища данных

Я пытаюсь создать хранилище данных в модели Star Schema... любая идея будет оценена по достоинству.

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

Каков наилучший подход к моделированию?

Пока у меня есть таблицы:

[КОД]

    Dimension Tables    Measure Tables
    ----------------    --------------
    DimEmployee           FactCRM
    DimProjects           FactTargets
    DimSalesDetails       FactRevenue
    DimAccounts
    DimTerritories
    DimDate
    DimTime

[/КОД]


sql star-schema-datawarehouse data-modeling
person Chris Singleton    schedule 07.04.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Размеры в схеме хранилища данных означают независимые объекты, например, например

 Dim_Employee
Empid(pk) 
Name
Address etc likewise all other 
dimensions

С ключами каждого измерения, связанными с вашим фактом, как в приведенном выше случае.

   FactCRM would include only crm 
   related measures and would be linled
  To their specific dimensions depending 
   upon the requirements

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

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

person Himanshu Ahuja    schedule 07.04.2020