Clever Geek Handbook

XBRL：複雑さについて-第5章新しい次元の発見

5.新しい次元の発見



前の章では、XBRLの概要とXBRLでできることを示しました。 既にご存じのとおり、これは拡張可能な標準です。 この章では、標準仕様を拡張するモジュールの1つであるXBRL Dimensionsについて検討します。







この章は、2006年6月19日のXBRL Dimensions仕様バージョン1.0 CRに基づいています。 執筆時点では、この仕様は勧告候補の状態にありますが、最終バージョンでは大きな驚きはないものと思われます。







XBRL仕様自体に関して、この章では、XBRLディメンションの基本的な理解を深めるために必要ないくつかの重要なポイントを強調しています。 残りのニュアンスは、完全な仕様に記載されています。







5.1。 はじめに



通常、レポートのファクトは何らかの方法で分類されます。たとえば、次のとおりです。









これらのカテゴリのうちの2つは、XBRL仕様で明示的に定義されています-期間およびレポートコンパイラ（会社、部門、会社部門）。 これらのカテゴリは、レポートのファクトによって参照されるコンテキストに常に存在します。







分類法の作成者が製品ライン、性別などの独自のカテゴリを示すことができるようにこれらの機能を拡張したいという要望は非常に自然です。 これはまさにXBRL Dimensionsが行うことです。 この仕様では、このようなカテゴリをディメンションと呼びます。







XBRL仕様で定義されているように、コンテキストに含まれるスクリプトとセグメントには、有効なXMLコンテンツを含めることができます。 XBRL Dimensionsは、そのような要素を使用して新しいディメンション（カテゴリ）をコンテキストに追加する正式な方法を定義しています。







前に使用した例は、以下を説明するのに非常に適しています。

nr_employeesの概念といくつかのディメンションを定義する必要があります。値{'men'、 'women'}を持つ性別（gender）と値{'...– 20'、'21 –40 '、'を持つ年齢層（年齢層） 41– ... '}。



レポートには、期間とディメンションの各組み合わせのコンテキストのセットが含まれ、各コンテキストには独自の事実があります。

コンテキスト 事実
01-01-2015 nr_employees = 35
01-01-2015 + '男性' nr_employees = 23
01-01-2015 +「女性」 nr_employees = 12
01-01-2015 + '...– 20' nr_employees = 5
01-01-2015 + '21 –40 ' nr_employees = 23
01-01-2015 + '41-... ' nr_employees = 7
2015年12月31日 nr_employees = 41
2015/12/31 +「男性」 nr_employees = 27
2015/12/31 +「女性」 nr_employees = 15
12/31/2015 + '...– 20' nr_employees = 9
12/31/2015 + '21 –40 ' nr_employees = 21
12/31/2015 + '41-... ' nr_employees = 11




5.1.1。 測定の概念



XBRL Dimensions仕様では、ここで簡単に説明する多くの概念を使用しており、次のセクションで詳細に説明します。









この仕様では、3種類の分類法を定義しています。 この3つのタイプへの分割は概念にすぎません。 3つの別個の分類法を使用できますが、仕様では、タイプごとに別個の分類法を使用する必要はありません。 1つの分類法で異なるタイプを組み合わせることは、まったく正常です。 概念をある関係の主要な概念として、また別の関係の次元の要素として使用することさえ許されています。


5.2。 ディメンション分類



このセクションでは、分類法を拡張してXBRL Dimensions仕様を適用する方法について説明します。 すべてのコンポーネントがどのように相互接続されているかを示すアーキテクチャ図から始めます。







画像







次のサブセクションでは、アーキテクチャの各コンポーネントについて詳しく説明します。







5.2.1。 測定



DMTは、置換グループ属性のxbrldt:dimensionItem



値を使用して、ディメンションを抽象アイテム概念として定義します。







注：属性xbrli:balance



、 xbrli:periodType



およびnillable



無視されます。







前述のように、ディメンションは型指定または明示的に指定できます。各ディメンションは、ドメイン要素を定義する独自の方法を使用します。







5.2.1.1。 型付きディメンション


型付きドメインの定義には、 xbrldt:typedDomainRef



値が必要xbrldt:typedDomainRef



は、ディメンションドメインを定義する要素の宣言を参照します。







ドメインは、XMLスキーマタイプを使用して定義されます。









5.2.1.2。 明示的な次元


明示的なディメンションドメインは、 dimension-domain



からドメインメンバー間のドメインメンバー関係ネットワークのルートまでのディメンションdimension-domain



関係によって識別されます。 明示的なディメンションにxbrldt:typedDomainRef



含めることはできません。







測定ドメインの要素はすべて、 domain-member



通信ネットワークのqname要素です。 各要素は、置換グループ属性のxbrli:item



