JP6934566B2

JP6934566B2 - 多次元データベース環境において重みを有する複数の親をイネーブルにするためのシステムおよび方法

Info

Publication number: JP6934566B2
Application number: JP2020518047A
Authority: JP
Inventors: ラマイヤー，クマール
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2017-09-29
Filing date: 2018-07-30
Publication date: 2021-09-15
Anticipated expiration: 2038-07-30
Also published as: CN111295651B; EP3676722A1; US20230185827A1; US20190102445A1; US11593402B2; JP2020535554A; WO2019067077A1; CN111295651A

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権保有者は、この特許文献または特許開示が特許商標庁の包袋または記録に掲載されているため、この特許文献または特許開示を誰でも複写複製できることに対して異議はないが、その他の点では全ての如何なる著作権をも保有する。

優先権の主張
本願は、２０１７年９月２９日に出願された出願番号第６２／５６５，５１２号である「多次元データベース環境において重みを有する複数の親をイネーブルにするためのシステムおよび方法（SYSTEM AND METHOD FOR ENABLING MULTIPLE PARENTS WITH WEIGHTS IN A MULTIDIMENSIONAL DATABASE ENVIRONMENT）」と題される米国仮特許出願、および、２０１７年９月２９日に出願された出願番号第６２／５６５，５１５号である「多次元データベース環境において共有メンバを使用する複数の親をモデル化するためのシステムおよび方法（SYSTEM AND METHOD FOR MODELING MULTIPLE PARENTS USING SHARED MEMBERS IN A MULTIDIMENSIONAL DATABASE ENVIRONMENT）」と題される米国仮特許出願に対する優先権を主張し、これらの出願は引用によって本明細書に援用される。

発明の分野
本発明の実施形態は、一般にデータベースおよびデータウェアハウジングに関し、特に多次元データベース環境において重みを有する複数の親をイネーブルにするためのシステムおよび方法に関する。

背景
多次元データベースコンピューティング環境は、企業が重要なビジネス情報を適切な人々に必要なときに届けることを可能にし、複数の既存のデータソースからのデータを活用および統合し、フィルタリングされた情報をエンドユーザコミュニティに、それらのユーザのニーズに最も適合する形式で配信する能力を含む。ユーザは、リアルタイムで、なじみのあるビジネス次元に沿ってデータと対話して利用することができ、思考スピードアナリティクスが可能になる。これらは、本発明の実施形態を使用することができるタイプの環境のいくつかの例である。

概要
ある実施形態に従って、多次元データベースにおいて重みを有する複数の親をイネーブルにするためのシステムおよび方法が本明細書に記載されている。システムの一例は、１つ以上のマイクロプロセッサを含むコンピュータと、上記コンピュータ上で実行される多次元データベースサーバとを備えてもよく、上記多次元データベースサーバは、データ次元の少なくとも１つの階層構造をサポートする。データ次元は、複数のメンバ、すなわち、第１のレベルにある第１のメンバセットと、第２のレベルにある第２のメンバセットとを備えてもよい。上記第２のレベルにおける上記第２のメンバセットのうちのあるメンバは、上記第１のレベルにおける上記第１のメンバセットのうちの２つ以上のメンバとの２つ以上のメンバ間関係を備えてもよい。上記２つ以上のメンバ間関係の各々は、重みに関連付けられる。

ある実施形態に係る、多次元データベース環境の一例を示す。ある実施形態に係る、ＢＯＭを表すデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、重みを有する複数の親をイネーブルにするための方法のフローチャートを示す。ある実施形態に係る、共有メンバを使用する複数の親をモデル化するためのデータ構造の一例を示す。ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。

詳細な説明
上記は、他の特徴とともに、同封の明細書、特許請求の範囲および図面を参照すると明らかになるであろう。具体的詳細は、さまざまな実施形態を理解できるようにするために記載されている。しかし、これらの具体的詳細がなくてもさまざまな実施形態を実施できることは明らかであろう。同封の明細書および図面は、限定的であるよう意図されてはいない。

多次元データベース環境は、その一例がＯｒａｃｌｅＥｓｓｂａｓｅを含んでいるのだが、この多次元データベース環境を使用して、場合によっては複数のデータソースからの大量のデータを統合して、フィルタリングされた情報をエンドユーザに、それらのユーザの特定の要求に応えるような態様で配信することができる。

図１は、ある実施形態に係る、多次元データベース環境１００の一例を示す。
図１に示されるように、ある実施形態に従って、データベース層として動作する多次元データベース環境は、１つ以上の多次元データベースサーバシステム１０２を含み得て、１つ以上の多次元データベースサーバシステム１０２の各々は、物理コンピュータリソースまたはコンポーネント１０４（たとえば、マイクロプロセッサ／ＣＰＵ、物理メモリ、ネットワークコンポーネント）と、オペレーティングシステム１０６と、１つ以上の多次元データベースサーバ１１０（たとえば、Ｅｓｓｂａｓｅサーバ）とを含み得る。

ある実施形態に従って、中間層１２０は、たとえばプロバイダサービス１２２（たとえば、ハイペリオンプロバイダサービス）、管理サービス１２４（たとえば、Ｅｓｓｂａｓｅ管理サービス）またはスタジオ／統合サービス１２６（たとえば、Ｅｓｓｂａｓｅスタジオ／Ｅｓｓｂａｓｅ統合サービス）などの１つ以上のサービスを含み得る。中間層は、多次元データベース環境とともに使用するために、ＯＤＢＣ／ＪＤＢＣ１２７，１２８または他のタイプのインターフェイスを介してメタデータカタログ１２９および／または１つ以上のデータソース１３０（たとえば、リレーショナルデータベース）へのアクセスを提供することができる。

ある実施形態に従って、１つ以上のデータソースは、多次元データベースの提供に使用するために、ＯＤＢＣ／ＪＤＢＣ１３２または他のタイプのインターフェイスを介して１つ以上の多次元データベースサーバによってアクセス可能でもある。

ある実施形態に従って、クライアント層１４０は、多次元データベース（たとえば、スマートビュー、スプレッドシートアドイン、スマートサーチ、管理サービス、ＭａｘＬ、ＸＭＬＡ、ＣＡＰＩまたはＶＢＡＰＩアプリケーション、オラクル・ビジネス・インテリジェンス・エンタープライズ・エディション・プラス、または他のタイプの多次元データベースクライアントなど）へのアクセスを可能にする１つ以上の多次元データベースクライアント１４２（たとえば、Ｅｓｓｂａｓｅサーバクライアント）を含み得る。クライアント層は、たとえば管理サービスコンソール１４４またはスタジオ／統合サービスコンソール１４６などの、中間層におけるサービスとともに使用するためのコンソールも含み得る。

ある実施形態に従って、クライアント層と中間層とデータベース層との間の通信は、ＴＣＰ／ＩＰ、ＨＴＴＰまたは他のタイプのネットワーク通信プロトコルのうちの１つ以上によって提供することができる。

ある実施形態に従って、多次元データベースサーバは、１つ以上のデータソースからのデータを統合して、多次元データベース、データ構造またはキューブ１５０を提供することができ、次いで、多次元データベース、データ構造またはキューブ１５０にアクセスして、フィルタリングされた情報をエンドユーザに提供することができる。

一般に、多次元データベースにおける各データ値は、キューブの１つのセルに格納され、特定のデータ値は、その座標をキューブの次元に沿って指定することによって参照可能である。１つの次元からのメンバの、１つ以上の他の次元の各々からのメンバとの交点がデータ値を表す。

