SMLは本物のDSLか、それとも単なるもう一つのフレームワークか
ドメイン固有言語(DSL)は、汎用言語をAPIで包んだだけのものではなく、特定のドメインに合わせて仕立てられた言語を提供すべきものです。独自の構文、ドメイン固有の抽象、そして定型コードを減らす仕組みが求められます。では、SML(Semantic Modeling Language)はどこに位置づけられるのでしょうか。本物のDSLなのか、それとも単なるもう一つのフレームワークなのか。
そもそもSMLとは何か
SMLはSemantic Modeling Languageの略です。ビジネスインテリジェンスにおける意味モデリングのために設計されており、ディメンション、階層、関係、算出メトリクスを定義するための言語を提供します。このドメインに特化した構文によって、多次元データモデリングを簡素化することを目指しています。
関心がおありなら、SMLそのものをコードでご覧ください。
本物のDSLの条件とは
真のDSLは、次を満たすべきです。
- 独自の構文と文法を持つこと:既存の言語を包むのではなく、ドメイン固有の構文を導入すべきです。
- ドメイン固有の抽象を提供すること:言語はドメインの概念に沿い、タスクを直感的にし、複雑さを減らすべきです。
- 定型コードを減らすこと:DSLは反復的な作業を最小化し、実装の詳細ではなくドメインのロジックを表現することに焦点を当てます。
- 汎用言語から独立していること:真のDSLは、汎用言語の構文に大きく依存することなく、単独で成立すべきです。
SMLは条件を満たすか
構文と文法:SMLはモデルや算出を定義するための独自の構文を導入します。次はSMLの
calculationファイルの例です。unique_name: Average Catalog Unit Net Profit object_type: metric_calc label: Average Catalog Unit Net Profit expression: "[Measures].[m_cs_net_profit_sum]/[Measures].[m_cs_quantity_sum]"この構文はSMLに固有のもので、カスタム算出を簡潔に定義する手段を提供し、汎用的なコードや設定ファイルとは一線を画します。
ドメイン固有の抽象:SMLは多次元モデリングの概念とよく整合します。関係、メトリクス、ディメンションを、ビジネスインテリジェンスでの用いられ方を反映する形で定義できます。例えば、データセット間の関係の定義は直感的です。
unique_name: factinternetsales_Date_Dimension_Order from: dataset: factinternetsales join_columns: - orderdatekey to: dimension: Date Dimension level: DayMonth role_play: "Order {0}"これは、SMLが複雑なデータ関係をドメインに親しみやすい形で抽象化する様子を示しています。
定型コードの削減:SMLは、SQLやORMフレームワークに比べて、複雑な関係や算出の定義を簡素化します。算出や関係を定義する構文は必要なコード量を減らし、ドメインの論理的な表現に焦点を当てます。
汎用言語からの独立性:SMLはPythonやSQLなど他の言語の知識を必要としませんが、それらからいくつかのメンタルモデルを借りています。算出式はMDX風の構文を用いており、SQLやOLAPの利用者には馴染みがあるかもしれませんが、それでも独自の構成として成立しています。
結論
SMLは、独自の構文、ドメインに沿った抽象、定型コードの削減という、真のDSLの条件のほとんどを満たしています。とはいえ、汎用言語との類似を十分に残しており、フレームワークの領域を完全には抜け出していません。他のパラダイムから完全に切り離されたDSLを求める純粋主義者にとっては、SMLは十分に満足のいくものではないかもしれません。しかし、言語とフレームワークの間にまたがる実用的な道具としては、SMLはかなり良いところまで来ています。
SMLは真のDSLなのか。おおよそ85%といったところです。柔軟性とドメイン固有性の必要性を釣り合わせながら、意味モデリングという目的を効果的に果たしています。