最初の2つの記事では、データウェアハウスの価値と構築のアイデアについて説明しました。ここでは、実際のビジネスシステムデータに基づいてデータウェアハウスモデルを実装します。最新のプロジェクトは、入札システムのデータウェアハウスの構築です。ビジネス関係するロジックはより複雑で、多くの参加者がいます。データの量は多くありません。データウェアハウスが構築された後、それは主に入札と調達のプロセス監視レベルをサポートすることです。
データウェアハウスの構築アイデアによると、順序は概念モデル->論理モデル->物理モデルです。最も重要で複雑なのは、ビジネスと組み合わせる必要がある概念モデルの設計と、ファクトテーブルとディメンションテーブルは、ビジネス特性、トップレベルのデータサマリーテーブルに従って設計されています。
1.概念モデル設計
概念モデルは、ビジネスロジックを整理するために、実動システムのER関係モデルと組み合わせる必要があります。現在の実動トランザクションシステムは、データを複数のデータベースに分割するORACLEデータベースを使用します。ビジネスデータベース（入札と購入のプロセスを含む）プロジェクト）、サブジェクト+組織データベース（入札者、入札者、入札評価の専門家、代理店）、財務データベース（入札料金、プラットフォームサービス料金、入札デポジット、CA処理料金など）、プロジェクトテーブルは入札プロセステーブルであり、入札プロセスを記録します。入札、開札、入札評価、および入札に関連するデータ：
入札：入札プロセスは入札者によって開始されます。入札者は入札プロセスを代理店に委託します。代理店は入札アナウンスを発行します。入札者は登録と応答の段階でデータを生成し、入札デポジットは応答;
入札：入札者は代理店に入札手数料を支払い、入札書類をダウンロードします。入札者は、入札を開始する前に応答し、入札保証金を支払う必要があります。入札書類が販売され、入札者が入札を購入した後、入札者が質問した場合入札書類または入札者が入札書類の変更を希望する場合、この時点で、指定された時間内に説明通知が発行されるものとします。
開札：入札開口部は、一般的にオフラインで行われる機関が開札室に入札者を呼び出し、公に入札者の引用、工事期間、品質、プロジェクトマネージャーや他の入札者の実質的な要件を発表しました。この段階では、入札書類がされています。開かれた、電子入札文書の復号化;
入札評価：入札評価は通常オフラインで行われます。代理店は監督者、入札者、専門家を入札評価室に招集し、専門家は入札者の資格と入札を採点します。これらは技術、商業、見積もりのポイントに分けられます。
入札決定：専門家が総合的に入札者を採点した後、総合ランキングを行います。最初にランク付けされた候補者が落札者です。入札評価が完了したら、事前の発表が必要です。上位3つが発表されます。発表期間、社会的監督を受け付けます。質問や質問は代理店/入札者が明確にする必要があり、明確化には明確化の発表が伴います。質問が有効になると、入札が無効になる可能性があります（入札評価コストが高い） 、および入札は通常無効にされません）;
契約：落札後の入札が解除された後、質問期間は落札候補者に影響を与えません。落札が解除されてからxxx日後、入札者は落札候補者と契約を結ぶ必要があります。入札者は、入札に勝てなかった他のユニットの預金を返還する必要があります。
プロセス全体を整理してビジネスを理解した後、顧客はプロセスの監視と早期警告にさらに注意を払い、これに基づいていくつかの監視の側面を整理します。
2.論理モデルの設計
論理モデルは、前回のブログ投稿で述べた次元モデリングモデルを採用しており、スノーフレークモデル、プロジェクトID、入札者ID、入札者ID、代理店ID、エキスパートIDは、入札、投資、開札、評価、入札の全プロセスです。 。主な参加者であるデータ抽出ツールは、ケトルを使用します。
データテーブルの命名規則： tb_model level_subject domain_businessdomain_summarization粒度
ケトルの命名規則： kt_model level_topic domain_businessdomain_summarization粒度
3.物理モデルの設計
前のブログで述べた物理モデルの設計に従って、ODS-> DWD-> DWS-> ADSの階層化モデルを構築します。ここで、ODSは、クリーニングや変更を行わずに、Oracleライブラリのソースデータのみを抽出します。 DWDレイヤーはデータクリーニングとデータエンジニアリングを開始し、DWSは簡単な要約を提供します。ADSはアプリケーションクエリの高レベルの要約を提供します。例としてプロジェクトとサプライヤーの要約ディメンションを取り上げます。プロジェクトプロセスはモデル設計の本体です。サプライヤはディメンションテーブルデータに似ています。2つの組み合わせにより、ビジネスの投資/勝利に関連するいくつかの要約ディメンションを取得できます（勝利率のランキング、入札者の登録金額に関連する統計など）。特定のプロジェクト、特定の入札者の入札への参加に関連する統計など）：
プロジェクトプロセステーブル（キャリブレーションプロセス）で、入札者の数を設計します。キャリブレーションプロセスの統計項目は、このタイプのADSの要約ディメンションから結果を取得します。