たとえば、売上げ志向型ビジネスアプリケーションで使用され得るキューブ１６２を示す図１に示されるように、クエリが「売上高」を示す場合、システムは、このクエリを、全ての「売上高」データ値を含むデータベース内のデータ値１６４のスライスまたは層として解釈することができ、「売上高」は、「実際」および「予算」と交差している。多次元データベースにおける特定のデータ値１６６を参照するために、クエリは、たとえば「売上高、実際、１月」を指定することによって各次元上のメンバを指定することができる。データベースをさまざまにスライスすることによって、データのさまざまな観点が提供される。たとえば、「２月」のデータ値のスライス１６８は、時間／年次元が「２月」に固定されたそれらのデータ値の全てを検討する。

データベースアウトライン
ある実施形態に従って、多次元データベースの開発は、データベース内のメンバ間の構造的関係を定義し、データベース内のデータを編成し、連結および数学的関係を定義するデータベースアウトラインの作成から始まる。データベースアウトラインの階層木またはデータ構造内に、各次元は、１つ以上のメンバを備え、これらの１つ以上のメンバは、他のメンバをさらに備えていてもよい。次元の仕様は、その個々のメンバの値をどのように連結するかをシステムに指示する。連結は、木の枝の中の一群のメンバである。

次元およびメンバ
ある実施形態に従って、次元は、データベースアウトラインにおける最も高い連結レベルを表す。部門機能（たとえば、時間、勘定、製品ライン、市場、事業部）に関連するビジネスプランの構成要素を表すために標準次元が選択されてもよい。標準次元に関連付けられる属性次元は、ユーザがメンバ属性または特徴に基づいて標準次元のメンバをグループ化して分析することを可能にする。メンバ（たとえば、製品Ａ、製品Ｂ、製品Ｃ）は、次元の個々の構成要素である。

次元およびメンバ関係
ある実施形態に従って、多次元データベースは、家族に関する用語（親、子、兄弟、子孫および先祖）および階層に関する用語（世代およびレベル、根および葉）を使用して、データベースアウトライン内のメンバの役割および関係を説明する。

ある実施形態に従って、親は、その下に枝を有するメンバである。たとえば、「利幅」は、「売上高」および「売上原価」（ＣＯＧＳ）の親であってもよい。子は、その上に親を有するメンバである。上記の例では、「売上高」および「売上原価」が、親である「利幅」の子である。兄弟は、同一世代内の同一の直接の親の子である。

ある実施形態に従って、子孫は、親の下の枝の中のメンバである。たとえば、「利益」、「在庫」および「比率」は、尺度の子孫であってもよく、この場合、「利益」、「在庫」および「比率」の子も尺度の子孫である。先祖は、メンバの上の枝の中のメンバである。上記の例では、「利幅」、「利益」および尺度が「売上高」の先祖であってもよい。

ある実施形態に従って、根は、枝の中の最上位のメンバである。たとえば、尺度は、「利益」、「在庫」および「比率」の根であってもよく、したがって、「利益」、「在庫」および「比率」の子の根であってもよい。葉（レベル０）メンバは、子を持たない。たとえば、期首「在庫」、追加および期末「在庫」が葉メンバであってもよい。

ある実施形態に従って、世代とは、次元内の連結レベルのことをいう。木の根枝は、「世代１」であると考えられ、世代番号は、根から葉メンバに向かって大きくなっていく。レベルとは、次元内の枝のことをいい、世代で使用された番号順序とは逆に番号付けられ、レベル番号は、葉メンバからその根に向かって小さくなっていく。

ある実施形態に従って、ユーザは、世代またはレベルに名前を割り当てて、その名前をその世代またはレベル内の全てのメンバの省略表現として使用することができる。

疎および密な次元
多次元データベース内のデータセットは、多くの場合、２つの特徴を共有する。すなわち、データがスムーズかつ均一に配信されないこと、および、メンバの組み合わせの大部分についてはデータが存在しないことである。

ある実施形態に従って、これに対処するために、システムは、２つのタイプの標準次元、すなわち疎な次元および密な次元を認識することができる。疎な次元は、利用可能なデータ位置が埋められる割合が比較的低い次元であり、密な次元は、次元のあらゆる組み合わせにおいて１つ以上のセルが占められる確率が比較的高い次元である。多くの多次元データベースは、メンバの組み合わせの大部分についてデータ値を欠いているという点において、元来疎である。

データブロックおよびインデックスシステム
ある実施形態に従って、多次元データベースは、データブロックおよびインデックスを使用して、データを格納してデータにアクセスする。このシステムは、疎な標準次元のメンバの固有の各組み合わせについて多次元アレイまたはデータブロックを作成することができ、各データブロックは、その疎な次元のメンバの組み合わせのための密な次元のメンバを表す。各データブロックについてインデックスが作成され、このインデックスは、疎な標準次元のメンバの組み合わせを表し、少なくとも１つのデータ値が存在する疎な標準次元のメンバの固有の各組み合わせについて入力またはポインタを含む。

ある実施形態に従って、多次元データベースサーバは、データ値を検索する際、インデックスによって提供されるポインタを使用して、適切なデータブロックを突き止め、そのデータブロック内でデータ値を含むセルを突き止めることができる。

管理サービス
ある実施形態に従って、管理サービス（たとえば、Ｅｓｓｂａｓｅ管理サービス）は、ユーザがサーバ、アプリケーションおよびデータベースを設計、開発、維持および管理することを可能にする単一アクセスポイントを提供する。

スタジオ
ある実施形態に従って、スタジオ（たとえば、Ｅｓｓｂａｓｅスタジオ）は、データモデル化、キューブ設計および分析アプリケーション構築に関連するタスクを実行するためのウィザード方式のユーザインターフェイスを提供する。

スプレッドシートアドイン
ある実施形態に従って、スプレッドシートアドインは、多次元データベースをスプレッドシートと統合して、接続、ピボット、ドリルダウンおよび計算などの高度なコマンドをサポートする。

統合サービス
ある実施形態に従って、統合サービス（たとえば、Ｅｓｓｂａｓｅ統合サービス）は、多次元データベースに格納されたデータとリレーショナルデータベースに格納されたデータとの間の統合に使用するためのメタデータ方式の環境を提供する。

プロバイダサービス
ある実施形態に従って、プロバイダサービス（たとえば、ハイペリオンプロバイダサービス）は、Ｊａｖａ（登録商標）ＡＰＩ、スマートビューおよびＸＭＬＡクライアントのためのデータソースプロバイダとして動作する。

スマートビュー
ある実施形態に従って、スマートビューは、たとえばハイペリオン・フィナンシャル・マネジメント（Hyperion Financial Management）、ハイペリオン・プランニング（Hyperion Planning）およびハイペリオン・エンタープライズ・パフォーマンス・マネジメント・ワークスペース（Hyperion Enterprise Performance Management Workspace）データのための共通のインターフェイスを提供する。

開発者製品
ある実施形態に従って、開発者製品は、カスタマイズされた企業分析アプリケーションの迅速な作成、管理および配備を可能にする。

ライフサイクル管理
ある実施形態に従って、ライフサイクル管理（たとえば、ハイペリオン・エンタープライズ・パフォーマンス・マネジメント・システム・ライフサイクル・マネジメント（Hyperion Enterprise Performance Management System Lifecycle Management））は、企業パフォーマンス管理製品がアプリケーション、リポジトリまたは個々の人工物を製品環境全体にわたって移動させることを可能にするための手段を提供する。

ＯＬＡＰ
ある実施形態に従って、オンライン分析処理（ＯＬＡＰ）は、ユーザが企業データを分析することを可能にする環境を提供する。たとえば、財務部門は、予算編成、活動基準原価計算、財務成績分析および財務モデリングなどのアプリケーションにＯＬＡＰを使用して、「ジャストインタイム」の情報を提供することができる。

