多次元テーブルプロセッサを使用するRAD

Habrコミュニティとビジネスインテリジェンスの分野のプロジェクトを共有したいと思います。このプロジェクトは、この1年半の自由時間に行ってきました。



多くの場合、表形式のプロセッサ（Excel、OpenOffice Calcなど）を使用して、単純な計算を実行するアプリケーション、レポート作成を支援するアプリケーション、または計画を容易にするアプリケーションをすばやく作成します。 そのようなアプリケーションの機能は通常非常に限られているという事実にもかかわらず、テーブルプロセッサの単純さにより、このアプローチは非常に人気があります。 この記事では、多次元データモデル（通常はOLAPの概念に関連付けられている）を使用してテーブルプロセッサの機能を拡張し、新しいツールで作業を複雑にしないようにします。 さらに読みたい人。

問題

過去5年間、私はITコンサルタントとして働いており、主に大企業の制御と計画の分野で.NET開発に携わってきました。 この間に、クライアントが多くの式といくつかのスクリプトを含む複雑なExcelドキュメントを示し、同じ機能といくつかの追加機能を備えたアプリケーションが必要だと言ったときに、いくつかのプロジェクトに出会いました。 これらのプロジェクトは、ドキュメントを使用するための同様のシナリオによって結合され、3つのステップで構成されています。

1. 多くの（5〜1000）ユーザーからデータを収集します。 データは、次のようないくつかの属性に関連付けられた数字でした：特定の時点での売上、特定の時間、プロジェクト、カテゴリ、部門の特定の製品または費用。 ドキュメントは通常、ネットワークフォルダーにあるか、コピーがメールでユーザーに送信され、応答が1つのドキュメントに手動で転送されました。
2. 統計/結果を計算します。 Excelは数年かけて複雑になり、多くの数式に加えて、Excelの使用は手動で実行されるいくつかのステップを暗示していました。 異なる入力データを使用した計算のシミュレーションも可能です。 たとえば、ドルが10％上昇した場合はどうなりますか。
3. 結果を表に表示します。 通常、この表はその後、印刷されたレポートまたはプレゼンテーションのスライドで使用されました。

私が扱ったテーブルプロセッサベースのソリューションは、通常、次の2つの目的のいずれかで使用されました。

• 計画、将来の計画および予測が会社の取引ベースではなく、専門家の頭の中にある場合
• ソースデータがトランザクションシステムで保持されない特別なレポート

時間が経つにつれて、テーブルプロセッサの使用に関連する手作業の量が急速に増加し、組織は多くのユーザーの並列作業とデータベース内の信頼できるデータストレージの可能性がある特別なソフトウェアの開発に費用を支払うことを決めました。

例

このようなスプレッドシートの非常に単純化された例を次に示しますが、それでも「フラットな」データモデルに関連する問題を示しています。



レモネードを販売している会社を想像してください。 市内のさまざまな場所でレモネードを販売する3人の従業員がいます。 会社は次の目的で毎日の販売を計画することにしました。

1. 午前中にいくつのレモンを買うかを大まかに知っている
2. 売り上げを伸ばそうとしている従業員にボーナスを支払う（たとえば、カウンターで電話で遊ぶのではなく、人を招待する）

会社には従業員3人、製品1つがあり、長期的な統計を維持する必要は特にないため、スプレッドシートを使用することにしました。 これは私たちのドキュメントのようです：





日および列のレモネードの販売数、収益、および計画の割合。 計画と現実を比較するために、計画と実際の2つのバージョンでデータを維持します。 各従業員用のワークシートを作成し、各シートの合計行が33であるという事実に基づいて金額を計算します。毎月、シートをコピーし、データを消去して再度記入します。



