Модель данных для объектно-реляционных данных

Модель данных для объектно-реляционных данных

Иллюстрации

Показать все

Реферат

Эта заявка испрашивает приоритет на основании предварительной заявки на выдачу патента США №60/657295, озаглавленной «DATA MODEL FOR OBJECT-RELATIONAL DATA» («МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-РЕЛЯЦИОННЫХ ДАННЫХ») и поданной 28 февраля 2005 года, а также имеет отношение к находящейся на рассмотрении заявке на выдачу патента США №11/171905, озаглавленной «PLATFORM FOR DATA SERVICES ACROSS DISPARATE APPLICATION FRAMEWORKS» («ПЛАТФОРМА ДЛЯ СЛУЖБЫ ПЕРЕДАЧИ ДАННЫХ ЧЕРЕЗ РАЗНОРОДНЫЕ КАРКАСЫ ПРИЛОЖЕНИЙ»), поданной 30 июня 2005 года.

УРОВЕНЬ ТЕХНИКИ

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

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

Разработчики этих приложений справляются с этими недостатками, описывая данные с использованием объектно-ориентированного проектирования, реализованного на языках программирования, таких как C#. Они, в таком случае, переносят SQL-данные в и из объектов либо вручную, либо с использованием некоторой разновидности объектно-реляционной технологии. К сожалению, не каждый объектно-ориентированный проект может быть легко приведен в соответствие заданной SQL-реализации или, в некоторых случаях, какой бы то ни было SQL-реализации, порождая значительный объем работ ручного программирования ввиду того, что разработчикам приходится иметь дело с различиями.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

Раскрытым изобретением является обогащенная модель данных, названная Общей моделью данных (CDM). Она поддерживается платформой, которая ее реализует, названной Общей платформой данных (CDP). CDM является моделью данных, общей для многочисленных специфичных приложений моделей данных. Например, она может поддерживать как PIM-данные (организатора персональной информации) приложения конечного пользователя, так и важные коммерческие (LOB) данные. Подобным образом, приложение со своей собственной моделью данных, такой как SDM (модель описания системы) Microsoft Windows™, может задавать свою модель поверх CDM. CDM делает возможной улучшенную функциональную совместимость между приложениями.

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

Один из примеров, где CDM превосходит SQL, заключается в определении отношений. В SQL отношение между потребителем (Customer) и заказом (Order) не может быть выражено явным образом. Является допустимым выражать ограничение внешнего ключа, из которого может быть выведено отношение, но внешний ключ является только одним из многих способов для реализации отношений. В CDM отношение может быть выражено явным образом и обладает атрибутами, таким же образом, как содержит атрибуты описание таблицы. Отношения являются первоклассным участником. Второй пример состоит в том, что CDM содержит систему типов для объектов, которая позволяет ей более естественно осуществлять интеграцию с CLR.

В еще одном ее аспекте предусмотрена альтернативная реализация CDM, в которой отношения определены на высшем уровне с использованием элементов <Association> или <Composition>. Соответственно, нет необходимости определять свойство по источнику (или родителю) для того, чтобы определить ссылочную (Ref) ассоциацию (или композицию).

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 иллюстрирует архитектуру общей модели данных (CDM) в соответствии со связанным изобретением.

Фиг.2 иллюстрирует способ предоставления CDM в соответствии с новым аспектом.

Фиг.3 иллюстрирует компонент отношения и его разновидности.

Фиг.4 иллюстрирует компонент объектной сущности, его членов и типы членов.

Фиг.5 иллюстрирует окно LOB-приложения для изображения основных признаков модели данных изобретения.

Фиг.6 иллюстрирует окно LOB-приложения и каким образом структурные отношения между объектными сущностями отражены в окне LOB-приложения по фиг.5.

Фиг.7 иллюстрирует композицию объектных сущностей в виде наложенного на окно LOB-приложения по фиг.5.

Фиг.8 иллюстрирует примерную LOB-модель, использующую концепции CDM, которая использует отношения объектных сущностей, сводные таблицы и их адресацию, и ограничительные условия в соответствии с изобретением.

Фиг.9 иллюстрирует использование ключей и идентификаторов объектной сущности в соответствии с CDM.

