Способ связать их - через внешний ключ.
Но прежде чем копаться в этом, мне кажется, что вы пытаетесь разобраться с физической моделью данных, не понимая сначала логическую модель данных;Вы когда-нибудь посещали этот ресурс когда-либо?
Директора компаний, бенефициары и партнеры по трастам являются специализированными случаями контакта с общим случаем;но для этого вы должны исключить из таблицы контактов все поля (члены), которые сообщают, что контакт является физическим лицом (например, пол, DOB, все, что я не вижу).
Итак, просто добавьтеполе fk_contact в CompanyDirector, TrustBeneficiary и PartnershipPartner;после, свяжите поле контакта id в качестве первичного ключа со всеми этими полями внешнего ключа в условной связи 1: N.
Таким образом, вы получите связь N: N между Партнерским контактом,Траст-Контакт, Компания-Контакт;промежуточные таблицы являются ассоциативными сущностями, выраженными в виде таблиц.
Конечно, это зависит от того, какую БД вы используете для ее физической реализации.
И, искренне, я не думаю, чтовопрос был так плохо сформулирован ...
РЕДАКТИРОВАТЬ 1 - на основе разбросанных комментариев:
Таблица сущностей будет иметь FK в Company, Trust,Партнерство и любая другая новая сущность
Именно поэтому сущность не является хорошим и описательным именем ... теоретически все субъекты / объекты могут быть сопоставлены с какой-либо сущностью ...
Наличие оператора switch каждый раз, когда я хотел бы получить что-то, - это не самый простой и лучший способ, как мне кажется
Вот почему мы должны разделить логические и физические модели ... дажеесли что-то правильно на логическом уровне, мы можем физически смоделировать это другим способом, основываясь на том, насколько мы получим доступ к некоторому атрибуту / полю;иногда мы денормализуем таблицу, включая некоторый атрибут, который логически принадлежит дочерней таблице, просто чтобы не платить за доступ к диску или сети ...
И будет проще, если вы опубликуете эти 2 основныхчасти информации:
- Какое описание вашего обычного английского, без псевдокода, т. е. мини-мира?
- Какие отчетыВы должны представить, то есть, на какие вопросы вы должны ответить?
РЕДАКТИРОВАТЬ 2: здесь вместо комментариев из-за размера моих сомнений:
@ codejunkie, мне кажется, что LegalEntity в вашей модели толькоатрибут других участников / классов: таблицы Доверия, Компании и Партнерства имеют те же поля.
Фокусировка только в таблицах Партнерства / ПартнерстваПартнер:
возможна ли эта запись?относящиеся к кортежу
PartnershipPartner.PartnershipId = Partnership.Id
PartnershipPartner.LegalEntityId <> Partnership.LegalEntityId
Если нет, то я думаю, что лучше и более представительным способом является:
Одна большая таблица LegalEntity, которая имеет все общие атрибуты Доверия, Компании и Партнерства;вспомогательные таблицы в 1-0..1 вместе с ним для исключительных атрибутов.
И TrustBeneficiary, PartnershipPartner и CompanyDirector в аналогичной структуре, и что они разделяют, вероятно, является таблицей контактов, которая была в схеме ранее.
Рекурсия будет реализована так же, как и в классическом случае, когда Человек является Отцом Человека;роль станет ассоциативной сущностью.
РЕДАКТИРОВАТЬ 3: - на основе комментариев @ Feb / 01, 2019
Одна важная вещь, которую я не спросил или не заметил: Таблицы уже заполнены реальными данными, и вы пытаетесь выяснить, как их связать?Если это так, это многое изменит.
Но, если это не так:
Доверие, Компания и Партнерство имеют только Имя, Страна в качестве общего атрибута.и телефон.У них есть куча других свойств ... ... ни одно из них не является общим.
Понятно;но это не отрицает, что они являются специализациями общего Сущности;теперь я думаю вслух, пытаясь упорядочить разбросанные кусочки, которые у меня есть:
- LegalEntity мне кажется, что это универсальный тип / класс сущности или Supertype Entity;Доверие, Компания и Партнерство сужают - и «спекулируют», с биологической точки зрения, - сферу его действия;
Даже рискуя поговорить об очень элементарных вещах - дайте мне знать, если это так - вот простой пример, который мне кажется параллельным вашему случаю: подумайте об общей сущности Врач испециализированные учреждения - кардиолог, госпиталист, врач по внутренним болезням и т. д .;и Врач, как правило, специализируется на Личности или Контакте;Пациент также является специализированным случаем Персона или Контакта;и врач может даже стать пациентом!Здесь мы говорим о ролях в реальном мире.
Тот факт, что вы видите абстракции, называемые Доверие, Компания и Партнерство, с некоторыми общими общими атрибутами и множеством различных атрибутов, не говорит нам, следует ли нам тогда инкапсулировать в общий класс /сущность, как я склоняюсь или делаю наоборот, как показывает ваше изображение.Ваши «потребности в отчете», атрибуты и отношения, которые вам необходимо представлять и сохранять, являются руководством к идеальному логическому плану (ам).
Только после того, как мы сможем или сможем,обратить наше внимание на физический дизайн.
Но все кажется запутанным в вашем вопросе;это может вызвать отрицательные голоса, согласно комментариям.
Вернуться к комментарию:
PartnershipPartner.PartnershipId = Partnership.Id вы правы.
ОК
Но есть один факт, который плохо пахнет:
PartnershipPartner.LegalEntityId <> Partnership.LegalEntityId you are again correct.
Я не понимаю: все экземпляры LegalEntityType (из одного и того же имени таблицы) можно применить (через таблицу LegalEntity) ко всем таблицам?Я понимаю, что Trust, Partnership и Company получают один и тот же атрибут LegalEntityType, но не в том случае, если TrustBeneficiary, PartnershipPartner и CompanyDirector могут получать одинаковые экземпляры LegalEntityType при выполнении другой роли.Если это так, и даже если это не так;) лучше отредактировать ваше сообщение и добавить несколько примеров отчетов и / или некоторые примеры таблиц / листов, лучше, если они будут с денормализованными записями.
РЕДАКТИРОВАТЬ 4: На основе комментариев после 2 февраля 2019 года:
Я думаю, что это более точное представление о том, что вам нужно: 