理论上将XBRL存储在数据库中的自然范例将是OLAP,因为XBRL是关于数据立方体的.关系数据库之上的OLAP将被称为ROLAP.
这不是一个微不足道的问题,因为从大量分类法中获取的事实可以形成一个非常庞大且稀疏的立方体(对于SEC文件,它是10k +维度),并且还因为创建SQL模式需要在导入之前知道分类法.如果出现新的分类法,就需要重新设计ETL.这不会使关系数据库适合作为一般解决方案.
如果文件共享相同的分类法,并且分类法非常简单(如:不是太多维度),则可以提出一个ad-hoc映射来将所有事实存储在ROLAP中包含许多行的单个表中感觉(事实到行,方面到列).一些供应商专门存储非维度XBRL事实,在这种情况下,传统的SQL(或"后行SQL",可以扩展行)提供良好的工作.
一些供应商为分类中的每个XBRL超立方体创建一个表,其中的模式派生自定义网络,但每个超立方体都有所不同.这可能导致数据库中的许多表,并且对于涉及多个超立方体的查询需要大量连接.
其他一些供应商对基础XBRL结构或其用户需要运行的查询类型做出假设.限制问题的范围允许查找特定的体系结构或SQL模式,这些体系结构或SQL模式也可以满足这些特定需求.
最后,要导入大量文件,可以在NoSQL数据存储而不是关系数据库之上构建通用映射.具有不同维度的大量事实适合于大型半结构化文档集合,并且网络很好地适合于分层格式.
首先您需要认识到 XBRL 文档（实例）包含许多不同类型的信息。例如：它可以包含投资基金的每日定价信息，还可以包含季度增值税报告或信用度信息。XBRL 是一种标准的通信方式，但内容有自己的（XBRL 标准化）分类法。例如：有一个荷兰分类法，荷兰税务机构是在该分类法的基础上建立的（有自己的分类法），在此基础上有一个用于提交增值税报告的特定分类法。这些分类法是使用 XSD、Xlink 和链接库定义的。将其视为字典的概念：字典的构建方式在任何地方都是相同的（使用字母表中的每个字母来组成“章节”，按字母顺序对单词进行排序等），但是希腊字典使用它自己的字母表，它的用自己的话和自己的语言来解释内容。
因此，如果您仅使用一种或几种不同类型的 XBRL 文档（共享相同的分类法），则可以创建从这些分类法到您自己的（数据库）对象的映射。如果您有更广泛的分类法，则必须创建一个可以“导入”分类法的更通用的解决方案。这将是一个相当大的挑战（这就是市场上可用工具不多的原因）。
如果您（公司）负担得起，我建议您研究现有工具 ，例如Altova 的 MapForce。这样，您无需为了开始开发自己的工具来解析这些文件而学习 XBRL、XSD、Xlink 和 linkbase，您可以利用现有产品将 XBRL 分类法映射到您的数据库/应用程序。