0

医薬品の日次売上高のテーブルを設計する必要があります。

{Name, code} には数百種類の製品があります。

これらの製品{名前、コード}を販売するために、何千人もの営業担当者が雇用されています。

さまざまなデポ{名前、コード}から製品を収集します。

それらはさまざまなエリアで機能します -> ゾーン -> マーケット -> アウトレットなど {すべてに名前とコードがあります}

各商品には、さまざまな種類の価格{製造価格、取引価格、業務価格、割引価格など}があります。そして、販売員はそれらの組み合わせから自由に選択して販売価格を見積もることができます。

問題は、毎日の売上高が膨大な量のデータ入力を必要とすることです。数年以内に (テラバイトではないにしても) ギガバイトのデータが存在する可能性があります。日次、週次、月次、四半期、および年次の売上レポートを表示する必要がある場合は、さまざまな種類の SQL クエリが必要になります。

これは私の最初のデザインです:

Product {ID, Code, Name, IsActive}
ProductXYZPriceHistory {ID, ProductID, Date, EffectDate, Price, IsCurrent}
SalesPerson {ID, Code, Name, JoinDate, and so on..., IsActive}
SalesPersonSalesAraeaHistory {ID, SalesPersonID, SalesAreaID, IsCurrent}
Depot {ID, Code, Name, IsActive}
Outlet {ID, Code, Name, AreaID, IsActive}
AreaHierarchy {ID, Code, Name, PrentID, AreaLevel, IsActive}
DailySales {ID, ProductID, SalesPersonID, OutletID, Date, PriceID, SalesPrice, Discount, etc...}

さて、インデックス作成とは別に、DailySalesテーブルを正規化して、今後何年も変更する必要のないきめ細かい設計を行うにはどうすればよいでしょうか?

上記の情報に基づいて、(すべてのタイプのレポートが照会される) データ入力テーブルのみのサンプル デザインを示してください。DailySales

詳細な設計アドバイスは必要ありませんDailySalesテーブルについてのみアドバイスが必要です。この特定のテーブルを分割して粒度を実現する方法はありますか?

4

3 に答える 3

2

あなたが探しているのは、データ ウェアハウス (DW) と呼ばれるものです。Ralph Kimball による「The Data Warehouse Toolkit」をご覧になることをお勧めします。小売販売向けのデータ ウェアハウス設計の例が掲載されています。これは、どのように見えるかを示す非常に単純化された (最初のドラフト) 例です。これは、レポートと分析用に最適化された非正規化構造であることがわかります。通常、ファクト テーブルの粒度はレシートの 1 つの項目 (行) です。これがあなたの解決策を示してくれることを願っています。DW は数テラバイトで十分です。


storedw_model_01

于 2009-11-16T15:10:13.660 に答える
1

Why not put a date and price on the product, so that you can drop the price from the dailysales table, since you can get it by joining.

Unless the price can be changed by the salesman, without any rationale in the database.

On a given date, can a salesman only be in one outlet? If so then you can drop the outletid.

You have PriceiD, SalesPrice and Discount. If I know the discount and outlet id and original price then I can determine taxes and so calculate the SalesPrice, so you can possibly drop that.

But, this would imply that you are storing tax info by date, to track what it was when the sale took place.

My point is that you should look at what already exists in another table and you can then simplify the daily sales table.

You will want to pull information from it into staging tables by day/month/year, for example, to help aggregate the data by date, so that your reports will be generated more quickly.

You have a lot of unknowns in your question, but hopefully this will help.

Update: Based on comment

I had a table that contained usage info on when resources were used by someone, and that table got large quickly. So, we decided that we would only keep 2 or 3 years of data, and the rest would be aggregated, and the raw data dumped to a file for archival purposes.

When looking at the number of rows, you will need to decide how much data you need to keep, and how you can archive the old data, to make it available if it is absolutely needed, but, you can generate the reports that should be needed beforehand.

By reducing the number of columns you will have a large impact on storage space, in case that is a concern, as many of the columns will probably not be null.

于 2009-11-16T08:27:36.687 に答える
1

If you are going to generate massive amounts of data and need to generate reports based on past data, you should consider using a business intelligence engine. Typically these engines allow you to archive historical data in a separate data store (so that you don't clutter the daily work database), yet to obtain statistical data and reports out of the archived data.

于 2009-11-16T08:28:31.637 に答える