エンビジョンメイキング計算

エンビジョンによる製作計算


ホーム » コマース分析 » このページ

エンビジョンは、単にそれ以外の場合はエクセルで行われる任意の計算について実施する可能性を提供している。この点において、このような計算するための構文はエクセルの数式に使用する構文と似ている。エンビジョンは、ベクトル計算に重点を置く。ベクターベースの操作は、一度に1つの値を操作するよりも、一度に多くの値を処理するために使用されている。表とベクターは、このページで詳細に覆われて、エンビジョンを使用して独自の計算をやり始めるのに役立つはずです。
このページをもっと便利に追跡するために、サンプルデータセットをセットアップすることを示す。入力データをロードするエンビジョン能力を相対的に詳述されていませんが、サンプルのデータセットで、スクリプトの先頭に一行のread "/sample1" allを追加するだけです。

テーブル及びベクトル

エンビジョンのデータモデルは、テーブルやベクトルを中心に展開する。エンビジョンテーブルは、リレーショナルデータベース内に存在するテーブルに、意思で似ている。エクセルの観点から、テーブルには最初の行は列ヘッダが含まれている整形式のスプレッドシートがあり、(多くの)行は以下正しくヘッダと整列されるデータが含まれている。エンビジョンスクリプトで、テーブルも名前が付けられていて、テーブル名は一般的に基礎となる表形式のファイルの名前によって駆動される。ベクターは、表の列に関連付けられていると同様に、それらはまた、名前が付けられている。エンビジョンは、操作が一度にすべてのベクトル値に対して実行できることを強調するために「ベクター」という用語ではなく、「列」を使用しています。

サンプルデータセットに適用することができ、スクリプトの数行でこの考えを示してみましょう。以下は、すべての注文ラインに、税率、つまり、税の額と顧客への税額の正味の比が顧客に提示される。

read "/sample1" all
Orders.TaxRate = Orders.TaxAmount / Orders.NetAmount

ここでOrdersは、指定されたトランザクション内の項目など多くの線で表されるすべてのトランザクションで全体の過去の販売が含まれているテーブルを参照する。変数Orders.TaxAmountは、テーブルOrdersTaxAmountという名前の列に関連付けられたベクターを参照する。テーブル名とベクトル名の間に、ドット(.)を使用することからなる構文を心に留めておいて下さい。なぜなら、このパターンはしばしばエンビジョンで使用されているからです。

等号=を伴う操作は代入と呼ばれます。計算は=記号の右側に行われ、その結果が文の左辺に割り当てられます。上記の例では、=右側に行われる除算演算がありまOrders.TaxAmountOrders.NetAmountも実際にスクリプト内の任意の場所に定義されていないため、エンビジョンは、入力データセットから直接データをロードしようとする。テーブルデータセットのOrdersテーブルが2つの列NetAmountTaxAmountが含まれているため、スクリプトが正常に実行されます。そして、左側に、Orders.TaxRateは新たに計算された税率を割り当てられます。代入は、割り当て変数に基づいて命名エクセルで新しい列を作成するためで、つまりここでは TaxRateと論理的に同等です。

次のスクリプトスニペットでは、簡潔さのために、常にすべてのスクリプトの先頭に含まれることが期待されているので、すべての例からラインread “/sample1” allを省略します。

エンビジョンでの計算の構文はエクセルの数式に使用されるものと同様です。以下のスクリプトでは、構文を説明するために(むしろ任意)一連の計算を行います。

Orders.A = 42
Orders.B = 5 * (1+ Orders.A)
Orders.C = (Orders.A + Orders.B) * (1 + Orders.A)

ここでは、スクリプトはそれぞれA, BCという名前の3つのベクトルを定義します。そして、すべてはOrdersテーブルに取り付けられています。最初の行は、値42がOrders.Aに割り当てられている単純な代入です。しかし、Orders.Aがベクトルなので、それはただ一つの値42ではありません。元のテーブルのすべての行に対して1つの値です。エンビジョンは、ベクトルに重点を置き、ベクトルの操作のほとんどは、一度にすべての値に行われています。

