問題タブ [star-schema]

私は OLAP を初めて使用し、次の状況に遭遇しました。

何百ものテーブルを含むスター スキーマ データベース (PostgreSQL) がありませんが、OLAP を実行するためにスター スキーマ データベースに変換する必要があります。ここにいくつかの質問があります：

1. スター スキーマの形式で新しいデータベースを作成し、既存のデータを新しいデータベースに挿入する必要がありますか? もしそうなら、そのタスクを自動的に完了するのに役立つツールはありますか?

2. Mondrian が必要とするデータはスター スキーマ データベースにあるはずですが、私の Web プロジェクトはスター スキーマ DB に基づいていません。つまり、新しいレコードを取得するたびに、両方の DB を同時に更新する必要がありますよね?

私はあなたの助けに感謝します、ありがとう!

こんにちは、SQL の達人です... 今月は、解決できないように見える長い問題があります。私はこの非常に広い（レポート）テーブルを約持っています。100以上のフィールド。現在、約 200 万件のレコードがあり、データが来る速度を考えると、今後 1 ～ 2 か月でこの数はおそらく 2 倍になるでしょう。現時点では許容範囲です。しかし、次の数か月でもう確信が持てなくなります。基本的に、このタイプのテーブルに最適なインデックス作成プランを知りたいだけです。これは実際のテーブルではありませんが、非常に近いものです。使用されるさまざまなデータ型を説明したいだけです。

現在、このテーブルは現在、次の方法でクエリされています。

各パラメーター/フィールドの可能な値は次のとおりです。

私は基本的な実行計画の読み取りを知っており、私が見ることができるものから...たくさんのスキャンが行われています. しかし、私が言ったように、私はすでに壁にぶつかったようです. 小さなテーブルの目的に基づいてインデックスを作成する方法を知っていますが、これは広いテーブルですか?? 私はただ自分自身を笑うことができます:D

アイデアはありますか？Columnstore INDEX について少し読んだことがあります..これは私が考えることができる最も実行可能なソリューションです..しかし、この時点でこのアプローチについて利用できる情報はほとんどありません。

どうやってこのテーブルを思いついたのか疑問に思っているなら. その内容は異なるテーブルから来ています（フラット化）。処理は毎晩行われます。結果は CSV ファイルにエクスポートされ、別のレポート アプリケーションのデータ ソースとして機能します。

前もって感謝します！

次元モデリングの意味を理解しようとしています。ディメンション モデリングの本を読みながら、スター スキーマを作成しました。

ファクト テーブルは累積スナップショット テーブルであり、代理キーを使用して日付ディメンションにリンクされた複数の日付列があります。

このスタースキーマを作成しようとしている明確に定義されたプロセスがあります。レポートや活動レポートのような目標到達プロセスを準備する必要があるため、この各ステップのファクト テーブルに日付フィールドがあります。だから質問は本当に

これは正しいです？ファクト テーブルは同じ日付ディメンション テーブルを複数回参照できますか?

私がインターネット上で見ている例は、これが正しいことを示しているようですが、Pentaho レポートで機能させるのに苦労しています。そのため、設計上の問題なのか、Pentahoで正しく行っていないのかはわかりません

免責事項:以前にデータ ウェアハウスを作成したことがありません。Kimball の Data Warehouse Toolkit のいくつかの章を読みました。

背景:工場 (工場) の管理チームは、さまざまな方法で生産情報を細かく分析できる必要があり、部門内の製造工場全体で一貫したレポート形式が必要です。ビジネス分析を通じて、事実粒度はプロセスが完了するごとに 1 行であるという結論に達しました。完成したプロセスは、「機械加工」または「組み立て」を意味します。私はこれを「生産事実」と呼んでいます。

ビジネスが答える必要がある質問は次のとおりです。

• プロセスが完了したとき、誰が作業していましたか?
• プロセスのサイクル タイムはどのくらいでしたか?
• このプロセスで製造された部品のシリアル番号は何ですか?

私のスキーマには、次の第 1 レベルのディメンションが含まれています。第 1 レベルを超えるディメンションはありませんが、工場のディメンションと、部品タイプ、シフト、およびプロセスのディメンションとの間に相互関係があります。

• 部品タイプ (属性: サロゲート キー、部品番号、モデル、バリアント、部品名)
• 植物 (属性: サロゲート キー、植物名、植物頭字語)
• シフト (属性: サロゲート キー、プラント キー、開始時間 24、開始時間、終了時間 24、終了時間)
• プロセス (属性: サロゲート キー、プラント キー、生産ライン、プロセス グループ、プロセス名、マシン タイプ)
• 日付 (典型的な日付ディメンション属性)
• 時刻 (典型的な時刻ディメンション属性)

非次元の事実は次のとおりです。

• 部品シリアル番号 (部品タイプのインスタンス)
• サイクルタイム
• 従業員 ID *MULTI-VALUED*

問題

私の問題は、複数の従業員がその時点でプロセスに取り組んでいた可能性があることです。そのため、モデルを変更する必要があるかどうか、およびモデルで従業員を最もよく表現する方法を考えています。従業員情報を保存しようとしているのではなく、会社の従業員 ID だけを保存しようとしています。次のオプションを検討しました。

