「NoERP」または企業会計システムのデータ正規化の新しい見方

こんにちは、Habr！



この記事は、新しい経験の高さから、企業内の古い現代の会計および計画システムのアーキテクチャ（ERPと略してみましょう）を検討する試みです。 執筆の理由は、WEBアプリケーションのパフォーマンスの小さなテストであり、単純な網羅的検索によって1分半で1,000万の事実を集約することができました。 もちろん、現代のDBMSにとってはこれはばかげた量ですが、私がかつて働いていた商業および産業保有のERPシステムによって、1か月あたりほぼ同じ数のトランザクションが生成されたことを思い出しました。 いくつかの工場、連続生産、卸売流通、比較的単純な財務モデル-完全に典型的な会社、典型的な会計システムですが、インデックス、統計、およびヒントを備えたSQLクラスターと連携するアプリケーションクラスターで1か月間のレポート作成が20分以上行われました。 年次報告は最大6時間待たなければならず、「what-if」モードでそれを再集計する必要性が会計士と経済学者の眠れない夜に変わった。 このクラスのシステムは非常に複雑で高価であり、この業界で15年以上働いた後、私は主張し続けます-それらは不当に複雑で高価です。



私の考えを明確にするために、典型的な西部ERPのアーキテクチャ（以下のセクションで説明します）を簡単に説明する必要があります。そして、30年前ではなく、当時の要件を考慮して、そのようなシステムをゼロから設計することに着手したことを想像してくださいこれらのシステムはすべて作成されました。 最初に行うことは、「ブラックボックス」のすべての入力と出力を記述し、次にどの内部抽象化が実際に必要で、どれが冗長であるかを理解することです。

入力と出力

入り口 予測、計画、予算などのビジネストランザクションは、さまざまな種類の主要なドキュメントによって行われます。 文書は、ヘッダー、ライン、サブストリング（倉庫ロットまたは保管セルなど）の最大3レベルのネストのツリー構造を持っています。 各タイプのドキュメントには独自の属性セットがあり、その一部はさらなる計算アルゴリズムに関係し、一部は参照用です。 入力データは入力段階で部分的に検証され、チェックの一部は追加の属性（通常は特別な訓練を受けた人に委ねられます）を追加した後、投稿段階で行われます。 したがって、ドキュメントには、新しいデータや他のドキュメントとともに「成長」するライフサイクルがあります。



理論的には、出口で、会社の活動に関する要約レポートが期待されます（残高、売上高、さまざまな種類の財務結果、コスト、予測、計画、税務記録など）-これは、これらのシステムが顧客に提示される方法です-上級管理職向けのダッシュボード、すべてのマクロインジケータを集約し、さらに、マウスを10回クリックするだけで元のドキュメントの数字を解読する理論上の機能を備えています。 ただし、現在の終了要件はやや広めです。

1. 現在、「金銭的罪の推定」の時代に-連邦税務局と4人の監査役は同じように機能します-最初に統合された明細書を要求し、次にすべての主要な文書を要求します（ほとんどの場合、電子形式ですが、紙も要求できます）。 文書は監査人自身の会計システムにアップロードされ、監査された会社の会計方針に従って計算が実行され、結果が比較されます。 このようなテストを事前に準備するために、企業は基本的なドキュメントのコンテキストでレポートを生成することを余儀なくされます。これは基本的に、階層的な畳み込みを使用した投稿の手順全体を意味します-大まかに言って、単純な損益ではなく、最終製品のコストで店のクリーナーの給与のシェアを確認する必要があります最新のOLAPシステムは、このような大量のデータを処理できます。
2. ビジネス分析と機械学習の最新のシステムでは、ビッグデータ全体が必要です。つまり、ソースドキュメントの少し重要な参照属性（管理者の位置と地理的位置）さえも、特定の場合に重要です。 また、システムには「ソースドキュメント-モジュラーポスト-総勘定元帳」というチェーンがあります。レベルが高いほど、特定のテーブルは1つではなく、ビジネストランザクションに関する包括的な情報を含み、データは数十のテーブルに「広がり」ます。
3. GCトランザクションとソースドキュメントの行との間に常に明確な関係があるわけではありません。通常、これは多対多の関係であり、単純な結合ではソースドキュメントの属性をサマリーレポートに自動的にプルできず、「オンザフライでの配布」は通常、生産性が低く、一見単純なレポートを作成するときの非常に数十分、さらには数時間です。 通常、数十個の外部結合はパフォーマンスに悪影響を及ぼします。

その結果 、各運用指標を解読して文書化する必要があるため、P＆L統合レポートと残高の価値は低下し、即時かつ最も詳細なレポートの必要性は高まっています。 すでに当日の夕方の小売業では、経営陣はマージンを期待しており、生産では誰もが月末を待たずにインスタントコストを管理したいと考えています（期間の10日と週ごとの締め切りのプロジェクトを見ましたが、これは制限ではありません）。



