1C：Enterpriseのデータモデルをどのように使用しますか（または「なぜテーブルを使用しないのですか？」）

この記事では、1C：Enterpriseプラットフォームで選択されたデータ操作モデルとその理由について説明します。



ビジネスアプリケーションの場合、データの操作は非常に重要なアーキテクチャ上の問題です。 いずれにしても、アプリケーションのすべての作業はデータを中心に構築されます。 さらに、ソフトウェアシステムの一部のクラスでデータが補助的である場合、ビジネスアプリケーションではデータがタスクの主要なコンテンツです。



ここ（この記事）では、データの保存と操作の技術的な側面についてではなく、アプリケーションを設計する方法としてデータを説明することについて説明します。 ビジネスアプリケーションにとってデータがそれほど重要なのはなぜですか？



それらはサブジェクト領域自体を記述するためです。 事業体はどのようなもので、どのように関連していますか。 データは問題自体を非常によく説明しています。 実際、アプリケーションを設計するとき、私たちは絶対にすべてのデータに興味を持っているのではなく、何らかの方法で解決される問題に影響を及ぼすデータ（およびそれらの関係）に興味があります（潜在的に興味深い方向でのシステムの開発のためのマージンを含む）。 たとえば、人材育成のプロセスを自動化する場合、教育、従業員の職歴に関心があります。 ただし、服や靴のサイズに関する情報は反映しません。 しかし、たとえば、作業服の会計を自動化する場合、これはすでに興味深いものになります。 しかし、好奇心designer盛なデザイナーはここで質問をするかもしれません。 スタッフの開発には、やる気があります。 そして、やる気があるところには、おそらく、会社のシンボルを使った衣服の製造があります。 ここでは、自然のデータ量は無限であり、データモデリングの技術がアプリケーションの設計の技術を大きく決定していることがわかります。



もちろん、プロセスはビジネスアプリケーションでも非常に重要な役割を果たします。 （私たちとビジネスアプリケーションを開発する他のプラットフォームの開発者の両方）がプロセス上のアプリケーションの設計にもっと重点を置いてほしいのですが、データは依然として主題分野の最も重要な側面のままです。 そして、メインアプリケーションモデルが構築されるのはデータの反映です。



ご予約はわずかです。 ここでのデータは、プロセスに付随するデータも指します。 つまり、プロセスもデータモデルを介して間接的に表現されることがわかります。



1C：エンタープライズプラットフォームにもプロセスを反映するメカニズムがありますが、これは別の記事のトピックです。



データを扱うための伝統的なパラダイムがいくつかあります。



まず、古典的なリレーショナルモデルがあります。 リレーショナルテーブルの形式でデータを記述します（通常はリレーショナルDBMSに格納されます）。 このパラダイムはまったく新しいものではありませんが、非常に重要です。



オブジェクトのパラダイムがあります。 その中で、データはプログラミング言語のオブジェクトとして記述され、何らかの形でデータベースに保存されます。 リレーショナルデータベースでもオブジェクトデータベースでもかまいません。 前者の場合、モデリング機能はDBMSによって決定され、 後者の場合は使用されるORMによって決定されます。



（ビジネスアプリケーションを作成する場合）あまり使用されない手法とアプローチもあります。 たとえば、構造化されていないデータに基づくアプローチ。



実際、1C：エンタープライズプラットフォーム用に選択したアプローチについてです。 彼には正式に認められた名前はありません。 これを「適用されたオブジェクトのタイプのモデル」と呼びます。 このアプローチの本質は、プラットフォームが開発者に特定の種類のアプリケーションオブジェクトのセットを提供することです。 各タイプは、ドメインエンティティの特定のカテゴリをアプリケーションモデルに反映することを目的としています。 アプリケーションモデルで解決される問題の主題領域を反映する場合、アプリケーション開発者は適切なタイプのオブジェクトを選択し、それらを使用してデータモデルを記述する必要があります。 実際、彼はデータモデルだけでなく、多くの点でアプリケーション自体のモデルについても説明しています。 しかし、それについては後で。



アプリケーションオブジェクトのタイプは何ですか？



これは、サブジェクト領域の本質を扱うさまざまな側面を定義する、プラットフォームに組み込まれたテンプレートの一種です（抽象クラ​​スと考えることもできます）。



