マルチパラダイムプログラミング言語を設計します。パート2-PL / SQL、LINQ、GraphQLでのモデル構築の比較

最後の投稿で現代の情報システムのビジネスロジックには多くの要素が含まれており、その説明は本質的に宣言的であるという質問を提起しました。概念の構造、それらの間の関係、条件、規則、アプリケーションのある層から別の層に移動するときの概念の変換、統合、フィルタリング、集約など。私の観点からは、ドメインモデルのソフトウェア実装の利便性の点で、機能的およびオブジェクト指向のスタイルは論理的なスタイルより劣っています。論理的なスタイルは、概念間の関係をよりコンパクトで自然な方法で伝えます。したがって、私は、オブジェクト指向または機能パラダイムと論理パラダイムを組み合わせたハイブリッドプログラミング言語を作成するという目標を設定しました。さらに、論理コンポーネントは、ドメインモデル（その概念の構造）を記述するのに便利である必要があります。それらの間の関係と依存関係も同様です。



この投稿では、宣言的なプログラミングの要素（PL / SQL、MS LINQ、GraphQL）を含むいくつかの人気のある言語とテクノロジーについて話したいと思います。私は、宣言的プログラミングを使用してそれらの中でどのタスクが解決されるか、宣言的アプローチと必須アプローチがどれほど密接に絡み合っているか、それがどのような利点をもたらすか、そしてそれらからどのようなアイデアを学ぶことができるかを理解しようとします。

SQL手続き型拡張機能

この関連付けが長い間業界標準になっている分野、つまりデータアクセス言語から始めましょう。これらの中で最も有名なのは、SQL言語の手続き型拡張であるPL / SQLです。この言語を使用すると、必須（変数、制御ステートメント、関数、オブジェクト）と宣言的プログラミングスタイル（SQL式）の両方を使用して、リレーショナルデータベース内のデータを処理できます。 SQLクエリを使用して、必要なデータに必要なプロパティ（必要なフィールド、それらを取得するテーブル、それらの相互関係、準拠する必要のある制約、集計方法など）を記述できます。また、データベースサーバーは独自にクエリ実行計画を作成し、指定された条件を満たすすべての可能なフィールドのセットを見つけます。 PL / SQLの手続き部分では、これらのタスクを実装できます宣言形式で表現するのは困難または不可能です。クエリの結果をループで処理し、任意の計算を実行し、関数とクラスでコードを構造化します。



言語の手続き的および宣言的コンポーネントは緊密に統合されています。 PL / SQLを使用すると、関数を宣言し、関数内でクエリを実行して結果を返し、クエリ内で関数を使用して、テーブルフィールドの値を引数として渡すことができます。カーソルを使用してクエリの結果にアクセスし、取得したすべてのレコードを強制的にループすることができます。カーソルを使用すると、テーブルの内容をより細かく制御でき、SQLのみを使用するよりもはるかに複雑なデータ処理ロジックを実装できます。カーソルをカーソル変数に割り当てて、関数、プロシージャ、さらにはクライアントアプリケーションに引数として渡すことができます。要求コード自体は、一連の必須コマンドによって動的に生成できます。いくつかの調整を使用して、プロシージャとクエリを組み合わせることで、再帰的なクエリを実装できます。 PL / SQLには、テーブルフィールドの複合データ型を宣言し、それらにメソッドを含め、継承を通じてクラスを作成できるオブジェクト指向の機能もあります。



PL / SQLを使用すると、データベースサーバー側でビジネスロジックを実装できます。さらに、ドメインモデルの実装は、その説明に非常に近くなります。ドメインモデルの基本概念は、リレーショナルデータモデルにマッピングされます。概念は、テーブル、属性、つまりそれらのフィールドに対応します。フィールド値の制約は、テーブルの説明に埋め込むことができます。また、他のテーブルとの関係は、外部キーを使用して設定できます。基本概念に基づいて構築された抽象的な概念は、ビューに対応します。これらは、他のビューの構築など、テーブルとともにクエリで使用できます。ビューはクエリに基づいて構築されているため、SQLの能力と柔軟性を最大限に活用できます。この方法では、テーブルとビューから、かなり複雑でマルチレベルのドメインモデルを完全に宣言型で構築できます。また、宣言スタイルにうまく適合しないものはすべて、プロシージャと関数を使用して実装できます。



