問題タブ [data-warehouse]

ファクト テーブルにキーがまったくないことはありますか? またはそれができる場合、それは良いデザインですか？ファクト テーブルにディメンションがない場合、どのような基準で分析されますか?

ファクト テーブルに主キーのみがあり、外部キーがない場合はどうなりますか?

ファクト テーブルの説明などのテキスト フィールドを使用できる場合はありますか?

私は現在、日付、クライアント、場所などの多数のディメンションを持つ会議イベント (粒度: 会議ごとの行) のファクト テーブルを持っています。会議の件名をファクト テーブルに入れる必要があります。対策ではないのですが、これでいいのでしょうか（例は見たことがありません）。事実と常に同じサイズ (行数) になるため、別の次元に移動することはできません。

過去の経験からのアイデアやアドバイスはありますか？

ありがとう

キューブで使用されているファクト テーブルが実際にはビューであることに気付きました。実際、それらはファクト テーブルのテンプレートでした (ファクト ビューに "where 1=2" が使用されていることがスクリプトでわかりました)。

そのため、テンプレートを使用すると、ビューにデータが表示されることはありません (ビューに挿入権限がないため、ビューに挿入できるかどうかはわかりません)。

ですから、私の質問は次のとおりです。立方体に見るべきものが欠けていますか? キューブは非常に経験豊富な開発者によって設計されており、私は単なる QA です。キューブ設計ペインは、テンプレートを使用していることを明確に示しています (DSV デザイナーの各長方形オブジェクトの黄色のヘッダーに示されているように)。ヘッダーに表示されているものとは対照的に、他のテーブル/ビューを参照できますか?

債券やローンなどの金融証券に関するデータを含む DW を作成しています。これらの有価証券は、支払スケジュールに関連付けられています。たとえば、債券は四半期ごとに支払うことができますが、住宅ローンは通常毎月 (場合によっては隔週) 支払うことになります。支払いスケジュールは証券の取引時に作成され、ほとんどの場合、変更されません。ただし、設計は変更される場合に対応する必要があります。

現在、このデータをモデル化しようとしていますが、実行可能な設計を思いつくのに苦労しています。最も一般的に照会されるフィールドの 1 つは、「次の支払い日」です。ユーザーは、証券が次に支払う時期を知りたいことがよくあります。したがって、証券ごとに次の支払い日と金額をできるだけ簡単に取得できるようにしたいと考えています。

また、ユーザーは履歴クエリを実行することが多く、その場合、特定の時点での次の支払い日と金額が必要になります。たとえば、2009 年 1 月 31 日を振り返り、次の支払い日 (住宅ローンの場合、通常は 2009 年 2 月) を照会したい場合があります。また、360 件のレコード (30 年間の住宅ローン x 12 回の支払い/年) で構成される証券の支払いスケジュール全体をクエリすることもよくあります。

次回の支払日と金額は毎月または隔週で変化するため、これらのフィールドはゆっくりと変化するディメンションにはうまく適合しないようです。おそらくファクト テーブルを使用する方が理にかなっていますが、それをモデル化する方法がわかりません。どんなアイデアでも大歓迎です。

データウェアハウジングについてもっと知りたいです。「ディメンション」、「スノーフレークスキーマ」、「スタースキーマ」などの用語が使われています。このことについてどこから学び始めますか？良い本やインターネットリソースはありますか？

ETLはこのスペースにありすぎますか？

「メタデータ管理」という用語が正しいかどうかはわかりません....

基本的に、あるクライアントが、データ ウェアハウジング プロジェクトに関して「メタデータ管理」ツールに関する推奨事項を求めてきました。この用語は、データ ディクショナリのようなものを作成することに関係していると推測していますが、この分野での経験が比較的少なく、無知な点から質問しています。

クライアントは現在、"メタデータ管理" 用の現在のツールとして Excel を使用しているが、もう少し堅牢なものを望んでいると聞いたことがあります (ただし直接見たことはありません)。

誰かがこの用語と、おそらくいくつかのオープン ソース ソリューションに光を当てることができれば、私はそれを感謝します.

MoinMoin のような無料のウィキを提案して、用語の「ウェブ」を作成できるようにするつもりでしたが、これが正しい方法かどうかはわかりません。

ソース トランザクション テーブルの ID 列または日時列を使用して、トランザクション システムからデータ ウェアハウスをロードする際にデルタ検出を実装しました。次回データを抽出する必要がある場合は、前回抽出された最大の日時値を抽出クエリのフィルターで使用して、新しいレコードまたは変更されたレコードを識別します。同じミリ秒で複数のトランザクションがあった場合を除いて、これで十分でした。

しかし、現在、SQL Server 2008 には変更データ キャプチャ (CDC) があり、長さ 10 のバイナリである LSN (ログ シーケンス番号) と呼ばれる新しいものを提供しています。今、私は混乱しています。ウィンドウ処理の目的で保存する必要があるデータ (LSN または日時)。もちろん、LSN を使用すると、大きなトランザクション テーブルに追加の日時値を格納する必要がなくなりますが、これには欠点がありますか? どちらを使用する必要がありますか? LSNを日時にマッピングしてから日時を保存することは、信頼できる方法ではないと感じています。あなたの意見は何ですか？

PS: BI の専門家でない方、申し訳ありません。

17 個のキーを持つファクト テーブルがあります。通常、私は主キーをすべての次元キーとして指定しています。MS SQL Server 2008 では、主キーまたは一意の制約で 16 列の制限があります。回避策はありますか?

データ ウェアハウスで、ファクト テーブルにクラスター化インデックスを作成することには欠点がありますか? (ほとんどの場合、日時列にあります)

「デフォルトで...」に「はい」または「いいえ」と答えますか?

デフォルトでクラスター化インデックスを作成すべきでないとしたら、それはなぜですか? (クラスター化インデックスの長所は知っていますが、短所は何ですか?)

参考文献

http://blogs.sqlserver.org.au/blogs/greg_linwood/archive/2006/09/11/365.aspx

OLTP に次のテーブル ルックアップ テーブルがあります。

これが OLAP に入ると、次のように構造を変更します。

私の質問は、TransactionStateId 列に関するものです。時間の経過とともに、OLAP で TransactionStateId 値が重複することがありますが、StartDateTime と EndDateTime の組み合わせにより、それらは一意になります。

OriginalTransactionStateId が追加され、着信 TransactionStateId がそれにマップされ、さらに新しい TransactionStateId IDENTITY フィールドが PK になり、結合に使用されるタイプ 2 ディメンションのサンプルを見てきました。

学士号 #2 または学士号 #3 を使用する必要がありますか?