要約 -出力では、システムはすべての重要な属性と重要でない属性を使用して、可能な限りすべての分析を最大詳細で（つまり、プライマリドキュメントの行まで）提供する必要があります。つまり、実際には入力を完全に複製し、計算の結果で補完します。



そして、ERPプログラマーとそのユーザーの苦しみを理解するために、このようなシステムの現在のデータベース構造について少し掘り下げます。

継承されたアーキテクチャ

コンピューターが低電力で、RDBMSをストレージとして使用し、ビッグデータテクノロジーが初期段階にあった遠い時代に、アーキテクチャが提案されました-すべてのドキュメントの指紋を最も統一された匿名形式で保存するが、迅速な構築に適した単一の会計レジスタを作成するOLAPレポート。 元帳はそのようなレジスタになりました（1Cの「操作ログ」という名前の類似物は、パフォーマンスの問題のために切り取られました）。 最終的に、転記中の各文書は総勘定元帳でトランザクションを生成します。理論的には、そこからすべての管理レポートを生成する必要があります。 実際、各モジュールには独自の小さなブックがあり、ドキュメントが最初にモジュラートランザクションを形成し、次にそれらに基づいて元帳トランザクションが形成されるため、プロセスは2ステップです。



典型的なシステムは、約10個のモジュールに分けられます（在庫、購入、販売、サブレポート、カッサバンク、生産、修理、プロジェクト、計画、固定資産）。 ドキュメントライフサイクルの主な段階を非常に大まかに説明し、DBMSテーブルの数を推定します。

1. ドキュメントの初期入力。 原則として、データ構造には、ドキュメントの見出し、ドキュメントの行、および部分文字列（倉庫ロットや保管セルのリストなど）の1..3テーブルが含まれます。 この段階では、基本的なディレクトリが使用されます（取引先、命名法、単位、目標、プロジェクトなど）。 各モジュールでは、各タイプのドキュメント/行は別々のテーブルに保存されます-合計で約20テーブル。
2. 単位と通貨の変換。 通常、計算値は表1の個別のフィールドに配置されます。
3. ドキュメントを他の種類のドキュメントに手動および半自動で「バインド」する（たとえば、輸送サービスの購入は移動ドキュメントに関連付けられ、通関費用は調達ドキュメントに関連付けられるなど）。 期間をクローズするプロセスですべてのバインディングが自動的に行われる場合、ステージは存在しない可能性がありますが、人生では異なる方法で発生します。 インターモジュールごとに1つのテーブルを使用し、合計で約5つです。
4. 操作のアカウント割り当て、つまり、パラグラフ1のディレクトリに基づいて-このドキュメントを投稿する必要があるアカウンティングレジスタの定義。 通常、これはアナリストを含む残高勘定科目であり、アナリストを含む記者勘定科目です-文書見出しと各行ごとに別々に。 レジスタは、最も詳細なモジュールエントリを形成します。 10個のテーブルがあります（モジュールの数に応じて）。
5. モジュラーレジスタのバランスが更新されます（バランス、負債、予算執行など）。 別の10テーブル。
6. モジュラー投稿はドキュメントに従って折りたたまれ、総勘定元帳-1..2テーブルに記録されます。
7. GK残高が更新されます-1テーブル。
8. 税制に応じた行ごとの税金および/または上限の計算-2つのテーブル。 ロシアでは、電子請求書と購入/販売の書籍の行を生成する必要があります。 さらに4つのテーブル、合計6。
9. 生成されたトランザクションと他のモジュールのトランザクションとの比較（条項3の関係に基づいて、またはバッチで）。 たとえば、消耗品の保管ロットは、多対多のスキームに従って到着と照合されます。また、DZ / KZを形成するトランザクションは、発行/受領された前払金と比較されます。 ここでは、すでに元のドキュメントから外れており、トランザクションをトランザクションと比較します。つまり、ある人工エンティティを別の人工エンティティと比較します。 モジュールごとに1つのテーブル、約5を使用します。
10. 条項9の比較グラフに基づく償却費用の再評価再評価は、トランザクションの別のカテゴリによって行われます。さらに2つのテーブルを考慮します。
11. 監査証跡（誰が、いつ、何を、どれだけ）を作成します。 別のテーブル。

合計で 、参考書がなくても、当社の業務は60のテーブルに分散しており、業務の実際に関する完全な情報が含まれているものはありません。



このデータスキームには、いくつかの正当化があります。

1. 当時、トランザクションパフォーマンスがボトルネックであったRDBMSが使用されていたため、可能な限りデータを正規化しようとしました。
2. RDBMSテーブルの列の追加/展開/名前変更（それぞれすべてのインデックスで）は難しい操作であり、通常はブロックし、システムのシャットダウンが必要です。したがって、モジュールの配線はドキュメントから分離され、元帳の配線はモジュールの配線から分離され、税金は配線から分離されます。 .d。 これにより、総勘定元帳などのテーブルの構造に大きな影響を与えることなく、1つのモジュールでの変更（税金など）の実装が容易になります。
3. データ共有の設定は簡単で、不正行為はより困難です（15のテーブルに一貫した変更を加えるには、専門家である必要があります）。