ある実施形態に従って、ＯＬＡＰシステムは、複数の次元においてデータを編成することができ、データセットの検索者／ユーザが、さまざまな次元を横断する有向検索を行って最終的に対象の結果に到達することを可能にする。ＯＬＡＰシステムは、データを次元の交点にあるものと見なすことができる。言い換えれば、ＯＬＡＰシステムの根底にあるデータは、全ての次元のクロス積の具体例である多次元データベースとして編成されて格納されることができる。これにより、ユーザ／検索者は、アドホックな態様で対象の次元に沿って階層を詳細に横断して、特定の目的のデータに到達することができる。緩やかに変化するデータは、現在のデータセット内のメタデータとして表すことができる。

重みを有する複数の親をイネーブルにすること
ある実施形態に従って、部品表（ＢＯＭ）は、企業経営計画における中核の概念である。図２は、ある実施形態に係る、ＢＯＭを表すデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭ２００の形式のデータ構造の一例が図２に示されている。示されている例では、最終製品Ａ２１０、最終製品Ｂ２１１および最終製品Ｃ２１２などの最終製品は、ＢＯＭの最上位レベルを構成し得る。最終製品の下には、組立品Ａ２２１、組立品Ｂ２２２、組立品Ｃ２２３および組立品Ｄ２２４などの複数の組立品（または、部分組立品）が存在し得る。これらの組立品は、たとえば各最終製品のためにクライアントが選択できるオプションを表し得る。ＢＯＭの最下部には、部品、またはＢＯＭが含んでいる最小のパーツ明細がある。示されている実施形態では、これらの部品は、部品Ａ〜Ｆ２３１〜２３６を含み得る。

ある実施形態に従って、示されているＢＯＭ２００は、たとえばさまざまなモデルの自動車が最終製品であるより大きなＢＯＭのごく一部を表し得る。すなわち、最終製品Ａ〜Ｃは、メーカーによって販売されるさまざまなモデルの自動車を表す。これらの自動車は、複数の排他的オプション（すなわち、オプションＡが選択される場合、オプションＢを選択することはできない）とともに販売することができる。たとえば、モデルＡの自動車は、革製シートまたは布製シートのいずれかを備えていてもよい。このようなオプションは、ＢＯＭでは組立品として表すことができ、組立品Ａは、革製シートを表してもよく、組立品Ｂは、布製シートを表してもよい。示されている実施形態では、上記を事実セットとしてとりあげると、モデルＣ（最終製品Ｃによって表される）は、組立品Ｂのシートのみを備えることになる。さらなる例として、組立品Ｃおよび組立品Ｄが異なるタイプのブレーキシステムを表し、組立品Ｃがアンチロックブレーキを表し、組立品Ｄがトラクションコントロールブレーキシステムを表すものとする。モデルＡ，ＢおよびＣの自動車は、任意に、アンチロックブレーキを備えていてもよく、またはトラクションコントロールブレーキシステムを備えていてもよい。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図２に示されているＢＯＭデータ構造では、部品Ｂは、組立品Ａにも組立品Ｂにも（革製シートにも布製シートにも）関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

ある実施形態に従って、ＢＯＭ次元は、さらに一般名称化されてもよく、ノードのレベルは、完成品（最上位）から組立品、部分組立品および部品に分類される。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、３層のデータ構造として図２に示されているが、より多くの層またはより少ない層を含んでいてもよく、材料の各系列は、どのレベルで終了してもよい（すなわち、全てが同一レベルの葉メンバであるとは限らない）。

上記および下記の例では、本明細書に記載されている例示的なＢＯＭのデータ次元は、自動車のモデルおよび部分組立品などの具体例の範囲内で説明されている。本開示はこのような具体例に限定されるものではなく、このような例は読みやすいように提供されているに過ぎない、ということを当業者は容易に理解するであろう。本明細書に記載されているデータ構造は、さまざまな用途で使用することができ、部品表はよい例である。したがって、本明細書における自動車業界に関連するＢＯＭを備えるものとしてのデータ構造の説明は、本開示を限定するものとして考えられるべきではなく、一般的概念を導き出すことができる実質的な例を提供するものとして考えられるべきである。

図３は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭ３００の形式のデータ構造の一例が図３に示されている。示されている例では、完成／最終製品次元３０１、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ３１０、モデルＢ３１１およびモデルＣ３１２を含む。ＢＯＭ内で、完成製品は、複数のより低いレベルの次元によって表される複数の排他的オプションによってさらに区別することができる。たとえば、示されているように、モデルＡの自動車は、革製シート３２０または布製シート３２１のいずれかを備えていてもよい。これは、モデルＢにもモデルＣにも当てはまるであろう。同様に、モデルＢの自動車は、アンチロックブレーキ３２２または常用ブレーキ３２３のいずれかを備えていてもよい。モデルＡおよびモデルＣの自動車も同様に、アンチロックブレーキまたは常用ブレーキを備えていてもよい。サンルーフ３２４の追加オプション／次元も提供されてもよい。

ある実施形態に従って、異なるレベルの次元間に重みパラメータを供給することができる。図３に示されている実施形態では、これらの重みパラメータは、下位の次元に対する各最上位次元の割合として示されている。このような重みパラメータは、割合、乗数、コストなどの形式を取ってもよい。このような重みパラメータは、異なる（または、時には同一の）レベルのデータ次元間のリンク関係に関連付けられたメタデータとして格納することができる。

ある実施形態に従って、このような重みパラメータは、動的に更新可能である。このような状況では、ＢＯＭの形式のデータ構造は、重みパラメータの変更に基づいてオンザフライで更新可能である。

ある実施形態に従って、さらに低い次元によって表されるさまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、示されているデータ構造では、部品３６０、パーツ３７０および部分組立品３８０は、中間レベルオプション次元の子次元であってもよい。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、自動車に対する需要をオプション（たとえば、組立品）に対する第１の需要に変換し、次いでこれらのオプションに対する需要をパーツ（たとえば、部品または部分組立品）に対する需要に変換することを可能にすることができる。自動車に対する需要は、オプション混合割合、すなわち自動車のオプションを選択する人々の割合を使用して、オプションに対する需要に変換可能である。図に示されているように、たとえば、モデルＡ３１０に対して１０００個の需要３５０があり、モデルＢ３１１に対して３２００個の需要３５１がある。

ある実施形態に従って、より低い次元に対する需要は、さらに、たとえば各々のより高い次元に対するさまざまな排他的オプションに対する需要の割合を示すことによって表すことができる。たとえば、図３に示されている例では、モデルＡのシートオプションに対する需要は、モデルＡにおける革製シートに対する需要が３５％であってもよく、モデルＡにおける布製シートに対する需要が６５％であってもよいとして表すことができる。また、モデルＢにおける革製シートに対する需要は７５％であってもよく、モデルＢにおける布製シートに対する需要は２５％であってもよい。そして、需要は、データ構造内で下向きに伝播させることができ（３４０）、これは、モデルＡに対する１０００個の車両需要のうちの３５％が３５０個の革製シートオプションの需要と６５０個の布製シートオプションの需要とに変換され得ることを意味している。同様に、３２００個の需要を有するモデルＢについても、需要をデータ構造内で下向きに伝播させることができる。この結果、モデルＢでは、２４００個の革製シートオプションの需要と８００個の布製シートオプションの需要になる。

ある実施形態に従って、オプションに対する需要は、さらに、同様の加重和技術を使用して、パーツ、部品および部分組立品などに対する需要を生成する。より低いレベルにおける需要が生成されると、データ構造は、逆に使用されて（上方向のコスト伝播３４５）、「自動車」レベルにおける「材料コスト」を求めることができる。そのために、データ構造は、パーツ需要数とパーツ単位コストとを乗算して、それらの値を逆方向に伝播させることができる。これにより、「コア材料」コストを求めることができる。次いで、これを自動車収益と比較して、売上総利益数を生成することができる。

