模板->实例化模型中外键的规范化问题
首先,我的平台是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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我认为在原件中的
JOB_PARAMS
中包含TASK_ID
没有任何问题。然而,如果它看起来太混乱,你可以尝试这个。创建新作业时,每个任务 (1,2,3..) 的
TaskSequenceNo
都会递增。Job_ID
是可选的——如果存在,则唯一且不为空
。JobParams
有两个 FK 约束,例如(可能需要调整句法):I do not see anything wrong with having
TASK_ID
inJOB_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. TheJob_ID
is optional -- if present thenunique not null
.There are two FK constraints on
JobParams
, something like (may need to adjust syntax):