タグ付けされた質問 「data-warehouse」

新しいデータウェアハウスの設計を開始したばかりで、日付と時刻のディメンションがどのように機能するかを設計しようとしています。複数のタイムゾーン（おそらく少なくともGMT、IST、PST、EST）をサポートできる必要があります。最初は、おそらく15分の粒度まで1つの広い日付時刻ディメンションを組み合わせると考えていました。これにより、ファクトテーブルに1つのキーがあり、サポートされるすべてのタイムゾーンのすべての異なる日付時刻データが1つのディメンションテーブルに含まれます。（つまり、日付キー、GMT日付、GMT時間、IST日付、IST時間など...） キンボールは、テーブルが大きくなりすぎないように（データウェアハウスツールキットp。240）、時間ディメンションとは別の日ディメンションを使用することを推奨していますが、これは、各タイムゾーンのファクトテーブルに2つのキーがあることを意味します。サポートする必要があります（1つは日付用、もう1つは時刻用）。 私はこの領域で非常に経験が浅いので、誰かが2つのアプローチ間のトレードオフ、つまりパフォーマンスとすべての異なるタイムゾーンキーの管理のトレードオフを知っていることを望んでいます。おそらく他のアプローチもあるかもしれませんが、ファクトテーブルにタイムゾーンごとに別の行があることを話している人を見たことがありますが、ファクトテーブルが数百万の行である場合、タイムゾーンを追加するためにそれを4倍にする必要があるという問題のようです。 15分の粒度を使用すると、日付時刻ディメンションテーブルに1年あたり131,400（24 * 15 * 365）行が含まれます。これは、パフォーマンスにとってそれほどひどく聞こえませんが、いくつかをテストするまで確実にはわかりません。プロトタイプクエリ。ファクトテーブルに個別のタイムゾーンキーがあることの他の問題は、クエリが目的のタイムゾーンに基づいてディメンションテーブルを別の列に結合する必要があることです。これはおそらくSSASが処理しますが、よくわかりません。 どんな考えにも感謝します、-Matt

10 sql-server  ssis  data-warehouse  ssas  dimensional-modeling 

インデックスについてこのウェブサイトからの質疑応答を読んだ後、疑問が浮かびました。 もし、1日がより細かいレベルの時間ディメンションテーブルを使用しているとしたらどうでしょう。インデックスはどこに置くべきですか？ 質問のランディ・メルダー：RDBMSで「インデックス」とはどういう意味ですか？言った： インデックスを「目次」と考えてください...これは、ファイル内の位置へのポインタ、つまりオフセットの順序付きリストです 時間ディメンションの場合、ほとんどのデータ調査は特定の日、特定の週、特定の月、または特定の年のすべての日がタイムテーブルに保存されている場合は特定の四半期に対して行われる可能性があります。 私の質問は、これらすべてのフィールドにインデックスを設定する必要がありますか？ 日は一意であると想定されているため、この日についてはインデックスの使用を完全に理解しています。ただし、週IDには7回、月IDには30/31回、四半期IDには120回程度の発生があります。 それらのフィールドにインデックスを付ける必要がありますか？ それはまだ役に立ちますか？ 同じ質問で、David Spillettが言ったので、私はあなたに尋ねます： インデックスを追加することは、もちろん最適化の悪い結果になる可能性があります。インデックスを格納するために使用される余分なスペース（および、DBが多数の書き込み操作を確認した場合にインデックスを維持するためのIO負荷）は、わずかに最適化されていない読み取りクエリよりも悪い問題である可能性があるためです。 、無理しないでください。 それでは、時間ディメンションの場合の最良の考慮事項は何でしょうか？

10 database-design  index  data-warehouse 

私は、既存のリレーショナルデータベースシステムからデータキューブを作成する必要がある新しいプロジェクトに関与しています。 既存のシステムは適切に設計されていません。どこから始めればよいかわかりません。 私の質問は： スタースキーマとデータキューブの違いは何ですか？ どこから始めなければなりませんか？スタースキーマからですか、それとも直接データキューブですか？ データキューブはスタースキーマから生成されますか？ リレーショナルデータモデリングの経験はほとんどありません。この質問は基本的なもののように思えるかもしれません。いくつかのリソースから理解しようとしましたが、まだ明確ではありません。アドバイスや提案をお願いします。 私がこの質問に関連して非常に重要な何かを見逃した場合は、それについてのあなたの考えも共有してください。

10 database-design  data-warehouse 

これらの明確な定義や説明は見つかりません。どちらも分散型のようです。フェデレーテッドDWHでは、データは分散され、単一のリポジトリに統合されず、分散ソースからアクセスされるようです。 分散型DWH実装では、データは1つの中央リポジトリに統合されます。 これら2つの実装の違いを説明してください。

9 data-warehouse  terminology  distributed-databases 