Фиг.10 иллюстрирует UML-представление некоторых подставляемых типов.

Фиг.11 иллюстрирует UML-представление некоторых типов объектной сущности.

Фиг.12 иллюстрирует UML-представление некоторых типов при композиции.

Фиг.13 иллюстрирует визуализацию экземпляра D в TS.TableD.

Фиг.14 иллюстрирует SQL-таблицы, которые соответствуют таблицам объектных сущностей по фиг.13.

Фиг.15 иллюстрирует платформу данных, которая может использовать CDM раскрытого изобретения.

Фиг.16 иллюстрирует фрагменты метамодели CDM, которые проясняют семантику модели, имеющую отношение к типам.

Фиг.17 иллюстрирует фрагменты метамодели CDM, которые проясняют семантику модели, имеющую отношение к свойствам.

Фиг.18 иллюстрирует фрагменты метамодели CDM, которые проясняют семантику модели, имеющую отношение к ассоциациям.

Фиг.19 иллюстрирует четыре основных концепции альтернативной реализации CDM.

Фиг.20 иллюстрирует, что CDM поддерживает понятие наследования типа.

Фиг.21 иллюстрирует таксономию типов CDM для этой реализации.

Фиг.22 иллюстрирует общее представление типов и экземпляров в этой реализации CDM.

Фиг.23 иллюстрирует, каким образом типы объектной сущности и подставляемые типы объявляются с использованием SDL.

Фиг.24 иллюстрирует многие виды отношений, поддерживаемых CDM.

Фиг.25 иллюстрирует структурную организацию для сделанных устойчивыми объектных сущностей в CDM.

Фиг.26 иллюстрирует использование расширений объектной сущности в этой реализации CDM.

Фиг.27 иллюстрирует фрагменты метамодели CDM альтернативной реализации, которые проясняют семантику модели, имеющую отношение к типам.

Фиг.28 иллюстрирует фрагменты метамодели CDM альтернативной реализации, которые проясняют некоторую семантику модели, имеющую отношение к свойствам.

Фиг.29 иллюстрирует фрагменты метамодели CDM альтернативной реализации, которые проясняют некоторую семантику модели, имеющую отношение к ассоциациям.

Фиг.30 иллюстрирует UML-диаграмму композиции по фиг.29, которая иллюстрирует некоторые аспекты отношения, показанного на нем.

Фиг.31 иллюстрирует усовершенствованные отношения альтернативной реализации.

Фиг.32 иллюстрирует структурную схему компьютера, работоспособного для приведения в исполнение CDM-архитектуры.

Фиг.33 иллюстрирует схематичную структурную схему примерной вычислительной среды, в которой CDM может быть использована.

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

Первоначально, со ссылкой на чертежи, фиг.1 иллюстрирует архитектуру 100 общей модели данных (CDM) в соответствии со связанным изобретением. CDM 100 включает в себя компонент 102 объектной сущности, который предоставляет объектную сущность данных, обладающую унифицированной идентичностью на всем большом количестве разнородных приложений. Компонент 104 отношения определяет отношение между двумя или более объектными сущностями данными.

CDM 100 является моделью данных, общей для многочисленных специфичных приложений моделей данных. Например, она может поддерживать как PIM-данные (организатора персональной информации) приложения конечного пользователя, так и важные коммерческие (LOB) данные. Подобным образом, приложение SDM-типа (модели описания системы Windows™) может задавать свою модель поверх CDM 100. CDM 100 делает возможной улучшенную функциональную совместимость между приложениями.

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

CDM связанного изобретения предусматривает по меньшей мере следующие новые аспекты.

• Система типов пополнена типами объектной сущности (Entity Type), подставляемыми типами (Inline Type), таблицами объектных сущностей (Entity Table), наборами таблиц (Table Set) и отношениями (Relationship)

• Проведение различий между типами объектной сущности и подставляемыми типами

• Типы объектной сущности включают в себя понятие идентичности и ключей (вместо определения их таблицами, как имеет место в SQL)

○ Явное объявление ключей, составленных из комбинаций свойств объектной сущности

• Разные виды отношений между объектными сущностями (ассоциации)

○ Компонуемость ассоциации объектной сущности с другими типами ассоциации

