Расширяемый язык запросов с поддержкой для расширения типов данных

Расширяемый язык запросов с поддержкой для расширения типов данных

Иллюстрации

Показать все

Реферат

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

По настоящей заявке на патент испрашивается приоритет по дате подачи предварительной заявки США № 60/784510, поданной 20 марта 2006.

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

Рассмотрим, например, приложение LOB. Как правило, такое приложение имеет дело с Customers (Клиенты), Orders (Заказы), OrderLines (Строки Заказа), Suppliers (Поставщики), Products (Продукты), Employees (Служащие), Shippers (Грузоотправители), Invoices (Счета-фактуры) и так далее. Каждое из этих понятий представляет отдельный расширенный тип данных со специальной структурой. Например, тип Customer (Клиент) имеет такие элементы, как CustomerID (Идентификатор Клиента), Company Name (Название Компании), Contact Name (Имя Представителя) и Address (Адрес), тип Order (Заказ) имеет такие элементы, как OrderID (Идентификатор Заказа), CustomerID (Идентификатор Клиента), OrderDate (Дата Заказа), OrderLines (Строки Заказа), DueDate (Дата Выполнения) и т.д. К любому из вышеупомянутых также могут предъявляться требования, например, для Address (Адреса) может требоваться PostalCode (Почтовый Код), который для США должен быть почтовым индексом США, который состоит из пяти символов, и каждый символ является цифрой между нулем и девятью. В Канаде PostalCode (Почтовый Код) должен иметь вид "ANA NAN", где A - буква, и N - число. Соответственно при моделировании почтовых кодов не достаточно просто определить его как строку (string) - на эту строку должны быть наложены дополнительные ограничения, ограничивающие диапазон возможных значений, которые она может принимать. Кроме того, между данными обычно существуют связи. Например, Order (Заказ) всегда может иметь связанного с ним Customer (Клиент), это связь - многие (Order)-к-одному (Customer). Products (Продукты) и Suppliers (Поставщики) имеют связь многие-ко-многим, потому что несколько продуктов могут поставляться одним поставщиком, и несколько поставщиков могут торговать идентичным продуктом.

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

Большинство приложений и сред разработки приложений создают свою собственную модель данных на основе систем, базирующихся на реляционной модели данных, для связывания рассогласования нагрузки между данными и средой прикладного программирования. Это потому, что большинству приложений, LOB, PIM, Information Worker (информационный работник) или другим, требуются такие концепции модели данных, как расширенная структура, связи, поведения и расширяемость. Эти концепции модели данных не поддерживаются в достаточной мере существующими моделями данных, и, кроме того, в настоящее время не существует соответствующих языков запросов для доступа к данным, если они будут организованы согласно более расширенной модели данных.

Современные иллюстративные кандидаты на метамодель данных включают в себя версию 1999 языка структурированных запросов (SQL99), общеязыковую среду исполнения (CLR), унифицированный язык моделирования (UML) и определение XML схем (XSD). Однако CLR является объектно-ориентированной средой императивного программирования времени выполнения и не имеет собственной модели данных или понятий ограничения целостности, связей или персистентности. В SQL99 отсутствуют такие концепции моделирования данных, как связи, и у него нет хорошей интеграции с языками программирования. Спецификация XSD не поддерживает такие концепции, как ключи, связи и персистентность, и является сложной и имеет громоздкое отображение в модели и реляционной базы данных, и времени выполнения. UML является слишком общим: в нем от разработчиков приложений требуется добавлять точную семантику, особенно для персистентности.

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

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

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

ПЕРЕЧЕНЬ ЧЕРТЕЖЕЙ

Системы и способы для расширяемого языка запросов с поддержкой для расширенных типов данных также описаны в соответствии с настоящим изобретением согласно прилагаемым чертежам, в которых:

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

Фиг.2 - главные компоненты архитектуры CDP, и, в частности, на ней изображен конвейер запроса, который может проводить запросы, сделанные с использованием расширяемого языка запросов, для расширенных типов данных, обсуждаемых более подробно ниже.