質問：複数の製品（新鮮なオレンジジュース？）がある場合はどうすればよいですか？数か月または1年の統計情報が必要な場合、販売者の本部が拡大し、市区町村ごとのデータを表示する必要があります（広告の効果を確認するなど）？ 数式を複雑にし、コスト計画を追加する場合はどうなりますか？ もちろん、テーブルにはもう少し苦労する可能性があります：各製品と販売者のワークシートを作成する（たとえば、5製品と10販売者= 50シート）、コピーされた数式を修正する、グループ販売者にスクリプトを書くなど。 もしも...

アイデア

データベースの大学コースを思い出して、多次元データモデルがそのようなシステムを記述するのに非常に適していることにすぐに気付きました。

私の最初の決定は、多次元キューブの形でデータベースにデータを格納し、データへのアクセスを制御し、IronPythonでスクリプトの形で計算を記述できる.NETフレームワークを作成することでした。 新しいプロジェクトごとに必要なコードは大幅に少なくなりましたが、このフレームワークを使用するにはC＃とデータベースの知識が必要でした。

しばらくして、テーブルプロセッサに似た多次元システムを作成するというアイデアが生まれました。この作業にはプログラミングスキルは必要ありません 。

市場

さらに、 OLAPおよび多次元データ分析について説明します。 このトピックはすでにハブで議論されているので（たとえば、 多変量解析の紹介 ）、繰り返しはせず、読者は議論されていることをほぼ知っていると思います。

インターネットで検索したところ、このアイデアは新しいものではないことがわかりました。 類似製品の2つのカテゴリに遭遇しました。

多次元スプレッドシート

1991年、Lotus Development Corporationは、このタイプのプログラムの典型的な代表であるLotus Improv製品を発売しました。 この製品は類似したシステムのすべてのクラスの例として機能したという事実にもかかわらず、あまり成功しておらず、その開発は1996年に中止されました。 インターネット上の記事から理解できる限り、この製品は1人のユーザー向けに設計されています。 私自身のために、私は次の結論を出しました。

• 多次元データモデルは、ほとんどの一般ユーザーにとって概念が複雑すぎます。
• 多次元キューブを単独で使用することはほとんど意味がありません。 1人が入力するデータは、ほとんどの場合2次元のタブレットに完全に適合します。 多次元データモデルは、マルチユーザーシナリオで意味があります。

計画機能を備えた本格的なビジネスインテリジェンスシステム

いくつかの大規模な（または非常に大規模な）企業が既にこのタイプのサーバーシステムを提供しています。

そのようなシステムの説明では、通常、OLAPという言葉が存在しますが、その作業には、通常、トランザクションシステムの既存のデータを分析するように設計された従来のOLAPシステムといくつかの違いがあります。 私の理解では、多次元データモデルを使用した計画システムは、多次元キューブへの便利なマルチユーザーデータ入力を可能にするという点で異なります。 つまり、このようなシステムの背後にあるデータベースは、トランザクション（ユーザー入力の保存）と分析（データ集約）の両方の操作モードを同時にサポートする必要があります。

私のクライアントの一部は、多次元データモデルでいずれかのプランニングシステムを既に使用しようとしており、次の問題に直面したことが判明しました。

• これらのシステムのほとんどを使用するには、高給の専門家が必要です。なぜなら、特別なスクリプト言語でプログラムできる必要があるからです。 システムを正しくインストールまたは管理するには、多くの場合、数百ページのドキュメントを読む必要があります。
• 比較的高価で複雑なライセンス。
• 同時に、そのようなシステムの機能は制限されており、システムに基づいて作成された最終製品の使用は通常、特別に作成されたアプリケーションを使用するよりも複雑です。

最後のポイントで何もするのは難しいです。 プログラミングスキルなしでソフトウェアを作成するという考えは新しいものではありませんが、人工知能が発明されるまで、そのようなプログラムの機能は制限されます。 最初の2つのポイントを修正することにしました。

解決策

次のプロパティを持つテーブルプロセッサを使用するのと同じくらい簡単に使用できるシステムを作成します。