図４は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭ４００の形式のデータ構造の一例が図４に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ４１０、モデルＢ４１１およびモデルＣ４１２を含む。これらの自動車は、一般に、さまざまな排他的オプション（すなわち、オプションＡが選択される場合、オプションＢを選択することはできない）とともに販売される。たとえば、示されているように、モデルＡの自動車は、革製シート４２０または布製シート４２１のいずれかを備えていてもよい。これは、モデルＢの自動車にも当てはまるであろうが、モデルＣの自動車は、布製シートオプションに限定される。同様に、モデルＢの自動車は、アンチロックブレーキ４２２またはトラクションコントロールブレーキシステム４２３のいずれかを備えていてもよい。モデルＡおよびモデルＣの自動車も同様に、アンチロックブレーキまたはトラクションコントロールブレーキシステムを備えていてもよい。

ある実施形態に従って、ＢＯＭは、さらに別のレベルの次元を含み得る。この第３のレベルは、部品Ａ〜Ｆ４３１〜４３６などの部品を備え得る。

ある実施形態に従って、異なるレベルの次元間に重みパラメータを供給することができる。図４に示されている実施形態では、これらの重みパラメータは、下位の次元に対する各最上位次元の割合、および、組立品当たりいくつの部品が必要であるかを示す乗数として示されている。このような重みパラメータは、割合、乗数、コストなどの形式を取ってもよい。このような重みパラメータは、異なる（または、時には同一の）レベルのデータ次元間のリンク関係に関連付けられたメタデータとして格納することができる。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図４に示されているデータ構造では、部品Ｂ４３２は、革製シートにも布製シートにも関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、自動車に対する需要をオプション（たとえば、組立品）に対する第１の需要に変換し、次いでこれらのオプションに対する需要をパーツ（たとえば、部品または部分組立品）に対する需要に変換することを可能にすることができる。自動車に対する需要は、オプション混合割合、すなわち自動車のオプションを選択する人々の割合を使用して、オプションに対する需要に変換可能である。図に示されているように、たとえば、モデルＡに対して１００００個の需要４５０があり、モデルＢに対して５０００個の需要４５１がある。

たとえば、図４に示されている実施形態では、モデルＡの自動車に対して１００００個の需要４５０が存在し、モデルＢの自動車に対して５０００個の需要４５１が存在する。そして、モデルＡにおける革製シートに対する需要は３５％であり、モデルＡにおける布製シートに対する需要は６５％であるなど、さまざまなオプションに対する需要を割り当てることができる。また、モデルＢにおける革製シートに対する需要は５０％であってもよく、モデルＢにおける布製シートに対する需要は５０％であってもよい。そして、需要は、データ構造内で下向きに伝播させることができ（４４０）（コストは上向きに伝播させることができる（４４５））、これは、１００００台の車両のうちの３５％または３５００個の革製シート組立品をモデルＡのために生産しなければならず、２５００個の革製シート組立品をモデルＢのために生産しなければならないことを意味している。同様に、６５００個の布製シート組立品をモデルＡのために生産しなければならず、２５００個の布製シートをモデルＢのために生産しなければならない。

ある実施形態に従って、オプションに対する需要が求められると、各オプションについてＢＯＭを考慮に入れることができる（たとえば、オプションを組み立てるのに必要な部品）。

ある実施形態に従って、この下向きの伝播をさらにとりあげると、モデルＡおよびＢのための、作成する必要がある合計６０００（３５００＋２５００）個の革製シート組立品のうち、シートの部品Ａ（たとえば、革張り物）を１２０００個供給しなければならず、部品Ｂ（たとえば、シート半完成品）を２４０００個供給しなければならない。

ある実施形態に従って、オプションに対する需要は、さらに、同様の加重和技術を使用して、パーツ、部品および部分組立品などに対する需要を生成する。より低いレベルにおける需要が生成されると、データ構造は、逆に使用されて（上方向のコスト伝播）、「自動車」レベルにおける「材料コスト」を求めることができる。そのために、データ構造は、パーツ需要数とパーツ単位コストとを乗算して、それらの値を逆方向に伝播させることができる。これにより、「コア材料」コストを求めることができる。次いで、これを自動車収益と比較して、売上総利益数を生成することができる。

図５は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭ５００の形式のデータ構造の一例が図５に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ５１０、モデルＢ５１１およびモデルＣ５１２を含む。これらの自動車は、一般に、さまざまな排他的オプション（すなわち、オプションＡが選択される場合、オプションＢを選択することはできない）とともに販売される。たとえば、示されているように、モデルＡの自動車は、革製シート５２０または布製シート５２１のいずれかを備えていてもよい。これは、モデルＢの自動車にも当てはまるであろうが、モデルＣの自動車は、布製シートオプションに限定される。同様に、モデルＢの自動車は、アンチロックブレーキ５２２またはトラクションコントロールブレーキシステム５２３のいずれかを備えていてもよい。モデルＡおよびモデルＣの自動車も同様に、アンチロックブレーキまたはトラクションコントロールブレーキシステムを備えていてもよい。

ある実施形態に従って、ＢＯＭは、さらに別のレベルの次元を含み得る。この第３のレベルは、部品Ａ〜Ｆ５３０〜５３５などの部品を備え得る。

ある実施形態に従って、図に示されているように、たとえば、モデルＡに対して１００００個の需要５５０があり、モデルＢに対して５０００個の需要５５１がある。

ある実施形態に従って、異なるレベルの次元間に重みパラメータを供給することができる。図５に示されている実施形態では、これらの重みパラメータは、下位の次元に対する各最上位次元の割合、および、組立品当たりいくつの部品が必要であるかを示す乗数として示されている。このような重みパラメータは、割合、乗数、コストなどの形式を取ってもよい。このような重みパラメータは、異なる（または、時には同一の）レベルのデータ次元間のリンク関係に関連付けられたメタデータとして格納することができる。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図５に示されているデータ構造では、部品Ｂは、革製シートにも布製シートにも関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、自動車に対する需要をオプション（たとえば、組立品）に対する第１の需要に変換し、次いでこれらのオプションに対する需要をパーツ（たとえば、部品または部分組立品）に対する需要に変換することを可能にすることができる。自動車に対する需要は、オプション混合割合、すなわち自動車のオプションを選択する人々の割合を使用して、オプションに対する需要に変換可能である。

ある実施形態に従って、図５は、データ構造内の関係に関連付けられた、図４に示されている実施形態からの重みの変化を表している。システムおよび方法は、このような重みのオンデマンドの変化（革製シートを有するモデルＡの車両が４０％の需要に増加し、布製シートに対する需要が６０％の需要に減少するなど）およびこのような重みの変化に基づいたデータ構造のオンザフライでの再計算を可能にすることができる。また、革製シートに対する部品Ａの重みも２ｘから４ｘに増加した。

たとえば、図５に示されている状況では、モデルＡにおける革製シートに対する需要は４０％であると新たに規定されてもよく、モデルＡにおける布製シートに対する需要は６０％であってもよい。また、モデルＢにおける革製シートに対する需要は５０％であってもよく、モデルＢにおける布製シートに対する需要は５０％であってもよい。そして、需要は、データ構造内で下向きに伝播させることができ（５４０）（コストは上向きに伝播させることができる（５４５））、これは、１００００台の車両のうちの４０％または４０００個の革製シート組立品をモデルＡのために生産しなければならず、２５００個の革製シート組立品をモデルＢのために生産しなければならないことを意味している。

この下向きの伝播をさらにとりあげると、モデルＡおよびＢのための、作成する必要がある合計６５００個の革製シート組立品のうち、シートの部品Ａ（たとえば、革張り物）を２６０００個供給しなければならず、部品Ｂ（たとえば、シート半完成品）を２６０００個供給しなければならない。

