如何设计一个处理当前员工和预测员工的数据模型？

3 回答

• 0

  我可以看到你需要两个表的几个原因：

  • 真正的员工必须有名称，部门等，而预测员工只能拥有这些属性

  • 只有真正的员工才有责任，所以你希望能够单独引用它们

  但与此同时，您希望确保两个表中没有ID冲突，因为（希望）预测员工将成为实际员工 .

  这样做的方法是实现超类型/子类型结构 . 因此，您有一个表，EMPLOYEES保证单个主键，以及两个从属表用于实际和预测员工 . 使用类型列至关重要，因为它确保给定的员工只出现在一个子表中 .

  create table employees
      ( emp_id number not null
        , emp_type varchar2(8) not null
        , constraint emp_pk primary key (emp_id)
        , constraint emp_uk unique (emp_id, emp_type)
        , constraint emp_type_ck check (emp_type in ('FORECAST', 'ACTUAL'));
  
  create table actual_employees
      ( emp_id number not null
        , emp_type varchar2(8) not null
        , name varchar2(30) not null
        , deptno number(2,0) not null
        , sal number(7,2) not null
        , hiredate date not null
        , constraint actemp_pk primary key (emp_id)
        , constraint actemp_type_ck check (emp_type = 'ACTUAL')
        , constraint actemp_emp_fk foreign key (emp_id, emp_type)
                     references emp (emp_id, emp_type) 
                     deferrable initially deferred ;
  
  create table forecast_employees
      ( emp_id number not null
        , emp_type varchar2(8) not null
        , name varchar2(30) 
        , deptno number(2,0) 
        , sal number(7,2) 
        , predicted_joining_date date
        , constraint foremp_pk primary key (emp_id)
        , constraint foremp_type_ck check (emp_type = 'FORECAST')
        , constraint foremp_emp_fk foreign key (emp_id, emp_type)
                     references emp (emp_id, emp_type) 
                     deferrable initially deferred ;
  

  因此键可能看起来有点奇怪 . 父表具有主键和复合唯一键 . 主键保证EMP_ID的单个实例 . 唯一键允许我们在子表上构建外键，这些外键引用了EMP_ID和EMP_TYPE . 结合对子t的检查约束这是因为它们引用父表而不是其主键上的唯一键 . 这种安排可以确保员工可以使用FORECAST_EMPLOYEES或ACTUAL_EMPLOYEES，但不能同时使用两者 .

  外键可以推迟，以允许将预测员工转换为实际员工 . 这需要三项活动：

  • 从FORECAST_EMPLOYEES中删除记录

  • 将记录插入ACTUAL_EMPLOYEES

  • 更改了EMPLOYEES中的EMP_TYPE（但不是EMP_ID） .

  使用延迟约束可以更轻松地同步动作2和3 .

  另请注意，引用EMPLOYEES的其他外键约束应使用主键而不是唯一键 . 如果关系关心员工的类型，那么它可能应该链接到子表 .

  ---

  “有点头疼”

  欢迎来到数据建模的世界 . 这是一个令人头痛的问题 . 因为努力将混乱的现实融入干净的数据模型很难：你需要明确的要求才能做到正确，并了解最重要的事情，这样你才能做出合理的妥协 .

  我根据您的其他问题提出了超类型/子类型方法，因为它似乎是处理两组数据的最佳方式：真实员工和名义员工 . 我认为这两个群体需要区别对待 . 例如，我坚持要求管理者成为真正的员工 . 这很容易做到对ACTUAL_EMPLOYEES的完整性约束，并且使用包含两种类型员工的单个表更难实现 .

  当然有两个表意味着可能会产生更多关于同步其结构的工作 . 所以呢？这在很大程度上是微不足道的，因为编写两个ALTER TABLE语句而不是一个语句几乎没有什么工作要做 . 此外，新列很可能仅适用于实际员工，对预测员工没有意义（例如EARNED_COMMISSION，LAST_REVIEW_RATING） . 在这种情况下，具有单独的表使数据模型更准确 .

  关于必须复制依赖表，正如奥利指出的那样，这是一种误解 . 适用于所有员工的表格，无论其实际情况如何，均应参考EMPLOYEES表而非其子女表 .

  最后我不明白为什么用两个表维护历史数据比用一个表更难 . 大多数日记代码应该完全从数据字典生成 .

  ---

  “如果我有员工表和Employee_forecast表......”

  有三个表：

  • EMPLOYEES - 保证唯一EMP_ID的主表

  • ACTUAL_EMPLOYEES - 为贵公司工作的人员的子表

  • FORECAST_EMPLOYEES - 您希望招募到公司的人员的儿童桌

  “......他们的产品或活动都将存储在一个产品/活动表中？”

  请记住，我从您提供的细节中对您的业务逻辑做出假设 .

  现在在我看来，那些尚未为贵公司工作的人不应该有任何相关的活动 . 在这种情况下，您将拥有一个表EMPLOYEE_ACTIVITIES，它是ACTUAL_EMPLOYEES的子项 .

  但也许你确实为那些不存在的人做了活动 . 所以这是一个选择：一个或两个表？一个表设计将EMPLOYEE_TASKS作为主EMPLOYEES表的子项 . 两个表设计分别将ACTUAL_EMPLOYEE_TASKS和FORECAST_EMPLOYEE_TASKS作为ACTUAL_EMPLOYEES和FORECAST_EMPLOYEES表的子项 .

  哪种设计是正确的取决于您是否需要执行有关任务授权的规则 . 例如，您的公司可能有一条规则，规定只有真正的人才能雇用新员工 . 因此，拥有一个仅允许将招聘任务分配给ACTUAL_EMPLOYEES的模型会很有用 .

  ---

  “此设计对月度预测没有任何考虑”

  好的，我已将日期列添加到两个表中 . 这将允许您运行所需的报告 .

  回复于 2024-05-11T03:20:24+08:00
• 2

  我认为您的数据模型将取决于您需要报告的信息 . 例如，我倾向于使用标准的 EMPLOYEE 和 DEPARTMENT 表（如Oracle默认的 SCOTT 模式） .

  我还有一个状态栏，您可以在其中表示员工是当前员工或潜在员工，从而允许您报告当前员工和预测员工 . 根据员工的状态等，您可以根据需要的列添加功能约束/业务规则 . 因此，当前员工将拥有全名，DOB等，而未来的员工可能不会 .

  然后我还会创建一个审计表来跟踪 EMPLOYEE 记录所经历的变化 . 这将允许您回顾性地查找他们的部门更改以及记录员工何时从预期员工更改为当前员工等以及 EMPLOYEE 记录中的其他数据的任何更改 .
  它还具有将所有数据保存在一个位置的优势 . 如果需要，您还可以考虑使用状态列对 EMPLOYEE 表进行分区 .

  这样，您就可以在申请过程中通过各个阶段的工作向每位员工发放一个ID .

  状态列的另一个好处是，您可以在将来根据需要引入员工可以经历的任何其他阶段 .

  EDIT:

  这也可以确保如果您需要在将来添加列，如上所述，您只需要支持一个表结构 .

  回复于 2024-05-11T03:20:24+08:00
• 1

  以下是我要做的事情：Employee和Department表是典型的，但emp表中的dept_id没有emp_dept表来表示员工和部门之间的多对多，以及关系的生效日期或生效日期范围 . 对于perspective_employees，我建议一个单独的表，其中包含日期，然后在需要该信息时与employee表联合 .

  这里很难详细说明，但我希望你能得到我所说的基础知识 .

  此致，罗杰

  回复于 2024-05-11T03:20:24+08:00