• 多次元および階層データモデル
• 使い慣れたテーブルプロセッサの式に可能な限り近い式
• Webを介して並行して作業する能力
• データと数式へのアクセスを制御する
• 簡単なインストール、無料版を使用して数分で作業を開始する機能
• メンテナンスが簡単（クラウドで作業する必要はありません）
• アプリケーションモデルを作成する少数の人々だけがOLAPの概念を理解する必要があります。 データを入力するユーザーは、単にテーブルにデータを入力します。
• 大量のデータ（最大10億の値）を保存し、迅速に計算する機能

設計

一般的なアーキテクチャ

システム（コードネームEgeria）は、Webを介したマルチユーザー操作用に設計されており、.NET / C＃で記述されたサーバーとWebクライアントで構成されています。 「自宅で」作業するために、データフォルダーを選択し、ローカルサーバーを起動し、目的のアドレスでブラウザーを開くことができるシンプルなアプリケーション（ランチャー）があります。

寸法とその要素

行と列にそれぞれ数字と文字の番号が付けられているテーブルプロセッサとは異なり、キューブのディメンションメンバーは通常、アプリケーションエリアの要素（この場合は売り手、製品、日など）から作成されます。 多くの場合、データベーステーブルは各ディメンションの要素を記述するために使用されます。 SQLを学習してユーザーの生活を複雑にしたくないため、メタデータを表現するための視覚的な概念を作成することにしました。

何が起こったのか、私はビジュアルドキュメントと呼んだ。 システムオブジェクト（キューブやディメンションなど）を含むシステム内のすべてのメタデータは、ビジュアルドキュメントで記述されます。 レポート位置の書式設定を説明するこのようなドキュメントの例は、次の画像に表示されています。





各ドキュメントには、式からドキュメントへのリンクのコード（コード）と画面に表示する名前（名前）の2つのフィールドがあります。 ビジュアルドキュメント自体は階層構造を持ち、テキスト入力フィールド、選択リスト、チェックボックス、要素のリストなどの通常の入力要素で構成されます。 ビジュアルドキュメントの構造は、ビジュアルスキームによって記述されます。ビジュアルスキームは、ビジュアルドキュメントです（ビジュアルスキームの構造は、XMLスキーマインスタンスを使用してXMLスキーマの構造を記述できるのと同じ方法で、ビジュアルスキームによって記述できます）。 前のイメージのドキュメントを記述するスキーマは、「フォーマット」フィールドを定義します。 この図は、次の画像の「レベルデータタイプ」セクションで確認できます。





この図は、測定の説明「位置レポート」（位置）を示しています。 エジェリアでは、すべてのディメンションは階層的です（1つの階層レベルのみが定義されている場合でも）。 これは、各ディメンションをツリーとして表現できることを意味します。 すでに述べたように、このツリーの要素は視覚的なドキュメントです。 各階層レベルのドキュメントには、ディメンションモデルで説明されている独自のスキームがあります。 Positionディメンションには、positionという1つの階層レベルがあります。 また、アスタリスクコード（*）を持つゼロ要素が各ディメンションに追加されます。 この要素にはデータが含まれておらず、階層の最上位レベルにあり、識別子スター（*）も付いています。 左の最初の図では、位置測定が5つの要素で構成されていることがわかります：*、P01、P02、P03、P04。

キューバ

数値データは、いわゆるキューブに保存されます。 キューブはそのディメンションによって記述され、多次元のExcelシートのようなものです。 キューブの各セルに1つの数値を保存できます。

データ表示：ワークシート

最新の画面には2次元しか表示されないため、2次元テーブルの行と列のデータを設計する必要があります。 ユーザーが使用できるキューブ部分のこの変換と選択は、ワークシートの概念を使用して説明されています。

エジェリアでは、テーブルプロセッサとは異なり、ワークシートにはデータが含まれておらず（キューブに格納されています）、キューブの一部のデータのみが表示されます。 2つのシートで同じキューブ領域を表示できます。