На фиг.3 изображено представление Outlook группировки по дате (group by date), аналогичное дружественному представлению с группировкой, формируемому с использованием вычисляемого метода согласно изобретению.

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

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

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

Иллюстративная модель данных и соответствующие механизмы поддержки данных

Иллюстративная модель данных и соответствующие механизмы поддержки данных могут быть включены в ряд таких технологий, как объекты данных Active X для платформы управляемого кода (ADO.NET), которая предназначена для обеспечения единообразного доступа к таким источникам данных, как сервер языка структурированных запросов (SQL) MICROSOFT®, а также к источникам данных, выставленных через связывание и встраивание объектов для базы данных (OLE DB) и расширяемый язык разметки (XML). Клиентские приложения совместного использования данных могут использовать ADO.NET для соединения с этими источниками данных и отыскания, обработки и обновления данных.

ADO.NET аккуратно разлагает доступ к данным из манипулирования данными в дискретные компоненты, которые могут использоваться отдельно или последовательно. ADO.NET включает в себя поставщиков данных.NET Framework для соединения с базой данных, исполнения команд и извлечения результатов. Эти результаты или обрабатываются непосредственно, или помещаются в объект DataSet ADO.NET для выставления их пользователю способом для данного случая, объединенными с данными из нескольных источников, или (удаленно) между звеньями. Объект DataSet ADO.NET может также использоваться независимо от поставщика данных.NET Framework для управления данными, локальными для приложения или поставляемыми из XML. Соответственно ADO.NET обеспечивает функциональные возможности разработчикам, пишущим управляемый код, подобный функциональным возможностям, обеспеченным разработчикам собственной COM технологией объектов данных Active X (ADO), знакомой специалистам в данной области техники.

В одном варианте осуществления платформа ADO.Net может быть расширена для обеспечения расширенного набора служб данных для приложений - по всему множеству таких сред разработки приложений, как интегрированные среды PIM и интегрированные среды LOB - для получения доступа к данным, их обработки и управления ими способом, который хорошо интегрирован со средой прикладного программирования. На фиг.1 изображено размещение этих функциональных возможностей в архитектуре поддержки приложения. Платформа общих данных (CDP) 100 может реализовывать ряд таких технологий, как платформа ADO.Net. Платформа общих данных (CDP) 100 и соответствующие технологии подробно обсуждаются в патентной заявке США 11/171905.

Архитектура поддержки приложения фиг.1 может включить в себя, например, источник 110 данных, например SQL SERVER®, WinFS® или базу данных ORACLE®; CDP 100, который обеспечивает службы расширенных данных для приложения и сред разработки приложений; набор услуг интегрированной среды, например UAF 120 и интегрированной среды 130 LOB, которые расширяют и дополняют функциональные возможности CDP 100; набор классов данных, например 122, 132, 140, которые инкапсулируют функциональные возможности интегрированной среды и общую логику приложения; и любое количество приложений 150, 160, 170, которые используют функциональные возможности, обеспеченные CDP 100 и интегрированными средами 120, 130, и/или классов 122, 132, 140.

Модель данных, которая поддерживается CDP 100, может содержать, например, модель данных сущностей-объектов (Entity Data Model, EDM), разработанную корпорацией MICROSOFT®, Редмонд, штат Вашингтон. EDM расширяет реляционную модель данных для приспособления нескольких сред разработки приложений, например LOB, PIM, Management (Управление) и т.д. EDM определяет абстракцию расширенного объекта для данных, моделирует расширенную семантику, например, связи данных, минимизирует рассогласование между структурами приложения и моделью данных, поддерживает определенные поведения приложения, поддерживает основные реляционные концепции, расширенные типы с наследованием и связи, и в целом обеспечивает концепции моделирования, которые перехватывают семантику данных независимо от звеньев развертывания и складов данных. EDM может быть включена в такие технологии, как ADO.NET.