値を持つアイテム概念の定義です（ xbrldt:hypercubeItem



xbrldt:dimensionItem



またはxbrldt:dimensionItem



グループに属することはできません）。







domain-member



は、要素の階層を形成します。 たとえば、階層にメンバーを追加して、ドメインメンバーとして使用することを意図していないネストされた階層のルートを作成できます。 これを行うために、デフォルトでtrue



に設定されているusable



ブール属性はfalse



示しfalse



。







明示的なディメンションには、デフォルトメンバーを指定できます。これは、ドメインメンバーとのdimension-default



関連付けを使用して行われdimension-default



。 このデフォルト値は、ディメンションメンバーが指定されていない場合にコンテキストで使用されます。 デフォルト値自体は、コンテキストで明示的に指定することはできず、常に自動的に決定されます。







dimension-default



関連付けは、それ自体ではドメインに要素を追加せず、ドメインとdomain-member



関連付けと同等ではないことに注意してください。







5.2.2。 domain-member



関係と継承


プライマリコンセプトは、プライマリコンセプト間のdomain-member



関係を指定することにより、他のプライマリコンセプトのハイパーキューブを継承できます。







2つの主要な概念があり、1つ（項目）がhc_ageハイパーキューブに関連付けられ、もう1つ（別の項目）が最初の概念とのdomain-member



関係に関連付けられているとしdomain-member



。



画像



最初の概念にはhc_ageハイパーキューブを介してage_groupディメンションとの接続があり、2番目の概念には最初のコンセプトとのdomain-member



接続があるため、2番目の概念は age_groupディメンションを継承します。


5.2.3。 ハイパーキューブ


ハイパーキューブは、ゼロ（ハイパーキューブが空の場合もあります）とその他のディメンションを組み合わせることにより、テンプレート分類法で定義されます。







declare要素は、置換グループ属性のxbrldt:hypercubeItem



値をxbrldt:hypercubeItem



なければならない抽象的な概念です。







ディメンションは、 hypercube-dimension



ロールを持つハイパーキューブアークに関連付けられています。 これらの関係は、各アークのorder



属性の値によって順序付けられます。 アークは環状結合を形成できません。







5.2.4。 主要概念とハイパーキューブの関係


ディメンションを使用して分類法を作成する場合、各概念を関連付けることができるディメンションを制御できます。 テンプレート分類法は、プライマリコンセプトとハイパーキューブコンセプト間のhas-hypercube



関係を介しhas-hypercube



、ハイパーキューブとプライマリコンセプト間の関係を定義することにより、この機能を提供します。







has-hypercube



notAll



接続には、 all



とnotAll



2つのタイプがあります。









これらのタイプの関係の組み合わせにより、各概念の測定および測定要素の構成を正確に制御できます。







2つのハイパーキューブがあるとします。



画像



タイプがall



キューブ、hc_age_x_genderのhas-hypercube



hypercube接続をhas-hypercube



主な概念は、すべての性別およびage_groupディメンションを持つことができます。 この概念に、タイプnotAll



とnotAll



ハイパーキューブの関係を追加すると、性別ディメンションの「女性」要素と、age_groupディメンションの「...– 20」要素にアクセスできなくなります。

has-hypercube



関係は、コンテキストのどの部分でディメンションを定義する必要があるか（ segment



またはscenario



）を示すcontextElement



ます。これには、 contextElement



属性がcontextElement



ます。









ハイパーキューブディメンション内の要素のみがコンセプトで利用可能であることを示すために、 has-hypercube



接続のオプションのブール型のclosed



属性でtrue



指定されます。 この属性は、リンクのcontextElement



属性の値に応じたスクリプトセグメントにのみ適用されます。 デフォルト値はfalse



で、セグメントまたはスクリプトを開いたままにします。







5.2.5。 ディメンションリレーションシップセット（DRS）



XBRLディメンションで定義された関係は、定義リンクベースに含まれています。 XBRL仕様によると、関係はその役割に従ってネットワーク上でグループ化されます。 これは、基本的な関係のセットと呼ばれます。







XBRL Dimensions仕様は、 all



、 notAll



、 notAll



hypercube-dimension



、 dimension-domain



domain-member



などのリンクタイプにtargetRole



属性を導入することにより、コアセットの概念を拡張しdomain-member



。 targetRole



属性は別のロールを参照し、1つのベースセット内のリンクのベースから、属性で指定されたロールを持つベースセット内のリンクのベースへの遷移を定義します。 このようなグループ化された関係のセットは、ディメンション関係セット、DRSと呼ばれます。