テーブルプロセッサのピボットテーブルのように機能します。 ユーザーは、どのディメンションを列にするか、どの行にするか、どのフィルターをドラッグアンドドロップで選択するかを選択します。 その後、各ディメンションについて、ワークシートに表示される要素が選択されます。 ワークシートを保存したら、キューブにデータを入力して数式を作成できます。

計算

エジェリアの主な利点は、シンプルだが柔軟なキューブコンピューティング処理システムです。 すべての計算はサーバー上で行われます。 数式はマシンコードにコンパイルされるため、非常に高速に実行されます。 平均的なラップトップでは、500万の値を持つキューブは10〜20秒で完全に計算されます（キューブ内の空のセルの数は関係ありません）。 キューブの依存関係追跡システムを使用すると、キューブの1つのセルの変化を即座に計算できます（もちろん、別の500万セルがこのセルに依存していない場合を除きます）。

エジェリアの数式を、従来のテーブルプロセッサの数式にできるだけ似たものにしたかったのです。 回避できなかった3つの主な違いを次に示します。

• Egeriaは、標準の式言語を少し拡張して、式でメタデータを使用できるようにします。 たとえば、式pos.formatは、現在のセルのposディメンション要素のformatフィールドの内容を返します。
• メタデータの操作とセルの書式設定を可能にするいくつかの新機能が追加されました。 これらの詳細については、システムのドキュメントをご覧ください。
• 重要な革新は、キューブアドレッシングシステムです。

キューブのアドレス指定

テーブルプロセッサのアドレスは、B3または$ C $ 4（最初の相対、2番目の絶対）のようになります。 各アドレスに各測定値を書き込むことは非常に困難です（10〜15の測定値を使用できます）。 さらに、Egeriaは、結果の計算モデルの速度と明確さの理由から、式をコピーすることを拒否します（各式について、動作する空間を記述しています）。

システムでのアドレス指定は、常にセルに対して行われますが、これは現時点では考慮されています。

キューブへの各呼び出しは、角括弧で囲まれています。 括弧内に、目的のセルに到達するために変更する必要がある各ディメンションのアドレスがコンマでリストされます。 式[]は、現在処理中のセルを返します。 式[dim1：a1]は、ディメンションdim1にコードa1のセルを返し、アドレスの残りの部分は変更しません。 階層ディメンションの要素にアクセスできる特別な機能もあります。 たとえば、 [dim1：children（）]は、ディメンションdim1の現在の要素の下にある各要素に対して1つのセルを返します。 これにより、データを集約できます。

エジェリアでの例はどのようになりますか？

次のようなものが得られます。







売り手と売り手のツリーの左を選択し、選択リストの上部に月と製品を選択すると、右の表に売上が表示されます。

ツリーで通りを選択すると、右側にこの通りの売り上げが表示されます。







このアプリケーションは、次の手順に従って20分（データ入力を含む）で作成できます。

1. メタデータエディターを開き、次のディメンションを作成します（括弧内は、式で使用されるディメンションコードです）。
   
   
   • 日（日）-1から31の要素を持つ販売日。
   • 月（月）-1から12までのアイテムの販売月。
   • データ型（dty）-要素を含むデータ型：計画済み（計画済み）および実数（実際）
   • 位置（pos）-要素を含むレポート/入力フォームの位置：販売されたレモネードのカップ数（販売されたカップ）、収益（販売）、計画の達成率（計画の達成率）、およびグラスあたりの価格（カップの価格）。
   • ビジネスユニット（bu）-私たちの従業員は、働く通りによってグループ化されています。
   • 製品（製品）-従業員が販売する製品。
   
   
   
2. 次のワークシート（ワークシートまたは入力フォーム）を作成します。
   
   
   • 価格：通りごとに価格を入力します。
   • 売上：販売済みカップの入力と収益の計算。
   • 月別売上：月次データを集計します。
   
   
   
