|
4. STEPlib／RDL詳細
4.1.1.1 一般的なデータモデリング手法について
今日一般に行われているデータモデリングの手法は、”エンティティ型”（”オブジェクト型”といってもよい）とそれらに関係する”属性型”並びにエンティティ型相互の関係を駆使したものである。これらの関係は特別の属性型で表現されていて、”foreign
key”と呼ばれている。オブジェクト指向によるモデリングでは、幾つかの付加的な概念が使われて、その一つに”メソッド”がありオブジェクトのビヘイビアーをイベントとサブタイプを用いて記述する。ここにサブタイプとは、オブジェクト型の間でスーパー／サブの関係を定義するものでその属性やビヘイビアーを下位のオブジェクト型（子オブジェクト）に上位の型（親オブジェクト）から継承を定義するものである。
この手法のもう一つの基本的なものは、”インスタンス”である。インスタンスとはデータベースの利用者によって入力されるもので、属性型のインスタンスとして保存され、インスタンスというエンティティ型にグルーピングされるものである。
これらの概念は、ITの専門家（データモデリング家）によって用いられ、”データモデル”として記憶されデータベースの構造を決定する。そのデータモデルは、実データを解釈するためのセマンティクスを定義し、利用者が属性のインスタンスを保存するのに供する。
4.1.1.2 現在行われている手法の問題点
今日一般的になっているデータモデリングに共通した特徴は、データモデルの定義が2つに明確かつ強固に分けられていることで、一つはデータ構造でセマンティクスやユーザデータの意味を定義している。もう一つはユーザデータである。その結果として、この手法では、セマンティクスルールの定義には、一般のデータベースのアプリケーション利用者の立場ではアクセスできないし拡張もできず、通常は”ユーザインターフェイス”を用いることで隠蔽されている。この為に統合やお互いのシナジー効果が発揮できてない。このことは、人間の一般的なコミュニケーションと大きく異なっているといえる。というのも交換データが表現されているのと同じ言語で、解釈のルールを提供することが出来るからである。
注： |
|
この二者間の隔たりが当たり前のものとなっていて、エンティティ型と属性型が固定された名前を持つのだが、これは普通の仕事で遭遇するオブジェクト型の名前とは明らかに異なっている。このITモデルとユーザデータ間で異なっているということが、さらにインテグレーションの障壁にもなっている。
|
また今日の手法の別の制約として、一旦データベースの設定が終了すると、そのデータモデルが固定され、ユーザデータを解釈するセマンティクスが固定されてしまうことがある。このセマンティクスを拡張するには、データベースの構造を再定義して、古いデータを新しいものに移してやらなければならない。
今の手法に対するもう一つの制約は、データモデルのスコープが制限されていても、あるいはデータモデルが大きくなったり、あるいは汎用的になっても、それをいじることが容易ではない。データモデルの汎用化はセマンティックの確かさを失うことにつながる。
最後に、データモデルは、それぞれ異なっていて、異なるシステム間のデータ交換は、特定のデータ構造毎に行われなければならないことである。これは今日のデータモデリング手法が、システマティックではなく、既存のものを再利用する為の標準化されたアプローチではないことを意味する。
本報では、こういったユーザデータとITモデルデータの間で制約や障壁を持たない方法論を簡潔に紹介する。反面、それは沢山の拡張可能なセマンティクスを定義するもので、データベースそのものに保存され20,000エンティティとそれに関係する属性からなるデータモデルに等しい。
セマンティクスの柔軟性は、次の事柄によって達成される；
1. クラス（type of things）に関する知識と個別のオブジェクトの知識の両者を同じデータベースに保存できる
2. 属性型とインスタンスとの間の処理の相違が発生しない、属性型をクラスとしてインスタンスと対でデータベースに保存していて、インスタンスを個別の属性値（インスタンス）と該当するクラス間の明示的なクラスの関係で置換えている。
3. エンティティ型と属性型の間の相違をなくして、エンティティとその属性との間の暗黙の関係をインスタンス間の明示的な’possession of aspect’関係で置き換えている。
図8は一般的な手法と本報で述べるGellish手法との本質的な概念を比較している。
(EXPRESS) Data Model Concepts |
(AP221) Gellish Data Base Concepts |
1. |
Instantiation
-Implicit classification relations |
1. |
Explicit classification relations |
2. |
Entities have Attributes
-Implicit relations between entity and attributes
-Implicit roles of objects in relations |
2. |
Explicit Relations between objects
Explicit roles of objects in relations |
3. |
Subtyping of entities (not of attributes)
-Methodology does not require a consistent subtyping strategy
-Usually a limited use of inheritance |
3. |
Specialization relations between classes
-Methodology requires that every class has at least one supertype, which results in one big specialization hierarchy
-Full use of inheritance |
4. |
Entity and attribute types are not instances (fixed data model)
-Fixed knowledge model outside database |
4. |
Entity types and attribute types (classes) are instances
-Flexible knowledge model in database |
図8 Comparison of EXPRESS concepts with Gellish concepts
アプリケーションにGellish Methodologyを適用すると、データモデルは柔軟性に富み拡張性も持つことができる、それはユーザのknowledgeを保存するもので、ユーザにはメタなモデルに見える。
Libraryに定義されているSTEPlibとGellish言語は、このMethodologyを実装したものである。一方STEPlib
Browserはアプリケーションソフトウェアで、knowledgeや個々のオブジェクトをビューイングするもので、このMethodologyの素晴らしさを体験できるものである。
より詳しい情報については、次のものを参照されたい；
−Gellish on the Web, a short introduction of the capabilities of Gellish to express messages.
−Guide on STEPlib, a guide to extent STEPlib and the
Gellish language
−The Gellish Reference Manual, a Gellish user guide
−The STEPlib database, a set of tables (in EXCEL) or a CLB database file native to the STEPlib Browser.
−The STEPlib Browser
このパラグラフでは、データとセマンティクスの保存について、通常の場合とGellishの場合について比べてみる。
次の例にて説明すると；
−あるポンプ（‘P-1’）が、ある流体（‘S-1’）を汲み上げているとする。
通常のデータベースでは、物の解釈をするセマンティクスを定義する為に、データモデルとして幾つかのエンティティ型と属性型を定義しなければならない。この例では、データモデルは、エンティティ型として、‘pump’、‘process’や‘stream’及びそれぞれの属性が定義される。
Gellishでは、‘pump’、‘process’や‘stream’の概念はエンティティ型ではなく、インスタンスの関係によって汎用的なデータベースに定義されるもので、最低限の数の‘basic
semantic axioms’のみを知るだけなのである。またデータベースには沢山の付加的な事柄をふくんでいる。最低限の数の‘basic semantic
axioms’は、予め分かっていなければいけないし、かつ付加的なセマンティクスな事柄を定義するに十分なものでなければならない。
新しい事柄を定義するには、数々の初歩的な事を、新しい事柄と既存の事柄との間の関係を表現して定義する必要がある。別の言い方をするなら、新規の事柄は図9に示す構造を作る必要がある。
心得ておく必要がある最低限の数の‘basic semantic axioms’とは；
−anything
−role
−relation／relations
−plays role
−requires role
−is／is a (is classified as a)
−specialization of kind (is a specialization of)
−individual thing／individual things
−kind of thing／kind of things
−single thing／plural thing
この最低セットは図9に示されている。
| （拡大画面：36KB） |
|
図9 Basic semantic axioms
2つまたはそれ以上の‘オブジェクト’間の‘atomic relation’によって、‘オブジェクト’と‘role’と‘relation’のクラス分けによって、新しい‘atomic
fact’が表現される。これは、新しいatomic factは、図9の青い箱で表わされた9ケのrelation（5ケ中4ケの箱は2つのrelationを持つ）によって表わされるということを意味する。セマンティックを拡張する新しいfactは、‘オブジェクト’間のrelationによって表現される、そのオブジェクトとはkind
of thingsである。
例として、インペラーO1が渦巻ポンプO2のpartである（impeller O1 is part of centrifugal pump O2）場合を、Gellishで次の4ケの初歩的な関係で表わす；
−object O1 plays role R1
−role R1 is required by relation C1
−relation C1 requires role R2
−role R2 is played by object O2
次の5ケの付加クラスのrelationがある；
−O1 is classified as an 'impeller'
−R1 is classified as a 'part'
−C1 is classified as a 'part-whole relation'
−R2 is classified as a 'whole'
−O2 is classified as a 'centrifugal pump'
実際に実装するには、Roleとクラスに対する明示的な識別子は無視される。何故ならrelationのクラスで賄われるからである。
従って、上記の関係は、通常つぎの3ケのGellishに集約される；
−O1 is classified as an 'impeller'
−O1 is part of O2
−O2 is classified as a 'centrifugal pump'
この例として、5ケのクラス分けされたkind of thingsが、これが定義される以前に、定義されていなければならない。これは、STEPlibライブラリで使えるようにGellishデータベースのトップダウン階層定義を生むことにある。
一例として、‘centrifugal pump’という定義は、分かっている必要がある。この考えは2ケの関係で定義される；
−以下の定義を行うrelationの特殊化（specialization）；
'centrifugal pump’は‘pump’のサブタイプである
−Centrifugal pumpを定義するには、centrifugalの原則を用いる
'centrifugal pump’は‘centrifugal’と定義される
双方の関係は、‘pump’と‘centrifugal’に関する以降の詳細な定義に立脚して作られる。
図2の各々の箱は、単数のthingまたは複数のthingとして解釈されることに注意のこと。例えば、もし‘anything’が複数のものに対するポインターであれば、そのクラスの関係は複数の各要素毎のクラスになる。さらに、‘kind of thing’は、3ケのクラスに対してkind of anything、つまりkind of roleとkind of relationをそれぞれ表わすので、‘kind of things’になる。
|
