マルチパラダイムプログラミング言語を設計します。パート6-SQLからの借用

宣言型論理スタイルとオブジェクト指向および関数型スタイルを組み合わせたマルチパラダイムプログラミング言語の作成についての話を続けます。これは、半構造化データを操作し、異なるソースからのデータを統合するときに便利です。言語は、互いに緊密に統合された2つのコンポーネントで構成されます。宣言型コンポーネントはドメインモデルの記述を担当し、命令型または関数型コンポーネントはモデルを操作して計算するためのアルゴリズムの記述を担当します。



ハイブリッド言語モデリングコンポーネントは、論理的な関係によって接続されたオブジェクトという概念のセットです。継承や概念間の関係の定義など、概念を定義する主な方法について話すことができました。また、否定演算子や高階述語論理のセマンティクスなど、論理プログラミングの微妙な違いについても説明します。このトピックに関する出版物の完全なリストは、この記事の最後にあります。



データを扱う分野では、議論の余地のないリーダーはSQL言語です。集約など、実際には非常に便利であることが判明したその機能の一部は、後で論理プログラミングに移行されました。したがって、モデリングコンポーネントについては、SQLから可能な限り借用すると便利です。この記事では、ネストされたクエリ、外部結合、および集計を概念定義に埋め込む方法を紹介します。また、論理検索に頼らずにアルゴリズムスタイルでオブジェクト（エンティティ）を生成する関数を使用して説明される、別のタイプの概念についても説明します。また、SQL UNNEST操作との類推により、オブジェクトの配列を親の概念として使用する方法を示します。 コレクションをテーブル形式に変換し、FROM句で他のテーブルに結合できるようにします 。

概念の匿名の定義

SQLの世界では、ネストされたクエリは、メインクエリでさらに処理するために中間データを取得する必要がある場合によく使用されるツールです。モデリングコンポーネントは、中間データを取得する方法を別の概念として形式化できるため、そのような緊急の必要性はありません。ただし、ネストされた概念定義が便利な場合があります。



場合によっては、概念を少し変更し、個々の属性を選択し、値を除外する必要があります。この変更が1つの場所でのみ必要な場合は、一意の名前で別の概念を作成することは意味がありません。この状況は、概念がexists、 find、または などの関数への引数である場合によく発生し ます。findOneは、概念の推論可能性をチェックし、概念の最初のオブジェクト（エンティティ）のすべてまたはのみを検索します。ここでは、次のような関数の引数として頻繁に使用されている関数型プログラミング言語で匿名関数、とのアナロジーを描くことができ マップ、 検索、 フィルタなどは、



匿名の概念を定義するための構文を考えてみましょう。一般に、これは一般的な概念定義の構文に従いますが、属性リストと子概念名を省略できる場合もあります。匿名の概念が存在するための引数として使用される 場合、その場合、その名前と属性のリストは重要ではありません。少なくとも何らかの結果があることを確認するだけで十分です。 検索と findOne機能は、出力が全体のコンセプトとしてではなく、唯一の連想配列内の属性のセットとして使用されていない場合、概念名を必要としない場合があります。属性が指定されていない場合、デフォルトで継承メカニズムが使用され、属性は親の概念から継承されます。コンセプト名が指定されていない場合は、自動的に生成されます。



いくつかの例を使用して、上記で記述された内容を説明してみましょう。存在関数を使用して 、埋め込まれた概念の推論可能性または非推論可能性を確認できます。

concept freeExecutor is executor e where not exists (
    task t where t.executor = e.id and t.status in ('assigned', 'in process')
)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この例では、匿名の概念は次のとおりです。

