今回は、かなりざっくりとですが、今後、Autodesk Platform Services(旧 Forge、以後 APS と表現)で扱うことになるデータ構造、あるいは、データベース構造に触れておきたいと思います。
設計データのファイル
CAD ソフトウェアが扱うファイルには、さまざまなデータが論理的に格納されています。最もシンプルな AutoCAD の DWGで見てみると、分かりやすくタイプ別にまとめられていることがわかります。
また、CAD ソフトウェアのファイルには、データ間の関係性も同時に保持されています。BIM を活用されている方には、自明のことと思いますが、この関係性の情報は非常に重要です。先の DWG でも、各データが別のデータを参照し合っています。モデル空間に作図されている円(Circle)や線分(Line)などの図形と画層(LayerTableRecord)の関係やブロック参照(BlockReference)とブロック定義(BlockTableRecord)の関係などです。
そして、設計ツールとデザインデータの遷移 でも触れたとおり、 時代とともに、扱うデータと表現は多岐にわたり、かつ、膨大になりつつあります。
SQL データベース
別の視点でデータを考えてみると、「設計データ」として直接扱わないタイプのデータとも連携が必要になることがあります。他社のコンポーネントや部材を設計に組み込む場合、それらのメーカーや型番、場合によっては在庫状況や新たに発注した場合の納期などの情報です。
このような場面では、サイドデータベースと呼ばれる外部データベースと連携する仕組みを構築するのが一般的です。この外部データベースとの併用は古くから活用されています。2D 図面運用でも比較的早い時期から機能を提供していました。例えば、AutoCAD では AutoCAD SQL Extension(略称 ASE、現 dbConnect)という機能を用意して、エンティティ(図形)と外部データベースに関係性を持てるようにしています。
CAD ソフトウェアとの連携で利用されてきたのは、リレーショナルデータベース(RDB)と呼ばれる SQL(Structured Query Language)タイプのデータベースです(以後 SQL データベース) 。クライアント コンピュータでの利用では、おそらく、Microsoft Access が最も馴染みのある RDB かもしれません。
SQL データベースは、データを格納するテーブル、カラム(行)、レコード(列)、フィールド、で構成された、いわゆる、構造化された(Structure)データベースです。格納すべきデータはデータタイプ(整数、実数、文字列など)と共に厳密に定義されているのが特徴です。また、レコードは特定のフィールド(キー)を使用して、他のテーブルの特定のレコードと関係性を維持しています。そして、RDB にデータを照会(クエリ)するのが 、SELECT 句を駆使する SQL 文というわけです。
SQL データベースについて簡単にまとめると、「データ タイプ別のテーブルに格納した情報が互いに参照し合うことでデータを表現する最適化されたデータベース」ということになるかと思います。
少し話が逸れますが、先の図で紹介した DWG が持つデータも、RDB の似た構造であることにお気づきと思います。もちろん、DWG 自体は AutoCAD 固有のファイルなので、SQL 言語で内部データをクエリ出来るわけではありません。
グラフ データベース
長らく利用されてきた SQL データベースですが、Web やクラウドの活用、IoT センサーや点群など、データソースが多様化し、データ間の関係性が複雑化してきています。言うまでもなく、オートデスクも APS を使った API 環境を提供することで、こういった活用を支援しています。
ただ、パフォーマンスの問題が表面化してきています。例えば、大規模な BIM データの場合、Model Derivative API:メタデータの活用 の方法で JSON データを取得するまでに一定程度時間がかかりますし、そうのような JSON データのパースにも時間がかかることも想像に難くありません。参考まで、Model Derivative API はバックエンドで SQL データベースとも言える SQLite を利用しています。
いわゆる、ビックデータに取り組む必要が急務な状態です。
そんな中で、パフォーマンスを維持したままビックデータを扱える新たなデータベースとして、NoSQL(Not only SQL)タイプのデータベースが脚光を浴びています。
NoSQL にはいくつかタイプが存在しますが、共通するのがデータ タイプや数に寛容な点です。既に APS で開発をされているなら、テーブルやレコードを気にせずに JSON が持つ内容をそのまま扱える、といった気軽さがあります。
NoSQL はパフォーマンスにも優れています。SQL データベースのように事前に定義されたデータタイプに沿った処理に限定されないので、ビックデータであっても、圧倒的に短い時間でクエリ結果を得ることが出来るようになる利点もあります。
APS を使ったアプリがサイドデータベースを使う APS サンプルでは、利用している MongoDB もNoSQL データベースの 1 つです。MongoDB は、NoSQL データベースの中でドキュメント指向データベースに分類されています。
さて、前置きが長くなりましたが、APS が採用を進めているデータ構造、ないし、データベース構造とは何でしょうか?
NoSQL データベースの 1 つであるグラフ指向データベース、グラフ データベースです。グラフ データベースはデータ間の関係を扱うネットワーク状モデルです。データはキーと値の組み合わせで構成されるプロパティで、プロパティ間の関係性はノードと呼ばれる単位を、エッジで結ぶかたちで表現されます。
この構造は、CAD のデータとデータ間の関係性を表現する最小単位として考えられると思います。そして、この構造こそが、インダストリークラウドや Data Exchange(データ交換)で取り組むことになる粒状データを表現するデータ構造ということになります。
これらは、ファイル内ではなく、クラウド上で実現されることになります。BIM で扱うようなビックデータも、グラフ データベース構造を持つ粒状データをクエリしていくことになります。
By Toshiaki Isezaki
コメント