Проектирование базы данных и нормализация, когда два ФК имеют отношение

Question

Я пытаюсь разработать веб-приложение на Java, которое может работать с различными объектами по разным путям.Эти объекты и пути будут определены в БД как Классы рабочего потока и Рабочие элементы .Сейчас я работаю над объектом Calculation Assignment, который получает путь своего рабочего потока на основе выбранного уровня вычислений.

Вот мои таблицы для выполнения текущих вычислений:

TPQOT_CALC_ASSIGNMENT "Calculation Assignment - Main Object"
=====================
CONSTRAINT dup_wf_instance UNIQUE (WORKFLOW_INSTANCE_ID) 
---------------------
CALC_NUM (PK)        VARCHAR2(6)  "Calculation Number"
CALC_REV (PK)        VARCHAR2(2)  "Calculation Revision Designator"
CALC_DEPT (PK)       VARCHAR2(3)  "Calculation Originating Department"
CALC_LEVEL_ID (FK)   VARCHAR2(24)  "Calculation Level ID"
WORKFLOW_INSTANCE_ID (FK) VARCHAR2(24)  "Workflow Instance Unique ID"


TPQOT_CALC_LEVEL_WORKFLOW "Calculation Level To Work Flow Class Lookup Table"
=========================
CONSTRAINT dup_calclvlwf UNIQUE (CALC_LEVEL, DEPT_OWNER, WORKFLOW_CLASS_ID)
CONSTRAINT dup_calclvl   UNIQUE (CALC_LEVEL, DEPT_OWNER)
-------------------------
CALC_LEVEL_ID (PK)     VARCHAR2(24) "Calculation Level To Work Flow Type Unique ID (Surrogate)"
CALC_LEVEL             VARCHAR2(3) "Calculation Level"
DEPT_OWNER             VARCHAR2(3) "Department Owner"
WORKFLOW_CLASS_ID (FK) VARCHAR2(24) "Work flow Class Unique ID"


WF_WORKFLOW_INSTANCE "Workflow Instances"
====================
WORKFLOW_INSTANCE_ID (PK)  VARCHAR2(24)  "Work Flow Instance Unique ID"
WORKFLOW_CLASS_ID (FK)     VARCHAR2(24)  "Work Flow Class Unique ID"  
STARTED_BY                 VARCHAR2(9)  "Work Flow Instance Started By Badge"  
LAST_DATE                  DATE         "Last date instance was worked"
STATUS                     VARCHAR2(3)  "Workflow Instance Status"


WF_WORKFLOW_CLASS "Workflow process classes by department Reference Table"
=================
CONSTRAINT dup_workflow UNIQUE (DEPT_OWNER, NAME)
-----------------
WORKFLOW_CLASS_ID (PK)   VARCHAR2(24) "Work flow Class Unique ID (Surrogate)"
DEPT_OWNER               VARCHAR2(3)  "Department Owner"
NAME                     VARCHAR2(64)  "Short Name"
DESCRIPTION              VARCHAR2(256)  "Description"
VERSION                  VARCHAR2(2) "Version Number"

Когда пользователь запускает новый рабочий процесс расчета, он выбирает уровень вычисления из раскрывающегося списка, который сообщает мне, какой WORK_FLOW_CLASS_ID Iследует сохранить в таблице WF_WORKFLOW_INSTANCE, когда они нажимают кнопку отправить.

В таблице TPQOT_CALC_ASSIGNMENT хранятся два внешних ключа - CALC_LEVEL_ID & WORKFLOW_INSTANCE_ID - оба относятся к одному и тому же WORK_FLOW_CLASS в своих уважаемых таблицах.

Что если редактировать данные Назначения расчета и уровень Calcизменяется с Calc уровня II на Calc уровня III (который относится к различным классам рабочих процессов)?

Это недостаток, который будет преследовать меня в будущем?Я понимаю, что могу написать код, чтобы убедиться, что если уровень Calc обновлен, то убедиться, что новый экземпляр рабочего процесса создан соответствующим образом.

Вы можете удивиться, почему у меня нет уровня Calc прямо в экземпляре рабочего процесса.Это потому, что я могу захотеть создать еще один объект для рабочего процесса, который не использует поле уровня и может иметь только один путь.Например, резюме соискателя.

JOB_APPLICANT 
=====================
APPLICANT_ID (PK)
FIRST_NAME
WORKFLOW_INSTANCE_ID (FK)

==== РЕДАКТИРОВАТЬ ==== Что если я просто удалю CALC_LEVEL_ID из таблицы TPQOT_CALC_ASSIGNMENT?Таблица TPQOT_CALC_LEVEL_WORKFLOW будет использоваться для понижения уровня Calc, что дает мне WORKFLOW_CLASS_ID для создания WF_WORKFLOW_INSTANCE?При просмотре формы назначения калькуляции я смогу объединить таблицы и получить метку уровня калькуляции.Есть мысли?

Answer 1

Что делать, если редактируются данные Назначения расчета и Уровень расчета изменен с Calc уровня II на Calc уровня III (который относится к разные классы рабочего потока)?

Если это обновление, которое вы намереваетесь разрешить, то вы несете ответственность за надлежащую реакцию на это обновление. Вам может потребоваться отозвать разрешения для базовых таблиц и обрабатывать все обновления через обновляемое представление или хранимую процедуру. Или вам может понадобиться написать один или несколько триггеров.

Если это обновление вы не должны разрешать, то вы не должны разрешать его. Вы можете предоставить только привилегии INSERT и DELETE и отозвать привилегии UPDATE. Возможно, есть и другие способы.

Разрешение на обновление без соответствующей реакции оставляет вашу базу данных в недопустимом состоянии. Поскольку это требование должно применяться ко всем пользователям, в идеале оно должно быть в базе данных, а не в коде приложения.

Answer 2

Если вы считаете, что отмена обновления слишком ограничительна, вы можете применить правило с помощью простого триггера, чтобы вызвать ошибку, если уровень calc обновляется без изменения идентификатора рабочего процесса:

CREATE OR REPLACE TRIGGER trg_chk_class_change
BEFORE UPDATE
ON tpqot_calc_assignment 
REFERENCING NEW AS New OLD AS Old
FOR EACH ROW
DECLARE

BEGIN   
    IF :NEW.calc_level_id <> :old.calc_level_id AND :NEW.workflow_class_id  = :OLD.workflow_class_id  THEN
        raise_application_error(-20001, 'Class change only allowed if workflowid is changed'); 
    END IF;    
END;