XBRLはデータキューブに関するものであるため、データベースにXBRLを格納するための理論上の自然なパラダイムはOLAPです。リレーショナルデータベース上のOLAPはROLAPと呼ばれます。
多数の分類法から取得したファクトが非常に大きくてまばらなキューブを形成する可能性があるため（SECファイリングの場合は10k以上の次元）、SQLスキーマを作成するには、インポートする前に分類法を知る必要があるため、これは簡単な問題ではありません。新しい分類法が登場した場合は、すべてを再ETLする必要があります。これは、リレーショナルデータベースを一般的なソリューションとして適切にするものではありません。
ファイリングが同じ分類法を共有し、分類法が非常に単純である場合（たとえば、次元が多すぎない場合）、ROLAPに多くの行がある単一のテーブルにすべてのファクトを格納するためのアドホックマッピングを考え出すことができます。センス（行へのファクト、列へのアスペクト）。一部のベンダーは、無次元のXBRLファクトの保存を専門としています。その場合、従来のSQL（または行に比例する「post-SQL」）オファリングが適切に機能します。
一部のベンダーは、分類法のXBRLハイパーキューブごとにテーブルを作成します。スキーマは定義ネットワークから派生していますが、ハイパーキューブごとに異なります。これにより、データベースに多数のテーブルが作成される可能性があり、複数のハイパーキューブを含むクエリには多数の結合が必要になります。
他のベンダーの中には、基盤となるXBRL構造、またはユーザーが実行する必要のあるクエリの種類について想定しているものもあります。問題の範囲を制限することで、これらの特定のニーズに対応できる特定のアーキテクチャまたはSQLスキーマを見つけることができます。
最後に、大量のファイリングをインポートするために、リレーショナルデータベースではなくNoSQLデータストアの上に汎用マッピングを構築することができます。さまざまな次元の多数のファクトが半構造化ドキュメントの大規模なコレクションに適合し、ネットワークは階層形式に適合します。