需要予測を分解するための単純なスキーマの設計

あなたの最後のコメントはまさに私が意味したものです。あなたがそれを手に入れたことを見てクールです！

私はそれを始めたので、私は模範的なコードを完成させました。あなたが言っていたこととの違いは、変化するものと変化しないものを分離することです（raw_material VS raw_material_hist ）月曜日である週の日付のみを使用する 、およびさまざまなチェック制約。

CREATE TABLE raw_material 
  ( 
     material_id     NUMBER PRIMARY KEY, 
     material_blabla VARCHAR2(20) 
  ); 

CREATE TABLE wip 
  ( 
     wip_id     NUMBER PRIMARY KEY, 
     parent_raw NUMBER REFERENCES raw_material(material_id), 
     wip_desc   VARCHAR2(20) 
  ); 

CREATE TABLE end_product 
  ( 
     end_product_id NUMBER PRIMARY KEY, 
     parent_wip     NUMBER REFERENCES wip(wip_id), 
     description    VARCHAR2(20) 
  ); 

CREATE TABLE rm_histo 
  ( 
     material_id NUMBER REFERENCES raw_material(material_id), 
     week_start  DATE CHECK (To_char(week_start, 'D')=1), 
     forecast    NUMBER(8) CHECK (forecast >0), 
     CONSTRAINT pk_rm_histo PRIMARY KEY (material_id, week_start) 
  ); 

CREATE TABLE wip_histo 
  ( 
     wip_id            NUMBER REFERENCES wip(wip_id), 
     week_start        DATE CHECK(To_char(week_start, 'D')=1), 
     wip_user_forecast NUMBER(8) CHECK (wip_user_forecast>0), 
     CONSTRAINT pk_wip_histo PRIMARY KEY (wip_id, week_start) 
  ); 

CREATE TABLE end_prod_histo 
  ( 
     end_product_id         NUMBER REFERENCES end_product(end_product_id), 
     week_start             DATE CHECK(To_char(week_start, 'D')=1), 
     end_prod_user_forecast NUMBER(8) CHECK (end_prod_user_forecast >0) 
  ); 

そして最後に、実際にビューを使用して予測されたものを表示するか、大量のデータがある場合は具体化されたものを表示します。ビューを使用することで、データが複製されないため、変更/更新がより安全かつ簡単になります。

ユースケース1または2の場合、これはデータベーススキーマを扱いません。結局のところ、予測の値を更新するだけで、ユースケース1または2のロジ​​ックは、PL/SQLプロシージャまたはインターフェイスに使用しているものに組み込まれる可能性があります。

編集：また、あなたの最後のコメントから、予測が手動で設定されたVS計算されたものを持っていることに言及していました。だから私はそのような列を追加しました、しかしクレジットはあなたに行きます

ビスの編集：バケット番号については、IWのように日付に適切なマスクを使用してください またはWW 。今年の最初の週であるこれらの2つの変更。