タグ付けされた質問 「dimension」

SQL Server 2008データベースに日付ディメンションテーブルを設定することを検討しています。テーブルのフィールドは次のとおりです。 [DateId] INT IDENTITY(1,1) PRIMARY KEY [DateTime] DATETIME [Date] DATE [DayOfWeek_Number] TINYINT [DayOfWeek_Name] VARCHAR(9) [DayOfWeek_ShortName] VARCHAR(3) [Week_Number] TINYINT [Fiscal_DayOfMonth] TINYINT [Fiscal_Month_Number] TINYINT [Fiscal_Month_Name] VARCHAR(12) [Fiscal_Month_ShortName] VARCHAR(3) [Fiscal_Quarter] TINYINT [Fiscal_Year] INT [Calendar_DayOfMonth] TINYINT [Calendar_Month Number] TINYINT [Calendar_Month_Name] VARCHAR(9) [Calendar_Month_ShortName] VARCHAR(3) [Calendar_Quarter] TINYINT [Calendar_Year] INT [IsLeapYear] BIT [IsWeekDay] BIT [IsWeekend] …

8 sql-server-2008  data-warehouse  business-intelligence  dimension  star-schema 

私はDW設計にかなり慣れておらず、ITインフラストラクチャをモデル化するためにDWに取り組んでいます。 この時点での主要な問題/質問は、ドライブ情報をモデル化する方法です。 ファイルとフォルダの集計データと物理ドライブの個別データを収集します。ドライブ情報には、最低でも合計と空き容量が含まれ、週に数回更新されます。 答える必要があるビジネス上の質問の1つは、ドライブの使用状況が時間とともにどのように傾向にあるかです。ドライブ情報は、ファイル/フォルダーレベルまでの階層でも使用されます。 私が今見ることができるオプションは： DRIVEディメンションとして 実装 階層設計を簡素化 これによりレポートに問題が発生しますか？ディメンションのみの時間制限データを報告することは私には直観に反するようです また、データを更新するたびに変化することがわかっているディメンションがあることも問題のようです。 DRIVEファクトテーブルとして実装 レポートを簡素化 複雑な階層（？）- Driveデータを特定のサーバーまたはコンピューターにマップするためにも使用します。ファクトテーブルを階層の中間レベルとして使用することはできますか？そうは思いません。 DRIVEファクトとディメンションの両方として実装 ファクトには、キー、日付、およびスペースに関するファクトのみが含まれます Dimensionには、使用しているコンピューターなど、その他の非追加データが含まれます。 両方の問題を解決しているようですが、これはアンチパターンですか？

8 data-warehouse  dimension