この記事の主な目的は、招待状を受け取ることではなく、アイデアを共有し、その実現可能性とスペシャリストのコミュニティからの見通しについてコメントを得る機会です。 （この記事への招待を既に受け取っています-不明なhabrの友人に感謝します）
私はかつて経済部門のプロジェクト研究所でプログラマーとして働いていました。
大規模な組織（Bashneft）の経済計算を行いました。 これらの計算に技術サポートを提供しました。
これらの目的のために本当に便利なツールはないという事実に直面しました。
そのようなツール、つまり経済計算を記述するための言語であるプロローグを連想させる特別な宣言型言語のアイデアを思いつきました。
経済計算を記述するための言語の主な考え方は、計算の記述を、経済学の教科書で行われる方法にできるだけ近づけることです。 つまり、次のようなものです。
利益=収益-コスト
収益= Unit_price_title * Quantity_title
等
ユーザーは、このような式の形式で計算を説明し、目標、つまり実際に計算する必要があるものを設定します。 その後、システムは決済ツリーを構築します。
たとえば、利益を計算する必要がある場合、最初に収益とコストを計算する必要があります。
収益を計算するには、製品の単価と製品の数量を決定する必要があります。
実際の経済計算を説明するには、この言語を拡張する必要があります。
次の機能を提供する必要があります。
1.データベースからデータを抽出する
2.コンテキストに応じて、さまざまな計算の説明を提供します。
これを行うには、次のエンティティが言語に導入されます。
1.条件付きの数式：
式のグループの前または単位式の前に、この式を使用できる条件を設定できます。
2.データソース：
計算が実行されている企業のデータベースからのサンプル。
（標準データソース：SQLクエリ、DBFテーブル、csvファイルなど）
名前、フィールド-文字列、数値、日付
データソースは、データベースからデータを抽出する機能でのみ使用されます
3.機能：
標準数学
日付を操作する
データベースからデータを抽出する
集計関数：合計、最大、最小など
4.タグ：
タグの種類：
数
日付
多くの
ひも
計算のコンテキストを説明するにはタグが必要です。
経済的な計算は何らかのコンテキストで行われます：
特定のオブジェクト（企業、ワークショップ、部門..）、特定の期間の日付。
さらに、オブジェクトのインジケーターを計算するには、多くの場合、サブオブジェクトのインジケーターを計算する必要があります。たとえば、部門の利益を計算するには、部門のすべての部門の利益を計算して追加する必要があります。
このすべてのために、タグのメカニズム、その継承と変更が使用されます。
つまり、計算の最初に、計算のコンテキストを説明するタグのリストが表示されます。 まず、これは計算の対象です（企業全体またはユニットのいずれか、計算が行われる日付と期間）。 数式には、コンテキストタグの変更、タグの変更または追加の機能があります。
行の次の例の最初の式：
利益=金額（利益[Object_Type =ショップ]、Object_code = Extract_Set（ショップのリスト、Object_ID、Parent_code = Object_code））
サブストリングProfit [Object_Type = Shop]では、Object_Typeタグの値がOGPDからShopに変更され、同じワークショップでさらに計算が実行され、これらの計算の合計がOGPDに渡されます。
{[Object_Type = OGPD]という形式の行は、Object_Type = OGPDの場合にのみ、中括弧の間にあるすべての数式を使用できることを意味します。
例：
{[Object_type = NGDU]
利益=金額（利益[Object_Type =ショップ]、Object_code = Extract_Set（ショップのリスト、Object_ID、Parent_code = Object_code））
}
{[Object_type = Workshop]
利益= Production_Oil * Price_Oil-コスト
Oil_Oil =量（Oil_Oil [Object_type = Well]、Object_code = Extract_Set（Well_list、Object_code、Parent_code = Object_code、Well_type = Injection））
}
{[Object_Type = Well]
Oil_Oil = Ivlec_Value（Production_by_well、Production、Code_Holes = Object_code、Date = Settlement Date）
}
この例では以下を定義します。
OGPDの利益は、それに含まれるワークショップの利益の量です。
部門ごとの利益は、販売された石油からの収益とコストの差として定義されます。 ワークショップでの石油生産は、井戸での生産量として定義されます。
また、3つのデータソース（エンタープライズデータベースのサンプルテーブル）が存在することも意味します。
ショップのリストは、Object_codeとParent_codeの少なくとも2つのフィールドを持つテーブルで、どのワークショップがどのOGDUに属するかを決定します。
井戸のリスト-ワークショップのリストと同様に、ワークショップへの井戸の所属を定義する表。
期間の井戸生産データ-少なくとも3つのフィールドがある表：生産、
まあコード、日付。
コード1でOGPDに従って計算を開始するには、クエリ入力ウィンドウに次のように入力する必要があります。
Object_Type = OGPD
Object_code = 1
決済日= '01 .01.2009 '
？ 利益
メインコアは3つのモジュールで構成されています。
1.計算式を編集する
2.クエリウィンドウ
3.データソースを接続するためのモジュール。
これがコンピューティングコアです。
便宜上、サービス機能を拡張することはかなり可能です。
たとえば、次の機能は私に最も関連があるようです。
1.単一の値ではなく、テーブルの形式でクエリする
2.コードではなく、名前、つまりディレクトリの編成によって、計算対象に関する情報を入力する機能。
等
このアプローチの利点：
1.柔軟性-一度完了すると、直感的な方法で簡単に計算をやり直すことができます。 さらに、経済学者自身が簡単な変更を加えることができます。 また、ビジネスプランから開始して、予測モデルに従って計算された数式のデータを実際の指標に徐々に置き換えてプロジェクトを実施することもできます。
2.汎用性-異種ソースから情報を取得する計算を行うことができます。 多くの比較的独立した子会社で構成される大規模な組織にとって非常に重要です。
3.透明性-任意の有限値に対して、計算のツリーを構築し、すべての中間値を表示できます。 エラーが避けられない大規模プロジェクトで実際に発生します。エラーの根本原因は通常、見つけるのが困難です。
短所：
1.学習の難しさ。 それでも、これはまったく新しい言語ですが、まったく新しい言語です。
2.計算のセットアップの複雑さ。 小さな計算の場合、この方法は面倒です。
このプロジェクトの実装のさらなるステップから私を妨げる別の問題があります。
事実、その使用は比較的大きなビジネス施設でのみ意味があるということです。
私はそのような施設のプロジェクトのエグゼキューターとしてさまざまな実装で豊富な経験があり、良いアイデアを持っています
そのような顧客への製品の販売には非常に特殊な技術が使用されていますが、残念ながら私はまったく所有していません。
それらを所有し、このアイデアに興味を持っている人がいるかもしれません。
経済計算の説明のための言語-プログラムのアイデア
All Articles