自社のBIシステムをゼロから開発しており、現在はデータウェアハウスの設計を行っています。全くの初心者で分からない事が多々ありますので、今後ともよろしくお願い致します。
私の問題は次のとおりです。
1) ソース システムには、「Booking」および「BookingAccess」というテーブルがあります。予約テーブルには、チェックイン時間とチェックアウト時間、予約日、予約番号、その予約の総額などの予約のデータが保持されます。
一方、BookingAccess では、bookerID、customerID、processID、hotelID、paymentproviderID、およびその予約の現在のステータスなど、予約に関連する外部キーを保持します。Booking と BookingAccess は 1 対 1 の関係にあります。
私たちのソース システムは、これらの予約の有効性を確認するためのものであり、これらの予約は私たちのものではありません。これらの予約情報は他のソースから受け取り、上記のプロセスを外部委託します。総額は、当社が検証する必要がある予約の単なる情報であり、当社のビジネスの一部ではありません。BookingAccess テーブルに保持されている予約の現在のステータスは、システム内のその予約の現在のステータスであり、「処理中」または「完了」のいずれかになります。
Ralph Kimball から読んだことによると、この状況では、「Booking」はディメンション テーブルであり、BookingAccess は事実である必要があります。BookingAccessは、予約が「処理中」のときと予約が「完了」のときを追跡する必要がある[累積スナップショットテーブル]のようなものだと思います。
私はそれを正しく理解していますか？
2) "Booking" テーブルには、"ImportID" という外部キーもあります。このキーは、「インポート」というテーブルにリンクしています。この「インポート」テーブルには、ファイル名、インポートされた日付、インポートされた合計予約などの属性を含む、システムにインポートされたファイル (これらのファイルには「予約」テーブルに書き込まれる予約が含まれています) の履歴レコードが保持されます...
私の観点からは、これは明らかにファクト テーブルです。
しかし問題は、"Import" テーブルと "Booking" テーブルが 1 対多の関係にあることです ("Import" テーブルの 1 つの ImportID は、"Booking" テーブルで同じ ImportID を持つ 1 つ、2 つ、またはそれ以上のレコードを持つことができます)。 ）。これは、Fact と Dimension の関係は多対 1 でなければならないというファクト テーブルの考え方に反するものであり、事実は常に多側にあります。
では、このケースを解決するにはどのようなアプローチを使用すればよいでしょうか? この問題を解決するためにブリッジテーブルを使用することを考えています。ただし、「インポート」テーブルには多くのレコードがあるため、これが良い方法かどうかはわかりません。そのため、これらすべてをカバーするためだけに大きなブリッジ テーブルを作成する必要があります。
3) リレーションシップと情報が混在するテーブル (ソース システムから) を、リレーションシップのみを含むファクト テーブルと情報のみを含むディメンション テーブルに分離する必要がありますか? (たとえば、ソース システムの「Customer」というテーブル。このテーブルには、顧客名、顧客住所、顧客タイプ ID、顧客の親 ID などの情報が含まれています。)
BI ツールを使用して物事を分析する場合 (たとえば、customertypeid = 1 を持つ顧客の数を分析する場合)、ファクト テーブルが含まれていないと何かおかしいと感じるので、この質問をしています。
それとも、単なるディメンション テーブルとして扱い、snowflake-schema を使用する必要がありますか? しかし、これにより、データ ウェアハウスでスター スキーマとスノーフレーク スキーマが混在することになります。これは正常ですか？私は、スノーフレークスキーマをできるだけ使用したり混ぜたりすることを避けるべきであると述べているいくつかの公式情報源 (おそらく Oracle) を読みました。しかし、Microsoft などの一部の情報源は、これはごく普通のことだと言っています。Advanture Work Data Warehouse サンプル データベースでさえ、この種のアプローチを使用しています。
または、その「顧客」テーブルのすべての関係を非正規化する必要がありますか? しかし、Customer に多くの列が含まれるようになり、"DIM_Customer" テーブルのすべての行の履歴を追跡するのが非常に難しくなるため、これは良いアプローチではないと思います。たとえば、「Customer」テーブルのいずれかのリレーションに変更が発生した場合、「DIM_Customer」テーブル全体を更新する必要があります。
データ ウェアハウスに関しては、まだ多くの質問があります。私は、助けやコンサルタントなしで、ほぼ一人で作業しています。そのため、何か不都合や間違いがあった場合はご容赦ください。