主な問題は、PL / SQLコードがDBサーバー側で排他的に実行されることです。これにより、このようなソリューションのスケーリングが困難になります。さらに、結果のモデルはリレーショナルデータベースに厳密にバインドされ、他のソースからのデータをモデルに含めるのは問題があります。

言語統合クエリ

言語統合クエリ（LINQ）は、.NETプラットフォームの一般的なコンポーネントであり、メインのオブジェクト指向の言語コードにSQLクエリ式を自然に含めることができます。データベースサーバー側でSQLに必須のパラダイムを追加するPL / SQLとは対照的に、LINQはSQLをアプリケーションレベルにもたらします。このおかげで、LINQのクエリを使用して、リレーショナルデータベースからだけでなく、オブジェクトのコレクション、XMLドキュメント、およびその他のLINQクエリからもデータを取得できます。



LINQアーキテクチャは非常に柔軟性があり、クエリ定義はOOPモデルと緊密に統合されています。 LINQを使用すると、新しいデータソースにアクセスするための独自のプロバイダーを作成できます。クエリを実行する独自の方法を設定し、たとえば、クエリのLINQ式ツリーを目的のデータソースへのクエリに変換することもできます。アプリケーションコードで定義されているラムダ式と関数をリクエスト本文で使用できます。確かに、LINQ to SQLの場合、クエリはデータベースサーバー側で実行され、これらの関数は使用できませんが、代わりにストアドプロシージャを使用できます。リクエストは第1レベルの言語の本質であり、通常のオブジェクトと同じように操作できます。コンパイラは、クエリ結果のタイプを自動的に推測し、明示的に宣言されていない場合でも適切なクラスを生成できます。



LINQを使用して、クエリのセットとしてドメインモデルを構築してみましょう。元のファクトは、アプリケーション側のリストまたはデータベース側のテーブルに配置でき、抽象的な概念はLINQクエリとしてフォーマットできます。LINQを使用すると、FROM句で指定することにより、他のクエリに基づいてクエリを作成できます。これにより、既存のコンセプトに基づいて新しいコンセプトを構築できます。SELECTセクションのフィールドは、コンセプトの属性に対応します。また、WHEREセクションには、概念間の依存関係が含まれます。以前の出版物からの請求書の例は次のようになります。



アカウントと顧客情報を持つオブジェクトをリストに配置します。

List<Bill> bills = new List<Bill>() { ... };
List<Client> clients = new List<Client>() { ... };

次に、未払いの請求書と債務者を取得するためのクエリを作成しましょう。

IEnumerable<Bill> unpaidBillsQuery =
from bill in bills
where bill.AmountToPay > bill.AmountPaid 
select bill;
IEnumerable<Client> debtorsQuery =
from bill in unpaidBillsQuery 
join client in clients on bill.ClientId equals client.ClientId
select client;

LINQで実装されたドメインモデルは、かなり奇妙な形をとっています。複数のプログラミングスタイルが関係しています。モデルのトップレベルには、必須のセマンティクスがあります。これは、オブジェクト変換のチェーンとして表すことができ、コレクションの上にオブジェクトのコレクションを構築します。クエリオブジェクトは、OOPワールドの要素です。それらを作成して変数に割り当てる必要があり、それらへの参照を他の要求に渡す必要があります。中間レベルでは、クエリオブジェクトは、クエリを実行するためのプロシージャを実装します。これは、ラムダ式で機能的にカスタマイズされ、SELECTセクションで結果構造を形成し、WHERE句のエントリを除外できます。内部レベルは、論理的なセマンティクスを持ち、リレーショナル代数に基づくクエリ実行プロシージャによって表されます。



LINQではドメインモデルを記述できましたが、SQL構文は主にデータのフェッチと操作を目的としています。モデリングに役立ついくつかの構成が欠けています。PL / SQLで基本概念の構造がテーブルとビューの形式で非常に明確に表現されている場合、LINQではOOPコードにレンダリングされることがわかりました。さらに、テーブルとビューは名前で参照できますが、LINQクエリは必須のスタイルで参照できます。さらに、SQLはリレーショナルモデルによって制限され、グラフまたはツリーの形式で構造を操作する場合の機能が制限されます。

リレーショナルモデルとロジックプログラミングの類似点