最初は1 TBで、毎月約20ギガバイト成長するデータウェアハウスを構築しています。 特定のテーブルについては、毎日ETLプロセスを行っており、他のテーブルについては毎週/毎月行っています。 テーブルへのデータインポートがある場合、インデックスを削除して再作成する必要がありますか？ インデックスを削除して再作成するポイントはありますか、それとも自動的に更新されますか？ 統計は自動的に更新されるように設定されています。 あなたの助けと指導を本当にありがとう。 私はこの天才的なスクリプトを得ました： SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' + CASE WHEN ps.avg_fragmentation_in_percent > 40 THEN 'REBUILD' ELSE 'REORGANIZE' END + CASE WHEN pc.partition_count > 1 THEN ' PARTITION = ' + …

9 sql-server  sql-server-2008  data-warehouse 

私はデータマートの設計に不慣れで、いくつかの概念をクリアする必要があります。 ファクトテーブルにディメンションテーブルへの外部キー参照が格納されていることがわかるディメンションモデリングについて少し読んだことがあります。 ここで、phonenumberディメンションテーブルとphone_extensionディメンションテーブルがあるとします。（これらの表は、詳細が異なるため、組み合わせることができません） 私が理解しているように、これらの両方のディメンションテーブルには、パフォーマンスを向上させるための整数主キーがあり、ファクトテーブルには独自の整数主キーがあり、これらのディメンションテーブルへの外部キー参照も格納されます。 しかし、すべての電話番号に関連するphone_extensionがあるわけではない状況があるとします。（一部の電話番号には内線が必要ありません） 内線番号を持つ電話番号の場合、ファクトテーブルには両方のディメンションテーブルへの外部キー参照がありますが、電話番号のみで内線番号がない（およびその逆、つまり電話番号のない内線番号）状況をどのようにキャプチャしますか？ 値とphone_extension外部キーがnullであるファクトテーブルの電話番号FKでこのような情報をキャプチャする必要がありますか？または、そのような非関連オブジェクトがファクトテーブルに記録されていませんか？ また、このデータマートのレポートを生成する必要があります。それでは、まずファクトテーブルをクエリしてディメンションキーの値を取得するか、ディメンションテーブルから直接レポートを作成しますか？ これを読んでくれてありがとう！ 助けてくれてありがとう!!

9 database-design  data-warehouse 

ターミナルでのコンテナの入口と出口を追跡する累積スナップショットファクトテーブルがあります。 コンテナーは3つの異なる方法で出入りできるので、これら3つの可能な方法（列車、船舶、またはトラック）をリストする特定のディメンションテーブルを作成することを考えました。 それから私はこのテクニックを間違っていると基本的に言っているこの記事を読みました、しかし私はその理由を理解できません。 最初の記事： ファクトテーブルに、個々の行にまばらに入力されているファクトの長いリストがある場合、ファクトテーブル行をメジャータイプディメンションで識別される単一の汎用ファクトに折りたたむメジャータイプディメンションを作成したくなることがあります。通常、この方法はお勧めしません。空のファクト列はすべて削除されますが、ファクトテーブルのサイズに各行の占有列の平均数が乗算され、列内の計算がはるかに困難になります。この手法は、潜在的なファクトの数が（数百単位で）極端な場合に許容されますが、特定のファクトテーブル行に適用できるのは一握りではありません。 「メジャータイプディメンション」がトランザクションファクトテーブルに実装されている場合、この他の記事にあるような問題が発生する可能性があることは理解していますが、スナップショットファクトの蓄積に使用してもマイナス面は見られません。 2番目の記事：（ 「メジャータイプディメンション」の実装のいくつかの欠点） [...]「メジャータイプディメンション」を使用すると、この分析能力が失われます。1つのメジャーが他のメジャーと互換性がない場合、それらを合計することはできません。 [...]レポートを作成するためにSQLが実行する必要のあるパスの数が多いほど、レポートは遅くなります。 [...] BIツールでメジャータイプフィルターを配置しない場合、ユーザーが「ゴミ情報」を取得する危険があります。使いやすさの観点から見ると、このデザインはごみです。 Mark Storey-Smithの回答への応答 とても素敵なアプローチ、私はそれについて考えたことはなかったでしょう。 もう1つ：コンテナをターミナルに持ち込む車両のすべての出入り口には一意のIDがあり、次のような情報が得られます。車両の到着予定、実際の到着、船の場合はドック、トラックの場合は料金所、他の多くの情報... これらは3つの異なるファクトテーブルであり、何らかの方法でコンテナファクトテーブルにリンクする必要があります。 航海のIDはであると思ったdegenerate dimensionので、コンテナのファクトテーブルに直接入力します。だから、私の疑問は：コンテナーファクトテーブルに6つの異なるフィールド（vessel_voyage_in_key、vessel_voyage_out_key、train_voyage_in_key、train_voyage_out_key、truck_voyage_in_key、truck_voyage_out_key）または他の2つのフィールド（voyage_in、voyage_outに動的にリンクするvoyage_out）を追加する必要があるかどうかです。 私の疑問が明確になれば幸いです、ありがとう。

8 database-design  data-warehouse 