ある実施形態に従って、オプションに対する需要は、さらに、同様の加重和技術を使用して、パーツ、部品および部分組立品などに対する需要を生成する。より低いレベルにおける需要が生成されると、データ構造は、逆に使用されて（上方向のコスト伝播５４５）、「自動車」レベルにおける「材料コスト」を求めることができる。そのために、データ構造は、パーツ需要数とパーツ単位コストとを乗算して、それらの値を逆方向に伝播させることができる。これにより、「コア材料」コストを求めることができる。次いで、これを自動車収益と比較して、売上総利益数を生成することができる。

ある実施形態に従って、ＢＯＭ次元は、ノード関係の重みを有する有向非巡回グラフ（ＤＡＧ）を備え得て、このグラフには複数のレベルのノードが存在し得る。ノードは、メンバであり、重みは、メンバ間関係の属性である。

ある実施形態に従って、メンバは、１つまたは複数の親を有し得る。
ある実施形態に従って、上記のデータ構造は、加重和および加重割り当ての実施形態をサポートすることができる。

ある実施形態に従って、ＢＯＭ次元は、メンバの動的な作成および削除をサポートすることができる。同様に、ＢＯＭ次元は、ＢＯＭ次元のメンバ間の関係の動的な再割り当てをサポートすることができる。さらに、ＢＯＭ次元は、メンバ間関係の重みの動的な更新をサポートすることができる。

図６は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。より特定的に、図６は、特定のオプションに対する需要の下向きの伝播を強調している。

ある実施形態に従って、ＢＯＭ６００の形式のデータ構造の一例が図６に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ６１０、モデルＢ６１１およびモデルＣ６１２を含む。これらの自動車は、一般に、さまざまな排他的オプション（すなわち、オプションＡが選択される場合、オプションＢを選択することはできない）とともに販売される。たとえば、示されているように、モデルＡの自動車は、革製シート６２０または布製シート６２１のいずれかを備えていてもよい。これは、モデルＢの自動車にも当てはまるであろう。アンチロックブレーキ６２２およびトラクションコントロールブレーキ６２３などの追加オプションは、この例にとっては無関係である。

ある実施形態に従って、ＢＯＭは、さらに別のレベルの次元を含み得る。この第３のレベルは、部品Ａ〜Ｆ６３０〜６３５などの部品を備え得る。

ある実施形態に従って、図に示されているように、たとえば、モデルＡに対して１００００個の需要６５０があり、モデルＢに対して５０００個の需要６５１がある。同様に、部品Ａ〜Ｃに関連付けられたさまざまなコスト６５２〜６５４がある。

ある実施形態に従って、異なるレベルの次元間に重みパラメータを供給することができる。図６に示されている実施形態では、これらの重みパラメータは、下位の次元に対する各最上位次元の割合、および、組立品当たりいくつの部品が必要であるかを示す乗数として示されている。このような重みパラメータは、割合、乗数、コストなどの形式を取ってもよい。このような重みパラメータは、異なる（または、時には同一の）レベルのデータ次元間のリンク関係に関連付けられたメタデータとして格納することができる。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図６に示されているデータ構造では、部品Ｂは、革製シートにも布製シートにも関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

たとえば、図６に示されている状況では、モデルＡにおける革製シートに対する需要は、４０％であると規定されてもよい。また、モデルＢにおける革製シートに対する需要は、５０％であってもよい。そして、需要は、データ構造内で下向きに伝播させることができ、これは、１００００台の車両のうちの４０％または４０００個の革製シート組立品をモデルＡのために生産しなければならず、２５００個の革製シート組立品をモデルＢのために生産しなければならないことを意味している。

革製シート組立品の需要を有する自動車の合計が６５００台であるこの例を受けて、下向きの伝播をさらにとりあげると、シートの部品Ａ（たとえば、革張り物）を２６０００個供給しなければならず、革製シートオプションのために供給されるように２６０００個の部品Ｂ（たとえば、シート半完成品）が計算される。

ある実施形態に従って、および上記の例を続けて、図６に示されている状況では、モデルＡにおける革製シートに対する需要は６０％であると規定されてもよい。また、モデルＢにおける革製シートに対する需要は５０％であってもよい。そして、需要は、データ構造内で下向きに伝播させることができ、これは、１００００台の車両のうちの６０％または６０００個の革製シート組立品をモデルＡのために生産しなければならず、２５００個の革製シート組立品をモデルＢのために生産しなければならないことを意味している。

革製シート組立品の需要を有する自動車の合計が８５００台であるこの例を受けて、下向きの伝播をさらにとりあげると、シートの部品Ｃ（たとえば、布張り物）を１７０００個供給しなければならず、布製シートオプションのために供給されるように３４０００個の部品Ｂ（たとえば、シート半完成品）が計算される。

図７は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。より特定的に、図７は、特定のオプションに対するコストの上向きの伝播を強調している。

ある実施形態に従って、ＢＯＭ７００の形式のデータ構造の一例が図７に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ７１０、モデルＢ７１１およびモデルＣ７１２を含む。これらの自動車は、一般に、さまざまな排他的オプション（すなわち、オプションＡが選択される場合、オプションＢを選択することはできない）とともに販売される。たとえば、示されているように、モデルＡの自動車は、革製シート７２０または布製シート７２１のいずれかを備えていてもよい。これは、モデルＢの自動車にも当てはまるであろう。アンチロックブレーキ７２２およびトラクションコントロールブレーキ７２３などの追加オプションは、この例にとっては無関係である。

ある実施形態に従って、ＢＯＭは、さらに別のレベルの次元を含み得る。この第３のレベルは、部品Ａ〜Ｆ７３０〜７３５などの部品を備え得る。

ある実施形態に従って、図に示されているように、たとえば、モデルＡに対して１００００個の需要７５０があり、モデルＢに対して５０００個の需要７５１がある。同様に、部品Ａ〜Ｃに関連付けられたさまざまなコスト７５２〜７５４がある。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図７に示されているデータ構造では、部品Ｂは、革製シートにも布製シートにも関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、自動車に対する需要をオプション（たとえば、組立品）に対する第１の需要に変換し、次いでこれらのオプションに対する需要をパーツ（たとえば、部品または部分組立品）に対する需要に変換することを可能にすることができる。自動車に対する需要は、オプション混合割合、すなわち自動車のオプションを選択する人々の割合を使用して、オプションに対する需要に変換可能である。各サブ部品または部分組立品に対する需要を算出した後（たとえば、図６を参照）、サブ部品または部分組立品の単位当たりのコストを再び上向きに伝播させることができる。

たとえば、図７に示されている状況では、サブ部品Ａの部品当たりのコストは＄２００であり、サブ部品Ｂの部品当たりのコストは＄１００であり、サブ部品Ｃの部品当たりのコストは＄５０である。そして、革製シート組立品当たりのコストは＄１２００であり、布製シート組立品当たりのコストは＄５００である。各モデルに対する需要（図７に図示）をとりあげて、それと革製シート組立品および布製シート組立品当たりのコストとを乗算すると、モデルＡでは、革製シート組立品のコストが＄４．８Ｍになり、布製シート組立品のコストが＄３Ｍになる。モデルＢでは、革製シート組立品のコストが＄３Ｍになり、布製シート組立品のコストが＄１．２５Ｍになる。

図８は、ある実施形態に係る、重みを有する複数の親をイネーブルにするためのデータ構造の一例を示す。