○ Ассоциации общего значения (Common Value)

○ Условные (Conditional) ассоциации (предусматривают более сложные отношения типа соединения)

• Факторизация атрибутов, заданных в объектной сущности (описания свойств), в зависимости от того, что задано в отношении (Relationship) (как такие свойства используются для соотнесения объектных сущностей)

• Вложенные таблицы (композиции)

• Расширения

○ Специфичные типу

○ Основанные на экземпляре или классе

○ Возможность порождения из других расширений

○ Возможность задавать таблицу-хранилище

• Расширяемые перечисления

• Объявление свойств навигации (Navigation) для отношений

• Задание области ассоциаций, чтобы применять только к конкретной таблице

• Группирование таблиц объектных сущностей (Entity Table) и отношений (Relationship) в наборы таблиц (Table Set)

• Возможность задавать таблицу, которая должна быть использована в описании объектной сущности (Entity), ассоциации или наборе таблиц

• Наборы атрибутов каждого описания типа

• Представление проекций в качестве анонимных типов

○ Возможность описывать анонимные типы подстановкой

• Задание ограничений типов

Последующее является текстовым описанием системы типов CDM, над которыми будет выполняться какая бы то ни была алгебра. Отступ указывает, что тип с отступом является разновидностью «выступающего» типа; например, тип Array (массива) является подставляемым (Inline) типом.

Type (тип) - абстрактная основа всех типов

Тип Entity (объектная сущность) - допускающий указание ссылкой тип (обладает уникальной идентичностью) со свойствами подставляемого (Inline) именованного типа

Подставляемый (Inline) тип - не обладает идентичностью

Тип Collection (коллекции)

Тип Array (массива) - однородное множество экземпляров подставляемого (Inline) типа

Тип Entity Table (таблицы объектных сущностей) - набор объектных сущностей

Тип Scalar (скалярный)

Тип Entity Ref (ссылки объектной сущности) - ссылка на объектную сущность

Тип Table Ref (ссылки таблицы) - это требуется для алгебры обновлений; он не должен использоваться в качестве типа свойства.

Тип Simple (простой) - примитивные типы без других членов, такие как int (целочисленный), string (строковый), Xml, FileStream (файлового потока)

Тип Enumeration (перечислимый)

Тип Array (массива) - однородное множество экземпляров подставляемого (Inline) типа; им является RowSet<I> (набор строк, возвращаемый по аргументу I)

Тип Complex (составной)

Тип Structured (структурированный) - тип с определяемыми пользователем свойствами; свойствами подставляемого (Inline) типа

Тип Anonymous (анонимный) - неименованный; переопределяемый при каждом использовании; имеет свойства подставляемого (Inline) типа

Тип Row Set (набора строк) - совокупность экземпляров подставляемого (Inline) типа или типа объектной сущности (Entity).

Тип Entity Table (таблицы объектных сущностей) - набор экземпляров типа Entity; им является сайт (место, где сохраняются экземпляры)

Тип Relational Table (реляционной таблицы) - однородное множество экземпляров анонимного (Anonymous) типа; он является сайтом

Фиг.2 иллюстрирует способ предоставления CDM в соответствии с новым аспектом. Несмотря на то, что, в целях простоты пояснения, один или более способов, показанных в материалах настоящей заявки, например, в виде блок-схемы алгоритма или диаграммы последовательности операций, показаны и описаны как последовательность действий, должно быть понято и принято во внимание, что связанное изобретение не ограничено очередностью действий, так как некоторые действия могут, в соответствии с ним, происходить в ином порядке и/или одновременно с другими действиями из тех, что показаны и описаны в материалах настоящей заявки. Например, специалисты в данной области техники будут понимать и принимать во внимание, что способ, в качестве альтернативы, мог бы быть представлен как последовательность взаимосвязанных состояний или событий, таких как на диаграмме состояний. Более того, не все проиллюстрированные действия могут потребоваться для реализации способа в соответствии с изобретением.

На 200 предоставлена схема, которая определяет пространство имен для задания области определений схемы. На 202 определяются типы объектных сущностей для группирования свойств и методов. На 204 определяется объектная сущность набора таблиц, чьими свойствами являются таблицы. На 206 семантические связи между объектными сущностями выражаются с использованием отношений (например, ассоциаций, композиций, …).

