Проблемы с нулевым или однозадачным или одним отношением

Question

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

К ним относятся 1-к-1, многие-ко-многим и 0 или 1-к-0 или 1. 1: 1, : и 0..1: 0..1.

Первые два имеют простые решения.

1. 1-к-1 может быть решена путем преобразования в 0..1-к-1 или 1-к-0..1, 0..1: 1 или 1: 0..1.

2. многие-ко-многим может быть решена с помощью таблицы в середине отношений, а затем либо 1: * и : 1 или 0..1: и *: 0 .. 1 или некоторые аналогичные комбинации. Я думаю, что есть четыре возможные комбинации, которые разрешают это.

Однако я застрял на 0..1-to-0..1. На самом деле, у меня есть такой набор таблиц, которые, похоже, имеют эти логические отношения.

В моем случае у меня есть четыре стола. Для аргумента предположим, что все они имеют первичные ключи типа INT. Таблицы - это люди, организации, клиенты и сотрудники.

Слово о логике. Организации могут иметь людей, их называют «Контакты» в отношениях. Люди могут быть либо Клиентом, либо Работником, либо и тем, и другим.

Организации < -> есть Контакты < -> as People. Это отношение 0..1: *. Это означает, что Человек может существовать с Организацией или без нее и что у Организации может быть много людей (или нет).

Сотрудник должен иметь запись человека, и это отношение имеет смысл. Это отношение 0..1: 1, когда у Работника должно быть Лицо, но у Лица может быть 0 или 1 запись сотрудника.

Но это не имеет смысла, поскольку наследование сущности движется в обоих направлениях логически. В случае Людей или организаций Клиенту. Клиент может быть либо Организацией, либо Лицом, но не обоими, а выбор производится через поле «Тип». Точно так же лицо не обязательно является Клиентом, это может быть Сотрудник или какой-либо другой тип контакта позже. Я не могу требовать, чтобы Лицо было Клиентом, и я не могу требовать, чтобы Клиент был Лицом. Точно так же я не могу требовать, чтобы Организация была Клиентом, и я не могу требовать от Клиента быть Организацией. Таким образом, необратимость наследования также необходима. В случае как Клиента: Лица и Заказчика: Организация, им необходимо реализовать 0..1: 0..1 и 0..1: 0..1. Но языковые инструменты не поддерживают его. Поскольку они являются строго типизированными языками, наследование объектов может протекать только в одном направлении. Даже на слабо типизированных языках вы все равно приходили бы в ситуацию, которая была первой: курица или яйцо.

JavaScript, возможно, подходит для этого случая, поскольку вы можете динамически изменять структуру типа объекта, и вы всегда можете объединить две структуры в любом порядке, даже если вы не могли явно объявить объект в этом манера.

Но мой инструмент на сегодня - это Microsoft LightSwitch, и он не сделает этого вообще. Я не думаю, что существует современный инструмент моделирования, который будет генерировать и набирать строго типизированный код языка, который позволит этот тип отношения.

Есть ли трюк, который преодолевает это отношение, 0..1: 0..1, или есть что-то фундаментальное, что я еще не понял? Я остаюсь здесь, чтобы выбрать сторону, и я не знаю, какая сторона выигрывает: Клиент или Лицо, Клиент или Организация. Но, возможно, есть что-то еще, что я могу сделать, не ставя под угрозу любой случай. Есть что-то в том, что нарушена модель?

Спасибо!

Answer 1

Модель 0..1 обычно является отношением is-a. Это сопоставляется с Inheritance в C#. В C# вы не можете создавать классы, которые наследуются от нескольких других классов (только через интерфейсы)

Ваша модель чисто моделируется как реляционная база данных, но она не относится к структуре объекта, которая не имеет множественного наследования. Определите модель на C#, которая работает (используя наследование и отношения), затем создайте для нее Datamodel, так как в этом случае C# является ограничивающим фактором.

Помните, что вы можете использовать наследование:

Customer 
<--is-a- Corporate Customer --has-a-- Organization --has-many-| 
<--is-a- Natural Customer --has-a-- Person <--is-a- Employee 

В этом случае вы не сможете бросить Customer непосредственно к человеку или организации, но вы можете получить запись, которая связана с этот класс, который чувствует себя естественно для меня. Но Employee всегда является Человеком (что имеет смысл).

Если вы хотите, чтобы унаследовать как Organization, так и Person от LegalEntity. Либо в модели выше (сохраняя Natural/Corporate Customer),

Customer<T:LegalEntity> -----------has-a--------------- LegalEntity 
^               ^ 
|--is-a- Customer<Organization> (--has-a--) Organization -is-a-| --has-many 
L--is-a- Natural<Person>  (--has-a--) Person -------is-a-|  | 
              ^      | 
               L--is-a- Employee -------| 

Но вы можете также упростить модель дополнительно в этом случае:

Customer 
    |--has-a LegalEntity <---is-a-- Organization --has-many-| 
         L-is-a-- Person <--is-a- Employee 

Или вы можете использовать Person в качестве основы, но это приводит к более уродливая модель:

Person 
<- Employee ---- Organization <- Corporate Customer 
<- Natural Customer ----|    | 
      |       | 
      L------------------------------->> ICustomer 

В этом случае ваш Person может быть либо Employee или Natural Customer (но не оба), а также вы не можете CRE съел список Customer, который содержит как Natural Customer, так и Corporate Customers, за исключением интерфейсов, но Entity Framework не всегда это понимает. Эта модель кажется неудобной, но кажется ближе к вашей нынешней модели.

Полная модель верности, которую вы хотите, не может быть построена с использованием .NET или Entity Framework.