Нормализация вопроса для внешнего ключа в шаблоне -> модель создания - PullRequest
1 голос
/ 15 июня 2011

Прежде всего, моя платформа - 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, которая используется для хранения фактических значений параметров для этого конкретного задания. Конечно, у него есть внешний ключ JOB_ID для таблицы JOBS, но он также должен иметь точное отношение к порядковым номерам в 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, потому что TASK_ID отсутствует в JOB_PARMS.

Это говорит о том, что TASK_ID должен присутствовать в JOB_PARMS, чтобы разрешить полный составной ключ для отношения внешнего ключа обратно к TASK_PARMS. Однако, поскольку задание действительно является только экземпляром задания, поле TASK_ID в JOB_PARMS никогда не изменится для одного значения JOB_ID. Кажется, это нарушает нормализацию.

У меня такое ощущение, что я что-то здесь упускаю. Я мог бы просто вставить TASK_ID в файл JOB_PARMS и продолжить с ним, но мое чувство всего, что правильно, хочет знать, где я иду не так.

1 Ответ

0 голосов
/ 16 июня 2011

Я не вижу ничего плохого в том, что TASK_ID in JOB_PARAMS в вашем оригинале.

Однако, если это выглядит слишком запутанно, вы можете попробовать это.TaskSequenceNo увеличивается для каждой задачи (1,2,3 ..) при создании нового задания.Job_ID является необязательным - если присутствует, то unique not null.

enter image description here

Есть два ограничения FK на JobParams, что-то вроде (может потребоваться настроить синтаксис):

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)
;
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...