モデルのSQLとPrologの実装には類似点があることがわかります。 SQLでは、テーブルまたはその他のビューに基づいてビューを作成し、Prologでは、事実とルールに基づいてルールを作成します。 SQLでは、テーブルはフィールドのコレクションであり、Prologの述語は属性のコレクションです。 SQLでは、テーブルフィールド間の依存関係をWHERE句の式として指定し、Prologでは、述語と述語属性を相互にリンクするブール変数を使用して指定します。どちらの場合も、ソリューションの仕様を宣言的に設定し、組み込みのクエリ実行エンジンがSQLで見つかったエントリまたはPrologの変数の可能な値を返します。



この類似性は偶然ではありません。 SQLの理論的基盤-リレーショナル代数はロジックプログラミングと並行して開発されましたが、後に理論的な関係が明らかになりました。それらは共通の数学的基礎を持っています-一次論理。リレーショナルデータモデルは、データテーブル間の関係、論理プログラミング、つまりステートメント間の関係を構築するためのルールを記述します。両方の理論は異なる用語を使用し、異なる分野で適用され、並行して開発されましたが、それらは共通の数学的基礎を持っていました。



厳密に言えば、リレーショナル計算は、表形式のデータを処理するための1次ロジックの適応です。この質問については、ここで詳しく説明します。..。つまり、リレーショナル代数の任意の式（任意のSQLクエリ）を1次ロジックの式に再定式化してから、Prologに実装できます。しかし、その逆はありません。リレーショナル計算は、1次ロジックのサブセットです。これは、一次論理で許容されるいくつかの種類のステートメントについて、関係代数で類似性を見つけることができないことを意味します。たとえば、SQLの再帰クエリの機能は非常に制限されており、遷移関係の構築も常に利用できるとは限りません。ターゲットの分離や拒否などの否定などのプロローグ操作は、SQLで実装するのがはるかに困難です。 Prologの柔軟な構文により、複雑なネストされた構造をより柔軟に操作でき、それらの構造のパターンマッチング操作がサポートされます。これにより、ツリーやグラフなどの複雑なデータ構造を操作するときに便利です。



しかし、あなたはすべてにお金を払わなければなりません。リレーショナルデータベースに組み込まれているクエリ実行アルゴリズムは、Prologの推論アルゴリズムよりも単純で汎用性が低くなっています。これにより、それらを最適化し、はるかに高いパフォーマンスを実現できます。 Prologは、リレーショナルデータベースの数百万行を迅速に処理することもできません。さらに、Prologの推論アルゴリズムは、プログラム実行の終了をまったく保証しません。一部のステートメントの出力は、無限の再帰につながる可能性があります。



ちなみに、データベースと論理プログラミングの交差点には、推論データベースやルールの言語、それらへのクエリデータログなどのテクノロジーもあります。テーブルのレコードの代わりに、推論データベースは論理的なスタイルで大量の事実とルールを保存します。DatalogはPrologのように見えますが、単一のファクトではなく、セットに結合されたファクトの操作に重点を置いています。さらに、大量のデータを高速に処理するための推論アルゴリズムを最適化するために、その中の1次ロジックの一部の機能がカットされました。したがって、論理言語の表現力の低い構文にも利点があります。

APIレイヤー記述への宣言的アプローチ

SQLは、モデル構築をデータアクセスレイヤーにバインドします。しかし、宣言的プログラミングは、アプリケーションの反対側、つまりAPI層で活発に開発されています。その特徴は、リクエストの構造に関する情報を、このAPIを使用するユーザーが利用できるようにする必要があることです。リクエストとレスポンスの構造を正式に説明するのは良い形です。したがって、この記述をアプリケーションコードと同期させ、たとえば、それに基づいて要求クラスと応答クラスを生成することが望まれます。次に、リクエストを処理するためのロジックを作成する必要があります。



GraphQLは、この従来のアプローチをはるかに超えたAPIを構築するためのフレームワークであり、クエリ言語だけでなく、クエリ実行環境も提供します。コードを生成する必要はありません。ランタイムはとにかくリクエストの説明を理解します。GraphQLを使用してAPIを実装するには、次のものが必要です。

1. 要求と応答の一部であるアプリケーションのデータタイプ（オブジェクト）を記述します。
2. 要求と応答の構造を説明します。
3. フィールドの値を取得するためにオブジェクトを作成するロジックを実装する関数を実装します。