その上、Ordersは、サンプルデータセットで使用可能な唯一のテーブルではありません。例えば、サンプルデータセットはPurchaseOrdersのテーブルも含まれており、非常に類似した動作は、このテーブルに対して実行することもできます。

PurchaseOrders.A = 42
PurchaseOrders.B = 5 * (1+ PurchaseOrders.A)
PurchaseOrders.C = PurchaseOrders.A + PurchaseOrders.B

第二のテーブルは導入しているので、問題を提起:エンビジョンはテーブル間の操作を行うことができますか?答えはイエスですが、ほんの少しもっと努力が必要です。次のスクリプトを考えてみましょう:

Orders.A = 1
PurchaseOrders.A = Orders.A + 1 // WRONG!

2つのテーブルのOrdersPurchaseOrdersはどのような方法で整列するか根拠理由がないので、-2つのテーブルがあっても同じ行数が含まれていません-このような動作に関連した意味論的には非常に不明確になります。したがって、このような操作はエンビジョンで有効ではありません。もし試みにそのようなスクリプトを実行させるならば、実行は失敗し、エラーメッセージが表示されます。

それにもかかわらず、エンビジョンは、異なるテーブルからデータを結合するための豊富な方法を提供し、この側面は、次のセクションでカバーされています。

特別な“アイテム”テーブル

エンビジョンで使用されるテーブルは名前が付けられています、しかし、この条約の重要な例外として扱うことがある:項目のテーブルです。実際、商業では、計算の大部分を他のすべてを支配する一つのテーブルがあることに気付く:製品のリスト/ 変異体 / SKU/...実際のビジネスの状況に依存することに考慮されています。と言うと、すべてのテーブルが平等に扱われているリレーショナル•データベースは異なり、エンビジョンは商業で見つけるほとんどのシナリオに対処することがはるかに容易になり、アイテムテーブルに特別な処理を提供します。

それらの存在のある時点で、小規模または大規模な一つ一つの小売業者は、すべての製品がリストされているスプレッドシート、1行に1つの製品を思い付く。シートは、余分な情報を提供する多くの追加の列が含まれ、製品カテゴリのような静的情報または、最後の5週間の総売上高のような動的な情報を表示します。状況に応じて、ラインが販売されている製品またはSKU、またはアイテムの任意の同様のきめ細かい表現に関連付けられます。このような統合テーブルを構築することが、多くの状況で実用的である:休止在庫、価格更新トップセラーを特定などの識別のとき。小売開業医として、おそらく多くの場面で、スプレッドシートを処理しています。

Lokadでは、そのような同様に形成されたシートは、小売で遍在していることに気づいて、技術でこれを反映することを決めました。非常に商業に普及している慣行にできるだけアラインされたままで、このパターンを深くキャプチャするためにエンビジョンを設計しました。

サンプルデータセットに戻りましょう。データセットは、項目のリストが含まれています。すべての項目の在庫値を計算したいと仮定しましょう。“アイテム”テーブルはItemsの命名された場合は、これを用いて行うことができます:

Items.StockValue = (Items.StockOnHand + Items.StockOnOrder) * PurchasePrice

しかし、“アイテム”テーブルの、そして唯一のこのテーブルでは、テーブルの名前が省略されるべきです。このため、スクリプトが実際このように記述する必要があります:

StockValue = (StockOnHand + StockOnOrder) * PurchasePrice

接頭辞Items.は削除され、慣例により、名前が任意の変数にドット(.)が含まれていないと、暗黙的に“アイテム”テーブルに関連付けられたベクターを参照します。“アイテム”を含む計算は、商業的にそれほど頻繁なので、この規則は、実際にエンビジョンは、より読みやすい。

