Как импортировать данные XBRL в MySQL?

Я работаю над проектом, связанным с обработкой большого объема документов XBRL ( > 1 м отдельных файлов). Я совершенно не знаком с XBRL и чувствую себя совершенно потерянным на данный момент.

У меня есть данные, относящиеся к этим документам XBRL в отдельной базе данных MySQL, и я хотел бы добавить данные XBRL в MySQL, чтобы хранить все в одном db.

Каковы наилучшие методы переноса данных из документов XBRL в MySQL?

Существуют ли для него библиотеки массовой обработки?

Я искал учебники по этим вопросам, но не смог найти ничего, обеспечивающего базовое введение, просто много информации высокого уровня.

Ответ 1

Естественная парадигма в теории для хранения XBRL в базе данных будет OLAP, потому что XBRL - это кубы данных. OLAP поверх реляционной базы данных будет называться ROLAP.

Это не тривиальная проблема, потому что факты, взятые из большого числа таксономий, могут образовывать очень большой и разреженный куб (для SEC регистрирует его размеры 10k +), а также потому, что при создании схемы SQL требуется знание таксономий перед любым импортом, Если появятся новые таксономии, нужно снова пересмотреть ETL. Это не делает реляционные базы данных подходящими в качестве общего решения.

Если заявки имеют одинаковую таксономию, и таксономия очень проста, хотя (как и в: не слишком много измерений), можно создать ad-hoc-отображение, чтобы хранить все факты в одной таблице со многими строками в смысле ROLAP (факты для строк, аспекты для столбцов). Некоторые поставщики специализируются на хранении фактов безразмерного XBRL, и в этом случае традиционные SQL (или "пост-SQL", которые масштабируются с помощью рядов), работают хорошо.

Некоторые производители создают таблицу для каждого гиперкабеля XBRL в таксономии, с помощью схемы, полученной из сети определения, но различной для каждого гиперкуба. Это может привести к большому количеству таблиц в базе данных и требует большого количества объединений для запросов с участием нескольких гиперкубов.

Некоторые другие производители делают предположения о базовой структуре XBRL или о запросах, которые должны выполнять их пользователи. Ограничение объема проблемы позволяет находить определенные архитектуры или схемы SQL, которые также могут выполнять работу для этих конкретных потребностей.

Чтобы импортировать большое количество заявок (например, все заявки SEC), мы (мой работодатель) построили общее сопоставление поверх данных NoSQL а не реляционные базы данных. Большое количество фактов с различным количеством измерений вписывается в большие коллекции полуструктурированных документов, а сети хорошо вписываются в иерархический формат.

Ответ 2

Сначала вам нужно понять, что документы (экземпляры) XBRL содержат много разных типов информации. Например: он может содержать ежедневную информацию о ценах для инвестиционных фондов, а также ежеквартальные отчеты по НДС или информацию о кредитоспособности. XBRL - это стандартный способ общения, но содержание имеет свои собственные (стандартизованные XBRL) таксономии. Например: существует голландская таксономия, на которой строится голландское агентство по доходам (с его собственной таксономией), по которому существует конкретная таксономия для подачи отчетов об НДС. Эти таксономии определяются с использованием XSD, Xlink и linkbase. Подумайте об этом как о концепции Dictionairy: способ создания диктовки везде одинаковый (используйте каждую букву алфавита, чтобы сделать "главы", сортировать слова в алфавитном порядке и т.д. И т.д.), Но греческое словосочетание использует свой собственный алфавит, его собственные слова и собственный язык, чтобы объяснить содержание.

Итак, если вы используете только один или несколько разных типов документов XBRL (которые используют одни и те же таксономии), вы можете создать сопоставление от этих таксономий к вашим собственным (базам данных) объектам. Если у вас более широкий диапазон таксономий, вам придется создать более общее решение, которое может "импортировать" таксономии. Это будет довольно сложной задачей (именно поэтому на рынке мало доступных инструментов).

Если вы (r company) можете себе это позволить, я рекомендую изучить существующие tools, например Altova MapForce. Таким образом, нет необходимости изучать XBRL, XSD, Xlink и linkbase только для того, чтобы начать разработку собственного инструмента для анализа этих файлов, вы можете использовать существующие продукты для сопоставления таксономий XBRL с вашей базой данных/приложением.

Ответ 3

Надеюсь, вы знаете, что MySQL - это структурированное хранилище данных, а XBRL - просто представление для сопоставления бизнес-документа в цифровом формате. XBRL является документом на основе XML, что означает, что он неструктурирован, а данные, требуемые из документа, могут или не могут встречаться в этом конкретном документе. Он также может содержать любую другую дополнительную информацию. XSD определяет, как XML может быть структурирован и сколько раз может появляться любой тег. Теперь, чтобы ответить на ваш вопрос, вы можете использовать eXistDB, который я также использовал в прошлом для хранения документа XBRL. Однако время от времени оно может быть медленным. Если вам нужны только некоторые данные из XBRL, и им нужно хранить в базе данных MySQL, вы можете использовать XPATH. В следующем простом коде Python вы можете захватить значения EquityTotalEndingBalance и ReservesTotalEndingBalance из этого документа.

from lxml import etree
root = etree.fromstring(open("file.xml").read())
nsmap = root.nsmap
nsmap.pop(None) # There was some error without this.
data_one = root.xpath("//iascf-pfs:EquityTotalEndingBalance/text()",namespaces=nsmap)
data_two = root.xpath("//novartis:ReservesTotalEndingBalance/text()",namespaces=nsmap)
print data_one
print data_two

Этот код напечатает значения:

['37216000000', '36862000000', '42245000000']
['35903000000', '35558000000', '40971000000']

Итак, как вы можете решить свою проблему?

  • Либо вам придется выбрать хранилище XML-документов NoSQL, например eXistDB, и написать Xpath для получения конкретных данных.

  • Вы можете вручную проанализировать документ XBRL, как указано выше, и сразу запустить XPath и сохранить данные.

Сложность возникнет, если вам нужно будет использовать все данные из всех типов документов. Таким образом, вам придется ограничить то, что вы будете потреблять из этих документов.