На фиг.2 изображены главные компоненты архитектуры CDP 100, и, в особенности, на ней изображен конвейер запроса, который может (проводить) запросы, сделанные с использованием расширяемого языка запросов, для расширенных типов данных, обсуждаемых более подробно ниже. Термин "eSQL" будет использоваться в этом документе для ссылки на расширяемый язык запросов для расширенных типов данных, вариант осуществления которых подробно изложен ниже. На фиг.2 также изображено, как запрос плавно проходит через различные компоненты CDP 100.

Во-первых, приложение 200 выдает запрос поставщику 210 сервисов объектов как запрос eSQL. Поставщик 210 сервисов объектов может содержать службу 211 синтаксического анализатора, который анализирует запрос и преобразует его в каноническое дерево, и отображающие трансформации 212, которые выполняют любые отображающие трансляции (из модели данных приложения в EDM, как предусмотрено в этом документе) на каноническом дереве. Поставщик сервисов объектов далее может передавать каноническое дерево поставщику 220 отображения.

Поставщик 220 отображения инкапсулирует реляционные отображающие функциональные возможности объекта. Он содержит отображающие трансформации 222, которые выполняют отображающие трансляции на каноническом дереве. Поставщик отображения передает каноническое дерево в связующее устройство 230 для посреднических услуг.

Связующее средство 230 может содержать компонент 231 услуг компенсации запроса, который разлагает каноническое дерево и выполняет любые компенсации модели данных, затем передает одно или несколько канонических деревьев поставщику 240 накопителей.

Поставщик 240 хранилища транслирует каноническое дерево на его родной диалект, например на диалект SQL, например SQL 2000 или SQL 2005, или в формат встроенной базы данных или WinFS. Поставщик 240 хранилища исполняет запрос и возвращает сообщение, например сообщение, которое может быть отформатировано для передачи в интерфейс DataReader ("DataReader") или из него в связующее устройство 230.

Связующее средство 230 содержит услугу 232 ассемблирования результата/значения, которая ассемблирует, в случае необходимости, результаты из потенциально нескольких DataReader, возвращенных поставщиком 240 хранилищ. Результатом этой операции, выполненной 232, является единый DataReader в терминах пространства EDM.

Далее поставщик 220 отображения просто возвращает DataReader из связующего устройства 230 поставщику 210 сервисов объектов. Сервисы 210 объектов транслируют результаты поставщика 220 отображения в объектное пространство. Поставщик 221 сервисов объектов содержит компонент 213, который дополнительно осуществляет результаты как объекты и кэширует эти объекты в таблице идентификации. Наконец, приложение 200 использует результирующий DataReader.

Более конкретно, согласно нескольким существенным аспектам EDM, EDM, в целом, создается согласно четырем базовым концепциям: типы, экземпляры, сущности-объекты и связи. Эти концепции можно проиллюстрировать с использованием примера типичного приложения LOB. Такое приложение имеет дело с различными видами данных, например заказом, клиентом, строками заказа, адресом, поставщиком, продуктом, служащим и так далее.

В иллюстративном использовании EDM данные Customer можно рассматривать как сущность-объект. Сущность-объект представляет элемент данных верхнего уровня, с которым работает приложение. Customer может иметь несколько полей: CustomerID, CompanyName, ContactName, Address и Phone (Телефон). Каждое поле имеет тип, который определяет структуру данных, входящих в это поле. Например, CustomerID может быть строкой (string) фиксированной длины. Поля CompanyName и ContactName также могут иметь тип string. Customer непосредственно также имеет тип; так как Customer является сущностью-объектом, то этот тип можно назвать типом сущности-объекта.

Поле Address может отличаться от других полей: оно обладает внутренней структурой в виде других полей, например City (Город), State (Штат) и PostalCode. В EDM тип такого поля, как Address называют составным типом. Напротив, типы CustomerID, CompanyName и ContactName все могут быть простыми типами.

Поле Phone может состоять из нескольких номеров телефона, каждый из которых является строкой. Его называют коллекцией.

Тип определяет структуру данных и определенные ограничения на значения. Фактические данные хранятся в экземплярах этих типов. Каждый, кто знаком с объектно-ориентированным программированием, проведет очевидную аналогию: типы и экземпляры подобны классам и объектам соответственно.