(task t where t.executor = e.id and t.status in ('assigned', 'in process'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

実際には、タスクの概念のすべての属性を継承する概念 です。

(concept _unanimous_task_1 as task t where t.executor = e.id and t.status in ('assigned', 'in process'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

検索機能を 使用すると、概念のすべての値をリストとして返すことができ、属性に関連付けることができます：

concept customerOrdersThisYear is customer c with orders where c.orders = find(
    (id = o.id, status = o.status, createdDate = o.createdDate, total = o.total) 
    from order o where o.customerId = c.id and o.createdDate > '2021-01-01'
)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この例では、注文の概念の選択された属性を含むオブジェクトである注文のリストを使用して、顧客の概念を拡張し ます 。匿名概念の属性のリストを指定しましたが、その名前は省略されています。 セクションの条件 匿名の概念は、このケースでは、親または子会社概念の他の属性を含むことが c.id。匿名の概念の特徴は、そのようなすべての外部変数と属性は、ソリューションの検索を開始するときに必ず値に関連付けられている必要があることです。したがって、匿名の概念のオブジェクトは、顧客の概念のオブジェクトを見つけた後でのみ見つけることができます。



..。

外部接続

匿名の概念定義は、親概念を表すfromセクションでも使用でき ます。さらに、匿名の概念の定義では、それを他の概念と結び付ける条件のいくつかを転送することが可能であり、それは特別な効果をもたらします。これらの条件は、匿名の概念の解決策を見つける段階でチェックされ、子の概念の推論プロセスには影響しません。ここでは、匿名概念のwhereセクションの条件 とSQLのJOINONセクションの条件の類似点を描くことができ ます。



したがって、匿名の概念を使用して、左外部結合のSQLアナログを実装できます。これには3つのことが必要です。

1. まず、目的の親概念をそれに基づく匿名の概念に置き換え、他の親概念とのすべての接続をそれに転送します。
2. 第二に、この概念の推論の失敗が、子の概念全体の推論の自動的な失敗につながるべきではないことを指摘すること。これを行うには、この親の概念をオプションのキーワードでマークする必要があります。
3. そして第3に、子の概念のwhereセクションで、この匿名の概念に対する解決策があるかどうかを確認できます。

小さな例を見てみましょう：

concept taskAssignedTo (task = t, assignee = u, assigneeName) 
from task t, optional (user where id = t.assignedTo) u 
where assigneeName = if(defined(u), u.firstName + ' ' + u.lastName, 'Unassigned') 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

taskAssignedToコンセプトの属性に は、タスクのオブジェクト、そのエグゼキューター、および個別にエグゼキューターの名前が含まれます。親の概念は タスクと ユーザーであり、タスクにまだエグゼキューターがない場合、後者は空にすることができます。これは、オプションのキーワードが前に付いた匿名の概念定義でラップされてい ます。推論プロシージャは、最初にタスクコンセプトのオブジェクトを検索し 、次にユーザーに基づいて 匿名コンセプトを作成し、タスクコンセプトの assignedTo属性の特定の値に関連付け ます。キーワード オプションは、概念が失敗した場合、そのオブジェクトが特別な値UNDEFINEDに関連付けられることを推論ルーチンに 通知します。また、子の概念レベルで出力の結果を確認すると、assigneeName属性でデフォルト値を設定でき ます。オプションのキーワードが指定されていない場合、 匿名の概念を推測できないと、子の概念検索の現在のブランチが失敗します。これは、SQLの内部結合に類似しています。 匿名概念のwhere



句の条件に は、他の親概念の assignedTo属性が含まれているためです。 タスクの場合、コンセプトユーザーのオブジェクトの検索は、 タスクオブジェクトを値でバインドした後でのみ可能 です。それらを交換することはできません：

from optional (user where id = t.assignedTo) u, task t 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

初期段階ではt.assignedToの値は 不明であるため、匿名の概念の定義を作成することはできません。



SQLの場合、fromセクションのテーブルの順序 重要ではありません。Prologでは、ルール内の述語の順序によって、決定木をトラバースする順序が一意に決定されます。シミュレーションコンポーネントについても同じことが言えます。シミュレーションコンポーネントの出力ルールは、Prologで使用されるSLD解像度に基づいています。その中で、左側の概念のオブジェクトの出力の結果は、右側のオブジェクトの出力の制限を決定します。このため、残念ながら、右外部結合と完全外部結合の操作を同じ自然な方法で実装することはできません。右の親概念の一連の結果のカーディナリティは、左の概念の結果よりも大きくなる可能性があるため、右の概念から左への反対方向に出力する必要があります。残念ながら、選択した推論手順の特性により、言語の機能に制限が課せられます。ただし、完全な外部結合操作は、内部を結合することでエミュレートできます。左右の組合：

concept outerJoinRelation( 
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = c1,
concept2 = c2
) from <concept1Name> c1, <concept2Name> c2
where c1.<concept1Key> = c2.<concept2Key>;

concept outerJoinRelation(
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = c1,
concept2 = null
) from <concept1Name> c1
where not exists( <concept2Name> c2 where c1.<concept1Key> = c2.<concept2Key>);

concept outerJoinRelation(
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = null,
concept2 = c2
) from <concept2Name> c2
where not exists( <concept1Name> c1 where c1.<concept1Key> = c2.<concept2Key>);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この一般化された概念は、前の記事で説明した高階論理を使用して説明されてい ます。その定義は3つの部分に分かれています。最初のものは概念の交差点を見つけ、2番目は-左の概念が持っているオブジェクトと持っていないオブジェクト、そして3番目は-その逆です。各パーツの名前は同じであるため、それらの推論の結果が組み合わされます。

集約

集約は、関係代数と論理プログラミングの両方の不可欠な部分です。 SQLでは、 GROUP BY句を使用すると、同じキー値を持つ行をサマリー行にグループ化できます。重複する値を削除することができ、sum、 count、 min、 max、 avgなどの集計関数で一般的に使用され ます。..。行のグループごとに、集計関数はそのグループ内のすべての行に基づいて通常の値を返します。論理プログラミングでは、集約のセマンティクスはより複雑です。これは、SLDルールの再帰的定義の場合によっては、解決が無限ループに入り、完了できないという事実によるものです。失敗としての拒否の場合と同様に、集約操作での再帰の問題は、永続的なモデルセマンティクスまたは十分に根拠のあるセマンティクスを使用して解決されます。前回の記事で、これらのアプローチについて簡単に説明しようとしました 。ただし、モデリングコンポーネントのセマンティクスは可能な限り単純にする必要があるため、標準のSLD解像度が推奨されます。そして、無限再帰を回避するという問題は、概念間の接続を再形成することによってよりよく解決されます。



集約は、ハイブリッド言語の計算コンポーネントを使用して、機能的なスタイルで自然に実装できます。これを行うには、推論結果を一意のグループにまとめ、それぞれの集計関数を計算する関数で十分です。しかし、概念の定義を論理的な部分と機能的な部分に分割することは、集約などの重要なツールにとって最も便利なソリューションではありません。定義の構文を拡張して、グループ化セクションと集計関数を含めることをお勧めします。

concept < > < > (
    < > = <>,
    ... 
)
group by < >, ... 
from 
    <  > <  > (
        < > = <> ,
        ...
    ),
    ...
where < >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

SQLの場合と同様に、group byセクション には、グループ化を実行するための属性のリストが含まれています。関係式には、集計関数を含めることもできます。そのような関数を含む式は、すべての親概念の値が見つかり、グループ化が実行されるまで、未定義と見なされます。次に、それらの値をグループごとに計算し、属性に関連付けたり、グループのフィルタリングに使用したりできます。条件を評価およびチェックするためのこの怠惰なアプローチでは、グループ化の前後にフィルター条件を分離するHAVINGセクションは必要ありません 。ランタイムはこれを自動的に行います。



主な集計関数は、 カウント、 合計です。、 平均、 最小、 最大。関数の目的は、その名前から理解できます。モデリングコンポーネントは複合データ型で自然に機能するため、グループ化された値をリストとして返す関数を追加することもできます。それをグループと呼びましょう 。その入力引数は式です。この関数は、グループ内の各要素についてこの式を評価した結果のリストを返します。他の関数と組み合わせることで、任意の集計関数を実装できます。グループ関数 は、group_concatや json_arrayagなどのSQL関数よりも便利 です。これは、フィールド値の配列を取得するための中間ステップとしてよく使用されます。



グループ化の例：

concept totalOrders (
    customer = c,
    orders = group(o),
    ordersTotal = sum(o.total)
) group by customer
from customer c, order o 
where c.id = o.customerId and ordersTotal > 100
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

orders属性 には、すべてのユーザー注文のリスト、ordersTotal（すべての注文の合計）が含まれます 。グループ化が完了し、合計関数が計算された後、ordersTotal> 100条件 がチェックされます 。

機能によって定義される概念

概念を記述する宣言型の論理形式は、必ずしも便利ではありません。計算のシーケンスを設定する方が便利な場合があり、その結果が概念の本質になります。この状況は、データベース、ファイル、外部サービスへのリクエストの送信など、外部データソースからファクトをロードする必要がある場合によく発生します。入力クエリをデータベースへのクエリに変換し、このクエリの実行結果を返す関数の形式で概念を表すと便利です。論理的な結論を放棄し、特定の問題の詳細を考慮してより効率的に解決する特定の実装に置き換えることが理にかなっている場合があります。また、整数のシーケンスなど、概念エンティティを生成する無限のシーケンスを機能的なスタイルで記述する方が便利です。



このような概念を扱う原則は、上記の他の概念と同じである必要があります。ソリューションの検索は、同じ方法で開始する必要があります。それら自体を概念定義の親概念として使用できます。ソリューションの検索の内部実装のみが異なる必要があります。したがって、関数を使用して概念を定義する別の方法を紹介します。

concept < > (
< >, ... 
)
by <  >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

関数を使用して定義された概念を定義するには、その属性のリストとオブジェクトを生成するための関数を指定する必要があります。属性のリストを定義の必須要素にすることにしました。これにより、そのような概念の使用が簡単になるためです。その構造を理解するために、オブジェクトを生成する機能を調べる必要はありません。



それでは、オブジェクトを生成するための関数について説明しましょう。明らかに、入力としてリクエストを受け取る必要があります-属性の初期値。これらの値は指定することも指定しないこともできるため、便宜上、関数の入力引数となる連想配列に配置できます。概念の意味の検索がどのモードで開始されるかを知ることも役立ちます-すべての可能な値を見つけるか、最初のものだけを見つけるか、または解決策の存在だけをチェックします。したがって、2番目の入力引数として検索モードを追加します。



関数を評価した結果は、概念オブジェクトのリストになります。ただし、バックトラッキングを使用した検索に基づく推論手順では、これらの値が一度に1つずつ消費されるため、関数の出力引数をリスト自体ではなく、そのイテレーターにすることができます。これにより、概念の定義がより柔軟になります。たとえば、必要に応じて、遅延評価またはオブジェクトの無限シーケンスを実装できます。標準コレクションのイテレータを使用することも、独自のカスタム実装を作成することもできます。コレクション要素は、コンセプト属性の値を持つ連想配列である必要があります。コンセプトのエッセンスは、それらに基づいて自動的に作成されます。

戻り値の型としてイテレータを使用することには欠点があります。単に結果のリストを返すよりも面倒でユーザーフレンドリーではありません。汎用性、シンプルさ、使いやすさを兼ね備えた最適なオプションを見つけることは、将来の課題です。



例として、時間間隔を説明する概念を考えてみましょう。就業日を15分間隔に分割したいとします。これは、かなり単純な関数で実行できます。

concept timeSlot15min (id, hour, minute) by function(query, mode) {
    var timeSlots = [];
    var curId = 1;
    for(var curHour = 8; curHour < 19; curHour += 1) {
        for(var curMinute = 0; curMinute < 60; curMinute += 15) {
            timeSlots.push({
                id: curId,
                hour: curHour,
                minute: curMinute;
            });
            curId++;
        }
    }
    return timeSlots.iterator();
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この関数は、営業日の15分間隔のすべての可能な値のイテレーターを返します。たとえば、まだ予約されていない空きスロットを検索するために使用できます。

concept freeTimeSlot is timeSlot15min s where not exists (bookedSlot b where b.id = s.id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この関数は、クエリクエリに準拠しているかどうかの計算結果をチェックしません 。これは、属性の配列をエンティティに変換するときに自動的に行われます。ただし、必要に応じて、クエリフィールドを使用して関数を最適化できます。たとえば、概念のクエリフィールドに基づいてデータベースクエリを作成します。



関数を介した概念は、論理的セマンティクスと機能的セマンティクスを組み合わせたものです。関数型パラダイムで関数が入力引数の指定された値の結果を計算する場合、論理パラダイムでは出力引数と入力引数に分割されません。引数の一部のみを任意の組み合わせで指定でき、関数は残りの引数の値を見つける必要があります。実際には、任意の方向で計算を実行できるこのような関数を実装できるとは限らないため、自由引数の可能な組み合わせを制限することは理にかなっています。たとえば、関数を評価する前に、いくつかの引数を値にバインドする必要があることを宣言します。これを行うには、概念の定義でそのような属性をキーワードrequiredでマークします 。



例として、特定の指数スケールの値を定義する概念を考えてみましょう。

concept expScale (value, position, required limit) by function(query, mode) {
return {
    _curPos = 0,
    _curValue = 1,
    next: function() {
        if(!this.hasNext()) {
            return null;
        }
        var curItem = {value: this._curValue, position: this._curPosition, limit:  query.limit};
        this._curPos += 1;
        this._curValue = this._curValue * Math.E;
        return curItem;
    },
    hasNext: function() {
        return query.limit == 0 || this._curPos < query.limit; 
    }
}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この関数は、遅延評価を使用して概念エンティティを生成するイテレータを返します。シーケンスのサイズはlimit属性の値によって制限されますが、 ゼロの場合は無限大になります。無限シーケンスに基づく概念は、推論ルーチンが完了することを保証しないため、非常に注意深く使用する必要があります。limit属性 は本質的に補助的なものであり、計算を整理するために使用されます。他の属性の値から推測することはできません。計算を開始する前に知っておく必要があるため、必須としてマークされました



関数としての概念がどのように見えるかについてのオプションの1つを検討しました。しかし、そのような概念の安全性と使いやすさの問題は、将来、より詳細な研究を必要とします。

ネストされたコレクションのフラット化

オブジェクト形式のデータを処理できる一部のSQLダイアレクトは、コレクションの内容をテーブル形式（行セット）に変換し、結果のテーブルをFROM句に追加する UNNESTなどの操作をサポートします 。これは通常、ネストされた構造を持つオブジェクトをフラット化するため、つまりオブジェクトをフラット化またはフラット化するために使用されます。そのような言語の例は、BigQueryやSQL ++です。



ユーザー情報をJSONオブジェクトとして保存するとします。

[ {
"id":1,
"alias":"Margarita",
"name":"MargaritaStoddard",
"nickname":"Mags",
"userSince":"2012-08-20T10:10:00",
"friendIds":[2,3,6,10],
"employment":[{
    "organizationName":"Codetechno",
    "start-date":"2006-08-06"
},
{
    "organizationName":"geomedia",
    "start-date":"2010-06-17",
    "end-date":"2010-01-26"
}],
"gender":"F"
},
{
"id":2,
"alias":"Isbel",
"name":"IsbelDull",
"nickname":"Izzy",
"userSince":"2011-01-22T10:10:00",
"friendIds":[1,4],
"employment":[{
    "organizationName":"Hexviafind",
    "startDate":"2010-04-27"
}]
}, 
…]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ユーザーオブジェクトは、友人や職場のリストとともにネストされたコレクションを格納します。SQL ++クエリを使用して、オブジェクトの上位レベルから取得したユーザーに関するデータと一緒に接着することにより、ユーザーの職場に関する添付情報を抽出することができます。

SELECT u.id AS userId, u.name AS userName, e.organizationName AS orgName
FROM Users u UNNEST u.employment e
WHERE u.id = 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

結果は次のようになります。

[ {
"userId": 1,
"userName": "MargaritaStoddard",
"orgName": "Codetechno"
}, {
"userId": 1,
"userName": "MargaritaStoddard",
"orgName": "geomedia"
} ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

この操作については、ここで詳しく説明し ます。



SQLとは異なり、モデリングコンポーネントでは、埋め込まれたデータを表形式ではなくオブジェクト形式に変換する必要があります。上で説明した概念は、これを支援します-関数と匿名の概念によって定義された概念。関数を介した概念を使用すると、ネストされたコレクションをオブジェクト形式に変換できます。匿名の概念を使用すると、その定義を親概念のリストに埋め込み、目的のネストされたコレクションを含む属性の値にアクセスできます。



関数を介した概念の完全な定義は、匿名の概念として使用するには面倒すぎるため、次のようになります。

concept conceptName(attribute1, attribute2, ...) by function(query, mode) {...}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

それを短くする方法を見つける必要があります。まず、クエリパラメータと モードパラメータを使用して、関数定義のタイトルを削除できます 。親コンセプトの位置では、mode引数 は常に「すべてのコンセプト値を検索」になります。他の概念の属性への依存関係を関数の本体に埋め込むことができるため、クエリ引数 は常に空になります。コンセプトキーワードも削除できます。したがって、次のようになります。

conceptName(attribute1, attribute2, ...) {…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

概念の名前が重要でない場合は、省略でき、自動的に生成されます。

(attribute1, attribute2, ...) {…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

将来、関数によって返されるオブジェクトのタイプから属性のリストを推測できるコンパイラを作成できる場合は、属性のリストを破棄できます。

{…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

したがって、ユーザーとその職場を概念として使用した例は、次のようになります。

concept userEmployments (
    userId = u.id,
    userName = u.name,
    orgName = e.orgName
) from users u, {u.employment.map((item) => {orgName: item.organizationName}).iterator()} e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

解決策は少し冗長ですが、普遍的であることが判明しました。同時に、ネストされたコレクションのオブジェクトの変換が必要ない場合は、大幅に簡略化できます。

concept userEmployments (
    userId = u.id,
    userName = u.name,
    orgName = e. organizationName
) from users u, {u.employment.iterator()} e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

調査結果

この記事では、2つの問題に焦点を当てました。まず、SQL言語の一部の機能（ネストされたクエリ、外部結合、集計、ネストされたコレクションとの結合）をモデリングコンポーネントに転送します。次に、モデリングコンポーネントへの2つの新しい構造の導入：概念の匿名定義と関数を通じて定義された概念。



匿名の概念は、概念定義の省略形である関数の引数として（使用するためのもので 見つけ、 findOneを、そして 存在する）又はにおけるネストされた概念の定義として where句..。これは、関数型プログラミング言語の無名関数定義に類似していると考えることができます。



関数によって定義される概念は概念であり、そのオブジェクトを生成する方法は、アルゴリズムを使用して明示的な形式で表現されます。これは、関数型またはオブジェクト指向プログラミングと論理プログラミングの世界の間の一種の「インターフェース」です。概念を定義する論理的な方法が便利または不可能な場合、多くの場合に役立ちます。たとえば、データベース、ファイル、またはリモートサービスへの要求から初期ファクトをロードし、ユニバーサル論理検索をその特定のものに置き換えるなどです。最適化された実装、またはオブジェクトを作成する任意のルールを実装します。



興味深いことに、ネストされたクエリ、外部結合、ネストされたコレクション結合などのSQLからの借用は、モデリングコンポーネントのロジックを大幅に変更する必要がなく、匿名の概念や関数を介した概念などの概念を使用して実装されました。これは、これらのタイプの概念が、優れた表現力を備えた柔軟で用途の広いツールであることを示唆しています。面白い使い方はもっとたくさんあると思います。



そのため、この記事と以前の2つの記事では、ハイブリッドプログラミング言語のモデリングコンポーネントの基本的な概念と要素について説明しました。しかし、モデリングコンポーネントを関数型またはオブジェクト指向プログラミングスタイルを実装する計算コンポーネントと統合する問題に進む前に、次の記事でそのアプリケーションの可能なオプションに専念することにしました。私の観点からは、モデリングコンポーネントは、従来のクエリ言語（主にSQL）に比べて利点があり、計算コンポーネントと深く統合することなく単独で使用できます。これについては、次の記事でいくつかの例を示します。



英語の完全な科学的テキストは、papers.ssrn.com / sol3 / papers.cfm？abstract_id = 3555711で入手できます。



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



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

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

マルチパラダイムプログラミング言語 を設計します。パート3-知識表現言語の概要

マルチパラダイムプログラミング言語 を設計します。パート4-モデリング言語の基本構造マルチパラダイムプログラミング言語を

設計します。パート5-論理プログラミングの機能