図８に示されるように、ある実施形態に従って、データベース層として動作する多次元データベース環境は、１つ以上の多次元データベースサーバシステム８０２を含み得て、１つ以上の多次元データベースサーバシステム８０２の各々は、物理コンピュータリソースまたはコンポーネント８０４（たとえば、マイクロプロセッサ／ＣＰＵ、物理メモリ、ネットワークコンポーネント）と、オペレーティングシステム８０６と、１つ以上の多次元データベースサーバ８１０（たとえば、Ｅｓｓｂａｓｅサーバ）とを含み得る。

ある実施形態に従って、中間層８２０は、たとえばプロバイダサービス８２２、管理サービス８２４またはスタジオ／統合サービス８２６などの１つ以上のサービスを含み得る。中間層は、多次元データベース環境とともに使用するために、ＯＤＢＣ／ＪＤＢＣ８２７，８２８または他のタイプのインターフェイスを介してメタデータカタログ８２９および／または１つ以上のデータソース８３０（たとえば、リレーショナルデータベース）へのアクセスを提供することができる。

ある実施形態に従って、１つ以上のデータソースは、多次元データベースの提供に使用するために、ＯＤＢＣ／ＪＤＢＣ８３２または他のタイプのインターフェイスを介して１つ以上の多次元データベースサーバによってアクセス可能でもある。

ある実施形態に従って、クライアント層８４０は、多次元データベース（たとえば、スマートビュー、スプレッドシートアドイン、スマートサーチ、管理サービス、ＭａｘＬ、ＸＭＬＡ、ＣＡＰＩまたはＶＢＡＰＩアプリケーション、オラクル・ビジネス・インテリジェンス・エンタープライズ・エディション・プラス、または他のタイプの多次元データベースクライアントなど）へのアクセスを可能にする１つ以上の多次元データベースクライアント８４２を含み得る。クライアント層は、たとえば管理サービスコンソール８４４またはスタジオ／統合サービスコンソール８４６などの、中間層におけるサービスとともに使用するためのコンソールも含み得る。

ある実施形態に従って、多次元データベースサーバは、１つ以上のデータソースからのデータを統合して、多次元データベースまたはデータ構造８５０を提供することができ、次いで、多次元データベースまたはデータ構造８５０にアクセスして、フィルタリングされた情報をエンドユーザに提供することができる。ある実施形態に従って、データ構造は、複数レベルのデータ構造を備え得て、特定のデータ次元は、複数の親と、異なる次元間のメタデータとして供給される重みとを有する。このようなデータ構造は、たとえば部品表の形式であってもよい。

図９は、ある実施形態に係る、多次元データベースにおいて重みを有する複数の親をイネーブルにするための方法のフローチャートである。

ステップ９１０において、方法は、コンピュータ上で実行される多次元データベースサーバを提供し得て、多次元データベースサーバは、データ次元の少なくとも１つの階層構造をサポートする。

ステップ９２０において、方法は、第１のレベルにある第１のメンバセットと第２のレベルにある第２のメンバセットとを少なくとも備える複数のメンバをデータ次元の階層構造内に提供し得て、第２のレベルにおける第２のメンバセットのうちのあるメンバは、第１のレベルにおける第１のメンバセットのうちの２つ以上のメンバとの２つ以上のメンバ間関係を備える。

ステップ９３０において、方法は、２つ以上のメンバ間関係の各々を複数の重みのうちのある重みに関連付け得る。

共有メンバを使用する複数の親
図１０は、ある実施形態に係る、共有メンバを使用する複数の親をモデル化するためのデータ構造の一例を示す。より特定的に、図１０は、特定のオプションに対する需要の下向きの伝播を強調している。

ある実施形態に従って、ＢＯＭの形式のデータ構造の一例が図１０に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ１０１０およびモデルＢ１０１１を含む。これらの自動車は、一般に、さまざまなオプション（そのうちのいくつかは排他的であってもよい）とともに販売される。たとえば、示されているように、モデルＡの自動車は、革製シート１０２０または布製シート１０２１のいずれかを備えていてもよい。これは、モデルＢの自動車にも当てはまるであろう。

ある実施形態に従って、さまざまな部品もデータ構造内に提供されてもよく、特定の部品は、１つまたは複数のより高いレベルの部品に関連付けられてもよい。たとえば、図１０に示されているデータ構造では、部品Ｂは、革製シートにも布製シートにも関連付けられる。このような部品は、たとえばシート半完成品（たとえば、張り物をされていないシート）であってもよく、部品Ａは、革であってもよく、部品Ｃは、シート半完成品に張るために使用される布であってもよい。

ある実施形態に従って、ＢＯＭを表すこのようなデータ構造は、自動車に対する需要１０５０および１０５１をオプション（たとえば、組立品）に対する第１の需要に変換し、次いでこれらのオプションに対する需要１０４０をパーツ（たとえば、部品または部分組立品）に対する需要に変換することを可能にすることができる。自動車に対する需要は、オプション混合割合、すなわち自動車のオプションを選択する人々の割合を使用して、オプションに対する需要に変換可能である。

ある実施形態に従って、システムおよび方法は、このような重みのオンデマンドの変化（たとえば、モデルＡが革製シートに関して３５％から４０％に変化する重みを有し、布製シートに関して６５％から６０％に変化する重みを有する場合）およびこのような重みの変化に基づいたデータ構造のオンザフライでの再計算を可能にすることができる。

この下向きの伝播をさらにとりあげると、モデルＡおよびＢのための、作成する必要がある合計６５００個の革製シート組立品のうち、シートの部品Ａ１０３１（たとえば、革張り物）を２６０００個（すなわち、更新された４ｘ重み）供給しなければならず、６００００個の部品Ｂ１０３２（たとえば、シート半完成品）および１７０００個の部品Ｃが計算される。

ある実施形態に従って、オプションに対する需要は、さらに、同様の加重和技術を使用して、パーツ、部品および部分組立品などに対する需要を生成する。より低いレベルにおける需要が生成されると、データ構造は、逆に使用されて（上方向のコスト伝播１０４５）、「自動車」レベルにおける「材料コスト」を求めることができる。そのために、データ構造は、パーツ需要数とパーツ単位コストとを乗算して、それらの値を逆方向に伝播させることができる。これにより、「コア材料」コストを求めることができる。次いで、これを自動車収益と比較して、売上総利益数を生成することができる。

ある実施形態に従って、ＢＯＭ次元は、重みがメタデータとしての関連付けられたノード関係である有向非巡回グラフ（ＤＡＧ）を備え得て、このグラフには複数のレベルのノードが存在し得る。ノードは、メンバであり、重みは、メンバ間関係の属性である。

ある実施形態に従って、上記のデータ構造は、加重和および加重割り当ての実施形態をサポートすることができる。

ある実施形態に従って、図１０に示されるデータ構造は、メンバの動的な作成および削除をサポートすることができる。同様に、ＢＯＭ次元は、ＢＯＭ次元のメンバ間の関係の動的な再割り当てをサポートすることができる。さらに、ＢＯＭ次元は、メンバ間関係の重みの動的な更新をサポートすることができる。

図１１は、ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭの形式のデータ構造の一例が図１１に示されている。示されている例では、最終製品、たとえば自動車のモデル（すなわち、モデルＡおよびＢ１１１０および１１１１）は、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡおよびモデルＢを含む。同様に、図１０に見られるように、根レベルよりも低いレベルの特定の次元は、複数の親を備え得る。すなわち、革製シートオプションも布製シートオプションも複数の親をサポートする。

ある実施形態に従って、計算を簡素化して動的な再計算をサポートするために、各次元が親を１つだけサポートするように、複数の親を有する次元をコピー／複製することができる。

ある実施形態に従って、データ構造の中間レベルでは、「革製シート」１１２０次元も「布製シート」１１２１次元も複数の親を有する。次いで、これらのデータ次元は、親関係が１つだけ存在するように複製される。そして、複製されたデータ次元１１２５および１１２６は、別々のデータ構造であると考えることができる。