И Customer, и Address сходны в том смысле, что у них обоих есть внутренняя структура: они состоят из нескольных полей. Но семантически и в отношении функционирования Customer отличается от Address. Customer действует как единица для запроса, операций обмена данными, транзакций, персистентности (создания и поддержания перманентных объектов) и совместного использования. Address, с другой стороны, всегда функционирует в пределах Customer и нельзя ссылаться или каким-либо другим способом воздействовать на него независимо. В EDM такие элементы данных верхнего уровня называются объектами. Все другие данные рассматниваются как встроенные в сущности-объекты.

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

Каждый заказ может состоять из нескольких строк заказа. Например, если вы заказываете пять книг на AMAZON.COM®, то данные о каждой книге составляют строку заказа. Это моделируется как другой вид связи, композиция. Каждый OrderLine в пределах композиции является сущностью-объектом.

Иллюстративные новые признаки eSQL

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

Спецификация eSQL, заданная ниже, содержит множество новых признаков, которые включают в себя, например, представление запросов и утверждений языка манипулирования данными (DMLs - термин "запрос", используемый в этом документе, относится к запросам и DMLs) в терминах языка моделирования данных с поддержкой для расширенных типов данных (расширенный язык моделирования данных), например EDM, канонические деревья команд (CTree), которые представляют программный способ определения запросов и DMLs в терминах расширенного языка моделирования данных, функциональные возможности связующего устройства, которые выполняют компенсацию для конкретных поставщиков посредством манипулирования каноническими запросами, использование развертывания вида для изящного объединения способа отображения OR по всей семантике расширенного языка моделирования данных с запросом и обновлениями. И способность расширить базовый язык запросов через расширения, которыми управляют из метаданных. Кроме того, иллюстративные новые аспекты спецификаций eSQL, изложенные ниже, включают в себя следующее.

Первоклассная поддержка для коллекций: иллюстративный вариант осуществления eSQL, обеспеченный в этом документе, разработан подобным SQL и обеспечивает преимущества перед SQL. В общем, ранние версии SQL (SQL 92 и более ранние) были в основном сконцентрированы на таблице. Таблицы обрабатывали, как первоклассные сущности-объекты, а строки/столбцы обрабатывали, как второклассные. И, конечно, не было никакого понятия о коллекциях. SQL 99 и более поздние диалекты обеспечивают поддержку для коллекций, но эта поддержка была настроена на SQL 92. Доказательство, например, тяжеловесные добавления наподобие unnest, apply и т.п.

Напротив, в одном варианте осуществления eSQL обрабатывает коллекции как первоклассные сущности-объекты. Например, выражения с коллекциями являются допустимыми в предложении from. Нет необходимости использовать синтаксические структуры unnest, подзапросы "in" и "exists" были обобщены для обработки любых коллекций - подзапрос просто является одним из видов коллекции, для выполнения этих операций предназначены конструкции eSQL "e1 in e2" и "exists(e)". Кроме того, многие из операций над множествами (set) (union (объединение), intersect (пересечение), except (исключение)) оперируют коллекциями. Операции join (соединение) также оперируют коллекциями.

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

1+2*3

"abc"

row(1 as a, 2 as b)

{ 1, 3, 5}

e1 union all e2

distinct(e1)

Единообразная обработка подзапросов. Так как SQL функционирует исходя из своего сконцентрированного на таблице представления о мире, то, как правило, у него существует тенденция интерпретировать подзапросы в контексте. Например, в SQL, считается, что подзапрос в предложении from является мультимножеством (таблицей), в то время как идентичный подзапрос, используемый в предложении select, считается скалярным подзапросом. Аналогично, подзапрос, используемый слева от оператора in, считается скалярным подзапросом, в то время как справа ожидается подзапрос мультимножества.

В одном варианте осуществления eSQL устраняет эти различия. Существует однообразная интерпретация выражения, которая не зависит от контекста, в котором оно используется. eSQL может считать все подзапросы подзапросами мультимножества. Если требуется скалярное значение из подзапроса, то eSQL может обеспечивать оператор element (элемент), который оперирует коллекцией (в данном случае подзапросом), и извлекать значение одного элемента из коллекции.

