Динамические типы в реляционной модели с использованием объектно-ролевого моделирования (ORM)

Question

В объектно-ролевом моделировании (ORM) для сущности вещь , которая имела отношение к сущности типа , где сущность типа может быть указана для жизни и для вещи сущность может иметь значение для даты рождения, как бы я указал ограничение, которое исключало бы экземпляры вещи из значения даты рождения, если бы экземпляр типа, связанный с вещью, не был установлен для жизни. См. Схему ниже ...

ORM Диаграмма модели, которая будет ограничена http://img197.imageshack.us/img197/6551/dynamictypeorm.jpg

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

Answer 1

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

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

Мы можем использовать либо ограничение подмножества, либо ограничение равенства, в зависимости от того, что именно вы хотите записать.

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

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

дополнения:
Чтобы создать эти типы ограничений на подмножество и равенство, которые будут работать, нам нужно использовать нечто, называемое 'Join Path' . Используя путь соединения, мы можем создать ограничение «Соединение-подмножество» и ограничение «Соединение-равенство», которое будет охватывать несколько ролей с обеих сторон ограничения. Примеры путей соединения иногда могут быть очевидными и легко понятными. но может также быть немного подавляющим и сложным время от времени. Также следует отметить, что хотя NORMA поддерживает создание путей соединения, в условиях равенства, подмножества и исключения исключение для них не завершено на 100%, как объяснено здесь . Это также одна из причин того, что в настоящее время проще использовать Подмножества, поскольку легче концептуально проверить правильность модели.

Чтобы создать Путь соединения в NORMA при назначении ролей для ограничения Подмножество, Равенство или Исключение, сначала назначьте все роли, являющиеся частью пути, одним щелчком, а затем дважды щелкните, чтобы перейти к следующему пути. Когда ограничение способно объединять пути, роли, участвующие в этом ограничении, будут помечены [#. #] Вместо просто [#]. Поэтому, когда мы создаем наши ограничения, мы можем сказать, что роли [1.1] и [1.2] являются подмножеством / равны ролям [2.1] / [2.1]. Обратите внимание, что факты, играющие роль в каждой роли, также должны совпадать. Таким образом, он мы получаем вербализацию от NORMA:
Если у некоторой вещи есть какой-то элемент DateOfBirth; некоторая вещь имеет некоторый тип, тогда эта вещь имеет некоторый тип; этот тип живет. Что лучше сформулировать так: если у некоторой вещи некоторого типа есть какой-то объект DateOfBirth; тогда этот Тип живет.

Однако есть третий (и предпочтительный) способ, которым мы могли бы ограничить это, который был бы подтипом. Так как вещи, которые живы, и вещи, которые не живы, очень разные, мы, вероятно, не хотим отображать их в те же таблицы в любом случае. Здесь мы разделяем наш Тип факта на два подтипа, OrganicTypes и NonOrganicTypes. Ограничение «Исключительно или» между двумя подтипами говорит нам, что каждый тип является органическим или неорганическим. и в примечании говорится о правиле деривации, которое мы используем для определения, к какой группе принадлежит тип. Оттуда мы переопределяем нашу роль [Вещи имеет тип] в [Живое существо имеет органический тип]. и поскольку OrganicThings путем дефиниции способны к жизни, наше ограничение для DOB / live теперь встроено в модель.

Answer 2

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

Кроме того, вы захотите уточнить, означает ли отсутствие факта «Тип живет» «Тип не живет» (Предположение о закрытом мире), или же оно подразумевает только «Тип неизвестен, чтобы жить» (Открытый мир Предположение, я думаю).

Еще одна проблема, с которой я столкнулся, заключается в том, что ваш вопрос выглядит несколько запутанным, объединяя «реляционную модель» и «ORM» в одном «предложении». Объектно-ролевое моделирование - это инструмент концептуального моделирования для создания концептуальных моделей, которые затем могут быть сопоставлены с реляционной схемой. Даже если вы реинжинирируете существующую реляционную схему, лучше всего использовать схему как часть информации, которую вы использовали бы для создания правильной концептуальной модели. Кроме того, используйте примеры правильного ввода и вывода, а также обсуждения с экспертами в области. Это часто поможет вам обнаружить важные ограничения, которые не были захвачены реляционной схемой или которые могли быть захвачены неправильно.

---

Кстати, о превосходном инструменте ORM см. NORMA . Это дополнение к Visual Studio 2005 или 2008 (Standard Edition или выше), использующее современную нотацию ORM2. Он может генерировать SQL для нескольких различных баз данных, а также диаграммы ER и даже код.

---

Также см. Книгу:

Answer 3

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

Псевдо-код:

 function fn_count_living(id)
     declare @count int
     select @count = count(*)
     from entities inner join types on entities.typeid = types.id
     where entities.id = id and types.living = 1
     return @count
 end

Constraint

 fn_count_living(entity_id) = 1 or dob is null

Answer 4

ORM (и модель домена ), насколько я понимаю, представляют собой концептуальную модель , которые используются для анализа бизнес-сферы вместо разработки решений. На этом уровне вводить понятия, такие как «типы» или «динамические типы», слишком рано, и это не соответствует цели модели.

С Моделирование ролей объектов: обзор

альтернативный текст http://i.msdn.microsoft.com/Aa290383.dv_vsea_ormoverview_06%28en-us,VS.71%29.gif

Вы можете поместить ограничение равенства (пунктирная линия с обведенным кружком символом «=») между «жив» и «имеет дату рождения». Похоже на "находится в должности" и "заключен контракт до."