Схема базы данных для отчета об уходе с изменяющейся структурой

Question

У меня есть требование показать историю отпусков и прогноз. Данные поступают еженедельно в отчете, который мне нужно хранить в таблице. Я могу использовать любую БД, поддерживаемую Java.

Пример данных выглядит следующим образом:

Чтобы показатьпрошлые итоги по отделам Мне нужно хранить данные, которые появляются в отчете каждую неделю.

Как хранить прогнозные данные, так как структура данных отчета постоянно меняется. В приведенном выше примере последние 12 столбцов - это 12 месяцев, следующих за датой запуска отчета. В следующем месяце первый столбец будет октябрь и т. Д.

Я создал скрипку здесь

Я рассмотрел просто сохранение последних 4 недель отчетов (каждый отчет вотдельная таблица) и вставка итогов рабочей группы в отдельную таблицу итогов, где каждая строка будет представлять отдел и его итоги.

Если есть лучший способ - какую структуру данных / схему мне следует использовать?

Answer 1

Я могу подумать о 3 подходах:

1. Вы можете добавить столбцы date и forecast, а затем избавиться от столбцов, названных в честь месяца / года. Это как transpose действие в Excel. Кроме того, поскольку Dept, Leave_Balance, projected_balance_6m не будут в том же порядке, что и новые столбцы, я бы создал новую таблицу. Пример строки из новой таблицы будет выглядеть следующим образом:

   +------------+-----------+----------+
   | EmployeeID | YearMonth | Forecast |
   +------------+-----------+----------+
   |        456 |    201901 |        0 |
   |        456 |    201902 |        5 |
   +------------+-----------+----------+
   

2. Снова в новой таблице вы можете добавить столбец year и сделать имена столбцов прогноза похожими на месяцы. Это не будет непрерывным, как ваше текущее решение, но проще в обработке в программном обеспечении BI.

   +------------+------+-----+-----+-----+-----+-----+-----+
   | EmployeeID | Year | Jan | Feb | Mar | Apr | May | Jun |
   +------------+------+-----+-----+-----+-----+-----+-----+
   |        456 | 2019 |   0 |   0 |   0 |   0 |   0 |   0 |
   |        456 | 2020 |   0 |   5 |   0 |   6 |   0 |   0 |
   |        123 | 2020 |   0 |   0 |   1 |   0 |   0 |   0 |
   +------------+------+-----+-----+-----+-----+-----+-----+
   

3. Другой подход может заключаться в переименовании столбцов относительно текущей даты. Здесь cur равно SEPT19, cur+1 равно OCT19 и так далее. Это решение будет иметь наименьшее влияние, но недостатком этого подхода является то, что неясно, когда вы последний раз обновляли таблицу, и каково значение cur на самом деле. Итак, эта информация должна быть где-то доступна.

   +-----+------+-------+---------------+--------------+-----+-------+-------+
   | ID  | Name | Dept  | Leave_Balance | p_balance_6m | cur | cur+1 | cur+2 |
   +-----+------+-------+---------------+--------------+-----+-------+-------+
   | 456 | Mary | Sales | 32.3          | 45.6         |   0 |    0  |     0 |
   +-----+------+-------+---------------+--------------+-----+-------+-------+
   

Мне больше нравятся первое и второе решения, потому что они более самодостаточны. Ваш выбор будет зависеть от того, насколько вы хотите положиться на программное обеспечение BI (Tableau, Qlikview и т. Д.).