Объектные сущности моделируют объекты реального мира. Объектной сущностью является объект данных, который является уникально идентифицируемым в CDM с использованием его идентичности (ключа). Объектная сущность является наименьшей единицей, которая может быть совместно использована (указана ссылкой) с использованием ее идентичности. Объектная сущность обладает структурой (например, свойствами) и поведением (например, методами). Некоторыми примерами разных типов объектных сущностей являются заказ (Order), потребитель (Customer), деловой контакт (Contact), документ (Document), и тому подобное. Объектные сущности подобны типизированным строкам на SQL99 или объектам в ODBMS-системах. Объектные сущности определены как экземпляры типов объектной сущности. Ниже, только в целях примера, изложен синтаксис для описания объектной сущности:

<EntityType Name="Order" Key="OrderId">

<Property Name="OrderId" Type="Guid" Nullalbe="false"/>

<Property Name="Date" Type="DateTime" Nullalbe="false"/>

…

</EntityType>

Каждая объектная сущность обладает уникальной идентичностью, которая пополнена значениями ключей объектной сущности. Эта идентичность является основой для формирования ссылки на объектную сущность. Ключом объектной сущности является набор из одного или более свойств объектной сущности. Каждая объектная сущность обладает уникальной идентичностью, которая пополнена значениями ключей объектной сущности. Эта идентичность является основой для формирования ссылки на объектную сущность. Ключом объектной сущности является набор из одного или более свойств объектной сущности. Каждое описание объектной сущности неабстрактного типа должно задавать ключевые свойства или наследовать ключевые характеристики от базового типа объектной сущности. Значения ключевых свойств могут быть определяемыми пользователем или вырабатываемыми системой.

Идентификатор объектной сущности формируется из ключа объектной сущности плюс идентификатора содержащей или родительской объектной сущности для данной объектной сущности. Родительской объектной сущностью является объектная сущность, содержащая таблицу, в которой сохранена дочерняя объектная сущность - потомок. Ключу объектной сущности необходимо быть уникальным только в пределах ее таблицы - другая таблица может содержать объектную сущность с таким же значением ключа объектной сущности. Таким образом, идентификатор объектной сущности является уникальным согласно комбинированию значения ее ключа с идентификатором ее родителя. В некоторых случаях ключ может быть уникальным в масштабе всего хранилища, к примеру, при использовании глобально уникального идентификатора (GUID). CDM требует, чтобы идентификатор был уникален лишь в пределах элемента (например, EntitySet).

Идентичность полностью идентифицирует объектную сущность и может быть разыменована, чтобы возвратить экземпляр объектной сущности. Ссылка использует идентичность. При заданной объектной сущности может быть получено значение ее ссылки. Две объектные сущности тождественны тогда и только тогда, когда тождественны их идентичности. Синтаксисом ссылочного типа в CDM является «Ref(<entity_type>)», а свойства могут быть типа «ref»; такое свойство названо ссылочным свойством. Ссылочные значения могут быть сделаны устойчивыми; они являются долговременными ссылками на объектные сущности. Копирование ссылочных значений не копирует объектные сущности, на которые они ссылаются. Ссылочные значения, к тому же, могли бы обеспечивать навигацию в пределах языка запросов, например, посредством операторов Ref и Deref.

Ссылки дают возможность совместного использования объектных сущностей. Например, объектная сущность заказа может содержать ссылочное свойство потребителя (Customer). Все заказы для одного и того же потребителя будут иметь одинаковое значение для ссылочного свойства потребителя. Структура ссылки является определяемой реализацией. Ссылки и ключи могут быть открыты для воздействия в качестве типов в API (прикладном интерфейсе программирования). Реализация ссылки включает в себя информацию идентификатора для объектной сущности, на которую она ссылается, в том числе значения ключей и, возможно, таблицу, в которой объектная сущность находится. Она могла бы хранить ссылку в качестве значений индивидуальных ключей (давая возможность рационального объединения) или в качестве единого непрозрачного значения. Функции могли бы открывать для воздействия структуры ссылок, чтобы получать значения ключей или таблицу, содержащую объектную сущность.