これは、革製シートオプションも布製シートオプションも、中間レベルにおける各次元が親を１つだけサポートするようにコピーされた（破線によって図示）図１１に示されている。このような状況における需要の下向きの伝播は、それに応じて自動的に計算／更新される。

ある実施形態に従って、需要伝播１１４０が引き継がれ、次いで１１３１〜１１３６において部品次元が再計算されることに留意されたい。同様に、図示されていないが、コスト伝播１１４５も（自動的に）再計算され得る。

図１２は、ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭの形式のデータ構造の一例が図１２に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ１２１０およびモデルＢ１２１１を含む。同様に、先の図に見られるように、根レベルよりも低いレベルの特定の次元は、複数の親を備え得る。すなわち、革製シートオプション１２２０も布製シートオプション１２２１も複数の親をサポートする。さらに、最下位レベルにおけるさまざまなデータ次元は、部品１２３１〜１２３８であり得る。

これは、部品Ｂが複数の親（革製シートおよび布製シートの両方）（図１１を参照）をサポートする図１２に示されている。そして、このような状況では、部品Ｂの各インスタンスが親を１つだけサポートするように、部品Ｂを表すデータ次元をコピー／複製することができる。このような状況における需要の下向きの伝播は、それに応じて更新される。

ある実施形態に従って、次いで、部品Ｂ１２３２および１２３６が各々のそれぞれの木１２３３および１２３７内に複製される。需要の下向きの伝播１２４０は、自動的に更新および再計算される。

図１３は、ある実施形態に係る、共有メンバを使用する複数の親をイネーブルにするためのデータ構造の一例を示す。

ある実施形態に従って、ＢＯＭの形式のデータ構造の一例が図１３に示されている。示されている例では、最終製品、たとえば自動車のモデルは、ＢＯＭを表すデータ構造の最上位に示されている。これらのモデルは、モデルＡ１２１０およびモデルＢ１２１１を含む。同様に、先の図に見られるように、根レベルよりも低いレベルの特定の次元は、複数の親を備え得る。すなわち、革製シートオプション１２２０も布製シートオプション１２２１も複数の親をサポートする。さらに、最下位レベルにおけるさまざまなデータ次元は、部品１２３１〜１２３８であり得る。

これは、革製シートデータ次元も布製シートデータ次元もコピー／複製されており、部品Ｂが複数の親（革製シートおよび布製シートの両方）をサポートする図１３に示されている。そして、このような状況では、部品Ｂの各インスタンスが親を１つだけサポートするように、部品Ｂをコピー／複製することができる。したがって、各「共有」メンバ（すなわち、共有メンバは、複数の親次元をサポートする子である）が親を１つだけサポートするようにコピー／複製されているので、各部品から開始するコスト（１３６１〜１３６８）の上向きの伝播は、簡素化される。

ある実施形態に従って、あらゆるレベルにおいてコストが存在する。コストの伝播を行う際、システムおよび方法は、全てのその子を反復的に横断し、その総コストを得て、それとスケールファクタとを乗算する（たとえば、自転車は２つのタイヤを必要とし、システムおよび方法は親に向かって上に横断するので、タイヤのコストに２を乗算する）。次いで、システムおよび方法は、親レベルにおいて追加コストを追加することができる。サポートされたシステムおよび方法は、別のキューブ「ＢＯＭ＿テーブル」を使用して、ＸＲＥＦを使用して、スケールファクタを探索することができる。

ある実施形態に従って、複数の親を有する共有メンバが上記のように使用される場合、システムおよび方法は、スケールファクタ（たとえば、コスト、必要な部品数など）の動的な変化をある期間にわたってサポートする。たとえば、図１３における部品Ａと革製シート組立品との間のスケールファクタが４ｘから２ｘに変更されると、新たなスケールファクタを有する部品Ａ（たとえば、部品Ａ′）について新たな次元が作成され得る。このように、元のスケールファクタが有効でなくなった時点で、新たなスケールファクタを利用しながら、革製シートから部品Ａを指し示しているのが、部品Ａ′を指し示すように更新され得る。このプロセスは、製造プロセスでは設計変更指示と称することができ、共有メンバを使用する複数の親は、このような変更をデータ構造環境においてモデル化することを可能にする。

以下の擬似コードは、ある実施形態に係るサポートされたアルゴリズムのためのモデル化表現を表す。

本発明のさまざまな実施形態について上記したが、それらは限定ではなく例として提示されているということが理解されるべきである。これらの実施形態は、本発明の原理およびその実際的用途を説明するために選択されて説明された。これらの実施形態は、本発明が利用されるシステムおよび方法を示しており、新たなおよび／または改良された特徴を提供することによって、および／または、リソース利用の減少、容量の増加、効率の改善およびレイテンシの減少などのメリットを提供することによってシステムおよび方法の性能を向上させる。

いくつかの実施形態では、本発明の特徴は、全体または一部が、プロセッサと、メモリなどの記憶媒体と、他のコンピュータと通信するためのネットワークカードとを含むコンピュータにおいて実現される。いくつかの実施形態では、本発明の特徴は、コンピュータの１つ以上のクラスタが、ローカルエリアネットワーク（ＬＡＮ）、スイッチファブリックネットワーク（たとえば、インフィニバンド）またはワイドエリアネットワーク（ＷＡＮ）などのネットワークによって接続される分散コンピューティング環境において実現される。分散コンピューティング環境は、単一の位置に全てのコンピュータを有していてもよく、またはＷＡＮによって接続されたさまざまな遠隔の地理的位置にコンピュータのクラスタを有していてもよい。

いくつかの実施形態では、本発明の特徴は、全体または一部が、ウェブ技術を使用してセルフサービスの計量の態様でユーザに届けられる共有の融通性のあるリソースに基づいて、クラウドコンピューティングシステムの一部として、またはクラウドコンピューティングシステムのサービスとして、クラウドにおいて実現される。（アメリカ国立標準技術研究所によって定義されるように）クラウドの特徴は５つある。すなわち、オンデマンド・セルフサービス、幅広いネットワークアクセス、リソースの共用、スピーディな拡張性、およびサービスが計測可能であること、である。たとえば、「クラウドコンピューティングのＮＩＳＴ定義」（Special Publication 800-145 （2011））を参照されたい。これは、引用によって本明細書に援用される。クラウド実装モデルは、パブリック、プライベートおよびハイブリッドを含む。クラウドサービスモデルは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）、プラットフォーム・アズ・ア・サービス（ＰａａＳ）、データベース・アズ・ア・サービス（ＤＢａａＳ）、およびインフラストラクチャ・アズ・ア・サービス（ＩａａＳ）を含む。本明細書におけるクラウドは、ハードウェアと、ソフトウェアと、ネットワークと、共有の融通性のあるリソースをセルフサービスの計量の態様でユーザに届けるウェブ技術との組み合わせである。本明細書におけるクラウドは、別段の定めがない限り、パブリッククラウドの実施形態、プライベートクラウドの実施形態、ハイブリッドクラウドの実施形態、ならびにクラウドＳａａＳ、クラウドＤＢａａＳ、クラウドＰａａＳおよびクラウドＩａａＳを含むがこれらに限定されない全てのクラウド実装モデルを包含する。