計画中のデータウェアハウスアップグレード用のデータウェアハウスサーバーの仕様を記述しようとしています。 VMWareホストで仮想サーバーを実行すると、必要に応じてリソースを追加または削除できます。以前は、必要に応じてRAMとCPUを段階的に追加していました。需要が高まるにつれて、より多くのリソースを求めてロビー活動を行ってきました。（主にディスクとRAM）。 もっとお願いします。彼らは私たちにできるだけ少ないを与えます。 しかし、最近リソースについて話すときはいつでも、そもそもマシンを正しく指定していないと非難されており、開発ホストが使い果たされていると言われ、RAMはもうありません。 私たちは小さな地方自治体の組織であり、DWを50人まで定期的に利用しています。通常の日常使用では問題なく動作します。mdxクエリのパフォーマンスは良好で、レポートとダッシュボードは高速です。ユーザーは満足しています。 ただし、ETLプロセスは夜通し実行されるため、データマートを同時に処理すると、メモリプレッシャーの兆候が見え始めています。昨夜、SSISは「メモリ不足エラー」に関する警告で失敗しました。 私たちの既存のDWサーバーは4つのCPUと16GbのRAMを搭載したWin 2008 R2で、SQL 2012 Stdを実行しています。私が持っている最大サーバーメモリ等の当社の既存のDWは3マート/ OLAPキューブを持っており、我々はより多くの2を開発しているOSおよびサービスのための4ギガバイトを残して、12ギガバイトのセットを。 +----------+----------+---------------+-----------+---------------+ | Datamart | Files GB | Fact (Rows) | Fact (Mb) | ETL & Process | | OLAP cube| | | | Time (hours) | +----------+----------+---------------+-----------+---------------+ | PBI | 3 | 190,000 | 180 | 0.2 | …

8 sql-server  data-warehouse  windows-server-2012  sql-server-2016 

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 

データウェアハウスにはSQL Server PDWアプライアンスを使用しています。ウェアハウス内のテーブルの1つは、約2,000万行の複製されたテーブルです。ETLプロセスの一部として、このディメンションの古いレコードを期限切れにする必要があります。ただし、少数のレコード（<100）の更新が完了するまでに1時間以上かかることがわかります。これは、できれば改善したいことです。 当然、私が考えた1つのオプションは、このディメンションを複製から分散に変更することでした。私のテストでは、ETLプロセスに時間がかかる（1.5時間から30秒に短縮された）問題が修正されることを示していますが、結合がほとんど同じ分布に基づいていないため、このディメンションの分散バージョンに対するすべての結合が影響を受けます。カラム。これらのクエリのいくつかの実行プランを見ると、通常、ShuffleMoveまたはBroadcastMove操作のいずれかが表示されます。 ここにあるPDWの第一人者に対する私の質問は次のとおりです。 このディメンションの複製バージョンでレコードを更新するパフォーマンスを向上させるために他にできることはありますか？ 繰り返しになりますが、分散テーブルへの移行は、他の人が開発した何百ものSQLクエリやレポートに影響を与えるため、最善の解決策ではないようです。

8 sql-server  data-warehouse  sql-server-pdw 

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

8 data-warehouse  dimension 

Sql Server 2012には、Enterprise Edition、Business Intelligence、Standardの3つの主要エディションがあります。 3つの完全な比較：http : //www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx ビジネスインテリジェンスエディションは、その目的がデータウェアハウジング用であることを意味し、そのための主要な懸念事項と思われるものをカバーしています。 セルフサービスビジネスインテリジェンス（アラート、Power View、PowerPivot for SharePoint Server） 高度な企業BI（表形式のBIセマンティックモデル、高度な分析とレポート、VertiPaq™インメモリエンジン） 高度なデータ統合（ファジーグループ化とルックアップ、変更データキャプチャ、高度なデータマイニング） エンタープライズデータ管理（データ品質サービス、マスターデータサービス） ただし、エンタープライズエディションは次のバージョンのみです。 データウェアハウジング（ColumnStoreインデックス、圧縮、パーティション化） これには、BIエディションとエンタープライズエディションに分離された機能が含まれますか？

8 data-warehouse  sql-server-2012 

インメモリOLAPエンジンは、キューブ全体を格納するのに十分なRAMに支えられた従来のOLAPエンジンよりも優れていますか？ たとえば、MOLAPエンジン（SSAS）とGB / TBのRAMを使用していて、キューブ全体（またはスタースキーマも）がRAMに常駐している場合、TM1 / SAP HANAと比べて何が違うのですか？

8 data-warehouse  business-intelligence  olap  in-memory-database 

MSSQL 2008 R2 Standardでデータベースを作成し、そこに多数のレコードを格納します。毎年1つのテーブルで2億件以上のレコードを見積もり、主にデータのUPDATEまたはDELETEをほとんど行わずにINSERTを実行しています。これは、履歴レコードを毎日挿入するデータアーカイブシステムです。ユーザーの要求に応じて、この履歴レコードに関するさまざまな種類のレポートを生成するため、いくつかの懸念があり、技術的な入力とアドバイスが必要です。 この種のアーカイブテーブルとデータベースを管理する最良の方法は何ですか？

8 sql-server  database-design  database-recommendation  data-warehouse