アプリケーションオブジェクトのタイプは、開発時（設計時）とシステム操作時（実行時）の両方に現れます。 設計時には、これはメタデータのオブジェクトを記述するためのメタモデルと、プログラムモデルのデータを操作するためのクラスです。 実行時には、これらはこのタイプのオブジェクトを操作するときのシステムの動作のさまざまな側面です。 たとえば、ロックメカニズムの動作。



1C：Enterpriseには、いくつかのタイプのアプリケーションオブジェクトがあります。



たとえば、次の3つのタイプを取ります。

• ディレクトリ
• ドキュメント
• 累積レジスタ

ディレクトリは、条件付きで一定の情報（従業員、商品、顧客のリストなど）をシステムに反映することを目的としています。



文書は、対象分野のいくつかの出来事を反映しています（販売、従業員の雇用、銀行への送金） 印刷されたフォームの名前で呼ばれることもあります（「支払い順序」、「雇用の順序」、...）。 しかし、これは理解を容易にするためだけです。 実際、これはまさに印刷されたフォームではなく、イベントのタイプです。



累積レジスタは、アプリケーションの一部の会計システムを反映することを目的としています。 たとえば、倉庫での現金または商品の保管の会計処理。



アプリケーションオブジェクトの種類によって提供される機能の「セット」にまだ含まれているものを見てみましょう



もちろん、まず、アプリケーションオブジェクトのタイプはデータモデルを記述し、リレーショナルストレージモデルへのデータマッピングを提供します。 しかし、これは彼の定義のほんの一部にすぎません。



たとえば、参照用：

• プラットフォームにすぐに配置されるいくつかの標準の詳細（フィールド）があります（リンク識別子、コード、名前、階層ディレクトリの親へのリンク、...）
• （任意の）詳細（フィールド）を説明できます
• 密接に関連するエンティティ（包含）である表形式のパーツを記述することも、ネストされたテーブルと見なすこともできます。

文書のように見えますが、標準属性Dateがあります。これは、時間軸上の他のイベントに対するイベントの位置を反映し、ドキュメントが会計システムに反映されるか下書きであるかを決定する「Posted」記号もあります。



累積レジスタの場合、フィールドはディメンション、リソース、および詳細に分けられます。 測定では、会計モデルの座標系（製品、倉庫など）、リソース-インジケーター（数量、金額など）、詳細-単なる追加フィールド（会計モデルに影響を与えず、移動の記録にコメント）を記述します。



なぜ私たちはタイプのアプリケーションオブジェクトで動作し、例えばテーブル（またはエンティティだけ）で動作しないのですか？



これは非常に重要なポイントです。 テーブルには多くの利点があります。 これらは、リレーショナルモデルの最も単純なモデリングに近いものであり、開発者を埋め込み型のフレームワークに限定するものではありません。 しかし、表は、選択したアプローチが提供する機会を提供していません。



私たちのアプローチの本質は、（簡単な言葉で）システム（プラットフォーム）が記述されたオブジェクトについて「多くのことを知って」おり、「それらと関係がある多くのことを知っている」ということです。 この知識とスキルに基づいて、システムはこれらのオブジェクトを直接または間接的に操作する12を超えるさまざまなメカニズムの作業を自動的に提供します。 つまり、アプリケーション開発者がオブジェクトのタイプを選択して特定のオブジェクトを記述し、特定のオブジェクトのタイプと記述を知っているプラ​​ットフォーム自体が、さまざまな便利な機能とメカニズムを提供していることがわかります。 これは、オブジェクトタイプレベルでこのタイプのオブジェクトのセマンティクスが決定される（オブジェクトの目的が「大規模」である）ために達成され、メタデータモデルを使用すると、さまざまなプロパティや生活のさまざまな側面を記述する特殊なモデルによる特定のオブジェクトのセマンティクスを明確にすることができます。



それらのほんの一部をリストします。

