またまた期間が空いてしまいました。

ブログ更新は超サボってますが、開発は順調に進んでいます。

一応さほどの手詰まり無く進んではいるのですが、なかなかやってきたことを文章化する時間を取れていません。

と、時間を言い訳に隙間時間は全部開発に充てていたのですが、ふとソースコードを見返したところ、もう既に何やってたか思い出せない箇所が出てきたのでいい加減進捗を書きます。

まずは全体の構成図から今回の開発範囲を記述します。今は以下の赤枠内を開発中です。

XBRLファイルを取得してくる箇所は開発済みですので、これを決算データとしてデータベースに投入しようとしています。

しかし、このXBRLが一筋縄ではいかない構造をしており、Pythonの処理内のみで決算データに変換するのはかなり無理のある構造になると断念して中間データを作るような形式に変えました。

今回の開発進捗はこのSTEP1です。STEP2については現在開発中です。

なぜこのような構造を取らざるを得なかったか、また、この実装を行う上でBeautySoupというPythonパッケージが大活躍したのでその紹介です。

XBRLをパースしようとする場合、他でも応用の効く内容です。

XBRLの構造とデータ化について

XBRLの説明なのですが、今回の様にデータベース化する場合に絞った情報です。

ちゃんと説明するともっと語ることがあるみたいですが、やりたいことに対してあまりにも余計な情報が多すぎます。

学習に時間を取られるのが勿体なかったので、必要最低限必要な理解に留めています。もし、誤りがあったらごめんなさい。

まず、XBRLは大きく分けて「文字データ」と「数値データ」と「自由に書ける情報」の3つに分かれています。

「自由に書ける情報」については大半がhtmlの体裁のための情報や「売上高」といったラベル文字列ですので今回不要です。

必要なのは「文字データ ix:nonnumeric」と「数値データ ix:nonfraction」です。

文字データを例に説明します。

文字データ(ix:nonnumeric)について

「ix:nonnumeric」というタグ名で始まるのが文字データです。XBRLは規格ですので、要素内の名称や取れる値に既定のルールがあります。

なのでデータの一つ一つを確認し、例えば、

証券コードが、name=「~SecuritiesCode」

決算期が、name=「~FiscalYearEnd」

という対比を作っていけばXBRLを決算データ化する事が出来ます。

しかし、データ分析やテーブル設計の分野では、この様な課題が発生した際、いきなり目的の構造化したデータを作ることはしません。

前回の進捗報告で記述した、「ログ層、集約層、集計層」というデータ構造の基本的な考え方に基づいてテーブル設計を行う必要があります。

つまり、今回の件で言えば、以下のようなデータを作ります。

filename	contextref	format	name	text
tse-qcedjpsm-…	CurrentAccumulatedQ3Instant		tse-ed-t:DocumentName	第３四半期決算短信〔日本基準〕(連結)
tse-qcedjpsm-…	CurrentAccumulatedQ3Instant	ixt:dateerayearmonthdayjp	tse-ed-t:FilingDate	平成30年9月10日