3. 数式を追加します。
   
   たとえば、売上の計算式は次のようになります。

     [日：*、dty：*、mon：*、pos：P04、bu：parent（）] * [pos：P01] 

   pos：P01は測定要素「コードの位置」のコードで、「販売カップ数」（販売カップ）と呼ばれます。pos：P04-「カップ価格」。 ガラスの価格は通りと製品にのみ依存するため、ディメンションの日（日）、データ型（dty）、および月（mon）のゼロ（*）要素に格納します。
   
   式bu：parent（）は、階層レベル「売り手」（事業単位の次元）から階層レベル「通り」に移動します。
   
   

このシステムの段階的な作成に関する詳細なビデオは、システムのウェブサイトのスクリーンキャストセクションにあります 。

もっと知りたいですか？

Webサイトhttp://egeria.rocksで次を見つけます。

• プロジェクトのドキュメントとスクリーンキャスト（残念ながら、これまでのところ英語のみ）
• 無料プレビューシステム
• エジェリアで構築されたアプリの例

ここに示した例に加えて、次のものがあります。

• 通貨変換を実行しながら、販売と費用から会社の収入を自動的に計算する販売計画システム
• 遊園地を例にした投資計画システム
• 資産評価システム
• 休日を入力する機能を備えたプロジェクト時間追跡システム

これは、エジェリアシステムの用途のほんの一部です。

技術データ

これがすべてどのように機能するかに興味がある人のために：

フロントエンド

Webアプリケーションの人気と機能の最近の成長により、JavaScript / HTML5（シングルページアプリケーション）がクライアントとして選択されました。 この場合、サーバーの役割はREST APIの提供に限定されます。

クライアントは、MVVMパターンを実装するAngularJSを使用します。 このプラットフォーム用の多数の無料コンポーネントの存在とそのよく考えられたアーキテクチャにより、クライアントの開発が大幅に簡素化されました。

バックエンド

サーバーはC＃で記述されています。 サーバーフレームワークとして、Nancy FXが使用されます。

ASP.NETは、REST APIを作成するには重すぎるように思えました。 さらに、ナンシーのシンプルさとファサードパターンの使用により、必要に応じて1〜2日以内にWebフレームワークを置き換えることができます。

また、ユーザーがアプリケーションをダウンロードして実行するだけで、ローカルWebサーバーを受信できるようにしたかったのです。 これは、ナンシーのセルフホストユースケースを完全にサポートします。

数式の解析にはSprache Frameworkを使用しました。これにより、数時間でパーサーを作成できます。 構文ツリーから解析した後、式ツリーが生成され、.NETランタイムはネイティブコードになります。

データベース

ビジュアルドキュメントは内部でJSONドキュメントにシリアル化されるため、Egeriaは任意のJSONデータベースにデータを保存できます。 現在、MongoDB用のアダプターがあります。 データをローカルファイルに保存するには、キーと値のストア（コピーオンライト）とprotobuf-netを使用したデータのシリアル化が使用されます。 残念ながら、完全にマネージコードで記述された、十分にサポートされているキーと値のストレージは見つかりませんでした。 JSONオブジェクトを操作するには 、 JSON.NETが使用されます。



キューブデータは、圧縮されたバイナリ表現（.NET 10進数の精度で1ポイントあたり約30バイト）で保存されます。これにより、メモリを節約し、データをキー値ストアからメモリに、またはその逆にすばやく移動できます。 システムはインメモリ処理の原理に基づいて構築されており、すべてのデータがメモリに収まることを前提としています。 キューブは非同期でロードされ、システムは起動後すぐに使用可能になります。

フィードバック

システムについてのあなたの意見を知って非常にうれしいです。

• 別の自転車か何か新しい？
• システムを使用するためのアイデアがありますか？
• コードを読みやすい形式で投稿し、Githubに投稿することを考えています。 ここでシステムコードを公開しますか、またはここで質の高い技術サポートがさらに重要ですか？
• バグを発見したか、新しい機能を提案したいですか？

コメントを書いてください。

特に興味深いのは、多次元データモデルを使用した計画システムをすでに扱っている人々の意見です。