"データを求めるアプリケーションリクエストを処理するシステムであって、プロセッサと、複数のアプリケーションデータモデルの中のいずれか1つにおいて表現されたデータベースクエリのfrom句の中に少なくともテーブルサブクエリ及び表現を含んだコレクション式を含むリクエストを受諾し、データベース及び非データベースデータタイプのコレクションを含むエンティティデータモデルに対するデプロイメントティア及びデータストアに対して独立なデータセマンティツクスを獲得するオブジェクトサービスレイヤ手段と、コレクション中の各データタイプに対してユニフォームな表現を生成するために前記コレクション中の各データタイプに関連したメタデータから駆動された拡張を使用してデータベース及び非データベースタイプの前記コレクションのためにクエリを一般化するオブジェクトサービスレイヤ手段と、前記リクエストをデータベースクエリを代表する正規表現ツリーに変換する複数のマッピング変換を供給し、前記エンティティデータモデルからの全てのデータをマッピングし、前記マップされたエンティティデータモデルはデータベース及び非データベースデータタイプのコレクション内の各エンティティに対して表現を有するマッププロバイダレイヤ手段と、前記正規表現ツリーを、第1のデータベース又はデータストアの少なくとも1つの要件に適応された変更済み正規表現ツリーにコンバートし、データモデルコンペンセーションを実行するブリッジレイヤ手段と、を備え、前記ブリッジレイヤ手段に結果を戻すように構成され、そして、前記ブリッジレイヤ手段は、前記正規表現ツリーを、複数のデータベースの中のいずれの要件にも適応された複数のデータモデル能力のいずれにもコンバートするように構成されていることを特徴とするシステム。前記リクエストは、union、intersect、およびexceptを含むグループから選択される集合演算をさらに含み、前記集合演算は、コレクションに対して作用することを特徴とする請求項1に記載のシステム。前記リクエストは、コレクションに対して作用するジョイン演算をさらに含むことを特徴とする請求項1に記載のシステム。プロセッサにより実行される方法であって、前記プロセッサにより実行されてコレクション中で各データタイプに対してユニフォームな表現を生成するために、union、intersect、およびexceptを含むグループから選択される、データベース及び非データベースデータに対してデータベースクエリのfrom句中に少なくともテーブルサブクエリ及び表現を含むコレクションに対して作用する集合演算を含むリクエストをオブジェクトサービスレイヤ手段を介して受諾するステップと、前記コレクション中の各データタイプに対してユニフォームな表現を生成するために前記コレクション中の各データタイプに関連したメタデータから駆動されるエクステンションを使用してデータベース及び非データベースタイプのコレクションに対するクエリを一般化するステップと前記リクエストをデータベースの正規表現ツリー代表に変換する複数のマッピング変換を供給するステップであって、エンティティデータモデルからの全てのデータをマッピングし、前記マップされたエンティティデータモデルはデータベース及び非データベースデータタイプのコレクション内の各エンティティに対して表現を有するマッププロバイダレイヤ手段を介して行われるステップと、前記正規表現ツリーを、第1のデータベース又は複数のデータストアのいずれかの少なくとも1つの要件に適応された変更済み正規表現ツリーにコンバートするステップであって、データモデルコンペンセーションをするブリッジレイヤ手段を介して行われるステップと、備え、前記ブリッジレイヤ手段に結果を戻すように構成され、そして、前記ブリッジレイヤ手段は、前記表現ツリーを、複数のデータベース又はストレージプロバイダの中のいずれの要件にも適応された複数のデータモデル能力のいずれにもコンバートするように構成されていることを特徴とする方法。前記リクエストは、コレクションに対して作用するジョイン演算をさらに含むことを特徴とする請求項4に記載の方法。データを求めるアプリケーションリクエストを処理するためのコンピュータプログラムを含んだコンピュータ可読記憶媒体であって、前記プログラムはプロセッサにより実行されると以下の動作を実行するものにおいて、データベース及び非データベースデータのコレクションを含むエンティティデータモデルに対するデプロイメントティア及びデータストアに対して独立なデータセマンティツクスを獲得し、そして複数のアプリケーションデータモデルのいずれか1つに表現されたデータクエリのfrom句中に少なくともテーブルサブクエリ及び表現を含むコレクションに対して作用するジョイン演算のリクエストを受諾するステップと、前記コレクション中の各データタイプに対してユニフォームな表現を生成するために前記コレクション中の各データタイプに関連したメタデータから駆動されるエクステンションを使用してデータベース及び非データベースタイプのコレクションに対するクエリを一般化するステップと、前記リクエストをデータベースクエリの正規表現ツリー代表に変換する複数のマッピング変換を供給するステップであって、エンティティデータモデルからの全てのデータをマッピングし、前記マップされたエンティティデータモデルはデータベース及び非データベースデータタイプのコレクション内の各エンティティに対して表現を有するステップと、ブリッジレイヤ手段を介して前記正規表現ツリーを、第1のデータベース又は複数のデータストアのいずれかの少なくとも1つの要件に適応された変更済み正規表現ツリーにコンバートするステップであって、データモデルコンペンセーションをするステップと、を備え、そして、前記ブリッジレイヤ手段は、前記表現ツリーを、複数のデータベースの中のいずれの要件にも適応された複数のデータモデル能力のいずれにもコンバートするように構成されていることを備えることを特徴とするコンピュータ可読記録媒体。データベースに対してデータをリクエストするように構成されたアプリケーションを実行するプロセッサであって、前記アプリケーションは、照会言語によるリクエストを生成し、前記照会言語は、少なくとも、以下の特徴を備え、前記照会言語が、データベース及び非データベースデータのコレクションを含むエンティティデータモデルに対するデプロイメントティア及びデータストアに対して独立なデータセマンティツクスを獲得し、そして複数のアプリケーションデータモデルのいずれか1つに表現されたデータクエリのfrom句中に少なくともテーブルサブクエリ及び表現を含むコレクション式の使用を許可する特徴と、前記照会言語が、オブジェクトサービスレイヤ手段を許可して、前記コレクション中の各データタイプに対してユニフォームな表現を生成するために前記コレクション中の各データタイプに関連したメタデータから駆動されるエクステンションを使用してデータベース及び非データベースタイプのコレクションに対するクエリを一般化する特徴と、前記照会言語が、データベースクエリの正規表現ツリーの代表へ前記コレクション式を変換するための複数のマッピングトランスフォームを供給するマッププロバイダレイヤ手段を開始する特徴と、前記照会言語が、前記コレクション中の各データタイプに対してユニフォームな表現を生成することにより、そしてデータベース及び非データベースデータに対するデータベースクエリのfrom句中にテーブルサブクエリ及び表現の少なくとも1つを含むコレクションからの表現のプロジェクションを可能にするためシンタクティツクオペレータを提供することにより、union、intersect、およびexceptを含むグループから選択される集合演算の使用を許可し、前記集合演算は、コレクションに対して作用する特徴と、前記照会言語が、コレクションに対して作用するジョイン演算の使用を許可し、エンティティデータモデルからの全てのデータをマッピングし、前記マップされたエンティティデータモデルはデータベース及び非データベースデータタイプのコレクション内の各エンティティに対して表現を有する特徴とを含むことを特徴とするプロセッサ。前記照会言語は、すべてのクエリが少なくとも1つの表現を含むことをさらに要求することを特徴とする請求項7に記載のプロセッサ。各式は、各式が使われるコンテキストに依存しない同一解釈をもつことを特徴とする請求項8に記載のプロセッサ。前記照会言語は、式の使用をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、全サブクエリをマルチセットサブクエリであると見なすことを特徴とする請求項7に記載のプロセッサ。サブクエリからスカラー値が所望される場合、前記照会言語は、コレクションに対して作用する要素演算子を前記アプリケーションが提供することを要求することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、コレクションから単集合値を抽出するための要素演算子、およびクエリ式中にローラッパーの作成を避けるためのselectvalue句の使用をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、暗黙のロー構築をスキップするためのselectvalue句の使用をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、selectvaluerowe1,e2,...ステートメントがselecte1,e2,...ステートメントと全く等しくなるような任意のローを構築するためのローコンストラクタの使用をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、前記from句の中の左相関を一般化し、前記左相関を一律に取り扱うクエリ式の使用をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、すべてのカラム参照がテーブルエイリアスで修飾されることを要求することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、コレクションを介したナビゲーションを扱うための構文的ショートカットの使用をさらに許可し、前記ショートカットは、a..bがtとしてaからt.b値を選択するの等価物となるように、コレクションからの式の射影を可能にするための..演算子を用いることを特徴とする請求項7に記載のプロセッサ。前記照会言語は、group-byキーのエイリアス作成の使用、およびこのようなキーの間の左相関をさらに許可することを特徴とする請求項7に記載のプロセッサ。前記照会言語は、2種類の集約、すなわちコレクションに対して作用するとともに集約結果を生じるコレクションベースの集約、および構造化照会言語SQLスタイルの集約の使用をさらに許可し、前記機構は、SQLスタイルの集約をコレクションベースの集約に暗黙的にコンバートすることを特徴とする請求項7に記載のプロセッサ。前記照会言語は、INSERT..VALUESステートメントの使用をさらに許可し、前記ステートメントは、前記INSERT..VALUESステートメント中でカラムリストを指定させないことを特徴とする請求項7に記載のプロセッサ。当該分野においては、リッチデータ型へのより優れたアプリケーションアクセスを提供するデータモデルおよび対応するサポートフレームワークに対する、満たされていない必要性がある。さらに、このようなデータモデルによってサポートすることができるようなリッチデータ型をサポートする拡張照会言語の必要性もある。上で明らかにした当該分野の短所を考慮した上で、本発明は、リッチデータ型をサポートする拡張照会言語を提供する。提供される照会言語の様々な例示的な特徴を、本明細書において論じる。さらに、システムは、照会言語によるクエリを生成するように構成されたアプリケーションを備え得る。提供される照会言語により生成されるクエリを扱うプラットフォームも提供する。プラットフォームは概して、究極的には様々な商用データベースとインターフェイスをとることができるオブジェクトサービスレイヤ、マッププロバイダレイヤ、およびブリッジレイヤを備える。本発明による、リッチデータ型をサポートする拡張照会言語用のシステムおよびメソッドを、添付の図面を参照してさらに説明する。本発明の様々な実施形態を完全に理解させるために、特定の具体的な詳細を、以下の説明および図面において述べる。ただし、本発明の様々な実施形態を不必要に分かりにくくすることを避けるために、しばしばコンピューティングおよびソフトウェア技術に関連づけられる特定の公知の詳細については、以下の開示において述べない。さらに、以下で説明する詳細の1つまたは複数なしで本発明の他の実施形態を実施できることが、当業者には理解されよう。最後に、以下の開示においてステップおよびシーケンスを参照して様々なメソッドを説明するが、そうした説明は、本発明の実施形態の明快な実装を実現するためのものであり、ステップおよび連続したステップは、本発明を実施するのに必要とされると見なされるべきでない。最初に、この説明では、例示的なデータモデルおよび関連データサポート機構を、本明細書において説明するリッチデータ型のサポートを照会言語に組み込むシステムおよびメソッドの例示的な実施形態において用いることができるものとして挙げる。次に、本明細書において述べる例示的な照会言語の様々な新規特徴および側面を強調し、論じる。例示的な照会言語の詳細な仕様を付表Aに記載し、その拡張を付表Bに記載する。詳細な実装形態は、新規かつ有用な数多くの特徴を含むことが、当業者には理解されよう。例示的なデータモデルおよび関連データサポート機構例示的なデータモデルおよび関連データサポート機構は、マネージドコードADO.NETプラットフォーム用のアクティブXデータオブジェクトなど、1組の技術に組み込むことができる。このプラットフォームは、マイクロソフト登録商標構造化照会言語SQLサーバなどのデータソース、ならびにデータベース用のオブジェクトのリンクと埋込みOLEDBおよび拡張マークアップ言語XMLにより公開されるデータソースへの一貫したアクセスを提供するように設計されている。データを共有する消費者アプリケーションは、ADO.NETを使って、こうしたデータソースに接続し、データを取得し、操作し、アップデートすることができる。ADO.NETは、データアクセスを、データ操作から、別個に、または協同で使うことができる個別の成分に手際よく因数分解する。ADO.NETは、データベースに接続し、コマンドを実行し、結果を取得する.NETフレームワークデータプロバイダを含む。こうした結果は、直接処理されるか、またはアドホックなやり方でユーザに公開され、多様なソースからのデータと組み合わされ、または層の間で離されるために、ADO.NETのDataSetオブジェクト中に配置されるかのどちらかである。ADO.NETのDataSetオブジェクトは、アプリケーションに対してローカルな、またはXMLから供給されるデータを管理するために、.NETフレームワークデータプロバイダとは独立して用いることができる。したがって、ADO.NETは、当業者にはよく知られているアクティブXデータオブジェクトADO技術によって固有COM開発者に提供される機能と同様な機能を、マネージドコードを書く開発者に提供する。一実施形態では、ADO.Netプラットフォームは、PIMフレームワークおよびLOBフレームワークなど、様々なアプリケーションフレームワークに渡るアプリケーションに、アプリケーションプログラミング環境と十分に統合された様式でデータにアクセスし、操作し、管理するための豊富な1組のデータサービスを提供するように拡張することができる。図1は、アプリケーションサポートアーキテクチャにおけるこの機能の配置を示す。共通データプラットフォームCDP100は、ADO.Netプラットフォームなど、1組の技術を実装することができる。共通データプラットフォームCDP100および関連技術については、例えば特許文献1において詳しく論じられている。図1のアプリケーションサポートアーキテクチャは、例えば、SQLSERVER登録商標、WinFS登録商標、またはORACLE登録商標データベースなどのデータソース110と、アプリケーションおよびアプリケーションフレームワークにリッチデータサービスを提供するCDP100と、1組のフレームワークサービス、例えばCDP100の機能を拡張し増補するUAF120およびLOBフレームワーク130と、フレームワーク機能および一般的な適用論理をカプセル化するデータクラスのセット、例えば、122、132、140と、CDP100およびフレームワーク120、130および/またはクラス122、132、140によって提供される機能を利用する任意の数のアプリケーション150、160、170を含み得る。CDP100によってサポートされるデータモデルは、例えば、ワシントン州レドモンドの本件特許出願人によって開発されたエンティティデータモデルEDMを含み得る。EDMは、例えばLOB、PIM、Managementなど、多様なアプリケーションフレームワークに適合するように、リレーショナルデータモデルを拡張する。EDMは、データ用のリッチオブジェクトの抽象化を定義し、データ関係など、豊富なセマンティクスをモデル化し、アプリケーション構造とデータモデルの間のミスマッチを最小限にし、特定のアプリケーション挙動をサポートし、基本的なリレーショナルコンセプト、継承を有するリッチ型、および関係をサポートし、概して、データストアおよび展開層に依存しないデータセマンティクスを取り込むモデリングコンセプトを提供する。EDMは、ADO.NETなどの技術に組み込むことができる。図2は、CDP100のアーキテクチャのメインコンポーネントを示し、特に、以下でより詳細に論じるリッチデータ型用の拡張照会言語を使って行われるクエリを指揮することができるものとしてのクエリパイプラインを記述する。eSQLという用語は、本明細書においては、リッチデータ型用の拡張照会言語を指すのに使われ、その実施形態は、以下で詳しく説明する。図2は、クエリがCDP100の異なるコンポーネントをどのように流れるかも示す。最初に、アプリケーション200が、eSQLクエリとして、オブジェクトサービスプロバイダ210に対するクエリを発行する。オブジェクトサービスプロバイダ210は、クエリを分析し正規ツリーにコンバートするパーササービス211、および正規ツリーに対して本明細書において与えられる、アプリケーションデータモデルからEDMへのいかなるマッピング翻訳も実施するマッピング変換212を備え得る。オブジェクトサービスプロバイダは次いで、正規ツリーをマッププロバイダ220に伝えることができる。マッププロバイダ220は、オブジェクトリレーショナルマップ機能をカプセル化する。プロバイダ220は、正規ツリーに対してマッピング翻訳を実施するマッピング変換222を備える。マッププロバイダは、正規ツリーを仲介サービス用のブリッジ230に渡す。ブリッジ230は、正規ツリーを因数分解し、いかなるデータモデル補償も実施し、次いで、1つまたは複数の正規ツリーをストレージプロバイダ240に伝えるクエリ補償サービスコンポーネント231を備え得る。ストレージプロバイダ240は、正規ツリーをその固有ダイアレクト、例えば、SQL2000やSQL2005などのSQLダイアレクト、あるいはWinFSまたは組込みデータベース形式に翻訳する。ストレージプロバイダ240は、クエリを実行し、メッセージ、例えばDataReaderインターフェイスDataReaderに、またはそこからブリッジ230に渡されるようにフォーマットすることができるメッセージを戻す。ブリッジ230は、ストレージプロバイダ240によって戻された、可能性としては多数のDataReaderからの結果を、必要な場合アセンブルする、結果/値アセンブリサービス232を備える。232によって実施されるこの演算の結果は、EDM空間の観点では単一DataReaderである。マッププロバイダ220は次に、DataReaderを単にブリッジ230からオブジェクトサービスプロバイダ210に戻す。オブジェクトサービス210は、マッププロバイダ220からの結果をオブジェクト空間に翻訳する。オブジェクトサービスプロバイダ221は、任意選択で結果をオブジェクトとして具体化し、識別マップ中にそうしたオブジェクトのキャッシュをとるコンポーネント213を備える。最後に、アプリケーション200は、結果として生じたDataReaderを利用する。より詳細に、EDMのいくつかの顕著な側面に移ると、EDMは概して、4つのコアコンセプト、すなわち型、インスタンス、エンティティ、および関係によって構築される。こうしたコンセプトは、典型的なLOBアプリケーションの例を用いて示すことができる。このようなアプリケーションは、異なる種類のデータ、例えば、注文、顧客、注文明細行、住所、供給元、製品、従業員などを処置する。EDMの例示的な使用において、Customerデータは、エンティティと見なすことができる。エンティティとは、アプリケーションが連動する最上位レベルのデータ単位を表す。Customerは、いくつかのフィールド、すなわちCustomerID、CompanyName、ContactName、Address、およびPhoneを有し得る。各フィールドは、そのフィールドに入るデータの構造を決定する型をもつ。例えば、CustomerIDは、固定長の文字列でよい。CompanyNameおよびContactNameフィールドも、文字列型でよい。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の間の1つの関係は、関連づけと呼ばれる。関連づけは通常、エンティティの間のピアツーピア関係をモデル化するのに使われる。各注文は、いくつかの注文明細行からなり得る。例えば、AMAZON.COM登録商標で5冊の本を注文した場合、各本についての情報が注文明細行である。このことは、別の種類の関係、すなわち構成としてモデル化される。構成中の各OrderLineはエンティティである。eSQLの例示的な新規特徴次に、例示的な照会言語の様々な新規特徴および側面について強調し、論じる。概して、eSQL言語およびその拡張は、以下で与えられるように、図1、2を参照して上述したようなシステム内に実装することができるが、以下の例示的な実施形態に関連づけられた様々な新規システムおよびメソッドは、他のコンテキストにおいても同様に実装できることが、当業者には理解されよう。以下に定められたeSQL仕様は、EDMなどのリッチデータ型リッチデータモデリング言語、リッチデータモデリング言語におけるプログラムによるクエリおよびDMLの指定法を表す正規コマンドツリーCTree、正規クエリを操作することによって特定のプロバイダを補償するブリッジ機能、クエリおよびアップデートを有するリッチデータモデリング言語セマンティクスすべてに渡ってORマッピング戦略をすっきりと統一するように展開する表示の使用をサポートするデータモデリング言語によってクエリおよびデータ操作言語ステートメントDML:本明細書で使用するクエリという用語は、クエリおよびDMLを指すを表すことを含むが、それに限定されない。そして、メタデータから駆動される拡張によりコア照会言語を拡張する能力。さらに、以下で述べるeSQL仕様の例示的な新規側面は、以下のものを含む。コレクションに対する第1クラスサポート:本明細書において与えられる例示的なeSQL実施形態は、SQLと同様となるとともにSQLを上回る利点を提供するように設計される。概して、SQLの初期バージョンSQL-92およびそれ以前のバージョンは、かなりテーブル中心であった。テーブルは、第1クラス市民として取り扱われ、ロー/カラムは第2クラスとして取り扱われた。しかも当然ながら、コレクションという概念はなかった。SQL-99およびそれ以降のダイアレクトは、コレクションのサポートを提供するが、このサポートは、SQL-92へ改造されている。例えば、unnest、applyなどのような役に立たない追加を参照されたい。対照的に、一実施形態では、eSQLは、コレクションを第1クラスエンティティとして取り扱う。例えば、コレクション式は、from句において正当である。unnest構文を使う必要はない。inおよびexistsサブクエリは、どのコレクションも扱うように一般化されており、サブクエリとは単に1種類のコレクションである。e1ine2およびexistseは、こうした演算を実施するためのeSQLコンストラクトである。さらに、集合演算union、intersect、exceptの多くは、コレクションに対して作用する。joinも、同様にコレクションに対して作用する。あらゆるものが式である:標準SQLは常に、2レベルのシステム、すなわちサブクエリtableおよび式row、columnをもっている。一実施形態では、コレクションおよびネストされたコレクション用の第1クラスサポートを提供するために、eSQLは、はるかに明快なモデル、すなわちあらゆるものが式であるを採用する。例えば、以下はすべて、正当なeSQLクエリである。サブクエリの統一した取扱い:テーブルを中心とした世の中の表示から操作を行うと、SQLは通常、サブクエリの文脈翻訳を実施する傾向があった。例えば、SQLにおいて、from句の中のサブクエリは、マルチセットtableであると見なされ、select句の中で使われる同じサブクエリは、スカラーサブクエリであると見なされる。同様の路線に沿って、in演算子の左側で使われるサブクエリは、スカラーサブクエリであると見なされ、右側はマルチセットサブクエリであると予想される。一実施形態では、eSQLは、こうした違いを排除する。式は、それが使われるコンテキストに依存しない同一解釈を有する。eSQLは、全サブクエリを、マルチセットサブクエリであると見なし得る。スカラー値がサブクエリから所望される場合、eSQLは、コレクションこの場合、サブクエリに対して作用する要素演算子を提供し、そのコレクションから単集合値を抽出することができる。不当な暗黙の強制の回避:上述した問題の関連した副作用は、スカラー値への、サブクエリの暗黙のコンバートの概念である。具体的には、SQLでは、単一フィールドを有するローのマルチセットが、そのデータ型がフィールドのデータ型であるスカラー値に暗黙的にコンバートされる。対照的に、eSQLの実施形態では、この暗黙の強制をサポートしない。eSQLは、コレクションから単集合値を抽出するための要素演算子、およびクエリ式の間にローラッパーの作成を避けるためのselectvalue句を提供することができる。select_value、暗黙のローラッパーの回避:SQLは、クエリからの結果の取扱いに関して多少あいまいである。SQLサブクエリ中のselect句は、その句の中の項目周辺にローラッパーを暗黙的に作成する。このことは、当然ながら、スカラーまたはオブジェクトのコレクションを作成することができない、すなわちすべてのコレクションは必要な場合、1つのフィールドを有するローのコレクションであることを含意する。SQLは、1つのフィールドをもつロー型と、同じデータ型の単集合値との間の暗黙の強制を認めることによって、この問題を回避する。一実施形態では、eSQLは、暗黙のロー構築をスキップするためにselectvalue句を提供する。selectvalue句の中では、ただ1つの項目を指定することができる。このような句が使われるとき、select句の中の項目周辺にローラッパーは構築されず、所望の形状のコレクションを生じることができる。eSQLは、任意のローを構築するためのローコンストラクタも提供する。したがって、selectvaluerowe1,e2,...は、selecte1,e2,...と全く等しい。別の実施形態では、selectのセマンティクスは、単一項目ケースに対するロー構築を避け、必要とされる場合はローコンストラクタを明示的に使うことができよう。select句は、多様な項目を含む場合、SQLでのように振る舞い続けることになる。代替的であるとともによりすっきりとした手法は、selecte1,e2from...の形のコンストラクトを認めず、その代わり人々にselectrowe1,e2from...を常に使うよう強制することである。左相関およびエイリアス作成:標準SQLでは、所与のスコープ内の式select、fromなどのような単一句は、同じスコープ内で先に定義されている式を参照することができない。T-SQLを含むSQLの一部のダイアレクトは、from句の中の限定された形のそうした式を実際にサポートするが、このようなコンストラクトを使うための構文は役に立たず、applyおよびunnest演算を必要とする。一実施形態では、eSQLは、from句の中の左相関を一般化し、それらを一律に取り扱う。from句の中の式は、特別な構文を必要とすることなく、同じ句の中の先の定義左側の定義を参照することができる。eSQLはまた、group-by句を伴うクエリに追加制約を課す。このようなクエリのselect句、having句などの中の式は、そのエイリアスを介してgroup-byキーのみを参照し得る。SQLでは正当だった以下のようなコンストラクトは、eSQLでは不正である。selecttxtyfromTastgroupbytxtyeSQLにおいて上記を行う正しいやり方は、以下の通りである。selectkfromTastgroupbyaskテーブルコレクションの列プロパティの参照:一実施形態では、eSQLにおけるすべてのカラム参照は、テーブルエイリアスで修飾されなければならない。以下のコンストラクトaがテーブルTの正当なカラムであると仮定するは、SQLでは正当であるが、eSQLでは正当ではない。selectafromTeSQLが承認した形は、以下のようになる。selecttaasafromTast非修飾参照は、いくつかの問題を被る。そうした参照は、あいまいな場合がある。そうした参照は、スキーマ発展中の外部/内部取込み問題を被り、その上、実装を複雑にする。SQLにおける適切に設計されたクエリは既に、修飾されたカラム参照を使って、こうした問題に対処している。eSQLが行うのは、このガイドラインを単に施行することだけであり、このことが言語をより複雑にするわけではない。オブジェクトを介したナビゲーション:SQLは、テーブルの複数カラム1つのローを参照する.表記を用いる。一実施形態では、eSQLは、この表記やはり、プログラミング言語から大部分を借用しているを、オブジェクトのプロパティによるナビゲーションをサポートするように拡張する。例えば、pがPerson型の式である場合、pAddressCityは、この人物の住所の市を参照するeSQL構文である。SQLの多くのダイアレクトは既に、この構文をサポートしている。コレクションを介したナビゲーション:SQLは、ネストされたコレクションを介したナビゲートするための簡単な機構を提供しない。一実施形態では、eSQLは、こうしたケースを扱うための構文的ショートカットを提供する。eSQLにおける..演算子は、コレクションからの式の射影を可能にする。例えば、a..bは実際には、tとしてaからt.b値を選択するの糖衣構文である。同様に、a..b..c2は、t1としてaからt2.c2値、t2としてt1.bを選択するの糖衣構文である。eSQLにおける.演算子により、ユーザは、コレクションから要素を抜き出すことができる。これは、XPathにおける[]演算子と同様である。a.pの形のコンストラクトは実際には、pの場合にtとしてaからt値を選択するのショートカットである。例えば、p.id=1は実際には、p0.id=1の場合にp0としてpからp0値を選択するを意味する。継承と連携するとき、上位型インスタンスのコレクションから下位型のインスタンスを選び出すことができることは、しばしば有用である。eSQLにおけるoftype演算子はCシーケンスにおけるoftypeと同様に、この機能を提供する。論理的に、oftypec,Tは、xがTの場合にxとしてcからtreatxasT値を選択すると等しい。の廃止:SQLは、非修飾構文をロー全体に対するエイリアスとして、修飾された構文t.をそのテーブルのフィールドに対するショートカットとしてサポートする。さらに、SQLは、ヌルを含む特別なcount集約を可能にする。SQLにおける、適切に設計されたクエリは、このような構文少なくとも、selectおよびselectt.変形体を使わない。の使用は、スキーマが発展している場合は危険である。問題の一部は、SQLが、ユーザにロー全体を選び出させないことである。一実施形態では、eSQLは、コンストラクトをサポートしない。selectfromTおよびselectT1fromT1,T2...の形のSQLクエリは、eSQLではそれぞれ、selectvaluetfromTastおよびselectvaluet1fromT1ast1,T2ast2...と表現することができる。さらに、こうしたコンストラクトは、継承値の代替性を巧みに扱うが、select変形体は、宣言された型の最上位レベルのプロパティに制限される。eSQLの実施形態は、count集約もサポートしない。代わりに、このケースを扱うために、countgroupコンストラクトをサポートする。groupbyに対する変更:上で説明したように、一実施形態では、eSQLは、group-byキーのエイリアス作成、およびこうしたキーの間の左相関をサポートする。実際、select句およびhaving句の中の式は、こうしたエイリアスを介して、groupbyキーを参照しなければならない。group-by句は暗黙的に、各group-byパーティションに対するネスト集約を生じ、この式はグループと呼ばれる。selectリストなどの中の集約関数は、この式を参照して集約を実施するべきである。例えば、selectklcountsumfromTastgroupbytbtcask1は、以下のSQLクエリに対するeSQL構文である。selectbccountsumfromTgroupbybcCollectionベースの集約:SQL集約は、理解しにくい。一実施形態では、eSQLは、2種類の集約をサポートする。Collectionベースの集約は、コレクションに対して作用し、集約結果を生じる。こうした集約は、クエリ中のどこにでも現れ、group-by句を必要とすることはない。例えば、以下のeSQLクエリは正当である。selecttaasacountasbfromTast一実施形態では、eSQLは、SQLスタイルの集約もサポートし、暗黙的に、グループコレクションに基づいてコレクションベースの集約にコンバートする。例えば、eSQLにおける以下のクエリselectasumfromTastgroupbytaasaは正当であり、内部では以下の形のクエリに翻訳される。selectasumasbfromTastgroupbytaasa一実施形態では、eSQLは、count集約をサポートしない。代わりにcountgroupコンストラクトを使う。Insert:一実施形態では、eSQLのINSERT..VALUESステートメントは、T-SQLとは異なる。T-SQLとは異なり、eSQLは、カラムリストをinsert中で指定させない。これには2つの理由がある。第1に、EDMは、カラムに関するデフォルト値の概念をもたない。第2に、カラムリスト手法は、継承値の代替性を扱うのに好適ではない。Delete、Update:T-SQLとは異なり、一実施形態では、eSQLは、deleteおよびupdateステートメント中で追加のfrom句を認めない。deleteステートメントに対しては、クエリはサブクエリを用いて書くことができるので、このことは問題を提示しない。ただし、updateステートメントに対しては、追加のfrom句は、Set句の中で使われる新しい値を生じる際にも役立つ。リフトされたプロパティおよびメソッド:ウィンドウズ登録商標照会言語WinQLは、コレクション自体が同じ名前のプロパティをもたない場合、.演算子を介したコレクションによるナビゲーションを可能にする。WinQLは、OPathと同様に、[]コンストラクトを介してコレクションの要素をふるい落とすことも可能にする。一実施形態では、eSQLは、この目的で..および.演算子を使う。やはり、スキーマの発展および内部取込みが、eSQLがコレクションナビゲーションとオブジェクトナビゲーションとを区別することを選ぶ主な理由である。そして、eSQLは、あいまいさの問題を避けるために、述部での[]の使用を意図的に避ける。order-byのセマンティクス:WinQLは、orderby句がselect句の前に処理されることを指定する。これは、orderby句がselect句の後に論理的に処理されるSQLとは異なる。一実施形態では、eSQLは、この点においてSQLに比較的近くてよいが、WinQLは、よりXQueryのような手法をとる。いずれの手法も妥当であり、いくつかの点では、WinQLモデルの方が優れている。ただし、WinQL手法は、SQLユーザに対する振舞いの変更を正当化する程、十分に優れているわけではない。SQL-92は実際に、orderby句を、select句の中の項目への参照のみを含むように制限する。ほとんどの実装形態は、orderby句に、現時点でスコープ内にある他の項目を参照させる。一実施形態では、eSQLは、後者のスタイルに従う場合もある。本明細書において明示的に述べた具体的な実装形態に加えて、他の態様および実装形態が、本明細書で開示した明細を考慮すれば、当業者には明らかであろう。本明細書および例示した実装形態は、添付の請求項の真の範囲および精神に対して、例としてのみ見なされることを意図している。付表A:例示的な照会言語の詳細な仕様以下は、ここで企図される例示的な照会言語の、例示的であって限定でない仕様である。以下の仕様に続くのは、このような照会言語に対する拡張のための例示的な仕様である。1機能の要約1.1問題空間の記述CDPは、アプリケーションおよびフレームワークによって利用することができるオブジェクトリレーショナルマッピングインフラストラクチャを提供する。WinFSは、広範囲に渡るデスクトップアプリケーション向けに、統制のとれた格納経験をもたらす。WinFSおよびCDPは両方とも、エンティティデータモデルEDMの上に構築される。EDMは、基本的なリレーショナルコンセプト、継承を有するリッチ型、および関係をサポートする拡張リレーショナルデータモデルである。ユーザは、EDMによって表現されるそうしたデータに対するリッチクエリを発行する能力を必要とする。SQLは歴史的に、データベースアクセスのために選ばれた照会言語であるが、多くの短所を被っている。リッチ型、非直交構造などをサポートしないことは、短所のいくつかに過ぎない。eSQLは、SQLに関するこうした問題の多くに対処することを試みる。eSQLは、SQLと同様になり、SQLに対する何らかの追加インフラストラクチャおよび改良を提供するように設計される。WinFSおよびCDPは両方とも、既存の.NETデータアクセス技術、すなわちADO.NETを活用して、データにアクセスし操作する。.NETDataProviderは、Connection、Command、DataReaderおよび他のこのようなオブジェクトを介して、どのデータソースからでもデータにアクセスする、多少統一のとれた方法を提供する。.NETDataProviderへのコマンドは、文字列として表現され、プロバイダの固有ダイアレクトより詳細には、プロバイダによって前置されるデータソースで書かれなければならない。CDP/WinFSの成果の一部として、3つの新規プロバイダ、すなわちObjectProvider、EDMProvider、およびWinFSProviderが供給されることになり、これらはすべて、eSQLを固有ダイアレクトとして使うことになる。2概観および設計原理2.1設計原理コレクションおよびオブジェクトの第1クラスサポートeSQLは、ユーザがそのオブジェクトおよびコレクションに渡ってシームレスに照会を行うことを容易にしなければならない。直交性eSQLにおけるコンストラクトは直交でなければならない。所与のコンストラクトの使用に関して、文脈解釈があってはならない。構成可能性eSQLにおけるコンストラクトは、他のコンストラクト中でも構成可能でなければならない。SQLとの類似eSQLは、可能な限り、SQLのような言語のままであるべきである。SQLからの逸脱が必要例えば、上記理由づけによって要求される場合でない限り、eSQLは、SQLコンストラクトとの忠実性を維持するべきである。3言語概観eSQLは、式の概念を含む。式とは、他のプログラミング言語でのように、値を生じるために数値を求めることができるコンストラクトである。eSQLクエリは、正当などの式にもなる。eSQLは、以下の種類の式を提供する。3.1リテラルリテラルとは、ほとんどのプログラミング言語でのように、単に定数値である。eSQLは、文字列および数値リテラル、ならびに特別な浮動データ型をもつnullリテラルの固有サポートを提供する。3.2パラメータeSQLにおけるパラメータは、式およびクエリが、クエリ外部で定義された値を参照することを可能にする。3.3変数参照eSQLにおける変数参照は、式が、同じスコープ内で先に定義されたかつ名前付きの他の式を参照することを可能にする。3.4組込み演算子eSQLは、小さな組込み演算子セットを提供する。これは、、-、、/のような算術演算子、比較演算子<、>、..、論理演算子and、or、notなど、およびいくつかの種々の演算子case、betweenなどを含む。3.5関数eSQLは、独自の組込み関数を全く定義しない。eSQL関数式は、ユーザが定義したどのeSQLから見える関数の使用も可能にする。3.6オブジェクトナビゲーション、メソッドこうしたeSQL式は、オブジェクトプロパティおよびメソッドが自然に参照され処置されることを可能にする。3.7集約関数eSQLにおける集約関数は、そのSQL相対物のように、コレクションに対する折畳み演算を可能にする。eSQLは、ネスト集約、およびどのユーザ定義集約もサポートする。eSQLの集約関数は、式のどこでも用いることができるという点で、コレクションベースである。eSQLは、クエリ式においてのみ使用可能である、SQLのようなグループベースの集約もサポートする。3.8コンストラクタeSQLは、3種類のコンストラクタを提供する。rowコンストラクタは、無名の、構造的に型づけされたレコード値を作成するのに使うことができる。objectコンストラクタCなどにおけるコンストラクタは、名前付きユーザ定義オブジェクトを構成するのに使うことができる。multisetコンストラクタは、他の値のマルチセットを構成するのに使うことができる。3.9型演算eSQLは、ある式値の型が照会され処置されることを可能にする演算を提供する。これは、isofCのis式と同様のような問合せ演算、treatCのas式およびoftypeCシーケンスのOfTypeメソッドのような下位型/上位型キャスト、ならびにcastのようなコンバート演算子を含む。3.10集合演算子eSQLは、豊富な1組の集合演算を提供する。これは、union、intersect、exceptおよびexistsのような、SQLのような集合演算子を含む。さらに、eSQLは、重複除去distinct、メンバシップ検査in、ジョインjoin用の演算子をサポートする。3.11クエリ式クエリ式は、古典的なSQLのselect-from-where-...クエリを表す。4言語詳細:eSQLの式4.1リテラルヌルヌルリテラルは、どの型のヌル値も表すのに使われる。ヌルリテラルは、浮動であると見なされ、すなわちどの型とも互換性がある。型づけされたヌルは、ヌルリテラルに優先して、Cast演算子を介して作成することができる。浮動ヌルリテラルを使うことができる場合の規則については、セクション9.6を参照されたい。ブール値ブール値リテラルは、真および偽というキーワードによって表される。整数Int32、Int64整数リテラルは、Int32またはInt64型でよい。Int32リテラルは、一連の数値キャラクタである。Int64リテラルは、その後に大文字Lが続く一連の数値キャラクタである。10進固定小数点数10進は、一連の数値キャラクタ、ピリオド.およびその後に大文字Mが続く別の一連の数値キャラクタである。浮動小数点、ダブル型倍精度浮動小数点数は、一連の数値キャラクタ、ピリオド.およびおそらくはその後に指数部が続く別の一連の数値キャラクタである。単精度浮動小数点数または浮動小数点は、その後に小文字fが続く倍精度浮動小数点数構文である。文字列文字列は、引用符に囲まれた一連のキャラクタである。引用符は、両単一引用符‘でも、両二重引用符でもよい。引用識別子は、[]またはのいずれでも表すことができる。デフォルトでは、[]スタイルのみが認められ、コンストラクトは、文字列リテラルとして取り扱われる。eSQLパーサは、パーサオプションによって制御されることになるが、これはこの文書の範囲外であるスタイルの引用識別子を認め得る。その場合、文字列リテラルは、単一引用符のみを用いることができる。これについてのより多くの情報に関しては、セクション9.1.2を参照されたい。他のリテラルeSQLは、元来、他のデータ型DateTime、Guidなどのリテラルをサポートしない。4.2パラメータパラメータは、一般にホスト言語によって使われる束縛APIを介して、照会言語の外部で定義される変数である。各パラメータは、名前および型をもつ。パラメータ名は、プロパティの名前またはクエリ内部で定義される他の名前と明確に区別するために、名前の前に接頭部として、記号を有して記述される。ホスト言語束縛APIは、束縛パラメータ用のAPIを提供する。以下の例は、式におけるパラメータの使用を示す。4.3変数変数式は、現在のスコープ内で先に定義された名前付きの式への参照である。変数参照は、6で定義されるような有効な識別子でなければならない。以下の例は、式における変数の使用を示す。4.4組込み演算子eSQLは、以下のように、いくつかの組込み演算子を提供する。4.4.1算術算術演算子は、Int32、Int16、Int64、Double、Single、およびDecimalなどの数値プリミティブ用に定義される。バイナリ演算子の場合、演算子が適用される前に、オペランドに対して暗黙の型昇格が起こる。全算術演算子の結果型は、昇格されたオペランド型と同じである。加算も、文字列に対して定義され、連結として振る舞う。4.4.2比較比較演算子は、Byte、Int32、Int16、Int64、Double、SingleおよびDecimalなどの数値プリミティブ、StringならびにDateTime用に定義される。比較演算子が適用される前に、オペランドに対する暗黙の型昇格が起こる。比較演算子は、常にブール値を生ずる。等式および不等式は、ブール値型および識別を有する任意のオブジェクト型用に定義される。識別を有する非基本要素オブジェクトは、同じ識別を共有する場合、等しいと見なされる。4.4.3論理論理演算子は、ブール値型用にのみ定義され、常にブール値型を戻す。4.4.4casecase式は、TSQLのcase式と同様のセマンティクスをもつ。case式は、どの式が適切な結果を生ずることになるか判定するための、一連の条件つきテストを行うのに使われる。b1、b2、...、bn-1がBoolean型の式であり、e1、e2、...、enが何らかのS型の式である場合、以下の式は、S型の単一値を生ずる有効なcase式である。この形のcase式は、正しい結果として生じる式を判定するための、一連の1つまたは複数のBoolean式に当てはまる。値真となる第1のwhen式は、対応するthen式を生ずる。それ以外の式は、評価されない。when条件のどれも満たされない場合、その結果は、else式存在する場合、またはヌルelse式がない場合を評価した結果となる。case式の実際の結果型を判定するための異なる結果式e1、e2、...en、vnの間で暗黙の型昇格が起こり得ることに留意されたい。4.4.5betweenbetween式は、SQLのbetween式と同じセマンティクスをもつ。この式は、所与の式が下限と上限の間の値を結果として生じるかどうか判定する。e1、e2、e3が何らかのT型であるすべての式である場合、上記の式は、有効なbetween演算子式である。between式は、同じ値に対する2つの比較演算子を書くことの短縮形である。between構文は、e1が複合式である場合に便利である。between式の逆を示すのに、not-between式を使うことができる。4.4.6likelike式は、TSQL用に記述されるのと同じセマンティクスをもつ。この式は、文字列がパターンと一致するかどうか判定し、文字列が一致する場合は真に、一致しない場合は偽に帰結する。match、patternおよびescapeが、String型をもつすべての式である場合、以下は、Boolean値を生ずる有効なlike式である。matchlikepatternmatchnotlikepatternmatchlikepatternescapeescapematchnotlikepatternescapeescapepattern文字列構文は、TSQLのpattern文字列構文と同じである。4.4.7ヌルテストisnullis-null演算子は、式が値ヌルを結果として生じるかどうか判定するのに使われる。式が値ヌルを結果として生じる場合、式は、値真を結果として生じる。ヌルを結果として生じない場合、式は、値偽を結果として生じる。eが式である場合、以下の式は、ブール値を生ずる有効な式である。eisnulleisnotnull外部ジョインの要素がヌルでないかどうか判定するのに、is-null演算子を使う。メンバが実効値をもつかどうか判定するのに、is-null演算子を使う。4.5メンバアクセスメンバアクセスは一般に、dot演算子としても知られる。オブジェクトインスタンスのプロパティまたはフィールドの値を生ずるのに、メンバアクセス演算子を用いる。mが、M型をもつT型のメンバであり、tがT型のインスタンスである場合、t.mは、M型である値を生ずる正当なメンバアクセス式である。4.6メソッド呼出しメソッド呼出しは、メソッドに対する明示的なコールである。この呼出しは、メソッドコールという結果を生ずる。メソッドは、ある型のインスタンスメソッド、ある型の静的メソッド、またはグローバル静的メソッドすなわちスタンドアロン関数でよい。mが、M型を戻すとともにP1、P2、...、Pn型のパラメータを有するT型のメソッドであり、tがT型のインスタンスであり、e1がP1型の式である、などの場合、t.me1,e2,...,enは、M型の値を生ずる有効なメソッド呼出しである。mが、M型を戻すとともにP1、P2、...、Pn型のパラメータを有するT型のメソッドであり、qnがT型を指す修飾名であり、e1がP1型の式である、などの場合、qn.me1,e2,...,enは、M型の値を生ずる有効な静的メソッド呼出しである。mが、M型を戻すとともにP1、P2、...、Pn型のパラメータを有するメソッドTであり、qnがメソッドの名前空間接頭部を指す修飾名であり、e1がP1型の式である、などの場合、qn.me1,e2,...,enは、M型の値を生ずる有効な静的メソッド呼出しである。eSQLクエリ中に現れ得るメソッド呼出しの例は、基本要素データ型に組み込まれたメソッドの使用でよい。4.6.1多重定義の解決同じ名前をもつ複数のメソッドを定義することができる。与えられた式によってどのメソッドが参照されるか判定するために、こうした規則に従う。単一メソッドのみを生ずる、続けて適用される第1の規則は、解決済みメソッドである。1.同じ数のパラメータを有するメソッドが存在する。2.各引数型がパラメータ型と全く一致し、またはヌルリテラルであるメソッド。3.各引数型がパラメータ型と全く一致し、またはその下位型であり、あるいは引数がヌルリテラルであるメソッド。下位型のコンバートの数が最小であるメソッドが勝つ。4.各引数型がパラメータ型と全く一致し、その下位型であり、またはそれに昇格することができ、あるいは引数がヌルリテラルであるメソッド。下位型のコンバートおよび昇格の数が最小であるメソッドが勝つ。5.メソッド呼出し式があいまいである。こうした規則を使って単一メソッドを抽出することができるとしても、引数は依然として、パラメータと一致するわけではないことに留意されたい。これが成り立つ場合、引数はエラーとなる。4.7enumenumは、名前によって参照される強く型づけされた整数値である。enumは、その後にdot演算子およびenumの名前が続くenumの型を参照するための修飾名を使って指定される。qnが何らかのenumEの修飾名であり、enがその列挙の値の名前である場合、qn.enは有効なenum参照である。4.8型演算eSQLは、式の値の型と連携するためのいくつかの演算を提供する。4.8.1isofisof式は、式が指定された型のインスタンスであるかどうか調べる。eが何らかのコンパイル時S型であり、SがTの下位型/上位型いずれかである場合、上の式は有効な式であり、Boolean型の結果を戻す。eの型が、実行時にTまたはTの何らかの下位型であると判定された場合、eisofTはTrueを戻す。eが実行時にnullである場合、この式はnullを戻し、nullでない場合、この式の結果はFalseである。唯一の修飾子が指定された場合、eがまさにT型であり、その下位型のどれでもない場合のみ、式は真を戻す。式eisnotofTおよびeisnotofonlyTは、それぞれnoteisofT、およびnoteisofonlyTと統語的に等しい。SがTの下位型でも上位型でもない場合、この式は、コンパイル時エラーを起こす。4.8.1.1treattreat式は、与えられた式を上位型/下位型によって型づけし直すことを試みる。eがS型を有し、TがSの下位型であるかまたはSがTの下位型である場合、上式は、有効なtreat式であり、T型の値を生ずる。SもTも他方の下位型でない場合、式は、コンパイル時エラーを結果として生じる。eがEmployee型を有しManagerがEmployeeの下位型である場合、以下の式は、同じ値eを生ずるが、EmployeeではなくManagerとして型づけされる。eの値が実際にはManager型でない場合、式は、値nullを生ずる。4.8.1.2castcast式は、TSQLのconvert式と同様のセマンティクスをもつ。cast式は、ある型の値を別の型の値にコンバートするのに使われる。特定の型のコンバートのみが言語によってサポートされる。eが何らかのS型であり、SがTにコンバート可能な場合、上式は、有効なcast式である。Tは基本要素スカラー型でなければならない。cast式の使用は、明示的コンバートと見なされる。明示的コンバートは、データを切り詰めることも、精度を落とすこともある。eSQLによってサポートされる有効なキャストのリストについては、セクション10.5に記述してある。4.8.1.3OfTypeOfType式は、コレクションの各要素に対して型検査を実施するために発行される式型を指定する。OfType式は、その型と等価であった、またはその下位型であった要素のみを含む指定された型の新しいコレクションを生じる。tsが、collection<S>型のコレクションでありTがSの下位型である場合、OfTypets,Tは、個々のe型、すなわちTeがTの下位型であるtsの要素eすべてからなるコレクションを生ずるcollection<T>型の式である。OfType式は、以下のクエリ式の短縮形である。ManagerがEmployeeの下位型であるとすると、以下の式は、従業員のコレクションから、管理職のみのコレクションを生じる。型フィルタを使ってコレクションをアップキャストすることも可能である。コレクションは現在、管理職のコレクションとして型づけされるが、すべての役員は管理職なので、結果として生じたコレクションは依然として、元の役員全員を含む。既知の不正な型キャストを行うことはできない。以下の式は、コンパイル時エラーを起こすことになる。当然ながら、AddressはEmployeeの下位型/上位型でないと仮定する。4.9参照eSQLは、参照用に以下の演算子をサポートする。4.9.1RefRef演算子は、entityset用の相関変数に適用されると、そのコレクションからエンティティへの参照を生じる。例えば、以下のクエリは、各Orderへの参照を戻す。以下は、ref演算子の不正な使用である。相関変数は、現在のスコープ内のエンティティセットに分解しなければならない。4.9.2CreateRefCreateRef演算子は、entityset中のエンティティへの参照を生じるのに使うことができる。この演算子への第1引数は、entityset識別子であり文字列リテラルではない、第2引数は、エンティティ型のキープロパティに対応する、レコードとして型づけされた式である。レコードとして型づけされた式は、エンティティ用のキー型と構造的に等価でなければならず、すなわちエンティティキーと同じ数および型のフィールドを同じ順序でもたなければならないが、フィールドの名前は不適切となる。4.9.3KeyKey演算子は、CreateRef演算子の逆であり、ref型をもつ式のキー部分を抽出するのに使うことができる。Key演算子の戻り型は、レコード型であり、エンティティの各キーに対して1つのフィールドを、同じ順序でもつ。4.9.4DerefDeref演算子は、参照値を取得し、その間接参照の結果を生じる。rがref<T>型の参照である場合、Derefrは、rによって参照されるエンティティを生ずるT型の式である。参照値がヌルであるか、または懸垂している、すなわち参照の目標が存在しない場合、Deref演算子の結果はヌルになる。4.9.5属性間接参照.演算子を使って、参照をナビゲートすることができる。以下の断片は、CustRefプロパティを介してナビゲートすることによって、CustomerのIdプロパティを抽出する。参照値がヌルであるか、または懸垂dangleしている、すなわち参照の目標が存在しない場合、結果はヌルとなる。4.10コンストラクタeSQLは、3種類のコンストラクタ、すなわちローコンストラクタ、オブジェクトコンストラクタおよびマルチセットコンストラクタを提供する。4.10.1ローコンストラクタローコンストラクタは、1つまたは複数の値から、構造的に型づけされた無名のレコードを構成するのに使うことができる。ローコンストラクタの結果型はロー型であり、そのフィールド型は、ローを構成するのに使われる値の型に対応する。例えば、式は、Recordaint,bstring,cint型の値を生じる。ローコンストラクタ中のすべての式について、エイリアスが作成されなければならない。エイリアスが与えられない場合、eSQLは、0で規定されるエイリアス作成規則によりエイリアスを生成することを試みる。ローコンストラクタ中の式は、同じコンストラクタにおいて先に左側で定義されたエイリアスを参照することができない。同じローコンストラクタ中の2つの式が同じエイリアスをもつのは不正である。dot.演算子は、レコードからフィールドを抽出するのに使うことができるオブジェクトの抽出プロパティと同様である。4.10.2NamedTypeコンストラクタNamedType初期化子eSQLは、名前付き型コンストラクタ初期化子が、名前付きの複合型および/またはエンティティ型のインスタンスを作成するのに使われるようにする。以下の式は、Person型のインスタンスを作成するPerson型はそうした2つの属性をもつと仮定する。コンストラクタへの引数は、型の属性の宣言と同じ順序であると仮定される。4.10.3Collectionコンストラクタマルチセットコンストラクタは、値のリストから、マルチセットのインスタンスを作成する。コンストラクタ中の値はすべて、相互に互換可能なT型でなければならず、コンストラクタは、Multiset<T>型のコレクションを生じる。以下の式は、整数のマルチセットを作成する。4.11集合演算このセクションは、様々な集合演算子を含む。4.11.1distinctdistinct式は、すべての重複参照が削除された新しいコレクションを生ずることによって、オブジェクトのコレクションをセットにコンバートするのに使われる。cがcollection<T>型のコレクションである場合、distinctcは、重複をもたないcollection<T>型のコレクションを生ずる有効なdistinct式である。T型は、等式に匹敵equalcomparableしなければならない。distinct式は、select式の短縮形である。4.11.2flattenflatten式は、コレクションからなるコレクションを、同じ要素すべてをもち、ネスト構造をもたないフラット化コレクションにコンバートするのに使われる。cがcollection<collection<T>>型のコレクションである場合、flattencは、collection<T>型の新しいコレクションを生ずる有効なflatten式である。flatten式は、select式使用の短縮である。4.11.3existsexists式は、TSQLのexists式と同じセマンティクスを有する。この式は、コレクションが空かどうか判定する。コレクションが空でない場合、exists式は真を戻し、空の場合は偽を戻す。cがCollection<T>型のコレクションである場合、existscは、Boolean型の単一値を生ずる有効なexists式である。4.11.4inin演算子は、コレクション中のメンバシップ向けの値を検査するのに使われる。inキーワードの左手側にある式の値は、右手側にある式で表されるコレクション中で検索される。eがT型を有する式でありtsがCollection<S>型を有するコレクションであり、SおよびTが上位型/下位型関係を有する場合、以下の式は、有効なin演算子式である。eintsenotints以下の例では、Bobという名前が、顧客の名前のセットの中で検索される。値がコレクション中にあると分かった場合、in演算子は、値trueを生ずる。値がヌルであるか、またはコレクションがヌルである場合、in演算子は、値nullを生ずる。それ以外の場合、in演算子は、値falseを生ずる。この演算子のnot形は、逆を生ずる。4.11.5union、unionalleSQLにおけるunionおよびunionall式は、そのTSQL同等物と同じセマンティクスを有する。UnionAllは、重複を有する2つのコレクションの組み合わされた内容を含むコレクションを生じる。unionは、重複が削除されたコレクションを生じる。c1がCollection<T>型のコレクションであり、c2がCollection<S>型のコレクションであり、ここでMはTおよびSの共通上位型である場合、c1unionc2およびc1unionallc2は、Collection<M>型のコレクションを生ずる有効なunion式である。以下の例は、ワシントンに住んでいるか、または得意客である全顧客のセットを識別する。第1の式は、どの重複例えば、ワシントンにも住んでいる得意客も排除するが、第2式は、すべての重複を保持する。4.11.6IntersectIntersect式は、TSQLのintersect式と同じセマンティクスを有する。この式は、2つのコレクションの交差を判定する。c1がCollection<T>型のコレクションであり、c2がCollection<S>型のコレクションであり、ここでMはTおよびSの共通上位型である場合、c1intersectc2は、Collection<M>型のコレクションを生ずる有効なintersect式である。以下の例は、ワシントンに住んでおり、得意客である全顧客のセットを識別する。4.11.7ExceptExcept式は、TSQLのexcept式と同じセマンティクスを有する。この式は、2つのコレクションの単方向の違いを判定する。c1がCollection<T>型のコレクションであり、c2がCollection<S>型のコレクションであり、ここでMはTおよびSの共通上位型である場合、e1exceptc2は、Collection<T>型のコレクションを生ずる有効なexcept式である。以下の例では、悪い顧客ではない全顧客のセットが識別される。4.11.8overlapsoverlaps式は、2つのコレクションが共通メンバをもつかどうか判定する。c1がCollection<T>型のコレクションであり、c2がCollection<S>型のコレクションであり、ここでMはTおよびSの共通上位型である場合、c1overlapsc2は、Boolean型の結果を生ずる有効なoverlaps式である。以下の例は、ワシントンのいずれかの顧客が得意客であるかどうか調べるとともに、の構文的ショートカットである。4.11.9elementelement式は、単集合コレクションから要素を抽出する。cがCollection<T>型のコレクションである場合、elementcは、T型のインスタンスを生ずる有効なelement式である。以下の例は、悪い顧客のセットから単集合要素を抽出することを試みる。コレクションが空であるか、または複数の要素をもつ場合、element式はヌルを戻す。4.12コレクションのナビゲーションeSQLは、コレクションをより簡単に扱うことができるようにするいくつかの統語コンストラクトを提供する。4.12.1射影..コレクション-射影演算子は、コレクションから要素を射影するのに使われる。cがCollection<T>型のコレクションであり、pがQ型をもつTのプロパティである場合、c..pは、Collection<Q>型のコレクションを生じる。より全般的には、cがCollection<T>型のコレクションであり、eがQ型の何らかの式である場合、c..eは、cの各要素ごとにeを評価した結果を含むCollection<Q>型のコレクションを生じる。以下の例は、全部署の大文字化された名前を得るとともに、以下のクエリのショートカットである。4.12.2フィルタリング.コレクション-フィルタ演算子は、コレクションから要素をふるい落とすのに使われる。cがCollection<T>型のコレクションであり、eがQ型をもつブール式である場合、c.eは、述部eを満たしたcの要素のみを含むCollection<T>型のコレクションを生じる。以下の例は、シアトルを拠点とする全部署のセットを得るとともに、以下のクエリのショートカットである。4.12.3フラット化された射影...フラット化コレクション-射影演算子は、ネストされたコレクションから要素を射影するのに使われる。より全般的には、cがCollection<Collection<T>>型のコレクションであり、eがQ型の何らかの式である場合、c...eは、第1のフラット化cの結果を含むCollection<Q>型のコレクションを生じ、次いで、cの各要素ごとにeを評価する。以下の例は、EmployeesがDepartmentのセット値プロパティであると仮定し、全従業員の大文字化された名前を得るとともに、以下のクエリのショートカットである。4.12.4フラット化フィルタリング..フラット化コレクション-フィルタ演算子は、ネストされたコレクションから要素をふるい落とすのに使われる。より全般的には、cがCollection<Collection<T>>型のコレクションであり、eが何らかのブール式である場合、c..eは、第1のフラット化cの結果を含むCollection<T>型のコレクションを生じ、次いで、eを満たさない結果の要素をふるい落とす。以下の例は、EmployeesがDepartmentのセット値プロパティであると仮定し、給料が10000より多い全従業員のセットを得るとともに、以下のクエリのショートカットである。スコープ作成規則上のケースすべてにおいて、Collection<T>型のコレクションの中をナビゲートするとき、新しいスコープが作成され、現在のコレクション要素は、変数itに束縛される。統語の便宜上、Tのプロパティおよびメソッドも、スコープ内にあると仮定されるが、これらは、it変数を介したメンバアクセスのためのショートカットであると見なされる。例えば、以下のようになる。4.13集約関数集約は、一連の入力値を必ずしもそうではないが、一般には単一値に削減する式である。こうした関数は普通、select式のgroup-by句とともに使われ、実際にどこで使うことができるかに関して、制約がある。各集約演算は、1つまたは複数の型に対して定義される。eSQLは、集約セットを定義しない。eSQLは、集約関数を扱うための周囲のメタデータ空間に依拠するだけである。Collectionベースの集約Collectionベースの集約は、特定の値セットに渡って算出される集約である。例えば、ordersが、全注文からなるコレクションであるとすると、最も早い出荷日付を以下の式で算出することができる。コレクションベースの集約内部の式は、現在の周囲の名前解決スコープを使って評価される。グループベースの集約グループベースの集約は、group-by句によって定義されるグループに渡って算出される。結果の中の各グループごとに、各グループ中の要素を集約算出への入力として使って、別個の集約が算出される。group-by句がselect式中で使われると、グループ化式の名前、集約または定数式のみを、射影またはorder-by句に提示することができる。以下の例は、各製品ごとに注文される平均的量を算出する。グループベースの集約は、コレクションベースの式の、SQLとの互換性を保つための単なるショートカットである。上の例は、実際には以下のように翻訳されることになる。上式で、group式は、group-by句によって暗黙的に生じられたネスト集約を指す。この式は、select式中に明示的なgroup-by句のないグループベースの集約をもつことが可能である。全要素は、定数に基づいたグループ化を指定するケースと等しく、単一グループとして取り扱われることになる。グループベースの集約内部の式は、where句式からは見えるはずの名前解決スコープを使って評価される。SQLのルックアンドフィールを保つために、グループベースの集約は、その入力においてallまたはdistinct修飾子を指定することもできる。distinct修飾子が指定された場合、集約が計算される前に、集約入力コレクションから重複が排除される。all修飾子が指定されたまたは修飾子が指定されなかった場合、重複除去は実施されない。distinct修飾子は実際には、distinct演算子の統語的短縮形である。Collectionベースの集約とグループベースの集約との区別Collectionベースの集約は、eSQLにおいて好ましい集約指定モードである。ただし、SQLユーザにとっての移行に伴う苦痛を和らげるために、グループベースの集約もサポートされる。同様に、集約入力への修飾子としてのdistinctまたはallの指定も、SQLのような振舞いのためにサポートされるが、好ましい機構は、distinct演算子を代わりに使うことである。グループベースの集約とコレクションベースの集約との名前解決ポリシーの違いにより、実装が両方のスコープの下で評価を試みることが必要になり得る。その戦略では、第1にコレクションベースの集約、第2にグループベースの集約としての翻訳を好む。4.14サポートされない式4.14.1非修飾述部SQLは、以下の形のコンストラクトを可能にする。eSQLは、このようなコンストラクトをサポートしない。上式は、eSQLでは、以下のように表現することができる。eSQLは、非修飾式で拡張することができよう。4.14.2SQLは、全カラムが射影される必要があることを示すための、select句における構文的ショートカットとして、の使用をサポートする。5言語の詳細:クエリ式クエリ式は、最も汎用なeSQL式であり、SQLに精通したプログラマにとって最も常識的である。この式は、多くの異なるクエリ演算子を単一構文に組み合わせる。こうした演算子の多くは、個々に指定することができるが、どれも、クエリ式に組み合わされるとき程の表現力はない。特段の指定がない限り、select式は、TSQLのselectステートメントと同様に振る舞う。クエリ式は、オブジェクトのコレクションに連続演算を適用する一連の句からなる。こうした句は、標準SQLのselectステートメントに見られる同じ句、すなわちselect、from、where、groupby、havingおよびorderbyに基づく。クエリ式は、その最も単純な形において、その後に射影リスト、fromキーワード、ソース表現、whereキーワードおよび最後にフィルタリング条件が続くselectキーワードによって指定される。この例では、cは何らかのT型のオブジェクトのコレクションであり、mはM型を有するTのメンバであり、eはTの1つまたは複数のメンバを参照し得るBoolean式である。クエリは、M型を有するオブジェクトの新しいコレクションを生じる。5.1From句ほとんどの部分に関して、from句は、TSQL向けに記述されるのと同じセマンティクスを有する。ただし、構文における制限ははるかに少なく、正当なソースとなるべきコレクションを生ずるどの言語式も認める。from句は、1つまたは複数のfrom句項目からなる、コンマで区切られたリストである。from句は、select式用の1つまたは複数のソースを指定するのに使うことができる。from句の最も単純な形は、コレクションおよびエイリアスを識別する単一式である。概して、select式は、注文の中のソースコレクションの各要素に対して作用する。これは、反復と呼ばれる。selectリストまたはwhere句の中の式は、変数が要素を参照するときにコレクションのエイリアスを使って、現在の要素のプロパティを参照することができる。5.1.1From句項目各from句項目は、クエリ中のソースコレクションを指す。eSQLは、from句項目の以下のクラスをサポートする。5.1.1.1単純なFrom句項目最も単純なfrom句項目は、コレクションおよびエイリアスを識別する単一式である。エイリアス指定は任意選択であり、上記from句項目の代替指定は、以下のようになり得る。エイリアスが指定されない場合、eSQLは、コレクション式に基づいてエイリアスを生成することを試みる。後で説明する0を参照されたい。5.1.1.2JoinFrom句項目JoinFromClauseItemは、2つのfrom句項目の間のジョインを表す。eSQLは、クロスジョイン、内部ジョイン、左および右外部ジョインならびに完全外部ジョインをサポートし、こうしたジョインはすべて、T-SQLと同様の様式である。T-SQLでのように、ジョインに巻き込まれる2つのfrom句項目は、独立していなければならず、すなわち、相関してはならない。CrossApply/OuterApplyは、こうしたケースに対して使うことができる。クロスジョインcrossjoin式は、2つのコレクションのデカルト積を生じる。内部ジョインinnerjoinは、2つのコレクションの制限されたデカルト積を生じる。この式は、on条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。on条件は、常に指定されなければならない。左外部ジョイン、右外部ジョインouterjoin式は、2つのコレクションの制限されたデカルト積を生じる。この式は、on条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。on条件が偽の場合、式は依然として、ヌル値をもつ右手要素に対して対になった左手要素の単一インスタンスを処理する。右外部ジョインは、同様の様式で表現することができる。完全外部ジョイン明示的なfullouterjoinは、2つのコレクションの制限されたデカルト積を生じる。この式は、on条件が真である場合に右手コレクションのすべての要素に対して対になった、左手コレクションのすべての要素からなる組合せを処理する。on条件が偽の場合、式は依然として、ヌル値をもつ右手要素に対して対になった、左手要素の1つのインスタンス、およびヌル値をもつ左手要素に対して対になった、右手要素の1つのインスタンスを処理する。注:Sql-92、TSqlとの互換性を保つために、外部キーワードは任意選択である。したがって、左ジョイン、右ジョイン、および完全ジョインは、左外部ジョイン、右外部ジョインおよび完全外部ジョインの別名である。ON句は、内部および外部ジョイン用に使われなければならず、クロスジョインに対しては不正である。5.1.1.3ApplyFrom句項目eSQLは、2種類のApply、すなわちCrossApplyおよびOuterApplyをサポートする。crossapplyは、左手コレクションの各要素の、右手式を評価することによって生じられたコレクションの要素との一意のペアリングを生じる。crossapplyにより、右手式は、左手要素の関数となる。クロスアプライの振舞いは、joinリストに関して記述されるのと同様である。右手式が、空のコレクションになる場合、クロスアプライは、左手要素のそのインスタンスに対するペアリングを生じない。outerapplyは、右手式が空のコレクションになるときでもペアリングが依然として生じられること以外は、クロスアプライと同様である。注:TSqlとは異なり、明示的ネスト解除ステップは必要ない。5.1.2From句における多様なコレクションfrom句は、コンマで区切られる複数のコレクション指定を含み得る。このようなケースでは、コレクションは、組み合わされるべきと仮定される。これらを、nウェイクロスジョインとして考える。5.1.3左相関from句の中の項目は、先に指定された項目を参照することができる。以下の例において、CおよびDは独立コレクションであり、c.NamesはCに依存する。これは、と論理的に等価である。5.1.4セマンティクス論理的に、from句の中のコレクションは、nウェイクロスジョインの一部、すなわち、1ウェイクロスジョインである縮退ケースであると仮定される。from句の中のエイリアスは、左から右へ処理され、以降の参照のために現在のスコープに追加される。from句は、from句の中の各項目ごとに1フィールドをもち、そのコレクション項目から単一要素を表すローのマルチセットを生じると仮定される。上の例において、from句は論理的に、フィールドc、d、eがC、D、およびc.Namesの要素型であると仮定される、Rowc,d,e型のローのマルチセットを生じる。eSQLは、スコープ内の単純な各from句項目用のエイリアスを導入する。例えば、以下のクエリにおいて、スコープ内に導入される名前はc、d、eである。SQLとは異なり、from句は、スコープ内にエイリアスを導入するだけである。こうしたコレクションのカラムプロパティに対するどの参照も、エイリアスで修飾されなければならない。5.2where句where句は、TSQLに関して説明したのと同じセマンティクスを有する。この句は、ソースコレクションの要素を、条件を渡すものに限定することによって、クエリ式によって生じられるオブジェクトを制限する。式eは、Boolean型をもたなければならない。where句は、from句の後、グループ化、順序づけまたは射影の前に直接適用される。from句の中で定義される全要素名は、where句の式から見える。5.3groupby句group-by句は、TSQLに関して記述したのと同様のセマンティクスを有する。集約を評価する目的で、ソース要素を一緒のグループにするのにその値が使われる1つまたは複数の式を指定することができる。groupby句の中の各式は、等式に匹敵し得る何らかの型に評価されなければならない。こうした型は概して、数字、文字列および日付などのスカラープリミティブである。型が等式の概念を定義する限り、group-by条件として複合型を使うことが可能である。コレクションによってグループ化することはできない。明示的にまたは暗黙的にクエリ中に句をもつことによりグループ句が指定されると、現在のスコープは隠され、新しいスコープが導入される。select句、having句およびorder-by句は、from句の中で指定される要素名をそれ以上参照することができなくなる。グループ化式自体だけを参照することができる。そうするためには、各グループ化式に新しい名前エイリアスを割り当てればよい。グループ化式のエイリアスが指定されない場合、eSQLは、0にあるエイリアス生成規則によりエイリアスを生成することを試みる。group-by句の中の式は、同じgroup-by句の中で先に定義された名前を参照することができない。グループ化名に加えて、select句、having句およびorder-by句の中では、集約も指定することができる。集約は、グループの各要素ごとに評価される式を含む。集約演算子は、こうした全式の値を常にではないが一般に、単一値に削減する。集約式は、親スコープ内で見える元の要素名への、またはgroup-by句自体によって導入される新しい名前への参照を行うことができる。集約は、select句、having句およびorder-by句の中に現れるが、実際にはグループ化式と同じスコープの下で評価される。このクエリは、group-by句を使って、製品によって分類される、注文された全製品の価格についての報告を生じる。このクエリは、グループ化式の一部として、製品に名前nameを与え、次いで、selectリスト中でその名前を参照する。このクエリはまた、注文明細行の価格および量を内部的に参照するselectリスト中で集約sumを指定する。名前付きグループグループ自体が、名前をもってよい。グループは、命名されると、グループインスタンスを形成するオブジェクトのコレクションを指す新しい名前をスコープ内に導入する。グループ自体が、グループに関する基準に一致する項目すべてをマルチセットに単に集約する集約、すなわちネスト集約である。論理的に、groupby句は、キーと、そのグループ用の非キーカラムのコレクションを含む各グループごとの暗黙のネスト集約とに基づいたグループ化を実施する。集約、すなわちグループベースの集約への以降の参照は、コレクションベースの集約に翻訳され、ここで問題となるコレクションは、groupby句によって生じられるネスト集約である。この例では、グループmygroupがgroup-by句の中で識別され、selectリスト中で参照される。名前mygroupは、単一グループを形成するOrderLineインスタンスのコレクションを指す。結果として生じたコレクションの各ローは、3つのプロパティ、すなわちname、totalおよびmygroupをもつことになる。グループ用に自分自身の名前を常に定義する必要はない。名前を指定しなくても、名前groupを使ってグループに常にアクセスすることができる。5.4having句having句は、グループ化の結果に対する追加のフィルタリング条件を指定するのに使われる。クエリ中でgroup-by句が指定されない場合、暗黙の1でのグループ化、すなわち単一セットグループが仮定される。having句は、group-by演算の後に適用される以外は、まさにwhere句のように作用する。このことは、having句はグループ化エイリアスおよび集約への参照だけを行うことができることを意味する。この例は、having句がグループを、その中に複数の製品単位をもつものだけに制限すること以外、group-byの例と同じである。5.5select句selectキーワードに続く1つまたは複数の式のリストは、selectリストまたはより正式には射影として知られる。射影の最も一般的な形は、単一式である。コレクションcから何らかのメンバmを選択した場合、cの各要素に対するm値すべてからなる新しいコレクションを生じることになる。例えば、customersが、string型のNameプロパティをもつcustomer型のコレクションである場合、customersからNameを選択すると、文字列のコレクションを生ずることになる。rowおよびvalueselect句eSQLは、select句の2つの変形体をサポートする。第1の変形体であるrowselectは、selectキーワードによって識別され、射影されるべき1つまたは複数の項目を指定するのに使うことができる。暗黙的に、項目の周辺にローラッパーが追加され、その結果、クエリ式の結果が常に、適切なフィールドを有するローのマルチセットとなる。rowselect中の各式は、エイリアスを指定しなければならない。エイリアスが指定されない場合、eSQLは、0に記載したエイリアス作成規則を使ってエイリアスを生成することを試みる。select句のもう1つの変形体であるvalueselectは、selectvalueキーワードによって識別され、ただ1つの項目を指定させ、ローラッパーへの追加は行わない。rowselectは、常にvalueselectによって表現可能である。例えば、以下のようになる。allおよびdistinct修飾子selectの両方の変形体は、allまたはdistinct修飾子の指定を可能にする。distinct修飾子が指定されると、クエリ式によって生じられたコレクションから重複が排除されるselect句を含むまで。all修飾子が指定された場合、重複除去は実施されない。こうした修飾子は、SQLと互換性をもつように保たれるだけである。eSQLは、代わりにdistinct演算子の使用を提案するが、こうした変形体をサポートし、透過的に式を翻訳する。セマンティクスselect句は、from、句、groupbyおよびhaving句が評価された後に評価される。select句は、現時点でスコープ内にある項目だけをfrom句により、または外部スコープから参照することができる。group-by句が指定されている場合、select句は、groupbyキー用のエイリアスのみを参照することが認められる。from句項目の参照は、集約関数の一部としてのみ許可される。5.5.1SQLからの逸脱の非サポートeSQLは、from句全体またはテーブルの全カラムが射影されるべきであることを示すのに、の使用も修飾されたの使用もサポートしない。こうしたコンストラクトは、スキーマが展開するときに予期されない副作用をもち得るので、SQLにおいてさえも、適切に設計されたクエリは、こうしたコンストラクトを避ける。eSQLは、代わりに、from句からのコレクションエイリアスを参照することによって、クエリに、レコード全体を射影させる。以下のSQLクエリは、eSQLでは以下のコンストラクトによってはるかに適切に表現される。5.6orderby句order-by句は、結果中の要素の順序づけを決定する1つまたは複数の式を指定することができる。order-by句は論理的に、select句の結果に適用される。この句は、selectリスト中の項目を、そのエイリアスにより参照することができる。さらに、この句は、現時点でスコープ内にある他の変数も参照することができる。ただし、select句がdistinct修飾子で指定されている場合、order-by句は、select句からのみエイリアスを参照することができる。order-by句の中の各式は、順序つき不等式未満またはより大きい、などに匹敵し得る何らかの型にならなければならず、こうした型は概して、数字、文字列および日付などのスカラープリミティブである。order-by句の中の各式は、任意選択で、基準のソートを指定することができる。特定の式に対して昇順ソートまたは降順ソートが必要とされることを示すために、ASCまたはDESCを指定することができる。さらに、文字列型の式の場合、順序づけ用に使われるべき文字列照合を示すために、COLLATE句を指定することができる。位置に関する指定、例えば、orderby3は、selectリスト上の対応する第3の項目がサポートされないことを示すのに使うことができる。6言語詳細:コマンド6.1コマンドeSQLコマンドとは、クエリリクエスト全体に対して使われる用語である。コマンドは、select式や、オブジェクトを挿入し、消去し、またはアップデートするのに使われるステートメントなどのクエリ式でよい。コマンドは、論理的に、3つの部分からなる。任意選択のプロローグ任意選択のWITH句クエリまたはDMLステートメント例えば、Customerと呼ばれる型およびcustomersと命名されたCustomerインスタンスのコレクションがあると仮定する。以下はすべて、有効なコマンドである。6.1.1コマンドプロローグ任意選択のコマンドプロローグは、使用するべき名前空間のセットを指定することができる。これらについては、後で、名前空間に関するセクションにおいて説明する。6.1.2WITH句eSQLは、WITH句を、どのクエリまたはDMLステートメントへの接頭部としてもサポートする。WITH句の構文は、以下のようになる。注<common-table-expr>定義は、WITH句の中で先に定義されたcommon-table-expressionsを参照することができる。例えば、以下の定義が正当である。6.2クエリステートメントクエリステートメントは単に式である。6.3DMLステートメントDMLステートメントについては、次のセクションで説明する。7DMLeSQLは、insert、updateおよびdeleteというDMLステートメントをサポートする。7.1.1InserteSQLにおけるINSERTコマンドは、標準SQLにおけるINSERTステートメントと全く同様である。セマンティクス<container>は、データのどのコンテナも表す。EntitySetsは、最も論理的なコンテナである。<expr>/<query_expr>は、コンテナに挿入するべき値のセットを生じる最初の2つのケースにおけるマルチセットである。第3のケースVALUES句において、<expr>は、コンテナの要素型である。With句は、後続セクションにおいて定義される。With-parent句は、後続セクションにおいて記述される。例注eSQLのINSERT..VALUESステートメントは、T-SQLとはわずかに異なる。1つには、値の周りの括弧は任意選択であり、存在する場合、ローコンストラクタとは解釈されない。T-SQLとは異なり、eSQLは、Insertステートメント用にカラムリストを指定させない。7.1.2DeleteeSQLにおけるDELETEコマンドは、標準SQLにおけるDELETEステートメントと同様である。セマンティクス<container>は、データのどのコンテナも表す。EntitySetsは、最も論理的なコンテナである。<expr>は、すなわちブール値型の述部である。<with-parent-clause>は後で定義される。例注T-SQLとは異なり、eSQLにおけるDELETEステートメントは、多様なfrom句を認めない。代わりにサブクエリを使用する。7.1.3UpdateeSQLにおけるupdateステートメントは概念上、標準SQLにおけるupdateステートメントと同様である。セマンティクス<container>は、データのどのコンテナも表す。EntitySetsは、最も論理的なコンテナである。<expr>は、すなわちブール値型の述部である。<field-expr>は、l値の式であり、すなわちカラム参照、カラムのプロパティへの参照、またはこのようなプロパティを伴うTREAT式でよい。<with-parent-clause>は後で定義される。例注T-SQLとは異なり、eSQLにおけるUPDATEステートメントは、多様なfrom句を認めない。代わりにサブクエリを使用する。属性は、UPDATEステートメント中で多くとも一度だけ変更してよい。7.2EDM関係のためのDMLEDMは、関係インスタンスのコレクションとして、RelationshipSetの概念を導入する。関連づけおよび構成関係は両方とも、こうしたRelationshipSetを介してモデル化される。7.2.1関連づけ一般的な使用形態では、最初にエンティティのインスタンスを作成し、次いで、RelationshipSetに挿入することによって、エンティティの間に関係を作成する。以下の例では、実際にDMLをこのようなrelationshipsetに入れる。2つのエンティティ型OrderおよびCustomerOrdersおよびCustomersというEntitySetを有するを仮定する。さらに、こうした2つのエンティティの間にOrderCustomer関係を、およびrelationshipsetとしてOrderCustomerSetを仮定する。7.2.2構成構成に対応するRelationshipSetは、同様にアップデート可能である。最初に、親エンティティインスタンスを作成しなければならない。ただし、関連づけとは異なり、子インスタンスを作成する別個のステップはない。構成RelationshipSetへの挿入を行うと、自動的に子インスタンスを作成することになる。この例は、以下を含む。注:特別なwithparentas句が、構成を修正する。8eSQL雑則8.1再帰クエリeSQLは、テーブル定義paranthesizedExprにそれ自体を参照させることによって、再帰クエリのサポートを可能にする。例えば、以下のようになる。eSQLは、再帰の終了については保証しない。8.2EDM関係のサポートEDMは、SQLにおけるリンクテーブルと論理的に同等であるRelationshipSetの概念を導入する。他のコレクションと全く同じように、RelationshipSetを照会することができる。さらに、eSQLは、関係を介したより簡単なナビゲーションのためのナビゲーションヘルパをサポートする。ナビゲーションヘルパの一般的な形は、以下のようになる。上記において、OrderCustomerは、関係の名前であり、Customerは、関係の顧客側の名前である。8.3コメントeSQLは、T-SQLスタイルのコメントをサポートする。eSQLのコメントは、以下の形でよい。コメントは、空白キャラクタが予想されるどの場所でも使うことができる。ダブルハイフンスタイルのコメントキャラクタは、実行されるべきコードと同じローでも、独立したローでも使うことができる。ダブルハイフンからローの末尾までのものはすべて、コメントの一部である。...フォワードスラッシュアスタリスクキャラクタペア。こうしたコメントキャラクタは、実行されるべきコードと同じロー、独立したロー、または実行可能コードの中でも使うことができる。開きコメントペアから閉じコメントペアまでのものはすべて、コメントの一部と見なされる。こうしたコメントは、複数ローに渡る。9eSQLの名前解決および他の規則9.1識別子eSQLにおける識別子は、式エイリアス、変数参照、オブジェクトのプロパティ、関数などを表すのに使われる。eSQLにおける識別子には、2種類ある。9.1.1単純な識別子単純な識別子とは、単なる一連の英数字およびunderRankキャラクタである。この識別子の第1キャラクタは、アルファベット、すなわちa~zまたはA~Zでなければならない。9.1.2引用識別子引用識別子は、角括弧、または二重引用符で囲まれた一連の任意のキャラクタである。デフォルトの引用は、角括弧である。二重引用符は、eSQL用パーサが認める場合のみ、引用キャラクタとして使うことができる。これを制御するための正確なパーサオプションは、パーサの裁量に委ねられる。二重引用符は、引用キャラクタとして使うことができるとき、文字列リテラル用に使うことはできないことにも留意されたい。したがって、文字列リテラルは常に、単一引用符を使う必要がある。引用識別子は、普通は識別子において正当でないはずのキャラクタで識別子を指定することを可能にする。角括弧または引用の間の全キャラクタは、すべての空白も含めて、識別子と一部と見なされる。引用識別子は、以下のキャラクタを含んではならない。改行キャリッジリターンタブバックスペース[[]スタイルの引用のケースにおいてのみそれ以外の場合は、普通は不正キャラクタをもつプロパティ名を考案することができよう。普通はその言語の予約単語と見なされることになる識別子を指定するのに、引用識別子を使ってよい。例えば、Email型がfromと命名されたプロパティをもつ場合、角括弧を使って、予約単語fromとは区別することができよう。引用識別子は、dot演算子の右側で使ってよい。識別子の中に閉じ引用キャラクタと同じcharを使うためには、それを2回使う。例えば、以下のようになる。識別子abc]は、適切に回避される。9.2大文字/小文字の区別eSQLにおける全キーワードは、大文字/小文字を区別しないSQLと同様。識別子は、指定されるパーサオプションに応じて、大文字/小文字を区別しても、大文字/小文字を区別しなくてもよい。eSQLにおけるキーワードは、常に大文字/小文字を区別しない。9.3エイリアス作成規則eSQLは、必要とされるときは常に、クエリ中でエイリアスが指定されることを推奨する。エイリアスは、以下のコンストラクト用に必要とされる。rowコンストラクタのフィールドクエリ式のfrom句の中の項目クエリ式のselect句の中の項目クエリ式のgroupby句の中の項目join式への引数有効なエイリアスどの単純識別子も引用識別子も、有効なエイリアスである。エイリアス生成エイリアスが指定されない場合、eSQLは、いくつかの単純な規則に基づいてエイリアスを生成することを試みる。エイリアスが指定されていない式が、単純または引用識別子である場合、その識別子がエイリアスとして使われる。例えば、以下のようになる。式がより複雑な式であるが、その式の最後のコンポーネントが単純識別子である場合、その識別子がエイリアスとして使われる。例えば、以下のようになる。それ以外の場合、コンパイル時の例外が起こされる。9.4スコープ規則スコープ規則は、照会言語において特定の変数が見えるときを定義する。一部の式またはステートメントは、新しい名前を導入する。スコープ規則は、そうした名前をどこで使うことができるか、もう一方と同じ名前をもつ新しい宣言が、およびいつまたはどこでその先行物を隠すことができるか決定する。名前は、定義されるとき、スコープ内で定義されると言われる。スコープは、クエリの領域をカバーする。特定のスコープ内のすべての式または名前参照は、そのスコープ内部で定義された名前を見ることができる。スコープが始まる前と終わった後は、スコープ内部で定義された名前を参照することはできない。スコープはネストすることができる。言語の部分は、やはりスコープを導入する他の言語の式を含み得る領域をカバーする新しいスコープを導入する。スコープがネストされると、参照がその内部にある最も内側のスコープ内部で定義された名前ならびに任意の外部スコープ内で定義された任意の名前への参照を行うことができる。同じスコープ内部で定義されたどの2つのスコープも、兄弟スコープと見なされる。兄弟スコープ内部で定義された名前への参照を行うことはできない。外部スコープ内で宣言された名前と一致する名前が内部スコープ内部で宣言された場合、そのスコープ内部またはそのスコープ内部で宣言されたスコープ内部での参照は、新たに宣言された名前のみを指す。外部スコープ内の名前は隠される。同じスコープ内部でも、定義される前に名前を参照することはできない。グローバル名は、実行環境の一部として存在し得る。この名前は、一貫したコレクションまたは環境変数の名前を含み得る。こうした名前を含むスコープは、最も外側のスコープである。パラメータは、スコープ内にない。パラメータへの参照は特別な構文を含むので、パラメータの名前は、クエリ中の他の名前と衝突しない。9.4.1クエリ式クエリ式は、新しいスコープを導入する。from句の中で定義される名前が、出現順に、左から右へ、fromスコープに導入される。joinリスト中で、式は、リスト中で先に定義された名前を参照することができる。from句の中で識別される要素のパブリックプロパティフィールドなどは、fromスコープに追加されない。すなわち、こうしたプロパティは、エイリアスで修飾名を介して常に参照されなければならない。普通は、select式の全部分が、fromスコープ内部と見なされる。group-by句も、新しい兄弟スコープを導入する。各グループは、グループ中の要素のコレクションを指すグループ名を有し得る。各グループ化式も、グループスコープに新しい名前を導入することになる。さらに、ネスト集約または名前付きグループも、スコープに追加される。グループ化式自体は、fromスコープ内部にある。ただし、group-by句が使われると、selectリスト射影、having句およびorder-by句は、fromスコープではなくグループスコープ内部であると見なされる。集約は、特別な取扱いを受け、それについては以下で説明する。selectリストは、スコープに新しい名前を順序通りに導入することができる。右側の射影式は、左に射影される名前を参照することができる。orderby句は、selectリスト中で指定された名前エイリアスを参照することができる。select式内部での句の評価順が、名前がスコープに導入される順序を決定する。from句が最初に評価され、その後にwhere句、grouping句、having句、select句および最終的にorder-by句が続く。集約の扱いeSQLは、2つの形の集約、すなわちコレクションベースの集約およびグループベースの集約をサポートする。コレクションベースの集約は、eSQLにおいて好ましいコンストラクトであり、グループベースの集約は、単にSQL互換性のためにサポートされる。集約を解決するとき、eSQLは最初に、集約をコレクションベースの集約として取り扱うことを試みる。これが失敗した場合、eSQLは、基準であるべき集約入力をネスト集約に変換し、この新しい式の解決を試みる。例えば、以下のようになる。9.4.2Collectionフィルタ/プロジェクト演算コレクションフィルタ/プロジェクト演算子..、...、.および..用に、射影/述部用の新しいスコープが作成され、コレクションの各要素を表すために、名前itがスコープに暗黙的に追加される。さらに、簡単にするために、コレクション要素のパブリックメンバもスコープに追加されるが、これもやはり射影/述部の評価を持続するためである。例えば、は、部署名のマルチセットを生じ、各Departmentは、Nameプロパティをもつと仮定される。9.5名前空間eSQLは、例えば型名、エンティティセット、関数など、グローバル識別子に関する名前衝突の問題に対処するために、名前空間を導入する。eSQLにおける名前空間サポートは、CLRモデルと全く同様である。eSQLは、コマンドプロローグにおいて使うことができるusing句を提供する。2つの形のusing句、すなわち修飾名空間ここで、名前空間用には、比較的短いエイリアスが提供される、および非修飾名前空間が提供される。名前解決規則ローカルスコープ内で識別子を解決することができない場合、eSQLは、グローバルスコープすなわち名前空間内での名前の位置決めを試みる。eSQLは最初に、識別子接頭部を修飾名空間の1つと一致させることを試みる。一致がある場合、eSQLは、指定された名前空間内での、識別子の残りの解決を試みる。一致が見つからない場合、例外が起こされる。eSQLは次いで、識別子用の、プロローグ内で指定されたすべての非修飾名前空間を調べることを試みる。識別子をちょうど1つの名前空間内に配置することができる場合、その場所が戻される。複数の名前空間がその識別子に関して一致する場合、例外が起こされる。識別子用に名前空間を識別することができない場合、eSQLは、次の外側のスコープCommand/Connectionオブジェクトに名前を渡す。CLRモデルとの違いCLRモデルとの1つの違いについては、付記しておく価値がある。CLRでは、部分修飾名空間を使うことができるが、eSQLではこれを認めていない。例えば、Cでは、以下は正当であるが、その相当物はeSQLにおいて正当ではない。ADO.NETの使用クエリ/DMLステートメントは、ADO.NETCommandを介して表現される。Commandは、Connectionオブジェクトに渡って構築することができる。Namespaceは、同様にCommandおよびConnectionオブジェクトの一部として指定することができる。eSQLがクエリ自体内部の識別子を解決することができない場合、外部の名前空間が調べられる同様の規則により。クエリ、CommandおよびConnectionオブジェクトは、名前空間のリングを形成し、ここで各リングが最初に調べられる。9.6ヌルリテラルおよび型の推論上で説明したように、ヌルリテラルは、eSQL型システムにおけるどの型とも互換性がある。ただし、正しく推論されるべきヌルリテラルの型に対しては、eSQLは、ヌルリテラルを使うことができる特定の制約を課す。以下の規則が該当する。型づけされたヌル型づけされたヌルすなわちcastnullasInt16を、どこでも使ってよい。この時点で型は知られているので、型の推論はそれ以上必要ない。浮動ヌルリテラル浮動ヌルリテラルは、以下のコンテキストにおいて使うことができる。cast/treat式への引数として。これは、型づけされたヌル式を生じられるために、推奨される機構である。メソッドまたは関数への引数。標準多重定義規則が該当する。多重定義を1つ選ぶことができない場合、コンパイルエラーが起こされる、-、,/などの算術式への引数の1つとして。他の引数群はヌルリテラルになることができない。そうでないと、型の推論は可能ではない。論理式and/or/notへの引数の1つとして。引数はすべて、boolean型であることが知られている。isnullまたはisnotnull式への引数として。式nullisnullおよびnullisnotnullは正当であるただし、愚かである/like式への引数の1つまたは複数として。引数はすべて、文字列であると予想される。名前付き型コンストラクタへの引数の1つまたは複数として。マルチセットコンストラクタへの引数の1つまたは複数として。ただし、マルチセットコンストラクタへの少なくとも1つの引数は、ヌルリテラル以外の式でなければならない。case式におけるthen/else式の1つまたは複数として。case式中のthen/else式の少なくとも1つは、ヌルリテラル以外の式でなければならない。浮動ヌルリテラルは、他のシナリオでは使うことができない。こうしたシナリオの一部網羅的ではなく、例示のためにのみ含まれるは、以下を含む。ローコンストラクタへの引数。注isnullおよびisnotnull式は、特殊であると見なされる。10eSQLの型システムeSQLは、エンティティデータモデルEDMのインスタンスに対して作用し、インスタンスを生じる。この文書では、EDMの詳細には踏み込まない。代わりに、いくつかの特別な興味項目について付記しておく。10.1ロー型ロー別名、タプルは、メンバシップによって構造的である。ローのコンストラクトは、それを構成する一連の型づけされた、名前付きメンバに依存する。ローとは、EDMのInlineTypeであり、識別をもたず、そこからの継承を行うことができない。メンバがそれぞれ等価である場合、同じロー型のインスタンスは、等価である。ローは、その構造的等価物を超える振舞いをもたない。ローは、共通言語ランタイムにおける等価物をもたない。クエリは、ローまたはローのコレクションを含むコンストラクトを結果として生じ得る。eSQLクエリとホスト言語の間のAPI束縛は、クエリの結果においてローがどのように実現されるかを定義することになる。ADO.NETでは、ローがDataRecordとして表出されることになる。10.2コレクションCollection型は、他のオブジェクトのゼロ以上のインスタンスを表す。EDMは、マルチセット、リストなどを含むいくつかの種類のコレクションをサポートする。この文書は、マルチセットのみを扱う。10.3ヌル可能性EDMでは、ヌル可能性は、プロパティに対する制約であり、Type自体のファセットではない。EDMにおけるすべての型は、ヌルになる可能性がある。eSQLにおけるnullリテラルは、EDMにおける他のすべての型と互換性があると見なされる。10.3.1ヌルのセマンティクスeSQLにおけるヌルは、TSqlにおけるNullとほとんど同様に振る舞う。具体的には、ヌルに対して作用するほとんどの式は、ヌルを戻す。こうした式は、以下を含む。算術式論理式型式以下の式は、その引数の1つまたは複数がヌルであるとき、ヌルを戻すことができない。コンストラクタ型、ロー、マルチセット関数/メソッドisnullおよびisnotnull演算子その他10.4暗黙の型昇格eSQLは、整数、浮動小数点および文字列などの基本要素データ型に対する加算、乗算および否定など、様々な共通バイナリおよび単項演算子を定義する。普通は、加算などのバイナリ演算子は、同じデータ型の2つのインスタンスに作用する。ただし、演算子が異なる型の2つのインスタンスに対して作用することをリクエストすることも、時には正当である。例えば、加算と整数および浮動小数点である。これを円滑に行うためには、2つのオペランドの一方が、他方の型に昇格されなければならない。概して、これは、最高の精度をもつ型であるので、コンバート中にデータの損失がない。いくつかの状況では、確実にデータ損失がないようにするために、両方のオペランドが第3の型に昇格される。以下のテーブルは、言語に組み込まれる暗黙の型昇格を列挙する。第1列は、ベース型を列挙し、第2列は、型に対して行うことができる最も直近の昇格を列挙する。例えば、Int16は、Int32に昇格することができる。ただし、Int32はInt64に昇格することができるので、Int32はInt64にも昇格することができる。列挙されていない、またはなしという昇格をもつものとして列挙されている型は、暗黙的に昇格することができない。浮動小数点へのInt16の加算を試みる際に正しい型昇格を知りたい場合は、Int16が本当に浮動小数点に昇格するのかどうかを調べるために、テーブルを見ればよいが、浮動小数点はInt16には昇格しない。したがって、Int16は、浮動小数点に昇格されるので、2つの浮動小数点は、合算することができる。もう少し複雑な例では、Int32が浮動小数点に加算される。Int32は浮動小数点に昇格せず、浮動小数点はInt32に昇格しないことに留意されたい。ただし、Int32および浮動小数点は両方とも、ダブル型に昇格する。したがって、両方のオペランドがダブル型に昇格され、2つのダブル型は合算される。10.5正当な型コンバート以下は、基本要素データ型の間の正当なコンバートのテーブルである。11ホスト言語の束縛ホスト言語の束縛は、eSQLと対話するためのAPIである。eSQLは、マイクロソフトのデータアクセスAPIを使って現在のTSQLがプログラマによってアクセスされるのとほとんど同じやり方で、ホストプログラミング言語からAPIを介してアクセスされる照会言語として設計されている。概念的に、照会されているデータは、ホスト言語のドメイン外部のどこか、一般の言語演算子には見えないデータベースまたは他の一貫したストア、あるいはデータ構造内に存在する。eSQL用の好ましいデータアクセス機構は、ADO.NETである。ADO.NETにおけるコマンドオブジェクトは、CommandTextプロパティeSQLクエリ文字列にセットすることができるをもつ。コマンドオブジェクトに対するExecuteメソッドは、DataReaderIEnumeratorインターフェイスをサポートするを戻す。DataReaderは論理的に、DataRecordのコレクションであり、ここでDataRecordは、結果の単一要素を表す。12文法12.1コマンド12.2DML12.3クエリ式付表B:例示的な照会言語に対する拡張のための詳細な仕様1概観1.1目的この文書は、WinFS/CDPのためのeSQL照会言語に対する拡張関数について詳述する。eSQLは、関数呼出しのサポートを提供するが、それ自体に対するいかなる組込み関数も提供しない。、-などの演算子は、異なるように扱われ、言語自体に焼かれるものと仮定される。T-SQLおよびSQLの他のダイアレクトのような言語のユーザは、豊富な1組の組込み関数に慣れている。この文書の目的は、こうした要件に対処するように、eSQLをどのように拡張することができるかを記述することである。根本的に、eSQLにおける全関数は同じように取り扱われる。すなわち、ユーザ定義関数として、eSQLは、型を含む名前空間の使用と同様の様式で関数の異なるコンテナを定義するのに、名前空間を使う。プロバイダは、関連づけられた関数の組を有するこのような名前空間を定義し、それらをeSQLのユーザへのメタデータサービスを介して使用可能にすることができる。この文書では、SQLサーバおよびWinFSから使用可能な特定の組込み関数の組と、それらを使用可能にするための名前空間とに焦点を当てる。この文書では、この関数リストをプロバイダがどのようにして供給するか、およびこれらがシステムの残りによってどのようにして搭載されるかという問題には対処しない。こうした拡張は、それらをサポートするストレージプロバイダによってグループ化される。プロバイダのリストは以下のようになる。1.SQLサーバ20002.SQLサーバ2005:このプロバイダは、SQL2000の関数をすべてサポートする。3.WinFS:このプロバイダは、SQL2005およびSQL2000の関数をすべてサポートする。以下のテーブルは、機能について要約している。上のテーブルにおいて部分サポートと列挙されているケースに関しては、文書の以降のセクションを参照されたい。1.2拡張機構拡張機能を可能にする、eSQL拡張機構についての詳細は、eSQL言語仕様のセクション9.4名前空間に見ることができる。部分的名前空間はサポートされないことに留意されたい。より詳しくは、eSQL言語仕様を参照されたい。名前空間は、eSQLのusing句を使ってクエリにインポートすることができる。あるいは、1つまたは複数の名前空間を、例えば、Command/Connectionオブジェクトの一部として、クエリの制約外部で指定することができる。1.3拡張の実行クエリの実行拡張関数を含むは、常にストアで起こる。さらに、別段の記載がない限り、拡張関数のセマンティクスは、サーバと同じであると予想される。eSQLパーサは、関数呼出しの署名を検証するが、どの意味認証も基底ストアで実施される。2詳細な設計2.1集約集約関数は、値のマルチセットに対する算出を実施し、単一値を戻す。COUNTという例外はあるが、集約関数は、ヌル値を無視する。以下の使用可能なSQL関数がサポートされる。集約関数は、値を計算するとき、ヌル値を無視するcountは除く。countはサポートされないことにも留意されたい。集約関数は、述部および射影定義中で使うことができる。さらに、集約は、等式をサポートするデータ型に対するdistinctモードをサポートするSQLサポートと同様に。こうした関数の戻り型は、関数がそれに対して実行されるプロパティの型に基づく。したがって、例えば、avgintは、intを戻すことになる。これは、2、3の平均が2.5ではなく2を戻すことになると予想することはできない。これを回避するために、ユーザは、プロパティを、正しい精度をもつ型、例えばavgcastintPropertyasdoubleに明示的にキャストする必要がある。2.1.1名前空間こうした関数は、System.Data.Tsql.Aggregates名前空間内にある。2.1.2例2.1.3サポートされるプラットフォームSQL2000、SQL2005およびWinFS上でサポートされる。2.2文字列関数こうしたスカラー関数は、文字列入力値に対して演算を実施し、文字列または数値を戻す。全文字列関数は、1から始まるインデックスをもつことに留意されたい。2.2.1名前空間こうした関数は、System.Data.Tsql.String名前空間内にある。2.2.2例2.2.3サポートされるプラットフォームSQL2000、SQL2005およびWinFS上でサポートされる。2.3数学関数こうしたスカラー関数は、共通の1組の数学演算を実施する。2.3.1名前空間こうした関数は、System.Data.TSql.Math名前空間にある。2.3.2例2.3.3サポートされるプラットフォームSQL2000、SQL2005およびWinFS上でサポートされる。2.4日付関数こうしたスカラー関数は、日時入力値に対して演算を実施し、文字列、数値、または日時値を戻す。2.4.1名前空間こうした関数は、System.Data.TSql.Date名前空間にある。2.4.2例datepartは、文字列リテラルとして指定される必要がある。2.4.3サポートされるプラットフォームSQL2000、SQL2005およびWinFS上でサポートされる。2.5システム関数System.Data.TSql.System名前空間に存在するプラットフォームによって変わる1組のシステム関数がある。以下のテーブルが、こうした関数を要約している。以下のセクションでは、特定の関数についてより詳細に述べる。2.5.1SoundexおよびDifferenceSoundex関数は、T-SQLのSoundex関数に対応し、同じように聞こえる単語または名前を見つけるために、英字列を4キャラクタコードにコンバートするのに使われる。コードの第1キャラクタは、character_expressionの第1キャラクタであり、コードの第2から第4キャラクタは数字である。character_expression中の母音は、文字列の第1文字でない限り無視される。文字列関数はネストすることができる。これに対する構文は以下のようになる。Differenceは、2つのキャラクタ式のSOUNDEX値の間の違いを整数として戻す。この関数は、例えば名前を発音によってソートする際に有用であり得る。これに対する構文は以下のようになる。以下は、クエリ中でsoundexおよびdifferenceを使った例である。2.5.1.1サポートされるプラットフォームSQL2000、SQL2005およびWinFS上でサポートされる。2.5.2DatalengthDatalength関数は、プロパティのサイズをintとして戻すのに使われる。この関数は、SQLのdatalength関数に対応する。これに対する構文は以下のようになる。プロパティが値をもたないすなわち、ヌルであるケースにおいて、戻り値は、ヌルではなく、ゼロとなる。これは、SQLのdatalength関数が作用するやり方とは対照的である。以下は、クエリ中でdatalengthを使った例である。2.5.2.1サポートされるプラットフォームSQL2005およびWinFS上でサポートされる。2.6XML関数XMLクエリのサポートは、拡張関数を介して有効にされる。以下の拡張関数が提供される。2.6.1名前空間こうした関数は、System.Data.TSql.XML名前空間にある。2.6.2例2.6.3サポートされるプラットフォームSQL2005およびWinFS上でサポートされる。2.7WinFS関数2.7.1フルテキストクエリWinFSのみWinFSは、フルテキスト検索のために、2つのTVF、すなわちContainsおよびFreeText各々に対して2つの多重定義をサポートしなければならない。こうした関数は、MSSearchにおける機能にマップされる。こうした関数はすべて、各々が2つのフィールドを有するローのマルチセットを戻す。ItemIdフィールドはGuidであり、完全テキスト述部に一致した項目のidである。Rankフィールドは、その項目に対するRankである。結果は、Rankによって格納されず、明示的orderbyが、これを遂行するためにクエリ中で使われなければならない。ContainsContainsは、MSSearchのContains述部をモデル化する。containsQuery引数は、MSSearchのContains述部によって指定された構文に準拠しなければならない。propName引数は、WinFSスキーマインストール中に検索プロパティを指定するのに使われる構文に準拠しなければならない。FreeTextFreeTextは、MSSearchのFreeText述部をモデル化する。freeTextQuery引数は、MSSearchのFreeText述部によって指定された構文に準拠しなければならない。propName引数は、WinFSスキーマインストール中に検索プロパティを指定するのに使われる構文に準拠しなければならない。注eSQLは、引数のどれも解釈しない。引数が文字列でなければならないことだけを気にかける。2.7.1.1仕組みスキーマのインストールWinFSスキーマがインストールされるとき、どの検索プロパティも識別され、クライアントアセンブリに格納される。プロパティ仕様に関する構文は、以下のようになる。クエリ処理上で言及したように、eSQLは、引数をこうした関数に解釈しない。より詳細には、クエリを解析するWinFSランタイムは、パラメータが文字列であることを確かめるため以外のいかなるチェックも実施しない。WinFSプロバイダは、propertyName引数を、おそらくSqlGenの一部として解釈し、クライアントアセンブリ中で適切なプロパティidをルックアップし、次いでストア中の等価なTVFコールに翻訳する責任がある。ストアTVFは、以下のように見える署名をもつことになる。2.7.1.2名前空間こうした関数は、System.Data.TSql.WinFS名前空間にある。2.7.1.3例以下の例は、こうした関数の使用を示す2.7.1.4サポートされるプラットフォームWinFS上でサポートされる。2.7.2SumStringWinFSのみSumString集約SumStringと呼ばれるストアUDFに対応するは、文字列のコレクションの内容を、区切り文字をもつ単一文字列に連結する能力を提供する。これは、単一テキストフィールドにおける、メッセージ参加者のToリストの表示を含むいくつかのAppシナリオにとって有用である。このeSQL拡張は、count、sum、maxなどの同様の集約関数であり、Group演算の結果として、InlineObjectCollection、ItemFragmentCollection、ExtensionCollectionおよびどの文字列プロパティに対する文字列プロパティにも適用することができる。この集約に関する構文は、以下のようになる。ここで、コレクションは、文字列のコレクションでなければならない。2.7.2.1名前空間こうした関数は、System.Data.TSql.WinFS名前空間にある。2.7.2.2例以下は、クエリ中でSumStringを使った例である。2.7.2.3サポートされるプラットフォームWinFS上でサポートされる。2.7.3NormalizeDigitsWinFSのみNormalizeDigits集約normalizedigitsと呼ばれるストアUDFに対応するは、ウィンドウズシェルソートと同様の形式で、文字列をソートする能力を提供する。この関数に関する構文は、以下のようになる。2.7.3.1名前空間こうした関数は、System.Data.TSql.WinFS名前空間にある。2.7.3.2例以下は、クエリ中でSumStringを使った例である。2.7.3.3サポートされるプラットフォームWinFS上でサポートされる。3名前空間のローディングこの文書に記載される名前空間はすべて、SqlClientプロバイダに接続する際に自動的にロードされるべきである。明示的using句を使う必要があってはならない。4算出されたメソッドおよびプロパティeSQL照会言語は、O空間部分クラスに追加されるプロパティすなわち、非マッププロパティをクエリ中で参照することができるようにするための拡張機構をサポートする。こうしたプロパティは、eSQL式が属性を介してプロパティに関連づけられることを必要とする。このis式は次いで、プロパティがクエリ中で参照される場合はどこにでも置き換えられる。供給されるeSQL式は、他の算出されたプロパティおよびメソッド、Providerマニフェストにおいて指定される他のマップされたプロパティおよび他の関数を参照することができる。4.1算出されたプロパティSystem.Data.Objects.CalculatedAttributeは、クエリ中のプロパティの参照を可能にするために、クライアントクラス中で定義されるプロパティにのみマップされたプロパティではなく追加することができる。CLRプロパティの型は、eSQL式によって戻される型と一致しなければならない。式の戻り型がヌル可能型である場合、プロパティは、ヌル可能型として宣言されなければならない。この制約は、インフラストラクチャによって強制され、例外が投げられることになる。式の戻り型がコレクションである場合、PropertyはQuery<T>型でなければならない。Itemに関するItemSizeプロパティは、今日のスキーマに存在する算出されたプロパティの実際の例である。以下は、このプロパティを使った例である。上の式は、ストア側の関数に対応するプロバイダマニフェストにおける関数を指す。PrimaryEmailAddressは、スキーマから算出することができたプロパティの例であり、今やこれを介して、この機能をeSQLにより述部とし、射影することができる。このプロパティは、PrimaryKeywordで印付けられたPersonのEメールアドレスを戻し得る。以下のコードは、このPrimaryEmailAddressプロパティを、eSQLによりこのプロパティを照会することを可能にするように定義する方法を例示する。このプロパティは次いで、クエリ中で以下のように使うことができる。eSQL式に関する注:this接頭部は、インスタンス上の他のマップされた、または算出されたProperty/Methodを参照するのに使われなければならない。式は、実行時にのみ検証される。using句を含む、有効などのeSQL式も供給することができる。算出されたパラメータは、式の中でそれを参照するために、を伴って前置される必要がある。4.2算出されたメソッド算出されたプロパティと同様、部分クラス中で定義されるメソッドも、eSQLにおいて使用可能となるように有効にすることができる。System.Data.Objects.CalculatedAttributeは、プロパティへの追加と同様にして、メソッドに追加することができる。以下のセマンティクスおよび制約は、算出されたメソッドに当てはまる。一般的例えば、X<T>メソッドは現在、eSQLにおいてサポートされない。すなわち、一般的型パラメータは、eSQL式の中で使われない。メソッドへの可変数のパラメータを認めるparamsCキーワードは、算出されたメソッド中でサポートされない。算出されたメソッドの多相性は現在、サポートされない。現在、外部定義されたプライベートまたは内部算出されたメソッドに対するサポートはない。すなわち、APIが、プロパティ/メソッドへのアクセスをもたなければならない。概して、算出されたメソッドにおける再帰コールはサポートされない。パラメータ値型による、算出されたメソッドの多重定義は現在、サポートされない。メソッドの戻り型は、eSQL式によって戻される型と一致しなければならない。○式の戻り型がヌル可能型の場合、メソッドは、ヌル可能型を戻す際に宣言されなければならない。この制約は、インフラストラクチャによって強制され、例外が投げられることになる。○式の戻り型がコレクションの場合、メソッドの戻り型はQuery<T>型でなければならない。新しい演算子を指定することによるメソッドの隠蔽はサポートされない。仮想メソッドはサポートされない。voidを戻すメソッドはサポートされない。メソッドパラメータは、式の中で参照するために接頭部を必要としない。以下は、算出されたメソッドを使った例である。ここでのシナリオは、図3に示したように、日付ビューによるOutlookのグループ化と同様の、親しさによるグループ化表示を生成することである。以下のコードは、他の場所で再利用することができるように、これをメソッドにカプセル化する。これは次いで、以下のように結果をグループ化するのに使うことができる。4.3CalculatedおよびCacluatedParameter属性System.Data.Objects.CalculatedAttributeは、以下のように定義される。この属性は、以下のプロパティを定義する。式:式プロパティは、値を射影する有効なeSQL式を含まなければならない。この値は次いで、別の式で使うことができる。名前付きパラメータを式の中でどのように指定するかに関するより詳細については、以下を参照されたい。System.Data.Objects.CalculatedParameterAttributeは、以下のように定義される。この属性は、以下のプロパティを定義する。名前:CalculatedAttributeのExpressionプロパティにおいて参照されるパラメータの名前。値:Nameプロパティによって定義されるパラメータの値。CalculatedAttributeにおいて定義されるNamedパラメータは、こうしたセマンティクスに続く。算出されたパラメータへの参照は、接頭部をもたなければならない。CalculatedParameterAttributeおよびCalculatedAttributeを定義する順序は、問題にならない。パラメータ名は、メソッドにおいてCalculatedParameterAttributeによって定義されるメソッドパラメータ名および他の名前付きパラメータに渡って一意でなければならない。算出されたプロパティに対して、式の中のどの名前付きパラメータも、CalculatedParameterAttributeによって定義されなければならない。以下の例は、上記属性クラスの使用を示す。"