CDM состоит из следующих основных понятий: объектная сущность и отношение. Объектной сущностью является набор непосредственно связанных данных с единой идентичностью. Отношением является механизм, который соотносит две или более объектных сущностей. Фиг.3 иллюстрирует компонент 102 отношения и его разновидности. Отношения описывают, каким образом соотносятся две или более объектных сущностей. Отношения 300 принимают одну из следующих форм.

Ассоциация 302 (Association) - наиболее общая форма отношения 300 между двумя или более объектными сущностями. Объектные сущности, названные сторонами, соотносятся одна с другой через явно заданное отношение источник-цель (подобное внешнему - первичному ключу) или посредством запроса. Каждая из сторон в отношении остается независимой от других сторон. Является допустимым обязывать одну сторону быть удаленной, когда удаляется другая сторона, или предохранять одну сторону от того, чтобы быть удаленной до тех пор, пока существует другая сторона.

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

Объектная сущность 306 ассоциации (Association Entity) определена там, где две или более объектных сущностей, сторон, связаны вместе отношениями по отдельной объектной сущности, объектные сущности ассоциации, которая сама может иметь свойства. Каждая из сторон на понятийном уровне остается независимой от других.

Фиг.4 иллюстрирует компонент 100 объектной сущности и его члены, и типы членов. Компонент 100 объектной сущности использует объектную сущность 400, которая является состоящей из членов объектной сущности. Поддерживаются следующие разновидности членов. Свойство 402 (Property) выделяет хранилище для экземпляра конкретного типа. Свойство 404 навигации (Navigation Property) упрощает запрашивание по всем объектным сущностям, соотнесенным ассоциацией. Расчетное свойство (Calculated Property) представляет рассчитываемые значения в качестве противопоставленных хранимому значению. Метод 408 представляет операцию, которая может быть выполнена.

Члены объектной сущности имеют типы членов и/или вмещают типизированные параметры. Следующие разновидности типов, подставляемые типы 412 (Inline Type) и табличные типы 414 (Table Type), имеются в распоряжении при описании членов объектной сущности. Подставляемым типом (Inline Type) является тип, чьи данные сохраняются внутри текста в объектной сущности. Подобно типам объектной сущности, подставляемые типы являются состоящими из членов. В отличие от типов объектной сущности, подставляемые типы не имеют идентичности сверх той, что наложена объектной сущностью, в пределах которой они находятся. Подставляемые типы могут быть объявлены непосредственно и охватывают некоторые другие разновидности типов в модели данных. Подставляемые типы (Inline Type) включают в себя следующие.

Простой подставляемый тип 416 (Simple Inline Type) - подставляемый тип, который не имеет внутренней структуры, которая является видимой в общей модели данных. Типы значений CLR являются простыми типами в общей модели данных. Перечислимый тип 418 (Enumeration Type) - набор именованных значений. Перечислимые типы 418 являются простыми типами, которые могут быть независимо и одновременно расширены многочисленными разработчиками без опасения конфликта. Тип 420 ссылки объектной сущности (Entity Reference Type) - долговременная ссылка на одиночную объектную сущность, возможно, включающая в себя ссылку на таблицу, в которой находится объектная сущность. Ссылки объектной сущности используются в соединении с ассоциациями, чтобы соотносить две объектные сущности. Тип 422 табличной ссылки (Table Reference Type) - долговременная ссылка на таблицу. Тип 424 массива (Array Type) - упорядоченная коллекция экземпляров подставляемого типа, иного чем массив.

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

Тип объектной сущности описывает членов объектной сущности. Типы объектной сущности могут быть порождены от базового типа объектной сущности, в каковом случае порожденный тип объектной сущности содержит все члены базового типа наряду с членами, описанными для порожденного типа. Типы объектной сущности могут быть независимо и одновременно расширены многочисленными разработчиками без опасения конфликта. Такие типы расширения объектной сущности не зависят от наследования типа. Типы объектной сущности и расширения объектной сущности не являются содержимыми типами.

Набор таблиц - экземпляр типа объектной сущности, который содержит нормированные таблицей свойства. Объявление набора таблиц создает одиночный именованный экземпляр типа и, таким образом, каждой из таблиц, которые он содержит. Набор таблиц создает место для хранения данных подобно способу, при котором создание базы данных создает место для хранения данных.