データタイプは、オブジェクトフィールドの説明です。スカラー型、リスト、列挙、ネストされた型への参照などの型がサポートされています。タイプフィールドには他のタイプへの参照を含めることができるため、データスキーマ全体をグラフとして表すことができます。要求は、APIから要求されたデータ構造の説明です。リクエストの説明には、必要なオブジェクト、それらのフィールド、および入力属性のリストが含まれています。各データタイプとその各フィールドは、リゾルバ関数に関連付ける必要があります。タイプ（オブジェクト）リゾルバーはそのオブジェクトを取得するためのアルゴリズムを記述し、フィールドリゾルバーはオブジェクトフィールド値を記述します。これらは、機能言語またはオブジェクト指向言語の1つで機能を表します。 GraphQLランタイムは、要求を受信し、必要なデータタイプを決定し、ネストされたオブジェクトのチェーンに沿ったものを含め、それらのリゾルバーを呼び出します。応答オブジェクトを収集します。



GraphQLは、宣言型データスキーマ記述を、それらを取得するための必須または機能アルゴリズムと組み合わせます。データスキーマは明示的に記述されており、アプリケーションの中心です。多くの人が、データソーススキーマを複製しないが、ドメインモデルに準拠するデータスキーマを作成することをお勧めします。これにより、GraphQLは、異種のデータソースを統合するための非常に人気のあるソリューションになります。



したがって、GraphQL言語を使用すると、ドメインモデルをかなり明確な方法で表現し、それを他のコードと区別して、モデルとその実装を近づけることができます。残念ながら、言語の宣言コンポーネントは、データタイプの構成の記述のみに制限されています。モデルの要素間の他のすべての関係は、リゾルバーを使用して実装する必要があります。一方では、リゾルバを使用すると、開発者はオブジェクトのデータを取得する任意の方法と、それらの間の任意の関係を独立して実装できます。ただし、その一方で、たとえば、キーによるレコードへのアクセスよりも複雑なクエリオプションの実装を試みる必要があります。一方、GraphQLのデータスキーマは、APIレイヤーとデータアクセスレイヤーの関係を明確に示しています。ただし、一方で、データスキーマがバインドされる主要なレイヤーはAPIレイヤーです。データスキーマの内容はそれに合わせて調整されます。リクエストの処理に関与していないエンティティは含まれません。データ記述言語GraphQLの表現力は、SQLやPrologなどの本格的な宣言言語より劣っていますが、このフレームワークの人気は、宣言モデル記述のツールが最新のプログラミング言語の一部である可能性があり、その一部である必要があることを示しています。

まとめます

PL / SQLは、ドメインモデルをテーブルとビューの形式で記述することと、それを操作するロジックの両方に便利な言語です。宣言的および手続き的コンポーネントは緊密に統合され、補完的です。主な問題は、この言語がデータの保存場所と密接に関連しており、データベースサーバー側でのみ実行でき、クエリ実行ロジックがリレーショナルデータモデルに制限されていることです。



アプリケーション側では、LINQやGraphQLなどのテクノロジーを使用して、モデルを宣言形式で記述することができます。 GraphQLデータスキーマを使用すると、ドメインモデルの構造、その概念のネストを明確かつ非常に明確に説明できます。また、ランタイムは必要なオブジェクトを自動的に収集することができます。残念ながら、ネストを除く、概念間の他のすべての関係と接続は、リゾルバー関数のレイヤーに実装する必要があります。 LINQには反対の長所と短所があります。 SQLの柔軟な構文により、概念間の関係をより柔軟に記述できます。しかし、要求の外では、宣言性は終わり、要求オブジェクトはOOPの世界の要素です。それらは作成され、変数に割り当てられ、必須のスタイルで使用される必要があります。



LINQとGraphQLの両方の利点を組み合わせたいと思います。そのため、GraphQLのように概念の構造の記述が明確になり、SQLのように論理に基づいてそれらの間の関係を設定できました。また、概念の定義をクラスとして名前で直接利用できるようにするため、オブジェクトを明示的に作成したり、変数に割り当てたり、参照を渡したりする必要はありませ



ん。ドメインモデルの記述言語を開発することから、このようなソリューションの設計を開始します。しかし、このためには、知識表現の既存の言語の概要を作成する必要があります。したがって、次の出版物では、ロジックプログラミング、RDF、OWL、およびフレームロジック言語について説明し、それらを比較して、予測されるビジネスロジック記述言語にとって興味深い機能を見つけようと思います。



Habréに関するすべての出版物のリリースを待ちたくない人のために、リンクで利用可能な英語の科学的なスタイルの全文があります：半構造化データ処理のためのハイブリッドオントロジー指向プログラミング。



以前の出版物へのリンク：

マルチパラダイムプログラミング言語の設計。パート1-それは何のためですか？