Избежание беспричинных неявных приведений типов данных: побочным эффектом, связанным с описанной выше проблемой, является склонность к неявному преобразованию подзапросов в скалярное значение. А именно, в SQL, мультимножество строк с одним полем неявно преобразуется в скалярное значение, типом данных которого является тип данных поля. Напротив, варианты осуществления eSQL не поддерживают это неявное приведение типа данных. eSQL может обеспечивать оператор element для извлечения значения одного элемента из коллекции и предложение select value (выбрать значение) для избежания создания упаковщика строк на протяжении выражения запроса.

Select_Value - избежание от неявного упаковщика строк: SQL до некоторой степени неоднозначен относительно обработки результата запроса. Предложение select в подзапросе SQL неявно создает упаковщика строк вокруг элементов этого предложения. Это, конечно, означает, что мы не можем создавать коллекции из скалярных величин или объектов - каждая коллекция является коллекцией строк (с одним полем, в случае необходимости). С обеспечением возможности неявного приведение типов данных между типом строк с одним полем и значением одиночного элемента идентичного типа данных.

В одном варианте осуществления eSQL обеспечивает предложение select value для пропуска неявного создания строки. В предложении select value может быть указан только один элемент. При использовании такого предложения вокруг элементов предложения select ни один упаковщик строк не создается, и может быть создана коллекция требуемой формы. eSQL также обеспечивает конструктор строки для создания произвольных строк. Так, select value row(e1, e2, ...) является точным эквивалентом select e1, e2, ...

В другом варианте осуществления в семантике select можно избежать создания строки для случая одного элемента, и при необходимости явно использовать конструктор строки. Если предложение select содержит несколько элементов, то оно продолжает вести себя, как в SQL.

В альтернативном и более изящном подходе не допускаются конструкции вида "select e1, e2 from...", и вместо них всегда неизбежно используется "select row(e1, e2) from...".

Корреляция слева и совмещение имен: В стандартном SQL выражения в заданной области видимости (одиночное предложение наподобие select, from и т.д.) не могут ссылаться на выражения, определенные ранее в идентичной области видимости. Некоторые диалекты SQL, в том числе T-SQL, действительно поддерживают их ограниченные формы в предложении from, но синтаксис для использования таких конструкций тяжеловесен и требует операций apply и unnest.

В одном варианте осуществления в eSQL обобщены корреляции слева в предложении from, и они обрабатываются однообразно. Выражения в предложении from могут ссылаться на более ранние определения (определения слева) в идентичном предложении без необходимости использования специальной синтаксической структуры. eSQL также налагает дополнительные ограничения на запросы, в том числе на предложения group-by. Выражения в предложении select, предложении having и т.д. таких запросов могут ссылаться на ключи group-by только через их псевдонимы. Конструкции наподобие следующих - которые допустимы в SQL - недопустимы в eSQL:

select t.x + t.y from T as t group by t.x + t.y

В eSQL будет правильно сделать это следующим образом:

select k from T as t group by (t.x + t.y) as k

Ссылка на столбцы (свойства) таблиц (коллекции): В одном варианте осуществления, все ссылки на столбец в eSQL должны быть уточнены посредством псевдонима таблицы. Следующая конструкция (предполагается, что "a" является допустимым столбцом таблицы "T") допустима в SQL, но не допустима в eSQL:

select a from T

Одобренной формой в eSQL является:

select t.a as a from T as t

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

Навигация по объектам: SQL использует нотацию "." для ссылки на столбцы (строку) таблицы. В одном варианте осуществления в eSQL эта нотация расширена (снова, в основном, позаимствовано из языков программирования) для поддержки навигации по свойствам объекта. Например, если "p" является выражением типа Person: p.Address.City является синтаксической структурой eSQL для ссылки на город (city) адреса (address) этого человека (person). Многие диалекты SQL уже поддерживают эту синтаксическую структуру.