1. ファクト テーブルの従業員列に複数の従業員 ID を許可します (たとえば、コンマ区切り)。欠点: プロセスに従事する従業員の数は可変数です。最大 X 人の従業員を収容するのに十分な大きさのフィールドを作成する必要がありますか? X はどうあるべきか?
2. 従業員ごとに各生産ファクトのレコードを作成します。これは、同じファクトに対して複数のレコードを意味します。それは悪いでしょう。:)
3. 従業員ディメンションと、従業員ディメンション テーブルとファクト テーブルの間に "Process Employees" ブリッジ テーブルを作成します。問題: その時点でプロセスに取り組んでいた従業員がファクト テーブルに表示されません。
4. Employee ディメンション、Process Employees Group テーブル、および Process Employees Group テーブルと Employee ディメンション テーブル間のブリッジ テーブルを作成します。従業員グループとブリッジ テーブルには、a) 考えられるすべての従業員の組み合わせを事前に入力する必要があります。これは、何千人もの従業員がいるため、どのレベルでも実用的ではありません。または、b) ETL 中にその場で入力します。4b では、特定の従業員グループが各プロセスにすでに存在するかどうかを確認する必要があります。これは、ソース レコードが 1 日に数回よりも頻繁にバッチ処理される場合 (たとえば、ほぼリアルタイムのレポートで 1 時間に 10 X)、DBMS/ETL システムに負担をかける可能性があります。

私の質問

オプション 3 が最も実行可能なオプションだと考えていますが、いくつか留保があります。潜在的な注意事項はありますか？他に検討すべき代替案はありますか? プロセスに携わった従業員をファクト テーブルから除外してもよろしいですか。

アドバイスありがとうございます。

Kimball スター スキーマ法を利用したレポーティング ソフトウェアの作成に参加しています。チーム全体 (私を含む) はこのテクノロジを使用したことがないため、これは初めてです。
これまでのところ、またはシステムにはいくつかのディメンション テーブルとファクト テーブルがあります。例:
- DIM_Customer (顧客のディメンション テーブル)
- DIM_BusinessUnit (ビジネス ユニットのディメンション テーブル)
- FT_Transaction (ファクト テーブル、トランザクションごとの粒度)
- FT_Customer (顧客のファクト テーブル、顧客 ID および日付は複合 PK にあります)

これは FT_Customer の現在の構造です:
- customer_id # (顧客 ID、複合 PK の一部)
- as_on_date # (観測日、複合 PK の一部)
- waic (KPI)
- wat (KPI)
- waddl (KPI)
- wadtp ( KPI)
-aging_bucket_current (KPI)
-aging_bucket_1_to_10 (KPI)
-aging_bucket_11_to_25 (KPI)
- ... ...
フィールド waic、wat、wadl、wadtp は、トランザクションの支払いの遅延に関連しています。これらのフィールドは、customer_id および as_on_date でグループ化された FT_Transaction テーブルに対する集計クエリによって計算されます。
フィールドaging_bucket_current、aging_bucket_1_to_10、aging_bucket_11_to_25には、支払いの遅延によって分類されたトランザクションの数が含まれています。たとえば、aging_bucket_current には期限内に支払われるトランザクションの数が含まれ、aging_bucket_1_to_10 には 1 ～ 10 日の遅延で支払われるトランザクションの数が含まれます...
この構造は、PHP Web アプリケーションおよび Cognos Studio からのレポート生成に使用されます。Cognos などの外部システムでより使いやすくするために、FT_Customer テーブルを再構築することについて説明しました。
FT_Customer の新しい提案された構造:
- customer_id # (顧客 ID、複合 PK の一部)
- as_on_date # (観察日、複合 PK の一部)
- kpi_id # (KPI の ID、DIM_KPI ディメンション テーブルを指す外部キー、複合 PK の一部)
- kpi_value (値 KPI)
- ... ...
この提案では、追加のディメンション テーブル DIM_KPI:
- kpi_id #
- title
このテーブルには、すべての KPI (wat、waic、wadl、エージング バケットなど) が含まれます。
FT_Customer の 2 番目の構造には、明らかに現在の構造よりも多くの行があります。
FT_Customer のどの構造がより普遍的ですか?
両方の構造を別々のテーブルに保持することは許容されますか? 一部の作業が 2 回行われるため、明らかに ETL レイヤーに追加の負担がかかりますが、一方で、さまざまなレポートの生成が容易になります。

提案をお寄せいただきありがとうございます。

3 つのファクトといくつかのディメンションを持つ表形式のモデルがあります。

3 つの事実のうち 2 つは、アカウントと製品に関するものです。

顧客のアカウントに実現した事実。アクティブな数、現在の残高、開始時の残高など。

Product Fact は、顧客が持っているさまざまなサプリメント製品に関するものです。彼/彼女はサプリメント製品を持っているかもしれませんし、持っていないかもしれません. 現在、これには、顧客がさまざまな製品で支払うべき金額、リベート額などの事実があります。

現在、両者は共通の Dim として Dimension Account を持っています。

アカウントと製品の関係は 1-M です。アカウントにサプリメント製品がある場合は、1、2、最大 3 になります。ない場合は、1-0 です:)

私たちが抱えている問題は、Account Dim 属性で両方の事実をスライスしたい場合、補足製品を持つアカウントのみを取得することです。テーブルモデルはINNER JOINSで機能すると信じているためです。この場合、OUTER JOINが必要です。クエリですべてのアカウントを取得したいので、サプリメント製品と一致する場所で、その製品の事実を確認します。

どんな助けでも大歓迎です。

次のようにGoogle BigQueryのjdbc接続を作成します

次に、次のようにカタログ名を取得します

しかし今、データセット名を取得しようとしています。null を返します。

publicdata のデータセット名を取得できますか?? そしてどうやって？？

ディメンション テーブルもファクト テーブルにすることはできますか? たとえば、名前、性別などの標準属性を持つ Customer ディメンション テーブルがあります。

SSAS を使用して、今日、先月、昨年などに作成された顧客の数を知る必要があります。

顧客キーと日付キーを使用して顔のないファクト テーブルを作成することも、両方のキーが既にあるため、同じ顧客ディメンション テーブルを使用することもできます。

Customer Dimension テーブルを Fact と Dimension の両方として使用するのは普通ですか?

ありがとう