• まず第一に、もちろん、これは、モデルが変更されたときに、ストレージ用のデータ構造の作成と構造の自動変換です。
• データの操作（読み取り、書き込み、検索）のためのオブジェクトモデルのクラスのセット
• オブジェクトリレーショナル変換メカニズム
• 典型的なデータ処理手順のセット。 たとえば、ドキュメントの場合、これは自動番号付けです。レジスタの場合、合計の計算、特定の時点で残高のスライスを取得することなどです。
• 権利制度への反映。 システムはオブジェクトの目的を知っているので、どの権利がそれに関連するかを知っています
• 視覚化（インターフェースでの反射）。 繰り返しになりますが、オブジェクトの目的と役割を知って、システム自体は、このタイプのオブジェクトにアクセスするためのアプリケーションインターフェイス、表示および編集用のフォーム、オブジェクトに対するさまざまなアクションのコマンドを構築します。
• データ交換。 データセマンティクスの知識に基づいて、プラットフォームは、関連するアプリケーション（分散ベースのノード）間および異種アプリケーション間（1Cで記述されたエンタープライズおよびその他のテクノロジー）の両方で、変更されたデータの非同期交換の標準メカニズムを提供します
• オブジェクトおよびトランザクションロック。 ブロックシステムを適切に構築するには、データの目的と関係についての知識が必要です。
• 特性のメカニズム（ユーザー定義の追加フィールド）
• 自動的に提供されるRESTインターフェース（OData標準）
• XML、JSONでのデータのアップロードとロード
• さらに、フルテキスト検索、データアクセスジャーナリングなどのメカニズムが自動的に機能します。

この図は、アプリケーションオブジェクトに基づいて動作するすべてのプラットフォームメカニズムとはほど遠いものですが、ごくわずかです。



ある意味では、アプリケーションオブジェクトのタイプはアスペクト指向のアプローチと交差しています。 上記の機能はすべて、アプリケーションオブジェクトのタイプを反映する定義済みの側面であるためです。 アプリケーションオブジェクトのタイプは、単なるテンプレートではなく、パラメータ化されたテンプレートであると言えます。 パラメータ化は、一連のメタデータプロパティを通じて実行されます。 プロパティ値を選択すると、開発者は選択したタイプのアプリケーションオブジェクトのテンプレートをパラメーター化し、それによって特定の側面におけるオブジェクトの動作を指定します。 たとえば、ドキュメントの番号付けの種類（年、四半期、月内）を選択すると、システムは自動的に特定の頻度で番号の割り当てと制御を行います。



適用されるオブジェクトのタイプは、エンティティ自体のセマンティクスだけでなく、その関係のセマンティクスに関する知識も提供します。 たとえば、サブジェクトエリアのイベントがアカウンティングモデルにどのように反映されるかを反映する、ドキュメントとレジスタの間に標準的な関係があります。 このような関係を決定すると、開発者はすぐに、ドキュメントと関連するレジストリエントリの有効期間を合わせた既製の機能を受け取ります。



それとは別に、重要な主題指向の側面に言及する価値があります。



たとえば、ディレクトリの場合、1つのフラグで階層のサポートを有効にできます。 同時に、システムは、ユーザーインターフェイス、レポート、オブジェクトモデルなど、すべての階層ディレクトリをサポートします。





ディレクトリ「Hierarchical Directory」の1つのプロパティを設定すると、すぐに、ユーザーインターフェイス、レポート、オブジェクトモデルの階層がサポートされます。



文書には、複数の種類の文書を組み合わせた雑誌、期間ごとの連続番号などの機能があります。



累積レジスタの場合、最も重要な機能は、計算された合計と、さまざまなセクションの合計にアクセスし、頻度を考慮するための既製の仮想テーブルの自動ストレージです。



つまり、本質的に、アプリケーションオブジェクトのタイプには、サブジェクト領域の対応するデータカテゴリの特性である、アプリケーションのビジネスロジックの普遍的な（典型的な）メカニズムのかなりの部分が埋め込まれています。



開発者は、デザイナーの詳細など、選択したタイプのオブジェクトからアプリケーションを収集することがわかります。 さらに、「抽象的な」詳細を持つデザイナーがいる場合、デザイナーのパーツにはすでに「目的」があります-ホイール、窓、ドア...

「ディレクトリ」タイプに基づいて、開発者は製品、従業員、通貨、顧客のディレクトリを作成します。 タイプ「ドキュメント」に基づく-ドキュメント「購入注文」、「アカウント」、「販売注文」など



