Как гарантировать целостность данных в сложных отношениях один ко многим?

Question

Предположим, у нас есть 4 таблицы, как описано ниже:

Table 1: Element  
element_id [integer] (PK)  
element_name [varchar]

Table 2: Element_Property  
property_id [integer] (PK)  
element_id [integer] (FK to Element.element_id)  
data_type [integer]

Table 3: Page_Elements  
page_element_id [integer] (PK)  
element_type_id [integer] (FK to Element.element_id)  
element_name [varchar]

Table 4: Page_Elements_Property_Values  
property_value_id [integer] (PK)  
page_element_id [integer] (FK to Page_Elements.page_element_id)  
property_id [integer] (FK to Element_Property.property_id)  
value [varchar]

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

Учитывая взаимосвязь между таблицами, описанными выше: Как гарантировать, по замыслу, что каждое значение свойства в таблице 4 ( Page_Elements_Property_Values ​​) ссылается на свойство в таблице 2 ( Element_Property)) принадлежит типу элемента в таблице 3 ( Page_Elements )?

Я приведу пример, чтобы объяснить это более подробно:
TextBox - это элемент, 'Длина'является свойством TextBox.«Высота» является свойством какого-либо другого элемента.«MyTextBox» является элементом страницы типа «TextBox», теперь ... Как гарантировать, что в таблице 4 ( Page_Elements_Property_Values ​​) у нас не будет значения «Height», ссылающегося на «MyTextBox»?

Реальная структура базы данных немного сложнее и имеет некоторые отношения «многие ко многим», но этой идеи достаточно для описания проблемы.

Любая помощь или руководство приветствуются!

Answer 1

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

Answer 2

Ну, задача не из легких. Тем не менее, это может помочь, если вы должны были представить список допустимых значений свойств для каждого типа элемента - каталог. Затем распространите ElementTypeID и PropertyID в таблицу фактических свойств. Что-то вроде

Вы также можете рассмотреть возможность использования отдельных таблиц для строковых, целых и числовых свойства для обеспечения типа данных для каждого.

Answer 3

Это та проблема, с которой ссылочная целостность в базе данных не подходит для решения.RI в определении схемы может навязывать прямые отношения между сущностями, но не может многое сделать для согласованности косвенных связей между другими записями (и их отношениями) в той же таблице.

СпособДля обработки этого типа требования необходимо использовать перед вставкой и перед обновлением триггеры для проверки согласованности записи, которая собирается быть записана с другими записями под тем же родителем.Если вы попытаетесь добавить к экземпляру текстового поля свойство, которое не применяется к текстовым полям, ваш триггер отклонит обновление / вставку и выдаст ошибку.