1

誰かが私が実装しようとしているデータベーススキーマを混乱させるのを手伝ってくれることを願っています. これは、ネットワーク プロバイダーからのモバイル契約とネットワーク ボルトの販売に基づいています。契約は、ネットワーク契約を販売する場合も販売しない場合もある多くのディストリビューターによって事前に満たされます。価格もディストリビューターごとに異なります。

Distributors
Name                Address
Distributor 1       address1
Distributor2        address2

Networks
Name
Orange
O2
Vodafone

Tariffs
Network         Tariff          Minutes
Orange      Business 600        600 Mins
Orange      Business 100        100 Mins
O2          Everyday 100        200 Mins
O2          Everyday 100        100 Mins

Devices
Name        Make        
Apple       Iphone
Samsung     Galaxy

Bolt Ons
Network Description
Orange      Web 500mb
Orange      Unlimited Texts
O2          Web 250Mb
O2          Unlimited Texts

    
注文
- ちょうど 1 ディストリビューター
- ちょうど 1 つのネットワーク
- 正確に 1 関税
- 0台以上のデバイス
- 0個以上のボルトオン
卸売業者
- 0件以上の注文
- 1 つ以上のネットワーク
- 1つ以上の関税
o 独自の関税コスト
- 1 つ以上のボルトン
o 独自のボルト オン コスト
- 1 つ以上のデバイス
o 固有のデバイス コスト
通信網
- 0 注文
- 0 以上のディストリビューター
- 1つ以上の関税
- 0 個以上のボルトン
- 0台以上のデバイス
関税
- 0件以上の注文
- 0 以上のディストリビューター
- ちょうど 1 つのネットワーク
- 0 個以上のボルトン
- 0 デバイス
ボルトン
- 0件以上の注文
- 0 以上のディストリビューター
- ちょうど 1 つのネットワーク
- 0以上の関税
- 0台以上のデバイス
デバイス
- 0件以上の注文
- 0 以上のディストリビューター
- 0 以上のネットワーク
- 0関税
- 1 つ以上のボルトン

私は 2 つのスキーマを思いつきましたが、本当に満足していません。主に、ディストリビュータがネットワークからすべての製品を提供するとは限らないという事実が原因です。また、タリフ、デバイス、ボルトオンの価格もディストリビューターごとに異なります。スキーマアプローチへの提案を期待していましたか?

どうもありがとう

ロブ

編集--------私が持っていたコメントに続いて、次のシェマを思いつきました。次の仮定を追加しました

デバイスとボルトンは、製品テーブルに含まれるほど類似しています。

実行する必要があるクエリの種類は、ユーザーが 6 ～ 12 か月前に支払った金額に基づいて請求書を生成することです。ディストリビューターの価格は毎月変わる可能性があります。

ネットワークごとのディストリビューターごとに販売された電話の数など...

  • 関税はディストリビューター間で同じですが、価格とコミッションはディストリビューターごとに異なります。

以下のスキーマに関するコメントはありますか?

[Distributors] 
    [Dist_ID] PK
    [Name],
    [Address]

[Network]
    [Network_ID]  PK,
    [Name],

[Tarrif]
    [TariffID] PK
    [Name],
    [Minutes] ,
    [OtherMinutes] ,
    [Texts] ,
    [Data],
    [Term] ,
    [Active] BIT,

[TariffsByDistributor] 
    [TariffsDistributorID] PK
    [DistID]    FK
    [TariffID]  FK
    [RevShare],
    [Commision],
    [Cost],
    [Active]

[Product_Type] 
    [Product_Type_ID]  PK,
    [Name],
    [Details],

[TariffsByNetwork]
    [Network_ID]  PK,
    [TariffID]    PK,

[Order] (
    [Order_Id]      PK,
    [Customer_Id],
    [Date Sold],
    [PaymentStatus],
    [PaymentStatusDate],

[TariffOrders] (
    [Order_Id]          PK,
    [TariffsDistributorID]  PK,
    [RevenueShare],
    [Commision],
    [Cost],

[Products] (
    [Product_Id]    PK
    [Product_Type_ID] FK,
    [Name],
    [Manufacturer],
    [Colour] 
    [Picture],
    [Active] BIT,

[ProductByDistributor]
    [ProductsByDistributorID] PK,
    [Dist_ID]    FK,
    [Product_Id] FK,
    [RevShare],
    [Commision],
    [Cost],
    [Active],

[ProductsOrder] 
    [Order_Id]          PK,
    [ProductsByDistributorID]   PK,
    [RevenueShare],
    [Commision],
    [Cost],

[Products_Network] 
    [Network_ID]    PK,
    [Product_Id]    PK,
4

1 に答える 1

0

ディストリビューターとオファリング、ディストリビューターと価格設定の間の関係を特定しているという点で、スキーマを完成させるための正しい軌道に乗っています。

まず、Distributor と Tariff の両方との関係を持つ DistributorTariff テーブルを追加します。次に、TariffPrice などの他の制限を探して、そこにテーブルを作成します。

人間関係のルールをすべて知っていれば、最初に紙に書き出すことができます。すべてのルールを共有していただければ、設計をさらに支援できます。

スキーマについて

よさそうです。この段階でデータベースを正規化する際の余分な複雑さのように見えるかもしれないことは、後で頭を悩ますことから解放されます。次の推奨事項を作成します。

  • テーブル名が複数形かどうかを標準化します。たとえば、単数形の "Order" と複数形の "Products" があるとします。私の個人的な好みは、singular を使用することですが、それについては別の機会に説明します。
  • 「ProductByDistributor」の名前を「DistributorProduct」に変更します (または、そのようにする場合は複数形)。
  • テーブル名を結合すると、「OwnerItem」形式の方が読みやすいことがわかります。たとえば、「ProductOrder」ではなく「OrderProduct」です。
  • テーブル「TariffOrders」と「ProductOrders」を取り除くことができます。これらの代わりに、「OrderPart」または「OrderItem」テーブルを追加する必要があります。これには、「Order」、「DistributorProduct」、および「DistributorTariff」にリンクする外部キーがあります。これにより、収益分配、コミッション、およびコスト データの重複が削除されます。
  • 「関税」という言葉の誤字を訂正してください。それは将来あなたを悩ませるでしょう！;o)

それが役立つことを願っています。ご不明な点がございましたら、お気軽にお問い合わせください。

于 2012-04-24T11:15:26.033 に答える