Далее, со ссылкой на фиг.5, проиллюстрировано окно LOB-приложения для изображения основных признаков модели данных изобретения. Объектная сущность заказа на покупку (Sales Order Entry) иллюстрирует данные, такие как номер заказа (Order Number), номер потребителя (Customer Number), имя потребителя (Customer Name) и информация о товаре заказа, такая как номер изделия (Item Number), описание (Description), количество (Quantity), и другую значимую информацию.

Фиг.6 иллюстрирует, каким образом структурные отношения между объектными сущностями отражены в окне LOB-приложения по фиг.5. Как указано ранее, двумя основными понятиями CDM являются объектная сущность и отношение. Объектной сущностью является объект с данными свойств и идентичности, которые уникально его идентифицируют. Отношением является способ для соотнесения объектных сущностей. На фиг.6 заказ (Order) и потребитель (Customer) являются двумя объектными сущностями, соотнесенными посредством ассоциации. Здесь, объектная сущность заказа (Order) ассоциативно связана только с одной («1») объектной сущностью потребителя (Customer). Интуитивно, потребитель может относиться к нулю или более («*») заказов. Объектные сущности обладают свойствами и могут наследовать друг от друга. Ассоциации реализуются разными способами: в качестве ссылки (например, Order.Customer), в качестве соединения между свойствами, в качестве объектной сущности, и т.д.

Ассоциации могут быть реализованы некоторым количеством разных способов. Один из подходов заключается в том, чтобы использовать ссылку (которая подобна указателю). В предыдущем примере по фиг.6 есть одна ссылка, которая является указателем из заказа (Order) на потребителя (Customer). Это просто реализует ограничение, при котором может быть один потребитель, соотнесенный с заказом. В одной из реализаций свойство ссылки может содержать в нем только одну ссылку.

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

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

Фиг.7 иллюстрирует композицию объектных сущностей в соответствии с изобретением, которые наложены на окно LOB-приложения по фиг.5. Композиция является включением, где один предмет заключает в себе другой, и таким образом, является не только отношением. Например, заказ (Order) содержит или заключает в себе набор объектных сущностей товаров заказа (OrderLine). Родительская идентичность плюс дочерняя идентичность вместе составляют полную идентичность потомка. Композиция изображается свойством таблицы объектных сущностей в родительской объектной сущности. Эта возможность повторного использования в пределах CDM табличного понятия для изображения композиции является полезной. Композиция (которая показана черным ромбом) ассоциативно связывает две объектные сущности как родителя, так и потомка. Каждый заказ (Order) содержит таблицу многих («*») объектных сущностей товара заказа (OrderLine) (или их производных). Родитель управляет временем существования потомка, так как потомок «живет» в пределах родителя, удаление родителя должно удалять потомка. Дочерней объектной сущности необходимо быть уникальной только среди других потомков в той же самой композиции.

Фиг.8 иллюстрирует примерную LOB-модель, использующую концепции CDM, которая использует отношения объектных сущностей, их сводные таблицы и адресацию, и ограничения в соответствии с изобретением. Линия со стрелкой изображает ассоциацию (например, ссылочное свойство), черный ромб указывает композицию (табличное свойство), а набор таблиц аналогичен базе данных. Набор таблиц является корнем дерева данных приложения. Набор таблиц является экземпляром типа набора таблиц. Типы набора таблиц содержат только нормированные таблицей свойства. То есть, типы набора таблиц участвуют только в композициях. Тип набора таблиц является разновидностью типа объектной сущности. Приложение создает данные посредством определения экземпляра типа набора таблиц, названного «набор таблиц» («table set») (например, определяет «Northwind» типа «NorthwindData»). Набор таблиц также описывает набор данных, которые устанавливаются в службе и, в конечном счете, в базе данных. Он является автономной и компонуемой единицей данных.

Когда объектная сущность (например, SalesData (данные продаж)) определена, она может быть соотнесена со многими иными объектными сущностями. Например, компания будет иметь набор заказов внутри нее и набор потребителей внутри нее. Это иллюстрирует пару разных композиций. Заказ (Ord