言及する価値のあるもう1つは、このアプローチの方法論的価値です。 すべての開発者は、アプリケーションの本質をよりよく理解し、コミュニケーションを簡素化するのに役立つ特定の概念セットで動作します。 なじみのない1C：エンタープライズプロジェクトを開いた開発者は、すぐに使い慣れた概念を確認し、このオブジェクトがシステム内でどのような役割を果たしているかをすばやく把握できます。 たとえば、アプリケーションの本質を理解するには、レジスタの構成を調べる価値があります。通常、アプリケーションの主な目的を反映しています。 テーブル構造、または特にテーブルやクラスを操作するツールで記述されたなじみのないアプリケーションのクラス構造を開くと、理解がはるかに少なくなります。



しかし、より重要なことは、このアプローチにより、開発者とビジネス担当者（またはアナリスト）の言語がより緊密になることです。 そのような言語の必要性については、 「Object-Oriented Design（DDD）」という本でよく言われています。 複雑なソフトウェアシステムの構造化」 Eric Evans著。 アプリケーションオブジェクトの種類は、非プログラマーにすぐに明らかになり、アナリスト、顧客、および開発者は、1つの言語でプロジェクトの主要な機能について議論できます。 プログラミングを知らないが、1Cの種類の観点からタスクを設定できるビジネス担当者またはアナリストと頻繁に会うことができます：エンタープライズアプリケーションオブジェクト。



他に何が面白いですか。 このアプローチにより、システムの継続的な開発が保証されます。 プラットフォームに新しいメカニズムを追加すると、それらはすぐに既存のオブジェクトに対して機能し始めます（アプリケーション開発者の努力なしで、または最小限の努力で）。 たとえば、最近、 データ履歴を保存するメカニズム（バージョン管理）を開発しました。 システムはデータのセマンティクスに関する一般的な用語を知っているため、開発者は特定のオブジェクトのデータ履歴を保存するボックスをチェックするだけで十分です。プラットフォームは、履歴の保存から視覚化まで、必要なすべてを提供します-ユーザーにさまざまなレポートの形で変更履歴を表示します。 以前に標準のRESTインターフェイス （OData標準に基づく）のメカニズムを開発したとき、既製のRESTインターフェイスがすべてのアプリケーションにすぐに登場しました。 開発者はこのために何も変更する必要がありませんでした。



既製のタイプのアプリケーションオブジェクトに加えて、「テーブルだけ」を実行しないのはなぜですか？ これは簡単な質問ではありません。 私たちは定期的にそれを自問しています。



一方で、それは魅力的なようです。 そのため、準備した適用済みオブジェクトの種類のセットにサブジェクト領域が理想的に収まらない場合は、問題のあるすべてのケースを閉じます。 開発者に言うことができます-「まあ、あなたはテーブルを持っているだけです-そして、あなたが望むようにその中のすべてをします。」 しかし、他方では、これはすべての標準メカニズムが「損失」のままであるという事実につながります-これらのテーブルをどのように扱うのでしょうか？ 結局のところ、彼らはこのデータのセマンティクスを知らず、それらを正しく操作する方法を理解できません。 まあ、つまり、「何らかの形で」彼らと一緒に作業することができます。 厳密に言えば、外部ソースに関してこのような経験があります。 外部ソースの場合、テーブルを正確に記述します（客観的な方向を指定せずに）。 そして、システムはそれらと何らかの普遍的な方法で機能しますが、機能の一部はサポートされていません。



すべてのデータのセマンティクスに関する知識に基づいて、モデルの純度と新しい機能を追加する機能を確保するために、「単なるテーブル」の導入を控えようとしています。 いくつかの機会が十分でない場合、最初に、アプリケーションオブジェクトのタイプの構成を開発する方法を検討します。 しかし、もちろん、これは議論の余地のある問題であり、私たちはそれについて考え続けます。



したがって、1C：Enterpriseプラットフォームが完成した形で提供する機能、およびアプリケーション開発者が認める抽象化レベルの向上は、アプリケーションオブジェクトのタイプのセットに大きく依存しています。 これは、1Cの最も大きな違いの1つです。他の開発ツールとエンタープライズ、そして迅速で統一された開発を提供する主要なツールの1つです。