いくつかの実施形態では、本発明の特徴は、ハードウェア、ソフトウェア、ファームウェアもしくはそれらの組み合わせを使用して、またはハードウェア、ソフトウェア、ファームウェアもしくはそれらの組み合わせの助けを借りて、実現される。いくつかの実施形態では、本発明の特徴は、本発明の１つ以上の機能を実行するように構成またはプログラムされたプロセッサを使用して実現される。いくつかの実施形態では、プロセッサは、本明細書に記載されている機能を実行するように設計されたシングルチップもしくはマルチチッププロセッサ、デジタル信号プロセッサ（ＤＳＰ）、システムオンチップ（ＳＯＣ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）もしくは他のプログラマブルロジックデバイス、ステートマシン、ディスクリートのゲートもしくはトランジスタロジック、ディスクリートのハードウェアコンポーネント、またはそれらの任意の組み合わせである。いくつかの実現例では、本発明の特徴は、所与の機能に特有の回路によって実現されてもよい。他の実現例では、これらの特徴は、たとえばコンピュータ読取可能記憶媒体上に格納された命令を使用して特定の機能を実行するように構成されたプロセッサにおいて実現されてもよい。

いくつかの実施形態では、本発明の特徴は、処理システムおよび／またはネットワーキングシステムのハードウェアを制御するため、ならびに、プロセッサおよび／またはネットワークが本発明の特徴を利用する他のシステムと対話することを可能にするためのソフトウェアおよび／またはファームウェアに組み込まれる。このようなソフトウェアまたはファームウェアは、アプリケーションコード、デバイスドライバ、オペレーティングシステム、仮想マシン、ハイパーバイザ、アプリケーションプログラミングインターフェイス、プログラミング言語および実行環境／コンテナを含み得るが、これらに限定されるものではない。適切なソフトウェアコーディングは、ソフトウェア分野における当業者に明らかであるように、本開示の教示に基づいて熟練のプログラマによって容易に準備することができる。

いくつかの実施形態では、本発明は、命令が格納された記憶媒体またはコンピュータ読取可能媒体であるコンピュータプログラム製品を含み、これらの命令を使用して、本発明のプロセスまたは機能のうちのいずれかを実行するようにコンピュータなどのシステムをプログラムまたはそうでなければ構成することができる。記憶媒体またはコンピュータ読取可能媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブおよび光磁気ディスクを含むいずれかのタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適したいずれかのタイプの媒体もしくはデバイスを含み得るが、これらに限定されるものではない。特定の実施形態では、記憶媒体またはコンピュータ読取可能媒体は、非一時的な記憶媒体または非一時的なコンピュータ読取可能媒体である。

上記の説明は、網羅的であるよう意図されたものではなく、本発明を開示されている厳密な形態に限定するよう意図したものでもない。また、特定の一連のトランザクションおよびステップを使用して本発明の実施形態を説明してきたが、本発明の範囲が記載されている一連のトランザクションおよびステップに限定されないということは当業者に明らかであるべきである。さらに、ハードウェアおよびソフトウェアの特定の組み合わせを使用して本発明の実施形態を説明してきたが、ハードウェアおよびソフトウェアの他の組み合わせも本発明の範囲内であるということが認識されるべきである。さらに、さまざまな実施形態は、本発明の特徴の特定の組み合わせを説明しているが、特徴の異なる組み合わせが本発明の範囲内であって１つの実施形態の特徴を別の実施形態に組み込むことができるものとして当業者に明らかであるということが理解されるべきである。さらに、形状、詳細、実現および用途の点でのさまざまな追加、削減、削除、変更および他の変形が本発明の精神および範囲から逸脱することなく本明細書においてなされてもよいということが当業者に明らかであろう。変更および変形は、開示されている特徴および／または実施形態の関連する組み合わせを含む。本発明のより広い精神および範囲は、以下の特許請求の範囲およびそれらの等価物によって定義されるよう意図される。

Claims

多次元データベースにおいて重みを有する複数の親をイネーブルにするための方法であって、
コンピュータ上で実行される多次元データベースサーバを提供するステップを備え、前記多次元データベースサーバは、データ次元の少なくとも１つの階層構造をサポートし、前記方法はさらに、
第１のレベルにある第１のメンバセットと第２のレベルにある第２のメンバセットとを少なくとも備える複数のメンバを前記データ次元の階層構造内に提供するステップを備え、前記第２のレベルにおける前記第２のメンバセットのうちのあるメンバは、前記第１のレベルにおける前記第１のメンバセットのうちの２つ以上のメンバとの２つ以上のメンバ間関係を備え、前記方法はさらに、
前記２つ以上のメンバ間関係の各々を複数の重みのうちのある重みに関連付けるステップを備える、方法。
前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々を複数の需要値のうちのある需要値に関連付けるステップをさらに備える、請求項１に記載の方法。
前記第２のレベルにおける前記第２のメンバセットのうちの前記メンバとの前記２つ以上のメンバ間関係の各々に沿って、前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々に関連付けられた前記需要値の各々を伝播させるステップをさらに備える、請求項２に記載の方法。
前記需要値の各々を伝播させるステップは、前記２つ以上のメンバ間関係の各々に関連付けられた前記重みを利用する、請求項３に記載の方法。
クライアント層から受け取られた入力に基づいて、前記２つ以上のメンバ間関係の各々に関連付けられた前記複数の重みのうちの前記重みの各々を変更するステップをさらに備える、請求項４に記載の方法。
前記２つ以上のメンバ間関係の各々に関連付けられた前記変更された重みに基づいて、前記２つ以上のメンバ間関係の各々に沿った前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々に関連付けられた前記需要値の各々の前記伝播を更新するステップをさらに備える、請求項５に記載の方法。
前記需要値の各々の前記伝播を更新するステップは、前記クライアント層から受け取られた前記入力に基づいてリアルタイムで行われる、請求項６に記載の方法。
多次元データベースにおいて重みを有する複数の親をイネーブルにするためのシステムであって、
１つ以上のマイクロプロセッサを含むコンピュータと、
前記コンピュータ上で実行されるように構成された多次元データベースサーバとを備え、前記多次元データベースサーバは、データ次元の少なくとも１つの階層構造をサポートし、
前記データ次元の階層構造は、複数のメンバを備え、前記複数のメンバは、第１のレベルにある第１のメンバセットと、第２のレベルにある第２のメンバセットとを備え、
前記第２のレベルにおける前記第２のメンバセットのうちのあるメンバは、前記第１のレベルにおける前記第１のメンバセットのうちの２つ以上のメンバとの２つ以上のメンバ間関係を備え、
前記２つ以上のメンバ間関係の各々は、複数の重みのうちのある重みに関連付けられる、システム。
前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々は、複数の需要値のうちのある需要値に関連付けられる、請求項８に記載のシステム。
前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々に関連付けられた前記需要値の各々は、前記第２のレベルにおける前記第２のメンバセットのうちの前記メンバとの前記２つ以上のメンバ間関係の各々に沿って伝播される、請求項９に記載のシステム。
前記需要値の各々を伝播させることは、前記２つ以上のメンバ間関係の各々に関連付けられた前記重みを利用する、請求項１０に記載のシステム。
前記２つ以上のメンバ間関係の各々に関連付けられた前記複数の重みのうちの前記重みの各々は、クライアント層から受け取られた入力に基づいて変更される、請求項１１に記載のシステム。
前記２つ以上のメンバ間関係の各々に沿った前記第１のレベルにおける前記第１のメンバセットのうちの前記２つ以上のメンバの各々に関連付けられた前記需要値の各々の前記伝播は、前記２つ以上のメンバ間関係の各々に関連付けられた前記変更された重みに基づいて更新される、請求項１２に記載のシステム。
前記需要値の各々の前記伝播を更新することは、前記クライアント層から受け取られた前記入力に基づいてリアルタイムで更新される、請求項１３に記載のシステム。
機械読取可能な形式のプログラム命令を備えるコンピュータプログラムであって、前記プログラム命令は、コンピュータシステムによって実行されると、請求項１〜７のいずれか１項に記載の方法を前記コンピュータシステムに実行させる、コンピュータプログラム。
請求項１〜７のいずれか１項に記載の方法を実行するための手段を備える装置。