Проблема
Вы не можете сделать это - внешний ключ (Reported_Id) не может ссылаться на три таблицы одновременно
Кажется, чтопроблема, связанная с занижением данных ... а не техническая проблема, связанная с тем, что FK указывает на три PK.
или один из трех, в зависимости от какого-то другого столбца в вашей таблице. Просто не может быть сделано.
Это не правильно. Такое требование довольно просто в реляционной базе данных:
Реляционная модель логична, она основана на исчислении предикатов первого порядка (он же Логика первого порядка)).
Наличие прочной математической основы дает ему большую силу.
отношения являются логическими существами
Физические Record IDs не логичны
нет предела тому, что может быть определено в FOL,
нет ничего, что может не быть определено в FOL
, поэтому нет ничего, что может не быть определено в реляционной базе данных (и, конечно, SQL, его подъязыке данных)
.
Обратите внимание, что то, что "теоретики" продвигают и позиционируют как "реляционные", на самом деле представляет собой систему регистрации записей 1960-х годов, которая не имеет никакой реляционной целостности;Относительная сила;или Реляционная скорость, которую имеет база данных, соответствующая Реляционная модель . Такие системы идентифицируются по их физическому использованию Record IDs. Да, в таких примитивных системах данные не являются логическими, и логические отношения или отношения не могут быть определены. Кроме того, требуемый код SQL ужасен.
То, что вы ищете в статье по логике, ИЛИ Gate . Необходимо определить специфику шлюза OR (существует несколько форм): это моделирование.
Данные
Забудьте о ID столбцах, которые служат только для урезания упражнения по моделированию данных. Сконцентрируйтесь на данных, что эти данные означают и к каким другим данным они относятся. Возможно, вы пытаетесь объявить что-то вроде этого (это FOPC / FOL Predicates ):
- Каждый пользователь независим
- Каждая фотография независима
- Каждое местоположение является независимым
- Каждый пользователь составляет от 0 до n отчетов
- Каждый отчет любой из {Фото |Расположение |Пользователь}
Это очень свободно, мы можем затянуть. Давайте перейдем к ...
Связи сущностей • Подтип
Эта модель данных (уровень ER) реализует кластер Неисключительный подтип для Отчета.
Все Предикаты являются явными в модели данных IDEF1X и, следовательно, могут быть читать из нее, однако я далсоответствующие предикаты в текстовой форме справа.
Обозначения
Все мои модели данных отображаются в IDEF1X ,Стандарт моделирования реляционных баз данных с 1993 года
My IDEF1X Введение является необходимым чтением для начинающих
IDEF1X Anatomy - это переподготовка для тех, кто скончался.
Неисключительный подтип - для получения полной информации см. Подтип Реализация подтипа.
- для контраста или интереса Эксклюзивный подтип , см. этот ответ .
Соотношение сущностей • Необязательный столбец
Приведенный выше реализует предикат:
- Каждый отчет любой из {Фото |Расположение |Пользователь}
означает, что в отчете должен быть хотя бы один из {Фото |Расположение |Пользователь}.
Однако, если это не так, если Report может иметь значение none of {Photo |Расположение |Пользователь}, что означает {Фото |Расположение |Пользователь} - это каждый необязательный столбец.
Определение
один из трех в зависимости от какого-то другого столбца в вашей таблице
Определение того, какие или все подтипы или дополнительные столбцы, которыеиспользуются для каждого отчета не является проблемой:
Эксклюзивный подтип
Да, для которого требуется столбец Дискриминатор в Базовый тип.
Неисключительный подтип
Существует несколько подтипов для базового типа, поэтому столбец «Дискриминатор» в базовом типе не имеет значения.
- Определение производится через
SELECT из таблицы подтипов (которая по определению имеет тот же PK, что и таблица базовых типов).
Необязательный столбец
Индикатор в базовом типе будет избыточным.
- Определение производится через
SELECT из таблицы необязательных столбцов (то же самое). - Обычно для базового типа можно создать
VIEW, например, Report_V, ивключить все возможные столбцы.