DRSの作成は、ディメンションの分類がより複雑になった場合に役立ち、必要になることさえあります。 DRSがないと、要素が属していないディメンションに要素を含めたり、間違ったハイパーキューブにディメンションを追加したりする可能性があります。 意味をなさない、または矛盾して無効であることが判明する可能性のある関係のセットを簡単に取得できます。







XBRL仕様で定義されているように、関係はベースセットの境界の外側に存在するため、リンク（ロール）のベースから別のベースへの移行のこのメカニズムにより、分類法またはレポートの検証プロセスはより複雑になります。



XBRL Dimensions仕様では、連続した関係の概念を使用しています。 これは、たとえば、ハイパーキューブの要素が最初にhypercube-dimension



関係によって決定され、次に見つかったすべてのディメンションについて、各domain-member



関係に対して順番に決定されることを意味しdomain-member



。



targetRole



属性値が定義されていない場合、連続するすべての関係はリンクベースの同じ役割内にあります。 この属性がアークに存在する場合、関係の検索は、指定されたロールを持つリンクデータベースに入ります。 この場合の元のリンクデータベース（ロール）のシリアル関係は存在しません。



シーケンシャルとして結合できるリレーションシップは、論理的に予想されるものに制限されますnotAll



has-hypercube



notAll



（ all



、 notAll



） notAll



は、リレーションシップをスキップするため、 dimension_domain



またはdomain_member



ではなく、 notAll



をシーケンシャルリレーションシップとして持つことができます。


5.3。 XBRLレポートのディメンション



概要で説明したように、ディメンションはレポートコンテキストのセグメントまたはシナリオで使用されます。 これらの選択は、 has-hypercube



contextElementType



接続のcontextElementType



属性を使用してcontextElementType



ます。







5.3.1。 ディメンション要素のタイプ



5.3.1.1。 型付きメンバー



型付きディメンションの場合、値はセグメントまたはスクリプト内のxbrldi:typedMember



子として指定されます。 そのような要素のdimension



属性は、型付き次元の定義を参照する必要があります。 typedMember



のコンテンツは、 xbrldt:typedDomainRef



指定されたディメンションのようなタイプの要素xbrldt:typedDomainRef



。 ディメンションの値は、このメンバーの値です。







0から（楽観主義者になります）150までの整数値を持つageタイプのageDimディメンションがあるとします。ディメンション45の値は、たとえば次のようなセグメント内の年齢の子として設定されます。 



 <xbrldi:typedMember dimension=”d:ageDim”> <d:age>45</d:age> </xbrldi:typedMember>




5.3.1.2。 明示的なメンバー



明示的な測定の場合、値はxbrldi:explicitMember



要素を使用して指定されます。 そのような要素のdimension



属性は、明示的な次元の定義を参照する必要があります。 ディメンションの値はこの要素のコンテンツであり、明示的に定義されたディメンション値のいずれかのqname要素でなければなりません。







次のメンバーが明示的に定義されたageGroupDimディメンションがあるとします：ageLessThan20、ageFrom21To40およびage41OrMore。 21〜40歳のグループのディメンション値は、たとえば次のようにセグメント内の子によって設定されます。 



 <xbrldi:explicitMember dimension=”d:ageGroupDim”>d:ageFrom21To40</xbrldi:explicitMember>




5.3.2。 検証



XBRL Dimensions仕様は、XBRL仕様の検証ルールのセットを補完します。







5.3.2.1。 主な事実の検証



主要な概念の事実は、概念とコンテキストに基づいて検証する必要があります。 has-hypercube



関係がその概念に対して定義されていない場合、ファクトは測定によって自動的に有効と見なされます。







has-hypercube



関係がconcept has-hypercube



定義されている場合、それらによって示されるhas-hypercube



は測定で有効でなければなりません。 ファクトコンテキストには、少なくとも1つの基本セット内に関連付けられているハイパーキューブの各ディメンションのドメイン要素または値の有効な組み合わせが含まれている必要があります。 ディメンション値が指定されていない場合、デフォルトのディメンション値（存在する場合）が使用されます。 複数のディメンション値を指定しないでください。







ディメンション内の指定された値の有効性を判断する際には、 domain-member



関係でusable



な属性やhas-hypercube



関係でclosed



られた属性などが考慮されることに注意してください。







測定検証の規範的な定義を説明するには、XBRL Dimensions仕様のいくつかのページが必要だったため、ここで説明したよりも現実は少し複雑です。 ただし、上記の単純な規則と常識により、次元検証とは何かを十分に理解できます。


5.3.3。 等しい測定



XBRL Dimensions仕様は、XBRL仕様の広範なリストに新しいタイプの平等-d-equalを追加します。 2つのファクトが同じディメンションの値を持っている場合、2つのファクトは1つのディメンションに対してd-equalと見なされます。













More articles:


All Articles