Навигация по коллекциям: SQL не обеспечивает простого механизма для навигации по вложенным коллекциям. В одном варианте осуществления eSQL обеспечивает синтаксические сокращения для обработки этих случаев. Оператор .. в eSQL обеспечивает возможность проекции выражения из коллекции. Например, "a..b", на самом деле, является синтаксическим упрощением для "select value t.b from a as t". Аналогично, "a..b..(c*2)" является синтаксическим упрощением для "select value t2.c*2 from a as t1, t1.b as t2".

Оператор ".?" в eSQL обеспечивает возможность пользователям отсекать элементы из коллекции. Он подобен оператору "[]" в XPath. Конструкция вида "a.? p", на самом деле, является сокращением для "select value t from a as t where p". Например, "p.?(id = 1)", на самом деле, означает "select value p0 from p as p0 where p0.id = 1".

При работе с наследованием часто бывает полезной возможность выбора экземпляров подтипа из коллекции экземпляров супертипа. Оператор oftype в eSQL (подобный oftype в Последовательностях (Sequences) C#) обеспечивает эту возможность. Логически, oftype(c,T) эквивалентно "select value treat(x as T) from c as x where x is of T".

Отказ от *: SQL поддерживает неуточненную синтаксическую структуру * как псевдоним для всей строки и уточненную синтаксическую структуру * (t.*) как сокращение для полей этой таблицы. Кроме того, SQL допускает специальный агрегат count(*), который включает в себя нули. Хорошо спроектированные запросы в SQL не используют такие синтаксические структуры (по меньшей мере, варианты "select *" и "select t.*"). Использование "*" опасно при развитии схемы. Часть проблемы состоит в том, что в SQL не было никакого способа для пользователя выбрать все строки.

В одном варианте осуществления eSQL не поддерживает конструкцию "*". Запросы SQL типа "select * from T" и "select T1.* from T1, T2..." могут быть выражены в eSQL как "select value t from T as t" и "select value t1 from T1 as t1, T2 as t2..." соответственно. Кроме того, эти конструкции обрабатывают наследование (замещаемость значения) изящно, в то время как варианты "select *" ограничены свойствами верхнего уровня заявленного типа. Варианты осуществления eSQL также не поддерживают агрегат count(*). Вместо этого для обработки этого случая он поддерживает конструкцию count(group).

Изменения для group by: Как описано ранее, в одном варианте осуществления, eSQL поддерживает совмещение имен ключей group-by, и корреляции слева среди этих ключей. На самом деле выражения в предложении select и предложении having должны ссылаться на ключи group by только через их псевдонимы. Предложение group-by неявно создает агрегат nest для каждого раздела group-by - это выражение называют "группа" ("group"). Для выполнения агрегирования агрегатные функции в списке выбора и т.д. должны ссылаться на это выражение. Например:

select kl, count(group), sum(group..(t.a))

from T as t

group by t.b + t.c as k1

является синтаксисом eSQL для следующего запроса SQL:

select b + c, count(*), sum(a)

from T

group by b + c

Агрегаты на основе коллекции: Агрегаты SQL трудны для понимания. В одном варианте осуществления eSQL поддерживает два вида агрегатов. Агрегаты на основе коллекции оперируют коллекциями и формируют агрегированный результат. Они могут появляться в любом месте запроса, и им не требуется предложение group-by. Например, следующий запрос eSQL допустим:

select t.a as a, count({1,2,3}) as b from T as t

В одном варианте осуществления eSQL также поддерживает агрегаты в стиле SQL, и неявно преобразует их в агрегаты на основе коллекции (на основе коллекции "group"). Например, следующий запрос на eSQL допустим:

select a, sum(t.b) from T as t group by t.a as a;

и внутри транслируется в запрос вида:

select a, sum(group..(t.b)) as b from T as t group by t.a as a.

В одном варианте осуществления eSQL не поддерживает агрегат count(*). Вместо него используют конструкцию count(group).

Insert (Вставить): В одном варианте осуществления утверждение INSERT..VALUES eSQL отличается от T-SQL. В отличие от T-SQL, eSQL не обеспечивает возможности указания списка столбцов в insert. Для этого существуют две причины. Во-первых, у EDM нет концепции значений по умолчанию для столбцов; во-вторых, подход списка столбцов плохо подходит для обработки наследования (замещаемость значения).

Delete, Update (Удалить, Обновить): В отличие от T-SQL, в одном варианте осуществления eSQL не обеспечивает возможности дополнительного предложения from в утверждениях delete и update. Для утверждений delete это не представляет проблемы, так как запрос может быть написан с подзапросом. Однако для утверждений update дополнительное предложение from также помогает в формировании новых значений, используемых в предложении Set.

Извлеченные свойства и методы: Язык запросов WINDOWS® (WinQL) обеспечивает возможность навигации по коллекциям через оператор ".", если у самой коллекции нет свойства с идентичным именем. WinQL также обеспечивает возможность отфильтровывания элементов коллекции через конструкцию "[]" - подобно OPath. В одном варианте осуществления eSQL с этой целью использует оператор ".?" и "..". И опять же, развитие схемы (и внутренний перехват) является основной причиной того, что eSQL делает выбор в пользу различия между навигацией по коллекциям и навигацией по объектам. И eSQL преднамеренно избегает использования "[]" для предикатов, чтобы избежать проблем двусмысленности.

Семантика order-by: В WinQL определено, что предложение order by обрабатывается до предложения select. Это является отличием от SQL, где предложение order by логически обрабатывается после предложения select. В одном варианте осуществления eSQL может быть ближе к SQL в этом отношении, в то время как в WinQL существует более схожий с XQuery подход. Любой подход разумен, и до некоторой степени модель WinQL лучше; однако подход WinQL может быть не настолько лучше, чтобы оправдать изменение стиля работы пользователей SQL.

SQL-92 фактически ограничивает предложение order by так, что оно может содержать только ссылки на элементы предложения select. Большинство реализаций обеспечивает возможность ссылаться в предложении order by на другие элементы, которые в настоящее время находятся в области видимости. В одном варианте осуществления eSQL может следовать последнему стилю.

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

ПРИЛОЖЕНИЕ A: Подробная спецификация иллюстративного языка запросов

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

1 Функциональный реферат

1.1 Описание проблемной области

CDP обеспечивает инфраструктуру реляционного отображения объектов, которая может быть использована приложениями и интегрированными средами. WinFS обеспечивает интегрированный опыт хранения информации для широкого многообразия приложений для настольных компьютеров. И WinFS, и CDP основаны на модели данных сущностей-объектов (EDM). EDM является расширенной реляционной моделью данных, которая поддерживает основные реляционные концепции, расширенные типы с наследованием и связи. Пользователи должны иметь возможность выдавать расширенные запросы по их данным, выраженным в терминах EDM.

Несмотря на то, что SQL исторически был предпочтительным языком запросов для доступа к базе данных, у него существует много недостатков. Отсутствие поддержки для расширенных типов, неортогональные конструкции и т.д. - только некоторые из них. eSQL пытается решить многие из этих проблем, связанных с SQL. eSQL разработан подобным SQL и обеспечивает некоторую дополнительную инфраструктуру и усовершенствования на основе SQL.

И WinFS, и CDP усиливают существующие.NET технологии доступа к данным - ADO.NET - для доступа к данным и манипулирования ими. Поставщик данных.NET обеспечивает до некоторой степени однообразный способ доступа к данным из любого источника данных через Connections (соединения), Commands (команды), интерфейсы DataReader и другие подобные объекты. Команды для поставщика данных.NET выражаются в виде строк и должны быть на родном диалекте поставщика (более конкретно, источника данных, на который выходит поставщик). Как часть усилий CDP/WinFS, будут обеспечены три новых поставщика - поставщик объектов, поставщик EDM и поставщик WinFS, и все они будут использовать eSQL как родной диалект.

2 Обзор и принципы разработки

2.1 Принципы разработки

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

Ортогональность

Конструкции в eSQL должны быть ортогональ