Створення простої схеми для дезагрегації прогнозу попиту


9

Я виконую просте завдання з проектування бази даних як навчальну вправу, де мені потрібно придумати базову схему для наступного випадку:

У мене є ієрархія батьків-дітей (наприклад, сировина> незавершене виробництво> кінцевий продукт).

  • Замовлення розміщуються на кожному рівні.
  • Кількість замовлень має відображатися у відрядах за тиждень протягом наступних 6 місяців.
  • Прогноз попиту можна зробити для кожного рівня продукту.
  • Прогноз попиту на будь-який тиждень протягом наступних 6 місяців можна зробити сьогодні.
  • Прогноз попиту робиться для тижневих відер, протягом наступних 6 місяців.

Прогноз попиту, як правило, робиться на більш високому рівні в ієрархії (сировина або робота в процесі прогресу). Її потрібно розділити на нижчий рівень (кінцевий продукт).

Є два способи, за допомогою яких прогноз попиту можна розділити з вищого на нижчий:

  1. Користувач визначає відсотковий розподіл для кінцевого продукту. Скажімо, є прогноз 1000 для роботи в прогресі. для кінцевого продукту 1 буде 400, а для кінцевого продукту 2 - 600.
  2. Користувач каже, що просто розділіть їх відповідно до замовлень, розміщених проти кінцевих продуктів у Відрі 5, а замовлення у відрі 5 для Кінцевого продукту 1 та 2 становлять відповідно 200 та 800, тоді прогнозне значення для EP1 складе ((200/1000) * 100)% а для EP2 було б ((800/1000) * 100)% від прогнозу "Робота в процесі".

Прогноз повинен бути видно у тижневих відрах протягом наступних 6 місяців, а ідеальний формат повинен бути:

product name | bucket number | week start date | week end date | forecast value | created_on

Таблиця PRODUCT_HIERARCHY може виглядати так:

id  |   name                |   parent_id
__________________________________________
1   |   raw material        |   (null)
2   |   work in progress    |   1
3   |   end product 1       |   2
4   |   end product 2       |   2

Таблиця ЗАМОВЛЕНЬ може виглядати приблизно так:

id | prod_id | order_date | delivery_date | delivered_date

де,

prod_idє зовнішнім ключем до посилань idна таблицю PRODUCT_HIERARCHY,

Як зберігати прогноз? Що було б хорошою базовою схемою такої вимоги?


Моя ідея вибрати замовлення на 26 відра на тиждень:

SELECT
    COUNT(*) TOTAL_ORDERS,
    WIDTH_BUCKET(
        delivery_date,
        SYSDATE,
        ADD_MONTHS(sysdate, 6), 
        TO_NUMBER( TO_CHAR(SYSDATE,'DD-MON-YYYY') - TO_CHAR(ADD_MONTHS(sysdate, 6),'DD-MON-YYYY') ) / 7
    ) BUCKET_NO
FROM
    orders_table
WHERE
    delivery_date BETWEEN SYSDATE AND ADD_MONTHS(sysdate, 6);

Але це дасть відра на тиждень, починаючи з сьогоднішнього дня, незалежно від дня. Як я можу конвертувати їх у неділю до суботи тижнів в Oracle?

Будь ласка, допоможіть розробити цю структуру бази даних.

(буде використовувати Oracle 11g)


1
здається, ви будуєте сховище даних. порядком буде таблиця фактів. продукту та дати розмірності таблиць. Можливо, ви хочете використовувати накопичувальну таблицю фактів, оскільки ви переглядаєте процес, який має кілька кроків.
Ніл Макгуйган

Відповіді:


1

Гаразд, ось ось модель даних, яку я придумав.

ПРОДУКТ - для зберігання інформації про продукт та підтримання ієрархії батько-дитина

id  NUMBER  "Primary Key Not Null"                  
level_code  VARCHAR2    Not Null                    
name    VARCHAR2    Not Null                    
description VARCHAR2                        
parent_id   NUMBER  Foreign Key references PRODUCT(id)                  

ЗАМОВЛЕННЯ - для зберігання замовлень на продукцію

id  NUMBER  "Primary Key Not Null"                  
prod_id     NUMBER  "Foreign Key references PRODUCT(id) Not Null"                   
order_type  VARCHAR2    "Not Null Default 'Default'"
order_qty   NUMBER  Not Null
order_date  NUMBER  Foreign Key references DATE_INFO(date_key)
delivery_date   NUMBER  "Foreign Key references DATE_INFO(date_key)
Check delivery_date >= order_date"

FORECAST - для збереження прогнозного значення для продуктів (значення магазину для вищих рівнів, зберігання для нижчих рівнів після дезагрегації від батьків)

id  NUMBER  "Primary Key Not Null"
product_id  NUMBER  "Foreign Key references PRODUCT(id) Not Null"
forecast_value  NUMBER  Not Null
week    NUMBER  "Foreign Key references DATE_INFO(date_key) Not Null"                   

DISAGGREGATION_RULES - для зберігання того, який метод використовувався для дезагрегації значення з вищого рівня на нижчий і який відсоток розподілився на нижчий рівень

id  NUMBER  "Primary Key Not Null"
parent_product_id   NUMBER  "Foreign Key id references PRODUCT(id) Not Null"
child_product_id    NUMBER  "Foreign Key id references PRODUCT(id) Not Null"
method  VARCHAR2    Not Null                    
from_week   NUMBER  "Foreign Key references DATE_INFO(date_key) Not Null"
to_week NUMBER  "Foreign Key references DATE_INFO(date_key) Not Null Check end_week >= start_week"
percent_distribution    NUMBER  Not Null                    

DATE_INFO - параметр дати, містить інформацію про дату початку (має бути субота) та кінцеву дату, що відповідає тижня, на який припадає конкретна дата

date_key    NUMBER  "Primary Key
Not Null"                   
full_date   DATE    Not Null                    
week_begin_date DATE    Not Null                    
week_end_date   DATE    Not Null

Що стосується номера відра. Я обчислюю дату початку тижня (дата в суботу, в моєму випадку) за допомогою наступної функції

CREATE OR REPLACE FUNCTION get_week_start_date(v_bucket_num IN NUMBER)
  RETURN DATE
IS
  week_start_date DATE;
BEGIN
  SELECT (TRUNC(SYSDATE+2, 'IW')-2) + ((v_bucket_num-1) * 7)
  INTO week_start_date FROM dual;
  RETURN week_start_date;
END;
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.