web-dev-qa-db-ja.com

リレーショナルデータベースのスタースキーマを設計する

私はデータウェアハウジングの初心者であり、記事を読んだり、原則についてのビデオを見たりしてきましたが、以下のデザインをどのようにしてスタースキーマに変換するかについて少し混乱しています。この例では、ファクトテーブルが（order-orderitem-book）で、メジャーが（category-customer-time）であると想定しています。私の質問は、本の著者に関するものです。スタースキーマに多対多の関係を置くことは許可されていますか？そして、私がこの相対データベースにスタースキーマを描画する方法が間違っているなら？ enter image description here

data-warehousestar-schema
1
J. DOE

データウェアハウス内に多対多の関係を置くこともできますが、データウェアハウジングツールによって作成を許可されていない場合でも、多くの人がそうすることは悪い習慣だと考えています。これが私があなたのデザインからスタースキーマを作成する方法です：

AuthorテーブルとCategoryテーブルには1つの貴重な属性（名前）しかないため、これらをBookテーブルにロールインして、最初のディメンションにします。 Customerテーブルは現状のままで、ディメンションにもなります。次に、2つのOrderテーブルを1つにまとめ、Order、OrderID、Date、BookID、CustomerIDで構成されるPriceファクトテーブルを作成します。

CREATE TABLE DimBook
(
    BookID      INT          NOT NULL PRIMARY KEY,
    Author      VARCHAR(50)  NOT NULL,
    Category    VARCHAR(50)  NOT NULL,
    Title       VARCHAR(50)  NOT NULL,
    ISBN        VARCHAR(50)  NOT NULL,
    Year        SMALLINT     NOT NULL,
    Price       DECIMAL(9,2) NOT NULL,
    NoPages     SMALLINT     NOT NULL,
    Description VARCHAR(100) NOT NULL
);

CREATE TABLE DimCustomer
(
    CustomerID INT         NOT NULL PRIMARY KEY,
    FirstName  VARCHAR(50) NOT NULL,
    LastName   VARCHAR(50) NOT NULL,
    ZipCode    VARCHAR(20) NOT NULL,
    City       VARCHAR(50) NOT NULL,
    State      VARCHAR(50) NOT NULL
);

CREATE TABLE FactOrders
(
    OrderID    INT          NOT NULL,
    "Date"     DATETIME     NOT NULL,
    BookID     INT          NOT NULL REFERENCES DimBook(BookID),
    CustomerID INT          NOT NULL REFERENCES DimCustomer(CustomerID),
    Price      DECIMAL(9,2) NOT NULL
);

また、日付による検索を容易にするために、スタースキーマやデータウェアハウスにも一般的に見られるDateディメンションを検討することもできます。非常に基本的な実装は次のとおりです。

CREATE TABLE DimDate
(
    "Date"  DATETIME NOT NULL PRIMARY KEY,
    "Year"  SMALLINT NOT NULL,
    "Month" TINYINT  NOT NULL,
    "Day"   TINYINT  NOT NULL
);

次に、ファクトテーブルのDate属性からDateテーブルのDimDateキーに外部キーを追加します。これは次のようなものを生成します：

Star Schema

本に多くの著者がいる（頻繁に発生する）シナリオを処理する必要がある場合は、いくつかの方法があります。

最初の推奨事項は、すべての作成者をAuthor属性内に含めることです。これにより、同じ著者の組み合わせで書かれたすべての本を簡単に検索できます。

2番目のアプローチでは、Author属性を独自のディメンションに非正規化し、それを本のディメンションで参照します。これはスノーフレークスキーマを作成し（質問ではスタースキーマが必要なので、このアプローチは避けました）、複数の作成者で検索しようとすると遅くなります。

最終的には、正確なニーズと満たそうとしている要件によって異なります。これは最も簡単な設計であり、スタースキーマの要件を満たすため、個人的にはすべての作成者を同じ属性に含めることにします。

1
Mr.Brownstone

あなたの質問はいくつかの異なる質問です-

  1. Authorは独自のディメンションであってはならず、単にBookディメンションの属性になります。

  2. ファクトテーブルの主キーは、一連の外部キーで構成される複合キーであるため、多対多の関係を持つすべてのテーブルをファクトテーブルとして表現する必要があります。ブリッジテーブルを使用する必要がありますが、 これを実装する最良の方法はニーズによって異なります 。

  3. 私はあなたのアプローチが間違っているとは思いませんが、あなたが何をしているのかを明確にするのを助けるために、Orderをファクトテーブルとして、そしてBook（これは私がAuthorとCategoryを属性として）に移動します）DateTime（またはDateとTimeを互いに分離）とCustomerを例のディメンションとして使用します。すべての量的データ（DateTime以外）はOrderに入れ、記述的および質的データはすべて周囲の次元に入れます。

0
Rhys