模板->实例化模型中外键的​​规范化问题

发布于 2024-11-15 06:04:15 字数 1707 浏览 1 评论 0原文

首先,我的平台是IBM i。这意味着我不习惯普通/通用术语,因此可能会稍微误用它们。

我正在构建一个数据库设计,它定义“任务”(操作模板)和“作业”,它们是任务的实例。

任务在 TASKS 表中定义,并且具有主键 TASK_ID。还有另一个表 TASK_PARMS 定义任务所需参数的属性。它具有 TASK_ID 和 PARM_SEQ 的复合主键,定义参数的顺序。 TASK_PARMS 和 TASKS 之间的 TASK_ID 上会有一个外键。这些是如何执行任务的模板(还有更多属性字段来实际定义某些操作,但它们与此问题无关)。下面的示例表值。

 TASKS                      TASK_PARMS
+---------+-----------+    +---------+----------+------------+
| TASK_ID | ATTRIBUTE |    | TASK_ID | PARM SEQ | ATTRIBUTES |
+---------+-----------+    +---------+----------+------------+
| FOO     | PGM_A     |    | FOO     |       10 | ALPHA10    |
+---------+-----------+    | FOO     |       20 | DEC5,0     |
                           +---------+----------+------------+

当我想要执行任务时,我会实例化一个作业。 JOBS 表有一个主键 JOB_ID,然后需要定义遵循哪个任务模板。因此它有一个 TASKS 主键 TASK_ID 的外键。由于作业由单个任务组成(概念上是单个任务的副本),因此从规范化的角度来看,这似乎是正确的。

有一个 JOB_PARMS 表用于保存此特定作业的实际参数值。当然,它具有 JOBS 表的 JOB_ID 外键,但它还必须与 TASK_PARMS 中的序列号具有精确的关系。

 JOBS                      JOB_PARMS
+--------+-----------+    +---------+----------+-----------+
| JOB_ID | TASK_ID   |    | JOB_ID | PARM SEQ | VALUE      |
+---------+----------+    +--------+----------+------------+
|     99 | FOO       |    |     99 |       10 | XY1000AA   |
+--------+-----------+    |     99 |       20 | 2048       |
                          +--------+----------+------------+

我的问题就在这里。我无法将 JOB_PARMS 中的序列字段设为 TASK_PARMS 的外键,因为 JOB_PARMS 中不存在 TASK_ID。

这表明 TASK_ID 必须存在于 JOB_PARMS 中,以允许外键关系的完整组合键返回到 TASK_PARMS。然而,由于作业实际上只是任务的实例,因此 JOB_PARMS 中的 TASK_ID 字段永远不会因 JOB_ID 的单个值而改变。这似乎打破了常态化。

我感觉我在这里错过了一些东西。我可以将 TASK_ID 粘贴到 JOB_PARMS 文件中并继续执行它,但我对一切正确的感觉想知道我哪里出了问题。

First of all, my platform is IBM i. That means I'm not used to normal/generic terms so may misuse them slightly.

I am building a database design which defines 'tasks' (a template of actions) and 'jobs' which are instantiations of tasks.

A task is defined in the TASKS table and will have a primary key TASK_ID. There is another table TASK_PARMS to define the attributes of the required parameters for a task. It has a composite primary key of TASK_ID and PARM_SEQ which defines the sequence of the parameters. There will be a foreign key on TASK_ID between TASK_PARMS and TASKS. These are then a template of how one performs a task (there are more attribute fields to actually define some actions, but they are not pertinent to this problem). Example table values below.

 TASKS                      TASK_PARMS
+---------+-----------+    +---------+----------+------------+
| TASK_ID | ATTRIBUTE |    | TASK_ID | PARM SEQ | ATTRIBUTES |
+---------+-----------+    +---------+----------+------------+
| FOO     | PGM_A     |    | FOO     |       10 | ALPHA10    |
+---------+-----------+    | FOO     |       20 | DEC5,0     |
                           +---------+----------+------------+

When I want to execute a task, I instantiate a job. The JOBS table has a primary key of JOB_ID and then needs to define which task template is being followed. So it has a foreign key to TASKS's primary key, TASK_ID. As a job is comprised of (conceptually, is a copy of) a single task, this seems to be correct from a normalisation perspective.

There is a JOB_PARMS table which is used to hold the actual parameter values for this particular job. It has, of course, a JOB_ID foreign key to the JOBS table, but it must also have an exact relationship to the sequence numbers in TASK_PARMS.

 JOBS                      JOB_PARMS
+--------+-----------+    +---------+----------+-----------+
| JOB_ID | TASK_ID   |    | JOB_ID | PARM SEQ | VALUE      |
+---------+----------+    +--------+----------+------------+
|     99 | FOO       |    |     99 |       10 | XY1000AA   |
+--------+-----------+    |     99 |       20 | 2048       |
                          +--------+----------+------------+

Herein lies my problem. I cannot make the sequence field in JOB_PARMS a foreign key to TASK_PARMS because the TASK_ID is not present in JOB_PARMS.

This suggests that TASK_ID must be present in JOB_PARMS to allow the complete composite key for the foreign key relationship back to TASK_PARMS. However, as a job is really just an instantiation of a task, the TASK_ID field in JOB_PARMS will never change for a single value of JOB_ID. This seems to break normalisation.

I get the feeling I'm missing something here. I could just stick the TASK_ID in the JOB_PARMS file and get on with it but my sense of all that is right wants to know where I'm going wrong.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

颜漓半夏 2024-11-22 06:04:15

我认为在原件中的 JOB_PARAMS 中包含 TASK_ID 没有任何问题。

然而,如果它看起来太混乱,你可以尝试这个。创建新作业时,每个任务 (1,2,3..) 的 TaskSequenceNo 都会递增。 Job_ID 是可选的——如果存在,则唯一且不为空

在此处输入图像描述

JobParams 有两个 FK 约束,例如(可能需要调整句法):

alter table JobParams
  add constraint fk1_jp foreign key   (TaskId, TaskSequenceNo)
                        references Job(TaskId, TaskSequenceNo)

, add constraint fk2_jp foreign key   (TaskId, Param_Seq)
                 references TaskParams(TaskId, Param_Seq)
;

I do not see anything wrong with having TASK_ID in JOB_PARAMS in your original.

However, if it looks too confusing you may try this one. The TaskSequenceNo increments for each task (1,2,3..) when a new job is created. The Job_ID is optional -- if present then unique not null.

enter image description here

There are two FK constraints on JobParams, something like (may need to adjust syntax):

alter table JobParams
  add constraint fk1_jp foreign key   (TaskId, TaskSequenceNo)
                        references Job(TaskId, TaskSequenceNo)

, add constraint fk2_jp foreign key   (TaskId, Param_Seq)
                 references TaskParams(TaskId, Param_Seq)
;
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文