(57)【要約】  リッチデータ型をサポートする照会言語が提供される。システムは、照会言語によるクエリを生成するように構成されたアプリケーションを備え得る。提供する照会言語により生成されるクエリを扱うプラットフォームも提供される。プラットフォームは概して、究極的には様々な商用データベースとインターフェイスをとることができるオブジェクトサービスレイヤ、マッププロバイダレイヤ、およびブリッジレイヤを備える。
2009530735.tif 000002
【特許請求の範囲】
【請求項１】
データを求めるアプリケーションリクエストを処理するシステムであって、
ｆｒｏｍ句の中にコレクション式を含むリクエストを受諾するオブジェクトサービスレイヤ２１０と、
前記リクエストをデータベースクエリに変換する複数のマッピング変換を供給するマッププロバイダレイヤ２２０と、
前記データベースクエリを、第１のデータベース２４０の少なくとも１つの要件に適応された変更済みデータベースクエリにコンバートするブリッジレイヤ２３０と、
前記変更済みデータベースクエリを処理するクエリ処理エンジンを備え、前記ブリッジレイヤに結果を戻すように構成された前記第１のデータベース２４０とを備えることを特徴とするシステム。
【請求項２】
前記リクエストは、ｕｎｉｏｎ、ｉｎｔｅｒｓｅｃｔ、およびｅｘｃｅｐｔを含むグループから選択される集合演算をさらに含み、前記集合演算は、コレクションに対して作用することを特徴とする請求項１に記載のシステム。
【請求項３】
前記リクエストは、コレクションに対して作用するジョイン演算をさらに含むことを特徴とする請求項１に記載のシステム。
【請求項４】
前記ブリッジレイヤ２３０は、前記データベースクエリを、複数のデータベース２４０のいずれの要件にも適応された複数の変更済みデータベースクエリのいずれにもコンバートするように構成されることを特徴とする請求項１に記載のシステム。
【請求項５】
データを求めるアプリケーションリクエストを処理するシステムであって、
ｕｎｉｏｎ、ｉｎｔｅｒｓｅｃｔ、およびｅｘｃｅｐｔを含むグループから選択される、コレクションに対して作用する集合演算を含むリクエストを受諾するオブジェクトサービスレイヤ２１０と、
前記リクエストをデータベースクエリに変換する複数のマッピング変換を供給するマッププロバイダレイヤ２２０と、
前記データベースクエリを、第１のデータベース２４０の少なくとも１つの要件に適応された変更済みデータベースクエリにコンバートするブリッジレイヤ２３０と、
前記変更済みデータベースクエリを処理するクエリ処理エンジンを備え、前記ブリッジレイヤに結果を戻すように構成された前記第１のデータベース２４０とを備えることを特徴とするシステム。
【請求項６】
前記リクエストは、コレクションに対して作用するジョイン演算をさらに含むことを特徴とする請求項５に記載のシステム。
【請求項７】
前記ブリッジレイヤ２３０は、前記データベースクエリを、複数のデータベース２４０のいずれの要件にも適応された複数の変更済みデータベースクエリのいずれにもコンバートするように構成されることを特徴とする請求項５に記載のシステム。
【請求項８】
データを求めるアプリケーションリクエストを処理するシステムであって、
コレクションに対して作用するジョイン演算を受諾するオブジェクトサービスレイヤ２１０と、
前記リクエストをデータベースクエリに変換する複数のマッピング変換を供給するマッププロバイダレイヤ２２０と、
前記データベースクエリを、第１のデータベース２４０の少なくとも１つの要件に適応された変更済みデータベースクエリにコンバートするブリッジレイヤ２３０と、
前記変更済みデータベースクエリを処理するクエリ処理エンジンを備え、前記ブリッジレイヤ２３０に結果を戻すように構成された前記第１のデータベース２４０とを備えることを特徴とするシステム。
【請求項９】
前記ブリッジレイヤは、前記データベースクエリを、複数のデータベースのいずれの要件にも適応された複数の変更済みデータベースクエリのいずれにもコンバートするように構成されることを特徴とする請求項８に記載のシステム。
【請求項１０】
データベース２４０に対してデータをリクエストするように構成されたアプリケーション２００を備えるコンピュータシステムであって、前記アプリケーションは、照会言語によるリクエストを生成し、前記照会言語は、少なくとも、
前記照会言語が、ｆｒｏｍ句の中でのコレクション式の使用を許可する特性と、
前記照会言語が、ｕｎｉｏｎ、ｉｎｔｅｒｓｅｃｔ、およびｅｘｃｅｐｔを含むグループから選択される集合演算の使用を許可し、前記集合演算は、コレクションに対して作用する特性と、
前記照会言語が、コレクションに対して作用するジョイン演算の使用を許可する特性とを含むことを特徴とするコンピュータシステム。
【請求項１１】
前記照会言語は、すべてのクエリが少なくとも１つの式を含むことをさらに要求することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１２】
各式は、各式が使われるコンテキストに依存しない同一解釈をもつことを特徴とする請求項１１に記載のコンピュータシステム。
【請求項１３】
前記照会言語は、式
【表１】
2009530735.tif 000158
の使用をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１４】
前記照会言語は、全サブクエリをマルチセットサブクエリであると見なすことを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１５】
サブクエリからスカラー値が所望される場合、前記照会言語は、コレクションに対して作用する要素演算子を前記アプリケーションが提供することを要求することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１６】
前記照会言語は、コレクションから単集合値を抽出するための要素演算子、およびクエリ式中にローラッパーの作成を避けるためのｓｅｌｅｃｔ  ｖａｌｕｅ句の使用をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１７】
前記照会言語は、暗黙のロー構築をスキップするためのｓｅｌｅｃｔ  ｖａｌｕｅ句の使用をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１８】
前記照会言語は、ｓｅｌｅｃｔ  ｖａｌｕｅ  ｒｏｗ（ｅ１，ｅ２，．．．）ステートメントがｓｅｌｅｃｔ  ｅ１，ｅ２，．．．ステートメントと全く等しくなるような任意のローを構築するためのローコンストラクタの使用をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項１９】
前記照会言語は、前記ｆｒｏｍ句の中の左相関を一般化し、前記左相関を一律に取り扱うクエリ式の使用をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項２０】
前記照会言語は、すべてのカラム参照がテーブルエイリアスで修飾されることを要求することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項２１】
前記照会言語は、コレクションを介したナビゲーションを扱うための構文的ショートカットの使用をさらに許可し、前記ショートカットは、「ａ．．ｂ」が「ｔとしてａからｔ．ｂ値を選択する」の等価物となるように、コレクションからの式の射影を可能にするための．．演算子を用いることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項２２】
前記照会言語は、ｇｒｏｕｐ−ｂｙキーのエイリアス作成の使用、およびこのようなキーの間の左相関をさらに許可することを特徴とする請求項１０に記載のコンピュータシステム。
【請求項２３】
前記照会言語は、２種類の集約、すなわちコレクションに対して作用するとともに集約結果を生じるコレクションベースの集約、および構造化照会言語（ＳＱＬ）スタイルの集約の使用をさらに許可し、前記機構は、ＳＱＬスタイルの集約をコレクションベースの集約に暗黙的にコンバートすることを特徴とする請求項１０に記載のコンピュータシステム。
【請求項２４】
前記照会言語は、ＩＮＳＥＲＴ．．ＶＡＬＵＥＳステートメントの使用をさらに許可し、前記ステートメントは、前記ＩＮＳＥＲＴ．．ＶＡＬＵＥＳステートメント中でカラムリストを指定させないことを特徴とする請求項１０に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本出願は、２００６年３月２０日に出願した米国特許仮出願第６０／７８４，５１０号の優先権を主張する。
【背景技術】
【０００２】
例えば、製品を閲覧し注文を生成する事業区分（ＬＯＢ）アプリケーションであっても、人々との会合をスケジュールする個人情報管理（ＰＩＭ）アプリケーションであっても、ほぼすべてのアプリケーションにおいて、データは重要な資産となっている。アプリケーションは、ますますデータ中心になりつつある。すなわち、その設計時および実行時経験の主要部分を、データの照会、操作、および提示を中心として策定する。こうしたアプリケーションの多くは、構造的完全性、データ制約、データの間の関係などのような、セマンティクスが豊富なデータを処置する。今日のアプリケーションは、データのセマンティクスを保つための手続きコードに主要作業を費やしている。
【０００３】
例えば、ＬＯＢアプリケーションについて検討する。通常、このようなアプリケーションは、Ｃｕｓｔｏｍｅｒ、Ｏｒｄｅｒ、ＯｒｄｅｒＬｉｎｅ、Ｓｕｐｐｌｉｅｒ、Ｐｒｏｄｕｃｔ、Ｅｍｐｌｏｙｅｅ、Ｓｈｉｐｐｅｒ、Ｉｎｖｏｉｃｅなどを処置する。こうした概念はそれぞれ、ある特定の構造を有する別個のリッチデータ型を表す。例えば、Ｃｕｓｔｏｍｅｒ型は、ＣｕｓｔｏｍｅｒＩＤ、Ｃｏｍｐａｎｙ  Ｎａｍｅ、Ｃｏｎｔａｃｔ  Ｎａｍｅ、およびＡｄｄｒｅｓｓのようなものをもち、Ｏｒｄｅｒ型は、ＯｒｄｅｒＩＤ、ＣｕｓｔｏｍｅｒＩＤ、ＯｒｄｅｒＤａｔｅ、ＯｒｄｅｒＬｉｎｅ、ＤｕｅＤａｔｅなどのようなものをもつ。上記のいずれにも、さらに必要なものがあり得る。例えばＡｄｄｒｅｓｓは、米国内では、各キャラクタが０と９の間の数字である、５キャラクタ長の郵便番号でなければならないＰｏｓｔａｌＣｏｄｅを必要とする場合がある。カナダでは、ＰｏｓｔａｌＣｏｄｅは、「ＡＮＡ  ＮＡＮ」の形でなければならず、Ａは文字であり、Ｎは数字である。郵便番号をモデル化するときは、したがって、文字列であることを指定するだけでは十分ではない。この文字列に対しては、とり得る可能な値の範囲を制限するような追加制約が課されなければならない。さらに、データの間には一般に、関係が存在する。例えば、Ｏｒｄｅｒは、それに関連づけられたＣｕｓｔｏｍｅｒを常にもち得る。これは、多（Ｏｒｄｅｒ）対１（Ｃｕｓｔｏｍｅｒ）の関係である。１つの供給元によって多様な製品を供給する場合があり、多数の供給元が同じ製品を販売する場合があるので、製品および供給元は、多対多の関係を伴う。
【０００４】
データモデルは、アプリケーションが関与するデータの様々な断片の構造およびセマンティクス、ならびに断片の間の関係を記述する。リレーショナルモデルおよびシステムは、データ管理において非常に成功を収めているが、アプリケーションデータモデルを取り込むことはできていない。従来のクライアント／サーバアプリケーションは、そのデータに対するクエリおよび永続化操作を、データベースシステムに委託している。データベースシステムは、ローおよびテーブルの形のデータに対して作用し、アプリケーションは、クラスおよびリッチデータ型など、比較的高レベルのプログラミング言語コンストラクトによるデータに対して作用する。アプリケーションとデータベース層の間のデータ操作サービスにおけるインピーダンスミスマッチは、従来のシステムでは許容可能であった。サービス指向アーキテクチャ（ＳＯＡ）、アプリケーションサーバおよび多層アプリケーションの出現により、プログラミング環境との整合性が十分であり、どの層の中でも動作することができるリッチデータアクセスおよび操作サービスの必要性が、途方もなく増している。
【０００５】
ほとんどのアプリケーションおよびアプリケーションフレームワークは、それ自体のデータモデルを、リレーショナルデータモデルベースのシステムの上で転が（roll）して、データとアプリケーションプログラミング環境の間のインピーダンスミスマッチを埋める。これは、ほとんどのアプリケーションが、ＬＯＢ、ＰＩＭ、Ｉｎｆｏｒｍａｔｉｏｎ  Ｗｏｒｋｅｒ、またはそれ以外のいずれであっても、豊富な構造、関係、振舞い、および拡張性のようなデータモデルコンセプトを必要とするからである。こうしたデータモデルコンセプトは、既存のデータモデルによっては適切にサポートされず、さらに、データがより高度なデータモデルにより編成されるべきである場合、そのデータにアクセスする適切な照会言語が現時点では存在しない。
【０００６】
データメタモデルの例示的な最新候補は、構造化照会言語の１９９９バージョン（ＳＱＬ９９）、共通言語ランタイム（ＣＬＲ）、統一モデリング言語（ＵＭＬ）およびＸＭＬスキーマ定義（ＸＳＤ）を含む。しかし、ＣＬＲは、オブジェクト指向であり、命令型プログラミングランタイムであり、固有データモデルも、完全性制約、関係、または永続性の概念ももたない。ＳＱＬ９９は、関係のようなデータモデリングコンセプトを欠いており、優れたプログラミング言語統合をもたない。ＸＳＤ仕様は、キー、関係、および永続性のようなコンセプトをサポートせず、複雑であり、ランタイムおよびリレーショナルデータベースモデル両方への不便なマッピングをもつ。ＵＭＬは一般的過ぎる。すなわち、アプリケーション開発者が、特に永続性に対して、厳密なセマンティクスを追加することを要求する。
【０００７】
【特許文献１】米国特許出願第１１／１７１９０５号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００８】
当該分野においては、リッチデータ型へのより優れたアプリケーションアクセスを提供するデータモデルおよび対応するサポートフレームワークに対する、満たされていない必要性がある。さらに、このようなデータモデルによってサポートすることができるようなリッチデータ型をサポートする拡張照会言語の必要性もある。
【課題を解決するための手段】
【０００９】
上で明らかにした当該分野の短所を考慮した上で、本発明は、リッチデータ型をサポートする拡張照会言語を提供する。提供される照会言語の様々な例示的な特徴を、本明細書において論じる。さらに、システムは、照会言語によるクエリを生成するように構成されたアプリケーションを備え得る。提供される照会言語により生成されるクエリを扱うプラットフォームも提供する。プラットフォームは概して、究極的には様々な商用データベースとインターフェイスをとることができるオブジェクトサービスレイヤ、マッププロバイダレイヤ、およびブリッジレイヤを備える。
【００１０】
本発明による、リッチデータ型をサポートする拡張照会言語用のシステムおよびメソッドを、添付の図面を参照してさらに説明する。
【発明を実施するための最良の形態】
【００１１】
本発明の様々な実施形態を完全に理解させるために、特定の具体的な詳細を、以下の説明および図面において述べる。ただし、本発明の様々な実施形態を不必要に分かりにくくすることを避けるために、しばしばコンピューティングおよびソフトウェア技術に関連づけられる特定の公知の詳細については、以下の開示において述べない。さらに、以下で説明する詳細の１つまたは複数なしで本発明の他の実施形態を実施できることが、当業者には理解されよう。最後に、以下の開示においてステップおよびシーケンスを参照して様々なメソッドを説明するが、そうした説明は、本発明の実施形態の明快な実装を実現するためのものであり、ステップおよび連続したステップは、本発明を実施するのに必要とされると見なされるべきでない。
【００１２】
最初に、この説明では、例示的なデータモデルおよび関連データサポート機構を、本明細書において説明するリッチデータ型のサポートを照会言語に組み込むシステムおよびメソッドの例示的な実施形態において用いることができるものとして挙げる。次に、本明細書において述べる例示的な照会言語の様々な新規特徴および側面を強調し、論じる。例示的な照会言語の詳細な仕様を付表Ａに記載し、その拡張を付表Ｂに記載する。詳細な実装形態は、新規かつ有用な数多くの特徴を含むことが、当業者には理解されよう。
【００１３】
例示的なデータモデルおよび関連データサポート機構
例示的なデータモデルおよび関連データサポート機構は、マネージドコード（ＡＤＯ．ＮＥＴ）プラットフォーム用のアクティブＸデータオブジェクトなど、１組の技術に組み込むことができる。このプラットフォームは、マイクロソフト（登録商標）構造化照会言語（ＳＱＬ）サーバなどのデータソース、ならびにデータベース用のオブジェクトのリンクと埋込み（ＯＬＥ  ＤＢ）および拡張マークアップ言語（ＸＭＬ）により公開されるデータソースへの一貫したアクセスを提供するように設計されている。データを共有する消費者アプリケーションは、ＡＤＯ．ＮＥＴを使って、こうしたデータソースに接続し、データを取得し、操作し、アップデートすることができる。
【００１４】
ＡＤＯ．ＮＥＴは、データアクセスを、データ操作から、別個に、または協同で使うことができる個別の成分に手際よく因数分解する。ＡＤＯ．ＮＥＴは、データベースに接続し、コマンドを実行し、結果を取得する．ＮＥＴフレームワークデータプロバイダを含む。こうした結果は、直接処理されるか、またはアドホックなやり方でユーザに公開され、多様なソースからのデータと組み合わされ、または層の間で離されるために、ＡＤＯ．ＮＥＴのＤａｔａＳｅｔオブジェクト中に配置されるかのどちらかである。ＡＤＯ．ＮＥＴのＤａｔａＳｅｔオブジェクトは、アプリケーションに対してローカルな、またはＸＭＬから供給されるデータを管理するために、．ＮＥＴフレームワークデータプロバイダとは独立して用いることができる。したがって、ＡＤＯ．ＮＥＴは、当業者にはよく知られているアクティブＸデータオブジェクト（ＡＤＯ）技術によって固有ＣＯＭ開発者に提供される機能と同様な機能を、マネージドコードを書く開発者に提供する。
【００１５】
一実施形態では、ＡＤＯ．Ｎｅｔプラットフォームは、ＰＩＭフレームワークおよびＬＯＢフレームワークなど、様々なアプリケーションフレームワークに渡るアプリケーションに、アプリケーションプログラミング環境と十分に統合された様式でデータにアクセスし、操作し、管理するための豊富な１組のデータサービスを提供するように拡張することができる。図１は、アプリケーションサポートアーキテクチャにおけるこの機能の配置を示す。共通データプラットフォーム（ＣＤＰ）１００は、ＡＤＯ．Ｎｅｔプラットフォームなど、１組の技術を実装することができる。共通データプラットフォーム（ＣＤＰ）１００および関連技術については、例えば特許文献１において詳しく論じられている。
【００１６】
図１のアプリケーションサポートアーキテクチャは、例えば、ＳＱＬ  ＳＥＲＶＥＲ（登録商標）、ＷｉｎＦＳ（登録商標）、またはＯＲＡＣＬＥ（登録商標）データベースなどのデータソース１１０と、アプリケーションおよびアプリケーションフレームワークにリッチデータサービスを提供するＣＤＰ１００と、１組のフレームワークサービス、例えばＣＤＰ１００の機能を拡張し増補するＵＡＦ１２０およびＬＯＢフレームワーク１３０と、フレームワーク機能および一般的な適用論理をカプセル化するデータクラスのセット、例えば、１２２、１３２、１４０と、ＣＤＰ１００およびフレームワーク１２０、１３０および／またはクラス１２２、１３２、１４０によって提供される機能を利用する任意の数のアプリケーション１５０、１６０、１７０を含み得る。
【００１７】
ＣＤＰ１００によってサポートされるデータモデルは、例えば、ワシントン州レドモンドの本件特許出願人によって開発されたエンティティデータモデル（ＥＤＭ）を含み得る。ＥＤＭは、例えばＬＯＢ、ＰＩＭ、Ｍａｎａｇｅｍｅｎｔなど、多様なアプリケーションフレームワークに適合するように、リレーショナルデータモデルを拡張する。ＥＤＭは、データ用のリッチオブジェクトの抽象化を定義し、データ関係など、豊富なセマンティクスをモデル化し、アプリケーション構造とデータモデルの間のミスマッチを最小限にし、特定のアプリケーション挙動をサポートし、基本的なリレーショナルコンセプト、継承を有するリッチ型、および関係をサポートし、概して、データストアおよび展開層に依存しないデータセマンティクスを取り込むモデリングコンセプトを提供する。ＥＤＭは、ＡＤＯ．ＮＥＴなどの技術に組み込むことができる。
【００１８】
図２は、ＣＤＰ１００のアーキテクチャのメインコンポーネントを示し、特に、以下でより詳細に論じるリッチデータ型用の拡張照会言語を使って行われるクエリを指揮することができるものとしてのクエリパイプラインを記述する。「ｅＳＱＬ」という用語は、本明細書においては、リッチデータ型用の拡張照会言語を指すのに使われ、その実施形態は、以下で詳しく説明する。図２は、クエリがＣＤＰ１００の異なるコンポーネントをどのように流れるかも示す。
【００１９】
最初に、アプリケーション２００が、ｅＳＱＬクエリとして、オブジェクトサービスプロバイダ２１０に対するクエリを発行する。オブジェクトサービスプロバイダ２１０は、クエリを分析し正規ツリーにコンバートするパーササービス２１１、および正規ツリーに対して（本明細書において与えられる、アプリケーションデータモデルからＥＤＭへの）いかなるマッピング翻訳も実施するマッピング変換２１２を備え得る。オブジェクトサービスプロバイダは次いで、正規ツリーをマッププロバイダ２２０に伝えることができる。
【００２０】
マッププロバイダ２２０は、オブジェクトリレーショナルマップ機能をカプセル化する。プロバイダ２２０は、正規ツリーに対してマッピング翻訳を実施するマッピング変換２２２を備える。マッププロバイダは、正規ツリーを仲介サービス用のブリッジ２３０に渡す。
【００２１】
ブリッジ２３０は、正規ツリーを因数分解し、いかなるデータモデル補償も実施し、次いで、１つまたは複数の正規ツリーをストレージプロバイダ２４０に伝えるクエリ補償サービスコンポーネント２３１を備え得る。
【００２２】
ストレージプロバイダ２４０は、正規ツリーをその固有ダイアレクト、例えば、ＳＱＬ２０００やＳＱＬ２００５などのＳＱＬダイアレクト、あるいはＷｉｎＦＳまたは組込みデータベース形式に翻訳する。ストレージプロバイダ２４０は、クエリを実行し、メッセージ、例えばＤａｔａＲｅａｄｅｒインターフェイス（「ＤａｔａＲｅａｄｅｒ」）に、またはそこからブリッジ２３０に渡されるようにフォーマットすることができるメッセージを戻す。
【００２３】
ブリッジ２３０は、ストレージプロバイダ２４０によって戻された、可能性としては多数のＤａｔａＲｅａｄｅｒからの結果を、必要な場合アセンブルする、結果／値アセンブリサービス２３２を備える。２３２によって実施されるこの演算の結果は、ＥＤＭ空間の観点では単一ＤａｔａＲｅａｄｅｒである。
【００２４】
マッププロバイダ２２０は次に、ＤａｔａＲｅａｄｅｒを単にブリッジ２３０からオブジェクトサービスプロバイダ２１０に戻す。オブジェクトサービス２１０は、マッププロバイダ２２０からの結果をオブジェクト空間に翻訳する。オブジェクトサービスプロバイダ２２１は、任意選択で結果をオブジェクトとして具体化し、識別マップ中にそうしたオブジェクトのキャッシュをとるコンポーネント２１３を備える。最後に、アプリケーション２００は、結果として生じたＤａｔａＲｅａｄｅｒを利用する。
【００２５】
より詳細に、ＥＤＭのいくつかの顕著な側面に移ると、ＥＤＭは概して、４つのコアコンセプト、すなわち型、インスタンス、エンティティ、および関係によって構築される。こうしたコンセプトは、典型的なＬＯＢアプリケーションの例を用いて示すことができる。このようなアプリケーションは、異なる種類のデータ、例えば、注文、顧客、注文明細行、住所、供給元、製品、従業員などを処置する。
【００２６】
ＥＤＭの例示的な使用において、Ｃｕｓｔｏｍｅｒデータは、エンティティと見なすことができる。エンティティとは、アプリケーションが連動する最上位レベルのデータ単位を表す。Ｃｕｓｔｏｍｅｒは、いくつかのフィールド、すなわちＣｕｓｔｏｍｅｒＩＤ、ＣｏｍｐａｎｙＮａｍｅ、ＣｏｎｔａｃｔＮａｍｅ、Ａｄｄｒｅｓｓ、およびＰｈｏｎｅを有し得る。各フィールドは、そのフィールドに入るデータの構造を決定する型をもつ。例えば、ＣｕｓｔｏｍｅｒＩＤは、固定長の文字列でよい。ＣｏｍｐａｎｙＮａｍｅおよびＣｏｎｔａｃｔＮａｍｅフィールドも、文字列型でよい。Ｃｕｓｔｏｍｅｒはエンティティなので、Ｃｕｓｔｏｍｅｒ自体も型をもち、この型は、エンティティ型と呼ぶことができる。
【００２７】
Ａｄｄｒｅｓｓフィールドは、他のフィールドとは異なり得る。すなわち、このフィールドは、Ｃｉｔｙ、Ｓｔａｔｅ、およびＰｏｓｔａｌＣｏｄｅなど、他のフィールドの形の内部構造を有している。ＥＤＭでは、Ａｄｄｒｅｓｓなどのフィールドの型は、複合型と呼ばれる。対照的に、ＣｕｓｔｏｍｅｒＩＤ、ＣｏｍｐａｎｙＮａｍｅ、およびＣｏｎｔａｃｔＮａｍｅの型はすべて、単純型でよい。
【００２８】
Ｐｈｏｎｅフィールドは、それぞれが文字列であるいくつかの電話番号からなり得る。これは、コレクション型と呼ばれる。
【００２９】
型は、データの構造および値に対する特定の制約を指定する。こうした型のインスタンスには、実データが格納される。オブジェクト指向プログラミングに精通している人であれば誰でも、型およびインスタンスは、それぞれクラスおよびオブジェクトと同様であるという明らかな類似を指摘するであろう。
【００３０】
ＣｕｓｔｏｍｅｒおよびＡｄｄｒｅｓｓは両方とも、両方とも内部構造をもつ、すなわち多様なフィールドからなるという点で類似している。しかし意味論的に、かつ運用上、Ｃｕｓｔｏｍｅｒは、Ａｄｄｒｅｓｓとは異なる。Ｃｕｓｔｏｍｅｒは、クエリ、データ変更操作、トランザクション、永続化、および共有のための単位として作用する。一方、Ａｄｄｒｅｓｓは常に、Ｃｕｓｔｏｍｅｒの中にあり、独立して参照を受けることも作用を受けることもできない。ＥＤＭにおいて、このような最上位レベルのデータ単位をエンティティと呼ぶ。他の全データは、エンティティに対してインラインと見なされる。
【００３１】
ここで、例示的なＯｒｄｅｒデータを検討する。ビジネスルールでは、すべての注文には対応する顧客があることを要求し得る。このことは、ＯｒｄｅｒエンティティとＣｕｓｔｏｍｅｒエンティティの間の関係によってモデル化される。ＥＤＭによってサポートされる異なる種類の関係がある。ＯｒｄｅｒとＣｕｓｔｏｍｅｒの間の１つの関係は、関連づけと呼ばれる。関連づけは通常、エンティティの間のピアツーピア関係をモデル化するのに使われる。
【００３２】
各注文は、いくつかの注文明細行からなり得る。例えば、ＡＭＡＺＯＮ．ＣＯＭ（登録商標）で５冊の本を注文した場合、各本についての情報が注文明細行である。このことは、別の種類の関係、すなわち構成としてモデル化される。構成中の各ＯｒｄｅｒＬｉｎｅはエンティティである。
【００３３】
ｅＳＱＬの例示的な新規特徴
次に、例示的な照会言語の様々な新規特徴および側面について強調し、論じる。概して、ｅＳＱＬ言語およびその拡張は、以下で与えられるように、図１、２を参照して上述したようなシステム内に実装することができるが、以下の例示的な実施形態に関連づけられた様々な新規システムおよびメソッドは、他のコンテキストにおいても同様に実装できることが、当業者には理解されよう。
【００３４】
以下に定められたｅＳＱＬ仕様は、ＥＤＭなどのリッチデータ型（リッチデータモデリング言語）、リッチデータモデリング言語におけるプログラムによるクエリおよびＤＭＬの指定法を表す正規コマンドツリー（ＣＴｒｅｅ）、正規クエリを操作することによって特定のプロバイダを補償するブリッジ機能、クエリおよびアップデートを有するリッチデータモデリング言語セマンティクスすべてに渡ってＯＲマッピング戦略をすっきりと統一するように展開する表示の使用をサポートするデータモデリング言語によってクエリおよびデータ操作言語ステートメント（ＤＭＬ：本明細書で使用する「クエリ」という用語は、クエリおよびＤＭＬを指す）を表すことを含むが、それに限定されない。そして、メタデータから駆動される拡張によりコア照会言語を拡張する能力。さらに、以下で述べるｅＳＱＬ仕様の例示的な新規側面は、以下のものを含む。
【００３５】
コレクションに対する第１クラスサポート：本明細書において与えられる例示的なｅＳＱＬ実施形態は、ＳＱＬと同様となるとともにＳＱＬを上回る利点を提供するように設計される。概して、ＳＱＬの初期バージョン（ＳＱＬ−９２およびそれ以前のバージョン）は、かなりテーブル中心であった。テーブルは、第１クラス市民として取り扱われ、ロー／カラムは第２クラスとして取り扱われた。しかも当然ながら、コレクションという概念はなかった。ＳＱＬ−９９およびそれ以降のダイアレクトは、コレクションのサポートを提供するが、このサポートは、ＳＱＬ−９２へ改造されている。例えば、ｕｎｎｅｓｔ、ａｐｐｌｙなどのような役に立たない追加を参照されたい。
【００３６】
対照的に、一実施形態では、ｅＳＱＬは、コレクションを第１クラスエンティティとして取り扱う。例えば、コレクション式は、ｆｒｏｍ句において正当である。ｕｎｎｅｓｔ構文を使う必要はない。「ｉｎ」および「ｅｘｉｓｔｓ」サブクエリは、どのコレクションも扱うように一般化されており、サブクエリとは単に１種類のコレクションである。「ｅ１  ｉｎ  ｅ２」および「ｅｘｉｓｔｓ（ｅ）」は、こうした演算を実施するためのｅＳＱＬコンストラクトである。さらに、集合演算（ｕｎｉｏｎ、ｉｎｔｅｒｓｅｃｔ、ｅｘｃｅｐｔ）の多くは、コレクションに対して作用する。ｊｏｉｎも、同様にコレクションに対して作用する。
【００３７】
あらゆるものが式である：標準ＳＱＬは常に、２レベルのシステム、すなわちサブクエリ（ｔａｂｌｅ）および式（ｒｏｗ、ｃｏｌｕｍｎ）をもっている。一実施形態では、コレクションおよびネストされたコレクション用の第１クラスサポートを提供するために、ｅＳＱＬは、はるかに明快なモデル、すなわち「あらゆるものが式である」を採用する。例えば、以下はすべて、正当なｅＳＱＬクエリである。
【００３８】
【表１】
2009530735.tif 000003
【００３９】
サブクエリの統一した取扱い：テーブルを中心とした世の中の表示から操作を行うと、ＳＱＬは通常、サブクエリの文脈翻訳を実施する傾向があった。例えば、ＳＱＬにおいて、ｆｒｏｍ句の中のサブクエリは、マルチセット（ｔａｂｌｅ）であると見なされ、ｓｅｌｅｃｔ句の中で使われる同じサブクエリは、スカラーサブクエリであると見なされる。同様の路線に沿って、ｉｎ演算子の左側で使われるサブクエリは、スカラーサブクエリであると見なされ、右側はマルチセットサブクエリであると予想される。
【００４０】
一実施形態では、ｅＳＱＬは、こうした違いを排除する。式は、それが使われるコンテキストに依存しない同一解釈を有する。ｅＳＱＬは、全サブクエリを、マルチセットサブクエリであると見なし得る。スカラー値がサブクエリから所望される場合、ｅＳＱＬは、コレクション（この場合、サブクエリ）に対して作用する要素演算子を提供し、そのコレクションから単集合値を抽出することができる。
【００４１】
不当な暗黙の強制の回避：上述した問題の関連した副作用は、スカラー値への、サブクエリの暗黙のコンバートの概念である。具体的には、ＳＱＬでは、単一フィールドを有するローのマルチセットが、そのデータ型がフィールドのデータ型であるスカラー値に暗黙的にコンバートされる。対照的に、ｅＳＱＬの実施形態では、この暗黙の強制をサポートしない。ｅＳＱＬは、コレクションから単集合値を抽出するための要素演算子、およびクエリ式の間にローラッパーの作成を避けるためのｓｅｌｅｃｔ  ｖａｌｕｅ句を提供することができる。
【００４２】
ｓｅｌｅｃｔ＿ｖａｌｕｅ、暗黙のローラッパーの回避：ＳＱＬは、クエリからの結果の取扱いに関して多少あいまいである。ＳＱＬサブクエリ中のｓｅｌｅｃｔ句は、その句の中の項目周辺にローラッパーを暗黙的に作成する。このことは、当然ながら、スカラーまたはオブジェクトのコレクションを作成することができない、すなわちすべてのコレクションは（必要な場合、１つのフィールドを有する）ローのコレクションであることを含意する。ＳＱＬは、１つのフィールドをもつロー型と、同じデータ型の単集合値との間の暗黙の強制を認めることによって、この問題を回避する。
【００４３】
一実施形態では、ｅＳＱＬは、暗黙のロー構築をスキップするためにｓｅｌｅｃｔ  ｖａｌｕｅ句を提供する。ｓｅｌｅｃｔ  ｖａｌｕｅ句の中では、ただ１つの項目を指定することができる。このような句が使われるとき、ｓｅｌｅｃｔ句の中の項目周辺にローラッパーは構築されず、所望の形状のコレクションを生じることができる。ｅＳＱＬは、任意のローを構築するためのローコンストラクタも提供する。したがって、ｓｅｌｅｃｔ  ｖａｌｕｅ  ｒｏｗ（ｅ１，ｅ２，．．．）は、ｓｅｌｅｃｔ  ｅ１，ｅ２，．．．と全く等しい。
【００４４】
別の実施形態では、ｓｅｌｅｃｔのセマンティクスは、単一項目ケースに対するロー構築を避け、必要とされる場合はローコンストラクタを明示的に使うことができよう。ｓｅｌｅｃｔ句は、多様な項目を含む場合、ＳＱＬでのように振る舞い続けることになる。
【００４５】
代替的であるとともによりすっきりとした手法は、「ｓｅｌｅｃｔ  ｅ１，ｅ２  ｆｒｏｍ．．．」の形のコンストラクトを認めず、その代わり人々に「ｓｅｌｅｃｔ  ｒｏｗ（ｅ１，ｅ２）ｆｒｏｍ．．．」を常に使うよう強制することである。
【００４６】
左相関およびエイリアス作成：標準ＳＱＬでは、所与のスコープ内の式（ｓｅｌｅｃｔ、ｆｒｏｍなどのような単一句）は、同じスコープ内で先に定義されている式を参照することができない。Ｔ−ＳＱＬを含むＳＱＬの一部のダイアレクトは、ｆｒｏｍ句の中の限定された形のそうした式を実際にサポートするが、このようなコンストラクトを使うための構文は役に立たず、ａｐｐｌｙおよびｕｎｎｅｓｔ演算を必要とする。
【００４７】
一実施形態では、ｅＳＱＬは、ｆｒｏｍ句の中の左相関を一般化し、それらを一律に取り扱う。ｆｒｏｍ句の中の式は、特別な構文を必要とすることなく、同じ句の中の先の定義（左側の定義）を参照することができる。ｅＳＱＬはまた、ｇｒｏｕｐ−ｂｙ句を伴うクエリに追加制約を課す。このようなクエリのｓｅｌｅｃｔ句、ｈａｖｉｎｇ句などの中の式は、そのエイリアスを介してｇｒｏｕｐ−ｂｙキーのみを参照し得る。ＳＱＬでは正当だった以下のようなコンストラクトは、ｅＳＱＬでは不正である。
select t.x + t.y from T as t group by t.x + t.y
【００４８】
ｅＳＱＬにおいて上記を行う正しいやり方は、以下の通りである。
select k from T as t group by (t.x + t.y) as k
【００４９】
テーブル（コレクション）の列（プロパティ）の参照：一実施形態では、ｅＳＱＬにおけるすべてのカラム参照は、テーブルエイリアスで修飾されなければならない。以下のコンストラクト（「ａ」がテーブル「Ｔ」の正当なカラムであると仮定する）は、ＳＱＬでは正当であるが、ｅＳＱＬでは正当ではない。
select a from T
【００５０】
ｅＳＱＬが承認した形は、以下のようになる。
select t.a as a from T as t
【００５１】
非修飾参照は、いくつかの問題を被る。そうした参照は、あいまいな場合がある。そうした参照は、スキーマ発展中の外部／内部取込み問題を被り、その上、実装を複雑にする。ＳＱＬにおける適切に設計されたクエリは既に、修飾されたカラム参照を使って、こうした問題に対処している。ｅＳＱＬが行うのは、このガイドラインを単に施行することだけであり、このことが言語をより複雑にするわけではない。
【００５２】
オブジェクトを介したナビゲーション：ＳＱＬは、テーブルの複数カラム（１つのロー）を参照する「．」表記を用いる。一実施形態では、ｅＳＱＬは、この表記（やはり、プログラミング言語から大部分を借用している）を、オブジェクトのプロパティによるナビゲーションをサポートするように拡張する。例えば、「ｐ」がＰｅｒｓｏｎ型の式である場合、
p.Address.City
は、この人物の住所の市を参照するｅＳＱＬ構文である。ＳＱＬの多くのダイアレクトは既に、この構文をサポートしている。
【００５３】
コレクションを介したナビゲーション：ＳＱＬは、ネストされたコレクションを介したナビゲートするための簡単な機構を提供しない。一実施形態では、ｅＳＱＬは、こうしたケースを扱うための構文的ショートカットを提供する。ｅＳＱＬにおける．．演算子は、コレクションからの式の射影を可能にする。例えば、「ａ．．ｂ」は実際には、「ｔとしてａからｔ．ｂ値を選択する」の糖衣構文である。同様に、「ａ．．ｂ．．（ｃ＊２）」は、「ｔ１としてａからｔ２．ｃ＊２値、ｔ２としてｔ１．ｂを選択する」の糖衣構文である。
【００５４】
ｅＳＱＬにおける「．？」演算子により、ユーザは、コレクションから要素を抜き出すことができる。これは、ＸＰａｔｈにおける「［］」演算子と同様である。「ａ．？ｐ」の形のコンストラクトは実際には、「ｐの場合にｔとしてａからｔ値を選択する」のショートカットである。例えば、「ｐ．？（ｉｄ＝１）」は実際には、「ｐ０．ｉｄ＝１の場合にｐ０としてｐからｐ０値を選択する」を意味する。
【００５５】
継承と連携するとき、上位型インスタンスのコレクションから下位型のインスタンスを選び出すことができることは、しばしば有用である。ｅＳＱＬにおけるｏｆｔｙｐｅ演算子は（Ｃ＃シーケンスにおけるｏｆｔｙｐｅと同様に）、この機能を提供する。論理的に、ｏｆｔｙｐｅ（ｃ，Ｔ）は、「ｘがＴの場合にｘとしてｃからｔｒｅａｔ（ｘ  ａｓ  Ｔ）値を選択する」と等しい。
【００５６】
＊の廃止：ＳＱＬは、非修飾＊構文をロー全体に対するエイリアスとして、修飾された＊構文（ｔ．＊）をそのテーブルのフィールドに対するショートカットとしてサポートする。さらに、ＳＱＬは、ヌルを含む特別なｃｏｕｎｔ（＊）集約を可能にする。ＳＱＬにおける、適切に設計されたクエリは、このような構文（少なくとも、「ｓｅｌｅｃｔ＊」および「ｓｅｌｅｃｔ  ｔ．＊」変形体）を使わない。「＊」の使用は、スキーマが発展している場合は危険である。問題の一部は、ＳＱＬが、ユーザにロー全体を選び出させないことである。
【００５７】
一実施形態では、ｅＳＱＬは、「＊」コンストラクトをサポートしない。「ｓｅｌｅｃｔ  ＊  ｆｒｏｍ  Ｔ」および「ｓｅｌｅｃｔ  Ｔ１＊  ｆｒｏｍ  Ｔ１，Ｔ２．．．」の形のＳＱＬクエリは、ｅＳＱＬではそれぞれ、「ｓｅｌｅｃｔ  ｖａｌｕｅ  ｔ  ｆｒｏｍ  Ｔ  ａｓ  ｔ」および「ｓｅｌｅｃｔ  ｖａｌｕｅ  ｔ１  ｆｒｏｍ  Ｔ１  ａｓ  ｔ１，Ｔ２  ａｓ  ｔ２．．．」と表現することができる。さらに、こうしたコンストラクトは、継承（値の代替性）を巧みに扱うが、「ｓｅｌｅｃｔ  ＊」変形体は、宣言された型の最上位レベルのプロパティに制限される。ｅＳＱＬの実施形態は、ｃｏｕｎｔ（＊）集約もサポートしない。代わりに、このケースを扱うために、ｃｏｕｎｔ（ｇｒｏｕｐ）コンストラクトをサポートする。
【００５８】
ｇｒｏｕｐ  ｂｙに対する変更：上で説明したように、一実施形態では、ｅＳＱＬは、ｇｒｏｕｐ−ｂｙキーのエイリアス作成、およびこうしたキーの間の左相関をサポートする。実際、ｓｅｌｅｃｔ句およびｈａｖｉｎｇ句の中の式は、こうしたエイリアスを介して、ｇｒｏｕｐ  ｂｙキーを参照しなければならない。ｇｒｏｕｐ−ｂｙ句は暗黙的に、各ｇｒｏｕｐ−ｂｙパーティションに対するネスト集約を生じ、この式は「グループ」と呼ばれる。ｓｅｌｅｃｔリストなどの中の集約関数は、この式を参照して集約を実施するべきである。例えば、
select kl, count(group), sum (group..(t.a))
from T as t
group by t.b + t.c as k1
は、以下のＳＱＬクエリに対するｅＳＱＬ構文である。
select b + c, count(*), sum(a)
from T
group by b + c
【００５９】
Ｃｏｌｌｅｃｔｉｏｎベースの集約：ＳＱＬ集約は、理解しにくい。一実施形態では、ｅＳＱＬは、２種類の集約をサポートする。Ｃｏｌｌｅｃｔｉｏｎベースの集約は、コレクションに対して作用し、集約結果を生じる。こうした集約は、クエリ中のどこにでも現れ、ｇｒｏｕｐ−ｂｙ句を必要とすることはない。例えば、以下のｅＳＱＬクエリは正当である。
select t.a as a, count({1,2,3}) as b from T as t
【００６０】
一実施形態では、ｅＳＱＬは、ＳＱＬスタイルの集約もサポートし、暗黙的に、（「グループ」コレクションに基づいて）コレクションベースの集約にコンバートする。例えば、ｅＳＱＬにおける以下のクエリ
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;
【００６１】
一実施形態では、ｅＳＱＬは、ｃｏｕｎｔ（＊）集約をサポートしない。代わりにｃｏｕｎｔ（ｇｒｏｕｐ）コンストラクトを使う。
【００６２】
Ｉｎｓｅｒｔ：一実施形態では、ｅＳＱＬのＩＮＳＥＲＴ．．ＶＡＬＵＥＳステートメントは、Ｔ−ＳＱＬとは異なる。Ｔ−ＳＱＬとは異なり、ｅＳＱＬは、カラムリストをｉｎｓｅｒｔ中で指定させない。これには２つの理由がある。第１に、ＥＤＭは、カラムに関するデフォルト値の概念をもたない。第２に、カラムリスト手法は、継承（値の代替性）を扱うのに好適ではない。
【００６３】
Ｄｅｌｅｔｅ、Ｕｐｄａｔｅ：Ｔ−ＳＱＬとは異なり、一実施形態では、ｅＳＱＬは、ｄｅｌｅｔｅおよびｕｐｄａｔｅステートメント中で追加のｆｒｏｍ句を認めない。ｄｅｌｅｔｅステートメントに対しては、クエリはサブクエリを用いて書くことができるので、このことは問題を提示しない。ただし、ｕｐｄａｔｅステートメントに対しては、追加のｆｒｏｍ句は、Ｓｅｔ句の中で使われる新しい値を生じる際にも役立つ。
【００６４】
リフトされたプロパティおよびメソッド：ウィンドウズ（登録商標）照会言語（ＷｉｎＱＬ）は、コレクション自体が同じ名前のプロパティをもたない場合、「．」演算子を介したコレクションによるナビゲーションを可能にする。ＷｉｎＱＬは、ＯＰａｔｈと同様に、「［］」コンストラクトを介してコレクションの要素をふるい落とすことも可能にする。一実施形態では、ｅＳＱＬは、この目的で「．．」および「．？」演算子を使う。やはり、スキーマの発展（および内部取込み）が、ｅＳＱＬがコレクションナビゲーションとオブジェクトナビゲーションとを区別することを選ぶ主な理由である。そして、ｅＳＱＬは、あいまいさの問題を避けるために、述部での「［］」の使用を意図的に避ける。
【００６５】
ｏｒｄｅｒ−ｂｙのセマンティクス：ＷｉｎＱＬは、ｏｒｄｅｒ  ｂｙ句がｓｅｌｅｃｔ句の前に処理されることを指定する。これは、ｏｒｄｅｒ  ｂｙ句がｓｅｌｅｃｔ句の後に論理的に処理されるＳＱＬとは異なる。一実施形態では、ｅＳＱＬは、この点においてＳＱＬに比較的近くてよいが、ＷｉｎＱＬは、よりＸＱｕｅｒｙのような手法をとる。いずれの手法も妥当であり、いくつかの点では、ＷｉｎＱＬモデルの方が優れている。ただし、ＷｉｎＱＬ手法は、ＳＱＬユーザに対する振舞いの変更を正当化する程、十分に優れているわけではない。
【００６６】
ＳＱＬ−９２は実際に、ｏｒｄｅｒ  ｂｙ句を、ｓｅｌｅｃｔ句の中の項目への参照のみを含むように制限する。ほとんどの実装形態は、ｏｒｄｅｒ  ｂｙ句に、現時点でスコープ内にある他の項目を参照させる。一実施形態では、ｅＳＱＬは、後者のスタイルに従う場合もある。
【００６７】
本明細書において明示的に述べた具体的な実装形態に加えて、他の態様および実装形態が、本明細書で開示した明細を考慮すれば、当業者には明らかであろう。本明細書および例示した実装形態は、添付の請求項の真の範囲および精神に対して、例としてのみ見なされることを意図している。
【００６８】
付表Ａ：例示的な照会言語の詳細な仕様
以下は、ここで企図される例示的な照会言語の、例示的であって限定でない仕様である。以下の仕様に続くのは、このような照会言語に対する拡張のための例示的な仕様である。
【００６９】
１  機能の要約
１．１  問題空間の記述
ＣＤＰは、アプリケーションおよびフレームワークによって利用することができるオブジェクトリレーショナルマッピングインフラストラクチャを提供する。ＷｉｎＦＳは、広範囲に渡るデスクトップアプリケーション向けに、統制のとれた格納経験をもたらす。ＷｉｎＦＳおよびＣＤＰは両方とも、エンティティデータモデル（ＥＤＭ）の上に構築される。ＥＤＭは、基本的なリレーショナルコンセプト、継承を有するリッチ型、および関係をサポートする拡張リレーショナルデータモデルである。ユーザは、ＥＤＭによって表現されるそうしたデータに対するリッチクエリを発行する能力を必要とする。
【００７０】
ＳＱＬは歴史的に、データベースアクセスのために選ばれた照会言語であるが、多くの短所を被っている。リッチ型、非直交構造などをサポートしないことは、短所のいくつかに過ぎない。ｅＳＱＬは、ＳＱＬに関するこうした問題の多くに対処することを試みる。ｅＳＱＬは、ＳＱＬと同様になり、ＳＱＬに対する何らかの追加インフラストラクチャおよび改良を提供するように設計される。
【００７１】
ＷｉｎＦＳおよびＣＤＰは両方とも、既存の．ＮＥＴデータアクセス技術、すなわちＡＤＯ．ＮＥＴを活用して、データにアクセスし操作する。．ＮＥＴ  Ｄａｔａ  Ｐｒｏｖｉｄｅｒは、Ｃｏｎｎｅｃｔｉｏｎ、Ｃｏｍｍａｎｄ、ＤａｔａＲｅａｄｅｒおよび他のこのようなオブジェクトを介して、どのデータソースからでもデータにアクセスする、多少統一のとれた方法を提供する。．ＮＥＴ  Ｄａｔａ  Ｐｒｏｖｉｄｅｒへのコマンドは、文字列として表現され、プロバイダの固有ダイアレクト（より詳細には、プロバイダによって前置されるデータソース）で書かれなければならない。ＣＤＰ／ＷｉｎＦＳの成果の一部として、３つの新規プロバイダ、すなわちＯｂｊｅｃｔ  Ｐｒｏｖｉｄｅｒ、ＥＤＭ  Ｐｒｏｖｉｄｅｒ、およびＷｉｎＦＳ  Ｐｒｏｖｉｄｅｒが供給されることになり、これらはすべて、ｅＳＱＬを固有ダイアレクトとして使うことになる。
【００７２】
２  概観および設計原理
２．１  設計原理
コレクションおよびオブジェクトの第１クラスサポート
ｅＳＱＬは、ユーザがそのオブジェクトおよびコレクションに渡ってシームレスに照会を行うことを容易にしなければならない。
【００７３】
直交性
ｅＳＱＬにおけるコンストラクトは直交でなければならない。所与のコンストラクトの使用に関して、文脈解釈があってはならない。
【００７４】
構成可能性
ｅＳＱＬにおけるコンストラクトは、他のコンストラクト中でも構成可能でなければならない。
【００７５】
ＳＱＬとの類似
ｅＳＱＬは、可能な限り、ＳＱＬのような言語のままであるべきである。ＳＱＬからの逸脱が必要（例えば、上記理由づけによって要求される場合）でない限り、ｅＳＱＬは、ＳＱＬコンストラクトとの忠実性を維持するべきである。
【００７６】
３  言語概観
ｅＳＱＬは、式の概念を含む。式とは、他のプログラミング言語でのように、値を生じるために数値を求めることができるコンストラクトである。ｅＳＱＬクエリは、正当などの式にもなる。ｅＳＱＬは、以下の種類の式を提供する。
【００７７】
３．１  リテラル
リテラルとは、ほとんどのプログラミング言語でのように、単に定数値である。ｅＳＱＬは、文字列および数値リテラル、ならびに特別な（浮動データ型をもつ）ｎｕｌｌリテラルの固有サポートを提供する。
【００７８】
３．２  パラメータ
ｅＳＱＬにおけるパラメータは、式（およびクエリ）が、クエリ外部で定義された値を参照することを可能にする。
【００７９】
３．３  変数参照
ｅＳＱＬにおける変数参照は、式が、同じスコープ内で先に定義された（かつ名前付きの）他の式を参照することを可能にする。
【００８０】
３．４  組込み演算子
ｅＳＱＬは、小さな組込み演算子セットを提供する。これは、＋、−、＊、／のような算術演算子、比較演算子（＜、＞、．．）、論理演算子（ａｎｄ、ｏｒ、ｎｏｔなど）、およびいくつかの種々の演算子（ｃａｓｅ、ｂｅｔｗｅｅｎなど）を含む。
【００８１】
３．５  関数
ｅＳＱＬは、独自の組込み関数を全く定義しない。ｅＳＱＬ関数式は、ユーザが定義したどの（ｅＳＱＬから見える）関数の使用も可能にする。
【００８２】
３．６  オブジェクトナビゲーション、メソッド
こうしたｅＳＱＬ式は、オブジェクトプロパティおよびメソッドが自然に参照され処置されることを可能にする。
【００８３】
３．７  集約関数
ｅＳＱＬにおける集約関数は、そのＳＱＬ相対物のように、コレクションに対する折畳み演算を可能にする。ｅＳＱＬは、ネスト集約、およびどのユーザ定義集約もサポートする。ｅＳＱＬの集約関数は、式のどこでも用いることができるという点で、コレクションベースである。ｅＳＱＬは、クエリ式においてのみ使用可能である、ＳＱＬのようなグループベースの集約もサポートする。
【００８４】
３．８  コンストラクタ
ｅＳＱＬは、３種類のコンストラクタを提供する。ｒｏｗコンストラクタは、無名の、構造的に型づけされた（レコード）値を作成するのに使うことができる。ｏｂｊｅｃｔコンストラクタ（Ｃ＃などにおけるコンストラクタ）は、（名前付き）ユーザ定義オブジェクトを構成するのに使うことができる。ｍｕｌｔｉｓｅｔコンストラクタは、他の値のマルチセットを構成するのに使うことができる。
【００８５】
３．９  型演算
ｅＳＱＬは、ある式（値）の型が照会され処置されることを可能にする演算を提供する。これは、ｉｓ  ｏｆ（Ｃ＃のｉｓ式と同様）のような問合せ演算、ｔｒｅａｔ（Ｃ＃のａｓ式）およびｏｆｔｙｐｅ（Ｃ＃シーケンスのＯｆＴｙｐｅメソッド）のような下位型／上位型キャスト、ならびにｃａｓｔのようなコンバート演算子を含む。
【００８６】
３．１０  集合演算子
ｅＳＱＬは、豊富な１組の集合演算を提供する。これは、ｕｎｉｏｎ、ｉｎｔｅｒｓｅｃｔ、ｅｘｃｅｐｔおよびｅｘｉｓｔｓのような、ＳＱＬのような集合演算子を含む。さらに、ｅＳＱＬは、重複除去（ｄｉｓｔｉｎｃｔ）、メンバシップ検査（ｉｎ）、ジョイン（ｊｏｉｎ）用の演算子をサポートする。
【００８７】
３．１１  クエリ式
クエリ式は、古典的なＳＱＬのｓｅｌｅｃｔ−ｆｒｏｍ−ｗｈｅｒｅ−．．．クエリを表す。
【００８８】
４  言語詳細：ｅＳＱＬの式
４．１  リテラル
ヌル
「ヌル」リテラルは、どの型のヌル値も表すのに使われる。ヌルリテラルは、浮動であると見なされ、（すなわち）どの型とも互換性がある。型づけされたヌルは、ヌルリテラルに優先して、Ｃａｓｔ演算子を介して作成することができる。
【００８９】
【表２】
2009530735.tif 000004
【００９０】
浮動ヌルリテラルを使うことができる場合の規則については、セクション９．６を参照されたい。
【００９１】
ブール値
ブール値リテラルは、「真」および「偽」というキーワードによって表される。
【００９２】
整数（Ｉｎｔ３２、Ｉｎｔ６４）
整数リテラルは、Ｉｎｔ３２またはＩｎｔ６４型でよい。Ｉｎｔ３２リテラルは、一連の数値キャラクタである。Ｉｎｔ６４リテラルは、その後に大文字Ｌが続く一連の数値キャラクタである。
【００９３】
１０進
固定小数点数（１０進）は、一連の数値キャラクタ、ピリオド「．」およびその後に大文字Ｍが続く別の一連の数値キャラクタである。
【００９４】
浮動小数点、ダブル型
倍精度浮動小数点数は、一連の数値キャラクタ、ピリオド「．」およびおそらくはその後に指数部が続く別の一連の数値キャラクタである。単精度浮動小数点数（または浮動小数点）は、その後に小文字ｆが続く倍精度浮動小数点数構文である。
【００９５】
文字列
文字列は、引用符に囲まれた一連のキャラクタである。引用符は、両単一引用符（‘）でも、両二重引用符（“）でもよい。引用識別子は、［  ］または“  “のいずれでも表すことができる。デフォルトでは、［  ］スタイルのみが認められ、“  “コンストラクトは、文字列リテラルとして取り扱われる。ｅＳＱＬパーサは、（パーサオプションによって制御されることになるが、これはこの文書の範囲外である）“  “スタイルの引用識別子を認め得る。その場合、文字列リテラルは、単一引用符のみを用いることができる。これについてのより多くの情報に関しては、セクション９．１．２を参照されたい。
【００９６】
【表３】
2009530735.tif 000005
【００９７】
他のリテラル
ｅＳＱＬは、元来、他のデータ型（ＤａｔｅＴｉｍｅ、Ｇｕｉｄなど）のリテラルをサポートしない。
【００９８】
４．２  パラメータ
パラメータは、一般にホスト言語によって使われる束縛ＡＰＩを介して、照会言語の外部で定義される変数である。各パラメータは、名前および型をもつ。パラメータ名は、プロパティの名前またはクエリ内部で定義される他の名前と明確に区別するために、名前の前に接頭部として、「＠」記号を有して記述される。ホスト言語束縛ＡＰＩは、束縛パラメータ用のＡＰＩを提供する。以下の例は、式におけるパラメータの使用を示す。
【００９９】
【表４】
2009530735.tif 000006
【０１００】
４．３  変数
変数式は、現在のスコープ内で先に定義された（名前付きの）式への参照である。変数参照は、６で定義されるような有効な識別子でなければならない。以下の例は、式における変数の使用を示す。
【０１０１】
【表５】
2009530735.tif 000007
【０１０２】
４．４  組込み演算子
ｅＳＱＬは、以下のように、いくつかの組込み演算子を提供する。
【０１０３】
４．４．１  算術
【０１０４】
【表６】
2009530735.tif 000008
【０１０５】
算術演算子は、Ｉｎｔ３２、Ｉｎｔ１６、Ｉｎｔ６４、Ｄｏｕｂｌｅ、Ｓｉｎｇｌｅ、およびＤｅｃｉｍａｌなどの数値プリミティブ用に定義される。バイナリ演算子の場合、演算子が適用される前に、オペランドに対して暗黙の型昇格が起こる。全算術演算子の結果型は、昇格されたオペランド型と同じである。加算も、文字列に対して定義され、連結として振る舞う。
【０１０６】
４．４．２  比較
【０１０７】
【表７】
2009530735.tif 000009
【０１０８】
比較演算子は、Ｂｙｔｅ、Ｉｎｔ３２、Ｉｎｔ１６、Ｉｎｔ６４、Ｄｏｕｂｌｅ、ＳｉｎｇｌｅおよびＤｅｃｉｍａｌなどの数値プリミティブ、ＳｔｒｉｎｇならびにＤａｔｅＴｉｍｅ用に定義される。比較演算子が適用される前に、オペランドに対する暗黙の型昇格が起こる。比較演算子は、常にブール値を生ずる。
【０１０９】
等式および不等式は、ブール値型および識別を有する任意のオブジェクト型用に定義される。識別を有する非基本要素オブジェクトは、同じ識別を共有する場合、等しいと見なされる。
【０１１０】
４．４．３  論理
【０１１１】
【表８】
2009530735.tif 000010
【０１１２】
論理演算子は、ブール値型用にのみ定義され、常にブール値型を戻す。
【０１１３】
４．４．４  ｃａｓｅ
ｃａｓｅ式は、ＴＳＱＬのｃａｓｅ式と同様のセマンティクスをもつ。ｃａｓｅ式は、どの式が適切な結果を生ずることになるか判定するための、一連の条件つきテストを行うのに使われる。
【０１１４】
ｂ１、ｂ２、．．．、ｂｎ−１がＢｏｏｌｅａｎ型の式であり、ｅ１、ｅ２、．．．、ｅｎが何らかのＳ型の式である場合、以下の式は、Ｓ型の単一値を生ずる有効なｃａｓｅ式である。
【０１１５】
【表９】
2009530735.tif 000011
【０１１６】
この形のｃａｓｅ式は、正しい結果として生じる式を判定するための、一連の１つまたは複数のＢｏｏｌｅａｎ式に当てはまる。値「真」となる第１のｗｈｅｎ式は、対応するｔｈｅｎ式を生ずる。それ以外の式は、評価されない。ｗｈｅｎ条件のどれも満たされない場合、その結果は、ｅｌｓｅ式（存在する場合）、または「ヌル」（ｅｌｓｅ式がない場合）を評価した結果となる。ｃａｓｅ式の実際の結果型を判定するための異なる結果式（ｅ１、ｅ２、．．．ｅｎ、ｖｎ）の間で暗黙の型昇格が起こり得ることに留意されたい。
【０１１７】
４．４．５  ｂｅｔｗｅｅｎ
ｂｅｔｗｅｅｎ式は、ＳＱＬのｂｅｔｗｅｅｎ式と同じセマンティクスをもつ。この式は、所与の式が下限と上限の間の値を結果として生じるかどうか判定する。
【０１１８】
【表１０】
2009530735.tif 000012
【０１１９】
ｅ１、ｅ２、ｅ３が何らかのＴ型であるすべての式である場合、上記の式は、有効なｂｅｔｗｅｅｎ演算子式である。ｂｅｔｗｅｅｎ式は、同じ値に対する２つの比較演算子を書くことの短縮形である。ｂｅｔｗｅｅｎ構文は、ｅ１が複合式である場合に便利である。
【０１２０】
【表１１】
2009530735.tif 000013
【０１２１】
ｂｅｔｗｅｅｎ式の逆を示すのに、ｎｏｔ−ｂｅｔｗｅｅｎ式を使うことができる。
【０１２２】
【表１２】
2009530735.tif 000014
【０１２３】
４．４．６  ｌｉｋｅ
ｌｉｋｅ式は、ＴＳＱＬ用に記述されるのと同じセマンティクスをもつ。この式は、文字列がパターンと一致するかどうか判定し、文字列が一致する場合は「真」に、一致しない場合は「偽」に帰結する。ｍａｔｃｈ、ｐａｔｔｅｒｎおよびｅｓｃａｐｅが、Ｓｔｒｉｎｇ型をもつすべての式である場合、以下は、Ｂｏｏｌｅａｎ値を生ずる有効なｌｉｋｅ式である。  
match like pattern
match not like pattern
match like pattern escape escape
match not like pattern escape escape
ｐａｔｔｅｒｎ文字列構文は、ＴＳＱＬのｐａｔｔｅｒｎ文字列構文と同じである。
【０１２４】
４．４．７  ヌルテスト（ｉｓ  ｎｕｌｌ）
ｉｓ−ｎｕｌｌ演算子は、式が値「ヌル」を結果として生じるかどうか判定するのに使われる。式が値「ヌル」を結果として生じる場合、式は、値「真」を結果として生じる。ヌルを結果として生じない場合、式は、値「偽」を結果として生じる。ｅが式である場合、以下の式は、ブール値を生ずる有効な式である。
e is null
e is not null
外部ジョインの要素がヌルでないかどうか判定するのに、ｉｓ−ｎｕｌｌ演算子を使う。
【０１２５】
【表１３】
2009530735.tif 000015
【０１２６】
メンバが実効値をもつかどうか判定するのに、ｉｓ−ｎｕｌｌ演算子を使う。
【０１２７】
【表１４】
2009530735.tif 000016
【０１２８】
４．５  メンバアクセス
メンバアクセスは一般に、ｄｏｔ演算子としても知られる。オブジェクトインスタンスのプロパティまたはフィールドの値を生ずるのに、メンバアクセス演算子を用いる。ｍが、Ｍ型をもつＴ型のメンバであり、ｔがＴ型のインスタンスである場合、ｔ．ｍは、Ｍ型である値を生ずる正当なメンバアクセス式である。
【０１２９】
【表１５】
2009530735.tif 000017
【０１３０】
４．６  メソッド呼出し
メソッド呼出しは、メソッドに対する明示的なコールである。この呼出しは、メソッドコールという結果を生ずる。メソッドは、ある型のインスタンスメソッド、ある型の静的メソッド、またはグローバル静的メソッド（すなわち）スタンドアロン関数でよい。
【０１３１】
ｍが、Ｍ型を戻すとともに（Ｐ１、Ｐ２、．．．、Ｐｎ）型のパラメータを有するＴ型のメソッドであり、ｔがＴ型のインスタンスであり、ｅ１がＰ１型の式である、などの場合、ｔ．ｍ（ｅ１，ｅ２，．．．，ｅｎ）は、Ｍ型の値を生ずる有効なメソッド呼出しである。
【０１３２】
ｍが、Ｍ型を戻すとともに（Ｐ１、Ｐ２、．．．、Ｐｎ）型のパラメータを有するＴ型のメソッドであり、ｑｎがＴ型を指す修飾名であり、ｅ１がＰ１型の式である、などの場合、ｑｎ．ｍ（ｅ１，ｅ２，．．．，ｅｎ）は、Ｍ型の値を生ずる有効な静的メソッド呼出しである。
【０１３３】
ｍが、Ｍ型を戻すとともに（Ｐ１、Ｐ２、．．．、Ｐｎ）型のパラメータを有するメソッドＴであり、ｑｎがメソッドの名前空間接頭部を指す修飾名であり、ｅ１がＰ１型の式である、などの場合、ｑｎ．ｍ（ｅ１，ｅ２，．．．，ｅｎ）は、Ｍ型の値を生ずる有効な静的メソッド呼出しである。
【０１３４】
ｅＳＱＬクエリ中に現れ得るメソッド呼出しの例は、基本要素データ型に組み込まれたメソッドの使用でよい。
【０１３５】
【表１６】
2009530735.tif 000018
【０１３６】
４．６．１  多重定義の解決
同じ名前をもつ複数のメソッドを定義することができる。与えられた式によってどのメソッドが参照されるか判定するために、こうした規則に従う。単一メソッドのみを生ずる、続けて適用される第１の規則は、解決済みメソッドである。
１．同じ数のパラメータを有するメソッドが存在する。
２．各引数型がパラメータ型と全く一致し、または「ヌル」リテラルであるメソッド。
３．各引数型がパラメータ型と全く一致し、またはその下位型であり、あるいは引数が「ヌル」リテラルであるメソッド。下位型のコンバートの数が最小であるメソッドが勝つ。
４．各引数型がパラメータ型と全く一致し、その下位型であり、またはそれに昇格することができ、あるいは引数が「ヌル」リテラルであるメソッド。下位型のコンバートおよび昇格の数が最小であるメソッドが勝つ。
５．メソッド呼出し式があいまいである。
【０１３７】
こうした規則を使って単一メソッドを抽出することができるとしても、引数は依然として、パラメータと一致するわけではないことに留意されたい。これが成り立つ場合、引数はエラーとなる。
【０１３８】
４．７  ｅｎｕｍ
ｅｎｕｍは、名前によって参照される強く型づけされた整数値である。ｅｎｕｍは、その後にｄｏｔ演算子およびｅｎｕｍの名前が続くｅｎｕｍの型を参照するための修飾名を使って指定される。ｑｎが何らかのｅｎｕｍ  Ｅの修飾名であり、ｅｎがその列挙の値の名前である場合、ｑｎ．ｅｎは有効なｅｎｕｍ参照である。
【０１３９】
【表１７】
2009530735.tif 000019
【０１４０】
４．８  型演算
ｅＳＱＬは、式の値の型と連携するためのいくつかの演算を提供する。
【０１４１】
４．８．１  ｉｓ  ｏｆ
ｉｓ  ｏｆ式は、式が指定された型のインスタンスであるかどうか調べる。
【０１４２】
【表１８】
2009530735.tif 000020
【０１４３】
ｅが何らかのコンパイル時Ｓ型であり、ＳがＴの下位型／上位型いずれかである場合、上の式は有効な式であり、Ｂｏｏｌｅａｎ型の結果を戻す。ｅの型が、実行時にＴ（またはＴの何らかの下位型）であると判定された場合、ｅ  ｉｓ  ｏｆ  ＴはＴｒｕｅを戻す。ｅが実行時にｎｕｌｌである場合、この式はｎｕｌｌを戻し、ｎｕｌｌでない場合、この式の結果はＦａｌｓｅである。
【０１４４】
唯一の修飾子が指定された場合、ｅがまさにＴ型であり、その下位型のどれでもない場合のみ、式は真を戻す。式ｅ  ｉｓ  ｎｏｔ  ｏｆ（Ｔ）およびｅ  ｉｓ  ｎｏｔ  ｏｆ（ｏｎｌｙ  Ｔ）は、それぞれｎｏｔ（ｅ  ｉｓ  ｏｆ（Ｔ））、およびｎｏｔ（ｅ  ｉｓ  ｏｆ（ｏｎｌｙ  Ｔ））と統語的に等しい。ＳがＴの下位型でも上位型でもない場合、この式は、コンパイル時エラーを起こす。
【０１４５】
４．８．１．１  ｔｒｅａｔ
ｔｒｅａｔ式は、与えられた式を上位型／下位型によって型づけし直すことを試みる。
【０１４６】
【表１９】
2009530735.tif 000021
【０１４７】
ｅがＳ型を有し、ＴがＳの下位型であるかまたはＳがＴの下位型である場合、上式は、有効なｔｒｅａｔ式であり、Ｔ型の値を生ずる。ＳもＴも他方の下位型でない場合、式は、コンパイル時エラーを結果として生じる。ｅがＥｍｐｌｏｙｅｅ型を有しＭａｎａｇｅｒがＥｍｐｌｏｙｅｅの下位型である場合、以下の式は、同じ値ｅを生ずるが、ＥｍｐｌｏｙｅｅではなくＭａｎａｇｅｒとして型づけされる。
【０１４８】
【表２０】
2009530735.tif 000022
【０１４９】
ｅの値が実際にはＭａｎａｇｅｒ型でない場合、式は、値ｎｕｌｌを生ずる。
【０１５０】
４．８．１．２  ｃａｓｔ
ｃａｓｔ式は、ＴＳＱＬのｃｏｎｖｅｒｔ式と同様のセマンティクスをもつ。ｃａｓｔ式は、ある型の値を別の型の値にコンバートするのに使われる。特定の型のコンバートのみが言語によってサポートされる。
【０１５１】
【表２１】
2009530735.tif 000023
【０１５２】
ｅが何らかのＳ型であり、ＳがＴにコンバート可能な場合、上式は、有効なｃａｓｔ式である。Ｔは基本要素（スカラー型）でなければならない。ｃａｓｔ式の使用は、明示的コンバートと見なされる。明示的コンバートは、データを切り詰めることも、精度を落とすこともある。ｅＳＱＬによってサポートされる有効なキャストのリストについては、セクション１０．５に記述してある。
【０１５３】
４．８．１．３  ＯｆＴｙｐｅ
ＯｆＴｙｐｅ式は、コレクションの各要素に対して型検査を実施するために発行される式型を指定する。ＯｆＴｙｐｅ式は、その型と等価であった、またはその下位型であった要素のみを含む指定された型の新しいコレクションを生じる。
【０１５４】
ｔｓが、ｃｏｌｌｅｃｔｉｏｎ＜Ｓ＞型のコレクションでありＴがＳの下位型である場合、ＯｆＴｙｐｅ（ｔｓ，Ｔ）は、個々のｅ型、すなわちＴｅがＴの下位型であるｔｓの要素ｅすべてからなるコレクションを生ずるｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型の式である。ＯｆＴｙｐｅ式は、以下のクエリ式の短縮形である。
【０１５５】
【表２２】
2009530735.tif 000024
【０１５６】
ＭａｎａｇｅｒがＥｍｐｌｏｙｅｅの下位型であるとすると、以下の式は、従業員のコレクションから、管理職のみのコレクションを生じる。
【０１５７】
【表２３】
2009530735.tif 000025
【０１５８】
型フィルタを使ってコレクションをアップキャストすることも可能である。
【０１５９】
【表２４】
2009530735.tif 000026
【０１６０】
コレクションは現在、管理職のコレクションとして型づけされるが、すべての役員は管理職なので、結果として生じたコレクションは依然として、元の役員全員を含む。既知の不正な型キャストを行うことはできない。以下の式は、コンパイル時エラーを起こすことになる。（当然ながら、ＡｄｄｒｅｓｓはＥｍｐｌｏｙｅｅの下位型／上位型でないと仮定する）。
【０１６１】
【表２５】
2009530735.tif 000027
【０１６２】
４．９  参照
ｅＳＱＬは、参照用に以下の演算子をサポートする。
【０１６３】
４．９．１  Ｒｅｆ
Ｒｅｆ演算子は、ｅｎｔｉｔｙｓｅｔ用の「相関変数」に適用されると、そのコレクションからエンティティへの参照を生じる。例えば、以下のクエリは、各Ｏｒｄｅｒへの参照を戻す。
【０１６４】
【表２６】
2009530735.tif 000028
【０１６５】
以下は、ｒｅｆ演算子の不正な使用である。相関変数は、現在のスコープ内のエンティティセットに分解しなければならない。
【０１６６】
【表２７】
2009530735.tif 000029
【０１６７】
４．９．２  ＣｒｅａｔｅＲｅｆ
ＣｒｅａｔｅＲｅｆ演算子は、ｅｎｔｉｔｙｓｅｔ中のエンティティへの参照を生じるのに使うことができる。この演算子への第１引数は、ｅｎｔｉｔｙｓｅｔ識別子であり（文字列リテラルではない）、第２引数は、エンティティ型のキープロパティに対応する、レコードとして型づけされた式である。
【０１６８】
【表２８】
2009530735.tif 000030
【０１６９】
レコードとして型づけされた式は、エンティティ用のキー型と構造的に等価でなければならず、（すなわち）エンティティキーと同じ数および型のフィールドを同じ順序でもたなければならないが、フィールドの名前は不適切となる。
【０１７０】
４．９．３  Ｋｅｙ
Ｋｅｙ演算子は、ＣｒｅａｔｅＲｅｆ演算子の逆であり、ｒｅｆ型をもつ式のキー部分を抽出するのに使うことができる。Ｋｅｙ演算子の戻り型は、レコード型であり、エンティティの各キーに対して１つのフィールドを、同じ順序でもつ。
【０１７１】
【表２９】
2009530735.tif 000031
【０１７２】
４．９．４  Ｄｅｒｅｆ
Ｄｅｒｅｆ演算子は、参照値を取得し、その間接参照の結果を生じる。
【０１７３】
【表３０】
2009530735.tif 000032
【０１７４】
ｒがｒｅｆ＜Ｔ＞型の参照である場合、Ｄｅｒｅｆ（ｒ）は、ｒによって参照されるエンティティを生ずるＴ型の式である。参照値がヌルであるか、または懸垂している、（すなわち）参照の目標が存在しない場合、Ｄｅｒｅｆ演算子の結果はヌルになる。
【０１７５】
４．９．５  属性間接参照
「．」演算子を使って、参照をナビゲートすることができる。
【０１７６】
以下の断片は、ＣｕｓｔＲｅｆプロパティを介してナビゲートすることによって、（Ｃｕｓｔｏｍｅｒの）Ｉｄプロパティを抽出する。
【０１７７】
【表３１】
2009530735.tif 000033
【０１７８】
参照値がヌルであるか、または懸垂（dangle）している、（すなわち）参照の目標が存在しない場合、結果はヌルとなる。
【０１７９】
４．１０  コンストラクタ
ｅＳＱＬは、３種類のコンストラクタ、すなわちローコンストラクタ、オブジェクトコンストラクタおよびマルチセットコンストラクタを提供する。
【０１８０】
４．１０．１  ローコンストラクタ
ローコンストラクタは、１つまたは複数の値から、構造的に型づけされた無名のレコードを構成するのに使うことができる。ローコンストラクタの結果型はロー型であり、そのフィールド型は、ローを構成するのに使われる値の型に対応する。例えば、式
【０１８１】
【表３２】
2009530735.tif 000034
【０１８２】
は、Ｒｅｃｏｒｄ（ａ  ｉｎｔ，ｂ  ｓｔｒｉｎｇ，ｃ  ｉｎｔ）型の値を生じる。
【０１８３】
ローコンストラクタ中のすべての式について、エイリアスが作成されなければならない。エイリアスが与えられない場合、ｅＳＱＬは、０で規定されるエイリアス作成規則によりエイリアスを生成することを試みる。ローコンストラクタ中の式は、同じコンストラクタにおいて先に（左側で）定義されたエイリアスを参照することができない。
【０１８４】
同じローコンストラクタ中の２つの式が同じエイリアスをもつのは不正である。ｄｏｔ（．）演算子は、レコードからフィールドを抽出するのに使うことができる（オブジェクトの抽出プロパティと同様である）。
【０１８５】
４．１０．２  ＮａｍｅｄＴｙｐｅコンストラクタ（ＮａｍｅｄＴｙｐｅ初期化子）
ｅＳＱＬは、名前付き型コンストラクタ（初期化子）が、名前付きの複合型および／またはエンティティ型のインスタンスを作成するのに使われるようにする。以下の式は、Ｐｅｒｓｏｎ型のインスタンスを作成する（Ｐｅｒｓｏｎ型はそうした２つの属性をもつと仮定する）。
【０１８６】
【表３３】
2009530735.tif 000035
【０１８７】
コンストラクタへの引数は、型の属性の宣言と同じ順序であると仮定される。
【０１８８】
４．１０．３  Ｃｏｌｌｅｃｔｉｏｎコンストラクタ
マルチセットコンストラクタは、値のリストから、マルチセットのインスタンスを作成する。コンストラクタ中の値はすべて、相互に互換可能なＴ型でなければならず、コンストラクタは、Ｍｕｌｔｉｓｅｔ＜Ｔ＞型のコレクションを生じる。以下の式は、整数のマルチセットを作成する。
【０１８９】
【表３４】
2009530735.tif 000036
【０１９０】
４．１１  集合演算
このセクションは、様々な集合演算子を含む。
【０１９１】
４．１１．１  ｄｉｓｔｉｎｃｔ
ｄｉｓｔｉｎｃｔ式は、すべての重複参照が削除された新しいコレクションを生ずることによって、オブジェクトのコレクションをセットにコンバートするのに使われる。ｃがｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションである場合、ｄｉｓｔｉｎｃｔ（ｃ）は、重複をもたないｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションを生ずる有効なｄｉｓｔｉｎｃｔ式である。Ｔ型は、等式に匹敵（equal-comparable）しなければならない。ｄｉｓｔｉｎｃｔ式は、ｓｅｌｅｃｔ式の短縮形である。
【０１９２】
【表３５】
2009530735.tif 000037
【０１９３】
４．１１．２  ｆｌａｔｔｅｎ
ｆｌａｔｔｅｎ式は、コレクションからなるコレクションを、同じ要素すべてをもち、ネスト構造をもたないフラット化コレクションにコンバートするのに使われる。ｃがｃｏｌｌｅｃｔｉｏｎ＜ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞＞型のコレクションである場合、ｆｌａｔｔｅｎ（ｃ）は、ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型の新しいコレクションを生ずる有効なｆｌａｔｔｅｎ式である。ｆｌａｔｔｅｎ式は、ｓｅｌｅｃｔ式使用の短縮である。
【０１９４】
【表３６】
2009530735.tif 000038
【０１９５】
４．１１．３  ｅｘｉｓｔｓ
ｅｘｉｓｔｓ式は、ＴＳＱＬのｅｘｉｓｔｓ式と同じセマンティクスを有する。この式は、コレクションが空かどうか判定する。コレクションが空でない場合、ｅｘｉｓｔｓ式は真を戻し、空の場合は偽を戻す。ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションである場合、ｅｘｉｓｔｓ（ｃ）は、Ｂｏｏｌｅａｎ型の単一値を生ずる有効なｅｘｉｓｔｓ式である。
【０１９６】
４．１１．４  ｉｎ
ｉｎ演算子は、コレクション中のメンバシップ向けの値を検査するのに使われる。「ｉｎ」キーワードの左手側にある式の値は、右手側にある式で表されるコレクション中で検索される。ｅがＴ型を有する式でありｔｓがＣｏｌｌｅｃｔｉｏｎ＜Ｓ＞型を有するコレクションであり、ＳおよびＴが上位型／下位型関係を有する場合、以下の式は、有効なｉｎ演算子式である。
e in ts
e not in ts
以下の例では、「Ｂｏｂ」という名前が、顧客の名前のセットの中で検索される。
【０１９７】
【表３７】
2009530735.tif 000039
【０１９８】
値がコレクション中にあると分かった場合、ｉｎ演算子は、値ｔｒｕｅを生ずる。値がヌルであるか、またはコレクションがヌルである場合、ｉｎ演算子は、値ｎｕｌｌを生ずる。それ以外の場合、ｉｎ演算子は、値ｆａｌｓｅを生ずる。この演算子のｎｏｔ形は、逆を生ずる。
【０１９９】
４．１１．５  ｕｎｉｏｎ、ｕｎｉｏｎ  ａｌｌ
ｅＳＱＬにおけるｕｎｉｏｎおよびｕｎｉｏｎ  ａｌｌ式は、そのＴＳＱＬ同等物と同じセマンティクスを有する。ＵｎｉｏｎＡｌｌは、（重複を有する）２つのコレクションの組み合わされた内容を含むコレクションを生じる。ｕｎｉｏｎは、重複が削除されたコレクションを生じる。
【０２００】
ｃ１がＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｃ２がＣｏｌｌｅｃｔｉｏｎ＜Ｓ＞型のコレクションであり、ここでＭはＴおよびＳの共通上位型である場合、ｃ１  ｕｎｉｏｎ  ｃ２およびｃ１  ｕｎｉｏｎ  ａｌｌ  ｃ２は、Ｃｏｌｌｅｃｔｉｏｎ＜Ｍ＞型のコレクションを生ずる有効なｕｎｉｏｎ式である。
【０２０１】
以下の例は、ワシントンに住んでいるか、または得意客である全顧客のセットを識別する。第１の式は、どの重複（例えば、ワシントンにも住んでいる得意客）も排除するが、第２式は、すべての重複を保持する。
【０２０２】
【表３８】
2009530735.tif 000040
【０２０３】
４．１１．６  Ｉｎｔｅｒｓｅｃｔ
Ｉｎｔｅｒｓｅｃｔ式は、ＴＳＱＬのｉｎｔｅｒｓｅｃｔ式と同じセマンティクスを有する。この式は、２つのコレクションの交差を判定する。ｃ１がＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｃ２がＣｏｌｌｅｃｔｉｏｎ＜Ｓ＞型のコレクションであり、ここでＭはＴおよびＳの共通上位型である場合、ｃ１  ｉｎｔｅｒｓｅｃｔ  ｃ２は、Ｃｏｌｌｅｃｔｉｏｎ＜Ｍ＞型のコレクションを生ずる有効なｉｎｔｅｒｓｅｃｔ式である。以下の例は、ワシントンに住んでおり、得意客である全顧客のセットを識別する。
【０２０４】
【表３９】
2009530735.tif 000041
【０２０５】
４．１１．７  Ｅｘｃｅｐｔ
Ｅｘｃｅｐｔ式は、ＴＳＱＬのｅｘｃｅｐｔ式と同じセマンティクスを有する。この式は、２つのコレクションの単方向の違いを判定する。ｃ１がＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｃ２がＣｏｌｌｅｃｔｉｏｎ＜Ｓ＞型のコレクションであり、ここでＭはＴおよびＳの共通上位型である場合、ｅ１  ｅｘｃｅｐｔ  ｃ２は、Ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションを生ずる有効なｅｘｃｅｐｔ式である。以下の例では、悪い顧客ではない全顧客のセットが識別される。
【０２０６】
【表４０】
2009530735.tif 000042
【０２０７】
４．１１．８  ｏｖｅｒｌａｐｓ
ｏｖｅｒｌａｐｓ式は、２つのコレクションが共通メンバをもつかどうか判定する。ｃ１がＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｃ２がＣｏｌｌｅｃｔｉｏｎ＜Ｓ＞型のコレクションであり、ここでＭはＴおよびＳの共通上位型である場合、ｃ１  ｏｖｅｒｌａｐｓ  ｃ２は、Ｂｏｏｌｅａｎ型の結果を生ずる有効なｏｖｅｒｌａｐｓ式である。以下の例
【０２０８】
【表４１】
2009530735.tif 000043
【０２０９】
は、ワシントンのいずれかの顧客が得意客であるかどうか調べるとともに、
【０２１０】
【表４２】
2009530735.tif 000044
【０２１１】
の構文的ショートカットである。
【０２１２】
４．１１．９  ｅｌｅｍｅｎｔ
ｅｌｅｍｅｎｔ式は、単集合コレクションから要素を抽出する。ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションである場合、ｅｌｅｍｅｎｔ（ｃ）は、Ｔ型のインスタンスを生ずる有効なｅｌｅｍｅｎｔ式である。以下の例は、悪い顧客のセットから単集合要素を抽出することを試みる。
【０２１３】
【表４３】
2009530735.tif 000045
【０２１４】
コレクションが空であるか、または複数の要素をもつ場合、ｅｌｅｍｅｎｔ式はヌルを戻す。
【０２１５】
４．１２  コレクションのナビゲーション
ｅＳＱＬは、コレクションをより簡単に扱うことができるようにするいくつかの統語コンストラクトを提供する。
【０２１６】
４．１２．１  射影
．．（コレクション−射影）演算子は、コレクションから要素を射影するのに使われる。ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｐがＱ型をもつＴのプロパティである場合、ｃ．．ｐは、Ｃｏｌｌｅｃｔｉｏｎ＜Ｑ＞型のコレクションを生じる。より全般的には、ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｅがＱ型の何らかの式である場合、ｃ．．ｅは、ｃの各要素ごとにｅを評価した結果を含むＣｏｌｌｅｃｔｉｏｎ＜Ｑ＞型のコレクションを生じる。以下の例
【０２１７】
【表４４】
2009530735.tif 000046
【０２１８】
は、全部署の大文字化された名前を得るとともに、以下のクエリ
【０２１９】
【表４５】
2009530735.tif 000047
【０２２０】
のショートカットである。
【０２２１】
４．１２．２  フィルタリング
．？（コレクション−フィルタ）演算子は、コレクションから要素をふるい落とすのに使われる。ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションであり、ｅがＱ型をもつブール式である場合、ｃ．？ｅは、述部ｅを満たしたｃの要素のみを含むＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションを生じる。以下の例
【０２２２】
【表４６】
2009530735.tif 000048
【０２２３】
は、シアトルを拠点とする全部署のセットを得るとともに、以下のクエリ
【０２２４】
【表４７】
2009530735.tif 000049
【０２２５】
のショートカットである。
【０２２６】
４．１２．３  フラット化された射影
．．．（フラット化コレクション−射影）演算子は、ネストされたコレクションから要素を射影するのに使われる。より全般的には、ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞＞型のコレクションであり、ｅがＱ型の何らかの式である場合、ｃ．．．ｅは、第１のフラット化ｃの結果を含むＣｏｌｌｅｃｔｉｏｎ＜Ｑ＞型のコレクションを生じ、次いで、ｃの各要素ごとにｅを評価する。以下の例
【０２２７】
【表４８】
2009530735.tif 000050
【０２２８】
は、ＥｍｐｌｏｙｅｅｓがＤｅｐａｒｔｍｅｎｔのセット値プロパティであると仮定し、全従業員の大文字化された名前を得るとともに、以下のクエリ
【０２２９】
【表４９】
2009530735.tif 000051
【０２３０】
のショートカットである。
【０２３１】
４．１２．４  フラット化フィルタリング
．．？（フラット化コレクション−フィルタ）演算子は、ネストされたコレクションから要素をふるい落とすのに使われる。より全般的には、ｃがＣｏｌｌｅｃｔｉｏｎ＜Ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞＞型のコレクションであり、ｅが何らかのブール式である場合、ｃ．．？ｅは、第１のフラット化ｃの結果を含むＣｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションを生じ、次いで、ｅを満たさない結果の要素をふるい落とす。以下の例
【０２３２】
【表５０】
2009530735.tif 000052
【０２３３】
は、ＥｍｐｌｏｙｅｅｓがＤｅｐａｒｔｍｅｎｔのセット値プロパティであると仮定し、給料が１００００より多い全従業員のセットを得るとともに、以下のクエリ
【０２３４】
【表５１】
2009530735.tif 000053
【０２３５】
のショートカットである。
【０２３６】
スコープ作成規則
上のケースすべてにおいて、Ｃｏｌｌｅｃｔｉｏｎ＜Ｔ＞型のコレクションの中をナビゲートするとき、新しいスコープが作成され、現在のコレクション要素は、変数ｉｔに束縛される。統語の便宜上、Ｔのプロパティ（およびメソッド）も、スコープ内にあると仮定されるが、これらは、ｉｔ変数を介したメンバアクセスのためのショートカットであると見なされる。例えば、以下のようになる。
【０２３７】
【表５２】
2009530735.tif 000054
【０２３８】
４．１３  集約関数
集約は、一連の入力値を（必ずしもそうではないが、一般には単一値に）削減する式である。こうした関数は普通、ｓｅｌｅｃｔ式のｇｒｏｕｐ−ｂｙ句とともに使われ、実際にどこで使うことができるかに関して、制約がある。各集約演算は、１つまたは複数の型に対して定義される。ｅＳＱＬは、集約セットを定義しない。ｅＳＱＬは、集約関数を扱うための周囲のメタデータ空間に依拠するだけである。
【０２３９】
Ｃｏｌｌｅｃｔｉｏｎベースの集約
Ｃｏｌｌｅｃｔｉｏｎベースの集約は、特定の値セットに渡って算出される集約である。例えば、ｏｒｄｅｒｓが、全注文からなるコレクションであるとすると、最も早い出荷日付を以下の式で算出することができる。
【０２４０】
【表５３】
2009530735.tif 000055
【０２４１】
コレクションベースの集約内部の式は、現在の周囲の名前解決スコープを使って評価される。
【０２４２】
グループベースの集約
グループベースの集約は、ｇｒｏｕｐ−ｂｙ句によって定義されるグループに渡って算出される。結果の中の各グループごとに、各グループ中の要素を集約算出への入力として使って、別個の集約が算出される。ｇｒｏｕｐ−ｂｙ句がｓｅｌｅｃｔ式中で使われると、グループ化式の名前、集約または定数式のみを、射影またはｏｒｄｅｒ−ｂｙ句に提示することができる。以下の例は、各製品ごとに注文される平均的量を算出する。
【０２４３】
【表５４】
2009530735.tif 000056
【０２４４】
グループベースの集約は、コレクションベースの式の、（ＳＱＬとの互換性を保つための）単なるショートカットである。上の例は、実際には以下のように翻訳されることになる。
【０２４５】
【表５５】
2009530735.tif 000057
【０２４６】
上式で、ｇｒｏｕｐ式は、ｇｒｏｕｐ−ｂｙ句によって暗黙的に生じられたネスト集約を指す。この式は、ｓｅｌｅｃｔ式中に明示的なｇｒｏｕｐ−ｂｙ句のないグループベースの集約をもつことが可能である。全要素は、定数に基づいたグループ化を指定するケースと等しく、単一グループとして取り扱われることになる。
【０２４７】
【表５６】
2009530735.tif 000058
【０２４８】
グループベースの集約内部の式は、ｗｈｅｒｅ句式からは見えるはずの名前解決スコープを使って評価される。
【０２４９】
ＳＱＬのルックアンドフィールを保つために、グループベースの集約は、その入力においてａｌｌまたはｄｉｓｔｉｎｃｔ修飾子を指定することもできる。ｄｉｓｔｉｎｃｔ修飾子が指定された場合、集約が計算される前に、集約入力コレクションから重複が排除される。ａｌｌ修飾子が指定された（または修飾子が指定されなかった）場合、重複除去は実施されない。ｄｉｓｔｉｎｃｔ修飾子は実際には、ｄｉｓｔｉｎｃｔ演算子の統語的短縮形である。
【０２５０】
【表５７】
2009530735.tif 000059
【０２５１】
Ｃｏｌｌｅｃｔｉｏｎベースの集約とグループベースの集約との区別
Ｃｏｌｌｅｃｔｉｏｎベースの集約は、ｅＳＱＬにおいて好ましい集約指定モードである。ただし、ＳＱＬユーザにとっての移行に伴う苦痛を和らげるために、グループベースの集約もサポートされる。同様に、集約入力への修飾子としてのｄｉｓｔｉｎｃｔ（またはａｌｌ）の指定も、ＳＱＬのような振舞いのためにサポートされるが、好ましい機構は、ｄｉｓｔｉｎｃｔ（）演算子を代わりに使うことである。グループベースの集約とコレクションベースの集約との名前解決ポリシーの違いにより、実装が両方のスコープの下で評価を試みることが必要になり得る。その戦略では、第１にコレクションベースの集約、第２にグループベースの集約としての翻訳を好む。
【０２５２】
４．１４  サポートされない式
４．１４．１  非修飾述部
ＳＱＬは、以下の形のコンストラクトを可能にする。
【０２５３】
【表５８】
2009530735.tif 000060
【０２５４】
ｅＳＱＬは、このようなコンストラクトをサポートしない。上式は、ｅＳＱＬでは、以下のように表現することができる。
【０２５５】
【表５９】
2009530735.tif 000061
【０２５６】
ｅＳＱＬは、非修飾式で拡張することができよう。
【０２５７】
４．１４．２  ＊
ＳＱＬは、全カラムが射影される必要があることを示すための、ｓｅｌｅｃｔ句における構文的ショートカットとして、「＊」の使用をサポートする。
【０２５８】
５  言語の詳細：クエリ式
クエリ式は、最も汎用なｅＳＱＬ式であり、ＳＱＬに精通したプログラマにとって最も常識的である。この式は、多くの異なるクエリ演算子を単一構文に組み合わせる。こうした演算子の多くは、個々に指定することができるが、どれも、クエリ式に組み合わされるとき程の表現力はない。特段の指定がない限り、ｓｅｌｅｃｔ式は、ＴＳＱＬのｓｅｌｅｃｔステートメントと同様に振る舞う。
【０２５９】
クエリ式は、オブジェクトのコレクションに連続演算を適用する一連の句からなる。こうした句は、標準ＳＱＬのｓｅｌｅｃｔステートメントに見られる同じ句、すなわちｓｅｌｅｃｔ、ｆｒｏｍ、ｗｈｅｒｅ、ｇｒｏｕｐ  ｂｙ、ｈａｖｉｎｇおよびｏｒｄｅｒ  ｂｙに基づく。
【０２６０】
クエリ式は、その最も単純な形において、その後に射影リスト、ｆｒｏｍキーワード、ソース表現、ｗｈｅｒｅキーワードおよび最後にフィルタリング条件が続くｓｅｌｅｃｔキーワードによって指定される。
【０２６１】
【表６０】
2009530735.tif 000062
【０２６２】
この例では、ｃは何らかのＴ型のオブジェクトのコレクションであり、ｍはＭ型を有するＴのメンバであり、ｅはＴの１つまたは複数のメンバを参照し得るＢｏｏｌｅａｎ式である。クエリは、Ｍ型を有するオブジェクトの新しいコレクションを生じる。
【０２６３】
５．１  Ｆｒｏｍ句
ほとんどの部分に関して、ｆｒｏｍ句は、ＴＳＱＬ向けに記述されるのと同じセマンティクスを有する。ただし、構文における制限ははるかに少なく、正当なソースとなるべきコレクションを生ずるどの言語式も認める。ｆｒｏｍ句は、１つまたは複数のｆｒｏｍ句項目からなる、コンマで区切られたリストである。ｆｒｏｍ句は、ｓｅｌｅｃｔ式用の１つまたは複数のソースを指定するのに使うことができる。ｆｒｏｍ句の最も単純な形は、コレクションおよびエイリアスを識別する単一式である。
【０２６４】
【表６１】
2009530735.tif 000063
【０２６５】
概して、ｓｅｌｅｃｔ式は、注文の中のソースコレクションの各要素に対して作用する。これは、反復と呼ばれる。ｓｅｌｅｃｔリストまたはｗｈｅｒｅ句の中の式は、変数が要素を参照するときにコレクションのエイリアスを使って、現在の要素のプロパティを参照することができる。
【０２６６】
５．１．１  Ｆｒｏｍ句項目
各ｆｒｏｍ句項目は、クエリ中のソースコレクションを指す。ｅＳＱＬは、ｆｒｏｍ句項目の以下のクラスをサポートする。
【０２６７】
５．１．１．１  単純なＦｒｏｍ句項目
最も単純なｆｒｏｍ句項目は、コレクションおよびエイリアスを識別する単一式である。
【０２６８】
【表６２】
2009530735.tif 000064
【０２６９】
エイリアス指定は任意選択であり、上記ｆｒｏｍ句項目の代替指定は、以下のようになり得る。
【０２７０】
【表６３】
2009530735.tif 000065
【０２７１】
エイリアスが指定されない場合、ｅＳＱＬは、コレクション式に基づいてエイリアスを生成することを試みる。後で説明する０を参照されたい。
【０２７２】
５．１．１．２  Ｊｏｉｎ  Ｆｒｏｍ句項目
Ｊｏｉｎ  ＦｒｏｍＣｌａｕｓｅＩｔｅｍは、２つのｆｒｏｍ句項目の間のジョインを表す。ｅＳＱＬは、クロスジョイン、内部ジョイン、左および右外部ジョインならびに完全外部ジョインをサポートし、こうしたジョインはすべて、Ｔ−ＳＱＬと同様の様式である。Ｔ−ＳＱＬでのように、ジョインに巻き込まれる２つのｆｒｏｍ句項目は、独立していなければならず、すなわち、相関してはならない。ＣｒｏｓｓＡｐｐｌｙ／ＯｕｔｅｒＡｐｐｌｙは、こうしたケースに対して使うことができる。
【０２７３】
クロスジョイン
ｃｒｏｓｓ  ｊｏｉｎ式は、２つのコレクションのデカルト積を生じる。
【０２７４】
【表６４】
2009530735.tif 000066
【０２７５】
内部ジョイン
ｉｎｎｅｒ  ｊｏｉｎは、２つのコレクションの制限されたデカルト積を生じる。
【０２７６】
【表６５】
2009530735.tif 000067
【０２７７】
この式は、ｏｎ条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。ｏｎ条件は、常に指定されなければならない。
【０２７８】
左外部ジョイン、右外部ジョイン
ｏｕｔｅｒ  ｊｏｉｎ式は、２つのコレクションの制限されたデカルト積を生じる。
【０２７９】
【表６６】
2009530735.tif 000068
【０２８０】
この式は、ｏｎ条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。ｏｎ条件が偽の場合、式は依然として、ヌル値をもつ右手要素に対して対になった左手要素の単一インスタンスを処理する。右外部ジョインは、同様の様式で表現することができる。
【０２８１】
完全外部ジョイン
明示的なｆｕｌｌ  ｏｕｔｅｒ  ｊｏｉｎは、２つのコレクションの制限されたデカルト積を生じる。
【０２８２】
【表６７】
2009530735.tif 000069
【０２８３】
この式は、ｏｎ条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。ｏｎ条件が偽の場合、式は依然として、ヌル値をもつ右手要素に対して対になった、左手要素の１つのインスタンス、およびヌル値をもつ左手要素に対して対になった、右手要素の１つのインスタンスを処理する。
【０２８４】
注：
・Ｓｑｌ−９２、ＴＳｑｌとの互換性を保つために、外部キーワードは任意選択である。したがって、「左ジョイン」、「右ジョイン」、および「完全ジョイン」は、「左外部ジョイン」、「右外部ジョイン」および「完全外部ジョイン」の別名である。  
・ＯＮ句は、内部および外部ジョイン用に使われなければならず、クロスジョインに対しては不正である。
【０２８５】
５．１．１．３  ＡｐｐｌｙＦｒｏｍ句項目
ｅＳＱＬは、２種類のＡｐｐｌｙ、すなわちＣｒｏｓｓＡｐｐｌｙおよびＯｕｔｅｒＡｐｐｌｙをサポートする。ｃｒｏｓｓ  ａｐｐｌｙは、左手コレクションの各要素の、右手式を評価することによって生じられたコレクションの要素との一意のペアリングを生じる。ｃｒｏｓｓ  ａｐｐｌｙにより、右手式は、左手要素の関数となる。
【０２８６】
【表６８】
2009530735.tif 000070
【０２８７】
クロスアプライの振舞いは、ｊｏｉｎリストに関して記述されるのと同様である。右手式が、空のコレクションになる場合、クロスアプライは、左手要素のそのインスタンスに対するペアリングを生じない。
【０２８８】
ｏｕｔｅｒ  ａｐｐｌｙは、右手式が空のコレクションになるときでもペアリングが依然として生じられること以外は、クロスアプライと同様である。
【０２８９】
【表６９】
2009530735.tif 000071
【０２９０】
注：ＴＳｑｌとは異なり、明示的ネスト解除ステップは必要ない。
【０２９１】
５．１．２  Ｆｒｏｍ句における多様なコレクション
ｆｒｏｍ句は、コンマで区切られる複数のコレクション指定を含み得る。このようなケースでは、コレクションは、組み合わされるべきと仮定される。これらを、ｎウェイクロスジョインとして考える。
【０２９２】
５．１．３  左相関
ｆｒｏｍ句の中の項目は、先に指定された項目を参照することができる。以下の例において、ＣおよびＤは独立コレクションであり、ｃ．ＮａｍｅｓはＣに依存する。
【０２９３】
【表７０】
2009530735.tif 000072
【０２９４】
これは、
【０２９５】
【表７１】
2009530735.tif 000073
【０２９６】
と論理的に等価である。
【０２９７】
５．１．４  セマンティクス
論理的に、ｆｒｏｍ句の中のコレクションは、ｎウェイクロスジョインの一部、すなわち、１ウェイクロスジョインである縮退ケースであると仮定される。ｆｒｏｍ句の中のエイリアスは、左から右へ処理され、以降の参照のために現在のスコープに追加される。ｆｒｏｍ句は、ｆｒｏｍ句の中の各項目ごとに１フィールドをもち、そのコレクション項目から単一要素を表すローのマルチセットを生じると仮定される。
【０２９８】
上の例において、ｆｒｏｍ句は論理的に、フィールドｃ、ｄ、ｅがＣ、Ｄ、およびｃ．Ｎａｍｅｓの要素型であると仮定される、Ｒｏｗ（ｃ，ｄ，ｅ）型のローのマルチセットを生じる。ｅＳＱＬは、スコープ内の単純な各ｆｒｏｍ句項目用のエイリアスを導入する。例えば、以下のクエリ
【０２９９】
【表７２】
2009530735.tif 000074
【０３００】
において、スコープ内に導入される名前はｃ、ｄ、ｅである。ＳＱＬとは異なり、ｆｒｏｍ句は、スコープ内にエイリアスを導入するだけである。こうしたコレクションのカラム（プロパティ）に対するどの参照も、エイリアスで修飾されなければならない。
【０３０１】
５．２  ｗｈｅｒｅ句
ｗｈｅｒｅ句は、ＴＳＱＬに関して説明したのと同じセマンティクスを有する。この句は、ソースコレクションの要素を、条件を渡すものに限定することによって、クエリ式によって生じられるオブジェクトを制限する。
【０３０２】
【表７３】
2009530735.tif 000075
【０３０３】
式ｅは、Ｂｏｏｌｅａｎ型をもたなければならない。ｗｈｅｒｅ句は、ｆｒｏｍ句の後、グループ化、順序づけまたは射影の前に直接適用される。ｆｒｏｍ句の中で定義される全要素名は、ｗｈｅｒｅ句の式から見える。
【０３０４】
５．３  ｇｒｏｕｐ  ｂｙ句
ｇｒｏｕｐ−ｂｙ句は、ＴＳＱＬに関して記述したのと同様のセマンティクスを有する。集約を評価する目的で、ソース要素を一緒のグループにするのにその値が使われる１つまたは複数の式を指定することができる。
【０３０５】
【表７４】
2009530735.tif 000076
【０３０６】
ｇｒｏｕｐ  ｂｙ句の中の各式は、等式に匹敵し得る何らかの型に評価されなければならない。こうした型は概して、数字、文字列および日付などのスカラープリミティブである。型が等式の概念を定義する限り、ｇｒｏｕｐ−ｂｙ条件として複合型を使うことが可能である。コレクションによってグループ化することはできない。
【０３０７】
明示的にまたは暗黙的に（クエリ中に句をもつことにより）グループ句が指定されると、現在のスコープは隠され、新しいスコープが導入される。
【０３０８】
ｓｅｌｅｃｔ句、ｈａｖｉｎｇ句およびｏｒｄｅｒ−ｂｙ句は、ｆｒｏｍ句の中で指定される要素名をそれ以上参照することができなくなる。グループ化式自体だけを参照することができる。そうするためには、各グループ化式に新しい名前（エイリアス）を割り当てればよい。グループ化式のエイリアスが指定されない場合、ｅＳＱＬは、０にあるエイリアス生成規則によりエイリアスを生成することを試みる。
【０３０９】
【表７５】
2009530735.tif 000077
【０３１０】
ｇｒｏｕｐ−ｂｙ句の中の式は、同じｇｒｏｕｐ−ｂｙ句の中で先に定義された名前を参照することができない。
【０３１１】
グループ化名に加えて、ｓｅｌｅｃｔ句、ｈａｖｉｎｇ句およびｏｒｄｅｒ−ｂｙ句の中では、集約も指定することができる。集約は、グループの各要素ごとに評価される式を含む。集約演算子は、こうした全式の値を（常にではないが一般に、単一値に）削減する。集約式は、親スコープ内で見える元の要素名への、またはｇｒｏｕｐ−ｂｙ句自体によって導入される新しい名前への参照を行うことができる。集約は、ｓｅｌｅｃｔ句、ｈａｖｉｎｇ句およびｏｒｄｅｒ−ｂｙ句の中に現れるが、実際にはグループ化式と同じスコープの下で評価される。
【０３１２】
【表７６】
2009530735.tif 000078
【０３１３】
このクエリは、ｇｒｏｕｐ−ｂｙ句を使って、製品によって分類される、注文された全製品の価格についての報告を生じる。このクエリは、グループ化式の一部として、製品に名前「ｎａｍｅ」を与え、次いで、ｓｅｌｅｃｔリスト中でその名前を参照する。このクエリはまた、注文明細行の価格および量を内部的に参照するｓｅｌｅｃｔリスト中で集約「ｓｕｍ」を指定する。
【０３１４】
名前付きグループ
グループ自体が、名前をもってよい。グループは、命名されると、グループインスタンスを形成するオブジェクトのコレクションを指す新しい名前をスコープ内に導入する。グループ自体が、グループに関する基準に一致する項目すべてをマルチセットに単に集約する集約、すなわち「ネスト」集約である。論理的に、ｇｒｏｕｐ  ｂｙ句は、キーと、そのグループ用の非キーカラムのコレクションを含む各グループごとの暗黙のネスト集約とに基づいたグループ化を実施する。
【０３１５】
集約、すなわちグループベースの集約への以降の参照は、コレクションベースの集約に翻訳され、ここで問題となるコレクションは、ｇｒｏｕｐ  ｂｙ句によって生じられるネスト集約である。
【０３１６】
【表７７】
2009530735.tif 000079
【０３１７】
この例では、グループｍｙｇｒｏｕｐがｇｒｏｕｐ−ｂｙ句の中で識別され、ｓｅｌｅｃｔリスト中で参照される。名前ｍｙｇｒｏｕｐは、単一グループを形成するＯｒｄｅｒＬｉｎｅインスタンスのコレクションを指す。結果として生じたコレクションの各ローは、３つのプロパティ、すなわちｎａｍｅ、ｔｏｔａｌおよびｍｙｇｒｏｕｐをもつことになる。
【０３１８】
グループ用に自分自身の名前を常に定義する必要はない。名前を指定しなくても、名前ｇｒｏｕｐを使ってグループに常にアクセスすることができる。
【０３１９】
【表７８】
2009530735.tif 000080
【０３２０】
５．４  ｈａｖｉｎｇ句
ｈａｖｉｎｇ句は、グループ化の結果に対する追加のフィルタリング条件を指定するのに使われる。クエリ中でｇｒｏｕｐ−ｂｙ句が指定されない場合、暗黙の「１でのグループ化」、すなわち単一セットグループが仮定される。ｈａｖｉｎｇ句は、ｇｒｏｕｐ−ｂｙ演算の後に適用される以外は、まさにｗｈｅｒｅ句のように作用する。このことは、ｈａｖｉｎｇ句はグループ化エイリアスおよび集約への参照だけを行うことができることを意味する。
【０３２１】
【表７９】
2009530735.tif 000081
【０３２２】
この例は、ｈａｖｉｎｇ句がグループを、その中に複数の製品単位をもつものだけに制限すること以外、ｇｒｏｕｐ−ｂｙの例と同じである。
【０３２３】
５．５  ｓｅｌｅｃｔ句
ｓｅｌｅｃｔキーワードに続く１つまたは複数の式のリストは、ｓｅｌｅｃｔリストまたはより正式には射影として知られる。射影の最も一般的な形は、単一式である。コレクションｃから何らかのメンバｍを選択した場合、ｃの各要素に対するｍ値すべてからなる新しいコレクションを生じることになる。
【０３２４】
【表８０】
2009530735.tif 000082
【０３２５】
例えば、ｃｕｓｔｏｍｅｒｓが、ｓｔｒｉｎｇ型のＮａｍｅプロパティをもつｃｕｓｔｏｍｅｒ型のコレクションである場合、ｃｕｓｔｏｍｅｒｓからＮａｍｅを選択すると、文字列のコレクションを生ずることになる。
【０３２６】
【表８１】
2009530735.tif 000083
【０３２７】
ｒｏｗおよびｖａｌｕｅ  ｓｅｌｅｃｔ句
ｅＳＱＬは、ｓｅｌｅｃｔ句の２つの変形体をサポートする。第１の変形体であるｒｏｗ  ｓｅｌｅｃｔは、ｓｅｌｅｃｔキーワードによって識別され、射影されるべき１つまたは複数の項目を指定するのに使うことができる。暗黙的に、項目の周辺にローラッパーが追加され、その結果、クエリ式の結果が常に、適切なフィールドを有するローのマルチセットとなる。ｒｏｗ  ｓｅｌｅｃｔ中の各式は、エイリアスを指定しなければならない。エイリアスが指定されない場合、ｅＳＱＬは、０に記載したエイリアス作成規則を使ってエイリアスを生成することを試みる。
【０３２８】
ｓｅｌｅｃｔ句のもう１つの変形体であるｖａｌｕｅ  ｓｅｌｅｃｔは、ｓｅｌｅｃｔ  ｖａｌｕｅキーワードによって識別され、ただ１つの項目を指定させ、ローラッパーへの追加は行わない。
【０３２９】
ｒｏｗ  ｓｅｌｅｃｔは、常にｖａｌｕｅ  ｓｅｌｅｃｔによって表現可能である。例えば、以下のようになる。
【０３３０】
【表８２】
2009530735.tif 000084
【０３３１】
ａｌｌおよびｄｉｓｔｉｎｃｔ修飾子
ｓｅｌｅｃｔの両方の変形体は、ａｌｌまたはｄｉｓｔｉｎｃｔ修飾子の指定を可能にする。ｄｉｓｔｉｎｃｔ修飾子が指定されると、クエリ式によって生じられたコレクションから重複が排除される（ｓｅｌｅｃｔ句を含むまで）。ａｌｌ修飾子が指定された場合、重複除去は実施されない。
【０３３２】
こうした修飾子は、ＳＱＬと互換性をもつように保たれるだけである。ｅＳＱＬは、代わりにｄｉｓｔｉｎｃｔ演算子の使用を提案するが、こうした変形体をサポートし、透過的に式を翻訳する。
【０３３３】
【表８３】
2009530735.tif 000085
【０３３４】
セマンティクス
ｓｅｌｅｃｔ句は、ｆｒｏｍ、句、ｇｒｏｕｐ  ｂｙおよびｈａｖｉｎｇ句が評価された後に評価される。ｓｅｌｅｃｔ句は、現時点でスコープ内にある項目だけを（ｆｒｏｍ句により、または外部スコープから）参照することができる。ｇｒｏｕｐ−ｂｙ句が指定されている場合、ｓｅｌｅｃｔ句は、ｇｒｏｕｐ  ｂｙキー用のエイリアスのみを参照することが認められる。ｆｒｏｍ句項目の参照は、集約関数の一部としてのみ許可される。
【０３３５】
５．５．１  ＳＱＬからの逸脱
＊の非サポート
ｅＳＱＬは、ｆｒｏｍ句全体（またはテーブルの全カラム）が射影されるべきであることを示すのに、＊の使用も修飾された＊の使用もサポートしない。こうしたコンストラクトは、スキーマが展開するときに予期されない副作用をもち得るので、ＳＱＬにおいてさえも、適切に設計されたクエリは、こうしたコンストラクトを避ける。ｅＳＱＬは、代わりに、ｆｒｏｍ句からのコレクションエイリアスを参照することによって、クエリに、レコード全体を射影させる。以下のＳＱＬクエリ
【０３３６】
【表８４】
2009530735.tif 000086
【０３３７】
は、ｅＳＱＬでは以下のコンストラクトによってはるかに適切に表現される。
【０３３８】
【表８５】
2009530735.tif 000087
【０３３９】
５．６  ｏｒｄｅｒ  ｂｙ句
ｏｒｄｅｒ−ｂｙ句は、結果中の要素の順序づけを決定する１つまたは複数の式を指定することができる。ｏｒｄｅｒ−ｂｙ句は論理的に、ｓｅｌｅｃｔ句の結果に適用される。この句は、ｓｅｌｅｃｔリスト中の項目を、そのエイリアスにより参照することができる。さらに、この句は、現時点でスコープ内にある他の変数も参照することができる。ただし、ｓｅｌｅｃｔ句がｄｉｓｔｉｎｃｔ修飾子で指定されている場合、ｏｒｄｅｒ−ｂｙ句は、ｓｅｌｅｃｔ句からのみエイリアスを参照することができる。
【０３４０】
【表８６】
2009530735.tif 000088
【０３４１】
ｏｒｄｅｒ−ｂｙ句の中の各式は、順序つき不等式（未満またはより大きい、など）に匹敵し得る何らかの型にならなければならず、こうした型は概して、数字、文字列および日付などのスカラープリミティブである。
【０３４２】
ｏｒｄｅｒ−ｂｙ句の中の各式は、任意選択で、基準のソートを指定することができる。特定の式に対して昇順ソート（または降順ソート）が必要とされることを示すために、ＡＳＣ（またはＤＥＳＣ）を指定することができる。さらに、文字列型の式の場合、順序づけ用に使われるべき文字列照合を示すために、ＣＯＬＬＡＴＥ句を指定することができる。
【０３４３】
位置に関する指定、例えば、ｏｒｄｅｒ  ｂｙ  ３は、ｓｅｌｅｃｔリスト上の対応する（第３の）項目がサポートされないことを示すのに使うことができる。
【０３４４】
６  言語詳細：コマンド
６．１  コマンド
ｅＳＱＬコマンドとは、クエリリクエスト全体に対して使われる用語である。コマンドは、ｓｅｌｅｃｔ式や、オブジェクトを挿入し、消去し、またはアップデートするのに使われるステートメントなどのクエリ式でよい。コマンドは、論理的に、３つの部分からなる。  
・任意選択のプロローグ
・任意選択のＷＩＴＨ句
・クエリまたはＤＭＬステートメント
例えば、Ｃｕｓｔｏｍｅｒと呼ばれる型およびｃｕｓｔｏｍｅｒｓと命名されたＣｕｓｔｏｍｅｒインスタンスのコレクションがあると仮定する。以下はすべて、有効なコマンドである。
【０３４５】
【表８７】
2009530735.tif 000089
【０３４６】
６．１．１  コマンドプロローグ
（任意選択の）コマンドプロローグは、使用するべき名前空間のセットを指定することができる。これらについては、後で、名前空間に関するセクションにおいて説明する。
【０３４７】
６．１．２  ＷＩＴＨ句
ｅＳＱＬは、ＷＩＴＨ句を、どのクエリ（またはＤＭＬステートメント）への接頭部としてもサポートする。ＷＩＴＨ句の構文は、以下のようになる。
【０３４８】
【表８８】
2009530735.tif 000090
【０３４９】
注
・＜ｃｏｍｍｏｎ−ｔａｂｌｅ−ｅｘｐｒ＞定義は、ＷＩＴＨ句の中で先に定義されたｃｏｍｍｏｎ−ｔａｂｌｅ−ｅｘｐｒｅｓｓｉｏｎｓを参照することができる。例えば、以下の定義が正当である。
【０３５０】
【表８９】
2009530735.tif 000091
【０３５１】
６．２  クエリステートメント
クエリステートメントは単に式である。
【０３５２】
６．３  ＤＭＬステートメント
ＤＭＬステートメントについては、次のセクションで説明する。
【０３５３】
７  ＤＭＬ
ｅＳＱＬは、ｉｎｓｅｒｔ、ｕｐｄａｔｅおよびｄｅｌｅｔｅというＤＭＬステートメントをサポートする。
【０３５４】
７．１．１  Ｉｎｓｅｒｔ
ｅＳＱＬにおけるＩＮＳＥＲＴコマンドは、標準ＳＱＬにおけるＩＮＳＥＲＴステートメントと全く同様である。
【０３５５】
【表９０】
2009530735.tif 000092
【０３５６】
セマンティクス
・＜ｃｏｎｔａｉｎｅｒ＞は、データのどのコンテナも表す。ＥｎｔｉｔｙＳｅｔｓは、最も論理的なコンテナである。
・＜ｅｘｐｒ＞／＜ｑｕｅｒｙ＿ｅｘｐｒ＞は、コンテナに挿入するべき値のセットを生じる（最初の２つのケースにおける）マルチセットである。第３のケース（ＶＡＬＵＥＳ句）において、＜ｅｘｐｒ＞は、コンテナの要素型である。
・Ｗｉｔｈ句は、後続セクションにおいて定義される。
・Ｗｉｔｈ−ｐａｒｅｎｔ句は、後続セクションにおいて記述される。
【０３５７】
例
【０３５８】
【表９１】
2009530735.tif 000093
【０３５９】
注
・ｅＳＱＬのＩＮＳＥＲＴ．．ＶＡＬＵＥＳステートメントは、Ｔ−ＳＱＬとはわずかに異なる。１つには、値の周りの括弧は任意選択であり、存在する場合、ローコンストラクタとは解釈されない。
・Ｔ−ＳＱＬとは異なり、ｅＳＱＬは、Ｉｎｓｅｒｔステートメント用にカラムリストを指定させない。
【０３６０】
７．１．２  Ｄｅｌｅｔｅ
ｅＳＱＬにおけるＤＥＬＥＴＥコマンドは、標準ＳＱＬにおけるＤＥＬＥＴＥステートメントと同様である。
【０３６１】
【表９２】
2009530735.tif 000094
【０３６２】
セマンティクス
・＜ｃｏｎｔａｉｎｅｒ＞は、データのどのコンテナも表す。ＥｎｔｉｔｙＳｅｔｓは、最も論理的なコンテナである。
・＜ｅｘｐｒ＞は、（すなわち）ブール値型の述部である。
・＜ｗｉｔｈ−ｐａｒｅｎｔ−ｃｌａｕｓｅ＞は後で定義される。
【０３６３】
例
【０３６４】
【表９３】
2009530735.tif 000095
【０３６５】
注
・Ｔ−ＳＱＬとは異なり、ｅＳＱＬにおけるＤＥＬＥＴＥステートメントは、多様なｆｒｏｍ句を認めない。代わりにサブクエリを使用する。
【０３６６】
７．１．３  Ｕｐｄａｔｅ
ｅＳＱＬにおけるｕｐｄａｔｅステートメントは概念上、標準ＳＱＬにおけるｕｐｄａｔｅステートメントと同様である。
【０３６７】
【表９４】
2009530735.tif 000096
【０３６８】
セマンティクス
・＜ｃｏｎｔａｉｎｅｒ＞は、データのどのコンテナも表す。ＥｎｔｉｔｙＳｅｔｓは、最も論理的なコンテナである。
・＜ｅｘｐｒ＞は、（すなわち）ブール値型の述部である。
・＜ｆｉｅｌｄ−ｅｘｐｒ＞は、ｌ値の式であり、（すなわち）カラム参照、カラムのプロパティへの参照、またはこのようなプロパティを伴うＴＲＥＡＴ式でよい。
・＜ｗｉｔｈ−ｐａｒｅｎｔ−ｃｌａｕｓｅ＞は後で定義される。
【０３６９】
例
【０３７０】
【表９５】
2009530735.tif 000097
【０３７１】
注
・Ｔ−ＳＱＬとは異なり、ｅＳＱＬにおけるＵＰＤＡＴＥステートメントは、多様なｆｒｏｍ句を認めない。代わりにサブクエリを使用する。
・属性は、ＵＰＤＡＴＥステートメント中で多くとも一度だけ変更してよい。
【０３７２】
７．２  ＥＤＭ関係のためのＤＭＬ
ＥＤＭは、関係インスタンスのコレクションとして、ＲｅｌａｔｉｏｎｓｈｉｐＳｅｔの概念を導入する。「関連づけ」および「構成」関係は両方とも、こうしたＲｅｌａｔｉｏｎｓｈｉｐＳｅｔを介してモデル化される。
【０３７３】
７．２．１  関連づけ
一般的な使用形態では、最初にエンティティのインスタンスを作成し、次いで、ＲｅｌａｔｉｏｎｓｈｉｐＳｅｔに挿入することによって、エンティティの間に関係を作成する。以下の例では、実際にＤＭＬをこのようなｒｅｌａｔｉｏｎｓｈｉｐｓｅｔに入れる。２つのエンティティ型ＯｒｄｅｒおよびＣｕｓｔｏｍｅｒ（ＯｒｄｅｒｓおよびＣｕｓｔｏｍｅｒｓというＥｎｔｉｔｙＳｅｔを有する）を仮定する。さらに、こうした２つのエンティティの間にＯｒｄｅｒＣｕｓｔｏｍｅｒ関係を、およびｒｅｌａｔｉｏｎｓｈｉｐｓｅｔとしてＯｒｄｅｒＣｕｓｔｏｍｅｒＳｅｔを仮定する。
【０３７４】
【表９６】
2009530735.tif 000098
【０３７５】
７．２．２  構成
構成に対応するＲｅｌａｔｉｏｎｓｈｉｐＳｅｔは、同様にアップデート可能である。最初に、親エンティティインスタンスを作成しなければならない。ただし、関連づけとは異なり、子インスタンスを作成する別個のステップはない。「構成」ＲｅｌａｔｉｏｎｓｈｉｐＳｅｔへの挿入を行うと、自動的に子インスタンスを作成することになる。この例は、以下を含む。
【０３７６】
【表９７】
2009530735.tif 000099
【０３７７】
注：特別な「ｗｉｔｈ  ｐａｒｅｎｔ  ａｓ」句が、構成を修正する。
【０３７８】
８  ｅＳＱＬ雑則
８．１  再帰クエリ
ｅＳＱＬは、テーブル定義（ｐａｒａｎｔｈｅｓｉｚｅｄＥｘｐｒ）にそれ自体を参照させることによって、再帰クエリのサポートを可能にする。例えば、以下のようになる。
【０３７９】
【表９８】
2009530735.tif 000100
【０３８０】
ｅＳＱＬは、再帰の終了については保証しない。
【０３８１】
８．２  ＥＤＭ関係のサポート
ＥＤＭは、ＳＱＬにおけるリンクテーブルと論理的に同等であるＲｅｌａｔｉｏｎｓｈｉｐＳｅｔの概念を導入する。他のコレクションと全く同じように、ＲｅｌａｔｉｏｎｓｈｉｐＳｅｔを照会することができる。さらに、ｅＳＱＬは、関係を介したより簡単なナビゲーションのためのナビゲーションヘルパをサポートする。ナビゲーションヘルパの一般的な形は、以下のようになる。
【０３８２】
【表９９】
2009530735.tif 000101
【０３８３】
上記において、ＯｒｄｅｒＣｕｓｔｏｍｅｒは、関係の名前であり、Ｃｕｓｔｏｍｅｒは、関係の顧客側の名前である。
【０３８４】
８．３  コメント
ｅＳＱＬは、Ｔ−ＳＱＬスタイルのコメントをサポートする。ｅＳＱＬのコメントは、以下の形でよい。
【０３８５】
【表１００】
2009530735.tif 000102
【０３８６】
コメントは、空白キャラクタが予想されるどの場所でも使うことができる。
・「--」（ダブルハイフン）スタイルのコメントキャラクタは、実行されるべきコードと同じローでも、独立したローでも使うことができる。ダブルハイフンからローの末尾までのものはすべて、コメントの一部である。
・/*．．．*/（フォワードスラッシュアスタリスクキャラクタペア）。こうしたコメントキャラクタは、実行されるべきコードと同じロー、独立したロー、または実行可能コードの中でも使うことができる。開きコメントペア（/*）から閉じコメントペア（*/）までのものはすべて、コメントの一部と見なされる。こうしたコメントは、複数ローに渡る。
【０３８７】
９  ｅＳＱＬの名前解決および他の規則
９．１  識別子
ｅＳＱＬにおける識別子は、式エイリアス、変数参照、オブジェクトのプロパティ、関数などを表すのに使われる。ｅＳＱＬにおける識別子には、２種類ある。
【０３８８】
９．１．１  単純な識別子
単純な識別子とは、単なる一連の英数字（およびｕｎｄｅｒＲａｎｋ）キャラクタである。
【０３８９】
この識別子の第１キャラクタは、アルファベット、すなわちａ〜ｚまたはＡ〜Ｚでなければならない。
【０３９０】
９．１．２  引用識別子
引用識別子は、角括弧、または二重引用符で囲まれた一連の任意のキャラクタである。デフォルトの引用は、角括弧である。二重引用符は、ｅＳＱＬ用パーサが認める場合のみ、引用キャラクタとして使うことができる。これを制御するための正確なパーサオプションは、パーサの裁量に委ねられる。二重引用符は、引用キャラクタとして使うことができるとき、文字列リテラル用に使うことはできないことにも留意されたい。したがって、文字列リテラルは常に、単一引用符を使う必要がある。
【０３９１】
引用識別子は、普通は識別子において正当でないはずのキャラクタで識別子を指定することを可能にする。角括弧（または引用）の間の全キャラクタは、すべての空白も含めて、識別子と一部と見なされる。引用識別子は、以下のキャラクタを含んではならない。
・改行
・キャリッジリターン
・タブ
・バックスペース
・［  （［］スタイルの引用のケースにおいてのみ）
それ以外の場合は、普通は不正キャラクタをもつプロパティ名を考案することができよう。
【０３９２】
【表１０１】
2009530735.tif 000103
【０３９３】
普通はその言語の予約単語と見なされることになる識別子を指定するのに、引用識別子を使ってよい。例えば、Ｅｍａｉｌ型が「ｆｒｏｍ」と命名されたプロパティをもつ場合、角括弧を使って、予約単語「ｆｒｏｍ」とは区別することができよう。
【０３９４】
【表１０２】
2009530735.tif 000104
【０３９５】
引用識別子は、ｄｏｔ演算子の右側で使ってよい。
【０３９６】
【表１０３】
2009530735.tif 000105
【０３９７】
識別子の中に閉じ引用キャラクタと同じｃｈａｒを使うためには、それを２回使う。例えば、以下のようになる。
【０３９８】
【表１０４】
2009530735.tif 000106
【０３９９】
識別子ａｂｃ］は、適切に回避される。
【０４００】
９．２  大文字／小文字の区別
ｅＳＱＬにおける全キーワードは、大文字／小文字を区別しない（ＳＱＬと同様）。識別子は、指定されるパーサオプションに応じて、大文字／小文字を区別しても、大文字／小文字を区別しなくてもよい。ｅＳＱＬにおけるキーワードは、常に大文字／小文字を区別しない。
【０４０１】
９．３  エイリアス作成規則
ｅＳＱＬは、必要とされるときは常に、クエリ中でエイリアスが指定されることを推奨する。エイリアスは、以下のコンストラクト用に必要とされる。
・ｒｏｗコンストラクタのフィールド
・クエリ式のｆｒｏｍ句の中の項目
・クエリ式のｓｅｌｅｃｔ句の中の項目
・クエリ式のｇｒｏｕｐ  ｂｙ句の中の項目
・ｊｏｉｎ式への引数
有効なエイリアス
どの単純識別子も引用識別子も、有効なエイリアスである。
【０４０２】
エイリアス生成
エイリアスが指定されない場合、ｅＳＱＬは、いくつかの単純な規則に基づいてエイリアスを生成することを試みる。
・（エイリアスが指定されていない）式が、単純または引用識別子である場合、その識別子がエイリアスとして使われる。例えば、以下のようになる。
【０４０３】
【表１０５】
2009530735.tif 000107
【０４０４】
・式がより複雑な式であるが、その式の最後のコンポーネントが単純識別子である場合、その識別子がエイリアスとして使われる。例えば、以下のようになる。
【０４０５】
【表１０６】
2009530735.tif 000108
【０４０６】
・それ以外の場合、コンパイル時の例外が起こされる。
【０４０７】
９．４  スコープ規則
スコープ規則は、照会言語において特定の変数が見えるときを定義する。一部の式またはステートメントは、新しい名前を導入する。スコープ規則は、そうした名前をどこで使うことができるか、もう一方と同じ名前をもつ新しい宣言が、およびいつまたはどこでその先行物を隠すことができるか決定する。
【０４０８】
名前は、定義されるとき、スコープ内で定義されると言われる。スコープは、クエリの領域をカバーする。特定のスコープ内のすべての式または名前参照は、そのスコープ内部で定義された名前を見ることができる。スコープが始まる前と終わった後は、スコープ内部で定義された名前を参照することはできない。
【０４０９】
スコープはネストすることができる。言語の部分は、やはりスコープを導入する他の言語の式を含み得る領域をカバーする新しいスコープを導入する。スコープがネストされると、参照がその内部にある最も内側のスコープ内部で定義された名前ならびに任意の外部スコープ内で定義された任意の名前への参照を行うことができる。同じスコープ内部で定義されたどの２つのスコープも、兄弟スコープと見なされる。兄弟スコープ内部で定義された名前への参照を行うことはできない。
【０４１０】
外部スコープ内で宣言された名前と一致する名前が内部スコープ内部で宣言された場合、そのスコープ内部またはそのスコープ内部で宣言されたスコープ内部での参照は、新たに宣言された名前のみを指す。外部スコープ内の名前は隠される。同じスコープ内部でも、定義される前に名前を参照することはできない。
【０４１１】
グローバル名は、実行環境の一部として存在し得る。この名前は、一貫したコレクションまたは環境変数の名前を含み得る。こうした名前を含むスコープは、最も外側のスコープである。パラメータは、スコープ内にない。パラメータへの参照は特別な構文を含むので、パラメータの名前は、クエリ中の他の名前と衝突しない。
【０４１２】
９．４．１  クエリ式
クエリ式は、新しいスコープを導入する。ｆｒｏｍ句の中で定義される名前が、出現順に、左から右へ、ｆｒｏｍスコープに導入される。ｊｏｉｎリスト中で、式は、リスト中で先に定義された名前を参照することができる。ｆｒｏｍ句の中で識別される要素のパブリックプロパティ（フィールドなど）は、ｆｒｏｍスコープに追加されない。すなわち、こうしたプロパティは、エイリアスで修飾名を介して常に参照されなければならない。普通は、ｓｅｌｅｃｔ式の全部分が、ｆｒｏｍスコープ内部と見なされる。
【０４１３】
ｇｒｏｕｐ−ｂｙ句も、新しい兄弟スコープを導入する。各グループは、グループ中の要素のコレクションを指すグループ名を有し得る。各グループ化式も、グループスコープに新しい名前を導入することになる。さらに、ネスト集約（または名前付きグループ）も、スコープに追加される。グループ化式自体は、ｆｒｏｍスコープ内部にある。ただし、ｇｒｏｕｐ−ｂｙ句が使われると、ｓｅｌｅｃｔリスト（射影）、ｈａｖｉｎｇ句およびｏｒｄｅｒ−ｂｙ句は、ｆｒｏｍスコープではなくグループスコープ内部であると見なされる。集約は、特別な取扱いを受け、それについては以下で説明する。
【０４１４】
ｓｅｌｅｃｔリストは、スコープに新しい名前を順序通りに導入することができる。右側の射影式は、左に射影される名前を参照することができる。ｏｒｄｅｒｂｙ句は、ｓｅｌｅｃｔリスト中で指定された名前（エイリアス）を参照することができる。ｓｅｌｅｃｔ式内部での句の評価順が、名前がスコープに導入される順序を決定する。ｆｒｏｍ句が最初に評価され、その後にｗｈｅｒｅ句、ｇｒｏｕｐｉｎｇ句、ｈａｖｉｎｇ句、ｓｅｌｅｃｔ句および最終的にｏｒｄｅｒ−ｂｙ句が続く。
【０４１５】
集約の扱い
ｅＳＱＬは、２つの形の集約、すなわちコレクションベースの集約およびグループベースの集約をサポートする。コレクションベースの集約は、ｅＳＱＬにおいて好ましいコンストラクトであり、グループベースの集約は、単にＳＱＬ互換性のためにサポートされる。
【０４１６】
集約を解決するとき、ｅＳＱＬは最初に、集約をコレクションベースの集約として取り扱うことを試みる。これが失敗した場合、ｅＳＱＬは、基準であるべき集約入力をネスト集約に変換し、この新しい式の解決を試みる。例えば、以下のようになる。
【０４１７】
【表１０７】
2009530735.tif 000109
【０４１８】
９．４．２  Ｃｏｌｌｅｃｔｉｏｎフィルタ／プロジェクト演算
コレクションフィルタ／プロジェクト演算子（．．、．．．、．？および．．？）用に、射影／述部用の新しいスコープが作成され、コレクションの各要素を表すために、名前ｉｔがスコープに暗黙的に追加される。さらに、簡単にするために、コレクション要素のパブリックメンバもスコープに追加されるが、これもやはり射影／述部の評価を持続するためである。例えば、
【０４１９】
【表１０８】
2009530735.tif 000110
【０４２０】
は、部署名のマルチセットを生じ、各Ｄｅｐａｒｔｍｅｎｔは、Ｎａｍｅプロパティをもつと仮定される。
【０４２１】
９．５  名前空間
ｅＳＱＬは、例えば型名、エンティティセット、関数など、グローバル識別子に関する名前衝突の問題に対処するために、名前空間を導入する。ｅＳＱＬにおける名前空間サポートは、ＣＬＲモデルと全く同様である。ｅＳＱＬは、コマンドプロローグにおいて使うことができるｕｓｉｎｇ句を提供する。２つの形のｕｓｉｎｇ句、すなわち修飾名空間（ここで、名前空間用には、比較的短いエイリアスが提供される）、および非修飾名前空間が提供される。
【０４２２】
【表１０９】
2009530735.tif 000111
【０４２３】
名前解決規則
ローカルスコープ内で識別子を解決することができない場合、ｅＳＱＬは、グローバルスコープ（すなわち）名前空間内での名前の位置決めを試みる。ｅＳＱＬは最初に、識別子（接頭部）を修飾名空間の１つと一致させることを試みる。一致がある場合、ｅＳＱＬは、指定された名前空間内での、識別子の残りの解決を試みる。一致が見つからない場合、例外が起こされる。
【０４２４】
【表１１０】
2009530735.tif 000112
【０４２５】
ｅＳＱＬは次いで、識別子用の、（プロローグ内で指定された）すべての非修飾名前空間を調べることを試みる。識別子をちょうど１つの名前空間内に配置することができる場合、その場所が戻される。複数の名前空間がその識別子に関して一致する場合、例外が起こされる。識別子用に名前空間を識別することができない場合、ｅＳＱＬは、次の外側のスコープ（Ｃｏｍｍａｎｄ／Ｃｏｎｎｅｃｔｉｏｎオブジェクト）に名前を渡す。
【０４２６】
【表１１１】
2009530735.tif 000113
【０４２７】
ＣＬＲモデルとの違い
ＣＬＲモデルとの１つの違いについては、付記しておく価値がある。ＣＬＲでは、部分修飾名空間を使うことができるが、ｅＳＱＬではこれを認めていない。例えば、Ｃ＃では、以下は正当であるが、その相当物はｅＳＱＬにおいて正当ではない。
【０４２８】
【表１１２】
2009530735.tif 000114
【０４２９】
ＡＤＯ．ＮＥＴの使用
クエリ／ＤＭＬステートメントは、ＡＤＯ．ＮＥＴ  Ｃｏｍｍａｎｄを介して表現される。Ｃｏｍｍａｎｄは、Ｃｏｎｎｅｃｔｉｏｎオブジェクトに渡って構築することができる。Ｎａｍｅｓｐａｃｅは、同様にＣｏｍｍａｎｄおよびＣｏｎｎｅｃｔｉｏｎオブジェクトの一部として指定することができる。ｅＳＱＬがクエリ自体内部の識別子を解決することができない場合、外部の名前空間が調べられる（同様の規則により）。クエリ、ＣｏｍｍａｎｄおよびＣｏｎｎｅｃｔｉｏｎオブジェクトは、名前空間のリングを形成し、ここで各リングが最初に調べられる。
【０４３０】
９．６  ヌルリテラルおよび型の推論
上で説明したように、ヌルリテラルは、ｅＳＱＬ型システムにおけるどの型とも互換性がある。ただし、正しく推論されるべきヌルリテラルの型に対しては、ｅＳＱＬは、ヌルリテラルを使うことができる特定の制約を課す。以下の規則が該当する。
【０４３１】
型づけされたヌル
型づけされたヌル（すなわち）「ｃａｓｔ（ｎｕｌｌ  ａｓ  Ｉｎｔ１６）」を、どこでも使ってよい。この時点で型は知られているので、型の推論はそれ以上必要ない。
【０４３２】
浮動ヌルリテラル
浮動ヌルリテラルは、以下のコンテキストにおいて使うことができる。
・ｃａｓｔ／ｔｒｅａｔ式への引数として。これは、型づけされたヌル式を生じられるために、推奨される機構である。
・メソッドまたは関数への引数。（標準多重定義規則が該当する。多重定義を１つ選ぶことができない場合、コンパイルエラーが起こされる）
・＋、−、，／などの算術式への引数の１つとして。他の引数（群）はヌルリテラルになることができない。そうでないと、型の推論は可能ではない。
・論理式（ａｎｄ／ｏｒ／ｎｏｔ）への引数の１つとして。引数はすべて、ｂｏｏｌｅａｎ型であることが知られている。
・「ｉｓ  ｎｕｌｌ」または「ｉｓ  ｎｏｔ  ｎｕｌｌ」式への引数として。式「ｎｕｌｌ  ｉｓ  ｎｕｌｌ」および「ｎｕｌｌ  ｉｓ  ｎｏｔ  ｎｕｌｌ」は正当である（ただし、愚かである）／
・ｌｉｋｅ式への引数の１つまたは複数として。引数はすべて、文字列であると予想される。
・名前付き型コンストラクタへの引数の１つまたは複数として。
・マルチセットコンストラクタへの引数の１つまたは複数として。ただし、マルチセットコンストラクタへの少なくとも１つの引数は、ヌルリテラル以外の式でなければならない。
・ｃａｓｅ式におけるｔｈｅｎ／ｅｌｓｅ式の１つまたは複数として。ｃａｓｅ式中のｔｈｅｎ／ｅｌｓｅ式の少なくとも１つは、ヌルリテラル以外の式でなければならない。
【０４３３】
浮動ヌルリテラルは、他のシナリオでは使うことができない。こうしたシナリオの一部（網羅的ではなく、例示のためにのみ含まれる）は、以下を含む。
・ローコンストラクタへの引数。
【０４３４】
注
ｉｓ  ｎｕｌｌおよびｉｓ  ｎｏｔ  ｎｕｌｌ式は、特殊であると見なされる。
【０４３５】
１０  ｅＳＱＬの型システム
ｅＳＱＬは、エンティティデータモデル（ＥＤＭ）のインスタンスに対して作用し、インスタンスを生じる。この文書では、ＥＤＭの詳細には踏み込まない。代わりに、いくつかの特別な興味項目について付記しておく。
【０４３６】
１０．１  ロー型
ロー（別名、タプル）は、メンバシップによって構造的である。ローのコンストラクトは、それを構成する一連の型づけされた、名前付きメンバに依存する。ローとは、ＥＤＭのＩｎｌｉｎｅＴｙｐｅであり、識別をもたず、そこからの継承を行うことができない。
【０４３７】
メンバがそれぞれ等価である場合、同じロー型のインスタンスは、等価である。ローは、その構造的等価物を超える振舞いをもたない。
【０４３８】
ローは、共通言語ランタイムにおける等価物をもたない。クエリは、ローまたはローのコレクションを含むコンストラクトを結果として生じ得る。
【０４３９】
ｅＳＱＬクエリとホスト言語の間のＡＰＩ束縛は、クエリの結果においてローがどのように実現されるかを定義することになる。ＡＤＯ．ＮＥＴでは、ローがＤａｔａＲｅｃｏｒｄとして表出されることになる。
【０４４０】
１０．２  コレクション
Ｃｏｌｌｅｃｔｉｏｎ型は、他のオブジェクトのゼロ以上のインスタンスを表す。ＥＤＭは、マルチセット、リストなどを含むいくつかの種類のコレクションをサポートする。この文書は、マルチセットのみを扱う。
【０４４１】
１０．３  ヌル可能性
ＥＤＭでは、ヌル可能性は、プロパティに対する制約であり、Ｔｙｐｅ自体のファセットではない。ＥＤＭにおけるすべての型は、ヌルになる可能性がある。ｅＳＱＬにおけるｎｕｌｌリテラルは、ＥＤＭにおける他のすべての型と互換性があると見なされる。
【０４４２】
１０．３．１  ヌルのセマンティクス
ｅＳＱＬにおけるヌルは、ＴＳｑｌにおけるＮｕｌｌとほとんど同様に振る舞う。具体的には、ヌルに対して作用するほとんどの式は、ヌルを戻す。こうした式は、以下を含む。
・算術式
・論理式
・型式
【０４４３】
以下の式は、その引数の１つまたは複数がヌルであるとき、ヌルを戻すことができない。
・コンストラクタ（型、ロー、マルチセット）
・関数／メソッド
・ｉｓ  ｎｕｌｌおよびｉｓ  ｎｏｔ  ｎｕｌｌ演算子
・その他
【０４４４】
１０．４  暗黙の型昇格
ｅＳＱＬは、整数、浮動小数点および文字列などの基本要素データ型に対する加算、乗算および否定など、様々な共通バイナリおよび単項演算子を定義する。普通は、加算などのバイナリ演算子は、同じデータ型の２つのインスタンスに作用する。ただし、演算子が異なる型の２つのインスタンスに対して作用することをリクエストすることも、時には正当である。例えば、加算と整数および浮動小数点である。
【０４４５】
これを円滑に行うためには、２つのオペランドの一方が、他方の型に昇格されなければならない。概して、これは、最高の精度をもつ型であるので、コンバート中にデータの損失がない。いくつかの状況では、確実にデータ損失がないようにするために、両方のオペランドが第３の型に昇格される。
【０４４６】
以下のテーブルは、言語に組み込まれる暗黙の型昇格を列挙する。第１列は、ベース型を列挙し、第２列は、型に対して行うことができる最も直近の昇格を列挙する。例えば、Ｉｎｔ１６は、Ｉｎｔ３２に昇格することができる。ただし、Ｉｎｔ３２はＩｎｔ６４に昇格することができるので、Ｉｎｔ３２はＩｎｔ６４にも昇格することができる。
【０４４７】
【表１１３】
2009530735.tif 000115
【０４４８】
列挙されていない、または「なし」という昇格をもつものとして列挙されている型は、暗黙的に昇格することができない。
【０４４９】
浮動小数点へのＩｎｔ１６の加算を試みる際に正しい型昇格を知りたい場合は、Ｉｎｔ１６が本当に浮動小数点に昇格するのかどうかを調べるために、テーブルを見ればよいが、浮動小数点はＩｎｔ１６には昇格しない。したがって、Ｉｎｔ１６は、浮動小数点に昇格されるので、２つの浮動小数点は、合算することができる。
【０４５０】
もう少し複雑な例では、Ｉｎｔ３２が浮動小数点に加算される。Ｉｎｔ３２は浮動小数点に昇格せず、浮動小数点はＩｎｔ３２に昇格しないことに留意されたい。ただし、Ｉｎｔ３２および浮動小数点は両方とも、ダブル型に昇格する。したがって、両方のオペランドがダブル型に昇格され、２つのダブル型は合算される。
【０４５１】
１０．５  正当な型コンバート
以下は、基本要素データ型の間の正当なコンバートのテーブルである。
【０４５２】
【表１１４】
2009530735.tif 000116
【０４５３】
１１  ホスト言語の束縛
ホスト言語の束縛は、ｅＳＱＬと対話するためのＡＰＩである。ｅＳＱＬは、マイクロソフトのデータアクセスＡＰＩを使って現在のＴＳＱＬがプログラマによってアクセスされるのとほとんど同じやり方で、ホストプログラミング言語からＡＰＩを介してアクセスされる照会言語として設計されている。概念的に、照会されているデータは、ホスト言語のドメイン外部のどこか、一般の言語演算子には見えないデータベースまたは他の一貫したストア、あるいはデータ構造内に存在する。
【０４５４】
ｅＳＱＬ用の好ましいデータアクセス機構は、ＡＤＯ．ＮＥＴである。ＡＤＯ．ＮＥＴにおけるコマンドオブジェクトは、ＣｏｍｍａｎｄＴｅｘｔプロパティ（ｅＳＱＬクエリ文字列にセットすることができる）をもつ。コマンドオブジェクトに対するＥｘｅｃｕｔｅメソッドは、ＤａｔａＲｅａｄｅｒ（ＩＥｎｕｍｅｒａｔｏｒインターフェイスをサポートする）を戻す。ＤａｔａＲｅａｄｅｒは論理的に、ＤａｔａＲｅｃｏｒｄのコレクションであり、ここでＤａｔａＲｅｃｏｒｄは、結果の単一要素を表す。
【０４５５】
１２  文法
１２．１  コマンド
【０４５６】
【表１１５】
2009530735.tif 000117
【０４５７】
１２．２  ＤＭＬ
【０４５８】
【表１１６】
2009530735.tif 000118
【０４５９】
１２．３  クエリ式
【０４６０】
【表１１７】
2009530735.tif 000119
【０４６１】
【表１１８】
2009530735.tif 000120
【０４６２】
【表１１９】
2009530735.tif 000121
【０４６３】
【表１２０】
2009530735.tif 000122
【０４６４】
【表１２１】
2009530735.tif 000123
【０４６５】
付表Ｂ：例示的な照会言語に対する拡張のための詳細な仕様
１  概観
１．１  目的
この文書は、ＷｉｎＦＳ／ＣＤＰのためのｅＳＱＬ照会言語に対する拡張（関数）について詳述する。
【０４６６】
ｅＳＱＬは、関数呼出しのサポートを提供するが、それ自体に対するいかなる組込み関数も提供しない。（＋、−などの演算子は、異なるように扱われ、言語自体に焼かれるものと仮定される）。Ｔ−ＳＱＬおよびＳＱＬの他のダイアレクトのような言語のユーザは、豊富な１組の組込み関数に慣れている。この文書の目的は、こうした要件に対処するように、ｅＳＱＬをどのように拡張することができるかを記述することである。
【０４６７】
根本的に、ｅＳＱＬにおける全関数は同じように取り扱われる。すなわち、ユーザ定義関数として、ｅＳＱＬは、型を含む名前空間の使用と同様の様式で関数の異なるコンテナを定義するのに、名前空間を使う。プロバイダは、関連づけられた関数の組を有するこのような名前空間を定義し、それらをｅＳＱＬのユーザへのメタデータサービスを介して使用可能にすることができる。この文書では、ＳＱＬサーバおよびＷｉｎＦＳから使用可能な特定の組込み関数の組と、それらを使用可能にするための名前空間とに焦点を当てる。
【０４６８】
この文書では、この関数リストをプロバイダがどのようにして供給するか、およびこれらがシステムの残りによってどのようにして搭載されるかという問題には対処しない。
【０４６９】
こうした拡張は、それらをサポートするストレージプロバイダによってグループ化される。プロバイダのリストは以下のようになる。
【０４７０】
１．ＳＱＬサーバ２０００
２．ＳＱＬサーバ２００５：このプロバイダは、ＳＱＬ２０００の関数をすべてサポートする。
３．ＷｉｎＦＳ：このプロバイダは、ＳＱＬ２００５およびＳＱＬ２０００の関数をすべてサポートする。
【０４７１】
以下のテーブルは、機能について要約している。
【０４７２】
【表１２２】
2009530735.tif 000124
【０４７３】
上のテーブルにおいて部分サポートと列挙されているケースに関しては、文書の以降のセクションを参照されたい。
【０４７４】
１．２  拡張機構
拡張機能を可能にする、ｅＳＱＬ拡張機構についての詳細は、ｅＳＱＬ言語仕様のセクション９．４（名前空間）に見ることができる。部分的名前空間はサポートされないことに留意されたい。より詳しくは、ｅＳＱＬ言語仕様を参照されたい。
【０４７５】
名前空間は、ｅＳＱＬのｕｓｉｎｇ句を使ってクエリにインポートすることができる。あるいは、１つまたは複数の名前空間を、例えば、Ｃｏｍｍａｎｄ／Ｃｏｎｎｅｃｔｉｏｎオブジェクトの一部として、クエリの制約外部で指定することができる。
【０４７６】
１．３  拡張の実行
クエリの実行（拡張関数を含む）は、常にストアで起こる。さらに、別段の記載がない限り、拡張関数のセマンティクスは、サーバと同じであると予想される。ｅＳＱＬパーサは、関数呼出しの署名を検証するが、どの意味認証も基底ストアで実施される。
【０４７７】
２  詳細な設計
２．１  集約
集約関数は、値のマルチセットに対する算出を実施し、単一値を戻す。ＣＯＵＮＴという例外はあるが、集約関数は、ヌル値を無視する。以下の使用可能なＳＱＬ関数がサポートされる。
【０４７８】
【表１２３】
2009530735.tif 000125
【０４７９】
集約関数は、値を計算するとき、ヌル値を無視する（ｃｏｕｎｔは除く）。ｃｏｕｎｔ（＊）はサポートされないことにも留意されたい。集約関数は、述部および射影定義中で使うことができる。さらに、集約は、等式をサポートするデータ型に対する「ｄｉｓｔｉｎｃｔ」モードをサポートする（ＳＱＬサポートと同様に）。こうした関数の戻り型は、関数がそれに対して実行されるプロパティの型に基づく。したがって、例えば、ａｖｇ（ｉｎｔ）は、ｉｎｔを戻すことになる。これは、２、３の平均が２．５ではなく２を戻すことになると予想することはできない。これを回避するために、ユーザは、プロパティを、正しい精度をもつ型、例えばａｖｇ（ｃａｓｔ（ｉｎｔＰｒｏｐｅｒｔｙ  ａｓ  ｄｏｕｂｌｅ））に明示的にキャストする必要がある。
【０４８０】
２．１．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．Ｔｓｑｌ．Ａｇｇｒｅｇａｔｅｓ名前空間内にある。
【０４８１】
２．１．２  例
【０４８２】
【表１２４】
2009530735.tif 000126
【０４８３】
２．１．３  サポートされるプラットフォーム
ＳＱＬ２０００、ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０４８４】
２．２  文字列関数
こうしたスカラー関数は、文字列入力値に対して演算を実施し、文字列または数値を戻す。
【０４８５】
【表１２５】
2009530735.tif 000127
【０４８６】
全文字列関数は、１から始まるインデックスをもつことに留意されたい。
【０４８７】
２．２．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．Ｔｓｑｌ．Ｓｔｒｉｎｇ名前空間内にある。
【０４８８】
２．２．２  例
【０４８９】
【表１２６】
2009530735.tif 000128
【０４９０】
２．２．３  サポートされるプラットフォーム
ＳＱＬ２０００、ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０４９１】
２．３  数学関数
こうしたスカラー関数は、共通の１組の数学演算を実施する。
【０４９２】
【表１２７】
2009530735.tif 000129
【０４９３】
２．３．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．Ｍａｔｈ名前空間にある。
【０４９４】
２．３．２  例
【０４９５】
【表１２８】
2009530735.tif 000130
【０４９６】
２．３．３  サポートされるプラットフォーム
ＳＱＬ２０００、ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０４９７】
２．４  日付関数
こうしたスカラー関数は、日時入力値に対して演算を実施し、文字列、数値、または日時値を戻す。
【０４９８】
【表１２９】
2009530735.tif 000131
【０４９９】
２．４．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．Ｄａｔｅ名前空間にある。
【０５００】
２．４．２  例
ｄａｔｅｐａｒｔは、文字列リテラルとして指定される必要がある。
【０５０１】
【表１３０】
2009530735.tif 000132
【０５０２】
２．４．３  サポートされるプラットフォーム
ＳＱＬ２０００、ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０５０３】
２．５  システム関数
Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．Ｓｙｓｔｅｍ名前空間に存在するプラットフォームによって変わる１組のシステム関数がある。以下のテーブルが、こうした関数を要約している。
【０５０４】
【表１３１】
2009530735.tif 000133
【０５０５】
以下のセクションでは、特定の関数についてより詳細に述べる。
【０５０６】
２．５．１  ＳｏｕｎｄｅｘおよびＤｉｆｆｅｒｅｎｃｅ
Ｓｏｕｎｄｅｘ関数は、Ｔ−ＳＱＬのＳｏｕｎｄｅｘ関数に対応し、同じように聞こえる単語または名前を見つけるために、英字列を４キャラクタコードにコンバートするのに使われる。コードの第１キャラクタは、ｃｈａｒａｃｔｅｒ＿ｅｘｐｒｅｓｓｉｏｎの第１キャラクタであり、コードの第２から第４キャラクタは数字である。ｃｈａｒａｃｔｅｒ＿ｅｘｐｒｅｓｓｉｏｎ中の母音は、文字列の第１文字でない限り無視される。文字列関数はネストすることができる。これに対する構文は以下のようになる。
【０５０７】
【表１３２】
2009530735.tif 000134
【０５０８】
Ｄｉｆｆｅｒｅｎｃｅは、２つのキャラクタ式のＳＯＵＮＤＥＸ値の間の違いを整数として戻す。この関数は、例えば名前を発音によってソートする際に有用であり得る。これに対する構文は以下のようになる。
【０５０９】
【表１３３】
2009530735.tif 000135
【０５１０】
以下は、クエリ中でｓｏｕｎｄｅｘおよびｄｉｆｆｅｒｅｎｃｅを使った例である。
【０５１１】
【表１３４】
2009530735.tif 000136
【０５１２】
２．５．１．１  サポートされるプラットフォーム
ＳＱＬ２０００、ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０５１３】
２．５．２  Ｄａｔａｌｅｎｇｔｈ
Ｄａｔａｌｅｎｇｔｈ関数は、プロパティのサイズを（ｉｎｔとして）戻すのに使われる。この関数は、ＳＱＬのｄａｔａｌｅｎｇｔｈ関数に対応する。これに対する構文は以下のようになる。
【０５１４】
【表１３５】
2009530735.tif 000137
【０５１５】
プロパティが値をもたない（すなわち、ヌルである）ケースにおいて、戻り値は、ヌルではなく、ゼロとなる。これは、ＳＱＬのｄａｔａｌｅｎｇｔｈ関数が作用するやり方とは対照的である。以下は、クエリ中でｄａｔａｌｅｎｇｔｈを使った例である。
【０５１６】
【表１３６】
2009530735.tif 000138
【０５１７】
２．５．２．１  サポートされるプラットフォーム
ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０５１８】
２．６  ＸＭＬ関数
ＸＭＬクエリのサポートは、拡張関数を介して有効にされる。以下の拡張関数が提供される。
【０５１９】
【表１３７】
2009530735.tif 000139
【０５２０】
【表１３８】
2009530735.tif 000140
【０５２１】
２．６．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．ＸＭＬ名前空間にある。
【０５２２】
２．６．２  例
【０５２３】
【表１３９】
2009530735.tif 000141
【０５２４】
２．６．３  サポートされるプラットフォーム
ＳＱＬ２００５およびＷｉｎＦＳ上でサポートされる。
【０５２５】
２．７  ＷｉｎＦＳ関数
２．７．１  フルテキストクエリ（ＷｉｎＦＳのみ）
ＷｉｎＦＳは、フルテキスト検索のために、２つのＴＶＦ、すなわちＣｏｎｔａｉｎｓおよびＦｒｅｅＴｅｘｔ（各々に対して２つの多重定義）をサポートしなければならない。こうした関数は、ＭＳＳｅａｒｃｈにおける機能にマップされる。
【０５２６】
【表１４０】
2009530735.tif 000142
【０５２７】
こうした関数はすべて、各々が２つのフィールドを有するローのマルチセットを戻す。ＩｔｅｍＩｄフィールドはＧｕｉｄであり、完全テキスト述部に一致した項目のｉｄである。Ｒａｎｋフィールドは、その項目に対するＲａｎｋである。結果は、Ｒａｎｋによって格納されず、明示的ｏｒｄｅｒ  ｂｙが、これを遂行するためにクエリ中で使われなければならない。
【０５２８】
Ｃｏｎｔａｉｎｓ
Ｃｏｎｔａｉｎｓは、ＭＳＳｅａｒｃｈのＣｏｎｔａｉｎｓ述部をモデル化する。ｃｏｎｔａｉｎｓＱｕｅｒｙ引数は、ＭＳＳｅａｒｃｈのＣｏｎｔａｉｎｓ述部によって指定された構文に準拠しなければならない。ｐｒｏｐＮａｍｅ引数は、ＷｉｎＦＳスキーマインストール中に検索プロパティを指定するのに使われる構文に準拠しなければならない。
【０５２９】
ＦｒｅｅＴｅｘｔ
ＦｒｅｅＴｅｘｔは、ＭＳＳｅａｒｃｈのＦｒｅｅＴｅｘｔ述部をモデル化する。ｆｒｅｅＴｅｘｔＱｕｅｒｙ引数は、ＭＳＳｅａｒｃｈのＦｒｅｅＴｅｘｔ述部によって指定された構文に準拠しなければならない。ｐｒｏｐＮａｍｅ引数は、ＷｉｎＦＳスキーマインストール中に検索プロパティを指定するのに使われる構文に準拠しなければならない。
【０５３０】
注
・ｅＳＱＬは、引数のどれも解釈しない。引数が文字列でなければならないことだけを気にかける。
【０５３１】
２．７．１．１  仕組み
スキーマのインストール
ＷｉｎＦＳスキーマがインストールされるとき、どの検索プロパティも識別され、クライアントアセンブリに格納される。プロパティ仕様に関する構文は、以下のようになる。
【０５３２】
【表１４１】
2009530735.tif 000143
【０５３３】
クエリ処理
上で言及したように、ｅＳＱＬは、引数をこうした関数に解釈しない。より詳細には、クエリを解析するＷｉｎＦＳランタイムは、パラメータが文字列であることを確かめるため以外のいかなるチェックも実施しない。
【０５３４】
ＷｉｎＦＳプロバイダは、ｐｒｏｐｅｒｔｙＮａｍｅ引数を、おそらくＳｑｌＧｅｎの一部として解釈し、クライアントアセンブリ中で適切なプロパティｉｄをルックアップし、次いでストア中の等価なＴＶＦコールに翻訳する責任がある。ストアＴＶＦは、以下のように見える署名をもつことになる。
【０５３５】
【表１４２】
2009530735.tif 000144
【０５３６】
２．７．１．２  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．ＷｉｎＦＳ名前空間にある。
【０５３７】
２．７．１．３  例
以下の例は、こうした関数の使用を示す
【０５３８】
【表１４３】
2009530735.tif 000145
【０５３９】
２．７．１．４  サポートされるプラットフォーム
ＷｉｎＦＳ上でサポートされる。
【０５４０】
２．７．２  ＳｕｍＳｔｒｉｎｇ（ＷｉｎＦＳのみ）
ＳｕｍＳｔｒｉｎｇ集約（ＳｕｍＳｔｒｉｎｇと呼ばれるストアＵＤＦに対応する）は、文字列のコレクションの内容を、区切り文字をもつ単一文字列に連結する能力を提供する。これは、単一テキストフィールドにおける、メッセージ参加者の「Ｔｏ」リストの表示を含むいくつかのＡｐｐシナリオにとって有用である。
【０５４１】
このｅＳＱＬ拡張は、ｃｏｕｎｔ、ｓｕｍ、ｍａｘなどの同様の集約関数であり、Ｇｒｏｕｐ演算の結果として、ＩｎｌｉｎｅＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎ、ＩｔｅｍＦｒａｇｍｅｎｔＣｏｌｌｅｃｔｉｏｎ、ＥｘｔｅｎｓｉｏｎＣｏｌｌｅｃｔｉｏｎおよびどの文字列プロパティに対する文字列プロパティにも適用することができる。この集約に関する構文は、以下のようになる。
【０５４２】
【表１４４】
2009530735.tif 000146
【０５４３】
ここで、コレクションは、文字列のコレクションでなければならない。
【０５４４】
２．７．２．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．ＷｉｎＦＳ名前空間にある。
【０５４５】
２．７．２．２  例
以下は、クエリ中でＳｕｍＳｔｒｉｎｇを使った例である。
【０５４６】
【表１４５】
2009530735.tif 000147
【０５４７】
２．７．２．３  サポートされるプラットフォーム
ＷｉｎＦＳ上でサポートされる。
【０５４８】
２．７．３  ＮｏｒｍａｌｉｚｅＤｉｇｉｔｓ（ＷｉｎＦＳのみ）
ＮｏｒｍａｌｉｚｅＤｉｇｉｔｓ集約（ｎｏｒｍａｌｉｚｅｄｉｇｉｔｓと呼ばれるストアＵＤＦに対応する）は、ウィンドウズシェルソートと同様の形式で、文字列をソートする能力を提供する。この関数に関する構文は、以下のようになる。
【０５４９】
【表１４６】
2009530735.tif 000148
【０５５０】
２．７．３．１  名前空間
こうした関数は、Ｓｙｓｔｅｍ．Ｄａｔａ．ＴＳｑｌ．ＷｉｎＦＳ名前空間にある。
【０５５１】
２．７．３．２  例
以下は、クエリ中でＳｕｍＳｔｒｉｎｇを使った例である。
【０５５２】
【表１４７】
2009530735.tif 000149
【０５５３】
２．７．３．３  サポートされるプラットフォーム
ＷｉｎＦＳ上でサポートされる。
【０５５４】
３  名前空間のローディング
この文書に記載される名前空間はすべて、ＳｑｌＣｌｉｅｎｔプロバイダに接続する際に自動的にロードされるべきである。明示的「ｕｓｉｎｇ」句を使う必要があってはならない。
【０５５５】
４  算出されたメソッドおよびプロパティ
ｅＳＱＬ照会言語は、Ｏ空間部分クラスに追加されるプロパティ（すなわち、非マッププロパティ）をクエリ中で参照することができるようにするための拡張機構をサポートする。こうしたプロパティは、ｅＳＱＬ式が属性を介してプロパティに関連づけられることを必要とする。このｉｓ式は次いで、プロパティがクエリ中で参照される場合はどこにでも置き換えられる。
【０５５６】
供給されるｅＳＱＬ式は、他の算出されたプロパティおよびメソッド、Ｐｒｏｖｉｄｅｒマニフェストにおいて指定される他のマップされたプロパティおよび他の関数を参照することができる。
【０５５７】
４．１  算出されたプロパティ
Ｓｙｓｔｅｍ．Ｄａｔａ．Ｏｂｊｅｃｔｓ．ＣａｌｃｕｌａｔｅｄＡｔｔｒｉｂｕｔｅは、クエリ中のプロパティの参照を可能にするために、クライアントクラス中で定義されるプロパティにのみ（マップされたプロパティではなく）追加することができる。
【０５５８】
ＣＬＲプロパティの型は、ｅＳＱＬ式によって戻される型と一致しなければならない。式の戻り型がヌル可能型である場合、プロパティは、ヌル可能型として宣言されなければならない。この制約は、インフラストラクチャによって強制され、例外が投げられることになる。式の戻り型がコレクションである場合、ＰｒｏｐｅｒｔｙはＱｕｅｒｙ＜Ｔ＞型でなければならない。
【０５５９】
Ｉｔｅｍに関するＩｔｅｍＳｉｚｅプロパティは、今日のスキーマに存在する算出されたプロパティの実際の例である。以下は、このプロパティを使った例である。
【０５６０】
【表１４８】
2009530735.tif 000150
【０５６１】
上の式は、ストア側の関数に対応するプロバイダマニフェストにおける関数を指す。
【０５６２】
ＰｒｉｍａｒｙＥｍａｉｌＡｄｄｒｅｓｓは、スキーマから算出することができたプロパティの例であり、今やこれを介して、この機能をｅＳＱＬにより述部とし、射影することができる。このプロパティは、Ｐｒｉｍａｒｙ  Ｋｅｙｗｏｒｄで印付けられたＰｅｒｓｏｎのＥメールアドレスを戻し得る。以下のコードは、このＰｒｉｍａｒｙＥｍａｉｌＡｄｄｒｅｓｓプロパティを、ｅＳＱＬによりこのプロパティを照会することを可能にするように定義する方法を例示する。
【０５６３】
【表１４９】
2009530735.tif 000151
【０５６４】
このプロパティは次いで、クエリ中で以下のように使うことができる。
【０５６５】
【表１５０】
2009530735.tif 000152
【０５６６】
ｅＳＱＬ式に関する注：
・「ｔｈｉｓ」接頭部は、インスタンス上の他の（マップされた、または算出された）Ｐｒｏｐｅｒｔｙ／Ｍｅｔｈｏｄを参照するのに使われなければならない。
・式は、実行時にのみ検証される。
・ｕｓｉｎｇ句を含む、有効などのｅＳＱＬ式も供給することができる。
・算出されたパラメータは、式の中でそれを参照するために、＠を伴って前置される必要がある。
【０５６７】
４．２  算出されたメソッド
算出されたプロパティと同様、部分クラス中で定義されるメソッドも、ｅＳＱＬにおいて使用可能となるように有効にすることができる。Ｓｙｓｔｅｍ．Ｄａｔａ．Ｏｂｊｅｃｔｓ．ＣａｌｃｕｌａｔｅｄＡｔｔｒｉｂｕｔｅは、プロパティへの追加と同様にして、メソッドに追加することができる。以下のセマンティクスおよび制約は、算出されたメソッドに当てはまる。
・一般的（例えば、Ｘ＜Ｔ＞）メソッドは現在、ｅＳＱＬにおいてサポートされない。すなわち、一般的型パラメータは、ｅＳＱＬ式の中で使われない。
・メソッドへの可変数のパラメータを認めるｐａｒａｍｓＣ＃キーワードは、算出されたメソッド中でサポートされない。
・算出されたメソッドの多相性は現在、サポートされない。
・現在、外部定義されたプライベートまたは内部算出されたメソッドに対するサポートはない。すなわち、ＡＰＩが、プロパティ／メソッドへのアクセスをもたなければならない。
・概して、算出されたメソッドにおける再帰コールはサポートされない。
・パラメータ値（型）による、算出されたメソッドの多重定義は現在、サポートされない。
・メソッドの戻り型は、ｅＳＱＬ式によって戻される型と一致しなければならない。
○式の戻り型がヌル可能型の場合、メソッドは、ヌル可能型を戻す際に宣言されなければならない。この制約は、インフラストラクチャによって強制され、例外が投げられることになる。
○式の戻り型がコレクションの場合、メソッドの戻り型はＱｕｅｒｙ＜Ｔ＞型でなければならない。
・新しい演算子を指定することによるメソッドの隠蔽はサポートされない。
・仮想メソッドはサポートされない。
・ｖｏｉｄを戻すメソッドはサポートされない。
・メソッドパラメータは、式の中で参照するために接頭部を必要としない。
【０５６８】
以下は、算出されたメソッドを使った例である。ここでのシナリオは、図３に示したように、日付ビューによるＯｕｔｌｏｏｋのグループ化と同様の、親しさによるグループ化表示を生成することである。
【０５６９】
以下のコードは、他の場所で再利用することができるように、これをメソッドにカプセル化する。
【０５７０】
【表１５１】
2009530735.tif 000153
【０５７１】
これは次いで、以下のように結果をグループ化するのに使うことができる。
【０５７２】
【表１５２】
2009530735.tif 000154
【０５７３】
４．３  ＣａｌｃｕｌａｔｅｄおよびＣａｃｌｕａｔｅｄＰａｒａｍｅｔｅｒ属性
Ｓｙｓｔｅｍ．Ｄａｔａ．Ｏｂｊｅｃｔｓ．ＣａｌｃｕｌａｔｅｄＡｔｔｒｉｂｕｔｅは、以下のように定義される。
【０５７４】
【表１５３】
2009530735.tif 000155
【０５７５】
この属性は、以下のプロパティを定義する。
・式：式プロパティは、値を射影する有効なｅＳＱＬ式を含まなければならない。この値は次いで、別の式で使うことができる。名前付きパラメータを式の中でどのように指定するかに関するより詳細については、以下を参照されたい。
【０５７６】
Ｓｙｓｔｅｍ．Ｄａｔａ．Ｏｂｊｅｃｔｓ．ＣａｌｃｕｌａｔｅｄＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅは、以下のように定義される。
【０５７７】
【表１５４】
2009530735.tif 000156
【０５７８】
この属性は、以下のプロパティを定義する。
・名前：Ｃａｌｃｕｌａｔｅｄ  ＡｔｔｒｉｂｕｔｅのＥｘｐｒｅｓｓｉｏｎプロパティにおいて参照されるパラメータの名前。
・値：Ｎａｍｅプロパティによって定義されるパラメータの値。
【０５７９】
ＣａｌｃｕｌａｔｅｄＡｔｔｒｉｂｕｔｅにおいて定義されるＮａｍｅｄパラメータは、こうしたセマンティクスに続く。
・算出されたパラメータへの参照は、＠接頭部をもたなければならない。
・ＣａｌｃｕｌａｔｅｄＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅおよびＣａｌｃｕｌａｔｅｄＡｔｔｒｉｂｕｔｅを定義する順序は、問題にならない。
・パラメータ名は、メソッドにおいてＣａｌｃｕｌａｔｅｄＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅによって定義されるメソッドパラメータ名および他の名前付きパラメータに渡って一意でなければならない。
・算出されたプロパティに対して、式の中のどの名前付きパラメータも、ＣａｌｃｕｌａｔｅｄＰａｒａｍｅｔｅｒＡｔｔｒｉｂｕｔｅによって定義されなければならない。
・以下の例は、上記属性クラスの使用を示す。
【０５８０】
【表１５５】
2009530735.tif 000157
【図面の簡単な説明】
【０５８１】
【図１】本明細書において提供されるシステムおよびメソッドに従ってデータにアクセスするアプリケーション用のアプリケーションサポートアーキテクチャを示す図である。
【図２】ＣＤＰアーキテクチャのメインコンポーネントを示し、特に、以下でより詳細に論じるリッチデータ型用の拡張照会言語を使って行われるクエリを指揮することができるものとしてのクエリパイプラインを記述する図である。
【図３】本発明による算出されたメソッドを用いて生成される、親しさによるグループ化表示と同様の、Ｏｕｔｌｏｏｋの日付でのグループ化表示を示す図である。
【図１】
2009530735.tif 000159
【図２】
2009530735.tif 000160
【図３】
2009530735.tif 000161
【国際調査報告】
2009530735.tif 000162
2009530735.tif 000163