“アイテム”のスプレッドシートが非常に広く使用されている主な理由の一つは、商業において遭遇した履歴データの大部分が、好都合にも、各イベントで一つのアイテムに取り付けられているイベントのリストとして表すことができることです。たとえば、―販売履歴は最低限3列のテーブルで :アイテム識別子、日付と購入数量です。同様に、購入履歴は、同じ3つの列で表すことができ、加えて、理想的には到着日が発注と納期間のリードタイムを考慮しています。もし誰かが再発の顧客の行動を分析するに興味がある場合には、顧客からの返品はまた、アイテム識別子、日付、数量、理想的にはクライアント識別子を含む列を含む表のように表すことができます。

リストが更けていく。商業は、流通です:顧客への供給業者から、商品の流れ、顧客からの取引先へのお金の流れ。そのようなすべての流通はすべての行が、特に一つのアイテムに添付されている基本線に分解することができます。このように、商業では、ただテーブルの種類を見るではなく、支配的にアイテムの周りに連動されているすべてのテーブルを見て、エンビジョンは正確にパターンを獲得します。

“アイテム”テーブルには必須であるただ1つの列がある:エンビジョンの規則の限り、それは“Id”名前を付ける必要があるアイテム識別子列です。エンビジョンにロードされたほぼすべての他のテーブルは独自の“Id”欄を有することも期待されます。OrdersテーブルとPurchaseOrdersのテーブルが整列されていなかったので、2つのテーブルを結合することはできなかったことを見てきました。さて、“アイテム”テーブルおよび他のテーブルの両方に見出される“Id”列は、正確にこの組み合わせが行われることを可能にするために必要とされる“ブリッジ”です。

現金計算でこれを説明しましょう。アイテムごとに、誰かが全額過去販売に関連付けられた現金収入及び現金払い、また、全額過去購入に関連付けられた計算をしたいと仮定しましょう。以下のスクリプトを用いて行うことができます。

CashIn = sum(Orders.NetAmount)
CashOut = sum(PurchaseOrders.NetAmount) 
CashFlow = CashIn - CashOut

ここで、割り当ての左側に“アイテム”、そして右側に他のテーブルがあり、少なくとも1行目と2行目があることがわかります。この場合、sum()アグリゲータを使用するため、同時に異なるテーブルを使用するのは正当なものです。このドキュメントは詳細にアグリゲータを検討しませんが、名前が示すように、sum()アグリゲータは、すべてのアイテムすべてのNetAmountの合計を計算しているとだけ言うに十分です。OrdersテーブルがあまりにもId列が付属しているのでアイテムと注文とのマッチングが透過的に行われています。

明確にするために3行にわたって計算を分解しています。ただし、次のようにスクリプトは、中間変数の命名をすることなく、よりコンパクトに書き直すことができます:

CashFlow = sum(Orders.NetAmount) - sum(PurchaseOrders.NetAmount)

合計に加えて、エンビジョンは、すべての古典的なアグリゲータを対応します:平均、最小、最大、中央値を... これらのアグリゲータは、商業で見つける課題の多くに対処することになり、非常に有用である。記述属性とアイテムテーブルを補完する多くの可能性を提供します。しかし、それは別のテーブルとアグリゲータを活用し、“アイテム”の中に新しいベクターを作成することが可能であるが、その逆を行うために、別のテーブルに関連付けられた計算を行う際に、“アイテム”テーブルのベクターを使用することも可能です。

誰かがすべての販売注文ラインに関連するVAT(付加価値税)を再計算したい状況を考えてみましょう。簡単に、付加価値税はすべてのアイテム全体で20%の均一料金と史上全体で計算されていると仮定しましょう。これは以下のように記述できます:

VatRate = 0.2 // hypothesis
Orders.Vat = Orders.NetAmount * VatRate / (1 - VatRate)

VatRateベクターは、すべての注文ラインが単一のオリジナルアイテムにリンクされているため、Ordersテーブルと整合ベクター中に自然に展開されます。この拡張は、実際のコードを記述することでより明確にすることができます:

VatRate = 0.2 // hypothesis
Orders.VatRate = VatRate
Orders.F = Orders.VatRate / (1 - Orders.VatRate)
Orders.Vat = Orders.NetAmount * Orders.F

上記の例では、Ordersテーブル内のFベクターは、単に計算の分解を説明するために導入されます。

サイドノートでは、Id列が含まれていないテーブルの場合でも、エンビジョンに任意のテーブルをロードするために実際に可能であることに注意してください。しかし、このような高度なシナリオは、本説明の範囲を超えています。

日付の特別な状況

見てきたように、商業的に多くの基本的な操作は、“アイテム”の概念を中心に展開するので、アイテムテーブルは、エンビジョンで特殊なケースです。しかし、このような操作は、通常に特定の日付にリンクされ、販売履歴の各行は適用日が付属し、購買発注履歴のためのアイテム、そして、過去のデータを修飾するほぼすべてのデータについても同様です。実質的にすべての事業活動は、株価動向や支払いの会計処理日付エントリのリストとして記述することができる商業的に過去のデータの重要性のため、エンビジョンは非常に商業主導の方法で、日付の特殊なケースになります。

すべてのテーブルは、正規のId列に加えて、Date列を持つことができます。このよDateの列が存在する場合、テーブルがアイテム識別子によってインデックス付けされているだけではなく、日付によっても可能です。日付によるインデクセーションは、多くの場合実用的です。なぜならば、誰かが計算にいくつかの種類の時間窓を適用しようとするときに、関与しているエントリの種類に関係なく、全体の歴史は同様にフィルタ処理されることが期待されています。

キャッシュ•フロー計算に戻りましょう。全体の歴史のための値を計算する代わりに、昨年のデータ史を取るだけの、アイテムごとのキャッシュフローを計算することに仮定しましょう。これを用いて行うことができます:

when date > end - 365
  CashFlow = sum(Orders.NetAmount) - sum(PurchaseOrders.NetAmount)

end変数は単純に入力データセット全体に見られた最近の日付を指すシンタックスシュガーです。endは日付であることを考えると、これは、上記のスクリプトのようにエンビジョンは、日付の算術演算を実行する可能性を提供することを示しています。エンビジョンで任意の日付に+1規則を追加すると、特定の日付に1日を追加することになります。このように、365日を減算することにより、過去に約1年間に戻ることになります。

スクリプトは、スクリプトの指定されたブロック内で処理されるすべての行に対して真と強制された状態を表すwhenフィルタで始まります。項目の限り、日付によって索引付けされていません。このように、日付フィルタはそれらに影響はありませんし、すべての項目はwhenブロック内に存在し続けています。ただし、注文と発注書の両方が独自のDateの列を持っています。その結果、whenフィルタの条件を満たさないすべての行は、ブロックからフィルター処理される。

その結果、whenブロック内のsum()凝集が唯一の非ろ過ラインを処理します。つまり、1歳未満であるライン。同様の計算は、完全な履歴例で最初に行われていただけのような中間変数で分解されている可能性があります。

when date > end - 365
  CashIn = sum(Orders.NetAmount)
  CashOut = sum(PurchaseOrders.NetAmount)
  CashFlow = CashIn - CashOut

上記の例では、おそらくフィルタリングブロックの開始とwhen文の説明を参照の理由として少し明確になります:確かに、ライン2、3、4の前に2つの余分なスペースで目立つブロック内のすべての行は、日付に同じ周囲のフィルタを受けます。

このスクリプトは、“アイテム”テーブルと他のテーブルから来て、複雑なデータを再整列させるためのエビジョンの能力を示しています。エクセルの観点から、それは製品のリストを含むマスターシートを使用して列に他のシート(例えば、注文履歴)を変形することが可能であったかのように示されます。

FORMATTER ERROR (Transcluded inexistent page or this same page)