提案されたスター スキーマ設計には、2 つの問題が考えられます。
問題 1: 柔軟性
価格決定基準をルックアップ テーブルへの外部キーの固定セットとして設定することにより、価格を追跡するすべてのコースが何らかの方法でこのスキームに適合しなければならない状況が作成されます。クリエイティブ マーケティング マネージャーがいるコースに参加するとすぐに、その 1 つのコースに合わせるためだけにスキーマを変更しなければならなくなることがあります。
問題 2: データ入力の労力
既にお気付きのように、一連の固定価格決定要因があるということは、これらすべての決定要因のクロス積が、維持しなければならない膨大な量のデータであることを意味します。これについてイライラすることは、多くのコースでは、いくつかの決定要因が問題にならないことです。
もう 1 つのイライラする可能性があるのは、各コースが各決定要因について独自の解釈を行う可能性があることです。たとえば、各コースにとってピーク シーズンとは何を意味するのでしょうか。これらの詳細を気にしない場合は問題ありませんが、実際に特定の用語で自分自身を説明する必要がある場合 (つまり、コースXの「ピーク」とはどの日付を意味しますか?)、多くのこともあるでしょう。価格ディメンション テーブルのデータも。
問題への対処:
より複雑なデータ モデルを使用する場合は、データ管理の量を大幅に削減できます。価格決定要因の固定セットを持つスター スキーマの代わりに、決定要因をテーブル駆動できます。スキーマは次のようになります。
COURSE -- The list of courses you are tracking
courseid (PK)
, name
COURSE_PRICE_POINT -- An individual price point for a course
cppid (PK)
, courseid -- FK to COURSE
, price -- The amount, if your system is multi-currency, include a code
-- for the currency, e.g. GBP, EUR, USD, etc.
COURSE_PRICE_FACTOR -- The list of factors that make a specific price point applicable
cppid (PK) -- PK, also FK to COURSE_PRICE_POINT
, pfid (PK) -- PK, also part of FK to FACTOR_VALUE
, fvid -- the other part of the FK to FACTOR_VALUE
FACTOR_VALUE -- A lookup table of price factors, e.g. "Peak Season", "18 Holes"
pfid (PK) -- PK, also FK to PRICE_FACTOR
, fvid (PK)
, value -- Description of the price factor value
PRICE_FACTOR -- A list of the dimensions that impact price,
-- e.g. Season, Holes, Person, Time
pfid (PK)
, description -- A caption/name for the price factor.
モデルが機能する方法は、コースが請求する可能性のある特定の価格ごとに、COURSE_PRICE_POINT. スター スキーマ テーブルの行数を最小限に抑えることができる場合、スター スキーマの価格設定テーブルにあるレコードごとに、このテーブルに 1 つのレコードが存在します。
スター スキーマの価格表の価格決定要因列は、 の行になりますPRICE_FACTOR。行列式ルックアップ テーブルに表示される可能性のある値は、 の行になりますFACTOR_VALUE。この部分は同じ量の作業ですが、新しい価格要素を追加する必要がある場合は、テーブル定義を変更する代わりに新しいデータを入力するだけで済みます。スター スキーマ アプローチ。
実際にプライス ポイントをその決定要因に固定するには、プライスポイントを、プライス ポイントを定義するために必要な要素値の最小セットCOURSE_PRICE_FACTORに接続するように設定します。は への FK によって識別されることに注意してください。これは、 の PK がへの FK の一部として検出されることを意味します。プライス ポイント ID とプライス ファクター ID の組み合わせで一意のインデックスを定義できるため、これは重要です (この組み合わせをテーブルの PK にしました)。これは、スキーマが、同じ価格要素に対して矛盾する値を持つことができないという制限を課すことを意味します。これは、ちょっとしたデータの一貫性の良い制約です。FACTOR_VALUEPRICE_FACTORPRICE_FACTORCOURSE_PRICE_FACTORFACTOR_VALUE
これらはすべて大変な作業のように思えるかもしれませんが、なぜスター スキーマより優れているのでしょうか? 一例として、スター スキーマに季節、穴、時間、人物のそれぞれに 4 つのバリエーションがあるとします。それはおそらく過小評価ですが、それで行きましょう。つまり、すべての価格変動を追跡するには、コースごとに 4 x 4 x 4 x 4 = 256 レコードが必要です。コースに非常に単純なプライス カードがあるとしたら、たとえば「オフシーズンは 1 日あたり 100 ドルでプレーできるのはすべて」などです。これは、提案したモデルの 1 つの価格ポイントですが、スター スキーマには 1 x 4 x 4 x 4 = 64 レコードが必要です。
さらに悪いことに、スター スキーマを使用する方法によっては、各ルックアップ テーブルの値を各コースの価格表で表す必要があるというルールが必要になる場合があります。つまり、シーズンなどに新しいレコードを追加すると、他のコースが新しいディメンション値を認識しない場合でも、すべてのコースで一連の新しいレコードが必要になります。
私が提案するモデルの主な利点は、(i) 特定の条件下での特定のコースの価格設定について非常に具体的かつ正確であること、および (ii) データのメンテナンスが最小限に抑えられることです。
このモデルの欠点は何ですか？このモデルは、あるコースと別のコースの価格比較表を作成するのにはあまり役に立ちません。比較している 2 つのコースの料金体系が大きく異なる場合、料金表を並べて料金比較表に表示する方法を見つけるのは非常に困難です。