このスキームがもたらすもの：

1. ユーザーは通常、事実に関する完全な情報に興味があります-誰が、何を、誰を販売し、どの輸送で、どの価格で、販売が支払われたかどうか、現在の残高と操作時の残高、マネージャーの名前など）、したがって、レポートSQLクエリ（マテリアライズドビュー、ミラーデータベース、OLAPなど）を使用して、これらすべてのテーブルからデータを収集する必要があります。
2. プログラマーは、より強力で動的に最適化されたSQL言語を自由に使用できます。これにより、予測可能なシングルパスアルゴリズムの代わりに、ネストされたクエリ（少なくともJOINは基本的にはネストされたループです）の使用が促進され、その結果、システムパフォーマンスがデータの増加に伴って非線形に低下しますしかし、次第にコンピューティングキャパシティプランニングが困難になります（たとえば、1つの新しいエンティティが追加され、パフォーマンスが10倍低下した）。
3. ERPシステムをブラックボックスと見なす場合-入力には完全なデータセットを持つドキュメントがあり、出力にはユーザーは同じドキュメントが必要ですが、追加の属性セット（アカウントと分析、相互決済の状態、関連ドキュメントからのデータ）が必要です。 ユーザーは、トランザクション、比較、レジスタなどの人工的なエンティティには興味がありません-調停（プライマリまたはカウンターパーティと）はドキュメントに従って行われ、監査とビッグデータはドキュメント行への復号化を必要とします。 しかし、入力ドキュメントと出力の間-プログラマーによって作成された人工エンティティと、プログラマーとシステム管理者の便宜のために正規化されたスキームがあり、その結果、最初にドキュメントを分子に解析し（実行時）、次に分子から再構築します（レポートで）。

ターゲットアーキテクチャ

今日では、サーバーとワークステーションのパフォーマンスが桁違いに成長し、資格情報の量はあまり変化していません-アーキテクチャを修正するときですか？ 入力と出力が非常に似ているのに、なぜこれらの変換を行ったり来たりする必要があるのですか？ 残高、比較、コストのレジスターは計算の結果であるため、どこにも行かないことは明らかですが、モジュールトランザクションおよび総勘定元帳トランザクションの形で中間の人工的なエンティティが必要ですか？ ドキュメントは入力と出力の両方で要求される横断的エンティティであるため、新しいERPはドキュメントを中央データ構造にすることを提案しています。 ライフサイクルのさまざまな段階で表示される属性（分析、比較、再集計）は、ドキュメント自体に書き込む必要があります。 これにより、均一で予測可能な方法で、線形時間でレポートを作成できます。



レポートアルゴリズムを統一するために、すべてのタイプのドキュメントを単一のデータベースに保存することを提案します。詳細のセットは異なる場合があり、さらに動的であるため、このデータベースはNoSQLである必要があります。 計算およびレポートアルゴリズムはデータベースをスキャンし、各ドキュメントで必要な属性またはそれらの組み合わせを見つけようとします（NoSQLは属性の組み合わせのインデックスをサポートしているため、フルフルスキャンは不要です）。 属性を見つけることは、特定の計算/レポートにドキュメントが含まれていることの兆候です。



ドキュメントは相互に接続できます。つまり、ストレージジャンクションは「それ自体」であり、これには、まず、すべてのディレクトリとドキュメント（因果関係グラフ）の整然としたストレージが必要であり、次に、シングルパスに有利なレポート生成アプローチのレビューが必要です短期記憶を備えたアルゴリズム-最適化されているものの、ネストされたループの代わりに。



いくつかの追加のエンティティ（残高、比較、再評価）が残っていますが、まず、これらのエンティティは実世界のオブジェクトを反映し、次に、基本原則を尊重する必要があります-取引の完全なデータは、メイン文書と関連文書から取得する必要があります、配線、会計台帳などの合成エンティティを使用せずに



追加のボーナス-提案されたシステムにより、データベースを停止することなく、プログラムコードへの干渉を最小限に抑えながら、特定の種類のドキュメントの追加の参照属性をオンザフライで作成できます。



欠点は、組み込みのDBMS機能に依存せずに、プログラムでストレージスキーム（有効な属性セット、有効な関係、データ検証）を実装する必要があることです。 公平のため、ほとんどの商用システムでは、外部キーとトリガーは使用されず、すべてのデータの整合性はアプリケーションサーバー側のアルゴリズムによって保証されます。



PS

別の記事では、このようなストレージスキームを使用した計算とレポートで使用する必要がある短期メモリを備えたシングルパスアルゴリズムの説明に値しますが、これがなくても、最初のMVP（ストレージスキーム+入力インターフェイス）の作業量は現在の能力を大幅に超えるため、プロジェクトはゆっくりと移動します。そして、私はおそらく次の記事で彼のステータスについてお知らせします。



PPSS

トピックの継続。